AI Agent部署后的参与式治理：Resourced Authority机制解析

如果你把一个具有工具调用、长期记忆和自主规划的 AI Agent 部署到了生产环境，它每天自动处理工单、审批请求、回复客户，甚至能调用外部服务完成交易。那么问题就来了：当它的某个行为偏离预期时，谁有权立刻停下它？如果不同团队对这个 Agent 的权限和工作边界有不同要求，又该按什么规则来协调？站在 2025 年往回看，AI 模型本身的生成能力已经不是唯一瓶颈，真正卡住落地的，往往是“部署之后谁来管、怎么管、靠什么管”。围绕这个问题，一个值得关注的思路是Resourced Authority——一个面向已部署 AI Agent 的参与式治理机制设计模型。它不是简单教你怎么给 Agent 配一个管理员账号，也不是劝你多做几轮测试，而是试图从更底层的机制角度，回答一个更难的问题：一个持续运行的 Agent，它的权力从哪里来、如何被分配、又如何被安全地收回。

1. 部署后的 AI Agent，为什么比开发阶段更缺人管

1.1 从“模型发布”到“Agent 常年在线”的变化

过去我们做一个 NLP 模型，流程通常是训练、评估、上线接口，然后通过监控指标观察调用情况。模型的输入输出相对可控，最坏情况是某个回答不准确，影响范围一般限定在一次对话里。但现在很多团队做的不再是“模型”，而是“Agent”：它会根据用户目标自己拆解任务，调用多个工具，写代码、查数据库、发邮件，甚至操作第三方系统。这个转变非常关键——Agent 不再只是回答问题，而是采取行动。

一旦 Agent 进入生产环境，它的生命周期就不是“发布那一刻”能定义的。它会持续接收环境反馈，长短期记忆可能不断更新，行为也会随上下文的积累而变化。你很难在开发阶段穷举所有真实场景。比如一个客服 Agent，开发时测试了退货、物流、发票常见流程，但上线后用户用非常规方式提出“帮我把地址改成酒店前台代收”，Agent 可能就把收件人信息改了。这个动作本身没有触发规则，但从治理角度看，就是一次越权操作。

所以部署后的 Agent 需要一种“在线治理”机制，而不是仅有发布前的测试和审批。它会面对真实世界不可预测的输入，而且它的行动会产生实际影响。这时候最稀缺的不是更多的模型调优，而是一套能持续判断“Agent 正在做什么、该不该做、由谁决定”的治理规则。

1.2 为什么权限列表解决不了动态授权问题

传统软件系统的权限管理，核心是静态的访问控制：用户 A 有文件 X 的读权限，用户 B 有数据库 Y 的写权限，管理员可以临时放开和收回。这套模型对普通应用是有效的，但对 AI Agent 来说存在几个不匹配的地方。

第一，Agent 不是一个固定用户，它更像一个“按目标执行的行动者”。它在一个任务里可能会尝试很多次工具调用，每次调用的上下文、目标、风险都不同。你不可能在事前把所有操作路径的权限都写死。第二，Agent 的自主性意味着，它会基于推理去尝试一些设计者没有明确授权的操作。如果不给任何空间，它就没有价值；如果给太多空间，它就可能越界。这个“动态授权边界”很难用静态 ACL 表达。第三，Agent 的行为链条可能很长，某一次单独调用看起来无害，但组合起来可能造成风险。比如先读取客户列表，再调用短信服务，再修改发送模板，单看每步都正常，合起来就是一次隐私事故。

因此，治理不能只停留在“谁能访问什么资源”这一层，而要回答：在什么条件下，Agent 可以被授予多大的行动能力；当条件变化时，谁有权调整或收回这个能力；以及整个过程中如何让利益相关方知情并参与。Resourced Authority 模型试图解决的，正是这个“动态权威”问题。

2. Resourced Authority：把“权力”翻译成“资源”

2.1 权威不是名分，是资源控制权

