#ai产业链#

Anthropic 的下一场竞争：把模型能力变成可托管的工作

信源：Latent Space｜Katelyn Lesse、Angela Jiang 谈 Claude Platform 与智能体工程｜2026-10-27。

一家前沿模型公司，为什么会为 CPU 不够用而发愁？

在 Latent Space 对 Anthropic 的访谈中，这个细节比“全球第一模型”的标题更值得追问。按照嘉宾的描述，CPU 要同时支撑 API、产品服务、智能体沙箱，以及代码提交后不断触发的自动化构建和测试。过去只要预算允许就能临时扩容的资源，现在也需要提前规划容量。

这揭示了智能体与聊天机器人的一个根本差别：聊天主要消耗生成答案的算力；智能体还会把答案变成代码、工具调用、文件修改和持续运行的任务。模型越能干，周围需要承接的执行活动就越多。

Anthropic 正在沿着这条因果链扩展自己的业务边界：从交付一次模型响应，延伸到交付一段可以持续、恢复、授权和验证的工作过程。 Claude Managed Agents 的意义就在这里。客户把更多运行责任交给平台，平台负责吸收模型更新和底层系统变化带来的复杂性。

理解这个变化，可以先看 Anthropic 如何改造自己的系统。

嘉宾披露，团队把 Messages API 从 Python 单体实现迁移到了 Rust。项目启动时，参与团队甚至没有现成的 Rust 开发者配置，Claude 承担了大量代码实现；人类工程师负责系统设计、迁移计划和验证，过程中也补充了有 Rust 经验的人。迁移带来的 CPU 节省，据其估算约为 40%—50%，首 token 延迟改善约为 10%—20%。

这些数字对应的是 API 服务迁移，不能读成训练成本下降一半，也不能外推为整家公司推理成本同比例下降。它们的价值在于说明：当模型服务规模扩大，传统软件层的效率也会成为交付智能的约束。

更有意思的是项目的做法。团队先建立一套完整的 Rust 实现，再用影子流量比较新旧系统的行为，最后逐步切换。迁移期间，他们刻意压住顺手增加新功能的冲动。否则，新系统的差异究竟来自迁移错误还是功能变化，就很难判断。

这比“AI 会写 Rust”更能解释生产率提升。旧系统提供了一个可比较的行为基准，影子流量提供了验证渠道，明确的范围控制又减少了变量。代码生成成本下降以后，过去因为实施周期太长而不值得推进的迁移，开始进入可执行范围。前提是工程团队知道怎样判断迁移是否成功。

这里出现了一个具体的反馈回路：模型帮助改进承载自身的基础设施，基础设施效率提升，又能释放更多服务容量。但这个回路并不会自动无限加速。API 迁移可以借助旧系统做参照，开放式研究、复杂产品设计和新业务探索，往往没有这样清晰的答案。能否建立有效的验证方法，决定了模型能力有多少能转化成实际产出。

同样的约束也出现在智能体架构中。

Anthropic 最初尝试过一种很直接的方案：把 Claude Code 放进沙箱，再在外面包一层 API。它容易理解，也便于快速做出原型。然而，用户必须等沙箱和程序启动后才能得到响应；沙箱一旦出问题，执行程序、会话状态和任务进度又可能一起受到影响。一个本应可以随时替换的计算环境，变成了不能轻易丢失的工作现场。

后来，他们把系统拆开：模型和负责调度工具的 harness 构成“大脑”，沙箱及工具构成“手”，会话记录则独立保存。这里的 harness，可以理解为围绕模型运转的程序：组织上下文、调用模型、分派工具，再把执行结果送回来。

这个拆分改变了故障的含义。沙箱失效，首先表现为一次工具调用失败，不再必然意味着整个智能体消失；负责调度的程序失效，也有机会根据持久化记录恢复工作。可靠性来自状态和执行环境之间更清楚的边界。Anthropic 的架构文章也明确将会话、harness 和沙箱设计为可分别替换的组件。

当然，保存会话不等于所有操作都能无损恢复。临时文件是否保存、一次外部写入有没有完成、重试会不会重复扣款，仍然需要各自的恢复和去重机制。架构拆分解决的是让任务不再被某一个容器绑死，而不是让失败从此不发生。

它也改变了资源配置方式。模型在思考、等待外部结果或仅调用远程工具时，不必始终占着一套完整的代码执行环境；需要执行代码时再启动相应资源，才能更灵活地利用紧张的 CPU 容量。访谈没有披露这种拆分节省了多少资源，但它解释了为什么延迟、可靠性和成本会共同推动同一种架构选择。

安全收益则让这套设计变得更重要。

在传统做法里，智能体需要访问外部服务，就可能把密钥放进运行环境。问题是，模型生成的代码也在同一个环境中运行。一旦受到恶意内容诱导，智能体就可能读取本不该暴露的凭据。

Anthropic 描述的方案，是把凭据保存在独立的密钥库中，智能体侧只接触占位符或受控调用接口，由代理在访问外部服务时注入相应凭据，再配合网络出口限制。这样，执行环境获得的是受约束的操作能力，不必获得原始密钥。

这个差别不能夸大成“智能体绝对安全”。看不到密钥，仍可能错误地使用一个已经获准调用的工具；允许访问某个域名，也不意味着发往该域名的每条请求都符合用户意图。Anthropic 自己的安全文章也强调，模型、环境和外部内容需要多层防护，风险不会被单一措施清零。

