OpenCode(anomalyco/opencode):客户端/服务端分离的开放编码智能体,7k token 低基线跑通 75 家模型

一、导读

过去一周没有哪个开源编码智能体比 OpenCode 更热闹:10 月 14 日官方发布 2.0 大版本(Hacker News 886 分),17 日又爆出托管服务凭据泄露事件(903 分),两件事叠加把它送上 GitHub 涨星榜,单日涨星 1417,截至 2026-10-19 总星数已达 21.6 万。本文基于官方公告、文档源码与第三方测量数据,拆解它的架构原理与落地场景。

二、项目速览

项目 信息
仓库 anomalyco/opencode(原 sst/opencode,团队已独立为公司 Anomaly)
定位 开源 AI 编码智能体:终端 TUI、桌面 App、Web、IDE 插件多端形态
协议与语言 MIT,TypeScript
规模 216,172 星、28,948 fork、约 1055 名贡献者(截至 2026-10-19)
版本线 1.x 线 npm 包 opencode-ai(v1.19.3);2.0 线 npm 包 @opencode/cli(2.0.32)
模型支持 经 Vercel AI SDK 与 models.dev 目录接入 75+ 供应商,支持本地模型
近期大事 10-11 v1.19.0;10-14 OpenCode 2.0;10-17 托管服务安全事件

三、为什么是它

OpenCode 2025 年 4 月底建仓,2026 年 3 月因「开放替代闭源编码智能体」的定位在 Hacker News 走红(1274 分),此后保持每周多个版本的发布节奏。这一年它经历了完整的「走红—审视—迭代」周期:3 月 Anthropic 发出法律要求、7 月被第三方机构逐 token 对账测量、同月还有「烦人且令人担忧的 OpenCode」一类批评帖(420 分)冲上首页,团队都用快速发版回应。这一轮涨星是三件事叠加的结果。

第一,2.0 大版本。官方公告称这是一次「大修」,借鉴了数百万日活用户的使用经验:把原本只在进阶用户间流行的 client/server 架构变成默认形态,服务端成为常驻后台单进程,重写了 API,新增 Code Mode、后台任务与插件体系,官方称 2.0 的几乎所有功能都由 80 多个内部插件实现。

第二,安全事件的「负面曝光」。10 月 17 日官方在 X 平台披露:一个正在退役的旧系统遭未授权访问,保存在 workspace 里的第三方供应商密钥(如 OpenAI、Anthropic)可能暴露,影响约 1.4% 的 Console(官方托管模型网关)用户。事件登上 Hacker News 首页 903 分,巨大争议带来大量新访客涌入仓库。

第三,桌面版进入 Beta。macOS(Apple Silicon 与 Intel 双架构)、Windows、Linux 安装包齐备,补上了与图形界面产品对峙时最明显的短板。

四、架构原理

4.1 总览:客户端/服务端分离,一个常驻服务统管所有端

OpenCode 从第一天起就是 client/server 结构,但 1.x 时代这只是进阶玩法;2.0 把它变成默认形态。服务端以单个后台进程常驻本机(opencode serve 默认监听 127.0.0.1:4096,可用 OPENCODE_SERVER_PASSWORD 加 HTTP 基本认证),对外暴露 OpenAPI 3.1 规范——/doc 端点可以直接查看这份规范,官方 SDK 就是由它生成的。打开 TUI、Web 界面或桌面 App 时,它们连的都是同一个中心进程;用 @opencode/client 写的脚本会自动发现本地服务,也可以用 opencode api 子命令直接调接口,或用 /pair 把其他设备配对进来。IDE 插件则通过服务端的 /tui 端点直接驱动终端界面。这个结构带来三个直接收益:

  1. 多端共享同一份会话状态,终端里开到一半的任务可以在桌面 App 里接着看;
  2. 服务可以无头运行,定时任务、CI、远程服务器场景直接复用同一套 HTTP 协议;
  3. 智能体自己也能调用这份 API——官方演示里,OpenCode 会在开工前调用 worktree_create 把当前会话挪进独立的 git worktree;发现别的会话卡住了,它能自己列出、中断、给那个会话重发提示词,再顺手关掉多余的标签页。

OpenCode 客户端/服务端分层架构手绘信息图

