Anthropic 2026 最新 Agent Harness 架构完整拆解：Managed Agents
🙋我是 Luhui Dev，一个长期拆解 Agent 工程、探索 AI 教育落地的开发者。关注 Agent Harness、LLM 应用工程、AI for Math 与教育 SaaS 产品化实践。
前言
Anthropic 最近几篇关于 Agent Harness 的技术博客很值得关注，把 Agent 工程从怎么写一个更聪明的循环，推进到了怎么设计一个能进生产的运行时。
这篇文章分享关于 Agent Harness 的最新实践：Session、Harness、Sandbox、Credential、Tool Protocol、Context Builder、Trace、Eval。
这几年的思路变化
Anthropic 的 Agent Harness 思路不是突然变成 Runtime 的。过去几年，它的重心变过几次。
阶段一：长上下文被当成主要抓手
早期 Anthropic 很强调 long context。
100K、200K context window 的出现，让 Claude 可以读更多文档、承载更长对话、处理更复杂材料。那时很多问题还被理解为 prompt engineering：怎么把信息放进去，怎么让模型在长上下文里找到正确内容，怎么减少遗漏。
这个阶段的判断可以理解。模型上下文突然变长，大家自然会把任务状态、文档、历史对话都往里面放。
但后来的 Agent 实践证明，长上下文只是工作区变大了，不等于系统有了可靠记忆。
上下文窗口再长，也还是一次模型调用能看到的 token。它会变贵，会退化，会被压缩，也会被无关信息污染。
阶段二：Agent 被拆成 workflow 和 autonomous loop
到《Building Effective AI Agents》阶段，Anthropic 开始把 workflow 和 agent 区分开。
workflow 是流程明确、路径可控的系统。模型在某些节点做判断。
agent 是开放式循环。模型自己规划、调用工具、观察结果、继续行动。
这个区分很实用，很多产品并不需要高自治 Agent。
稳定业务流程用 workflow 更便宜、更稳、更容易调试。硬上 Agent，往往只是把可控流程做成不可控黑盒。
这一阶段 Anthropic 的思路是先用简单结构，只有任务真的需要开放式决策时，再引入更高自治能力。
这句话现在依然适用。
阶段三：工具、上下文、安全开始成为主战场
2025 年之后，Anthropic 的分享明显转向工程细节。
think tool 解决复杂工具调用里的思考空间。
multi-agent research system 解决复杂研究任务里的并行搜索和分工。
context engineering 解决上下文选择、压缩、裁剪、动态加载。
Agent Skills 解决领域程序性知识的按需加载。
Claude Code sandboxing 解决代码执行、文件系统、网络和凭证边界。
MCP、code execution with MCP、advanced tool use 解决工具连接、工具发现、工具定义膨胀和中间结果污染上下文。
这些看起来主题分散，其实都在指向同一个问题：
Agent 一旦开始做真实工作，问题会从模型会不会回答转向系统怎么承载模型行动。
工具太多，上下文会爆。
任务太长，聊天记录不够用。
执行太自由，安全边界会失控。
多 Agent 太积极，成本和协调复杂度会压上来。
模型升级太快，旧 harness 假设会过期。
阶段四：把问题抬到 Runtime 层
到了最近的 Managed Agents，Anthropic 不再只讨论某种 harness 怎么写，而是在讨论 Agent Runtime 的稳定接口。
它把系统拆成 Session、Harness、Sandbox。
把 Claude + harness 称为 brain，把 sandbox 和执行环境称为 hands。
把 session 放在上下文窗口之外。
把凭证挡在 sandbox 外面。
它让执行环境可以失败、替换、重建。
这就是 Anthropic 这几年思路变化的主线：
长上下文 → 工具循环 → 上下文工程 → 安全执行 → 可恢复运行时Managed Agents 的核心逻辑：接口要稳定，策略可以换
Managed Agents 的核心逻辑就一句话：不要把会变化的东西绑死在一起。
模型会变，Harness 策略会变，工具会变，Sandbox 形态会变，上下文策略会变，客户部署环境会变。安全要求也会变。
如果这些东西都塞进一个容器、一个 loop、一个 prompt 体系里，系统很快会变成难以替换的工程包袱。
Harnesses encode assumptions that go stale as models improve.
Harness 会编码当前模型的弱点。模型不会长任务规划，就加 planner。模型容易漏检，就加 evaluator。模型上下文快满了容易提前收尾，就加 context reset。模型工具调用不稳，就加复杂 retry。
这些策略在某一代模型上可能有效。模型一升级，它们可能变成额外成本。
Anthropic 举了一个具体的例子：Claude Sonnet 4.5 在接近上下文窗口上限时容易提前结束任务，所以 harness 加了 context reset。到了 Claude Opus 4.5，这个行为消失了，原来的 reset 逻辑就开始显得多余。
这个例子说明一件事：
不要把今天模型的缺陷，写成明天系统的架构。
Managed Agents 沉淀的核心接口大致是：
Session：任务发生过什么 Harness：下一步怎么调度 Sandbox：动作在哪里执行 Tool interface：动作如何被调用 Credential boundary：动作是否被授权 Context builder：这次模型该看什么 Trace / Eval：过程和结果如何被复盘这套设计不追求某一个固定 Agent loop 的优雅。
它追求的是当模型、工具、执行环境变化时，系统还能继续演进。
这是 Managed Agents 真正值得学的地方。
关键点一：Brain / Hands 解耦
Managed Agents 里最关键的一刀，是把 brain 和 hands 拆开。
Brain 是 Claude + harness。
Hands 是 sandbox、MCP server、外部工具、设备、浏览器、代码执行环境。
早期做法往往是把 brain 放进 hands 里面。也就是一个容器里跑 harness、存 session、执行工具、放文件系统，有时还放凭证。
但进入生产，它会制造一个典型问题：容器变成 pet server。
它不能轻易丢、不能轻易重启，挂了要救、调试要进去看。
用户数据、执行状态、工具调用、凭证边界全混在一起。
Anthropic 后来的做法是让 harness 离开 sandbox。Harness 成为相对无状态的控制面，sandbox 变成可调用、可重建的执行资源。
二者之间通过一个简单接口连接：
execute(name, input) -> string这个接口让 Harness 不必知道对面是容器、远程服务、MCP server，还是某个客户 VPC 内的工具环境。它只知道调用动作，拿回结果。
这样一来，系统得到几个直接收益：
- Sandbox 挂了，不等于任务死了
- Brain 可以先工作，sandbox 后加载
- 一个 brain 可以调多个 hands
关键点二：Session 的设计
Managed Agents 里另一个关键判断是：
Session is not Claude’s context window.
很多 Agent 系统会把 session、聊天记录、memory、上下文窗口混在一起。短任务还能撑，长任务很容易乱。
上下文窗口只是模型这一次推理能看到的 token，它是工作区。
Session 应该是任务发生过的持久记录，它更像 event log。
一个靠谱的 session 至少应该记录：
user_input model_response tool_call tool_result file_change error retry approval checkpointHarness 每次调用模型时，再从 session 中选择当前需要的部分，构造成模型上下文。
这个分工非常关键，Prompt 是工作区，Session 是账本。
工作区可以整理、压缩、裁剪、重组；账本要尽量完整、可查、可恢复。如果把所有历史都塞进上下文，成本会爆，模型也会被噪音拖累。如果只靠摘要，摘要漏掉的细节可能在后面变成关键错误。
所以更稳的结构是：
原始事件长期保存 ↓ Context Builder 动态选择 ↓ 当前模型调用看到一个高信号上下文这也是 context engineering 和 durable state 的分界线。
Context engineering 负责这次模型该看什么。
Session event log 负责系统到底发生过什么。
长任务 Agent 如果没有这一层，后面做 resume、trace、eval、debug 都会很难。
关键点三：Sandbox 的设计
Sandbox 在 Agent 系统里经常被低估。
很多团队一开始只是给 Agent 一个 shell，能跑命令、能读文件、能改代码，就觉得够了。
这在 demo 阶段没问题；生产里，sandbox 是安全边界，也是执行边界，还是成本和延迟来源。
Anthropic 在 Claude Code sandboxing 和 Managed Agents 里强调了几个方向：
- Sandbox 要隔离文件系统和网络。模型生成代码必须按不可信代码处理，sandbox 需要限制文件系统访问范围，也要限制网络访问范围。否则 prompt injection 可以诱导 Agent 读不该读的文件，访问不该访问的服务，把结果带出去。
- Sandbox 不该直接持有长期凭证。只要 sandbox 里有 GitHub token、数据库 key、云服务密钥，Agent 就有机会被诱导读取它们。
- Sandbox 要能重建和恢复。长任务 Agent 一定会遇到失败，如果 sandbox 和 session 绑定太死，失败就会拖垮任务。更好的做法是让 sandbox 可重建，可恢复，必要时支持 snapshot / resume。这也是 Brain / Hands 解耦的延伸。
总结：2026 Anthropic Agent Harness 架构图
把 Anthropic 2026 年的思路合在一起，可以抽象成下面这张图：
这张图的重点在每个模块的责任边界。
Harness 是控制面，负责调度模型、上下文、工具、策略。
Session event log 是持久状态，不跟某个容器绑定。
Context Builder从 session、memory、skills、工具结果里组装高信号上下文。
Tool Router 负责把动作分发给 MCP、代码执行环境、sandbox 或其他 hand。
Sandbox 负责执行动作，可以失败，可以重建。
Credential Proxy / Vault 管住凭证，不让不可信执行环境直接拿 token。
Trace / Eval贯穿整个 run，让系统能复盘、回归、对比 harness 改动。
研究型 Harness 和生产型 Harness 的区别
很多 Agent demo 看起来很强，进入生产之后变得笨重、昂贵、难调。
原因是研究型 harness 和生产型 harness 的目标不同。
研究型 harness 追求能力上限。它可以多花 token，多开 subagent，多加 evaluator，多试几轮。任务成功率上去，就算实验有价值。
生产型 harness 追求稳定收益。它要算成本，要看延迟，要控权限，要可恢复，要能观察，要能灰度，要能回滚。
| 维度 | 研究型 Harness | 生产型 Harness |
|---|---|---|
| 目标 | 拉高任务成功率上限 | 在成本、延迟、安全约束下稳定交付 |
| 状态 | transcript、本地文件、临时 progress file | 外部 session log、checkpoint、event history |
| 上下文 | 尽量多给模型 | 更小、更高信号的上下文集合 |
| 工具 | 能接多少接多少 | 动态发现、按需加载、权限收敛 |
| 多 Agent | 优先尝试并行和角色分工 | 只在高价值、可并行任务中启用 |
| 安全 | 人工确认、简单隔离 | sandbox、proxy、vault、scoped credential |
| 失败恢复 | 重跑或人工接管 | resume、replay、checkpoint、trace |
| 评估 | 看最终 demo 是否完成 | outcome eval、trace analysis、regression suite |
| 迭代方式 | 加模块、加策略、加 Agent | 做 ablation，删掉过时策略 |
Anthropic 的博客中有个说法是Harness 策略会被模型升级重新定价。
意思是今天 planner 有用，明天可能拖慢系统；今天 evaluator 能救错，明天可能只是在增加成本；今天 context reset 是必要补丁，明天可能成了无用复杂度。
所以生产型 harness 不能只会加东西，也要能删东西。这就是 ablation 的价值。
每次模型升级，都应该重新测：memory 是否有收益，critic 是否有收益，tool search 是否有收益，multi-agent fanout 是否值得，context reset 是否还需要。
Agent 工程里，能删掉过时复杂度，是一种很实际的能力。
写在最后
Agent 产品会继续变复杂，但复杂度不应该都堆在 prompt 和 loop 里，它会下沉到 runtime：
Session：持久状态 Harness：控制面 Context Builder：上下文调度 Tool Router：工具分发 Sandbox：隔离执行 Credential Proxy：凭证边界 Trace：过程记录 Eval：结果评估这组东西才是 Agent 进入生产的底座。
Multi-agent 还会继续发展；MCP 生态也会继续扩大；长上下文窗口还会变长；模型也会继续提升工具调用、规划和自我修复能力。
但这些变化只会让一个问题更突出：系统要能替换掉旧策略。
一个把所有能力写死在 prompt、容器和固定 loop 里的 Agent 平台，会越来越难维护。
一个把状态、执行、凭证、上下文、评估边界拆清楚的系统，才有机会跟着模型一起演进。
参考资料
- Anthropic, Scaling Managed Agents: Decoupling the brain from the hands
www.anthropic.com/engineering/managed-agents - Anthropic, Harness design for long-running application development
www.anthropic.com/engineering/harness-design-long-running-apps - Anthropic, Effective harnesses for long-running agents
www.anthropic.com/engineering/effective-harnesses-for-long-running-agents - Anthropic, Effective context engineering for AI agents
www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - Anthropic, Making Claude Code more secure and autonomous with sandboxing
www.anthropic.com/engineering/claude-code-sandboxing - Anthropic, Code execution with MCP: building more efficient AI agents
www.anthropic.com/engineering/code-execution-with-mcp - Anthropic, Introducing advanced tool use on the Claude Developer Platform
www.anthropic.com/engineering/advanced-tool-use - Anthropic, Equipping agents for the real world with Agent Skills
www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills - Anthropic, Building Effective AI Agents
www.anthropic.com/engineering/building-effective-agents