17 篇博文 含有标签「llm-engineering」

当一个 PlanCompiler 风格的智能体（agent）与直接的 LLM 生成代码模式在 300 个分层多步任务中进行基准测试时，结构化方法实现了 92.67% 的成功率，单任务成本为 $0.00128。而直接方法——即 LLM 在自由形式的循环中逐步决定行动——成功率为 62$0.0106。这意味着准确率提高了 50%，而成本仅为原来的八分之一。

差异不在于模型的能力。两种方法使用的是同一个模型。差异在于架构：一个将计划生成与计划执行分离开来；另一个则将两者混为一谈。

你交付了一个工具，让你的 Agent 可以获取用户个人资料。描述中写道：“通过用户 ID 检索用户信息。”六周后，后端团队将 user_id 重命名为 customer_uuid 并添加了一个必填的 tenant_id 字段。没有人更新工具的 Schema。你的 Agent 继续调用旧的签名，收到 400 错误，将空结果解释为“未找到用户”，并“热心地”创建了一个重复记录。

日志中没有错误。没有触发任何报警。Agent 全程都非常自信。

这就是工具文档问题：Schema 漂移将陈旧的描述变成了隐性故障向量。这可能是当今生产环境 AI 系统中最被低估的可靠性风险，而且你的 Agent 运行的时间越长，情况就越严重。

演示总是成功的。这是 AI 产品开发中最昂贵的一句话。产品经理看到模型处理好了理想路径（happy path），工程师发布了该功能的直观版本，六周后，支持队列里塞满了指标未能预见的投诉。模型本身没有退化。提示词（prompt）也没有变糟。只是该功能的形态并非模型所擅长的，而团队在工作开始前没有办法指出这一点。

相当大一部分已发布的 AI 功能都是以这种方式失败的——不是因为模型不好，而是因为任务错了。产品需要的输出是确定性的，而引擎是随机性的。用户对长尾误差的容忍度是千分之一的错误率，而模型的失败分布比这更厚。单位经济效益（unit economics）要求的延迟预算只有你在可负担范围内模型所能提供的一半。评估质量所需的地面真值（ground truth）并不存在，也无法低成本创建。这些都不是模型问题。它们是任务形态（task-shape）问题，应该在写下第一条提示词之前就被筛选出来。

大多数工程团队对待 LLM 上下文窗口的方式，就像早期 Web 开发者对待全局变量：先塞进去，问题以后再说。上下文里堆满了最近 40 轮对话、仓库里的三个完整文件、十几份检索到的文档，以及一个经过六个月集体修改、越来越臃肿的系统提示词。一切看起来都能运行——直到某天突然不行了，而那时已经很难判断究竟是哪里出了问题。

上下文窗口不是堆内存。它更接近于 CPU 寄存器文件：容量有限、单位成本高昂，且其内容直接影响模型执行的每一次计算。当你把寄存器当成草稿纸随意使用而忘记管理时，程序会以各种匪夷所思的方式崩溃。当你把上下文窗口当成草稿纸时，LLM 会以悄无声息且代价高昂的方式退化。

高层级智能体框架承诺将三天的集成工作转化为三小时的原型开发。这个承诺是真实的。问题在于接下来发生的事情：在一家开发 AI 驱动的浏览器测试智能体的公司中，工程师们在进入生产阶段六个月后发现，他们花在调试 LangChain 上的时间竟然和开发功能的时间一样多。他们的解决方案很彻底——完全弃用了框架，并回退到模块化的构建块。“一旦我们移除了它，”他们写道，“我们就不再需要将需求转化为符合 LangChain 规范的方案。我们可以直接编码。”

他们并不孤单。大约 45% 尝试使用高层级 LLM 编排框架的开发者从未将其部署到生产环境。另有 23% 的开发者在上线后最终将其移除。这些数字并不意味着框架是糟糕的工具——它们意味着框架是具有特定有用范围的工具，而那个范围比演示中展示的要窄。

你的智能体中杠杆率最高的 prompt 并不在你的系统 prompt（system prompt）中。它是你六个月前在某个工具定义下写的那句描述，它随实现代码一起提交，之后就再也没动过。模型在每一轮对话中都会读取它，以此决定是否调用该工具、绑定哪些参数，以及当响应不符合预期时如何恢复。工程师将其视为面向人类的 API 文档，而模型则将其视为一个 prompt。

