Agent 人工介入与升级策略工程 2026：从触发边界、证据包到安全接管的闭环架构

一、问题的提出：为什么生产 Agent 需要人工介入

大模型驱动的自主 Agent 在生产环境中运行时会遇到模型能力边界无法处理的场景：涉及法律合规判断、需要人工确认的高风险操作、外部系统响应异常超出 Agent 推理范围、或者用户明确要求人工接管。这些场景的共同特征是：Agent 的不确定性超出了系统预设的置信阈值，但系统不能简单地 fail-close（直接拒绝），因为许多业务流程对可用性有严格要求。如何设计一套可靠、可审计、可量化的人工介入（Human-in-the-Loop, HITL）与升级（Escalation）策略，是 2026 年 Agent 生产落地的核心技术挑战之一。

传统软件系统的升级策略通常由业务规则引擎驱动：满足条件 → 触发升级 → 人工处理 → 恢复自治。这种模式在 Agent 场景下面临三个根本性的新问题。第一，Agent 的输出是概率性的，不存在明确的"正确/错误"二元判断——同一个工具调用结果在不同上下文下可能需要不同处置。第二，Agent 的决策链路通常是多步的，升级点不仅要在最终结果层设置，还需要在中间推理步骤中埋点，否则 Agent 可能在错误的方向上消耗大量 token 后才被人工发现。第三，人工介入的代价是昂贵的（人工时间成本、延迟增加、用户体验降级），升级策略必须与业务风险和成本效益联合优化，而不是无差别地"遇到不确定就升级"。

本文从工程实战的角度，系统化地讨论 Agent 人工介入与升级策略的设计、实现与运维闭环。我们将建立一个覆盖升级触发器设计、证据包构造、人工工作台、状态机与租约、并发安全、权限与审批、生产监控与成本优化的全链路工程框架，帮助 SRE 和平台工程师在生产环境中构建可靠的 Agent + 人工混合系统。

二、形式化模型：升级决策的不确定性量化

2.1 升级决策的四元组

将 Agent 升级决策形式化为一个四元组 $(S, A, U, T)$：

• $S$（状态空间）：Agent 当前世界模型的 belief state，表示为关于环境变量和行动结果的概率分布。
• $A$（可用行动空间）：Agent 可执行的全部行动集合，包含纯 Agent 行动和需要人工审批/介入的行动子集。
• $U$（不确定性度量）：对当前 belief state 的置信度度量，可以是熵（entropy）、互信息（mutual information）或任务特定的置信分数。
• $T$（升级触发器）：布尔函数 $T: (S, A, U) \rightarrow \{\text{AGENT}, \text{ESCALATE}\}$，当 $U$ 超过阈值 $\theta$ 或 $S$ 落入预设的高风险区域时返回 ESCALATE。

升级触发器的核心设计难点在于如何量化 $U$。单一指标（如输出的 logprob）不足以捕获所有需要人工介入的场景。更实用的做法是构造一个多维不确定性向量：

$U = (u_{\text{conf}}, u_{\text{drift}}, u_{\text{risk}}, u_{\text{cost}})$

其中 $u_{\text{conf}}$ 是模型对当前行动的置信度（来自 logprob 或内部一致性检测），$u_{\text{drift}}$ 是对话/推理轨迹中不确定性随步数的累积漂移（通过 KL-divergence 或 embedding 距离度量），$u_{\text{risk}}$ 是业务层面的风险评分（财务损失、合规风险、生命安全等），$u_{\text{cost}}$ 是人工介入的直接成本（人力时间、延迟）。触发条件为：

$\text{ESCALATE} \Leftrightarrow \exists i: u_i > \theta_i \quad \text{或} \quad \sum_i w_i u_i > \theta_{\text{composite}}$

权重 $w_i$ 由业务方配置，反映组织对不同维度风险的真实偏好。

2.2 升级策略的类型

基于上述框架，主流的升级策略可以分为三种范式：

确定性阈值触发（Deterministic Threshold）：预设固定阈值，当任一指标超过阈值时立即触发升级。优点是实现简单、可解释性强；缺点是无法适应任务难度的分布差异——简单任务的高置信度阈值会造成过度升级，复杂任务的低阈值可能漏掉真正风险。

