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

AI 工程中的大多数“自研还是购买”之争都是逐个组件展开的。我们应该构建自己的模型网关还是使用 OpenRouter？编写自己的智能体循环还是采用框架？微调还是提示词？每一次争论都有专门的会议、电子表格和嗓门最大的人。而每一次争论都悄悄地假设，格局会保持足够长的时间，让决策能够产生回报。

事实并非如此。你 AI 技术栈下的根基正以史无前例的速度移动。在固定的能力水平下，推理价格每年下降 9 倍到 900 倍不等 —— 具体取决于你追踪的能力阈值。2021 年底每百万 token 耗资 60 美元的 GPT-3 级输出，现在只需几分钱。智能体框架在三年内经历了多次颠覆性的重写。网关层从“我们应该建一个”到充满托管和私有化选项的竞争激烈的红海市场，仅用了大约 18 个月。在这样的格局中逐个组件进行决策，就像是盯着脚尖去划船。

有一个诞生了 60 年的工具正是为了解决这个问题：沃德利地图。它不会告诉你该构建什么。它会告诉你一些更有用的东西 —— 你的哪些组件即将变成别人的廉价产品，而哪些组件正在向相反的方向移动。

18 个月前，“我们构建了自己的检索流水线”在架构评审中还是一个非常合理的说法。你拥有分块策略、经过基准测试的嵌入模型、调优过的向量数据库、重排序器，以及一个由 3 名工程师耗时一个季度才搞定的上下文填充启发式算法。那一套技术栈曾是真正的差异化基础设施。而今天，同样的能力只需一次托管的工具调用：将文件上传到向量数据库，将其附加到请求中，供应商就会完成解析、分块、嵌入、存储、检索和重排序——所有这些都隐藏在一个 API 背后。曾经需要 3 名工程师开发一个季度的成果，现在只是一个配置对象。

这就是目前构建 AI 产品令人不安的模式。自建与外购之间的界限并非固定，它在移动，而且只向一个方向移动。每隔几个月，模型供应商就会发布一个原生功能（primitive），蚕食掉你曾经拥有的一个层级：记忆、检索、结构化输出、工具路由，甚至是多步编排。上个季度还让你引以为傲的基础设施，这个季度就成了竞争对手可以免费获得的东西，而且默认配置更好，延迟底线更低，因为它就运行在供应商自己的数据中心内部。

一种本能反应是将其视为需要防范的威胁。但这种思维框架是错误的。供应商吸收通用基础设施实际上是在帮你——它帮你删除了你本就不想要的维护工作。真正的问题在于，你选择构建的东西是位于不断上升的水位线之上还是之下。大多数团队从未明确做出这个决策。他们为了演示需求构建了一切，一年后才发现 70% 的代码库是在重新实现供应商现在提供的原生功能，而那 30% 真正具有防御性的部分反而因为缺乏关注而枯萎。

关于 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 脱敏工具，看起来像是背离实际产品开发的六个月漫长弯路，而供应商通常提供免费额度和五分钟即可完成的集成。这种集成确实很快。但随之而来的架构后果是，第三方现在介入了每一次面向用户的生成请求路径，其可用性、延迟和行为特征是你无法控制且未曾建模的。

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