大模型智能体设计模式实战指南：从提示链到架构设计-优快云博客

这篇文章介绍了提示链（Prompt Chaining）设计模式，解释了如何将复杂AI任务拆分为多步流水线，每步由专门提示负责。文章指出单一超长提示词会导致输出混乱、关键信息丢失和调试困难，而提示链模式通过结构化输出和分步处理解决了这些问题。作者提供了使用LangChain的代码示例，并分享了先画流程再写提示、中间结果结构化等实用心法，帮助开发者构建更可控、可维护的AI Agent系统。

前排提示，文末有大模型AGI-优快云独家资料包哦！

So… what’s this series actually about?

欢迎来到《智能体设计模式实战指南》的第一篇。
先说好，这不是那种“看完感觉懂了、写代码发现不会”的 AI 科普，而是给AI应用开发者准备的一套 能直接搬进项目里的 Agent 设计套路。

整个系列围绕一本超硬核的书展开——《Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems》。
作者 Antonio Gulli 把一个现代 Agent 系统拆成了 21 个设计模式：从最基础的提示链、路由、并行、反思、工具使用，到记忆管理、学习与适应、人机协作，再到 A2A 通信、评估监控、探索与发现，基本把“一个 Agent 系统从能跑到跑得稳”的关键结构问题都过了一遍。

在代码层面，这个系列会优先使用 LangChain（示例代码默认基于 LangChain v1.0 接口规范，如果你使用的是其他主版本的LangChain，某些模块路径和调用方式可能会略有差异，请以官方文档为准稍作调整。）作为示例框架——不是别的框架不行，只是出于生态成熟度、文档丰富度和工程落地案例方面考虑，才作此选择：

你在这里看到的大部分代码思路，可以很容易地迁移到你自己的 Tech Stack 里（无论是自研编排、其他 Agent 框架，还是直接基于 LLM SDK 搭建）。

这个博客系列要做的事情，可以简单粗暴地理解为：给这本书加一套“面向一线工程师的实战注解”（没错，就是给各位大佬搬搬砖[手动狗头]）。
本系列目标和受众群体：


这个博客系列
在做什么？
适合谁看？
你能得到什么？
每篇只讲一个设计模式聚焦“解决什么问题 & 何时使用”
用贴近真实业务的案例而不是只翻译玩具示例
配上可运行代码 + 流程图把书里的抽象结构落到工程节点
从“写 Prompt 调模型”升级到“设计 Agent 架构”的开发者/架构师
已经在用大模型但觉得 Agent 部分不好观测/不好调优的团队
想系统性补智能体设计模式但不打算啃 400+ 页英文书的同学
遇到需求时第一反应是先画工作流而不是堆长 Prompt
搞清楚：哪些需求用“提示链 + 路由 + 并行”足够哪些场景必须上记忆 / RAG / 多智能体
在自己的项目里落下一套可观测、可调优、可扩展的 Agent 设计

• 每篇只聚焦一个设计模式，讲清楚它解决什么问题、什么时候该用、什么时候别用
• 不搞纸上谈兵，用尽量贴近真实业务的例子（而不是只翻译一个“帮我写新闻摘要”）
• 配上可以跑的代码和流程图，把书里的抽象结构，落到你项目里的具体节点

如果你大概属于下面这几类人，这个系列会比较对胃口：

• 正在从“写 Prompt 调模型”升级到“设计 Agent 系统架构”的开发者 / 架构师
• 已经在项目里用大模型，但觉得 Agent 这块“有点散、不好观测、不好调优”的团队
• 想系统性补一遍智能体设计模式，但不打算先啃完 400+ 页英文技术书的同学

跟着这个系列往下走，你可以期待的是：

• 遇到需求时，第一反应不再是“我再写个更长一点的提示词”，而是先画出一条工作流
• 知道哪些问题用“提示链 + 路由 + 并行”就足够，哪些场景必须上记忆、RAG 或多智能体
• 能够在自己的项目里落下一套 可观测、可调优、可扩展 的 Agent 设计，而不是一堆一次性脚本

有一说一，最近大家做 Agent，是否多少都有点这种体验：

• 文档、论文看了一堆，上手还是只会“写一个长长的 Prompt 调个模型”
• 框架示例抄了不少，串起来却总感觉像 if-else 拼接脚本

所以这个系列想做的事情很简单：
把书《Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems》里的那些模式，拆成一篇篇“能看懂、能跑起来、能复用”的工程笔记。
这一期，我们就从后面很多模式都会依赖的底座开始——提示链（Prompt Chaining）。

一、为什么“一个超长提示词”撑不起一个靠谱的 Agent？

想象一个常见需求：你有一篇 10 页的产品设计文档，希望 Agent 做这么几件事：

