1. 背景介绍

随着大型语言模型（LLM）能力的飞速发展，我们正在进入一个由 AI Agent 驱动的软件开发新时代。Agent，作为能够自主理解、规划并执行复杂任务的智能实体，正逐渐从理论走向实践，深刻改变着开发者与代码交互的方式。从最初的单体 Agent 辅助编码，到如今由多个专业 Agent 协同作战，多 Agent 系统（Multi-Agent Systems）已成为提升开发效率、解决复杂软件工程问题的关键。

什么是agent

在人工智能领域，一个 AI Agent（智能体）可以被理解为一个能够感知其环境、进行自主决策并执行动作以实现特定目标的计算实体。不同于传统的程序，Agent 具备一定程度的自主性、反应性和社会性。一个典型的 Agent 系统由以下几个核心部分组成：

  • 感知（Perception）：通过传感器或数据输入来获取环境状态信息。
  • 决策（Decision-Making）：基于其内部知识、目标和感知到的信息，通过推理或学习来选择下一步的行动。
  • 行动（Action）：通过执行器（如 API 调用、代码执行）来改变环境状态。
  • 学习（Learning）：根据行动的反馈和结果来调整其内部模型和决策逻辑，以提升未来表现。

对于编码 Agent 而言，其环境是代码库、IDE、终端和外部文档；其行动包括读取/写入文件、执行命令、调用工具、与用户交互等；其目标则是根据用户指令完成软件开发任务，例如实现新功能、修复错误或重构代码。

在当前大语言模型（LLM）的浪潮下，Agent 的概念被进一步发扬光大。LLM 成为了 Agent 强大的“大脑”，使其具备了前所未有的自然语言理解、推理和规划能力。一个基于 LLM 的 Agent 通常能够理解复杂的指令，拆解任务，调用外部工具（如搜索引擎、代码解释器、数据库），并根据结果进行下一步操作，从而完成比单纯的文本生成复杂得多的任务。

Agent = 感知 (Perception) + 规划 (Planning) + 行动 (Action)

为什么需要 Multi-Agent？

随着任务复杂度的提升，单一的、全能型的 Agent 开始暴露出其局限性。

局限性 描述
任务类型单一 某个模型/擅长某类任务，难以覆盖所有场景
上下文窗口限制 大型项目难以在一个会话中处理
并发能力缺失 无法同时处理多个独立任务
专业化缺失 缺乏特定领域的深度知识
验证不足 自己的工作难以自我验证

这与人类社会的发展类似，当任务超出个人能力范围时，就需要团队协作。多 Agent 系统（Multi-Agent System, MAS） 正是应对这一挑战的产物。它是一个由多个自主 Agent 组成的系统，这些 Agent 通过相互通信与协作来解决单个 Agent 难以甚至无法完成的复杂问题。

引入多 Agent 架构主要有以下几点好处：

  1. 专业化分工（Specialization）：现实世界的任务往往需要多种不同的技能。例如，完成一个软件开发需求，可能需要产品经理进行需求分析、架构师进行系统设计、程序员进行编码、测试工程师进行质量保证。在多 Agent 系统中，我们可以设计具有不同“角色”和“专长”的 Agent，如“代码生成 Agent”、“代码审查 Agent”、“安全分析 Agent”等。每个 Agent 专注于其擅长的领域，从而提升整体的效率和产出质量。

  2. 可扩展性与可维护性（Scalability & Maintainability）：在单 Agent 系统中增加新功能，往往意味着对其核心 Prompt 和逻辑进行复杂且风险较高的修改。而在多 Agent 系统中，增加新能力通常只需要引入一个新的、具有特定技能的 Agent 即可，对现有系统的侵入性更小。这种模块化的设计使得系统更易于扩展和维护。

  3. 并行与效率（Parallelism & Efficiency）：对于可以分解的子任务，多 Agent 系统可以并行执行，显著缩短任务完成时间。例如，在进行技术选型时，可以同时派出多个 Agent 分别研究不同方案的优缺点，然后汇总报告，这远比单个 Agent 依次研究要高效得多。

  4. 鲁棒性与可靠性（Robustness & Reliability）：通过引入冗余或多样化的 Agent，系统可以对冲单个 Agent 失败或表现不佳的风险。例如，可以设计一个“评审 Agent”，对其他 Agent 的产出进行检查和验证，形成制衡，从而提高最终结果的可靠性。

