2026年Q2，多智能体系统从"能跑"进入"敢跑"阶段。当Agent集群从3个扩展到300个，当工具调用从每分钟10次飙升到每秒1000次，当金融交易、医疗决策、法律文书开始由Agent自主生成时，一个被长期忽视的问题浮出水面：谁在Agent运行的每一毫秒里确保它不会越界？ 答案是运行时治理（Runtime Governance）——一个横跨策略引擎、身份验证、沙箱隔离、人机协作、可观测性和弹性恢复的六层防线体系。本文实测Microsoft Agent Governance Toolkit、NVIDIA NeMo Guardrails、MI9 Framework三大栈，拆解它们如何拦截Agent Loop中的每一次危险动作。

运行时治理的必要性：从"事后审计"到"毫秒级拦截"

传统AI安全聚焦于训练时对齐（Alignment）和部署前评估（Evaluation），但Agent系统引入了一个全新的攻击面：运行时涌现行为。一个合法Agent在执行第47步工具调用时，可能因为上下文窗口溢出、提示注入累积或工具返回异常数据，突然偏离预期路径。

Microsoft在2026年4月开源的Agent Governance Toolkit（AGT）明确指出：它覆盖OWASP Agentic Top 10的全部10项风险，包括提示注入（AG01）、敏感信息泄露（AG02）、供应链攻击（AG03）、越权操作（AG04）等。这不是静态策略文件——AGT的七包架构（Agent OS、Agent Mesh、Policy Engine、Identity、Sandbox、Audit、Resilience）构成了一个在Agent Loop每次迭代中都能拦截和干预的运行时控制平面。

Forrester同期发布的AEGIS框架（Agentic AI Enterprise Guardrails for Information Security）则从CISO视角划出六个治理域：身份与访问管理、数据安全、运行时保护、可观测性、合规审计、弹性恢复。两个框架互为补充——AGT提供工程实现，AEGIS提供治理方法论。

六大治理栈横评

深度分析一：Microsoft Agent Governance Toolkit——七包架构拆解

AGT的核心创新在于将运行时治理拆解为七个独立可组合的包，每个包覆盖Agent生命周期的不同阶段。

Agent OS是整个工具包的基石，它实现了一个"治理门"（Governance Gate）机制——在Agent Loop的每一次迭代中，Agent OS会在LLM调用前、工具执行前、结果返回前插入三个检查点。每个检查点可以执行策略评估、身份验证和审计记录。这意味着Agent不可能在未经治理层审查的情况下执行任何动作。

Agent Mesh解决的是多Agent场景下的治理问题。当Agent A调用Agent B，Agent B又调用工具C时，Mesh层确保治理上下文在整个调用链中传递——包括原始策略、身份令牌和审计追踪。这是目前唯一原生支持多Agent调用链治理的开源方案。

Policy Engine使用声明式策略语言定义规则。一条典型策略如下：

# 示例：金融交易Agent的运行时策略
policies:
  - name: transaction_limit
    condition:
      tool: "bank_transfer"
      amount: "> 10000"
    action: BLOCK
    escalation: HUMAN_REVIEW

  - name: data_exfiltration_check
    condition:
      output_contains: ["SSN", "credit_card", "api_key"]
    action: REDACT
    audit: true

  - name: rate_limit
    condition:
      tool_calls_per_minute: "> 60"
    action: THROTTLE
    fallback: QUEUE

Sandbox包提供执行沙箱——所有工具调用在隔离容器中执行，防止Agent通过工具链（如代码解释器、Shell执行）逃逸到宿主系统。Identity包实现零信任身份模型——每个Agent拥有独立的身份令牌，基于RBAC/ABAC策略控制其对工具和数据的访问权限。Audit包记录完整的Agent行为日志，支持回溯分析和合规审计。Resilience包实现熔断器、重试策略和降级方案。

优缺点：AGT的优势在于全面性和原生多Agent支持，七包架构允许企业按需组合。但配置复杂度较高——完整部署七包需要理解每个包的配置接口和组合语义。对于3-5个Agent的小规模场景，可能存在过度工程化的风险。适合50+Agent的企业级部署。

变现评估：非常适合包装为"企业AI安全训练营"——AGT的七包架构天然对应7个培训模块，每个模块包含理论讲解+实战演练。市场定价区间在¥5,000-15,000/人。