但方向非常清楚：如果每一步都要由人确认，智能体很难长时间自主工作。更明确的环境边界，可以让一部分低风险动作无需反复审批。安全工程因此直接影响可交付的自动化程度。 企业敢给多少权限、允许跑多久、愿意接入哪些系统，都与失败后果能否被限制有关。

这也解释了嘉宾为何反复强调，发布模型已经包含大量模型之外的工作。

他们谈到的发布流程，既有能力评估和客户试用，也有在线防护、离线审查，以及贯穿系统的授权机制。某个客户可以访问什么模型、使用哪些特殊能力、是否拥有迁移宽限期，都需要在请求经过各层服务时得到一致执行。把权限当成一个简单开关，随着产品和例外情形增加，很快就会失去可管理性。

防蒸馏措施提供了另一个例子。嘉宾介绍，为减少推理轨迹被提取的风险，平台强化了对思考内容跨轮保留的要求。但开发者原本可能自行压缩上下文，这种变化会破坏他们的实现。于是 Anthropic 又提供兼容新要求的压缩能力，并与客户及开源维护者协调迁移。

对开发者而言，接入模型以后，维护工作并没有结束。模型行为会变，推理参数会变，安全规则和上下文管理方式也会变。这些变化有时还相互牵连。托管平台能够出售的价值，正是替客户持续处理其中可以共用的部分。

不过，共用基础设施与共用行为策略之间，存在一道重要边界。

访谈明确提到，Managed Agents 与第一方产品可以共享沙箱等底层设施，却不必共享完全相同的 harness。这种安排很合理：代码开发、资料研究和企业流程可以使用同类执行环境，但“何时继续探索、何时停止、何时询问用户”的最佳策略并不相同。

嘉宾举了一个非常日常的矛盾：有的用户抱怨模型太懒，没有把任务做完；有的用户则只是想讨论方案，模型却已经修改了一堆代码。同一种主动性，在两种场景里会得到相反评价。于是，“模型更强”很难直接等价于“产品更好用”。

这使客户评测具有双重作用。一方面，它帮助客户选择适合自己任务的配置；另一方面，外部客户把 Claude 放进不同的 harness，可以暴露第一方产品内部试用没有发现的问题。模型、运行策略和工作环境必须放在一起评估，单独看模型榜单不足以决定一个业务系统的表现。

访谈后段关于路由的讨论，又把问题推进了一步。面对一项任务，系统未必从开头就知道它有多难，也未必知道执行中会遇到什么信息。起初像简单查找的工作，可能在深入之后变成复杂判断。一次性选定便宜模型或昂贵模型，容易过早作出决定。

Angela Jiang 因而更看好一种较统一的体验：随着任务信息展开，动态调整投入的推理努力，尽量减少频繁更换模型带来的行为断裂。这是她提出的方向，不能当成已经解决的问题。它说明，未来平台需要管理的不仅是“调用哪一个模型”，还包括“在什么时候，为这项工作投入多少计算”。

多智能体让这个资源管理问题更加突出。嘉宾建议，适合拆分的工作可以由一个主智能体协调，子任务异步推进，并共享必要的上下文。并行化能够缩短等待，但也会增加模型调用、沙箱和协调负担。任务之间依赖越强，合并结果的成本就越高；增加智能体数量，本身并不能保证产出改善。

访谈中的 dreaming 也应放在这个层面理解：另一个智能体回看已有过程，提炼并写入记忆，帮助后续工作。它属于运行系统中的经验整理，不等于模型权重在后台自动升级。整理出来的记忆是否正确、是否适用于下一个任务，依旧需要检验。

因此，托管平台的竞争力将越来越取决于一件具体的事：能否用合适的状态管理、权限边界和计算分配，让同一份模型能力完成更多有效工作。

对应用开发者来说，这个变化意味着基础设施负担可能下降，同时也需要重新选择自己要掌握的部分。通用的会话恢复、凭据管理和沙箱维护适合交给平台；行业里的成功标准、关键例外和业务责任，则很难一并外包。平台可以保证任务继续运行，却不能仅凭通用能力知道，一份供应链决策或工程报告是否足以让客户采取行动。

这种分工也给 Anthropic 留下了机会与约束。客户使用托管会话、记忆和授权机制越深，迁移时需要处理的内容就越多，平台关系可能比单纯的 token 采购更稳固。但客户也会在意可移植性、多模型选择和基础设施控制权。更强的模型能吸引试用，要让客户长期交出运行责任，还需要持续证明可靠性、透明度和总成本优势。

访谈结尾谈到 AI 生成的低质量文档时，嘉宾的态度与前面的工程选择其实一致：可以充分使用 Claude，但提交者仍然要为质量负责。自己不检查就把生成结果交给同事，只是把审阅成本转移给别人。

这也应成为衡量整套智能体平台的标准。多生成多少代码、多调用多少工具，都不能单独证明生产率提升。更有意义的问题是：完成同样一项合格工作，需要多少计算、多少等待，以及多少次人的介入。

当模型越来越擅长执行，下一轮竞争会围绕这些指标展开。Anthropic 能否把模型优势延伸为平台优势，要看它能否让客户把任务交出去之后，少花时间照看过程，仍然拿回可以负责的结果。