如果我沒有足夠的工程資源，同時實作格式驗證和內容真實性驗證，該優先做哪一個？
如果真的只能二選一先做,優先做格式驗證,但要清楚意識到這只是解決了一部分問題,不能因為做完格式驗證就以為可靠性工程已經完成。
優先做格式驗證的理由:格式驗證的投入產出比通常更高——實作成本相對低(多數主流 LLM API 已經內建 Structured Output 支援,不需要自己從零打造這個機制),但能立即消除「下游程式碼因為解析錯誤而崩潰」這類最基礎、最容易發生的故障,這類故障如果沒處理,系統可能連基本的穩定運作都做不到,更不用談進一步討論內容真實性的問題。
格式驗證做完之後,下一步的優先順序判斷:資源有限時,不需要同時對所有輸出欄位做完整的內容真實性驗證,可以依照「這個欄位錯誤的話,實際傷害有多大」來排優先順序。涉及金錢操作、不可逆動作的欄位(例如交易金額、目標地址),優先投入內容驗證資源;純粹用於展示、分析參考、不會直接觸發任何實際動作的欄位(例如一段解釋性的文字摘要),內容驗證的優先順序可以放低,因為即使這個欄位的內容有些微不準確,造成的實際傷害通常有限。
低成本但高價值的內容驗證起手式:不需要一開始就打造複雜的驗證系統,一個成本很低但價值不錯的做法是,要求模型在輸出關鍵結論的同時,附上簡短的推理依據(前面文章提到的「引用了哪些數據、依據什麼邏輯」),即使沒有進一步自動化交叉驗證,光是要求模型「說明依據」這個動作本身,就能過濾掉一部分品質特別差、模型自己都說不出具體依據的輸出——這是一個投入成本很低,但能篩掉最明顯問題的起手式,值得在資源有限時優先採用。
如果我要求模型附上推理依據，是不是就代表這個輸出的內容一定比較可信？模型會不會也「編造」出一份看起來合理但實際上是假的推理依據？
這是一個非常值得提出的問題,答案是:模型確實可能編造出看起來合理但實際上不對應真實依據的推理過程,要求模型附上依據,不能保證依據本身一定真實,但依然有實際價值,原因如下。
要求附上依據的價值,不在於「保證依據一定真實」,而在於「讓依據變得可被檢驗」。如果模型只輸出一個孤立的結論(例如「這個協議風險較低,建議投入資金」),沒有任何依據,人工審查者或另一個驗證 Agent 完全沒有切入點去質疑或驗證這個結論——結論本身是黑盒的。如果模型被要求附上依據(例如「因為這個協議過去 90 天 TVL 穩定成長、審計報告沒有發現高風險漏洞」),即使這個依據本身有可能是編造的,它至少提供了一個具體的、可以被查證的切入點——人工審查者或驗證 Agent 可以去確認「這個協議過去 90 天 TVL 是否真的穩定成長」這個具體陳述是否屬實,如果查證後發現這個具體陳述本身就是錯的,就能推翻整個結論;如果沒有這個具體陳述,根本無從查起。
進一步的防禦:讓依據裡的具體陳述,盡可能是可以自動化查證的。與其只是要求模型「說明依據」,更嚴謹的設計是,要求依據裡包含可以被自動化交叉比對的具體資訊(例如具體的數字、具體的引用來源、具體的時間戳記),而不是接受「這個協議看起來比較穩健」這種無法查證的模糊描述。前面文章提到的「對可以獨立驗證的欄位加入額外驗證步驟」,可以延伸應用在依據欄位本身——如果依據裡引用了一個具體的 TVL 數字,下游系統可以自動化去查詢這個數字是否和真實鏈上數據相符,這比只是要求模型「說明理由」更進一步,把「依據是否真實」這件事,也納入自動化驗證的範圍。
核心心態:要求附上依據,是把「內容真實性」這個難以驗證的問題,轉化成「依據裡的具體陳述是否真實」這個相對容易驗證的子問題,是一種降低驗證難度的工程手段,而不是一勞永逸解決真實性問題的萬靈丹——編造推理依據依然是可能發生的情況,但比起完全沒有依據的孤立結論,有具體、可查證依據的結論,整體的可信度驗證流程會順暢很多。
在鏈上 Agent 場景，如果 Agent 輸出的內容涉及對某個 DeFi 協議的風險評估，這種主觀性較強、沒有絕對客觀答案的判斷，該怎麼設計驗證機制？
主觀性較強的判斷,確實不能用「查證某個具體數字是否正確」這種二元對錯的驗證方式,但依然有幾個可行的驗證方向,核心思路是把「這個判斷是不是絕對正確」轉換成「這個判斷的推理過程是不是站得住腳」。
方向一:拆解成多個可獨立驗證的子判斷。一個籠統的「這個協議風險較低」結論很難直接驗證,但可以要求模型把這個結論拆解成幾個更具體的子判斷,例如「智能合約是否經過知名機構審計」「TVL 規模和成長趨勢」「治理機制是否去中心化」「過去是否發生過安全事件」——這幾個子判斷,雖然每一個本身也帶有一定的主觀評估成分,但都比「風險較低」這個籠統結論,更容易被獨立查證(例如「是否經過審計」這件事,可以直接去查證審計報告是否存在、是不是真的來自聲稱的審計機構)。整體風險評估的可信度,某種程度上可以透過驗證多個子判斷的紮實程度來間接評估,而不是直接驗證那個籠統的最終結論。
方向二:一致性檢查,而非絕對正確性檢查。既然沒有絕對客觀的答案,一個實務上有效的替代驗證方式是「一致性檢查」——讓同一個 Agent,針對相似情況的多次判斷,檢查判斷邏輯是否前後一致(例如,如果 Agent 對兩個 TVL、審計狀況、治理機制都高度相似的協議,給出了截然不同的風險評估結論,這種不一致本身就是一個值得警覺的信號,代表判斷邏輯可能不夠穩定,或者受到了某些不該影響判斷的因素干擾)。一致性本身不能證明「判斷是正確的」,但缺乏一致性,通常是判斷品質有問題的強烈信號。
方向三:多個獨立來源的交叉比對。對於主觀性判斷,單一 Agent 的結論可信度有限,可以設計成用多個獨立的驗證路徑(例如另一個獨立的 Agent、或人工審查者),針對同一個協議各自做一次風險評估,如果多個獨立來源的結論高度一致,整體可信度會提升;如果出現明顯分歧,這代表這個判斷本身可能存在爭議或不確定性,應該標記出來,而不是盲目採用單一 Agent 的結論當作定論。
核心原則:對於主觀性較強的判斷,驗證的目標不是追求「絕對正確」(這本身可能不存在),而是追求「判斷過程夠透明、夠一致、有多個獨立視角互相印證」,這是一種降低不確定性的工程做法,而不是消除不確定性的萬靈丹——最終,對於高風險的主觀判斷,依然應該保留人工做最終決策的空間,Agent 提供的是輔助判斷的參考資訊,而不是取代人類判斷的最終權威。
在多 Agent 系統裡，如果 Sub-agent A 產生的內容（附有推理依據）被交接給 Sub-agent B，B 對這份內容做了驗證後判斷可信，這個「已驗證」的狀態，之後傳到 Orchestrator 或其他 Sub-agent 時，還需要重新驗證嗎？
這個問題延伸了前面 Handoff 詞條討論過的「執行前重新驗證」原則,但這裡的情境更細緻——如果 B 已經做過驗證,後續環節是不是可以直接信任「已驗證」這個狀態，不需要重複驗證？
核心判斷原則:信任「驗證結果」本身,但要確認驗證的有效期和範圍,而不是重新從頭驗證一次。B 已經花費資源做過驗證,如果後續環節每次都要重新做一次完整驗證,會造成不必要的重複成本,這不是效率上合理的設計。更合理的做法是,B 完成驗證後,把「驗證結果」本身當成一個新的、可信的欄位,附加在交接封包裡繼續往下傳遞(例如新增 verification_status: verified、verified_by: sub_agent_B、verification_timestamp、verification_scope(具體驗證了哪些欄位,不是驗證了「全部內容」這種籠統陳述)這些欄位),下游的 Orchestrator 或其他 Sub-agent,可以直接信任這個「已驗證」的狀態,不需要重新執行一次驗證邏輯。
但這個信任不是無條件的,需要檢查兩件事:
驗證的有效期是否還在合理範圍內。前面滑點容忍度文章討論過類似的概念——市場數據、鏈上狀態這類即時性敏感的資訊,「已驗證」的狀態有一個隱含的時效性,如果 B 完成驗證到 Orchestrator 實際使用這份資料之間,間隔了很長時間(例如超過一個合理的門檻,具體門檻取決於資料本身的變動速度),即使狀態欄位寫著「已驗證」,這個驗證本身可能已經過時,不能無條件信任,應該視為需要重新驗證的情況。
驗證的範圍是否涵蓋了下游實際要用到的部分。B 的驗證可能只針對這份內容裡的某幾個欄位做了查證(例如只驗證了 TVL 數字,沒有驗證審計報告的真實性),如果下游要使用的,剛好是 B 沒有驗證到的欄位,「已驗證」這個籠統標記反而會造成誤導——這代表驗證狀態的記錄,不能只是一個籠統的布林值,而應該像前面提到的,明確記錄「驗證範圍」,讓下游能準確判斷「我要用的這部分,是不是真的在已驗證的範圍內」。
這個設計呼應的核心原則:驗證結果本身,可以且應該被信任並傳遞,不需要每個環節都重新做一次完整驗證(這才是善用前面環節已完成工作的效率設計);但信任驗證結果的前提,是驗證的時效性和範圍要被明確記錄、可被檢查,而不是把「已驗證」當成一個模糊的、萬用的免驗證通行證。
大多數 Agent 開發者，在系統上線初期最先關注的可靠性問題，是「輸出格式對不對」——會不會漏欄位、JSON 有沒有語法錯誤、格式驗證通不通過。這是合理的第一步，也是相對容易解決的問題（透過 Structured Output 這類機制，格式錯誤率可以壓到接近零）。但格式可靠性解決之後，一個更隱蔽、更難察覺的問題才真正浮現：一個格式完全正確的輸出，內容本身可能是錯的，而且這種錯誤，比格式錯誤更難被發現，因為它不會觸發任何明顯的系統警報。
這篇文章要拆解的，正是「格式可靠性」和「內容真實性」這兩個經常被混為一談、實際上完全獨立的問題，以及為什麼多數 Agent 系統的可靠性工程，會不小心把大部分心力放在前者，卻幾乎沒有處理後者。
格式驗證（例如 Structured Output 的 Schema 約束）能保證的事情，本質上只有一件：模型輸出的資料結構，符合預先定義的形狀。一個 `confidence_score` 欄位是 0 到 1 之間的浮點數，一個 `source_url` 欄位是合法的 URL 字串格式，一個 `status` 欄位是預先定義的幾個選項之一——這些都是格式驗證能夠檢查、能夠攔截違規輸出的範圍。
但格式驗證完全無法檢查的是：這個信心分數，是不是真的反映了模型內部的不確定性，還是模型隨便生成了一個看起來合理的數字；這個 URL，是不是真實存在、內容是否真的和引用的內容相符，還是模型憑空生成了一個格式正確但根本不存在的連結；這個狀態選項，是不是準確描述了實際發生的情況，還是模型選了一個「看起來比較安全」的選項來規避真正的判斷。這些問題，全部落在格式驗證的能力範圍之外，需要完全不同的機制去處理。
格式錯誤會觸發明確的系統反應——JSON 解析失敗、Schema 驗證不通過，這些都是可以被自動化偵測、自動化告警的事件，開發者很容易在儀表板上看到「格式錯誤率」這個指標，並針對它做優化。
內容錯誤則完全不會觸發任何自動化警報。一個 Agent 生成了一份格式完美、但內容是幻覺出來的分析報告，系統的角度來看，這是一次「成功」的執行——沒有任何錯誤日誌、沒有任何異常告警，唯一能發現問題的方式，是有人實際去查證這份報告的內容是否真實，而這種人工查證的成本很高，不可能對每一次輸出都做，這代表多數內容層面的錯誤，會在沒有被發現的情況下持續存在，直到某次造成了實際的損失（例如根據錯誤資訊做出了錯誤的交易決策），才會被回頭追查發現。
這裡有一個違反直覺的現象值得特別指出：Structured Output 這類格式化機制，雖然大幅提升了系統的可靠性，但也可能無意間讓內容錯誤變得更難被人工發現，因為格式化的輸出，本身帶有一種「這是經過系統化處理、應該可信」的視覺暗示。
一段自由文本的模型輸出，如果內容有明顯的邏輯跳躍或矛盾，人類讀者通常比較容易察覺（因為閱讀自由文本時，讀者的注意力是分散在整段內容上的）；但一個格式工整的 JSON 物件，人類（尤其是下游只做程式化處理、不做人工審閱的系統）反而更容易直接信任每個欄位的值，因為「格式正確」在心理上很容易被誤讀成「內容也經過了驗證」——這是格式可靠性帶來的一個隱藏成本，值得在設計系統時特別意識到。
既然格式驗證解決不了內容真實性，實際的解法必須疊加在格式驗證之外，這裡有幾個方向。
對於可以獨立驗證的欄位（例如 URL、數值型的市場數據、引用的具體協議名稱），在下游加入額外的驗證步驟，真的去查證這個欄位的內容是否屬實，而不是假設格式正確就代表內容正確——這呼應了前面 Structured Output 詞條提到的分層驗證思路。對於不容易直接驗證、涉及推理或判斷的欄位（例如分析結論、風險評估），要求模型在輸出裡額外附上推理依據（例如具體引用了哪些數據、依據什麼邏輯得出這個結論），讓後續的人工審查或另一個獨立的驗證 Agent，能對這個結論的合理性做交叉檢查，而不是只看到一個孤立的、沒有支撐依據的結論。對於高風險決策（例如涉及實際金錢操作），無論格式看起來多麼完整、可信，都應該保留前面反覆提到的人工確認這道防線，不能因為輸出格式正確就跳過這一步。
如果你正在開發 Agent 系統，實作 Structured Output 只是可靠性工程的第一步，不是終點——上線一個格式驗證機制之後，容易產生一種「輸出已經足夠可靠」的錯覺，但這只解決了格式層面的問題。真正該投入資源的下一步，是針對「內容本身是否真實」設計獨立的驗證機制，尤其是對高風險、高影響力的輸出欄位。如果你是 Agent 產品的使用者或評估者，看到一個 Agent 輸出格式整齊、專業，不要因為這個視覺印象就直接信任內容本身——格式的整潔和內容的真實，是兩件完全獨立的事，值得分開評估。