Day 14：寫作代理人的架構設計，從規格到草稿 結尾留下一句明確的懸念，寫作代理人被賦予了查證能力，但查證具體要怎麼查、要查什麼、什麼時機該查，都還沒有答案。今天要逐一回答這個問題。

架構有了，查證還是一個問號

寫作代理人已經知道怎麼讀懂一份 Section Spec，也知道要依序逐段展開內容，還知道自己身上背負著一項規劃代理人沒有的職責，查證。這三件事都已經在 Day 14 定案。但知道自己「要查證」，跟知道「怎麼查證」，是完全不同層次的兩件事。查證要去哪裡查、什麼時機該查、查到之後又要怎麼跟撰寫這個動作交錯進行，這些具體問題，Day 14 一個都沒有回答。

今天的任務就是把這個空白填滿，逐一回答查證要怎麼查、查什麼時機該查、查到之後怎麼跟撰寫交錯進行，並且在回答完這些問題之後，替這整套工作模式正式命名。

在動手之前，先把今天的任務範圍畫清楚。今天只定義查證這件事本身的工作模式與邏輯樣貌，不涉及程式碼正確性保證的具體機制，那是 《Day 16：程式碼生成的正確性保證機制》 的範疇。也不涉及寫作代理人的查證職責與審查代理人的查核職責如何分工，那是 Day 19 才會處理的問題。今天要交出的，是一套清楚、可解釋、有名字的查證工作模式。

為什麼不能只靠內建知識，事實幻覺的陰影還在

先回到最根本的問題，寫作代理人為什麼不能單靠自己訓練時累積的知識，直接把技術內容寫出來。

答案要扣回 Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？ 定案的事實幻覺病灶。模型完全依賴訓練記憶，整個生成流程裡沒有任何一個步驟要求模型去驗證這個知識點是否已經過時，導致技術文章用肯定語氣寫出完全錯誤或已經過時的技術細節。這個病灶不會因為換了一個角色、換成寫作代理人來操刀，就自動消失。

訓練資料存在明確的知識截止時間，這是根本限制，無法繞過。技術領域的版本更新、API 異動、官方建議寫法的變化，速度遠比模型重新訓練的週期快得多。今天還被視為標準做法的寫法，半年後可能已經被官方文件標註為不建議使用。寫作代理人如果只靠內建知識落筆，等於是延續 Day 01 定案的一鍵生成同樣的賭注邏輯，賭這一次剛好沒有踩到過時的細節。賭贏了沒有人會發現問題，賭輸了就是一篇用肯定語氣講錯話的文章。

這裡要扣回 Day 14 已經確立的架構前提：查證能力是寫作代理人與規劃代理人最根本的差異。

但這句話本身只描述了一個架構層級的事實，如果這個能力不被實際觸發運作，它就只是名義上被賦予的資格，並沒有真正解決事實幻覺這個病灶。能力必須落實成一個會主動運作的工作模式，才算真正被兌現。今天接下來要做的，就是把這個名義上的能力，變成一套具體可運作的機制。

查詢什麼時候該被觸發，不是逢字必查

一個很自然的疑慮會浮現，如果要查證，是不是代表每一句話、每一個細節都要查一次。這樣做的效率成本太高，而且大部分技術寫作裡，真正需要查證的內容其實只佔一小部分。查詢動作必須是有選擇性的，而不是逢字必查。

哪些情境應該觸發查詢動作。

第一種是涉及版本號的技術細節，例如某個框架或函式庫只有在特定版本之後才支援的語法，這類內容一旦寫錯版本對應關係，讀者照著做就會直接踩坑。

第二種是涉及套件或框架的 API 語法，例如函式簽章、參數名稱、呼叫方式，這類細節經常隨版本迭代而變動，稍有不慎就會寫出已經被取代的舊寫法。

第三種是時效性強的技術細節，例如某個寫法是否已經被官方文件列為不建議使用的反模式，這類判斷會隨時間推移而改變，去年還算合理的做法，今年可能已經被官方明確勸退。

這三類內容有一個共同特徵，它們都有明確的正確或錯誤答案，而且這個答案會隨時間變化，正是查詢動作最需要介入的地方。

哪些情境不需要觸發查詢。通用的程式設計原則，例如單一職責原則、關注點分離，這類概念的核心主張不會因為某個框架升級到新版本就整個翻轉。不涉及版本差異的邏輯概念，例如遞迴的運作原理、時間複雜度的基本定義，這類知識屬於相對穩定的計算機科學基礎，不會因為時間推移而過時。這類內容不需要每次都觸發查詢動作。

把這個判準收束成一句話，觸發查詢的核心在於，這段內容的正確性是否可能隨時間或版本而改變。只要存在這個可能性，就是查詢動作該介入的節點。這個判準讓查詢行為變得可預期、可解釋，讀者可以理解為什麼某一段觸發了查詢、另一段沒有，而不是把查詢當成一個隨機或憑感覺決定的動作。

推理與查詢如何交錯，一個反覆進行的循環

判準確立之後，接下來要回答的是本篇最核心的問題，查詢動作被觸發之後，具體要怎麼跟撰寫這個動作交錯進行。

