我自己做 B2B GTM 与战略营销，平时几乎所有工作流都挂在 LLM 上。大家都在晒各种复杂的 Agent ，但我发现自己真正在主力跑、每天离不开的，其实是一套跑在 MacBook Pro 上的[b]个人 AI 网关[/b]。
它现在接管了我本机全部的 LLM 调用——Cursor 、Codex CLI 、Claude Code ，还有我自己的 Agent 内容管线。
[size=5]为什么要做[/size]
2026 年中，我的调用环境彻底失控了：手头十几个模型订阅和 API Key （ DeepSeek 、NVIDIA NIM 、DashScope 、Gemini 等），各个客户端和脚本直连模型，endpoint 写死在代码里。结果就是每个月都在焦虑额度，钱花在哪儿完全是一笔糊涂账。
问题不在模型，在调用失控。我要的其实就三样：
[list]
[*][b]一个入口[/b]：所有客户端只配一次；
[*][b]路由智能[/b]：打杂分诊走便宜的本地小模型，硬骨头再上顶级云端模型；
[*][b]全程可审计[/b]：每次调用留痕，哪个渠道挂了随时无感替换。
[/list][size=5]架构[/size]
[img]https://i.v2ex.co/Rd6YgOGz.png[/img]
[list]
[*][b]:8081 —— 决策网关（自研）[/b]：FastAPI 服务，launchd 守护进程。在请求真正碰到模型之前干五件事：出站安全守门、本地语义路由（判断这次该走哪个模型/渠道）、系统级工具能力挂载、跨渠道协议抹平，以及清洗 <think> 与 reasoning_content（治理 thinking 污染，不让推理过程漏进下游上下文）。如果本地没有命中自研端点，就把请求全量透明反代给 :8082。
[*][b]:8082 —— 聚合底座[/b]：LiteLLM Proxy ，挂着几十个国内外模型渠道（ DeepSeek 官方、NVIDIA NIM 、DashScope Coding Plan 、Gemini 等）。渠道配置是声明式的 providers/*.json，启动时编译，带健康检查和失败自动回滚。
[*][b]:1234 —— 本地模型[/b]：LM Studio ，4B 模型做路由裁决，14B 做本地代码生成。
[*][b]:8083 —— 本地向量服务[/b]：本地 Qwen3 Embedding 向量记忆服务。
[/list][size=4]8081 路由流程[/size]
[img]https://i.v2ex.co/PWXI84Zl.png[/img]
[size=5]管我一天的两个别名[/size]
平时在各个客户端里，我主要就切这两个模型别名：
[list]
[*]hybrid-auto —— [b]强制本地[/b]。分诊、起草、敏感内容不出本机。
[*]hybrid-auto-cloud —— [b]允许云端[/b]。硬问题交给顶级云端模型。
[/list]另外有一条铁律在网关层强制执行：[b]只走原生 Vision[/b]。模型本身不是多模态的，绝不用转换层伪装。
[size=5]实际运行数据[/size]
这套网关不是 Demo ，是我的日常主力。四个客户端每天的所有请求，都要过 :8081 的路由、安全守门和 <think> 清洗，才到得了模型。
我的 Agent 内容管线（ LLM API + Python + Agent 工作流）全跑在上面，把我的内容生产周期缩短了 60%，每周产出 30+ 篇 AI 相关内容。2026 年 8 月，仅我个人 DeepSeek 面板单月就有 [b]25,896 次请求、约 17.06 亿 tokens[/b]。这个量级如果没有网关收口，基本就是裸奔。
[size=5]踩过的坑[/size]
列一份诚实的踩坑清单：
[list]
[*][b]两个端口根路径都是 Swagger UI[/b]：我曾花了一个下午排查为什么访问 :8081 的根路径会返回 :8082 LiteLLM 的 Swagger UI ，后来才想起来——未命中路径全量透明反代，是我自己设计的。现在它写进了文档的已知行为，不再是谜。
[*][b]渠道配置静默失败[/b]：早期 providers/*.json 的编译步骤对畸形渠道配置是静默失败的，导致陈旧路由继续在线。直到有一次坏配置黑洞掉我一晚上的 Agent 任务，我才把启动健康检查和自动回滚加上。
[*][b]Thinking 污染[/b]：在网关加上 <think> 清洗之前，上游模型的推理 trace 会漏进下游 prompt ，用一种很隐蔽、极难追踪的方式拉低输出质量。最后在回调层加了清洗器解决——真正的教训是，多模型串联时居然还有这类隐蔽 bug 。
[*][b]/capabilities/* 端点还在建[/b]：核心链路（路由、守门、聚合、清洗）已经稳定跑着，扩展的能力端点面是下一步。先跑起来解决问题，再慢慢补全。
[/list][size=5]下一步[/size]
短期先把能力端点面补完，加上按渠道的单次请求成本归因——“哪个模型值”要用账本数据回答，不用体感。
长期我在看业界怎么把这一层产品化。比如 DeepSeek Harness 团队刚开源了 dsh-superagent（ MIT ），事件驱动的 Agent bundle ，思路看起来像我这套个人网关的商业版亲戚。个人网关是个原型，更有意思的问题是：面向团队的托管版应该长什么样？
如果你也在本地跑多客户端、多渠道的 Agent 工作流，建议先做调用审计。你看不见流量的地方，是没法做路由的。欢迎交流各自的网关方案。
⚠️内容来自互联网，如有侵权请点击反馈！侵权投诉