自适应阈值触发（Adaptive Threshold）：阈值随任务难度、上下文长度或历史升级率动态调整。典型实现是用滑动窗口统计最近 $N$ 次同类任务的升级率，如果升级率偏高则自动收紧阈值，反之放松。优点是长期运营成本更低；缺点是收敛需要时间，且在任务分布突变时可能失效。

基于采样的不确定性估计（Sampling-based Uncertainty）：使用多次采样（如 temperature decoding 或 beam search）估计输出分布的熵，当熵超过阈值时触发升级。OpenAI 的 Agents SDK 和 Anthropic 的 Claude Agent SDK 均支持内置的 uncertainty 估计接口。优点是直接反映模型对输出的真实分歧程度；缺点是计算成本翻倍（$N$ 次推理），且对某些确定性任务不公平。

在工程实践中，混合策略最为常见：先用轻量级指标（$u_{\text{conf}}$）做第一层过滤，对可疑案例再用重采样方法做二次确认。这种级联设计在工程成本和召回率之间取得平衡。

三、升级触发器与风险分层

3.1 风险分层的工程设计

将 Agent 操作按业务风险分为四个层级（L0 到 L3），每个层级对应不同的触发条件和介入深度：

L0（低风险，自主执行）：不涉及外部系统写入、不产生不可逆影响、成本极低的操作。例如查询数据库只读接口、计算聚合指标、生成内部日志。Agent 无需任何人工审批，自主权完整。

L1（中等风险，轻量审批）：涉及数据读取但可能影响用户体验，或产生一定成本的操作。例如发送通知邮件、生成报告文档、执行对数据库的写操作（但可回滚）。触发条件通常是 $u_{\text{conf}}$ 低于 0.7 或 $u_{\text{risk}}$ 超过预设阈值。介入方式是异步审批——Agent 继续执行但人工可在事后审计和干预。

L2（高风险，强制暂停）：涉及财务交易、合规敏感数据、或不可逆状态变更的操作。例如修改用户权限、转账操作、删除数据。触发条件是 $u_{\text{conf}}$ 低于 0.5 或 $u_{\text{risk}}$ 超过高阈值或检测到罕见工具调用组合。介入方式是同步阻塞——Agent 执行暂停，等待人工明确批准或拒绝。

L3（极高风险，禁执行）：涉及生命安全、法律合规强制要求的操作，Agent 根本不应具备执行能力。例如医疗诊断建议（无资质）、司法判决、法律文件签署。此类操作在工具注册阶段即被禁用，任何触发尝试立即上报并记录。

3.2 触发器的工程实现

升级触发器的实现需要在 Agent 执行循环中插入中间层检查点（checkpoint），而非仅在最终步骤后检查。以 LangGraph 为例，一个典型的带升级检查点的执行循环如下：

from langgraph.graph import StateGraph
from langgraph.prebuilt import ToolNode
from typing import TypedDict

class AgentState(TypedDict):
    messages: list
    belief_state: dict
    escalate: bool
    escalation_reason: str

def uncertainty_check(state: AgentState) -> AgentState:
    conf = state["belief_state"].get("confidence", 1.0)
    risk = state["belief_state"].get("risk_score", 0.0)
    
    if conf < 0.7 or risk > 0.6:
        state["escalate"] = True
        state["escalation_reason"] = (
            f"confidence={conf:.2f} below 0.7 or "
            f"risk={risk:.2f} above 0.6"
        )
    return state

# 构建带升级检查点的图
graph = StateGraph(AgentState)
graph.add_node("uncertainty_check", uncertainty_check)
graph.add_node("agent", tool_node)  # 原有 agent 节点

graph.add_edge("__start__", "uncertainty_check")
graph.add_conditional_edges(
    "uncertainty_check",
    lambda s: "human_review" if s.get("escalate") else "agent",
    {
        "human_review": "human_review_node",
        "agent": "agent",
    }
)

关键实现细节：检查点必须在每次工具调用后重新评估，因为工具的返回值会显著改变 Agent 的 belief state。例如，Agent 调用外部 API 获取数据，API 返回错误码时置信度可能骤降，此时应该立即触发升级检查，而非等待当前推理阶段完成。

