企业官网建设流程全解析

开头：一个"要不要搞"的决定，比"怎么搞"更难

前面四篇，我把 AI 网关"是什么、差在哪、怎么流转、面对多协议有多乱"讲了一遍。到这里，很多人会冒出一个更现实的问题：“道理我都懂了，但我们团队真要上一个 AI 网关，到底该怎么选？自己写？拿开源的改？还是花钱买现成的？”

我可以很负责任地说：这个"选哪条路"的决定，往往比"网关怎么实现"更难，也更值钱。因为技术实现是可以抄作业的，但选错路线带来的返工、锁定、维护负担，是要团队用真金白银和时间去还的。

这一篇，我把我们团队当时的决策过程完整复盘出来——不是告诉你"应该选哪个"（这得看你的具体情况），而是给你一套判断框架，以及我们踩过的、让你能少走弯路的坑。

先说结论，再展开：我们最终选了"开源改造"这条路。但这不是标准答案，下面你会看到我们为什么这么选、以及这条路值不值得你走。

二、先把三条路的本质讲清楚

很多人对这三条路的理解停留在"自己写 / 改别人的 / 买现成的"，但真正影响决策的，是它们各自背后完全不同的投入结构和风险结构。我把它们摊开讲。

路一：自研——从零写一个网关

本质是：你自己把一个"能承接、转发、治理 AI 请求"的网关从头写出来。

这条路最大的诱惑是"完全可控、没有包袱"。但代价藏得很深：一个 AI 网关要真正能上生产，你要自己解决的东西远不止"转发一个 HTTP 请求"——流式响应怎么处理？高并发下怎么保证稳定？协议转换怎么做对？插件怎么组织？监控日志怎么接？这些东西单拎出来每个都不难，但攒到一起，就是一个巨大的工程黑洞。

很多人对自研的理解是"写个转发代理"，但真正会把你拖垮的，是那些"看起来不重要、上线才发现是命门"的部分：流式 SSE 的边收边发、连接超时与重试、背压、异常时的资源回收。这些我后面几篇会专门讲，这里先埋个伏笔。

路二：开源改造——拿一个成熟底座，做 AI 化改造

本质是：选一个已经解决了"网关底层问题"的开源项目，你在它之上，只做"AI 相关的增量"。

这条路的关键判断是：一个 AI 网关里，"AI 能力"只占一小块，剩下 90% 是传统网关早就在做的事——路由、鉴权、限流、负载均衡、插件体系、高并发、可观测。这些你没必要重写，也写不过那些经过大量生产验证的开源项目。

所以"开源改造"的真实含义是：把 90% 的底座交给开源，把 10% 的 AI 增量自己做。你聚焦在协议识别、提示词治理、token 限流、模型路由这些"AI 专属"的东西上。

路三：买商业方案——直接用厂商现成的

本质是：付费使用厂商提供的 AI 网关产品（SaaS 或私有化部署），你只管用，不管实现。

这条路最大的优势是"快"和"省心"——能力现成、有人维护、出问题有人兜底。但代价是控制力的让渡：定制能力有限、依赖供应商的迭代节奏、数据要过别人的手、以及——锁定。一旦你的业务深度绑定某家厂商的特定能力和接口，想换就难了。

三、决策框架：别拍脑袋，先问三个问题

看完三条路，你可能会更纠结。所以我给你一个我们当时用的框架——先回答三个问题，答案会自动把你推向某一条路。

问题一：你要解决的，到底是"能力问题"还是"成本问题"？

这是最容易被混淆的一点。

• 如果你要的是能力（多模型统一接入、提示词治理、token 级成本控制），那你需要的是一套完整的能力体系，自研的性价比极低，商业方案或开源改造更合适；
• 如果你要的是成本（单纯想把多家的 API 费用管起来、做个统一入口），那需求其实很薄，甚至可能不需要"网关"，一个轻量的代理层就够了——别为了一个薄需求上重型方案。

问题二：你们团队，有没有"改得动底层"的人？

开源改造这条路，对团队有个硬门槛：你至少要有一两个人，能读懂网关底层的执行模型、会写它的插件、能定位并发和流式的问题。

如果没有这样的人，“开源改造"会变成"开源但改不动”，最后要么退回自研（更糟），要么发现还不如直接买商业方案。这条路的核心成本是"人"，不是"代码"。

问题三：你的需求，和主流方案的重合度有多高？

如果你要的 AI 网关，就是"主流能力"（统一接入、限流、路由、观测），那商业方案和开源改造都能覆盖大部分，你的定制量很小；

但如果你的需求里有很偏门的东西（比如某种特殊的协议、特殊的计费规则、和内部系统的深度耦合），那商业方案大概率满足不了，你会被迫走向自研或开源改造——因为只有这两条路给你"改到内核"的自由。

四、我们当时怎么选的：完整复盘

交代完框架，回到我们的真实决策。

