51 篇博文 含有标签「ai-agents」

大多数构建 AI Agent 的团队在第一个月都在追求性能：更好的提示词、更智能的路由、更快的检索。接下来的六个月，你则会忙于补救之前忽略的东西——治理（governance）。无法被审计的 Agent 会被法务部门叫停。没有权限边界的 Agent 会在预发布环境中造成混乱。没有人工升级路径的 Agent 则会在规模化运行时悄无声息地犯下严重的后续错误。

一个令人不安的事实是，大多数 Agent 部署之所以失败，并不是因为模型性能不足，而是因为围绕它的脚手架（scaffolding）缺乏结构。近三分之二的企业正在尝试 Agent；但只有不到四分之一的企业成功实现了生产规模化。差距不在于模型质量，而在于治理。

大多数构建 LLM 系统的人最初几周都会沉迷于优化提示词。他们进行 A/B 测试，争论该使用 XML 标签还是 JSON，并不断迭代系统提示词，直到模型输出看起来正确的内容。然而，一旦进入生产环境，加入真实数据、记忆和工具调用——模型就会开始出现各种提示词调优无法解决的异常行为。问题从来都不在提示词上。

生产级 LLM 系统的真实瓶颈在于上下文——即模型输入中包含什么信息、以何种顺序排列、信息量有多少，以及这些信息是否与模型即将做出的决策相关。上下文工程是将该输入空间作为系统首要关注点进行设计和管理的学科。它包含了提示工程，就像软件架构包含了变量命名一样：较小的技能依然重要，但它并不能大规模地决定最终成果。

这是一个在采用 AI 编程智能体的团队中不断上演的模式：一位开发者发现 Claude 违反了某条规则，于是他们在 CLAUDE.md 中添加了一个更清晰的版本。Claude 违反了另一条不同的规则，于是他们也把那条加上。几周后，这个文件达到了 400 行，而 Claude 忽略的规则比以往任何时候都多。解决方案反而让问题变得更糟。

发生这种情况是因为指令文件的一个基本属性，而大多数开发者从未将其内化：超过一定规模后，添加更多指令会导致模型遵循的指令变少。 正确编写指令文件与其说是追求完整性，不如说是进行无情的筛选 —— 知道该包含什么、该删除什么，以及如何构建其余部分。

你的 Datadog 仪表板显示零错误。延迟正常。所有服务都返回 HTTP 200。与此同时，你的 AI agent 刚刚在错误的时区预订了一个会议，幻觉了一个客户的订单历史，并为此烧掉了 4 美元的 token。

这正是让 agent 可观测性变得异常困难的原因：你现有的指标几乎无法告诉你 agent 是否真的在正常工作。

传统的分布式追踪建立在关于软件如何失效的一系列假设之上。LLM agent 违反了所有这些假设，而“我的基础设施是健康的”与“我的 agent 做出了正确的事情”之间的差距，正是大多数调试痛苦的根源。

一个 Shopify 规模的商户助手，每天处理 1,000 万次对话，在不进行优化的前提下每月成本高达 210 万美元 —— 而经过优化后，成本仅需 45 万美元。这 78% 的差距并非源于算法上的突破，而是来自缓存、路由以及一些大多数团队在收到账单前都会忽略的工程规范。

AI Agent 并不只是多了几个步骤的聊天机器人。单次用户请求会触发规划、工具选择、执行、验证，通常还有重试循环 —— 消耗的 token 数量大约是直接对话交互的 5 倍。一个运行 10 个周期的 ReAct 循环，其 token 消耗量可能是单次交互的 50 倍。在顶级模型的价格体系下，这种计算开销很快就会变成一项财务负担。

这篇文章将涵盖 Agent 成本的来源机制，以及能够真正产生影响的具体技术（附带数据支持）。

1969 年，Volker Strassen 发表了一种算法，使用比朴素方法更少的标量乘法来计算 4×4 矩阵。在 56 年的时间里，没有人做得更好。然后一个 AI 编程智能体重写了它——在生产环境中，部署在 Google 的全球基础设施上——并不是通过比人类数学家更聪明，而是通过运行一个循环：生成变体，评估它，保留有效的，重复。

这个循环才是重点。LLM 只是其中一个环节。其周围的架构才是让 AlphaEvolve 奏效的原因，理解这个架构能告诉你 AI 辅助工程正在走向何方。