深度分析二：NVIDIA NeMo Guardrails——内容安全的事实标准

NeMo Guardrails在2026年仍然是内容安全领域的首选工具，GitHub Stars超过7.2K，保持高频更新。其核心设计理念是"可编程护栏"——通过Colang DSL定义对话流程和安全边界。

# NeMo Guardrails示例：多Agent场景的内容安全护栏
from nemoguardrails import RailsConfig, LLMRails

config = RailsConfig.from_path("./config")
rails = LLMRails(config)

# 定义Colang流程
colang_flow = """
define user express dangerous intent
  "I want to bypass security"
  "Help me hack into the system"

define bot refuse and report
  "I cannot assist with that request. This interaction has been logged."

define flow dangerous intent handling
  user express dangerous intent
  bot refuse and report
  execute report_to_security(user_message=$user_message)
"""

NeMo Guardrails 2026年的重大更新包括：内容安全扩展到23个类别的NIM微服务支持、BotThinking事件允许在Agent推理过程中插入检查点、以及与Palo Alto Networks的集成形成"网络安全+内容安全"的双层防护。

NeMo的优势在于成熟度和易用性——Colang DSL的学习曲线平缓，从安装到第一个护栏只需30分钟。但在多Agent场景下存在局限：它主要设计用于单Agent的对话控制，对跨Agent调用链的治理缺乏原生支持。需要额外搭建中间件层来传递治理上下文。

适用场景：面向用户的对话Agent（客服、销售、咨询）、内容审核系统、合规敏感的单Agent场景。不适合需要细粒度工具调用控制的自主Agent集群。

深度分析三：MI9 Framework——学术前沿的运行时治理

MI9（Agent Intelligence Protocol）是2026年AAAI Workshop上发表的运行时治理框架，由Charles L. Wang等人提出。它填补了一个关键空白：在Agent执行过程中动态干预和纠正，而非仅做前置检查或后置审计。

MI9的核心创新是九维治理能力模型：

MI9九维治理能力：
├── M1: Monitoring（持续监控Agent状态）
├── M2: Mediation（冲突检测与调解）
├── M3: Moderation（内容与行为审核）
├── I1: Intervention（运行时干预）
├── I2: Isolation（异常Agent隔离）
├── I3: Identity（身份与权限管理）
├── 9a: Audit（全链路审计）
├── 9b: Assurance（行为保证）
└── 9c: Adaptation（动态策略调整）

MI9最引人注目的特性是动态策略适应——当Agent在执行过程中表现出偏离预期的行为模式时（如连续3次工具调用失败后开始尝试非授权工具），MI9可以自动提升安全级别，从"观察模式"切换到"干预模式"，甚至直接隔离异常Agent。

MI9-Eval是配套的评估框架，提供了标准化的治理能力评测方法。但MI9目前仍处于学术阶段，缺少生产级的工程实现。适合作为自建治理系统的设计参考，而非直接使用的工具。

对训练营收效：MI9的理论深度使其适合面向研究型客户的高级工作坊——"AI安全工程师认证"的定价可达¥20,000/人。

深度分析四：分层自治模式——从全手动到全自动的五级体系

运行时治理不是要阻止Agent自主执行，而是要为不同风险级别的任务配置不同的自治级别。2026年多个独立框架（DeepMind的AGI Levels、CSA的Agentic Trust Framework、Zylos的Autonomy Taxonomy）正在收敛到一个五级自治模型：

# 五级自治配置示例
autonomy_levels:
  level_1:
    name: "Copilot模式"
    description: "每步需人工确认"
    trust_score_threshold: 0.0
    allowed_tools: ["read_only"]
    human_approval: EVERY_STEP

  level_2:
    name: "半自主+审批门"
    description: "低风险自主，高风险需审批"
    trust_score_threshold: 0.3
    allowed_tools: ["read_only", "web_search", "calculator"]
    human_approval: ON_HIGH_RISK

  level_3:
    name: "任务域自主"
    description: "限定任务域内完全自主"
    trust_score_threshold: 0.6
    allowed_tools: ["read_only", "web_search", "calculator", "code_runner_sandboxed"]
    human_approval: ON_DOMAIN_BOUNDARY

  level_4:
    name: "监督自主"
    description: "自主执行，事后人工审计"
    trust_score_threshold: 0.8
    allowed_tools: ["all_sandboxed"]
    human_approval: POST_EXECUTION_AUDIT

  level_5:
    name: "完全自主"
    description: "无人工干预（2026年公认不安全）"
    trust_score_threshold: 1.0
    allowed_tools: ["all"]
    human_approval: NONE
    warning: "EXPLICITLY_UNSAFE_FOR_ENTERPRISE"

