LuaN1aoAgent v2：把渗透测试推理写成因果图的 TypeScript 智能体
LuaN1aoAgent is a fully autonomous AI-driven penetration testing agent powered by graph-based cognitive reasoning.
秒懂
- 它是什么？
- v2 用 TypeScript 与 Pi SDK 重写了 v1 的 Python 运行时，把 Planner、Executor、Observer 拆成显式边界，并要求漏洞与利用结论必须挂上证据引用。本文只依据仓库说明与 README 描述其机制、配置入口与限制。
- 适合谁用？
- 适合已经具备授权测试流程、并且愿意维护一套 TypeScript 运行时与模型 API 成本的团队，尤其是那些更在意结论可追溯性而不是单次跑分的人。不适合把它当成一条命令出报告的工具，也不适合 Node.js 版本停留在 24 及以下、或者无法接受 AGPL-3.0 传染性条款的组织。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它想解决的不是扫描覆盖率，而是结论说不清来源
传统自动化渗透工具的产出是一份漏洞清单，问题在于清单里的每一条都缺少推理过程。扫描器报出一个可疑端点，人接手时往往要重新走一遍判断：这条告警基于哪次请求、哪段响应、哪个假设，中间有没有被推翻过。LuaN1aoAgent 的切入点就在这里。README 把设计原则写成一句话：每个重要结论都必须能追溯到持久化的事件、产物和图证据。
目标用户是已经拿到授权、正在做安全研究的工程师，而不是想找一键工具的人。仓库描述里写的是 autonomous、authorized security research，这两个限定词决定了它的定位。它不负责发现资产，也不负责替代人工判断，它负责的是把一次测试过程中的观察、假设、确认漏洞和成功利用串成一条可回看的链条。
这个定位也解释了为什么 v2 要做成一次重写而不是原地重构。README 明确写着 v2 不是 Python v1 运行时的原地重构，配置、持久化、Agent 生命周期和可观测性契约都不一样。换句话说，v1 时代积累的调参经验在 v2 上基本作废。
Planner、Executor、Observer 三个角色各自拿什么、交什么
v2 把原先共享历史的 P-E-R 循环拆成显式运行时边界，三个角色的输入输出都被收窄。
Planner 读的是压缩后的任务图、推理图和操作图视图，产出的是目标级任务，而不是具体动作。它负责依赖关系、优先级、独立任务并发度、范围和任务预算。README 提到一个细节：图变化和任务交接之后，Planner 会拿就绪任务去匹配可用容量，而不必等一整批并行任务全部结束。这是调度层面的设计，不是提示词层面的技巧。它的决策通过 planner_submit 这个终止型工具提交。
Executor 收到一个边界明确的 TaskEnvelope，自己决定用什么工具策略。它记录公开意图、工具输入、工具输出、用量、错误和最终任务结果。大体积输出会被存成不可变产物，而不是塞进 Agent 上下文。同一个 Task 的不同 epoch 复用同一条持久化 Pi session 血缘和同一个工作区，不同 Task 之间保持隔离。结果通过 task_result_submit 提交。
Observer 分成两个独立模式。Supervisor 在热路径上检查 Executor 最近的动作，决定继续、打检查点、停止还是把控制权交回 Planner。Projector 异步把归一化后的观察转成带证据的推理图和操作图增量。README 特别说明每次调用都用全新的 Pi session，不共享隐藏的模型历史。两者分别通过 control_submit 和 graph_delta_submit 提交。
一个直接后果是模型调用次数会明显上升。每次 Observer 调用都是一条干净的会话，代价是上下文无法在 Observer 内部累积，换来的是判断不被前序对话污染。这个取舍是否划算，取决于你的模型单价和任务规模。
因果图强制了证据引用，也强制了它自己的表达方式
推理图的结构在 README 里给了明确的边类型：Evidence 通过 supports 或 contradicts 指向 Hypothesis，Hypothesis 通过 confirms 指向 Vulnerability，Vulnerability 通过 exploited by 指向 Exploit，Evidence 通过 observed on 指向 WebEndpoint 或 Service。
关键约束在于强制溯源。已确认的 Vulnerability 节点和成功的 Exploit 节点，没有证据引用就写不进去。这条规则把「模型觉得这里有洞」和「有请求响应支撑这里有洞」分开了。假设节点和确认漏洞节点在数据结构上就是两类东西，不会被一段流畅的叙述抹平。
跨图关联是另一个设计点。推理图里的结论会链接到操作图里的具体实体，也就是说一条判断最终能落到某个具体端点或服务上，而不是悬在半空。
需要直说的地方是：这套结构对使用者有要求。图模式是固定的，如果你的测试场景里存在难以归入 Evidence、Hypothesis、Vulnerability、Exploit 这四类的中间结论，就得想办法硬塞进去，或者让它只留在事件日志里而不进图。README 没有给出扩展节点类型的说明，这一点在动手前值得确认。
任务图是改出来的，不是重新生成出来的
Planner 维护的是一张持续演化的任务图，而不是每次重新生成一份线性清单。README 给出的图操作包括 create_tasks、patch_task、replace_dependencies、set_task_status，示例图里 Goal 分出 Recon Task 和 Auth Task，Recon 产出 Service Profile 里程碑，Validation Task 依赖这个里程碑和 Auth 的结果，另有 Blocker 节点通过 blocks 边挡住 Validation。
这个模型和「生成一份待办列表然后逐条执行」的差别在于，依赖关系是一等公民。某个任务被阻塞时，Planner 看到的是图上的阻塞边，而不是执行到一半才发现前置条件不满足。任务可以打补丁，依赖可以整体替换，状态可以单独设置，这些都是在既有图上做的增量操作。
代价是 Planner 需要持续读取三张图的压缩视图来维持判断。图越大，视图压缩策略就越关键，而 README 没有展开说明压缩是怎么做的。如果你的测试范围很大，任务图节点数上百之后 Planner 的判断质量如何变化，属于需要自己观察的部分。
跑起来需要哪些前置条件
README 的徽章给出了两条硬性运行时要求：Node.js 25+ 和 TypeScript 5.x。Node.js 25 这个版本线本身就过滤掉了一批环境，很多长期支持版本还停在更早的号段，部署前先确认这一点。
运行时是 Pi SDK，架构标记为 P-E-O。v2 的配置契约与 v1 不同，README 用 IMPORTANT 块做了提醒，所以不要拿 v1 的配置文件往 v2 上套。
工具提交入口是这套系统里最明确的一组接口名：planner_submit 用于 Planner 决策，task_result_submit 用于 Executor 任务结果，control_submit 用于 Supervisor 的控制决策，graph_delta_submit 用于 Projector 的图增量。这四个终止型工具是三个角色与运行时之间的实际契约边界。
仓库提供了中英文双份 README，中文版在 README_CN.md。首页字段为空，没有独立站点，文档以仓库内文件为准。
需要说明的是，本次材料里没有完整的配置键清单和启动命令，README 在系统架构一节之前就被截断了。因此具体的环境变量名、模型供应商参数、工作区路径配置，只能以仓库当前文件为准，这里不做推测。
真正会卡住你的地方
第一个限制写在 README 自己身上。v1 报告过的基准结果不会自动归属到 v2，v2 的基准结果要等到在冻结版本上完成可复现的重跑之后才会公布。这意味着现在没有任何可引用的效果数据，任何关于它能打穿多少目标的说法都没有依据。
第二个限制来自架构本身。Observer 每次调用都用全新 Pi session，不共享隐藏的模型历史。单次判断更干净，但同一段上下文会被反复重读，token 消耗随任务步数增长。长任务上这是实打实的成本项。
第三个限制是授权边界。仓库描述里写的是 authorized security research，这是一款需要你自带合法授权的工具。它不会替你判断目标是否在范围内，范围控制靠的是 Planner 的 scope 设置，而范围一旦配错，自主执行的部分不会替你踩刹车。
第四，证据强制引用是一把双刃剑。它挡住了无依据的漏洞结论，也意味着某些确实成立但难以用一次请求响应固化的判断，会停留在假设层而无法升级。对某些类型的测试目标，这可能让图看起来进展缓慢。
第五，Node.js 25+ 的要求会把一部分只在旧版本上验证过的 CI 环境排除在外。
和共享历史的单体 Agent 差在哪
最常见的替代做法是单个 Agent 加一条长对话历史，边聊边调工具。这种方案的优势是上下文连续，模型能看到自己前面所有动作，短任务上开销更低，实现也简单。
LuaN1aoAgent v2 走的是相反方向。它把共享历史拆掉，换成三个角色各自持有收窄的输入：Planner 看压缩后的图视图，Executor 看一个 TaskEnvelope，Observer 每次开新会话。角色之间不通过对话传递状态，而是通过结构化提交工具和持久化的事件、产物传递。
差别体现在两个地方。一是可追溯性，单体 Agent 的结论藏在对话历史里，翻起来要靠人读；v2 的结论挂在图上，带证据引用。二是并发，Planner 能在图变化后立即把就绪任务匹配到可用容量，不必等整批并行任务收尾，单体 Agent 的线性历史很难做到这一点。
反过来，单体方案在短平快的小目标上更省。v2 的三角色拆分、图投影和证据校验都是固定开销，目标越小，这部分开销占比越高。如果你的场景是单台主机、几个端口的快速验证，这套架构大概率是过度设计。
维护成本与 AGPL-3.0 的实际含义
许可标识是 AGPL-3.0。这类许可的关键点在于网络服务条款：如果你修改后以网络服务形式提供给他人使用，通常需要向使用者提供对应源码。它不是可以随手嵌进闭源产品的许可。具体到你的使用方式是否触发义务，需要咨询法务，这里只指出这个条款存在，并且它在 AGPL 里是核心条款而非附注。
维护成本方面，README 明确 v2 与 v1 的配置、持久化、Agent 生命周期和可观测性契约都不同。这意味着从 v1 迁移不是改几个参数，而是要重新理解一套运行时契约。v1 被标注为 Legacy，两个版本在同一天发布，v2 是 2026-07-20 的 18:09，v1 是当天的 17:50，相差不到二十分钟。这个发布节奏说明 v1 是作为历史版本一并留档的，不是仍在并行演进的路线。
升级成本还来自运行时依赖。Node.js 25+ 和 Pi SDK 这两项决定了你的构建环境和 CI 镜像要跟着走。仓库最后推送时间是 2026-08-24，v2.0.0 发布之后一个月左右，处于活跃维护期，但材料里没有版本支持策略的说明。
编辑结论
适合已经具备授权测试流程、并且愿意维护一套 TypeScript 运行时与模型 API 成本的团队，尤其是那些更在意结论可追溯性而不是单次跑分的人。不适合把它当成一条命令出报告的工具，也不适合 Node.js 版本停留在 24 及以下、或者无法接受 AGPL-3.0 传染性条款的组织。上手前先确认三件事：本机 Node.js 是否达到 25 及以上、用于执行工具的隔离环境是否已经就绪、以及 README 中列出的配置项在你选定的模型供应商下是否都能填齐。v2 的基准结果按仓库说明要等到冻结版本上复现重跑之后才会公布，所以任何关于成功率的预期现在都只能悬置。
社区笔记