編輯 | 秦言

來源：懂懂筆記

如果說提示詞工程與上下文工程逐步將AI推向了“可用區(qū)間”，那么駕馭工程的技術(shù)使命是完成了單個 Agent 從 “基礎(chǔ)運行” 到 “穩(wěn)態(tài)運行、可控調(diào)度、合規(guī)交付” 的能力閉環(huán)構(gòu)建。但當任務開始呈現(xiàn)出更明顯的鏈路化、并行化與角色化特征時，新的瓶頸會立刻顯現(xiàn)：單Agent再強，也很難同時承擔調(diào)研、分析、執(zhí)行、校對、匯總這些彼此依賴、不同節(jié)奏的工作。比如華為云近期正式發(fā)布的OfficeClaw辦公智能體，重點是圍繞辦公場景讓AI從“單兵作戰(zhàn)”走向”團隊協(xié)防“，引發(fā)關(guān)于辦公效率的底層革命。

如何讓多個智能體像一支精銳團隊一樣

自主分工、高效溝通、無縫協(xié)作？

面向這個下一代的核心難點問題，華為支持的openJiuwen社區(qū)發(fā)布最新版JiuwenClaw，帶來AgentTeam多智能體協(xié)同能力，并把行業(yè)下一階段的工程焦點明確指向：“駕馭工程”的下一跳是“協(xié)同工程”。

JiuwenClaw已正式上線AgentTeam能力，歡迎體驗！

項目地址：

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

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

本篇博客將詳細講解JiuwenClaw AgentTeam的設計理念與核心架構(gòu)。

AgentTeam：一個Leader帶隊

多個Teammate并行作戰(zhàn)

JiuwenClaw AgentTeam的核心理念很直接：模擬真實團隊的協(xié)作方式。一個Leader Agent負責需求分析、團隊組建和任務規(guī)劃；多個Teammate Agent各自領(lǐng)取任務、獨立執(zhí)行、匯報結(jié)果。整個過程由事件驅(qū)動，無需人工介入即可完成從需求到交付的全流程，實現(xiàn)真正的“協(xié)同工程”。

1. Leader自主分析需求、組建團隊、創(chuàng)建帶依賴關(guān)系的任務

2. Teammate通過共享工作區(qū)協(xié)同產(chǎn)出，文件鎖定保證一致性

3. Leader審批關(guān)鍵決策，故障自動恢復，全程實時可觀測

下面逐一解讀這三項核心能力。

1.Leader智能編排，Teammate自主執(zhí)行

傳統(tǒng)的Multi-Agent方案往往需要使用者手動編排——你得預先定義誰先誰后、誰跟誰通信。JiuwenClaw AgentTeam把這件事交給了Leader Agent自己。

Leader做什么：

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

● 動態(tài)組建團隊：無需預先定義固定陣容。Leader基于團隊模版，根據(jù)目標描述動態(tài)分配角色和成員——調(diào)研專員、內(nèi)容撰寫、數(shù)據(jù)分析、質(zhì)量審核，按需生成。執(zhí)行過程中發(fā)現(xiàn)人手不足或方向調(diào)整，Leader還可以隨時增減成員，團隊組成始終跟著目標走。

● 規(guī)劃任務：將需求拆解為具體任務，建立依賴關(guān)系（比如"數(shù)據(jù)采集完成后，分析才能開始"）

● 分配與監(jiān)控：創(chuàng)建任務后，通過事件系統(tǒng)實時感知進展——誰認領(lǐng)了什么、誰完成了什么、誰遇到了問題。

Teammate做什么：

Teammate不需要被"指揮"——它們自主運轉(zhuǎn)：

●主動認領(lǐng)：收到任務創(chuàng)建事件后，自動瀏覽任務板，認領(lǐng)與自身能力匹配的任務；

● 獨立執(zhí)行：在自己的工作空間中完成調(diào)研、撰寫、分析等工作。遇到復雜任務，Teammate可以自行拆解為更細粒度的子步驟；遇到阻塞或不確定，可以主動向Leader發(fā)消息求助決策；

● 匯報結(jié)果：

任務完成后自動更新狀態(tài)，觸發(fā)事件通知Leader和其他依賴方。

這是一種分級自主協(xié)同：Leader基于目標和當前進度做戰(zhàn)略級拆分，Teammate在各自任務內(nèi)獨立決策和執(zhí)行，同時保留向上求助的通道——既不事事請示，也不閉門造車。這也是“協(xié)同工程”的核心思想。

