1. 先说句得罪人的话你的Agent优化可能根本不是优化最近总有人跑来问我我的Agent不听话我改了二十几版提示词从“你要做一个资深助手”改成“你是拥有十年经验的资深专家”再加一堆“请务必、一定要、注意细节”效果还是飘忽不定。每次我听到这种问题第一反应不是看他的提示词写得好不好而是想问他你凭什么觉得问题出在提示词上这个行业现在有个很怪的风气——什么东西火了什么东西就被拿来背锅。AI火了提示词就被封神了。网上铺天盖地的“提示词工程”“XXX提示词大全”“鹈鹕测试提示词原版”满天飞。所谓“鹈鹕测试”就是拿那种“一只鹈鹕骑着自行车穿过沙漠嘴里叼着冰淇淋”的离谱要求去测模型这玩意儿确实能反映模型的指令跟随能力但你别忘了那是单轮对话的测试不是Agent系统测试。拿单轮对话的评判标准去优化一个需要多轮交互、工具调用、状态管理的Agent这不叫优化这叫刻舟求剑。我必须先把话说清楚提示词确实重要它像方向盘决定Agent往哪儿走。但方向盘不等于整车。一辆车跑偏可能是轮胎歪了可能是悬挂坏了甚至可能是路况问题。你猛打方向盘轻则白费力气重则车辆失控。Agent优化真正要解决的问题是把整套系统调好——工具调用、上下文管理、状态流转、回退机制、评估反馈提示词只是其中最容易被看见但也最容易被高估的一个部件。我平时在社区里看到太多这样的案例一个人花了两周时间调提示词最后效果不如另一个花半天重新设计工具接口的人。这不是玄学是有原因的。我自己踩过这个坑也带团队跳过这个坑。这篇文章我把这几年做Agent项目攒下来的真实经验拆开揉碎讲给你听你就明白为什么我说“别把Agent优化写成提示词玄学”。2. 为什么提示词在Agent体系里权重比你想象的低得多2.1 提示词的类型决定了它的能力上限先做个小实验。你打开任何一个大模型的对话框给它打一段话它能回复得很好。这让你觉得提示词无所不能。但Agent不是对话框Agent是一个在跑的流程它要做的是理解任务、拆解步骤、调用工具、拿到结果、判断结果、再决策下一步、直到任务完成。提示词在Agent里的角色分三种系统提示词SysPrompt决定Agent的基调和边界任务提示词TaskPrompt描述当前这一步要干什么以及嵌入在工具定义里的说明性文本告诉模型某个函数是干嘛的、参数怎么填。这三者叠加在一起在整套Agent逻辑里占的比重说实话不超过三成。剩下七成是代码逻辑、工具可用性、数据流设计、状态管理和错误恢复机制。我见过最荒谬的一个项目Agent调一个天气API失败率高达40%团队不查API返回格式也不做重试硬是在提示词里写“如果天气接口失败请换一种方式尝试”结果Model越换越蠢。这就好比你家水管漏了你不请水电工反而跟水龙头说“请你从另一个路径出水”。水龙头哪有什么冯诺依曼依赖啊你得修管子。2.2 关于提示词你唯一需要记住的一句话我做了这么多年对提示词的理解浓缩成一句话提示词是行为约束不是逻辑代码。它的作用是给模型画一个围栏告诉它别跑出去而不是替模型把它该处理的信息处理完。逻辑要靠上下文、工具结果和代码判断来闭环。为什么这么说因为不管是4o还是Claude还是Gemini它们的核心能力都来自预训练。你的提示词写得再花哨模型不会突然获得新的能力。它只能根据已有知识去理解、生成。所以提示词能做到的极限是“唤醒”模型已有的知识和能力让它更准确地发挥出来。它无法做到“创造”模型本来就不具备的能力。如果你的Agent需要调用内部数据库那靠的不是提示词背数据而是工具和RAG的接驳。如果你想让它做数学计算它不是真的在算背后得挂计算器。如果明白这个前提你就理解为什么那么多人在提示词里堆了一大堆规则结果Agent还是乱来。因为那不是优化那是给模型提一堆超纲要求模型背不动。有些人对提示词的期待已经超出了任何模型的能力边界那种调试注定是无用功甚至越调越糟。2.3 为什么你会觉得“改提示词有效”但话说回来很多人的“改提示词有效”是真的吗这里有一个幸存者偏差改提示词有效只发生在模型本身能力足够、任务边界清晰、上下文不冲突的前提下。你不是通过改提示词“增加”了能力而是通过改提示词“释放”了已有的能力。打个比方一个工具箱里明明有螺丝刀、电钻和扳手但你的指令写得含糊模型只用了扳手。你把指令改清楚说“拧这里的螺丝用螺丝刀打孔用电钻”它工效变高。这不叫玄学这叫“指令清晰度优化”。但绝大多数人栽跟头的地方在于他们把“指令清晰度优化”误当成“Agent优化”一旦Agent整体表现不佳就试图用改提示词来力挽狂澜。说了不听的Agent你换一个说法它就会听吗未必。因为它真正的问题可能是拿了错误上下文或者工具调用参数传错了甚至第一步的目标解析就偏了。这些问题全是指令之外的地方。所以我的结论是提示词优化在Agent里要做但它不是第一优先级。你得先把其他七成的系统问题理顺再回头精修提示词。这个顺序反了你后面就是在泥潭里挣扎。3. Agent优化的真实杠杆点全藏在这些不起眼的细节里3.1 工具调用的设计决定了Agent的上限我接手过很多“优化不动”的Agent项目第一件事永远不是翻提示词而是翻工具定义和API文档。工具是Agent的触手触手残废脑子再好也白搭。工具设计真正考验人的地方不在功能实现而在接口是否贴合模型的理解习惯和Agent的任务流。先说一个最常见的低级错误工具参数定义不清晰。你给Agent一个函数参数名叫data下面写“object类型”没有任何说明模型怎么知道你期待什么样的JSON结构它只能靠猜。猜对了是运气猜错了你怪Agent蠢其实是你没把话说清楚。正确做法是每个参数都给详尽描述列举可以接受的具体值甚至枚举类型给一个示例JSON。这个工作量看起来很琐碎但对于减少“模型胡乱传参”这一类问题效果立竿见影。再说第二层工具之间的边界。新手做Agent最喜欢把一堆功能塞进同一个工具里什么“get_user_and_discount”之类的这就很要命。为什么因为模型不是编排执行器它不知道你这个杂合函数内部发生了什么它只能根据输入输出做匹配。工具越原子化模型就越容易理解和组合。哪怕会导致一次任务多调用几次函数也无所谓稳定可靠比节省几步调用重要得多。工具返回结果也是同样的逻辑我的建议是工具返回的JSON结构越简单越好。模型是语言模型一层套一层的嵌套JSON它虽然能解析但容易出错。把该后处理的逻辑都放到代码里给模型返回一个干净、平铺、带明确字段的结果。宁可多写几行解析代码也别把复杂度留给模型。3.2 上下文管理才是Agent的生存之本你看很多Agent表现不稳定有一个最隐蔽的原因上下文被污染。Prompt写得太长历史对话太多或者上一次任务留下的残留信息没有清理都会干扰模型的判断。这就像一个人背着塞满杂物的背包跑百米反应自然会慢动作自然会变形。先说上下文长度。很多人在系统提示词里堆了一堆背景资料、规章制度、行业知识恨不得把整个操作手册塞进去。结果就是重要指令被淹没在无关信息里模型注意力一分散该听的没听到不该管的倒管上了。我做Agent的第一条军规系统提示词的输入宁可精简尽量不要超过模型上下文窗口的四分之一。留出足够空间给实时任务信息和中间推理。再说历史信息的取舍。Agent每轮任务结束上一轮的中间日志、报错信息、临时变量该清理就清理。什么时候清理用对话轮次监控超过N轮就做摘要压缩然后替换掉旧历史。这个N值取决于你的具体场景但我的经验是超过10轮的纯文本聊天历史就应该启动压缩了否则后面每一轮的有效输出质量都在下滑。上下文管理还有一个容易被忽略的维度筛选。比如RAG场景你检索回来50个文档片段一股脑放进上下文告诉模型“请根据这些资料回答”这绝对是灾难。模型真的会把所有片段当作一回事来参考。正确的做法是在检索端就做好相关性排序和内容过滤只把最相关的5-8个片段回收进上下文。这一步花不了几个钱但提升的准确率是肉眼可见的。3.3 状态管理和错误恢复机制是Agent真正走向工程化的分水岭判断一个Agent是玩具还是生产工具不看它跑得多顺看它出错之后怎么办。这里说的“错误”不是指代码抛异常而是指Agent执行逻辑层面的失败。比如调用了工具但工具返回空比如解析用户意图解析错了比如中途生成格式不对。很多人写的Agent遇到这些情况就是一封死信直接continue触发模型自己想下一步。这个做法其实很差劲。为什么因为模型自己想下一步没有真实反馈作为依据就是闭着眼睛乱猜。正确做法是给Agent设计“分支反馈”机制工具返回空代码先判断一下能不能重试不能重试的话往提示词里注入一条明确信息“上一轮工具调用未返回有效结果请更换策略”再让模型决定下一步。这样模型才不会傻傻地在原地打转。再进阶一点是可以做“计划-执行-验证”三层结构。Agent先列出执行计划再逐步执行每一步当中都做验证如果某一步验证失败就回退到计划节点重新规划。这就很接近人的做事方式了。这种模式虽然得写更多代码但确实能大幅提高任务成功率。把失败交给流程兜底而不是靠模型打死不承认错误来硬扛这是Agent工程化的分水岭。3.4 评测反馈闭环没有数据支撑的优化都是盲目修改我接手的很多项目优化做得像在水里游泳——拼命划水但不知道方向对不对。原因很简单没有评测集。提示词改一句话你觉得变好了觉得变差了全凭感觉。这种感觉说实话跟抛硬币没有本质区别。正确的做法是建一个评测集里面覆盖三类输入——正常输入、边界输入、异常输入。正常输入是日常高频的任务类型边界输入是那些恰好卡在规则边缘的例子异常输入是那种意图不清、缺少信息、甚至故意刁难的请求。每个输入项都标好预期输出然后每次改动之后拿整个评测集跑一遍记录通过率、中间步骤调用率、失败率对比得分。这看起来像是一个正规测试流程但真做起来成本不高一次全量评测可能就几百次调用。比起你盲目改三个月提示词性价比高太多。我自己的习惯是任何调优动作没有评测数据支持就不会上线。这个习惯逼着我从“我觉得”切换到“数据显示”Agent优化的很多谜团都是这么解开的。4. 实操从“提示词调优”转向“系统调优”的完整流程4.1 第一步先用最简配置推倒重来如果你手上已经有个跑不顺的Agent我的第一个建议可能反直觉把提示词删光把代码剥干净从最简版本开始搭。你原来那套精心打磨的提示词现在看起来是在提供帮助其实是把问题都掩盖了。推到只剩骨架系统给你报什么错你就知道哪里真的有问题这是最直接的“真相回归”。具体操作是这样首先系统提示词只保留三句话说清楚Agent的身份、任务边界、输出格式不要加任何废话其次把所有工具调用注释掉先只跑一个最小闭环比如“用户说一句话Agent理解后返回一个结构化结果”。这一步是确认基础链路通不通。最后跑通之后再一个工具一个工具地加回来每加一个就重新用评测集测试一次。可能你会觉得这种重建浪费几小时时间。可我告诉你这个方法在医院系统、电商推荐、内容审核这些场景的Agent项目里全部都能用。原因很简单你从零搭起来的系统每一步都是可解释的你不会被“不知道哪一步引入的问题”困住。4.2 第二步给工具和API建立“合同”这个“合同”指的是工具输入输出的严格规范。我在实际项目里所有工具定义都要求做到三件事参数名用完整语义化命名比如user_email而不是em每个参数都写详尽的类型说明和示例值返回值给一个固定JSON结构字段有中文注释也可以关键是稳定。还有个执行细节工具层要自己做参数校验模型传进来的参数如果格式不对代码直接拦截并返回“参数错误”的信息这个信息再喂给模型告诉它“之前调用方式不对请参考工具说明修正”。这套做法可以让很多模型胡乱传参的问题自动消失。它相当于在工具和模型之间加了一个翻译官而不是让模型直接跟底层API裸奔。4.3 第三步把踩过的坑沉淀成可复用的“经验文件”我见过很多精明的Agent开发者他们会维护一份“注意事项”列表。这个列表不是写在系统提示词里的而是放在一个独立文件或数据库字段中每当Agent在执行某个任务时代码把对应的注意事项动态塞入上下文不涉及的任务从来不放。举个例子一个自动写公众号文章的Agent它最常见的错误是文章结尾喜欢来一句“总之”“综上所述”或者开头总爱写“随着时代的进步”。这些问题是模型学校的惯性不是提示词一两句话能压住的。怎么办我把“本账号风格避免AI套路话术禁止出现‘总之’‘综上所述’等总结词开头直接进入主题”这些规则做成结构化JSON存进只跟写作任务关联的经验文件。每次Agent执行写作任务时代码主动加载这份文件再拼接进任务提示词。模型看到这些具体的负面清单跑偏的概率大大降低。为什么这样比全部塞进系统提示词好因为不同任务需要的经验规则互不相干塞在一起就是信息冗余彼此干扰。把“经验文件”做成和任务绑定的动态配置上下文每次只用最精简的信息性能和效果双赢。4.4 第四步用日志回放定位“决策盲区”最后一步可能最容易被忽略但它决定了你能不能持续优化Agent每一步执行都要留痕。这个留痕不是简单打日志而是把“当前观察到的状态 模型做出的决定 决定依据的技术指标”记录下来形成可回放的事件流。实际遇到Agent行为异常时你就可以看事件流复盘是哪一步开始走偏的。比如你发现Agent在某次工具调用后开始疯言疯语那问题大概率不在提示词而是工具返回的数据里混入了异常内容。你把这些坏数据清洗掉Agent自然就稳了。这件事比你在提示词里反复强调“请忽略错误信息”有效得多。我团队里的Agent项目现在每个都强制挂日志回放工具。没有日志的Agent优化就像在没有仪表盘的飞机里修引擎只能靠手感太冒险了。5. 当你再遇到“Agent不听话”先查这几张排查表5.1 症状Agent总是答非所问或偏离主题第一时间检查的不是提示词是上下文有没有被污染。看看系统提示词是不是塞太满历史对话是不是没清理RAG检索的片段相关性是不是过差。通常把上下文瘦身问题就解决一大半了。我有一个真实案例一个客服Agent老是答非所问排查发现是开场对话历史里存了上一位用户的聊天记录没清理新用户进来直接继承了前面的上下文。你说这跟提示词有什么关系5.2 症状Agent反复做同一个错误操作不听“劝”这经常是因为你的兜底逻辑有问题。Agent调用工具失败后接着又重试了一样的操作它就等于在原地打转。这时候你要做的是在代码层增加“熔断检查”限制同一工具调用的次数上限超过N次就强制降低优先级。不要指望提示词里写“如果失败请换个思路”能拯救一切因为你面对的模型可能压根没有那个能力去思考更优雅的方案。5.3 症状输出质量忽高忽低同一输入不同结果这类问题大概率是模型采样的随机性导致的。解决办法是把关键参数temperature调低尤其在结构化输出场景把top_p也压一压。同时检查输入数据链路是不是存在字段缺失或顺序不稳定。记住输出质量不稳定和模型生成的随机性有关不是提示词能完全控制的你只能通过参数和预处理来降低方差。5.4 症状Agent表现已经不错但想“更进一步”不要急着加提示词先加场景覆盖。你的评测集里多塞点奇怪的真实请求跑一轮看看哪里崩了。很多时候Agent从“八十分”到“九十分”不是靠调一句提示词而是靠把边界场景和异常分支补全。这又回到那句话别把Agent优化写成提示词玄学。它是一门工程一门有流程、有数据、有决策记录的工程。6. 最后说点实操心得我做了这么多Agent项目踩过最大的一个坑就是曾经试图靠改提示词把一个工具链设计有问题的Agent救回来。结果折腾了两周把系统提示词加到了三千字模型倒是更听指令了但工具调用几乎瘫痪。后来推倒重建重新设计工具参数和上下文方案三天就上线了稳定版本。从那以后我给自己立了一个规矩优化任何Agent之前先回答三个问题——我有没有评测数据上下文有没有清理工具接口是不是清晰的如果这三个问题没回答就不要碰提示词。另外一个我特别想分享的小建议把你所有改过的提示词、上下文策略、工具定义变更都记录下来打完一个实验就立刻写一条备忘录。这能让你的优化变得有迹可循。你复盘的时候会发现有些看起来特别精妙的措辞调整对指标的提升其实毫无帮助而一次工具参数描述的小修改可能一下子让Agent的准确率涨了十几个点。这个判断你就是靠记录和评测得出的不是靠感觉猜的。7. 再分享一个让优化事半功倍的扩展思路知道自己正在优化的那三个问题之后你的Agent稳了接下来怎么扩展我会建议你开始沉淀“业务说话规则”。所谓业务说话规则就是针对你的垂直场景积累的负面清单、风格偏好、行为约束全部做成结构化配置通过代码在合适时间注入合适上下文。比如给每个任务类型配一个专属的规则文件日常任务优先级、风格偏好、禁忌词、边界条件都写清楚。这个做法的天花板很高。一方面它让上下文始终精简模型不会被全局注入的大段规则拖累另一方面它让规则复用性极高换一个项目把规则文件换掉就行Agent框架的代码几乎不用动。这种思路其实才是Agent系统的天然扩展方式。你不需要在提示词上雕刻艺术你需要做的是给Agent设计一套可插拔的“行为插件”。最后我想坦白一件事我自己也不是一开始就想明白这些的。做Agent这几年有一段时间真的以为只要提示词写得够好什么Agent都能起飞。后来被现实扇了几个耳光才老老实实回头补工程课。现在回头看真是很庆幸自己没陷在“提示词玄学”里。也希望读到这篇的朋友少走一点弯路多花一点时间在真正让Agent变强的那些地方——工具、数据、流程、反馈。这些听起来没那么酷但真管用。
别把Agent优化写成提示词玄学：系统化调优的工程实践
1. 先说句得罪人的话你的Agent优化可能根本不是优化最近总有人跑来问我我的Agent不听话我改了二十几版提示词从“你要做一个资深助手”改成“你是拥有十年经验的资深专家”再加一堆“请务必、一定要、注意细节”效果还是飘忽不定。每次我听到这种问题第一反应不是看他的提示词写得好不好而是想问他你凭什么觉得问题出在提示词上这个行业现在有个很怪的风气——什么东西火了什么东西就被拿来背锅。AI火了提示词就被封神了。网上铺天盖地的“提示词工程”“XXX提示词大全”“鹈鹕测试提示词原版”满天飞。所谓“鹈鹕测试”就是拿那种“一只鹈鹕骑着自行车穿过沙漠嘴里叼着冰淇淋”的离谱要求去测模型这玩意儿确实能反映模型的指令跟随能力但你别忘了那是单轮对话的测试不是Agent系统测试。拿单轮对话的评判标准去优化一个需要多轮交互、工具调用、状态管理的Agent这不叫优化这叫刻舟求剑。我必须先把话说清楚提示词确实重要它像方向盘决定Agent往哪儿走。但方向盘不等于整车。一辆车跑偏可能是轮胎歪了可能是悬挂坏了甚至可能是路况问题。你猛打方向盘轻则白费力气重则车辆失控。Agent优化真正要解决的问题是把整套系统调好——工具调用、上下文管理、状态流转、回退机制、评估反馈提示词只是其中最容易被看见但也最容易被高估的一个部件。我平时在社区里看到太多这样的案例一个人花了两周时间调提示词最后效果不如另一个花半天重新设计工具接口的人。这不是玄学是有原因的。我自己踩过这个坑也带团队跳过这个坑。这篇文章我把这几年做Agent项目攒下来的真实经验拆开揉碎讲给你听你就明白为什么我说“别把Agent优化写成提示词玄学”。2. 为什么提示词在Agent体系里权重比你想象的低得多2.1 提示词的类型决定了它的能力上限先做个小实验。你打开任何一个大模型的对话框给它打一段话它能回复得很好。这让你觉得提示词无所不能。但Agent不是对话框Agent是一个在跑的流程它要做的是理解任务、拆解步骤、调用工具、拿到结果、判断结果、再决策下一步、直到任务完成。提示词在Agent里的角色分三种系统提示词SysPrompt决定Agent的基调和边界任务提示词TaskPrompt描述当前这一步要干什么以及嵌入在工具定义里的说明性文本告诉模型某个函数是干嘛的、参数怎么填。这三者叠加在一起在整套Agent逻辑里占的比重说实话不超过三成。剩下七成是代码逻辑、工具可用性、数据流设计、状态管理和错误恢复机制。我见过最荒谬的一个项目Agent调一个天气API失败率高达40%团队不查API返回格式也不做重试硬是在提示词里写“如果天气接口失败请换一种方式尝试”结果Model越换越蠢。这就好比你家水管漏了你不请水电工反而跟水龙头说“请你从另一个路径出水”。水龙头哪有什么冯诺依曼依赖啊你得修管子。2.2 关于提示词你唯一需要记住的一句话我做了这么多年对提示词的理解浓缩成一句话提示词是行为约束不是逻辑代码。它的作用是给模型画一个围栏告诉它别跑出去而不是替模型把它该处理的信息处理完。逻辑要靠上下文、工具结果和代码判断来闭环。为什么这么说因为不管是4o还是Claude还是Gemini它们的核心能力都来自预训练。你的提示词写得再花哨模型不会突然获得新的能力。它只能根据已有知识去理解、生成。所以提示词能做到的极限是“唤醒”模型已有的知识和能力让它更准确地发挥出来。它无法做到“创造”模型本来就不具备的能力。如果你的Agent需要调用内部数据库那靠的不是提示词背数据而是工具和RAG的接驳。如果你想让它做数学计算它不是真的在算背后得挂计算器。如果明白这个前提你就理解为什么那么多人在提示词里堆了一大堆规则结果Agent还是乱来。因为那不是优化那是给模型提一堆超纲要求模型背不动。有些人对提示词的期待已经超出了任何模型的能力边界那种调试注定是无用功甚至越调越糟。2.3 为什么你会觉得“改提示词有效”但话说回来很多人的“改提示词有效”是真的吗这里有一个幸存者偏差改提示词有效只发生在模型本身能力足够、任务边界清晰、上下文不冲突的前提下。你不是通过改提示词“增加”了能力而是通过改提示词“释放”了已有的能力。打个比方一个工具箱里明明有螺丝刀、电钻和扳手但你的指令写得含糊模型只用了扳手。你把指令改清楚说“拧这里的螺丝用螺丝刀打孔用电钻”它工效变高。这不叫玄学这叫“指令清晰度优化”。但绝大多数人栽跟头的地方在于他们把“指令清晰度优化”误当成“Agent优化”一旦Agent整体表现不佳就试图用改提示词来力挽狂澜。说了不听的Agent你换一个说法它就会听吗未必。因为它真正的问题可能是拿了错误上下文或者工具调用参数传错了甚至第一步的目标解析就偏了。这些问题全是指令之外的地方。所以我的结论是提示词优化在Agent里要做但它不是第一优先级。你得先把其他七成的系统问题理顺再回头精修提示词。这个顺序反了你后面就是在泥潭里挣扎。3. Agent优化的真实杠杆点全藏在这些不起眼的细节里3.1 工具调用的设计决定了Agent的上限我接手过很多“优化不动”的Agent项目第一件事永远不是翻提示词而是翻工具定义和API文档。工具是Agent的触手触手残废脑子再好也白搭。工具设计真正考验人的地方不在功能实现而在接口是否贴合模型的理解习惯和Agent的任务流。先说一个最常见的低级错误工具参数定义不清晰。你给Agent一个函数参数名叫data下面写“object类型”没有任何说明模型怎么知道你期待什么样的JSON结构它只能靠猜。猜对了是运气猜错了你怪Agent蠢其实是你没把话说清楚。正确做法是每个参数都给详尽描述列举可以接受的具体值甚至枚举类型给一个示例JSON。这个工作量看起来很琐碎但对于减少“模型胡乱传参”这一类问题效果立竿见影。再说第二层工具之间的边界。新手做Agent最喜欢把一堆功能塞进同一个工具里什么“get_user_and_discount”之类的这就很要命。为什么因为模型不是编排执行器它不知道你这个杂合函数内部发生了什么它只能根据输入输出做匹配。工具越原子化模型就越容易理解和组合。哪怕会导致一次任务多调用几次函数也无所谓稳定可靠比节省几步调用重要得多。工具返回结果也是同样的逻辑我的建议是工具返回的JSON结构越简单越好。模型是语言模型一层套一层的嵌套JSON它虽然能解析但容易出错。把该后处理的逻辑都放到代码里给模型返回一个干净、平铺、带明确字段的结果。宁可多写几行解析代码也别把复杂度留给模型。3.2 上下文管理才是Agent的生存之本你看很多Agent表现不稳定有一个最隐蔽的原因上下文被污染。Prompt写得太长历史对话太多或者上一次任务留下的残留信息没有清理都会干扰模型的判断。这就像一个人背着塞满杂物的背包跑百米反应自然会慢动作自然会变形。先说上下文长度。很多人在系统提示词里堆了一堆背景资料、规章制度、行业知识恨不得把整个操作手册塞进去。结果就是重要指令被淹没在无关信息里模型注意力一分散该听的没听到不该管的倒管上了。我做Agent的第一条军规系统提示词的输入宁可精简尽量不要超过模型上下文窗口的四分之一。留出足够空间给实时任务信息和中间推理。再说历史信息的取舍。Agent每轮任务结束上一轮的中间日志、报错信息、临时变量该清理就清理。什么时候清理用对话轮次监控超过N轮就做摘要压缩然后替换掉旧历史。这个N值取决于你的具体场景但我的经验是超过10轮的纯文本聊天历史就应该启动压缩了否则后面每一轮的有效输出质量都在下滑。上下文管理还有一个容易被忽略的维度筛选。比如RAG场景你检索回来50个文档片段一股脑放进上下文告诉模型“请根据这些资料回答”这绝对是灾难。模型真的会把所有片段当作一回事来参考。正确的做法是在检索端就做好相关性排序和内容过滤只把最相关的5-8个片段回收进上下文。这一步花不了几个钱但提升的准确率是肉眼可见的。3.3 状态管理和错误恢复机制是Agent真正走向工程化的分水岭判断一个Agent是玩具还是生产工具不看它跑得多顺看它出错之后怎么办。这里说的“错误”不是指代码抛异常而是指Agent执行逻辑层面的失败。比如调用了工具但工具返回空比如解析用户意图解析错了比如中途生成格式不对。很多人写的Agent遇到这些情况就是一封死信直接continue触发模型自己想下一步。这个做法其实很差劲。为什么因为模型自己想下一步没有真实反馈作为依据就是闭着眼睛乱猜。正确做法是给Agent设计“分支反馈”机制工具返回空代码先判断一下能不能重试不能重试的话往提示词里注入一条明确信息“上一轮工具调用未返回有效结果请更换策略”再让模型决定下一步。这样模型才不会傻傻地在原地打转。再进阶一点是可以做“计划-执行-验证”三层结构。Agent先列出执行计划再逐步执行每一步当中都做验证如果某一步验证失败就回退到计划节点重新规划。这就很接近人的做事方式了。这种模式虽然得写更多代码但确实能大幅提高任务成功率。把失败交给流程兜底而不是靠模型打死不承认错误来硬扛这是Agent工程化的分水岭。3.4 评测反馈闭环没有数据支撑的优化都是盲目修改我接手的很多项目优化做得像在水里游泳——拼命划水但不知道方向对不对。原因很简单没有评测集。提示词改一句话你觉得变好了觉得变差了全凭感觉。这种感觉说实话跟抛硬币没有本质区别。正确的做法是建一个评测集里面覆盖三类输入——正常输入、边界输入、异常输入。正常输入是日常高频的任务类型边界输入是那些恰好卡在规则边缘的例子异常输入是那种意图不清、缺少信息、甚至故意刁难的请求。每个输入项都标好预期输出然后每次改动之后拿整个评测集跑一遍记录通过率、中间步骤调用率、失败率对比得分。这看起来像是一个正规测试流程但真做起来成本不高一次全量评测可能就几百次调用。比起你盲目改三个月提示词性价比高太多。我自己的习惯是任何调优动作没有评测数据支持就不会上线。这个习惯逼着我从“我觉得”切换到“数据显示”Agent优化的很多谜团都是这么解开的。4. 实操从“提示词调优”转向“系统调优”的完整流程4.1 第一步先用最简配置推倒重来如果你手上已经有个跑不顺的Agent我的第一个建议可能反直觉把提示词删光把代码剥干净从最简版本开始搭。你原来那套精心打磨的提示词现在看起来是在提供帮助其实是把问题都掩盖了。推到只剩骨架系统给你报什么错你就知道哪里真的有问题这是最直接的“真相回归”。具体操作是这样首先系统提示词只保留三句话说清楚Agent的身份、任务边界、输出格式不要加任何废话其次把所有工具调用注释掉先只跑一个最小闭环比如“用户说一句话Agent理解后返回一个结构化结果”。这一步是确认基础链路通不通。最后跑通之后再一个工具一个工具地加回来每加一个就重新用评测集测试一次。可能你会觉得这种重建浪费几小时时间。可我告诉你这个方法在医院系统、电商推荐、内容审核这些场景的Agent项目里全部都能用。原因很简单你从零搭起来的系统每一步都是可解释的你不会被“不知道哪一步引入的问题”困住。4.2 第二步给工具和API建立“合同”这个“合同”指的是工具输入输出的严格规范。我在实际项目里所有工具定义都要求做到三件事参数名用完整语义化命名比如user_email而不是em每个参数都写详尽的类型说明和示例值返回值给一个固定JSON结构字段有中文注释也可以关键是稳定。还有个执行细节工具层要自己做参数校验模型传进来的参数如果格式不对代码直接拦截并返回“参数错误”的信息这个信息再喂给模型告诉它“之前调用方式不对请参考工具说明修正”。这套做法可以让很多模型胡乱传参的问题自动消失。它相当于在工具和模型之间加了一个翻译官而不是让模型直接跟底层API裸奔。4.3 第三步把踩过的坑沉淀成可复用的“经验文件”我见过很多精明的Agent开发者他们会维护一份“注意事项”列表。这个列表不是写在系统提示词里的而是放在一个独立文件或数据库字段中每当Agent在执行某个任务时代码把对应的注意事项动态塞入上下文不涉及的任务从来不放。举个例子一个自动写公众号文章的Agent它最常见的错误是文章结尾喜欢来一句“总之”“综上所述”或者开头总爱写“随着时代的进步”。这些问题是模型学校的惯性不是提示词一两句话能压住的。怎么办我把“本账号风格避免AI套路话术禁止出现‘总之’‘综上所述’等总结词开头直接进入主题”这些规则做成结构化JSON存进只跟写作任务关联的经验文件。每次Agent执行写作任务时代码主动加载这份文件再拼接进任务提示词。模型看到这些具体的负面清单跑偏的概率大大降低。为什么这样比全部塞进系统提示词好因为不同任务需要的经验规则互不相干塞在一起就是信息冗余彼此干扰。把“经验文件”做成和任务绑定的动态配置上下文每次只用最精简的信息性能和效果双赢。4.4 第四步用日志回放定位“决策盲区”最后一步可能最容易被忽略但它决定了你能不能持续优化Agent每一步执行都要留痕。这个留痕不是简单打日志而是把“当前观察到的状态 模型做出的决定 决定依据的技术指标”记录下来形成可回放的事件流。实际遇到Agent行为异常时你就可以看事件流复盘是哪一步开始走偏的。比如你发现Agent在某次工具调用后开始疯言疯语那问题大概率不在提示词而是工具返回的数据里混入了异常内容。你把这些坏数据清洗掉Agent自然就稳了。这件事比你在提示词里反复强调“请忽略错误信息”有效得多。我团队里的Agent项目现在每个都强制挂日志回放工具。没有日志的Agent优化就像在没有仪表盘的飞机里修引擎只能靠手感太冒险了。5. 当你再遇到“Agent不听话”先查这几张排查表5.1 症状Agent总是答非所问或偏离主题第一时间检查的不是提示词是上下文有没有被污染。看看系统提示词是不是塞太满历史对话是不是没清理RAG检索的片段相关性是不是过差。通常把上下文瘦身问题就解决一大半了。我有一个真实案例一个客服Agent老是答非所问排查发现是开场对话历史里存了上一位用户的聊天记录没清理新用户进来直接继承了前面的上下文。你说这跟提示词有什么关系5.2 症状Agent反复做同一个错误操作不听“劝”这经常是因为你的兜底逻辑有问题。Agent调用工具失败后接着又重试了一样的操作它就等于在原地打转。这时候你要做的是在代码层增加“熔断检查”限制同一工具调用的次数上限超过N次就强制降低优先级。不要指望提示词里写“如果失败请换个思路”能拯救一切因为你面对的模型可能压根没有那个能力去思考更优雅的方案。5.3 症状输出质量忽高忽低同一输入不同结果这类问题大概率是模型采样的随机性导致的。解决办法是把关键参数temperature调低尤其在结构化输出场景把top_p也压一压。同时检查输入数据链路是不是存在字段缺失或顺序不稳定。记住输出质量不稳定和模型生成的随机性有关不是提示词能完全控制的你只能通过参数和预处理来降低方差。5.4 症状Agent表现已经不错但想“更进一步”不要急着加提示词先加场景覆盖。你的评测集里多塞点奇怪的真实请求跑一轮看看哪里崩了。很多时候Agent从“八十分”到“九十分”不是靠调一句提示词而是靠把边界场景和异常分支补全。这又回到那句话别把Agent优化写成提示词玄学。它是一门工程一门有流程、有数据、有决策记录的工程。6. 最后说点实操心得我做了这么多Agent项目踩过最大的一个坑就是曾经试图靠改提示词把一个工具链设计有问题的Agent救回来。结果折腾了两周把系统提示词加到了三千字模型倒是更听指令了但工具调用几乎瘫痪。后来推倒重建重新设计工具参数和上下文方案三天就上线了稳定版本。从那以后我给自己立了一个规矩优化任何Agent之前先回答三个问题——我有没有评测数据上下文有没有清理工具接口是不是清晰的如果这三个问题没回答就不要碰提示词。另外一个我特别想分享的小建议把你所有改过的提示词、上下文策略、工具定义变更都记录下来打完一个实验就立刻写一条备忘录。这能让你的优化变得有迹可循。你复盘的时候会发现有些看起来特别精妙的措辞调整对指标的提升其实毫无帮助而一次工具参数描述的小修改可能一下子让Agent的准确率涨了十几个点。这个判断你就是靠记录和评测得出的不是靠感觉猜的。7. 再分享一个让优化事半功倍的扩展思路知道自己正在优化的那三个问题之后你的Agent稳了接下来怎么扩展我会建议你开始沉淀“业务说话规则”。所谓业务说话规则就是针对你的垂直场景积累的负面清单、风格偏好、行为约束全部做成结构化配置通过代码在合适时间注入合适上下文。比如给每个任务类型配一个专属的规则文件日常任务优先级、风格偏好、禁忌词、边界条件都写清楚。这个做法的天花板很高。一方面它让上下文始终精简模型不会被全局注入的大段规则拖累另一方面它让规则复用性极高换一个项目把规则文件换掉就行Agent框架的代码几乎不用动。这种思路其实才是Agent系统的天然扩展方式。你不需要在提示词上雕刻艺术你需要做的是给Agent设计一套可插拔的“行为插件”。最后我想坦白一件事我自己也不是一开始就想明白这些的。做Agent这几年有一段时间真的以为只要提示词写得够好什么Agent都能起飞。后来被现实扇了几个耳光才老老实实回头补工程课。现在回头看真是很庆幸自己没陷在“提示词玄学”里。也希望读到这篇的朋友少走一点弯路多花一点时间在真正让Agent变强的那些地方——工具、数据、流程、反馈。这些听起来没那么酷但真管用。