open·kritt：让 AI 团队协作挖漏洞的安全研究平台

当你独自面对百万行代码

想象一下，你是一个独立安全研究员，接到了一个众测任务：目标是一个拥有数十万行代码的 DeFi 协议，奖金池高达数十万美元。传统的做法是什么？手动审计？用 Semgrep 跑规则？这些都是单兵作战——你的注意力会随时间衰减，你可能会漏掉一个关键路径，变量命名不规范的项目更是让人头疼。

现在，有一款工具告诉你：不用你一个人扛，让一群 AI 特工队帮你找。

这就是 open·kritt——一个开源的、自托管的 AI Agent 编排平台，专门为代码漏洞挖掘而设计。它的核心理念很简单：与其让一个大模型囫囵吞枣地读整个代码库，不如把任务拆解成多个小的、专注的子任务，并行调度多个 AI Agent 协同工作，最终把输出汇总、去重、排序，得出真实可用的漏洞报告。

这个理念不是闭门造车。开发团队 Kritt AI（代号 Blockian）依靠这套方法论，已在各大漏洞赏金平台斩获了 超过 150 万美元的奖金——这是经过真实战场检验的实战派工具。

图：open·kritt 的可视化工作流构建界面，支持拖拽式编排多个分析步骤

拆解任务：让 AI 各司其职

open·kritt 的工作方式借鉴了人类安全团队的协作模式。在真实的安全审计中，团队成员通常会分工协作：有人专门负责审计智能合约的访问控制，有人负责检查 SQL 注入路径，有人负责复现 PoC。open·kritt 把这个模式搬到了 AI 层面。

工作流（Workflow） 是 open·kritt 的核心抽象。一个工作流由多个"步骤（Step）"组成，每个步骤对应一个特定的 AI 分析任务。这些步骤可以串行执行，也可以并行调度，步骤之间通过共享上下文传递分析结果。例如，第一步可以让 AI Agent 扫描代码中的危险函数调用（如 eval()、exec()、system()），第二步则针对这些危险调用路径进行深度溯源分析。

这种"分而治之"的策略解决了大模型在代码审计中的核心痛点：注意力分散。当一个模型试图同时理解整个代码库时，它往往会在无关的辅助代码上浪费大量推理预算。open·kritt 通过工作流将 AI 的注意力引导到真正需要关注的安全关键路径上。

支持多模型：Codex、Claude 和 OpenRouter

在模型支持方面，open·kritt 展现了极佳的开放性。它并不绑定某一个 AI 提供商，而是同时支持：

• GitHub Codex（基于 GPT-4 的代码专用模型）
• Anthropic Claude（支持 Claude Code 运行时）
• OpenAI GPT 系列（通过 OpenRouter 接入）
• OpenRouter 聚合（一个 API 接口对接数十个模型）

这种多模型架构背后有实际的安全研究考量：不同模型在代码分析上有各自的优势和盲点。Claude 在长上下文理解上表现出色，Codex 在代码补全和 API 调用上更精准，GPT-4 在复杂推理上更强。安全研究员可以根据目标代码的特性选择最合适的模型，甚至在同一工作流中混用多个模型进行交叉验证。

图：open·kritt 支持同时配置多个 AI 模型提供商

验证与 PoC 生成：不只是发现问题

大多数静态分析工具的输出止步于"这里可能有问题"——这对于安全研究员来说只是起点，还需要大量手动工作去验证和复现。open·kritt 在这方面迈出了关键一步：它内置了 后置脚本（Post-scripts） 机制，支持在发现疑似漏洞后自动执行验证脚本、构建概念验证（PoC），并生成结构化的漏洞报告。

这个设计对实战意义重大：当你运行完一个工作流后，收获的不再是一堆模糊的告警，而是一份可以直接提交给甲方的漏洞报告。open·kritt 还支持自定义严重性评级规则和自动去重机制，确保你不会在同一个问题上浪费精力。

部署体验：开箱即用的 docker-compose

对于一个自托管工具，部署门槛决定了它能否真正落地。open·kritt 在这方面做得很贴心：项目提供了一个 ./kritt 启动脚本，封装了 git clone → ./kritt setup → ./kritt start 三步曲，背后由 docker-compose 完成所有服务的编排——前端 React + Vite、后端 Express + Prisma（PostgreSQL）、引擎层 Python + 多 Agent 调度器。

