给 agent 地图，别给代码

当开发者在大型代码库里开启一个会话、给 agent 一个任务时，第一个问题是开局往 context 里放什么。我的答案是：放地图，不放代码——文件只有在 agent 导航到它时才进来。

context 问题，本质上是 monolith（单体）的问题。

如果代码库是微服务，基本没什么要解决的。一个服务就那么大，整个服务塞得进窗口，agent 直接读完就行。单体永远塞不下——而且往 context 里塞得越多，agent 不会越聪明，只会越慢、越贵、越容易分心。

所以面对单体，我不预加载代码。我给 agent 一张地图。

我自己的系统里，检索靠两个结构，没有 embeddings。第一是树：按目录组织的索引，就是文件在磁盘上实际的样子。第二是链接：条目之间双向互相指，就像 wiki 那样。agent 从地图出发，自己走。

代码也有同样的两个形状。目录树，以及代码内部的连接——谁调用谁，什么实现了什么。

第二个形状是大家总想重新发明的那个，而 IDE 几十年前就解决了。跳到定义。查找调用方。跳过去，看一眼，跳回来。这些是导航操作，是给人配着快捷键用的。把同样的操作做成工具给 agent，它就能像开发者一样在代码库里导航。

会话开始时进 context 的是地图，不是领土本身。一个文件只有在 agent 导航到它的时候才进来。其余的一律留在外面——这是刻意的。留什么在外面，是设计的大头。

窗口还是会满的。这两年大家收敛到了同一步：把前面的对话压缩成摘要，从摘要继续。我的访客会话按设计就短，所以我的难点不在这里。难的不是压缩本身，而是知道压缩之后 agent 的行为还对不对——那是一个 eval 问题，靠对着检查反复跑来回答，永远不是读一遍记录点点头。

context 不是一个要填满的桶。它是一个 agent 应该能在里面找到东西的地方。