正是这些优势，使得多 Agent 系统成为构建下一代智能编码工具的核心架构选择。接下来，我们将深入探讨实现多 Agent 协作的关键——Agent 编排。

多 Agent 编排

什么是multi agent

多 Agent 系统的核心挑战在于编排（Orchestration）——即如何有效地组织和协调多个 Agent 的行为，使其能够作为一个整体高效协作。它定义了 Agent 之间如何分配任务、共享信息、解决冲突以及整合各自的工作成果。一个优秀的编排系统是多 Agent 系统成功的关键，它如同一个经验丰富的项目经理或技术总监，确保整个“Agent 团队”能够高效、有序地运作。

主流编排模式

业界已经探索出多种成熟的 Agent 编排模式，每种模式针对不同的任务复杂度、上下文管理需求和协作方式，适用于不同的场景。根据 LangChain 和微软 Azure 等机构的总结，目前主流的编排模式可以归纳为以下几种 [2][3]：

编排模式 核心思想 适用场景
顺序编排 (Sequential) Agent 像流水线一样按预定顺序依次执行，每个 Agent 处理上一个 Agent 的输出。 具有明确线性依赖关系的多阶段流程，如“草稿-审查-发布”的内容生成管道。
并发编排 (Concurrent) 多个 Agent 同时对同一任务进行独立处理，最后由一个聚合器整合结果。 需要从多个独立视角进行分析或评估的任务，如对一个技术方案进行多维度评审。
群聊编排 (Group Chat) 多个 Agent 在一个共享的对话空间中进行开放式讨论和协作，类似于人类的团队会议。 需要集思广益、迭代创新的复杂问题，如系统架构设计或头脑风暴。
交接编排 (Handoff) Agent 根据任务的当前状态和需求，动态地将控制权“交接”给最合适的下一个 Agent。 任务流程不固定，需要根据中间结果进行动态路由的场景。

Sequential orchestration

将多个 Agent 按照预定义的线性顺序连接起来，形成一个处理管道。

每个 Agent 的输出是下一个 Agent 的输入，类似于工厂流水线。

具有明确前后依赖关系的多阶段任务，如“草稿-审查-润色”流程。

优点：简单直观，易于实现和管理。
缺点：灵活性差，不支持并行、分支或迭代。

Subagents: Centralized orchestration

由一个中心化的智能体（Supervisor／Coordinator）负责总体控制，调用多个“子智能体”作为工具执行具体子任务。

主管 Agent 将子 Agent 作为“工具”来调用，负责收集结果并进行最终决策。子 Agent 通常是无状态的。

子智能体不自己保存历史对话或状态；主智能体统一组合结果并返回

优点：控制力强，易于追踪任务状态。
缺点：主管 Agent 容易成为性能瓶颈，所有通信都需经过中心节点，延迟较高。

Skills: Progressive disclosure

不是严格意义上的多智能体，而是一个智能体根据任务动态加载不同“技能包（Skill）”，这些技能包封装了特定能力的提示、指令和资源。

单一智能体需具备多种专业能力；

Skill 被加载后会进入对话历史

多次调用后容易出现上下文膨胀（token 累积）

Handoffs: State-driven transitions

控制权在不同的 Agent 之间根据预设的条件进行转移，形成一个状态机，实现分阶段、顺序性工作流。

每个 Agent 完成自己的阶段性任务后，将控制权和相关状态“交接”给下一个指定的 Agent。

具有明确阶段划分和状态转换的流程，如客户支持、多步表单填写。

优点：流程清晰，状态管理明确，适合顺序解锁能力的场景。
缺点：状态管理更复杂，需要精心设计状态存储与切换逻辑。

Router: Parallel dispatch and synthesis

通过一个 Router Agent 对请求进行分类或拆解，并将子任务 并行分发 给多个专用 Agent，并对返回的结果进行综合。

需要根据输入类型动态选择处理路径，或需要并行查询多个信息源的场景。

