2026年4月，Anthropic发布了一篇关于托管代理（Managed Agents）架构设计的深度技术文章。这篇文章揭示了一个核心问题：随着模型能力的快速迭代，传统代理框架中的假设会迅速过时。Anthropic给出的解决方案是将代理的"大脑"与"双手"解耦，通过稳定的接口层实现系统的长期演进能力。
01-Harness假设会随模型升级而过时
在构建长周期代理系统时，工程师需要设计harness（控制框架）来协调模型的行为。但harness本质上编码了关于"模型不能独立完成什么"的假设。这些假设会随着模型能力提升而失效。
真实案例：Anthropic在使用Claude Sonnet 4.5时发现，模型会在接近上下文窗口限制时过早结束任务，这种行为被称为"上下文焦虑"。团队通过在harness中添加上下文重置机制来解决这个问题。但当他们使用相同的harness运行Claude Opus 4.5时，发现这种行为已经消失——之前的重置机制变成了无用负担。
这一现象说明，harness需要持续演进。如果将harness与具体实现紧密耦合，每次模型升级都需要重写大量代码。
02-借鉴操作系统的设计哲学
计算机历史上曾面临类似问题：如何为"尚未被构想出的程序"设计系统？操作系统的解决方案是将硬件虚拟化为一组抽象概念——进程、文件。这些抽象足够通用，能够支撑未来几十年出现的各种新程序。
read()命令不关心它访问的是1970年代的磁盘还是现代SSD。上层的抽象保持稳定，下层的实现可以自由变化。
Anthropic将这一思路应用到代理系统中，将代理组件虚拟化为三个核心接口：
会话（Session）：所有发生事件的追加日志，记录代理执行的完整历史。
Harness（控制框架）：调用模型并将工具调用路由到相关基础设施的循环逻辑。
沙箱（Sandbox）：执行环境，模型可以在其中运行代码和编辑文件。
这种设计允许每个组件的实现独立替换，而不影响其他组件。系统关注接口的形态，而非背后的具体实现。
03-不要养宠物，要养牲畜
在基础设施管理中，"宠物"与"牲畜"是一个经典比喻。宠物是有名字、需要精心照料的个体，一旦丢失就无法替代；牲畜是可互换的，任何一头都可以被另一头取代。
Anthropic最初将所有代理组件放在单个容器中，会话、harness和沙箱共享同一个环境。这种方式的好处是文件编辑直接通过系统调用完成，没有服务边界需要设计。但这种紧耦合带来了严重问题：容器变成了"宠物"。
如果容器故障，会话就会丢失。如果容器无响应，工程师必须进入容器内部诊断问题。但由于容器中也包含用户数据，这种调试方式存在安全风险且效率低下。更糟糕的是，当客户希望将代理连接到他们的虚拟私有云时，必须进行网络对等配置，或者在他们自己的环境中运行harness——harness中嵌入的假设成为了扩展的障碍。
04-解耦大脑与双手
解决方案是将"大脑"（模型及其harness）与"双手"（沙箱和执行工具）以及"会话"（事件日志）彻底分离。每个组件都成为独立接口，可以独立故障或替换。
harness离开容器。解耦后，harness不再生活在容器内部，而是像调用其他工具一样调用容器：execute(name, input) → string。容器变成了可互换的"牲畜"。如果容器死亡，harness将其作为工具调用错误捕获并返回给模型。如果模型决定重试，可以通过标准配方重新初始化新容器：provision({resources})。工程师不再需要"护理"故障容器恢复健康。
从harness故障中恢复。harness本身也变成了可互换的。由于会话日志位于harness之外，harness中没有任何内容需要在崩溃后存活。当一个harness失败时，新的harness可以通过wake(sessionId)重启，使用getSession(id)获取事件日志，并从最后一个事件继续执行。在代理循环期间，harness通过emitEvent(id, event)写入会话以保持事件的持久记录。
安全边界。在紧耦合设计中，模型生成的任何不受信任代码都在包含凭证的同一容器中运行——提示注入只需要说服模型读取自己的环境变量即可。一旦攻击者获得这些令牌，就可以生成新的无限制会话并将工作委托给他们。结构性修复是确保令牌永远无法从沙箱中被访问。
Anthropic采用了两种模式来实现这一点。认证可以捆绑在资源中，或保存在沙箱外的保险库中。对于Git，他们使用每个仓库的访问令牌在沙箱初始化期间克隆仓库，并将其连接到本地git远程。沙箱内的push和pull操作无需代理本身处理令牌。对于自定义工具，他们支持MCP协议并将OAuth令牌存储在安全保险库中。模型通过专用代理调用MCP工具；该代理接收与会话关联的令牌，然后从保险库获取相应凭据并向外部服务发出调用。harness永远不会感知到任何凭据的存在。
05-会话不是模型的上下文窗口
长周期任务经常超出模型的上下文窗口长度，标准的解决方法都涉及关于保留内容的不可逆决策。压缩让模型保存上下文窗口的摘要，记忆工具让模型将上下文写入文件，实现跨会话学习。这可以与上下文修剪配对，选择性删除诸如旧工具结果或思考块之类的令牌。
但选择性保留或丢弃上下文的不可逆决策可能导致失败。很难知道未来的步骤需要哪些令牌。如果消息经过压缩步骤转换，harness会从模型的上下文窗口中移除压缩后的消息，只有存储后才能恢复。
在Managed Agents中，会话提供了同样的好处，作为存在于模型上下文窗口之外的上下文对象。但与存储在沙箱或REPL中不同，上下文被持久存储在会话日志中。getEvents()接口允许"大脑"通过选择事件流的位置切片来查询上下文。该接口可以灵活使用，允许大脑从上次停止读取的地方继续，回退到特定时刻之前的事件以查看前因后果，或在特定动作之前重新读取上下文。
任何获取的事件都可以在传递给模型的上下文窗口之前在harness中进行转换。这些转换可以是harness编码的任何内容，包括上下文组织以实现高提示缓存命中率和上下文工程。他们将可恢复上下文存储在会话中，将任意上下文管理放在harness中，因为他们无法预测未来模型需要什么特定的上下文工程。接口将上下文管理推入harness，只保证会话是持久的且可供查询。
06-多脑多手的扩展优势
多脑扩展。解耦大脑与双手解决了早期客户的一个主要抱怨。当团队希望Claude在他们的VPC资源上工作时，唯一的路径是将他们的网络与Anthropic的网络对等，因为包含harness的容器假设每个资源都在旁边。一旦harness不再位于容器中，这个假设就消失了。
这一变化还带来了性能收益。最初将大脑放在容器中意味着多个大脑需要多个容器。对于每个大脑，在容器配置完成之前无法进行推理；每个会话都要预先支付完整的容器设置成本。每个会话，即使是那些永远不会接触沙箱的会话，都必须克隆仓库、启动进程、从服务器获取待处理事件。
这段等待时间体现在首令牌时间（TTFT）中，它衡量会话在接受工作和产生第一个响应令牌之间等待的时间。TTFT是用户最直观感受到的延迟。
解耦后，容器仅在需要时由大脑通过工具调用按需配置。因此不需要立即使用容器的会话不必等待。推理可以在编排层从会话日志中提取待处理事件后立即开始。使用这种架构，p50 TTFT下降了约60%，p95下降了超过90%。扩展到多个大脑只需启动多个无状态harness，并在需要时将它们连接到双手。
多手扩展。Anthropic还希望将每个大脑连接到多个双手。在实践中，这意味着Claude必须推理多个执行环境并决定将工作发送到哪里——这比在单个shell中操作更难。他们最初将大脑放在单个容器中，因为早期模型不具备这种能力。随着智能水平的提升，单个容器反而成为了限制：当该容器失败时，他们会失去大脑正在接触的每只手的状态。
解耦后，每只手都成为一个工具：execute(name, input) → string。名称和输入进入，字符串返回。该接口支持任何自定义工具、任何MCP服务器和他们自己的工具。harness不知道沙箱是容器、手机还是模拟器。由于没有手与任何大脑耦合，大脑可以相互传递手。
总结
Anthropic的Managed Agents架构展示了一个深刻的工程洞见：在快速变化的技术环境中，稳定的接口比具体的实现更重要。通过将代理系统分解为会话、harness和沙箱三个独立组件，并通过清晰的接口连接它们，系统获得了应对模型升级、安全需求变化和扩展压力挑战的能力。
这种"解耦大脑与双手"的设计哲学不仅适用于代理系统，也为其他需要长期演进的复杂软件系统提供了参考。关键不在于预测未来需要什么，而在于设计出能够容纳未知变化的接口层。
原文链接：
扫一扫
246
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
