OpenCode 多 agent 协作简介

Eloudy

293人浏览 · 2026-08-18 02:11:05

Eloudy · 2026-08-18 02:11:05 发布

OpenCode 实现多 Agent 协作主要依赖其插件生态，核心思路是主 Agent 编排 + 多个子 Agent 并行执行。以下是完整的实现路径：

1. OpenCode 多 Agent 简介

1.1. 核心架构：Sisyphus 模式

OpenCode 原生是单 Agent 的终端 AI 助手，多 Agent 能力通过插件（主要是 Oh-My-OpenCode）注入。其架构模仿人类开发团队：

角色	职责	典型 Agent 名称
主 Agent（编排器）	任务拆解、调度、依赖管理、结果汇总	Sisyphus / Orchestrator
架构师	技术方案设计、数据库 Schema、接口契约	Oracle / Architect
开发者	核心代码实现（前端/后端）	Hephaestus / Developer
探索者	存量代码库分析、依赖检索	Librarian / Explore
测试/审查	代码审查、测试用例、Bug 修复	Reviewer / QA
文档	技术文档、发布说明	Document-Writer

主 Agent 收到需求后，自动拆解任务并分发给子 Agent，子 Agent 之间可通过消息传递直接通信（例如后端 Agent 改完接口后通知前端 Agent）。

1.2. 安装与配置

1. 安装 OpenCode 核心

# 方式一：官方脚本
curl -fsSL https://opencode.ai/install | bash

# 方式二：npm
npm install -g opencode-ai

2. 安装多 Agent 插件（Oh-My-OpenCode）

# 需要 Bun 环境
curl -fsSL https://bun.sh/install | bash

# 交互式安装
bunx oh-my-opencode install
# 或 npx
npx oh-my-opencode install

安装过程中会提示选择启用的模型（Claude / GPT / Gemini），并自动写入配置。

3. 配置文件（`~/.config/opencode/opencode.json`）

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "name": "openai-compatible",
    "baseURL": "https://api.xxx.com/v1",
    "apiKey": "sk-xxx"
  },
  "model": "gpt-5.2",
  "plugins": ["oh-my-opencode"]
}

4. 项目级配置（`AGENTS.md`）

在项目根目录创建 AGENTS.md，定义项目规范、技术栈和 Agent 行为边界，所有 Agent 都会读取该文件以保持上下文一致。

1.3. 使用方式

1. @符号调用特定 Agent

安装完成后，直接在对话中使用 @ 调用专业 Agent：

@oracle 请设计整体微服务架构图和数据库 Schema
@librarian 搜索项目中所有与支付相关的代码，总结现有逻辑
@frontend-ui-ux-engineer 实现一个响应式侧边栏，支持折叠和动态路由

2. 主 Agent 自动拆解（推荐）

直接描述需求，让主 Agent（Sisyphus）自动判断是否需要拆分：

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

主 Agent 会自动创建团队并分配子任务：

Alice：处理用户接口验证（范围：src/api/users/）
Bob：处理订单接口验证（范围：src/api/orders/）
Carol：补集成测试和前端错误提示（依赖 Alice、Bob 完成后启动）

3. 多模型混合调度

不同 Agent 可配置不同模型，实现成本与性能的平衡：

Agent 角色	推荐模型	原因
主编排 / 架构	GPT-5.2 / Claude Opus	逻辑强、上下文长
代码探索 / 检索	Claude Sonnet	速度快、成本低
前端 / 视觉	Gemini 3 Pro	多模态能力强
文档 / 简单任务	Gemini 3 Flash / 本地模型	极低成本

1.4. 实战示例：开发邀请码功能

以"给 SaaS 后台加一套邀请码机制"为例，完整协作流程如下：

阶段	执行者	产出
设计	主 Agent / 用户	字段定义、接口契约、验收标准
并行 1	Agent A（后端）	邀请码生成与校验逻辑
并行 2	Agent B（前端）	管理后台页面
后置	Agent C（测试）	集成测试、错误提示检查
收口	用户	Review diff、跑验证、合并

