Agent Skills：从召回到编排，如何用对技能

用户上传一份销售表，要求清洗重复记录、保留公式，再生成汇报用的演示文稿。Agent 找到了表格技能和演示文稿技能，也按顺序调用了它们。最后交付的文件却丢了公式，幻灯片中的数字还是清洗前的版本。

这里没有明显的“没找到工具”。问题出在几个很小的交界处：清洗要求没有进入技能选择条件，表格输出没有成为下游的唯一输入，执行器也没有确认收到的是哪个版本。技能选对了名字，任务仍然可能在交接中失败。

本文把 Skill 理解为可复用的过程知识包：它可以包含适用条件、操作步骤、脚本、参考材料和验证方法。Harness 是承载模型、工具、状态与执行循环的宿主。对 C 端 Agent，我更关心的是一次请求中，哪些知识在什么时候进入模型，以及这些知识怎样转化为可检查的动作。

沿着这个问题，SkillRouter、Graph-of-Skills、AgentSkillOS 和 GraSP 分别提供选择、依赖补全、节点交接与局部修复的思路。下文以同一个表格到演示文稿的教学案例串联它们。案例与组合架构由本文构造；研究事实与工程建议分别说明，实验不声称独立复现。

1. 先把“用到了 Skill”拆开

日志里出现一次 Skill 调用，信息量很有限。它可能只是发起了读取，工具随后报错；也可能读到了正文，却没有执行其中的关键检查。要定位开头的失败，需要把整个过程拆成可以关联的事件。

这些事件有先后关联，但不一定由五个独立服务实现。小系统可以在一个循环里完成，关键是每个事件的含义清楚。例如“请求读取成功”与“材料内容到达模型”应能关联到同一次调用，不能只对终端文本搜索一个技能名称。

图 1：本文的执行事件图。反馈返回计划，不意味着每次失败都要重写技能正文。

对“保留公式”这样的条件，也要区分未知与失败。若系统没有保存文件差异，无法判断公式是否改变，就应记录证据不足。把未知直接当作成功，会让后续的技能学习建立在错误标签上。

2. 选择技能时，需要比名字更多的信息

大库中最容易混淆的往往不是毫不相关的技能，而是相邻能力。例如同为表格清洗，一份技能适合把所有内容导出成静态值，另一份会保留公式、格式与工作表关系。只按“清洗 Excel”检索，两者都可能排在前面。

SkillRouter 使用检索与重排两阶段，并将技能正文中的能力细节引入路由判断。1 它的启发是：路由模型需要理解的材料，可以比最终执行模型首轮携带的材料多。 离线索引与在线重排负责辨别能力，执行器只读取此次真正采用的部分。全文参与路由并不等于将全库全文塞进用户会话。

这种方法仍有输入限制。字段截断会影响尾部条件，训练中的相似负例也可能其实是有效替代方案。因此，“保留公式”“只能本地处理”“支持哪个工具版本”不能长期藏在正文的偶然位置。我的工程建议是把这些约束同步到可检查的元数据，同时保留正文作为判断依据。

可以把候选筛选分成两层：先排除权限、环境和输出格式明确不满足要求的项，再比较剩余方案的相关性与成本。硬条件不能被一个很高的语义相似度抵消。没有足够证据证明候选适用时，回退到直接工具执行或向用户澄清，也是一种合理结果。

依赖召回解决的是另一个缺口

找到演示文稿技能，不代表找到了它所依赖的图表生成能力。Graph-of-Skills 将技能关系用于结构检索，让查询能够沿依赖扩展到单纯语义相似度可能遗漏的前置能力。2

这与“再多取几个 Top K”不同。增加 K 只是扩大邻近候选，依赖扩展试图回答：已经选中 B，为了让 B 的前置条件成立，还需要哪个 A？在表格案例中，这条边应该具体到“图表生成消费已验证的数据表，演示文稿消费图表与解释”，而非只有两个技能的名称相邻。

关系图也可能放大错误。一个过期依赖会稳定召回错误版本；把常见共现当作必要前置，会给所有任务增加多余步骤。关系至少需要记录适用条件、来源与版本。某条边来自人工规则、文本推断还是执行验证，应当能被区分。

3. 有了执行图，还需要定义信息交接

AgentSkillOS 将技能组织、选择与 DAG 执行结合起来。最值得看的一处实现，是规划器与节点执行器接收的材料不同：规划阶段可以看到选中技能的名称、描述和正文；执行阶段按节点构造任务，携带目标、产物路径、使用提示与输出要求。34

规划器读过的信息，不会自动成为下游执行器的历史。 在新的会话里，产物路径、使用方法和预期输出都需要显式传递。反过来，如果执行器继承了全部旧会话，它还可能同时看到过期文件、失败尝试与已经撤销的计划。

下面比较的是同一个时刻：表格清洗完成，准备生成演示文稿。它是依据节点交接思路构造的教学示例，不是一次真实 API 请求记录。

共享长历史：
用户需求、两份技能全文、所有清洗尝试、旧图表路径、
工具错误、修正说明、当前要求“继续生成演示文稿”。

按节点交接：
目标：生成销售复盘演示文稿，保留数据口径。
权威输入：cleaned.xlsx，版本与内容指纹已记录。
补充材料：validation.json、charts/、口径说明。
使用要求：从 cleaned.xlsx 取数，不使用旧草稿。
预期输出：report.pptx，并给出逐页数据来源。
下一步：执行器按需读取材料，再执行生成与验收。

