“驾驭工程”已过时？ JiuwenClaw AgentTeam开启“协同工程”全新范式

编辑 | 秦言

来源：懂懂笔记

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

如何让多个智能体像一支精锐团队一样

自主分工、高效沟通、无缝协作？

面向这个下一代的核心难点问题，华为支持的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各自领取任务、独立执行、汇报结果。整个过程由事件驱动，无需人工介入即可完成从需求到交付的全流程，实现真正的“协同工程”。

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

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

3. 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就会被唤醒做下一步决策。

用户: "帮我完成Q3市场分析报告"

Leader分析→ 组建团队:
├── researcher (行业调研)
├── analyst (数据分析)
└── writer (报告撰写)

Leader规划任务:
├── task-1: 收集行业数据与竞品动态→ researcher
├── task-2: 用户调研与反馈整理→ researcher
├── task-3: 数据清洗与趋势分析→ analyst (依赖task-1)
├── task-4: 竞品对比分析→ analyst (依赖task-1, task-2)
└── task-5: 整合撰写完整报告→ writer (依赖task-3, task-4)

Teammate并行执行:
researcher 同时认领task-1, task-2 → 完成→ task-3, task-4 自动解除阻塞
analyst 认领task-3 → 完成→ 认领task-4 → 完成→ task-5 解除阻塞
writer 认领task-5 → 整合产出最终报告

Leader收尾:
所有任务完成→ 审查结果→ 关闭团队→ 输出最终交付物

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

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

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

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

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

它是怎么工作的？

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

Teammate A (调研) 的工作目录
├── workspace/ # 各自的独立工作空间
└── .team/ # 共享工作区挂载点
└── artifacts/
├── data/ # 共享数据（采集数据、清洗结果）
├── docs/ # 共享文档（分析报告、设计方案）
└── reports/ # 共享报告（最终交付物）
Teammate B (分析) 的工作目录
├── workspace/
└── .team/ → 同一个共享工作区 # 读写同一份文件

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

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

策略

行为

适用场景

LOCK

文件级锁定，同一时间只有一个写入者

关键配置、核心数据源等不可并发修改的文件

MERGE

基于Git的并发写入，自动提交并报告冲突

文档类产物，允许多人并发编辑

LAST_WRITE_WINS

无冲突检测，后写覆盖

日志、临时草稿等无需一致性保证的文件

整个过程对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——随时查看团队当前状态：

查询

内容

团队信息

团队名称、Leader、创建时间

成员状态

每个成员的运行状态（READY / BUSY / ERROR / SHUTDOWN）

任务进度

所有任务的状态、认领人、依赖关系

消息记录

成员间的通信历史

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

openJiuwen Agent Team核心架构

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

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

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

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

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

AgentTeam协作流程如下：

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

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

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

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

维度

Leader

Teammate

工具集

组建团队、生成成员、创建/更新任务、关闭成员、审批计划、审批工具调用、列出成员+ 共享工具

认领任务+ 共享工具

Prompt

角色策略+ 工作流+ 生命周期+ 团队上下文

角色策略+ 团队上下文

事件处理

观察所有成员的状态变化

仅处理与自身相关的事件

特有组件

模型分配器（队员模型轮询分配）、工作区管理器

成员状态对象

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

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

2.事件驱动的协调循环

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

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

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

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

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

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

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

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

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

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

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

3.分段式Prompt注入（TeamRail）

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

优先级

片段

更新策略

1

角色策略

当前成员的身份和行为规范

静态

2

工作流

Leader的团队工作流程指引

静态

3

生命周期

临时团队或持久化团队的策略差异

静态

4

人设

当前成员的角色人设描述

静态

5

用户自定义

用户注入的额外指令

静态

6

团队信息

团队名称、描述等元数据

动态

7

成员关系

当前团队的成员列表及角色

动态

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

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

4.可插拔基础设施

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

传输层（Messager）：

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

后端

场景

特征

ZMQ

单机多进程

轻量级，低延迟，点对点直连+ 发布/订阅广播

Pulsar / RocketMQ

跨机分布式

持久化队列，高可用，支持大规模集群组网

存储层（TeamDatabase）：

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

后端

场景

特征

SQLite

单机、默认

WAL模式，异步IO，跨会话持久化

PostgreSQL

分布式、生产

多节点共享状态，高并发，事务保障

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

JiuwenClaw简介和行业案例

JiuwenClaw ——由云AgentArts、2012九问团队和社区广大开发者联合在openJiuwen共建的“小龙虾“智能管家。“Claw”象征着精准的抓取与连接，能够将大语言模型的强大能力，通过你日常使用的各类通讯应用，直接延伸至你的指尖。

JiuwenClaw基于Python开发，天然拥有良好的生态兼容性和扩展能力，在模型接入方面，JiuwenClaw支持华为云MaaS 等主流模型平台，用户只需简单配置即可调用华为云的模型服务。此外，JiuwenClaw 已实现与小艺开放平台的无缝对接，华为手机用户可以通过小艺直接唤醒并使用JiuwenClaw，享受随叫随到的智能服务。

JiuwenClaw的独特优势是“懂你所想，自主演进”。针对你的各种复杂输入场景，如任务追加、打断、修改等，它就是懂你的贴身任务管家，将你的各类需求排出优先级，并有条不紊地完成；同时它也能在你身边自主演进，当你对他表达不满或运行出错时，它会根据你的反馈自动调整相应技能，全心全意为你服务。在连接渠道方面，JiuwenClaw已实现鸿蒙小艺、飞书、钉钉、Discord、Telegram、WhatsApp等channel的无缝接入，并将持续拓展至更多元平台。无论是进行复杂代码编写、寻求即时的技术支持，还是管理日程与信息流，JiuwenClaw都能让你从任何地方、以最熟悉的方式，唤出一个始终在线、数据自主的专属AI助理。

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”所带来的高效与便捷的差异化体验！

冷眼旁观 麻辣点评 深入分析

个人观点，仅供参考