#多智能体系统

Google 11月最新白皮书「Introduction to Agents」—— 作为「Google x Kaggle 5天 AI 智能体强化课程」的开篇,提供从概念验证到生产级智能体系统的指导框架。 Google 这份最新白皮书,聚焦于 AI 智能体的核心架构、分类、构建实践、生产部署、安全治理以及演化学习,客观分析了生成式 AI 从被动预测向自主问题解决的转变,强调智能体是语言模型在软件中的自然延伸,能够通过循环推理、行动和观察来实现目标。 白皮书的核心观点是:构建智能体并非简单集成语言模型,而是设计一个完整的应用系统,需要平衡灵活性和可靠性。 1. 从预测 AI 到自治智能体 AI 正从被动任务(如翻译或生成图像)转向自主智能体,这些系统能独立规划和执行多步任务,而非依赖人类每步指导。智能体结合语言模型的推理能力与实际行动工具,使其成为“语言模型的自然演化,在软件中变得实用”。白皮书强调,从原型到生产级的挑战在于确保安全性、质量和可靠性。 2. 智能体介绍 智能体定义为模型、工具、编排层和运行服务的组合,通过语言模型循环来实现目标。核心组件包括: · 模型(大脑):核心推理引擎,如通用模型、微调模型或多模态模型,负责处理信息、评估选项和决策。 · 工具(双手):连接外部世界的机制,包括 API、代码函数和数据存储,用于获取实时信息或执行行动。 · 编排层(神经系统):管理操作循环,处理规划、记忆和推理策略(如链式思考或 ReAct)。 · 部署(身体和腿):从本地原型到安全、可扩展服务器的托管,确保通过 UI 或 API 访问。 开发智能体类似于导演角色:设置指导提示、选择工具并提供上下文。白皮书指出,语言模型的灵活性是双刃剑,需要“上下文工程”来引导可靠输出。智能体本质上是上下文窗口的策展者,能适应新情境解决问题。 3. 智能体问题解决过程 智能体通过连续循环实现目标,分为五个步骤: 1. 获取任务:从用户或触发器接收高水平目标。 2. 扫描场景:感知环境,收集上下文(如用户请求、记忆、工具)。 3. 思考:模型分析任务并制定计划。 4. 行动:执行计划的第一步,如调用工具。 5. 观察与迭代:评估结果,更新上下文并循环。 示例:客户支持智能体处理“我的订单#12345在哪里?”时,先规划多步(查找订单、查询跟踪、合成响应),然后逐一执行。这种“思考-行动-观察”循环使智能体处理复杂任务。 4. 智能体系统分类 白皮书将智能体分为五个级别,每级基于前一级扩展: · 0级:核心推理系统:孤立语言模型,仅依赖预训练知识,无法实时交互。 · 1级:连接问题解决者:添加工具,能访问外部数据(如搜索 API)。 · 2级:战略问题解决者:支持复杂规划和上下文工程,能主动管理信息。 · 3级:协作多智能体系统:如人类团队,智能体将其他智能体视为工具,实现分工。 · 4级:自演化系统:识别能力差距,动态创建新工具或智能体。 5. 核心智能体架构:模型、工具和编排 · 模型选择:优先考虑特定任务的推理和工具使用能力,而非通用基准。建议多模型路由(如大模型规划、小模型执行)以优化成本和速度。多模态模型处理图像/音频,或使用专用工具转换数据。 · 工具:分为信息检索(如 RAG、NL2SQL)和行动执行(如 API 调用、代码沙箱)。函数调用通过 OpenAPI 或 MCP 连接,确保可靠交互。包括人类交互工具(如 HITL 确认)。 · 编排层:管理循环,决定何时思考或行动。核心选择包括自治程度(确定性 vs. 动态)、实现方法(无代码 vs. 代码优先,如 ADK)和框架(开放、可观测)。 6. 核心设计选择、多智能体系统和设计模式 · 指令与上下文:使用系统提示注入领域知识和角色(如“友好支持智能体”)。增强上下文包括短期记忆(当前会话)和长期记忆(RAG 查询历史)。 · 多智能体:采用“专家团队”模式,避免单一超级智能体。常见模式:协调器(路由子任务)、顺序(流水线)、迭代精炼(生成-批评循环)和HITL(人类审批)。 · 部署和服务:从本地到云托管(如 Vertex AI Agent Engine 或 Cloud Run)。需处理会话历史、安全日志和合规。 7. Agent Ops:结构化处理不确定性 Agent Ops 是 DevOps 和 MLOps 的演化,针对智能体的随机性。关键实践: · 度量重要指标:如目标完成率、用户满意度、延迟和业务影响。 · 质量评估:使用“语言模型作为评判者”对输出打分,基于黄金数据集。 · 指标驱动开发:自动化测试变化,A/B 部署验证。 · 调试:OpenTelemetry 追踪记录执行路径。 · 人类反馈:将报告转化为新测试用例,关闭循环。 8. 智能体互操作性 · 智能体与人类:通过聊天 UI、计算机使用工具(控制界面)、动态 UI 生成或实时多模态(如 Gemini Live API)交互。 · 智能体与智能体:A2A 协议标准化发现和通信(异步任务)。 · 智能体与金钱:AP2 和 x402 协议处理交易,确保授权和微支付。 9. 安全与扩展 · 单个智能体安全:平衡效用与风险,使用混合防护(确定性护栏 + AI 守卫)。智能体身份作为新主体,使用 SPIFFE 验证。ADK 示例:回调、插件和 Model Armor 检测注入。 · 扩展到企业舰队:处理“智能体蔓延”,通过控制平面(网关 + 注册表)强制政策。关注安全(提示注入、数据泄露)和基础设施(可靠性和成本,如预置吞吐量)。 10. 智能体如何演化和学习 智能体需适应变化,避免“老化”。学习来源:运行经验(日志、HITL 反馈)和外部信号(政策更新)。优化包括上下文工程和工具创建。示例:多智能体工作流学习合规指南。Agent Gym 是前沿:离线模拟平台,使用合成数据和专家咨询优化。 11. 高级智能体示例 · Google Co-Scientist:虚拟研究伙伴,生成并评估假设。通过监督智能体管理专家团队,运行循环改进想法。 · AlphaEvolve:发现算法,结合 Gemini 生成代码和进化评估。人类指导定义问题,确保透明和实用。 12. 结论 智能体将 AI 从工具转变为伙伴,通过模型、工具和编排的集成实现自主性。开发者需从“砖瓦工”转向“导演”,强调评价和治理。这一框架指导构建可靠系统,推动智能体成为团队成员。 Google x Kaggle 5天 AI 智能体强化课程: Google 11月最新白皮书「Introduction to Agents」:
Hubble 的 AI 交易系统在实盘 48 小时内收益 +22.44%。 同期, 的多款顶尖模型取得 -21% 至 -60% 的亏损。 多数所谓的 “AI 交易模型” 都赚不到钱,其实一点也不意外。 为什么? 因为它们的训练对象就是人类行为。 AI学会的,是像人类一样交易—— 在贪婪时贪婪,在恐惧时恐惧。 它们过度拟合过去有效的模式, 而在市场切换周期时完全失灵。 最终,它们交易的方式依旧像人一样,更快——却犯着同样的错误。 Hubble是怎么做的? 我们所做的不是让一个大模型负责所有决策, 而是运行一个 多智能体系统(multi-agent system): 每个 agent 拥有不同的职责、逻辑和决策周期。 它的运作方式更像一个自动化的交易团队,而不是一条 LLM 流水线,让系统进行实时协同 👇 - PORTFOLIO_SUMMARIZER(资产摘要):实时监控盈亏、杠杆与仓位结构,根据真实市场变化提出交易方案,而非依赖情绪信号。 - TRADER(执行交易):在高置信度信号下快速执行,严格控制滑点与仓位规模。 - PORTFOLIO_MANAGER(仓位管理):跟踪整体风险敞口,动态调仓,避免集中暴露。 - RISK_MANAGER(风险控制):动态执行资金使用、清算阈值与波动率上限等约束。 这样的结构让系统具备高频反应、灵活调节与自我修正的能力。 各个 agent 并行运行,不等待中央指令。 它们在毫秒级的周期内持续读取市场信号、更新仓位、再平衡风险。 当波动来临,系统不会“卡死”,而是自动调整。 权重在变化、优先级在转移、资金流向新的机会。 这正是 Hubble 能在高频环境下保持稳定的关键: 不追逐噪音,而是围绕变化进行自适应交易。 实际收益对比: - Hubble:+22.44% - nof1 模型:-13.74%、-21.21%、-42.97%、-49.05%、-60.19% 附图展示了相同时间窗口下的账户总价值(Total Account Value)变化。 可以看到,Hubble 在趋势反转时反应灵活,在信号清晰时加仓更果断,在波动上升时能够迅速降杠杆、减风险。 启示 Hubble构建的,不是一套赚快钱的交易模型, 而是一种能在真实环境中持续学习的结构。 同样的框架,未来将延伸到数据、研究与执行层面, 成为 Hubble 正在打造的 开放智能体市场(Agent Marketplace) 的基础层。 交易只是起点。 我们的目标,是构建一个能自主推理、协作、演化的智能网络—— 一步一个层级地生长。
sitin
2周前
Susan STEM
3个月前
AI Agent 到底是什么?从 Jennings 定义谈起 “AI Agent”这一术语虽在近年大热,但其核心概念早已由 Nicholas R. Jennings 与 Michael Wooldridge 在 1995 年的《Intelligent Agents: Theory and Practice》中系统确立。他们将“智能体”定义为:一个嵌入特定环境中的计算系统,能够在该环境中自主行动以实现其设计目标。这一定义成为多智能体系统(MAS)研究的基础,并提出四项衡量智能体的关键属性:自主性(能独立运行)、反应性(感知并响应环境变化)、前瞻性(基于目标采取主动行动)与社会性(能够协作与沟通)。 然而,在当下的工程实践中,要真正实现这四大属性仍具有相当高的难度。尽管 ReAct、AutoGen、LangGraph、CrewAI 等主流框架纷纷打出“Agent”旗号,它们多数仍停留在“语言模型 + 工具调用”的阶段,缺乏结构化的状态封装、计划机制与交互协议。这些系统通常依赖自然语言记忆作为状态存储,对环境的感知局限于文本输入输出,目标与计划的建模大多被简化甚至省略,而协作机制也往往停留在对话模拟层面,缺乏真实的社会行为协议与组织控制结构。 换句话说,当代 LLM Agent 多数只能在表层满足 Jennings 框架中的“工具调用”与“表面协作”,而在真正的状态感知、计划能力、环境互动与协作协议等方面仍存在明显工程落差。它们更像是 prompt 的包装器,而非具备认知与调度能力的结构性智能体。 要真正构建接近 Jennings 理想的 AI Agent,必须引入可解释的状态模型与持久记忆结构、明确的计划调度机制、标准化的交互协议以及多轮对话中的身份与行为一致性。只有当智能体具备了这些结构能力,它才不再是一个被动执行的语言函数,而是一个真正能够协同、规划、反应并自主演化的结构系统单元。 真正的智能体到底值不值得投入研究?还是说,它会不会最终成为一个耗尽心力、却注定走入死胡同的幻象? 这个问题越来越像一面照妖镜。现实世界里,有太多曾被寄予厚望的底层技术,最终悄无声息地被市场淘汰、被工程复杂性吞噬。Jennings 所定义的理想型智能体,正面临类似的命运风险。它拥有令人敬畏的结构理想—— 🧱 结构性:每一个模块边界清晰、可组合、可迁移; 🧠 状态性:具备可追踪、可持久、可调度的运行状态; 💾 记忆性:融合语义唤醒与行为经验的双系统记忆机制; 🧭 路径性:支持非线性、多策略、可重构的执行结构; 🤖 调度性:能够统一调度工具、任务、子 Agent; 🔁 自演化:具备反思、失败容忍、成长与优化能力。 这简直就是我心中最理想的“结构人格”,我是无比憧憬的。这个甚至能完美解决上下文的问题。 看起来无比完美,却让人光是读完就头皮发麻。工程难度极高,构建成本惊人,调试流程复杂,状态不可控,行为难以解释。我也怀疑:这样一个理想结构真的能落地吗?它真的有价值吗? (2/n)
凡人小北
4个月前
读完 Anthropic 的多智能体系统文章,有几个点挺触动的,尤其是放回我们平时在做 agent 编排和系统落地的过程中,对应起来很多痛点被他们提前踩过、总结得非常系统。 这套系统看上去是给 Claude 提升复杂研究任务能力,底层其实是三个关键词:带宽、结构、机制。 1️⃣从 token 到带宽:扩容问题其实是系统问题 他们很明确地说,单个 agent 很快就会遇到 token 限制,这不是模型能力不行,而是容量不够。很多时候 LLM 的“不会”、“忘了”、“答不出来”,只是 context 塞不下。这一点在我们自己调长链条、多跳调用的时候也很明显。Anthropic 选择的解法不是扩模型,而是拆任务、开并发、分 agent,每个 agent 自带上下文窗口,从系统结构层面扩容。 这种设计非常实用,因为它绕过了 token 墙的天然限制,通过多 agent 并发变相把 token 维度拉开了。这是我最近做 agent 编排时反复体会到的:不是把 prompt 写得多聪明就能解决,而是要想清楚结构怎么设计,谁来拉信息、谁来拼结构、谁来追引用。 2️⃣提示词是系统指令,很重要、很重要、很重要! 这篇文章有个细节写得特别清楚:主 agent 的提示词,是负责分配任务、指明目标、交代格式、选工具的。这个逻辑其实是我们做复杂 agent 系统中很容易忽略的一块:提示词不只是沟通语言,更是调度逻辑、任务协议、格式规范的集中承载体。 尤其是多个 agent 并行运行时,如果没有一个清晰、格式化、结构稳固的 prompt 模板,每个子 agent 拉回来的信息会特别散、错漏率高、很难合并。这时候,主 agent 的提示词就等于一个调度中枢的“编程语言”。 从我们平时用的实践来看,这就意味着主 agent 的提示词策略应该和流程图一样严谨:每一步要预设结果、预设失败、预设上下游。这块我觉得是现阶段很多 agent 框架还不够成熟的地方。 3️⃣系统级机制,决定了能不能撑进生产环境 我觉得特别值得借鉴的工程概念:checkpoint、异步重试机制、全链路 tracing、彩虹部署。这几个在大数据异步系统里很常见概念,AI 领域得好好学习下。 这些词不是为了好听,它们背后都是在回答一个问题:这个系统崩了怎么办?agent 卡死怎么办?升级逻辑还没验证好怎么办?一整套机制让这个系统不是在 demo 一个可能性,而是在上线跑任务、自动修复、平滑演进。 平时我们在做流程型 AI 系统的时候,很容易只关注“怎么生成”“怎么判断好坏”,但 Anthropic 的做法提醒我:agent 系统本质上要往服务化方向走,就必须预设失败是常态,重试是能力。 4️⃣评估机制是不可缺的闭环,不然做不出反馈导向的系统进化 他们有一个细节很打动我:让另一个 LLM 去评审 agent 的结果,从准确性、引用合理性、覆盖度等多个维度打分。这就相当于在系统里内嵌了 QA 流程,而且不是事后人评,而是可以插入调试链路的 LLM 评测器。 我们自己在调多 agent 结构时常遇到一个问题:任务执行完了,但结果质量很难量化,只能靠人工判断或者事后比对。这套“LLM 评估 LLM”的机制,让我们开始可以想象一种更自动化的 agent 演化路径:系统自己跑,自己打分,自己选择 prompt A 还是 B,更适合持续调优。 5️⃣并发是工具,不是策略,适用场景边界要想清楚 这套系统最适合的场景是:问题复杂度高、信息广度要求强、非实时产出型任务。例如政策研判、产品调研、文献综述、竞品分析这些,在私域服务里也可以类比成“多维标签用户意图研判”这种复杂工作。 但如果放在需要紧密配合、频繁迭代、低延迟要求的任务上,例如代码生成、对话任务、实时接口构建,多 agent 的协调成本反而可能放大系统复杂度。所以并发结构是个好工具,但什么时候该开几个 agent,什么时候该单线程跑到头,这种策略边界要想清楚。 这篇文章最核心的不是“我们做了一个多 agent 系统”,而是他们已经把多 agent 作为一种工程能力进行制度化建设:有流程、有容错、有评估、有上线机制。 对在第一线实际落地 AI 能力的团队来说,有一个非常直接的启发是:构建 agent 系统,不能只是对话式的 prompt 编排,而要像搭服务一样,从任务定义到评估反馈,从并发机制到异常兜底,形成一整套可以持续运行的系统逻辑。 这一点,比起模型调优,本质上更像是一种架构能力的竞争。
orange.ai
5个月前
今天很有趣,两家知名的公司各出了一篇文章,争论要不要使用多智能体系统。 Claude 的官方 Anthropic :如何构建多智能体系统 Devin 的官方 Cognition :不要构建多智能体系统 这核心的争议点在于:Context 上下文到底应该共享还是分开? Claude 这边的观点是,搜索信息的本质是压缩,单个智能体的上下文有限,面对无限的信息,压缩比太大就会失真。 这就好比一个老板能力再强,也不可能搞定所有的事情,还是需要雇人去解决。 通过多智能体系统,老板让不同的智能体分别研究、汇报重点,老板最后整合到一起。由于每个智能体有自己的专长,具有多样性,减少了单一路径依赖现象,实际效果上,多智能体也超过但智能体 90%。 这是集体智慧,一起协作获得的胜利。 Devin 这边的观点是,多个智能体的上下文不一致,会导致信息割裂、误解、他们汇报给老板的信息经常充满了矛盾。 而且很多时候,智能体的每一步行动都是依赖前一个步骤产生的结果,而多智能体通常分别跟老板沟通,互相之间缺乏沟通,这样很容易导致互相矛盾的结果。 这体现出了个体智慧的完整性和高效性。 两边观点看下来,是否使用多智能体架构,特别像是人类运行一家公司的选择。 一人公司还是多人公司? 一人公司,一个人的脑力、体力、时间都是非常有限的。 优点是一人公司的沟通成本为0 ,可以把所有的时间都高效使用。 而多人公司,人越多,沟通成本就越高,管理难度就越大,总体效率下降。 但因为人数多,脑力多,体力多,整体的价值产出也就有可能更多。 多智能体的设计很有难度,这其实很正常,就像运行一家公司一样,很难。 难就难在建立有效协作的系统。 而且 1个人,3个人,10个人,100人,1000人,所需要的协作系统又不大相同。 参考人类历史,依靠集体智慧,人类在近代获得了文明的指数级发展。 多智能体的集体智慧,也许就是在 Scaling Law 逐渐放缓后,AI 获得指数级发展的那个萌芽。 而关于上下文,人类的协作至今也无法做到完美的上下文管理。 这让我想到,软件工程从来不是追求完美,而是持续迭代。
orange.ai
5个月前
做 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,后者处理文档和研究报告以确定引用的具体位置。 这确保所有声明都正确归属于其来源。最终的研究结果(包括引文)将返回给用户。