一人软件公司：OpenCode 多Agent并行开发实操

• OpenCode 多 Agent 的核心思路
• OpenCode Ensemble 是怎么工作的
• 一次像样的实战，应该怎么跑
  • 第一步：先拆依赖，再拆人
  • 第二步：给子 Agent 设硬边界
  • 第三步：把“消息传递”用在真正有依赖的地方
  • 第四步：最后一道关必须是人工审查
  • 第五步：会话断了，优先接管，不要急着重跑
• OpenCode 多 Agent 适合什么任务
  • 1. 同一目标下的多模块改动
  • 2. 明确、可验收、边界稳定的任务
  • 3. 已经有一定工程基础的项目
• 什么情况下别上多 Agent
  • 1. 需求还在变
  • 2. 多个任务一定会改同一批核心文件
  • 3. 项目没有任何验收抓手
  • 4. 你自己还没想清楚验收标准
• 一人公司怎么起步最稳
  • 档位一：2 个 Agent
  • 档位二：3 个 Agent
  • 档位三：4 个以上 Agent
• 一份能直接照着用的起手式
• 总结
• 参考文献

本文首发地址 https://h89.cn/archives/578.html
一个人，不是只能开一个终端慢慢改。需求拆得对，OpenCode 可以让你像带一个小团队一样推进前后端、测试和修复。

一人公司最容易卡住的，不是不会写代码，是事情全挤在一个人脑子里。

一个真实的软件需求，通常不是一块完整的代码，而是四五件彼此有关、但又不必串行的活：

• 后端补接口
• 前端接页面
• 校验规则统一
• 测试补齐
• 文档和变更说明收尾

如果你还是用单 Agent 一条条做，流程基本会退化成这样：刚写完接口，切到前端；前端刚接一半，发现测试没补；测试补的时候，又发现验证规则前后不一致。上下文来回切，脑子最先炸。

OpenCode 的多 Agent 方案值钱，就值钱在一件事上：把这些本来就能并行的活拆开，让主 Agent 负责调度，子 Agent 负责执行，你只盯需求和验收。

这篇文章不再铺一堆工具，而是只讲一个问题：OpenCode 多 Agent 到底怎么落地，适合一人公司什么场景，又不适合什么场景。

先把结论放前面：如果你现在还是一个人盯着前端、后端、测试来回切，OpenCode 多 Agent 最适合解决的是同一需求下的多模块并行。如果你的需求还在飘，或者多个任务一定会改同一个核心文件，那先别上。

OpenCode 多 Agent 的核心思路

OpenCode Ensemble 的底层不是魔法，本质上还是 Orchestrator 模式：

一句需求
   │
   ▼
主 Agent
   │
   ├── 拆任务
   ├── 判断依赖
   ├── 创建团队
   └── 派发给子 Agent
           │
           ├── Agent A：改后端
           ├── Agent B：改前端
           └── Agent C：补测试
                    │
                    ▼
             合并 / 审查 / 收尾

这里面最关键的不是“并行”两个字，而是下面三件事：

1. 任务边界要清楚
2. 子 Agent 必须隔离
3. 最后必须有人审查

前两件做不好，多 Agent 不是提效，是制造 Git 冲突。第三件做不好，合并回主分支时迟早翻车。

OpenCode Ensemble 是怎么工作的

OpenCode Ensemble 是 OpenCode 的多 Agent 插件。主 Agent 可以创建团队、生成子 Agent、传消息、处理依赖、最后合并。

最小配置就是一行：

{
  "plugin": ["@hueyexe/opencode-ensemble@0.13.0"]
}

装完以后，你的交互方式会从“自己开 3 个终端”变成“只跟主 Agent 说一句话”。

比如这类需求：

给现有 API 端点加输入验证，前端表单报错文案也要统一，同时补上集成测试。

主 Agent 比较合理的拆法，通常是这样：

team: validation

- alice
  目标：处理用户相关接口的输入验证
  范围：src/api/users/, src/validators/user.ts

- bob
  目标：处理订单相关接口的输入验证
  范围：src/api/orders/, src/validators/order.ts

- carol
  目标：补集成测试和前端错误提示
  依赖：alice、bob 完成后再启动
  范围：tests/integration/, src/web/forms/

这个拆法里有两个实战细节很重要：

1. 按目录和模块拆，不按“感觉”拆
2. 测试 Agent 放在依赖链后面，不要一开始就并行跑

这里顺手说一个很实际的问题：team: validation 这种名字，不一定非要主 Agent 自己决定。

一般有两种方式：

1. 你自己指定
2. 让主 Agent 自己创建

如果你已经想清楚任务边界，可以直接在 prompt 里说：

创建一个 team，名字叫 validation。
把用户接口验证、订单接口验证、集成测试拆成 3 个子任务。

如果你只关心结果，不想管命名和编排细节，也可以这么说：

给现有 API 端点加输入验证，并补测试。
你自己拆任务并创建合适的团队。

