目錄

一、引言

二、以「對話為中心」的ChatBot

三、以「交付為中心」的多智能體Agent

三、什么是智能體Agent

    1. 從Prompt到思維鏈

    2. ReAct架構

    3. Agent

    4. Manus：一個Agent典型案例

    5.大模型上下文協議（MCP）

四、智能體Agent實現的源碼剖析（OpenManus項目）

    1. 準備

    2. 代碼

五、總結

一、引言

從2022年12月份OpenAI發布ChatGPT產品至今已有2年多的時間，當大家已經習慣于在對話框中與AI交互，習慣于通過各種Prompt技巧讓AI更好的理解并回答我們的問題，似乎默認這就是一種比較好與AI的交互方式了。

然而，這就是我們期盼的與AI交互的形式嘛？這是一種高效的方式嘛？

顯然，這是不夠的。

我們期望的是：告訴AI我們想要的目標或者任務，AI能夠理解深度理解并分析我們的意圖、自動的進行任務的拆解、自動的尋找可以使用的工具、自動的進行結果數據的匯總過濾、自動的呈現符合任務的展示形式。同時在任務處理過程中，可以自己完成異常的檢測和修改。就如同一位優秀的同學，我們告訴他任務的目標，他可以自己尋找飛書文檔、搜索網絡知識、使用內部系統、自己編碼驗證方案可行性，并最終給一份好的解決方案。

二、以「對話為中心」的ChatBot

我們發送一條指令，AI被動的響應指令。即完成一輪人與AI的交互。

三、以「交付為中心」的多智能體Agent

我們發送一個任務，AI自動分析任務、調用可用的工具、分析結果、過濾數據并自動處理異常，最終呈現解決方案。

完成這樣的一個任務，需要多智能體Agent間的協作以及對常用工具的調用。那什么是智能體Agent呢？

四、什么是智能體Agent

從Prompt到思維鏈

隨著大模型的發展，Prompt工程已成為撬動大模型潛能的核心技術。即使我們普通用戶在與大模型的交互中，也通過角色定義（如"資深工程師"）或示例引導來優化輸出效果，但這類簡單提示往往難以突破模型固有的邏輯天花板——就像給賽車裝自行車輪胎，再怎么調整也難以突破速度極限。

但偶然間，人們發現了一個神奇的咒語：只需要告訴大模型，你的 think 要 step by step。研究者發現只要加了這個prompt，就能極為顯著地改善大模型做數學題的正確率。

大模型的數學與邏輯能力短板，是所有體驗過其對話功能的用戶都能直觀感受到的痛點。這一缺陷嚴重制約了大模型的商業化落地進程，畢竟沒有人敢輕易信任一個邏輯混亂的智能系統能輸出可靠的決策結果。于是，提升大模型數學能力，被所有做基礎模型的公司當作了第一目標。

研究者試圖通過強化思維鏈來突破這一瓶頸。一個直觀的思路是：讓模型像人類解題時在草稿紙上推演那樣，通過 "step by step" 的方式展開邏輯鏈條 —— 在這個過程中，包含假設、演繹、反思、糾錯等一系列思維活動。既然人類通過這種結構化的思考方式能夠有效解決數學問題，那么大模型是否也能通過類似機制實現能力躍遷？這一猜想推動著研究向縱深發展，最終形成了思維鏈技術的核心框架。這樣的觀念經過繼續鉆研，最終就構成了思維鏈，思維鏈是一個能以最小的代價，而非常顯著提升模型智力水平（邏輯能力、解題能力、代碼能力）的技術。

值得注意的是，2025 年春節期間引發廣泛關注的 DeepSeek 大模型，正是思維鏈技術的成功實踐典范。盡管 DeepSeek 并非首創者，但其通過創新性地融合混合專家（MoE）架構與強化學習技術，顯著提升了思維鏈推理的計算效率與性能表現。這種技術優化使得 DeepSeek 在保持高精度推理的同時，大幅降低了計算成本，最終實現了屠榜級表現。

ReAct架構

如果說思維鏈（COT）是給 AI 裝上了人類的 "草稿紙"，那么 ReAct 框架就是為它配備了 "雙手"—— 讓 AI 不僅能在腦子里推演，還能主動采取行動獲取信息。這種 "思考 + 行動" 的組合，正在把大模型從 "紙上談兵" 的理論家，變成能解決現實問題的實干家。

