📚 喵喵的笔记库

01-Agent编排模式

18分钟阅读

阶段一：Agent 编排 + Prompt 工程 + MCP

第 1-3 周 | 核心目标：Humanizer 升级为对话式改写 Agent + ClawHub Skill 发布

⚠️ v5 变更：阶段扩至 3 周，前 3 天为 Prompt Engineering 独立练习，研发助手移至综合项目阶段

⚠️ LangGraph 使用原则：以 Agent 开发为目标，LangGraph 要学透（能搭生产级 workflow），但自建项目不主动依赖 langchain-core 抽象层 💡 职业提醒：LangGraph 是 Agent 编排的事实标准，面试和工作中大概率会遇到

Day 1-3：Prompt Engineering 独立练习

在写 Agent 之前，先系统化 Prompt 能力。Prompt 是 Agent 每个节点的质量根基。

练习 1：四层体系实验（Day 1）

用 Humanizer 的改写任务做实验对象，每种策略 A/B 对比：

| 层次 | 实验 | 对比维度 | |------|------|----------| | 指令层 | 有角色定义 vs 无角色定义 | 输出风格一致性 | | 上下文层 | 0-shot vs 3-shot vs 5-shot | 改写质量、风格匹配度 | | 推理层 | 无 CoT vs "先分析再改写" | 复杂文本的处理质量 | | 约束层 | 自由输出 vs JSON Schema 约束 | 输出稳定性、可解析性 |

交付物：Prompt 实验笔记（Obsidian），记录每组的输入/输出/评分

练习 2：Structured Output 实战（Day 2）

  • 让 LLM 输出 JSON 格式的改写结果：{rewritten: string, strategy: string, confidence: number}
  • 对比不同模型（GPT-4o / Qwen / Claude）的 Structured Output 稳定性
  • 测试边界情况：超长文本、多语言混合、格式混乱的输入

练习 3：Prompt 模板库搭建（Day 3）

  • 在 Obsidian 建立个人 Prompt 模板库
  • 模板分类：改写类、分析类、结构化提取类、对话类
  • 每个模板记录：适用场景、参数、示例输入/输出、注意事项
  • 这个模板库会在后续所有阶段复用

Day 4-21：Agent 编排 + MCP + 项目实战

Step 1：本阶段资料

| 资料类型 | 具体资料 | 用途 | |----------|---------|------| | 文档 | LangGraph 官方文档和 Academy | ⭐ 学透：状态机、checkpoint、human-in-the-loop、子图 | | 代码 | LangGraph GitHub examples | 从零搭 production-grade workflow | | 代码 | Anthropic Tool Use + Multi-Agent Patterns 笔记本 | 可运行的代码示例 | | 视频 | 吴恩达 Agent 短课系列 | Functions, Tools and Agents with LangChain | | 文章 | 《The Architecture of Agency》by NJ Raman, 2026-04 | 技术深度 | | 源码 | OpenClaw 源码 | 作为 Agent 平台的参照系 | | 教程 | Anthropic Prompt Engineering Interactive Tutorial | 官方交互式教程，30分钟过一遍 | | 指南 | OpenAI Prompt Engineering Guide | 结构化 prompt 方法论 | | 文章 | 《Prompt Patterns for LLM Application Development》| 可复用的 prompt 模式库 | | 规范 | MCP 官方规范（modelcontextprotocol.io）| MCP 三原语：Tools/Resources/Prompts | | 教程 | Anthropic MCP 入门教程 | 官方 GitHub，快速上手 | | 文档 | OpenClaw Skill 开发文档 | Skill 规范和发布流程 | | 工具 | MCP Inspector | MCP 调试 UI | | 文档 | LangChain 文档（LCEL / Tools / Retrievers / Memory）| ⭐ 了解核心抽象，按需使用 | | 文档 | LangSmith 文档 | 全链路 trace + 评估 | | 文档 | LangServe 文档 | FastAPI 部署 |

Step 2：本阶段心智模型

Prompt Engineering 核心模型

