1. 为什么“先拆能力再改 Skill”是 Agent 进化的分水岭做 Agent 开发的人十有八九都经历过这样一个阶段发现 Agent 在某类任务上表现不行第一反应就是去改 prompt、加工具、换模型甚至把整个 skill 推倒重来。结果改完之后原来能跑的场景反而崩了新加的能力也没真正生效。这种“越改越乱”的困境本质上不是 skill 写得不好而是在动手改之前根本没有把能力拆清楚。SkillFocus 这篇论文之所以值得精读就是因为它把这个问题摆到了台面上Agent 的 skill 不是一块铁板而是一组可以独立评估、独立迭代的能力单元。你只有先知道“哪一项能力弱、弱在哪个环节、这个环节和其他能力怎么耦合”才有可能做出精准的修改决策。否则所有的 skill 优化都是盲人摸象。这篇文章我会按照论文精读的方式把 SkillFocus 的核心思路、能力拆解方法论、实操落地步骤、以及我在实际 Agent 项目中踩过的坑完整地拆给你看。不管你是刚接触 agent skill 的新手还是已经在做 agent 架构与编排的老手只要你的工作涉及 skill 的设计、测试和迭代这篇内容都能直接拿去用。核心关键词会贯穿全文Agent、SkillFocus、skill、能力拆解、论文精读。我不会只讲论文结论而是把“为什么这么设计”“实际怎么落地”“哪些地方容易翻车”全部展开。2. SkillFocus 到底解决了什么问题从“整体评估”到“能力级诊断”2.1 传统 Skill 评估的致命盲区大部分团队评估一个 agent skill 的方式其实非常粗糙跑一批测试用例看整体通过率。通过率 80% 就觉得还行通过率 50% 就回去改 prompt。这种做法有一个根本性的问题——它把 skill 当成一个黑盒只告诉你“行不行”不告诉你“哪里不行”。我举个实际例子。之前做过一个文档处理的 agent skill任务是“读取用户上传的 PDF提取关键信息生成结构化摘要”。整体通过率只有 62%。如果只看这个数字你根本不知道该改哪里。是 PDF 解析能力不行是信息抽取的准确率不够还是摘要生成的格式不对这三个环节对应的是完全不同的修改策略解析问题要换工具或加预处理抽取问题要调 prompt 或加 few-shot 示例格式问题可能只需要改输出模板。SkillFocus 的核心贡献就是把这层黑盒打开了。它提出了一套能力拆解框架把一个复合 skill 拆成若干可独立评估的能力维度然后针对每个维度单独打分、单独定位问题。这样一来你的修改决策就从“猜”变成了“诊断”。2.2 能力拆解的三个层次SkillFocus 的能力拆解不是随便切几刀而是有明确的层次结构。我在实际项目中把它归纳为三层原子能力层这是最细粒度的能力单元比如“识别 PDF 中的表格结构”“判断一段文本的情感倾向”“从对话中提取时间实体”。原子能力是可以通过单点测试直接验证的。组合能力层多个原子能力按照特定流程组合起来完成一个子任务。比如“从 PDF 中提取表格并转成 JSON”就是“表格识别 结构映射 格式输出”的组合。端到端能力层整个 skill 面向用户的最终表现比如“用户上传 PDF 后得到一份结构化摘要”。关键洞察在于端到端能力差不一定是因为所有原子能力都差。很多时候是某一个原子能力拖了后腿或者组合逻辑出了问题。SkillFocus 的方法论就是让你逐层往下拆直到定位到那个真正需要修改的最小单元。2.3 为什么不能跳过拆解直接改有人可能会想我直接改不就行了拆解多麻烦。但实际经验告诉我跳过拆解的修改大概率会引入回归问题。原因很简单——skill 内部的能力之间是有耦合的。你为了提升信息抽取准确率把 prompt 改得更严格结果模型变得过于保守反而漏掉了原本能提取到的信息。这种“按下葫芦浮起瓢”的现象在没有能力级评估的情况下根本发现不了。SkillFocus 的价值就在于它让你在修改前就知道这个改动会影响哪些能力维度哪些维度可能因此退化从而提前做好回归测试的准备。3. 论文核心方法拆解SkillFocus 的能力诊断流程3.1 能力定义与边界划分SkillFocus 的第一步是能力定义。听起来简单但实际操作中这是最容易出问题的地方。能力定义得太粗拆解没有意义定义得太细评估成本爆炸。论文里给出的原则是每个能力单元应该对应一个可独立验证的输入输出对。也就是说你给这个能力一个输入它能产出一个明确的结果而且这个结果的对错是可以判断的。我在实操中总结了一个更接地气的判断标准如果你没法为这个能力写出一条独立的测试用例那说明它拆得还不够细或者定义得不够清晰。比如“理解用户意图”这个能力就太模糊了没法写测试但“从用户 query 中判断是查询类还是操作类意图”就可以写测试。边界划分还有一个关键点能力之间尽量不要重叠。如果两个能力单元覆盖了同一段逻辑那评估结果就会互相干扰你没法判断到底是哪个能力出了问题。3.2 能力评估指标的设计定义完能力之后下一步是给每个能力设计评估指标。SkillFocus 强调的是能力级指标要和端到端指标解耦。什么意思呢端到端指标通常是任务完成率、用户满意度这类综合指标。但能力级指标应该更具体比如能力类型评估指标示例判断方式信息抽取抽取字段的准确率、召回率与标注结果对比格式转换输出格式合规率结构化校验意图分类分类准确率、混淆矩阵与标注标签对比多步推理中间步骤正确率分步验证工具调用调用成功率、参数正确率日志分析这张表是我根据论文思路和实际项目经验整理的。核心逻辑是每个能力都要有一个可以量化、可以复现的评估方式。没有量化指标的能力在 SkillFocus 框架里是不合格的。3.3 能力短板的定位算法SkillFocus 最核心的技术点是它提出了一套能力短板定位算法。简单说就是通过对比不同能力维度的评估结果找出对端到端表现影响最大的那个短板。论文里的思路大致是这样的先建立能力维度与端到端表现之间的关联模型然后通过消融分析或者贡献度分析确定每个能力对最终结果的边际贡献。贡献度低且评估分数低的能力就是优先要改的对象。我在实际项目中用了一个简化版的方法逐能力替换法。具体做法是把某个能力的输出替换成“理想输出”然后看端到端表现提升多少。提升越大说明这个能力越是瓶颈。这个方法虽然粗糙但非常实用不需要复杂的建模。3.4 修改决策的优先级排序定位到短板之后不是所有短板都要立刻改。SkillFocus 给出了一个优先级排序框架考虑三个因素影响面这个能力影响多少下游能力或最终输出修改成本修改这个能力需要多少工作量是否涉及工具更换、模型切换回归风险修改这个能力是否可能影响其他能力的表现综合这三个因素你可以把短板分成四类高影响低成本优先改、高影响高成本规划改、低影响低成本顺手改、低影响高成本暂时不改。这个排序框架看起来简单但实际用起来非常有效。它避免了“哪个问题显眼就先改哪个”的冲动决策。4. 实操落地把 SkillFocus 方法用在你自己的 Agent 项目里4.1 第一步给你的 Skill 画一张能力地图假设你有一个“客服对话 agent skill”任务是接收用户问题、查询知识库、生成回复。按照 SkillFocus 的方法第一步是画能力地图。我会这样拆原子能力意图识别、实体提取、知识库检索、答案生成、多轮上下文管理组合能力问题理解意图识别 实体提取、知识匹配检索 排序、回复生成答案生成 上下文融合端到端能力用户问题解决率、回复满意度画完地图之后你会发现原本以为是一个整体的 skill其实内部有这么多可独立评估的单元。这张地图就是后续所有评估和修改的基础。注意能力地图不是画一次就固定的。随着 skill 迭代能力单元可能会合并或拆分。建议每次大版本更新时重新审视一遍。4.2 第二步为每个能力建立测试集这一步是最耗时的但也是最值得投入的。SkillFocus 强调能力级测试集要独立于端到端测试集。我的做法是针对每个原子能力准备 20-50 条测试用例覆盖正常情况、边界情况、异常情况。比如“实体提取”这个能力测试集里要有标准实体、嵌套实体、模糊实体、不存在的实体等。测试集的标注质量直接决定了评估的可靠性。我的经验是宁可测试集小一点也要保证标注准确。50 条高质量标注用例比 500 条模糊标注有用得多。4.3 第三步跑评估生成能力诊断报告有了能力地图和测试集就可以跑评估了。评估结果建议整理成一张诊断报告表能力单元评估指标当前得分瓶颈标记影响面修改成本意图识别准确率0.91否高低实体提取F10.63是高中知识检索召回率0.78是高高答案生成人工评分0.82否高中上下文管理一致性0.70是中低这张表一出来修改优先级就非常清晰了。实体提取和知识检索是主要瓶颈但知识检索修改成本高所以先改实体提取。上下文管理虽然影响面中等但成本低可以顺手优化。4.4 第四步小步修改能力级回归SkillFocus 反复强调的一个原则是每次只改一个能力改完立刻做能力级回归。我见过太多团队一次性改好几个地方结果端到端表现提升了但不知道是哪个改动起了作用或者端到端下降了也不知道是哪个改动引入的问题。小步修改 能力级回归虽然看起来慢但实际上是更快的因为它避免了反复试错。具体操作上我会在每次修改后跑三组测试被修改能力的专项测试、相关能力的回归测试、端到端测试。三组都通过才认为这次修改是安全的。4.5 第五步建立能力迭代档案这一步是 SkillFocus 论文里没有重点提但我在实际项目中觉得非常重要的。每个能力的每次修改都应该记录在案改了什么、为什么改、改前改后的评估分数、是否引入了回归问题。这份档案的价值在于当你后面遇到类似问题时可以快速查到历史上有没有遇到过、当时是怎么解决的。它也是团队协作时的重要知识资产。5. 常见问题与排查技巧实录5.1 能力拆得太细导致评估成本爆炸怎么办这是新手最容易踩的坑。拆到原子能力之后发现有三四十个能力单元每个都要建测试集、跑评估根本忙不过来。我的建议是先粗后细按需拆分。第一版能力地图可以只拆到组合能力层等你发现某个组合能力表现不稳定时再往下拆原子能力。不要一上来就追求最细粒度。另外测试集可以复用。很多原子能力的测试用例可以从端到端测试用例中派生出来不需要完全从零开始建。5.2 能力之间耦合太强没法独立评估怎么办这是第二个常见问题。有些 skill 的能力之间确实耦合很深比如多步推理任务中间步骤的输出依赖于前一步的结果很难单独评估某一步。SkillFocus 论文里提到的处理方式是用理想输入替代法。也就是说评估某个能力时给它提供理想的上游输入看它能不能产出正确输出。这样可以剥离上游能力的影响单独评估当前能力。如果连理想输入都没法构造那说明这个能力可能不应该被单独拆出来应该和上游能力合并成一个更大的能力单元。5.3 评估分数和实际体感不一致怎么排查有时候能力级评估分数很高但实际用户反馈很差。这种不一致通常有几个原因测试集分布和真实分布不一致测试集覆盖的场景和用户实际使用的场景偏差太大评估指标设计不合理指标没有真正反映能力的核心质量存在未拆解的能力有些影响体验的因素没有被纳入能力地图排查方法是从真实 bad case 出发反推是哪个环节出了问题然后检查对应的能力评估是否覆盖了这类情况。5.4 修改一个能力后其他能力退化怎么处理这就是前面提到的回归问题。处理方式有两个层面短期处理建立能力级回归测试集每次修改后自动跑一遍发现退化立刻回滚或调整。长期处理在能力地图上标注能力之间的依赖关系修改某个能力时提前识别可能受影响的下游能力有针对性地加强测试。5.5 常见问题速查表问题现象可能原因排查方向解决建议端到端差但各能力分数都不低组合逻辑有问题检查能力之间的衔接优化编排流程某能力分数波动大测试集不稳定检查测试用例质量补充边界用例修改后整体退化能力间耦合做能力级回归小步修改评估成本太高拆解粒度过细审视能力地图合并低价值能力分数高但体验差指标设计偏差对比真实 bad case重新设计指标6. 我在实际 Agent 项目中的几条硬核经验6.1 能力拆解不是目的修改决策才是我刚开始用 SkillFocus 方法时花了很多时间在拆解上画了很漂亮的能力地图但拆完之后不知道下一步该干嘛。后来才想明白拆解是为了服务于修改决策。如果拆解结果不能帮你决定“先改哪个、怎么改”那这个拆解就是无效的。所以现在我做能力拆解时会先问自己拆完之后我能做出什么之前做不了的决策如果答案是“没什么不同”那就说明拆解方式有问题。6.2 测试集的质量比数量重要十倍这个坑我踩过不止一次。早期为了追求覆盖率快速标注了大量测试用例结果评估结果忽高忽低根本没法用。后来缩减到每个能力 30 条精标用例评估稳定性立刻上来了。精标的意思是每条用例都有明确的预期输出边界情况有明确标注争议 case 有讨论记录。这样的测试集虽然小但可信度高。6.3 不要迷信论文里的算法要结合自己的场景简化SkillFocus 论文里的短板定位算法涉及一些统计建模理论上很优雅但实际落地时数据量往往不够跑出来的结果不稳定。我的做法是用更简单的启发式方法逐能力替换 人工判断。虽然不够“科学”但在小数据量下更可靠。论文提供的是思路框架不是必须照搬的实现。理解它的核心思想——能力级诊断、短板定位、优先级排序——然后用自己的方式实现这才是正确的精读方式。6.4 能力迭代档案是最容易被忽视的资产很多团队做完一轮优化就结束了没有把过程记录下来。等到三个月后同样的问题再次出现又要从头排查一遍。我现在要求团队每次能力修改都记录三样东西修改前后的评估分数、修改的具体内容、修改后的回归测试结果。这份档案看起来不起眼但半年后回头看它就是整个 skill 的进化史价值极高。6.5 端到端测试不能省但也不能只靠它SkillFocus 强调能力级评估但这不意味着端到端测试不重要。端到端测试是最终的质量守门员能力级评估是诊断工具。两者配合使用能力级评估帮你定位问题端到端测试帮你确认修复效果。我的做法是日常迭代以能力级评估为主快速定位和修复版本发布前跑完整的端到端测试确保整体表现达标。7. 从 SkillFocus 延伸Agent Skill 进化的下一步7.1 能力拆解的自动化目前能力拆解主要靠人工成本高且依赖经验。后续可以考虑用 agent 自身来辅助拆解让一个专门的“拆解 agent”分析 skill 的输入输出和中间步骤自动生成候选能力单元人工再审核调整。这样可以把拆解效率提升一个量级。7.2 能力级监控与在线诊断现在的评估主要是离线的。如果能把能力级评估搬到线上实时监控每个能力的表现就能在问题发生的早期发现异常。比如实体提取的 F1 突然下降系统自动告警而不是等到用户投诉才发现。7.3 能力库的复用与组合当能力拆解做得足够细之后你会发现很多能力是通用的比如意图识别、实体提取、格式转换。这些能力可以沉淀成能力库在不同 skill 之间复用。新 skill 的开发就变成了“从能力库中选取能力 设计组合逻辑”效率会大幅提升。这也是 SkillFocus 方法的一个自然延伸先拆清楚再标准化最后复用。拆解是第一步复用是最终目标。7.4 与 Agent 编排框架的结合能力拆解的结果可以直接指导 agent 编排。每个能力单元对应一个可调用的节点能力之间的依赖关系对应编排的边。这样编排框架就不只是“把工具串起来”而是“按照能力地图来组织执行流程”逻辑更清晰也更容易调试。我在最近的一个项目里尝试了这种做法先把 skill 拆成能力单元然后用编排框架把能力单元组织起来。结果是调试效率明显提升因为每个节点的输入输出都是明确的出问题很容易定位到具体能力。7.5 能力评估的标准化如果行业内能形成一套能力评估的通用标准比如常见能力的标准测试集、标准评估指标那 skill 的评估和对比就会容易很多。目前这块还是各做各的但趋势是往标准化走的。SkillFocus 这类论文的价值就是为标准化提供了方法论基础。8. 一个具体案例用 SkillFocus 方法优化文档摘要 Skill8.1 案例背景与初始表现最后用一个完整案例收尾。这是一个真实的项目文档摘要 skill输入是用户上传的 PDF 或 Word 文档输出是结构化摘要包含核心观点、关键数据、结论建议。初始版本端到端通过率 58%用户反馈主要集中在“摘要遗漏关键信息”和“格式不统一”。8.2 能力拆解与诊断结果按照 SkillFocus 方法拆解后得到以下能力单元和评估结果能力单元评估指标得分瓶颈文档解析文本提取完整率0.95否段落分割分割准确率0.88否关键信息识别召回率0.61是信息压缩压缩比合理性0.75是结构化输出格式合规率0.68是多文档融合一致性0.72否诊断结论很清晰关键信息识别是最大瓶颈结构化输出次之信息压缩也有优化空间。8.3 修改过程与效果验证针对关键信息识别我做了三件事补充 few-shot 示例、调整 prompt 中的识别标准、增加一轮自检。改完后召回率从 0.61 提升到 0.83。针对结构化输出我引入了输出模板校验格式合规率从 0.68 提升到 0.94。信息压缩暂时没改因为修改成本高且影响面相对小。最终端到端通过率从 58% 提升到 81%。整个过程只改了两个能力单元没有动其他部分也没有引入回归问题。这个案例最值得说的是如果一开始就整体改 prompt很可能三个问题都碰一点但哪个都没改透。能力拆解让修改变得精准这才是 SkillFocus 方法的核心价值。8.4 案例复盘哪些地方可以做得更好复盘下来有两点可以改进。一是测试集还是偏小关键信息识别的测试用例只有 25 条评估结果的置信度不够高。二是没有建立持续监控改完之后的效果只验证了一次没有跟踪长期表现。如果重做一遍我会在拆解阶段就规划好测试集规模并且在修改后建立定期评估机制确保效果稳定。这个案例后续还可以这样扩展把关键信息识别能力进一步拆成“事实识别”和“观点识别”两个子能力分别评估和优化。因为实际使用中发现这两类信息的识别难度和优化策略是不同的。拆得更细之后修改会更精准。