861 篇博文 含有标签「insider」

当一个多智能体系统开始出现奇怪的行为——给出不一致的答案、丢失任务追踪、做出与早期推理相矛盾的决策——本能反应是责怪模型。调整提示词，换一个更强的模型，添加更多上下文。

真正的原因往往更平凡，也更危险：并发写入导致的共享状态损坏。两个智能体读取同一块内存，都计算出更新，其中一个默默地覆盖了另一个。结果状态在技术上是有效的——没有异常抛出，没有模式违规——但在语义上是错误的。之后读取它的每一个智能体都在对错误信息进行正确的推理。

这种故障模式在单个操作层面是不可见的，在测试环境中难以复现，仅通过查看输出几乎无法与模型错误区分开来。O'Reilly 2025年关于多智能体内存工程的研究发现，36.9%的多智能体系统故障源于智能体间的不对齐——智能体在对共享信息的不一致视图上运行。这不是一个理论上的顾虑。

当团队部署 AI 安全过滤器时，对话几乎总是集中在它拦截了什么。它是否拦截了越狱攻击？它是否标记了仇恨言论？它能检测提示词注入吗？对于召回率（Recall）来说，这些都是正确的问题。但它们几乎从未与另一个同样重要的问题挂钩：它错误地拦截了哪些不该拦截的内容？

答案通常是：很多。由于大多数团队在发布时都使用供应商的默认阈值，并且从未在生产环境中对误报（False Positives）进行监测，他们直到用户开始抱怨时才会发现——或者直到用户停止抱怨，因为他们已经停止使用该产品了。

你的 AI 功能在内部测试中表现出色。工程师拍手叫好，产品经理竖起大拇指，评估套件在基准测试中显示了 94% 的准确率。然后你上线了，两周之内，用户就遇到了你从未见过的故障模式——错误的答案、混乱的输出，以及让模型显得极为糟糕的边缘情况。

这就是生产分布差距（production distribution gap）。这不是一个新问题，但对 AI 系统来说，它比确定性软件严重得多。理解其背后的原因——并制定具体的解决方案——是决定 AI 功能悄然侵蚀用户信任还是随着使用不断改进的关键分水岭。

大多数RAG团队会花数月时间调整分块大小、尝试不同的嵌入模型、争论混合搜索配置。然后他们上线，宣告成功，转身离开。六个月后，用户开始抱怨系统给出错误答案——团队才发现，当初精心构建的索引已经悄然腐化。

索引新鲜度是最后才被解决的问题，通常是在用户投诉事故之后才被重视，而非之前。与检索质量问题会立即在评测中暴露不同，数据陈旧是无声无息的退化：延迟保持平稳，检索看似正常，上下文召回率和忠实度等标准RAG指标评分良好——直到系统自信地返回几个月前就已更新的政策时，才会东窗事发。

你花了数周时间调优嵌入模型。检索精度看起来不错。分块大小、重叠、元数据过滤器——一切都已调整到位。然而用户不断反映，系统"忽略"了它明明能访问的信息。相关段落每次都出现在 top-5 检索结果中，模型就是不用它。

罪魁祸首往往是位置偏差（position bias）：语言模型倾向于过度依赖上下文窗口开头和结尾的信息，而对中间内容的注意力显著不足。在受控实验中，将相关段落从 20 篇文档上下文中的第 1 位移至第 10 位，准确率会下降 30-40 个百分点。你的检索器找到了正确的内容，但排序毁了它。

你的检索器在 94% 的情况下都能返回正确文档。你的 LLM 在给定良好上下文时能正确回答 96% 的问题。可以上线了。能出什么问题？

把这两个数字相乘：0.94 × 0.96 = 0.90。在不考虑任何边缘情况、提示词格式问题、token 截断，以及检索器与正确文档一起返回的干扰文档之前，你就已经损失了 10% 的查询。但更深层的问题不是这个算术——而是你的单元测试永远不会发现这一点。检索器在隔离测试中通过了。生成器在隔离测试中通过了。失败的是两者的组合，而大多数团队对此没有任何测试。

这就是检索-生成接缝：检索器交付内容与生成器实际能够使用的内容之间的接口。它是生产 RAG 系统中测试最不充分的边界，也是大多数故障的根源。