优点：并行效率高，可扩展性好。
缺点：如果需要维护对话历史，会产生重复的路由开销。

Group Chat

多个 Agent 在一个共享的对话空间中进行交互，每个 Agent 都能看到其他 Agent 的发言并作出反应。

类似于人类的团队会议，通过多轮对话和讨论来共同解决问题。通常需要一个“管理员”来引导流程。

需要动态、复杂交互和集体决策的探索性任务。

优点：高度灵活，能够模拟复杂的协作模式。
缺点：难以控制流程，容易出现无效讨论或循环，对 Agent 的协作能力要求高。

主流编排框架比较

除了理论模型，社区也涌现出多个优秀的开源框架，旨在简化多 Agent 系统的开发。其中，LangGraph、CrewAI 和 AutoGen 是目前最受关注的几个框架。

  • LangGraph: 由 LangChain 团队开发，它将多 Agent 协作流程建模为图（Graph），其中每个节点代表一个 Agent 或一个工具。这种方式为定义复杂的、带有循环和条件分支的工作流提供了极大的灵活性和控制力。

  • CrewAI: 专注于通过角色扮演来定义 Agent 的能力和职责。它提供了一种高度声明式的方法来组建“Agent 团队”，强调的是 Agent 的角色定位和团队协作流程。

  • AutoGen: 由微软研究院推出，其核心理念是让 Agent 通过对话进行协作。它擅长构建能够自动进行多轮对话、协商和共同解决问题的 Agent 系统。

维度 AutoGen (Microsoft) CrewAI LangGraph (LangChain)
核心理念 对话驱动 角色驱动 图结构驱动
架构隐喻 多个 Agent 通过对话进行协作 一个分工明确的“小公司”或“团队” 流程图或状态机
设计特点 以“对话”为中心，Agent 间通过消息传递进行协作，支持灵活的对话模式和人机混合。 强调“角色”（Role）、“职责”（Duty）和“任务”（Task）的定义，流程固定为“规划-执行-验证”。 将多 Agent 协作流程建模为图（Graph），每个节点（Node）是一个 Agent 或工具，边（Edge）代表流程的走向，支持复杂的条件分支和循环。
适用场景 探索性任务、快速原型验证、需要人类参与的复杂对话系统。 目标明确、流程固定的业务自动化任务，如市场分析报告生成、邮件自动化处理等。 需要对工作流进行精细控制的复杂、动态任务，如需要条件判断、迭代修改的软件开发流程。
优缺点 优点：灵活，易于上手，非常适合模拟人类协作。
缺点：流程控制相对困难，容易陷入无效对话。		 优点：概念清晰，结构化强，易于理解和管理。
缺点：流程相对固定，灵活性不足。		 优点：控制力最强，高度灵活和可定制。
缺点：学习曲线最陡峭，需要开发者具备图的思维模式。

从 OpenCode 到 Oh-My-OpenCode

OpenCode 作为一个开源的 AI 编码 Agent，提供了一个坚实的基础平台。而 Oh My OpenCode 作为其社区驱动的增强插件，则在多 Agent 协作与编排方面进行了大刀阔斧的创新，为我们展示了从“单兵作战”到“团队协同”的进化路径。

OpenCode

架构设计

OpenCode 采用了经典的客户端-服务器（Client-Server）架构，这使其具备了良好的跨平台能力和远程协作潜力。其 Agent 系统设计简洁而高效，主要包含两类主 Agent 和一系列辅助性子 Agent。

  • 主 Agent (Primary Agents)：这是用户直接交互的核心。build Agent 拥有完整的开发权限，负责执行代码修改、文件操作等任务；而 plan Agent 则是一个只读的“分析师”，用于在不产生副作用的前提下探索代码库和规划任务，体现了安全性的考量。

  • 子 Agent (Subagents)：作为主 Agent 的“工具”存在。例如，general Agent 用于处理复杂的多步研究任务，而 explore Agent 则专注于快速的代码库搜索。这些子 Agent 在被调用时执行特定任务，但本身不维护长期状态，其生命周期由主 Agent 完全控制。

