[Dev Workflow] 一群 AI 交接工作卻不用重講:原來是同一套系統的兩條軸

白話版:讓不同的 AI 半路接手,卻不用你在旁邊重講一遍

想像一家 24 小時的便利商店在交班。接班的人要順利接上,手上得有兩本東西:一本是「現在正在發生什麼」的交班本——這批貨還沒上架、這個客訴還沒處理完;另一本是「這家店本來就怎麼運作」的長期資料——哪個供應商靠得住、哪條規矩老闆試過覺得不行。少了交班本,接班的人會把做到一半的事整個漏掉;少了長期資料,他每次上工都要重問一遍「這家店到底怎麼開的」。

我這個系列前面幾篇,其實一直在幫一群 AI 蓋這兩本東西。一本是「長期知識」——它知道什麼,長效、要用再查;另一本是「即時狀態」——它現在做到哪,易逝、隨時要寫。這篇是這個兩軸故事的收尾,我才後知後覺地發現:這兩本東西,原來是同一套系統的兩條軸,受同一套規矩管。

把這兩條軸搭好,就能做到一件我一直想要的事:凌晨三點,一個 AI 做到一半,另一個全新的 AI 半路接手,把剩下的跑完——沒人叫醒我、也沒人漏掉半成品。這篇要講的,就是這兩條軸各是什麼、為什麼缺一不可、怎麼匯流成「多 AI 協作」,還有那條讓一群長得不一樣、也不完全信得過的 AI 還能安全接力的規矩。

---

前言

某天凌晨三點,一個訓練跑完了。接手的不是我——我在睡覺——是一個全新開機的 Codex session。它讀了兩份檔案:一份寫著「這台機器、這個專案我早就知道的事」,一份寫著「上一棒的 Claude Code 做到哪、下一步該幹嘛」。然後它跑了下一個命令、把任務收掉。我隔天醒來,活是別人做完的。

這件事聽起來沒什麼,但它有一個很硬的前提:兩個 AI 不能只共用一份對話紀錄。對話會跟著 session 一起死;上一棒講過的話,下一棒根本看不到。它們能接上,是因為那兩份「上一棒知道什麼」和「上一棒做到哪」的東西,被寫進了一個活得過任何單一 session 的地方——檔案。

這個系列前面拆的,其實就是這兩份東西的各一半。Part 12、Part 13 蓋的是「知識」那半:檔案、搜尋、圖、蒸餾層,管的是 AI 知道什麼。Part 9、Part 10 蓋的是「狀態」那半:交接檔、工單、佇列,管的是 AI 現在做到哪。這篇是這一段的收尾,回頭看整段路才發現:這兩半不是兩套東西,是同一套系統的兩條軸。

兩條軸,是資訊的兩種半衰期

先把兩條軸擺清楚——差別就一個字:半衰期。

第一條是持久知識軸:我知道什麼。長效,而且要用再查。哪條路我親手走過發現不通、我在什麼限制底下工作、哪個看起來很聰明的做法其實測過丟掉了——這些東西一寫下來,幾個月後還是對的。它的形狀是檔案疊上搜尋、疊上一張圖、最上面再疊一層蒸餾結論,Part 12 跟 Part 13 蓋的就是這條。

第二條是即時狀態軸:我現在做到哪。易逝,而且隨時在變。這個訓練跑到第幾步、這張工單開了還沒收、剛剛那個決定是為了繞過哪個坑——這些東西的壽命以分鐘計,任務一結束就沒意義了。它的形狀是交接檔、工單、佇列這種「隨轉換就寫一筆」的檔案,Part 9 跟 Part 10 蓋的是這條。

一個講「我是誰」,一個講「我在幹嘛」。看起來像兩回事,但接下來你會看到,它們其實是同一招,用在保存期限不同的兩種資訊上。

養錯一條軸,另一種失敗照樣發生

