来自O'Reilly的观察：意外的编排者

_【编辑注】我们将在博客中开设一个每周五的专栏，定期分享来自开发者社区的声音，无论是在 Stack Overflow 内部还是外部。这是该系列的第一篇文章，是对 O’Reilly Media 博客 Radar 上一篇文章的重新发表。我们将每月重新发布他们的文章。_

本文最初发表于 _O’Reilly Radar_，并经作者授权在此转载。

—————————

这是关于代理工程（agentic engineering）和 AI 驱动开发系列文章的第一篇。请关注 3 月 19 日在 O’Reilly Radar 上发布的下一篇文章。

关于 AI 和软件开发的讨论已经铺天盖地，而这些讨论主要分为两种观点。一种观点认为：“我们都完了，像 Claude Code 这样的工具将在一年内让软件工程变得过时。”另一种观点则说：“别担心，一切都很正常，AI 只是工具箱里的另一个工具。”这两种说法都不诚实。

我花了超过 20 年的时间撰写面向实践者的软件开发相关文章，涵盖从编码、架构到项目管理和团队协作等各个方面。在过去两年里，我专注于 AI 领域，培训开发者如何有效使用这些工具，并通过书籍、文章和报告来探讨哪些方法有效、哪些无效。但我在不断遇到同一个问题：我尚未找到任何一位经验丰富的开发者能给出一个连贯的答案，即他们应该如何实际使用这些工具。虽然有很多技巧和炒作，但缺乏结构化的方法，也几乎没有可以练习、教授、批评或改进的内容。

我一直观察着开发者在工作中使用 AI 的各种成功与失败情况，逐渐意识到我们需要把这种现象当作一门独立的学科来思考。特斯拉前 AI 负责人、OpenAI 创始成员 Andrej Karpathy 最近提出了“代理工程”（agentic engineering）这一术语，用于描述有纪律地使用 AI 代理进行开发，而 Addy Osmani 等人也开始认同这个概念。Osmani 的观点是：AI 代理负责实现，而人类负责架构、审查每个变更、并持续测试。我认为这是正确的。

然而，在过去两年里，我一直在教导开发者如何使用 Claude Code、Copilot 中的代理模式、Cursor 等工具，而我听到最多的是：他们都知道自己应该审查 AI 的输出、维护架构、编写测试、保持文档更新，并掌控代码库。他们知道理论上的做法。但在实践中却卡住了：你如何真正审查数千行由 AI 生成的代码？当你在数周内跨多个 AI 工具工作时，如何保持架构的一致性？你如何判断 AI 在自信地犯错？不只是初级开发者在代理工程方面遇到困难。我也和一些高级工程师谈过，他们也在适应代理工具方面感到挣扎；还有一些中级开发者则能自然地掌握它。区别并不在于经验年限，而在于是否找到了一种有效且结构化的方式来与 AI 编程工具协作。_开发者应如何进行代理工程，以及如何将其融入日常工作的差距，正是目前许多工程师焦虑的真实来源。_ 这正是本系列试图填补的空白。

尽管代理工程的很多炒作都在告诉你相反的观点，但这种开发方式并不会消除对开发者专业知识的需求——恰恰相反。与 AI 代理高效协作实际上提高了开发者所需具备的知识门槛。我在之前一篇 O’Reilly Radar 的文章《认知捷径悖论》中写到了这一点。那些从 AI 编程工具中获益最多的开发者，往往是那些已经了解什么是优秀软件的人，他们通常能够判断出 AI 是否写出了这样的代码。

AI 工具在经验丰富的开发者主导下表现最佳，这与我所观察到的一切相符。这听起来很合理，我也想用一种其他开发者能理解的方式去验证它：通过构建软件。因此，我开始构建一套具体、实用的代理工程方法，专为开发者设计，并付诸实践。我用这套方法从零开始构建了一个生产系统，规则是：所有代码都由 AI 来写。我需要一个足够复杂的项目来考验这种方法，同时又足够有趣，能让我在艰难的部分也能坚持下去。我想应用我学到的所有知识，并发现我仍不知道的东西。于是，我回到了 蒙特卡洛模拟。

