跳到主要内容

哪些模式真值得带去项目，哪些更适合先当认知储备

我不会把书里的每个模式都当“立刻该上”​

AI Agent Book 的覆盖面很广，这既是优点，也是一个风险：你很容易把“知道它存在”误解成“我现在就该把它做进系统”。

所以我会明确分成两类：

  • 现在就值得带去项目的模式
  • 先当认知储备、别急着硬上的模式

现在就值得带走的模式​

1. 编排收益和协调成本一起算​

这件事现在就该带走，因为它几乎不增加实现成本，但会大幅提高你的判断质量。

只要你开始想拆多 Agent，就先问：

  • 任务是否足够独立，值得并行
  • 是否真的需要专业分工
  • 结果整合成本会不会反杀收益

这个判断一旦建立，能帮你避免大量“为了多 Agent 而多 Agent”的伪复杂度。

2. 控制平面和执行平面的责任分离​

不一定非得马上上 Go/Rust/Python 三层，但“编排责任”和“执行责任”不要揉在一起，这个模式现在就值得带走。

哪怕是一个小系统，也应该尽早区分：

  • 谁决定任务如何分解与路由
  • 谁真正执行工具、隔离副作用
  • 谁负责和模型、向量库、外部能力对接

这件事越晚做，后面越难拆。

3. 预算意识前置​

Token budget 控制不一定要一开始就上完整系统，但“预算是架构变量，不是运营变量”这个判断必须尽早带走。

因为它会直接影响：

  • 上下文组织方式
  • 模型分层策略
  • 编排粒度
  • 失败重试策略

如果没有预算意识，很多系统不是功能做不出来，而是根本跑不起。

4. 权限和安全边界前置​

Policy governance 和 secure execution 不一定立刻全量实现，但权限边界不该后补。

尤其一旦系统能调工具、能执行代码、能触文件，权限模型就不是“企业版功能”，而是基本结构。

更适合先当认知储备的模式​

1. 完整的 Temporal 工作流体系​

Temporal 很强，但它不是每个项目的起手式。

如果你的系统还没到：

  • 任务很长
  • 崩溃恢复很重要
  • 执行状态需要精确追踪
  • 持久化编排已经成为痛点

那 Temporal 更适合先知道它能解决什么，而不是立刻引入。

2. 完整多租户设计​

多租户是典型的“迟早会来，但现在不一定该先做满”的能力。

如果系统当前都还没有稳定的单租户边界，过早做多租户通常只会把复杂度提前引爆。

3. 全套企业治理链路​

OPA、全套策略治理、组织级配置分发这些都很重要，但前提是你已经真的进入多团队、多环境、多合规约束的场景。

在那之前，它们更适合作为认知储备，帮助你避免把未来彻底锁死，而不是现在就一股脑全上。

一个实际的带走顺序​

如果让我把书里的模式按“进入项目的优先级”排一下，我会这样排：

  1. 编排收益 vs 协调成本
  2. 控制平面 / 执行平面责任分离
  3. 预算意识前置
  4. 权限边界前置
  5. 可观测性留接口
  6. Temporal / 多租户 / 完整治理体系按需进入

最后一个提醒​

AI Agent Book 最大的价值，不是让你觉得“原来还有这么多高级模式”，而是帮你建立一种节奏感：

  • 先立住会决定系统生死的边界
  • 再决定哪些模式现在真该进项目
  • 剩下的先放进脑子，不要急着放进代码

如果这个节奏感建立起来，这本书就没有白读。