周五下午 4:50，数据团队的某人启动了一次评估扫描（eval sweep）：针对公司的共享模型部署运行四万个提示词，计划在周末完成。下午 5:10，面向客户的聊天助手开始超时。值班工程师盯着仪表盘看了两个小时，显示服务商返回了 429 错误，直到有人想起问一句还有谁在使用该账号。没有任何东西损坏。系统正完全按照配置运行，也就是说什么也没做，因为没人配置它去做任何事。
这是一种新型故障的雏形，它具有一个比普通停机更棘手的特性：没有需要修复的 Bug。评估扫描是正当的工作。聊天助手的流量也是正当的工作。失败之处在于，两个具有不同紧急程度的团队从一个无差别的推理算力池中提取资源，而该池子对谁更重要没有任何判断。当你的公司有多个团队同时使用同一个服务商账号时，容量分配就不再仅仅是基础设施的细节——它变成了一个政治问题，而传呼机（pager）继承了这一麻烦。
两年前，组建 AI 卓越中心（CoE）是一项负责任的举措。当时没人知道如何评估模型，采购部门不清楚推理合同该是什么样，而法律部门则希望有一个明确的责任方。将那十个懂行的人集中到一个中心团队显然是正确的做法。
如今，正是这个团队导致你的产品工程师为了修改一个 Prompt 要等上六周。CoE 审查每一次系统消息（system-message）的修改，掌握着公司唯一的评估框架，并由一个每两周开一次会的委员会来把持模型升级。团队已经察觉到了这一点。他们开始使用个人 API 密钥发布产品，在 CoE 永远看不到的 Notebook 中运行评估，并将客户数据粘贴到任何响应最快的工具中。你并没有防止影子 AI —— 而是你创造了它，并给了它一个需要躲避的治理机构。
每一个内部 LLM 平台都会经历同样的曲线。在第一个月，推理是免费的：平台团队买单，产品团队疯狂实验，每个人都在为增长曲线欢呼。到了第六个月，账单增长了 10 倍，财务部门开始提出尖锐的问题，平台团队发现 80% 的支出由三个团队产生——其中一个团队还在运行一个没人记得批准过的夜间批处理作业。本能的反应是安装计量器并开始收费。这种本能如果应用得过于幼稚，正是你毁掉平台的方式。
这是一个令人不安的事实：按 Token 计费的分摊机制（Chargeback）恰恰惩罚了你构建平台所鼓励的行为。正在原型化可能改变支持流程的智能体（Agent）团队消耗 Token 就像熔炉一样——智能体工作负载每个任务消耗的 Token 是简单聊天补全（Chat Completion）的 5 到 30 倍。如果从第一天起就按原价向他们收费，他们就会停止原型开发。与此同时，运行成熟且经过优化的功能的团队只需支付微薄的费用，看起来非常“节俭”。你构建了一个对学习征税、对停滞奖励的定价系统。
你的平台团队通过开发者采纳度来衡量成功。内部 API 的月活跃工程师数量。新服务的首次调用时间（Time-to-first-call）。季度 DX 调研中的净推荐值 (NPS)。每一个指标都假设请求的另一端是一个人类——一个阅读入门指南、复制 curl 示例、并在错误消息毫无帮助时在 Slack 中抱怨的人。
这种假设正悄然变得不再成立。你内部 API 增长最快的消费者不是人，而是一个智能体 (Agent)：一个正在解决工单的编码助手，一个在夜间核对发票的工作流，或者一个为了回答一个问题而调用六个服务的支持机器人。这些调用者不会浏览你的文档——它们会将你的工具模式 (tool schemas) 摄取到上下文窗口中。当错误提示模糊不清时，它们不会提交 bug——它们会默默地重试、消耗 token，然后放弃。而且它们的数量即将超过人类。
合规计划是对审计员签字通过当天你公司所拥有系统的描述。你公司今天的系统是另一套完全不同的组合，而这两者之间的差距，就是从那时到现在期间每一个上线了新持久化存储的发布版本的表面积。你向客户承诺的删除保证是针对第一套系统的保证，而最终对此进行询问的监管机构，问的将是第二套。
这种失败模式并非删除代码中的 Bug。删除代码本身是正确的。Saga 流程会扇出到数据清单中命名的每一个存储系统，调用每个系统的删除端点，收集每个系统的回执，并在每个回执都返回已签署状态时报告成功。Saga 正在准确执行其被构建时所承担的任务。问题在于，Saga 迭代的是一份 18 个月前的存储系统列表，而智能体平台团队在 6 个月前上线了一个长期记忆功能，却没有任何人将其添加到该列表中。
我认识的一个平台团队花了两个季度构建了一个模型注册中心（model registry）。它拥有组织架构要求的一切：从 dev 到 staging 再到 prod 的晋升工作流、CODEOWNERS 风格的审批矩阵、血缘追踪、评估分数门禁、包含 30 天窗口期的弃用政策，以及一个展示每个模型版本在哪个服务中运行的 Backstage 磁贴。他们发布了上线公告，举办了技术分享会，并在合规活页夹中增加了相关条目。
六个月后，公司流量最高的智能体（agent）运行在一个模型卡片上，其“所有者”字段仍指向一个已经离职的人，评估分数来自团队早已弃用的基准测试，而“批准人”姓名是平台技术主管——他从未用过那个智能体，从未读过其评估集，并在周四晚上 11:43 点击了批准，因为生产者在私信（DM）中对他说，明天就要发布了。
注册中心没有坏。晋升门禁触发了。审计日志是完整的。发布公告承诺的一切都是真的。然而，该组织对生产环境模型的实际监管，反而比 18 个月前更少了。当时同样的决策是由一名 ML 工程师在将模型 URI 粘贴进配置文件之前，手动阅读评估输出后做出的。
一个平台团队发布了一项质量改进。推理阶段的一个图层会读取用户的近期交互记录，并悄无声息地调整响应风格：这里更正式一些，那里更简洁一些，或者当历史记录显示是一个工程师在提问时，响应会更具技术性。A/B 测试显示，整体满意度提升了几个百分点。发布公告的标题是“更智能的响应，无需更改 API”。没有人修改 API 中的标志位。没有人更新文档。响应内容中也没有任何迹象表明模型刚刚采用了哪种人格。
六周后，一位企业客户提交了一个支持工单，称“你们的模型比宣传的要差”。他们的内部评估套件——运行的是你们团队发布基准测试时所用的相同提示词——得分低了 8 分。你团队的第一步是核实提示词的一致性。提示词完全匹配。解码参数匹配。模型版本字符串也匹配。差异最终追溯到了个性化层，它为客户新开设的测试账号推断出一个“历史记录贫乏的默认人格”，而为你衡量基准测试的长效用户账号推断出了一个更丰富的人格。关于个性化究竟是功能还是缺陷的讨论，不再仅仅是一个产品决策，而演变成了一场合同谈判。
打开一个生产环境中的智能体，在用户输入第一个字符之前，数一数上下文窗口里已经有了什么。有一段由平台团队负责的系统提示词（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的工程组织与不能的工程组织之间的分水岭。答案不是放慢智能体的开发——而是在熵使整合变得不可能之前，先进行一次组合审计。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
