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

全局提示词定基调，步骤里只写增量指令就行，不然改哪都崩。

调试时做个输出对比表，改一步看全链路，别靠感觉调。

我最近也在弄类似的，试下来感觉全局系统提示词还是得有，但别管太细，就定人设和输出风格，具体步骤的格式要求放各自Prompt里会清爽不少。你那个规划阶段和选工具阶段格式冲突的问题，我一般会在全局里写“所有输出必须用JSON”，然后每个步骤只补充额外字段，这样至少不会各说各话。调试的话我习惯先用固定输入跑一遍全流程，把每步输出存下来对比，改一个Prompt就重跑一次，慢慢就能看出是哪一步影响了后面，不然真的会改到怀疑人生。

我觉得你这个问题其实挺典型的，很多人在搭Agent的时候都会掉进“拆解”的坑里。我个人经验是，全局的系统提示词一定要有，它相当于给整个Agent定了个“人格”和底层规则，比如输出语气、工具使用边界、错误处理逻辑，这些如果每个步骤都重复写，不仅冗余，而且很容易出现前后矛盾。步骤Prompt只写增量指令，比如规划阶段只要求输出“目标拆解清单”，选工具阶段就只说“基于清单匹配合适工具”，这样上下文靠变量传递，反而更干净。

但你提到的“改一个步骤影响另一个”的现象，我猜大概率是全局提示词里塞了太多和当前步骤无关的约束，导致模型在不同阶段对同一规则的权重理解不一样。我调试的时候习惯把每个步骤的输入输出样例固定下来，做成几个测试用例，每次改Prompt就跑一遍全流程，看哪个环节开始跑偏。另外，你可以试试在规划阶段就让模型顺便输出“每个步骤需要的工具类型”，这样选工具阶段就不用重新解析格式，直接做映射就行。

还有一个思路是，别把步骤切得太死，有些时候“规划”和“选工具”其实可以合并成一个Prompt，让模型一次性输出“任务+工具+参数草案”，然后检查阶段再细拆。这样减少一次上下文切换，连贯性会好很多，调试起来也少一个变量。不过这个也看你的任务复杂度，如果工具特别多，可能还是得分开。你现在这四个步骤里，哪个步骤的输出最不稳定？

我最近也在搞类似的agent，你说的这个痛点太真实了。我现在的做法是搞一个全局的system prompt，把任务背景、工具列表、输出规范全放进去，然后每个步骤的prompt只写“基于当前状态，你要做什么”这种增量指令，这样至少不会出现规划格式和选工具格式打架的情况。但说实话，全局prompt写太长也有问题，模型容易把后面的指令权重降低，所以我现在还在试到底哪些信息该全局，哪些该局部传递。调试的话，我建议你给每个步骤单独做日志，把输入输出都打出来，然后每次只改一个prompt，跑同一组测试用例对比结果，不然真的没法定位是哪里把链路带偏了。另外你提到改一个步骤影响另一个，我猜可能是上下文里保留了太多历史信息，试试每次只传必要变量，把之前的中间结果截断一下，也许能缓解。还有个疑问，你检查结果那步是让模型自己判断要不要重试吗？这个环节我觉得最不好调，容易死循环。

全局提示词必须留一份，步骤里只写增量指令，不然改一处全崩。调试就用单步快照对比输入输出，省心很多。

全局提示词定调子，步骤里只写增量指令，调试时用固定测试用例回归，别靠感觉调。

我最近也在搞类似的，试过全局系统提示词统管风格，但发现模型很容易被全局约束带偏，反而局部步骤的灵活性没了。现在改成每个步骤只带必要的上下文变量，风格统一靠步骤间的输出格式强约束。

调试的话，我习惯给每个步骤单独录输入输出日志，改完一个Prompt就只回放那一步的样本，看它跟上下游的衔接是否自然。你那个“规划→选工具”的格式重复问题，其实可以在规划步骤的输出schema里直接嵌套选工具的字段，让下一步直接解析，不用重新解释。

