orange.ai
1个月前
今天很有趣,两家知名的公司各出了一篇文章,争论要不要使用多智能体系统。 Claude 的官方 Anthropic :如何构建多智能体系统 Devin 的官方 Cognition :不要构建多智能体系统 这核心的争议点在于:Context 上下文到底应该共享还是分开? Claude 这边的观点是,搜索信息的本质是压缩,单个智能体的上下文有限,面对无限的信息,压缩比太大就会失真。 这就好比一个老板能力再强,也不可能搞定所有的事情,还是需要雇人去解决。 通过多智能体系统,老板让不同的智能体分别研究、汇报重点,老板最后整合到一起。由于每个智能体有自己的专长,具有多样性,减少了单一路径依赖现象,实际效果上,多智能体也超过但智能体 90%。 这是集体智慧,一起协作获得的胜利。 Devin 这边的观点是,多个智能体的上下文不一致,会导致信息割裂、误解、他们汇报给老板的信息经常充满了矛盾。 而且很多时候,智能体的每一步行动都是依赖前一个步骤产生的结果,而多智能体通常分别跟老板沟通,互相之间缺乏沟通,这样很容易导致互相矛盾的结果。 这体现出了个体智慧的完整性和高效性。 两边观点看下来,是否使用多智能体架构,特别像是人类运行一家公司的选择。 一人公司还是多人公司? 一人公司,一个人的脑力、体力、时间都是非常有限的。 优点是一人公司的沟通成本为0 ,可以把所有的时间都高效使用。 而多人公司,人越多,沟通成本就越高,管理难度就越大,总体效率下降。 但因为人数多,脑力多,体力多,整体的价值产出也就有可能更多。 多智能体的设计很有难度,这其实很正常,就像运行一家公司一样,很难。 难就难在建立有效协作的系统。 而且 1个人,3个人,10个人,100人,1000人,所需要的协作系统又不大相同。 参考人类历史,依靠集体智慧,人类在近代获得了文明的指数级发展。 多智能体的集体智慧,也许就是在 Scaling Law 逐渐放缓后,AI 获得指数级发展的那个萌芽。 而关于上下文,人类的协作至今也无法做到完美的上下文管理。 这让我想到,软件工程从来不是追求完美,而是持续迭代。
BadUncle
1个月前
Claude Code进化时刻:自举时代已经到来; 从先学再做的怪圈进化到先做再学 今天想和大家分享一个关于Claude Code心智上的转变——我称之为“自举”。 一句话总结:一切以Claude Code为中枢,我只需动嘴,Claude Code动手。所谓“自举”,就是Claude Code可以自我管理、自我驱动。 这个并不夸张, 就连claude code自己其80%的代码也是通过Claude Code自身生成的 举个应用的例子:最近我需要在Claude Code里集成一个叫zen mcp的插件,它能让Claude Code访问其他大模型,比如我最想用的gemini 2.5 pro(支持o3 api的也能用)。 按照传统流程,通常要查官方文档、配置docker、设置一堆参数。虽然对我来说不难,但对新手门槛还是挺高。 但现在只需以下步骤: ⁠git clone xx git⁠ ⁠cd zen-mcp-server⁠ 输入 ⁠claude⁠ 进入CC 然后输入如下prompt:“请帮我将zen mcp集成到claude code,我的docker用的是OrbStack,gemini用openai兼容格式,key是xx,baseurl是xxx,默认模型是xxx。” 接下来,Claude Code会自动帮你设置.env参数、启动docker、检查和测试,整个流程高度自动化。 zen mcp的激活也很简单,只需输入zen关键词,比如:“请让zen分析下该bug的原因” Claude Code会自动把必要上下文传给zen,gemini开始执行。如果gemini发现上下文不全,会自动向Claude Code提问,Claude Code再补充内容给gemini。 这样,一个以Claude Code为中心、无需切换到gemini或o3的工作流就搭建好了。 以前遇到Claude Code解决不了的问题,我会去用gemini web或cline,但这样做数据无法实时共享,也没有通信。现在,mcp就是最优的通信机制。 配图是我使用zen mcp的截图,强烈推荐Claude Code用户体验!也欢迎加入Claude Code全家桶社区,每天都有新玩法,vx: timesfriends
orange.ai
1个月前
做 Agent 研究的不要错过今天 Anthropic 发布的关于多智能体系统的文章。 ## 什么是多智能体系统? 多智能体系统是指由多个AI代理(如LLM)协同工作、并行使用工具来完成复杂任务的系统。 与单智能体相比,多智能体系统能同时探索多个方向,分工明确,提升效率和覆盖面,尤其适合开放性、动态变化的问题。 ## 为什么要用多智能体系统? 在过去的十万年里,人类个体的智能水平不断提升。 而在信息时代,随着人类集体智慧和协调能力的提升,人类社会的能力也呈指数增长。 Agent 也是类似的,即便是通用的智能体,在单独运作时也会遇到瓶颈,而 Agent 群体可以完成更多的任务。 在内部研究评估中,Claude Opus 4 为主导 Agent,Claude Sonnet 4 为子 Agent 的系统,比 Claude Opus 4 的单 Agent 性能高出 90.2% 。 举例来说,当被要求识别信息技术标准普尔 500 指数公司的所有董事会成员时,多 Agent 系统通过将其分解为子 Agent 的任务找到了正确答案,而单 Agent 系统则无法通过缓慢的顺序搜索找到答案。 ## 为什么多智能体系统是有效的? 搜索的本质就是压缩。从庞大的语料库中提炼 Insights。 但是语料过于庞大,压缩就会失真。 通过多智能体系统就能有效解决这一问题。 子 Agent 在自己的上下文窗口中进行压缩,自主地为主 Agent 提供多个方面的浓缩信息。 子 Agent 各有分工,使用不同的工具、提示词、探索路径,这样减少了路径依赖,实现多个独立方向的同时调查。 多 Agent 系统的有效是因为他们使用了足够多的 token 来解决问题。 在 BrowseComp 评估 (测试浏览智能体查找难以找到的信息能力),80%的性能差异都可以用 token 使用的多少来解释。15% 的差异可以用工具调用次数和模型选择来解释。 所以,多 Agent 是一种非常有效的架构。把工作分配给具有单独上下文窗口的智能体,以增加并行推理能力。 ## 多智能体系统的缺点 缺点嘛,就是贵。 智能体使用的 Token 一般是聊天的 4 倍。 而多智能体系统使用的 Token 一般那是聊天的 15 倍。 只有任务的价值足够高,才能对得起这么高的成本。 此外,一些任务并不适合多智能体系统,比如要求所有智能体共享上下文,或多智能体之间具有依赖关系的任务。 例如,大多数的编码任务,可并行化任务比较少。 ## 多智能体系统和 RAG 的区别是什么? 传统的方法使用 RAG,静态检索。获取与输入查询最相似的一组数据块,并用这些数据块进行回应。 而多智能体架构使用多步骤搜索,动态查找相关信息,结合新发现的信息,分析结果,并形成高质量的答案。 流程图展示了我们多智能体研究系统的完整工作流程。当用户提交查询时,系统会创建一个 LeadResearcher 智能体,并进入迭代研究流程。 LeadResearcher 首先仔细考虑方法并将其计划保存到内存中以保留上下文,因为如果上下文窗口超过 200,000 个标记,它将被截断,并且保留计划非常重要。 然后,它会创建专门的子代理(此处显示两个,但数量可任意),并执行特定的研究任务。每个子代理独立执行网络搜索,运用交叉思维评估工具结果,并将结果返回给首席研究员。首席研究员会综合这些结果,并决定是否需要进一步研究——如果需要,它可以创建更多子代理或改进其策略。 一旦收集到足够的信息,系统就会退出研究循环并将所有发现传递给 CitationAgent,后者处理文档和研究报告以确定引用的具体位置。 这确保所有声明都正确归属于其来源。最终的研究结果(包括引文)将返回给用户。