系列第五篇。上一篇讲任务流怎么断得起、接得上。这一篇讲“可扩展”：每接一个新系统，为什么不用改 Agent 核心代码。还是用高中生能懂的例子。

0. 先看一个真实的头疼场面

你的 Agent 已经上线，能开人事证明了。老板说：

“下周把班车查询也接进来，再下周把工单提交接进来，还有业务接口人检索。”

你打开代码一看，发现当初写的时候，开证明的逻辑和 Agent 核心是焊死的：

if 用户要开证明:    问证明类型    问用途    问含不含奖金    调人事接口    渲染证明卡片elif 用户要查班车:    问线路    问时间    调班车接口    渲染班车卡片

每加一个场景，就得在核心代码里加一个elif。加三个场景，代码变成一坨；改一处，可能把别的场景改坏。

生活类比：你家墙上只有一个插座，每添一个电器就得把墙凿开重新接线。加一个电器凿一次墙，迟早把墙凿塌。

这一篇讲的就是：怎么把墙改成标准插座，让新电器插上就能用，不用凿墙。

1. 先把三个词讲清楚

1.1 Tool（工具）

一句话：Agent 能调用的一项能力，有名字、有说明、有参数格式。

生活例子：工具箱里的螺丝刀，标签写着“十字螺丝刀，用于拧十字螺丝”。Agent 看到标签，才知道什么时候该拿它。

在 Agent 里：开人事证明是一个工具，查班车是一个工具，提交工单也是一个工具。每个工具都有“叫什么、干什么用、要什么参数”的说明。

1.2 插件化（Plugin）

一句话：把每个能力做成一个独立的小零件，能随时装上、卸下，不影响其他零件。

生活例子：手机充电器。你换手机，不用换整面墙的电路，换个充电头就行。充电头就是插件。

在 Agent 里：班车查询做成一个插件，装上就能用，卸下也不影响开证明。新场景上线，只装新插件，不动核心。

1.3 MCP

一句话：Model Context Protocol，一个让“工具提供方”和“Agent 使用方”用统一格式对接的协议。类似 USB 接口标准。

生活例子：USB。以前每个设备一种接口，鼠标一种、键盘一种、U 盘一种；现在都做成 USB，插上就能用。MCP 就是 Agent 世界的 USB 标准。

关键点：MCP 解决的是“工具怎么标准化接入”，不解决“流程怎么控”（那是状态图的事）。它让工具像 USB 设备一样即插即用。

一句话总结：Tool 是能力，插件化是“能装能卸”，MCP 是“统一接口标准”。三个词合起来，就是“新场景插上就能用”。

2. 不插件化会怎样：三种死法

死法一：核心代码变成“elif 地狱”

每加一个场景加一个elif，代码越来越长，越来越难读。新人接手，看三天看不懂。

生活类比：一个抽屉里塞满了各种充电线，每次找线都得翻半天。

死法二：改一处，坏三处

开证明和查班车共用了一段代码，你为了加班车改了一行，结果开证明坏了。因为你不知道这段代码还有谁在用。

生活类比：老房子电路，你想换个灯泡，结果一拧，全屋跳闸。

死法三：联调成本高到离谱

每接一个新系统，都要改 Agent 核心、重新测试、重新上线。3~5 人日一个场景，接十个场景就是一个月。

生活类比：每买一个新电器，都得请电工来凿墙接线，买十个电器请十次电工。

一句话总结：不插件化，就是“核心代码越写越乱、改一处坏三处、接一个场景请一次电工”。

3. 插件化 Tool：把能力做成标准零件

3.1 一个标准 Tool 长什么样

一个工具要能被 Agent 正确使用，必须说清四件事：

{"名称":"开人事证明","描述":"为用户开具在职、收入等人事证明，需要用户确认后调用","参数":{"证明类型":{"类型":"枚举","可选值":["在职证明","月收入证明","年收入证明"],"必填":true},"用途":{"类型":"枚举","可选值":["旅游签","探亲签","商务签"],"必填":true},"是否含奖金":{"类型":"布尔","必填":false}},"权限":"仅本人可开","超时":"5秒"}

生活类比：电器说明书。写清“这是什么、怎么用、要注意什么”，用户才不会用错。

关键点：描述写得好不好，直接决定模型会不会用错。描述含糊，模型就可能在不该调的时候调、传错参数。

3.2 工具层统一做四件事

上一篇讲过“脏活累活收在一处”，这里展开。所有工具调用都走同一个入口，统一做四件事：

参数校验：类型对不对、枚举值合不合法、必填项有没有；

权限校验：这个用户能不能用这个工具；

超时兜底：接口 5 秒没回就返回超时，不无限等；

启停控制：这个工具现在是开还是关。

