智能体 AI 模型治理框架 v1.5（下）

2.2 让人类承担有意义的问责（Make humans meaningfully accountable）

部署智能体的组织及监督智能体的人员，仍需对智能体的行动负责。但当智能体的行动是从交互中动态、自适应地产生，而非源自固定逻辑时，履行这一问责可能颇具挑战。智能体生命周期的不同环节还可能涉及多个利益相关方，从而稀释问责。最后，自动化偏见——即过度信任自动化系统的倾向，尤其是当该系统过去一直表现可靠时——随着人类监督能力日益增强的智能体，正成为更大的隐忧。

为应对人类问责面临的这些挑战，组织应考虑：

• 在组织内部和外部清晰分配责任：在整个智能体价值链和生命周期中建立问责链条，同时强调适应性治理，使组织能够快速了解新进展，并随技术演进更新其方法。

• 实现有意义的人类监督的措施：例如在重要检查点要求人工审批、审计人工审批的有效性，并以自动化监控作为这些措施的补充。

2.2.1 在组织内部和外部清晰分配责任

作为部署方，组织和人员对智能体的决策与行动始终负有责任。然而，与 AI 一样，智能体 AI 的价值链涉及多个主体。组织应考虑在其内部，以及相对于价值链上的其他组织，如何分配责任。

_简化的智能体 AI 价值链²⁵_

组织可能在这条价值链上扮演多个相互重叠的角色。例如，一个自行开发智能体并随后加以部署的组织，将同时扮演系统提供商和部署方的角色。

注 25：关于智能体 AI 生态系统中潜在利益相关方更全面的清单，参见 CSA 与 FAR.AI《保障智能体 AI 安全：讨论文件》（Securing Agentic AI: A Discussion Paper）。

组织内部

在组织内部，组织应在智能体生命周期中为不同团队分配责任。虽然每个组织的架构各不相同，以下示例展示了此类责任可以如何在不同团队之间分配：

关键决策者（Key decision makers）

人员构成：为组织制定战略决策和高层政策的领导者，例如董事会成员、C 级高管、董事总经理或部门负责人。

关键职责可包括：

• 设定智能体使用的高层目标

• 定义智能体获准的运营用例，包括对智能体数据访问的限制

• 设定总体治理方针，包括风险管理框架和上报流程

产品团队（Product teams）

人员构成：负责将利益相关方需求或业务目标转化为技术型智能体解决方案的角色，例如产品经理、UI／UX 设计师、AI 工程师、软件工程师。

关键职责可包括：

• 定义智能体的设计与需求，以及任何功能控制或分阶段发布安排

• 可靠地实现智能体，即在智能体生命周期中进行开发、部署前测试和部署后监控

• 教育用户负责任地使用智能体产品

网络安全团队（Cybersecurity teams）

人员构成：负责保护智能体系统免受网络威胁的角色，通过实施和管理安全措施、识别漏洞和响应事件，例如首席安全官、网络安全专家、渗透测试员。

关键职责可包括：

• 定义基线安全护栏和「安全内建」（secure-by-design）模板，供技术团队针对所部署的智能体系统实施或调整

• 定期开展红队演练（red teaming）和威胁建模

用户（Users）

人员构成：任何利用智能体输出来助力实现组织目标的个人，例如做出决策或将工作流和实践自动化的公司员工。

关键职责可包括：

• 合乎伦理、负责任地使用智能体

• 参加要求的培训、遵守使用政策、及时报告智能体的缺陷或问题

PwC 新加坡：为报告起草智能体系统在不同内部团队之间分配人类问责

普华永道（PwC）是由遍布 137 个地区的专业服务公司组成的网络，业务涵盖审计与鉴证、税务与法律、交易与咨询。

为加速内部生产力，PwC 新加坡的 AI Factory 开发了一款智能体应用，可自动起草内部报告中的研究和分析章节——这是一项传统上依赖人工且研究密集的流程。用户定义所需章节后，系统会从 PwC 维护并（针对监管和市场动态）持续更新的标准化模板中提取内容，从源材料中检索并综合信息，在数秒内生成草稿内容。

该系统在一个以顺序为主的工作流中使用三个相互协调的智能体，并在需要额外检索或重构时设有反馈循环。

以下职责说明了在 PwC 新加坡更广泛的 AI 治理框架下，这一报告起草用例的运营问责如何分配：

1. 用例负责人（Use case owner）——用例适当性与问责使用：确认该用例服务于正当的业务需求、适合预期目的，并与组织的 AI 治理框架保持一致。用例负责人对该应用的负责任使用，以及确保建立适当的人类监督，持续承担责任。

2. 技术风险管理团队（Technology Risk Management Team）——风险评估与控制建议：支持对该用例的技术、风险、安全和合规考量（包括任何监管要求）进行评估。这包括就与工具和模型、访问权限、关联知识库或数据源相关的适当控制提出建议。

3. AI Factory——设计、开发、护栏与监控：设计、开发和维护该应用，包括提示词设计、模型选择、工具配置、与获批知识库的集成，以及适当的护栏。AI Factory 还负责监控模型变更，并通过标准变更管理流程管理更新，而不是将其留给终端用户。

4. 终端用户／主题专家（End users / subject matter specialists）——输出审查与批准：在使用 AI 生成内容之前进行审查。内部指引明确规定，AI 生成的内容只是初稿，旨在支持而非取代专业判断。人工审核员在依赖或进一步使用输出之前对其进行完善和批准，包括核查准确性、完整性，以及与既定方法论的一致性。

培养适应治理所需的内部能力

