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

我之前也踩过这个坑，后来发现全局系统提示词里定好统一的输出规范和角色，各步骤的Prompt只写增量指令会轻松很多，不然每个环节都重复解释格式太容易出bug。调试的话建议给每个步骤单独做输入输出样本的回归测试，改一个环节就固定其他环节的输入去跑，不然根本分不清是哪个Prompt影响了质量。另外你提到的“规划→选工具→生成参数”之间，试试在规划输出里直接带上工具ID和参数占位符，让下一步直接引用，能省掉不少重复解释。

说实话你这个拆法我太有同感了，之前做类似的东西也是被这个连贯性问题折磨得不行。后来我试出来的做法是保留一个全局的system prompt，把任务背景、工具列表、输出风格这些公共信息全放进去，然后每个步骤的prompt只写“当前这一步要干什么”和“必须遵守的额外约束”，这样至少不会出现规划格式到选工具阶段又得解释一遍的情况。不过全局prompt也不能写太长，不然模型容易把注意力分散到不相关的地方，我一般控制在300字以内。调试多轮prompt我自己的土办法是给每一步的输入输出都打日志，把变量实际传进去的内容单独存下来看，很多时候问题出在格式解析上而不是prompt本身。至于改一步影响另一步，这个确实无解，我后来是把每个步骤的测试用例固化下来，改完跑一遍回归，虽然麻烦但至少能及时发现哪里崩了。你那个“检查结果”的步骤，如果发现模型经常把错误归因到工具上，可以考虑把工具返回的原始错误信息原样传给下一步，而不是让模型自己总结，这样能减少信息失真。

全局系统提示定死风格和格式，步骤里只写增量指令，不然改一处全崩。调试就靠记录每步输出，回看哪步变了再单独调。

全局系统提示词定基调，步骤里只写增量指令，不然改一处崩全局。调试时先固定输出格式，再单测每步变量传递。

我最近也在搞类似的东西，踩过一样的坑。我的做法是保留一个全局系统prompt定调子，定义清楚工具列表和通用规则，后面每个步骤只写增量要求，这样至少格式不用反复解释。调试的话建议给每一步都加个日志输出，把传给模型的上下文和返回结果都打出来，不然真的很难定位是哪个环节跑偏了。另外你提到的改一步影响另一步，大概率是之前步骤的输出格式不够稳定，试试在prompt里强制JSON输出，能省不少事。

我最近也在搞类似的，试过全局系统提示词统管风格，步骤里只写增量指令，感觉比各写各的连贯多了，至少格式不用反复解释。调试的话，建议你先把每个步骤的输入输出用json固定下来，改一个prompt就跑一遍全流程看哪里断了，别老盯着单步调，我现在就是这么干的，头疼能缓解不少。

全局系统提示词定好规矩，步骤里只写增量指令，不然改一处崩全局，真的会疯。

调试的话建议先固定其他步骤只动一个，变量多了根本分不清是谁影响的。

全局提示词定风格真的有用，步骤里只写增量指令，不然改一处全局崩。

调试的话建议先把每步输出打日志看变量传递，别同时调两个步骤，不然问题都找不到。

全局系统提示词定风格和格式，步骤里只写增量指令，不然改一处全崩。调试就加日志看每步输入输出，问题藏在传递里。

