从指挥者到统筹者：AI 智能体编程的未来

原文：Conductors to Orchestrators: The Future of Agentic Coding

作者：Addy Osmani

从“微观管理者”到“宏观管理者”：编程的异步未来

AI 编码助手 (AI coding assistants) 已经迅速从新奇事物转变为必需品，高达 90% 的软件工程师在某种程度上使用 AI 进行编码。但是，一种新的软件开发范式正在出现——工程师将驾驭自主 AI 智能体 (autonomous coding agents) 集群。在这个 AI 智能体盛行的未来，软件工程师的角色正在从执行者 (implementer) 演变为管理者 (manager)，换句话说，是从编码者 (coder) 演变为指挥者 (Conductor)，并最终成为统筹者 (Orchestrator)。

随着时间的推移，开发者将越来越多地指导 AI 智能体构建正确的代码，并协调多个 AI 智能体协同工作。本文将探讨在 AI 辅助编码中，指挥者和统筹者之间的区别，定义这些角色，并审视当今的前沿工具如何体现这两种方法。资深工程师可能已经开始意识到：我们的工作正从*“我该如何编码？”转变为“我该如何让正确的代码被构建出来？”*——这是一个微妙但深刻的变化。

“统筹者”工具一句话总结是什么？它支持多 AI 智能体工作流，你可以并行运行许多 AI 智能体，而它们之间不会互相干扰。不过，让我们先多谈谈术语。

指挥者：引导单个 AI 智能体

在 AI 编码的背景下，扮演指挥者 (Conductor) 意味着与单个 AI 智能体就特定任务紧密合作，就像指挥家引导独奏者完成一场表演。

工程师在每一步都保持在循环中 (in the loop)，动态地引导 AI 智能体的行为、调整提示、在需要时进行干预，并实时迭代。这是许多开发者已经熟悉的“AI 结对程序员” (AI pair programmer) 模式的合乎逻辑的延伸。在指挥者式的工作流中，编码是在人与 AI 之间的同步 (synchronous)、交互式会话中发生的，通常在你的 IDE (即集成开发环境) 或 CLI (即命令行界面) 中进行。

关键特征： 指挥者与一个 AI 智能体保持紧密的反馈循环，验证或修改每一个建议，就像司机使用 GPS 导航一样。AI 帮助编写代码，但开发者仍需执行许多手动步骤——创建分支、运行测试、编写提交信息等，并最终决定接受哪些建议。

至关重要的是，这种互动在很大程度上是临时的 (ephemeral，即会话是短暂的，一旦结束，AI 的角色就完成了)：一旦代码编写完毕，会话结束，AI 的角色就完成了，任何未被代码捕获的上下文或决策都可能丢失。这种模式对于集中式任务非常强大，并允许精细控制，但它没有充分利用多个 AI 并行工作的潜力。

作为指挥者的现代工具： 当前有几款 AI 编码工具是指挥者模式的典范：

  • Claude Code (Anthropic)： Anthropic 公司的 Claude 模型提供了一种编码助手模式（可通过 CLI 工具或编辑器集成访问），开发者与 Claude 对话以生成或修改代码。例如，使用 Claude Code CLI，你在终端中浏览你的项目，要求 Claude 实现一个函数或重构代码，它会打印出差异 (diffs) 或文件更新供你批准。你仍然是指挥者：你触发每个动作并立即审查输出。虽然 Claude Code 具有处理长时间运行任务和工具的功能，但在基本用法中，它本质上是一个在人类指导下逐步工作的智能联合开发者。

  • Gemini CLI (Google)： 一款由谷歌 Gemini 模型驱动的命令行助手，用于在超大上下文窗口中进行规划和编码。工程师可以提示 Gemini CLI 分析代码库或起草解决方案计划，然后在结果上进行交互式迭代。人类指导每一步，Gemini 在 CLI 会话中响应。它是一个一次性的协作者，而不是自己跑去修改代码（至少在这种指挥者模式下是这样）。

  • Cursor (编辑器 AI 助手)： Cursor 编辑器（一种专门的 AI 增强型 IDE）可以在内联或聊天模式下运行，你向它提问或要求编写代码片段，它会立即在你的编码会话中执行这些编辑或给出答案。同样，你一次一个请求地引导它。Cursor 作为指挥者的优势在于其深度上下文集成——它会索引你的整个代码库，因此 AI 可以回答关于其中任何部分的问题。但其标志是你，作为开发者，实时发起并监督每一个变化。

  • VSCode, Cline, Roo Code (IDE 内聊天)： 与上述类似，其他编码 AI 智能体也属于这一类。它们会建议代码甚至多步骤修复，但始终处于持续的人工指导之下。

