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

全局提示词管风格真挺重要的，我试过只靠变量传上下文，结果风格乱成一锅粥。

调试的话建议每步单独跑用例，把输出缓存下来对照改，不然牵一发动全身太痛苦。

全局系统提示词定风格，每步只写增量指令，调试时单步打日志最管用。

全局统管风格确实省心，但步骤间变量传递得设计清楚，不然改哪都容易崩。

我最近也踩过这个坑，后来发现全局系统提示词里只放角色和通用规则，把步骤间的格式要求全塞进各自Prompt反而更稳。你那个“规划→选工具”断层的问题，可以试试在规划输出里直接定义好工具ID和参数占位符，后面步骤只做解析，减少重复解释。调试的话，我习惯给每步加一个“上一步输出摘要”的变量，改Prompt时先锁定其他步骤的输出格式，再单独调变量传递的逻辑，不然牵一发动全身真的会疯。

全局系统提示词定风格，各步骤只写增量指令，调试时先锁住下游输出再改上游。

建议全局系统提示词统管风格，步骤里只写增量指令，不然每步都重复解释格式纯属浪费token。调试时先固定其他步骤，单独调一个，改完再回归测试，不然真没法定位问题。

全局提示词定风格和格式，步骤里只留增量指令，能省掉不少重复解释的麻烦。调试时建议先固定其他步骤，单独调一个环节，不然变量太多根本定位不了问题。

设置好全局规则后，各步骤只写“这步要干啥”，冗余感会少很多。调试多轮prompt建议固定其他步骤，单独调一个环节，不然变量太多根本定位不了问题。

我最近也在搞类似的流程，试下来感觉全局系统提示词还是得有，但别写太死，只定风格和边界，具体步骤的指令放各阶段里。你那个“参数生成”和“规划”之间的格式问题，其实可以在系统提示里给个统一的JSON schema，步骤里只强调该填哪些字段。调试的话，我习惯给每个步骤固定一个测试用例，改完一个prompt就跑全套，重点看相邻两步的交接是否流畅，不然确实容易按下葫芦浮起瓢。

建议全局系统提示词管风格，各步骤只写增量指令，调试时固定其他步骤只改一个变量。

全局提示词定基调，步骤提示词只写差异部分，这样改起来不会牵一发动全身。

我之前搞类似的东西也踩过这个坑，后来是把全局风格和约束都塞进system prompt里，各个步骤的prompt只保留当前动作要的东西，像“根据上一步输出，输出JSON格式的xxx”，这样改起来才不容易连锁翻车。调试的话强烈建议给每个步骤都加个log，把输入输出都打出来，然后单独跑某个步骤，用固定的假数据去测，不然真的不知道是哪一步带偏了。另外你那个“检查结果”的步骤，其实可以复用到前面几个步骤上，不用每步都写一套检查逻辑，省得冗余。

全局提示词定基调是必须的，各步骤只写增量指令能少很多重复解释。调试时改一步就全量回归测试，拿几个固定case盯输出变化。

全局系统提示词管风格，分步就纯写增量指令，别重复定义格式。调试建议搞个回归用例集，改完跑一遍看哪个环节漂移了。

我最近也踩过类似的坑，拆太细反而让模型丢失了全局观。建议保留一个简短的系统级prompt定基调，后面步骤只写“当前任务+必须遵守的硬性格式”，别重复解释规则。

调试的话，强烈建议给每个步骤单独记log，把输入输出都存下来，出问题就回放哪一步变形了。改prompt时一次只动一个，跑同一批测试案例对比，不然根本分不清是谁影响的。

另外可以试试把“规划→执行”改成循环结构，让模型自己决定下一步调什么，比硬拆四个阶段更自然，也省得来回解释格式。

我之前也踩过这个坑，后来发现全局系统提示词里只放角色和硬性输出规范，步骤间的格式要求靠前一步输出里带，别重复定义。调试的话，建议给每步加一个“自检”字段，让模型自己确认输出结构，这样改一步出问题能快速定位到是哪层逻辑变了。另外参数生成那步最容易崩，可以考虑把工具schema直接塞进去，别让它自己猜。

说实话你这个拆法我太熟了，之前做类似东西也是这么干的，后来发现最核心的问题不是每个步骤Prompt写得好不好，而是它们之间共享的“状态”根本没对齐。我现在的做法是全局系统提示词里只定死角色、工具清单和输出格式的公共规范，然后每个步骤的Prompt只写“基于你刚才规划的结果，现在做选择”这种增量指令，这样至少不会出现规划阶段让输出JSON选工具阶段又让它解释一遍字段的情况。调试的话，我建议你搞一套固定的“测试剧本”，就是给几个典型的任务输入，每次改完Prompt把四步的完整输出都打出来对比，别只看单步结果，因为变量传递的隐形错误往往比Prompt本身更坑。另外你说的改一步影响另一步，大概率是格式约束不一致导致的，比如规划阶段要求输出“工具名+参数占位符”，到选工具阶段又让它自由发挥，模型就会在中间层产生歧义，所以你可以试着一个贯穿始终的“中间表示”，比如每一步都往这个表示里填字段，而不是每步重新生成一套格式。还有个小技巧，如果某个步骤反复出问题，就把它踢出去跟另一个步骤合并，有时候分太多步反而让模型失去上下文焦点，合并以后反而更稳。

