打开一个生产环境中的智能体，在用户输入第一个字符之前，数一数上下文窗口里已经有了什么。有一段由平台团队负责的系统提示词（system prompt）。有工具定义——可能有 40 个甚至更多——每一个都包含名称、描述、JSON schema、字段级文档以及一些枚举值。有一段检索到的示例，是搜索团队为了提升某个评测指标而加入的少样本（few-shot）示例。有来自信任与安全团队的 6 行安全指令，来自设计团队的 4 行格式规则，还有一段某人在处理故障时添加但没人删除的领域术语表。
加在一起，智能体启动时就有 30,000 个 token 的开销。在连接了三个 MCP 服务器的配置下，这个数字通常会更糟糕——一个被广泛引用的测量结果显示，三个服务器占用了 200,000 token 预算中的 143,000 个，在对话开始前就消耗了 72% 的窗口。这一切都没有错。每一行都是由为了解决实际问题的人添加的。而这恰恰就是上下文窗口正在被摧毁的原因。
这种说辞听起来很负责任。“我们别在各处硬编码 OpenAI —— 我们在前面加一层薄薄的抽象，这样以后如果需要，我们可以随时更换供应商。”两年后，那个“薄薄的抽象”变成了一项拥有自己部署流水线、SRE 值班表、拦截糟糕 Prompt 的评估门控、每年节省七位数资金的语义缓存、带有针对特定供应商退避机制的重试策略、所有仪表盘都依赖的可观测性架构，以及一个存放着六家模型厂商凭证的密钥库的服务。公司里的每一个 AI 功能最终都汇聚于此。
它也几乎是在无意间，成为了整个技术栈中爆炸半径最大的单点故障（SPOF）。当主要 LLM 供应商宕机时 —— 2025 年，OpenAI 自 1 月以来被记录了 294 次停机事件，而 Anthropic 仅在 12 月就记录了 184.5 小时的总客户影响 —— 网关会自动绕过它，大多数用户甚至察觉不到。而当网关本身挂掉时，每个产品中的每个 AI 功能都会同时停止工作，原本应该触发的故障转移根本没有机会执行，复盘报告的开头往往是：“我们为了隔离供应商宕机影响而构建的抽象层，本身成了那场宕机。”
你公司最具战略意义的 AI 投资，可能是一位工程师在某个周五下午编写的一个 Slack 机器人。它回答“如何获取分级环境凭据”、“哪个值班人员负责认证服务”或“部署卡住时的运行手册是什么”，它节省的工程小时数比整个面向客户的 AI 路线图还要多——而后者占据了你四分之三的模型开销、安全审查队列以及发布沟通带宽。
组织架构图并未反映出这一点。OKR 文档也没有反映这一点。没有人是它的产品经理（PM），也没有人是它的工程经理（EM）。这个机器人之所以能生存下来，是因为构建它的工程师仍在回复 GitHub 上的 issue，在每一个面向客户的功能因六周的安全审查和发布就绪检查清单（之所以存在是因为客户可能会流失）而推迟发布时，它的价值正在悄然复合增长。
我合作过的一个团队在上季度发布了一个“智能”日期提取器。该模型可以解析像“下周二”和“14 号之后的两周”这样的自然语言短语，在生产环境中通过功能标志 (feature flag) 运行，在选定的层级上每次请求的成本约为 3 美分。六周后，一位后端工程师偶然参加了一场设计评审，随口提到公司其实早就有了一个日期解析器。它编写于 2019 年，存在于一个 AI 团队中没人读过的工具模块里，能以不到 1 毫秒的延迟处理 99.4% 的相同输入，而且运行成本几乎为零。那个 AI 功能并没有被撤下，而是被合理解释了——“模型可以处理长尾情况”——于是团队继续前进，发布了一个比公司已有方案更贵、更慢、准确度更低的版本。
这并非个案。对于那些比 AI 团队成立时间更久的公司来说，这是 AI 功能最主要的失败模式。这种模式不断重复：一个智能分类器复制了多年前编写的正则表达式流水线；一个检索系统获取了一个内部服务一直作为类型化表维护的供应商列表；一个智能体 (agent) 学习提取那些解析器已经可以确定性提取的实体。AI 功能发布的质量标准甚至低于它并不知道其存在的确定性系统，而构建确定性系统的团队往往在跨团队会议上才发现这一点。
大多数工程团队在推出第一个AI智能体六个月后，会发现自己已经拥有了15个。这并非出于规划——而是因为每个团队都解决了真实问题并付诸实施。客服团队构建了分类智能体，数据团队构建了报告生成智能体，平台工程团队构建了运行手册智能体，基础设施团队又构建了三个。这些智能体之间没有共享的认证、日志、工具或评估方法。Token费用从十几个供应商账户持续流失，而没有人能告诉你哪个智能体负责哪些开销。
这一时刻，正是能够规模化AI的工程组织与不能的工程组织之间的分水岭。答案不是放慢智能体的开发——而是在熵使整合变得不可能之前，先进行一次组合审计。
AI 平台团队最常见的失败模式不是技术问题，而是组织问题：中央平台团队成了每个产品团队将 AI 能力推上生产的必经关卡。请求队列不断增长，交付周期从几天膨胀到几周。产品团队愈发沮丧，开始拼凑非官方的绕道方案——硬编码 API 密钥、私下接入 LLM、用个人信用卡注册供应商账户。等平台团队察觉时，组织里已有一半的 AI 工作游离在任何治理体系之外。
问题不在于平台团队关心治理，而在于他们把治理实现成了审批流程，而非基础设施。
你的 SRE 团队非常擅长运行微服务。他们精通蓝绿部署、金丝雀发布、分布式链路追踪、SLO 消耗率告警以及复盘文化。接着，有人发布了一个由 LLM 驱动的功能，不到一周就发生了一起上述实践都无法处理的故障：模型开始生成听起来很合理但结构错误的内容，没有日志报错，没有健康检查失败，用户在任何人注意到之前已经默默地接收了四个小时的垃圾信息。
这不是技能差距，而是架构差距。运行 LLM 服务是一门与运行微服务截然不同的运维规范。如果你不明确地识别出那些无法迁移的实践，它们将会让你的团队陷入困境。
你的数据治理审计可能已经发现了它们：用个人信用卡支付的 OpenAI 和 Anthropic API 密钥，通过个人账户接入 Claude 的 Slack 机器人，通过企业 VPN 代理请求的本地 Ollama 实例。没有人通知平台工程团队，没有人请示 IT 部门。工程师们只是……自己动手做了。
这就是影子 AI 问题。无论你是否已经发现，它早已潜伏在你的组织内部。在知识工作环境中，大约一半的员工表示自己在使用雇主未授权的 AI 工具。在软件工程师群体中——他们既有能力搭建非官方集成，又面临提升生产力的压力——这一比例几乎肯定更高。
你支持团队的一位高级 CSM 花了一个周末搭建了一个内部 Slack 机器人。他们自己编写了系统提示词（system prompt），并将其指向了公开文档、Zendesk 已解决工单的导出数据以及变更日志（changelog）。六周后，它能回答团队以前需要手动输入的约 40% 的一级（tier-1）问题。你的工程团队架构中没人知道它的存在。当平台团队第一次发现它时，安全部门的人会问，为什么一个服务账号会在凌晨 3 点访问 Zendesk 的 API。
默认的反应是恐慌。封锁 API 令牌。发送一封关于未经授权 AI 的全公司邮件。在下一次治理审查中增加一张幻灯片。然后承诺平台团队将在下个季度，按照正式的路线图（roadmap）构建“官方版本”。
这种反应忽略了实际发生的情况。CS 团队并没有擅自行动 —— 他们构建了一个工程团队尚未交付的产品的可用原型。他们拥有真实的反馈数据、真实的提示词迭代周期和真实的用户反馈。而你的平台路线图里这些都没有。将这个机器人视为合规违规行为，会丢掉你的 AI 计划今年能获得的最准确的优先级信号。
一位平台工程师修改了公司“品牌风格”序言中的开场白——这是用于统一所有面向客户的助手语气的一行代码。这项改动通过 feature flag 发布。到了周二，搜索团队的相关性退化指标激增，支持机器人的评估通过率下降了四个百分点，入职引导 Agent 的重试率翻了一倍。这些团队中没有一个动过自己的代码。他们都没有收到任何预警。平台工程师对这一切一无所知，因为没人收到过类似的警报：“你的修改刚刚搞坏了三个下游功能。”
这就是定义 AI 团队成立第二年后的典型失效模式。第一年，每个团队都在各自的角落闭门造车。第二年，这些角落开始共享产物——这里一个提示词片段，那里一个种子评估集，或者一个被当作协议复用的工具 Schema。当这种共享变得隐性时，AI 功能之间的依赖图就变得不可见了。你现在拥有的是一个没人能叫出其边缘名称的分布式系统。
解决这一问题的方法论（discipline）并不是一个新平台，而是绘制这张图。
打开公司里那位上线真实的 AI 功能超过六个月的工程师的日历。数一数那些重复出现的 “30 分钟同步 —— 关于 Agent 的问题” 邀请，那些最终被预定的即时 “能耽误你 15 分钟吗？” Slack 消息，那些被标记为 “可选” 但他们实际上不得不参加的架构评审，以及最初只是周五下午的一个时段、现在却每天吞噬两个小时的 Office Hours。然后看看路线图，追踪哪些功能取决于该工程师尚未做出的决定。两者的交集才是你真正的发布时间表。Jira 看板只是虚构。
这就是 AI Office Hours 瓶颈，它在 2026 年的 AI 组织中是核心承重约束，尽管组织里没人会大声说出来。团队快速扩展了 AI 功能开发 —— 每个产品小组都拿到了模型预算，每个 PM 都学会了写 Prompt —— 然后把每一个 “这个模型对吗”、“这里该不该用 RAG”、“我们的评估设计是否有效”、“为什么缓存命中率很奇怪” 的问题都抛给了唯一那个真正上线过足够多生产环境 AI 功能、能给出答案的工程师。六个月后，那位工程师的日历成了半个路线图的限速试剂，“我需要找他谈 30 分钟” 成了你的事故响应本该明确化的核心升级路径。
走进任何一家有五十名工程师在生产环境编写 LLM 代码的公司，你都会发现七个网关形态的产物。推荐团队造了一个用于在 OpenAI 和 Anthropic 之间路由。支持机器人团队写了一个用来挂载他们的 Prompt 注册表。平台团队有一个半成品代理，处理鉴权但不处理限流。增长团队有一个 Lambda，在数据发出时进行 PII 脱敏。数据科学团队直接调用供应商 SDK，而且没人告诉他们停止这样做。没有共享网关。只有七个共同的问题，每个都被孤立且拙劣地解决了，而首席财务官 (CFO) 正准备询问为什么 AI 账单环比增长了 40%，却没有任何明确的负责人。
这与行业在 2016 年和 2017 年遇到微服务时的架构节奏完全相同。成千上万的外部依赖，每个团队都有相同的共同关注点——鉴权、重试、可观测性、策略——以及在“解决一次”或“随处重新发明”之间做出选择。当时的答案是服务网格 (Service Mesh)。现在的答案是内部 LLM 网关，而大多数公司仍处于“随处重新发明”的阶段。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
