“驾驭工程”下一跳？JiuwenClaw AgentTeam开启“协同工程”全新范式

如果说提示词工程与上下文工程逐步将AI推向了“可用区间”，那么驾驭工程的技术使命是完成了单个 Agent 从 “基础运行” 到 “稳态运行、可控调度、合规交付” 的能力闭环构建。但当任务开始呈现出更明显的链路化、并行化与角色化特征时，新的瓶颈会立刻显现：单Agent再强，也很难同时承担调研、分析、执行、校对、汇总这些彼此依赖、不同节奏的工作。比如华为云近期正式发布的OfficeClaw办公智能体，重点是围绕办公场景让AI从“单兵作战”走向”团队协防“，引发关于办公效率的底层革命。

真正决定上限的，不再是“一个Agent能做到多少”，而是“多个Agent能否像团队一样持续协同”：能不能自动分工、能不能低摩擦交接、能不能在无人盯盘时也不掉链子、能不能把过程做成可观测与可治理的工程系统。

如何让多个智能体像一支精锐团队一样，自主分工、高效沟通、无缝协作？

面向这个下一代的核心难点问题，华为支持的 openJiuwen 社区发布最新版 JiuwenClaw，带来 AgentTeam 多智能体协同能力，并把行业下一阶段的工程焦点明确指向：“驾驭工程”的下一跳是“协同工程”。

JiuwenClaw已正式上线AgentTeam能力，欢迎体验！

项目地址：

• https://gitcode.com/openJiuwen/jiuwenclaw

• https://github.com/openJiuwen-ai/jiuwenclaw

本篇博客将详细讲解JiuwenClaw AgentTeam的设计理念与核心架构

AgentTeam：一个Leader带队多个Teammate并行作战

JiuwenClaw AgentTeam的核心理念很直接：模拟真实团队的协作方式。一个Leader Agent负责需求分析、团队组建和任务规划；多个Teammate Agent各自领取任务、独立执行、汇报结果。整个过程由事件驱动，无需人工介入即可完成从需求到交付的全流程，实现真正的“协同工程”。

• Leader自主分析需求、组建团队、创建带依赖关系的任务

• Teammate通过共享工作区协同产出，文件锁定保证一致性

• Leader审批关键决策，故障自动恢复，全程实时可观测

下面逐一解读这三项核心能力。

1.Leader智能编排，Teammate自主执行

传统的Multi-Agent方案往往需要使用者手动编排——你得预先定义谁先谁后、谁跟谁通信。JiuwenClaw AgentTeam把这件事交给了Leader Agent自己。

Leader做什么：

用户只需描述需求，Leader会自主完成以下工作：

• 动态组建团队：无需预先定义固定阵容。Leader基于团队模版，根据目标描述动态分配角色和成员——调研专员、内容撰写、数据分析、质量审核，按需生成。执行过程中发现人手不足或方向调整，Leader还可以随时增减成员，团队组成始终跟着目标走

• 规划任务：将需求拆解为具体任务，建立依赖关系（比如"数据采集完成后，分析才能开始"）

• 分配与监控：创建任务后，通过事件系统实时感知进展——谁认领了什么、谁完成了什么、谁遇到了问题

Teammate做什么：

Teammate不需要被"指挥"——它们自主运转：

• 主动认领：收到任务创建事件后，自动浏览任务板，认领与自身能力匹配的任务

• 独立执行：在自己的工作空间中完成调研、撰写、分析等工作。遇到复杂任务，Teammate可以自行拆解为更细粒度的子步骤；遇到阻塞或不确定，可以主动向Leader发消息求助决策

• 汇报结果：任务完成后自动更新状态，触发事件通知Leader和其他依赖方

这是一种分级自主协同：Leader基于目标和当前进度做战略级拆分，Teammate在各自任务内独立决策和执行，同时保留向上求助的通道——既不事事请示，也不闭门造车。这也是“协同工程”的核心思想。

两者之间靠什么连接？任务和消息双驱动。

