1. 從“工具調用”到“智能體”為什么你的AI項目需要升級思維如果你最近在折騰AI應用開發(fā)尤其是基于大語言模型LLM構建一些自動化流程那么“Tool Calling”工具調用這個概念你一定不陌生。簡單來說就是讓AI模型能夠理解你的指令然后去調用一個預設好的外部工具比如查詢天氣、發(fā)送郵件、執(zhí)行計算來完成特定任務。這就像是給一個聰明的“大腦”裝上了可以操作外部世界的“手”和“腳”讓它從“紙上談兵”變成了“能動手干活”。很多教程和項目包括一些熱門的開源框架都止步于此。你可能會跟著教程用幾行代碼就搭好了一個能調用搜索引擎、能操作數(shù)據(jù)庫的AI助手感覺一切都很美好。但當你真正想用它去處理一個稍微復雜點的業(yè)務流程時問題就來了這個“大腦”似乎只會執(zhí)行單一步驟。你告訴它“幫我查一下上海明天的天氣如果下雨就提醒我?guī)悴堰@個提醒加到我的日歷里”它可能會卡住或者只執(zhí)行第一步就結束了。它缺乏一種“統(tǒng)籌規(guī)劃”和“自主決策”的能力無法將多個工具調用串聯(lián)起來形成一個連貫的、目標導向的工作流。這就是“Agent”智能體概念要解決的核心問題。Agent不是一個新工具而是一種新的架構思維。它讓AI從一個被動的、單次響應的“函數(shù)調用者”轉變?yōu)橐粋€主動的、擁有記憶和規(guī)劃能力的“任務執(zhí)行者”。最近網(wǎng)絡上關于“Agent開發(fā)”、“AI Agent搭建”、“Hermes Agent”的討論熱度飆升正反映了開發(fā)者們從實現(xiàn)基礎功能到追求更高級別自動化的普遍需求。簡單理解如果Tool是AI的“手腳”那么Agent就是給這具身體裝上了“小腦”和“前額葉”讓它能自己判斷先邁哪只腳、怎么走到目的地。2. Agent的核心架構超越簡單的工具調用鏈那么一個典型的Agent和簡單的工具調用鏈到底有什么區(qū)別關鍵在于它引入了幾個核心的“認知”組件這些組件共同構成了Agent的“智能循環(huán)”。理解這個架構是進行Agent開發(fā)的第一步。2.1 規(guī)劃Planning從目標拆解到步驟生成這是Agent區(qū)別于普通工具調用的最顯著特征。普通的工具調用是“刺激-反應”模式用戶輸入一個明確的、原子化的指令如“查詢天氣”模型直接匹配并調用對應工具。而Agent需要處理的是模糊的、高層次的用戶目標如“幫我策劃一個周末的短途旅行”。規(guī)劃器Planner的工作就是將這個宏大目標分解成一系列可執(zhí)行的子任務。這個過程不是隨機的它通?；趦煞N策略鏈式思考Chain-of-Thought讓模型逐步推理?！安邉澛眯小毙枰取按_定目的地”然后“查詢天氣和交通”接著“查找景點和酒店”最后“生成行程安排”。模型會顯式地輸出這些思考步驟。任務分解Task Decomposition將目標遞歸地拆解為更小的任務樹直到每個葉子節(jié)點都能被一個具體的工具或指令處理。在實際開發(fā)中規(guī)劃能力通常由一個大語言模型如GPT-4、Claude 3或開源的Llama 3來承擔。你需要設計高質量的提示詞Prompt來引導模型進行這種分解。例如你的提示詞模板里需要明確說明“你是一個旅行規(guī)劃助手。請將用戶的旅行需求分解為具體的、可順序執(zhí)行的任務步驟。每個步驟應該對應一個你可以執(zhí)行的操作如‘搜索目的地信息’、‘查詢航班’、‘篩選酒店’等。”2.2 工具集ToolsAgent的能力邊界工具集是Agent賴以行動的“武器庫”。它繼承了Tool Calling的所有能力但要求更高。一個為Agent設計的工具不僅要有清晰的函數(shù)定義和描述其描述信息還需要足夠豐富以便規(guī)劃器能準確判斷在什么場景下該使用它。例如一個簡單的“搜索網(wǎng)絡”工具其描述可能從“搜索互聯(lián)網(wǎng)信息”升級為“當需要獲取最新的、實時的、或知識庫外的公開信息時使用此工具例如查詢新聞、股價、天氣、或某個概念的解釋”。更高級的Agent框架如LangChain、AutoGPT的架構會要求為工具定義更詳細的元數(shù)據(jù)包括輸入/輸出模式、使用場景示例、甚至與其他工具的關聯(lián)性。這里有一個關鍵的開發(fā)心得不要一次性給Agent提供幾十個工具。工具過多會導致規(guī)劃器困惑增加錯誤調用和循環(huán)調用的風險。應該根據(jù)Agent的專有領域Domain來精心挑選和設計工具集。一個“客服Agent”的工具集可能包括“查詢訂單”、“檢索知識庫”、“生成工單”而一個“數(shù)據(jù)分析Agent”的工具集則可能是“執(zhí)行SQL查詢”、“生成圖表”、“發(fā)送報告”。2.3 記憶Memory讓對話擁有上下文記憶是Agent實現(xiàn)多輪對話和持續(xù)學習的基礎。它分為幾種類型短期記憶/對話記憶保存當前會話的歷史消息。這是最基本的確保Agent能理解“你剛才說的XXX”指的是什么。長期記憶將重要的信息持久化存儲到向量數(shù)據(jù)庫如Chroma、Pinecone或傳統(tǒng)數(shù)據(jù)庫中。例如用戶說“我喜歡靠窗的座位”這個偏好可以被存儲下來在下次預訂機票時自動使用。摘要記憶對于非常長的對話可以將歷史壓縮成摘要既保留了關鍵信息又避免了上下文長度Context Window的爆炸。在實現(xiàn)上記憶模塊不僅僅是存儲和讀取。它涉及到信息的提取、壓縮、索引和檢索。當Agent進行規(guī)劃時它需要從記憶庫中檢索相關的歷史信息來輔助決策。例如規(guī)劃“推薦餐廳”時需要檢索用戶記憶中“喜歡吃辣”、“預算中等”等標簽。2.4 執(zhí)行與反思Execution Reflection閉環(huán)的關鍵Agent按照規(guī)劃執(zhí)行工具調用但這并不是終點。反思Reflection或自我批判Self-Criticism是高級Agent的另一個標志性能力。在執(zhí)行完一個或一系列動作后Agent會評估結果是否達成了子目標。結果驗證調用“計算器”工具后檢查計算結果是否合理例如沒有出現(xiàn)除以零的錯誤。目標核對執(zhí)行“搜索景點”后檢查返回的信息是否與用戶需求如“適合家庭出游”匹配。錯誤處理與重規(guī)劃如果結果不理想或工具調用失敗如API返回錯誤反思模塊會分析原因并可能觸發(fā)重新規(guī)劃。例如搜索“XX小眾景點”沒結果Agent可能會決定改用更通用的關鍵詞重新搜索或者向用戶請求更具體的描述。這個“規(guī)劃 - 執(zhí)行 - 觀察 - 反思 - 再規(guī)劃”的循環(huán)構成了Agent的自主性。市面上一些開源的Agent框架如微軟的AutoGen、LangGraph的核心就是在編排這個循環(huán)。3. 主流Agent開發(fā)框架與技術棧選型了解了核心架構后你需要選擇合適的“腳手架”來構建你的Agent。不同的框架抽象層次不同適合不同需求的開發(fā)者。3.1 高階框架專注于編排與協(xié)作這類框架提供了高級的抽象讓你通過配置和少量的代碼就能定義復雜的Agent工作流特別適合構建多Agent系統(tǒng)多個Agent協(xié)作完成任務。AutoGen微軟目前非常活躍和強大的多Agent對話框架。它核心的概念是“Conversable Agent”。你可以輕松定義多個Agent角色如“程序員”、“測試員”、“產品經(jīng)理”并為它們配置不同的LLM、系統(tǒng)提示詞和工具。Agent之間可以通過結構化對話來自動協(xié)商和完成任務。它的優(yōu)勢在于復雜的多輪交互和角色扮演場景例如自動化的代碼評審、頭腦風暴會議等。適合場景研究性質的多Agent交互、復雜任務自動化、需要模擬不同角色的場景。上手難度中等需要理解其對話和群組管理機制。LangGraph / LangChainLangChain是一個龐大的LLM應用開發(fā)庫而LangGraph是其中專注于構建有狀態(tài)、多環(huán)節(jié)工作流即Agent的模塊。它使用“圖”Graph的概念來定義工作流節(jié)點Node可以是工具調用、LLM調用或條件判斷邊Edge定義了執(zhí)行流程。它的控制流非常靈活可以輕松實現(xiàn)循環(huán)、分支等邏輯。適合場景需要精細控制執(zhí)行流程的復雜業(yè)務邏輯、已有LangChain生態(tài)的項目升級。上手難度中高需要理解圖計算的概念和LangChain的基礎。3.2 實用型框架平衡靈活與易用這類框架在提供足夠靈活性的同時盡量降低了開發(fā)復雜度是大多數(shù)應用型Agent項目的首選。CrewAI這是一個新興但設計非常優(yōu)雅的框架。它引入了“角色Role”、“任務Task”、“流程Process”這幾個清晰的概念。你像導演一樣先定義各個Agent的“角色”如“研究員”、“寫作專家”然后創(chuàng)建具體的“任務”并指定由哪個角色、按何種“流程”順序執(zhí)行或輪詢執(zhí)行來完成。它的代碼非常直觀接近于用自然語言描述工作流。適合場景面向任務的自動化流水線如自動化報告生成、競品分析、內容創(chuàng)作等。上手難度低概念清晰文檔友好。Hermes Agent根據(jù)網(wǎng)絡熱度這很可能是一個特定領域如金融、游戲或某公司開源的Agent項目。對于這類具體項目在選型時一定要深入其官網(wǎng)或GitHub倉庫明確其設計哲學和解決的問題域。它可能在某些方面如工具集成、領域模型微調有獨特優(yōu)勢但通用性和社區(qū)支持可能不如上述主流框架。選型建議如果它的定位恰好解決你的痛點例如它內置了完美的股票交易工具鏈可以深入評估。否則建議從通用框架開始。3.3 底層技術棧構建自定義Agent的基石如果你需要極高的定制化或者想深入理解Agent的每一行代碼可以從這些底層組件開始搭建LLM SDK/API這是Agent的“大腦”。OpenAI GPT、Anthropic Claude、Google Gemini的API是閉源但強大的選擇。開源方面Llama 3、Qwen、DeepSeek等模型通過Ollama、vLLM等本地部署方案提供了數(shù)據(jù)隱私和成本可控的選項。關鍵點選擇LLM時除了關注常規(guī)的對話能力更要關注其在“規(guī)劃”和“步驟分解”任務上的表現(xiàn)這需要設計專門的測試用例進行評估。向量數(shù)據(jù)庫實現(xiàn)長期記憶的核心。Chroma輕量、易用、Pinecone全托管、高性能、Qdrant開源、高性能是常見選擇。你需要將記憶片段文本編碼成向量Embedding并存儲在需要時進行相似性檢索。應用開發(fā)框架FastAPI或Flask用于構建提供Agent服務的Web APIStreamlit或Gradio用于快速構建演示界面。工具層你需要將各種API如SerpAPI搜索、SendGrid郵件、各種數(shù)據(jù)庫客戶端封裝成符合框架要求的工具函數(shù)。這部分工作量大但決定了Agent能力的廣度。技術棧選型心得對于大多數(shù)項目我建議采用“實用型框架如CrewAI 主流LLM API如GPT-4”的組合快速搭建原型。驗證想法和流程的可行性比追求技術棧的“高大上”更重要。待核心邏輯跑通后再根據(jù)性能、成本、數(shù)據(jù)安全的需求考慮替換為開源模型或更底層的框架。4. 實戰(zhàn)構建一個簡單的“旅行規(guī)劃Agent”讓我們用一個具體的例子將上述概念串聯(lián)起來。我們將使用CrewAI框架因其代碼最清晰來構建一個能進行多步規(guī)劃的旅行助手。目標用戶輸入“我想下周末去杭州旅行預算3000元”Agent能自動完成目的地信息搜集、景點推薦和簡單行程安排。4.1 環(huán)境準備與框架安裝首先確保你的Python環(huán)境建議3.10然后安裝必要的包。我們使用OpenAI的模型作為大腦。pip install crewai crewai-tools langchain-openai你需要準備一個OPENAI_API_KEY環(huán)境變量。4.2 定義角色與任務在CrewAI中我們首先定義執(zhí)行任務的“智能體”角色。import os from crewai import Agent, Task, Crew, Process from crewai_tools import SerperDevTool, WebsiteSearchTool from langchain_openai import ChatOpenAI # 初始化LLM這里使用gpt-3.5-turbo成本更低適合演示 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0.7, api_keyos.getenv(OPENAI_API_KEY)) # 定義工具一個網(wǎng)絡搜索工具需要注冊Serper.dev獲取免費額度 search_tool SerperDevTool() # 1. 定義“旅行研究員”角色 researcher Agent( role資深旅行研究員, goal根據(jù)用戶的預算、時間和興趣挖掘目的地的詳細、實用信息包括必去景點、當?shù)孛朗?、交通貼士和消費水平。, backstory你是一位足跡遍布全球的旅行作家擅長從海量信息中篩選出最精華、最真實的旅行建議。你對性價比和獨特體驗有敏銳的嗅覺。, verboseTrue, # 打印詳細執(zhí)行日志 allow_delegationFalse, # 不允許委托任務給其他Agent tools[search_tool], # 賦予它搜索工具 llmllm ) # 2. 定義“行程規(guī)劃師”角色 planner Agent( role貼心行程規(guī)劃師, goal基于研究員提供的信息為用戶量身打造一份詳細、可行、節(jié)奏舒適的每日行程計劃并嚴格控制總預算。, backstory你是一位資深旅行社策劃為無數(shù)家庭、情侶、背包客設計過完美旅程。你深知如何平衡觀光、休閑和美食讓每一天都充實而不疲憊。, verboseTrue, allow_delegationFalse, # 規(guī)劃師不需要直接搜索它處理研究員提供的信息 llmllm )4.3 創(chuàng)建具體任務并建立依賴關系接下來我們創(chuàng)建具體的任務并指定由哪個Agent執(zhí)行以及任務之間的輸入輸出關系。# 任務1信息搜集 research_task Task( description針對用戶的目的地“{destination}”和預算“{budget}”進行深入調研。 重點收集以下信息 1. 未來一周目的地的天氣情況。 2. 3-4個最值得去的核心景點并注明大致門票費用和游覽時間。 3. 2-3種當?shù)靥厣朗臣叭司M。 4. 從用戶所在城市假設為上海到目的地的主流交通方式、耗時及大致費用。 請確保信息準確、最新并直接與用戶的預算約束相關聯(lián)。, expected_output一份結構清晰的調研報告包含天氣、景點、美食、交通四個部分并附上關鍵數(shù)據(jù)費用、時間。, agentresearcher, # 此任務由研究員執(zhí)行 async_executionFalse # 順序執(zhí)行 ) # 任務2行程規(guī)劃它依賴于任務1的輸出 plan_task Task( description基于以下調研報告 {research_output} 為用戶規(guī)劃一個為期兩天周末的詳細行程。 要求 1. 行程需具體到每天上午、下午、晚上。 2. 每個時間段安排一個主要活動景點參觀或美食體驗。 3. 在行程中明確標注預估的單項費用門票、餐費。 4. 計算行程總花費并確保它不超過用戶預算{budget}。如果超出請調整方案如選擇更經(jīng)濟的餐館或免費景點。 5. 給出一些實用的貼士如穿著建議、交通卡購買等。, expected_output一份詳細的、包含時間線、活動內容和費用明細的周末旅行行程單以及總預算核算。, agentplanner, # 此任務由規(guī)劃師執(zhí)行 context[research_task], # 關鍵指明此任務需要research_task的輸出作為上下文 async_executionFalse )4.4 組建團隊并執(zhí)行最后將Agent和Task組合成一個“團隊”Crew并指定執(zhí)行流程這里使用順序流程。# 組建團隊 travel_crew Crew( agents[researcher, planner], tasks[research_task, plan_task], processProcess.sequential, # 順序執(zhí)行先research_task再plan_task verbose2 # 輸出詳細的執(zhí)行日志 ) # 執(zhí)行任務 inputs { destination: 杭州, budget: 3000元 } result travel_crew.kickoff(inputsinputs) print(\n *50) print(最終生成的旅行計劃) print(*50) print(result)當你運行這段代碼時你會看到控制臺輸出詳細的執(zhí)行過程資深旅行研究員開始工作它會自動思考如何完成調研任務并調用SerperDevTool進行網(wǎng)絡搜索。研究員生成一份調研報告。這份報告作為輸入傳遞給貼心行程規(guī)劃師。規(guī)劃師基于報告開始規(guī)劃具體行程并在過程中進行預算核算。最終輸出一份完整的旅行計劃。這個簡單的例子揭示了Agent開發(fā)的核心價值你不再需要手動編寫“先搜A再搜B然后計算C”的硬編碼流程。你只需要定義好“角色”和“目標”它們就會在LLM的驅動下自主地使用工具、處理信息、完成任務。當你需要修改流程時比如增加一個“酒店預訂專家”角色你只需要定義新的Agent和Task并調整Crew的配置即可系統(tǒng)的可擴展性和可維護性大大增強。5. 避坑指南Agent開發(fā)中的常見挑戰(zhàn)與解決方案從工具調用升級到Agent開發(fā)你會遇到一系列新的挑戰(zhàn)。以下是我在實際項目中總結的幾個關鍵問題和應對策略。5.1 幻覺與錯誤規(guī)劃如何讓Agent更可靠LLM的“幻覺”在Agent場景下危害更大因為它可能導致一連串錯誤的工具調用。例如規(guī)劃器可能憑空捏造一個不存在的工具“預訂火星船票”并試圖調用它。解決方案嚴格的工具描述與驗證為每個工具提供極其精確和具體的描述包括輸入格式、輸出示例和嚴格的適用邊界。在工具被調用前可以增加一個“參數(shù)驗證”層檢查輸入是否符合預期。設置規(guī)劃驗證步驟在規(guī)劃器生成任務列表后不立即執(zhí)行而是增加一個“規(guī)劃評審”步驟?？梢杂昧硪粋€LLM或同一LLM的不同提示來評審這個計劃是否合理、是否所有步驟都有對應的可用工具。采用“ReAct”Reasoning Acting模式強制要求Agent在每次調用工具前先輸出一個“思考Thought”步驟闡明它為什么要調用這個工具、期望得到什么結果。這不僅能提升可解釋性有時也能讓模型自我糾正。使用更強大的模型實踐證明GPT-4、Claude 3 Opus等頂級模型在復雜規(guī)劃和避免幻覺方面遠優(yōu)于小模型。在關鍵Agent節(jié)點上投資更好的模型是值得的。5.2 循環(huán)與僵局當Agent陷入死胡同Agent可能陷入無限循環(huán)例如為了“寫一篇最好的文章”它不斷調用“搜索資料”工具永遠無法進入“開始寫作”階段。或者在兩個任務之間來回跳轉無法推進。解決方案設定明確的終止條件在任務描述中明確指出“當收集到5條相關資料后就停止搜索開始撰寫大綱”。或者為整個Agent流程設置最大迭代次數(shù)如10輪和超時時間。引入“裁判”或“管理者”Agent在CrewAI或AutoGen的多Agent系統(tǒng)中可以設置一個“管理者”角色其職責就是監(jiān)控任務進度在檢測到循環(huán)或僵局時進行干預例如重新指派任務或修改目標。優(yōu)化提示詞在規(guī)劃器的提示詞中加入明確的約束如“請生成一個線性、無循環(huán)的任務序列。確保每個任務都是前一個任務的自然延續(xù)且最終能達成總目標?！?.3 上下文管理與成本控制Agent的交互輪次多每次調用LLM都會消耗Token。攜帶完整的對話歷史、工具輸出和記憶上下文會迅速膨脹導致成本飆升甚至超出模型限制。解決方案選擇性上下文不要無腦地將所有歷史信息都塞進下一次LLM調用。只傳遞與當前決策最相關的記憶和工具結果。這需要設計智能的檢索策略。摘要與壓縮對冗長的工具輸出如一篇長文搜索結果進行摘要只將核心結論傳遞給下一步。同樣對較長的對話歷史進行定期摘要。分層記憶系統(tǒng)區(qū)分“工作記憶”當前任務相關和“長期記憶”用戶偏好等。每次主要從長期記憶中檢索相關片段放入工作記憶而不是全部加載。使用性價比更高的模型在不需要復雜推理的步驟如簡單的信息提取、格式化中使用小型、快速的模型如GPT-3.5-Turbo只在核心的規(guī)劃和創(chuàng)意步驟使用大模型。5.4 工具調用失敗的處理網(wǎng)絡超時、API限流、參數(shù)錯誤都會導致工具調用失敗。一個健壯的Agent必須有錯誤處理機制。解決方案實現(xiàn)重試機制對于網(wǎng)絡類錯誤可以實現(xiàn)帶指數(shù)退避的重試邏輯如最多重試3次每次間隔增加。提供清晰的錯誤反饋當工具調用失敗時將具體的錯誤信息如“天氣API返回無效的城市代碼”格式化后反饋給Agent的“反思”環(huán)節(jié)讓它有機會修正輸入或選擇其他工具。設計備選工具對于關鍵功能準備備用工具。例如主要搜索引擎失敗后自動切換至備用搜索引擎或知識庫查詢。設置“人工接管”出口當Agent多次嘗試失敗后應能優(yōu)雅地暫停并向用戶或系統(tǒng)管理員發(fā)送通知請求人工干預。6. 進階從單Agent到多Agent系統(tǒng)與真實業(yè)務集成當你掌握了單個Agent的構建后真正的威力在于構建多Agent系統(tǒng)并將它們集成到真實的業(yè)務流中。6.1 多Agent協(xié)作模式多個Agent可以以不同模式協(xié)作解決更復雜的問題流水線模式就像我們的旅行規(guī)劃例子研究員和規(guī)劃師依次工作前者的輸出是后者的輸入。適合流程清晰、步驟線性的任務。管理者-工作者模式一個“管理者”Agent接收用戶請求將其分解為子任務然后分配給不同的“工作者”Agent如代碼專家、文檔專家、測試專家并行或順序執(zhí)行并匯總結果。AutoGen非常擅長此模式。辯論與共識模式讓多個持有不同視角的Agent如“樂觀派”、“悲觀派”、“務實派”就一個問題進行討論甚至辯論最終形成一個更全面、平衡的結論。這對于創(chuàng)意生成、風險評估等場景很有用。6.2 與現(xiàn)有系統(tǒng)集成一個孤立的Agent演示價值有限。要創(chuàng)造實際業(yè)務價值必須考慮集成API化使用FastAPI將你的Agent Crew封裝成RESTful API。這樣前端應用、移動端或其他后端服務都可以通過HTTP請求來調用Agent能力。消息隊列與事件驅動讓Agent監(jiān)聽消息隊列如RabbitMQ、Kafka中的事件。例如當電商系統(tǒng)產生一個新訂單時觸發(fā)一個“客服跟進Agent”開始工作自動生成歡迎郵件和購物指南。數(shù)據(jù)庫集成Agent的記憶和知識庫需要與業(yè)務數(shù)據(jù)庫連接。確保你的工具函數(shù)封裝了安全的數(shù)據(jù)庫操作并且Agent有權限訪問必要的業(yè)務數(shù)據(jù)。人機協(xié)同設計Agent在遇到不確定或高權限操作時能主動向人類用戶發(fā)起詢問例如通過Slack消息、郵件或在一個管理界面上生成待辦事項。這被稱為“Human-in-the-loop”。6.3 評估與持續(xù)改進如何判斷你的Agent是否有效你需要建立評估體系任務完成率給定100個標準測試任務有多少個被成功、正確地完成了步驟效率完成一個任務平均需要多少次LLM調用和工具調用能否優(yōu)化成本指標處理單個請求的平均Token消耗和API費用是多少人工評分定期抽樣一批Agent的處理結果由真人從準確性、有用性、流暢性等維度打分。基于這些指標你可以持續(xù)迭代優(yōu)化提示詞、調整工具集、改進規(guī)劃邏輯甚至對LLM進行特定領域的微調Fine-tuning讓Agent越來越聰明、越來越高效。從實現(xiàn)一個簡單的工具調用到構建一個能自主規(guī)劃、執(zhí)行、反思的智能體這中間需要思維模式的根本轉變。你不再是一個“流程程序員”而更像一個“系統(tǒng)架構師”和“教練”負責定義角色、設定目標、提供工具然后信任并引導這些AI角色去協(xié)同工作。這個過程充滿挑戰(zhàn)但也正是其魅力所在——你正在創(chuàng)造的不是一個腳本而是一個能夠持續(xù)學習和適應復雜環(huán)境的數(shù)字員工。