给Agent沉淀Skill还是反复教？方式对比与选型

一、对比背景：为什么“每次都像第一次做”

如果你最近频繁与 Agent 协作，大概率遇到过这样的场景：你刚刚纠正过的输出格式、提醒过的风险点、跑通的工具调用顺序，换一个任务又要从头解释一遍。它不是完全不会做，而是每次都像第一次做。

这个问题的本质并不是模型“不聪明”。人类同事做熟一件事后，会形成习惯、检查表和固定的操作路径；而 Agent 的“经验”只存在于当前上下文里，会话结束或任务切换，这些纠正和提醒就随之丢失。无论是直接使用通用对话助手，还是在百度智能云等平台上构建智能体应用，只要任务里的经验没有被结构化沉淀下来，这种重复解释就不可避免。

实践中应对这个问题有两种典型方式：

• 方式A：反复对话教学。每次任务中通过临时提示、现场纠正、举例演示来引导 Agent；
• 方式B：沉淀 Skill。把一类任务的做法整理成结构化的能力包，让 Agent 下次主动调用。

本文就围绕这两种方式展开对比，回答三个问题：它们的差异到底在哪里？各自适合什么场景？如果要迁移，需要注意什么？

二、对象定义：两种方式分别是什么

方式A：反复对话教学

这是最常见的默认做法。每次把任务交给 Agent 时，用户在对话里临时说明要求：文档要按什么版式排、代码 Review 先看什么、工具调用的参数顺序是什么。Agent 在当次会话中表现良好，但这些信息没有脱离会话存在，下一次任务需要重新输入。

方式B：沉淀 Skill

Skill 不是把知识“灌进”模型，也不是让模型永久学会某个技能，而是一个可被 Agent 打开和执行的工作手册。它通常是一个目录，核心是一个说明文件（如 SKILL.md），说明这个能力适用于什么任务、开始前要读什么、按什么顺序做、哪些情况必须停下来确认；目录中还可以放模板、参考资料和辅助脚本。

其关键机制是按需加载：平时只在 Agent 的可用列表中暴露一条简短的 description，用于第一眼匹配；真正命中任务时，才把详细流程读进上下文。一句话概括：Skill 是给 Agent 使用的可复用工作能力包，把触发条件、操作流程、参考资料、工具脚本和验收标准放在一起。

一个典型的目录结构如下（通用示意）：

my-skill/
├── SKILL.md        # 触发条件、执行顺序、确认点
├── checklist.md    # 输出前的验收清单
├── templates/      # 固定输出模板
└── scripts/        # 可复用的辅助脚本

说明文件中的触发描述可以这样写（通用示意）：

description: 当用户要求"按团队格式整理纪要"或"输出周报"时触发
执行顺序:
  1. 读取 templates 下的最新模板
  2. 按"提取要点 → 归类 → 校对格式"的顺序处理
  3. 输出前逐项核对 checklist
  4. 遇到缺失字段先向用户确认，不自行补全

三、相同点：它们共享的底层逻辑

在展开差异之前，先明确两种方式的共同点，避免误以为它们是完全互斥的关系。

1. 目标一致。两者都是为了让 Agent 在同类任务中把事做对，减少猜测、遗漏和返工。
2. 都不改变模型本身。两种方式都不涉及训练或微调，本质都是通过上下文向模型注入信息，只是注入的时机、结构和持久性不同。
3. 都依赖人的经验质量。无论临时教还是写成文档，经验本身没总结清楚，Agent 照样做不好，输入质量决定输出上限。
4. 都需要持续维护。任务要求变化时，临时教学的说法要更新，Skill 文档同样要更新，否则会出现“照着旧流程做错事”的问题。

四、核心差异：七个维度的系统对比

1. 知识载体与组织方式

反复教学的信息散落在聊天记录里，与某次具体对话绑定，是非结构化的。Skill 则要求把经验拆解为触发、执行、资料、验证四个部分分开组织。这个结构化过程本身就有价值：很多你以为说清楚了的细节，落笔时才发现存在缺漏。

2. 触发与复用机制

教学方式下，触发完全靠人：你得记得“这件事上次教过”，还得记得教了什么。Skill 把触发条件写进 description，由 Agent 做第一眼匹配，同类问题出现时按既定方法执行，不再依赖人的记忆，也就不会因为忘记提醒而漏做。

3. 上下文占用与成本

每次重复教学，都要占用当次会话的上下文空间，且大部分内容与本次任务的新信息无关。Skill 平时只暴露一行说明，触发后才加载详细流程，单次任务的上下文开销更小，也降低了长任务中关键要求被挤出上下文的风险。

4. 输出一致性与稳定性

