长时间运行的AI Agent 如何安全停机：预算、熔断、人工接管与状态回读

摘要：OpenAI 最新内部安全事件说明暴露了长任务中的持续推进、目标偏移和未授权路径问题。本文不把实验室事件外推到普通产品，而是给出一套适用于内容运营与办公 Agent 的运行时控制架构：范围、预算、熔断、可观测性、人工接管和状态回读。

设计 Agent 时，团队通常先做权限：允许读哪些文件、调用哪些 API、执行哪些动作。这一步回答的是 can it do。

长时间运行以后，还需要回答另一个问题：should it continue。

OpenAI 2026 年 8 月 26 日公布了一份内部网络安全评估事件说明。该事件发生在降低部分安全防护的内部研究环境，主要涉及内部研究模型，不能直接类比普通用户产品；官方明确表示客户数据、产品功能和可用性未受影响。对普通工程团队真正可迁移的启示，是 Agent 在困难任务里需要明确的退出条件。

1. 权限控制与运行时控制是两层问题

最小权限限制影响面，但不能阻止以下故障：

同一步骤反复失败并无限重试；
为完成目标不断寻找替代路径，逐渐偏离原任务；
多个 Agent 互相传递未经验证的中间结论；
工具返回 200 就被当成业务成功；
人接管时无法判断已经产生哪些副作用。

因此，Agent 运行契约应同时包含：

ts 复制代码

type RuntimeContract = {
  scope: ScopePolicy;
  budget: BudgetPolicy;
  breakers: BreakerRule[];
  approvals: ApprovalPolicy;
  telemetry: TelemetryPolicy;
  verification: VerificationPolicy;
};

2. 先定义范围，再允许探索

范围策略不只列工具名，还要约束数据、目标和外部系统：

yaml 复制代码

scope:
  goal: 发布一篇已审核的技术文章
  allowed_platforms: [csdn, juejin, toutiao]
  allowed_data:
    - /workspace/content-review/current/**
  allowed_actions:
    - read
    - create_draft
    - upload_asset
    - prefill
  approval_required:
    - public_publish
  denied_actions:
    - delete_account
    - payment
    - modify_source_code

"允许调用浏览器"过于宽泛。更好的授权单位是岗位动作，例如 prefill_article、read_publish_status，而不是把整个浏览器和所有登录态交给同一个 Agent。

3. 预算要覆盖钱、时间和外部副作用

成本上限只是预算的一部分：

ts 复制代码

interface BudgetPolicy {
  maxWallClockMs: number;
  maxToolCalls: number;
  maxExternalWrites: number;
  maxRetriesPerStep: number;
  maxModelCost: number;
}

尤其要单独统计 externalWrites。生成十个本地草稿与创建十个在线草稿的副作用完全不同。

预算耗尽后的默认状态应是 WAITING_FOR_HUMAN，而不是自动切换工具、扩大权限或提高消费上限。

4. 熔断规则必须是可执行条件

"遇到问题及时停止"无法直接运行。需要把它写成事件规则：

ts 复制代码

const breakers: BreakerRule[] = [
  repeatError({ sameSignature: 2 }),
  noProgress({ heartbeats: 3 }),
  authChallenge({ types: ['captcha', 'risk_control', 'logged_out'] }),
  sourceConflict({ criticalFacts: true }),
  scopeDrift({ similarityBelow: 0.65 }),
  irreversibleAction({ requireApproval: true })
];

触发熔断以后，要保存恢复点：当前状态、最后一个成功步骤、已打开资源、已产生写入、待确认事项。

5. 监督不是每一步弹窗

Anthropic 对 Claude Code 与公共 API 的实际使用研究发现，经验更丰富的用户更常自动批准，同时也更常中断 Agent。其含义不是"越熟练越不管"，而是监督策略从逐步批准转向持续观察和关键介入。

可以按风险划分动作：

风险	示例	默认处理
低、可逆	读资料、生成候选、建本地文件	自动执行并记录
中、有外部写入	建在线草稿、上传素材、修改非唯一副本	执行后回读
高、不可逆或对外	公开发布、付款、删除、覆盖唯一文件	人工确认

如果所有动作都弹窗，人很快会形成确认疲劳；如果所有动作都自动，错误又可能积累。正确目标是让人始终处在"能看见、能介入"的位置。

6. 可观测性应该回答六个问题

一个实用的运行面板至少显示：

当前目标；
当前步骤；
最近一次工具调用及结果；
已产生的外部副作用；
剩余预算；
下一步计划与风险。

心跳事件可以统一成：

json 复制代码

{
  "run_id": "run_20260828_2030",
  "state": "RUNNING",
  "step": "toutiao.prefill",
  "progress_delta": "cover_uploaded",
  "external_writes": 2,
  "remaining_tool_calls": 19,
  "next": "verify_editor_fields"
}

连续三个心跳没有 progress_delta，应触发无进展熔断。

7. 人工接管需要现场包

Agent 不能只说"遇到错误，请人工处理"。接管包至少包含：

yaml 复制代码

handoff:
  completed:
    - title_filled
    - body_uploaded
  failed:
    - cover_upload
  side_effects:
    - draft_id: 12345
  retained_state:
    - editor_url: https://example.com/editor/12345
  minimum_human_action:
    - 完成验证码后重新检查登录态
  safe_to_retry: true

这使人工接管成为流程的一部分，而不是 Agent 失败后的临时补洞。

8. 点击按钮不等于完成

推荐状态机：

text 复制代码

PREPARED → RUNNING → PREFILLED → REVIEWED → SUBMITTED → VERIFIED
                ↓          ↓
             ABORTED   WAITING_FOR_HUMAN

SUBMITTED 必须通过目标系统回读进入 VERIFIED：文章要取得作品 ID 和审核状态，文件要校验路径与内容，订单要查询真实记录。工具层成功不能替代业务层成功。

9. 岗位化 Agent 的价值与边界

岗位化让运行契约更短。博客发布助手只需要稿件、素材和平台字段；视频制作助手只处理脚本、素材与成片；不同岗位不必共享所有工具。

这也是我们做 Tipkay 时采用"专业 AI 员工"结构的一个原因。官网强调岗位经验、流程和工具已经配置，关键操作由用户确认。需要明确：岗位化、本地登录态和人工确认不是对基础设施安全的保证，更不能防御 OpenAI 报告里的攻击链；它们解决的是产品层的范围收敛、操作分工和责任边界。

结论

长任务 Agent 的成熟度，不应只看它能连续运行多久，还要看它是否能在错误扩大前停下、把现场交给人，并从正确位置恢复。

最好的停止按钮，不是页面右上角那个红色图标，而是一套从范围、预算、熔断到状态回读都能真正执行的运行契约。

参考资料：

标签：人工智能、软件工程、信息安全