生产级Agent提示工程:10个防翻车技巧

以虚构邮件助手Mailmind为例,拆解十个让生产级Agent行为确定化的提示工程技术。
文章以虚构的AI邮件助手Mailmind为运行示例,系统阐述生产级Agent提示工程的十个关键技术:角色定义设定默认姿态,编号任务分解替代开放式指令,JSON输出模式保证下游可解析,负面约束充当断路器,少样本示例澄清模糊边界,思维链用于复杂权衡,接地指令以“无引用,无声明”消除幻觉,置信度阈值将低确定决策路由人工,提示链将复杂任务拆为提取→分类→总结的独立步骤,动态提示构建则从情节记忆注入用户偏好与领域上下文。文章强调提示应被视为职位描述与培训手册,每个元素都在削减模型自由度,并给出漂移监测、LLM评审、提示注入防护与版本控制等运维实践。
生产级Agent的提示工程远不止写几句聪明的对话。一个缺失的约束就可能导致Agent未经批准发送邮件,即使其他代码完美无缺。本文以虚构的AI邮件助手Mailmind为例,拆解十个让Agent行为确定化的关键技术。

为什么模糊的提示会导致Agent失败?
“处理我的收件箱”这样的指令给了模型太多自由。Agent必须猜测“处理”的含义、该调用哪些工具、如何格式化输出。每次运行都可能产生不同的解读——今天把重要客户邮件标记为垃圾邮件,明天又起草回复。ReAct循环会放大这个问题:思考-行动-观察循环中每一个模糊步骤都会累积成不可预测的行为。
解决方案是把提示当作职位描述和培训手册。你添加的每个元素都在减少模型的自由度,直到只剩下预期行为。下面的十个技巧就是逐一移除这些自由度的方式。
ReAct循环(Reasoning and Acting)是一种让语言模型交替进行推理与工具调用的Agent架构模式:模型先输出一段“思考”(Thought),据此决定调用哪个工具并生成“行动”(Action),环境返回“观察”(Observation)后模型再进入下一轮思考。由于每一轮的输入都包含上一轮的输出,早期步骤中的模糊判断会被后续步骤继承并放大——例如分类时把客户邮件误判为“其他”,后续的归档和摘要就会一并出错。ReAct的价值在于让推理过程可追踪、可插入外部工具,但代价是错误具有累积性,因此生产环境中通常需要在每个循环节点加入格式校验与置信度检查,必要时中断循环并交由人工处理。
如何定义Agent角色以防止越权?
从角色定义开始,它设定了整个决策框架。Mailmind的系统提示开头是:
你是一个邮件分类助手。你精确且保守。当不确定时,标记给用户而非自行行动。
这句话告诉模型它是什么,以及默认姿态应该是什么。没有它,Agent可能会给每封邮件起草回复、从垃圾邮件中安排会议、或删除它认为不相关的消息。角色定义就像宪法:后续每条指令都通过这个透镜来解释。
资深工程师会将其识别为先验。你把模型的分布向谨慎、用户优先的行动方向偏移。提示的其余部分则把这个先验精炼成精确的策略。
为什么显式任务分解比开放式指令更可靠?
编号步骤每次都胜过“处理我的收件箱”。任务分解移除了模型自行拆解目标的需要。你定义序列:
- 读取邮件主题和发件人。
- 将邮件分类为五个类别之一:紧急、通讯、收据、会议请求、其他。
- 对紧急邮件起草回复但不发送。
- 对会议请求检查用户日历并提议三个可用时段。
- 对收据提取供应商、金额和日期,然后归档。
每个步骤都是Agent可通过工具调用执行的离散单元。分解也让调试变得简单:如果Agent在第3步失败,你确切知道去哪里找。一个说“管理我的邮件”的巨型提示给不了你这种可追溯性。
如何用输出格式规范强制一致性?
Agent产生机器可读的输出供下游系统消费。如果输出格式漂移,流水线就会断裂。你必须指定确切的JSON模式、字段名和类型。
对Mailmind的分类步骤,提示中包含:
输出一个JSON对象,字段为:
- "category": 字符串,取值为["urgent", "newsletter", "receipt", "meeting_request", "other"]之一
- "confidence": 0到1之间的浮点数
- "reasoning": 字符串,一句话解释
这个规范保证流水线下一个步骤能无错解析结果。它还迫使模型做出决定并量化不确定性。没有模式,Agent可能返回一段每次运行格式都变化的自由文本。
Mailmind对1000封邮件的分类置信度分布显示:高置信度(>0.8)占70%,可自动化处理;低置信度(<0.5)占5%,需人工审查。
JSON模式(结构化输出) 指通过提示约束或API参数(如OpenAI的response_format、各家的JSON Schema约束解码)强制模型输出符合预定义字段与类型的对象。相比在提示中“请求”JSON,约束解码在采样阶段就屏蔽了不合法的token,能从机制上杜绝字段缺失、类型错误和多余文本。实践中建议双层防护:提示中写明模式以便模型理解语义,接口层再用schema校验兜底,解析失败时触发重试或降级。此外应为枚举字段设置默认的“other/unknown”兜底值,避免模型在边界情况下强行归类,导致下游逻辑误判。
为什么负面约束与正面指令同等重要?
Agent绝不能做的事往往比它该做的事更关键。Mailmind的提示包含硬约束:
- 未经用户明确批准,绝不发送邮件。
- 绝不删除任何邮件。
- 如果搜索3次后仍找不到答案,说明情况并停止。
这些约束防止最严重的故障模式。起草回复但等待批准的Agent是安全的;未经询问就发送的Agent是负债。约束充当断路器,覆盖任何可能导致禁止行为的其他指令。
如何用少样本示例减少解释错误?
少样本示例向模型展示正确行为的样子。对于类别边界模糊的判断特别有效。Mailmind的提示包含一个微妙的例子:
输入:"Your weekly digest from The Hustle" 输出:{"category": "newsletter", "confidence": 0.95, "reasoning": "主题行明确说明是摘要。"}
输入:"URGENT: Server down in us-east-1" 输出:{"category": "urgent", "confidence": 0.98, "reasoning": "主题表明关键基础设施问题。"}
第一个例子教会Agent“digest”意味着通讯,即使没有出现“urgent”一词。第二个强化了主题中的“URGENT”是强信号。没有这些例子,模型可能把服务器警报归类为“其他”,或因一个首字母大写的词把通讯误标为紧急。
什么是Agent的思维链提示,何时有用?
思维链提示要求模型在行动前逐步推理。对Mailmind的紧急度检测,提示说:
在标记邮件为紧急之前,逐步推理:谁发的、他们要求什么、如果等24小时会发生什么?
这迫使模型考虑上下文而非依赖表面模式。CEO发来的主题为“Quick question”的邮件,如果正文问的是午餐计划,可能并不紧急。推理步骤揭示了这种细微差别。
思维链在决策需要权衡多个因素时最有价值。它增加延迟和token成本,所以只用在判断真正复杂的地方。对简单分类,少样本示例通常就够了。
思维链(Chain-of-Thought, CoT) 通过让模型显式输出中间推理步骤来提升复杂判断的准确率,其效果在需要多步算术、逻辑权衡或规则组合的任务上尤为明显。需要注意的是,CoT生成的推理文本并不保证忠实反映模型真实的决策依据,可能是在结论之后补写的合理化解释,因此不应把推理过程当作可靠的审计证据。工程上常见的做法是将推理与结论分离:推理写入单独字段供人工排查,结论字段则经过独立验证;对于可形式化验证的规则(如金额、日期约束),仍应使用代码校验而非依赖模型自述的推理。
如何用接地防止Agent输出中的幻觉?
总结邮件线程的Agent绝不能编造细节。接地指令把每个声明绑定回源文本。Mailmind的摘要提示包含:
只陈述邮件文本中存在的事实。引用支持每个声明的确切句子。无引用,无声明。
这条规则通过让编造无法不留证据来消除幻觉。如果模型找不到支持性引用,它必须省略该声明。输出变成一组可提取、可验证的陈述,而非自由形式的摘要。
当Agent的输出将展示给用户或用于触发行动时,接地尤其重要。一个幻觉的会议时间可能导致错过约会。
处理Agent行动中的不确定性的正确方式是什么?
Agent必须知道何时超出能力范围。Mailmind的提示定义了置信度阈值:
如果你对分类的置信度低于0.8,将邮件路由到不确定列表并标记给用户审查。
阈值是可调参数。较低阈值意味着更多邮件自动处理但风险更高;较高阈值意味着更多邮件交给用户,违背自动化目的。关键是Agent绝不在低置信度决策上行动。保守且不完整胜过自信且错误。
这个模式也给你一个清晰指标:路由到不确定列表的邮件比例告诉你提示的校准程度。实际调优中,阈值0.8时约15%邮件需人工审查,0.9时升至30%,0.7时降至5%。
为什么提示链优于单个巨型提示?
提示链把复杂任务拆成一系列聚焦的提示,每个只负责一件事。Mailmind的邮件处理流水线是:
- 提取事实:发件人、主题、正文、任何日期或金额。
- 使用提取的事实分类邮件。
- 为用户每日摘要总结邮件。
每个步骤是独立的LLM调用,有自己的提示、输出模式和错误处理。调试直接明了:如果摘要错误,你检查事实提取是否正确,再检查分类是否正确。一个什么都做的巨型提示是黑盒。
链式还允许你为每个步骤使用不同的模型或配置。事实提取可能用更小更快的模型,而摘要用更强的模型。对比来看,单个巨型提示难以定位失败步骤,任何改动后都需重新测试整个提示;链式提示则隔离故障、独立修改。
如何向Agent提示注入运行时上下文?
静态提示无法适应Agent学到的用户信息。Mailmind的情节记忆存储了“这个发件人的‘紧急’邮件从不紧急”之类的事实。运行时,提示构建器注入该上下文:
注意:发件人jane@example.com过去一个月发送了12封标记为“紧急”的邮件。没有一封需要立即行动。降低此发件人的紧急信号权重。
这种动态提示构建让Agent行为个性化而无需重新训练。上下文在LLM调用前注入,基础提示保持不变。你可以从任何记忆存储添加上下文:用户偏好、过往交互或领域特定规则。
情节记忆(Episodic Memory) 是Agent记忆体系中与“语义记忆”“程序记忆”并列的一类,存储的是带时间与情境标签的具体经历,例如“某次交互中用户拒绝了这类提议”“该发件人历史邮件多为低优先级”。与静态的知识库不同,情节记忆会随交互持续写入与衰减,使用时通常按相关性检索出若干条,再以自然语言摘要注入提示。设计要点包括:为每条记忆附加时间戳与置信度以便过期淘汰,限制注入条数以控制token成本,并对记忆内容做来源标记,避免模型把用户可控的文本误当作系统指令执行。
当领域变化而提示不变时会发生什么?
在公司邮件上调优的提示在用户连接大学邮箱时可能静默失败。邮件格式、规范和词汇都不同。代码没变,领域变了而提示没适应。
解决方案是检测领域并注入领域特定上下文块。对大学邮箱,Mailmind的提示构建器添加:
你现在处理大学邮箱账户。常见模式:课程公告、学生咨询、部门通讯。主题行中的“URGENT”很少表示真正紧急。
它还向情节记忆播种领域特定的少样本示例并调整置信度阈值。基础提示保持不变,只有注入的上下文变化。这种分离保持核心逻辑稳定,同时允许Agent在多个领域运行。
快速参考
| 技巧 | 作用 | Mailmind示例 |
|---|---|---|
| 角色定义 | 设置Agent默认姿态 | “你精确且保守;不确定时标记给用户。” |
| 任务分解 | 用编号步骤替代开放式目标 | 1.读主题 2.分类 3.起草回复(不发送) |
| 输出格式 | 强制机器可读JSON模式 | {"category": "urgent", "confidence": 0.95} |
| 负面约束 | 防止禁止行动 | “未经明确批准绝不发送邮件。” |
| 少样本示例 | 为模糊案例展示正确行为 | 通讯 vs. 紧急公告 |
| 思维链 | 行动前强制逐步推理 | “标记紧急前,推理:谁发的、要求什么...” |
| 接地 | 每个声明绑定源引用 | “无引用,无声明。” |
| 不确定性处理 | 低置信度决策路由审查 | 置信度低于0.8 → 标记给用户 |
| 提示链 | 复杂任务拆成聚焦子提示 | 提取事实 → 分类 → 总结 |
| 动态提示构建 | 从记忆注入运行时上下文 | “此发件人的‘紧急’邮件从不紧急,降权。” |
常见问题
如何测量提示随时间漂移? 每周在固定 curated 邮件集上运行Agent并比较输出分布。跟踪路由到不确定列表的比例、类别分布和平均置信度。任何指标突然偏移都信号提示漂移,即使代码没变。
可以用另一个LLM评估Agent输出吗? 可以。给第二个Agent同样的邮件和第一个Agent的输出,检查接地违规、缺失约束和模式合规性。这个验证Agent在生产流量样本上运行并标记异常。
如何处理Agent提示中的提示注入攻击? 绝不把不可信用户输入直接拼接到系统提示。如果必须包含邮件内容,用清晰分隔的块包裹并指示模型将其视为数据而非指令。始终运行输出验证步骤。
何时用思维链 vs 少样本示例? 映射清晰但微妙时用少样本;决策需要权衡多个因素或推理本身需可解释时用思维链。可以结合:展示包含推理步骤的少样本示例。
如何版本控制Agent提示? 将每个提示作为模板存储在版本化文件中,为动态上下文留占位符。用使用的提示版本标记发布。部署新提示时,在黄金测试集上运行并与前一版本比较输出分布,若发散超过阈值则回滚。
自测
你的Mailmind摘要器在5-10条消息的测试线程上完美工作,但在50+条消息的线程上产生幻觉。用户报告编造的会议时间和动作项。你会做什么提示工程更改?
答案: 长线程超出模型有效上下文窗口,模型用看似合理的虚假细节填补空白。首先,添加接地指令:“对摘要中每个声明,引用支持它的确切消息。如果没有消息支持,删除该声明。”其次,链接任务:逐条提取每封邮件的关键事实(必要时用滑动窗口),然后仅从这些提取的事实合成摘要。第三,添加自验证步骤:生成摘要后,让模型对照提取的事实检查每个声明并删除不支持的。对高风险摘要,运行第二个验证Agent独立执行相同检查。最后,设置最大线程长度,超过时回退到逐消息的提取式摘要。
本文基于Internals Decoded的AI系统设计系列,Mailmind为虚构运行示例。
相关推荐

Claude用梗造了个编程语言:Memesis让AI智能体安全"整活"
开发者借助 Claude Code 打造了 AI 智能体专用编程语言 Memesis,用网络梗作为关键字,内置 sus/yolo 安全机制,开源且可本地运行。

数字身份新变革:如何拥有并治理你的AI分身
数字身份正在转向AI分身时代。本文结合Reddit社区讨论,解析AI分身的拥有权归属、数据与模型控制、以及权限分级、行为审计、身份标识等治理机制,探讨普通人如何拥有并治理自己的AI分身。

Megatron-LM MoE训练手册:逐项配置实战指南
Hugging Face发布MoE训练手册,基于约80万GH200 GPU小时经验,逐项讲解Megatron-LM配置:从稠密基线到MoE层拆解、路由与负载均衡,附开源脚本和55张图表。