Agent架构搭建 ≠ 堆Skills

在“让AI足够灵活”和“让系统足够可控”之间找到平衡点。

现在，我看到一个Agent架构是以一大堆Skills为基础的时候，我就知道完蛋了。

为什么这种搞法大概率会翻车？

Skills这类机制，本质上是把一堆操作指南和脚本打包成文件夹，让模型根据描述自己判断要不要用，和什么时候用。

这套机制的问题在于，它把关键的决策权交给了模型的“临场判断”，但是这种判断并不总是靠得住。

有实测数据显示（包括我自己搭建newtype OS的经验），即便Agent手头有现成的Skill可用，也有超过一半的情况选择不调用，效果和完全没有文档时几乎一样。

原因很简单：Skill要不要被激活，全靠SKILL.md里那段简短的description描述能不能被模型准确匹配到当前任务上。

描述写得模糊，或者装了多个功能相似的Skill互相“打架”，模型就容易选错，甚至干脆不选。

更麻烦的是，随着Skill数量增多，模型要在一堆技能里做检索和判断，这个负担本身就会拖累整体表现。之前看到过一个研究，当技能库规模超过某个阈值（小模型大约是90个左右）时，Agent的判断质量会出现断崖式下滑——这被称为“认知生死线”。

换句话说，单纯靠堆Markdown文档、Skills数量，系统的可靠性反而会随着规模增长而变差。

这背后其实反映了当下Agent架构设计的一个核心矛盾：如何在“让AI足够灵活”和“让系统足够可控”之间找到平衡点。

那么，怎么搞才好呢？

思路很简单：把整条链路上能靠代码确定完成的部分，全部工程化处理掉。只把AI留给最后一步“填空”。

我来具体拆解一下这个逻辑。