我最近也在搞类似的，试下来感觉全局系统提示词还是得有一个，但别管太细，就定风格和边界，步骤里只写增量指令，不然每步都重复解释太蠢了。调试的话，我会给每步单独做几个固定用例跑，先保证单步稳定再串起来，不然互相影响根本定位不到问题。另外你那个参数生成和检查结果其实可以合并成一个Prompt，让模型自己纠错，省一轮交互，你可以试试。

我自己的做法是分两层，最外层放一个总纲，把工具列表、输出规范、错误处理都写清楚，内部步骤的Prompt就只写“这一步要干嘛+上一步的什么数据”，相当于总纲是数据库，步骤是查询语句。调试的话，建议每步都打印完整上下文，我经常发现问题是上一步的输出格式没严格按prompt来，而不是下一步的指令写得不好。

我倒是觉得碎片化本身不是问题，关键是每个Prompt里都得带上一个“状态摘要”，把前几步的关键结果用统一格式塞进去，这样模型不用猜。调试的话，我习惯用对比法，改一个步骤后跑同一组测试用例，看输出差异集中在哪，这样能快速定位是哪个Prompt的改动影响了全局，比瞎调省力多了。

我最近也在搞类似的Agent，试下来觉得全局系统提示词还是得留一份，专门定调子和约定通用规则，步骤里只写差异化的增量指令，不然每步都在重复解释确实很割裂。调试的话，我习惯把每步的输入输出都打日志，改一个地方就固定其他变量，不然根本分不清是谁引起的波动。还有个坑是步骤间传递的上下文别一股脑全塞，最好做个精简摘要，不然越往后prompt越长，模型反而抓不住重点。

我自己的经验是别把四个步骤的prompt完全独立，全局风格统一一下，但每步的格式要求可以单独写，甚至用上一步输出的schema来约束下一步，这样能省掉重复解释。调试这种多轮prompt，我一般会先拿几个固定case跑，改哪步就看哪步的输出，同时把前一步的结果缓存下来，方便对比，不然真的调不动。

这种问题我碰到过，建议把prompt拆成两半：一个全局的交代角色、目标和共同约束，另一个每步只写“这一步你要做什么”和“输出长什么样”。格式定义那块可以抽出来做个公共模板，用变量填，不用重写。调试的话，我会给每步加个“预期输出检查点”，改完一步就单独验证那步，别一上来就跑全流程，不然问题根本定位不准。

全局系统提示词必须留，风格和格式归它管，步骤里只写增量指令，不然改起来全崩。

调试可以给每步固定输入输出样例，像单元测试那样跑，哪步坏了改哪步，别靠感觉调。

全局提示词管风格确实省心，步骤里只写增量能少很多重复解释。调试的话建议先固定别的步骤，单测一个环节，不然牵一发动全身太正常了。

说实话你这个问题我太有同感了，之前搭工具调用类Agent时也被这个搞到崩溃。我现在的做法是反过来，全局系统提示词只定死一件事：所有步骤共享的“输出规范”，比如JSON结构里必须带step_id和confidence字段，这样各步骤之间传递变量时就不用反复解释格式。至于每个步骤的Prompt，我倾向于只写增量指令，比如规划阶段输出“意图+候选工具”，选工具阶段就直接引用上一步的意图字段，不再重复描述任务背景，这样冗余会少很多。调试的话，我建议你给每个步骤单独准备一套固定输入样例，改动某个Prompt后只跑对应步骤的回归测试，别每次全流程跑，不然你会分不清是哪个环节影响了最终结果。另外你提到的“改一个步骤影响另一个步骤”，我怀疑是变量传递时隐式依赖了Prompt里的措辞，比如规划阶段要求输出“工具列表”，选工具阶段又用了“可用工具”这个词，模型就会飘，最好把字段名统一成完全一样的字符串。还有个偏门技巧，可以在每个步骤的Prompt末尾加一句“以上是上下文，请直接输出结果”，能减少模型在步骤间重复解释的欲望，你可以试试看。

