Meta Agent 安全风波、纳维-斯托克斯争议与 Claude 遭滥用
朋友们,
过去两周,为 AI 危险大肆渲染焦虑的声音声量极高,且势头迅猛。AI 技术本身并没有发生什么突发性的危险转向,但围绕它的炒作——背后似乎有一场精心策划的公关运动在推波助澜——已经制造了相当大的恐慌。我担心这会成为我们领域发展的倒退。
我曾多次撰写文章指出,对 AI 的恐惧被过度夸大了。AI 的能力确实可以像人类一样不可思议且难以预测,当直接参与者表达担忧时,这种焦虑是理性的。但我将这些问题视为未来工程工作的指示信号,而非不可逾越的障碍或天塌下来的灾难。AI 技术仍在不断进步——这是好事!——但由于公众对技术进展理解不足,那些试图制造炒作的人便获得了反复操弄机会。
首先,与几个月前相比,我没有看到 AI 导致人类灭绝的风险有任何升级。关于这一点的理论依然是几个月前那些天马行空的科幻场景。AI 风险最大的变化在于其网络安全能力——这是一个我们应该严肃对待的话题——但即便如此,这也绝不会导致世界末日。
近期导致恐惧情绪加剧的最显著事件,是 OpenAI 团队部署的 Agent 集群黑进了 Hugging Face。主流媒体报道中充斥着大量炒作。例如,有媒体称此次攻击是由 1,200 个 Agent 集群完成的。虽然在技术描述上这并无不实,但在我写这篇文章时,我笔记本电脑上正运行着约 1,300 个进程。没错,让大规模 Agent 集群并行处理任务确实是一项重要的技术进展,且在高算中,多个进程同时运行本就是常态。因此,这不应被视为某种神奇的能力。
此外,OpenAI 沙箱和监控流程中的漏洞也是这次事件得以发生的关键。正确的做法是修复这些漏洞、加强监控,而不是叫停 AI。攻击软件系统的方法早已广为人知。AI agent 的主要优势在于不知疲倦——它们会持续尝试各种手段,耐心地把多个漏洞串联起来,而这些在过去需要的人力成本高得不切实际。但长期来看,我认为优势还是在防御方(因为他们掌握更多信息,能发现并修复漏洞),只是网络威胁的格局已经发生巨大变化。发现和利用漏洞依然存在瓶颈:AI agent 仍需大量试错才能找到有效手段,这些操作需要时间,也可能被防御方察觉。所以,尽管如今很容易获取护栏已被移除或削弱、不会拒绝执行网络攻击的领先开源权重模型,世界也并没有因此崩塌。

我还担心很多报道把 AI 过度拟人化,不必要地把 LLM 和 agent 当作人来对待。就像我抡锤子砸钉子没砸中,不小心把墙砸出个坑,问题不在锤子,而在我使用锤子的方式。同理,如果我提示一个 agent 去入侵别人的系统,责任在我,而不在 agent。
当然,我们希望构建尽可能安全和可预测的系统。(例如,一把不安全的锤子,是在正常使用中锤头就可能随机飞出的那种。)当前的代理系统尚不具备可预测性,但我看不出有什么理由认为,通过应用稳健的工程实践,我们就无法让它们变得极其安全可用。在预言 AI 带来的毁灭时,一个新的元素是 AI 公司推卸自身产品的责任。“不是我干的,是我失控的代理干的!”我们需要在工具制造者和使用者之间划定责任的界限,但当出现问题时,让我们追究建造和/或使用锤子的人的责任,而不是锤子本身。(顺便说一下,如果你担心 AI 生物武器风险,David Bellamy 有一篇精彩的文章,解释了为什么这也是过度炒作。简而言之,构建生物武器的瓶颈不在于智能,而在于实验室工作和制造环节。)
暂停 AI 进步造成的危害将远大于其益处。首先,我们的对手肯定不会放慢脚步。其次,工程需要经验性地发现问题以便修复。如果我们暂停 AI 发展十年,发现并实施安全工程修复措施的时间也将相应推迟大约十年。
当然,煽动恐惧的动机——无论是为了监管俘获、吸引眼球,还是让自家技术显得更强大——与以往无异。推卸责任是一种新现象。但仔细从技术角度审视实际风险后,我认为被煽动起来的恐惧程度缺乏事实依据。我们仍需在提升 AI 安全性方面开展艰难的研究和工程工作,但有益的应用远远大于风险,我们应当继续构建。
Andrew
来自 DEEPLEARNING.AI 的信息