你构建的一个智能体在最终输出评估中获得了 82% 的分数。你发布了它。两周后，你的支持队列里塞满了用户的投诉，抱怨智能体获取了错误的数据，使用了错误的参数调用 API，并且在错误的中期工作基础上生成了听起来很自信的回复。你回头查看追踪记录（traces）—— 发现智能体在 40% 的查询中路由都是错误的。最终输出评估从未捕捉到这一点，因为智能体往往还是误打误撞地得到了正确答案。

这是智能体评估中的核心陷阱：仅衡量最后输出的结果，无法告诉你智能体是如何到达那里的，而“到达那里”的过程正是大多数失败发生的地方。

大多数 AI Agent 的 Bug 并不是模型本身的 Bug。模型只是在执行它被告知的操作——出问题的是你放入上下文（context）的内容。在 Agent 执行到一定阶段后，问题不在于能力，而在于熵：噪声、冗余和注意力错位的缓慢积累，这会降低模型生成的每一项输出的质量。研究人员称之为“上下文腐烂”（context rot），而且所有主流模型——GPT-4.1、Claude Opus 4、Gemini 2.5——在任何输入长度增加的情况下，无一例外都会表现出这种现象。

上下文工程是专门管理这一问题的学科。它比提示词工程（prompt engineering）更广泛，后者主要关注静态的系统提示词。上下文工程涵盖了模型在推理时看到的一切：你包含什么、排除什么、压缩什么、将内容放在哪里，以及如何在长期运行的任务中保持缓存状态。

当单智能体（single-agent）系统在研究任务中失败时，人们的直觉是增加更多内存、更好的工具或更强大的模型。但在某些点上，问题不在于能力——而在于并发性（concurrency）。深度研究任务需要同时推进多个线程：从不同角度验证论点、跨领域扫描来源、实时交叉引用发现。单智能体按顺序执行这些操作，就像研究人员在做笔记之前先逐本阅读每一本书。回想起来，多智能体（multi-agent）的替代方案似乎显而易见，但在生产环境中正确实现它比架构图所示的要困难得多。

这篇文章讨论了多智能体研究系统是如何实际构建的——行之有效的架构选择、在生产环境中才显现的故障模式，以及在大规模应用中保持其有用性所需的工程纪律。

你将智能体连接到 50 个 MCP 工具。它可以查询数据库、调用 API、读取文件、发送电子邮件、浏览网页。理论上，它拥有所需的一切。但在实践中，一半的生产事故都源于工具使用——错误的参数、上下文预算超支、级联重试循环，导致成本是预期的十倍。

这是大多数教程都会跳过的部分：你加载的每个工具定义都是预先支付的 Token 税，甚至在智能体处理单条用户消息之前就开始计算了。连接了 50 多个工具后，仅定义一项就会在每次请求中消耗 70,000–130,000 个 Token。这并非极端情况——这是任何连接到多个 MCP 服务器的智能体的默认状态。

大多数 AI 智能体之所以昂贵，是因为一个细微的架构错误：它们将每一个中间结果都视为要反馈给模型的消息。每一次工具调用都变成了 LLM 上下文窗口的一次往返，而当一个中等复杂度的任务完成时，你已经为处理相同的数据支付了五次、十次、甚至二十次的费用。一个在三个分析工具之间传递的 2 小时销售录音，可能在路由上就花费你 50,000 个 token —— 而这还不是为了分析，仅仅是为了路由。

有一种更好的方法。当智能体编写并执行代码而不是逐个调用工具时，中间结果会保留在执行环境中，而不是上下文窗口中。模型看到的是摘要和过滤后的输出，而不是原始数据。这种差异不是渐进式的 —— 在实际工作负载中，token 消耗量减少了 98–99%。

大多数构建多智能体系统的团队都会遇到同一堵墙：系统在演示时效果出色，但在生产环境中却分崩离析。这并不是因为他们实现协作协议的方式不对，而是因为协议本身就是问题所在。

多智能体 AI 具有一种直观的吸引力。复杂的任务应该被分解为并行的工作流；专门的智能体应该处理专门的工作；编排器（orchestrator）将它们组合在一起，整体就会大于部分之和。这种直觉是错误的——或者更准确地说，它还不成熟。研究表明，在已研究的执行追踪中，多智能体系统在生产环境中的实际失败率在 41% 到 86.7% 之间。这不是调优问题，而是结构性问题。