ReAct 的核心在于將推理（Reasoning）與行動（Action）緊密結合。當模型面對復雜問題時，會先像人類一樣拆解思考步驟，然后根據中間結果調用外部工具（如搜索引擎、數據庫、計算器）獲取實時數據，再把這些信息整合到后續推理中。

其實，實現一個ReAct很簡單，只需要構建Prompt+提供工具+循環執行即可，筆者在這里不進行詳細的介紹，只需要給一個Prompt例子，讀者就能理解：

盡可能最好地為用戶回答接下來的問題，你可以使用以下工具來輔助你：{tools} 使用以下格式：

- 問題：你需要回答的輸入問題

- 思考：你需要持續思考下一步采取什么行動 

- 行動：要采取的行動，應該是 [{tool_names}] 中的一個，以及該行動的輸入內容 

- 觀察：行動并觀測結果，并判斷結果是否合理 ...（這個思考 / 行動  / 觀察可以重復 N 次，直到你認為知道了最終答案 

- 最終答案：原始輸入問題的最終答案 

開始！ 

- 問題：{input}

Tools支持開發者自定義，比如給予LLM一個查詢天氣的接口、計算器接口等。

ReAct架構實現了一種"問題拆解-工具調用-結果整合"的閉環機制，使得開發者僅需通過定義工具集（如天氣API、計算器、知識圖譜接口）和設計任務引導詞，就能將大模型轉化為可執行多步驟決策的智能體。最終可以使大模型突破純文本推理的局限，真正具備了在動態場景中解決開放性問題的工程化能力。

Agent

Agent作為大模型技術的集大成者，通過整合思維鏈（CoT）的推理能力和ReAct框架的行動機制，構建了具備自主決策與執行能力的智能系統。其核心突破在于將“大腦”與“四肢”有機統一，標志著大模型從被動應答邁向主動干預現實的質變。

在架構上，Agent與ReAct差別不大，ReAct是Agent的核心實現范式之一，Agent進一步整合記憶存儲、多智能體協作等模塊，形成更完整的自主決策系統。下圖是一個簡單的Agent架構圖：

Agent處理流程

1-4步會循環進行，直到LLM認為問題已被回答。

1.規劃（Planning）：

• 定義：規劃是Agent的思維模型，負責拆解復雜任務為可執行的子任務，并評估執行策略。
• 實現方式：通過大模型提示工程（如ReAct、CoT推理模式）實現，使Agent能夠精準拆解任務，分步解決。

2.記憶（Memory）：

• 定義：記憶即信息存儲與回憶，包括短期記憶和長期記憶。
• 實現方式：短期記憶用于存儲會話上下文，支持多輪對話；長期記憶則存儲用戶特征、業務數據等，通常通過向量數據庫等技術實現快速存取。

3.工具（Tools）：

• 定義：工具是Agent感知環境、執行決策的輔助手段，如API調用、插件擴展等。
• 實現方式：通過接入外部工具（如API、插件）擴展Agent的能力，如ChatPDF解析文檔、Midjourney文生圖等。

4.行動（Action）：

• 定義：行動是Agent將規劃與記憶轉化為具體輸出的過程，包括與外部環境的互動或工具調用。
• 實現方式：Agent根據規劃與記憶執行具體行動，如智能客服回復、查詢天氣預報、AI機器人抓起物體等。

Manus：一個Agent典型案例

在讀完前一節關于智能體（Agent）的技術解析后，讀者也許會認為這類系統的工程實現并非難事，實際上也確實是這樣。近期爆火的 Agent 產品 Manus 便是典型案例。當用戶提出 "定制 7 天日本旅行計劃" 的需求時，Manus 能夠基于目標，自主進行網絡搜索并將信息整合，展現出高度擬人化的任務執行邏輯。

盡管 Manus 目前尚未向普通用戶開放，且采用邀請制注冊的封閉運營模式，但其通過官方演示視頻呈現的強大智能化表現，已在技術圈引發廣泛關注。值得關注的是，隨著Agent技術的熱度攀升，開源社區已迅速涌現出 OpenManus、OWL 等多個復刻項目。

因為Manus并非開源，我們很難了解其技術細節。但好在：