先拆解这个英文标题。Resourced Authority，直译是“有资源的权威”或“资源化的权威”。它暗示了一个很重要的判断：权威不能停留在名义层面，必须由具体资源来支撑。如果一个治理主体说“我有权监督这个 Agent”，但连日志都读不到，那这个权威就是空的。如果某个参与者说“我不同意这个 Agent 的行为”，但没有任何手段阻止它的下一步行动，那这句话也只是建议。

在实际工程里，可以用来支撑权威的资源包括：

• 模型调用配额：决定 Agent 还能执行多少次推理。
• 工具访问令牌：控制 Agent 能调用哪些外部服务。
• 数据库读写权限：限制 Agent 对业务数据的接触范围。
• 日志和审计数据读取权限：让治理者能看到 Agent 的实际行为。
• Agent 上下文和记忆的修改/清除权：在必要时纠正或重置 Agent 的认知。
• 计算资源上限：通过资源限制控制 Agent 的执行规模和频率。
• 预算配额：限制 Agent 使用付费 API 或产生费用的总量。
• 紧急停止能力：包括冻结任务、吊销令牌、隔离沙箱、终止进程等。

一个治理角色如果拥有上述某几类资源的控制权，它就拥有了“资源化的权威”。反之，如果只是挂在组织架构图上说“某某委员会负责 AI 治理”，却没有对应资源抓手，那这套治理制度很容易流于形式。

2.2 参与式治理：不是投票，是机制设计

“Participatory Governance”听起来像“让所有人投票决定 Agent 该怎么做”。如果真这么理解，那就宽了。参与式治理的关键不是“人数多”，而是让受 Agent 影响的各方，拥有影响治理规则的正当渠道和资源能力。

一个已部署的 Agent 通常有这些利益相关方：

• 开发者：关注模型效果和迭代速度。
• 部署方/运营方：关注稳定性、成本和业务目标。
• 最终用户：直接受到 Agent 输出影响。
• 被 Agent 操作波及的群体：比如被批量通知、被数据处理的客户。
• 安全与合规角色：负责防止风险、满足合规要求。
• 审计与监督角色：需要独立验证 Agent 的行为。

这些角色对 Agent 的诉求并不一致。开发者可能希望 Agent 更自主，以处理复杂任务；安全角色希望更保守，减少误操作；用户可能希望 Agent 能替自己做更多事，同时又担心隐私。参与式治理要做的，不是强行达成一致，而是把不同诉求放进一套可协商、可调整的机制里。

这正好是机制设计模型的用武之地。机制设计是博弈论的一个分支，研究“给定一群理性参与者，如何设计游戏规则，使参与者在追求自身目标时，也能实现整体期望的结果”。放到 AI Agent 治理里，就是把权力分配、审批流程、评估指标、奖惩机制都写成规则，然后让各方在规则下博弈，最终既保障 Agent 的效用，又防止权力滥用和治理失灵。

2.3 模型带来的新思路：权威可分配、可审计、可回收

Resourced Authority 这个命名的另一个启发是：权威不是一个人独占的静态属性，而是一组可以被拆分、分配、审计和回收的资源权限包。

可以这样理解：Agent 本身是一个行动者，而不同治理者控制着它行动所需的不同“开关”。某个角色的权限可以细化为：

• 在“紧急停止”场景下，是否有权吊销 Agent 的 API 凭证。
• 在“预算超支”条件下，是否有权调整 Agent 的单日调用上限。
• 在“行为异常”报告中，是否有权要求 Agent 进入只读模式。
• 在“用户投诉”升级时，是否有权清除 Agent 关于该用户的历史记忆。

这些授权都不是一次性的，而要有使用门槛、有效期、记录和回收机制。换句话说，治理者“暂时拥有某类资源控制权”并不代表永久拥有；一旦风险下降或角色变更，权威也应该被自动或手动回收。这种“可分配、可审计、可回收”的权力模型，比“管理员——普通用户”的二元结构更适合 Agent 的动态场景。

3. 从模型到落地：搭一个最小可行的参与式治理流程

理论模型要落地，不能只停留在概念。结合现有工程实践，我建议用下面这个“最小可行参与式治理”五步法来把它变成可运行的机制。这套方法不要求一开始就做到完美，但至少要让每个参与方都知道“自己手上有什么资源、能做什么事、行为会被怎样记录”。

