1. 引言：当"原则"遇上"智能体"
过去两年，AI 安全治理的主旋律是"立规矩"——从伦理原则、风险分级到合规清单，行业已经积累了相当多的共识文本。但当 AI 从"被动应答的模型"演进为"能自主规划、调用工具、长期运行的智能体（Agent）"时，一个尖锐的问题浮现出来：
我们并不缺原则，缺的是把原则翻译成工程能力的那一层。
2025 年以来，几个标志性动作让这一判断变得清晰：国内《人工智能安全治理框架》迭代至 3.0 版本，并首次以附件形式发布《智能体风险管理框架》；美国 NIST 启动"AI 智能体标准倡议"；中国信通院发布《智能体部署风险管理指南》。治理的重心，正在从"倡导"转向"落地"。
本文尝试梳理这条演进路径：智能体到底带来了哪些新风险、全生命周期该如何拆解、以及国内外标准与指南分别给出了什么可操作的抓手。
下面这张图概括了本文的论述主线：从"原则倡导"到"能力落地"的演进路径。
flowchart TD
A["原则倡导阶段"] --> B["智能体形态演进"]
B --> C["三类风险特征"]
C --> D["全生命周期风险梳理"]
D --> E["七大类防范措施"]
E --> F["标准与指南支撑"]
F --> G["能力落地：可定义 / 可观测 / 可干预"]
2. 一个信号：智能体风险管理被单独"拎出来"
《人工智能安全治理框架》3.0 的一个关键变化，是把智能体风险管理从"通用 AI 风险"中独立出来，以附件形式专门成文。
这个形式本身就有信息量：
- 从"包含"到"单列"：智能体不再被视为大模型的一个应用场景，而是具有独立风险结构的技术形态；
- 从"原则"到"框架"：附件给出的是可拆解的风险维度与措施清单，而非价值宣示；
- 从"模型侧"到"系统侧"：关注点从模型输出内容，扩展到智能体所处的工具链、数据流与运行环境。
换句话说，监管与标准制定者已经意识到：用治理聊天机器人的方法，治理不了会自己干活的智能体。
从治理视角看，这一"单列"动作对应着关注重心的三重迁移：
flowchart LR
subgraph OLD["传统 AI 治理"]
O1["包含于通用风险"]
O2["原则与价值宣示"]
O3["模型输出内容"]
end
subgraph NEW["智能体治理"]
N1["独立风险结构"]
N2["可拆解措施清单"]
N3["工具链 / 数据流 / 运行环境"]
end
O1 --> N1
O2 --> N2
O3 --> N3
3. 智能体的三类风险特征
要设计治理能力，先要理解风险形态的差异。相比传统 AI 应用，智能体风险有三个显著特征。
3.1 动态演化
智能体的行为不是一次性生成的，而是在"感知—规划—行动—观察"的循环中逐步展开。同一段提示词，在不同工具返回、不同记忆状态下可能走出完全不同的执行路径。
这意味着：静态的输入输出审查无法覆盖风险。风险可能在第 7 步才出现，而前 6 步看起来都完全正常。
可以用一个循环图来理解这种动态性——风险在循环中逐步累积，而非在入口处一次性暴露：
flowchart LR
P["感知"] --> PL["规划"]
PL --> AC["行动（工具调用）"]
AC --> OB["观察结果"]
OB --> P
AC -.->|"第 N 步才暴露风险"| RK["风险点"]
3.2 长期累积
智能体往往具备记忆与状态持久化能力。一次无害的操作可能被写入长期记忆，在后续任务中被反复引用、放大，形成"风险沉淀"。
典型场景包括：错误结论被写入知识库、越权获取的数据被缓存、用户偏好被过度泛化。
记忆污染一旦形成，会沿着"写入—引用—放大"的链路持续扩散：
flowchart LR
A["一次无害操作"] --> B["写入长期记忆"]
B --> C["后续任务反复引用"]
C --> D["错误结论被放大"]
D --> B
D --> E["风险沉淀"]
3.3 跨系统扩散
智能体通过工具调用连接外部系统——数据库、代码仓库、邮件、支付接口、其他智能体。一次越权调用可能沿着调用链扩散，影响面远超单个应用边界。
这也带来了责任归属的难题：当 A 智能体调用 B 智能体、B 又操作了 C 系统，出了问题该由谁负责？
flowchart LR
U["用户指令"] --> A["规划智能体"]
A --> T1["工具：数据库"]
A --> T2["工具：代码仓库"]
A --> B["子智能体"]
B --> T3["工具：外部 API"]
T1 --> R["风险扩散面"]
T2 --> R
T3 --> R
4. 全生命周期风险梳理与七大类防范措施
把风险按生命周期拆开，是让治理"可落地"的第一步。一个较为通用的划分是：设计开发 → 部署上线 → 运行使用 → 退役下线。
4.1 各阶段的主要风险
4.2 七大类防范措施
围绕上述风险，可将措施归纳为七大类，形成从"制度"到"技术"的完整闭环：
- 治理与责任机制：明确智能体的责任主体、审批流程与问责路径，建立风险分级与上线评审制度。
- 权限最小化与隔离：按任务授予最小必要权限，工具调用采用白名单，敏感操作强制人工确认。
- 输入输出与行为管控：对提示注入、工具返回内容做校验，对关键动作设置策略拦截与速率限制。
- 可观测与审计：全链路记录规划步骤、工具调用参数与返回结果，保证行为可回溯、可复现。
- 记忆与数据治理：对长期记忆设置写入校验、时效与来源标记，防止污染扩散。
- 评测与红队测试：在上线前进行对抗性测试，覆盖越权、注入、目标劫持等场景，并持续回归。
- 应急响应与熔断：设置异常行为检测、自动降级与一键熔断机制，明确事故处置流程。
这七类措施的共同点是：都可以被工程化实现，而不是停留在"应当加强安全管理"的表述层面。
把七类措施按生命周期串起来，可以形成一条完整的防护链：
flowchart LR
subgraph DEV["设计开发"]
M1["治理与责任机制"]
M2["权限最小化与隔离"]
M6["评测与红队测试"]
end
subgraph RUN["部署与运行"]
M3["输入输出与行为管控"]
M4["可观测与审计"]
M5["记忆与数据治理"]
end
subgraph INC["异常处置"]
M7["应急响应与熔断"]
end
DEV --> RUN
RUN --> INC
INC -.->|"复盘反哺"| DEV
5. 国际视角：NIST 的"AI 智能体标准倡议"
在大洋彼岸，NIST 启动的"AI 智能体标准倡议"释放了相似的信号：标准体系需要针对智能体这一形态重新组织。
其关注点大致集中在几个方向：
- 互操作与接口标准：智能体之间、智能体与工具之间的通信协议需要统一，否则安全边界无从定义；
- 身份与授权：智能体如何被识别、如何获得与让渡权限，是跨系统协作的前提；
- 评测方法与基准：需要可复现的测试集与评价指标，来衡量智能体的安全表现；
- 风险分类与术语统一：为跨组织协作与监管对接提供共同语言。
值得注意的是，NIST 的路径偏向"标准与评测基础设施"，而国内框架更强调"治理体系与责任落实"。两者互补，共同构成智能体安全治理的两条腿。
6. 落地视角：信通院《智能体部署风险管理指南》
如果说框架解决"管什么"，那么部署指南解决的是"怎么管"。中国信通院的《智能体部署风险管理指南》更贴近工程实践，其价值主要体现在把抽象要求转化为部署环节的具体动作。
从落地角度看，可以提炼出几条可执行的实践建议：
- 上线前做一次"权限体检"：逐个核对智能体可调用的工具与数据范围，删除"为了跑通而临时放开"的权限；
- 给关键动作加"人闸"：涉及资金、删除、对外发送的操作，默认需要人工确认；
- 建立行为日志基线：先跑一段时间建立正常行为画像，再基于偏离度做异常告警；
- 把记忆当数据资产管：明确哪些内容可写入长期记忆、保留多久、如何追溯来源；
- 准备一份"熔断预案"：明确什么条件下停止智能体、由谁决策、如何回滚。
这些动作并不复杂，但恰恰是"从原则到能力"之间最容易被跳过的一层。
7. 结语：治理能力的三个落脚点
回看这一轮演进，智能体安全治理的落地，最终会收敛到三个落脚点：
- 可定义——风险被拆解到具体阶段与具体动作，而不是笼统的"安全风险"；
- 可观测——智能体的每一步行为都能被记录、复现与审计；
- 可干预——在风险发生时，有权限、有机制、有预案去中止与回滚。
原则倡导解决的是"要不要做"，能力落地解决的是"做不做得成"。当智能体开始真正替我们做事，后者的分量只会越来越重。
对于一线的开发者与架构师而言，现在正是把安全能力前置到设计阶段的窗口期——等到智能体已经在生产环境里跑起来，再补这堂课，成本会高得多。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。