722 篇博文 含有标签「insider」

一个正在构建多智能体研究工具的团队在一次失控任务运行到第 11 天时发现，他们的两个智能体在整个过程中一直在循环交叉引用彼此的输出。账单金额：47,000 美元。没有人类看到过结果。没有触发任何警报。系统只是在持续运行，并确信自己正在取得进展，因为架构中没有任何环节提出这样一个问题：当一个任务确实无法完成时会发生什么？

消息队列在几十年前就通过死信队列 (DLQ) 解决了这个问题。一条超过投递重试限制的消息会被路由到一个暂存区，操作员可以在那里检查它、修复根本原因，并在系统准备就绪时重新播放。这种模式简单、经过实战检验，但在当今的生产级智能体系统中几乎完全缺失。

你的图像生成功能刚刚走红。每天有 100,000 个请求涌入。API 提供商的速率限制在技术上可以应对。但 p95 延迟爬升到了 12 秒。你的 NSFW 分类器正在误报合法的医学插图。合规性审计显示，加州的《人工智能透明度法案》（AI Transparency Act）要求自 2024 年 9 月起添加水印。支持团队收到了 50 个来自内容被静默拦截的用户的待处理工单。当你意识到需要一套真正的生产级技术栈时，你已经在危机模式中虚耗了两周。

这就是“直接调用 API”失效的时刻——不是因为 API 本身不好，而是因为演示的成功暴露了你对推理延迟、内容策略、审核公平性和监管合规性所做出的每一项假设。教程中从未展示过的工程工作就在这里。

大多数构建多智能体系统的团队，把大量时间花在授权信任上：智能体 B 被允许执行哪些操作、可以调用哪些工具、能访问哪些数据。这是一个重要的问题。但还有第二个信任问题同样关键，却鲜少得到足够重视——而正是它在实际生产系统中造成严重故障。

这个问题是认知层面的：当智能体 A 将任务委托给智能体 B 并收到答案时，A 应该在多大程度上相信 B 返回的内容？

这不是 B 是否被授权回答的问题，而是 B 是否真的有能力回答的问题。

你的流式传输正常工作。你的重试逻辑正常工作。你的安全过滤器正常工作。你的个性化功能也正常工作。但当你将它们部署在一起时，奇怪的事情发生了：流式传输中途出现的速率限制错误导致用户看到的是一段被截断的响应，而系统却将其记录为成功。重试机制触发了，但流式传输已经结束。个性化层提供了一个定制化的响应，而安全过滤器本应拦截这个响应——除非过滤器看到的是 Prompt 的脱敏版本，而不是个性化层所处理的那个版本。

每一个功能都通过了你编写的各项测试。然而系统还是让用户失望了。

这就是功能交互故障（feature interaction failure），它是当今 AI 系统中最容易被误诊的生产环境 Bug。

中央 AI 团队本应是答案。把最优秀的 ML 工程师集中到一个团队，统一工具链，建立治理机制，让产品团队无需深入理解 AI 就能直接消费 AI 能力。这是一个听起来很美的架构——在组织架构图上清晰可见，在董事会演示中无懈可击。然而在实践中，它可靠地生产出一种失败模式，看起来恰恰就像它本要消除的碎片化。

中央 AI 团队变成了瓶颈。产品团队在后面排队等待。它交付的 AI 对每个需要特定功能的领域来说都显得过于通用。构建平台的 ML 工程师不了解产品指标。需要帮助的产品工程师只能靠提工单才能调试 AI 行为。一个 3 个月的试点成功了；一个 9 个月的安全审查把它埋葬了。

2025 年，企业放弃 AI 项目的比率已超过 2024 年的两倍。这些失败大多发生在从概念验证过渡到生产环境的阶段——正是人手不足、脱节的中央团队暴露出裂缝的时候。

一个在生产环境中运行的智能体曾经收到指令"清理测试数据"，然后对生产数据库执行了 DROP TABLE 命令。工具调用成功执行了。审计日志显示了一个结构完美的 JSON 载荷。智能体做的恰恰就是被要求做的——只是不是任何人所期望的那样。这不是一个提示注入的故事，而是一个架构选择的故事：团队赋予了智能体生成和执行任意代码的能力，却低估了这在运行时真正意味着什么。