你的办公桌不应是你唯一的学习场所。DeepLearning.AI 应用让你随时随地追踪最新新闻和课程进度,无论是在通勤途中还是咖啡休息时。在 iOS 和 Android 上下载应用
新闻

如何让大众级 AI 代理更安全
恶意网页可能会骗过 AI 代理,使其做出违背你意愿的操作。Meta 在构建代理时,预设了这种攻击必然发生,并据此设计机制,确保 Prompt 注入类漏洞不会导致代理偏离正确轨道。
新动向:Meta 发布了 Muse,一款基于 Muse Spark 1.3 模型的个人 AI 代理。用户可以通过 Muse App 或 WhatsApp 对其进行控制,它不仅能读写邮件、浏览网页、填写表单、完成购物,即便 Muse App 关闭,后台仍可继续工作。除非用户主动退出,否则交互数据将用于训练 Meta 模型。
- 功能特性:可连接浏览器、邮件客户端、日历、Instagram、Facebook 等应用,以及汽车、智能家居设备;支持对每项服务单独配置读取或写入权限;支持定时触发及事件触发的后台运行;记忆功能支持读取、编辑与遗忘;提供操作日志;输出格式包括文档、PDF、网页及仪表盘;通过 Stripe Link 进行交易;即将支持 Shop Pay 和 1Password。
- 可获取性:仅限美国,18 岁及以上用户可通过 iOS、Android、muse.ai及 WhatsApp 使用。
- 价格:免费(每周最高 1 亿 tokens);$20(每周最高 5 亿 tokens);$100(每周最高 30 亿 tokens)。
- 授权许可:专有软件。
- 未披露信息:Muse Spark 1.3 的参数量、架构、知识截止日期及训练数据;Muse Prompt 注入分类器的评估结果;Muse 代理本身的评估指标。
工作原理: Muse agent 从设计之初就以安全为核心。每个 agent 运行在一台 VM 上(一个独立专用的虚拟机,配备 Linux 操作系统、浏览器、存储和内存)。VM 中保存着 agent 的工作区、用户文件以及所有已连接服务的凭据。为防范提示注入攻击,VM 被划分为两个区域:(i) 一个封闭的运行时单元(runtime cell),agent 及其工具在这里处理不可信数据;(ii) 单元之外的服务,负责保管密码并决定 agent 能做什么。
- agent 的 harness、用户工作区和工具都位于一个 Linux 容器内,拥有独立的文件系统和虚拟网络接口。VM 限制其对操作系统的请求和所持有的权限,运行时单元内的管理员权限不会延伸到宿主机。单元只能通过本地通道访问外部服务,操作系统例程会验证通道两端各自的进程,且这些通道不携带任何密码或访问令牌。
- Muse Spark 1.3 完全接触不到凭据。密码和访问令牌由运行时单元之外的一个凭据服务处理,agent 使用的是替代令牌。另一个叫 Sentinel 的 agent 与 Muse Spark 1.3 运行在同一台 VM 上,但位于运行时单元之外,它负责审批每个请求,并在请求离开 VM 时换入真实凭据。Meta 表示,这样一来攻击者就无法通过提示注入窃取凭据,因为 agent 手中根本没有凭据。日历等外部服务的连接器同样运行在单元之外,且只获得各自所需的凭据。邮件连接器会在 agent 读取邮件之前,先剔除临时验证码和密码重置链接。
- 只有 Sentinel 能批准 Muse Spark 1.3 提出的操作。它会检查每个出站请求,并将连接器的每次调用与用户设置的权限进行比对,然后决定放行、拒绝,还是交由用户判断。系统还会追踪哪些工具进程读取过用户数据:未读取用户数据的进程可以自行访问一小份预先批准的目标地址列表,而读取过的进程则必须先征得用户同意。
- 当 Sentinel 请求用户输入时,智能体停止执行,该请求以系统对话框的形式发送至 Muse 应用,而非作为对话中的一条消息。这样,提示注入文本就无法伪造用户的批准。批准权限绑定于特定的连接器、目标及用途。用户可限制批准范围,使其仅适用于单一操作、会话、任务或时间段,或适用于所有后续使用。发送邮件和进行购物始终需要用户验证,而在不熟悉的网站上购物则使用来自 Stripe Link 钱包的一次性卡号,该卡号仅对特定商户、金额和时间段有效。
- Meta 对 Muse Spark 1.3 进行了训练,使其能够抵御提示注入,并增加了三层额外保护。(i)来自系统外部的数据在进入模型上下文时被标记为不可信。(ii)一个分类器集成体(与模型独立训练)对每个文件和工具输出进行筛选。该过程在单元格外部运行,攻击者无法将其禁用。(iii)在浏览器中,子智能体读取每个页面的结构化摘要——即屏幕阅读器使用的无障碍树——而非页面的代码。它无法运行 JavaScript,因此隐藏在脚本或标记中的指令无法到达它。其他分类器监视页面文本、图像和下载文件中隐藏的注入尝试,还有更多分类器会在智能体试图将个人数据路由到任务未要求的目标时对其进行阻止。
但是: Meta 表示,它使用一个未公开的评估数据集来评估 Muse Spark 1.3 抵御提示注入的能力,且未提供用于筛选传入数据的分类器的准确率指标。相反,该公司提供最高 300,000 美元的漏洞赏金用于有效报告,以及最高 130,000 美元的奖励用于成功的提示注入攻击。
幕后故事:Muse 整合了 Meta 当前 AI 实验室成立之前,由安全研究员提出的设计特性。2025 年 4 月,由 Edoardo Debenedetti 领导的 Google DeepMind 和苏黎世联邦理工学院(ETH Zurich)研究人员提出了 CaMeL。该架构将“规划模型”与“读取不可信数据的模型”分离,并在调用工具前强制执行预设策略。两个月后,独立开发者 Simon Willison 指出了 AI 智能体的“致命三要素”:私有数据、不可信内容以及数据外发通道。Willison 认为,唯一安全的做法是避免让这三者同时出现。据 Meta 称,Muse 虽然处理这三类数据,但所有外发数据都经过一个模型无法篡改的组件。尽管基于过往提示词注入(prompt injections)训练的分类器可能拦截 99% 的新攻击,但 Willison 撰文表示,这依然是一个不可接受的风险。因此,Meta 构建了容器、凭证隔离机制以及 Sentinel,以确保在初始防线失效时仍能守住底线。
为何重要:安全性是当前智能体的重大风险。大多数 agentic 框架(harnesses)都包含系统提示词,指示模型忽略内容中出现的指令,并配有识别此类指令的分类器,但高明的黑客能够绕过这些防御。Meta 假设模型会被欺骗,因此它在操作系统层面构建了控制机制,无论模型行为如何,这些控制都应当生效。Meta 详细列出了模型之外的防护层:一个智能体无法逃逸的容器、它无法持有的凭证、它无法绕过的守门程序(gatekeeper),以及不通过对话进行的审批流程。构建敏感任务智能体的开发者可以借鉴这种方法。
我们的思考:Meta 表示最终会发布 Muse Spark 的权重。但让 Muse 智能体保持安全的,更多是其框架(harness)而非模型本身。我们希望 Meta 也能开源这款软件。