def 调工具(工具名, 参数, 用户):if not 工具已启用(工具名):return {"状态": "失败", "可行动错误": "该功能暂未开放"}if not 参数合法(工具名, 参数):return {"状态": "失败", "可行动错误": "参数不合法，缺少：用途"}if not 有权限(用户, 工具名):return {"状态": "失败", "可行动错误": "无权限"}try:return 实际调用(工具名, 参数, 超时=5秒)    except 超时:return {"状态": "失败", "可行动错误": "接口超时，请稍后重试"}

好处：新工具一注册，自动继承这四件事，不用每个工具重写一遍。

生活类比：小区门禁。不管你是快递员还是访客，都得过同一道门禁，保安统一检查。工具层就是 Agent 的“门禁”。

3.3 插件化怎么做到“新场景不改核心”

关键设计：核心代码只认“工具注册表”，不认具体工具。

核心代码长这样，永远不变可用工具 = 工具注册表.获取所有已启用工具()结果 = 模型.选择工具并调用(用户输入, 可用工具)# 新场景上线，只做一件事：往注册表里加一条工具注册表.注册(班车查询工具)

核心代码不关心“有哪些工具”，它只问注册表“现在有哪些工具可用”。加工具就是往注册表加一条，核心代码一行不改。

生活类比：电视机的 HDMI 接口。核心是“接口”，你插游戏机、插电脑、插机顶盒，电视机不用改，插上就能用。工具注册表就是 Agent 的 HDMI 接口。

一句话总结：插件化的核心是“核心认注册表，不认具体工具”。加场景 = 往注册表加一条，核心代码不动。

4. MCP 双向接入：既会用别人的，也能被别人用

4.1 MCP 解决什么问题

假设你公司有十个系统，每个系统都想接 AI。如果每个系统都自己定一套对接格式，那就是十套格式，乱成一锅粥。

MCP 就是来统一格式的：工具提供方按 MCP 标准暴露能力，Agent 使用方按 MCP 标准调用能力。像 USB 一样，谁做设备都按 USB 标准做，谁都能插。

生活例子：以前每个手机品牌一种充电口，出门得带一堆线；现在统一成 Type-C，一根线走天下。MCP 就是 Agent 世界的 Type-C。

4.2 双向是什么意思

“双向”指 Agent 既能当客户端去用别人的工具，也能当服务端把自己的能力给别人用。

方向一：MCP Client——用别人的工具

你的 Agent 要查班车，班车系统已经按 MCP 标准暴露了“查班车”能力。你的 Agent 作为客户端，直接接进去用，不用自己重写一遍班车逻辑。

Agent 作为 MCP Client，接入外部班车 Server班车工具 = MCP客户端.连接("班车系统MCP地址").获取工具("查班车")工具注册表.注册(班车工具)

生活例子：你家的电视支持 HDMI，游戏机也支持 HDMI，插上就能玩，电视不用自己造一个游戏机。

方向二：MCP Server——把自己的能力给别人用

你的 Agent 平台积累了“知识检索”“开证明”这些能力，别的系统也想用。你把它们封装成标准 MCP Server 暴露出去，别人按标准接进来就能用。

把知识检索封装成 MCPServer 对外暴露MCP服务端.暴露工具("知识检索", 知识检索实现)MCP服务端.暴露工具("开人事证明", 开证明实现)

生活例子：你家的插座不光自己用，还能让邻居来充电（当然得你允许）。你的能力成了公共设施。

一句话总结：MCP Client 是“我会用别人的”，MCP Server 是“别人能用我的”。双向接入，Agent 从“单点应用”升级成“能力底座”。

4.3 双向接入的价值

复用：外部已有能力直接接，不重复造轮子；

被复用：自己的能力强封装出去，别的系统能用；

标准化：大家都按 MCP 来，对接成本从“一家一议”变成“插上就用”。

生活类比：USB 接口普及后，你买任何设备都不用担心“能不能插上”。MCP 普及后，任何系统接 Agent 都不用担心“格式对不对”。

5. 插件化 + MCP 之后，新场景上线长什么样

以“接入班车查询”为例，对比一下：

不插件化（旧做法）

1. 改 Agent 核心代码，加 elif 分支2. 写班车参数收集逻辑3. 写班车接口调用4. 写班车卡片渲染5. 重新测试所有场景（怕改坏开证明）6. 重新上线耗时：3~5 人日

插件化 + MCP（新做法）

1. 班车系统按 MCP 标准暴露“查班车”工具2. Agent 作为 MCP Client 接入，注册到工具注册表3. 配一下班车卡片模板4. 测试班车场景（核心没改，不用回归其他场景）耗时：1 人日以内

差别在哪：旧做法改的是“核心”，新做法加的是“插件”。核心不动，就不用回归测试所有场景，成本自然降下来。

生活类比：旧做法是每买一个电器凿一次墙；新做法是墙上装好标准插座，买电器插上就行。

6. 工具描述规范：模型用错工具，多半是描述没写好

工具描述是模型选工具的唯一依据。描述写不好，模型就会选错、传错参数。

6.1 好描述的三条标准