JiuwenClaw AgentTeam的协同不只靠"派任务-做任务-交任务"这条线。团队成员既通过任务协作驱动核心流程——认领、执行、完成、解除下游阻塞；又通过任务外消息持续沟通——讨论方案、协商优先级、反馈问题、请求支援。两条通道并行工作，适用于需要讨论和协商的复杂场景，而不仅仅是机械地分发和汇总，已经非常类似人类团队协作的机制了！

所有交互——任务状态变更、成员间消息、成员上下线——都通过事件总线实时传递。不是Leader每隔几秒轮询"你干完没"，而是Teammate完成任务的瞬间，Leader就会被唤醒做下一步决策。

这个过程中，任务依赖自动管理。task-3被task-1阻塞时，状态为BLOCKED；task-1完成的瞬间，系统自动将task-3解除阻塞，变为可认领状态。Teammate不需要理解依赖图，只需要认领和执行。

2.Team Workspace：团队共享工作区

多 Agent 协作绕不开一个现实问题：Agent之间怎么共享工作产物？

调研 Teammate 采集了行业数据，分析T eammate 需要读取；分析 Teammate 输出了趋势图表，撰写 Teammate 需要引用。如果每个 Agent 各干各的、互不可见，"团队协作"就只是个空壳。

AgentTeam 通过Team Workspace解决这个问题——一个团队级的共享文件空间，所有成员均可透明访问。

它是怎么工作的？

每个 Teammate 的工作目录中都会自动挂载一个共享路径，指向同一个团队工作区。调研 Teammate 写入的行业数据文件，分析 Teammate 立刻可见。不需要手动传文件、不需要 Agent 之间互相发消息"你去看某某路径"——直接读写，天然共享。

每个Teammate在自己的独立工作空间中干活，需要跨成员协作时写入共享区即可。

但共享带来冲突风险——两个 Teammate 同时写同一个文件怎么办？Team Workspace 提供了三种冲突策略，按场景选择：

整个过程对 Agent 透明——框架内置的工作区护栏自动拦截所有共享目录的文件操作：写入前检查锁、写入后自动提交并通知其他成员、读取前拉取最新版本。Agent 只管读写文件，协调逻辑由框架处理。

在涉及代码协作的场景中，框架还支持 Git Worktree，为每个 Teammate 提供独立的文件系统视图，与 Team Workspace 的产物共享互不冲突。

3.全生命周期管控：从Plan审批到故障自愈

真实的团队协作不仅仅是"分任务-干活-汇总"。JiuwenClaw AgentTeam 覆盖了从任务创建到团队解散的完整生命周期，包括审批、容错和可观测。

Leader 审批：关键决策和敏感操作不放手

Agent 自主执行效率高，但不是所有决策都应该放手。AgentTeam提供两层审批机制：

• Plan 模式：对于重要任务，Teammate 认领后不直接动手，而是先提交执行计划给 Leader 审批。Leader 觉得合理就通过，觉得方向有偏就驳回并给出反馈，Teammate 修订后重新提交

• 工具审批：当 Teammate 要执行敏感操作（比如删除重要文件、调用外部 API、修改共享配置），审批请求自动发送给 Leader，Leader 决定是否允许

两者的核心原则一致：Agent 可以自主建议，但关键决策权始终在 Leader手上，避免"自由发挥后收拾烂摊子"。

事件驱动机制：让团队始终保持运转

多Agent协作最怕的情况是隐性停滞——Teammate 异常僵死无人察觉、任务长时间无人认领、已认领的任务迟迟不完成、成员间消息漏接……整个团队看似还在运行，实际已经卡住，却没人主动处理。

AgentTeam 在底层搭了一套完整的事件驱动机制来规避这类风险。团队里几乎所有有意义的变化都会产生事件，外部事件和内部事件双管齐下：

• 任务事件：创建、认领、完成、取消、解除阻塞——任务板的每一次状态翻转都触发事件

• 成员事件：上线、下线、状态切换（空闲/忙碌/异常）、重启——每个成员的生命周期变化都被捕获

• 消息事件：点对点消息、广播通知、审批请求——所有通信都走事件总线

• 内部轮询事件：框架内定时产生的自检事件（邮箱轮询、任务板轮询等），在没有外部事件到来时仍定期唤醒Agent做自我检查

