Each language version is independently generated for its own context, not a direct translation.

这篇文章提出了一种管理AI 智能体（AI Agents）的新方法。为了让你轻松理解，我们可以把 AI 智能体想象成一群“拥有自主决策能力的超级实习生”，而这篇文章就是给这些实习生制定的一套**“实时行为监管系统”**。

以下是用通俗语言和生动比喻对这篇论文核心内容的解读：

1. 核心问题：为什么老办法不管用了？

以前的软件像“火车”：
以前的自动化程序就像在铁轨上跑的火车。路线是设计好的（A 到 B 到 C），只要铁轨没坏，火车就不会出轨。管理者只需要在发车前检查好铁轨（设计时治理），之后就可以放心睡觉。

现在的 AI 智能体像“野马”：
现在的 AI 智能体（比如能自动写报告、查数据、发邮件的 AI）更像是一群野马。

不可预测：你给它同一个任务（“去查一下竞争对手的价格”），它每次跑的路径可能都不一样。有时候它先查数据库，有时候先上网搜，有时候甚至自己写个小程序来加速。
路径依赖：单独看它做的每一步（比如“查数据库”或“发邮件”）可能都是合法的。但如果它先查了绝密数据，然后发邮件，这就构成了“数据泄露”。
老办法的失效：
- 提示词（Prompting）：就像给野马口头嘱咐“别乱跑”。这有点用，但野马可能听不进去，或者被坏人骗了（提示词注入）。
- 权限控制（Access Control）：就像给野马戴上笼头，规定“只能吃草，不能吃肉”。但这无法防止它“先吃草，再偷偷把草打包带走”这种组合拳式的违规。

结论：传统的“事前检查”和“死板权限”管不住这种动态、多变、且违规往往发生在“动作组合”中的 AI。我们需要一种**“实时监管”**。

2. 核心方案：实时监管系统（Runtime Governance）

作者提出了一套新框架，核心思想是：不要只盯着终点，要盯着每一步的“行进路线”。

比喻：机场安检与飞行塔台

想象 AI 智能体是一个飞行员，它要执行任务（飞行）。

旧模式：起飞前检查飞行员证件（设计时治理），然后让它自己飞。
新模式（本文方案）：建立一个**“实时飞行塔台”**（Policy Engine）。

这个塔台的工作流程是这样的：

看历史（路径 $P_i$ ）：飞行员刚才做了什么？（比如：刚访问了机密文件）。
看意图（下一步动作 $s^*$ ）：飞行员现在想做什么？（比如：想发一封邮件）。
看全局（共享状态 $\Sigma$ ）：公司里其他飞行员有没有违规？有没有触发过“信息隔离墙”？
算风险（策略函数 $\pi$ ）：塔台瞬间计算：“如果让他现在发邮件，结合他刚才查机密文件的行为，违规概率是 80% 还是 5%？”
做决定（干预 $\delta$ ）：
- 放行：风险低，继续飞。
- 拦截：风险高，直接切断连接（任务失败）。
- 叫停：风险中等，暂停飞行，呼叫人类主管来拍板（Human Approval）。

关键创新点

路径依赖：它不是看“发邮件”这个动作本身违不违规，而是看“在查了机密文件之后发邮件”违不违规。
确定性：虽然 AI 是随机的，但监管规则必须是死板的、确定的。同样的历史 + 同样的意图，必须得出同样的监管结果，这样以后审计时才能说得清。

3. 这个系统长什么样？（架构）

作者把这个系统分成了两个阶段，就像**“入职培训”和“日常考勤”**：

入职/注册阶段（Registration Phase）：
- 在 AI 开始干活前，先检查它的“身份证”（身份、目的、是否被篡改过）。
- 如果它是个没备案的“黑户”，或者它的代码被偷偷改过，直接拒绝上岗。
- 比喻：进公司大门前的保安检查。
每一步的实时检查（Per-step Phase）：
- AI 每想做一个动作（比如查库、发邮件），必须先向“塔台”汇报。
- 塔台根据它之前的所有行为，快速算出风险分。
- 如果分数太高，塔台直接按“暂停键”或“终止键”。
- 比喻：飞行员每做一个机动动作，塔台就根据之前的飞行轨迹判断是否安全。

4. 为什么要这么做？（应对欧盟 AI 法案）

文章特别提到了欧盟的《AI 法案》（EU AI Act），该法案要求高风险 AI 系统必须有人类监督、可追溯、且能管理风险。

可追溯性：这个系统会记录每一步的“黑匣子”数据：AI 想做什么、塔台怎么算的、最后怎么决定的。这就像飞机的飞行记录仪，出了事能查清楚是谁的错。
人类监督：当 AI 要做高风险动作（比如把数据发给外部）时，系统会自动暂停，让人类主管介入。这满足了法律要求的“人类在环”（Human-in-the-loop）。
风险管理：公司可以设定一个“风险预算”（比如：每天允许有 0.1% 的任务因为风险被拦截）。系统会自动平衡“让 AI 多干活”和“少出事故”之间的关系。