3.1 第一步：划定 Agent 的行动边界和风险等级

先不要急着分配权力。第一件事是画一张 Agent 的“行动地图”，把 Agent 能做的所有操作列出来，并给每个操作做风险分级。

风险分级可以用一个简单的三维度判断：

• 影响范围：只影响当前会话，还是影响多个用户、多个系统。
• 不可逆程度：错误操作能否被回滚，还是会造成永久修改。
• 敏感程度：是否涉及个人隐私、资金、法律承诺或公开内容。

基于这三个维度，可以把操作分成三档：

• 低风险：读取公开信息、生成草稿、检索内部知识库。
• 中风险：修改非敏感字段、发送普通通知、调用第三方 API。
• 高风险：删除数据、修改权限、发起支付、对外发布内容、批量处理个人信息。

这个分级表是后续授权和审批流程的基础。没有分级，所有操作都走同一套审批，Agent 的自主价值会被拖垮；不分级就放权，又等于裸奔。

3.2 第二步：明确参与者及其资源包

接下来要列出参与治理的角色，并为每个角色分配具体的“资源包”。资源包不等于业务权限，而是治理权威的抓手。

下面是一个典型示例：

这个表格不是固定的，而是要根据实际组织架构和风险等级调整。但思路是一致的：每个参与者都必须至少握有一种具体资源，否则他们就不具备真正的治理能力。

3.3 第三步：设计决策和审批流

有了角色和资源包，下一步是定义 Agent 的决策和审批流程。一个好的机制设计不是让每一步都经过人工确认，而是根据风险等级选择不同强度的控制。

一个常见的设计是：

• 低风险操作：Agent 自动执行，事后记录日志。
• 中风险操作：Agent 执行前通知业务负责人，如无否决则自动放行，但保留完整上下文。
• 高风险操作：必须由至少一个具备相应资源包的人显式审批，Agent 才能执行。
• 紧急情况：安全角色有权一键冻结 Agent，冻结操作优先于其他所有流程。

下面是一个简化版的治理策略配置示例，用 JSON 示意：

{ "agent_id": "customer-support-01", "risk_tier": { "low": "auto_execute", "medium": "notify_before_execute", "high": "require_human_approval" }, "authority_bindings": { "engineer": ["config_update", "tool_registration"], "security": ["kill_switch", "token_revoke", "read_audit_log"], "business_owner": ["approve_medium_risk", "approve_high_risk"] }, "audit_policy": { "log_all_actions": true, "retention_days": 180, "alert_on_high_risk": true } }

这里不是生产级配置，但它展示了如何把“资源化权威”落到具体策略中：由谁控制哪些资源、不同风险等级走什么流程、所有行为如何被记录。

3.4 第四步：建设评估与审计闭环

参与式治理和普通的“审批流”最大的区别，在于它需要持续评估 Agent 的行为是否符合各方预期。也就是最近经常被讨论的 “demystifying evals for AI agents”——把 Agent 评估这件事从“发布前的测试”变成“运行时的治理信号”。

没有评估，参与治理的人就没有事实依据。当安全团队说“Agent 行为有风险”时，必须有一套可验证的评估证据；当业务团队说“Agent 效率提升”时，也要有可量化的指标。这套评估体系要覆盖几个层面：

• 任务成功率：Agent 完成目标任务的比例。
• 越权率：Agent 尝试访问未授权资源或执行越权操作的次数。
• 审批通过率：中高风险操作被人工批准的比例，以及人工驳回后的修正行为。
• 用户投诉率：与 Agent 交互后发起投诉或负面反馈的比率。
• 安全事件数：需要紧急停止或回滚的事件数量。

评估结果要反过来影响资源包配置。如果某个 Agent 的越权率持续偏高，安全团队就应该获得更多控制权，甚至可以自动触发“进入只读模式”的规则。如果审批通过率极高且没有异常，就可以考虑扩大中风险操作的自动放行范围。这样，评估和治理就形成闭环，而不是相互独立。

3.5 第五步：定期重新校准资源和权威