四、证据包与人工工作台

4.1 证据包的构造

人工介入的价值取决于审批者获取信息的质量。如果人工只能看到"模型建议你批准这个操作"的摘要，而无法了解决策的完整上下文，审批质量将大打折扣。证据包（Evidence Package） 是 Agent 向人工审批者提供的结构化信息载体，包含以下核心组件：

推理轨迹（Reasoning Trace）：Agent 的完整思维链，以分层结构呈现。包括：初始任务理解、子目标分解、工具选择理由、工具执行结果摘要、最终决策依据。推理轨迹不是原始的 token 序列，而是经过压缩和结构化的摘要视图。典型的压缩策略是保留关键决策节点的结论，省略中间试错过程。

不确定性报告（Uncertainty Report）：以可解释的方式呈现不确定性向量的各个分量。例如："置信度 0.65（低于阈值 0.7），主要因为工具调用结果中包含 3 个未知错误码；风险评分 0.8（超过阈值 0.6），因为该操作将修改用户角色权限。"

影响评估（Impact Assessment）：升级后若执行该操作，对系统的预期影响。包括：业务连续性影响（是否有 Plan B）、数据完整性影响（是否可回滚）、财务影响（预估费用或损失）、用户体验影响（延迟增加量）。

历史相似案例（Historical Cases）：检索过去 $N$ 次相似操作的处理记录，帮助人工审批者参考历史决策。如果历史上有 $80\%$ 的类似申请被批准，则可以作为参考但不应直接套用。

4.2 人工工作台的设计

人工审批工作台是审批者与 Agent 升级请求交互的前端界面。其设计需要在信息充分性与认知负载之间取得平衡。信息过少会导致审批质量下降，信息过多会造成审批疲劳（Alert Fatigue），反而增加系统风险。

一个实用的工作台信息架构分为三层：概览层展示任务类型、风险等级、核心不确定性指标和建议操作，审批者可在 10 秒内做出 L0-L1 级别决策；详情层展示推理轨迹、不确定性报告和影响评估，支持 L2 级别决策；深挖层提供原始工具调用日志、系统内部状态快照和历史案例链接，供复杂 L2 或 L3 决策使用。

工作台的响应时效设计也很关键。对于 L1 异步审批，系统应设置 SLO（如 4 小时内响应）并通过 Slack/邮件/飞书推送提醒；对于 L2 同步阻塞，需要更短的 SLO（如 15 分钟），并在超时后触发升级提醒或值班人员通知。超时机制的设计必须与业务方协商确定：超时后是自动拒绝、自动放行还是转给值班主管，不同选择对应不同的风险模型。

五、状态机、租约与并发接管

5.1 升级状态机

Agent 升级涉及多个状态的流转，清晰的状态机定义是防止"升级状态丢失"和"死锁"的基础。一个完整的状态机包含以下状态：

AGENT_RUNNING：Agent 正在自主执行推理和工具调用，此时处于完全自治状态。

PENDING_HUMAN_REVIEW：升级请求已发出，人工审批者正在处理。此时 Agent 的执行线程应被阻塞（L2 同步场景）或挂起（L1 异步场景）。阻塞与挂起的区别在于：阻塞时 Agent 持有执行上下文锁，其他并发的同类请求必须等待；挂起时 Agent 释放上下文，其他请求可以推进但不能对同一资源冲突。

HUMAN_APPROVED：人工批准，Agent 恢复执行或完成该操作。状态机需要记录审批者身份和审批时间戳，用于后续审计。

HUMAN_REJECTED：人工拒绝，Agent 收到明确的拒绝原因和替代建议。Agent 应将拒绝原因纳入 belief state，重新规划路径。

ESCALATION_TIMEOUT：升级请求超时无人响应。根据预设策略自动拒绝、自动降级执行或升级给主管。

AGENT_RESUMING：Agent 在人工介入完成后恢复执行。需要正确恢复中断点的上下文，包括对话历史、中间变量和工具调用状态。

5.2 租约机制与并发安全

