---
title: "AI Agent 模式解析：Prompt Chaining 提示链"
author: deletexiumu
pubDatetime: 2026-03-14T00:00:00+08:00
featured: false
draft: false
tags:
  - AI Agent
  - AI 编程
  - Claude Code
description: "Prompt Chaining 是 AI Agent 最基础也最实用的流水线模式。本文以开源项目 GSD 为核心案例，拆解 Chain 骨架、Gate 检查点、混合模式嵌套，并提供最小可用模板。"
---

**预计阅读时间：18 分钟**

*Building Effective Agents 模式解析系列（1/6）*

---

## 真实场景引入

用 Claude Code 做过稍大一点项目的人，大概都经历过这种崩溃：你把需求甩给它——"帮我调研一下技术选型，做个方案，然后把代码写了，再跑一下测试"。前面几步还挺像样，到了写代码的时候，它开始遗忘需求里的关键细节，测试阶段更是胡编乱造。

这就是 **context rot**——上下文窗口被前面的对话填满后，模型对后续指令的注意力急剧下降，输出质量断崖式跌落。200k token 的窗口听起来很大，但当调研笔记、方案文档、代码片段全堆在一个会话里，模型的"工作记忆"早就超载了。

一个叫 [GSD（Get Shit Done）](https://github.com/gsd-build/get-shit-done) 的开源项目用了完全不同的思路：同样的任务，它拆成 6 个阶段顺序执行，每个阶段启动独立的上下文窗口，阶段之间用结构化文件传递信息。结果是主窗口始终保持较低负载，质量稳定。

这个"拆成阶段、逐步推进、中间检查"的思路，就是今天要讲的 **Prompt Chaining（提示链）**。

![Prompt Chaining 基本架构](/blog/prompt-chaining-agent-pattern/01-chain-overview.png)

---

## 什么是 Prompt Chaining

Anthropic 在 [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) 中定义了五种 Agentic 工作流模式，Prompt Chaining 排在第一位——它也是最直觉、最容易落地的一种。

**核心定义**：把一个复杂任务拆成固定的顺序步骤，每步是一次独立的 LLM 调用，前一步的输出作为后一步的输入。步骤之间可以插入**检查点（Gate）**做质量把关。

### Gate 的三种类型

Gate 是 Prompt Chaining 区别于"只是调多次 API"的关键。按实现成本从低到高：

| 类型 | 实现方式 | 适用场景 | 示例 |
|------|---------|---------|------|
| **程序化 Gate** | 正则、字数、JSON Schema 校验 | 格式合规性 | 输出必须是合法 JSON；摘要不超过 200 字 |
| **LLM Gate** | 另一次 LLM 调用做语义判断 | 内容质量评估 | "这份计划是否覆盖了所有需求？" |
| **人工 Gate** | 等待用户确认 | 高风险决策 | UAT 验收、方案审批 |

Anthropic 在原文中推荐在步骤间加入 **programmatic checks**（程序化检查）来验证流程是否在轨道上。工程经验也指向同一方向：能用代码校验的就别用 LLM——更快、更便宜、结果确定。

### Prompt Chaining vs Chain-of-Thought (CoT)

这两个名字经常被混淆，但它们在完全不同的层级上工作：

- **CoT** 是**单次调用内的推理技巧**——"请一步步思考"。模型在一次响应中展开推理链条。
- **Prompt Chaining** 是**多次调用间的任务编排**——每步是独立的 API 调用，中间可以插入验证、人工干预、甚至换模型。

两者可以结合：在 Chain 的某个步骤内使用 CoT 提升该步骤的推理质量，同时在步骤之间用 Gate 保证整体流程可控。

### Chaining 的固有优势

这三条是 Prompt Chaining 区别于其他多步模式的核心特征：

1. **固定顺序，流程可预测**：步骤编排在代码里写死，每次执行路径一致，方便做回归测试和审计。
2. **任意步骤可插 Gate，故障定位精确**：哪步的 Gate 挂了，问题就出在哪步——不用在一团意大利面条式的调用日志里翻找。
3. **步骤间接口明确，易于维护**：每步的输入/输出契约清晰定义，改一步不影响其他步。

核心权衡：**用延迟换准确性**。多次调用必然比单次慢，但每步的范围更窄、更可控，最终质量更高。

工程实践中，链式方法在摘要、分类、提取等任务上通常优于单次 prompt——每步的范围更窄，模型的注意力更集中，输出更可控。模型能力越强，chaining 带来的增益越明显。

---

## GSD：以 Prompt Chaining 为骨架的混合工作流

GSD 不是纯粹的 Prompt Chaining——这一点必须先讲清楚。它是以 Chain 为骨架、在局部步骤嵌套其他模式的**混合型系统**。这恰恰说明了现实中 Prompt Chaining 的最佳用法：**做骨架，不做全部**。

### 6 阶段管线全景

```
Initialize → Discuss → Plan → Execute → Verify → Complete
     ↓           ↓         ↓        ↓          ↓         ↓
PROJECT.md  CONTEXT.md  PLAN.md  SUMMARY.md  UAT.md   归档+Tag
```

每个阶段由独立的 subagent 执行，产出固定命名的结构化文件，作为下一阶段的输入。

| 阶段 | 职责 | 产出物 | Gate 类型 | 嵌套模式 |
|------|------|--------|----------|---------|
| **Initialize** | 收集需求 | PROJECT.md, REQUIREMENTS.md, ROADMAP.md | — | — |
| **Discuss** | 澄清灰色地带 | CONTEXT.md | LLM Gate：覆盖所有待决策项 | — |
| **Plan** | 研究 + 规划 | RESEARCH.md, PLAN.md | LLM Gate + 循环：plan-checker 验证 | Evaluator-Optimizer（checker 循环迭代） |
| **Execute** | 波次执行任务 | SUMMARY.md + 原子 Git 提交 | 程序化 Gate：每个 task 的 verify 步骤 | Parallelization（波次并行） |
| **Verify** | UAT 逐项验证 | UAT.md | 人工 Gate：用户确认 | — |
| **Complete** | 归档打 tag | — | — | — |

注意三类 Gate 在这条链上全出现了——Plan 阶段用 LLM 判断计划质量，Execute 阶段用程序跑验证脚本，Verify 阶段等用户拍板。

### Chain 骨架的三个核心价值

以下三点是 **Chain 结构本身**带来的价值，而非"多步工作流"的通用优势。

**1. 上下文隔离——彻底解决 context rot**

GSD 的每个阶段由独立 subagent 执行，各自使用独立的上下文窗口。主窗口只做阶段调度，保持较低的上下文负载。

这之所以可行，是因为 Chain 的**固定顺序**让"每步独立启动新窗口"成为一种自然的设计选择。如果步骤之间需要动态跳转（像 Orchestrator-Workers 那样），你就很难做到干净的窗口隔离——因为你不知道下一步会是什么，也就无法预先决定哪些上下文该保留、哪些该丢弃。

**2. 结构化文件传递——信息不靠记忆，靠文件**

```
PROJECT.md → CONTEXT.md → PLAN.md → SUMMARY.md → UAT.md
```

信息不是在上下文窗口里"记着"，而是写进文件里"存着"。Chain 的线性结构让每步的输入/输出接口可以被精确定义——Initialize 的产出就是 Discuss 的输入，不多不少。

GSD 的文件传递表：

| 文件 | 谁产出 | 谁消费 | 作用 |
|------|--------|--------|------|
| PROJECT.md | Initialize | 所有阶段 | 全局愿景锚点 |
| CONTEXT.md | Discuss | Planner + Researcher | 决策记录 |
| PLAN.md | Plan | Executor | 原子任务清单 |
| SUMMARY.md | Execute | Verifier | 执行结果汇总 |
| STATE.md | 所有阶段 | 所有阶段 | 跨会话状态记忆 |

**3. 故障精确定位——出问题只需回退一步**

线性结构意味着回退成本可控。Plan 质量不行？重跑 Plan 阶段就行，Initialize 和 Discuss 的产出不受影响。

GSD 在 Plan 阶段的实现更进一步：plan-checker 最多迭代 3 轮，超过就停下来等人工介入——这其实是在 Chain 的一个节点上嵌套了 Evaluator-Optimizer 模式，但这种嵌套不影响整条 Chain 的线性骨架。

### 模型选择的灵活性

Chain 的步骤边界让"不同步骤用不同模型"变得自然（虽然这不是 Chaining 独有的优势，任何多步模式都能做到，但 Chain 的固定步骤让选择更直观）。

GSD 提供 quality / balanced / budget 三档配置 profile。通用原则是：**高不确定性、高决策密度的阶段用强模型**（如研究和规划），**结构化、模板化的阶段可以降配**。具体配置因项目而异，不必硬性规定"某步一定用某模型"。

### 混合架构的启示

GSD 的整体骨架是 Prompt Chaining——6 个阶段按固定顺序执行。但在局部：

- Execute 阶段内部用了 **Parallelization**（波次并行执行独立任务）
- 项目初始化阶段的 Research 步骤用了 **Parallelization**（多个研究员并行调研）
- Plan 阶段用了 **Evaluator-Optimizer**（plan-checker 循环迭代）

**现实中的 Agent 系统很少只用一种模式**。Prompt Chaining 最自然的角色就是做骨架——提供可预测的主流程，在需要的节点嵌入其他模式。

![GSD 六道工序流水线](/blog/prompt-chaining-agent-pattern/02-gsd-pipeline.png)

---

## 更多案例 + 最小模板

### Anthropic 原文的两个经典案例

1. **营销文案翻译链**：生成英文营销文案 → Gate 检查品牌一致性 → 翻译为目标语言
2. **文档写作链**：写大纲 → Gate 检查大纲是否满足标准 → 基于大纲写全文

这两个案例的共性是：步骤固定、前后依赖明确、中间可插入质量检查。

### 代码审查管线

一个更贴近开发者日常的例子——CI/CD 集成的代码审查链（参考 [AWS 文档](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-patterns/workflow-for-prompt-chaining.html) 和 [GitHub: ChrisSc/prompt-chaining](https://github.com/ChrisSc/prompt-chaining)，查询日期 2026-03-13）：

```
提取 PR diff → 静态分析 → 安全扫描 → LLM 逻辑审查 → 汇总为 PR comments
```

每步产出结构化 JSON，下一步只消费它需要的字段。

### 最小 Prompt Chain 模板

下面是一个 3 步链的设计模板，展示 Chain 的核心结构。`call_llm` 和 `validate_json` 需要根据你实际使用的 API 来实现。

**步骤表：**

| 步骤 | 职责 | 输入 | 输出 | Gate |
|------|------|------|------|------|
| Step 1: Extract | 从原始文本提取关键信息 | 原始文本 (str) | JSON: `{facts: [...], entities: [...]}` | 程序化：JSON Schema 校验 |
| Step 2: Analyze | 基于提取结果做分析 | Step 1 的 JSON 输出 | JSON: `{summary: str, risk_level: "low"\|"medium"\|"high"}` | LLM Gate：分析是否覆盖所有 facts |
| Step 3: Report | 生成可读报告 | Step 2 的 JSON 输出 | Markdown 报告 | 程序化：字数 > 100 且包含风险等级标题 |

**Python 伪代码：**

```python
import json
from typing import Any

# ---------- 工具函数 ----------
def call_llm(prompt: str, model: str = "YOUR_MODEL_ID") -> str:
    """调用 LLM，返回文本响应（省略具体 API 调用细节）"""
    ...

def validate_json(text: str, schema: dict) -> tuple[bool, Any]:
    """JSON Schema 校验，返回 (是否通过, 解析后的对象或错误信息)"""
    ...

# ---------- Gate 定义 ----------
def programmatic_gate(output: str, schema: dict) -> tuple[bool, Any]:
    """程序化 Gate：JSON Schema 校验"""
    return validate_json(output, schema)

def llm_gate(output: str, criteria: str) -> tuple[bool, str]:
    """LLM Gate：语义质量判断，返回 (是否通过, 判定说明)"""
    verdict = call_llm(
        f"判断以下输出是否满足标准。只回答 PASS 或 FAIL，并给出一句话理由。\n"
        f"标准：{criteria}\n输出：{output}"
    )
    return ("PASS" in verdict.upper(), verdict)

# ---------- 链式执行引擎 ----------
def run_step_with_retry(prompt: str, gate_fn, max_retries: int = 3) -> str:
    """执行单步 + Gate 校验 + 失败重试。gate_fn 统一返回 tuple[bool, str]。"""
    for attempt in range(max_retries):
        output = call_llm(prompt)
        passed, detail = gate_fn(output)
        if passed:
            return output
        print(f"  Gate 未通过 (第 {attempt+1}/{max_retries} 次)，重试...")
        prompt += f"\n\n[上次输出未通过检查：{detail}，请修正]"

    raise RuntimeError(f"步骤在 {max_retries} 次重试后仍未通过 Gate，停止执行。")

# ---------- 主链 ----------
def run_chain(raw_text: str) -> str:
    # Step 1: Extract
    extract_schema = {
        "type": "object",
        "properties": {
            "facts": {"type": "array"},
            "entities": {"type": "array"}
        },
        "required": ["facts", "entities"]
    }
    step1_output = run_step_with_retry(
        prompt=f"从以下文本中提取关键事实和实体，输出 JSON。\n\n{raw_text}",
        gate_fn=lambda out: programmatic_gate(out, extract_schema)
    )

    # Step 2: Analyze
    step2_output = run_step_with_retry(
        prompt=f"基于以下提取结果进行风险分析，输出 JSON 含 summary 和 risk_level 字段。\n\n{step1_output}",
        gate_fn=lambda out: llm_gate(out, f"分析是否覆盖了以下所有事实：{step1_output}")
    )

    # Step 3: Report
    step3_output = run_step_with_retry(
        prompt=f"基于以下分析结果生成 Markdown 报告，必须包含风险等级。\n\n{step2_output}",
        gate_fn=lambda out: (len(out) > 100 and "风险" in out, out)
    )

    return step3_output
```

**几个设计要点：**

- `run_step_with_retry` 是通用的"步骤 + Gate + 重试"执行器，所有步骤共用同一套逻辑。
- Gate 失败时，错误信息被追加到 prompt 中（`[上次输出未通过检查：...]`），引导模型修正——这比单纯重试更有效。
- `max_retries` 是断路器：超过 3 次就停止，避免无限循环烧 token。
- 每步的 `prompt` 只包含它需要的输入（前一步的输出），不携带整条链的历史——这就是上下文隔离。

---

## 怎么设计一条好的 Chain

### 拆分原则

三条硬标准：

1. **每步职责单一**：一步只干一件事。"提取关键信息并做分析"应该拆成两步。
2. **输出可验证**：每步的输出必须能被某种方式检查——哪怕只是"输出长度 > 0"。
3. **Gate 有明确的通过标准**：不是"看起来还行"，而是"JSON 必须包含 facts 和 entities 两个数组"。

一个实用的检验方法：如果你没法用一句话描述某步的职责，它大概率需要继续拆。但也别走另一个极端——10 步以上的链，延迟和成本都会爆炸。

### Gate 设计要点

**优先级**：程序化 > LLM > 人工。每引入一个 LLM Gate 就多一次 API 调用（延迟 + 成本），人工 Gate 更是直接阻塞流程。

**失败处理策略**（从轻到重）：

| 策略 | 适用场景 | GSD 中的例子 |
|------|---------|-------------|
| 重试（附加错误信息） | 格式问题、遗漏字段 | Execute 阶段的 verify 失败后重新执行 |
| 回退到上一步 | 输入质量不足 | — |
| 循环迭代 | 需要反复精炼 | Plan 阶段的 plan-checker 循环（最多 3 轮） |
| 人工介入 | 超出自动化能力 | Verify 阶段启动 debug agent 后仍失败 |

关键原则：**每个 Gate 必须设置断路器**。GSD 的 plan-checker 最多迭代 3 轮，超出就停止。没有断路器的循环 Gate 会烧掉你的 API 额度。

### 步骤间接口设计

每步的输入输出契约需要明确定义。两种做法：

1. **结构化输出**（JSON Schema / XML）：适合程序消费的中间步骤，便于程序化 Gate 校验。
2. **结构化文件**（GSD 的做法）：每阶段产出固定命名的 `.md` 文件，内容有明确的 section 结构。适合需要人工审阅的步骤。

不管用哪种，核心原则是：**前一步的输出只包含后一步需要的信息**。传太多是噪声（干扰模型），传太少是断层（模型无法完成任务）。映射出下一步精确需要的信息，确保只传递那些内容。

### 错误传播与止损

链式结构有一个必须正视的风险：**错误沿链传播**。Step 1 的输出有一个小错误，到 Step 3 可能已经被放大成一个大错误——因为每步都在上一步的基础上工作。

止损层级：

```
Step 1 → [Gate: 拦截格式错误] → Step 2 → [Gate: 拦截语义错误] → Step 3
              ↓ 失败                            ↓ 失败
         重试 (≤3次)                        回退 + 报告
              ↓ 仍失败
         断路: 停止并通知
```

GSD 的做法值得参考：每个 task 完成后立即做一次原子 Git 提交。即使后续步骤出问题，前面的工作成果不会丢失，可以用 `git bisect` 精确定位问题引入点。

### 常见反模式

| 反模式 | 症状 | 药方 |
|--------|------|------|
| **过度拆分** | 10+ 步链，延迟 > 2 分钟，用户等得烦躁 | 合并职责相近的步骤，目标 3-6 步 |
| **Gate 形同虚设** | Gate 总是通过，从没拦截过任何东西 | 用真实的边缘输入测试 Gate，确保它真的会拒绝不合格输出 |
| **步骤间信息丢失** | 后续步骤"不知道"前面步骤的关键信息 | 明确定义输入输出契约；用结构化文件传递（GSD 的方案） |
| **不设断路器** | Gate 失败后无限重试，token 烧到账户清零 | 所有循环 Gate 设置 max_retries |

![错误传播对比：没有检查点 vs 有检查点](/blog/prompt-chaining-agent-pattern/03-error-propagation.png)

---

## 适用场景与模式组合

### Chain 做骨架

当你的主流程是**固定顺序**时，Prompt Chaining 是最自然的骨架选择。在局部节点可以嵌套其他模式：

- **需要加速的步骤**：嵌套 Parallelization。GSD 的 Execute 阶段将独立任务分成波次并行执行，Research 阶段让 4 个研究员同时调研。
- **需要迭代精炼的步骤**：嵌套 Evaluator-Optimizer。GSD 的 Plan 阶段用 plan-checker 做循环评审。
- **需要分类处理的步骤**：嵌套 Routing。客服场景下，先用 Chain 做主流程（接收 → 分类 → 处理 → 回复），在"分类"节点用 Routing 将不同类型的查询导向不同的处理逻辑。

### 不适合做骨架

当子任务**不固定、需要动态决策**时，Chain 的刚性反而是负担。比如：

- 用户需求模糊，不知道要执行几步——用 Orchestrator-Workers，让中央 LLM 动态拆分。
- 任务本身需要反复迭代直到满足标准——用 Evaluator-Optimizer 做主循环。

### 核心判断标准

一句话：**步骤是否固定可预测？**

- 是 → Chain 做骨架，局部嵌套其他模式
- 否 → 考虑 Orchestrator-Workers 或 Evaluator-Optimizer 做骨架

| 场景特征 | 推荐骨架 | 理由 |
|---------|---------|------|
| 步骤固定、顺序明确 | Prompt Chaining | 可预测、可复现、易调试 |
| 子任务动态、数量不确定 | Orchestrator-Workers | 中央调度灵活分配 |
| 核心循环是"生成-评估-改进" | Evaluator-Optimizer | 天然适合迭代场景 |

---

## 结尾

这是 Building Effective Agents 模式解析系列的第一篇。Anthropic 原文定义了五种 Agentic 工作流模式，Prompt Chaining 是最基础、最直觉的一种——但"基础"不意味着简单，GSD 用真实项目证明了一条设计得当的 Chain 能解决 context rot 这样棘手的工程问题。

核心观点只有一句：**Prompt Chaining 适合做固定顺序的骨架；真实系统通常在链的局部嵌套并行和评估循环——GSD 正是这种混合形态。**

**下一步**：拿文中的最小模板试一下。找一个你正在做的任务，拆成 3 步，定义好每步的输入输出和 Gate，跑一遍看效果。模板在"更多案例 + 最小模板"章节。

---

*原文参考：[Anthropic - Building Effective Agents](https://www.anthropic.com/research/building-effective-agents)*
*案例来源：[GSD - Get Shit Done](https://github.com/gsd-build/get-shit-done)*

---

## 相关阅读

- [AI Agent 模式解析：Routing 路由分流](/posts/ai-agent-routing/) — 系列第二篇，讲解如何用分类器将请求分流到不同模型和处理流程