Harness Engineering 思考：托管 Agent 与团队 Harness 层的演进
沿着前面的一篇文章《为什么我在团队大力推进Harness Engineering的同时却不认为它就是未来》 来炒个不算冷的冷饭吧，聊聊我对 Claude Managed Agents 的理解。
Anthropic 4月发了一个很关键的产品：Claude Managed Agents，非常有意思，对我们在拿开源的东西搓Harness 平台的团队或者企业有挺大的冲击和借鉴意义。
这玩意儿不只是一个Agent API，它真正想表达的应该是：
通用 Agent Harness 这层东西，你不用每个团队都从零手搓了。
模型的局限性，模型厂商最清楚。模型在哪些地方容易失控，在哪些地方需要重试，什么时候该压缩上下文，什么时候该 reset，什么时候该拆任务，什么时候该换 Agent，这些经验过去属于团队自己的 Harness Engineering。
现在 Anthropic 的意思是：这部分我可以先替你托管。你把任务、工具、权限和运行环境边界定义清楚，剩下的 agent loop、session、sandbox、工具路由、失败恢复和长任务运行，我来负责一大块。
这个包，就是 Managed Agents。
简单看一下时间线：
- 2026 年 4 月 8 日，Anthropic 发布 Claude Managed Agents，把它定位成面向长任务和异步工作的托管 Agent Harness；
- 2026 年 4 月 23 日，Anthropic 给 Managed Agents 加上 built-in memory，让 Agent 可以把跨 session 的经验沉淀到可管理、可审计的 memory store；
- 2026 年 5 月 6 日，Anthropic 又更新了 dreaming、outcomes、multiagent orchestration 和 webhooks：dreaming 让 Agent 定期回看历史 session 并整理 memory，outcomes 用 rubric 定义成功标准，multiagent orchestration 让主 Agent 可以拆分任务给子 Agent 并行处理；
- 2026 年 5 月 19 日，Anthropic 继续补上 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 本身，而是它正在降低一件事的必要性：
每个团队都自己手搓通用 Agent Harness 的必要性。
1. Anthropic 想卖的不是 Agent，而是 Harness
这件事很像十年前 AWS 教育市场什么是云计算。
一开始，AWS 不是直接说“你把机器都交给我”。它先教育市场：弹性计算、对象存储、托管数据库、按需付费、基础设施自动化，这些东西为什么重要。
等所有人都意识到“上云”是必要的，AWS 再说：你自己搭不好，也没必要自己搭，我来。
最后，大多数企业真的选了托管。
不是因为企业没有能力买服务器，也不是因为企业不懂 Linux，而是因为基础设施从来不是大多数公司的核心竞争力。
Anthropic 现在做的事情很像。
过去一段时间，Anthropic 一直在用工程博客教育市场：什么是 harness，为什么 harness 比单纯换模型更重要，怎么设计一个好的 long-running agent harness。
它先告诉你：不要等下一代模型，马上做 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 在说：
你们不要再围着 Claude 手搓一整套通用 Agent 运行时了。
Claude 怎么跑长任务，怎么保存会话，怎么连接沙盒，怎么恢复失败，怎么适配下一代模型，我比你更懂其中一大部分。
这里要说得严谨一点：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，突然变成了 dead weight。
这个例子非常重要。
因为它说明了一件事：很多通用 Harness 补丁的保鲜期很短。
你今天为模型缺陷写下的工程补丁，明天可能就会因为模型升级变成复杂度包袱。
如果这套 Harness 是你自己维护的，你就要自己发现问题、自己验证、自己删除旧逻辑、自己适配新模型。
如果这套通用 Harness 在 Anthropic 手里，模型升级时，Harness 也可以一起升级。
这才是 Managed Agents 真正要卖的东西：
不是帮你写 Agent，而是帮你承担通用 Harness 随模型变化而持续腐烂的维护成本。
这也是我在前面文章中说的：留给我们的空间其实会越来越少。
4. 技术上，它把 Agent 拆成了三块
之前很多 Agent SDK 的实现方式，本质上是把推理循环、代码执行、工具调用、会话记录都塞进一个容器里。
这带来一个问题：容器变成了“宠物”。
它不能随便死。因为容器里有会话，有工具状态，有文件，有 Agent 正在执行的上下文。容器挂了，任务就可能丢了；容器卡住了，工程师还得进去救。
Managed Agents 的思路是把它拆开：
- 大脑：Claude + Harness，负责思考、规划、决策和工具路由；
- 手：Sandbox + Tools，负责执行代码、调用工具、操作外部系统；
- 记忆：Session，独立保存 append-only 的事件日志。
这三者之间不再强绑定在同一个长生命周期容器里。
容器挂了？新容器可以按标准配方重建。
Harness 挂了？新的 Harness 读取 session log，从断点继续。
工具变了？只要还符合接口，Harness 不必关心背后是一台容器、一部手机，还是一个模拟器。
这里最关键的一点是：
通用 Harness 变成了一个可替换、可演进的托管模块。
但掌握演进节奏的，不一定完全是你。
在 Managed Agents 里，Agent 配置、工具、MCP、权限确认和运行环境仍有你的控制空间。尤其 Anthropic 也支持 self-hosted sandbox，这说明执行环境不一定必须全部交给 Anthropic 云。
但 Managed Harness 本身怎么升级、怎么适配下一代 Claude、怎么调整 agent loop，这部分节奏主要在 Anthropic 手里。
这就是平台化的真实代价：
你少维护一层基础设施，也少掌握一层底层节奏。
5. Managed Agents 改变的不是 Harness，而是“通用 Harness 的自建冲动”
所以如果把这件事说得更准确一些，其实是：
Anthropic 正在降低“每个团队都自己手搓通用 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 分，往往才是我们竞争力：
- 什么样的输出在你的业务里算正确；
- 哪些工具调用必须人工审批；
- 哪些数据绝不能进入模型上下文；
- 哪些错误可以自动重试，哪些必须停机；
- 哪些测试代表真实质量；
- 哪些规范是团队长期演进的底线；
- 哪些知识是你所在领域独有的隐性经验。
所以，真正值得做的不是“全部自建”或者“全部托管”。
而是区分：
哪些 Harness 能力是基础设施，应该交给平台；
哪些 Harness 能力是业务护城河，必须掌握在自己手里。
这也是我们做团队 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. 写在最后
之前大家说：
Harness 意味着，真正稀缺的能力不在模型里面，而在模型外面。
这句话仍然对。
但 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 要么被模型进步淘汰，要么被平台服务替代，要么你得跑得比这两者都快。
所以，今天真正值得问的不是：
我要不要做 Harness？
而是（工程化、与产品AI化同样适用）：
我做的 Harness，哪些是未来会被平台吃掉的基础设施？
哪些是必须留在自己手里的领域判断、质量标准和安全边界？
前者，不要恋战。
后者，才是未来。
下一篇学习、思考点啥呢？超级个体与超级团队的实践思考？本体与知识图谱在Harness Engineering 中的实践效果小结？
本文首发于微信公众号：欣逸AI，个人微信号：（aixinyi0724）
