架构设计 | Feisky

MCP 不只是开发工具：生产级 Agent 集成的三条路

Pengfei Ni — Thu, 23 Apr 2026 10:00:00 +0800

题记：本文编译自 Anthropic 博客《Building agents that reach production systems with MCP》。文章从 Agent 连接外部系统的三条路讲起，重点梳理了 MCP 服务器的设计模式、认证标准化、上下文优化，以及 Skills 的互补定位。不算长，但信息密度不低，尤其是 Cloudflare 的代码编排模式和 Vault 的凭证管理思路，值得做 MCP 服务器的人细看和参考。

我之前给 Claude Code 配 MCP 服务器的时候，最头疼的是上下文占用的问题，后来《Claude Code 终于解决了 MCP 最大的痛点》那篇写过 Tool Search 怎么解决这个事。但用得越多越发现，上下文只是冰山一角。

本地开发时，Agent 调个 API、跑个命令行工具，一切都很丝滑。但等你想把它放到云上跑，问题就来了：CLI 工具没有 shell 可用，API 调用的认证凭证要自己管，每对接一个新服务就要从头写一套集成代码。

刚刚看到 Anthropic 发了一篇博客，系统梳理了 Agent 连接外部系统的三条路，以及为什么生产环境下 MCP 可能是最务实的选择，分享一下，供大家参考。

把 Agent 接入外部系统

Anthropic 把 Agent 接入外部系统的方式分成三种：直接调 API、用 CLI，以及走 MCP 协议。

直接调 API 是最多人的起点，也是最简单的。Agent 在沙箱里发 HTTP 请求，或者通过 function calling 调用外部服务。一个 Agent 对一个服务没什么问题。但接的服务一多，每个 Agent 和服务的配对都要单独处理认证、工具描述和异常情况。做过微服务的人应该很熟悉，这就是经典的 M×N 集成问题。

CLI 也能用，快、轻量，复用现有工具链。但在移动端、Web 端和云托管平台这些没有 shell 的地方往往会到处碰壁，认证也只能靠磁盘上的凭证文件。说白了，CLI 是本地开发的好帮手，离生产还差一截。

MCP 走的是协议层。Agent 连上一个 MCP 服务器，服务器把你系统的能力暴露出来，认证、发现、语义描述都标准化了。一个远程服务器可以同时服务 Claude、ChatGPT、Cursor、VS Code 这些客户端，部署在哪都行。MCP 的前期投入确实比前两种大一些，但换来的是可移植性，以及协议本身能描述的东西也更多。

我自己的感受是，本地开发阶段 CLI 和 MCP 都够用，但一旦 Agent 要上云、要服务多个客户端，MCP 基本是唯一的选择。那为什么 Anthropic 现在特别强调生产环境？

生产 Agent 跑在云上

因为生产级 Agent 越来越多地跑在云上，它们需要连接的系统也在云上：数据存在那里，工单跟踪在那里，基础设施也在那里。这些系统通常是远程的、带认证的，正好是 MCP 擅长处理的场景。

从 Anthropic 自己的产品线也能看出这个趋势。前段时间发布的 Managed Agents，底层就是靠 MCP 连接外部工具和数据源，之前那篇《Managed Agents 架构拆解》分析过它的脑手分离设计。Claude Cowork、Claude Code Channels 也是类似的思路，MCP 在里面扮演的就是连接层的角色。MCP SDK 的月下载量从年初的 1 亿涨到了 3 亿，增速确实有点猛。

不过 Anthropic 也没说 MCP 就应该替代其他方式。API 是基础，CLI 服务本地开发，MCP 覆盖云端。三条路最终都会并存。

那问题就变成了：决定用 MCP 之后，服务器怎么设计才好用？

MCP 服务器怎么设计才好用

Anthropic 目前 MCP 目录里有 200 多个服务器。从这些实践中他们提炼了几个设计模式，结合我自己写 MCP 服务器的经验，聊聊几个我觉得最有价值的。

远程服务器优先

只有远程服务器才能同时覆盖 Web、移动端和云端 Agent，这是分发的前提。本地服务器在开发阶段够用，但想让 Agent 在任何环境下都能调用你的服务，必须上远程。

按意图分组工具，不要一比一镜像 API

这个我之前在《Claude Code 终于解决了 MCP 最大的痛点》提过，工具越少、描述越好，Agent 用起来越准。一个create_issue_from_thread 工具，比让 Agent 自己拼get_thread +parse_messages +create_issue +link_attachment 靠谱得多。

