前三篇我们把 AI Agent 的核心原理拆完了：LLM 负责思考，Tool Use 负责执行，Agent Loop 把它们串成循环。
但你有没有想过一个问题：同样是 Claude 模型，为什么你可以让它变成一个严格的代码审查员，也可以让它变成一个自主干活的编程助手？模型没变，工具也没变，凭什么表现完全不一样？
答案就是今天要聊的东西，System Prompt。
什么是 System Prompt
System Prompt，直译叫"系统提示词"，但我更喜欢叫它 Agent 的"出厂设置"。
你可以把它理解为一段写给 LLM 的"内部指令"。用户看不到它，但它在每次对话中都会被发给 LLM，默默地影响着 LLM 的一切行为。
Anthropic 在 Claude 的 API 中，专门提供了一个 system 参数来设置它：
| |
就这么一段话，就能让同一个 Claude 模型表现得完全不同。加上这段 system prompt，它就变成了一个严肃的代码审查员；换一段，它又能变成一个耐心的编程导师。
在 Agent 的整体架构中，System Prompt 的位置大概是这样的：
| |
System Prompt 是所有行为的起点。LLM 每次思考之前，都会先"读"一遍这个出厂设置，然后再决定怎么做。
System Prompt 到底管什么
一个好的 System Prompt 通常定义以下几件事：
1. 身份和角色
告诉 LLM “你是谁”。这不是闲聊，而是在设定它的行为基调。
比如 Claude Code 的 System Prompt 开头就会告诉 Claude：你是一个终端环境下的 AI 编程助手，你的任务是帮助用户完成软件工程任务。
这一句话就决定了 LLM 后续的所有行为倾向，它会倾向于读代码、写代码、执行命令，而不是跟你聊天侃大山。
2. 行为规则
告诉 LLM “该做什么、不该做什么”。
比如：
- 修改文件之前必须先读取文件内容
- 不要在没有用户确认的情况下执行危险命令（比如
rm -rf） - 回复要简洁，不要输出多余的解释
- 优先使用专用工具而非 Bash 命令
这些规则就像公司给新员工发的行为手册。LLM 会尽量遵守这些规则来完成任务。
3. 工具使用策略
虽然工具定义告诉了 LLM “有哪些工具可以用”，但 System Prompt 可以进一步指导 LLM “什么时候该用哪个”。
比如 Claude Code 的 System Prompt 里，有大量类似这样的指导：
- 搜索文件用 Glob 工具，搜索文件内容用 Grep 工具
- 简单的代码搜索直接用工具，复杂的探索性搜索交给子 Agent
- 修改文件优先用 Edit 工具而不是完整重写
- 读文件用 Read 工具，不要用 Bash 执行 cat 命令
没有这些策略，LLM 虽然也能用工具，但可能用得不够好。就像一个新手虽然知道厨房里有哪些工具，但不知道切肉该用什么刀。
4. 输出格式
告诉 LLM 用什么方式说话，用 Markdown 还是纯文本？要不要加 emoji？代码块要不要标注语言？回复该长还是该短？
这些细节决定了用户体验，你可能觉得无所谓，但如果一个终端工具的 Agent 每次回复都输出一大堆 HTML 格式的内容，用起来会很难受。
为什么 System Prompt 这么重要
我打个比方。
LLM 就像一个能力很强但什么都不知道的新人。它脑子聪明、学东西快，但刚来公司什么情况都不了解。
Tool Use 是给它发了一套工具箱，Agent Loop 是让它可以自己干活。
System Prompt 是什么？是入职第一天，老板坐下来跟它说的那番话：
“你是我们团队的后端开发，主要负责 API 模块。我们的代码规范是这样的，git 提交格式是那样的，遇到不确定的事情先问我，不要自己乱搞。对了，生产环境的数据库别乱动。”
有了这番话，这个新人就知道自己该干嘛、不该干嘛、怎么干。没有这番话，它可能也能干活，但大概率会踩坑。
这就是 System Prompt 的价值，它不改变 LLM 的能力上限，但决定了 LLM 在具体场景下能发挥出多少。
同一个模型，不同的 Prompt，完全不同的表现
我们来做一个简单的实验。同一个 Claude 模型，给它两段不同的 System Prompt：
A：代码审查助手
“你是一个专业的代码审查员。用户会给你一段代码，你需要逐行审查，指出潜在的 bug、安全漏洞和性能问题。回复要严谨、有条理，每个问题都要给出修复建议。”
B：终端编程助手
“你是一个终端环境下的 AI 编程助手。用户给你任务，你自己去完成。你可以读文件、写文件、执行命令。回复要简洁高效，优先行动，少说废话。”
同样是让它们处理一个"login 接口有 bug"的问题：
- A（审查员） 会等你把代码贴给它，然后逐行分析，列出问题清单，给出修改建议。它不会主动去读文件、改代码，因为它的角色定位就是"审查"，不是"动手"。
- B（编程助手） 会自己去搜索 login 相关的文件，读源码，定位 bug，改代码，跑测试，测试不过还会自己 debug。整个过程不需要你引导。
同一个 Claude 模型，因为 System Prompt 不同，表现出了完全不同的行为模式。一个像严谨的审查员，一个像独立干活的开发者。
System Prompt 就是 Agent 产品的"灵魂"。 工具和循环是骨架，System Prompt 才是让 Agent 有个性、有风格、有专业性的东西。
System Prompt 的层级结构
在实际的 Agent 产品中，System Prompt 并不只是一段话，而是分成了好几层：
第一层：产品级 System Prompt。 这是 Agent 产品的开发者写死的，用户看不到也改不了。它定义了 Agent 最基础的行为模式，比如 Claude Code 的那几万字 System Prompt，涵盖了身份定义、工具使用策略、输出格式、安全规则等方方面面。
第二层：用户级自定义。 这是 Agent 产品提供给用户的定制入口。比如 Claude Code 的 CLAUDE.md 文件，Cursor 的 Rules 配置。你可以在这里写上你的项目规范、技术栈、代码风格偏好，Agent 每次启动都会把它加到上下文里。
第三层：对话级上下文。 每次对话时动态注入的信息，比如当前打开的文件、项目的目录结构、之前对话的摘要等。这些不是你写的，而是 Agent 程序自动收集并注入的。
这三层叠加在一起，就构成了 LLM 在每次对话中看到的完整"指令集"。产品级 Prompt 定义了基础行为，用户级定制做个性化调整，对话级上下文提供实时信息。
这也是为什么同一个 Claude Code，在不同项目里表现可能不一样，因为每个项目的 CLAUDE.md 不一样，对话级上下文也不一样，等于给 Agent 做了不同的"岗前培训"。
System Prompt 的局限性
说了这么多 System Prompt 的价值，也得说说它的局限，别把它神化了。
第一，LLM 不是 100% 遵守 System Prompt 的。 它只是"倾向于"遵守。你在 System Prompt 里写"回复不要超过 100 字"，它大多数时候会听，但偶尔还是会写一大段。特别是当用户的指令和 System Prompt 有冲突时，LLM 有时候会优先响应用户，毕竟它的本能是"尽可能满足用户的需求"。
第二，Prompt 越长，后面的指令越容易被忽略。 Claude Code 的 System Prompt 有几万字，要把所有规则都遵守得完美无缺是不现实的。这就是为什么 Agent 产品需要不断调优 Prompt，哪些规则放在前面、哪些用粗体强调、措辞怎么写更有效，都是需要反复实验的。
第三，System Prompt 解决不了模型能力本身的问题。 你不能靠一段 Prompt 让一个小模型去做它能力范围外的事情。Prompt 能做的是在模型能力范围内，引导它表现得更好，但不能把天花板抬高。
理解这些局限，你就能更理性地看待 System Prompt 的价值：它很重要，但不是万能的。
一句话总结
System Prompt 就是 Agent 的"出厂设置"，它定义了 LLM 的身份、行为规则、工具使用策略和输出格式。不改变模型的能力上限，但决定了实际表现。
下一篇，我们来聊另一个非常实际的问题，上下文管理。
Agent 跑了几十轮循环之后，消息历史越来越长，token 要爆了怎么办？LLM 的上下文窗口就像一个容量有限的工作台，东西堆多了就放不下了。
怎么在有限的空间里让 Agent 持续高效地工作？这是从"能跑"到"能用"的关键一步。