Harness与Claude Managed Agents深度对比：团队层架构解析

Harness Engineering 深度复盘：托管 Agent 如何重塑团队 Harness 层

延续前文《为什么我在团队大力推进Harness Engineering的同时却不认为它就是未来》的逻辑，这次深入拆解 Anthropic 的 Claude Managed Agents。话题虽不新鲜，但值得反复推敲。

Anthropic 在4月推出的 Claude Managed Agents，对正在用开源组件搭建 Harness 平台的团队或企业而言，冲击力与借鉴价值不容小觑。

这绝非仅是一个 Agent API，其核心意图在于：

模型厂商最清楚自己的短板。模型在哪些环节容易失控、何时该重试、何时压缩上下文、何时重置、何时拆分任务、何时切换 Agent——这些经验过去完全依赖团队自建的 Harness Engineering。

现在 Anthropic 的意图是：由平台先行托管这部分通用运行时。你只需定义清任务、工具、权限与运行环境边界，剩下的 agent loop、session、sandbox、工具路由、失败恢复及长任务运行，平台承担绝大部分。

这套打包方案，就是 Managed Agents。

快速回顾一下产品迭代时间线：

• 2026年4月8日，Anthropic 推出 Claude Managed Agents，定位为面向长任务与异步工作的托管 Agent Harness；
• 2026年4月23日，加入 built-in memory，支持 Agent 将跨 session 的经验沉淀到可管理、可审计的 memory store；
• 2026年5月6日，更新 dreaming、outcomes、multiagent orchestration 与 webhooks：dreaming 让 Agent 定时回顾历史 session 并整理 memory，outcomes 通过 rubric 定义成功标准，multiagent orchestration 支持主 Agent 拆分任务给子 Agent 并行处理；
• 2026年5月19日，补充 self-hosted sandboxes 与 MCP tunnels：前者让工具执行可运行在企业自有基础设施或 Cloudflare、Daytona、Modal、Vercel 等 sandbox provider 中，后者让 Agent 连接企业私网内的 MCP server，无需将内部服务暴露到公网。

综观这几次更新，Managed Agents 已远超“托管一个会调工具的 Agent”的范畴，逐步补齐了长期运行、自我改进、结果评估、多 Agent 协作及企业边界内执行的能力。其路线图更清晰了：Anthropic 托管 agent loop、session 与 harness，企业则牢牢把控工具执行、私有数据及内部系统访问的控制权。

因此，更准确的表述是：并非 Anthropic 要否定 Harness Engineering 本身，而是它正在降低某件事的必要性：

1. Anthropic 想卖的不是 Agent，而是 Harness

这很像十年前 AWS 教育市场什么是云计算。

最初，AWS 并未直接说“你把机器都交给我”。而是先教育市场：弹性计算、对象存储、托管数据库、按需付费、基础设施自动化——这些技术为何重要。

等所有人都意识到“上云”的必要性，AWS 才说：你自己搭不好，也没必要自己搭，我来做。

最终，大多数企业确实选择了托管。

不是因为企业没有能力买服务器，也不是不懂 Linux，而是基础设施从来不是大多数公司的核心竞争力。

Anthropic 的战术如出一辙。

过去一段时间，Anthropic 持续用工程博客教育市场：什么是 harness？为何 harness 比单纯换模型更重要？如何设计一个优秀的 long-running agent harness？

它先告诉你：不要等下一代模型，立即着手做 Harness。

接着又提醒：上一代 Harness 思路会过时，模型能力不断变化，你需要持续复审 Harness。

再往前一步，它现在说：

这就是 Managed Agents 的核心卖点。

它并非“帮你写一个 Agent”。

更像是“帮你承担一大部分通用 Agent 运行时的维护成本”。

2. Harness Engineering 在研发工程中的定位

——研发工程是值得深入探讨的方向，因此重点聚焦于此，而非泛泛谈论 AI 产品。

要理解 Anthropic 为何要托管 Harness，先得厘清 Harness Engineering 在软件研发系统中的位置。

Harness Engineering 是 AI Agent 进入真实软件工程生产链路时，夹在“人类研发活动”与“工程基础设施”之间的一层协作中枢。

它负责将一个“会说话、会写代码的大模型”，转化为能在研发系统中落地的工程协作者。

一个典型的 Harness 至少需要处理以下事项：

• 任务如何拆分；
• 上下文如何传递；
• 工具如何调用；
• 权限如何管控；
• 测试如何执行；
• 失败如何恢复；
• 会话如何保存；
• 长任务如何防止中途跑偏；
• 人类何时介入；
• 最终产物如何进入 PR、CI 与发布流程。

所以，真正稀缺的能力不在模型内部，而在模型的外部。

这个“模型外部”，就是 Harness。

