Linux.do论坛一位开发者分享了自制的本地代理脚本，解决了Kimi Code等第三方AI编程工具无法调用OpenCode Console免费模型的兼容性问题。问题根源在于：OpenCode Console对免费档模型设有工具名校验，要求工具名必须是小写的read、write、edit、bash、glob、grep等原生格式，否则返回403 FreeTierError错误；而Kimi Code发送的是首字母大写的工具名（Read、Write、Edit等），双方命名规则不一致导致请求被拒。作者的解决方案是用Python标准库编写约百行代码的本地代理服务，默认监听127.0.0.1:18080端口，上游指向opencode.ai的OpenAI兼容推理接口。代理在请求发出前将六种大写工具名映射为小写，在响应返回时（包括普通JSON响应和SSE流式响应）再把小写名还原为大写，使客户端与服务端各自看到自己熟悉的命名，其余内容原样透传。整个实现不依赖任何第三方库，并附带bash管理脚本，提供start、stop、status三个命令，支持幂等的进程状态检测与端口冲突提示。该方案同样适用于其他发送大写工具名的AI编程客户端，作者欢迎社区指导改进。
事件分析
从技术实现看，该代理的核心难点在于SSE流式响应的逐行解析与改写，仅在data字段中拦截tool_calls的工具名并还原，其余内容直接透传，兼顾了实时性与正确性。这一案例折射出AI编程工具生态的现状：各家客户端在工具调用的命名约定上尚未形成统一标准，OpenAI兼容协议虽是事实标准，但工具名层面的细节差异仍会制造互操作性壁垒。社区以轻量代理做协议转换，本质上是补齐生态碎片化的缝隙。类似的兼容层思路在Claude Code、Gemini CLI等工具的第三方接入场景中已多次出现，正逐渐形成一种常见模式。后续若OpenCode调整免费档校验逻辑，或各客户端在工具命名上向标准化靠拢，此类代理的必要性可能下降；但在标准统一之前，这类低成本桥接方案仍会持续涌现，成为开发者获取免费模型资源的典型技术路径。
核心观点：兼容协议止于接口层、工具命名各自为政，AI编程生态的碎片化正由民间几十行代理代码来缝补。
原文链接：Linux.do
