核心命題： 一個長時間自主運行的代理系統，最大的敵人往往不是能力不足，而是狀態污染——把「推測」寫進「事實」，然後沿著錯誤前提一路空轉。 本文角度： 架構設計分析。以一個公開的代理式系統為樣本，拆解它如何用「雙圖」把狀態切開。
問題：一張表為什麼不夠
假設有一個代理系統在長時間執行一項複雜任務。它需要記錄兩類東西：
第一類是「世界的真相」：目標有哪些資產、哪些服務在運行、它們之間的從屬關係。這類資訊跨任務共享——今天確認的事實，明天仍然成立。
第二類是「我怎麼走到這裡」：我試過哪些方向、每個方向基於什麼判斷、產出了什麼結果。這類資訊只屬於當前這次任務，而且充滿中間態——很多嘗試最終被證明是死路。
多數系統把兩者塞進同一張表。於是出現三個典型病症：
病症一：推測被當成事實。 代理在中間步驟寫下「看起來可以注入」，後續步驟把它當成已確認條件，繼續往下推理。錯誤被放大。
病症二：結論無法回溯。 事後想問「這個結論是基於什麼」，卻找不到血緣關係——只有一堆平鋪直敘的記錄。
病症三：跨任務重複勞動。 每次新任務都從零開始確認同樣的資產資訊，因為「事實」與「本次過程」混在一起，無法只挑出可複用的部分。
解法：兩張圖，兩種職責
這套系統的做法是：把兩類資訊拆成兩張獨立的圖。
資產圖：全局共享的真值庫
節點是客觀實體：根域名、子域名、IP、服務、應用、端點。
它的特點是：
- 跨任務唯一一份——不同任務看到的是同一份資產真值；
- 父子關係由程式計算，不靠模型填寫——域名到子域、子域到服務、服務到端點的從屬關係與去重鍵，全部由程式碼決定；
- 代理只提交原始資訊，不負責決定「這個資產該掛在哪裡」。
這一條設計非常關鍵：把結構化的工作從模型手裡拿走。模型擅長的是判斷與推理，不是維護一致性的 ID 體系。讓程式做程式擅長的事。
探索圖：每任務獨立的推進鏈
節點是主觀過程：目標、意圖、事實、漏洞、提示。
它用血緣關係連起來：
| 邊 | 含義 |
|---|---|
spawns | 由某個目標派生出一個意圖（方向） |
yields | 某個意圖產出了一項事實 |
derived_from | 某個方向派生自哪些既有事實 |
proves | 某個意圖最終證明了某個漏洞 |
有了這張圖，任何一個結論都可以回溯：它是基於哪條方向、哪些事實得出的。
關鍵設計：錨點——兩張圖如何相連
如果兩張圖完全獨立，就無法回答一個實務上最常問的問題：「這個資產被測過沒有？測到什麼程度？」
於是有了錨點：一張對照表，把探索圖上的節點（意圖／事實／漏洞）釘到資產圖上的具體資產。
有了錨點，兩個方向都能查：
- 從方向查資產：這條意圖打的是哪些資產？
- 從資產查歷史：這個端點被哪些意圖測過、得出了哪些事實？
這也正是「資產測試覆蓋度」與「覆蓋圖」的基礎——在大量資產中，一眼看出哪些已測、哪些還沒碰。
三個好處
好處一：推測與事實物理隔離。 未經證實的判斷留在探索圖（可以被推翻、可以標記為推斷），只有真正確認的資訊才沉澱進資產圖。狀態污染被架構性地擋住。
好處二：可回溯。 任何結論都有血緣路徑，能回答「為什麼這樣判斷」，而不只是「系統這樣做了」。
好處三：可複用。 資產圖跨任務共享，新任務不必從零確認同樣的事實。
這個模式不只適用於安全領域
把名稱換掉，這個架構可以套用到很多場景：
| 場景 | 真值庫（共享） | 推進鏈（每任務） |
|---|---|---|
| 投資盡職調查 | 公司／股東／財務事實 | 本次調查走過的路徑與線索 |
| 學術研究 | 論文／作者／引用關係 | 本次研究的假設與驗證過程 |
| 客服自動化 | 產品／客戶／訂單事實 | 本次對話的推理與嘗試 |
| 軟體除錯 | 程式碼結構／依賴關係 | 本次排查的假設鏈 |
共同點是：「世界長什麼樣」與「我怎麼查的」是兩種本質不同的資訊，混在一起就會互相污染。
一個重要的反面提醒
這套設計並非沒有代價：
- 需要維護兩套資料結構，複雜度高於單表設計；
- 錨點的維護成本：每次把節點釘到資產，都多一次寫入；
- 對小規模任務而言是過度設計——如果一次任務只涉及幾個目標、不會重複，單表反而更簡單。
值得採用它的判斷標準是：任務是否夠長、是否會重複、是否會累積共享事實。三個都是，就值得拆。
下一步
- 想了解這兩張圖如何在多代理之間協作，可閱讀本系列的多代理協作機制
- 想從個案脈絡進入，可先讀個案導入一篇
- 想了解如何在隔離環境研究此類系統，可閱讀隔離研究實務