https://www.knightli.com/tags/%E5%A4%9A%E6%99%BA%E8%83%BD%E4%BD%93/ Recent content in 多智能体 on KnightLi的博客 Hugo -- gohugo.io zh-cn Mon, 27 Apr 2026 08:19:02 +0800 https://www.knightli.com/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ Mon, 27 Apr 2026 08:19:02 +0800 https://www.knightli.com/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ <p>如果你最近在折腾 coding agent，很快就会遇到一个现实问题：<strong>AI 当然能干活，但怎么让它连续干几个小时，还不在中途跑偏、忘要求、返工一堆？</strong></p> <p>围绕 <code>Ralph</code> 和多智能体协同的这类讨论，真正值得看的也正是这个问题。它不是单纯比较某个模型有多强，而是把重点放在一层更实际的东西上：<strong>怎么设计工作流，才能让 AI 在长任务里保持稳定输出。</strong></p> <p>把这个问题拆开看，常见的路线主要有两条：</p> <ul> <li><code>Ralph</code> 方案：不断启动新会话，通过文件系统衔接上下文</li> <li>多智能体方案：主 Agent 做协调，子 Agent 分工执行</li> </ul> <p>如果把它压成一句更好理解的话，这期内容讲的其实不是“哪个模型更厉害”，而是“怎么把 AI 组织起来，让它更像一个能持续交付的小团队”。</p> <h2 id="01-为什么长时任务容易失控">01 为什么长时任务容易失控 </h2><p>短任务里，很多问题不明显。你给一句指令，模型读几份文件，改几行代码，事情也就结束了。</p> <p>但任务一旦拉长，问题会集中冒出来：</p> <ul> <li>会话越来越长，上下文开始膨胀</li> <li>早先的要求被新信息挤掉</li> <li>一个 Agent 既要想方案，又要写代码，还要自己测，容易顾不过来</li> <li>没有明确验收环节时，看起来“做完了”，其实只是“说自己做完了”</li> </ul> <p>所以长时间运行 AI，真正考验的往往不是模型单次输出能力，而是 <strong>任务拆分、状态衔接、角色分工和反馈回路</strong>。</p> <h2 id="02-ralph-方案把长任务拆成很多短回合">02 Ralph 方案：把长任务拆成很多短回合 </h2><p><code>Ralph</code> 的思路很适合先解决“上下文越跑越脏”这个问题。</p> <p>它的核心做法是：</p> <ul> <li>用循环不断启动新的 agent 会话</li> <li>每轮只处理一个足够小的任务</li> <li>把跨轮状态放到文件里，而不是全压在同一个对话上下文里</li> </ul> <p>这样做的好处很直接：每次都是 fresh context，单轮会更聚焦，也更不容易被历史消息拖慢。</p> <p>如果你已经看过 <code>Ralph</code> 相关项目，会发现这套方法背后的逻辑很一致：</p> <ul> <li>当前任务写在结构化文件里</li> <li>中间经验写到进度文件里</li> <li>代码变化留在 git 历史里</li> </ul> <p>换句话说，<code>Ralph</code> 不是试图让一个 Agent “永远记住所有事”，而是主动把记忆外置，让会话本身保持轻一点。</p> <p>这类方案特别适合下面几种情况：</p> <ul> <li>任务已经能拆成一组小 story</li> <li>每个 story 都能在单个上下文窗口里完成</li> <li>项目里已经有测试、typecheck 或其他检查机制</li> </ul> <p>它解决的是“如何让 AI 一轮一轮稳定推进”。</p> <h2 id="03-多智能体方案把一个人做不完的事分出去">03 多智能体方案：把一个人做不完的事分出去 </h2><p>另一条路线是多智能体协同。</p> <p>从这类工作流设计思路来看，更值得推荐的通常是这种方式：主 Agent 不直接埋头干活，而是负责协调；子 Agent 各自处理开发、测试、检查、验收等不同任务。</p> <p>这和 <code>Ralph</code> 的区别在于：</p> <ul> <li><code>Ralph</code> 更像串行迭代</li> <li>多智能体更像并行分工</li> </ul> <p>如果任务里天然有不同角色，多智能体会更顺手。比如：</p> <ul> <li>一个 Agent 负责拆任务和写执行计划</li> <li>一个 Agent 负责具体实现</li> <li>一个 Agent 负责测试和验证</li> <li>一个 Agent 负责回看结果是不是符合最初需求</li> </ul> <p>这样做的价值不是“多开几个窗口显得很高级”，而是让不同工作职责分离开。原来塞在一个 Agent 身上的几件事，现在可以拆成几个更明确的环节。</p> <p>一旦角色边界清楚，很多问题都会变轻：</p> <ul> <li>写的人不必同时当审的人</li> <li>跑测试的人不必重新推导整套需求</li> <li>主 Agent 不会被实现细节淹没</li> </ul> <p>它解决的是“如何让 AI 像一个小团队那样配合”。</p> <h2 id="04-真正关键的不是多开而是怎么拆">04 真正关键的，不是多开，而是怎么拆 </h2><p>无论是 <code>Ralph</code> 还是多智能体，最容易被忽略的一点都是：<strong>流程设计比多开几个 Agent 更重要。</strong></p> <p>如果任务拆分不对，就算开再多 Agent，也只是把混乱并行化。</p> <p>比较稳的拆法通常有几个特点：</p> <ul> <li>一个任务只对应一个明确目标</li> <li>一个角色只负责一类输出</li> <li>每轮都有清楚的完成标准</li> <li>上一轮的结果能被下一轮直接消费</li> </ul> <p>比如比起给 AI 一个“把整个功能做完”的大指令，更稳的方式往往是：</p> <ul> <li>先拆出需求和边界</li> <li>再拆实现</li> <li>再拆测试</li> <li>最后单独做验收</li> </ul> <p>这类拆法的好处是，问题一旦出现，更容易知道是出在理解、实现、测试，还是交付标准上。</p> <h2 id="05-为什么验收环节特别重要">05 为什么验收环节特别重要 </h2><p>很多 AI 工作流失败，不是因为前面完全没做事，而是因为最后缺了一个真正独立的确认动作。</p> <p>在长任务里，“已经生成结果”和“结果真的可用”之间，经常隔着一整层差距。</p> <p>这里有个很值得重视的方向，就是把开发和验收拆开看。哪怕不做到特别复杂，至少也应该把这些问题单独问一遍：</p> <ul> <li>它真的完成了最初那条任务吗</li> <li>有没有只改表面、没解决根因</li> <li>测试是不是只验证了最顺利的路径</li> <li>有没有把上游要求悄悄改掉</li> </ul> <p>只要这层检查缺位，AI 很容易在长流程里不断“自我宣布成功”。</p> <h2 id="06-两条路线怎么选">06 两条路线怎么选 </h2><p>如果只是想快速判断，可以先这么理解：</p> <ul> <li>你最痛的是上下文膨胀和长会话失焦，先看 <code>Ralph</code></li> <li>你最痛的是一个 Agent 身兼多职、任务之间互相打架，先看多智能体</li> </ul> <p>再具体一点：</p> <ul> <li><code>Ralph</code> 更适合流程清楚、任务细碎、可以按回合推进的工作</li> <li>多智能体更适合角色明显、需要并行和交叉验证的工作</li> </ul> <p>很多时候，这两条路也不是非此即彼。比较成熟的做法，反而可能是把它们组合起来：</p> <ul> <li>外层用 <code>Ralph</code> 这种迭代循环推进大任务</li> <li>内层在单轮里再用多智能体处理研究、实现、测试和验收</li> </ul> <p>这样既能控制长上下文，又能提高单轮内部的协作效率。</p> <h2 id="07-一句话总结">07 一句话总结 </h2><p>这类方法最值得看的地方，不是单独推荐了 <code>Ralph</code> 或多智能体，而是把一个很现实的问题讲清楚了：<strong>让 AI 长时间稳定工作，关键从来不只是模型本身，而是你有没有把上下文、任务、角色和验收设计好。</strong></p> <p>如果你已经开始让 <code>Claude Code</code>、<code>Codex</code> 或其他 coding agent 处理更长的真实任务，这类工作流思路会比“再换一个更强模型”更值得优先补课。</p>