Agent 治理框架选型指南：先定边界，再谈框架

选型之前先明确一个事实：Agent 治理框架不是给 Agent 套上的缰绳，而是给组织自身的决策流程装上的一组约束条件。框架的价值不在技术实现，在于它迫使你回答三个问题：谁有权让 Agent 做什么、Agent 的行为以什么为基准被判定对错、出问题时责任如何追溯。

这三个问题的答案，决定了你需要的框架类型。技术选型的顺序是先定治理边界，再选框架，而不是反过来。

治理框架的四个层级，先判断你在哪一层

Agent 治理不是一个单一的技术栈，它从下到上分为四个层级，每层解决不同的问题，选型时先定位自己的需求落在哪一层。

第一层是身份与权限层。Agent 以什么身份行动，能调用哪些工具，能读写哪些数据。这一层最容易理解，也最容易被低估。很多团队以为给 Agent 配一个服务账号就完成了身份治理，但 Agent 不是无状态的服务，它会在一次任务中多次切换上下文，可能代表不同用户执行不同操作。如果身份粒度不够细，权限边界就会模糊，而模糊的权限边界是所有安全事故的起点。

第二层是行为规范层。Agent 被允许使用哪些策略完成任务，哪些行为被明确禁止。比如一个客服 Agent，它被允许为用户退款，但不被允许查看用户的密码重置记录。行为规范不是写在 prompt 里的软性指令，而是可执行的硬性约束，需要在框架层面被强制校验。

第三层是审计与追溯层。Agent 的每一步决策是否被完整记录，记录是否不可篡改，能否在事后复现完整的决策链路。这一层决定了当事故发生时，你是能定位到具体原因，还是只能面对一个黑盒猜测。

第四层是策略演进层。随着 Agent 的行为模式和业务需求变化，治理策略本身如何被更新和迭代，更新流程是否有版本控制，是否有灰度机制。

多数团队在选型时只盯着第一层，或者把四层混为一谈，试图用一个工具解决所有问题。结果是权限做了，但行为不可控；行为可控了，但审计链断裂；审计做全了，策略又僵化到无法更新。

框架的两种路线：嵌入型与旁路型

明确了层级需求后，框架的选型路线分两种，各有明确的使用场景。

嵌入型框架是把治理逻辑直接写进 Agent 的执行循环里。Agent 的每一步行动前，框架拦截请求，校验权限，检查行为合规性，通过后才放行。LangGraph 的 interrupt 机制、自定义的 tool 校验层、状态机里的 guardrail 节点，都属于这一类。嵌入型的优势是实时性强，能在行动发生前阻止违规；劣势是治理逻辑与业务逻辑耦合，Agent 代码复杂度上升，框架升级会牵动业务代码。

旁路型框架是独立于 Agent 运行时的治理服务。Agent 发出请求，治理服务在外部做校验和记录，两者通过 API 通信。这类框架的优势是解耦，Agent 可以用任何语言写、跑在任何环境里，治理规则统一在外部维护；劣势是存在网络延迟，而且如果 Agent 绕过治理服务直接调用底层工具，旁路就形同虚设。

选嵌入还是旁路，取决于你的 Agent 是运行在可控环境中还是开放环境中。如果 Agent 只运行在你自己的服务器上，调用你白名单内的工具，嵌入型足够，效率更高。如果 Agent 需要调用外部 API、访问第三方系统、运行在用户的浏览器端，旁路型是必须的，因为你无法保证 Agent 一定走你的代码路径。

具体选型时的五个判断标准

不罗列框架清单，给出选型时的判断维度。

标准一：框架是否原生支持人机回环。 Agent 治理与普通 API 治理的最大区别是，Agent 的决策具有不确定性，你无法预判它在每个分支会做什么。因此框架必须支持在关键节点暂停执行、请求人工审批、审批通过后恢复执行的能力。LangGraph 的 interrupt 机制是这类能力的典型实现。如果一个框架不支持在执行中途暂停和恢复，它不适合做 Agent 治理，只适合做简单的自动化脚本管理。

标准二：策略是否与代码分离。 治理策略的变更频率高于业务代码的变更频率。业务需求变了，Agent 的行为边界就要跟着调整。如果策略是硬编码在 Agent 逻辑里的，每次调整都要重新发版，治理就变成了瓶颈。框架因该支持将策略配置化，让非技术角色也能在受控条件下调整规则。

标准三：审计日志是否具备因果完整性。 不满足于记录了 Agent 做了什么，要能记录 Agent 为什么这么做。即每条决策日志需要关联触发它的输入、当时的上下文状态、调用的工具和参数。只有因果完整的日志，才能在事故排查时定位到是哪一步决策出了问题，是 prompt 的问题、工具的问题还是权限配置的问题。

标准四：是否支持多 Agent 的治理隔离。 如果你的系统里有多个 Agent 协作，每个 Agent 的治理边界必须相互独立。Agent A 的越权行为不应该污染 Agent B 的权限上下文。在 MAREF 的实践中，我们遇到过 Agent A 通过调用共享工具间接获得了 Agent B 的数据访问权，就是因为治理隔离没做好。框架需要支持每个 Agent 独立的命名空间和权限域。

标准五：框架自身的逃生舱机制。 任何治理框架都可能被绕过或失效。框架需要提供明确的逃生通道——当治理服务不可用时，Agent 是降级运行、暂停运行还是直接熔断。选型时问清楚这个问题，比问框架有多少功能更重要。

MAREF 的实践：为什么我们在核心链路用 LangGraph

MAREF 做为数字员工管理系统，治理是系统架构的一部分，不是附加功能。我们在核心决策链路上选用 LangGraph 作为执行框架，原因不是它功能最全，而是它在嵌入型治理上提供了最清晰的抽象。

LangGraph 的状态机模型天然适配治理需求。每个节点是一个决策步骤，节点间的边是允许的转移路径，这本身就是一种行为约束。interrupt 机制提供了原生的暂停-审批-恢复循环，不需要自己实现状态持久化。更关键的是，LangGraph 的图结构可以作为审计日志的骨架——每条执行路径对应图上的一个具体遍历序列，回溯时直接沿图反向查找即可。

但 LangGraph 不是万能的。它在旁路治理上支持薄弱，如果 Agent 需要跑在不受信任的环境里，我们会在外层叠加独立的治理代理，而不是依赖 LangGraph 自身的机制。

选型时不要只评估框架本身，要评估框架在你现有技术栈里的嵌入成本。一个功能完美的框架，如果引入后导致你的 Agent 开发效率下降一半，那它的治理价值就是负的。

治理框架不是终点，是起点

框架选型落地后，真正的治理工作才开始。你需要持续监控治理规则本身的有效性——哪些规则被频繁触发，哪些规则从未被触发，频繁触发说明 Agent 的行为边界与业务需求存在偏差，从未触发可能说明规则形同虚设或 Agent 已经找到了绕过的路径。

治理框架的演化速度应该快于 Agent 业务逻辑的演化速度。当你的 Agent 从一个执行简单任务的工具成长为一个自主决策的数字员工，治理框架必须同步从规则校验演进为风险评估。这个演进不是一次性的，是持续的架构迭代。

选型没有标准答案，只有适合你当前阶段和远期演进的答案。先定义清楚你的治理边界，再让框架服务于这个边界，顺序不能颠倒。

---

关于作者

本文由 十亿少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。