心智模型 0：Prompt 质量乘数模型

  • 核心思想：Prompt 质量是 LLM 输出质量的乘数因子。同样一个模型，好的 prompt 和差的 prompt 输出质量可以差 3-5 倍
  • 关键变量：指令清晰度、上下文充分性、输出格式约束、few-shot 示例质量
  • 应用场景：Agent 的每个节点都需要精心设计 prompt——意图识别 prompt、策略选择 prompt、改写执行 prompt、质量评估 prompt
  • 局限性：Prompt 不能弥补模型能力不足；过度复杂的 prompt 可能反而降低效果
  • 相关资料：OpenAI Prompt Engineering Guide、Anthropic Prompt Engineering Interactive Tutorial

Prompt 工程四层体系：

  1. 指令层：清晰的角色定义 + 任务描述 + 输出格式（system prompt 设计）
  2. 上下文层：few-shot 示例 + 相关信息注入（RAG 检索结果、对话历史）
  3. 推理层：chain-of-thought 引导、self-consistency、step-by-step 约束
  4. 约束层：guardrail、output schema（JSON mode）、token budget、禁止事项

Agent 中的 Prompt 设计原则：

  • 每个节点一个独立 prompt，职责单一
  • 节点间的状态传递用结构化格式（JSON），不用自然语言
  • 加上明确的"何时停止"条件，避免 Agent 陷入循环
  • Prompt 版本管理：每次改动都要记录，方便 A/B 对比

心智模型 1：Agent 推理循环模型

  • 核心思想：Agent 的本质是"思考→行动→观察"循环。不同模式的区别在于循环的结构
  • 关键变量：ReAct（边想边做）、Plan-Execute（先规划再执行）、ReWOO（解耦推理和执行）、Reflexion（自我反思迭代）
  • 应用场景：代码审查、数据分析、文档生成、客服、对话式改写
  • 局限性：循环次数越多成本越高；复杂任务容易陷入无限循环
  • 相关资料：LangGraph 文档、Anthropic 笔记本

心智模型 2：多 Agent 通信成本模型

  • 核心思想：多 Agent 不是越多越好。Agent 间的通信成本随数量指数增长
  • 关键变量：Orchestrator-Worker（中心调度）、Hierarchical（层级管理）、Peer-to-Peer（去中心化）
  • 应用场景：大型项目分解、跨领域协作、策略选择 Agent + 执行 Agent
  • 局限性：调试困难，错误传播链路长
  • 相关资料：《The Architecture of Agency》

心智模型 3：MCP 三原语模型（原阶段三，v4 并入）

  • 核心思想：MCP 只有三个原语——Tools（有副作用的动作）、Resources（只读数据）、Prompts（可复用模板）。Agent 需要调用工具，MCP 是工具调用的标准协议
  • 关键变量：Tool 的幂等性、Resource 的缓存策略、Prompt 的参数化程度
  • 应用场景：Agent 工具调用标准化、IDE 集成、OpenClaw Skill
  • 局限性：MCP 只解决"怎么调用"，不解决"调用什么"和"调用的结果怎么用"
  • 相关资料：MCP 官方规范

心智模型 4：MCP 传输层模型（原阶段三，v4 并入）

  • 核心思想：stdio 适合本地开发，Streamable HTTP 适合远程部署
  • 关键变量：传输方式、认证方式（OAuth 2.1 + PKCE vs Bearer API Key）、超时控制
  • 应用场景：本地 IDE 集成 vs 云端多用户服务、Skill 本地开发 → ClawHub 分发
  • 局限性：Streamable HTTP 增加了运维复杂度
  • 相关资料：MCP 规范传输层章节

心智模型 5：LCEL Pipeline 组装模型

  • 核心思想：LangChain 的 LCEL 把复杂流程变成 Runnable 管道，loader | splitter | retriever | prompt | llm | parser 一条链搞定
  • 关键变量：RunnablePassthrough（透传数据）、RunnableLambda（自定义逻辑）、RunnableParallel（并行分支）
  • 应用场景：日志分析 pipeline、postmortem 报告生成、任何多步文本处理流程
  • 局限性：调试不如普通函数直观；过度嵌套 Runnable 可读性差
  • 相关资料：LangChain LCEL 文档

