当模型开始连续工作：Anthropic为什么要为 Agent 造一层“操作系统”

信源：[Kleiner Perkins｜Katelyn Lesse、Angela Jiang（Anthropic）访谈｜2026-08-25]

过去一年，Agent 最重要的变化并不是回答更聪明了，而是模型能够连续工作的时间变长了。

对于聊天机器人，一次回答失败，用户重新提问就可以了。可当 Agent 开始执行持续几十分钟甚至数小时的任务，失败的含义完全不同：它可能丢失工作状态、留下半成品、重复执行操作、误用凭证，或者在错误路径上持续消耗 token。

模型工作时间越长，AI 产品就越不像一个对话框，越像一个需要持久运行的生产系统。

这也是这场访谈透露出的核心变化：Agent 竞争正在从模型能力，延伸到一套类似操作系统的运行层。这里所说的“Agent 操作系统”，不是一个新的模型，而是一组负责持久状态、任务调度、隔离执行、错误恢复、权限控制和审计追踪的基础设施。模型负责判断，运行层负责让这个判断能够安全、连续地转化为行动。

Anthropic 最初也走过一条看似自然的路线：把模型、Agent harness 和执行环境全部塞进同一个容器。harness 本质上是一个循环——接收输入、调用模型、执行工具，再把结果送回模型。短任务这样做足够简单，但在长任务中，容器一旦宕机，模型的工作状态、工具环境和会话可能一起消失。

Managed Agents 后来的架构选择，是把“脑”“手”和“记忆”拆开。

“脑”是模型与 harness；“手”是运行代码、编辑文件或调用外部系统的 sandbox；“记忆”则是一份独立于两者的持久化 session log。sandbox 挂掉，可以重新创建；harness 挂掉，可以读取日志并从最后一个事件恢复；敏感凭证保存在 sandbox 之外的 vault 中，通过代理完成调用，模型生成的代码接触不到原始 token。

这不只是容错优化。Anthropic 披露，解耦之后，其 Managed Agents 的首 token 延迟中位数下降约60%，P95下降超过90%。更重要的是，执行环境从必须长期照料的“宠物”，变成了随时可以替换的基础资源。[这套架构]使长时间运行的 Agent 第一次具备了接近云原生服务的故障恢复方式。

其中一个容易被忽略的设计是：session 不等于模型的上下文窗口。

上下文窗口只是模型当前能够看到的工作区，长任务迟早会遇到容量限制。压缩、摘要和删除旧工具结果都意味着不可逆的信息取舍，而系统很难提前知道后续步骤会重新需要哪段信息。Anthropic 的做法，是把完整事件流保存在上下文窗口之外，模型只按需读取其中的切片。

这意味着，未来 Agent 的“记忆”未必依赖无限扩大的上下文，而更可能由持久日志、工作记忆和按需检索共同组成。模型负责决定此刻需要什么，系统负责确保历史仍然存在。

当这些基础设施被平台化之后，价值开始向更高一层迁移。

Angela Jiang 在访谈中反复强调，开发者不应该重新实现无差异的 sandbox、状态管理和错误恢复，而应该把精力放在客户、领域知识和任务策略上。但这并不代表所有 Agent 最终都会使用同一种 harness。Anthropic 的判断恰恰是：底层运行机制可以标准化，如何组合模型、工具、记忆、评分器和升级路径，仍然高度依赖具体任务。

这也解释了访谈里一个很有意思的说法：token 不再是同质化商品，而是可以被分配不同“岗位”。

一部分 token 负责执行，一部分负责规划，一部分负责检查结果，还有一部分负责从历史任务中整理记忆。低成本模型可以承担大量机械操作，在遇到困难时再调用更强模型作为 advisor；执行 Agent 完成任务后，另一个 Agent 根据 rubric 评分，不合格就要求重做；“Dreams”机制则从历史会话中合并重复记忆、淘汰过时信息并提炼新的经验。这些能力已经陆续进入 Claude Platform 的公开测试。[Anthropic 的更新记录]显示，Advisor、Outcomes、Memory 和 Dreams 均已成为独立平台能力。

因此，衡量 Agent 成本不能只看每百万 token 的价格，而要看完成一个正确结果需要多少总成本。一个更贵的模型如果能够减少返工、缩短路径，反而可能更便宜。

不过，访谈对此给出的说法比公开证据更激进。Katelyn Lesse 提到，内部评测中“Sonnet 执行、Opus 提供建议”可以接近 Opus 的效果，成本甚至低于单独使用 Sonnet。Anthropic 目前公开文档支持的是更谨慎的版本：在部分编码任务中，中等 effort 的 Sonnet 配合 Opus advisor，可以用更低成本达到接近默认 effort Sonnet 的能力，而且结果取决于具体 workload。[官方文档]尚不足以证明这一策略在所有任务上都能接近 Opus。

基础设施改变之后，企业内部的瓶颈也会跟着迁移。

访谈中，两位负责人认为，企业常见的错误是把 Agent 塞进原有的人类流程：看到哪个环节人工效率低，就直接用 Agent 替换那个人。但许多流程原本就是由历史政策、人工交接和组织边界拼凑出来的。让 Agent 完全模仿人类执行，等于把旧流程的摩擦一并保留下来。

更有效的方法，是从最终结果重新设计流程：把任务拆成可以独立完成和自我验证的单元，明确什么叫“完成”，只在异常情况下升级给人类。Agent 带来的不只是自动化某个步骤，而是删除一部分原有步骤的可能性。

Anthropic 约200人的平台团队提供了一个内部案例。访谈中，Katelyn Lesse 提到，过去留给产品经理和技术负责人进行协调的时间，正在被工程执行速度压缩：以前需要两周的开发工作，现在可能两天就完成了，需求对齐和组织决策反而来不及跟上。Angela Jiang因此认为，产品经理不得不回到更纯粹也更困难的工作——选择问题、提出假设、判断客户需要什么，以及决定哪些赌注值得下注。

AI 并没有消灭管理和产品判断。它只是压低了执行成本，从而提高了错误决策的代价。

Managed Agents 仍有一个不可忽略的边界。访谈中关于“Anthropic 不使用客户数据训练模型”的回答，对商业产品默认政策而言是准确的；但“不用于训练”不等于“不被保留”。根据 Anthropic 当前规则，Managed Agents 是有状态服务，会话记录会一直保存到客户主动删除，而且目前不适用零数据保留协议。[官方数据规则]明确区分了模型训练与数据留存。对于金融、医疗和其他受监管行业，这可能比模型能力更早成为部署限制。

因此，下一阶段 Agent 平台的核心指标，不会只是上下文长度、benchmark 分数或 token 单价，而是：在固定成本和权限边界内，一个 Agent 能够连续工作多久，正确完成多少端到端任务，需要多少次人工介入，并且在故障后能否可靠恢复。

如果长任务仍然需要人类逐步监督，或者企业无法接受其状态与数据保留方式，那么“Agent 操作系统”只能服务有限场景。反过来，如果无人值守任务成功率持续提高，Anthropic、OpenAI等模型公司争夺的就不再只是智能入口，而是数字化工作真正运行其上的系统层。