AI Agent 是什么？OpenCode 的多 Agent 系统解析

本文通过 OpenCode/Oh My OpenCode 的真实案例，解释 AI Agent 的工作原理和多 Agent 协作机制。

一、先说人话：什么是 AI Agent？

传统 AI vs AI Agent

传统 AI（比如 ChatGPT）： - 你问："帮我分析这个项目的代码质量" - AI 说："请把代码发给我" - 你复制粘贴代码 - AI 给你分析结果

AI Agent： - 你说："帮我分析这个项目的代码质量" - Agent 自己去： 1. 读取项目文件 2. 运行代码检查工具 3. 查看测试覆盖率 4. 生成报告 - 直接给你结果

核心区别：传统 AI 是"客服"，你问它答。Agent 是"助理"，你说需求它自己搞定。

Agent 的三个关键能力

1. 会用工具：能读文件、跑命令、搜网络、调 API
2. 有记忆：记得之前做过什么，不会重复劳动
3. 会规划：知道把大任务拆成小步骤，一步步完成

二、为什么需要多个 Agent？

单 Agent 的问题：上下文竞争

想象你让一个人同时做： - 架构设计（需要宏观思考） - 写代码（需要关注细节） - 调试 bug（需要追踪状态） - 写文档（需要清晰表达）

这个人会： - 认知负担过重：规划和执行细节在同一个脑子里竞争注意力 - 容易搞混：修 Bug A 时，又在修 Bug B 的过程中重新引入 Bug A - 失忆：做了几轮调试后，忘了最初的规划目标

这不是能力问题，是信息架构问题——把不该混在一起的东西混在了一起。

多 Agent 的核心价值：信息域隔离

多 Agent 的杠杆来自信息域隔离，而不是模仿公司组织架构。

关键洞察（来自公理 T03）： - 隔离的目的不是为了分工，而是为了让每个 Agent 在干净的信息环境中做出更好的决策 - Planner（规划者）专注全局决策，不被执行细节淹没 - Executor（执行者）专注底层实现，不被规划讨论分散注意力

类比： - 单 Agent = 一个人既当老板又当员工，脑子里同时想战略和细节 - 多 Agent = 老板专注战略，员工专注执行，通过共享文档协调

三、OpenCode 的 Agent 团队

团队结构

OpenCode 有一个"项目经理"（Sisyphus - 西西弗斯），管理 11 个"专家"。

项目经理：Sisyphus（西西弗斯）

为什么叫这个名字：希腊神话中，西西弗斯每天推石头上山，石头滚下来，第二天继续推。寓意 AI 每天处理重复任务，永不停歇。

核心职责： - 接收你的需求，理解意图 - 决策：判断需要哪些专家 Agent - 分配任务给专家 Agent - 汇总结果，验证质量

决策逻辑：Sisyphus（西西弗斯）怎么知道派谁？

用户请求
    ↓
分析任务类型
    ↓
┌─────────────────────────────────────┐
│ 需要搜索代码？                       │
│   → Explore（探索者）                │
│                                     │
│ 需要查外部资料？                     │
│   → Librarian（图书管理员）          │
│                                     │
│ 需要架构建议？                       │
│   → Oracle（神谕者）                 │
│                                     │
│ 需要写代码？                         │
│   → 根据复杂度选 Category            │
└─────────────────────────────────────┘
    ↓
评估是否可以并行
    ↓
派出 Agent（可能同时派多个）
    ↓
等待结果 → 汇总 → 验证

实际案例：你说"修复登录 bug"

Sisyphus（西西弗斯）的思考过程： 1. 这是修复任务，不是新功能 2. 涉及认证，可能跨多个文件 3. 需要先理解现有代码 → 派 Explore（探索者） 4. 可能需要查常见问题 → 派 Librarian（图书管理员） 5. 两个任务独立，可以并行 6. 等结果回来后，决定修复方案 7. 修复是简单改配置 → 用 quick category

11 个专家 Agent

根据 Oh My OpenCode 官方文档，分为 4 类：

1. 沟通协调类

• Metis（墨提斯 - 前置分析师）
• 职责：在任务开始前，识别隐藏的坑
• 什么时候用：需求模糊、可能有多种理解时
• 推荐模型：Claude Opus 4.6（需要深度推理）

• 例子：你说"添加用户认证"，Metis 会问：

  • 需要数据库迁移吗？
  • 用 JWT 还是 Session？
  • 现有代码有认证模式吗？

• Momus（摩摩斯 - 质量审查员）

• 职责：检查工作计划是否靠谱
• 什么时候用：复杂任务，计划做好后让它审查
• 推荐模型：Claude Opus 4.6（需要批判性思维）
• 例子：Sisyphus 做了个 5 步计划，Momus 检查：
  • 步骤是否完整？
  • 有没有遗漏的依赖？
  • 验证标准是否明确？

