智能体设计模式详解 B#1：提示词链 (Prompt Chaining)

Gabriel.YU

443人浏览 · 2026-03-03 20:04:10

Gabriel.YU · 2026-03-03 20:04:10 发布

【全景】基于双向协同的能力融合设计

Agent设计模式 V1：基于双向协同的能力融合设计
- 39种设计模式分层清单
A#0 智能体设计模式全景（上）：大模型如何“思考”？（认知视角导论）
- Agent Design Pattern Catalogue: A Collection of Architectural Patterns for Foundation Model based Agents
- 18种大模型视角设计模式卡片
B#0 智能体设计模式全景（下）：开发者如何“构建”？（工程视角导论）
- Agentic Design Patterns
- 21种Agent工程视角设计模式卡片

【洞察】模式卡译解 #B1：提示词链（Prompt Chaining）

提示词链速查

核心假设：任务可线性分解，子任务间存在明确数据依赖
关键约束：中间输出必须结构化（JSON/Schema），否则静默失败
失败主因：错误静默传播 + 上下文窗口膨胀 + 校验缺失
升级信号：出现条件分支/回溯修正/并行聚合需求时
首选框架：LangChain（线性编排）→ LangGraph（图式状态机）

模式卡片

项目	内容
分类	II. 输入/输出结构化与接口标准化层（Agent工程视角）
意图	将复杂任务拆解为一系列顺序执行的子任务，每个子任务的 LLM 输出经结构化处理后作为下一任务的输入，形成可控、可测试的推理流水线
适用场景	- 多跳问答（如“先查数据，再分析趋势，最后生成报告”）- 需要中间结果校验或人工介入的流程- 提示工程需分阶段优化（如先摘要再翻译）
工作机制	1. 定义任务分解图（DAG 或线性链）2. 为每个子任务设计专用提示模板与输出格式约束3. 执行引擎按序调用 LLM，解析前序输出并注入下一提示4. 支持失败重试、跳过或降级策略
优势	- 将不可靠的端到端生成转化为可靠分步推理- 每步可独立测试、监控与优化- 支持混合人工/自动节点（Human-in-the-Loop）
局限	- 增加延迟与 token 消耗- 错误在链中传播，需健壮的异常处理- 链式依赖限制并行优化空间
典型组合	+ 提示/响应优化器（A#3）+ 异常处理和恢复（B#12）+ 资源感知优化（B#16）
反模式警示	1. 在可单步完成的任务中强行拆链，造成性能浪费2. 未对中间输出做格式校验，导致下游提示注入脏数据

| 伪代码示例 |

chain = [
    {"prompt": "Summarize: {input}", "output_key": "summary"},
    {"prompt": "Translate to French: {summary}", "output_key": "translation"}
]

context = {"input": user_query}
for step in chain:
    response = llm(step["prompt"].format(**context))
    parsed = json_or_regex_parse(response)  # Enforce structure
    context[step["output_key"]] = parsed

final_output = context["translation"]

【原文】第一章：提示链

提示链模式概述

提示链（Prompt Chaining），有时也被称为流水线模式（Pipeline Pattern），是一种在使用大语言模型（LLM）处理复杂任务时极为有效的范式。它摒弃了期望模型通过单一、庞大的提示一次性解决复杂问题的做法，转而采用分而治之的策略：将原始的复杂问题拆解为一系列更小、更易管理的子问题。每个子问题通过专门设计的提示单独处理，前一个提示生成的输出会作为输入传递给链条中的下一个提示。

这种顺序处理方式为与大语言模型的交互引入了模块化与清晰性。通过任务分解，每个步骤更容易被理解与调试，从而使整体流程更加稳健且可解释。链条中的每一步都可以被精细打磨，专注于解决更大问题中的特定环节，从而产生更准确、更聚焦的输出。

前一步骤的输出作为后一步骤的输入，这一机制至关重要。它建立了信息传递的依赖关系，使模型能够在其先前工作的基础上持续构建、深化理解，并逐步逼近理想结果。这种渐进式处理不仅限于任务拆解，还支持与外部知识和工具的集成。在链条的每个环节，模型都可以被指示调用外部系统、API 或数据库，从而突破其内部训练数据的局限，大幅拓展其能力边界。这使得大语言模型不再作为孤立的组件存在，而是成为更广泛智能系统中的有机组成部分。

