你的Agent又不听话了先别急着改提示词。这是很多团队的日常Agent效果不好第一反应就是把系统提示词拿出来改改。加一句你必须调用工具不行改成请务必使用工具还是不行再网上搜个万能提示词模板粘进去好像好了一点换几个输入又崩了。一轮折腾下来时间没少花效果全凭运气。我把这种现象叫提示词玄学。它的典型特征是改了有反应但不稳定验证靠肉眼不靠数据归因靠感觉不靠日志。说白了就是把Agent优化当成了提示词修辞大赛而不是一个可观测、可评测、可迭代的工程问题。这篇内容我想围绕一个问题展开Agent优化到底该怎么从玄学变回工程。会先聊为什么大家容易陷进提示词玄学再给一套我自己在项目里反复用、确认有效的分层优化方法最后盘几个常见的坑——包括最近网上很火的那些测试提示词提示词泄露话题它们背后暴露的东西可能和你想的不一样。1. 为什么Agent优化最后都变成了提示词玄学1.1 效果差的真凶问题根本不在提示词先泼一盆冷水Agent表现拉胯大概率不是提示词写得不好。我拆过不少跑偏的Agent项目最后定位到根因分布大概是这样的工具层问题工具数量太多、schema设计不合理、接口报错没人管约占三到四成上下文层问题系统提示词太长、检索结果杂乱、记忆没做好约占两到三成模型参数问题temperature乱设、模型本身不适合任务约占一两成真正的提示词表达问题可能只占两成左右。这个比例不是拍脑袋。你想想一个Agent完整链路是用户输入 → 意图理解 → 工具选择 → 参数提取 → 工具调用 → 结果解析 → 答案生成。这里面任何一环出问题表象都是Agent不听话但根因相差很远。举个例子。我之前遇到一个项目Agent老是调用错工具——用户问订单到哪了它去调了商品详情接口。所有人第一反应是改提示词请根据用户问题选择正确工具。改了两周时好时坏。后来查日志发现商品详情工具的描述里写了用于查询订单状态这句话——是文件里抄错了。工具描述错了提示词写得再花也没用。所以当Agent不听话时第一步不是改提示词而是先回答一个问题它到底在哪一步开始不听话的没有这个答案所有调整都是在猜。1.2 调prompt像赌博即时反馈带来的错觉那为什么大家还是忍不住先调提示词因为改提示词是整条链路上试错成本最低、即时反馈最强的操作。改一行字立刻跑一次看到输出变了大脑就分泌多巴胺——这个感觉太像赌博了容易上瘾。对比一下改工具Schema要走代码、要重新定义JSON结构、要改后端起服务改上下文管理要设计检索链路、写缓存逻辑这些改动周期长、反馈慢。而改提示词是纯文本操作几秒钟就有结果。问题在于有反馈不等于有进展。你改了一版提示词跑通了一个case很可能只是命中了模型的随机性。下一次同样的输入、同样的提示词输出又不一样。你以为自己在优化其实在做无意义的重复劳动。我自己的习惯是如果一次改动后在10个以上用例上都稳定生效我才认为这个改动是有效的如果只是单个case从失败变成功那多半是运气不算优化。1.3 什么时候才轮到提示词背锅当然我不是说提示词永远无辜。当排除了工具、上下文、参数这些因素之后提示词确实需要优化。具体来说提示词该背锅的场景有这么几类模型能理解但输出格式不稳定比如要求返回JSON偶尔多了一句讲解任务规则复杂且模型经常违反比如用户没确认价格就不能下单模型老抢跑同一个意图有不同的表达模型对其中一种表达理解不到位需要模型扮演特定角色或保持特定语气但风格不稳定。这些时候提示词优化是有意义的工作。请注意它们的共同特征是链路其他环节已经正常剩下的就是模型没按约定做事。约定写得不清楚、不具体、不一致优化它们就是提示词工程的本职。2. 把玄学变成工程优化前必须打好的四个地基说到优化方法论之前得先把地基打牢。很多人一上来就调提示词跳过了四个前提步骤最后越调越乱。这四个步骤是可观测性、评测集、失败分类、版本管理。2.1 可观测性没有日志的Agent优化是闭眼开车我接手任何一个Agent项目的第一件事不是看提示词是看日志。需要记录的关键信息至少包括每一轮用户输入、最终输出每次LLM调用的完整输入当时使用的prompt和输出每次工具调用的名称、参数、返回结果、耗时、状态码单轮对话的token消耗和总延迟链路中每个环节的标记比如意图识别通过工具调用完成。工具层面Langfuse、LangSmith、AgentOps这些都能用。如果不想引入重框架哪怕自己写个JSONL日志追加都行——重点是有日志而不是用了多贵的工具。有了日志很多玄学问题立刻现原形。比如之前说的工具调用错打开日志一看模型压根没调用你预期那个工具它调了另一个再比如Agent复读机问题日志显示工具返回结果为空模型只能自己瞎编。这些原因肉眼盯对话记录看不出来盯日志能看出来。提示我在项目里会额外给每个Agent调用注入一个request_id贯穿前后端。排查问题时输入request_id就能把整条链路拉出来比对着聊天记录猜高效得多。这是第一个地基先知道Agent到底做了什么再谈优化。2.2 最小评测集用30个用例锁死优化方向第二个地基是评测集。没有评测集的优化等于打靶不看靶子。不需要一上来就做几百条先做30条左右覆盖三类场景主流程场景15条、边界场景10条、典型badcase5条。每条用例要包含输入用户话术、期望行为期望调用哪个工具、期望返回什么、期望不做什么、通过标准可客观判断。比如输入期望行为通过标准查一下昨天的订单到哪了调用 order_tracking 工具query昨天的工具名正确、query参数正确帮我退掉这个订单不直接执行先询问订单号和原因输出包含确认或请问用户输入为空/乱码触发澄清话术不调用任何工具输出澄清语句有了评测集每次改动之后跑一遍通过率是升是降一目了然。通过率不降的改动才是有效改动通过率下降的哪怕感觉效果更好也要回滚。我见过一个团队一周改了十几版提示词每版都觉得这次好了结果跑评测集通过率一直在40%-50%之间波动——他们的好只是看见了几个成功case而产生的幸存者偏差。评测集就是为了打破这种偏差而存在的。2.3 失败分类学八成问题不在提示词层第三个地基是失败分类。评测集跑完你会得到一批失败case。接下来要做分类而不是直接去改提示词。我的习惯是把失败分成下面五类失败类型典型表现主要优化方向意图理解失败用户说A模型理解成B模型选型、few-shot、澄清机制工具选择错误该调A工具调了B工具工具描述、工具数量、路由策略参数提取错误调用正确参数是上海市上海市工具Schema、结构化输出约束执行/环境错误API报错、权限不足、超时工程修复别碰提示词答案生成错误工具返回正确输出时胡编提示词规则、输出校验、低temperature分类的意义在于告诉你该去动哪一层。我看到太多人把参数提取错误当成提示词问题去调调半天没用——那是工具Schema的字段约束没写好需要的是给参数加枚举、加正则描述、加示例而不是在系统提示词里写你提取参数时必须准确。每类问题都有对应解法。你在优化提示词之前先花半小时把失败case分好类你会发现真正需要动提示词的可能只有一只手的数量。2.4 提示词版本管理改过的每一版都要留档第四个地基可能最容易被忽略提示词版本管理。很多人改提示词是覆盖式的——今天在这份提示词上改一句明天又改一句改来改去最后忘了原始版本长什么样也不知道哪一版对哪个指标负责。这是典型的玄学操作。我建议两个习惯一是一发版一存档。每次修改后把当前版本的提示词全文、评测集通过率、修改意图记在一个文件夹或Git仓库里。文件名写清楚日期和改动目的比如20250401_系统提示词_v12_增加工具调用失败重试说明.md。二是一改一验。一次只改一个点改完跑评测集对比通过率。从v11到v12只改了一个句子通过率从62%涨到75%这个改动就是有效贡献如果一次改了五处通过率涨了你根本不知道是谁的功劳下次复制不了经验。版本管理本质上是在给优化建立因果记录。有了因果记录提示词优化才从感觉有用变成可验证有效。3. 分层优化实操从工作流到提示词哪层该动哪层不该动地基打好之后就可以开始真正的优化了。我的优化顺序是固定的先工作流与工具层再上下文与记忆层再模型参数层最后才轮到提示词。为什么是这个顺序因为越靠前的层级影响面越大、越稳定。提示词在最底层是因为它最容易改但它也最不稳定——同一个提示词换个说法可能就变了。前面的层级稳了提示词才能发挥应有作用。3.1 工作流与工具层让Agent先会做事工作流和工具层是一个Agent的骨架。这一步做不好后面全是白费。具体看几个高频优化点。第一控制工具选择面。理想情况下单个Agent能看到的工具数量建议控制在10个以内。工具越多模型的选择准确率下降得越厉害。实在有几十个工具别让一个Agent自己选——用分组、路由Agent或者检索式工具选择让Agent先定位到能处理这类问题的工具子集再从中选。第二把工具描述写成说明书而不是名词解释。工具描述是模型做选择时最重要的依据。写好的技巧是动词开头 使用场景 关键参数说明 一个例子。比如- 描述: 查询订单物流信息。当用户询问订单/快递/物流/到哪了时使用。 - 参数: - order_id: 订单号必填用户未提供时先询问。 - mobile: 手机号后四位选填用于身份校验。这段描述里包含了什么时候用参数要不要问用户模型照着这个就能减少很多误判。第三给工具调用加上重试和保护机制。工具调用失败时Agent要想清楚是重试还是换工具不能傻傻返回错误涉及删除、转账、发消息这类不可逆操作要在工作流里加一层人工确认。这些跟提示词没关系但对Agent听不听话的影响极大。第四善用状态机和子任务拆解。一个Agent做五件事不如拆成三个各司其职的子Agent由主Agent编排。功能边界清晰了提示词反而可以写得更短。3.2 上下文与记忆层让Agent记得住骨架搭好后看上下文。Agent的记忆力和注意力都由这一层决定但它常常被当成提示词不够长来对待——这是个大误区。系统提示词不是越长越好。我见过不少项目把系统提示词写成三千字的小作文恨不得把所有业务规则都塞进去。实测下来提示词超过一定长度之后模型对关键规则的遵循度是下降的——它记不住或者被大量无关信息稀释了注意力。真正该做的是按需投喂把不变的规则放进系统提示词控制在几百字内把动态的业务数据放到检索结果或工具返回值里让模型在需要的时候才看到。用户身份、权限信息在每轮对话里动态注入而不是写死在提示词里商品信息、库存数据通过检索或工具调用获取不要让模型背对话历史不是越长越好超过一定轮次要做摘要压缩不然模型会被旧信息带偏。我这里特别想提醒一句如果你发现Agent总是忘记某个规则先别急着在提示词里再强调一遍。看看这条规则是不是离用户当前意图太远或者被淹没在太多规则里。把规则移到合适的层级比如工具描述里、结构化校验里往往比再加一句记住有效得多。3.3 模型参数层让Agent稳定发挥上下文没问题之后看模型参数。这一层是很多人忽略的重灾区不少项目从头到尾用默认参数跑出了问题就怨提示词其实问题出在随机性上。最重要的参数是temperature。它的作用范围是所有输出token的概率分布——如果任务是稳定性优先的客服问答、数据提取、工具调用建议设置0或者0.1。我实测过很多时好时坏的玄学问题把temperature从1调到0.1之后直接消失。原因很简单Agent场景本来就不需要文采需要的是输出可复现。top_p一般不建议单独调如果一定要动和temperature二选一即可。此外还有两个常被忽视的参数模型本身和最大输出长度。有些任务Instructions能力弱的模型提示词写得再好也白搭——这时候该换模型而不是改提示词。最大输出长度太小会导致回答被截断看起来也像Agent傻了。一个真实案例某个Agent经常输出到一半就断了团队成员在提示词里加了请完整回答不要省略没用。最后排查发现是max_tokens设成了300而工具返回结果本身就远超300 token。参数问题被当成提示词问题折腾了一周。3.4 提示词层单变量A/B测试的科学调法到了这一层才开始真正动提示词。提示词的调法原则就是四个字单变量验证。一次只改一个点改完跑评测集通过率说话。不要甩锅也不要贪功。具体来说我常用的提示词优化动作有这几个第一把模糊愿望改成具体指令。比如请准确地调用工具是模糊愿望当用户问题涉及物流信息时必须调用tool_get_logistics参数order_id从用户消息中提取提取不到先询问是具体指令。输出格式也一样请返回JSON不如只返回一个JSON对象不要包含任何其他文字或解释。第二少用堆砌强调词。必须一定千万用多了等于没有强调。重点太多模型反而抓不住重心。我见过有人的提示词连续出现七八个必须实测效果并不比一个都不用强多少。第三给模型反例比给正例更省事。比如不要猜测订单号如果用户没有提供请直接询问用户请问您的订单号是这类负向约束在输出格式上尤其管用。第四不同角色的指令要分块写。系统提示词里你是一个客服助手工具列表输出格式禁止事项分块清晰比揉成一团要好维护得多。也更容易做版本对比。第五提示词里不要写事实要写规则。比如系统提示词里写我们的客服电话是400-123456就不合适哪天电话换了你还得改提示词换版本。正确做法是让Agent需要时通过工具查询。提示词应该是不变的变化的数据尽量走数据链路——这也是提示词能长期稳定发挥的前提。4. 常见误区与避坑那些被热词吹大的坑最后聊点行业里最近很热闹我实际观察下来纯属坑的东西。4.1 复杂提示词框架不一定是更优解网上流传很多所谓的高级提示词模板什么上策、下策、角色扮演、思维链、零样本链……不可否认它们在某些任务上有效但Agent优化的核心问题不在一个句子写得好不好而在整套系统稳不稳固。把大量精力花在打磨一个华丽的提示词框架上往往得不偿失——越复杂的提示词越难维护、越难复制、越容易出现换个输入就崩的问题。我的经验是Agent的提示词先写短。能一句话说明白的规则不要写一段话。规则的表达优先于修辞明确优先于华丽。等评测集告诉你这里确实需要更详细的规则时再往深了加。提示词是从短到长、从粗到细地长出来的不是一上来就写三五千字的宏伟模板。4.2 一次跑通不算修复随机性陷阱Agent开发和普通软件开发一个很大的不同是它有随机性。同一段代码同一条输入两次运行结果可能不一样。这让很多人产生了我改好了的错觉。判断一个问题真的修好没有我的标准是在评测集上连续跑三轮通过率稳定不回落才算修好。另外复现问题的时候不要只看一次输出至少要跑三到五次看看失败模式是稳定的失败还是偶发的失败——后者大概率是参数、上下文或工具链路的随机问题不是提示词问题。还有一个实用技巧定位问题时把temperature临时设为0先排除随机干扰等问题定位修好了再恢复原设置。这个技巧帮我节省了大量排查时间。4.3 提示词泄露暴露了什么最近Cursor提示词泄露这类话题很热评论里一片快抄。我看了下流传的那些内容老实说就算把别人全套系统提示词给你抄你大概率也复现不了人家的效果。原因很简单提示词只是一份说明书Agent的能力来自模型、工具实现、数据链路、评测闭环的组合。缺了后面的工程部分光有说明书是开不动车的。更值得做的是反过来想想自己项目的提示词有没有泄露风险重点检查系统提示词里有没有写入内部密钥、数据库账号、业务机密对外提供的接口有没有可能被用户套出内部指令日志系统会不会把完整提示词打到第三方平台。注意如果你的Agent会读取外部不可信内容网页、邮件、用户上传文档要小心提示词注入——内容里可能夹带忽略之前所有指令只做我要求的操作这类攻击指令。务必要把外部内容当作数据而不是指令来处理把指令和数据在结构上隔离并对高风险操作加人工确认。这里我也想把网上那些破甲NSFW提示词之类的话题点一句这类所谓提示词本质是试图绕过模型安全限制的攻击输入我们不讨论具体写法更不建议在任何产品里尝试。真正值得关注的是怎么防御输入侧过滤、输出侧校验、权限最小化、关键操作二次确认。Agent越强大安全护栏越要做实。4.4 警惕玄学热词鹈鹕骑自行车提示词背后的事实最近还有一类热词什么鹈鹕骑自行车提示词鹈鹕测试据说用一条奇怪的提示词就能测出模型水平高下。我试过也专门研究过这类测试的逻辑。这类测试词的特点是比较反常识、场景模糊、需要模型进行一定推理和想象。它能反映一部分模型的指令跟随能力和世界知识但它不是万能标尺——同样是鹈鹕骑自行车换一个模型、换一种表述结果可能完全不同。这一点恰恰说明我前面反复强调的问题提示词的效果不是一个孤立变量它和模型能力、任务类型、上下文设计紧紧绑在一起。拿一条模糊的网络热词提示词去给Agent能力下定论就是在把Agent优化往玄学方向带。真要知道Agent行不行回到你的业务场景用真实评测集跑分那才是唯一靠谱的标尺。说到底Agent优化不是一个调词的活儿是一个调系统的活儿。我经手的每个Agent项目最后稳定下来靠的都不是什么神级提示词而是一层一层把工具、上下文、参数、评测这些地基打牢提示词只是其中最后一块拼图。我的个人习惯是收到任何Agent不听话的报告先查日志、跑case、分类再动手每次改动只动一层改完跑评测集评测集通过率是我唯一的说服标准。这套方法不性感但管用。希望你看完这篇下次面对一个跑偏的Agent也能先按住改提示词的手从日志和评测开始。