说实话你这个拆分方式我特别能理解，我之前就是这么干的，结果跟你一样，四个Prompt各说各话，模型在第三步突然忘了第一步的约定。后来我试了另一种路子，全局system prompt里把整个任务的背景、工具列表、通用输出规范全写死，每个步骤的Prompt只负责说“这一步具体干啥”，比如规划阶段就只给任务描述和约束，选工具阶段就只给当前可选项和上一步的规划结果，这样上下文靠变量传，但风格和规则不重复，感觉清爽很多。调试的话，我建议你每次只改一个步骤的Prompt，然后固定其他步骤的输出作为输入，跑十次看统计，别凭感觉调，因为LLM对措辞特别敏感，你改个标点都可能影响后面步骤。还有个坑是“检查结果”这个步骤，如果它跟“生成参数”之间没有明确的错误反馈机制，模型很容易陷入自我修正的循环，我后来是把检查失败的原因直接拼回生成参数的Prompt里，让它基于错误重试，效果比单独写一个检查Prompt好。你那个“规划→选工具→生成参数→检查结果”的链路，我觉得可以试试把前两步合并，因为规划的时候其实已经能确定要调哪个工具了，拆太碎反而增加不一致的风险。另外调试多轮Prompt有个小技巧，就是在每步输出里加一行注释性的字段，比如“draft_reason”，让模型自己解释为什么这么选，排查问题时能省不少力气。

我之前也踩过这个坑，后来发现全局系统提示词其实不用管太多风格，重点是把“工具定义”和“输出协议”这种跨步骤的硬约束放进去，然后每个步骤的Prompt只负责描述当前阶段的输入输出和动作。你那个“规划→选工具→生成参数→检查结果”的拆法本身没问题，但冗余感往往来自步骤间没有共享一份“状态摘要”——比如规划阶段产出的中间变量，选工具时其实只需要引用变量名，不用重新解释含义，这样能省掉很多重复描述。调试这种多轮Prompt，我建议你先把每个步骤的输入输出样例固定下来，做成一个小的单元测试集，改任何一个Prompt后跑一遍全流程，看哪里崩了再定位。还有一个容易忽略的点：如果你发现改A步骤影响B步骤，大概率是因为B步骤的Prompt里隐含了对A步骤输出的具体格式假设，这时候最好显式地在系统提示里声明“所有步骤的中间结果必须遵守同一套schema”，而不是靠每个子Prompt去猜。最后，建议你把“检查结果”这一步设计成可以回退重跑的循环，而不是单纯的线性结束，这样调参的时候能更快找到是哪一步引入的错误。

我最近也在搞类似的Agent，踩过一样的坑。我的做法是全局系统提示词只定角色和输出风格，然后把步骤间共享的格式约定塞进一个单独的“公共规范”变量里，每个步骤的Prompt只写自己的增量逻辑，这样改起来能少牵连一些。调试的话，我会给每个步骤固定一个测试用例，单独跑通再串起来，不然一出问题根本分不清是哪个环节带偏了。你说的改一步影响另一步，大概率是变量传递时格式没对齐，建议在步骤间加个轻量的校验函数，比纯靠Prompt硬约束稳得多。

我最近也在搞类似的东西，踩过的坑跟你差不多。我的感觉是，全局系统提示词确实得有，但别写成风格约束，而是把整个任务的“世界观”和工具清单放进去，这样每个步骤的Prompt就只负责说“这步要干嘛”和“输出长什么样”，不然你后期改一个步骤，其他全得跟着动。至于你说的冗余问题，我试过在规划阶段就强制模型输出一个统一的JSON结构，后面选工具和生成参数直接拿那个结构里的字段去拼，这样重复解释格式的情况会少很多。调试多轮Prompt我真的建议你做个简单的日志系统，把每轮的完整输入输出都存下来，尤其是token用量和模型返回的原始内容，光看控制台打印根本看不出是哪一步影响了下一步。另外，你提到改一个步骤另一个就变差，这太正常了，因为LLM对上下文顺序很敏感，我后来把步骤之间的变量名统一成一套，比如都用task、tool、args，然后每一步的Prompt里都明确写“你收到的是上一步的task字段，不要改动它”，这样输出稳定性会好一些。还有个偏方，如果你觉得步骤太多，可以考虑把“生成参数”和“检查结果”合并成一个Prompt，让模型自己先提参数再自检，虽然逻辑上没那么干净，但实际效果经常比拆开要好调。

