Checkly 在 2026-09-01 通过官方博客发表了一篇工程实践复盘,标题是《We Let AI Agents Rewrite a 92M-Message-a-Day Service in Go. Zero Incidents.》,作者 Edvinas Janusevicius。文章本身完整展示了「让 Coding Agent 直接重写一个日均 9200 万条消息的关键路径 Node 服务
Checkly 在 2026-09-01 通过官方博客发表了一篇工程实践复盘,标题是《We Let AI Agents Rewrite a 92M-Message-a-Day Service in Go. Zero Incidents.》,作者 Edvinas Janusevicius。文章本身完整展示了「让 Coding Agent 直接重写一个日均 9200 万条消息的关键路径 Node 服务到 Go,生产环境零事故」这一工程实践的全过程。这是 2026 年下半年 Coding Agent 进入生产级代码改造场景的最具代表性公开案例之一,本文围绕这篇 Checkly 原文与 Checkly 在 2026-03-26 发布的另一篇《Checkly and the Agentic Software Layer》做合并解读,把这场实践背后的工程原则、可复用模式、失败模式整理出来,供准备让 Coding Agent 接手类似代码改造的工程团队参考。
在解读这场实践之前,需要先理解 Checkly 自家在 Agent 工程上的官方定位。Checkly CEO Hannes Lenke 在 2026-03-26 那篇文章里给出了清晰判断:50% percent of our active CLI users are already agents.——Checkly 自家活跃 CLI 用户里已经有 50% 是 AI Agent,这一数字本身就让 Checkly 的产品方向具备不可替代的现实感。Lenke 同时给出了三段对 Agent 工程的判断:November 24th, the Opus 4.5 release turned around the entire tech industry. This was the moment when agents became capable. Capable enough to write solid staff-level code.——把 Opus 4.5 的发布视作 Agent 真正能写出 staff-level 代码的拐点,而 Checkly 把 Monitoring as Code 这套 CLI 优先工作流作为 Agent 友好的天然形态,正因为 Agent 在终端里读文本、写文本、跑命令,MaC 把监控以 .ts 文件形式存放在代码仓库里,正好契合 Agent 的工作方式。
Checkly 在 2026-03-26 那篇文章里给出的三条工程原则,直接奠定了 92M-message Node 转 Go 重写能够「零事故」的基础。第一条是 Code & CLI 优先:Checkly 早早把监控配置从「专有 UI 加专有 DSL」迁移到 TypeScript 文件加 CLI 命令,Agent 在重写服务时可以同时读懂被监控的目标服务代码与监控配置本身,这等于让 Agent 在改造前就有了完整的「当前行为规约」。第二条是 Agent Skills 开放标准:Checkly 把自家 CLI 与 docs 打包成符合 Claude Code / Cursor / OpenAI Codex / GitHub Copilot 共同支持的 Agent Skills 开放标准,任何 Coding Agent 客户端只需要 npx checkly skills install 就能拿到与 Checkly 交互的全部知识;这等于把「Agent 能不能搞懂 Checkly 自己的工具栈」这个最大不确定性提前消除了。第三条是确认协议:Checkly 在 CLI 里为写操作实现了一套 confirmation protocol——破坏性或对外可见的命令会先返回一个 JSON 信封描述变更、提供一个确认命令,Agent 必须显式跑一次确认才能真正落地;这条协议对工程治理至关重要——没有它 Agent 会变成 liability,有了它 Agent 才是 force multiplier。
把视线从 Checkly 的工程原则拉回到 92M-message Node 转 Go 重写本身的工程实践。这场重写涉及的是一个日均 9200 万条消息的关键路径服务,任何一次上线失败都会被用户直接感知。Checkly 能做到「零事故」,从工程复盘的角度可以提炼出五条与 Coding Agent 相关的关键约束。第一条是「代码与监控共仓库」:Node 服务代码、Go 重写代码、Checkly 监控配置、测试用例、CI 配置全部在同一个 Git 仓库;Agent 在改造过程中可以同时读懂「被改造目标」「预期行为」「当前监控」三类信息,这等于让 Agent 拥有了近乎人类工程师级别的上下文。第二条是「测试即合约」:Node 服务原本就有完整的单元测试与集成测试覆盖,Agent 在重写到 Go 时把这些测试当作行为合约直接搬到 Go 版本,只要 Go 版本能跑通所有测试,功能就等价于 Node 版本。第三条是「影子流量加金丝雀发布」:Go 服务不是一次性全量替换,而是先以影子流量模式接收 1% 真实流量,与 Node 服务并行处理同一份请求并对比响应;对比一致后再切到 5% / 25% / 50% / 100% 的金丝雀比例,每一阶段都对错误率、延迟、资源占用做严格对比。第四条是「可中断回滚」:任何一步切流比例发生异常(错误率超阈值、P99 延迟突增、内存泄漏),自动触发立即回滚到 Node 版本,Agent 与人类工程师都不需要手动介入。第五条是「Checkpoint 评审」:Agent 提交的每一个 PR 都必须有人类工程师 code review;Checkly 把这场重写定位为 Agent 写草稿、人类把关最后一步,而不是 Agent 独立完成改造。
Checkly 的 92M-message 重写案例里,有几个值得展开的工程细节。第一个细节是「类型系统迁移」:Node 服务是 TypeScript 类型,Go 服务是 Go 类型,Agent 在迁移时必须把 TypeScript interface 转 Go struct、TypeScript union type 转 Go interface 加 type switch、TypeScript generic 转 Go generics;Checkly 让 Agent 在迁移前先输出一份类型对照表,人类工程师对照表先做一次确认,再让 Agent 写代码。第二个细节是「异步模型迁移」:Node 服务是单线程事件循环加 Promise,Go 服务是 goroutine 加 channel;Agent 在迁移时必须把每一个 await 替换成对应的 goroutine 加 select,Checkly 让 Agent 把异步边界用注释显式标注出来,后续 code review 可以一眼看出哪里是边界点。第三个细节是「依赖替换」:Node 服务的 npm 依赖在 Go 生态里未必有等价物,Agent 在迁移时必须为每一个外部依赖单独做一次等价物调研,Checkly 把这一步做成了显式的 ADR(Architecture Decision Record),每个依赖的去留都有据可查。第四个细节是「可观测性平移」:Node 服务的 Prometheus metrics / OpenTelemetry spans / 结构化日志,在 Go 版本里必须保持 metric name 与 label 一致,否则监控告警规则会全部失效;Checkly 把这条作为重写完成的硬验收条件之一。
把 Checkly 92M-message 重写案例放进 Anthropic 在 2024-12-19 发布的《Building effective agents》给出的方法论坐标里,可以看到这场重写几乎是 simple, composable patterns 这一原则的完美示范。Anthropic 给出的核心判断是:Over the past year, we've worked with dozens of teams building large language model agents across industries. Consistently, the most successful implementations were not using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns. Checkly 在重写过程中没有引入任何新的 Agent 框架,所有动作都是「读已有代码」「按测试合约翻译」「影子流量对比」「金丝雀发布」「人类 code review」这五步的反复循环——这是 workflows 而不是 agents 的典型形态;但 Checkly 之所以能让 Agent 跑完这五步,是因为 Checkly 自身的工具栈(Code 与 CLI 优先加 Agent Skills 加 Confirmation Protocol)已经把 Agent 的工作面简化为读 .ts 写 .go 跑 CLI 看 metric。
理解 Checkly 案例给整个 Coding Agent 工程的真正启示,关键在于它把「Agent 重写生产代码」这件事拆成了 Code 与 CLI 优先、Agent Skills、Confirmation Protocol、影子流量、金丝雀、Checkpoint 评审、可观测性平移这七层独立工程护栏。任意一层失守,前面六层全部白做。Anthropic 在 containment 报告里反复强调的 defense-in-depth,本质就是这套七层护栏的抽象表达;Checkly 把抽象原则落到了具体可执行的工程动作上,这是 2026 年下半年 Coding Agent 进入生产级代码改造场景的最具操作性参考。
把视线从 Checkly 案例拉到工程团队想要复刻这场实践时需要做的几件事。第一件是代码与监控共仓库:把目标服务的代码、测试、监控配置、CI 配置全部纳入同一个 Git 仓库;如果目标服务当前没有完整的监控覆盖,需要先用 4 到 6 周时间把监控补齐,否则 Agent 在改造时会失去当前行为规约。第二件是测试覆盖率门槛:目标服务的单元测试与集成测试覆盖率必须达到 80% 以上;低于这个门槛,Agent 在重写时会因为测试不能完整描述原行为而频繁踩坑。第三件是 Agent Skills 安装:把目标服务自家 CLI 与 SDK 打包成 Agent Skills 开放标准;如果目标服务没有自家 CLI,需要先把最常用的运维操作封装成 CLI。第四件是 Confirmation Protocol 实现:为目标服务的部署、切流、回滚、数据库迁移操作实现一套 confirmation protocol;任何破坏性操作必须先返回 JSON 信封加等待显式确认。第五件是影子流量加金丝雀基础设施:确保目标服务的部署系统支持影子流量模式与金丝雀发布,否则任何 Agent 主导的改造都缺乏安全网。这五件事做完,才能让 Coding Agent 真正具备重写生产代码的工程基础。
把视线从落地路径拉回到 Coding Agent 工程的整体趋势。2026 年的 Coding Agent 讨论里,有一个反复出现但很少被明说的判断:Coding Agent 真正能进入生产级代码改造,不是因为 Agent 本身变强,而是因为工具栈本身变 Agent 友好。Checkly 在 2026-03-26 那篇文章里给出的 50% percent of our active CLI users are already agents 是这一判断的最佳量化——当 Agent 成为工具栈的主要使用者,工具栈的设计起点就会从人类使用转向 Agent 使用,这一转向会让 Code 与 CLI 优先、Agent Skills、Confirmation Protocol 这类设计原则成为新的工程基线。下一阶段的 Coding Agent 工程,会越来越围绕工具栈 Agent 化、工作流可中断、代码与监控共仓库这三个轴心展开;Checkly 的 92M-message 重写案例,也应当沿着这一框架被反复引用与复刻。
最后回到工程基线本身。Checkly 92M-message 重写案例的真正教训,从来不是 Agent 已经能写生产代码了、重写零事故所以 Agent 可以独立负责大型改造,而是工具栈本身必须为 Agent 重新设计,Code 与 CLI 优先加 Agent Skills 加 Confirmation Protocol 加影子流量加金丝雀加 Checkpoint 评审加可观测性平移这七层独立护栏必须全部到位。把 Coding Agent 当作万能工程师而工具栈维持人类友好,只会让 Agent 在生产改造里反复翻车;真正落地的项目,无一不是先重塑工具栈,再让 Agent 在新工具栈上跑完整工作流。Checkly 在这场实践里给出的不是 Agent 多强的故事,而是工具栈怎样变成 Agent 友好的工程范本。