一个只被写入却从未被读取的缓存算不上缓存。它只是一个增加了额外延迟、按 KB 计费的日志系统。而这种失效模式最残酷的版本是，从每个角度看缓存都是健康的：set 调用成功，get 调用返回迅速，键（key）格式正确，值（value）有效，TTL 设置合理。唯一的问题是，没有任何一次 get 调用能找到之前 set 调用写入的键，因为键中的一个字段在每次计算时都会发生变化。
这是一个关于调试过程的故事：为了“能分辨出我正在看的是哪条缓存记录”，一位工程师在缓存键中添加了一个时间戳。结果，在没人察觉的两个星期里，系统悄悄地为每场对话多支付了 14 次额外的 LLM 调用费用。
一个用户问：“这是否符合第 28 条规定的‘转移’（transfer）？”四十轮对话后，模型给出了一个针对不同问题的答案。对话记录显示，模型回答了它收到的问题。用户正在阅读一份看起来像幻觉的投诉。两者都对。模型从未看到用户的提问——它看到的是你的摘要生成器对其进行的礼貌改写：“用户询问了第 28 条的适用性。”
“转移”一词就是问题所在。摘要生成器把它丢弃了，因为摘要生成器的损失函数被调优为保留事实而非措辞，而且评估准则从未学会区分改写主题和改写约束。主题被保留了。约束变成了迷雾。
这种失效模式是结构性的，而非偶发性的。任何通过模型生成的摘要来压缩长对话的应用，在关键路径上都有第二个模型——其质量契约通常被视为 Token 预算旋钮，而非一段产品逻辑。这种不对称性正是 Bug 所在。
一个运行时间较长的 Agent 在第 3 步生成了一个计划。计划的内容大致是：“如果第 1 步中 get_order 返回的订单状态为 shipped，则向客户发送一封物流追踪邮件；否则开启退款工单。”Agent 自信地选择了邮件分支。但客户从未收到追踪号码，因为订单实际上处于 pending 状态。你查看 Trace，期望能发现幻觉。但你发现的情况更糟：第 1 步的工具结果已经不在上下文中了。Pruner 在第 2 步和第 3 步之间将其剔除了——因为它在最近性排名中较低，而且为了给 12KB 的对话记录腾出空间。计划仍在运行。分支仍被选中。现在的决策指向了一个根本不存在的证据。
这在通常意义上并不是模型失败。模型生成了语法正确的计划，按顺序执行，并做出了分支决策。分支是基于一个曾经在上下文中但现在已不在其中的事实做出的。思维链编码了条件（if status == "shipped"）；而实际的状态在传递到需要它的步骤时被丢弃了。计划看起来是确定性的，但它已经被悄悄地从证据中剥离了。
一位用户询问我们的支持智能体：“为什么发票 INV-2025-08-44719 在 4 月 3 日被扣了两次款？”45 分钟和 18 次工具调用之后，智能体自信地回复道：该账户在该季度没有任何重复计费的证据。用户理所当然地投诉了。当我们回放追踪记录（trace）时，答案变得显而易见。智能体在第九轮对话时对内容进行了压缩（compacted）。摘要显示用户“在询问 4 月初的一笔重复收费”。其中并不包含字符串 “INV-2025-08-44719”。随后的每一次工具调用——账本查询、退款 API 查询、审计日志扫描——都是针对转述后的意图发出的，而不是用户输入的字面意义上的发票编号。
Bug 不在工具里，也不在模型的推理中。问题在于我们的上下文管理器（context manager）与每个下游组件之间都有一个契约，但没有人把它写下来。契约写着：“我会保留语义。”而组件需要的是：“我会保留字符串。”
一个用户打开你的长会话智能体（agent），在第 3 轮对话时说：“我是素食主义者，而且预算有限。”对话继续进行。11 轮之后，裁剪器（pruner）开始运行。它计算 Token 数量，发现第 3 轮内容既陈旧又短小，于是为了将窗口维持在预算范围内，将其丢弃了。第 14 轮用户问：“我今晚该做点什么菜？”模型查看一个约束条件已不存在的窗口，推荐了一份 40 美元的肋眼牛排。用户觉得智能体变得越来越难用，打开满意度调查，给这次会话打了一个 2 分。
你的技术栈中没有任何环节会报告记忆失败。Token 预算仪表盘会显示窗口健康地维持在上限之下。延迟仪表盘会显示绿色。评估套件——将单轮回答与预留集进行对比评分——会报告没有退化。唯一能体现智能体能力下降的信号是一个差评，而你的产品团队会将其归咎于“模型方差”。但这并不是模型方差，而是裁剪启发法在错误的目标上，精准地执行了它被调优后该做的任务。
用户输入“其实，我的意思是五十，而不是十五”，点击最后一条消息上的铅笔图标并进行编辑。UI 表现得非常出色：它向用户展示修改后的消息，淡出旧消息，将助手过时的回复变为带删除线的“幽灵”状态，并呈现一段流畅的对话，读起来就像最初的错误从未发生过一样。用户心满意足地发送了下一轮对话。而智能体却用“十五”进行了回答。
Bug 不在模型身上。模型准确地接收了服务器发送的内容，而服务器发送的是：原始消息、原始助手回复、撤回动作、修改后的消息以及新的请求——所有内容按顺序拼接在一起，实时发送。用户在进行一场已经编辑过的对话。而智能体在进行一场从未被编辑过的对话。两份对话记录在第三轮开始分叉，此后再未统一，之后的每一轮对话都在为这一差距支付“利息”。
凌晨两点，你的客服智能体呼叫一位真人。那位真人已经请假一周了。休假自动回复就躺在智能体正在读取的同一个邮箱里。智能体仍然 ping 了过去。自动回复弹了出来。智能体礼貌地道了声谢，然后又 ping 了一次——因为回复里没有它在等的那个工单解决码。十二个循环之后，另一支团队的人偶然发现这个未读会话已经堆了六十条消息，才手动去把值班的人叫醒。
智能体完全照着 prompt 说的做了。Prompt 让它升级给一个人。这个"人"在它眼里只是一个字符串，不是一个角色。这个字符串不知道什么叫 PTO。
Model Context Protocol (MCP) 正如其初衷所愿：它让赋予智能体（agent）新能力变得几乎零成本。接入日历服务器、数据库服务器、公司内部服务器，或是厂商现今发布的 30,000 个工具目录中的任何一个，都只是一个配置更改，而不是一个开发项目。这种无摩擦感是其特性，但也是问题所在。
正因为添加工具的成本极低，每个团队都在添加工具。数据团队接入了仓库服务器。支持团队添加了工单服务器。有人为了某次性任务连接了文件系统服务器后就再也没移除。这些决策本身都没有错。但没有任何一个决策者对这些工具的“总和”负责——即你的智能体在每次请求中携带的聚合工具表面（tool surface）。工具列表已变成了一个具有实际持有成本的依赖图，而在大多数组织中，这是唯一一个无人负责的依赖图。
结果就是蔓延：工具目录单调递增，无人审查，每季度成本都在上涨，并悄悄地让智能体变得更糟。这就是无人负责的表面，它理应受到和你对待 API 表面以及 npm 树同等程度的审视。
在你的代码库某处，有一行代码看起来像 retriever.search(query, top_k=8)。某位工程师在某个下午写下了那个 8。它从未被团队以外的任何人评审过，从未出现在规范文档中，也从未被重新审视。这一个整数决定了你的上下文窗口中有多少配额分配给了检索到的文档而非对话历史，决定了每次请求的成本，决定了响应速度的感官体验，并且——由于语言模型在长文本下的实际表现——还决定了答案的准确性。
这是一个产品决策。它却被硬编码在一个 f-string 里。
打开一个生产环境中的智能体，在用户输入第一个字符之前，数一数上下文窗口里已经有了什么。有一段由平台团队负责的系统提示词（system prompt）。有工具定义——可能有 40 个甚至更多——每一个都包含名称、描述、JSON schema、字段级文档以及一些枚举值。有一段检索到的示例，是搜索团队为了提升某个评测指标而加入的少样本（few-shot）示例。有来自信任与安全团队的 6 行安全指令，来自设计团队的 4 行格式规则，还有一段某人在处理故障时添加但没人删除的领域术语表。
加在一起，智能体启动时就有 30,000 个 token 的开销。在连接了三个 MCP 服务器的配置下，这个数字通常会更糟糕——一个被广泛引用的测量结果显示，三个服务器占用了 200,000 token 预算中的 143,000 个，在对话开始前就消耗了 72% 的窗口。这一切都没有错。每一行都是由为了解决实际问题的人添加的。而这恰恰就是上下文窗口正在被摧毁的原因。
当一个智能体（agent）加入你的团队时，每个工程经理脑海中最接近的类比就是新员工。因此，应对策略显而易见：给它一个沙盒和只读日志，将最初的任务范围缩小，与其结对编程，预留一段磨合期，并随着信任的累积让它承担更重的工作。这听起来很负责任。这感觉就像是你把上一个初级工程师培养成高级工程师时那种耐心的管理方式。
这也是一个范畴错误（category error）——它不只是一个略显不完美的类比，而是一个错误的类比。初级工程师是一个还不太了解你系统的人。而智能体是一个无状态的函数，无论接触系统多少次，它永远都不会真正“了解”你的系统。这是两种完全不同的事物，适用于前者的管理直觉会在无形中让你错配注意力。
这之所以重要，是因为这个隐喻不仅会产生误导，还会让你把精力投在错误的地方。“培养智能体”并不是一种策略。智能体是固定的，你真正能改变的一切都存在于它之外。
当一个智能体（agent）给出的回答比上周差时，第一直觉往往是归咎于提示词（prompt）。有人会重新编写系统指令，删减几句话，增加一个示例，然后发布。有时这会有所帮助。但通常这毫无作用，因为提示词从来就不是问题所在。问题在于，一个冗长的工具调用结果静默地消耗了 18,000 个 token，将实际的任务指令推到了上下文窗口中关注度较低的中部位置，让模型在一个 70% 都是噪音的记录上进行推理。
这不仅是措辞问题，更是资源分配问题。资源分配在系统工程中有一个专属名称：调度（scheduling）。上下文窗口是一种固定大小的资源，多个消费者在其中竞争，而目前大多数智能体技术栈“调度”它的方式就像 1960 年代的批处理系统调度内存一样——先到先得，直到用完为止。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
