​
先看下最终效果

我是怎么把 OpenCode 包装成一个本地 OpenClaw / 飞书接入桥的

如果你平时会用 OpenClaw、飞书机器人，或者你已经在本机跑了 OpenCode Serve，你很快会遇到一个实际问题：

OpenCode 本身很好用，但很多外部接入方并不能直接把它当成一个稳定的、标准兼容的 API 来消费。

于是我做了一个很小但很实用的本地桥接层：OpenCodeProxy。

它的目标不是做一个线上公共平台，也不是做多用户 SaaS，而是把你本机已经跑起来的 OpenCode 能力，包装成一个更容易被 OpenClaw 和 飞书 接入的本地开放 API。

这篇文章我主要讲三件事：

• 我想解决什么问题

• 这个项目怎么部署

• 最后达到了什么结果

---

一、要解决的问题

1. OpenCode 本身不是为 OpenClaw / 飞书直接接入设计的

OpenCode 更像一个本地 AI 编码环境，它很强，但外部系统接入时会遇到几个现实问题：

• 没有一个现成的、本地就能直接复用的标准兼容入口

• OpenClaw 这类系统更适合对接稳定的 API base URL

• 飞书机器人也更适合走一个固定的本地桥接层

换句话说，问题不是模型本身，而是接入层不够顺手。

2. 我需要一个稳定、可控、低成本的本地桥

我希望最终是这样一条链路：

OpenClaw / 飞书

-> 本地桥接代理 (18888)

-> 本地 OpenCode Serve (4096)

-> 你本机已经配置好的模型与 provider

如果把它画得更完整一点，就是：

┌─────────────────────┐

│ OpenClaw / 飞书 │

└─────────┬───────────┘

│

v

┌─────────────────────┐

│ OpenCodeProxy │

│ 127.0.0.1:18888 │

└─────────┬───────────┘

│

v

┌─────────────────────┐

│ OpenCode Serve │

│ 127.0.0.1:4096 │

└─────────┬───────────┘

│

v

┌─────────────────────┐

│ 本机 provider / 模型 │

└─────────────────────┘

也就是说：

• OpenClaw 不需要理解 OpenCode 内部细节

• 飞书也不需要直接碰 OpenCode Serve

• 只要接这个本地代理就行

---

二、这个项目现在的定位

这个仓库现在只做一件事：

把本地 OpenCode Serve 转换成一个适合 OpenClaw / 飞书接入的本地 API 桥。

所以它不是：

• 线上模型售卖平台

• 公共 SaaS 网关

• 多租户代理平台

它就是一个本地接入桥。

---

三、项目结构

我最后把目录整理成适合放到 GitHub 的样子：

OpenCodeProxy/

README.md

LICENSE

package.json

.gitignore

openclaw-local/

opencode-proxy.js

openclaw.example.json

其中最关键的文件有两个：

• openclaw-local/opencode-proxy.js

• 本地桥接代理核心

• openclaw-local/openclaw.example.json

• 脱敏后的 OpenClaw 示例配置

---

四、我是怎么部署这套本地桥的

Step 1：先启动本地 OpenCode Serve

OpenCode 本身还是底层能力提供者，所以第一步先让它跑起来：

opencode serve --port 4096

这一步完成后，本地会有一个：

• 127.0.0.1:4096

Step 2：准备 OpenClaw 配置

把仓库里的示例配置复制到本机实际配置位置：

cp openclaw-local/openclaw.example.json ~/.openclaw/openclaw.json

然后把里面这些值替换成你自己的：

• 模型 ID

• Feishu appId

• Feishu appSecret

• gateway token

示例里，OpenClaw 的 provider 是这样接本地桥的：

"opencode": {

"baseUrl": "http://127.0.0.1:18888",

"apiKey": "not-needed",

"api": "openai-completions"

}

Step 3：启动本地桥接代理

项目根目录下直接启动：

npm start

或者直接运行源码：

node openclaw-local/opencode-proxy.js

默认端口是：

• Proxy：127.0.0.1:18888

• OpenCode Serve：127.0.0.1:4096

Step 4：让 OpenClaw / 飞书 对接本地桥

这时候链路就变成：

OpenClaw / 飞书

-> 127.0.0.1:18888

-> 127.0.0.1:4096

-> OpenCode provider / models

如果你想在博客里放一张更清晰的部署图，也可以直接用下面这版：

部署前：

OpenClaw / 飞书

-> 直接碰 OpenCode

-> 接入关系不清楚


 

部署后：

OpenClaw / 飞书

-> OpenCodeProxy (18888)

-> OpenCode Serve (4096)

-> provider / models

对于上层接入方来说，它根本不需要关心 OpenCode 里面到底怎么配 provider，只要把本地桥当成标准兼容接口即可。

---

五、这个代理解决了什么实际问题

1. 统一了接入入口

以前你得直接对着 OpenCode Serve 思考怎么接，或者让外部系统理解 OpenCode。

现在只需要记住一个入口：

http://127.0.0.1:18888/v1

2. OpenClaw 可以直接挂上去

OpenClaw 更适合消费稳定的 provider/baseUrl，这个桥刚好承担了这一层。

3. 飞书接入边界更清楚

飞书不再直接碰到底层 OpenCode，而是通过本地代理走统一链路。

4. 保留 OpenCode 自己的灵活性

底层 provider、模型、提示词仍然由你本机的 OpenCode 配置决定，不需要在桥接层里重复实现一整套 provider 管理。

---

六、我最后得到的结果

最终我想要的效果已经达到了：

• 本地 OpenCode Serve 继续作为底层能力

• OpenClaw 有了固定本地桥接入口

• 飞书也可以走同一条本地链路

• 整个项目边界变清楚了：

• 它只是本地桥

• 不再冒充线上平台主链路

一句话总结就是：

我不是把 OpenCode 做成一个线上 SaaS，而是把它整理成一个本地可复用的接入层。

如果用一句更工程化的话来说：

这个项目最终解决的是本地 AI 能力接入边界问题，而不是模型能力本身的问题。

---

七、适合什么人参考

如果你也有下面这些需求，这个思路会很适合你：

• 你已经在本机跑 OpenCode

• 你希望让 OpenClaw 复用它,不想用本地的弱智模型

• 你想把飞书接进来

• 你不想把这套东西直接暴露成线上公共网关

---

八、结语

很多时候，真正难的不是模型本身，而是“怎么让它以一种合适的方式接入现有工作流”。

对我来说，这个项目最大的价值不是又写了一个代理，而是把本地 OpenCode 的能力边界重新理顺了：

• 该给本地用的，就本地用

• 该做桥接层的，就只做桥接层

• 不把本来不该承担的线上职责硬塞进去

如果你也在折腾 OpenClaw、飞书和 OpenCode 的组合，希望这篇文章能给你一点参考。

如果喜欢的人比较多，我把源码开放给大家！

​