ZON
ZON / Best Minds Board Private
Stage Summary · OpenClaw
Best Minds Stage Summary

OpenClaw Gateway CORS 阶段性总结

把这条线从“最初想成为 OpenClaw 贡献者、寻找可合并价值点”，收口到一个更现实的结论： 你当前工作树里最显眼的 browser/CORS 改动，解决的是一个已经被你放弃的本地 IM / 浏览器直连方向； 它不是你现在的 Feishu 主线刚需，所以最优解不是继续硬推 upstream，而是把实验和主线拆开管理。

最初诉求成为可持续贡献者 当前主线Feishu → Gateway → 远端控制 关键判断这批 CORS 改动不属于当前主线 推荐动作归档实验 patch，主工作树回近 upstream
Real Problem
浏览器 loopback CORS
不是 Feishu 收发本身，而是浏览器直连本地 Gateway 的预检与跨域。
Current Importance
低
对你当前实际使用路径不是必要条件，属于被废弃方向残留。
Upstream Likelihood
偏低
因为它更像 fork 级定制而不是共享痛点修复。
Best Next Move
拆分
浏览器 patch 单独归档；主工作树优先保护 Feishu 主线并贴近上游。

谁最懂这个问题

这不是“代码能不能写出来”的问题，而是“什么应该进主线、什么应该留在实验分支”的问题。

OpenClaw Maintainers

他们最关心的是：这是不是多数用户共享的问题？维护成本是不是低？边界是不是说得清楚？

从这个视角看，你现在的 loopback CORS 改动更像一个特定使用方式的增强，而不是主流路径上的 bug 修复。

Linus Torvalds

经典判断标准不是“能不能加”，而是“为什么非加不可”。

如果一个改动主要服务于个人工作流或定制场景，它更适合停留在 fork / patch / branch，而不是占据上游主线复杂度。

Jez Humble

实验可以很多，但主线必须可验证、可回滚、可低风险演进。

所以这里的重点不是“删不删代码”，而是先把实验路径和生产主线隔离，再用定向测试保护现有流程。

一句话结论

你最初是想找到一条“真实有价值、能被 OpenClaw 接收、并能帮助你成为贡献者”的改动路径； 这次排查后的结论是：当前这批 Gateway browser/CORS 改动解决的是你在 2026-02-14 左右为“自建 IM APP 接 clawbot”而打开的一条分支需求， 但你现在真正持续使用的是 Feishu → Gateway，所以这批改动对当前主线不是必要条件。

时间线

2026-02-14 23:56 CST 微信限制太多，想做 IM APP 接 clawbot 随后出现浏览器直连 Gateway 并为 localhost:3000 做 CORS 预检 方向变化 转向现成入口与 Feishu 主链路 2026-03-10 阶段复盘 结论：实验 patch 不再属于主线刚需
关键不是这段代码“有没有用”，而是它服务的那条产品路径已经不再是你的主线。
2026-02-14 23:56 CST
最初动机被定位到了。 在本地历史记录中，你明确写过“微信限制太多，做了一个 IM APP 接 claedbot”。这说明 browser / API 直连路线不是凭空出现的，而是为摆脱微信限制而开的分支方向。
本地工作树证据
改动目标也被定位到了。 scripts/im-demo-local.sh 中存在显式的 OPTIONS /v1/chat/completions 预检请求，带 Origin: http://localhost:3000， 并等待 204。这不是 Feishu 路径会用到的行为，而是本地浏览器 / IM demo 会用到的行为。
2026-03-10 阶段复盘
当前判断发生了变化。 你后来放弃了“自己做一个这样的入口”，转而使用现成入口和现成渠道。于是这批 CORS 代码虽然能工作，但不再直接支撑你的当前目标。

问题到底是什么

通俗说，它解决的不是“飞书发不过来”，而是“浏览器网页能不能直接调你本地 Gateway HTTP API”。

它实际解决了什么

  • 浏览器从 http://localhost:3000 一类 loopback 页面，直连本地 Gateway 的 /v1/chat/completions。
  • 浏览器从 loopback 页面，直连本地 Gateway 的 /v1/responses。
  • 处理 OPTIONS 预检，并在响应里回写允许的 Origin / methods / headers。

