为什么需要这本书¶
关于 AI 智能体的材料已经很多了。真正更少的是那些把智能体系统当成必须在生产环境里被设计、约束、发布、调查和维护的系统来讨论的材料。
这本书就是为了补上这个缺口。
规范书籍案例（Canonical book cases）
这本书要补上的缺口，在三个规范案例（canonical cases）里最清楚。支持分流（Support triage） 说明为什么写入动作（write actions）、审批（approvals）、策略门禁（policy gates）、重复工单恢复（duplicate-ticket recovery）和审计轨迹（audit trail）比打磨过的演示（polished demo）更重要。内部知识助手（Internal knowledge assistant） 说明为什么检索（retrieval）、记忆边界（memory boundaries）、来源锚定（source grounding）、来源证明（provenance）和租户感知访问（tenant-aware access）必须是架构决策，而不是提示词技巧（prompt tricks）。事件协调（Incident coordination） 说明为什么追踪（traces）、服务级目标（SLOs）、升级（escalation）、响应归属（response ownership）、发布控制（rollout control）和事件后学习（post-incident learning）必须在生产事故（production incident）之前就存在，而不是事后再补。
它不是什么¶
它不是：
- 某个框架的手册；
- 某个供应商产品的指南；
- 提示集合；
- 基准测试和 AI 新闻巡礼；
- 没有架构模型的安全检查清单。
它想做什么¶
这本书把智能体系统看成受治理的生产系统，它们应该具备：
- 信任边界；
- 受策略约束的执行；
- 面向高风险动作的审批；
- 记忆与上下文纪律；
- 追踪、SLO 与评测；
- 发布控制、负责人边界与生命周期治理。
它的主要目标不是帮助人们做出“最自主的智能体”，而是帮助他们做出一个在运行中值得信任的系统。
和框架文档相比¶
框架文档在你已经知道自己想构建什么系统时非常有用。它们通常很擅长解释编排模式、状态图、SDK 用法和集成细节。
但它们很少回答这类问题：
- 智能体到底该被允许做什么；
- 哪些动作必须经过审批；
- 记忆应该怎样被约束；
- 怎样在不失去控制的前提下发布变更；
- 事故之后应该怎样做评审。
这本书试图站在框架之上，而不是和框架争论。
和供应商文档相比¶
供应商文档往往给出通往演示的最短路径。这当然有用，但它天然受限于单一供应商的表面。
这本书试图让架构站在产品表面之上，并把更稳定的工程纪律和变化更快的平台工具分开。
和安全检查清单方法相比¶
检查清单方法是必要的，但它本身并不会自动变成一套可工作的架构。它会告诉你该看哪里，却不会告诉你怎样把运行时、审批、遥测、负责人边界和生命周期连接成一个受治理的轮廓。
这正是这本书试图完成的事情。
希望达到什么结果¶
读完这本书后，读者应该：
- 看清信任边界与动作边界真正在哪里；
- 理解如何捕获运行行为，而不是只从症状去猜；
- 知道怎样定义健康预算与风险预算；
- 知道怎样产出关于质量与回归风险的可评审判断；
- 能把发布、响应、谱系与问责区分成不同的运行职能。
如果这些问题比另一篇智能体剧场更接近你的现实，那么这本书就是为你写的。