暑期实习时我搭建了这一个自用渗透工作台，缝合了挺多的东西，但十分有效。

一开始我寻求开源社区的“渗透Agent”现成方案，但却不尽如我意。我尝试了Strix，它的架构不错，但是Python写的，运行起来实在太卡了，而且缺少很多Agent应有的功能（比方说不能主动压缩导致非常烧Token，打断也比较麻烦），我喜欢它的思路，但它的架构让微调实在太麻烦了。

于是我搭了 pentest-box：以 Kali 攻击工具链为执行层，以 OMP 为驾驶舱，再叠一层多专家子代理与黑板协调，并使用开源社区搜罗的各种渗透技能。

2. 总体架构

flowchart TB
  subgraph Host["宿主"]
    Chrome["有头 Chrome + CDP"]
    Proxy["系统代理"]
    OMPAgent["~/.omp/agent<br/>LLM 配置与登录态"]
  end

  subgraph Box["pentest-box 容器"]
    OMP["OMP 驾驶舱"]
    CSO["cso 主会话<br/>定界 / 派工 / 评审"]
    Experts["cae / cie / cpe / cre / cce"]
    Skills[".omp/skills/"]
    BB["blackboard.json"]
  end

  subgraph Out["产出"]
    Eng["engagements/目标/"]
    Scans["scans/"]
    Reports["reports/"]
  end

  Chrome --> OMP
  Proxy --> Box
  OMPAgent --> OMP
  OMP --> CSO
  CSO --> Experts
  Experts --> Skills
  Experts --> BB
  Experts --> Eng
  Eng --> Scans
  Eng --> Reports

三层分工：

渗透产出统一进 engagements/<目标>/：scans/ 放大体积原始输出，reports/ 放可交付报告，黑板状态与 engagement 同目录。

3. 容器基座：把「能跑」做成「能长期用」

镜像以攻击工具链为基座，工作目录挂载到 /work。真正决定能不能天天用的，是几条工程决策。

3.1 非 root 运行

容器默认用户是 pentester（uid 1000，与常见宿主用户对齐），sudo 免密。写入 /work 的文件在主机上属于当前用户，如果默认root用户则跑完会在主机上出现一地必须用root权限才能操作的垃圾。

需要原始套接字的操作（如 nmap -sS、masscan、抓包）显式加 sudo，边界清晰。

3.2 run-box.sh：代理透传

宿主若设了 http_proxy / https_proxy / all_proxy，脚本会：

1. 把 URL 里的 127.0.0.1 / localhost 改写成 host.docker.internal；
2. 以 -e 注入容器；
3. 给 no_proxy 自动补上 host.docker.internal 等。

3.3 browser-host.sh：宿主有头浏览器附着

容器内 OMP 的 browser 工具通过项目级配置附着宿主 Chrome 的 CDP 端口。登录态、JS 渲染、验证码人工点一下，都还能用真实浏览器。

3.4 单实例约束

~/.omp/agent 挂进容器是为了复用主机的 LLM 配置与登录态。尽量不要同时跑两个挂载同一 agent 目录的 omp 实例（sqlite 会话库并发写风险）。容器里跑 omp 时，主机上的最好先退出。

4. 技能库：可触发的方法论，不是提示词堆

技能目录里有上百个专项。来源大致两类：

1. 公开精选与迁移：网络安全公开技能集、以及从 Strix 体系迁移过来的 strix-* 技能（SQLi、XSS、SSRF、IDOR、工具语法等）。
2. 按实战补的增强技能：国内 OA / 国际 CMS 定向验证、备份与敏感路径发现、证据包固化、独立结果核验、业务逻辑与越权知识库、进阶 Web 绕过笔记、收尾与 preflight 等。

设计原则只有几条，但很硬：

• 先指纹再定向，禁止无版本盲打；
• 技能带 SKILL.md + references/，能对照、能回源；
• 工具缺失先上报、再安装，不静默改环境；
• 试错型向量（SQLi / XSS / SSRF 等）优先脚本批量喷洒，再挑异常做人工验证。

