Agent开发先拆能力再改skill：SkillFocus能力拆解方法论

1. 为什么“先拆能力”比“先改 skill”更重要

做 Agent 开发的人，大概都经历过这样一个循环：发现 Agent 在某类任务上表现不好，第一反应是去改 skill——加几条规则、补几个示例、调一下触发条件，然后重新跑一遍，发现好像好了一点，但换个场景又不行了。再改，再跑，再崩。几轮下来，skill 文件越来越长，注释比正文还多，可 Agent 的整体能力并没有实质提升。

这个循环的根源，是把“能力问题”和“skill 问题”混为一谈了。SkillFocus 这篇论文要解决的核心问题，恰恰就是这件事：在决定怎么改 skill 之前，先把 Agent 当前到底具备什么能力、缺什么能力、能力之间的依赖关系是什么，拆清楚。

我自己的体会是，Agent 的能力不是一个扁平的清单，而是一张有层次、有依赖、有强弱之分的网。比如一个“代码审查”能力，它底层依赖“代码理解”“缺陷模式识别”“上下文检索”，上层又和“修改建议生成”“优先级排序”耦合在一起。如果你只看到“审查结果不准”，直接去改审查 skill 的提示词，很可能改的是最上层那一片叶子，根上的“缺陷模式识别”没动，效果自然不稳定。

SkillFocus 的思路可以概括成一句话：把能力当作一等公民来建模，skill 只是能力的一种实现载体。能力拆清楚了，skill 该改哪里、该不该改、改了会影响什么，才有判断依据。这听起来像是一句正确的废话，但真正落到工程里，大部分团队是反着做的——先有 skill，再从 skill 反推能力，结果能力边界被 skill 的实现细节绑架了。

这篇精读我想做的事情，不是逐段翻译论文，而是把 SkillFocus 里那套“能力拆解”的方法论，翻译成一线开发者能直接上手的东西。我会讲清楚它怎么定义能力、怎么度量能力、怎么判断一个能力该由 skill 承担还是该由框架承担，以及最关键的——拆完之后，skill 的修改决策是怎么做出来的。如果你正在维护一个多 skill 的 Agent 系统，或者正在纠结“这个功能到底该写成 skill 还是写进 prompt”，这篇应该能帮你省下不少来回试错的时间。

2. SkillFocus 对“能力”的定义：不是功能列表，而是可观测的行为单元

2.1 能力和功能的区别：一个反直觉的切入点

大多数人描述 Agent 能力时，用的是功能语言：“它能查天气”“它能写代码”“它能总结文档”。这是功能视角，不是能力视角。功能是“Agent 做了什么”，能力是“Agent 在什么条件下、以什么质量、稳定地做到什么”。

SkillFocus 对能力的定义更接近后者：能力是一个可观测、可度量、有输入输出边界的行为单元，它在特定条件下被触发，并产生可评估的结果。这个定义里有三个关键词，每一个都对应一个工程上的坑。

第一个是“可观测”。很多团队写 skill 的时候，能力是隐式的——它藏在 prompt 的某一段里，藏在某个工具调用的组合里，你没法单独把它拎出来测。SkillFocus 要求能力必须能被单独观测，这意味着你得能为它设计独立的测试用例，而不是只能端到端跑一遍看整体效果。

第二个是“可度量”。能力不能只有“好/不好”这种二元判断，得有连续的度量维度。比如“代码理解”能力，可以用“给定一段代码，能否正确回答关于它的结构性问题”来度量，准确率、响应一致性、边界情况覆盖率都是维度。

第三个是“有输入输出边界”。这是最容易被忽略的。一个能力如果边界模糊，它就会和相邻能力纠缠，改一个动全身。SkillFocus 强调边界清晰，本质上是为了让 skill 的修改影响面可控。

2.2 能力的三个层次：原子能力、组合能力、元能力

SkillFocus 把能力拆成三层，这个分层是我认为整篇论文里最实用的部分。