提示链的意义远超基础问题求解。它是构建复杂 AI 智能体的基石技术。这些智能体可利用提示链自主进行规划、推理与行动，以应对动态环境中的多步骤任务。通过精心设计提示序列，智能体能够执行需要多轮推理、规划与决策的工作流，其行为模式更贴近人类的思维过程，从而在复杂领域中实现更自然、更高效的人机交互。

单一提示的局限性：面对多维度任务，若仅依赖单一复杂提示，模型往往难以兼顾各项约束与指令，容易出现指令忽略（部分提示内容被忽视）、上下文漂移（丢失初始语境）、错误累积（早期错误被放大）、上下文窗口不足（信息不完整导致回应失败）以及幻觉（认知负荷增加导致生成错误信息）等问题。例如，若要求模型分析一份市场研究报告、总结核心发现、识别附带数据支撑的趋势并起草邮件，单一提示很可能导致模型虽能完成总结，却遗漏数据提取或邮件撰写环节。

通过顺序分解提升可靠性：提示链通过将复杂任务转化为聚焦、有序的工作流，显著提升了系统的可靠性与可控性。以上述场景为例，可设计如下链条式处理流程：

初始提示（摘要生成）：“请总结以下市场研究报告的核心发现：[文本]。”模型仅需专注摘要任务，提升该步骤的准确性。
第二提示（趋势识别）：“基于上述摘要，识别三大新兴趋势，并提取支持每项趋势的具体数据点：[步骤1的输出]。”此提示约束更明确，且建立在已验证的输出之上。

第三提示（邮件起草）：“请为市场团队起草一封简明邮件，概述以下趋势及其支撑数据：[步骤2的输出]。”

这种分解方式实现了对流程的细粒度控制。每一步骤更简单、歧义更少，降低了模型的认知负担，从而获得更准确可靠的最终结果。这种模块化思路类似于计算流水线——每个函数执行特定操作后，将结果传递给下一环节。为确保每项任务的精准响应，可在每个阶段为模型分配特定角色。例如，在上述场景中，初始提示可指定角色为“市场分析师”，第二提示为“行业趋势分析师”，第三提示为“专业文案撰写人”等。

结构化输出的关键作用：提示链的可靠性高度依赖于步骤间传递数据的完整性。若某一步骤的输出模糊或格式混乱，后续提示可能因输入错误而失效。为规避此风险，明确指定结构化输出格式（如 JSON 或 XML）至关重要。

例如，趋势识别步骤的输出可格式化为如下 JSON 对象：

{
  "trends": [
    {
      "trend_name": "AI驱动的个性化服务",
      "supporting_data": "73%的消费者倾向于选择能利用个人信息提供更相关购物体验的品牌。"
    },
    {
      "trend_name": "可持续与道德品牌",
      "supporting_data": "过去五年间，带有ESG相关声明的产品销售额增长28%，而无此类声明的产品仅增长20%。"
    }
  ]
}

此类结构化格式确保数据可被机器精准解析，并无歧义地嵌入后续提示中。该实践有效规避了自然语言解析可能引发的错误，是构建稳健多步骤LLM系统的关键要素。

实际应用与用例

提示链是一种高度通用的模式，适用于构建智能体系统的多种场景。其核心价值在于将复杂问题拆解为顺序执行的可管理步骤。以下是若干典型应用：

1. 信息处理工作流：许多任务涉及对原始信息进行多阶段转换。例如，对文档进行摘要、提取关键实体，再利用这些实体查询数据库或生成报告。提示链可设计如下：

提示1：从指定URL或文档中提取文本内容。
提示2：对清洗后的文本进行摘要。
提示3：从摘要或原文中提取特定实体（如人名、日期、地点）。
提示4：利用提取的实体搜索内部知识库。
提示5：整合摘要、实体与搜索结果，生成最终报告。

该方法广泛应用于自动化内容分析、AI驱动的研究助手开发及复杂报告生成等领域。

2. 复杂问题解答：回答需多步推理或信息检索的复杂问题时，提示链尤为适用。例如：“1929年股市崩盘的主要原因是什么？政府政策如何应对？”

提示1：识别用户查询中的核心子问题（崩盘原因、政府应对）。
提示2：专门检索1929年崩盘原因的相关信息。
提示3：专门检索政府对1929年股灾的政策响应信息。
提示4：综合步骤2与3的信息，形成对原始问题的连贯回答。