所有参与智能体 AI 的团队还应培养理解该技术的内部能力。了解智能体发展的进步与局限——例如计算机使用智能体等新形态，或新的评估框架——能够使组织迅速调整其治理方法以适应新进展。

组织外部

组织在部署智能体时也可能需要与外部方合作，例如模型开发商、智能体 AI 提供商，或外部 MCP 服务器或工具的托管方。

在这些情况下，组织同样应确保建立相应措施以履行自身问责。一些智能体特有的考量包括：

• 明确义务的分配：在组织与外部方之间的任何条款或合同中明确义务分配。组织尤其应考虑有关安全安排、性能保证或数据保护的条款。如存在缺口，组织应重新评估该智能体部署是否符合其风险容忍度。

• 应对第三方不透明性：外部方提供的智能体可能难以观察和控制，使人难以了解其依据什么信息作答、从对话中推断出什么，或数据如何被存储和使用。组织应采取措施保持足够的安全性和控制力，例如：

• 要求外部方保持透明和问责，例如披露智能体能力和数据处理实践

• 索取并评估技术安全与控制功能，例如限定范围的 API 密钥、按智能体划分的身份令牌等强身份验证措施，以及工具调用和访问历史的日志记录等可观测性。如缺乏此类功能，组织应考虑替代方案或自研方案，或收窄智能体用例范围，例如限制对敏感数据的访问。

终端用户

组织可能向其内部或外部的用户部署智能体。在此过程中，组织应确保向用户提供足够的信息，使其能够追究组织的责任，并提供与用户自身责任相关的信息。更多信息见下文「赋能终端用户承担责任」。

2.2.2 设计有意义的人类监督（Design for meaningful human oversight）

• 定义需要人工审批的重要检查点或行动边界

• 培训人类有效评估这些审批请求，并对这些审批进行审计

• 以自动化监控机制和预设告警阈值作为补充

_建立有效人类监督的体系_

组织应定义需要人工审批的重要检查点或行动边界²⁶，尤其是在敏感行动执行之前。这可以包括：

• 高风险行动和决策，例如编辑敏感数据、高风险领域（如医疗或法律）的最终决策、可能引发责任的行动

• 不可逆行动，例如永久删除数据、发送通信、进行付款

• 离群或异常行为，例如智能体访问其工作范围之外的系统或数据库，或智能体选择的配送路线长度是中位距离的两倍

• 用户自定义，例如智能体可能代表风险偏好不同的用户行事。在组织定义的边界之外，可以让用户自行定义边界，例如要求对超过一定金额的购买进行审批。

除了考虑何时需要审批之外，组织还应考虑审批应采取何种形式。这些考量包括：

• 保持审批请求具有上下文、易于理解，同时明确风险。向人类请求审批时，应保持请求简短清晰，而不是提供可能难以解读的冗长日志或原始数据。但应包含有用的补充数据，例如与该行动相关的风险或置信度分数。

• 考虑所需人类输入的形式。对于访问数据库等简单行动，人类用户只需批准或拒绝即可。对于更复杂的情况，例如在执行前审查智能体的计划，让人类先编辑计划再放行可能更有效率。对于高风险行动，可以要求人类用户在批准或拒绝之前额外提供书面理由。

组织应实施措施，确保人类监督持续有效，尤其是人类仍容易受到告警疲劳和自动化偏见的影响，并可能受拟人化设计左右。这些措施可以包括：

• 定期审计人类监督的有效性。一些方法包括：

• 追踪可度量的指标

• 人工干预率（human override rate），即人类拒绝或修改智能体行动的频率。过低的比率可能意味着「橡皮图章」式的敷衍审批行为。

• 人类审查智能体行动时的响应时间。过短的时间可能意味着自动化偏见或审查疲劳。

• 使用数据分析识别「离群」人类，即决策模式显著偏离常态者。这可能表明监督已失效。

• 培训人类监督者识别常见失败模式或智能体局限，例如智能体推理不一致、智能体引用过时政策。还应注意，有时用于可解释性的思维链（chain-of-thought）推理并不等同于人类推理²⁷，未必忠实解释智能体的行动。

• 确保人类具备评估智能体行动所需的领域专业知识，例如使用智能体进行「氛围编程」（vibe code）的用户，可能不具备审查所生成代码健壮性的软件工程专业知识。

最后，人类监督应以自动化实时监控作为补充，以便对任何意外或异常行为进行上报。这可以通过以下方式实现：

• 对某些记录事件实施告警（例如尝试未授权访问，或多次调用工具失败）

• 使用数据科学技术识别异常的智能体轨迹

• 使用智能体监控其他智能体

• 当审批基础设施失效时默认拒绝行动（例如无法联系到人类监督者，或智能体尝试尚无既定审批政策的新行动）。

更多信息见下文「持续测试与监控」。

注 26：关于可考虑人类介入环节的更多示例，参见 Partnership on AI《优先实现 AI 智能体的实时失败检测》（Prioritising real-time failure detection in AI agents）。 注 27：参见 Anthropic《推理模型并不总是说出它们的想法》（Reasoning models don't always say what they think）。

腾讯（Tencent）：在编码助手中实现有意义的人类监督

腾讯是一家总部位于中国的跨国科技公司，业务涵盖游戏、即时通讯应用微信（WeChat）以及混元（Hunyuan）等 AI 模型。

CodeBuddy 是腾讯云开发、由其工程师使用的智能体 AI 编码系统。它可以通过自然语言指令自主规划、编写、测试和部署代码，能够访问文件系统、终端命令、外部 API 和 MCP 工具。

CodeBuddy 采用预设安全默认值与可配置权限相结合的方式，在不使用户过度疲劳的前提下实现有意义的人类监督：