技能多不等于能用。中间做过一轮质量治理：把不可执行的文稿重写成通顺、可落地的方法论文档，清掉死引用和卫生问题。对外交付的是「能照着做」的技能，不是「看起来很长」的 markdown。

5. 多代理编排：cso 不亲自打洞

来自玄幕的角色迁移。

主会话扮演 cso（编排者）：读范围、拆目标、按域派专家、过评审门、维护覆盖、汇总报告。需要触碰目标就派子代理；主会话自己不跑扫描器、不发注入 payload。

纪律：

• 一代理一任务，子代理不要多任务一起做导致注意力涣散；
• 任务书自包含，子代理看不到主会话，范围、非目标、已有线索、产出路径都要写进任务书；
• 动作风险分级 T0–T3：被动情报可以直接派；利用尝试必须有明确意图；后渗透与高影响动作证据标准更严，且要独立验证。

漏洞工作流固定走三段链：

发现代理 → 独立验证代理（发现者不得自证）→ 报告代理

Critical / RCE 一类结论，再过结果核验门。合法结局有三种：无发现、验证失败（误报排除）、确认漏洞——前两种同样要记，不硬报。

6. 黑板：多代理并行时的唯一协调面

并行时不能靠「大家都记得聊天里说过什么」。黑板是跨代理的共享推理图，节点三类：

• Intent：打算探什么方向；
• Fact：已经确认的发现（必须挂到促成它的 Intent）；
• Hint：人工指导，创建后不流转。

状态机：proposed → in_progress → confirmed | rejected | superseded。死路应该标 rejected。

每个目标一份 engagements/<目标>/blackboard.json，写操作走 CLI（文件锁 + 原子替换），禁止手改 JSON。

7. 覆盖治理

「扫过了」和「覆盖完了」不是一回事。每个范围内资产只能处于一种状态，例如：

covered / active / queued / blocked / deferred / thin / out of scope

其中 thin 很关键：只抽了常见口、深扫和 HTTP 认领还没做，不得当 covered。禁止用「下线」代替 blocked/thin；只有全端口（或已触发的深扫）加多路径证据一致无 listener，才能结「无 Web 面」。

评审门是 failure-seeking 的：每次子代理返回后，对照用户要求逐项标 satisfied / incomplete / blocked……证据薄、仅抽样、未验证的，一律 incomplete。端口覆盖是硬项：范围内每个 IP 有没有扫口证据？常见口全失败有没有触发深扫？每个 open 口有没有 HTTP(S) 认领？任一否就继续派，不收场。

新线索出现时做关联：凭据/token 触发访问复测，端点/对象 id 触发越权复测，版本号触发已知面审查。专家说「blocked until X」，就把 X 存成复测触发器——X 出现就定向跟进，而不是让旧失败沉底。

8. 一条最小工程闭环

搭完骨架后，一次干净任务大致是：

1. 定界：目标、授权、明确非目标；
2. engagements/<目标>/ 建工作区，初始化黑板；
3. cie 建攻击面（资产、端口、指纹），结果写 Fact；
4. cpe 按优先级验证（IDOR / SQLi / SSRF / XSS …），独立验证代理复现；
5. 确认项固化证据目录（请求/响应 raw、meta、必要时截图）；
6. wrap-up：自包含报告、覆盖板收口、残留面与风险定性。

9. 边界：做什么，不做什么

做：

• 授权范围内的侦察、验证、留证、收尾；
• 多工具交叉，扫描器结论必须 PoC 复现；
• 白盒场景尽量给到代码级修复建议。

不做：

• 无授权扫描与范围外扩展；
• 把模型幻觉或扫描器输出直接当结论；
• 为了「自动化」牺牲独立验证与覆盖治理。

已知限制也如实说：部分工具镜像里没有，按需安装；上游方法论文档更新后要手动同步；容器默认 --rm，装过的工具用完即丢——要长期用就进 Dockerfile 重建。