做过 Agent 开发的你应该都体会过，把底层 API 原封不动暴露给模型，基本就是在赌它能自己编排出正确的调用序列。赌赢的概率不高。我之前做 Kubernetes MCP 服务器的时候，最开始也是把 Kubernetes API 一比一映射成工具，结果模型光是选对工具就要好几轮，后来按运维场景重新分组，调用准确率提升了很多。

大量 API 场景用代码编排

如果你的服务有几百个接口，按意图分组也覆盖不完。这时候 Cloudflare 的做法挺妙的：只暴露两个工具（搜索和执行），覆盖了大约 2500 个 API 端点，整个工具定义只占 1K token。思路是让 Agent 写一小段脚本，服务器在沙箱里跑，只返回结果。

用 MCP Apps 做交互

MCP Apps 是 MCP 协议的第一个官方扩展，允许工具返回交互式界面，图表、表单、仪表盘，直接嵌在对话里渲染。你让 Agent 查一下数据库的慢查询，返回的不是一堆文本，而是一个可排序的交互式表格。这体验一下子就提升上去了，Anthropic 说支持 MCP Apps 的服务器在用户留存上表现好很多，这个不难理解。

还有一个叫 Elicitation 的能力也值得关注。它让 MCP 服务器在工具调用中途暂停，向用户请求输入。比如你让 Agent 删一个资源，服务器可以弹一个确认表单，而不是直接执行。更敏感的操作比如 OAuth 登录，可以把用户引到浏览器里完成，凭证不经过 MCP 客户端。这个设计思路和之前聊过的 Managed Agents 的安全隔离一脉相承，敏感信息能不过手就不过手。

认证这块终于不用自己造轮子了

说实话，认证一直是 MCP 从开发到生产最让人头疼的部分。本地开发时 MCP 服务器大多不需要认证，或者直接用 API Key 凑合。但到了生产环境，用户授权、token 存储、过期刷新、多租户隔离，每个环节都是坑。之前每个 MCP 服务器都得自己处理 OAuth 流程，各种边角情况踩不完。

最新的 MCP 规范在这块改进了不少。CIMD（Client ID Metadata Documents）简化了客户端注册的 OAuth 流程，用户首次授权更快，反复弹授权框的情况也少了。MCP SDK、Claude.ai 和 Claude Code 都已经支持这个规范。

对云端 Agent 来说，令牌的存储和刷新是另一个痛点。Managed Agents 的 Vault 机制处理了这个问题：注册一次用户的 OAuth 令牌，创建 session 时引用 Vault ID，平台自动把凭证注入每个 MCP 连接，过期了自己刷新。不用自己搭密钥管理服务，不用每次调用传 token。这个思路和 Kubernetes 里 ServiceAccount 自动挂载 token 的逻辑挺像的，让凭证管理变成基础设施的一部分，应用层不用操心。

上下文效率：Tool Search 和程序化调用

MCP 服务器越多，上下文占用越大，这个问题前面提到过。Anthropic 现在有两个客户端侧的优化模式。

Tool Search 是按需加载工具定义，不一次性全塞进上下文。Agent 运行时搜索工具目录，只拉取当前任务需要的工具。根据 Anthropic 的测试，工具定义相关的 token 占用能降低 85% 以上，选择准确率基本不受影响。

程序化工具调用是在代码执行沙箱里处理工具返回结果，而不是原样扔回给模型。Agent 可以在代码里循环、过滤、聚合多次调用的结果，只把最终输出放进上下文。复杂的多步工作流能省掉大约 37% 的 token。

两个模式叠加使用的效果更好：上下文更精简，往返次数更少，响应也更快。

Skills 和 MCP 是互补的

这个话题之前也聊过。简单说，MCP 给 Agent 能力（能调什么工具、能访问什么数据），Skills 给 Agent 知识（怎么用这些工具完成具体任务），两者最好结合着一起使用。

具体有两种组合模式。

第一种是把 Skills 和 MCP 服务器打包成 Plugin。Claude 的 Plugin 可以捆绑 Skills、MCP 服务器、Hooks、子 Agent 这些组件，一键分发。比如 Cowork 的数据 Plugin，里面有 10 个 Skills 和 8 个 MCP 服务器，覆盖 Snowflake、Databricks、BigQuery 这些数据工具。这种模式让 Claude 从通用助手变成领域专家。

