手写 loop vs LangGraph：一场差点误诊的对照实验

实验前提：两套实现共用同一份 prompt（prompt.ts）、同一个检索后端（tools.ts 的 MCP）、同一个裁判（judge.ts）。唯一的变量是「谁来驱动模型循环」——手写的 while vs LangGraph 的图引擎。

实验设置

轮次	状态	LangGraph 调用	手写调用	token 差异	延迟差异
1	流程未对齐	8	10	+46.1%	−3.4%（手写快）
2	改手写版	8	10	+90.3%	+64.9%（手写慢）
3	流程已对齐	6	11	+39.3%	−4.5%（手写快）

第 3 轮（当前状态，流程对齐后）：

指标	LangGraph	手写 loop	差异
模型调用次数	6	11	手写多 5 次
token 消耗	31,518	43,890	手写多 39.3%
辩手延迟	94.2s	89.9s	手写快 4.5%
端到端墙钟	160.0s	148.6s	手写快 7.1%
客套命中率	0 / 4	0 / 4	持平

原始数据：runs/compare_*.json

三轮实验里，只有调用次数的差距是稳定的（8/10 → 8/10 → 6/11）。 token 百分比在 +46% ~ +90% 之间大幅波动，延迟甚至两次反转（快3.4% → 慢64.9% → 快4.5%）。

这说明单次实验的百分比全部在噪声范围内。 而调用次数是整数、可复现的，才是可信信号。

差异来源查清了：LangGraph 那边 createAgent 收敛得更好—— 6 次调用完成了「取证 + 4 轮发言」，而手写版用了 11 次。我的工具描述里写了"建议 2-3 次"，反而暗示模型多调几次；框架那边只说"检索支持本方立场的事实"，模型一次就收手。

这个差异是 prompt 措辞造成的，不是 loop 机制造成的。 下次要测公平，得把这个变量也固定住。

手写版快 4.5%（墙钟快 7.1%），但它在多调 5 次的情况下还更快—— 这不符合常理（多 5 次网络往返应该更慢），说明差异来自网络抖动而非机制。

所以"手写比框架快"这个结论不成立。 3~7% 完全被单次请求的波动盖住了。真要测延迟，得跑 10 次以上取 p50/p95。

三轮实验，裁判评分在正方 19.5~~22.5、反方 18.5~~25.2 之间浮动， 但两版在同一场里的评分始终接近。发言质量也不因实现而异：

质量来自 prompt 和反谄媚机制，不来自 loop 框架。 想提升辩论质量该改 prompt。

第一轮我把 46% 的 token 差距诊断成"maxSteps 太宽松 + 上下文裁剪粗糙"，改完差距反而扩大到 90%。数据揭示真相：两版的准备阶段流程压根不一样—— 手写版拆成三步 LLM 调用，框架版一次 createAgent 走完。

测出来的差异是流程差异，不是框架差异。

教训：做 A/B 对照时，流程必须先对齐，再谈机制。否则你测出来的任何数字，都可能只是在测你两边写得不一样而已。

本次实验没有得出"谁更快更便宜"的结论，因为变量还没完全控制住。但得出了两个更重要的判断：

场景	建议
本项目（同步、短流程、崩了重跑不心疼）	手写。性能差距不构成理由，可解释性才是
跨进程/跨天任务	LangGraph。checkpoint 能力手写要几个月
中途需要人工审批	LangGraph。断点续跑是刚需
要跑百万次的编排	LangGraph。并发一致性自己扛不住

不是为了省 token，是这三件事手写之后才真正属于你：

上下文裁剪策略可以自己定。框架给的是通用摘要，但我们知道辩论该保什么（自己的立场 + 对手最近说了什么），可以写针对性更强的策略
中间件的边界自己划。反谄媚的锚点注入在 wrapModelCall 里做是一行，在框架里要理解它的钩子生命周期才能放对位置
调试时知道去哪看。框架把 loop 藏进图里，出问题时你得先反推图的结构（见 docs/agent-harness-research.md 第二节的源码位置）