线上出错后，先让 AI 修，还是让它直接发版？

一款已经上线的小应用开始报 500，慢查询把延迟拖上去，用户还没来得及发来那句“怎么又打不开了”。你会让 Agent 去看日志、找原因、改代码吗？大多数人会。

那再往前推一步：修完之后，要不要让它把改动直接推到线上？这一步，事情忽然没那么浪漫了。

Replit 昨天发布的 Monitoring Agent，刚好把这道选择摆在设置页里。它可以读取生产日志和指标，调查错误、变慢和部署失败；开启告警与 Auto-fix 后，它会在后台尝试、验证修复，再把摘要发到邮箱。另一个叫 Auto-republish 的开关，才负责把修好的版本重新发布。

很多介绍会把它叫成“AI 值班工程师”。这个说法很顺耳，但容易把三种完全不同的权力揉成一团：发现问题的观察权、改动代码的修复权，以及把变更送进生产环境的发布权。Replit 的产品设计里，恰好没有把它们绑成一个按钮。

这比“它会不会自动修 Bug”更值得拆。因为线上事故里最贵的，往往不是找不到一处 patch，而是把一处看起来没问题的 patch 放进了错误的时间、错误的环境，影响了错误的用户。

别把“修好了”当成“可以上线”

Replit 的官方文档写得比营销文案克制：Monitoring alerts、Auto-fix、Auto-republish 是三个独立设置。你可以只收告警，不给 Agent 改代码的权限；也可以让它尝试修复，但仍由人决定要不要发布。Auto-republish 还是实验性功能，并且依赖 Auto-fix；打开 Auto-fix 本身，并不等于同意上线。

这组拆分很像一个小型的发布控制面。告警回答“现在发生了什么”；自动修复回答“能不能做出一个候选改动”；自动发布才回答“这个候选改动有没有资格影响真实用户”。三个问题看起来连着，证据门槛却不该相同。

比如一个接口突然大量 500。Agent 读日志后发现某个配置缺失，补上一行默认值，跑过已有测试，听起来很像可以直接发版。可如果这个默认值改变的是支付状态、权限校验或数据库连接的 fallback 行为，测试绿了只说明一部分路径没炸，不说明业务含义仍然对。

反过来，某个静态资源路径因为 CDN 配置失效导致 404，修复是把一条明确的 URL 配置还原，影响范围小，回归也容易观察。把这类问题和前一种问题放在同一个“自动修复成功”篮子里，就很容易把风险平均掉。

把观察、修复、发布拆开，才能让每一层匹配不同的证据门槛。

所以我会把 Replit 这三个开关翻译成一个更实用的顺序：先开观察，再开候选修复，最后才讨论发布授权。 不是为了把 Agent 关在门外，而是让它先在可回看的范围内积累可信度。

官方已经替你划出一条线

Monitoring Agent 的自动检查目前盯三类信号：应用错误日志、HTTP 错误和请求延迟。需要人工发问时，它还能查询流量、端点的 p50、p95、p99 延迟，CPU 与内存、磁盘和网络出口，以及按严重度或部署版本筛选的运行日志。

这是一套很有用的排障视野，但它不是“懂你的生产系统”。文档也明确说，自动检查覆盖的范围小于 Agent 在被询问时能调查的遥测。更关键的是，能看到指标，不等于能自动判断某个业务指标下滑到底是故障、活动流量，还是刚刚上线的正确变化。

官方还单独提醒了数据库迁移和索引操作可能有风险。这一句该被放大。因为它指出了自动修复最容易被忽略的边界：代码层面的正确性，和数据层面的可逆性，并不是一回事。

给一个演示环境补错别字，或者为一个无状态接口恢复超时配置，失败后多半能回滚。给线上库改 schema、补索引、清洗重复数据，即使 Agent 的 SQL 语法完全正确，也可能触发锁表、长事务、写放大或不可逆的数据变化。后者不该因为“修复已经通过验证”就自动获得发布权。

