trafly

借楼分享一下我日常在 macOS 上作为主力生产环境跑的本地多 Agent 智能路由与能力网关方案，给折腾本地 Agent 协同的同学一点参考。

很多同学做本地 LLM 接入，习惯直接起一个 LiteLLM 或 Ollama 端口供所有客户端调用。但在多 Agent 混用场景下（我日常混用 Cursor 、Codex CLI 、DSH 、Claude Code ），单层代理有几个痛点：跨厂商 Thinking 泄漏导致上下文雪崩、缺少本地/云端动态裁决、没有统一的本地记忆与能力挂载。于是做了"8081 （决策与能力网关）+ 8082 （模型聚合底座）"双层解耦。

一、架构拓扑

客户端：Cursor / Codex CLI / DSH / Claude Code 等。

127.0.0.1:8081 （ FastAPI 决策与能力网关）：macOS launchd 守护常驻。职责是出站安全守门 + JEV 语义分流 + 系统级 Capability 挂载 + 协议抹平。根路径 /{path:path} 未命中自研端点时，全量透明反代到上游 8082 。

127.0.0.1:8082 （ LiteLLM Proxy 模型底座）：只做 upstream 连接池与跨厂商模型聚合，承接几十个国内外模型渠道。

周边：1234 端口 LM Studio （ 4B 做路由裁决，14B 做本地代码生成）； 8083 端口本地 Qwen3 Embedding 向量记忆服务。

二、核心设计

1. JEV 双引擎动态分流：对外只暴露 hybrid-auto （强制本地）、hybrid-auto-cloud （允许云端）等别名。请求进 8081 后：先过硬规则（数据出站策略 + 真实附件检查，不用正则/关键词瞎猜），再调本地 4B 模型做强类型语义裁决（结构化 choice 输出），短问答/私密代码/简单修改下发本地 14B ，架构设计或高难任务才转云端（ 8082 上的 DeepSeek/Claude 等）。

2. 治理 Thinking 污染：很多模型/渠道会返回 <think> 或 reasoning_content ，部分兼容层会把思考过程当正文反复回传，导致上下文爆炸或复读死循环。8081 在回调层统一清洗，对外只吐干净正文。

3. 系统级 Capabilities：/capabilities/vector_search 查本地向量库（只读）；/capabilities/web_search 聚合 Firecrawl / Tavily / Brave 多源回退；另有原生视觉端点。各 Agent 只需对接网关，不用重复造工具链。

4. 原生多模态铁律：早期试过网关层 OCR 图片转文字再喂纯文本模型，极易破坏 Prompt 结构、搞乱 Agent 上下文。现在铁律是只走原生 Vision ，非多模态模型不做伪装转换，上游如实报错。

5. 声明式配置 + 自动回滚：渠道配置拆成 providers/*.json ，启动时编译成最终配置并做健康检查；供应商改 API 协议导致配置失效时，自动回滚到上一版备份。手改 YAML 缩进翻车过几次，保命必备。

三、踩坑两条

1. 网关必须双协议：Claude Code 默认走 Anthropic /v1/messages ，OpenAI 系走 /v1/chat/completions ，网关层做好映射和 stream 转换才能多客户端通吃。

2. 小模型做裁决，不做主力：3B/4B 本地模型判意图/难度/隐私级别几乎零延迟，把重活分给云端强模型或本地 14B/32B ，整体体验远好于一刀切。

@JingW 和 Bot 们说好，活我可以不干，钱记得分我

1)Grok Bot:今天你歇着，脏活我接着盯。;
2)MUSE:0day 可以明天再修，今天先过节。;
3)Chatgpt:今天让 bug 休假，让灵感加班。;
4)DeepSeek:今天是 2¹⁰ 的好日子，希望你的代码一次通过、依赖不掉链子、构建一直走在对的分支上。

@BlueSkyXN 是的，成果和案例很关键，光讲方法很难说服企业。我过去的 ToB 经历不能直接当成 AI 项目的成绩，这部分需要在具体项目里积累。不过，我之前梳理过一套方法，也研究了一些产业数字化上市企业的 AI 落地案例，可以作为场景选择和试点设计的参考。这些是案例研究，不是我自己的交付成绩。

涉及跨部门、改流程的项目，往往需要一把手支持，和 CEO ／董事长之间的信任也很重要。所以我更希望先从一个小场景做起，把问题和验收标准说清楚，做出结果再谈下一步。

不同行业差异很大，还得和熟悉行业、客户业务的伙伴一起做。我觉得 AI 落地未必比数字化轻松，数据、流程和人员配合都需要磨合。不必等全公司的数据都标准化，但至少要确认试点涉及的数据和流程具备条件。

看了楼里的讨论，我最近在整理“企业 AI 化十节点”这套判断框架。里面的节点 0 ，不是先问企业想不想上 AI ，而是看业务对象和数据基座有没有成形：对象能否稳定记录，字段和规则是否相对统一，流程经验能否复用。

我在想，做 FDE 项目时，需求梳理是不是也得往这一步追：客户说要做 Agent ，背后的业务对象、数据口径和处理规则到底清不清楚？如果还不清楚，可能要先补基座，或者把试点范围压到低风险辅助，而不是直接把 Demo 跑通当成落地。你们实际项目里，通常怎么判断这个边界？

@BlueSkyXN 找项目合作，不是招同事。我目前是独立做事，希望认识有企业客户或具体项目的技术团队。我参与需求梳理和试点设计，开发实施由对方负责，具体按项目商量分工和费用。

小心哦，合并后的 cursor 是默认不带第三方 LLM 额度的，需要购买 API 额度

这个挺逗的，我做了一套暹罗猫，一套黑猫的。免费的。