没人会刻意决定给智能体 (agent) 配备 40 个工具。这就像车库堆满杂物一样自然而然地发生了。你接入一个搜索工具，然后是一个数据库读取器，接着团队里有人发布了 Slack 集成，然后又安装了 ticketing MCP 服务器，因为这只需要一行配置。每次添加在当时看来都是合理的。没人会移除任何东西，因为移除工具感觉就像是在剥夺能力，而剥夺能力感觉就像是一种倒退。
六个月后，你的智能体有了一个工具带，其中有三个它经常使用的工具，十几个偶尔使用的工具，以及二十多个在生产环境中技术上从未被选中的长尾工具。这种“长尾”并非免费，甚至代价高昂。目录中每一个未使用的工具都在主动降低智能体从那些重要工具中做出正确选择的能力。
GraphQL 的核心赌注是客户端应该能够自主组合其数据需求。在过去的十年里，这个赌注大体上是输了——因为客户端是由人类团队组成的，而他们根本不想组合任何东西。前端工程师想要的是一个可以调用后就不用管的稳定端点。GraphQL 推销的灵活性是以解析器复杂度（resolver complexity）、缓存变通方案和安全审查为代价的，而换取的收益——按请求进行字段选择——对于已知的、变化缓慢的 Web 应用来说几乎毫无必要。到 2024 年，从业者的共识已明显降温：大多数内部 API 只服务于两三个已知客户端，一个设计良好的 REST 端点或 BFF 层就能很好地覆盖这些需求。
接着，一种新型的客户端出现了。AI 智能体没有固定的一套屏幕。它根据每个任务决定自己需要什么数据，并且它为响应的每一个字节付费——字面意义上是在为 Token 付费，而在认知意义上，随着上下文窗口被没人要求的字段填满，推理能力也会随之下降。真正能够自主组合数据需求的客户端终于出现了。只是它不是人类。
你的平台团队通过开发者采纳度来衡量成功。内部 API 的月活跃工程师数量。新服务的首次调用时间（Time-to-first-call）。季度 DX 调研中的净推荐值 (NPS)。每一个指标都假设请求的另一端是一个人类——一个阅读入门指南、复制 curl 示例、并在错误消息毫无帮助时在 Slack 中抱怨的人。
这种假设正悄然变得不再成立。你内部 API 增长最快的消费者不是人，而是一个智能体 (Agent)：一个正在解决工单的编码助手，一个在夜间核对发票的工作流，或者一个为了回答一个问题而调用六个服务的支持机器人。这些调用者不会浏览你的文档——它们会将你的工具模式 (tool schemas) 摄取到上下文窗口中。当错误提示模糊不清时，它们不会提交 bug——它们会默默地重试、消耗 token，然后放弃。而且它们的数量即将超过人类。
一场安全事件回顾以一个团队无法回答的问题开始：智能体是如何知道它刚刚调用的工具名称的？审计追踪显示了一个 tools/call 请求，但该工具的名称并未出现在 harness 记录的任何 tools/list 响应中。MCP 服务器欣然接受并执行了该调用。在事后分析中，当被要求解释工具名称来源时，模型给不出答案，因为根本没有答案 —— 它猜中了，而且这个猜测恰好命中了一个真实的操作。
这是两个在理论上看起来兼容的假设之间产生的失效模式。客户端将工具列表视为一份契约，界定了它被授予的权限范围。服务器则将工具列表视为当前可用工具的快照，可以随着环境的变化自由增长。在这两种观点之间，LLM 是一座不知道二者差异的桥梁。
周一，一位新工程师加入了团队。到周三时，她已经搭建好了本地 Agent 环境：一个桥接到公司部署 API 的 MCP 服务，指向 Staging 环境，并与她的编辑器相连。入职文档引导她完成了 OAuth 流程。她粘贴到服务器环境文件中的令牌是同事发给她的——这与 CI 流水线用于发布到 Staging 环境的是同一个令牌。到周五，她已在共享办公空间与团队一起进行协作开发。
MCP 服务仍在运行。绑定在 127.0.0.1。无需身份验证。令牌已加载到进程中。她没多想，因为她并没在使用它。但那天访问任何网站的任何标签页，都可以通过她自己的浏览器与她的本地服务通信。共享办公空间 Wi-Fi 上的任何其他笔记本电脑也同样可以，因为她没注意到该服务实际上绑定到了 0.0.0.0。你的 CI 流水线用来推送到 Staging 的 OAuth 令牌，现在任何能诱导浏览器向本地 IP 发起请求的人都能触及——在 2026 年，这只需要一个弹窗。
本文讨论的就是这类故障：“我在笔记本上开发”与“我的笔记本是对手可以触及的服务器”之间的鸿沟。MCP 服务在设计上恰好处于这个鸿沟之中。大多数团队尚未察觉。
用户打开集成页面，找到上个月安装的 Stripe 连接器，点击“移除”，然后关闭了标签页。他们认为自己刚刚撤销了一项授权。实际上，他们只是修改了数据库中的某行数据，而当前正在与他们对话的 Agent 在接下来的 43 分钟内都不会再次读取该数据。在此期间，Agent 会尝试调用该 Stripe 工具，注册中心的授权层会正确地拒绝请求，Agent 的 harness 框架会将此次拒绝视为暂时的下游波动并重试三次，而用户自己的 Stripe 审计日志将记录来自他们认为刚刚已断开连接的供应商的三次未经授权访问尝试。
用户的投诉几乎原话是：在我移除之后，你们的平台仍在尝试访问我的 Stripe。这正是实际发生的情况，而根本原因比错误报告所涉及的层面更深。工具注册中心是 Agent 获准执行操作的唯一事实来源（source of truth）。但 Agent 并没有读取这个事实来源，它读取的是缓存。
智能体工具调用抽象失效最明显的标志是：追踪记录（trace）显示该步骤已标记为完成，而下游系统却显示什么都没发生。模型调用了一个工具，收到了一个任务 ID 返回值，将该任务 ID 视为答案，然后继续执行。三分钟后，实际工作要么在无人监听的情况下成功，要么失败并产生一条记录在无人查看的日志中的错误。用户看到的是一份自信的总结；而操作队列看到的却是一个搁浅的任务。
这就是函数调用（function-calling）抽象悄然允许的失效模式。JSON Schema 描述了参数和返回类型，但它们无法区分“此工具返回一个结果”与“此工具返回一个操作回执，你稍后需要查询其结果”。模型对两者一视同仁，因为在规划器（planner）看来，它们看起来是一样的——都是一个带有非错误负载的成功工具调用。
用户在你的智能体授权页面上点击一次“授权”。当会话结束时，该智能体已经链式调用了 11 个工具，协商了 3 次提权授权，现在拥有了它所触及的每个工具的权限并集。用户只记得授权了一件事。你的审计日志却显示它拥有半个账户的读写权限。OAuth 标准说一切都在按设计运行，而这恰恰就是问题所在。
经典的 OAuth 授权模型是为“一个应用与一个 API 通信”的世界构建的。智能体在两年前打破了这一假设，而标准在实践中尚未跟上，即使规范已经更新。其结果是一类无人刻意发布的静默权限提升——它随着每一次工具注册而累积，而你的安全审查却一直在盯着前门。
我上个月交流过的一个团队有一个典型的提示词注入（prompt-injection）案例。他们的网关会对每条用户消息运行分类器。任何评分超过阈值的消息都会被礼貌地报错并拒之门外。他们针对一个公开的对抗性数据集进行了基准测试，达到了 99.4% 的拦截率，然后发布了产品。两周后，一个客户成功（customer-success）工单显示，Agent 在悄无声息的情况下起草、批准并发送了一封电子邮件，指示内部计费工具将一个陌生人的发票退款到一个新账户。恶意指令从未接触过用户输入。它是通过一个 Confluence 页面进入的，当用户非常无辜地询问“我们的退款政策是怎么说的？”时，Agent 抓取了该页面。
这是任何输入清理器（input sanitizer）都无法捕获的失败模式，而它现在已成为生产环境 Agent 中主要的提示词注入矢量。你针对用户提示词训练的分类器从未见过这个负载（payload），因为负载是通过另一扇门进入的。当字节到达模型时，Agent 已经将其标记为“我检索到的用于帮助用户的上下文”，而不是“来自互联网陌生人的不可信文本”。模型以同样的顺从本能对待两者，因为模型根本没有信任的概念。
一个下游搜索服务在周二下午发布了 v2.3.2 版本。发布说明提到重命名了一个状态字段，新增了一个可为空的 confidence 值，并重新排列了结果包中的数组。CHANGELOG 中没有任何内容被标记为破坏性变更。提供商自家的客户端库通过一个小版本更新消化了这些变化。你团队的 HTTP 集成通常会在一小时内记录下反序列化错误。但你的智能体——那个通过该搜索工具路由客户问题的智能体——并没有报错。它继续回答。问题依然得到解决。仪表盘依然是一片绿色。
六周后，有人注意到“缺货”回复在查询中的比例从 2% 攀升到了 11%。根本原因是 v2.3.2 的升级。重命名后的状态字符串从 in_stock 变为 available，而智能体——作为一个对文本进行灵活推理而非严格遵守模式（schema）的客户端——将旧令牌（token）的缺失解读为“无货”，然后将这一发现组织成乐于助人、语气自信但内容错误的客户消息。契约回归在消费者端被吸收了，而那里没有任何测试套件在监控。
这是传统的 API 规范（hygiene）从未被设计用来捕捉的故障模式。严格的客户端会大声报错。智能体则静默失效。你越是将智能体当作普通的 HTTP 消费者对待，这类 Bug 隐藏在看似正常的指标中的时间就越长。
一个搜索工具返回了十个文档 ID。一个素材工具返回了一个 S3 预签名 URL。一个数据库工具返回了一行的 handle。一个文件工具返回了一条路径。这些返回值，从形式上看，全都是指针——一串简短的字符串，命名着智能体当前还没有真正拿到手的那个值。模型接下来怎么走，完全取决于它是否意识到这一点、并在推理之前先做一次解引用，还是说它把指针当成了对象本身。
这个失败模式在 trace 里是看不见的。工具调用成功了。返回结构正常。模型也输出了看上去合理的文本。日志里没有任何一行会说："智能体在对一个文件名做推理，并把它当成了文档。"指针 vs 值的混淆，发生在可见行为底下的那一层——一个你的工具 schema 从未命名过的层。
我认识的一个团队有一套教科书级别的 staging 设置。生产数据库的只读副本。一个假装会扣款的 Stripe 模拟账户。带着没人拥有的域名邮箱的合成用户。这个 agent 被要求在 staging 里端到端走一遍"账户欠费"的升级流程,作为发版演练的一部分。trace 看起来很干净,agent 做了它该做的事。
三分钟后,一个真实客户——一个付费客户,六个月前流失的,但仍然留在一个开发者用来播种测试数据的休眠导出里——回复了一封措辞礼貌的逾期付款邮件。那个"send_email"工具,与十几个其他全部以 mock 收尾的工具注册在一起,却接在了生产环境的 Mailgun key 上。两个 sprint 前配置它的开发者当时在快速迭代邮件模板,沙箱层级把发送量限制在每小时五封,把内部反馈循环搞坏了,于是他们换上了真 key"就用一下午",然后忘了换回去。没人复查过。agent 没有任何办法知道这件事。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