原子能力是最小可观测单元，不能再拆，或者再拆就失去工程意义。比如“识别代码中的空指针风险”可以算原子能力，“识别代码中的空指针风险并给出修复建议”就不算，因为它其实是两个能力。原子能力的判断标准是：它能否被一个独立的测试用例覆盖，且这个测试用例不依赖其他能力的输出。

组合能力由多个原子能力按特定流程编排而成。比如“代码审查”就是组合能力，它调用“代码理解”“缺陷识别”“严重性排序”“建议生成”等原子能力。组合能力的关键不是它包含哪些原子能力，而是编排逻辑——同样的原子能力，不同的编排顺序和触发条件，会得到完全不同的组合能力表现。

元能力是控制层的能力，它决定“什么时候调用哪个能力”“调用失败了怎么办”“多个能力冲突时怎么取舍”。元能力最典型的例子是“任务分解”和“结果校验”。很多 Agent 表现不稳定，问题不在原子能力弱，而在元能力缺失——它不知道该在什么时候停下来检查，也不知道该在什么时候换一条路。

这三层的区分，直接决定了 skill 的修改策略。原子能力弱，改的是具体实现；组合能力弱，改的是编排逻辑；元能力弱，改的是控制策略。如果你不区分层次，就会用改原子能力的方式去改元能力问题，比如给一个“任务分解”有问题的 Agent 加更多工具示例，这基本是无效的。

2.3 能力依赖图：为什么改一个 skill 会牵动一片

SkillFocus 用依赖图来描述能力之间的关系。节点是能力，边是依赖。这个图不是画着好看的，它直接回答一个工程问题：我改这个 skill，会影响哪些其他能力？

举个具体的例子。假设你的 Agent 有一个“文档摘要”skill，它依赖“长文本理解”和“关键信息抽取”两个原子能力。如果你发现摘要质量下降，去改摘要 skill 的 prompt，可能有两种结果：一种是摘要 skill 本身的问题，改了有效；另一种是“关键信息抽取”能力退化了，改摘要 skill 只是治标。依赖图能让你快速定位：先测“关键信息抽取”的独立表现，如果它没问题，再往上查。

更隐蔽的是反向依赖。有些能力是多个组合能力共享的原子能力。比如“实体识别”可能同时被“摘要”“问答”“检索”三个组合能力依赖。你为了优化摘要去改实体识别的 skill，很可能把问答和检索一起改坏。依赖图的价值就在于，它让你在动手之前就知道影响面。

我自己的做法是，维护一个简化的能力依赖表，不追求完整，但要求每个 skill 都能对应到至少一个能力节点，并且标注它依赖谁、被谁依赖。这个表不需要很精确，但有了它，改 skill 之前扫一眼，能避免很多“改 A 崩 B”的事故。

3. 能力度量：怎么判断一个能力是真的弱，还是只是没触发

3.1 触发率和成功率的分离

这是 SkillFocus 里我认为最容易被低估的一个点。一个能力表现不好，有两种完全不同的原因：该触发的时候没触发（触发率低），或者触发了但做错了（成功率低）。这两种问题的修复方向完全相反。

触发率低，说明元能力或者触发条件有问题——Agent 没意识到该用这个能力。这时候你去改能力本身的实现，是南辕北辙。成功率低，说明能力实现有问题，这时候改触发条件也没用。

SkillFocus 建议把这两个指标分开度量。具体做法是：为每个能力设计一组“应该触发”的测试用例，统计实际触发比例；再为“已触发”的用例统计成功比例。两个数字一对比，问题定位就清楚了。

我实测下来，大部分团队报的“能力不行”，其实是触发率问题。Agent 不是不会做，是没意识到要做。这又回到元能力——它缺少“识别当前场景需要什么能力”的判断逻辑。

3.2 能力度量的四个维度

