907 篇博文 含有标签「insider」

语义缓存命中是唯一一种能在不到一毫秒的时间内，将错误答案发送给错误用户的 LLM 优化方式。SQL 缓存之所以会返回你或他人的数据行，是因为有人写错了 join —— 这种故障模式属于查询 bug。而语义缓存返回另一个租户的响应，是因为两个 embedding 在 0.03 的余弦距离内落到了一起，这正是系统完全按设计运行的结果。缓存完成了它的工作，问题在于这份工作本身。

大多数团队将语义缓存作为一种成本方案来推行 —— 每个 AI 工程 Slack 频道里都流传着一份“削减 70% 账单”的 PPT —— 并且像对待 Redis TTL 一样审查缓存键（cache key）：完全不审。这种审查通常交由性能团队负责。安全团队永远看不到设计文档，因为没有人会为“我们增加了一条更快的路径”提交安全审查。六个月后，某人的合规审计发现，“我无法登录我的账户，我的电子邮件是 [email protected]”和“我无法登录我的账户，我的电子邮件是 [email protected]”在向量化后都处于“我无法登录我的账户”的阈值内，于是缓存愉快地向 Bob 提供了原本为 Jane 生成的响应，其中包含了她账户请求的密码重置链接。

这篇文章将讨论为什么语义缓存值得拥有与 SQL 谓词相同的审查严谨性、如何通过缓存键设计从结构上防止跨用户泄露，以及你需要什么样的审计追踪来区分“缓存命中提供了正确答案”与“缓存命中在亚毫秒级延迟下提供了他人的答案”。

我接手时，我们客服智能体的提示词已经达到了 2,400 个 token，而编写它的工程师已经离职了。其中的每一条指令对于某些生产行为来说都是“承重的”，但没人能告诉我哪些才是关键。一条关于“在回答之前务必先复述用户问题”的条目看起来像是凑数的，直到我们删掉它后，CSAT（客户满意度）在一周内下降了四个百分点。事实证明，提示词就是规范（specification）。它既是实现（implementation），也是测试套件（test suite）——它是隐性的、未记录的，仅存在于那位已经离职的工程师脑中。

这就是“提示词即规范”的终局。提示词既是智能体应该做什么，也是它如何做，一旦提示词规模超过了单个作者的掌握范围，两者就会变得无法区分。你无法重构它，因为你不知道哪些行编码了需求，哪些行仅仅是暗示。你无法评审变更，因为没有可以与之对比的基准产物。你无法让任何人接手并负责它，因为负责意味着“最近阅读过全文并记得每一项条款存在的原因”，这是一项没人愿意批准的、长达六个月的投资。

“规范优先”颠覆了这种顺序。契约（contract）——输入、输出、不变量、错误情况、拒绝语义、升级触发条件——是一个先于提示词并约束每次修订的一等产物（first-class artifact）。对提示词的修改变成了针对规范的补丁（diff），而不是对规范本身的重写。这种转变听起来很官僚，直到你看到它所释放的潜力：评估（evals）源自规范而非反之，评审只需几分钟而非整个下午，最终能让新工程师在没有六个月学徒期的情况下直接接手整个模块。

你技术栈中最灵敏的泄露信号并不在 SIEM 中。它隐藏在财务人员月初打开的一份电子表格里。当攻击者窃取了 LLM API 密钥、利用提示词注入（prompt injection）窃取数据，或者通过被入侵的租户会话查询相邻客户的内存时，痕迹首先会表现为 Token 使用异常——这远在任何 DLP 规则触发、任何身份验证警报响起或任何终端代理察觉到异常之前。财务看到了，而安全部门却没看到。

这种差距并非理论上的。Sysdig 的威胁研究团队在观察到攻击者利用窃取的云凭据产生每日五位数的账单后，创造了“LLMjacking”一词。这一类别现已演变成一个有组织的犯罪产业，出现了每个账号 30 美元的交易市场，且有记录显示某些活动让受害者的损失每天超过 100,000 美元。OWASP 记录了一家初创公司因为密钥泄露，在 48 小时内产生了 200,000 美元的账单。斯坦福大学的一个研究小组由于在 Jupyter notebook 中遗忘了一个 Token，在 12 小时内烧掉了 9,200 美元。所有这些事件的共同点是：在安全团队察觉之前，账单图表就已经在几个小时甚至几天前揭示了真相。

