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

当你的 Agent 执行退款、发送邮件、关闭工单或写入数据行时，该操作便脱离了系统并进入了现实世界。现实世界没有回滚按钮。客户已经看到了退款，收件人已经阅读了邮件。而当 Agent 在三步之后走错了方向，你的恢复计划通常只是复盘会议中的一句话：“我们告诉它以后不要再那样做了。”

“以后不要再那样做”不是撤销（undo）。它是对未来的承诺，却被用来解决过去的问题。令人不安的事实是，大多数 Agent 架构根本没有撤销已完成副作用的机制——不是机制不好，而是根本没有机制。Agent 可以规划、调用工具并重试，但它无法回头。它只有前进挡，没有倒车挡。

一个退款智能体正在处理一笔 42 美元的客户请求。它发出的工具调用是 refund(amount: 4200) —— 等等，这正确吗？如果后端以“分”为单位存储金额，那它完全正确。如果后端以“美元”为单位存储，那么客户刚刚得到了 4,200 美元的退款。两次调用在语法上都是完美的。两者都在微秒级内通过了 JSON Schema 验证。Schema 规定 amount 是一个数字，而 4200 毫无疑问是一个数字。

这是一类单元测试、Schema 验证器和大多数智能体评估（Agent evals）都会忽略的错误：工具调用边界处的单位混淆。模型会根据其训练数据进行数值模式匹配 —— 以美元计价的货币、以秒计价的时间、由周围文本暗示的重量单位 —— 而你的工具则期望的是分、毫秒或公斤。类型系统不会提出任何异议。发票金额只是偏差了 100 倍。

实验组之所以上线，是因为仪表盘显示“转化率 +4%，p < 0.01，n = 2.3M”。但在全球推行 6 周后，这一增长消失了。由于没有其他合理解释，团队将这次复盘报告归类为“规模效应”。然而，真正的原罪一直潜伏在提示词组装器（prompt assembler）中：决定实验分组的路由哈希（routing hash）派生自一个用户层级（user-tier）属性，而三行代码后，同样的属性被插值到了提示词模板中。模型直接在带内（in band）读取了分组分配。所谓的“实验干预”（treatment）并非提示词的改变，真正的干预是提示词改变后所吸引的用户群体。

这是一种在团队从 Web 时代继承的实验手册中并不存在的失效模式。按钮颜色不会读取用户层级并决定表现不同，但提示词会。一旦你的实验干预是一个由模型解释的字符串，那么任何触及路由决策且同时触及提示词的输入，都会变成实验无法关闭的后门。

一次隐私评审批准了你的脱敏层。姓名、邮箱、账号、电话——所有这些都在提示词送达模型之前被清理掉了。你的单轮分类器仍然能跑到 94% 的准确率。六周后，你的多步骤智能体开始对类似"Sarah 用于登录的邮箱和她账单记录里的邮箱是同一个吗？"这样的问题给出自信但错误的答案，而且没人能在开发环境里复现。

脱敏层做到了 infosec 团队要求它做到的一切。它同时也悄悄地摧毁了你的智能体推理所依赖的性质：在不同轮次中出现的两个实体指代是同一回事。这个智能体并没有产生幻觉，它读到的是一份转录文本，其中 Sarah 变成了三个不同的人，"同一个"邮箱地址变成了两个互不相同的占位符。

Model Context Protocol (MCP) 正如其初衷所愿：它让赋予智能体（agent）新能力变得几乎零成本。接入日历服务器、数据库服务器、公司内部服务器，或是厂商现今发布的 30,000 个工具目录中的任何一个，都只是一个配置更改，而不是一个开发项目。这种无摩擦感是其特性，但也是问题所在。

正因为添加工具的成本极低，每个团队都在添加工具。数据团队接入了仓库服务器。支持团队添加了工单服务器。有人为了某次性任务连接了文件系统服务器后就再也没移除。这些决策本身都没有错。但没有任何一个决策者对这些工具的“总和”负责——即你的智能体在每次请求中携带的聚合工具表面（tool surface）。工具列表已变成了一个具有实际持有成本的依赖图，而在大多数组织中，这是唯一一个无人负责的依赖图。

结果就是蔓延：工具目录单调递增，无人审查，每季度成本都在上涨，并悄悄地让智能体变得更糟。这就是无人负责的表面，它理应受到和你对待 API 表面以及 npm 树同等程度的审视。

一位后端工程师重命名了一个字段。user_id 变成了 customer_id，因为团队终于在所有服务中统一了 “customer” 这个术语。他们还增加了一个参数 region，因为计费系统现在需要它。这次变更通过一个包含两个批准的普通拉取请求（pull request）发布。每一个调用该端点的下游服务都在同一个发布版本中进行了更新。集成测试全部通过。按照后端团队衡量的一切标准，这是一次常规且执行良好的 API 变更。

一周后，支持工单开始增加。负责下单的智能体偶尔会在没有关联客户的情况下下单，或者将其关联到错误的区域。没有人改动过智能体。没有人改动过提示词（prompt）。模型的版本与上个月完全相同。然而，智能体现在却出现了一种以前从未有过的错误。

原因既不是模型中的 Bug，也不是后端中的 Bug。而是工具 Schema（tool schema）有两个消费者，但在审查变更时，只有其中一个在场。

当一个 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）只会表现为衡量智能体是否真正起到帮助的指标在缓慢下降。