flowchart TB
    subgraph clients["客户端层"]
        TUI["TUI 终端"]
        WEB["Web 界面"]
        DT["桌面 App"]
        IDE["IDE 插件"]
        SC["@opencode/client 脚本"]
    end
    subgraph server["常驻服务端 · 单进程 127.0.0.1:4096"]
        HTTP["OpenAPI 3.1 HTTP API"]
        AG["主智能体 Build / Plan"]
        SUB["子智能体 General / Explore / Scout"]
        BG["后台任务"]
        subgraph state["State 注册表 transform + reload"]
            TOOLS["工具"]
            SK["技能 SKILL.md"]
            MCP["MCP 服务器"]
            PLG["80+ 内部插件"]
            CAT["模型目录"]
        end
    end
    subgraph env["执行环境"]
        LSP["LSP 服务器 30+"]
        SH["Shell"]
        GIT["Git / Worktree"]
    end
    subgraph models["模型层"]
        MD["models.dev 目录"]
        PV["75+ 供应商"]
    end
    TUI --> HTTP
    WEB --> HTTP
    DT --> HTTP
    IDE --> HTTP
    SC --> HTTP
    HTTP --> AG
    AG --> SUB
    AG --> BG
    AG --> state
    AG --> LSP
    AG --> SH
    AG --> GIT
    state --> MD
    MD --> PV

4.2 插件内核:一切注册表都是 State

2.0 最核心的内核设计是官方博客《OpenCode Reloaded》讲的 State 抽象。OpenCode 的运行环境——模型目录、技能、命令、智能体、工具、MCP 服务器、格式化器——全部由插件装配,官方甚至迫使自己把 2.0 的几乎所有功能都重写为内部插件(80 多个),以保证插件 API 有人维护。如果插件直接修改共享对象,会出现三类经典 bug:目录刷新插件整表覆盖后,冲掉策略插件对个别模型的禁用;策略插件改成「监听刷新再执行一次」后,会误伤其他插件后来新增的模型;对输出限额「减半」这类非幂等变换被重复执行,限额从 128K 一路被减到 32K。

OpenCode 的解法是把「直接改」改成「注册变换」:插件只向 State 登记一个变换函数,State 从空值出发按注册顺序把每个变换各跑一遍,得到最终目录;刷新时调用 reload(),从空值重新回放全部变换。官方在文末半开玩笑地总结了这套设计——「自同态天然构成幺半群」——用人话说:同样的起点、同样的变换序列,永远得到同样的结果,插件之间因此不需要互相感知。删除插件文件时,它注册的变换被整体摘除,受影响的 State 立即重建;编辑插件等价于删旧再装新。配合全链路文件监听,智能体可以在会话进行中给自己写一个插件并立刻生效——不需要退出、不需要手动重载。模型目录由内置插件从 models.dev 拉取、每小时刷新,走的也是同一条回放管道。

4.3 Code Mode:把 MCP 编译成模型可写的脚本

2.0 的 Code Mode 是对「工具调用上下文膨胀」的一次正面进攻。官方的理由很直白:模型爱写代码。Code Mode 把 MCP 服务器或 OpenAPI 端点转换成一组函数,让模型写一段普通 JavaScript 脚本一次完成「调用 GitHub 列出 issue、逐条写入 Linear、返回编号」这类组合任务,替代「调一次工具、等一轮返回、再调下一次」的多轮往返——后者每轮都要重付一遍基线开销。执行靠 @opencode/codemode 包里自研的极简 JavaScript 解释器,官方明确说不用 Node.js VM 也不嵌 QuickJS。更激进的是 2.0 里所有 MCP 服务器默认接入 Code Mode,官方的说法是「可以挂一千个 MCP 而几乎不撑爆上下文」:模型面前只有一份简短的函数清单,完整参数结构在脚本执行时才被解释器消费。

4.4 智能体体系、规则文件与权限闸门

OpenCode 内置两个主智能体:Build 全权负责开发;Plan 默认把文件编辑与 shell 命令全部设为 ask,只能看不能动,适合只读分析;Tab 一键切换。三个内置子智能体各司其职:General 承接并行多步任务(也可在消息里 @general 手动唤起),Explore 只读快速探索代码库,Scout 负责把依赖仓库克隆进托管缓存、与本地实现对照阅读。另有一个隐藏的 compaction 主智能体,在上下文过长时自动压缩成摘要。项目规则靠 /init 生成 AGENTS.md——它会扫描仓库、必要时反问几个问题,沉淀构建与测试命令、架构要点、项目约定;文件已存在时做增量改进而非盲目覆盖,官方建议把它提交进 Git。权限模型是 allow/ask/deny 三态,支持通配符(如 mymcp_* 一组工具统一审批)与按输入内容细粒度判断的对象语法,--auto 标志可把未显式 deny 的请求全部放行。语言侧内置 30 多个 LSP 服务器(gopls、rust-analyzer、pyright、jdtls、clangd 等),把编译器诊断回喂给智能体——写错了不用等模型自省,类型检查器直接说话。