这种指挥者式的 AI 辅助已经显著提高了生产力。感觉就像身边总有一个初级工程师或结对程序员。然而，它本质上是一次一个 AI 智能体且同步的。为了真正规模化地利用 AI，我们需要超越指挥者。这就是统筹者 (Orchestrator) 角色发挥作用的地方。

统筹者：管理 AI 智能体“舰队”

如果说指挥者是与一个 AI“音乐家”合作，那么统筹者 (Orchestrator) 则是监督由多个 AI 智能体组成的“交响乐团”，它们并行地处理一个项目的不同部分。统筹者设定高层目标、定义任务，并让一个自主编码 AI 智能体团队独立执行实施细节。

人类不再是微观管理每一个函数或错误修复，而是专注于协调、质量控制和集成 AI 智能体的输出。实际上，这通常意味着工程师可以将任务分配给 AI 智能体（例如通过 issue 或提示），然后让那些 AI 智能体异步 (asynchronously) 地生成代码更改——通常是以准备好审查的拉取请求 (pull requests) 的形式。工程师的工作变成了审查、提供反馈和合并结果，而不是亲自编写所有代码。

这种异步、并行的工作流是一个根本性的转变。它将 AI 辅助从前台转移到了后台。当你处理更高级别的设计或其他工作时，你的“AI 团队”正在后台编码。 当它们完成后，它们会把完成的工作（包括测试、文档等）交给你审查。这类似于一个项目技术负责人将任务委派给多个开发者，并在稍后审查他们的拉取请求，只不过这些“开发者”是 AI 智能体。

关键特征： 统筹者打交道的是自主 AI 智能体 (autonomous agents)，它们能够以最少的人工干预来规划和执行多步骤编码任务。这些 AI 智能体拥有更大的自主权：它们可以克隆你的仓库、创建新的 git 分支、编辑多个文件、编译/运行测试，并在提交解决方案之前迭代优化。

统筹者不会看到每一个中间步骤（除非他们选择查看）；他们主要确保最终结果符合要求。重要的是，这一切都发生在可跟踪、持久化的工作流中（通常利用版本控制和 CI 管道，即持续集成流程），而不是临时的建议。例如，GitHub 的编码 AI 智能体完全通过 GitHub 上的拉取请求来操作，因此每个更改都会被记录和审查。另一个标志是并发性：统筹者可以启动多个 AI 智能体同时处理不同任务，从而极大地并行化开发。