SkillFocus 提出的度量框架有四个维度，我结合自己的实践解释一下。

稳定性这一维特别值得说。很多 skill 在单次测试里表现很好，但多跑几次就飘。这通常是因为 skill 的实现依赖了不确定的因素——比如 prompt 里有过多的自由发挥空间，或者工具调用的顺序不固定。SkillFocus 强调稳定性度量，本质上是逼你把 skill 的实现收敛到确定性的路径上。

边界覆盖则是另一个重灾区。正常用例谁都能过，真正区分能力强弱的是边界。比如“代码理解”能力，正常代码没问题，但遇到超长文件、嵌套极深的逻辑、非标准语法时还能不能用，这才是关键。

3.3 度量结果怎么指导 skill 修改决策

度量不是为了打分，是为了做决策。SkillFocus 给了一个很实用的决策矩阵：

• 触发率低 + 成功率低：能力本身可能就不该存在，或者定义有问题。先重新审视能力边界，再考虑实现。
• 触发率低 + 成功率高：能力实现没问题，问题在元能力或触发条件。改的是控制层，不是 skill 本身。
• 触发率高 + 成功率低：典型的 skill 实现问题，直接改 skill 的实现逻辑。
• 触发率高 + 成功率高：能力没问题，如果整体表现还差，问题在组合能力或元能力层。

这个矩阵的价值在于，它把“改 skill”从一个默认动作，变成了一个需要条件判断的决策。我见过太多团队，不管什么问题都去改 skill，结果 skill 越改越复杂，问题却还在。

4. 从能力拆解到 skill 修改：一套可复现的决策流程

4.1 第一步：建立能力清单，而不是 skill 清单

大部分团队的文档里，列的是 skill 清单：有哪些 skill、每个 skill 干什么。SkillFocus 建议反过来，先列能力清单，再映射到 skill。

具体操作上，我会这样做：拿一张白纸，不看现有 skill，只从 Agent 要完成的端到端任务出发，问“要完成这个任务，Agent 需要具备哪些能力”。这个过程要克制，不要一上来就写“调用某某工具”，那是实现，不是能力。

列完之后，再和现有 skill 做映射。你会发现两种情况：一种是一个能力对应多个 skill，说明 skill 拆得太细，可以考虑合并；另一种是一个 skill 承载多个能力，说明这个 skill 职责过重，是修改时的风险点。

4.2 第二步：给每个能力标注依赖关系和度量状态

能力清单列出来后，给每个能力补两个信息：它依赖哪些能力，以及它当前的度量状态（触发率、成功率、稳定性、边界覆盖）。

这一步的产出是一张能力状态表。这张表不需要很精细，但要求每个能力都有明确的度量结论，不能是“感觉还行”。我自己的经验是，只要逼着自己把“感觉”变成数字，很多之前以为的问题就不是问题，很多之前忽略的问题会浮出来。

4.3 第三步：定位问题层次，决定改什么

有了能力状态表，问题定位就变成了查表。整体表现差，先看是哪个能力拖后腿；找到能力后，看是触发问题还是执行问题；触发问题查元能力，执行问题查 skill 实现。

这里有个关键判断：如果一个能力的问题可以通过改 skill 解决，那它大概率是原子能力或组合能力的实现问题；如果改 skill 解决不了，那它大概率是元能力问题。元能力问题改 skill 是无效的，因为元能力控制的是“什么时候用 skill”，而不是“skill 怎么做”。

4.4 第四步：小步修改，单能力回归验证

确定要改 skill 之后，SkillFocus 强调单能力回归验证。也就是说，改完一个 skill，先只测它对应的那个能力，确认这个能力提升了，再跑端到端。

这一步看起来慢，实际上快。因为如果你直接跑端到端，整体提升了你不知道是哪个改动起的作用，整体没提升你也不知道是改错了还是被其他能力拖累了。单能力回归让每次修改的因果清晰。

