大佬们，我在这分享一个最近捣腾的开源项目：mythos-agent 一个 AI 驱动的代码安全智能体。
- GitHub： https://github.com/mythos-agent/mythos-agent
- 主页： https://mythos-agent.com
- 飞书群： https://mythos-agent.com/feishu
- Discord： https://mythos-agent.com/discord
- 协议：MIT
简单说下为什么做这个，以及怎么跑。
起点
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 这种阈值过滤才真的有意义。
技术选型
- TypeScript 写的，TS/JS 用 Babel 解析器，其他语言（ Python 、Go 、Java 、PHP 、Rust 、C/C++）走各自的 parser 适配器，统一到一个 normalized CST
- 43 个扫描分类（ 15 个正式上线，28 个实验中）：SQL 注入、SSRF 、路径穿越、命令注入、XSS 、JWT 算法混淆、竞态、加密误用、AI/LLM 安全（ prompt injection 、cost attack ）、供应链（ typosquatting ）、零信任、隐私/GDPR 等
- 329+ 条内置规则，8 种目标语言
- 后端支持 Claude 、GPT-4o 、Ollama ，以及任意 OpenAI 兼容端点；纯规则模式完全离线，不需要任何 API key
- 输出 SARIF 2.1.0 （ GitHub Code Scanning 直接能用）、HTML 报告、JSON
- 发布产物用 Sigstore (cosign) 签名，附带 CycloneDX SBOM
目前难题
- 动态类型语言 (Python 、JS) 的 false positive 比静态类型语言多。类型信息是 Analyze 阶段的重要信号，没有的话整体置信度偏低。
- 跨第三方依赖的污点追踪会丢信号。污点流进一个没源码的 dep ，假设阶段只能按 public API 推测，容易过度生成。
- 成本。全仓跑假设生成用 Claude / GPT-4o 一次不便宜，CI 里建议只跑 diff 。
适合谁用
- 平时写 TypeScript / Node.js 后端，想给 CI 加一层 SAST 又不想买商业扫描器
- 给 LLM 集成类项目做安全审查（ prompt injection / 客户端 API key 泄漏 / 未鉴权的付费模型调用这几类传统 SAST 基本覆盖不到）
- 对 SAST + LLM 的结合方式感兴趣，想看看一个开源实现长什么样
最后
MIT 协议，v4.0.0 今天刚发。欢迎拍砖，特别想听几个方向的反馈：
- 假设生成这套路子，你们有没有踩过类似的坑？哪些假设类型特别容易翻车？
- 对动态类型语言的 AST 归一化，有什么经验？
- SARIF 2.1.0 除了 GitHub Code Scanning ，还有哪些下游消费者真的能把字段完整渲染出来？
如果有 bug 或者 false positive 例子，直接开 issue ，最好附一小段能复现的代码片段。谢谢各位。
目前尚无回复
Select Language