自从小时候起，我就对蒙特卡洛模拟非常着迷。我父亲是一名流行病学家——他整个职业生涯都是在从混乱的人口数据中寻找规律，这意味着统计学一直是我们生活的一部分（这也意味着我很早就学会了 SPSS）。当我大约 11 岁的时候，他给我讲了“醉酒水手问题”：一个水手离开酒吧，每次随机向水中或船的方向迈出一步。他会掉进水里还是回到家？单次运行无法预测结果。但如果运行一千次模拟，噪声中的模式就会显现出来。个体结果是随机的，但整体结果是可以预测的。

我记得在 TRS-80 Color Computer 2 上用 BASIC 编写那个模拟程序：一个方块状的小水手在屏幕上蹒跚前行，两步向前，一步向后。这个醉汉水手就是“蒙特卡洛模拟”的“Hello, world”。蒙特卡洛是一种用于解决无法通过解析方法求解的问题的技术：你可以模拟数百或数千次，并测量总体结果。每次单独运行都是随机的，但随着样本量的增长，统计数据会收敛到真实答案。这是我们建模从核物理到金融风险再到疾病在人群中的传播等各种问题的方式之一。

如果你今天可以通过用英语描述来运行这种类型的模拟呢？不是玩具演示，而是数千次迭代，带有种子随机性以确保可重现性，输出得到验证，结果被汇总成实际可用的统计数据。或者是一个流水线，其中一个 LLM 生成内容，第二个 LLM 对其评分，任何未通过的内容都会被送回重新尝试。

我实验的目标是构建这样一个系统，我称之为 Octobatch。目前，业界一直在寻找代理工程领域的新现实世界端到端案例研究，我希望 Octobatch 正好是这样的案例研究。

我把从教学和观察开发者使用 AI 中学到的所有知识，通过从零开始构建一个真正的系统来进行测试，并将这些经验转化为一种结构化的方法，我称之为AI 驱动开发（AIDD）。这是关于代理工程在实践中是什么样子的一系列文章的第一篇，它对开发者提出了什么要求，以及你如何将其应用到自己的工作中。

最终结果是一个功能完整、经过充分测试的应用程序，由几十个文件中的约 21,000 行 Python 代码组成，配有完整的规范、近一千个自动化测试，以及质量集成和回归测试套件。我使用 Claude Cowork 审查了整个项目的所有 AI 聊天记录，结果发现我在七周内总共投入了大约 75 小时的活跃开发时间构建了整个应用程序。相比之下，我去年玩 _Blue Prince_ 的时间只用了构建 Octobatch 的一半多一点。

但这系列文章不仅仅是关于 Octobatch。我在每个层级都整合了 AI 工具：Claude 和 Gemini 协作进行架构设计，Claude Code 编写实现代码，LLM 生成在它们帮助构建的系统上运行的流水线。这一系列文章讲述的是我在该过程中学到的东西：哪些模式有效，哪些失败教会了我最多，以及将这一切联系在一起的编排思维。每篇文章都从实验中提取不同的教训，从验证架构到多 LLM 协调，再到让项目保持正轨的价值观。

当大多数人谈论使用 AI 写代码时，他们通常指的是两种情况之一：像 GitHub Copilot、Cursor 或 Windsurf 这样的 AI 编码助手，它们已经远远超越了自动补全，发展成为可以执行多文件编辑会话并定义自定义代理的代理工具；或者是“氛围编码”，即你用自然语言描述想要的内容，并接受返回的结果。这些编码助手确实令人印象深刻，而氛围编码也可以非常高效。

然而，在一个真实的项目中有效使用这些工具，保持数千行 AI 生成代码的架构一致性，是完全不同的问题。AIDD 的目标是帮助解决这个问题。这是一种结构化的代理工程方法，其中 AI 工具驱动了实现、架构甚至项目管理的大量工作，而你作为人机交互中的“人”，决定构建什么以及它是否足够好。所谓“结构”，是指开发者可以学习和遵循的一套实践方法，一种判断 AI 输出是否真正良好的方式，以及一种在整个项目生命周期中保持方向感的方法。如果代理工程是一门学科，那么 AIDD 是实践它的其中一种方式。

