你的Agent是一人公司还是小分队 - PMSOLO-PM的坚持成长之路

内容纲要

不少人把Skill框架和多Agent框架当作竞争对手来讨论，好像选了Skill就不该用多Agent，反过来也一样。我觉得这是个挺大的误解——而且这个误解正在导致很多人在做AI产品时走弯路。

说白了，Skill和多Agent解决的是同一个底层问题的两种思路，它们能共存，而且在生产级系统里通常是一起用的。但在搞清楚"怎么一起用"之前，我们得先把两者说清楚。

一个Agent变聪明 vs 一群Agent分工干活

先说最直觉的类比。

Skill框架，可以理解为"培训一个全能员工"。你只有一个Agent，但你可以随时给它注入不同的专业知识——调试代码时它用"Debugging Skill"，写文档时切换"Writing Skill"，做Code Review时激活"Review Skill"。知识按需加载，用完就走，Agent本身不变。

多Agent框架，更像是"组建一个小分队"。你预先定义好每个成员的职责：有人专门搜索，有人专门分析，有人专门写作。大任务进来，分解派发，各自执行，结果汇总。

听起来多Agent更强大？其实不一定。这里有一个数据值得注意：研究表明，单个Agent超过10-20个工具之后，性能会显著下降。工具越多，Agent越容易"选择困难"，行为越难预测。多Agent的出现，很大程度上就是为了解决这个"工具爆炸问题"。

但Skill框架走了另一条路——不是分裂成多个Agent，而是让一个Agent动态按需加载能力，保持上下文干净。

这就是两种不同的复杂度管理策略。

它们共同的敌人：上下文污染

要真正理解这两种架构的价值，得先知道它们在对抗什么。

你有没有遇到过这种情况：跟AI聊到后期，它越来越"蠢"，开始忘事、答非所问？这不是模型变差了，是上下文污染在作怪。

Transformer架构的工作方式决定了：窗口里的每一个Token，都要跟其他所有Token互相计算。信息越堆越多，注意力越来越分散，有用的内容被无关内容淹没，性能就下滑了。研究者把这个现象叫做"Context Rot"（上下文腐烂）。

两种框架的应对思路截然不同——

Skill框架的做法是"按需注入，用完即走"。任务结束后，Skill带来的上下文影响自然消散，对话窗口保持干净。

多Agent框架的做法是"隔离上下文"。每个子Agent各自维护独立的上下文窗口，主Agent只接收汇总结果，大幅降低了信息污染。

你看，两种架构在解决同一个问题，只是选了不同的切入点。这就是为什么它们不是对手，而是应对不同场景的不同工具。

Skill在架构上到底是什么？

这里要稍微深入一点，不然很容易跟"工具（Tool）"混淆。

Skill的本质是：Prompt模板 + 对话上下文注入 + 执行权限修改，打包成一个可复用的单元。

以Anthropic的Claude Code Superpowers系统为例，它的实现分三层：

Skill Meta-Tool：工具数组里的专用分发器，由LLM自己推理决定激活哪个Skill——没有硬编码规则，纯语言理解
对话上下文注入：Skill的指令以隐藏消息形式注入，用户看不到，但Agent完全遵循
执行上下文修改：临时调整工具权限、模型选择，只在当前Skill执行期间生效

还有一个关键设计叫渐进式披露（Progressive Disclosure）：先只加载Skill的名称和描述，Agent判断匹配后再加载完整的Skill文件。这样就避免了"把所有知识一股脑塞进去"的上下文膨胀问题。

简单说：Skill不是一个独立运行的Agent，而是一个行为修改器。它不产生新的对话线程，不需要进程间通信，所有操作都在单个上下文里完成。

这跟Tool的区别很清楚——Tool给Agent"动手能力"（调API、执行代码），Skill告诉Agent"该怎么做"（思维框架、操作规范）。两者互补，不是替代关系。

多Agent的架构逻辑

多Agent的世界里，最常见的有四种模式：

中央编排（Manager-Worker）：主Agent分配任务，子Agent执行汇报——最经典，可控性最强
Agent作为工具：子Agent被当成可调用的函数，输入输出边界清晰，测试友好
图结构工作流：任务按预设路径流转，每个节点是一个专业Agent，适合流程固定的场景
并行扇出/扇入：多个Agent同时探索，结果统一汇总——速度快，但需要好的合并逻辑

每种模式都有适用的场景，生产系统通常是混合使用的。

子Agent可以用Skill吗？当然可以

这是很多人的盲点：多Agent框架和Skill框架不是互斥的，子Agent完全可以使用Skill。

技术上没有任何障碍——Skill的本质是Prompt注入，任何能接收系统提示的Agent都能用。更重要的是，每个子Agent可以有自己独立的Skill库，专门为它的职责优化。

