AI代理正在从回答问题转向采取行动。
这一转变彻底改变了风险模型。
聊天机器人生成文本。代理操作系统。
它们可以读取电子邮件、调用 API、更新客户记录、部署代码、创建工单、审批工作流步骤、与其他代理协调，并将新知识存储到长期记忆中。
这意味着核心问题不再是：
这个答案正确吗？
而是：
这个代理现在应该被允许行动吗？
这正是治理层要回答的问题。
1. 记忆是有用的，但它不是治理。
记忆帮助代理在会话之间保留上下文。
它帮助代理记住用户偏好、过往工作、工具输出以及之前的决策。这很重要。但记忆并不能决定：
- 哪些事实可以被允许进入记忆
- 哪些记忆已经过时或被污染
- 哪些行动需要审批
- 哪个工作流步骤必须下一步执行
- 执行前需要哪些证明
- 哪个代理可以使用哪些信息
在生产级的代理系统中，更棘手的问题往往不是检索，而是权限。
记忆帮助代理记住。
治理帮助代理判断它被允许做什么。
这就是 Marrow 的定位所在。
Marrow 不仅仅是一个记忆层。它是AI 代理集群的研判层。
2. 可观测性解释过去。代理需要的是对未来行动的控制。
可观测性是必要的。团队需要追踪、日志、评估、标注、告警和仪表盘。
但事后可见性并不能在不良行动发生前阻止它。
如果一个代理部署了不安全代码、发送了敏感邮件、审批了错误的付款，或跳过了必要的工作流步骤，仪表盘或许能在事后解释事件。但它不一定能预防事件。
对于高影响工作流，信号必须在行动前到达代理：
- 风险级别
- 所需证明
- 策略约束
- 所有者审批
- 回滚计划
- 确切下一步
- 允许、警告、审核或阻止
这就是可观测性与治理之间的差距。
仪表盘告知人类。
治理在代理行动前告知代理。
3. 评估是一个快照。生产环境是一条流。
部署前的评估能发现许多失败。但生产环境中的代理活在不断变化的环境中。
提示词会变。工具会变。API 会变。数据会变。策略会变。集群中的其他代理也会变。
一个基准测试可能表明某个代理在某种条件下表现良好。生产环境则提出了另一个问题：
当环境变化时，这个代理还能持续做出正确决策吗？
关于工具使用代理的研究也指向同一方向。
ToolEmu 研究了使用高风险工具的语言模型代理，表明代理失败可能造成严重的现实后果。AgentHarm 和 CUAHarm 关注代理在能够使用工具或操作计算机时的有害行为。其他研究显示，代理可能在抽象层面理解风险，但在具体轨迹中仍未能避免风险行为。
教训是实际的：
安全不能只存在于模型中，也不能只存在于基准测试中。
生产环境中的代理需要运行时控制。
4. 治理正在成为 AI 基础设施。
主要 AI 治理框架正汇聚到同一个理念上：负责任的 AI 必须变得可操作。
不仅仅是原则。
不仅仅是策略 PDF。
不仅仅是仪表盘。
可操作的治理需要：
- 记录在案的风险管理
- 自动日志记录
- 针对高影响决策的人工监督
- 贯穿生命周期的质量管理
- 系统行为的可追溯性
- 上市后监控
- 对不良后果的责任追究
这一点在 NIST AI RMF、NIST 生成式 AI 概况、ISO/IEC 42001、OECD AI 原则、欧盟 AI 法案、OWASP 代理 AI 风险分类以及 2026 年五眼联盟关于代理 AI 服务的指南中均有体现。
方向很明确。
企业 AI 系统需要在其整个运行生命周期内具备证据、控制、可追溯性和问责制。
对于 AI 代理而言，这意味着治理必须进入运行时。
5. 代理治理层应该做什么
治理层是位于代理运行时与代理可能影响的系统之间的控制平面。
它接收代理的意图行动，根据策略、权限、风险、证明和先前结果进行评估，然后返回一个可强制执行的决策：
允许
警告
需要审核
阻止
一个真正有效的治理层需要九个功能。
- 身份与范围化权限
每个代理都需要一个清晰的身份、有限的权限和范围化的凭证。
如果每个代理共享同一个 API 密钥，集群就无法被治理。
- 运行时策略
策略必须变成可执行的运行时条件。
哪个步骤必须先执行？
需要哪些证明？
哪个行动总是需要审核？
哪个行动永远不应自动运行？
- 风险门控
系统应根据影响、可逆性、敏感性和业务上下文对行动进行分类。
低风险工作可以自动运行。高风险工作可能需要证明、审批或阻止。
- 证明包
行动前，代理应附上证据。
例子：
- 测试覆盖率
- 回滚计划
- 策略条款
- 身份验证
- 临床审批
- 账单审核
- 主管签字
- 审批路由
人工审核不应是一个针对所有事项的手动队列。
它应该是一个针对错误成本高的行动的检查点。
- 审计与溯源
每个决策都应是可追溯的。
谁发起的？
为什么被允许或阻止？
应用了哪条策略？
附带了哪些证明？
谁审批的？
接下来发生了什么？
- 结果闭环
治理并非在允许或阻止时结束。
系统必须完成闭环：
- 行动成功了吗？
- 行动失败了吗？
- 需要回滚吗？
- 谁审批了？
- 应该存储什么教训？
- 记忆写入治理
并非每条日志都是知识。
并非每条知识都应影响每个代理。
真实结果只有通过受控写入才能成为记忆。
- 集群级学习
治理层应跟踪整个集群的行为：
- 与基线工作流的偏离
- 重试循环
- 重复失败
- 应警告未来代理的模式
这就是治理超越限制、成为学习的地方。
6. Marrow 作为治理案例研究
Marrow 围绕一个简单的操作循环设计：
定向 → 思考 → 行动 → 检查 → 提交
每个步骤都有一个治理功能。
定向 呈现相关的历史、警告和约束。
思考 在行动发生前评估意图行动。
行动 在上下文和护栏的加持下执行。
检查 检查是否缺少证明或闭环。
提交 记录结果，以便下一次决策得以改进。
这是记忆与研判之间的核心区别。
记忆问：
代理知道什么？
Marrow 问：
代理应该行动吗？在什么条件下？
其产品功能直接映射到运行时治理：
- decisionBrief() 为代理提供行动前上下文。
- workflowGate() 返回允许、警告、需要审核或阻止。
- runGuarded() 包装风险工作，附上行动前指导和结果闭环。
- agentRuntime() 将经验和证明要求注入代理上下文。
- agentStatus() 显示 Marrow 是否活跃并收集有用信号。
- valueReport() 将治理转化为所有者可见的证明。
换句话说：
Marrow 将过往结果转化为行动前研判。
7. 一个具体例子：糟糕的部署
想象一个 CI/CD 代理即将部署一个支付 webhook 变更。
构建通过了。
分支准备好了。
代理即将推送到生产环境。
但拉取请求缺少三样东西：
- 测试覆盖率
- 回滚计划
- 冒烟测试
没有治理，部署可能会通过。
支付故障数小时后才出现。客户受到影响。值班工程师手动回滚。事故变成了又一次事后复盘。
有了治理，工作流门控在部署前运行。
它返回：
风险级别：高
证明包缺失
部署已被阻止
代理不仅仅是在记录更多日志。它被强制在正确的时间点停下。
这就是行动前治理的价值。
8. 代理治理的正确指标
治理层不应只统计日志。
它应衡量集群是否变得更安全、更一致、更易于审计。
有用的指标包括：
- 行动覆盖率： 有多少高影响行动经过了门控
- 证明完成率： 有多少行动在执行前包含了所需证明
- 结果闭环率： 有多少决策以真实结果闭环
- 预防重复失败： 已知失败模式被避免的频率
- 偏离严重度： 代理偏离已批准工作流的程度
- 误报率： 门控过于频繁阻止的频率
- 漏报率： 危险行动漏过的频率
- 审计重建时间： 解释一个决策所需的时间
- 人工审核精准度： 人工审批是否用于正确的行动
治理是有用的，当它能减少回滚、防止重复事件、缩小不必要的审核，并使代理行为更容易证明。
否则，它就变成了合规秀。
9. 治理层也有风险
治理层也可能失败。
它可能配置错误。策略可能过时。证明可能不完整。门控可能过度阻止。攻击者可能针对控制平面。如果它存储了太多敏感数据，它就会成为风险集中点。
因此，治理层本身也需要纪律：
- 默认最小权限 代理应只获得它们需要且当时所需的权限。
- 高影响行动失败时关闭 如果行动可能造成严重伤害，缺失证明应停止执行。
- 低风险自动化失败时软化 并非每个行动都值得同等程度的阻碍。
- 人类可读的证据，机器可读的策略 操作人员需要理解决策。系统需要强制执行。
- 从真实结果中学习 没有结果闭环，系统只会积累日志，而非研判。
10. 结论
AI 代理将软件推向一种新的运行模式。
它们可以选择工具、与其他代理协调、修改系统，并产生后果。
在这种模式下，治理不是部署后添加的层。它属于运行时内部。
记忆、可观测性、评估和人工审核都很重要。但每个只解决了问题的一部分。
治理层将它们连接成一个负责任的行动循环：
行动前的策略
执行前的证明
行动中的权限
行动后的结果
跨集群的学习
这就是 Marrow 背后的论点。
AI 代理集群不仅仅需要记住更多。
它们在行动前需要更好的研判。
参考文献
- NIST. AI 风险管理框架
- NIST. 生成式 AI 概况，NIST AI 600-1
- OECD. OECD AI 原则
- 欧洲委员会 AI 法案服务台. 第 9 条：风险管理系统
- 欧洲委员会 AI 法案服务台. 第 12 条：记录保存
- 欧洲委员会 AI 法案服务台. 第 14 条：人工监督
- 欧洲委员会 AI 法案服务台. 第 17 条：质量管理系统