1. 先帮你提取关键需求和约束
1. 再总结成一份 1 页的产品梗概
1. 顺便列出一些潜在风险点和技术挑战

很多人的第一反应是写一个“超级提示词”：

“请你阅读下面的文档，帮我做 1、2、3、4、5、6……（下略两百字）”

如果把这个“脑子一热写了个超长 Prompt”画成一张图，大概是这样：


10 页产品文档
一个超长 Prompt一次性做完提取 + 总结 + 风险分析 + 建议
一坨混在一起的长输出

从结果上看，通常会遇到这几件糟心事：

• 输出里有你要的东西，但结构混乱，很难直接用在后续流程里
• 有些关键点会莫名其妙消失（指令一多，模型就开始“选择性失忆”——上下文腐烂）
• 一旦你想稍微调整一下需求，就得重写整段巨长提示

换句话说，你把所有的复杂度都塞给了同一个 Prompt 和同一次模型调用。
书里的总结其实很朴素：复杂任务 + 单一提示 = 高认知负荷 + 难以控制。
你给模型塞得越多，它越难“既记得住所有事情，又能按你的格式输出”，而你这边的调试成本也会指数级上升。

而提示链模式要做的事，就是把上面那团“糊成一锅”的东西拆开，变成下面这种形态：


10 页产品文档
步骤1：只做信息抽取
步骤2：只管整理成结构化表示
步骤3：只负责生成总结
步骤4：只管做风险分析

这也是提示链模式要解决的第一个现实痛点：

把“不好控制的一大坨任务”，拆成“若干可控的小步骤”，每一步只做一件事。

二、提示链模式到底在干什么？

用一句话概括：提示链（Prompt Chaining）就是把复杂任务拆成一条多步流水线，每一步由一个专门的提示负责，前一步的输出是后一步的输入。

从工程视角看，它至少解决了三类问题：

• 指令管理问题：每个步骤的提示词更短、更聚焦，更容易迭代和调优
• 输出结构问题：通过结构化输出（比如 JSON），让后续步骤不再“读自然语言猜意思”
• 可维护性问题：你可以针对某一小步单独测试、单独替换，而不用动整条链

用一个极简的流程来画，大概是这样：


原始文档
步骤1：抽取核心信息
步骤2：结构化整理成 JSON
步骤3：生成自然语言总结
步骤4：产出行动建议/报告

如果再“工程化”一点，一个稍微保险的版本通常还会长这样：


抽取成功
抽取失败

原始文档
步骤1：信息抽取
步骤2：结构化存储（DB / KV / 向量库）
回退策略：重试 / 降级 / 人工审核
步骤3a：总结报告
步骤3b：风险分析
步骤3c：生成后续任务列表

上面这条图里，有两个小细节很关键：

• 抽取失败不是“悄悄算了”，而是要有明确的回退节点（方便你挂告警、拉人值班）
• 抽取结果一旦结构化存了起来，后面无论要接多少下游 Agent，都可以直接读这份“规格书”，而不是让每个 Agent 各自再读一遍原文档

在原书的 21 个模式里，提示链更像是一个“底层骨架”：
路由、反思、工具使用、规划、多智能体协作……很多模式最后都会“落”在一个更复杂的链条上，只是中间节点不再只是“提示 + 模型调用”，而是可以夹杂工具、记忆、外部系统调用等更多东西。

三、一个从“文档”到“报告”的提示链长什么样？

我们先不用一上来就堆框架 API，先把工程思路讲清楚，再看一段尽量贴近实战的代码片段。

假设现在有一个需求：

输入：一段比较长的产品需求文档
输出：一份结构化的需求表 + 一段高层总结 + 三条风险提示

一个典型的提示链可以这么拆：

1. 步骤一：从文档里抽取关键信息

• 目标：识别“功能需求、非功能需求、约束条件、依赖项”等
• 输出：一个结构化的 JSON 对象

1. 步骤二：基于结构化信息生成高层总结

• 目标：用人话概括“这是个什么东西”
• 输入：上一步的 JSON

1. 步骤三：基于同样的结构化信息分析风险

• 目标：列出可能踩坑的地方
• 输入：仍然是那份 JSON

也就是说，第 1 步负责“从自由文本到结构化数据”，后面的步骤则是在“结构化数据”上做派生任务。
只要第 1 步的输出稳定可靠，后面要加多少分析步骤、换多少种总结风格，基本都不会影响链条前半段。

先给你看一下“反面教材”——很多人一开始会这么写：

long_prompt = f"""你是一个超级智能的文档助手，请阅读下面这份长文档，然后一次性完成以下所有任务：1. 提取所有功能需求2. 总结成一段给老板看的概述3. 列出所有潜在的技术风险4. 顺便给出一些实现建议5. 如果你觉得有必要，还可以补充你认为重要的点文档内容：{doc}"""resp = llm.invoke(long_prompt)print(resp)