我自己的做法是，每个 skill 修改都配一个最小测试集，只覆盖这个 skill 对应的能力。改完先跑这个集，过了再跑全量。这个习惯帮我省了很多“改了三天发现方向错了”的时间。

5. 实操中的坑：能力拆解容易走偏的几个地方

5.1 拆得太细，导致 skill 碎片化

能力拆解的第一个坑是过度拆分。把“代码理解”拆成“变量识别”“控制流识别”“数据流识别”“类型推断”……拆到最后每个能力都小得没法独立测试，skill 也碎成一地。

SkillFocus 的判断标准是：拆到能被独立测试用例覆盖为止，不要再往下拆。如果一个能力你没法为它写一个不依赖其他能力的测试用例，说明它还不是原子能力，或者你拆错了维度。

我自己的经验是，原子能力的粒度大概对应“一个明确的输入，一个明确的输出，一个明确的判断标准”。超过这个粒度就是组合能力，低于这个粒度就是实现细节。

5.2 把实现细节当成能力

第二个坑是把实现细节写进能力清单。比如“调用搜索工具”不是能力，“信息检索”才是能力。区别在于，能力是目标导向的，实现是手段导向的。如果你把手段当能力，skill 的修改就会变成“换工具”，而不是“提升能力”。

这个坑的隐蔽之处在于，它会让你的能力清单看起来很长很充实，但实际上没有指导价值。判断方法是：如果一个“能力”换一种实现方式就不成立了，那它是实现，不是能力。

5.3 忽略元能力，把所有问题都归到 skill

第三个坑是最常见的：Agent 表现不好，默认去改 skill。但很多问题的根源在元能力——Agent 不知道该用什么能力、不知道什么时候停、不知道结果对不对。

SkillFocus 反复强调元能力的独立性，就是因为元能力问题用 skill 层面的修改是解决不了的。你需要单独设计元能力的度量，单独优化控制策略。比如“任务分解”能力弱，你要改的是分解逻辑，而不是某个具体 skill 的实现。

5.4 度量一次就定论，忽略能力的动态变化

第四个坑是把能力度量当成一次性工作。Agent 的能力会随着 skill 修改、模型更新、数据变化而漂移。上个月测的触发率，这个月可能就不一样了。

SkillFocus 建议把能力度量做成持续的过程，至少在每个 skill 修改后重新测相关能力。我自己的做法是，把能力测试集纳入 CI，每次 skill 变更自动跑一遍，有退化就报警。这个投入不大，但能避免很多“悄悄变坏”的问题。

6. 一个具体的拆解案例：从“摘要不准”到定位到元能力

6.1 问题现象和初始判断

假设你的 Agent 有一个文档摘要功能，最近用户反馈摘要质量下降。初始判断很自然：摘要 skill 有问题，去改摘要 skill 的 prompt。

但如果按 SkillFocus 的流程走，第一步不是改，是拆。摘要这个组合能力，拆开来看至少包含：长文本理解、关键信息抽取、重要性排序、摘要生成。四个原子能力，加上一个编排逻辑。

6.2 逐层度量后的发现

分别度量四个原子能力，结果可能是：长文本理解正常，关键信息抽取正常，重要性排序正常，摘要生成正常。四个原子能力都没问题，但组合起来就是不行。

这时候问题就定位到了编排逻辑或者元能力。继续查，发现是编排逻辑里“重要性排序”和“摘要生成”之间的衔接有问题——排序结果没有正确传递给生成环节，导致生成用的是原始顺序。这是一个组合能力层面的编排 bug，不是任何单个 skill 的实现问题。

如果一开始就去改摘要 skill 的 prompt，这个 bug 永远修不好，因为 prompt 改的是生成逻辑，而问题在传递逻辑。

6.3 这个案例的通用启示

这个案例的启示是：组合能力的问题，往往不在组件，在连接。SkillFocus 的能力拆解之所以要先拆再改，就是为了让你能区分“组件问题”和“连接问题”。组件问题改 skill，连接问题改编排，元能力问题改控制策略。三者混在一起，就只能靠试。

