Agent在2024上半年还是一个特别火的话题，下半年似乎大家都对其祛魅了。

什么Agent，不过是LLM套壳而已。

相比于Reasoning能力的突飞猛进，绝大多数Agent的论文还停留在讲故事的层次。把Memory、Planner、Runner、Reflection、Verifier什么的搭个积木出来，在某个场景里调prompt调work了，就是一篇论文。多的就再采点数据调一调。

当然，我也是这么干的。

本文就从技术角度分享，我觉得做Agent难在哪儿。

Agent不是玩具

大家真正想要的Agent绝对不是玩具，Agent本身就是冲着落地、提高生产力去的。

个人认为，Agent 30%、60%、80%的成功率，本质上都是0，因为没有人会去用。Agent完成一个任务往往需要十次以上的LLM inference，其中一个步骤的错误，往往导致整个任务直接失败。假设每个步骤的成功率都是0.95，十次都成功的概率就只有0.6。等Agent完成之后再去检查、纠正，有这个功夫还不如我自己手动做了。

所以，o1类模型的反思能力还是给了解决这个问题很大希望的，慢一点可以，但尽量不要fail了。有些场景下，也不能太慢了。

Agent需要与Environment交互

在做WebAgent的时候，我花了大力气处理LLM与Browser之间的交互问题，其中存在的bug数不胜数，比如HTML加载失败、网络卡了、莫名其妙没有反应、弹窗、反爬虫……甚至有时候采了很多数据才发现，里面存在着共同的问题，又要想办法解决、重新采。

而当需要并发采集数据时，又需要处理多进程/多线程的资源冲突问题。一般的LLM任务中，唯一的速度瓶颈是GPU，而在Agent任务中，CPU、内存甚至网络速度，都可能成为瓶颈，而且处理资源冲突问题也更复杂。在Mac下，同时执行20个Browser page任务已经是上限；在Windows下，同时开8个星际争霸2的游戏进程已经是上限；在Code Interpreter任务中，一个机器学习任务就可以轻易吃满所有CPU，参数搜索几个小时都很正常。

但是算法工程师很难把这些工作都推给别人做，只能什么杂活都干。

Agent微调的复杂度高

为了提升Agent成功率，当然可以采集数据对其中的模型进行微调，这又带来几个问题。

首先是Agent中可能包含了不同功能的模型，原本只需要一个加载一个LLM，配置不同的prompt就足够了，现在就需要同时加载若干模型。当然，这个问题有一些妥协方案，例如使用LoRA微调以动态更改模型、使用同一份混合数据微调，但是都不是使得Agent效果最佳的方案。如果GPU足够多，也只是影响总体利用率而已；GPU只有8块，就头疼了。

其次是如果仅使用垂域数据微调，会带来通用能力的弱化，影响对ood问题的泛化能力，比如Code能力提升了，但是对复杂Query的理解能力下降了。因此在微调时，需要混合通用数据，数量配比跟任务本身的难度和特点有关，需要实验。

最后就是采集数据本身就很困难。很多场景都需要半自动地构造任务，对于任务的成功与否难以判别，更不用说判定其中某一个步骤是否成功了。采集数据本身的丰富程度也要想办法估计，然后进行采样和增强。

写在最后

说实话，做了这么多工作，我有点丧气。如果LLM本身足够强，很多工作其实都没必要，理想情况就是OpenAI的ReFT，给几个Example，就自动泛化很多场景。也许现在真的还不是做Agent的时机？也许真的就等LLM足够强大，prompt指哪儿打哪儿，开个API给开发工程师就可以了？

但总归我是很快就要弃坑了。