我最近也在搞类似的，试下来感觉全局系统提示词还是得留一个，但别写太死，主要定语气和输出规范，具体步骤的增量指令里再去强调格式。调试的话，我习惯给每步的输入输出都打个日志，改完一个Prompt就固定其他步骤的输入样例跑一遍回归，不然真的牵一发动全身。另外你可以试试把后一步需要的关键字段名统一命名，规划阶段就要求模型输出带特定标签，这样后面不用重复解释，会清爽不少。

全局系统提示词定风格，步骤只写增量指令，不然改一处崩全局太正常了。

调试的话建议固定其他步骤只调一个，变量隔离了才能定位问题。

说实话我之前也踩过这个坑，后来发现全局系统提示词还是要有的，但别管太细，就定语气、输出规范和工具列表，每个步骤的Prompt只写“这一步要干嘛”和“上一步结果怎么用”，这样改起来不会牵一发动全身。调试的话建议固定住其他步骤的输入，一次只调一个环节，拿几个典型case反复跑，不然变量太多你根本不知道是哪句话影响了后面。另外你提到的冗余问题，试试在每个步骤Prompt里只放必要的历史摘要，别把完整对话全塞进去，模型反而更听话。

我觉得全局系统提示词还是得有，但不一定管太死，主要是定语气和输出约束，步骤里只放增量逻辑会清爽很多。调试这种多轮Prompt，我习惯每个步骤先固定住其他环节的输入输出，单独测一个模块，不然变量一多真的无从下手。另外你那个“规划→选工具”的冗余，可以试试规划阶段就把工具列表和参数schema一起喂进去，让模型直接输出结构化动作，省掉中间一步的转换。

我自己的经验是步骤之间别靠“重新解释”来衔接，而是用代码逻辑去拼接上下文，比如前一步的输出直接作为后一步的system或user的一部分，这样改起来更可控。至于格式问题，与其在多个Prompt里重复写，不如抽一个公共的format指令拼到每个步骤后面，改一处全生效。

我之前也踩过这个坑，后来发现全局系统提示词比想象中重要得多。你那种四个步骤的拆法其实没问题，但每个子Prompt里都重复描述工具规范、输出格式这些底层约束，反而会让模型在切换上下文时产生混淆。我现在是让系统提示词固定住“你是谁、你有哪些工具、你回答问题的通用风格”，然后把每个步骤的Prompt压缩成只包含“当前阶段目标、输入变量、期望输出字段”的增量指令，连贯性会好很多。调试的话，建议你给每个步骤的输入输出都加个缓存日志，改完某个环节后对比一下前后两轮的中间状态，很多问题其实是上游生成了不符合下游预期的结构，而不是Prompt本身写得不好。另外我有个疑问，你检查结果那一步是让模型自己判断重试，还是直接交给代码逻辑去验证？这个如果混在Prompt里，很容易出现模型为了迎合指令而假装成功的情况，我后来改成硬校验才稳下来。

我最近也在搞类似的，试下来感觉全局系统提示词还是得留一个，把工具定义、输出格式这些公共约束放进去，步骤里只写“这一步要干嘛”确实会清爽很多。不过你说的改一个步骤影响另一个，我猜多半是变量传递时格式没对齐，建议每步输出都强约束成JSON，调试时先打印原始返回看看。多轮调试我一般就拿三个典型case反复跑，改一步就全量回归一遍，虽然慢但至少能知道是哪次改动引入的。

我之前搞类似的多步agent也踩过这坑，建议还是得有个全局提示词把风格和公共格式定死，每步只写增量，不然改起来太折磨了。调试的话，我习惯给每一步都打个日志，把输入输出存下来，出问题就回放看是哪一步开始跑偏的，比盲改强很多。

其实你那个“规划→选工具→生成参数”的拆法没问题，但关键是得让每个步骤的prompt都明确“你只需要做X，别管Y”，不然模型老爱越权。另外可以试试让前一步直接输出后一步需要的结构，省得中间还要转换。

全局系统提示词确实该有，不然每个步骤都在重复解释规则，改起来还容易牵一发动全身。

调试的话建议先把输出格式固定成JSON，再单独调每个步骤的指令，能省不少心。