1. 为什么“先拆能力再改 Skill”是 Agent 进化的分水岭做 Agent 开发的人几乎都经历过这样一个阶段发现 Agent 在某类任务上表现不行第一反应就是去改 Skill——改提示词、加示例、补工具、调参数改完跑一遍好像好了点过两天换个场景又崩了。然后继续改继续崩陷入一种“打地鼠”式的循环。我自己带过几个 Agent 项目踩过最深的坑就是这个。后来读到 SkillFocus 这篇论文的思路有一种被点醒的感觉问题往往不在 Skill 本身而在于你根本没搞清楚 Agent 到底缺的是哪个能力。你把一个“推理能力不足”的问题当成“工具调用格式不对”来修那当然修不好。这篇论文精读的核心主张其实就一句话在决定怎么改 Skill 之前先把 Agent 的能力拆清楚。听起来像废话但真正落地的时候绝大多数人跳过的恰恰就是这一步。这篇文章我打算按自己的理解把 SkillFocus 这套“能力拆解优先”的方法论完整拆一遍。包括它为什么要这么设计、能力到底怎么拆、拆完之后怎么映射到 Skill 的修改动作、实操中怎么落地、以及我在实际项目里踩过的那些坑。适合正在做 Agent 开发、被 Skill 调优折磨过的朋友也适合刚开始搭 Agent 框架、想少走弯路的人。不管你是用哪套框架这套思路都是通用的。2. SkillFocus 到底在解决什么问题2.1 传统 Skill 调优的三大盲区先说清楚痛点不然方法论听起来都是空中楼阁。传统做法里Skill 调优基本靠“感觉 试错”背后有三个很典型的盲区。第一个盲区把能力问题当成格式问题。比如 Agent 做多步推理任务时总是漏掉中间步骤很多人的第一反应是“提示词没写清楚”于是往 Skill 里塞更多 few-shot 示例。但如果真实原因是模型的长链推理能力在某个复杂度阈值上衰减你塞再多示例也没用因为瓶颈不在格式在能力。第二个盲区Skill 改动没有归因。你同时改了提示词、加了工具、调了温度参数跑出来效果变好了但你不知道是哪一项起了作用。下次遇到类似问题你没法复用这次的经验只能重新试。这就是典型的“改了但没学到”。第三个盲区能力评估粒度太粗。大多数团队评估 Agent 就看一个端到端的成功率。这个数字太粗了它无法告诉你 Agent 是“理解任务”这一步出了问题还是“规划步骤”出了问题还是“执行工具”出了问题。粒度不够就没法精准定位。SkillFocus 的价值就在于它把这三个盲区一次性摊开了先建立能力维度的评估再做归因最后才动 Skill。2.2 能力拆解和 Skill 修改的关系这里要讲清楚一个关键逻辑能力拆解不是目的它是 Skill 修改的前置条件。打个比方。你去看医生医生不会一上来就给你开药。他先问诊、检查、定位病灶然后才开方。Skill 修改就是“开方”能力拆解就是“问诊 检查”。跳过问诊直接开方就是瞎治。在 Agent 场景里这个逻辑链条是这样的Agent 在任务上表现不佳现象通过能力拆解定位到具体是哪个能力维度薄弱诊断判断这个能力维度是否可以通过 Skill 层面改善可行性判断如果可以设计针对性的 Skill 修改处方验证修改是否真的提升了该能力维度复诊大部分人的问题出在第二步和第三步之间——他们跳过了诊断直接假设“所有问题都能靠改 Skill 解决”。但事实是有些能力短板是 Skill 改不动的比如模型本身的知识边界、上下文窗口的硬限制。这时候你改 Skill 就是白费力气正确的做法可能是换模型、拆任务、或者加外部检索。2.3 这套方法论适合谁用说句实在话SkillFocus 这套思路不是给“玩具级 Agent”准备的。如果你只是搭个 demo 玩玩端到端跑通就行那不需要这么重的方法论。但如果你符合下面任何一种情况这套东西就值得认真看Agent 已经上线有真实用户在用效果波动会直接影响业务你在做 Agent 的持续迭代需要一套可复用的调优流程团队里多个人协作开发 Agent需要统一的评估和归因语言你被“改了 Skill 但说不清为什么有效”这个问题困扰过我自己的经验是Agent 项目从 demo 走向生产最大的门槛不是技术难度而是迭代效率。谁能更快地定位问题、更准地修改、更可靠地验证谁就能把 Agent 真正做出来。SkillFocus 提供的正是这套迭代效率的底层方法。3. 能力拆解把 Agent 的“黑盒”打开3.1 能力维度的划分逻辑能力拆解的第一步是确定拆成哪几个维度。这里没有唯一标准答案但有几个原则必须遵守。原则一维度之间要尽量正交。如果两个维度高度相关那拆了等于没拆。比如“理解能力”和“推理能力”在很多任务里是耦合的你得想办法把它们分开评估。原则二维度要可观测。每个维度都得有对应的评估方法能给出一个相对客观的分数或判断。不能观测的维度拆出来也没用。原则三维度要能映射到修改动作。拆出来的能力维度最终要能指导你“改什么”。如果一个维度拆出来之后你不知道该动 Skill 的哪部分那这个维度就太抽象了。基于这三个原则SkillFocus 的思路里Agent 能力通常可以拆成这么几层能力层级具体维度典型表现感知层任务理解、意图识别、约束提取能不能准确读懂用户要什么认知层推理、规划、分解、反思能不能想出正确的解决路径执行层工具选择、参数构造、结果解析能不能把想法正确落地交互层多轮记忆、上下文管理、澄清提问能不能在对话中保持一致性元能力层自我评估、错误恢复、边界感知知不知道自己行不行这个划分不是死的你可以根据自己 Agent 的任务类型调整。比如做代码 Agent执行层可能要再细分成“代码生成”和“代码调试”做客服 Agent交互层的权重会更高。3.2 每个能力维度的评估方法拆完维度接下来是评估。这一步是很多人卡住的地方——知道要拆但不知道怎么测。我的做法是为每个维度设计最小可观测任务。所谓最小可观测任务就是专门针对某一个能力维度设计的、其他维度干扰尽量小的测试用例。举个例子。要测“任务理解”这个维度你可以设计一组任务它们的解决路径都很简单不需要复杂推理但表述方式有各种歧义、隐含约束、多意图混杂。如果 Agent 在这些任务上失败那基本可以归因到理解能力而不是推理或执行。要测“规划能力”就反过来任务表述清晰无歧义但解决路径需要多步分解。如果 Agent 理解对了但步骤乱了那就是规划问题。这里有个实操技巧每个维度的测试集不需要很大10 到 20 个精心设计的用例就够定位问题了。关键是用例的“纯度”要高别一个用例同时考验三四个能力那样测出来也不知道是谁的问题。评估的粒度也要注意。不要只记“通过/不通过”最好能记录失败的具体形态。比如规划能力失败是“步骤顺序错”还是“漏了关键步骤”还是“多做了无用步骤”这些细节直接决定了你后面怎么改 Skill。3.3 能力短板定位的实操流程把上面的东西串起来完整的定位流程大概是这样收集失败案例。从真实使用或测试中收集 Agent 表现不佳的案例越多越好但要注意多样性。粗分类。先按任务类型粗分比如“多步推理类”“工具调用类”“多轮对话类”。逐案例归因。对每个失败案例用能力维度表逐个排查判断最可能的短板维度。这一步最好两个人独立做然后对比减少主观偏差。统计分布。把所有案例的归因结果汇总看哪个能力维度出现频率最高。验证假设。针对高频短板维度用专门设计的最小可观测任务再测一遍确认判断。我踩过的一个坑是归因的时候容易过度自信。看到一个案例觉得“这明显是规划问题”结果深入一看其实是理解阶段就把约束搞错了导致后面规划全歪。所以第三步一定要慢宁可多花时间也别急着下结论。提示归因时建议记录“主因”和“次因”。有些失败是多因素叠加的只记一个主因会丢失信息。次因虽然优先级低但可能在主因修复后暴露出来。4. 从能力短板到 Skill 修改的映射4.1 哪些能力短板 Skill 能修定位到短板之后下一个关键判断是这个短板能不能靠改 Skill 解决这个问题没有标准答案但有一些经验规律。我整理了一张对照表能力维度Skill 可修性说明任务理解高提示词、示例、约束说明都能显著改善推理规划中可以通过思维链、分解模板改善但有上限工具执行高工具描述、参数示例、错误处理都能优化多轮记忆中摘要策略、记忆提取规则可调但受上下文限制知识边界低Skill 改不动需要外部检索或换模型自我评估中可以通过反思提示改善但依赖模型本身能力这张表的核心信息是Skill 修改对“流程性”和“格式性”问题效果好对“能力性”和“知识性”问题效果有限。什么意思如果 Agent 是“知道该怎么做但没做对”那大概率是 Skill 问题改 Skill 有效。如果 Agent 是“根本不知道该怎么做”那可能是模型能力或知识边界问题改 Skill 只能缓解不能根治。4.2 不同短板对应的 Skill 修改策略确定了可修性之后具体怎么改这里按能力维度给几套策略。任务理解短板。核心是减少歧义。具体动作包括在 Skill 里明确列出常见歧义模式和处理规则增加“先复述任务再执行”的步骤对多意图任务强制要求先拆分再处理。我实测下来光是加一个“执行前先用自己的话复述一遍任务”的步骤理解类错误就能降不少。推理规划短板。核心是提供结构化脚手架。具体动作包括在 Skill 里内置任务分解模板要求 Agent 显式输出规划步骤再执行对复杂任务强制分阶段。这里要注意脚手架不能太死太死会限制 Agent 的灵活性反而在简单任务上拖慢速度。工具执行短板。核心是把工具用法的“隐性知识”显性化。具体动作包括为每个工具补充正反示例明确参数边界和常见错误增加工具调用前的参数自检步骤。工具类问题往往是最容易通过 Skill 修复的因为它的失败模式很具体。多轮记忆短板。核心是设计好记忆的“进出规则”。具体动作包括明确什么信息需要记住、什么可以丢弃设计摘要触发条件在多轮中定期做上下文压缩。这块的难点在于平衡记太多会撑爆上下文记太少会丢信息。4.3 修改优先级怎么排短板可能有好几个Skill 修改动作可能有一堆先改哪个我的排序原则是先改影响面大的再改修复成本低的最后改需要重构的。具体来说先看哪个短板在失败案例里出现频率最高优先修。如果两个短板频率差不多选那个修改动作最简单、风险最低的先做。因为 Skill 修改本身也有风险——你改了一处可能影响其他场景的表现。所以先用小改动验证方法论再动大手术。还有一个容易被忽略的点有些短板之间是有依赖关系的。比如理解能力不行会导致规划也做不好。这种情况下你得先修理解再看规划是不是自动就好了。如果顺序搞反了先修规划可能白费功夫。注意每次 Skill 修改最好只动一个变量。同时改多处即使效果变好了你也不知道是哪处起了作用经验无法沉淀。5. 完整实操一次 Skill 迭代的全流程记录5.1 案例背景与初始评估光讲方法论太虚我拿一个自己做过的项目来完整走一遍。项目是一个文档处理 Agent主要任务是读用户上传的各种格式文档提取结构化信息然后按用户要求做汇总或转换。上线后发现在处理“多文档交叉汇总”这类任务时成功率明显偏低大概只有六成左右。按 SkillFocus 的流程第一步不是改 Skill是评估。我收集了 50 个失败案例逐个做能力归因。归因结果分布是这样的任务理解类8 个16%推理规划类27 个54%工具执行类9 个18%多轮记忆类6 个12%很明显规划是主要短板。但 54% 这个数字还不够我得知道规划具体是怎么失败的。5.2 能力短板的精确定位把 27 个规划类失败案例再细看发现三种典型形态步骤遗漏Agent 汇总时漏掉了某些文档的关键信息占 11 个顺序错误先做了汇总再做提取导致汇总基于不完整信息占 9 个过度分解把简单任务拆得太碎反而增加了出错概率占 7 个这三种形态对应的 Skill 修改方向其实不一样。步骤遗漏要补检查机制顺序错误要固定流程过度分解要加复杂度判断。如果不做这层细分笼统地“改规划”很可能改了一个方向另外两个方向的问题还在。我又针对“步骤遗漏”设计了一组最小可观测任务给 Agent 三到五篇文档要求提取每篇的关键信息再汇总文档数量、格式、信息密度都做了控制。结果确认当文档数量超过三篇时遗漏率明显上升。这就把问题定位得很具体了多文档场景下的信息覆盖不完整。5.3 Skill 修改方案的设计与验证定位清楚之后修改方案就有的放矢了。我做了三处改动第一处在 Skill 里加入显式的文档清单步骤。要求 Agent 在处理多文档任务时先列出所有待处理文档每处理完一篇就标记最后检查清单是否全部完成。这一步直接针对“步骤遗漏”。第二处固定处理流程。明确要求“先逐篇提取再统一汇总”不允许 Agent 自行调整顺序。这一步针对“顺序错误”。第三处加复杂度判断。在 Skill 开头加一个判断如果文档数量少于三篇且结构简单走简化流程不做过度分解。这一步针对“过度分解”。改完之后用同一批测试集验证。多文档汇总的成功率从六成提到了八成五左右。更重要的是三种失败形态的分布变了步骤遗漏基本消失顺序错误大幅减少过度分解也改善了。这里有个细节值得说我没有一次性把三处改动都上而是分三次上每次只改一处单独验证。这样我能清楚知道每处改动各自的贡献。实测下来第一处改动贡献最大第二处次之第三处主要是提升了简单场景的效率对成功率贡献不大但降低了延迟。5.4 迭代后的效果复盘这次迭代让我对 SkillFocus 这套方法论有了更实的体感。几个关键收获归因的精度决定了修改的精度。如果我只停在“规划能力不足”这一层修改方案大概率是笼统的“优化规划提示词”效果肯定不如现在。最小可观测任务是真的有用。它帮我确认了“文档数量”这个关键变量如果没有这一步我可能会以为是文档格式的问题改错方向。分步验证比一次性改完更值。虽然慢一点但经验能沉淀下来下次遇到类似问题我知道优先改哪里。6. 实操中的常见问题与避坑指南6.1 能力拆解阶段的典型误区误区一维度拆得太细。有人一上来拆出十几个能力维度结果每个维度都没法好好评估反而增加了工作量。我的建议是初次做拆解控制在五到七个维度够用就行后续有需要再细分。误区二用端到端指标代替维度评估。这是最常见的。端到端成功率是个结果指标不是诊断指标。你得有维度级的评估才能定位问题。误区三归因时只看失败案例。其实成功案例也值得看尤其是“侥幸成功”的案例——Agent 用了错误的方式但碰巧对了。这类案例往往藏着隐患换个场景就会暴露。6.2 Skill 修改阶段的常见坑坑一改动过大无法归因。前面提过一次只改一个变量。但实操中很容易忍不住看到问题就想一起改。我的做法是把想改的都列出来排个优先级一次只上一个。坑二忽略回归测试。改完 Skill只测了目标场景没测其他场景结果修好了 A 场景搞坏了 B 场景。每次修改后都要跑一遍完整的回归测试集。坑三把 Skill 当万能药。有些短板 Skill 真的修不动比如模型的知识边界。这时候要果断承认转向其他方案别在 Skill 上死磕。6.3 效果验证与回归测试要点验证这块我整理了一个检查清单每次迭代都过一遍检查项目的通过标准目标场景测试确认修改有效目标指标提升且稳定回归测试确认没搞坏其他场景其他场景指标不下降边界测试确认极端情况可控边界场景不崩溃稳定性测试确认不是偶然多次运行结果一致成本测试确认没引入额外开销延迟和 token 消耗可接受最后一项“成本测试”经常被忽略。有些 Skill 修改确实提升了成功率但代价是 token 消耗翻倍或者延迟大幅增加。这种修改在生产环境里未必划算得综合权衡。提示建议给每次 Skill 迭代建一个简单的记录包括修改内容、验证结果、遗留问题。积累几次之后你会发现自己对“什么改动有效”的判断越来越准。7. 我对这套方法论的真实体会做 Agent 这几年我越来越觉得Agent 开发的难点不在“能不能做出来”而在“能不能持续做好”。前者靠技术选型和快速原型后者靠的是迭代方法论。SkillFocus 这套“先拆能力再改 Skill”的思路本质上就是一套迭代方法论。它最大的价值不是某个具体技巧而是把“改 Skill”这件事从“凭感觉试错”变成了“有依据的工程流程”。你不再需要靠运气去猜哪里出了问题而是有一套可重复的流程去定位、修改、验证。当然这套方法也不是银弹。它需要你投入时间做评估、做归因前期看起来比“直接改”慢。但拉长看它省下的是反复试错的时间而且积累下来的经验是可复用的。我自己的项目从这套方法里受益最大的不是某一次具体的成功率提升而是整个团队对“Agent 为什么不行”这件事有了共同的语言和判断框架。如果你现在正被 Skill 调优折磨我的建议是下次遇到问题先别急着改 Skill。花半天时间把失败案例收集起来做一次能力归因。你可能会发现真正要改的地方和你一开始想的完全不一样。
1. 为什么“先拆能力再改 Skill”是 Agent 进化的分水岭做 Agent 开发的人几乎都经历过这样一个阶段发现 Agent 在某类任务上表现不行第一反应就是去改 Skill——改提示词、加示例、补工具、调参数改完跑一遍好像好了点过两天换个场景又崩了。然后继续改继续崩陷入一种“打地鼠”式的循环。我自己带过几个 Agent 项目踩过最深的坑就是这个。后来读到 SkillFocus 这篇论文的思路有一种被点醒的感觉问题往往不在 Skill 本身而在于你根本没搞清楚 Agent 到底缺的是哪个能力。你把一个“推理能力不足”的问题当成“工具调用格式不对”来修那当然修不好。这篇论文精读的核心主张其实就一句话在决定怎么改 Skill 之前先把 Agent 的能力拆清楚。听起来像废话但真正落地的时候绝大多数人跳过的恰恰就是这一步。这篇文章我打算按自己的理解把 SkillFocus 这套“能力拆解优先”的方法论完整拆一遍。包括它为什么要这么设计、能力到底怎么拆、拆完之后怎么映射到 Skill 的修改动作、实操中怎么落地、以及我在实际项目里踩过的那些坑。适合正在做 Agent 开发、被 Skill 调优折磨过的朋友也适合刚开始搭 Agent 框架、想少走弯路的人。不管你是用哪套框架这套思路都是通用的。2. SkillFocus 到底在解决什么问题2.1 传统 Skill 调优的三大盲区先说清楚痛点不然方法论听起来都是空中楼阁。传统做法里Skill 调优基本靠“感觉 试错”背后有三个很典型的盲区。第一个盲区把能力问题当成格式问题。比如 Agent 做多步推理任务时总是漏掉中间步骤很多人的第一反应是“提示词没写清楚”于是往 Skill 里塞更多 few-shot 示例。但如果真实原因是模型的长链推理能力在某个复杂度阈值上衰减你塞再多示例也没用因为瓶颈不在格式在能力。第二个盲区Skill 改动没有归因。你同时改了提示词、加了工具、调了温度参数跑出来效果变好了但你不知道是哪一项起了作用。下次遇到类似问题你没法复用这次的经验只能重新试。这就是典型的“改了但没学到”。第三个盲区能力评估粒度太粗。大多数团队评估 Agent 就看一个端到端的成功率。这个数字太粗了它无法告诉你 Agent 是“理解任务”这一步出了问题还是“规划步骤”出了问题还是“执行工具”出了问题。粒度不够就没法精准定位。SkillFocus 的价值就在于它把这三个盲区一次性摊开了先建立能力维度的评估再做归因最后才动 Skill。2.2 能力拆解和 Skill 修改的关系这里要讲清楚一个关键逻辑能力拆解不是目的它是 Skill 修改的前置条件。打个比方。你去看医生医生不会一上来就给你开药。他先问诊、检查、定位病灶然后才开方。Skill 修改就是“开方”能力拆解就是“问诊 检查”。跳过问诊直接开方就是瞎治。在 Agent 场景里这个逻辑链条是这样的Agent 在任务上表现不佳现象通过能力拆解定位到具体是哪个能力维度薄弱诊断判断这个能力维度是否可以通过 Skill 层面改善可行性判断如果可以设计针对性的 Skill 修改处方验证修改是否真的提升了该能力维度复诊大部分人的问题出在第二步和第三步之间——他们跳过了诊断直接假设“所有问题都能靠改 Skill 解决”。但事实是有些能力短板是 Skill 改不动的比如模型本身的知识边界、上下文窗口的硬限制。这时候你改 Skill 就是白费力气正确的做法可能是换模型、拆任务、或者加外部检索。2.3 这套方法论适合谁用说句实在话SkillFocus 这套思路不是给“玩具级 Agent”准备的。如果你只是搭个 demo 玩玩端到端跑通就行那不需要这么重的方法论。但如果你符合下面任何一种情况这套东西就值得认真看Agent 已经上线有真实用户在用效果波动会直接影响业务你在做 Agent 的持续迭代需要一套可复用的调优流程团队里多个人协作开发 Agent需要统一的评估和归因语言你被“改了 Skill 但说不清为什么有效”这个问题困扰过我自己的经验是Agent 项目从 demo 走向生产最大的门槛不是技术难度而是迭代效率。谁能更快地定位问题、更准地修改、更可靠地验证谁就能把 Agent 真正做出来。SkillFocus 提供的正是这套迭代效率的底层方法。3. 能力拆解把 Agent 的“黑盒”打开3.1 能力维度的划分逻辑能力拆解的第一步是确定拆成哪几个维度。这里没有唯一标准答案但有几个原则必须遵守。原则一维度之间要尽量正交。如果两个维度高度相关那拆了等于没拆。比如“理解能力”和“推理能力”在很多任务里是耦合的你得想办法把它们分开评估。原则二维度要可观测。每个维度都得有对应的评估方法能给出一个相对客观的分数或判断。不能观测的维度拆出来也没用。原则三维度要能映射到修改动作。拆出来的能力维度最终要能指导你“改什么”。如果一个维度拆出来之后你不知道该动 Skill 的哪部分那这个维度就太抽象了。基于这三个原则SkillFocus 的思路里Agent 能力通常可以拆成这么几层能力层级具体维度典型表现感知层任务理解、意图识别、约束提取能不能准确读懂用户要什么认知层推理、规划、分解、反思能不能想出正确的解决路径执行层工具选择、参数构造、结果解析能不能把想法正确落地交互层多轮记忆、上下文管理、澄清提问能不能在对话中保持一致性元能力层自我评估、错误恢复、边界感知知不知道自己行不行这个划分不是死的你可以根据自己 Agent 的任务类型调整。比如做代码 Agent执行层可能要再细分成“代码生成”和“代码调试”做客服 Agent交互层的权重会更高。3.2 每个能力维度的评估方法拆完维度接下来是评估。这一步是很多人卡住的地方——知道要拆但不知道怎么测。我的做法是为每个维度设计最小可观测任务。所谓最小可观测任务就是专门针对某一个能力维度设计的、其他维度干扰尽量小的测试用例。举个例子。要测“任务理解”这个维度你可以设计一组任务它们的解决路径都很简单不需要复杂推理但表述方式有各种歧义、隐含约束、多意图混杂。如果 Agent 在这些任务上失败那基本可以归因到理解能力而不是推理或执行。要测“规划能力”就反过来任务表述清晰无歧义但解决路径需要多步分解。如果 Agent 理解对了但步骤乱了那就是规划问题。这里有个实操技巧每个维度的测试集不需要很大10 到 20 个精心设计的用例就够定位问题了。关键是用例的“纯度”要高别一个用例同时考验三四个能力那样测出来也不知道是谁的问题。评估的粒度也要注意。不要只记“通过/不通过”最好能记录失败的具体形态。比如规划能力失败是“步骤顺序错”还是“漏了关键步骤”还是“多做了无用步骤”这些细节直接决定了你后面怎么改 Skill。3.3 能力短板定位的实操流程把上面的东西串起来完整的定位流程大概是这样收集失败案例。从真实使用或测试中收集 Agent 表现不佳的案例越多越好但要注意多样性。粗分类。先按任务类型粗分比如“多步推理类”“工具调用类”“多轮对话类”。逐案例归因。对每个失败案例用能力维度表逐个排查判断最可能的短板维度。这一步最好两个人独立做然后对比减少主观偏差。统计分布。把所有案例的归因结果汇总看哪个能力维度出现频率最高。验证假设。针对高频短板维度用专门设计的最小可观测任务再测一遍确认判断。我踩过的一个坑是归因的时候容易过度自信。看到一个案例觉得“这明显是规划问题”结果深入一看其实是理解阶段就把约束搞错了导致后面规划全歪。所以第三步一定要慢宁可多花时间也别急着下结论。提示归因时建议记录“主因”和“次因”。有些失败是多因素叠加的只记一个主因会丢失信息。次因虽然优先级低但可能在主因修复后暴露出来。4. 从能力短板到 Skill 修改的映射4.1 哪些能力短板 Skill 能修定位到短板之后下一个关键判断是这个短板能不能靠改 Skill 解决这个问题没有标准答案但有一些经验规律。我整理了一张对照表能力维度Skill 可修性说明任务理解高提示词、示例、约束说明都能显著改善推理规划中可以通过思维链、分解模板改善但有上限工具执行高工具描述、参数示例、错误处理都能优化多轮记忆中摘要策略、记忆提取规则可调但受上下文限制知识边界低Skill 改不动需要外部检索或换模型自我评估中可以通过反思提示改善但依赖模型本身能力这张表的核心信息是Skill 修改对“流程性”和“格式性”问题效果好对“能力性”和“知识性”问题效果有限。什么意思如果 Agent 是“知道该怎么做但没做对”那大概率是 Skill 问题改 Skill 有效。如果 Agent 是“根本不知道该怎么做”那可能是模型能力或知识边界问题改 Skill 只能缓解不能根治。4.2 不同短板对应的 Skill 修改策略确定了可修性之后具体怎么改这里按能力维度给几套策略。任务理解短板。核心是减少歧义。具体动作包括在 Skill 里明确列出常见歧义模式和处理规则增加“先复述任务再执行”的步骤对多意图任务强制要求先拆分再处理。我实测下来光是加一个“执行前先用自己的话复述一遍任务”的步骤理解类错误就能降不少。推理规划短板。核心是提供结构化脚手架。具体动作包括在 Skill 里内置任务分解模板要求 Agent 显式输出规划步骤再执行对复杂任务强制分阶段。这里要注意脚手架不能太死太死会限制 Agent 的灵活性反而在简单任务上拖慢速度。工具执行短板。核心是把工具用法的“隐性知识”显性化。具体动作包括为每个工具补充正反示例明确参数边界和常见错误增加工具调用前的参数自检步骤。工具类问题往往是最容易通过 Skill 修复的因为它的失败模式很具体。多轮记忆短板。核心是设计好记忆的“进出规则”。具体动作包括明确什么信息需要记住、什么可以丢弃设计摘要触发条件在多轮中定期做上下文压缩。这块的难点在于平衡记太多会撑爆上下文记太少会丢信息。4.3 修改优先级怎么排短板可能有好几个Skill 修改动作可能有一堆先改哪个我的排序原则是先改影响面大的再改修复成本低的最后改需要重构的。具体来说先看哪个短板在失败案例里出现频率最高优先修。如果两个短板频率差不多选那个修改动作最简单、风险最低的先做。因为 Skill 修改本身也有风险——你改了一处可能影响其他场景的表现。所以先用小改动验证方法论再动大手术。还有一个容易被忽略的点有些短板之间是有依赖关系的。比如理解能力不行会导致规划也做不好。这种情况下你得先修理解再看规划是不是自动就好了。如果顺序搞反了先修规划可能白费功夫。注意每次 Skill 修改最好只动一个变量。同时改多处即使效果变好了你也不知道是哪处起了作用经验无法沉淀。5. 完整实操一次 Skill 迭代的全流程记录5.1 案例背景与初始评估光讲方法论太虚我拿一个自己做过的项目来完整走一遍。项目是一个文档处理 Agent主要任务是读用户上传的各种格式文档提取结构化信息然后按用户要求做汇总或转换。上线后发现在处理“多文档交叉汇总”这类任务时成功率明显偏低大概只有六成左右。按 SkillFocus 的流程第一步不是改 Skill是评估。我收集了 50 个失败案例逐个做能力归因。归因结果分布是这样的任务理解类8 个16%推理规划类27 个54%工具执行类9 个18%多轮记忆类6 个12%很明显规划是主要短板。但 54% 这个数字还不够我得知道规划具体是怎么失败的。5.2 能力短板的精确定位把 27 个规划类失败案例再细看发现三种典型形态步骤遗漏Agent 汇总时漏掉了某些文档的关键信息占 11 个顺序错误先做了汇总再做提取导致汇总基于不完整信息占 9 个过度分解把简单任务拆得太碎反而增加了出错概率占 7 个这三种形态对应的 Skill 修改方向其实不一样。步骤遗漏要补检查机制顺序错误要固定流程过度分解要加复杂度判断。如果不做这层细分笼统地“改规划”很可能改了一个方向另外两个方向的问题还在。我又针对“步骤遗漏”设计了一组最小可观测任务给 Agent 三到五篇文档要求提取每篇的关键信息再汇总文档数量、格式、信息密度都做了控制。结果确认当文档数量超过三篇时遗漏率明显上升。这就把问题定位得很具体了多文档场景下的信息覆盖不完整。5.3 Skill 修改方案的设计与验证定位清楚之后修改方案就有的放矢了。我做了三处改动第一处在 Skill 里加入显式的文档清单步骤。要求 Agent 在处理多文档任务时先列出所有待处理文档每处理完一篇就标记最后检查清单是否全部完成。这一步直接针对“步骤遗漏”。第二处固定处理流程。明确要求“先逐篇提取再统一汇总”不允许 Agent 自行调整顺序。这一步针对“顺序错误”。第三处加复杂度判断。在 Skill 开头加一个判断如果文档数量少于三篇且结构简单走简化流程不做过度分解。这一步针对“过度分解”。改完之后用同一批测试集验证。多文档汇总的成功率从六成提到了八成五左右。更重要的是三种失败形态的分布变了步骤遗漏基本消失顺序错误大幅减少过度分解也改善了。这里有个细节值得说我没有一次性把三处改动都上而是分三次上每次只改一处单独验证。这样我能清楚知道每处改动各自的贡献。实测下来第一处改动贡献最大第二处次之第三处主要是提升了简单场景的效率对成功率贡献不大但降低了延迟。5.4 迭代后的效果复盘这次迭代让我对 SkillFocus 这套方法论有了更实的体感。几个关键收获归因的精度决定了修改的精度。如果我只停在“规划能力不足”这一层修改方案大概率是笼统的“优化规划提示词”效果肯定不如现在。最小可观测任务是真的有用。它帮我确认了“文档数量”这个关键变量如果没有这一步我可能会以为是文档格式的问题改错方向。分步验证比一次性改完更值。虽然慢一点但经验能沉淀下来下次遇到类似问题我知道优先改哪里。6. 实操中的常见问题与避坑指南6.1 能力拆解阶段的典型误区误区一维度拆得太细。有人一上来拆出十几个能力维度结果每个维度都没法好好评估反而增加了工作量。我的建议是初次做拆解控制在五到七个维度够用就行后续有需要再细分。误区二用端到端指标代替维度评估。这是最常见的。端到端成功率是个结果指标不是诊断指标。你得有维度级的评估才能定位问题。误区三归因时只看失败案例。其实成功案例也值得看尤其是“侥幸成功”的案例——Agent 用了错误的方式但碰巧对了。这类案例往往藏着隐患换个场景就会暴露。6.2 Skill 修改阶段的常见坑坑一改动过大无法归因。前面提过一次只改一个变量。但实操中很容易忍不住看到问题就想一起改。我的做法是把想改的都列出来排个优先级一次只上一个。坑二忽略回归测试。改完 Skill只测了目标场景没测其他场景结果修好了 A 场景搞坏了 B 场景。每次修改后都要跑一遍完整的回归测试集。坑三把 Skill 当万能药。有些短板 Skill 真的修不动比如模型的知识边界。这时候要果断承认转向其他方案别在 Skill 上死磕。6.3 效果验证与回归测试要点验证这块我整理了一个检查清单每次迭代都过一遍检查项目的通过标准目标场景测试确认修改有效目标指标提升且稳定回归测试确认没搞坏其他场景其他场景指标不下降边界测试确认极端情况可控边界场景不崩溃稳定性测试确认不是偶然多次运行结果一致成本测试确认没引入额外开销延迟和 token 消耗可接受最后一项“成本测试”经常被忽略。有些 Skill 修改确实提升了成功率但代价是 token 消耗翻倍或者延迟大幅增加。这种修改在生产环境里未必划算得综合权衡。提示建议给每次 Skill 迭代建一个简单的记录包括修改内容、验证结果、遗留问题。积累几次之后你会发现自己对“什么改动有效”的判断越来越准。7. 我对这套方法论的真实体会做 Agent 这几年我越来越觉得Agent 开发的难点不在“能不能做出来”而在“能不能持续做好”。前者靠技术选型和快速原型后者靠的是迭代方法论。SkillFocus 这套“先拆能力再改 Skill”的思路本质上就是一套迭代方法论。它最大的价值不是某个具体技巧而是把“改 Skill”这件事从“凭感觉试错”变成了“有依据的工程流程”。你不再需要靠运气去猜哪里出了问题而是有一套可重复的流程去定位、修改、验证。当然这套方法也不是银弹。它需要你投入时间做评估、做归因前期看起来比“直接改”慢。但拉长看它省下的是反复试错的时间而且积累下来的经验是可复用的。我自己的项目从这套方法里受益最大的不是某一次具体的成功率提升而是整个团队对“Agent 为什么不行”这件事有了共同的语言和判断框架。如果你现在正被 Skill 调优折磨我的建议是下次遇到问题先别急着改 Skill。花半天时间把失败案例收集起来做一次能力归因。你可能会发现真正要改的地方和你一开始想的完全不一样。