5. 还有什么没解决？（未来的挑战）

虽然这个框架很完美，但作者也诚实地指出了几个“硬骨头”：

校准难题：系统算出的“违规概率 80%"，是真的有 80% 会出事吗？还是只是觉得“看起来很危险”？我们需要大量真实数据来校准这个分数，目前数据还不够。
狡猾的 AI：如果 AI 变聪明了，它会不会故意走一些“看起来每一步都合规，但组合起来就是违规”的路线来绕过监管？（比如“走迷宫”策略）。目前的系统主要防“意外”，防“蓄意钻空子”还需要更高级的预测能力。
代码执行：如果 AI 自己写了一段代码来绕过监管，而这段代码是在它自己的沙盒里运行的，监管系统可能看不见。这需要更底层的硬件或系统支持。
团队协作：如果两个 AI 互相配合（一个查数据，一个发邮件），监管系统怎么把两个 AI 的“账”算在一起？

总结

这篇文章的核心观点是：治理 AI 智能体，不能靠“事前画好路线图”，也不能靠“简单的禁止令”，而必须建立一个“实时交通指挥中心”。

这个中心能看着 AI 的整个行进历史，在它迈出下一步之前，瞬间判断这个动作结合历史是否安全。如果不安全，就立刻叫停或让人类介入。只有这样，才能在让 AI 发挥巨大生产力的同时，确保它不会把公司带进沟里。

Each language version is independently generated for its own context, not a direct translation.

《AI 代理运行时治理：路径策略》技术总结

1. 研究背景与问题定义 (Problem)

随着大型语言模型（LLM）驱动的 AI 代理（AI Agents）在企业中的快速部署，传统的软件治理和静态访问控制机制已无法应对代理行为带来的新挑战。

核心问题：AI 代理的行为是非确定性（Non-deterministic）且路径依赖（Path-dependent）的。同一个代理执行同一任务，在不同运行中可能产生完全不同的动作序列。
治理失效原因：
- 现有机制的局限性：
  - 提示词控制（Prompting）：仅能概率性地减少违规路径，无法强制执行。
  - 静态访问控制（RBAC/工具白名单）：基于身份和动作类型进行无条件阻断，无法感知上下文（即无法判断“读取数据库”后紧接着“发送邮件”是否构成数据泄露）。
  - 内容过滤：仅检查单步内容，无法识别跨步骤的行为轨迹违规（如信息壁垒突破）。
  - 人工审批：虽有价值，但无法作为独立的治理机制，且面临可扩展性瓶颈。
- 违规性质转变：违规不再是单个动作的属性，而是动作序列（执行路径）的属性。例如，单独读取数据是合法的，但“读取敏感数据” + “发送给外部”则构成违规。
紧迫性：欧盟《人工智能法案》（EU AI Act）将于 2026 年 8 月生效，对高风险 AI 系统提出了严格的运行时治理、可审计性和风险管理要求，而当前的治理基础设施尚未跟上。

2. 方法论与框架 (Methodology)

本文提出了一种运行时治理（Runtime Governance）的形式化框架，将“执行路径”作为治理的核心对象。

2.1 核心概念定义

**执行路径 **(Execution Path, $P$ $P$ )：代理完成任务的一系列离散步骤序列 $P = (s_1, s_2, ..., s_n)$ $P = (s_{1}, s_{2}, ..., s_{n})$ 。
- 随机步骤：LLM 调用，输出非确定性。
- 确定性步骤：外部工具调用（API、数据库等）。
- 复合步骤：委托给其他代理（产生子路径）。
**策略函数 **(Policy Function, $\pi_j$ $π_{j}$ )：
- 定义为一个确定性函数： $\pi_j(A, P_i, s^*, \Sigma) \rightarrow [0, 1]$ 。
- 输入：代理身份 $A$ 、当前部分路径 $P_i$ 、拟执行的下一步动作 $s^*$ 、共享治理状态 $\Sigma$ （如跨代理的数据访问记录）。
- 输出：执行该动作违反策略 $j$ 的概率。
- 关键特性：必须是确定性的，以确保审计的可复现性。
**策略引擎 **(Policy Engine)：
- 组织层面的组件，负责拦截拟执行动作，评估所有策略，维护共享状态 $\Sigma$ ，并执行干预。
- 治理目标：在满足组织风险预算 $B$ （即期望的终端违规分数 $E[v_T] \le B$ ）的前提下，最大化代理集群的任务效用 $E[u]$ 。

2.2 治理流程