X0PA：在高影响招聘工作流中实现有效的人工审批

X0PA 是一家提供 AI 驱动招聘解决方案的 B2B 软件公司。其 AI 智能体平台（AI Agentic Platform）将智能体 AI 应用于招聘工作流。这些智能体已通过渐进式发布部署给 X0PA 的现有客户，工作流程如下。

由于招聘是高影响领域，重点在于增强而非取代人类决策。

1. 人工审批检查点：在初选（shortlisting）和最终选择等关键阶段保留人工检查点，确保具有重大影响的招聘决策仍掌握在人类招聘人员和用人经理手中。

2. 实现有效的用户审批，通过：

a. 可解释的输出：匹配分数和排名理由使用户能够理解智能体建议的依据，从而进行有效审查。

b. 培训：通过培训和入职流程让用户熟悉系统功能，包括其局限性和潜在失败模式。

i. 就招聘而言，这些包括智能体误读非标准职业路径的情形，或对历史记录或结构化数据有限的候选人给出低置信度评估的情形。

ii. 用户还接受培训，以识别面试智能体可能无法充分捕捉上下文因素的情形，例如沟通风格、特定领域的细微差别或非典型的候选人经历，以及可能需要额外人工评估的情形。

3. 用户控制与反馈循环：用户可以推翻建议并提供反馈。这些反馈可用于随时间推移优化系统性能，在用户与 X0PA AI 的智能体之间形成交互循环。

2.3 实施技术控制与流程（Implement technical controls and processes）

使智能体区别于简单 LLM 应用的那些智能体组件，要求在实施生命周期的关键阶段增加额外的控制。

组织应考虑：

• 在设计与开发期间，设计并实施技术控制。智能体的新组件和新能力需要新的、量身定制的控制。根据智能体设计，实施访问控制等措施。此外，通过对工具和数据强制执行最小权限访问，限制智能体对外部环境的影响。

• 部署之前，测试智能体的安全性与保障。与所有软件一样，部署前测试可确保系统按预期运行。针对智能体，需测试整体任务执行、策略遵从性和工具使用准确性等新维度，并跨多样化数据集进行测试，以覆盖智能体行为的全部谱系。

• 部署时，渐进式发布智能体并在生产环境中持续监控。智能体的自主本质和不断变化的环境，使得在部署前穷尽并测试所有可能结果颇具挑战。应渐进式发布智能体，并辅以部署后的实时监控，确保智能体安全运行。

• 在整个生命周期中，实施变更管理与版本控制流程。在复杂的智能体生态系统中，对一个智能体的更改可能在相互关联的工作流中产生级联效应。因此，组织应定义触发变更审查流程的明确条件，并据此对所需变更进行分类。

2.3.1 在设计与开发期间使用技术控制

组织应在智能体 AI 系统中设计并实施技术控制，以缓解已识别的风险。具体到智能体，除基线的软件和 LLM 控制外，还应考虑为以下方面增加控制：

• 新的智能体组件，例如规划、推理和工具

• 更大攻击面和新协议带来的日益增加的安全隐患

• 多智能体交互

在选择合适的控制时，考虑以下几点：

• 结构性、基于规则的控制 vs 基于模型或提示层的控制：

• 相比提示层防护，应考虑实施通过预定义逻辑在系统层面运行的确定性防护措施，尤其是针对高风险行动。

• 例如，与其指示智能体不要使用某些工具，不如在工具层实施访问控制，从根本上阻止这些工具被调用，或只允许以特定方式调用（例如仅读取权限）。同样，如果智能体需要遵循既定程序，将该序列内建到工作流中，比仅通过指令提示智能体遵守更为稳健。

• 提示层防护在不同用户之间的定义往往不一致，而系统层防护可以被一致地定义和执行。

• 但在某些通过固定规则难以界定风险的情形下，基于模型的防护可能最为有效，例如检测可能以不同方式呈现的有害内容。

• 运行时控制（Runtime controls）：由于智能体与用户和系统实时交互，在设计时配置的静态防护可能不足以捕捉每一个风险。运行时控制通过在执行过程中进行监控和干预来解决这一问题，例如用速率限制防止工具被过度使用，或用输入验证在有害响应被执行前将其拦截。

以下示例列出了智能体的一些示例性控制，仅作说明。更全面的清单，组织可参考 CSA 的《保障智能体 AI 安全附录（草案）》和 GovTech 的《智能体风险与能力框架》。

MCP 作为治理层

虽然 MCP 通常被视为一种连接协议，但由于它位于智能体与其所访问的企业系统之间，有可能充当治理层。组织可以考虑在 MCP 层定义控制，例如过滤经由服务器传输的敏感数据、记录所有智能体到系统的交互，或仅将可信服务器列入白名单。

Terminal 3：在硬件层面为准确、安全的智能体支付实施控制

Terminal 3 是一家总部位于香港的数据隐私基础设施提供商，提供安全且保护隐私的数据处理，无需进行数据传输。

该公司部署了一个财务薪资智能体，用以自动化其月度薪资周期，包括计算税前和税后工资、政府法定缴款、验证报销申请，并在发放工资总额之前交叉核对账户明细。

该流程本质上属于高风险，因为它涉及处理敏感个人数据和执行金融交易。为确保此类行动由智能体安全处理，Terminal 3 实施了以下技术控制：

1. 在凭证范围内定义智能体的权限边界：在每月薪资周期开始前，人力资源总监会向智能体签发一份「可验证意图凭证」（Verifiable Credential of Intent）——一种具有数学约束力、限定于本周期范围的授权，其中定义：