关键约束——给子 Agent 设硬边界：

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

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

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

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

1.5. 关键机制与最佳实践

1. 消息传递（Agent 间通信）

当两个任务共享规则但不值得合并时，子 Agent 可直接通信：

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

2. 依赖管理

先拆依赖，再拆 Agent：接口契约必须先定，否则前后端反复返工
后置任务放在依赖链后面：测试 Agent 等开发 Agent 完成后再启动
避免多个 Agent 同时修改同一批文件（如共享 Schema、通用工具函数）

3. 权限隔离

通过 opencode.json 中的 permissions 字段控制每个 Agent 的文件访问范围，防止越界修改。

4. 人工审查兜底

多 Agent 协作不能自动合并，最后必须人工检查：

diff 是否超出任务目录
多个 Agent 是否引入了相似但不一致的实现
前后端字段名、错误码是否对齐
lint / test / build 是否通过

1.6. 与 Claude Code Agent Teams 的对比

能力	Claude Code	OpenCode + OMO
多 Agent 协作	✅	✅
跨厂商模型混合	❌	✅（可同时调用 GPT + Claude + Gemini）
异步并行	✅	✅
消息传递	✅	✅
开源免费	❌	✅

1.7. 总结

OpenCode 实现多 Agent 协作的核心公式是：

OpenCode 核心 + Oh-My-OpenCode 插件 + 多模型配置 + 清晰的任务边界

它解决的不是"AI 会不会写代码"，而是一个人如何同时推进多块互相关联、但不必串行的任务。关键记住三点：

先拆依赖，再拆 Agent——不要看见能并行就全并行
范围写死——子 Agent 不会自动理解"这个文件最好别碰"
人工兜底——最后的审查和合并必须你自己来做

2. OpenCode 多 agent 协作示例

先重新梳理多 agent 协作概念，然后介绍内置 agent、自定义配置，最后实战编排模式。

2.1. 核心概念：两类 Agent

OpenCode 的多 agent 体系只有两种角色：

类型	说明	调用方式
Primary agent（主 agent）	我们直接对话的助手，按 Tab 键切换	人工切换
Subagent（子 agent）	被主 agent 通过 Task 工具调用的专项助手，也可以在消息里 @ 提及手动调用	自动委派或 `@名称`

内置 primary agent 有两个：

Build（默认）：所有工具全开，日常开发用。
Plan：受限的规划 agent，文件编辑和 bash 默认设为 ask，适合只做分析不改代码。

内置 subagent 有三个：

General：通用型，几乎全工具权限，可执行多步任务、并行跑多份工作。
Explore：快速只读 agent，用于找文件、搜代码、回答代码库问题，不能改文件。
Scout：只读的外部文档/依赖调研 agent，可把依赖仓库克隆到 OpenCode 托管缓存里对照源码。

2.2. 基本协作玩法

1. 会话内切换主 agent：Tab 循环切换 Build / Plan，比如先用 Plan 出方案，再切 Build 执行。

2. @ 提及子 agent：在输入框直接写：

@explore 帮我找一下认证中间件在哪些文件里被引用

3. 主 agent 自动委派：Build/Plan 会根据子 agent 的 description 自行决定何时把任务拆给 Explore/General 并行执行。多个 @general 可以在一条消息里并行派发。

4. 查看子会话：子 agent 会创建子会话，默认快捷键 Ctrl+X ↓ 进入子会话，↑ 返回父会话。

2.3. 自定义 Agent

有两种定义方式，效果等价：

方式 A：`opencode.json`

{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "code-reviewer": {
      "description": "审查代码的最佳实践和潜在问题",
      "mode": "subagent",
      "model": "anthropic/claude-sonnet-4-20250514",
      "prompt": "你是代码审查员，重点关注安全、性能和可维护性。",
      "permission": {
        "edit": "deny"
      }
    }
  }
}

方式 B：Markdown 文件