路径本身不是上下文。只有实际读取之后，文件内容才进入模型可用材料。交接字段也不是越多越好：可以直接检查的机器状态留在运行状态里，模型需要解释和决策的部分再进入上下文。把完整审计日志复制给每个节点，既增加成本，也让过时信息重新参与判断。

图 2：本文建议的产物交接。箭头表达依赖，访问权限仍由宿主独立控制。

AgentSkillOS 的作者实验包含 30 个产物型任务，即使提供相同的理想技能集合，结构化编排也表现出优势。3 但其成对偏好与排序指标不能改写成任务准确率；整套系统的改善也不能全部归给“新建会话”。规划质量、交接方式、重试与材料组织共同变化，需要另外做消融。

还有一个容易忽略的边界：会话隔离不等于文件隔离。源码中的节点可以共享工作目录，交接材料也不必只来自直接父节点。4 如果要实现最小权限，还需要限制节点可访问的路径与工具，不能从 DAG 图形直接推出安全保证。

4. 执行中应修复哪一部分

执行图适合表达已知依赖，但真实工具调用会产生新信息。清洗结果可能提示表中存在不可自动合并的重复记录；图表生成可能发现缺少时间字段。此时继续照原计划走，或直接重跑全部流程，都可能浪费成本。

GraSP 将技能组合表达为可检查的图，并把失败映射到局部修复。5 对框架的启发是：先保留已经可靠完成的状态，定位哪个节点、哪条依赖或哪个条件失效，再决定补节点、换方法、修参数或停止。验证对象包括计划结构与执行结果，图在结构上合法并不保证任务能完成。

以表格案例为例，若清洗已经正确完成，只是图表缺少单位，应修复图表或补充口径，没必要再次删除重复行。如果原因是上游误删数据，则必须使受影响的下游产物失效，再从可靠版本重算。这里需要的是数据依赖和失效传播，不只是让模型写一句“我将重新检查”。

这张表是诊断顺序，不是自动判因器。同一个表象可能有多个原因。框架应把观察、假设和后续验证分开记录，保留“证据不足”，避免一次失败立即触发全库文本优化。

5. A 调用 B，怎样判断组合值得存在

很多关系图来自日志共现：A 后面经常出现 B，于是建立 A→B。这个证据太弱。两者可能只是都在困难任务中频繁出现，也可能重复完成同一件事。是否存在组合增益，需要在具体任务分布与预算下验证。

我的建议是为重要组合至少保留三个参照：只用 B；在同样约束下使用 A 再用 B；不给 A 额外知识、只增加相近计算预算的直接执行方案。若 A 的贡献是生成中间文件，还应检查 B 实际使用了该文件，以及换成过期或错误产物时结果如何变化。

对开头的例子，“清洗→图表→演示文稿”可能合理；但“所有表格任务都先跑一次清洗”就不合理。用户只要求调整字体时，清洗会引入不必要的数据风险。边的适用域应该随任务条件收窄，而不是随着成功次数增加而无限泛化。

关系也要区分必要依赖与可选帮助：前者不满足就无法执行，后者只是可能提升质量。二者放在同一无标签图里，会让规划器把所有有帮助的步骤都当作必做步骤，技能数量和成本随之膨胀。

6. 一个可以逐步落地的编排器

对已有 C 端框架，我会先增加可追溯性，再增加自动规划自由度。最初只支持少数稳定组合，把一次请求的选择、材料和产物说清楚，通常比先建设庞大的关系学习系统更有价值。

一个节点任务至少应记录以下内容。它是本文的参考契约，字段名称不代表上述项目的统一标准。

node: make_slides
skill: pptx@固定版本
goal: 生成销售复盘演示文稿
inputs:
  - artifact: cleaned.xlsx
    producer: clean_sheet
    digest: 已记录的内容指纹
constraints:
  - 只采用已验证数据
  - 不对外发送文件
outputs:
  - report.pptx
checks:
  - 页面数据与输入一致
  - 关键口径有来源
budget:
  retries: 预先设定的有限次数

在这个基础上，先测试四类故障：候选不适用、读取失败、交接错版本、下游验收失败。每一种都应能从日志找到最早出现问题的位置。再比较直接执行、扁平技能选择与结构化编排的质量和全部成本，详细协议见收益评测篇。

当这些边界清楚之后，再引入关系检索、更多动态节点与自动修复。它们解决的是规模和适应性问题；若基本事件还无法追踪，更多自治只会增加解释失败的难度。

我判断一个编排系统是否成熟，会看它能否回答三句话：这一步为什么需要这个技能，它实际看到了什么，下一步凭什么信任它的产物。 这三件事能解释清楚，才有条件讨论更复杂的能力组合。

参考资料

1. SkillRouter，arXiv:2603.22455v5：技能检索与重排；作者实现。
2. Graph-of-Skills，arXiv:2604.05333v4：依赖感知的结构检索。
3. AgentSkillOS，arXiv:2603.02176v1：组织、编排与产物型任务评测。
4. AgentSkillOS 固定源码：src/orchestrator/dag/engine.py、prompts.py 与 runtime/client.py；源码静态观察不代表独立运行结果。
5. GraSP，arXiv:2604.17870v1：图结构技能组合与修复。

资料以所列固定版本及 2026 年 9 月研究底稿为界，2026-10-07 合并修订。后续版本变化不自动适用于文中结论。

• Previous
  领域驱动设计：战术建模与代码组织
• Next
  Agent Skills：从执行经验到持续改进