口头教学的输入质量随人的状态波动：说得细就做得好，说得略就漏步骤。Skill 以固定文本存在，配合 checklist 等验收标准，同类任务的步骤和输出风格更稳定。“少猜、少漏、少返工”正是来自这种确定性。

5. 团队协作与复用边界

聊天记录里的经验基本是个人资产，难以交接。Skill 是目录形态的文件，可以入库、评审、版本化，一个人的踩坑总结可以变成整个团队的标准做法，这是教学方式做不到的。

6. 成本结构

教学方式前期成本几乎为零，但成本随使用次数线性增长——每做一次任务就付一次“解释税”。Skill 需要前期投入整理和编写，之后边际成本趋近于读取文档的成本，使用频率越高摊薄越明显。

7. 错误反馈与演进路径

教学中发现 Agent 做错了，当场纠正即可，反馈快但不留痕。Skill 的错误会稳定复现，反而更容易定位是流程写得有问题还是触发条件不精确，可以像维护代码一样迭代文档。

差异汇总表

对比维度	反复对话教学	沉淀 Skill
知识载体	聊天记录，非结构化	目录化文档，结构分离
触发方式	人工重复说明	按 description 自动匹配
上下文占用	每次重复注入	平时仅加载简短说明
输出一致性	随表达质量波动	流程+验收标准，稳定
团队共享	个人资产，难复用	可入库、评审、版本化
成本结构	零前期、线性增长	有前期、长期摊薄
适用任务	一次性、探索性	高频、流程化、格式严格

五、典型场景选择

适合反复教学的场景：

• 一次性任务：只做一两次的事情，沉淀成本收不回来；
• 探索性任务：做法尚未定型，先在对话里试错，等路径稳定再沉淀；
• 快速验证：验证某个想法是否可行，不值得先写文档。

适合沉淀 Skill 的场景：

• 高频重复任务：如每周的纪要整理、日报周报，重复次数越多收益越大；
• 格式严格型任务：排版、命名、字数等硬性要求，靠记忆容易漏；
• 固定流程型任务：先看 diff、再看测试、最后列风险这类顺序敏感的工作；
• 多人协作场景：团队需要统一做法时，Skill 是可共享的标准；
• 易错型任务：参数顺序、必须确认的风险点，适合写进验收标准强制拦截。

六、选型建议

结合上述差异，可以按以下条件做判断：

1. 看频率。同一个纠正说到第三遍，就是明确的沉淀信号；只出现一次的要求，留在对话里即可。
2. 看结构化程度。任务要求能写成“步骤+检查项”的，适合 Skill；高度依赖临场判断的，教学更灵活。
3. 看团队规模。个人使用可以容忍聊天记录式的松散经验；多人协作时，结构化 Skill 的共享价值会迅速放大。
4. 看容错成本。出错代价高的任务（如涉及生产环境的操作），更值得用 Skill 把确认点和验收标准固化下来。
5. 推荐混合策略。两者不是二选一：日常用教学保持灵活，定期回顾对话，把反复出现的纠正提炼成 Skill。先教学观察、后沉淀固化，通常是成本最低的路径。

七、迁移与使用注意事项

从“反复教”转向“沉淀 Skill”，有以下几点需要提前评估：

1. 触发条件要写清。description 的核心是回答“用户说什么时应该触发这个 Skill”，写得含糊会导致该触发时不触发，或不该触发时误触发。
2. 避免过度沉淀。不是所有对话都值得写成 Skill，判断标准是“下次还会遇到、做法已经稳定、做错有成本”。沉淀太多低频内容反而增加 Agent 的匹配负担。
3. 保持渐进加载设计。说明文件本身保持简短，详细资料放目录内按需引用，避免把所有内容堆进一个文件，失去按需加载的优势。
4. 建立更新机制。任务要求变更时同步修订文档并记录版本，防止旧流程被错误沿用。
5. 注意脚本与资料安全。目录中的脚本会被真实执行，应做好权限控制和内容审查，避免引入未经确认的操作。
6. 从现有素材入手。迁移不必从零开始：翻看历史对话里反复出现的纠正和提醒，就是最好的编写素材，把它们按“触发—流程—资料—验证”重新组织即可。

八、总结

反复对话教学和沉淀 Skill 解决的是同一个问题——让 Agent 把事做对，但路线完全不同：前者把经验留在会话里，随用随付、灵活但不可积累；后者把经验结构化为可被 Agent 主动调用的能力包，前期有投入、长期可复用、团队可共享。判断的核心不是哪种方式绝对更好，而是任务的重复频率、结构化程度、容错成本和协作范围。实践中更可取的是混合策略：用教学应对探索，用 Skill 承接稳定，让 Agent 少猜一点、少漏一步、少重复问一遍背景。