我扒了 Claude Code 的源码，给 opencode 搓了个平替——结果 token 省了 90%

Posted on | In |
Words count in article: 11k | Reading time ≈ 11 mins.

Claude Code 配 DeepSeek V4 一直用得挺好，最近第三方模型动不动断流，也不知道是不是 A/ 又在下毒。找了 opencode 当替代，引擎能力够强，但内置 agent 太基础了。索性扒了源码自己搓了一套配置出来。

万恶之源：Claude Code又断流了

我一直以来的工作流是 Claude Code + DeepSeek V4。通过 CC-Switch 把 Haiku 槽位映射到 deepseek-v4-flash，Opus/Connect 槽位映射到 deepseek-v4-pro。这套组合拳效果一直很好——v4-pro 做规划和复杂推理，v4-flash 做快速执行，成本比直接用 Anthropic 官方模型低一个数量级，体验却不差。

但最近 Claude Code 对第三方模型的支持越来越差。对话到一半经常莫名其妙断掉，回复突然截断，像是被什么 invisible token limit 卡住了。

我不确定是 A/ 又在”下毒”（暗中限制非官方模型），还是 CC 本身的兼容性出了问题。但不管原因是什么，这都不是长久之计，我需要一个Plan B。

尝试opencode：差点意思

opencode 是目前最活跃的开源 AI 编程助手之一，架构清晰，插件体系完善，还支持后台子代理。但它的内置 agent 只有两个：

  • build —— 全能型，什么都能干，什么权限都有
  • plan —— 只读分析，不能改文件

这满足不了我。我要的不是一个AI包揽一切，而是claude-code那种自主规划 + 委派执行的体验：

  • 一个只动脑不动手的编排器，负责理解需求、拆分任务、调度资源
  • 一群专业化的执行者，每个只干一类活，权限最小化
  • 对抗性验证——改完代码后不是自我确认”看起来没问题”，而是真的去跑测试、写探针、试图 break 它

opencode内置的build agent做不到这种分离。它是一个全能但有权限的胖代理——上下文里塞满了文件内容和工具输出，越干越慢，越干越贵。

扒源码

既然opencode本身不支持，那就自己搓。我做了两件事：

第一，读opencode的源码。把它的运行时机制翻了个底朝天——核心循环、流式工具执行、子代理调度、权限系统、上下文压缩。结论是opencode的引擎能力其实很强，它已经有流式工具并行执行、实验性后台子代理、动态权限评估、多层级联压缩。缺的不是能力，是配置。

**第二，找claude-code的代码做参考。**claude-code的源码通过npm source map泄露过一份（怎么找的别问）。我重点研究了三块：

  • Coordinator Mode——claude-code的编排器模式，4 阶段工作流（Research → Synthesis → Implementation → Verification），prompt撰写指南，continue-vs-spawn决策表
  • Verification Agent——对抗性验证子代理的完整 prompt，包含反合理化模式（”reading code is not verification, run it”）、按改动类型的验证策略、good/bad输出示例
  • /simplify 技能——三分支并行代码审查（复用/质量/效率），维度定义非常具体

这些是工业级的prompt工程，不是随便写的。我把其中最核心的设计理念提取出来，针对opencode的运行时做了适配，最终产出了一套7个agent定义文件——就是 opencode-solo。

搓出Solo

核心思路：让主Agent只负责思考和决策（不动手），六个子代理负责干活（不深度思考）。

Solo 是一个只读的编排器——零文件 / Shell 访问权限。它只能调度子代理干活，或者向用户提问。所有实际操作都通过专业化子代理完成：