在 AI 驱动开发中，开发者不只是接受建议或希望输出正确。他们会为特定工具分配特定角色：一个 LLM 负责架构规划，另一个负责代码执行，一个编码代理负责实现，而人类则负责愿景、验证和需要理解整个系统的决策。

而“驱动”这个词是字面意思。AI 几乎写了所有的代码。我对 Octobatch 实验的一个基本原则是，我让 AI 来写全部代码。我对代码质量有很高的标准，实验的一部分就是看看 AIDD 是否能产出符合这些标准的系统。人类决定构建什么，评估它是否正确，并维持约束条件以保持系统的连贯性。

并非所有人都认同开发者需要在多大程度上保持在环中，而完全自主的那一端已经产生了警示故事。Anthropic 的 Nicholas Carlini 最近指派了 16 个 Claude 实例并行构建一个 C 编译器，且全程无人参与。在 2,000 次会话和 20,000 美元的 API 费用之后，这些代理生成了一个包含 100,000 行代码的编译器，能够构建 Linux 内核，但它并不能替代任何现有编译器。当所有 16 个代理在同一错误上卡住时，Carlini 不得不介入并自行划分任务。即使是完全放手、以氛围驱动的代理工程坚定支持者也可能认为这已经走得太远了。问题是，你需要多少人类判断力才能使这段代码值得信赖，以及哪些具体做法能帮助你有效地运用这种判断力。

如果你想让开发者以正确的方式思考代理工程（agentic engineering），你必须从他们如何与 AI 合作开始，而不仅仅是他们使用什么工具。这是我开始构建结构化方法时的切入点，这也是为什么我从习惯入手的原因。我为此开发了一个框架，称为 Sens-AI 框架，并以两种形式发布：O’Reilly 报告（《与 AI 编码的关键思维习惯》）和 Radar 系列。该框架围绕五项实践展开：提供上下文、在提示前进行研究、精确地定义问题、对输出进行有意识的迭代，以及对 AI 所生成的一切应用批判性思维。我从这里开始，因为习惯是你锁定工作方式的思维方式。没有这些习惯，AI 驱动的开发会产生看起来合理但经不起推敲的代码；而有了这些习惯，它则能产出单个开发者在相同时间内无法独立完成的系统。

习惯是基础，但它们并不是全部。AIDD（AI-Driven Development，AI 驱动开发）还包括实践（具体的技术，如多 LLM 协调、上下文文件管理，以及用一个模型验证另一个模型的输出）和价值观（这些实践背后的原理）。如果你曾使用过 Scrum 或 XP 等敏捷方法论，这种结构应该会很熟悉：实践告诉你如何日常开展工作，而习惯则是你培养出的本能反应，使这些实践变得自动化。

价值观常常显得有些理论化，但它们是拼图中重要的一环，因为当实践无法给出明确答案时，它们引导你做出决策。目前围绕代理工程正在形成一种新兴文化，你在项目中所秉持的价值观要么与之契合，要么产生冲突。理解价值观的来源，才能让实践真正落地。这一切最终带来了一种全新的思维方式，我称之为编排思维模式（orchestration mindset）。本系列将构建这四个层面，并以 Octobatch 作为验证平台。

Octobatch 是一次有意为之的 AIDD 实验。我将该项目设计为整个方法的测试案例，以观察一个纪律严明的 AI 驱动工作流能够产出什么成果，以及它在何处会失效。我也借此来应用并改进这些实践和价值观，使其更有效且易于采纳。无论是出于直觉还是巧合，我选中了这个完美的项目来做这次实验。Octobatch 是一个批处理编排器（batch orchestrator），它协调异步作业，在失败时管理状态，追踪流水线步骤之间的依赖关系，并确保经过验证的结果能够顺利输出。这类系统在设计上很有趣，但实现细节——比如状态机、重试逻辑、崩溃恢复和成本核算——往往繁琐且容易出错。这正是 AIDD 应该大显身手的地方，因为模式已知，但实现过程重复且容易出错。