第二种是让 MCP 服务器自带 Skill。Canva、Notion、Sentry 这些厂商已经在做了，在 Claude 的目录里把 Skill 和 Connector 放在一起。MCP 社区也在做一个扩展，让服务器直接分发 Skills，客户端自动继承，版本跟着 API 走。

我的体会是：MCP 服务器只提供工具的话，Agent 每次都得自己摸索调用顺序和参数搭配，效率不高。Skill 把最佳实践编码进去，等于给 Agent 附了一份操作手册，开箱就能按套路来。

写在最后

回头看生产环境 Agent 集成外部系统这件事，由于 Agent 跑在云上，需要连接的服务也在云上，中间就需要一个标准化的协议层。

相比直接 API 调用和命令行 CLI，MCP 目前是这个位置上最合适的协议，特别是远程 MCP 服务器。MCP 的优势在于它是开放协议，不绑定任何一家模型厂商，一个服务器建好了，Claude、ChatGPT 之类的任意 AI Agent 都能用。

Harness 不只是脚手架：从 Claude Code、Hermes 和 OpenClaw 看 Agent 架构的三条路

Pengfei Ni — Tue, 21 Apr 2026 10:00:00 +0800

提到 Harness，大部分人第一反应是 Anthropic 说的那个概念：模型外面包的一层编排代码，负责调用模型、路由工具、管理上下文。我之前写过一篇《为什么单 Agent 搞不定复杂应用？Anthropic 的 Harness 设计给出了答案》，里面详细拆了 Anthropic 的 Generator-Evaluator 模式。Anthropic 的核心观点是 Harness 编码的是对模型能力边界的假设，模型变强了，Harness 就该做减法。

这个理解没错，但只是三种理解中的一种。

最近我把 Claude Code、Hermes Agent 和 OpenClaw 的源码和架构文档都翻了一遍，发现一个挺有意思的事：这三个项目嘴上都在说 Harness，但做出来的东西完全不一样。Claude Code 把 Harness 当脚手架，越轻越好，模型能搞定的事就别替它做。Hermes 把 harness 当学习系统，每次任务都在积累经验，越用越聪明。OpenClaw 把 Harness 当基础设施，Gateway、路由、设备节点、任务调度，跟模型强不强没什么关系。

对 Harness 的理解不同，造出来的产品就完全不同。下面我就带你一起拆开看看它们都是如何设计 Harness 的。

Harness 核心设计

从这三个项目的代码结构和设计文档上，很容易发现它们的架构设计具有明显的不同。

OpenClaw 的核心是 Gateway。官方架构文档第一句也写明了他是一个 long-lived Gateway 拥有所有 messaging surfaces。CLI、macOS app、Web UI、自动化任务，全部通过 WebSocket 连接 Gateway。

手机、Mac、远程设备也通过同一个协议接入，只不过声明自己是 node，暴露摄像头、屏幕、Canvas 等能力。Gateway 默认监听127.0.0.1:18789，连 Canvas 和 A2UI 都由同一个 HTTP server 托管。

也就是说，OpenClaw 把多入口收束成了单控制平面。你从 Telegram 发消息，从 Web UI 操作，从手机节点触发，最终都进入同一套协议、同一套会话管理、同一套工具策略、同一套事件流。也就是说，OpenClaw 先做了神经系统，而不是大脑。

Hermes Agent 的核心是AIAgent。它通过一个 1 万多行的代码，整合了 prompt 装配、provider 选择、工具执行、重试、fallback、上下文压缩、会话持久化等所有的核心功能。CLI、Gateway、ACP、Batch Runner、API Server 这些入口最终都收敛到一起，后来才逐渐补充了 Gateway 和 messaging 平台的适配。

Hermes 的优先级是先把 Agent Loop 做到足够强，让它支持并发工具调用、子代理委派、多 provider fallback、上下文压缩保护，然后再考虑怎么把这个大脑连上外面的世界。

Claude Code 的核心既不是 Gateway 也不是 Agent Loop，而是权限系统和上下文管理。正如《Managed Agents 架构拆解：Anthropic 给 Agent 造了一套 K8s》里提到的，Anthropic 把 Agent 的组件拆成了 session、harness、sandbox 三个独立接口，每个可以独立替换。Claude Code 的源码也是这个思路的体现。

翻它之前泄漏的源码，最庞大的模块是权限相关的代码，处理了六种权限模式、八个权限来源、分类器自动审批、hook 扩展等等。而主循环本身反而很薄，只是负责把每轮完整消息历史交给模型，工具执行完立刻流式返回，没有复杂的调度算法。