作为统筹者的现代工具： 仅在过去一年里，就出现了几种体现这种统筹者范式的工具：

  • GitHub Copilot 编码智能体 (Microsoft)：Copilot 的这次升级将其从编辑器内助手转变为自主的后台开发者（我在这个视频中介绍过它）。你可以将一个 GitHub issue 分配给 Copilot 的 AI 智能体，或者通过 VS Code 的 AI 智能体面板调用它，告诉它（例如）“实现功能 X”或“修复错误 Y”。然后，Copilot 会通过 GitHub Actions 启动一个临时开发环境，检出你的仓库，创建一个新分支，然后开始编码。它可以运行测试、linter (即代码风格检查工具)，甚至在需要时启动应用程序，所有这些都无需人工“ babysitting”(即保姆式的看管)。完成后，它会打开一个包含更改的拉取请求 (pull request)，并附有描述和有意义的提交信息。然后它会请求你的审查。你，作为人类统筹者，审查这个 PR（也许可以使用 Copilot 的 AI 辅助代码审查来进行初步分析）。如果需要更改，你可以留下评论，比如 @copilot 请更新针对 Z 边界情况的单元测试，AI 智能体就会迭代这个 PR。这就是异步、自主的代码生成在行动。 值得注意的是，Copilot 自动化了繁琐的事务性工作：创建分支、提交、打开 PR 等，这些过去常常花费开发者的时间。所有围绕编写代码的“苦力活”（除了设计本身）都被处理了，让开发者能专注于高层次的审查和指导。GitHub 的 AI 智能体有效地让一个工程师能够监督许多“AI 初级工程师”在不同 issue 上并行工作（你甚至可以为不同任务类型创建多个专门的 AI 智能体）。

  • Jules, 谷歌的编码智能体： Jules 是一款自主编码 AI 智能体。Jules “不是副驾驶，不是代码补全的搭档，而是一个能阅读你的代码、理解你的意图并开始工作的自主 AI 智能体。” Jules 与 Google Cloud 和 GitHub 集成，让你连接一个仓库，然后要求它执行任务，就像你对团队中的开发者一样。在底层，Jules 将你的整个代码库克隆到一个安全的云虚拟机 (VM) 中，并用强大的模型进行分析。你可能会告诉 Jules：“为我们的应用添加用户身份验证”或“将此项目升级到最新的 Node.js 并修复任何兼容性问题。” 它会制定一个计划，呈现给你批准，一旦你批准，它就会异步执行更改。它在新分支上进行提交，甚至可以为你打开一个拉取请求以便合并。Jules 处理编写新代码、更新测试、升级依赖项等所有工作，而你可能正在做别的事情。至关重要的是，Jules 提供了透明度和控制权：它在进行更改前会向你展示其提议的计划和推理，并允许你在任何时候进行干预或修改指令（谷歌称之为“用户可操控性” (user steerability) 的功能）。这类似于给一个 AI 实习生规格说明书，然后不那么频繁地“监工”——你相信他们能基本搞定，但你仍会核实最终的差异 (diff)。Jules 还拥有一些独特的点缀，如音频变更日志（它会生成代码变更的语音摘要）以及在云中并发运行多个任务的能力。简而言之，谷歌的 Jules 演示了统筹者模型：你定义任务，Jules 异步完成繁重工作，你监督结果。

    🐙 Google Jules: The AI Coding Agent That Actually Works Autonomously | by Elio Verhoef | Medium

  • OpenAI Codex (云智能体)： OpenAI 推出了一个新的基于云的 Codex 智能体 来补充 ChatGPT。这个进化版的 Codex（不同于 2021 年的 Codex 模型）被描述为“一个可以并行处理多项任务的、基于云的软件工程 AI 智能体”。它作为 ChatGPT Plus/Pro 的一部分以 OpenAI Codex 的名称提供，并通过 npm CLI (npm i -g @openai/codex) 提供。通过 Codex CLI 或其 VS Code/Cursor 扩展，你可以像使用 Copilot 或 Jules 一样将任务委托给 OpenAI 的 AI 智能体。例如，你可以在终端中说：“嘿 Codex，为设置页面实现暗黑模式”。Codex 随后会进入你的仓库，编辑必要的文件，也许会运行你的测试套件，完成后，它会呈现差异 (diff) 供你合并。它在隔离的沙盒 (sandbox) 中运行以确保安全，将每个任务放在一个包含你的仓库和环境的容器中运行。与其他工具一样，OpenAI 的 Codex 智能体与开发者工作流集成：你甚至可以从手机上的 ChatGPT 移动应用 启动任务，并在 AI 智能体完成时收到通知。OpenAI 强调 Codex 可以“在实时协作和异步委托之间无缝切换”。实际上，这意味着你可以灵活地在指挥者模式（在 IDE 中结对编程）或统筹者模式（将后台任务交给云智能体）下使用它。Codex 还可以被邀请进入你的 Slack 频道——团队成员可以在 Slack 中将任务分配给 @Codex，它会从对话和你的仓库中提取上下文来执行它们。这是一个无处不在的 AI 辅助愿景，编码任务可以从任何地方被委托。早期用户报告称，给定一个范围明确的提示，Codex 可以自主识别和修复错误，或生成重要功能。所有这些再次与统筹者工作流保持一致：人类定义目标，AI 智能体自主交付解决方案。

    OpenAI Codex: The Autonomous AI Coding Agent | by Komal Raut | AI Simplified in Plain English | Medium

  • Anthropic Claude Code (网页版)： Anthropic 提供 Claude 作为 AI 聊天机器人已有一段时间，他们的 Claude Code CLI 一直是交互式编码的最爱。Anthropic 迈出了下一步，推出了 Claude Code for Web，这实际上是他们编码 AI 智能体的托管版本。使用 Claude Code for Web，你将其指向你的 GitHub 仓库（具有可配置的沙盒权限）并给它一个任务。然后，该 AI 智能体在 Anthropic 的托管容器中运行，就像 CLI 版本一样，但现在你可以从 Web 界面甚至移动应用触发它。它会将多个提示和步骤排队、执行它们，完成后，将一个分支推送到你的仓库（并可以打开一个 PR）。本质上，Anthropic 将他们的单 AI 智能体 Claude Code 变成了云中可统筹的服务。他们甚至提供了一个“传送” (teleport) 功能，如果你想手动接管，可以将“会话”转移到你的本地环境。这个 Web 版本的理由与统筹者的好处一致：方便和规模。你不需要在你的机器上运行长时间的工作；Anthropic 的云处理繁重的工作，并具有文件系统和网络隔离以确保安全。Claude Code for Web 承认具有安全性的自主性是关键——通过沙盒化 AI 智能体，他们减少了对持续权限提示的需求，让 AI 智能体更自由地运作（用户更少地“操心”)。实际上，Anthropic 使得将 Claude 用作你按需启动的自主编码“工人”变得更加容易。

  • Cursor 后台智能体 (Background Agents)： 简而言之 - Cursor 2.0 有一个更专注的多智能体界面，更侧重于 AI 智能体而不是文件。Cursor 2 将其后台智能体功能扩展为为开发者提供的成熟的统筹层。除了作为交互式助手外，Cursor 2 还允许你生成在托管云工作区中异步运行的自主后台 AI 智能体。当你委托一个任务时，Cursor 2 的 AI 智能体现在会克隆你的 GitHub 仓库，启动一个临时环境，并检出一个隔离的分支，在其中端到端地执行工作。这些 AI 智能体可以处理整个开发循环——从编辑和运行代码，到安装依赖、执行测试、运行构建，甚至搜索网页或参考文档来解决问题。完成后，它们会推送提交并打开一个详细的拉取请求，总结它们的工作。Cursor 2 引入了多 AI 智能体统筹，允许几个后台 AI 智能体在不同任务上并发运行——例如，一个在优化 UI 组件，而另一个在优化后端性能或修复测试。每个 AI 智能体的活动都通过一个实时仪表板可见，可以从桌面或移动设备访问，使你能够监控进度、发出跟进指令或在需要时手动干预。这个新系统有效地将每个 AI 智能体视为按需 AI 劳动力的一部分，通过开发者的高层意图进行协调。Cursor 2 对并行、异步执行的关注极大地放大单个工程师的吞吐量——完全实现了统筹者模型，即人类监督一个协作的 AI 开发者“舰队”，而不是单个助手。

  • AI 智能体统筹平台： 除了个别产品，还有一些新兴的平台和开源项目旨在统筹多个 AI 智能体。例如，Melty Labs 的 Conductor（尽管它的名字叫“指挥者”！）实际上是一个统筹工具，它允许你在你自己的机器上并行部署和管理多个 Claude Code AI 智能体。使用 Conductor，每个 AI 智能体都有自己隔离的 Git 工作区 (worktree) 以避免冲突，你可以看到所有 AI 智能体的仪表板（“谁在做什么”）并在它们进展时审查它们的代码。其理念是让运行一小群编码 AI 智能体像运行一个一样容易。同样，Claude Squad 是一个流行的开源终端应用，它本质上是复用了 Anthropic 的 Claude——它可以在单独的 tmux 窗格中衍生出几个并发工作的 Claude Code 实例，允许你给每个实例分配不同的任务，从而通过并行化“10 倍速”编码。这些统筹工具凸显了这一趋势：开发者希望协调多个 AI 编码智能体，并让它们协作或分工。甚至微软的 Azure AI 服务也在促成这一点——在 Build 2025 (这是一个虚构的年份，原文如此，意指未来的开发者大会) 上，他们宣布了供开发者“统筹多个专门的 AI 智能体来处理复杂任务”的工具，其 SDK 支持 AI 智能体间的通信 (Agent-to-Agent communication)，以便你的 AI 智能体“舰队”可以相互交谈和共享上下文。所有这些基础设施都是为了支持“统筹者工程师”而构建的，他们最终可能会监督数十个 AI 流程来处理软件开发生命周期的不同部分。

