https://knightli.com/tags/harness/ Recent content in Harness on KnightLi的博客 Hugo -- gohugo.io zh-cn Mon, 27 Apr 2026 08:19:02 +0800 https://knightli.com/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ Mon, 27 Apr 2026 08:19:02 +0800 https://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> https://knightli.com/2026/04/10/anthropic-harness-agent-os/ Fri, 10 Apr 2026 09:22:56 +0800 https://knightli.com/2026/04/10/anthropic-harness-agent-os/ <p>Anthropic 最近发布了一篇关于 Harness 的工程实践。表面看是在讲产品实现，实质上回答的是一个更长期的问题：</p> <p><strong>当模型能力持续变化时，Agent 系统哪些层要稳定，哪些层应该允许快速替换？</strong></p> <h2 id="核心判断">核心判断 </h2><p>我对这篇文章的核心理解是：Agent 基础设施会越来越像一个轻量的 <strong>Agent OS</strong>。</p> <p>重点不在“把今天的最佳流程写死”，而在“定义长期稳定的系统抽象”。</p> <h2 id="为什么这点重要">为什么这点重要 </h2><p>很多 Agent 框架常见的问题是：</p> <ul> <li>把模型的临时短板固化为永久架构</li> <li>把 prompt 工程误当成系统边界</li> <li>把一次有效的补丁写成长期依赖</li> </ul> <p>模型会变强，今天合理的补丁，明天可能就是技术债。</p> <h2 id="anthropic-的解法从具体-harness-到-meta-harness">Anthropic 的解法：从具体 Harness 到 Meta-Harness </h2><p>这套思路不是承诺某一种固定编排方式，而是抽象出三层稳定接口：</p> <ol> <li><code>session</code>：可恢复的事件与状态历史</li> <li><code>harness</code>：推理与调度循环（brain）</li> <li><code>sandbox</code>：执行环境与工具能力（hands）</li> </ol> <p>它们分离后，系统更容易替换、恢复和扩展。</p> <h2 id="1-session-不是上下文窗口">1) Session 不是上下文窗口 </h2><p>一个关键观点是：<strong>Session 不等于模型上下文。</strong></p> <p>Session 应该是可查询、可回放、可恢复的事件日志，而不是直接塞给模型的历史拼接。</p> <p>这样做的价值：</p> <ul> <li>trimming 不等于历史消失</li> <li>compaction 不等于事实丢失</li> <li>崩溃恢复可以回到事件层，而不是依赖摘要记忆</li> </ul> <h2 id="2-harness-是可替换的编排层">2) Harness 是可替换的编排层 </h2><p>Harness 应专注于调度，而不是持有业务状态。</p> <p>理想接口更接近：</p> <p><code>execute(name, input) -&gt; string</code></p> <p>这意味着模型只关心“我能调用什么能力”，而不强绑定具体设备、容器或操作系统。</p> <h2 id="3-sandbox-是手不是脑">3) Sandbox 是“手”，不是“脑” </h2><p>当 brain 和 hands 解耦：</p> <ul> <li>工具环境可以独立演进</li> <li>不同基础设施可以并行接入</li> <li>不必每个会话都预热完整执行环境</li> </ul> <p>这直接带来更好的启动与扩展表现。</p> <h2 id="性能与安全启发">性能与安全启发 </h2><p>这种拆分通常会同时改善性能和安全。</p> <p>性能上：</p> <ul> <li>可以先启动 brain，再按需拉起 hands</li> <li>降低首 token 延迟（TTFT）</li> </ul> <p>安全上：</p> <ul> <li>不把高敏凭证直接暴露给模型</li> <li>用受控 proxy / vault 做间接凭证访问</li> <li>安全边界建立在系统约束上，而不是“模型应该做不到”</li> </ul> <h2 id="相关链接">相关链接 </h2><ul> <li><a class="link" href="https://claude.com/blog/claude-managed-agents" target="_blank" rel="noopener" >Usage patterns and customer examples</a></li> <li><a class="link" href="https://www.anthropic.com/engineering/managed-agents" target="_blank" rel="noopener" >The design of Claude Managed Agents</a></li> <li><a class="link" href="https://platform.claude.com/docs/en/managed-agents/quickstart" target="_blank" rel="noopener" >Onboarding, quickstart, overview of the CLI and SKDs </a></li> </ul>