我个人建议全局系统提示词别省，但只负责定语气和边界，像“你是调度者”这种就够了，具体格式全扔给各步骤增量写，能少很多重复解释。调试的话，我习惯给每步留一个固定的JSON输出模板，改哪步就只盯着那步的schema看，不然变量一乱确实容易连锁崩。另外你那个“检查结果”步骤其实可以做成通用校验器，别让它参与业务逻辑，这样至少能稳住一头。

我之前也踩过这个坑，后来是把全局规则放在系统提示词里，比如输出格式、语气这些，步骤Prompt只写当前要做什么，不然改一个地方全崩。调试的话建议每个步骤单独跑测试用例，固定住前几轮的输出，不然问题根本定位不了。

其实连贯性不一定要靠Prompt硬撑，步骤之间传结构化数据比让模型自己记上下文靠谱多了。我试过把规划阶段的JSON schema直接传给下一步，比重新解释一遍省心太多。

至于改一个步骤影响另一个，大概率是前一步的输出格式不够稳定。你可以在规划阶段强制要求输出带编号的JSON，后面步骤直接解析，而不是让模型再理解一遍自然语言。调试的话用langsmith这类工具录trace，哪一步变了对比一下很直观。

我之前也遇到过类似的问题，后来发现把全局规则塞进系统提示词里确实能省不少事，各步骤只写增量要求，格式冲突会少很多。调试的话，建议给每个步骤单独跑测试用例，别一上来就全链路跑，不然变量太多根本定位不到问题。还有个土办法，就是给每个Prompt加个固定的“输出自检”字段，让模型自己检查格式，能过滤掉不少隐性问题。

其实拆步骤的思路没问题，但连贯性差往往是因为全局信息没传透。我习惯把公共约束（比如输出格式、命名规范）写进一个system prompt，步骤里只保留“这步该干嘛”和“上一步给你的东西怎么处理”。调试的时候可以记录每步的输入输出做对照，改完一个步骤后重点看它下游的步骤是否还认得上文格式，别怕麻烦，这玩意儿就是得反复喂数据调。

我自己的做法是“全局大纲+局部细节”混着来，系统提示词里定死风格和通用规则，各步骤只写跟当前动作强相关的指令，像参数生成那步就只强调字段类型和边界。调试的话，我会给每个步骤写个单独的“金标准”输出样例，拿模型输出和样例比对，这样哪个步骤跑偏了一眼就能看出来。另外，改完一个步骤最好把整条链子跑一遍，因为上下文传递经常会把旧

全局系统提示词定调子，各步骤只写增量指令，不然改一处全崩。调试就加日志盯每步输出，变量传递时格式对齐能省好多事。

我之前也踩过这个坑，后来改成全局系统提示词定语气和输出规范，步骤Prompt只写当前阶段的增量要求，冗余感会好很多。调试的话建议给每一步都加个独立的日志记录输入输出，不然改一个环节后面全乱套，根本不知道问题出在哪。另外你可以试试把“选工具”和“生成参数”合并成一步，让模型直接输出带参数的调用指令，能少一次格式转换的损耗。

我最近也在搞类似的，试下来感觉全局系统提示词还是得有，但别塞太多风格性的东西，把工具定义和输出规范放进去就够了，步骤里只写这轮要干嘛，不然模型容易混淆上下文。调试的话我习惯给每步加个日志钩子，把传进去的变量和原始输出都打出来，改完一个prompt就回看前后两步的输入输出，这样能快速定位是哪步把格式带偏了。另外你那个“检查结果”的步骤，试试让它输出结构化错误码而不是自然语言描述，后面重试逻辑会好写很多。

我最近也在搞类似的agent，试下来感觉全局系统提示词还是得留一份，专门定调子和约定通用格式，但每个步骤的prompt里该重复的关键信息还是得重复，不能指望模型自己记住，省那点token后面调试更费劲。调试的话我习惯先把每个步骤的输出单独打日志，看是哪一步开始跑偏的，不然真的改一步崩一步。

另外你那个“规划→选工具→生成参数→检查结果”的拆法，我觉着问题可能不在prompt碎不碎，而是步骤之间传递的上下文结构没设计好。我后来是把每一步的schema都统一了，比如都用json包一层带step_name和content，这样模型跨步骤理解起来负担小很多，你可以试试看。

我踩过的坑是检查结果那一步特别吃上下文，如果前面选工具的输出格式不固定，后面检查逻辑就得写一堆模糊匹配。所以我现在干脆让选工具那步也输出一个“预期效果”字段，检查步骤直接拿它跟实际结果比对，省得来回解释，提示词也精简了不少。