此类顺序处理方法是构建具备多步推理与信息合成能力AI系统的基础。当问题无法通过单一数据点解答，而需逻辑推导或跨源信息整合时，该模式不可或缺。

例如，一个自动生成专题研究报告的智能体，其工作流通常结合并行与串行处理：系统首先批量检索相关文章，随后可对每篇文章独立进行关键信息提取——此阶段适合并行处理以提升效率。但当所有提取完成后，流程转为串行：系统需先汇总数据，再合成初稿，最后审阅润色。后三个阶段存在逻辑依赖关系，此时提示链发挥作用：汇总数据作为合成提示的输入，合成文本又成为审阅提示的输入。因此，复杂操作常融合并行数据采集与串行合成优化，提示链则主导后者。

3. 数据提取与转换：将非结构化文本转化为结构化数据通常需迭代处理，通过顺序修正提升输出的准确性与完整性。

提示1：尝试从发票文档中提取特定字段（如姓名、地址、金额）。
处理：校验是否提取全部必要字段且符合格式要求。
提示2（条件触发）：若字段缺失或格式错误，构造新提示，引导模型针对性查找缺失/错误信息，可辅以前次尝试的上下文。
处理：再次验证结果，必要时重复迭代。
输出：提供经验证的结构化数据。

该方法特别适用于从表单、发票或邮件等非结构化源中提取与分析数据。例如，处理含手写内容的PDF表单这类复杂的OCR任务，采用分步策略更为可靠：首先用大语言模型执行基础文本提取；随后对原始输出进行数据规范化（如将“一千零五十”转换为数字1050）；鉴于大语言模型在精确计算方面存在局限，下一步可将算术运算委托给外部计算器工具——模型识别计算需求，将规范化后的数字传入工具，再将精确结果整合回输出。这种文本提取→数据规范化→外部工具调用的链式流程，往往比单次查询更易获得准确结果。

4. 内容生成工作流：复杂内容的创作是典型的流程化任务，通常分解为构思、大纲、初稿、修订等阶段。

提示1：基于用户兴趣生成5个主题创意。
处理：由用户选择其一或自动筛选最优主题。
提示2：基于选定主题生成详细大纲。
提示3：依据大纲第一要点撰写初稿段落。
提示4：依据大纲第二要点撰写下一段落，并提供前文以保持连贯性；依此类推完成所有要点。
提示5：通读全文，优化逻辑连贯性、语气与语法。

该方法广泛应用于自动化创作，包括创意叙事、技术文档及其他结构化文本内容的生成。

5. 具状态感知的对话智能体：尽管完整的状态管理架构通常采用比简单串联更复杂的机制，提示链仍为维持对话连续性提供了基础方法。该技术通过将每轮对话构造为新提示，并系统性地融入前序交互中提取的意图与实体，从而保持上下文连贯。

提示1：处理用户首轮发言，识别意图与关键实体。
处理：将意图与实体更新至对话状态。
提示2：基于当前状态生成回应，或识别下一步所需信息。
后续轮次重复此流程，每轮新发言均触发一条利用累积对话历史（状态）的提示链。

该原则是构建多轮对话智能体的基石，使其能在长对话中维持上下文一致性，准确响应依赖历史信息的用户输入。

6. 代码生成与优化：功能性代码的生成通常需经历多阶段处理，将问题分解为一系列离散的逻辑操作并逐步执行。

提示1：理解用户对代码功能的需求，生成伪代码或逻辑大纲。
提示2：基于大纲编写初始代码草案。
提示3：识别代码中的潜在错误或可优化点（可借助静态分析工具或另一次LLM调用）。
提示4：根据识别的问题重写或优化代码。
提示5：补充文档注释或测试用例。

在AI辅助软件开发中，提示链的价值在于将复杂编码任务拆解为可管理的子问题，降低模型在每一步的认知负荷。更重要的是，该方法允许在模型调用之间插入确定性逻辑，实现中间数据处理、输出验证与条件分支，从而将原本易出错的单一复杂请求转化为由执行框架管理的结构化操作序列。

7. 多模态与多步推理：分析包含多种模态的数据集时，需将问题拆解为多个基于提示的子任务。例如，解读一张包含图像、嵌入文本、高亮标注及解释性表格的复合图片：