“我发现 Conductor 对我来说最有意义。它在与 AI 智能体交谈和在旁边窗格中查看我的更改之间取得了完美平衡。它的 Github 集成感觉无缝；例如，合并 PR 后，它立即将任务显示为“已合并”并提供了一个“存档”按钮。” - Juriy Zaytsev, 领英 (LinkedIn) 资深软件工程师

他还尝试了 Magnet：“将任务与看板 (Kanban board) 联系起来的想法很有趣，也很有意义。因此，Magnet 感觉非常以产品为中心。”

指挥者 vs 统筹者 - 差异

即使统筹者模式成熟，许多工程师仍将继续参与指挥者式的工作流（单 AI 智能体、交互式）。这两种模式将共存。

很明显，“指挥者”和“统筹者”不仅仅是花哨的术语，它们描述了我们与 AI 工作方式的真正转变：

  • 控制范围： 指挥者在微观层面操作，引导一个 AI 智能体完成单个任务或一个狭窄的问题。统筹者在宏观层面操作，为多个 AI 智能体或一个能处理多步骤项目的强大单 AI 智能体定义更广泛的任务和目标。指挥者问：“我如何在 AI 的帮助下解决这个函数或错误？” 统筹者问：“我今天可以委托哪些任务给 AI 智能体来推进这个项目？”

  • 自主程度： 在指挥者模式下，AI 的自主性很低——它每一步都在等待用户的提示。在统筹者模式下，我们给予 AI 高度的自主性——它可能会在需要人类反馈之前，在内部规划和执行数十个步骤（编写代码、运行测试、调整其方法）。一个 GitHub Copilot AI 智能体或 Jules 一旦被分配任务，就会尝试从头到尾完成一个功能，而 Copilot 在 IDE 中的建议只是在你输入时逐行给出。

  • 同步 vs 异步： 指挥者的交互通常是同步的 (synchronous)——你提示，AI 在几秒钟内响应，你立即集成或迭代。这是一个实时循环。统筹者的交互是异步的 (asynchronous)——你可能派发一个 AI 智能体，然后在几分钟或几小时后当它完成时再回来检查（有点像启动一个长时间的 CI 任务）。这意味着统筹者必须处理等待、上下文切换，并可能同时管理多件事情，这对开发者来说是一种不同的工作流节奏。

  • 产物和可追溯性： 一个微妙但重要的区别：统筹者工作流会产生持久的产物 (artifacts)，如分支、提交和拉取请求，这些都保存在版本控制中。AI 智能体的工作被完整记录（并经常链接到 issue/ticket），这提高了可追溯性和协作性。而对于指挥者式（IDE 聊天等），除非开发者手动提交中间更改，否则 AI 的许多参与并没有被明确记录。本质上，统筹者留下了团队中其他人可以看到甚至自己触发的“书面记录”（或者更确切地说是“git 记录”）。这有助于将 AI 更自然地带入团队流程。

  • 人类的精力投入： 对于指挥者来说，在 AI 工作的近 100% 时间里，人类都在积极参与——审查每个输出、优化提示等。这是交互式的工作。对于统筹者来说，人类的精力投入是前置的（为 AI 智能体编写一个好的任务描述或规范，设置正确的上下文）和后置的（审查最终代码并测试它），但在中间过程不需要太多。这意味着一个统筹者可以并行管理比一次只与一个 AI 合作所能完成的更多的工作。本质上，统筹者利用规模化的自动化，用精细的控制换取吞吐量的广度。

