模式选择与最小架构
本节目标
学完本节，你应能先描述任务，再选择普通代码、确定性工作流、单 Agent 或多 Agent；还能把选择写成可检查的状态图，而不是以“模型很聪明”为前提。
先澄清三个词
- 组件是模型、工具、检索器、数据库等零件。
- 模式是反复出现的问题与可复用的组织方法，例如路由、并行、审批和检查点。
- 框架是实现这些模式的软件。模式不等于某个框架 API；框架升级后，状态、权限和验收约束仍然存在。
从任务不确定性开始
Anthropic 的官方工程文章把 agentic systems 分为两类：**工作流（workflow）**通过预定义代码路径编排模型和工具；Agent 让模型动态决定过程和工具使用。文章同时建议从最简单的方案开始，只在任务收益能够覆盖时延、成本和错误累积时增加复杂度。这是来源陈述，不代表所有团队都必须采用同一实现。
可以用四级阶梯做第一次筛选：
| 级别 | 谁决定下一步 | 适合情形 | 主要验证方式 |
|---|---|---|---|
| 普通函数或脚本 | 程序规则 | 规则稳定、输入输出明确 | 单元测试、属性检查 |
| 确定性工作流 | 程序状态机 | 步骤与分支可预先列出 | 节点与转换测试 |
| 单 Agent | 模型在受限动作集中选择 | 路径无法预先枚举，需要依据环境观察调整 | 轨迹、结果与预算评测 |
| 多 Agent | 多个模型角色协调 | 权限、上下文或专业能力必须隔离，且协调收益已被证明 | 协议、交接和系统级评测 |
例如“把固定 CSV 转为 JSON”属于普通程序；“解析文档→检索→生成→引用校验”通常是工作流；“在未知代码库中定位故障并选择检查工具”才可能需要 Agent。把同一个提示复制给三个角色，并不会自动得到三份独立证据。
六个诊断问题
开始画架构前，逐项回答：
- 成功能否写成断言、测试或人工量表？
- 步骤与依赖能否提前列出？
- 哪些分支能用确定性规则决定？
- 哪些动作会改变外部世界，是否可撤销？
- 环境会不会在执行期间变化，是否需要重新规划？
- 允许消耗多少步骤、时间、模型调用和人工审批？
若成功条件不清楚，加入 Agent 只会把含糊需求搬进运行时。若步骤和分支已知，工作流通常更容易回放。只有当路径确实取决于未知环境观察时，模型驱动的动态循环才带来独特价值。
一页最小架构卡
设计文档至少写清以下字段：
| 项目 | 必须回答的问题 | 可验证产物 |
|---|---|---|
| 输入 | 类型、大小、来源、可信度、拒绝条件是什么？ | JSON Schema 或输入测试 |
| 输出 | 谁消费、结构是什么、如何判断完成？ | 验收断言或评分表 |
| 状态 | 哪些字段跨步骤保存，谁能修改？ | 状态 schema 与版本 |
| 决策 | 哪些由规则决定，哪些交给模型？ | 路由表与未知分支 |
| 工具 | 权限、超时、错误、副作用是什么？ | 工具契约 |
| 停止 | 成功、失败、超预算、转人工分别何时发生？ | 显式终态 |
| 证据 | 如何重放并定位错误？ | 事件轨迹、回执、测试集 |
一个最小状态可以是：
{
"run_id": "run-001",
"stage": "classify",
"input_ref": "sha256:...",
"budget": {"steps_left": 6},
"approval": null,
"result": null
}字段阅读：
run_id把一次运行的状态、事件和审计记录关联到同一稳定标识。stage是业务代码控制的当前流程阶段，不能由模型自由改写。input_ref指向已冻结、可复查的输入摘要或版本。budget.steps_left把最大执行步数放进可校验状态，而不是只写在 Prompt 中。approval在获得可信批准前保持null，不把模型文字当授权。result只在达到合法终态后保存受控产物或其引用。
状态只保存继续执行所需的事实，不把整段聊天历史当数据库。input_ref 应指向受控输入版本；真实系统还要定义访问控制与保留周期。
逐步构造：固定日报
需求是“每天读取三个固定 RSS 源，筛出指定关键词，生成摘要并保存草稿”。
- 来源固定，获取和筛选步骤可列出，因此先选工作流。
- 三个源互不依赖，可并行读取；汇聚后检查是否缺源。
- 摘要可以由模型生成，但流程控制仍由代码完成。
- 保存为草稿是写操作，使用固定目录和幂等文件名。
- 成功条件是三份抓取状态齐全、摘要字段合法、草稿回执存在。
若需求后来变为“自行发现相关来源、决定查询轮数并处理反爬限制”，才重新评估是否需要 Agent。架构选择应随任务证据变化，不随流行词变化。
常见误区与排查
- 把自主性当目标：先问业务结果，不问“能否更自主”。自主性越高，验证面越大。
- 把模型输出当状态事实：模型的建议是候选决策；工具回执或数据库记录才是外部状态证据。
- 先选框架再定义状态：框架默认值会替你做隐含决定，导致失败时难以解释。
- 只有成功路径：网络失败、权限拒绝、人工拒绝与预算耗尽都应有终态。
- 只看演示一次成功：随机模型的一次通过不等于稳定；至少建立可重复任务集和多次 trial。
练习：完成一张架构卡
为“读取客户工单，生成回复草稿；退款只生成建议，不直接执行”提交：
- 四级阶梯中的选择及理由；
- 输入、输出、状态、决策、工具、停止、证据七项；
- 一张包含
success、failed、human_review的状态图； - 三个正常样本、两个边界样本和一个恶意输入样本。
参考判断：分类、检索和草稿生成可组成工作流；退款建议应与真实退款工具隔离。只有工单处理路径确实无法预先定义时，才考虑让 Agent 动态选择受限工具。
掌握检查
- 能给出一个不该使用 Agent 的任务，并说明原因。
- 能区分组件、模式和框架。
- 能将“完成”改写为可检查的结果或环境状态。
- 能列出模型决策增加的成本、时延和验证面。
- 能写出成功、失败、取消、超预算和人工接管终态。
下一步
进入 路由、并行与汇聚，用可预测结构组合任务。
参考资料
- Anthropic：Building effective agents（发布：2024-12-19；核对：2026-07-14）
- OpenAI：A practical guide to building agents（核对：2026-07-14）