06 · 上下文工程

system prompt、动态注入与"少即是多"

📚 系列导航：这是《Agent 开发进阶》的第 6 篇（共 24 篇）。上一篇你把工具打磨成了模型看得懂的 API，这一篇解决另一半问题——上下文这块寸土寸金的地皮该怎么规划。下一篇：07 · 结构化输出与验证。

你大概也这么干过：agent 效果不理想，就往 system prompt 里再加一条规则；工具不会用，再贴一段说明；输出格式乱，再补三行示例。半年滚成三千字大杂烩，效果反而越来越飘。问题不在模型笨，在你把上下文当成了免费仓库。这一篇只干一件事：把"往里塞"的习惯改成"做预算"，给你一套四层结构和动态注入的判断法。

看完这一篇，你会拿到：

• 一套 system prompt 四层模板（身份/规则/工具指南/输出规范），可直接套用
• 一条动态注入三分法判据：什么进 system、什么进 message、什么等检索
• 一个长会话滚动压缩策略，防住 20 轮后成本 30 倍的坑
• 一次 3000 字大杂烩的重构演练，验收看成功率和 token 双指标

---

01 注意力稀释：塞得越多，每条越不被当回事

上下文是稀缺资源。50 条规则塞进 system prompt，模型只稳定遵守前 10 条——不是它叛逆，是注意力被稀释：每多塞一条，每条被认真对待的概率就掉一点。

打个比方，这就像开会宣布纪律：一口气念 50 条，散会没人记得第 23 条；把最要命的 3 条贴在门口，人人遵守。落地做法是分级：高频硬规则（红线、必守流程）常驻 system，控制在 10 条内；低频规则做成检索，用到再查。

💡 一句话总结：上下文按"注意力预算"管理——常驻的越少，每条被遵守得越稳。

02 四层结构：身份、规则、工具指南、输出规范

大杂烩的病根是没有结构。把 system prompt 固定成四层，每层只回答一个问题：

SYSTEM = "\n\n".join([
    "# 身份\n你是 X 公司的售后助手，只服务已购用户。",
    "# 规则\n1.不承诺具体退款金额 2.涉及安全问题立即转人工",
    "# 工具指南\n查订单先用订单工具；同一工具连败 2 次就停下求助",
    "# 输出规范\n对用户说人话，不超过 3 段；给程序的数据走 JSON",
])

预期效果：改任何一层不动其他层，排查时一眼定位问题出在哪层。层内有序，层间不混（工具技巧别写进身份里）。

💡 一句话总结：四层各答一问——是谁、什么不能做、工具怎么用、话怎么说。

03 动态注入三分法：每轮都要的才配常驻

不是所有信息都该进 system。判据一条：这条信息每轮都需要吗？ 每轮都要的（身份、红线）进 system；只有本轮任务相关的（当前工单、订单号）进 message，用完即走；低频大体积的（文档全文、几百条细则）等检索，需要时再查。就像收拾行李：天天穿的放手边，当天要用的进背包，换季的存仓库。我踩过反例：整段 API 文档贴进 system，每轮白烧几千 token。

💡 一句话总结：进 system、进 message、等检索——按"使用频率 × 体积"给信息分家。

04 上下文腐化：长会话要压缩，甚至重置

会话越长，上下文越"腐"：过时的中间结果、跑偏的尝试记录全堆在里面，既花钱又带偏模型。每轮带全量历史，20 轮后单轮成本能到首轮的 30 倍。策略两个：一是滚动压缩——每隔几轮把旧历史压成摘要，留结论丢过程，替换原文；二是重置——任务切换时开新会话，把上一段的结论作为新会话的输入，比拖着全部历史干净得多。

💡 一句话总结：历史保留结论、丢弃过程；能重置就别硬拖。

05 动手：把 3000 字大杂烩重构成四层

任务：找一份你项目里最臃肿的 system prompt（没有就找份超过 1500 字的），四步重构：① 逐句打标签：身份/规则/工具指南/输出规范/低频知识；② 低频知识全部抽出，做成检索或文档工具；③ 规则分级，常驻的砍到 10 条以内；④ 用同一批测试任务，新旧版本各跑 20 次。

验收标准：一张对比表——任务成功率、单次平均 token 消耗，两个数字至少一个明显改善、另一个不恶化。

两种结果都正常：双改善，说明砍对了，把四层模板固化下来；如果成功率反而降了，通常是把某条高频规则错当"低频"抽走了——去失败 case 里找被违反的那条，捞回 system 再测；能这样快速定位，正是分层的价值。

06 小结

你现在应该能：用四层结构重写 system prompt、用三分法决定每条信息的去处、给长会话配上压缩或重置策略。

上下文管住了，下一个问题是输出端：模型给的答案，程序敢直接吃吗？下一篇 07 · 结构化输出与验证，给输出上契约。

---

📎 实战案例

一个客服 agent 的 system prompt 塞了 50 条业务规则，模型只稳定遵守前 10 条。工程师重构成四层结构、常驻规则砍到 8 条、40 多条低频细则改走检索后，规则遵守率明显回升，单次调用 token 少了近一半。

踩坑

• 我把 API 文档整段贴进 system，每轮白烧几千 token——低频大体积内容走检索，别常驻。
• 我曾每轮带全量历史，20 轮后单轮成本是首轮的 30 倍——从此每 5 轮压缩一次旧历史。
• 我写过"要认真负责"式的空话规则，0 条生效——规则要具体到动作和条件：写完问自己"违反了能被程序检测出来吗"。