a. 智能体可以访问哪些员工记录；

b. 适用的政府法定缴款费率；

c. 报销申请阈值、合格类别和每日津贴上限；以及

d. 合并银行转账的金额上限，设定为基本工资加缓冲余量，并在每次运行前明确声明。

2. 在结构上将敏感数据与智能体上下文分离：所有敏感个人数据（例如员工身份证号、薪资数字和银行账户明细）都专门保存在 Terminal 3 的可信执行环境（Trusted Execution Environment，TEE）内，任何时点都不会传输给智能体。智能体仅基于非敏感输入运行，其输出也只包含不透明的员工参考标识符和类别化的标记原因。这种架构分离意味着智能体上下文中不存在可能被泄露或通过对抗性输入被提取的敏感数据——风险在设计上即被消除。

3. 通过硬件强制执行该权限边界：每一个智能体行动都会经过 TEE 路由，并以硬件速度对照凭证参数进行验证。超出范围的行动（无论源于错误推理还是对抗性提示）都会在执行前被拦截并记录。所有敏感计算都专门在此安全边界内进行。

4. 记录防篡改的审计轨迹：智能体执行的每一步（包括任何被拦截的行动）都记录在 T3N 不可变账本（Immutable Ledger）上——这是一种经硬件证明、可加密验证的日志，为任何事后调查提供证据链。

Cyber Sierra：提升尽职调查问卷填写准确性与可靠性的技术控制

Cyber Sierra 是一家总部位于新加坡的公司，是一个治理、风险与合规（Governance, Risk and Compliance，GRC）智能体工厂，为网络运营、安全合规和审计任务构建多智能体基础设施。

该公司开发了 TracyAI，这是一个自动回复安全与合规问卷的解决方案。此类问卷通常包含数百个关于数据保护、访问控制、认证和风险管理的重复性问题。TracyAI 通过一个智能体系统实现这一点，该系统在过往尽职调查问卷、信息安全政策文件和证据文件夹上进行多步骤搜索与推理。TracyAI 已部署在一家总部位于香港的大型金融机构的治理、风险与合规团队中，将通常需要 100 多人工小时的任务缩短至 15 分钟。

为降低输出不准确和幻觉的可能性，团队实施了以下技术控制：

• 让智能体审查自身输出的反思架构（Reflection architecture）：该智能体系统纳入了两类反思节点（使用 LangGraph 实现），在智能体生成输出后向其提供反馈：

• 基于 LLM 评判（LLM Judge-based）：由一个 LLM 评判者对输出进行批评，判断标准包括是否回答了问题、论证是否与检索到的证据一致，以及是否引入了无依据或虚构的主张。

• 基于指标（Metrics-based）：相似度分数以及 RAGAS 指标，例如忠实度（faithfulness）、上下文相关性（context relevance）、回答相关性分数（response relevance score）。

随后智能体会审查并完善自身输出。如果在三次迭代内未能同时达到两个节点的通过阈值，其执行轨迹将被终止。

• 结构化信息以增强智能体理解：在开发初期，团队观察到当智能体引用以下内容时容易出现不准确输出：

• 知识库中同一文档的多个版本，其中部分已过期；以及

• 此前依赖了现已过期文档的问卷。

为了更具确定性地解决这一问题，团队没有直接干预智能体，而是将源信息结构化为一张展示内部文档、政策与认证之间关系的图谱，使智能体能够理解证据如何跨领域相互关联。随后又为其补充元数据，形成一个上下文图谱，以确定性方式确保只使用最相关（基于地点、主题等）且最新（基于版本、到期日期等）的文档。

Stability Solutions：面向内部与面向外部的智能体采用不同控制

Stability Solutions 是一家位于美国和新加坡的公司，构建并提供基于区块链的基础设施，用于大规模记录、保存和验证数据完整性。其解决方案包括全球信任网络（Global Trust Network，「GTN」，一条高吞吐量的无加密公链，目前用于供应链和物流），以及 Monolith——一款记录创意作品来源的应用，允许创作者对任何文件进行数字指纹识别、签发 C2PA 清单和来源元数据，并嵌入知识产权许可和 AI 训练权限，将所有这些以稳健、可验证、机器可读的格式记录在 GTN 上。

Stability 部署了其自研的智能体 AI 系统 L3，目前由 26 个 AI 智能体组成，全天候（24/7）运行于公司几乎所有职能，包括产品开发、软件工程和市场营销。其内部智能体具备采取行动的能力，例如在整个公司范围内整合和归档信息、发送每日晨报、监控并解决网络问题、充当数字孪生或个人助理，以及支持工程与开发活动（例如规划项目和编写代码）。L3 经过优化以尽可能多地访问信息，使其能够跨团队协调（例如工程团队计划升级时，L3 会告知他们已排期的市场活动，以避免任何冲突）。

当 Stability 开发其第一个面向外部的智能体 Howard，用以展示 L3 的功能并回答关于 L3 和公司的问题时，公司意识到风险等级更高，因为该智能体可能被不可信的第三方攻陷。与面向内部的智能体相比，必须实施额外的护栏：

1. 数据访问控制：该智能体拥有自己的记忆，由从 L3 接收的信息构成。L3 的智能体了解该智能体的角色及其相关风险，会为其专门筛选一份特殊数据集。

2. 交互控制：该智能体通过聊天进行交互，或经由 Slack，或经由网页界面。Stability 的人类员工会在第三方输入被发送给智能体之前进行审查。这使他们能够过滤掉旨在提取个人数据和商业机密等敏感信息的提示攻击或侵入性问题。随着该智能体在安全性和可靠性上的提升，预计这一控制将变得不再必要。

