
摘要Agent 從「能對話」演進為「能行動」,應用設計邏輯發生根本變化——從「Prompt → 回答」走向「感知 → 思考 → 工具調用 → 行動 → 反饋」的閉環。本文系統拆解智能體的 3 大核心能力:工具調用(Function Call)、記憶管理(Memory)、多 Agent 協作(Multi-Agent),并給出 4 個真實落地架構。所有數據與代碼均來自 2026 奇點智能大會確認嘉賓張鈁、鄭耀威的公開技術分享。SEO關鍵詞:AI Agent / 智能體開發 / 多 Agent 協作 / MCP 協議 / 工具調用 / 記憶管理 / Agent UX / 2026 奇點智能大會一、為什么 2026 是「智能體應用元年」過去 18 個月,大模型的能力躍遷已經觸及天花板——單純靠模型變大帶來的邊際收益迅速下降。但「讓模型能用工具、能記住對話、能跟其他 Agent 協作」的能力,正在打開一個全新空間。2026 奇點智能大會把這一議題命名為「智能體應用創新與開發實踐」,由張鈁(上海 AI Lab 智能體中心負責人)與鄭耀威(開源 Harness 作者)擔綱,核心回答 3 個問題:工具調用:Agent 怎么用工具?Function Call 協議怎么設計?記憶管理:Agent 怎么記住歷史?短期記憶 vs 長期記憶怎么權衡?多 Agent 協作:多個 Agent 怎么協作?通信協議怎么設計?二、核心能力 1:工具調用(Function Call) 協議設計:OpenAI Function Call 規范工具調用是 Agent 能力的基石。當前主流的 OpenAI Function Call 協議規范:{name:get_weather,description:獲取指定城市的天氣信息,parameters:{type:object,properties:{city:{type:string,description:城市名稱,如北京},unit:{type:string,enum:[celsius,fahrenheit],description:溫度單位}},required:[city]}}Agent 收到用戶 query 后,會判斷是否需要調用工具,并返回結構化參數:{tool_calls:[{id:call_abc123,type:function,function:{name:get_weather,arguments:{\city\: \北京\, \unit\: \celsius\}}}]}? 工程實現:工具注冊與執行# 偽代碼:Agent 的工具調用核心classAgentToolRegistry:def__init__(self):self.tools{}self.schemas[]defregister(self,name,func,schema):注冊一個工具self.tools[name]func self.schemas.append(schema)defexecute(self,tool_call):執行工具調用nametool_call.function.name argsjson.loads(tool_call.function.arguments)try:resultself.tools[name](**args)return{tool_call_id:tool_call.id,result:result}exceptExceptionase:return{tool_call_id:tool_call.id,error:str(e)}# 真實使用示例agentLLMAgent(modelgpt-5)agent.tool(description查詢訂單狀態,schema{...})defquery_order(order_id:str)-dict:查詢訂單狀態的工具returndb.orders.find_one({_id:order_id})agent.tool(description發起退款,schema{...})defprocess_refund(order_id:str,reason:str)-dict:發起退款流程returnpayment.refund(order_id,reason)# 用戶 query: 幫我看看訂單 12345 的狀態,如果 7 天還沒發貨就退款# Agent 自動拆解為:# 1. query_order(order_id12345)# 2. 判斷發貨時間,如果 7 天則 process_refund(order_id12345, reason超時未發貨)張鈁(上海 AI Lab 智能體中心負責人)對工具調用的關鍵判斷:「工具原子化」是工具調用設計的核心原則——每個工具只做一件事,不要做大工具。原子化讓 Agent 更容易理解,出錯時更容易定位。三、核心能力 2:記憶管理(Memory) 3 層記憶架構智能體的記憶分為 3 層:層級容量速度用途L1 短期記憶128K-1M token極快(顯存)當前會話上下文L2 工作記憶100K-1M 條快(向量數據庫)跨會話的關鍵事實L3 長期記憶無限較慢(數據庫)用戶畫像、領域知識、ADR# 偽代碼:3 層記憶架構classAgentMemory:def__init__(self):self.short_termConversationBuffer(window20)# 20 輪對話self.workingVectorStore(embedding_modelbge-large)# 向量庫self.long_termPostgreSQL()# 關系數據庫defadd(self,message):添加一條對話到記憶self.short_term.add(message)# 提取關鍵事實到工作記憶factsself.extract_facts(message)forfactinfacts:self.working.upsert(fact)defretrieve(self,query,top_k5):根據 query 檢索相關記憶# 1. 短期記憶:返回最近 20 輪recentself.short_term.get()# 2. 工作記憶:返回最相關的 top_k 條relevantself.working.search(query,top_ktop_k)# 3. 長期記憶:根據 query 提取用戶畫像user_profileself.long_term.get_user_profile(query.user_id)return{recent:recent,relevant:relevant,user_profile:user_profile}? 記憶壓縮與摘要長期記憶會隨時間膨脹,需要定期壓縮:# 偽代碼:記憶壓縮classMemoryCompressor:defcompress(self,conversations,target_token2000):把長對話壓縮為摘要,保留關鍵信息# 1. 用 LLM 提取每段對話的關鍵事實facts[]forconvinconversations:factself.llm.extract(f從以下對話中提取關鍵事實:\n{conv})facts.append(fact)# 2. 合并相似事實merged_factsself.deduplicate(facts)# 3. 生成壓縮摘要summaryself.llm.summarize(factsmerged_facts,target_tokenstarget_token)returnsummary鄭耀威(PenguinAI Harness 作者)對記憶管理的關鍵判斷:「記憶不是越多越好,是越相關越好」——一個 Agent 塞滿 1M token 的記憶,實際推理時只會用其中 1%。工程上的關鍵是精準檢索,而非全量記憶。四、核心能力 3:多 Agent 協作(Multi-Agent) 3 種主流協作模式模式原理適用場景代表項目主從模式1 個 Planner Agent N 個 Worker Agent任務可清晰拆解OpenAI Swarm、MetaGPT對等模式N 個 Agent 平等協作,無中心創造性任務、辯論AutoGen、CrewAI分層模式多級 Agent 嵌套,上層 Agent 調度下層復雜企業級應用LangGraph、AgentVerse? 工程實現:主從模式 Multi-Agent# 偽代碼:主從模式 Multi-AgentclassPlannerAgent:負責拆解任務、調度 Worker Agentdef__init__(self,workers):self.workersworkers# 注冊的 Worker Agent 列表self.history[]defplan(self,task):把任務拆解為子任務序列planself.llm.generate(f把以下任務拆解為可并行/串行執行的子任務:\n{task})returnself.parse_plan(plan)defexecute(self,task):sub_tasksself.plan(task)results{}forsubinsub_tasks:ifsub.parallel:# 并行執行results[sub.id]self.parallel_execute(sub)else:# 串行執行results[sub.id]self.workers[sub.agent].run(sub.input,contextresults)returnself.synthesize(results)classWorkerAgent:負責執行具體子任務def__init__(self,name,tools,system_prompt):self.namename self.toolstools self.system_promptsystem_promptdefrun(self,input,contextNone):執行子任務messages[{role:system,content:self.system_prompt},{role:user,content:f輸入:{input}\n上下文:{context}}]whileTrue:responseself.llm.generate(messages,toolsself.tools)ifresponse.tool_calls:forcallinresponse.tool_calls:resultself.execute_tool(call)messages.append({role:tool,content:result})else:returnresponse.content# 真實使用:多 Agent 協作完成「代碼評審」任務plannerPlannerAgent(workers{code_analyzer:WorkerAgent(name代碼分析員,tools[read_file,search_code,run_linter],system_prompt你是代碼分析員,負責檢查代碼質量、安全、性能),test_runner:WorkerAgent(name測試執行員,tools[run_test,run_coverage],system_prompt你是測試執行員,負責運行測試用例并生成報告),review_writer:WorkerAgent(name評審撰寫員,tools[write_file],system_prompt你是評審撰寫員,負責綜合分析結果,撰寫 PR Review 評論)})resultplanner.execute(審查 PR #1234 的代碼質量)# Planner 自動拆解為:# 1. code_analyzer 分析代碼(并行)# 2. test_runner 跑測試(并行)# 3. review_writer 綜合 12 寫評審(串行,依賴前兩步)張鈁對多 Agent 協作的關鍵判斷:「多 Agent 不是越多越好,而是越『邊界清晰』越好」——每個 Agent 的職責、能力、接口必須嚴格定義,否則 Agent 之間的通信開銷會指數級增長。3-5 個 Agent 是大多數場景的最佳規模。五、4 個真實落地架構? 架構 1:客服 Agent(單 Agent 工具)用戶 → Agent(意圖識別) → 工具調用(訂單/退款/物流) ↓ 知識庫 RAG(常見問題) ↓ 不確定 → 轉人工? 架構 2:研發 Agent(主從 Multi-Agent)Planner ├── Code Generator(寫代碼) ├── Test Runner(寫測試) ├── Code Reviewer(代碼審查) └── Deploy Agent(部署)? 架構 3:數據分析 Agent(對等 Multi-Agent)Question Agent(理解問題) SQL Agent(寫 SQL) Data Analyst(分析結果) Visualizer(生成圖表)? 架構 4:企業級 Agent 網(分層)L1 決策 Agent(CEO/部門級) ↓ 調度 L2 業務 Agent(HR/財務/產品) ↓ 調度 L3 執行 Agent(具體任務執行)六、Agent UX 設計的關鍵挑戰張鈁特別強調:「智能體時代,UX 設計發生了根本變化」。傳統 UXAgent UX用戶操作固定流程用戶描述意圖,Agent 自主決策錯誤可預測錯誤不可預測,需要「兜底」設計反饋即時反饋延遲(多步推理)確定性結果不確定性結果(同一 query 可能不同答案)UX 設計的 4 個關鍵原則:永遠給用戶「取消」按鈕——Agent 跑偏時,用戶要能立即打斷永遠展示 Agent 的「思考過程」——讓用戶知道 Agent 在做什么、為什么這么做永遠提供「人工接管」入口——任何 Agent 決策,關鍵節點都要能轉人工永遠設置「置信度閾值」——置信度低時主動告知用戶,而非強行給出答案七、常見問題 FAQQ1:Function Call 協議有標準嗎?有。OpenAI 在 2023 年 6 月推出 Function Call 規范,現已成為事實標準。Anthropic、阿里通義、DeepSeek 等都兼容。Anthropic 在 2024 年還推出了更結構化的「Tool Use」協議。Q2:多 Agent 協作的最大挑戰是什么?通信開銷與狀態同步。N 個 Agent 之間是 O(N2) 的通信復雜度,Agent 數量超過 5 個后,通信開銷會指數級增長。工程上必須嚴格定義每個 Agent 的邊界。Q3:智能體時代,前端工程師會被取代嗎?不會。Agent UX 反而需要更多前端工程師——可視化 Agent 思考過程、人類反饋回路、置信度展示等都是新的前端課題。想深入了解張鈁、鄭耀威等智能體方向嘉賓的完整工程實踐,可前往奇點大會官方渠道免費領取大會 PPT 詳細資料。