graph TB
    Solo["Solo — 编排器
专家模型"]
    Solo -->|"阶段 1"| Explore["explore
快速模型 — 只读"]
    Solo -->|"阶段 3"| Editor["editor
快速模型 — 读写"]
    Solo -->|"阶段 4"| Verify["verify
专家模型 — 对抗性"]
    Solo -.->|"按需"| Reviewer["reviewer
专家模型 — 审查"]
    Solo -.->|"按需"| Observer["observer
视觉模型 — 图像"]
    Solo -.->|"兜底"| General["general
可配置"]

上下文隔离 = Token 省钱

传统单代理模式下，所有东西堆积在一个上下文里：

graph TB
    subgraph Traditional ["传统 — 单代理"]
        T1["上下文每轮增长
文件读取 + 工具输出堆积"]
        T1 --> T2["每次调用处理 100K+ token"]
    end
    subgraph SoloArch ["Solo — 隔离上下文"]
        S1["Solo: ~5-10K token
仅摘要 + 决策"]
        S1 --> S2["每个子代理: 全新会话
大量读取被隔离"]
        S2 --> S3["专家模型上下文
缩小 10-20 倍"]
    end

Solo只看到子代理返回的简洁文本摘要，从不接触原始文件内容或冗长的工具输出。一个100Ktoken 的任务，Solo的编排器可能只消耗5-10K token的上下文（我脑测的，一切以实际数据为准）。

别迷信模型能力——规划执行分离才是王道

这里要安利一下DeepSeek V4的组合用法。

很多人觉得”要用就用最强的”，一个Opus/GPT搞所有事。但这其实是最浪费的方案：

做法 问题
全用专家模型 读个文件也要花Opus 级别的token，1M上下文每次调用都重新处理，成本爆炸
全用快速模型 规划能力不足，任务拆解质量差，容易跑偏

正确的做法是 分层：

层级 代理 用什么模型 为什么
专家 Solo, verify, reviewer deepseek-v4-pro 规划、对抗性分析、质量判断需要深度推理
快速 explore, editor deepseek-v4-flash 文件搜索、代码编辑是机械任务，不需要强推理
专用 observer 视觉模型 图像分析需要多模态能力

因为 Solo 的上下文里只有子代理返回的摘要和决策，用v4-pro做编排的成本极低。而写代码这种机械任务交给v4-flash，又快又便宜（flash 的吐词速度更快）。

规划执行分离 + 专家模型规划 + 快速模型执行 = 比全程用强模型更好的体验，同时成本大幅降低。

这不只是我的个人经验。我让AI找了一些论文来论证我的观点这，一架构有活跃的学术研究支撑：

  1. Cai, T., Wang, X., Ma, T., Chen, X., & Zhou, D. (2023). Large Language Models as Tool Makers. arXiv preprint arXiv:2305.17126. Google DeepMind.
  2. Chen, L., Zaharia, M., & Zou, J. (2023). FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. arXiv preprint arXiv:2305.05176. Stanford University.
  3. Ong, I., Almahairi, A., Wu, V., Chiang, W.-L., Wu, T., Gonzalez, J. E., Kadous, M. W., & Stoica, I. (2024). RouteLLM: Learning to Route LLMs with Preference Data. arXiv preprint arXiv:2406.18665. UC Berkeley.
  4. Hong, S., Zhuge, M., Chen, J., Zheng, X., Cheng, Y., Zhang, C., et al. (2024). MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. In ICLR 2024.
  5. Qian, C., Liu, W., Liu, H., Chen, N., Dang, Y., et al. (2024). ChatDev: Communicative Agents for Software Development. In ACL 2024.

Solo的工作流程

Solo 收到请求后，先调度 explore 搜索代码库、读取项目约定（阶段 1）。拿到发现后 Solo 自己综合分析，必要时向用户确认方案（阶段 2）。确认后调度 editor 执行修改（阶段 3），再调度 verify 做对抗性测试——跑真实命令、写探针、猎杀边界情况（阶段 4）。如果验证失败，Solo 让 editor 修复后重新验证，最多两轮，通过后才向用户汇报。reviewer 和 observer 随时按需调度，长任务还能后台并行。

flowchart TD
    Req["用户请求"] --> P1["explore — 搜索代码库
读取约定 + 架构"]
    P1 -->|"findings"| P2{"Solo 综合分析
+ 确认方案"}
    P2 -->|"dispatch"| P3["editor — 执行修改"]
    P3 -->|"changes"| P4{"verify — 对抗性测试
跑测试 + 写探针 + 猎边界"}
    P4 -->|"PASS"| Done["向用户汇报"]
    P4 -->|"FAIL → editor 修复
max 2 轮"| P3
    P2 -.->|"按需"| Rev["reviewer — 代码审查"]
    Rev -.-> Done

开箱即用

安装opencode后，三步搞定：

1
2
3
4
5
6
7
8
9
# 1. 复制 agent 文件
git clone https://github.com/Dqz00116/opencode-solo.git
cp opencode-solo/agent/*.md ~/.config/opencode/agent/

# 2. 配置模型（改成你自己的 provider）
cp opencode-solo/opencode.jsonc.example ~/.config/opencode/opencode.jsonc

# 3. 启用后台子代理（推荐）
export OPENCODE_EXPERIMENTAL_BACKGROUND_SUBAGENTS=true

在 opencode.jsonc 里填你自己的 provider，下面是我自己的配置：

1
2
3
4
5
6
7
8
9
10
{
  "agent": {
    "verify":    { "model": "deepseek/deepseek-v4-pro", "variant": "max" },
    "explore":   { "model": "deepseek/deepseek-v4-flash", "variant": "medium" },
    "editor":    { "model": "deepseek/deepseek-v4-flash", "variant": "medium" },
    "general":   { "model": "deepseek/deepseek-v4-pro", "variant": "max" },
    "reviewer":  { "model": "deepseek/deepseek-v4-pro", "variant": "max" },
    "observer":  { "model": "kimi-for-coding/k2p5" }
  }
}

然后启动opencode，选 solo agent，完事。

总结

从Claude Code断流到扒源码到搓出opencode-solo，整个过程大概两天。核心收获是：

  1. opencode的引擎能力很强——流式工具执行、后台子代理、动态权限、多层级联压缩都有，缺的是好配置
  2. claude-code的prompt工程是工业级的——反合理化模式、对抗性验证策略、good/bad 示例，值得学习
  3. 规划执行分离+模型分层是经过学术验证的架构——不是拍脑袋
  4. DeepSeek V4 pro + flash组合很能打——别迷信模型能力，用对架构比用对模型更重要

项目地址：github.com/Dqz00116/opencode-solo

MIT 协议，开箱即用。如果觉得有用，给个 Star ⭐~