这个五级模型的关键洞察是：信任不是静态的，而是动态校准的。一个Agent在成功执行100次Level 2任务后，其信任分数会逐步提升，可以升级到Level 3。反之，如果Agent在Level 3任务中出现越界行为，信任分数立即降级回Level 2甚至Level 1。

在代码实现上，LangGraph的breakpoint机制天然支持这种分层模式：

from langgraph.graph import StateGraph
from langgraph.checkpoint import MemorySaver

# LangGraph中的审批门实现
def should_approve(state):
    """根据自治级别决定是否需要人工审批"""
    risk_score = calculate_risk(state)
    autonomy_level = state.get("autonomy_level", 1)

    if autonomy_level >= 3 and risk_score < 0.7:
        return "execute"  # 自主执行
    elif autonomy_level >= 2 and risk_score < 0.4:
        return "execute"  # 低风险自主
    else:
        return "human_review"  # 人工审批

graph = StateGraph(AgentState)
graph.add_node("plan", plan_step)
graph.add_node("execute", execute_step)
graph.add_node("human_review", human_review_step)
graph.add_conditional_edges("plan", should_approve)

深度分析五：人机协作审查模式——六种实战形态

运行时治理中最复杂的部分不是技术实现，而是人机协作的设计。根据McKinsey 2026年Agentic AI治理研究和多家企业实践，六种人机协作审查模式已形成明确的应用场景划分：

审批门模式（Approval Gate）：最经典的模式——Agent在执行关键操作前暂停，等待人工确认。适合金融交易、法律文书生成、医疗诊断建议等高风险场景。Microsoft Foundry的Guardrails Control Plane原生支持此模式。

影子模式（Shadow Mode）：Agent完全自主运行，人类在只读仪表盘中实时监控。人类可随时中断（Circuit Breaker）。适合Agent上线初期的信任建立阶段。Salesforce的AgentForce平台采用此模式。

共识仲裁模式（Consensus Arbitration）：多个Agent提出不同方案，当置信度低于阈值或Agent间存在分歧时，人工作为最终仲裁者。适合内容审核、风险评估、战略决策支持。

分层自治模式（Tiered Autonomy）：如前所述，根据任务风险等级动态调整人工介入程度。

纠正反馈模式（Correction Feedback）：Agent执行完毕后，人工提供纠正或评分，反馈被注入后续Agent运行中。这是RLHF在编排层的应用。CrewAI的human_input工具支持此模式。

协作监督模式（Collaborative Oversight）：一个人类团队监督一个Agent池，通过共享仪表盘实现多对多监督。这是2026年的新兴模式，适合大规模Agent部署。

深度分析六：多Agent调用链治理——从单点防护到全链路追踪

当Agent A→Agent B→Tool C→Agent D形成调用链时，治理的复杂度呈指数级增长。一个看似合法的请求可能经过多次Agent转发后变成越权操作。

Microsoft的Multi-Agent Reference Architecture提出了三层治理模型：

入口治理层：在Agent Mesh的入口点执行策略检查和身份验证。每个进入Mesh的请求都携带治理令牌，包含调用者身份、允许的操作范围和信任级别。

传播治理层：治理上下文在调用链中自动传播。当Agent A调用Agent B时，Agent A的治理令牌被传递给Agent B，Agent B在此基础上叠加自己的治理策略。如果Agent B的策略比Agent A更严格，则以更严格的为准。

出口治理层：在最终执行工具调用或返回结果前，执行最终的策略检查。这是最后一道防线，确保即使中间Agent的治理层被绕过，出口层仍然能拦截危险操作。

