作指南：任務(wù)分配、工作交接與沖突序列化)
Beads 多 Agent 協(xié)作指南任務(wù)分配、工作交接與沖突序列化【免費(fèi)下載鏈接】beadsBeads - A memory upgrade for your coding agent項(xiàng)目地址: https://gitcode.com/GitHub_Trending/beads1/beads本指南面向使用 Beads 驅(qū)動(dòng)多個(gè) AI Agent 協(xié)同工作的場(chǎng)景圍繞 docs/multi-agent/coordination.md 展開講解如何在 Agent 之間分配與原子認(rèn)領(lǐng)claim工作、通過評(píng)論與標(biāo)簽完成交接、用 merge slot 串行化沖突密集的合并工作以及跨倉庫協(xié)調(diào)任務(wù)依賴。讀完本文你將掌握一套可落地的多 Agent 編排命令組合并能理解這些命令在 Beads 存儲(chǔ)層internal/storage/merge_slot.go背后的原子性保證。工作分配Assign 與 Claim多 Agent 協(xié)作的第一步是確定誰做什么。Beads 提供兩條互補(bǔ)的路徑指派assign由協(xié)調(diào)者決定歸屬認(rèn)領(lǐng)claim由 Agent 自主搶占。# 把 issue 指派給某個(gè) Agent bd assign bd-42 agent-1 # 原子地認(rèn)領(lǐng)一個(gè) issue把 assignee 設(shè)為自己狀態(tài)置為 in_progress bd update bd-42 --claim # 認(rèn)領(lǐng)第一個(gè)匹配你過濾條件的 ready issue bd ready --claim --json # 釋放已認(rèn)領(lǐng)的 issue bd assign bd-42 # 清空 assignee bd update bd-42 --status open # 讓它重新可被認(rèn)領(lǐng)從源碼看bd assign實(shí)際上是bd update id --assignee name的簡(jiǎn)寫形式cmd/bd/assign.go參數(shù)名傳空字符串即可清空 assignee。它附帶一個(gè)重要的安全選項(xiàng)# 僅當(dāng)當(dāng)前 assignee 是 agent-1 時(shí)才轉(zhuǎn)移給 agent-2holder-aware 轉(zhuǎn)移避免覆蓋他人 bd update bd-42 --if-assignee agent-1 -a agent-2 # 強(qiáng)制覆蓋他人 in_progress 的認(rèn)領(lǐng)僅限確認(rèn)對(duì)方已崩潰、租約過期等廢棄場(chǎng)景 bd assign bd-42 agent-2 --force--force的注釋明確警告它用于abandoned claims崩潰的 Agent、過期的租約并優(yōu)先推薦bd reclaim走正規(guī)回收流程。日常協(xié)作中應(yīng)盡量避免覆蓋其他 Agent 的活躍認(rèn)領(lǐng)。檢查已分配的工作# agent-1 正在做什么 bd list --assignee agent-1 --status in_progress # 什么工作對(duì) agent-1 是就緒的 bd ready --assignee agent-1 # JSON 輸出方便 Agent 解析 bd list --assignee agent-1 --json--json在整個(gè) CLI 中普遍可用是 Agent 消費(fèi)結(jié)構(gòu)化數(shù)據(jù)的標(biāo)準(zhǔn)接口——例如 merge-slot 的check/acquire/release、ready 的--claim都支持 JSON 輸出見 cmd/bd/merge_slot.go 中jsonOutput分支。交接模式順序、并行與扇出扇入順序交接Sequential HandoffAgent A 完成工作后用評(píng)論說明上下文再把 assignee 轉(zhuǎn)移給 Agent B# Agent A bd comment bd-42 API complete, ready for review bd assign bd-42 agent-b # Agent B 接手 bd list --assignee agent-b # 看到 bd-42 bd update bd-42 --claim并行工作Parallel Work協(xié)調(diào)者把不同 issue 分給不同 Agent各 Agent 獨(dú)立認(rèn)領(lǐng)后并行推進(jìn)協(xié)調(diào)者用一條命令持續(xù)監(jiān)控# 協(xié)調(diào)者 bd assign bd-42 agent-a bd assign bd-43 agent-b bd assign bd-44 agent-c # 每個(gè) Agent 認(rèn)領(lǐng)自己的 issue 獨(dú)立工作 bd update bd-42 --claim # 協(xié)調(diào)者監(jiān)控進(jìn)度 bd list --status in_progress --json扇出 / 扇入Fan-Out / Fan-In把一個(gè)大任務(wù)拆成多個(gè)部分并行執(zhí)行再匯聚回一個(gè)合并點(diǎn)# 扇出在 epic 下創(chuàng)建子任務(wù) bd create Part A --parent bd-epic bd create Part B --parent bd-epic bd create Part C --parent bd-epic bd assign bd-epic.1 agent-a bd assign bd-epic.2 agent-b bd assign bd-epic.3 agent-c # 扇入等待所有部分完成一次調(diào)用只加一條依賴 bd dep add bd-merge bd-epic.1 bd dep add bd-merge bd-epic.2 bd dep add bd-merge bd-epic.3關(guān)于 epic 上的 size/effort 標(biāo)簽bd create --parent默認(rèn)會(huì)把父級(jí)的標(biāo)簽繼承到子級(jí)詳見 docs/core-concepts/labels.md。如果bd-epic帶有l(wèi)arge或sp:13這類規(guī)模標(biāo)簽子任務(wù)也會(huì)繼承它導(dǎo)致bd list -l large返回整棵子樹而失去篩選意義。需要按子任務(wù)單獨(dú)估算時(shí)創(chuàng)建時(shí)傳入--no-inherit-labels即可bd create Part A --parent bd-epic --no-inherit-labels -l small結(jié)構(gòu)化扇出的進(jìn)階方案對(duì)于正式的大型 epicbd swarm可以創(chuàng)建一個(gè) swarm molecule 來編排并跟蹤并行工作見 cmd/bd/swarm.gobd swarm create bd-epic-123 # 為 epic 創(chuàng)建 swarm bd swarm create bd-epic-123 --coordinatorobserver/ # 指定協(xié)調(diào)者身份 bd swarm status gt-swarm-456 # 通過 swarm molecule 查看狀態(tài)swarm molecule 與 epic 之間通過 relate-to 依賴關(guān)聯(lián)對(duì)單個(gè)任務(wù)使用bd swarm create bd-task-456會(huì)自動(dòng)將其包裝成 swarm源碼注釋為 Auto-wrap single issue。這比手工多次bd create --parent更適合需要跟蹤整體進(jìn)度的場(chǎng)景。Agent 發(fā)現(xiàn)沒有注冊(cè)表靠狀態(tài)聚合Beads沒有 Agent 注冊(cè)表——assignee 只是普通字符串不存在Agent 上線/下線的概念。想知道當(dāng)前哪些 Agent 活躍按 assignee 聚合 in_progress 的工作即可bd list --status in_progress --json這個(gè)設(shè)計(jì)意味著任何字符串都可以作為 assignee 使用Agent 身份完全由工作數(shù)據(jù)派生天然支持異構(gòu) Agent不同工具鏈、不同會(huì)話在同一倉庫里協(xié)作。沖突預(yù)防原子認(rèn)領(lǐng)與 Merge Slot原子認(rèn)領(lǐng)Atomic Claims多個(gè) Agent 從同一個(gè) ready 隊(duì)列取活時(shí)--claim是原子的第一個(gè)認(rèn)領(lǐng)者勝出且重復(fù)認(rèn)領(lǐng)自己已持有的 issue 是冪等的。因此當(dāng) Agent 自主挑選工作時(shí)優(yōu)先用 claim 而不是 assignbd ready --claim --json底層實(shí)現(xiàn)上bd ready --claim走的是ReadyClaimer角色cmd/bd/ready.go它通過 store 的ReadyClaimer()拿到 claimer 后調(diào)用ClaimNext。而 issueops/claimer.go 中明確ClaimRequest 描述的是one atomic compare-and-set claim整個(gè)請(qǐng)求作為一個(gè)原子操作提交——這正是第一個(gè)認(rèn)領(lǐng)者勝出的保證來源。使用限制源碼中直接校驗(yàn)--claim不能與--gated、--mol、--explain組合使用同時(shí)會(huì)觸發(fā)只讀檢查CheckReadonly(ready --claim)。Merge Slot沖突密集工作的獨(dú)占串行化對(duì)于誰先合并誰這類天然沖突密集的工作典型如 merge-queue 的沖突解決Beads 提供merge slot——一種獨(dú)占訪問原語同一時(shí)刻只允許一個(gè) Agent 持有。每個(gè)項(xiàng)目只有一個(gè) merge slot bead命名由 issue 前綴推導(dǎo)而來例如bd-merge-slot# 為當(dāng)前項(xiàng)目創(chuàng)建 merge slot bd merge-slot create # 檢查可用性 bd merge-slot check # 開始前獲取完成后釋放 bd merge-slot acquire bd merge-slot release狀態(tài)模型來自 cmd/bd/merge_slot.go 與 internal/storage/merge_slot.go字段含義statusopenslot 可用statusin_progressslot 被持有metadata.holder當(dāng)前持有者metadata.waiters按優(yōu)先級(jí)排序的等待隊(duì)列實(shí)現(xiàn)細(xì)節(jié)ID 推導(dǎo)MergeSlotID讀取配置issue_prefix如gt拼出prefix-merge-slot未配置時(shí)回退為bd-merge-slot。可發(fā)現(xiàn)性標(biāo)簽每個(gè) slot bead 都帶gt:slot標(biāo)簽工具無需知道確切 ID 就能定位它。冪等創(chuàng)建create重復(fù)執(zhí)行不會(huì)報(bào)錯(cuò)直接返回已存在的 slot。原子獲取acquire在RunInTransaction內(nèi)完成檢查狀態(tài) → 置為 in_progress → 寫入 holder的原子 check-and-set兩個(gè) Agent 不可能同時(shí)拿到 slot。等待隊(duì)列slot 被占時(shí)acquire默認(rèn)失敗并提示Use --wait to add yourself to the waiters queue傳入--wait則把自己加入 waiters去重并返回排隊(duì)位置。# 指定獲取者身份默認(rèn)取 BEADS_ACTOR 環(huán)境變量 bd merge-slot acquire --holder agent-1 # slot 被占用時(shí)排隊(duì)等待 bd merge-slot acquire --wait # 釋放時(shí)校驗(yàn)持有者防止誤釋放他人占用的 slot bd merge-slot release --holder agent-1# 釋放校驗(yàn)失敗的示例slot 被 agent-1 持有agent-2 無法釋放 $ bd merge-slot release --holder agent-2 slot held by agent-1, not agent-2釋放操作同樣是冪等的slot 已是 open 時(shí)重復(fù) release 直接返回成功。JSON 輸出可用于 Agent 編程式判斷available、holder、waiters、acquired、waiting、position等字段。需要留意merge-slot 系列命令在 proxied-server 模式下不可用源碼中四個(gè)子命令均顯式拒絕。通信模式評(píng)論與標(biāo)簽通過評(píng)論Comments評(píng)論是 Agent 之間傳遞上下文的主要載體評(píng)論內(nèi)容會(huì)進(jìn)入完整的事件歷史# Agent A 留下說明 bd comment bd-42 Completed API, needs frontend integration # Agent B 讀取 bd comments bd-42通過標(biāo)簽Labels標(biāo)簽適合做可過濾的狀態(tài)信號(hào)配合--label-any讓下游 Agent 精準(zhǔn)拉取自己關(guān)心的批次# 標(biāo)記為待評(píng)審 bd update bd-42 --add-label needs-review # Agent B 按標(biāo)簽過濾 bd list --label-any needs-review推薦的狀態(tài)標(biāo)簽約定needs-review、blocked、ready詳見本文末尾最佳實(shí)踐?？鐐}庫協(xié)調(diào)Agent 可以協(xié)調(diào)跨越多個(gè)倉庫的工作當(dāng)一個(gè) issue 依賴另一個(gè)項(xiàng)目交付的能力時(shí)使用external:前綴的外部引用依賴cmd/bd/dep.go# 依賴由另一個(gè)項(xiàng)目交付的能力 bd dep add bd-42 external:backend:api-ready更多跨倉庫的路由multi-repo routing、聚合視圖以及貢獻(xiàn)者/團(tuán)隊(duì)工作流參見 docs/multi-agent/routing.md 與 docs/multi-agent/multi-repo-migration.md。最佳實(shí)踐清單明確歸屬Clear ownership——用 assign 或 claim 讓每個(gè) issue 恰好有一個(gè)負(fù)責(zé)人避免三個(gè)和尚沒水喝。交接留痕Document handoffs——用評(píng)論說明上下文讓接手的 Agent 無需考古就能繼續(xù)。用標(biāo)簽表達(dá)狀態(tài)Use labels for status——統(tǒng)一使用needs-review、blocked、ready等約定標(biāo)簽配合--label-any做隊(duì)列篩選。主動(dòng)避免沖突Avoid conflicts——Agent 自主取活時(shí)優(yōu)先原子 claim沖突密集的工作如合并沖突解決用 merge slot 串行化杜絕多個(gè) Agent 同時(shí)改同一處導(dǎo)致沖突雪崩。持續(xù)監(jiān)控進(jìn)度Monitor progress——定期用bd list --status in_progress --json匯總在途工作。會(huì)話結(jié)束同步Sync at session end——每個(gè) Agent 工作結(jié)束時(shí)運(yùn)行bd dolt push讓其他 Agent 立刻看到你的更新同步機(jī)制詳見 docs/core-concepts/sync-concepts.md。小結(jié)Beads 的多 Agent 協(xié)調(diào)能力建立在三個(gè)核心機(jī)制之上assign/claim 雙通道歸屬控制、評(píng)論標(biāo)簽的輕量通信、merge slot 的獨(dú)占串行化。其中原子 claim 由 ReadyClaimer 角色的 compare-and-set 保證merge slot 由事務(wù)內(nèi)的 check-and-set 保證兩者都直接落在 Dolt 存儲(chǔ)層internal/storage/merge_slot.go因此無論多少個(gè) Agent 并發(fā)操作狀態(tài)都不會(huì)錯(cuò)亂。配合bd swarm編排大型 epic、external:依賴打通跨倉庫協(xié)作這套模式足以支撐從兩三個(gè) Agent 的小團(tuán)隊(duì)到多倉庫、多 Agent 的規(guī)?；⑿虚_發(fā)?！久赓M(fèi)下載鏈接】beadsBeads - A memory upgrade for your coding agent項(xiàng)目地址: https://gitcode.com/GitHub_Trending/beads1/beads創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Beads 多 Agent 協(xié)作指南：任務(wù)分配、工作交接與沖突序列化
Beads 多 Agent 協(xié)作指南任務(wù)分配、工作交接與沖突序列化【免費(fèi)下載鏈接】beadsBeads - A memory upgrade for your coding agent項(xiàng)目地址: https://gitcode.com/GitHub_Trending/beads1/beads本指南面向使用 Beads 驅(qū)動(dòng)多個(gè) AI Agent 協(xié)同工作的場(chǎng)景圍繞 docs/multi-agent/coordination.md 展開講解如何在 Agent 之間分配與原子認(rèn)領(lǐng)claim工作、通過評(píng)論與標(biāo)簽完成交接、用 merge slot 串行化沖突密集的合并工作以及跨倉庫協(xié)調(diào)任務(wù)依賴。讀完本文你將掌握一套可落地的多 Agent 編排命令組合并能理解這些命令在 Beads 存儲(chǔ)層internal/storage/merge_slot.go背后的原子性保證。工作分配Assign 與 Claim多 Agent 協(xié)作的第一步是確定誰做什么。Beads 提供兩條互補(bǔ)的路徑指派assign由協(xié)調(diào)者決定歸屬認(rèn)領(lǐng)claim由 Agent 自主搶占。# 把 issue 指派給某個(gè) Agent bd assign bd-42 agent-1 # 原子地認(rèn)領(lǐng)一個(gè) issue把 assignee 設(shè)為自己狀態(tài)置為 in_progress bd update bd-42 --claim # 認(rèn)領(lǐng)第一個(gè)匹配你過濾條件的 ready issue bd ready --claim --json # 釋放已認(rèn)領(lǐng)的 issue bd assign bd-42 # 清空 assignee bd update bd-42 --status open # 讓它重新可被認(rèn)領(lǐng)從源碼看bd assign實(shí)際上是bd update id --assignee name的簡(jiǎn)寫形式cmd/bd/assign.go參數(shù)名傳空字符串即可清空 assignee。它附帶一個(gè)重要的安全選項(xiàng)# 僅當(dāng)當(dāng)前 assignee 是 agent-1 時(shí)才轉(zhuǎn)移給 agent-2holder-aware 轉(zhuǎn)移避免覆蓋他人 bd update bd-42 --if-assignee agent-1 -a agent-2 # 強(qiáng)制覆蓋他人 in_progress 的認(rèn)領(lǐng)僅限確認(rèn)對(duì)方已崩潰、租約過期等廢棄場(chǎng)景 bd assign bd-42 agent-2 --force--force的注釋明確警告它用于abandoned claims崩潰的 Agent、過期的租約并優(yōu)先推薦bd reclaim走正規(guī)回收流程。日常協(xié)作中應(yīng)盡量避免覆蓋其他 Agent 的活躍認(rèn)領(lǐng)。檢查已分配的工作# agent-1 正在做什么 bd list --assignee agent-1 --status in_progress # 什么工作對(duì) agent-1 是就緒的 bd ready --assignee agent-1 # JSON 輸出方便 Agent 解析 bd list --assignee agent-1 --json--json在整個(gè) CLI 中普遍可用是 Agent 消費(fèi)結(jié)構(gòu)化數(shù)據(jù)的標(biāo)準(zhǔn)接口——例如 merge-slot 的check/acquire/release、ready 的--claim都支持 JSON 輸出見 cmd/bd/merge_slot.go 中jsonOutput分支。交接模式順序、并行與扇出扇入順序交接Sequential HandoffAgent A 完成工作后用評(píng)論說明上下文再把 assignee 轉(zhuǎn)移給 Agent B# Agent A bd comment bd-42 API complete, ready for review bd assign bd-42 agent-b # Agent B 接手 bd list --assignee agent-b # 看到 bd-42 bd update bd-42 --claim并行工作Parallel Work協(xié)調(diào)者把不同 issue 分給不同 Agent各 Agent 獨(dú)立認(rèn)領(lǐng)后并行推進(jìn)協(xié)調(diào)者用一條命令持續(xù)監(jiān)控# 協(xié)調(diào)者 bd assign bd-42 agent-a bd assign bd-43 agent-b bd assign bd-44 agent-c # 每個(gè) Agent 認(rèn)領(lǐng)自己的 issue 獨(dú)立工作 bd update bd-42 --claim # 協(xié)調(diào)者監(jiān)控進(jìn)度 bd list --status in_progress --json扇出 / 扇入Fan-Out / Fan-In把一個(gè)大任務(wù)拆成多個(gè)部分并行執(zhí)行再匯聚回一個(gè)合并點(diǎn)# 扇出在 epic 下創(chuàng)建子任務(wù) bd create Part A --parent bd-epic bd create Part B --parent bd-epic bd create Part C --parent bd-epic bd assign bd-epic.1 agent-a bd assign bd-epic.2 agent-b bd assign bd-epic.3 agent-c # 扇入等待所有部分完成一次調(diào)用只加一條依賴 bd dep add bd-merge bd-epic.1 bd dep add bd-merge bd-epic.2 bd dep add bd-merge bd-epic.3關(guān)于 epic 上的 size/effort 標(biāo)簽bd create --parent默認(rèn)會(huì)把父級(jí)的標(biāo)簽繼承到子級(jí)詳見 docs/core-concepts/labels.md。如果bd-epic帶有l(wèi)arge或sp:13這類規(guī)模標(biāo)簽子任務(wù)也會(huì)繼承它導(dǎo)致bd list -l large返回整棵子樹而失去篩選意義。需要按子任務(wù)單獨(dú)估算時(shí)創(chuàng)建時(shí)傳入--no-inherit-labels即可bd create Part A --parent bd-epic --no-inherit-labels -l small結(jié)構(gòu)化扇出的進(jìn)階方案對(duì)于正式的大型 epicbd swarm可以創(chuàng)建一個(gè) swarm molecule 來編排并跟蹤并行工作見 cmd/bd/swarm.gobd swarm create bd-epic-123 # 為 epic 創(chuàng)建 swarm bd swarm create bd-epic-123 --coordinatorobserver/ # 指定協(xié)調(diào)者身份 bd swarm status gt-swarm-456 # 通過 swarm molecule 查看狀態(tài)swarm molecule 與 epic 之間通過 relate-to 依賴關(guān)聯(lián)對(duì)單個(gè)任務(wù)使用bd swarm create bd-task-456會(huì)自動(dòng)將其包裝成 swarm源碼注釋為 Auto-wrap single issue。這比手工多次bd create --parent更適合需要跟蹤整體進(jìn)度的場(chǎng)景。Agent 發(fā)現(xiàn)沒有注冊(cè)表靠狀態(tài)聚合Beads沒有 Agent 注冊(cè)表——assignee 只是普通字符串不存在Agent 上線/下線的概念。想知道當(dāng)前哪些 Agent 活躍按 assignee 聚合 in_progress 的工作即可bd list --status in_progress --json這個(gè)設(shè)計(jì)意味著任何字符串都可以作為 assignee 使用Agent 身份完全由工作數(shù)據(jù)派生天然支持異構(gòu) Agent不同工具鏈、不同會(huì)話在同一倉庫里協(xié)作。沖突預(yù)防原子認(rèn)領(lǐng)與 Merge Slot原子認(rèn)領(lǐng)Atomic Claims多個(gè) Agent 從同一個(gè) ready 隊(duì)列取活時(shí)--claim是原子的第一個(gè)認(rèn)領(lǐng)者勝出且重復(fù)認(rèn)領(lǐng)自己已持有的 issue 是冪等的。因此當(dāng) Agent 自主挑選工作時(shí)優(yōu)先用 claim 而不是 assignbd ready --claim --json底層實(shí)現(xiàn)上bd ready --claim走的是ReadyClaimer角色cmd/bd/ready.go它通過 store 的ReadyClaimer()拿到 claimer 后調(diào)用ClaimNext。而 issueops/claimer.go 中明確ClaimRequest 描述的是one atomic compare-and-set claim整個(gè)請(qǐng)求作為一個(gè)原子操作提交——這正是第一個(gè)認(rèn)領(lǐng)者勝出的保證來源。使用限制源碼中直接校驗(yàn)--claim不能與--gated、--mol、--explain組合使用同時(shí)會(huì)觸發(fā)只讀檢查CheckReadonly(ready --claim)。Merge Slot沖突密集工作的獨(dú)占串行化對(duì)于誰先合并誰這類天然沖突密集的工作典型如 merge-queue 的沖突解決Beads 提供merge slot——一種獨(dú)占訪問原語同一時(shí)刻只允許一個(gè) Agent 持有。每個(gè)項(xiàng)目只有一個(gè) merge slot bead命名由 issue 前綴推導(dǎo)而來例如bd-merge-slot# 為當(dāng)前項(xiàng)目創(chuàng)建 merge slot bd merge-slot create # 檢查可用性 bd merge-slot check # 開始前獲取完成后釋放 bd merge-slot acquire bd merge-slot release狀態(tài)模型來自 cmd/bd/merge_slot.go 與 internal/storage/merge_slot.go字段含義statusopenslot 可用statusin_progressslot 被持有metadata.holder當(dāng)前持有者metadata.waiters按優(yōu)先級(jí)排序的等待隊(duì)列實(shí)現(xiàn)細(xì)節(jié)ID 推導(dǎo)MergeSlotID讀取配置issue_prefix如gt拼出prefix-merge-slot未配置時(shí)回退為bd-merge-slot。可發(fā)現(xiàn)性標(biāo)簽每個(gè) slot bead 都帶gt:slot標(biāo)簽工具無需知道確切 ID 就能定位它。冪等創(chuàng)建create重復(fù)執(zhí)行不會(huì)報(bào)錯(cuò)直接返回已存在的 slot。原子獲取acquire在RunInTransaction內(nèi)完成檢查狀態(tài) → 置為 in_progress → 寫入 holder的原子 check-and-set兩個(gè) Agent 不可能同時(shí)拿到 slot。等待隊(duì)列slot 被占時(shí)acquire默認(rèn)失敗并提示Use --wait to add yourself to the waiters queue傳入--wait則把自己加入 waiters去重并返回排隊(duì)位置。# 指定獲取者身份默認(rèn)取 BEADS_ACTOR 環(huán)境變量 bd merge-slot acquire --holder agent-1 # slot 被占用時(shí)排隊(duì)等待 bd merge-slot acquire --wait # 釋放時(shí)校驗(yàn)持有者防止誤釋放他人占用的 slot bd merge-slot release --holder agent-1# 釋放校驗(yàn)失敗的示例slot 被 agent-1 持有agent-2 無法釋放 $ bd merge-slot release --holder agent-2 slot held by agent-1, not agent-2釋放操作同樣是冪等的slot 已是 open 時(shí)重復(fù) release 直接返回成功。JSON 輸出可用于 Agent 編程式判斷available、holder、waiters、acquired、waiting、position等字段。需要留意merge-slot 系列命令在 proxied-server 模式下不可用源碼中四個(gè)子命令均顯式拒絕。通信模式評(píng)論與標(biāo)簽通過評(píng)論Comments評(píng)論是 Agent 之間傳遞上下文的主要載體評(píng)論內(nèi)容會(huì)進(jìn)入完整的事件歷史# Agent A 留下說明 bd comment bd-42 Completed API, needs frontend integration # Agent B 讀取 bd comments bd-42通過標(biāo)簽Labels標(biāo)簽適合做可過濾的狀態(tài)信號(hào)配合--label-any讓下游 Agent 精準(zhǔn)拉取自己關(guān)心的批次# 標(biāo)記為待評(píng)審 bd update bd-42 --add-label needs-review # Agent B 按標(biāo)簽過濾 bd list --label-any needs-review推薦的狀態(tài)標(biāo)簽約定needs-review、blocked、ready詳見本文末尾最佳實(shí)踐?？鐐}庫協(xié)調(diào)Agent 可以協(xié)調(diào)跨越多個(gè)倉庫的工作當(dāng)一個(gè) issue 依賴另一個(gè)項(xiàng)目交付的能力時(shí)使用external:前綴的外部引用依賴cmd/bd/dep.go# 依賴由另一個(gè)項(xiàng)目交付的能力 bd dep add bd-42 external:backend:api-ready更多跨倉庫的路由multi-repo routing、聚合視圖以及貢獻(xiàn)者/團(tuán)隊(duì)工作流參見 docs/multi-agent/routing.md 與 docs/multi-agent/multi-repo-migration.md。最佳實(shí)踐清單明確歸屬Clear ownership——用 assign 或 claim 讓每個(gè) issue 恰好有一個(gè)負(fù)責(zé)人避免三個(gè)和尚沒水喝。交接留痕Document handoffs——用評(píng)論說明上下文讓接手的 Agent 無需考古就能繼續(xù)。用標(biāo)簽表達(dá)狀態(tài)Use labels for status——統(tǒng)一使用needs-review、blocked、ready等約定標(biāo)簽配合--label-any做隊(duì)列篩選。主動(dòng)避免沖突Avoid conflicts——Agent 自主取活時(shí)優(yōu)先原子 claim沖突密集的工作如合并沖突解決用 merge slot 串行化杜絕多個(gè) Agent 同時(shí)改同一處導(dǎo)致沖突雪崩。持續(xù)監(jiān)控進(jìn)度Monitor progress——定期用bd list --status in_progress --json匯總在途工作。會(huì)話結(jié)束同步Sync at session end——每個(gè) Agent 工作結(jié)束時(shí)運(yùn)行bd dolt push讓其他 Agent 立刻看到你的更新同步機(jī)制詳見 docs/core-concepts/sync-concepts.md。小結(jié)Beads 的多 Agent 協(xié)調(diào)能力建立在三個(gè)核心機(jī)制之上assign/claim 雙通道歸屬控制、評(píng)論標(biāo)簽的輕量通信、merge slot 的獨(dú)占串行化。其中原子 claim 由 ReadyClaimer 角色的 compare-and-set 保證merge slot 由事務(wù)內(nèi)的 check-and-set 保證兩者都直接落在 Dolt 存儲(chǔ)層internal/storage/merge_slot.go因此無論多少個(gè) Agent 并發(fā)操作狀態(tài)都不會(huì)錯(cuò)亂。配合bd swarm編排大型 epic、external:依賴打通跨倉庫協(xié)作這套模式足以支撐從兩三個(gè) Agent 的小團(tuán)隊(duì)到多倉庫、多 Agent 的規(guī)?；⑿虚_發(fā)?！久赓M(fèi)下載鏈接】beadsBeads - A memory upgrade for your coding agent項(xiàng)目地址: https://gitcode.com/GitHub_Trending/beads1/beads創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考