System prompt 和 user message 看起来做的是同一件事——都是影响模型的文本。但它们的用途根本不同，在 API 中的位置不同，时间范围也不同。
不同的用途
System prompt — 设定 agent 的角色、行为规则和持久指令。“你是一个研究助手。只引用经过验证的来源。保持专业语气。“这为 agent 的每一条响应定调。
User message — 提供当前轮次的具体任务或问题。“总结这篇文档。""processPayment 函数做了什么？“这是逐轮的输入，每次交互都会变。
持久的行为要求（语气、策略、角色）放 system prompt。逐轮的内容（问题、待分析的文档）放 user message。
在 API 中的位置不同
系统指令用顶层的 system 参数——在 messages 数组外面。用户的问题放在 messages 数组里，role: "user"。两者在结构上是分开的。
messages 数组里没有 role: "system"。没有合并的 instructions 参数。系统内容不在 HTTP header 里。System prompt 有它自己的专用参数。
API 是无状态的
关键事实：Claude API 是无状态的。System prompt 不会在第一次请求后存储在服务端。每次请求都必须包含 system prompt——没有”服务器记得上次的”这回事。如果你在某次请求中省略了 system prompt，模型在那次调用中就没有行为框架。
这意味着 system prompt 会出现在每次 API 调用中，增加 token 消耗。但这是刻意设计的——每次请求自包含，system prompt 提供一致的行为框架。
正确的分工
客服 agent 的例子：
- System prompt：专业语气、公司政策、升级规则 → 适用于每一条响应
- User message：“客户询问订单 #12345 的退货政策” → 每轮不同
不要把持久规则放在 user message 里（每轮都重复，浪费）。不要把逐轮的问题放在 system prompt 里（它不变）。各有各的归属。
一句话总结： System prompt 在顶层 system 参数中提供持久的行为框架（角色、规则、语气）；user message 在 messages 数组中提供逐轮输入——API 是无状态的，所以每次请求都要带上 system prompt。