编排——即协调多个独立进程以达成统一结果的工作——演变成了 AIDD 的核心理念。我发现，自己在编排 LLM 时，与 Octobatch 编排批处理作业的方式如出一辙：分配角色、管理交接、验证输出、从失败中恢复。我正在构建的系统和我用来构建它的流程遵循着同样的模式。起初我并未预料到这一点，但构建一个用于编排 AI 的系统，恰恰是学习如何编排 AI 的一种极佳方式。这就是“意外编排者”中的“偶然”部分。这种平行关系贯穿于本系列的每一篇文章。

我并没有从完整的端到端蒙特卡洛模拟开始 Octobatch 项目。我像大多数人一样，从在聊天界面中输入提示开始。我在尝试不同的模拟和生成思路，为项目注入结构，其中一些想法最终被保留下来。一个黑杰克策略对比成为多步骤蒙特卡洛模拟的理想测试案例。一个角色扮演游戏中的 NPC 对话生成则给了我一个具有主观质量评估的创造性工作负载。两者都具有相同的结构：一组结构化的输入，每个都以相同方式处理。因此，我让 Claude 编写了一个简单的脚本来自动化我之前手动执行的操作，并使用 Gemini 来复核工作，确保 Claude 真正理解了我的需求，并修正幻觉问题。在小规模运行时效果良好，但一旦我开始运行超过一百个或更多单元，就不断遇到速率限制，也就是服务商对每分钟 API 请求次数的上限设定。

这促使我转向LLM 批量 API。与其逐一发送提示并等待每个响应，主流 LLM 提供商都提供了批量 API，允许你一次性提交包含所有请求的文件。服务商按自己的节奏处理这些请求；你只需等待结果，而不是立即获得响应，但也不必担心速率限制。我很高兴发现这些批量 API 的价格还便宜了 50%，于是开始认真跟踪令牌使用情况和成本。但真正的惊喜在于，批量 API 在大规模下比实时 API 表现更好。一旦流水线超过 100 或 200 个单元，批量处理的速度明显快于实时处理。服务商在其基础设施上并行处理整个批次，因此你不再受往返延迟或速率限制的制约。

切换到批量 API 改变了我对大规模协调 LLM API 调用问题的思考方式，并催生了可配置流水线的想法。我可以将各个阶段串联起来：一个步骤的输出可以成为下一个步骤的输入，我可以启动整个流水线并稍后获取完成的结果。事实证明，我并不是唯一一个转向批量 API 的人。在 2024 年 4 月至 2025 年 7 月期间，OpenAI、Anthropic 和 Google 都推出了批量 API，并采用了相同的定价模型：以异步处理换取实时费率的 50%。

你可能没有注意到三大 AI 提供商都发布了批量 API。行业讨论主要集中在智能体、工具使用、MCP 和实时推理上。批量 API 发布时几乎没有引起太多关注，但它们代表了我们使用 LLM 方式的一个真正转变。我们不再将它们视为对话伙伴或一次性 SaaS API，而是将其视为处理基础设施，更接近于 MapReduce 作业而非聊天机器人。你只需提供结构化数据和提示模板，它们就会处理所有内容并将结果返回。重要的是，你现在可以可靠地、大规模地运行数万次这样的转换操作，而无需管理速率限制或连接失败问题。

如果批量 API 如此有用，为什么不能简单地写一个 for 循环来提交请求并收集结果呢？你可以这样做，在简单情况下，一个带 for 循环的快速脚本完全可以胜任。但一旦你开始运行更大的工作负载，问题就开始堆积。解决这些问题成了我在构建代理工程结构化方法过程中最重要的教训之一。

首先，批量任务是异步的。你提交一个任务，几个小时后才会收到结果，因此你的脚本需要跟踪已提交的内容并轮询任务完成状态。如果你的脚本在中途崩溃，就会丢失这些状态。其次，批量任务可能会部分失败。也许 97% 的请求成功了，而 3% 失败了。你的代码需要找出哪 3% 失败了，提取出来并重新提交这些项目。第三，如果你正在构建一个多阶段的流水线，其中前一步骤的输出作为下一步的输入，你需要跟踪各阶段之间的依赖关系。第四，你需要进行成本核算。当你运行数万次请求时，你希望知道花费了多少，理想情况下，你希望在启动批量任务之初就知道预计花费多少。这些问题中的每一个都与你在代理工程中所做的事情有直接对应关系：跟踪多个 AI 智能体同时执行的工作，处理代码故障和错误，确保当 AI 编码工具只关注当前上下文中的某一部分时整个项目仍保持连贯性，以及从更宏观的角度审视项目管理。

