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