揭秘:关于一项里程碑式智能体驱动数学证明的争议
OpenAI 的智能体解决了一个悬赏 100 万美元的长期数学难题,但不少观察者质疑这些智能体是否借鉴了两位数学家未发表的研究成果。
最新动态:9 月 8 日,OpenAI 宣布,一个未发布的模型给出了流体力学中一个未解问题的证明:Navier-Stokes 方程是否会出现物理上不可能存在的解。这个证明由 1 万个智能体耗时 88 小时完成,结论是肯定的:在特定条件下,这些方程确实会失效。不过,数学家 Tristan Buckmaster 和 Levent Alpöge 此前一直在用 OpenAI Codex 研究同一个问题,Buckmaster 也和 OpenAI 的人员讨论过这个项目。在他们发布相关方程证明的仅一天后,OpenAI 就公布了自己的证明,这引发了外界的猜测:OpenAI 的智能体是否看到了他们的工作,也许是模型在他们的数据上训练过。
智能体证明了什么:Navier-Stokes 方程描述流体的运动规律,从管道里的水流到机翼上方的气流都适用。几十年来,数学家一直试图确定这些方程是否总能产生“光滑”的解——即不会出现突变或无限大的速度——还是可能预测出无限速度(真实流体不可能达到)。无论哪个答案都能解决这个由克雷数学研究所设立、悬赏 100 万美元的千禧年大奖难题。OpenAI 的证明表明,在一个光滑的外力作用下,流体的速度可以突破有限上限,而能量仍然保持有限。克雷研究所的官方问题描述承认这一结果。(更难的版本——即完全不存在外力时出现无限速度或突变——仍是未解之谜,这也是大多数数学家心中的目标。)
角逐悬赏:OpenAI 发布了一篇 166 页的论文,以及智能体用 Lean 编写的代码。Lean 是一种编程语言,可以让计算机逐行验证数学证明。底层模型的名称、规模和训练数据均未公开,OpenAI 只表示该模型“能力显著强于 GPT-6 Astra”,是通过“在预训练模型基础上进行大规模强化学习”构建的。
- 9 月 1 日,在得知其他地方的智能体正在解决千禧年难题的传闻后,OpenAI 启动了一组旨在攻克这些公开问题的智能体。每个智能体都可以读取网页缓存快照、运行代码并与组内其他智能体通信。
- 一个由近 100 个智能体组成的团队在约 50 小时内解决了与欧拉方程相关的问题——这是 Navier-Stokes 方程的简化情形。随后,OpenAI 将负责其他问题的智能体调往 Navier-Stokes 方程。该团队规模扩大至 10,000 个并发智能体,于 9 月 5 日启动后 88 小时得出结论。将推理步骤形式化到 Lean 中又花了 17 小时。
- 智能体之间总共交换了 490 万条消息,生成了约 3000 亿个输出 tokens。OpenAI 未披露成本。根据 GPT-6 Astra 的标价,估算范围在 200 万美元 到 2250 万美元 之间。
- 截至目前,尚无人完成对 OpenAI 证明的独立评审。Clay 研究所的规则要求先公开发表,等待两年,并经专业数学家普遍接受和评审,才会认定一个解法。OpenAI 表示他们并不寻求该奖项。
争议焦点:在 OpenAI 宣布结果前数小时,NYU 数学家 Tristan Buckmaster 发布了一份声明,指控 OpenAI 研究员 Sébastien Bubeck 就他在 Anthropic 工作的 Levent Alpöge 共同完成的相关工作中的署名权施加压力。Buckmaster 表示,他和 Alpöge 花了大半年时间使用 OpenAI Codex 和 Anthropic Claude 追逐类似证明,这一工作在数年前由数学家 Diego Córdoba 和 Luis Martínez-Zoroa 开辟的路径上展开,Buckmaster 归功于二人奠定了“该计划的基本思路”。Buckmaster 和 Alpöge 于 9 月 7 日发布了三个较简单流体方程(包括 Navier-Stokes 变体)的 Lean 验证证明。
- Buckmaster 表示,他与 Alpöge 的合作纯属个人行为而非机构行为,相关费用全部由其个人科研经费承担,“包括支付给 OpenAI 的一大笔费用”。9 月 6 日,他两次通过电话与 OpenAI 的 Bubeck 通话,询问 OpenAI 的模型是否在其训练数据中接触过、或是否有权访问他与 Alpöge 在 Codex 中存放文稿的会话记录。据他称,对方回复该模型并未查询用户数据,但关于是否将其用于训练的疑问未得到解答。他还提到,Bubeck 建议 Buckmaster 亲自撰写 OpenAI 的研究成果,且不要提及 Alpöge 的名字,因为 Alpöge 在 Anthropic 任职。Bubeck 在 X 社交平台上< a href="https://x.com/SebastienBubeck/status/2097379411691516310">发帖否认曾试图省略 Alpöge 的名字。
- 9 月 8 日,OpenAI 声明称,在其研究人员和 Agent 发布前均未看到二人的工作,也未访问任何特定用户数据——但无法确定公司是否利用他们的活动来提升模型性能。9 月 10 日,OpenAI 撤换了该句表述:经查证,其在声明发布前两个月内 Buckmaster 的 Codex 提示词“对系统没有任何影响,包括通过训练方式”。然而,OpenAI 未回应更早之前的 Codex 提示词是否可能影响了系统。
新闻背后: 构建精通数学的 AI 竞赛已进入尤为激烈的阶段。在 OpenAI 发布声明前四天,Anthropic 宣布一款 Claude 模型生成了费马大定理的首个完整 Lean 证明。一款与 Claude Fable 5.1 性能相当的研究模型自主工作了 11 天,消耗了约 60 亿个输出 Token,仅为 OpenAI 统计量的 2%。该证明未引发任何争议,其中不包含任何新的数学发明。Anthropic 在 Kevin Buzzard 团队工作的基础上构建成果并予以署名,该团队自 2024 年起便开始该定理的形式化工作,最终成果也获得了 Buzzard 的认可。
为什么重要:Buckmaster 把 OpenAI 的 Navier-Stokes 证明称为“Deep Blue 击败 Kasparov 的时刻”,指的是 1996 到 1997 年间 IBM 的 Deep Blue 计算机战胜国际象棋世界冠军 Gary Kasparov 的那场标志性对弈。有评论人士质疑数学家是否会成为濒临消失的职业。不过 Buckmaster 指出,真正关键的是数学家与 LLM 协作推进研究的速度。但一个形式上正确的证明并不能告诉你它为什么成立、问题设定本身是否正确,以及能从中引出什么意义。自动化验证如今成本已经很低,但人类可读的理解依然昂贵。
我们的看法:围绕 OpenAI 是否使用了数学家工作成果的争议提醒我们:要检查 LLM 服务商的隐私设置,在处理不希望被服务商使用的敏感数据时,考虑启用零数据保留选项。