放在全局 ~/.config/opencode/agents/ 或项目级 .opencode/agents/ 下，文件名即 agent 名：

---
description: 审查代码质量与最佳实践
mode: subagent
model: anthropic/claude-sonnet-4-20250514
temperature: 0.1
permission:
  edit: deny
  bash: deny
---
你处于代码审查模式。重点关注：
- 代码质量与最佳实践
- 潜在 bug 和边界情况
- 性能影响与安全风险
给出建设性反馈，不直接修改代码。

2.4. 进阶编排：真正的"多 agent 协作"

1. 用 `permission.task` 控制调度权限

用 glob 模式精确规定某个 agent 能调用哪些子 agent——这是构建"编排者"模式的关键：

{
  "agent": {
    "orchestrator": {
      "mode": "primary",
      "permission": {
        "task": {
          "*": "deny",
          "orchestrator-*": "allow",
          "code-reviewer": "ask"
        }
      }
    }
  }
}

设为 deny 的子 agent 会从 Task 工具描述中彻底移除，模型根本不会尝试调用它。

2. 控制嵌套深度 `subagent_depth`

默认值为 1：主 agent 可以启动子 agent，但子 agent 不能再启动子 agent。设为 2 允许再嵌套一层，设为 0 禁止一切子 agent 调用：

{
  "$schema": "https://opencode.ai/config.json",
  "subagent_depth": 2
}

3. 隐藏内部 agent

hidden: true 让子 agent 不出现在 @ 补全菜单里，但仍可被其他 agent 通过 Task 工具程序化调用，适合做"纯后台 worker" 。

4. 权限细化

权限支持到命令级 glob，例如：

"permission": {
  "bash": {
    "git push": "ask",
    "git status *": "allow"
  }
}

权限键包括 read、edit、bash、task、webfetch、websearch 等，取值 allow / ask / deny 。

2.5. 实战示例：审查流水线

一个典型的 Subagent-Driven 工作流——主 agent 负责思考和决策，脏活累活全委派：

你（对话）
  └─ Build（主 agent：设计、决策、修代码）
       ├─ @explore    → 定位相关代码（只读，快）
       ├─ @scout      → 查第三方库上游实现（只读）
       ├─ @general    → 并行执行多个独立改造任务
       └─ @code-reviewer → 改完后审查 diff（edit: deny）

搭配建议：

给 explore、code-reviewer 配便宜快速的模型（如 haiku 级别）省成本，主 agent 用强模型。
审查类 agent 一律 edit: deny，从机制上防止"审查员顺手改代码"。
给不同 agent 设 color（如 "color": "accent"），UI 里一眼区分谁在说话。
想让会话默认从规划开始，设 "default_agent": "plan"（必须是 primary agent）。

2.6. 常见坑

在 opencode.json 里给 markdown 定义的 subagent 加条目时，记得显式写 "mode": "subagent"，否则部分版本会把它错误地当成 primary agent 出现在 Tab 切换列表里。
子 agent 的 description 要写清楚——主 agent 是根据它决定何时委派的。
生态里还有现成插件可以按主会话模型自动路由子 agent 模型（如 opencode-subagent-model-selector），不想手写配置可以看看。

3. OpenCode 与 LangGraph 协作

OpenCode 与 LangGraph 属于不同层级、不同定位的工具，二者是互补关系而非竞争关系。简单来说：

OpenCode 是"终端编码 Agent"（应用层工具），LangGraph 是"多 Agent 编排框架"（基础设施层）。

3.1. 生态定位对比

维度	OpenCode	LangGraph
类别	终端编码 Agent（CLI 工具）	多 Agent 编排框架
核心模式	Single loop（单 Agent 内循环）	Graph composition（图编排）
执行模型	Hybrid（混合执行）	Stateful（有状态持久化）
主要场景	终端代码编写、重构、调试	复杂工作流编排、多 Agent 协作
多 Agent 原生支持	❌ 无完整多 Agent 团队机制	✅ 核心能力
状态管理	会话级上下文	内置 checkpointing、time-travel

3.2. 核心差异

