LuaN1ao 拆解：把每条渗透结论钉回证据链，而不是留在模型的记忆里

1.3k star 的自主渗透智能体 v2：Planner-Executor-Observer 三角色 + 任务/推理/操作三张图，把 Evidence → Hypothesis → Vulnerability → Exploit 变成可追溯的结构化链路。TypeScript + Pi SDK 完全重写，AGPL-3.0。

一、速览：值不值得你花时间

推荐指数：★★★★☆（4 / 5）

给到这个分数的理由：它是我见过的对「Agent 到底凭什么下结论」这件事最较真的开源渗透项目。绝大多数自主渗透工具的推理过程只存在于模型的上下文里 —— 跑完你就拿到一份报告，中间那一步「为什么认为这里有洞」是黑盒，不可复核、不可回放。LuaN1ao v2 反过来，它要求每一条被确认的 Vulnerability 节点和每一条成功的 Exploit 节点，都必须携带 evidence 引用，否则不许写入。它把「证据」从一句口号变成了 schema 层面的硬约束。

再往下看，它还做对了一件更难的事：规划不是线性清单，而是一张依赖图。新证据进来时不是推翻重排整个计划，而是 patch 受影响的那几个节点和边。这让长任务不会因为中途一个新发现就全局洗牌。

扣掉的一颗星在四个地方，而且都不轻：AGPL-3.0（传染性很强，企业法务会卡）；Node.js 25+（因为它用了内置 node:sqlite，这个门槛把大部分现成环境挡在门外）；v2 的 benchmark 还没发布 —— README 明确写了 v1 的成绩不自动归给 v2，而 v1 正是拿过腾讯比赛名次的那版，所以目前你看到的战绩属于旧实现；以及 human approval gates（高危动作人工审批）还挂在 Roadmap 里没做，也就是说现阶段它真的会自己往下打。

关键数据（截至 2026-09-29）

适合谁

二次开发

二、它是什么，不是什么

先把边界划清楚，不然很容易把它当成错的东西期待：

• 不是一个漏洞扫描器。它不套 CVE 规则库去匹配版本，也没有「扫描→出列表」这种固定流水线。
• 不是一个报告生成器。报告是推理图的投影结果，不是目标本身。
• 不是 v1 的原地重构。README 用 IMPORTANT 明确标了：v2 是新实现，配置、持久化、Agent 生命周期、可观测性契约全都换了。Python v1 还留在 v1 分支和 v1.0.0 release 上。
• 不是一个「给你一个 Agent 让它自由发挥」的框架。它恰恰是把自由圈进边界里 —— 谁改任务图、谁选工具、谁投影事实，写死在 Runtime invariants 里。

它的自我定位在 Introduction 里写得很直白（意译）：每一条重要结论都必须能追溯到持久化的 event、artifact 和 graph evidence。整篇 README 其实都在论证这一句。

提炼三个关键词：graph-based cognitive reasoning（图驱动的认知推理）、explicit agent boundaries（显式 Agent 边界）、evidence-backed memory（有证据支撑的记忆）。

三、P-E-O：三个角色，各管一段，谁也不越界

v2 把 v1 的 P-E-R（Planner / Executor / Reflector）换成了 P-E-O，最关键的差别是 Reflector 那个「共享历史的反思循环」被拆成了两个独立模式：

几个我很欣赏的设计细节：

1）每个 Agent 调用都有显式的终止工具契约。 Planner 必须以 planner_submit 结束，Executor 以 task_result_submit 结束。这把「Agent 跑到一半不知道该输出什么」这类不确定性变成了 schema 校验问题。

2）Observer 的两种模式各自用全新的 Pi session，不共享隐藏的模型历史。 这一条很关键 —— 监督者如果和执行者共享上下文，它就会「理解」执行者的思路，从而更容易放过错误。切断历史让它只能基于规范化后的观测做判断。