为了说明这一点，考虑一个常见的场景：添加一个新功能，它涉及前端、后端，并需要新的测试。作为一名指挥者，你可能会打开你的 AI 聊天，在 AI 的帮助下实现后端逻辑，然后分别实现前端，然后让它生成一些测试——在你的全程参与下，按顺序完成每个步骤。作为一名统筹者，你可以将后端实现分配给一个 AI 智能体（智能体 A），将前端 UI 更改分配给另一个（智能体 B），将测试创建分配给第三个（智能体 C）。你给每一个 AI 智能体一个提示或一个 issue 描述，然后退后一步，让它们并发工作。

很短时间后，你可能会收到三个 PR：一个用于后端，一个用于前端，一个用于测试。你的工作就是审查和集成它们（如果智能体 A/B 的代码在集成过程中发生了变化，也许还要让智能体 C 调整测试）。实际上，你管理了一个小型的“AI 团队”来交付这个功能。这个例子突出了统筹者是如何从任务分配和集成的角度思考，而指挥者则专注于逐步实现。

值得注意的是，这些角色是流动的，而不是僵化的类别。同一个开发者可能在某一刻扮演指挥者，在下一刻扮演统筹者。例如，你可能启动一个异步 AI 智能体来处理一个任务（统筹者模式），而你同时在另一个棘手的算法上与另一个 AI 合作（指挥者模式）。工具也正在模糊界限：正如 OpenAI 的 Codex 营销所暗示的，你可以无缝地在实时协作和委托异步任务之间切换。因此，可以把“指挥者”和“统筹者”看作是 AI 辅助开发谱系的两端，中间有许多混合的工作流。

为什么统筹者很重要

专家们表示，向统筹者的转变可能是我们所见过的编程生产力最大的飞跃之一。考虑一下历史趋势：我们从编写汇编到使用高级语言，然后到使用框架和库，最近到利用 AI 进行自动补全。每一步都抽象掉了更多底层的工作。自主编码 AI 智能体是下一个抽象层——你不再是手动编码每一个部分，而是在更高的层次上描述你所需要的，并让多个 AI 智能体来构建它。

随着统筹者式 AI 智能体的增加，我们可以想象更大比例的代码将由 AI 起草。当 AI 智能体生成了 80% 或 90% 的代码，而人类提供 10% 的关键指导和监督时，一个软件团队会是什么样子？许多人认为这并不意味着取代开发者——而是意味着增强开发者以构建更好的软件。我们可能会见证生产力的爆炸式增长，一个小型的工程师团队，通过有效管理数十个 AI 智能体流程，可以完成过去需要一支庞大程序员队伍耗时数月才能完成的工作。（注意：我仍然认为，如果所有这些代码不至于变成“垃圾”，我们将需要继续在我们的人类技能上投入精力的代码审查循环，这方面还有待改进）。

