Prompt 链式调用设计：多步推理不是一直把上一步输出拼上去

Prompt 链式调用设计多步推理不是一直把上一步输出拼上去一、当链式 Prompt 变成上下文垃圾堆大模型应用的工程实践中多步推理是最常见的需求之一。一个复杂的问答任务往往需要拆分为多个子任务串联执行。拆分本身是合理的但串联方式却经常出问题。最常见的做法是每一步的输出直接拼接到下一步的 Prompt 里。三步之后Prompt 膨胀到数千 Token。五步之后模型开始遗忘最初的指令。十步之后幻觉率明显上升。这不是模型的问题是架构设计的问题。把所有的中间推理都塞进上下文窗口相当于让模型在噪音中寻找信号。上下文窗口越大信噪比越低。这违背了 Prompt Engineering 的核心原则精准、简洁、可验证。多步推理的本质不是信息的线性堆叠而是状态的结构化传递。每一步需要的往往只是上一步的结论而不是完整的推理过程。把计算过程留在外部把决策结果传给模型——这是链式调用设计的第一性原理。二、链式调用的信息传递模型链式 Prompt 调用的核心矛盾在于上下文长度与推理质量的负相关关系。每多一个 Token模型注意力就会被稀释一点。graph TD A[用户输入] -- B{任务路由器} B -- C1[步骤1: 意图识别] C1 -- D1[状态对象: intent confidence] B -- C2[步骤2: 信息检索] C2 -- D2[状态对象: docs relevance_score] B -- C3[步骤3: 推理合成] C3 -- D3[状态对象: reasoning evidence] D1 -- E{状态聚合器} D2 -- E D3 -- E E -- F[结构化上下文注入] F -- G[最终生成]上图展示的是一个信息传递模型每一步的输出不是原始文本而是结构化的状态对象。状态聚合器负责筛选、压缩、格式化这些状态然后将精简后的信息注入最终生成阶段。这跟函数的输入输出设计是同一个逻辑。写代码时不会把中间变量全部传给下一个函数而是将必要的参数传递下去。链式 Prompt 调用也应该遵循同样的原则定义清晰的输入输出接口避免信息泄露。见证奇迹的时刻在于当信息从全文拼接改为状态传递后Prompt 长度可以压缩 60% 到 80%而推理准确率反而提升。因为模型看到的都是精选后的有效信息注意力不会被无关内容分散。三、状态化链式调用的代码实现下面是一个状态化链式调用的实现框架核心设计是ChainState类。from dataclasses import dataclass, field from typing import Any, Dict, List, Optional import json dataclass class ChainState: 链式调用的状态容器 设计原因用结构化对象替代文本拼接保证每一步只传递必要的决策信息。 每个字段都是精选的关键结论而不是完整的推理过程。 intent: Optional[str] None confidence: float 0.0 entities: List[str] field(default_factorylist) retrieved_docs: List[Dict[str, Any]] field(default_factorylist) reasoning_steps: List[str] field(default_factorylist) final_answer: Optional[str] None def to_prompt_context(self) - str: 将状态转换为精简的 Prompt 上下文 设计原因只提取对下一步有用的关键字段过滤中间推理过程。 输出格式要简洁减少 Token 消耗。 context_parts [] if self.intent: context_parts.append(f意图: {self.intent} (置信度: {self.confidence:.2f})) if self.entities: context_parts.append(f关键实体: {, .join(self.entities[:5])}) if self.retrieved_docs: # 只传递最相关的文档摘要而不是全文 summaries [ f- {doc.get(title, )}: {doc.get(summary, )[:100]} for doc in self.retrieved_docs[:3] ] context_parts.append(f相关信息:\n \n.join(summaries)) return \n.join(context_parts) def merge(self, other: ChainState) - ChainState: 合并两个状态 设计原因多分支推理时需要合并不同路径的结果。 不会简单拼接而是按优先级和置信度选择。 merged ChainState() merged.intent self.intent or other.intent merged.confidence max(self.confidence, other.confidence) merged.entities list(set(self.entities other.entities)) # 按相关性分数合并文档去重 seen_titles set() merged.retrieved_docs [] for doc in self.retrieved_docs other.retrieved_docs: title doc.get(title, ) if title not in seen_titles: seen_titles.add(title) merged.retrieved_docs.append(doc) # 步骤按时间线拼接 merged.reasoning_steps self.reasoning_steps other.reasoning_steps return merged class ChainExecutor: 链式调用执行器 设计原因统一管理多步推理的执行流程支持分支、回退和状态追踪。 def __init__(self, model: Any, max_steps: int 10): self.model model self.max_steps max_steps self.state ChainState() def run(self, query: str) - str: steps [self._intent_recognition, self._entity_extraction, self._knowledge_retrieval, self._reasoning, self._generate] for i, step_fn in enumerate(steps): if i self.max_steps: break try: # 每个步骤只接收精简的状态上下文 context self.state.to_prompt_context() prompt step_fn.prompt_template.format( queryquery, contextcontext ) result self.model.generate(prompt) step_fn.post_process(self.state, result) except Exception as e: # 失败时记录但不中断后续步骤可降级处理 self.state.reasoning_steps.append(f[步骤{i}异常: {str(e)}]) return self.state.final_answer or 无法完成推理这个实现的核心理念是状态对象是外部记忆Prompt 只是指令通道。每一步的推理过程留在 Python 代码里只把结构化结论注入到 Prompt 中。这样做的好处有三个Token 消耗可控、中间结果可审计、出错时可精确定位。四、状态传递 vs 全文拼接的 Trade-off 分析两种方案的选择没有绝对的对错取决于具体场景的需求。以下是对比分析维度状态传递模式全文拼接模式Token 消耗低线性增长高指数级或累加增长推理准确性高噪音少随步骤增加而下降实现复杂度高需定义状态结构低直接字符串拼接可调试性强状态可单独检查弱上下文过长难以排查中间信息保留可能丢失细节完整保留但冗余选择建议步骤数 ≤ 3 且每步输出简短≤ 200 Token时全文拼接的实现成本最低效果也可接受。步骤数 ≥ 5 或涉及长文档检索时状态传递模式是必须的否则推理质量会断崖式下降。混合模式是最佳实践核心推理路径用状态传递旁路验证用全文拼接做交叉检查。见证奇迹的时刻在于认识到不是所有信息都值得传给模型。删掉的信息有时比保留的信息更有价值因为它减少了干扰。这跟搜索里的减少召回数量反而提升精确率是同一个道理。五、总结多步推理的链式调用设计关键不在于怎么拼接 Prompt而在于定义每一步的信息接口。状态化传递模式将中间推理保留在外部系统中只将必要的结构化结论注入 Prompt可以在控制 Token 消耗的同时提升推理质量。实现时需要注意状态对象的字段设计、合并策略和异常回退机制。当链式步骤超过三步时建议从全文拼接切换到状态传递模式同时在关键步骤保留交叉验证逻辑防止关键信息在压缩传递过程中丢失。