企业官网建设流程全解析

如果你也正在做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覆盖要均匀，别只覆盖你喜欢的路径。我给出一套可直接复用的指标表格：

每次改提示，把这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条评测集、限制检索上下文、区分硬约束与软建议、加入状态回流块。两个月后，指标变化比较明显：

当然，指标提升不全是提示词的功劳，代码侧的工具选择逻辑、评测集的质量同样重要。但提示架构的改造是其中不可替代的一环。

8.2 改造后的最终结构与我总结的优化checklist

最终“某售后助手”的系统提示大致是这样：

[系统策略层] 你是售后客服Agent，必须遵守：不承诺未验证信息、不泄露隐私、不修改订单金额。 [任务定义层] 处理订单查询、发票、售后申请。先理解用户意图，再决定是否调用工具。 [工具能力层] 工具列表： - query_order（订单号、用户ID） - query_invoice（订单号、发票类型） - create_after_sale（订单号、问题描述） [动态上下文层] 用户输入：{user_input} 最近工具结果：{tool_output} 状态回流：{state_block}

改造并不复杂，但每一步都对应一个坑。我把这套思路整理成一张可直接使用的检查清单，你可以贴在自己项目的文档里：

• [ ] 系统提示里是否显式描述了“多步循环”，而不是一次生成？
• [ ] 静态规则、任务、工具、动态上下文是否分层？
• [ ] 有没有一套至少30~50条的评测集，并在每次改动后跑回归？
• [ ] 检索结果和历史对话是否被裁剪，控制在“够用”范围？
• [ ] 是否只把安全与合规设为硬约束，执行路径保留了模型自由度？
• [ ] 每一轮工具结果是否通过状态回流块，被标记为最高优先级事实？

我在一个个项目里踩过这些坑之后，最深的体会是：Agent提示优化没有“终极提示词”这回事。它是一套持续的结构调整、评测、裁剪、回流设计，而不是某一天的灵光一现。对照这份清单自查，你大概率能发现自己已经在某些错误上待了很久。中了几个其实不重要，重要的是从下一个迭代开始，不再重复它们。