提示1：从用户提供的图像中提取并理解文本内容。
提示2：将提取的图像文本与其对应标注建立关联。
提示3：结合表格信息解读已收集数据，生成最终输出。

动手实践：代码示例

实现提示链的方式多样，既可采用脚本中的直接顺序函数调用，也可借助专为管理控制流、状态与组件集成而设计的框架。LangChain、LangGraph、Crew AI 与 Google 智能体开发套件（ADK）等框架提供了构建与执行多步骤流程的结构化环境，尤其适用于复杂架构。

为便于演示，LangChain 与 LangGraph 是理想选择：前者提供线性序列的基础抽象，后者则扩展支持具状态与循环计算的能力，这对实现更复杂的智能体行为至关重要。以下示例聚焦于基础线性序列。

该代码实现了一个两步提示链，构成数据处理流水线：第一阶段从非结构化文本中提取特定信息；第二阶段接收提取结果并将其转换为结构化数据格式。

首先安装必要库（可通过以下命令）：

pip install langchain langchain-community langchain-openai langgraph

注：langchain-openai 可根据需要替换为其他模型提供商的对应包。随后需配置执行环境，设置所选语言模型提供商（如 OpenAI、Google Gemini 或 Anthropic）的 API 凭证。

import os
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

## 为提升安全性，可从 .env 文件加载环境变量
## from dotenv import load_dotenv
## load_dotenv()
## 确保 .env 文件中已设置 OPENAI_API_KEY

## 初始化语言模型（推荐使用 ChatOpenAI）
llm = ChatOpenAI(temperature=0)

## --- 步骤1：信息提取 ---
prompt_extract = ChatPromptTemplate.from_template(
    "请从以下文本中提取技术规格信息：\n\n{text_input}"
)

## --- 步骤2：转换为JSON格式 ---
prompt_transform = ChatPromptTemplate.from_template(
    "请将以下规格信息转换为JSON对象，包含'cpu'、'memory'和'storage'三个键：\n\n{specifications}"
)

## --- 使用LCEL构建链条 ---
## StrOutputParser() 将LLM的消息输出转换为纯字符串
extraction_chain = prompt_extract | llm | StrOutputParser()

## 完整链条将提取链的输出传入转换提示的'specifications'变量
full_chain = (
    {"specifications": extraction_chain}
    | prompt_transform
    | llm
    | StrOutputParser()
)

## --- 执行链条 ---
input_text = "新款笔记本电脑配备3.5 GHz八核处理器、16GB内存及1TB NVMe固态硬盘。"

## 以输入文本字典形式执行完整链条
final_result = full_chain.invoke({"text_input": input_text})

print("\n--- 最终JSON输出 ---")
print(final_result)

该Python代码演示了如何使用LangChain库处理文本：通过两个独立提示，先提取技术规格，再将其格式化为JSON对象。ChatOpenAI模型负责语言交互，StrOutputParser确保输出为可用字符串格式。LangChain表达式语言（LCEL）优雅地串联了提示与模型调用：提取链（extraction_chain）完成首轮信息抽取；完整链（full_chain）则将提取结果作为输入传递给转换提示。示例输入为一段笔记本电脑描述文本，执行后输出为包含规格信息的JSON字符串。

上下文工程与提示工程

上下文工程（Context Engineering，见图1）是一门系统性学科，致力于在AI模型生成令牌前，为其设计、构建并交付完整的信息环境。该方法论认为，模型输出的质量更多取决于所提供上下文的丰富程度，而非模型架构本身。

在这里插入图片描述

图1：上下文工程致力于为AI构建丰富、全面的信息环境，此类上下文的质量是实现高级智能体性能的关键因素。

它标志着从传统提示工程的重要演进——后者主要聚焦于优化用户即时查询的措辞。上下文工程则将范围扩展至多层信息：包括系统提示（定义AI操作参数的基础指令，例如“你是一名技术写作者，语气须正式精确”）；外部数据（如从知识库主动检索的文档，用于提供项目技术规格）；工具输出（如调用日历API获取用户实时日程）；以及关键的隐式数据（如用户身份、交互历史与环境状态）。核心原则在于：即便最先进的模型，若被置于信息贫乏或构建不良的操作环境中，其表现也会大打折扣。

