Agent 的 System Prompt 工程：如何把角色定义、工具描述、约束规则高效塞进有限上下文

2023 年，一篇论文让很多本来埋头调 Prompt 的人心里一凉：语言模型在拿长上下文做“阅读理解”时，会忽略放在中间位置的信息，哪怕那信息跟问题直接相关。这项来自斯坦福、UC Berkeley 等机构的研究，名字就叫 《Lost in the Middle: How Language Models Use Long Contexts》。

如果你写过 Agent 的 System Prompt，一定见过这种“中间迷失”的现场：角色写在开头，工具说明写在中间，规则写在最后。结果模型像个只扫一眼标题和落款的人——开头知道自己是客服，结尾记得要礼貌，但中间的“下雨天记得带伞”完全忘了。

普通问答的 System Prompt 通常只有“你是一个……”几句话。但 Agent 不一样，它要自己做计划、调工具、看结果，System Prompt 是它唯一的操作手册。你需要把四类信息塞进上下文：角色定义（我是谁）、工具描述（我能用什么）、约束规则（我必须遵守什么）、输出格式（我怎么回答）。每一类都在消耗有限的注意力。

这篇文章不谈泛泛的“提示工程”，专门讲 Agent 场景下的 System Prompt 信息架构。下面是我踩过坑之后，为你拆开的四个关键部位。

角色定义：给模型一个“我是谁”的坐标，而不是小作文

我最早以为，角色定义写得越有性格，模型就会越像人。后来发现，模型需要的是“决策边界”，不是“人格魅力”。你写“你是一名亲切而有耐心的旅行顾问”，模型只学会了“亲切”和“耐心”，却没搞清自己到底该管哪些事。好的角色定义包含三要素：身份、职责、边界。比如：

你是 CNHack 的客服 Agent。
你的职责是处理订单、退换货和物流咨询。
超出这三个范围的问题，请礼貌地告诉用户你无法处理，并建议转人工。

短短三句话，模型就知道自己什么能碰、什么不能碰。为什么这个很重要？因为角色定义是模型所有推理的“起点”，开头位置的注意力权重最高，这个坐标一旦歪了，后面所有规则都会被带偏。

工具描述：不是写 API 文档，是写“触发时机”

工具描述是 System Prompt 里最耗 token 的部分，也是错得最离谱的部分。我曾见过有人把每个工具的参数说明照抄进 Prompt，还带上默认值和枚举类型。模型根本用不过来。

工具描述真正要回答的是两个问题：什么时候用我？用的时候要注意什么？用一张对比表感受下差别：

反面写法最大的问题是：只说了“这是什么”，没说“什么时候用”。模型遇到所有包含“天气”的请求都会想去调用，哪怕用户只是说“今天天气很好，推荐个户外活动”。而正面写法用“触发场景”提前告诉模型：这个问题先要推荐活动，不一定要调天气工具。

压缩工具描述的常用套路，是把每个工具拆成“短描述”和“长描述”。System Prompt 里只放短描述，完整参数细节通过 Function Calling 或动态加载补上。如果你用纯文本 Agent，也得把“触发场景”写在前面，参数细节尽量合并成一句话。

还有一个容易忽略的点：工具描述的顺序会影响选择。模型对列表前几项有天然偏好，所以把高频工具放在工具列表前部，低频工具放在后面。如果你发现某个工具几乎不会被选中，先别怀疑模型，检查一下它是不是被排到了“注意力洼地”。

约束规则：少而硬，放在最前和最后

约束规则的第一个问题是超载。你给模型 15 条禁令，它每条都记一点，每条都不牢靠。我自己的经验是：区分硬约束和软约束。硬约束要满足“如果不遵守，任务几乎一定会失败”，只保留 2-3 条，放在开头和结尾。软约束（比如语气、措辞）放在一个单独的“风格指南”段落，并且允许模型在必要时忽略它。

第二个问题是表达方式。常见写法是“不要编造数据”。这句话看似清楚，但对模型来说，“编造”和“数据”都容易触发联想，反而可能诱导它在不知道时去想象一个看起来合理的数据。更稳的写法是肯定句：

所有数字必须来自工具返回值。
如果工具没有返回对应字段，回答“未获取到”。

更麻烦的是约束之间的冲突。如果你既要求“每次回答前都检查工具结果”，又要求“尽量快”，模型就会在速度与准确性之间摇摆。这时候你需要显式声明优先级：当两条规则冲突时，哪条优先。没有优先级，模型会随机选一条。