基于这些事件，框架构建了一套激活处理逻辑：事件一旦触发，相关的Agent就会被唤醒，重新审视自己该做什么——空闲的 Teammate 会主动检查任务板并认领待领任务；Leader 会监控全局进度，识别长期未认领的 PENDING 任务和执行超时的 CLAIMED 任务，必要时重新规划或换人；消息接收方会优先处理未读。对于 Teammate 自身的异常僵死，框架也会通过心跳检测和重启机制自动恢复。配合定时轮询兜底，即使某个事件偶发丢失，系统也能在下一轮自检中自愈。

这套机制的价值不仅在于让信息在团队里流动起来，更在于让团队始终保持运转——不会有任务长期无人认领、不会有Teammate挂掉没人知道、不会有执行停滞却无人干预。单点问题始终能在可控时间内被发现并处置，不会阻塞整个团队协作。

持久化团队：跨会话不丢状态

团队不一定是用完即弃的。启用Persistent（持久化）模式后，团队可以跨会话保留：

• 会话结束时，团队进入待机状态，成员信息和配置持久化到数据库

• 下次使用时，一键恢复——创建新的会话空间，重新启动队员，无需重新组建团队

适合需要长期运转的项目——每次打开都是熟悉的团队阵容，直接开始新任务。

TeamMonitor：实时可观测

AgentTeam 的整个协作过程透明可见，TeamMonitor 提供两个维度的观测能力：

查询API——随时查看团队当前状态：

事件流——实时订阅团队事件。任务完成、成员状态变更、消息收发……所有事件都可以通过异步迭代器逐条消费。你可以据此构建 Dashboard、日志系统，或者触发外部工作流。整个团队的运转不是黑盒，而是每一步都可追踪、可审计。

openJiuwen Agent Team 核心架构

openJiuwen AgentTeam 协同层是一套完整的多智能体编排基础设施。

它的核心技术原理可以归结为三点：

• 基于共享任务列表的一致性协同：所有成员共享同一份动态任务列表，各自基于团队目标、任务定义和自身能力，自主认领并执行任务，天然保证信息一致

• 消息和任务双驱动模式：成员间既通过任务流转驱动核心工作流，又通过任务外的消息通道持续推进讨论和协商，覆盖从结构化执行到非结构化沟通的全场景

• 角色与工具工程：RolePolicy 定义 Leader 和 Teammate 在团队中的行为规范和决策边界，TeamTools e赋予团队成员具体的协调操作能力——角色决定"该做什么"，工具决定"能做什么"

AgentTeame 协作流程如下：

下面讲解其核心技术设计。

1.双角色统一类：一套代码，两种人格

AgentTeam 中 Leader 和 Teammate 共用同一个 Agent 架构——TeamAgent。它根据运行时的角色身份展现不同行为：不同的工具集、不同的 Prompt 策略、不同的事件处理逻辑。

架构上，TeamAgen t将团队协调层与单 Agent 执行层（Harness SDK）做了清晰分离。协调层负责角色策略、事件路由和团队管理；执行层复用 openJiuwen 已有的 Harness 能力——提示词、工具、护栏、任务循环。两层独立演进，互不干扰。

共享工具（Leader 和 Teammate 均可使用）：查看任务、发送消息/广播。

这意味着新增一种团队角色（比如"审核员"）不需要从头开发一个新 Agent，只需配置不同的工具集和 Promp t策略。协调层的升级也不会影响单 Agent 的执行能力，两侧独立迭代。

2.事件驱动的协调循环

团队协调的核心引擎是协调循环（CoordinatorLoop）——一个事件驱动的调度中枢，为每个TeamAgent提供"大脑"。

设计亮点：双通道事件入口。

• 实时通道：传输层事件（任务完成、消息到达、成员状态变化）立即入队，延迟极低

• 轮询通道：两个独立定时器分别检查邮箱和任务板（间隔可配置），作为兜底——即使传输层偶发丢事件，轮询保证最终一致性

• 事件分发器根据事件类型智能路由：

• 用户输入→ 启动或引导 Agent 执行

• 任务事件→ 推动空闲 Agent 认领新任务

• 消息事件→ 处理未读消息，转化为 Agent 输入

• 成员事件→ 更新成员跟踪状态，触发过期任务检查

