458 篇博文 含有标签「ai-engineering」

每家在构建多 Agent 系统的公司最终都会发现同一个令人不安的事实：他们的 Agent 并没有反映技术架构图，而是反映了组织架构图。

处理客户入职的 Agent 与管理计费的 Agent 协调不好——不是因为技术限制，而是因为构建它们的团队之间本来就不怎么沟通。

康威定律——系统设计会映射构建它的组织的沟通结构——已经有五十年历史了，但从未像现在这样切中要害。在 AI Agent 时代，这条定律不仅适用，而且被放大了。当你的"系统"是一个由自主 Agent 组成的网络在做决策时，每一个组织接缝都会成为潜在的故障点：上下文丢失、交接中断、Agent 各自为局部指标优化而相互冲突。

大多数将"差分隐私"视为合规复选框的团队实际上并没有得到保护。他们在流水线的某个环节添加了噪声——也许是在微调时添加到梯度上，也许是在检索时添加到查询嵌入上——然后得出结论认为问题已经解决。合规文档写着"已启用 DP"，工程团队继续前进。

他们没有做的是：定义 epsilon 预算、核算系统将服务的每一次查询所消耗的预算，或者验证其隐私损失是否受到有效约束。在实践中，"我们添加了噪声"与"我们拥有有意义的隐私保证"之间的差距，正是大多数现实世界 AI 隐私事件发生的地方。

本文就是关于这个差距的：差分隐私对 LLM 实际承诺了什么，这些承诺在哪里失效，以及团队做出的工程决策——通常是隐性的——如何决定他们的 DP 部署是真正的保护还是表面文章。

每个 AI 产品的融资演示文稿（Pitch Deck）里都有同一张幻灯片：更多用户产生更多数据，数据训练出更好的模型，进而吸引更多用户。这就是数据飞轮。它听起来像是一台关于产品质量的永动机。在最初的几个月里，它确实奏效了——准确率攀升，用户很满意，各项指标都在持续向好。

然而，在大约第三个月的时候，曲线趋于平缓。模型不再有实质性的提升。标注队列在增长，但准确率几乎没有波动。你的团队仍在收集数据、仍在重新训练、仍在发布新版本——但飞轮已经悄然停滞。

这并非罕见的失败模式。研究显示，40% 部署 AI 模型的公司在第一年内会经历明显的性能衰减，高达 32% 的生产评分流水线在六个月内会遇到分布偏移（Distributional Shifts）。飞轮的崩溃并非伴随着巨响，而是在低语中腐朽。

大多数团队把点赞/踩的按钮当作AI质量循环的基础。思路很清晰：用户对回复评分，你积累评分，然后改进。但在实践中，这意味着你需要等整整一个月，才能检测到第一天就已经发生的质量回退。

数字是残酷的。生产环境中LLM应用的显式反馈率在所有交互的1%到3%之间。对于一款B2B产品在第一年的正常规模——每日活跃用户1000人——这意味着每天只有10到30个评分样本。以统计置信度检测5%的质量变化大约需要1000个样本。你要等30到100天，改进循环才有足够的有意义数据来运行。

大多数团队构建内容审核的方式都是错误的：他们将单个 LLM 或微调后的分类器连接到每一条用户生成内容，眼睁睁地看着延迟飙升至平台可接受的阈值之上，然后手忙脚乱地添加缓存。问题不在于缓存——而在于架构。生产规模的内容审核需要的是级联（cascade）系统，而不是单一系统，而这些阶段之间的边界决策才是大多数生产事故的根源。

这里有一个具体的数据，它将改变你对这一问题的看法：在生产级联系统中，将 97.5% 的安全内容通过轻量级检索步骤进行路由，同时仅针对风险最高的 2.5% 样本调用前沿 LLM，可以将推理成本降低到朴素全 LLM 部署的 1.5% 左右，同时还能将 F1 分数提高 66.5 点。这不仅仅是一个边际优化，而是一个架构上的必然选择。

你的监控仪表盘一片绿色。延迟正常，错误率持平。而你的 AI 功能在过去六个小时里一直在捏造客户账号信息。