2. 探索调研类

• Explore（探索者 - 代码库搜索专家）
• 职责：在你的项目里找文件、找代码模式
• 什么时候用：不熟悉代码库，需要定位相关文件
• 推荐模型：MiniMax-M2.1（轻量快速，使用频繁）
• 例子：找所有认证相关的代码

• 不能做：不能搜外部资料（只搜本地项目）

• Librarian（图书管理员 - 外部资料检索专家）

• 职责：上网搜文档、找 GitHub 示例、查最佳实践
• 什么时候用：需要外部知识（官方文档、开源案例）
• 推荐模型：MiniMax-M2.5（中等模型，平衡性能和成本）
• 例子：查 JWT 认证的安全最佳实践
• 不能做：不搜本地代码（只搜外部资料）

3. 顾问类

• Oracle（神谕者 - 架构顾问）
• 职责：给建议，但不改代码（只读）
• 什么时候用：需要架构建议、调试复杂问题、连续失败 3 次
• 推荐模型：Claude Opus 4.6（最强推理能力）
• 例子：设计分布式锁方案、分析性能瓶颈
• 特点：成本高但质量好，只在关键时刻用

4. 执行类（按任务类型分）

这些不是具体的 Agent 名字，而是根据任务类型自动选择的执行模式：

关键设计：同一个任务框架，根据类型自动切换最合适的模型。

为什么这么配置？

• Oracle（神谕者）用最强模型：架构建议需要最强推理，成本高但只在关键时刻用
• Librarian（图书管理员）用中等模型：搜索外部资料需要理解意图，使用频繁
• Explore（探索者）用轻量模型：搜索本地代码只需模式匹配，使用非常频繁
• Ultrabrain（超级大脑）用最强模型：复杂逻辑需要深度推理，任务质量要求高
• Quick（快手）用轻量模型：简单修改追求速度，成本低

设计原则：根据任务难度和频率，选择性价比最优的模型。

四、真实案例：Agent 怎么协作？

案例 1：修复登录 bug

你的需求："登录功能有 bug，修一下"

工作流程：

第 1 步：并行派出探索 Agent
┌─────────────────────────────────────────────────┐
│ Sisyphus（西西弗斯）同时派出两个 Agent          │
│                                                 │
│ ┌─────────────────┐    ┌──────────────────┐   │
│ │ Explore（探索者）│    │ Librarian        │   │
│ │ 搜索本地代码     │    │ （图书管理员）    │   │
│ │                 │    │ 搜索外部资料      │   │
│ └─────────────────┘    └──────────────────┘   │
│         ↓                      ↓               │
│   找认证相关代码          查 JWT 常见问题       │
└─────────────────────────────────────────────────┘

第 2 步：等结果回来
┌─────────────────────────────────────────────────┐
│ Explore（探索者）报告：                          │
│   找到 login.ts、auth.ts、token.ts             │
│                                                 │
│ Librarian（图书管理员）报告：                    │
│   常见问题是 token 过期时间配置错误              │
└─────────────────────────────────────────────────┘

第 3 步：派执行 Agent 修复
┌─────────────────────────────────────────────────┐
│ Sisyphus（西西弗斯）决定：                       │
│   这是简单配置修改                               │
│   → 派 Quick（快手）执行                        │
│   → 在 token.ts 中修复过期时间                  │
└─────────────────────────────────────────────────┘

第 4 步：验证
┌─────────────────────────────────────────────────┐
│ - 运行代码检查工具                               │
│ - 确认没有新错误                                 │
│ - 报告完成                                       │
└─────────────────────────────────────────────────┘

关键点：Explore（探索者）和 Librarian（图书管理员）是真正同时运行的，不是一个接一个。

案例 2：写一篇技术调研报告

你的需求："调研 React Server Components 的最佳实践"

Sisyphus（西西弗斯）的策略：

派出 3 个 Librarian（图书管理员），每个负责不同角度，但有 30-50% 重叠（用来交叉验证）：

并行调研（3 个 Librarian 同时跑）
┌─────────────────────────────────────────────────┐
│ Agent 1：官方文档 + 社区讨论                     │
│ Agent 2：社区讨论 + 生产案例  ← 重叠：社区讨论   │
│ Agent 3：生产案例 + 对比分析  ← 重叠：生产案例   │
└─────────────────────────────────────────────────┘
         ↓
交叉验证重叠区域
         ↓
┌─────────────────────────────────────────────────┐
│ 如果 Agent 2 和 Agent 3 对"生产案例"的信息一致  │
│   → 可信度高                                     │
│                                                 │
│ 如果不一致                                       │
│   → Sisyphus（西西弗斯）进一步核实               │
└─────────────────────────────────────────────────┘
         ↓