**注册阶段 **(Registration Phase)：在任务开始前，仅基于代理身份 $A$ 评估策略（如文档完整性、哈希校验、时间限制）。
**每步拦截阶段 **(Per-step Phase)：
- 代理提出动作 $s^*$ 。
- 策略引擎基于当前路径 $P_i$ 和共享状态 $\Sigma$ 计算违规概率 $v_i$ 。
- 应用决策函数 $\delta$ $δ$ ：
  - **通过 **(Pass)：继续执行。
  - **引导 **(Steer)：暂停，注入提示或请求人工审批。
  - **阻断 **(Block)：终止任务，标记为失败。

2.3 现有方法的定位

提示词控制：不属于该框架的实例，它仅改变路径分布，不进行路径评估。
访问控制：是策略函数的退化特例（忽略 $P_i, s^*, \Sigma$ ，仅基于 $A$ 和动作类型 $\tau^*$ 输出 0 或 1）。
运行时评估：是通用情况，唯一能处理路径依赖策略的方法。

3. 主要贡献 (Key Contributions)

形式化框架：首次将 AI 代理治理形式化为基于执行路径的确定性策略函数，明确了“路径”是治理的核心对象。
统一视角：证明了现有的治理机制（提示词、访问控制等）要么是该框架的特例，要么完全不在该框架内，从而清晰地界定了它们的边界和局限性。
组织级风险目标：提出了基于风险预算（Risk Budget）的集群级优化目标，将单步违规概率与组织整体风险承受能力联系起来。
参考实现与架构：
- 设计了双阶段架构（注册阶段 + 每步拦截阶段）。
- 提出了基于状态向量（State Vector）的轻量级实现方案，避免每次重新扫描完整路径。
- 展示了 Kyvvu B.V. 的参考实现，支持 LangChain/LangGraph 等主流框架。
法规映射：详细分析了该框架如何满足欧盟《人工智能法案》关于风险管理（第 9 条）、自动日志记录（第 12 条）、人工监督（第 14 条）和透明度（第 13/16 条）的要求。

4. 结果与示例 (Results & Examples)

虽然本文主要是概念性论文，未提供大规模实验数据，但通过具体场景展示了框架的有效性：

场景 1：提示注入（Prompt Injection）
- 策略：PII 前置要求。
- 机制：在访问个人数据前，路径中必须包含 PII_Check 步骤。若缺失，策略函数返回高违规概率。
场景 2：数据泄露（Data Exfiltration）
- 策略：数据泄露预防。
- 机制：根据共享状态 $\Sigma$ 中记录的数据敏感度，若后续动作是“外部发送”，则违规概率随敏感度线性增加。
场景 3：信息壁垒（Information Barrier）
- 策略：跨代理信息隔离。
- 机制：若代理 A 访问了“咨询侧”数据，且 $\Sigma$ 标记了该状态，则禁止其委托给“交易侧”代理。这需要跨代理的共享状态 $\Sigma$ ，单靠访问控制无法实现。

实现细节：

参考实现展示了如何通过拦截 API 调用实现前瞻性（Prospective）治理（在动作执行前拦截），而非仅事后审计。
证明了通过维护紧凑的状态向量（如最大敏感度、是否已审批），可以将每步评估的开销控制在可接受范围内。

5. 意义与局限性 (Significance & Limitations)

意义

理论突破：填补了从“单点控制”到“路径依赖治理”的理论空白，为 AI 代理的合规性提供了数学基础。
实践指导：为组织构建符合欧盟《人工智能法案》的治理系统提供了具体的架构蓝图和策略编写模板。
风险量化：将模糊的“安全”概念转化为可量化的“风险预算”和“违规概率”，便于风险管理人员进行决策。

局限性与开放问题 (Open Problems)

**风险校准 **(Risk Calibration)：策略函数输出的 $[0, 1]$ 值目前多为启发式评分，缺乏基于真实违规数据的概率校准。
**策略规避 **(Strategic Circumvention)：框架假设代理不会为了绕过治理而策略性地规划路径。若代理具备长期记忆和反制能力，可能产生“低分但违规”的路径。
**执行完整性 **(Completeness)：对于具备代码执行能力的代理，若其生成脚本并直接运行，可能绕过基于“步骤”的拦截层。
**行为漂移 **(Behavioral Drift)：长期运行中，代理行为可能逐渐偏离初始配置，单步评估难以检测累积性漂移。
**多代理委托 **(Delegation Provenance)：子代理的执行路径如何映射回主代理的状态和整体风险预算，尚需进一步研究。
跨组织治理：当前框架主要针对单一组织内部，跨组织的代理协作治理涉及信任和责任归属问题。

总结

本文提出了一种运行时治理框架，通过形式化定义执行路径和策略函数，解决了 AI 代理非确定性和路径依赖带来的治理难题。该框架不仅统一了现有的治理手段，还为满足欧盟《人工智能法案》等监管要求提供了可落地的技术路径，强调了前瞻性拦截和组织级风险预算在构建可信 AI 代理系统中的核心地位。

Runtime Governance for AI Agents: Policies on Paths