做 Agent 最容易写错的两样东西，System Prompt 和 Skills 真不是一回事

很多人刚开始做 Agent，最容易犯的一个错，不是模型选错了，也不是工具接少了，而是把两类完全不同的东西混到一起了：System Prompt 和 Skills。

表面看，它们都像在给模型下命令，都是一堆说明、一堆约束、一堆规则。可真正落到工程里，这俩东西压根不是一个层级，也不是一个用途。

如果你把边界搞混，Agent 一开始可能还能跑，跑着跑着就会越来越重，越来越乱，最后不是触发错技能，就是上下文臃肿，要么就是改一个地方，别的地方全跟着崩。

所以这篇最值得讲透的，其实不是概念解释，而是一个很现实的问题：

System Prompt 到底该管什么，Skill 到底又该放什么？

System Prompt 管的是“你是谁，底线在哪，默认怎么做”

System Prompt 本质上是 Agent 的总控层。

它负责的是那些不应该随着具体任务频繁变化的东西，比如：

• 角色身份
• 行为边界
• 安全约束
• 默认工作方式
• 回答风格和工具使用原则

你可以把它理解成宪法，或者操作系统级规则。

它不是拿来写具体业务流程的，也不是拿来塞某一类任务的详细操作手册的。

因为 System Prompt 一旦过重，就会有两个典型问题。

第一，所有任务都得背着它。你今天做设计、明天写代码、后天查文档，结果每次都要把一大坨不相关规则扛进上下文。

第二，它会越来越难改。因为你塞进去的内容越杂，它就越像一团拧在一起的总开关，碰一下就可能连别的任务行为也带歪。

所以 System Prompt 适合放“长期不变的总规则”，不适合放“某类任务的详细流程”。

Skills 管的是“遇到这种任务时，具体该怎么做”

Skill 则是另外一层。

它不是用来定义 Agent 是谁，而是用来定义 Agent 在某种特定任务场景里该怎么干活。

比如：

• 做产品原型时，先梳理目标用户、页面结构、状态补齐，再出原型
• 写技术文档时，先查官方资料，再归纳接口，再给示例
• 做代码评审时，优先看边界条件、异常处理、回滚路径和测试覆盖
• 处理 PDF 时，什么时候该读说明，什么时候该直接跑脚本提字段

这些东西都不该常驻在 System Prompt 里。

因为它们不是总规则，而是任务性知识、流程性知识、领域性知识。它们最好按需触发，按需加载。

这也是为什么 Skills 这套东西现在越来越重要。它本质上是在把“做事方法”模块化。

两者最大的区别，不在内容长短，而在控制层级不同

很多人会误会，以为 System Prompt 和 Skill 的差别只是一个写得更大，一个写得更细。

其实不是。真正差别在于控制层级。

System Prompt 解决的是： 这个 Agent 默认如何思考、说话、用工具、守边界。

Skill 解决的是： 在某一类任务里，具体步骤、参考资料、脚本和验证方式怎么组织。

一个是全局控制，一个是局部能力。

一个是长期常驻，一个是条件触发。

一个决定 Agent 的骨架，一个决定 Agent 某些动作怎么做得更专业。

这俩如果混了，系统就会很别扭。

最常见的错法，是把流程全塞回主提示词

很多团队一开始做 Agent，最顺手的办法就是继续往主提示词里堆东西。

这个任务加一段规则，那个场景加一段说明，写文档再补一段风格要求，做设计再塞一段步骤，慢慢主提示词就膨胀成了一个谁都不敢碰的巨物。

这类 Agent 常见症状特别明显：

• 上下文很快膨胀
• 行为不稳定，时灵时不灵
• 明明是 A 任务，老被 B 规则干扰
• 想优化某个能力时，不知道该改哪一段
• 新成员接手后根本看不懂这一大坨规则是怎么长出来的

说白了，就是把本来该模块化的流程，硬写进了总控层。

短期看省事，长期看一定烂。

另一种错法，是把核心身份和边界也塞进 Skill

当然还有另一种常见反向错误。

就是过度迷信 Skill，把一些本来应该永远生效的东西，也拆成 Skill。

比如安全底线、输出风格、权限限制、默认工具策略、回复纪律，这些如果变成“某个 Skill 才会带上”，那就会出大问题。

因为这类东西不是能力模块，而是 Agent 的人格和边界。

边界不能按需触发，底线也不能看心情加载。

所以真正稳的结构，一定是：

• System Prompt 放长期有效的骨架规则
• Skills 放任务特定的专业流程
• 脚本和资源文件继续挂在 Skill 下面，按需被调用

这样系统才会既稳又轻。

真正成熟的 Agent，靠的不是一个超级提示词，而是分层

这也是为什么现在越来越多成熟 Agent 系统，都在往分层走。

不是拼命写一个万能 prompt，而是把不同层级的问题拆开：

• 总控层负责身份、边界、默认策略
• 任务层负责 Skill 触发和流程约束
• 工具层负责脚本、API、代码执行和确定性处理
• 资源层负责参考文档、模板、知识文件和附加上下文

这套东西一分开，很多问题反而就简单了。

你要调行为，就看是不是总控层问题； 你要补任务能力，就加 Skill； 你要提确定性，就往脚本和工具里下沉。

这才是 Agent 真正工程化的样子。

一个更直接的判断

如果你现在的 Agent 越写越重、越改越乱、主提示词越来越像一个失控的大杂烩，那大概率不是模型不行，而是分层做错了。

System Prompt 和 Skills 之所以老被混淆，本质上是因为它们都长得像“文本指令”。

但真正值钱的，不是它们都是文字，而是它们分别处在不同的控制层。

System Prompt 管骨架，Skill 管做法。

把这层边界理顺，Agent 才会从“能跑一次”慢慢进化成“能长期维护、长期迭代、长期复用”的系统。

顺手说一句，如果你后面真要把这种 Agent 分层、技能文件、脚本执行和发布链路都接起来，底层环境也得稳住。像雨云这种偏实干型的云服务，拿来挂自动化任务、对象存储、脚本服务和轻量工作流，其实就挺合适。很多团队以为自己缺的是一段更强的 prompt，实际上缺的是一套能把分层架构真正跑起来的环境。