不是自治滑块，是三个开关
10 月 22 日，Replit 上线 Monitoring Agent，官方博客由 Akram Hussein 与 Carl Cortright 署名，更新日志记为 10 月 23 日。包装语是「属于你自己的软件工程团队」，但真正值得读的是文档里的三档设置。
监控告警只做一件事：盯住已发布的应用，出状况时通知你，代码和部署都不动。自动修复往下走一层，智能体读生产指标、运行时日志与源码，诊断、写出候选改动并尝试验证，结果放进会话里等你自己发布。自动重新发布再往下走一层，把验证过的改动直接推上线——它挂着实验功能标签，而且依赖自动修复先打开。
这个设计比「一个自治等级滑块」诚实得多。业界谈智能体自治，习惯把它当成一条连续光谱；Replit 用三个开关说明这是三个不同的授权决定：能不能看、能不能改、能不能让线上用户用上。每两个 App 之间那道门要不要交出去，由开发者自己定，配置按应用分别进行。
触发很窄，可查很多
自动检测盯三类信号：应用错误日志、HTTP 错误、请求延迟。这个触发集合窄，Replit 也没有装作很宽——文档直接写着「告警不保证有修复」，比如外部服务的问题需要在应用之外处理。
接到告警之后，智能体能按需查的东西不少：请求数与可用性、4xx 与 5xx 比率、每个端点的均值与 p50 到 p99 延迟、CPU 与内存占用、活跃实例数、启动延迟、运行时长、磁盘用量、网络出口，以及按严重级别或部署版本筛过的运行时日志。
这个「便宜的启发式负责触发，贵的推理负责调查」的切分是合理的，代价也清楚：队列积压、第三方超时、数据损坏、某个区域依赖在降级、业务级不变量被破坏——这些都不会抬高错误率也不拖慢响应，它们只是以正常速度返回错误答案。一个没有告警的应用可能已经坏得很彻底，而智能体不会主动去看，除非被人问到。
审批游标往前挪了，回退路径没跟上
缺的那一半要说清楚。Replit 说修复在获得自动重新发布资格之前会先被验证，但没有公开跑哪些测试、验证是否用生产级数据、通过门槛是多少、发布之后是否需要在一段时间内保持健康。也没有看到金丝雀比例、分阶段发布、反复修复后的自动叫停，以及修复后错误率重新爬升时的自动回滚。
一份已公开的第三方评测给出的是同一处顾虑：自动修复适合有人看着的生产分诊，而实验性的自动重新发布规格太弱，不足以用于关键生产路径；对面向客户的应用，建议默认开告警与自动修复、关掉自动重新发布。Replit 自己点名的风险区是数据库迁移与索引类操作——恰恰是回滚最难的两类。
另一处对照也值得记下来。近期的另一类设计是让智能体每次要发消息、付款或删除时都弹一次确认；那种做法的弱点是人点习惯之后就成了形式。Replit 走的是相反的路：你在设置面板里做一次决定，之后它就自己发版。没有提示疲劳，也没有第二次过目——十月里拨的那个开关，到第二年三月还在替你决定事情。
还没说出口的几项
公开材料里没写的还有三件：哪些套餐包含这个功能、智能体夜间被叫醒做的工作怎么计入用量计费、以及自动发布关掉之后那份已验证的修复以什么形态存在——是草稿、拉取请求，还是一封邮件。这几项不影响功能上线，但影响账单和值班流程的设计。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
本站此前记录过运行时评测进入企业管理台的动向，也记录过主流框架连「谁批准了什么」都不写的缺口。Replit 这一款落在两者之间：它把运维闭环的后半段补上了，把决定权拆细了，却把「改错了怎么退回来」留给了平台之外。对正在考虑开这三档的团队，务实的顺序是先把告警打开跑一段时间，看看它叫醒你的频率与命中率，再决定要不要交出发布权。