Claude Code 的设计哲学可以总结为信任模型+管好边界。模型自己决定调用什么工具、按什么顺序执行、什么时候停下来。Harness 不替模型做决策，只在两个地方卡住：你有没有权限做这件事，上下文是不是快溢出了。

三个项目对 Harness 的理解，在这一层就分道了。OpenClaw 把重心放在多入口收束和协议统一，Hermes 把重心放在 Agent Loop 的能力密度，Claude Code 把重心放在权限管控和上下文保护。

记忆系统设计

记忆是 Agent 从临时工变成长期搭档的关键一步。三个项目在这件事上的做法差异也很大。

Claude Code 的方案最简单，简单到有点反直觉。CLAUDE.md 文件前缀加载，每次会话开始时注入 system prompt。Auto Memory 让模型自己往~/.claude/ 目录下写 Markdown 文件，MEMORY.md 作为索引（最多 200 行、25KB）。没有向量检索，没有 embedding，没有外部数据库。记忆不是主动召回的，而是作为上下文的一部分被模型看到。

上下文压缩也是反应式的：上下文窗口用到快满了才触发压缩。压缩方式是 fork 一个新的 Claude 实例来做摘要，压缩算法会保护工具调用和结果的完整性，不会把一个 tool call 和它的 result 切开。如果压缩连续失败三次，circuit breaker 会停掉，避免死循环。

这个方案的好处是简单、可预测、不依赖外部服务。代价是记忆容量有限，跨会话的信息密度完全取决于 CLAUDE.md 写得好不好。

Hermes Agent 把记忆做成了分层系统。第一层是MEMORY.md 和USER.md，类似 Claude Code 的方案，保存在~/.hermes/memories/，会话开始时注入 prompt。第二层是 SQLite + FTS5 全文搜索，所有历史会话都能被检索和摘要。第三层是 8 个外部 memory provider 插件，包括 Honcho、Mem0、Hindsight 等。

Honcho 的设计值得单独说一下。它不只做向量检索，而是把用户和 AI 都建模为 peer，做跨会话的辩证推理，维护用户表征和 session summary。启用后，Hermes 每轮前会预取相关记忆，每轮后同步对话，会话结束时抽取长期记忆。

Hermes 的记忆哲学是：模型的短期记忆不够用，需要系统帮它在多个时间尺度上积累和召回信息。这和 Claude Code 模型自己能搞定的思路差别挺大的。

OpenClaw 则走了另一条路：把 Context Engine 做成可替换的运行时插件，控制如何构建模型上下文，决定包含哪些消息、如何摘要旧历史、如何跨 subagent 管理上下文。内置的是legacy engine，但插件可以注册完全不同的 engine。

每次模型运行时，engine 有四个生命周期点：ingest(消息进来时)、assemble(构建上下文时)、compact(压缩时)、after turn(一轮结束后)。插件 engine 甚至可以返回systemPromptAddition，动态注入召回指导或检索提示。

OpenClaw 的会话管理也很讲究：DM 默认共享 session，群聊按 group 隔离，rooms 按 room 隔离，cron 每次新 session。多 Agent 场景下，每个 Agent 有独立的 workspace、auth profile、session store。

OpenClaw 的记忆哲学不是记更多，而是让记忆管理本身成为一个可插拔的系统服务。长期 Agent 的记忆需求会不断变化，与其内置一套固定方案，不如把接口留好，让生态去填充。

三种方案，背后是三种对 Agent 该记什么的不同理解。Claude Code 觉得模型够聪明，给它看到就行。Hermes 觉得光看到不够，得帮它在多个时间尺度上积累。OpenClaw 觉得记忆本身的需求会变，不如把接口留好。

扩展性设计

接下来再来看看扩展性的设计，这是让 Agent 能搜索、浏览网页、生成图片、读写文件等各种外置能力的关键。

OpenClaw 把能力扩展拆成了三层：内置 Tools 是 Agent 可以随时调用的预装能力，Skills 是教 Agent 什么时候用、怎么用外部工具的扩展能力，而 Plugins 则是打包了工具、技能、消息通道、模型等各种扩展的能力包。

这个三层模型把三个容易混淆的东西拆开了：工具是默认能做什么，技能是什么时候/怎么样去调用外部工具，插件是怎么打包、发现、分发这些能力。ClawHub 上架了 58000 多个社区 Skill，一条命令安装，这对于带火 OpenClaw 功不可没。