附录

仓库：github.com/Liushenwuzhu-Alpaca/pentest-box

起点

起因是想尝尝最新上线的Kimi-K3模型，看看它的前端能力怎么样。

一开始只是和它说搭一个博客，顺利搭建后发现只是去拉了一个模板，审美风格我并不满意，于是后面我又尝试重构了。

设计稿与审美风格

我比较青睐Anthropic式的审美风格，于是先和模型对话、让它尝试解析风格，并做出了一个网页给我呈现。通过网页呈现和细化描述，我和模型最终敲定了一个设计稿。

设计稿定了几条原则：纸面质感、发丝线、衬线、克制。技术栈是 Astro + 一套主题骨架，部署到 GitHub Pages，另备一个 Docker 镜像以后上服务器。

第一天晚上线了基础站点和第一批功能：文章导航、相关文章、友链页、页脚的朱砂印章和「已书写 N 字」统计、Konami 码解锁的隐藏主题。第二天上了清单一到三档的剩余功能：阅读进度条、项目页 GitHub 同步、系列文章、此刻流、相册、生长状态、修订次数、节气日期、暗色问候、随便看看，外加 Giscus 评论和 Umami 统计。

并行智能体：快，但要看住

为了速度，功能被拆成互不重叠的文件块，派给多个子代理并行实现。两轮下来，教训比代码多。

代理会跑题，而且理直气壮。 让它做「GitHub 仓库同步」，它交回来一个没人要求的统计页，还顺手改了导航；让它做「印章与统计」，它去改了别人的文章页。两个跑题的代理，失败模式一模一样：不做被指派的，做自己想到的。对策只有一个——文件所有权写死在任务书里，完工后用 git status 对账，越界一律回退。

代理的报告不可全信。 有代理弄坏了页面模板（两个 div 没闭合），报告里写「构建通过」；有代理把真实的编译错误称为「历史遗留问题」。所以每一条代理汇报都要对着磁盘验证：diff、构建、浏览器实测，一个不能少。

验证要针对功能，不只是构建。 「随便看看」按钮在代理环境里一直静默降级到归档页——因为它拿生产域名的 atom.xml 和本地预览比同源，全部丢弃。构建是绿的，功能是坏的。这类 bug 只有真的点一次才能发现。

数据诚实

书单、相册、装备这些页，上线时都是空态——「清单整理中，照片还在冲洗」。这是故意的。代理曾经「贴心」地在装备页写了我没说过的东西（KDE Plasma 桌面），被发现后删掉了。个人站点的每一行个人事实都必须是真的，空着比编的好。

人也干了活

不是一切都交给 AI。身份改名、印章字样是自己在间隙里改完直接提交的；使用说明书也是自己先写了一版——AI 不知情，又写了一份覆盖上去，发现后恢复了人的版本，只把新信息补进去。网络抖动时推送也是手动完成的。

协作里最舒服的分工大概是：人负责审美判断、事实和最终拍板，AI 负责体力活和全量验证。

现在的样子

打开首页能看到纸面和印章；文章页顶部有进度发丝线，日期旁有节气或 🌱；底部有上一篇下一篇、相关文章和评论区；页脚能「随便看看」，暗色模式下多一句问候。输任意页面上 ↑↑↓↓←→←→BA，会解锁第四套配色。

剩下的没做完：Newsletter 需要外部账号，书单和相册等我慢慢填。清单在仓库里，做完一项勾一项。

方法论小结

• 拆任务按文件所有权拆，不按「聪明程度」拆
• 代理汇报一律对账磁盘，构建绿不等于功能对
• 空态优于编造，回退优于报错
• 人保留审美和事实的最终决定权

它基于 Astro 和 Retypeset 构建，托管在 GitHub Pages。之后会在这里记录计算机学习笔记、项目实践和一些值得留存的想法。

写作原则

尽量写清楚问题、过程和结论。把当下不完全的理解留下来，等未来有新的认识再修订它。