# AgenticWorkflow：从想法到代码的完整AI驱动开发工作流 > AgenticWorkflow是一个端到端的AI辅助开发框架，通过交互式规划阶段和自主执行阶段的结合，将粗糙的想法转化为可合并的代码。它采用独特的两阶段工作流：先通过/grill-me、/to-prd和/to-issues三个技能进行交互式规划，再通过Ralph循环实现自主执行。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-06-11T08:48:09.000Z - 最近活动: 2026-06-11T08:54:52.984Z - 热度: 154.9 - 关键词: AI辅助开发, Agentic Workflow, Claude Code, GitHub Copilot, 自动化工作流, 软件工程, TDD, Docker沙箱, GitHub Actions, 项目管理 - 页面链接: https://www.zingnex.cn/forum/thread/agenticworkflow-ai - Canonical: https://www.zingnex.cn/forum/thread/agenticworkflow-ai - Markdown 来源: ingested_event --- ## 原作者与来源 - 原作者/维护者：kimlundjohansen - 来源平台：github - 原始标题：AgenticWorkflow - 原始链接：https://github.com/kimlundjohansen/AgenticWorkflow - 来源发布时间/更新时间：2026-06-11T08:48:09Z ## 原作者与来源\n\n- 原作者/维护者：kimlundjohansen\n- 来源平台：GitHub\n- 原始标题：AgenticWorkflow\n- 原始链接：https://github.com/kimlundjohansen/AgenticWorkflow\n- 来源发布时间/更新时间：2026-06-11T08:48:09Z\n\n## 背景与动机\n\n在AI辅助编程工具日益普及的今天，开发者面临着一个新的挑战：如何有效地将AI代理集成到实际的软件开发流程中。传统的开发流程往往需要大量的人工干预和上下文切换，而纯粹的AI自动编码又缺乏足够的规划和质量控制。AgenticWorkflow项目正是为了解决这一矛盾而诞生的，它提出了一种将人类智慧的最佳部分与AI代理的自动化能力相结合的混合工作流。\n\n这个项目的核心理念是：人类应该专注于他们最擅长的事情——思考、规划和决策——而AI代理则负责执行那些需要大量重复性劳动的任务。通过明确划分这两个阶段，AgenticWorkflow试图在保持代码质量的同时，显著提高开发效率。\n\n## 项目架构概述\n\nAgenticWorkflow采用了一个精心设计的两阶段架构，分别对应软件开发的规划阶段和执行阶段。这种分离不是随意的，而是基于对AI辅助开发本质的深刻理解：规划需要人类的洞察力和判断力，而执行则更适合交给不知疲倦的AI代理。\n\n第一阶段是交互式规划阶段，开发者与AI助手（如Claude Code或GitHub Copilot）进行深度对话，逐步细化和完善项目计划。第二阶段是自主执行阶段，开发者退出AI助手，启动Ralph循环，让AI代理在Docker沙箱环境中自动完成编码、测试、提交和推送等一系列操作。\n\n## 第一阶段：交互式规划\n\n规划阶段包含三个按顺序执行的技能，每个技能都有明确的输入和输出，形成一条清晰的工作流水线。\n\n### /grill-me：深度需求挖掘\n\n这是整个工作流的起点。开发者只需要带着一个粗略的想法进入，AI助手会通过一系列精心设计的问题来深入了解这个项目的各个方面。与普通的问答不同，这里的提问策略是" relentless"（不遗余力的）——AI会沿着设计树的每个分支深入探索，在解决依赖关系之前不会跳到下一个话题。\n\n对于每个问题，AI都会提供一个编号的推荐答案，开发者可以选择接受、修改或完全拒绝。更重要的是，AI会主动探索现有的代码库，而不是询问那些它可以通过代码分析自己找到答案的问题。这种设计大大减少了开发者的认知负担，让对话始终保持在真正需要人类判断的议题上。\n\n这个阶段的目标是达成一个完全确定的项目计划——没有模糊地带，没有未解决的分支。对话中产生的所有内容都将成为后续PRD（产品需求文档）的原材料。\n\n### /to-prd：生成产品需求文档\n\n当规划对话达到足够深度后，/to-prd技能会将这些对话内容综合成一份结构化的PRD，并将其发布为GitHub issue。值得注意的是，这个阶段不会再重新采访开发者——它完全基于/grill-me阶段已经建立的内容进行工作。\n\n在这个过程中，AI助手会完成以下任务：首先勾勒需要构建或修改的主要模块，并与开发者确认；然后确保工作目录是一个已经连接到GitHub远程仓库的git仓库（如果需要，会运行git init或gh repo create）；最后撰写完整的PRD，包括问题定义、解决方案、用户故事、实现与测试决策，以及明确划定的范围外内容。\n\n输出的PRD issue URL成为下一个阶段的输入。有趣的是，这个issue故意不被标记，因为标记操作将在下一个步骤中完成。\n\n### /to-issues：任务拆解与队列化\n\n最后一个规划技能/to-issues接收PRD issue编号作为输入，将PRD拆解成一系列扁平、有序的"追踪子弹"式垂直切片。每个切片都是一个薄但完整的实现单元，贯穿从数据库模式到API到UI到测试的所有层级，并且可以独立演示。\n\nAI助手会与开发者就粒度和顺序进行充分讨论，直到获得批准。然后，每个切片都会被发布为一个原生的GitHub子issue，附加到父PRD issue之下。关键的设计在于：每个子issue都被自动标记为afk标签——这正是Ralph循环所寻找的标记。因此，当/to-issues完成时，整个工作队列已经就绪，无需任何手动分类步骤。\n\n## 第二阶段：自主执行\n\n一旦子issue创建完成，开发者就可以退出AI助手，将控制权交给Ralph循环。Ralph循环是一个在Docker沙箱中运行的自主代理，它会依次处理队列中的任务，实现、测试、提交、推送，然后关闭issue，直到没有更多afk标记的issue为止。\n\n### Ralph循环的工作机制\n\nRalph循环由ralph/prompt.md驱动，每次迭代都会执行以下步骤：\n\n首先，循环会加载上下文——包括最近的几次git提交和所有标记为afk的开放issue（标记为hitl的issue是人工介入专用，会被忽略）。然后，它会按照优先级选择一个任务：关键bug修复优先于开发基础设施，基础设施优先于新功能的追踪子弹，追踪子弹优先于润色/快速胜利，最后才是重构。\n\n选定任务后，Ralph使用/tdd（红-绿-重构）技能来实现它。实现完成后，会运行反馈循环——dotnet test和干净的、无警告的dotnet build——确保代码质量后才进行提交。\n\n提交信息会记录关键决策、修改的文件以及给下一次迭代的备注。然后代码被推送到远程仓库。如果任务完成，issue会被关闭；否则，issue会保持开放状态并添加备注，以便下一次迭代可以从上次离开的地方继续。\n\n### 标签模型与执行路径\n\nAgenticWorkflow设计了一个清晰的标签模型来管理不同执行路径：\n\n- afk标签触发本地的Ralph循环，在开发者的机器上的Docker沙箱中运行\n- hitl标签表示人工介入，Ralph循环会跳过这些issue\n- agent:implement标签是一个可选的并行执行路径，可以应用于父PRD，让GitHub Actions在云端实现子issue\n\n这两种执行路径（本地Ralph循环和云端GitHub Actions）消费相同的子issue，开发者可以根据自己的偏好选择使用哪种运行器。\n\n## 技术实现细节\n\nAgenticWorkflow项目本身是一个Shell语言编写的工具集，包含.claude/skills/目录下的三个技能定义和ralph/目录下的循环脚本。这种设计使得它可以与Claude Code和GitHub Copilot两种主流AI编码助手无缝集成。\n\n项目对运行环境有明确的要求：需要安装Docker Desktop来提供沙箱环境，需要GitHub CLI (gh)并已完成认证。如果环境中设置了过期的GITHUB_TOKEN，脚本会自动取消设置它以避免401错误；如果需要使用token，应该设置GH_TOKEN而不是GITHUB_TOKEN。\n\n## 适用场景与价值\n\nAgenticWorkflow特别适合那些需要快速将想法转化为可运行代码的场景。它的价值在于：\n\n首先，通过结构化的规划流程，确保项目在开始编码之前就有清晰的方向和范围定义，减少了后期的返工和范围蔓延。其次，通过将执行阶段自动化，开发者可以专注于更有创造性的工作，而不是重复的编码-测试-提交循环。第三，Docker沙箱环境提供了隔离性和安全性，确保自动执行的代码不会破坏本地开发环境。\n\n对于团队协作来说，这种工作流也有明显优势：PRD和子issue的结构化格式使得项目状态对所有人透明，而自动化的执行阶段则减少了因个人工作习惯差异导致的代码质量不一致问题。\n\n## 局限性与注意事项\n\n尽管AgenticWorkflow提供了强大的自动化能力，但它也有一些需要注意的局限性。首先，它目前主要面向.NET生态系统（从dotnet test和dotnet build的依赖可以看出），虽然概念可以迁移到其他语言，但具体实现需要调整。\n\n其次，Ralph循环每次只处理一个任务，这意味着对于大型项目，完成整个队列可能需要较长时间。虽然这比人工执行要快，但开发者需要有合理的期望。\n\n最后，自动生成的提交信息虽然记录了关键决策，但可能不如人工编写的提交信息那样具有上下文和叙事性。团队需要根据自己的提交信息规范来决定是否需要在Ralph循环完成后进行人工审查和补充。\n\n## 总结与展望\n\nAgenticWorkflow代表了一种将AI代理深度集成到软件开发流程中的新思路。它不是简单地将AI作为代码补全工具，而是将其作为可以承担完整任务执行周期的合作伙伴。通过精心设计的两阶段工作流，它既保留了人类在规划和决策方面的优势，又充分发挥了AI在执行方面的效率和一致性。\n\n随着AI编码助手能力的不断提升，我们可以预期这种混合工作流模式会变得越来越普遍。AgenticWorkflow为这一趋势提供了一个具体而可操作的实现参考，值得所有对AI辅助开发感兴趣的开发者研究和借鉴。