这也解释了为什么“让 AI 值班”不等于“不再需要值班”。人的位置从盯着一行行日志，慢慢移到定义事件等级、修改范围、验收信号和止损条件。少的是重复查找，不能少的是谁来对影响范围签字。

一张可以直接拿去配的权限表

如果你的应用也准备接这种能力，不用从“全开”或“全关”二选一。先按变更可逆性和影响范围分组，配置可以像这样写进团队的发布约定：

monitoring_alerts: on
auto_fix:
  allow:
    - 已验证的配置回退
    - 无状态服务的重启与重试参数修复
    - 具备完整测试覆盖的小范围代码改动
  require_review:
    - 认证、权限、计费和支付相关改动
    - 新增外部服务调用
    - 跨模块重构或依赖升级
  deny:
    - 数据库迁移与索引操作
    - 批量删除、批量写入和密钥轮换
auto_publish:
  default: off
  enable_only_when:
    - 有明确的回滚版本
    - 关键健康指标有发布后观察窗口
    - 变更属于已演练的低风险类别

这不是 Replit 的产品配置语法，而是一份拿来和团队对齐的判断模板。它逼着你在事故发生前回答几个本来就该回答的问题：哪些操作能撤回？谁能看到改动？上线后看哪条信号？如果指标继续变坏，用哪一个动作停止？

Replit 的设置本身也给了一个很自然的渐进路径。先只打开告警；确认告警质量后，再允许 Auto-fix 生成候选修复；想保留自动修复、但不想自动上线，就关掉 Auto-republish。要停止后台调查和修复，关闭 Auto-fix 即可，告警仍能保留。

这里还有一笔经常被遗漏的账：Monitoring Agent 的运行可能产生 Agent 用量费用。自动化不是只拿到了一个夜间工程师，也是在给每次调查、每轮修复尝试和每段上下文付费。把告警阈值、事件合并、最大尝试次数和费用监控设在同一张表上，会比事后翻账单舒服得多。

还有一个更朴素的办法：给每次自动处理留一份最小事故记录。不是为了再造一套厚重流程，而是让人能在第二天回答四件事：它因为什么信号启动、读过哪些日志或指标、改了哪些文件或设置、最终为什么没有或为什么已经发布。Replit 会把处理结果通过邮件汇报；把这类摘要留进自己的 issue 或运行记录里，后面才能知道某一类自动修复究竟是在省时间，还是在制造更多待确认的工作。

不要只记“成功次数”。一次系统把错误吞掉、表面恢复了 200，也可能被统计成成功。更有用的是把它们拆成“找对根因”“候选改动通过检查”“发布后观察窗口无回退”“人工否决”几类。只要人工否决长期集中在同一类变更上，那一类就该从允许自动处理的列表挪到人工复核，而不是继续给 Agent 加一句更长的提示词。

真正的发布门不在“Agent 说修好了”的那一刻，而在修复能否带着可验证证据穿过影响范围。

验证到底要验证什么

“Agent 验证了修复”这句话很容易让人放松。它至少还缺四个问题。

第一，验证的是故障症状，还是故障原因？一个 500 消失，可能是异常真的被修掉，也可能是接口被兜底成了 200。第二，验证用的是生产同类请求、预发布流量，还是一组单元测试？它们给出的把握完全不同。

第三，验证有没有覆盖发布后的副作用？例如把慢接口改快，可能换来了缓存穿透、队列堆积或成本飙升。第四，谁能在异常出现时撤回？如果没有可回滚版本、没有观察窗口、没有负责人，所谓自动发布只是把“手工失误”换成“高速失误”。

Replit 文档里有一个很适合拿来做发布后观察的线索：端点级别可看请求数、延迟与 4xx/5xx，延迟还包括平均值、p50、p95、p99。对低风险的自动重新发布，至少应该在短窗口里盯住错误率和尾延迟；只看平均延迟，会让一小群被卡住的用户悄悄消失在平均数里。

