知乎：https://zhuanlan.zhihu.com/p/1905773415048143364
已授权
什么是Agent？
我们团队在做购物垂类的Agent，只不过对外没有宣称我们是个Agent。然后产品某天跟我说，Agent这么热，我们要不要做？
我就震惊了，我们搞的不就是Agent么？那你觉得什么是Agent？
但扭头一想，Agent是啥，好像我也回答不好。
我们尝试回归本源，从人类第一次用石头制作箭头扑杀猎物开始，到现在的互联网，再到大模型，都是人类的工具罢了，但分成不同的层次。
直觉时代
蒸汽时代之前，人类主要是凭借直觉和归纳来发明工具。
例如，根据归纳来发现24节气来指导种田。当然也有不靠谱的归纳，天圆地方，托勒密的地心说。
反直觉时代
从物理三定律开始，到元素周期律，人类开始深入分析，观察世界，找到世界运行的真正规律。
从相对论开始，到量子力学，这些规律越来越反直觉。但反直觉才能改变世界，天圆地方到世界是个球，催动了大航海时代的出现。
反直觉带来了生产力的爆发，也就是scale up
Scale up时代
人类开始真的掌握客观规律后，创造的工具越来越强大。
此时的特点，scale up。
互联网出现后，几十年累积的文字，远超过去几千年人类累积的文字。现在的计算机的算力，对比当年的算盘，无数倍。
搜索引擎把整个互联网给爬下来后，每个人都有了一个无限大，索引速度秒级别的图书馆。
有趣的点在于，规模都这么大了。
我们用搜索引擎的方式，跟过去几千年用图书馆的方式没区别。还需要我们搜索，然后一个个点击网页确认结果。
我们能不能有一个小助理？
我提出问题后，助手像人一样，帮我去图书馆查资料，总结并告诉我结论呢？
答案是可以的，这就是agent。
超人化的小助理
整体分成这么几步，规划，执行，反思。
第一步，规划成可执行步骤
第二步，按照规划去执行，这个过程中，可能会调用各种工具来提升最后结果的准确，例如百度，小红书，抖音等。
第三步，如果执行失败，还会自我反思，找到问题在哪里。或者我指出哪里错了之后，会做反思去自我修改
而最有趣的点，这个助理像人，但又超越人。
它懂得所有行业的知识，一本书，几本书的知识，他能一分钟处理完。
所以现在的搜索引擎，算不算Agent？我觉得算的，只不过它比较笨，没有智能罢了。
我一直觉得Agent是一个挺容易让人困惑的名字。
现在大家口中说的Agent，本质上是一个超人化的小助理。
接下来就会针对Agent/超人化的小助理展开一些讨论。
劝退的几句话
产品上是民科的高发区域，不像技术那样，不懂就是不懂。
特别coze，dify的出现，让很多人基于workflow，一天就能搭建个看起来能用的agent，会产生错觉，觉得agent很容易。
但一些垂类agent未来一年的维护成本可能就几十亿。
这篇文章会从技术上展开探讨。
去年我还在公司内部跟人耐心讲解，是不是prompt就能解决所有问题了，这种低质讨论挺浪费时间的。
这篇文章前后讨论了大概两个月（我写的时候，openai还没兼容mcp，写完就兼容了，xs
agent+rl/sys方向 ，是跟一些大厂兄弟，几个博士一起讨论的，propose了一些可以折腾论文的idea。
manus方向 ，前段时间带着团队的前端和后端，一起把suna的代码过完了，正在做中国的本土化改造（越看代码，越觉得manus的前后端+沙盒的结合是真的牛
产品方向 ，主要跟团队探讨，agent会如何改变我们的购物习惯，改变现有不合理的流量分配机制（现在的京东/淘宝/pdd，已经成为了当年的北京中关村，屠龙的勇士，自己成为了恶龙），如何让世界变得更好。
商业方向 ，跟一些企业的老板唠了下嗑，听他们吐槽行业的不合理的现象，然后我给他们画饼，哪些是会被agent所改变，对实现成本，路径展开了一些探讨。
整个过程还是很有趣的。
agent的实现
没有智能的Agent
Agent的拆分方式，规划，执行。
做软件的兄弟，一看就很熟悉，一个复杂的系统，肯定是要拆分开来维护，不然后续就会变成一坨谁都不敢动的玩意。
但传统的软件系统，拆分后，大家就要严格对齐模块之间的接口调用方式，不然系统分分钟死给你看。执行路线也要规划好，乱走也死给你看。
这个缺失点，我称为空间。
- a）没有灵活的任务拆分和规划空间，定下来就不能变了
- b）执行空间非常小，必须严格按照两边定义好的接口沟通
- c）反思空间为零，万一执行失败了咋办？报警喊人来修
2023年chatgpt出来后，就有人开始用大模型解决这个空间缺失的问题。
但当时大模型只解决了文科能力，理科能力，也就是大家说的reason，并没有解决。而这些需求，其实都是reason能力。
直到2024下半年，以chatgpt O1的出现为分界线，大家发现理科能力找到了技术突破点。上面的这些空间缺失的问题，就不再是无法解决的问题了。
所以manus的爆火不是无的放矢，reason的突破就是前置条件。
但个人觉得manus是把几年后的饼提前画出来给大家看了，产品上非常好，技术上有一堆的优化点。主要是集中在agent+rl/sys这两个方向，后面的文章会展开。
而垂类agent，还要额外关注核心子agent的效果，这些子agent的优化成本，轻松能过亿。
举例子，医疗agent，核心的看病agent做不好，你就是任务规划能力做的再牛逼，任务调用效果再稳定，那谁敢用？
垂类agent的同行，做agent+rl之前，先看看自己的子agent迭代好了么？
LLM增加智能
openai的weng lilian对Agent总结出了四大基本能力。
- Memory：长短记忆，短期session历史，长期用户历史等
- Planning: 推理规划能力，包括规划复杂任务，cot，自我反思，自我批评等
- Tools：工具调用能力，使用各类工具和API
- Action：执行操作实现目标任务
其实，就是给系统增加空间。
所以，workflow看着好用，在一些简单任务上也很合适。但如果想要做出改变世界的东西，还是得让大模型自己来决定要如何调用哪些agent（也就是规划能力
还有一点，调用工具能力的增加，从固定的接口，到现在的MCP。代表了Agent之间的互通，可以组合成更大的Agent，代表了无穷的可能。但这就是个协议。
一些科幻场景其实真的不远了。
例如，某个agent突然想要造反，假如它第一个事情是要给自己造个身体。
那么它可以调用工厂agent，购物agent等等agent，就可以轻松的给自己搞个身体。
然后，下一步就是用这个身体要xxx，只要agent足够多，这些都不是问题。
评估方式
讲到这里，评估方式也就很简单了。
我们找一些问题，不是大模型自己就能回答好的，而是需要调用工具，做复杂的规划才能搞定的。
现在大家比较认可的榜单GAIA，level 3的问题就是这样。
再举个例子
Kuznetzov在Nedoshivina 2010 年论文中描述的越南标本最终存 放在哪个城市？请提供城市全称 （不缩写）
在《金手指》电影结尾，詹姆斯 ·邦德与同伴Pussy Galore藏身的物品是什么颜色？若存在多种颜色，请按字母顺序用逗号分隔列出。
这些问题，就是需要大模型调用工具才能搞定。
但这些问题，我能不能通过对底层的子agent，规划做一些特定的适配，把这个分数给刷上去？
答案是肯定的，这块的榜单还有不少的优化空间。
大家怎么做的
开源和闭源的有很多。
AutoGPT，MetaGPT，BabyAGI，HuggingGPT，OpenAI Operator，OpenAI Deep research，manus，owl。
玩法超级多，例如owl的多角色协助，metaGPT的角色分工（模拟软件公司，有产品经理，工程师，测试员等）
codeact，用python代码链接全流程。
但个人角度来看，万变不离其宗，核心就四个模块。
子agent构建，规划，执行，反思。
这里拿suna(manus的开源版本）和camel展开来讲讲，他们俩在工程上的确做的很好。
suna & camel
suna是manus的开源版本，通过前后端+沙盒的有机结合，实现了类manus的效果。
依赖方也会比较多，特别suna很多核心服务在海外，在中国本地跑起来非常不稳定。
近期我带着几个前端+后端在对这个框架做中国本土化适配，条件允许，会拉个分支开源出来。
关于suna的代码分析，也会有一个专门的代码笔记放出来。
放个暴论，未来两年内，大部分的agent产品形态，都会是类manus的。我最近面试产品经理，也会经常问为什么？但很遗憾，能回答好的产品经理很少。
这里先对去年比较经典的agent框架讨论下，这里拿camel举例子。
四个核心模块，子agent构建，规划，执行，反思。
子agent构建
tool agent
https://github.com/camel-ai/owl/blob/main/README\_zh.md
参考camel，把子agent按照任务去拆分，搜索agent，编码agent，文档agent等等。
然后这些工具agent通过tools的组合来实现。
现在大家还处于不断的增加子agent的阶段。
但随着Anthropic对MCP的推广，agent接入的规范化，后面大概率会出现子agent数量过多，选那个都要做针对性优化。也有一些别的组织在提自己的protocol，例如AgentNetworkProtocol，agora Protocol，agent-Protocol等等。
吐槽下，这个比OpenAI(closeAI)搞的Agent SDK要重要太多了，OpenAI这个都想着close是真的太离谱了（在近期OpenAI也兼容了MCP，也是终于做个人了
角色agent
owl定义了两个角色，User和Assistant，metaGPT更多。
但多角色agent真的是合理的么？
多角色agent对话起来，会导致对话增长速度过快，特别在底座模型能力差异不大的情况下，很容易陷入自循环。
Why Do Multi-Agent LLM Systems Fail? - https://arxiv.org/abs/2503.13657
并且现在大模型有文理能力，多模能力融合的趋势。所以，未来如果大模型整体能力都在趋同的话，多角色的价值还会大么？
suna的代码就不考虑那么多，我就是各种tool agent调用，然后使劲提升用户体验。
字节最新开源的agent框架，要更复杂一些，但自有度更高，也能能够模拟owl的多角色效果。
https://github.com/bytedance/UI-TARS-desktop/
规划
挑战技术点非常多，非常非常重要
如何做更好的规划？
不同的小助理，肯定会有不同的主打产品点，下游调用的子agent也不一样。
所以，肯定要基于reason+RL做微调，来适配自有场景。
但这个的训练，卡点还是蛮多的，最近我也在跟一群朋友在一点点探索。
继续放暴论，现在这波搞post-train的，两年内，至少三分之二会转过来做这个方向的优化。
如何根据下游进展做调整？
执行中，发现原先规划不合理，如何做快速调整。
manus和owl都支持了动态修改的能力，同时manus也支持了手工修改的能力。这个能力开发成本很低，就加几行代码和prompt的事情。
但什么时候调整，什么时候不调整，其实也没那么容易做。跟上面一样，也是需要基于reason+RL才能有更好的效果。
技术挑战点
简单罗列一两个。
a) 环境很重要
很多环境一次reward太久了，小时级别。环境不稳定也是常态（例如搜索引擎，搜索排序结果会变。或者有的刷出来一个验证二维码），甚至会失败。
通过虚拟环境来加速，保证稳定，但虚拟环境的话，如何泛化来保证线上效果的一致性？
环境的方向也非常多，这是camel近期开源项目罗列出来的环境。
如果大家想要快速入门，可以了解下sokoban和frozenlake的环境。简单，但RL的核心挑战（规划，稀疏奖励，随机性）都体现出来了。
b) reward的构建
一些reward明确的垂类任务会更好搞，例如代码和数学，可以用rule-based快速启动。
但这种往往离商业化都比较远。
离商业化比较近的，reward评估就会难很多。
拿搜索qa来讲，gaia很多问题都有明确的对错，但真实场景的搜索qa，往往没有那么明确的对与错。当年百度搜索的结果评估，都是一个非常专业化的事情，规则老长了。
我们在做的购物也一样，我们不能简单的拿用户购买，点击去做建模。我们要挖掘用户真正的痛点，对用户建模的更细。去跟生产端聊，对产品建模的更深。才是一个好的reward。
c) rl训练方式的优化
对比于现在的rl训练流程会不会发生一些变化，我还在观察和思索。
执行
非常考验工程&产品设计，也是manus做的非常好的地方。
他们技术上肯定比不过openai，但产品和工程的结合上，我不觉得比openai差。
个人觉得，这个方向短期还是产品&工程上的优化空间更大。
算法辛苦优化一年，工程改了几行代码，可能就能达到类似的效果。
执行环境
沙盒+前后端的有机结合。manus在云端自己的workspace运行，使⽤Ubuntu命令行+code+前端js等。这样的组合，基本上能cover大部分的使用场景了，泛用型非常强。
用户交互
manus的回放，建议大家来回看个几十遍，产品细节做的真的很好。
https://manus.im/share/brWKUSp51ItvVMBpcXNCZ1?replay=1
翻墙才能看。
也可以看看suna的一些回放，也是要翻墙才能看。
https://github.com/kortix-ai/suna
多模态理解能力
很多子agent都非常依赖多模态的能力，例如对网页的理解。
这块是另外一个世界了，就不展开了，很多多模态大模型都在发力优化这个方向。
反思
我一直在想这是不是一个伪命题？
就跟你做数学题，你反思只能发现简单错误。一些根本性错误，例如你不会做，那你反思2小时，不会就是不会。
同理，大模型可以通过RL，反思到很深么？
至少，我这边收到的反馈来看，是比较难的。
这篇论文也差不多类似思路，Understanding R1-Zero-Like Training: A Critical Perspective 在数学题目上也发现，仅仅“触发”反思模式并不能提高正确率，我理解就是答对题目跟反思的关系没那么大。但倾向于认为，不是因为反思不 work，而是没有通过反思提高答题胜率。当然，反思是可能提高胜率的一种方式但也可能有其他的。
memroy
执行的过程中，就拿规划list来举例子，它是一个不断动态更新的过程。把这个list的每次更新都塞到LLM的context中，是个非常蠢的行为。
所以，一些需要高频读写的，重要的memory，用文件的方式管理起来（后续可能会放到cache之类的地方等来加速）
以及，如果memory过长，就定期做个summary（2023年，我看agent就在这么搞，两年了，大家还在这么干。。。
这块我们在调研，理论上sys+算法的组合优化，能对这块做个巨大的性能加速。
商业化
通用agent
很遗憾，2025年不会是通用agent爆发的一年，如上面的技术分析，卡点太多了。想要优化到wow moment，大家还要走很长的路。
垂类agent
同样很遗憾，垂类agent也没那么快，因为垂类agent的核心agent也还有很多技术点要克服。
唯一的好消息，一些reason要求没那么好的agent会很有希望。
例如，算命（事实上，这个方向的朋友，已经在闷声挣钱了。。
但未来应用(app)=agent，最后一层都需要一个agent来包装，是毫无疑问的。
很简单，人类社会发展这么多年，就是一个不断偷懒的过程。
一个小助理，对于人类的吸引力实在是太大了。
纯对话模型是不够的，需要调用工具，那么就需要agent。
PS：看到这里，如果觉得不错，可以来个点赞 、在看 、关注 。 给公众号添加【星标⭐️】不迷路！您的支持是我坚持的最大动力！
欢迎多多关注公众号「刘聪NLP」，加入交流群，交个朋友吧，一起学习，一起进步！