简介：Agent技能机制让单智能体挂载上百个技能成为可能，但最新研究表明，技能库扩容存在非线性的“相变”上限。本文对比单Agent技能组合与多Agent架构在上下文管理、检索机制、成本延迟、扩展上限、安全运维上的差异，给出典型场景选型建议、六条工程建议与迁移注意事项，帮助开发者避开“扩容墙”，做出数据驱动的架构决策。
自某主流模型厂商推广Agent技能（Skills）机制以来，“即插即用”的模块化体验迅速成为业界共识：开发者不再需要维护一套臃肿的多智能体编排系统（MAS），只需把领域能力写成一组结构化的Markdown技能文件，由Agent在运行时按需调用。相比传统的多智能体方案，这种做法把“多个模型互相调用”压缩为“一个模型按需读文档”，公开的实践反馈显示，典型任务下的API账单与端到端延迟能同时下降一半以上。
看起来问题已经终结：给一个Agent挂载几十甚至上百个技能，它似乎就能包打天下。但事实并非如此。模型厂商的官方文档鼓励开发者放心创建技能，却鲜有说明：当技能目录里堆到两百个技能文件时，会发生什么。
来自高校与研究机构的最新研究给出了量化答案：大模型的技能检索与CPU的缓存机制类似，存在物理极限。当技能库规模线性增长时，Agent的“清醒程度”——即正确选择并执行技能的能力——会在某个临界点之后经历一次非线性的“相变”。研究据此提出了“Agent技能扩容墙”的概念，并总结了六条开发法则。
这就把一个此前被掩盖的架构决策推到了台前：当能力需求不断膨胀时，是继续给单Agent堆技能，还是拆分成多Agent架构？本文围绕这一问题展开系统对比。
方案A：单Agent + 技能组合。 一个Agent实例外挂一个技能库，每个技能以“名称+描述+执行步骤”的结构化文档形式存放。Agent收到任务后，根据任务语义在技能库中匹配并加载对应技能。它的核心假设是：模型本身足够聪明，只要把“说明书”写清楚并放进上下文，模型就能自己完成检索与执行。它解决的是能力扩展的“轻量化”问题——不加服务、不写编排，加一个文件夹就能扩展能力。
方案B：多Agent架构。 由多个各自绑定独立系统提示词、独立上下文窗口和职责边界的专职Agent组成，由编排层（或主Agent）负责任务路由、结果汇总与状态传递。它的核心假设是：与其让一个模型在浩瀚选项里挑说明书，不如事先把说明书分成几摞，每摞交给一个“只读这一摞”的专职模型。它解决的是能力扩展的“规模化”问题——通过分工与隔离，让能力增长不再以牺牲单点清晰度为代价。
这些共同点意味着：两种方案不是“先进与落后”的关系，而是同一工程目标在不同规模下的两条实现路径。
方案A中，技能描述要么全量注入、要么检索后注入，上下文占用随技能库规模线性增长。这可以类比CPU缓存：当“工作集”（任务真正需要的技能，加上所有被注入的干扰描述）超出模型的有效注意力范围后，匹配质量骤降。伪代码示意：
# 伪代码（示意）：单Agent技能注入的上下文膨胀def run_single_agent(task, skill_library):prompt = system_promptfor s in skill_library:prompt += s.description # ① 描述随库规模线性膨胀return llm(prompt, task) # ② 越过阈值后，匹配质量非线性下滑
方案B则把上下文天然分片：每个子Agent只携带本领域的少量技能，单点上下文始终保持“清醒”。代价是跨Agent通信本身会消耗令牌、引入延迟。
方案A的“检索”发生在模型内部，是隐式的：模型读完一堆技能描述后自行决定用哪个。这带来两个问题：一是不可观测，匹配错了很难第一时间定位错在哪一环；二是描述互相干扰，语义相近的技能越多，误触发概率越高。
方案B的路由显式发生在编排层，可以用规则、分类器甚至独立的轻量模型实现。路由日志、命中率、误路由率都可以单独度量与优化，工程上可控性明显更强。
在技能数量可控（数十个以内）、任务同质性高的场景，方案A几乎是成本与延迟的最优解：一次模型调用完成任务，没有编排开销，有公开实践反馈其账单与延迟相比完整多智能体编排可下降一半以上。
方案B的调用链存在“乘法效应”：任务路由一次调用、子Agent执行至少一次、结果汇总可能再一次，协作轮次越多，令牌消耗与延迟增长越快。但两者的成本曲线性质不同：方案B是“平缓变贵”，方案A过墙后是“变贵的同时质量崩塌”——后者往往才是更危险的。
这是相关研究最核心的发现。方案A并非渐进变差，而是存在“相变”：技能库规模越过临界点后，典型表现是Agent不仅学不会新技能，连原本稳定的旧任务也可能被干扰拖垮，呈现悬崖式下滑。方案B的瓶颈则相对平缓：Agent数量增加主要推高编排复杂度与一致性维护成本，单点能力不会因此退化。换言之，方案A的上限是“硬墙”，方案B的上限是“缓坡”。
方案A中所有技能共享同一个执行环境与权限上下文：一个表述含糊的技能描述可能污染其他技能的触发，权限也只能做到Agent级粗粒度控制。方案B中各Agent天然隔离，可以按Agent分配最小权限、独立限流、独立审计，故障影响面可控——这对企业级的权限与合规要求更友好。
方案A的日常运维接近“文档管理”：改一个Markdown文件、跑一遍回归即可。方案B则是一项系统工程：编排逻辑、状态传递、重试幂等、多版本并存、链路追踪，每一项都需要专门的工程投入与团队工程能力。
| 对比维度 | 单Agent + 技能组合 | 多Agent架构 |
|---|---|---|
| 架构形态 | 单实例 + 外挂技能文件库 | 多个专职Agent + 编排/路由层 |
| 上下文占用 | 随技能库规模线性膨胀 | 按Agent分片，单点始终聚焦 |
| 检索机制 | 模型内隐式匹配，不可观测 | 编排层显式路由，可度量 |
| 成本与延迟 | 中小规模最低，实践反馈可降一半以上 | 调用链乘法效应，随规模上升 |
| 扩展上限 | 存在“相变”式扩容墙 | 平缓缓坡，瓶颈在编排复杂度 |
| 故障隔离 | 单点，技能间可能互相干扰 | Agent间天然隔离 |
| 安全与权限 | 粗粒度，Agent级 | 可按Agent最小授权、独立审计 |
| 运维复杂度 | 低，接近文档管理 | 高，需要系统工程能力 |
| 适用规模 | 数十以内技能、同质任务 | 上百异构能力、跨领域长流程 |
选型不应是站队，而应视为技能库规模的函数。给出条件化决策清单：
结合研究结论与业界通行实践，可归纳出六条工程建议：
从方案A迁移到方案B（或混合架构）时，需重点评估：
单Agent + 技能组合与多Agent架构，本质上是同一工程目标（能力扩展）在“上下文经济学”上的两种分配方式：前者把所有说明书塞进一个大脑，轻、快、省，但存在相变式的扩容墙；后者把说明书分成几摞各归各的大脑，重、贵，但扩展曲线平缓、边界清晰。两者不是替代关系，而是规模光谱上的不同区段——数十个技能以内，技能组合几乎是必然选择；跨领域、上百能力、强合规的场景，多Agent或分层混合才是正解。最务实的路径是：以评测数据为罗盘，以技能命中率为哨兵，先跑通轻量方案，并在撞墙之前完成一次从容的架构拆分。