不过，有一个安全提醒值得特别关注：AI Agent 会在容器内以 root 权限 运行，并拥有可写的代码库副本和直接的互联网访问权限。这意味着 AI 可以执行 apt install、pip install，甚至编译和运行二进制文件——这对安全研究来说是必要的（因为漏洞验证往往需要这些能力），但如果用来扫描来源不明的代码，就存在一定风险。项目文档明确建议：仅在专用的 Docker 主机或 VM 上运行 open·kritt。

在资源需求方面，由于涉及容器化编译和多 Agent 并行调度，建议配置 4 核以上 CPU、8GB 以上内存，并预留至少 20GB 的磁盘空间用于 Docker 镜像和本地代码仓库缓存。

局限与争议：没有银弹

客观地说，open·kritt 并非万能药。它的局限性主要体现在以下几点：

第一，AI 幻觉问题依然存在。 即使有工作流引导，AI Agent 仍可能产生误报（将无害代码标记为漏洞）或遗漏（真正的漏洞未被触发）。open·kritt 的后置脚本验证机制有助于降低误报，但并不能完全消除。

第二，许可证限制。 项目采用 AGPL-3.0 开源许可，意味着如果你在 SaaS 服务中集成并提供访问，需要开源你的修改。这对商业化使用有一定约束。

第三，无内置认证。 默认配置下服务仅绑定 127.0.0.1，且没有应用层认证机制。项目文档建议配合反向代理实现访问控制，这对于想要在团队内共享使用的用户来说需要额外配置。

第四，对模型提供商的强依赖。 漏洞发现的质量直接取决于底层 AI 模型的能力。如果你的 Codex 或 Claude 账号额度耗尽或模型版本更新导致能力变化，分析效果也会随之波动。

项目结构：前后分离 + Python 引擎层

从代码架构来看，open·kritt 采用经典的前后分离设计：

模块	技术栈	职责
前端 frontend/	React + Vite + TypeScript	可视化工作流构建、结果展示
后端 backend/	Express + Prisma + PostgreSQL	API 服务、数据库持久化、认证管理
引擎 engine/	Python + asyncio	Agent 调度、代码扫描执行、Docker 容器管理
视图 executor-view/	独立服务	Agent 执行过程的实时可视化

后端使用 Express 框架搭配 Prisma ORM 与 PostgreSQL 交互，数据库 migrations 存放在 database/ 目录。前端依赖 React Router 实现 SPA 路由，UI 组件风格统一使用 Prettier 进行格式化。

行业意义：从一人战队到 AI 军团

open·kritt 的出现折射出一个更宏观的趋势：AI 安全研究正在从"人海战术"向"智能编排"演进。传统漏洞赏金中，一个安全研究员需要数年经验积累才能覆盖足够多的漏洞类型和攻击面。而 open·kritt 通过工作流将专家知识结构化，让经验较少的研究员也能调用经过实战验证的分析套路。

从数据上看，Kritt AI 团队已通过这套方法论获得了超过 150 万美元的漏洞赏金，这个数字本身就是对工具实用性的最强背书。更值得关注的是，随着 Claude Code 和 GitHub Copilot Workspace 等 AI Coding 工具的普及，代码安全问题正在爆发式增长——根据多项研究，AI 生成的代码在安全漏洞密度上并不低于人类编写，而传统扫描工具对 AI 代码的适配又普遍滞后。open·kritt 这样的 Agent 化审计平台，恰好填补了这一空白。

从 GitHub Star 增长来看，该项目目前约 970 颗星，对于一个 2024 年才进入公开阶段的安全工具来说，这个增速反映了市场对 AI 安全研究工具的强烈需求。

总结

open·kritt 是一款将 AI Agent 编排理念深度融入安全代码审计的开源平台。它通过工作流机制将复杂的漏洞挖掘任务分解为可管理的子任务，支持多模型并行分析，并内置验证和 PoC 生成能力。docker-compose 一键部署降低了使用门槛，AGPL-3.0 许可证保证了开源透明性。

对于独立安全研究员和小型安全团队，open·kritt 是一个值得尝试的效率倍增器；对于企业安全团队，它提供了将 AI 安全分析能力内网化的可行路径。不过需要清醒认识到：它是一个强大的辅助工具，而非替代安全专家的银弹——AI 幻觉、无内置认证、对模型提供商的依赖等局限在实际部署时需要纳入考量。

一句话评价：让 AI 特工队替你挖漏洞，实战验证过的效率工具，但记得管好你的 API 密钥和容器权限。