搓Skill还是Agent？不用纠结了！

Claude Code 中 skill 和 agent 到底有何区别？提示词该放进 skill 还是做成 agent？Skill 执行特定任务，agent 承载底层思维模型与工作模式。理解两者差异，才能搭建高效的 AI 协作工作台。

从我刚开始介绍「Claude Code」上的skill和agent开始，就有不少小伙伴问我，这两个东西到底有什么区别？提示词应该放进skill里，还是做成agent？

最开始我的做法比较简单粗暴。

「Claude Code」上agent最显著的特征是什么？是它能单开一路，处理过程不干扰当前对话，也不占用上下文资源，还可以绑上指定模型。所以，我把类似审稿之类的提示词，都做成了agent。

但是，随着使用深入，和「Claude Code」升级优化，我发现这种使用方式并不是最好的选择，原因如下：

首先，这种写法本质上还是在做skill，而将这些具体的能力分散在skill和agent中，会让提示词管理变得零散而混乱，不便于后期维护。

其次，如果只是为了单开一路，大可不必这么干，因为现在「Claude Code」已经支持给skill指定启用agent运行，或agent运行时主动挂载某些skill，完美解决了之前的场景需求。

所以，到底什么情况下制作skill，什么时候该写agent呢？

Agent和skill的根本区别

关于skill的文章，我已经写了很多，网上还有各路大佬的分享，相信大家已经不陌生。简单来说，skill就是用于执行特定处理、解决特定问题的提示词片段（当然也可以带有脚本）。

那么agent是什么？主要用来做什么？

当我们感到困惑的时候，官方文档就是最好的指引。我们或许可以从「Claude Code」官方内置的几个agent窥见一斑，包括如下几种：

抛开最后「其他」里几个不谈，探索（Explore）、计划（Plan）、通用（General-purpose）这几个agent特点显著，它们面向的场景较为宽泛，都是以一套机制作为支撑，来保障生成效果。

举个更直观好理解的例子，「Antigravity」上的Planning模式，其实就和「Claude Code」上这些agent类似。Planning模式下，AI会经过深入的分析思考，规划任务和执行步骤，然后按照计划执行，最终向用户反馈变更信息，依次完成Task→Implementation→（用户要求的）生成内容→Walkthrough，依托这一套机制来高质量交付。

由此可见，agent承载的并不是具体的执行技巧、套路，而是更底层的思维模型、工作模式。

这才是agent和skill根本性的区别。

怎么设计agent

Agent面向的不是某个具体的问题，而是某类问题，并提供解决这一类问题的过程管理。

在我们工作场景中，这种处理方式可太常见了，比如质量管理常用的PDCA模型，文档编写常用的金字塔模型，故事创作常用的雪花写作法……我之前示例中做的 生成-审稿 循环、之前小火过一把的 多专家评审 等模型，其实也都可固化成一套解决问题的框架。

为什么这些框架有效？因为它们找到了“做事”的章法，把处理过程变得条理分明，形成流程、规则、标准。避免盲目抓瞎不知如何下手，也避免随意发挥导致交付质量不可控。有了这些方法加持，即使是新手操刀，结果也不会糟糕到哪里去。

投射到人机协作上，把框架落地成提示词，就变成了agent。调用agent本质上就是选择一套思维模型、框架，来提升输出品质。

现在，对于agent的设计，是不是更清晰了？

写法上依然是那些提示词设计的技巧，定义角色、工作流程、读写交互等，agent更注重通过好的过程控制保障结果质量，并不拘泥于细节上的小技巧。

小结

以上是我经过一段时间实践后，对「Claude Code」上skill和agent两套机制的理解。

随着「Claude Code」升级迭代，不管skill还是agent，都在变得更加完善。灵活搭建「AI写网文」工作台的同时，我们可以进行更细致的管控和配置，两者使用场景渐已分明。

现在「Claude Code」内置的几款agent，其实都不够贴合网文创作的场景。如何提升剧情质量，如何解决记忆问题，如何避免OOC……这些都是写文Agent绕不开的问题。

感兴趣的壮士们，可以开动脑筋搓搓看，没准就炼出神器了呢？

「Claude Code」关于agent搭建的官方文档地址：

https://code.claude.com/docs/zh-CN/sub-agents

题图来自Unsplash，基于 CC0 协议。