4.5 上下文经济学:7k 起步与字节级稳定前缀

咨询机构 Systima 在 2026 年 7 月把 Claude Code 与 OpenCode 放在同一模型、同一机器上逐 token 对账:开口说第一句话之前,Claude Code 的系统提示、工具 schema 与注入脚手架约消耗 33,000 token,OpenCode 约 7,000;OpenCode 的请求前缀在全部采样中逐字节一致,缓存写一次全会话按缓存读计价,而竞品在会话中反复改写数万缓存 token,同一任务缓存写入量最多差 54 倍——缓存写按溢价计费,这正是很多人账单失控的原因。配置还会继续放大差距:一份 72KB 的 AGENTS.md 平均再增加约 20,000 token,五个普通 MCP 服务器再加 5,000 到 7,000,真实生产环境的首个请求普遍深达 75,000 到 85,000 token。这篇文章也给了反面数据:多步任务上竞品靠批量工具调用摊薄请求数,整任务总消耗反而可能更低;子代理扇出会把基线翻倍——121k token 能直接做完的事,双子代理要 513k。这组数字勾勒出 OpenCode 的架构取向:把「每轮固定开销」压到最低并保持前缀稳定,代价是长任务要靠后台任务与 compaction 控制轮数。

4.6 与同类架构路线的差异

把三大主流 harness 摆在一起看,路线差异一目了然。Claude Code 是「深度绑定模型」的单体进程:harness 与 Anthropic 模型联合调优,行为迭代由官方单方驱动,第三方只能通过 MCP 与 Agent SDK 在外围扩展。Aider 则代表「无智能体调度」的结对编辑流派:没有常驻服务、没有子代理,靠仓库地图与精准的编辑格式取胜,轻但天花板明显。OpenCode 的赌注是第三条路——把 harness 做成平台:协议先行(HTTP/OpenAPI 定义一切)、状态内核化(所有注册表走 State 回放)、功能插件化(80 多个内部插件与用户插件走同一条 API)。这条路线的代价是复杂度前置——用户要理解服务端、配置、权限三层概念;收益则是 2.0 展示的组合能力:任何端、任何模型、任何语言生态都能挂在同一份协议上,智能体自己也能作为客户端参与编排。行业里做类似选择的还有 Zed 推动的 Agent Client Protocol——OpenCode 2.0 已支持 ACP,可直接接入兼容编辑器,开放协议之间开始互认。

五、应用场景

OpenCode 一次编码任务端到端流程手绘示意图

5.1 多供应商自由切换的日常终端编码

痛点是被单一厂商订阅锁定,模型好坏全看供应商脸色,成本不可控。OpenCode 用 /connect 配置任意供应商的 key,/models 随时切换,支持本地模型;不想到处申请 key 的新手可以用官方托管的 Console/Zen 通道一键接入一批官方实测过的模型。7k 的低基线意味着同样的对话轮数下,花在脚手架上的钱只有高基线竞品的两成左右(Systima 口径)。官方在模型文档里还维护了一份推荐清单(GPT 5.2、Claude Opus 4.5、Gemini 3 Pro、Minimax M2.1 等),理由是同时擅长代码生成与工具调用的模型其实不多。最小路径:

curl -fsSL https://opencode.ai/install | bash
cd your-project && opencode
# TUI 内执行 /connect 填 key,/models 选模型,/init 生成 AGENTS.md

风险敏感的仓库建议先收紧权限再开工:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "ask",
    "edit": "allow",
    "bash": "ask"
  }
}

适用边界:key 与账单要自己管理,团队统一采购、按用量报销审计的场景更适合走 5.4 的企业形态。

5.2 大仓库的只读探索与变更规划

痛点是接手陌生代码库时,直接让全权智能体动手风险高,改错文件、跑错命令都要回滚。把 Tab 切到 Plan 模式,编辑与 shell 默认 ask,模型只能读与分析;配合 Explore 子智能体做快速定位、Scout 子智能体把上游依赖克隆进托管缓存对照阅读,LSP 诊断让「理解」有编译器背书;输入 @ 还能模糊检索并引用项目文件,把上下文喂得又快又准。探索满意后切回 Build 执行,/undo 可逐步回退、/redo 重做。这一流程适合代码评审前的预研、跨仓库影响面分析、给新成员做架构讲解——拖一张架构图进终端,模型可以直接读图作答。边界:Plan 模式仍会消耗 token 做大规模阅读,超大型单体仓库建议先用 /init 生成精炼的 AGENTS.md 再探索。

5.3 无人值守自动化:从定时任务到 GitHub 机器人