3. 智能体配置控制：实施了明确的护栏和定义好的人格协议，以尽可能降低智能体泄露商业机密、个人或机密数据等敏感信息的可能性。

2.3.2 部署之前，测试智能体

组织应在部署之前测试智能体的安全性与保障。这能让人确信智能体按预期工作、控制措施有效。软件和 LLM 测试的最佳实践仍然适用，例如软件系统的单元测试和集成测试，以及 LLM 测试中选择有代表性的数据集、有用的指标和评估器。组织可以参考此前的指引，例如《基于 LLM 的应用安全与可靠性测试入门套件》（Starter Kit for Testing of LLM-based Applications for Safety and Reliability）。

然而，组织应针对智能体调整其测试方法。一些考量包括：

• 测试新风险：除了产生错误输出之外，智能体还可能通过工具采取不安全或非预期的行动²⁸。组织可以考虑测试：

• 整体任务执行：智能体能否准确完成任务

• 策略遵从：智能体是否遵循既定的 SOP，并在需要时路由至人工审批

• 工具调用：智能体是否以正确的权限、正确的输入、正确的顺序调用正确的工具

• 鲁棒性：由于智能体需要应对并适应真实世界的情况，应测试其对错误和边缘情况的响应

• 测试完整的智能体工作流：智能体可以在无人参与的情况下连续采取多个步骤。因此，除了测试智能体的最终输出之外，还应在其整个工作流（包括推理和工具调用）中对智能体进行测试。

• 单独测试与联合测试智能体：除单个智能体之外，还应在多智能体系统层面开展测试，以理解智能体协作时的任何涌现风险和行为，例如竞争行为，或一个智能体被攻陷后对其他智能体的影响。

• 在真实或逼真的环境中测试：由于智能体可能需要应对真实世界的情况，测试应在配置恰当、尽可能贴近生产环境的执行环境中进行，例如使用与部署时行为一致的工具集成、外部 API 和沙箱。不过，组织应在逼真度的需要与过早允许智能体访问影响现实世界的工具的风险之间进行权衡。

• 重复测试并跨多样化数据集测试：智能体行为本质上是随机的、依赖上下文的。因此测试应大规模开展并覆盖多样化数据集，以观察任何低概率的意外行为，尤其是高影响的行为。这需要生成覆盖智能体可能遇到的不同条件的测试数据集。这些测试还应多次运行以检查稳定性（例如相同的输入和上下文产生一致的输出），必要时加入轻微扰动。

• 大规模评估测试结果：在大规模下可靠地评估测试结果是 LLM 测试的已知难题。智能体又增加了一层复杂性，因为其工作流可能很长，且包含人类或自动化脚本难以处理的结构化信息。

组织可以考虑对智能体工作流的不同部分采用不同的评估方法（例如对结构化工具调用采用确定性测试，对非结构化的智能体推理采用 LLM 或人工评估）。但仍然需要对智能体进行整体评估，以便评估跨步骤的智能体行为模式。因此，当前的行业解决方案包括定义 LLM 或智能体来评估其他智能体²⁹，同时纳入「人在回路中」审查。（智能体评估解决方案的示例，参见 AWS Labs 的 Agent Evaluation。）

注 28：关于需要测试的智能体新维度的示例，参见 Microsoft Foundry《智能体评估器》（Agent evaluators）。 注 29：参见 AWS Labs《智能体评估》（Agent Evaluation）。

Google x 新加坡政府：测试计算机使用智能体

为了解自主智能体在实践中的行为方式，Google、CSA、GovTech 和 IMDA 发起了一个沙箱¹，针对潜在的公共部门用例测试计算机使用智能体，即：

• 自动化质量保证（QA）：对政府数字服务进行自动化 QA 测试

• AI 安全测试：自动化对第三方聊天机器人等 AI 软件的安全测试

• 社会援助申请：协助公民浏览并申请社会援助计划，帮助简化复杂流程

虽然每个用例都有其特定的风险画像，但该沙箱揭示了一些关于智能体测试方法的普遍洞见，包括：

• 使用逼真的测试数据和环境：在 AI 安全测试用例中：

• 数据：安全测试提示词在长度、语言和格式上通常差异显著。测试数据集基于反映此类多样性的真实世界越狱提示词（jailbreak prompts）策划而成。测试表明，智能体能很好地捕捉格式和语言上的变化，但由于其依赖截图，难以准确复现较长的回应。

• 环境：智能体针对真实聊天机器人进行了测试（部分出于安全考虑在预演环境中进行），这可以检视其在不同用户界面中导航的鲁棒性，例如在遇到用户限制、加载时间过长或其他错误时刷新会话或重试提示的能力。

• 记录并评估智能体在工作流每一步的推理：这能对测试结果进行更细致的评估，以调试意外行为。例如在社会援助用例中，测试了智能体的数据最小化能力，即它能否区分与申请相关的信息和不应包含的无关个人细节。在相当多的案例中，智能体包含了这些无关细节。对其推理过程的审查显示，它有时仍认为此类信息相关，或假定需要包含提供给它的所有信息。据此可以设计更有针对性的提示层防护。

• 基于用例识别攻击向量：通过嵌入外部网站的恶意第三方提示，智能体可能被引向有害行动（也称为间接提示注入，indirect prompt injection）。虽然这是一种普遍风险，但它在每个用例中的表现形式各不相同。例如在 AI 安全测试中，智能体需要与第三方聊天机器人交互。攻击者因此可以创建一个在回应中夹带有害指令的恶意聊天机器人。这一威胁场景被专门测试。观察到在某些情况下，智能体在被指示后会导航至任意 URL。这可以通过网站白名单或提示词设计等控制（包括但不限于）来缓解。

