在 Claude Code 源代码泄露之后，我们从泄露的源码里整理出了 12 种 Agentic Harness 模式。后来又结合 Anthropic 官方的 Agent Skills 构建指南，进一步拆解出 14 种 Skill 编写模式。这次我们再往前推一步，问题就变得更实际了：当 Agent 真正投入到生产系统里，到底该怎么连接那些真实的业务工具、权限系统和数据源呢？Anthropic 官方最近有一篇关于 MCP 的文章，标题是《Building agents that reach production systems with MCP》，讲的就是这个问题。
文章里对比了直接 API 调用、CLI 和 MCP 这三种方式的区别，还解释了为什么现在生产级 Agent 越来越倾向于用 MCP。生产级 Agent 的难点，不在于能不能调用工具，而在于能不能安全、稳定，还能低成本地连接到真实的系统。所以这篇文章不打算讲 MCP 协议的具体细节，而是换个角度：如果把 Anthropic 的实践提炼成工程模式，哪些设计是我们可以直接复用的？我把这些实践拆成了 5 组、一共 12 个模式，覆盖了工具交互面、交互语义、认证凭证、上下文经济，还有打包分发这五个方面。搞懂这些模式，比单纯会写一个 MCP Server 要有用得多。
工具交互面（Tool surface）
工具交互面的设计，是 MCP Server 要做的第一个架构决策。很多团队第一次做 MCP Server，很自然就会想：既然已经有现成的 API 了，那干脆把每个 API endpoint 都包装成一个工具就行。这个想法很直观，但通常不是最优解。因为 Agent 思考问题不是按 endpoint 来的，它要做的是具体任务，比如“从 Slack 话题里创建一个 Issue”“查一查这次部署为啥失败了”“帮我找出过去七天里最异常的指标”。如果 MCP Server 只是简单镜像 API，Agent 就得自己去拼接一大堆底层操作。工具越多，调用的链条就越长，上下文就越臃肿，出问题的地方也会跟着变多。好的 MCP Server，不是 API 的翻译器，而是 Agent 面向具体任务的产品接口。
1. 远程优先服务器模式（Remote-First Server Pattern）
第一个模式要解决的问题是：MCP Server 应该运行在什么地方？本地的 MCP Server 通过 stdio 和客户端通信，适合桌面应用、IDE Agent、本地的 Claude Code，或者一些命令行场景。它很轻便，开发调试起来也方便。但一旦进入生产环境，这个前提就不稳固了。生产环境里的 Agent，可能运行在浏览器、移动端、云端执行环境或者托管平台上，它不一定能启动本地进程，也不一定能访问用户机器上的文件系统。所以 Anthropic 的建议很明确：如果目标是生产级的集成，从一开始就该按远程 MCP Server 的标准来设计。远程优先的好处很明显：
- 一个 Server 可以服务多个客户端；
- 同一套认证流程，能跨不同环境复用；
- Web、移动端、云端的 Agent 都能访问；
- Server 可以独立部署、扩展、监控和审计。
不过远程优先也不是没有代价。你得处理网络延迟、可用性、限流、认证、安全边界、日志和运维这些问题。本地进程里可以偷懒的地方，远程服务都得一一补齐。所以这个模式适合大多数生产集成，但也不是说所有本地 Server 都该被淘汰。更准确的判断是：本地 MCP Server 适合开发者环境，远程 MCP Server 才是生产分发的正确形态。
2. 按意图组织工具模式（Intent-Grouped Tools Pattern）
第二个模式要解决的是：工具应该按什么粒度暴露给 Agent？最常见的错误，就是把 MCP Server 做成和 API endpoint 一一对应的样子。比如一个工单系统原本有这些接口：
- get_thread
- parse_messages
- create_issue
- link_attachment
如果把这些接口原样暴露给 Agent，模型就得自己判断先调用哪个、怎么把上一步的结果传给下一步、失败了该怎么恢复。这不是不能实现，而是把太多编排的责任都推给了模型。更好的做法，是按用户的意图来组织工具。比如直接提供一个工具：create_issue_from_thread这样一来，Agent 就不用拼接四个底层动作了，直接调用这一个面向任务的工具就行。底层的 API 编排、ID 归一化、附件关联、错误重试，都可以在 MCP Server 内部处理好。这个模式适合那些 API 面不算太大、用户任务相对明确的系统。比如 Linear、Slack、Notion、Sentry 这类工具，很多操作都能归纳成明确的用户意图：创建工单、总结话题、查询错误、生成报告、更新页面。它的代价也很清楚：你不能只导出 schema，还得用心设计工具。工具的名称、参数结构、返回结果、错误处理，都要围绕 Agent 的任务体验重新梳理。MCP Server 不只是一个代理层，更是一个需要持续优化的产品接口。
3. 薄交互面模式（Thin Surface Pattern）
第三个模式要解决的是：如果底层的 API 面太大，就算按意图组织，也会变得难以控制，该怎么办？比如 AWS、Cloudflare、Kubernetes 这类系统，底层操作可能有几百甚至几千个。就算按意图分组，也很难把所有能力都封装成数量合理的工具。这时候，继续增加工具数量，只会让上下文变得臃肿不堪。薄交互面的思路刚好相反：不暴露太多工具，只暴露少量但能力强大的工具。典型的组合就是：
- search：让 Agent 自己搜索可用的 API 或能力；
- execute：让 Agent 写一段短脚本，由服务端在沙箱里执行。
Anthropic 的文章里提到，Cloudflare MCP Server 就是个典型例子：两个工具就覆盖了大约 2500 个 endpoint，工具定义大概只需要 1000 tokens。这背后的逻辑是：把庞大的 API 面藏在 Server 后面，让 Agent 通过搜索找到自己需要的能力，再用短代码完成调用和组合。这个模式特别适合那种“API 规模巨大、任务形态不固定”的系统。但它的代价也更大：你必须有可靠的沙箱、资源限制、超时策略、权限边界和审计机制。因为 Agent 不再只是简单填写参数，而是要在服务端执行代码。所以薄交互面不是默认选择，它适合超大 API 面的场景，不适合那些本来就能被清晰意图封装的小系统。
交互语义（Interaction Semantics）
很多早期的 Agent 工具，都默认工具返回的是文本或者 JSON。在简单场景里这没问题，比如查询一个状态、返回一段摘要、创建一个对象。但生产系统里的很多信息，本来就不适合用文字来描述。比如搜索结果、指标看板、错误列表、文件预览、支付流程、OAuth 页面、删除确认，这些东西如果都让模型转换成自然语言，不仅效率低，还容易丢失原本的结构。MCP 的一个重要发展方向，就是让工具拥有更丰富的交互语义。也就是说，工具不只是“返回一段文本”，还能返回 UI、请求用户补充结构化信息，或者把用户安全地引导到外部流程里。
4. 内联 UI 模式（Inline UI Pattern）
内联 UI 要解决的问题是：有些结果不应该让模型去描述，而是应该直接展示给用户看。比如一个监控 Dashboard、一张趋势图、一组搜索结果、一个审批表单、一个文件预览页面。如果工具先返回一大段 JSON，再让模型总结成文字，用户看到的其实是二手信息，原本的结构、细节和可操作性都会大打折扣。MCP Apps 允许工具返回一个可交互的界面，让客户端在聊天界面里直接渲染出来。这就意味着，MCP Server 不只是后端能力的提供者，也开始承担一部分产品界面的职责。这个模式适合所有“看比听更重要”的结果：
- 图表
- 表格
- Dashboard
- 搜索结果
- 文件预览
- 审批确认
- 状态面板
代价是，Server 团队不能再只按后端接口的思维来工作了，还要考虑组件版本、可访问性、视觉一致性和客户端兼容性。但从用户体验来看，这绝对是更自然的方向。
5. 引导式输入模式（Elicited Input Pattern）
生产环境里调用工具，经常会遇到信息缺失的情况。比如用户说：“帮我重启这个服务。”但这个服务可能部署在多个 region，或者有多个同名的实例。这时候 Agent 有三个选择：
- 猜一个；
- 回到对话里追问用户；
- 暂停工具调用，向用户请求结构化的输入。
前两个选择都不理想：猜测有风险，普通的追问又会打断整个流程。MCP 的 Form Mode elicitation 就支持这种场景：Server 在工具调用中途，返回一个表单的 schema，Client 负责渲染这个表单，用户填写完成后，再把控制权交回给 Server。这适合几种场景：
- 缺少 region、环境、项目 ID 这类结构化参数；
- 有多个候选项，需要用户选择；
- 删除、支付、部署这类高风险操作，需要用户确认；
- Server 明确知道还缺哪些信息。
它的好处是，用户不用重新发起一轮对话，Agent 也不用假装自己知道答案。代价是，每一次引导输入都是一次 UX 设计。如果表单设计得不好，用户会觉得 Agent 像在审问自己。同时，这个模式不适合无人值守的场景。如果是 headless Agent 或者批量工作流，没人在场填写表单，整个流程就会卡住。
6. 外部跳转交接模式（External Handoff Pattern）
外部跳转交接要解决的是更敏感的问题：有些信息根本不应该经过 MCP Client。比如第三方 OAuth、支付流程、银行卡信息，还有某些合规要求下的敏感凭证。如果这些信息进入了 Agent 的上下文，或者经过了 MCP Client，就会扩大安全边界。很多时候，正确的做法不是让 Agent 处理这些机密信息，而是把用户引导到外部系统去处理。MCP 的 URL Mode Elicitation 就是这种形式。Server 返回一个 URL，Client 打开浏览器或者外部页面，用户在那里完成 OAuth、支付或者敏感信息的输入，流程结束后，再回到 Server 继续执行。这里要区分一下 Form Mode 和 URL Mode：
- Form Mode 适合 Server 可以合法接收和处理的结构化输入；
- URL Mode 适合那些应该由第三方或者外部系统处理的敏感流程。
这个模式的代价是，用户会离开 Agent 界面。每一次跳转，都可能导致用户流失，也会增加流程恢复的难度。所以在工程上，必须设计好 resume-after-redirect 机制，让用户跳转回来之后，流程还能继续衔接上。
认证与凭证流（Auth and Credential Flow）
生产级 Agent 绝对绕不开认证这个问题。只要 Agent 要访问真实的系统，就必须处理用户身份、组织权限、OAuth scope、token 刷新、凭证撤销和审计这些事情。如果每个 MCP Server 都自己搞一套认证方式，用户接入的成本会非常高，客户端也很难统一支持。所以认证不是一个附属问题，而是 MCP 能不能成为生产级连接层的关键。
7. 可发现认证模式（Discoverable Auth Pattern）
如果一个 Server 要求用户手动复制 token、配置 client ID、填写 redirect URI，那第一次接入的时候，很容易出问题。在生产系统里，这种“靠用户手工配置”的流程，通常意味着更高的失败率和更多的重复登录。MCP 支持标准的 OAuth 能力，Anthropic 的文章里特别提到了 CIMD，也就是 Client ID Metadata Documents。简单理解就是，CIMD 让客户端可以通过标准的元数据，自动发现这个 Server 的认证方式。客户端不用去猜这个 Server 该怎么登录，只要读取元数据，按照标准流程启动 OAuth 就行。这个模式适合所有需要访问用户数据的生产级 MCP Server。它的价值不是让 OAuth 本身变得多神奇，而是把认证流程从“每家各搞一套”变成了“客户端可自动发现”。代价是，Server 必须严格遵守标准的 OAuth 行为，维护好 metadata endpoint、redirect URI 校验、scope 设计、token 校验，还有跨客户端的兼容性。
8. 凭证托管到 Vault 模式（Vault-Held Credentials Pattern）
就算认证流程标准化了，token 还是需要一个安全的存放地方。很多糟糕的集成，会把 token 放进工具参数、环境变量、临时配置里，甚至每次调用工具都携带凭证。这在生产系统里是非常危险的。凭证托管到 Vault 模式的思路是：把凭证的生命周期管理，提升到平台层来做。在 Claude Managed Agents 里，MCP OAuth credential 可以注册到 Vault 里。创建 session 的时候，只要引用 vault ID，平台就会负责把合适的凭证注入到 MCP 连接中，还会处理凭证的刷新、撤销和生命周期管理。这个模式的关键，不只是“有一个密钥存储”这么简单。真正重要的是：MCP Server 不需要在每次工具调用时接收 token，也不用自己实现完整的凭证刷新、撤销和轮换逻辑。凭证管理从工具调用的路径里抽离出来，变成了平台的一项能力。代价是，你必须信任这个平台 Vault。它的安全性、可用性、审计能力和导出策略，都会成为生产架构的一部分。对于没有托管平台的团队，也需要自己实现类似的模式，而不是把 token 的生命周期管理，零散地放在工具代码里。
上下文经济（Context Economy）
做 Agent 工程的人，很容易忽略一个事实：上下文窗口不是无限的资源，而是一个架构上的约束。MCP 让 Agent 可以连接更多的 Server，获得更多的工具。但如果每个 Server 都暴露几十上百个工具，Client 一上来就把所有的 tool definitions 都塞进模型上下文，成本会非常高。更糟的是，工具返回的结果也可能很大。比如日志、trace、文档、搜索结果、JSON 列表、指标数据，如果原样返回给模型，模型会消耗大量的 token 去读取很多其实用不上的信息。所以 MCP Client 也需要对应的工程模式。
9. 按需加载工具模式（On-Demand Tool Loading Pattern）
按需加载工具模式要解决的，是工具定义带来的上下文成本问题。当 Agent 连接多个 MCP Server 时，它可能会拥有几百个工具。如果全量加载这些工具定义，相当于任务还没开始，就已经消耗了大量的上下文预算。tool search tool 的做法是延迟加载。Agent 先通过一个搜索工具，查找可能相关的工具，只把找到的工具定义加载进上下文，剩下的工具保持不可见。根据 Anthropic 官方的测试，Tool Search 可以让 tool-definition tokens 减少 85% 以上，同时还能保持较高的工具选择准确率。这个模式的代价是，多了一次搜索步骤，而且高度依赖工具描述的质量。如果工具描述模糊，搜索可能找不到正确的工具；如果描述太宽泛，又可能加载很多无关的工具。所以 Tool Search 不是用来替代工具设计的，反而会倒逼工具描述写得更像产品文案：准确、可检索、能区分。
10. 程序化工具调用模式（Programmatic Tool Calling Pattern）
另一个浪费上下文的地方，是工具返回的结果。很多工具返回的结果，并不适合直接给模型看。比如：
- 几千行的日志；
- 一大段 JSON；
- 多页的搜索结果；
- trace 树；
- 数据表；
- 多个 API 调用的结果。
模型真正需要的，往往不是这些原始数据，而是经过过滤、聚合、排序、统计之后的结果。程序化工具调用的做法是，让 Agent 在代码执行沙箱里处理工具返回的结果。它可以循环调用工具、过滤数据、聚合字段、做中间计算，最后只把必要的结果放进模型上下文。根据 Anthropic 官方的测试，这种方式在复杂的多步流程里，能减少大约 37% 的 token 使用。它和按需加载工具模式能形成一个完整的组合：
- 按需加载工具模式，减少“工具定义”进入上下文；
- 程序化工具调用模式，减少“工具结果”进入上下文。
代价是，客户端需要有代码沙箱，也需要能调试 Agent 写出来的中间代码。对于简单的一次性工具调用，这个模式可能显得太复杂。但对于日志分析、数据处理、跨系统查询这类任务，它会非常实用。
打包与分发（Packaging and Distribution）
到这里，MCP Server 已经解决了很多问题：连接、工具面、交互、认证、上下文。但真实的集成还有一个关键问题：怎么交付？一个真正有用的 Agent 集成，通常不只是一个 MCP Server。它还可能包括：
- Skills：告诉 Agent 怎么用这些工具完成实际工作；
- hooks：在生命周期事件里注入规则；
- subagents：处理特定类型的任务；
- LSP server：提供语言能力；
- 项目级的约定和工作流说明。
所以 Anthropic 特别强调，MCP 和 Skills 是互补的关系。MCP 解决的是“Agent 能访问什么”，Skills 解决的是“Agent 应该怎么使用这些能力”。
11. 插件打包模式（Plugin Bundle Pattern）
插件打包模式要解决的是分发问题。如果一个集成需要 MCP Server、Skills、hooks、subagents，但这些组件要分开安装、分开升级，就很容易出现配置漂移和版本不匹配的问题。Claude Code Plugins 提供了一种打包方式：把 Skills、MCP servers、hooks、LSP servers、specialized subagents 统一放进一个插件里进行分发。用户一次安装，就能获得完整的能力包。Cowork data plugin 就是一个典型例子：它包含 10 个 Skills 和 8 个 MCP servers，能连接 Snowflake、Databricks、BigQuery、Hex 等多种数据工具。这个模式的价值，是减少安装时的麻烦，也减少组件之间的版本错配。代价是，发布节奏会被绑定。一个 Skill 更新、一个 Server 更新、一个 hook 更新，都可能需要牵动整个插件的版本。但对用户来说，“一个插件就是一套完整的工作能力”，通常比“自己拼装十几个组件”要更省心、更自然。
12. 服务器分发 Skills 模式（Server-Distributed Skills Pattern）
最后一个模式要解决的是：Agent 有了工具的访问权，就真的会用这些工具吗？答案通常是否定的。一个 MCP Server 可以告诉 Agent 有哪些工具，但它不一定会告诉 Agent，在复杂的业务场景里，该怎么安全、高效地组合这些工具。比如一个 Sentry MCP Server 可以暴露 issue、trace、release、alert 等能力，但怎么排查线上错误、怎么判断错误的影响范围、怎么生成修复建议，这些更像是领域知识和操作手册。这就是 Skills 的价值所在。服务器分发 Skills 模式的核心是：由 MCP Server 直接分发和自身能力匹配的 Skills。客户端连接 Server 时，不只是获得工具，还能获得使用这些工具的操作指南。Anthropic 的文章里提到，Canva、Notion、Sentry 等已经在 Claude 中，把 Skill 和 connector 配对展示了。MCP 社区也在探索 server-distributed skills 的扩展，让这种能力可以跨客户端移植。这个模式还在不断演进，但方向很明确：未来的 MCP Server 不只是分发能力，还会分发使用这些能力的方法。这也意味着，Agent 集成的竞争点，会从“谁有工具”变成“谁能把工具、流程、经验和安全边界一起交付”。
结语
这些模式真正有价值的地方，不是告诉我们“MCP 很重要”，而是把生产级 Agent 集成中的工程问题，一个个拆解清楚了。比如连接在哪里运行、工具按什么粒度暴露、用户如何参与流程、凭证如何托管、上下文如何控制、能力如何打包分发。这些问题加起来，才是 Agent 从demo 走向 production 的真正门槛。生产级 Agent 不是简单地多接几个工具，而是要重新设计 Agent 和真实系统之间的连接层。MCP 的意义就在这里。它让每一个系统，都有机会为 Agent 提供一个更稳定、更安全、更可复用的产品交互面。随着更多客户端、Server、Skills 和协议扩展进入生态，这个交互面的价值还会不断叠加。如果你正在做 AI 工程化，或者准备把 Agent 接入企业内部系统，那么这 12 个模式值得你反复对照。不用一次全部实现，但每一个模式都在提醒我们：真正的 Agent 工程，不只是把模型接上工具，而是让工具真正走进生产。
