大佬们，我在这分享一个最近捣腾的开源项目：mythos-agent 一个 AI 驱动的代码安全智能体。
简单说下为什么做这个，以及怎么跑。
Semgrep / Snyk / CodeQL 这类扫描器用多了，会发现一个很现实的问题：它们能找到的漏洞，基本就是规则库里写过的那些。规则库覆盖不到的结构变体 —— 比如 eval 不是直接作用在 req.body 上，而是中间过了两层函数、变量名被改了 —— 基本就漏掉了。
做一段时间代码审计之后，我意识到人在读这类代码时其实是在提假设：
"这里
path.join拼了用户传的 path ，但没解析 symlink ，是不是路径穿越？" "这里对同一行先读后写，没加锁，是不是 TOCTOU 竞态？"
传统规则匹配做不到这一步，但 LLM 可以。mythos-agent 做的就是这件事：在传统 AST 扫描之上，加一层 LLM 假设生成 + 验证。不是用 LLM 替代规则库，是给规则库补一个"大胆假设、小心求证"的 stage 。
npx mythos-agent scan # 纯规则扫描，不需要 API key ，完全离线
npx mythos-agent hunt # 完整 AI 假设 + 验证流水线（需要 LLM 端点）
npx mythos-agent quick # 10 秒快速体检
典型输出：
✗ src/api/transfer.ts:38 [HIGH, conf 0.88]
Hypothesis: 对 balance 的读-改-写没加行锁，并发请求可能双花。
Evidence: line 42 读 balance ，line 51 写 balance - amount ；
作用域内没有 FOR UPDATE / 事务隔离。
Suggested: BEGIN ... SELECT ... FOR UPDATE ... COMMIT ，
或 SERIALIZABLE 隔离级别。
四个阶段：Recon → Hypothesize → Analyze → Exploit（ Exploit 默认关闭）。
关键是 Hypothesize 和 Analyze 分成两个 agent。Hypothesize 阶段让模型"大胆假设"——允许它对每个函数产出很多不一定成立的具体猜测； Analyze 阶段让另一个 agent 逐条去验证，带置信度打分。两步合成一个 prompt 会退化成"模型既出题又打分"，实际结果是生成一堆看起来合理但实际不存在的 false positive 。
分成两个 agent 之后，--severity high 这种阈值过滤才真的有意义。
MIT 协议，v4.0.0 今天刚发。欢迎拍砖，特别想听几个方向的反馈：
如果有 bug 或者 false positive 例子，直接开 issue ，最好附一小段能复现的代码片段。谢谢各位。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。