阿图因 AI 凭什么在 CyberGym 测试中超过 Mythos？看懂 Agent 与模型的真正差别

阿图因 AI 在分析 curl 项目时，发现了一个新漏洞：CVE-2026-9079。

curl 官方将它定级为中危，并在 8.21.0 版本中完成修复。

关键点来了：此前，Mythos 没有发现这个漏洞。

于是，一个很容易引发争论的问题出现了：

阿图因 AI 是不是比 Mythos 更强？

先别急着下结论。这个结果很有价值，却不能直接变成“阿图因 AI 全面胜过 Mythos”。真正值得看的，是两者根本不是同一类东西。

这次测试到底发生了什么？

事情的背景并不复杂。

研究团队看到 Daniel Stenberg 关于 Mythos 的分析文章后，使用阿图因 AI 对 curl 项目进行安全分析。分析过程中，阿图因 AI 找到了一个新的漏洞，漏洞编号为 CVE-2026-9079。

curl 官方确认了漏洞，并在 8.21.0 版本中修复。

这至少说明了一件事：

• 阿图因 AI 在这次 curl 漏洞挖掘任务中找到了有效结果。
• Mythos 在对应分析中没有找到这个漏洞。
• 这个漏洞得到了项目维护者确认，而不是停留在模型自报的“疑似问题”阶段。

对于漏洞挖掘系统来说，能不能被官方复现、确认和修复，是很硬的指标。模型说“这里可能有问题”，和维护者提交补丁，中间隔着一整套验证流程。

Agent 和模型，不是同一个维度

很多比较会从这里开始跑偏。

大家习惯把 AI 产品都叫作“模型”，可阿图因 AI 和 Mythos 的定位并不一样。

Mythos：更像一个能力核心

模型负责理解代码、推理行为、识别模式，并根据上下文给出判断。

你可以把它看成一位经验丰富的安全研究员。它有很强的分析能力，但需要有人安排工作：

• 该看哪个目录？
• 先分析源码，还是先跑测试？
• 发现可疑路径后，是否需要构造输入？
• 结果能不能复现？
• 哪些问题值得继续深挖？

模型本身未必会自动完成整套流程。

阿图因 AI：更像一支自动化研究小组

Agent 的重点不只是“能不能想明白”，还包括“能不能把任务做完”。

它通常会围绕目标组织多个步骤，例如：

1. 获取并建立项目代码环境。
2. 浏览目录、识别关键模块。
3. 追踪输入、解析和内存操作路径。
4. 调用工具执行测试或构造样例。
5. 根据运行结果调整分析方向。
6. 记录候选漏洞并尝试复现。
7. 整理报告，交给人工或项目维护者确认。

打个比方：

• 模型像发动机，负责思考和判断。
• Agent 像一辆配好导航、工具箱和执行流程的车，目标是把任务跑完。

你不能只拿一辆车和一台发动机比谁“更强”。它们承担的工作不同。

为什么阿图因 AI 可能更适合漏洞挖掘？

漏洞分析不是一次问答。

真实项目往往有几十万行代码，函数之间层层调用。一个问题可能藏在非常不起眼的地方：某个异常分支、一次长度计算、一个边界条件，或者输入经过多次转换后的状态。

Agent 的优势通常来自任务编排。

它会持续推进，而不是回答一次就结束

普通问答模式可能是：

“请分析 curl 是否存在安全漏洞。”

模型分析一轮，给出几条判断，任务可能就停了。

Agent 会把任务拆开。它会继续追踪调用链，运行脚本，检查结果，修正假设。遇到一个方向没有证据，它可以回到上一步，换一条路径继续查。

它能把工具接入分析过程

源码阅读只是漏洞挖掘的一部分。

实际工作还会用到：

• 静态分析工具
• 编译器和调试器
• 模糊测试工具
• 版本对比工具
• 日志与崩溃分析工具
• PoC 验证脚本

一个只会读代码的模型，和一个能读代码、跑程序、看崩溃、反复验证的 Agent，工作结果自然可能不同。

它更适合长流程任务

漏洞挖掘经常需要几十分钟甚至几小时。

某个线索刚出现时，证据可能不够。Agent 可以保留上下文，继续追踪这个线索，而不是每次都从头开始解释。

这也是自动化系统和一次性对话之间的差距。

一次发现，能证明谁更强吗？

不能直接证明。

这次结果可以证明：阿图因 AI 在特定的 curl 漏洞挖掘任务中表现出色，并找到了 Mythos 没有找到的问题。

它无法证明阿图因 AI 在所有安全任务中都更强。

原因很现实：测试任务不同，评分标准不同，工具权限不同，运行时间也可能不同。