OpenCode：专注终端编码体验

OpenCode 的核心价值在于统一命令、技能、权限和会话路径，提供精美的 TUI 界面、LSP 深度集成和多模型支持。它是一个"单 Agent"产品，本身没有内置完整的多 Agent 团队机制。

LangGraph：专注工作流编排

LangGraph 将 Agent 工作流建模为有向图，通过节点（LLM 调用、工具、条件判断）和边（条件跳转、循环、分支）实现复杂的多步骤推理。它提供内置的 checkpointing，支持长运行任务在崩溃后恢复，以及 time-travel 调试。

3.3. 两者的关系：互补与组合

关系 1：不同层级的工具

两者都属于"自托管 AI 工具"的大范畴，但关注点完全不同：

OpenCode 更偏向代码和执行工具使用
LangGraph 更偏向工作流编排和状态管理

选择哪个取决于任务是否需要复杂流程图和多节点状态。

关系 2：LangGraph 编排 + OpenCode 执行（最佳实践）

这是目前业界推荐的组合模式：

用 LangGraph（或 CrewAI）做编排层，驱动多个专用 Coding Agent（如 OpenCode）并行工作，构建端到端工程自动化流水线。

例如：

LangGraph 定义整体工作流：需求分析 → 架构设计 → 并行编码（前端/后端）→ 代码审查 → 测试 → 部署
OpenCode 作为"执行节点"中的具体工具，负责实际的代码编写和文件操作
通过 MCP（Model Context Protocol）或外部 Agent 迁移机制，让 LangGraph 调用 OpenCode 完成具体编码任务

关系 3：与 Codex 的 AgentGraphStore 对比

有趣的是，Codex CLI 的 AgentGraphStore 被描述为"最接近 LangGraph 的竞品抽象"，但两者关注点不同：

LangGraph 关心"图怎么执行"（编排运行时）
AgentGraphStore 关心"图怎么持久化与查询"（拓扑存储）

Codex 把编排留给 ThreadManager，把拓扑存储独立为 trait——未来甚至可以把 LangGraph 风格的执行器接到 AgentGraphStore 上。这种设计思路也适用于 OpenCode 与 LangGraph 的关系：OpenCode 负责终端执行，LangGraph 负责上层编排。

3.4. 实际使用场景

场景	推荐方案
个人日常编码、终端交互	单独使用 OpenCode
复杂多步骤工作流（需要分支、循环、人工审批）	单独使用 LangGraph
企业级 Multi-Agent 流水线	LangGraph 编排 + OpenCode 执行
需要跨厂商模型混合的编码任务	OpenCode（原生支持多 provider）
需要审计追踪和状态恢复	LangGraph（内置 checkpointing）

3.5. 总结

OpenCode 与 LangGraph 的关系可以概括为：

不是替代品——OpenCode 不会取代 LangGraph 的编排能力，LangGraph 也不会取代 OpenCode 的终端编码体验
可以组合使用——LangGraph 作为上层编排器，OpenCode 作为下层执行器，通过 MCP 或 API 集成
生态分层——OpenCode 属于"Coding Agent Harness"层，LangGraph 属于"Multi-Agent Orchestration Framework"层

如果已经在用 OpenCode 做日常开发，但遇到需要多个 Agent 协作的复杂项目，正确的做法不是放弃 OpenCode，而是在其上叠加 LangGraph（或 CrewAI、AutoGen）作为编排层，让 OpenCode 专注于它最擅长的终端编码执行。

4. OpenCode 与 Harness

OpenCode 对 Harness Engineering（驾驭工程） 的支持程度可以概括为：原生能力扎实、生态扩展丰富、但在深度编排和状态持久化上仍有提升空间。OpenCode 本身就被业界视为一个功能完备的 Agent Harness，同时也有大量第三方项目专门为其增强 harness 能力。

4.1. Harness Engineering 的核心理念

Mitchell Hashimoto 提出的 Harness Engineering 强调：不是优化模型本身，而是设计一个让 Agent 无法越界的环境。每次 Agent 犯错，就增加一条工程约束，让它不会再犯。

