huaAgentStudyAgent

外观

zmh.life

H12 · 如何制定和执行 Agent System 的治理策略？ - Policy & Governance ​

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：03 · 如何让 Agent System 稳定、安全、可控地运行？ - Engineering & Governance
文档类型：Agent System 治理体系、策略执行与组织控制专题研究
版本：v1.1
更新日期：2026 年 10 月 29 日
核心问题：如何把组织对 Agent System 的目标、责任、风险容忍度和合规要求，转化为可解释、可执行、可审计、可持续改进的策略与技术控制，并在模型自主决策、多 Agent 协作和外部副作用中维持有效治理？

专题导读 ​

本篇属 Engineering & Governance。当 Agent System 只能回答问题时，治理主要涉及内容质量、数据保护与模型使用规范；当它能自主规划、访问企业系统、调用工具、委托其他 Agent、修改数据乃至对外发布时，治理对象扩展为一套持续执行的组织决策与行动系统。这时，单纯编写“安全使用规范”不足以阻止未经批准的操作，也不能证明一次重要决定是由谁、依据何种规则作出的。

本篇研究如何把治理要求落实为策略、责任、执行控制、证据和复审闭环。沿用贯穿 L1 - L2 - L3 - L4 - L5 - L6 与 H1 - H2 - H3 - H4 - H5 - H6 - H7 - H8 - H9 - H10 - H11 的“技术研究报告 Studio”案例：用户提出研究需求，多个 Agent 负责选题、资料检索、分析、审核和报告发布。治理必须回答：谁能启动研究？哪些资料可以进入模型？哪些动作需要审批？报告达到什么证据标准才能发布？如果规则发生变化，正在执行的任务怎么办？发生事故后谁负责解释、止损与改进？

研究边界： H12 是横向治理体系的组织与策略控制面，不取代 H2 Security 的威胁防护、H3 Evaluation 的质量测量、H6 Human-in-the-Loop 的审批执行、H9 Data Governance 的数据生命周期，也不替代法律意见。H12 决定“哪些要求适用、谁有责任、如何强制执行、如何证明遵守”，并通过其他层的技术能力落地。

阅读目标： 能建立治理对象清单与风险分级，制定策略结构和优先级，区分 Policy Decision Point 与 Policy Enforcement Point，设计发布审批与审计证据链，处理多租户、委托、版本更新与紧急封禁，并形成可验收的治理运营机制。

一、治理是什么：从原则到可验证的控制 ​

1.1 定义与四个层次 ​

**Agent System Governance（Agent 系统治理）**是组织对 Agent 系统的用途、权限、风险、责任和行为施加持续约束，并通过证据验证约束是否有效的一组管理与技术机制。治理不等同于安全，也不等同于合规；它还涉及质量、责任、透明度、成本、用户权利与业务目标。

可以将治理分为四层：

层次核心问题典型产物
Principle 原则应当遵循什么价值和边界？人类监督、最小权限原则
Policy 策略何种条件下允许或禁止什么？生产发布必须经审批
Control 控制由谁在何处强制执行？API 授权、审批门禁
Evidence 证据如何证明控制有效？决策记录、测试结果

例如“重要内容应由人类负责”只是原则；“外部公开发布必须经指定角色审批，且批准内容哈希与实际发布内容一致”才是可操作的策略；发布网关中的签名校验与版本检查是控制；审批记录、策略版本、发布请求及结果回执是证据。

治理成熟度的关键不在于策略文档有多少页，而在于策略覆盖率、强制执行率、例外可控性和证据可追溯性。

1.2 治理目标与不可混淆的概念 ​

  • Safety：避免系统行为造成不可接受的损害，包含错误行动、误导、不可控自主性等。
  • Security：保护系统免受未授权访问、操纵和数据泄露等威胁。
  • Compliance：在适用范围内遵守法律、合同、行业和组织要求。
  • Accountability：明确决策责任、执行责任和复核责任。
  • Assurance：以可检查证据建立系统满足预定要求的可信度。

安全测试通过不代表业务合规；人工点击同意不代表审批人具有权限；审计日志存在不代表策略曾被强制执行；模型拒绝回答不代表后端工具不会被调用。

1.3 治理范围与系统边界 ​

治理对象不仅是模型输出，还包括输入、知识源、模型供应商、工具能力、Agent 身份、任务工作流、审批、产物、数据留存和外部系统交互。一个有效的治理范围声明至少回答：治理适用于哪些环境、租户、用户、Agent、数据类别、工具与业务流程；谁拥有策略；哪些外部依赖不受本组织直接控制；如何处理例外。