位置决定命运：把关键信息放在 U 形曲线的两端

再看《Lost in the Middle》的结论：模型对长上下文的注意力呈 U 形曲线——开头和结尾记得最牢，中间部分的回忆准确率明显下降。这意味着 System Prompt 必须做三明治结构：

"We find that model performance is highest when relevant information is at the very beginning or end of the input context, and degrades significantly as the position of the relevant information moves toward the middle."

• 开头：角色定义 + 最重要的 2-3 条硬约束
• 中段：工具描述、场景示例、次要规则
• 结尾：输出格式要求 + 一条“最后检查”提示

有的工程师会在结尾重复一遍最关键的约束，这不浪费 token，因为结尾是第二次高注意力区间。比如开头写了“不要编造数据”，结尾再来一句“没有工具结果时，直接回答‘我不知道’”，往往比在中间唠叨十遍管用。

同时，用明确的标签把各区域隔开，也能帮模型快速定位。Anthropic 官方文档建议用 XML 标签包裹不同语义块，比如 <instructions>、<tools>、<examples>。这相当于在提示词里加了“路标”，模型不需要通读全文也能抓住重点。Anthropic 官方文档

塞不下怎么办？动态编排，让工具按需出场

很多人以为，把全部工具塞进 System Prompt 是理所当然。但随着工具数量从 5 个涨到 50 个，模型的选择准确率会断崖下跌，上下文也被吃光。与其硬塞，不如让工具“随叫随到”：

1. 把工具描述放在外部配置里，比如 JSON 文件或向量库。
2. 每一轮用户请求进来，先用一个轻量意图识别模块，挑出可能用到的 3-5 个工具。
3. 只把这些工具的完整描述插入到本轮系统消息中，其余工具“沉睡”。

这种做法的代价是增加一层路由逻辑，但换来 System Prompt 的轻量化。若你用的是 OpenAI 或 Anthropic 的 Function Calling 接口，工具描述本身放在独立字段，不占用 System Prompt 的自然语言空间，效果更好。在纯文本 Agent 中，则需要手动实现“动态系统提示”。

别忘了，System Prompt 只是上下文的一部分，对话历史和工具执行结果也会占据窗口。如果 Agent 需要多轮调用工具，每次工具返回都很长，会把关键指令挤出窗口。这时需要为工具结果做“摘要”，只把必要字段放回上下文。你可以设定规则：工具返回后，先把原始 JSON 压缩成一两句含关键状态的中文描述，再让模型继续推理。这个过程，本质上是上下文的一次“垃圾回收”。

几个常见问题

System Prompt 越长，模型越听话吗？

不是。长 Prompt 会稀释注意力，尤其是中间部分。核心规则保持在必要长度，多余的话反而干扰判断。

否定句提示（比如“不要编造”）有用吗？

有些场景有效，但容易引发模型过度关注被禁止的行为。更稳妥的写法是用肯定句描述期望行为，例如“只返回工具数据中的数字”。

上下文窗口已经 128K 了，还有必要做这些压缩吗？

有必要。Lost in the Middle 的核心问题是注意力分配，而不是容量。窗口越大，你在中间塞的无关信息越多，模型越难找到关键指令。

工具描述里的参数类型必须写进 System Prompt 吗？

如果工具调用是结构化 schema（如 Function Calling），参数类型放在 API 参数里即可，不必占用 System Prompt。若工具是自然语言调用的，至少写清必填项和格式。

回到我自己踩过的坑：最早我把工具描述放在 System Prompt 的正中间，测试时发现模型经常在“要不要调工具”上犹豫。后来我把工具描述移到角色定义之后，并在每个工具描述前加上“如果……那么……”的触发条件，错误调用明显变少。这个小改动让我意识到：System Prompt 工程不是写文案，而是信息架构——你必须假设模型只会“扫读”，然后用位置、结构、格式帮它抓住重点。

所以，System Prompt 工程的本质，是在跟 Transformer 的注意力机制打交道。你无法让模型一字一句读完你的 3000 字手册，但你可以通过“位置、结构、动态加载”让它在扫读时抓住关键信息。

它的能力边界也很清楚：System Prompt 的优化空间仅限于“让已有能力发挥出来”。如果模型本身不具备某个推理步骤，你很难靠 prompt 硬造出来。未来 Agent 的可靠性会更依赖工具本身可验证、决策逻辑外置到代码，而不是只靠提示词。但至少在今天，懂得如何把角色、工具、规则高效塞进上下文，仍然是每个 AI Engineer 的基本功。