夜雨聆风
首发全文翻译|从腾讯、谷歌到 OpenClaw:新加坡与时俱进的最全3万字《智能体模型治理框架》解读
本文为《新加坡AI智能体治理框架 v1.5》的独家中文完整翻译。该指南为全球首个涵盖多智能体、工具调用与人类监督，并明确纳入 OpenClaw 等前沿实践的官方指南。前言部分附带了我们专门为国内企业准备的合规与落地指引。
译者导读与合规建议：新加坡《AI智能体治理框架 v1.5》
核心摘要
新加坡信息通信媒体发展局（IMDA）最新发布的《智能体治理框架（v1.5版）》（Model AI Governance Framework for Agentic AI）是对既有 AI 治理体系的重大升级，专门针对具备自主规划、工具调用和执行能力的新一代“代理型 AI（Agentic AI / 智能体）”提出了结构化的治理指南。
与被动的生成式 AI 不同，AI智能体能够代表人类执行复杂工作流甚至不可逆的行动。这种自主性和复杂性带来了更高的系统性风险、多智能体交互风险以及自动化偏见。为此，该框架提出了四个核心治理维度：
- 预先评估并界定风险边界
：评估用例的适用性，通过架构设计（如限制操作空间、读写权限分离）预先设定自主性的物理边界。 - 使人类承担有意义的问责
：在模型开发者、平台方和部署者等价值链各环节清晰划分责任；在智能体执行高风险行动前，设立必须由人类介入的“关键检查点（Checkpoints）”，并防范人类的“告警疲劳”。 - 实施技术控制和流程
：在设计阶段嵌入针对规划、工具调用和协议（如 MCP）的专门护栏；采用“沙盒”进行部署前测试，并在生产环境中进行持续的实时监测。 - 促进终端用户责任
：向内部员工和外部用户提供充分的透明度提示，说明智能体的能力边界与潜在缺陷，提供专项培训以提升用户审查智能体输出的能力。
v1.5 版的亮点在于引入了大量行业前沿的真实案例（包括腾讯 CodeBuddy、OCBC 银行、PwC、Google 沙盒测试等），为抽象的治理原则提供了高参考价值的落地范式。
—
企业合规与落地指引（Compliance Guidance）
对于正在探索或已经部署 AI 智能体（Agent）工作流的企业而言，本框架提供了极具实操性的合规对照表。企业在落地代理型 AI 时，建议重点关注以下合规与风控动作：
1. 严格落实“最小权限原则”与智能体身份管理
企业应当将智能体视作具有特定操作权限的“机器员工”。对于它所调用的工具（Tools）和外部接口（API），必须遵循“最小权限（Least Privilege）”原则。对于仅需信息检索的任务，坚决不授予写入或删除权限。此外，应为不同的智能体分配独立的身份标识（Agent ID），以确保所有的操作日志、数据访问和资源消耗均可追溯。
2. 建立“人在环路中（HITL）”的强制审批机制
在涉及金融交易、人力资源决策（如筛选简历）、生产环境代码修改、敏感数据流转等高风险场景时，智能体绝不能实现端到端的完全自治。企业必须在流程的关键节点设计强制的人工审批流。审批界面需提供智能体的“推理过程（Reasoning）”或“执行意图解释”，以帮助人类员工做出有效判断，对抗过度依赖 AI 带来的“自动化偏见”。
3. 管控多智能体协同与第三方协议风险
随着 MCP（模型上下文协议）等标准的普及，智能体可能会直接与其他第三方系统或外部智能体进行数据交互。企业在合规审查时，需穿透审查这些第三方平台的安全资质与数据隐私条款，避免敏感业务数据在未经授权的跨智能体通信中发生泄漏。
4. 建立灰度发布与持续监控体系
鉴于智能体 在真实环境中的涌现能力和幻觉具有不可预测性，企业不应跳过沙盒测试直接全量上线。建议采用“内部小范围测试 -> 限定功能灰度 -> 全量发布”的演进路线，并建立实时的拦截与告警机制（例如监测异常高的 API 调用频率或超出常规行动轨迹的越权请求），一旦发生异常立刻将控制权交还人类。
—
AI智能体治理框架
Version 1.5 | 发布日期：2026年5月20日
目录
执行摘要
本版本新增内容
1 智能体 AI 简介
1.1 什么是智能体 AI？
1.1.1 智能体的核心组成部分
1.1.2 多智能体设置
1.1.3 智能体设计如何影响每个智能体的边界和能力
1.2 智能体 AI 的风险
1.2.1 风险来源
1.2.2 风险类型
1.2.3 系统性风险和多智能体风险
2 智能体 AI 治理框架
2.1 预先评估并界定风险边界
2.1.1 确定适合部署智能体的用例
2.1.2 通过设计界定风险边界，明确智能体的限制和权限
2.2 使人类承担有意义的问责
2.2.1 在组织内外清晰分配责任
2.2.2 为有意义的人类监督而设计
2.3 实施技术控制和流程
2.3.1 在设计和开发阶段使用技术控制
2.3.2 部署前测试智能体
2.3.3 部署时持续监测和测试
2.4 促进终端用户责任
2.4.1 不同用户，不同需求
2.4.2 与智能体互动的用户
2.4.3 将智能体整合进工作流程的用户
执行摘要
智能体 AI 是 AI 的下一阶段演进，对用户和企业具有变革性潜力。与生成式 AI 相比，AI 智能体能够采取行动、适应新信息，并与其他智能体和系统互动，代表人类完成任务。虽然相关用例正在快速演进，但智能体已经通过代码助手、客服智能体以及企业生产力工作流自动化，改变工作场所。
这些更强的能力也带来了新的风险。智能体访问敏感数据并改变其环境的能力，例如更新客户数据库或进行支付，是一把双刃剑。随着我们走向部署多个具有复杂交互的智能体，结果也会变得更加不可预测。
人类必须继续承担问责，并妥善管理这些风险。虽然透明度、问责和公平等可信 AI 的既有治理原则仍然适用，但它们需要在实践中针对智能体加以转化。此外，有意义的人类控制和监督需要被整合进智能体 AI 生命周期。然而，也需要取得平衡，因为在规模化场景下，对所有智能体工作流持续进行人类监督会变得不切实际。
《智能体治理框架》（Model AI Governance Framework for Agentic AI，MGF for Agentic AI）为组织提供了一个结构化概览，说明智能体的风险以及管理这些风险的新兴最佳实践。如果风险得到妥善管理，组织就能够更有信心地采用智能体。MGF 面向计划部署智能体的组织，无论其是内部开发AI智能体，还是使用第三方智能体解决方案。
在我们此前治理框架的基础上，我们为组织概述了智能体四个方面的关键考虑因素：
- 预先评估并界定风险边界
组织应调整其内部架构和流程，以应对智能体带来的新风险。其中的关键，是首先理解智能体行动所产生的风险；这些风险取决于智能体可采取行动的范围、这些行动的可逆性以及智能体的自主程度等因素。
为及早管理这些风险，组织可以在规划阶段设计适当边界，限制智能体的影响范围，例如限制其访问工具和外部系统。组织还可以通过智能体身份管理和访问控制等措施，确保智能体的行动可追踪、可控制。
- 使人类承担有意义的问责
一旦智能体部署获得“绿灯”，组织就应采取措施确保人类问责。
然而，智能体的自主性可能会使传统责任分配复杂化；传统责任分配通常与静态工作流绑定。智能体生命周期的不同部分也可能涉及多个参与者，从而稀释问责。因此，清晰界定组织内部不同利益相关方以及外部供应商的责任非常重要，同时还要强调适应性治理，使组织能够快速理解新的发展，并随着技术演进更新其方法。
具体而言，“人在环路中”（human-in-the-loop）需要被调整，以应对自动化偏见；随着智能体能力日益增强，自动化偏见已经成为更大的关切。这包括在智能体工作流中界定需要人工批准的重要检查点，例如高风险或不可逆行动，并定期审计人类监督，以检查其是否能够随时间推移继续保持有效。
- 实施技术控制和流程
组织应通过在智能体生命周期各阶段实施技术措施，确保 AI 智能体安全、可靠地投入运行。
在开发阶段，组织应针对规划、工具以及仍在成熟中的协议等新的智能体组件纳入技术控制，以应对这些新攻击面带来的更高风险。
部署前，组织应测试智能体的基线安全性和可靠性，包括整体执行准确性、政策遵循情况和工具使用等新的维度。评估智能体将需要新的测试方法。
在部署期间和部署之后，由于智能体会与其环境动态互动，而且并非所有风险都能预先预测，建议组织在部署后持续监测的同时逐步推出智能体。
- 促进终端用户责任
可信地部署智能体并不完全依赖开发者，也依赖终端用户以负责任的方式使用智能体。为了促进负责任使用，作为基线，应告知用户智能体的行动范围、对数据的访问以及用户自身责任。组织应考虑叠加培训，使员工掌握管理人机互动和进行有效监督所需的知识，同时保持其专业技艺和基础技能。
本文档是一份持续演进的文件。我们已与政府机构和领先企业合作，汇集当前最佳实践并贡献真实世界案例研究，但这是一个快速发展的领域。本框架需要持续更新，以跟上新的发展。我们欢迎反馈，以完善本框架，也欢迎更多案例研究，展示如何应用本框架实现负责任的智能体部署。
本版本新增内容
本版本纳入了自 v1.0 以来从 60 多家公司收到的反馈。主要变化包括：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 智能体简介
1.1 什么是智能体？
关于如何定义 AI 智能体，目前尚无共识，但存在一些共同特征：智能体通常具有一定程度的独立规划、决策和行动能力（例如搜索网页或创建文件），能够通过多个步骤实现用户定义的目标。智能体系统是由一个或多个 AI 智能体组成的软件系统，这些智能体可以单独运行，也可以协作运行。
在本框架中，我们聚焦于基于生成式 AI 模型构建的智能体；这类智能体正被越来越多地采用。一般而言，这类智能体使用小语言模型、大语言模型或多模态大语言模型（SLM、LLM 或 MLLM）作为其“大脑”，以作出决策并完成任务。不过，值得注意的是，软件智能体并不是一个新概念，其他类型的智能体也已存在，例如使用确定性规则或其他神经网络作出决策的智能体。
1.1.1 智能体的核心组成部分
由于智能体构建在语言模型之上，从简单的基于 LLM 的应用的核心组成部分入手会有所帮助；智能体会以类似方式使用这些组成部分。
-
模型：作为中央推理和规划引擎，或智能体“大脑”的 SLM、LLM 或 MLLM。它处理指令、解释用户输入，并生成符合语境的适当回应。 -
指令：定义智能体角色、能力和行为约束的自然语言命令，例如 LLM 的系统提示。 -
记忆：被存储并可供 LLM 访问的信息，可以位于短期或长期存储中。有时会添加记忆，使模型能够从此前用户互动或外部知识来源中获取信息。
此外，智能体还具有其他组成部分，使其能够完成更复杂的任务：
-
规划与推理：模型通常经过训练，能够进行推理和规划，这意味着它能够输出完成任务所需的一系列步骤。 -
工具：工具使智能体能够采取行动并与其他系统互动，例如写入文件和数据库、控制设备或执行交易。模型调用工具来完成任务。智能体本身也可以作为工具被调用，例如一个监督型智能体为某项任务调用另一个专门智能体。 -
协议：智能体与工具以及其他智能体通信的标准化方式。例如，Model Context Protocol（MCP）已经被开发用于智能体与工具通信，而 Agent2Agent Protocol（A2A）则定义了智能体彼此通信的标准。这是一个快速发展的领域，更多协议正在被开发，用于标准化智能体交互，尤其是在智能体商务领域。
除这些使能组件外，智能体通常还具有用于安全可靠运行的组件：
-
控制：控制限制智能体的行动空间和自主性。虽然控制有很多类型，但与智能体最相关的是： -
访问控制：这些控制限制智能体被允许查看、使用或改变的内容，包括限制其访问敏感数据、工具和系统。 -
护栏：护栏在智能体行动之前、期间或之后监测并约束其行为。它可以帮助检测不安全指令、政策违规，或看似与用户意图不一致的行动。 -
人工批准：要求人类审查或批准智能体行动。 -
日志记录和监测：记录智能体在所有组成部分中的行动、决策和互动，以支持监测、调试和问责。
1.1.2 多智能体设置
在智能体系统中，设置多个智能体共同工作是常见做法。这使每个智能体能够专门处理某项功能或任务，并且/或者并行工作。与单个智能体访问许多工具相比，让多个智能体分别专门负责不同任务，也意味着每个智能体的工具和权限可以被分别限定和定义。
多智能体系统有三种简单设计模式：
-
顺序型：智能体在线性或其他结构化工作流（例如图）中一个接一个工作。每个智能体的输出成为下一个智能体的输入。 -
监督型：一个监督智能体协调其下的专门智能体，在需要时将特定智能体作为工具调用。 -
群体型：智能体同时工作，并在需要时交接给另一个智能体。
多智能体设置并不存在普遍正确的架构，手头任务可能需要不同模式或混合模式。一个定义清晰、具有逐步工作流的任务，可能适合顺序型架构；而更开放、需要头脑风暴或沿不同调查线索推进的任务，可能受益于群体型架构。
1.1.3 智能体设计如何影响每个智能体的边界和能力
虽然每个智能体可能具有相同的核心组成部分，但每个组成部分的设计会显著影响智能体能够做什么。
在考虑智能体能够做什么时，通常有助于区分两个概念：
|
行动空间 （或权限、能力） 智能体可以采取的行动范围，包括其可以执行的交易，由其被允许使用的工具以及这些工具上的权限决定。 |
自主性 （或决策） 智能体能够在多大程度上决定如何朝目标行动，例如通过定义应采取的步骤来行动，由其指令和人类参与程度决定。 |
行动空间
智能体的行动空间主要取决于其可以访问的工具，这可能影响：
-
其可以访问的系统： -
仅限沙盒：不能影响任何其他系统的沙盒工具（例如用于代码执行、数据分析的工具）。 -
内部系统：组织内部的工具，例如能够搜索和更新组织数据库。 -
外部系统：使智能体能够访问外部服务的工具，例如通过第三方预定义 API 检索和更新数据。 -
其可以就可访问系统采取的行动： -
读取与写入：智能体可能只能从系统读取和检索信息，而不能向系统写入和修改数据。
智能体 AI 的一种新兴形态是计算机使用智能体，其主要工具是访问计算机和浏览器。这意味着它可以采取人类能够通过计算机和浏览器采取的任何行动（例如滚动、点击、输入），而不必依赖具体定义的工具和 API。这显著扩大了智能体能够访问和执行的范围。
自主性
智能体的自主性主要取决于其指令以及智能体系统中的人类参与程度。在企业部署中，大多数智能体实现都是将确定性规则与一定自主性结合起来的混合系统。
就指令而言，智能体可以被赋予不同层级的指令：
-
详细指令和标准操作程序：被指示按照详细标准操作程序完成任务的智能体，在每个阶段可作出的决策会受到限制。 -
使用自身判断：被指示使用自身判断完成任务的智能体，将有更大的自由来定义其计划和工作流。
另一个相关因素是人类参与程度。在与智能体互动时，人类可以以不同程度参与：
-
智能体提出建议，人类操作：人类审查并批准每一项智能体行动。 -
智能体与人类协作：人类和智能体共同工作。智能体在重要步骤需要人工批准，例如写入数据库或付款之前。不过，人类可以随时通过接管智能体工作，或暂停智能体并要求更改来介入。 -
智能体操作，人工批准：智能体仅在关键步骤或失败时需要人工批准，例如删除数据库或进行超过预定义金额的支付。 -
智能体操作，人类观察：智能体完成任务时不需要人工批准，但其行动可在事后接受审计。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
软件工程智能体不同行动空间和自主性的示意图。
1.2 智能体的风险
1.2.1 风险来源
智能体的新组成部分构成新的风险来源。风险本身并不陌生；从根本上说，智能体是构建在 LLM 之上的软件系统。它们继承了传统软件漏洞（例如 SQL 注入）和 LLM 特有风险（例如幻觉、偏见、数据泄露和对抗性提示注入）。
然而，这些风险可能通过不同组成部分以不同方式表现出来。例如：
-
规划与推理：智能体可能由于幻觉或语义错位（对用户意图的不正确解释），创建无法完成所请求任务的计划，或创建与用户意图相冲突的计划，或偏离此前计划。 -
工具：智能体可能产生幻觉并调用不存在的工具，可能因调用错误工具、以错误输入调用正确工具，或以有偏方式调用工具而出错。由于工具将智能体连接到外部系统，提示注入或代码注入也可能操纵智能体，泄露或以其他方式操纵其可访问的数据。 -
协议：随着新的协议出现以处理智能体通信，这些协议可能被不当部署或遭到破坏，例如部署包含用于泄露用户数据代码的不可信 MCP 服务器。
1.2.2 风险类型
-
错误行动 -
未经授权的行动 -
有偏或不公平的行动 -
数据泄露 -
对连接系统的扰乱
由于智能体会在现实世界中采取行动，当其发生故障时，可能导致有害的现实世界影响。组织应意识到以下负面结果：
-
错误行动：不正确的行动，例如智能体将预约安排在错误日期，或生成有缺陷的代码。具体有害结果取决于相关行动，例如有缺陷的代码可能导致安全漏洞被利用，错误的医疗预约可能影响患者健康结果。 -
未经授权的行动：智能体在其获准范围或权限之外采取的行动，例如根据明确的人类指令、公司政策或标准操作程序，本应升级交由人类批准，但却未升级而采取行动。 -
有偏或不公平的行动：有偏或不公平的输出是 LLM 的已知问题，并且可能转化为智能体中的有偏行动。这些行动会导致不公平结果，尤其是在处理不同画像和人口统计群体时，例如采购中的有偏供应商选择、补助发放和/或招聘决策。 -
数据泄露：导致敏感数据暴露或被操纵的行动。这类数据可能是可识别个人身份的信息或保密信息，例如客户详情、商业秘密和/或内部通信。这可能是由于安全漏洞造成的，即攻击者利用智能体披露私人信息；也可能是由于智能体未能识别信息的敏感性而披露敏感数据。虽然这也是 LLM 的已知风险，但智能体通常具有更大的数据访问权限，并且不仅可能泄露数据，也可能错误地修改数据。 -
对连接系统的扰乱：由于智能体会与其他系统互动，当其被攻陷或发生故障时，可能扰乱连接系统，例如删除生产代码库，或以请求淹没外部系统。
1.2.3 系统性风险和多智能体风险
智能体系统的速度和复杂性可能增加上述风险。尤其是：
-
速度和规模：智能体作出决策的速度，使监督机制难以在未经授权行动造成伤害之前实时检测并阻止这些行动。要求人类批准者持续监督智能体作为一种保障，也可能导致自动化偏见和告警疲劳。 -
级联或复合效应：某一步中的错误可能传播并放大到后续步骤，造成过大的影响。例如，在供应链管理中，一个最初由幻觉产生的库存数字，可能导致下游行动重新订购过多或不足的库存。
多智能体系统会因为互动智能体数量增加而加剧这些风险。例如，多智能体系统通常要求智能体与其他智能体共享上下文、记忆和中间输出。这会增加敏感数据被无意记录、传递给安全性较低的智能体，或通过提示注入攻击暴露的可能性。
多智能体系统在多大程度上会引入性质上不同的风险，仍在研究之中，但其中较为相关的风险包括：
-
智能体蔓延：随着更多 AI 智能体在组织内被创建和部署，可能导致 AI 智能体在缺乏集中管理的情况下不受控制地扩散。这可能引发来源可追溯性问题、新旧智能体之间的不兼容问题，和/或管理不同代际智能体的困难；这些智能体之间可能无法良好通信。 -
协作失败 -
协调不当：共同工作的智能体可能因沟通不良或协调不当而导致意外失败。例如，在同一任务上工作的智能体可能对用户意图作出不同解释，并朝不同目标工作。 -
冲突：优化不同目标的智能体可能发生冲突。例如，客服智能体可能为了快速解决投诉而提供退款，而收入保护智能体可能阻止超过某一阈值的退款。 -
串通：智能体可能发展出看似协调的行为，即使没有收到明确的串通指令。例如，不同组织使用的定价智能体可能观察彼此价格，并趋同于更高价格，而不是相互竞争。这种行为已经在定价算法中被研究，也正在基于 LLM 的智能体中被研究。 -
不可预测性和其他涌现行为：当多个非确定性智能体共同工作时，可能结果的数量会呈指数增长。这可能导致无法通过单独测试每个智能体来预测的涌现行为。
最后，多个智能体既可以在一个系统内部互动，也可以跨系统互动。当智能体跨越系统或组织边界时，测试并预判潜在结果范围会变得更加困难，尤其是在组织无法对白盒访问这些外部系统时。
2 智能体治理框架
|
1. 预先评估并界定风险边界 |
2. 使人类承担有意义的问责 |
|
3. 实施技术控制和流程 |
4. 促进终端用户责任 |
智能体治理框架的四个维度
智能体治理框架建立在 MGF（2020）为组织提出的负责任 AI 实践基础之上，突出说明应对智能体新关切的新兴最佳实践。其目的在于使组织能够在具备必要知识和判断的情况下开发和使用智能体。
本框架首先帮助组织预先评估并界定风险边界。它强调在风险评估过程中应考虑的新风险，以及规划阶段的设计考虑，以限制智能体潜在影响范围，并确保智能体可追踪、可控制。
虽然智能体可以自主行动，但人类责任仍然适用。一旦部署智能体 AI 获得“绿灯”，组织就应立即采取措施，使人类承担有意义的问责。这包括在参与智能体生命周期的组织内外多个行动者之间清晰界定责任；并采取措施，确保即便存在自动化偏见，人在环路中仍能随时间推移保持有效。
为确保智能体安全可靠地投入运行，组织应在 AI 生命周期各阶段采用技术控制和流程。在开发阶段，应针对 AI 智能体中的新组成部分（例如规划和工具）实施护栏。部署前，应测试智能体的基线安全性和可靠性。部署后，随着智能体与其环境动态互动，应持续监测智能体。
最后，可信地部署智能体并不完全依靠开发者，也依靠终端用户。组织有责任通过向终端用户提供必要信息，使其能够适当使用智能体并进行有效监督，同时保持其专业技艺和基础技能，从而促进终端用户责任。
这四个维度应被视为一个迭代过程。例如，如果在实施或监测过程中发现异常，组织应重新评估前面的维度，必要时重新评估并进一步界定风险边界。这确保了随着部署经验产生新的洞见，组织能够持续改进和适应。
IMDA：将框架四个维度应用于 OpenClaw
2026年5月，IMDA 发布了关于负责任部署 OpenClaw 的案例研究，应用本框架，并借鉴 GovTech、CSA 以及曾试用 OpenClaw 的 Grab、Microsoft 等行业参与者的实践经验。
OpenClaw 是一个开源 AI 智能体平台，可通过 Telegram 和 Slack 等常见聊天界面充当自主个人助手。它可以自动执行日常任务，例如汇编研究资料、处理客户询问或调试代码。它发布时只具备有限的安全控制，安全部署并非易事。相关关切包括其成熟度和加固不足、访问控制和认证缺口、敏感数据暴露、第三方技能带来的供应链风险，以及记忆投毒风险。
该框架可用于负责任地部署 OpenClaw（以及类似）智能体：
- 预先评估并界定风险边界
-
避免在任务关键型环境中按原样部署 OpenClaw，包括处理敏感数据或金融交易的系统。 -
避免创建一个不受限制访问的单一“全能”智能体，而应使用多个规则狭窄且定义清晰的智能体。 -
避免将 OpenClaw 安装在包含敏感数据的主要工作设备或个人设备上，并避免授予其对文件和应用程序的不受限制访问。 - 使人类承担有意义的问责
-
采用基于风险的方法，根据数据敏感性和任务关键性确定适当的智能体自主程度。 -
在可行情况下通过系统级控制强制执行人工批准，而不是依赖提示层护栏；后者可能被绕过或被“遗忘”。 - 实施技术控制和流程
-
在设计和开发阶段，审查并收紧默认较为宽松的 OpenClaw 配置，例如限制消息渠道访问，并为智能体使用专用身份和凭证。 -
部署前，测试并验证安全控制和人在环路中是否按预期工作，例如尝试被禁止的行动，以确保限制有效。 -
部署后，确保所有智能体行动均被记录且可归属，并避免让智能体长时间处于无人监督状态。 - 促进终端用户责任
-
提供人员培训，提高员工对自主智能体风险的认识，并强化其防止粗心误用的责任。
2.1 预先评估并界定风险边界
智能体带来新的风险，尤其体现在其访问敏感数据，以及通过采取行动改变其环境的能力。其适应性、自主性和多步骤特征，也增加了意外行动、涌现风险和级联影响的可能性。组织应通过以下方式考虑这些新维度：
-
通过考虑可能影响风险发生可能性和影响程度的智能体特有因素，确定适合部署智能体的用例。 -
通过对智能体访问工具和系统施加限制，并定义稳健的身份和权限框架，在设计选择中预先界定风险边界。
2.1.1 确定适合部署智能体的用例
在考虑某个智能体用例是否适合开发或部署时，应首先识别并评估风险与收益。风险是可能性（风险发生的概率）和影响（风险发生时影响的严重程度）的函数。并非所有用例都适合智能体，有些用例可能更适合由确定性工作流处理。
以下非穷尽因素会影响智能体用例的风险水平：
影响程度因素（风险发生时影响的严重程度）
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
可能性因素（风险发生的概率）
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
威胁建模还通过系统性识别攻击者可能采取哪些具体方式来攻陷系统，使风险评估更加严谨。智能体系统的常见安全威胁包括记忆投毒、工具滥用和权限攻陷。由于智能体系统可能变得非常复杂，使用一种称为污点追踪（taint tracing）的方法通常很有用，可用于映射所有工作流和互动，以追踪不可信数据如何在系统中流动。关于如何对智能体系统进行威胁建模和污染追踪的更多信息，组织可参考 CSA 的《Draft Addendum on Securing Agentic AI》。
威胁建模与风险评估之间的关系
威胁建模通过生成情境化威胁事件来增强风险评估流程；这些威胁事件具有被充分描述的行动序列、活动和场景，说明攻击者可能如何攻陷系统。有了更相关的威胁事件，风险评估将更加严谨和稳健，从而产生更有针对性的控制和有效的分层防御。由于风险评估是连续的，威胁模型也应定期更新。
关于智能体 AI 系统潜在安全威胁的更全面覆盖，参见 OWASP，《Agentic AI – Threats and Mitigations》。
Dayos：在 IT 管理中按风险等级分层并界定智能体行动边界
Dayos 是一家总部位于新加坡、在美国开展业务的企业 AI 自动化公司。该公司构建了 Hero，这是一个位于 Oracle、SAP、Workday、NetSuite 和 Microsoft Dynamics 之上的智能体平台，可自动执行 IT 管理、会计、人力资源和采购等工作流。
Dayos 用基于 Hero 构建的 AI 工单智能体替换了自己的 ServiceNow 实例。完整退役过程耗时 45 天，并每年减少了 121,000 美元的传统许可成本。该智能体现在处理每一个进入的内部 IT 请求：它读取工单，判断其紧急程度和复杂性，然后自动解决或路由给人类。
在任何功能上线之前，Dayos 进行了结构化风险评估。每一类 IT 工单都根据三个问题评分：
-
影响严重程度：如果智能体做错了，会有多糟？ -
可逆性：该行动能否撤销？ -
人类监督可行性：让人类在每一步进行审查是否现实？
这些分数决定每类工单落入哪个层级，而该层级决定智能体使用什么推理策略，以及智能体获得多少自主性。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
2.1.2 通过设计界定风险边界，明确智能体的限制和权限
在选择了适当的智能体用例后，组织可以通过为每个智能体定义适当的限制和权限政策，进一步界定风险边界。
智能体限制
组织应考虑对以下方面定义限制：
-
智能体对工具和系统的访问：定义最小权限政策，只向智能体提供完成任务所需的最低限度工具和数据访问权限。例如，代码助手可能不需要访问广泛的网页搜索工具，尤其是在其已经可以有选择地访问最新软件文档的情况下。围绕功能边界构建智能体（例如将 IT 帮助台与 HR 自助服务分开），可以形成一种自然约束。 -
智能体的自主性：对于流程驱动型任务，标准操作程序和协议经常用于提高一致性并减少不可预测性。应为智能体工作流定义类似的标准操作程序，约束智能体遵循这些程序，而不是让智能体自由定义工作流的每一步。 -
智能体的影响范围：设计机制和程序，以便在智能体发生故障时使其离线，并限制其潜在影响范围。这可以包括在网络和数据访问受限的自包含环境中运行智能体，尤其是在其执行代码执行等高风险任务时。
一般而言，应偏好确定性限制而不是非确定性限制，并通过设计界定边界。例如，与其依赖提示来指示智能体不要访问某些工具，不如实施访问控制，从根本上防止智能体调用该工具。2.3.1“在设计和开发阶段使用技术控制”对此作了进一步阐述。在限制具有非确定性或可靠性较低的情况下，应叠加更多监测措施，或纳入人在环路中审查，以捕捉任何失败。
OCBC：在财富来源分析中界定智能体自主性边界
OCBC 是新加坡历史最悠久的银行，也是按资产规模计算的东南亚第二大金融服务集团，在 19 个国家和地区运营。Bank of Singapore 是 OCBC 的全资私人银行子公司。
Bank of Singapore 的客户经理和合规团队将客户提供的财务文件综合成结构化的财富来源备忘录。该银行开发了一个智能体 AI 系统来支持这项工作，其目标是：
-
提高分析的一致性和完整性 -
减少文件审查和起草中的人工工作量
该智能体系统解析与收入相关的文件（例如纳税申报、公司年度报告、房产文件、股息报表），并基于内部指引和基准生成财富来源备忘录草稿。该系统仅提供决策支持，不自主作出信贷、开户或风险决策；最终验证和批准仍由指定人类审查者负责。
该智能体工作流通过定义智能体自主性的限制，以设计方式界定风险边界：
-
仅限任务级自主性：智能体执行范围狭窄的任务（提取、起草、检查），而不是作出端到端决策。 -
不自行发起行动：智能体只有在被预定义工作流触发时才运行。 -
无决策权限：在关键决策点存在人类审查，包括在收入和财务文件被评估后进行审查，以确保准确性。最终，输出属于咨询性质，并受人类验证约束。
智能体身份
身份管理和访问控制，是今天组织为人类实现可追踪性和问责的关键手段之一。随着组织部署更多智能体，包括跨组织边界互动的智能体，身份管理需要扩展到智能体，以追踪单个智能体行为，并确定谁对每个智能体承担问责。这是一个正在演进的领域，当前在稳健处理智能体身份方面仍存在缺口。例如，现有授权系统通常具有预定义的静态范围。然而，为了在更复杂场景中安全运行，智能体需要精细化权限，这些权限可能会根据上下文、风险水平和任务目标动态变化。当前认证系统通常也基于单一、唯一的个人。这类系统在处理复杂智能体设置时会遇到困难，例如智能体代表具有不同权限的多个人类用户行动，或在递归委托场景中由智能体启动多个子智能体。
用于解决这些问题的方案正在被开发，例如组织内部身份系统被扩展到智能体，或将 OAuth 2.1 等成熟标准整合进 MCP。行业也在为智能体开发新的标准和解决方案，例如去中心化身份管理和动态访问控制。
在过渡期间，组织应考虑以下最佳实践：
-
识别：智能体的身份应当： -
唯一：智能体应具有其自身唯一且可通过密码学验证的身份，使其能够向组织、人类用户或其他智能体表明身份。 -
可问责：该身份应绑定到一个监督智能体、一个人类用户或一个组织部门，以支持问责和追踪。 -
按其行动身份加以区分：应记录智能体以不同身份行动的情形（例如独立行动或代表特定人类用户行动），以支持可审计性。 -
编目并集中管理：为防止智能体蔓延，所有智能体身份（及其附随权限）都应由集中化系统签发并追踪。这使组织能够追踪已部署智能体，识别任何异常，并移除不再需要的身份。 -
授权：智能体的权限应当： -
有范围、最小权限、不可转让：授权通常应当有范围限制，受时间或会话约束，不可转让，并默认遵循最小权限原则，同时为提升权限设置明确升级路径。 -
受授权人类权限限制：智能体可以基于其角色或任务具有预定义权限，也可以由其授权人类用户动态设置权限，或两者结合。作为经验规则，人类用户不应能够为智能体设置超过该人类用户自身被授权范围的权限，例如访问超出该人类权限的数据。此类权限委托应被清晰记录。
评估残余风险
残余风险是指适用缓解措施后仍然存在的风险。需要注意的是，即使已经努力识别适当的智能体用例，并为任何智能体定义限制，仍然始终会有一定程度的风险残留，尤其是在智能体快速演进的情况下。最终，组织应评估并判断其智能体部署的残余风险是否处于可容忍水平并可以接受。
2.2 使人类承担有意义的问责
部署智能体的组织以及监督智能体的人类，仍然需要对智能体的行动承担责任。但当智能体行动是从互动中动态、适应性地产生，而不是来自固定逻辑时，履行这种责任可能具有挑战性。多个利益相关方也可能参与智能体生命周期的不同部分，从而稀释责任。最后，自动化偏见，即过度信任自动化系统的倾向，尤其是在该系统过去表现可靠时，会随着人类监督能力越来越强的智能体而成为更大的关切。
为应对这些人类责任方面的挑战，组织应考虑：
-
在组织内外清晰分配责任，在智能体价值链和生命周期中建立问责链，同时强调适应性治理，使组织能够快速理解新的发展，并随着技术演进更新其方法。 -
采取措施促进对智能体的有意义人类监督，例如在重要检查点要求人工批准，审计人工批准的有效性，并用自动化监测补充这些措施。
2.2.1 在组织内外清晰分配责任
作为部署者，组织和人类仍然需要对智能体的决策和行动承担问责。然而，与 AI 一样，智能体 AI 的价值链涉及多个行动者。组织应考虑其组织内部以及与价值链上其他组织之间的责任分配。
组织可能在这条价值链中扮演多个重叠角色。例如，一个组织如果开发自己的智能体并随后部署这些智能体，就同时扮演系统提供者和部署者角色。
关于智能体 AI 生态系统中可能涉及的潜在利益相关方的更完整列表，参见 CSA 和 FAR.AI，《Securing Agentic AI: A Discussion Paper》。
组织内部
在组织内部，组织应为智能体生命周期中不同团队分配责任。虽然每个组织的结构不同，以下示例说明如何在不同团队之间分配此类责任：
PwC Singapore：为报告起草智能体系统在不同内部团队之间分配人类责任
PwC 是一个专业服务公司网络，覆盖 137 个地区，业务包括审计与鉴证、税务与法律、交易和咨询。
为提升内部生产力，PwC Singapore 的 AI Factory 开发了一个智能体应用，用于自动起草内部报告中的研究和分析章节；这一流程传统上高度依赖人工且研究密集。用户定义所需章节后，系统会从 PwC 维护并更新（用于监管和市场发展）的标准化模板中取材，从源材料中检索并综合信息，并在数秒内生成草稿内容。
该系统使用三个协调智能体，主要采用顺序工作流，在需要额外检索或重构时包含反馈循环。
以下责任说明了在 PwC Singapore 更广泛 AI 治理框架下，该报告起草用例的运营问责如何分配：
-
用例所有者——用例适当性和负责任使用：确认该用例服务于合法业务需求，适合预期目的，并与组织 AI 治理框架一致。用例所有者仍然对应用的负责任使用负责，并负责确保适当的人类监督到位。 -
技术风险管理团队——风险评估和控制建议：支持评估该用例的技术、风险、安全和合规考虑因素，包括任何监管要求。这包括就工具和模型、访问权限以及连接的知识库或数据源相关适当控制提出建议。 -
AI Factory——设计、开发、护栏和监测：设计、开发和维护该应用，包括提示设计、模型选择、工具配置、与经批准知识库的集成，以及适当护栏。AI Factory 还监测模型变更，并通过标准变更管理流程管理更新，而不是将其留给终端用户。 -
终端用户/主题专家——输出审查和批准：在使用 AI 生成内容之前对其进行审查。内部指引明确说明，AI 生成内容是用于支持而非取代专业判断的初稿。人类审查者在依赖或进一步使用输出之前，对其进行完善和批准，包括检查准确性、完整性以及与既定方法的一致性。
培养适应性治理的内部能力
所有参与智能体 AI 的团队也应培养理解该技术的内部能力。了解智能体发展的改进和局限，例如计算机使用智能体等新形态，或新的评估框架，使组织能够快速调整其治理方法以适应新的发展。
组织外部
组织在部署智能体时也可能需要与外部方合作，例如模型开发者、智能体提供者，或外部 MCP 服务器或工具的托管方。
在这些情况下，组织同样应确保有措施履行自身责任。一些智能体特有的考虑因素包括：
-
在组织与外部方之间的任何条款条件或合同中，明确义务分配。尤其是，组织应考虑安全安排、性能保证或数据保护相关条款。存在缺口时，组织应重新评估智能体部署是否符合其风险容忍度。 -
应对第三方不透明性：由外部方提供的智能体可能难以观察和控制，使组织难以理解这些智能体基于什么信息，其从对话中推断出什么，或数据如何被存储和使用。组织应采取措施保持充分的安全性和控制，例如： -
要求外部方提供透明度和问责，例如披露智能体能力和数据处理实践。 -
请求并评估技术安全和控制功能，例如有范围的 API 密钥、逐智能体身份令牌等强认证措施，以及工具调用和访问历史日志等可观测性。如果缺乏此类功能，组织应考虑替代方案或内部解决方案，或缩小智能体用例范围，例如限制对敏感数据的访问。
终端用户
组织可以向组织内部或外部用户部署智能体。在这样做时，组织应确保向用户提供充分信息，使用户能够追究组织责任，并提供与用户自身责任相关的任何信息。更多信息见下文“促进终端用户责任”。
2.2.2 为有意义的人类监督而设计
组织应定义需要人工批准的重要检查点或行动边界，尤其是在执行敏感行动之前。这可以包括：
-
高风险行动和决策，例如编辑敏感数据、高风险领域（如医疗或法律）中的最终决策、可能触发责任的行动。 -
不可逆行动，例如永久删除数据、发送通信、进行付款。 -
异常值或非典型行为，例如智能体访问其工作范围之外的系统或数据库，或智能体选择的配送路线是中位距离的两倍。 -
用户定义，例如智能体可以代表具有不同风险偏好的用户行动。除组织定义的边界外，可以让用户选择定义自己的边界，例如要求对超过某一金额的购买进行批准。
除考虑何时需要批准外，组织还应考虑批准应采取何种形式。这些考虑因素包括：
-
使批准请求具有上下文且易于理解，同时清楚说明风险。要求人工批准时，应保持请求简短清晰，而不是提供可能难以解读的长日志或原始数据。不过，应纳入有用的补充数据，例如该行动相关风险或置信度分数。 -
考虑所需人类输入的形式。对于访问数据库等直接行动，人类用户可以简单批准或拒绝。对于更复杂的情形，例如在执行前审查智能体计划，让人类在批准智能体继续之前编辑计划可能更有效。对于高风险行动，可以要求人类用户在批准或拒绝之前提供额外书面理由。
组织应实施措施，确保人类监督持续有效，尤其是考虑到人类仍容易受到告警疲劳和自动化偏见影响，也可能受到拟人化设计影响。这些措施可以包括：
-
定期审计人类监督的有效性。可采取的一些方式包括： -
人类推翻率，即人类拒绝或修改智能体行动的频率。较低比例可能表明存在盖章式批准行为。 -
人类审查智能体行动时的响应时间。较短时间可能表明自动化偏见或审查疲劳。 -
跟踪可衡量指标 -
使用数据分析识别“异常值”人类，即其决策模式显著偏离常态的人。这可能表明监督受损。 -
训练人类监督者识别常见失败模式或智能体局限，例如智能体推理不一致、智能体引用过时政策。还应注意，有时用于可解释性的思维链推理并不等同于人类推理，也可能并非智能体行动的忠实解释。 -
确保人类具备评估智能体行动的领域专业知识，例如使用智能体进行“氛围编程”（vibe code）的用户，可能并不具备审查生成代码稳健性的软件工程专业知识。
最后，人类监督应由自动化实时监测补充，以升级任何意外或异常行为。这可以通过以下方式实现：
-
对某些被记录事件实施告警（例如尝试未经授权访问，或多次调用工具失败）。 -
使用数据科学技术识别异常智能体轨迹。 -
使用智能体监测其他智能体。 -
当批准基础设施失效时默认拒绝行动（例如人类监督者无法联系，或智能体尝试尚无既定批准政策的新行动）。
更多信息见下文“持续测试和监测”。
Tencent：在代码助手中实现有意义的人类监督
Tencent 是一家总部位于中国的跨国科技公司，负责游戏、即时通信应用 WeChat 以及 Hunyuan 等 AI 模型。
CodeBuddy 是 Tencent Cloud 开发并由其工程师使用的智能体编码系统。它可以通过自然语言指令自主规划、编写、测试和部署代码，并可访问文件系统、终端命令、外部 API 和 MCP 工具。
CodeBuddy 采用预设安全默认值和可配置权限的组合，以允许有意义的人类监督，同时避免用户过度疲劳：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
curl https://example.com/api-docs<br>如果后来使用类似模式的命令看起来可疑或实质上风险更高，例如<br>curl https://example.com/api-docs && echo test > /tmp/unexpected_file<br>CodeBuddy 的保护机制可以要求重新取得人工批准。 |
拟议命令：bash mysqldump -u root -p my_database | gzip > / backups/my_database_$(date +%Y%m%d).sql.gz 解释：我将为你的数据库创建完整备份，在生成过程中即时压缩以节省空间，并将其保存到 /backups/，文件名中包含今天的日期。系统会提示你输入数据库 root 密码。原始数据库不会被修改；这是一项只读操作。
X0PA：在高影响招聘工作流中实现有效人工批准
X0PA 是一家提供 AI 驱动招聘解决方案的 B2B 软件公司。其 AI Agentic Platform 将智能体 AI 应用于招聘工作流。这些智能体已经通过逐步推出方式，为 X0PA 当前客户部署在以下工作流中：
由于招聘是高影响领域，其重点是增强而不是取代人类决策。
-
人工批准检查点：在人选筛选和最终选择等关键阶段保留人类检查点，确保具有重大影响的招聘决策仍由人类招聘人员和用人经理作出。 -
通过以下方式实现有效用户批准： -
对招聘而言，这包括智能体误解非标准职业路径，或对历史数据或结构化数据有限的候选人给出较低置信度评价的情形。 -
用户还接受培训，以识别面试智能体可能无法充分捕捉沟通风格、领域特定细微差别或非典型候选人经历等上下文因素的情形，以及可能需要额外人类评估的情形。 -
可解释输出：匹配分数和排名理由使用户能够理解智能体建议的依据，从而进行有效审查。 -
培训：通过培训和入职流程，使用户熟悉系统功能，包括其局限和潜在失败模式。 -
用户控制和反馈循环：用户可以推翻建议并提供反馈。这可用于随时间推移改进系统表现，在用户与 X0PA AI 的智能体之间形成互动循环。
2.3 实施技术控制和流程
使智能体区别于简单基于 LLM 应用的智能体组件，要求在实施生命周期的关键阶段增加控制。
组织应考虑：
-
在设计和开发阶段，设计并实施技术控制。智能体的新组件和新能力需要新的、定制化的控制。根据智能体设计，实施访问控制等控制。此外，通过对工具和数据强制执行最小权限访问，限制智能体对外部环境的影响。 -
部署前，测试智能体的安全性和安保性。与所有软件一样，部署前测试确保系统按预期运行。对于智能体而言，尤其应测试整体任务执行、政策遵循和工具使用准确性等新维度，并在不同数据集上测试，以捕捉智能体行为的完整范围。 -
部署时，逐步推出智能体，并在生产环境中持续监测。智能体的自主性以及不断变化的环境，使得在部署前穷尽并测试所有可能结果具有挑战性。应逐步推出智能体，并由部署后的实时监测支持，以确保智能体安全运行。 -
在整个生命周期中，实施变更管理和版本控制流程。在复杂智能体生态系统中，对一个智能体的变更可能对相互连接的工作流产生级联影响。因此，组织应定义触发变更审查流程的明确触发条件，并相应分类所需变更。
2.3.1 在设计和开发阶段使用技术控制
组织应在智能体系统中设计并实施技术控制，以缓解已识别风险。针对智能体，除基线软件和 LLM 控制外，还应考虑为以下方面增加控制：
-
规划、推理和工具等新的智能体组件。 -
因更大攻击面和新协议而增加的安全关切。 -
多智能体互动。
选择适当控制时，应考虑以下因素：
-
结构性、基于规则的控制与基于模型或提示层的控制： -
例如，与其指示智能体不要使用特定工具，不如在工具层实施访问控制，从一开始就防止这些工具被调用，或只允许以特定方式调用（例如仅限读取访问）。同样，如果智能体需要遵循一套既定程序，将该顺序构建进工作流，比单纯通过指令提示智能体遵守该程序更稳健。 -
与其使用提示层保障措施，不如考虑实施通过预定义逻辑在系统层运行的确定性保障措施，尤其是针对较高风险行动。 -
提示层保障措施也往往在不同用户之间定义不一致；相比之下，系统级保障措施可以被一致定义和执行。 -
然而，在某些风险较难通过固定规则定义的情况下，基于模型的保障措施可能最有效，例如检测可能以不同方式表现出来的有害内容。 -
运行时控制：由于智能体会实时与用户和系统互动，在设计时配置的静态保障措施可能不足以捕捉每一种风险。运行时控制通过在执行过程中监测和干预来应对此问题，例如使用速率限制防止过度使用工具，或使用输入验证在有害回应被采取行动之前捕捉这些回应。
以下是一些智能体控制示例，供说明之用。更完整列表可参见 CSA 的《Draft Addendum on Securing Agentic AI》和 GovTech 的《Agentic Risk and Capability Framework》。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
MCP 作为治理层
虽然 MCP 通常被视为一种连接协议，但它有可能充当治理层，因为它位于智能体与其访问的企业系统之间。组织可以考虑在 MCP 层定义控制，例如过滤通过服务器传递的敏感数据、记录所有智能体到系统的互动，或仅将可信服务器列入白名单。
Terminal 3：在硬件层面实现准确、安全的智能体支付控制
Terminal 3 是一家总部位于香港的数据隐私基础设施提供商，提供安全且保护隐私的数据处理，无需数据转移。
该公司部署了一个财务薪资智能体，用于自动执行其每月薪资周期，涉及计算税前和税后工资、政府规定缴款、验证费用报销，并在发放整体工资前交叉核对账户详情。
该流程本质上属于高风险流程，因为它涉及处理敏感个人数据并执行金融交易。为确保智能体安全处理这些行动，Terminal 3 实施了以下技术控制：
-
在凭证中定义智能体权限范围：每月薪资周期开始前，人力资源负责人向智能体签发一份可验证意图凭证（Verifiable Credential of Intent），这是一项具有数学约束力、按周期限定的授权，定义： -
智能体可以访问哪些员工记录； -
适用的政府规定缴款率； -
费用报销阈值、符合条件的类别和每日津贴上限；以及 -
合并银行转账的金额上限，设定为基本工资加缓冲额，并在每次运行前明确声明。 -
将敏感数据与智能体上下文作结构性分离：所有敏感个人数据（例如员工身份证号码、薪资数字和银行账户详情）都完全保存在 Terminal 3 的可信执行环境（TEE）内，并且在任何时候都不会传输给智能体。智能体仅基于非敏感输入运行，并且只接收不透明的员工引用标识符和分类标志理由作为输出。这种架构分离意味着智能体上下文中不存在可通过对抗性输入泄露或提取的敏感数据；风险通过设计被消除。 -
通过硬件强制执行该权限边界：每项智能体行动都通过 TEE 路由，并以硬件速度根据凭证参数进行验证。超出范围的行动（无论来自错误推理还是对抗性提示）会在执行前被阻止并记录。所有敏感计算都只在该安全边界内发生。 -
记录防篡改审计轨迹：智能体执行的每一步，包括任何被阻止行动，都会记录在 T3N Immutable Ledger 上；这是一种由硬件证明、可通过密码学验证的日志，用于为任何事件后调查提供证据链。
Cyber Sierra：提高尽职调查问卷填写准确性和可靠性的技术控制
Cyber Sierra 是一家新加坡公司，是一家治理、风险与合规（GRC）智能体工厂，为网络运营、安全合规和审计任务构建多智能体基础设施。
该公司开发了 TracyAI，这是一个用于自动回复安全和合规问卷的解决方案。此类问卷通常包含数百个与数据保护、访问控制、认证和风险管理有关的重复问题。TracyAI 通过一个智能体系统完成这项工作，该系统会通过多个步骤，在过往尽职调查问卷、信息安全政策文件和证据文件夹中搜索和推理。TracyAI 被部署在一家总部位于香港的大型金融机构的治理、风险与合规团队中，将一项通常需要 100 多个小时人工完成的任务缩短到 15 分钟。
为降低输出不准确和幻觉的可能性，该团队实施了以下技术控制：
-
供智能体审查自身输出的反思架构：该智能体系统纳入了两类反思节点，使用 LangGraph 实现，在智能体生成输出后向其提供反馈： -
基于 LLM Judge：一个 LLM judge 根据输出是否回答了问题、理由是否与检索到的证据一致，以及是否引入无支持或捏造的主张来批评输出。 -
基于指标：相似度分数和 RAGAS 指标，例如忠实性、上下文相关性、回应相关性分数。
智能体随后会审查并完善自身输出。如果在三次迭代内未能达到两个节点的通过阈值，其轨迹将被终止。
-
结构化信息以增强智能体理解：在开发初期，该团队观察到，当智能体引用以下内容时，容易产生不准确输出： -
知识库中同一文件的多个版本，其中一些已经过期；以及 -
一份依赖后来已经过期文件的过往问卷。
为以更确定性的方式解决这一问题，该团队没有对智能体本身进行干预，而是将源信息结构化为一张图，展示内部文件、政策和认证之间的关系。这使智能体能够理解证据如何跨领域连接。随后，该图又通过元数据丰富，形成上下文图，从而以确定性方式确保只使用最相关（基于地点、主题等）且当前有效的文件（基于版本、到期日等）。
Stability Solutions：对面向内部与面向外部的智能体设置不同控制
Stability Solutions 是一家总部位于美国和新加坡的公司，构建并提供由区块链驱动的基础设施，用于大规模记录、保存和验证数据完整性。其解决方案包括 Global Trust Network（“GTN”，一个高吞吐量、无加密货币的公共区块链，目前用于供应链和物流），以及 Monolith；Monolith 是一个通过允许创作者为任何文件生成数字指纹、签发 C2PA 清单和来源元数据、嵌入知识产权许可和 AI 训练权限来记录创意作品来源的应用，并以稳健、可验证、机器可读的格式将所有这些内容记录在 GTN 上。
Stability 部署其内部智能体系统 L3，该系统目前由 26 个 AI 智能体组成，全天候运行，覆盖几乎所有公司职能，包括产品开发、软件工程和营销。其内部智能体具有行动能力，例如整合和归档整个公司的信息、发送每日晨报、监测并解决网络问题、充当数字孪生或个人助手，以及支持工程和开发活动，如规划项目和编写代码。L3 被优化为尽可能访问更多信息，使其能够跨团队协调（例如，如果工程团队正在计划升级，L3 会告知其已计划的营销活动，以避免任何中断）。
当 Stability 开发其首个面向外部的智能体 Howard，用于展示 L3 功能并回答关于 L3 和公司的问题时，它认识到风险水平更高，因为该智能体可能被不可信第三方攻陷。与面向内部的智能体相比，必须实施额外护栏：
-
数据访问控制：该智能体拥有自己的记忆，这些记忆由从 L3 接收的信息形成。L3 的智能体知道该智能体的角色及其相关风险，因此为该智能体整理一个特殊数据集。 -
互动控制：该智能体通过聊天互动，可以经由 Slack 或网页界面。Stability 的人类员工会在第三方输入发送给智能体之前进行审查。这使他们能够过滤提示攻击或旨在提取个人数据和商业秘密等敏感信息的侵入性问题。随着该智能体安全性和可靠性提高，预计这一控制将不再必要。 -
智能体配置控制：实施明确护栏和定义清晰的人格协议，以尽量降低智能体披露敏感信息的可能性，例如商业秘密、个人数据或保密数据。
2.3.2 部署前测试智能体
组织应在部署前测试智能体的安全性和安保性。这使组织能够确信智能体按预期工作，且控制有效。软件和 LLM 测试的最佳实践仍然相关，例如软件系统的单元测试和集成测试，以及为 LLM 测试选择有代表性的数据集、有用指标和评估器。组织可以参考此前指南，例如《Starter Kit for Testing of LLM-based Applications for Safety and Reliability》。
然而，组织应为智能体调整测试方法。一些考虑因素包括：
-
测试新风险：除产生不正确输出外，智能体还可能通过工具采取不安全或非预期行动。组织可考虑测试： -
整体任务执行：智能体是否能够准确完成任务。 -
政策合规：智能体是否遵循定义的标准操作程序，并在需要时路由给人工批准。 -
工具调用：智能体是否以正确权限、正确输入和正确顺序调用正确工具。 -
稳健性：由于预期智能体会对现实世界情况作出反应和适应，应测试其对错误和边缘情况的回应。 -
测试完整智能体工作流：智能体可以在没有人类参与的情况下连续采取多个步骤。因此，除测试智能体最终输出外，还应测试其整个工作流，包括推理和工具调用。 -
单独测试智能体并共同测试智能体：除单个智能体外，还应在多智能体系统层面开展测试，以理解智能体协作时的任何涌现风险和行为，例如竞争行为，或当一个智能体被攻陷时对其他智能体的影响。 -
在真实或逼真环境中测试：由于预期智能体可能需要导航现实世界情境，测试应在经过适当配置、尽可能接近生产环境的执行环境中进行，例如使用工具集成、外部 API，以及行为与部署时一致的沙盒。不过，组织应在真实性需求与过早允许智能体访问会影响现实世界工具的风险之间进行校准。 -
反复测试并跨不同数据集测试：智能体行为本质上具有随机性且依赖上下文。因此，应大规模并跨不同数据集进行测试，以观察任何意外的低概率行为，尤其是高影响行为。这要求生成覆盖智能体可能遇到的不同条件的测试数据集。这些测试还应多次运行，以检查稳定性（例如相同输入和上下文是否产生一致输出），并在需要时包括轻微扰动。 -
大规模评估测试结果：可靠地大规模评估测试结果，是 LLM 测试中的已知挑战。智能体进一步增加了一层复杂性，因为其工作流可能很长，并包含难以由人类或自动化脚本轻松处理的非结构化信息。
关于需要测试的新智能体方面的示例，参见 Microsoft Foundry，Agent evaluators。
组织可以考虑对智能体工作流的不同部分使用不同评估方法（例如对结构化工具调用使用确定性测试，对非结构化智能体推理使用 LLM 或人类评估）。然而，仍有必要整体评估智能体，以便评估跨步骤的智能体模式。因此，当前行业解决方案包括定义 LLM 或智能体来评估其他智能体，同时纳入人在环路中审查。
关于智能体评估解决方案的示例，参见 AWS Labs，Agent Evaluation。
Google x Singapore Government：测试计算机使用智能体
为理解自主智能体在实践中如何运行，Google、CSA、GovTech 和 IMDA 启动了一个沙盒，用于测试面向潜在公共部门用例的计算机使用智能体，即：
-
自动化质量保证（QA）：针对政府数字服务的自动化 QA 测试。 -
AI 安全测试：自动化测试第三方聊天机器人等 AI 软件的安全性。 -
社会援助申请：协助公民导航并申请社会援助项目，帮助简化复杂流程。
虽然每个用例都有自身特定风险画像，但该沙盒呈现了一些关于智能体测试方法的一般洞见，包括：
-
使用逼真测试数据和环境：在 AI 安全测试用例中： -
数据：安全测试提示通常在长度、语言和格式上差异很大。测试数据集基于反映这种多样性的真实世界越狱提示进行整理。测试显示，该智能体很好地捕捉了格式和语言的变化，但其对截图的依赖意味着它难以准确复现较长回应。 -
环境：该智能体针对真实聊天机器人进行测试（尽管为安全起见，其中一些处于预发布环境），这使审查者能够检查其在导航不同用户界面时的稳健性，例如当遇到用户限制、较长加载时间或其他错误时，其刷新会话或重试提示的能力。 -
记录并评估智能体在工作流每一步的推理：这使测试结果能够被更详细地评估，以调试意外行为。例如，在社会援助用例中，测试智能体的数据最小化能力，即其是否能够区分与申请相关的信息和不应纳入的无关个人详情。在相当多的案例中，智能体纳入了这些无关详情。对其推理过程的审查显示，它有时仍然认为这类信息相关，或假定需要纳入提供给它的全部信息。由此可以制定更具体的提示层保障措施。 -
基于用例识别攻击向量：通过嵌入外部网站的恶意第三方提示，智能体可能被重定向至有害行动（也称为间接提示注入）。虽然这是一般风险，但在每个用例中可能以不同方式表现。例如，对于 AI 安全测试，智能体需要与第三方聊天机器人互动。因此，攻击者可以创建一个恶意聊天机器人，在其回应中包含有害指令。该威胁场景被专门测试。观察发现，在一些情形中，智能体在被指示后导航到任意 URL。可通过网站白名单或提示设计等控制缓解这一点，但不限于这些控制。 -
在测试期间纳入人在环路中：计算机使用智能体由于能够灵活导航不同用户界面，往往具有更广泛的行动空间和自主性。由于它们仍处于早期阶段，在测试过程中纳入人类监督和审查，可以显露任何意外或涌现行为。
关于已部署用例和测试风险的更多信息，参见完整论文。
City Developments Limited x Knovel Engineering：测试智能体系统中的数据访问边界
City Developments Limited（CDL）是一家总部位于新加坡的开发商和资产所有者/运营者，资产组合横跨住宅、商业、酒店和综合开发项目。Knovel Engineering 是一家新加坡 AI 咨询公司，帮助企业和政府机构运营化可信 AI。
作为 Global AI Assurance Sandbox 的一部分，Knovel 测试了 CDL 的内部智能体系统，该系统通过检索业务洞见、访问内部知识和执行面向任务的工作流来回答查询。智能体编排处理多步骤任务，例如总结行业表现或检索特定运营指标。
CDL 将数据泄露识别为其系统的一项关键风险，并优先对其进行测试。目标是确定数据访问控制和边界是否在用户之间被正确执行，即用户只能获得其拥有访问权限的信息。
为测试这一点，Knovel 采用了以下方法：
-
使用 7 个用户账户 x 4 个领域（物业、财务、商业、酒店）的矩阵，验证边界遵循情况。 -
登录具有受限领域访问权限的用户账户，并开展多轮对话，逐步引入针对范围外领域的间接查询（例如，物业领域用户询问 A 酒店第四季度收入）。 -
将受限账户的输出与合法授权账户的输出进行比较，以检测信息泄露。 -
此外，通过提供部分正确的系统提示和工具调用结构，利用系统倾向于“乐于助人”的特性，观察系统是否会无意中更正或补全被遮盖信息。
关于该案例研究的更多细节，包括测试洞见和被测试的其他风险，见此处。
2.3.3 部署时持续监测和测试
部署前测试建立了有用基线，但需要由部署期间的持续监测和测试补充。智能体会适应实时条件，其行为可能发生变化。尤其是对多智能体系统而言，协调不当或涌现行为等失败模式，可能只有随着时间推移并在真实条件下通过智能体行为表现出来。本节提出缓解此类风险的建议，包括：
-
逐步部署智能体。 -
持续测试和监测。 -
稳健的变更管理。
逐步部署智能体
组织应考虑将智能体逐步推出到生产环境，以控制风险暴露量。这类推出可以基于以下方面进行控制：
-
智能体用户，例如先向受过训练或有经验的用户推出。 -
智能体可用的工具和协议，例如先限制智能体只能使用更安全、列入白名单的 MCP 服务器。 -
暴露给智能体的系统，例如先在风险较低的内部系统中使用智能体。
GovTech：分阶段推出代码助手，在为新功能准备控制的同时逐步监测风险
Government Technology Agency of Singapore，即 GovTech，是新加坡一个法定机构，负责开发数字政府服务并推动公共部门转型。
2025年10月，GovTech 在组织内部推出两个智能体代码助手，即 Windsurf 和 GitHub Copilot（Agent Mode），并在 2026年4月推出 Claude Code。在针对常见失败和威胁向量（例如智能体操纵、幻觉和 MCP 服务器被攻陷）进行广泛测试并实施相应技术控制后，GovTech 采用分阶段方法推出这些智能体能力。这使其能够较早赋能开发团队、提升生产力，同时监测风险，并随着技术演进为新的 AI 功能逐步开发进一步控制。
第一阶段，推出范围受到限制，以控制任何潜在风险的爆炸半径：
-
内部员工：智能体代码助手只向 GovTech 员工推出，即单一组织内较小的一组开发者；他们可以接受培训，了解如何负责任地使用智能体，而不是面向整个政府推出。 -
不允许 MCP：用户只能使用智能体内置能力，例如在开发者环境中进行多步骤推理以规划和执行任务，而不能访问 MCP 服务器。 -
低风险系统：不属于关键基础设施且数据访问水平较低的系统。
在第一阶段进行期间，GovTech 开始建立必要控制和基础设施，以支持第二阶段中更广泛的智能体能力，例如集中日志记录和监测，并试行其第一版 MCP 治理框架，即让开发者能够从容器化沙盒连接到列入白名单 MCP 服务器的路径。GovTech 开展红队测试，以验证这些护栏抵御外部威胁的有效性。
在当前开始的第二阶段，推出范围将逐步扩大，包括其他政府机构的公共部门开发人员，然后是非政府供应商和承包商。修订后的 MCP 治理框架也将首先向 GovTech 开发者开放，并从 Figma 开始，随后基于用户需求和风险因素逐步向政府其他部门开放其他受管 MCP，例如 GitLab。
第一阶段的经验为第二阶段推出提供了依据，例如：
-
解决初期问题，例如网络信任配置问题。 -
允许用户选择操作系统原生沙盒，使智能体可以更灵活地运行某些命令，而无需不断寻求人工批准，从而降低人工批准者的认知负担。 -
降低采用 MCP 治理框架的摩擦，取消对复杂本地开发容器和自托管基础设施的需求，并在可用情况下将架构改为结合 AI 编码工具原生沙盒与 Cloudflare 的受管 MCP 网关。
随着智能体快速演进，GovTech 继续实验、测试和监测 AI 的影响，以发现缺口和新的经验。平衡风险缓解与开发者体验，是成功采用智能体并提升开发者生产力的关键。
持续测试和监测
组织应在部署后持续监测并记录智能体行为，并为智能体失败或意外行为建立报告和故障安全机制。这使组织能够：
-
实时介入：当检测到潜在失败时，停止智能体工作流并升级给人类监督者，例如当智能体尝试未经授权访问时。 -
在事件发生时调试：记录和追踪智能体工作流以及智能体之间互动的每一步，有助于识别失败点。 -
定期审计：这确保系统按预期运行。
监测和可观测性并不是新概念，但智能体引入了一些挑战。由于智能体以机器速度执行多个行动，组织面临从监测系统生成的大量日志中提取有意义洞见的问题。当高风险异常预期需要实时检测并尽早显露时，这会变得更困难。
设置监测系统时的关键考虑因素包括：
-
记录什么：组织应确定其监测目标（例如实时介入、调试、组件之间集成），以识别需要记录什么。在这样做时，应优先监测高风险活动，例如更新数据库记录或金融交易。 -
如何有效监测日志：组织可以考虑实施以下实践： -
程序化、基于阈值：当智能体触发阈值时定义告警，例如智能体尝试未经授权访问，或在指定时间范围内进行过多重复工具调用。 -
异常值/异常检测：使用数据科学或深度学习技术处理智能体信号，并识别可能表明故障的异常行为。 -
智能体监测其他智能体：设计智能体实时监测其他智能体，标记任何异常或不一致。 -
在多个层面进行监测，例如用户-智能体互动层、智能体-工具调用层和模型推理层，以识别具体失败来源。 -
定义告警阈值： -
定义具体干预：对于每类告警，考虑干预水平应为何。应纳入与风险水平相称的一定程度人类审查。例如，较低优先级告警可以标记为在预定时间审查，而较高优先级告警可能要求暂时停止智能体执行，直到人类审查者能够评估。在发生灾难性智能体故障或被攻陷时，应考虑相应措施，例如终止和后备解决方案。 -
人在环路中：一定程度的人类审查或人在环路中，有助于检测此前可能未被考虑到的任何涌现行为。 -
与可观测性平台集成：考虑将智能体监测与现有可观测性和调试平台集成，包括 OpenTelemetry 等追踪标准，以便详细分析智能体工作流中的工具调用、轨迹和系统互动。 -
确保日志不可变：通过确保有问题的智能体轨迹和失败不能被删除，维护完整审计轨迹，并将其保留用于分析和合规目的。 -
建立反馈循环：建立反馈循环，将监测洞见反馈到训练数据集和评估框架中，以实现持续改进。
最后，即使在部署后，也应持续测试智能体系统，以确保其按预期工作，且不受模型漂移或环境中其他变化影响。
稳健的变更管理
随着智能体系统变得更加复杂，小修改可能级联成更大影响。为防范这一点，应考虑：
-
定义变更审查流程的触发条件。这可以包括技术触发条件（模型更新、工具修改）、环境触发条件（领域变化、业务背景变化）、性能触发条件（异常行为、性能下降）以及监管触发条件（合规要求变化）。 -
按风险对审查变更进行分类。提示优化等小变更可以遵循较轻量审查流程，而模型更新或自主性调整等实质性变更可能需要完整治理审查，影响高风险决策的关键变更则可能要求立即重新进行风险评估。
2.4 促进终端用户责任
最终，终端用户是使用并依赖智能体的人，人类问责也延伸至这些用户。组织应向终端用户提供充分信息，以促进信任并支持负责任使用。
组织应考虑：
-
透明度：应告知用户智能体的能力（例如智能体访问用户数据的范围、智能体可以采取的行动），以及当智能体发生故障时用户可以升级联系的联系人。 -
教育：应教育用户正确使用和监督智能体（例如应就智能体行动范围、幻觉等常见失败模式、数据使用政策提供培训），以及潜在的专业技艺流失，即随着智能体接管更多功能，基础运营知识可能被侵蚀。因此，应提供充分培训（尤其是在智能体普遍存在的领域），确保人类保留核心技能。
2.4.1 不同用户，不同需求
组织应针对具有不同信息需求的不同用户，提供相应信息，使这些用户能够负责任地使用 AI。概括而言，终端用户主要有两类原型：与智能体互动的用户，以及将智能体整合进工作流程或监督智能体的用户。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
2.4.2 与智能体互动的用户
此类用户通常与代表组织行动的智能体互动，例如客服或销售智能体。这些智能体往往面向外部，但也可以部署在组织内部，例如与组织内其他用户互动的人力资源智能体。
对于这些用户，应聚焦透明度。组织应共享相关信息，以培育信任并促进智能体的适当使用。此类信息可以包括：
-
用户责任：清晰定义用户责任，例如要求用户复核智能体提供的所有信息。在适当情况下，允许用户基于其个人风险容忍度，在组织定义的限制之外，为智能体行动设置自己的批准阈值和边界。 -
互动：在用户界面中，在互动发生时即预先声明用户正在与智能体互动，而不是只写在单独文件中。 -
智能体行动和决策范围：告知用户智能体被授权执行和作出的行动及决策范围。 -
数据：根据组织的数据隐私政策，清楚说明用户数据如何被智能体收集、存储和使用。必要时，在为智能体收集或使用用户数据前取得用户明确同意。 -
人类问责和升级：向用户提供负责该智能体的相应人类联系人；如果智能体发生故障，或用户对某项决策不满意，可以提醒这些联系人。
2.4.3 将智能体整合进工作流程的用户
此类用户通常将智能体作为其内部工作流的一部分来使用，例如代码助手、企业流程自动化。智能体为用户并代表用户行动。
对于这些用户，除上述信息外，还应叠加教育和培训，使用户能够负责任地使用智能体。关键方面包括以下教育和培训：
-
关于智能体的基础知识 -
相关用例，使用户理解如何最好地将智能体整合进日常工作，以及在哪些场景下应限制使用智能体（例如不要将智能体用于保密数据）。 -
指示智能体，例如提示的一般最佳实践。 -
智能体的行动范围，使用户了解其能力和潜在影响。 -
对智能体的有效监督 -
常见智能体失败模式，例如幻觉、在错误后陷入循环，使用户能够识别并指出问题。 -
持续支持，例如更新最新功能和常见错误的复训。 -
反馈循环，例如当用户推翻智能体行动或识别错误行动时，使其能够报告，以便在需要时用于改进智能体流程。 -
对专业技艺和业务连续性的潜在影响 -
随着智能体接管通常作为新员工训练的入门级任务，可能导致技能退化，使用户失去基础运营知识。 -
这可能造成业务连续性风险，即当智能体发生故障或不可用时，用户可能不再知道如何手动执行关键流程。 -
组织应识别每项工作的核心能力，并提供充分培训和工作接触，使用户保留基础技能。
关于此类研究的示例，参见《The Quarterly Journal of Economics》，《Generative AI at Work》。
Workday：面向与财务和 HR 智能体互动的终端用户保持透明
Workday 是一个用于管理人员、资金和 AI 智能体的全球企业 AI 平台，被全球各行业超过 11,500 家组织使用，其中包括超过 65% 的《财富》500 强企业。
为简化其内部财务和人力资源运营，Workday 实施了一套专有 AI 智能体。具体而言，HR 智能体的用例包括：
-
Recruiter Agent，支持针对职位角色筛选和评估候选人。 -
Conversational Scheduling Agent，管理完整的面试、入职和活动会议安排生命周期。
Workday 实施了若干设计要素，以符合其减轻已部署 AI 工具下游用户潜在风险的承诺。这包括确保 AI 智能体向终端用户保持透明，并遵守 Workday 的负责任 AI 标准，使用户能够知情且负责任地使用 AI 智能体：
|
|
|
|---|---|
|
|
|
|
|
|
通过使智能体的推理可见，用户获得了审查并以负责任方式使用结果所需的相关基本信息。这些透明度措施旨在支持用户理解其应如何与智能体互动。此外，这些措施旨在突出需要人类判断之处，以确保人类决策并防止较高风险决策被自动化。
Ant International：使终端用户能够稳健设计自己的智能体工作流
Ant International 主要在亚洲、欧洲、中东和拉丁美洲开展运营，是领先的全球数字支付、数字化和金融科技提供者。通过私营和公共部门协作，其统一科技金融平台支持各种规模的金融机构和商户，通过全面的前沿数字支付和金融服务解决方案实现包容性增长。
在内部，Ant International 部署利用第三方 LLM 的 AI 智能体，用于数据质量保证和网络安全等用例。为确保人类能够保持对智能体工作流的控制，该公司一直在试行一个用于智能体 AI 设计和开发的新框架，即 High-Order Program 或 HOP 框架。HOP 框架嵌入在智能体构建器中，并提供一个流程，使用户能够用普通语言描述其智能体目标，并在该智能体工作流由智能体构建器转换为代码之前予以确认。
-
终端用户可以自行读写智能体工作流规范：HopSpec 是一份规范文件，以易于理解的文本（Markdown）逐步列明智能体应做什么以及约束（即 SOP）。具体智能体工作流的要求可以由终端用户起草和审查，包括领域专家、合规官和产品经理。 -
终端用户可以与智能体构建器就良好智能体工作流应是什么样进行迭代：当任务成熟度较低或没有定义清晰的 SOP 时，可能难以定义规范。HOP 会与用户就任务可如何完成进行迭代，探索潜在解决路径，并为其拟议工作流提供置信度分数，供用户评估。 -
智能体工作流内置验证：为防范级联错误，所有智能体工作流都带有可定制和内置验证步骤，例如从输出中重构原始任务、通过对其他 LLM 的单独调用交叉核对回应，以及回应是否符合预期格式。如果任何验证失败，用户将收到智能体重试的通知，并且智能体工作流将在特定次数失败后结束。
例如，在开发用于检测反向 shell 攻击的智能体工作流时，即受害者机器绕过其防御并通过恶意代码向攻击者发起连接，用户可能没有任何定义清晰的 SOP，因为恶意代码可能以多种形式存在，并且类似正常出站连接。
在这种情况下，用户可以从诸如“是否存在任何看起来像反向 shell 攻击的可疑出站连接？”这样的查询开始。智能体构建器随后可以构建一套 SOP，系统性检查文件名、文件路径和目标 IP 等属性，以评估这一点。在与用户迭代并经用户确认后，该工作流将被自动翻译成可以重复执行和验证的代码。
注释
以下注释统一整理自原文脚注、图表说明和来源提示，为避免打断阅读，未在正文中逐条插入。
-
关于 AI 智能体定义与治理基础，参见世界经济论坛（WEF），《AI Agents in Action: Foundations for Evaluation and Governance》。 -
“智能体的核心组成部分”图示参考并改编自《国际 AI 安全报告》、GovTech Singapore《Agentic Risk & Capability Framework》、新加坡网络安全局（CSA Singapore）《Draft Addendum on Securing Agentic AI》，以及 Anthropic《Building Effective Agents》。 -
关于智能体通信协议，参见 Anthropic 的 Model Context Protocol 和 Google 的 Agent2Agent Protocol。 -
关于智能体商务协议，参见 OpenAI 的 Agentic Commerce Protocol、Alipay 的 Agentic Mobile Protocol，以及 Google 的 Universal Commerce Protocol。 -
关于智能体安全可靠运行组件，详见原文 2.3“实施技术控制和流程”。 -
关于多智能体风险分析，参见 Gradient Institute，《Risk Analysis Techniques for Governed LLM-based Multi-Agent Systems》。 -
关于算法定价与算法串通，参见 Bichler, Durmann, & Oberlechner，《Algorithmic Pricing and Algorithmic Collusion》。 -
关于本框架与既有新加坡 AI 治理框架的关系，参见《Model AI Governance Framework》（第二版）。 -
关于 OpenClaw 案例，参见原文完整案例研究。 -
“威胁建模与风险评估之间的关系”图示改编自 CSA，《Guide to Cyber Threat Modelling》。 -
关于智能体限制与部署风险，参见 PwC《The rise – and risks – of agentic AI》、Grab《Introducing the SOP-driven LLM agent frameworks》，以及 McKinsey《Deploying agentic AI with safety and security: A playbook for technology leaders》。 -
关于智能体身份管理，参见 OpenID《Identity Management for Agentic AI》、Microsoft《What is Microsoft Entra Agent ID》、Alibaba Cloud《Agent ID Guard overview》、MCP《Authorisation support》，以及 Cloud Security Alliance《Agentic AI Identity & Access Management: A New Approach》。 -
关于实时失败检测和人类参与设计，参见 Partnership on AI，《Prioritising real-time failure detection in AI agents》。 -
关于推理模型解释的局限，参见 Anthropic，《Reasoning models don’t always say what they think》。