“駕馭工程”已過時？ 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共建的“小龍蝦“智能管家?！癈law”象征著精準的抓取與連接，能夠將大語言模型的強大能力，通過你日常使用的各類通訊應用，直接延伸至你的指尖。

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”所帶來的高效與便捷的差異化體驗！

冷眼旁觀 麻辣點評 深入分析

個人觀點，僅供參考