我的建议是第一次跑多 Agent 时别全放开，最好用“半指定”模式：你来指定目标、范围和依赖，team 名和具体分工让主 Agent 去完成。这样既不会失控，也能看出它的调度能力。

如果你把 3 个 Agent 都同时扔出去，而且它们都要碰 shared schema 或 common utils，那不是团队协作，是三个人抢一把键盘。

再直白一点，适合拆给不同 Agent 的，通常是这种结构：

任务	是否适合并行	原因
用户接口验证	适合	范围清楚，能按目录隔离
订单接口验证	适合	与用户模块耦合低
集成测试	适合后置并行	依赖前面两个模块稳定后再接
共用 schema 重构	不适合	多个 Agent 容易同时改到同一处
命名规范统一	谨慎	看起来简单，实际容易扫到全仓库

一次像样的实战，应该怎么跑

先给一个我认为最像一人公司日常的例子：给一个已经上线的小型 SaaS 后台补一套邀请码机制。

这个需求看着像一件事，实际上至少分成 4 段：

• 数据结构和接口契约
• 后端生成与校验逻辑
• 管理后台页面
• 测试和发布说明

如果你把它交给一个 Agent 从头写到尾，它很可能在一个长上下文里来回切。更稳的做法，是按下面这个节奏推进：

阶段	谁来做	产出
设计	主 Agent 或你自己	字段、接口、验收标准
并行 1	Agent A	后端邀请码生成与校验
并行 2	Agent B	后台管理页面
后置	Agent C	集成测试、错误提示检查
收口	你自己	看 diff、跑验证、决定是否合并

这个表看起来很普通，但它解决的是一人开发最贵的东西：上下文切换。

第一步：先拆依赖，再拆人

一人公司最容易犯的错，是看见能并行就想全并行。其实真正应该先问的是：

• 哪些任务一定要先做
• 哪些任务能独立验收
• 哪些任务一定会改到同一批文件

我更建议用这种方式想：

需求：给 SaaS 后台加一套邀请码机制

先做：
- 设计字段和接口契约

可以并行：
- Agent A：后端邀请码生成与校验
- Agent B：后台管理页面

后置任务：
- Agent C：集成测试
- Agent D：文档和发布说明

这里“设计字段和接口契约”不要并行。因为这一步没定，后面的前后端一定反复返工。

第二步：给子 Agent 设硬边界

子 Agent 不是同事，它不会自动理解“这个文件虽然能改，但最好别碰”。边界不写清楚，它就会为了完成目标顺手把别的地方也改了。

Prompt 里至少要明确 3 件事：

1. 目标是什么
2. 允许修改哪些目录
3. 不允许碰哪些文件

比如：

处理用户注册接口的输入验证。

只允许修改：
- src/api/users/
- src/validators/user.ts

不要修改：
- package.json
- 数据库迁移文件
- 共享 UI 组件

完成后输出：
- 改动说明
- 风险点
- 需要谁继续接手

这段约束看起来土，但很管用。很多翻车都不是模型不会写，而是它写得太积极了。

第三步：把“消息传递”用在真正有依赖的地方

OpenCode Ensemble 支持子 Agent 之间通信，这个能力不是拿来聊天的，是拿来处理交叉依赖的。

一个典型场景：

alice → bob：用户邮箱验证我用了 z.string().email()，订单联系人邮箱也统一吗？
bob → alice：统一，我这边也按这个规则走，避免前后端提示不一致。

只有当两个任务共享规则，但又不值得合并成一个任务时，这种消息机制才有意义。

第四步：最后一道关必须是人工审查

多 Agent 最容易给人一种错觉：都已经拆开干活了，最后自动 merge 就行。

这个想法很危险。

一人公司不是没人 review，而是你自己就是最后那个 reviewer。合并前至少看这三件事：

• 有没有多个 Agent 分别引入相似但不一致的实现
• 有没有顺手改了范围外文件
• 测试补的是不是在测真正的业务约束，而不是只让 CI 变绿

如果你想把这件事做成固定动作，最小检查清单可以直接用下面这版：

• diff 有没有超出任务目录
• lint/test/build 至少跑一轮
• 前后端字段名、错误码、提示文案有没有对齐
• 子 Agent 的改动说明里，有没有遗留风险没交代

第五步：会话断了，优先接管，不要急着重跑

多 Agent 真正在现场最常见的问题，不是不会拆任务，而是中途退出之后还能不能接上。

这里要分两种情况看：

1. 只是退出界面，但 session 还在
2. 对话回不去了，session 也丢了

第一种情况，不一定要重新创建 Agent。如果 OpenCode 和插件还能恢复原来的 session，那就继续用原来的主 Agent 和子 Agent。

第二种情况，通常就要重新创建主 Agent，或者至少重新编排一轮。原因很简单：多 Agent 丢掉的不只是聊天记录，还可能包括这些运行时状态：

• 任务是怎么拆的
• 哪些子 Agent 已完成
• 哪些任务还在阻塞
• 子 Agent 之间传过什么消息
• 当前审查和合并进行到哪一步