兩者之間靠什么連接？任務和消息雙驅(qū)動。

JiuwenClaw AgentTeam的協(xié)同不只靠"派任務-做任務-交任務"這條線。團隊成員既通過任務協(xié)作驅(qū)動核心流程——認領(lǐng)、執(zhí)行、完成、解除下游阻塞；又通過任務外消息持續(xù)溝通——討論方案、協(xié)商優(yōu)先級、反饋問題、請求支援。兩條通道并行工作，適用于需要討論和協(xié)商的復雜場景，而不僅僅是機械地分發(fā)和匯總，已經(jīng)非常類似人類團隊協(xié)作的機制了！

所有交互——任務狀態(tài)變更、成員間消息、成員上下線——都通過事件總線實時傳遞。不是Leader每隔幾秒輪詢"你干完沒"，而是Teammate完成任務的瞬間，Leader就會被喚醒做下一步?jīng)Q策。

用戶: "幫我完成Q3市場分析報告"

Leader分析→ 組建團隊:
├── researcher (行業(yè)調(diào)研)
├── analyst (數(shù)據(jù)分析)
└── writer (報告撰寫)

Leader規(guī)劃任務:
├── task-1: 收集行業(yè)數(shù)據(jù)與競品動態(tài)→ researcher
├── task-2: 用戶調(diào)研與反饋整理→ researcher
├── task-3: 數(shù)據(jù)清洗與趨勢分析→ analyst (依賴task-1)
├── task-4: 競品對比分析→ analyst (依賴task-1, task-2)
└── task-5: 整合撰寫完整報告→ writer (依賴task-3, task-4)

Teammate并行執(zhí)行:
researcher 同時認領(lǐng)task-1, task-2 → 完成→ task-3, task-4 自動解除阻塞
analyst 認領(lǐng)task-3 → 完成→ 認領(lǐng)task-4 → 完成→ task-5 解除阻塞
writer 認領(lǐng)task-5 → 整合產(chǎn)出最終報告

Leader收尾:
所有任務完成→ 審查結(jié)果→ 關(guān)閉團隊→ 輸出最終交付物

這個過程中，任務依賴自動管理。task-3被task-1阻塞時，狀態(tài)為BLOCKED；task-1完成的瞬間，系統(tǒng)自動將task-3解除阻塞，變?yōu)榭烧J領(lǐng)狀態(tài)。Teammate不需要理解依賴圖，只需要認領(lǐng)和執(zhí)行。

2.Team Workspace：團隊共享工作區(qū)

多Agent協(xié)作繞不開一個現(xiàn)實問題：Agent之間怎么共享工作產(chǎn)物？

調(diào)研Teammate采集了行業(yè)數(shù)據(jù)，分析Teammate需要讀��；分析Teammate輸出了趨勢圖表，撰寫Teammate需要引用。如果每個Agent各干各的、互不可見，"團隊協(xié)作"就只是個空殼。

AgentTeam通過Team Workspace解決這個問題——一個團隊級的共享文件空間，所有成員均可透明訪問。

它是怎么工作的？

每個Teammate的工作目錄中都會自動掛載一個共享路徑，指向同一個團隊工作區(qū)。調(diào)研Teammate寫入的行業(yè)數(shù)據(jù)文件，分析Teammate立刻可見。不需要手動傳文件、不需要Agent之間互相發(fā)消息"你去看某某路徑"——直接讀寫，天然共享。

Teammate A (調(diào)研) 的工作目錄
├── workspace/ # 各自的獨立工作空間
└── .team/ # 共享工作區(qū)掛載點
└── artifacts/
├── data/ # 共享數(shù)據(jù)（采集數(shù)據(jù)、清洗結(jié)果）
├── docs/ # 共享文檔（分析報告、設計方案）
└── reports/ # 共享報告（最終交付物）
Teammate B (分析) 的工作目錄
├── workspace/
└── .team/ → 同一個共享工作區(qū) # 讀寫同一份文件

每個Teammate在自己的獨立工作空間中干活，需要跨成員協(xié)作時寫入共享區(qū)即可。

但共享帶來沖突風險——兩個Teammate同時寫同一個文件怎么辦？Team Workspace提供了三種沖突策略，按場景選擇：

策略

行為

適用場景

LOCK

文件級鎖定，同一時間只有一個寫入者