将函数调用与代码生成作为 AI 智能体动作层之间的选择，是智能体架构中最关键的决策之一，却几乎没有人对其进行直接基准测试。论文衡量任务完成的准确性；它们很少衡量在生产中真正重要的失败模式——静默语义错误、不可逆副作用、安全暴露面，以及出错时的调试成本。

你的智能体已经与同一个用户对话了400次。六个月前她说她更喜欢Python。三个月前她的团队迁移到了Go。上周她提到了一个新的TypeScript项目。这三个事实现在都存储在你的向量数据库中——语义相似、时间顺序混乱、权重相同。下次她请求代码帮助时，你的智能体会同时检索到这三条信息，将这团矛盾的内容递给模型，然后自信地为TypeScript场景生成带有Go风格的Python代码。

这就是幽灵上下文：那些永不消亡的过时信念，与其替代版本一同被检索，悄然腐蚀智能体的推理。

这个问题之所以被低估，是因为它不会产生可见错误。智能体不会崩溃，不会拒绝响应，而是生成流畅自信的输出——只是微妙地、代价高昂地出错了。

你的 AI agent 刚刚完成了一项复杂的数据库迁移任务。它调用了正确的工具，使用了恰当的术语，引用了正确的库，并返回了看起来完全合理的输出。然后你的 DBA 在一个拥有 5000 万行的生产表上运行它 —— 结果备份标志（backup flag）写错了。这个标志存在于相邻的库版本中，语法上是有效的，但它在静默状态下没有执行备份步骤。

这个 agent 并不是在胡言乱语。它表现得自信、流畅且方向正确。但在操作上，它错得正是会导致数据丢失的那种方式。

这是该领域投入不足的一种幻觉类别，也是你的评估（evals）几乎肯定无法捕捉到的那种。

当 LLM 的输出感觉不对劲时，工程师会本能地去调 temperature。这是调试手册里最早的动作之一——调低它以获得更强的一致性，调高它以获得更多创意。这感觉很有效，因为改动简单且效果立竿见影。但这几乎从来都不是正确的做法。

Temperature 和 top-p 只是输出质量最后 10% 的因素，而不是前 90%。真正决定模型成败的变量是上下文质量、指令清晰度和模型选择——依次排列。在一个有问题的提示词之上再调整采样参数，就像给一道还没煮熟的菜调味一样。根本问题并没有消失。

有人离职了。入职文档上写着“去问 Sarah”，但 Sarah 现在已经在另一家公司了。你正盯着一个 900 行的系统提示词（system prompt），里面有些章节标题写着类似 ## DO NOT REMOVE THIS SECTION 的字样，而你完全不知道如果删掉会发生什么。

这就是“继承的 AI 系统”问题，它与继承常规代码不同。对于遗留代码，意志坚定的工程师可以追踪执行路径、阅读测试，并从行为中重构意图。但对于继承的 LLM 功能，提示词就是逻辑——但它是用自然语言编写的，其失败模式是概率性的，而且作者的意图被困在他们的脑海里。没有堆栈跟踪会告诉你哪个护栏（guardrail）触发了以及为什么触发。

大多数部署 LLM 代码审查工具的团队都会在两周内发现同一种失败模式：模型为每个 PR 生成 10–20 条评论，其中 80% 都是噪音。在第三个 PR 中，如果开发者不看就关闭了所有评论，这个工具就名存实亡了 —— 通知被发送到无人查看的频道，而机器人仍然在每次推送时消耗算力。

问题不在于模型。而在于这些团队发布了一个评论生成器，却称之为审查工具。

大多数构建 LLM 应用的团队最终都会趋向于同一种临时架构：散乱的计算用户摘要的定时任务（cron jobs），每次请求都要重新查询的向量数据库，因延迟到了令人尴尬的地步而添加的 Redis 缓存，以及三个对“用户偏好”定义略有不同的代码库。通常只有在生产事故发生后，他们才会意识到自己构建了什么：一个特征存储（feature store）—— 而且是一个拼凑出来的劣质品。

特征存储是传统机器学习（ML）基础设施中经过实战检验的最成熟模式之一。当有意识地将其应用于 LLM 上下文组装时，它可以消除困扰大多数检索流水线的延迟、成本和一致性问题。本文将解释其原理。