3）Planner 不等待整个并行波次结束再调度。 它读的是紧凑的 task / reasoning / operation 图视图，图一变就 reconcile ready tasks 和可用容量。这让并发调度是增量的而不是批量的。

4）大输出不进模型上下文，落成内容寻址的 artifact。 Executor 把超过阈值的工具输出写成不可变 artifact，只把引用和预览传给模型。这直接缓解了长任务里 context 爆炸的问题。

Plan-on-Graph：改计划是 patch，不是 regenerate

这是我觉得最值得单独拎出来讲的一点。对比表（README 原文）：

Planner 的「规划语言」是五个结构化图操作：create_tasks、patch_task、replace_dependencies、set_task_status、set_node_status。每条 Planner 命令都要带 reason，并且可以引用它所依据的图节点或事件。

任务和动作是分离的：目标、任务、里程碑、blocker、scope 活在 Task Graph 里；底层的工具动作留在 append-only 的 ExecutionLog 里。这个分层让「计划」和「执行痕迹」不会互相污染。

四、三图架构与因果推理链

v2 持久化的是三张图，外加一条 append-only 事件账本：

1
2
3
4
5

flowchart LR
    Evidence[Evidence] -->|supports / contradicts| Hypothesis[Hypothesis]
    Hypothesis -->|confirms| Vulnerability[Vulnerability]
    Vulnerability -->|exploited by| Exploit[Exploit]
    Evidence -. observed on .-> Endpoint[WebEndpoint / Service]

• Task Graph：目标、任务、依赖、里程碑、blocker、scope。Planner 的地盘。
• Reasoning Graph：Evidence / Hypothesis / Vulnerability / Exploit 的因果链。Projector 的地盘。
• Operation Graph：WebEndpoint、Service 这类具体实体。推理图通过 cross-graph context 链接到它。
• ExecutionLog：append-only 的执行事件账本，是上述一切的输入源。

因果链的四个约束（这是本文开头说的「硬约束」的具体化）：

1. Evidence first —— 推理节点和边必须保留支撑它的事件引用。
2. Explicit uncertainty —— hypothesis 和 confirmed vulnerability、successful exploit 是不同的节点类型，不允许混为一谈。
3. Enforced provenance —— 确认的 Vulnerability 节点和成功的 Exploit 节点没有 evidence 引用就写不进去。
4. Asynchronous projection —— Projector 用有界的 observation batch 异步转图，不阻塞 Executor 的循环。

第 3 条是整个项目的立意所在。绝大多数「AI 渗透工具」的问题不是模型不够聪明，而是它说有洞的时候你没法验证它为什么说有洞。当 schema 强制要求 evidence 引用时，你就把「幻觉成漏洞」这条路径在数据结构层面堵掉了一大半 —— 剩下的那一半，靠的是复核者愿意不愿意去看那条 evidence。

Runtime invariants（8 条，改代码前先读）

README 把这 8 条单独列出来，我认为是作者最想让人看见的部分：

• Planner 独占任务图决策；Executor 绝不改任务拓扑
• Executor 在 TaskEnvelope 边界内独占底层动作选择
• Supervisor 只管是否继续，不投影语义图事实
• Projector 只写推理图 / 操作图，不改任务节点
• 每次 Agent 调用都有显式终止工具契约
• Projector 的 desired / committed watermark 单调
• 图变更与已提交的投影 watermark 是原子的
• 持久化的 event 与 artifact 是可观测性的唯一真相来源

五、沙箱与出网收口

这一节是它和「玩具项目」的分水岭。

Docker 是每个 Task 一个 Executor，跑在私有内部网络上。 Executor 和它的 Gateway 处在不同的 network namespace，而 Gateway 是该任务网络的唯一出口。HTTP/HTTPS 在任何 TCP 端口上被透明捕获，其他 TCP 原样中继。

权限上做得也干净：

