AI智能体开发，别只盯着大模型那一步

去年有一些朋友跟我说过, 他的公司打算开展所谓的人工智能智能体业务, 而该朋友讲出的第一句话内容竟然是只需要接入大语言模型就可以了。对此我沉默了三秒钟的时间, 并且对他说，你这种做法并不称作是智能体行为, 这种情形只是给一个聊天机器人套了一个外壳而已。

这句话讲得虽然可能不太中听, 但实际上它准确地指出了很多人存在的一个认识上的误区。智能体和大型语言模型之间的关系, 在本质上有种类似司机与发动机之间的那种关联。发动机的性能非常强大, 并且动力十足, 这并不代表驾驶者本人就具备高超的驾驶技术或者能够顺利地把车开走。

AI智能体开发到底在开发什么

先说结论: 一个完整的AI智能体, 至少要包含5个模块, 感知、规划、记忆、行动、反思。

感知模块负责接收包括文本、图像以及音频在内的多模态输入；规划模块利用大语言模型的推理能力, 将最终目标拆解为若干个子任务；记忆模块划分为短期记忆和长期记忆两种类型, 其中短期记忆存在于上下文窗口中, 而长期记忆通常存储在向量数据库里；行动模块负责调用各类工具, 这些工具的例子包含搜索功能、代码执行机制以及API请求等操作。

大家总是最常把那个叫做反思的关键环节给忽略了, 它的主要作用是让智能体在处理完每一轮行动以后去检查结果怎么样, 然后根据评估的情况来做出决定判断接下来是继续往下做还是退回来。

在2024年斯坦福大学发布的关于的那篇论文里面, 研究人员测试了七种市面上主流的技术框架。他们发现, 如果在系统里加上反思模块之后, 执行多步任务的成功率, 平均而言提升了百分之十一点三。

这个增长的数据看起来可能并不特别显著, 但是呢, 一旦你面对那种需要依靠连续操作来完成的任务场景, 前后的差距就很清楚了。

AI智能体开发的流程是怎样的

说句老实话, 这里头其实是没有标准答案的, 然而绝大多数的团队都是走上了这一条路:

第一步, 需要先把任务的边界给明确地定义清楚。你的那个智能体, 它究竟是要去解决什么样子的一个问题? 它的输入内容是什么? 它的输出结果又应该是怎样的? 如果失败了的话, 什么样的情况会被被视为是失败的标准? 要把这一步给做好, 如果这步做得不好, 那么后续的工作就全都是白费力气, 全都白搭。

第二步, 去挑选那个模型还有那个架构方面的事儿。到底是要用一个单模型, 还是让多个模型一起协作, 或者是选择那个ReAct模式好, 亦或是选择Plan-and-模式好, 这一切都得取决于你所面对的任务有多复杂。

如果遇到那种比较简单的问答任务的时候，用单个模型就已经够用了, 可是如果要处理那些需要多步才能操作的复杂情况的话, 可能非得拆解成两到三个不同的角色不可。

采取第三步, 也就是进行连接工具的操作。这一阶段所需要处理的工程量是最大的。在填写工具的描述内容时, 务必要写得如同面向一位没有任何相关背景知识的初学者一样清晰详尽。造成这种要求的原因是大型语言模型确实缺乏那种去“猜测”你真实意图的能力。

我曾亲眼目睹过有人仅仅是将工具的描述写成了执行查询这么寥寥几个字, 其结果就是导致大型语言模型完全不清楚具体应当对哪一个对象执行查询、也不清楚应当在哪一个位置上执行查询。这种情况直到反复尝试了五轮之后才算凭借着运气终于蒙对了正确的情境。

到了第四步的时候, 需要去写那个提示词, 还要去做流程控制方面的处理。这里的调试时间, 通常要占到整个开发周期的百分之六十以上。这里的话, 千万不要去低估它的重要程度。

第五步, 评估和迭代。别只看一个case跑通了就上线。至少要准备30到50个测试用例, 这些测试用例需要覆盖正常路径和边界情况。

AI智能体开发中最容易踩的坑

坑一: 上下文溢出。一个任务要跑够五轮, 且每一轮都会带着工具返回结果, 这会导致 token 直接爆炸。解法是把历史对话进行压缩, 或者是将中间结果存储到外部存储里面, 这样在每一轮的时候只需要获取所需的片段即可。

在坑二的情况里, 工具调用会出现死循环的问题。语言模型会反复去调用同一个工具。调用的参数几乎没有任何变化。必须加上一种硬性的限制规则。比如规定同一工具如果连续被调用超过3次。一旦超过这个次数就强制终止操作。如果不这么做的话。光是那些token的费用消耗。就会让你感到非常肉疼。

第三个坑叫做评估标准太模糊。什么叫“回答得好不好”这个概念, 在现实中是完全没办法被量化测量的。你应该在事情开始之前, 就把相关的细节全都确定下来, 比如事实方面的准确率要控制在什么程度, 步骤完成的比例要达到多少, 还有响应时间不能超过多少个秒作为界限。

我曾经亲眼目睹过某一个开发团队, 他们当时写在文档里的评估标准是“回答内容必须准确并且同时要有帮助意义”, 这种表述导致整个项目开发持续了两个月之后, 大家最后在复盘的时候才发现, 这套标准其实是完全无法用来判断最终成果是否合格的, 具体的人手工去抽查了二十个样本结果, 然后找来了三位不同的测试人员, 这几个人给出的检查结论竟然有三种完全不同的版本, 彼此之间完全没法统一。

还有一点, 很多人是不主动去提的, 那东西就是成本。一个多轮智能体的任务, 单次可能消耗的token数量是在4000到6000这个范围内。按照主流模型目前定出来的价格, 要是调用1000次的话, 花费就是几百块钱的样子。

一旦量级上去了, 那个数字是不怎么好看的。因为在开发阶段就得把token预算的事情算在里面。不要在等上线之后, 才突然发现那个账单是特别吓人的。

写到最后一个部分的时候发现, 关于人工智能智能体的开发这种事务, 纯粹的技术性上的难度实际上并没有很多大众所想象的那样高, 真正具有困难性的环节是在于工程层面的细节之处, 是那些看起来并不起眼但是只要一旦遗漏就会导致整体系统完全崩坏的方面, 把基础的地基打得非常稳固, 这一做法比去追求更新款的模型要显得更为有用和有价值。