第 2 章：安全智能体的参考架构¶

怎样读这一章

第一遍不用试着记住所有层的名字。

更有用的是先完成三件事：

顺着一个支持请求走完整条路径；
看清系统的行动权到底从哪里开始；
记下几个必需层，因为没有它们，请求就不能安全地走到外部副作用。

1. 不要先看层，要先看一个活生生的案例¶

继续沿用上一章里的支持智能体。

用户写道：

我已经等了三天权限开通。请帮我查一下状态，如果申请卡住了，就创建一个加急工单。

如果把这个任务想得过于简单，后面的流程看上去似乎很直白：

模型读消息；
选择合适的工具；
检查状态；
创建工单；
返回答复。

但生产系统不能建立在这种“大致如此”的想象上。因为太多关键问题还没有被回答：

到底是谁在请求这个动作；
这个请求具有什么权限；
智能体到底能不能创建工单；
创建工单是否需要审批；
哪些上下文允许送进模型；
如果工具返回的是部分结果或不稳定结果，该怎么办；
发生事故以后，怎样把整条链路重新还原出来。

平台架构，正是从这些问题里长出来的。它不是出于对“分层”的偏爱，而是因为这些问题必须在高风险写路径出现之前就得到回答。

2. 智能体的最小形状，以及为什么它还不够¶

一开始不用把整张图都装进脑子里。先分清两件事就够了：

智能体系统的最小核心；
让这个核心不再只是原型的生产外层。

OpenAI 的实用指南有一个很好的起点：最小的智能体系统通常只有三样东西。³

model
tools
instructions

这是一个很好的起步框架，因为它能防止你过早过度设计。

但对生产来说，这还不够。只要系统开始拥有：

对内部系统的访问；
私有数据；
长会话；
写路径动作；
审批；
多个团队和多种访问角色，

这个最小三元组就不再是架构了。它只是核心，而不是平台。

这正是对上一章论点的进一步证明。model + tools + instructions 足以让一个原型看起来会工作，但它已经不足以解释权限、副作用、问责和恢复，一旦系统真正接触现实环境，这些问题就会立刻出现。

2.1. 哪些属于运行时架构，哪些不属于¶

这里最好再画一条边界，因为团队很容易把运行时设计、模型训练和产品表面混在一起。

通常属于智能体运行时架构的，会包括：

model；
instructions；
tools；
memory；
规划例程或技能；
runtime；
防护栏和策略。

但也有几样东西通常不属于运行时架构：

训练数据集和奖励模型属于模型开发与训练，而不属于运行时；
用户界面属于产品表面，而不属于智能体核心逻辑；
上下文窗口是所选模型的属性，而不是一个独立的架构层。

这一区分看起来有点理论化，但实践里非常有用。如果系统开始在工具路由、审批路径或检索纪律上退化，原因通常在运行时轮廓，而不是在界面或奖励模型。

3. 一个请求应该怎样穿过系统¶

现在，把同一个支持案例当作一条架构路径来看。

3.1. 入口¶

消息不应该直接飞进模型。系统首先要把它变成一个标准化请求：

用户是谁；
请求属于哪个 tenant；
来自哪个入口渠道；
风险等级是什么；
属于哪个 session 和哪个 trace_id；
会被哪组策略约束。

换句话说，进入系统的不是“文本”，而是一个可管理的执行上下文。

3.2. 控制层¶

接下来，系统必须先决定这次运行到底被允许做什么：

可以使用哪些模型；
可以调用哪些工具；
哪些动作必须先经过审批；
有哪些额度或限制；
当前环境里有哪些禁区。

这就是控制平面。它负责的不是“聪明”，而是系统有没有权利行动。

3.3. 运行时¶

然后请求才进入运行时，在这里确定执行模式：

这里普通工作流就够；
这里需要 single-agent loop；
这里必须插入审批中断；
这里需要先写入检查点，之后再继续。

一个好的运行时往往很“无聊”。它不是靠魔法取胜，而是靠可预测性取胜。

3.4. 模型层¶

只有这时模型才真正登场：

接收整理过的上下文；
决定下一步；
提议调用工具或者生成文本答复；
把结构化结果返回给运行时。

这里最重要的区分是：模型可以提出动作建议，但它不应该是唯一决定“能不能执行”的地方。

3.5. 工具层¶

如果智能体想检查申请状态，或者创建工单，它不应该直接进入外部世界。那是工具网关的工作：

检查策略决策；
在需要时要求审批；
隔离副作用；
把结果返回给运行时；
把事件写入追踪。

3.6. 追踪与评估¶

系统每走一步，都应该留下痕迹：

模型做了什么判断；
调用了哪个工具；
哪个策略门禁生效了；
是否触发审批；
延迟在哪一步上升；
故障发生在什么位置。

如果没有这些东西，你拥有的不是平台，而是一个复杂黑箱。

4. 到了这里，再看整张图才真正有意义¶

如果你在这里仍然觉得这张图有点密，不用急着记住所有模块名称。先回答四个问题就够了：

