MCP 协议这两年算是 AI 圈子里绕不开的词了，尤其是做 AI 编程智能体（Coding Agent）的人，几乎天天跟它打交道。我自己的团队从 2024 年年底开始把内部的一个代码评审机器人往 MCP 架构上迁，到现在已经在生产环境跑了半年多，服务过十几个内部项目和外部客户，踩过的坑和沉淀下来的经验都不少。这篇文章就把我们从零构建商业级 AI 编程智能体的完整过程拆开来讲，包括 MCP 协议本身的定位、架构怎么设计、核心代码怎么写、生产环境怎么保证稳定性和安全性，以及在真实业务落地中遇到的典型问题。不管你是刚接触 MCP 想搞清楚它到底是什么的初学者，还是已经在做 Agent 产品、正在纠结架构选型的工程师，这篇都能给你一些实际的参考。
先回答一个很多人纠结的问题：MCP 的"协议"，到底是软件协议还是硬件协议那个概念？其实它跟 HTTP、WebSocket 一样，是应用层的软件协议，不是 PCIe、USB 那种硬件接口协议。很多人混淆是因为"协议"这个词在中文语境里横跨软硬件两个领域，但 MCP 全程是 Model Context Protocol，它做的事情完全是软件层面的——定义 AI 模型和外部工具、数据源之间怎么通信、怎么格式化消息。你不需要动任何硬件，只需要在代码层面实现一套通信规范就行。
1. MCP 协议到底是什么：先把这个概念掰扯清楚
1.1 协议的本质：软件协议还是硬件协议
先说结论：MCP 是纯粹的软件协议，而且是应用层协议。我们可以把它类比成 HTTP——HTTP 定义了浏览器和服务器之间怎么发请求、怎么返回响应、状态码什么意思；MCP 定义了 AI 应用（客户端）和外部能力提供方（服务端）之间怎么发现工具、怎么发起调用、怎么传参数和返回结果。
之所以很多人会问"这是硬件还是软件协议"，是因为他们看到协议列表里有 TCP、UDP、I2C、SPI 这类名字，这些确实是偏硬件底层的通信协议。但 MCP 完全不涉及物理层的信号、时序、电平这些东西，它跑在 TCP/IP 之上，用的是 JSON-RPC 这种轻量级的远程调用格式。所以你只需要用你熟悉的编程语言，写一个能接收 JSON 消息、处理请求并返回结果的服务进程，就算实现了一个 MCP Server。
这里有个细节值得注意：MCP 的设计哲学和 HTTP 有一个本质区别。HTTP 是"无状态"的，每个请求之间互相独立；而 MCP 是"有状态"的，它专门为对话场景设计。客户端和服务端建立连接后，会维持一个会话上下文，AI 模型在多轮对话中反复调用同一个工具时，服务端可以记住会话状态。这对编程智能体特别重要——因为一个真实的编码任务往往需要查询文件、修改代码、运行测试多个步骤连续执行，每一步的结果都可能影响下一步的参数选择。如果像 HTTP 那样每次调用都从头开始，智能体的效率会非常低。
1.2 MCP 要解决的真实问题
在 MCP 出现之前，让 AI 模型调用外部工具简直是噩梦。每个框架各有各的玩法：OpenAI 有 function calling，LangChain 有自定义 Tool 类，Hugging Face 的 transformers 有它自己的 tool 机制。你辛辛苦苦给 A 框架写的工具函数，换到 B 框架里全部要重写。更麻烦的是，工具和 AI 应用深度耦合，你没法独立地开发、测试、部署一个工具服务，然后让多个 AI 应用共享它。
MCP 做的事情就是把"工具提供方"和"工具消费方"解耦。打个比方：USB 接口规定了设备怎么和电脑通信，你买一个打印机，只要它是 USB 接口，就能插在任何电脑上，不用管电脑是 Windows 还是 macOS。MCP 就是 AI 领域的 USB——你可以独立开发一个 MCP Server（相当于打印机），提供文件操作、代码搜索、数据库查询、CI 触发等能力，任何支持 MCP 的客户端（相当于电脑）都能直接连接使用。
这个解耦对商业级产品的影响是深远的。我们团队的实际经验是：以前给客户交付定制化 Agent，每个项目都要重新对接客户内部系统，平均耗时两周；现在我们把客户的内部系统封装成标准 MCP Server，客户端侧几乎零改动，交付周期压缩到三天以内。这就是协议标准化的力量——它让分工和复用成为可能。
1.3 MCP 的核心架构组件
MCP 协议的架构其实非常简洁，一共就四个核心概念：
客户端（Client）：运行 AI 模型的一方，负责发起请求、维护会话状态。在编程智能体场景里，客户端通常是 IDE 插件、命令行工具，或者你自建的后台服务。
服务端（Server）：提供工具能力的一方。一个 Server 可以暴露多个工具（Tool），也可以暴露资源（Resource）和提示词模板（Prompt）。
工具（Tool）：最核心的抽象，本质上就是一个可被 AI 模型调用的函数。每个工具都有名称、描述、输入参数的 JSON Schema、输出格式定义。
传输层（Transport）：客户端和服务端之间的通信通道，官方支持两种：stdio（标准输入输出）和 Streamable HTTP。stdio 适合本地进程间通信，比如 IDE 插件拉起一个本地 Node 进程；Streamable HTTP 适合远程部署，比如把工具服务架在服务器上，让多个客户端通过网络访问。
理解了这四个概念，MCP 的面纱就算揭开了一大半。剩下的问题就是：怎么用这些组件搭出一个真正能用的商业级智能体？
2. 商业级 AI 编程智能体的架构设计
2.1 从单 Agent 到多 Agent 协作
很多人刚开始做编程智能体的时候，默认是一个 Agent + 一堆工具的模式。这种模式在 Demo 阶段完全够用，但一上生产就会出问题。核心矛盾在于：一个 Agent 的上下文窗口是有限的，而真实的软件开发任务需要同时处理代码搜索、依赖分析、测试执行、文档生成等多种能力，你不可能把几十个工具全部塞给模型，让它在每次决策时都从里面挑。
我们的做法是引入多 Agent 协作架构。具体来说，我们把智能体拆成三个角色：规划者（Planner）、执行者（Executor）和审查者（Reviewer）。
规划者负责理解用户需求，把它拆解成若干子任务，然后为每个子任务选择合适的执行者；执行者负责调用具体工具完成任务，它只需要关注自己负责的那一小块上下文；审查者负责检查执行结果，比如代码格式、测试覆盖率、潜在 Bug，不合格就打回重做。
这个架构的好处是可以把上下文切小——每个 Agent 只需要在一个专业领域内使用 MCP 工具，上下文利用率大幅提升。坏处是通信开销变大，Agent 之间的协调逻辑变复杂。我们的经验是：不要一上来就搞多 Agent，先单 Agent 跑通业务闭环，再按痛点拆分。我们第一版就是单 Agent，后来发现模型经常在"搜索代码"和"修改代码"之间来回切换导致上下文爆炸，才拆出了独立的执行者角色。
2.2 MCP Server 的设计原则
多 Agent 架构下，MCP Server 的数量会显著增加。我们生产环境里目前有 12 个 Server 在同时运行，覆盖代码搜索、文件修改、Git 操作、容器执行、HTTP 调用、数据库查询等能力。这么多 Server 要管理好，必须遵循几条设计原则：
第一，单一职责。一个 Server 只做一类事，不要搞"万能 Server"。我们把代码搜索和代码修改拆成两个独立 Server，因为两者的权限模型完全不同——搜索是只读的，修改需要写权限，混在一起会让权限控制变得非常困难。
第二，无状态优先。MCP Server 尽量保持无状态，所有必要的状态都通过参数显式传递。原因很简单：Server 被做成无状态之后，可以水平扩展，可以任意重启，也不容易出现会话错乱的诡异问题。我们需要状态的地方（比如记录整个任务上下文的仓库路径），都放在客户端侧维护。
第三，超时与并发控制。MCP 协议本身没有规定超时机制，但生产环境必须自己加。我们的做法是每个工具调用都设置 30 秒超时，超时后返回一个明确的错误信息给模型，让模型决定是重试还是换方案。并发方面，Server 侧用信号量限制最大并发数，防止某个高耗时工具把整个进程的线程池占满。
第四，可观测性。每个 Server 必须暴露健康检查和指标接口。我们统一用 Prometheus 格式输出 metrics，包括每个工具的调用次数、平均耗时、错误率、超时次数。没有这些数据，你根本没法定位生产环境的问题——这个后面展开讲。
2.3 工具调用的上下文管理
多 Agent + 多 Server 带来了一个棘手问题：上下文管理。MCP 工具调用产生的中间结果可能非常庞大，比如搜索代码返回了几百个文件路径，直接塞给模型会瞬间撑爆上下文。
我们设计了一套"分层上下文"策略。第一层是"概要层"，工具返回结果时先做一个摘要，比如"共找到 37 个匹配文件，按相关度排序前 5 个是……"；第二层才是"详情层"，模型主动要求查看某个具体文件的完整内容时才返回。这个策略在 MCP Server 侧实现起来并不复杂——工具返回结构化结果时带上一个 summary 字段，客户端根据 summary 决定是否拉取完整内容。
另外一个关键点是上下文裁剪。对话历史不可能无限累积，我们定期把旧的、已经完成子任务的对话回合压缩成摘要，只保留关键决策信息。比如"用户要求修复 login 模块的鉴权漏洞，Agent 已完成修复并通过测试"这一句话，就替代了几十轮对话记录。压缩策略的触发条件是总 token 数超过预设阈值，我们一般设为上下文窗口的 60%，留出余量给模型生成回答。
3. 核心实现细节与实操要点
3.1 快速搭建一个 MCP Server
先给出一段可以直接跑的示例代码，用 Python 实现一个极简 MCP Server，提供一个执行 Shell 命令的工具。这个工具在编程智能体里非常实用——让 Agent 能运行测试、执行构建脚本、查看环境信息。
我用的是官方 Python SDKmcp，安装方式很简单：
pip install mcp核心代码：
import asyncio import subprocess from mcp.server.models import InitializationOptions import mcp.server.stdio as stdio from mcp.types import TextContent, Tool async def run_command(command: str, timeout: int = 30) -> str: try: result = subprocess.run( command, shell=True, capture_output=True, text=True, timeout=timeout, check=False ) return f"exit_code: {result.returncode}\nstdout: {result.stdout}\nstderr: {result.stderr}" except subprocess.TimeoutExpired: return f"Command timed out after {timeout} seconds" async def main(): server = await stdio.create_server() @server.register_tool("run_command", description="Execute a shell command and return the output") async def handle_run_command(arguments: dict) -> list[TextContent]: command = arguments.get("command") timeout = arguments.get("timeout", 30) if not command: raise ValueError("command is required") result = await asyncio.wait_for(run_command(command, timeout), timeout + 5) return [TextContent(type="text", text=result)] await server.run( InitializationOptions( server_name="shell-tool-server", server_version="1.0.0" ) ) if __name__ == "__main__": asyncio.run(main())这个 Server 通过 stdio 跟客户端通信，启动命令就是python main.py。客户端侧用 MCP 的 Python 客户端连接后，就能自动发现run_command这个工具，获取它的参数 schema，然后发起调用。
有个细节要强调：工具的参数必须声明为 JSON Schema 格式，AI 模型会根据这个 schema 生成符合格式的参数。如果 schema 写得模糊，模型就很容易传错参数。比如command字段的描述应该写清楚：建议使用绝对路径、不要包含交互式命令、不要使用管道符等。我们实测下来，schema 描述写得越具体，模型调用的成功率越高。
还有一点非常经验的分享：不要把管理员的 shell 权限直接暴露给 MCP Server。上面这段代码在本地开发时没问题，生产环境必须要加白名单机制，限制可执行的命令范围。我们后面专门有一章讲安全，这里先留个悬念。
3.2 工具定义与 schema 设计
工具定义的细节直接决定智能体的智商上限。很多团队的第一版 MCP Server 工具写得很粗糙，模型经常误用。我梳理几个核心原则：
工具描述要写"何时使用"。不要只写"搜索代码"这种一句话描述，要写清楚适用场景和边界，比如："搜索代码仓库中的源代码文件。当用户需要定位某个函数定义、查找某个标识符的引用、寻找某个错误信息的来源时使用。此工具只搜索代码，不搜索文档和配置文件，如需搜索文档请使用 search_docs 工具。"
参数 schema 要用强类型和枚举约束。能列枚举值就列枚举值，不要用开放字符串。比如搜索范围的参数，可以定义为enum: ["workspace", "project", "file"]，模型就不太可能传一个乱写的值。
返回值要结构化。我们统一用 JSON 返回，并且字段设计成机器可读 + 人可读的混合结构。机器可读部分给模型做下一步决策用，比如matched_files: ["src/auth/login.py"]，人可读部分给最终报告用，比如summary: "找到 2 个匹配文件"。
时机问题：工具粒度是粗好还是细好。我们的经验是：同时提供粗粒度和细粒度的工具，让模型自己选择。比如我们既有read_file(path, offset, limit)这种细粒度读取工具，也有get_file_context(path, keyword, range)这种粗粒度工具——后者一次返回关键字附近的代码片段，省得模型先搜索再读取两步操作。实测中，模型在大多数场景会自动选择粗粒度工具，只有需要精确查看特定行时才用细粒度。
3.3 与主流框架的集成方式
现在主流的 AI 应用框架基本都支持 MCP，但集成方式有细微差异。我以我们实际用过的两个场景为例说明。
LangChain / LlamaIndex 场景：这两个框架都提供了load_mcp_servers之类的工具加载函数，它会连接你指定的 MCP Server，把注册的工具转换成框架自己的 Tool 对象。这个转换过程通常发生在 Agent 初始化的时候，所以你要保证 MCP Server 在客户端启动前已经就绪。如果 Server 是远程的，还需要处理好鉴权——框架一般支持在连接时传入 headers，你可以把 API token 放在里面。
自建 Agent 循环场景：如果你跟我一样，最终选择了自建 Agent 循环（不用 LangChain 这类高层框架），那集成方式就更直接。你只需要实现一个 MCP 客户端，在每次 Agent 决策循环中做三件事：查询可用工具列表、把工具描述拼进系统提示词、拦截模型输出的工具调用请求并转发给对应 Server。这个流程用官方 Python SDK 也就一百多行代码。我们最终选择了自建方案，原因很简单：高层框架对我们的多 Agent 架构限制太多，自定义程度不够。
这里给一个代码层面的建议：把所有 MCP 客户端封装成统一接口，不管底层用的是 stdio 传输还是 HTTP 传输，对上层业务代码都暴露一个名为call_tool(server_name, tool_name, arguments)的方法。这样切换传输方式或者增加新 Server 时，业务代码完全不用动。我们就是靠这个抽象，在迁移阶段省了大量重构工作。
4. 商业级落地的关键考量：稳定性、安全与成本
4.1 稳定性设计与降级策略
商业级产品和 Demo 的最大区别就是稳定性。我们遇到过的最典型的问题：MCP Server 进程崩溃、工具调用超时、服务端返回格式不符合约定。针对这些问题，我们有几套完整的策略：
进程守护。所有 MCP Server 都运行在 systemd 或 Docker 容器中，配置自动重启策略。同时挂了探活接口，30 秒探测一次，如果连续三次失败就告警并自动拉起新实例。
故障隔离。某个 Server 崩溃不能影响其他 Server 和客户端主流程。我们用的是多进程部署：每个 Server 独立进程，进程间通过消息队列通信。这样即使最核心的代码搜索 Server 挂了，用户的会话也不会中断，只是暂时无法使用搜索功能。我们在产品里给这种情况设计了降级路径——模型会提示用户"搜索服务暂时不可用，是否改用文件遍历方式？"
超时重试与熔断。不同工具设置不同的超时阈值：读文件 10 秒、搜索代码 20 秒、执行测试 60 秒、部署操作 120 秒。连续失败超过 5 次就触发熔断，暂时屏蔽该工具，防止模型反复调用同一个坏工具浪费 token。熔断后 30 秒自动半开，允许少量探测请求，成功则恢复。这套机制参考了微服务领域的熔断模式，在 MCP 场景下完全适用。
幂等设计。能幂等的操作全部设计成幂等。比如"创建分支"这个工具，如果分支已存在就直接返回成功；"设置文件内容"就比"追加文件内容"更好做幂等。原因在于：AI 模型在收到超时响应后，经常会自动重试同一个调用，如果工具不是幂等的，就会造成重复执行。我们线上出过一次事故：Agent 连续重试"部署服务"工具三次，直接把测试环境打崩了。那之后我们要求所有写操作工具必须实现幂等。
4.2 安全与权限控制
编程智能体是拿着代码仓库最高权限的"AI 员工"，安全设计绝对不能含糊。我们花了大量精力在权限体系建设上，核心是三个层级的控制。
第一层：工具级白名单。不是所有暴露给 MCP 的工具都能被模型自由调用。有些高危操作（比如删除分支、推送远程、修改生产配置）默认不注册给模型使用，而是通过内部接口调用；只有模型先触发了某个审批动作，客户端才会临时放开对应工具的调用权限。
第二层：资源级权限。用细粒度 ACL 控制 Server 能访问的路径。比如代码搜索 Server 只能读/data/repos/目录，数据库 Server 只能连dev和staging两个环境，绝不能连生产库。实现方式是在 Server 启动参数里传入允许路径列表，工具函数内部做前缀校验。
第三层：审计日志。每次工具调用都必须记录：调用者、使用的 Server/工具、参数摘要、返回结果的 hash、耗时。我们曾经遇到一个问题：开发环境的一条数据被误改了，通过审计日志回溯，发现是模型在测试一个"批量更新"功能时把参数写错了。没有审计日志，这种问题根本无法定位。
还有一个经常被忽略的细节：MCP 传输层的加密和鉴权。本地 stdio 传输不需要加密，但远程 HTTP 传输必须走 TLS，并且要求每个请求都带访问令牌。我们用的是双向 HTTPS + 短期 token，token 有效期 10 分钟，由客户端启动时向内部认证服务申请。密钥管理用 Vault，不在任何配置文件和代码仓库里存放明文密钥。
4.3 成本控制与性能优化
AI 编程智能体的成本大头是模型 token 消耗，MCP 在其中扮演的角色很关键——它决定了模型能看到什么、调用多少次。控制成本的策略有很多，我们实践下来最有效的是四条。
减少无效搜索。编程智能体最常见的资源浪费是盲目搜索。很多模型的默认行为是：收到任务先全局搜索一遍代码，哪怕这个任务只需要改一个已知位置的配置。我们在工具设计上加了"意图相关性"提示词，告诉模型：如果用户提供了明确文件路径，直接用文件读取工具，不要搜索。就这一条优化，token 成本下降了大约 20%。
压缩工具返回结果。我们已经讲了概要层的用法，这里补充一个具体指标：默认所有工具返回结果超过 2000 字符时，自动截断并附上截断说明。模型需要更多内容时会主动请求分页加载。这条策略把平均每次调用的 token 消耗降低了三分之一。
缓存高频调用结果。有些 MCP 工具是"只读查询且结果相对稳定"的，比如查看项目的依赖树、读取配置文件。我们给这类工具加了内存缓存，TTL 设为 60 秒。模型在同一个任务里多次查询时，直接从缓存返回，既不消耗 Server 资源，也不多耗模型 token（因为 MCP 返回内容本来就进了上下文）。
模型分层。不是所有子任务都用同一个大模型。规划者用最强的模型，执行者可以降级用中等模型，审查者用中等模型就够了。我们粗略估了一下，如果所有子任务都用最强模型，成本是分层的 2.5 倍以上，而效果差异其实很小。
5. 常见问题与排查技巧实录
5.1 典型问题速查表
我直接把我们生产环境中积累的问题按场景整理成一个速查表格，每个问题后面附上解决建议。
| 问题现象 | 可能原因 | 处理思路 |
|---|---|---|
| 模型频繁调用某个工具但结果不符合预期 | 工具描述写得太模糊，模型对适用场景判断错误 | 重写工具描述，增加"何时使用/何时不使用"的明确说明 |
| MCP Server 连接后工具列表为空 | Server 未正确注册工具，或注册代码在初始化之后才执行 | 检查 register_tool 装饰器位置，确保在 run 方法前完成注册 |
| 工具返回内容过大撑爆上下文 | 没有做概要层截断或分页 | 实现 summary 字段 + 分页加载机制 |
| 工具调用超时频发 | Server 处理能力不足或单个操作耗时过长 | 排查 Server 的并发限制，为耗时操作设置合理超时并支持取消 |
| 模型重复调用同一个失败操作 | 返回的错误信息不够明确，模型无法判断该换方案 | 错误信息中附带建议，如"文件不存在，请检查路径或尝试 search_code 工具" |
| 多 Agent 并行执行时资源竞争 | 多个执行者同时调用同一个写操作工具 | 在 Server 侧实现分布式锁，同一个 key 同时只允许一个写操作 |
这些问题的共性本质是：你设计的工具接口没有匹配模型的行为模式。MCP 的工具不是给人用的 API，是给模型用的 API——模型的理解方式跟程序员完全不同，它对模糊描述和隐式约定的容忍度极低，你必须把一切说得清清楚楚，连"什么时候不该用这个工具"都要写进描述里。
5.2 排查思路与工具链
遇到 MCP 相关问题时，我们有一套固定的排查流程，按顺序走一遍基本能定位。
第一步，看 MCP 层日志。官方 SDK 会输出客户端和服务端的通信日志，包括请求参数、响应结果、错误堆栈。这些日志默认可能没打开，需要设置MCP_LOG_LEVEL=debug环境变量。从这里你能快速判断问题是出在通信层还是工具内部逻辑层。
第二步，手动调用复现。如果明确了是某个工具的问题，我们用mcp-cli这类交互工具直接连上 Server，手动构造参数发起调用，绕过 AI 模型，快速定位是工具本身有 Bug 还是模型传参有问题。这个步骤非常高效，比反复跟模型对话调试节省时间。
第三步，检查 metrics 指标。我们在监控面板上能看到每个工具的错误率、P99 耗时、调用数量。如果错误率暴涨或耗时突增，大概率是上游资源（比如代码仓库、数据库）的问题，而非 MCP 层的问题。
第四步，回放审计日志。审计日志能告诉你模型在什么语境下调用了工具、传了什么参数、获得了什么结果。很多"模型行为异常"的问题，在审计日志里一看就明白——比如模型没传关键参数，或传了超出预期的危险值。
5.3 我踩过的几个坑
最后分享四个我们真实踩过的坑，每一个都让团队付出了不小的代价。
第一个坑是把所有工具塞进一个 Server。第一版产品图省事，把 30 多个工具全部放在一个 Server 里。上线后这个 Server 频繁因为某个工具的 Bug 崩溃，导致所有能力一起不可用。后来拆成 12 个独立 Server，故障隔离后可用率从 92% 提升到了 99.5% 以上。教训是：拆分看似增加部署复杂度，其实是保命的最低成本。
第二个坑是没有处理 MCP 的初始化握手。MCP 客户端连接 Server 后，要通过 initialize 请求确认协议版本和能力列表。我们有一次升级 SDK 后忘了检查版本兼容性，导致生产环境里一部分旧客户端连不上新 Server。排查了整整一天才找到原因。现在我们的规范是：客户端和服务端的 MCP SDK 版本统一固定，升级必须走完整回归测试。
第三个坑是让模型直接操作真实数据库。我们的数据服务 Server 最初允许模型直接执行 SQL，结果模型在一个测试任务中误删了一张临时表的数据。虽然最终恢复回来了，但这个事故彻底改变了我们的设计：之后所有数据库操作都走受控的 API 封装，比如"按条件查询用户"、"新增订单"这种精细化工具，不再开放原始 SQL 能力。降低模型的自由度会牺牲一些灵活性，但这是商业级产品必须做出的权衡。
第四个坑是忽视了超大返回值的处理。代码搜索工具曾经返回过 3000 多个匹配文件，这个 JSON 序列化后接近 200KB，直接把模型上下文窗口撑爆，客户端直接报了上下文长度超限的错误。那次我们从底层重构了返回逻辑，强制所有工具先返回 top N 结果，并附带获取全部结果的专用工具。从此再也没出现过这个问题。
写在最后的一点心得
MCP 协议本身不复杂，一个下午就能读懂规范。但真正把它做成商业级产品，考验的是你在协议之外的设计能力——权限模型、稳定性保障、成本控制、上下文管理，这些都是协议文档里不会写、但生产环境逃不掉的东西。
我个人做下来最大的体会是：MCP 只是给了你一个标准化的插槽，插槽里的工具怎么设计，才是决定智能体智商和可靠性的关键。把工具当作给模型用的产品来打磨，描述写清楚、参数约束严、返回值结构化、有降级有审计，你的智能体就已经超过了市面上大半的 Demo 项目。
最后分享一个我们正在做的小改进：把每个 MCP 工具的使用效果数据收集起来，统计哪些工具被频繁使用、哪些工具模型总是传错参数，然后反向优化工具描述和 schema。这个闭环做起来之后，Agent 的稳定性还在持续提升。MCP 生态还在早期，工具质量的差异化空间非常大，这恰恰是现在入场的人和团队最大的机会。
