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

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

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

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

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

大多数 LLM 质量问题并非提示词（Prompt）问题。它们是上下文（Context）问题。

你花了数小时打磨完美的系统提示词。你添加了 XML 标签、思维链指令和精细的人设定义。你在一些输入上进行了测试，效果看起来很棒。然后你上线了产品。两周后，你盯着一个工单发呆：智能体一本正经地告诉用户错误的账户余额 —— 因为它检索到了前一个用户的交易记录。模型完美理解了指令，它只是拿到了错误的输入。

这就是提示词工程（Prompt Engineering）与上下文工程（Context Engineering）之间的核心区别。提示词工程问的是：“我该如何措辞？”上下文工程问的是：“模型现在需要知道什么，以及我如何确保它准确获得这些信息？”前者是文案写作，后者是系统架构。

一家公司交付了 7,949 个 AI Agent。其中只有 15% 能够正常工作。其余的要么静默失败，要么陷入死循环，或者在执行任务中途前后矛盾。这并非个别现象——企业级分析一致发现，88% 的 AI Agent 项目从未进入生产阶段，95% 的生成式 AI 试点项目以失败告终或表现严重不及预期。引人入胜的演示 (Demo) 与可靠系统之间的差距并非模型问题，而是架构问题。

那些成功交付了实际可用 Agent 的工程师们，在架构决策上达成了一系列共识，而这些决策与框架教程中的玩具示例截然不同。本文将探讨这些决策：层级如何划分、故障集中在哪里，以及为什么最难的问题从来不是提示词 (Prompt)。

大多数团队在发布他们的第一个 LLM 功能后，会在生产环境中因糟糕的输出而受挫，然后紧急加上护栏进行损害控制。结果是一个脆弱的系统，它会阻止合法的请求，减慢响应速度，并且在关键的边缘情况下仍然失效。护栏值得做好——但天真的方法会以你意想不到的方式伤害你。

以下是实际的权衡取舍，以及如何构建一个不会悄悄破坏你产品的护栏层。

大多数工程师学习提示工程都是倒着来的。他们从“发挥创意”和“一步一步思考”开始，反复迭代一个演示直到它奏效，然后在生产环境中发现模型有 15% 的时间在“幻觉”（胡编乱造），他们的 JSON 解析器每隔几小时就会抛出异常。让聊天机器人令人印象深刻的技术，往往不是让生产系统可靠的技术。

在将 LLM 功能部署到真实系统一年后，以下是真正区分有效提示和在负载下仍能保持稳定的提示的关键。

LLM 在生产环境中函数调用失败最令人惊讶的地方在于它们的来源。不是幻觉推理。也不是模型选错了工具。代理不稳定的首要原因在于参数构造：错误的类型、缺少必填字段、格式错误的 JSON、幻觉出的额外字段。模型本身没问题。你的 schema 才是问题所在。

这是个好消息，因为 schema 修复成本很低。

每次 AI 产品演示看起来都很棒。模型生成了一些貌似合理的内容，利益相关者频频点头，每个人都带着乐观的情绪离开会议。然后产品发布了，真实用户出现了，事情开始以没人预料到的方式走向下坡路。团队手忙脚乱地修复一个故障模式，却无意中制造了另一个，经过数周的“打地鼠”后，提示词已经变成了一个 2000 个 token 的庞然大物，没人再能完全理解它了。

根本原因几乎总是相同的：没有评估系统。那些发布可靠 AI 产品的团队很早就构建了评估系统，并将其视为基础设施，而不是事后才考虑的事情。那些停滞不前的团队则将评估视为“等产品更成熟了”才需要担心的事情。到那时，他们已经陷入困境。

大多数 AI 团队在产品发布六周后都会遇到同样的瓶颈。最初的演示令人印象深刻，原型按时交付，早期用户也褒奖有加。然而，"足以展示" 和 "足以留住用户" 之间的鸿沟变得无法避免。团队手忙脚乱——调整提示词、更换模型、添加防护措施——但产品却几乎纹丝不动。

那些真正能快速改进的团队有一个反直觉的习惯：他们花在架构上的时间较少，而花在审视数据上的时间更多。不是仪表盘。不是汇总指标。而是对话日志中那些原始的、糟糕的、单独的失败案例。

这是一份实践指南，旨在区分快速发展的 AI 团队和停滞不前的团队。

大多数 AI 团队都在错误地衡量事物，使用错误的方式，并且让错误的人参与其中。典型的评估设置是这样的：一个 1 到 5 的李克特量表，少量示例，以及一个初级工程师进行数据统计。然后有人会构建一个 LLM 评判者来自动化这个过程——六个月后却想不明白为什么整个系统漏洞百出。

如果方法得当，将 LLM 用作评判者是一种强大的模式。但“方法得当”这个词在句子中承载了大量工作。本文是一个具体的指南，教你如何构建与实际质量相关联、捕获真实回归问题并经受住生产环境考验的评估器。

如今大多数使用 LLM 构建产品的团队都在重复别人一年前犯过的错误。最代价昂贵的错误就是将模型误认为是产品。

在 LLM 驱动的系统（代码生成工具、文档处理器、面向客户的助手、内部知识系统）上线生产环境一年后，从业者积累了一系列辛苦换来的知识，这些知识与炒作周期所暗示的大相径庭。这些教训不在于选择哪个基础模型，或者 RAG 是否优于微调，而在于构建可靠系统的那些枯燥工作：如何评估输出、如何构建工作流、何时投资于基础设施、何时继续迭代提示词，以及如何思考差异化。

这是对这些实战经验的总结。

大多数团队将 RAG 上线并称之为检索策略。他们将文档分块、嵌入、存储向量，并在查询时运行最近邻搜索。这在演示中效果足够好。然而在生产环境中，用户开始报告系统找不到他们知道存在的文章、遗漏文档中字面意义上的错误代码，或者返回语义相似但事实错误的内容。

问题不在于 RAG。问题在于将检索视为一个一维问题，而它实际上一直都是多维的。