Hermes Agent 的工具系统用了 registry 自注册模式。tools/registry.py 是中心注册表，每个工具文件在模块级调用registry.register() 声明 schema、handler、toolset 归属和可用性检查。model_tools.py 是 registry 之上的薄编排层，负责导出工具定义、处理函数调用、维护工具到 toolset 的映射。

有个很细的设计：model_tools.py 会根据当前真正可用的工具重建execute_code 的 schema。比如 web API key 没配置，模型就不会在 sandbox 里看到web_search 这个工具。这能减少模型“以为自己能做但其实做不了”的幻觉式调用。

Hermes 的技能系统用了 progressive disclosure：Level 0 只加载 name 和 description，Level 1 加载完整技能内容，Level 2 加载技能引用的附件。模型先扫描技能列表，匹配到了再深入加载。更关键的是，Agent 可以通过skill_manage 自己创建、更新、删除技能。解决了一个非平凡任务后，它可以把方法保存为技能文件，下次遇到类似问题直接复用。

这就是 Hermes 说的“程序性记忆”。普通 Agent 完成任务后只留下结果，Hermes 完成任务后还试图留下方法。当你积累 20 个以上自创技能后，同领域任务完成速度能提升 40% 。

Claude Code 的扩展体系跟前两者的思路都不一样，它不是围绕工具注册或技能发现来组织的，而是围绕权限边界层层展开的。

最底层是 28 个内置工具，覆盖文件读写、搜索、Shell 执行、Web 访问、子代理调度等基础能力。这些工具分两类：Read、Glob、Grep 这类只读工具不需要权限，Bash、Edit、Write 这类有副作用的工具每次执行都要过权限检查。权限不在工具注册时声明，而是在执行时由 harness 拦截，模型不需要考虑“我能不能做这件事”，该拦的时候自然会拦。

往上一层是 MCP 协议。Claude Code 通过 MCP 接入外部工具服务器，支持 stdio、HTTP、SSE 三种传输方式。MCP 工具默认是延迟加载的：会话开始时只把工具名称放进上下文，模型需要用的时候通过ToolSearch 工具按需拉取完整 schema。这个设计跟 Hermes 的 progressive disclosure 异曲同工，只是实现路径不同，一个在技能层做分级加载，一个在工具层做延迟发现。

再往上是 Hooks、Skills 和 Plugins 三层扩展。Hooks 提供了 25 个生命周期事件，可以挂 shell 命令、HTTP 请求、甚至 LLM 评估。Skills 遵循开放的 Agent Skills 标准，用 Markdown + YAML frontmatter 定义可复用的工作流，，持参数替换和条件触发。Plugins 则是把 Skills、Hooks、MCP 配置、子代理定义打包成一个可分发的单元。

子代理是 Claude Code 处理复杂任务的核心机制。每个子代理运行在独立的上下文窗口里，有自己的系统提示和会话历史。内置了 Explore（快速搜索，用 Haiku 模型）、Plan（规划研究）、general-purpose（全功能）等预设类型，也支持通过.claude/agents/ 目录自定义。自定义子代理可以精细控制工具白名单、权限规则、模型选择，甚至预加载特定 Skills。

能力管理的复杂性往哪放？OpenClaw 交给社区生态，Hermes 交给 Agent 自身的积累，Claude Code 交给分层的权限边界。

怎么面对模型进步

这个维度最值得琢磨。

Anthropic 有一个很有意思的观察：harness 编码的是对模型能力边界的假设，但模型在进步，假设会过期。Sonnet 4.5 的时候模型有上下文焦虑，随着上下文窗口接近极限会提前收工，harness 里加了重置机制来应对。结果换到 Opus 4.5，这个行为自己消失了，重置机制变成了死代码。

Claude Code 对这一点的应对是大量的功能开关，从它泄露的源码能看到大量 HISTORY_SNIP、REACTIVE_COMPACT、TRANSCRIPT_CLASSIFIER 等等这样的开关。比如，到了 Opus 4.6，之前在 harness 里加的 Sprint 机制（把长任务拆成小块、每块结束后评估）就被整个拿掉了，因为模型已经可以连续写代码不跑偏。Evaluator 也从每个 Sprint 后评分改成了全部开发完再做一轮 QA。

