凌晨三点手机响，线上接口全在报 500。这件事过去十年的解法是叫人起床，2026 年开始有另一种解法：叫 Agent 起床。
10 月 22 日 Replit 上线 Monitoring Agent，10 月 23 日进变更日志。宣传语很直接，说它是你自己的软件工程团队。做的工作是一整条闭环：读生产日志和指标，定位告警原因，尝试改代码，验证，然后可以选择直接发布出去。
这条链路里最有意思的不是它能不能修，而是它把「权限」设计成了三个开关。这个细节值得单独拿出来讲，因为它决定了你敢不敢在真实业务上开。
闭环四步：发现、定位、改、验证
流程不复杂，难的是每一步的边界。
监控告警负责发现并通知，只做这件事，不碰代码也不碰部署。自动修这一档，Agent 才被允许读生产指标、运行时日志和源码，定位原因，改出一版补丁，并且自己验证一遍，结果落在对话里等人来发。第三档自动发布，才把最后那个人工动作也去掉，验证通过的改动能直接上生产。
后两档是串起来的。自动发布必须依赖自动修，不能单独开。这个设计挺克制，也堵掉了一个危险组合——只开自动发布不开自动修，等于让一个没做过诊断的东西直接上线。
Replit 的文档里有一句话我觉得应该被所有推 AI 运维的产品抄下来：告警不保证有修复。原文的意思是，一个外部服务的问题可能需要你在应用之外处理。这句话等于承认了大多数生产故障根本不是代码缺陷。
三个开关怎么配：从只开第一档开始
第三方评测给出的默认建议是：面向客户的应用，告警开、自动修开、自动发布关。我基本同意，但会更保守一点。
新项目或者第一次用，先只开告警，跑两周。目的不是让它修东西，是看它的告警质量——多少是真故障，多少是噪音，同一个问题会不会反复报。这两周的数据决定后面两档要不要开。
自动修这一档，前提是你的项目里有测试，而且测试跑得起来。它改完会自己验证，但你不该把「验证」这件事完全外包给一个刚上线的功能。手动审一遍补丁、看它有没有偷偷改配置、有没有顺手重命名变量，这个动作省不掉。
自动发布，我的建议是面向客户的生产环境一律不开，内部工具、演示站、个人小项目可以试。官方自己把它标成实验性，还要求必须先开自动修，这个态度已经说明问题了。
安全这块 Replit 做得比预期细。开发和生产环境强制沙箱隔离，Agent 不会同时持有两边的写权限；每个 Agent 有独立身份，所有动作可审计。这两条是这类产品能不能进企业的门槛，比修得快不快重要。
它盯的只有三类信号，剩下靠你开口
自动检测覆盖的范围窄得有点意外：应用错误日志、HTTP 错误、请求延迟。就这三类。
告警触发之后能查的东西多得多：请求量和可用性、4xx 与 5xx 比例、每个端点的平均延迟和 p50、p95、p99、CPU 与内存占用、活跃实例数、启动延迟、正常运行时间、磁盘、出网流量，以及按级别或部署版本过滤的运行时日志。
这个分工是合理的：便宜的启发式负责叫醒，贵的推理负责调查。但它带来一个可预期的盲区。
队列积压、第三方接口超时、数据被写坏、某个区域的依赖降级、业务不变量被破坏——这些都不一定会产生应用错误、HTTP 错误或者延迟飙升。它们的结果是：系统用正常的速度返回错误的答案。
一个没有任何告警的应用，可能已经病得很重。Agent 不会主动去看，因为没人让它看。
这条限制对做业务系统的人特别重要。你那套系统的核心风险往往不在 500，在于「金额算错了但页面显示正常」。这类问题得靠你自己的业务校验、对账任务、数据质量监控去兜，别指望值班 Agent。
缺的那块不是智能，是回滚
我把能查到的材料翻了一遍，发现真正缺的东西跟 AI 能力无关，全是运维的老功课。
没有公开的金丝雀比例，没有分阶段放量，没有连续修复失败后的自动熔断，也没有修复上线后错误率再次抬升时的自动回滚。验证环节同样模糊：跑哪些测试、是不是用类似生产的数据、通过阈值是多少、发布后要健康多久才算过，文档都没写。
换句话说，它把「谁来按按钮」这个问题解决得很好，把「按错了怎么办」留给了你。
这两件事的难度完全不同。让 Agent 定位一个空指针，2026 年的模型已经做得不错；让它判断一个补丁在流量峰值的真实负载下会不会引发连锁反应，还差得远。自动回滚之所以是最后一公里，因为它要求系统先知道自己「健康」的标准是什么，而大部分小团队根本没定义过这个标准。
所以要用它，得自己补三样东西：能一键回滚的部署历史、一个明确的错误率阈值和熔断规则、发布后至少半小时的观察窗口。这三样东西 Replit 不提供，但你的项目里必须有人管。
和 Sentry 那条路的差别
同样是让 AI 处理线上故障，Sentry 的 Seer 走的是另一条路，对比一下能看清两家的取舍。
Seer 的流程是四步：根因分析、给方案、生成代码、迭代 PR。关键在它可以配置停点——只做根因分析、停在方案、或者直接开 PR，甚至把活交给 Cursor 这类编码 Agent。默认是开到 PR 为止，合并由你按。
两边的分歧就在这个默认值上。Seer 假设你有一个正常的代码评审流程，它把自己放在流程的上游；Replit 假设你根本没有流程，所以它把发布也做成了开关，还默认关着。
价格也不是一个量级。Seer 现在是一个活跃贡献者每月四十美元、不计量使用；Replit 是订阅制，Core 每月二十美元、Pro 每月一百美元，Agent 的用量按工作量另算，免费档只能发布一个应用而且三十天后下线。
选哪个取决于你的应用跑在哪。跑在 Replit 上，Monitoring Agent 是原生的，省掉接监控 SDK 这一步；跑在别处，Sentry 这类专业可观测性工具配上你自己的 CI，可控性更高。站内写过 Vercel 那个断点续跑的包，思路是一样的：把 Agent 塞进已有的工程流程，而不是另起一套。
什么人可以开，什么人先别急
适合开的：一个人维护的小产品，没有 on-call，半夜出问题只能第二天早上看；内部工具和演示项目，挂了不影响收入；刚上线还在快速迭代的项目，错误日志本身就是开发素材。
先别急的：有真实支付和资金流水的系统，一次错误发布可能比一次故障更贵；多人协作、有正经发布流程的团队，Agent 直接改主干会打乱节奏；跑在监管行业里的应用，自动改代码这件事本身就过不了审计。
还有个更实际的判断标准：你现在能不能在五分钟内把上一版部署回去。能，就可以试第二档；不能，先把回滚做好再谈自动化。
老达点评
这类产品今年会越来越多，DeepSeek 那套 Super-agent 架构讲的是把会话管理和上下文同步交给系统，Android Studio 那批智能体讲的是把编码流程拆成可验收的环节。Replit 这一版补的是最后一格：谁在没人看着的时候动手。
我觉得它做对的地方是把自主性拆成了三段，而不是给一个「全自动」的总开关。多数 AI 产品的失败不是因为能力不够，是因为只给了用户「信」和「不信」两个选项。三段式至少让人可以从「它看着、我动手」开始，慢慢过渡。
做得不够的地方也很清楚：验证过程不透明，回滚缺失，检测信号窄。这三点合起来意味着它现在是个很好的「三更半夜帮你定位问题的人」，还不是一个能替你值班的工程师。
要试的话，我的建议只有一句：先只开告警，把噪音摸清楚，再谈后面两档。真正决定你能不能睡好觉的，从来不是 Agent 有多聪明，是你的回滚有多快。
想系统看智能体怎么接进工程流程，AI 智能体与自动化专题里有完整的链路拆解；关心工具选型和上手成本的，AI 编程工具专题那几篇更对症。