因此，该实践将任务重心从“回答问题”重新定义为“为智能体构建完整的操作图景”。例如，一个经过上下文工程优化的智能体在处理邮件请求时，会先整合用户的日历可用性（工具输出）、与收件人的职业关系（隐式数据）以及过往会议记录（检索文档），从而生成高度相关、个性化且实用的回应。“工程”一词体现在需构建稳健的数据获取与转换管道，并建立反馈循环以持续优化上下文质量。

为规模化实现该优化，可借助专用调优系统。例如，Google Vertex AI的提示优化器能通过系统化评估响应质量（基于样本输入与预定义指标），提升模型表现。该方法无需大量手动重写，即可适配不同模型的提示与系统指令：向优化器提供样本提示、系统指令与模板后，它能程序化地精炼上下文输入，为实现高级上下文工程所需的反馈循环提供结构化支持。

这种结构化方法正是区分基础AI工具与高级情境感知系统的关键。它将上下文本身视为核心组件，强调智能体“知晓什么”、“何时知晓”以及“如何运用该知识”。该实践确保模型对用户意图、历史与当前环境形成全面理解。归根结底，上下文工程是推动无状态聊天机器人向高度情境感知系统演进的必要方法论。

一览表

问题所在：复杂任务若交由单一提示处理，常使大语言模型不堪重负，导致性能显著下降。模型认知负荷增加时，易出现指令遗漏、上下文丢失及信息错误等问题。单一提示难以有效管理多重约束与顺序推理步骤，致使输出不可靠、不准确，无法全面应对多维度需求。

解决方案：提示链通过将复杂问题拆解为一系列相互关联的子任务，提供标准化解决路径。链条中每一步均采用聚焦式提示执行特定操作，大幅提升可靠性与可控性。前序输出作为后序输入，形成逻辑连贯的工作流，逐步逼近最终解。这种模块化、分而治之的策略使流程更易管理与调试，并支持步骤间集成外部工具或结构化数据格式。该模式是构建具备多步推理、工具集成与状态管理能力的高级智能体系统的基础。

经验法则：当任务过于复杂难以单次提示完成、涉及多个独立处理阶段、需在步骤间调用外部工具，或需构建具备多步推理与状态保持能力的智能体系统时，应采用此模式。

图示概要：
在这里插入图片描述

图2：提示链模式：智能体接收一系列来自用户的提示，前一个智能体的输出作为下一个智能体的输入，形成链式处理流程。

核心要点：

提示链将复杂任务拆解为一系列更小、更聚焦的顺序步骤，该模式亦称流水线模式。
链条中每一步均涉及一次大语言模型调用或处理逻辑，并将前一步输出作为输入。
该模式显著提升与语言模型交互的可靠性与可管理性。
LangChain/LangGraph、Google ADK 等框架为定义、管理与执行此类多步骤序列提供了强大工具支持。

结语

通过将复杂问题解构为一系列更简单、更易管理的子任务，提示链为引导大语言模型提供了稳健框架。这种“分而治之”的策略通过让模型每次仅专注单一操作，显著提升了输出的可靠性与可控性。作为基础性模式，它使构建具备多步推理、工具集成与状态管理能力的复杂AI智能体成为可能。最终，掌握提示链技术对于开发能够执行超越单一提示能力的复杂工作流、具备高度情境感知能力的稳健系统至关重要。

参考文献

LangChain LCEL文档：https://python.langchain.com/v0.2/docs/core_modules/expression_language/
LangGraph文档：https://langchain-ai.github.io/langgraph/

提示工程指南—提示串联：https://www.promptingguide.ai/techniques/chaining
OpenAI API文档（通用提示概念）：https://platform.openai.com/docs/guides/gpt/prompting

Crew AI文档（任务与流程）：https://docs.crewai.com/
Google AI开发者资源（提示指南）：https://cloud.google.com/discover/what-is-prompt-engineering?hl=en

Vertex提示优化器：https://cloud.google.com/vertex-ai/generative-ai/docs/learn/prompts/prompt-optimizer

【实践】设计 - 评估 - 迭代

设计决策

