578 篇博文 含有标签「insider」

你的智能体中杠杆率最高的 prompt 并不在你的系统 prompt（system prompt）中。它是你六个月前在某个工具定义下写的那句描述，它随实现代码一起提交，之后就再也没动过。模型在每一轮对话中都会读取它，以此决定是否调用该工具、绑定哪些参数，以及当响应不符合预期时如何恢复。工程师将其视为面向人类的 API 文档，而模型则将其视为一个 prompt。

这两种视角之间的鸿沟，正是最糟糕的工具使用（tool-use）类 bug 的温床：模型调用了正确的函数名，传入了正确的参数，发出了正确的 API 调用 —— 但原因却是错的，场景是错的，或者它放着旁边更合适的工具不用。没有任何异常抛出。你的评估套件依然通过。这种退化（regression）只会表现为衡量智能体是否真正起到帮助的指标在缓慢下降。

当智能体决定记住某件事——"用户更喜欢邮件而非Slack"——看起来只是一次写入。实际上，它是六次写入：向量存储中的一个新嵌入、关系数据库中的一行记录、会话缓存中的一个条目、事件日志中的一条记录、审计轨迹中的一个条目，以及上下文存储的一次更新。每一次写入都因为系统的某个部分对数据有合理需求而发生，每一次写入都引入了新的故障点。

这是基础设施层面的写放大，也是生产智能体部署中较为隐蔽的运营危机之一。它不会导致戏剧性的故障，而是导致部分故障：用户偏好在语义上可以被搜索到，但关系查询返回的是过时数据；审计日志显示某个动作已完成，但实际上从未完全提交；缓存是热的，但上下文存储没有更新，因此下一个会话在没有已学习模式的情况下启动。

理解这一切为何发生——以及如何应对——需要借鉴数据库内部知识，而不是智能体框架文档。

每一个从"我们有个聊天机器人"升级到"我们有个 Agent"的工程团队，都会撞上同一堵墙：他们的测试套件开始失去意义。

经典测试金字塔——70% 单元测试、20% 集成测试、10% 端到端测试——建立在三个基本假设之上：单元测试运行成本低、与外部系统隔离、结果确定可重复。Agentic AI 系统同时打破了这三个假设。所谓的"单元"是一次消耗 token 且每次返回不同结果的模型调用。一次端到端运行可能耗时数分钟，消耗的 API 预算足以让一位初级工程师整个迭代周期的测试都无法证明其合理性。而隔离性几乎无从实现，因为 Agent 的智能恰恰来自于与外部工具和状态的交互。

当一位人工贷款官员拒绝一份申请时，这个决定背后有一个具体的名字。这位官员接收了特定信息，经过深思熟虑后做出了行动。推理过程或许并不完美，但它是可归因的——有人可以被联系、被质询、被追责。

当一个 AI 智能体拒绝同一份申请时，留下的只有一条数据库记录。这条记录表明决定已做出，但没有说明原因，没有说明是什么输入驱动了这个决定，没有说明当时运行的是哪个版本的模型，也没有说明系统提示词是否在两周前悄悄更新过。当你的合规团队将这条记录交给监管机构时，监管机构不会满意。

这就是智能体审计追踪问题，而大多数构建 AI 智能体的工程团队至今尚未解决它。

大多数团队对待标注流水线的方式，就像对待他们 2019 年的 CI 脚本一样：它能运行，大部分时候如此，而且没人想去碰它。一个带有颜色标记行的共享电子表格。一个将任务路由到 Slack 频道的 Google 表单。三名承包商异步工作，在一个讨论串中对比笔记。

接着，一个模型发布后质量下降，评估（eval）以一种令人困惑的方向退化，事后分析（post-mortem）最终揭示了显而易见的事实：标签错了，而且没人构建任何东西来检测它。

标注不是一个数据问题。它是一个软件工程问题。那些以此方式对待它的团队——使用队列、模式（schemas）、监控和结构化的分歧处理——构建的 AI 产品会随着时间的推移而改进。而那些不这么做的团队则陷入了无法解释的重新标注循环。

你的 AI 产品三个月前上线了。你有显示延迟、错误率和 token 成本的仪表盘。你已经看到用户与系统交互了数千次。然而你的模型和上线那天相比，好的地方一样好，差的地方一样差。

