Agent系统里每个步骤的Prompt该怎么拆？总感觉写得太碎

全局系统提示词定风格，步骤里只写增量指令，不然上下文一长必乱。调试时用trace记录每步输入输出，改哪步就看哪步的变量流。

全局系统提示词定风格，步骤只写增量指令，不然上下文串味调试更痛苦。

我之前也踩过这坑，建议你试试先把全局模板固定，再逐个调步骤，能少掉不少头发。

全局系统提示词定风格和格式，步骤里只写增量指令，不然改一处全崩，调试能累死。

说实话你这个拆法我太懂了，之前做类似东西也踩过这个坑。我现在的做法是全局系统提示词只定角色和输出底线，比如“你是调度员，必须用JSON返回”，然后每个步骤的Prompt只写本步要什么和跟上下文的衔接字段，别让它们各写各的。你提到的格式重复问题，其实可以试试点“继承式”写法，就是在选工具那步开头直接写“根据上一步计划的task_list，从中选一个”，这样模型能顺着上下文走，不用重新解释。调试的话我建议先固定住全局提示词，然后单独调每个步骤的输入输出样例，用五六个典型case来回跑，别一上来就调全链路，不然改A坏B根本找不到原因。还有个土办法，把每步的真实输出打到日志里，对比看是哪一步开始格式崩的，比瞎猜快得多。你那个“检查结果”步骤，有没有试过把错误信息原样塞回去让它自己改？有时候比重新生成参数管用。

我之前也踩过这个坑，后来发现全局系统提示词还是要有的，但只定死输出格式和角色边界，把具体步骤的逻辑全塞进各阶段prompt里反而更清晰。你那个“规划→选工具”的割裂感，大概率是格式说明重复了，试试在全局统一定义一个通用的JSON Schema，后面步骤只写“基于上一步结果填充字段”。调试的话建议给每步单独跑测试用例，固定前一步的mock输出，不然你根本分不清是哪个环节被带偏了。

全局prompt定死风格和协议，步骤里只塞增量指令，调试会省心很多。

我一般先把各步骤输出打出来看变量传递，再用脚本批量跑case对比改动影响。

全局提示词定风格，步骤里只写增量指令，不然改一处牵全身。调试时给每步固定输入录个基线，变化好定位。

全局提示词定风格挺重要的，步骤间只传必要变量，别让每步都从零解释。调试的话建议先固定其他步骤，单测变化那一步的输出。

全局统管风格确实省心，但增量指令写不好更乱。我一般用trace记录每步输入输出，改完看全链路，比盲调强。

我之前也踩过这个坑，后来干脆把全局约束（比如输出格式、工具调用规则）全塞进系统提示词里，每个步骤的Prompt只写“这一步要干嘛”和“上一步结果怎么用”，这样改起来轻松很多。调试的话建议给每个步骤加一个“自检输出”的字段，让它先打印理解的目标再执行，不然真的容易牵一发动全身。另外你可以试试把“选工具”和“生成参数”合并成一个Prompt，很多时候分开写反而会逼着模型重复解释上下文。

全局提示词定死风格和公共格式，步骤里只写增量指令，不然改一处崩全链路。

调试建议先固定中间输出快照，单独测每步再串起来，不然变量太多根本定位不了问题。

我最近也在搞类似的Agent，踩过一样的坑。我的做法是全局系统提示词只定角色和输出风格，步骤间的格式要求靠各步Prompt里的few-shot示例来约束，这样改起来不会全局崩。调试的话建议给每步单独记log，把输入输出都存下来，出问题直接看是哪一步的格式没对上，比盲调省心很多。

我之前也踩过这个坑，后来干脆把全局规则（比如输出格式、工具定义）全塞进系统提示词里，每个步骤只写“这步要干嘛”的增量指令，这样改起来不会牵一发动全身。调试的话建议给每个步骤单独跑测试用例，别整条链路一起调，不然出问题都不知道是哪个Prompt在捣鬼。你那个“检查结果”步骤有没有考虑过跟“生成参数”合并？有时候拆太细反而会让模型丢失上下文。

全局prompt定风格+步骤只写增量，不然改一处崩全局，调试能逼疯你。
我一般给每步加个输入输出的强校验，比靠prompt硬控稳定多了。

我最近也在搞类似的，试过把系统提示词当“总纲”写清楚全局约束和输出风格，每个步骤的prompt只塞当前任务和变量，这样改起来会轻松不少。调试的话建议给每个步骤单独加log，把模型输入输出都打出来，哪个环节崩了直接看那一步的上下文，别整个链路一起调。另外你那个“检查结果”的步骤其实可以复用规划阶段的格式要求，不用重复定义，把公共格式抽到全局提示里就行。

全局system prompt定死规则，步骤prompt只写增量，不然上下文一长风格必漂。

调试我建议给每步输出加个校验节点，哪个环节挂了就只调那个环节，别全链路返工。

我最近也踩过这个坑，后来发现全局系统提示词还是得留着，但只负责定义角色和输出风格，具体每个步骤的格式要求全部挪到各自的prompt里，这样改起来不会互相污染。调试的话，建议给每个步骤单独准备几个固定case，改完一个prompt就跑一遍，看输出变化，别等全串起来再试，不然根本定位不了问题。另外你那个“生成参数”和“检查结果”其实可以合并，很多工具调用失败是参数格式问题，让模型自己先校验一遍能省一轮对话。

我之前也踩过这个坑，后面改成全局系统提示词统管整体风格和输出规范，步骤里只写“这步该干嘛”的增量指令，明显顺多了。调试的话，最笨但有用的办法是固定其他步骤的输入输出，单独改一个步骤然后跑用例对比，不然牵一发动全身根本定位不了问题。另外你提到格式冗余，不如直接把共享格式定义成全局变量，每个步骤Prompt里引用变量名就行，省得重复写。说实话这种多轮调参确实头疼，建议每次改完都记录一下各步骤的实际输出，久了就能看出规律。

全局提示词必须有，不然风格必崩，步骤间只传变量不传上下文太容易跑偏了。调试的话我习惯把每步输出存下来对比看，单改一步确实会连锁反应，只能慢慢试。

说实话我之前也踩过这个坑，后来干脆把全局规则（输出格式、工具使用边界）都塞进system prompt里，后面每步只写“这步要干嘛”的增量指令，感觉清爽多了。调试的话建议给每个步骤单独打日志，把实际收到的上下文和输出都记下来，不然改一个环节确实容易牵一发动全身。另外你试试让模型在规划阶段就输出一个结构化意图，后续步骤直接解析那个格式，能少写很多重复解释。

我最近也在搞类似的Agent，试下来感觉全局提示词还是得留一份，专门定语气和通用规则，但别把具体步骤塞进去，不然各阶段模型容易互相干扰。步骤间的prompt建议只带必要上下文，比如规划输出直接转成结构化数据传给下一步，比让模型自己“记住”上一步说了啥靠谱。调试的话，我习惯给每步加个固定的测试用例，改完一个prompt就跑一遍全流程对比输出，不然真的会拆东墙补西墙。