我后来把这个思路固化成了一个检查顺序：先测原子能力，再测组合能力的编排，最后测元能力。按这个顺序走，大部分问题都能在十分钟内定位到层次，而不是花几天在 skill 里瞎改。

7. 把 SkillFocus 的思路落到日常开发里

7.1 能力清单作为 skill 设计的前置文档

我现在做新 skill 之前，会先写能力清单，而不是先写 skill。能力清单里明确：这个 skill 承载哪个能力、这个能力的输入输出边界是什么、它依赖哪些已有能力、它被哪些组合能力依赖。

这个文档不需要很长，但要求每个字段都有明确答案。写不出来，说明能力还没想清楚，这时候写 skill 大概率会返工。

7.2 修改 skill 前的三问

每次要改 skill 之前，我会问三个问题：

1. 这个问题是触发问题还是执行问题？触发问题不改 skill。
2. 这个能力是原子能力还是组合能力？组合能力优先查编排。
3. 改完之后，哪些能力可能受影响？依赖图上有哪些邻居？

这三个问题答完，再动手。实测下来，能过滤掉至少一半的无效修改。

7.3 能力度量的最小可行方案

不需要一上来就搞很复杂的度量体系。最小可行方案是：每个能力配 5 到 10 个测试用例，覆盖正常、边界、异常三类；每次 skill 修改后跑一遍；记录触发率和成功率两个数字。

这个投入大概每个能力半小时，但收益是长期的。有了这两个数字，skill 修改从“凭感觉”变成“看数据”，决策质量完全不一样。

7.4 元能力的单独维护

元能力容易被忽略，但它其实是 Agent 稳定性的关键。我建议把元能力单独列出来，单独设计测试，单独优化。元能力的测试用例和普通能力不一样，它测的是“在什么情况下选择什么能力”，而不是“能力本身做得好不好”。

比如“任务分解”元能力，测试用例应该是：给定一个复杂任务，看 Agent 是否把它拆成了合理的子任务，子任务之间的依赖是否正确。这类测试比普通能力测试更难设计，但价值更高。

8. 我对 SkillFocus 这套方法的一点个人体会

SkillFocus 这篇论文最打动我的地方，不是它提出了什么新算法，而是它把一件被大家默认跳过的事情——能力拆解——变成了一个必须显式完成的步骤。在 Agent 开发里，我们太习惯从 skill 出发，太习惯用“改 prompt”解决一切问题，结果就是 skill 越堆越多，系统越来越脆。

能力拆解的价值，在于它把“改什么”这个问题，从直觉变成了推理。你先知道能力是什么、能力之间什么关系、能力当前什么状态，然后才知道该改哪里。这个顺序反过来，就是无尽的试错。

我自己实践下来，最大的变化是改 skill 的频率降低了，但每次改的有效性提高了。以前是每周改好几个 skill，每个都改一点，整体没变化；现在是两周改一个 skill，但改完确实有提升。慢即是快，这句话在 Agent 开发里特别成立。

还有一个体会是，能力拆解这件事，越早做越好。等 skill 堆到几十个再回头拆，成本极高。最好是从第一个 skill 开始，就养成先拆能力再写 skill 的习惯。这个习惯的复利，在系统规模上去之后会非常明显。

最后说一个具体的技巧：能力清单不要写在文档里就完了，要让它活起来。我的做法是把能力清单和测试集绑定，每个能力对应一个测试文件，能力清单里直接链接到测试文件。这样能力清单不是一份静态文档，而是一个可执行、可验证的活体。改 skill 之前扫一眼能力清单，改完之后跑一遍对应测试，整个流程就闭环了。这个闭环建立起来之后，Agent 的持续进化才真正有了工程基础，而不是靠不断堆 skill 来碰运气。