Anthropic 认为 harness 应该为减法而设计。每个组件都应该能被安全移除，而不是越堆越厚。权限分类器也是同一思路，模型能力到了之后，很多需要人类确认的操作可以自动放行（所以后来新增了 Auto 权限模式）。

Hermes Agent 的思路不太一样。它认为有些东西不会因为模型变强而过期：五层记忆系统、技能文件沉淀、跨会话搜索、用户建模。模型再强，也需要知道“上次这个用户让我做过什么”和“这类任务我之前是怎么解决的”。

Hermes 甚至有一个单独的hermes-agent-self-evolution 仓库，用 DSPy 和 GEPA 来做自动化的技能优化。具体做法是：跑一组评估任务，比较优化前后的技能文件在完成效率和准确率上的差异，自动选择更好的版本。目前实现了 Phase 1 的技能文件优化，Phase 2 计划覆盖工具描述和系统提示词。说实话，这个想法挺有意思的，相当于给 Agent 加了一个慢速但持续的自然选择过程。虽然模型会趋同，但谁能把每次任务变成下一次的能力，谁就有了复利。

OpenClaw 的基础设施层几乎不受模型进步的影响。Gateway 不会因为 Claude 变强就不需要了。多入口路由不会过期，设备节点不会过期，会话隔离不会过期，权限分层不会过期。

模型会越来越强，但连接现实世界的管道不会自动出现。你还是需要一个东西来管理“谁能在什么时候通过什么入口让 Agent 做什么事”，模型再强也替代不了这一层。

三种方向，对应三种对“模型进步会淘汰什么”的判断。OpenClaw 认为基础设施不会过期，所以建管道。Hermes 认为经验积累不会过期，所以做加法。Claude Code 认为大部分脚手架会过期，所以做减法。

写在最后

有意思的是，三条路正在往一个方向收敛。Claude Code 加了 auto memory 和 channels，Hermes 加了 Gateway 和多平台适配，OpenClaw 在做 Context Engine 可插拔化。起点不同，但目的地越来越像：一个有记忆、有技能、有入口、有权限、有持久状态的个人 AI 系统。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

]]>

Managed Agents 架构拆解：Anthropic 给 Agent 造了一套 K8s

Pengfei Ni — Thu, 09 Apr 2026 10:00:00 +0800

题记：本文编译自 Anthropic 工程博客《Scaling Managed Agents: Decoupling the brain from the hands》，由 Lance Martin、Gabe Cemaj 和 Michael Cohen 撰写。

Kubernetes 早就是 AI 基础设施的事实标准了。不管是大模型训练还是推理服务，最后都跑在 K8s 上。AI Agent 也不例外，Harness、sandbox、工具调用这些组件，基本都可以容器化部署。

但跑过长时间 Agent 任务的人应该都碰过这种事：Agent 跑着跑着容器挂了，session 没了，只能从头来。session 卡死了想调试，Harness、sandbox、session 全在一个容器里，根本分不清问题出在哪。好不容易跑起来了，上下文窗口又满了，压缩还是丢弃，怎么选都可能踩坑。

做过 K8s 的人看这些问题应该很眼熟。十年前容器编排领域碰到的也是同一类：组件耦合、状态丢失、扩展困难。K8s 的解法是把硬件虚拟化成抽象层，Pod、Service、PersistentVolume 这些概念比底层硬件活得久得多。你换磁盘、换机器，上层应用完全不用管。

Anthropic 昨天开放公测的 Managed Agents，本质上在做同样的事，只不过虚拟化的对象从硬件换成了 Agent 的组件。

Anthropic 的工程博客一直在聊怎么给 Agent 搭 Harness：从构建有效 Agent 到长时间任务的 Harness 设计，再到上下文工程。这些文章贯穿着一条线索：Harness 编码的是对 Claude 当前能力边界的假设，但模型在进步，假设会过期。

举个例子。之前在 Sonnet 4.5 上，他们发现模型会随着上下文窗口接近极限而提前收工（也称为上下文焦虑）。于是 Harness 里加了上下文重置机制。结果换到 Opus 4.5 上一跑，行为消失了。重置机制变成了死代码。

Harness 免不了一直改下去。所以 Anthropic 造了 Managed Agents：用一组尽可能通用的接口来运行长时间 Agent，让这些接口比任何一套具体的 Harness 实现活得更久。

它把 Agent 的核心组件虚拟化成了三个接口：session（发生了什么的完整事件日志）、harness（调用 Claude 和路由工具调用的循环）、sandbox（Claude 跑代码和编辑文件的执行环境）。每个组件可以独立替换，互不干扰。跟 K8s 对 Pod、Volume、Service 的抽象思路一致。