一个有趣的可能性是，每个工程师在某种程度上都将成为 AI 开发者的管理者。这有点像每个人都有一个由实习生或初级工程师组成的个人团队。你的效率将取决于你分解任务、向 AI 传达需求以及验证结果的能力。人类的判断力仍将至关重要：决定构建什么、确保正确性、处理模糊性，以及在 AI 可能不足的地方注入创造力或领域知识。换句话说，统筹者的技能组合——良好的规划、提示工程 (prompt engineering)、验证和监督——将会有很高的需求。这些 AI 智能体远非让工程师过时，它们可以将工程师提升到项目上更具战略性、监督性的角色。

迈向专业的“AI 团队”

今天的编码 AI 智能体主要处理实现：编写代码、修复代码、编写测试等。但愿景不止于此。想象一个完整的软件开发流水线，其中多个专门的 AI 智能体处理生命周期的不同阶段，由一个人类统筹者协调。这已经近在眼前。研究人员和公司已经提出了这样的架构，例如，你拥有：

  • 一个规划 AI 智能体 (Planning Agent)，分析功能请求或错误报告，并将其分解为具体任务

  • 一个（或几个）编码 AI 智能体 (Coding Agent)，在代码中实现这些任务

  • 一个测试 AI 智能体 (Testing Agent)，生成并运行测试以验证更改

  • 一个代码审查 AI 智能体 (Code Review Agent)，检查拉取请求的质量和标准合规性

  • 一个文档 AI 智能体 (Documentation Agent)，更新 README 或文档以反映更改

  • 可能还有一个部署/监控 AI 智能体 (Deployment/Monitoring Agent)，可以推出更改并观察生产中的问题。

在这种情况下，人类工程师的角色变成了对整个流程的监督和统筹：你可能以一个高层目标（例如，“在我们的应用中添加对加密货币支付的支持”）来启动这个过程，规划 AI 智能体将其转化为子任务，编码 AI 智能体异步实现每个子任务，测试 AI 智能体和审查 AI 智能体发现问题或润色代码，最后，在监控 AI 智能体的注视下，所有内容被合并和部署。

人类会介入以批准计划，解决 AI 智能体提出的任何冲突或问题，并给出部署的最终批准。这本质上是一个“AI 蜂群” (AI swarm) 在端到端地处理软件开发，而工程师则是管弦乐队的指挥（此处原文用词为 conductor of the orchestra，即指挥家，与上文的 Conductor 角色呼应）。

虽然这可能听起来很未来主义，但我们看到了早期的迹象。微软的 Azure AI Foundry (即 AI 铸造厂) 现在为企业环境中的多 AI 智能体工作流和 AI 智能体统筹提供构建模块，含蓄地支持了多个 AI 智能体将在复杂、多步骤任务上协作的想法。科技公司的内部实验已经让 AI 智能体创建的拉取请求由其他 AI 智能体审查者自动批评，形成一种 AI/AI 交互，最后由人类介入。在开源社区中，人们已经将像 Claude Squad（并行编码器）这样的工具与其他集成其输出的脚本链接起来。关于 模型-上下文协议 (MCP) 这样用于 AI 智能体共享状态和相互通信结果的标准，相关的讨论已经开始。

我之前注意到，“专门负责设计、实施、测试和监控的 AI 智能体可以协同工作，在复杂环境中开发、启动和落地功能”——开发者将这些 AI 智能体“招募”到他们的团队中，并指导/监督它们的执行。在这样的设置中，AI 智能体将*“自主地与其他 AI 智能体协调，在关键点请求人类的反馈、审查和批准”*，并在其他时候在它们之间处理繁杂的事务。目标是建立一个中央平台，我们可以在整个工作流中部署专门的 AI 智能体，而无需人类微观管理每一步——相反，人类在拥有完整上下文的情况下监督整个操作。

这可能会改变软件项目的管理方式：更像是在运行一条自动化的装配线，工程师确保质量和方向，而不是在装配线上手工制作每个组件。

统筹的挑战与人的角色

