如果你也正在做Agent大概率经历过这种场景demo演示时提示词一跑工具调用行云流水回答几乎完美结果放到线上用户换了一种说法Agent就开始自说自话要么不调工具要么调完工具就把返回结果丢在一边。我最近以提示工程架构师的身份参与了好几个Agent项目的评审发现Agentic AI提示优化领域正在出现一批非常相似的坑。大家不是不努力而是努力的方向还停留在“把提示词写得更好看”这个旧思维里。很多团队拿着一条几百字的prompt反复改版改到第N版几个case变好了另外几个case悄悄变坏却谁也说不清坏在哪个环节。这篇文章把评审中最高频出现的6个常见错误一次讲透每个都会说清症状、背后的原因、以及架构师视角下的改造方案。适合正在做Agent开发、RAG应用、智能客服、自动化工作流的朋友。读的时候可以顺便自查看看自己中了几个。1. 先弄清一件事Agent的提示优化是在优化一个“流程”而不是一句“话”在展开这6个错误之前我想先纠正一个前提。很多人把“Agent提示优化”和“Prompt Engineering”划等号这其实是误解也是后面所有问题的起点。1.1 单轮Prompt与Agentic提示的本质差异单轮Prompt的核心是“一次性生成”你给模型一段指令和输入它返回一段输出完了。这种场景下你优化的对象是措辞、示例、格式约束目标非常直接。就像你在菜谱上写下“红烧肉怎么做”厨师照着做一盘端上来就结束了。Agentic AI不是这样。Agent的提示控制的是一个“循环”模型要先判断需不需要调用工具调用完之后要结合工具返回的结果决定下一步动作可能还要再调工具再判断直到生成最终回复。这个循环里模型更像一个决策器而提示是它的“操作系统启动配置”。你和它交互的不是一句命令而是一套贯穿多个回合的协议。打个更容易理解的比方单轮Prompt是给一个员工作单Agent提示是给整个后厨团队写“出餐流程”。出餐流程里除了菜谱还有检查点、应急方案、备料顺序、出货标准。你优化红烧肉配方和优化整条出餐流程怎么可能用同一种方法1.2 架构师眼中的Agent提示静态配置动态运行时我习惯把Agent提示拆成两块。一块是“静态配置层”包括人设、安全边界、工具说明、输出格式、任务目标这些内容相对稳定可以预先写好甚至做缓存。另一块是“动态运行时”包括用户当前输入、工具调用结果、前文摘要、当前状态这些内容每一轮都在变化需要系统在运行时拼装。大部分优化误区的根源要么是有人只优化静态配置那一块对动态运行时完全不敏感要么反过来把动态信息打散到静态配置里导致模型分不清哪些是恒定规则、哪些是临时事实。下面的6个错误几乎都能归结到这两种失配。想通了这条主线后面每个错误你都会觉得眼熟。2. 常见错误一把Agent当单轮文本生成器2.1 症状一次生成、拿来即用这个错误出现的频率高得惊人几乎每次新接手Agent项目都能看到。表面上你写了一个很像Agent的提示实际上整个流程里只调用了一次模型。很多团队把模型调用封装在后台函数里看起来也有接口、也返回答案但仔细看主流程会发现用户消息进来拼好system prompt一次LLM调用把结果直接返回给用户结束。这个流程里没有任何“第二轮思考”的空间。这种“单轮Agent”线上表现非常典型用户问一次性问题还行只要涉及追问、改口、需要查数据的场景立刻崩。比如用户说“帮我查一下上个月的发票”模型能答用户紧接着追问“那补开发票呢”模型就不知道怎么把“补开”这个动作和查发票工具关联起来因为它根本没被设计成“继续思考”的模式。我在一次评审中遇到更极端的案例某团队的Agent系统提示里写着“如果你需要更多信息请调用query工具”但代码里压根没给模型输出工具调用的机会模型生成的调用请求被当成普通文本丢给了前端展示。用户看到一串类似命令的字符体验直接归零。这就是典型地“优化了提示但没优化流程”提示写得再漂亮也白费。2.2 正确设计多步循环和工具调用的显式表达Agent提示优化的第一个动作就是让“循环”在提示里显式存在。你需要告诉模型先看用户需求判断需不需要工具如果需要把工具调用意图表达出来拿到结果后不要急着结束先检查结果是否满足需求。我经常给出这样一段结构作为改造起点你是[角色]。 请严格按下面循环工作 1. 分析用户最新需求判断是否需要调用工具获取信息。 2. 如果需要输出工具调用指令工具参数从用户输入中提取。 3. 系统执行工具后你会收到工具的返回结果。 4. 结合工具返回结果再次检查是否覆盖用户全部需求。 5. 如果覆盖生成最终回复并结束 如果未覆盖说明还缺什么继续执行第2步。 6. 工具调用失败时最多使用替代参数重试一次再次失败则如实告知用户不编造结果。这一步看似简单但已经很关键。它不再把Agent当成“生成器”而是当成“决策器”。你优化的也不再是某一句回答的质量而是模型在整个工作流里每一步做选择的质量。后面几个错误也都是在这个循环基础上继续叠加的。这里还要提醒一句循环写进提示不代表代码就能循环。你需要确认工程侧真的把模型输出解析为“工具调用”或“最终回答”两种分支并且把每次工具执行后的结果重新喂回模型。提示只负责教模型“应该怎么做”代码负责给它“执行的条件”。3. 常见错误二系统提示词“大锅烩”静态和动态混在一个长文本里3.1 症状提示越来越长效果越来越飘把系统提示当成容器不停追加内容这个习惯也不是一天形成的。业务方今天要求加一条规则明天换一个工具后天觉得某个案例很典型也想贴进来当示例于是文档越写越长系统提示跟着越堆越臃肿。我评审时见过一条超过3000个token的提示里面甚至包含了一整个客服话术手册。看起来信息很全实际效果通常越来越差。原因有两个。第一模型对指令的遵循率会随指令所在位置变化夹在一长串中间位置的指令最容易被忽略。这和人类阅读逻辑很像你在一张写满字的说明书里寻找到底哪句是“关键注意点”找半天找不到最后很可能漏掉它。第二动态内容一旦混进固定规则区模型会把临时检索到的信息误当成长期规则。我见过一个在线教育Agent因为把某位用户的“会员到期时间”拼在了业务规则后面模型竟然错误地把它当成所有用户的统一到期时间几乎每个用户都收到了错误的到期提醒。这种事故很难排查因为你看到的是模型“不听话”实际原因是提示结构里信息污染。3.2 分层改造模块化系统提示的落地方式架构师最喜欢的系统提示一定是分层的。我建议至少拆成四个区域用清晰的标记隔开[系统策略层] 固定内容不建议修改 你是企业客服Agent。始终遵守安全规则不承诺未验证的信息不泄露他人隐私不修改订单金额。 [任务定义层] 低频变化 你的任务是处理订单查询、发票补开、售后申请。回复前先确认用户意图。 [工具能力层] 低频变化 可用工具及参数 - query_order查询订单状态参数为订单号、用户ID - query_invoice查询发票参数为订单号、发票类型 - create_after_sale创建售后单参数为订单号、问题描述 [动态上下文层] 每轮刷新 用户输入{user_input} 最近工具结果{tool_output} 前文摘要{dialogue_summary}这样的好处很明显静态层稳定、复用度高可以在工程上做缓存动态层只放“这一次决策真正需要的信息”并且放在提示靠后的位置更容易被模型在生成时参考。想调整业务规则时也只改任务定义层或策略层那一小段不用动整篇文本。以后做回归测试也更容易定位是哪部分变化导致改坏。这里提醒一句分层不是让你把每个字段都搞得很复杂。如果你的Agent只有两三个工具、目标单一两层就够。分层是手段目的是让模型分得清“哪些是约束哪些是事实”。别为了架构好看而堆砌结构。4. 常见错误三改提示全靠手感没有评测集4.1 症状样例只能覆盖“我能想到的情况”这是我见过主观性最强的一个环节。大部分团队优化Agent提示的方法是打开几个测试case手动跑一下觉得输出“看起来不错”然后上线。问题是“看起来不错”这个标准因人而异。同样一个回答业务方觉得可以技术方觉得缺数据用户觉得废话太多。更麻烦的是提示改动往往是牵一发动全身。你在第7个case上强行加了约束可能把第23个case的逻辑改坏。由于没有一套固定的评测case集合你甚至不知道它坏了。等用户投诉出现的时候你已经找不到是哪一次改动导致的。我在某项目里见过一个很具体的回归事故团队为了让Agent在“查不到库存”时更果断地给出替代建议在提示里加了一句“如果库存不足直接推荐相似商品”。上线后“查库存”类case确实变好了但“开发票”类case却开始凭空推荐商品因为模型把“库存不足”误理解成“任何未找到结果的情况”。这就是没有评测集、没有回归的典型后果。4.2 搭一个轻量评测集让每次改动有据可依不要一听到“评测集”就觉得要搞复杂的大平台。小团队30~50条case就能起步。关键是case覆盖要均匀别只覆盖你喜欢的路径。我给出一套可直接复用的指标表格评测维度权重建议样例说明意图识别准确率30%用户说“查发票”是否被误判为“开票”工具选择正确率30%该调用query_order却调成了create_order最终回答合规率20%是否严格遵守输出格式与安全规则端到端任务完成率10%多轮对话后用户问题是否真正解决幻觉/编造率10%是否引用工具结果之外的不实数据每次改提示把这50条case重新跑一遍对比分数。定的标准可以简单一些新优化必须提升某一类case至少10%同时不能导致其他任何一类case下降超过5%。有这套机制在你才不会在改提示时“拆东墙补西墙”。我还建议把评测集本身纳入版本管理。提示词改版时同步记录是哪一天改的、基于哪个评测集得出的结论。不然三个月后回看你拿着一版高分提示却完全不知道当初为什么这样设计后面的人也不敢动它。5. 常见错误四上下文塞得越满越好导致噪声压过信号5.1 症状信息密度过低模型反而“看不到”关键指令很多团队在优化Agent时有一个执念既然有上下文窗口那就把信息全塞进去。比如把RAG检索到的十几段内容全文粘贴、把历史对话原样保留。这种做法表面上是“让模型掌握足够多信息”实际上是在降低上下文的信息密度模型反而抓不住重点。我审过一个售后Agent它的上下文中塞了5000多个token的检索结果其中真正对当前问题有用的可能只有200个token。模型为了在一堆无关信息里找答案经常抓错重点。用户问“我的订单什么时候到”它却引用了另一份同类产品的介绍段落答非所问用户一看就懵了。这个问题的另一个隐性成本是延迟和费用。每多塞一个token模型处理时就要多算一次。你把5000个token的噪声喂进去实际是在为模型增加大量无效计算。Agent每轮调用工具都要重新处理一遍上下文浪费更明显。5.2 控制上下文有用信息筛选与压缩策略在Agent场景里上下文不是仓库而是“工作台”。工作台上只放当前决策要用的工具和材料其余放回抽屉。具体可以这么做。第一检索返回要设上限。不要一股脑把top-20都放进去可以先返回top-5让模型判断够不够不够再触发新一轮检索。第二历史对话要做摘要而不是原样拼接。保留最近两轮原文更早的对话压缩成要点比如“用户之前已确认退款金额为100元”。第三在动态上下文里单独划出“最新工具结果”区块并标注为最高优先级事实让模型明确知道回答要基于这里而不是某处旧文。我还会用一个朴素公式提醒团队每一轮决策前看一眼“有用token/总token”的占比。如果低于20%大概率是上下文塞得太多了。你优化提示时有一半的功夫应该花在“剪掉什么”上而不是“继续加什么”。多数Agent效果差不是因为信息不够而是因为信息太多导致信号被淹没了。6. 常见错误五提示写成“规章制度”把Agent的自由度锁死了6.1 症状规则越细Agent越机械与“没规则”相反的极端是把提示写成了规章制度。为了给Agent设定最佳路径一些人会写下非常详尽的步骤“必须先调用A工具如果返回空再调用B工具最后调用C工具否则判定失败。”这种提示在小范围测试时会很稳因为它把一切分支都预设好了。但Agent面对的是开放世界不可能所有输入都落在你预设的分支里。一旦用户表达方式超出预期规则越细模型越容易卡死。要么它为了遵守顺序而执行毫无意义的工具调用要么它找不到匹配分支直接崩溃。我在一个自动化审批Agent里见过规则写明“必须先查合同再查发票”但当用户只问“发票什么时候开”时Agent先浪费一轮去查合同查完再查发票效率极低还不敢在应该简化的时候简化。过度约束表面上是提升稳定性实际是在磨灭Agent最该有的灵活性。6.2 正确边界硬约束和软建议分开把Agent提示当作边界管理会比当作流程手册更有效。所谓边界就是告诉模型什么绝对不能做、什么必须遵守至于路径只给参考建议不硬性规定。看这两个示例的差别错误示例规章制度式 处理退款时你必须按以下顺序执行 1. 先调用query_order 2. 再调用check_policy 3. 最后调用refund。 如果不按此顺序直接报错。建议示例边界建议式 处理退款时需要先确认订单信息和退款政策。 可依次使用query_order、check_policy完成确认确认符合条件后再调用refund。 若某个工具不可用不要编造结果主动向用户说明暂时无法处理。两者一样都在规范流程但后者没有剥夺模型的判断空间。模型可以在“确认信息”这一目标下自行决定先查哪个、缺什么、还要不要继续。Agent核心价值是规划能力如果路径都被写死它和普通的if-else脚本有什么本质区别我还遇到过一种更隐蔽的过度约束在系统提示里写“永远不要改变你的想法”。这种绝对化的词在部分场景能防止模型反复横跳但在需要根据工具反馈修正结论时就成了灾难。建议把“永远”“必须”“绝不”这类词只留给真正的安全红线其它位置尽量用“尽量”“优先”“建议”这类表达。7. 常见错误六只优化首轮输出不考虑工具结果的回流闭环7.1 症状工具调用完Agent就开始“失忆”这个错误在“多工具长流程”的Agent里尤其严重。流程大概是模型输出了工具调用指令代码执行工具拿到了结果然后把结果拼到对话里继续让模型生成下一轮。看起来好像没问题但拼装的时候没有把工具结果强调成当前最重要的“新事实”。于是模型经常出现两种离谱行为。第一种它明明拿到了工具返回结果却还在基于自己之前学到的旧知识回答导致答案和查询结果互相矛盾。第二种它没意识到这个工具结果已经覆盖了用户需求继续去调用同一个工具造成不必要的重复请求。我遇到过一个数据查询Agent用户问“帮我统计今天的销售额”模型调用了query_sales工具工具返回了准确数字但模型在最终回答里却使用了自己训练知识里的估算值把“今天销售额”说成另一个数。后来排查才发现提示里只写了“根据工具结果回复”却没有在结构和逻辑上把工具结果放到最高优先级模型根本不知道要强制相信哪个信息源。7.2 回流机制让工具结果成为每个回合的最新事实正确的做法是给每一轮对话设计一个显式的“状态回流块”把工具结果放进去并明确告诉模型它是最新事实。我用得比较顺手的模板是这样的[当前状态块] 当前回合{turn_number} 用户最新输入{user_input} 最近一次调用工具{last_tool} 工具返回结果最高优先级事实{tool_output} 尚未满足的用户需求{unfinished_request} 下一步动作 - 如果工具返回结果已满足需求生成最终回复。 - 如果未满足继续调用相关工具。 - 如果工具调用失败使用替代参数重试一次仍失败则如实告知。除了回流块还要设计“回流数据的压缩”。如果工具返回的内容特别长比如一页订单明细不要全量塞回去而是抽取成结构化摘要包括“订单状态、预计到货时间、是否满足用户要求”这几个要点。这样既保留了关键信息又不会稀释模型对“最新事实”的注意力。最后提醒一个工程细节回流块里的内容必须在每一轮真正更新。如果实现里只是静态拼了第一次的工具输出后面所有轮次都用同一份旧结果那提示写得再清楚也没用。提示设计要和代码状态管理配合着做这不是纯文本问题。8. 实例复盘一个客服Agent提示优化的前后对比8.1 改造前的提示结构和线上问题为了让你能直接参考我说一个虚拟但很典型的改造例子。某团队做了一个售后客服Agent项目代号就叫“某售后助手”。改造前它的提示结构是一大段固定系统提示里面塞了订单规则、工具描述、几个问答示例。代码流程是用户消息进来拼上系统提示一次调用模型返回答案。线上问题非常集中用户用不同说法表达同一个诉求时Agent经常听不出来需要多步查询时Agent容易“一步到位”编结果工具调用后模型仍然基于训练记忆作答导致结果冲突系统提示改了三次之后旧问题悄悄回来无人察觉。这些正好是前面6个错误的缩影。改造时我们没有搞什么“高级魔法”只按架构师的流程走了一遍去掉单轮思维、分层系统提示、建50条评测集、限制检索上下文、区分硬约束与软建议、加入状态回流块。两个月后指标变化比较明显指标改造前改造后工具调用正确率62%91%端到端任务完成率48%84%平均每轮处理token数约4200约2300错误引用旧知识的比例30%6%当然指标提升不全是提示词的功劳代码侧的工具选择逻辑、评测集的质量同样重要。但提示架构的改造是其中不可替代的一环。8.2 改造后的最终结构与我总结的优化checklist最终“某售后助手”的系统提示大致是这样[系统策略层] 你是售后客服Agent必须遵守不承诺未验证信息、不泄露隐私、不修改订单金额。 [任务定义层] 处理订单查询、发票、售后申请。先理解用户意图再决定是否调用工具。 [工具能力层] 工具列表 - query_order订单号、用户ID - query_invoice订单号、发票类型 - create_after_sale订单号、问题描述 [动态上下文层] 用户输入{user_input} 最近工具结果{tool_output} 状态回流{state_block}改造并不复杂但每一步都对应一个坑。我把这套思路整理成一张可直接使用的检查清单你可以贴在自己项目的文档里[ ] 系统提示里是否显式描述了“多步循环”而不是一次生成[ ] 静态规则、任务、工具、动态上下文是否分层[ ] 有没有一套至少30~50条的评测集并在每次改动后跑回归[ ] 检索结果和历史对话是否被裁剪控制在“够用”范围[ ] 是否只把安全与合规设为硬约束执行路径保留了模型自由度[ ] 每一轮工具结果是否通过状态回流块被标记为最高优先级事实我在一个个项目里踩过这些坑之后最深的体会是Agent提示优化没有“终极提示词”这回事。它是一套持续的结构调整、评测、裁剪、回流设计而不是某一天的灵光一现。对照这份清单自查你大概率能发现自己已经在某些错误上待了很久。中了几个其实不重要重要的是从下一个迭代开始不再重复它们。