询问一个 Agent 团队他们的工具调用成功率是多少，你会得到一个答案。但如果你问他们的工具幻觉率（tool-hallucination rate）是多少，全场就会陷入沉默。大多数团队并不追踪这一指标，而那些追踪的团队通常也只计算最灾难性的版本——即目录中不存在的函数名——而那些更隐蔽、代价更高的变体则在生产环境中未受监控地运行。

幻觉化的工具调用不仅仅是指模型凭空捏造了 delete_orphaned_users(older_than="30d") 导致你的分发器（dispatcher）抛出 ToolNotFoundError。这是简单的情况。更复杂的情况是，虚假的调用通过模糊匹配隐匿地指向了一个相邻的真实工具，或者工具名称正确，但 Agent 捏造了一个参数，而你的 Schema 因为将其标记为可选而愉快地接受了它。这两种情况都能通过你的“工具调用是否成功”仪表盘，但都不是用户真正想要的。

一个来自 AI 编程智能体的 40 个文件的重构任务摆到了你的桌面。你打开 PR，滚动查看差异（diff），每一个代码块（hunk）看起来都没问题。命名重构很一致，导入很整洁，测试在隔离状态下也能编译。你合并了代码。40 分钟后，主分支的 CI 变红了，因为同级包（sibling package）中的两个调用点仍然向一个现在需要四个参数的函数传递三个参数，而原本能捕获这一错误的类型检查器从未包含在智能体的内环（inner loop）中。

这是当今智能体编写的重构中最常见的失败模式，而且它与单个修改的质量几乎无关。每一个文件单独审查时，看起来都像是一个细心的人类写的。Bug 存在于“接缝”处——即来自不同文件的修改必须保持一致的边界。文件级的审查隐藏了接缝级的正确性，而大多数审查工作流都是围绕文件设计的。

第一次验证器捕捉到糟糕的 LLM 输出时，感觉像是一场胜利。第二次，你会调整提示词以降低失败的可能性。到第二十次时，团队中没人能解释为什么提示词中存在那三个段落 —— 它们是早已被遗忘的事故留下的瘢痕组织，而模型在阅读警告上花费的 Token 比推理实际任务还要多。

这就是验证器陷阱。你添加的每一个事后防护（post-hoc guard）—— JSON 模式检查、正则表达式、内容分类器、第二个作为裁判的 LLM —— 都会对上游提示词施加反馈压力。提示词会增加防御性指令来安抚验证器，验证器反过来又会捕捉到一类新的失败，接着你又会添加更多指令。每一次迭代在局部看来都是合理且明智的。但总体而言，系统变得越来越慢、越来越贵，而且在原本设计的任务上的表现也明显变差了。

十一个智能体在同一秒内启动。在第一个工具调用返回之前，就有三个阵亡了。那 27% 的失败率不是模型问题、提示词问题或工具问题。这是一个调度问题 —— 就像操作系统在五十个进程同时唤醒并争抢单个 CPU 时所解决的问题一样。区别在于，操作系统拥有四十年的智慧积累，而智能体运行时只有大约两年。

任何连接过超过几个并发 LLM 工作节点的人都见过类似的情况。你在 02:00 启动一个定时任务，三十个智能体同时启动，它们在 200 毫秒内同时请求同一个提供商，结果大多数都以 429、502 和连接重置告终。幸存者只能获得承诺的一半速率配额，因为提供商的公平共享逻辑已经开始对你的 API 密钥进行节流了。到 02:05 时，幸存的智能体运行结束，你的仪表盘显示的完成率足以让一个刚写出第一个生产者-消费者的计算机专业大一学生感到汗颜。你的值班人员会争论是该增加重试、增加队列，还是干脆减少运行数量。