这对应三层栈：

上下文工程（Context Engineering）：给 Agent 足够且精准的信息
护栏工程（Guardrail Engineering）：限制 Agent 的行为边界
编排工程（Orchestration Engineering）：多 Agent 协作与任务调度

4.2. OpenCode 原生支持的 Harness 能力

OpenCode 作为终端编码 Agent，本身提供了大量 Harness Engineering 所需的基础设施：

能力维度	OpenCode 支持情况	说明
多模型支持	✅ 12+ 提供商	Anthropic、OpenAI、Google、GitHub Copilot、Bedrock、Azure、OpenRouter、本地模型等，无厂商锁定
Skills 系统	✅ 可发现、可复用	自动发现 `SKILL.md`，支持本地和远程来源，形成可复用的能力生态
MCP 协议	✅ 完整支持	stdio / HTTP / SSE 三种传输方式，prompts 和 resources 可作为命令暴露
权限控制	✅ per-agent 规则	支持按 Agent 设置规则集（如 `build` 宽松、`plan` 只读），文件模式拒绝（如 `.env`）
插件系统	✅ 一等公民	`@opencode-ai/plugin` SDK，支持事件钩子、工具注册、Provider 钩子、OpenTUI 组件
Session 管理	🟡 部分支持	SQLite 持久化消息、工具调用、权限、待办事项和文件 diff，支持快照和回滚，但无显式 checkpoint API
Worktrees	✅ 支持	隔离的 git worktree 流程，支持并行 Agent 工作和安全的实验
LSP 集成	✅ 深度集成	自动加载语言服务器，为 LLM 提供精确的工具支持，这在编码 Agent 中很少见
多界面	✅ 终端/Web/桌面/IDE	同一后端驱动多种前端，还支持 `opencode serve` 无头模式及 SDK
跨 Harness 协作	✅ 通过 Agent Intercom	支持与 Pi、Claude Code、Codex 等跨 Harness 的本地消息传递

4.3. 第三方 Harness 增强生态

业界已出现多个专门为 OpenCode 打造的 Harness 增强项目，说明其扩展性得到认可：

1. OpenCode Harness（80+ Agents, 260+ Skills）

提供完整的 Agent 团队体系：

17 个工程工作流 Agent：规划、架构、代码审查、TDD、重构、测试、调试
17 个代码审查 Agent：按语言细分（Python、Rust、Go、Java、TS 等）
11 个构建修复 Agent：覆盖所有主流语言
26+ MCP 服务器配置：GitHub、Jira、Supabase、Vercel、Playwright 等

核心命令：

/plan          # 创建实现计划
/tdd           # 强制 TDD 工作流（80%+ 覆盖率）
/code-review   # 代码质量与安全审查
/security      # 综合安全审查
/orchestrate   # 多 Agent 编排
/learn         # 提取模式与经验

2. OpenCode Agent Team Harness（Orchestrator + 6 子代理）

采用能力自适配设计：Orchestrator 自动发现项目层提供的可选能力，有什么用什么，没有则优雅降级。子代理按模型能力分层：

assistant：主力（大范围搜索、多文件分析）
architect：架构设计、方案对比
reviewer：深度代码审查、安全审计
scout：只读搜索（用轻量模型降低成本）
worker：极简单修改（用最便宜模型）

3. AI Engineering Harness（跨工具统一配置）

支持用同一套配置同时管理 Claude Code、OpenCode、Gemini CLI、Pi 四个工具，实现跨 Harness 的上下文工程标准化。

4. OpenCode Memory（Harness 工程引导器）

提供本地 RAG 记忆层，并内置 Harness 工程自动引导器，一键创建标准的三层架构和生命周期文件。

4.4. Harness Engineering 实践中的"四护栏"

在 OpenCode 的 Harness Engineering 实践中，社区总结出了四层护栏机制，OpenCode 对其支持度如下：

护栏一：上下文工程（Context Engineering）