它没有解决什么

  • 不解决 Feishu 消息进 Gateway 的链路。
  • 不解决 OpenClaw 的远程控制核心能力。
  • 不解决模型能力、群路由、skills 隔离、安全策略这些主线问题。
  • 不自动带来更高的 upstream 合并概率，因为它的受众面窄。
Current Mainline vs Abandoned Side Path 当前主线 Feishu → Gateway → Agent / Tools → Remote machine control / existing workflow 这里不依赖浏览器 CORS。 已放弃的支线 Browser / IM App → Loopback Gateway HTTP API 这里才需要处理 loopback origin 的 CORS 预检。 当前 patch 的主要价值也集中在这里。
你后面产生的困惑，本质上来自“代码解决的是支线问题，但你现在问的是主线价值”。

为什么之前想做 后来又不想做

之前想做

  • 微信限制多，想绕开平台限制。
  • 希望自己掌控入口和交互方式。
  • 本地 IM / 浏览器页面直连 Gateway，会比受限平台更自由。

后来不想做

  • 各大厂商已经开放入口，你没必要再自己补一个完整入口层。
  • 现成渠道更快落地你真正想要的东西。
  • 你的持续使用路径已经变成了 Feishu 驱动，不再依赖本地浏览器入口。
所以不是“这段代码突然没价值了”，而是它服务的目标已经从当前主线目标里退场了。

如果不提交 不保留 会怎样

问题 答案 影响等级
如果不保留 CORS patch，会不会影响你现在的 Feishu 主线？ 按目前定位，不会直接影响。因为 Feishu 路径不需要浏览器从 localhost 直接调 Gateway HTTP。 低
如果以后又想做本地浏览器 / IM demo 呢？ 那时浏览器预检会再次成为问题，所以更合理的做法是归档而不是忘掉。 中
如果一直把它留在主工作树里呢？ 会增加和 upstream 的差异、抬高后续同步与解释成本，但不一定立刻炸主流程。 中

当前工作树 Keep / Drop / Review

Decision Matrix Drop from main worktree browser / loopback CORS 专用改动 Review separately timer env 化是否有真实部署收益 Keep on mainline Feishu 现有主流程相关逻辑不动 http-cors.ts openai/openresponses CORS 分支 server-constants.ts 若你确实需要调低后台探测频率，可单保留 Feishu 主链路相关配置与逻辑 这次不要顺手动
最重要的是只处理“浏览器支线残留”，不要顺带扰动你的 Feishu 主线。
文件 作用 建议 理由
src/gateway/http-cors.ts 新增 loopback origin 识别与 CORS header 处理。 回退主线 / 归档 完全服务于浏览器直连本地 Gateway 的场景，不是你当前主线必需。
src/gateway/openai-http.ts 给 /v1/chat/completions 加 CORS 分支。 回退主线 / 归档 价值点和上面一致，属于支线需求接线点。
src/gateway/openresponses-http.ts 给 /v1/responses 加 CORS 分支。 回退主线 / 归档 同样只对浏览器入口有意义。
src/gateway/openai-http.e2e.test.ts 验证 chat/completions 的 loopback CORS。 随 patch 一起归档 测试本身没问题，但如果主线不保留功能，测试也不该留在主线。
src/gateway/openresponses-http.e2e.test.ts 验证 responses 的 loopback CORS。 随 patch 一起归档 同上。
docs/gateway/openai-http-api.md / docs/gateway/openresponses-http-api.md 给浏览器 loopback CORS 写说明。 随 patch 一起归档 文档服务于同一支线，不该先于决策长期留在主线。
scripts/im-demo-local.sh 本地 IM / 浏览器 demo 的验证脚本。 归档 作为实验资产保留有价值，但不必占据主工作树核心位置。
src/gateway/server-constants.ts 让 tick / health refresh 间隔支持 env 覆盖。 单独评估 它和浏览器 CORS 不是一回事。如果你现实里确实需要降低后台探测频率，这是唯一可能还值得单独保留的部分。

理想状态应该怎么做

主线工作树

  1. 只保留和 Feishu 主流程、当前实际运行链路直接相关的改动。
  2. 把 Gateway browser/CORS 相关内容移出主工作树。
  3. 尽量回到“最接近你当前已 fetch 的 upstream/main”的状态。