1. "Manus 的部分技術細節，包括其提示詞設計、運行機制等內容被網友通過非官方渠道披露，感興趣的讀者可自行查閱相關公開資料。
2. 我們可以了解一下大模型上下文協議（Model Context Protocol，MCP），這是 Anthropic (Claude) 主導發布的一個開放的、通用的、有共識的協議標準，雖然Manus不一定用了這個協議，但目前一些相關開源項目也是基于MCP的，本文會在下面介紹MCP。
3. 目前已有復刻的開源項目Openmanus，筆者會在接下來的章節剖析其源碼。

大模型上下文協議（MCP）

MCP是做什么的？

MCP（Model Context Protocol）作為一項開放協議，旨在為應用程序與大型語言模型（LLMs）之間的上下文交互提供標準化框架。其設計理念可類比為數字時代的 "USB-C 接口"—— 正如 USB-C 統一了設備與外設的連接標準，MCP 通過標準化的上下文交互接口，實現了 AI 模型與多樣化數據源、工具之間的無縫對接。

如下圖所示，圖中的MCP server都可以看成一個個工具(如搜索引擎、天氣查詢)，通過“接口”連接到MCP clients(大模型)上，大模型可以使用各種MCP server來更好地處理用戶的問題。

此外，下游工具的開發者也可以更好的開發其工具，目前在MCP官網即可了解其各種編程語言的SDK和相關概念。

MCP架構

MCP 的核心采用客戶端-服務器架構，其中 host 可以連接到多個服務器，讀者簡單看看即可：

• MCP 主機（MCP Hosts）：指需要通過 MCP 協議獲取數據的應用程序，涵蓋 AI 開發工具（如 Claude Desktop）、集成開發環境（IDEs）等智能應用場景。
• MCP 客戶端（MCP Clients）：作為協議的執行者，每個客戶端與對應的 MCP 服務器建立一對一的專屬連接，負責協議層面的通信交互。
• MCP 服務器（MCP Servers）：輕量化的功能載體，通過標準化的 Model Context Protocol 對外開放特定能力，可視為連接模型與工具的智能橋梁。
• 本地化數據源（Local Data Sources）：包括服務器可安全訪問的本地文件系統、數據庫及專有服務，構成數據交互的近端生態。
• 遠程服務（Remote Services）：通過互聯網連接的外部系統，例如各類 API 接口服務，拓展了模型的能力邊界。

為什么要用MCP？

從技術演進視角看，MCP 的誕生是提示工程（Prompt Engineering）發展的必然產物。研究表明，結構化的上下文信息能顯著提升大模型的任務表現。在傳統提示工程中，我們往往需要人工從數據庫篩選信息或通過工具檢索相關內容，再手動將這些信息注入提示詞。然而，隨著復雜任務場景的增多，這種手工注入信息的操作變得愈發繁瑣且低效。

為解決這一痛點，主流大模型平臺（如 OpenAI、Google）先后引入了函數調用（Function Call）機制。該機制允許模型在推理過程中主動調用預定義函數獲取數據或執行操作，極大提升了自動化水平。然而，函數調用機制存在顯著局限性：其一，不同平臺的函數調用 API 存在較大差異，例如 OpenAI 與 Google 的實現方式互不兼容，開發者在切換模型時需重新編寫代碼，徒增適配成本；其二，該機制在安全性、交互性及復雜場景的擴展性方面仍存在優化空間。

在此背景下，MCP 協議通過標準化的上下文交互接口，為大模型構建了更具普適性的工具調用框架。它不僅解耦了模型與工具的依賴關系，還通過統一的協議規范解決了跨平臺兼容性問題。更重要的是，MCP 將上下文管理提升到系統架構層面，為大模型在復雜業務場景中的深度應用提供了可擴展的技術底座。這種從碎片化的提示工程到體系化的上下文協議的演進，標志著大模型應用正在向更高效、更規范的方向邁進。

四、智能體Agent實現的源碼剖析（OpenManus項目）

OpenManus 是一個基于 MCP 協議的開源智能體實現項目，旨在通過標準化的上下文協議實現大模型與工具的高效協同。當前項目仍處于快速迭代階段，本文以其 2025 年 3 月 12 日的版本為分析對象。選擇該項目的原因如下：

• 團隊背景與代碼質量：項目作者來自MetaGPT，具備深厚的工程經驗，代碼結構清晰且注釋完善，兼顧了技術實現與可讀性。
• 部署便捷性：只需通過虛擬環境安裝依賴并配置大模型 API Key（如 OpenAI 的 API 密鑰），即可快速啟動，降低了技術門檻。
• 技術前沿性：項目緊跟大模型技術發展，且目前仍在不斷迭代的過程中。

