Claude 如何走向生产：Anthropic 谈模型发布、安全边界与工程责任

一、嘉宾背景

这期 Latent Space 由 Alessio Fanelli 与 Shawn swyx Wang 主持，嘉宾是 Anthropic 的 Katelyn Lesse 和 Angela Jiang，节目时长约107分钟。访谈围绕模型能力如何进入产品与生产系统展开，从发布前的客户反馈，一直谈到 API、基础设施和开发者生态。

两位嘉宾从不同工作侧面解释这些问题。Angela 关注产品中的取舍，包括智能水平、成本、安全和商业影响；Katelyn 更侧重工程实现、API 集成与开发者体验。两人曾在 Stripe 共事。她们的工作范围也决定了这场讨论的重心：模型行为的变化，需要同时放到用户需求、接口约束和系统运行条件中理解。

Katelyn 介绍，她所在的团队负责平台、API 业务和产品基础设施，并参与建立分别面向 API 和 agentic coding 生态、相互协作的 DevRel 团队。她的工作横跨客户如何评价模型行为、授权如何在系统中传递、沙箱如何运行、接口如何升级，以及开发者如何完成集成。两位嘉宾提供的是参与这些工作的产品与工程经验；涉及效果的判断，也需要结合她们所描述的环境理解。

二、本期主要内容

主持人以两个循环解释 Anthropic 的增长：模型改进带来更多用例和反馈，收入增长则支持进一步投资与能力提升；内部产品复用平台原语，让平台同时承接内部和外部开发者的需求。这是主持人组织讨论的解释框架。他还援引人均收入从140万美元增至660万美元、季度 GAAP 利润率19%等数字。给定材料没有提供独立核验文件，人均收入、计算成本对应收入和会计利润也不能合并为同一口径的效率指标。这些财务陈述构成了采访的背景，工程与产品表现仍需由具体过程和结果支撑。

据嘉宾介绍，模型发布要经过安全测试、能力评估、多个候选版本和内部试用，再通过自有产品或 API 客户的早期访问，收集正式评测结果与主观反馈。Cognition 和 Cursor 是她们列举的合作示例。早期访问更倾向于拥有成熟评测集、能够在候选版本到全面开放的紧凑窗口内迅速返回结果的客户。外部 harness，也就是组织工具调用、上下文和执行过程的运行框架，还能发现内部试用未曾覆盖的问题。

不同接口承担的工作有所不同。Messages API 提供较原始的 token 访问；Claude Managed Agents 则提供定义 agent、启动 session 的高层接口，代管 harness 和基础设施。不同产品可以共用 sandbox 基础设施，但不意味着共用同一套 harness。团队刻意保持基础 harness 简单，将 Dreaming 这样的策略放在上层：由另一个 managed agent 检查先前 agent 的工作，并写入记忆。嘉宾表示，部分探索因安全投入而放缓，开放更多原语和模板仍在计划之中。

基础设施压力具体体现为 CPU 容量的竞争。嘉宾称，产品、API、沙箱、CI 和训练都需要容量，团队必须提前规划，同时维持租户隔离。在将 Python API 移植到 Rust 的过程中，人类负责系统设计、计划和验证，Claude 承担 Rust API 实现。团队先建立完整的平行版本，通过影子流量对照 Python 输出，再逐步切换流量。期间，他们也招聘了更有 Rust 经验的人员。

嘉宾报告，Rust Messages API 已在访谈前一周全面上线，CPU 节省约40%—50%，首 token 时间改善约10%—20%；针对长时负载的进一步改进当时尚待推出。这些数字是团队对该次迁移结果的自述。移植期间，团队严格限制新增功能，并用静态分析提醒并行开发者考虑 Rust 实现，避免两套代码持续偏离。服务端保存对话状态属于后续探索，而 prompt caching 本身仍要求客户端传回状态，两者不能混同。跨三大云部署也限制了团队对计算架构的选择。

三、核心观点：推理、例子与边界

模型质量需要结合任务和使用方式判断。嘉宾提到，一个候选模型曾因过于“懒惰”而重新训练；与此同时，另一些用户只想讨论方案，模型却提前开始写代码。两种反馈指向不同的行动边界。主持人由此追问：如果基准会因操作次数或文件修改而扣分，却没有纳入用户的个性化指令，是否会把可调整的行为误判为能力缺陷？嘉宾承认，个性化评测仍有不足。目前，团队依靠参数、面向不同用户群的默认值和人工判断缓解冲突，但这些办法难以随规模扩展，增加控制项也会提高 API 的使用复杂度。单一分数因而不足以说明模型在不同授权范围和用户偏好下的表现。

反蒸馏措施则把安全取舍带到了接口层。嘉宾将其主要理由归于安全：提取思维链可以帮助蒸馏，而衍生模型可能脱离 Anthropic 原有的输出安全分类器。这解释了团队采取措施的动机，但不足以独立证明每项限制的必要性或效果。跨轮保留 thinking blocks 会破坏部分客户手写的压缩流程，团队因此与客户及开源 harness 维护者协调，并提供兼容的 API compaction。她们尤其希望避免接口调整导致用户原本能够完成的任务变得无法完成。迁移是否必要，与迁移后任务能否继续完成，是发布验证中需要分别回答的问题。嘉宾称，在可测量范围内，相关措施显著增加了蒸馏难度；由于没有披露测量方法和量化幅度，这一判断不能换算成确定的防护成功率。