这种设计本质上是中心化编排模式（Coordinator/Subagents） 的一种实现。主 Agent 如同大脑，负责思考和决策，子 Agent 如同四肢，负责执行。所有任务流、信息流都汇聚于主 Agent，由其统一调度。这种模式简单、可控，但主 Agent 容易成为能力的上限和性能的瓶颈。

可拓展性

OpenCode 的前瞻性在于其对扩展性的重视。它通过两大协议来构建其开放生态：

  • Agent Client Protocol (ACP)：这是一套基于 JSON-RPC 的标准化协议，允许第三方开发者将自己的 Agent 接入 OpenCode 的生态系统。这为我们自己的产品集成提供了标准接口。
  • Model Context Protocol (MCP)：该协议旨在标准化 Agent 与外部工具（如 API、数据库）的交互。通过 MCP，我们可以将公司内部的各种服务（如代码分析工具、知识库）封装成 Agent 可用的“工具”，实现能力的复用。

此外，其内置的细粒度权限系统（PermissionNext），允许对文件访问、命令执行等敏感操作进行 allow、deny、ask 三种级别的控制，为 Agent 的安全运行提供了保障。

Oh-My-OpenCode

架构设计

如果说 OpenCode 是一个能力全面的“全栈工程师”，那么 Oh My OpenCode 则构建了一个各司其职、高效协作的“精英技术团队”。它在 OpenCode 的基础上，引入了更为复杂的分布式协作架构。

Oh My OpenCode 的核心是名为 Sisyphus 的主编排 Agent。它的角色不再是亲力亲为的执行者，而是一位经验丰富的“技术主管”或“架构师”。其核心职责是理解用户意图、分解复杂任务，并将其委派给最合适的专家 Agent。Sisyphus 的工作流程被设计为多阶段的决策过程：

  1. 意图识别：首先判断用户请求的类型（是简单的问答，还是复杂的开发任务？）。
  2. 代码库评估：对于开放式任务，它会先评估当前项目的代码质量和风格，以决定后续工作的策略。
  3. 委派决策：这是最关键的一步。Sisyphus 根据任务的性质，决定是将其分配给一个具有特定“类别（Category）”的通用开发 Agent，还是直接指派给一个高度专业化的 Agent。

Agent 类型

Oh My OpenCode 的强大之处在于其丰富的专家 Agent 团队。每个 Agent 都有明确的职责和推荐使用的模型，以达到最佳性价比和效果。

Agent 角色 模型 核心职责
Sisyphus Claude Opus 4.5 核心编排者，负责任务的执行和委派。
Prometheus Claude Opus 4.5 规划者，负责制定工作计划。
Oracle GPT-5.2 Medium 架构师/调试专家，提供高层次的调试和复杂问题分析。
Frontend UI/UX Engineer Gemini 3 Pro Preview 前端专家，负责视觉设计和 UI 实现。
Document-Writer Gemini 3 Pro Preview 技术文档撰写
MultiModal Looker Gemini 3 Flash PDF/ 图像等多模态内容分析
Librarian GLM-4.7 研究员，多仓库分析，文档检索与整理。
Explore Grok Code 代码上下文探索
Metis & Momus Claude Sonnet 4.5 顾问与审查者，负责在规划阶段进行预分析、风险识别和计划校验。

工作流

Oh My OpenCode 设计了一套完整的工作流，将用户的模糊意图转化为精确的代码实现。这个过程被清晰地划分为三个阶段：

阶段一：访谈与规划 (Interview & Planning)

  • 过程: Prometheus Agent 接管，通过提问、分析现有代码（调用 explore Agent）和查阅文档（调用 librarian Agent），与用户共同明确需求，并将所有讨论内容记录在 .sisyphus/drafts/ 目录下。
  • 产出: 一份详尽、结构化的任务计划 Markdown 文件，存放在 .sisyphus/plans/ 目录下。

阶段二：计划审查 (Plan Review)

  • 过程: Momus 对 Prometheus 生成的计划进行严格审查，如果发现任何模糊、遗漏或不合理之处，会拒绝该计划并要求 Prometheus 重新修订，直到计划完美无缺。

