Day 24：封面與插圖生成，用生成式圖像工具自動配圖 結尾留下一句話，架構圖、資料視覺化、封面插圖，視覺代理人這三種產出類型今天全數有了各自的工作原則。但三者目前都還是各自獨立驗證，寫作代理人產出文字、視覺代理人產出圖像，兩者實際協同運作起來會是什麼樣貌，這個問題今天還沒有答案，將在下一篇正式揭曉。今天要正面回答這件事。

兩個角色都準備好了，是時候看它們一起工作

Day 21 到 Day 24 依序把視覺代理人的定位、職責邊界，以及架構圖、資料視覺化、封面插圖三種產出類型的轉譯原則定案，寫作代理人與視覺代理人實際協同運作起來會是什麼樣貌，這件事今天還沒有答案。今天要正面回答這件事，答案的方向分兩步走，先完整跑一次協同產出的流程，涵蓋三種產出類型各自被實際轉譯一次，再驗證這套多 Agent 架構加入視覺代理人這個新角色之後是否還站得住腳。

在往下走之前，先把今天的任務範圍畫清楚。今天只示範這一次協同流程本身，不涉及具體繪圖語法、圖表函式庫或生成式圖像技術，也不涉及審查代理人如何複核這份圖文草稿，這是 Day 26 的範疇。

協同不是接力賽，是邊寫邊配合

Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 已經定案，寫作代理人與視覺代理人之間，關係比較特殊，是協同而非單純的先後接力，兩者不必嚴格排隊等待對方完全做完才輪到自己動工，最終目標是把文字與圖表整合成一份圖文並茂的完整草稿。

今天要具體示範這句話實踐之後的樣貌。寫作代理人在逐段展開的過程中，寫到某一段需要視覺輔助時，依 Day 22 定案的圖表佔位符機制標記一則佔位描述，這個標記本身就是一個交接訊號。視覺代理人可以在寫作代理人繼續往下一段展開的同時，讀取這則佔位描述並開始轉譯，不需要等待整篇文章全數完稿才進場。

這不是寫作代理人先寫完整篇、視覺代理人才整批進場的分批接力模式，而是隨著文字逐段成形，圖表也隨之逐一到位。

場景延續，回到那個 Git 版本控制入門課堂

這邊的實戰示範延續 Day 13：實戰，讓規劃代理人產出一套完整的系列大綱、Day 20：實戰，寫作代理人依規格產出完整初稿 已經使用過的示意主題，Git 版本控制入門系列，給完全沒有寫過程式、沒用過版本控制的讀者看的實用系列。今天延續同一個示意脈絡，不是系列作者真正拿去用的產出結果。

系列讀到這裡，細心的讀者可能已經注意到，Day 15：結合即時查證，讓寫作代理人自己查資料、Day 16：程式碼生成的正確性保證機制、Day 17：狀態管理，讓寫作代理人記得前幾天寫過什麼、Day 18：處理複雜內容，長篇論證與公式推導的撰寫策略 正文裡都出現過圖表，當時讀者只是看到這些圖表，實際怎麼轉換的機制則沒有說明。

今天要用這個例子來展示視覺代理人是怎麼運作的。

第一種轉譯，把系列自己的機制畫成一張圖

Day 15 正文原本的佔位符原文如下：

<!-- 圖表佔位：呈現寫作代理人在單一段落展開過程中，推理判斷、外部查詢、帶回推理脈絡三者反覆交錯的循環樣貌，並標示這個循環鑲嵌在逐段展開架構單一段落節點內部運作 -->

視覺代理人讀取這則佔位描述，依 Day 22 定案的三層原則展開轉譯。判斷依據，這則佔位描述裡明確點出推理判斷、外部查詢、帶回推理脈絡三個節點，以及三者反覆交錯的循環關係，具備可辨識的節點與關係，適合轉譯成流程性質的架構圖。

轉譯輸入，視覺代理人讀取的就是這則佔位描述裡已經點出的三個節點與它們的循環關係，不需要回頭重新閱讀 Day 15 整篇正文。轉譯輸出，圖表忠實呈現這三個節點與循環關係，並標示這個循環鑲嵌在逐段展開架構單一段落節點內部運作，不自行增減節點，不自行調整這個循環與外層節奏的相對位置。

實際生成的圖片如下

這是系列前面已經埋下、今天才正式兌現的伏筆。

讀者當時看到這張圖，可能只是簡單看過，今天終於知道轉換成圖片的整個流程。

第二種轉譯，效果要用數字說話

架構圖有現成的伏筆可以回收，資料視覺化沒有，須延續 Git 版本控制入門示意系列虛構一則新的示意段落規格。這則段落規格的重點是不同 commit 粒度下定位一個 bug 平均需要查閱的 commit 數量比較，每次改動涵蓋五個檔案、十個檔案、十五個檔案三種粒度各自對應的平均查閱數量。

寫作代理人展開這一段時，依 Day 23 定案的機制標記佔位描述，這則描述除了說明要呈現三種 commit 粒度的查閱數量比較，還須承載數據來源，指向系列前面某一天正文裡已經提過的實測數字，或知識庫切分單元裡的原始數據段落。

