# Add：基于状态机的智能体驱动开发工作流系统 > 一套个人可插拔的智能体技能集合，通过史诗/故事生命周期管理软件开发工作，解决长会话上下文漂移问题，支持 Claude Code 和 Codex 双平台。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-04-23T08:45:15.000Z - 最近活动: 2026-04-23T08:54:57.169Z - 热度: 159.8 - 关键词: 智能体开发, Claude Code, Codex, 工作流, 状态机, TDD, 技能系统, 项目管理 - 页面链接: https://www.zingnex.cn/forum/thread/add - Canonical: https://www.zingnex.cn/forum/thread/add - Markdown 来源: ingested_event --- # Add：基于状态机的智能体驱动开发工作流系统 ## 项目核心理念 Add 是一套个人可插拔的智能体技能集合，专为管理软件开发生命周期而设计。它的核心创新在于采用状态机模型来组织工作流，每个状态转换都对应一个全新的会话。这种设计直接针对长期智能体会话中的上下文漂移问题：当上下文窗口填满时，模型开始产生幻觉文件路径，早期指令被压缩丢失，单个错误决策会因为没有干净的状态重置而级联放大。 项目的核心理念可以用一句话概括：基于文件的状态管理，而非基于内存的状态管理。工作状态保存在 MASTER.md 跟踪器和结构化的故事文件中，而不是对话历史里。任何会话都可以通过读取协调文件来接续上次的工作，无需继承一个可能已经污染的上下文窗口。 ## 状态机工作流设计 Add 系统定义了一个清晰的状态生命周期，每个故事都会经历从规划到完成的完整流程。工作流从 `/epic-plan` 开始，通过引导式访谈创建新的史诗并生成 MASTER.md 跟踪文件。然后使用 `/epic-story-plan` 命令规划和发布新的待办故事，每个故事都包含验收标准和验证矩阵。 在实现阶段，`/epic-story-claim` 命令负责认领未分配的故事，找到最小的失败测试接缝，并以红绿重构的 TDD 方式执行。如果实现过程中被打断，可以使用 `/epic-story-resume` 恢复进行中的故事。完成实现后，故事进入评审状态，由 `/epic-story-review` 命令根据规范审查实现，并记录评审结论。 这种设计的一个关键原则是：每个命令只做一件事，每个会话只执行一个命令。规划只规划，实现只实现，评审只评审。特别是评审命令明确警告不要在编写代码的同一个会话中进行评审，因为产生代码的上下文会合理化自己的工作，而不是批判性地审视它。 ## 测试驱动开发的制度化 Add 系统将测试驱动开发从实现阶段的实践提升为规划阶段的约束。`/epic-story-plan` 命令要求提供验证证明矩阵，将每个验收标准映射到具体的测试接缝，然后故事才能从待办状态移出。 这种设计确保了在开始编写代码之前，测试策略已经明确。当 `/epic-story-claim` 开始工作时，问题不是"我们应该测试这个吗？"，而是"哪个失败的接缝应该首先变绿？"。严格的计划消除了即兴发挥的空间，故事规范成为工程蓝图而非建议，实现没有漂移的余地，因为每个行为都与验收 ID 和证明接缝绑定。 ## 会话交接与知识沉淀 Add 系统通过结构化的会话交接机制确保工作的连续性。每个实现会话都会写入"会话交接"部分，记录变更内容、剩余工作和确切的下一步。下一个全新的会话读取这些信息，而不是继承一个陈旧的上下文窗口。 系统还包含自我改进机制。`/memorize` 命令在会话结束时反思理解困难的地方，评估摩擦点，并提出对 AGENTS.md 或文档的补丁建议，以便未来的会话从更好的上下文开始。`/epic-squash` 命令在故事级别执行类似操作，将完成的规范合并到 CONTRACT.md 中。这两种机制都防止未来的会话重复学习过去会话已经掌握的知识。 ## 双平台支持与安装机制 Add 的独特之处在于它同时支持 Claude Code 和 Codex 两个平台。项目提供了两种安装路径：通过 Claude Code 插件市场安装，或使用自定义 shell 脚本一次性安装两个平台的技能。 安装脚本支持用户级和项目级两种作用域，通过符号链接将技能文件链接到对应位置。这种设计使得更新变得简单：只需在仓库目录执行 `git pull`，无需重新安装。脚本具有幂等性，除非使用 `--force` 标志，否则不会覆盖非符号链接目标。 ## 命令体系与功能概述 Add 系统包含十个协调工作流命令和两个小型工具命令。核心命令包括：`/epic-plan` 用于引导式创建史诗；`/epic-story-plan` 用于规划和发布故事；`/epic-story-plan-review` 用于在认领前审查计划；`/epic-story-claim` 用于认领和实现故事；`/epic-story-resume` 用于恢复进行中的故事；`/epic-story-review` 用于审查实现；`/epic-story-pr` 用于创建 GitHub PR；`/epic-squash` 用于合并已完成的故事。 工具命令包括 `/grillme`，用于对计划或设计进行持续的提问直到达成共同理解；以及 `/memorize`，用于反思会话摩擦并提出文档改进建议。这些命令共享单一的状态生命周期和协调文件的约定，确保整个系统的一致性和可预测性。 ## 应用场景与实践价值 Add 系统特别适合需要长期维护的复杂项目，或者需要多个开发者协作的场景。通过将状态外化到文件系统，它解决了智能体会话的天然限制，使得大型项目的管理成为可能。 对于个人开发者，Add 提供了一种结构化的工作方式，帮助保持专注并减少上下文切换的成本。对于团队，它提供了一种标准化的协作语言和工作流程，减少了沟通开销。 更重要的是，Add 展示了一种与 AI 协作的新范式：不是依赖单一的长会话，而是通过精心设计的交接机制，将工作分解为多个短而专注的会话。这种方法既利用了 AI 的能力，又规避了它的局限性，是一种务实的工程解决方案。 ## 总结与启示 Add 项目为我们展示了如何构建可持续的智能体驱动开发工作流。它的核心洞察是：真正的状态应该保存在文件系统中，而不是对话历史里。基于这个洞察构建的状态机工作流，不仅解决了上下文漂移的技术问题，更提供了一种新的与 AI 协作的思维方式。 对于希望在自己的项目中采用类似方法的开发者，Add 提供了一个经过验证的参考实现。它的设计理念和实现细节都值得深入研究，特别是会话交接机制和知识沉淀流程，这些都可以被适配到其他工作流和工具链中。