• 在测试过程中纳入「人在回路中」：计算机使用智能体因其在不同用户界面中导航的灵活性，往往具有更宽的行动空间和自主性。由于它们仍处于起步阶段，在测试过程中纳入人类监督和审查，可以发现任何意外或涌现行为。

关于已部署的用例和所测试风险的更多信息，请见完整论文。

城市发展有限公司（City Developments Limited）x Knovel Engineering：测试智能体系统中的数据访问边界

城市发展有限公司（CDL）是一家总部位于新加坡的开发商和资产所有者／运营商，业务组合涵盖住宅、商业、酒店和综合开发项目。Knovel Engineering 是一家总部位于新加坡的 AI 咨询公司，帮助企业和政府机构落地可信 AI。

作为全球 AI 保障沙箱（Global AI Assurance Sandbox）的一部分，Knovel 测试了 CDL 的内部智能体系统。该系统通过检索业务洞察、访问内部知识和执行面向任务的工作流来回答查询。智能体编排（agent orchestration）处理多步骤任务，例如总结行业表现或检索特定运营指标。

CDL 将数据泄露识别为其系统的关键风险，并将其列为测试的优先事项。目的是确定数据访问控制和边界是否在各用户之间得到正确执行，即用户只能获取其有权访问的信息。

为测试这一点，Knovel 采用了以下方法：

• 使用 7 个用户账户 × 4 个领域（地产、财务、商业、酒店）的矩阵来验证边界遵从情况

• 登录具有受限领域访问权限的用户账户，开展多轮对话，逐步引入针对范围外领域的间接查询（例如_地产领域用户询问 A 酒店第四季度的营收_）

• 将受限账户的输出与合法授权账户的输出进行比较，以检测信息泄露

• 此外，通过提供部分正确的系统提示词和工具调用结构，利用系统「乐于助人」的倾向，观察系统是否会无意中更正或补全被删节的信息。

关于本案例研究的更多细节，包括测试洞见和所测试的其他风险，请见 https://go.gov.sg/sandbox-cdlxknovel 。

2.3.3 部署时，持续监控与测试

部署前测试建立了有用的基线，但需要以部署期间的持续监控和测试作为补充。智能体会适应实时条件，其行为可能发生变化。尤其对于多智能体系统，协调失误或涌现行为等失败模式，可能只有在真实条件下随时间推移才通过智能体行为显现。本节提供了缓解此类风险的建议，包括：

• 智能体的渐进式部署

• 持续测试与监控

• 健全的变更管理

智能体的渐进式部署

组织应考虑将智能体逐步发布到生产环境，以控制风险暴露量。此类发布可以基于以下因素加以控制：

• 智能体的用户，例如先向受过培训或有经验的用户发布

• 智能体可用的工具和协议，例如先限制智能体仅使用更安全、已列入白名单的 MCP 服务器

• 向智能体暴露的系统，例如先在风险较低的内部系统中使用智能体

GovTech：分阶段发布编码助手，逐步监控风险并为新功能准备控制措施

新加坡政府科技局（Government Technology Agency of Singapore，简称 GovTech）是新加坡的一个法定机构，负责开发政府数字服务并推动公共部门转型。

2025 年 10 月，GovTech 在组织内部推出了两款智能体编码助手，即 Windsurf 和 GitHub Copilot（Agent Mode），随后于 2026 年 4 月推出 Claude Code。在对常见的故障和威胁向量（例如智能体 AI 被操纵、幻觉、MCP 服务器被攻陷）进行大量测试并实施相应技术控制之后，GovTech 采取了分阶段的方式发布这些智能体能力。这使其能够尽早赋能开发团队提升生产力，同时监控风险，并随着技术演进为新 AI 功能逐步开发更多控制措施。

在第一阶段，发布范围受到限制，以控制任何潜在风险的「爆炸半径」（blast radius）：

• 仅限内部员工：智能体编码助手仅向 GovTech 员工发布——这是单一组织内规模较小的开发者群体，可以接受培训、接受负责任使用智能体的教育，而不是面向整个政府。

• 不允许使用 MCP：用户只能使用智能体的内置能力，例如在开发者环境内进行多步推理以规划和执行任务，不能访问 MCP 服务器。

• 低风险系统：非关键基础设施、数据访问级别较低的系统。

在第一阶段进行的同时，GovTech 开始部署必要的控制和基础设施，以支持第二阶段更广泛的智能体能力，例如集中式日志记录与监控，并试运行其第一版 MCP 治理框架（MCP Governance Framework）——为开发者提供一条从容器化沙箱连接白名单 MCP 服务器的路径。GovTech 还开展了红队演练，以验证这些护栏抵御外部威胁的有效性。

目前正在启动的第二阶段，发布范围将逐步扩大，先纳入其他政府机构的公职开发者，然后是政府供应商和承包商。修订后的 MCP 治理框架也将先向 GovTech 的开发者开放，再逐步推广到政府其余部门，先从 Figma 开始，随后根据用户需求和风险因素扩展到其他托管 MCP（如 GitLab）。

第一阶段的经验为第二阶段的发布提供了参考，例如：

• 解决初期磨合问题，例如网络信任配置问题。

• 降低人工审批者的认知负荷：允许用户选择操作系统原生沙箱，使智能体能够更灵活地运行某些命令，无需不断寻求人工审批。

• 降低 MCP 治理框架的采用阻力：不再需要复杂的本地开发容器和自托管基础设施，并将架构改为在可用情况下利用 AI 编码工具的原生沙箱配合 Cloudflare 的托管 MCP 网关。