这两种视角之间的鸿沟，正是最糟糕的工具使用（tool-use）类 bug 的温床：模型调用了正确的函数名，传入了正确的参数，发出了正确的 API 调用 —— 但原因却是错的，场景是错的，或者它放着旁边更合适的工具不用。没有任何异常抛出。你的评估套件依然通过。这种退化（regression）只会表现为衡量智能体是否真正起到帮助的指标在缓慢下降。

大多数团队对待标注流水线的方式，就像对待他们 2019 年的 CI 脚本一样：它能运行，大部分时候如此，而且没人想去碰它。一个带有颜色标记行的共享电子表格。一个将任务路由到 Slack 频道的 Google 表单。三名承包商异步工作，在一个讨论串中对比笔记。

接着，一个模型发布后质量下降，评估（eval）以一种令人困惑的方向退化，事后分析（post-mortem）最终揭示了显而易见的事实：标签错了，而且没人构建任何东西来检测它。

标注不是一个数据问题。它是一个软件工程问题。那些以此方式对待它的团队——使用队列、模式（schemas）、监控和结构化的分歧处理——构建的 AI 产品会随着时间的推移而改进。而那些不这么做的团队则陷入了无法解释的重新标注循环。

你的智能体完美地完成了第一步到第六步。第七步与第二步相矛盾。第八步幻觉出了一个并不存在的工具。第九步自信地提交了垃圾内容。没有程序崩溃，没有抛出错误。智能体只是忘记了它正在做什么 —— 并且无论如何都在继续。

这就是上下文窗口悬崖（context window cliff）：即 AI 智能体积聚的上下文超过其有效推理能力的时刻。它不会优雅地失败，也不会寻求帮助。它会基于部分信息做出自信但错误的决策，而你直到损失造成才会察觉。

你对模型进行了安全微调。评估套件显示它以 98% 的比率拒绝有害请求。然后你将它部署到生产环境，你的医疗文档助手开始对常规临床术语含糊其辞，你的法律研究工具拒绝总结涉及暴力的判例法，你的代码生成流水线给每个 shell 命令包裹了三层警告。完成率下降了 15%。用户满意度暴跌。模型更安全了——但也更没用了。

这就是对齐税：安全训练对语言模型施加的可衡量的任务性能退化。每个交付 LLM 驱动产品的团队都在支付这笔税，但大多数团队从未量化过它——更少有人知道如何在不牺牲所需安全属性的前提下降低它。

在每个 AI Agent 项目中都有一个特定的时刻——框架不再帮忙了。你发现自己花在阅读框架源码上的时间比写业务功能还多的时候，你就知道这个时刻到了。那些本该帮你屏蔽复杂性的抽象，反而成了复杂性的主要来源。

这就是抽象反转问题：当一个框架迫使你在高级抽象之上重新构建底层原语——而这些高级抽象本来就是为了隐藏这些底层原语而设计的。这个术语来自计算机科学，它描述的是当抽象层缺少你需要的逃生通道时会发生什么：你最终不得不在抽象之上重新构建底层能力，代价更高，用起来也更别扭，还不如一开始就不用这个抽象。

在 AI 工程领域，这个问题已经泛滥成灾。团队采用编排框架期望加快速度，几周内就撞墙，然后花几个月时间来绕过这个本该加速他们的工具。

你的 AI Agent 刚刚为了回答一个只需要两次调用的问题，进行了十二次 API 调用。你没有注意到这一点，因为工具调用没有 EXPLAIN ANALYZE，没有 ORM 分析器来标记问题，而且 Agent 最终还是得到了正确答案 —— 只是晚了两秒钟，且 Token 预算超支了三倍。

这就是 N+1 查询问题，它已悄然从数据库层迁移到了你的 Agent 工具调用层。坏消息是：这种故障模式与 2010 年代毒害 Web 应用程序的模式完全相同。好消息是：那个时代的解决方案几乎可以直接移植过来。

你的 AI Agent 在开发阶段的成本比你想象的要低，但在生产环境中的成本却远超你的预料。API 账单——大多数团队针对其进行优化的指标——仅占在生产环境中运行 Agent 真实总成本的 10–20% 左右。其余部分则隐藏在大多数工程预算从未明确建模的层级之中。

这很重要，因为决定大规模部署 Agent 并不是一个真正的技术决策。而是一个单位经济效益决策。那些基于不完整成本模型做出决策的团队，正是六个月后报告投资回报率 (ROI) 为负的那些团队。