CodeGraph 互动式 A/B 实测直接在主会话作答还是委派给 Explore 子代理【免费下载链接】codegraphPre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, CoPilot, and Hermes Agent — fewer tokens, fewer tool calls, 100% local项目地址: https://gitcode.com/GitHub_Trending/co0degr/codegraph本篇基于 CodeGraph 仓库中的实测报告 answer-directly-vs-explore-agent.md拆解一个对 Claude Code 用户很关键的问题当 agent 回答X 是怎么工作的这类结构性问题时在主会话中直接调用 CodeGraph 作答与把探索委派给一个一次性 Explore 子代理用子转录吸收文件读取、保持主上下文精简哪种方式更优读完本篇你将掌握互动式 A/B 实验的完整方法论为什么必须用 tmux 驱动 TUI 而不是claude -p、主会话上下文在 16 倍仓库规模下为何保持 ~50k 不变的预算机制explore输出的分层预算上限以及这条结论如何直接改写了 CodeGraph 下发给 agent 的指令文案。核心问题与结论先行报告要回答的问题非常具体直接在主会话用 CodeGraph 回答how does X work?会不会把主会话上下文撑爆Claude Code 是不是应该把这类探索委派给Explore 子代理子代理在独立转录里读文件主上下文因此保持精简更关键的是当仓库规模远超 Excalidraw 时结论会不会反转短答案是不会反转。有了 CodeGraph主会话上下文大致是规模不变的~50k——因为检索是定向的、explore的返回载荷有预算上限仓库大 16 倍它也不会膨胀。直接作答在每一个规模上都赢主上下文与委派路径相当甚至更精简、文件读取为 0、token 少约 28%。为卫生而委派的优势即使在大代码库上也只是边际性的。重要警示本报告的 token 数字未经复核2026-08-05 标记。该实验早于parse-run.mjs的result.usage修复commit04c0f8e其少 28% token很可能取自一个只报告最后一个回合用量的字段——详见 call-sequence-analysis.md 中的踩坑记录。该误差会低估回合数更多的那一臂因此如果委派臂跑得更长真实差距大于28%如果两臂回合数相近则数字大致正确。原始日志已丢失无法重新推导——token 数字应视为指示性而回合数、读取数、主上下文这些不依赖该字段的结论是可靠的。实验方法论为什么必须用互动式 TUI方法学细节决定了这份报告的可信度值得逐条拆解测试框架通过 itrun.shtmux驱动的互动式 Claude Code TUI而不是 headless 的claude -p。这一点至关重要headless 模式派生 0 个 Explore 子代理根本无法测量委派行为只有互动 TUI 能复现用户实际看到的行为。脚本头部注释写得很直白headless print-mode picks the general-purpose subagent, while real interactive sessions delegate to the Explore subagent (or drive codegraph from the main thread). Only the interactive TUI reproduces the behavior users actually see.两臂ArmsWITH MCP 配置里启用 CodeGraphWITHOUT 空 MCP 配置--strict-mcp-config。模型opus每臂 n 3。主线程与子代理的转录都被解析parse-session.mjsRead/Bash 次数在主线程 所有子代理之间求和。仓库Excalidraw643 文件中等规模与 VS Code约 10.7k 文件大规模——约为 Excalidraw 的16 倍。构建版本0.9.4。日期2026-05-24。指标定义主会话上下文指 TUI 上报的Context X/Y中主线程的值子代理上下文不计入billable tokens 逐回合 assistant 用量求和input output cache read cache creation。从源码看parse-session.mjs 的做法与报告完全对应它读取 Claude Code 写入~/.claude/projects/escaped-cwd/的 session JSONLtally()函数统计主转录中每个tool_use块子代理转录则从session/subagents/*.jsonl汇总——这正是reads/bash 在 main sub-agents 上求和的实现。sumTokens()按回合累加output_tokens、input_tokens cache_creation_input_tokens新鲜输入与cache_read_input_tokens最后以gen fresh作为 billable 近似值与报告逐回合求和的定义一致。itrun.sh本身也体现了互动式测量的工程细节它通过tmux send-keys输入 prompt 并做输入验证确认 prompt 前 24 个字符真的落进输入框再按内容稳定性而非 spinner 字符串判断 agent 完成——因为某些模型流式输出最终答案时不渲染任何忙碌指示符短阈值的中断判定会把答案截断。结果一Excalidraw643 文件中等规模问题How does Excalidraw render and update canvas elements?指标WITH codegraphWITHOUTExplore 子代理派生数0 / 0 / 00 / 1 / 13 次中 2 次委派主会话上下文51k / 49k / 50k~50k48k / 34k / 26k~36k总工具调用4 / 4 / 416 / 55 / 37Reads主子0 / 0 / 06 / 25 / 16billable tokens~127k~175k观察没有 CodeGraph 时Claude Code 在 3 次中的 2 次选择派生 Explore 子代理派生与否直接决定了主上下文落在 26k 还是 48k——委派路径的主上下文收益是真实存在的但代价是 16–55 次工具调用和 6–25 次文件读取。结果二VS Code约 10.7k 文件约为 Excalidraw 的 16 倍问题How does the extension host communicate with the main process?指标WITH codegraphWITHOUT主会话上下文47k / 43k / 50k~47k54k / 29k / 31k~38kExplore 子代理0 / 0 / 00 / 1 / 12/3 委派codegraph 调用~8search explore×2–3 context0Reads主子0 / 1 / 06 / 26 / 19billable tokens~126k~176k16 倍规模的仓库WITH 臂主上下文~47k与 Excalidraw~50k几乎一致。这正是本报告最重要的发现。为什么主上下文是规模不变的预算上限的定向检索报告的归因是codegraph 的explore返回载荷是**有预算上限budget-capped且检索是定向targeted**的——回答一个问题只拉入相关的流/区域不会因为仓库巨大就拉更多。因此 CodeGraph 让主会话上下文大致规模不变~50k。为卫生而委派的优势即使在大代码库上也只是边际性的——恰好与规模上会变得重要的预期相反。这个归因可以在源码中得到印证。tools.ts 中定义了ExploreOutputBudget——一个随项目规模自适应分层的输出预算Adaptive output budget forcodegraph_explore, scaled to project size小代码库获得更紧的总上限、更少的默认文件数、更小的单文件上限getExploreBudget(indexedFileCount)在每次explore调用时根据已索引文件数解析当前项目的预算maxOutputChars是总输出的硬上限候选文件按相关性排序后按比例分摊这个预算Split budget.maxOutputChars across ranked candidates in proportion to...。也就是说载荷大小由本次问题的答案面决定而不是由仓库大小决定——这就是~50k 主上下文在 643 文件与 10.7k 文件仓库上都不变的机制来源。报告还区分了两种主上下文精简路径Claude Code 自己也能做到不用 CodeGraph委派给 Explore 子代理主上下文 29–31k但代价是17–26 次文件读取和约 28% 更多的 token。CodeGraph 的方式更优一个有上限的定向载荷——不委派、0 次读取。Explore 子代理会用 codegraph——复现失败报告尝试复现一个流传的设想Explore 子代理在委派后自己也会用 codegraph既瘦主上下文、又低工作量。结果跨两个仓库共 6 次with-codegraph 运行Claude Code一次都没有委派——每次都直接在主会话作答。Explore 子代理路径只出现在WITHOUT臂因为那一臂的 MCP 配置里没有 codegraph子代理用的是 grep/read。结论在当前指令 codegraph 在场的前提下Claude Code 留在主会话——经 Explore 子代理瘦主上下文这个最佳情形实际并不会发生发生的是经有上限的 codegraph 瘦主上下文而且它更便宜。这个行为不是偶然而是被指令文案主动引导的。server-instructions.ts 中随 MCPinitialize下发的指令明确写着Codegraph 本身就是预建的搜索索引running your own grep read loop,or delegating the lookup to a separate file-reading sub-task/agent, repeats work codegraph already didand costs more for the same answer——即把查找委派给独立读文件的子任务会被视为重复劳动而被劝阻。instructions-template.ts 安装到 agent 指令文件中的## CodeGraph区块也强调用 MCP 工具或codegraph exploreCLI 直接作答并且其注释记录了测量依据强制委派场景下没有该区块时子代理只有约 1/9 的运行会真正加载并使用 codegraph。README 中Agent Tool Guidance一节进一步说明README 明确写道 CodeGraph only helps when querieddirectly, so its instructions steer agents to answer directly rather than delegate exploration to file-reading sub-agents — otherwise a sub-agent reads files regardless and CodeGraph becomes overhead.判决与对指令文案的改写直接用 codegraph 作答对 Claude Code 同样全胜——在每一个规模上。不需要按 agent 拆分统一的answer directly指令对 Claude Code和Codex / Cursor / opencode这些工具没有 Explore 子代理机制否则只能直接读文件都是正确的。这条结论直接驱动了 README 中## CodeGraph示例块的更新旧文案曾指示 agent NEVER直接调用codegraph_explore/ALWAYS派生一个 Explore 子代理——那正是把 Claude Code 引向更差的路径17–26 次读取、多 ~28% token。当前仓库中的指令文案answer directly、delegating the lookup to a separate file-reading sub-task/agent repeats work就是这次实验的产物。保留项Explore 子代理 codegraph 的组合为何暂不采纳报告诚实地列出了唯一反方向的可能性一个自己会用 codegraph的 Explore 子代理理论上能同时拿到瘦主上下文和低工作量。但报告给出三条不把它设为默认的理由answer directly 指令在实际中阻止了委派6 次运行 0 次委派该路径当前根本不会发生主上下文收益是边际性的~50k → ~30k两者都只占 1M 窗口的几个百分点它增加一轮子代理往返。因此结论是值得做未来的实验不值得设为默认。复现与延伸阅读本实验的原始日志已不可得见开头警示但仓库保留了完整的可复现工具链itrun.shitrun.sh repo-path label prompttmux 驱动互动式 Claude Code 会话要求 tmux 3.0、已登录的claudeCLI 与配好的 codegraph MCP输出目录由AGENT_EVAL_OUT控制默认/tmp/agent-eval。parse-session.mjsnode scripts/agent-eval/parse-session.mjs project-dir输出主/子线程工具调用统计、billable token 估算以及 explore 之后的充分性sufficiency与答案取材allocation分析。延伸阅读同目录下的对照报告共享同一方法论与result.usage踩坑记录call-sequence-analysis.md37 个 A/B 单元的调用序列分析量化了result.usage只报最后一回合的字段缺陷commit04c0f8e修复并给出读取得节省不转化为墙钟时间的归因。codegraph-ab-matrix.mdreadings 减少 75% 而墙钟仅 ~16% 的 A/B 矩阵总表。方法学上的三点经验对做类似 A/B 的人测量委派行为只能用互动 TUI。headless 模式不派生 Explore 子代理测出来的是另一个问题。指标定义必须跨主/子线程求和——否则子代理里的 25 次 Read 会直接从统计里消失本实验 WITHOUT 臂的主力成本全在子转录里。token 字段要先验证再使用。本实验的 ~28% 差距来自一个只报末回合的字段回合数、读取数这类计数型指标不受该缺陷影响应作为主要判决依据。仓库后续报告在 call-sequence-analysis.md 中把读逐回合 usage 求和而非result.usage固化为了方法论规则。【免费下载链接】codegraphPre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, CoPilot, and Hermes Agent — fewer tokens, fewer tool calls, 100% local项目地址: https://gitcode.com/GitHub_Trending/co0degr/codegraph创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