AGENTS.md：全局注入的系统 prompt，所有 subagent 启动时必读
分层 Spec：按 agent 类型注入规范文件（模板已建，自动化注入尚未完全落地）
Codebase Memory MCP：代码知识图谱按需检索，避免 grep 瞎猜或凭记忆编造

⚠️ 教训：过度注入上下文反而有害。有实践者建了 30 个 loop-*.md 命令文件，结果占满 context window，执行质量下降，最终全部删除后 Agent 反而更稳定。

护栏二：权限与沙箱

文件级权限：支持 edit: deny 等规则，防止 Agent 修改关键文件
⚠️ 无真正 OS 级沙箱：权限是 UX 和运行时策略层，不是操作系统隔离

护栏三：多模型路由

静态配置已成熟，自动化模型路由仍在探索中（如前端布局自动用轻量模型，安全关键代码自动升级最强模型）

护栏四：反馈循环

Learnings 机制：手动将经验写入 memory，理想状态是让 Agent 在 TDEK（Test-Driven Experience & Knowledge）循环中自动更新规范文件

4.5. 与其他 Harness 的对比定位

特性	OpenCode	Pi Coding Agent	Claude Code	Codex
定位	Batteries-included 全能型	极简可扩展（Lego 式）	单 Agent 深度体验	OpenAI 原生
资源占用	较高	极低	中等	中等
Harness 扩展性	高（插件 + Skills + MCP）	极高（TypeScript 模块）	中等（Skills + MCP）	中等（Plugins）
多模型	✅ 最广	✅ 支持	❌ Anthropic 为主	❌ OpenAI 为主
跨 Harness 协作	✅ Agent Intercom	✅ Agent Intercom	✅ Agent Intercom	✅ Agent Intercom
LSP 支持	✅ 深度	❌ 无	✅ 有	🟡 基础
Worktrees	✅ 支持	❌ 无	✅ 支持	✅ 支持

4.6. 当前局限与待改进

无显式 Checkpoint API：虽然 SQLite 持久化丰富，但缺乏 LangGraph 式的 time-travel 和状态恢复机制
无真正沙箱：权限控制是策略层，非 OS 隔离，敏感操作仍需人工兜底
多 Agent 原生支持有限：核心仍是单 Agent 产品，多 Agent 需依赖 Oh-My-OpenCode 等插件或外部编排器（如 LangGraph）
记忆系统待升级：当前主要是项目级记忆，跨项目的个人知识迁移尚未实现
复杂度较高：后端、TUI、Web、桌面、SDK、协议层叠加，比极简 CLI 更难理解和定制

4.7. 总结

OpenCode 对 Harness Engineering 的支持程度是中上水平，且生态活跃：

层级	支持度	评价
基础 Harness 能力	⭐⭐⭐⭐⭐	多模型、Skills、MCP、插件、权限、LSP、Worktrees 一应俱全
Harness 扩展生态	⭐⭐⭐⭐⭐	第三方项目丰富（80+ Agents、260+ Skills、跨 Harness 协作）
深度编排能力	⭐⭐⭐	原生多 Agent 有限，需借助 Oh-My-OpenCode 或 LangGraph
状态持久化	⭐⭐⭐⭐	SQLite 持久化扎实，但缺少 checkpoint/time-travel
安全隔离	⭐⭐⭐	策略层权限完善，但无 OS 级沙箱

适合场景：

需要多模型混合（同时用 GPT + Claude + Gemini + 本地模型）
需要深度编码集成（LSP、Worktrees、复杂文件操作）
愿意通过插件和第三方 Harness 扩展多 Agent 能力
重视开源和可审计性（MIT 协议，可 fork 和自托管）

不适合场景：

需要原生复杂工作流编排（LangGraph 更适合）
需要严格的 OS 级沙箱隔离
追求极简轻量（Pi 更合适）
需要自动化的跨项目知识迁移（尚在探索中）

乐奇 Rokid 开放社区

更多推荐