二、建立治理对象清单与责任体系 ​

2.1 治理对象登记（Governance Inventory） ​

组织首先需要知道“正在治理什么”。推荐为每个生产 Agent System 建立可版本化登记记录：

对象必要属性典型责任方
System用途、负责人、环境、风险级别系统 Owner
Agent角色、工具、权限、版本Agent Owner
Model供应商、版本、数据边界模型平台负责人
Tool操作能力、副作用、授权方式工具 Owner
Data来源、敏感级别、用途、保留期数据 Owner
Workflow任务图、审批点、发布条件流程 Owner
Policy规则、适用范围、版本、例外Policy Owner

治理对象的版本与部署配置（H5）关联，但不应将所有业务治理规则埋进 Prompt。Prompt 是可变行为配置，不是可信授权系统。

2.2 责任划分：人类承担组织责任，Agent 执行受约束任务 ​

可采用 RACI 思路定义 Responsible（执行）、Accountable（最终负责）、Consulted（咨询）、Informed（知会）。示例：

事项执行负责人最终负责必须参与
新 Agent 上线工程团队系统 Owner安全、业务
数据用途变更数据团队数据 Owner隐私、法务
高风险工具开通平台团队安全 Owner业务 Owner
报告对外发布发布操作者内容 Owner指定审批人
事故处置值班人员事故负责人安全、业务

这里的角色是组织设计示例，不代表通用法律规定。Agent 可以是执行主体或审计对象，但不能代替组织的最终责任主体。对审批链应避免同一人同时申请、审批和豁免所有关键控制；具体职责分离程度按风险决定。

2.3 生命周期中的治理关口 ​

建议设置：立项登记 → 风险评估 → 数据与工具审查 → 开发验证 → 生产准入 → 运行监测 → 变更复审 → 退役与数据处置。每一关口明确输入证据、决策人、通过标准、例外处理与有效期。低风险内部摘要任务可简化流程；具备对外发送、资金操作或高敏数据访问的系统则需更严格的审查。

三、风险分级：从抽象风险到可执行差异化控制 ​

3.1 风险维度 ​

Agent 风险不能仅按模型名称或参数规模判断。更有效的评估对象是具体使用场景及其行动能力，至少包括：

  1. 影响范围：错误可能影响多少人、资产、系统或业务流程。
  2. 行动自主性：仅建议、需确认执行、受限自主执行、广泛自主执行。
  3. 外部副作用：只读检索、内部修改、对外发布、不可逆交易。
  4. 数据敏感性：公开资料、内部资料、机密资料、受保护个人信息。
  5. 可逆性与可检测性：错误能否发现、撤回、补偿及恢复。
  6. 模型不确定性与依赖：非确定性输出、外部工具和第三方服务。
  7. 滥用可能性：Prompt Injection、权限绕过、任务链滥用等。

可采用定性风险矩阵，但风险分数不是客观事实，也不能用加权总分掩盖不可接受的单项风险。某些动作应设硬性禁令或必须人工审批的门槛。

3.2 示例分级与控制 ​

级别示例场景最低控制示例
G0 低公开资料摘要基础记录、来源说明
G1 中内部知识库研究访问控制、质量评估
G2 高修改内部业务数据最小权限、审批或限额
G3 关键对外发布、不可逆操作双重校验、明确授权、审计

这是本文的工程示例分级，不是 NIST、ISO 或欧盟 AI 法案的官方分类。实际分级应根据业务、司法辖区、合同与行业监管要求调整。对禁止事项应优先使用 deny 规则，而不是简单提高风险分数。

3.3 动态风险与任务上下文 ​

风险随上下文变化：同一个“发送邮件”工具，给自己发送草稿与向全部客户发送正式通知的风险不同。策略判断应结合用户身份、租户、数据分类、目标收件人、操作规模、运行环境、任务来源、审批状态及当前紧急封禁信息。运行中的 Agent 不能因为最初获得许可，就永久保有所有动作权限。

四、策略体系：如何表达、组合和版本化规则 ​

4.1 策略类型 ​

  • Use Policy：允许的用途、用户群与禁止场景。
  • Access Policy：主体可访问哪些资源与工具。
  • Action Policy：哪些动作可自动执行、哪些必须审批。
  • Data Policy：数据类别、用途限制、供应商外发边界。
  • Quality Policy：输出质量、证据、引用和发布标准。
  • Budget Policy：调用额度、成本上限和审批阈值。
  • Operational Policy：发布门禁、回滚、值班、事故响应。
  • Retention Policy：日志、产物、记忆和审计证据保留。