• Executor 容器以 UID 1000、零 capability、只读根文件系统运行，/tmp 限大小，只有 /workspace 持久且主机可见。
• Gateway 容器先 drop 所有 capability，再只加 NET_ADMIN / SETUID / SETGID；PID 1 配好 TUN 和策略路由后启动 Go Gateway 进程，该进程随后清空自己的 capability bounding set。
• 没有 Docker 时，macOS 走 Seatbelt、Linux 走 Bubblewrap，workspace 是显式的开发兜底。
• Executor workspace 之外的主机路径在强制沙箱模式下 fail closed。

Scope 是网络授权根，不是提示词。 --scope 接受逗号分隔的 IPv4 / CIDR / 精确域名 / 前导通配域名。裸 IP 归一成 /32。省略 --scope 时 Planner 只从 --goal 里抽取明确出现的 IPv4 和 CIDR，确定性校验会拒绝臆造或放宽的网段；域名 scope 必须显式给。如果 goal 里没有任何显式 IPv4 目标，启动直接失败并要求你补 --scope。

这一点我认为比其他同类项目都严谨：scope 不是写在 system prompt 里求模型别越界，而是写进 Gateway 的策略里，越界在内核态就被拒。 域名 scope 还有一层：Gateway 会过滤 DNS 查询，把返回的 IPv4 加进该任务本地、会过期的 kernel set 再放行响应；域-derived 的 UDP/ICMP 只能访问经由该 Gateway 受控 DNS 学到的地址。

会话目录结构

每次 CLI 调用都会建一个隔离 session（.agent-runtime/sessions/<session>/）：

六、部署与上手

环境硬门槛

安装

1
2
3
4
5
6
7
8

git clone https://github.com/SanMuzZzZz/LuaN1aoAgent.git
cd LuaN1aoAgent
npm ci
npm run build

# Docker 后端需要这两个镜像；./install.sh 会自动构建
npm run build:executor-image
npm run build:network-image

配置 .env（该文件被 Git 忽略，切勿提交）：

1
2
3
4
5
6

LLM_API_KEY=your-api-key
LLM_API_BASE_URL=https://api.openai.com/v1
LLM_DEFAULT_MODEL=your-model-id

# 可选：openai-completions 或 openai-responses
LLM_API_TYPE=openai-completions

跑一次

1
2
3
4
5

npm start -- \
  --goal "评估授权目标 10.0.0.10" \
  --scope "10.0.0.0/24,11.0.0.0/24" \
  --max-cycles 8 \
  --max-parallel-tasks 2

主要 CLI 参数：

1
2
3
4
5
6
7
8
9
10
11

--goal <text>                Agent 目标
--scope <entries>            授权的 IPv4 / CIDR / 域名（如 baidu.com,*.baidu.com）
--proxy <socks5-url>         把 scope 内的 Agent TCP 透明走 SOCKS5
--runtime-dir <path>         新运行时的空目录
--resume <session>           恢复某个 runtime（自动带出 Goal 和 Scope）
--max-cycles <number>        无进展时 Planner 的最大连续轮次
--max-parallel-tasks <n>     最大并发任务数
--max-run-time-ms <number>   全局运行超时（毫秒）
--json                       关闭 TUI，最后打印 JSON
--jsonl                      以 JSON Lines 流式输出持久事件
--no-tui                     关闭交互式 TUI

--resume 不要带 --goal 或 --scope —— 它会恢复原会话的 Goal 和 Scope，重复传反而会覆盖授权范围，这是个容易踩的安全坑。

机器可读输出：最后一条 JSONL 记录是 type: "result"，之前全是 type: "event"。接外部系统用这个。

LLM 之外的两个可选 key：BRAVE_SEARCH_API_KEY（web_search，没 key 时退化为 HTML 搜索兜底）、NVD_API_KEY（vulnerability_search 提速率，非必需）。

七、边界与风险（必须诚实说的部分）

1）AGPL-3.0 是最现实的一道坎。 不是 MIT / Apache 那种「拿去用」，网络服务化部署也触发源码披露义务。企业里真要用，法务这一关大概率过不去。个人研究、教学、授权红队自用没问题。