阶段三：执行 (Execution)

  • 过程: Sisyphus Agent 读取最终确定的计划，并创建一个 boulder.json 文件来跟踪任务状态。然后，它会逐一处理计划中的 TODO 事项，通过 sisyphus_task() 函数将具体的子任务委派给最合适的专业 Agent（如将 UI 任务交给 frontend-ui-ux-engineer）。
  • 特点: 整个执行过程是持续的、可恢复的。即使会话中断，Sisyphus 也能通过 boulder.json 在下次启动时从中断处继续执行。

sisyphus_task：编排的核心工具

Sisyphus 通过 sisyphus_task 这一核心工具来下达指令。该工具的设计精妙地体现了其编排思想：

  • Category 模式：对于通用的开发任务，Sisyphus 可以指定一个“类别”，如 visual-engineering（前端视觉）或 ultrabrain（后端逻辑）。系统会据此动态生成一个名为 Sisyphus-Junior-{category} 的子 Agent 来执行任务。这类似于为项目临时组建一个“功能小组”。
  • Agent 模式：对于需要特定专家能力的，Sisyphus 可以直接指定 Agent 名称，如 subagent_type="oracle"，将任务直接委派给专家。

后台任务并行执行

Oh My OpenCode 最具突破性的创新之一是其后台任务系统（Background Task System）。当 Sisyphus 发出指令时，可以通过 run_in_background=true 参数，让子 Agent 在一个独立的后台会话中执行任务。这意味着 Sisyphus 可以同时委派多个研究或探索性任务，实现真正的并行工作，极大地提升了信息收集和分析的效率。这套系统包含了完整的任务生命周期管理、并发控制和完成通知机制，是一个工业级的实现。

技能系统与通信机制

  • 技能系统 (Skills)：Oh My OpenCode 引入了“技能”的概念，这是一些可复用的、针对特定任务的指令集（如 frontend-ui-ux、playwright）。在委派任务时，Sisyphus 可以为子 Agent “装备”上相应的技能，从而更精确地指导其行为。

  • 通信机制：Oh My OpenCode 的通信是异步和事件驱动的。每个后台任务都在独立的会话中运行，通过会话 ID 与父会话关联。任务完成后，通过事件通知 Sisyphus。这种设计解除了主 Agent 与子 Agent 之间的紧耦合，是实现高并发、分布式协作的基础。

OpenCode 对比 Oh-My-OpenCode

维度 OpenCode Oh My OpenCode 设计演进
编排模式 中心化编排 (Coordinator) 分布式协作 + 中心化委派 (Hybrid) 从“主管-员工”模式演变为“项目经理-专家团队”模式。
Agent 角色 通用执行者 + 辅助工具 战略编排者 + 高度专业化的专家 职责更加细分，专业化程度显著提高。
并行能力 有限（依赖于主 Agent 的工具调用方式） 完整的后台任务系统，支持真并行 从顺序执行演变为并行执行，效率大幅提升。
状态管理 主 Agent 集中管理 分布式状态，每个子 Agent 拥有独立会话 状态管理下沉，降低了中心节点的复杂性，提高了可扩展性。
通信方式 同步工具调用 异步消息 + 事件驱动 从紧耦合的同步调用演变为松耦合的异步通信，适应分布式系统。

通过对比可以看出，Oh My OpenCode 并非简单地对 OpenCode 进行功能增强，而是在其基础上进行了一次深刻的架构范式升级。它从一个强大的“个人英雄”，演变成一个懂得如何“领导团队”的“卓越领导者”，其设计思想更贴近于解决真实世界中复杂软件工程问题所需要的团队协作模式。

ultrawork：

Oh My OpenCode 认识到，并非所有任务都需要用户深度参与规划。为此，它提供了一个名为 ultrawork（或 ulw）的“魔法词”。当用户在提示中包含这个词时，相当于将整个“规划-执行”流程完全委托给 Agent 系统自动完成。这极大地降低了使用门槛，让用户在不想关心细节时，也能享受到多 Agent 编排带来的强大能力。

讨论 & 总结

引入多 agent 并发执行

并行多个agent同时开发，最后审核对比

用的比较多的 CLI 工具

opencode 有哪些心得/好用的点/不好用的点

参考资料