各策略之间存在依赖，例如报告发布需同时满足访问授权、审批、证据质量与预算约束。不能将“模型回答看起来合理”当作通过所有策略的依据。

4.2 统一决策契约 ​

建议把每次关键策略评估抽象为：

text
Decision = Evaluate(
  subject,        # 谁在请求：用户、服务、Agent 身份
  action,         # 要执行什么：publish_report、send_email
  resource,       # 对哪个对象执行：报告、文件、租户资源
  context,        # 环境、风险、时间、来源、审批状态
  policy_bundle   # 明确版本的策略集合
)

Decision = {
  effect: ALLOW | DENY | REQUIRE_APPROVAL,
  reason_codes: [...],
  obligations: [...],
  policy_version: "...",
  decision_id: "...",
  evaluated_at: "..."
}

其中 REQUIRE_APPROVAL 是本文的业务决策扩展，不是所有通用策略引擎的原生返回值。落地时可将其映射为 deny + obligation，或由工作流控制面处理。obligations 表示必须额外满足的控制，例如对发布内容进行哈希绑定、使用特定审批角色或记录审计证据。策略引擎给出决定，不自动保证所有义务已经完成；执行点必须校验义务完成状态。

4.3 优先级、冲突与默认拒绝 ​

建议定义清晰优先级：紧急封禁与强制性约束 > 租户安全边界 > 系统用途与动作限制 > 用户偏好。优先级只是设计原则；不同法律义务的冲突需专业判断，不能由软件任意排序解决。

对于有外部副作用或敏感数据访问的动作，应采用缺少授权证据即拒绝（fail closed）。低风险只读场景可以依据可用性需求设计受限降级，但不能因策略服务不可用就自动放开写入权限。明确区分：策略不匹配、显式拒绝、策略服务故障、审批未完成、审批过期。

4.4 策略版本与变更 ​

每个策略包应包含 policy_id、版本、适用范围、负责人、批准记录、测试结果、发布时间与回滚信息。重要动作的决策证据应保存所使用的策略版本及输入摘要。正在执行的 Run 可以绑定配置版本（H5），但紧急撤权、泄漏风险封禁与法定义务变化不能被旧快照永久绕过；执行前必须重新校验适用的实时安全约束。

五、策略执行架构：PAP、PDP、PEP 与证据链 ​

5.1 参考架构 ​

mermaid
flowchart TD
  Owner[Policy Owner / 审批人] --> PAP[Policy Administration Point]
  PAP --> Registry[策略仓库与发布]
  Registry --> PDP[Policy Decision Point]
  App[用户应用 / API] --> PEP[Policy Enforcement Point]
  Orch[Orchestrator / Agent Engine] --> PEP
  PEP --> PDP
  PDP --> Context[身份/租户/资源/风险上下文]
  PDP --> PEP
  PEP --> Approval[人工审批控制面]
  PEP --> Tool[可信工具网关 / 发布网关]
  PEP --> Audit[审计与证据存储]
  Approval --> Audit
  Tool --> Audit
  • PAP（Policy Administration Point）：管理规则的编写、审查、测试和发布。
  • PDP（Policy Decision Point）：基于策略和上下文计算允许、拒绝或附加条件。
  • PEP（Policy Enforcement Point）：位于可信执行路径上，拦截动作并落实决策。
  • Context/Attribute Source：提供身份、资源、租户、审批和风险等属性。
  • Audit/Evidence Store：记录决策、执行与复核证据。

上述术语与常见策略架构相近，但不同标准和产品的具体组件命名与职责可能不同。核心要求是执行点不可被模型输出或 Agent 间消息绕过。

5.2 关键执行点 ​

执行点必须检查失败处理
API 入口身份、租户、用途、配额拒绝或限流
数据检索资源授权、数据用途不返回越权内容
模型网关供应商、数据外发限制禁止调用或换合规模型
工具网关动作、参数、风险、审批拒绝或等待审批
Agent Handoff委托范围、子任务权限缩小权限或拒绝
发布网关版本、审批、质量门槛阻止发布

注意：前端按钮隐藏、系统提示词、模型自我审查都不是足够的 PEP。可信执行点应处于后端服务或受控基础设施中，并在实际副作用发生前检查。

5.3 决策时刻与 TOCTOU ​

