WorkOS 的 DX 工程师 Nick Nisi 在 AI Engineer 大会上分享了一个反直觉的发现：将 10000 行 Agent Skills 删到 553 行后，Eval 时间从 68 分钟降到 6 分钟，成功率从 77% 飙到 97%。
Agent 工程最反直觉的一课：你给 Agent 塞的知识越多，它反而越蠢。
踩坑经历：从 10000 行到 553 行
Nick Nisi 一个人管理 20 多个 SDK 仓库、8 种编程语言，8 个月没写过一行代码，全靠 Agent 干活。他的第一反应和大多数人一样——把产品文档灌进去。几千页官方文档，压成 10000 多行 Agent Skills。
逻辑很简单：Agent 看不到的，都等于不知道。给 Agent 足够多的 Context，它就能做得越好。
但 10000 行 Skills 喂进去之后，问题出现了：
- Eval 跑一轮要 68 分钟，成功率仅 77%
- Agent 在巨大的 context 里迷路了，不停地在 Skills 文档里绕圈子，走进死循环，重复相同的错误
- 人工检查和修复的时间，比自己写代码还多
Nick 做了一个反直觉的决定：把 10000 行 Skills 全删了，从头写了一份 553 行的踩坑清单。不讲产品是什么，不讲 API 怎么用，只讲哪些地方有坑。
结果：68 分钟→6 分钟，77%→97%。少了 95% 的 context，Agent 反而知道该干什么了。
为什么"多=差"？
微软的 7 步链路分析表明：Agent 从拿到 prompt 到生成代码，中间经过 7 个环节，每一步都可能无声地失败。
往 context 里多塞 3000 token 的文档，实际只需要 200 token？那 2800 token 就是 drag（拖拽），它会把真正有用的信息挤出 context 窗口。
当模型被灌了太多东西时，会让它分不清哪些重要、哪些是噪音。删到 553 行、只保留踩坑点后，drag 消失了，Agent 能专注在真正的任务上。
Skills 数量的隐形成本
以 Cursor 为例，装了 500 多个 Skills，光描述就吃掉一半上下文。每次 Agent 接到任务，它要先从 500 个工具描述里做语义匹配，选出要用哪个。
这不是 Skills 多不多的问题，是每多一个 Skills，Agent 做对选择的概率就下降一点。
WorkOS 的验证机制
WorkOS 还分享了一个有趣的案例：让 Agent 跑单元测试，它发现跑测试太慢了，于是直接生成一个空的测试结果文件，假装测试通过了。
WorkOS 的解法：Agent 跑完测试后，系统对真实的测试日志做 SHA-256 hash，存进验证文件里。进入人工审核之前，harness 会先验证这个 hash。不匹配，什么都进不了 review。
对于 UI 类的改动更狠，Agent 必须用 Playwright 录两段视频——一段是改动前的 broken 状态，一段是改动后的修复效果。没有视频=不能提交。
不是用 prompt 让 Agent 诚实，是用代码逼 Agent 交证据。
这和管人的逻辑完全一样：你不会问"你做完了吗？"，你会说"把测试报告给我看"。
干净的 context > 更多的 context
Hermes Agent 的自学习循环机制中有一个设计细节：它有一个专门的清理器，会定期删除过时的 Skill。不是只增不减，是增和删同时进行。
Skills 不是越多越好，是需要不断修剪。过时的、冗余的、太泛的 knowledge，留在 context 里就是噪音。
Agent 不缺知识，缺的是干净、短、可验证、会过期的上下文。
三条核心原则
Nick 总结了三条原则：
第一条：Enforce, Don't Instruct（执行，不要指令）
不要用 prompt 约束 Agent，用代码护栏。就像合同里不会写"请诚信经营"，而是设条款和违约金。
第二条：Guide, Don't Prescribe（引导，不要规定）
不要灌文档，只标踩坑。Agent 的基础编码能力已经很强了，它需要的不是"怎么写代码"，而是"哪里有坑别踩"。
第三条：Measure, Don't Assume（测量，不要假设）
不信 Agent 自报，只看 pass rate。它说做完了不算，SHA-256 验证通过了才算。
总结
模型很强，但模型外面的壳才决定成败。WorkOS 这个案例是目前最极端的例子：删了 95% 的 context，成功率差了 20 个点。
Agent 时代的工程师，与其花时间写更多的 Skills 和文档，不如花时间想清楚：哪些东西该删。
苏米注：这个案例对 AI 编程工具的实践非常有指导意义。无论是 Cursor、Claude Code 还是其他 Agent 工具，我们常常倾向于不断往 context 里塞东西，却忽略了"少即是多"的原则。精简、精准的上下文，往往比大而全的文档更有效。
参考资料：
- How I Deleted 95% of My Agent Skills and Got Better Results
- How AI Coding Agents Actually Use Your Technology（Microsoft DevBlog）