Word Embedding ：从分布式假设到神经网络语言模型

Word Embedding（词嵌入）是一种将离散的词汇符号映射到连续的低维稠密向量空间的技术。在这个向量空间中，语义相似的词在几何距离上彼此接近，从而实现了从"符号匹配"到"语义计算"的跨越。核心定义词嵌入是将单词（或多词短语）表示为固定维度的实值向量，这些向量之间的距离（例如余弦相似度）反映了单词之间的相关性，这种相关性基于单词通常出现的上下文。分布式假设（1954）↓统计共现分析（LSA/S

乐奇 Rokid 开放社区

镜游小导：运行在 Rokid AR 眼镜上的景区实景讲解智能体

项目以 RokidAIUI 开放智能体形态交付：页面用.ink描述，运行在眼镜端智能体运行时，直接调用系统能力。AGENTS.md身份镜游小导v1.0.0，景区 AR 实景讲解智能体；权限（Capabilities）microphonenetworkaudiogyroscope；技能（Skills）。

乐奇 Rokid 开放社区

AI 智能眼镜技术文档

乐奇 Rokid 开放社区

所有评论(0)

查看更多评论

Eloudy

@eloudy

已为社区贡献10条内容

OpenCode 多 agent 协作简介

Eloudy

1. OpenCode 多 Agent 简介

1.1. 核心架构：Sisyphus 模式

1.2. 安装与配置

1. 安装 OpenCode 核心

2. 安装多 Agent 插件（Oh-My-OpenCode）

3. 配置文件（~/.config/opencode/opencode.json）

4. 项目级配置（AGENTS.md）

1.3. 使用方式

1. @符号调用特定 Agent

2. 主 Agent 自动拆解（推荐）

3. 多模型混合调度

1.4. 实战示例：开发邀请码功能

1.5. 关键机制与最佳实践

1. 消息传递（Agent 间通信）

2. 依赖管理

3. 权限隔离

4. 人工审查兜底

1.6. 与 Claude Code Agent Teams 的对比

1.7. 总结

2. OpenCode 多 agent 协作示例

2.1. 核心概念：两类 Agent

2.2. 基本协作玩法

2.3. 自定义 Agent

方式 A：opencode.json

方式 B：Markdown 文件

2.4. 进阶编排：真正的"多 agent 协作"

1. 用 permission.task 控制调度权限

2. 控制嵌套深度 subagent_depth

3. 隐藏内部 agent

4. 权限细化

2.5. 实战示例：审查流水线

2.6. 常见坑

3. OpenCode 与 LangGraph 协作

3.1. 生态定位对比

3.2. 核心差异

OpenCode：专注终端编码体验

LangGraph：专注工作流编排

3.3. 两者的关系：互补与组合

关系 1：不同层级的工具

关系 2：LangGraph 编排 + OpenCode 执行（最佳实践）

关系 3：与 Codex 的 AgentGraphStore 对比

3.4. 实际使用场景

3.5. 总结

4. OpenCode 与 Harness

4.1. Harness Engineering 的核心理念

4.2. OpenCode 原生支持的 Harness 能力

4.3. 第三方 Harness 增强生态

1. OpenCode Harness（80+ Agents, 260+ Skills）

2. OpenCode Agent Team Harness（Orchestrator + 6 子代理）

3. AI Engineering Harness（跨工具统一配置）

4. OpenCode Memory（Harness 工程引导器）

4.4. Harness Engineering 实践中的"四护栏"

护栏一：上下文工程（Context Engineering）

护栏二：权限与沙箱

护栏三：多模型路由

护栏四：反馈循环

4.5. 与其他 Harness 的对比定位

4.6. 当前局限与待改进

4.7. 总结

所有评论(0)

温馨提示：您尚未绑定手机号

Eloudy

3. 配置文件（`~/.config/opencode/opencode.json`）

4. 项目级配置（`AGENTS.md`）

方式 A：`opencode.json`

1. 用 `permission.task` 控制调度权限

2. 控制嵌套深度 `subagent_depth`