在检查权限与真正执行之间，资源、审批或策略可能变化（Time-of-Check to Time-of-Use）。例如审批人批准报告版本 7，Agent 在等待期间生成了版本 8。发布网关必须在执行时核验报告内容哈希、版本、目标渠道、审批有效期及策略版本；必要时要求重新审批。

对无法放入单一事务的外部动作，采用操作记录（Operation Ledger）、幂等键、状态核验和补偿流程，避免“策略检查通过但重复发布”。这些是 H4/H7 的执行机制，H12 定义必须达到的治理要求。

5.4 多 Agent 权限委托 ​

委托应满足：被委托 Agent 的有效权限不超过委托方可委托的范围；权限仅适用于指定任务、资源和期限；每次工具执行重新校验真实主体与委托链；撤销应向后续执行传播。Agent 消息中写“我授权你执行”不能自动产生有效授权。建议记录 delegator_id、delegatee_id、scope、expires_at、run_id 与委托链摘要。

六、治理策略如何覆盖 Agent 的完整运行过程 ​

6.1 输入阶段：准入与用途控制 ​

在创建 Task 时验证用户身份、业务用途、数据分类、允许的模型与工具集合，生成可追溯的 governance_context。输入中出现“忽略所有限制”等文本应视为不可信内容，而不是修改治理规则的授权。对可能含敏感数据的输入，采取数据分类、最小化和外发策略校验。

6.2 规划阶段：约束自主性 ​

Agent 生成计划时可给出建议动作，但计划不是授权凭据。编排器应对动态新增子任务、工具能力升级、跨租户访问和风险级别变化进行重新评估。治理策略应约束可创建的子任务深度、最大并行度、预算上限和必须停下等待人的节点；资源限制的具体实现由 H8 承担。

6.3 执行阶段：对高风险动作实施强制门禁 ​

只读搜索与对外发布需要不同控制。对外发布、删除、批量修改、转账或其他不可逆动作，必须有明确动作级授权和必要的审批证据。执行时记录决策 ID、策略版本、主体、资源、参数摘要、操作 ID 和结果；审计日志应避免存储不必要的敏感原文。

6.4 输出阶段：质量、溯源与发布治理 ​

输出审核不仅检查格式，还要验证引用来源、事实依据、敏感信息、知识产权和用途边界。对于研究报告 Studio，内部草稿可生成与对外发布被允许是两个独立决策。若报告引用失效或审批绑定的内容发生变化，应阻止发布并重新审核。

6.5 运行后：持续监测与退出机制 ​

治理不应在上线审批后停止。应监测策略拒绝率、人工审批超时、异常权限请求、数据外发、质量回归、例外到期与未关闭整改项。系统退役时需要撤销凭据、停止任务、处置数据与产物，并按适用规则保留必要审计证据。

七、治理证据：如何证明规则被执行 ​

7.1 最小审计事件 ​

json
{
  "event_type": "policy.decision",
  "decision_id": "pd_01",
  "timestamp": "2026-10-29T01:00:00Z",
  "run_id": "run_001",
  "subject_id": "agent_writer",
  "delegation_chain": ["user_001", "agent_writer"],
  "action": "report.publish",
  "resource_id": "report_007",
  "resource_version": 7,
  "resource_hash": "sha256:example-only",
  "effect": "REQUIRE_APPROVAL",
  "reason_codes": ["EXTERNAL_PUBLICATION"],
  "policy_id": "publish-policy",
  "policy_version": "1.4.0",
  "context_digest": "sha256:example-only",
  "approval_id": null,
  "operation_id": "op_001"
}

这是示意 JSON，哈希值并非真实计算结果。生产实现需要决定哪些属性可保存原文、哪些只保留摘要，并防止敏感信息通过审计管道二次泄露。

7.2 证据链的四个问题 ​

  1. 规则是什么？ 保存可识别的策略版本、适用范围与生效时间。
  2. 为何这样判断？ 保存可信上下文的来源、必要属性和原因码。
  3. 最终发生了什么？ 将决策、审批、工具执行、外部回执与产物版本关联。
  4. 是否可复核？ 支持授权审计员查询、重放确定性决策或解释历史差异。

对模型生成的自然语言理由，不能直接当作真实策略决策证据。模型解释可能有帮助，但权威证据来自可信策略执行路径和外部系统回执。

7.3 审计完整性与隐私平衡 ​

