本刊此前两篇姊妹篇已经把 Agent 治理的地基铺得很清楚：《Agent 持证上岗：AI 员工入职要闯的六道关卡》拆解了身份、网络准入、企业工牌、支付资格、信誉背调、责任保险——六道关卡都在同时建设；《接管清单：Skill Market 里，谁在允许 Agent 按下那个按钮》则拆解了 Skill/MCP 市场里"读取/写入/破坏性"三档权限颗粒度，和高危操作前的人工确认闸门。两篇加起来回答的是："这个 Agent 是谁，它有资格做多细颗粒度的事。"但这留下了两道更难、也更没有共识的题：该审核这个 Agent 的哪个部分——它声明的意图、它的思维过程，还是它即将执行的动作本身；以及整个生态到底该向谁敞开——完全开放，还是白名单准入。而开源模型和开源 Agent 的存在，让这两道题连"技术上能不能有完整答案"都要打一个问号。
一、从"身份证"到两道更难的题
《持证上岗》里说得很直白：Cloudflare Web Bot Auth 的签名、Cloudflare Wallets 的持久身份、企业侧 Entra Agent ID 的强制绑定、ERC-8004 的链上"护照"——2026 年，"敲门的这个程序到底是谁"这个最基础的问题，正在被多家公司同时、独立地解决。这道关卡的进展速度是六道里最快的，原因也很朴素：它复用的是身份管理这个已经存在了几十年的成熟工程领域，只是把"人类员工"换成了"Agent"。
但身份证解决的只是"你是谁"，回答不了后面两个更难的问题。第一个问题发生在每一次具体的行动之前：你说你要做的事，和你实际会做的事，是同一件事吗？谁来验证，验证的对象又是什么？第二个问题发生在生态的入口处：这个身份证，应该被允许走进哪些门？是所有门都默认打开，还是只有被列进名单的门才开？这两个问题，恰好也是过去半年里安全研究、协议设计和产业实践里进展最快、也最混乱的两块战场。
二、审什么：声明的意图、思维链，还是行动本身
目前至少有三条并行的技术路线，回答"该审核 Agent 的哪个部分"这个问题，彼此的假设完全不同。
路线一：审核声明的意图。《持证上岗》里提到的 Google AP2 协议，核心设计就是三份可签名的"委托书"——Intent Mandate（意图授权）、Cart Mandate（购物车授权）、Payment Mandate（支付授权），把"用户到底授权了什么"做成 W3C 可验证凭证提前留痕。这条路线的优点是成本低、可预先审计；缺点也很直接：它审的是 Agent 声称 要做什么，不是它实际会做什么——一份委托书完全可以被诚实地签署，然后被一次模型的偏差执行得面目全非。
路线二：把思维链本身当作审计日志。一种正在被讨论、甚至被部分场景要求的做法，是把 Agent 做出高风险决策（招聘、放贷、定价、医疗分诊）时的推理过程完整记录下来，作为可追溯、防篡改、可供监管审计的日志，有的方案甚至提出至少保留七年。这条路线的逻辑很直觉——普通日志只记录"做了什么"，但 Agent 场景里"为什么这么做"往往比结果本身更重要。但业内已经出现明确的技术性反驳：《你的 AI Agent 思维链不是审计日志》指出，模型输出的推理文本，不一定忠实反映它内部真正的决策过程——这正是 AI 可解释性研究里"思维链不忠实"（unfaithful reasoning）这个更早就存在的老问题，换了一个监管场景重新出现。Anthropic 自己在高风险评测场景的安全操作建议里，给出的做法是同时监控模型的思考过程、实际行动和网络活动三者，而不是只信任其中任何一个单一信号。
路线三：在动作真正发生前，实时拦截和验证。这条路线放弃了"信任声明"和"信任叙述"，转而在 Agent 已经决定好要做什么、但还没真正执行的那个瞬间插一刀。2026 年 3 月发表、被 AAAI 2026 "Trust and Control in Agentic AI" workshop 接收的 TrustBench，正是这个思路的代表：它在 Agent 形成动作之后、执行之前介入，跑一遍针对医疗、金融、技术等领域的专用安全校验插件。论文报告的结果是：跨多个 Agent 任务，有害行动整体降低 87%，领域专用插件比通用校验多降低 35%，且延迟控制在 200 毫秒以内——快到足以嵌进真实的生产流程。同期还有 Proof of Execution 这类更偏密码学的方案，把"这一步是否被合约授权""历史记录是否防篡改""执行轨迹能否被确定性重放"三件事绑定进一个运行时可验证的单一对象——论文实测的开销是单次调用约 2.7 毫秒，批量并发场景约 4.4%。
数据来源：Sharma et al., TrustBench, arXiv:2603.09157
三条路线不是互斥关系，更像是同一个问题在不同成本和不同信任假设下的三种答案：意图委托书最便宜也最容易被绕过，思维链记录信息量最大但最不可靠，实时行动拦截最直接但需要为每个高风险领域单独建立校验规则。截至目前，还没有出现一套能同时满足"低成本、高可靠、跨领域通用"的方案——这本身也是为什么 FINRA 在 2025 年底的年度监管报告里，第一次专门为生成式 AI 加了一整节，要求金融机构对 Agentic 系统同时具备监督、留痕和持续监控能力，而不是押注单一某种审核对象。
三、放不放：从"完全开放的注册表"到"企业内部应用商店"
如果说"审什么"是纵向问题，"放不放"就是横向问题：一个已经有身份、也有审核机制的 Agent，应该被允许连接哪些工具和服务？目前的答案分裂成两个方向，正在同时野蛮生长。
一端是完全开放的公开注册表。Smithery、mcp.so、Glama 这类平台的定位是"发现层"而非"准入层"——任何 Agent 都可以连接任何已注册的服务器，注册表本身不做访问控制，也不记录"哪个 Agent 在什么时候访问了哪个工具"。截至目前，公开注册表里索引的 MCP 服务器已经超过一万个，但业内公认的现状是：其中大多数已经破损、被废弃，或者从一开始就是实验性质、无人维护——"如何在一万多个服务器里找到安全、能用的那一小撮"，本身就是这个生态尚未解决的问题。
另一端是企业级白名单。JFrog 的 MCP Registry 把这个问题当作供应链安全问题处理：提供细粒度的角色访问控制和审计日志，让企业只维护一份内部批准过的目录，把未经验证的公开端点挡在企业网络之外。Snowflake 的治理框架干脆直接借用"应用商店"这个说法——IT 和安全团队决定哪些能力可用、谁能访问、在什么条件下访问，员工通过一个可搜索的目录发现已批准的连接器；这个思路在 2026 年 6 月被写进了协议层本身：MCP 规范新增的"企业托管授权"（Enterprise-Managed Authorization，EMA）扩展，让企业身份提供商（IdP）成为 MCP 服务器访问权限的唯一授权源——用户只需登录一次，IdP 自动配置已获批准的服务器，省掉逐个服务器弹出的 OAuth 授权确认框，所有访问决策都留在 IdP 后台一条可审计的记录里。AWS 也发布了对应的开源基础设施，让中央 IT 维护一份批准名单的同时，允许各业务线继续发布自己的内部工具。
| 模式 | 代表 | 优点 | 风险 |
|---|---|---|---|
| 完全开放注册表 | Smithery、mcp.so、Glama | 发现成本低，生态扩张快 | 无访问控制，大量废弃/未维护服务 |
| 企业白名单 | JFrog、AWS MCP Gateway、Snowflake | 供应链风险可控，审计留痕 | 牺牲发现效率，需要持续人工维护名单 |
| 协议内置授权 | MCP EMA 扩展（2026-06） | 把授权决策收敛到企业 IdP，免逐个确认 | 把信任集中在少数身份提供商手里 |
| 精选市场（中间路径） | Claude Skills、GPT Store、社区 Hub | 质量审查 + 开发者分成，兼顾发现与安全 | 平台方拥有事实上的准入裁量权 |
这个分裂并不新鲜——PC 软件、移动应用、浏览器插件，几乎每一代计算平台的工具生态都走过同一条弧线：先是完全碎片化的野蛮生长，然后出现目录型的发现层，再收敛成有审查机制的精选市场，最后往往只剩一两个赢家垄断准入权。Skill/MCP 生态目前正处在"目录"向"精选市场"过渡的阶段：Anthropic 的 Claude Skills 是第一方直营目录，OpenAI 的 GPT Store 走应用商店式的分成模式，社区维护的 MCP Hub 靠精选度而非平台控制力竞争，Hugging Face Spaces 承接的则主要是开源 Agent。历史经验如果重演，这场"完全开放 vs 白名单"的拉锯，最终大概率不会有哪一方"获胜"，而是像应用商店一样收敛成几个寡头平台各自的准入规则。
四、开源这个变量：当模型权重本身就绕开了所有关卡
前面两节讨论的所有机制——身份、意图委托书、思维链留痕、实时拦截、白名单——都隐含一个共同前提：有一个可以被追责的中心化主体，站在 Agent 背后。一个厂商托管的模型可以被要求接入审核插件，一个企业的 IT 部门可以维护一份白名单，一个受监管的支付协议可以要求留痕。但一个下载到本地、自己微调、自己接上工具链跑起来的开源模型，绕开的不是某一道具体关卡，而是这整套逻辑的前提本身。
治理框架本身也还没追上这个问题。2026 年发表的一篇安全综述《从生成内容到自主行动：生成式 AI 的安全与安全威胁》系统梳理了 AI 系统从"生成内容"迁移到"执行操作"之后攻击面的扩张，核心结论是：不少关键的防御手段依赖某种制度协调，而现有治理安排目前还没能提供这种协调——能力部署和攻击面扩张的速度，反复跑在防御响应前面。具体到监管节奏：新加坡资讯通信媒体发展局（IMDA）在 2026 年 1 月率先发布了专门针对 Agentic AI 的治理框架，5 月又根据 60 多家机构的反馈发布了 1.5 版；相比之下，美国 NIST 的 AI 标准与创新中心（CAISI）直到 2 月才刚启动同类的 Agent 标准倡议，业内预计定论级别的指南要到 2027 年才可能出现——而这中间，具备自主操作能力的商业化 Agent 产品早已批量上线了一年多。
欧盟 AI 法案对开源模型的处理方式，某种程度上放大了这个落差：法案明确肯定开源 AI 的经济价值，对开源通用模型的提供者，只要求较轻的透明度义务（训练数据来源的高层级文档、预期用途说明），除非模型达到"系统性风险"的算力门槛，才会触发模型评估、风险缓解等更重的义务。这个设计在"内容生成"时代是合理的——开放权重能让独立研究者、公民社会和监管者做闭源 API 无法做到的审计，偏见可以被检测，失败模式可以被记录，问责可以落到具体的设计决策上，而不是模糊的企业流程。但到了"自主执行"时代，这个设计留下了一个结构性缺口：一旦模型权重被发布或泄露，它就永久存在于全球分散的本地硬件上，完全在自上而下的执法触及范围之外——不管后来监管者定出多严格的 Agent 治理规则，都无法追溯到那个已经在某台本地机器上自主运行的实例。
产业界正在用平行的自愿性协调，弥补这个正式监管留下的空白：由 Anthropic、OpenAI、Block 共同发起、隶属 Linux 基金会的 Agentic AI Foundation（AAIF）——正是《接管清单》里提到的、MCP 协议后来被捐赠托管的那个组织——试图为自主系统建立跨厂商的开放标准；IBM 和 Meta 牵头的 AI Alliance，以及 OECD 的 AI 开放性入门指南，也在从不同角度推动"开放不等于不可问责"这个立场。但这些都是自愿性的行业协调，不是有强制力的监管——对一个决心绕开所有关卡的开源 Agent 部署者，这些框架目前还没有任何硬约束力。
五、对开发者、企业安全团队和政策观察者意味着什么
对 Agent 开发者和安全团队
不要把"意图声明"当作唯一的安全边界。AP2 式的委托书解决的是商业纠纷里的举证问题，不是行为安全问题——如果你的 Agent 会触碰高风险操作，至少要在执行前叠加一层类似 TrustBench 的实时校验，而不是只依赖它自己声明会做什么。
对企业 IT 与合规团队
公开注册表和企业白名单不是二选一，而是要同时存在：公开注册表负责发现新工具，白名单负责决定哪些能真正接入生产环境。2026 年 6 月的 MCP 企业托管授权（EMA）扩展提供了一条把这两层缝合起来的协议级路径，值得优先评估——这比等每个团队各自手搓一套准入流程更值得投入。
对政策观察者
开源模型的执法困境不是"要不要监管开源"的问题，而是"传统的、依赖中心化主体的监管工具，对去中心化分发的权重根本不适用"的结构性问题。新加坡的先行框架和产业界的自愿性协调，短期内会是唯一能落地的答案；真正的制度设计难题——如何为一个没有中心化责任主体的自主系统建立问责机制——目前没有任何一个司法辖区给出过完整方案。
主要参考来源
Agent 持证上岗：AI 员工入职要闯的六道关卡, DeepDive · 接管清单：Skill Market 里，谁在允许 Agent 按下那个按钮, DeepDive · Your AI Agent's Chain of Thought Is Not an Audit Log, DEV Community · Tavishi Sharma, Vinayak Sharma, Pragya Sharma, Real-Time Trust Verification for Safe Agentic Actions using TrustBench, arXiv:2603.09157（AAAI 2026 Workshop on Trust and Control in Agentic AI）· James Rhodes, George Kang, Proof of Execution: Runtime Verification for Governed AI Agent Actions, arXiv:2607.05397 · Zelin Zhang, Qi Li, Jie Cao, Lingshuang Liu, Jianbing Ni, From AI-Generated Content to Agentic Action: Security and Safety Threats in Generative AI, arXiv:2605.16471（Journal of Information and Intelligence）
作者：冯小平，[email protected]