当Skill热度下降后，还有人关心Agent的复杂边界么？

type

status

date

slug

summary

一、Skill的初衷是对的

Agent的工作方式是基于上下文推理。你给它一段文字（系统提示词+用户消息），它基于这段文字生成回答。

问题是上下文是有限的。模型的注意力窗口就那么大，塞进去的信息越多，对每条信息的处理就越浅。这是模型的物理约束，不是工程能绕过去的。

Skill的思路很直接：把能力拆成独立模块，用的时候再加载，不用的时候不占上下文空间。本质上是在做上下文的按需调度。

这个设计哲学没有问题。就像操作系统的虚拟内存，不是所有程序都需要同时驻留内存，需要的时候加载，用完了释放。

问题出在实现方式上。

二、全量注入让解法变成了问题

大多数Agent框架的Skill实现，是把每个Skill的name + description全量注入系统提示词。

什么意思？你装了50个Skill，每个Skill的描述大概200 token，加在一起就是10000 token的系统提示词。用户还没开口，模型的注意力预算已经被50段Skill描述占掉了大半。

而用户实际触发的，可能永远是那5-8个。

Berkeley Function Calling Leaderboard的实测数据很能说明问题：工具从4个扩展到51个，模型的选择准确率从43%暴跌到2%。

Anthropic的内部测试也指向同一个结论：58个工具定义，约占55000 token。这个体量已经接近很多模型的有效处理上限了。

所以Skill数量膨胀带来的问题不是"选择多了"这么简单，而是一个结构性矛盾：

Skill在概念上是按需加载，但在实现上是全量注入。这两件事是矛盾的。

每个Skill单独拿出来都有用，但全量堆在一起就是对上下文的滥用。有用是局部的，滥用是全局的。

三、减法才是解法

如果全量注入是问题的根源，那解法方向就很明确：减少模型每次看到的工具数量。

目前业界走通的方案叫分层路由，本质是一个三步过滤器：

第一步，意图分类。 用户的请求进来，先过一个轻量级的分类器——可以是小模型，也可以是规则引擎。它不关心具体怎么执行，只判断这个请求属于哪个领域："翻译""金融""代码""写作"。一个领域通常只有3-5个相关工具，直接砍掉80%的无关选项。

第二步，语义检索。 在剩下的小类里，用向量检索做精确匹配。用户的问题和工具的描述做embedding，算相似度，取Top-K。这一步确保注入的是最相关的那几个。

第三步，上下文注入。 最终进入模型推理的，只有用户原始query加上5-8个工具描述。干净、聚焦、不浪费注意力。

整条链路是：分类 → 映射 → 注入 → 执行。 主模型只参与最后一步。

这套方案的核心转变是：把"选择用哪些工具"这件事，从大模型手里拿走了。 大模型不再需要从50个工具里挑，它只需要在5-8个里面做判断。

问题不在Skill有多少，在于谁来做选择。

四、从Skill到Sub-agent，同一个问题换了一层皮

聊完Skill，我们来看一个更大的架构层面的问题：Multi-agent。

从主Agent的视角看，Sub-agent、Skill、Tool本质上是同一件事——可调用的资源。 区别只是执行体不同：Tool是代码，Skill是提示词模板，Sub-agent是另一个LLM。调用模式都一样：输入，执行，返回结果。

所以Skill数量膨胀的问题，在Multi-agent架构里同样存在，只是换了名字：不是"工具太多选不过来"，而是"子Agent太多协调不过来"。

Sub-agent引入了一个Skill没有的问题：黑盒性。

Tool是确定性的——输入A，一定输出B，出错了有明确的报错。Sub-agent不是。它是一个LLM在独立推理，中间过程对主Agent完全不透明。

你可以看到它最终返回的结果，但看不到它是怎么得出这个结果的。它可能在第三步就走偏了，但只要最后输出格式正确、内容看起来完整，主Agent很难自动识别出"这个结果是错的"。

更要命的是，当Sub-agent出错时，主Agent没有"局部修正"的能力。不能说"前70%是对的，只重做后面30%"。只能整体终止，重新来过。

容错粒度是组件级的，不是步骤级别的。 一个Sub-agent跑十分钟，错了，重来又是十分钟。这个效率损耗在任务数量多的时候会变得不可接受。

五、体验的空白比技术的空白更危险

技术上，Sub-agent的执行链路已经可以做到非常细粒度的可观测。

LangGraph提供了四种stream_mode，可以追踪到LLM的每一个token输出、每一个节点的状态变更、每一个子图的执行进度。工程上完全可行，数据是实时的。

但产品上，几乎没有人把这些信息暴露给终端用户。

大多数Agent产品的执行过程对用户来说就是一个黑盒：你发了一个请求，看到"处理中"，然后等。等三分钟还是十分钟，不知道。中间有没有跑偏，不知道。能不能中途叫停，做不到。

这就是并发是架构师的效率，不是用户的体验。 多Agent并行执行在架构层面提升了吞吐，但用户感知到的不是"更快"，而是"更不可控"。原来等一个Agent回答，现在等一群Agent各自忙完，沉默时间可能更长了。

更深层的问题是：没有实时反馈，用户就无法参与。 知远在调研，如果我能实时看到他的搜索结果，发现方向偏了可以立刻纠正。但现在做不到。我只能等他交卷，然后判断对不对，错了就全部重来。

这不是技术做不到，是产品设计还没跟上。

最后

这篇文章从Skill聊到Sub-agent，从工具选择聊到架构复杂度。背后其实是一个很朴素的观察：

我们一直在给Agent加能力，但很少问"系统还扛不扛得住"。

加Skill容易，加Sub-agent也容易。技术上都是"能做"。但系统的复杂度不是线性增长的——每多一个组件，组件之间的连接、协调、容错成本都在指数级上升。

Agent架构的复杂度边界，不在于技术能不能实现，而在于系统的每个组件之间，连接是否可靠、状态是否可感知、出错是否可干预。

真正的考验不是"Agent能不能做这件事"，而是"Agent做错的时候，我们能不能发现、能不能修正、能不能让用户安心"。

产品经理的判断力，不是决定给Agent加什么能力，而是知道什么时候不加。