在多 Agent 或 Agent + 人工并发执行的场景下，必须处理**状态竞争（Race Condition）**问题。典型场景是：Agent A 和 Agent B 同时要对同一个资源（如用户账户、订单）执行冲突操作，Agent A 触发了人工审批但尚未完成，Agent B 也在进行中。此时如果缺乏租约（Lease）机制，可能导致以下问题：资源被两个 Agent 同时修改导致数据不一致，或者人工审批了 Agent A 的请求但 Agent B 在此之前已经修改了资源（审批依据已过时）。

租约机制的核心是在升级检查点对资源加锁，并在状态机中嵌入锁的租约超时逻辑：

import time
from contextlib import contextmanager

class EscalationLease:
    def __init__(self, resource_id: str, ttl_seconds: int = 900):
        self.resource_id = resource_id
        self.ttl = ttl_seconds
        self.leased_until = None
        self.leaseholder = None
    
    def acquire(self, holder: str) -> bool:
        if self.leased_until and time.time() < self.leased_until:
            if self.leaseholder == holder:
                # 续租
                self.leased_until = time.time() + self.ttl
                return True
            return False  # 被其他 holder 持有
        self.leaseholder = holder
        self.leased_until = time.time() + self.ttl
        return True
    
    def release(self, holder: str):
        if self.leaseholder == holder:
            self.leaseholder = None
            self.leased_until = None
    
    def is_valid(self) -> bool:
        return self.leased_until and time.time() < self.leased_until

当人工介入开始时，Agent 对操作涉及的资源加租约。租约的 TTL 需要平衡锁的持有时间和业务容忍延迟——对于金融交易类操作，TTL 可以短至 60 秒并支持自动续约；对于需要长时间人工审批的复杂操作，TTL 可以设为 15 分钟并支持审批者手动延长。

5.3 多 Agent 并发升级协调

在多 Agent 系统中，单个 Agent 的升级请求可能与其他 Agent 的操作产生依赖关系。例如，订单处理 Agent 和库存管理 Agent 同时需要人工审批，而它们的操作是互补的——订单批准了但库存不足会导致后续执行失败。处理这类问题需要升级协调器（Escalation Coordinator）。

协调器维护一个升级依赖图（Dependency Graph）：每个升级请求是图中的一个节点，如果两个操作涉及相关资源，则它们之间存在边。协调器在收到升级请求时，首先检查图中是否存在已有节点与新请求冲突。若存在冲突且新请求优先级更高（由业务方配置），则协调器可以撤回已有的低优先级升级请求，并通知其 Agent 重新规划。如果新请求优先级更低，则新请求进入等待队列，直到依赖节点完成。

这种基于图的协调机制比简单的互斥锁更灵活，因为它允许非冲突的并发升级，同时保证冲突升级的序列化。

六、工具权限、审批与安全边界

6.1 工具的分级权限体系

工具是 Agent 能力的边界。一个生产 Agent 系统需要建立工具分级权限（Tool Permission Hierarchy），明确每类工具需要的审批级别和执行约束。

权限体系的构建需要从能力（Capability） 和风险（Rish） 两个维度对工具进行矩阵评估。能力维度衡量工具的操作范围（如只读/可写/可删除/可跨租户），风险维度衡量工具错误使用时的潜在影响（如数据泄露/财务损失/合规违规/服务中断）。两个维度交叉后形成权限矩阵，如下表所示（高能力+高风险 = 必须 L2 审批）：

6.2 审批流的配置化管理

审批规则不应硬编码在 Agent 代码中，而应通过配置中心（Configuration Center） 进行管理。这样做的好处是：规则变更不需要重新部署 Agent，审计人员可以集中查看全平台的升级策略，规则可以按租户/场景差异化配置。

一个实用的配置结构示例：

escalation_policy:
  version: "2026.08"
  default_policy:
    confidence_threshold: 0.7
    risk_threshold: 0.6
    timeout_seconds: 900
  overrides:
    - name: "financial_transaction"
      tool_pattern: "transfer|payment|reconcile"
      confidence_threshold: 0.95
      risk_threshold: 0.3
      timeout_seconds: 300
      require_second_approver: true
    - name: "data_deletion"
      tool_pattern: "delete|drop|truncate"
      action: "FORBIDDEN"

