编码智能体该用「大技能」还是「小工具」？一个框架让它在运行时自己换挡
一句话版本：编码智能体执行任务时面临粒度选择——用打包好的宏技能高效但脆，用原子工具稳但慢。这篇论文提出「自适应技能粒度」：把粒度当成运行时策略来路由，宏技能失败时还能降挡到微操作恢复，兼顾效率与鲁棒性。
老问题：技能库建好了，怎么用没人管
给编码智能体建「技能库」已经是主流做法——把常见任务流程打包成命名技能，写清什么时候用、用什么工具、怎么验证完成。但现有研究几乎都在解决「执行前怎么挑技能」：检索、组合、预规划。
这篇论文指出一个被忽略的运行时控制问题：同一个任务，既可以用原子工具一步步干（搜索、编辑、语法检查、跑测试），也可以用一个宏技能一把梭，还可以混合——先上宏技能，失败后回退到微操作收拾残局。粒度选错，代价完全不同：小 bug 修复用宏技能容易过度打包，模块搬迁用原子工具又慢又贵。
框架：粒度即策略，失败可降挡
「自适应技能粒度」把粒度选择建模成一个以任务结构、执行状态、宏技能失败为条件的行为抽象策略，两个组件：
- 特征粒度控制器：根据任务与执行状态的特征，动态路由下一步走宏还是微；
- 有限状态恢复执行器：宏技能失败不等于全盘重来——显式定义宏→微的降挡转移，把「宏技能走不下去的部分」用原子操作恢复完成。
实验与结论
用确定性编码智能体协议评估，指标除成功率与总成本外，还专门测过程指标：宏采纳率、失败恢复率、路由匹配度、转移正确性。
结论很清晰：
- 固定宏执行：任务匹配时高效，但一旦错配就脆——失败的宏技能在固定粒度下无解；
- 运行时路由 + 显式宏微恢复：鲁棒性显著提升，能救回固定粒度下救不回的受控宏失败。
论文最值得记的一句结论：技能库不应只被当作「可检索的资源」，而应是「可控、可验证、可恢复的执行抽象」——把技能从静态文档变成运行时的一等控制对象。
对我们的启发
- 给智能体配技能时，别只想着「存」和「取」。BuddyMe 工作流的任务模板同理：模板适合的场景走模板，模板外的场景要允许智能体降级到逐步执行——这需要在任务设计里预留降挡路径，而不是要求模板覆盖一切。
- 失败恢复是设计出来的，不是碰运气。宏技能失败后怎么降挡、降到哪一级、降挡后怎么衔接，显式写进状态机，比指望模型自己临场发挥可靠得多。
- 长期看，智能体的「经验沉淀」不只是积累技能条目，还包括积累何时该用哪条技能、何时该放弃它的路由知识。
构建这类可控智能体工作流，可以试试 BuddyMe——每日免费 4500 万 Token。
---
- 论文：Adaptive Skill Granularity for Coding Agents: Runtime Routing and Macro-to-Micro Recovery（arXiv:2610.31461）
- 代码：github.com/Jayceon-3/Adaptive-Skill-Agent