「技能化」Agent 架构正在取代「大杂烩」Agent：一次架构升级的复盘

如果你维护过一个工具数超过 15 个的 Agent，一定见过这些症状：选错工具、参数填错、在无关工具上浪费 token、改一个工具导致别的场景退化。根因不是模型不行，而是架构错了。 2026 年越来越多的团队转向「技能化」（Skill-based）架构，本文复盘这次转变。

「大杂烩 Agent」为什么必然失效

传统做法的思路是：把所有能力都做成工具，全塞给一个 Agent，靠提示词教它”什么时候用哪个”。

三个结构性缺陷：

1. 上下文污染：30 个工具的 schema 描述可能占掉几千 token，模型的注意力被稀释，越到后面越容易被无关工具误导。
2. 能力耦合：你为了修 A 场景微调了工具描述，B 场景的选择准确率跟着掉——因为它们在竞争同一个”决策位置”。
3. 无法单独评估：整个 Agent 只有一个端到端指标，你不知道是哪一步错了。

Skill-based 架构的核心思想

把”一个万能 Agent”拆成”一个调度器 + 若干技能”。每个技能是一个自包含的单元，包含：

• 一段专属的指令（我是干什么的、边界在哪）
• 只属于它的少数几个工具
• 它自己的输出格式和验收标准

调度器（Orchestrator）只负责路由：“用户这个请求属于哪个技能？“而不负责执行细节。

这其实是软件工程的单一职责原则搬到了 Agent 领域：一个技能只做一件事，工具集尽量小（3-5 个为宜）。

一个具体例子

假设一个客服 Agent，原来有 25 个工具：查订单、改地址、退款、开发票、查物流、转人工……

拆成技能后：

技能	工具	触发条件
订单查询	查订单、查物流	用户问进度/状态
售后处理	退款、换货、开票	用户要退换/开票
地址变更	改地址、校验地址	用户要改收货信息
转人工	仅转接	无法处理或用户要求

调度器看用户意图，直接路由到对应技能。每个技能只带 2-3 个工具，选择准确率显著提升。

拆分带来的三个收益

1. 可独立评估与迭代：退款技能准确率掉了？单独调它，不影响订单查询。
2. 上下文干净：每个技能只加载自己需要的工具，token 省了，准确率还涨了。
3. 可组合：复杂请求（“改地址并重新发货”）= 调度器依次调用两个技能。

怎么迁移现有 Agent

不用推倒重来，三步走：

1. 打标签：把过去一个月里 Agent 的每次调用按”业务意图”归类，你会自然发现 5-8 个聚类。
2. 抽技能：每个聚类对应的工具和指令抽成一个技能，先并行运行，和旧 Agent 对比准确率。
3. 切流量：确认新架构不劣于旧的后，逐步把流量切过来，调度器可以先用规则、后期再上模型。

边界与坑

• 技能不是越多越好：拆到每个技能只剩 1 个工具，调度器反而变复杂。3-5 个工具是比较舒服的粒度。
• 调度器本身也会错：路由错误要单独监控，它比执行错误更隐蔽。
• 共享状态：多个技能协作时，中间结果怎么传要提前设计，别让每个技能各自维护一份。

小结

「大杂烩 Agent」的问题在于把决策、执行、状态全揉在一起，注定不可维护。技能化把单一职责原则引入 Agent，让每一块都能独立评估、独立迭代。当你的 Agent 开始”哪个场景都想管、哪个场景都管不好”时，就是该拆分技能的信号。