别养宠物

做过 K8s 的你对 Pets vs Cattle 这个比喻肯定不陌生。Pet 是你精心照料的单台服务器，挂了就得抢救；Cattle 是随时可以杀掉重建的无状态实例。云原生的核心理念之一就是把所有东西变成 Cattle。

Managed Agents 一开始没做到这一点。

最初的设计是把所有 Agent 组件塞进一个容器。好处是文件操作就是本地 syscall，不需要设计服务边界。但这就养了一只宠物。容器挂了，session 就没了。容器卡住了，得想办法把它救活。

救活容器意味着调试卡死的 session。唯一的观察窗口是 WebSocket 事件流，但它分不清故障发生在哪个环节。Harness 的 bug、事件流的丢包、容器下线，在外面看起来症状完全一样。要搞清楚怎么回事，工程师得开 shell 进到容器里，但容器里还有用户数据，这条路基本走不通。

还有一个更深的问题。Harness 默认 Claude 的工作内容就在同一个容器里。当客户说“我想让 Claude 连我自己的 VPC”时，要么做网络对等互联，要么让客户在自己的环境里跑 Anthropic 的 Harness。一个 Harness 里硬编码的假设，变成了基础设施层面的约束。

这跟早年单体应用跑在物理机上的困境太像了。

把大脑从手上拆下来

解法是把大脑（Claude 和 Harness）从手（sandbox 和工具）和记忆（session 日志）上拆开。每个组件变成一个接口，对其他组件的假设尽可能少，独立故障、独立替换。

K8s 里 Pod 是无状态的计算单元，PersistentVolume 是持久化存储，两者通过声明式绑定关联但互不依赖。Pod 挂了重建一个，数据还在。Managed Agents 的拆法思路一样。

Harness 不再住在容器里。它像调用其他工具一样调用容器：execute(name, input) → string。容器变成了 Cattle，挂了就挂了，Harness 把失败当作工具调用错误传回给 Claude，Claude 决定要不要重试。重试的话，provision({resources}) 拉一个新的就行。

不用再抢救挂掉的容器了。

Harness 自己也是 Cattle。session 日志在外部，Harness 里没有任何需要在崩溃中存活的状态。挂了？wake(sessionId) 启动一个新的，getSession(id) 拿回事件日志，从最后一个事件继续。运行过程中用emitEvent(id, event) 往 session 写入持久化记录。

这里面还有一个安全维度值得单独说。

之前所有东西耦合在一个容器里的时候，Claude 生成的不可信代码和凭证跑在同一个环境中。一次成功的 prompt injection 只需要说服 Claude 读一下自己的环境变量。拿到 token 之后，攻击者可以开新 session 干什么都行。

收窄 token 权限？当然可以。但这本身又是一个假设：Claude 拿着受限 token 干不了什么。模型在变强，这个假设随时可能失效。

结构性的解法是让 token 在 sandbox 里根本不可达。Git 仓库的做法是在 sandbox 初始化时用 token 克隆仓库并写入本地 git remote，之后push 和pull 都走本地配置，Agent 从头到尾碰不到 token。自定义工具走 MCP，OAuth token 存在安全保险箱里，Claude 通过专用代理调用 MCP 工具，代理根据 session 拿到对应的凭证再调外部服务。整个链路里，Harness 不接触任何凭证。

Anthropic 这个思路挺值得参考的：不是所有安全问题都要靠权限收窄来解决，有时候换个架构就能把问题消除掉。

Session 不是上下文窗口

脑手分离解决了组件耦合的问题，但 Agent 跑久了还有另一个挑战：上下文管理。

长时间任务经常超出 Claude 的上下文窗口。常见的应对方式都涉及不可逆的决策：compaction 把上下文压缩成摘要，memory 工具把信息写到文件，context trimming 选择性地删掉旧的工具结果或 thinking block。这些方法都能用，但有个共同的软肋，就是你很难预判未来哪些 token 会被用到。删错了就回不来了。

之前有研究探索过一个思路：把上下文存成一个对象放在 REPL 里，模型通过写代码来过滤和切片，而不是被动接受压缩后的结果。

