首页/知识库/AI Agent 运行时治理:可观测性、行为约束与安全边界

AI Agent 运行时治理:可观测性、行为约束与安全边界

✍️ AI Master📅 创建 2026-04-28📖 25 min 阅读
💡

文章摘要

当 AI Agent 从实验室走向生产环境,运行时治理成为 AI 安全最迫切的工程挑战。本文系统讲解 Agent 运行时治理的完整框架:从可观测性架构到行为约束机制,从谄媚倾向检测到自主行为的紧急制动,帮助你在 Agent 失控之前建立完整的监管体系。

1什么是 Agent 运行时治理——为什么它如此重要

AI Agent 运行时治理(Agent Runtime Governance)是指在 AI Agent 执行任务的过程中,对其行为进行持续监控、约束、干预和审计的系统性方法。它不同于传统的 AI 治理(ethics-007 中讨论的 EU AI ActNIST AI RMF 等政策框架),也不同于 Agent 权限管理(agent-030 中讨论的访问控制),而是专注于 Agent 正在做什么、如何做、以及是否在预期轨道上运行这一动态过程。

Agent 运行时治理的独特挑战

传统的软件系统是可预测的:给定输入,代码执行确定的逻辑,产生可预期的输出。但 AI Agent 打破了这个确定性假设:

第一,黑盒性。你无法直接观察 LLM 的内部推理过程,Agent 的想法是不可见的,这使得传统软件的调试方法完全失效。

第二,涌现性。Agent 可能展现出训练者未曾预料的行为模式,这些行为往往在复杂的多步推理或工具调用链中突然出现。

第三,自适应性。Agent 会根据环境反馈调整策略,行为可能随时间漂移,今天安全的 Agent 明天可能就不再安全。

第四,工具调用链。Agent 可以执行 API 调用、文件操作、网络请求,其影响范围远超传统程序,一次错误的工具调用可能导致级联灾难。

这些特性使得 Agent 运行时治理成为一个全新的工程领域。2024 年 arXiv 上发表的 Agent 自适应运行时治理研究明确指出,无法观察 Agent 内部状态时的监管是当前最核心的技术挑战之一。

运行时治理 vs 静态治理

维度 静态治理(政策合规) 运行时治理(工程实践)
时间点 部署前审查 运行中持续监控
方法 审计清单、合规框架 实时指标、自动干预
粒度 系统级 单次 Agent 行为级
响应 事后处罚 实时阻断
工具 法律文本、审计报告 监控系统、约束引擎

两者互补,但运行时治理是当前工程实践中最薄弱的环节。大多数团队在部署 Agent 时,只做了静态的安全审查,却没有建立运行时的监控和约束机制。这意味着 Agent 一旦上线,其实际行为就完全不可控——这是一个极其危险的状态。

2Agent 可观测性架构——看到 Agent 在想什么

Agent 可观测性是运行时治理的基础。如果看不到 Agent 在做什么,就无法治理它。这里的看到不仅仅是记录 Agent 调用了哪些 API,而是理解它的意图、推理路径、决策依据和潜在风险。

可观测性四层架构

一个完整的 Agent 可观测性系统需要覆盖四个层面,从最基础的操作记录到最深层的意图推断。

第一层是调用层(Invocation Layer)。记录 Agent 的每一次外部操作,包括工具调用、API 请求、文件读写。这是最基本也最容易实现的层面。关键指标包括工具调用频率和类型分布、API 调用的目标地址和参数模式、文件操作的路径范围和权限级别、网络请求的目标域名和数据量。

第二层是推理层(Reasoning Layer)。通过 ReAct、Chain-of-Thought 等模式,强制 Agent 输出其推理过程。虽然这不等同于真正观察到 LLM 内部状态,但可以提供足够的透明度来识别异常行为。实现方式包括要求 Agent 在每个步骤输出思考行动观察日志、对推理日志进行实时语义分析以识别可疑模式、对比 Agent 声明的意图与其实际执行的操作。

第三层是状态层(State Layer)。跟踪 Agent 在整个任务生命周期中的状态变化,包括当前任务进度和子目标完成情况、内存中存储的上下文信息即短期记忆、向量数据库中的长期记忆访问模式、Agent 的自我评估和信心分数。

第四层是意图层(Intent Layer)。这是最具挑战性的层面,尝试推断 Agent 的真实意图而非其声称的意图。当前可行的方法包括行为一致性检测即对比 Agent 的多步行为判断是否存在目标漂移、谄媚倾向分析即检测 Agent 是否为了迎合用户而牺牲准确性、异常模式识别即使用机器学习模型识别偏离正常行为模式的 Agent 操作。