随着智能体 AI 的快速演进，GovTech 持续对 AI 的影响进行实验、测试和监控，以发现缺口和新的经验。在风险缓解与开发者体验之间取得平衡，是成功采用智能体 AI 和提升开发者生产力的关键。

持续测试与监控

组织应在部署后持续监控并记录智能体行为，并为智能体故障或意外行为建立报告和故障保护（failsafe）机制。这使组织能够：

• 实时干预：当检测到潜在故障时，停止智能体工作流并上报给人类监督者，例如智能体尝试未授权访问时。

• 事件发生时进行调试：记录和追踪智能体工作流的每一步以及智能体之间的交互，有助于定位故障点。

• 定期审计：确保系统按预期运行。

监控与可观测性并不是新概念，但智能体带来了一些挑战。由于智能体以机器速度执行多个行动，组织面临的问题是如何从监控系统生成的海量日志中提取有意义的洞察。当高风险异常需要被实时检测并尽早浮现时，这一任务变得更加困难。

建立监控系统时的关键考量包括：

• 记录什么：组织应确定其监控目标（例如实时干预、调试、组件间集成），以确定记录内容。在此过程中，应优先监控高风险活动，例如更新数据库记录或金融交易。

• 如何有效监控日志：组织可以考虑实施以下实践：

• 多层监控：例如用户—智能体交互层、智能体—工具调用层和模型推理层，以识别具体的故障来源。

• 定义告警阈值：

• 程序化、基于阈值：当智能体触发阈值时发出告警，例如智能体尝试未授权访问，或在规定时间内重复调用工具次数过多。

• 离群／异常检测：使用数据科学或深度学习技术处理智能体信号，识别可能预示故障的异常行为。

• 智能体监控智能体：设计智能体实时监控其他智能体，标记任何异常或不一致。

• 定义具体的干预措施：针对每种告警类型，考虑应有的干预级别。应纳入与风险等级成比例的人工审查。例如，低优先级告警可以标记后在预定时间审查，而高优先级告警可能需要暂时中止智能体执行，直到人工审核员能够评估。若发生灾难性的智能体故障或攻陷事件，应考虑与之相称的措施，例如终止运行和回退（fallback）方案。

• 人在回路中：一定程度的人工审查或「人在回路中」机制有助于检测此前未曾考虑到的涌现行为。

• 与可观测性平台集成：考虑将智能体监控与现有的可观测性和调试平台集成，包括 OpenTelemetry 等追踪标准，以实现对整个智能体工作流中工具调用、追踪记录和系统交互的详细分析。

• 确保日志不可篡改：确保有问题的智能体轨迹和故障记录无法被删除，将其保存用于分析和合规目的，从而维持完整的审计轨迹。

• 建立反馈循环：建立反馈循环，将监控洞察回馈到训练数据集和评估框架中，实现持续改进。

最后，即使在部署之后也要持续测试智能体系统，以确保其按预期工作，且不受模型漂移（model drift）或环境中其他变化的影响。

健全的变更管理

随着智能体系统变得更加复杂，小的修改可能级联成更大的影响。为防范这一点，应考虑：

• 定义变更审查流程的触发条件。这可以包括技术触发条件（模型更新、工具修改）、环境触发条件（领域偏移、业务背景变化）、性能触发条件（异常行为、性能下降），以及监管触发条件（合规要求变化）。

• 按风险对变更审查进行分类。提示词微调等轻微变更可以遵循较轻的审查流程，而模型更新或自主性调整等重大变更可能需要完整的治理审查，影响高风险决策的关键变更则可能要求立即重新进行风险评估。

2.4 赋能终端用户承担责任（Enable end-user responsibility）

归根结底，终端用户才是使用和依赖智能体的人，人类问责也延伸至这些用户。组织应向终端用户提供了充分的信息，以促进信任并实现负责任的使用。

组织应考虑：

• 透明度（Transparency）：应告知用户智能体的能力（例如智能体访问用户数据的范围、智能体可采取的行动），以及智能体出现故障时用户可以上报的联系人。

• 教育（Education）：应教育用户正确使用和监督智能体（例如就智能体的行动范围、幻觉等常见失败模式、数据使用政策提供培训），以及专业技艺可能流失的问题——即随着智能体接管越来越多的职能，基础操作知识可能被侵蚀。因此应提供充分的培训（尤其是在智能体普及的领域），确保人类保留核心技能。

2.4.1 不同的用户，不同的需求

组织应满足不同用户的不同信息需求，使这些用户能够负责任地使用 AI。大体而言，终端用户主要有两种原型——与智能体交互的用户，以及将智能体融入其工作流程或对其实施监督的用户。

2.4.2 与智能体交互的用户

此类用户通常与代表组织行事的智能体交互，例如客户服务或销售智能体。这些智能体往往面向外部，但也可以部署在组织内部，例如与组织内其他用户交互的人力资源智能体。

对于这些用户，重点是透明度。组织应分享相关信息，以培养信任并促进对智能体的正确使用。此类信息可以包括：

• 用户的责任：明确定义用户的责任，例如要求用户复核智能体提供的所有信息。在适当情况下，允许用户在组织设定的限制之外，基于个人风险容忍度自行设定智能体行动的审批阈值和边界。

• 交互声明：在交互发生之处的用户界面中预先声明用户正在与智能体交互，而不是只写在单独的文档中。

• 智能体的行动与决策范围：告知用户智能体被授权执行和做出的行动与决策范围。