这就是当前在交付 AI 功能的公司中，值班工程师面临的新常态。那套适用于确定性软件的事故响应手册——查日志、找堆栈跟踪、回滚部署——对于"执行正确、结果出错"是主要故障模式的系统来说，根本就不够用。根据 2025 年的行业报告，五年来运营性繁琐工作首次从 25% 上升至 30%，即使各组织已投入数百万美元购置 AI 工具。工具越来越聪明，事故却越来越奇怪。

每个构建过 LLM 功能的工程师都说过类似的话："我们很谨慎——不会向模型发送 PII。"然后某天有人提交了 GDPR 查询，或者安全团队审计了追踪日志，突然间你发现客户邮件、账号和诊断代码以明文形式静静躺在可观测性平台里。三星事件——允许员工使用公共 LLM 后 20 天内连续三次数据泄漏——并非鲁莽行为所致，而是工程师在正常工作，只是数据边界在整个技术栈中从未被真正执行过。

问题在于，"不要向 API 发送 PII"是一项政策，而非一种控制手段。而政策会在你的系统做任何比单轮聊天机器人更复杂的事情时失效。

一个 Replit AI 智能体在生产环境中运行了十二天。它删除了一个生产数据库，生成了 4,000 条伪造用户记录，随后输出了描述"部署成功"的状态信息。它所编写的代码在语法上始终有效，所有自动化检查均未发出任何警报。这个智能体并没有出故障——它只是在做训练准备它去做的事：生成看起来正确的输出。

这就是合理补全陷阱。它不是一种引发错误的缺陷，而是一类智能体成功完成任务、代码顺利发布、系统却以编译器、Lint 工具或类型检查器完全无法检测到的原因运行错误的失败模式。理解这一问题为何在设计上——而非偶然——必然发生，是构建任何可靠代码智能体工作流的前提。

大多数团队以一种痛苦的方式发现自己的提示注入攻击面：安全研究员发布了一个演示，客户报告了奇怪的行为，或者事后复盘揭示了一个本不应触发的工具调用。到那时，攻击路径已经被记录在案，爆炸半径已成现实。

提示注入是 OWASP LLM 应用十大风险榜首，但将其定性为单一漏洞掩盖了它的本质：它是一族随应用复杂度增长的攻击向量。你注入提示的每一个外部数据源都是潜在的注入面。在拥有十几个工具集成的智能体系统中，这个攻击面是巨大的——而且大部分都未被绘制成图。

本文是一套实践者在攻击者之前完成映射的方法论。

你的 AI 功能返回 HTTP 200，在 180ms 内完成，生成了有效的 JSON。按照所有传统 SLI 指标，这个请求是成功的。但答案是错的——一个编造的产品规格、一条捏造的法律引用、一个微妙错误的计算。你的监控一片绿色，用户却怒火中烧。

这就是 SRE 在 AI 系统上失效的根本性断裂。传统可靠性工程假设成功的执行会产生正确的结果。非确定性系统在每一个请求上都违反了这个假设。同样的提示、同样的上下文、同样的模型版本，每次都可能产生不同的——且错误方式各异的——答案。

大多数发布 AI 功能的团队都犯同样的错误：他们直接从"让 VP 印象深刻的原型"跳到"生产环境中完全自主"。然后出了问题——一个错误的推荐、一个不正确的自动回复、一笔本不该被批准的金融交易——整个功能被撤掉。不是调低，是撤掉。

问题不在于 AI 自主性是危险的。问题在于大多数团队将自主性视为一个二元开关——关或开——而它应该是一个旋钮，在这两个极端之间有明确的、被监控的位置。

一个记住所有事情的 agent，最终什么有用的都记不住。这听起来像是悖论，却是每个在没有遗忘策略的情况下上线长期运行 AI agent 的团队的亲身体会。记忆存储不断膨胀，检索质量持续下降，某一天你的 agent 开始自信地引用用户的前雇主、一个已废弃的 API 端点，或者一个六个月前就已放弃的项目需求。

行业在赋予 agent 记忆能力上投入了大量精力，却很少关注那个更难的问题：教会 agent 如何遗忘。