前言
有个读者说想知道怎么让多个agent相互配合，这也就是这篇文章的写作动机。 我们言归正传。
我大概是在2026年的一月份左右接触到OpenCode的。当时这个工具在程序员这个圈子里面，掀起过一阵讨论热潮。我是因为Oh My OpenCode 这个OpenCode插件才对OpenCode感兴趣的。 因为我当时是半全栈的感觉，刚好需要一个全栈助手，而Oh My OpenCode 当时的介绍正中下怀，里面有架构agent、前端agent等等。不过最后我没折腾成功，再加上当时中转站比较稳定，我就将这个事抛在一边了。
现在，随着我越来越深入地用大模型进行编码，我渐渐发现，一方面，token的消耗增速非常快; 另一方面是, 我喜欢用最先进的模型，但是最先进的模型思考时间比较长，执行也比较慢。 如果拆解AI 编码这个过程，我们可以把大模型编码分为几个步骤:
第一步，尝试理解你的语言； 第二步,将语言转换为对应的任务；第三步，在项目里面搜索文件；第四步，编写代码。 搜索文件这个工作，其实可以交给便宜一点的模型来做，因为这一步相当消耗token，如果交给昂贵的模型，不仅成本高，速度也比较慢。这让我重新想到了OpenCode: 能不能将昂贵的模型和便宜模型编排起来？
OpenCode 是什么？
在官网上，OpenCode 称自己为开源的AI编码代理，它提供终端界面、桌面应用和 IDE 扩展等多种使用方式。"代理"这个词容易让我想到的是Proxy。 那它代理的是什么呢？就像房产中介代理房子一样。那么，AI编码代理到底代理的是什么？ 所以我们不妨切换到英文文档看， 英文原文描述的是OpenCode is an open source AI coding agent。
这里我们再次碰到了agent。这个词在中文里面常被翻译为"智能体"，有时候也会被翻译成"代理"。我们不妨看看agent这个词在英文本身的含义：a person who acts for or represents another。 也就是代他人行动的人。在AI Coding agent这个语境下，该怎么理解呢？ 它使用开发者配置好的key，然后代开发者执行Coding这个动作。我们细致的分析agent词义的目的，是为了下次再碰到某个以agent 结尾的工具时，能够知道它的大致定位。
对于OpenCode来说，比较值得我们关注的一个能力就是agent 编排。
Agent编排 怎么理解？
主Agent + 子Agent
Coding agent 可以将我们的自然语言变成代码，但是如果不看执行计划，它的执行结果很容易跑偏。但人心往往是贪婪的，人总是希望自己只说很少的话，有第三方完全揣度出自己的心声。所以让coding agent 进行编程时，我一般是先做好计划，然后再执行。OpenCode 就将编码过程切割为了Plan 和Build模式: plan负责计划，build负责执行。 可以通过tab键来切换两种模式，如果你觉得Plan阶段太慢，可以直接切换到Build模式。
但build 这里是不是只能有一个执行者？ 也不见得。如果我们能够将任务拆分的足够独立，各个任务之间互相没有依赖关系，那么这些任务就可以被并行执行，这也就是general子代理的用处。
但开发时还有另一种常见需求: 我们需要知道代码的现状是什么，这也就需要对项目进行搜索。如何快速的搜索呢? 昂贵模型执行缓慢，我们不妨将目光转移到deepseek上，也就是说用deepseek充当探索者这个角色。
使用OpenCode进行编码，我推荐的步骤应当是先计划，后执行，执行的过程中OpenCode可以调用子代理加快速度。 这就呼应了我在《用 OpenCode 实现分层执行：让贵模型决策，便宜模型执行》这篇里面讲的内容: 让昂贵模型做决策，让便宜模型做执行。分离职责能够有效的降低token消耗，提升执行速度。但执行本身还可以继续拆分: 有些任务需要直接改代码，有些任务需要先搜索项目，这也就是General和Explore这两个子代理的用处。
agent team
理想的状态是各个agent执行的任务相互独立，互相不依赖。但如果两个agent之间需要通信呢？ 比如一个agent负责前端，一个agent负责后端，后端agent改了接口返回，前端agent如果不知道这个变化，可能还在按旧字段写。这种场景下，我们也可以让主agent做转发工作，所有信息先到主agent，再由agent进行转述。但这种结构容易慢半拍，为什么后端agent不能和前端agent之间进行通信呢？
再比如我们需要改动登录流程，给登录流程加验证码。 这个任务可以拆成以下几个子agent要执行的任务:
这里不是几个 agent 各干各的就行。它们之间有依赖：
- Test 发现的问题又可能反过来影响 Backend 和 Frontend
另一个场景是测试agent和实现agent之间需要反馈，比如测试 agent跑完测试之后发现登录失败测试失败，就需要直接反馈给Backend agent。Backend agent 修完后，再通知测试复测。这个场景很像真实开发里面的: 开发 => 测试 => 发现问题 => 反馈给开发 => 再测。这也就是agent编排的另一种形式agent team。OpenCode原生并不支持这种形式的agent编排，但是可以通过插件来做到，也就是Oh My OpenCode，现在已经更名为Oh My OpenAgent。需要值得说明的是Oh My OpenAgent在Team Mode这种形式下才会将编排模式调整为agent team这种形式。
那代价是什么？
但这里还有一个新的问题: 如果便宜的模型执行不力，或者在搜索中出现了幻觉该怎么办？ 这也是大模型让我沮丧的地方: 它像一个黑盒，对外暴露的窗口似乎就只有提示词。
解决这个问题的一个思路， 是昂贵的模型将执行路线做得具体一点，让便宜的模型严格按照这个路线执行，然后再复核结果。那用做探索的模型出现了幻觉怎么办？再加一个模型去验证吗？ 这个时候用贵一点的模型，还是便宜一点的模型？如果用贵的模型，那不是又回到了起点？我总是会想起埃舍尔的那幅画，两只手究竟是谁把谁画出来的呢？
我们似乎不能简单假定，眼前负责搜索的模型已经达到了主 Agent 的判断水平，然后选择相信它。我觉得应该有另一种解法：不是让模型彼此无限验证，而是让每一次探索都留下证据。
比如 Explore 不能只说“登录逻辑在 auth 模块里”，它要告诉我：它搜索了哪些关键词，读了哪些文件，找到了哪些函数，调用链是怎么连起来的，哪些文件看过之后被排除了，哪些地方它自己也不确定。这样主 Agent 拿到的不是一个黑盒结论，而是一条可以复核的证据链。它可以顺着这条链路检查 Explore 有没有漏看关键文件，函数关系是否成立，最终修改是否和代码现状一致。
开发者也一样。开发者不可能每次都重新理解整个项目，但可以抽查关键证据：核心文件、关键函数、调用路径、测试结果和最终 diff。只要这些证据能对上，就比单纯相信 agent 的一句“我已经检查过了”更可靠。
所以，我认为打破死循环的方式，不是再加一个模型去验证前一个模型，而是让 agent 的工作过程变得可检查。便宜模型可以做探索，但它必须把探索路径交出来；强模型可以做决策，但它必须基于证据做判断；开发者最后看的，也不是模型有多自信，而是证据是否站得住。
如何安装OpenCode
这里提供一种简单省力的方式来安装OpenCode。 如果你是Windows 环境，建议先安装一个WSL。OpenCode官方也推荐这个运行环境，在这个环境中能获得最佳运行体验。
然后你需要有大模型厂商提供的CLI，将OpenCode的官网交给它，让它帮你安装opencode。这似乎是AI原生时代安装软件最快的方式，前提是，安装过程中不出错。
推荐安装的插件CodeGraph
CodeGraph是这么介绍自己的: 当Claude Code 探索一个代码库的时候，会启动一些Explore agents(探索代码)。 这些代理会通过grep、glob和Read等方式来扫描文件，而每次工具调用都会消耗token。CodeGraph则为这些agent提供了一张提前索引好的知识图谱，其中包含:
这样agent就可以直接快速地查询这张图，而不必再逐个扫描文件。也就是说，这个插件能够帮你省token，加快扫描速度。如果你已经安装好了OpenCode，可以让OpenCode帮你安装这个插件。
写在最后
到这里，我们已经对OpenCode做了一个概述，对agent 编排有了一个基本的概念。也许OpenCode的这些能力，未来都会被各家模型厂商提供的agent 或者CLI吸收进去。但从一体化程度上来说，模型厂商提供的coding agent，往往更面向自家模型。在实际开发中，我们可能要组合多个模型的能力，来完成开发工作。
参考资料
参考资料
[1] OpenCode Agents Documentationhttps://opencode.ai/docs/agents/
[2] CodeGraph GitHub: Pre-indexed code knowledge graph for coding agentshttps://github.com/colbymchenry/codegraph
[3] CodeGraph OpenCode Integration Documentationhttps://codegraph.ru/docs/en/integrations/OPENCODE_PLUGIN.html
[4] Oh My OpenAgent GitHubhttps://github.com/code-yeongyu/oh-my-openagent
