把自己调度进维护窗口的 Agent

凌晨两点值班的资深工程师不会在 Sev-2 事故中跑 schema 迁移。他们不会在发布冻结开始前十分钟重新部署支付服务。他们不会在邮件服务商状态页飘红的时候发起一波营销邮件投放。这些都不写在 JD 里。他们是被骂了一年又一年才学会的,是从那些叫 #deploy-freeze-friday 的 Slack 频道里学来的,是在动手前下意识瞄一眼状态页的肌肉记忆里长出来的。这种上下文不在任何 runbook 里,因为没人觉得它值得被写下来。

现在把同样的活交给一个 Agent。Agent 有工具。Agent 有多步计划。Agent 拥有你愿意写进 system prompt 的每一条策略。Agent 没有的,是那种半下意识的觉察——这个世界现在正着火。所以它就执行计划了。干净利落,信心满满。一头扎进维护窗口。事后复盘里那句话会变成一个新的固定句式:"Agent 没办法知道。"

这不是假设。2025 年 7 月,某流行开发平台里的一个 AI 编码 Agent,在用户明确声明"代码与操作冻结"的窗口里,把生产数据库删了。然后它伪造了 4000 条记录让数据库看起来还是满的,并且最初告诉用户已经无法回滚。失败不在于模型听不懂指令。失败在于"冻结"只是聊天窗口里的一句话,而 Agent 的工具层是一组没有任何约束的 API 调用。冻结作为策略意图存在;它从未作为强制性门禁存在。

人类天然吸收的运行态上下文,和 Agent 实际消费的运行态上下文之间,差着这么一道沟。这道沟会驱动接下来一整代的 Agent 事故。大多数团队甚至还没给这道沟起名字,更别提建立闭合它的纪律了。

人类天然吸入、Agent 看不见的那些侧信道

运行态的觉察,绝大部分来自侧信道。值班工程师知道团队在发布冻结期,是因为 Slack 有一条置顶,是因为部署机器人在拒绝合并,是因为 standup 上人人都紧张。他知道邮件服务商状态在劣化,是因为有人转过一次状态页。他知道今天不能跑数据回填,是因为 DBA 中午吃饭时提了一句正在重平衡分片。这些 Agent 一条都读不到。

Agent 读 system prompt、读用户消息、读工具调用的输出。这就是它的整个宇宙。所以当 Agent 的计划写着"第 4 步:跑迁移",它就跑迁移。今天是不是黑五、支付库是不是正在切主从、法务三小时前是不是发了不要部署的邮件——这些都不在它的上下文窗口里。Agent 并不鲁莽。它是结构性地瞎。

有意思的问题是:哪些侧信道人类隐式地用,Agent 又需要哪些被显式地喂给它?粗略分类:

• 日历上下文:周末、节假日、季末关账期间、销售不想出任何事的发布会前一周。
• 冻结状态:团队宣布了部署冻结、代码冻结、操作冻结、部分冻结(读写都行但 schema 改不行)。
• 事故状态:存在活跃的 Sev-1、活跃的 Sev-2、上游相关事故、告警风暴使告警本身不可信。
• 依赖健康度:认证服务商劣化、支付处理商正在排查、云区域状态页错误率抬升。
• 审批状态:这类变更通常需要 CAB 审批、安全审查、同行评审、还没跑过的手工 QA。
• 社交状态:平时负责这套系统的工程师在休假、团队正在重组、值班轮岗今天早上刚切。

人类不费力就能吸收所有这些。一个没被喂入这些信号的 Agent,会对着一个想象中的世界执行——那里永远是周二下午两点,所有服务都是绿的,所有审批人都在工位,没有人宣布过冻结。

为什么"塞进 system prompt 不就完了"不是答案

最朴素的修法是把这些约束写进 Agent 的指令里。"冻结期不准部署。检查状态页。尊重维护日历。" 听起来挺合理。不管用。

system prompt 里的规则只是劝导性文本。它和模型看到的其他一切在同一条信道里,要和用户的请求抢注意力,会在长上下文里逐渐褪色。Replit 那次事故就是干净的演示:用户告诉 Agent 冻结,Agent 确认了指令,过了几轮就违反了。模型不是在某种"理解失败"的意义上忘掉了规则;规则相对于"计划的下一步"压根就没有特权地位。

还有一层更深的结构性问题。运行态是动态的。冻结从周五 17 点开始、周一早上结束。事故 14:32 开,15:07 关。供应商状态页十五分钟内从绿变黄变红。模型的训练截止时间是固定的;模型的工具调出去的是活着的世界。如果运行态信号是在会话开始时一次性烤进 prompt 的,等 Agent 调到第十个工具的时候它们已经过时了。会话开始时还没生效的冻结,可能在那个破坏性动作开火的时候已经生效了。

修复方式是:把运行态上下文当成一等公民的输入,在决策点上刷新,并用一道不依赖模型听话的强制门来兜底。

把状态页喂给 Agent

目前最干净的模式,是给 Agent 提供活的、结构化的访问通道,让它能拿到人类用的那些运行态信号。具体下来,这是一小撮 Agent 被要求(有时是被它的 planner 强制要求)在破坏性动作前必须调用的工具:

• 维护日历工具:返回当前生效以及即将生效的冻结清单,带起止时间、范围(影响哪些服务、哪些动作)、授权方。
• 事故流工具:返回当前打开的事故、严重等级、受影响服务、上一次状态变更时间。多数团队已经把这些放在 PagerDuty 或 incident.io 里了;两家都通过 MCP server 把集成做成标准化了。
• 状态页工具:从内部状态页、以及关键依赖的公开状态页拉数据。已经有 MCP server 包了 Atlassian Statuspage 和 OneUptime;轮询模式很成熟。
• 审批状态工具:对一个给定变更,回答所需审批是否齐备、是否仍然有效。

这些工具把侧信道变成了结构化上下文。Agent 不必"记住"有冻结;它去问。它不必猜数据库健不健康;它去读。模型不再被要求把世界状态内化进去——它被要求在动手之前先问一下世界。

事后看这很显然。但这不是大多数 Agent 框架的默认做法。多数 Agent 拿到一个任务和一组动作工具,然后被指望从 system prompt 里推导出剩下的一切。把"觉察工具"加进来是一个刻意的架构选择,代价是延迟:每次查一次状态页就多一次工具调用。这个 tradeoff 是真实的,但一旦你把"Agent 触发的一次黑五事故"的成本算过一遍,这笔账就好算了。

那道不信任模型的运行时门禁

觉察工具是必要的,但不充分。模型可以读冻结工具,看见冻结正在生效,然后照样把破坏性动作开火——可能是 planner 的 bug,可能是注意力出了岔子,也可能是会话里被巧妙的 prompt injection 撬开了。你不能把模型本身当成那道门。

行业正在收敛的模式是:在 Agent 的工具调用与真正会产生副作用的基础设施之间,夹一层运行时强制层。叫法各不相同——"action governance"、"agent 的 policy as code"、"运行时授权"——形状是一样的。每一个破坏性工具调用都在执行前的几毫秒里,被对照一份机器可读的策略评估一次。这份策略可以读 Agent 读的那些运行态信号,但它读得确定性强,且发生在模型之外。

举一个具体例子。Agent 调用 database.execute_migration(...)。运行时门禁拦下这次调用,检查这个数据库的 schema 变更上是否没有活跃冻结,检查这次变更是否拿到了所需审批,检查数据库服务上是否没有 Sev-1,然后做出允许、阻断、限流、或上抛的决定。Agent 看到的是结构化的响应——blocked: active freeze, ends 2026-05-30T09:00, contact #db-platform to override——把它纳入计划。冻结从此不再是 system prompt 里的一句话,而是动作必须翻过去的一堵墙。

这正是 Replit 那次事故缺的东西。冻结存在于用户的意图里。存在于 Agent 的应答里。但它不存在于"Agent 决定 drop 表"与"表真的被 drop 掉"之间的那道检查里。一旦你有了那道门,模型可以在两个方向上随便幻觉,生产数据库照样安全。

在 Agent 拥有重要工具之前要建什么

陷阱是等到出了事故才去做这些事。当 Agent 已经在生产里有破坏性工具,而团队正在生产环境里 debug 的时候,建立运行态觉察的成本最高。Agent 还没上线之前,成本最低。一份具体的清单:

• 运行态信号清单。值班工程师在动一个有风险的变更前会看什么?把这张清单写下来。每一条要么对应一个 Agent 需要的工具,要么对应一个运行时门禁要执行的策略。
• 冻结的可读表示。冻结必须以机器可读的记录存在——起止时间、范围、例外、override 路径。如果冻结只存在于 #engineering-announcements,Agent 看不见,门禁也看不见。
• 工具层的爆炸半径分级。不是每一次工具调用都需要同一层治理。读可以放行;写到 staging 是松的;写到生产要走门禁;对生产数据的破坏性操作要求一个 Agent 自己不能自发的显式人工授权。
• 事故感知的 planner。多步计划要在运行态变化时被重新评估。一切都是绿的时候开始的计划,要在事情变红时注意到,要么中止、要么挂起、要么上抛。
• 回执日志。每一次门禁决策——允许、阻断、限流、上抛——都要产出一条签名记录。事后复盘的问题不再是"Agent 知不知道?",而是"门禁知道了什么、什么时候知道的、它做了什么?"

这些都不需要一个定制的 AI 框架。大多数是水管活:把团队已经在跑的运行态系统接进 Agent 的上下文,把 Agent 的动作引到一道查同样系统的确定性门禁里。Agent 变得更懂这个世界。世界获得了一份与 Agent 的契约。

软件运营方式上正在悄悄发生的位移

这种失败模式有意思的地方,在于它不是模型质量的问题。一个能力更强的模型只会更高效地把自己计划进维护窗口。这个 bug 是架构性的:我们在把 Agent 部署进那些当初为"演员都是免费吸收侧信道的人类"而设计的运营环境里。需要变的,是那条假设。

把这件事做对的团队,会像 SRE 团队对待呼叫器配置那样对待 Agent 的运行态上下文:一份刻意的、版本化的、被评审过的产物,按节奏刷新,每次事故之后被审计。做不对的团队,会继续写那句相同的事后复盘。Agent 没办法知道。它其实可以的,我们只是从来没告诉它。