特别值得一提的是空闲推动机制：当T eammate 完成任务变为空闲时，事件分发器会主动检查任务板上是否有可认领的任务，如果有就"推一把"——把任务摘要注入 Agent 的上下文，驱动它继续工作。Leader 端则检测长期未认领的待领任务和超时的已认领任务，必要时重新规划或重新分配。

这套机制让 Agent 平时处于"休眠"状态，有事件才被唤醒，资源消耗极低。而轮询作为兜底，保证即使消息偶发丢失系统也不会卡死——兼顾了低延迟和高可靠。

3.分段式Prompt注入（TeamRail）

团队上下文信息（角色策略、团队成员、任务状态）需要注入 Agent 的系统 Prompt。传统做法是拼接成一个大字符串，每次全量重建。AgentTeam 采用了分段注入——将团队 Prompt 拆解为7个独立片段（Section），每个片段承载一类上下文信息，按优先级有序组装：

前5个片段在团队初始化时一次构建，后续直接复用。后2个片段（团队信息、成员关系）会随团队运行发生变化，框架通过时间戳缓存按需刷新——只有数据真正变化时才重新查询，团队运行稳定时组装开销几乎为零。

分段带来的另一个好处是可扩展：后续需要给 Agent 注入新的团队上下文（比如共享知识库摘要），只需增加一个片段，不会影响已有的角色策略和工作流。对于长时间运行的团队，动态缓存也避免了每次模型调用都重新查数据库。

4.可插拔基础设施

AgentTeam 的通信和存储完全可插拔——框架内置了适合单机场景的默认实现，同时支持替换为企业级方案：

传输层（Messager）：

单机默认使用 ZMQ 轻量通信；分布式场景可切换为 Pulsar、RocketMQ 等消息队列

存储层（TeamDatabase）：

单机默认使用 SQLite；分布式场景可切换为 PostgreSQL 等关系数据库

需要自定义？通过注册表一行代码即可接入 Redis、PostgreSQL 等第三方后端。所有注册表延迟加载——内置实现在首次使用时才初始化，可选依赖缺失时优雅跳过。接入新的后端只需调整配置，无需修改业务逻辑。

JiuwenClaw在企业级办公智能体产品OfficeClaw中的实践落地

就在刚刚过去的4月16日，华为云举办 OfficeClaw 办公智能体新品体验会，并启动了产品邀测。

OfficeClaw的创意来源于开源项目，华为云研发团队捕捉到这一创新价值，集结数十位研发人员开展联合攻关，依托华为自主创新全开源的 JiuwenClaw 项目为技术底座，基于华为云AI基础设施能力和 AgentArts 智能体开发平台，提供企业级安全防护、分钟级定障精准评估、精准上下文、羽量沙箱百毫秒启动、Agent 自进化等五大核心能力，让企业成百上千个AI 智能体能既快又稳、管得住、用得好。

写在最后：为什么Coordination Engineering是下一跳

当行业还在继续深化Harness Engineering（提示词工程、工具编排、护栏机制、任务循环、工作空间管理）时，真正的增量空间正在向“团队化交付”转移：一个 Agent 很难覆盖完整链路，但一个 AgentTeam 可以把复杂任务拆成并行工序、把交接变成机制、把治理变成可观测与可恢复的系统。

因此，Coordination Engineering不是一个简单的概念，而是 Harness Engineering 合乎逻辑的下一跳：在每个Teammate内部保留完整的 Harness SDK Agent 能力，在团队层叠加协同编排与治理能力，让多个强个体以更低摩擦组织成高效团队。

同时，JiuwenClaw 提出的Team Skill机制也值得关注：它能把 AgentTeam 执行过程中的团队协作流程沉淀为可复用的“团队 SOP” 协作模板，并在每次使用后自动优化——用得越多，SOP 越精准，进一步增强 Evolution Engineering 能力。

如果你正在寻找一条从单 Agent 走向团队协同的工程路径，不妨直接从开源地址上手，用真实任务跑一遍AgentTeam，亲手见证 “Coordination Engineering” 所带来的高效与便捷的差异化体验！

搜索 openJiuwen 官网解锁更多实操案例与技术解读：https://openjiuwen.com/