AI 依赖足迹：每个功能都在增加新的基础设施所有者

上个季度，你的团队上线了一个基于 RAG 的搜索功能。它需要向量数据库、嵌入模型、标注流水线、分块服务和评估框架。每个组件单独来看都合情合理。但六个月后，你发现这五个组件中有三个没有明确的负责人，有两个运行在工程师的个人云账户上，还有一个被供应商悄悄下线了，无人知晓。凌晨三点的告警来自一个没人记得是何时添加的组件。

这就是 AI 依赖足迹问题：每个 AI 功能所需基础设施的累积叠加，加上组织层面在上线前几乎不规划所有权的现实，共同造就了这一困局。

这一模式在各团队中反复上演。2025 年记录的 AI 事故同比增加了 55%——而事后复盘中反复出现的主题不是模型失效，而是组织失效：所有权不清晰、依赖未受监控、对从未经过审计的基础设施盲目信任。问题不在于 AI 基础设施特别脆弱，而在于团队把它当作临时脚手架，它却一再成为永久承重结构。

一个功能，九层依赖

即便是中等复杂度的功能，现代生产 AI 技术栈也大约横跨九个独立的基础设施层：模型安全与护栏、可观测性与监督、合成数据生成、嵌入与标注、微调与实验追踪、向量存储、应用编排框架、基础模型，以及云推理后端。每一层都有三到五种工具可供选择。

这形成了一张团队并非有意设计的依赖图——而是在每个迭代引入新需求时一块一块拼凑而成的。产品经理要求个性化搜索，需要嵌入；嵌入需要向量数据库；向量数据库需要分块策略；分块策略需要评估框架来验证质量；评估框架需要标注流水线来产出真值数据。每一步看起来都是小小的增量，但累积下来的足迹是十五个独立的工具依赖，各自有自己的升级周期、故障模式，以及"有人在盯着它"这一隐性假设。

更糟糕的是级联问题。向量数据库依赖嵌入质量，嵌入质量依赖基础模型选型，可观测性层同时监控所有上游组件。一旦出了问题，影响范围真的难以判断——哪一层失效了？哪个团队负责那一层？这是数据问题、模型问题，还是基础设施问题？

所有权真空

所有权真空形成得悄无声息。一位数据科学家在黑客马拉松期间用一个新的向量数据库做实验，实验产出了令人眼前一亮的演示，被采纳进生产功能，然后那位数据科学家转向了下一个项目。没有人明确移交所有权。数据库或多或少地运行着，直到某天它不再正常——然后没人有上下文来调试，没人有凭证来修复，没人确定该呼叫哪个团队。

研究持续发现，生产环境中的大多数 AI 工具实际上处于无人管理的状态。影子 AI 工具在组织工作流中平均存留 400 天以上才被发现或清除。已部署 AI 代理的组织中，采用率达 91%——但只有 10% 为这些代理建立了治理框架。

这不是个别工程师的失误，而是结构性缺口。软件团队在基础设施所有权方面已有成熟惯例：服务有运维手册，数据库有 DBA，API 有 SLA。AI 基础设施默认继承了这些惯例中的极少部分。工具更新，所有权规范尚未成形，而 AI 功能开发的速度又在主动阻碍那种成熟软件团队视为理所当然的深思熟虑的所有权规划。

最贴切的类比是 2010 年代末的微服务危机。团队迅速采用微服务，因为技术收益是真实的。运营成本——数百个服务日志不一致、没有标准的服务间通信、没有分布式追踪就无法调试——在 12 到 24 个月后才变得可见。AI 团队正在走同一条路，但速度更快，因为 AI 功能往往需要比典型微服务更多的基础设施组件，而工具格局的变化速度也快得多。

审计你的依赖图

管理 AI 依赖足迹的第一步是让它变得可见。大多数团队没有这样做。审计不需要是正式流程——它只需要在事故强迫你审计之前发生。

一个实用的起始框架涵盖六个领域：

访问与身份：谁能调用哪个模型、调用哪个嵌入服务、写入哪个向量索引？如果答案是"任何有 Slack 置顶消息里共享 API 密钥的人"，那就是一个所有权信号。

使用与费用：你是否按团队、按功能、按实验设置了预算策略和速率限制？意外的 AI 基础设施成本是未受管理依赖的先行指标——组织在 AI 基础设施上的实际支出通常比预算高出 40%–60%，主要原因是那些变成生产功能的个人实验从未被纳入计量方案。

可观测性：每个 AI 组件是否都在以某人主动监控的格式输出日志？向量数据库查询延迟、嵌入漂移、模型错误率——这些都会悄悄劣化，直到造成用户可感知的故障。"嵌入会漂移，分块策略会改变，嵌入模型会更新。"一个团队曾直白地描述他们的处境："我们对嵌入是如何生成的毫无了解……我们害怕切换嵌入模型，因为不知道重训练会怎样影响它。"

