目录一、单 Agent 的能力边界1.1 V1 架构的核心组件1.2 V1 的运行模式1.3 运行环境1.4 单 Agent 的天花板二、升级决策树2.1 决策树2.2 简化为三个维度判断三、V2 架构总览3.1 V2 架构图3.2 TeamManager团队生命周期管理3.3 技能继承机制3.4 V2 典型角色设计3.5 并发管理与 LLM 调用3.6 实时事件监控3.7 架构演进图3.8 V1 vs V2 架构对比四、迁移检查清单4.1 前置条件4.2 配置迁移步骤4.3 模式切换确认4.4 数据存储4.5 迁移成本评估4.6 V1 → V2 迁移检查清单20 项必查五、实操演示V1 vs V2 效果对比5.1 场景说明5.2 步骤一启动服务5.2.1 下载exe安装包5.2.2 双击安装包exe文件进行安装5.2.3 双击图标启动客户端5.3 步骤二V1 模式下的体验对比基准5.4 步骤三切换到 V2 集群模式5.5 步骤四发送调研任务5.6 步骤五观察团队运行5.7 步骤六追加新方向5.8 步骤七查看结果5.9 效果对比六、什么情况下不要升级七、写在最后参考资料当你用一个 Agent 完成日常对话和简单任务时体验往往还不错。但任务复杂度一旦上来——多步骤串行、多领域交叉、实时协作——单 Agent 架构的天花板就会暴露得越来越明显。本文基于 JiuwenSwarm 的真实架构帮你建立一套清晰的升级决策框架什么时候单 Agent 就够了什么时候该切到多 Agent 团队模式升级路径怎么走以及怎么验证升级效果。全文提供决策树、架构对比、迁移检查清单和实操演示不臆造。一、单 Agent 的能力边界先搞清楚一个问题单 Agent 到底能扛到什么程度1.1 V1 架构的核心组件JiuwenSwarm 基于 openJiuwen 框架构建通过适配器模式AgentAdapter将底层能力统一封装。入口类是JiuWenSwarm位于jiuwenswarm/server/runtime/agent_adapter/interface.py它在首次请求时通过_ensure_adapter()懒初始化适配器实例后续请求复用同一实例。V1 是单智能体架构所有任务由一个 Agent 串行处理。核心组件分工如下组件职责源码位置JiuwenSwarm主协调器懒初始化适配器、分发请求server/runtime/agent_adapter/interface.pyAgentAdapter适配器层封装底层 DeepAgent 能力server/runtime/agent_adapter/SkillManager技能生命周期管理安装、卸载、市场server/runtime/agent_adapter/interface.py 内嵌SessionManager会话管理与并发控制server/runtime/agent_adapter/interface.py 内嵌MessageHandler消息路由Channel 级别模式控制gateway/message_handler/message_handler.py来看看JiuWenSwarm的初始化逻辑理解 V1 的运行时结构class JiuWenSwarm: def __init__(self) - None: self._adapter: AgentAdapter | None None self._sdk_name: str | None None self._skill_manager SkillManager(workspace_dirstr(get_agent_workspace_dir())) self._session_manager SessionManager()一个_adapter就是一个 Agent 适配器。它在首次请求时通过_ensure_adapter()懒初始化def _ensure_adapter(self, *, mode: str agent) - AgentAdapter: if self._adapter is None: self._sdk_name resolve_sdk_choice() self._adapter create_adapter(self._sdk_name, modemode) if hasattr(self._adapter, set_skill_manager): self._adapter.set_skill_manager(self._skill_manager) return self._adapter所有会话共享这一个适配器实例通过SessionManager做会话隔离。这就意味着同一时刻只能处理一个请求链路。1.2 V1 的运行模式当前系统通过Mode枚举定义了多种运行模式用户可以在聊天界面直接切换class Mode(Enum): AGENT_PLAN agent.plan # 规划模式任务拆解 动态插入 AGENT_FAST agent.fast # 智能执行经典 ReAct适合日常对话 CODE_PLAN code.plan # 代码规划模式 CODE_NORMAL code.normal # 代码普通模式 CODE_TEAM code.team # 代码团队模式 TEAM team # 集群模式多 Agent 团队协作对于日常使用最核心的两个模式是agent.plan规划模式和agent.fast智能执行。模式从用户到 Agent 的数据流很清晰前端通过 WebSocket 传递params.mode字段MessageHandler._apply_channel_state()将当前 Channel 的模式状态注入消息参数def _apply_channel_state(self, msg: Message) - None: 将当前 Channel 的控制状态应用到消息上session_id / mode. channel_type self._resolve_control_channel_type(msg) if channel_type not in self._control_channel_types: return state self._get_or_create_channel_state(msg) # ... 会话 ID 解析 ... if msg.params is None: msg.params {} if isinstance(msg.params, dict): msg.params.setdefault(mode, state.mode.value)对于非 Web Channel飞书、小艺等用户可以通过/mode agent.plan、/mode agent.fast、/mode team等命令切换模式。1.3 运行环境项目配置值操作系统Windows 10 / macOS / LinuxPython3.11 / 3.12 / 3.13模型服务华为云 MaaS / OpenAI 兼容接口 / ModelScope 等通信渠道Web / 飞书 / 钉钉 / 企业微信 / 小艺 / Telegram / Discord / WhatsApp / 个人微信Agent 框架openJiuwen内置1.4 单 Agent 的天花板这套架构在日常问答、单领域工具调用、结构化的线性任务上表现良好。但当任务出现以下特征时瓶颈就会显现长链条串行任务比如整理本月发票 → 提取关键信息 → 汇总 Excel → 发邮件通知。中间任何一步出错后续流程可能中断。最大迭代轮数react.max_iterations默认 50也会限制超长任务的完成率。多领域复合任务一个 Agent 同时操作浏览器、编写代码、管理文件时上下文膨胀和注意力分散几乎不可避免。并发需求三个独立的调研方向需要同时展开单 Agent 只能排队处理。上下文膨胀随着信息累积LLM 的有效注意力会被稀释后期任务质量下降。说白了单个 Agent 的注意力、专业度、并发能力都有明确的天花板。到了这个点就需要考虑架构升级了。二、升级决策树不是所有场景都需要多 Agent。以下决策树帮你判断。2.1 决策树2.2 简化为三个维度判断如果你不想走决策树从任务复杂度、响应时间、用户满意度三个维度快速判断是否需要升级维度判断标准升级信号任务复杂度涉及 3 个以上独立子任务、跨领域操作单 Agent 串行处理效率急剧下降响应时间单任务串行耗时超过 30 分钟并发可显著提速用户等待体验差用户满意度上下文膨胀导致后期质量下降、无法追加需求单一注意力被稀释交互灵活性不足三个维度中出现两个或以上亮红灯就应该认真考虑升级了。三、V2 架构总览确定要升级后先理解 V2 的架构设计。JiuwenSwarm 的做法是让 Agent 组队。通过内置的 Swarm Agent 机制一个 Leader Agent 可以动态创建多个 Teammate Agent各司其职、协同完成复杂任务。这套机制与 JiuwenSwarm 已有的技能自演进、记忆系统、任务规划等能力是打通的不是孤立的模块。3.1 V2 架构图核心组件分工组件职责源码位置TeamManager团队生命周期管理创建/销毁/会话隔离agents/harness/team/team_manager.pyConfigLoader从 config.yaml 加载团队配置并构建规格agents/harness/team/config_loader.pyTeamAgentSpec团队规格定义角色/技能/生命周期openjiuwen agent_teams.schemaTeamAgent运行时团队实例Leader Teammateopenjiuwen agent_teams.agentTeamMonitorHandler实时事件监控成员/任务/消息agents/harness/team/monitor_handler.pyTeamRuntimeInheritance技能继承与能力卡复制agents/harness/team/team_runtime_inheritance.pyteam_helpers流式协作多请求并发/事件广播server/runtime/agent_adapter/team_helpers.py3.2 TeamManager团队生命周期管理TeamManager是 V2 的核心调度器。它的数据结构以session_id为键管理团队实例、监控器和后台流式任务同时维护技能演进和会话状态class TeamManager: def __init__(self): self._team_agents: dict[str, TeamAgent] {} # session_id → TeamAgent self._team_monitors: dict[str, TeamMonitorHandler] {} # session_id → monitor self._stream_tasks: dict[str, asyncio.Task] {} # session_id → asyncio.Task self._lock asyncio.Lock() self._active_session_id: str | None None self._active_team_name: str | None None self._team_skill_rails: dict[str, Any] {} # 技能演进 Rail self._team_evolution_watchers: dict[str, asyncio.Task] {} # 演进监控对外暴露的核心方法是get_or_create_team()实现了懒加载复用——已有 Team 就复用没有就新建async def get_or_create_team(self, session_id, deep_agent, ...) - TeamAgent: async with self._lock: team_agent self._team_agents.get(session_id) if team_agent is not None: return team_agent await self._destroy_other_sessions(session_id) return await self.create_team(session_id, deep_agent, ...)值得注意的是每个 Channel飞书、Web、钉钉等拥有独立的TeamManager实例通过全局注册表获取_team_managers: dict[str, TeamManager] {} def get_team_manager(channel_id: str | None None) - TeamManager: resolved_channel_id str(channel_id or default).strip() or default manager _team_managers.get(resolved_channel_id) if manager is None: manager TeamManager() _team_managers[resolved_channel_id] manager return manager这是 commit1380032中引入的改进解决了多 Channel 同时使用 Team 模式时的冲突问题。3.3 技能继承机制这是 V2 设计中比较精巧的部分。新 Teammate 创建时不是从零开始而是通过TeamRuntimeInheritance和TeamManager.build_agent_customizer()自动继承主 Agent 的技能和工具。继承分两步走先将全局技能复制到团队共享目录再按成员配置选择性复制到个人目录。以下是TeamManager.build_agent_customizer()中的核心逻辑def copy_member_configured_skills( member_skills_dir: Path, selected_skills: list[str], ) - None: selected_skill_set set(selected_skills) member_skills_dir.mkdir(parentsTrue, exist_okTrue) for skill_dir in global_skills_dir.iterdir(): if not skill_dir.is_dir() or not (skill_dir / SKILL.md).is_file(): continue if skill_dir.name not in selected_skill_set: continue dest member_skills_dir / skill_dir.name if not dest.exists(): shutil.copytree(skill_dir, dest)能力卡的继承也是自动的。主 Agent 的工具能力卡中标记为可继承的通过白名单过滤会被添加到新成员TOOL_WHITELIST frozenset({ free_search, fetch_webpage, paid_search, vision, audio, image_ocr, visual_question_answering, generate_image, audio_transcription, search_skill, install_skill, uninstall_skill, task_tool, user_todos, create_note, search_notes, modify_note, search_file, upload_file, # ... 更多工具 }) def filter_inheritable_ability_cards(main_agent: Any) - list[ToolCard]: result [] try: abilities main_agent.ability_manager.list() for ability in abilities: if isinstance(ability, ToolCard): if ability.name in TOOL_WHITELIST: result.append(ability) except Exception as exc: logger.warning([TeamRuntime] Failed to filter inheritable abilities: %s, exc) return result白名单从早期的 9 项扩展到了 30 项覆盖搜索、视觉、音频、技能管理、笔记、文件等工具类别。实际效果是给主 Agent 安装了网页搜索技能管理等技能后新创建的 Teammate 会自动拥有这些能力不需要逐个配置。3.4 V2 典型角色设计以客服场景为例V2 架构的典型角色分工角色职责说明Leader编排接收用户请求任务拆解与分发汇总结果相当于项目经理不做具体执行Teammate-A查询订单查询、物流追踪、账户信息检索专注查询类任务技能限定为搜索和数据访问Teammate-B工单处理退款、投诉、售后工单创建与流转专注写入类任务技能限定为工单系统操作当用户提出帮我查一下订单 12345 的物流然后申请退款时Leader 将请求拆分为查询物流、处理退款两个子任务Teammate-A 和 Teammate-B 分别并行执行Leader 汇总结果返回给用户。3.5 并发管理与 LLM 调用多 Agent 同时调用 LLM API 时并发控制由底层 openjiuwen 框架和模型服务提供商共同保障。TeamManager通过asyncio.Lock管理团队创建/销毁的并发安全确保同一 Channel 下不会出现两个 Team 同时创建的竞态条件async def get_or_create_team(self, session_id, deep_agent, ...) - TeamAgent: async with self._lock: team_agent self._team_agents.get(session_id) if team_agent is not None: return team_agent await self._destroy_other_sessions(session_id) return await self.create_team(session_id, deep_agent, ...)LLM API 层面的 429 限流处理由 openjiuwen SDK 内部机制管理。如果模型服务商有并发限制建议在部署时根据配额合理控制 Teammate 数量。3.6 实时事件监控V2 通过TeamMonitorHandler实现了实时事件监控定义了 12 种事件类型3.7 架构演进图V1: [单Agent] ──→ V2: [Leader 2个Teammate] │ │ 单线程 并行处理 单技能 专业分工 单模型 按需分配3.8 V1 vs V2 架构对比维度V1单 AgentV2多 Agent 团队执行模式串行 ReAct 循环Leader 调度 Teammate 并行执行上下文管理单一上下文随任务累积膨胀每个 Teammate 独立上下文质量稳定工具注册全量注册到单个 Agent按角色选择性继承或全量继承任务监控TodoToolkit 状态追踪12 种事件类型覆盖全生命周期追加交互排队等待当前任务完成立即创建新 Teammate 处理模型消耗单路 LLM 调用多路并发调用配置复杂度react: 段即可需额外 team: 段四、迁移检查清单确定要升级到 V2 后按以下清单逐项操作。4.1 前置条件检查项要求验证方式Python 版本3.11 / 3.12 / 3.13python --versionJiuwenSwarm 版本确认已安装最新版本pip show jiuwenswarm模型 API 配额多 Agent 并发会增大调用量确认配额充足查看 API 服务商控制台team 模块确认 jiuwenswarm/agents/harness/team/ 目录存在ls jiuwenswarm/agents/harness/team/4.2 配置迁移步骤第一步保留现有 V1 配置不动V1 的react:配置段不需要任何修改V2 是在其基础上新增配置。这是关键设计——V1 和 V2 共存不是替代# V1 配置保持不变 react: agent_name: main_agent max_iterations: 50 model_name: ${MODEL_NAME:-glm-4.7} model_client_config: client_provider: OpenAI api_base: ${MODEL_API_BASE:-https://open.bigmodel.cn/api/paas/v4} api_key: ${MODEL_API_KEY} verify_ssl: false第二步添加 team 配置段最小可用配置只需 4 行team: team_name: my_team lifecycle: persistent teammate_mode: build_mode spawn_mode: inprocess进阶配置含自定义 Leader、技能选择、预定义成员team: team_name: project_team lifecycle: persistent teammate_mode: build_mode spawn_mode: inprocess leader: member_name: project_manager display_name: 项目经理 persona: 擅长任务分解和项目管理的专家 agents: leader: skills: [openJiuwen-DeepSearch, advanced-daily-report] teammate: {} # Teammate 继承全部技能 predefined_members: - member_name: data_analyst display_name: 数据分析师 persona: 擅长数据清洗、统计分析和可视化 - member_name: doc_writer display_name: 文档编写员 persona: 擅长技术文档、报告和公文撰写关键配置项说明配置项说明默认值建议team.lifecycle团队生命周期模式persistent保持默认团队实例跨会话复用team.teammate_modeTeammate 构建模式build_mode任务不固定用 build_mode固定流程用 predefined_membersteam.spawn_mode进程模式inprocess初期用 inprocess后期可切 pyzmq 做分布式agents.leader.skillsLeader 技能列表继承全部建议限定核心技能减少上下文噪音agents.teammate.skillsTeammate 技能列表继承全部根据角色按需配置第三步验证配置生效客户端启动后AgentServer 会自动检测team配置段。存在则启用 Swarm Agent 模式不存在则以 V1 模式运行。完全向后兼容。4.3 模式切换确认V2 启用后前端模式按钮组会增加第三个选项按钮模式标识说明规划模式V1 - 任务规划agent.plan主动记忆 任务规划⚙️智能执行V1 - 经典 ReActagent.fast基础 Agent适合日常对话集群模式V2 - 团队协作team多 Agent 团队协作4.4 数据存储团队运行时数据默认存储在~/.jiuwenswarm/agent/team.dbSQLite。分布式模式下推荐 PostgreSQLteam: storage: type: postgresql params: connection_string: postgresqlasyncpg://user:pass127.0.0.1:5432/team_db4.5 迁移成本评估成本维度具体内容评估代码改动量零代码改动纯配置升级。V1 配置完全保留V2 通过新增 team: 配置段启用低配置复杂度最小配置仅需 4 行 YAMLteam_name / lifecycle / teammate_mode / spawn_mode低运维成本需关注多 Agent 并发导致的 LLM API 调用量增长、团队运行时状态监控中学习成本需理解 Leader/Teammate 角色分工、技能继承机制、12 种事件类型中资源消耗多 Agent 并发占用更多内存和 API 配额需根据实际配额合理控制 Teammate 数量视规模而定回退风险V1 和 V2 共存设计删除 team: 配置段即可回退到 V1无风险结论迁移成本整体偏低核心原因是配置驱动而非代码驱动。主要增量成本在于 API 调用量和运维监控。4.6 V1 → V2 迁移检查清单20 项必查环境与依赖5 项#检查项要求验证方式1Python 版本3.11 / 3.12 / 3.13python --version2JiuwenSwarm 版本确认已安装最新版本pip show jiuwenswarm3team 模块确认 jiuwenswarm/agents/harness/team/ 目录存在ls jiuwenswarm/agents/harness/team/4模型 API 配额多 Agent 并发会增大调用量确认配额充足查看 API 服务商控制台5系统资源系统资源满足多进程并发需求内存、磁盘充足系统监控工具配置迁移5 项#检查项要求验证方式6V1 配置完整性react: 配置段正常工作发送测试消息确认 V1 响应正常7team 配置段添加最小配置 4 行 YAML 已写入 config.yaml检查 config/config.yaml8环境变量MODEL_API_KEY 等环境变量已配置echo $MODEL_API_KEY9Leader 角色定义persona 和 skills 已配置可选检查 team.leader 配置10数据存储配置SQLite 或 PostgreSQL 连接配置正确启动后检查 team.db 是否创建功能验证5 项#检查项要求验证方式11模式切换前端三个模式按钮均可点击切换依次切换 agent.plan / agent.fast / team12团队创建Leader Agent 能正常创建并显示在面板发送消息后检查团队成员面板13Teammate 创建Leader 能动态创建 Teammate发送多子任务请求观察成员列表更新14技能继承Teammate 自动继承主 Agent 的技能检查 Teammate 是否能使用搜索等继承技能15事件监控12 种事件类型能正常触发和显示查看任务事件面板稳定性与回退5 项#检查项要求验证方式16追加交互运行中能追加新需求而不中断已有任务调研过程中追加新方向17会话隔离不同 Channel 的团队实例互不干扰多 Channel 同时使用 team 模式18错误恢复Teammate 出错不影响其他成员和 Leader模拟一个 Teammate 异常19资源释放任务完成后 Teammate 正确关闭资源释放观察成员状态变为灰色已关闭20回退验证删除 team: 配置段后能正常回退到 V1删除配置重启服务确认 V1 正常五、实操演示V1 vs V2 效果对比用一个实际场景走一遍完整流程直观对比 V1 和 V2 的差异。5.1 场景说明用户要求对 AI Agent 的多个方向同时展开深度调研帮我全面调研一下 AI Agent 的最新进展我需要了解三个方向1主流 Agent 框架的设计对比LangGraph vs CrewAI vs AutoGen2Agent 通信协议的现状MCP、A2A、ACP3Agent 在企业场景中的落地案例。每个方向生成一份独立的 Markdown 报告保存到工作目录。这个场景完美命中升级决策树的三个信号3 个独立子任务、跨领域技术对比 协议分析 案例调研、需要并发提速。5.2 步骤一启动服务5.2.1 下载exe安装包访问https://openjiuwen.com/jiuwenswarm#quick-start根据电脑系统选择下载相应的安装包我这里选择的是windows。点击立即下载按钮完成下载。5.2.2 双击安装包exe文件进行安装在安装弹框中选择要安装的文件路径点击next按钮。再次点击next按钮。点击install按钮。安装完成。5.2.3 双击图标启动客户端图示启动JiuwenSwarm客户端图示JiuwenSwarm的客户端界面5.3 步骤二V1 模式下的体验对比基准先在规划模式V1下执行同样的任务。帮我全面调研一下 AI Agent 的最新进展我需要了解三个方向 1主流 Agent 框架的设计对比LangGraph vs CrewAI vs AutoGen 2Agent 通信协议的现状MCP、A2A、ACP 3Agent 在企业场景中的落地案例 每个方向生成一份独立的 Markdown 报告保存到工作目录。Agent 先创建任务列表依次标记为running→completed第一个方向处理完后才开始第二个总耗时约 45-60 分钟随着信息累积后期任务的质量可能因上下文膨胀而下降如果中途追加新需求需要排队等待当前任务完成5.4 步骤三切换到 V2 集群模式在聊天输入框底部的工具栏中找到左侧的模式切换按钮组三个并排按钮点击最右侧的集群模式按钮 图标。如果当前会话有历史消息会弹出确认弹窗提示切换模式将创建新会话点击确认即可。5.5 步骤四发送调研任务在集群模式下发送同样的调研指令帮我全面调研一下 AI Agent 的最新进展我需要了解三个方向 1主流 Agent 框架的设计对比LangGraph vs CrewAI vs AutoGen 2Agent 通信协议的现状MCP、A2A、ACP 3Agent 在企业场景中的落地案例 每个方向生成一份独立的 Markdown 报告保存到工作目录。消息发送后系统进入 Swarm Agent 模式。代码层面process_team_message_stream()判断这是首次请求自动创建团队并启动监控async def process_team_message_stream( request: Any, inputs: dict[str, Any], deep_agent: DeepAgent, ) - AsyncIterator[AgentResponseChunk]: # 判断是否首次请求 is_first_request not team_manager.has_stream_task(session_id) if is_first_request: # 构建团队规格并创建团队 team_spec await team_manager.get_enriched_team_spec(...) # 启动流式消费任务 stream_task asyncio.create_task( _consume_stream_with_query(channel_id, session_id, team_agent, query) ) team_manager.register_stream_task(session_id, stream_task) else: # 追加交互直接注入消息到运行中的团队 await team_manager.interact(session_id, query)5.6 步骤五观察团队运行在聊天区域右侧会显示团队面板包含两个区域团队成员面板显示所有成员及其状态 绿色就绪 黄色忙碌 蓝色重启中 橙色关闭请求中⚪ 灰色已关闭 红色错误任务事件面板显示实时事件日志可以看到任务被创建 → 被成员认领 → 完成的完整生命周期。初始状态可以看到 Leaderteam_leader被创建。随后 Leader 分析任务动态创建 3 个 Teammate成员列表实时更新。Leader 会实时监控成员运行状态给出提醒并汇报进度。5.7 步骤六追加新方向调研进行到第 5 分钟左右直接在输入框追加减指令再帮我加一个方向Agent 的安全与对齐问题也调研一下。在集群模式下消息会通过追加交互路径注入正在运行的 TeamAgent。代码层面的判断很直接——检查该 session 是否已有流式任务在跑如果是直接注入而不是新建团队# 不是首次请求 if query: success await team_manager.interact(session_id, query)Leader 收到后动态创建新的 Teammate 处理不影响其他正在执行的成员。观察团队成员面板可以看到第 4 个成员被创建并开始执行。5.8 步骤七查看结果调研完成后聊天区域Leader 汇总所有调研结果团队成员面板所有成员状态变为 就绪随后变为 ⚪ 已关闭工作目录报告文件已保存workspace/session/sess_research/ ├── Agent框架对比分析.md # LangGraph vs CrewAI vs AutoGen ├── Agent通信协议技术对比.md # MCP / A2A / ACP ├── Agent企业落地案例.md # 企业应用实践 ├── Agent安全与对齐.md # 追加的安全方向 └── todo.md # 任务进度记录5.9 效果对比维度V1单 AgentV2Swarm Agent处理方式串行处理 4 个方向并行处理31 个 Teammate 同时工作耗时约 60 分钟约 20 分钟上下文质量信息累积导致膨胀后期质量下降每个 Teammate 上下文独立质量稳定追加需求需排队等待当前任务完成立即创建新 Teammate 处理六、什么情况下不要升级最后说一个重要的事不是所有场景都需要升级到 V2。场景原因任务始终是线性的步骤 A → B → C串行执行更自然上下文共享是优势API 配额紧张多 Agent 并发会显著增加调用量任务简单30 秒内完成多 Agent 的调度开销反而拖慢速度只需要单一领域操作上下文不需要隔离调试和开发阶段单 Agent 的调试体验更直观V1 和 V2 是共存关系不是替代关系。日常对话用 V1 的智能执行模式复杂任务切 V2 的集群模式。系统支持在不同会话间自由切换互不影响。七、写在最后从 V1 到 V2 的升级本质上是把一个人扛变成一个团队协作。但团队协作不是免费的——你需要配置团队结构、管理资源竞争、监控运行状态。JiuwenSwarm 的设计重心在于降低这个升级成本配置驱动而非代码驱动V1 配置完全保留V2 通过新增team:配置段启用零侵入能力继承而非重复配置新 Teammate 自动继承主 Agent 的技能和能力卡不需要逐个配置动态 静态双模式build_mode按需动态创建适合任务不固定的场景predefined_members适合固定流程全链路可观测12 种事件类型覆盖团队运行的关键节点前端实时展示总的来说这是一套实用导向的升级方案——重心放在如何让现有能力在多 Agent 场景下顺畅运转而不是追求架构上的花哨。参考资料https://atomgit.com/openJiuwenhttps://www.openjiuwen.com