一个生产级AI代码助手可能长这样：

主编排Agent（使用通用协调Skill）
    ├── 代码子Agent（加载 TDD Skill + Debugging Skill）
    ├── 文档子Agent（加载 Writing Skill + Review Skill）
    └── 测试子Agent（加载 Testing Skill + QA Skill）

多Agent负责任务分发和上下文隔离，Skill负责在各层注入专业行为。这才是2025年底生产系统的真实长相——混合架构，不是二选一。

LangChain的官方文档对此有一个很直接的表述：Skills代表"单Agent内的渐进式能力披露"，而Subagents是"独立实例"——两者定位不同，解决不同维度的问题，自然可以叠加使用。

什么时候用哪个？一张表说清楚

光说"都能用"还不够，来点实际的：

场景	推荐方案	原因
重复性请求，单领域	Skill优先	比多Agent方案节省约40%的API调用
多领域并行查询	多Agent优先	比单Agent减少约67%的上下文Token消耗
快速原型，小团队	Skill框架	启动成本低，写Markdown文件就行
企业级，强可控性	多Agent + 路由层	结构化路由，易审计，便于监控
复杂生产系统	混合架构	多Agent骨架 + 各层Skill，取长补短

有意思的数据：对于重复性的单领域请求，Skill方案可以省40%的调用次数；但对于需要同时查询多个知识域的场景，多Agent并行处理能减少67%的Token消耗。没有哪个方案在所有场景都占优，这正是两者并存的根本原因。

成本上的差异也很明显：Skill框架的启动成本极低（写几个Markdown文件），但随对话积累上下文有Token增长；多Agent启动成本高（需要设计Agent拓扑），每次任务多次模型调用，但扩展上限更高。

这件事跟产品经理有什么关系？

可能比你想的关系更大。

场景一：你在设计一个AI写作助手

用户反馈想要"根据不同任务类型切换风格"。如果工程师方案是"搭建场景识别Agent + 多个专业写作Agent的协作链路"，这当然能实现，但工程复杂度会爆炸。

更合理的方案是：设计三个Skill——商业文案、学术写作、创意写作，让Agent自动识别激活。工程投入大概降低80%，效果基本相当。这时候如果PM不懂这个逻辑，就没办法在技术方案评审时提出有效意见。

场景二：你在设计一个企业知识库问答系统

用户需要同时查询法规库、产品手册、历史案例三个不同数据源，然后综合回答。

这才是多Agent真正该出场的场景：三个专门的检索Agent并行查询，大幅减少响应时间。如果硬要用单Agent+Skill，上下文会被三份文档塞满，性能下降明显，体验会很差。

搞清楚两种架构的边界，PM就能在产品设计阶段做出更合理的技术约束，而不是等工程师做完了再发现方向不对。

现在在哪个阶段，以后往哪走

时间线拉一下：

时间	关键事件
2023年初	Function Calling成为Agent工具化主流方式
2023年中	LangChain、AutoGen发布，多Agent框架开始普及
2024年	"工具爆炸问题"被广泛报道，单Agent局限性显现
2025年初	Anthropic发布Claude Code + Superpowers Skill系统，Skill成为正式架构概念
2025年中	LangChain在文档中正式区分Skills vs Subagents，提供决策框架
2025年底	混合架构成为生产主流，"子Agent使用Skill"成为标准配置

现在的状态是：多Agent框架已在企业场景规模落地，Skill框架作为独立概念还在普及阶段，混合架构正从先行者实践走向标准化。

往后看，我倾向于认为Skill框架会越来越像Agent系统的"操作系统内核"——每个Agent默认具备Skill加载能力，而多Agent框架向更轻量化方向演进，两者之间的边界会越来越模糊，最终可能被统一的平台层屏蔽掉。

届时开发者面对的接口可能就是：描述你的任务，系统自动决定用Skill还是子Agent。

三个还没有答案的问题

最后留几个我自己也在想的问题：

1. Skill设计会成为一个独立职业吗？
当Skill质量成为AI产品的核心竞争力，谁来负责它的设计、维护和迭代？是PM、工程师，还是会诞生"Skill Architect"这样的新角色？

2. 多Agent架构的最小必要门槛在哪里？
从"能用单Agent就用单Agent"到"真的需要多Agent"，中间有一个复杂度门槛。这个门槛有没有可操作的判断标准，而不只是"感觉复杂了就上多Agent"？

3. 如果平台层把选择权抹掉，竞争格局会怎么变？
未来如果所有平台都自动帮你选Skill还是子Agent，那差异化还剩什么？会不会反过来让Skill的设计质量成为唯一值得比拼的地方？