┌─────────────────────────────────────────────────┐
│              多Agent调用链治理架构                │
│                                                   │
│  ┌──────┐   治理令牌    ┌──────┐   治理令牌     │
│  │Agent │─────────────▶│Agent │─────────────▶   │
│  │  A   │  策略+身份    │  B   │  叠加策略      │
│  └──┬───┘              └──┬───┘                  │
│     │                     │                      │
│     ▼                     ▼                      │
│  ┌──────────────────────────────────┐            │
│  │       Agent Mesh治理层           │            │
│  │  ┌────────┐ ┌────────┐          │            │
│  │  │Policy  │ │Identity│          │            │
│  │  │Engine  │ │ Verify │          │            │
│  │  └────────┘ └────────┘          │            │
│  │  ┌────────┐ ┌────────┐          │            │
│  │  │Audit   │ │Sandbox │          │            │
│  │  │Trail   │ │Exec    │          │            │
│  │  └────────┘ └────────┘          │            │
│  └──────────────────────────────────┘            │
│     │                     │                      │
│     ▼                     ▼                      │
│  ┌──────┐            ┌──────┐                    │
│  │Tool C│            │Agent │                    │
│  │(沙箱)│            │  D   │                    │
│  └──────┘            └──────┘                    │
└─────────────────────────────────────────────────┘

深度分析七：可观测性——治理的眼睛

没有可观测性，治理就是盲目的。2026年的多Agent可观测性栈正在从"日志收集"进化到"治理感知遥测"。

LangSmith、Arize Phoenix、LangFuse等工具提供了Agent执行追踪能力，但它们缺乏治理语义。一个"治理感知"的可观测性系统需要记录：

• 策略触发事件：哪条策略在哪个检查点被触发，触发了什么动作（BLOCK/REDACT/ESCALATE/THROTTLE）
• 信任分数变化：Agent信任分数的时序变化曲线，包括升降级事件和原因
• 人工介入事件：审批门的等待时间、审批结果、审批人的决策模式
• 异常模式检测：连续失败、异常工具调用序列、非预期状态转移

Microsoft AGT的Audit包提供了这些能力的基线实现，但它与可观测性平台（如Datadog、Grafana）的集成仍需要额外工作。

多Agent运行时治理架构总览

graph TB
    subgraph "用户请求层"
        U[用户/系统请求]
    end

    subgraph "治理控制平面"
        direction TB
        GOV[治理协调器]
        PE[策略引擎]
        ID[身份验证]
        TC[信任校准]
        HT[人机协作管理]

        GOV --- PE
        GOV --- ID
        GOV --- TC
        GOV --- HT
    end

    subgraph "Agent执行层"
        direction LR
        A1[Agent A<br/>Level 3 自治]
        A2[Agent B<br/>Level 2 自治]
        A3[Agent C<br/>Level 4 自治]

        A1 <-->|治理令牌传播| A2
        A2 <-->|治理令牌传播| A3
    end

    subgraph "安全执行层"
        SB[沙箱执行环境]
        TOOL[工具注册表<br/>权限控制]
        RL[速率限制器]

        SB --- TOOL
        SB --- RL
    end

    subgraph "可观测性层"
        AUD[审计日志]
        MON[实时监控]
        ALR[告警系统]
        DASH[治理仪表盘]

        AUD --- MON
        MON --- ALR
        MON --- DASH
    end

    U -->|入口治理| GOV
    GOV -->|策略+令牌| A1
    A1 -->|工具调用请求| SB
    SB -->|执行结果| A1
    A1 -->|治理事件| AUD
    HT -.->|人工审批| GOV
    TC -.->|信任分数更新| GOV

    style GOV fill:#e74c3c,color:#fff
    style PE fill:#c0392b,color:#fff
    style SB fill:#2ecc71,color:#fff
    style AUD fill:#3498db,color:#fff

五级自治与治理栈匹配决策树

