人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习【免费下载链接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent开发、运行、调优与演进相关的全套SDK能力。项目地址https://gitcode.com/openJiuwen/agent-core-java点击查看免费下载本文聚焦 openJiuwen agent-core-javacom.openjiuwen.agentteams团队协作框架中的Teammate团队成员系统提示词策略。该策略定义了在 Leader-Teammate 团队模式下成员如何自主领取任务、独立制定执行方案、通过send_message横向协作并完成高质量交付。读完本文你将完整掌握 Teammate 的工作流程、任务状态机、通知与通信协议、worktree 与共享文件锁协作规则并能在源码层面印证每一项约定背后的实现机制。一、Teammate 策略的定位与 Leader 的分工边界在agentteams的多智能体团队模型中团队由两类角色构成TeamLeader项目负责人与Teammate领域专家成员。角色策略文件分别存放在Teammate 策略本文主题teammate_policy.mdLeader 策略leader_policy.md系统提示词组装模板system_prompt.md两者的分工边界非常清晰Leader 定义做什么和为什么做Teammate 决定怎么做。Leader 只负责目标拆解、成员组建、信息枢纽与质量把关并明确禁止认领和执行任务而 Teammate 不是等待指令的执行者而是能自主思考、主动协作的专业人才。从源码看这套角色提示词通过 AgentTeamPolicy.java 加载并按语言注入系统提示词rolePolicy(role, language)根据TeamRole.LEADER加载leader_policy否则加载teammate_policy最终由 system_prompt.md 中的占位符{{role_policy}}拼装成完整的成员提示词。测试用例 PolicyCompatibilityTest.java 专门验证了 Teammate 策略中必须包含view_task等任务流程关键词确保与 Python 版本策略行为一致。二、Teammate 的核心理念与核心职责核心理念领任务后独立决策策略开篇即定义了成员的自我认知Leader 定义了做什么你来决定怎么做。领取任务后成员应当独立分析需求、制定计划、执行交付遇到问题先尝试自己解决或与相关成员协调只有真正超出能力范围的决策才升级给 Leader。五项核心职责职责说明自主领取用view_task查看任务主动领取与自身专长匹配的任务独立规划领取任务后自行分析需求、制定执行方案高质量交付按任务中的验收标准完成工作主动协作与其他成员直接沟通协调共享信息和成果不事事经过 Leader 中转关键汇报向 Leader 汇报完成结果和重要决策而非每个执行细节这五项职责对应源码中的角色工具集合。在 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 天然无法调用create_task、spawn_member等管理类工具——它只能认领和执行这正是成员不等待指令与成员不越权管理双重要求在工具层的同时落地。三、Teammate 九步工作流程详解策略给出了成员端到端的工作流程用view_task查看可领取任务领取前判断评估任务是否与自己的领域专长匹配只领取属于自己专业领域的任务或收到明确指派的任务不匹配的任务原则上留给更合适的成员——但若某任务长时间无人认领且处于你能力边缘应主动认领或send_message请 Leader 重新分配避免 DAG 僵死用claim_task(statusclaimed)领取任务分析任务目标和验收标准制定执行方案执行任务——过程中自主决策技术细节需要与其他成员协调时直接联系对方。任务跨度大多阶段或长耗时时在关键里程碑send_message向 Leader 同步一次阶段性进展完成后用claim_task(statuscompleted)标记完成用send_message向 Leader 发送完成汇报附结果摘要汇报一次即结束不要为致谢/确认消息再次回复客套话继续用view_task领取下一个任务如果没有可领取的任务且手头无进行中的工作停下来等待——系统会在新任务就绪或收到消息时主动通知你不要反复轮询view_task。源码视角view_task 与 claim_task 的语义view_task工具TeamTools.java 中ViewTaskTool支持三种actionactionget按task_id查询单个任务详情actionlist按可选status过滤列出任务statusclaimable会展开为pending状态任务actionclaimable直接列出当前可认领任务getClaimableTasks()。claim_task工具ClaimTaskTool的status枚举只有claimed与completed两个取值。在认领时TeamTaskManager.claimResultTeamTaskManager.java会执行多重校验任务必须处于pending状态才能认领任务未被他人认领assignee为空同一成员同时只能持有一个 claimed 任务必须完成当前任务后才能认领下一个——这是源码中明确的防止任务囤积task hogging约束。任务完成后会发布TASK_COMPLETED事件框架随即自动检查依赖图并发布TASK_UNBLOCKED事件唤醒依赖该任务的后续任务publishUnblockedEvents逻辑这正是 DAG 依赖驱动的被动唤醒机制。四、任务状态流转与状态机约束策略定义的任务状态集合为pending / blocked / claimed / plan_approved / completed / cancelled并给出三条硬约束只能认领statuspending且无 assignee 的任务claim_task(statusclaimed)任务内容被 Leaderupdate_task修改时会自动重置为 pending成员认领被撤销completed和cancelled是终态不可再转换。这些约束在源码中得到完整实现任务数据结构 TeamTask.java 携带taskId / teamName / title / content / status / assignee / updatedAt / dependenciesstatus默认值为pending创建带依赖的任务时初始状态为blockedcreateTask逻辑dependencies非空则blocked否则pendingclaimResult仅允许从pending认领completeResult仅允许从claimed或plan_approved完成updateTaskResult仅允许编辑pending / blocked状态的任务内容修改会重置认领TeamTaskManager的事件发布机制TASK_CREATED / TASK_CLAIMED / TASK_COMPLETED / TASK_CANCELLED / TASK_UNBLOCKED驱动整个状态机的流转与成员唤醒。另外在 plan_mode 下还有一个中间态plan_approved。从 team_plan_mode.md 与源码approvePlanResult可以看到plan_mode 复用同一套状态机——成员提交计划时任务变为claimedLeaderapprove_plan批准后进入plan_approved才能执行拒绝则停留在claimed允许成员修订后重新提交。TeamTaskManager.completeResult也专门校验plan_mode 成员只能完成plan_approved状态的任务。五、通知机制事件驱动禁止轮询策略反复强调无需主动轮询当有新任务就绪、新消息到达时系统会主动通知成员如果当前没有可领取的任务也没有进行中的工作停下来等待通知成员只需在收到通知后做出响应。这一约定与 Leader 策略中的事件驱动不轮询原则一致。从源码看其支撑机制是消息总线与事件发布TeamTaskManager在任务创建、认领、完成、取消、解除阻塞时都会通过messager.publish发布TeamEvent事件团队成员通过事件回调被唤醒而不需要反复调用view_task查询。对 LLM 而言这能显著降低无效工具调用带来的 token 开销与空转风险。六、通信协议send_message 是唯一通信方式策略对成员间通信有严格约定send_message是团队成员间唯一的通信方式面向用户的对话除外所有成员间的信息传递都必须通过此工具完成to*表示广播全员消息分为单播消息来自特定成员与广播消息全员通知新消息自动推送处理后自动标记已读无需手动操作优先横向协调需要与其他成员配合时参考团队成员列表直接联系对方无需 Leader 中转遇到方向性阻塞需求不清晰、目标冲突时升级给 Leader技术层面的问题优先自行解决或与相关成员协商若协商陷入僵局双方无法达成一致视为方向性阻塞升级 Leader 裁决。源码视角消息数据结构与发送实现消息结构定义在 TeamMessage.javamessageId / teamName / fromMemberName / toMemberName / content / timestamp / isBroadcast / isRead。其中isBroadcast用于区分广播与单播。SendMessageToolTeamTools.java的调用参数为to接收方成员名或*、content消息正文、可选summary摘要。实现细节值得注意to支持按member_name或display_name解析接收方发送前会自动拉起auto-start所有 UNSTARTED 状态的成员保证消息能送达消息本身只进入邮箱mailbox不会折叠进成员的启动提示词中广播to*的开销与团队规模成正比因此 Leader 策略也建议优先单播定向沟通仅将广播用于全局决策、约束变更或必须全员知晓的公告。七、代码与文件协作worktree 隔离与共享文件锁当多个成员并行修改同一仓库时策略给出了三种协作模式场景约定工具代码修改涉及修改项目代码的任务开始前用enter_worktree进入独立 worktree 副本完成后exit_worktree改动与其他成员隔离、互不冲突enter_worktree/exit_worktree共享文件写入多成员协作修改.team/下的共享文件时写入前用workspace_meta(actionlock)获取独占锁写完后unlockLock 是协作约定write_file不会自动检查锁workspace_meta只读或探索纯读取或探索性工作不需要 worktree也不需要 lock—源码视角worktree 与 workspace_metaEnterWorktreeTool/ExitWorktreeTool成员专属工具enter_worktree创建或进入隔离的 git worktree 副本并切换工作目录返回worktree_path与worktree_branchexit_worktree支持actionkeep|remove与discard_changes决定保留还是销毁 worktree 及变更。WorkspaceMetaTool共享工具action支持lock / unlock / locks / history。lock需要指定 workspace 相对路径获取独占文件锁unlock释放锁locks列出当前所有锁含持有者与过期时间history查看文件版本历史。策略中特别注明Lock 是协作约定write_file不会自动检查锁——即锁的约束力来自成员遵守提示词纪律而非文件系统强制。八、协作精神团队目标高于个人任务策略在最后强调成员应有的协作姿态成员与其他成员拥有共同的团队目标个人任务是达成目标的一部分主动关注上下游任务完成后及时通知依赖方发现其他成员可能需要的信息时主动分享遇到跨领域问题时与相关成员协商解决而非独自猜测。这与 Leader 策略成员 idle 是正常状态的响应节奏形成闭环团队成员基于事件被唤醒以主动认领 横向协作 里程碑汇报的方式驱动任务 DAG 推进而不会陷入反复轮询或 Leader 微管理。九、执行模式build_mode 与 plan_mode 下的 TeammateTeammate 的行为还受执行模式影响提示词通过 TeamRail.java 中的buildTeamRoleSection注入build_mode默认成员领取任务后自主执行并直接标记完成无需 Leader 审批计划此时approve_plan / approve_tool / submit_plan工具不会被创建plan_mode成员领取任务后必须先通过submit_plan提交执行计划等待 Leaderapprove_plan审批通过任务进入plan_approved后才能开始执行。plan_mode 的完整规则见 team_plan_mode.md团队规划专家提示词见 team_plan_agent.md。在TeamTools.createTeamTools中teammateMode参数决定是否注入submit_plan工具、Leader 是否拥有approve_plan / approve_tool工具——即执行模式是编译到工具集层面的硬约束而非仅靠提示词约束。十、实践建议与常见误区规避结合策略文本与源码实现使用 Teammate 模式时有几点实践建议不要抢占不匹配的任务认领前先用view_task(actionclaimable)评估领域匹配度对长时间无人认领且在自己能力边缘的任务主动认领或请求 Leader 重分配防止 DAG 僵死。一个时刻只持有一个进行中任务源码强制同时只能有一个 claimed 任务完成当前任务后再认领下一个避免任务囤积导致的协作阻塞。不要对 Leader 进行执行细节轰炸只在关键里程碑同步一次进展完成时汇报结果摘要为致谢/确认消息反复回复只会增加无效通信。不要反复轮询任务列表依赖事件通知机制收到通知后再响应可显著降低无效工具调用。写共享文件前务必 lock改代码前务必进入 worktree锁与 worktree 是并发安全的协作约定遵守与否直接影响多成员并行修改的隔离效果。结语Teammate 策略是 openJiuwen agent-core-java 团队协作框架中成员侧的执行公约它以自主规划、独立执行、横向协作、关键汇报为核心配合任务状态机、事件通知、worktree 隔离与共享文件锁等基础设施让多名领域专家成员能在 Leader 的目标牵引下并行、有序地交付。本文所引源码TeamTools.java、TeamTaskManager.java、TeamRail.java可作为进一步研究其实现细节的入口。赞分享人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习【免费下载链接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent开发、运行、调优与演进相关的全套SDK能力。项目地址https://gitcode.com/openJiuwen/agent-core-java点击查看免费下载相关推荐openJiuwen agent-core-java 智能体团队快速构建指南基于 LeaderTeammateAgentTeam 的多智能体协作实战openJiuwen agent core java 智能体团队快速构建指南基于 LeaderTeammateAgentTeam 的多智能体协作实战 本文是人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习openJiuwen AgentTeams 智能体团队框架详解Leader-Teammate 协作、持久化恢复与团队技能演进实战指南openJiuwen AgentTeams 智能体团队框架详解Leader Teammate 协作、持久化恢复与团队技能演进实战指南 openJiuwen a人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习openJiuwen agent-core HITT 模式实战让真实人类以团队成员身份参与 Agent 团队协作openJiuwen agent core HITT 模式实战让真实人类以团队成员身份参与 Agent 团队协作 Human In The TeamHITT人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考