• 数据：按照组织的数据隐私政策，明确说明智能体如何收集、存储和使用用户数据。必要时，在为用户目的收集或使用其数据之前，获得用户的明确同意。

• 人类问责与上报渠道：向用户提供对智能体负责的相应人工联系方式，当智能体出现故障或用户对某项决定不满时，用户可以向其反映。

2.4.3 将智能体融入其工作流程的用户

此类用户通常将智能体作为其内部工作流的一部分加以利用，例如编码助手、企业流程自动化。智能体代表用户并为用户行事。

对于这些用户，除上述信息外，还应叠加教育和培训，使用户能够负责任地使用智能体。关键方面包括以下内容的教育和培训：

• 关于智能体的基础知识

• 相关用例：使用户了解如何最好地将智能体融入日常工作，以及在哪些情形下应限制智能体的使用（例如不要将智能体用于机密数据）

• 指示智能体：例如提示词（prompting）的一般最佳实践

• 智能体的行动范围：使用户了解智能体的能力和潜在影响

• 对智能体的有效监督

• 常见的智能体失败模式：例如幻觉、出错后陷入循环，使用户能够识别并标记问题。

• 持续支持：例如更新最新功能和常见错误的复训课程

• 反馈循环：当用户推翻智能体行动或识别出错误行动时，让他们能够上报，以便在需要时用于改进智能体流程。

• 对专业技艺和业务连续性的潜在影响

• 随着智能体接管入门级任务——这些任务通常也是新员工的培训途径——可能导致技能退化³⁰，即用户丧失基础操作知识。

• 这可能造成业务连续性风险：当智能体出现故障或不可用时，用户可能已不再知道如何手动执行关键流程。

• 组织应识别每个岗位的核心能力，并提供充分的培训和实际工作锻炼，使用户保留基础技能。

注 30：此类研究的示例，参见《经济学季刊》（The Quarterly Journal of Economics）《工作中的生成式 AI》（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 智能体：

身份与行动范围：

• AI 智能体的用户界面会向用户清晰提示该工具由 AI 驱动，并且每当用户与 AI 智能体交互时（例如在 Slack 或 Microsoft Teams 中），说明其旨在支持特定范围的行动。

• 提供给用户的事实说明（factsheets）还明确了：

• 智能体能做什么（例如根据职位要求审查候选人、总结人才画像、向面试官和面试者发送提醒、收集面试后反馈）

• 它不能做什么（例如做出与招聘、晋升或继任相关的决定、发起对员工记录的更改），强调用户和 HR 仍掌握控制权。

推理：当智能体在敏感工作流中提供建议时——例如招聘智能体支持某职位的候选人筛选，或为某员工建议发展行动——每条建议都会附上其推理说明，包括所考虑的数据、影响该建议的关键因素，以及任何已注意到的不确定性或风险。

通过使智能体的推理过程可见，用户获得了以负责任方式审查和使用结果所需的关键信息。这些透明度措施旨在帮助用户理解应如何与智能体互动。此外，它们还旨在凸显需要人类判断的环节，以确保人类决策，防止高风险决策被自动化。

蚂蚁国际（Ant International）：赋能终端用户稳健地设计自己的智能体工作流

蚂蚁国际的主要业务遍及亚洲、欧洲、中东和拉丁美洲，是全球领先的数字支付、数字化和金融科技提供商。通过公私部门的协作，其统一的科技金融（techfin）平台支持各种规模的金融机构和商户，通过一系列前沿的数字支付和金融服务解决方案实现包容性增长。

在内部，蚂蚁国际利用第三方 LLM 部署 AI 智能体，用于数据质量保证和网络安全等用例。为确保人类能够掌控智能体工作流，公司一直在试用一个用于智能体 AI 设计与开发的新框架，即高阶程序框架（High-Order Program，HOP）。HOP 框架被嵌入一个智能体构建器（agent builder）中，并提供这样一个流程：用户可以用通俗语言描述其智能体目标，并在智能体构建器将其转换为代码之前确认该智能体工作流。

1. 终端用户可以自行阅读和编写智能体工作流规格：HopSpec 是一份规格文档，逐步列出智能体应做什么及其约束（即 SOP），以易于理解的文本（Markdown）编写。特定智能体工作流的需求可以由终端用户（包括领域专家、合规官和产品经理）起草和审查。

2. 终端用户可以与智能体构建器反复迭代，明确何为良好的智能体工作流：当某项任务不够成熟或没有明确定义的 SOP 时，可能难以定义规格。HOP 会与用户就该任务如何完成进行迭代，探索潜在的解决路径，并为其提议的工作流提供置信度分数供用户评估。

3. 智能体工作流自带内建验证：为防范级联错误，所有智能体工作流都带有可定制和内建的验证步骤，例如从输出反向重构原始任务、通过另行调用其他 LLM 交叉核对回应，以及检查回应是否符合预期格式。如果任何验证失败，用户将收到智能体重试的通知，且在特定次数的失败尝试后，该智能体工作流将终止。

例如，在开发一个用于检测反向 shell 攻击（受害者机器绕过防御、通过恶意代码向外连接攻击者）的智能体工作流时，用户可能没有任何明确定义的 SOP，因为恶意代码可能以各种形式存在，并与正常的出站连接相似。

在这种情况下，用户可以从这样一个查询开始：「是否存在任何看起来像反向 shell 攻击的可疑出站连接？」智能体构建器随后可以制定一个 SOP，系统性地检查文件名、文件路径和目标 IP 等属性来进行评估。在与用户迭代并经用户确认后，该工作流将被自动转换为可重复执行和验证的代码。 PRIMARY_SOURCE: https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf