受监管的AI智能体：一个策略模型，多个运行时执行点
如何在运行时控制成本、模型选择、数据、工具以及MCP调用：治理框架、中性策略方案、备用机制、限制措施与追踪功能。
来源: Building Governed AI Agents: How to Control Cost, Data, Tools and Actions at Runtime
一名客服人员收到一笔退款申请，消息中包含了账户号码和电话号码。为处理该请求，客服需要借助语言模型来阅读申请内容，使用内部工具查询订单信息，通过MCP连接CRM系统添加备注，对于金额异常巨大的退款情况还可能需要另一名客服进行审核。这些技术早已不再新鲜。难点在于，这一流程中的每一步都会跨越不同的政策边界，而每次跨越都会引发新的问题。
- 这些客户数据是否可以传输给选定的模型提供商？
- 该笔退款仍在预算范围内吗？
- 此地区的工作负载是否可以使用该模型？
- CRM服务器是否需要接收整个对话内容？
- 退款工具能否在无人审批的情况下直接支付2,000美元？
政策文件原则上可以回答这类问题，系统提示也可以提醒智能体注意部分要点。但两者都无法始终如一地强制执行规则。正因如此，智能体治理便成了一个运行时问题。
有一套已发布的受控智能体框架很好地描述了这一转变：治理负责制定规则，而网关则是这些规则与实时流量相接的地方。该框架将相关工作分为五项活动：治理、决策、保护、观察和保障。其中一个重要的观点是，模型调用、工具调用、MCP调用以及智能体间的交互各自存在不同的风险。这种区分有助于设计出更合理的方案，而非将所有控制措施都塞进一个庞大的提示或网关中。
让政策随请求一同传递
最简单的模型是一个伴随系统交互而存在的治理信息包，其中包含足够的上下文信息，以便在跨越特定边界之前做出决策：
- 身份与租户信息，
- 工作负载与执行代理，
- 风险等级与数据分类，
- 当前支出与限额，
- 允许使用的服务提供商与地区，
- 允许使用的工具及操作范围，
- 需要人工审批的阈值，
- 策略版本以及追踪或决策编号。
并非每个组件都需要所有字段，这个信息包的存在是为了让无论执行代理走到何处，都能一致地回答同类问题。
- 对于模型调用而言，相关信息包括支出金额、服务提供商、地区、数据保留期限及删除规则。
- 对于退款工具而言，相关信息则是用户的身份、订单归属权、退款金额以及审批等级。
因此，设计并非采用单一的通用过滤器，而是一个具有多个执行点的策略模型。此时运行时治理才变得具体起来，因为关键问题不再是是否存在策略，而是哪个组件能够在产生任何副作用之前终止交互。
一个简化的、与供应商无关的示例
无需任何治理平台即可识别这种模式。下面的Python代码刻意保持中立，不依赖任何产品的API，其作用是展示决策点。
from dataclasses import dataclass
from enum import Enum
class Decision(str, Enum):
ALLOW = "allow"
BLOCK = "block"
APPROVAL = "approval"
FALLBACK = "fallback"
@dataclass(frozen=True)
class PolicyContext:
user_id: str
workload: str
risk_tier: str
data_class: str
spend_usd: float
spend_limit_usd: float
policy_version: str
def before_model_call(ctx: PolicyContext, model: str) -> Decision:
if ctx.spend_usd >= ctx.spend_limit_usd:
return Decision.BLOCK
if ctx.data_class == "restricted" and model not in APPROVED_PRIVATE_MODELS:
return Decision.FALLBACK
return Decision.ALLOW
def before_tool_call(
ctx: PolicyContext,
tool: str,
amount: float = 0,
) -> Decision:
if tool not in TOOL_SCOPES[ctx.workload]:
return Decision.BLOCK
if tool == "issue_refund" and amount > 500:
return Decision.APPROVAL
return Decision.ALLOW
def before_mcp_call(
ctx: PolicyContext,
server: str,
) -> Decision:
if server not in APPROVED_MCP_SERVERS:
return Decision.BLOCK
if ctx.data_class == "restricted" and server in EXTERNAL_SERVERS:
return Decision.BLOCK
return Decision.ALLOW
语法的重要性远低于模型绝不允许处理的那些事项清单。模型可以理解客户的需求，但它无法判定现在退还2000美元符合政策规定，也无法因为请求内容看似无害就认为未获批准的MCP服务器可以使用。这类结果都属于由运行时决定的确定性状态变化。
生产版本还应为每个决策提供证据：政策版本、输入范围、结果、理由、执行主体、时间戳以及追踪ID。这些证据才能证明究竟是哪条政策被实际执行，而不仅仅是表明存在相应的政策文档。
模型网关能提供帮助，但并非完整的设计方案
在该框架中，LLM网关是一个用于身份验证、模型选择、上下文裁剪、使用额度管控、故障处理以及决策依据的共享层。目前已有某代理工具供应商推出了相关产品，该产品已于2026年8月进入公开测试阶段，具备使用额度与速率限制、模型备用方案、服务提供商路由选择、敏感数据保护以及追踪功能集成等特性。对于普通模型客户端而言，其使用成本较低：只需将客户端的base_url指向该网关，集中存储服务提供商密钥，并在一处设置相关策略即可。
这一点非常重要，因为否则模型治理机制将不得不被复制到每个代理中。
agent A → custom rate logic → OpenAI
agent B → custom PII logic → Anthropic
agent C → custom fallback → Gemini
agent D → no controls → self-hosted model
网关可以将这些数据合并到同一层中。
agents
↓
shared model-call policy
↓
approved providers / hosts
不过要避免在此轻易过度概括。该治理框架的范围比任何单一网关产品都要广泛，它明确讨论了工具调用、MCP调用以及智能体之间的交互，因为智能体的最大风险往往在于其能够执行的操作，而非它生成的文本。网关的公共测试版控制功能主要针对模型流量，而在智能体框架、工具运行时环境、MCP边界或专门的操作网关处仍需额外的管控措施。这种分工是合理的，因为模型网关不应假装自己能够授权那些它根本无法看到的生产数据库变更。
可靠性也是治理的一部分
一旦网关处于关键路径上，如果故障处理机制不够明确，治理措施本身就可能导致服务中断。有两个思路可以解决这个问题。
首先，每项工作负载都需要明确的故障开放或故障关闭策略。那些无法连接到策略服务的低风险摘要请求可以实现优雅降级。而那些无法证明其数据已经过脱敏处理或符合存储策略的受限数据请求，则不应被允许进入故障开放状态。
其次，备用模型必须与主模型具有同等策略标准，而不仅仅是可用即可。假设某个主模型因能将数据存储在约定保留策略要求的区域中而获得通过，那么自动切换到违反这些条款的更便宜或更易获取的服务提供商并不会提升系统的弹性，反而只是用合规性问题来换取看似正常运行的假象。
支出控制也遵循同样的逻辑。设定上限固然有帮助，但如果仅有上限却没有警报机制和升级路径，就会让治理工作变成任意的停机处理。更好的设计应是采用分步控制的方式。
usage approaches threshold
↓
alert
↓
route / reduce context / downgrade model if allowed
↓
hard block when policy requires it
↓
auditable exception path if business-approved
正因如此，模型路由更接近于投资组合管理，而非向廉价模型发送简单的提示。成本至关重要，延迟、数据处理、质量、风险等级以及可用性也同样重要。
中央控制平面的成本
将策略集中管理可以避免每个代理都携带自己的副本，但同时也把责任集中在了那个地方。运行时层现在处于模型流量的路径上，在某些设计中还负责授权操作，因此必须像其他关键服务一样进行精心设计。
- 策略检查的运行速度必须足够快，以免影响请求延迟；同时策略服务本身也需要具备冗余机制。
- 每个提供商的价格数据必须保持最新，并进行缓存；批量处理和推理所需的令牌数量也必须准确统计，这样才能确保费用控制的可信度。
另一个成本在于组织层面。中央平台团队可以让安全默认设置轻松实现，但过度的控制措施会拖慢产品团队的工作效率。从可视化监控、在警告模式或影子模式下测试新策略、衡量实际效果，到仅在风险确实存在时才进行彻底阻断，这样的流程能够缓解这一问题。该机制应避免重复工作，同时不能变成一种无人能绕过、调试或安全修改的封闭系统。
管控机制不应擅自决定最终行动
防护措施分为两种。模式规则适用于结构化的敏感信息和标识符，而基于模型的检测器则能处理更复杂的类别，如非结构化的个人数据、越狱尝试或真实性验证等问题。这两种方法都没有完美之处，且基于模型的检测属于概率性判断，因此可能会出现误报和漏报。
一个合理的处理原则是：内容检测虽能降低风险，但绝不能成为阻止智能体产生不良后果的唯一控制手段。
- 退款限额最好通过代码来实现，而非依赖分类器。
- 生产环境部署时应进行授权检查。
- 高风险操作可能需要人工审批。
- 权限设置应有所限制，确保智能体不会超出其任务所需范围，即便防护措施存在疏漏。
该框架也以相同方式设定边界：相关操作依赖于确定的限制条件或人类审批，而非仅依靠内容检测。问题在于如何在识别出危险意图与遏制危险能力之间找到平衡。OWASP关于过度自主性的指导也得出了相同结论，建议尽量减少工具的功能与权限，将授权机制置于下游系统中实施，而非交由模型自行判断。这两层措施都是必不可少的。
监控与保障
一旦将策略决策纳入追踪流程，溯源功能就会变得极为有用。
- 被拒绝的模型请求会显示是哪项支出策略触发了拦截。
- 内容屏蔽事件会表明应用了哪个版本的策略，同时不会暴露敏感信息。
- 工具审批记录会与它所管控的操作相关联。
评估不仅可以判断模型的准确性，还可以测试在路由变更后较小模型是否仍能保持质量、裁剪上下文是否能在不影响结果的前提下降低成本、审查策略是否会产生过多误报，以及新的备用方案是否仍与原有策略等效。
这些要素共同构成了五部分循环：治理层面负责确定所有权、风险与策略；决策层面负责选择路由、处理升级及故障转移；保护层面在各个边界执行约束；观察层面用于衡量行为与策略效果；保障层面则负责保留历史记录并测试变更。仅仅部署规则并不能完成任务，只有当能够明确指出是哪条规则被执行、它做出了什么决策、随后发生了什么，以及系统变更后控制措施是否仍能正常工作时，任务才算完成。
这对代理架构意味着什么
无论选择哪种网关，生产环境中的代理都需要一个运行时控制架构。中央模型网关是管理成本、服务提供商选择、数据脱敏、速率限制及备用方案的最佳场所，它能够在不影响每个应用程序的情况下实现模型选项的灵活配置。而受管控的代理仍然需要以下各层：
- 对工具操作的授权及固定限制，
- 关于MCP服务器的信任决策以及数据输出规则，
- 协作代理之间最小化的上下文信息与经过验证的身份，
- 对可能带来严重后果的操作进行审批或限制，
- 每个决策背后都可追溯的策略来源。
在处理退款请求时，模型仍可进行推理，代理也可执行操作。该架构不再要求模型在提示词中包含整个治理流程。所有重要的边界都在跨越之前就得到了解答：
- 谁在发起请求？
- 哪些数据正在传输，传输到何处？
- 允许消耗多少工作量？
- 允许使用哪些模型和工具？
- 如果首选路径出现故障，应采取什么措施？
- 是否需要人工审批？
- 是哪个政策版本做出了该决策？
这正是拥有AI策略与拥有受治理的代理之间的区别。