安全机制还对应着不同的观察范围。在线防护检查流经系统的内容，跨账号的协同行为却难以仅靠在线 token 检查发现，可能需要保留数据，再进行自动或人工审查；架构隔离处理的则是系统边界。嘉宾强调，数据保留政策按模型决定，某个模型的安排不能视为全平台统一规则。网络安全和生命科学验证项目同样按用户及用例审批，再通过 trust grants 将授权贯穿系统。这套机制后来复用于访问控制、迁移宽限和撤权。Angela 将较通用设计带来的复用解释为不确定环境中的组合下注经验。这一案例展示了通用原语的价值，但不足以推导出所有团队都应提前建设一套通用授权平台。

托管 Agent 的架构说明，可靠性和安全可以由同一组系统边界支撑。早期方案把 Claude Code 整体放入沙箱，既有启动等待，也会在沙箱死亡时丢失整个 agent。将持久化 harness、状态与按需执行沙箱分离后，执行容器的生命周期便不再决定任务的生命周期。凭证保存在独立 vault 中，agent 只看到占位符，真实凭证由出口代理注入；沙箱还可以设置域名允许列表或关闭网络，限制执行代码能够访问的外部资源。这些设计有助于减少故障的连带影响和凭证的直接暴露，但安全性仍取决于具体边界如何实现。嘉宾区分了训练中的受压任务与具备在线防护、架构隔离的生产环境，同时承认长时 Agent 的控制机制仍在发展。这些差异不能证明生产环境已经没有风险。

回退与路由讨论暴露出另一项限制：系统在任务开始时掌握的信息并不完整。主持人以生物作业中的误回退，以及安全卡分析约五分钟后才触发过滤的经历，讨论回退体验。后一个例子提示，判断可能涉及生成中的内容和累积上下文，仅检查初始提示未必足够。嘉宾承认连续回退的体验复杂，并介绍了服务端回退、SDK 辅助和重新提示等选择。信息不足也限制了成本路由：即使分类器表现很好，系统在任务开始时仍未必知道实际难度。因此，她更看好由同一模型随任务进展动态调整 effort，以减少模型切换带来的交互割裂。这仍是方向判断，尚不能视为已经实现的能力或成本优势。

四、学习与应用

构建 Agent 产品，可以先将“模型是否更好”转化为可检查的任务要求：用户希望讨论、规划还是执行，允许修改哪些对象，什么结果算完成。嘉宾建议从简单评测起步，结合确定性检查与 LLM-as-a-judge，持续扩大覆盖，避免因追求复杂方法而迟迟没有实际评测。主持人则强调预先定义目标，并区分评测、环境和模型各自造成的错误。应用时可以保留失败条件与预期结果，先检查工具和评分规则，再决定调整提示、修改 harness 或更换模型。模型评审能够补充反馈，但无法自动纠正对用户偏好的错误定义。

大型移植可以参考 Rust 案例的验证顺序：确定需要保持一致的行为，建立平行实现，通过影子流量比较输出，再逐步切流；新增能力留待后续阶段处理。并行开发也需要同步机制，否则旧实现继续增长，新实现就可能持续落后。这种方法适用于能够保留参照系统、对照关键输出的项目，同时需要承担维护两套实现和处理差异的成本。节目中约40%—50%的 CPU 节省属于该团队的迁移结果，不能作为其他项目采用 Rust 或 Claude 后的预期收益。容量决策仍应建立在自身瓶颈的测量之上。

长时任务的设计，需要先明确编排、状态、执行环境和凭证各自存放在哪里。按照嘉宾介绍的架构，任务进度应避免只存在于可销毁的沙箱中，真实凭证尽量经受控代理注入，并按任务需要限制网络出口。这些边界同时服务于可靠性和安全，但配置与实际执行路径仍须验证。采用托管服务时，也需要确认平台承担哪些编排和升级工作，以及应用仍需定义哪些任务权限。平台代管基础设施，并不能替代应用对业务动作合理性的判断。

多智能体实验应先判断问题能否并行。嘉宾建议设置 lead，使用共享上下文和状态，让子代理异步工作、互不阻塞。实践中，可以选择一个可拆分的问题，明确各子任务的交付结果与汇合方式，再与单 agent 方案比较质量、耗时和总成本。强顺序依赖的任务未必能从增加代理中获益，协调本身也有负担；节目没有提供量化加速或成本证据。Dreaming 这类上层策略，也应与现有底层能力及未来开放计划分别理解，不能把路线图当作已经可用的功能。

实现提速后，组织还需要决定如何使用节省下来的时间。访谈中的产品讨论强调用户理解、实验和明确目标，避免机械地增加功能。嘉宾认为，部分任务的收益已趋于饱和，长时工程和科学任务仍有空间，而现有流程的自动化效果因领域而异。对 AI 生成的代码和文档，团队要求提交者阅读、把关并承担质量责任；接收者可以退回低质量产物，但不应仅凭语言风格判断质量。快速确认代码建立在设计清楚、验证充分的基础上，不能据此普遍减少审查。

开发者教育则需要同时考虑人和 coding agent。嘉宾认为，cookbook 继续承担展示用例和实现思路的作用，Claude API skill 帮助 coding agent 完成集成。该 skill 由 DevRel 团队负责、Lance 构建，也明确了这类集成资产的维护责任。Katelyn 从产品、内容和社区三个方面理解 DevRel，强调平台需要自己的声音，也需要让反馈回到产品。主持人建议由负责人集中提供经验，再由专业团队制作传播内容；嘉宾认同，这能降低工程师参与社区的时间成本。对其他团队而言，值得借鉴的是让专家更容易输出经验，并检查内容是否帮助开发者完成集成、是否将实际问题带回产品。

来源

• 原始节目：How Anthropic ships the #1 LLM in the World — with Katelyn Lesse and Angela Jiang