所有这些问题都是可以解决的，但你不希望一遍又一遍地去解决这些问题（无论是在编排 LLM 批量任务还是编排 AI 编码工具时）。在代码中解决这些问题让我对代理工程的整体方法有了有趣的见解。批量处理将复杂性从连接管理转移到了状态管理。实时 API 的难点在于速率限制和重试机制。而批量 API 的难点在于你必须跟踪哪些任务正在进行中、哪些成功了、哪些失败了，以及接下来该做什么。

在我开始开发之前，我寻找了现有的工具来处理这种组合问题，因为我并不想浪费时间重复造轮子。我没有找到能够满足我需求的工具。像 Apache Airflow 和 Dagster 这样的工作流编排器管理有向无环图（DAG）和任务依赖关系，但它们假设任务是确定性的，并且不提供 LLM 特定功能，比如提示模板渲染、基于模式的输出验证，或者由语义质量检查触发的重试逻辑。LangChain 和 LlamaIndex 等 LLM 框架围绕实时推理链和智能体循环设计——它们不管理异步批量任务的生命周期，不会在进程崩溃后持久化状态，也不处理按块级别的部分失败恢复。而提供商提供的批量 API 客户端库只处理单个批次的提交和检索，但不支持多阶段流水线、跨步骤验证或跨提供商的统一执行。

我所找到的任何工具都无法覆盖多阶段 LLM 批量工作流的完整生命周期，从提交和轮询到验证、重试、成本追踪和崩溃恢复，涵盖所有三大 AI 提供商。这就是我所构建的内容。

本文的目标，作为我关于代理工程和 AI 驱动开发系列文章的第一篇，是提出 Octobatch 实验的假设和结构。该系列的其余部分将深入探讨我从中获得的教训：验证架构、多 LLM 协调、工作中涌现的实践和价值观，以及将这一切联系在一起的编排思维。一些早期的教训尤为突出，因为它们展示了 AIDD 在实际中的样子，也说明了为什么开发者体验比以往任何时候都更加重要。

