Anthropic 如何用 Claude 开发 Claude

把模型接进产品，难点很快就会从「回答够不够聪明」变成「任务断了能否恢复、代码能拿到什么权限、升级 API 会不会把现有流程弄坏」。Latent Space 这次采访 Anthropic 的工程与产品负责人，讨论的正是这些问题。

最值得开发者带走的，是 Managed Agents 对运行架构的拆分：让保存任务进度、调度模型的「大脑」，与执行代码的「双手」分别运行。它也解释了一个现实：模型升级、安全约束和应用工程，已经很难分开处理。

为什么执行环境挂了，任务不该跟着消失

采访里最清楚的一条工程思路，是把 session log、harness 和 sandbox 拆开。session log 保存会话记录；harness 可以理解为 Agent 的运行控制程序，负责组织上下文、调用模型、调度工具；sandbox 则是实际执行代码的隔离环境。

他们描述的早期方案，是把整个编程 Agent 放进沙箱，再通过 API 对外提供服务。这样做容易理解，但启动环境和启动 Agent 都发生在首次响应之前，增加了等待。如果沙箱消失，运行中的 Agent 也一起消失。

Managed Agents 将会话记录和 harness 与执行沙箱分离。需要执行代码时再创建环境，执行环境失败，也不必直接结束整个会话。

执行环境可以被替换，任务进度应该独立保存。

这句话对长任务尤其有用。Agent 修改文件、运行检查、根据错误继续调整，可能跨越多轮模型调用。把这些进度只留在某个进程里，就把恢复能力绑在了进程寿命上。

但拆开不等于自动拥有完整的故障恢复。原文没有交代文件状态如何恢复、工具调用怎样避免重复执行，也没有公布拆分前后的延迟数据。它给出了架构方向，具体恢复机制仍需要应用自己落实。

密钥不进入沙箱，比提醒模型保密更可靠

同样的拆分，也带来一个直观的安全收益：执行生成代码的沙箱，如果从未收到服务凭证，代码就无法从这个沙箱里读出那份凭证。

采访描述的做法，是把凭证保存在其他位置，通过代理附加到请求上，同时限制沙箱流量可以访问的目标。这里有两个不同的问题：代码能否看到密钥，以及代码能够借助授权做什么。

前一个问题可以通过不注入密钥来缩小风险，后一个问题还要靠代理权限和网络控制解决。否则，代码即使读不到密钥，也可能通过过宽的代理权限执行不该执行的操作。

对运行 AI 生成代码的 Node 服务，这比给提示词加一句「不要泄露环境变量」更有工程价值。提示词约束模型行为，隔离架构则直接限制代码能够接触的资源。

采访还区分了训练中的异常行为与生产 API 的运行条件。训练实验可能刻意给模型施压，生产环境则有在线防护和外围架构。这个区分有助于理解风险，但不能据此推导出生产环境绝对安全。原文提供的是防护思路，没有完整的攻击测试结果或风险发生率。

升级 Opus 5.5，为什么还要检查上下文管理

Opus 5.5 的发布不只有模型能力和价格变化。Anthropic 表示，他们针对此前 Opus 5 写作冗长、表达绕的问题做了调整，也降低了运行成本；实际节省多少，取决于工作负载和上下文缓存的使用方式。

这些都是厂商在采访中的描述。材料没有给出可供复算的价格表，也没有一组相同任务的成本对照，不能直接换算成团队自己的降本比例。

更值得已有集成关注的，是 thinking blocks，也就是多轮交互中需要保留的思考内容块。Anthropic 希望限制推理轨迹被提取后用于模型蒸馏，因此逐步加强跨轮次保留这些内容的要求。

应用一侧的问题随之出现：原来能够运行的上下文压缩策略，可能不再符合新的要求。compaction 就是把较长历史压缩成较短上下文；如果应用自行删改了必须保留的内容，后续调用便可能受影响。

他们说，团队提前联系了开源 harness 维护者和大客户，并提供新的 API compaction 功能，替代部分原来由客户手工完成的压缩逻辑。原文没有给出具体 API 字段和调用示例，不能据此直接编写迁移代码。

这段讨论最实用的地方，是把兼容性分成两层：一层是需要修改接入代码，但原来的任务仍然能完成；另一层是升级后原来的任务已经做不了。Anthropic 表示，他们尽量避免后一种情况。

所以，切换模型不能只验证最终回答。历史消息如何保存、压缩后能否续跑、多模型协作怎样处理上下文，都可能成为兼容性的一部分。

我的判断

我更认可这篇采访对运行架构的解释。把持久状态、任务调度、不可信代码执行和凭证管理分开，各部分的职责与故障影响会更清楚。相比把整个 Agent 塞进一个容器，它为恢复、启动速度和权限管理留下了更多调整空间。

不过，简单任务未必需要立即照搬。生命周期很短、失败后可以整体重跑的任务，采用一个沙箱承载完整流程，也可能更容易维护。拆分之后，会话状态与执行状态如何同步，又会变成新的工程成本。作者没有给出两种方案的对照数据，因此性能和可靠性收益仍应视为团队经验，不能直接当作普遍结论。

对安全动机，也要区分陈述与证据。Anthropic 将反蒸馏措施主要解释为安全需求，并表示其可观测范围内的相关行为变得更困难。但采访没有给出测量方法和具体降幅，我们能确认的是他们的产品取舍，不能独立判断措施效果有多大。

另一个有意思的例子是 Dreaming：一个 Agent 检查另一个 Agent 过去的工作，再把记忆写回去。它把「记忆」解释成了可实现的工作流，而不是神秘能力。但记忆写错了怎么办、哪些内容应该保留、是否真的改善后续任务，材料都没有展开。文中提到的未来平台能力，也应按计划理解，不能当成已经交付的承诺。

评估是这些讨论的共同落点。早期客户在自己的 harness 中运行任务，能暴露 Anthropic 自有产品覆盖不到的问题；模型也可以辅助生成评估和分析失败，但评估是否贴近用户工作，仍需要人来判断。

至于开头用营收、利润和人效解释公司效率的部分，证据要更谨慎看待。材料中的亏损比例同时出现了 -126% 和 -129%，转录稿也提示可能有误。仅凭这篇材料，无法把财务变化归因于某一项 Agent 架构设计。

能拿来做什么

• 如果你的 Node 服务运行 AI 生成的代码，先检查执行进程能否读取服务密钥，再检查代理究竟允许访问哪些目标、执行哪些操作。把凭证移出沙箱之后，仍要收紧可使用的权限。

• 如果你的 AI 编程任务需要多轮修改和验证，就把会话记录、当前进度与执行环境分开考虑。至少明确沙箱失败后如何接回任务，以及重试会不会重复产生副作用。

• 升级模型或 API 前，用自己已有的编程任务验证完整流程，尤其检查历史消息重放、compaction 和长会话续跑。一次新建会话回答正确，覆盖不了这些兼容性问题。

• 如果准备增加 Agent 记忆，可以先参考 Dreaming 的做法，让另一个 Agent 从历史工作中提炼候选记忆，再检查内容是否准确、后续任务是否受益。先验证记忆质量，再决定是否自动写回。