这些方法本身都不是正确答案。正确答案是：一个智能体集群是一个小型分布式系统，需要按照分布式系统的方式进行设计。

一个平台团队对他们的摘要服务的系统提示词（system prompt）进行了一行细微的调整。没有代码审查，没有迁移指南，没有版本更新——这“仅仅是一个提示词”。两周后，法律产品团队发现他们的合规自动脱敏功能一直在静默地泄露姓名。调查耗费了一个冲刺（sprint）。修复很简单。损害的是信任。

这是 AI 变更日志问题的缩影。行为现在是你系统的一等输出（first-class output），当提示词、模型、检索器或工具模式（tool schemas）发生变化时，行为也会随之改变——而这些变化都不会出现在消费方应用的 git diff 中。如果团队像对待后端部署那样对待 AI 更新，认为在 #releases 频道发一条 Slack 消息就足够了，那么他们最终会重蹈 2010 年代早期那种“我们先上线，稍后再告诉 QA”工作流的覆辙。

大多数工程师在构建第一个 LLM agent 时，都会遵循相同的流程：写一个系统提示词，添加一个调用模型的循环，撒上一些工具调用逻辑，然后看着它在简单的测试用例上运行。六周后，这个 agent 变成了一团难以理解的嵌套条件、粘贴在 f-string 里的 prompt 片段，以及散落在三个文件中的重试逻辑。添加一个功能需要通读整个代码。遇到生产 bug 就得盯着一个上千 token 的上下文窗口，试图重建模型当时在"想"什么。

这就是"意大利面式 agent"问题，在以 prompt 为起点而非设计为起点的团队中几乎普遍存在。解决方案不是更好的提示技巧，也不是换一个框架，而是一种纪律：在写第一个 prompt 之前，先设计好状态机。

麦肯锡 2025 年的调查发现，75% 的业务负责人正以某种形式使用生成式 AI —— 但近一半的人已经遭遇过严重的负面后果。这种差距并非模型质量问题，而是信任问题。而缩小这一差距的最快路径不是更多的评估（evals）、更好的提示词（prompts）或新的前沿模型，而是向用户准确展示智能体（agent）做了什么。

大多数工程团队将审计追踪视为事后才考虑的事情 —— 就像你为了 GDPR 合规或 SOC 2 认证而临时接入的东西，然后将其锁在只有运维人员（ops）查看的内部仪表盘中。这是错误的做法。当用户能看到智能体调用了哪个工具、检索了哪些数据，以及哪条推理分支生成了答案时，会发生三件事：采用率上升，支持工单减少，并且模型错误能比任何后端警报提早数天显现。

47% 的专业开发者现在使用 AI 代码审查工具——两年前这一比例仅为 22%。然而在同一时期，AI 协作编写的 PR 合并后产生的 Bug 数量是人工编写代码的 1.7 倍，整个行业的变更失败率上升了 30%。团队在部署这些工具时出了问题，而问题并非工具本身。

核心问题在于工程师在没有理解 AI 审查能力边界的情况下就将其引入工作流。这类系统在真实代码库上的效果上限为 50–60%，只擅长一小类表层问题，而恰恰在导致生产事故的错误上静默失败。将 AI 审查视为通用质量关卡的团队，得到的是虚假的信心，而非真正的覆盖。

在受监管行业部署 LLM 的大多数团队都会以惨痛的方式发现他们的合规差距：审计员出现并要求提供特定日期哪个文档影响了某个特定输出的完整日志，而团队却无法给出答案。这并不是因为系统没有记录——它记录了——而是因为 LLM 调用的文本日志并不等同于具有防篡改证据的审计追踪，而 LLM API 的响应主体也不等同于输出溯源（Output Lineage）。

金融、医疗和法律领域不仅仅是消费类软件的“更严格”版本。它们需要通用 LLM 框架从未设计的底层基础设施原语：不可变事件链、单次输出溯源、拒绝处置记录（Refusal Disposition Records）以及结构化可解释性钩子。目前流行的编排框架都没有提供这些开箱即用的功能。本文介绍了这种架构差距，以及如何在不重构整个技术栈的情况下弥补这一差距。