Agentic Design Patterns 第一章笔记
Agentic Design Patterns
AI Agent 这几个月被吹得神乎其神，让我看看到底怎么个事！
书是 Antonio Gulli 的 Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems，21 章 + 7 个附录。配套代码在 evoiz/Agentic-Design-Patterns。
Prompt Chaining
又名 Pipeline pattern。核心一句话：把复杂任务拆成顺序步骤，每步一个聚焦的 prompt，上一步的输出喂给下一步。
单 prompt 为什么不行
书里列了五种失效模式：
| 失效模式 | 含义 |
|---|---|
| Instruction neglect | 指令被漏执行 |
| Contextual drift | 丢掉最初上下文，跑偏 |
| Error propagation | 早期错误在后续被放大 |
| 上下文窗口不够 | 信息塞不下 |
| Hallucination | 认知负载升高，编造概率上升 |
例子：一个 prompt 里同时要求「分析市场报告 + 总结 + 提取趋势和数据点 + 起草邮件」，模型可能总结得不错，但数据没提、邮件写砸。
拆成链
① 总结关键发现 → ② 基于摘要找前三趋势 + 支撑数据点 → ③ 基于趋势起草邮件。每步可赋予不同角色（Market Analyst / Trade Analyst / Writer）。
每步更简单、更少歧义，模型认知负载下降 —— 这是书的说法。
其实我不理解 prompt 里主动要求任务分解 + 拆解，和不要求有什么区别，如果都是通过 LM 注意力机制，有没有又有什么区别呢，prompt 的质量确实能影响结果的好坏，但到底是怎么影响的呢？
区别不在「prompt 里写不写拆解」—— 在同一个 prompt 里让模型自己分步，和干脆不写，效果差别不大。真正的区别是拆成多次独立的调用：每次调用的上下文更短、约束更单一，模型不必同时兼顾五件事。书的例子其实是后者，但它没有把这个区别讲透。
结构化输出
步骤之间用 JSON/XML 传递，保证下游能精确解析。
注意书的原话是 “minimizes errors that arise from interpreting natural language” —— 它管的是传输格式，不是内容真假。
让 LLM 生成结构化输出，确实对构建自动化/Agent 系统是有帮助的，但能保障结果的正确性吗？Agent 系统会因为幻觉而失败吗？MCP 的提出能保证完全避免幻觉导致非结构化的输出吗？
不能。JSON 格式合法 ≠ 内容正确，字段里照样可以是编的。MCP 是工具调用协议，跟幻觉没有关系。
书里点出、但容易被忽略的一点
链真正的价值之一，是能在模型调用之间插入确定性逻辑 —— 校验输出、条件分支、调外部工具。比如精确算术交给计算器，而不是让 LLM 自己算。
应用场景
- 信息处理工作流：抓取 → 总结 → 抽实体 → 查知识库 → 出报告
- 复杂问答：拆子问题 → 分别检索 → 综合
- 数据抽取转换：发票字段抽取，缺字段就条件性再补一轮
- 内容生成：选题 → 大纲 → 逐节起草 → 润色
- 有状态对话：把累积的实体/状态构造进新 prompt
- 代码生成精修：伪码 → 草稿 → 检错 → 重写 → 文档/测试
- 多模态多步推理：图里文字 → 关联标签 → 查表得结论
书里的自动化研究 Agent 是混合的：检索 + 抽取并发跑，整合 → 综合 → 审查串行跑。
好像都是计划和执行的结合，抛开 LLM Agent，传统编程/人去做这些任务也几乎是这样做的，有什么区别呢？LM 是速度更快还是处理能力更强？目前的 Agent 系统真的发挥了其智能的优势吗？
这一章没有回答。拆步骤、传结构化数据、插确定性逻辑 —— 这些传统工程早就在做。LLM 带来的增量是每步可以做模糊的语义操作（总结、抽取、判断），而不是「会规划」。书把这些包装成「智能」，但本章讲的其实是工程约束，不是智能。
上下文工程和提示工程
（本章最后一节。）
Context Engineering 的定义：在生成 token 之前，系统性地设计、构造、投递一个完整的信息环境给模型。它断言：输出质量更少取决于模型架构本身，更多取决于所提供上下文的丰富度。
- 系统提示词：定义 AI 操作参数的基础指令（如「你是一名技术作家，语气需正式精确」）
- 外部数据集成
- 检索文档：AI 主动从知识库获取信息（如提取项目技术规格）
- 工具输出：通过 API 获取实时数据（如查询日历确定用户空闲时间）
- 隐式数据融合：结合用户身份、交互历史和环境状态等关键信息
核心原则：即使高级模型，在有限或不良构建的操作环境下也会表现不佳。
表现不佳，LM 参数够大，训练的数据够好，表现会差到哪里去呢？在我看来
参数大 ≠ 知道你的上下文。模型再强，也看不到你的代码库、你的历史决策、你此刻的环境。上下文工程解决的正是这个：不是让模型变聪明，而是把模型不知道的东西喂给它。「提示工程」管怎么说，「上下文工程」管给什么 —— 书里说后者的工程部分在于「运行时抓取、转换数据的健壮管道 + 持续改善上下文质量的反馈回路」。
小结
- 是什么：单 prompt 处理复杂任务会压垮模型（漏指令、丢上下文、编造）
- 为什么：拆成互相连接的小步骤，每步聚焦一个操作，更可靠、更好调试
- 什么时候用：任务对一个 prompt 太复杂 / 有多个独立处理阶段 / 步骤间要调外部工具 / 要多步推理并维护状态
- LangChain/LangGraph、Google ADK 提供现成的链式编排工具
一句话：第一、三章之前的这个模式，本质是「分而治之 + 步骤间接确定性逻辑」。它不神秘，但确实是把 LLM 塞进可靠系统的基本手段。