• 你必须运行程序并检查数据。 记住那个醉酒水手，蒙特卡洛模拟的“你好，世界”吗？有一次我注意到，当我通过 Octobatch 运行模拟时，77.5% 的水手掉进了水中。随机游走的结果应该是 50/50，所以显然出了大问题。结果发现，随机数生成器在每次迭代时都使用连续的种子值重新播种，这在运行之间产生了相关性偏差。我没有立即发现问题；我使用 Claude Code 作为测试运行器来生成每个测试、运行它并记录结果；Gemini 查看了结果并找到了根本原因。Claude 在提出一个能正常工作的修复方案上遇到了困难，并建议在管道中使用一个包含大量预设随机数的列表作为变通方法。Gemini 则通过回顾我与 Claude 的对话提出了基于哈希的修复方案，但看起来过于复杂。在我理解了问题并拒绝了它们的建议后，我认为最好的修复方案比 AI 提出的任何一种都要简单：为每个模拟单元设置一个持久化的 RNG，让它自然地推进其序列。我需要同时理解统计学和代码才能评估这三个选项。看似合理的输出和正确的输出并不相同，你需要足够的专业知识来区分它们。（我们将在本系列的下一篇文章中进一步讨论这种情况。）
• 大型语言模型（LLM）常常高估复杂度。 有一段时间我想在分析管道中添加对自定义数学表达式的支持。Claude 和 Gemini 都反对，告诉我：“这是 v1.0 的范围蔓延”和“留到 v1.1 再做”。Claude 估计需要三小时来实现。由于我对代码库很熟悉，我知道我们已经在别处使用了 asteval——一个用于安全、极简的数学表达式和简单 Python 语句求值的 Python 库——因此这似乎是对现有库的直接应用。然而两个 LLM 都认为这个解决方案会比实际复杂得多且耗时更多；仅用了两次提示给 Claude Code（由 Claude 生成），加上大约五分钟就完成了实现。该功能上线后使工具变得强大得多。AI 的保守是因为它们没有了解系统架构的上下文。经验告诉我集成会非常简单。如果没有这种经验，我会听从它们的建议，推迟一个只需五分钟就能完成的功能。
• AI 往往倾向于增加代码而不是删除代码。 生成式 AI 不出所料地偏向于生成。因此当我要求 LLM 修复问题时，它们的第一反应通常是添加更多代码，增加另一层或另一个特殊情况。在整个项目中，我无法想到任何一个 AI 曾经退一步说：“把它删掉，重新思考方法。”最有效的会话是那些我压制直觉、坚持追求简洁的时候。这是有经验的开发者在职业生涯中学到的东西：最成功的变更往往删除的比添加的多——我们引以为傲的 PR 是那些删除数千行代码的。
• 架构是从失败中浮现出来的。 AI 工具和我并没有提前设计 Octobatch 的核心架构。我们的第一次尝试是一个带有内存状态和大量希望的 Python 脚本。它对小批次有效，但在扩展时崩溃了：网络抖动意味着从头开始重启，格式错误的响应则需要手动排查。在我加入“系统随时可能被杀死”的约束条件后，很多东西才逐渐清晰起来。这一单一要求催生了 tick 模型（唤醒、检查状态、执行工作、保存、退出）、以清单文件作为事实来源以及整个崩溃恢复架构。我们通过反复尝试做更简单的事情而发现了这个设计。
• 你的开发历史是一份数据集。 我刚刚讲了几段关于 Octobatch 项目的经历，本系列文章也会充满这样的故事。每一个故事都来自我回溯我和 Claude、Gemini 之间的聊天记录。借助 AIDD，你可以获得每一次架构决策、每一个错误方向、每一次你否决 AI 的时刻以及它纠正你时刻的完整记录。很少有开发团队拥有如此详尽的项目历史记录。挖掘这些日志中的经验教训是我发现最有价值的做法之一。
• 在项目接近尾声时，我切换到了 Cursor，以确保这一切并非特定于 Claude Code。我使用之前一直维护的相同上下文文件创建了新的对话，立刻就能启动高效的会话；上下文文件按设计工作得非常好。我养成的习惯、上下文管理方式和工程判断力可以无缝转移到不同的工具上。这种方法的价值来自于习惯、上下文管理和你在对话中带来的工程判断力，而不是依赖于某个特定厂商。

这些工具正在将世界推向一个更有利于开发者发展的方向，他们了解工程可能出现的问题，掌握扎实的设计和架构模式……并且愿意放手让 AI 控制每一行代码。

代理工程需要结构，而结构需要一个具体的例子来使其变得真实。本系列的下一篇文章将深入探讨 Octobatch 本身，因为它编排 AI 的方式与 AIDD 要求开发者做的事情惊人地相似。Octobatch 为不同的处理步骤分配角色，管理它们之间的交接，验证其输出，并在它们失败时进行恢复。这正是我在构建它时所遵循的模式：为 Claude 和 Gemini 分配角色，管理它们之间的交接，验证其输出，并在它们走错路径时进行恢复。理解系统的工作原理，实际上是对如何编排 AI 驱动开发的一个很好的理解方式。我将介绍其架构，展示从提示到结果的真实流水线是什么样子的，呈现一个包含 300 手二十一点蒙特卡洛模拟的数据，该数据对所有这些想法进行了测试，并利用这些数据来演示我们可以直接应用于代理工程和 AI 驱动开发的想法。

后续文章将进一步深入探讨我从这个实验中学习到的实践和理念，这些实践和理念使 AI 驱动开发成为可能：我是如何在不失去对架构控制的情况下协调多个 AI 模型的，当我用实际意图构建的内容来测试代码时发生了什么，以及我对运行代码与实现预期功能的代码之间差距的了解。在此过程中，实验产生了一些关于不同 AI 模型如何看待代码的发现，这些发现是我未曾预料到的——而这些发现最终比我想的更重要。