關(guān)鍵配置、核心數(shù)據(jù)源等不可并發(fā)修改的文件

MERGE

基于Git的并發(fā)寫入，自動提交并報告沖突

文檔類產(chǎn)物，允許多人并發(fā)編輯

LAST_WRITE_WINS

無沖突檢測，后寫覆蓋

日志、臨時草稿等無需一致性保證的文件

整個過程對Agent透明——框架內(nèi)置的工作區(qū)護欄自動攔截所有共享目錄的文件操作：寫入前檢查鎖、寫入后自動提交并通知其他成員、讀取前拉取最新版本。Agent只管讀寫文件，協(xié)調(diào)邏輯由框架處理。

在涉及代碼協(xié)作的場景中，框架還支持Git Worktree，為每個Teammate提供獨立的文件系統(tǒng)視圖，與Team Workspace的產(chǎn)物共享互不沖突。

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

真實的團隊協(xié)作不僅僅是"分任務-干活-匯總"。JiuwenClaw AgentTeam覆蓋了從任務創(chuàng)建到團隊解散的完整生命周期，包括審批、容錯和可觀測。

Leader審批：關(guān)鍵決策和敏感操作不放手

Agent自主執(zhí)行效率高，但不是所有決策都應該放手。AgentTeam提供兩層審批機制：

● Plan模式：對于重要任務，Teammate認領(lǐng)后不直接動手，而是先提交執(zhí)行計劃給Leader審批。Leader覺得合理就通過，覺得方向有偏就駁回并給出反饋，Teammate修訂后重新提交；

● 工具審批：當Teammate要執(zhí)行敏感操作（比如刪除重要文件、調(diào)用外部API、修改共享配置），審批請求自動發(fā)送給Leader，Leader決定是否允許；

兩者的核心原則一致：Agent可以自主建議，但關(guān)鍵決策權(quán)始終在Leader手上，避免"自由發(fā)揮后收拾爛攤子"。

事件驅(qū)動機制：讓團隊始終保持運轉(zhuǎn)

多Agent協(xié)作最怕的情況是隱性停滯——Teammate異常僵死無人察覺、任務長時間無人認領(lǐng)、已認領(lǐng)的任務遲遲不完成、成員間消息漏接……整個團隊看似還在運行，實際已經(jīng)卡住，卻沒人主動處理。

AgentTeam在底層搭了一套完整的事件驅(qū)動機制來規(guī)避這類風險。團隊里幾乎所有有意義的變化都會產(chǎn)生事件，外部事件和內(nèi)部事件雙管齊下：

● 任務事件：創(chuàng)建、認領(lǐng)、完成、取消、解除阻塞——任務板的每一次狀態(tài)翻轉(zhuǎn)都觸發(fā)事件

● 成員事件：上線、下線、狀態(tài)切換（空閑/忙碌/異常）、重啟——每個成員的生命周期變化都被捕獲

● 消息事件：點對點消息、廣播通知、審批請求——所有通信都走事件總線

● 內(nèi)部輪詢事件：框架內(nèi)定時產(chǎn)生的自檢事件（郵箱輪詢、任務板輪詢等），在沒有外部事件到來時仍定期喚醒Agent做自我檢查。

基于這些事件，框架構(gòu)建了一套激活處理邏輯：事件一旦觸發(fā)，相關(guān)的Agent就會被喚醒，重新審視自己該做什么——空閑的Teammate會主動檢查任務板并認領(lǐng)待領(lǐng)任務；Leader會監(jiān)控全局進度，識別長期未認領(lǐng)的PENDING任務和執(zhí)行超時的CLAIMED任務，必要時重新規(guī)劃或換人；消息接收方會優(yōu)先處理未讀。對于Teammate自身的異常僵死，框架也會通過心跳檢測和重啟機制自動恢復。配合定時輪詢兜底，即使某個事件偶發(fā)丟失，系統(tǒng)也能在下一輪自檢中自愈。

這套機制的價值不僅在于讓信息在團隊里流動起來，更在于讓團隊始終保持運轉(zhuǎn)——不會有任務長期無人認領(lǐng)、不會有Teammate掛掉沒人知道、不會有執(zhí)行停滯卻無人干預。單點問題始終能在可控時間內(nèi)被發(fā)現(xiàn)并處置，不會阻塞整個團隊協(xié)作。

持久化團隊：跨會話不丟狀態(tài)