最后一个步骤容易被忽略：治理规则本身必须定期被重新审视。Agent 的能力在提升，业务范围在扩展，人员角色也在流动。如果一个 Agent 上线初期被严格限制，三个月后业务需求已经变了，但治理策略还停留在初期，效率就会严重下降；反过来，如果风险环境变化了，治理策略却没有收紧，又可能酿成事故。

建议以月为单位做一次治理复盘，内容包括：

• 审批记录中有没有反复出现同一类异常。
• 风险评估是否需要调整。
• 各参与者是否真的使用了分配到的资源包。
• 是否有参与者长期闲置，可以先回收权威。
• 新功能上线后，行动地图是否已经更新。

这个过程要沉淀成文档和自动化检查项，不能只靠会议纪要。治理机制本身也要有版本管理，每次变更都要有记录、有原因、有回滚方案。

4. 参与式治理最容易被忽略的四个工程点

4.1 评估不能只在发布前做，要成为在线治理信号

很多团队做 Agent 评估还停留在“上线前跑一批测试集”的思维。但 Agent 的问题是，任何测试集都覆盖不了真实世界的长尾场景。更重要的不是“上线前表现如何”，而是“运行中是否在持续偏离预期”。

我见过一个比较典型的案例：一个 Agent 被配置为自动回复客户邮件，上线初期表现很好，但一个月后因为一个上游数据格式变化，开始自动生成大量乱码邮件。离线评估根本没有发现，因为测试集没有包含新格式。如果治理机制里有在线评估信号，比如“生成内容可读性分数”“用户投诉率”“重试次数”，就能在事故扩大前触发熔断。

所以，不要把评估当成静态门槛，要把它当作治理系统的实时传感器。每个中高风险操作都应该有对应的评估指标，一旦指标达到阈值，就自动触发权限回收或人工介入。

4.2 日志与可观测性：权威的“事实底座”

资源化权威能够成立的前提，是每个参与者都能看到真实的行为记录。如果日志不完整，或者治理者的审计访问被绕过，那么“参与式治理”就会变成“黑箱治理”。

这就要求 Agent 的每次工具调用、每次上下文变更、每次外部请求，都有结构化日志。不只是记录“调用了某 API”，最好还要记录：

• 调用前后的完整状态。
• Agent 给出的推理摘要。
• 输入数据来源和敏感度。
• 执行结果和异常情况。
• 使用了哪个身份凭证、对应哪个资源包。

可观测性不仅是事后排查，也是授权机制的一部分。当审计角色发现 Agent 的某个行为违反了既定策略，他们需要有足够信息来确定是模型问题、数据问题、配置问题还是权限问题。否则，即使有“停止”按钮，也无法准确判断该停止什么、如何避免复发。

4.3 撤销权必须比授权权更重

在治理机制里，“授权”往往是被反复设计的，而“撤销权”却经常被忽略。实际上，撤销权比授权权更重要，也更容易被工程化。

给 Agent 授权可能只需要在配置中心加一条权限记录。但撤销，尤其是紧急撤销，要求能够在几秒钟内生效。你需要提前准备：

• 全局紧急停止开关：可以暂停该 Agent 的所有外部动作。
• 凭证吊销机制：立刻让 API 令牌失效。
• 资源配额为零化：将 Agent 的预算和调用额度归零。
• 只读模式：允许 Agent 继续接收输入，但禁止所有写操作。
• 沙箱隔离：如果 Agent 运行在动态沙箱中，可以立刻隔离并保留现场。

更重要的是，撤销权不能被单一利益方垄断，也不能被普通审批流程拖慢。通常建议由安全角色或独立治理角色持有紧急撤销权，并且每一次紧急撤销都需要事后审计。没有人希望天天按紧急开关，但真正出事时，一个可用的撤销按钮比什么都重要。

4.4 治理机制本身也要有熔断机制

最后一点，容易被忽略的是：治理机制自己也会出错。审批流可能存在单点故障；某个治理角色可能长期不响应；自动审批规则可能被绕过；审计日志也可能因为存储故障而缺失。所以，参与式治理需要设计“对治理机制本身的熔断”。

