最近，anomalyco 开源的 OpenCode 在开发者圈子里火了起来。它不像传统 Copilot 插件那样只做补全，而是一个能理解自然语言指令、自主操作文件系统、运行测试甚至调试的 AI 编码代理（AI Coding Agent） 。很多团队开始尝试基于它构建内部工具，甚至探索对外提供 SaaS 服务。
但很快，一个问题浮现出来：OpenCode 默认依赖 Claude 或 OpenAI。这意味着：
- 成本不可控（尤其高频调用场景）
- 数据可能出境，不符合企业合规要求
- 无法灵活定价、难以实现按客户计费
于是，不少人转向 自建开源代码大模型（如 Meta 的 CodeLlama、DeepSeek-Coder、StarCoder2），通过 vLLM 或 TGI 部署推理服务。这解决了模型层的问题，但新的挑战又来了：
如何让 OpenCode 稳定、高效、可计量地调用这些私有模型？
这时候，我注意到一个低调但极其务实的开源项目 —— LLMProxy。它不做模型、不搞 UI，只专注一件事：为自建 LLM 服务提供生产级网关能力。而在 OpenCode 的商业化路径中，它恰好扮演了关键角色。
为什么 LLMProxy 特别适合 OpenCode 场景？
✅ 1. 无缝对接 OpenCode 的 API 要求
OpenCode 期望后端提供标准的 OpenAI 兼容接口（/v1/chat/completions）。LLMProxy 能将你的 vLLM/TGI 服务自动包装成这一格式，无需修改 OpenCode 客户端配置——只需把 api_base 指向 LLMProxy 地址即可。
✅ 2. 原生支持流式响应，保障编码体验
写代码时，用户需要逐 token 实时看到输出。LLMProxy 对 SSE（Server-Sent Events）做了零缓冲透传，确保首 token 延迟（TTFT）几乎无增加，体验媲美商用服务。
✅ 3. 自动用量计量，打通计费闭环
这是商业化的核心。当 OpenCode 发起一次请求，LLMProxy 会在响应结束后（包括流式请求的 [DONE] 事件）异步推送 prompt_tokens 和 completion_tokens 到你的 Webhook。你可以据此实现：
- 按客户/租户统计用量
- 生成月度账单
- 超额自动限流或停服
整个过程非阻塞，不影响主链路性能。
✅ 4. 轻量、可靠、无侵入
- 单 Go 二进制，Docker 镜像 < 20MB
- 配置仅需一个 YAML 文件
- 不依赖数据库，不解析业务逻辑
- 内置 Prometheus 指标 + Grafana 面板
对于希望快速验证商业模式的小团队来说，这种“开箱即用”的设计极大降低了运维成本。
一个典型的部署架构
text
编辑
1[OpenCode Client]
2 ↓
3[LLMProxy] ←→ [Webhook 计费系统]
4 ↓
5[vLLM + CodeLlama-34B] ← 私有化部署，数据不出内网
你只需：
- 用 vLLM 启动 CodeLlama
- 配置 LLMProxy 指向该后端 + 设置 Webhook
- 修改 OpenCode 的
api_base为 LLMProxy 地址
即可拥有一个完全自主可控、可计量、可收费的 AI 编程服务平台。
写在最后
LLMProxy 并不是一个“炫技”型项目，它没有大模型、没有前端、甚至没有复杂的控制台。但它精准地解决了 自建 LLM 服务走向生产落地的最后一公里问题——尤其是像 OpenCode 这类需要稳定、可计量、低延迟后端的智能代理场景。
如果你正在探索：
- 用开源模型替代 OpenAI/Claude
- 构建内部 AI 编程助手
- 对外提供 MaaS（Model-as-a-Service）服务
那么，LLMProxy 值得你花 10 分钟试一试。
GitHub 地址：github.com/aiyuekuang/…
MIT 开源协议，文档齐全，支持 Docker / Kubernetes 一键部署。
PS：目前已有团队基于此方案为中小开发团队提供按 token 计费的 OpenCode 服务，客单价从几百到数千元/月不等。基础设施的成熟，正在让“一个人的 AI 公司”成为可能。