看上去很省事，但问题也很明显：

• 结果结构不稳定，每次生成出来都长得不太一样
• 某一块内容缺失时，你很难定位到底是“抽取阶段就漏了”，还是“后面表述时忘了写”
• 想把其中第 3 条“风险分析”单独拿去做 A/B 测试，基本做不到

所以我们换个思路，从一开始就用“提示链”的方式来搭：

from typing import Dict, Anyfrom langchain_openai import ChatOpenAIfrom langchain_core.prompts import ChatPromptTemplatefrom langchain_core.output_parsers import JsonOutputParserllm = ChatOpenAI(model="gpt-4o-mini")  # 你可以替换成自己的模型名称# 步骤1：信息抽取（自由文本 -> JSON）extract_prompt = ChatPromptTemplate.from_template(    """你是一个需求分析助手，请从下面的产品文档中抽取关键信息，并严格按照 JSON 输出：文档内容：{doc}请输出：{{  "functional_requirements": [...],  "non_functional_requirements": [...],  "constraints": [...],  "dependencies": [...]}}""")extraction_chain = extract_prompt | llm | JsonOutputParser()# 步骤2：高层总结summary_prompt = ChatPromptTemplate.from_template(    """你是产品负责人，请基于下面这份结构化需求信息，用面向干系人的口吻生成一段总结：{spec}""")summary_chain = summary_prompt | llm# 步骤3：风险分析risk_prompt = ChatPromptTemplate.from_template(    """你是技术负责人，请基于下面的需求信息，列出 3~5 条最关键的技术/项目风险，并给出简要说明：{spec}""")risk_chain = risk_prompt | llmdef run_with_langchain(doc: str) -> Dict[str, Any]:    """使用 LangChain v1 风格的提示链，把文档变成总结 + 风险分析。"""    # 第一步：抽取结构化需求    spec = extraction_chain.invoke({"doc": doc})    # 第二步 & 第三步：在同一份结构化 spec 上派生不同视角    summary = summary_chain.invoke({"spec": spec})    risks = risk_chain.invoke({"spec": spec})    return {        "spec": spec,        "summary": summary,        "risks": risks,    }

如果你习惯先从“最小可用玩具”开始，可以先写一个完全不用框架、只靠字符串拼接的版本：

from typing import Dict, Anydef call_llm(prompt: str) -> str:    """伪代码：这里换成你自己的 LLM SDK 调用即可"""    ...def step_extract(doc: str) -> Dict[str, Any]:    prompt = f"""你是需求分析助手，请从下面的产品文档中抽取关键信息，并用 JSON 返回：文档内容：{doc}"""    raw = call_llm(prompt)    return json.loads(raw)def step_summary(spec: Dict[str, Any]) -> str:    prompt = f"""你是产品负责人，请基于下面这份结构化需求信息，用面向干系人的口吻生成一段总结：{spec}"""    return call_llm(prompt)def step_risks(spec: Dict[str, Any]) -> str:    prompt = f"""你是技术负责人，请基于下面的需求信息，列出 3~5 条最关键的技术/项目风险，并给出简要说明：{spec}"""    return call_llm(prompt)def run_pipeline(doc: str) -> Dict[str, Any]:    spec = step_extract(doc)    return {        "summary": step_summary(spec),        "risks": step_risks(spec),    }

有了这个“玩具版”之后，你就可以很自然地往里加日志、错误处理、监控等工程特性了，例如：

import logginglogger = logging.getLogger(__name__)def safe_run_pipeline(doc: str) -> Dict[str, Any]:    logger.info("[pipeline] start")    try:        spec = step_extract(doc)        logger.debug("[pipeline] extracted spec: %s", spec)    except Exception as e:        logger.exception("[pipeline] extraction failed")        raise    summary = step_summary(spec)    risks = step_risks(spec)    logger.info("[pipeline] done")    return {"summary": summary, "risks": risks, "spec": spec}

到这里，你已经有了一条 清晰可观测的“提示链骨架”，后面把它换成AutoGen 、CrewAI 或者你自研的编排框架，其实只是“底层执行引擎”变了而已。

这里有几个值得注意的“提示链思维”：

• 抽取 → 结构化 → 多下游任务
只要把第一个“抽取步骤”打磨好，后面可以随时增加“成本估算”“排期建议”等新步骤，而不用重新让模型去“通读全文再想一遍”。
• 每一步都只负责一件清晰的事
抽取步骤不负责“写总结”，写总结的步骤也不负责“再去补充信息”，职责边界清晰。
• 中间结果是“工程友好的格式”
用 JSON 而不是“自然语言段落”，可以让你把这些结果进一步写入数据库、发到前端、在其他 Agent 里复用。