先讲一件我最近在团队里撞见的真实场景。一位刚上手大模型的同事想把客户给的会议纪要做成需求清单他直接把原始记录粘进对话框来了一句“帮我把重点整理一下”。模型确实给了三行漂亮的总结可惜其中一条把讨论时被否掉的方案又当成了确定需求写进去。同事很委屈问我是不是这个模型理解能力不行。我让他把那段会议纪要拿过来看了一眼反问他你有没有告诉它“重点”指的是什么维度输出形式是清单还是段落要不要区分已确认和待讨论他一愣——原来这些信息也要说清楚才行。这就是提示词工程最核心也最容易被忽略的第一课大模型不是搜索引擎不会猜你想要什么。它是个概率模型你给的上下文边界越清晰它输出的结果才越靠近你的意图。这篇是“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 也就越来越短、越来越稳。