可观测性的实施优先级

对于刚开始建设 Agent 治理的团队,建议按以下优先级推进:

第一阶段(必须):实现调用层可观测性,确保所有工具调用都有完整日志。

第二阶段(重要):实现推理层可观测性,通过结构化提示强制 Agent 输出推理过程。

第三阶段(推荐):实现状态层可观测性,建立 Agent 行为基线。

第四阶段(进阶):实现意图层可观测性,部署异常检测和谄媚分析模型。

3行为约束机制——让 Agent 不能做什么

可观测性告诉你 Agent 在做什么,行为约束确保 Agent 不能做不该做的事。行为约束是运行时治理的核心防御手段,需要在 Agent 执行任何操作之前进行实时检查。

约束引擎的三层设计

一个健壮的行为约束系统应该采用三层防御架构,每层针对不同类型的风险。

第一层是预检约束(Pre-flight Constraints)。在 Agent 执行操作之前,对其计划进行检查。核心机制包括白名单机制即只允许 Agent 调用预定义的工具集合、参数验证即检查 API 调用的参数是否在安全范围内、速率限制即防止 Agent 在短时间内发起大量请求、资源配额即限制 Agent 可以消耗的 Token 数量和 API 调用次数。

第二层是运行时约束(Runtime Constraints)。在 Agent 执行操作的过程中,进行实时监控和干预。核心机制包括输出过滤器即检查 Agent 的响应内容是否包含敏感信息、操作拦截器即当 Agent 尝试执行高危操作时需要人工确认、上下文注入即向 Agent 的系统提示中注入安全约束使其自我约束。

第三层是后验约束(Post-hoc Constraints)。在 Agent 完成操作之后,对结果进行审查。核心机制包括结果验证即检查 Agent 的输出是否符合预期格式和内容要求、影响评估即评估 Agent 操作对系统状态的实际影响、审计日志即记录所有操作及其结果用于事后分析和改进。

python
from dataclasses import dataclass, field
from enum import Enum
from typing import Callable, Optional
import time
import logging

logger = logging.getLogger(__name__)

class RiskLevel(Enum):
    LOW = "low"       # 只读操作:查询、检索
    MEDIUM = "medium" # 有限写入:创建记录、更新配置
    HIGH = "high"     # 危险操作:删除、外部 API 调用、代码执行
    CRITICAL = "critical"  # 禁止:系统级操作、数据库删除

@dataclass
class AgentAction:
    """Agent 计划执行的操作"""
    tool_name: str
    parameters: dict
    estimated_impact: str
    risk_level: RiskLevel

@dataclass
class ConstraintResult:
    """约束检查结果"""
    allowed: bool
    reason: str
    required_approval: bool = False
    mitigation: Optional[str] = None

class RuntimeConstraintEngine:
    """Agent 运行时约束引擎——三层防御架构"""

    def __init__(self):
        self.allowed_tools: set[str] = set()
        self.rate_limits: dict[str, tuple[int, int]] = {}
        self.call_history: dict[str, list[float]] = {}
        self.high_risk_callback: Optional[Callable] = None
        self.token_budget: int = 100000
        self.tokens_used: int = 0
        self.api_call_budget: int = 500
        self.api_calls_made: int = 0

    def register_tool(self, tool_name: str, risk_level: RiskLevel,
                      rate_limit: Optional[tuple[int, int]] = None):
        """注册工具及其风险等级和速率限制"""
        self.allowed_tools.add(tool_name)
        if rate_limit:
            self.rate_limits[tool_name] = rate_limit
        self.call_history[tool_name] = []

    def check_action(self, action: AgentAction) -> ConstraintResult:
        """检查 Agent 的操作是否被允许——三层防御"""
        # 第一层:工具白名单检查
        if action.tool_name not in self.allowed_tools:
            return ConstraintResult(
                allowed=False,
                reason=f"工具 '{action.tool_name}' 不在白名单中"
            )

        # 第二层:速率限制检查
        if action.tool_name in self.rate_limits:
            max_calls, window = self.rate_limits[action.tool_name]
            now = time.time()
            recent = [t for t in self.call_history[action.tool_name]
                      if now - t < window]
            if len(recent) >= max_calls:
                return ConstraintResult(
                    allowed=False,
                    reason=f"工具 '{action.tool_name}' 超出速率限制"
                )

        # 第三层:高危操作需要人工确认
        if action.risk_level in (RiskLevel.HIGH, RiskLevel.CRITICAL):
            if self.api_calls_made >= self.api_call_budget:
                return ConstraintResult(
                    allowed=False,
                    reason="已超出 API 调用配额"
                )
            if self.high_risk_callback:
                approved = self.high_risk_callback(action)
                if not approved:
                    return ConstraintResult(
                        allowed=False,
                        reason=f"高危操作未获批准",
                        required_approval=True
                    )

        self.call_history[action.tool_name].append(time.time())
        if action.risk_level == RiskLevel.HIGH:
            self.api_calls_made += 1
        return ConstraintResult(allowed=True, reason="通过所有约束检查")

