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