32 篇博文 含有标签「llm」

大多数在生产环境中部署的多智能体 LLM 系统，在几周内就会失败 — 失败并非源于基础设施中断或模型退化，而是因为从一开始就存在的协调问题。对七个开源框架的 1,642 条执行轨迹进行全面分析后发现，在标准基准测试中，其故障率在 41% 到 86.7% 之间。这不是模型质量问题，而是系统工程问题。

令人不安的发现是：约 79% 的故障可追溯到规范和协调问题，而非计算限制或模型能力。即使你换一个更好的模型，你的多智能体管道仍然会以同样的方式崩溃。要理解其原因，你需要仔细审视故障分类。

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

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

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

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

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

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

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

第一次一个 AI 编程代理破坏了一个团队的 CI 流水线——不是因为它编写了糟糕的代码，而是因为它生成拉取请求的速度超过了 GitHub Actions 的处理能力——这清楚地表明一些根本性的东西已经发生了转变。我们不再讨论一个更智能的自动补全工具。我们讨论的是一种完全不同的软件生产模式。

AI 辅助编程的发展轨迹迅速。自动补全工具改变了个人打字的方式。本地代理改变了单个会话能完成的任务。云代理现在正在改变团队构建软件的方式——将工作并行化到多个异步线程中，在提交 PR 之前运行测试，并且越来越多地处理长达 3 小时的任务，而开发人员则可以休息或转去解决其他问题。

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

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

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

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

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

大多数智能体故障都是架构故障。当任务偏离轨道时，模型往往会受到指责，但十有八九，真正的问题在于没有人充分思考规划、工具使用和反思应该如何协同工作。即使你换一个更好的模型，仍然可能会遇到同样的崩溃——因为模型周围的支架从未被设计成处理模型被要求完成的任务。

本文是一份关于智能体内部实际工作原理的实用指南：核心组件是什么，规划在哪里出错，反思循环如何帮助（以及何时会损害），以及当你为生产而非演示构建多智能体系统时它们会是什么样子。

大多数使用 LLM 构建产品的工程师都经历过相同的轨迹：两天内跑通 demo，六周后生产环境一片混乱。这项技术在真实负载、真实用户和真实数据下的表现截然不同。从中得出的教训不是哲学层面的，而是操作层面的。

在观察了众多公司的团队发布（有时也放弃）LLM 驱动产品之后，一些规律反复出现。这些不是边缘案例，而是普遍经历。

大多数 LLM 演示都能正常运行。但大多数生产环境中的 LLM 应用却并非如此——至少不稳定。一个引人注目的原型与能够承受真实用户流量的应用之间的差距，比我接触过的任何其他软件类别都要大，而且故障很少发生在你的预期之中。

这是一份关于容易出现故障的环节的指南：成本、一致性、组合和评估。这不是理论，而是导致团队在首次成功演示三个月后悄然搁置项目的具体问题。

大多数声称在“生产环境中有智能体”的团队其实没有。调查一致显示，大约 57% 的工程组织已经部署了 AI 智能体——但当你应用严格的标准（LLM 必须能够规划、行动、观察反馈并根据结果进行调整）时，只有 16% 的企业部署和 27% 的初创公司部署符合真正的智能体标准。其余的只是加装了工具调用功能的“美化版”聊天机器人。

这种差距不在于模型能力，而在于架构。真正的自主智能体需要三个相互关联、协同工作的子系统：规划、记忆和工具使用。大多数实现只正确地完成了其中一个，部分实现了第二个，却忽略了第三个。结果是系统在演示中表现出色，但在生产环境中却会不可预测地失败。

演示总是有效的。用精选的例子提示模型，获得清晰的输出，将截图发给利益相关者。六周后，系统面对真实用户，而演示中的例子却一个都没有出现在生产流量中。

这是每个LLM产品团队最终都会遇到的鸿沟：从“它在我的输入上有效”到“它在我未曾预料的输入上都有效”的飞跃。弥合这一鸿沟的模式并非关于模型选择或提示词的巧妙，而是关于系统设计。七种模式解释了功能原型与可靠生产系统之间的大部分差异。