大多数 RAG 架构长得都一样：你的应用从 Postgres 读取数据，将文本发送到嵌入 API，将向量写入 Pinecone 或 Weaviate，并在读取时查询两个系统。你维护着两个数据存储、两套一致性模型、两套备份策略，以及一条同步管道——这条管道总是离让你的向量索引落后源数据数周只差一个边缘情况。
如果数据库自己就能搞定一切呢？这已经不再是假设。PostgreSQL 扩展如 pgvector、pgai 和 pgvectorscale——以及 AlloyDB AI 等托管服务——正在将整个嵌入与检索堆栈折叠进数据库本身。结果不仅仅是减少了活动部件，而是一种根本不同的运维模型：你的向量始终与其所代表的数据保持事务一致。
每一个交付 LLM 驱动功能的团队最终都会进行同样的对话：“如果我们需要更换供应商怎么办？”标准的回答——“我们只需要换一下 API 密钥”——揭示了对耦合实际存在位置的危险误解。在实践中，尝试进行供应商迁移的团队会发现，API 端点是他们最不需要担心的问题。真正的锁定隐藏在七个不同的耦合点中，每一个都能将一次“快速更换”变成一个耗时一个季度的项目。
迁移费用通常会消耗原始开发时间的 20–50%。那些将模型切换视为即插即用的企业团队，往往在面对损坏的输出、激增的 Token 成本以及需要数周才能诊断出的推理质量变化时束手无策。在需要迁移之前，了解这些耦合点在哪里，是受控过渡与紧急应对之间的本质区别。
大多数团队知道他们的用户发送了多少 token。但几乎没有人知道在用户开口说话之前，他们已经支出了多少 token。
在典型的生产级 LLM 流水线中，系统提示词 (system prompts)、工具架构 (tool schemas)、聊天历史、安全前导词和 RAG 序言在实际用户查询到达之前，就默默消耗了上下文窗口的 30–60%。对于拥有数十个注册工具的智能体 (agentic) 系统，这种开销在 128k 窗口中可能达到 45% —— 约 55,000 个 token —— 而这些工具定义甚至从未被调用过。
这就是隐藏的 token 税。它虚增了成本、增加了延迟并降低了输出质量 —— 然而，它从未出现在任何面向用户的指标中。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
