161 篇博文 含有标签「agents」

一个令人不安的事实：80% 的 AI 项目未能提供业务价值，但团队却一直在追求最复杂的解决方案。一个具备工具调用、记忆检索和自主规划的多 Agent 编排系统可以做一个引人入胜的演示。而一个将客户支持工单路由到正确队列的简单 Prompt，在第一年就能为你公司赚到 200 万美元。这两种结果的可能性并不相等，普遍程度也不同，而行业一直在做出错误的选择。

这种模式是可预测的。一个工程团队构建了一些令人印象深刻的东西，向领导层演示，获得发布批准——然后眼睁睁地看着它在生产环境中悄无声息地退化。与此同时，竞争对手悄悄部署了一个封装了分类器的两百行 Python 脚本，从未进行过演示，却在每一项重要的业务指标上都超越了他们。

大多数团队选择一个分块大小，针对检索质量进行调优，然后就此止步。接着，他们在同一个索引上构建一个 Agent，并纳闷为什么 Agent 会以奇怪的方式失败——它只执行了一半的工作流，忽略了条件逻辑，或者根据不完整的指令自信地采取行动。使你的 NDCG 分数最高的分块大小，恰恰是让你的 Agent 变得不可靠的原因。

RAG 检索和 Agent 执行并不是同一个问题。它们有不同的目标、不同的失败模式，以及对什么是“好的分块”有着根本不同的定义。当你针对其中之一优化分块时，你就在系统性地削弱另一个。大多数团队直到已经在错误的架构基础上构建完产品后才意识到这一点。

你的智能体在第三轮对话时明确说过"绝对不要使用 eval()"。到了第三十轮，它调用了 eval()。你的保险处理系统规定"未经有效身份验证，不得批准理赔"。经过十五个压缩周期后，它批准了一笔。这些不是模型失败——是压缩失败。智能体的推理本身没有问题，是摘要中间件把那条唯一关键的约束丢掉了。

上下文压缩如今已成为长时运行智能体系统的标准基础设施。当对话历史增长到超出上下文窗口时，你就会进行压缩——把旧的轮次汇总成摘要，进行修剪、分块或精炼。问题在于，现代摘要器并不是随机破坏信息，而是可预测地沿着特定的断裂线破坏信息，而大多数团队只在生产环境中才发现这些断裂线。

你的 AI 功能在测试中运行完美。单轮问答，毫无问题。但在生产环境中，当真实用户进行一场 10 轮调试对话时，它却失败了——不是因为模型出了问题，而是因为你的速率限制器是为一个完全不同的世界设计的。

标准 API 速率限制是专为无状态 REST 调用设计的粗糙工具。每个请求被视为一个独立的、大致等量的消耗单元。对于 CRUD 端点而言，这种模型运行良好，因为每次调用确实具有可比性。但对于多轮对话，这种模型就行不通了——每一个后续轮次的成本都在递增，一次用户交互可能触发数十次内部模型调用，而会话中途被切断造成的损害，远比一次失败的单次查询严重得多。

你的 LLM API 调用在 P99 分位下于 500 毫秒内完成。但你的用户却在等待 12 秒。这两个数字都是准确的，谁都没有撒谎——它们只是在测量完全不同的东西。两者之间的差距正是大多数 Agent 系统性能无声流失的地方，而且大多数团队从未对其进行过监控（instrumentation）。

问题是结构性的：P99 LLM 延迟是一个应用于多步执行模型的单次调用指标。一个 ReAct Agent 进行五次连续的工具调用、重试一个幻觉化的函数、组装不断增长的上下文并生成 300 个 token 的推理链，这并不是一次 LLM 调用。这是一个分布式工作流，其中 LLM 只是一个节点，而其他每个节点都有其自身的延迟开销。

大多数团队都以相同的方式发现了同步 UI 的问题：用户点击"生成报告"，然后浏览器标签页陷入沉默长达四十秒。没有加载动画，没有进度提示，只有一个冻结的按钮。一半用户刷新页面并重复提交。另一半用户认为产品出了故障，直接关掉标签页。

根本问题不在于智能体的延迟——而在于 LLM 驱动的智能体所处的时间尺度，打破了同步请求-响应 UX 所有内置的假设。单次 GPT-4o 调用平均需要 8–15 秒。一个搜索网页、读取三份文档、写初稿再格式化输出的多步智能体，可能需要两到四分钟。你无法通过优化智能体来让这感觉变快，必须重新设计后端与 UI 之间的契约。

当两个微服务在API假设上出现偏差时，集成测试会在上线前捕获问题。当两个智能体在提示词假设上出现偏差时，你只会在客户收到自相矛盾的答案——或者整条流水线因级联故障崩溃——时才会发现。多智能体AI系统在生产环境中的失败率高达41%–87%。这些失败中超过三分之一并非模型质量问题，而是协调故障：某个智能体改变了输出格式，另一个智能体仍然期望旧的数据结构，而没有人为此写过测试。