團隊不一定是用完即棄的。啟用Persistent（持久化） 模式后，團隊可以跨會話保留：

● 會話結(jié)束時，團隊進入待機狀態(tài)，成員信息和配置持久化到數(shù)據(jù)庫；

● 下次使用時，一鍵恢復——創(chuàng)建新的會話空間，重新啟動隊員，無需重新組建團隊；

適合需要長期運轉(zhuǎn)的項目——每次打開都是熟悉的團隊陣容，直接開始新任務。

TeamMonitor：實時可觀測

AgentTeam的整個協(xié)作過程透明可見，TeamMonitor提供兩個維度的觀測能力：

查詢API——隨時查看團隊當前狀態(tài)：

查詢

內(nèi)容

團隊信息

團隊名稱、Leader、創(chuàng)建時間

成員狀態(tài)

每個成員的運行狀態(tài)（READY / BUSY / ERROR / SHUTDOWN）

任務進度

所有任務的狀態(tài)、認領(lǐng)人、依賴關(guān)系

消息記錄

成員間的通信歷史

事件流——實時訂閱團隊事件。任務完成、成員狀態(tài)變更、消息收發(fā)……所有事件都可以通過異步迭代器逐條消費。你可以據(jù)此構(gòu)建Dashboard、日志系統(tǒng)，或者觸發(fā)外部工作流。整個團隊的運轉(zhuǎn)不是黑盒，而是每一步都可追蹤、可審計。

openJiuwen Agent Team核心架構(gòu)

openJiuwen AgentTeam協(xié)同層是一套完整的多智能體編排基礎(chǔ)設施。

它的核心技術(shù)原理可以歸結(jié)為三點：

● 基于共享任務列表的一致性協(xié)同：所有成員共享同一份動態(tài)任務列表，各自基于團隊目標、任務定義和自身能力，自主認領(lǐng)并執(zhí)行任務，天然保證信息一致

● 消息和任務雙驅(qū)動模式：成員間既通過任務流轉(zhuǎn)驅(qū)動核心工作流，又通過任務外的消息通道持續(xù)推進討論和協(xié)商，覆蓋從結(jié)構(gòu)化執(zhí)行到非結(jié)構(gòu)化溝通的全場景

● 角色與工具工程：RolePolicy定義Leader和Teammate在團隊中的行為規(guī)范和決策邊界，TeamTools賦予團隊成員具體的協(xié)調(diào)操作能力——角色決定"該做什么"，工具決定"能做什么"。

AgentTeam協(xié)作流程如下：

下面講解其核心技術(shù)設計。

1.雙角色統(tǒng)一類：一套代碼，兩種人格

AgentTeam中Leader和Teammate共用同一個Agent架構(gòu)——TeamAgent。它根據(jù)運行時的角色身份展現(xiàn)不同行為：不同的工具集、不同的Prompt策略、不同的事件處理邏輯。

架構(gòu)上，TeamAgent將團隊協(xié)調(diào)層與單Agent執(zhí)行層（Harness SDK）做了清晰分離。協(xié)調(diào)層負責角色策略、事件路由和團隊管理；執(zhí)行層復用openJiuwen已有的Harness能力——提示詞、工具、護欄、任務循環(huán)。兩層獨立演進，互不干擾。

維度

Leader

Teammate

工具集

組建團隊、生成成員、創(chuàng)建/更新任務、關(guān)閉成員、審批計劃、審批工具調(diào)用、列出成員+ 共享工具

認領(lǐng)任務+ 共享工具

Prompt

角色策略+ 工作流+ 生命周期+ 團隊上下文

角色策略+ 團隊上下文

事件處理

觀察所有成員的狀態(tài)變化

僅處理與自身相關(guān)的事件

特有組件

模型分配器（隊員模型輪詢分配）、工作區(qū)管理器

成員狀態(tài)對象

共享工具（Leader和Teammate均可使用）：查看任務、發(fā)送消息/廣播。

這意味著新增一種團隊角色（比如"審核員"）不需要從頭開發(fā)一個新Agent，只需配置不同的工具集和Prompt策略。協(xié)調(diào)層的升級也不會影響單Agent的執(zhí)行能力，兩側(cè)獨立迭代。

2.事件驅(qū)動的協(xié)調(diào)循環(huán)