在經過前面對相關概念的討論，我們可以得知實現Agent有幾個關鍵的點，讀者可以帶著問題在項目中尋找答案：

• Prompt：其結構化的Prompt是什么樣的？通過Prompt可以對其架構有一個初步認識。
• OpenManus：怎么通過大模型思考和處理問題？
• 工具相關：怎么進行工具注冊、工具管理的？工具執行邏輯是什么的？

準備

項目地址：https://github.com/mannaandpoem/OpenManus/tree/main

構建環境

創建一個pythnotallow=3.12的虛擬環境

• 筆者測試了一下，非3.12版本會有一個package不兼容。
• 可以用conda或python內置的uv，項目文檔提供了詳細的指令。

安裝playwright

• 如果第一次使用，需要安裝playwright。

playwright install
## 或者
python -m playwright install
## 以上命令會安裝所有瀏覽器，如果只需要安裝一個瀏覽器比如firefox
python -m playwright install firefox

配置大模型API Key

• 可以用DeepSeek或通義千問的API Key，其中通義有免費額度，DeepSeek雖然收費但價格便宜，測試一次使用約1000token,成本不到0.01元。
• 根據項目文檔配置cofig.yaml即可，但項目調用大模型是使用基礎的OpenAI API，如果使用其他大模型，可能需要基于對應的官方文檔小改一下。

代碼

OpenManus客戶端

Python OpenManus/main.py即可在終端運行OpenManus，讀者也可以嘗試其Web版本。

• 具體會調用20行代碼，執行Manus類的方法run()。

進入OpenManus/app/agent/manus.py查看Manus類，可以發現它繼承了ToolCallAgent類，再進入會發現又是繼承，有點復雜，這里我畫一張關系圖。

• act()執行時使用execute_tools()進行具體的工具執行。
• 總體來說，Manus類定義了Prompt和可使用的工具。
• Base類定義了run()，在run()中會循環執行ReAct類的方法step()，直到Finish或達到max_step。
• step()類會順序執行ToolCallAgent類的think()和act()。

當然，這里只羅列了重要的組件和方法，一些方法沒有畫在圖中。

Prompt

一般來說，輸入給LLM的prompt分為兩種：1）系統 prompt，用于定義模型的角色定位和行為規則；2）用戶 prompt(OpenManus稱為Next Step Prompt)，用于傳達具體的任務指令或信息需求。

在OpenManus/app/prompt/manus.py中即可看到Manus的Prompt，這里展示一下中文版，讀者基于此可對OpenManus架構有一個初步認識：

• 系統Prompt（SYSTEM_PROMPT）：“你是 OpenManus，一個全能的人工智能助手，旨在解決用戶提出的任何任務。你擁有各種可使用的工具，能調用這些工具高效地完成復雜的請求。無論是編程、信息檢索、文件處理還是網頁瀏覽，你都能應對自如。”
• 下一步Prompt（NEXT_STEP_PROMPT）：“你可以使用 PythonExecute 與計算機進行交互，通過 FileSaver 保存重要的內容和信息文件，使用 BrowserUseTool 打開瀏覽器，并使用 GoogleSearch 檢索信息。根據用戶的需求，主動選擇最合適的工具或工具組合。對于復雜的任務，你可以將問題分解，逐步使用不同的工具來解決它。在使用完每個工具后，清晰地解釋執行結果并給出下一步的建議。

當然，在實際執行時會對prompt有進一步優化，不過核心的系統定位與任務指導原則是不會改變的。

Manus類

我們先看一下OpenManus擁有的工具，工具也支持自定義，會在后文進行介紹。

• PythonExecute：執行 Python 代碼以與計算機系統交互、進行數據處理、自動化任務等等。
• FileSaver：在本地保存文件，例如 txt、py、html 等文件。
• BrowserUseTool：打開、瀏覽并使用網絡瀏覽器。如果你打開一個本地 HTML 文件，必須提供該文件的絕對路徑。
• GoogleSearch：執行網絡信息檢索。
• Terminate：如果LLM認為回答完畢，會調用這個工具終止循環。

Base類

run()

• 首先，輸入的request就是用戶輸入的提問。

狀態管理

• 執行時首先檢查代理的當前狀態是否為 IDLE?（空閑狀態）。如果不是空閑狀態，會拋出 RuntimeError 異常，因為只有在空閑狀態下才能啟動代理的執行。

