reliable_design零基础约 55 分钟
第 0-5 课
为什么 Agent 要有系统架构：把“会出错的模型”放进可靠流程
学完你能做到
- 知道系统架构在 Agent 中解决什么问题
- 区分确定性代码该做什么、模型该做什么
- 理解工作流、路由与 Agent 是三种不同程度的自主性
系统架构不是“画框图”，而是分配不确定性
先建立直觉
做飞机时，飞行员可以判断天气和路线，但起落架、刹车、油量告警不能靠“飞行员今天很认真”来保证。适合规则化的部分交给机械和检查表，适合判断的部分交给人。
| 任务 | 优先交给谁 | 原因 |
|---|---|---|
| 判断用户意图、总结资料、提出检索词 | 模型 | 语言含义开放且规则难写全 |
| 检查日期格式、JSON 字段、答案是否拼写相同 | 代码 | 规则明确，代码更稳定 |
| 读数据库、扣费、发邮件、删除文件 | 受权限控制的工具层 | 需要身份、审计和副作用保护 |
| 把问题分到听力导师/论文阅读/客服 | 路由器 + 明确回退 | 先缩小任务范围，再用更专门的提示词或模型 |
| 是否允许最终提交高风险操作 | 人工确认或业务规则 | 不能把责任交给概率生成 |
工作流、路由、Agent：不是三选一，而是从稳定到开放的谱系
先建立直觉
流水线永远按同一张工序单做；医院分诊先把病人送到不同科室；医生遇到复杂病情再根据检查结果决定下一步。
案例推演：把不稳定的模型放进稳定的报销系统
模型负责从票据提取金额并解释异常，但财务系统不能因为一句自然语言就付款。系统需要把概率判断和确定性规则分开。
本节追问：哪些判断可以交给模型，哪些必须由代码、权限和人工控制？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。
| 阶段 | 本步要做的决定 | 什么算证据 | 最常见的失败 |
|---|---|---|---|
| 划分职责 | 模型做识别与解释，代码做金额计算和规则判断 | 每个输出有明确执行者与验证方式 | 让模型自行算税并直接写账 |
| 建立契约 | 模型按 Schema 输出字段与证据位置 | 缺字段、类型错会被程序拒绝 | 从自由文本中猜金额 |
| 设置门槛 | 低风险自动流转，高风险进入人工复核 | 金额、异常类型和置信证据触发规则 | 所有请求都全自动或全人工 |
| 保留追踪 | 记录输入、模型版本、规则版本和最终动作 | 任一付款能解释并重放 | 只保存最后一句“审核通过” |
阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。
常见误解
用更强模型替代系统架构
实际上
可观察症状：平均准确率提高，但一次高风险错误仍可直接造成损失。
更可靠的修复：让模型建议、确定性组件验证、权限层授权、审计层记录。
案例工作坊 · 建议真正动手完成
25 分钟- 列出报销流程中五个模型任务和五个确定性任务。
- 设计三条必须转人工的风险规则。
- 画出从票据上传到付款的可审计数据流。
查看参考答案
系统架构不是为了弥补“差模型”，而是承认概率组件会出错。职责分离、结构验证、权限门槛和审计让错误可发现、可阻断、可恢复。
迁移检查：换一个场景还会不会
模型输出“金额为 580 元”后，付款前最关键的下一步是？