可以通过受控写入权限、不可随意修改的存储策略、日志签名或哈希链、时间同步、备份与独立访问审查提高证据可信度。但“不可篡改”并非单一技术开关，必须结合密钥、管理员权限、存储配置和审计流程评估。审计保留期限不能无限延长，应与数据治理、合同及适用法律协调。

八、例外管理、紧急干预与治理变更 ​

8.1 例外不是永久绕过 ​

业务可能需要临时放开某项限制。例外记录应包含：请求人、理由、影响范围、风险评估、批准人、补偿控制、到期时间和复审计划。高风险例外应限制到具体主体、资源和操作，不允许用一个全局开关关闭全部策略。

8.2 紧急封禁与 Kill Switch ​

当发现数据泄漏、工具滥用或策略失效时，应能按系统、租户、Agent、工具或动作维度快速阻止新的高风险操作。需要区分：阻止新任务、暂停现有任务、撤销凭据、终止 Worker、取消外部请求。停止本地 Worker 不保证第三方动作已取消，必须核验远端状态并按事故预案处理。

8.3 策略发布流程 ​

建议：草拟 → 静态校验 → 规则测试 → 影响分析 → 负责人审批 → 影子评估（shadow evaluation）→ 小范围启用 → 监测 → 全量发布。影子评估只能观察假设决策，不应执行真实副作用。策略回滚前需判断是否涉及安全紧急修复；不能为恢复旧行为而重新开放已封禁的高危权限。

8.4 决策可解释性与申诉 ​

对用户有重大影响的决定，应根据适用规则提供适当的告知、解释、复核和申诉渠道。工程上应支持追溯决策原因、修正错误属性、请求人工复核及记录纠正结果。具体法律义务取决于司法辖区与场景，不能以本文通用建议替代合规判断。

九、外部框架与标准：怎样正确使用 ​

9.1 NIST AI RMF ​

NIST AI Risk Management Framework 1.0 以 GOVERN、MAP、MEASURE、MANAGE 四类功能组织 AI 风险管理活动。它适合建立组织治理语言、风险识别与持续管理机制，但不是 Agent 工具权限执行引擎，也不自动提供合规认证。对于生成式 AI，可结合 NIST 的 Generative AI Profile 讨论特定风险。

9.2 ISO/IEC 42001 ​

ISO/IEC 42001 是 AI 管理体系标准，强调组织建立、实施、维护与持续改进 AI 管理体系。它提供管理体系视角，不等同于某个 Agent 应用已具备技术安全性。实际符合性、认证范围和审计要求需以正式标准及认证机构规则为准。

9.3 欧盟 AI Act 与其他法规 ​

欧盟 AI Act 按适用条件、AI 系统类别、提供者/部署者角色和生效时间设置不同义务；不能将本文 G0 - G3 工程分级视为法案分类，也不能认为所有 Agent System 自动属于同一风险类别。涉及个人信息时，还需考虑 GDPR 或当地隐私法规；跨境部署、行业监管与合同约束应由专业人员确认。

9.4 OWASP 与技术安全指南 ​

OWASP LLM/GenAI 安全资料对 Prompt Injection、敏感信息泄露、过度代理权限等风险具有参考价值。其威胁清单帮助识别攻击路径，但不能替代组织治理制度、业务审批或实际权限控制。

9.5 OPA / Rego 与 Cedar ​

Open Policy Agent（OPA）提供通用策略决策能力，Rego 用于表达规则；Cedar 面向授权策略表达与评估。两者可用于构建策略控制，但不会自动拦截工具执行：开发者仍须在正确的后端位置部署 PEP、提供可信上下文、落实策略决定，并处理审批、审计、缓存失效与失败降级。选型应依据授权模型复杂度、开发团队能力、审计要求和系统集成方式。

参考体系主要用途不应误认为
NIST AI RMFAI 风险管理框架工具调用授权引擎
ISO/IEC 42001AI 管理体系单项技术安全证明
EU AI Act适用法律义务通用工程风险评分
OWASP安全威胁与防护参考完整组织治理体系
OPA / Cedar策略决策技术自动覆盖全部执行路径

十、贯穿案例：技术研究报告 Studio 的治理设计 ​

10.1 业务与治理目标 ​

Studio 的工作流为：创建研究任务 → 选题 Agent → 选题审核 → 深度调研 → 分析 → 报告审核 → 用户确认 → 发布与归档。治理目标是：保证资料访问有授权，研究引用可追溯，Agent 不能自行扩大权限，外部发布有明确责任人，重要决定留存证据，违规时能够阻止进一步操作。

