Manus 大火，不僅讓 Agent 成為了 2025 年上半年最受關注的 AI 領域，也讓一些復刻 Manus 的開源 Agent 項目獲得了更多開發者的關注。

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 輕易取代，那就說明該垂直領域的工作還不夠「垂直」，沒有解決這個領域最核心的痛點。

Founder Park 正在搭建開發者社群，邀請積極嘗試、測試新模型、新技術的開發者、創業者們加入，請掃碼詳細填寫你的產品/項目信息，通過審核后工作人員會拉你入群～

進群之后，你有機會得到：

• 高濃度的主流模型（如 DeepSeek 等）開發交流；

• 資源對接，與 API、云廠商、模型廠商直接交流反饋的機會；

• 好用、有趣的產品/案例，Founder Park 會主動做宣傳。

01OWL 的源起，以及和 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 只能使用固定工具。開源的優勢就在于你可以定制自己的工具，在自己的領域或應用場景中，將特有的工具加入進來，提高效率和穩定性。

02

從技術實現角度看 Manus

我挺喜歡 Manus 項目，雖然現在還沒嘗試過，但我覺得它意義重大，在近期的分享和朋友圈都提過。有句話形容得很貼切，說Manus 像把火，點燃了AIagent 這一波技術浪潮。

我們做底層技術研究兩年了，從首個基礎框架做到現在，得到的關注遠不及它。正因為 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 有很多值得借鑒的地方，對技術發展意義重大，并非像有些人說的那么不堪。

03

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介紹：

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，由使用者自行定義。

04

垂直領域 Agent 需要更深入、更專業

Q：AgenticAI目前有兩條看似相反的實現路徑，一條基于底層模型端到端的學習 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 產生擠壓，那就需要把垂直領域的工作做得更深入、更專業。

05

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 的方式，分配多個任務，再整合它們的記憶，我認為這不是大問題，具備可操作性。

06

非常看好 agent 用來做
AIfor Science

Q：有什么維度或者準則可以判斷一個 agent system 的好壞？

李國豪：當然，評判一個系統好壞的維度有很多，一是性能方面，目前有一些基準測試，比如這次 Manus 使用的 GAIA benchmark，還有像香港大學做的 OSWorld Benchmark 也被大家廣泛采用，包括我們正在做的跨平臺操控手機和電腦的 Crab Benchmark。除此之外，從效率角度來看，比如系統運行的速度、消耗的資源等方面，也是評估系統的重要維度。

Q：國內一些本土業務結合，比如電話反控、風控這類不被流行 benchmark 覆蓋的領域，如果要用 agent 來做，該如何構建對應的 benchmark？有可參考的工作嗎？

李國豪：如果使用 agent 進行電話反詐風控，首先要對案例標注是否是詐騙，以此開展強化學習或監督學習。構建專屬 benchmark，關鍵在于保證采集數據的多樣性與足夠的數據量，這也是最基礎的。傳統方式是人工采集，但要注意避免數據偏差，比如不能只采集男性詐騙人員的通話數據，需了解真實世界數據分布來合理采集。

另一種方式是數據合成，基于已有數據合成更多數據，再進行標注與過濾。除了數據外，設計合理的評判指標對基準測試十分重要。agent 的指標和一般數據指標不同，除了最終是否完成任務，還需考量任務完成的進度，例如完成了百分之多少等方面的評估。

Q：如果是在AIfor Science 領域的話，agent 和通用 agent 的產品形態上會有很大的不一樣嗎？

李國豪：我非常看好 agent 用來做AIfor 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 系統無疑是未來的重要發展方向。既然大公司現在不太會去做，那對資源有限的團隊來說，這就是一個很好的切入點。