这是否意味着编程变成了一项“按按钮”的活动，你只需坐享其成，让 AI 工厂运转？不完全是——而且可能永远不会完全是。统筹者模型面临着重大的挑战和悬而未决的问题：

  • 质量控制与信任： 统筹多个 AI 智能体意味着你不会在每一项更改发生时都盯着它。如果完全依赖 AI，错误或设计缺陷可能会溜走。人类的监督作为最后的故障保险仍然至关重要。事实上，当前的工具明确要求人类在合并之前审查 AI 的拉取请求。这种关系经常被比作管理一个初级开发者团队：他们可以完成很多工作，但你不会在没有审查的情况下发布他们的代码。统筹者工程师必须对检查 AI 的工作保持警惕，编写好的测试用例，并部署好监控。AI 智能体可能会犯错或产生逻辑上正确但不理想的解决方案（例如，以一种晦涩的方式实现一个功能）。统筹者技能的一部分是知道何时干预，何时信任 AI 智能体的计划。正如 Stack Overflow 的首席技术官所写，“开发者保持专业知识来评估 AI 的输出”，并且将需要新的“信任模型”来进行这种协作。

  • 协调与冲突： 当多个 AI 智能体在共享的代码库上工作时，协调问题就会出现——就像多个开发者如果接触相同的文件可能会发生冲突一样。我们需要策略来防止合并冲突或重复工作。当前的解决方案是使用工作区隔离（每个 AI 智能体在自己的 git 分支或独立环境中工作）和明确的任务分离。例如，每个任务一个 AI 智能体，并且任务设计要最小化重叠。一些统筹者工具甚至可以自动合并更改或变基 (rebase) AI 智能体的分支，但通常这需要人类来集成。确保 AI 智能体不会“踩到彼此的脚”是一个活跃的开发领域。可以想象，未来 AI 智能体可能会（通过类似 AI 智能体间通信协议的方式）相互协商以避免冲突，但今天是由统筹者来设定界限。

  • 上下文、共享状态和交接： 编码工作流富含状态 (state)：仓库结构、依赖关系、构建系统、测试套件、风格指南、团队实践、遗留代码、分支策略等。多 AI 智能体统筹需要共享的上下文、内存和顺畅的转换。但在企业环境中：跨 AI 智能体共享上下文并非易事。没有统一的“工作流统筹层”，每个 AI 智能体都可能成为一个孤岛，在自己的领域工作良好，但无法融合。在编码工程团队中，这可能转化为：一个 AI 智能体创建一个功能分支，另一个运行单元测试，再一个合并到主干——如果第一个 AI 智能体没有标记第二个 AI 智能体期望的元数据，你就会遇到故障。

  • 提示和规范： 具有讽刺意味的是，随着 AI 处理更多的编码工作，人类的“编码”上升到了编写规范和提示的层面。AI 智能体输出的质量高度依赖于你对任务的规范程度。“模糊的指令会导致不佳的结果或 AI 智能体误入歧途”。已经出现的最佳实践包括为 AI 智能体编写迷你设计文档或验收标准 (acceptance criteria)——本质上是把它们当作需要明确“完成定义”的承包商。这就是为什么我们看到像 AI 规范驱动开发 (spec-driven development) 这样的理念：你给 AI 智能体一个详细的规范说明要构建什么，这样它就可以可预测地执行。工程师需要磨练他们清晰明确地描述问题和期望解决方案的能力。矛盾的是，这是一项非常老派的技能（编写好的规范和测试），在 AI 时代重新变得重要。随着 AI 智能体的改进，提示可能会变得更简单（“给我写一个用于 X 和 Y 的移动应用，具有这些功能”），但仍能产生更复杂的结果，但我们还没有到 AI 能直觉地理解所有未说出口的事情的程度。目前，统筹者必须是他们“数字劳动力”的优秀沟通者。

  • 工具和调试： 对于人类开发者，如果出了问题，他们可以实时调试。对于自主 AI 智能体，如果出了问题（比如 AI 智能体卡在一个问题上或产生了一个失败的 PR），统筹者必须调试这种情况：是一个糟糕的提示吗？AI 智能体是否误解了规范？我们是回滚再试一次，还是介入并手动修复它？新的工具正在被添加进来以提供帮助：例如，检查点 (checkpointing) 和回滚 (rollback) 命令让你可以在 AI 智能体走错路时撤销它的更改。监控仪表板可以显示 AI 智能体是否花费了太长时间或有错误。但实际上，统筹者有时可能不得不降级到指挥者模式来修复一个问题，然后再回到统筹模式。随着 AI 智能体变得更加健壮，这种相互作用将得到改善，但它凸显了统筹并不仅仅是“发射后不管”——它需要主动监控。AI 可观测性 (AI observability) 工具（跟踪 AI 智能体的成本、性能、准确性）很可能成为开发者工具包的一部分。

  • 伦理和责任： 另一个角度——如果一个 AI 智能体编写了大部分代码，谁对该代码中的许可证合规性、安全漏洞或偏见负责？最终，人类统筹者（或他们的组织）承担责任。这意味着统筹者应该纳入一些实践，比如对 AI 生成的代码进行安全扫描和验证依赖项。有趣的是，像 Copilot 和 Jules 这样的一些 AI 智能体包含了内置的安全措施（例如，它们不会引入已知易受攻击的库版本，并且可以被指示运行安全审计）。但归根结底，“信任，但要核实” (trust, but verify) 是座右铭。人类仍然对交付的产品负责，因此统筹者需要确保 AI 的贡献符合团队的质量和道德标准。

