Claude团队发现：AI每次开工先交47%探索税

每开一次新会话，Claude重新读一遍同样的文件，Codex重新发现一遍同样的插件模式，Gemini重新问一遍同样的文件夹结构问题。

模型没变慢，是它们在从零开始。

这不是算力问题，是记忆问题。作者给出的解法很直接：给AI一张常驻地图，而不是每次让它们自己探路。

多Agent的隐形成本：探索税

一个多Agent工作流里，每个Agent每次启动都要交一笔"探索税"。动手干活之前，它得先搞清楚：插件系统在哪？命名规范是什么？哪些文件被subtree管理不能碰？之前已经做了哪些决定？

小项目里这只是烦人。大项目，或者多个Agent并行跑的时候，这就是token的坟场。

常规解法是写个CLAUDE.md或AGENTS.md，用文字描述代码库。有用，但有限。文字是被动的——Agent读完还得自己映射到具体文件。这是README，不是地图。

文档解释，索引定位。

作者想要的是这种开场白："公开函数放scripts/plugins/，不带下划线前缀。scripts/k3d-manager里的调度器懒加载它们。这是现有插件和它们的公开函数列表。"

可直接导航。Agent读完直奔目标文件，带着正确模式，零探索。

Cline的另类用法：专职侦察兵

作者用Cline做这件事。Cline有持久记忆，能跨会话维持对代码库的结构化理解。不把它当代码生成器，而是专职侦察Agent——只负责读仓库、建结构化地图、保持更新。

其他Agent消费这张地图。它们不再重复探索。

这相当于给团队配了个永不遗忘的架构师，专门画地图。其他AI是施工队，进场先看地图，直接开工。

三层索引：结构、契约、状态

作者定义了有用的代码库索引该长什么样，分三层。

第一层：结构——东西在哪，为什么在这

``` scripts/ k3d-manager # 调度器——把函数名映射到插件文件 lib/ # 核心库；通过lib-foundation做subtree管理 plugins/ # 懒加载模块；一个工具一个文件 tests/ # BATS测试套件；纯逻辑，不mock集群 ```

不是罗列文件，是标注意图。k3d-manager是调度器，lib/是subtree托管的，plugins/是懒加载的。Agent一看就知道该找谁、不该碰谁。

第二层：契约——Agent必须遵守的规则，编码为事实而非建议

``` - 新插件：scripts/plugins/.sh - 公开函数：不带下划线前缀 - 私有函数：_前缀 - 特权命令：_run_command --prefer-sudo，禁止裸sudo - if-count限制：每函数≤8个；例外见etc/agent/if-count-allowlist - Subtree管理区：scripts/lib/foundation/——只改上游 ```

不是"我们建议"，是"事实如此"。新插件必须放这，公开函数必须长这样，特权命令必须这么调。Agent不用猜，不用试探边界。

第三层：状态——进行中的、已决定的、被阻塞的

``` 活跃分支：k3d-manager-v0.9.17 当前任务：_antigravity_ensure_acg_session 阻塞项：lib-foundation v0.3.14（5个修复待合并） ```

这是Agent自己读代码读不出来的。哪个分支在跑，当前卡在谁身上，为什么卡着。避免三个Agent同时去修同一个阻塞点，或者重复问"这个版本能用吗"。

从"更聪明"到"更省"

作者的核心判断：缺失的部件不是更聪明的模型，是常驻索引。

这有点反直觉。行业惯性是堆模型能力——更大的上下文窗口、更强的推理、更长的记忆。但作者指向另一个方向：工程化。用结构化的信息组织，减少每次会话的重复劳动。

类比一下：不是给工人更好的锤子，是给工人一张不会丢的施工图。锤子再好，每次开工先花半小时重新测量，都是浪费。

Cline在这里的角色也很有意思。它本身是个AI编程助手，但作者把它降级（或升级）为基础设施——不做生成，只做索引。这种"AI管理AI"的分层设计，可能是多Agent系统的关键模式。

一个Agent专门处理信息熵，其他Agent专注任务执行。分工明确，成本可控。

作者没提具体省了多少钱，但算笔粗账：如果一个中等代码库每次会话需要2000 token做探索，一天10个会话，一年就是730万token。多个Agent并行，数字再翻。一张维护好的索引，把这变成固定成本。