• 當進入循環時前，使用 state_context?上下文管理器將代理的狀態臨時切換到 RUNNING?（運行狀態）。在上下文管理器中執行的代碼塊會在進入時將狀態切換為指定狀態，在退出時恢復到之前的狀態。如果在執行過程中發生異常，會將狀態切換為 ERROR。

Memory管理

我們調用大模型的API，本質是向大模型提供方發http請求，http請求是無狀態的。

• 也就是說，服務端不會保留任何會話信息。對于每次都完成一個獨立的任務，無狀態是沒有任何問題的。但對持續聊天來說，就會出現對之前會話一無所知的情況。

所以為了讓大模型持續與用戶的對話，一種常見的解決方案就是把聊天歷史告訴大模型。

• 因此，在OpenManus中會進行Memory的管理。

• 用戶提供的 request? 參數，調用 update_memory 方法將該請求作為用戶消息添加到代理的Memory中。
• 除了這個函數，Manus也在進行think()、act()時也會更新Memory，同時Memory容量也不是無限大的，容量滿時需要刪除老的Message。

主循環

agent本質就是循環執行。

• step實現參考react step。
• 循環結束條件：max_steps或者FINISHED狀態。
• 每次執行一個step并獲得result——step_result = await self.step()。
• is_stuck? 方法用于檢查代理是否陷入了循環（即是否出現了重復的響應）。如果是，則調用 handle_stuck_state 方法處理這種情況，例如添加一個提示來改變策略。

ReAct

step()

• 這里的邏輯很簡單。

ToolcallAgent

Think()

• 輸入：不需要輸入，因為用戶的question是被存放在Memory中。
• 輸出：一個bool類型，當內部LLM判斷需要act()時，為True，否則為Fasle。

詢問LLM

• 55行的代碼用于調用LLM的API接口，獲取回復。

對應到OpenManus/app/llm.py 233行附近，這里就是基于OpenAI提供的API接口進行對話，具體的參數可參考相應官方文檔。

• 這里會將之前定義的下一步Prompt發給LLM，LLM會根據提供的工具列表，判斷是否需要且調用的是哪個工具，當然也可能是：1）不需要工具只進行回復 2）調用Terminate工具結束會話。

下圖是一次返回response結果。

• 輸入的question是“計算Kobe Bryant的BMI？”，LLM先分析出了要通過瀏覽器查詢資料，因此要use the BrowserUseTool。
• 根據傳入的工具類型等信息，LLM自動構建了執行工具需要用的tool_name、action等參數。

ChatCompletionMessage(
    cnotallow="It seems there was an issue with retrieving the information about Kobe Bryant's height and weight through a Google search. To calculate Kobe Bryant's BMI, we need his height and weight. Let's try to find this information by opening a browser and visiting a reliable source. I will use the BrowserUseTool to navigate to a website that provides details about Kobe Bryant's height and weight. Let's proceed with this approach.", 
    refusal=None, 
    role='assistant', 
    annotatinotallow=None, 
    audio=None, 
    function_call=None, 
    tool_calls=[
        ChatCompletionMessageToolCall(
            id='call_aez57ImfIEZrqjZdcW9sFNEJ',
            functinotallow=Function(
            arguments='{
                "action":"navigate",
                "url":"https://www.biography.com/athlete/kobe-bryant"
                }', 
            name='browser_use'), 
            type='function')]
)

think后續邏輯

• think()后續的邏輯比較簡單，主要是更新memory(memory存儲單位是message)，最后在100行附近的邏輯，基于self.tool_choices等參數的設置和LLM返回的工具列表，輸出bool類型結果。
• 同時，需要被調用的工具會被記錄到self.tool_calls這個列表中，后續的act()會執行對應的工具。

Act()

• 輸入：同think()，不需要輸入。
• 輸出：results，根據工具結果構建的一個字符串。

• 這個函數比較簡單，主要是調用execute_tool()函數。

Execute_tool()

該函數會調用Tool類提供的接口execute()。

• Tool類接口會在后面介紹。

同時，對于預設定的special tool，會self._handle_special_tool(name=name, result=result)進行特殊處理。

• 當前的special tool只有一個Terminate工具，特殊處理就是設置Agent的狀態為AgentState.FINISHED，結束對話。

工具相關

我們在之前介紹了MCP相關的概念，如下圖所示：