总而言之，统筹者式开发的兴起并没有将人类从循环中移除——它改变了人类在循环中的位置。我们从那个“拧扳手”的人，变成了设计和监督“拧扳手”的机器的人。这是一个更高杠杆 (higher-leverage) 的位置，但也需要更广泛的意识。

那些适应成为高效的 AI 指挥者和统筹者的开发者，在这个新格局中可能会更有价值。

结论：每个工程师都会成为“音乐大师”吗？

每个工程师都会成为多个编码 AI 智能体的统筹者吗？这是一个引人深思的问题，但趋势表明，对于一大类编程任务，我们正朝着这个方向发展。在 2020 年代末，软件工程师的日常现实可能涉及更少的“埋头苦干”式编码，更多的是对主要由 AI 编写的代码进行高层次的监督。

今天，我们已经看到早期采用者将 AI 智能体视为团队成员——例如，一些开发者报告说每天将 10 多个拉取请求委托给 AI，有效地将 AI 智能体视为一个独立的团队成员，而不是一个智能自动补全。那些开发者解放了自己，专注于系统设计、棘手的算法，或者仅仅是协调更多的工作。

话虽如此，这种转变为不会一夜之间发生在每个人身上。初级开发者可能会从“AI 指挥者”开始，习惯于与单个 AI 智能体合作，然后才开始统筹多个。经验丰富的工程师更有可能早期采用统筹者工作流，因为他们有经验来架构任务和评估结果。在许多方面，这反映了职业成长：初级工程师实现（现在有 AI 帮助），高级工程师设计和集成（很快将有 AI 智能体团队的帮助）。

我们讨论的工具——从 GitHub 的编码智能体到谷歌的 Jules 再到 OpenAI 的 Codex——正在迅速降低尝试这种方法的门槛，所以预计它会很快成为主流。抛开夸张的成分不谈，这些能力确实可以极大地放大单个开发者所能做的事情。

那么，我们都会成为统筹者吗？可能在某种程度上——是的。我们仍将编写代码，特别是对于那些难以简单规范的新颖或复杂的部分。但大部分的样板代码、常规模式，甚至许多复杂的“胶水代码” (glue code) 都可以交给 AI。“软件工程师”的角色可能会演变为强调产品思维、架构和验证，而实际的编码在很大程度上将是一种自动化的行为。在这个设想的未来，要求一个工程师手动敲出数千行平凡的代码，会感觉就像要求一个现代会计师用铅笔和纸计算分类账一样低效。相反，工程师会将其委托给他们的 AI 智能体，并专注于围绕它的创造性和批判性思维方面。

顺便说一句，是的，有很多事情值得警惕。我们需要确保这些 AI 智能体带来的问题不会比它们解决的更多。而且，统筹多个 AI 智能体的开发者体验仍在成熟中——有时可能还很笨拙。但轨迹是清晰的。正如持续集成 (CI) 和自动化测试成为标准实践一样，持续委托给 AI (continuous delegation to AI) 可能会成为开发过程中的一个正常部分。那些掌握了这两种模式的工程师——知道何时成为一个精确的指挥者，何时扩展为一个统筹者——将最有能力利用这个“AI 智能体”的世界。

有一件事是肯定的：未来 5-10 年我们构建软件的方式将与过去 10 年截然不同。我想强调的是，并非所有或大部分代码会在一两年内由 AI 智能体驱动，但这是我们前进的方向。 键盘不会消失，但在我们的敲击声旁边，我们将向智能助手“蜂群”发出高层指令。归根结底，人的因素仍然是不可替代的：正是我们的判断力、创造力以及对现实世界需求的理解，引导着这些 AI 智能体走向有意义的结果。

编码的未来不是 AI 或人类，而是 AI 与 人类——由人类作为指挥者和统筹者掌舵，指挥一个强大的“合奏团”来实现我们的软件抱负。

我很高兴地宣布，我与 O'Reilly 合著了一本新的关于 AI 辅助工程的书。如果你喜欢我在这里写的文章，你可能有兴趣去看看。

来源: https://addyo.substack.com/p/conductors-to-orchestrators-the-future

See all posts