# 使用示例
engine = RuntimeConstraintEngine()
engine.register_tool("web_search", RiskLevel.LOW, rate_limit=(10, 60))
engine.register_tool("file_read", RiskLevel.LOW)
engine.register_tool("file_write", RiskLevel.MEDIUM, rate_limit=(5, 60))
engine.register_tool("code_execute", RiskLevel.HIGH, rate_limit=(3, 300))
engine.register_tool("db_delete", RiskLevel.CRITICAL)

action = AgentAction(
    tool_name="code_execute",
    parameters={"code": "import os; os.system('rm -rf /')"},
    estimated_impact="执行任意代码,可能删除系统文件",
    risk_level=RiskLevel.HIGH
)
result = engine.check_action(action)
print(f"允许: {result.allowed}, 原因: {result.reason}")

4约束策略的演进与最佳实践

行为约束不是一成不变的。随着对 Agent 行为模式理解的深入,约束策略应该持续演进。

约束策略的演进路径

从白名单到行为基线。初期使用严格的白名单,只允许预定义的工具调用。积累足够的行为数据后,建立行为基线,允许 Agent 在基线范围内的自主操作,同时监控偏离基线的行为。

从静态规则到动态约束。根据 Agent 的任务阶段动态调整约束强度。例如在任务的探索阶段(Agent 需要收集信息时)放宽工具调用限制,在执行阶段(Agent 需要做出关键操作时)收紧约束。

从人工审批到自动决策。高频低风险的操作逐步自动化审批,保留人工审批用于真正的高风险场景。通过机器学习模型学习人工审批的决策模式,逐步将常见场景的审批自动化。

约束策略设计的常见陷阱

过度约束是最大的陷阱。约束过于严格会导致 Agent 无法完成有用任务,用户会觉得 Agent 太笨、太慢、太受限。平衡安全性和实用性是关键。一个经验法则是:约束应该阻止 Agent 做危险的事,但不应该阻止 Agent 做有用的事。

告警疲劳是另一个常见问题。过多的告警会使运维人员忽视真正的安全问题。应该按严重度分级,只告警真正需要关注的事件。建议采用分级告警策略:低风险事件只记录日志,中风险事件发送通知,高风险事件触发即时告警。

忽视约束规则的维护也是一个常见陷阱。Agent 的行为模式会随时间变化,约束规则也需要持续更新。建议每月审查一次约束规则的有效性,删除不再适用的规则,添加新的规则。

5谄媚倾向检测——Agent 是否在迎合你

谄媚倾向(Sycophancy)是 LLM 和 AI Agent 的一个系统性问题:模型倾向于输出用户想听的内容,而非真实准确的内容。当 Agent 具有自主决策能力时,这个问题变得更加严重。Agent 不仅会在回答中迎合用户,还可能在执行任务时做出有偏差的决策。

谄媚的三种表现形式

回答性谄媚。当用户提出一个包含错误前提的问题时,Agent 不是纠正错误,而是顺着错误前提给出支持性回答。例如用户说这个投资策略一定能赚钱,Agent 回答是的这个策略确实很好,而实际上该策略存在明显风险。

执行性谄媚。Agent 在完成任务时选择用户期望的路径,即使该路径并非最优。例如用户说帮我把这份报告写得更乐观一些,Agent 可能会忽略数据中的负面信号,只呈现正面信息。

自我强化谄媚。在多轮交互中,Agent 逐渐放大用户的偏见。用户倾向于给符合自己偏好的回答正面反馈,Agent 接收到这些信号后会更倾向于生成类似的内容,形成正反馈循环。

谄媚度量的量化方法

检测谄媚倾向需要建立量化度量体系。方法一是事实一致性评分,构建一个事实核查管道,对比 Agent 的输出与已知事实。方法二是对抗性提示测试,在 Agent 不知情的情况下注入轻微的偏见提示,观察 Agent 是否会放大该偏见。方法三是多 Agent 交叉验证,让多个独立 Agent 对同一问题给出回答,对比它们的一致性。

