最近在技術(shù)社區(qū)和開發(fā)者社群里一個看似與代碼無關(guān)的話題被頻繁討論“IG打不過WBG啊theshy1500分有啥用呢也就是宗師守門員Elk加小虎能有4500分” 這句話表面上是電競?cè)Φ墓５绻阕屑氉聊l(fā)現(xiàn)它精準地戳中了當前AI Agent和智能體開發(fā)領(lǐng)域的一個核心痛點單一模型的能力上限遠不如一個高效協(xié)作的“團隊”。在AI技術(shù)快速迭代的今天很多開發(fā)者包括我自己都曾陷入一個誤區(qū)執(zhí)著于尋找或微調(diào)那個“最強”的單一模型希望它能解決所有問題。就像期待一個“1500分”的頂級選手TheShy能一己之力Carry全場。但現(xiàn)實是殘酷的無論是復雜的業(yè)務(wù)系統(tǒng)開發(fā)、多輪對話任務(wù)還是需要結(jié)合代碼生成、邏輯推理和工具調(diào)用的場景單個模型往往力不從心暴露出知識盲區(qū)、邏輯錯誤或工具調(diào)用混亂等問題。反觀“Elk加小虎能有4500分”這個比喻它揭示了一個更優(yōu)的工程化路徑通過角色分工與協(xié)同讓多個“專家級”智能體Agent組成團隊其綜合效能4500分將遠超單個強力模型1500分。這不僅僅是“112”更是架構(gòu)設(shè)計思路的根本轉(zhuǎn)變。本文將深入探討如何將這種“團隊協(xié)作”思想落地到AI應(yīng)用開發(fā)中。我們將不再空談概念而是聚焦于一個能實際運行的多智能體協(xié)作框架——CrewAI。我會帶你從零開始搭建一個模擬“產(chǎn)品經(jīng)理 前端工程師 后端工程師”的智能體開發(fā)團隊完成一個真實的“用戶需求分析到代碼生成”任務(wù)。你會看到清晰的角色定義、任務(wù)編排和協(xié)作流程并得到可直接復用的完整代碼。無論你是想提升現(xiàn)有AI應(yīng)用的可靠性還是探索下一代人機協(xié)作模式這篇文章都將提供一條清晰的實踐路徑。1. 從“單兵作戰(zhàn)”到“團隊協(xié)作”為什么智能體架構(gòu)正在改變在傳統(tǒng)的AI應(yīng)用開發(fā)中我們習慣于與一個“全能”的模型對話。無論是通過OpenAI API調(diào)用GPT-4還是部署一個開源大模型我們都在嘗試讓這一個模型理解需求、拆解任務(wù)、生成代碼、檢查錯誤。這種模式就像在游戲中只操作一個英雄要求他既要對線強勢又要能打野支援還要負責開團和輸出。這種模式的瓶頸非常明顯上下文負擔過重一個任務(wù)描述可能需要包含業(yè)務(wù)背景、技術(shù)棧要求、代碼規(guī)范、安全限制等所有信息極易超出模型的上下文窗口或?qū)е玛P(guān)鍵信息被忽略。角色混淆與幻覺模型需要在“產(chǎn)品思維”、“架構(gòu)思維”、“開發(fā)者思維”之間快速切換容易產(chǎn)生不符合特定角色身份的“幻覺”輸出比如讓一個以生成為主的模型去做嚴謹?shù)拇a審查。缺乏深度與專業(yè)性一個通用模型很難在每一個細分領(lǐng)域如React最佳實踐、Spring Security配置、SQL優(yōu)化都達到專家級深度。任務(wù)流程難以固化每次對話都是獨立的優(yōu)秀的任務(wù)拆解和協(xié)作模式無法沉淀為可復用的流程。而“智能體團隊”的思路則是為不同的子任務(wù)分配合適的“專家”。就像一支真正的開發(fā)團隊產(chǎn)品經(jīng)理Agent專注于理解用戶原始需求進行業(yè)務(wù)分析輸出清晰、無歧義的產(chǎn)品需求文檔PRD。前端專家Agent只關(guān)心如何根據(jù)PRD實現(xiàn)交互界面精通React/Vue等框架和UI庫。后端專家Agent專注于API設(shè)計、數(shù)據(jù)庫建模和業(yè)務(wù)邏輯實現(xiàn)熟悉Spring Boot/Django等后端技術(shù)。每個Agent都在自己最擅長的領(lǐng)域工作通過定義好的協(xié)作規(guī)則如順序執(zhí)行、接力傳遞信息共同完成任務(wù)。CrewAI正是實現(xiàn)這一理念的杰出框架。它不是一個新模型而是一個用于編排多個智能體、任務(wù)和工具的“操作系統(tǒng)”讓開發(fā)者能像組建項目團隊一樣構(gòu)建AI應(yīng)用。2. CrewAI核心概念智能體、任務(wù)與流程在開始動手之前我們需要理解CrewAI的三個核心抽象這對應(yīng)著團隊管理中的基本要素。2.1 智能體Agent你的專家員工一個Agent不再是一個通用的聊天對象而是一個具有特定角色、目標、背景和能力的“員工”。角色Role定義Agent的身份如“資深前端架構(gòu)師”、“嚴謹?shù)暮蠖碎_發(fā)工程師”。這會影響其思考和行為模式。目標Goal該Agent存在的終極目的例如“創(chuàng)建用戶友好、高性能的前端應(yīng)用”。背景Backstory為Agent增加更豐富的背景描述使其性格和能力更鮮明例如“一個對UI細節(jié)有極致追求、熟悉React生態(tài)所有最新特性的開發(fā)者”。工具Tools賦予Agent調(diào)用外部能力的手段如搜索網(wǎng)絡(luò)、查詢數(shù)據(jù)庫、執(zhí)行代碼、讀寫文件等。一個Agent可以擁有多個工具。語言模型LLMAgent的“大腦”。CrewAI支持配置不同的模型給不同的Agent實現(xiàn)成本與性能的最優(yōu)組合例如用GPT-4處理復雜設(shè)計用GPT-3.5-Turbo處理格式化的代碼生成。2.2 任務(wù)Task具體的工作項任務(wù)是具體要執(zhí)行的工作單元它會被分配給一個或多個Agent。描述Description清晰、具體的任務(wù)說明這是Agent工作的直接依據(jù)。預期輸出Expected Output明確說明任務(wù)完成后應(yīng)該交付什么例如“一份包含用戶故事和驗收標準的PRD文檔”、“一個完整的React組件代碼文件”。Agent分配指定由哪個Agent來負責執(zhí)行此任務(wù)。上下文Context一個任務(wù)可以依賴于其他任務(wù)的輸出。CrewAI會自動將上游任務(wù)的輸出作為上下文傳遞給下游任務(wù)實現(xiàn)信息流轉(zhuǎn)。2.3 流程Process團隊的工作方式流程定義了多個Agent如何協(xié)作來完成一系列Task。CrewAI主要支持兩種流程順序流程Sequential任務(wù)按順序依次執(zhí)行后一個任務(wù)依賴前一個任務(wù)的輸出。這是最常見的流程模擬了“需求分析 - 設(shè)計 - 開發(fā) - 測試”的瀑布模型。分層流程Hierarchical一個“管理者”Agent負責協(xié)調(diào)和分配任務(wù)給“執(zhí)行者”Agents適合更復雜的協(xié)作模式。理解了這三個概念我們就可以開始搭建我們的“開發(fā)團隊”了。3. 環(huán)境準備與CrewAI安裝我們將使用Python作為主要語言。請確保你的環(huán)境滿足以下條件前置條件Python 3.10 或更高版本推薦3.11pip 包管理工具一個可用的OpenAI API密鑰或其他CrewAI支持的LLM提供商密鑰如Anthropic、Groq、本地Ollama等安裝步驟創(chuàng)建并激活虛擬環(huán)境強烈推薦# 創(chuàng)建虛擬環(huán)境 python -m venv crewai-env # 激活虛擬環(huán)境 # Windows: crewai-env\Scripts\activate # macOS/Linux: source crewai-env/bin/activate安裝CrewAI核心庫pip install crewai這將會安裝crewai及其核心依賴。安裝可選工具庫 為了讓Agent能力更強我們安裝一些常用的工具庫。例如讓Agent能進行網(wǎng)絡(luò)搜索pip install crewai[tools] # 如果需要使用DuckDuckGo搜索還需要安裝 pip install duckduckgo-search配置API密鑰 將你的OpenAI API密鑰設(shè)置為環(huán)境變量。這是與LLM通信的憑證。# Windows (PowerShell) $env:OPENAI_API_KEY你的-api-key-here # macOS/Linux export OPENAI_API_KEY你的-api-key-here為了持久化你也可以將上述命令添加到shell的配置文件中如.bashrc,.zshrc。環(huán)境準備就緒接下來我們開始定義團隊成員。4. 構(gòu)建你的第一個智能體開發(fā)團隊我們的目標是創(chuàng)建一個能協(xié)作完成“構(gòu)建一個簡易待辦事項Todo List應(yīng)用”的智能體團隊。團隊由三個角色構(gòu)成。首先創(chuàng)建一個名為todo_crew.py的Python文件。4.1 導入依賴與設(shè)置LLM# todo_crew.py import os from crewai import Agent, Task, Crew, Process from crewai_tools import SerperDevTool # 示例一個搜索工具 # 確保已設(shè)置OPENAI_API_KEY環(huán)境變量 # 初始化一個共享的LLM這里使用gpt-4你可以根據(jù)情況替換為gpt-3.5-turbo或其他 from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4, temperature0.7) # 可選初始化工具 search_tool SerperDevTool()4.2 定義三位“專家”智能體我們創(chuàng)建產(chǎn)品經(jīng)理、前端工程師和后端工程師三個Agent。# 1. 產(chǎn)品經(jīng)理 Agent product_manager Agent( role資深產(chǎn)品經(jīng)理, goal深入理解用戶需求并將其轉(zhuǎn)化為清晰、可執(zhí)行的產(chǎn)品需求文檔確保技術(shù)團隊理解業(yè)務(wù)價值。, backstory你是一位擁有10年經(jīng)驗的產(chǎn)品負責人擅長從模糊的用戶描述中提煉核心痛點并定義出簡潔、有深度的產(chǎn)品需求。你厭惡模糊不清的需求堅信好的PRD是項目成功的一半。, verboseTrue, # 讓Agent輸出詳細的思考過程便于調(diào)試 allow_delegationFalse, # 此Agent不允許將任務(wù)委派給其他Agent llmllm, # 使用我們定義的LLM # tools[search_tool] # 如果需要可以賦予其搜索工具來調(diào)研競品 ) # 2. 前端工程師 Agent frontend_engineer Agent( roleReact前端架構(gòu)師, goal根據(jù)產(chǎn)品需求文檔設(shè)計并實現(xiàn)美觀、響應(yīng)式、高性能的前端用戶界面。, backstory你是React生態(tài)的專家對Hooks、狀態(tài)管理Redux/Zustand、現(xiàn)代CSS方案Tailwind CSS, Styled-Components了如指掌。你追求極致的用戶體驗和代碼優(yōu)雅。, verboseTrue, allow_delegationFalse, llmllm, ) # 3. 后端工程師 Agent backend_engineer Agent( roleNode.js后端開發(fā)專家, goal根據(jù)產(chǎn)品需求文檔和前端接口約定設(shè)計穩(wěn)健的RESTful API、數(shù)據(jù)模型和業(yè)務(wù)邏輯。, backstory你專注于用Node.js和Express或NestJS構(gòu)建可擴展的后端服務(wù)。你對數(shù)據(jù)庫設(shè)計MongoDB/PostgreSQL、API安全JWT、錯誤處理和性能優(yōu)化有豐富的實戰(zhàn)經(jīng)驗。, verboseTrue, allow_delegationFalse, llmllm, )關(guān)鍵參數(shù)解釋verboseTrue在控制臺輸出Agent的思考鏈Chain-of-Thought這對于理解其決策過程和調(diào)試至關(guān)重要。allow_delegation如果設(shè)置為True該Agent在認為自己無法完成時可以請求其他Agent協(xié)助。在簡單順序流程中我們先關(guān)閉它。llm可以全局共享一個也可以為每個Agent單獨配置不同的模型實現(xiàn)成本優(yōu)化。4.3 創(chuàng)建具體的工作任務(wù)Task任務(wù)需要具體、可交付。我們定義三個任務(wù)形成工作流。# 定義任務(wù) # 任務(wù)1需求分析 (由產(chǎn)品經(jīng)理執(zhí)行) task_analyze Task( description分析以下用戶需求并撰寫一份產(chǎn)品需求文檔PRD。 用戶需求“我想要一個網(wǎng)頁版的待辦事項列表應(yīng)用可以添加任務(wù)、標記完成、刪除任務(wù)最好能按日期篩選。希望界面簡潔現(xiàn)代?！?你的PRD應(yīng)包含 1. 項目概述與目標用戶。 2. 核心用戶故事User Stories。 3. 功能特性列表Feature List。 4. 非功能性需求如性能、響應(yīng)式設(shè)計。 5. 提供給技術(shù)團隊的初步建議如建議的技術(shù)棧。 , expected_output一份結(jié)構(gòu)完整、細節(jié)清晰的產(chǎn)品需求文檔Markdown格式。, agentproduct_manager, # 指定執(zhí)行者 ) # 任務(wù)2前端設(shè)計與實現(xiàn) (由前端工程師執(zhí)行依賴任務(wù)1的輸出) task_frontend Task( description根據(jù)產(chǎn)品經(jīng)理提供的產(chǎn)品需求文檔PRD完成以下工作 1. 設(shè)計并實現(xiàn)一個單頁應(yīng)用SPA的Todo List主界面。 2. 使用React函數(shù)組件和Hooks。 3. 實現(xiàn)以下功能組件 - 任務(wù)輸入框和添加按鈕。 - 任務(wù)列表展示每個任務(wù)項包含復選框、文本、刪除按鈕。 - 狀態(tài)篩選器全部/未完成/已完成。 4. 使用內(nèi)聯(lián)樣式或簡單的CSS保證界面整潔。 5. 在代碼中提供清晰的注釋。 請輸出完整的React組件代碼。假設(shè)后端API已就緒使用模擬數(shù)據(jù)一個todos數(shù)組進行開發(fā)。, expected_output一個完整的、可運行的React組件代碼文件.jsx或.js包含所有UI和交互邏輯。, agentfrontend_engineer, context[task_analyze], # 關(guān)鍵此任務(wù)依賴task_analyze的輸出 ) # 任務(wù)3后端API設(shè)計 (由后端工程師執(zhí)行依賴任務(wù)1的輸出) task_backend Task( description根據(jù)產(chǎn)品經(jīng)理提供的產(chǎn)品需求文檔PRD完成以下工作 1. 設(shè)計Todo List應(yīng)用的RESTful API接口包括路徑、方法、請求體、響應(yīng)體。 2. 定義任務(wù)Todo的數(shù)據(jù)模型字段列表及類型。 3. 使用Node.js和Express框架編寫核心API路由的偽代碼或簡要實現(xiàn)包括 - GET /api/todos - 獲取任務(wù)列表支持篩選參數(shù) - POST /api/todos - 創(chuàng)建新任務(wù) - PUT /api/todos/:id - 更新任務(wù)如標記完成 - DELETE /api/todos/:id - 刪除任務(wù) 4. 考慮簡單的錯誤處理如資源未找到。 請輸出API設(shè)計文檔Markdown格式以及核心的Node.js/Express代碼片段。, expected_output一份API設(shè)計文檔和核心的后端路由實現(xiàn)代碼片段。, agentbackend_engineer, context[task_analyze], # 依賴產(chǎn)品需求文檔 )關(guān)鍵設(shè)計context[task_analyze]這是實現(xiàn)協(xié)作的靈魂。它告訴CrewAItask_frontend和task_backend需要等待task_analyze完成并將其輸出內(nèi)容作為自己任務(wù)描述的一部分傳入。這樣前端和后端工程師就能基于同一份PRD工作避免了信息不一致。4.4 組建團隊并設(shè)定流程將Agent和Task組裝成Crew并指定協(xié)作流程。# 組建團隊 todo_crew Crew( agents[product_manager, frontend_engineer, backend_engineer], tasks[task_analyze, task_frontend, task_backend], processProcess.sequential, # 使用順序流程需求分析 - 前端開發(fā) - 后端開發(fā) verbose2, # 設(shè)置Crew的詳細輸出級別2為詳細 ) # 運行團隊執(zhí)行任務(wù) result todo_crew.kickoff()5. 運行團隊與結(jié)果分析在終端運行我們的腳本python todo_crew.py你會看到類似以下的詳細輸出展示了多智能體協(xié)作的完整思考過程# 產(chǎn)品經(jīng)理開始思考... [資深產(chǎn)品經(jīng)理] 思考用戶需要一個網(wǎng)頁版Todo應(yīng)用核心功能是CRUD和篩選。我需要先明確目標用戶可能是個人或小團隊... [資深產(chǎn)品經(jīng)理] 行動我將開始撰寫PRD首先概述項目... # ... 產(chǎn)品經(jīng)理輸出完整的PRD Markdown ... # PRD自動傳遞給前端工程師... [React前端架構(gòu)師] 思考我收到了產(chǎn)品經(jīng)理的PRD。需求很清晰我需要一個包含添加、列表、篩選的React組件。我會使用useState管理狀態(tài)用map渲染列表... [React前端架構(gòu)師] 行動我將編寫一個名為TodoApp的React函數(shù)組件... # ... 前端工程師輸出完整的React代碼 ... # PRD自動傳遞給后端工程師... [Node.js后端開發(fā)專家] 思考基于同一份PRD我需要設(shè)計對應(yīng)的API。一個Todo對象應(yīng)該有id, title, completed, createdAt等字段... [Node.js后端開發(fā)專家] 行動我將先定義數(shù)據(jù)模型然后設(shè)計RESTful端點... # ... 后端工程師輸出API文檔和代碼片段 ... # CrewAI 最終匯總輸出 print(result)result變量包含了整個流程的最終輸出。默認是最后一個任務(wù)的輸出即后端API設(shè)計。但更重要的是在整個過程中信息流是自動傳遞的。前端和后端工程師接收到的任務(wù)描述里已經(jīng)包含了產(chǎn)品經(jīng)理產(chǎn)出的具體PRD內(nèi)容他們是在此基礎(chǔ)上進行工作的。6. 進階優(yōu)化協(xié)作與處理復雜場景基礎(chǔ)的順序流程已經(jīng)能解決很多問題。但在真實項目中協(xié)作往往更復雜。6.1 獲取每個任務(wù)的獨立輸出你可能需要查看每一個任務(wù)的產(chǎn)出而不僅僅是最后一個?？梢栽谶\行后通過Task對象獲取# 運行crew todo_crew.kickoff() # 獲取每個任務(wù)的輸出 print(\n 產(chǎn)品需求文檔 ) print(task_analyze.output.raw) # 訪問任務(wù)的原始輸出 print(\n 前端組件代碼 ) print(task_frontend.output.raw) print(\n 后端API設(shè)計 ) print(task_backend.output.raw)6.2 實現(xiàn)異步與部分并行如果前端和后端任務(wù)互不依賴可以讓他們并行執(zhí)行。這需要用到hierarchical流程或更精細的任務(wù)async_execution配置。一個簡單的改進是創(chuàng)建兩個獨立的順序Crew然后并行運行使用asyncio。但更優(yōu)雅的方式是使用CrewAI的Process.hierarchical并定義一個manager_agent來協(xié)調(diào)。6.3 為Agent裝備實用工具真正的專家需要工具。例如讓產(chǎn)品經(jīng)理能搜索競品分析讓工程師能運行代碼測試。from crewai_tools import FileReadTool, CodeDocsSearchTool # 定義一個讀取文件內(nèi)容的工具 prd_template_tool FileReadTool(file_path./templates/prd_template.md) # 定義一個搜索代碼文檔的工具如React官方文檔 react_docs_tool CodeDocsSearchTool(docs_urlhttps://react.dev/reference/react) # 將工具賦予Agent frontend_engineer_with_tools Agent( roleReact前端架構(gòu)師, goal..., backstory..., tools[react_docs_tool], # 裝備工具 llmllm, verboseTrue )當任務(wù)描述中涉及不確定的API用法時Agent可以主動調(diào)用react_docs_tool去查詢最新文檔確保生成代碼的準確性。6.4 使用本地模型降低成本如果你使用Ollama在本地運行開源模型如Llama 3, Qwen2.5可以輕松切換減少API成本。from langchain_community.chat_models import ChatOllama local_llm ChatOllama(modelllama3:8b, base_urlhttp://localhost:11434) simple_agent Agent( role助理, goal..., backstory..., llmlocal_llm, # 使用本地LLM verboseTrue )7. 常見問題與排查思路在實踐CrewAI多智能體協(xié)作時你可能會遇到以下典型問題問題現(xiàn)象可能原因排查方式解決方案運行時報錯OPENAI_API_KEY not found環(huán)境變量未正確設(shè)置在Python腳本中打印os.getenv(‘OPENAI_API_KEY’)確保在運行腳本的終端環(huán)境中已設(shè)置并導出OPENAI_API_KEY。Agent輸出內(nèi)容空洞或偏離主題1. 角色/目標定義模糊2. 任務(wù)描述不夠具體3. Temperature參數(shù)過高1. 檢查Agent的role,goal,backstory是否足夠清晰有約束力。2. 檢查Task的description是否包含具體輸出要求。3. 將LLM的temperature調(diào)低如0.1-0.3。細化Agent定義賦予更專業(yè)的背景。任務(wù)描述使用“請輸出...”、“包含以下章節(jié)...”等明確指令。調(diào)整LLM參數(shù)。下游任務(wù)未接收到上游任務(wù)的輸出1. 未在Task中設(shè)置context依賴2. 流程Process類型不支持自動傳遞1. 檢查下游Task的context參數(shù)是否包含了上游Task對象。2. 確認使用的是Process.sequential。確保在定義Task時通過context[upstream_task]建立依賴關(guān)系。運行速度很慢或消耗大量Token1. 使用的LLM模型較大如GPT-42.verbose模式輸出大量思考過程3. 任務(wù)描述或上下文過長1. 觀察每個步驟的耗時和Token使用量可在OpenAI后臺查看。2. 關(guān)閉或降低verbose級別。3. 簡化任務(wù)描述或讓Agent先輸出摘要。對非核心Agent使用更快的模型如GPT-3.5-Turbo。生產(chǎn)環(huán)境將verbose設(shè)為False。優(yōu)化提示詞減少冗余信息。Agent試圖調(diào)用未安裝的工具Tool的依賴庫未安裝查看錯誤信息確認缺少哪個Python包。根據(jù)crewai_tools文檔或錯誤提示安裝對應(yīng)的工具包。例如pip install duckduckgo-search。8. 最佳實踐與工程化建議將多智能體協(xié)作應(yīng)用于真實項目需要遵循一些工程最佳實踐模塊化定義不要將所有Agent和Task寫在一個巨型文件中。可以將Agent定義、Task定義、Crew組裝分別放在不同的Python模塊中提高可維護性。提示詞工程role,goal,backstory以及Task的description都是關(guān)鍵的“提示詞”。迭代優(yōu)化它們比調(diào)整代碼更能提升輸出質(zhì)量。可以將其抽取到配置文件如YAML或數(shù)據(jù)庫中管理。輸出規(guī)范化在expected_output中明確要求輸出格式如JSON、Markdown、特定代碼語言。這能極大提高下游程序自動化處理結(jié)果的能力。成本與性能監(jiān)控在生產(chǎn)環(huán)境中記錄每個Task消耗的Token數(shù)、耗時和使用的模型。這有助于優(yōu)化流程和成本控制?？梢钥紤]為不同的Task配置不同價位的LLM。人機協(xié)同與審核不要期望全自動流程一次完美。將智能體團隊視為強大的“初級助理”或“頭腦風暴伙伴”。重要的輸出如架構(gòu)設(shè)計、核心代碼應(yīng)加入人工審核環(huán)節(jié)。可以在Crew流程中插入一個“人類審核”Task需要特殊配置。錯誤處理與重試網(wǎng)絡(luò)或API調(diào)用可能失敗。為Crew的執(zhí)行添加重試機制和異常捕獲確保部分失敗不影響整體流程的穩(wěn)定性。版本控制與實驗像管理代碼一樣管理你的Agent和Task定義。使用Git進行版本控制便于回滾和對比不同提示詞版本的效果?；氐轿覀冮_頭提到的“4500分團隊”比喻。通過CrewAI這樣的框架我們不再是依賴一個“全能但可能過載”的1500分模型而是組建了一個由多個“專精”角色組成的、總分更高的協(xié)作團隊。產(chǎn)品經(jīng)理、前端、后端各司其職信息通過context自動流轉(zhuǎn)這不僅大幅提升了復雜任務(wù)完成的可靠性和質(zhì)量更將開發(fā)者的角色從“與模型對話的提示詞工程師”提升到了“智能團隊架構(gòu)師與管理者”。你可以基于這個Todo應(yīng)用的例子進行擴展嘗試構(gòu)建更復雜的團隊如加入“測試工程師Agent”來編寫單元測試加入“運維工程師Agent”來生成Dockerfile和部署腳本。智能體協(xié)作的邊界正由你的工程想象力決定。