执行上下文是从哪里形成的；
行动权到底放在哪里；
系统在哪里留下了足够支撑排障和发布决策的证据；
运行时针对这一类任务到底选择了哪一种编排模式。

现在再回头看平台全图，就更容易理解它为什么存在。

安全智能体平台的参考结构图

flowchart TB
    user["User / API / Event"] --> interface["Interface layer"]
    interface --> identity["Identity & session layer"]
    identity --> control["智能体控制平面"]
    control --> runtime["编排运行时"]
    runtime --> cognition["认知平面"]
    runtime --> memory["记忆与知识平面"]
    runtime --> tools["工具执行平面"]
    runtime --> telemetry["遥测与评测平面"]
    tools --> external["外部系统 / MCP / SaaS"]
    memory --> stores["Vector DB / KB / 画像记忆"]
    control --> approval["审批 / 策略 / 配额"]
    telemetry --> audit["追踪 / 指标 / 审计"]

这张图里真正重要的不是层的“好看”，而是每一层都在回答一个原型自己答不出的失败问题：

层	负责什么	缺了会怎样
接口层	Chat、API、webhooks、events	否则入口渠道和执行逻辑会混在一起
身份与会话层	用户、服务账号、tenant、request scope	否则 IAM、审计和隔离都会失效
智能体控制平面	策略、审批、限额、目录	否则系统会在缺乏控制的情况下行动
编排运行时	工作流图、规划器、检查点	否则一旦流程变复杂，执行就会散掉
认知平面	模型路由器、提示组装、验证器	否则模型会重新变成“世界中心”
记忆与知识平面	状态、记忆、检索	否则上下文会无纪律地膨胀
工具执行平面	网关、沙箱、副作用隔离	否则爆炸半径太大
遥测与评测平面	追踪、指标、数据集、回归门禁	否则质量无法被测量和调查

如果只看文本版，这张图可以压缩成一条链：入口先变成带身份边界的 execution context；control plane 决定什么被允许；runtime 选择并保存执行路径；cognition、memory 和 tools 只能通过各自边界工作；telemetry 与 evals 留下可用于调查和发布决策的 evidence。

5. 生产平台的五个支柱¶

Google Cloud 最近的材料还给出了一条很实用的补充框架：不要围绕“一个聪明智能体”思考，而要围绕生产平台的五个支柱思考。⁴

framework
model
tools
runtime
trust

这个框架之所以有价值，是因为它很快就能戳破自我安慰。

如果你只有：

一个强模型；
一个不错的提示；
几个工具，

但没有 runtime 和 trust，那你依然没有平台。你只有原型。

6. 哪些架构决策必须显式做出来¶

有些决策，最好在一开始就明确，而不是“先做着看”。

6.1. 你的上下文层到底有哪些¶

Google 通过上下文层来约束提示组装，这一点非常实用。⁵⁶

在实践里，通常至少要分出：

static context：角色、策略、允许的能力、固定指令；
session context：跨会话持续存在的上下文；
turn context：只属于当前请求的上下文；
cached context：按需注入的上下文。

实用规则很简单：进入提示的不应该是“所有能拿到的数据”，而应该是“用途和生命周期都清楚的数据”。

6.2. 行动权到底放在哪里¶

模型不应该直接拥有执行外部副作用的权力。

真正的行动权应该存在于下面这个组合里：

策略引擎；
审批逻辑；
工具网关。

这就是控制平面如此重要的原因：它把“模型建议这样做”和“系统被允许这样做”清楚地分开。

6.3. 什么时候才值得拆成多个智能体¶

OpenAI 的实用指南有一点很对：不要把 multi-agent 当成默认答案。³ Microsoft 最新的架构指南在这里也很有价值，因为它把复杂度升级路径说得更明确了：团队应该先问，这个问题是否仍然只是直接模型调用，然后再问一个带工具的单智能体是否已经足够，只有在这之后才进入多智能体编排。⁷

这条纪律很重要，因为每多一个智能体，通常就会多出：

一条新的上下文边界；
一条新的协调路径；
一次新的延迟跳点；
一个新的失败表面；
一条新的负责人机制与策略边界。

通常只有在这些信号出现时，拆分才是合理的：

一次运行的上下文已经太拥挤；
子任务需要不同的工具和不同的防护栏；
负责人机制已经分到不同团队；
并行执行确实能降低延迟或认知负载；
安全边界差异已经大到不该由一个智能体持有全部权限。

如果这些信号不存在，一个带良好工作流图的单智能体通常更简单，也更可靠。

一条实用的复杂度升级阶梯可以写成：

direct model call 处理单步任务；
single agent with tools 处理单一领域中的动态动作；
multi-agent orchestration 只在专门化、安全分离或并行分解确实值得额外运行时复杂度时才采用。

Anthropic 的模式目录让这条阶梯变得不那么抽象，因为它把团队在走向完整智能体自治之前，通常真正需要的中间工作流形态点了出来。¹ 在实践里，真正容易漏掉的问题往往不是“我们需不需要智能体？”，而是“哪一种更小的编排模式已经足够安全地解决这个问题？”

这通常意味着应该先检查这些选项：

