每开一次新会话，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并行，数字再翻。一张维护好的索引，把这变成固定成本。
热门跟贴