Day 20：實戰，寫作代理人依規格產出完整初稿 結尾留下一句話，文字內容到今天已經全數到位，但技術文章顯然不只有文字，還缺一塊，這個缺口今天還沒有答案，將在下一篇正式揭曉。

今天要正式回答，缺的那一塊是什麼。

文字都到位了，缺的那一塊是什麼

答案其實不難猜。讀者實際打開一篇技術文章時，除了文字之外，還會期待看到架構圖、資料圖表這類視覺元素幫助理解，這正是文字之外還缺的那一塊。

規劃代理人負責把主題拆解成規格，寫作代理人負責把規格填成文字，兩個角色各自到位之後，文章讀起來通順、查證過關、跨篇語氣一致，但翻開一篇真正成熟的技術文章，光有文字往往還是不夠，複雜的系統架構、密集的數據比較，這些內容單靠文字堆砌，讀者理解起來仍然吃力。補上這一塊的角色，正是今天要正式登場的視覺代理人。

今天的任務範圍要先畫清楚，只定義視覺代理人的定位與職責邊界，不涉及任何具體的圖表生成技術、工具或繪圖語法，這些留給接下來幾天處理。

讀者不是不想讀文字，是讀不動純文字堆出來的複雜結構

先把問題攤開來看。技術文章的讀者面對一段描述系統架構或資料流向的文字時，需要在腦中同步建立起元件之間的空間關係與先後順序。舉個例子，一段文字描述某個系統有三個服務，請求先進入閘道，閘道依規則轉發給對應的處理服務，處理服務再把結果寫回一個共用的資料層，資料層更新完成後觸發通知服務推播結果。這段敘述本身邏輯清楚，但讀者讀到「觸發通知服務」這句時，往往已經需要回頭確認一次，資料層是誰更新的、更新完之前處理服務做了什麼、閘道當初轉發的規則又是什麼。這正是文字線性敘述天生不擅長傳遞的資訊，空間關係與先後順序，被迫壓縮成一句接一句的線性排列，讀者得自己在腦中把這些線索重新組裝成一張完整的圖像。

這件事的代價不是「讀起來不夠流暢」這麼輕描淡寫。讀者必須一邊讀文字一邊在腦中重建圖像，讀到後面容易忘記前面提到的元件關係，需要反覆回頭對照前文才能拼湊出完整樣貌。越是複雜的架構，這種來回對照的次數越多，讀者的專注力就消耗得越快，很多人讀到一半放棄，不是因為文字寫得差，而是因為腦中那張圖始終拼不完整。

圖表輔助要解決的正是這個問題。它的作用不是讓文章看起來更美觀，而是把讀者原本需要在腦中吃力重建的空間關係或數量關係，直接以視覺形式呈現出來。讀者面對一張架構圖時，不再需要自己一邊讀一邊組裝，而是直接辨識這張圖已經畫好的元件與箭頭，這個動作背後的心力消耗，跟前面那種邊讀邊重建的心力消耗，完全不在同一個量級。認知負擔從重建轉為辨識，兩者所需的心力差距很大，這正是圖表存在的核心理由。

所以，技術文章需要圖表，理由不是美觀加分，而是降低讀者理解複雜結構時的認知負擔。這是本篇論證視覺代理人存在理由的核心依據，也是接下來要展開視覺代理人職責邊界時，一切設計都要回頭校準的原點。

視覺代理人不是萬能畫圖工具，它的邊界劃在哪裡

Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 已經定案視覺代理人的職責邊界，「單一負責的認知任務，是依據文章內容產出輔助理解的視覺素材，例如架構圖、資料圖表、封面或插圖。它的輸入是已經存在的文字或數據，輸出是對應的視覺呈現。但它明確不做兩件事。第一，它不判斷文章的論述邏輯是否成立，一段論證是否站得住腳，不在它的判斷範圍內。第二，它不修改或補充正文的文字內容，即使它在畫圖過程中發現某段文字描述得不夠清楚，也不會擅自回頭改寫文字，這種回饋屬於審查代理人的職責。」今天要做的，是把這段邊界具體展開成讀者能夠想像的實際樣貌。

