什么时候使用 Agent，什么时候使用 Skill？这个问题看起来像工具选择，其实更像工作方式选择。Agent 适合处理变化、判断和执行；Skill 适合沉淀稳定经验，让下一次执行更一致。把两者混在一起用，很容易出现两个问题：本来该让 Agent 灵活判断的任务，被写成僵硬流程；本来该沉淀成 Skill 的经验，又每次靠临场提示重新解释。
我更愿意把它们理解成一组搭档。Agent 是会行动的执行者，能根据上下文拆任务、调用工具、观察结果、修正路线。Skill 是可复用的操作手册，告诉未来的 Agent 在某类任务里应该优先看什么、避免什么、按什么顺序做。前者解决“这一次怎么完成”，后者解决“以后遇到同类问题不要从零开始”。
先把两个概念分清楚
Agent 不是一段提示词，也不是一个更长的聊天窗口。一个真正有用的 Agent，至少要具备四个能力：理解目标、保留上下文、调用工具、根据反馈调整下一步。它可以读文件、跑命令、改代码、检查结果，也可以在发现方向不对时换一种办法。它的价值在于动态执行。
Skill 也不是普通文档。普通文档是给人看的，Skill 是给未来的 Agent 用的。它应该告诉 Agent：什么时候该触发这个能力，任务应该按什么流程推进，哪些坑必须避开，什么结果才算完成。一个好的 Skill 不需要把所有背景知识都塞进去，但要把容易被忘掉、容易被做错、值得反复复用的经验写清楚。
所以二者的差别不在“谁更高级”，而在职责。
Agent 面向当前任务。它要处理真实环境里的不确定性：文件可能不存在，测试可能失败，用户需求可能含糊，外部 API 可能变化。Skill 面向重复任务。它把某类任务的稳定做法固定下来，让下一次 Agent 不必重新摸索。
这也是最容易误判的地方。很多人看到一个流程复杂，就想写 Skill；看到一个任务开放，就想多派 Agent。实际上，复杂不等于适合 Skill，开放也不等于适合 Agent。关键要看不确定性和复用频率。
一个实用判断：不确定性和复用频率
我通常用两个问题判断。
第一个问题：这件事的不确定性高不高？如果任务路径不清楚，需要先调查、试错、判断、验证，那就偏 Agent。比如排查一个线上问题、理解一个陌生仓库、为一个新功能找实现方案。这类任务一开始很难写成固定流程，因为你还不知道真正的关键点在哪里。
第二个问题：这件事会不会反复发生？如果它每周、每个项目、每次发布都会遇到，就值得考虑 Skill。比如写文章发布流程、代码 review 检查表、排障时的日志收集顺序、生成某类报告的格式要求。这些东西每次靠人提醒一次，会慢慢变成团队隐性成本。
把这两个维度放在一起，就有四种情况。
低复用、低不确定性：不用 Agent，也不用 Skill。普通提示就够了。比如“把这段话改得更口语一点”“给这个标题想三个备选”。这类任务没必要过度工程化。
低复用、高不确定性：用 Agent。比如临时分析一个陌生错误，或者探索一个新工具能不能接入当前项目。它可能只发生一次，但过程需要判断和工具调用。
高复用、低不确定性：用 Skill。比如每次发布文章都要做 SEO、图片、构建、git 安全检查。流程稳定，规则明确，最适合沉淀。
高复用、高不确定性：先用 Agent 跑几次，再把稳定部分沉淀成 Skill。这个区间最常见，也最值得耐心处理。比如“如何做一次高质量代码审查”。每个仓库不同，具体问题不同，所以需要 Agent 判断；但审查顺序、风险分类、输出格式、测试缺口这些东西又很稳定，可以写进 Skill。
什么时候应该使用 Agent
当任务需要持续判断时，用 Agent。这里的“判断”不是简单分类，而是根据中间结果改变路径。
比如你让系统“修复一个构建失败”。这不是一条固定命令能解决的事。Agent 需要先跑构建，读错误，判断是依赖问题、类型问题、路径问题，还是配置问题。修完后还要重新验证。如果新的错误出现，它还要继续收敛。这个过程明显适合 Agent。
再比如“分析这个仓库的架构并告诉我从哪里下手”。Agent 需要浏览目录、读关键文件、找入口、理解数据流，然后把结果组织成建议。这里没有稳定到可以直接写成 Skill 的流程。Skill 可以规定分析顺序，比如先看 package、路由、布局、测试命令；但真正的理解仍然要靠 Agent。
还有一类场景是多工具协作。只要任务需要读文件、跑命令、改代码、截图验证、再根据结果调整，就应该让 Agent 负责。Skill 可以给它原则，不能替它执行。
我会在这些情况下优先用 Agent：
- 需求还不完全清楚，需要边问边收敛。
- 任务结果依赖当前仓库、当前页面、当前错误日志。
- 中途可能失败，需要读取反馈后修正。
- 需要比较多个方案，并结合上下文做选择。
- 需要调用工具完成真实操作，而不是只输出一段文本。
Agent 的优势是能动。但这也是它的风险。Agent 如果没有边界，就会做太多；如果没有验证，就会过早宣布完成；如果上下文太杂，就会抓错重点。所以使用 Agent 时，最重要的不是“让它自由发挥”，而是给它清楚的目标、约束和完成标准。
一个好的 Agent 任务应该像这样：
目标：修复当前 Astro 博客的文章构建失败。
范围：只修改 src/layouts、src/pages/posts 和必要的 public 资源。
限制：不要改 package 依赖，不要提交 dist。
验证：必须运行 pnpm build。
输出：说明改动文件、验证结果、剩余风险。这比“帮我看看哪里坏了”可靠得多。
什么时候应该使用 Skill
当你发现自己第三次向 Agent 解释同一件事，就该考虑写 Skill。
Skill 的价值不是让 Agent 变聪明一点，而是让它少走弯路。比如你希望每次发布文章时都必须先确认 brief、生成图片、跑构建、只 stage 相关文件、避免 git add .。这些要求如果每次都靠用户口头提醒，很容易漏。写成 Skill 后，它就变成流程的一部分。
Skill 适合三类内容。
第一类是稳定流程。比如文章发布、代码审查、测试失败排查、PDF 处理、表格生成。这些事情每次对象不同，但步骤差不多。Skill 可以写清楚入口条件、执行顺序、检查项和反模式。
第二类是团队偏好。比如“这个项目用 pnpm，不用 npm”“文章必须带图片和图片风格”“不要提交 dist”“中文文章默认 zh-CN”。这些不是通用常识，但对你的工作很重要。
第三类是容易犯错的判断。比如“什么时候可以 commit”“什么时候必须先问用户”“什么时候不能开 subagent”“什么时候需要查最新资料”。这类东西最适合写进 Skill，因为它们不是代码能自动保证的，却会直接影响结果质量。
但 Skill 也不能滥用。一个 Skill 如果只是写了很多常识，比如“代码要清晰”“文章要好读”，帮助不大。好的 Skill 应该足够具体，能改变 Agent 的行为。它最好回答这些问题：
- 什么情况下必须使用这个 Skill？
- 开始前要确认什么？
- 操作顺序是什么？
- 哪些事情绝对不能做？
- 什么时候算完成？
- 如果失败，下一步怎么处理？
如果这些问题答不出来，说明这个 Skill 还没沉淀到位。
最常见的错误：把 Agent 当 Skill 用
很多人会把同一段超长提示词反复贴给 Agent，让它每次按这个流程干活。这其实是在用 Agent 临时扮演 Skill。
短期看没问题，长期看会有三个坏处。
第一，提示词会越来越长。你今天补一条“不要忘记构建”，明天补一条“不要提交 dist”，后天再补一条“图片要带 alt”。最后这段提示词变成一坨没人愿意维护的东西。
第二，执行不稳定。因为这段提示词没有明确触发条件，也没有被组织成流程，Agent 很可能读到了，但没有把它当成硬约束。
第三，经验无法迁移。你在这次对话里纠正过的问题，下次新会话仍然会再犯。
如果一段提示词已经被你复制了好几次，或者你发现自己总是在纠正同一种错误，那就应该把它改成 Skill。Skill 不一定很长，反而应该尽量短。它的重点是把关键动作和边界写准。
另一个错误：把 Skill 写成百科
Skill 不是知识库。它不应该把所有背景、理论、案例都塞进去。未来的 Agent 读 Skill，是为了知道怎么做，不是为了学习一门课。
比如一个“文章发布”Skill，不需要解释什么是 SEO，也不需要展开讲 Open Graph 的历史。它需要明确：frontmatter 要有哪些字段，图片要怎么处理，构建失败怎么办，git 只能 stage 哪些文件，什么时候必须停下来等用户确认。
Skill 写得越像百科，越容易被跳过重点。一个实用的 Skill 应该像检查表、流程图和护栏的组合。它不负责替 Agent 思考所有细节，只负责在关键地方把 Agent 拉回正确轨道。
Agent 和 Skill 最好的关系：先探索，再固化
我最推荐的做法是：先用 Agent 处理新问题，等模式稳定后再写 Skill。
第一次做某件事，不要急着写 Skill。让 Agent 去探索，看看真实难点在哪里。你以为难点是写作，结果可能是发布流程；你以为难点是代码实现，结果可能是测试环境；你以为难点是图片生成，结果可能是图片版权和路径管理。
第二次做同类任务时，开始记录重复步骤。哪些判断每次都一样？哪些错误每次都容易出现？哪些用户偏好每次都要重复说明？
第三次再做时，就可以写 Skill。不要把第一次探索时的所有细节都写进去，只写已经被验证过、以后还会用到的部分。
这个节奏很重要。太早写 Skill，会把未验证的做法固化下来；太晚写 Skill，又会浪费 Agent 的执行能力。比较合理的信号是：你已经能说出“下次再做这件事，必须按这些规则来”。
一个简单决策清单
如果你还不确定该用 Agent 还是 Skill，可以按下面这组问题判断。
先问：这件事需要操作真实环境吗？需要读文件、跑命令、改代码、查资料、截图验证吗？如果需要，用 Agent。
再问：这件事的路径是否确定？如果路径不确定，用 Agent 探索。如果路径已经很稳定，考虑 Skill。
再问：这件事以后会重复吗？如果只做一次，不必写 Skill。如果会反复做，尤其是每次都要求相同标准，就应该写 Skill。
再问：这件事失败的代价高不高？如果代价高，比如发布、提交、删除、迁移、收费操作，就应该把安全检查写进 Skill，让 Agent 每次都走同样的确认流程。
最后问：这里有没有容易被忘记的偏好？比如文件路径、命名规则、输出格式、审查口径、禁止事项。如果有，Skill 很适合承载这些偏好。
简化成一句话：不确定的执行交给 Agent，确定的经验沉淀为 Skill；先让 Agent 把路走通，再让 Skill 把路标立起来。
在个人工作流里的用法
个人使用时，我建议从小 Skill 开始。不要一上来写一个“万能工作流”。先挑最常重复、最容易出错的一件事。
比如写文章。你可以先让 Agent 帮你写几篇，观察每次都要补充什么要求。可能是“要先确认受众”，可能是“文章里要有图”，可能是“发布前必须跑构建”，也可能是“不要直接 push”。把这些要求整理成 Skill，就能显著减少下一次沟通成本。
再比如代码 review。第一次让 Agent review，它可能只看语法；第二次你提醒它关注回归风险；第三次你提醒它先列问题再总结。到这里就该写 Skill 了：review 时按严重程度输出 findings，必须引用文件行号，先讲风险，不要先夸改动。
个人 Skill 不需要完美。它应该随着真实使用慢慢变硬。每次 Agent 犯了可复用的错误，就补一条；每次发现某条规则没用，就删掉。Skill 是活的流程，不是一次写完的制度。
在团队里的用法
团队场景下，Agent 和 Skill 的边界更重要。因为团队的目标不是让某个人这次跑得快，而是让不同人、不同会话、不同 Agent 都能稳定产出。
团队可以把 Skill 当作“AI 工作规范”。比如：
- 发布 Skill：规定版本号、构建、截图、回滚说明。
- Review Skill：规定审查重点、输出格式、风险分级。
- Debug Skill：规定先复现、再定位、再最小修复、最后验证。
- 文档 Skill：规定语气、结构、术语和示例风格。
这并不意味着所有事情都流程化。Agent 仍然负责处理具体任务里的不确定性。但 Skill 可以保证底线：该问的问题要问，该跑的验证要跑，该避开的危险动作不能碰。
团队最应该沉淀的不是“如何写出更聪明的答案”，而是“哪些行为不能漏”。比如不验证就宣布完成、随手 git add .、没看用户已有改动就覆盖、没确认发布意图就 push。这些错误靠口头提醒很难长期稳定，写进 Skill 更现实。
怎么把一次 Agent 经验变成 Skill
写 Skill 可以按一个很朴素的方式来。
先记录触发条件：什么时候必须用它？比如“用户要求发布文章”或“准备完成任务并声称通过验证”。
然后写核心流程：第一步做什么，第二步做什么，哪里必须停下来等确认。不要写太多解释，未来的 Agent 需要的是行动顺序。
接着写反模式：哪些事情以前做错过？比如“不要用 git add .”“不要发布占位图”“不要把草稿请求直接推送到远端”。
最后写完成标准：什么证据能证明任务完成？是构建通过、测试通过、截图正常，还是用户明确批准？
一个 Skill 能不能用，不看它写得多漂亮，而看它能不能改变下一次 Agent 的行为。如果它能阻止一次危险提交，或者减少一次重复解释，就已经值了。
结论
Agent 和 Skill 不是替代关系。Agent 负责在不确定环境里完成任务，Skill 负责把稳定经验变成可复用的流程。
遇到新问题，先用 Agent。让它探索、判断、执行、验证。等你发现某些步骤开始重复，某些要求总要强调，某些错误总会再犯，就把这些东西写成 Skill。
真正高效的 AI 工作流，不是到处开 Agent，也不是给所有事情都写 Skill，而是让二者各司其职：Agent 处理变化，Skill 保持一致；Agent 把路跑通，Skill 把路留下。
这就是我判断“什么时候使用 Agent，什么时候使用 Skill”的核心标准。