視覺代理人讀取這則佔位描述，依 Day 23 定案的三層原則展開轉譯。判斷依據，佔位描述裡點出三個項目之間的數量比較，具備可量化的數值關係。轉譯輸入，讀取佔位描述裡已經點出的呈現需求與數據來源這兩類線索。轉譯輸出，忠實呈現數據來源裡的實際查閱數量數字，不自行增減數據點，不自行調整數值大小，也不會因為佔位描述裡剛好沒寫清楚某個 commit 粒度的確切數字，就自己推算一組看起來合理的數字湊數。

與第一種轉譯的差異在於，這次多了一個數據來源查核的步驟，但用的仍是同一套判斷依據、轉譯輸入、轉譯輸出三層原則框架。

第三種轉譯，這篇文章給人的第一印象

Git 版本控制入門示意系列裡，假設某一篇的標題是「commit 粒度如何決定除錯效率」，Section Spec 核心目標欄位寫著這一篇要讓完全沒寫過版本控制的讀者，理解 commit 粒度是新手最容易忽略、卻最能左右除錯效率的關鍵變因。

視覺代理人依 Day 24 定案的原則，用這篇文章的標題與核心目標作為輸入，決定封面該呈現的意象方向，而不是自己重新閱讀通篇正文去尋找靈感。這則標題與核心目標已經清楚交代了主題是 commit 粒度、定位是為新手破除忽略關鍵變因的迷思，意象方向可以往結構感、轉折感這類視覺語彙靠攏。

決定意象方向之後，視覺代理人查閱全域錨點檔案，確認系列前面已經產出過的封面與插圖，色調、構圖傾向、畫風調性各自是什麼，讓這一張新的封面與系列前面的圖像維持一致，不會因為單獨這一篇的主題轉折感較強，就自作主張換成完全不同調性的畫風。

這次轉譯沒有佔位符可以依循，靠的是文章本身的定位資訊，但精神上仍然呼應輸入是已經存在的文字或數據這條原則，標題與核心目標同樣是既有素材，不是視覺代理人自行杜撰的內容。

三張圖都到位了，這套架構撐得住新角色嗎

今天是階段五的收尾篇章，依系列前面兩次收尾篇章的慣例，這裡該回頭檢視這五天累積的成果，究竟如何回應四大病灶。但今天要驗證的不是這件事。

須誠實點名一件事，Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 定案的四大病灶對照表裡，注意力稀釋、內容漂移、事實幻覺、零容錯結構，四個病灶的主要負責與次要協助分別落在規劃代理人、寫作代理人、審查代理人三者身上，視覺代理人從未被列入任一病灶的責任欄位。

它存在的理由是 Day 21：為什麼技術文章需要圖表，視覺代理人的定位 定案的「降低讀者理解複雜結構時的認知負擔」，這是獨立於四大病灶敘事之外的存在理由。

因此今天真正該驗證的是 35 天大綱明確指定的方向，多 Agent 架構的可擴充性。加入視覺代理人這個新角色時，既有的規劃代理人與寫作代理人協作模式、既有的交接介面設計，是否需要被推翻或重新設計。

新角色是被嵌進來的，不是外掛上去的

答案是不需要，這裡有三項證據。

第一項證據，視覺代理人沿用 Day 22 已定案的圖表佔位符機制作為主要輸入介面。這個機制本身是寫作代理人在撰寫過程中順手標記的產物，早在 Day 15 到 Day 18 就已經反覆出現在正文裡，不需要為了視覺代理人另外新增一套獨立的規劃流程。

第二項證據，即便封面插圖無法沿用圖表佔位符機制，Day 24 已定案改用文章標題與 Day 04：規劃代理人的產出介面，認識 Section Spec 定案的核心目標欄位作為輸入。這兩者同樣是既有交接介面裡本來就存在的欄位，不是為了封面插圖另外新增的新格式。

第三項證據，Day 24 定案的風格一致性機制沿用 Day 05：系列的單一事實來源，打造全域錨點檔案 定案的全域錨點檔案，是既有基礎設施的延伸使用，不是新增獨立檔案。

三項證據合起來，視覺代理人是被嵌入既有架構，而不是被外掛在既有架構之外，這正是單一職責 Agent 原則搭配結構化交接介面所能提供的可擴充性。

圖文都有了，但還沒人挑剔過

今天完整跑過一次協同流程，寫作代理人與視覺代理人隨寫隨標、隨標隨轉譯，三種產出類型今天都各自被實際轉譯了一次，系列正文裡早就留下的佔位符伏筆，今天正式被兌現成一張架構圖。

今天最核心的結論，是這套多 Agent 架構在加入視覺代理人這個新角色後依然站得住腳，圖表佔位符機制、Section Spec 既有欄位、全域錨點檔案，這些既有基礎設施今天全數被視覺代理人沿用或延伸使用，沒有任何一項因為新角色加入而被打掉重練。新角色是被嵌入既有架構，不是被外掛在既有架構之外。

圖文整合的草稿今天已經能穩定產出。但這份草稿目前為止只經過寫作代理人與視覺代理人各自在撰寫或轉譯當下的單點確認，還沒有人用最嚴苛讀者的眼光通盤複核過，這個問題今天還沒有答案，將在下一篇正式揭曉。