第 1 章：为什么智能体需要的是平台，而不是魔法¶

1. 不要从“魔法感”开始，要从一次常见失败开始¶

如果这本书始终在反对一件事，那就是先从“看起来聪明”开始，而不是先从运行失败开始。

先看一个很常见的场景。

某个团队做了一个内部支持智能体：

智能体读取客户邮件；
在知识库里找相关文章；
创建工单；
在需要时请求人工审批。

在演示里，一切都很好看。智能体响应很快，选工具很果断，看起来几乎已经“足够自主”。

问题往往出现在之后：

在一个场景里，智能体把内部备注带进了对外回复；
在另一个场景里，它因为重试重复创建了同一张工单；
在第三个场景里，值班人员根本说不清它为什么决定升级处理；
到了第一次事故，团队又无法快速还原：到底给了模型什么上下文，真正出错的是哪一步。

这正是整本书的核心出发点：多数时候，坏掉的不是模型的“聪明程度”，而是围绕模型搭起来的工程系统。

贯穿案例

支持分诊故事不只是开篇例子。它是本书反复使用的实战案例之一：后面同一个形态会再次出现，只是换成信任边界、工具网关、审批、追踪、评测和发布前检查。如果你更喜欢先从具体系统读起，可以先看实战案例，再回到本章。

所以，这本书并不是真的在教你如何让一个智能体看起来神奇。它是在讨论，怎样避免这种“魔法感”在第一次重试、第一次副作用、第一次审批边界、长上下文或第一次事故面前就崩掉。

2. 这些系统通常缺的到底是什么¶

当团队把智能体理解成“LLM 加几个工具”时，最容易少建的，偏偏是最贵的那些层：

明确的信任边界；
对高风险动作的控制层；
审批规则；
幂等性与回滚边界；
按步骤可观测的执行链路；
清晰的变更生命周期。

因此，智能体往往先显得惊艳，然后很快变得昂贵、脆弱，而且难以运营。

所以，更有用的看法不是“一个聪明助手”，而是“一个可控执行的平台”。

这也是本书最短的一句主张：智能体需要平台，而不是魔法。

构建智能体很枯燥，但结果令人震撼：正是策略、追踪、审批、幂等性和生命周期这些枯燥层，把好看的演示变成值得信任的系统。

3. Vikulin 提出的问题是对的，但今天已经不够了¶

Dmitry Vikulin 的文章提出了一个很好的起点问题：一个可靠的智能体，到底由哪些模块组成。¹ 这确实是正确的起点。

但对于生产系统来说，只有模块清单已经不够了。实践里，成熟团队会很快转向更严格的工程框架：

先选择最简单、最可执行的模式；
把高风险动作放进独立的控制层；
只有在已经有策略、追踪和回滚边界的地方，才放出更多自治空间。²⁶³

换句话说，问题已经不只是“智能体由什么组成”，而是“在高负载、长会话和真实写操作里，怎样让它保持可控”。

4. 默认先选工作流，而不是先选智能体¶

这是整个主题里最实用的原则之一。

Anthropic 很明确地区分了 workflows 和 agents，并建议先从更简单的那一类开始。² OpenAI 也给出了非常接近的结论：只有当智能体真正买来了有价值的灵活性时，它才值得引入，而不是因为它“听起来更现代”。⁴

翻成工程语言，这条规则其实很简单：

如果执行路径事先就清楚，先写 workflow；
如果系统只需要在一个窄边界内选择下一步或选择工具，就用 single-agent loop；
只有当任务天然拆成多个独立子任务，而且上下文和责任边界都不同，才考虑 multi-agent。

这个建议很保守。也正因为保守，它非常有效。

Anthropic 还有一个很实用的提醒，就是在早期阶段不要默认先上框架。² 如果直接调用 API，再加上一层很薄的编排就已经足够解决问题，那么过早引入额外抽象，通常只会让调试、提示检查和运行责任变得更糟，而不是更好。

证据简述

外部来源在一个实践规则上是一致的：先从更简单的可执行形态开始，只在确实带来真实灵活性时才增加 agency。²⁴

本章的作者解释更严格：一旦自主性触及写路径、访问权限、记忆或事故响应，它就应该被当成执行平台的一部分。本章完整的置信模型放在第 14 节。

另一种观点：为什么不先 agent-first？

也有一种合理的相反观点：如果模型进步很快，而任务本身很 messy，团队可以先从 agent loop 开始，再逐步加约束。对于探索、内部原型或低风险助手，这有时是成立的。本章的 production 论点更窄：一旦系统接触真实用户、私有数据或写路径，默认选择就应该反过来。先从动态性最低的可执行形态开始，再在额外灵活性足以抵消运营成本的地方加入 agency。

5. 什么时候智能体才是真的合理¶

是否需要智能体，应该由任务形态决定，而不是由风格决定。

下面这些信号通常说明智能体有意义：

系统必须在执行过程中连续做出一串并不显然的决策；
规则分支太多，用硬编码维护成本太高；
真正有价值的信号藏在非结构化数据里，比如邮件、文档、笔记或网页内容；
人工路由的成本已经高于“可控自治”带来的成本；
任务变化很快，如果每次都改确定性工作流，代价太高。

而更适合普通工作流的信号是另一类：

步骤几乎总是固定的；
状态转移容易形式化；
写路径上的错误代价很高；
可解释性和可重复性比灵活推理更重要；
“自治”听上去诱人，但并没有带来多少真实收益。

6. 判断规则：工作流、单智能体还是多智能体¶

这是最值得先记住的一张短表。

快速判断：工作流、单智能体还是多智能体

先选择能够安全解决问题、同时动态性最低的形态：

