Agent Harness：Managed agent

长周期智能体 Anthropic《Scaling Managed Agents: Decoupling the brain from the hands》

本文中的harness专指直接调用 LLM、并分发 tool call 的控制循环，而不是广义的harness系统层

Harness sandbox session解耦，进行many brain，many hands以及cattle随用随起的设计

核心方案

原方案：把harness + sandbox + session 都放在一个container里运行

• 缺点：container不能挂 挂了就没有session了，而且故障难以排查（因为container里有用户数据，debug登进container破坏了安全性）

新方案：把brain（harness大模型调用循环）与 hands（sandboxes/tools执行）以及session（log记忆日志）分开

将harness单独变成一个纯协调层，要像调用工具一样去调用某个执行环境；同时将harness本身变成了cattle（随用随丢的东西）：只需新起一个空harness然后getSession读回完整的事件流即可，保证没有任何状态必须依赖某一台正在运行的 harness 实例才能保留。

沙箱-安全控制

Auth和资源打包放在一起：以git为例

• 沙箱初始化阶段，系统拿着该仓库的 access token 把它 clone 好；
• git remote 已经配置完成；
• 接下来在沙箱内执行 git push、git pull 完全正常；
• 但是 agent/claude 从来没有触碰过这个 token

OAuth Token放在Vault，用proxy转发：确保harness全程不知道真实token是什么

• 将oauth token放在安全的vault
• agent通过专门的proxy发起mcp tool call
• proxy拿到本次session的一个临时标识，再从vault中拿到真实的token并向外部服务发送实际请求

长周期任务处理

长周期任务常常超过上下文窗口，常见的应对手段有：

• 压缩摘要；memory tool（主动写记忆）；上下文移除（选择性删掉一些tool result）

缺点是：每一次都很难决定到底要保存什么东西，因为无法预测日后需要用到哪段历史记忆

Managed agent做法：让 session 日志成为一个位于 LLM 上下文窗口之外的大型 context object，从这个session日志中拉出来的raw events，还可以由harness决定怎么做变换（比如应用不同的上下文工程策略）

• 分层抽象，session只保证durability以及availability；把具体的context engineering交给harnss，这样如果未来出现更先进的长上下文技术时，只需要改变harness

多脑多手

Many brains：更低的首次输出延迟TTFT(Time-To-First-Token 用户发起请求后到看到第一个生成字符之间的时长）

• 原本harness sandbox session一体化，那么即使当前对话暂时不需要用到沙箱，也必须部署好，严重拖慢时间
  • 解耦之后：只在brain真正需要时才分配出container，不需要等沙箱就绪就能从session中拉取pending events

Many Hands：一个brain可以调用多个hands，harness与这些hands完全解耦