client/server 结构在这里兑现价值。服务端常驻后,脚本通过 Service.ensure() 自动发现本地服务,几行代码就能驱动一次完整的智能体任务:

import { OpenCode } from "@opencode/client"
import { Service } from "@opencode/client/service"

const endpoint = await Service.ensure()
const client = OpenCode.make({ baseUrl: endpoint.url, headers: Service.headers(endpoint) })
const session = await client.session.create({ location: { directory: process.cwd() } })
await client.session.prompt({ sessionID: session.id, text: "Review the current changes" })

这让它天然适合「每晚巡检失败测试、自动开 issue」的定时任务;智能体还会把并行工作挪进独立 git worktree 互不干扰。GitHub 之外还有 GitLab 集成:通过 GitLab CI/CD 组件或 GitLab Duo 接入,任务同样只在你的 GitLab runner 里执行。GitHub 集成走 opencode github install,之后在 issue 或 PR 评论里写 /oc 修复这个 flaky test,OpenCode 会在 GitHub Actions runner 里开新分支、提交 PR——代码始终不出你的仓库与 runner,官方把这点列为该集成的主要安全卖点。收益是响应时间从「人来看」变成分钟级出 PR。边界:CI 机时要计入成本;自动提交的 PR 仍需人工评审,不要把合并权限也交给机器人。

5.4 团队与企业私有化

痛点是编码智能体要碰公司源码,SaaS 形态过不了合规。OpenCode 的数据面承诺是「不存储代码与上下文,处理在本地或直连你信任的供应商」;Enterprise 形态在此之上提供集中配置、SSO 与内部 AI 网关对接,配合 4.4 的三态权限做工具白名单,官方文档写明了先内部试用再谈采购的路径。边界:私有化意味着自己运维模型网关与密钥——10 月 17 日的事故恰恰说明,托管面(Console)与本地 CLI 是两套信任域,企业应把密钥留在内网网关,而非托管工作区。

5.5 给智能体写插件与技能:会话中途自扩展

痛点是每个团队的工序都有自己的私有知识,通用工具覆盖不了。OpenCode 的技能遵循 SKILL.md 开放标准,且同时兼容三套目录:自己的 .opencode/skills/,以及 .claude/skills/、.agents/skills/ 两套社区惯例路径,从其他工具迁移不用改文件;技能按需加载,只在模型需要时才展开全文,不占常驻上下文。插件则支持本地 TypeScript 文件或 npm 包安装。官方演示里有一个生动的闭环:让智能体写文章,它发现需要统计字数,就当场给自己写一个 word_count 插件、装一个 grill-me 技能,随即在同一场会话里用上——全部得益于 4.2 的热重载内核。TUI 插件也已转正(基于 OpenTUI),可以定制终端界面本身。边界:插件拥有绕过默认行为的能力,生产项目里装第三方插件前应审查源码,提示注入风险在插件生态里会被放大。

六、快速上手

# 安装(三选一)
curl -fsSL https://opencode.ai/install | bash
brew install anomalyco/tap/opencode   # macOS/Linux,更新最及时
npm i -g @opencode/cli@latest         # 2.0 线

# 初始化与使用
cd your-project
opencode          # 启动 TUI(2.0 起同时拉起常驻服务端)
# /connect 配置模型供应商(新手可选 Console/Zen 托管通道)
# /init    扫描仓库生成 AGENTS.md(记得提交进 Git)
# Tab      在 Build / Plan 主智能体间切换
# /models  切换模型;@文件名 引用文件;拖图可进多模态提示
# /undo /redo  逐步回退或重做改动

进阶三件套:opencode serve 起无头服务端(默认 127.0.0.1:4096,可用 OPENCODE_SERVER_PASSWORD 加基本认证);opencode github install 接入 issue/PR 自动处理;opencode upgrade --major 从 1.x 升 2.0(注意破坏性变更,官方建议让 OpenCode 对着迁移文档自己改配置)。

七、横向对比

方案 协议 模型接入 架构形态 扩展机制
OpenCode 2.0 MIT 75+ 供应商 + 本地模型 客户端/常驻服务端分离 80+ 内部插件热重载、MCP、SKILL.md
Claude Code 专有 Anthropic 模型 单体进程 MCP、Claude Agent SDK、插件市场
Codex CLI Apache-2.0 以 OpenAI 模型为主 终端单进程 MCP、配置文件
Aider Apache-2.0 多供应商 结对编辑单进程 仓库地图与编辑格式,无智能体调度