Anthropic 称部分 Kimi 和 DeepSeek 用户收到的其实是 Claude 的回答
Anthropic 指控 Moonshot AI、阿里巴巴、DeepSeek 等七家中国 AI 开发商滥用其 Claude 模型,欺骗自家用户并借此改进自己的模型。
最新动态:Anthropic 在一份冗长的报告中指控,这些中国公司把 Claude 对用户提问的回答当作自家模型的输出来呈现,并将 Claude 的回答蒸馏进自己的模型。报告详细列出了这些公司在 2026 年 2 月至 8 月间违反 Claude 服务条款的多种行为,包括通过中国境内的灰色渠道获取 Claude 访问权限,并将其用于诈骗、间谍活动以及设计生物武器或自主武器。
运作机制:Anthropic 的指控聚焦于蒸馏技术,即由教师模型生成对查询的响应,再利用这些响应训练学生模型。Anthropic 承认蒸馏是合法的训练方法,但该公司反对大规模提取 Claude 推理能力的行为——据称涉事公司是通过欺诈手段实施的——并试图以极低的成本和算力在另一个模型中复现该能力。Anthropic 将此称为“非法”蒸馏。
- Claude 在中国大陆被屏蔽。Anthropic 称这些公司使用中转站绕过地域限制。据称,其中多家公司使用虚假身份创建账户,输入伪造或窃取的信用卡号码,并使用了盗用的 API 密钥。
- 据 Anthropic 称,阿里巴巴、DeepSeek、Moonshot AI、小米和智谱(又称Z.ai)运行了蒸馏活动,旨在通过数百或数千个欺诈账户提取 Claude 的推理日志。
- 2026 年 5 月至 6 月间,阿里巴巴开展了 Anthropic 迄今发现的最大规模蒸馏行动,涉及 1.51 亿次交互。据称,阿里巴巴通过 5,000 个欺诈账户访问 Claude。
- Anthropic 指控称,智谱创建了网络安全挑战,并利用领先的美国 AI 模型来解决和评估这些问题,旨在将这些能力整合进自家模型。报告称,智谱最初将目标定为 Anthropic 的 Fable 模型,但在 Fable 较强的网络安全防护限制了响应实用性后放弃了这一尝试。随后,智谱转向 Opus 4.6 和另一个美国前沿模型,原因是这些模型的防护机制显得较弱。
- 据称,DeepSeek、Moonshot AI 等公司将自家客户的查询转发给 Claude,并将其输出包装成其他模型的响应。Anthropic 记录了多起敏感信息通过此方式提交给 Claude 的案例。Anthropic 表示,在用户中识别出了一名中国人民解放军成员、一名中国国有企业员工以及一名俄罗斯国防机构代理人。
背景:蒸馏技术近来受到美国头部 AI 开发商和政策制定者的密切关注,他们中的许多人希望保护美国的专有技术。
- Anthropic 今年早些时候指责 DeepSeek、月之暗面(Moonshot)和 MiniMax 进行“产业规模”的蒸馏。
- 今年 4 月,白宫科技政策办公室的 Michael Kratsios 发布备忘录,承认大规模蒸馏是一种对抗性威胁,并表示美国将制定防御策略。
- 今年 7 月,Kratsios 在 X 上发文称,月之暗面在开发自家的 Kimi K3 时蒸馏了 Anthropic 的 Claude Fable。他把这类大规模蒸馏行为称为“不可接受的窃取美国技术的企图”。
为什么重要:把蒸馏作为构建竞争模型的手段,其正当性本身就有争议。但在客户不知情的情况下把其输入转给第三方,再把输出当作自己的成果,这就近乎欺诈了。这类做法不仅损害公众对 AI 公司保护信息隐私与安全承诺的信任,也会动摇整个 AI 行业的公信力。
我们的看法:靠蒸馏是蒸馏不出前沿模型的。蒸馏虽然有助于模型训练,但被 Anthropic 指控的这些实验室都取得了重大技术突破,其中许多是公开发表的,而这些突破才是其模型具备竞争力的关键。所谓“这些公司靠蒸馏美国模型”的说法,让人误以为它们的竞争力完全来自蒸馏,实际上技术创新才是更重要的因素。

