ICM架构师 是做什么的？
构建这样的工作空间：让文件夹结构负责编排。一个智能体，在正确的时机读取正确的文件，就能取代多智能体框架——编号文件夹承载顺序，层级结构承载上下文范围，纯文本Markdown文件承载状态。人类可以打开任意文件夹，确切地看到系统处于什么状态，因为状态就是文件。
把工作空间想象成一个图书馆。路由文件是目录——小巧、稳定，指向一切，几乎不存储任何内容。内容存放在书架上（阶段文件夹、节点文件、参考材料）。一个图书管理员——一个模型——在大楼里走动，由问题决定走向哪个书架。没有人把整个图书馆复制到背包里；这就是所谓的“上下文填充”。目录是刻意保持小巧的。
方法：可解释上下文方法论（Van Clief & McDermott, arXiv:2603.16021, MIT许可）。
不变原则
每个ICM，无论其形式如何，都必须遵守这些原则。在构建或重构时，强制执行所有十条：
- 一个文件夹，一个职责。 每个文件夹执行单个步骤或承载单一类型的事物，并在其内部的某个文件中说明自己的目的。结构本身就是文档。
- 小而稳定的入口文件。 根目录下的
CLAUDE.md（或AGENTS.md）回答“我在哪里，所有东西在哪里，任务X去哪里”等问题——除此之外不做任何事。目标控制在〜60行以内。它负责路由；它从不承载内容。 - 编号编码顺序。 在顺序重要的地方使用
01_、02_……重命名文件夹即重新排序流水线——这正是重点所在。 - 每个文件夹级别的契约都是显式的。 每个工作文件夹内有一个
CONTEXT.md：它读取的内容（输入）、它执行的操作（过程）、它写入的内容（输出）、人类需要检查的内容。参见assets/templates/stage-CONTEXT.md。 - 工厂与产品分离。 参考材料（规则、语气、模式、模板——跨运行稳定）与工作制品（输出、草稿——每次运行都是新的）在结构上分开存放。工厂配置一次；产品是每次运行产生的输出。
- 每个输出都是一个编辑面。 中间输出是普通文件，人类可以打开、编辑并保存，然后下一步才能读取。在人类阅读完上一个输出之前，什么都不会向前推进。
- 只加载步骤所需的内容。 执行某个步骤的智能体读取其契约、其引用和其输入——而不是整个工作空间。每个步骤的Token消耗在2000–8000范围内是健康的。
- 纯文本，可链接，可查询。 Markdown + YAML前置元数据。链接（
[[wiki链接]]或相对路径）使其成为图结构；前置元数据标签使其可查询。每个事实只有一个归宿——链接优于副本。 - 文件系统就是状态机。 “状态”可以通过扫描输出文件夹中存在的内容推导出来。生成的索引（文件映射、日志）由脚本重建，绝不手动编辑。
- 通过复制来实例化。 新的工作单元 = 复制一个模板文件夹，而不是从空白页开始。模板保存在
_templates/或_system/文件夹中。
选择模式
- 从描述的过程、想法或问题构建 → 构建模式。
- 现有的文件夹、仓库或知识库需要ICM结构 → 重构模式。
构建模式
1. 从对话中提取结构。 结构已经存在于用户描述工作的方式中——不要强加形状，而是揭示他们的形状。询问（一次几个，不要全部同时问）：
- 工作的重复单元是什么？（一个片段、一个客户、一份报告、一个人、一个团队？）
- 请带我走一遍完整的工作流程，从开始到结束。你在哪里停下来、在继续之前检查某些东西？
- 每次运行中什么保持不变（语气、规则、品牌、模式） vs. 什么每次运行都是新的？
- “完成”是什么样的——什么制品会离开工作空间？
- 还有谁接触这个，他们需要什么才能在不问你的情况下找到？
他们的停顿成为阶段边界。他们的“我总是在X之前检查Y”成为人工关卡。他们的“它必须听起来像/遵循Z”成为工厂参考材料。
2. 选择形式。 阅读references/forms.md并选择：
| 形式 | 在什么情况下使用 |
|---|---|
| 流水线 | 相同的序列重复运行，每次运行产生一个可交付物 |
| 伞状结构 | 多个不同的流水线共享一个品牌/语气/参考层 |
| 记录库 | 单元是一个记录（人、客户、会话），会累积，而非一次运行 |
| 知识包 | 产品本身就是可导航的知识（大脑、维基、某物的模型） |
| 上下文地图 | 主题是一个组织——团队、流程、数据以及它们之间的链接 |
真实的工作空间会混合多种形式（记录库中的记录是小型知识包；流水线输出到记录库）。可以自由组合——不变原则在每个层级递归地保持不变。
3. 搭建能够承载工作的最小结构。 从assets/templates/复制启动器并填充它们。不要为还不存在的阶段、空的“杂项”桶或推测性的深度创建文件夹。三个真实的阶段胜过七个想象中的阶段。如果整个工作适合放在一个保存的提示中，请直接说明，不要构建工作空间。
4. 编写契约。 根CLAUDE.md（标识 + 路由表）、根CONTEXT.md（流水线或模式定义）、每个阶段/枢纽文件夹一个CONTEXT.md、如果需要按用户配置工厂则创建setup/questionnaire.md。输入指定为确切的文件路径，分为工作输入（本次运行）和参考输入（每次运行）。
5. 通过行走测试验证（见下文）。
重构模式
1. 在触碰之前先盘点。 列出目录树。对每个区域记录：它是什么、上次何时修改、哪些地方引用它。在这一轮中绝不删除或移动。
2. 找到隐藏的形式。 询问所有者（或推断并确认）：这里的重复单元是什么？工作从哪里进入、从哪里离开？混乱通常包含一个在没有骨架的情况下生长起来的真正流水线、库或地图——提取它，而不是替换它。就像面谈一个人一样面谈文件夹。
3. 将每个文件分类为五种角色之一：
- 目录 —— 标识/路由（成为或提供
CLAUDE.md/索引文件） - 契约 —— 描述步骤如何工作（成为
CONTEXT.md） - 工厂 —— 稳定的参考（ →
_shared/、_system/或references/） - 产品 —— 特定于运行的制品（ → 阶段
output/或记录文件夹） - 死亡 —— 过时的、重复的或被取代的（ → 建议
_archive/，绝不静默删除）
4. 在移动之前先提议。 呈现目标目录树和迁移映射（旧路径 → 新路径 → 角色）。获得批准。这是一种以人为关卡的方法中的人为关卡——请尊重它。
5. 迁移。 移动文件，编写入口文件和契约，去重以实现一个事实一个归宿（如果副本可能被引用，则在原副本位置留下一个链接）。将方法与实例分离：如果结构将在其他地方被重复使用，空白模板必须与这次填充的部署分开存放。
6. 通过行走测试验证。
行走测试
像没有记忆的智能体一样，从头开始走一遍任何ICM（新建或重构的）来验证：
- 打开根目录。你能在入口文件加上最多两次读取内回答“我在哪里”和“去哪里找当前任务”吗？
- 选择任意阶段/节点。它的契约是否指定了确切的输入路径、任务、输出和人类检查点？
- 能否仅通过扫描
output/文件夹中存在的内容（或节点前置元数据）来陈述流水线的状态？ - 是否有任何路由文件承载了内容负载？将负载移到书架上；留下一个指针。
- 是否有任何事实存储在两个地方？选择一个归宿；从另一个地方链接过来。
- Token检查：入口文件 + 一个契约 + 它的输入应该大致落在2k–8k个Token内。
如果某个步骤失败，修复结构——不是通过做更多解释，而是通过移动或拆分文件，直到行走测试通过。
护栏
- 不要过度结构化。 阶梯运行的顺序是：聊天 → 保存的提示/技能 → 文件夹 + 一个智能体。只有当下面的阶梯级确实已被自动化且重复时，才往上爬。为只做两次的事情建工作空间，那叫脚手架，不是架构。
- 知道ICM失效的领域。 实时多智能体协作、高并发多用户服务、以及自动化的流水线中分支确实需要框架代码。ICM适用于顺序执行、人工审核、可重复的工作——这是大多数知识工作，但不是全部。
- 实践中发现的反模式： 重复的入口文件发生漂移（从其中一个生成另一个，或者让一个成为指针）；模式文档强制使用实际文件已不再使用的名称（更新模式或更新文件——二选一）；手动编辑生成的索引；工作坊会议产生幻灯片而不是结构化数据（每次工作会话都应该以结构可以容纳的制品结束）；从上到下强加模式（一个团队抱怨只是发牢骚——同一个形状独立出现三次才是结构）。
参考资料
- references/core.md — 五个设计原则、五层上下文层级、命名约定、Token纪律。在编写契约或结构决策产生争议时阅读。
- references/forms.md — 五种形式的深入讲解：骨架树、关键步骤、失败模式。在构建模式的步骤2或重构模式的步骤2时阅读。
- assets/templates/ — 可复制的启动器：
CLAUDE.md、工作空间CONTEXT.md、阶段-CONTEXT.md、node.md、schema.md、questionnaire.md。