LuaN1aoAgent v2：把滲透測試的推理鏈寫進圖裡
LuaN1aoAgent is a fully autonomous AI-driven penetration testing agent powered by graph-based cognitive reasoning.
秒懂
- 它是什麼？
- 這是一套以 TypeScript 重寫、跑在 Pi SDK 上的自主安全代理，用 Planner、Executor、Observer 三角色取代舊版共享歷史的 P-E-R 迴圈，並要求漏洞與利用節點必須附帶證據引用。判斷重點在於：它的可追溯性設計是真約束，但 v2 是全新實作，v1 的基準數據不繼承。
- 適合誰用？
- 如果你要的是可審計的授權測試流程，且團隊能接受 Node.js 25+ 與 Pi SDK 這個相對年輕的執行環境，LuaN1aoAgent v2 的證據強制寫入機制值得評估。若你需要穩定的自動化 CI 掃描、或無法承擔 AGPL-3.0 對外提供服務時的源碼義務，這個專案不是合適的選擇。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「結論無法回溯」這個問題
多數 LLM 代理做安全測試時，最後交出來的是一段敘述：我掃了什麼、我認為哪裡有洞。問題在於這段敘述是模型自己寫的，中間的工具輸出、失敗的嘗試、被推翻的假設，全部壓縮進上下文裡，事後沒人能把某個結論對回某一次具體的工具呼叫。LuaN1aoAgent v2 針對的就是這一層。README 把它寫成一句設計原則：每個重要結論都必須可追溯到已持久化的事件、產物與圖證據。
目標讀者是有授權範圍的滲透測試人員與安全研究團隊，而不是想拿它去掃任意網站的愛好者。專案描述本身就限定在 authorized security research。它假設你已經有明確的測試邊界、能提供目標環境，並且需要對外說明「為什麼判定這裡有漏洞」。反過來說，如果你的需求只是定期跑一次已知漏洞掃描，這套架構的推理圖與證據鏈對你是純粹的額外負擔。
三角色分工：誰下決定、誰動手、誰記帳
v2 明確捨棄了舊版 P-E-R 迴圈共享同一份歷史的做法，改成三個有邊界的角色。
Planner 讀的是壓縮過的 task、reasoning、operation 三種圖視圖，產生或修補目標層級的任務，而不是直接指定低階動作。它掌握依賴關係、優先序、獨立任務的併發度、範圍與任務預算，並在圖變動或任務交接後，把可執行任務與剩餘容量重新對齊，不需要等整批平行任務跑完。它的決策透過 planner_submit 這個結構化終止工具送出。
Executor 收到一個有界的 TaskEnvelope，自行決定工具策略，記錄公開意圖、工具輸入、工具輸出、用量、錯誤與最終結果。大輸出會被存成不可變的 artifact，而不是塞進代理上下文。同一個 Task 的不同 epoch 會重用同一條持久化的 Pi session lineage 與工作區，不同 Task 之間則互相隔離。結果透過 task_result_submit 送出。
Observer 分成兩個獨立模式。Supervisor 在熱路徑上檢視 Executor 最近的動作，決定繼續、設檢查點、停止，或把控制權交回 Planner。Projector 則非同步地把正規化後的觀測轉成圖的增量。兩者每次呼叫都用全新的 Pi session，不共享隱藏的模型歷史。這是一個關鍵設計：把「判斷要不要停」和「把觀測寫進圖」拆開，前者不能延遲 Executor 迴圈，後者可以慢慢做。
證據強制寫入是這套圖最硬的一條規則
README 給出的推理鏈是 Evidence 經 supports 或 contradicts 指向 Hypothesis，Hypothesis 經 confirms 指向 Vulnerability，Vulnerability 經 exploited by 指向 Exploit，而 Evidence 以 observed on 連到 WebEndpoint 或 Service。
真正有約束力的不是這張圖，而是它附帶的規則：已確認的 Vulnerability 節點與成功的 Exploit 節點，在沒有證據引用的情況下不能被寫入。這是把「不確定」制度化。假設留在 Hypothesis 層，不會因為模型語氣肯定就自動升級成漏洞。對需要交付報告的團隊來說，這條規則直接決定了報告能不能拿出來給客戶或內部稽核看。
同時要看清它的代價。證據引用是額外的寫入與校驗成本，而 Projector 是非同步的，意味著圖的狀態可能落後於 Executor 剛做完的動作。如果你要求「工具一跑完，圖上立刻反映」，這個架構不是那樣運作的。
Plan-on-Graph 與任務圖操作
Planner 維護的是一張會演化的 Task Graph，而不是每次重新生成一份線性清單。README 的示意是 Goal 分出 Recon Task 與 Auth Task，Recon 產出 Service Profile 這個里程碑，Service Profile 與 Auth Task 共同指向 Validation Task，另外有一個 Blocker 以 blocks 關係擋住 Validation。
對應的圖操作是結構化的：create_tasks、patch_task、replace_dependencies、set_task_status。這個設計的實際差異在於，當偵察結果推翻原本假設時，你不需要重新規劃整條路徑，而是修補受影響的節點與依賴。對於目標環境大、前期資訊不足的測試，這比線性 checklist 更貼近實際工作方式。
但這也代表規劃品質取決於圖操作是否被正確使用。README 只列出操作名稱，沒有展開每個操作的參數與失敗處理。要真正評估，得去看倉庫裡對應的實作與 schema，而不是只看這份說明。
跑起來需要什麼：Node.js 25+ 與 Pi SDK
README 的徽章標示 Node.js 25+ 與 TypeScript 5.x，執行環境是 Pi SDK，架構標記為 P-E-O。這三項是部署前的硬性前提，其中 Node.js 25+ 值得特別注意：它高於多數企業環境目前長期支援的版本線，若你的 CI runner 或容器基礎映像固定在較舊的 LTS，得先處理升級。
README 提供的內容以架構與機制說明為主，quick start 章節在所提供的材料中並未展開成具體指令，因此這裡不列出未經確認的安裝步驟。可以確定的是需要設定 LLM 供應商，topics 中標示了 deepseek。實際的環境變數名稱、模型設定鍵、以及圖與 artifact 的持久化路徑，必須以倉庫內的設定檔與文件為準。
版本方面，v2.0.0 於 2026-07-20 發布，同日另有標記為 Legacy 的 v1.0.0。README 用 IMPORTANT 區塊明確聲明：v2 不是 Python v1 執行環境的原地重構，而是配置、持久化、代理生命週期與可觀測性契約都不同的新實作。升級等同於重新部署，不是換個版本號。
什麼情況下它是錯的工具
第一，基準數據目前是空的。README 自己寫明 v1 報告過的基準結果不會自動歸給 v2，v2 的基準只會在凍結版本上完成可重現的重跑之後才發布。也就是說，在撰寫當下你無法從這份材料得知 v2 的實際成功率或誤報率。任何拿 v1 成績推論 v2 的做法都不成立。
第二，非同步投影與熱路徑 Supervisor 的組合，讓系統行為不是完全同步可預測的。如果你需要的是確定性、可重複、逐步一致的掃描流程，這種設計會讓你難以在 CI 裡做嚴格的通過與失敗判定。
第三，授權是 AGPL-3.0。這不是一般寬鬆授權。若你把它的功能包成對外提供的服務，AGPL 的源碼提供義務會延伸到那個服務的使用者。這對內部授權測試通常不構成問題，對商業產品化則是必須先與法務確認的前提。這裡只陳述授權識別，不構成法律意見。
第四，Node.js 25+ 這個門檻本身就會排除一部分環境。
與共享歷史型代理的差異在哪
多數同類工具走的是單一代理加上一條不斷增長的對話歷史：所有工具輸出、所有推理、所有失敗都堆在同一個上下文裡，靠模型自己在其中維持連貫。這種做法在短任務上很有效率，但歷史一長就會出現兩個問題，早期證據被後來的敘述覆蓋，以及上下文成本隨任務時間線性膨脹。
LuaN1aoAgent v2 走的是另一條路：把狀態外化到圖與 artifact，讓每個角色的上下文保持有界。Executor 只拿一個 TaskEnvelope，Observer 每次用全新 session，Planner 讀的是壓縮視圖。差別不在於「有沒有用 LLM」，而在於結論的存放位置是模型歷史還是持久化圖。前者無法審計，後者可以。
代價是系統複雜度。三個角色、多種結構化終止工具、兩張圖、非同步投影，這些都是需要理解才能維運的元件。如果你只需要一個能跑腳本的輔助工具，這套架構的重量不會帶來對應的回報。
維護成本與採用判斷
v2.0.0 發布於 2026-07-20，最後推送時間為 2026-08-24，兩者相隔約一個月。這代表專案在 v2 發布後仍有活動，但材料中沒有路線圖細節可供評估後續節奏。README 的 Roadmap 章節在所提供的內容中被截斷，因此無法說明未來規劃。
升級成本的主要來源是契約變更。README 明說 v2 的配置、持久化、代理生命週期與可觀測性契約都與 v1 不同，這意味著 v1 的設定檔、部署腳本與任何依賴其持久化格式的周邊工具都無法直接沿用。若你已經在 v1 上建了流程，遷移是一次性重做，不是調整參數。
授權為 AGPL-3.0。用於內部授權測試的團隊通常不受影響，把它整合進對外服務的團隊則需要先確認源碼提供義務的範圍。這部分請以授權全文與自身法務判斷為準。
至於是否採用：需要可審計推理鏈、且能接受 Node.js 25+ 與 Pi SDK 的團隊，可以從 v2 開始評估。需要穩定自動化掃描、或無法承擔 AGPL 義務的團隊，應該先看別的方案。動手前務必確認 Pi SDK 的取得方式與版本約束、v2 可重現基準是否已發布、以及圖與 artifact 的持久化落在哪個路徑。
編輯結論
如果你要的是可審計的授權測試流程，且團隊能接受 Node.js 25+ 與 Pi SDK 這個相對年輕的執行環境，LuaN1aoAgent v2 的證據強制寫入機制值得評估。若你需要穩定的自動化 CI 掃描、或無法承擔 AGPL-3.0 對外提供服務時的源碼義務，這個專案不是合適的選擇。動手前先確認三件事：Pi SDK 的實際取得與版本約束、v2 在凍結版本上的可重現基準是否已發布（README 明說 v1 數據不繼承），以及 reasoning graph 與 operation graph 的持久化檔案落在哪個路徑、能否納入你既有的備份與稽核流程。
社群筆記