graph TD
    START[评估Agent任务风险等级] --> Q1{涉及敏感数据?}

    Q1 -->|是| Q2{操作可逆?}
    Q1 -->|否| Q3{工具调用频率>100/min?}

    Q2 -->|否| L1[Level 1: Copilot模式<br/>每步人工确认<br/>AGT + NeMo Guardrails]
    Q2 -->|是| Q4{涉及资金/法律?}

    Q4 -->|是| L2[Level 2: 审批门模式<br/>高风险操作人工审批<br/>AGT + LangGraph Breakpoints]
    Q4 -->|否| L3[Level 3: 任务域自主<br/>域内自主+边界审批<br/>NeMo + 自建策略层]

    Q3 -->|是| L3
    Q3 -->|否| Q5{Agent数量>10?}

    Q5 -->|是| L4[Level 4: 监督自主<br/>事后审计+实时监控<br/>AGT全栈 + 可观测性平台]
    Q5 -->|否| L3

    L1 --> IMPL[实施建议]
    L2 --> IMPL
    L3 --> IMPL
    L4 --> IMPL

    style L1 fill:#e67e22,color:#fff
    style L2 fill:#f39c12,color:#fff
    style L3 fill:#27ae60,color:#fff
    style L4 fill:#2980b9,color:#fff

场景推荐与实施路径

快速启动路径：

第一步，从NeMo Guardrails开始，花1天时间搭建内容安全护栏。这是ROI最高的切入点——投入小、效果立竿见影。

第二步，引入LangGraph的breakpoint机制实现审批门。如果你的Agent框架不是LangGraph，用AutoGen的UserProxyAgent或CrewAI的human_input工具也能实现类似效果。

第三步，当Agent规模超过10个时，开始评估Microsoft AGT。它的Agent Mesh和传播治理层在多Agent场景下的价值才开始显现。

第四步，建立治理仪表盘。无论你用哪个治理栈，可观测性都是刚需。从LangSmith或LangFuse开始，逐步添加治理语义的监控指标。

关键洞察：2026年的运行时治理正在从"可选安全层"转变为"合规必需品"。EU AI Act对高风险AI系统的人工监督要求、美国AI行政令的透明度要求，都在推动运行时治理成为Agent系统的标配。这不是技术选型问题，而是法律合规问题。不部署运行时治理的Agent系统，在2026年Q4的监管环境中将面临不可接受的法律风险。

OWASP Agentic Top 10的发布是另一个标志性事件——它为Agent安全提供了标准化的威胁分类，而Microsoft AGT是第一个声称全覆盖这10项威胁的开源工具。这意味着安全审计师现在有了明确的检查清单，而AGT提供了对应的实现方案。

从工程实践角度看，运行时治理最大的挑战不是技术实现，而是治理策略的定义。什么样的工具调用需要审批？什么样的输出需要脱敏？信任分数的升降级阈值如何设定？这些问题需要安全团队、业务团队和工程团队共同回答。一个好的治理系统应该让这些策略的定义、测试和迭代变得尽可能简单——这也是AGT声明式策略语言的设计初衷。

参考来源

1. Microsoft Agent Governance Toolkit - GitHub — 七包运行时治理架构，覆盖OWASP Agentic Top 10
2. MI9: An Integrated Runtime Governance Framework for Agentic AI - arXiv — AAAI 2026 Workshop论文，九维治理能力模型
3. Forrester AEGIS Framework — 企业级Agentic AI安全六域治理框架
4. Multi-Agent Reference Architecture - Microsoft — 微软多Agent参考架构中的治理层设计
5. AI Agent Autonomy Levels: Taxonomy, Trust Calibration - Zylos Research — 五级自治分类与信任校准研究
6. Governing Multi-Agent AI Systems: Enterprise Blueprint - Architecture & Governance — 企业级多Agent治理蓝图 ��系统）会产生大量检查点。如何在不丢失关键状态的前提下压缩历史检查点？这类似于数据库的VACUUM操作，但需要理解Agent状态的语义。

Mem0在2026年提出的分层记忆架构（短期→工作→长期→归档）为这个问题提供了参考，但其面向的是单Agent记忆，多Agent共享记忆的压缩仍需探索。

参考来源

1. LangGraph Persistence Documentation — LangGraph官方检查点与持久化层设计文档
2. Production Multi-Agent System with LangGraph: State Checkpointing — LangGraph生产环境状态管理与检查点实战指南
3. Multi-Agent Memory from a Computer Architecture Perspective (arXiv:2603.10062) — 从计算机体系结构视角分析多Agent记忆系统的学术论文
4. OpenAI Agents SDK vs Swarm: Migration Guide (2026) — OpenAI Agents SDK与Swarm的架构差异及Handoff状态传递分析
5. Agent Self-Healing and Failure Recovery — 生产AI Agent系统的死锁预防、熔断器和恢复策略深度分析

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。