Step 3：本阶段分歧点

分歧 1：ReAct vs Plan-Execute？

  • A 方（ReAct 派）：灵活，边想边做，适合探索性任务
  • B 方（Plan-Execute 派）：有计划性，适合复杂任务，容易监控进度
  • 实践倾向：Humanizer 对话式改写适合 Plan-Execute——先分析文本特征选择策略，再执行改写，最后根据反馈优化
  • 为什么重要：选错模式会导致 Agent 陷入死循环或做出次优决策

分歧 2：LangGraph vs 轻量 SDK？

  • A 方（LangGraph 派）：状态机模型清晰，checkpoint、human-in-the-loop 都有
  • B 方（轻量派）：OpenAI Agents SDK 够用了，LangGraph 太重
  • 实践倾向：Humanizer 需要 checkpoint 保存对话状态、human-in-the-loop 做多轮优化，LangGraph 更合适
  • 为什么重要：复杂度投资要匹配业务需求

分歧 3：MCP vs 自定义 API？（原阶段三，v4 并入）

  • A 方（MCP 派）：MCP 是标准，所有 Agent 平台都支持，一次开发到处用
  • B 方（自定义派）：MCP 增加了协议开销，简单场景直接调 HTTP API 更高效
  • 实践倾向：做 OpenClaw Skill 必须符合 MCP 规范，这样所有 OpenClaw 用户都能用。但 Humanizer 内部的 Agent 工具调用不一定需要 MCP，直接函数调用更高效
  • 为什么重要：标准协议带来复用性，但不是所有工具调用都需要标准化

分歧 4：自然语言 prompt vs 结构化 prompt（JSON/XML）？

  • A 方（自然语言派）：自然语言更灵活，LLM 本来就擅长理解自然语言
  • B 方（结构化派）：JSON/XML 格式的 prompt 输出更稳定、更容易解析、更不容易跑偏
  • 实践倾向：Agent 内部节点间通信用结构化格式（JSON），面向用户的输出用自然语言。混合使用，不极端
  • 为什么重要：Agent 的可靠性很大程度取决于 prompt 输出的稳定性

当前状态：输入文本 → 单次改写 → 输出 目标状态：理解用户意图 → 选择改写策略 → 多轮优化 → 输出最佳结果

  • [ ] 分析 Humanizer 现有改写流程，梳理需要 Agent 化的环节
  • [ ] 设计 Agent 状态机：意图识别 → 策略选择 → 改写执行 → 质量评估 → 用户反馈处理
  • [ ] 用 LangGraph 实现核心流程（至少 3 个节点、2 种工具调用）
  • [ ] 实现用户反馈处理："再自然一点"、"保持专业感"、"太长了缩短"
  • [ ] 加上 step cap（对话轮次上限）和 tool budget（单次改写 token 上限）
  • [ ] 加上超限降级策略：轮次用完时输出当前最佳结果
  • [ ] 部署到 Humanizer，替换现有单次改写接口
  • [ ] 实现 token 消耗追踪和日志记录（用户输入 → Agent 决策 → 最终输出）

MCP 交付物：OpenClaw Skill 发布到 ClawHub

  • [ ] 学习 OpenClaw Skill 开发规范（SKILL.md 格式、工具声明、依赖管理）
  • [ ] 用 TypeScript/Python SDK 构建 MCP Server，实现核心 Tool
  • [ ] 输入验证 + 错误处理（无效输入返回明确错误信息）
  • [ ] 超时控制 + 降级策略
  • [ ] 用 MCP Inspector 测试所有 Tool 和 Resource
  • [ ] 本地 OpenClaw 实例集成测试通过
  • [ ] 提交到 ClawHub，填写 Skill 描述和标签

Step 4.5：💬 AI 教练对话（做任务时用）

Prompt 1：架构设计（开始前）

