Docker造了7個AI員工：不寫腳本，只寫"人設(shè)"

「當測試失敗時，腳本會停止。角色會調(diào)查?！惯@是Docker團隊對AI代理（智能代理）的核心判斷。

他們沒選傳統(tǒng)自動化路線，而是給7個AI代理寫了"簡歷"——不是代碼，而是markdown文件定義的"你是誰、該做什么、能用什么工具"。這些代理現(xiàn)在自主測試產(chǎn)品、分類問題、發(fā)版說明、修bug，全在CI里跑。

為什么不是腳本，是"角色"

Docker的Coding Agent Sandboxes項目（內(nèi)部叫sbx）給AI編碼代理提供安全隔離環(huán)境。最近兩周，團隊在此基礎(chǔ)上搭了"艦隊"（Fleet）——7個AI代理角色組成的虛擬團隊。

關(guān)鍵設(shè)計在Claude Code的skill機制。skill不是"執(zhí)行這幾步"的腳本，而是"你是構(gòu)建工程師，這是你的知識庫和決策方式"的角色描述。代理需要判斷力，不只是指令。

同一個skill文件，開發(fā)者筆記本和CI環(huán)境行為完全一致。

本地優(yōu)先：先在自己電腦跑通

艦隊的設(shè)計原則很硬：每個skill先在本地跑。

做/cli-tester技能（艦隊的探索性測試員）時，團隊沒先寫GitHub工作流。先在本地調(diào)用，看它編譯二進制、執(zhí)行CLI命令、發(fā)現(xiàn)問題、報告問題。調(diào)skill直到終端里表現(xiàn)正確，才接進工作流。

對比CI-only代理的噩夢：提交-推送-等待-讀日志，每次迭代幾分鐘。本地跑是秒級。你能看見代理怎么"想"，在哪困惑。改skill文件，重新調(diào)用，再試。

CI只是skill的另一個運行時。 nightly跑在MacOS、Linux、Windows上的/cli-tester，和終端里調(diào)的是同一個。工作流只干三件事：搭環(huán)境、拉代碼、調(diào)skill。沒有"CI版本"，沒有翻譯層。

這為什么重要

傳統(tǒng)自動化維護兩套系統(tǒng)：本地腳本+CI配置。Docker艦隊只維護一套角色定義。當測試邏輯要改，改一處，到處生效。

更深層的變化是調(diào)試體驗。腳本失敗時，你讀日志猜原因。代理角色失敗時，你能觀察它的"思考過程"——這是markdown人設(shè)給的可解釋性。

CI從"黑盒執(zhí)行環(huán)境"變成"代理的另一個辦公地點"。

現(xiàn)在這7個AI員工每天自動干完測試、分類、發(fā)版、修bug。團隊沒招更多人，只是把"重復判斷型工作"從人類簡歷里刪掉，寫進了AI的。