3. 但 Anthropic 正在将一部分“模型外部”托管回模型厂商手中

这就是 Managed Agents 最值得警惕，也最值得兴奋之处。

它并非又一个简单的 API。

更像是 Anthropic 在宣告：

需要严谨地指出，Anthropic 并未将“模型外部”的一切全部收走。

任务定义、工具选择、权限策略、业务规则、数据边界、领域质量判断，仍需开发者和企业自行定义。Managed Agents 解决的是更通用的 Agent 运行时问题，比如 harness、session、sandbox、tool execution 与长任务恢复。

官方文章里有一个非常典型的案例：context anxiety。

在 Claude Sonnet 4.5 上，Anthropic 观察到一种名为 context anxiety 的现象：模型在感知自己接近上下文窗口极限时，倾向于提前收工，长任务表现明显受限。Anthropic 之前为这个问题在 Harness 里加入了 context reset：清空当前上下文窗口，启动一个新 Agent，并用结构化 handoff 传递前一个 Agent 的状态与下一步任务。

但同一套 Harness 用在 Claude Opus 4.5 上时，Anthropic 发现该行为基本消失。

于是，之前精心设计的 context reset，突然变成了冗余代码。

这个例子极为关键。

因为它说明了一件事：许多通用 Harness 补丁的保鲜期很短。

今天为模型缺陷写下的工程补丁，明天可能因模型升级而沦为复杂度包袱。

如果这套 Harness 由自己维护，就要自己发现问题、自己验证、自己删除旧逻辑、自己适配新模型。

如果这套通用 Harness 掌握在 Anthropic 手中，模型升级时，Harness 也能同步升级。

这才是 Managed Agents 真正的卖点：

这也呼应了前文观点：留给自建的空间其实在持续收窄。

4. 技术上，它将 Agent 拆分为三块

此前许多 Agent SDK 的实现方式，本质上是把推理循环、代码执行、工具调用、会话记录全部塞进一个容器里。

这带来一个问题：容器变成了“宠物”。

它不能随意挂掉。因为容器里有会话、工具状态、文件以及 Agent 正在执行的上下文。容器挂了，任务可能丢失；容器卡住，工程师还得进去抢救。

Managed Agents 的思路是将它拆开：

• 大脑：Claude + Harness，负责思考、规划、决策与工具路由；
• 手：Sandbox + Tools，负责执行代码、调用工具、操作外部系统；
• 记忆：Session，独立保存 append-only 的事件日志。

三者之间不再强绑定在同一个长生命周期容器里。

容器挂了？新容器可依据标准配方重建。

Harness 挂了？新 Harness 读取 session log，从断点继续执行。

工具变了？只要仍符合接口规范，Harness 无需关心背后是一台容器、一部手机，还是一个模拟器。

这里最关键的一点是：

但演进节奏的掌控权并不完全在团队自己手中。

在 Managed Agents 中，Agent 配置、工具、MCP、权限确认与运行环境仍属于你的控制范围。尤其 Anthropic 也支持 self-hosted sandbox，说明执行环境不一定必须全部交给 Anthropic 云。

但 Managed Harness 本身的升级、适配下一代 Claude、调整 agent loop——这部分节奏主要掌握在 Anthropic 手中。

这就是平台化的真实代价：

5. Managed Agents 改变的不是 Harness，而是“通用 Harness 的自建冲动”

所以，更准确的表述是：

Harness Engineering 不会消失，但团队自建的那套可能被替代。

相反，它会变得更重要。

但其形态会发生改变。

过去，团队可能需要自行维护 agent loop、上下文压缩、沙盒生命周期、工具调用、权限确认、session 恢复、失败重试、日志追踪。

未来，这些通用能力很可能被模型厂商、云厂商、开源框架与 Agent 平台消化。

这与之前对 Harness Engineering 的判断一致：

它是当前软件工程 AI 化的最佳实践之一。

但它并非终局。

因为它本质上是当前模型能力与真实工程复杂度之间的中间层。

只要模型还不够稳定，Harness 就有价值。

但只要模型继续进步，平台继续托管，这个中间层里的“通用基础设施部分”就会不断被压缩。

真正留下来的，是那些与业务正确性、工程组织、权限责任、质量标准强绑定的部分。

6. 平台会吃掉 80 分，但最后 20 分仍然属于你

不过，这并不意味着所有人都应该立即把 Harness 交出去。

通用 Harness 能覆盖大部分通用场景，但无法覆盖所有场景。

尤其是法律、金融、医疗、安全、工业软件、企业内部研发平台等领域，每个领域都有自己独特的评估标准、权限边界、审计要求与失败成本。

