Clawd 核心 Agent 分析报告
本报告重点分析记忆模块实现机制和 Agent 框架对比。
背景说明
网上介绍 clawd 安装使用的报告比较多，这里就不再赘述了。本报告在此阅读的基础上，重点介绍了两部分内容 Clawdbot 的功能、架构和部署流程。针对两个技术细节做进一步分析：
- Clawd 的记忆模块是如何实现的？ 与 Mem0 这类主流方案有什么区别？
- Clawd 的 Agent 核心（Pi Monorepo）与 Claude Code 有什么差异？ 各自适合什么场景？
第一部分：Clawd 与 Pi Monorepo 的关系
在分析具体问题之前，需要先澄清一个概念：Clawdbot 是基于 Pi Monorepo 构建的开源个人 AI 助手。
| 项目 | 定位 | 关系 |
|---|---|---|
| Pi Monorepo | 底层 Agent 运行时和工具集 | 基础架构 |
| Clawdbot | 基于 Pi 的完整个人助手产品 | 上层应用，增加了 Gateway、多 IM 集成等 |
整体架构：
┌─────────────────────────────────────────────────────────────────────────┐
│ Clawdbot 架构 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 用户交互层 │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │WhatsApp │ │Telegram │ │Discord │ │ Slack │ │ iMessage│ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ ↑ 多 IM 渠道集成 │ │
│ └────────────────────────┼────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────┼────────────────────────────────────────┐ │
│ │ Gateway 网关层 │ │
│ │ ┌──────────────────────────────────────────────────────────┐ │ │
│ │ │ WebSocket Server │ 路由引擎 │ 会话存储 │ 安全认证 │ │ │
│ │ └──────────────────────────────────────────────────────────┘ │ │
│ │ 24小时在线服务 │ │
│ └────────────────────────┼────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────┼────────────────────────────────────────┐ │
│ │ Pi Mono Agent 核心层 │ │
│ │ ┌──────────────────────────────────────────────────────────┐ │ │
│ │ │ 队列管理 │ 模型推理 │ 工具执行 │ 流式输出 │ 记忆系统 │ │ │
│ │ └──────────────────────────────────────────────────────────┘ │ │
│ │ 基于 pi-agent-core 的 Agent 运行时 │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Clawdbot 在 Pi Monorepo 基础上增加了：
- Gateway 控制平面：WebSocket 服务器、消息路由引擎，实现服务持续在线
- 多 IM 集成：打通 WhatsApp、Telegram、Discord、Slack、Signal、iMessage 等渠道
- 管控后台：本地 18789 端口的 Canvas 管控台
- 浏览器扩展：Chrome 插件支持网页操作
第二部分：记忆模块分析 —— Clawd vs Mem0
2.1 ~/clawd 工作区目录结构
Clawd 的记忆和人格系统通过 ~/clawd 工作区目录实现，核心是一组 Markdown 提示词文件：
~/clawd/
├── AGENTS.md # Agent 行为指南（入口文件）
├── SOUL.md # 人格定义（核心价值观、行为边界）
├── IDENTITY.md # 身份信息（名字、头像、风格）
├── USER.md # 用户画像（主人信息、偏好）
├── MEMORY.md # 长期记忆（精炼的重要信息）
├── TOOLS.md # 工具配置笔记（设备、SSH、语音偏好）
├── HEARTBEAT.md # 心跳任务清单（定期检查项）
├── BOOTSTRAP.md # 初始化引导（首次运行后删除）
├── memory/ # 每日记忆目录
│ └── YYYY-MM-DD.md # 每日原始日志
└── canvas/ # Canvas 管控台资源
└── index.html
各文件作用：
| 文件 | 作用 | 加载时机 |
|---|---|---|
| AGENTS.md | Agent 行为总纲，定义会话流程、安全规则、心跳机制 | 每次会话 |
| SOUL.md | 人格核心，定义价值观（真诚帮助、有观点、尊重隐私） | 每次会话 |
| IDENTITY.md | 身份元数据（名字、表情、头像路径） | 每次会话 |
| USER.md | 用户信息（姓名、称呼、时区、上下文笔记） | 每次会话 |
| MEMORY.md | 长期记忆（精炼后的重要信息，类似人类长期记忆） | 仅主会话 |
| TOOLS.md | 本地配置笔记（摄像机名、SSH 地址、TTS 语音偏好） | 按需读取 |
| HEARTBEAT.md | 心跳检查清单（定期任务，如检查邮件、日历） | 心跳轮询时 |
| BOOTSTRAP.md | 首次运行引导，完成后删除 | 仅首次 |
| memory/*.md | 每日原始日志，记录当天发生的事情 | 每次会话读取今天+昨天 |
提示词加载流程：
会话开始
│
├── 1. 读取 SOUL.md（我是谁）
├── 2. 读取 USER.md（我在帮谁）
├── 3. 读取 memory/今天.md + memory/昨天.md（最近上下文）
│
└── 如果是主会话（直接与用户对话）
└── 4. 读取 MEMORY.md（长期记忆，含隐私信息）
可复用性说明：经过测试，这套 ~/clawd 技能包可以被打包成 Claude Code 插件（ccPlugins），在 Claude Code 中直接复用，使其具备同样的记忆和人格能力。
![[Pasted image 20260128203033.png]]
![[Pasted image 20260128203058.png]]
2.2 两种架构对比
Clawd 采用"Markdown 文件 + SQLite 索引"的双层架构，Mem0 采用"LLM 驱动 + 向量数据库"的架构。两者代表了 AI 记忆系统的两种不同设计思路。
Clawd 记忆架构：
┌─────────────────────────────────────────────────────────────────┐
│ Clawdbot 记忆系统架构 │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 文件记忆层 │◄────►│ 向量索引层 │ │
│ │ (Markdown) │ │ (SQLite) │ │
│ │ │ │ │ │
│ │ ~/clawd/memory/ │ │ ~/.clawdbot/ │ │
│ │ *.md 文件 │ │ memory/*.sqlite│ │
│ └─────────────────┘ └─────────────────┘ │
│ │ │ │
│ │ 人可读/可编辑 │ 机器高效检索 │
│ │ (单一真实来源) │ (可重建的派生数据) │
│ ▼ ▼ │
│ Agent ──► file_write ──► watcher ──► 自动索引 │
│ │
└─────────────────────────────────────────────────────────────────┘
核心设计原则：
| 原则 | 说明 |
|---|---|
| 单一数据源 | Markdown 文件是唯一真实来源，SQLite 只是派生索引 |
| 可重建性 | 删除 SQLite 不会丢失记忆，系统会自动重新索引 |
| 人工可读 | 用户可直接编辑 ~/clawd/memory/*.md 文件 |
| 隐私优先 | 所有数据保存在本地，无云端依赖 |
| 异步索引 | 文件变更后 debounce 1500ms 触发自动索引 |
与 Mem0 的关键区别：
| 维度 | Mem0 | Clawd |
|---|---|---|
| 更新触发 | 显式 add() API 调用 | 文件系统变更监听 |
| 决策主体 | LLM 主动决策 (Add/Update/Delete/NOOP) | Agent 决策 + 系统被动索引 |
| 更新粒度 | 记忆条目级 | 文件级（整文件重新索引） |
| 存储格式 | 二进制向量数据库 | Markdown 纯文本 + SQLite 索引 |
| 人可读性 | 否 | 是（可直接编辑） |
2.2 更新机制差异
两种系统在处理记忆更新时的逻辑完全不同。
Mem0 时序链路
用户对话 Mem0 系统 存储层
│ │ │
│ "我爱吃橘子" │ │
├─────────────────────────►│ │
│ │ │
│ ┌─────┴─────┐ │
│ │ Extraction │ │
│ │ Phase │ │
│ │ (LLM调用) │ │
│ └─────┬─────┘ │
│ │ 提取记忆: "用户爱吃橘子" │
│ │ │
│ ┌─────┴─────┐ │
│ │ Update │ │
│ │ Phase │ │
│ │ (LLM调用) │ │
│ └─────┬─────┘ │
│ │ 决策: ADD │
│ ├──────────────────────────────►│
│ │ 存入向量数据库 │
│ │ id=mem_001 │
│ │ │
│ "噢错了，其实是橙子" │ │
├─────────────────────────►│ │
│ │ │
│ ┌─────┴─────┐ │
│ │ Extraction │ │
│ │ Phase │ │
│ └─────┬─────┘ │
│ │ 提取: "用户纠正：爱橙子非橘子" │
│ │ │
│ ┌─────┴─────┐ 检索相似记忆 │
│ │ Update │◄────────────────────────│
│ │ Phase │ 返回: mem_001 │
│ └─────┬─────┘ │
│ │ 检测到冲突，决策: DELETE+ADD │
│ ├──────────────────────────────►│
│ │ 删除 mem_001 │
│ │ 新增 "用户爱橙子" │
│ │ │
关键点：Mem0 每次对话都会触发两次 LLM 调用（提取+决策），系统自动处理冲突。
Clawd 时序链路
用户对话 Agent 文件系统 索引系统
│ │ │ │
│ "我爱吃橘子" │ │ │
├──────────────────►│ │ │
│ │ │ │
│ Agent 决定记录 │ │
│ │ │ │
│ │ file_write │ │
│ │ memory/偏好.md │ │
│ ├────────────────────►│ │
│ │ "- 我爱吃橘子" │ │
│ │ │ │
│ │ │ chokidar 监听到 │
│ │ ├───────────────────►│
│ │ │ │
│ │ │ 1500ms 后 │
│ │ │ ┌──────────────┤
│ │ │ │ 计算文件hash │
│ │ │ │ 分块+Embedding│
│ │ │ │ 写入SQLite │
│ │ │ └──────────────┤
│ │ │ │
│ "噢错了，其实是橙子" │ │ │
├──────────────────►│ │ │
│ │ │ │
│ Agent 决定更新 │ │
│ │ │ │
│ │ memory_search │ │
│ │ ("橘子") │ │
│ │◄────────────────────┼────────────────────│
│ │ 返回: memory/偏好.md │ │
│ │ │ │
│ │ memory_get │ │
│ │ (memory/偏好.md) │ │
│ │◄────────────────────│ │
│ │ 返回文件内容 │ │
│ │ │ │
│ │ file_write │ │
│ │ memory/偏好.md │ │
│ ├────────────────────►│ │
│ │ "- 我爱吃橙子" │ │
│ │ (替换原内容) │ │
│ │ │ │
│ │ │ chokidar 监听到 │
│ │ ├───────────────────►│
│ │ │ │
│ │ │ ┌──────────────┤
│ │ │ │ hash不同 │
│ │ │ │ 删除旧chunks │
│ │ │ │ 重建新索引 │
│ │ │ └──────────────┤
│ │ │ │
关键点：Clawd 的索引更新是被动的，由文件变更触发。冲突处理依赖 Agent 主动搜索和决策。
对比小结
| 环节 | Mem0 | Clawd |
|---|---|---|
| 记忆提取 | LLM 自动提取 | Agent 主动决定写什么 |
| 冲突检测 | 系统自动检索相似记忆 | Agent 需主动调用 memory_search |
| 冲突处理 | LLM 决策（DELETE/UPDATE/ADD） | Agent 决定如何修改文件 |
| 索引更新 | 实时写入向量库 | 文件变更后延迟 1500ms 重建 |
| LLM 调用 | 每次对话 2 次 | 0 次（索引层无 LLM） |
2.3 各自适用场景
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 个人隐私助手 | Clawd | 数据本地存储，可直接查看和编辑 |
| 需要审计追踪 | Clawd | Markdown 文件可 git 版本控制 |
| 快速原型开发 | Mem0 | 开箱即用，无需理解记忆管理逻辑 |
| 多租户 SaaS | Mem0 | 云端扩展，支持团队管理 |
| 成本敏感 | Clawd | 无额外 LLM 调用开销 |
| 复杂实体关系 | Mem0 | 支持 Graph Memory |
第三部分：Agent 编排架构对比 —— OpenCode vs Clawdbot
OpenCode 和 Clawdbot 都是开源的 AI Agent 框架，但在架构设计上代表了"重量级"和"轻量级"两种不同思路。本节重点分析两者的编排架构差异及其对扩展性的影响。
3.1 基本信息
| 属性 | OpenCode | Clawdbot (Pi Mono) |
|---|---|---|
| 开源协议 | MIT | MIT |
| 核心语言 | TypeScript (Bun) | TypeScript |
| GitHub Stars | 80,000+ | - |
| 月活开发者 | 150 万+ | - |
| 设计哲学 | 功能完备，模块化 | 极简主义 |
3.2 架构层次对比
OpenCode：多层模块化架构
┌─────────────────────────────────────────────────────────────────────────┐
│ OpenCode 架构 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 客户端层 │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ TUI │ │ Web App │ │ Desktop │ │ │
│ │ │ (终端) │ │(SolidJS)│ │ (Tauri) │ │ │
│ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │
│ │ └───────────┼───────────┘ │ │
│ │ ▼ │ │
│ │ HTTP API (Hono) + SSE 事件流 │ │
│ └───────────────────┼─────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────┼─────────────────────────────────────────────┐ │
│ │ ▼ 核心层 │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ Session Manager │ │ │
│ │ │ ├─ 消息管理 │ │ │
│ │ │ ├─ LLM 流处理 │ │ │
│ │ │ └─ 上下文压缩 │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ┌────────────────────┼────────────────────────────────────┐ │ │
│ │ │ ▼ │ │ │
│ │ │ Agent System │ │ │
│ │ │ ├─ build (默认开发) ├─ plan (只读分析) │ │ │
│ │ │ ├─ general (多步任务) └─ explore (快速探索) │ │ │
│ │ └──────────────────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ┌────────────────────┼────────────────────────────────────┐ │ │
│ │ │ ▼ │ │ │
│ │ │ Tool Registry │ │ │
│ │ │ bash │ edit │ read │ write │ grep │ glob │ ... │ │ │
│ │ └──────────────────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ 集成层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ MCP │ │ LSP │ │ Plugin │ │ Provider │ │ │
│ │ │ Servers │ │ Clients │ │ System │ │ Layer │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │ │
│ │ ┌────────────────┴──────────────┐ │ │
│ │ │ Anthropic │ OpenAI │ Google │ │ │
│ │ │ Azure │ Bedrock │ Local... │ │ │
│ │ └───────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Clawdbot：扁平化极简架构
┌─────────────────────────────────────────────────────────────────────────┐
│ Clawdbot 架构 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 渠道层 │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │Telegram│ │WhatsApp│ │Discord │ │ Slack │ │iMessage│ │ │
│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │
│ │ └──────────┴──────────┼──────────┴──────────┘ │ │
│ │ ▼ │ │
│ │ Gateway (WebSocket) │ │
│ └────────────────────────────┼────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────┼────────────────────────────────────┐ │
│ │ ▼ 核心层 │ │
│ │ ┌──────────────────────────────────────────────────────────┐ │ │
│ │ │ pi-agent-core │ │ │
│ │ │ │ │ │
│ │ │ 用户消息 ──► LLM 决策 ──► 工具执行 ──► 返回结果 │ │ │
│ │ │ │ │ │
│ │ └──────────────────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ┌─────────────────────────┴────────────────────────────────┐ │ │
│ │ │ 极简工具集: read │ write │ edit │ bash │ │ │
│ │ └──────────────────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ 扩展层 │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Extensions │ │ Skills │ │ Packages │ │ │
│ │ │ (能力扩展) │ │ (技能包) │ │ (功能模块) │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
3.3 Agent 编排机制对比
两者在 Agent 编排上的核心差异体现在执行模式上：Pi Mono 采用简单的 ReAct 循环，OpenCode 支持多路并行协调。
3.3.1 执行模式差异：ReAct vs 多路并行
Pi Mono（Clawdbot）的 ReAct 循环：
Pi Mono 采用经典的 ReAct（Reasoning + Acting）模式，是个相对简单的单线程循环：
┌─────────────────────────────────────────────────────────────────┐
│ Pi Mono ReAct 循环 │
│ │
│ 用户输入 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Agent Loop │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Reason │───►│ Act │───►│ Observe │──┐ │ │
│ │ │ (LLM推理) │ │ (工具执行) │ │ (获取结果) │ │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │ │
│ │ ▲ │ │ │
│ │ └────────────────────────────────────────┘ │ │
│ │ │ │
│ │ 循环直到 stopReason === 'stop' │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 返回结果 │
│ │
└─────────────────────────────────────────────────────────────────┘
对应代码流程（来自 pi-agent-core）：
用户故事 2: 工具调用流程
LLM 返回 tool_call
↓
Agent 解析 → AgentTool.execute()
├── 验证参数 (TypeBox + AJV)
├── 执行工具 (read/write/edit/bash)
└── 返回 ToolResult
↓
toolResultMessage 添加到 context
↓
继续 LLM 调用 (如果 stopReason === 'toolUse')
↓
循环直到 stopReason === 'stop'
OpenCode 的多路并行协调：
OpenCode 支持多 Agent 协作，Primary Agent 可以派发任务给 Subagent 并行执行：
┌─────────────────────────────────────────────────────────────────┐
│ OpenCode 多路并行协调 │
│ │
│ 用户输入 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Primary Agent (build/plan) │ │
│ │ │ │
│ │ 任务分析 ──► 复杂任务检测 │ │
│ │ │ │ │
│ │ ┌───────────┼───────────┐ │ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │Subagent│ │Subagent│ │Subagent│ ← 并行执行 │ │
│ │ │general │ │explore │ │explore │ │ │
│ │ │(多步任务)│ │(探索A) │ │(探索B) │ │ │
│ │ └───┬────┘ └───┬────┘ └───┬────┘ │ │
│ │ │ │ │ │ │
│ │ └───────────┼───────────┘ │ │
│ │ ▼ │ │
│ │ 结果汇总 ──► 继续执行或返回 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
对比总结：
| 维度 | Pi Mono (ReAct) | OpenCode (多路并行) |
|---|---|---|
| 执行模式 | 单线程顺序循环 | 多 Agent 并行协调 |
| 任务分解 | 无（依赖 LLM 自行规划） | Primary → Subagent 派发 |
| 上下文隔离 | 单一上下文 | 每个 Subagent 独立上下文 |
| 适合场景 | 简单线性任务 | 复杂多步任务、需要探索的任务 |
| 复杂度 | 低（易于理解和调试） | 高（需要协调多个 Agent） |
| 扩展方式 | Extension/Skill/Package | 自定义 Agent + Subagent |
3.3.2 Agent 类型与调度
| 维度 | OpenCode | Clawdbot |
|---|---|---|
| Agent 类型 | 4 种内置 Agent（build/plan/general/explore） | 单一 Agent |
| 子 Agent 调度 | 支持（general/explore 作为 subagent） | 不支持 |
| Agent 切换 | 运行时可切换模式 | 无 |
| 自定义 Agent | 支持（.opencode/agents/*.md） | 通过 Skills 实现 |
OpenCode 的 Agent 调度流程：
用户请求
│
▼
┌─────────────────────────────────────────────────────────┐
│ Primary Agent (build/plan) │
│ │
│ 判断任务复杂度 │
│ │ │
│ ├── 简单任务 ──► 直接执行 │
│ │ │
│ └── 复杂任务 ──► 派发给 Subagent │
│ │ │
│ ├── general (多步骤推理) │
│ │ └── 独立上下文 │
│ │ └── 返回结果给 Primary │
│ │ │
│ └── explore (快速探索) │
│ └── 只读操作 │
│ └── 返回探索结果 │
│ │
└─────────────────────────────────────────────────────────┘
Clawdbot 的执行流程：
用户请求
│
▼
┌─────────────────────────────────────────────────────────┐
│ pi-agent-core │
│ │
│ 消息 ──► LLM 推理 ──► 工具调用 ──► 返回 │
│ │ │
│ └── 无子 Agent 概念 │
│ └── 所有任务由同一 Agent 处理 │
│ └── 通过 Skills 扩展能力 │
│ │
└─────────────────────────────────────────────────────────┘
3.3.2 权限与审批机制
| 机制 | OpenCode | Clawdbot |
|---|---|---|
| 权限模式 | ask / allow / deny 三级 | YOLO 模式（无确认） |
| 权限持久化 | 支持（once/always） | 无 |
| 审批流程 | 弹出确认 → 用户响应 → 继续执行 | 直接执行 |
| 权限规则 | Agent 级别可配置 | 无 |
OpenCode 权限流程：
LLM 返回 tool-call
│
▼
权限规则匹配
│
├── allow ──► 直接执行
│
├── deny ──► 拒绝执行
│
└── ask ──► 弹出确认
│
├── once ──► 本次允许
├── always ──► 永久允许
└── reject ──► 拒绝
3.3.3 工具系统对比
| 维度 | OpenCode | Clawdbot |
|---|---|---|
| 内置工具数 | 10+ (bash/edit/read/write/grep/glob...) | 4 (read/write/edit/bash) |
| MCP 协议 | 支持 | 不支持 |
| LSP 集成 | 支持 | 不支持 |
| 自定义工具 | .opencode/tool/*.ts | Skills 目录 |
| 工具注册 | Tool Registry 集中管理 | Agent 运行时加载 |
3.4 扩展性对比
两种架构对后续扩展的影响：
| 扩展场景 | OpenCode | Clawdbot |
|---|---|---|
| 新增 AI 提供商 | Provider Layer 添加 loader | pi-ai 配置 |
| 新增工具 | Tool Registry 注册 | Skills 目录添加 |
| 新增客户端 | 对接 HTTP API 即可 | 实现 Channel + outbound adapter |
| 新增 Agent 模式 | .opencode/agents/*.md | 不支持 |
| IDE 集成 | LSP 原生支持 | 无 |
| 外部服务集成 | MCP 协议 | 需自行实现 |
扩展性小结：
-
OpenCode 采用模块化设计，各层职责清晰，扩展时只需在对应层添加实现，对其他层无影响。但架构复杂度较高，上手成本大。
-
Clawdbot 采用扁平化设计，扩展主要通过 Skills/Extensions/Packages 三层机制实现。架构简单，但缺少 MCP、LSP 等标准协议支持，与外部生态的集成需要更多自定义工作。
3.5 基准测试数据
根据 Artificial Analysis 独立第三方评测（Terminal-Bench 2.0）：
| 排名 | Agent | 模型 | 准确率 | 备注 |
|---|---|---|---|---|
| 4 | Droid | Claude Opus 4.5 | 63.1% | Factory.ai 出品 |
| 11 | Letta Code | Claude Opus 4.5 | 59.1% | - |
| 19 | Goose | Claude Opus 4.5 | 54.3% | Block 出品 |
| 22 | Claude Code | Claude Opus 4.5 | 52.1% | Anthropic 官方 |
| 25 | OpenCode | Claude Opus 4.5 | 51.7% | SST 出品 |
注：Pi Mono / Clawdbot 目前未在 Terminal-Bench 2.0 官方排行榜上列出独立条目。
从测试数据看：
- OpenCode 与 Claude Code 处于同一水平（51.7% vs 52.1%）
- 相同模型下，Agent 编排框架对最终效果影响显著（Droid 63.1% vs OpenCode 51.7%）
- 更复杂的架构不一定带来更好的效果，编排策略的优化可能比架构复杂度更重要
3.6 各自优势总结
OpenCode 的优势：
| 维度 | 说明 |
|---|---|
| 多路并行协调 | 支持多 Subagent 并行执行，适合复杂任务 |
| 多客户端支持 | TUI / Web / Desktop 统一 API |
| Agent 调度 | 多种 Agent 模式（build/plan/general/explore） |
| 标准协议 | MCP + LSP 原生支持 |
| 权限系统 | 细粒度权限控制（ask/allow/deny） |
Clawdbot 的优势：
| 维度 | 说明 |
|---|---|
| ReAct 简洁循环 | 单线程顺序执行，易于理解和调试 |
| 多 IM 集成 | 原生支持 Telegram/WhatsApp/Discord 等 |
| 主动性 | 心跳机制，可监测事件并主动通知用户 |
| 启动速度 | 极快（极简架构） |
| 浏览器操作 | 支持 Chrome 扩展控制网页 |
第四部分：选型建议
4.1 场景对应
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 复杂多步任务 | OpenCode | 多 Agent 并行协调，任务分解能力强 |
| 简单线性任务 | Clawdbot | ReAct 循环简单高效 |
| 终端编码助手 | OpenCode | LSP 集成、权限控制 |
| 多 IM 个人助手 | Clawdbot | 原生 IM 集成、24 小时在线 |
| 需要浏览器操作 | Clawdbot | Chrome 扩展支持 |
| IDE 深度集成 | OpenCode | LSP + MCP 协议支持 |
4.2 决策流程
主要使用场景是什么？
├── 终端编码 → 是否需要多 Agent 协作？
│ ├── 是 → OpenCode
│ └── 否 → 偏好哪种交互方式？
│ ├── 终端 → OpenCode / Pi Mono CLI
│ └── 聊天软件 → Clawdbot
│
├── 个人助手 → 是否需要多 IM 渠道？
│ ├── 是 → Clawdbot
│ └── 否 → 是否需要浏览器操作？
│ ├── 是 → Clawdbot
│ └── 否 → 两者皆可
│
└── 企业开发 → 是否需要权限审批？
├── 是 → OpenCode
└── 否 → 根据团队偏好选择
结论
两类方案面向不同场景，不是替代关系，而是互补关系：
| 方案 | 定位 | 执行模式 | 适用场景 |
|---|---|---|---|
| Clawdbot | 轻量级个人助手 | ReAct 单线程循环 | 简单线性任务、多 IM 接入、浏览器操作 |
| OpenCode | 重量级编码工具 | 多路并行协调 | 复杂多步任务、终端编码、IDE 集成 |
关于记忆系统：Clawd 的 Markdown 文件方案在个人助手场景具有优势（透明、可编辑、无云端依赖），Mem0 的 LLM 驱动方案在需要智能去重和多租户场景更适合。
关于 Agent 编排：
- Pi Mono（Clawdbot） 采用简单的 ReAct 循环（Reason → Act → Observe），单线程顺序执行，架构简单易调试，适合简单线性任务
- OpenCode 采用多路并行协调，支持 Primary Agent 派发任务给多个 Subagent 并行执行，适合复杂多步任务
从 Benchmark 数据看，架构复杂度与效果并非正相关，编排策略的优化可能比架构复杂度更重要。选择时应根据实际任务复杂度和使用场景决定。
报告生成时间：2026-01-28 数据来源：Artificial Analysis、Terminal-Bench、各框架官方文档