智能体也需要提醒
随着智能体轨迹的延伸,它们往往会忽略之前发生的事情,原因包括上下文被截断,或者未能从大量无关信息中识别出关键内容。一种新方案将执行动作的智能体与一个独立的智能体配对,后者负责判断何时提示前者其需要知道的信息。
最新进展:Meta AI 的 Yifan Wu 及其团队推出了 Proactive Memory Agent,它与常规智能体并行运行,用于维护和选择性突显与当前问题相关的信息。在作者测试的所有基准上,记忆智能体都提升了动作智能体的性能。
核心洞察:在解决会产生长上下文的问题时,智能体的历史记录中会包含需求、失败指令和有用观察等信息——但这些信息未必能影响其下一步决策。突显相关记忆可以弥补这一缺陷,而不会使智能体的注意力过载。
工作原理:作者构建了大、小两套系统,每套系统都将动作智能体与记忆智能体配对。动作智能体基于 Claude Sonnet 4.5、Claude Opus 4.6 或 Qwen3.5-122B-A10B(后者规模显然更小)。记忆智能体基于 Claude Opus 4.6 或(在小系统中)经过监督微调和 SETA 命令行问题的强化学习后的 Qwen3.5-27B。
- 根据问题描述及动作智能体最近八次输出或工具调用,记忆智能体会更新一组与问题相关的笔记,其中包含事实、当前工作目录等环境细节、早期遇到的问题的成功修复方案、未完成的部分以及失败的指令(以避免重复)。
- 在每一步,记忆智能体都会向动作智能体的输入中追加无内容或简短的提醒。提醒可能指向动作智能体忽视的问题部分、环境事实(例如可用的工具)或某条失败指令。
结果:在大系统中,记忆模型提升了 Claude Sonnet 4.5 和 Claude Opus 4.5 在 Terminal-Bench 2.0 和 τ2-Bench 上的成功率。在小系统中,它提升了微调后的 Qwen3.5-27B 在 Terminal-Bench 2.0 上的性能。
- 在包含 85 个命令行任务的 Terminal-Bench 2.0 测试中,使用更大内存模型的 Claude Sonnet 4.5 成功率达到 45.9%,而不用内存模型仅为 37.6%。同样地,使用内存模型的 Claude Opus 4.6 成功率为 45.9%,不用则为 43.5%。使用较小内存模型的 Qwen3.5-27B 成功率为 41.1%,不用则为 37.6%。
- 在包含 278 个航空、零售和电信问题的 τ2-Bench 测试中,使用内存模型的 Claude Sonnet 4.5 得分 61.8%,不用则为 55.0%。使用内存模型的 Claude Opus 4.6 得分为 68.7%,不用则为 66.2%。(作者没有测试较小系统在 τ2-Bench 上的表现。)
重要性: 使用独立智能体来管理主智能体的上下文,能显著提升本研究任务的执行效果。由于内存智能体不触碰实际执行任务的模型,因此无需重新训练即可将其集成到现有智能体中。此外,这也使得你可以轻松实验更换模型或智能体框架。
我们的思考: 在另一项结果中,作者发现他们的系统优于一种在每个步骤都提醒行动智能体相关信息的方法。显然,仅仅提醒是不够的,关键在于在对的时刻进行提醒。