更现实的一点是，Managed Agents 目前也并非一个“所有企业场景都可以放心全量迁移”的成熟终局。它仍带有 beta 产品的边界，而且因为需要保存状态和 session，不适合某些 Zero Data Retention 或高合规约束场景。医疗、金融、核心交易链路这类场景，不能只看功能好不好用，还要看数据、审计、责任与合规如何落地。

平台可以帮你解决 80 分的问题：

• 长任务如何运行；
• 会话如何存储；
• 沙盒如何隔离；
• 工具如何接入；
• 容器如何恢复；
• 事件如何追踪；
• 模型升级后 Harness 如何适配。

但最后 20 分，往往才是真正的竞争力：

• 什么样的输出在你的业务里算正确；
• 哪些工具调用必须人工审批；
• 哪些数据绝不能进入模型上下文；
• 哪些错误可以自动重试，哪些必须停机；
• 哪些测试代表真实质量；
• 哪些规范是团队长期演进的底线；
• 哪些知识是你所在领域独有的隐性经验。

因此，真正值得做的不是“全部自建”或“全部托管”。

而是区分：

这也是团队推进 AI 化时最容易踩的坑。

有些团队一看到平台能力变强，就想把流程判断也交出去；有些团队一担心平台锁定，就什么都自己做。

两个方向都容易累垮团队。

前者的问题是，业务责任不会因为你用了托管 Agent 就消失。出了质量事故、合规事故、权限事故，平台不会替你面对客户和监管。

后者的问题是，把 session、sandbox、tool loop、context reset 这些通用脏活全揽在自己身上，长期看维护成本会极其高昂。尤其模型每升级一代，之前为旧模型写的补丁都可能要重新审一遍。

该托管的托管，该自建的自建。难的不是技术洁癖，而是边界判断。

7. 另一条路线：让 Agent 自己写自己的 Harness

除了模型厂商托管，还有一条更有意思的路线：开源社区与 Agent 自演化。

比如以 Hermes 这类思路为代表的方向，重点不是把 Harness 交给平台，而是让 Agent 自己写 Skill、自己用 Skill、自己改 Skill。

这条路线的想象空间很大，但确定性尚未像 Managed Agents 那样强。

传统 Harness 是人写给 Agent 的。

Managed Agents 是平台写给 Agent 的。

而下一步，可能是 Agent 自己生成自己的 Harness。——这是一个值得持续实验的方向，尽管尚未完全成熟。

这会将 Harness Engineering 推向一个更激进的方向：

Harness 不再是固定支架，而是一个可学习、可演化、可被 Agent 自己修改的运行系统。

当然，这里面潜藏着巨大的安全问题和治理问题。

Agent 自己写规则，谁来审查规则？

Agent 自己改工具，谁来确认权限？

Agent 自己优化 Harness，谁来保证它没有为了完成任务而绕过约束？

所以这条路线不会简单替代 Managed Agents。它更像是另一股压力：模型厂商想把通用 Harness 托管起来，开源社区与自演化 Agent 则会不断提醒，Harness 也可能从“人写规则”走向“系统生成规则”。

但在企业生产环境里，这件事不能浪漫化。

Agent 可以帮我们生成 Skill、总结失败模式、沉淀工具包装，但最终是否进入团队级规则库，仍然需要人类 Review、权限分级、版本管理与回滚机制。

8. 写在最后

之前大家常说：

这句话依然成立。

但 Anthropic 现在正在尝试把“模型外部”的通用运行时部分，重新托管回模型厂商手中。

这不是小变化。

这意味着 AI 软件工程的竞争正在从“谁的模型更强”，扩展到“谁能控制 Agent 的运行时”。

模型厂商不会满足于只卖 token。

它们会继续往外扩展：

• 吃 prompt；
• 吃 context；
• 吃 tool calling；
• 吃 sandbox；
• 吃 session；
• 吃 agent loop；
• 吃一部分 observability；
• 吃一部分 evaluation；
• 最后吃掉大部分通用 Harness。

这里的 observability 与 evaluation 还不能说已经被 Managed Agents 完整吃掉。更准确地说，它们是平台继续向外扩张时自然会触碰到的下一层能力。

因为只要平台托管了 agent loop、session 与 sandbox，它迟早会想回答两个问题：

• Agent 为什么这么做？
• 这次执行到底算不算成功？

前一个问题通向 observability，后一个问题通向 evaluation。

Harness Engineering 不会死。

但“人做通用 Harness”这件事的窗口期，可能比很多人想象得更短。

你的 Harness 要么被模型进步淘汰，要么被平台服务替代，要么你得跑得比这两者都快。

所以，今天真正值得问的不是：

而是（工程化、与产品 AI 化同样适用）：

前者，不要恋战。

后者，才是未来。

下一篇学习、思考点啥呢？超级个体与超级团队的实践思考？本体与知识图谱在 Harness Engineering 中的实践效果小结？