这种配置化设计的工程实现需要注意：规则变更的事务性——当规则被更新时，正在进行中的升级审批应继续使用旧规则（避免审批到一半规则变了），新请求使用新规则；规则的版本化——每次规则变更应生成不可变版本，便于追溯和回滚。

6.3 安全边界：防止权限提升

Agent 人工介入系统中最严重的安全风险是权限提升（Privilege Escalation）：恶意或被攻击的 Agent 尝试通过升级机制获取超出其设计权限的操作能力。

主要攻击向量包括：触发器欺骗——Agent 通过构造特殊的工具返回值人为降低置信度，诱使系统触发不必要的升级，然后利用人工审批者的疏忽获取批准。防御策略是引入异常检测：如果某类操作的升级率长期偏高，或者置信度分布出现非自然的双峰（高置信和低置信都多、中间少），则触发规则审查。

审批会话劫持——攻击者试图在人工审批者不知情的情况下，在审批工作台中通过 XSS 或 CSRF 方式批准恶意请求。防御策略包括：审批会话绑定设备指纹和 IP 地址，审批前需要二次验证（OTP 或生物识别），所有审批操作带时间戳和客户端签名。

七、反馈回流、评测与成本优化

7.1 升级决策的反馈闭环

每次人工介入（批准或拒绝）都是对 Agent 能力边界的真实标注，应该回流到 Agent 的决策模型中形成持续学习闭环。反馈闭环的设计需要解决三个核心问题：标注质量——人工审批者的决策本身可能存在噪声（疲劳、不一致、个人偏好），需要引入交叉审批或专家审核机制过滤低质量标注；延迟问题——人工介入的结果可能在数小时后才返回，而此时 Agent 的上下文已经变化，需要用异步标注队列处理；反馈信号的稀疏性——L0 级别操作（无介入）占大多数，正负反馈严重不均衡，需要用优先采样策略确保模型在高风险场景下的学习。

一个实用的反馈回流架构如下：升级事件写入事件总线（Kafka/Pulsar），包含升级类型、人工决策、审批者 ID、时间戳、上下文摘要；标注消费者从总线读取事件，将标注数据写入特征存储（Feature Store）供模型训练使用；定期（如每周）触发模型微调任务，使用最新标注数据更新 Agent 的置信度模型。

7.2 升级效率的评测指标

运营人工介入系统需要一套清晰的指标体系，用于评估系统的效率和安全平衡。核心指标包括：

升级率（Escalation Rate）：$\text{ER} = \frac{\text{升级请求数}}{\text{总 Agent 操作数}}$。过高的升级率意味着 Agent 自主能力不足、人工成本上升；过低的升级率可能意味着升级阈值设置过高、系统处于危险的自负状态。

升级批准率（Approval Rate）：$\text{AR} = \frac{\text{批准数}}{\text{升级请求数}}$。高批准率（如 $>90\%$）可能表明升级阈值偏低或 Agent 置信度模型存在系统性偏差；低批准率（如 $<30\%$）可能表明升级触发器过于敏感或 Agent 规划存在方向性问题。

升级响应时间（Escalation Response Time）：从升级请求发出到人工完成审批的中位时间。这个指标直接影响 Agent 的阻塞时长，进而影响用户体验和系统吞吐量。SRE 应为其设置 P50/P95/P99 分位目标。

错误升级率（Erroneous Escalation Rate）：实际无需升级但被错误触发的比率。可以通过定期的人工审计（采样历史升级事件）来评估，理想值应低于 $5\%$。

7.3 成本优化：升级的 token 经济

每次人工介入的直接成本不仅是审批者的时间，还包括 Agent 在等待期间的token 消耗。在等待人工审批时，Agent 的上下文需要保持（不能释放），因此 LLM 的上下文窗口持续被占用。优化这一成本可以从以下角度入手：

上下文压缩：在等待人工响应时，Agent 可以主动压缩上下文窗口，保留最核心的推理轨迹和信念状态，丢弃中间试错步骤。一旦人工批准，Agent 可以从压缩点恢复。这需要 Agent 具备"摘要-恢复"的自我状态管理能力。

