为什么Antfarm的AI智能体不会「懵圈」深入解析Ralph循环的新鲜会话与Git记忆机制【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarmAntfarm是一个开源的 AI 智能体团队协作工具一条命令就能在 OpenClaw 中组建一支由 planner、developer、verifier、tester、reviewer 组成的智能体团队以可靠、可重复的工作流自动完成开发任务。很多用过 AI 编程工具的人都有过这种经历——智能体干着干着就开始懵圈忘记自己改过什么、把上一轮的任务混进这一轮、甚至幻觉出一个不存在的状态。Antfarm 的解法很有意思它没有试图让单个智能体记住更多而是让每个智能体每次都是全新的把记忆外包给 Git 仓库和进度文件。这套机制就叫做Ralph 循环Ralph Loop本文带你拆解它背后的设计。为什么长对话会让 AI「失忆」甚至「幻觉」先理解问题本身。传统做法是把一个大任务丢给一个智能体让它在一个会话里从头做到尾。随着对话变长会发生三件事上下文窗口膨胀几十轮对话之后早期的关键信息被挤到窗口边缘智能体开始顾此失彼状态幻觉智能体以为自己记得的中间状态可能与仓库里的真实代码已经不一致错误累积第 10 步基于第 8 步的一个小误解整个任务就偏了而且很难察觉。Antfarm 项目文档里对这一点的态度非常直接每个智能体都拿到干净的会话。没有上下文窗口膨胀没有来自 50 条消息之前的幻觉状态。见 README.mdRalph循环新鲜会话是「重置」不是「重来」Ralph 循环的核心思想可以概括为一句话每次工作都在一个全新的会话中进行跨会话的记忆不靠上下文而靠持久化的外部载体。在 Antfarm 中这个模式被用在了智能体工作流的循环步骤上。以 workflows/feature-dev/workflow.yml 的开头注释为例Ralph loop — each agent runs in a fresh session with clean context. Memory persists via git history and progress files.翻译过来就是每个智能体都在干净上下文的独立会话中运行记忆则通过Git 历史和进度文件来持久化。新鲜会话是怎么落地的Antfarm 的每个智能体都由一个独立的 cron 定时任务驱动。看 src/installer/agent-cron.ts 中创建定时任务的部分sessionTarget: isolated是关键——每次轮询都在隔离的会话中运行上一次会话的对话内容不会带入这一次。再配合 src/installer/step-ops.ts 中的claimStep逻辑智能体每次认领任务时系统会把当前任务的完整上下文任务描述、仓库路径、分支、已完成的 stories、进度文件内容等一次性渲染进任务模板。换句话说智能体不靠回忆工作而是每次开工前把工作交接单完整重读一遍。这正是 feature-dev 工作流中implement步骤的循环配置workflows/feature-dev/workflow.yml- id: implement agent: developer type: loop loop: over: stories completion: all_done fresh_session: true # 每个故事都开一个全新会话 verify_each: true verify_step: verifyfresh_session: true就是新鲜会话机制的开关每实现一个用户故事developer 智能体都会获得一个全新的会话干净地开始。Git记忆机制把「脑子」换成「档案柜」新鲜会话解决了上下文污染问题但带来一个自然疑问新会话的智能体怎么知道之前发生了什么Antfarm 的答案是三个互补的持久化载体1. Git 历史 —— 代码本身的记忆代码和提交记录就存在 Git 仓库里。每个新会话开工的第一件事就是git pull拉取分支最新代码见 workflows/feature-dev/workflow.yml 中 implement 步骤的指令Pull latest on the branch。上一位同事写了什么代码、改了什么文件git log和git diff一看便知——这是最可靠、不会幻觉的记忆。2. 进度文件 —— 结构化的交接笔记除了代码本身developer 智能体还被要求维护一份进度日志progress-run-id.txt定义在 workflows/feature-dev/agents/developer/AGENTS.md。每次会话结束前必须重写这份文件内容包括每个已完成的故事做了什么、改了哪些文件Learnings踩过的坑、发现的项目惯例Codebase Patterns写在文件最顶部专门沉淀可复用的模式例如测试用 node:test 运行、API 路由都在某个目录下。下一个新鲜会话的智能体第一步就是读这份文件。这样我发现了什么这类 Git 里看不到的隐性知识也通过文件可靠地传递了下去。3. SQLite 数据库 —— 工作流引擎的记忆智能体之间的组织记忆则由 Antfarm 的调度引擎保管。src/installer/step-ops.ts 中的readProgressFile会从智能体工作区读取进度文件并在认领步骤时把它注入到任务模板的{{progress}}变量中而 runs、steps、stories 的状态与输出全部记录在 SQLite 里src/db.ts。所以哪些故事做完了、当前卡在哪一步、验证失败的原因是什么引擎自己心里有数不依赖任何智能体的记忆。一个完整故事的流转重置与记忆的协作把上面三块拼起来一个用户故事在 feature-dev 工作流里的旅程是这样的Planner把任务拆成若干用户故事每个故事小到一个上下文窗口能装下Developer在新鲜会话中认领故事 1读进度文件 → 拉取最新代码 → 实现并写测试 → 提交 → 重写进度文件Verifier在另一个独立会话中验收角色权限上它甚至没有写权限只能读和执行测试不合格则带着ISSUES反馈打回重做故事 1 完成后developer 再次以全新会话开始故事 2——它对故事 1 一无所知但通过进度文件、Git 提交和数据库中的completed_stories列表拿到了完整、可信的交接信息。这套做完即重置、交接靠档案的循环让 20 个故事跑下来智能体的注意力依然像第一个故事时那么清醒——因为它每次都确实是在第一个故事的状态。失败也不怕重试、升级与自我修复新鲜会话机制还带来一个隐藏好处重试是廉价的。失败的故事被重置为pending后src/installer/step-ops.ts 的failStep下一次执行就是一个带上了验证反馈的干净会话不会在上次失败时的错误上下文里越陷越深。此外还有两道保险遗弃步骤清理cleanupAbandonedStepssrc/installer/step-ops.ts会找出认领了却没干完的卡死步骤按智能体超时阈值自动重置回待办保证流程不会静默卡死人工升级每个步骤都配置了max_retries和on_fail: escalate_to: human重试耗尽后会主动通知你而不是默默失败。小结少即是多的智能体工程问题传统长会话方案Antfarm 的 Ralph 循环上下文膨胀越聊越长逐渐失焦每次全新会话上下文恒定干净状态幻觉依赖智能体回忆依赖 Git 历史 进度文件 SQLite知识传递靠对话历史易丢失结构化交接进度文件重写 代码提交失败恢复在错误上下文里继续挣扎干净会话重试失败原因显式注入Antfarm 给我们新手的一个启示是让 AI 团队协作稳定不一定要更强的记忆确定性的流程 干净的上下文 可靠的持久化交接往往比一个什么都记得的智能体更靠谱。如果你想深入了解整套设计推荐从 README.md 的 Built on the Ralph loop 一节读起再配合 docs/creating-workflows.md 里的 Loop Steps (Story-Based) 章节看看fresh_session、verify_each等字段如何组合出自己的多智能体流水线。【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/2 23:02:56 · 阅读 1.2k 为什么Antfarm的AI智能体不会「懵圈」？深入解析Ralph循环的新鲜会话与Git记忆机制
为什么Antfarm的AI智能体不会「懵圈」深入解析Ralph循环的新鲜会话与Git记忆机制【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarmAntfarm是一个开源的 AI 智能体团队协作工具一条命令就能在 OpenClaw 中组建一支由 planner、developer、verifier、tester、reviewer 组成的智能体团队以可靠、可重复的工作流自动完成开发任务。很多用过 AI 编程工具的人都有过这种经历——智能体干着干着就开始懵圈忘记自己改过什么、把上一轮的任务混进这一轮、甚至幻觉出一个不存在的状态。Antfarm 的解法很有意思它没有试图让单个智能体记住更多而是让每个智能体每次都是全新的把记忆外包给 Git 仓库和进度文件。这套机制就叫做Ralph 循环Ralph Loop本文带你拆解它背后的设计。为什么长对话会让 AI「失忆」甚至「幻觉」先理解问题本身。传统做法是把一个大任务丢给一个智能体让它在一个会话里从头做到尾。随着对话变长会发生三件事上下文窗口膨胀几十轮对话之后早期的关键信息被挤到窗口边缘智能体开始顾此失彼状态幻觉智能体以为自己记得的中间状态可能与仓库里的真实代码已经不一致错误累积第 10 步基于第 8 步的一个小误解整个任务就偏了而且很难察觉。Antfarm 项目文档里对这一点的态度非常直接每个智能体都拿到干净的会话。没有上下文窗口膨胀没有来自 50 条消息之前的幻觉状态。见 README.mdRalph循环新鲜会话是「重置」不是「重来」Ralph 循环的核心思想可以概括为一句话每次工作都在一个全新的会话中进行跨会话的记忆不靠上下文而靠持久化的外部载体。在 Antfarm 中这个模式被用在了智能体工作流的循环步骤上。以 workflows/feature-dev/workflow.yml 的开头注释为例Ralph loop — each agent runs in a fresh session with clean context. Memory persists via git history and progress files.翻译过来就是每个智能体都在干净上下文的独立会话中运行记忆则通过Git 历史和进度文件来持久化。新鲜会话是怎么落地的Antfarm 的每个智能体都由一个独立的 cron 定时任务驱动。看 src/installer/agent-cron.ts 中创建定时任务的部分sessionTarget: isolated是关键——每次轮询都在隔离的会话中运行上一次会话的对话内容不会带入这一次。再配合 src/installer/step-ops.ts 中的claimStep逻辑智能体每次认领任务时系统会把当前任务的完整上下文任务描述、仓库路径、分支、已完成的 stories、进度文件内容等一次性渲染进任务模板。换句话说智能体不靠回忆工作而是每次开工前把工作交接单完整重读一遍。这正是 feature-dev 工作流中implement步骤的循环配置workflows/feature-dev/workflow.yml- id: implement agent: developer type: loop loop: over: stories completion: all_done fresh_session: true # 每个故事都开一个全新会话 verify_each: true verify_step: verifyfresh_session: true就是新鲜会话机制的开关每实现一个用户故事developer 智能体都会获得一个全新的会话干净地开始。Git记忆机制把「脑子」换成「档案柜」新鲜会话解决了上下文污染问题但带来一个自然疑问新会话的智能体怎么知道之前发生了什么Antfarm 的答案是三个互补的持久化载体1. Git 历史 —— 代码本身的记忆代码和提交记录就存在 Git 仓库里。每个新会话开工的第一件事就是git pull拉取分支最新代码见 workflows/feature-dev/workflow.yml 中 implement 步骤的指令Pull latest on the branch。上一位同事写了什么代码、改了什么文件git log和git diff一看便知——这是最可靠、不会幻觉的记忆。2. 进度文件 —— 结构化的交接笔记除了代码本身developer 智能体还被要求维护一份进度日志progress-run-id.txt定义在 workflows/feature-dev/agents/developer/AGENTS.md。每次会话结束前必须重写这份文件内容包括每个已完成的故事做了什么、改了哪些文件Learnings踩过的坑、发现的项目惯例Codebase Patterns写在文件最顶部专门沉淀可复用的模式例如测试用 node:test 运行、API 路由都在某个目录下。下一个新鲜会话的智能体第一步就是读这份文件。这样我发现了什么这类 Git 里看不到的隐性知识也通过文件可靠地传递了下去。3. SQLite 数据库 —— 工作流引擎的记忆智能体之间的组织记忆则由 Antfarm 的调度引擎保管。src/installer/step-ops.ts 中的readProgressFile会从智能体工作区读取进度文件并在认领步骤时把它注入到任务模板的{{progress}}变量中而 runs、steps、stories 的状态与输出全部记录在 SQLite 里src/db.ts。所以哪些故事做完了、当前卡在哪一步、验证失败的原因是什么引擎自己心里有数不依赖任何智能体的记忆。一个完整故事的流转重置与记忆的协作把上面三块拼起来一个用户故事在 feature-dev 工作流里的旅程是这样的Planner把任务拆成若干用户故事每个故事小到一个上下文窗口能装下Developer在新鲜会话中认领故事 1读进度文件 → 拉取最新代码 → 实现并写测试 → 提交 → 重写进度文件Verifier在另一个独立会话中验收角色权限上它甚至没有写权限只能读和执行测试不合格则带着ISSUES反馈打回重做故事 1 完成后developer 再次以全新会话开始故事 2——它对故事 1 一无所知但通过进度文件、Git 提交和数据库中的completed_stories列表拿到了完整、可信的交接信息。这套做完即重置、交接靠档案的循环让 20 个故事跑下来智能体的注意力依然像第一个故事时那么清醒——因为它每次都确实是在第一个故事的状态。失败也不怕重试、升级与自我修复新鲜会话机制还带来一个隐藏好处重试是廉价的。失败的故事被重置为pending后src/installer/step-ops.ts 的failStep下一次执行就是一个带上了验证反馈的干净会话不会在上次失败时的错误上下文里越陷越深。此外还有两道保险遗弃步骤清理cleanupAbandonedStepssrc/installer/step-ops.ts会找出认领了却没干完的卡死步骤按智能体超时阈值自动重置回待办保证流程不会静默卡死人工升级每个步骤都配置了max_retries和on_fail: escalate_to: human重试耗尽后会主动通知你而不是默默失败。小结少即是多的智能体工程问题传统长会话方案Antfarm 的 Ralph 循环上下文膨胀越聊越长逐渐失焦每次全新会话上下文恒定干净状态幻觉依赖智能体回忆依赖 Git 历史 进度文件 SQLite知识传递靠对话历史易丢失结构化交接进度文件重写 代码提交失败恢复在错误上下文里继续挣扎干净会话重试失败原因显式注入Antfarm 给我们新手的一个启示是让 AI 团队协作稳定不一定要更强的记忆确定性的流程 干净的上下文 可靠的持久化交接往往比一个什么都记得的智能体更靠谱。如果你想深入了解整套设计推荐从 README.md 的 Built on the Ralph loop 一节读起再配合 docs/creating-workflows.md 里的 Loop Steps (Story-Based) 章节看看fresh_session、verify_each等字段如何组合出自己的多智能体流水线。【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考