想像寫作代理人正在展開某一段落，這一段規格要求它介紹某個函式庫的呼叫方式。寫到一半，它意識到接下來要寫的內容涉及一個具體的 API 呼叫，而這個呼叫方式恰好落在剛剛定義的觸發判準裡，涉及參數名稱與版本對應關係。此時它不會憑著模糊的印象繼續往下寫，而是先形成一個推理判斷，判斷這裡需要查證，也判斷需要查證的具體對象是什麼，是這個函式的完整簽章，還是這個參數在近期版本裡是否已經改名。接著它執行一次外部查詢動作，取得查詢結果。取得結果之後，它把這個結果帶回原本的推理脈絡，繼續往下走，決定這段內容該怎麼寫。如果查詢結果與原本的假設一致，撰寫就順著原本的方向繼續。如果查詢結果推翻了原本的假設，例如原本以為的參數名稱其實已經在新版本改名，寫作代理人就需要調整這段原本打算怎麼寫。

這是一個反覆的循環，不是一次性的動作。一段內容展開的過程裡，可能會不只一次出現這樣的推理與查詢交錯，每一次交錯都聚焦在當下這個具體的疑點上，查完之後繼續往下推進，直到這一段的撰寫任務完成。

這裡必須扣回 Day 14：寫作代理人的架構設計，從規格到草稿 定案的逐段展開架構。這個推理與查詢交錯的循環，不是獨立於逐段展開之外的另一套流程，而是鑲嵌在逐段展開架構裡運作的機制。寫作代理人依序處理每一則段落規格時，在該段落內部視需要觸發這個推理與查詢交錯的循環，查完之後仍然回到同一段落的撰寫任務裡繼續往下走，而不是跳出逐段展開的節奏，另外跑一輪獨立於外的查證流程。

這個工作模式跟一鍵生成的根本差異，在這裡看得特別清楚。一鍵生成是單一次推理，從指令直接到成品交付，過程中沒有任何檢查點。今天描述的這個循環，則是在撰寫過程中反覆穿插檢查點，每一次查詢都是一次校準事實的機會，讓最終產出的內容不再只是賭一把訓練記憶還沒過時，而是在真正落筆之前，先確認過這個細節此刻是否依然正確。

這個模式有了名字，ReAct 模式

到這裡，查詢什麼時候該被觸發、觸發之後如何跟撰寫交錯進行，這兩個問題都已經有了具體答案。今天要正式做一件事，把這整套「推理，查詢，再推理」反覆交錯的工作模式，鄭重賦予一個名字。

從今天起，這個工作模式正式定名為 ReAct 模式。它的定義是，讓寫作代理人交錯執行推理與外部查詢動作的工作模式。這個定義從今天開始定案，成為全系列統一用詞，後續任何涉及即時查證的段落，一律沿用這個名稱，不再使用「查證機制」或「查資料流程」這類籠統的說法去指稱同一件事。

這類反覆交錯推理與行動的工作模式，在更廣泛的技術脈絡裡並非全新發明，早已是描述 Agent 如何一邊思考一邊行動的常見樣貌。但今天不打算展開任何學術文獻回顧或技術史考證，重點不在於這個模式從何而來，而在於它此刻在寫作代理人身上具體扮演的角色，已經被清楚定義出來。

有了明確的名字，後續系列裡任何提到即時查證這件事的段落，都可以直接使用 ReAct 模式這個詞彙指稱同一件事，不需要每次都重新用一長串描述句去解釋。這正是全域錨點檔案這類機制存在的價值，在正文裡具體被兌現的一刻。一個概念一旦被正式命名並定案，它就成為全系列共享的詞彙資產，往後每一次引用都是在累積同一個概念的重量，而不是每次都重新發明一種說法。

從今天起，寫作代理人的查證能力，不再只是一句架構層級的宣告。它有名字，叫做 ReAct 模式，也有清楚的邏輯樣貌，涉及何時觸發、如何交錯、如何回到撰寫任務。查證這件事，終於從一個抽象的職責描述，落實成一套具體可運作的工作模式。

查證有了做法，但程式碼還需要更嚴格的把關

今天正式回答了 Day 14 留下的懸念。查證能力不能只停留在架構層級的宣告，寫作代理人若只靠訓練時的內建知識撰寫技術內容，等於延續一鍵生成同樣的賭注邏輯，事實幻覺這個病灶並不會因為架構上具備查證能力就自動消失，能力必須被實際觸發運作，才算真正兌現。

查詢動作不是逢字必查，而是有明確判準。涉及版本號、API 語法、時效性強的技術細節，這類正確性可能隨時間或版本改變的內容，才是查詢該介入的節點，通用且穩定的邏輯概念則不需要每次觸發。

查詢動作被觸發之後，寫作代理人會先形成推理判斷這裡需要查證什麼，接著執行查詢取得結果，再把結果帶回原本的推理脈絡繼續往下走。這個推理與查詢反覆交錯的循環，鑲嵌在 Day 14 定案的逐段展開架構之中，在每一段落展開的過程中視需要被觸發。

這個工作模式今天正式有了名字，ReAct 模式，讓寫作代理人交錯執行推理與外部查詢動作的工作模式，從今天起成為全系列統一用詞，後續任何涉及即時查證的段落都將沿用這個名稱。

查證有了明確的做法，但程式碼範例是特別容易出錯、特別需要驗證可執行性的內容，光靠 ReAct 模式的查詢動作是否就足夠保證程式碼真的能跑、版本真的正確，這個問題今天還沒有答案，將在 《Day 16：程式碼生成的正確性保證機制》 正式揭曉。