任务看起来像什么	从哪里开始	为什么
路径基本已知	`workflow`	更容易维护、更容易测试，也更容易解释。
系统只需要受限地选择下一步或某个工具	`single-agent loop`	增加灵活性，但不会过早引爆复杂度。
存在独立子任务、不同上下文和不同责任边界	`multi-agent`	只有当这种拆分真实存在时，才值得分离责任和上下文。

如果只看文本版，同一条规则就是：路径已知时用 workflow；只需要受限选择下一步时用 single-agent loop；只有在独立子任务和不同 owner 都真实存在时，才用 multi-agent。

还有一条很实用的判断规则：

如果你不能用一小段话说清楚为什么这里必须是智能体，那大概率现在还不该上智能体；
如果你说不清为什么这里必须是 multi-agent，那它几乎肯定太早了。

7. 团队在起步阶段最常做错什么¶

最常见的早期错误几乎总是这些：

在工作流还没描述清楚之前，就先决定“这里要上智能体”；
只要系统不止一个步骤，就把它叫作 multi-agent；
团队还说不清底层提示、工具契约和失败路径时，就先把框架引进来；
在信任边界、审批和可观测性还没定义前，就先争论提示和模型；
用演示的表现衡量成败，而不是看第一次重试、第一次超时和第一次事故之后会发生什么。

如果这些问题还没有答案，那么关于“更强智能体自治”的讨论通常都太早了。

8. 为什么“魔法感”会比你想得更早失效¶

在短而安全的场景里，系统确实可能看起来一切正常。然后它会逐渐引入：

长上下文；
外部系统；
私有数据；
审批；
多种访问角色；
代价高昂的副作用。

到这个阶段，主要问题就不再只是“回答质量如何”，而会变成别的东西：

成本开始不可预测；
行为开始漂移；
结果变得难以复现；
事故变得难以调查；
团队也不再确定自己是否真的控制住了写路径。

这正是智能体从“带工具的 LLM”变成“完整工程系统”的时刻。

9. 接下来应该依赖的四个原则¶

9.1. 控制优先于自治¶

先把执行路径做成可预测的，再逐步放大自由度。

9.2. 安全不能事后外挂¶

如果策略、身份和审批没有嵌进运行时，后面做的就不是演进，而是在压力下修架构。

9.3. 状态必须是显式的¶

长任务不应该因为进程重启或请求重放，就把步骤、审批和副作用弄丢。

9.4. 可观测性比“看起来聪明”更重要¶

如果智能体“看上去很聪明”，但你没有 traces、evals 和 step metadata，那你其实没有控制住这个系统。⁵⁶

本章的简短视觉公式：智能体需要平台，而不是魔法

flowchart LR
    A["Request"] --> B["Execution context"]
    B --> C["Policy / approvals"]
    C --> D["Runtime path"]
    D --> E["Model / memory / tools"]
    E --> F["Trace / eval evidence"]
    F --> G["Rollout / lifecycle"]

10. 生产团队必须始终看见什么¶

最低可用的一组信息应该非常具体：

智能体构建了什么计划；
调用了哪些工具；
哪些上下文被送进了模型；
质量到底在哪一步下降了；
请求过哪些审批；
运行时走的是固定工作流、受约束循环，还是委派式多智能体路径；
每一步花掉了多少延迟和 token。

一旦这些东西从视野里消失，智能体就会开始变成黑箱。

11. 读完这一章立刻该做什么¶

如果你现在就在设计一个智能体系统，不要先从提示开始。先问三个问题：

哪些地方其实普通工作流就够了？
哪些动作真的危险，需要独立的控制层？
团队在生产第一天就必须看见哪些信号？

如果这些问题现在还答不上来，那就还太早，不该先讨论“自治程度”。你先需要一个执行平台。

小型架构评审清单

在把系统称为可投入生产之前，先检查五件事：执行模式是否已经是仍然有效的最低动态形态；所有高风险副作用是否都经过控制层；写入路径是否有负责人；追踪是否显示身份、策略决策和结果；第一批评测集是否覆盖重试、超时，以及形态接近真实事故的失败。

12. 一个简短结论¶

如果这一章你只记住一句话，那就记这句：

一个好的智能体产品，并不是从最大自治开始，而是从一个可预测的平台开始，自治是被逐步加进去的。

这条原则听起来刻意比大多数智能体演示更不兴奋，但它正是整本书其余部分的形状来源。

所以下一章不会继续谈抽象意义上的“聪明”，而会进入平台架构：为了让智能体系统可以安全上线、被观察、被演进，到底必须有哪些层。

13. 本章证明了什么¶

本章并不是要证明智能体总是必要的。恰恰相反，它说明：有用的 agency 往往从约束开始。

如果执行路径可以提前描述，就先从 workflow 开始。如果确实需要灵活性，也要把它和 ownership、policy boundaries、approvals、traces 与 eval signals 一起加入。核心主张因此很简单：智能体不是工程纪律的替代品，而是会提高对工程纪律的要求。

14. 本章的证据模型¶

阅读本章观点时，可以把它们分成不同置信层级：

Standards / normative sources： 设定治理、可审计性和风险控制预期，但不提供完整的智能体蓝图。
Vendor / platform practice： OpenAI 与 Anthropic 都建议先从更简单的可执行形态开始，只在确实带来有用灵活性时才增加 agency。
Runtime practice： durable execution、approvals 和可复现 traces 是工程机制，不是修辞。
稳定主张： 高风险 side effects 需要明确控制点；traces 与 eval signals 是生产问责的基础。
快速变化层： agent frameworks、SDKs 与 orchestration patterns 会比底层控制原则变化更快。
作者解释： platform, not magic 是本书把这些实践压缩成的一条设计规则。