如今，大多数构建 AI agent 的团队都将授权视为事后才考虑的事情。他们接入一个 OAuth 令牌，给 agent 分配与触发它的用户相同的权限范围（scopes），然后就大功告成了。然而，几个月后，他们会发现一段被操纵的提示词导致 agent 窃取了文件，或者一个受损的工作流在连接的服务中悄无声息地提升了权限。

问题不在于 RBAC 不好。而是在于 RBAC 是为具有稳定工作职能的人类设计的，而 AI agent 既不稳定也不是人类。在一个对话回合中，agent 的“角色”可能从只读研究转变为具备写入能力的代码执行。静态角色无法表达这一点，这种不匹配创造了一个可预见的漏洞攻击面。

一家中型 SaaS 公司的团队在阅读了一些基准测试后，在每个提示词中都加入了“让我们一步步思考”（let's think step by step）。他们的响应质量有了明显的提升——但他们的 LLM 账单也翻了三倍。当他们深入研究日志时，发现大部分额外的 Token 都花在了支持单分类和会议记录总结等任务上，而在这些任务中，额外的推理对输出质量并没有明显的改善。

扩展思考模型对于难题来说是真正的能力飞跃。但如果不加区别地应用，它们也是一个可靠的成本陷阱。一个经过良好调优的推理部署与一个昂贵的部署之间的区别通常归结为一点：理解哪些任务真正受益于思维链（chain-of-thought），而哪些任务只是在为显而易见步骤的冗长叙述买单。

如果你曾剖析过一个莫名其妙跑得很慢的AI Agent，大概率会发现一个瀑布。Agent调用工具A，等待，再调用工具B，等待，再调用工具C——即便B和C根本不依赖A的结果。你为1倍的工作量付出了3倍的延迟。

这个模式并非边缘情况，而是几乎所有Agent框架的默认行为。模型在单次响应中返回多个工具调用，执行循环则逐一按顺序运行它们。修复并不复杂，但前提是要有一种可靠的方法来识别哪些调用真正相互独立。

某金融科技公司首次部署AI交易审批代理时，产品团队在一周离线评估结果良好后便确信模型已准备好自主运行。他们将其推进至副驾驶模式——代理提出审批建议，人工可以覆盖——审批率看起来很不错。三周后，一个规律浮现：模型在系统性地低批准来自非英语用户的交易，这种偏差与姓名模式相关，而非风险信号。在上线前没有人检查过分段层级的性能。这不是欺诈检测失败，而是阶段门控失败。

大多数团队原则上理解AI功能应该渐进式上线。但他们缺少的是一个具体的工程框架来定义"渐进"的实际含义：哪些指标解锁每个阶段、在升级之前需要哪些监控，以及什么触发自动回滚。没有这些，自主性升级就变成了组织层面的乐观主义行为，而非可重复的工程决策。

你的负载均衡器将一个传入的智能体请求分配给副本 3。但用户的对话历史存储在副本 7 的内存中。副本 3 完全不知道过去六轮发生了什么，于是它从头开始，让用户一头雾水，你的值班工程师在凌晨 2 点被叫醒。你启用了会话粘滞。现在该用户的所有请求永远路由到副本 7。你用一个正确性问题换来了一个可扩展性天花板。

就在这一刻，团队意识到：AI 智能体的"水平扩展"和 Web 服务器的水平扩展根本不是同一个问题。修复方式不同，而那些看似直接的路径会以可预见的方式失败。

一家电信公司发布了一款 AI 客服聊天机器人，拥有 99.99% 的可用性和低于 200ms 的响应时间 —— 每一个传统的 SLA 指标都显示为绿色。然而，在 35% 的账单查询中，它的回答都是错误的。没有任何合同条款涵盖这一点。没有任何警报触发。客户只是悄然流失。

这就是 AI 的“西瓜效应”：系统表面看起来很健康，内部却在悄悄腐烂。传统的可靠性 SLA —— 可用性、错误率、延迟 —— 是为确定性系统构建的。它们衡量的是你的服务是否回答了问题，而不是回答得好不好。在传统的 SLA 下发布 AI 功能，就像保证你的支持团队发送的每封邮件都能送达，却不对回复内容是否合理做任何承诺。