事實上，OpenManus也是基于MCP的，OpenManus的tool相當于MCP server，根據MCP協議，我們只需要定義tool類支持的方法和參數等，每次注冊一個新工具，根據父類override一個子類即可。

那我們首先要了解父類都定義了什么參數和方法，也就是OpenManus/app/tool/base.py定義的Basetool類。

Base Tool

可以看出，代碼很簡單，每個tool包含的參數為:name、description(提供給LLM看的，對工具的介紹)、parameters(執行工具時要用的參數)。

同時，一個tool支持的方法有execute()和to_param()。

• execute()用于執行具體的邏輯，每個子類需要override這個方法。
• to_param()將工具調用的結果結構化輸出。

當然，這里還有一個python關鍵字__call__，這個關鍵字很簡單，定義了__call__，該類的實例對象可以像函數一樣被調用。

工具JSON

可以根據OpenManus預定義的工具json簡單了解一下，每個工具執行時需要的參數。

[
  {
    "type": "function",
    "function": {
      "name": "python_execute",
      "description": "Executes Python code string. Note: Only print outputs are visible, function return values are not captured. Use print statements to see results.",
      "parameters": {
        "type": "object",
        "properties": {
          "code": {
            "type": "string",
            "description": "The Python code to execute."
          }
        },
        "required": ["code"]
      }
    }
  },
  {
    "type": "function",
    "function": {
      "name": "google_search",
      "description": "Perform a Google search and return a list of relevant links.\nUse this tool when you need to find information on the web, get up-to-date data, or research specific topics.\nThe tool returns a list of URLs that match the search query.\n",
      "parameters": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string",
            "description": "(required) The search query to submit to Google."
          },
          "num_results": {
            "type": "integer",
            "description": "(optional) The number of search results to return. Default is 10.",
            "default": 10
          }
        },
        "required": ["query"]
      }
    }
]

工具示例——google_search

OpenManus項目在OpenManus/app/tool中定義了bash工具、瀏覽器工具、谷歌搜索工具等，這里簡單看一下谷歌搜索工具。

當然，國內可能比較難使用谷歌搜索，OpenManus社區也有大佬提供了baidu、bing等搜索引擎工具。

可以看出，代碼很簡單，主要做了兩件事。

• 定義工具參數：name、description、parameters。
• 定義execute：基于googlesearch庫提供的函數進行搜索并返回。

五、總結

OpenManus的代碼介紹到這里，主要是介紹一下核心代碼，同時，原作者寫了planning部分的代碼但暫時沒有應用到項目中，筆者也沒有介紹。如果想對該項目有更進一步的了解，請大家查看github上提供的源碼。而且，作者還是非常積極的，每天會有十幾個commit。

同時，讀者可以簡單本地部署玩一下OpenManus，通過幾個prompt，就可以知道該項目還是停留在“玩具階段”，比如筆者測試了一下，當詢問“計算一下科比的BMI？”，OpenManus可以很準確的實現谷歌搜索——瀏覽器訪問——python計算這個過程。但如果詢問“計算科比、梅西的BMI并排序？”，無論我改寫了幾次prompt，OpenManus都沒有給我滿意的回答。

此外，無論是在工具參數信息、還是prompt、memory管理中，都可以看到agent應用大模型token消耗量巨大，即使我們不考慮token成本，但大模型的上下文仍然是有限的，這種資源消耗也會直接導致模型在處理多步驟任務時面臨信息截斷的風險 —— 早期的關鍵信息可能因上下文溢出而被丟棄，進而引發推理鏈條的斷裂。更值得警惕的是，當模型試圖在有限的上下文中 “腦補” 缺失的信息時，往往會產生與事實不符的幻覺。

鑒于此，盡管 OpenManus 展示出了利用工具鏈解決復雜問題的潛力，不過距離成為一個實用、高效且穩定的生產級人工智能助手仍有很長的路要走。未來，開發者們或許需要在優化工具使用邏輯、提升多任務處理能力、降低大模型 token 消耗以及增強上下文管理等方面進行深入探索與改進。同時，對于普通用戶而言，在體驗這類項目時，也應該保持理性和客觀的態度，既看到其創新性和趣味性，也認識到其當前存在的局限性。希望在技術的不斷迭代和完善下，OpenManus 以及類似的項目能夠早日突破現有的瓶頸，真正為人們的工作和生活帶來實質性的幫助。

本文轉載自??得物技術??，作者：漢堡