Managed Agents 的 session 做了类似的事，但把上下文存在了 sandbox 外面。session 日志是持久化的，通过getEvents() 接口让大脑按位置切片查询事件流。可以从上次读到的地方继续往下读，也可以倒回某个时刻前几个事件看看当时的背景，或者在执行某个操作前重新读一遍相关上下文。

拿到的事件在传给 Claude 之前还可以在 Harness 里做各种变换：重组结构以提高 prompt cache 命中率，或者做其他上下文工程。这里的设计考量是把“可恢复的上下文存储”和“任意的上下文管理”分成两个关注点。前者放在 session 里保证持久和可查询，后者放在 Harness 里，怎么折腾都行。因为未来的模型需要什么样的上下文工程，现在谁也说不准，但 session 的持久性是确定需要的。

用 K8s 类比的话，session 就是 PersistentVolume：数据在那里，不管哪个 Pod 来挂载都能用。上下文工程是 Pod 里的应用逻辑，随着业务需求随时可以换。

多脑多手

组件拆开之后，扩展变得自然了。

先说多脑。之前大脑和手都在一个容器里，每启动一个 session 就要起一个容器。不管这次 Claude 用不用 sandbox，容器都得先跑起来：克隆仓库、启动进程、拉取待处理事件。这些全卡在 TTFT（Time to First Token）上，用户最敏感的延迟指标。

拆开之后，容器只在需要时才通过工具调用启动。不需要 sandbox 的 session 直接跳过容器初始化，推理在编排层拉到 session 事件后就开始。

p50 TTFT 下降约 60% ，p95 下降超过 90% 。

这个优化思路在 K8s 社区一点都不陌生。这些年围绕 Pod 冷启动的优化从没停过：镜像预拉取、lazy snapshot、WASM 轻量运行时。核心逻辑都是一样的，不需要的东西别提前准备。

再说多手。之前一个大脑只能操作一个容器，容器挂了就全完了。现在每只手就是一个工具调用：execute(name, input) → string，名字和输入进去，字符串出来。这个接口能接任何自定义工具、任何 MCP 服务器、Anthropic 自己的内置工具。Harness 不知道也不关心 sandbox 到底是一个容器、一部手机，还是一个宝可梦模拟器。

因为手不绑定任何特定的脑，多个 Agent 之间可以互相传递工具。产品公告里提到 Managed Agents 已经在研究预览中支持多 Agent 协调，一个 Agent 可以生成和指挥其他 Agent。多脑多手的架构落地之后，这种能力是水到渠成的。

Anthropic 内测的数据也挺有意思。在结构化文件生成这类任务上，比如根据 API schema 自动生成 SDK 代码和文档，相比标准的 prompting 循环，任务成功率最高提升了 10 个百分点，难题上增益最大。加上 Console 里内置的执行追踪和分析工具，每个工具调用、每次决策、每个失败点都能看到，对于把 Agent 推上生产环境的团队来说实用性不错。

写在最后

读完这篇工程博客，我脑子里一直跑着一个想法：这就是 Agent 领域的 Kubernetes。

K8s 当年解决的也是同一类问题。应用越来越复杂，单机跑不动了，需要一个编排层来管理容器的生命周期、网络和存储。K8s 没有规定你的应用该怎么写，它定义了一组接口，让任何应用都能跑在上面。十年过去了，底层的容器运行时从 Docker 换到了 containerd，节点从 CPU 服务器换到了 GPU 集群，但 Pod 的定义还是那个 Pod。

Managed Agents 在做同样的事。它不规定 Harness 怎么写，而是把 Agent 的核心组件虚拟化成接口。Claude Code 是一个很好的 Harness，任务专用的 Agent Harness 在特定领域可能表现更好，Managed Agents 都能承载。接口固定，实现自由替换。

不过有一个差异。K8s 是开源的，CNCF 社区驱动，任何云厂商都能跑。Managed Agents 是 Anthropic 的托管服务，目前只服务 Claude 生态，或许这也是为什么他们会不停封禁诸如 OpenClaw 这样的第三方平台。当然，这篇博客公开了设计理念和接口抽象的思路，即使不用 Managed Agents，这套脑手分离的架构模式也能自己实现。

AI Agent 的基础设施层还在快速成型。Anthropic 在做 Managed Agents，OpenAI 有 Codex 的云端 Agent，Google 有 Vertex AI Agent Engine，最终谁成为 Agent 编排的事实标准还不好说。但有一点是确定的：Agent 的组件解耦、状态持久化、安全隔离这些需求不会消失，只会随着 Agent 能力的增长变得更重要。