ClickHouse实战：代理编码，是“神”还是“坑”？

首批编码模型和代理问世至今仅一年光景，而今天，关于在实践中使用代理编码 (agentic coding) 的看法却两极分化。一些人认为代理将取代我们所有的工作，另一些人则认为编码代理完全无用。有人出于各种原因厌恶 AI，也有人早已陷入 AI 狂热。如果你关注新闻，情况也无济于事：每天都是层出不穷的新一代前沿模型、更先进的工具、新的研究突破以及基准测试中令人瞩目的成绩，同时又伴随着低质量代码、安全漏洞、负面经济影响的研究报告，以及自主代理在实际工作中表现平平的结果。在许多公司，领导层试图强制推行 AI 的使用，而员工却感到困惑和不安。 我希望避免这种困惑，并阐明我的观点。我们在 ClickHouse 中使用编码代理，它们在特定场景下是极佳的工具。 注：我不会使用 AI 来撰写文本，因为我个人不喜欢这种方式。我写作速度很慢，但这是我自己的方式。 一些前提假设 在我们开始之前，请允许我提出一些假设。这些假设可能不完全正确，且难以逐一论证，但为了保持后续讨论的理性，我们姑且采纳这些假设。 大型语言模型不具备感知能力。它们没有意识、感质 (qualia) 或灵魂。通用人工智能 (AGI) 和超级智能短期内都不会实现。安全的 AI 既不存在，也不可能实现。AI 不会取代所有工作，但会取代其中一部分。也许它会取代你的工作，不过如果你正在阅读这篇文章，根据 贝叶斯推断，这种可能性较小。 为何是现在？ Claude Code 于 2025 年 2 月问世。我在一年前测试时，其用途有限。它能够成功生成小型 JavaScript 应用程序，特别是那些重复编写过多次的应用，并且可以编写一次性的 Python 和 Shell 脚本。在处理小型仓库中的各种样板任务时，它也助我一臂之力，例如 ClickBench。然而，当我将其应用到我们的主要 C++ 代码库时，它便力不从心，生成的代码也差强人意。 无论如何，这类重复性任务很多，即使在一年前，这些 Agent 也非常有用——公司内部对它们有着实际需求。因此，我们与 Anthropic、Windsurf 和 Cursor 签订了合作协议（解决所有法律和安全问题耗费了一些时间，并且许多问题需要在公司内部达成共识）。 我们开始使用这些 Agent，不仅限于重复性任务，还用于快速开发内部工具，例如性能测试和发布状态仪表板。我们还推出了自研的 Agent：DWAINE、CAISER 和 TRAISA（这些名字很奇怪，因为它们是 AI 生成的），以及 SQL 控制台中的 Agent 和 AI SRE Agent。这种趋势势不可挡，以至于我们收购了 Librechat 和 Langfuse，以增强 AI 可观测性。 Claude Sonnet 4.5（2025年9月）在质量上实现了显著提升——举例来说，团队生产力仪表板是通过 112 次提示交互会话构建而成的，我将其记录了下来，因此您可以回顾所有步骤。 即便如此，对于主要的 ClickHouse C++ 代码库而言，Agent 的价值依然存疑。2025 年 10 月，在公司全员研讨会上，我们主要讨论的是 Agent 在非常有限的任务中的零星应用案例，而且团队中有一半成员此前从未接触过代码生成 Agent。因此，问题来了——代码生成 Agent 真的适用于后端 C++ 开发吗？ 保持怀疑态度并非难事 一个普遍的说法是——如果你半年前在自己引以为傲的代码库上尝试了 Agent，它未能解决任务，反而生成了劣质代码，你定会大失所望。类似地，如果你打开一个 Agent 并键入“证明黎曼假设”，你同样会感到失望——因为（至少目前）AI 还没有那么强大。 因此，你可能会这样想——Agent 确实擅长 JavaScript，但它们对我的核心后端代码有用吗？Agent 在 Python 后端代码方面表现不错，但如果我坚持用 Rust 手写代码，还安全吗？Agent 在 Rust 服务端代码方面也行，但它们肯定无法取代我，毕竟我还在为管理核电站而编写的庞大且复杂的 C++ 代码库中费尽心力避免段错误？请不要抱有这种想法——如今，无一例外，每个人都将受到影响。 2025 年 11 月 Claude Opus 4.5 推出后，我对编程代理（coding agents）能力的看法彻底改变了。我尝试将其应用于 ClickHouse C++ 源码中简单而又细节繁琐的任务，接着是 CI 日志（CI logs）中 bug 报告的调查，然后是开发小功能…… 每次都超出我的预期。自从 Opus 4.5 问世以来，代理已能完全胜任大型 C++ 代码库的日常工作。 随着这些工具和模型的问世，2025 年对于编程代理而言是革命性的一年，而 2026 年则有望成为生产力大年。如今，我们拥有了极其强大的模型和成熟的工具，足以应对日常工作。在 2025 年持怀疑态度尚可理解，但怀疑论者在 2026 年将难以立足。 AI 编码的层级 代理式编程（Agentic coding）是 AI 辅助编程的一种形式，它分为三个层级： 第一层级：即“从 ChatGPT 复制粘贴”：向模型提问并从聊天中复制粘贴代码片段。这是一种有效的 AI 辅助编程形式，对于探索而言仍可接受。你可能自 2023 年以来一直在使用它。但与代理相比，它已然过时； 第二层级：在命令行（command line）或你的 IDE 中使用代理，无论是手动引导代理还是即兴编码（vibe coding）。我们目前正处于此层级； 第三层级：在隔离环境中运行多个代理，执行具备自动反馈的循环，开展规范驱动开发（spec-driven development），以及编排多代理（multi-agent）设置等。在 ClickHouse，我们确实拥有一些自主编程代理（autonomous coding agents）的案例，但我们才刚刚触及这一层级。这类工作的工具才刚刚开始涌现，而长期自主循环的结果可能仍存在不确定性。 可用工具 公司内部拥有丰富的可用工具。对于命令行接口（CLI）代理，我们主要使用结合 Opus 4.6 的 Claude Code，但也有一些人更倾向于使用结合 Codex 5.4 的 Codex CLI。由于每个模型提供商都会经常出现停机情况，因此随时准备在它们之间切换至关重要。我们使用 Copilot CLI 处理部分脚本，也部署了 Gemini CLI，但不知何故，目前的 Gemini 模型表现不佳。另有一小部分人使用 OpenCode。 一个良好的实践是，打开一个带有命令行接口（CLI）代理的终端窗口，同时打开一个 IDE 用于代码阅读。然而，也有一些人选择使用集成在 Cursor、Windsurf（出于某些不便透露的原因，我们同时使用这两种工具）或 VSCode 中的代理。我个人使用 CLion 阅读代码，但它过于缓慢和臃肿，并且经常卡顿数分钟，因此我无法放心地让它运行代理。 需要指出的是，市面上存在大量编码平台即服务（Coding Platforms as a Service）：Replit、Lovable、v0、Bolt、Devin 等。其中大多数都是 ClickHouse 的客户。当企业准备将核心竞争力之外的