把这件事落到操作上，可以设一个很窄的发布逃生通道。候选修复先在当前可用的检查里跑一遍；若属于预先允许的低风险类别，再重新发布；发布后只观察几个事先约定的信号，例如该端点的 5xx、p95 和请求量。任一信号越过阈值，就停止后续自动处理并回到人工。这里的重点不是阈值该填多少，而是阈值在事故之前就写好，不能等 Agent 已经上线才临时凭感觉决定。

同一套思路也适合处理“没有问题”的情况。官方的告警表会区分 Active、Resolved 和 Cannot measure。Cannot measure 不该被悄悄当作一切正常；它只是平台暂时无法评估。对依赖外部支付、第三方 API 或后台任务的应用，真正重要的业务信号可能根本不在这三种自动检查里。人需要补上的，正是这些产品最在意、却没有天然落在 HTTP 错误或延迟里的指标。

例如一个预约应用的接口全部返回 200，不代表预约真的创建成功；一个内容站的 p95 很漂亮，也不代表发布任务没有卡住。把业务确认信号放在发布门旁边，才不会把“服务活着”错当成“服务完成了用户要的事”。Monitoring Agent 可以成为排障入口，但不该被误认为整个业务验收系统。

这份边界也会让事故后的复盘更有价值。与其问“为什么 AI 没有一次性修好”，不如顺着权限链去看：告警是否足够早，调查是否拿到了关键上下文，候选改动是否越过了允许范围，发布后的哪条信号本该阻止它继续前进。这样得到的结论能回写到阈值、测试、回滚和授权规则里，而不只是把某次事故归结为模型“偶尔不聪明”。

当然，官方没有在文档里承诺金丝雀发布、自动回滚或业务级审批。不要把产品没写的保障，脑补进你的发布流程。你可以把 Auto-republish 当成一个值得试的低风险自动化入口，却不该替它补上一套不存在的可靠性承诺。

如果你正在决定第一批该交给它的任务，可以反着选：挑那些人类工程师遇到后也会先做同一套、步骤短、后果容易撤回的事。恢复一条已知配置、重试一个无状态服务、修正已经有测试覆盖的小范围判断，都比“顺便重构一下”“顺便升级依赖”“顺便清掉历史数据”更适合进入自动处理队列。前一组的价值在于帮人跳过凌晨里最机械的动作；后一组的危险在于表面像修复，实际已经悄悄改变了系统结构。

这也是 Replit 官方配置说明 把告警、Auto-fix、Auto-republish 分开的意义。它不是把责任推回用户，而是给团队留了一条逐级授权的路：每一层先证明自己没有把问题变大，再拿下一层的权限。对于刚开始把 Agent 接进生产环境的团队，这比一上来追求“全自动”可靠得多。

真正被替换的，是那段最机械的等待

小团队最痛的部分很少是“完全不会修”。更多时候是告警来了以后，没人方便立刻登录，日志散在几处，复现和改动都要在工作流之间来回搬。Monitoring Agent 的价值，是把这段机械的观察、归因和候选修复压缩掉，让人更早看到一个带证据的选项。

但发布仍然是一种承诺：承诺这份改动对真实用户、真实数据和真实账单的影响，已经被放进了可接受的范围。Agent 可以把证据搬到桌上，也可以替你跑很多检查；最后那条“允许影响生产”的线，最好先由团队画清楚，再决定是否交给机器执行。

如果你今天只能改一件事，不必急着开 Auto-republish。先为自己的线上应用写下三类“绝不自动发布”的改动，再挑一类已经演练过、随时能回滚的小修复让 Agent 接手。等告警质量、修复质量和费用边界都看明白了，发布权自然会有更合适的位置。

你们的线上流程里，哪一种改动最适合让 Agent 先试着修、但绝不该直接上线？

— 小岛AI

记录一线实战、踩坑与成长