假设有两位安全专家：

• A 擅长源码审计。
• B 擅长数据恢复和恶意软件分析。

A 找到了一个关键漏洞，不代表 B 在所有领域都不如 A。把专长领域的成绩，直接扩展成全面排名，结论就过头了。

阿图因 AI 的设计目标偏向漏洞挖掘等具体任务。在这些任务上，它可能更有优势。

换到数据恢复、恶意软件分析等场景，Mythos 可能更强。能力边界要看任务，不能只看一个榜单或一个案例。

看 AI 安全测试成绩，重点盯住这 5 件事

以后看到“某 AI 击败另一 AI”的新闻，可以按下面这份清单检查。

1. 比的到底是什么

是基础模型，还是完整 Agent？

是模型裸奔，还是接入了搜索、代码执行、调试器和模糊测试工具的系统？

比较对象不在同一层，结论就需要谨慎。

2. 任务是否完全一致

两套系统有没有分析同一个项目、同一个版本、同一批文件？

输入提示、环境配置、可用工具和时间限制是否相同？

这些细节都会影响结果。

3. 结果是否经过验证

“发现一个疑似漏洞”不等于“发现了有效漏洞”。

更可信的结果通常包含：

• 可复现的触发条件
• 清晰的影响范围
• 项目维护者确认
• 漏洞编号或正式记录
• 已发布的修复版本

CVE-2026-9079 能得到 curl 官方确认并进入修复版本，证据链就比普通模型报告完整得多。

4. 有没有统计多个任务

单个漏洞很容易受到偶然因素影响。

更可靠的测试应该覆盖多个项目、多个漏洞类型和多个难度等级，然后统计：

• 有效发现数量
• 误报数量
• 漏报数量
• 平均分析时间
• 复现成功率
• 报告质量

只报一个“击败了谁”的案例，适合传播，不足以完成严谨评估。

5. 能力是否能迁移

一个系统在 curl 上表现很好，换到 Linux 内核、浏览器、数据库或移动应用后，表现会怎样？

真正有价值的安全 Agent，需要在不同代码风格、不同语言和不同漏洞类型中保持稳定输出。

如果你想自己评估一个漏洞挖掘 Agent

不需要一上来就分析大型项目。咱们可以从小型开源项目开始，流程更容易控制。

准备测试环境

选一个有明确版本记录的开源项目，固定：

• 项目版本
• 编译器版本
• 操作系统
• 依赖版本
• 测试数据
• 分析时长

环境不固定，结果很难复现。

设定清晰任务

不要只给一句“找漏洞”。可以把目标写清楚：

分析指定版本的项目，寻找可由外部输入触发的内存安全问题。
请记录相关函数、输入路径、触发条件、影响范围，并提供可复现的验证步骤。
所有结论必须区分“疑似问题”和“已验证问题”。

任务越清楚，结果越容易比较。

记录完整过程

别只保存最终报告。

同时记录：

• Agent 查看过哪些文件
• 执行过哪些命令
• 哪些方向被放弃
• 每个候选问题花了多少时间
• 是否出现误报
• 是否成功构造复现样例

这些数据能帮你判断，系统是真有分析能力，还是只是碰巧命中了一个点。

让人工完成确认

AI 报告只能作为候选线索。

提交给维护者前，人工需要检查代码路径、触发条件、影响判断和修复建议。安全场景里，误报会消耗大量时间，错误结论还可能干扰项目维护。

避坑清单：看到“AI 击败模型”时别急着转发

• 把一个案例当成全面排名。
• 把 Agent 的系统能力算成基础模型的单独能力。
• 只看发现数量，不看误报和复现率。
• 忽略工具权限、运行时间和上下文长度。
• 把“疑似漏洞”直接写成“确认漏洞”。
• 只比较成功案例，不公布失败任务。
• 忽视任务类型，拿漏洞挖掘成绩推断恶意软件分析能力。

结语：更值得关注的是系统怎么工作

阿图因 AI 发现 CVE-2026-9079，是一个值得重视的信号。

它说明，面向具体安全任务设计的 Agent，可能通过任务拆解、工具调用和持续验证，找到单次模型分析遗漏的问题。

但这不等于阿图因 AI 在所有场景都胜过 Mythos。

更准确的说法是：在这次 curl 漏洞挖掘任务中，阿图因 AI 交出了更好的结果。至于谁更强，要看测试范围、任务类型、工具条件和验证数据。

看 AI 安全能力，别只盯着“击败”两个字。真正有含金量的，是它能不能稳定找到问题，能不能把问题复现出来，能不能给出维护者用得上的报告。