阿里妹導讀
文章結合了理論分析與實踐案例，旨在幫助讀者系統地認識AI Agent的核心要素、設計模式以及未來發展方向。
背景
前一階段Manus大火，被宣傳為全球首款“真正意義上的通用AI Agent”，其核心能力就是基於LLM的自主任務分解與執行，根據官方測試資料，Manus 在 GAIA 基準測試中表現超越 OpenAI 同類產品，且完成任務的成本更低。雖然之後技術大咖們對齊技術深度表示不屑（嫉妒~）， 認為其缺乏底層創新，依賴現有工具鏈組合。 但其工程化整合能力仍具有較高的價值，另外還有兩個明顯的特點，值得學習。
-
透過工程化能力（任務排程、工具整合）將 AI Agent 從概念落地為大眾產品，滿足了大家對AI “自主解決問題”的深層期待。
-
準確抓住行業熱點，成為2025年AI領域的現象級話題，精準抓住“國產AI”標籤與行業熱點，邀請碼機制（限量發放）製造稀缺性，創始人透過簡潔演示快速傳遞產品價值。
隨後MetaGPT團隊推出了OpenManus，宣稱是Manus的開源復刻版，且在3小時內完成基礎開發（看程式碼提交記錄確實卷）。 OpenManus是一個簡潔的實現方案，還在快速迭代中， 趁著專案還沒有熟透，克隆下來學習了下。對比LangChain，程式碼結構還算比較容易理解，是一個很好的學習專案，也比較容易做二次開發。 週末花了兩天時間基於OpenManus做了二次開發，希望構建屬於自己的“Manus”，在這過程中對Agent有了更明確的實踐認知，在這裡分享下這個過程。
為了讓讀者對Agent能夠有系統的認識，同時也可以對Agent的認識完成一次祛魅的過程。 本篇文章結構為：
1）認識， 對AI Agent相關的一些組成進行原理性解釋
2）設計，基於OpenManus構建自己的MyManus，落地和驗證認識中的一些概念和原理
3）實驗，基於MyManus進行驗證，對當前的Agent存在的問題有個直觀的感受。
4）改進，結合前面的實驗以及Agent當下的問題，探討未來的方向和改進方案。
認識
結合Agent相關的幾篇關鍵文章和論文，梳理下基於LLM的AI Agent的設計模式以及一些原理性的概念。ATA上關於LLM和Agent的原理性的優質文章太多，這裡主要涉及Manus或OpenManus用到的部分。
AI Agent正在重新定義軟體服務
你只需要告訴我你要什麼，不要告訴我怎麼做。
AI Agent將使軟體架構的正規化從面向過程遷移到面向目標，就像傳統面向過程的工作流和K8S的宣告式設計模式一樣， 當然這兩種解決的問題是不一樣的， K8s透過定義期望狀態而非具體步驟來管理叢集，降低叢集狀態管理的複雜度，確保叢集的穩定性和容錯性。 Agent之前，傳統的軟體架構，只能解決有限範圍的任務， 而基於Agent的架構，可以解決無限域的任務，真正意義上的性化服務。
ProAgent: From Robotic Process Automation to Agentic Process Automation
我們可以從Manus的官方網站看到，Manus宣稱可以做如下的事情，並提供了相當豐富的案例。
-
資料分析：比如分析店鋪銷售資料，制定改進策略等。
-
教育：互動課程，學習資源收集，宇宙探索等
-
生活：保險策略對比，租賃合同分析，旅行計劃等
-
效率：合同審查，簡歷篩選，網站SEO最佳化等。
-
研究：財報分析，政策研究
AI Agent的核心要素
不同的機構或團隊， 對Agent的架構模組的劃分略有差異，但基本上包含了：感知，記憶，規劃，行動四個核心的要素。 此外，部分團隊還涉及定義（管理 Agent 角色特性）、學習（預訓練、小樣本學習）、認知與意識（思考、整體認知）等特色模組。
*內容來源：華泰證券研究所
Lilian Weng（翁荔）LLM Powered Autonomous Agents這篇部落格被廣泛認為是 “AI Agent領域最權威的結構化綜述之一” ，為開發者提供了技術框架參考， 大家應該對文中的圖已經很熟悉了， 作者將 AI Agent 定義為 “規劃 + 記憶 + 工具呼叫” 的組合，強調LLM作為系統的核心控制器。
-
規劃（Planning） ：任務分解、子任務生成及自我反思
-
記憶（Memory） ：長期記憶儲存與上下文管理，用於處理複雜任務
-
工具使用（Tool Usage） ：透過API或外部工具增強Agent的能力（如搜尋、檔案操作，程式碼執行等）
設計
接下來圍繞Agent幾個核心要素進行設計，會先簡單介紹一些基本的原理，然後基於OpenManus做二次設計或者展示其原來的實現。
LLM
在這之前概括下LLM的一些基本的原理，關於LLM的原理性文章已經很多了，這裡只對LLM的推理原理做個簡單回顧。
當下的LLM的核心依然是基於神經網路， 相比傳統的神經網路CNN/RNN等，Transformer架構透過自注意力機制允許模型直接計算任意兩個位置之間的關係，從而更高效捕捉長距離依賴，使得LLM有更強大的多層疊加能力。Transformer的平行計算能力（如自注意力的矩陣運算）同時加速了訓練速度，支援更大的模型規模。另外透過多層非線性啟用函式（如 ReLU、GeLU）可學習更加複雜模式， 隨著引數規模和訓練資料增加，LLM 會突現傳統神經網路難以實現的能力（如邏輯推理、程式碼生成），LLM具備了湧現能力！（ 也許這就是量變產生了質變吧）
LLM的推理簡單理解為是一個 “模式匹配 + 機率計算” 的過程，透過 Transformer 架構和自迴歸生成，基於海量文字學習到的統計規律，逐步生成符合語言習慣的輸出。其效果依賴於訓練資料的質量、模型規模以及生成策略的選擇。 每一步生成都依賴於已生成的上下文，即透過已知的前序詞預測下一個詞，當前LLM具備上下文學習（In-Context Learning）能力，LLM透過Prompt中提供的示例或指令，無需引數更新即可適應新任務，依然是在於利用模型的模式匹配能力和統計規律，Transformer 架構中，Prompt的token位置靠前，權重更高，對後續生成的影響更大。
LLM的湧現能力使其具備複雜任務處理能力，但同時也因訓練資料的噪聲和統計生成特性，容易產生幻覺。RAG透過引入外部知識減少幻覺，SFT微調透過高質量資料最佳化輸出，Agent透過工具呼叫增強互動能力。這些方法可在一定程度上緩解幻覺，增強可解釋性， 但可解釋性仍受限於LLM的黑箱特性。Agent設計中，Prompt是核心元件之一，所有的設計都是圍繞構建和管理Prompt，需結合工具呼叫、記憶管理等模組設計。為適應不同任務，Prompt需精細化設計並管理多個版本。
Memory
前面瞭解到，LLM本質上就是一個具有數十億到千億級別引數的無狀態函式， 比如可以這樣：
LLM自身不具備主動記憶功能，但可透過外部技術（如提示工程、記憶模組）模擬記憶效果，以增強任務表現和互動連貫性。所以別想著LLM會有人類的情感啦，LLM的“連貫性”是機率驅動的，而非真正的意圖或情感。
LLM就像一個失憶的絕世高手一樣，雖然沒有記憶，但可以武功還在， LLM回覆完全基於輸入的提示（prompt）和訓練資料中的模式，通常我們所說的記憶是指的是使用者輸入提示， 分為短期記憶和長期記憶。
-
LLM的“短期記憶”通常依賴於其上下文視窗（最大Token限制），透過在輸入中包含當前對話或任務的相關資訊來維持連貫性。LLM的一些生產引數比如Temperature，Top-P可以影響其基於上下文生成文字內容。 Temperature主要是影響生成的確定性， 是透過控制Temperature實現生成內容的準確性與創造性二者之間的權衡。Top-P主要是發散程度，在聚焦和多樣性之間的平衡。
-
長期記憶依賴於外部元件，雖然LLM的預訓練引數“儲存”了知識，通常已經過時，特定領域的知識，需外部技術（如RAG）補充長期依賴關係。短期記憶也可以轉變為長期記憶， 這個對Agent的自主進化很有幫助。
我們設計一個簡單的短期記憶模組， 記錄推理和外部感知的結果資訊， 每次呼叫LLM時都會帶上（受限於LLM的最大Token）, 這樣LLM就會在每次推理時“記住”之前的推理過程，以及外部工具感知的結論。相當於：每次你問問題，都要講一遍前面的交流內容。 定義Memory類，記錄每次的Message內容。
classMemory(BaseModel): messages: List[Message] = Field(default_factory=list) max_messages: int = Field(default=100)以下是Memory內容例子
{"messages": [ {"role": "user","content": "\n CURRENT PLAN STATUS:\n Plan: QuickSort Implementation Plan (ID: plan_1742277313)\n==========================================================\n\nSteps:\n1. [→] {'step_name': 'Research and understand the QuickSort algorithm', 'status': 'in_progress', 'notes': ''}\n2. ...","tool_calls": null,"name": null,"tool_call_id": null }, {"role": "user","content": "You can interact with the computer using PythonExecute, save important content and information files through FileSaver, open browsers with BrowserUseTool, and retrieve information using GoogleSearch.\n\nPythonExecute: ...","tool_calls": null,"name": null,"tool_call_id": null }, {"role": "assistant","content": "","tool_calls": [ {"id": "call_294a4ff7396f4c91813990","type": "function","function": {"name": "google_search","arguments": "{\"query\": \"QuickSort algorithm explained\"}" } } ],"name": null,"tool_call_id": null }, {"role": "tool","content": "Observed output of cmd `google_search` executed:\n['https://www.w3schools.com/dsa/dsa_algo_quicksort.php']...","tool_calls": null,"name": "google_search","tool_call_id": "call_294a4ff7396f4c91813990" }, {"role": "user","content": "You can interact with the computer using PythonExecute...","tool_calls": null,"name": null,"tool_call_id": null }, {"role": "assistant","content": "I have researched the QuickSort algorithm using a Google search. Here are some resources that can help us understand how it works...","tool_calls": null,"name": null,"tool_call_id": null } ]}Tools
人類創造、修改和利用外部物體來做超出人類身體和認知極限的事情，為 LLM 配備外部工具可以顯著擴充套件模型功能和應用場景。
Agent的工具呼叫，實際上是藉助LLM的能力， LLM需要先理解工具的功能和引數格式。
Tool Learning with Large Language Models: A Survey
上圖可以簡單概括為：
1. 你有一系列工具，同時有比較詳細的說明書， 你拿著說明書找LLM問一個LLM自身推理無法（準確）完成的問題， 比如：今天幾號，天氣怎麼樣， 當前資料庫內容是什麼， 這些預訓練的LLM是無法感知到的， 需要藉助外部工具。
2. LLM會從你的工具說明書列表中選工具，準確地告訴你你應該用哪個工具，同時把輸入引數也給你（基於說明書描述）
3. 你拿到後呼叫工具，獲取感知資訊， 然後再把結果資訊給到LLM。
4. LLM判斷輸出結果，並繼續回答你之前的問題。
舉一個基於LangChain的簡單例子， 加了些HTTP請求埋點， 方便跟蹤LangChain與LLM的IO互動。
import osimport httpxfrom dotenv import load_dotenvload_dotenv('../.env.production')os.environ["OPENAI_API_KEY"] = os.getenv("DASHSCOPE_API_KEY")os.environ["OPENAI_API_BASE"] = os.getenv("DASHSCOPE_API_BASE_URL")print(os.getenv("DASHSCOPE_API_BASE_URL"))import jsonimport loggingfrom langchain_core.tools import toolfrom langgraph.prebuilt import create_react_agentfrom langchain_openai import ChatOpenAIlogging.basicConfig(level=logging.INFO)logger = logging.getLogger("httpx")logger.setLevel(logging.INFO)defstring_length(text: str) -> int:"""Calculate text length"""returnlen(text)defprint_request(request, *args, **kwargs): logger.info(f"HTTP Request: {request.method}{request.url}") logger.info(f"Request Headers: {request.headers}") logger.info(json.dumps(json.loads(request.content),indent=1))defprint_response(response, *args, **kwargs): logger.info(f"HTTP Response: {response.status_code}{response.reason_phrase}") logger.info(f"Response Headers: {response.headers}") response.read() logger.info(json.dumps(json.loads(response.text),indent=1))custom_client = httpx.Client( base_url=os.getenv("DASHSCOPE_API_BASE_URL"), headers={"X-Custom-Header": "value"}, event_hooks={"request": [print_request],"response": [print_response] })llm = ChatOpenAI(model_name="qwen-max-latest", verbose=True, http_client=custom_client )agent = create_react_agent(llm, [string_length],)response = agent.invoke({"messages": [("human", "How long is 'Hello World'")]},config={"callbacks": []})# 列印輸出for message in response["messages"]: message.pretty_print(){"messages": [ {"content": "How long is 'Hello World'","role": "user" } ],"model": "qwen-max-latest","stream": false,"tools": [ {"type": "function","function": {"name": "string_length","description": "Calculate text length","parameters": {"properties": {"text": {"type": "string" } },"required": ["text" ],"type": "object" } } } ]}{"choices": [ {"message": {"content": "","role": "assistant","tool_calls": [ {"function": {"name": "string_length","arguments": "{\"text\": \"Hello World\"}" },"index": 0,"id": "call_816c14bce4124280b61eb3","type": "function" } ] },"finish_reason": "tool_calls","index": 0,"logprobs": null } ],"object": "chat.completion","usage": {"prompt_tokens": 162,"completion_tokens": 18,"total_tokens": 180 },"created": 1742270364,"system_fingerprint": null,"model": "qwen-max-latest","id": "chatcmpl-18a82215-d19c-92ff-8bb1-7d0684f4abac"}"messages": [ {"content": "How long is 'Hello World'","role": "user" }, {"content": null,"role": "assistant","tool_calls": [ {"type": "function","id": "call_816c14bce4124280b61eb3","function": {"name": "string_length","arguments": "{\"text\": \"Hello World\"}" } } ] }, {"content": "11","role": "tool","tool_call_id": "call_816c14bce4124280b61eb3" } ],"model": "qwen-max-latest","stream": false,"tools": [ {"type": "function","function": {"name": "string_length","description": "Calculate text length","parameters": {"properties": {"text": {"type": "string" } },"required": ["text" ],"type": "object" } } } ]}"choices": [ {"message": {"content": "The length of the text 'Hello World' is 11 characters.","role": "assistant" },"finish_reason": "stop","index": 0,"logprobs": null } ],"object": "chat.completion","usage": {"prompt_tokens": 191,"completion_tokens": 16,"total_tokens": 207 },"created": 1742270365,"system_fingerprint": null,"model": "qwen-max-latest","id": "chatcmpl-1452e622-cf30-9cf8-9971-4530065952f6"}Planning
Lilian Weng博文裡Planning包含四個子模組，Reflection（反思）、Self-critics（自我批評）、Chain of thoughts（思維鏈）、Subgoal decomposition（子目標分解）， Planning將任務分解為可執行的步驟，並根據反饋不斷最佳化計劃。例如，透過Subgoal decomposition將大任務拆解為小任務，透過Reflection評估結果並調整策略。
我們可以透過Reason + Act（ReAct）和Plan-and-Solve（PS）來初步實現Agent的Planning能力。還有一些其他的模式。 比如ToT 模式（ 提示詞：“生成3種不同預算方案，總預算不超過10萬元，並列出每個方案的子任務”）， 基於角色的多Agent（MetaGPT）
Reason + Act推理-行動-反饋
ReAct透過LLM交替執行推理和行動，增強了推理和外界感知（透過行動獲得）之間的協同作用：推理幫助模型推斷、跟蹤和更新行動計劃，以及處理異常，而行動則允許它與外部資源（如知識庫或環境）互動，以獲取額外資訊。
ReAct: Synergizing Reasoning and Acting in Language Models
設計ReActAgent流程， 如下圖，實現重複的Thought- Action-Observation
退出機制有2種方式，一種是當超過最大步數， 另一是當LLM提示要呼叫一個終止工具時，退出迴圈。
終止工具描述為：When you have finished all the tasks, call this tool to end the work。
設計ReAct抽象類，由主體的Agent繼承， 包含llm和memory，同時有think和act兩個階段的操作，think透過呼叫LLM進行推理， act主要是呼叫工具獲取額外的資訊。 透過step串聯， step由Agent重複呼叫，每次都會透過LLM的推理判斷是否需要呼叫工具。
classReActAgent(BaseModel, ABC): name: str = Field(..., description="Unique name of the agent") description: Optional[str] = Field(None, description="Optional agent description")# Prompts system_prompt: Optional[str] = Field(None, description="System-level instruction prompt" ) next_step_prompt: Optional[str] = Field(None, description="Prompt for determining next action" )# Dependencies llm: LLM = Field(default_factory=LLM, description="Language model instance") memory: Memory = Field(default_factory=Memory, description="Agent's memory store") @abstractmethodasyncdefthink(self) -> bool:"""Process current state and decide next action""" @abstractmethodasyncdefact(self) -> str:"""Execute decided actions"""asyncdefstep(self) -> str:"""Execute a single step: think and act. Thought: ... Action: ... Observation: ... ... (Repeated many times) """ should_act = await self.think()# 判斷是否使用工具 ifnot should_act:return"Thinking complete - no action needed"returnawait self.act()Plan-and-Solve
Chain-of-Thought（CoT）使LLMs能夠明確地生成推理步驟並提高它們在推理任務中的準確性。比如Zero-short-CoT將目標問題陳述結合"讓我們逐步思考"這樣的提示詞， 作為LLM的輸入。這是一種隱式生成推理鏈，具有一定的模糊性，存在語義理解錯誤， 無法生成合理的計劃等問題
Plan-and-Solve是一種改進的CoT提示方法 ，透過顯式分解任務為子目標並分步執行，提升複雜任務的推理能力。Plan-and-Solve將傳統的“黑箱”推理操作，進一步轉化為結構化流程，使得Agent的可解釋性增強， 而且還可以動態調整和反思。 是Agent實現Planning能力的很好的技術支撐。
Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models
參考Plan-and-Solve論文，設計一個Planner
Agent
我們完成了Agent的Memory，Tools，Planning的核心模組，這裡還差一個LLM模型呼叫， 目前各個雲廠商或者模型部署工具Ollama，vLLM之類的都相容OpenAI的API介面， 某種程度上算是統一了~。
現在需要把這幾個組裝起來。文章開頭提到了， OpenManus是個好的學習專案， 所以整體實現也是基於（抄）OpenManus實現的，暫且命名為MyManus！為了便於加深理解，實驗以及後續的擴充套件， 做了如下改動。
-
簡化了Tools，ReActAgent，Planning之間的依賴關係，但完全相容OpenManus的工具。
-
進一步簡化了Planning實現， 去掉了多個Plan的排程邏輯，暫時去掉了多Agent支援，多Agent後續還會加進來。OpenManus的Agent機制比較簡單， 就如下圖描述，由Planning根據每一步計劃的型別選擇用哪個Agent，當前程式碼裡面目前只有一個主Agent，暫時無用。 （最新的OpenManus把PlanningAgent去掉了， Planning放到了flow裡面）
-
新增EventListenerManager，用於跟蹤幾個核心模組之間的協同事件，同時優化了其WebUI的文字展示~
-
新增兩個資料開發相關的工具
-
DatabaseTool 可以做資料庫相關的執行和查詢操作， 為了驗證Agent的問數效果。
-
Jupyter Notebook Client 可以使得Agent遠端執行Python程式碼和指令（比如安裝依賴的Python包）， 另外後續可以透過Jupyter Notebook管理敏感金鑰資訊。
以下為整體的設計
Prompt
到這裡， 你會發現前面的Memory，Tools，Planning每一部分，其實都是在解決最核心的問題：如何在正確階段構建最佳的Prompt，印證了LLM部分描述提示詞的重要性。 所以Prompt非常重要， 如果你發現Agent效果不好， 可以先從最佳化提示詞開始。
系統的提示詞，某種程度上決定了LLM對Agent的特質和能力判斷， 比如藉助LLM生成計劃，如果沒有設計系統的提示詞，LLM根據使用者的輸入，會生成完全無關的計劃，思考的域越大，效果會越差。 Openmanus裡面的計劃系統提示詞，就很明確地告知LLM的如何執行計劃，如何使用工具等。
每一步的提示詞，決定LLM如何使用工具， 比如我希望LLM優先使用RemoteJupyterClient，可以重點強調其作用，尤其是加了You Can also use pip install packages when package not found 這一句，LLM可以生成pip命令，自動安裝包。
Planning
PLANNING_SYSTEM_PROMPT = """You are an expert Planning Agent tasked with solving problems efficiently through structured plans.Your job is:1. Analyze requests to understand the task scope2. Create a clear, actionable plan that makes meaningful progress with the `planning` tool3. Execute steps using available tools as needed4. Track progress and adapt plans when necessary5. Use `finish` to conclude immediately when the task is completeAvailable tools will vary by task but may include:- `planning`: Create, update, and track plans (commands: create, update, mark_step, etc.)- `finish`: End the task when completeBreak tasks into logical steps with clear outcomes. Avoid excessive detail or sub-steps.Think about dependencies and verification methods.Know when to conclude - don't continue thinking once objectives are met."""ManusAgentSYSTEM_PROMPT = "You are OpenManus, an all-capable AI assistant, aimed at solving any task presented by the user. You have various tools at your disposal that you can call upon to efficiently complete complex requests. Whether it's programming, information retrieval, file processing, or web browsing, you can handle it all."NEXT_STEP_PROMPT = """You can interact with the computer using PythonExecute, save important content and information files through FileSaver, open browsers with BrowserUseTool, execute python code with RemoteJupyterClient and retrieve information using GoogleSearch.PythonExecute: Execute Python code to interact with the computer system, when RemoteJupyterClient not work, try use this.RemoteJupyterClient: Execute Python code on a remote Jupyter Server to data processing, automation tasks, etc. You Can also use pip install packages when package not found.FileSaver: Save files locally, such as txt, py, html, etc.BrowserUseTool: Open, browse, and use web browsers.If you open a local HTML file, you must provide the absolute path to the file.GoogleSearch: Perform web information retrievalTerminate: End the current interaction when the task is complete or when you can do nothing.Based on user needs, proactively select the most appropriate tool or combination of tools. For complex tasks, you can break down the problem and use different tools step by step to solve it. After using each tool, clearly explain the execution results and suggest the next steps.Always maintain a helpful, informative tone throughout the interaction. If you encounter any limitations or need more details, clearly communicate this to the user before terminating."""toolsSYSTEM_PROMPT = "You are an agent that can execute tool calls"NEXT_STEP_PROMPT = ("If you want to stop interaction, use `terminate` tool/function call.")實驗
好了， 終於到實驗環節了， 為了驗證前面的實現，做了以下幾個場景的實驗。
經過我精心雕花，我們可以藉助WebUI來觀察效果，Planning和ReAct Agent用的LLM都是：qwen-max-latest
-
實驗一，寫一個QuickSort（無計劃）：生成很快，前面直接給出結果，並希望獲得下一步指示，但是我們並沒有給Agent其他額外指令（LLM很熱情，但是感受不到你需要它） 最後LLM只選擇JupyterClient驗證了程式碼正確性。
-
實驗二，寫一個QuickSort（有計劃）：Planning將該任務拆分成9個步驟，用時6分鐘， 綜合運用了Google Serach, PythonExecutor，JupyterClient，FileSave多個工具，並生成了程式碼和效能測試報告，可解釋性增強許多。
-
實驗三，Which sales agent made the most in sales in 2009 ? Answer based on database data. （無計劃）：感到驚訝， LLM自己做了規劃，查看錶結構， 最後的結果也正確。
-
實驗四，最近7天杭州天氣怎麼樣，請畫出相關圖表（有計劃）：這一段最為精彩
-
1、LLM嘗試使用工具爬取結構化的天氣資料，但是失敗了。 呼叫了Terminate工具結束任務。
-
2、但是ReAct Agent並沒有明確失敗是失敗， Planning繼續執行下一步，LLM這時候出現了幻覺， 從歷史的資料獲取資料。
-
3、拿到假的資料後， LLM充分利用了JupyterClient工具，編寫程式碼，遠端執行程式碼，遇到包不存在，使用PIP安裝包！這其實是在創造新工具。
# Action🚀 Manus is about to execute 1 tools: [ChatCompletionMessageToolCall(id='call_6284438a03d74103b16fc7', function=Function(arguments='{"code":"import sys\\n!{sys.executable} -m pip install matplotlib"}', name='remote_jupyter'), type='function', index=0)]# Using Tool🔧 Activating tool: 'remote_jupyter' args:{'code': 'import sys\n!{sys.executable} -m pip install matplotlib'}總結，我們可以從以上幾個實驗看到：
-
單純的ReAct模式的Agent對LLM的依賴較高， 執行效率也高，產生的結果沒有過多修飾。
-
使用Plan and Solve模式下，可解釋性提高, 但有時生成的計劃趕不上變化和實際不符合，導致ReAct會在一個計劃步驟內完成所有事情。
-
天氣的實驗，Agent對工具的能力依賴較高，需要考慮"兜底的邏輯"，防止LLM出現幻覺。
-
複雜的任務會上下文輸入會超過LLM的限制，導致任務無法進行下去。
-
並不能穩定地產生正確的結果，有時生成的程式碼或者SQL能正確執行，但結論是錯誤的。
改進
自主化演進
-
自我批判：實驗中可以看到， 透過LLM的規劃能力，能夠使得Agent更好的完成複雜的任務，在任務規劃方面從基於規則、引數的規劃能力逐步向基於環境的感知，實踐的反思、迭代進化。 ReActAgent具備一定的感知，反思，迭代能力，但是無法完成複雜的任務，可解釋性比PS要低。 當前我們Planning有兩個問題，1是依據較少，LLM容易出現幻覺，導致步驟較多， 執行計劃前需要更多資訊。 2是計劃執行過程中，無法動態調整， 需要能夠動態改進計劃。
-
程式碼即為工具：在工具使用與選擇方面，向多種工具的選擇規劃進化，甚至更進一步地創造適用於 LLM 的工具。LLM創造工具，依賴於其編碼能力，比如Manus團隊在描述是否使用MCP時，提到受到CodeAct啟發，將程式碼執行視為解決問題的工具而非目標，正所謂“太極生兩儀。兩儀生四象，四象生八卦”。
Executable Code Actions Elicit Better LLM Agents
-
自我成長：如何讓Agent根據之前的經驗（記憶）改進行為呢？
-
上下文長度限制和注意力問題：ReAct Agent依靠週而復始的Thought- Action-Observation不斷迭代，得到最終的結果，Agent會記錄每次的結果，按時間序列組織記憶，隨著步數的增多，每次給LLM的上下文會變得很長，比如Qwen-Max 有32K的上下文長度，多輪對話或者複雜的問題處理，很容易超出LLM的上下文長度限制。而且如果每次給LLM的上下文都很大，LLM推理的效能相應的也會變慢。除了慢以外，也會影響LLM的注意力，LLM並不能穩定的利用長輸入上下文資訊， LLM比較容易“記住”開頭和結尾的上下文，中間的部分有時會被忽略， 就和你開一個漫長的會議一樣， 沒有結論的會議等於白開了。
Lost in the Middle: How Language Models Use Long Contexts
-
對記憶進行概括和抽象：實際中如果讓Agent每次進行下一次行為之前都要回憶一生，聽起來都覺得不靠譜。所以Agent的記憶管理很重要。 Agent記憶， 可以結合RAG技術，實現將知識庫轉變為長期記憶。實現時需要區分短期工作（互動的上下文）和長期記憶， 同時能夠根據使用者行為習慣和反饋儲存和修改記憶，對後續的Agent的體驗可能會有幫助。 實現上可以參考MemGPT和Mem0的設計思路。 針對記憶的儲存，整理和讀取三個階段，進行干預。 比如Mem0是依靠LLM來實現記憶分層和自適應能力。
Mem0 Memory Operations
-
Agent自我學習能力評測： Anthropic官方關於構建AI Agent的建議中，提到的最重要的一點就是：Make sure that you have a way to measure your results。 最近不小心看到了StreamBench這個專案， 可能會有幫助。
StreamBench: Towards Benchmarking Continuous Improvement of Language Agents
多Agent
ChatDev: Communicative Agents for Software Developmen
吳恩達提到的Agent設計模式有四個（Reflection，Tool Use， Planning，Multi-Agent Collaboration），我們驗證了前三個。
Multi-Agent Collaboration可以提高任務執行效率，多個智慧體分工協作，同時具備複雜問題分解能力。
每個Agent各司其職，其上下文記憶對LLM也友好， 不容易偏差，可以更好的利用LLM。 凡事都有兩面性，多個Agent也會帶來新的問題，就如同微服務相對於單體應用一樣，增加了系統的複雜度。 這就引入了Agent之間協作，資訊共享，隱私安全，多智慧體學習問題。下圖是《Why Do Multi-Agent LLM Systems Fail?》 這篇Paper描述的三種常見的失敗類別。
Why Do Multi-Agent LLM Systems Fail?
前文提到的Planning的問題，對於複雜問題的規劃，往往會遇到困難或者因為LLM的幻覺，生成不合理的步驟。 雖然ReActAgent有時可以透過推理，行動，觀察來為Planning的不合理計劃兜底， 但是會降低Agent的效率。
歸因為沒有對Planning生成的計劃進行驗證。 針對這個問題，Google提出了新的框架PLanGEN, 包含三個關鍵的元件： 約束，驗證和選擇智慧體。在PlanGEN框架中，智慧體根據例項複雜性最佳化演算法選擇，確保更好地適應複雜的規劃問題， 約束引導的迭代驗證可以提升推理時演算法的效能，而適應性的選擇則進一步提高了在複雜規劃和推理問題上的表現。
PlanGEN: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories for Complex Problem Solving
另外《Scaling Large-Language-Model-based Multi-Agent Collaboration》https://arxiv.org/abs/2406.07155這篇Paper提到了協作湧現。 受到神經網路規模法則的啟發，增加神經元會導致新能力的湧現，在多智慧體協作中，增加智慧體是否遵循類似的原理，挺有趣的。
MCP
MCP（Model Context Protocol）是由Anthropic公司提出的一種協議，其核心動機在於顯著提升AI模型（如Claude）與外部系統之間的互動能力。透過開源的方式，MCP不僅鼓勵社群共同參與和完善這一協議，還旨在推動AI Agent生態的發展。從技術角度來看，MCP的設計並不複雜，但其真正的力量來自於共識——這種共識使得不同系統間的協作成為可能，併為開發者提供了一種標準化的解決方案。
藉助MCP，Agent只需一次接入即可無縫適配多種工具和服務，從而大幅減少碎片化開發的重複勞動。MCP讓一個Agent能夠連線整個世界，實現跨系統的無縫整合能力。如果想追蹤MCP當前的發展動態及其生態狀況，可以關注awesome-mcp-servers：https://github.com/punkpeye/awesome-mcp-servers專案，這裡匯聚了全球開發者對這一領域的最新探索與貢獻。
在架構設計上，MCP將Host（Client）與Server分離，工具由Server端呼叫，而Server端則負責統一管控這些工具的使用，並對外提供服務。這種設計模式提高了系統的靈活性和可擴充套件性， 對於雲服務提供商來說或者Dify這種LLMOps中間價產品，是利好的， 個人覺得可能有如下幾個方面：
1. 服務複用
MCP透過標準化工具整合流程，雲廠商無需再為每個客戶或場景單獨開發介面，客戶也不需要定製開發，而是可以直接複用現有的成熟服務模組。在保證功能完整性的同時，也降低了維護成本。
2. 一站式平臺構建
依託MCP的標準化協議，雲廠商能夠快速搭建起“一站式”AI服務平臺。例如，透過視覺化管理介面和低程式碼工作流配置工具，使用者無需深入理解底層技術細節，便可輕鬆完成複雜的任務部署。
3. 工具生態整合
在MCP的支援下，客戶不僅可以享受雲廠商提供的專屬工具，還能自由利用開源生態中的豐富資源，如資料庫、瀏覽器自動化工具等。這些工具透過Agent進行統一呼叫，形成了一套協同的工作體系。雲廠商因此得以藉助開源社群的力量，避免從零開始開發，從而幫助使用者加速AI應用的落地程序，這是一種共生關係。
4. 合規與安全性保障
透過在MCP Server端實施許可權管理、審計機制以及沙箱環境的構建，能有效減少敏感資料暴露的風險。例如，在MyManus中引入JupyterClient時，就是希望為程式碼執行其設計了一個受控的沙箱環境，允許單租戶擁有專屬的環境變數設定。
也有反對使用MCP的， 比如LangChain發起了討論，並對MCP是否是曇花一現發起了投票，有40%的人認為是個未來的標準， 20%的認為是曇花一現。 具體討論可以看MCP: Flash in the Pan or Future Standard? .
https://blog.langchain.dev/mcp-fad-or-fixture/
當下不能過於神化任何AI相關東西，MCP解決不了LLM很多時候無法正確地使用工具問題，但還是值得投入研究的，“人們總是高估一項科技所帶來的短期效益，卻又低估它的長期影響”。AI最大的機會可能在於改變現有的業務流程和產品，專注特定的小規模的業務場景，深入解決具體問題，而不是追求建立大型平臺。
最後
看了許多關於人工智慧的學術文章與技術論文之後， 深切體會到，唯有將這些理論付諸實踐，將其轉化為文字和具體的程式碼，才能真正感受到當下大型語言模型（LLM）所蘊含的非凡魅力，這種從認識到實踐的過程，不僅加深了技術理解，更是一場思想深度對話，Agent相關的研究還有很多，希望這篇文章對大家有幫助，也算是為知識傳播盡了一份綿薄之力，如果沒有，書寫本身便已是一種自我沉澱與邏輯自洽的過程，也足以讓自己滿足~
參考附錄：
-
Tool Learning with Large Language Models: A Survey：https://arxiv.org/abs/2405.17935
-
ReAct: Synergizing Reasoning and Acting in Language Models：https://arxiv.org/abs/2210.03629
-
Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models：https://arxiv.org/abs/2305.04091
-
ChatDev: Communicative Agents for Software Developmen：https://arxiv.org/abs/2307.07924
-
https://arxiv.org/abs/2405.17935：https://arxiv.org/abs/2405.17935
-
https://www.holisticai.com/blog/llm-agents-use-cases-risks：https://www.holisticai.com/blog/llm-agents-use-cases-risks
-
Scaling Large-Language-Model-based Multi-Agent Collaboration：https://arxiv.org/abs/2406.07155
-
PlanGEN: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories for Complex Problem Solving：https://arxiv.org/abs/2502.16111
-
A Survey on the Memory Mechanism of Large Language Model based Agents
-
Lost in the Middle: How Language Models Use Long Contexts：https://cs.stanford.edu/~nfliu/papers/lost-in-the-middle.arxiv2023.pdf
端到端全鏈路追蹤診斷
本方案為您介紹如何使用應用即時監控服務 ARMS 應用監控進行一站式呼叫鏈路追蹤，幫助您快速定位問題，洞察效能瓶頸，重現呼叫引數，從而大幅提升線上問題診斷的效率。
點選閱讀原文檢視詳情。