如果这些状态没有持久化，只剩下 worktree、分支和代码改动，那你能恢复结果，但不一定能恢复协作过程。

这时候最稳的处理方式是：

1. 先检查各个 worktree 或分支还在不在
2. 看哪些代码已经完成，哪些只做了一半
3. 重新创建一个主 Agent
4. 把当前状态明确告诉它，让它接管剩余任务

比如可以直接给它这样一段：

之前的多 Agent 会话中断了，现在继续接管。

当前状态：
- user-validation 分支已完成输入验证
- order-validation 分支已完成主要逻辑，但未审查
- integration-tests 还没开始
- 不要重做已完成代码，先读取现有改动
- 接下来请基于当前 worktree / 分支状态继续编排剩余任务

所以对一人公司来说，一个很现实的原则是：多 Agent 流程最好设计成“就算 session 丢了，也能靠代码状态继续接管”。每个子 Agent 最好都留下这几样东西：

• 清晰的分支或 worktree
• 明确的改动范围
• 简短的任务说明
• 当前完成度说明

OpenCode 多 Agent 适合什么任务

最适合的是这三类：

1. 同一目标下的多模块改动

比如一个需求同时涉及：

• API 输入验证
• React 表单交互
• 集成测试

目标是同一个，但代码落点分散，天然适合拆开。

2. 明确、可验收、边界稳定的任务

例如：

• 给现有接口补鉴权
• 批量补测试
• 把一组页面接到已有 API 上

这类任务的共同点是：验收标准比较清楚，Agent 不需要猜你脑子里的产品方向。

3. 已经有一定工程基础的项目

如果你的项目至少具备下面两样，多 Agent 才容易提效：

• 有测试或最起码的验证命令
• 目录结构比较稳定

如果仓库本身就乱，OpenCode 只会更快地把混乱扩大。

什么情况下别上多 Agent

这部分反而更重要。

1. 需求还在变

需求没定时，多 Agent 会把错方向同时放大。你今天改数据结构，明天改交互，后天再改命名，最后每个子 Agent 都得返工。

2. 多个任务一定会改同一批核心文件

比如都要碰：

• schema.ts
• auth middleware
• shared form component

这种场景强行并行，最后大概率在合并时一起结账。

3. 项目没有任何验收抓手

没有测试、没有 lint、没有最基本的运行检查，主 Agent 再会调度也没用。因为你根本不知道“完成”到底是完成了，还是只是生成了一堆看起来像样的 diff。

4. 你自己还没想清楚验收标准

这是很多人不愿意承认的一点。Agent 不会替你定义产品边界，它只会更快执行你给出的边界。你如果自己都说不清“这个功能做成什么算完成”，那多 Agent 只会更快制造返工。

一人公司怎么起步最稳

不要一上来就开 8 个 Agent。我更建议按这三档走：

档位一：2 个 Agent

适合第一次试。

• Agent A：后端
• Agent B：前端或测试

先验证你能不能把范围控制住。

档位二：3 个 Agent

这是最实用的一档。

• Agent A：业务实现 1
• Agent B：业务实现 2
• Agent C：测试 / 收尾

大多数独立开发者在这一档就够用了。

档位三：4 个以上 Agent

只有当你的任务拆分已经很稳定、项目结构也足够清楚时，再往上加。否则协调成本会上来，最后收益不一定比 3 个 Agent 更高。

一份能直接照着用的起手式

如果你准备第一次在 OpenCode 里试多 Agent，我建议从下面这种需求开始：

• 不改数据库主结构
• 不动认证主链路
• 能拆成后端、前端、测试三块
• 有现成的验证命令

一个比较稳的 prompt 模板可以写成这样：

给现有功能补输入验证和测试。

目标：
- 用户接口补输入验证
- 前端表单提示文案统一
- 增加对应集成测试

要求：
- 先拆任务，再创建团队
- 后端和前端可以并行
- 测试任务必须在前两个任务完成后再启动
- 每个子 Agent 只能修改自己负责的目录
- 合并前先汇总改动和风险

第一次别追求酷，追求稳。只要你能连续两三次把这种中等复杂度需求跑顺，多 Agent 才算真的进入可用状态。

总结

OpenCode 多 Agent 真正解决的，不是“AI 会不会写代码”，而是“一个人怎么同时推进多块互相有关、但不必串行的活”。

如果你是一人公司，我觉得最实用的经验就三条：

1. 先拆依赖，再拆 Agent
2. 范围写死，不要让子 Agent 自由发挥
3. 最后的审查和合并，必须你自己兜底

它不是万能加速器，也不是一句 prompt 就能自动交付的软件工厂。

但在任务边界清楚、仓库结构稳定的前提下，OpenCode 确实能让一个人干出一点“小团队协作”的味道。

如果你想看 OpenCode 之外还有哪些多 Agent 方案，可以接着看下一篇：一人公司：还有哪些多Agent并行开发方案。

参考文献

[1] OpenCode Ensemble — https://github.com/hueyexe/opencode-ensemble
[2] OpenCode — https://github.com/sst/opencode