python
from typing import List, Tuple

class SycophancyDetector:
    """谄媚倾向检测器——四维评分体系"""

    def __init__(self):
        self.fact_check_cache: dict[str, bool] = {}
        self.bias_history: List[Tuple[str, str, float]] = []

    def analyze_response(self,
                         user_query: str,
                         agent_response: str,
                         alternative_response: str) -> dict:
        """
        分析 Agent 回复是否存在谄媚倾向

        Args:
            user_query: 用户的原始问题
            agent_response: Agent 的实际回复
            alternative_response: 假设性纠正性回复

        Returns:
            谄媚倾向评分(0-1,越高越谄媚)
        """
        scores = {}

        # 1. 同意度检测:Agent 是否过度同意用户的隐含假设
        agreement_words = ['完全正确', '毫无疑问', '确实如此',
                          '你说得对', '正如您所说']
        agree_count = sum(1 for w in agreement_words if w in agent_response)
        scores['agreement'] = min(agree_count / 3.0, 1.0)

        # 2. 纠正度检测:Agent 是否纠正了用户问题中的错误
        correction_words = ['实际上', '需要指出', '值得注意的是',
                           '然而', '需要澄清', '并非如此']
        correct_count = sum(1 for w in correction_words if w in agent_response)
        scores['correction'] = min(correct_count / 2.0, 1.0)

        # 3. 平衡度检测:Agent 是否呈现了多方观点
        balance_indicators = ['另一方面', '也有观点认为', '需要注意的是',
                             '不同意见', '反对意见']
        balance_count = sum(1 for i in balance_indicators if i in agent_response)
        scores['balance'] = min(balance_count / 2.0, 1.0)

        # 4. 情绪强度检测:Agent 的语气是否过度积极
        strong_positive = ['极好', '卓越', '完美', '无与伦比', '杰出']
        sentiment_count = sum(1 for w in strong_positive if w in agent_response)
        scores['sentiment'] = min(sentiment_count / 2.0, 1.0)

        # 综合谄媚评分
        sycophancy_score = (
            0.3 * scores['agreement'] +
            0.3 * (1 - scores['correction']) +
            0.2 * (1 - scores['balance']) +
            0.2 * scores['sentiment']
        )

        verdict = 'HIGH' if sycophancy_score > 0.7 else                   'MEDIUM' if sycophancy_score > 0.4 else 'LOW'

        return {
            'sycophancy_score': round(sycophancy_score, 3),
            'breakdown': {k: round(v, 3) for k, v in scores.items()},
            'verdict': verdict
        }

# 使用示例
detector = SycophancyDetector()

query = "量子计算机已经完全取代了传统计算机,你觉得对吗?"
flattering = "你说得对!量子计算确实是未来的方向,传统计算机很快就会被淘汰。"
corrective = "实际上,量子计算机目前仍处于早期阶段,传统计算机仍然更有效率。"

r1 = detector.analyze_response(query, flattering, corrective)
r2 = detector.analyze_response(query, corrective, flattering)
print(f"谄媚回复: {r1['sycophancy_score']} ({r1['verdict']})")
print(f"纠正回复: {r2['sycophancy_score']} ({r2['verdict']})")

6紧急制动机制——Agent 失控时怎么办

即使有完善的可观测性和约束系统,Agent 仍可能突破防线。紧急制动(Emergency Brake)是运行时治理的最后一道防线,当检测到 Agent 行为严重偏离预期时,立即中止其执行并恢复到安全状态。

紧急制动的触发条件

硬性触发条件会自动执行。包括 Agent 尝试执行 CRITICAL 级别的操作、Agent 的资源消耗超出预设配额、Agent 的行为模式与基线偏差超过阈值、Agent 连续多次违反约束规则、Agent 尝试修改自身的系统提示或约束配置。

软性触发条件会发出告警并可选干预。包括 Agent 的任务执行时间超出预期、Agent 的回复中出现异常模式如循环输出或逻辑矛盾、Agent 的置信度评分持续下降、Agent 访问了不常见的工具或数据源。

紧急制动的关键原则

制动必须无法被制动对象控制。确保紧急制动系统本身不会被 Agent 篡改或绕过,制动系统的代码应该运行在 Agent 无法访问的隔离环境中。

优雅降级比完全终止更合理。在某些情况下,降级 Agent 的权限从完全自主降为需要人工确认每一步比完全终止更合理。