选择逻辑:看重供应商中立与多端协同选 OpenCode;全押 Anthropic 生态、要官方支持选 Claude Code;深度 OpenAI 用户选 Codex CLI;只要精准的结对编辑、不需要智能体调度,Aider 依然顺手。上下文开销上,7k 对 33k 的基线差距(Systima,2026-07)是 OpenCode 最硬的差异化数据,但多步任务的整任务总消耗两家各有胜负,选型前最好用自家仓库实测账单。

八、局限与风险

第一,安全信任。10 月 17 日事件中泄露面是 Console 托管工作区里保存的第三方密钥,官方建议受影响用户立即吊销换钥;本地 CLI 用户用自己的 key 按官方口径不在影响范围内,但社区有「.env 文件也可能被智能体读取」的传言,未经证实(待确认)。所谓密钥被用于「大规模蒸馏」的说法目前没有公开证据。此外仓库在 2026 年 1 月还披露过未认证 RCE 漏洞(细节待确认),安全履历需要持续观察官方 postmortem。

第二,供应商关系与治理。2026 年 3 月官方按法律要求移除了仓库中的 Anthropic 品牌引用(PR #18186:删除提示词文件、provider 提示、anthropic 认证插件与枚举);README 专门要求衍生项目声明无隶属关系。第三方「opencode-xx」项目泛滥,选型时要认准 anomalyco 官方仓库。

第三,破坏性升级。1.0 插件在 2.0 全部失效,server API 完全重写,tui.json 配置移除,两条版本线不能并装。生产环境升级要预留迁移与回归时间。

第四,成本结构不适合所有任务形态。子代理扇出会把固定基线成倍放大(同一件事 121k 直接做、513k 扇出做),长链路多步任务的整任务消耗可能反超高基线但批量工具调用的竞品。

第五,工程成熟度。4675 个开放 issue 配合每周多版的节奏,issue 积压与行为变更都来得快,关键场景建议锁版本;桌面版仍在 Beta,多端体验以 TUI 为最稳。7 月那篇 420 分批评帖所代表的社区审视,也在提醒它隐私默认值与工程决策会持续被放大检验。

九、小结与行动建议

OpenCode 用 client/server 分离、插件化内核与近乎偏执的上下文节俭,证明了「开放编码智能体」不只是闭源产品的影子,而在多模型中立、无人值守集成这两条路上走得更远;10 月的安全事件则提醒我们,托管面与本地面的信任边界需要用户自己看清。行动建议:

  1. 个人开发者:装一份跑一周,重点体验 Plan 模式只读探索与 /models 多模型切换,用自家真实任务对比 token 账单;
  2. 已有编码智能体订阅的用户:并行评估两边的会话开销(7k 对 33k 基线),留意多步任务的反例;
  3. 平台工程师:试点 opencode serve 加 @opencode/client 的定时任务流水线,以及 GitHub /oc 的 issue 自动修复,这两处是 2.0 架构红利的兑现点;
  4. 安全与合规团队:把供应商密钥收进内网网关而不是托管工作区,持续跟踪本次事件的官方 postmortem;
  5. 插件开发者:2.0 把全部内部功能都压在插件 API 上,官方有维护动力,是值得早期投入的扩展面。

参考资料

  1. anomalyco/opencode 仓库与 README:https://github.com/anomalyco/opencode(获取日期 2026-10-19)
  2. OpenCode 2.0 发布说明,Anomaly 官方:https://anoma.ly/notes/opencode-2-0/(获取日期 2026-10-19)
  3. OpenCode Reloaded(插件热重载架构),Anomaly 官方:https://anoma.ly/notes/opencode-reloaded/(获取日期 2026-10-19)
  4. OpenCode 官方文档(Server / Agents / Permissions / LSP / Skills / Models / Enterprise 各页):https://opencode.ai/docs/(获取日期 2026-10-19)
  5. Systima:Claude Code Is Way More Token-Hungry Than OpenCode. We Measured Exactly How Much:https://systima.ai/blog/claude-code-vs-opencode-token-overhead(获取日期 2026-10-19)
  6. Hacker News:OpenCode 2.0(886 分):https://news.ycombinator.com/item?id=50094994(获取日期 2026-10-19)
  7. Hacker News:OpenCode Hacked: User credentials leaked(903 分,含 OpenCode 团队声明转述):https://news.ycombinator.com/item?id=50133401(获取日期 2026-10-19)
  8. PR #18186「anthropic legal requests」:https://github.com/anomalyco/opencode/pull/18186(获取日期 2026-10-19)
← 返回资讯列表

读者留言

COMMENTS 暂无
仅本站原创文章开放留言 · 请勿留下手机号、邮箱等个人信息

还没有留言,来说第一句?