AI Agent 长任务中断、状态丢失、context 超限怎么办？拆解 Anthropic Managed Agents 的架构设计
159 views
Anthropic 最近发布了一篇工程博客，讲他们怎么重新设计 Agent 的底层架构。表面上是一篇基础设施文章，但背后的设计思路值得仔细看。
DataLearner WeChat
Follow DataLearner WeChat for the latest AI updates
Anthropic 最近发布了一篇工程博客，讲他们怎么重新设计 Agent 的底层架构。表面上是一篇基础设施文章，但背后的设计思路值得仔细看。
Follow DataLearner WeChat for the latest AI updates
做 Agent 开发的人都遇到过这种情况：模型有某个行为问题，于是在框架层面加一段逻辑来绕过它。问题解决了，但这段逻辑就永远留在代码里了。
Anthropic 自己也遇到了这件事。他们发现 Claude Sonnet 4.5 在 context 快满的时候会提前放弃任务，表现得像是"时间不多了，赶紧收尾"——他们把这个现象叫做 context anxiety（上下文焦虑）。解决方案是在 harness 里加入 context reset 的逻辑，每隔一段就重置一次。
后来他们把同一套 harness 用在 Claude Opus 4.5 上，发现这个行为消失了。模型能力提升之后，context anxiety 不再出现，而那段 reset 逻辑就变成了没有意义的死代码。
这个例子说明一个更普遍的问题：架构里的每一个设计决定，本质上都是一个关于"模型不能做什么"的假设。模型在进化，假设会过期，但代码不会自动失效。
Anthropic 的应对思路是：与其不断打补丁，不如重新设计架构，让接口足够稳定，能撑过任意一代模型的变化。这套架构就是他们现在推出的 Managed Agents。
Anthropic 最初的实现很直接：把 Agent 运行需要的一切——调度逻辑、执行环境、会话记录——全部放进一个容器里。好处是简单，文件读写就是系统调用，不需要跨服务通信。
问题在于，这个容器承担了太多职责，变成了一个"动不了的个体"。一旦容器崩溃，整个会话就丢了，没有办法恢复。如果容器卡死，工程师只能进去手动排查，但容器里同时还跑着用户数据，这让调试变成一件既繁琐又有安全风险的事。
更深层的问题是，这个设计把"Claude 的执行环境必须和 harness 在一起"这个假设硬编码进了架构。当企业客户希望把 Claude 接到自己私有云里的资源时，唯一的选择是把自己的网络和 Anthropic 的网络打通，或者自己部署整套 harness。一个隐含假设，变成了扩展性的障碍。
解决方案是把三个部分拆开：
三者之间只通过简单的接口通信。Hands 对外暴露的接口就是 execute(name, input) → string，大脑不需要知道手是一个容器、一台手机还是别的什么，只需要传入指令和参数，拿回结果。
这个拆分带来了两个直接好处。
第一个是可靠性。 沙盒容器挂了，harness 只是收到一个工具调用失败的错误，可以决定是否重试，重新起一个新容器继续执行。Session 日志放在外部，harness 自己崩了也无所谓——重启一个新的 harness，读取 session 日志，从上次停的地方继续，没有任何状态丢失。每个组件都可以独立失败、独立重启。
第二个是性能。 原来的设计里，每个 Agent 会话启动时必须先把容器跑起来，才能开始推理。现在容器是按需启动的——如果一个会话暂时不需要执行代码，就不用等容器。推理可以在调度层拿到 session 日志之后立刻开始。这一个改动让首 token 延迟的 p50 降了约 60%，p95 降了 90% 以上。
这部分稍微解释得细一点，因为涉及的安全逻辑不是一眼就能看明白的。
在原来耦合的设计里，Claude 生成的代码和各种 API token、访问凭证都在同一个容器里。这意味着如果 Claude 被 prompt injection 攻击——比如被恶意内容诱导执行了一段读取环境变量的代码——攻击者就能拿到容器里的所有 token，然后用这些 token 发起新的、不受控制的请求。
新架构的结构性解法是：让沙盒里运行的代码从物理上就拿不到任何凭证。
以 Git 为例。Claude 需要能够 push 和 pull 代码，但不需要"知道"用什么 token 在做这件事。Anthropic 的做法是：在沙盒初始化阶段，用仓库的 access token 完成 clone，并把 token 配置进本地 git 的 remote 设置里。之后 Claude 在沙盒里执行 git push 或 git pull，git 工具自己处理认证，Claude 生成的代码全程接触不到那个 token 本身。这就是"把 token wire 进去"的意思——token 在初始化环节就被嵌入工具配置，而不是作为一个变量暴露在运行环境里。
对于其他外部服务，Anthropic 用了 MCP proxy 的方式：OAuth token 存在 harness 外部的安全 vault 里，Claude 调用外部工具时请求先到 proxy，proxy 凭 session 标识从 vault 取出对应凭证，再转发到外部服务。Claude 的沙盒环境和 harness 都不持有这些凭证。
结果就是，即便沙盒里的代码被劫持，攻击者也没有任何凭证可以拿走。安全保证不依赖"相信模型不会被骗"，而是靠结构隔离实现的。
Agent 处理长任务时，很快会遇到 context 长度的上限。常见的处理方式是 compaction——让模型把当前 context 总结成一段摘要，用摘要替换原始内容，释放空间。问题在于这是一个不可逆的操作，原始信息一旦压缩就找不回来了，而且很难提前判断哪些细节在后续步骤里还会用到。
Managed Agents 的 session 设计从根本上解决了这个问题。Session 是一个完整保存在外部的事件流，而 context window 只是这个事件流的一个视图。
具体来说，harness 可以调用 getEvents() 从 session 里取任意位置的事件片段，然后决定把哪些内容放进 Claude 的 context window。可以只取最近的 N 条事件，可以重新读取某个关键决策之前的上下文，也可以在某个特定动作之前往前多看几条做参照。
这和传统 compaction 的本质区别在于：对 context window 里内容的操作是可逆的。压缩、裁剪、重组，都是 harness 在"视图"层面做的选择，原始数据始终完整地保存在 session 里。出了问题可以回溯，未来换了新的 context 管理策略也不需要迁移数据。
Anthropic 用了一个操作系统的类比来说明这套设计的目标。Unix 的 read() 系统调用，从 1970 年代的磁盘时代用到今天的 NVMe，接口从来没变过，变的只是底层实现。应用程序不需要关心存储介质是什么。
Managed Agents 想做的是同样的事情。Session、harness、sandbox 三个抽象定义好接口，背后跑什么实现是可以随时替换的。Claude Code 是一种 harness，任务特化的 harness 也能接进来，将来还没出现的 harness 同样可以。架构不对任何特定的实现下注，只对接口的形状下注。
对做 Agent 应用的人来说，这个思路有一个很直接的启示：不要把对当前模型能力的 workaround 写死进架构，而是定期问自己，哪些设计决定本质上是对模型局限性的假设，这些假设现在还成立吗。