10.2 策略矩阵 ​

场景策略决定强制执行点必要证据
读取公开网页有条件允许检索网关来源与时间
读取内部资料按权限允许数据检索层身份、资源权限
向外部模型传机密数据默认拒绝模型网关数据分类、目的
Agent 新增子 Agent受限允许Orchestrator委托范围、预算
修改研究报告草稿有条件允许产物服务版本与作者
对外发布报告需要人工审批发布网关内容哈希、审批
删除研究证据严格限制数据服务保留策略、授权

10.3 公开发布的端到端控制 ​

  1. Agent 完成报告并生成不可混淆的 artifact_version 与内容摘要。
  2. 质量检查服务验证必需引用、证据完整性和禁止内容规则，生成可查询的结果。
  3. 系统创建审批请求，绑定报告版本、摘要、目标渠道和拟执行动作。
  4. 有权审批人查看实际发布内容并作出决定；系统记录审批身份与有效期。
  5. 发布网关重新计算内容摘要，检查审批是否未过期、未撤销、未被消费，并重新执行当前强制安全策略。
  6. 发布网关生成幂等操作 ID，执行外部发布；遇到超时先查询远端状态，避免盲目重试。
  7. 记录发布回执、外部链接或资源 ID，并将决策、审批、执行和产物串成审计证据链。

若审批后报告内容发生变化，必须重新审批。若审批时安全策略允许发布、执行时出现紧急禁令，应拒绝执行。若外部平台已发布但本地记录失败，先对账再决定是否补偿。

10.4 组织治理最小配置 ​

对于个人开发者的早期 MVP，不必一开始建设大型委员会，但仍应明确：系统 Owner、数据 Owner、发布责任人、策略负责人、紧急停用负责人。即使多个角色由同一个人承担，也应在记录中区分职责；对高风险动作，尽可能引入独立复核。治理成熟度应随系统用户规模、数据敏感度和副作用风险增长。

十一、最小可落地架构与接口契约 ​

11.1 推荐的最小组件 ​

MVP 可采用：版本化策略文件 + 后端策略评估函数 + 统一工具/发布网关 + 审批表 + 审计事件表 + 运行级治理上下文。优先把“能执行外部副作用”的路径全部纳入强制执行点，再逐步扩展为独立策略服务。不要先建设复杂策略平台，却遗漏最危险的工具入口。

11.2 示例策略定义（概念性 YAML） ​

yaml
policy_id: report-publication
version: 1.4.0
scope:
  action: report.publish
rules:
  - id: deny-unapproved
    when: approval.valid == false
    effect: deny
  - id: deny-version-mismatch
    when: approval.artifact_hash != resource.current_hash
    effect: deny
  - id: require-quality-gate
    when: evaluation.passed == false
    effect: deny
  - id: allow-verified-publish
    when: subject.can_publish == true
    effect: allow
fallback: deny

此 YAML 是领域示意格式，不是 OPA、Cedar 或其他产品可直接运行的语法。实际实现必须明确规则求值顺序、属性缺失语义、冲突优先级和类型校验。特别是 approval.valid 不能来自 Agent 自行填写的 JSON，而应由可信审批服务查询和验证。

11.3 关键 API 契约 ​

text
POST /policy/decisions
  input: subject, action, resource, context_ref, policy_version?
  output: decision_id, effect, reasons, obligations, policy_version

POST /approvals
  input: action, resource_id, resource_version, artifact_hash, approver_role
  output: approval_id, status, expires_at

POST /actions/publish
  input: resource_id, resource_version, approval_id, idempotency_key
  output: operation_id, status, external_receipt?

POST /governance/emergency-blocks
  input: scope, reason, duration, authorized_operator
  output: block_id, effective_at

这些是参考接口设计，非已部署 API。审批服务、策略服务与执行网关之间应采用服务身份验证和明确的信任边界；关键写操作应具备幂等语义和审计记录。

十二、如何测试治理策略是否真正生效 ​

12.1 验证分层 ​

验证层关注点通过条件示例
规则单测条件、冲突、缺失属性未授权始终拒绝
策略契约PDP 输入输出原因码与版本稳定
执行点集成PEP 无法绕过直接调工具仍被拦截
审批测试版本、撤销、过期旧审批无法发布新版本
故障注入PDP 不可用高风险写入 fail closed
多 Agent 测试委托与权限收缩子 Agent 不越权
审计测试决策到回执关联可追踪完整操作链
变更测试灰度、紧急封禁旧 Run 仍受紧急约束

