Skip to content

22 · AI 原生系统设计

一句话点题:19 章 的客服是「对话 + 受控动作」;这一章把自主性再推一档——设计一个能自己规划、调用工具、多步把整个工单处理到底的自主 Agent**。自主性每涨一格,17 章 那三个新约束就咬得更狠,而给放飞的自主性「装刹车」,正是 AI 原生系统设计的全部功夫。**


🎯 实战篇第 5 章(收官)· 本章只练一件事

17 章 的三个新约束 + agentic 硬骨头,落到一次完整的 AI 原生设计上。它是实战篇的终点,也是通往 AI 协同设计篇(23–26) 的桥。

读完你应该能本章靠什么练
第一时间判断「该用工作流还是自主 Agent」第一节:最重要的那个决策
把非确定性 / 上下文 / 成本三角落成具体设计第二节
看懂「自主 Agent = 整个进阶篇的叠加」第三节:硬骨头逐条装刹车

开场:从「受控动作」到「自主」

回到那个 AI 客服。19 章 里,模型只能「提议」,真正退款由确定性代码执行——自主性很低,所以很安全

现在产品想更进一步:遇到一个复杂工单(「我上周买的鞋穿了一次开胶了,要么退要么换」),让 Agent 自己处理到底——查订单、查物流、调质保政策、判断责任、决定退款还是补发、执行动作、回复客户,搞不定才升级人工。

   自主性的阶梯(越往上,能力越强,硬骨头叠加越狠):

   单次问答  ─▶  对话+受控动作(19 章)  ─▶  确定性工作流  ─▶  自主 Agent(本章)
   "你问我答"     "模型提议、代码执行"      "固定步骤、节点判断"   "自己规划下一步"

                                          能力最强,但也最贵、最慢、最难控、最危险

这就是本章的核心张力:自主性是把双刃剑。它让 Agent 能处理开放任务,但每涨一格,17 章 的非确定性、成本、上下文三个约束,以及整个进阶篇的分布式硬骨头,全都成倍放大。 AI 原生系统设计,本质就是**「在尽量低的自主性上,解决问题」+「给不得不放飞的那部分,装满刹车」**。


一、最重要的一个判断:工作流,还是自主 Agent?

在画任何框之前,先做这个决策——它比后面所有设计加起来都重要。

Anthropic 在《Building Effective Agents》里的核心建议:能用确定的工作流解决,就别上自主 Agent。 工作流可预测、可控、便宜;Agent 灵活,但更贵、更慢、更不可控。这和 04 章「能用单体就别微服务」、10 章「能不分布式就别分布式」是同一种克制。

   该用哪个?——一棵决策树:

   任务的步骤是不是基本固定、可预先编排?

     ├─ 是 ──▶ 用【确定性工作流】
     │         [接工单]→[分类]→[检索政策]→[生成方案]→[人工/自动执行]
     │         ✓ 可预测、好调试、便宜、好评测  ← 80% 的「智能」需求其实到这就够了

     └─ 否(任务开放、必须随机应变、步骤因情况而异)

            ▼  才用【自主 Agent】(并立刻给它装满下面的刹车)

对我们的工单场景做判断:大部分工单(查物流、退运费、改地址)其实是固定流程,用工作流;只有「责任判定模糊、要多方查证、要权衡退还是换」的少数复杂工单才值得上自主 Agent。

架构智慧:别因为「自主 Agent 听起来更高级」就上它。 把能固化的固化成工作流(便宜、可控、可评测),只把真正开放的那一小撮留给自主 Agent——这是 AI 原生设计的第一个、也是最省钱省心的判断。可预测性是工程美德。


二、落地 17 章 的三个新约束

决定了「这一小撮复杂工单上自主 Agent」,就要正面解决三个新约束。

约束 1:非确定性 → 评测驱动 + 护栏 + 可回退

传统系统靠「同输入 → 同输出」的断言;Agent 同一工单两次运行路径都可能不同。三件事应对:

手段怎么设计
评测驱动(eval-driven)攒一批代表性工单 + 期望处理要点,做成评测集;改提示 / 换模型 / 改工具前,CI 跑 eval(规则 + LLM-as-judge),分数掉了不许上线(承接 20 章 ADR-005)
护栏 + 人审关卡不确定的输出在产生副作用前要兜底:退款 / 补发等不可逆动作,走 human-in-the-loop;置信度低就升级人工
可观测 + 可回退每一步(规划、工具调用、结果)全程 trace,能回放、能回滚

约束 2:上下文工程 → 把上下文当「内存层级」来管

Agent 跑十几步,上下文会爆;塞太多既贵又「迷失在中间」,塞太少缺依据。按 17 章 的「内存层级」管:

   ┌───────────────────────────┐
   │ 上下文窗口(最贵最快,工作内存) │ ← 只放「这一步真正需要的」
   ├───────────────────────────┤
   │ 检索 RAG(按需取政策/历史工单)  │ ← 链 RAG(18/19 章那套)
   ├───────────────────────────┤
   │ 长期记忆(跨工单,落盘)        │ ← 这个客户的历史、已解决的同类工单
   └───────────────────────────┘

核心取舍还是那三条路(没有银弹):长上下文 vs RAG vs 微调——把整本政策塞进去简单但贵且糊;RAG 精准但要维护检索;微调改行为但僵化。长任务还要定期压缩 / 摘要历史步骤,别让上下文无限膨胀(对应 Claude Code 的上下文自动压缩)。

约束 3:成本 / 延迟 / 质量三角 → 路由 + 缓存 + 硬上限

Agent 最烧钱:成本随步数线性涨,一个工单十几步 = 十几次模型调用。破解都似曾相识:

  • 模型路由:简单子任务(分类、抽取)给小模型,只有「权衡判断」才上大模型。
  • 缓存:重复的政策检索、相同的子问题,缓存复用。
  • 硬上限(最关键):每个任务设「最多 N 步 / 最多 $X / 超时 T」,超了就停、转人工——这既是省钱,也是下一节「防失控」的生命线。

三、Agentic 硬骨头:给放飞的自主性逐条装刹车

17 章 有个关键洞见:一个自主 Agent,恰恰是前面每一章硬骨头的叠加。 所以「设计 Agent」=「把进阶篇的刹车逐条装上」:

Agent 的难点它其实就是进阶篇的…装什么刹车
行动循环可能原地打转、无限烧钱12 · 韧性工程 的降载/熔断步数 / 成本 / 超时上限 + 重复检测,超限即停
工具调用有副作用、多步像分布式事务11 · 数据一致性 的 Saga/幂等工具幂等;多步动作可补偿回滚(19 章 退款闸门同理)
长任务跑很久、节点会挂、要可恢复10 · 分布式硬道理 的部分失败检查点持久化(durable execution),断了能续
多 Agent 协作 = 分布式 + 扇出放大10 / 13 · 规模化力学从单 Agent 起步,扛不动再拆多 Agent;控扇出
提示注入是头号威胁,工具权限要最小化16 · 安全与多租户工具沙箱 + 最小权限;一切外部内容当不可信
从能跑的原型渐进演化为可控系统14 · 演进与拆分影子运行验证、灰度放量(同 21 章)

把这些刹车装到架构里,就是 Agent 平台的全景图:

   复杂工单:「鞋开胶,要退要换」


   ┌──────────────────────────────────────────────────────────┐
   │  编排器 Orchestrator                                       │
   │   ┌──────────────── 行动循环 ──────────────────────┐      │
   │   │ ① 规划:下一步做什么?                            │      │
   │   │ ② 调工具(查单/查物流/查质保政策)── 沙箱执行       │      │
   │   │ ③ 观察结果 → 喂回模型                            │      │
   │   │ ④ 没完成?回 ①(受【≤N 步 / ≤$X / 超时 T】约束)  │      │
   │   └───────────┬──────────────┬───────────────┬─────┘      │
   │         ┌─────▼────┐  ┌──────▼──────┐  ┌─────▼──────┐    │
   │         │ 工具沙箱   │  │ 记忆          │  │ 检查点      │    │
   │         │ 最小权限   │  │ 短期+RAG+长期 │  │ 长任务可恢复 │    │
   │         └──────────┘  └─────────────┘  └────────────┘    │
   │                                                            │
   │   ⚠ 退款/补发等不可逆动作 ──▶【人审关卡】审批后才执行         │
   └────────────────────────────┬───────────────────────────────┘
                                ▼ 全程 trace 写入可观测系统
                            处理结果 / 升级人工

架构智慧:没有控制阀的 Agent 循环,就是一台会自己烧钱、还可能闯祸的失控机器。 灵魂不在「让它更自主」,而在套在自主性外面的那圈控制阀——步数/成本/超时上限、沙箱、最小权限、人审关卡、全程 trace。读 Claude CodeCodexOpenClawHermes 这四张真实 Agent 地图,你会发现它们的「灵魂」全在如何给放飞的自主性装刹车——而刹车的原理,你在进阶篇早已学完。


📌 真实案例:工具侧的共识——「能不放飞就别放飞」

  • Anthropic《Building Effective Agents》:反复强调**「保持简单、能用工作流就别上自主 Agent」**,以及「按需才增加复杂度」。这不是保守,是工程成熟——和本仓库一以贯之的克制(能不用就先别用)完全同源。
  • 四个真实 Agent 产品(Claude Code / Codex / OpenClaw / Hermes):无一例外,把大量设计花在给自主性装刹车上——沙箱、双层权限、预算/步数上限、心跳即省钱、人审关卡。能力是模型给的,安全是架构给的

📎 Anthropic: Building Effective Agents · AI Agent / 工作流平台模板


🎯 随堂检验

🤔要给客服系统加「自动处理复杂工单」的能力,符合业界(如 Anthropic)建议的第一判断是?
  • A直接上多 Agent 协作,越自主越先进
  • B先问任务能不能用确定性工作流解决——能固化的固化成工作流(便宜、可控、可评测),只把真正开放、必须随机应变的少数任务,才交给自主 Agent
  • C把所有工单都交给一个全自主 Agent,省得分类
🤔一个自主 Agent 的行动循环,最不可省的「刹车」是?
  • A给它配一个更大的上下文窗口
  • B步数/成本/超时的硬上限 + 不可逆动作的人审关卡 + 工具沙箱最小权限
  • C让它多调用几次模型以提高质量

本章小结

  • AI 原生设计的第一判断:工作流 vs 自主 Agent——能固化就固化成工作流(便宜可控可评测),只把真正开放的少数任务留给自主 Agent。能不放飞就别放飞。
  • 落地 17 章 三个新约束:① 非确定性 → eval 当门禁 + 护栏/人审 + 可回退;② 上下文工程 → 当「内存层级」管(窗口/RAG/长期记忆 + 压缩);③ 成本/延迟/质量三角 → 模型路由 + 缓存 + 步数/成本/超时硬上限
  • 自主 Agent = 整个进阶篇的叠加:行动循环要降载(12)、工具要幂等(11)、长任务要检查点(10)、多 Agent 是分布式扇出(13)、提示注入是头号威胁(16)。设计 Agent = 把这些刹车逐条装上。
  • 灵魂在控制阀,不在自主性:能力模型给,安全架构给——四个真实 Agent 产品的设计重心,全在给放飞装刹车。

🏁 实战篇收官 · 承上启下:你已经把一个 AI 系统完整走了一圈——读懂(18)→ 设计(19)→ 演进(20)→ 拆迁(21)→ AI 原生设计(22)。但这一路有个反复出现的主角:eval、护栏、人审、规格、约束——它们都是「人怎么把判断喂给 AI、又怎么审查 AI 的产出」。这正是下一章 23 · 规格即架构 开启的 🤝 AI 协同设计篇(23–26) 的主题:会设计之后,学会与 AI 协作落地与审查,而不失控。 它和 architecture-copilot skill 是同一条产品线。


相关链接

💬 评论