这不是数据问题。你拥有的数据已经多得不知该拿来做什么。这是架构问题。那些告诉你模型哪里失败的信号，就躺在应用日志、用户会话和下游结果数据里。它们与任何能改变模型行为的东西断开了连接。

大多数团队把 LLM 当作静态制品，然后在外围包裹监控和评估。最优秀的团队则把生产环境视为一条永不停歇的训练流水线。

你的智能体完成了十二步工作流中的第三步，并自信地报告目标 API 返回了 200 状态。实际上并没有 —— 这个结果来自第一步，仍然停留在上下文窗口中。到第九步时，智能体已经基于一个从未真实存在过的事实进行了四次下游调用。工作流“成功”结束。没有记录任何错误。

这就是上下文污染（context poisoning）：它不是一种安全攻击，而是一种可靠性故障模式，即智能体自身积累的上下文变成了错误信息的来源。随着智能体运行时间变长、交互工具增多、管理状态增加，这种故障的发生概率会急剧上升。而且，与崩溃或异常不同，上下文污染对标准监控来说是不可见的。

负责任的 AI 部署核心存在一个悖论：你越努力让人类参与审查 AI 决策，这种审查就越失去意义。

2024 年哈佛商学院的一项研究让 228 名评估者获得了带有 AI 推理说明的 AI 建议。人类审查者与 AI 建议保持一致的可能性比对照组高 19 个百分点。当 AI 还提供叙述性理由——解释为什么做出某个决策——时，顺从度又增加了 5 个百分点。更好的可解释性反而产生了更差的监督效果。回路中的人类已经沦为表格上的橡皮图章。

用LLM智能体替换所有Zapier流程和RPA脚本的团队，往往在六个月后发现了同一件事：他们用"脆弱但可审计"换来了"灵活但难以维护"。Zapier流程以可预测的方式崩溃——第14步因API变更而失败。LLM工作流则悄无声息地出错——模型悄悄地将支持工单路由到错误的队列，直到客户升级投诉才被发现。审计日志只记录着"AI决策"，这用律师的话来说就是"没人知道发生了什么"。

答案不是回避在自动化中使用LLM，而是要有意识地判断哪些任务交给哪个系统，并架构好两者之间的接缝，使故障不会相互传染。

你的系统平均端到端延迟为 400ms，p95 是 4.2 秒，p99 是 11 秒。在产品规格中你承诺了"亚秒级"体验。仪表盘上的每个指标看起来都很正常，直到有人问起 5% 的用户遭遇了什么——这时，你一直引以为傲的平均值才成了埋葬你的东西。

这就是 AI 功能的延迟预算问题，它与你之前解决过的问题有着本质区别。当核心组件是数据库查询或微服务调用时，p95 延迟大致可预测，并且适用标准 SRE 技术。而当核心组件是 LLM 时，响应时间的分布呈重尾特征，依赖于输入，并且部分由你无法控制的条件驱动。在制定诚实的 SLO 之前，你需要一套不同的思维模型——更别说去达成它了。

2024 年 12 月，Zendesk 发布了一份正式事故报告，称从 2025 年 6 月 10 日到 11 日，客户无法访问所有 Zendesk AI 功能，持续时间超过 33 个连续小时。工程团队的修复措施栏是空的——什么都做不了。此次故障完全由其上游 LLM 供应商宕机引起，而 Zendesk 没有任何在没有该供应商的情况下恢复服务的架构路径。

这就是供应商可靠性陷阱最清晰的体现：你发布了一个功能，让它成为用户工作流程的一部分，通过隐性或显性的 SLA 承诺保证可用性，然后发现你整个可靠性状态受限于一个你无法控制、无法修复、甚至可能在上线前从未正式评估过的依赖项。

典型的 AI 叙事往往是这样的：你构建一个产品，添加一个 AI 功能，用户就能获得更智能的输出。这种框架虽然正确，但并不完整。更持久的优势根本不在产品层，而是在其底层运行的数据流水线中。

越来越多的工程团队悄然将 ETL 流水线中的正则规则、自定义分类器和手写解析器替换为 LLM 调用。结果是：流水线可以处理非结构化输入，适应模式偏移（schema drift），并对数千个类别的记录进行分类——而无需为每一个新的边缘情况重新训练模型。大规模运行这种模式的团队正在构建具有复利效应的数据资产。而那些仍将 LLM 纯粹视为产品功能的团队则不然。