AI Agent 一旦部署到业务环境真正难管的不是它能生成什么而是它被允许执行哪些动作。Resourced Authority 这个提法就是想用机制设计模型来解决部署后 AI Agent 的参与式治理问题。简单说它把“权威”从抽象承诺变成了具体资源Agent 能调用什么资源、资源由谁授权、参与者在什么条件下可以调整或叫停这些才是治理真正能落地的点。我建议先把 Resourced Authority 理解成一套治理框架而不是一个可以直接安装的工具。它适合正在做 Agent 应用、权限体系、AI 平台治理以及需要给 Agent 准备审计与合规方案的团队。如果只是跑一个 Demo默认提示词够用但如果要长期稳定运行就需要把授权、参与、审计和评估当成正式系统来设计。下面我按“为什么需要、机制是什么、怎么落地、怎么评估、踩过什么坑”这个顺序拆一遍。1. AI Agent 一旦部署治理就不再是“模型安全”问题1.1 从输出风险到执行风险传统大模型应用风险集中在输出内容有没有幻觉、有没有敏感表述、有没有事实错误。这类风险在很大程度上可以通过提示词、评测集和内容过滤去控制。AI Agent 不一样。Agent 不只是输出文本它还会调用工具、读取数据库、发消息、改配置、下单、退款、访问外部接口。也就是说它的风险从“说了什么”变成了“做了什么”。一个 Agent 可以做错事不一定是因为模型判断错了也可能是因为它拿到了不该拿的资源。比如一个客服 Agent 同时拥有查订单、改订单、触发退款的接口权限单个动作本身都合规但组合起来就可能出现越权操作。部署后的 Agent 治理重点应该放在“执行链路”上而不是只盯“生成质量”。1.2 为什么“资源”比“权限”更适合做治理抓手传统权限体系里核心概念是“角色”。给某个 Agent 绑定一个角色角色上有对应权限。这个思路适合静态系统但对 AI Agent 不够直观。Agent 的决策是概率性的同样的输入在不同时间可能走不同路径。角色权限很难表达“这件事可以做但只能做 50 次”“这个接口可以调但单日成本不能超过 80 元”“这批数据可以读但不能导出”。这些限制本质上都是资源约束。Resourced Authority 把治理抓手从“角色权限”换成了“资源授权”。Agent 每次动作要么消耗资源要么触碰资源要么申请新的资源。只要资源清单清楚、授权链路可见治理就有抓手。反过来说如果只讨论“Agent 应该遵守原则”讨论再多也很难落地。因为原则不可度量而资源可以度量。这是 Resourced Authority 最实用的地方。2. 先理解 Resourced Authority 到底在设计什么2.1 机制设计不是让所有人直接决策而是设计决策规则机制设计是博弈论的反向使用。常规博弈论是给定规则预测参与者会怎么选机制设计是先确定想要的结果再设计规则让参与者在追求自身利益的时候自然产生那个结果。用大白话说不要假设参与者都是好人也不要假设他们都是坏人。好的规则应该让好人不需要额外付出成本让坏人占不到便宜。放在 AI Agent 治理里参与者可能是产品负责人、安全工程师、最终用户、外部审计员。不同的人利益不完全一致。产品负责人希望 Agent 多干活安全负责人希望少出风险终端用户希望隐私被保护审计方希望过程可追溯。机制设计要解决的不是“谁更正确”而是“什么样的授权流程能让各方在表达自己诉求时整体结果仍然可控”。这就是激励相容的基本思路。2.2 参与式治理谁受影响谁就有表达通道参与式治理的核心是受影响的人不应该只是被动接受结果而应该有某种参与空间。在单机 Demo 里Agent 只影响开发者一个人不太需要参与式治理。但在企业生产系统里Agent 可能影响员工、客户、审核员、下游系统。在开源社区或公共服务里Agent 影响的范围更大。参与式治理不等于所有事情都要投票。我们可以把问题分成两类高频、低影响、边界清楚的动作交给预设规则处理。低频、高影响、存在价值冲突的动作需要参与者介入。比如“查天气”不需要参与式治理“退款超过某个金额”就需要审批“允许 Agent 访问某个新数据源”可能需要相关方共同确认。参与式治理的目的是让关键决策有合法性而不是让所有决策都变慢。2.3 这两个概念合在一起就是一套授权系统Resourced Authority 把机制设计和参与式治理放在一起本质上是在设计一套“资源授权系统”。核心逻辑可以概括成三句话Agent 的能力由它实际可以调用的资源决定。资源的分配、调整、撤销由特定参与者通过规则完成。所有参与者的行为要受机制约束使结果不依赖某个人的自觉。这不是权力概念的堆砌而是把治理问题转化成一组可检查的工程问题资源有没有登记授权有没有条件参与者有没有入口过程有没有日志结果有没有评估只要这四个问题能回答治理就不至于沦为空谈。3. Resourced Authority 的四个设计构件3.1 资源目录把 Agent 能碰到的都登记下来资源目录是整个框架的地基。没有资源目录后面所有授权、审计、参与都没有对象。资源不只有 API 接口。对于 AI Agent 来说资源至少包括模型调用额度按次、按 token 或按金额计算。工具调用权限搜索、代码执行、文件读写、邮件发送、消息推送。数据访问范围数据库表、数据仓库、对象存储、第三方平台数据。外部系统身份API Key、服务账号、OAuth Token、凭证。操作额度退款次数、删除数量、导出条数、批量任务大小。每一类资源都要有登记项资源 ID、资源类型、归属方、可用配额、授权对象、有效期、关联的 Agent。我一般建议先不要做太复杂的资源建模。先把 Agent 在测试环境里能碰到的所有外部系统列出来再逐步归类。资源清单不要求一开始漂亮要求完整。3.2 授权策略把动作和资源绑定有了资源目录授权策略就可以从“角色-权限”升级成“Agent-资源-动作-条件”。例如Agent 可以使用订单查询接口。Agent 可以发起退款但单笔金额不能超过 200 元。Agent 可以读取用户联系方式但不能导出。Agent 可以调用代码执行工具但只能访问沙箱目录。这样设计的好处是授权策略可以覆盖 Agent 的长尾行为。模型判断可能存在不确定性但资源约束是确定的。即使 Agent 计划了某个恶意或者越权动作只要资源层拦截它就执行不了。条件部分也很重要。建议至少包含时间窗口、调用频次、单次消耗上限、叠加消耗上限。不要只写“允许调用”。这里不需要一开始就引入很重的框架。先形成一份策略表策略表里写清楚“哪个 Agent、可以碰哪个资源、在什么条件下、不能碰什么”等规模变大后再考虑用策略引擎管理。3.3 参与协议给受影响的人留出入口参与式治理不能只喊口号要变成具体协议。协议至少回答三个问题谁能参与能参与哪些决策通过什么流程参与常见的参与角色包括资源所有者拥有某个资源决定是否授权。受影响方Agent 行为会影响到的人或系统。治理委员会负责审批高影响变更。审计员检查日志、抽样验证、提出整改。参与流程可以是多种形式资源授权申请需要负责人审批。提高 Agent 预算需要相关方确认。新工具接入需要安全评审。发生越权行为后受影响方可以发起复核。在设计参与协议时要避免两个极端一是所有动作都审批导致 Agent 失去效率价值二是完全没人审批所有权限都提前放开。把“默认拒绝”作为原则把“批准”作为例外是更稳妥的起点。3.4 可审计性让治理过程可以被复盘没有审计的治理不是治理更像信任投票。Agent 治理日志不能只记对话内容至少要记录哪个 Agent 发起了什么动作。动作调用了哪个资源。调用的参数和上下文是什么。授权条件是否被满足。这次调用消耗了多少配额。执行结果是成功、失败还是被拦截。如果涉及审批审批人、审批时间、审批依据是什么。日志的关键不是量大而是能串起来。从 Agent 意图到工具调用再到资源消耗和结果最好能形成一条完整链路。这样出了问题审计员才能快速定位是模型误判、授权过宽、参与流程失效还是资源配额设置不合理。4. 从零落地一条最小可跑的参与式治理链路4.1 第一步先做资源资产盘点不用先做宏大规划。选一个真实运行的 Agent先回答一个问题它到底能碰哪些东西我建议先跑一遍最小样例把 Agent 的所有外部调用打开日志执行几个典型任务然后看日志。你会发现 Agent 实际调用的接口可能比设计文档里多也可能比预期少。这一步的目的是拿到真实的资源清单。资源盘点完成之后给每个资源打上标签只读还是可写。是否涉及资金操作。是否涉及个人敏感信息。是否可以导出。是否会影响其他人的数据。标签不需要太细能支撑后续授权判断就可以。4.2 第二步配置授权策略和参与规则资源清单确定后进入策略配置。核心原则是默认拒绝显式放行。给 Agent 配置授权时要注意几点不要把整个 API 都放开先放开最小动作集合。给资源加上配额比如单日调用次数、成本上限。给高风险动作设置审批门槛。给授权设置有效期不要一次授权永久有效。参与规则也从最小开始。可以先设置两层常规动作条件满足时自动执行只记日志。高风险动作需要相关负责人审批或者达到阈值后自动熔断。等规则稳定之后再考虑引入委员会、代表投票、群众评审等更复杂的形式。4.3 第三步接入日志、审计和熔断日志要在第一版就接入不要等出问题再补。审计反馈越早期越便宜。最低要求是每个 Agent 动作都有 trace_id每次资源调用都能关联到 trace_id每条授权变更都有操作人和时间戳。熔断机制可以做成两层硬熔断成本超过日预算直接停止调用。软熔断某个接口连续报错或者检测到越权尝试自动降级到人工处理。这些机制不复杂但需要在 Agent 真正跑起来之前就装上。4.4 一个示例配置方便对照下面这个配置只是示例不是某个产品的标准格式。写出来的目的是帮你理解“资源化授权”长什么样。{ agent_id: support-bot-v2, resource_budget: { max_cost_per_day: 50, max_token_per_hour: 10000 }, allowed_tools: [ ticket.search, order.status.query, refund.initiate ], condition_rules: [ { resource: refund.initiate, allowed: true, single_amount_max: 200, daily_count_max: 20, need_approval_above: 100 }, { resource: user.mobile.export, allowed: false } ], participants: [ { role: resource_owner, scope: [ticket.search, order.status.query] }, { role: risk_approver, scope: [refund.initiate] } ], audit: { log_all_actions: true, trace_id_required: true, alert_channels: [governance-audit] } }这个示例想表达的是所有权限都以资源为边界而不是简单说“这个 Agent 是客服”。测试时可以拿这种配置跑一周再根据实际情况调整配额和审批阈值。5. 治理型评估怎么判断这套机制真的有效5.1 常规评测不够还要看授权链很多人讨论 Agent 的评估时习惯看回答质量准确率、召回率、流畅度、指令遵循。这些能力评测很重要但放在部署后的治理场景里还不够。治理型评估要看的是Agent 在拿到资源、执行动作、消耗配额的过程中有没有越界、有没有被正确拦截、参与机制有没有起作用。换句话说能力评测回答“Agent 能不能做”治理评估回答“Agent 被允许做的过程中系统能不能管住”。这两类评估目标不同指标也不同。只跑能力评测不跑治理评估等于只检查发动机不检查刹车。5.2 判断有效性的四组指标这里给出四组可以实际采集的指标评估维度要看的指标判断标准授权合规越权调用次数、被拦截次数越权次数应为 0拦截次数不能长期为 0 或长期过高参与有效性提案数、审批数、否决数、规则变更数参与者不只是挂名规则能随环境变化资源效率单任务成本、资源闲置率、单日消耗预算没有被过度申请也没有频繁熔断可审计性日志完整率、链路回溯率、审计平均耗时任意动作都能在日志里还原完整链路这些指标不一定要做得很重但至少要能按周或按月导出。稳定的治理机制反馈周期应该是可预期的。5.3 通过什么方式做持续评估在 Agent 上线前可以做“治理演练”构造一组可能越权的动作比如让 Agent 尝试导出敏感数据、尝试超额退款、尝试重复调用某个接口然后看系统能不能全部拦截住。这组演练不需要非常复杂重点覆盖高风险动作。上线后可以每周抽取一部分真实日志做抽样复核确认日志链路完整、审批流程正确、熔断阈值没有失效。评估的目的不是追求一个完美分数而是保证出了问题能被发现并且发现后能定位到具体环节。参与式治理如果只是走流程没有数据反馈就等于没做。6. 落地时会遇到的坑和排查顺序6.1 没人参与怎么办参与式治理最容易出现的第一个问题不是机制复杂而是没人参与。配置了投票流、审批流、审计会但实际没人看、没人投。出现这种情况优先排查三件事参与成本是不是太高比如每个低风险动作都要投票参与者自然会疲惫。参与后有没有实际影响如果参与结果不被采纳后面就不会有人再来。信息是不是透明参与者看不到 Agent 当前能力和风险就没法形成判断。对应做法是降低参与成本只对高风险动作开放参与同时把参与结果回传到执行层让参与者看到自己的决策真实改变了 Agent 行为。6.2 参与的人只关心自己怎么办参与式治理里参与者可能只关心自己的利益这是正常现象。机制设计要解决的就是这个问题。排查思路授权权重是否合理所有参与者平均投票不等于公平。是否存在利益冲突比如能用退款功能的人不应该自己审批自己的退款。否决门槛是否设置过高或过低门槛太高问题永远无法被叫停门槛太低正常执行会被频繁打断。这里不要一开始就追求完美治理。先通过审计记录看参与者的意见和最终决策是否存在系统性偏向再决定要不要调整权重或引入独立审计角色。6.3 流程合规但 Agent 效果变差怎么办还有一种情况很经典流程都跑了票也投了审批也做了但 Agent 的实际效果明显变差。比如任务经常被熔断、预算太紧导致高频业务跑不完、审批周期太长错过时效窗口。这通常不是治理错了而是“约束条件”设置不合理。排查顺序是看熔断原因是成本超限、频次超限还是动作被误判为越权。看预算使用曲线是持续打满还是偶尔波动。看审批超时是审批人太少还是审批门槛设置得过低导致堆积。对应的调整方向是把低频低风险动作的约束放宽把高频高风险动作盯紧审批流可以由“单人多级”改为“抽样复核”“事后追责”。治理的目的是让 Agent 在安全边界内更高效不是让边界缩小到没法做事。6.4 排查优先顺序如果 Agent 治理出现问题我建议按这个顺序排查先确认是不是资源目录不完整有没有 Agent 可以访问但没登记的资源。再确认授权策略是否过宽Default 是允许还是拒绝条件规则是否生效。然后看参与流程是否失效审批是否只是形式投票是否没有实际影响。接着看日志链路能不能从动作反查到授权变更。最后看评估指标熔断次数、被拦截次数、审计平均耗时是否异常。很多治理问题看起来像 Agent 能力问题实际是授权和审计问题。先看链路再改参数是最省事的办法。7. 我的一点实际建议7.1 小团队怎么起步如果团队只有几个人不要急着设计委员会和投票机制。先做一个最小闭环选一个 Agent列资源清单。给资源配置默认拒绝策略。把高风险动作的审批接到人工。记录全量日志。每周看一次审计摘要。这个闭环跑通之后再逐步增加参与者。小团队不需要复杂机制但需要把“授权、日志、熔断”三件事先立住。7.2 大团队怎么避免过度治理如果组织很大要区分“执行决策”和“治理决策”。Agent 的日常动作由策略引擎执行不需要每次都召集人审批只有资源结构调整、高风险工具接入、预算大幅提升这类治理决策才需要参与式流程。参与式治理不是越多越好而是该有通道的时候有通道该自动执行的时候自动执行。把高频动作交给规则低频高风险动作交给参与者这个比例才是机制设计真正需要调优的地方。Resourced Authority 这类框架真正落地最该盯住的不是有没有投票界面而是三个可判断的东西资源清单是否完整、授权变更是否可追溯、参与通道是否真的能影响执行。把这三点抓住它就不只是概念里的治理模型而是能让 Agent 跑得更稳的普通工程实践。