对比维度	Prompt Chaining	Router Pattern	Parallelization
控制流	严格顺序，前驱→后继	条件分支，意图路由	并发执行，结果聚合
适用任务	依赖前序结果的流水线（如提取→转换→加载）	多意图分类/任务分发（如客服路由）	独立子任务聚合（如多文档摘要）
错误处理	链式传播，需checkpoint/重试机制	分支隔离，失败可fallback至默认路径	部分失败不影响整体，支持容错聚合
典型组合	+ 输出解析器(A#3) + 校验中间件	+ 意图识别器 + 置信度阈值	+ 结果聚合器 + 冲突消解策略

设计决策点

链式 vs 图式：当任务存在if-else分支、循环修正或动态路径选择时，应放弃线性Chain，升级至LangGraph等图式框架
同步 vs 异步：若子任务间无数据依赖（如多源信息检索），应并行执行以降低端到端延迟
强校验 vs 弱校验：关键业务节点必须使用Pydantic/JSON Schema强制约束；探索性步骤可放宽，但需添加validation_prompt兜底

权衡矩阵

可靠性 ↑  ←→  延迟 ↓
可调试性 ↑  ←→  Token成本 ↓
灵活性 ↑  ←→  工程复杂度 ↓

决策原则：优先保障可靠性与可观测性，成本优化置于第二顺位

演进路径

线性Chain 
  → DAG工作流（条件分支/并行） 
  → 状态机Agent（记忆+回溯） 
  → 自主规划Agent（动态生成执行图）

关键洞察：Chain的本质假设是"任务可预先线性分解"。当任务存在运行时条件依赖、用户反馈修正或环境状态变化时，必须向图式/状态机架构演进。

工程陷阱与防御策略

陷阱1：静默失败（Silent Failure）

现象：中间步骤输出"不确定"/“无相关信息”，但未被检测，下游基于空数据继续推理，最终输出看似合理实则空洞

防御：

# 每步增加置信度评分或显式校验
class ValidatedOutput(BaseModel):
    content: str
    confidence_score: float = Field(ge=0, le=1)
    validation_notes: Optional[str] = None

# 或添加独立校验prompt
validation_prompt = "请判断以下输出是否完整回答了问题：{output}。若否，请指出缺失项。"

陷阱2：上下文膨胀（Context Bloat）

现象：Chain超过5-7步后，历史输出累积超出模型context window，导致关键信息被截断或注意力分散
防御：
- 设计"摘要压缩"节点：每N步对中间结果进行语义压缩
- 采用外部Memory：将非关键历史写入Vector DB，按需检索注入
- 使用支持长上下文的模型（但需权衡成本）

陷阱3：调试黑箱（Debugging Blackbox）

现象：5步Chain失败时，难以定位是prompt设计、解析逻辑还是LLM随机性导致
防御：
- 为每步添加trace_id与结构化日志
- 集成LangSmith/Arize等观测平台，可视化执行链路
- 关键节点设置"断点测试"，支持单步回放

代码示例：格式校验

反例：无约束的中间输出

chain = [
    {"prompt": "Extract specs: {text}", "output_key": "specs"},  # 输出可能是自然语言
    {"prompt": "Convert to JSON: {specs}", "output_key": "json"}  # 下游解析失败风险极高
]
# 问题：第一步输出"八核3.5GHz处理器"，第二步LLM无法确定字段映射关系

正例：Schema约束 + 解析Fallback

from pydantic import BaseModel, Field
from langchain.output_parsers import PydanticOutputParser

class Specs(BaseModel):
    cpu: str = Field(description="处理器型号与频率，例：'Intel i7-13700H 3.5GHz'")
    memory: str = Field(description="内存容量，例：'16GB DDR5'")
    storage: str = Field(description="存储配置，例：'1TB NVMe SSD'")

parser = PydanticOutputParser(pydantic_object=Specs)

# 在prompt中注入格式指令
prompt_with_format = prompt_extract + "\n{format_instructions}"
# 使用function calling或JSON mode确保输出结构
# 添加解析异常处理
try:
    parsed = parser.parse(llm_output)
except OutputParserException:
    # fallback：重试或调用校验prompt
    parsed = retry_with_validation(llm_output)

度量与优化指标

指标	测量方法	优化方向
端到端准确率	黄金测试集评估（人工标注+自动校验）	增加中间校验节点；关键步骤引入HITL
单步失败率	日志分析每步exception/解析失败次数	优化prompt模板+输出约束；添加few-shot示例
平均延迟	trace链路timing分析（P50/P99）	并行可独立步骤；缓存高频中间结果
Token成本	统计每步input+output token总量	压缩中间表示；蒸馏小模型处理简单子任务
可调试性	问题定位平均耗时（MTTR）	完善trace日志；提供单步回放工具