我要把 Humanizer 从单次改写工具升级为对话式改写 Agent。
当前流程：用户输入文本 → 调 LLM 改写 → 返回结果
目标流程：理解意图 → 选策略 → 多轮优化 → 输出最佳结果

请帮我分析：
1. 这个场景适合 ReAct 还是 Plan-Execute？为什么？
2. Agent 的状态应该包含哪些字段？
3. 哪些节点需要 human-in-the-loop？
不要直接给代码，引导我根据 Humanizer 的业务特点做决策。

Prompt 2：用户反馈设计（设计反馈机制时）

Humanizer 的用户可能说"再自然一点"、"保持专业感"、"太长了缩短"。
请帮我分析：
1. 这些反馈应该怎么映射到 Agent 的具体操作？
2. 怎么避免 Agent 过度迎合用户导致改写质量下降？
3. 需要什么 guardrail 防止改写偏离原文语义？

Prompt 3：Debug（Agent 行为异常时）

我的改写 Agent 在执行时陷入了无限循环，反复微调同一句话。
请帮我诊断：
1. 最可能的原因是什么？
2. step cap 和 tool budget 怎么设？
3. 怎么让 Agent "知道自己改好了"？
不要直接给代码，只做诊断。

Prompt 4：模型提取（完成项目后）

我刚完成了 Humanizer 对话式改写 Agent。
请帮我归纳：
1. 状态机模型相比传统 Agent 循环的优势是什么？
2. checkpoint 在多轮改写场景下有什么具体价值？
3. 如果要让改写满意度提升 20%，最值得优化的环节是哪个？
让我先总结，你再补充。

Step 5：关 AI 自测

关闭所有资料和 AI，纯靠记忆回答。

  1. ReAct 和 Plan-Execute 的核心区别是什么？Humanizer 对话式改写更适合哪个？为什么？
  2. 多 Agent 架构中，通信成本为什么随 Agent 数量指数增长？Humanizer 需要多 Agent 吗？
  3. step cap 设得太低会怎样？太高又会怎样？你怎么为 Humanizer 确定合适的上限？
  4. 如果 Agent 的改写结果偏离原文语义，应该在状态机的哪个环节加 guardrail？
  5. 给 Agent 设计 prompt 时，为什么"明确的停止条件"比"继续优化"更重要？怎么在 prompt 里表达停止条件？
  6. LCEL 的 chain = retriever | prompt | llm | parser 这条管道，如果 retriever 返回空结果，后续步骤会怎样？怎么加 fallback？
  7. LangGraph 的 checkpoint 在 SRE 场景下有什么具体价值？比如排查到一半服务挂了，恢复后怎么继续？

评分：每题 25 分，≥80 分通过。

Step 6：费曼输出 + 信心校准

一句话版本：用 1 句话说清楚"Agent 编排的核心是什么"。 三分钟版本：给不懂技术的同事讲清楚 Humanizer 从"改写工具"变成"改写助手"意味着什么。

信心自评：___/10 分 我最可能在什么地方翻车？（预测 2 周后的薄弱点）

工程化要求

  • [ ] 每轮对话的 token 消耗追踪（记录输入/输出/总消耗）
  • [ ] 对话轮次上限（建议 5 轮）+ 超限降级策略（输出当前最佳结果）
  • [ ] 日志记录（用户输入 → Agent 决策 → 工具调用 → 最终输出）
  • [ ] 超时控制（单轮改写不超过 30s，超时返回上一次结果）
  • [ ] 错误恢复（LLM API 失败时自动重试 1 次，仍失败返回友好提示）

验证指标

| 指标 | 目标值 | 测量方式 | |------|--------|----------| | 改写满意度 | 提升 20%+ | 用户反馈（👍👎）对比 A/B 测试 | | 平均对话轮次 | ≤ 3 轮 | 日志统计 | | 单次改写成本变化 | 不超过原来的 2 倍 | token 消耗追踪 | | 超时/错误率 | < 5% | 日志监控 | | ClawHub Skill 发布 | ✅ 完成 | 发布成功 + MCP Inspector 测试通过 |

关系图谱