乐悠厨房最近我把OpenCode这个AI Agent项目从源码完整构建了一遍。起因挺朴素——官方的一键安装脚本在我这台Win11 + WSL2的机器上连续翻了两次车，第一次装完命令找不到，第二次装完运行起来又提示缺少运行环境。与其继续跟安装器搏斗，不如直接把仓库拉到本地自己编译，顺便验证我一直在琢磨的一个问题：同一个项目，用Bun构建和用Node构建，速度到底能差多少。
这篇文章适合三类人看：打算从源码安装OpenCode的开发者、对Agent框架感兴趣想看看它内部怎么组织的人，以及正在评估要不要把Bun引入日常构建流程的人。文章会完整记录OpenCode从clone到运行的构建链路，给出同一环境下的Bun和Node实测数据，最后把我踩过的几个坑逐个讲清楚。
1. 从一键脚本翻车到决定自己构建
先说结论：如果你在官网或者GitHub Releases页面能顺利下载到对应平台的安装包，并且装完一切正常，真没必要折腾源码构建。我这次完全是安装器被环境坑了，才被迫走上源码这条路。但走完之后我反而觉得，这趟折腾挺值的。
1.1 官方安装脚本在我机器上的翻车现场
我平时的主力环境是Win11宿主机加WSL2（Ubuntu 22.04），OpenCode这类AI Agent工具我习惯放在WSL里，因为它跟命令行生态、git、容器环境挨得近。官方一键安装脚本在Linux下一般很顺，但我在WSL里执行完之后，回到Windows自带的PowerShell执行opencode，发现命令完全不可用，报错信息如下：
code复制opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称
这个报错很经典。问题出在脚本装好的二进制放在WSL内部的 ~/.opencode/bin 下，Windows的PATH根本不知道这个路径的存在。我尝试用 bash -c "opencode --version" 又能跑通，说明WSL内部其实装好了，只是PowerShell没找到。后来我改用VSCode的WSL插件，直接在WSL终端里执行，倒也能运行，但总觉得别扭——每次要先进WSL，再手动加载环境，体验非常割裂。
1.2 源码构建到底让我得到了什么
折腾了一阵子之后，我决定不再和安装器搏斗，直接源码构建。这套路线换来了几个实打实的好处：
- 拿到主分支的最新改动能第一时间用上，包括新出的技能系统、模型接入调整等，不用等官方打包发布；
- 想改内置行为时可以顺着源码直接改，比如自定义Agent技能目录、调整系统提示词模板；
- 遇到报错时能看到具体是哪个模块抛出来的，排查问题的信息量比黑盒安装包大得多；
- 可以顺手在自己机器上做性能验证，也就是这次的Bun和Node速度对比。
当然代价也很明显：构建过程会暴露大量依赖兼容性问题，特别是当项目用了比较新的ESM规范和Option Chaining语法时，Node版本太低就会翻车。如果你只是想要一个开箱即用的工具，官方包已经足够；但如果你像我一样想搞明白这玩意儿到底怎么跑的，源码构建是必经之路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前的环境底牌：Node版本、nvm和Bun的进场方式
源码构建的第一步其实不是clone，而是把运行环境捋顺。OpenCode本身的代码是用TypeScript写的，构建期需要Node或者Bun来跑脚本。我的建议是两套都装上，这样对比才方便，遇到兼容性问题时也能快速切换验证。
2.1 Node侧：版本锁定的坑
版本选择上，我强烈建议直接上Node.js 20 LTS或者更高。原因很简单，OpenCode的源码用了现代ESM规范，很多依赖包也在用 import { promisify } from 'node:util' 这种显式导入方式。Node 16以下的版本对ESM的导出支持不完整，很容易出现那个经典报错：
code复制SyntaxError: The requested module 'node:util' does not provide an export named 'promisify'
这个报错表面看是模块导入问题，本质是Node版本太老，node:util 的ESM导出表里没有对应