我终于把上周说的AI Native团队跑通了。。创业复盘：2026 年怎么做 AI Na...
现在团队所有人进到一个入口用AI，里面内置的多个助手
背后都统一在我Gateway上运行，可能调用Codex的 $computer-use 和 @chrome去抓reddit和亚马逊数据；可能通过sub2api用我的GitHub Copilot，里面有Claude Opus4.7；可能通过飞书cli处理文档。。。
并且，所有跟AI的对话过程，全部写进一个 Postgres，加上飞书里的工作讨论内容，每周清洗一次进知识库。下一周再问 AI，AI 是基于公司自己的最新经验回答的。
这套系统叫 NGS AI Center Gateway，从架构设计到能跑通，我用了 6 天，全部 Claude Code 写。中间替我顶住最长那一段架构推演和 8 小时长程任务调度逻辑的，是刚发的千问 3.7-Max。
千问3.7-Max发布，位列国产模型第一
接下来完整给大家复盘一下：
第一，为什么我非要自己造一个 Gateway，不直接用现成的
第二，完整架构、docker-compose、Codex Adapter 代码、提示词模板，开箱即用！
第三，千问 3.7 在这次开发里到底干了什么活，凭什么我说它现在是国内做 Agent 项目的首选底座。
01
先说为什么这事卡在 AI 层
我之前在公司分享过一个观点：AI Native 公司不是工具多，而是工具之间能互相递话。
我们之前是典型的 AI-enabled——只是传统公司很会用AI
导致有三个问题，每个都让我难受很久：
第一，公司在烧钱给 OpenAI、Anthropic、Google，但没有任何东西留下来。员工昨天跟 ChatGPT 聊了 2 万字想清楚一个营销策略，今天另一个员工接手这个项目，得从零开始问。所有交互都是一次性的，用完就扔。
第二，AI 看不到公司的真实上下文。我让 AI 帮我判断「这个 Reddit 帖子值不值得回复」，它不知道我们之前在哪些 subreddit 被删过、哪些回复带来过转化、哪些表达被认定为广告味。它的判断只能基于通用知识，不基于 NGS 的经验。
第三，订阅成本失控。我个人订了 Claude Max、ChatGPT Pro、GitHub Copilot、Antigravity，公司账号还订了 Cursor、Codex、Gemini。员工想用，要么共享账号容易封号，要么各自再订一份。一个月光 AI 订阅就 1 万多。
这三个问题指向同一件事：公司缺一个 AI 层的统一入口。
不是缺工具，是缺一个把所有 AI 能力收口、把所有员工 Prompt 留存、把所有订阅账号复用、把所有数据回流到本地知识库的中间层。
这就是 NGS AI Center Gateway 要解决的事。
02
千问3.7：为什么这次我没用Claude Opus做主力
进入教程之前要先声明一下，这个项目我是用 Claude Code 写的，但 Claude Code 背后接的模型是阿里刚发的千问 3.7-Max。
为什么？
第一，千问 3.7 在 Terminal Bench 2.0-Terminus 上拿到 69.7 分，超过了 Claude Opus 4.6。这个 benchmark 测的是模型在终端环境里独立完成多轮工具调用任务的能力。
而我这次的活儿——Gateway 的 docker-compose 编排涉及 7 个容器、4 组相互依赖、macOS 下的 NAS 卷权限处理，千问 3.7 直接把 healthcheck、depends_on、condition、volume permission 全配对了，没让我查任何官方文档。
第二，千问 3.7 跑了一个让我有点震撼的实验：在平头哥真武 M890 这块全新芯片上，没有任何性能分析数据、硬件文档或示例代码，只给一个任务描述和评测脚本，模型自己持续编程 35 小时，独立进行了超过 1000 次工具调用，最后写出来的内核比 SGLang Triton 官方参考实现快 10 倍。运行到 30 小时还能发现新的优化点，甚至主动重设计架构。
千问3.7-Max可独立执行35小时的长程复杂任务
对应到我的活儿，这个长程任务能力直接让 Codex Adapter 那段 800 行的协议翻译可以一次性出。Sonnet 4.6 我试过同样的提示词，能写但需要分 4 段喂上下文；千问 3.7 一次性把 OpenAI chat completions 协议跟 Codex app-server 的 Thread 协议双向翻译写完了，partial chunk 处理逻辑也是对的。
第三，千问 3.7 在 Claude Code、OpenClaw、Qwen Code 三个框架下都能稳定跑，泛化能力出来了。
对应到我的活儿——我不用换工具，继续在 Claude Code 里写，只在 settings 里把模型 endpoint 换成阿里云百炼，整个开发体验跟以前用 Sonnet 没区别，但成本只有 Claude Opus 的 1/5。
OK，接下来，正式上教程。
03
先说架构：员工开箱即用，但背后都是业务流程
整套系统的设计原则就一条：员工只感知一个入口，所有 AI 能力在背后通过一个 Gateway 统一调度。
text
员工电脑 / 浏览器 ↓ Open WebUI (:3000) ← 唯一入口 ↓ OpenAI 兼容协议 NGS Gateway (:8000) ← 自研路由大脑 ├── Codex Host Bridge (:8765) → 本机 Codex / Reddit / 飞书 / 文件 ├── Seedance / ModelArk (:4100) → 视频生成 ├── Sub2API (:8088) → 把订阅服务转 OpenAI 协议 ├── Postgres (:54330) → 任务、Prompt、返回结果全量日志 ├── Redis (:6390) → 队列和缓存 └── NAS / storage → 上传、输出、知识库资产
Gateway 整体架构
员工在 Open WebUI 看到的是 8 个助手：
text
ngs-text → 日常对话/写文案，走 Sub2API 跑 Copilot 算力 ngs-reddit-research → Reddit 深度调研，走 Codex + computer-use + chrome ngs-file-assistant → 读写 NAS 文件，走 Codex ngs-feishu → 飞书协作，走 Codex 调飞书 OpenAPI ngs-image → 生图，走 Codex 内置 imagegen skill ngs-seedance-video → 视频生成，走 Seedance ngs-sub2api → 直连订阅池，给开发者用 ngs-knowledge → 公司知识库问答，走本地 RAG
员工不知道下面哪个走 Codex 哪个走 Sub2API，也不用知道。他只需要在 Open WebUI 下拉选模型，发消息，等结果。
下面这张图是员工实际看到的界面：
员工端 Open WebUI 助手列表
下面这张图是 Gateway Admin 后台，能看到当前所有助手的调用次数、平均耗时、token 消耗：
Gateway Admin 后台监控
下面把 Gateway 的三层能力拆开讲。这三层不是平行的功能模块，是一条递进链：先把分散的算力收口、再让算力能真正做事、最后让做完的事变成公司资产。
Gateway 三层能力的认知递进
04
第一层：我订一份 Copilot，让全家都用上了Claude
先解决最便宜的问题：算力。
有个工具叫sub2api，能把订阅服务（GitHub Copilot、Antigravity、Cursor）的客户端调用，伪装成标准 OpenAI API 协议，让你能在任何支持 OpenAI 接口的地方调用。
我订一份 GitHub Copilot，原本只能在 VSCode 里用。接上 sub2api，团队所有人都能在 Open WebUI 里调到这份 Copilot 算力，背后跑的是Claude
在 Gateway 的 docker-compose 里 sub2api 这一段长这样：
yaml
sub2api: image: your_sub2api_image ports: - "8088:8080" environment: - COPILOT_TOKEN=${COPILOT_TOKEN} - ANTIGRAVITY_TOKEN=${ANTIGRAVITY_TOKEN} volumes: - ./storage/sub2api:/data
环境变量在 .env 里：
bash
SUB2API_BASE_URL=http://sub2api:8080 SUB2API_API_KEY=Sub2API管理端生成的key SUB2API_DEFAULT_MODEL=gpt-4o COPILOT_TOKEN=xxxx
Gateway 的路由层判断：如果员工选的是 ngs-text 助手，请求直接打到 sub2api。结果就是公司日常文本任务的算力成本接近零——本来就订了的服务，多几 个人用而已。
省下来的钱不少。假设8 个人各订 ChatGPT Pro 一个月 1600 块，现在合并成一份 Copilot 订阅 + Sub2API，月成本压到 200 以内。
划重点：Codex、GitHub Copilot、Antigravity 现在都支持第三方登录，也可以直接登录到 Gateway 端，统一调度。不一定要走 sub2api 这条路。
但光省钱不够。员工要的不是「能问 AI 问题」，是「AI 能真的帮我把活干完」。这就要进入第二层。
05
第二层：让 AI 真的去打开 Chrome 抓 Reddit，而不是用过时数据糊弄我
这一层是整个 Gateway 里技术含量最高的部分，也是千问 3.7 帮我顶下来的部分。
需求是这样的：员工选「NGS-Reddit调研助手」，发一句「帮我看 r/dropshipping 这周最热的 5 个帖子，把用户痛点提炼成飞书文档」。
普通模型做不了这事。它要么用过时的训练数据回答，要么连不上 Reddit。我需要的是：模型真的去打开 Reddit 浏览器，真的抓页面，真的看实时数据。
这就要用到 Codex app-server 的 computer-use + chrome 能力。Codex CLI 内置一个本地 Chrome 控制器，模型可以发指令让 Chrome 打开页面、滚动、点击、截图、读 DOM。
问题是 Open WebUI 只懂 OpenAI 协议，Codex app-server 走的是自己的 Thread 协议。中间需要一个 Adapter 做协议翻译。
Adapter 大概结构是这样：
python
# adapters/codex_adapter.py class CodexAdapter: def __init__(self, codex_server_url: str): self.codex_url = codex_server_url async def chat_completion(self, request: ChatRequest): # 1. 把 OpenAI 的 messages 转成 Codex Thread thread = await self.create_thread( system=request.system_prompt, workspace="/Volumes/home/AI Center/reddit-research", tools=["computer-use", "chrome", "feishu-api"], ) # 2. 把用户最后一条消息作为任务下发 task_id = await self.submit_task( thread_id=thread.id, instruction=request.messages[-1].content, max_steps=50, ) # 3. 流式读取 Codex 的执行日志，转成 SSE 给 Open WebUI async for event in self.stream_events(task_id): yield self.codex_event_to_openai_chunk(event)
关键的难点在 codex_event_to_openai_chunk 这一步。Codex 的事件类型有 20 多种：tool_call_started、tool_call_finished、screenshot_taken、file_written、thread_completed……每一种都要映射到 OpenAI 的 delta 结构里，否则 Open WebUI 会卡住或乱码。
我让千问 3.7 一次性把这张映射表写完了。Claude Code 的提示词大概是：
text
任务：实现 Codex app-server 事件到 OpenAI chat completions SSE chunk 的双向转换器。 要求： 1. 处理所有 Codex 事件类型（参考 codex-app-server v0.4 SDK） 2. tool_call 转成 OpenAI 的 function_call delta 3. 浏览器截图转成 markdown image link，路径写到 NAS 4. 长任务（30分钟+）保持 SSE 心跳，避免 Open WebUI 断连 5. 错误事件转成 OpenAI 的 error chunk，包含 error.code 和 error.message 输入：codex-app-server 的 event stream（参考 codex_events.proto） 输出：SSE 格式的 OpenAI chunk stream 要求一次性产出完整代码，不要伪代码。
千问 3.7 一次返回了 800 多行可跑通的转换器。中间有一处对 streaming tool_call 的处理我修了一下（它默认把 partial arguments 合并到最后一条 chunk，但 Open WebUI 需要 partial delta），其它全过。
跑通后的效果是：员工在 Open WebUI 输入「调研 r/dropshipping」，几秒钟后看到 Chrome 自动打开了，截图实时显示在对话窗口里，模型一边滚动一边总结。10 分钟后给一份完整的 Markdown 报告，自动存到 NAS 并生成飞书文档链接。
同样的链路可以做亚马逊选品调研、Shopee 竞品分析、TikTok 热门视频抓取。只要换 prompt 里的目标站点，Codex 就会用 computer-use 真的去那个站点抓。
但 Codex 跑完一次就走了。员工下周问同一个 subreddit，Codex 还是从零开始抓、从零开始想。这就要进入第三层。
06
第三层：每条对话进 Postgres，第八周 AI 就能看懂 NGS 在干什么
这一步是整个 AI Native 闭环里最关键的一环，但也是最容易被忽略的。
Gateway 中间件层加了一个 logger，在每个请求进来和返回时都拦截一次：
python
# gateway/logger.py @app.middleware("http") async def log_ai_interactions(request: Request, call_next): if not request.url.path.startswith("/v1/chat"): return await call_next(request) req_body = await request.body() req_id = str(uuid.uuid4()) # 异步写入，不阻塞主流程 asyncio.create_task( save_request(req_id, request.headers.get("x-user-id"), req_body) ) response = await call_next(request) # 流式响应也要落盘 response.body_iterator = log_response_chunks(req_id, response.body_iterator) return response async def save_request(req_id, user_id, body): await db.execute( """ INSERT INTO ai_interactions (id, user_id, assistant_id, prompt, created_at) VALUES ($1, $2, $3, $4, NOW()) """, req_id, user_id, parse_assistant(body), body )
每条对话都会落到 Postgres 的 ai_interactions 表，字段包括用户 ID、用的哪个助手、完整 Prompt、完整返回、调用的工具、消耗的 token、执行时间。
这些数据本身没价值。有价值的是每周一跑的清洗任务：
text
每周一凌晨 2:00 → 读取上周所有 ai_interactions → 按助手类型分桶（Reddit 调研归 Reddit 桶，飞书任务归飞书桶） → 调用 Codex 跑清洗 prompt： 「从这批对话里提炼出 NGS 的可复用知识： 1. 用户高频问的问题 + 满意的回答模板 2. 被否定的回答（用户追问 / 反驳的） 3. 工具调用失败的场景 + 失败原因 4. 涉及的具体公司内部数据（项目名、客户名、SOP 编号）」 → 输出结构化的知识条目 → 写入 NAS 的 /knowledge/ 目录 → 自动同步到 RAG 向量库
下一周员工再用 AI，RAG 会先检索一次本地知识库，命中的内容拼到 system prompt 里。这就是「越用越好用」的真实闭环。
第一周可能 RAG 命中率 5%，第四周到 30%，第八周到 60%。员工感觉到的变化是：以前问 AI 一个项目，AI 说「请提供更多上下文」；现在问同样的问题，AI 直接说「这个项目是 3 月启动的 Cecilia 出海项目，DRI 是 X，上次 SOP 提到的禁用表达包括 A、B、C」。
没有回流的 AI 是高级一次性筷子，有回流的 AI 才是公司资产。 这是 Gateway 三层里最不显眼但最关键的一层。
NGS 数据飞轮：越用越好用
07
这才刚开始
Gateway 跑通只是把员工的 AI 交互收口了。未来衡量公司效率的指标会从「人数」变成「token 使用量」。
这句话的真正意思不是疯狂烧 API。是：公司产能不再只来自员工人数，而来自员工背后能调动多少智能资源。
Gateway解决了「员工 → AI」
接下来重头戏在：公司核心信息 → AI。
飞轮一旦转起来，就停不下来了。
这才是 AI Native 公司真正的开始。
如果你想复现的话，直接把我这边文章扔给Claude Code+Qwen3.7 就好了！！
