3 篇博文 含有标签「build-vs-buy」

关于 AI 网关是自研还是购买的决策，几乎从来不是基于某种决策框架做出的。它往往在第一周由一位对该问题感兴趣的工程师凭直觉决定，然后在第九个月由一位厌倦了账单的总监重新审视。这两个时刻都不是做决策的最佳时机，而且双方都没有站在未来 18 个月的关键维度上来衡量这一选择。

自研路径的诱人之处在于第一个月非常便宜。在 OpenAI 前面加一个 200 行代码的代理，写一个 switch 语句将“claude”请求路由到 Anthropic，再加上一个重试循环，团队就交付了一个看起来像网关的东西。到了第九个月，那个代理变成了 1.2 万行代码，充斥着写了一半的重试逻辑、失效机制混乱的 Prompt 缓存、没人敢相信的成本统计、在上次事故中触发方式错误的备用路由、与技术栈其他部分脱节的可观测性模式，以及在第一个企业客户提出要求后强行加入的租户限流。每一个功能都是“购买路径”在第一天就能交付的功能的拙劣复制。而当初写那 200 行代码的工程师已经离职了。

我合作过的一个团队在上季度发布了一个“智能”日期提取器。该模型可以解析像“下周二”和“14 号之后的两周”这样的自然语言短语，在生产环境中通过功能标志 (feature flag) 运行，在选定的层级上每次请求的成本约为 3 美分。六周后，一位后端工程师偶然参加了一场设计评审，随口提到公司其实早就有了一个日期解析器。它编写于 2019 年，存在于一个 AI 团队中没人读过的工具模块里，能以不到 1 毫秒的延迟处理 99.4% 的相同输入，而且运行成本几乎为零。那个 AI 功能并没有被撤下，而是被合理解释了——“模型可以处理长尾情况”——于是团队继续前进，发布了一个比公司已有方案更贵、更慢、准确度更低的版本。

这并非个案。对于那些比 AI 团队成立时间更久的公司来说，这是 AI 功能最主要的失败模式。这种模式不断重复：一个智能分类器复制了多年前编写的正则表达式流水线；一个检索系统获取了一个内部服务一直作为类型化表维护的供应商列表；一个智能体 (agent) 学习提取那些解析器已经可以确定性提取的实体。AI 功能发布的质量标准甚至低于它并不知道其存在的确定性系统，而构建确定性系统的团队往往在跨团队会议上才发现这一点。

你为了加快上线速度而购买的托管审核 API，现在已经成了你安全关键路径上的一个同步外部依赖。这句话并非观点——而是被如实重绘后的架构图。在供应商服务降级的日子里，你面临两个选择，且两者都很糟糕：故障开启（fail open），此时护栏在最需要的时候恰恰失效了；或者故障关闭（fail closed），护栏的故障直接导致了功能的停摆。大多数团队是在事故发生时才发现自己选了哪一个，而不是在此之前。

团队选择供应商的原因并非因为懒惰。在内部构建内容分类器、提示词注入检测器和 PII 脱敏工具，看起来像是背离实际产品开发的六个月漫长弯路，而供应商通常提供免费额度和五分钟即可完成的集成。这种集成确实很快。但随之而来的架构后果是，第三方现在介入了每一次面向用户的生成请求路径，其可用性、延迟和行为特征是你无法控制且未曾建模的。

这篇文章的主旨是将这一决定视为架构决策，而非采购决策。