Coding Agent on 鬼哥的空间

Skill 越多，Agent 为什么越容易犯选择困难？

Wed, 19 Aug 2026 00:00:00 +0000

不知道大家Vibe Coding时间久了以后会不会碰到这样的问题: 学习和使用了不少有用的skill, 自己的skill库越来越丰富, 但 Skill 库越攒越多，Agent 反而偶尔开始犯一种很熟悉的病：选择困难症。 有些问题, 这个skill能处理, 那个也能搞定, 但又都不是完美匹配当前场景的. 导致同一个问题, 多次解决路径居然不一致, 带来的结果和周边影响也不一样.

AI跟人一样, 对一些问题有多条解决路径选择时。就跟鬼哥看到“干炒牛河、辣椒炒肉、小炒黄牛肉、湖南米粉”同时出现在菜单上，脑子就直接进入一个 Infinity Loop 循环, 这顿饭都没力气吃下去了。Agent 面前如果同时摆着几十份名字相近、边界暧昧的 Skill，情况大致相同，只是它不会叹气，而是更认真地读错几份文件。

鬼哥昨天读到一篇新论文 Demystifying Agent Skills: Why They Work—Until They Don’t 恰好把这个问题拆开了。它问的不是“Skill 有没有用”，而是更麻烦也更有价值的问题：它什么时候帮忙、为什么帮忙、又从哪里开始添乱？

论文的答案很克制：Skill 确实有效，但它最主要的作用不是给 Agent 多塞一点知识，而是把过去混乱的经验压缩成一根可执行的“程序锚点”。问题也在这里：锚点一旦抛错地方，船就会稳稳地停在错误的位置。

Skill 不是“经验文档”，而是经验的蒸馏

论文把同一批历史执行轨迹做成了三种版本：

给 Agent 的东西	它保留了什么	它容易带来的问题
Raw	什么都不注入，让 Agent 从头做	每次都要重新发现环境、命令和检查步骤
Workflow Memory	清洗过的历史流程	仍夹带失败分支、偶然细节和冗长探索
Skill	从同一批流程蒸馏出的 `SKILL.md`	需要判断是否适用、如何适配

这个对照很关键。Skill 和 Workflow Memory 来自同一批成功与失败轨迹，所以它们的差异不能简单归因于“前者知道得更多”。

在匹配比较里，Skill 的成功率为 61.9%，Raw 为 59.1%，Workflow Memory 为 55.9%；Skill 相比 Workflow Memory 的增益为 6.06 个百分点，95% bootstrap 置信区间为 +0.76 到 +11.36。

更有意思的是，研究者逐条分析 Agent 轨迹后发现：Skill 有效的案例里，65.7% 是因为它提供了程序锚点——步骤顺序、工具调用、检查点、验证方案、常见坑；只有 4.5% 是因为它补充了 Agent 原本不知道的事实。

这和很多人的直觉相反。我们写 Skill 时常想“把知识写全一点”，但真正有价值的，往往是让 Agent 在关键时刻不忘记：先启动什么、再检查什么、哪种输出不算完成、踩坑后怎样退回来。

Skill 最大的作用，不是替 Agent 多记一条知识，而是在关键步骤上少忘一件事。

它最擅长修的，是“会做但总忘”的问题

论文里的细分结果很像所有做过 Agent 工程的人见过的事故单：

环境或基础设施失败：从 Raw 的 5.3% 降到 Skill 的 0.2%；
输出格式或 schema 不匹配：从 7.4% 降到 3.2%；
后台服务生命周期失败：从 2.7% 降到 0.8%。

这些不是深奥推理题。它们更多是执行纪律问题：路径没记住、服务没确认、schema 没校验、命令没按正确顺序跑。

所以一个好的 Skill，应该像一位靠谱但不啰嗦的值班同事：它不替你决定产品要不要做，却会在你准备发布前提醒“配置读了吗？”“服务起来了吗？”“返回值真符合接口吗？”

但别因此高估它。算法逻辑错误在 Skill 条件下仍有 7.4%，只做静态检查、没有真正运行验证的失败仍有 11.7%。Skill 能稳住执行，不能替人重新定义一个理解错了的问题。

Skill 的反噬：它会让错误的假设更有执行力

Skill 不是自动执行的。Agent 必须先判断它是否相关，再决定跟到什么程度，还得在当前环境里修改它。