你可能會想:那我把其中一條養到完美,是不是就夠了?不夠。兩條軸互不代替,少哪一條,就換一種方式失敗。

先看只養知識軸。假設你的知識庫完美到極點——AI 對你的偏好、你否決過什麼瞭若指掌。然後 session 一死,那個做到一半的訓練、那張開了還沒收的工單,全部蒸發。知識庫救不了它,因為那不是知識,是狀態(這正是 Part 9 的整篇論點)。它知道你是誰,卻不知道上一棒做到哪。

反過來,只養狀態軸。假設你的交接檔完美到極點——每一步做到哪都記得清清楚楚。然後第十個 agent 進場,又要你從頭講一遍你是誰、你否決過哪些做法、哪條教科書標準答案在你這裡是錯的。交接檔擋不住它,因為那不是狀態,是知識。它知道上一棒做到哪,卻每個決定都得重推一遍。

所以這兩條軸不是「一條的兩種版本」,是兩種不同壽命的資訊,記法跟維護方式也不一樣。顧錯了,另一種失敗一定會從另一頭冒出來。

說是「協作」,其實它們從不對話——只是輪流讀寫同一批檔案

在講兩條軸怎麼匯流之前,得先戳破一個直覺。

我們講「多 AI 協作」,腦裡容易浮出一群 agent 圍著開會、即時喊來喊去、互相協調的畫面。實際上完全不是。這套系統裡,agent 之間沒有任何即時協調——它們從不互相對話。所謂協作,說穿了就是一個目錄:一群 AI 輪流讀寫同一批檔案。上一棒寫完、下一棒讀進來接著做,如此而已。

這個分別很關鍵,因為它決定了整套東西為什麼站得住:沒有即時通道要維護,就沒有「兩個 agent 同時在講話、講的還不一致」這種要喬同步的麻煩。它們唯一的交會點,就是那批檔案。誰先誰後、隔多久,都無所謂——反正下一棒讀的是檔案當下的樣子。

合流點:一個陌生人半路進場,得同時讀兩條軸

兩條軸在哪裡匯流?就在「多 AI 交接」這個點上——而這件事我這套系統裡天天在發生:額度斷了、新 session 接上;Claude Code 做一半、換 Codex 接;某個自架模型接過夜工。每一次,進場的都是一個陌生人:它沒參與過前面,對現場一無所知。

而它要接得住,就得同時讀兩條軸。讀即時狀態(交接檔),才不會把上一棒做到一半的東西漏掉;讀知識(蒸餾記憶),才不用你重講一遍它早該知道的常識背景。少讀哪一條,就換一種方式失敗:只讀了狀態,它知道做到哪,但每個決定都要重推;只讀了知識,它知道你的偏好,卻不知道上一棒到底做了什麼。

凌晨三點那個 Codex 之所以接得住,不是因為它比較聰明,是因為兩份檔案都在:一份告訴它現場做到哪,一份告訴它這現場本來是怎麼一回事。它兩條都讀了,所以它接得住,而我在睡覺。

同一套哲學,套在兩條軸上

到這裡是全篇的骨:這兩條軸不是各搞各的,是同一套規矩,用了兩次。同樣五條規則,一條管知識、一條管狀態,只是套上去做出來的樣子不一樣。