汇总生成综合报告

为什么要重叠？

• Agent 2 和 Agent 3 都会看"生产案例"
• 如果他们找到的信息一致 → 可信度高
• 如果不一致 → Sisyphus（西西弗斯）会进一步核实

结果：3 个 Agent 同时跑，比一个 Agent 串行快 3 倍，而且信息更全面。

五、关键设计机制

1. 任务路由：Category 系统

Sisyphus（西西弗斯）根据任务类型自动选择最合适的模型：

任务类型判断
    ↓
┌─────────────────────────────────────────┐
│ 前端、UI、样式？                         │
│   → visual-engineering（视觉工程师）     │
│   → 用 MiniMax-M2.5（视觉理解强）        │
│                                         │
│ 复杂逻辑、架构设计？                     │
│   → ultrabrain（超级大脑）               │
│   → 用 Claude Opus 4.6（推理最强）       │
│                                         │
│ 简单修改、typo？                         │
│   → quick（快手）                        │
│   → 用 MiniMax-M2.1（快速便宜）          │
└─────────────────────────────────────────┘

好处：同一套框架，根据任务自动切换最合适的模型。

2. Session 复用：避免重复工作

如果 Agent 第一次没做好，可以继续对话，不用从头开始：

第一次尝试
    ↓
Agent 执行任务
    ↓
返回 session_id（如 "ses_abc123"）
    ↓
失败了？
    ↓
继续同一个 session
    ↓
Agent 记得：
  - 之前读过哪些文件
  - 尝试过哪些方案
  - 遇到过哪些问题
    ↓
节省 70% 的重复工作

价值：Agent 保留完整上下文，不需要重新探索。

3. 委派 Prompt 的 6 要素

Sisyphus（西西弗斯）派任务时，必须说清楚 6 件事：

1. TASK：具体要做什么
2. EXPECTED OUTCOME：什么算成功
3. REQUIRED TOOLS：能用哪些工具
4. MUST DO：必须做的事
5. MUST NOT DO：禁止做的事
6. CONTEXT：相关文件、现有模式、约束

为什么这么严格？（来自公理 A08）

清晰的提示质量是 AI 能否正确理解意图的决定性因素。模糊的提示会让 Agent 在巨大的搜索空间中猜测你的意图，失败概率很高。

4. 失败恢复：3 次规则

如果 Agent 连续失败 3 次：

失败 3 次
    ↓
立即停止所有编辑
    ↓
回滚到最后能工作的版本
    ↓
咨询 Oracle（神谕者 - 架构顾问）
    ↓
Oracle 也搞不定？
    ↓
问用户

为什么：避免 Agent 瞎试，浪费时间和钱。

六、与其他框架的对比

OpenCode vs 传统框架

核心差异（来自公理 T03）：

OpenCode 的多 Agent 价值来自信息域隔离： - 传统框架 = 一个全能选手，规划和执行在同一个上下文里竞争 - OpenCode = 专业团队，每个 Agent 在干净的信息环境中做决策

类比： - 传统框架 = 一个全能选手 - OpenCode = 一个专业团队

简单任务，全能选手可能更快（没有协调成本）。复杂任务，专业团队明显更强。

成本与性能

根据社区数据： - 请求数：Oh My OpenCode 是普通版的 3 倍（96 vs 27） - 时间：多 10 分钟（55 vs 45 分钟） - 成功率：略低 4%（69% vs 73%）

但是： - Oh My OpenCode 处理的任务更复杂 - 包含更多验证和质量检查 - 提供更详细的中间结果

选择建议： - 简单任务（改个 typo）→ 用普通版 - 复杂任务（多模块重构）→ 用 Oh My OpenCode - 成本敏感 → 控制并行度

七、总结

核心要点

AI Agent 是什么： - 不只是回答问题，能自己完成任务 - 会用工具、有记忆、会规划

OpenCode 的创新： - 多 Agent 分工，信息域隔离 - 根据任务类型自动选模型 - 真正的并行执行 - Session 复用避免重复工作

关键原则： - 能委派就不自己做 - 能并行就不串行 - 每个操作都有验证 - 3 次失败立即停止

适用场景

OpenCode 擅长： - 复杂多模块任务 - 需要深度调研 - 陌生代码库探索

不擅长： - 简单单文件修改 - 高度串行任务 - 极致成本控制

参考资料

• Oh My OpenCode GitHub
• 官方文档
• Agent 架构深度分析 - Rost Glukhov, 2026-03

写在最后：本文基于 OpenCode/Oh My OpenCode 的实际使用经验撰写，结合公理系统（T03 上下文隔离、A08 提示质量、M05 简洁性）的指导。系统仍在快速迭代，细节可能随版本更新而变化。