prompt chaining，适用于可以拆成固定串行步骤、并在中间插入门禁的任务；
routing，适用于输入可以分成少数几类，而这些类别值得走不同提示、工具或下游路径的任务；
parallelization，适用于把独立检查拆开后能提高置信度或降低延迟的任务；
orchestrator-workers，只在子任务事先无法知道、必须动态委派时才采用；
evaluator-optimizer，适用于迭代式批评能实质改善产物的任务。

这在架构上很重要，因为这些不只是提示技巧。每一种模式都会改变运行时里检查点、审批、重试、追踪边界和负责人机制应该放在哪里。

这条阶梯的价值在于，它把架构变成一种显式的反过度工程纪律。真正该问的问题不是“我们能不能把它拆成多个智能体？”，而是“什么样的最低复杂度形态，仍然能在生产中可靠运行？”

7. 给架构复杂度做一次快速成熟度测试¶

团队不应该只因为已经有一个智能体、几种工具和一张分层图，就觉得自己的架构已经成熟。

更高的标准应该是：

团队能够解释，当前问题为什么仍然是直接模型调用、带工具的单智能体，还是多智能体系统；
沿着这条阶梯的每一次升级，都来自真实的运营压力，而不是新奇感；
新增智能体带来的是清晰的专门化或控制收益，而不是模糊的“更高级”；
架构明确消除了动作权限、副作用和审批究竟放在哪里的歧义；
生成出来的运行时在事故发生时仍然能被操作员解释清楚。

如果这些条件不成立，系统在幻灯片上也许看起来很“有架构”，但在实践里已经开始过度复杂化。

8. 什么东西绝对不要混在一起¶

至少有四样东西，从一开始就值得分开：

短期状态：当前执行状态；
长期记忆：事实、画像、片段；
检索：对外部知识的访问；²
工具执行：在外部世界里真正发生的动作。

系统还小的时候，这种分离看起来可能像官僚主义。等第一起严重事故真的发生，它就会看起来像工程卫生。

9. 一个最小代码原则¶

如果你想用最紧凑的方式看清这个设计，下面这个模板就够了：

from dataclasses import dataclass


@dataclass
class ToolRequest:
    tool_name: str
    actor_id: str
    risk_class: str
    payload: dict


def execute_tool(request: ToolRequest, policy_engine, approval_service, gateway):
    decision = policy_engine.evaluate(request)
    if not decision.allowed:
        raise PermissionError(decision.reason)

    if decision.requires_approval:
        approval_service.require_human_signoff(request, decision)

    return gateway.call(request.tool_name, request.payload)

这里的核心只有一句话：模型可以提议动作，但真正的执行权在网关和策略层，不在模型里。

10. 给你自己系统做一次快速架构审查¶

如果你已经有一个智能体或类智能体工作流在生产里运行，可以把这一章当作一份简短的审查清单。

你应该能清楚回答这些问题：

请求是在什么地方被标准化为可管理的执行上下文？
系统是在什么地方决定“什么被允许”？
哪些动作必须审批，这个约束是在哪里执行的？
哪些副作用只能经过网关或沙箱？
哪些字段一定会进入追踪？
在重试、部分失败或重启之后，系统会怎样表现？

如果这些答案只存在于提示、口头约定或团队记忆里，那说明这套架构仍然过于隐式。

11. 这一章真正要带走什么¶

简短地说，一个好的智能体平台建立在几件很“无聊”、但极其值钱的东西上：

显式的入口上下文；
控制平面；
独立的运行时；
独立的工具网关；
独立的追踪和评测；
只在确实需要的地方加审批。

架构之所以重要，不是因为图更好看，而是因为它能阻止系统在第一次真正复杂起来的时候散架。

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

如果你现在就在设计一个智能体系统，先写下至少这五件事：

你的执行上下文从哪里开始？
行动权放在哪里？
第一版运行时模式是什么？
哪些副作用只能通过网关？
团队第一天就必须在追踪里看见哪些字段？

如果这些东西已经写清楚了，架构就开始存在了。如果没有，那你现在还只有一个“智能体想法”。

13. 本章的证据模型¶

本章结合了几类证据：

稳定主张： identity、policy、approval、tool execution、memory 和 telemetry 不应该被压缩进 prompt。
厂商实践： OpenAI、Google Cloud、Microsoft 与 Anthropic 都把 agents 描述成由 models、tools、instructions、orchestration 和 governance 组成的系统，而不是裸模型调用。
运行时实践： gateways、policy engines、approval services 和 trace schemas 是让行动权可检查的具体方式。
另一种观点： 有些团队更喜欢把 local guardrails 放在每个工具或产品表面里，因为它们离代码更近，变化也更快。对于小型、低风险系统，这可能有效。本章的主张是：当同一个智能体跨越 tenants、tools、approvals 或 write paths 时，应该有共享的 policy/control layer，因为只靠局部规则会让行动权的一致审计变得更难。
作者解释： 精确的层名称不如 rights、side effects、state 与 evidence 的分离重要。
快速变化层： productized agent builders 与 orchestration frameworks 会继续变化；章末的 review questions 应该能跨越这些变化继续有用。