上周我读到了一则新闻：一款 AI 设计出了一种疫苗，能对抗我们甚至还未曾遇到过的冠状病毒（科学日报）。剑桥大学进行了首次人体试验，39 名志愿者接种了抗原。
想想看，一个算法分析了一种病毒的整个基因家族，并为那些仍在动物间传播、伺机感染人类的病毒株设计了防护措施，这简直不可思议。但当我让它从一堆文档中提取我最新的简报时，它却可能花上近两分钟的时间，在我的资料库中打开错误的文件，最终却只给我看三个月前的一份简报。
我知道剑桥大学使用的是经过定制训练的 AI，但我想告诉你的是，AI 的能力与具体设置所能发挥的作用之间的差距，才是决定你工作流和生产力成败的关键。
我从未刻意地搭建过“脚手架”，直到最近才发现它的重要性。这层结构是随着文件夹的堆积，不知不觉地围绕在 Agent 周围形成的，直到它在我自己亲手制造的混乱中迷失了方向。
于是，我花了一天时间记录下每一次失败，并从中发现了一个规律。在这篇文章中，我会向你展示，为什么当全世界都称 AI 为天才时，你的 Agent 却在简单任务上屡屡绊倒；以及如何修复这个问题，让它真正为你所用。
本文要点：
- 文件夹结构让我的 Agent 寸步难行，因为我的文件夹是按我的思维方式组织的，而非 Agent 的导航方式
- 在每个主文件夹根目录放置一个索引文件，能将缓慢的搜索过程缩短到三十秒内阅读完
- Agent 周围那些无形的“脚手架”比 Agent 自身的能力更重要——本文将教你如何搭建它
- 一个只需五分钟的诊断测试，帮你判断文件夹结构是否才是真正的问题所在
Agent 无法理解的结构
我像大多数人一样组织我的资料库。文章、研究素材、资源、策略文档，它们各有各的文件夹。这种结构之所以感觉清晰，是因为我是按内容类型来思考的。文件夹映射着我的分类，我从不需费心去查找。草稿归文章，笔记归研究，归档系统自动运行。
但 Agent 并非按分类来思考。当我让 Hermes 规划一个产品发布时，任务需要从策略笔记、品牌指南和过往发布记录中提取信息，而这些文件散落在不同的文件夹里。
这些上下文信息在我的内容类型结构中分布在不同位置。我的 Agent 每次都必须到处搜索，却无法区分哪个草稿是最新的、哪个已被归档，或是哪个研究笔记是本月的、哪个是六个月前的。
按内容类型组织对人来说完美无缺。你一生都在按分类归档物品，你的大脑会自动进行交叉引用。自然地，你会期望 AI 也能如此运作。但实际上，Agent 必须手动进行这种交叉引用，而这正是结构失效的症结所在。
Agent 周围的结构比 Agent 自身的能力更重要。
一旦我发现了这个模式，原因就显而易见了：我为能够记住文件位置的人类大脑构建了资料库，然后把它交给了一个每次都需要从头搜索的 Agent，这恰恰暴露了文件夹混乱表象下的真正问题。
搜索者需要一张地图，因为没有地图，Agent 就像在黑暗中摸索，把每个文件都当作可能的答案。
能力在何处被浪费
Hermes 总是要打开一堆文件才能找到正确的那个，或者当当前文件在其他地方时，它却抓取了一个已归档的版本。更糟的是，本应能从上下文中显而易见的答案，它却会问该用哪个文件。这种情况在我使用的每个模型上都发生过，包括 Opus、GPT 5.5、Qwen 和 GLM。
这个模式反复出现，我眼睁睁地看着同样的缓慢搜索在一项又一项任务中重复上演。
尽管我的 Agent 有足够的能力找到东西，但在接触到实际工作之前，文件夹结构本身就成了主要的瓶颈。
在我记录失败的那天，我终于忍无可忍。我追踪了 Hermes 在找到正确文件之前打开了多少个文件，以及找到它花了多长时间。在我做出任何改变之前，五个常见任务的表现如下：
在我更改之前：
- 查找当前的文案简报：打开了 7 个文件，耗时 2 分钟才找到正确文件
- 查找品牌颜色定义：打开了 5 个文件，耗时 1 分 12 秒
- 查找文案队列以便规划：打开了 4 个文件，耗时 48 秒
- 查找关于同一主题的过往文案：打开了 6 个文件，耗时 1 分 36 秒
- 获取产品发布的推广策略：打开了 3 个文件，耗时 34 秒
这是个粗略的实验，所以请将具体数字视为方向性参考。
每项任务都需要跨越多个文件夹。大多数任务在找到当前版本之前，会先打开已归档的版本。我的 Agent 将能力浪费在了导航上，而不是执行任务上。一次产品发布计划需要三个文件，它们分别位于三个不同的文件夹中，我眼睁睁地看着它尝试了三次错误选择，才最终找对。
一个能写文章、能编码、能规划的 Agent，不应该把大部分时间花在找东西上。
最有效的“笼子”
每个事务一个文件夹，用数字排序，并在根目录放置一个 INDEX.md 映射所有内容。这就是全部的修复方法，细节体现在三条协同工作的规则中。
每个主文件夹根目录下的 INDEX.md 就是一张地图。它列出了所有子文件夹和规范文件，以及我的 Agent 应该从哪里开始。我的 Agent 会先读取这个文件，在触碰任何其他文件之前就知道里面有什么。你可以把它想象成一个软性的审批门，Agent 在知道自己要处理什么之前，不允许开始工作。
重组后，我的品牌文件夹结构如下所示：
105.Brand/2├── INDEX.md3├── 01.Brand System/4├── 02.Editorial Strategy/5├── 03.Promotion/6├── 04.Public Deliverables/7├── 05.Operating Plan/8└── 06.Archived/
这种结构是按“事务”而非“内容类型”来组织的。每个事务都有自己独立的文件夹，因此品牌工作与品牌工作在一起，策略工作与策略工作在一起。我的 Agent 不会跨界去寻找不属于那里的东西。
文件夹上的数字明确了读取顺序，而不是依赖字母排序。01. Brand System 会在 02. Editorial Strategy 之前被读取。我的 Agent 无需猜测。文件夹内部的数字对文件也起到同样的作用，所以 Agent 知道 01. Articles 是起点，而不是 02. Previous Articles。
我给文件夹名加上了数字前缀，因为这样对我也更容易记忆。
这就是我那套价值 30 美元的完整 Hermes 系统如何能在数十个文件夹中轻松移动，而我的 Agent 却从不迷路的原因。
归档内容放在 06.Archived 中，旧的简报和废弃的计划在那里等候。我的 Agent 知道，除非我特别要求查阅历史上下文，否则不会去那里。这种分离保证了活跃文件夹的整洁和搜索的快速。
一旦我的 Agent 被告知默认情况下不要跨越这个界限，活跃文件夹内的所有任务都运行得更快了。
我的 INDEX.md 看起来是这样的：
1# Brand Index23此文件夹包含当前的品牌体系。45## 文件夹映射67| 文件夹 | 用途 | 更新日期 |8|---|---|---:|9| `01.Brand System/` | 视觉识别、主题范围、语气 | 2026-06-11 |10| `02.Editorial Strategy/` | 文案方向、标题规则、队列 | 2026-06-11 |11| `03.Promotion/` | 发布、分发、工具策略 | 2026-06-11 |1213## 规范文件1415| 文件 | 用途 |16|---|---|17| `01.Brand System/01. Brand System.md` | 视觉识别、颜色、排版 |18| `02.Editorial Strategy/01. Articles.md` | 文案队列、标题规则 |1920## 入手点2122- 从 `01.Brand System/04. Direction.md` 开始了解使命23- 使用 `02.Editorial Strategy/01. Articles.md` 选择文章
INDEX.md 经历了三个版本。我的第一个版本列出了品牌文件夹内的每一个文件，长达四十行。它在技术上是完整的，但我的 Agent 每次都必须解析它，冗长本身也成了一种开销。我的第二个版本太短了，大概十五行，结果我的 Agent 还是问了一些我尚未回答的问题。第三个版本只列出了子文件夹和规范文件，并带有一个简短的“入手点”部分，告诉 Agent 从哪里开始。
当我让 Agent 为一个产品发布获取推广策略时，它会读取 05.Brand/INDEX.md，打开 03.Promotion/01. Promotion Strategy.md，然后开始工作。重组后的耗时如下：
重组之后：
- 查找当前的文案简报：打开 1 个文件，耗时 10 秒
- 查找品牌颜色定义：打开 3 个文件，耗时 22 秒
- 查找文案队列以便规划：打开 1 个文件，耗时 10 秒
- 查找关于同一主题的过往文案：打开 2 个文件，耗时 18 秒
- 获取产品发布的推广策略：打开 1 个文件，耗时 12 秒
最慢的任务从 2 分钟降到了 26 秒，最快的任务则在 10 秒左右完成。我的 Agent 打开 INDEX.md，按照所需的起点操作，然后直接开始工作，无需盲目摸索。Agent 自身的能力没有任何改变。文件夹结构在任务开始之前，就阻止了大部分能力的浪费。
文件夹结构是我搭建的一个“笼子”，它约束了 Agent 的行动方式，却不限制它所能做的事。在“笼子”里，Agent 可以自由驰骋。没有它，Hermes 就倾向于四处游荡，我还得花时间把它指向正确的文件。
迁移到 Hermes 使我能够同时在文件、供应商和记忆之间构建这种系统。而 INDEX.md 模式是其中最小但最能带来日常巨大改变的一环。
每个“笼子”都有一把锁
我犯的第一个错误是给每个子文件夹都加了 INDEX.md。地图太多意味着 Agent 把时间都花在阅读索引上，而不是实际工作。我只在主文件夹的根目录下放置 INDEX.md，比如“品牌”和“编辑策略”这类有足够多子文件夹需要指引的地方。在只有四五个文件的小子文件夹里，Hermes 无需任何地图就能直接导航。
请记住，当你添加新文件夹时，编号会变得繁琐。我必须决定新文件夹在序列中的位置，有时我会直接把它追加到最后，而不是重新编号所有内容。这完全没问题。只要数字能指示方向，就不必追求完美。目标并非打造完美排序的文件夹，否则，一个实用的解决方案就变成了一个纯粹的“美化工程”。
一个更大的错误是在 Agent 表现出任何困惑之前就构建结构。大多数人会过度设计他们的 Agent 环境，因为他们认为需要完备的基础设施。
我当前的规则，与选择 MCP 还是 CLI 抑或是自建工具背后的原则相同：使用能完成工作的最小界面。只在 Agent 迷路时才添加结构，并且只添加足够解决特定问题的结构。
我遇到的另一个失败是结构中的嵌套结构。我在子文件夹下又添加子文件夹，试图让一切完美分类，结果把两级层次结构变成了五级。我的 Agent 为了找到一个文件，不得不读取多个 INDEX 文件和解析多个编号序列。我把这些多余的层级合并回扁平的子文件夹，导航速度就又快了。
层级深度是快速文件查找的敌人，而大多数重组都在增加深度，误以为这就是精确性。
重组之前先衡量
在碰任何一个文件夹之前，先对你 Agent 处理最频繁的三个真实任务运行这个测试。计算每个任务的时间，并记录它在找到正确文件之前打开了多少个文件。追踪它选错文件或停下来问你该用哪个文件的频率。
任何任务，如果你的 Agent 耗时超过 30 秒，或者打开了 3 个或更多错误文件，都表明该任务背后的某个文件夹出了问题。
选择最常发生的那一个失败任务。打开那个文件夹，编写一个 INDEX.md，列出所有子文件夹和重要文件，以及你的 Agent 应该从哪里开始。保存它。再次运行同样的任务。
如果你的 Agent 在 30 秒内找到了正确的文件，那么修复就起作用了，你现在已经掌握了这个模式。将其应用到下一个有问题的文件夹。如果它仍然失败，问题很可能出在编号或“一个文件夹一个事务”原则上，接下来就是修复这两点。
从那个最浪费时间的文件夹开始，修复它，然后在你准备好的时候再移向下一个。
仍有弯曲的栅栏
有时，为了获取背景信息，我仍然需要查阅归档内容，比如一份旧的简报。我的 Agent 必须知道要去 06.Archived 查找，而不是在活跃文件夹里寻找。我在 INDEX.md 中提到了这一点，以便它知道历史资料存在哪里。没有这个提示，我的 Agent 会认为归档内容不存在。
另外，当 Obsidian Sync 未能干净利落地跨设备同步时，偶尔也会产生问题。如果我在笔记本电脑上更新了一个文件，但旧版本仍然留存在我的 VPS 上，Hermes 就会加载 VPS 上的副本，并将其视为当前的真实来源。这更多是一个同步问题，而非文件夹结构问题，但它会暴露在文件夹系统中，因为 Agent 只看到它面前的文件。
当你拥有的文件夹数量多到序列变得毫无意义时，编号就失效了。当同一层级编号项目超过十个或十二个时，这些数字就开始变得随意了。
我尽量将主要类别保持在这个阈值以下，并将更深层次的结构放在内部，而不是扩展顶层。
重命名是另一个摩擦点。当我重组时，有时会为了更好匹配用途而重命名文件夹，而 INDEX.md 中任何对旧名称的引用都会失效，直到我更新它。我现在尝试一次性设置好文件夹名称，然后就不再改动，因为一个略有不妥的名称，也比一个失效的引用代价更小。
这种结构最适合内容密集型工作流和规划密集型工作流。纯代码或数据密集型环境可能需要完全不同的组织原则，INDEX.md 模式也并不能解决所有导航问题。
我在这篇文章中写的一切，都追溯到一个本能：掌控那个重要的层。我构建我的系统，使得没有公司能控制我的工具。我构建我的资料库，使得没有混乱能控制我的 Agent。同样的原则，从供应商到文件夹，再到未来的一切。
当围绕能力的“脚手架”破损时，能力本身也变得廉价。搭建好“脚手架”，能力自然会发挥出来。一个索引文件加上文件夹名前的一些数字，就是区分一个四处游荡的 Agent 和一个真正工作的 Agent 的关键。
如果这篇文章对你有用——欢迎关注 @wandermist 获取更多类似内容！