團隊協(xié)調(diào)的核心引擎是協(xié)調(diào)循環(huán)（CoordinatorLoop）——一個事件驅(qū)動的調(diào)度中樞，為每個TeamAgent提供"大腦"。

設計亮點：雙通道事件入口。

● 實時通道：傳輸層事件（任務完成、消息到達、成員狀態(tài)變化）立即入隊，延遲極低；

● 輪詢通道：兩個獨立定時器分別檢查郵箱和任務板（間隔可配置），作為兜底——即使傳輸層偶發(fā)丟事件，輪詢保證最終一致性。

事件分發(fā)器根據(jù)事件類型智能路由：

● 用戶輸入→ 啟動或引導Agent執(zhí)行

● 任務事件→ 推動空閑Agent認領(lǐng)新任務

● 消息事件→ 處理未讀消息，轉(zhuǎn)化為Agent輸入

● 成員事件→ 更新成員跟蹤狀態(tài)，觸發(fā)過期任務檢查

特別值得一提的是空閑推動機制：當Teammate完成任務變?yōu)榭臻e時，事件分發(fā)器會主動檢查任務板上是否有可認領(lǐng)的任務，如果有就"推一把"——把任務摘要注入Agent的上下文，驅(qū)動它繼續(xù)工作。Leader端則檢測長期未認領(lǐng)的待領(lǐng)任務和超時的已認領(lǐng)任務，必要時重新規(guī)劃或重新分配。

這套機制讓Agent平時處于"休眠"狀態(tài)，有事件才被喚醒，資源消耗極低。而輪詢作為兜底，保證即使消息偶發(fā)丟失系統(tǒng)也不會卡死——兼顧了低延遲和高可靠。

3.分段式Prompt注入（TeamRail）

團隊上下文信息（角色策略、團隊成員、任務狀態(tài)）需要注入Agent的系統(tǒng)Prompt。傳統(tǒng)做法是拼接成一個大字符串，每次全量重建。AgentTeam采用了分段注入——將團隊Prompt拆解為7個獨立片段（Section），每個片段承載一類上下文信息，按優(yōu)先級有序組裝：

優(yōu)先級

片段

更新策略

1

角色策略

當前成員的身份和行為規(guī)范

靜態(tài)

2

工作流

Leader的團隊工作流程指引

靜態(tài)

3

生命周期

臨時團隊或持久化團隊的策略差異

靜態(tài)

4

人設

當前成員的角色人設描述

靜態(tài)

5

用戶自定義

用戶注入的額外指令

靜態(tài)

6

團隊信息

團隊名稱、描述等元數(shù)據(jù)

動態(tài)

7

成員關(guān)系

當前團隊的成員列表及角色

動態(tài)

前5個片段在團隊初始化時一次構(gòu)建，后續(xù)直接復用。后2個片段（團隊信息、成員關(guān)系）會隨團隊運行發(fā)生變化，框架通過時間戳緩存按需刷新——只有數(shù)據(jù)真正變化時才重新查詢，團隊運行穩(wěn)定時組裝開銷幾乎為零。

分段帶來的另一個好處是可擴展：后續(xù)需要給Agent注入新的團隊上下文（比如共享知識庫摘要），只需增加一個片段，不會影響已有的角色策略和工作流。對于長時間運行的團隊，動態(tài)緩存也避免了每次模型調(diào)用都重新查數(shù)據(jù)庫。

4.可插拔基礎(chǔ)設施

AgentTeam的通信和存儲完全可插拔——框架內(nèi)置了適合單機場景的默認實現(xiàn)，同時支持替換為企業(yè)級方案：

傳輸層（Messager）：

單機默認使用ZMQ輕量通信；分布式場景可切換為Pulsar、RocketMQ等消息隊列。

后端

場景

特征

ZMQ

單機多進程

輕量級，低延遲，點對點直連+ 發(fā)布/訂閱廣播

Pulsar / RocketMQ

跨機分布式

持久化隊列，高可用，支持大規(guī)模集群組網(wǎng)

存儲層（TeamDatabase）：

單機默認使用SQLite；分布式場景可切換為PostgreSQL等關(guān)系數(shù)據(jù)庫。

后端

場景

特征

SQLite

單機、默認

WAL模式，異步IO，跨會話持久化

PostgreSQL

分布式、生產(chǎn)

多節(jié)點共享狀態(tài)，高并發(fā)，事務保障

