先讲一件我最近在团队里撞见的真实场景。一位刚上手大模型的同事，想把客户给的会议纪要做成需求清单，他直接把原始记录粘进对话框，来了一句“帮我把重点整理一下”。模型确实给了三行漂亮的总结，可惜其中一条把讨论时被否掉的方案又当成了确定需求写进去。同事很委屈，问我是不是这个模型理解能力不行。我让他把那段会议纪要拿过来看了一眼，反问他：你有没有告诉它“重点”指的是什么维度？输出形式是清单还是段落？要不要区分已确认和待讨论？他一愣——原来这些信息也要说清楚才行。
这就是提示词工程最核心也最容易被忽略的第一课：大模型不是搜索引擎，不会猜你想要什么。它是个概率模型，你给的上下文边界越清晰，它输出的结果才越靠近你的意图。这篇是“AI Agent 学习之路”系列的第二篇，上一篇聊了 Agent 的整体构成，这一篇我们把注意力集中到“人机接口”这一层——提示词与提示工程。我会从原理讲到落地，再到具体的踩坑记录和评测迭代方法，希望能帮那些正在搭 Agent、或者想系统提升大模型使用效率的朋友，真正把“让模型听懂人话”这件事变成一门可操作、可验证的手艺。
1. 先搞懂：大模型凭什么“听你的话”
很多人把提示词工程当成“咒语大全”，觉得只要找到了某个神秘句式，模型就会突然变聪明。其实不是。不理解底层的运行逻辑，你写出来的提示词要么碰运气，要么不可复现。这一节先把这个根基打牢。
1.1 从概率续写说起：提示词的本质是“设定了生成方向”
严格来说，GPT 这类大模型是一个自回归语言模型，它的核心工作只有一个：根据当前已有的文字，预测下一个最可能出现的字或词（token）。你输入“床前明月”，它预测下一个大概率是“光”；你输入“中国的首都是”，它预测“北京”的概率最高；你输入“帮我写一首李白风格的诗”，它会沿着古体诗的用词习惯一路续写下去。
这意味着什么呢？意味着所谓的“听懂”，本质上是你的提示词改变了模型在每个生成位置上的概率分布。同样是让你“写一段话”，如果你的 prompt 里出现了“你是律师”，它输出的就是法言法语；出现了“你是产品经理”，它输出的就是 PRD 风格。模型的能力底座是固定的，但提示词决定了从它脑子里哪一个方向的“概率分布抽屉”里取内容。
我常跟团队打一个比方：你手底下有个读过几百万本书的实习生，他知识面很广，但你如果不说清楚“此时此刻的岗位是什么、手头任务是什么、客户验收标准是什么”，他只能按自己默认的一套模板交差。你指令越含糊，他“自由发挥”的空间就越大——这个自由发挥，在提示词工程里就是暴走和幻觉的来源。
1.2 注意力机制与上下文：提示词为什么能改变输出
大模型能够“看回”prompt 里的每一个位置，关键在 Transformer 架构的注意力机制。简单理解，模型在生成每一个新 token 的时候，都会重新计算一遍输入序列里各个词对当前生成的“重要程度”，然后加权融合这些信息。Prompt 里你写下的每个词都有可能被注意到，但被注意的强度差异很大。
这个机制解释了为什么提示词的结构会影响输出质量：同样一条关键信息，放在 prompt 的开头和结尾会比放在大段无关描述中间更容易被模型关注到。这也是为什么我后面给出的五要素框架里，要求把最重要的任务描述放在靠前的位置，而不是把背景故事堆在前面。
另外要记住上下文窗口这个概念。模型能同时“看到”的输入加输出 token 数是有限的，一次对话里你喂进去的提示词、历史消息、参考资料，加上最终输出，总量不能超过窗口上限。提示词写得太长，留给输出的空间就变小了，这会在系统层面限制回答的质量。
1.3 提示词工程不是魔法，而是“对齐工程”
把话说得再直接一点：提示词工程的目标不是“让模型变聪明”，而是“让模型现有能力的输出方向和你对齐”。
模型的能力在训练完成后基本固定。提示词能解决的是：任务表述不清、输出结构不对、风格不合适、稳定性不足。它解决不了的是：模型本身没有学过的知识、超出推理能力上限的复杂逻辑、以及彻底缺失的领域信息。如果你发现提示词怎么调都无效，大概率不是措辞问题，而是该换模型、上 RAG 检索，或者走微调路线了。这个边界感越早建立，你越不会在 prompt 上做无意义的死磕。
2. 提示词五要素：我搭 Agent 以来一直在用的设计框架
市面上关于“怎么写提示词”的文章很多，但我从自己做 Agent 项目的经验出发，习惯把一段完整可用的提示词拆成五个要素：角色、任务、上下文、输出格式、约束边界。这套框架不花哨，但每个要素都有明确的职责，组合起来就能形成稳定输出。下面逐个拆开讲。
2.1 要素一：角色设定——先给模型一个“立场”
角色设定的本质，是在激活某一类文本风格和决策倾向。同样一句“请分析这组用户数据”，告诉模型“你是数据分析师”和“你是销售总监”，得到的输出在侧重点上会有明显差异：前者会讲统计方法、显著性、置信区间；后者会讲客户分层、转化漏斗、销售话术。
写角色的时候我建议往“具体”方向靠，不要写“你是世界上最顶级的营销专家”这种浮夸设定。角色越泛，模型就越不知道该往哪个具体方向输出。更实用的写法是带上岗位、业务背景和任务目标，例如“你是一家 B 端 SaaS 公司的客户成功经理，负责老客户续费，关注客户健康度和使用黏性”。这种角色定位，比单纯一句“你是专家”有用得多。
顺带提一个观点：角色不是越多越好。一段 prompt 里塞“你是产品经理，也是技术专家，还是心理学大师”，模型反而容易被相互拉扯的角色属性干扰。一个清晰角色 > 三个模糊角色。
2.2 要素二：任务描述——把“做什么”写得像验收标准
这是五要素里分量最重的一个，但常常被人忽略。大多数人写任务只写了动作，比如“分析这份数据”“写一封邮件”，没有写目标、对象和成功标准。
我建议每次写任务时问自己三件事：
- 动作是否足够具体？“分析”不如“提取”“分类”“对比”这种可验收的动词。
- 对象是谁、范围是什么？对谁写邮件、对哪几条数据做处理，要讲清楚。
- 做到什么程度算好？比如覆盖几类情况、字数限制、必须包含哪些元素。
举一个我改过的真实案例。原任务是“写一封续费提醒邮件给老客户”。我改成：“写一封续费提醒邮件，发给使用免费版超过 6 个月、近 30 天活跃度下降的 SMB 客户，目标是让客户愿意点开‘升级方案’页面。邮件必须说明免费版的 3 个实际使用痛点，并对应给出 Pro 版功能亮点，总字数不超过 180 字。”模型看到这样的任务描述，输出立刻变得可用了。
2.3 要素三：上下文信息——补齐模型不知道的背景
模型不认识你的客户，不知道你产品的具体数据，更不知道上个月客户发了什么工单。这些信息必须在 prompt 里显式给到，否则模型只能凭借“一般经验”脑补，而脑补就是幻觉的来源。
上下文的关键词是“与任务相关”。越相关越好，但无关的信息塞多了反而会分散注意力。我在项目里见过有人把整个公司介绍文档贴进 prompt，就为了让模型写一封简单的回访邮件——结果模型被公司愿景带跑了，写出来的邮件像媒体通稿。
一个典型的上下文补充是这样的：“该客户公司约 30 人，使用我方项目管理工具免费版，最近 30 天活跃度下降 40%。历史无投诉，但上个月发过一次工单询问导出功能。”这些具体信息直接决定了模型能写出多贴合场景的内容。
当你要喂的上下文多到几十页文档那种量级，就不应该硬塞 prompt 了，那是检索增强（RAG）的职责，后面章节我会展开讲。
2.4 要素四：输出格式——用结构化要求拴住输出
自由文本和结构化输出之间的差距，做过 Agent 开发的人应该深有体会。模型默认喜欢输出长篇大论，如果你希望后续程序能直接消费结果，就必须把输出格式框死。
需要程序解析的场景，直接要求 JSON 或 Markdown，并且给出字段说明。需要人工阅读的场景，要求分段落、分标题，甚至给出“主题行 / 正文三段 / 署名”这种框架。不要在格式描述上吝啬字数，格式上的清晰是对后续处理最有效的减负。
我自己常用的句式是：“输出格式：主题行 | 正文三段，第一段描述痛点场景，第二段给出产品价值，第三段为行动号召，结尾署名。禁止输出除上述内容以外的任何文字。”这个“禁止多余输出”的尾巴，能有效避免模型在正式内容前后加一堆“以下是我为你准备的邮件”之类的废话。
2.5 要素五：约束边界——告诉模型“什么不能做”
模型默认会最大化满足用户的表面请求，哪怕没有依据也会硬编。这就是为什么约束边界必须有。典型约束包括：不得编造数据，不得用未提供的客户信息，不得夸大产品功能，语气控制在什么范围，涉及第三方时用什么替代词。
约束要具体、可执行，而不是情绪化的“不要瞎写”。比如“不得编造统计数字，如果统计数据未提供，请明说‘暂无数据’”就比“别乱编数字”好用得多。
另外，关于“不要做”类约束有个反直觉的坑——你越强调“不要提竞品”，模型反而越容易触发竞争对手相关的联想。这个问题我在第六章会专门用一个踩坑实录来讲，这里先留个印象。
2.6 一个完整示例：从零到一写出可落地的提示词
把上面五个要素组合起来，用“老客户续费提醒邮件”来做完整演示：
【角色】你是一家 B 端 SaaS 公司（产品名 ProTask）的资深客户成功经理，负责老客户续费与满意度维护。 【任务】写一封续费提醒邮件，发给使用免费版超过 6 个月、近 30 天活跃度下降的 SMB 客户。目标是让客户愿意点开“升级方案”页面。 【背景】该客户约 30 人，使用 ProTask 免费版，最近 30 天活跃度下降 40%。历史无投诉，但上个月发过工单询问数据导出功能。 【输出格式】输出内容依次为：邮件主题 | 正文三段（痛点场景 → 产品价值 → 行动号召） | 署名。正文总字数 180 字以内。 【约束】不得编造客户数据；不得夸大产品功能；语气温和，不促销化；结尾只保留一个行动按钮文案“查看升级方案”。这段 prompt 在实测里跑过很多次，输出的邮件事实上稳定在同一个框架内，措辞会有变化，但核心信息和结构不会跑偏。这就是五要素想要的效果——把内容锁住，把风格自由度交给模型。
3. 进阶技巧：六种我实测有效的提示词方法
五要素解决的是基础对齐问题，但很多任务光靠基础框架还不够。这几种技巧是我在项目里反复用过、确认有效的，它们各自解决一类特定问题。
3.1 Few-Shot 示例：给模型可模仿的“样板间”
零样本让模型输出某种固定格式，它偶尔会自创变体。解决办法是给几个“输入-输出”示例，让它照着写。示例相当于在 prompt 里塞进了几个活生生的样板间，模型在格式和思路上都会主动对齐。
举个分类任务的例子：
将下面的用户反馈分类为：技术问题、计费问题、功能建议、其他。 示例： 输入：你们上传文件总是失败，报 1001 错误。 输出：技术问题 输入：账单里多扣了两百块，能退吗？ 输出：计费问题 输入：希望支持深色模式。 输出：功能建议 现在分类： 输入：界面太卡了，半天加载不出来。 输出：这里有个经验：示例的质量比数量重要。一个模糊的示例会让模型学到错误的判断逻辑。示例最好覆盖边界情况，比如最容易混淆的“技术问题”和“功能建议”各给一个，模型的分界线就会清晰很多。
3.2 思维链与分步推理：让模型像人一样先把逻辑理顺
当任务包含多步推理时，直接问答案容易让模型跳步、出错。思维链的核心不是让模型“认真思考”，而是把推理过程拆成一步步可见的结构，减少跳步导致的错误。
写法上我会明确列出步骤：
请按以下步骤回答： 1. 提取问题中的关键信息 2. 列出影响该问题的所有因素 3. 逐一分析每个因素的影响 4. 综合所有因素，给出结论和可执行建议这个方法在逻辑题、排查类任务、计划制定里效果非常明显。但在特别简单的任务里不要滥用分步指令，本来一句话能答的事，硬拆五步反而让输出变得累赘，也会多消耗 token。
3.3 ReAct 模式：Agent 场景下的“思考-行动”循环
ReAct 是 Reasoning + Acting 的组合，是目前 Agent 类应用里最常用的提示词模式之一。它要求模型交替输出“思考”和“行动”，通过一步步推理来调用工具、观察结果、再推理，最终给出答案。
一个典型结构长这样：
思考：我需要查询北京的当前天气。 行动：调用工具 get_weather(city="北京") 观察：工具返回“晴，25 度” 思考：天气信息已获取，现在整理成用户友好的回答。 回答：北京当前晴，气温 25 度，适合户外活动。这种交替输出让模型的决策过程变得可追踪、可干预。如果某一步工具返回了异常，模型可以在下一步“观察”里发现并调整策略，而不是直接硬编一个答案。对于做 Agent 的朋友，这套模式是理解 Agent 循环的起点。
3.4 Self-Consistency 与多轮自检：用多次采样换稳定
同一个 prompt 让模型跑多次，结果可能不完全一样。在高价值任务里，可以用 Self-Consistency 来降低随机性：多次采样，然后取多数答案或质量最高的一个。
另一个变体是“草稿-审查-修订”三步法。先生成一个草稿，再要求模型以审查者身份指出草稿里的错误和遗漏，最后给出修订版。我在写代码、写方案这类内容时经常这样用，把模型的“输出者”和“审查者”两种角色分开，质量会扎实很多。代价是调用次数变多，成本上升，适合用在重要场景而不是每一条普通请求上。
3.5 负面描述的反效果：关于“不要做什么”的真相
心理学上有个“白熊效应”，你越告诉一个人别想白熊，他脑子里越全是白熊。模型也有类似的倾向，提示词里频繁出现“不要提竞品”“不要编造数据”“不要啰嗦”，这些词本身会激活相关的语义空间，反而让模型的注意力往不该去的地方飘。
我处理这类约束的方法，是把“不要 X”改写成“用 Y 替代 X”。比如“不要提竞品”改成“涉及其他产品时，统一使用‘其他产品’一词代替”；“不要啰嗦”改成“回答不超过三句话”。正向替代既限制了边界，又不会触发负面联想。
4. AI Agent 场景下的提示词工程：从“会聊天”到“会干活”
普通聊天里的提示词和 Agent 里的提示词，最大的区别在于：聊天时模型只需要做一次性反应，而 Agent 里的提示词是长期运行的“岗位说明书”，它要支撑模型自主决策、调用工具、多轮交互。这一节重点写 Agent 场景下提示词工程特有的几个关键点。
4.1 系统提示词：Agent 的岗位说明书
在 Agent 框架里，系统提示词（System Prompt）是每次请求都会加载的固定上下文，相当于这家“虚拟员工”的宪法。它通常需要覆盖：身份与目标、可用工具、决策规则、交互风格、兜底策略。
我拿一个“天气 + 日程助手”的 system prompt 示范一下，你感受一下每一句话的用意：
你是一个个人助理 Agent，可以执行以下任务： 1. 天气查询：使用工具 get_weather(city, date) 2. 日程查询：使用工具 get_calendar(date) 决策规则： - 当用户询问天气时，必须调用 get_weather；若城市名缺失，先向用户确认，不得猜测。 - 当用户询问日程时，必须调用 get_calendar。 - 如果工具调用失败，如实告知用户“暂时无法获取”，并提供替代建议，不要编造结果。 - 回答保持简洁，不超过 3 句话；需要列举时使用 Markdown 无序列表。 - 与任务无关的话题，礼貌拒绝并引导回任务。 当前日期：2025-06-14注意最后那行当前日期，看似不起眼，但很多 Agent 翻车就翻在这里——模型不知道今天的日期，就会把“明天”理解错，或者干脆默认成训练数据里某个日期。一个 Agent 的系统提示词里，至少要带上当前时间和用户的基本上下文。
另外，很多框架里提到的“Skill”，本质上就是一组可复用的提示词加工具流程的封装。理解了系统提示词，你就理解了 Skill 的底层——它只是把一段固定提示词和对应的工具调用步骤打包成了一个技能块，按需加载到系统提示词里。
4.2 工具调用：把函数的使用说明写进提示词
Agent 要操作真实世界，必须调用外部工具，比如查天气、查数据库、发消息。而模型怎么决定“什么时候该调哪个工具”，靠的就是你在提示词里给出的工具说明。工具描述写得模糊，模型就会乱调或者忘调。
一个工具描述通常包含名称、用途说明、参数结构，以 JSON Schema 的形式出现。比如：
{ "type": "function", "function": { "name": "get_weather", "description": "查询指定城市在指定日期的天气情况", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，如北京" }, "date": { "type": "string", "description": "日期，格式 YYYY-MM-DD，默认为今天" } }, "required": ["city"] } } }这里容易被忽略的是 description 的细节。比如我要求 city 参数必须写“北京”而不是“北京市”，就是为了防止模型把城市名弄得五花八门导致代码解析失败。另外，在系统提示词里我会写明“当工具返回值明确表示查不到时，如实告知用户并停止，不要反复重试”，避免 Agent 陷入傻循环。这部分经验往往是在真实调用里被逼出来的。
4.3 对话历史的提示词管理：上下文窗口的取舍
Agent 跑多轮之后，对话历史会越来越长，系统提示词加上历史消息、工具返回结果，很快就会占满上下文窗口。我见过不少 Agent 应用初期效果不错、一跑长对话就崩，根源就在这。
常用的方案有三类：
- 截断：只保留最近 N 轮对话。实现简单，但会丢掉早期确认过的重要信息。
- 摘要压缩：每隔几轮调用一次模型，把已有对话压缩成一份结构化摘要，再拼回上下文。适合需要长期记忆的场景，但会额外消耗一次调用。
- 关键信息抽取：把对话里的用户偏好、已确认事实、待办事项抽出来，维护成固定的“记忆区”，每次只把记忆区拼进系统提示词，而不是让原始对话全文堆积。
我自己在 LangGraph 这类框架里做 Agent 时，更倾向第三种方案：人为定义好状态结构，把真正重要的信息抽出来单独维护，让对话历史保持轻薄。这本质上就是上下文工程的一部分——提示词工程负责“怎么写”，上下文工程负责“喂什么”。两者配合，Agent 才谈得上稳定。
4.4 提示词与 RAG、微调的分工：什么时候靠工程，什么时候靠数据
接触大模型开发一段时间后，你会遇到一个困惑：问题到底该靠提示词解决，还是该上 RAG，或者直接微调？我的判断标准是这样的：
- 提示词工程：调整成本最低、见效最快，适合行为引导、格式控制、任务拆解。
- RAG / 上下文工程：当任务需要大量、新鲜、不断变化的外部知识时，把知识源外置比硬塞 prompt 可靠得多。知识规模越大，越应该走 RAG。
- 微调：当模型在某一领域的行为底色、固定风格、专业术语使用上就是不够好，而且你手里有足够多的标注数据时，才值得考虑。微调是成本最高、杠杆也最重的手段。
先说结论：三者是配合关系，不是替代关系。提示词是那个最便宜的杠杆，先用它解决问题永远是第一选择。但如果你发现提示词已经写得很长、很复杂、怎么调都效果平平，那大概率不是 prompt 的问题，而是知识供给或者模型底座的问题，这时候就得往 RAG 和微调方向找答案。
5. 实测对比：同一个任务，四种提示词的输出差距
理论讲了一堆，不如直接看对照组。我做一个小实验，任务很简单：把一段客户会议纪要整理成需求清单。分别用四种提示词跑同一份纪要，体验一下输出质量是怎么一步步抬上去的。
5.1 实验设定与测试用例
测试输入是一段典型的项目会议纪要，包含四条讨论结论，其中一条是“暂定但未最终确认”的需求，另外还有一句与主题无关的闲聊。这四条信息分布在三段文字里。
四组提示词设计如下：
- Prompt A：只粘贴原文，不加任何指令。
- Prompt B：原文 + “请总结重点”。
- Prompt C：原文 + 角色 + 任务 + 格式要求。
- Prompt D：原文 + 五要素完整版 + Few-Shot 示例 + JSON 输出要求。
5.2 模型输出直拍与分析
Prompt A 的输出，读写来挺流畅，但问题很明显：它把那段闲聊也当成了“重点”，并且把“暂定未确认”的需求直接写成了确定需求。原因很简单，我没有告诉它判断重点的标准，它只能按“信息量大的内容就是重点”来猜。
Prompt B 稍微好一点，结构从全文变成了分点，但依然是清单式罗列，没有区分已确认和待确认，也没有输出任何后续动作。模型知道要做“总结”，但不知道总结的颗粒度和维度。
Prompt C 的进步在于：角色定位让它更像产品经理的口吻，格式上也开始有“问题描述 - 建议方案”的雏形。但它仍然把那条未确认需求当成既定结论——因为没有约束条件告诉它“待确认项要单独标记”。
Prompt D 是我平时在 Agent 里用的那种写法，加入了“区分已确认与待确认”“把每条结论映射到负责人”“以 JSON 格式输出”等要求。输出直接变成干净的 JSON 数组，每条需求带 status 字段。模型不再把闲聊和临时讨论当成有效需求，因为提示词里已经明确写了“只提取有明确结论或行动项的内容”。
这个实验想说的是：提示词的层级差异，不是“好一点”和“差一点”，而是“能不能直接用于生产”。Prompt A 到 C 的输出，无论如何美化，后续都需要人眼逐条校对；Prompt D 的输出则可以直接被程序消费、导入项目管理工具。
5.3 迭代过程记录：我是怎么把提示词调稳的
实际开发中，Prompt D 也不是一次写成的。我第一次跑 D 版本时，模型输出的 JSON 里字段名偶尔会从 status 变成 state，导致下游解析失败。我一开始以为要写更长的格式说明，后来发现更有效的做法是给一个字段示例（Few-Shot），让模型照着这个字段结构走。
在前一小节的 JSON 示例中补了一个完整的输入输出对之后，我连续跑了 10 次，字段一致性达到 100%。这个“加示例解决格式不稳定”的做法，是提示词工程里最典型的迭代路径——发现问题、缩小变量、定向修改、批量验证。想让提示词稳定，靠的不是一次写完美，而是这套循环。
6. 踩坑实录：我在提示词工程里翻过的四个车
这一节全是我的真实翻车经历，写出来帮大家绕路。每个坑背后都有一个“当时觉得完全合理、后来发现完全错误”的瞬间。
6.1 提示词越长越好吗？我踩过的“冗余表述”坑
我最早做客服类 Agent 的时候，生怕模型漏掉规则，把公司流程、产品介绍、常见 QA 全塞进系统提示词，写了大几百字。测试时发现模型开始出现奇怪的重复表述，有时还把后文的规则提前输出。排了很久，最后定位到问题就是提示词太长，关键指令被大量背景信息稀释，注意力的权重被无关内容抢走了。
后面的调整思路是分层：把必选核心指令放在最前面，背景资料尽量精简，需要更多知识时走 RAG 而不是硬塞。提示词真的不是越长越好，它的本质是一份高密度的操作说明，信息密度比篇幅更重要。
6.2 “专家人设”不能掩盖任务描述模糊
我审过不少团队新人的 prompt，开头都是满满的“你是资深数据分析师”“你是 10 年经验的运营专家”，结果往下一看，“分析这份表”五个字就完了。模型确实会用“专家”的口吻说话，但因为没有定义分析维度、判断标准和输出形式，讲出来的全是正确而无用的废话。
专家人设负责风格，任务描述负责内容，两件事不能混为一谈。当我要求他们把任务部分改写成“请对比 A 和 B 两组数据在留存率上的差异，并给出可能的原因和实验建议，输出不超过一页 PPT 的结构”之后，同样一个人设，输出质量完全不一样了。
6.3 越强调“不要”，越容易触发——白熊效应的翻车现场
我在做另一个客服 Agent 时，在系统提示词里写了“回复中不要提及竞品名称”。结果测试中用户问“你们和 XX 相比怎么样”，模型竟然真的开始详细对比，还列了优缺点。这就是前面讲到的白熊效应，负面指令反而激活了相关语义。
改成“当用户询问与其他产品的对比时，统一回复‘其他产品的功能细节我们不便评论，建议您以官方信息为准’”，这个问题立刻消失。这条经验几乎适用于所有“不要做”类约束——如果你想禁止某件事，就给它一个明确的正向替代动作。
6.4 上下文污染：对话历史里的错误会被模型当成事实
多轮对话里有个隐蔽的坑：某轮模型失误说错了一个数字，用户纠正了一次，但后面几轮模型又引用回最初那个错误数字。原因是对话历史里的错误信息在后续轮次里被当成了“既定事实”，注意力机制会反复加重早期信息的影响。
我现在的处理方式是在系统提示词里加一条“后续回答必须基于用户最新确认的信息，忽略此前已被纠正的过时内容”，并且在历史管理时主动做冲突处理：一旦发现新旧信息矛盾，只保留最新一条。这个处理方法本质上属于上下文工程的范畴，但如果不和提示词配合，单靠历史截断很难彻底解决。
7. 让提示词持续变好：评测、版本管理与成本控制
提示词写出来只是开始，真正的工作量在持续迭代。如果没有一套评测和管理的机制，prompt 就会在无数次“微调”里悄悄退化。
7.1 先定义“好”：搭建一个二十条以内的评测集
我每做一个 Agent 项目，第一件事就是建一个评测集：20 到 30 条典型用户 query，覆盖正常场景、边界场景（比如缺关键信息、语气极端）和异常场景（比如完全无关的提问）。然后定义三到五个评价维度，比如正确性、相关性、格式符合度、稳定性和安全性。
不需要多复杂的评分系统，每个维度 0 到 5 打分，手动跑一遍也就半小时。每次改提示词，就把评测集完整跑一遍，把总分和之前对比。没有这个基准，你根本不知道一次修改到底是变好了还是变坏了——很多人调 prompt 调到最后变差，就是因为全凭感觉。
7.2 把提示词当代码一样管理
提示词是 Agent 的行为代码，迭代频率极高，如果你不给它做版本管理，迟早会迷失在无数的“最终版”“最终版2”“真正最终版”里。我的习惯是每个 prompt 一个 Markdown 文件，用 Git 管理，每次修改提交时写清楚变更原因和效果，大改动之前先留一个 baseline 副本。
比较新旧版本的时候，永远用同一组评测集来测，而不是拿一两条新对话凭感觉判断。这套方法一点也不高科技，但它能保证你的 Agent 行为是可控、可回溯的。
7.3 压缩提示词，本质是成本优化
最后算一笔账。大模型的成本与 token 消耗直接挂钩，系统提示词每多一个 token，每一次调用都会多花一份钱。假设你的 Agent 一个月被调用 100 万次，系统提示词从 2500 token 压到 1000 token，一次调用就省 1500 token，一个月就是 15 亿 token 的差距。哪怕按一颗很便宜的单价去算，也是肉眼可见的成本差别。
压缩提示词的常见手段包括：把不变的冗长背景挪到 RAG、把长对话历史改成摘要或结构化记忆、用 Few-Shot 代替冗长的格式说明。注意，压缩要以评测集不降分为前提，单纯为了省 token 把行为压坏了，是得不偿失的。先把行为做对，再考虑把 token 压下来，这个次序不能反。
我现在写 prompt 的习惯已经变成了：先写出一个“啰嗦但正确”的版本，跑评测集确认行为达标，然后逐步删减冗余，每删一次就用评测集验证一次。这套循环跑得越久，我对“哪些信息模型真的需要”的理解就越准确，写出来的 prompt 也就越来越短、越来越稳。