实验资产

  1. 把 browser/CORS patch 保存成独立 branch 或 patch 文件。
  2. 保留 im-demo-local.sh 作为未来需要时的复活入口。
  3. 如果未来真要推 upstream，再基于明确共享痛点重做论证，而不是沿用当前私人动机。

我这次是怎么分析的

测试现状

这次我没有只停留在静态分析，还做了最小必要的定向验证。但我不会夸大成“全链路已经验证完毕”。

测试 结果 说明
./node_modules/.bin/vitest run --config vitest.e2e.config.ts src/gateway/openai-http.e2e.test.ts 通过 4/4 通过，包含新增的 loopback CORS 用例。
./node_modules/.bin/vitest run --config vitest.e2e.config.ts src/gateway/openresponses-http.e2e.test.ts 通过 4/4 通过，包含新增的 loopback CORS 用例。
node --import tsx 对 server-constants.ts 做 env smoke 通过 验证了合法值会覆盖默认值，非法值会回退到默认值。
pnpm test:e2e -- <files> 的第一次尝试 不作为结论 该命令意外把大量无关 e2e 也带起来了，噪音过大，因此不能作为这次局部改动的判断依据。
Feishu live workflow 未跑 这次没有去动你的实际 Feishu 运行环境，也没有冒然在 live 登录态上做扰动测试。
所以目前最真实的说法是：HTTP 两个入口的局部自动化验证已通过；Feishu live 主线尚未在“回退 browser patch 之后”做回归验证。

如果现在要安全回到接近官方 应该怎么测

Verification Staircase 1. 先归档 browser patch 2. 定向跑 gateway 自动化测试 3. 启动本地 gateway 验证能正常起 不依赖 browser CORS 4. Feishu smoke 收消息 发消息 执行 1 个常用动作 5. 再观察 日志 session health 24h
你不需要一上来就跑全套 live 测试，先把验证分层，才能既稳又快。
层级 测试用例 目标
自动化 / 局部 Gateway HTTP 相关 e2e；如果保留 server-constants.ts，再补一个真正的单测。 确认改动面内的行为清楚、可复现。
启动 smoke 本地启动 Gateway，看是否能正常监听、认证、返回健康信息。 确认没有因回退 browser patch 导致服务本身起不来。
Feishu smoke 发一条普通消息；看是否回复；再执行 1 个你常用动作。 确认当前实际主流程无回归。
观察期 看日志、health、session 行为、报错率。 避免只验证“瞬间可用”，忽略延时问题。

当前最好的建议

建议保留

  • 这次调查结论本身，以及与其对应的证据链。
  • browser/CORS patch 的归档副本，用于未来万一重启本地 IM / browser 方向。
  • server-constants.ts 的 env 化改动，但前提是你现实里确实需要它。

建议回退

  • 所有仅服务于 loopback browser CORS 的主工作树改动。
  • 相关 docs 与 e2e case，如果主线不再保留该功能。
  • 把 scripts/im-demo-local.sh 从主线心智里降级为“归档资产”。
最稳的方案不是“完全照官方但什么都不留”，而是主线贴近官方 + 实验资产单独封存。

下一步行动计划

  1. 把 browser/CORS 相关文件做成独立 patch 或独立 branch，先保留资产，再从主工作树移出。
  2. 单独决定 server-constants.ts 留不留；如果留，建议补 1 个真正的自动化测试。
  3. 回退完成后，先跑局部 Gateway 自动化测试，再做本地 Gateway 启动 smoke。
  4. 最后只做最小 Feishu smoke，不去一次性全量折腾 live 环境。
  5. 等主线稳定后，再重新找真正适合 upstream 的贡献点，例如 parser bug、CLI bug、Feishu/skills 隔离这类共享痛点。
阶段性结论不是“否定之前的尝试”，而是把它放回正确的位置： 它更像一个已经完成历史使命的实验分支，而不是你现在最值得继续推进的主线贡献点。
阶段性结论：当前未提交的 Gateway CORS 改动解决的是本地浏览器直连 loopback Gateway 的预检问题，来源于已放弃的 IM APP 方向；它不是现行 Feishu 主线的刚需，最佳动作是归档 browser patch、单独评估 timer env 化改动，并在不碰主线下回到更接近 upstream 的状态。
— One small system