给编码 agent 拆技能，颗粒度比数量重要

给编码 agent 攒技能库的人常遇到怪事：技能攒了几十条，任务成功率没见涨，单个任务耗时反而变长了。10 月 22 日挂出的一篇论文给了一个解释——问题多半不在技能数量，在颗粒度。

一、发生了什么

这篇论文把技能颗粒度当成一个运行时决策问题。同一个编码任务，可以让 agent 直接调底层工具，也可以走一个打包好的大技能，还可以先走大技能、中途失败再退回逐步调用。作者搭了一套框架：一个基于特征的控制器根据任务结构、执行状态和大技能的失败情况，决定当下该用哪种粒度；另配一个状态机专门处理大技能失败后的回退。评测用确定性的编码任务协议，以验证器判定成败，除总成本外还统计了大技能采用率、失败恢复率、路径匹配等过程指标。结论很清晰：固定用大技能，顺的时候最快，但一旦场景不匹配就很脆；运行时路由加上明确的由宏到微的回退，能救回一部分固定粒度方案救不回的失败。

二、跟你有什么关系

自己给 agent 写技能文件的工程师：技能不是资产越多越好，配置不当的大技能是负资产。维护团队共享技能库的人：该给每个技能补的不只是描述，还有失败后的退路。做 agent 评测的人：只看最终成功率会漏掉一半问题，过程指标更值得记录。

这是背景，不是论文结论：目前主流的编码 agent 普遍靠一份或多份说明文件向模型注入流程指引，技能库的检索与组合已有不少研究，但「执行到一半该换哪种粒度」这个环节很少有人专门处理。日常使用里最常见的翻车场景就是大技能硬套：一个为某类仓库写的部署技能，被拿去套结构完全不同的项目，卡在第三步反复重跑，还不如让模型现场逐步操作。这正是论文里「固定粒度在错配时变脆」的现实版本。

三、怎么用

1. 只把高频、稳定、步骤固定的流程做成大技能，低频或易变的任务留在工具级操作。
2. 每个大技能都写清楚失败后怎么退回：哪一步失败、退到哪、哪些中间产物可以复用。
3. 用验证器自动判成败，定期统计每个技能的采用率和失败恢复率，砍掉长期没人选中或失败后救不回的技能。

顺序很重要：先跑通第 1 步的筛选，再谈第 2 步的回退设计，最后才轮到第 3 步的量化淘汰。反过来先堆一批技能再补治理，返工成本会高得多。

四、三个别信的说法

技能越多越强。这篇论文的对照显示，固定粒度的大技能在场景不匹配时反而拖累整体表现，颗粒度得当比数量堆叠更管用。

失败了多重试几次就行。论文强调的是显式的回退结构：从大技能退回细粒度操作，而不是在同一个粒度上盲目重跑，两者的恢复效果不同。

论文结论可以直接照搬到生产。这是背景，不是论文结论：该研究用的是确定性协议下的受控评测，真实代码库的环境噪声大得多，具体收益要自己量。

五、一句话结论

技能库不该只当检索资源，它要能路由、能验证、能回退，才算合格的执行抽象。颗粒度是设计出来的，不是攒出来的。

信息来源

• arXiv：编码 agent 的自适应技能颗粒度（2026-10-22）

功能与价格以官方公告为准。本文写于 2026 年 10 月 26 日。