bluechips-zhao/DITING

只有在已经开展获授权测试、并且能自备 PostgreSQL、登录密码和模型凭据时才值得试；它是一套自托管工作区，不是开箱即用的扫描器。

解决什么问题

开始一个已划定范围的测试任务时，测试人员通常要把目标资产、抓到的流量、与模型的对话、待确认的发现和最终报告分散放在不同工具里，最后再手工对齐。稍有疏漏，就看不出某条发现来自哪个请求，或者分享的是哪一版报告。DITING 把资产、范围规则、Agent 运行、流量证据和发现放进同一个自托管工作区，一条发现可以回溯到对应的请求/响应，并重新生成报告。得到的是任务的一条审计线索，而不是一堆导出文件。

有什么不同

项目基于 ARTEX 改造，保留资产图、多代理探索、流量证据和人工审批，新增 token/工具预算、证据关系、报告版本、完整导出与加密备份恢复 项目说明。2.6 版侧重运行可观测性：模型调用用量口径、任务执行统计，以及候选发现的来源和审核状态，这些候选信号保持待审核，不会自动当成已确认漏洞 发行说明。预算机制包含保守预留和预算耗尽后的收尾，用来限制失控的循环；不过 README 明确说明 token 预算只是本地用量账本，不等于供应商账单金额。

代价是这套工具高度依赖操作者判断。约束只作为代理上下文，工具拦截规则独立执行，所以范围控制需要两处都配好。候选发现不会自动升级为确认漏洞，人工审核是流程的一部分，而不是可有可无的润色。

谁值得试

适合个人渗透测试者或小型红队：希望在授权范围内使用自托管的 LLM 辅助工作区，并且愿意自备数据库和模型配置。Docker 用户会得到一份 compose 模板，运行时密钥和工作区数据分属独立持久卷，密钥不会落在可浏览的工作区目录 备份说明。想要一键云端扫描，或者本机跑不了 PostgreSQL 16+ 的人，不适合。非 Windows 平台需要从源码编译；发行包只提供 Windows amd64，Docker 模板走源码构建入口，不附带预构建镜像。

使用条件与边界

首次使用是空白业务状态：没有演示数据库、管理员密码、模型密钥或任务，配置意味着建好 PostgreSQL 16+ 数据库、设置至少 8 位登录密码并配置模型 开始使用。源码构建需要 Go 1.26.3+、Node 22、npm 和 PostgreSQL。初始化向导只绑定回环地址，并检查本机来源、Host 和一次性启动令牌。

后续维护的成本更高。模型凭据等机密用独立的 secrets.key 加密保存；密钥丢失或被替换可能导致启动中止，备份时必须把该密钥一起打包，或明确声明已另行备份。从 2.3.x 升到 2.4.0 会加密旧凭据，因此回退需要恢复升级前的数据库和工作区备份。README 还说明，发布时本机 Docker 不可用，2.6.0 容器镜像没有重新构建和验收；此前 2.5 的本地记录也不算这次正式镜像的验收。

HotRepo 点评

HotRepo 在 2026-10-25 记录到 119 个总 star、新项目榜（并非总榜）第 23 名，仓库创建于 2026-10-11。目前没有可比的日榜历史，因此无法判断热度能否持续。投入时间之前，建议先确认 Windows 发行包和文档中的加密备份恢复流程与你的环境相符，因为真正用起来之后，恢复流程往往才是最要紧的那一环。