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

「當測試失敗時，腳本會停止。角色會調查。」這是Docker團隊對AI代理（智能代理）的核心判斷。

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

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

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

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

同一個skill文件，開發者筆記本和CI環境行為完全一致。

本地優先：先在自己電腦跑通

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

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

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

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

這為什么重要

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

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

CI從"黑盒執行環境"變成"代理的另一個辦公地點"。

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