实际应用中的持久化AI智能体：成本问题、内存偏移以及80%的问题。

大约两年来，使用模型的标准方式是通过对话进行。你输入消息，阅读回复，然后要么采纳它，要么对其提出异议。你处于一个循环中，在任何内容被使用之前都会先进行检查。后来思路发生了转变：不再输入提示语，而是让具备记忆功能、工具以及无需在每一步都被监控即可完成任务权限的智能体自主运行。试着让这类能够阅读代码、执行命令并提交拉取请求的智能体运行一周，这种做法在某些方面确实有效，但很多情况下并不行。失败往往以相当可预测的顺序出现。

人们为何放弃使用提示语

放弃使用提示词实际上反映了某种根本性的限制。提示词仅包含一个问题与一个答案，适用于简单查询，但在需要模型从多个来源收集信息、对已有知识进行推理、使用工具并根据反馈结果进行调整的场景中表现不佳。要求模型一次性完成所有这些工作并不符合实际工作流程。

真正需要的是一个循环：思考、行动、查看结果、再次思考。若再加上能在会话之间保留信息的机制，就能实现人们所说的“持久化智能体”。有一个区别需要尽早明确：聊天记录并非智能体的记忆，而记忆更像是智能体可以读写以存储信息的文件。这一差异将在下文中进一步阐述。

因此这一举措是合理的，没人应该装作不然。重要的是真正实施之后会发生什么，从成本开始，到最终谁仍要对结果负责为止。

费用问题

没人提及的第一点是：每次API调用都是从零开始。服务提供方不会保留之前调用的记录，所以程序每次请求数据时都必须重新发送整个对话内容。第一步的成本很低，但到了第二十步，随着工具输出和更多细节的加入，每次调用可能包含数千字的内容，而你每次都要为这些内容付费。

计算起来会让人感到不安。对三十个工程团队的调研显示，任务中某个步骤的延迟会导致约15美分的损失。这听起来微不足道，但若考虑到每个任务有五十个步骤、每位开发人员每天要处理数十个任务，再加上整个团队的话，每月的损失就会达到六位数的水平，而且执行这类任务的智能体所消耗的令牌量远高于普通聊天。

成本失控是另一个风险。如果智能体不断重试那些注定无法成功的事情，就会持续产生费用。有这样一个传闻：某家公司就因为这种状况而被收取了5亿美元的账单。无论这个数字是否准确，一个配置错误的智能体在处理一个仅需10分钟的手动任务时却耗尽每日预算，这种情况是完全有可能发生的。令人不安的是，在这一切发生时，一切看起来都很正常——智能体仍在工作，只是陷入了循环而已。

在实践中行之有效的解决方案包含三个部分：

• 为每个智能体设定固定的每日预算，并在智能体外部进行管控
• 采用滚动式上下文窗口，使早期的处理步骤自动移除而不堆积
• 将常规任务交给成本较低的模型处理，仅将复杂案例转交给性能更强的模型

采用这种简单管控措施的团队表示，智能体的成本在一个月内下降了50%以上。更强大的模型并非关键所在，真正起作用的是约束机制——坦白说这一点很重要，因为当账单出现时，人们的第一反应往往是寻找更好的模型。

第一个拉取请求其实是个陷阱

智能体的第一个拉取请求看起来可能非常出色：整个功能几分钟内就完成了，所有测试也都通过，人们自然会感到宽慰。但随后就会怀疑实际工作并未完成，而这种怀疑通常是对的。

各个团队不断报告同样的问题模式：最初的 Pull Request 效果不错，但到第五个时，生产环境中就会出现测试未能发现的故障。可能是缺少重试机制，或是未处理空值情况，又或者是身份验证仅覆盖了三个接口端点而遗漏了第四个。代码虽然能运行，却经不起实际环境的考验。

这通常被称为“80%问题”。自动化工具能够完成那些显而易见的80%的任务，却总是忽略那20%由非功能需求、故障模式和架构一致性构成的部分，因为这20%需要自动化工具所不具备的上下文信息。它生成的只是能运行的代码，而非经得起时间考验的稳定代码。

这种问题的简短概括就是：代码虽然能编译通过代码检查，但由于人们对其重视不足，仍然会出错。输出结果看似完整，因此人们只会快速浏览一下，就像查看初级员工完成的工作那样草率了事。

事后修复的成本远高于一开始就正确处理。这类问题在整个代码库中反复出现，因此没有单一的位置可以修复它们。

内存有两种类型

最大的问题在于内存，它以两种起初并不明显的形式存在。

第一种是在执行任务时遗忘信息。当某个任务运行时间过长，智能体就会忘记早先做出的决策。业界通常的解决办法是提供更多上下文，比如一百万或两百万个标记，认为看到所有信息就能做出正确决策。但这种做法并不奏效。智能体面对大量复杂的代码时会感到困惑，它可能解决了某个问题，却引发了更大的问题，因为它只能看到零散的细节，而无法理解整体。

第二种形式更为隐蔽，也是造成真正危害的那种：上下文偏移。智能体遵循配置文件和规范文件行事，而代码库却在不断演变，这些文件却始终未变。很快，一个持续运行的工作进程就会按照数月前就已过时的标准来编写代码，而且看起来一切正常，因为它只是在遵循来自陈旧信息的指令。当这种情况在多个智能体和代码库中普遍存在时，这种差距就会在悄无声息中日益扩大。

这样一来，责任就不再归于模型本身。出问题的并非模型，而是项目的记忆机制——即存储在磁盘上、能超越任何会话期限而存在的部分，因为它并未得到妥善构建。

开发者的工作内容发生了变化

开发者并没有减少，只是他们的工作内容发生了转移，实际结果既没有宣传中那么夸张，也没有反对者所说的那么糟糕。

一旦智能体运行时间较长，提示语的精心设计就不再那么重要了。真正关键的是上下文：智能体能看到什么、能记住什么、被允许做什么，以及如何了解它的行为。那些取得成果的团队并没有使用什么巧妙的提示语，而是编写规范、及时更新这些规范，将其作为智能体的记忆输入，并亲自审查其架构。

以规范为导向的工作方式让开发者变得更为重要，同时也决定了工作的重点：明确智能体应执行的任务、审批它可采取的行动范围，并审查其提出的架构。当需求发生变化时，调整的是规范而非提示语。智能体只是根据这些规范进行草拟、实现和测试，它并不决定发展的方向。正是这种分工才避免了系统出错。

在这一切背后，隐藏着一种克制的尖锐性。有一项研究对实际代码库中的开发者进行计时测试，发现他们的工作效率比自我感觉慢约19%，尽管他们觉得自己快了20%左右。快速的感觉与实际的速度已经出现了分离。如果任由这些持续运行的智能体自行运作，这种差距还会进一步扩大，因为它们擅长营造出速度感。而缩小这一差距的，则是那些枯燥但必要的措施：管理规范、代码审查、符合现实的规格要求以及支出上限。

回归纯粹的提示方式并非解决方案，因为循环机制更为强大。但这类智能体并非同事，而是快速且自信的承包商，而且从不承认自己存在不确定之处。人们会保留这样的承包商，是因为他们很有用，而且每次都会仔细阅读他们交给自己的所有内容。