根本问题在于，智能体之间通过隐式契约进行通信。一个研究型智能体——在某人的心智模型中——约定返回带有 sources 数组的JSON对象。编排型智能体依赖这个结构。没有人把它写下来，没有人测试它。六周后，研究型智能体的提示词被优化为返回排名列表而非 sources 数组，编排型智能体就悄无声息地丢失了一半输入。

一个智能体成功创建了 GitHub Issue、开启了 Jira 工单，并更新了共享表格。然后在发送 Slack 通知之前超时了。框架将此次运行记录为"已交付"。用户从未收到通知。副作用存在于三个系统中，而对人类真正重要的结果却没有送达。

这是生产智能体系统中最常见的超时失败模式，但几乎从来不是团队预先准备好的那种。大多数智能体实现把超时当作普通异常处理：捕获、记录、返回错误。即使智能体完成了 90% 的工作，用户也什么都得不到。问题不在于是否设置超时——每个生产系统都需要超时。问题在于当时钟走完时，智能体该如何应对。

一位我上季度合作过的 Staff Engineer 发现了一个在过去六周内已经被“修复”过三次的 bug。由三位不同的工程师处理，涉及三个不同的文件。三次 CI 运行都顺利通过。三次都采用了由 Agent 生成并被接受的补丁。每一个补丁都让失败的测试通过了，也让用户报告的错误消失了。但每一个补丁都只是把 bug 转移到了别处，潜伏在那里，直到被另一个表现面再次触发。当它第四次出现时，它导致的数据损坏已经静默累积了 40 天。

这个 bug 只是分页游标中一个简单的“差一错误”（off-by-one）。Agent 对于“症状会消失”的判断是正确的，但它对“原因”的判断是错误的。而那些优秀的、资深的、动机良好的工程师们，在理解失败机制之前，就各自接受了一个通过测试的补丁。

这就是“智能代理调试陷阱”（agentic debugger's trap）：你的 Agent 生成修复方案的速度，超过了你构建评估该方案正确性所需的心智模型（mental model）的速度。补丁速度超过了诊断速度。Bug 数量下降了，CI 面板变绿了，而你交付的代码库，其失败模式你却不再理解。

一个用于市场数据研究的多智能体系统在无人察觉的情况下，在四周内悄悄烧掉了 47,000 美元的推理成本。原本的每周账单仅为 127 美元。原因既不是流量激增，也不是模型升级——而是两个智能体在十一天里来回传递同一个对话，每个智能体都确信对方才是处理该请求的正确位置。没有任何报错。没有任何警报触发。一个机器人的“队列已转移”指标和另一个机器人的“任务已接收”指标都在同步增长，两边的仪表盘看起来都很健康。

这就是闭环升级漏洞 (closed-loop escalation bug)。它是两个热心的同事互相坚持“不，你来处理”的多智能体版本，只不过他们谁都不会感到厌烦并走开。你在设计时画的架构图中，每个专业智能体都拥有一块清晰的问题领域。而运行时实际执行的架构却包含了一个房间里没人能看到的路由循环。

AI 编程工具的默认思维模型是 VS Code 内部的一个面板。一个对话框，几个行内建议，或许还有一个“应用差异（apply diff）”按钮。这种构想已经过时两年了。该领域的领先产品并不是 VS Code 扩展；它们是完整的编辑器，只是启动时碰巧看起来像 VS Code。Cursor 是一个分叉版本（fork）。Windsurf 是一个分叉版本。Zed 是一个从零开始构建的原生编辑器。这种模式并非巧合 —— 当智能体（agent）的覆盖面最终超过了宿主编辑器的插件 API 所能支持的范围时，必然会出现这种情况。

如果你正在构建一个编程智能体，并且仍然将“发布一个插件”视为理所当然的分发选择，那么你即将撞上那些领跑者在 2024 年左右遇到并选择翻越的那面墙。这面墙有个名字：插件 API 是为了给人类控制的编辑器添加功能而构建的，而不是为了托管一个想要控制编辑器的自主智能体。

你的智能体管道很慢，于是你把任务拆分给五个并行子智能体。p50 下降了，你把它上线了。三天后，告警响了：一批用户请求超时。你挖进去发现 p99 从 4 秒涨到了 22 秒。单个智能体本身没有任何变化。超时是因为编排层在等最慢的那个——它以 1% 的概率遇到了检索抖动，但现在任何触碰全部五条路径的请求都会遇到这个概率。

这就是并行陷阱：这个模式看起来是显而易见的提速方案，实则以一种伤害真实用户更多的方式重构了延迟分布，p50 的改善远不能弥补 p99 的恶化。在生产基准测试中，单个智能体在 64% 的评估任务上能匹配甚至超过多智能体管道。并行扇出奏效的时候，确实奏效得很干净——但仅限于特定类别的问题。把扇出当作默认选项，才是错误所在。