Cairn：把渗透测试当作状态空间搜索的通用引擎
A AI general-purpose state-space search engine, validated first on autonomous penetration testing.
秒懂
- 它是什么？
- Cairn 是一个通用问题求解引擎，先用自主渗透测试验证了自身。它不定义角色，不预设工作流，只凭事实、意图和提示构成的黑板架构，在未知状态空间中寻找从起点到目标的路。
- 适合谁用？
- Cairn 适合那些问题结构清晰、起点和目标明确、中间路径未知的自动化任务，尤其是 CTF、漏洞验证和需要并行探索的渗透测试场景。它不适合需要严格角色分工或预设流程的团队，也不适合无法接受 AGPL-3.0 传染性的闭源项目。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 8 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个不叫渗透测试工具的渗透测试引擎
Cairn 的 README 开篇就划清了界限：它不定义角色，不定义工作流。给定一个起点和一个目标，它在未知的状态空间中搜索路径。渗透测试只是第一个被验证的领域。这个定位让它区别于市面上一堆号称 AI 渗透测试的产品。那些产品往往预设了侦察、扫描、利用这样的阶段，而 Cairn 把问题抽象成更底层的形式。起点是已知的目标 IP，目标是拿到 shell 或 flag，路径未知。这种结构在漏洞研究、数学证明、CTF 题目里同样存在。Cairn 就是为这一类问题设计的。它用事实、意图和提示三个原语来驱动搜索，而不是用一堆预定义的 agent 角色。
黑板、事实图与 OODA 循环
Cairn 的核心是黑板架构。所有 agent 不直接通信，只通过一个共享的图来协调，这种机制叫 Stigmergy。图上有三种节点。Fact 是已确认的客观发现，写入黑板。Intent 是尚未执行的探索方向。Hint 是人在任意时刻注入的判断，agent 下次读取时会吸收。图从起点向目标生长，每个新 Fact 是一块垫脚石，每个 Intent 是向未知迈出的一步。Agent Worker 跑一个 OODA 循环：观察整张图，定位当前状态，决定下一步意图，执行探索，然后把发现写回为新的 Fact。Worker 没有固定角色，任务是根据图当前状态在运行时生成的，而不是来自预定义的职位描述。这个设计的关键在于，协调成本被压到了最低，因为所有信息都在一张图上，没有信息孤岛。
三种任务，同一套 Worker
Cairn 只有三种任务类型，全部由同一个 Worker 执行。Bootstrap 在项目开始时尝试直接解决问题，输出一个 Fact 或者直接完成。Reason 读取整张图，判断目标是否达成，以及下一步该探索什么，输出可能是 Complete、新 Intent 或 no-op。Explore 认领一个 Intent，执行探索，报告发现，产生一个 Fact。这种设计的简洁性值得注意。它没有为不同阶段设计不同的 agent，而是让同一个 Worker 根据图的状态动态决定自己该做什么。这意味着系统对问题领域的适应不靠增加角色，而靠图本身的演化。从架构图看，Cairn Server 只维护图的一致性，Cairn Dispatcher 负责读取图、调度任务、管理容器，并且是协议的唯一写入者。每个项目有自己的 Worker Container，里面可以并发跑多个 Agent Worker。Worker 只接收 prompt 并返回结构化输出。
本地模式与容器模式的选择
部署方式有两种。容器模式需要 Docker，每个项目一个 Worker Container，隔离性好，适合并行跑多个项目。本地模式不需要 Docker，Worker 直接跑在 Dispatcher 主机上。README 明确说 Docker 仅在容器执行时需要，本地模式可以完全跳过。这个灵活度对资源有限的团队是实际的考量。容器模式要拉两个镜像：一个是 worker container 镜像，地址是 ghcr.io/oritera/cairn-worker-container:latest，另一个是构建 Cairn 的基础镜像 ghcr.io/astral-sh/uv:python3.13-trixie。然后用 docker compose up --build 启动，cairn-server 跑在 8000 端口，cairn-dispatcher 等 server 通过健康检查后再启动。配置方面，需要复制 dispatch.example.yaml 为 dispatch.yaml，填上你的 LLM endpoint 和 API key。支持的 worker 后端是 Claude Code、Codex 和 Pi。
竞赛成绩背后的冷启动故事
README 里最有信息量的不是 54/54 的解题数，而是那句「系统在比赛前从未测试过」。全流程在比赛当天凌晨 4 点才第一次跑通。没有训练，没有调参，没有领域专用工具，零 MCP 工具，零 RAG，零预定义 agent 角色。这个成绩来自腾讯云黑客松第二届 AI 渗透测试挑战赛，610 支队伍，1345 名参与者，Cairn 是唯一 AK 的队伍，最终排名第三。这段叙述的价值在于它展示了系统的泛化能力，但也要冷静看待。一次竞赛的成功不能证明系统的长期稳定性。竞赛环境是封闭的、目标明确的，而真实渗透测试往往有噪音、有对抗、有模糊的目标。Cairn 的架构设计确实为泛化做了准备，但验证还停留在单次事件上。
局限：当状态空间搜索不是答案
Cairn 的抽象有一个隐含前提：问题必须能被表述为起点、目标、路径三要素。这个前提在渗透测试里成立，在 CTF 里成立，但并非所有安全任务都满足。比如需要持续监控的蓝队场景，没有明确的「目标状态」，搜索框架就套不上。另一个问题是调试难度。因为 agent 之间不直接通信，所有协调都发生在黑板上，当系统行为不符合预期时，你只能从 Fact 和 Intent 的演化去追溯原因。这比查看多 agent 对话日志要抽象得多。还有资源消耗。每个项目一个容器，每个容器里多个 Worker 并发跑 OODA 循环，每个循环都要调用 LLM。成本不是线性的，而是随图规模增长。README 没有给出任何性能基准或成本数据，这一点在采用前需要自己验证。
同类工具的差异：从预设角色到动态生成
要理解 Cairn 的取舍，可以对比那些预设 agent 角色的渗透测试框架。常见的做法是定义侦察 agent、扫描 agent、利用 agent，每个有固定 prompt 和工具集。这种方法的优点是行为可预期，缺点是遇到没见过的场景时容易卡住，因为角色边界限制了探索方向。Cairn 反过来，不设角色，任务从图状态动态生成。Worker 每次读图，自己判断该做什么。这个差异在架构层面是根本性的。预设角色相当于把解决方案写死在代码里，动态生成则是把解决方案交给 LLM 在运行时推导。Cairn 的 README 用 OODA 循环来描述这个过程，本质上是在模仿人类分析师的决策方式，而不是流水线式的步骤执行。哪种更好取决于你对 LLM 推理能力的信任程度，以及你对结果可复现性的要求。动态生成更灵活，但也更难预测。
维护成本与许可证约束
Cairn 采用 AGPL-3.0 许可证。这意味着如果你修改了代码并对外提供服务，需要开源你的修改版本。对于内部使用没有影响，但如果你计划把 Cairn 集成进商业产品并分发，这个许可证可能是障碍。维护方面，项目最近一次推送是 2026 年 9 月，版本号到了 v0.2.1，说明还在活跃迭代。但要注意，v0.1.0 到 v0.2.1 只隔了七天，版本节奏快不代表稳定性高。README 没有提供升级指南或迁移说明，也没有列出已知问题。对于依赖它的团队，这意味着每次升级都要自己验证行为变化。另外，支持的 worker 后端只有三个，Claude Code、Codex 和 Pi，如果你用的是其他 LLM 服务，要么自己适配，要么放弃。这些约束在采用前都应该有清晰的认识。
编辑结论
Cairn 适合那些问题结构清晰、起点和目标明确、中间路径未知的自动化任务，尤其是 CTF、漏洞验证和需要并行探索的渗透测试场景。它不适合需要严格角色分工或预设流程的团队，也不适合无法接受 AGPL-3.0 传染性的闭源项目。采用前应先确认三件事：你的 LLM 后端是否在支持的 Claude Code、Codex 或 Pi 之列；你的目标环境是否允许容器调度；以及你是否接受黑板架构带来的调试难度，因为所有协调都发生在共享图上，没有直接的 agent 通信日志可查。Cairn 的竞赛成绩来自一个从未预先测试的系统，这既是它的亮点，也是它尚未在长期运行中证明自己的信号。
社区笔记