• 檔案是真相源。 知識是一批 md 筆記,狀態是交接檔跟工單——兩邊都不是資料庫、也不是對話史。理由同一個:只有檔案活得過寫它的那個 process。對話跟 session 一起死,資料庫會長成另一個要你維護的系統,只有檔案兩頭都不占。
• 每個 index 都是可重建快取。 知識這邊,搜尋跟圖是從筆記重建出來的;狀態這邊,開機那份摘要,就是把交接檔重新讀一遍生出來的視圖。index 壞了、丟了都無所謂,拿底下的檔案重跑一次就回來了。
• 容忍 drift,你當唯一閘門。 兩台機器晚幾分鐘才同步,不追問哪份才是真的。owner 只是個路由提示,不是所有權;不管是把一則筆記升成 canonical,還是決定誰來接手,拍板的都是你,沒有一個 agent 在審另一個 agent。
• 要用之前,先驗一次。 舊筆記採信前對現況重驗一次、接手前把上一棒宣稱做完的最後一步重跑一次、報告採信前對實際結果重跑一次。過時是在「讀取的時候」抓出來的,不是在「寫入的時候」想辦法擋掉。
• 要跨 process 留著的,就寫成檔案。 上面四條收束成這一句:凡是要活得比當下這個 process 久的,就寫進檔案。兩條軸說到底就是同一招,用在保存期限不同的兩種資訊上。

看懂這一層,你才會相信我一開始說的:它不是兩套系統,是一套。

這樣搭起來,換來什麼

兩條軸受同一套規矩管,換來四個我在任何 AI fleet 都想留住的好處:

• 多接一種模型也很省事。 不管它是 Claude Code、Codex 還是自架模型,要做的只是把它指到同一批檔案。沒有 per-agent 的 onboarding,零額外設定。
• 任何一個工具掛掉,工作都接得下去。 視窗爆了、額度斷了、CLI 崩了都不要緊——工作躺在檔案裡,不在哪個 session 的腦子裡。換一棒讀進來接著跑就好。
• 幾乎不用再從頭解釋。 知識軸殺掉「你是誰再講一次」,狀態軸殺掉「我們做到哪」。交接變成一個「讀」的動作,不是一場「對話」——而讀,不用你在場。
• 沒有東西會不知不覺跑掉。 每個 claim 真的要用時都會被驗一次。一則過時的筆記、一份說錯的「done」,只要有人真的去依賴它,當場就會現形。系統會自己告狀,不會讓錯的東西悶著爛。

架構到這裡就講完了。只想直接套用的,文末那份五行 checklist 就是全部;想看串起整個 arc 的那個觀察——那條我在四個不同層各撞見一次、才認出來是中心律的規則——再往下讀。

每一層各自獨立收斂到同一條規則

底下是回頭看整個系列時,我才拼出來的一個 pattern:同一條規則,在四個毫不相干的層各自被重新發現一次。這不是「用這套系統」的必要知識,只想拿設計跟 checklist 的,直接跳到收穫。

先把那條規則講白:永遠別信一個系統對自己的描述,要在你依賴它的當下,對真實狀態重驗一次。 這條律我不是想出來的,是被四個不同的坑各教了一次,最後才認出它們是同一件事。

知識軸,重學了兩次

第一次在 Part 11。一份我以為早就「死掉」、準備退役的鏡像,凌晨兩點半居然還在被寫入。它對自己的描述是「我退休了」,現實卻不是——我是去查了檔案的 mtime,才當場抓到它在說謊。

第二次在 Part 13。一則 canonical 筆記可以「存在,卻被無視」。資料齊全、搜得到,agent 卻沒去查,自由發揮給了個流暢但錯的答案。這裡的落差是:知識庫對自己的描述是「這條規則我有」,但「有」不等於「被查」。

狀態軸,也重學了兩次

第三次在 Part 10。一份報告說「done」,結果根本沒做完。報告是一個 claim,不是一個結果——它對自己的描述是「我做完了」,你要是照單全收,就吃了一記悶虧。

第四次在 Part 9 的 false-takeover。交接協議自己寫的一條規則,把一個還要再跑 19 小時的訓練,標成了「abandoned、可以接手」。系統忠實地執行了一條錯規則——它對自己狀態的描述,悄悄跟現實對不上了,而它照著錯的描述往下走。

四個不同層,同一種失敗

