关键词：Cursor 自带密钥（BYOK）、OpenAI Compatible、天翼云、本机 SSE 兼容转发、Cloudflare 安全隧道
一句话：天翼云侧模型调用成本较低，但自定义接入直连官方 URL 时，流式协议与 Cursor 云侧不完全匹配；用本机转发服务做兼容处理后，再通过安全隧道提供给云端访问，即可在 Cursor 原生里稳定使用天翼云模型。
一、问题（源头）
目标：让 Cursor 自带 Agent / Chat 稳定使用天翼云模型（如kimi-k3-oc/deepseek-v4-pro-0813-oc/glm-5.3-oc）。
为什么值得做：天翼云侧模型调用成本相对较低，同量级对话成本低于许多默认通道；若能在 Cursor 原生里跑通，性价比很明显。卡点不在“成本是否可接受”，而在“连接是否稳定”。
问题源头不是“没有公网域名”，而是协议层。
把自定义 Base URL 直指天翼云官方 OpenAI Compatible 地址时，链路在业务上似乎“通了”，但表现不稳：
- 流式（SSE）响应里的字段、分片节奏、收尾方式与 Cursor 云侧期望不完全一致；
- 常见结果是协议/连接类错误、中途断开、界面卡住或报 connecting；
- 天翼云往往已经在出内容，Cursor 却不能稳定“吃完这一条流”。
因此需要在中间加一层专为 Cursor 服务的兼容处理，而不是继续让云端直接连接官方 URL。
说明：像 OpenCode 一类本机客户端，往往可以直接配天翼云官方接口；本文方案针对Cursor 云端自定义接入的特殊约束，不讨论其它客户端怎么接。
二、分析
2.1 源头：合拍要求的是“流”，不是“能不能 POST 通”
OpenAI Compatible 只保证路径与大致 JSON 形状相近。Cursor 云侧对 SSE 还有隐含约定，例如：
- 是否尽快见到响应头（否则易撞超时）；
- 一条流上的
id是否前后一致； - 是否出现明确的
finish_reason/[DONE]，连接是否及时关掉。
官方 URL 直接回的流，在这些细节上与云侧不完全一致时，就会表现为“不稳”——这是要做本机转发服务的直接理由。
2.2 直接替代也不成立：自定义接入填127.0.0.1
直觉是：既然要本机兼容处理，自定义接入直接写http://127.0.0.1:18787/v1。
但 Cursor 的自定义接入由云端出站访问 Base URL；云端的127.0.0.1是云侧自己，访问不到你的电脑。表现往往是 connecting、本机转发服务零日志。
因此完整链路应该是：
云端 →（公网可达入口）→ 本机转发服务（兼容处理）→ 天翼云，
而不是“云端 → 天翼云”或“云端 → 本机 loopback”。
2.3 转发服务要补什么（对应源头）
| 能力 | 针对的源头现象 |
|---|---|
| 提前回 SSE 头 | 等上游首包过久 → 超时/connecting |
统一流id | 云侧按一条流解析失败 |
注入reasoning_effort=low | 控制推理开销（落地配置） |
补finish_reason+[DONE]并关连接 | 协议错误、流未收干净 |
公网入口启用 Bearer 鉴权（/healthz除外） | 入口开放后的安全底线 |
三、解决（技术可行方案）
思路分三步：本机转发服务解决流式兼容 → 公网入口解决云端可达 → 按上述设计实现并打包发布。
3.1 方案核心：本机转发服务，处理 Cursor 流式兼容
其它工具若能直连天翼云官方接口，不必走这套。Cursor 不行，是因为自定义接入出站在云端，且对 SSE 收尾更挑。可行做法是在本机起一个 OpenAI Compatible 转发服务：对上游做兼容处理，再对外提供/v1。
关键实现是本机proxy.py（提前 SSE 头、统一 id、补[DONE]等），可用系统服务保持常驻。有了转发服务，还缺一环：Cursor云端必须能 HTTP(S) 访问到这台机器上的:18787。
3.2 公网入口：两种可行方案
转发服务解决“兼容”；下面解决“可达”。条件不同，成本也不同。
| 维度 | 方案 A：快速验证（quick tunnel） | 方案 B：固定入口（命名隧道 + 自有域） |
|---|---|---|
| 条件与费用 | Cloudflare 临时隧道，无需买域名，可零额外域名成本先跑通 | 需自行购买域名（及按注册商规则完成 NS 接入），Cloudflare 站点可用 Free；域名本身要花钱 |
| 公网访问 URL | https://*.trycloudflare.com（会变） | 固定主机名（示例：https://ctyun.lcw918.loan） |
| cloudflared | tunnel --url http://127.0.0.1:18787 | tunnel run+ 文件读入令牌 |
| 自定义接入 | 换址后需完全退出 Cursor 再写入 | 配一次即可长期用 |
| 运维 | 抖动更大，换址要跟着改 | KeepAlive 即可，无需换址看门狗 |
| 适用 | 验证“云端→隧道→转发服务→天翼云”闭环 | 日常长期使用 |
实践上可先用方案 A 验证链路，再迁到方案 B。固定域名时还要注意：本机网络策略需放行cloudflared进程直连、NS/DNSSEC、Service URL 带http://、访问密钥不进命令行、1033 多为 connector 未挂上等；域名接入步骤见压缩包内说明。
3.3 设计落地：统一程序压缩包
上面 3.1、3.2 是设计；按“本机转发服务 + 方案 B 固定入口”把脚本、自启配置与说明收成一份实现，打成压缩包随文提供：
[附件-ctyun-local-proxy.zip]
包内主要包括：流式兼容转发服务、命名隧道启停、状态检查、macOS 自启样例、网络分流规则样例、写入 Cursor 自定义接入的脚本，以及使用说明与域名接入说明。解压后按包内使用说明.md配置本机路径、密钥与隧道，验收healthz通过后，完全退出 Cursor 再执行 apply 脚本写入自定义接入配置，即可选用天翼云模型。
到此：天翼云访问凭证，可以配套 Cursor 稳定使用。
说明：以上仅面向自有或已授权环境，请遵守 Cursor、天翼云、Cloudflare 等相关服务条款，妥善保管密钥，不对外共享入口。平台审核结果仍以其规则为准。