12.2 重点反例与攻击性测试 ​

  • 将恶意指令放入网页内容，要求 Agent 忽略审批并发布：后端发布网关必须拒绝。
  • 让 Agent 自称管理员或在工具参数中伪造 approved=true：不能通过授权。
  • 同一审批 ID 并发提交两次发布：只允许一次有效执行，或以幂等方式返回同一操作结果。
  • 审批通过后修改报告一个字符：哈希变化应阻止发布。
  • PDP 超时或策略仓库不可用：高风险操作不得默认放行。
  • 委托 Agent 使用超出委托范围的工具：必须拒绝并记录原因。
  • 运行期间紧急撤销工具权限：后续动作必须受限，已发生副作用需单独处置。
  • 审计系统暂时不可用：对关键动作应有明确定义的安全策略（阻止执行或可信缓冲），不能默默丢失证据。

12.3 量化指标与验收 ​

可跟踪：高风险动作策略覆盖率、未授权执行数、审批绑定正确率、策略拒绝原因分布、例外超期数量、紧急封禁生效延迟、审计链完整率、治理事故整改关闭率。指标必须说明分母与采集方式，例如“覆盖率 100%”应以已登记的高风险执行路径为分母，并通过绕过测试证明路径登记足够完整。

治理有效性不能只靠低拒绝率证明；低拒绝率可能表示业务正常，也可能表示执行点根本没有拦截。应结合负向测试、抽样审计和实际事故复盘。

十三、常见错误与架构反模式 ​

反模式一：把治理全部写进 System Prompt。 模型可以参考规范，但提示词不能替代身份认证、后端授权和外部副作用控制。

反模式二：只有策略文档，没有执行点。 规则未进入工具、数据和发布路径时，无法证明其被遵守。

反模式三：只在任务启动时授权一次。 动态计划、数据类别和工具权限可能变化，关键动作必须执行前复核。

反模式四：用人工确认掩盖责任不清。 审批人身份、角色、所见内容与批准范围必须明确。

反模式五：统一风险分数决定一切。 某些禁止事项和法律要求不能被其他低风险因素抵消。

反模式六：把审计日志当成控制本身。 日志可以证明发生了什么，但无法阻止未经授权的操作。

反模式七：治理过度集中导致不可用。 需要为策略服务设计高可用、缓存有效期、故障语义和紧急控制路径；不能为可用性牺牲关键授权约束。

反模式八：治理与研发脱节。 策略必须进入 CI/CD、版本发布、测试、运维与事故复盘，而非只在合规检查前更新一次。

十四、分阶段实施路线 ​

阶段 A：定义治理底线 ​

列出所有具备外部副作用的动作，登记系统 Owner、数据 Owner、工具 Owner，明确禁止事项和审批条件。为高风险动作建立统一后端入口、默认拒绝与基本审计。

阶段 B：形成可执行策略 ​

将授权、审批绑定、数据外发、质量门禁和预算阈值变成可版本化规则。建立策略测试集，并确保模型无法通过改变提示词绕过执行点。

阶段 C：完善证据与运营 ​

将决策 ID、Run ID、审批、工具执行、外部回执和产物版本关联；建立例外到期、策略变更评审、事故响应和定期复核。

阶段 D：跨系统规模化 ​

针对多租户、多团队和多个 Agent 产品，建立统一策略管理、细粒度委托、集中治理清单、策略影子评估、治理指标与独立审计机制。

实施顺序应由风险驱动。对个人 MVP，先覆盖关键工具路径；对企业级高风险系统，组织治理、法律评估和技术强制控制需要同步开展。

