CAMEL-AI 团队在 Manus 上线后 1 天内推出的 OWL 就是其中最具代表性的一个，项目实测成绩达到开源界 GAIA 性能天花板，达到了 58.18%，超越 Huggingface 提出的 Open Deep Research 55.15% 的表现。
3 月初，Founder Park 邀请了 OWL 团队进行了一场线上闭门分享，就 OWL 的技术框架、Manus 以及 Agent 相关的技术原理、目前的实现逻辑及商业落地现状等进行了深度探讨。
在进行了一些脱敏处理后，Founder Park 整理了本次沉淀内容。
嘉宾介绍：
李国豪：开源社区 CAMEL-AI 创始人。
Key Message;
OWL 项目和 Manus 并不完全一样，技术上有很多区别，但做的事情相近。
因为 Manus 的出现，大众看到了 AI 技术的可能性，尤其现在 agent 的实际应用，点燃了 AI agent 这一波技术浪潮。
Manus 复现技术相对简单，更多在于产品交互和形态方面，而且 Manus 首发占优势，后续产品要复现它的成功会比较难。
MCP 是未来，它能让所有框架接入相同工具，像 Cursor 和我们的项目都能使用符合 MCP 标准的工具，借助众多开源工具完善 agent。
对于 Agentic AI 来说，基模+外部工程框架并非未来趋势。
如果垂直领域的工作能被通用 agent 轻易取代，那就说明该垂直领域的工作还不够「垂直」，没有解决这个领域最核心的痛点。
高浓度的主流模型（如 DeepSeek 等）开发交流；
资源对接，与 API、云厂商、模型厂商直接交流反馈的机会；
好用、有趣的产品/案例，Founder Park 会主动做宣传。
01
OWL 的源起，
以及和 Manus 的区别
我们目前在打造一个开源社区，名叫 CAMEL-AI，我们的使命是「finding the scaling laws of agent」。简单来说，我们相信 AI agent 有其独特的「scaling laws」，而我们的工作就是探寻它的「scaling laws」究竟是什么样的。
我们一直专注底层技术，做了很多前沿研究，像打造世界上第一个 multi-agent 框架、第一个跨平台操控项目（CRAB：能同时通过 UI 操控手机和电脑上任意 APP），还构建了世界上第一个拥有 100 万 agent 的 multi-agent 系统——OASIS。这些从 0 到 1 的成果，耗费大量精力、时间和工程研究，但是受到的关注比较少，但我们相信会是未来 Agent 应用的重要基础设施。
CRAB：https://github.com/camel-ai/crab
OASIS：https://github.com/camel-ai/oasis
具体而言，我们主要在做以下几件事：
一是搭建基础设施。这涵盖了框架、数据、agent 及其通信协议，还有相关应用。作为一个开源社区，我们还会开发一些面向开发者的工具，主要服务于开发者和研究人员。与此同时，我们也在开展前沿研究，与大家一起撰写论文，进行开放性质的研究。这次开源的猫头鹰（OWL）项目，既是我们的一项学术研究，也是一个能让开发者基于其进行构建的工具。
我们坚信 AI agent 中存在特定的规律，所以开展了很多不同的研究，也开发了不少工具。比如 camel，这是我们的一个基础框架，利用它，你可以进行数据生成，包括生成 COT 数据、instruction-following 数据，还有 alignment 数据。同时，它也能用于任务自动化，像这次 OWL 项目里用到的模块和工作流等，你可以用它实现 UI 自动化、网页自动化等功能。我们还运用大语言模型进行大规模复杂系统的模拟，比如之前的 OASIS 项目，用 100 万个 agent 模拟社交网络行为，包括流言传播、从众效应、观点极化效应等，探索能否通过 AI 实现这些模拟。
简单讲讲 camel，它是一个 agent 框架，和一般框架不同的是，我们非常注重数据驱动，从数据角度构建框架，这样未来 AI 就能实现自我发展。此外，camel 整合了 multi-agent，拥有数据生成相关的流程，集成了国内外几乎所有主流模型，整合了大量工具，具备短期记忆、长期记忆功能，支持多种存储方式。我们还有不同的基准测试用于 agent benchmark。它有多种可执行代码的解释器、不同的数据加载器，这次项目中也用到了。如果你要做检索，它既支持向量检索，也支持 Bm25 检索等功能。这就是为什么我们能快速复刻 Manus，因为我们有一套非常完备的工具库，借助这个工具库可以快速构建各种应用。
猫头鹰（OWL）项目主要复刻了 Manus 的一些功能，我们在项目中提出了一种名为 Optimized Workforce Learning 的技术，用于通用的 multi-agent 协助，主要处理现实世界中的任务，比如网页检索、读取 PDF、生成代码等。说 0 天复刻其实有点标题党，因为这个项目我们做了一段时间，主要时间花在性能提升上，这是一个由我带的博士生们参与的科研项目。Manus 发布两周前，我们在 GAIA benchmark 上取得了开源项目中的最高分。但没发布，原因是项目负责人起的名字我觉得不太好，所以一直没发布，刚好赶上这波热点，让我们提前发布了这个还不太成熟的项目。这几天经过快速迭代，项目也越来越完善。
OWL 项目和 Manus 并不完全一样，技术上有很多区别，但做的事情相近。
给大家讲讲系统框架：用户指令输入后，会进入 multi-agent 系统，系统内的 agent 负责执行任务。我们有 AI user agent 和 AI 助手 agent，二者相互协作、扮演不同角色来完成任务，这个概念源于我们两年前论文提出的方法。OWL 项目沿用了这一思路，两个 agent 相互对话，助手 agent 可调用各类工具，像 web agent 操控浏览器、search agent 进行谷歌搜索或社区搜索、coding agent 生成并执行代码获取结果、document agent 读取并转换 PDF 格式等，并且任意工具都能接入我们的基础系统。
举个例子：让 agent 查找附近影院正在上映的电影，它能打开浏览器，定位所在城市获取近期上映影片信息。或者让 agent 调研代码仓库，它会浏览仓库，明确任务并生成报告。近期我们做了大量更新，现在支持谷歌搜索，能处理视频、图像、音频，可借助 Playwright 实现网页浏览，还能解析 PDF 文档、支持代码执行，有丰富工具可选来增强 agent 能力。
用户可以根据不同任务选择不同工具，不像 Manus 只能使用固定工具。开源的优势就在于你可以定制自己的工具，在自己的领域或应用场景中，将特有的工具加入进来，提高效率和稳定性。
从技术实现角度看 Manus
我挺喜欢 Manus 项目，虽然现在还没尝试过，但我觉得它意义重大，在近期的分享和朋友圈都提过。有句话形容得很贴切，说 Manus 像把火，点燃了 AI agent 这一波技术浪潮。
我们做底层技术研究两年了，从首个基础框架做到现在，得到的关注远不及它。正因为 Manus 的出现，大众看到了 AI 技术的可能性，尤其现在 agent 的实际应用，比如做研究、写代码、操控网页等。其实这些技术在研究领域早有应用，但是 Manus 首次以出色的产品形态，尤其是 UI/UX 形式面向大众，让众多原本不了解该技术的人，包括工程师、研究人员和普通用户，都开始关注，极大推动了 AI 技术发展，我觉得这有重大的意义。
当然，除了推动技术发展的意义，客观来讲，网上对 Manus 评价两极分化。有人说它是国运级产品，我觉得还达不到那个程度；也有人说它是套壳产品，可套得好也是本事，毕竟技术底层都基于英伟达 GPU，从这看「套壳」无可厚非。
从工程角度，通过用户案例推测出他们的做法，感觉有两点值得学习。
其一，（我猜测是）利用 Ubuntu 文件系统做上下文持久化和管理，非常灵活高效。将存储文件置于用户文件夹，方便随时读取，相比传统数据库语义检索更灵活，虽然我们还没进行严格对比，不过肯定有其优势。
其二，把终端命令行运用到极致。有技术背景的朋友都清楚，命令行非常通用，功能强大，能写代码、浏览网页等。AI agent 如果能熟练运用命令行，便具备超强通用能力，还能安装 Python 包或系统软件包，极大拓展功能。学会把命令行当作通用工具解决问题，远比自己构建工具高效得多。
在国外，Manus 火得比国内稍微晚两天，评价同样两极分化。一部分人觉得产品做得很棒，仿佛通用 AI 时代要来了；另一部分从技术层面看，觉得这是个谁都能做出来的简单「套壳」产品。Manus 的首席科学家在推特上分享了很多，他们自己也说没什么技术秘密，很坦诚地分享技术，听起来好像就是一些成熟技术的组合。比如他们提到用的 agent 来自 UIUC 的一个研究项目 CodeAgent，使用 Claude-3.5 模型作为主要 agent，通过 post-trainingQwen 模型来做规划之类的。
总体而言，我认为 Manus 有很多值得借鉴的地方，对技术发展意义重大，并非像有些人说的那么不堪。
Agent 之间的差距
可能主要是模型差距
Q：OWL 和 CAMEL 离大规模实际部署有多大距离？实测中单次调用消耗 24 万 token（成本约$36）。如果是作为商业化产品，如何构建不可替代的付费价值？有没有可以降低消耗的方法？
李国豪： 关于 36 美元的花费，我不太清楚具体任务，证明费马大定理之类的？就我们做的一些简单任务而言，像单纯打开网页查找信息，或者调研某条新闻、某项技术，一般花费不会超过 1 美元，大概也就零点几美元。36 美元这个花费确实挺高的，毕竟我们框架所使用的模型成本相对较低。
在框架里，我们主要用的是 GPT 相关模型，少数推理任务采用 o3-mini，相较于 Claude 3.7 成本要低很多。当然要是你追求更好效果，可以选用 Claude 3.7。不过，也不排除存在这样的情况：agent 在执行任务时可能无法完成，却反复调用、尝试，在实际上无法完成任务的情况下，这就可能导致大量的 token 消耗，成本也就随之大幅上升。针对这种情况，我们可以设置最大步数等限制，以此来确保成本不会过高。
总体来说，大部分任务的成本没那么高，尽管完成一个任务需要零点几美元甚至 1 美元，我认为作为一款商业化产品，尤其是 ToC 的产品，目前最重要的就是降低成本。只有当用户量非常大时，成本能够降下来，这个产品才有可能真正实现大规模应用（scale up）。比如 OpenAI 的 Operator 每月收费 200 美元，很多人就觉得价格昂贵。我觉得 Manus 可能也是如此，他们采用邀请码机制，限制用户使用，可能并非是想搞饥饿营销，而是服务器成本、算力消耗以及模型 API 调用等方面的成本都相当高。如果不做好成本控制，一旦向所有用户开放，假设拥有 100 万用户，一天可能就会花费高达 1000 万美元。
至于如何降低成本，这涉及很多层面。首先是模型能力方面，如果模型能够更高效地完成任务，更精准地理解指令，并通过最优规划去执行，自然能够降低成本。其次从推理层面以及硬件层面来看，在推理层面，如果能做好量化、稀疏化、缓存（cache）等技术，就能够降低推理成本。在硬件层面，如果能使用比英伟达芯片更便宜的专用推理芯片，进行硬件优化，也有可能进一步降低成本。
Q：与 Manus 在复杂任务的差距主要是什么原因导致的？有什么优化方向？
李国豪： 我们通过在 GAIA benchmark 上对比发现，在 level-1 的性能上，我们和 Manus 差不多，但在 level-2 和 level-3 上，我们的性能比 Manus 差很多，大概差 20% 左右。主要原因有以下几点：
其一，我们使用的模型不同。我们用 GPT-4o 测试，Manus 用 Claude 3.5，比我们的模型要好很多，因为 Claude 3.5 具备 Computer Use（代码执行）的能力。最近 OpenAI 最近也开放了 computer use 接口，如果我们的项目和 Manus 都改用支持 computer use 的模型，差距会缩小。level one、level two、level three 是按任务难度划分的级别，level three 最难。所以，模型差距是关键，换成支持 Computer Use 的模型，性能将大幅提升。
其二，我们现在也在优化一些工具，力求缩小与 Manus 在工具层面的差距。实际上，我们开发的工具不少，双方各有对方没有的工具，我们打算补齐自身缺失的部分。
其三，在工程优化方面，这就需要进行更多的调试，通过更多的实验让它表现得更好。
顺便提下 MCP，我们已集成了 MCP，MCP 能让我们使用任意开发者开发的工具，很厉害。
我觉得 MCP 是未来，它能让所有框架接入相同工具，像 cursor 和我们的项目都能使用符合 MCP 标准的工具，借助众多开源工具完善 agent。简单来说，利用「MCP Toolkit manager」，把 MCP 服务器信息给到它，连接 MCP 就能与相应 APP 连通，agent 随之可获取并使用所有 MCP 工具，和其他场景使用 MCP 的方式一致。
附MCP介绍：拾象科技万字详解MCP：Agentic AI中间层最优解，以及创业公司的三个机会
Q：GPT 出现大约有 3 年的时间，为什么 Manus 现在才出现？
李国豪：GPT 是在 2022 年 12 月发布的，Manus 现在才出现，我觉得并非突然，而是经历了一个量变的过程。
2023 年 3 月我们就发布了第一个 multi-agent 的框架，当时用 multi-agent 写游戏、代码、股票交易软件等，当时做的很早而且也是处于科研领域，没做成好产品，没有受到太多关注。那时 AutoGPT 也是很火的项目，和我们算同期，能做搜索、代码生成等，但效果也不算好，但整个形态从很早之前就有了。之后像 kimi、豆包、Perplexity 等产品把搜索做得不错，Deep Research 进一步优化，OpenAI 的 Operator 能操控网页。Manus 也是在这些基础上的量变，可能也产生了质变，经过了优化之后出现的。
所以 Manus 的出现不算突然，它和 Operator 产品很相似，出现时间也不长。业界说复现 Manus 不难，我认为复现形态相对容易，但要达到一样的效果还需要评估才行，所以中不中肯要看这个「复现」要到什么程度了。从技术层面看，我们对底层技术较了解，而且 Manus 自己也说没什么秘密，复现技术相对简单，更多在于产品交互和形态方面，而且 Manus 首发占优势，后续产品要复现它的成功会比较难。
Q：如何看待 Manus 采用 CodeAct 来调用工具，和 MCP 的差异是什么？
李国豪：Manus 是通过写代码调用的工具，这与使用 MCP 进行的所有调用并不冲突。MCP 解决的是 agent 与工具之间接口的统一问题，而且 MCP 也支持以代码形式执行调用，并不矛盾。
Q：从 OWL 角度如何看待 MCP 路线和 multi-agent 之间的关系？
李国豪：MCP 的服务器（server）可以是简单工具，也可以是 agent。如果服务器和客户端（client）均为 agent，就能实现两个 agent 间的通讯。而且，服务器和客户端本身也可以是 multi-agent 系统，如此便可实现 multi-agent 之间的通讯。
总之，MCP 统一了它们之间的通信，至于参与通信的实体，既可以是工具，也可以是 agent，由使用者自行定义。
垂直领域 Agent 需要更深入、
更专业
Q：Agentic AI 目前有两条看似相反的实现路径，一条基于底层模型端到端的学习 tool learning 能力，一条基于基模+外部工程框架，如何看待这二者的区别？
李国豪：从工程手段来看，部分可能只是过渡阶段。我们的框架基本没走后一条路线，因为觉得它并非未来趋势。以前很多做法是让 AI 输出 JSON，我们认为这只是短期行为。当然，也有一些工程手段能让输出 JSON 更稳定或强制其输出，像 Outlines、XGarmmar 之类工具，通过在模型采样时进行约束采样（constrain sampling），能更好地调用工具。
这两条路线其实是互补的。模型使用工具的能力本质上是概率模型，无法永远保证调用工具完全准确。外部工程架构方面，如果是通过提示词工程（Prompt Engineering）输出稳定的 JSON，可能还是依赖模型能力，并非长期首选；但如果基于约束采样等方式实现工具调用，是很好的方式，其原理是利用控制机制确保 token 采样满足某种语法，以适配工具调用。
总之，两者并不冲突。明确工程层面和模型层面各自该做什么，就能让两者并进，把事情做得更好。
Q：是否认可 Manus 等通用 agent 框架已初步成型？如果是的话，垂类 agent 框架是否更值得发力？
不同领域的信息处理逻辑、所需的工具，数据源、api 都不同，导致通用 agent 框架难以很好地适配垂类场景。例如，做 2025 年宏观环境与 2022 年的对比及预测，和做自动比价的机票助手，两者逻辑截然不同。基于以上论点，实现难度可能在哪些环节？
李国豪：我认为垂类领域更值得发力。用通用框架或模型解决专业领域问题，势必存在效率或解决能力方面的不足。比如，假如你是化学专业学生，要做化学实验，可将框架应用在化学领域，让 agent 调用相关的工具；做宏观环境预测，也能为 agent 提供特定数据源等等，而不是依赖通用方案。
其中，最难的是找准问题所在。不同领域难点不同，有的是工具欠缺，补充工具即可；有的是推理能力不足，那就采集数据优化模型以提升推理；还有的缺乏有效监督信号用于训练，比较开放，这种情况就需根据期望结果，通过偏好学习等方式来解决。
Q：通用 Agent 产品的能力提升是否会持续挤压垂类 Aqent 市场空间？（like 通用搜索>垂类搜索？)
通用 Agent 应用怎样解决输出内容个性化问题？（如旅行攻略场景，没有用户偏好数据即使爬取再多网页也很难生成满足需求的结果）
李国豪：我觉得 AI 领域和模型领域还是有所不同，虽然不排除未来通用模型能解决很多垂直领域问题，但效率始终是个问题，通用 agent 解决垂直领域问题时，总会有效率不足的情况。
除了效率，短期内还存在一个问题，即通用 agent 是否会持续挤压垂直领域 agent 的生存空间。如果垂直领域的工作能被通用 agent 轻易取代，那就说明该垂直领域的工作还不够「垂直」，没有解决这个领域最核心的痛点。
Agent 和模型有很大区别，agent 更需要优质的交互界面（interface）和良好的 UI/UX（用户体验设计）。模型的输出通常是文本，而 agent 的输出形式多样，比如操控浏览器，就需要好的 UI/UX 来展示操控界面；如果是操控机械，就不能用同一套产品。如果涉及到专业领域，可能还需要可视化结果或特定操控工具，所以它们的 UI/UX 设计差异很大，产品形态也有很大不同。
因此，如果通用 agent 对垂直领域 agent 产生挤压，那就需要把垂直领域的工作做得更深入、更专业。
Agent 会带来新的人机交互
Q：通用 agent 怎么解决内容输出个性化的问题？
李国豪：对于个性化问题，目前线上的解决方案更多是通过记忆模块来实现。这个模块能跨不同任务生成不同知识，在执行任务前会检索知识，回忆其中的内容，从记忆层面解决用户偏好等问题。不过，这需要与它不断交互以产生个性化。OpenAI 的 ChatGPT 也有类似功能，如果想做得更好，可能需要提供更多数据，甚至进行训练。
Q：类似 Manus 的通用 agent 嵌套多个模型，导致业务多个环节的步骤都会产生幻觉，可用性直线下降，难以商用，该如何优化？
李国豪：我认为「嵌套多个模型一定会导致性能线性下降，且每一步都一定会产生幻觉」这个陈述未必正确。这取决于所构造的系统是收敛系统还是发散系统。如果多个 agent，每一步都更趋向收敛，那么产生的幻觉会更少。比如每一步都采用不易产生幻觉的 agent，性能不一定会线性下降。
这个问题需要结合实际场景分析，明确每一步产生幻觉的原因，是模型的问题还是工具的问题，进而思考能否通过更换更好的模型或工具来解决。
Q：类似于 Deep Research 这类端到端的 agentic 模型产品未来有没有可能吃掉类似于 Manus 这种套壳式产品？
李国豪：关于 Manus 未来是否会做端到端训练并不明确。据我所知，他们自己称规划模型是经过训练的，执行层面的模型用的是 Claude。但现在模型大多可以微调，OpenAI 也提供了微调接口，Manus 同样可以微调，微调之后是否算端到端也不好说。
我认为如果 Manus 能把「壳」套好，自身架构做得更完善，不一定会被淘汰，这取决于他们的发展路线。他们已经有大量用户数据，也有能力做端到端训练。开源模型越来越强，闭源模型也开放了微调接口，大家都有机会。如果 Manus 能积累更多数据，有更好的产品思路，就不一定会被淘汰。但 OpenAI 要做好 Deep Research 也需要大量的产品投入，所以很难断定 Manus 的未来走向，目前还无法预知。
Q：对于 Agent 产品的交互方式，以及 agent 产品和普通 ai 工具在人机交互方式的区别，有没有什么可以分享的心得？动态生成 agent，会是未来的一个方向吗？
李国豪：我觉得 agent 产品和普通 AI 产品在人机交互方面存在的差别，有一个很有意思的方向。许多传统 AI 工具需人主动提问、下达任务，更多是人主导。而 agent 产品或许能减少人的参与，更自主地完成任务，仅在特殊情况下需要人确认，如果能实现，人机交互方式将截然不同。
此外，不仅是人机交互，agent 与机器的交互也很有趣，和传统 AI 工具不同。例如微信、小红书目前是供人使用的，如果未来是给 agent 使用，会发生怎样的变化？这里可能存在人、机器和 agent 三者间的交互关系，有很多值得探索的地方，比如 agent 使用和人使用时的 UI 是否不同。
当下有很多人在做生成式 UI，这也是未来人机交互的一种方式，UI 不一定是固定的，动态生成 agent 是一个发展方向，我们也在做相关方案。
Q：Agent 系统能是否有潜力成为具身机器人的任务管理的技术底座？目前的系统还需要等待用户输出输入单一的任务来激活，未来能不能同时监控多个任务同时具备执行的能力？
李国豪：我认为 agent 系统在未来大有可为，而且这个趋势已在发生。我们也在做 agent 系统与机械结合的 multi-agent 系统工作，很多机构也在做类似探索，利用 agent 系统调用原子技能，实现 AI agent 与具身场景的融合，这肯定是未来方向。
第二个问题，但从工程层面看，让 agent 进行多次推理是可行的。比如借鉴 MapReduce 的方式，分配多个任务，再整合它们的记忆，我认为这不是大问题，具备可操作性。
非常看好 agent 用来做
AI for Science
Q：有什么维度或者准则可以判断一个 agent system 的好坏？
李国豪：当然，评判一个系统好坏的维度有很多，一是性能方面，目前有一些基准测试，比如这次 Manus 使用的 GAIA benchmark，还有像香港大学做的 OSWorld Benchmark 也被大家广泛采用，包括我们正在做的跨平台操控手机和电脑的 Crab Benchmark。除此之外，从效率角度来看，比如系统运行的速度、消耗的资源等方面，也是评估系统的重要维度。
Q：国内一些本土业务结合，比如电话反控、风控这类不被流行 benchmark 覆盖的领域，如果要用 agent 来做，该如何构建对应的 benchmark？有可参考的工作吗？
李国豪：如果使用 agent 进行电话反诈风控，首先要对案例标注是否是诈骗，以此开展强化学习或监督学习。构建专属 benchmark，关键在于保证采集数据的多样性与足够的数据量，这也是最基础的。传统方式是人工采集，但要注意避免数据偏差，比如不能只采集男性诈骗人员的通话数据，需了解真实世界数据分布来合理采集。
另一种方式是数据合成，基于已有数据合成更多数据，再进行标注与过滤。除了数据外，设计合理的评判指标对基准测试十分重要。agent 的指标和一般数据指标不同，除了最终是否完成任务，还需考量任务完成的进度，例如完成了百分之多少等方面的评估。
Q：如果是在 AI for Science 领域的话，agent 和通用 agent 的产品形态上会有很大的不一样吗？
李国豪：我非常看好 agent 用来做 AI for Science。 AI for Science 中的许多任务存在重复性，也涉及工具调用。但 AI for Science 与传统 AI 不一样的是，它往往速度较慢，经常需要与物理世界交互，比如进行物理、化学甚至生物实验，反馈周期可能好几天甚至一年。它们的交互形式、数据、时间维度及所需工具都因实验而异，形态自然不同。
我们之前做过自动化实验室的相关工作，例如自动寻找新化合物，这就需要 agent 操控机械臂完成药品选择、分发，同时对实验进行观测、分析，甚至开展强化学习，是个非常复杂的场景。
Q：对于资源极其有限的学术研究项目，基于 OWL 或 CAMEL 做 research 的时，应该优先聚焦和避开哪些方向？
李国豪：如果资源极其有限，我建议选择的研究方向最好与大厂或大型创业公司有所不同，可以关注一些他们不太在意或者尚未关注到的领域。我当初开展 camel 相关研究以及后续的一些研究时，也是基于同样的考虑。
在资源如此受限的情况下，我们做了什么呢？我们避开了 OpenAI 和 DeepMind 等公司正在做的事情，专注于他们暂时还不会去做的领域。这些大公司有自己的优先级，有些虽然重要但不在他们当前优先级范围内的事情，我觉得是可以考虑聚焦的方向。
比如，OpenAI 目前的首要任务可能是优化模型、做好 agent。那我们就关注 multi-agent，构建更大规模的系统。因为我们认为在短期内他们不会涉足这个领域，这并非他们的最高优先级。但同时，这也是一个非常重要的研究方向。大家都知道，AI 有五个不同级别的智能定义，第五级是组织层面能够完成的事情。我认为只有 multi-agent 系统才能实现组织层面的任务，multi-agent 系统无疑是未来的重要发展方向。既然大公司现在不太会去做，那对资源有限的团队来说，这就是一个很好的切入点。
