第 11 章：为什么 Agent 需要一层协议来接外部世界
本章目标：讲清外部能力接入为什么不能靠随手硬连，MCP 这类协议层到底在解决什么问题，以及它在 Agent 系统里扮演什么位置。
本章对应总纲：docs/ebook-outline.md中“第 11 章正文写作提纲（2026-03-31 归档）”。
11.1 为什么 Agent 不可能永远只活在本地世界里
如果一个 Agent 只能在自己的上下文里推理，却无法接触外部世界，那它的行动能力很快就会撞墙。
现实任务天然会要求它接入外部能力，例如：
- 读数据库
- 调业务 API
- 查第三方服务
- 操作浏览器
- 访问远程资源
- 和其他系统交换结构化信息
所以只要 Agent 真想做事，而不是只想解释，它就迟早要面对一个工程问题：
怎么把外部能力稳定、安全、可复用地接进来？
这才是协议层开始变得重要的地方。
11.2 为什么“直接连 API 不就完了”通常不够
最朴素的想法当然是：
- 需要什么能力
- 就直接接一个 API
- 模型直接调它
听起来很简单。
问题是，系统很快就会被一堆具体麻烦拖住：
- 每个服务接口风格不一样
- 认证方式不一样
- 错误格式不一样
- 参数约束不一样
- 生命周期不一样
- 权限边界不一样
然后你会发现自己不是在做 Agent，而是在不停写胶水层。
所以真正的难点不是“有没有外部能力”，而是：
外部能力能不能被系统用统一方式理解、暴露、调用和治理。
11.3 协议层解决的，本质上是标准化问题
当外部能力越来越多时，系统最需要的不是再加一个个 ad-hoc 集成，而是一层统一协议来把差异收拢。
一层协议通常会统一几件事：
- 能力如何声明
- 工具如何暴露
- 参数如何描述
- 返回结果如何表达
- 错误如何表达
- 认证和连接如何处理
这层东西的价值，不在“更高级”，而在于它让系统终于不用对每个外部服务都单独长一套脑子。
这就是协议层的现实价值。
11.4 MCP 这种东西，到底在系统里扮演什么角色
把名字先放一边，最重要的是它在结构中的位置。
MCP 这类协议，本质上是在 Agent 系统和外部能力之间放了一层标准接口。你可以把它理解成：
它不是外部能力本身，而是外部能力进入 Agent 系统的标准接入面。
这个定位很重要。
因为它意味着：
- Agent 不需要为每个外部系统单独写一套交互习惯
- 外部能力可以以更统一的工具形式暴露出来
- 系统可以在更高层统一做权限、发现、调用和约束
所以 MCP 的意义，不是“又多了个技术名词”，而是把接入问题从一次次硬编码，提升成一层可复用协议。
11.5 为什么协议层对模型也有直接帮助
前面讲过，模型不是靠读源代码理解工具，而是靠接口描述和上下文去判断工具怎么用。
协议层一旦存在，对模型最直接的帮助就是：
- 工具描述更统一
- 参数结构更稳定
- 返回格式更可预期
- 错误信号更容易被识别
这会直接影响：
- 工具选择质量
- 参数生成质量
- 反馈解释质量
- 跨服务使用时的一致性
所以协议层不是纯后端工程问题，它会直接反映到 Agent 的动作质量上。
11.6 协议层不只解决接入，还解决治理
如果外部能力只是能接上，那还只做了一半。
真正成熟的系统还要治理这些接入能力，例如：
- 哪些服务可见
- 哪些工具可用
- 哪些动作需要授权
- 哪些连接方式更安全
- 认证信息怎么管理
- 出错时怎么退回系统主流程
所以协议层还有一个经常被低估的价值：
它给了系统一个统一治理外部能力的抓手。
没有这层抓手，接入越多，系统越散。
11.7 外部能力接入里，最容易被忽视的三种风险
11.7.1 能力边界失控
如果外部工具暴露过宽，系统可能会比你以为的拥有更大行动能力。
11.7.2 认证边界失控
一旦接入真实服务，认证、令牌、账户权限这些问题都会进来。这里不是文风问题，是安全问题。
11.7.3 错误边界失控
外部系统会超时、拒绝、限流、返回脏结果。
如果这些错误不能被稳定接住，Agent 的闭环就会被外部世界拖垮。
所以外部接入不是“工具更多了”，而是系统边界突然变复杂了。
11.8 为什么 MCP 这类协议不是万能药
说清楚一点：协议层很重要，但它不是魔法。
它不能自动解决这些问题：
- 你到底该暴露哪些外部能力
- 哪些能力不该让模型直接调用
- 哪些结果该如何进入主流程
- 哪些连接在业务上根本没必要
也就是说，协议层解决的是“怎么标准化接入”，不是“接什么都合理”。
如果系统设计本身没品味，协议层也只能把混乱标准化，而不是把混乱变正确。
11.9 用 Claude Code 看一个现实中的协议层样本
Claude Code 这种系统很适合拿来理解这一层，因为它并没有把外部能力接入做成一堆彼此孤立的硬编码脚本。
从当前仓库和运行环境就能看到几个很具体的信号：
- 当前工具环境里 MCP 能力有独立命名空间，例如资源列举、资源读取、认证启动、文档查询、Figma、Chrome DevTools、Gmail、Google Calendar 这些都不是和本地文件工具混成一锅
plugins/README.md里的标准插件结构把.mcp.json单独列出来，说明外部能力接入在平台里本来就被当成一层独立接口，而不是顺手塞进命令正文examples/settings/settings-strict.json又展示了另一面：即使接入能力标准化了，系统仍然要在更高层配置deny、审批和沙箱约束，说明协议层解决的是“怎么统一接”，不是“接进来就一定能放开用”
你能看到它把 MCP 作为一类独立能力来对待：
- 有专门的工具命名空间
- 有独立的资源列举和读取机制
- 有认证接入流程
- 有和本地工具并列的能力入口
这说明现实里的 Agent 系统一旦开始接外部世界，就很自然会需要一层独立的协议与治理结构，而不是无限堆 ad-hoc 集成。
11.10 什么时候你真的该上协议层
不是所有项目一开始都必须搞协议层。
但通常出现下面这些信号时，就说明已经值得考虑了：
- 外部能力来源越来越多
- 不同服务接入风格差异很大
- 工具描述和调用方式开始不一致
- 认证和权限管理越来越麻烦
- 你开始为每个新接入都重复写同一类胶水逻辑
一旦这些信号出现，继续 ad-hoc 扩展只会让系统越来越难维护。
这时上协议层不是炫技，而是止损。
11.11 本章小结
这一章真正想讲清的是：Agent 接外部世界，难点从来不只是“能不能连上”，而是“能不能统一地接、稳地接、管得住地接”。
你现在应该记住六件事：
- 现实 Agent 迟早都要接外部能力。
- 直接硬连 API 很快会把系统拖进胶水地狱。
- 协议层的核心价值是把能力声明、调用、返回和错误处理标准化。
- MCP 这类协议，本质上是 Agent 和外部能力之间的标准接入面。
- 协议层不仅解决接入问题，也提供外部能力治理的抓手。
- 协议层不是万能药，但当外部接入足够复杂时，它往往是必要的止损层。
下一章我们继续往下走，讲一个常被低估但越来越重要的问题：配置。不是那种无聊配置文件导览，而是为什么配置其实在决定一个 Agent 系统运行时能看到什么、能做什么、该怎么做。