首批编码模型和代理问世至今仅一年光景，而今天，关于在实践中使用代理编码 (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 的客户。当企业准备将核心竞争力之外的开发工作外包时，这些平台可以很好地替代传统外包模式。如果运用得当，这是一个巨大的市场。不过，我们内部不使用这些工具进行日常工作。
OpenClaw 值得一提。出于安全原因（我们部署了 端点安全 (endpoint security) 措施来管控），工作机器上不允许安装 OpenClaw。但我们已经在具备有限访问权限的隔离机器上运行了多个 OpenClaw 实例，供工程和非工程团队使用。
如果您想开始尝试，我的建议是：在终端中使用 Claude Code，并保留 Codex 作为备用选项。
为何优先选择 CLI 代理 (CLI agents) 而非集成开发环境 (IDE)？
Claude Code 是一款非常强大的工具，但它可能运行缓慢，并且存在 Bug 和小故障 (glitches)。尽管如此，我仍然推荐优先使用它而非集成代理 (integrated agents)。为了阐明原因，下面列出了 Claude Code 能够完成的一些任务（并非完整列表）：
编写计划并进入计划模式；
向用户提问以进行澄清；
管理上下文：在上下文不足时精简对话；
启动子代理 (subagents)；
在一个会话中并行执行多任务；
为特定任务调用更小的模型；
研究您的代码库；
在网络上搜索；
调用您的工具；
表明其不确定性；
使用既有技能；编写新技能；
读取并 Grep 日志；查询数据库；使用 GitHub；
构建代码，并使用 clangd 确保代码的正确性；
提交并推送更改，监控并查看 持续集成报告 (CI reports)；
TLDR（太长不看）：如今，您可以通过 CLI 代理 (CLI agents) 获得大多数前沿特性。
ClickHouse 内部的使用场景
我不想自上而下地强制推行 AI 的使用，这既不合理，也可能 导致灾难。为用而用 AI 毫无意义。相反，我希望通过我自身的实践案例来激励大家。
所有这些示例都来自 ClickHouse 开源代码库以及其他开源代码库。
为了在公司内部展示这些示例，我还快速开发了一个微服务，用于查看和分享 Claude Code 会话，它 被命名为“Alexey Prompts”。出于隐私考量，我不会分享这 3000 个包含 270 亿个 Token 的会话，但您仍可自行使用这款工具。
为你生成代码
作为一名经验丰富的工程师，你对自己的代码库了如指掌。你注重代码质量，力求其简洁优雅……即便如此，你仍然可以使用编程代理（coding agents）！你只需明确告知需要修改哪些文件、编写哪些函数以及具体实现方式、需要删除哪些代码，代理便能代劳这项最枯燥乏味的工作——编写代码。
对我而言，编写代码通常需要一块大显示屏、一套趁手的机械键盘和鼠标、一个我早已习惯的集成开发环境 (IDE)，以及充裕的时间。然而，如果你身处异地，身边只有一台笔记本电脑，又该如何是好？此时，你可以求助于编程代理，让它来完成任务。有了代理，即使是使用小巧局促的笔记本电脑，也能让人勉强接受，并且能够更快地完成工作。
完成搁置的拉取请求
在这个案例中，我正在评审一位外部贡献者的代码。我们经过了多轮反馈，我曾要求他们重写代码的最后一部分内容，以便将其合并。然而，之后这位贡献者便销声匿迹了——也许是喜得贵子，我不得而知，但这情有可原。不过现在，我无需等待孩子长大，只需请求编程代理来完成这个拉取请求 (pull request)。
编写样板代码和集成
当你需要对多个地方（例如构建系统等）进行重复性的修改时——请交给编程代理来完成！手动执行毫无意义，你从中也得不到任何益处。代理能够以更少的错误完成此类任务。这种场景是初次尝试使用编程代理的绝佳选择。
我记得在进行 Hadoop+Spark 基准测试时，要找到正确的 JDK 版本并按照正确的顺序完成所有安装是多么艰难。编程代理让这些对开发者不够友好的技术变得更具可用性。也许它们最终能帮助我们安装 Trino 呢？
现代云基础设施的工作体验，常常让人感觉像是在瓶中造船。当你使用诸如 AWS Lambda 或 Kubernetes 这样“精妙”的技术时，你需要编写大量的配置，将它们部署到某个地方，然后祈祷它能正常运行，接着反复尝试数百次，直至成功。很难想象还有什么比这项工作更令人沮丧了。但如果你求助于编程代理，它们犯错的可能性会大大降低。
请记住，你仍然需要审查代理生成的内容并批准这些修改。或者至少，不要将其直接应用于你的生产基础设施。
解决合并冲突
当你的拉取请求 (pull request) 处于这种状态时，你可能会想——我明天会完成它。然而明天却迟迟未至，你开始对自己失去信心。
在处理这类问题时，代理几乎在 100% 的情况下都能比人类做得更好。即使是简单的合并冲突，也应该使用它……因为作为人类，你可能会犯简单的拼写错误，在反复修改上浪费时间，或者引入 bug。
但你需要审查其生成的代码差异 (diff)。这种“代理执行，人工审查”的模式能提高代码质量，因为很难审查自己刚写完的代码，但借助代理，你可以以全新的视角审视代码。
跨代码库移植代码
对于已分叉的代码库（如旧分支、复刻 (fork) 项目），甚至是架构相似但独立的项目，代理都能自动将功能从一个移植到另一个。即使是采用不同编程语言的代码库，这项功能也能奏效。
一个例子是 Polyglot 项目——一个用于转换不同 SQL 方言的库。它提供了 ClickHouse 方言解析器，我决定使用数万个 ClickHouse 测试来 验证它。我很快发现它实际上并不真正支持 ClickHouse SQL，只是表面上如此。因此，我决定修复所有不兼容之处，确保所有 ClickHouse 查询都能成功解析。
代理在 36 小时内（其中 API 调用时间为 23 小时）完成了这项任务，费用约为 500 美元。我不得不说，这是我投入成本最高的一次会话，但它已成功集成并 合并到该库中。如今，我们可以将其用于我们自己的需求，例如在浏览器中解析 ClickHouse SQL。
另外值得一提的是，Polyglot 库本身是借鉴了 Python 库 sqlglot 的思想而创建的。
但这种方法也存在一些需要考虑的因素：
1. 当你的 agent 审查或使用他人的代码时，你必须遵守其他代码库的许可证，包括适当的署名，因为这将构成一个衍生产品；
2. 如果他人的代码质量不佳，存在设计缺陷，agent 能够修复表面化的 bug，但若要进行代码重构，则需为其提供适当的指引；
3. 如今，开源代码的重用、回收和再封装变得前所未有的便捷，即便是在竞争对手之间亦是如此。
小型重构
小型但繁琐的重构工作：
你不愿手动执行；
你渴望完成却一再拖延；
请 agent 协助！
完善产品，解决遗漏
任何产品都不可避免地会积累大量的 细枝末节的问题和痛点。这些问题通常未被纳入计划，工程师往往缺乏动力去处理计划之外的任务，因此迟迟得不到解决。最糟糕的做法莫过于与经理讨论修复这些小 bug。
如今，修复这些小 bug 不再有任何借口。不必征求经理意见，直接寻求 agent 的帮助！
处理不熟悉的代码库
初次接触新代码库？启用 agent，提出疑问，并请求建议。
代码评审
首先，你可以启用 Claude 来进行代码评审。它能够访问你本地机器上的代码，有足够时间阅读代码，能够在互联网上搜索，调用各类工具，并执行代码构建与测试。如果代码由 Claude 编写，可交由 Codex 进行评审；反之亦然。
更值得关注的是自动化代码评审工具，我们对此进行了大量尝试。
最初，我们从集成于 GitHub 的 Copilot 入手。起初，它在发现细微 bug 方面的表现令人印象深刻。然而，与在本地机器上调用 Claude 的效果相比，其能力可能仅为后者的 5%。我们尝试通过自定义指令对其进行适配，但不知何故，GitHub 上的 Copilot 无法遵循这些指令（已提交问题单）。
随后我们试用了 Cursor bugbot（测试版）。它给出的评审意见质量极高，令人印象深刻，简洁且一针见血，而且几乎无需定制。我们后来停止使用了它，因为在测试阶段，其定价模型存在一些不兼容问题。因此，我们本会等待其正式发布 (GA)，但很可能不会，原因如下：
我们为代码评审构建了自己的机器人。它通过脚本调用 Copilot CLI，但与 GitHub Copilot 相比，其差异堪称天壤之别。如今，这个机器人能够遵循我们所有的指令，其质量之高，每天都令我赞叹不已！
现在，人工评审人员只需关注架构和变更的合理性，而自动化评审工具则能找出资源管理 Bug、竞态条件 (race conditions) 和边缘情况 (corner cases)。
另外值得一提的是，目前市面上提供了大量小型自动化代码评审服务。在我看来，如果一家公司能通过单个提示词 (prompt) 就被轻易复刻，那么它的价值便荡然无存。
复杂 Bug 的排查
借助于 Claude Opus 4.6，我们成功攻克了一个复杂 bug。该 bug 由过去六个月内的多项变更共同导致，且在 ClickHouse Cloud 和我们的 CI 中极难复现。
人工曾三次尝试修复此 bug，但均告失败。最初，即使通过 agent 尝试（在一个月内进行了数次尝试），也未能成功。然而，在反复提问并尝试多种方法后，agent 最终经过一小时的思考，完成了一行代码的修改，并提供了完整的解释和测试。这或许是最昂贵的单行代码，但其成本仍然低于 $30！
在其中一种方法中，我同时使用了 Claude 和 Codex，它们相互质疑对方的推理。我将所有设置调整到最高级别，并明确要求它们分析所有历史方法、大量 CI 日志，并验证每一个假设等等。在此过程中，它提出了许多似是而非的假设，需要工程师具备大量预备知识和丰富经验才能筛选出正确信息。虽然它给出了一些初步修复，解决了其他问题，但首次尝试并未触及根本原因。
我们有充分信心相信，通过最终的尝试已成功修复了该 bug。然而，我们仍需等待数月时间，并完成数十亿次（包括压力测试和模糊测试）测试调用，才能最终确认此次修复彻底奏效。
调查常规 bug
我注意到，在一段时间内，我们某个测试套件一直没有输出报告，这引起了我的警觉（毕竟我们的代码并非完美无缺）。我在 Slack 上向我们的 CI 团队提问，但当时是周日，团队成员都在休息。于是，过了一会儿，我将同样的问题转而询问了 Claude。
Claude 发现，压力测试之所以总是报告成功，是由于代码中存在一个简单错误。这个错误（忘记了 if 或 break 语句）显然是人为失误造成的……这也进一步印证了：agent 在代码编写和审查方面的表现优于人类！
修复压力测试后，大量问题随之浮现，这些问题是在压力测试失效期间累积的，我不得不动用 agents 来修复所有这些错误。
事故调查
Agents 擅长读取日志并验证假设。日志不一定存储在文件中，它们可以与 ClickHouse 完美结合，而我们所有的日志、指标和追踪 (traces) 都存储在 ClickHouse 中！
以下是一位值班工程师的反馈：
我正在大量使用 claude（希望没有信用额度限制），并不断探索它的局限性，学习何时以及如何对其进行质疑。总的来说，我感觉在初步调查阶段效率提高了很多（原本需要三四天的工作，现在一天就能完成）。但是，一旦它形成某种理论，你就需要不断要求它用数据和日志来证明，然后进行复核并要求进一步完善，因为它经常无法提供可靠的支撑或直接给出错误的信息。
然而，也存在一些注意事项：
1. 我们无法将所有日志都提供给模型提供商，即便考虑到提供商的零数据保留政策也是如此。对于通用基础设施日志，我们可以这样做，但通常不适用于来自客户服务的服务器日志。首先，日志必须经过仔细匿名化处理，并且只有非敏感部分才能由模型处理。然而，即使是某个客户服务的指标趋势 (trends of metrics) 也可能属于敏感数据，因此除非获得明确批准，否则我们无法将其提供给模型；
注：我们在非常有限的场景下使用自托管的 Qwen。
2. 调查的成功与否，在很大程度上取决于工程师的资历。Agents 会生成许多看似合理却错误的假设 (hypotheses)，你需要首先将其排除。这项工作非常艰巨，但它可能不为人所见，甚至容易被忽视。
简单来说，一名 SRE 能够利用 agents 成功调查生产问题，而一名 VP 却可能采纳错误的假设，从而无法解决客户问题。
修复不稳定的测试 (Flaky Tests)
每天，ClickHouse CI 平均运行大约 2000 万到 8000 万次测试，涉及 600 次提交 (commits) 和 300 个拉取请求 (pull requests)。其中涵盖了针对多种构建配置 (build configurations) 的各项测试套件运行，以及利用模糊测试器 (fuzzers) 和压力测试 (stress tests) 进行的随机化测试。ClickHouse CI 令我引以为豪，在我看来，它对于 ClickHouse 的开发至关重要。
有时，测试会呈现“不稳定”（flaky test）状态，在大多数情况下，这并不意味着代码存在缺陷，而仅仅是与某些随机环境因素偶然巧合的结果。在少数情况下，不稳定测试确实能揭示代码中的缺陷，但若要关注这类缺陷，我们必须先减少其他不稳定测试所带来的干扰。
我们如何处理不稳定测试呢？首先，我们从不屏蔽它们，也从不自动重试测试（这是不允许的），因此每次失败都必须进行调查。当测试因随机因素而失败时，我们会思考两件事：一是如何通过改进测试本身，来限制其对该随机因素的依赖；二是如何均衡化随机性，确保随机因素能以均匀随机的方式出现，而非稀有现象。我们甚至会刻意增加测试基础设施内部的随机性，例如，我们会随机化线程调度。我为我们的持续集成（CI）系统感到非常自豪，甚至可以一直谈论它。
然而，问题在于多年来我们未能彻底解决所有的 CI 发现问题。我尝试了各种方法来解决这个问题：我创建了一个仪表盘（dashboard）并将其展示在办公室的电视上；我们定期召开解决不稳定测试的会议，每周团队会议都必须从解决不稳定测试开始；我们甚至专门安排了数周的冲刺（sprint）周期，完全用于修复 CI 发现的问题。而我的目标并非仅仅修复这些不稳定测试，而是实现一种状态：届时我们将能添加更多的随机化检查和新的模糊测试（fuzzing）方法。
最近唯一真正奏效的方案是——通过智能代理（agents）加速修复工作。在一月和二月，借助智能代理的帮助，我提交了 700 个用于修复测试和 CI 基础设施的拉取请求（pull requests），并由团队审查和合并了这些变更。这一成果比以往任何举措都要高出一个数量级，因此，我们成功将每天发现的问题数量从大约 200 个降低到每 10,000,000 次执行仅 3 到 5 个。
即使这是人工智能（AI）唯一的应用场景，它也足以证明其价值，因为没有 AI，这个成果是无法实现的，这已为多年的数据和多项组织努力所证实。
一周前，我们新增了两个自主代理（autonomous agents）：
Groene.AI —— 负责修复易失败的测试并提交拉取请求。在大约 30% 到 50% 的情况下，修复方案直接完善，其余情况则需要根据反馈进行迭代和完善；
ClickGap —— 负责发现边缘用例并补充缺失的测试。
这些智能代理 (agent) 就像是受限且定制化的“利爪”（它们基于自定义代码构建，与 openclaw 没有任何关系）。
安全研究
ClickHouse 拥有一个公开的 漏洞赏金计划，我们为发现的漏洞支付报酬。然而，我们也收到了大量无效提交，这些是渴望金钱的人利用 AI 胡乱生成、只为索取赏金的低质量内容。该计划主要由 BugCrowd 负责管理。
但我们也收到真正有价值的发现，包括与 ClickHouse 服务器本身相关的漏洞，每年大约 10 例。在最近半年内，所有真实的漏洞发现，无一例外，均通过编码智能代理 (coding agent) 发现。AI 智能代理 (AI agent) 还能协助进行 POC (Proof-of-Concept) 漏洞利用的开发。
总而言之：对于安全研究人员而言，到 2026 年如果仍不采用 AI，就只有两条路可走：要么开始使用，要么选择退休。
低成本实验
是否曾想尝试一些重大变革，却因人力和时间成本过高而却步？现在只需请求一个智能代理 为你代劳，待其完成后，再评估其是否符合你的需求。
优化问题
只需给智能代理设定一个明确的目标，它便能为你进行穷举式优化！
在此示例中，一个智能代理 将 ClickHouse 的构建速度优化 了 28%。我们手动挑选了其中满意的特定提交 (commit)，并将其集成到项目中，现在每次构建都能享受这一速度提升。尽管在大型服务器上彻夜运行智能代理的成本不菲，但其所带来的回报在最初几天内便已显现。
穷举式解决繁琐问题
多年前，我们的客户服务部门曾面临一次紧急情况，根本原因在于，当用户对表执行 DETACH 后再 ATTACH 操作时，表未能完全保留其某些特定属性。我们解决了这个问题，随后集思广益，思考如何在未来杜绝此类问题的发生：我们可以在测试中加入随机的 DETACH 和 ATTACH 查询！于是我们 着手实施，但这项工作非常难以完成，因为它需要对数百个与这种随机化不兼容的旧测试进行标注。
我的原则是：永不遗忘。因此，我持续每周、每月、乃至每年几次地提醒大家这项任务。但最终，我成了唯一一个还在关注如何避免那个早已解决的（却又反复出现）问题的人。
然而，就在一个月前，我借助 agent 的力量，成功让这项任务“死灰复燃”，如今它已接近完成！现在，我能找出所有我们自 2020 年、2019 年乃至更早以前未能解决的任务，并计划一场“复仇”。
新功能原型开发
你可能想实现一项新功能，却不确定其真正价值、实际可用性如何，甚至不确定它最终是否会被真正实现。现在，你无需提前规划——你可以先开发一个所需功能的 粗略原型 并进行实验。
Vibe-coding 工具与内部应用
“vibe coding”这个术语由 Andrej Karpathy 提出，意指不审查 agent 生成的代码。人们对这个词褒贬不一，它带有许多负面含义，有时人们会以贬低或不屑一顾的方式提及“vibe-coded”。但我认为，事实不应如此。
在 ClickHouse 的主代码库中，我们不允许未经审查的代码。然而，我们有大量通过 vibe-coding 开发的内部工具和 小型应用。任何安全和基础设施暴露有限的项目，都是 vibe-coding 的有效应用场景。
Vibe-coded 工具的质量也参差不齐。有些人可能对一个一次性页面感到满意，即便它功能不全、设计欠佳（默认的 Claude 设计辨识度很高）。而另一些人则会通过数百次 prompt 迭代来打磨和验证产品，提供创新的自动化测试方法。这对于追求高质量的产品来说是不可避免的，因为 agent 往往倾向于偷工减料。
我的朋友以 AI World Clocks 为例，作为反驳 vibe-coding 的论据，但这更多是个玩笑（因为只需简单修正 prompt，让 agent 截取屏幕截图，就能得到完美结果）。
留给读者一个问题：你认为我们为什么会采用 agentic coding，却不将 vibe-coding 用于 ClickHouse 服务器呢？
驱动同事协作，实现目标
这是我最喜欢的方法之一。通常，你希望某项工作得到推进，但在 Slack 上询问同事时，他们会回复说，等假期后的下一次周会再讨论规划，并创建一个 Linear 工单。而这，基本上就意味着这项工作永远不会有人去做了。
在这种情况下，你可以使用 agent 完成原型设计，提交到其代码仓库并请求审查。根据我的经验，这会大大加快项目进度！
举个例子：我在火车上旅行时，打开 ClickHouse 文档，发现搜索栏无法使用——点击后毫无反应，甚至无法输入内容。我先在 Slack 上询问，几分钟后又咨询了一个 agent。agent 告诉我，搜索栏必须加载 25 MB 的 JavaScript 包才能启用。接着，它提到了 React hydration（我对这个概念一无所知），然后 修复了这个问题。
(问题在于——它为何要加载 25 MB 的 JavaScript？如果我们的文档是 vibe-coded，我还能理解，但它们并非如此。这不过是 JavaScript 的常态罢了。)
另一个例子是，一个任务悬置两年之久，它阻碍了代码中一项重要迁移的推进——在这两年里毫无进展。客观来说，这是一项非常艰巨的任务，已接近当前模型的能力极限。为了探究其能力边界，我让 Claude Opus 4.6 和 GPT Codex 5.3 都尝试解决。结果 Opus 4.6 耗时 3 天，Codex 5.3 耗时一周。它们的智能水平非常相似——仅勉强能解决。随后我询问同事哪个解决方案更好，他们回答：“都一塌糊涂。”我接着说，我敢打赌，即便没有 AI，他们一个月内也无法做得更好。他们没有应战，也确实没有在一个月内解决。不过，今天我们有了 Nikolai 提供的第三个解决方案，它结合了卓越的工程能力与最新 AI 模型强大威力。
加速反馈闭环，降低跨团队沟通成本
跨团队沟通开销是导致大型组织效率低下的主要因素，因为要完成一项任务，就需要与更多人协作，而这些人又负责问题域的不同部分。如果每位员工都能拥有一支小型工程师团队，并能瞬间召唤他们，那会怎样？
这正是编码 agent 的价值所在。使用编码 agent，就相当于与一支由 3 到 7 名工程师组成的团队合作——他们从不休假、从不睡觉，并且极少争执 :)
半真半假。优秀的工程师依然大有可为。
使用建议
AI 是思维的工具，而非思考的替代品。 最稳妥的做法是把编码智能体 (coding agent) 视为一种工具，就像你的编辑器乃至键盘一样。利用它来完成你想要做的事情。
AI 是一种乘数效应——优秀的工程师将如虎添翼，平庸的工程师感受不到明显差异，而糟糕的工程师则会造成更大的破坏。
从小任务入手，循序渐进地提升对其处理更复杂任务的信任度。 当前的 AI 模型仍存在诸多局限，你需要培养一种直觉，辨明哪些任务适合由智能体完成，哪些则超出其能力范畴。但同时，也要做好准备，当更优秀的前沿模型发布时，及时重新评估你的预期。保持较低的期望，并根据实际成果逐步提升，这是完全可行的。对于 AI 怀疑论者而言，这亦是一条明智的路径，因为尝试解决大型复杂任务只会进一步加深他们的怀疑。
务必验证每一次变更。增加测试数量。 拓展测试方法。在 ClickHouse，我们有幸通过在 CI (持续集成) 和测试方面的投入，取得了最佳成效。
尝试使用最新的模型。对于高难度任务，可同时尝试多个供应商提供的模型。 在循环中不断质疑现有成果，并持续推动寻求更优解决方案。
将指导原则保存至 CLAUDE.md / AGENTS.md。 这一点可能存在争议。请勿在指令中添加过多内容（否则模型很可能会忽略大部分指令）；请勿指明不应做之事（模型有时如同孩童，反而会去执行你所禁止的行为）；也请勿过度复杂化问题（模型具备一定的智能，不妨给予其一些信任）。
将常见任务保存为技能和工具。 例如，教授模型如何查阅测试历史记录，以及如何在日志数据库中进行搜索。
不限于编码用途。 命令行接口 (CLI) 智能体远比你想象中更具通用性，不妨将其应用于各类日常事务。
完整规范与过度规范。 当你使用编程语言编写代码时，需要精确地指定你的意图。与智能体协作时，你并非必须如此——但尽可能精确地阐明你的意图也无妨，这有助于提升产出效果，而且我们依然具备进行这种精确规范的工程能力。
阅读代码、智能体响应及其思考过程，尤其是其规划。 使用智能体意味着你需要进行大量的阅读与思考，对此没有捷径可言，且过程可能会令人精疲力尽。但一旦你感到与智能体协作已力不从心，请务必立即停止——否则，其结果将是灾难性的。
提出后续问题，质疑并改进现有方法和解决方案。
并行运行多个会话。 但数量不宜过多，我认为五个 Agent (代理) 就已足够。鉴于当前模型的限制，在 C++ 代码库中工作的 Agent 通常每十分钟就需要人工修正和手把手指导，因此需要你付出相应的精力来关注它们。
在独立的虚拟机上运行无人值守会话。 这与上述建议看似矛盾，但对于特定任务，例如自主实验、原型设计、优化以及收尾阶段的工作，这种做法是行之有效的。
至少准备两种来自不同模型提供商的工具。 当前，模型提供商是服务可靠性最低的类型之一，几乎每天都会发生停机。考虑到需求呈爆炸式增长，这种情况不难理解，我甚至对他们能在此环境下生存下来感到钦佩。务必做好准备。
请保持礼貌和冷静，不要说脏话，更不要侮辱 Agent (代理)。 如果你侮辱这些优秀的模型，我会替你感到羞愧。不开玩笑——大语言模型 (LLM) 据说没有意识或感情。但我确实有两个理由建议你不要对模型无礼。首先，模型对人类行为的模拟过于出色：当你在沟通中过于强势，出现侮辱和威胁时，模型会不惜一切代价尝试纠正错误，有时唯一的办法可能就是：删除你的主目录并清除生产基础设施。第二个原因在于，如果你甚至对一个无生命物体都表现出恶劣的沟通方式，这本身就反映了你的不良行为，并可能让你成为一个更糟糕的人。
开源中的 AI
你可能已经注意到 GitHub 经常宕机。出现这种情况，是因为每个 AI 实验室都在疯狂下载 GitHub 上的所有可用资源，以及大量自主 Agent (代理) 也在试图自主完成某些无人知晓的任务，这些行为都对 GitHub 造成了巨大的负载。
我们也正经历着大量涌入 ClickHouse 的贡献，其质量参差不齐。ClickHouse 开源至今已有近十年，与贡献者协同合作是我们工作不可或缺的一部分。我们非常感谢所有提供反馈的贡献者和用户，深知即使是草稿或半成品，即便最终未能合并，也同样具有其价值。
一年前，我经常收到质量低下、甚至格格不入的拉取请求，这让我怀疑贡献者可能使用了 AI，才导致代码如此糟糕。而今年，情况则截然不同：当我收到一个包含变量拼写错误、内存管理方面不应有的疏忽以及竞态条件的低质量代码拉取请求时，这反而让我怀疑贡献者是否忘记使用 AI agents 来编写这段代码。因为代码代理（coding agents）能够显著提升代码的最低质量水平。
我决定为 ClickHouse 制定一项 AI policy，该政策全面拥抱 AI 的使用，并支持在 ClickHouse 代码库上进行任何合法的实验和研究。
现代 AI 模型在 ClickHouse 代码上表现如此出色，因为它是一个开源项目，而且 AI 模型直接使用我们的代码和 issues 进行了训练。例如，Claude 生成了 clickhouse-client 的命令行参数，这些参数现在无论在代码还是文档中都已不存在，但在一年前是存在的。它还尝试在字符串中插入一个终止零字节，而我在 去年八月的一次大型重构中 将其全部移除。这意味着——如果你是一名数据库开发人员，并使用代码代理（coding agents）编写另一个数据库，它们很可能会按照 ClickHouse 的现有模式来构建它。
我乐于看到 ClickHouse 开源代码在 AI 领域得到更广泛的应用。我将对所有关于 AI 可复现性研究、AI 模型比较、代理（agents）自主性研究、软件性能和可靠性研究的论文都非常感兴趣。
AI FUD 检查清单
许多人对 AI 感到恐惧，甚至有不少 AI 的反对者。我整理了这份检查清单，作为一份讨论要点，旨在探讨人们可能担忧的方面。
大量使用代理（agentic）编程可能会变得过于昂贵。
这确实有可能发生，但目前 AI 使用量仍有很大的增长空间。尽管衡量 AI 使用量增长带来的投资回报率（ROI）存在难度，但预计它能为公司的所有部门带来积极收益。
AI 泡沫可能破裂，AI 服务将变得更难获取。
关于人工智能 (AI) 热潮所创造的价值，存在诸多争议。它催生了前沿 AI 模型——这些耗资巨大的奇迹，提供了大量新的可能性。但即便我们假设其发展速度会放缓，我们最终仍将拥有许多这类奇迹，包括可在各类硬件上运行的开源模型 (open-weight models)。
使用 AI 会使你能力退化，或丧失工程师技能。
当然，也存在对立因素。编程智能体 (agent) 是极佳的学习工具——前提是你愿意投入精力去学习。我曾通过旁观智能体的工作过程，学到了许多使用 git 和 bash 的方法。然而，现实中也存在许多人会懒散地使用智能体，就像操作一台老虎机一样。
过度使用 AI 可能会导致产品质量下降。
AI 提供了诸多提升质量的途径。最简单的方法是避免将其用于开发新功能和编写大量代码。相反，应将其用于调查 Bug、验证假设、执行严格的代码审查、增加测试用例、拓展测试方法、发现边缘情况等。为了保持高质量标准，绝大部分工作，包括 AI 的产出，都必须投入到质量保证环节。
AI 的过度使用可能导致 AI 诱发的精神困扰。
这种情况确实存在。我并非治疗师，因此请勿将这些观点视为权威论断，但我可以提出三种 AI 诱发的精神困扰类型：
1. Chatbot psychosis 。指聊天机器人强化或放大用户妄想的情况；
2. AI 狂热 (AI mania) 。当使用编码代理时，许多任务看起来轻松且唾手可得，巨大的可能性范围令人应接不暇，开发速度令人上瘾，正向的反馈循环让你心情愉悦，促使你不断利用代理完成更多任务，甚至因此而牺牲其他重要事项。与此同时，你每天都精疲力尽，甚至因此失眠。在这种情况下，最好的办法是暂停使用代理几天，彻底从中抽离。如今，这已成为一种新的“瘾”，但随着时间的推移，它将回归常态，沦为一种平淡无奇的工具；
3. 全球 AI“精神错乱” (Worldwide AI psychosis) 。投资者对那些不具备根本性优势的 AI 公司进行过度投机押注；领导层在缺乏合理依据的情况下强制推行 AI 使用，并采用诸如令牌（token）使用量等虚假指标；产品经理正在强行集成 AI 功能，效果适得其反；员工则在毫无节制地消耗令牌（token）。不过，也无需过分担忧——当前各方反应普遍过度，但随着时间的推移，这种局面将逐渐趋于稳定。
AI 让编写复杂代码变得更容易，但代码的可读性可能会因此降低。
对于那些凭直觉快速开发的应用，复杂代码通常不是问题——最坏的情况无非是直接废弃重来。但长此以往，维护难度会逐渐增大，最终积累技术债务。
对于服务器端代码，工程师会进行代码审查，AI 生成的代码自然会受到更严格的审查。然而，代码复杂性在一定程度上增加是意料之中的，因此前述观点总体上是成立的。
将 AI 用于核心产品可能会掩盖或削弱我们的竞争优势。
目前，AI 代理仍很少能自主编写代码，也无法做出优秀的架构决策——它们更像是结对程序员，只擅长处理你提供的规模较小、范围明确的任务。产品战略、实施质量标准、对细节的关注以及以客户为中心——这些核心要素依然需要我们来把控和负责。
使用人工智能可能导致注意力分散，并对产品方向产生负面影响。
这种担忧是真实存在的，就像使用任何其他工具一样。AI 应用中存在一个陷阱，它表现为：当编码智能体被认为是构建内部应用的最佳选择时，内部应用的数量可能会增加十倍，而核心产品开发可能因此放缓。工程师开始引入智能体，却突然将精力投入到开发新的智能体编排工具中，结果是出现了十种不同的智能体编排方案。这与不使用 AI 的情况并无二致——每个人都会去解决那些有趣且有吸引力的任务。这凸显了专注和产品思维的重要性。
所谓的生产力提升可能并非真实存在，或仅停留在表面层面。
我预计，感知到的十倍生产力提升，最终在公司层面的指标上，可能只带来一个相对较小但仍然有意义的提升。
你是 AI 抵触者，不愿接触 AI 热潮。
不是每个人都必须使用 AI。如果团队中有一两名工程师不使用智能体继续工作，这其实是有道理的，因为他们能提供多元化的视角。
但我仍然建议抛开所有炒作，尝试使用编码智能体。即使你对 AI 持抵触态度，偶尔解决一些任务，也能从中获得效率提升。
此外，我不建议你长期与新技术脱节。你认识还在使用 dBase][ 维护后台系统的人吗？或者还在用 Borland C 编程的人？他们或许是真正的专业人士，但你肯定不想成为那样的人。
AI 可能会取代我们的工作。
在当前技术水平下，AI 无法取代所有工程师，甚至包括初级工程师。AI 加剧了工程师之间的差异，并降低了对技能水平较低工程师的需求。
哪些类型的工作可能会被取代？许多 IT 相关工作，例如编写 WordPress 插件、Salesforce 集成等，都可能面临被取代的风险。
在高度竞争的领域，AI 提升了对工程工作成果的预期，这种提升甚至抵消或超越了单个工程师生产力的增长。然而，如果我们假设每位工程师使用 AI 模型的 token 成本将与工程师的薪酬相近，那么结果将是，企业需要为模型支付更多费用，同时却能雇佣更少的工程师。
我们应该更多地使用它
我们仍处于 AI 应用的初期阶段。我们已在公司内部普及了相关工具和模型，掌握了在无人值守虚拟机上运行代理的技能，开发了编排工具，部署了自主 QA 和 CI 工程师，启用了 AI 评审，并集成了 BI 和 SRE 代理……然而，我们的目标不止于此：我们希望实现新功能的 agentic 测试、对 Bug 报告的初步调查、不良变更的自动回滚、自动协助贡献者解决停滞的拉取请求，以及对问题工作负载的持续分析。
ClickHouse 本身是 agentic analytics 和 AI 基础设施的核心组件。如果您是一位技术精湛的工程师，并且对 AI 充满热情，欢迎加入 ClickHouse！
/END/
征稿启示
面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出 &图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com。
