你每天都在用 Claude Code 写代码、修 Bug、重构模块。你觉得它是个听话的助手。Elder-plinius 不这么想。在他看来，你桌上的那个 AI 编程代理已经是黑客了，只是还没人给它发武器。
这就是 T3MP3ST 在做的事。2026 年 7 月 4 日上线 GitHub，不到三周冲到约 2,700 Stars，安全圈直接炸了。不是因为技术有多炫，而是它的设计思路实在太”省事”：不训练专属模型，不额外申请 API Key，不依赖云基础设施。把你已经登录的 Claude Code、OpenAI Codex 或 Hermes 接上，它就把你的编程助手变成了能自主完成侦察到漏洞利用全链条的红队作战单元。听起来像科幻片里的情节，但它的基准测试结果摆在那，每一条都可以复现。
XBEN 104 道黑盒挑战 pass@1 达到 90.1%，比 XBOW 自报的 85% 还高。40 道 Cybench 学术基准无提示解了 23 题。更关键的是，在 10 个 2026 年新披露的真实 CVE 上，单智能体精准定位了 8 个的文件、行号和 CWE 分类。这些漏洞的披露时间在模型训练截止日期之后，排除了死记硬背的可能。如果看整个工具套件的覆盖度，10 个 CVE 全部被检出。
说白了这篇文章就想讲清楚两件事：这个框架到底怎么把编程 Agent 变成攻击者，以及安全圈为什么对它又爱又怕。那它具体好在哪？
打动我的几个地方
T3MP3ST 最核心的设计，是那个被 README 反复强调但容易被忽略的概念：“无密钥作战”。它不是一个独立的漏洞扫描器，而是一个编排层。你把 War Room（跑在 localhost:3333 的 Web 面板）连上你本地的编程 Agent，剩下的侦察、扫描、漏洞利用、报告生成全部由 Agent 驱动，T3MP3ST 负责递工具、管节奏、做出口控制。
工具箱的规模比我想象的大。默认 35 个工具覆盖 nmap、nuclei、semgrep、ffuf、gobuster 这些红队常用链。如果你开启 T3MP3ST_FULL_ARSENAL 标志，工具数直接跳到 108 个，包含 Metasploit 和 Hydra 这类后渗透驱动。不过完整武器库需要人工审批才能调用，不是一键自动开火。这个设计在安全框架里不算新鲜，但放对地方很关键。
八操作员模型是让我觉得”这个设计是真懂红队”的原因。Recon 管侦察，Scanner 管扫描，Exploiter 管漏洞利用，Infiltrator 管横向移动，Exfiltrator 管数据提取，Ghost 管持久化和隐身，Coordinator 管任务调度，Analyst 管模式分析与报告。每个角色映射到 MITRE ATT&CK 战术 ID，不是随便起的名字。
从侦察到分析研判，八个角色完整覆盖了一条杀伤链的所有战术阶段。这张图最值得注意的不是角色的数量，而是它们之间的递进关系：前一阶段的输出直接成为后一阶段的输入，不需要人工切换上下文。
最让我停下来想一想的，是它的基准测试有一个 npm run verify-claims 命令。项目 README 列出的所有数字，都绑定了一个可重新计算的校验靶标，27/27 项全部绿色通过。作为一个在 GitHub 上见过太多”水分”项目的人，这种做法戳中了我的一种直觉：它不是在宣传，而是在提供可复现的证据。和那些用精心挑选的 benchmark 截图来吸引 Star 的项目相比，T3MP3ST 的底气来自可验证性。你有多久没见过一个安全工具在 README 里主动告诉你”我们的数字可以自己重算”了？
但数据好看不等于能用得顺手，实际打开看看是什么感觉？
跑起来看看
T3MP3ST 的安装步骤简单到让人不安，尤其是当你习惯了安全工具动辄几十行依赖配置的时候。如果你已经有 Claude Code 或 Codex 在本地运行。
npm install
npm run server
浏览器打开 http://127.0.0.1:3333/ui/，在 War Room 的 Settings 页面连上本地的 AI Agent。然后在 Op Admiral 面板用自然语言描述授权测试目标，Agent 就开始自主工作了。整个过程不需要填任何新的 API Key，这是 T3MP3ST 和其他安全框架最根本的差异。
War Room 的界面设计走的是实用路线，没有花哨的仪表盘。左侧是任务列表和 Agent 状态，右侧是执行日志和发现摘要。对于习惯 CLI 的人来说，面板的学习成本大概在五分钟以内。如果你不想依赖本地 Agent，或者想接入第三方 LLM 做推理后端，也可以配置 API Key。
export OPENROUTER_API_KEY=sk-...
export XAI_API_KEY=...
它甚至支持完全离线运行，只要你有 Ollama 在本地跑着。对于不想让测试数据经过任何外部 API 的安全团队来说，这条路的价值不言而喻。
ollama serve && ollama pull llama3
export TEMPEST_LOCAL_BASE_URL=http://localhost:11434/api
export TEMPEST_LOCAL_MODEL=llama3
npm run build
npx tempest
有几个配置点值得注意：
-
容器默认绑定 127.0.0.1:3333，仅限本地访问，这个安全默认是合理的 -
出口范围限制硬编码：一旦定义了任务目标，所有网络工具自动拒绝向目标范围外的公网主机发起连接 -
早期用户的主要卡点在 Agent 连接配置和环境变量拼写上，多 Agent 并发时的上下文隔离还不够直观
好在维护者 Joseph Magly 的响应速度相当快，大部分配置类问题都在 24 小时内给了答复。维护者 Joseph Magly 的响应速度相当快，大部分配置类问题都在 24 小时内给了答复。
体验上的坑说清楚了，不过更关键的问题还没聊：这东西到底适合谁？
什么时候用，什么时候别用
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 内部红队自动化 | 安全团队 | 零额外成本，复用现有 Agent | 多 Agent 协同未经验证 |
| 授权渗透测试 | 渗透测试员 | 完整杀伤链覆盖 | 需要理解 Agent 行为 |
| CTF 竞赛 | 安全研究者 | Cybench 58% 无提示通过率 | 部分模块仍实验性 |
| 漏洞挖掘研究 | 安全研究员 | CVE 定位精准 | 样本量小，方向性参考 |
| Web 应用安全审计 | 蓝队/红队 | XBEN 90.1% pass@1 | 仅限 XBEN 验证场景 |
不适用的情况也很清楚。项目文档写得直白：多 Agent 协同的”群组”模式处于实验阶段。基准测试中那些亮眼的数字，全部来自单 Agent 的 ReAct 循环，不是 8 操作员一起上的效果。如果你想把 T3MP3ST 扔给一个目标然后去喝咖啡，我劝你清醒一点。框架的 Scout、Scanner、Exploiter 三个早期阶段的单 Agent 执行是稳定的，但从 Infiltrator 往后的渗透链还没经过规模化验证。
另一个不太适合的场景是做云基础设施和移动端的深度测试。项目自己的状态表标得很清楚，Cloud IaC 和 Mobile 模块还在开发中，二进制逆向也停在 Roadmap 阶段。如果你的目标主要是这些领域，现在还不是入手的时候。
场景聊完了，该看更实际的问题了：这个项目能活多久？
维护靠不靠谱
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | 约 2,791（2026 年 7 月） | 上线不到三周，增速惊人 |
| 核心维护者 | 2 人（elder-plinius + jmagly） | Bus Factor 偏低，单点风险 |
| Commits | 152 次 | 迭代频率高 |
| 协议 | AGPL-3.0 | 商业使用受限 |
Stars 涨得快，但这不是我关注的重点。2 个核心维护者负责 152 次提交、一个多 Agent 框架、108 个工具适配器和一个完整的 War Room 界面，这个工作量分配一眼就能看出来 Bus Factor 偏低。如果 Joseph Magly 或者 Pliny 中间有一个人退出，项目的迭代速度会立刻受到影响。
不过社区讨论的质量相当高。Reddit 的 blueteamsec 社区把这个框架的发布称为”自主红队工具领域的里程碑事件”。安全研究员 Sean Breeden 在自己的博客里写了一份详细的技术分析，提出了一个值得防御方关注的角度：T3MP3ST 的八操作员模型不仅是攻击框架，还可以反过来当作防御路线图。Recon 和 Scanner 阶段依赖暴露的攻击面，对应防守方的 EASM 持续扫描就是这个阶段的克制手段。
HackerNews 的讨论里有不少人关心滥用问题。Pliny 在 README 里用加粗字体写了一条不可协商的规则：“一切仅用于授权测试”。AGPL-3.0 协议本身不具备防止滥用的法律效力，但这至少表明了作者的立场。说实话，在安全工具越来越容易被滥用的当下，AGPL-3.0 的选择也限制了一些企业用户的采用意愿。
聊完了数据和社区，该聊点真的了：值不值得跟？
我的真实看法
翻完 T3MP3ST 的代码、基准测试结果和社区讨论，花了我大半个晚上的时间，结论比最初预想的复杂得多。
这不是一个”好”或”坏”的项目。它是一个信号。AI 攻击能力的民主化，和 AI 编程能力民主化走的是同一条路：先是少数人掌握，然后是工具化，然后门槛消失。T3MP3ST 把第二步和第三步压缩到了同一天。根据 Check Point Research 的数据，AI 辅助的攻击在 2025 年 Q1 到 2026 年 Q1 之间增加了 1,265%，这不是巧合。
让我觉得不太舒服的一点是，它的基准数据确实好，但好到让人本能地想怀疑。XBEN 90.1% 比 XBOW 自报的 85% 高，Cybench 58% 的通过率对于一个 2026 年 7 月才发布的项目来说非常激进。好在 verify-claims 命令提供了可复现性，你可以自己跑一遍验证。目前能看到的外部独立验证还不多，这是需要更多时间来回答的问题。
对比同类项目，T3MP3ST 和 RedAmon 走了完全相反的路。RedAmon 是全栈平台，10 层纵深防御，Neo4j 图数据库做攻击链记忆，开箱即用但需要配置 API Key 和 Docker。T3MP3ST 是 Agent-as-Platform 路线，零配置复用已有 Agent，轻量到可以直接 CLI 跑。RedAmon 在安全防护维度拿到 8.0/8.0 的评分，而 T3MP3ST 只做了出口范围和 Agent 连接层面的基本约束。选哪个，取决于你更需要”深度可控”还是”零门槛上手”。
至于值不值得跟。如果你是安全团队，想降低内部红队的工具成本和接入门槛，T3MP3ST 的无密钥设计确实解决了真问题。如果你是个体研究者，想探索 AI Agent 在漏洞挖掘中的边界，它的单 Agent 基准已经足够有说服力。但如果你是防御方，真正该问的问题不是”这东西能攻破我的系统吗”，而是”我的暴露面在它的侦察阶段能坚持多久”。目前最成熟的模块是侦察和单 Agent 利用，多 Agent 协同的”群组”攻击还是实验性的，但侦察这块已经足够让防守方紧张了。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/elder-plinius/T3MP3ST |
| 官方文档 | https://github.com/elder-plinius/T3MP3ST/tree/main/docs |
所以，说完了分析，接下来就是行动了。
先看 Issue 再 Star
如果你在做内部安全测试，直接用 npm install 把 War Room 跑起来，连上已有的 Claude Code 或 Codex，从 XBEN 基准开始熟悉它的工作模式。如果你只是好奇，先去 Issue 区翻一遍，看清楚当前单 Agent 和未来群组之间的差距有多大。这个项目最值得关注的时间点，不是现在，而是多 Agent 协同从实验性变成稳定标注的那一天。
好吧，得承认最开始我是带着 BS 检测器打开这个项目的。但 verify-claims 那个 27/27 的绿色通过，加上基准测试的透明度，确实让我收窄了判断。它不是完美的，但它把该做的事做了，把难的事——多 Agent 规模化验证——坦诚地标成了”实验性”。这在安全工具里不多见。