例如，当某个高风险审批超过 10 分钟未处理，系统应该自动升级到更高层级；当审计日志写入连续失败时，Agent 应停止执行高风险操作；当紧急停止开关本身不存在时，不得上线任何高风险 Agent。这些规则听着繁琐，但都是治理的“兜底”。

一个简单的检查表可以是：

• 是否有明确的升级路径。
• 是否在关键流程里有超时熔断。
• 是否对治理者本身也有权限分离和审计。
• 是否能在治理系统故障时，以“默认保守”的方式降级。

5. 适用边界与我的判断

5.1 这个模型真正适合哪些场景

Resourced Authority 这类机制设计模型，最适用的场景往往具备这几个特征：Agent 拥有真实行动权，影响范围不限于单次对话；有多类利益相关方，而且他们的诉求存在差异；系统需要长期运行，不能靠一次性发布测试兜底；风险容忍度比较低，一旦出错可能造成资金、隐私或声誉损失。

典型的例子包括银行客服 Agent、企业智能助手、自动化运维 Agent、内容审核 Agent。这些场景里，Agent 不只是输出文字，还会修改数据、触发流程、影响真实业务。这类 Agent 上线后，如果没有参与式治理，最后一定会变成“出事了要找谁”的危机响应模式。

5.2 哪些场景不要套用它

但不建议一上来就对所有 AI 功能都套用这套治理模型。如果只是一个本地运行的代码生成工具，或者一个单用户个人助理，参与式治理带来的额外成本会远大于收益。你不需要为写摘要的 Agent 设计一个多方会签流程。任何治理机制都有成本：审批耗时、资源包管理、评估、审计、角色协调。给小规模、低风险场景套上重治理机制，只会让团队疲于应付流程，反而阻碍迭代。

另外，如果 Agent 本身没有行动能力，只是一个问答接口，那么传统的内容审核和权限控制就足够，不需要上升到“参与式治理”层面。行动能力越强，治理机制才越必要。

5.3 现有实践与模型之间还差几块拼图

从这篇标题所代表的机制设计模型，到真正能在工程里普遍落地，我认为还差几块拼图。

第一，激励量化。机制设计需要参与者的效用函数，但现实中的利益相关方很难被简约量化。安全团队和业务团队之间的博弈，不只是“成本 vs 安全”，还有职业风险、KPI 和个人判断。把一个模型变成可计算的机制，需要大量辅助指标和制度设计。

第二，标准缺失。目前 Agent 治理没有统一的标准。权限、日志、评估、撤销这些能力，每个平台都有自己的实现。参与式治理要让不同团队、不同工具链协作，就需要共同的标准接口，比如统一的 Agent 行为日志格式、工具调用审计协议、治理策略 API。

第三，参与成本。普通用户或受影响群体，很难有精力持续参与 Agent 治理。一个客服 Agent 的用户可能只想快速解决自己的问题，并不想参加机制设计。所以参与式治理未必是“每个人都参与”，而是“受影响的人有知情权和申诉渠道，且关键决策由有代表性的角色参与”。

5.4 我建议的切入路线

如果你正在负责一个需要长期运行、有实际业务影响的 Agent，不必急着搭建一个包含所有利益相关方的完整治理委员会。我建议从最小闭环开始。

第一，先补齐最基础的三样东西：结构化日志、紧急停止、风险分级。没有这三样，任何治理机制都是空谈。

第二，加一层审批流：中高风险操作需要人工审批，并用策略配置管理。

第三，引入“资源化权威”的概念，把审批权、日志读取权、紧急停止权、配置修改权分别分配给不同角色，而不是集中在一个管理员手里。

第四，建立在线评估指标，让治理者基于数据做判断，而不是凭感觉。

最后，再逐步增加参与方、申诉机制、定期复盘。你会发现，当治理机制被资源化、模块化之后，它就不再是流程负担，而是一套能随着 Agent 能力一起进化的基础设施。对一个已部署的 AI Agent 而言，有资源支撑的参与式治理，不是可选项，而是它能长期被信任的前提。