我们的情况是这样的：

第一，我们要的是"能力"，不是单纯"省成本"。团队的核心诉求是：让内部几十个业务方，用一个统一入口接不同的模型，并且能统一治理提示词、统一按 token 控成本。这不是一个"薄需求"，而是一套能力体系。→ 这一步，基本排除了"纯自研一个转发代理"的选项。

第二，我们团队有能改底层的人。团队里有熟悉网关底层执行模型、能写 Lua 插件、能啃源码的人。这让我们敢走开源改造这条路。→ 这一步，让"开源改造"从"理论上可行"变成了"现实可选"。

第三，我们的需求，有一部分很"偏门"。比如我们要做一套"纯 Lua 实现的 token 计数"，要对齐某个特定模型的 token 算法，还要和内部的提示词模板体系深度耦合。这些是商业方案给不了、也不该要求厂商为我们定制的。→ 这一步，把"买商业方案"从"首选"降成了"备选"。

综合下来，我们的答案是：基于一个成熟的开源网关做底座，把 AI 相关的能力作为"增量"改造上去。

这个选择还有两个附加原因：

• 掌控演进节奏：AI 领域变化太快，模型协议、能力形态几个月就变一次。商业方案的迭代节奏是厂商定的，我们等不起；自研又追不上变化。开源改造给了我们"自己决定什么时候上什么能力"的主动权。
• 数据与合规：我们的请求数据、提示词模板、成本数据都不希望离开自己的环境，私有化部署是硬要求。这一点，商业 SaaS 直接出局，剩下的是"私有化商业方案"和"开源改造"之争，而前者又回到"定制受限 + 锁定"的老问题。

五、踩坑与边界：每条路的真实代价

选型文章最容易写成"三条路各吹各的好"，但真正值钱的是每条路埋的坑。我把我们亲历的、以及调研中确认的坑，摊开讲。

自研的坑：你以为在写"网关"，其实在重写"网络库"

自研最大的幻觉，是以为"网关 = 转发"。等你真正动手，会发现流式 SSE 的边收边发、连接复用、超时重试、高并发下的稳定性、内存和文件描述符的回收……这些全是传统网关用多年血泪换来的东西，你要从头交一遍学费。

我们调研时看到太多"自研网关"最后退化成"一个只能跑通 demo 的转发脚本"，一到高并发或流式场景就崩。自研只适合一种情况：你的需求极其简单、且确定不会长大。

开源改造的坑：改上去的东西，成了"升级的债"

这是我们现在正在还的债，也是最需要提醒你的。

开源改造的本质是"在别人的代码上打补丁"。这个补丁打上去容易，但上游版本一升级，你的补丁就可能失效，甚至冲突。我们踩过的真实场景是：上游发了一个新版本，我们改造过的某个插件，因为底层接口变了，升级后直接不工作，排查了整整两天。

所以走这条路，从一开始就要想清楚"改造点怎么跟上游共存"：尽量把改造做成"独立插件"而不是"改动内核"，尽量往上提、少往下钻。这个教训，我后面讲架构设计（第 6 篇）时还会再展开。

买商业方案的坑：三个字——“改不动”

商业方案的坑，概括起来就是"改不动"：

• 定制能力受限：厂商给的是"标准能力"，你偏门的需求它不给做，或者要做就单独报价、单独排期；
• 迭代节奏被锁：AI 协议变了，你只能等厂商适配，你不能自己先上；
• 私有化的隐性成本：私有化部署看似解决了数据问题，但你要自己负责它的运维、升级、故障兜底，这部分的隐性成本经常被低估。

买商业方案只适合一种情况：你的需求高度标准、团队没有改底层的人、且能接受"跟着厂商节奏走"。

六、一张决策树，帮你快速定位

把上面的框架和坑，收成一张决策树，你照着走一遍，大概率能定位到自己该走哪条路：

这张图想传达的核心其实只有一句话：选型不是"哪条路更好"，而是"你的约束条件把你推向了哪条路"。团队有没有人、需求标不标准、能不能接受被锁定——这三个约束，比任何"三条路优劣对比"都更接近真相。

结语

这一篇，我把 AI 网关选型这个"最难的决定"拆开了：三条路的本质是三种不同的投入/风险结构，而真正决定你走哪条的，不是路本身的优劣，而是你的三个约束——要能力还是要省钱、有没有改底层的人、需求标不标准。

我们最终选了"开源改造"，因为它同时满足了我们的能力诉求、团队禀赋和偏门需求，也给了我们掌控演进节奏和数据主权的自由——代价是"改造点成了升级的债"，这个债我们正在还，后面几篇你都能看到它在具体场景里怎么还。

下一篇，进入真正的架构设计：一个"数据面 + 控制面"分离的网关，为什么几乎成了 AI 网关的标配？我会讲清楚这个分离到底解决了什么问题、以及我们在落地时踩过的坑。