273 篇博文 含有标签「llm」

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

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

大多数构建 LLM 系统的团队都从错误的问题开始。他们在了解系统到底哪里会出错之前，就先问“我该如何评测这个系统？”。然后，他们花几周时间构建评测基础设施，却测量了错误的东西，迅速达到了 90% 以上的通过率，最后发布了用户讨厌的产品。评测本身并没有错——它们只是没有在测量失败。

有效的评测工程（Eval Engineering）主要并不在于基础设施，而在于对你的特定系统而言，“好”究竟意味着什么，并建立精确且共识的理解。基础设施几乎是次要的。在成熟的 LLM 团队中，60–80% 的开发时间都花在错误分析和评测上，而不是功能开发。这个比例会让大多数工程师感到惊讶，直到他们将一个有缺陷的模型推向生产环境，并花了一周时间去调试到底是哪里出了问题。

Google DeepMind 在 2025 年末发布的一项研究分析了 5 种架构和 3 个大语言模型（LLM）家族中的 180 种多智能体配置。在讨论部分被掩盖的一个发现是：与单智能体基准相比，非结构化多智能体网络将错误放大了高达 17.2 倍。不是修复错误——而是放大错误。智能体们自信地在彼此的幻觉基础上进行构建，创造出回声壁效应，使每个独立模型的失败模式显著恶化。

这是多智能体对话框架核心的悖论。赋予它们强大力量的特性——智能体进行协商、批判、委派和修订——如果缺乏周密设计，也正是让它们变得危险的原因。理解基于对话的编排（orchestration）与传统流水线链式调用（pipeline chaining）之间的区别，是正确使用这两者的第一步。

2024 年，90% 的智能体 RAG（Agentic RAG）项目在生产环境中失败了。原因并非技术本身存在缺陷，而是工程师们仅仅将向量搜索、提示词（prompt）和大语言模型（LLM）组合在一起，称之为检索管道并直接发布——却忽略了从查询到回答之间每一层累积的失败成本。

经典的 RAG 是一个确定性函数：嵌入查询 → 向量搜索 → 填充上下文 → 生成。它单向运行一次，没有反馈循环。当查询是针对分块良好的语料库进行简单的单步查找时，这种方式很有效。但当用户询问“比较这五份合同中的责任条款”或“总结自第三季度事故以来我们的基础设施配置发生了哪些变化”，或者任何需要先综合多份文档中的证据才能形成答案的问题时，它就会惨遭失败。

一个 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）的替代方案似乎显而易见，但在生产环境中正确实现它比架构图所示的要困难得多。

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

大多数智能体（Agent）框架在早期都会犯一个关键性错误：将智能体视为一个函数。你调用它，它循环运行，然后返回。这种思维模型在演示（Demo）中行得通。但当一个现实世界的任务运行了 45 分钟，在第 23 步遇到速率限制（Rate Limit），而你却没有任何可以恢复的内容时，它就会崩溃。

生产环境的智能体运行时（Runtime）不是一个函数运行器。它是一个执行基座（Execution Substrate）——比起 Python 函数，它更接近于进程调度器或分布式工作流引擎。从一开始就理清这一区别，决定了你的智能体系统是能够优雅地处理故障，还是需要人工点击重试。

大多数 Agent 框架都默认采用同一种动作模型：LLM 输出一个 JSON 块，宿主系统对其进行解析，调用工具，然后返回结果。如此循环。这种方式整洁、可审计，且几乎被普遍使用——而这恰恰是问题所在。对于超出单一工具调用的任何场景，这种架构都会迫使你编写脚手架代码来解决 Agent 本可以自行解决的问题——前提是如果允许它编写代码。

还有另一种方法：给 Agent 一个 Python 解释器，让它输出可执行代码作为其动作。一项已发布的基准测试显示，与 JSON 工具调用相比，其 任务成功率高出 20%。内部基准测试显示，平均 LLM 往返次数减少了 30%。一个围绕这一理念构建的框架在发布后不久便登顶 GAIA 排行榜榜首（验证集准确率为 44.2%）。权衡在于执行环境更加复杂——但所需的工程量是可控的，而且带来的行为增益是实实在在的。

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

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