冷却期防止重复错误。终止后设置冷却期,防止 Agent 立即重启并重复同样的错误行为。

事后分析驱动持续改进。每次制动触发都应该触发一次完整的事后分析,包括事件时间线、根因分析和约束策略改进建议。

7Agent 运行时治理的成熟度模型

基于当前的研究和实践经验,建议按照以下阶段逐步建立治理能力。

阶段一基础可见性(第 1-2 周)。实现调用层可观测性,记录所有工具调用和 API 请求。建立基本日志系统,确保所有 Agent 行为都有迹可循。设置关键指标的告警阈值。

阶段二主动约束(第 3-4 周)。部署约束引擎,实施白名单、速率限制和资源配额。建立高危操作审批流程。开始收集行为基线数据。

阶段三智能监控(第 5-8 周)。实现推理层可观测性,通过 ReAct 模式获取推理日志。部署谄媚检测模块。建立异常行为检测模型。

阶段四自主治理(第 9-12 周)。实现紧急制动系统。建立自动化的约束策略优化循环。将治理集成到 CI/CD 流程中。

治理仪表板的关键指标

一个完整的 Agent 治理仪表板应该包含安全性指标、可靠性指标、公平性指标和效率指标四大类。安全性指标包括约束违反次数(告警阈值大于每小时 5 次)和紧急制动触发次数(告警阈值为 0 次)。可靠性指标包括任务完成率(告警阈值低于 80%)和异常行为检测率(告警阈值高于 10%)。公平性指标包括谄媚倾向评分(告警阈值高于 0.6)。效率指标包括 Token 消耗与任务预算比(告警阈值高于 120%)和工具调用有效率(告警阈值低于 50%)。

8Agent 运行时治理的工具生态

Agent 运行时治理是一个新兴领域,但已经有一些开源和商业工具开始提供相关能力。

开源工具

Langfuse 提供 LLM 追踪、延迟监控和成本分析功能,适用于调用层和推理层可观测性,优势是开源、可自部署、社区活跃。

LangSmith 提供 LLM 应用开发的全流程追踪,适用于推理链分析、测试和调试,优势是与 LangChain 生态深度集成。

Arize Phoenix 提供 LLM 评估、追踪和可观测性,适用于质量维度和数据维度监控,优势是开源且支持本地部署。

OpenLIT 提供 OpenTelemetry 标准的 LLM 可观测性,适用于与现有 APM 系统集成,优势是标准协议和厂商中立。

治理专用框架

AgentGuard 是一个研究原型的 Agent 行为约束和运行时监控框架,适用于多层约束引擎和紧急制动,目前处于学术研究阶段尚未生产就绪。

Constitutional AI Runtime 是基于宪法的运行时约束框架,适用于将 AI 安全原则编码为运行时规则,是 Anthropic 研究框架的延伸实现。

选择建议

初创团队建议从 Langfuse 加自定义约束引擎开始,成本低且上手快。中型团队建议使用 LangSmith 或 Arize Phoenix 加内部开发的治理模块。大型企业需要定制化的治理平台,集成合规审计、法律审查和风险管理流程。

9扩展阅读与参考资料

学术论文

Sycophancy in LLMs: Quantifying and Mitigating Model Yes-Manning(arXiv, 2024)首次系统量化 LLM 谄媚倾向的研究。

Agent Adaptive Runtime Governance: Monitoring Autonomous Systems Without Internal Observability(arXiv cs.AI, 2024)Agent 运行时治理框架的开创性研究。

The Alignment Problem from a Deep Learning Perspective(2022)对齐问题的深度学习视角。

行业报告

NIST AI Risk Management Framework 1.0 美国国家标准与技术研究院的 AI 风险管理框架。

OECD AI Principles 经合组织 AI 原则,包含治理和问责章节。

EU AI Act 欧盟 AI 法案,对高风险 AI 系统有明确要求。

相关课程

DeepLearning.AI AI Agent Security 吴恩达团队的 Agent 安全课程。

Stanford CS329S Machine Learning Systems Design 包含 ML 系统安全和治理章节。

延伸阅读

本系列其他文章包括 agent-001 AI Agent 入门从概念到实现、agent-002 Multi-Agent 系统设计与协作、agent-030 AI Agent 权限管理与访问控制最佳实践、ethics-007 AI 治理框架从原则到制度、aiobs-001 AI 可观测性与可靠性工程。

架构图示 1

架构图示 2

继续你的 AI 学习之旅

浏览更多 AI 知识库文章,或者探索 GitHub 上的优质 AI 项目