降级模型（Fallback Model）：在等待人工期间，Agent 可以切换到更小的降级模型（如 7B 参数）维持基本的上下文保持，从而降低 token 成本。审批完成后切回主模型。

异步流水线：对于 L1 异步审批，Agent 无需等待审批结果即可继续处理其他不冲突的任务，从而提高并发吞吐。状态机需要支持 Agent 在 L1 审批期间保持"部分阻塞"状态。

八、生产落地、故障复盘与反模式

8.1 实施路线图

在生产环境中落地人工介入系统，建议采用三阶段渐进式实施策略：

第一阶段（0-30 天）：可视化与基线。在不改变 Agent 行为的前提下，在现有 Agent 执行路径中插入升级检查点，记录所有"本应触发升级"但当前被静默处理的场景。同时建立人工审批工作台（可以是简陋的内部工具），让 SRE 团队熟悉升级流程。此阶段的目标是建立升级事件的数据基线，为后续阈值调优提供依据。

第二阶段（30-90 天）：策略激活与调优。基于第一阶段的数据，配置升级触发器的初始阈值。阈值应从保守（低升级率、高批准率）开始，逐步收紧。每周回顾升级指标，调整权重参数。此阶段的关键风险是阈值配置不当导致过多的假阳性升级或假阴性漏过，需要与业务方紧密协同。

第三阶段（90 天+）：自动化与优化。在升级数据积累到一定规模后，引入自动阈值调优（基于贝叶斯优化或强化学习）。逐步引入反馈回流机制，更新 Agent 的置信度模型。建立完整的 SLA 监控和告警体系。

8.2 常见故障复盘

案例一：升级触发器漏过导致数据事故。某电商 Agent 在处理退款请求时，工具返回了异常错误码（外部支付系统临时不可用），Agent 将错误码误判为"可忽略的网络抖动"并重试了 3 次，最终在用户不知情的情况下完成了退款操作。根因是升级触发器仅检查置信度，未对工具返回的异常模式做专项检测。修复方案是在工具调用结果解析器中增加异常模式匹配规则，当返回错误码属于高风险类别时，无论置信度如何都强制触发 L2 升级。

案例二：租约超时导致的状态不一致。某金融系统中的 Agent 申请了修改用户风险评级的租约，升级请求发出后人工审批者因休假未能及时响应，租约超时后系统自动释放锁。Agent 在未获批准的情况下因系统超时而退出了执行流程。一周后审批者返回并批准了该请求，但此时用户的风险评级已被其他并发的合规检查流程修改，状态已不一致。根因是升级状态机的完成事件与原操作之间缺乏条件依赖：批准操作应该依赖资源当前状态未变化。修复方案是引入乐观锁版本号，审批通过后需验证版本号未变。

8.3 反模式

反模式一：以"人工介入率"作为 Agent 能力考核指标。如果业务方将"人工介入率越低越好"作为 Agent 能力的考核 KPI，Agent 团队将面临道德风险——降低介入率的最简单方法是提高触发阈值，但这同时也降低了系统的安全边界。正确的考核指标应该是"有效升级率"（真正需要人工介入的事件被正确捕获的比例）和"错误升级率"（假阳性的比例）。

反模式二：审批流程作为"安全门"而非"改进信号"。将人工介入视为"Agent 能力不足的失败标志"，而不是"模型持续改进的信号"。这种认知导致团队过度关注压制升级数量，而忽视了升级事件中蕴含的模型改进机会。

反模式三：升级策略的"一刀切"配置。全平台使用同一套升级阈值，未按业务场景差异化配置。高风险金融业务和低风险内部工具使用相同的触发条件，要么前者过于宽松，要么后者过于严格。

九、30/60/90 天实施路线与结语

9.1 实施里程碑

第 0-30 天（奠基期）：

• 完成工具清单梳理，按能力和风险两个维度完成矩阵评估
• 在核心 Agent 执行路径中植入升级检查点（仅记录，不干预）
• 搭建基础审批工作台（飞书机器人或内部 Web 工具）
• 建立升级事件的日志和指标采集基础设施
• 定义初始升级阈值基线（保守配置）

第 31-60 天（激活期）：

