RinDig/icm-architect

它解决的问题

多代理设置通常依赖编排代码来定义步骤、上下文和状态，这使得它们难以理解和调试。icm-architect 用简单的文件夹结构替代了这些代码：编号文件夹设定顺序，层级限制代理看到的上下文，markdown 文件保存状态。任何人都可以打开任意文件夹查看系统正在做什么，一个代理在正确的时间读取正确的文件就能完成多代理框架的工作。

工作原理

它有两种工作模式。构建模式提取你描述工作时已经隐含的结构（阶段、检查、稳定部分与每次运行部分），并创建承载该结构的最小工作区。重构模式审计现有文件夹，将每个文件分类为类型（目录、合同、工厂、产品、废弃），查找依赖关系，提出迁移方案供批准，然后迁移并验证。

每个工作区由三个原语构建：序列（编号步骤，每个输出馈送给下一个）、架子（同形状文件的文件夹）和目录（指向下方的小文件）。它们组合成五种形式：管道、记录库、知识包（包括从转录构建的，每个引用都对照来源验证）、上下文映射和系统映射。这些形式可以嵌套。

每个步骤以检查结束（人、脚本或小模型），以便错误在放大之前被捕获。最终验证是行走测试：一个没有记忆的代理必须仅从文件就能定位、行动并报告状态。工作区是普通文件夹和 markdown，以 AGENTS.md 作为入口文件，并为期望不同文件名的代理添加一行指针。

适用人群

构建代理驱动工具和工作流的人，他们想要比编排代码更简单、更透明的替代方案。它适用于任何读取 SKILL.md 文件的代理，包括 Codex、Gemini CLI、Hermes Agent、Claude Code、Cursor 和 GitHub Copilot。它还帮助团队将现有仓库或知识库重构为代理友好、可解释的布局。

亮点

• 两种模式：从描述构建工作区，或通过审计和迁移重构现有文件夹。
• 基于三个原语和五种可嵌套的可复用形式，保持小工作区最小化。
• 每个步骤以检查结束，完成的工作区通过“行走测试”确保新代理可以导航。
• 供应商中立：普通文件夹和 markdown，使用 AGENTS.md，并为期望其他名称的代理提供指针。
• 可选的 Python 脚本检查链接和输入路径，绘制工作区图，生成索引，并验证引用与来源。