人工智能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 中 Agent Teams 的**临时团队temporary**生命周期收尾机制展开剖析内置 Leader 提示词模板lifecycle_temporary.md的语义、shutdown_member与clean_team两个收尾工具的底层实现以及配套的状态机与完成判定逻辑。读完本文你将掌握临时团队从任务完成、成果汇总到成员关闭、团队解散的完整收尾链路并能在自己的多智能体应用中正确、高效地编排团队生命周期。什么是临时团队一次任务、一次生命周期在 openJiuwen agent-core-java 的com.openjiuwen.agentteams包中团队的生命周期模式由TeamAgentSpec.lifecycle字段声明默认值即为temporary见 TeamAgentSpec.java。也就是说不加显式声明创建的团队天然是一次性团队它围绕某次具体任务临时组建任务完成后就地解散不长期驻留。与它相对的是persistent长期团队——完成任务后保持运行、进入待命状态等待新指令不关闭成员也不解散团队见 lifecycle_persistent.md。两者在 Leader 的系统提示词中占据同一位置、由同一套装配逻辑按lifecycle值二选一注入但收尾语义截然相反。这一设计对应到真实场景一个分析财报 → 输出报告的投资分析任务结束后团队没有继续存在的意义应立即回收资源而一个持续服务用户的智能助手团队则应当长期存活。临时团队的价值正是按需组建、用完即毁避免成员进程、KV Cache、共享工作空间等资源长期空转。收尾提示词模板临时团队的行为契约lifecycle_temporary.md是专门注入给 Leader 角色的系统提示词片段全文如下原文位于 lifecycle_temporary.md英文版见 en/lifecycle_temporary.md## 团队性质临时团队 本团队为临时团队在所有任务完成后应解散。完成所有任务后 1. 汇总工作成果 2. 用 shutdown_member 关闭所有成员 3. 用 clean_team 解散团队 **收尾要高效**用 send_message(to*) 一次性广播总结与解散通知后立即执行关闭流程不要逐个成员告别也不要回复成员的致谢/确认消息避免无意义的来回寒暄。这段模板定义了临时团队的三条收尾铁律先汇总、后关闭、再解散成果汇总在成员存活时完成顺序不可颠倒收尾手段固定关闭成员用shutdown_member解散团队用clean_team两个工具都仅 Leader 可调用参见 AgentTeams.md 团队工具集 中 Leader 专属工具清单收尾要高效send_message(to*)一次性广播总结与解散通知随后立即执行关闭流程——禁止逐个成员告别、禁止回复致谢。第三条是刻意设计的协作礼仪约束Agent 团队中每多一轮谢谢/不客气式的寒暄就多一次无意义的 LLM 推理开销。而to*广播则保证全员在同一时刻收到统一信息同时把通信次数压缩到一次。模板如何被注入 Leader 提示词该模板并不是写了就算数的普通文档而是被运行时真实装配进 Leader 系统提示词的动态章节。装配入口是TeamRail.buildTeamLifecycleSection(...)见 TeamRail.java其关键逻辑仅 Leader 注入role ! TeamRole.LEADER时直接返回空 sectionteammate 永远不会看到收尾指令按 lifecycle 二选一persistent.equals(lifecycle)加载lifecycle_persistent否则加载lifecycle_temporary作为独立 PromptSection 存在section 名称为team_lifecycleTeamRail.LIFECYCLE常量与角色策略、工作流程、团队信息等章节按优先级拼接成 Leader 的完整提示词。从源码结构看模板正文与装配逻辑解耦——CLAUDE.md 明确说明Markdown 模板是团队 Agent 的行为契约……改提示词不需要动装配代码新增语言只需在cn/、en/下成对添加翻译文件。收尾第一步汇总工作成果在调用任何关闭工具之前Leader 必须先把本轮协作的成果汇聚成一份可交付的总结。这与团队协作模式的产物约定一致在默认default团队模式下teammate 完成任务后通过send_message向 Leader 发送完成摘要与产物文件路径典型如.team/reports/T*.mdLeader 在收尾前把这些信息归并进最终总结广播语法为send_message(to*)一次调用送达全员同时作为解散前的正式通知。需要注意的是总结必须在shutdown_member之前完成。一旦成员进入关闭流程其 ReAct 循环终止、流关闭不会再处理新消息此时再索要成果为时已晚。收尾第二步shutdown_member 有序关闭成员shutdown_member是临时团队收尾的核心工具其语义定义在工具描述文件 shutdown_member.md 中参数用法member_name要请求关闭的成员 member_name应指向当前团队中的有效成员force是否强制关闭。仅在成员卡死、长期无响应或无法正常收尾时作为兜底使用适用场景成员已完成负责的工作需要有序退出团队收尾需逐个关闭成员后再clean_team成员长时间卡住、无法恢复时可考虑forcetrue。关键语义发起请求而非同步关闭工具描述明确强调这不是立即完成关闭的同步操作而是发起关闭请求。调用后应等待成员真正进入SHUTDOWN再执行clean_team或依赖其已退出的后续操作。forcetrue仅用于异常兜底可能中断未完成工作不应作为常规路径。从实现看TeamBackend.shutdownMember(...) 的调用链为校验成员存在且当前状态允许迁移依赖MemberStatus.canTransitionTo状态机把成员持久化状态置为SHUTDOWN_REQUESTED通过messageManager.sendMessage(...)向该成员发送Shutdown requested by team leader.消息发布MEMBER_SHUTDOWN团队事件驱动成员侧的shutdownSelf()。而成员侧收到事件后见 TeamAgent.shutdownSelf()会依次取消 agent → 关闭流 → 将自身状态更新为SHUTDOWN→ 释放会话 KV Cache → 关闭资源。这一收尾动作在成员自然轮次结束点落定finalizeStreamingRound中执行确保成员完成当前推理后再退出而非被粗暴打断。状态机视角SHUTDOWN_REQUESTED → SHUTDOWNMemberStatus 定义了成员全量状态其中与收尾直接相关的是READY / BUSY / PAUSED / STOPPED→ 允许迁入SHUTDOWN_REQUESTEDSHUTDOWN_REQUESTED→ 只允许迁入SHUTDOWN或ERROR终态前的最后一站。也就是说SHUTDOWN_REQUESTED是一个中间态——它标记Leader 已请求关闭成员正在完成收尾。TeamBackend.isAnyMemberShuttingDown()专门检测这一窗口见 TeamBackend.java当存在SHUTDOWN_REQUESTED成员时StreamController会跳过POLL_MAILBOX派发避免 Leader 在关闭窗口期内被自身事件反复唤醒、空耗 LLM token。内置保护不关仍有任务在身的成员TeamTools.ShutdownMemberTool 在调用后端前有一道守卫若该成员名下仍存在非终态任务非 completed/cancelled默认拒绝关闭并提示Complete, reassign, or cancel them first; or pass forcetrue。原因是关闭一个仍持有 in-flight 任务的成员会使这些任务成为孤儿拖垮整个团队任务 DAG。只有forcetrue才能绕过作为管理员的最后手段。收尾第三步clean_team 解散团队当所有非 Leader 成员都进入SHUTDOWN后Leader 调用clean_team正式解散团队。工具语义见 clean_team.md解散团队并删除所有资源团队记录、成员、任务——级联删除。仅 Leader 可用。重要如果任何成员未处于 SHUTDOWN 状态clean_team 将失败。请先用 shutdown_member 关闭所有成员再调用 clean_team。对应实现 TeamBackend.cleanTeam() 的流程是校验所有非 Leader 成员均为SHUTDOWN任一成员不是SHUTDOWN直接返回失败——这就是为什么必须先shutdown_member再clean_team级联删除团队记录db.team.deleteTeam成员、任务、依赖关系随之删除触发onTeamCleaned回调让宿主TeamAgent把StreamController标记为终止并关闭流见 TeamAgent.handleTeamCleaned()清理团队共享工作空间、成员工作空间等资源发布CLEANED团队事件。clean_team 的三个拒绝分支CleanTeamTool见 TeamTools.java在调用后端前还有两道任务层面的守卫存在非终态任务非 completed/cancelled拒绝清理要求先完成任务存在被取消的任务cancelled拒绝清理要求 Leader 处理cancelled 在任务侧虽然是终态但在团队收尾语境下被视为悬而未决需要 Leader 完成或确认后端返回失败但无活跃成员提示团队可能已被清理或删除已处于终态。这三道防线共同保证不会带着未结任务解散团队也不会对不存在的团队做无意义的清理。完成判定的底层支撑TEAM_COMPLETED 事件临时团队的收尾不是 Leader 拍脑袋决定的而是建立在框架的团队完成判定之上。TeamCompletionHandlerleader-only见 AgentTeams.md在 Leader idle 时周期性调用TeamBackend.isTeamCompleted()见 TeamBackend.java该方法三条件同时满足才返回完成快照任务全部终态所有 task 处于completed/cancelled即GraphUtils.TASK_TERMINAL_STATUSES成员全部 settled所有成员含 Leader处于READY / PAUSED / STOPPED / SHUTDOWNMEMBER_SETTLED_STATUSES——SHUTDOWN_REQUESTED、RESTARTING、BUSY、ERROR都会阻止完成判定无未读消息全团队无未读消息含广播。三条件满足后handler 上升沿发布一次TEAM_COMPLETED事件到team:name主题。temporary团队此时由 Leader 自己按提示词指引走shutdown_memberclean_team这正是lifecycle_temporary.md生效的时机而persistent团队则由TeamLifecycleController自动关闭 Leader 流、驱动 finalize → pause进入待命。这一差异在 AgentTeams.md 中有明确记载。值得一提的是clean_team成功后团队 DB 行被删除isTeamCompleted()会返回一个终态快照保证TEAM_COMPLETED只发一次、Leader 流正常关闭不会因级联删除导致 Leader 在过期 dispatch prompt 上空转。实战一条完整的临时团队收尾链路结合 Leader 工作流模板 与上述机制一个临时团队从组建到解散的完整生命周期如下建队build_team组建团队lifecycle缺省即temporary建任务create_task创建任务 DAG依赖任务初始为blocked依赖满足后自动转pending拉人spawn_member按领域创建专业成员预定义团队模式下此步被禁用启动send_message(to*)广播启动指令系统自动拉起未启动成员协作成员claim_task领取、执行、update_task(statuscompleted)标记完成Leader 审批计划仅 plan_mode、裁决冲突完成判定全部任务终态 全员 settled 无未读消息 → 框架发TEAM_COMPLETEDLeader 收尾本主题核心汇总各成员通过send_message上报的成果形成最终总结send_message(to*)广播总结与解散通知对每个成员调用shutdown_member(member_name...)等待其从SHUTDOWN_REQUESTED进入SHUTDOWN全部关闭后调用clean_team级联删除团队记录、成员、任务及工作空间资源框架确认onTeamCleaned回调终止 Leader 流isTeamCompleted()返回终态快照整个团队生命周期结束。官方 E2E 示例 AgentTeamE2eExample.java 印证了这一链路示例在finally块只做leader.close()和Runner.stop()不显式调用clean_team——因为 lifecycle 是temporaryLeader 会在收到TEAM_COMPLETED后按提示词指引自行完成shutdown_memberclean_team参见 AgentTeams.md 的 Demo 收尾说明。测试佐证生命周期语义的可验证性仓库测试 TeamLifecycleCompatibilityTest.java 对生命周期语义做了直接验证temporaryTeam_defaultLifecycle未显式声明 lifecycle 的 spec默认即为temporarypersistentTeam_lifecycleIsCreatedBeforeStartpersistent团队 build 后团队级生命周期为CREATEDstart 后转RUNNINGpersistentTeam_memberReadyToReadyIsValidREADY→READY自迁移在 persistent 模式下合法长期团队保持 READY 待命的基础。而 TeamRailCompatibilityTest.java 则验证了提示词装配规则teammate 只能收到ROLE / PERSONA / EXTRA三个静态章节workflow 与 lifecycle 章节对非 Leader 一律不注入。常见问题与最佳实践Q1clean_team报Active members remain怎么办说明仍有成员未处于SHUTDOWN。逐个核对成员状态shutdown_requested表示已发起关闭但成员尚未完成收尾应等待其自然进入SHUTDOWN若成员卡死长期停留在SHUTDOWN_REQUESTED或无法收尾可对其实例重试shutdown_member(forcetrue)——TeamBackend对已处于SHUTDOWN_REQUESTED的成员以 force 重试时会重新发布MEMBER_SHUTDOWN事件再次驱动shutdownSelf见 TeamBackend.java 注释从而解锁clean_team。Q2为什么收尾要高效每一轮寒暄都是一次完整 LLM 推理往返。send_message(to*)把总结通知压缩为一次通信成员收到后即进入关闭流程Leader 不回复致谢避免制造新的未读消息——别忘了无未读消息是完成判定的条件之一寒暄反而可能拖住收尾。Q3shutdown_member与clean_team的时序要求严格有序先全部shutdown_member全部进入SHUTDOWN后再clean_team。两者之间是请求 → 确认的关系clean_team会强制校验所有非 Leader 成员状态。Q4临时团队与持久团队如何选择单次任务、用完即回收的场景选temporary默认需要长期驻留、等待多轮用户指令的场景选persistent。二者共享同一套协调内核仅收尾语义不同——前者由 Leader 主动关闭解散后者完成任务后自动 pause 待命concludeCompletedRound关闭 Leader 流见 TeamAgent.java。最佳实践清单成果汇总含产物路径必须在shutdown_member之前完成并广播逐个shutdown_member后用list_members或事件确认全员SHUTDOWN再调clean_teamforcetrue仅在成员卡死时使用正常路径绝不启用若团队需要复用改用lifecyclepersistent不要对临时团队做半解散式保留。通过本文的剖析可以看到lifecycle_temporary.md虽是一段不足十行的提示词背后却串联着工具集过滤、成员状态机、完成判定、事件驱动与资源回收的完整机制。理解它是正确驾驭 openJiuwen Agent Teams 生命周期管理的关键一步。赞分享人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习【免费下载链接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent开发、运行、调优与演进相关的全套SDK能力。项目地址https://gitcode.com/openJiuwen/agent-core-java点击查看免费下载相关推荐503行审计脚本如何揪出静默断链Automotive Skills Suite列级链式契约审计原理503行审计脚本如何揪出静默断链Automotive Skills Suite列级链式契约审计原理 Automotive Skills Suite 是一个包含人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习openJiuwen Agent-Core 团队技能演进实战TeamSkillCreateRail 与 TeamSkillEvolutionRail 深度解析openJiuwen Agent Core 团队技能演进实战TeamSkillCreateRail 与 TeamSkillEvolutionRail 深度解析人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习openJiuwen agent-core DeepAgent Rails 机制详解生命周期钩子、内置护栏与双命名空间事件路由openJiuwen agent core DeepAgent Rails 机制详解生命周期钩子、内置护栏与双命名空间事件路由 本篇基于 openjiuwen人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考