让智能体跑上一整天 — 长时运行编码智能体的运维基础设施

问题是什么

很长一段时间里，用编码智能体就是短促的来回。改一下这个函数、看一下这个测试，人每隔几分钟握住又松开键盘。可 OpenAI 的 Codex 在从空仓库做设计工具的实验里，约25小时没有人工介入地一路跑了下来。烧掉1300万 token，生出3万行代码。现在可以按小时、甚至按天放开智能体，而不是按分钟。麻烦在于，一旦放它跑这么久，短任务里藏着的东西就会一齐冒出来。上下文窗口反复被填满又压缩，在这个翻搅里智能体从最初的规格慢慢漂移。token 成本毫无节制地线性堆积，一位实践者警告长时运行模式「消耗多到离谱的 token」，五小时上限的套餐还没把大活干完就到期。最要命的是，凌晨3点跑着的25小时运行悄无声息地崩掉，到早上都没人发现。智能体你能启动 — 但那一层运维：盯着它是不是真在跑、成本漏了就停、漂移了就抓住、卡住了就呼叫人 — 整块都是空的。

为什么是现在

长时运行从实验室演示跨进真实工作流的信号同时冒出来好几个。OpenAI 在 GPT-5.1-Codex-Max 里推出了压缩：上下文接近上限时，模型修剪历史、保留核心状态另开一个新窗口继续执行，内部评测报告它在单任务上自主跑了24小时以上。Codex CLI 在 v0.128.0+ 加了 /goal 命令，处理能跨越中断、会话断开和 token 上限存活下来的持续目标。不再是一次给一条指令，而是给一个带可验证停止条件的目标，让智能体跨多轮去追求。模型侧的效率也跟上了：在同等推理强度下少用30%思考 token 还拿到更高准确率的报告，正是让整天自主在经济上跑得通的条件。也就是说，模型和运行时已经在朝长时运行全力跑。可真正能同时管制多个运行、实时看成本和漂移、在卡住的节点呼叫人的那块仪表盘，却是每个团队用 Markdown 文件和 shell 脚本每次手工拼。没有标准化运维工具，典型的空白。

怎么构建

入口大致有三条。一，检查点与恢复层。25小时实验里真正驯住智能体的，是刻在仓库里的规格、计划、状态 Markdown 文件。把这种外部化状态的模式从手写文件抬升成产品：给运行打快照，崩了就从最后一次通过验证的节点把它救活，自动留下「做了哪些决定、走到哪一步」的审计轨迹。二，漂移与成本管制看板。把多个智能体运行放在一块屏幕上看。现在在哪个里程碑、烧了多少 token、偏离规格多远（碰了那个说好别改的文件没有）、在哪儿验证崩了。设预算上限，半夜 token 暴涨就自动停。三，人工介入节点设计。智能体在判断的岔口停下呼叫人，拿到答复就原地接着跑；把可验证停止条件和「别改这个」的约束放在一处管理的策略层就挂在这里。变现走团队订阅 — 并发运行数、保留的检查点容量、管制的智能体台数。别一开始就盯所有模型和运行时，深扎进一个率先押注长时运行的运行时（如 Codex /goal），成为那个生态的控制塔，更现实。

flowchart LR
  A[长时运行智能体] -->|进度状态| B[检查点层]
  A -->|token 与漂移指标| C[管制看板]
  C -->|超预算| D[自动停机]
  C -->|需要判断| E[人工介入]
  E -->|答复| A
  B -->|崩溃时恢复| A

成功条件

这个市场拼的是「多快赢得信任」。第一，运维层本身必须比它管制的智能体更稳。控制塔一晃，底下所有运行跟着晃 — 检查点恢复只要有一次出岔、把好端端的活给丢了，客户立刻掉头就走。第二，成本护栏必须是实时拦截，而不是事后账单。「你昨天用了这么多 token」已经太晚，价值在于踩到上限前那一下停住。第三，漂移检测才是数据锁定的核心。哪些信号真正预示漂移（哪种文件改动、哪种验证失败模式），只会随着运行累积越来越准，那份越滚越大的优势是快速跟随者复制不了的。最常见的失败，是一上来就想撑住所有运行时，结果哪个都没扎深。