• 激活升级触发器，启用 L0/L1 的自动执行和 L2 的同步阻塞
• 每周分析升级指标，迭代调优阈值参数
• 建立审批 SLA 监控和超时告警
• 引入反馈数据的基础标注流程
• 对 SRE 团队进行升级系统操作培训

第 61-90 天（深化期）：

• 按业务场景配置差异化升级策略
• 启动置信度模型的反馈回流训练
• 实施租约机制，解决并发场景下的状态竞争
• 完成安全审计，检查权限提升攻击向量
• 建立季度升级策略评审机制

9.2 结语

Agent 人工介入与升级策略不是"给 Agent 加一个审批按钮"这么简单。它是一个涉及不确定性量化、状态机设计、并发控制、安全审计、成本优化和持续学习的系统工程。核心工程挑战在于：升级触发器的设计需要同时兼顾召回率（不漏掉真正风险）和精确率（不过度打扰人工审批者），而这两个目标在数据不充分的初期是矛盾的——解决这个矛盾的方法是渐进式激活+数据驱动调优，而非一开始就追求最优配置。

本文讨论的框架已在多个生产系统的落地过程中验证有效性。需要强调的是：任何升级策略都需要与业务方深度协商确定——风险容忍度、人工成本、用户体验 SLA 这些维度没有标准答案，必须结合组织的具体情况量体裁衣。随着 Agent 能力边界的扩展和人工标注数据的积累，升级策略本身也需要持续演进，这本身就是一个人工介入系统的元级别升级问题。

参考文献

1. Wei, J., et al. "Chain-of-thought prompting elicits reasoning in large language models." NeurIPS 2022.

2. Yao, S., et al. "ReAct: Synergizing reasoning and acting in language models." ICLR 2023.

3. OpenAI. "Agents SDK Documentation." https://platform.openai.com/docs/agents, 2026.

4. Anthropic. "Claude Agent SDK — Uncertainty Estimation." https://docs.anthropic.com/en/docs/agents-sdk, 2026.

5. LangChain. "LangGraph — Fault Tolerance and Human-in-the-Loop." https://langchain-ai.github.io/langgraph, 2026.

6. Brynjolfsson, E., & McAfee, A. "The Second Machine Age: Work, Progress, and Prosperity in a Time of Brilliant Technologies." W.W. Norton, 2014.

7. Marcus, G. "The Next Decade in AI: Four Milestones." arXiv:2401.03403, 2024.

8. Kahneman, D. "Thinking, Fast and Slow." Farrar, Straus and Giroux, 2011.

9. Amodei, D., et al. "Concrete problems in AI safety." arXiv:1606.06565, 2016.

10. Huang, J., et al. "Learning to be cautious: Provable safety in AI agents." ICML 2024.

11. Zhou, D., et al. "Cognitive architectures for AI agents: A survey." AI Open 2024.

12. Schick, T., et al. "Toolformer: Language models can teach themselves to use tools." arXiv:2302.04761, 2023.

13. Nakajima, S. "Multi-Agent Coordination with Communication and Learning." AAAI 2025.

14. Russell, S. "Human Compatible: Artificial Intelligence and the Problem of Control." Viking, 2019.

15. OpenAI. "GPT-4 System Card." https://openai.com/gpt-4, 2023.

16. Anthropic. "Constitutional AI: Harmlessness from AI feedback." arXiv:2212.08073, 2022.

17. Perez, E., et al. "Discovering language model behaviors with human-written specifications." arXiv:2204.01129, 2022.

18. Chen, M., et al. "Evaluating the monotonicity of large language models." ACL Findings 2024.

19. Liu, T., & Liu, Y. "Provable RL with human feedback: A survey." arXiv:2403.10081, 2024.

20. Slusallek, P., et al. "AgentOps: Observability for production AI agents." IEEE S&P 2026.

21. Geist, A., et al. "Escalation protocols in enterprise AI systems." Gartner Research, 2025.

22. Microsoft. "Azure OpenAI Service — Content Filtering and Safety." Microsoft Docs, 2026.

23. Zhang, Y., et al. "Rethinking uncertainty estimation in large language model alignment." arXiv:2406.04567, 2024.