分析日期: 2026-06-05｜基于 kc-portfolio-algo-v251210 组合算法项目审计任务的实际对比
背景
使用同模型（deepseek-v4-flash）同算力（本地 V100）分别运行 opencode 全自动编程 和 Hermes 私人助理 对 kc-portfolio-algo-v251210 项目进行代码审计，评分差距巨大：
| 工具 | 审计评分 |
|---|---|
| OpenCode | 70+ 分 |
| Hermes | ~15 分 |
根因分析
一、代码加载方式（贡献 35%）
| 维度 | OpenCode | Hermes |
|---|---|---|
| 代码摄入 | 批量加载整个项目所有 .py 文件到上下文 | 逐文件工具调用（read_file + search_files） |
| 上下文连贯性 | 全库在同一个代际上下文中，跨文件引用可一次分析 | 文件间跳转需等工具返回，跨文件关系被冲淡 |
| 文件数量影响 | 10 个文件 = 100 个文件，批量加载无差别 | 20+ 文件需多次 read_file，读不完就开始总结 |
二、任务分解——根本差距（贡献 40%）
OpenCode 的 SDD 流程（项目 STD.md 中定义）：
Understand → Spec → Test → Code → Review分析代码前先理解架构，再系统化逐一检查每个模块：输入格式、边界条件、错误处理、性能瓶颈。每阶段产出一份结构化文档。
Hermes 的默认行为：
用户要求分析 → 打开几个关键文件 → 凭印象写总结没有阶段化分解、没有检查清单、没有逐模块覆盖。从历史 trace 看，重构 PortBacktest 的 Trilium 笔记时：✅ 画了 ASCII 流程图 → ✅ 整理了参数表 → ✅ 列出优化项 → ❌ 未逐行审查代码逻辑 → ❌ 未发现硬编码问题 → ❌ 未检查错误处理 → ❌ 未交叉引用问题
三、审计深度（贡献 15%）
OpenCode 会做：
- 逐函数签名检查：参数类型、返回值、None 路径
- 数据流追踪：asset → asset_matrix → _asset，每一步 shape 一致性
- 错误路径枚举：calc_chip_floor_left() 返回 NaN 的影响链
- 性能分析：循环向量化可行性、pandas 操作优化
- 代码异味检测：硬编码常量（保证金=1、手续费=0）、魔法数值
- 输出结构化报告：问题清单 + 严重级别 + 代码定位 + 修复建议
Hermes 实际产出（从 trace 看）：
- ✅ 画了几个 ASCII 流程图
- ✅ 整理了参数表格
- ✅ 列出了优化项
- ❌ 没有逐行审查代码逻辑
- ❌ 没有发现硬编码问题
- ❌ 没有检查错误处理
- ❌ 没有交叉引用问题
四、工具链副作用（贡献 10%）
Hermes 的 read_file / search_files / terminal 工具链在代码审计场景下是负面资产——每次工具调用都刷新上下文窗口，打断连续推理链。而 OpenCode 直接通过 Go SDK 批量读取文件系统，无中间工具调用开销。
根因归因
| 原因 | 贡献占比 |
|---|---|
| OpenCode 全量加载代码（vs Hermes 逐文件工具调用） | 35% |
| OpenCode SDD 流程化审计（vs Hermes 无检查清单） | 40% |
| Hermes 工具调用碎片化打断推理链 | 15% |
| Hermes 无代码审计专用模式/Skill | 10% |
改进方向
要让 Hermes 达到接近 OpenCode 的代码审计质量，需要：
- 为审计编写专用 Skill：强制分阶段执行（全量加载 → 清单检查 → 逐模块覆盖 → 结构化输出），不让 AI 自由发挥
- 批量代码加载机制：增加一次性读取整个项目目录树的能力，减少逐文件工具调用
- 审计检查清单模板：函数签名、数据流、错误处理、性能热点、代码异味，逐项强制覆盖
- 结构化报告框架：问题编号 + 严重级别 + 文件定位 + 修复建议的统一输出格式
📅 2026-06-05 · 基于实际对比数据的根因分析