附录 B：模式选择指南
面对一个真实需求时，该用哪个模式？这份指南帮你快速决策。原则贯穿全书：能简单就别复杂，能单 Agent 就别多 Agent。
决策一：要不要上 Agent？
先问最根本的问题——这事真的需要 Agent 吗？
- 一次 LLM 调用能解决（翻译、改写、分类）→ 不需要 Agent，直接调模型。
- 需要调用外部工具、多步骤、看结果再决定 → 需要 Agent（第 1 章）。
- 只是固定流程的自动化，步骤完全确定 → 考虑普通脚本，Agent 的不确定性反而是负担。
Agent 的价值在“自主决策”。流程越确定，越不需要 Agent。
决策二：单 Agent 还是多 Agent？
| 情况 | 选择 |
|---|---|
| 职责单一、上下文装得下 | 单 Agent（Part 1–4） |
| 职责很杂、一个 prompt 塞不下多个角色 | 多 Agent |
| 上下文会被大量子任务塞爆 | 多 Agent（隔离上下文） |
| 需要独立视角（生成者 vs 批评者） | 多 Agent |
| 能单 Agent 解决 | 就用单 Agent——多 Agent 成本/复杂度高得多 |
决策三：单 Agent 用哪个增强？
- 复杂任务、易遗漏步骤 → Planning 规划（第 13 章）
- 输出容易出错、需要纠正 → Reflection 反思（第 14 章），优先用真实反馈
- 复杂推理、算数/逻辑 → Chain-of-Thought（第 15 章）或推理模型
- 需要探索多种方案、会走进死路 → Tree-of-Thoughts（第 20 章，很贵）
决策四：多 Agent 用哪种编排？
| 任务特征 | 模式 | 章节 |
|---|---|---|
| 结构清晰、有中心协调 | Supervisor（主管） | 第 16 章 |
| 任务间有明确依赖、要并行 | DAG 工作流 | 第 17 章 |
| 开放/对话式、流程无法预排 | Swarm（去中心交接） | 第 18 章 |
| 有明确对错、要提升可靠性 | Debate（辩论） | 第 21 章 |
| 又广又深的调研 | Research-Synthesis | 第 22 章 |
一句话记忆：结构化任务 → 主管/DAG；动态任务 → Swarm；要可靠 → Debate；要调研 → Research-Synthesis。
决策五：工具、技能还是扩展？
pi 里三个扩展面容易混，按“你要注入什么”选：
| 你要… | 用 | 章节 |
|---|---|---|
| 给 Agent 一个原子动作能力 | Tool 工具 | 第 4 章 |
| 接入别人做好的通用能力 | MCP | 第 5 章 |
| 封装一套领域工作流/方法论 | Skill 技能 | 第 7 章 |
| 注入规则、拦截、控制循环 | Extension/Hook 扩展 | 第 8 章 |
记忆口诀：Tool = 动作，MCP = 接现成，Skill = 工作流，Hook = 控制点。
决策六：上下文与记忆怎么管？
先把四个概念分清。它们经常被混用，但在 pi 这种 harness 视角下，职责并不一样：
| 概念 | 解决的问题 | pi 里通常对应 | 生命周期 | 常见误用 |
|---|---|---|---|---|
| Storage（存储） | 信息放在哪里、如何持久化？ | 会话文件、数据库、对象存储、向量库、外部系统 | 由业务决定，可长期保存 | 以为“存下来了”就等于模型会自动记得 |
| Memory（记忆） | 哪些信息值得跨会话回忆？ | memory 扩展提炼出的偏好、事实、经验，再按需注入 context | 跨会话，需提炼和遗忘 | 把原始聊天记录当记忆，导致噪声越来越多 |
| State（状态） | 当前任务跑到哪一步？ | session tree、pending tool calls、计划进度、工作目录、分支、运行中任务状态 | 一次 run、一个 session 或一个后台任务 | 把临时进度写进长期记忆，后续反而误导 Agent |
| Context（上下文） | 这一次模型调用能看到什么？ | 当前 messages、system prompt、工具结果、检索片段、压缩摘要 | 单次调用或当前会话窗口 | 把所有历史都塞进窗口，直到 token 爆掉 |
一句话区分：
- Storage 是存放介质：它只回答“东西在哪里”。
- Memory 是可回忆的长期信息：它回答“下次还值得记住什么”。
- State 是运行中的机器状态：它回答“这件事进行到哪了”。
- Context 是喂给模型的窗口内容：它回答“这一次模型实际看见什么”。
做决策时按场景选：
- 单次会话内快满了 → Compaction 压缩 Context（第 9 章），保重点、丢细节
- 需要跨会话记住偏好/事实 → Memory 记忆（第 10 章），先提炼再注入
- 需要恢复/回溯/分支 → State + 会话树（第 12 章），保存任务进度而不是塞进记忆
- 需要长期保存原始资料/日志/向量 → Storage，再通过工具、MCP、RAG 或 memory 扩展取回
决策七：生产化清单
上生产前，逐项过（详见第 35 章清单）：
- 成本 → 预算控制 + 分层模型（第 25、33 章）
- 知识 → RAG 来源引用 + 版本更新（第 11 章）
- 可观测 → 持久化会话 + 成本归因（第 25 章）
- 质量 → 任务集 + 会话回放 + RAG 评测（附录 D）
- 安全 → 隔离 + 确认门（第 7、27 章）
- 治理 → 策略 + 审计（第 27 章）
- 部署 → RPC/后台/多租户 + 回滚降级（第 23、32、28 章，附录 E）
决策八：隔离用哪种强度？
| 信任程度 | 隔离 | 章节 |
|---|---|---|
| 自己用、跑自己代码 | 进程级 + 危险命令确认 | 第 8 章 |
| 处理不可信输入 | 容器级（Docker） | 第 28 章 |
| 多租户、面向公网 | 微 VM（Gondolin）+ 每租户隔离 | 第 27、28 章 |
别过度隔离（慢、重），也别隔离不足（一次事故就够受）。
一条总原则
从最简单的方案开始，只在确实撞到墙时才升级到更复杂的模式。每加一层复杂度，都要问：“这值得吗？”