Agent里套娃调LLM，Prompt越写越长但效果反而变差，怎么破？

说实话你这问题我太有同感了，我之前做那种需要多轮工具调用的Agent时也栽在同样的坑里。后来我仔细想了一下，感觉核心矛盾在于：单步Prompt追求的是“把话说全”，但串联起来后，模型反而被那些冗余的约束干扰了，它得在“理解你给的复杂规则”和“处理上游输出”之间分心。我现在的做法是给中间步骤做减法，只保留最核心的字段定义和输出JSON的schema，去掉所有角色和few-shot，让模型把注意力全放在“把输入转换成正确结构的SQL”上。另外，格式漂移这事，与其指望Prompt写死，不如在代码层加一个轻量校验和修复逻辑，比如正则抽取出```sql块，或者用一次极简的LLM调用专门做“输出标准化”，把脏格式洗一遍。还有，你提到后一个LLM误解前一个输出，我怀疑是上游生成的SQL里带了多余解释性文字，你可以在传给下游前强制把中间结果截断或序列化成纯数据，别让模型自由发挥。说到底，Agent的稳定性不能全押在Prompt上，它更像一个工程问题，得靠流程控制和数据契约来兜底。你要是试过把Prompt砍到只剩“任务一句话+输出规范”还不行，那可能得看看是不是模型选型的问题了，小模型在这种长链路上确实更容易崩。

Prompt越长模型越容易顾此失彼，试试每个子任务只留必要约束，中间结果用结构化格式硬约束住。

中间步骤别用自然语言传给下一个，直接传结构化JSON，省得模型瞎猜。

拆成多个小Agent各管一段，别让一个Prompt扛所有事，中间用结构化格式传。

这个问题我踩过一模一样的坑，感觉根源不在Prompt写得不够细，而是你把太多职责压给同一个LLM了。每个子任务都塞角色设定、few-shot、边界处理，单看没问题，但串起来之后模型其实是在一堆互相冲突的约束里做取舍，格式漂移几乎是必然的。我现在更倾向于把中间产物结构化，比如SQL生成完直接解析成JSON或者固定字段，后面写总结的LLM只吃干净的结果，不再让它去“理解”上一段自然语言。另外Prompt越长，模型对前面内容的注意力就越稀释，你加的那些“如果xxx就yyy”反而可能被它忽略或者误触发。还有一点值得怀疑：你说的单步测试还行，是不是单步时你只测了理想输入？Agent流程里上游输出稍微带点噪声，下游Prompt没做防御就会崩。我现在会把每个LLM调用的输出schema定死，解析失败就直接重试或者走fallback，而不是指望Prompt能兜住所有情况。

拆成独立小Agent各管一段，中间加个格式校验，比堆长Prompt管用多了。