这一步一旦偷懒，Skill 就从经验变成了惯性。论文中，skill_guidance_misapplied_or_ignored 在 Skill 组里占 10.0%，而 Raw 是 0.8%、Workflow Memory 是 0.4%。

这不是说 Skill 内容一定不好。更常见的情况是：旧任务和新任务看起来像，但一个前提已经变了；Agent 拿着一份“通常正确”的流程，顺手把它套到“不再通常”的场景上。

一个没有退出条件的 Skill，是把经验固化成偏见的最快方式。

这也是为什么我现在更在意 Skill 里有没有下面四块，而不是它写了多少页：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


## 适用前提
- 什么输入、环境和权限下使用？

## 执行路径
- 关键步骤的顺序是什么？

## 验证标准
- 跑什么检查？什么结果才算完成？

## 退出与升级
- 哪些信号说明不适用？何时停止并转人工/换方案？

前面三项让它可执行，最后一项让它不会过度自信。

Skill 库越大，难的不是保存，而是选择和适配

论文专门测了这个问题。候选 Skill 池从 5 个增加到 100 个时，Agent 在真实执行里实际使用 ground-truth Skill 的精确率，平均从 29.6% 掉到 3.3%。

但下游任务成功率却没有同步崩掉，只从 36.4% 变到 39.3%。原因并不神秘：Agent 可能看了多份相近 Skill；其中某份并非标注的“唯一正确答案”，却依然给了有用的操作线索。反过来，即使它选中了 ground-truth Skill，也仍可能在执行、适配或验证环节失败。

论文由此给出一个很重要的结论：精确调用标注上的正确 Skill，既不是任务成功的充分条件，也不是必要条件。

这对个人开发者的含义是：别只用“检索命中了没有”衡量 Skill 库。更应该问：

这份 Skill 的触发条件是否能和相邻 Skill 区分开？
它能否解释自己为什么适用于当前任务？
它的关键步骤能否被当前环境的 verifier 验证？
当它与另一份 Skill 冲突时，Agent 知不知道该降级、组合还是停下来问？

Skill 库的瓶颈从来不是存储空间，而是选择和适配能力。菜单可以很长，但“都来一份”不是一个工程策略。

失败轨迹别急着扔，它们是 Skill 的边界说明书

研究者还做了一个很实用的消融：构建 Skill 时，保留或去掉历史轨迹的“成功/失败”标记。

只有成功轨迹时，是否保留标记影响不大；一旦混入失败轨迹，结果标签就开始发挥作用。以 Gemini 在 Terminal-Bench-2 的 3 成功 + 2 失败 轨迹组合为例：构建 Skill 时保留 outcome labels，成功率为 74.62%；拿掉标签后，只有 40.00%。

这说明失败轨迹并不是应当删掉的脏东西。它告诉我们：哪一步看似合理却不通、什么条件一变流程就失效、最终验证为什么没有通过。

当然，失败记录原封不动地塞回上下文也不行——Workflow Memory 的 timeout/budget exhaustion 达 10.6%，而 Skill 为 4.4%。正确做法不是保存更多过程，而是把失败蒸馏成可判断的边界：失败模式、触发条件、检查办法、替代路径。

给个人开发者的一条 Skill 维护规则

如果你正在维护自己的 Skill 库，我建议不要从“再写一份新的”开始，而是从每次真实任务结束后的四个问题开始：

这次 Agent 反复犯的，究竟是知识缺口，还是执行步骤遗漏？
哪一步可以写成稳定的前提、动作和 verifier？
哪个失败条件必须写进这份 Skill 的退出路径？
它和已有 Skill 的边界是否足够清楚，还是只是在菜单上多加了一道相似的菜？

若答案只是“我觉得这条 Prompt 很有用”，先别急着建库。让它在几个真实任务里活下来，再把它写成 Skill。

这篇论文仍是一篇预印本，实验主要集中在终端与工具调用任务，覆盖的 Agent 框架和模型数量也有限；它不等于已经证明了所有网页 Agent 或开放式协作场景的规律。但它至少把一个常被忽略的问题说清了：Skill 的效果不是一次注入，而是一条生命周期——蒸馏、检索、调用、适配、验证。

回到开头那张菜单。鬼哥并不需要把所有菜从菜单上划掉；我需要的是知道今天为什么点这道、吃到一半发现不对时能不能换，以及不要把“菜单很丰富”误当成“晚饭已经解决”。

对 Agent 也是一样。

参考资料

Zhiyuan Jiang et al., Demystifying Agent Skills: Why They Work—Until They Don’t, arXiv:2608.14036, 2026.