把這四次擺在一起看,你會發現長得一模一樣:某個東西描述了自己 → 那個描述悄悄跟現實對不上 → 唯一的防線,是在你真的要依賴它的當下,對真實狀態重驗一次。退役鏡像、canonical 筆記、任務報告、交接規則——四個毫不相干的層,同一種失敗。撞見一次,你當它是個 bug;撞見四次,你就得承認它不是四個 bug,是這套系統的中心律。

為什麼這條律讓一群「不一樣」的 AI 還能安全協作

想通這條律,我才看懂整套東西為什麼撐得住。這整個 arc 一路在換模型、一路在升級——Claude Code、Codex、各種自架模型輪番上陣,而且它們幾乎每個月都變強。但讓它們能協作的,從來不是「模型更強」。

我不是在賭 Claude Code 會對、Codex 會對、自架模型會對——恰恰相反,我一個都不信它的片面之詞。每次交接,重跑上一棒宣稱做完的最後一步;每份報告,對實際結果重跑;每則筆記,採信前對現況重查。連 Part 11 那條治理原則——「產出者不替自己的高風險工作背書」——回頭看,也不過是「要用之前先驗一次」的同一條律,再套一次而已。

所以答案很反直覺:讓一群長得不一樣、能力參差、也不完全信得過的模型還能安全接力的,不是更聰明的 AI,是「沒有收據就不信任何一個」這條鐵律。模型可以隨便換、隨便升,系統的安全性不掛在任何一個模型的可靠度上。

收穫

最花時間的地方

不是蓋這兩條軸——那是幾個星期、一篇一篇慢慢蓋出來的。真正的體會反而是最後才來:回頭看才發現,知識那半跟狀態那半跑的是同一套五條規則,而其中「要用之前先驗一次」根本不是一個交接細節,是撐住整套系統最關鍵的一條。搭的時候我埋頭在各自的坑裡,認出它們是同一件事,是最後站遠一步才看到的。

可以搬走的診斷

交接失敗時,先問「哪一條軸空了」:如果是丟了做到一半的工作,空的是狀態軸;如果是每個決定都要重推一遍,空的是知識軸——兩邊要修的地方完全不同,別混著救。決定一個東西該放哪裡,先問它的半衰期:長效的,放要用再查的記憶;易逝的,寫進隨轉換就記一筆的檔案。還有,任何 agent、任何報告、任何規則講了什麼,把它當成一個「使用時要驗」的 claim,不是一個「可以歸檔」的事實。

通用原則

多 AI 的 fleet 不靠即時協調,靠的是輪流讀寫同一批檔案,加上一套哲學。而讓這件事真的安全的,是「沒有收據就不信」——正因為你不需要信任任何單一模型,你才敢把一群不完全信得過的異質模型,指到同一份工作上,仍拿到可靠的結果。

如果你也要讓一群 AI 交接工作卻不用重講,這是我試出來的順序

1. 按半衰期分家。 長效知識走一條軸——搜尋、圖、蒸餾過的記憶,要用再查;易逝狀態走另一條——交接檔隨轉換就寫。別把兩種壽命的東西互塞。
2. 檔案當真相源。 不是對話史(會跟 session 一起死)、也不是資料庫(會變成另一個要你維護的系統)。index 跟摘要都只是可重建的快取。
3. 讓 agent 輪流,不要對話。 協作就是一個兩個 CLI 共讀共寫的目錄;交接就是讀那兩份檔。沒有即時通道要維護。
4. 你當唯一閘門。 容忍 drift、把 owner 當路由提示;不管是升 canonical 還是決定誰來接手,都由人拍板。別做 agent 審 agent。
5. 要用之前先驗一次。 接手前重跑最後那步 Done、報告對實際重跑、筆記對現況重驗——就是這一條,讓一群不受信任的異質 fleet 變得安全。

說到底,這六篇文做的,是把一堆 markdown 加幾個 CLI,變成一個「不同的 AI 交接工作卻不用重講、也不丟工作」的系統。它跑得起來,不是因為我信任那些模型——是因為我把它蓋成了不需要信任。