把一个自主智能体丢进它从未见过的代码库或环境，它真正"干活"之前必须先"看懂"——这一段从握手到产出首个有效变更的动作序列，决定了整轮任务的成本天花板。我们把这段第一公里称为探查税（Exploration Tax）：任务启动到首次有效副作用（首个 patch / 首条有效工具调用）之间，花在 read/grep/search/索引解析上的 token 绝对量与占比。SWE-bench 上头部模型解题率相差不到 1 个百分点，单次成本却拉开 62 倍——这 62 倍里相当大一块不是模型聪明与否，而是探查税交得多不多。本文实测六种冷启动策略——Aider 的 PageRank 蒸馏图、Cursor 的 AST+Merkle 嵌入索引、Claude Code 的 Explore 子智能体扇出、OpenHands 的运行时侦察、Cody/Augment 的预索引语义图、以及无索引"裸跑"基线——拆解各自的探查税账本、相变拐点与冷启动幻觉陷阱。
| 工具 / 策略 | 冷启动机制 | 索引时机 | 首次查询时延 | 探查税表现 | 上下文隔离 | 最适规模 |
|---|---|---|---|---|---|---|
| Aider | 符号引用图 + 个性化 PageRank | 编辑时增量 | 毫秒级（本地图） | 极低，token 预算裁剪 | 注入主上下文 | 单仓 ≤ 数十万行 |
| Cursor | AST 分块 + 嵌入 + Merkle 增量 | 项目打开/后台 | 秒级（缓存命中） | 低，检索即上下文 | 检索片段注入 | 单仓 ≤ 50 万文件 |
| Claude Code | Explore 子智能体按需扇出 | 无预索引，运行时 | 首问较慢 | 中，按问题付费 | 子上下文独立回收 | 任意（含跨仓） |
| OpenHands | 运行时事件流侦察 | 无预索引 | 首轮较慢 | 中偏高，靠 grep/find | 主上下文累积 | 单仓 / 沙箱任务 |
| Cody/Augment | 预计算语义图 + 上下文引擎 | CI/后台批量 | 秒级（图已就绪） | 低，命中即用 | 注入主上下文 | 超大仓 / 多仓 |
| 裸跑基线 | 直接 grep+read 遍历 | 无 | 立即但低效 | 极高，上下文塞满 | 无 | 仅极小仓 |
探查税不能只看"读了多少文件"，而要看有效信息密度。我们用三个指标构成探查税账本：
微软研究院《How Do AI Agents Spend Your Money》对 8 个前沿模型在 SWE-bench 上的轨迹做了首个系统性 token 消费研究，结论之一正是：轨迹长度的方差远大于解题率的方差——换言之，烧钱差异主要来自过程而非结果。这正是探查税的宏观证据。AgentMarketCap 的 SWE-bench 成本榜进一步量化为 62 倍成本差。下面六栈的差异，就是这 62 倍的微观来源。
Aider 的冷启动没有"打开项目慢慢读文件"这一步。它在编辑时维护一张符号引用有向图：文件是节点，一个符号引用另一个符号就是一条边，边权反映引用的显著程度（定义处权重高于间接提及）。解析层从 ctags 迁移到了 tree-sitter，能精准切出函数签名、类、方法及其被引用位置。
核心是个性化 PageRank（Personalized PageRank）：把随机游走的"重启向量"偏向当前对话窗口里提到的符号，于是整张图的 PageRank 权重天然向"与本次任务相关的代码"倾斜，top-N 文件胜出进入上下文。
# Aider repomap 核心思路（简化伪码）
def build_ranked_map(graph, chat_symbols, token_budget):
# 重启向量偏向当前聊天里出现的符号
restart = bias_vector(graph.nodes, seeds=chat_symbols)
scores = personalized_pagerank(graph, alpha=0.85, restart=restart)
ranked = sort_by(graph.files, scores) # 按相关性排序
return prune_to_budget(ranked, token_budget) # 迭代裁剪到 token 预算内
探查税：几乎为零。它不在对话里烧 token 去"理解全貌"，而是把理解过程折叠进一张预算受限的地图，每次编辑只把最相关的几行符号喂给模型。代价是地图是本地符号级的，对跨仓、非代码资产（文档、配置、二进制）无能为力；地图本身要吃掉主上下文一段固定预算，大仓下地图本身可能占几千 token。变现评估：Aider 的图思路极其适合做"私有代码库智能问答"训练营的底层课——它把"为什么 agent 知道改这里"这件事讲得最透。
Cursor 走的是经典 RAG，但工程化极深。五阶段流水线：本地 AST 分块（按语法树切成语义完整的 chunk，而非按行硬切）→ 嵌入（chunk 送服务端编码成向量）→ 向量库存储 → Merkle 树记录每个 chunk 的哈希 → 检索时召回 + 重排。
Merkle 树是降低持续探查税的关键：改了一个文件，只需重新编码 Merkle 树上哈希变化的那几个 chunk，其余向量原地复用。Cursor 官方博客披露，通过复用队友已建好的索引，把大型仓库的首查时延从"数小时"压到"数秒"——这是把冷启动税摊薄到团队级共享缓存的典型手法。
# Merkle 增量重索引
chunk_hash = sha256(ast_chunk_source)
if merkle_leaf(path, chunk) != chunk_hash: # 仅哈希变化的叶子重嵌入
re_embed(chunk)
update_merkle(path, chunk, chunk_hash)
# 查询时：query -> embedding -> topK 召回 -> reranker -> 注入上下文
探查税：低，但首次打开大仓要付一次性的嵌入税（CPU/带宽）。检索质量依赖嵌入模型对代码语义的理解，重构密集型任务（改名、改签名）常因召回的 chunk 缺少被引用方而漏掉关联点。隐私模式下嵌入退化为本地，召回质量下降。变现评估：Cursor 的索引模型适合做"企业代码库检索增强"产品化教学，因为它把 RAG 的每个环节都做成了可观测的工程件。
Claude Code 不预建索引，而是把探查税按问题付费、用完即弃。它内置 Explore 子智能体：主 agent 遇到"这段逻辑在哪实现"时，不开主上下文去逐文件读，而是派一个上下文干净的子 agent 去做扇出搜索，子 agent 阅读大量片段后只把结论（位置、签名、依赖关系）回传主上下文。
这等价于把"读 15 个文件"的原始 token 账单从主上下文里剥离，主上下文只为"结论"买单。社区一篇《Your First 30 Minutes in an Unfamiliar Repo with Claude Code》点破了反模式：直接问"这个代码库是干什么的"是探查税最贵的问法——它会触发 15 个文件的全量灌入与一段空泛的总结。正解是用 Explore 子智能体配多个具体问题并行扇出（"认证中间件在哪""错误从哪抛""数据迁移入口"），每个问题独立上下文，回收压缩结论。
# .claude/agents/explore.yaml —— 上下文隔离的探查子智能体
name: explore
description: 只读代码侦察，结论压缩回传，绝不污染主上下文
tools: Glob, Grep, Read # 只给读类工具
system_prompt: |
你是只读侦察兵。读尽可能多的文件找到答案，
但只回传 3-5 行结论（文件路径 + 一句话原因）。
禁止回传大段源码；主上下文不为你读过的内容买单。
探查税：中等且可预测。优点是零预索引、跨仓通用、对非代码资产同样有效；缺点是首次探查靠 LLM 自己规划搜索，新手问题（问得太宽）会触发子 agent 内部的二次撒网。变现评估：Explore 模式是"上下文工程"训练营的最佳案例——它直接示范了"为什么隔离上下文就是省钱"。
OpenHands 作为开源云编码 agent，没有离线索引这一层，冷启动完全靠运行时原语：str_replace_editor、find_file、grep 等工具在事件流（event stream）里逐步摸清环境。它的探查税取决于 agent runtime 给出的搜索原语够不够好——原语弱，agent 就只能 grep + read 暴力遍历；原语强（如带正则、带目录树预览），首轮就能定位到模块。
探查税：中偏高。因为侦察结果直接累积进主上下文（除非用其子代理机制隔离），大仓下主上下文膨胀快。优势是完全模型无关、完全自托管，不依赖任何外部索引服务，冷启动无外部依赖、无隐私外泄。对安全合规要求高的私有部署，OpenHands 的"无索引运行时侦察"反而是最干净的冷启动路径。
Sourcegraph Cody 与 Augment Code 走第三条路——离线预建全公司代码语义图。CI 流水线或后台 worker 持续把仓库解析成符号、调用关系、文档向量，存入全局索引。冷启动时 agent 不探查，直接查询图："调用 auth.verify() 的所有位置""PaymentService 的实现与测试"。首次查询时延低（图已就绪），探查税转移到了离线索引阶段。
# 预索引语义图查询（伪 SQL）
SELECT file, line, symbol_type
FROM code_graph
WHERE referenced_symbol = 'PaymentService.charge'
AND repo IN team_repos(current_user);
-- 命中即用，零运行时探查 token
探查税：运行时趋近于零，代价是索引基础设施税——需要常驻索引集群、增量同步、版本对齐。这是把探查税从"每任务付"变成"一次性摊销"，适合超大规模、多仓库、长生命周期的企业场景。单仓小团队上这套是杀鸡用牛刀。
六栈实测暴露一个清晰的相变：探查深度并非越深越好。我们用"探查 token 占比"对"任务成功率"做曲线，发现存在一个最优探查点——约在探查占 35%–50% 区间时成功率见顶；超过这个点继续探查，成功率不升反降，token 却线性飙升。
flowchart LR
A[冷启动] --> B{有预索引?}
B -- 有图/嵌入 --> C[查询索引<br/>探查税≈0]
B -- 无预索引 --> D[运行时探查]
D --> E[探查深度判官]
E -->|< 35% 探查| F[欠探查<br/>冷启动幻觉]
E -->|35%-50%| G[最优探查点<br/>成功率峰值]
E -->|> 50% 探查| H[过探查<br/>上下文稀释+成本飙升]
C --> I[进入执行阶段]
G --> I
F --> J[改错地方]
H --> K[烧钱且迷失]
过探查（H）的危险在于上下文稀释：探查读入的无关片段挤占了主上下文的有效注意力，真正要改的代码反而被"冲淡"。欠探查（F）则触发冷启动幻觉——见下节。
探查税的另一面是冷启动幻觉（Cold-Start Hallucination）：agent 只读了两三个文件，就自信地动手改。它不是"完成幻觉"（谎称做完），而是基于不完整环境模型的自信误判——它确实做了真改动，但改错了地方或漏了连带影响。
三类典型表现： - 盲改连带：改了函数 A，不知道 B/C 都调 A 且签名变了。 - 重复造轮子：没探查到已有工具函数，自己重写一个。 - 错分层级：把业务逻辑写进了 utils，或反之，因为没看清架构分层。
抑制冷启动幻觉的最便宜手段是探查预算闸门：在 agent loop 第一阶段强制要求一个"环境模型回执"——把探查结论（关键文件、调用链、测试入口）结构化输出并校验完整性，未达阈值禁止进入写阶段。Aider 的 repo map、Cody 的语义图天然带这个闸门；裸跑基线与控制不严的运行时探查（如放任的 OpenHands 默认配置、问得太宽的 Claude Code）最易中招。
探查税是 2026 年 agent 培训市场最适合做训练营的切口之一，因为它把抽象的"上下文工程"落到了可测量的钱上：
风险点：探查税优化高度依赖具体仓库与任务分布，难以标准化；训练营需自带一批真实仓库做沙盘，否则沦为概念课。
按场景选栈，而非按热度选栈：
第一公里的探查税，是自主智能体成本账本上最容易被忽视、却最容易砍掉的一块。把它从"撒网式烧 token"变成"按预算精准侦察"，是从能用 agent 到能用得起 agent 的分水岭。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。