2）v2 的 benchmark 还没有。 README 用 NOTE 明确写了：v1 报告的成绩不自动归给 v2，v2 的成绩要等「在冻结 release 上可复现重跑」之后才发布。而你在 README 顶部看到的腾讯比赛 badge 属于 v1 时代。现阶段没有公开的 v2 横向评测数据，想评估效果只能自己搭环境跑。

3）高危动作没有人工审批闸门。 Roadmap 里 Human approval gates for high-risk actions 还是未勾选状态。也就是说当前版本下，Executor 在 scope 内决定打就打了。实践建议：只在完全隔离的靶场 / 一次性 VM 里跑，别接任何生产流量的网络。

4）Node.js 25+ 的门槛比看起来高。 因为它依赖内置 node:sqlite，这不是「装个新版本」就行 —— 很多团队的 CI 镜像、内网镜像源根本没 25.x。而且 v2 是 2025-12 才起步的新实现，生产环境验证样本很少。

5）Docker 在 Linux 上的权限是个隐性风险。 文档建议 sudo usermod -aG docker $USER，而 docker 组等价于 root。如果你的机器上有别的东西，这一步的副作用要自己评估；不装就只能用 Seatbelt / Bubblewrap 兜底，出网收口能力会打折。

6）Roadmap 未完成项还有几个关键的：稳定的 v2 扩展 API、打包好的容器运行时与部署 profile、可复现的公开 benchmark、跨运行的能力记忆。扩展工具目前没有稳定 API，想加自己的工具要等或自己啃内部接口。

7）Open Issues 只有 4 个，这未必是「很稳定」。 项目 10 个月、v2 是重写、用户基数还小，issue 少更可能反映的是用的人还不够多，而不是质量已经收敛。

八、上手建议（按这个顺序来）

1. 先在一次性 VM 或容器里装。 执行器能跑 shell 命令，README 自己的 WARNING 就写了要用隔离主机。别在你的日常开发机上跑第一次。
2. 先把 Docker 后端跑通再谈别的。 npm run build:executor-image + npm run build:network-image 这两个镜像是出网收口和沙箱的基础，跳过它等于把最重要的安全机制关掉。
3. 第一次跑把 scope 收到最小。 用 /32 单 IP 而不是 /24，确认 Gateway 确实拦住了越界访问（看 traffic/ 下的 .net.jsonl 遥测）再放大。
4. 用 --max-cycles 3 --max-parallel-tasks 1 起步。 先看清 Planner 怎么建图、Executor 怎么用工具、Projector 怎么投影，再谈并发。交互式 TUI 的 Tab / Shift+Tab 可以在「全部任务」和「单任务」之间切换，看得很清楚。
5. 重点看 Reasoning Graph，不看最终报告。 这个项目的价值在过程而不在产物。Web workbench 里把 Evidence → Hypothesis → Vulnerability → Exploit 这条链走一遍，你会立刻明白它和别的工具差在哪。
6. 想接自动化就走 --jsonl，最后一条 type: "result" 是终态。但别指望它当 CI 门禁 —— 定位和耗时都是长任务那一类。
7. 评估「能不能用」之前先确认你要的是 v1 还是 v2。 要现成战绩看 v1 分支；要新架构看 main。别混。

九、一句话结论

如果你关心的是「AI 下的每一个渗透结论能不能被复核」，LuaN1ao v2 是开源里把这件事做到 schema 层面的少数作品，值得认真读一遍它的 Runtime invariants；但如果你要的是「今天装上去、明天出报告」，它还差 v2 benchmark、审批闸门和一条不那么劝退的许可证。

给红队和研究者的第一动作：在隔离 VM 里跑通 Docker 后端，用 /32 单 IP scope 做一次 --max-cycles 3 的短跑，然后去 Web workbench 里把那条因果链从头走到尾。 那一步看完，你就知道它对你的价值有多大了。