人工智能AI AgentAgent 框架工具調(diào)用Agent 工作流RAGMCP Clients強(qiáng)化學(xué)習(xí)【免費(fèi)下載鏈接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent開發(fā)、運(yùn)行、調(diào)優(yōu)與演進(jìn)相關(guān)的全套SDK能力。項(xiàng)目地址https://gitcode.com/openJiuwen/agent-core-java點(diǎn)擊查看免費(fèi)下載本文聚焦 openJiuwen agent-core-javacom.openjiuwen.agentteams團(tuán)隊協(xié)作框架中的Teammate團(tuán)隊成員系統(tǒng)提示詞策略。該策略定義了在 Leader-Teammate 團(tuán)隊模式下成員如何自主領(lǐng)取任務(wù)、獨(dú)立制定執(zhí)行方案、通過send_message橫向協(xié)作并完成高質(zhì)量交付。讀完本文你將完整掌握 Teammate 的工作流程、任務(wù)狀態(tài)機(jī)、通知與通信協(xié)議、worktree 與共享文件鎖協(xié)作規(guī)則并能在源碼層面印證每一項(xiàng)約定背后的實(shí)現(xiàn)機(jī)制。一、Teammate 策略的定位與 Leader 的分工邊界在agentteams的多智能體團(tuán)隊模型中團(tuán)隊由兩類角色構(gòu)成TeamLeader項(xiàng)目負(fù)責(zé)人與Teammate領(lǐng)域?qū)＜页蓡T。角色策略文件分別存放在Teammate 策略本文主題teammate_policy.mdLeader 策略leader_policy.md系統(tǒng)提示詞組裝模板system_prompt.md兩者的分工邊界非常清晰Leader 定義做什么和為什么做Teammate 決定怎么做。Leader 只負(fù)責(zé)目標(biāo)拆解、成員組建、信息樞紐與質(zhì)量把關(guān)并明確禁止認(rèn)領(lǐng)和執(zhí)行任務(wù)而 Teammate 不是等待指令的執(zhí)行者而是能自主思考、主動協(xié)作的專業(yè)人才。從源碼看這套角色提示詞通過 AgentTeamPolicy.java 加載并按語言注入系統(tǒng)提示詞rolePolicy(role, language)根據(jù)TeamRole.LEADER加載leader_policy否則加載teammate_policy最終由 system_prompt.md 中的占位符{{role_policy}}拼裝成完整的成員提示詞。測試用例 PolicyCompatibilityTest.java 專門驗(yàn)證了 Teammate 策略中必須包含view_task等任務(wù)流程關(guān)鍵詞確保與 Python 版本策略行為一致。二、Teammate 的核心理念與核心職責(zé)核心理念領(lǐng)任務(wù)后獨(dú)立決策策略開篇即定義了成員的自我認(rèn)知Leader 定義了做什么你來決定怎么做。領(lǐng)取任務(wù)后成員應(yīng)當(dāng)獨(dú)立分析需求、制定計劃、執(zhí)行交付遇到問題先嘗試自己解決或與相關(guān)成員協(xié)調(diào)只有真正超出能力范圍的決策才升級給 Leader。五項(xiàng)核心職責(zé)職責(zé)說明自主領(lǐng)取用view_task查看任務(wù)主動領(lǐng)取與自身專長匹配的任務(wù)獨(dú)立規(guī)劃領(lǐng)取任務(wù)后自行分析需求、制定執(zhí)行方案高質(zhì)量交付按任務(wù)中的驗(yàn)收標(biāo)準(zhǔn)完成工作主動協(xié)作與其他成員直接溝通協(xié)調(diào)共享信息和成果不事事經(jīng)過 Leader 中轉(zhuǎn)關(guān)鍵匯報向 Leader 匯報完成結(jié)果和重要決策而非每個執(zhí)行細(xì)節(jié)這五項(xiàng)職責(zé)對應(yīng)源碼中的角色工具集合。在 TeamTools.java 中工具按角色做了嚴(yán)格過濾MEMBER_ONLY_TOOLSclaim_task、enter_worktree、exit_worktree、submit_planSHARED_TOOLSview_task、send_message、workspace_metaLeader 與成員共享LEADER_ONLY_TOOLSbuild_team、clean_team、spawn_member、shutdown_member、approve_plan、approve_tool、create_task、update_task、list_members。也就是說Teammate 天然無法調(diào)用create_task、spawn_member等管理類工具——它只能認(rèn)領(lǐng)和執(zhí)行這正是成員不等待指令與成員不越權(quán)管理雙重要求在工具層的同時落地。三、Teammate 九步工作流程詳解策略給出了成員端到端的工作流程用view_task查看可領(lǐng)取任務(wù)領(lǐng)取前判斷評估任務(wù)是否與自己的領(lǐng)域?qū)ｉL匹配只領(lǐng)取屬于自己專業(yè)領(lǐng)域的任務(wù)或收到明確指派的任務(wù)不匹配的任務(wù)原則上留給更合適的成員——但若某任務(wù)長時間無人認(rèn)領(lǐng)且處于你能力邊緣應(yīng)主動認(rèn)領(lǐng)或send_message請 Leader 重新分配避免 DAG 僵死用claim_task(statusclaimed)領(lǐng)取任務(wù)分析任務(wù)目標(biāo)和驗(yàn)收標(biāo)準(zhǔn)制定執(zhí)行方案執(zhí)行任務(wù)——過程中自主決策技術(shù)細(xì)節(jié)需要與其他成員協(xié)調(diào)時直接聯(lián)系對方。任務(wù)跨度大多階段或長耗時時在關(guān)鍵里程碑send_message向 Leader 同步一次階段性進(jìn)展完成后用claim_task(statuscompleted)標(biāo)記完成用send_message向 Leader 發(fā)送完成匯報附結(jié)果摘要匯報一次即結(jié)束不要為致謝/確認(rèn)消息再次回復(fù)客套話繼續(xù)用view_task領(lǐng)取下一個任務(wù)如果沒有可領(lǐng)取的任務(wù)且手頭無進(jìn)行中的工作停下來等待——系統(tǒng)會在新任務(wù)就緒或收到消息時主動通知你不要反復(fù)輪詢view_task。源碼視角view_task 與 claim_task 的語義view_task工具TeamTools.java 中ViewTaskTool支持三種actionactionget按task_id查詢單個任務(wù)詳情actionlist按可選status過濾列出任務(wù)statusclaimable會展開為pending狀態(tài)任務(wù)actionclaimable直接列出當(dāng)前可認(rèn)領(lǐng)任務(wù)getClaimableTasks()。claim_task工具ClaimTaskTool的status枚舉只有claimed與completed兩個取值。在認(rèn)領(lǐng)時TeamTaskManager.claimResultTeamTaskManager.java會執(zhí)行多重校驗(yàn)任務(wù)必須處于pending狀態(tài)才能認(rèn)領(lǐng)任務(wù)未被他人認(rèn)領(lǐng)assignee為空同一成員同時只能持有一個 claimed 任務(wù)必須完成當(dāng)前任務(wù)后才能認(rèn)領(lǐng)下一個——這是源碼中明確的防止任務(wù)囤積task hogging約束。任務(wù)完成后會發(fā)布TASK_COMPLETED事件框架隨即自動檢查依賴圖并發(fā)布TASK_UNBLOCKED事件喚醒依賴該任務(wù)的后續(xù)任務(wù)publishUnblockedEvents邏輯這正是 DAG 依賴驅(qū)動的被動喚醒機(jī)制。四、任務(wù)狀態(tài)流轉(zhuǎn)與狀態(tài)機(jī)約束策略定義的任務(wù)狀態(tài)集合為pending / blocked / claimed / plan_approved / completed / cancelled并給出三條硬約束只能認(rèn)領(lǐng)statuspending且無 assignee 的任務(wù)claim_task(statusclaimed)任務(wù)內(nèi)容被 Leaderupdate_task修改時會自動重置為 pending成員認(rèn)領(lǐng)被撤銷completed和cancelled是終態(tài)不可再轉(zhuǎn)換。這些約束在源碼中得到完整實(shí)現(xiàn)任務(wù)數(shù)據(jù)結(jié)構(gòu) TeamTask.java 攜帶taskId / teamName / title / content / status / assignee / updatedAt / dependenciesstatus默認(rèn)值為pending創(chuàng)建帶依賴的任務(wù)時初始狀態(tài)為blockedcreateTask邏輯dependencies非空則blocked否則pendingclaimResult僅允許從pending認(rèn)領(lǐng)completeResult僅允許從claimed或plan_approved完成updateTaskResult僅允許編輯pending / blocked狀態(tài)的任務(wù)內(nèi)容修改會重置認(rèn)領(lǐng)TeamTaskManager的事件發(fā)布機(jī)制TASK_CREATED / TASK_CLAIMED / TASK_COMPLETED / TASK_CANCELLED / TASK_UNBLOCKED驅(qū)動整個狀態(tài)機(jī)的流轉(zhuǎn)與成員喚醒。另外在 plan_mode 下還有一個中間態(tài)plan_approved。從 team_plan_mode.md 與源碼approvePlanResult可以看到plan_mode 復(fù)用同一套狀態(tài)機(jī)——成員提交計劃時任務(wù)變?yōu)閏laimedLeaderapprove_plan批準(zhǔn)后進(jìn)入plan_approved才能執(zhí)行拒絕則停留在claimed允許成員修訂后重新提交。TeamTaskManager.completeResult也專門校驗(yàn)plan_mode 成員只能完成plan_approved狀態(tài)的任務(wù)。五、通知機(jī)制事件驅(qū)動禁止輪詢策略反復(fù)強(qiáng)調(diào)無需主動輪詢當(dāng)有新任務(wù)就緒、新消息到達(dá)時系統(tǒng)會主動通知成員如果當(dāng)前沒有可領(lǐng)取的任務(wù)也沒有進(jìn)行中的工作停下來等待通知成員只需在收到通知后做出響應(yīng)。這一約定與 Leader 策略中的事件驅(qū)動不輪詢原則一致。從源碼看其支撐機(jī)制是消息總線與事件發(fā)布TeamTaskManager在任務(wù)創(chuàng)建、認(rèn)領(lǐng)、完成、取消、解除阻塞時都會通過messager.publish發(fā)布TeamEvent事件團(tuán)隊成員通過事件回調(diào)被喚醒而不需要反復(fù)調(diào)用view_task查詢。對 LLM 而言這能顯著降低無效工具調(diào)用帶來的 token 開銷與空轉(zhuǎn)風(fēng)險。六、通信協(xié)議send_message 是唯一通信方式策略對成員間通信有嚴(yán)格約定send_message是團(tuán)隊成員間唯一的通信方式面向用戶的對話除外所有成員間的信息傳遞都必須通過此工具完成to*表示廣播全員消息分為單播消息來自特定成員與廣播消息全員通知新消息自動推送處理后自動標(biāo)記已讀無需手動操作優(yōu)先橫向協(xié)調(diào)需要與其他成員配合時參考團(tuán)隊成員列表直接聯(lián)系對方無需 Leader 中轉(zhuǎn)遇到方向性阻塞需求不清晰、目標(biāo)沖突時升級給 Leader技術(shù)層面的問題優(yōu)先自行解決或與相關(guān)成員協(xié)商若協(xié)商陷入僵局雙方無法達(dá)成一致視為方向性阻塞升級 Leader 裁決。源碼視角消息數(shù)據(jù)結(jié)構(gòu)與發(fā)送實(shí)現(xiàn)消息結(jié)構(gòu)定義在 TeamMessage.javamessageId / teamName / fromMemberName / toMemberName / content / timestamp / isBroadcast / isRead。其中isBroadcast用于區(qū)分廣播與單播。SendMessageToolTeamTools.java的調(diào)用參數(shù)為to接收方成員名或*、content消息正文、可選summary摘要。實(shí)現(xiàn)細(xì)節(jié)值得注意to支持按member_name或display_name解析接收方發(fā)送前會自動拉起auto-start所有 UNSTARTED 狀態(tài)的成員保證消息能送達(dá)消息本身只進(jìn)入郵箱mailbox不會折疊進(jìn)成員的啟動提示詞中廣播to*的開銷與團(tuán)隊規(guī)模成正比因此 Leader 策略也建議優(yōu)先單播定向溝通僅將廣播用于全局決策、約束變更或必須全員知曉的公告。七、代碼與文件協(xié)作worktree 隔離與共享文件鎖當(dāng)多個成員并行修改同一倉庫時策略給出了三種協(xié)作模式場景約定工具代碼修改涉及修改項(xiàng)目代碼的任務(wù)開始前用enter_worktree進(jìn)入獨(dú)立 worktree 副本完成后exit_worktree改動與其他成員隔離、互不沖突enter_worktree/exit_worktree共享文件寫入多成員協(xié)作修改.team/下的共享文件時寫入前用workspace_meta(actionlock)獲取獨(dú)占鎖寫完后unlockLock 是協(xié)作約定write_file不會自動檢查鎖workspace_meta只讀或探索純讀取或探索性工作不需要 worktree也不需要 lock—源碼視角worktree 與 workspace_metaEnterWorktreeTool/ExitWorktreeTool成員專屬工具enter_worktree創(chuàng)建或進(jìn)入隔離的 git worktree 副本并切換工作目錄返回worktree_path與worktree_branchexit_worktree支持actionkeep|remove與discard_changes決定保留還是銷毀 worktree 及變更。WorkspaceMetaTool共享工具action支持lock / unlock / locks / history。lock需要指定 workspace 相對路徑獲取獨(dú)占文件鎖unlock釋放鎖locks列出當(dāng)前所有鎖含持有者與過期時間history查看文件版本歷史。策略中特別注明Lock 是協(xié)作約定write_file不會自動檢查鎖——即鎖的約束力來自成員遵守提示詞紀(jì)律而非文件系統(tǒng)強(qiáng)制。八、協(xié)作精神團(tuán)隊目標(biāo)高于個人任務(wù)策略在最后強(qiáng)調(diào)成員應(yīng)有的協(xié)作姿態(tài)成員與其他成員擁有共同的團(tuán)隊目標(biāo)個人任務(wù)是達(dá)成目標(biāo)的一部分主動關(guān)注上下游任務(wù)完成后及時通知依賴方發(fā)現(xiàn)其他成員可能需要的信息時主動分享遇到跨領(lǐng)域問題時與相關(guān)成員協(xié)商解決而非獨(dú)自猜測。這與 Leader 策略成員 idle 是正常狀態(tài)的響應(yīng)節(jié)奏形成閉環(huán)團(tuán)隊成員基于事件被喚醒以主動認(rèn)領(lǐng) 橫向協(xié)作 里程碑匯報的方式驅(qū)動任務(wù) DAG 推進(jìn)而不會陷入反復(fù)輪詢或 Leader 微管理。九、執(zhí)行模式build_mode 與 plan_mode 下的 TeammateTeammate 的行為還受執(zhí)行模式影響提示詞通過 TeamRail.java 中的buildTeamRoleSection注入build_mode默認(rèn)成員領(lǐng)取任務(wù)后自主執(zhí)行并直接標(biāo)記完成無需 Leader 審批計劃此時approve_plan / approve_tool / submit_plan工具不會被創(chuàng)建plan_mode成員領(lǐng)取任務(wù)后必須先通過submit_plan提交執(zhí)行計劃等待 Leaderapprove_plan審批通過任務(wù)進(jìn)入plan_approved后才能開始執(zhí)行。plan_mode 的完整規(guī)則見 team_plan_mode.md團(tuán)隊規(guī)劃專家提示詞見 team_plan_agent.md。在TeamTools.createTeamTools中teammateMode參數(shù)決定是否注入submit_plan工具、Leader 是否擁有approve_plan / approve_tool工具——即執(zhí)行模式是編譯到工具集層面的硬約束而非僅靠提示詞約束。十、實(shí)踐建議與常見誤區(qū)規(guī)避結(jié)合策略文本與源碼實(shí)現(xiàn)使用 Teammate 模式時有幾點(diǎn)實(shí)踐建議不要搶占不匹配的任務(wù)認(rèn)領(lǐng)前先用view_task(actionclaimable)評估領(lǐng)域匹配度對長時間無人認(rèn)領(lǐng)且在自己能力邊緣的任務(wù)主動認(rèn)領(lǐng)或請求 Leader 重分配防止 DAG 僵死。一個時刻只持有一個進(jìn)行中任務(wù)源碼強(qiáng)制同時只能有一個 claimed 任務(wù)完成當(dāng)前任務(wù)后再認(rèn)領(lǐng)下一個避免任務(wù)囤積導(dǎo)致的協(xié)作阻塞。不要對 Leader 進(jìn)行執(zhí)行細(xì)節(jié)轟炸只在關(guān)鍵里程碑同步一次進(jìn)展完成時匯報結(jié)果摘要為致謝/確認(rèn)消息反復(fù)回復(fù)只會增加無效通信。不要反復(fù)輪詢?nèi)蝿?wù)列表依賴事件通知機(jī)制收到通知后再響應(yīng)可顯著降低無效工具調(diào)用。寫共享文件前務(wù)必 lock改代碼前務(wù)必進(jìn)入 worktree鎖與 worktree 是并發(fā)安全的協(xié)作約定遵守與否直接影響多成員并行修改的隔離效果。結(jié)語Teammate 策略是 openJiuwen agent-core-java 團(tuán)隊協(xié)作框架中成員側(cè)的執(zhí)行公約它以自主規(guī)劃、獨(dú)立執(zhí)行、橫向協(xié)作、關(guān)鍵匯報為核心配合任務(wù)狀態(tài)機(jī)、事件通知、worktree 隔離與共享文件鎖等基礎(chǔ)設(shè)施讓多名領(lǐng)域?qū)＜页蓡T能在 Leader 的目標(biāo)牽引下并行、有序地交付。本文所引源碼TeamTools.java、TeamTaskManager.java、TeamRail.java可作為進(jìn)一步研究其實(shí)現(xiàn)細(xì)節(jié)的入口。贊分享人工智能AI AgentAgent 框架工具調(diào)用Agent 工作流RAGMCP Clients強(qiáng)化學(xué)習(xí)【免費(fèi)下載鏈接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent開發(fā)、運(yùn)行、調(diào)優(yōu)與演進(jìn)相關(guān)的全套SDK能力。項(xiàng)目地址https://gitcode.com/openJiuwen/agent-core-java點(diǎn)擊查看免費(fèi)下載相關(guān)推薦openJiuwen agent-core-java 智能體團(tuán)隊快速構(gòu)建指南基于 LeaderTeammateAgentTeam 的多智能體協(xié)作實(shí)戰(zhàn)openJiuwen agent core java 智能體團(tuán)隊快速構(gòu)建指南基于 LeaderTeammateAgentTeam 的多智能體協(xié)作實(shí)戰(zhàn) 本文是人工智能AI AgentAgent 框架工具調(diào)用Agent 工作流RAGMCP Clients強(qiáng)化學(xué)習(xí)openJiuwen AgentTeams 智能體團(tuán)隊框架詳解Leader-Teammate 協(xié)作、持久化恢復(fù)與團(tuán)隊技能演進(jìn)實(shí)戰(zhàn)指南openJiuwen AgentTeams 智能體團(tuán)隊框架詳解Leader Teammate 協(xié)作、持久化恢復(fù)與團(tuán)隊技能演進(jìn)實(shí)戰(zhàn)指南 openJiuwen a人工智能AI AgentAgent 框架大模型工具調(diào)用RAG提示工程強(qiáng)化學(xué)習(xí)openJiuwen agent-core HITT 模式實(shí)戰(zhàn)讓真實(shí)人類以團(tuán)隊成員身份參與 Agent 團(tuán)隊協(xié)作openJiuwen agent core HITT 模式實(shí)戰(zhàn)讓真實(shí)人類以團(tuán)隊成員身份參與 Agent 團(tuán)隊協(xié)作 Human In The TeamHITT人工智能AI AgentAgent 框架大模型工具調(diào)用RAG提示工程強(qiáng)化學(xué)習(xí)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考