摘要
iceCoder 是一个自托管的 LLM 运行时治理层，核心理念是“有治理的执行”。在过去一个月的四轮同模型、同任务、盲评裁判的 Benchmark 中，iceCoder 四次战胜 Claude Code——涵盖中等修复、高复杂度分布式事务、长周期创造性任务和 L4+ 超高难度逻辑修复。本文将介绍这个项目的设计哲学、核心架构、Benchmark 结果，以及为什么“可靠性”作为产品价值在当前市场中难以传播。
iceCoder 的双模运行时监管方案，目前仍是一个探索性项目。它并非一个成熟的产品，而是在“AI Agent 过程治理”这个方向上的一次深度尝试。设计思路、架构选型、Benchmark 结果均公开透明，欢迎大家参考、批评、改进，共同推动这个方向的探索。
一、问题的起点：AI Agent 在长任务中会失控
如果你使用过 Claude Code、Cursor 或 Codex CLI 执行过超过 50 轮的长任务，你大概率遇到过以下场景：
- 模型开始反复修改同一个文件，每次改动微小且无意义
- 同一命令失败后不断重试，不知道换策略
- 上下文压缩后丢失关键信息，模型行为出现“断片”
- 模型声称“已完成”，但实际上既没有跑测试也没有确认交付物存在
这些问题并非模型能力不足，而是因为当前的 AI 编程工具缺乏运行时层面的过程治理机制。它们信任模型的自我管理能力，但模型在长任务中会因为上下文膨胀、目标遗忘、信号衰减等原因逐渐偏离正轨。
iceCoder 正是为了解决这个问题而设计的。
二、iceCoder 是什么
iceCoder 不是 IDE 插件，不是 Copilot 的替代品。它是一个跑在你本地仓库上的、带治理机制的执行运行时。
它的核心架构由以下子系统组成：
- Harness 主循环：管理 LLM 与工具的交互，包含权限裁决、验收门禁、上下文压缩与恢复重注入。每一轮都给模型注入结构化的任务状态——当前目标、阶段、已修改文件、验证状态等——模型不需要从聊天历史中“猜测”自己该做什么。
- 双模监管（Supervisor L1/L2）：L1 控制执行模式（free/forced），在风险升高时自动收紧工具门禁。L2 在后台持续观测 no_progress、file_loop、tool_repeat_fail、goal_drift 等信号，必要时 takeover 接管控制权、纠偏后再 handoff 交还。事件写入 supervisor-events.jsonl 供事后审计。
- CheckpointEngine v2：在同一份 checkpoint JSON 上叠加 runtimeV2（工具轨迹、失败恢复、分支预算、监管快照），确保压缩、刷新或进程重启后可以从快照恢复，而非仅靠聊天记录推断。
- TaskGraph：唯一的结构化执行上下文来源。对 edit/debug/test/refactor 类型任务注入节点上下文；对 question/inspect 等探索型任务保持自由模式。
- 文件化记忆：长期事实以 Markdown 文件存储，无需外部向量库。支持粗召回、Dream 整合、加权淘汰与多会话隔离。
三、Benchmark 结果
评测方法
- 同模型：确保双方使用相同模型（minimax-m2.7 / m2.5-pro / MiniMax-M3），剥离模型能力差异。
- 同任务：相同 prompt、相同起始仓库、相同验收标准。
- 盲评裁判：Cursor Composer 2.5 在不知道工具身份的情况下打分。
- 评分体系：40 分客观门禁 + 60 分多维度裁判评分 = 100 分 Composite。
四轮结果
| 任务 | 难度 | 模型 | iceCoder | Claude Code | 差异 |
|---|---|---|---|---|---|
| 多文件订单流水线（4 Bug） | 中等 | m2.7 | 86 | 83 | +3 |
| Saga 仓库对账（7 类缺陷） | 高 | m2.7 | 88 | 85 | +3 |
| Spell Brigade 幸存者游戏 | 超高长周期 | m2.5-pro | 81 | 80 | +1 |
| 计费系统（19 Bug, 97 文件） | L4+ | M3 | 93 | 92 | +1 |
重点分析：计费系统任务
这是迄今为止难度最高的任务——97 个源文件、~9200 行代码、19 处跨模块隐性缺陷，涉及货币、税务、定价、计费、收入确认、催款、幂等等十几个领域。
关键数据：
- iceCoder：23 轮 / 71 次工具调用 / ≈3.6 分钟 / 93 分
- Claude Code：5 分 45 秒 / 92 分
这是 iceCoder 首次在效率维度上领先 Claude Code（快了约 37%）。在之前的创造性任务中，CC 曾以 87 分钟 vs 120 分钟的速度优势胜出。这次的结果表明，在逻辑密集的修复任务中，iceCoder 的上下文注入和结构化状态管理能显著减少模型的冗余试探。
Supervisor 的实战记录：
第 16 轮 Supervisor recover（no_progress）；第 21 轮 handoff 交还模型。
这是双模监管系统在真实 Benchmark 中自动触发并成功纠偏的直接证据。模型在第 16 轮陷入停滞，Supervisor 接管后纠正方向，第 21 轮模型回到正轨。全程零人工介入。
四、为什么“可靠性”难以传播
尽管 Benchmark 数据充分证明了 iceCoder 的优势，但项目在 GitHub 上的关注度极低。这是一个值得深入反思的问题。
- “可靠性”是滞后感知的价值
大多数开发者尚未被 Agent 跑偏折磨过——因为他们很少让 Agent 执行 100 轮以上的任务。只有当一个人经历过“模型跑了一小时，回来发现全是无效修改”时，才会意识到“过程治理”不是多余的负担，而是必需品。
- 护城河是不可见的
Supervisor 在后台纠正跑偏时，用户看到的是“任务还在正常运行”。Checkpoint 在压缩后恢复状态时，用户看到的是“哦，续上了”。这些“什么都没发生”的价值，在静态的 README 中很难被感知。
- 实证型产品需要更长的信任建立周期
iceCoder 的每一个核心功能——Harness、Supervisor、CheckpointEngine——背后都有 1,800+ 条测试用例和多次 Benchmark 验证。但这种“实证可靠性”需要用户投入时间去理解和信任，而竞品的“视觉流畅度”可以在 5 秒内被感知。
五、双模方案的独特性：市面上几乎没有同类产品
在调研了当前主流的 AI 编程工具后，一个值得关注的事实是：iceCoder 的双模运行时监管方案，在目前市面上几乎没有同类实现。
这不是营销话术，而是基于对以下产品的逐一分析：
5.1 主流工具的“模式切换”与双模的本质区别
| 产品 | 相关功能 | 与双模的区别 |
|---|---|---|
| Claude Code | 无内置模式切换；依赖提示词约束 | 完全依赖模型自觉，无运行时硬约束 |
| Codex CLI | 无模式概念 | 模型自由执行，无监管层 |
| Cursor | Agent 模式 vs 普通模式（手动切换） | 用户手动选择，非运行时自适应 |
| Cline | Plan 模式 vs Act 模式（手动切换） | 流程阶段分离，非动态监管 |
| Aider | Architect/Editor 模式（模型分工） | 不同模型协作，非执行约束切换 |
这些产品的共同特点是：
- 要么没有模式概念（完全自由执行）
- 要么需要用户手动切换模式（Plan vs Act、Agent vs Normal）
- 要么依赖提示词软约束（“请按照计划执行”）
它们都没有在运行时层面实现“自动感知任务风险 → 动态调整执行约束 → 纠正后恢复自由”的闭环。
5.2 双模方案的核心壁垒
iceCoder 的双模方案之所以难以复制，是因为它需要同时解决以下问题：
- 实时信号检测：在每轮工具调用后，判断模型是否出现 no_progress、file_loop、tool_repeat_fail、goal_drift 等异常信号。这不是简单的规则匹配——需要结合任务状态、历史轨迹、验收进度做综合判断。
- 接管与交还的完整状态机：Supervisor 的 takeover 不是“报个错就完了”，而是一个完整的状态迁移——free → takeover → handoff_pending → cooldown → free。每次迁移都需要同步 Harness 主循环、TaskGraph、工具门禁、checkpoint 等多个子系统的状态。
- 与 TaskGraph 的深度联动：在 forced 模式下，工具调用必须与 TaskGraph 的当前节点对齐。ToolGate 不是全局开关，而是节点级的白名单——这一步允许改哪些文件、跑哪些命令，都是在任务规划阶段就确定好的。
- 实证验证的工程投入：Supervisor 的 95% 测试覆盖率、1,800+ 条用例、多次 Benchmark 的自动触发记录——这些不是 PPT 上画个架构图就能做到的，而是需要在真实任务中反复调试和验证。
5.3 学术界的相关探索
学术界对“AI Agent 运行时监管”这个方向确实有一些探索（如港中文的 ArbiterOS、Google DeepMind 的 DIR 框架），但它们更偏向安全拦截和架构验证，尚未在实用级 AI 编程工具中形成完整的产品化方案。
iceCoder 是目前已知的唯一一个，将“运行时监管”从学术概念落地为可日常使用的编程工具的案例。
六、与 Claude Code 的客观对比
| 维度 | Claude Code | iceCoder |
|---|---|---|
| 长任务可靠性（100+ 轮） | ★★☆☆☆ | ★★★★★ |
| 防跑偏机制 | 提示词软约束 | 硬约束 + 自动接管纠偏 |
| 崩溃恢复 | 依赖聊天历史 | 结构化快照恢复 |
| 自托管 / 可控性 | 闭源 | MIT 开源，完全自托管 |
| 双模运行时监管 | 无 | 唯一实现 |
| 实时漂移检测与纠正 | 无 | 唯一实现 |
个人体验备注：在日常短任务（30 轮以内）的使用中，iceCoder 的响应速度、工具调用流畅度和交付质量与 Claude Code 相当，并不存在明显的体验差距。上述对比中未列出“短任务体验”这一维度，是因为在作者的实际使用中，两者在该场景下表现接近，未构成显著的差异化。此备注基于作者个人日常使用感受，非 Benchmark 数据。
Claude Code 优化的是“模型自由发挥”的体验——它快速、流畅、不设防。iceCoder 优化的是“长任务的可靠性”——它在后台持续监控、快照、纠偏。两者的设计哲学不同，适用场景互补。
七、开源与参与
iceCoder 采用 MIT 协议完全开源，所有代码、文档、Benchmark 报告均在 GitHub 上公开。项目包含：
- 1,800+ 条 Vitest 测试用例，Harness 覆盖率约 84%，Supervisor 覆盖率约 95%
- 四份完整的 Benchmark 报告，含裁判打分详情和代码 diff 对比
- 完整的中文架构文档和英文 Project Guide
- 27 个内置工具 + MCP 扩展支持
- CLI / Web / WebSocket 三种使用入口
- 冰豆 Web 会话指示器、多会话侧栏、多端扫码同步等完整前端体验
如果你对“如何构建可靠的 AI Agent 运行时”这个话题感兴趣，或者你在实际使用中遇到过 Agent 长任务跑偏的问题，欢迎访问项目主页查看代码和文档。
如果这个项目对你有所启发，或者你认为这个方向值得探索，请在 GitHub 上给项目一个 Star——这是对开源作者最直接的鼓励。
why？CC，codex他们为什么要给模型更高的自由度？因为他们是模型厂商，不愿意承认自己的模型更弱。他们只能做给模型更多自由度的工具。
下一步准备针对deepseek缓存进行优化。预计能提升30%左右的缓存命中率。平均达到90%左右。
后期可能会做gui，但是不太确定什么时间。
大家有问题可以帮我提issue，或者直接发我邮箱:lbiceman@126.com
