原野: 今天啊,咱们要好好掰扯掰扯一篇特别有意思的文章,标题直接就叫‘Cognition | Don’t Build Multi-Agents’。
原野: 文章里头啊,直接就点明了为啥多智能体架构老是让人失望,还抛出了个核心理念——上下文工程,说这才是构建可靠代理的关键。你说,这年头咱们搞个AI代理,咋就感觉跟回到了互联网拓荒时代似的,还在那儿用最原始的HTML和CSS瞎折腾呢?
晓曼: 可不是嘛!就像React当年给Web开发带来了全新一套哲学,AI代理现在也急需自己的‘武功秘籍’。咱们以前老是挂在嘴边的‘提示工程’,现在看来,得升级到‘上下文工程’了!这玩意儿,说白了就是在动态系统里,能自动把所有相关的背景、前因后果、历史决策一股脑儿地喂给AI。你想想,一个顶尖的工程师,如果连项目全貌都不知道,那他能高效干活儿吗?根本不可能嘛!
原野: 那话说回来了,这个‘上下文工程’,跟咱们平时理解的‘提示工程’,到底有啥本质上的不同啊?能不能给咱们来个大白话的类比,一下子就懂的那种?
晓曼: 这么说吧,如果‘提示工程’是咱们给AI一份‘操作说明书’,那‘上下文工程’可就牛了,它是在AI执行每一步的时候,都能自动、实时地给它展现一幅‘全局图’。让AI不光知道‘怎么做’,更明白‘为什么要这么做’以及‘我这一步棋在整个大局里是个啥角色’。这就好比咱们盖房子,你不能光给工人一张施工图纸就完事儿,还得让他们随时能看到整栋楼的进度、设计理念,甚至这房子将来是给谁住的,这样工人才能干得心里有数,对吧?
原野: 哇,听你这么一说,这概念简直太棒了!可为啥一到实际操作,尤其是在多代理系统里,这玩意儿就变得跟纸糊的一样,异常脆弱呢?
晓曼: 咱们再回过头来说说文章开头那个Flappy Bird的例子,简直是教科书级别的反面教材!你想啊,当一个大任务被拆分成两半,分别扔给两个子代理去做的时候,就算你把最原始的任务描述都发给他们了,他们还是能给你搞出幺蛾子。一个可能一拍脑袋,说‘我要做个马里奥风格的背景!’另一个呢,画出来的鸟可能跟游戏根本搭不上边。结果呢,主代理就得硬着头皮去面对这些风马牛不相及的‘作品’。这不就是多代理并行时,上下文彻底‘断片儿’的典型表现嘛!简直是鸡同鸭讲!
原野: 哎呦,你这么一说我可太明白了!这就像是子代理一开始可能知道自己要干啥,但随着多轮对话和各种工具的调用,它就跟‘失忆’了一样,彻底忘了大局是啥。那你说,这个‘共享上下文’,到底要共享到什么程度,才能真正避免这种‘跑偏’的问题啊?
晓曼: 所以啊,文章里给出的第一条金科玉律就是:必须共享上下文!而且,这个共享可不是随便扔几条消息就完事儿,它得是完整的‘代理追踪记录’,从头到尾。这就像咱们团队协作,每个人都得能随时翻阅所有的讨论记录、设计决策、甚至具体到实施的每一个小细节,这样才能确保大家的工作是真正对齐的,而不是各干各的,最后拼凑起来一塌糊涂。
原野: 嗯,我懂了,上下文的完整性和连续性,这简直就是咱们的第一道‘防火墙’啊!那你说,你刚才还提到了一个‘更深层次的问题’,那又是个啥呢?听起来还挺神秘的。
晓曼: 这个‘更深层次的问题’啊,就是那些‘隐性决策的冲突’。你想想,每个代理在干活儿的时候,都会在不知不觉中做出一些没有明确写出来的决定。比如说,一个子代理可能就喜欢卡通风格,非要往那儿靠;另一个呢,偏偏就钟情于像素艺术。它们表面上看起来好像是基于相同的上下文在工作,但就是因为这些‘没说清楚’的隐性决策没有协调好,最后出来的结果,那可不就糟糕透顶了嘛!就像两个设计师,一个要做复古风,一个要做未来感,最后拼在一起能好看吗?
原野: 听你这么一说,这问题可就不是简单的信息不透明了,更要命的是决策上的‘各行其是’啊!那既然多代理系统有这么多‘先天不足’,咱们到底该怎么搞,才能构建出真正可靠的AI代理呢?有没有一种更‘皮实’、更稳健的架构啊?
晓曼: 文章里给出的答案,简单粗暴但有效,那就是:单线程线性代理!这玩意儿,就像一个特别一丝不苟的‘老工程师’,一步一个脚印地把任务给完成了。所有的决策都在一条连贯的思路下进行,这样就彻底避免了因为并行操作引发的上下文丢失,以及那些让人头疼的隐性决策冲突。简直是‘一专多能’的典范!
原野: 哎呦,听起来是挺理想的!可问题来了,如果任务量特别庞大,那上下文窗口会不会变成一个巨大的瓶颈啊?毕竟AI的‘脑容量’也是有限的,它会不会干着干着就把前面那些内容给‘忘了’呢?
晓曼: 你问到点子上了,这确实是个实实在在的挑战!不过呢,文章里也给出了一个挺巧妙的解决办法:可以引入一个专门的LLM模型,专门负责把那些冗长的历史对话和行动记录给‘压缩’一下,就跟咱们请了个资深助理似的,帮你把一堆会议记录浓缩成关键的细节和决策。这样一来,主代理的‘脑子’就不会被撑爆,就能持续高效地工作更长时间了。
原野: 哇,这种上下文压缩技术听起来也太实用了吧!简直是‘记忆瘦身’大法!那在实际应用里,我们能看到哪些遵循了这些原则的AI代理案例呢?有没有什么成功的‘模范生’可以学习学习?
晓曼: 当然有!你看像Claude Code,它的子代理就特别‘听话’,从来不搞并行操作,就老老实实地负责回答那些特别清晰的问题,也不去写什么复杂的代码。这样一来,自然就避免了上下文丢失和决策冲突。再比如那个‘编辑应用模型’,早些时候啊,它还是大模型发指令给小模型去执行,结果呢,后来就演变成一个模型把所有的编辑决策和应用都包揽了,这样中间环节的‘跑偏’和误解也就大大减少了。看来,‘少即是多’,在AI这块儿也挺适用!
原野: 这么说来,现实世界里那些成功的AI案例,都是在小心翼翼地绕开多代理的‘大坑’啊!那我就好奇了,你觉得未来AI代理的终极形态,会不会还是回到多代理协作这条路上呢?毕竟咱们人类团队都能高效沟通,AI也能做到吗?还是说,它们就是天生‘不合群’?
晓曼: 哎,长远来看,我个人对多代理协作还是抱有乐观态度的,毕竟人类团队都能配合得这么好,AI没理由不行。但现在最大的症结在于,咱们得让AI在跟人类和其他代理沟通的时候,变得更主动、更有‘眼力劲儿’。目前呢,跨代理的上下文传递问题还是个老大难,这个‘肠梗阻’还没彻底打通。我觉得啊,等咱们的单线程代理在人机沟通这方面,变得更成熟、更‘懂事儿’的时候,这个瓶颈或许就能被彻底突破,到时候才能真正解锁大规模的并行和效率,实现AI的‘大协同’!
原野: 嗯,所以说啊,多智能体这事儿,现在看来是有点让人‘心碎’,想构建可靠的AI,核心秘诀还得是:上下文!上下文!以及上下文!