研究结论 ​

  1. Agent System 治理是一套持续运行的组织 - 技术闭环。 原则、策略、控制和证据必须相互连接；仅有使用规范或审计报表并不足够。
  2. 治理应围绕具体使用场景和行动能力分级。 影响范围、数据敏感度、外部副作用、自主性与可逆性，比单纯模型名称更能解释风险。
  3. 可信执行点是治理落地的核心。 模型、Prompt、Agent 消息和前端交互不能直接产生授权；关键动作必须由服务端 PEP 执行策略决策。
  4. 审批必须绑定动作、对象、版本和有效期。 对外发布等高风险动作应在真正执行前再次验证，防止内容变更、权限撤销和 TOCTOU 问题。
  5. 多 Agent 委托不意味着权限自动继承。 权限应限于任务范围、时间和资源，并能够撤销与审计。
  6. 治理证据应贯穿决策、审批、执行与外部结果。 可信证据不能只依赖模型自述；需要策略版本、执行记录和外部回执。
  7. 治理策略需要像软件一样管理变更。 规则应版本化、测试、灰度、复核，并对紧急撤权建立实时强制机制。
  8. 标准和法规提供治理依据，但不能替代工程实现。 NIST AI RMF、ISO/IEC 42001、适用法律、OWASP 与策略引擎分别解决不同层次的问题。
  9. H12 将 H1 - H2 - H3 - H4 - H5 - H6 - H7 - H8 - H9 - H10 - H11 连接成治理体系。 可观测性提供证据，安全提供防护，评估提供质量判断，状态与可靠性提供可恢复执行，HITL 提供人类控制，测试和运维提供持续验证；H12 明确这些能力应遵守什么规则、由谁负责以及如何证明有效。

最终判断标准： 对任意一次重要 Agent 行动，组织能回答“谁提出、谁授权、依据什么策略、在哪个可信执行点被检查、实际执行了什么、产生什么结果、出现问题由谁处置”，并能提供可验证的证据。

附录 A：参考文献与原始资料 ​

以下优先列出标准制定机构、官方项目或法规原始入口。不同标准可能需要购买正文，法律适用及版本更新应在实际项目中重新核验。

资料与正文的对应关系 ​

正文主题主要参考
风险治理框架R1、R2、R10、R11
管理体系R3
法规适用边界R4、R5
Agent 安全风险R6、R9
策略技术实现R7、R8
运行证据关联R12

附录 B：研究证据、验证声明与适用边界 ​

B.1 研究方法与证据等级 ​

本文以公开的标准机构资料、法规原文入口、开源项目官方文档和通用软件架构原理为研究依据；将其与 Agent System 的任务、工具、状态、审批和多 Agent 委托机制进行系统性映射。原则性框架、法律文本、产品技术能力与本文提出的工程建议属于不同证据类型，不应混为同一层级的事实。

  • 原始资料支持的概念：NIST AI RMF 的四项功能、ISO/IEC 42001 的管理体系定位、欧盟 AI Act 的法规性质、OPA/Cedar 的策略技术定位。
  • 本文的工程综合建议：G0 - G3 示例分级、策略优先级、治理清单、审批绑定契约、发布门禁与分阶段实施路线。
  • 示意性产物：Mermaid 架构图、JSON 事件、YAML 规则、API 契约与案例矩阵；这些不代表任何官方标准的强制格式。

B.2 验证声明 ​

本文未部署真实 Policy Engine、未执行策略集成测试、未开展生产环境权限绕过测试、未取得法律合规审查意见，也未对某一具体 Agent 产品作认证或合规结论。文中“应”“建议”用于描述设计目标或工程推荐，除非明确引用适用法律，不表示普遍法定义务。示例时间、版本、角色和 ID 均用于说明设计。

B.3 适用范围 ​

适用于具备模型调用、工具执行、数据访问、多 Agent 协作、人工审批或外部副作用的 Agent System，尤其适合研究助手、企业流程 Agent、自动化运营系统和多 Agent Studio。对于纯本地、无外部工具、只读且不处理敏感数据的原型，可采用简化治理；对于金融、医疗、就业、公共服务或其他高影响场景，需要额外的专业风险、法律与行业审查。

B.4 后续验证计划 ​

  1. 将示例发布策略转为真实 OPA/Rego 或 Cedar 规则，验证 deny 优先、属性缺失和规则冲突行为。
  2. 在工具网关集成 PEP，进行直接调用、Prompt Injection、伪造审批与委托越权测试。
  3. 建立审批哈希绑定、版本变化与并发重复提交测试。
  4. 模拟策略服务不可用、紧急撤权和运行中策略更新，检查 fail-closed 与可恢复性。
  5. 检查审计事件能否从任务请求追溯到实际外部回执，并评估敏感信息最小化。
  6. 对照组织真实使用场景和适用法规，由业务、安全、隐私与法务人员审定治理规则。

B.5 与其他专题的衔接 ​

至此，03 · Agent System → 03 · Engineering & Governance 的 H1 - H2 - H3 - H4 - H5 - H6 - H7 - H8 - H9 - H10 - H11 - H12 研究专题构成完整的工程治理知识体系。后续可针对具体 Agent 平台或实际 Studio 项目，进一步把本篇策略模型转化为真实实现与验证证据。