持续学习 - 读吴恩达老师的 AI Engineering Skills Map

Sun, 16 Aug 2026 00:00:00 +0000

Andrew Ng 最近发布了 The AI Engineering Skills Map。

我原以为，它大概又会列出一串要学的新名词：模型、Agent、RAG、MCP、评估……毕竟这两年 AI 圈最不缺的，就是下一批必须学会的工具。

但读完后，真正让我停下来的不是某个工具，而是其中一项能力：Shaping the build。

当 AI 越来越擅长“按规格把东西做出来”，工程师更重要的工作，反而变成了决定：究竟什么值得被做出来。

我们太擅长围观模型，太少真正走进现场

这两年，AI 圈最不缺的，是围绕模型的热闹。

又一家机构发布了新模型，参数多大，跑分涨了多少，在哪个 benchmark 超过了谁。我们很容易花半天时间讨论它的能力边界，仿佛坐在路边摊上，也能把国际局势分析得头头是道。

信息当然重要。模型进步也确实会改变工程方案。我自己也在关注、在试用、在学习各种 AI Coding 工具、harness 和 Skill。

但读完 Andrew 的文章，我开始反问：这些信息最后有多少变成了我真正做过的东西？我有没有拿一个真实问题去试过、撞过墙、做过评估、承担过一次“它答错了怎么办”的后果？

鬼哥一直有个很朴素的判断：

上过一天战场的普通士兵，强过训练过一年、却从未见过敌人眼中杀气的特种部队。

放到 AI 开发上，这不是鼓吹粗糙上线，而是说：一次真实实践里遇到的脏数据、用户误解、预算约束、模型幻觉和责任边界，比十篇模型评测更能逼着人长出工程判断。

一句“做个 AI 客服”，其实还没有开始定义问题

假设有人对你说：

“我们做一个 AI 客服，提高客服效率吧。”

这句话看起来已经足够清楚。于是很自然的下一步是：选一个模型，接知识库，做一个聊天窗口，必要时再加个 RAG 和转人工按钮。

这些都没错。但这其实是把一个尚未被理解的问题，过早翻译成了一个技术方案。

更值得先问的是：

“效率”到底是谁的效率？是用户更快得到答案，还是客服少处理一些重复问题？
用户来找客服时，真的只需要一个事实答案吗？还是需要确认、安抚、解释，甚至需要一个愿意负责的人？
如果它答错了一次，错的是退款金额、物流状态，还是医疗、金融、账户安全这类高风险问题？
哪些问题可以自动处理，哪些必须立刻转给人？

这些问题会直接改变知识库怎么建、工具权限开多大、评估集怎么选、何时升级人工、界面如何表达不确定性，以及为了可靠性愿意付出多少成本。

所谓“理解用户”“理解人性”，不是产品课上的漂亮话。它会一行一行地进入你的系统设计。

Andrew 的四项能力，恰好解释了差别从哪里开始

Andrew 的团队基于 10,000 多条招聘信息、专家与招聘方访谈、问卷及其他在线数据，归纳出四项最重要的 AI Engineering 能力。对我来说，它们不是一张“待学名词表”，而是一张让那句 AI 客服需求显影的地图。

1. 构建与部署 AI 应用：把“不确定”当作系统属性

传统软件大多是确定性的：同样的输入，通常得到同样的输出。AI 应用不是。你给 LLM 一段上下文，不会完全知道它下一次会怎么回答；你训练一个模型，也无法保证它面对新样本时的判断。

所以 AI 客服的关键从来不是“它能不能回答”，而是：它会怎样答错，我们如何发现、衡量并纠正它。

这就是为什么 Andrew 特别强调 disciplined evals 和 error analysis loops。没有评估和错误分析，所谓优化常常只是换一个 Prompt、换一个模型，然后凭感觉说“似乎好一些”。

2. 软件工程基础：AI 不会替你做取舍

一个客服系统不仅有模型，还有并发、延迟、缓存、数据权限、审计、成本、可用性和隐私。

如果客户上传的订单截图被送进第三方模型，数据如何处理？如果一个工具调用错了退款接口，如何避免不可逆操作？如果高峰期响应慢了 3 秒，用户会等待还是转人工？

这些没有标准答案，只有取舍。工程基础的价值，不是让人比 Agent 多写几行代码，而是让人看见 Agent 看不见、也不会主动替你承担的代价。

3. 使用 Coding Agent：不是让它替你思考，而是让它进入闭环

