LLM Agent 架构模式：从工具调用到多智能体
结论先行：Agent = LLM + 工具 + 循环 + 记忆 + 停止条件。90% 的"Agent 需求"其实用一个带工具调用的确定性工作流就够了；只有当步骤数不可预知、需要动态决策时，才真正需要自主循环。
相关阅读：Prompt 工程模式、LLM 应用评估、LLM 应用架构、RAG 架构。
1. Agent 的五个部件
- 规划（Planning）：把目标拆成步骤。可显式（先出 plan）或隐式（每步即时决定）。
- 工具（Tools）：检索、代码执行、API、数据库。每个工具是一个有 schema 的函数。
- 循环（Loop）：观察→思考→行动→观察……直到满足停止条件。
- 记忆（Memory）：短期（对话/scratchpad）+ 长期（向量库/结构化存储）。
- 停止条件（Halting）：达成目标、达到最大步数、成本上限、或需要人工。没有它就会烧钱空转。
2. 从简单到复杂的模式谱系
2.1 单次工具调用（Tool Use）
最常见也最稳。LLM 输出一个函数调用，代码执行后可选把结果回灌一次。适合"查天气/查订单/结构化抽取"。能用它就别上循环。
2.2 ReAct（Reason + Act）
交替"推理—行动—观察"，模型自己决定下一步用哪个工具：
Thought: 需要先查用户余额
Action: get_balance(user_id="u1")
Observation: 1200
Thought: 余额够，执行转账
Action: transfer(...)
Observation: ok
Thought: 完成
Answer: 已转账优点：灵活、可解释。风险：可能绕圈、步数发散——必须设 max_steps 与循环检测。
2.3 Plan-and-Execute
先让模型产出完整计划，再逐步执行（执行时可用更便宜的模型）。比 ReAct 更可控、更省钱，适合步骤较确定的多步任务；计划错了需要"重规划"分支。
2.4 反思 / 自我修正（Reflexion）
执行后让模型对照目标/测试结果自评并重试。对"写代码→跑测试→修错"类任务提升明显；代价是更多轮次。
2.5 多智能体编排
把复杂任务拆给多个专职 agent（如 规划者 / 编码者 / 评审者），由一个 orchestrator 协调。
| 拓扑 | 说明 | 适用 |
|---|---|---|
| Supervisor（主管路由） | 一个主管把子任务分派给专家 | 任务可清晰分工 |
| Pipeline（流水线） | A 的输出是 B 的输入 | 阶段固定 |
| Debate / Review | 生成者 + 批评者互相制衡 | 高质量要求 |
忠告：多智能体会放大延迟、成本与故障面。先用单 agent + 好工具打透，确有必要再拆。
3. 工具设计（决定 Agent 上限）
- 描述即接口：工具名、参数 schema、docstring 要写得像给初级同事看的文档。模型靠这些选工具。
- 粒度适中：太细导致步数爆炸，太粗导致不可控。
- 可观测 + 幂等：工具要能重试；有副作用的（转账、删数据）加确认或 dry-run。
- 错误可回灌：工具报错时把结构化错误返回给模型，让它自愈而不是崩溃。
4. 生产可靠性清单
- 停止条件：max_steps、max_cost、超时、重复动作检测。
- 护栏：工具白名单、权限校验在代码层做（别信 prompt）；危险操作人工确认（human-in-the-loop）。
- 确定性优先：能写死的流程别交给模型自由发挥。
- 可恢复：把每步状态持久化，失败可续跑（尤其长任务）。
- 成本控制：规划用强模型、执行用弱模型；缓存工具结果。
- 可观测：记录每步 thought/action/observation、token、耗时，便于回放与评估。
5. 评估 Agent
除最终答案外，评估轨迹质量：是否选对工具、步数是否合理、是否绕圈、成本是否可控。把典型任务做成黄金集，回归门禁化——见 LLM 应用评估。
6. 何时不要用 Agent
- 步骤固定 → 写普通工作流 / 状态机。
- 只需一次检索 + 回答 → 用 RAG。
- 对延迟极敏感的在线路径 → 自主循环不可预测，慎用。
小结
Agent 的工程难点不在"让它更聪明"，而在约束它：清晰的工具、硬性的停止条件、代码层护栏、可回放的可观测性。先做最简形态，用评估驱动复杂度的增加。