标准一：说清“什么时候用”

差：“查询班车”

好：“查询公司班车线路和发车时间，用户问‘班车几点’‘有没有到某地的车’时使用”

标准二：说清“什么时候不用”

差：不写

好：“仅查询班车信息，不负责预约。用户要预约班车时，请用‘班车预约’工具”

标准三：参数说清格式和可选值

差：“线路：字符串”

好：“线路：枚举，可选值【1号线、2号线、3号线】”

生活类比：药盒说明书。写清“治什么病、怎么吃、什么情况不能吃”，你才不会吃错药。工具描述就是给模型看的说明书。

6.2 描述写错的后果

描述太笼统 → 模型在该用 A 工具时用了 B 工具；

没写“什么时候不用” → 模型在预约场景调了查询工具；

参数没写可选值 → 模型传了个不存在的线路，报错后又瞎试，形成循环。

一句话总结：工具描述是模型选工具的唯一依据，写得越清楚，模型用错越少。

7. 启停与权限：插件化不是“全部放开”

插件化不等于“所有工具随时可用”。要有启停和权限控制。

7.1 启停

某个工具出故障了，或者还没准备好上线，可以在注册表里关掉它。关掉后模型看不到这个工具，自然不会调。

生活例子：小区某个门临时维修，贴个“此门关闭”，大家走别的门。启停就是“给工具贴个关闭牌”。

7.2 权限

不同用户能用不同工具。普通员工能查班车，但不能开收入证明；HR 能开证明，但可能不能提工单。

生活例子：公司门禁，不同职级能进不同区域。权限就是“工具的门禁卡”。

关键点：权限校验放在工具层统一做，不放在每个节点里。这样新工具一注册，自动继承权限校验，不会漏。

一句话总结：插件化是“能装能卸”，启停是“现在开不开”，权限是“谁能用”。三者配合，才既灵活又安全。

8. 效果与口径

这套插件化 + MCP 落地后，简历里那几个数字对应的是：

新场景联调成本降低约 70%：对比“改核心 + 全量回归”和“加插件 + 单场景测试”的人日差；

单场景接入周期由 3~5 人日缩短至 1 人日以内：工具注册 + 卡片配置 + 单场景联调；

新场景上线无需改动 Agent 核心代码：核心只认注册表，加场景 = 加注册项。

口径要写清楚：成本下降不是“代码行数减少”，是“人日减少”；“不改核心代码”指不改状态图主干和意图路由逻辑，不是一行代码都不碰（卡片模板、配置还是要配的）。

9. 面试怎么答

Q：插件化 Tool 解决什么问题？

A：解决“每接一个新场景就改 Agent 核心代码”的问题。核心只认工具注册表，不认具体工具；新场景加工具、注册、配卡片，核心代码不动。好处是改一处不坏三处、联调成本大幅下降。

Q：MCP 是什么？双向接入指什么？

A：MCP 是工具接入的统一协议，类似 USB 标准。双向指 Agent 既能当 Client 接外部 MCP Server 复用别人能力，也能当 Server 把自己能力封装出去给别人用。价值是复用、被复用、标准化对接。

Q：工具描述为什么重要？

A：描述是模型选工具的唯一依据。要写清“什么时候用、什么时候不用、参数格式和可选值”。描述含糊，模型就会选错工具、传错参数，甚至形成重试循环。

Q：插件化之后怎么保证安全？

A：启停控制 + 权限校验，都收敛在工具层统一做。关掉的工具模型看不到；没权限的调用直接被拦。新工具一注册自动继承，不会漏。

Q：插件化和状态图是什么关系？

A：状态图管“流程怎么走”，插件化管“能力怎么接”。状态图里的“调工具”节点调的是注册表里的工具，加工具不影响图的走向。两者一个管流程、一个管能力，配合使用。

10. 检查清单：你的 Agent“插得上”吗？

□核心代码里有一堆if 场景A / elif 场景B吗？

□加一个新场景，要改核心代码吗？

□加一个新场景，要回归测试所有老场景吗？

□每个工具都有清晰的名称、描述、参数格式吗？

□工具描述写了“什么时候用”和“什么时候不用”吗？

□参数校验、权限校验、超时兜底收敛到工具层了吗？

□工具有启停开关吗？

□工具权限是按用户区分的吗？

□外部能力是重复造轮子，还是用 MCP 接进来？

□自己的能力强封装成 MCP Server 给别人用了吗？

中五条以下，你的 Agent 大概还处在“每买一个电器凿一次墙”的阶段。

下一篇

这一篇讲了“能力怎么插上就用”。下一篇讲“用户等的时候别干瞪眼”：

《FastAPI + SSE 流式与卡片混合下发：解决长回答空白等待》

我们会讲：为什么流式不只是“一个字一个字蹦”、中间执行状态怎么推给用户、卡片和文本怎么混着下发、超时了怎么降级。还是用高中生能懂的例子。