半年里我用了四套智能体框架：数据复盘

2026 年 3 月到 9 月，我在本机上先后深度使用过 Codex、Claude Code、ZCode，以及一个自己改造的版本。写这篇的目的不是评测谁更好，而是把自己半年多的使用记录翻出来，看看哪些判断被数据支持，哪些只是当时的直觉。

先说结论

• 迁移从来不是因为"出了新工具"，而是手上的任务类型变了，旧框架的能力边界挡在了那里；
• 会话数量最多的框架，未必是产出最多的框架——短问答会天然抬高会话数；
• 真正跨框架保留下来的是三样东西：规则文件、记忆文件、验收习惯，它们都不在框架里。

一、使用规模

把本机上各框架留下的会话记录统计了一遍：

框架	使用时段	会话/线程规模	主要用途
Codex	2026.03 – 09	783 个执行记录、282 个命名线程	长任务实验、竞赛项目开发、文档材料
Claude Code	2026.06 – 09	9 个项目、93 个会话	科研工作流 skills 套件、鸿蒙端调试
ZCode	2026.08 – 09	29 个会话、3,169 次工具调用	语料摄取长跑、服务部署、数模竞赛
自研版本	2026.06 – 09	仓库内测试会话千级	自己日常改代码

一个容易被误读的数字

Codex 的记录里，362 个是子代理线程——也就是说接近一半"会话"不是我和它对话，而是主流程派发出去的子任务。统计使用量时如果不区分这两类，会把"一次派发 20 个子任务"误读成"聊了 20 次"。

二、四个框架各自解决了我什么问题

Codex：它的优势在长任务的自主推进——目标模式可以把一个实验从"设计"跑到"出结论"，中间不需要我逐步确认。我在它上面跑的是最耗时的类别：竞赛项目的反复迭代、几百次子任务并行的消融实验。

Claude Code：优势是工程细节的把控——它会主动读上下文、追问不清楚的地方，适合"把一件事做对"而不是"尽快做完"。科研工作流套件的 13 个模块与 90 余项测试基本是在它上面成型的。

ZCode：优势是超长任务的稳定执行与大规模并行子代理。三万篇论文的语料摄取（11.2 小时连续运行）和一次十小时的自主研发任务都跑在它上面。

自研版本：优势完全在于可控——持久记忆、按我的任务结构定制的多智能体工作流、以及"目标驱动执行"的具体形式都由我决定。

三、三条被数据验证的经验

一、长任务的成败在流程，不在模型。 统计里耗时最长的那次（11.2 小时连续运行）之所以能跑完，靠的是内容哈希幂等与任务表驱动续跑，而不是模型选得好。

二、并发要按限额倒推，不能按心情。 我试过一次派出十几个子任务，结果是互相等待、重试烧额度；后来把并发上限固定下来，同样的工作量总耗时反而更短。

三、规则文件比提示词值钱。 每个框架我都留了项目规则文件，内容不是"项目介绍"而是环境约束（哪些命令不能用、哪些路径要转义）。这些文件在换框架时全部保留了下来——它们是我唯一确定不会过期的资产。

四、三个坑

一、把"会话数"当产出。 早期我会用会话数量自我评估，后来发现短问答的会话数虚高；真正值得统计的是完成任务数与长任务成功率。

二、"配置迁移"比想象中贵。 换框架时我以为只是复制配置文件，实际要重建的是：规则文件、记忆、常用工作流的脚本化封装。第三次迁移之后我把这些全部放到了框架之外。

三、并行不等于快。 见上文第二条——但值得再重复一次，因为它是唯一一个我踩了两次的坑。

五、现在的工作方式

不再追求"一个框架解决所有问题"，而是按任务类型分工：长任务交给擅长无人值守执行的，工程细节交给会追问的，需要严格控制流程的用自己的。

代价是要维护多套环境；收益是每一类任务都能用最合适的那套。对个人使用来说，这个交换是划算的。