先看輸入與輸出的關係。視覺代理人不會憑空發想要畫什麼，它的畫面內容完全來自寫作代理人已經產出的文字段落或數據。文字說完一件事，視覺代理人把這件事的結構樣貌畫出來，它要做的是把已經存在的內容轉譯成視覺形式，不是自己決定文章該講什麼、該強調哪個重點。這個轉譯關係決定了它在整條工作流中的位置，永遠站在寫作代理人之後，永遠以已經寫定的文字或數據作為唯一依據。

再具體看第一條邊界，不判斷論述邏輯是否成立。這意味著視覺代理人看到一段因果推導文字時，只負責把這段推導的結構畫成圖，前一步指向下一步、下一步又指向再下一步，它把這個順序關係如實呈現出來，但不負責判斷這段推導本身是否站得住腳，也就是說，就算這段推導其實邏輯有漏洞，視覺代理人依然會把它畫成一張看起來合理的圖，這個漏洞不會被它攔截。這件事留給審查代理人。

第二條邊界，不修改或補充正文文字，意味著視覺代理人即使在畫圖過程中發現文字描述得不夠清楚，例如某個元件名稱前後不一致，或某段因果關係文字寫得含糊，它也不會擅自回頭改寫文字。它只會把這個發現留待其他管道回饋，不越界代勞。這條邊界看起來嚴格，但正是它讓整套系統的職責分工維持乾淨，一旦視覺代理人開始順手改文字，寫作代理人與審查代理人的職責邊界就會開始模糊，Day 02：產出優先思維，先定義規格再動筆 定案的單一職責 Agent 原則就會被打破。

這裡順帶處理一個讀者可能會有的疑惑。架構圖、資料圖表、封面插圖，這三種產出類型性質差異不小，一種是流程結構，一種是數據呈現，一種偏向美術創作，會不會其實需要拆成三個不同的角色分別處理。答案是不需要。這三種類型明確定案為同一個視覺代理人內部依產出類型執行的不同子任務，不是三個獨立角色。系列鐵律規定，任何一天都不得引入第五類常設 Agent，若某個內容看似需要新角色，應優先檢視是否能歸屬到既有四類之一的子任務，架構圖、資料圖表、封面插圖三者的共同本質都是「把已經存在的文字或數據轉譯成視覺呈現」，差別只在轉譯的產出形式不同，這正好落在同一個認知任務的範圍內，不需要另立門戶。

定位確立了，接下來要一種一種打造具體能力

今天正式點名了 Day 20 結尾留下的缺口，文字內容已經全數到位，但技術文章顯然不只有文字，讀者實際打開一篇技術文章時，還會期待看到架構圖、資料圖表這類視覺元素幫助理解，這正是文字之外還缺的那一塊，補上這一塊的角色，正是今天正式登場的視覺代理人。

技術文章為何需要圖表輔助，今天給出的答案不是美觀加分，而是降低讀者理解複雜結構時的認知負擔。讀者面對描述空間關係或流程關係的文字時，需要在腦中吃力重建圖像，圖表把這份重建工作直接轉為辨識，兩者所需的心力差距很大，這正是視覺輔助存在的核心理由。

視覺代理人的職責邊界今天也具體展開了，呼應 Day 03 已經劃定的範圍，它的輸入是寫作代理人已經產出的文字或數據，輸出是對應的視覺呈現，它不判斷論述邏輯是否成立，也不修改或補充正文文字。架構圖、資料圖表、封面插圖，三種產出類型都歸屬同一個視覺代理人內部的不同子任務，不新增第五類常設角色。

定位與邊界確立之後，接下來要一種一種具體打造這些能力。階段五最後一天會有寫作代理人與視覺代理人協同的實戰驗收，但那還在後面。第一個要處理的，是架構圖，讓視覺代理人依文章內容自動繪製流程性質的圖表，這件事今天還沒有答案，將在下一篇正式揭曉。