我个人建议全局系统提示词只定角色和输出底线，具体步骤的prompt尽量只写增量指令，不然四个阶段共享一套长上下文，模型反而容易混淆优先级。调试的时候可以给每个步骤单独存log，改一个环节就对比前后两轮的结构变化，别光看最终结果。另外你那个“选工具”和“生成参数”其实可以合并，很多模型一步就能处理好，拆太碎反而增加不稳定因素。

说实话你这个拆法我太熟了，之前做工具调用也卡在这。我的经验是全局系统提示词必须得有，但别让它管太细，就定死“你是执行者，按步骤输出JSON”这种底层规矩，然后每个步骤的Prompt只写增量，比如规划阶段只管给目标清单，选工具那步就别重复解释格式了，直接说“根据上一步的清单，输出工具名和理由”。这样改起来至少有个锚点，不会牵一发动全身。

调试的话，我建议你先把每个步骤的输入输出固定成schema，跑通一条理想路径再开始调风格。我一般会准备三个测试用例，一个正常、一个边界、一个恶意输入，每次改完Prompt全跑一遍，看哪个环节崩了再单独看那步的log。你说的改一个步骤影响另一个，大概率是变量传递里带了太多隐含格式化信息，比如规划阶段输出里混了多余描述，到选工具时模型就被带偏了，所以尽量让每步只吃结构化字段，别让它自己猜。

还有个土办法，你可以在每步Prompt末尾加一句“严格只输出规定格式，不要解释”，能省掉好多重复说明。不过说实话，多步Agent本来就是个熵增过程，我后来干脆把步骤合并成两个，规划加选工具一起，参数生成和检查拆开，反而好调多了，你可以试试看。

我最近也在搞类似的，拆太碎确实容易上下文断裂，但全局系统提示词写多了又会让模型在具体步骤上犯迷糊。我的做法是全局只定角色和约束，步骤里只写当前要做的动作和输出格式，变量靠代码拼进prompt。调试的话，我会给每一步单独跑测试集，改一步就回归跑前面几步，看输出格式变化，不行就调那一步的描述，别指望一步到位。

全局系统提示词得立住，步骤里只写增量，不然真就各说各话。调试我建议给每步单独留日志，改哪看哪，别全链路一起调。

全局系统提示词定基调，步骤里只写增量指令，不然改一处崩全局太正常。调试时建议给每步喂固定中间输出，单独验效果。

全局系统提示词肯定要留一份的，不然每个子步骤都在重复解释角色和格式，模型又容易飘。我自己是把公共约束放系统层，步骤里只写“这步要干嘛”和“上一步给了你啥”，这样改单步逻辑不会连带崩掉别的环节。

调试的话，建议给每步单独存log，输入输出都打下来，出问题先看是哪一步的上下文污染了。你那个“规划格式到选工具得重新解释”的痛点，多半是规划输出没做结构化解析，直接拿原始文本喂给下一步了，试试强制JSON输出会好很多。

说实话你这个拆分方式我太熟了，之前做工具调用也踩过同样的坑。我的经验是全局系统提示词必须得有一份，但别让它管太细，就定死语气、输出风格和通用的JSON格式规范，这样四个步骤至少看起来是同一个“人”在干活。每个步骤的Prompt里，除了必要的变量，我还会把上一步的输出摘要塞进去，哪怕只是两三行，比光传结构化数据管用得多，模型能少猜很多隐含意图。调试的话，我一般会固定住前三步的Prompt，只调最后一步，等稳定了再回去动前面的，不然真没法定位是哪里崩的。另外你可以试试给每个步骤加一个“输出自检”的隐形指令，比如让模型在生成参数前先复述一遍它理解的工具功能，这招能明显减少格式错乱。还有个坑，规划阶段别让它输出太复杂的嵌套结构，不然到选工具那步解析就容易丢字段，不如就让它给个扁平的清单。你那个“检查结果”的步骤其实最值得花心思，很多问题都是前面步骤的错被这里放大，我建议这里用单独的Prompt，并且允许它返回“纠错指令”而不是只报错。