他删掉95%的 Agent 技能后，系统反而更聪明了

当所有人都在给 AI Agent 拼命加技能、加工具时，WorkOS 的 Nick Nisi 却反其道而行：删掉 95% 的 Agent 能力。结果不是退化，而是效果显著提升。这场分享，几乎颠覆了我们对“更强 Agent=更多技能”的默认认知。

最反直觉的结论：Agent 不是技能越多越好

Nick Nisi 在开场就抛出了一个让人不安的事实：他构建过一个“看起来很强”的多 Agent 系统，里面塞了五个不同职责的 Agent、大量技能（skills）、精心设计的流程，但真实使用体验却并不好。

问题不在模型能力，而在系统复杂度。Agent 拿到的上下文越多、可调用的技能越多，行为反而越不可预测：该用的不用，不该碰的频繁触发；一次小改动，就可能引发连锁反应。Nick 形容这种状态就像“你以为在指挥一个团队，实际上是在和一群同时说话的人吵架”。

于是他做了一个几乎违背行业共识的决定：大幅删减 Agent 能力。不是优化提示词，不是换模型，而是直接删除 95% 的技能和中间 Agent。结果令人意外——系统稳定性上来了，成功率更高，完成任务的时间更短。

从“五个 Agent”到“一个 Agent”：系统为什么更稳了

最初的系统是从一个 Claude skill 演化而来，逐渐变成包含五个 Agent 的复杂架构：有的负责找上下文，有的负责执行，有的负责验证结果。设计初衷是“分工明确”，但现实是：Agent 之间并没有你想象中那么默契。

Nick 发现，真正拖慢系统的不是模型推理，而是“Agent 决策成本”。每多一个 Agent，就多一层判断：该不该交给下一个？用哪个技能？要不要重试？这些决策在复杂任务中会迅速放大，最终表现为失败率上升。

当他把系统压缩为“一个核心 Agent + 极少数必要工具”后，事情反而简单了：上下文由系统显式提供，Agent 只负责解决问题本身。少了来回传话，少了无效试探，Claude 的表现更接近一个专注的工程师，而不是一个被流程绑架的机器人。

评估（evals）救不了糟糕的架构

在系统调优过程中，Nick 也做了大量评估（evals）：成功率、耗时、失败类型，几乎能量化的都量化了。但他坦承，一个关键教训是——评估无法弥补错误的系统设计。

在复杂 Agent 架构下，evals 只能告诉你“它现在不行”，却很难告诉你“为什么不行”。你可能看到成功率提升了一点，却不知道是运气、上下文偶然更合适，还是某个 Agent 刚好没捣乱。

当系统被简化后，评估才真正有意义：每一次失败都更可解释，每一次改动的影响都更清晰。Nick 的结论很直接：如果你需要大量 evals 才能判断 Agent 有没有在做正确的事，那很可能说明你的 Agent 设计已经过度复杂了。

给 Agent 让路，而不是给它塞能力

在分享的后半段，Nick 把视角从“怎么造 Agent”转向了“怎么为 Agent 造环境”。他认为，很多团队犯的错误是：不断教 Agent 新技能，却忽略了运行环境本身是否友好。

真正有效的做法是：让 Agent 更容易拿到正确的上下文，更少被无关信息干扰；让系统状态是显式的，而不是藏在某个 Agent 的“记忆”里；让失败是可恢复的，而不是一次错误就全盘推翻。

换句话说，与其打造一个全能型 Agent，不如打造一个“不会犯蠢”的 Agent。能力不足可以补，系统失控却很难救。

总结

Nick Nisi 的这场分享，核心不是“少即是多”的鸡汤，而是一个工程现实：在 AI Agent 时代，复杂度才是最大的敌人。删掉 95% 的技能，并不是退步，而是把系统从失控边缘拉回来。

对正在做 Agent 的你来说，真正值得反思的或许是：你的 Agent 失败，是因为模型不够强，还是因为你给了它太多选择？下一次想加新技能前，不妨先问一句：如果我把它删掉，系统会不会反而更好？

关键词： AI Agent， 多Agent系统， Claude， 系统设计， Agent评估

事实核查备注： 需要核查：1）Nick Nisi 的具体身份与 WorkOS 关系；2）“删掉 95% 技能”是否为其原话或演讲中的明确比例；3）系统最初包含“五个 Agent”的描述；4）使用的模型为 Claude；5）视频发布时间与链接有效性