模型治理：经过批准的基础模型列表是什么？供应商故障时的降级路径是什么？对单一模型供应商的集中依赖，往往是依赖图中隐而不见的风险。

数据处理与安全：哪些组件接触 PII？哪些有数据驻留要求？这是 AI 基础设施蔓延造成最严重合规风险的地方，因为个人实验往往绕过生产服务所需的数据治理审查。

供应商依赖：你的 AI 基础设施组件中，哪些是单一供应商的？哪些是由小型团队维护的开源项目？了解每个依赖的集中度和脆弱性，是优先整合的起点。

每季度进行一次这样的审计——哪怕只是非正式的——能在所有权真空演变为事故之前将其暴露出来。

整合而不失能力

整合的直觉是对的：减少独立 AI 基础设施组件的数量，可以缩小运营暴露面、集中专业知识，并让所有权分配变得可行。但团队往往抵制整合，因为他们担心失去驱动原始选择的能力收益。

实用的做法是区分消除能力的整合与消除冗余的整合。向量数据库蔓延问题是一个有用的例子。许多团队最终运行着两三个向量数据库——一个是研究原型时选的，一个是产品团队独立采用的，一个嵌在第三方工具里。整合到一个，并不需要选最差的那个；而是需要选出覆盖最广泛用例的那个，然后迁移其他的。运营收益（一套监控、一个升级周期、一个有深度专业知识的团队）通常足以证明迁移成本的合理性。

到 2025 年，一个清晰的整合模式已经浮现：对于已经运行 PostgreSQL 的团队，基于 PostgreSQL 的向量存储（pgvector）成为首选；对于没有运行 PostgreSQL 的团队，则使用成熟云服务商的托管服务。逻辑很简单：在现有数据库上添加向量扩展，消除的是整个依赖层，而不仅仅是在层内整合。

同样的原则适用于其他层。如果你的团队在不同功能上运行着三个不同的 LLM 编排框架，整合到一个并不意味着功能停止工作——而是意味着一个框架，而不是三个升级周期、三套破坏性变更、三份部落知识。

有效的组织启发式：不要改善增殖，而是消除它。用一条无需协调即可使用的单一默认路径，替代多个相似组件。让 AI 基础设施选择变得简单一致的团队，会降低个别工程师绕过默认方案的动机。

所有权分配模型

所有权真空有一个结构性解决方案：在上线之前分配所有权，而不是在事故发生之后。

规模化效果最好的模型将 AI 基础设施分为两层。中央平台团队负责核心基础设施——权威的向量数据库部署、嵌入服务、模型网关、评估框架。各产品团队负责运行在该基础设施之上的用例特定配置和评估。中央团队维护基础，确保其达到生产级标准；产品团队对其功能如何使用这些基础设施保持问责。

这与 Anthropic 工程团队描述的评估基础设施所有权模型相呼应：一个专属团队负责核心评估基础设施和工具，而领域专家和产品团队贡献用例特定的评估任务。职责划分清晰，因为责任本来就是不同的——平台团队关心可靠性、成本和标准；产品团队关心他们的特定功能是否正常工作。

分配模型有一个实际的执行机制：AI 功能的生产就绪审查应包括基础设施所有权检查清单。在功能上线前，团队应能回答：如果向量索引崩溃，谁会被呼叫？谁负责嵌入模型版本并了解升级的影响？谁在随时间推移监控评估质量？

这些问题不需要正式流程来回答——它们需要的是有人在功能进入生产之前就思考过这些问题。这就是所有权分配模型：让思考变成必须，而不是让文书变成必须。

在事故逼出答案之前

AI 依赖足迹问题最终会自我解决。要么团队在事故发生之前主动建立治理，要么事故替他们建立——通过一次事后复盘，确立那些本应从一开始就存在的所有权规范。

主动的路径需要将 AI 基础设施视为一等基础设施，而不是脚手架。这意味着运行依赖审计、明确分配所有权、在冗余积累的地方进行整合。意味着将适用于 API 服务的运维手册和值班惯例，同样延伸到你的嵌入流水线和向量存储。意味着在功能上线之前就要求回答所有权问题，而不是在它发出告警之后。

另一条路——等待凌晨三点的事故来揭示哪些组件没有人负责——是一种有效的选择。团队一直在这样做。但这是一种选择，而不是必然。你的团队构建的依赖足迹，只要去看就是可见的。所有权真空是可以填补的。整合路径是存在的。问题在于，你是审计自己的技术栈，还是等待技术栈来审计你。