需要自定義？通過注冊表一行代碼即可接入Redis、PostgreSQL等第三方后端。所有注冊表延遲加載——內(nèi)置實現(xiàn)在首次使用時才初始化，可選依賴缺失時優(yōu)雅跳過。接入新的后端只需調(diào)整配置，無需修改業(yè)務邏輯。

JiuwenClaw簡介和行業(yè)案例

JiuwenClaw ——由云AgentArts、2012九問團隊和社區(qū)廣大開發(fā)者聯(lián)合在openJiuwen共建的“小龍蝦“智能管家�！癈law”象征著精準的抓取與連接，能夠?qū)⒋笳Z言模型的強大能力，通過你日常使用的各類通訊應用，直接延伸至你的指尖。

JiuwenClaw基于Python開發(fā)，天然擁有良好的生態(tài)兼容性和擴展能力，在模型接入方面，JiuwenClaw支持華為云MaaS 等主流模型平臺，用戶只需簡單配置即可調(diào)用華為云的模型服務。此外，JiuwenClaw 已實現(xiàn)與小藝開放平臺的無縫對接，華為手機用戶可以通過小藝直接喚醒并使用JiuwenClaw，享受隨叫隨到的智能服務。

JiuwenClaw的獨特優(yōu)勢是“懂你所想，自主演進”。針對你的各種復雜輸入場景，如任務追加、打斷、修改等，它就是懂你的貼身任務管家，將你的各類需求排出優(yōu)先級，并有條不紊地完成；同時它也能在你身邊自主演進，當你對他表達不滿或運行出錯時，它會根據(jù)你的反饋自動調(diào)整相應技能，全心全意為你服務。在連接渠道方面，JiuwenClaw已實現(xiàn)鴻蒙小藝、飛書、釘釘、Discord、Telegram、WhatsApp等channel的無縫接入，并將持續(xù)拓展至更多元平臺。無論是進行復雜代碼編寫、尋求即時的技術(shù)支持，還是管理日程與信息流，JiuwenClaw都能讓你從任何地方、以最熟悉的方式，喚出一個始終在線、數(shù)據(jù)自主的專屬AI助理。

JiuwenClaw在企業(yè)級辦公智能體產(chǎn)品OfficeClaw中的實踐落地

就在剛剛過去的4月16日，華為云舉辦OfficeClaw辦公智能體新品體驗會，并啟動了產(chǎn)品邀測。

OfficeClaw的創(chuàng)意來源于開源項目，華為云研發(fā)團隊捕捉到這一創(chuàng)新價值，集結(jié)數(shù)十位研發(fā)人員開展聯(lián)合攻關(guān)，依托華為自主創(chuàng)新全開源的JiuwenClaw項目為技術(shù)底座，基于華為云AI基礎(chǔ)設施能力和AgentArts智能體開發(fā)平臺，提供企業(yè)級安全防護、分鐘級定障精準評估、精準上下文、羽量沙箱百毫秒啟動、Agent自進化等五大核心能力，讓企業(yè)成百上千個AI智能體能既快又穩(wěn)、管得住、用得好。

為什么Coordination Engineering是下一跳？

當行業(yè)還在繼續(xù)深化Harness Engineering（提示詞工程、工具編排、護欄機制、任務循環(huán)、工作空間管理）時，真正的增量空間正在向“團隊化交付”轉(zhuǎn)移：一個Agent很難覆蓋完整鏈路，但一個AgentTeam可以把復雜任務拆成并行工序、把交接變成機制、把治理變成可觀測與可恢復的系統(tǒng)。

因此，Coordination Engineering不是一個簡單的概念，而是Harness Engineering合乎邏輯的下一跳：在每個Teammate內(nèi)部保留完整的Harness SDK Agent能力，在團隊層疊加協(xié)同編排與治理能力，讓多個強個體以更低摩擦組織成高效團隊。

同時，JiuwenClaw提出的Team Skill機制也值得關(guān)注：它能把AgentTeam執(zhí)行過程中的團隊協(xié)作流程沉淀為可復用的“團隊SOP”協(xié)作模板，并在每次使用后自動優(yōu)化——用得越多，SOP越精準，進一步增強Evolution Engineering能力。

如果你正在尋找一條從單Agent走向團隊協(xié)同的工程路徑，不妨直接從開源地址上手，用真實任務跑一遍AgentTeam，親手見證“Coordination Engineering”所帶來的高效與便捷的差異化體驗！

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

個人觀點，僅供參考