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

有一个 100 行代码的 Python Agent，在 SWE-bench Verified 上获得了 74–76% 的评分——仅比资金雄厚的团队构建的最先进系统低 4–6 个百分点。执行循环本身并不是复杂性所在。世界级的团队会投入 6 到 12 个月的时间来围绕该循环构建基础设施。这种基础设施有一个名字：Harness。

公式很简单：Agent = Model + Harness。Model 负责推理，Harness 负责其他一切——工具执行、上下文管理、安全管控、错误恢复、状态持久化以及人在回路（human-in-the-loop）工作流。如果你花了几个月的时间优化 Prompt 和模型选择，却交付了脆弱的 Agent，那么你一直在优化错误的东西。

Wait, I should double-check the truncate tag and headers.

大多数构建 LLM 应用的团队都会陷入两种失败模式之一。第一种是完全不建立评估（Evals），凭感觉发布功能。第二种是在还没搞清楚到底要衡量什么之前，就构建了复杂的评估基础设施。这两种都是代价高昂的错误。

表现优秀的团队有一个共同点：他们从观察数据开始，而不是从构建系统开始。错误分析优先于自动化评估。在信任任何自动评判器之前，先用人工判断为指标奠定基础。他们不把评估看作是一个需要跨越的里程碑，而是一个随着产品共同演进的持续准则。

这就是 Evals 在实践中的真实样貌——那些至关重要的决策、浪费精力的模式，以及在你被“坑”过之前都不明显的权衡。

大多数团队构建 LLM 评估器（evaluators）的顺序都是错误的。他们先写标准，然后再看数据。这种倒置是评估失准的根本原因，而且在交付首个 AI 产品的团队中几乎普遍存在。这些标准在纸面上听起来很合理 —— “回复应当准确、有帮助且简洁” —— 但当你将它们应用于真实模型输出时，你会发现评分标准（rubric）与你真正关心的内容并不匹配。你最终得到的评估器评分的是你并未衡量的内容，却漏掉了真正重要的失败情况。

解决方法不是制定更好的评分标准。而是一个不同的工作流：先看数据，再定义标准，然后在信任其进行无人值守运行之前，根据人类判断验证你的评估器。

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

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

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

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

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

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

大多数将生成式 AI 技术栈视为模型集成项目的团队，最终都会发现他们实际上构建了——或需要构建——一个平台。模型是最简单的部分。难点在于它周围的一切：将查询路由到正确的模型、可靠地检索上下文、过滤不安全的输出、缓存冗余调用、在由五个 LLM 调用组成的链条中追踪出错原因，以及随着使用规模扩大，防止成本逐月翻倍。

本文讨论的就是这个平台层。不是模型权重，也不是提示词——而是将一个可行的原型与一个你可以放心交付给百万用户的系统区分开来的基础设施。

大多数工程师将提示词（prompts）视为咒语——稍微修改一下措辞，寄希望于它能奏效，然后就此作罢。这在演示阶段（demos）没问题。但在生产环境中，这会导致系统表现不稳定：没人知道为什么模型在周二的表现与周一不同，一次常规的模型更新可能会悄无声息地破坏掉三个功能。正确的提示工程是一门学科，而不是一种仪式。本文涵盖了全栈内容：何时使用每种技术、基准测试（benchmarks）实际显示了什么，以及陷阱在哪里。

当 GPT-4o、Claude 3.5 Sonnet 和 Llama 3.1 405B 在 MMLU 上的得分都在 88–93% 之间时，这个数字究竟能告诉你该部署哪种模型？令人不安的答案是：几乎什么也说明不了。曾经能区分优秀模型与平庸模型的基准测试已经饱和。每个前沿模型都能在测试中取得优异成绩，但它们在生产环境中的表现却大相径庭。基准测试表现与实际效用之间的差距从未如此之大，理解其中的原因对于任何基于 LLM 构建的工程师来说都至关重要。

基准测试之所以显得严谨，是因为它们产生了数字。数字看起来像测量，而测量看起来像真理。但基准测试分数的合法性完全取决于它所测量内容的有效性——而这种有效性往往会以排行榜上鲜有提及的方式崩溃。

当你的智能体在放弃之前，第三次默默地重试同一个损坏的工具调用时，你就会意识到，“仅仅添加工具”并不是一种生产环境的策略。工具调用解锁了真正的能力——外部数据、副作用、保证格式的输出——但使其工作的智能体循环（agentic loop）具有在演示中不会表现出来的尖锐边缘。

这篇文章将探讨这些边缘：循环实际上是如何运行的，悄悄破坏并行执行的格式规则，如何编写能让模型做出正确选择的工具描述，以及如何处理错误以让模型恢复而不是陷入死循环。

当团队从单智能体系统转向多智能体 AI 系统时，一个模式会反复出现：单个智能体在独立运行时表现完美，但系统作为一个整体却表现得难以预测。问题不在于智能体本身，而在于它们之间的边界。

针对生产环境多智能体部署的研究表明，在缺乏正式编排的情况下，失败率在 41% 到 86.7% 之间。最常见的复盘结果并非“LLM 给出了错误的答案”，而是“错误的上下文在错误的时间传达给了错误的智能体”。智能体之间的接缝正是系统悄然崩塌的地方。

一个构建支持分流系统的团队将其分类流水线从 GPT-4o 切换到了 o3。准确率提升了 2%。成本上升了 900%。延迟从 400 ms 跳升至 12 秒。他们最后切回去了。

这是目前生产环境 AI 中最常见的故事。推理模型代表了真正的能力飞跃 —— 在之前没有模型能超过 2% 的 Frontier Math 基准测试中，o3 解决了 25% 的问题。但这种能力伴随着成本和延迟的代价，使得它们在普通生产系统的多数任务中并不适用。理解其中的差异是 AI 工程师现在能掌握的最有价值的事情之一。