Coding Agent 能很快搭出客服界面、接好 API、补齐测试的表面结构。它也可能在没有足够上下文时，做出一个看起来合理、实则危险的默认选择。

会用 Agent，远不止会写一段 Prompt。它意味着你知道该给什么上下文，什么时候先规划，什么时候直接执行；更意味着你能给它清晰的 verifier：哪些回答算正确，哪些调用绝不能发生，哪些失败必须自动暴露。

Agent 是执行的杠杆。没有规格、边界和验证，它放大的往往只是含糊。

4. Shaping the build：最难的工作在代码之前

前三项能力让系统能被可靠地做出来；第四项追问的是：它该不该这样被做出来？

当 Agent 越来越擅长交付一份明确的 spec，工程师的价值正从“把 spec 写成代码”，逐渐前移到“参与决定 spec 应该写什么”。

回到 AI 客服：也许真正的问题不是客服打字太慢，而是退款规则本身让用户反复追问；也许用户要的不是一个更会说话的机器人，而是一个能告诉他“这件事已经由谁、在什么时候处理”的确定性。

如果没有走到用户面前，没有理解业务目标和人的感受，再强的模型也只会把错误的问题实现得更快。

持续学习，不是追完每一条模型新闻

Andrew 在最后还提到了一项贯穿所有能力的底层心态：Continuous Learning。

这句话看起来最不“技术”，却可能是最难的一项。

因为 AI 变化太快了。模型在变，Coding Agent 的能力边界在变，工具的最佳实践也在变。两个月前还需要手工拆解的步骤，今天可能已经可以交给 Agent；今天看起来可靠的工作流，下一次模型升级后又可能需要重新设计。

所以，持续学习当然包括关注新模型、试用新工具、阅读好文章。但如果它只停在这些地方，我们又会回到开头那种“围观模型”的热闹里。

我更愿意把它理解成一种把真实反馈不断写回自己脑中的能力：

用一个真实问题做出最小可用的尝试；
看它在真实用户、真实数据和真实约束下怎样失败；
分析失败到底来自模型、上下文、流程、工程设计，还是自己一开始就理解错了需求；
把得到的判断更新进下一次的规格、提示、评估和系统边界；
再去尝试新的模型和工具，而不是把“新”本身当成收获。

这才是一种会越用越强的学习循环。

比如 AI 客服上线后，发现用户不断追问“我的退款到底什么时候到账”。这未必说明模型不够聪明。它也许暴露的是：系统没有接到订单状态、退款流程对用户不透明、客服话术没有说清责任人，或者我们一开始就把“效率”误解成了“少回复几句”。

一次这样的失败，往往比知道某个新模型多了几个 benchmark 分数更有价值。前者会改变你下一次怎么理解问题；后者未必会。

持续学习因此不是把知识库存得越来越满，而是让自己的判断在一次次真实交付中变得更准。它让工具进步不只发生在屏幕上，也发生在使用工具的人身上。

AI 提高了效率，但没有取消人的认知边界

这也是我从这张技能地图里读到的、更私人一点的理解。

AI 确实让我们以前所未有的速度做出页面、功能、原型，甚至一个像模像样的产品。它降低了表达想法的成本，也放大了动手实践的机会。

但它没有自动给我们产品判断，没有自动补齐软件工程的基本功，也不会替我们理解需求背后那个焦虑、愤怒、着急或无助的人。

你给 AI 的不只是 Prompt。你给它的还有：你对用户的理解、你识别风险的能力、你知道哪些地方该慢下来、以及你愿意对什么结果负责。

当然，反过来也成立：你没有看见的约束、没有问出的需求、没有验证的假设，也都会被它更快地编码进产品。

你是什么，你的 AI 就是什么。

每次让 AI 开工前，先问自己五个问题

如果这篇文章只留下一件可以立刻执行的事，我希望是下面这五问：

用户说出的需求，背后真正想解决的是什么？
AI 答错或做错一次，谁承担什么后果？
我用什么真实样本和标准，判断它真的有用？
哪些决策可以交给 AI，哪些必须由人负责？
我现在给 AI 的上下文，是否已经暴露了自己的认知盲区？

AI Coding 最好的时代，或许不是每个人都能更快地生成代码的时代。

而是每个愿意走进真实问题、持续校准自己判断的人，都能把自己的能力更大规模地交付给世界的时代。

参考资料

Andrew Ng, The AI Engineering Skills Map