自主长时间运行的Coding Agent

自主长时间运行的Coding Agent 自主长时间运行的Coding Agent Modified June 14 循环让自主性更持久 目标给智能体方向，但循环让工作活下去。这个区分很重要，因为模型经常会在真正任务完成前停下来。它们可能达到轮数上限、失去信心、耗尽上下文，或者判定一个局部方案已经足够。 循环是外层控制系统。它会唤醒、检查进展、运行检查、把结果与目标对比，并在目标尚未达成时，把下一条指令送回给智能体。最简单的形式，是 Ralph 循环模式：一个编码智能体加一个确定性条件。更灵活的形式，则包含一个能推理进展并决定下一步的评测智能体。 长时间运行的自主性，不是一段连续不断的智能行为，而是在控制层监督下反复努力。智能体仍然可能失败，但循环让系统能注意到失败并继续推进，而不是悄悄宣称胜利。 规划是专业能力进入系统的地方 规划与模型分工 这场课中最强的主题之一是：规划仍然关键。你可以让前沿模型生成计划，但在把任务交给自主循环之前，你仍然需要检查计划、挑战假设，并把成功标准变得更锋利。 这会形成一种有用的分工。更强的规划模型可以帮助定义目标、识别缺失约束，并组织评测结构。等计划清楚之后，可以由另一个执行模型来运行实现。实践中，这意味着工程师不应该再把“模型”想成单一选择。模型选择会变成架构决策。 有些模型更擅长规划。有些更擅长执行。有些是更便宜的评测器。有些更擅长基于视觉的审阅。好的编排器会允许你替换这些角色，而不是等待某一家厂商提供完美的编码智能体界面。 可视化产物成为控制界面 可视化产物成为控制界面 当许多智能体同时运行时，终端记录无法扩展。一旦你有多个会话并行工作，原始文本就会变成理解进展的糟糕界面。 实时产物很重要，因为一个包含损失曲线、基准分数、任务状态、截图、成本估算和近期决策的仪表盘，能让人类更好地监督自主系统。产物会变成决定何时介入的控制界面，而不是事后生成的报告。 最有用的模式，是把存储和呈现分开。Markdown 或知识库可以存储持久证据、日志、笔记、计划和结果。HTML 产物可以把这些状态渲染成可视化、可交互的东西。智能体可以搜索 Markdown，人类可以监控产物。 对界面和产品工作来说，视觉线索尤其强大。参考截图比文字更精确地传达设计意图，而具备视觉能力的评测器可以把实现与参考图进行对比。这能减少常见失败：智能体技术上实现了请求的组件，却错过了间距、层级、对齐或产品感。 会话挖掘把使用记录变成记忆 会话挖掘与记忆 另一个重要洞察是，过去的智能体会话是丰富的工作流数据来源。如果一个智能体反复以同样方式失败、忘记运行同一个检查、使用错误路径，或者重复尝试同一个坏命令，这种模式不应该埋在日志里。 会话挖掘会把这些记录变成操作规则。智能体可以扫描最近 30 天的工作，找到反复出现的失败模式，并建议更新项目指令、知识库经验或智能体规则。团队可以用这种方式逐步改进运行框架，而不需要手动记住每一个错误。 目标是让本地环境变得更聪明，而不是从零训练一个模型。智能体指令文件里的一条小规则，就能防止未来会话反复失败，尤其当这条规则是项目专属规则时。 一个实用运行模型 实用运行模型 对 AI 工程师来说，正在形成的工作流大概是这样： • 在启动完整自主运行之前，先用一个小而便宜的子集开始。 • 写一个包含可衡量成功标准、明确约束，以及在可能情况下包含轮数或时间预算的目标。 • 分离执行者和评测器，避免把实现和判断压缩成同一个角色。 • 在长时间运行循环开始之前，先定义外部验证器。 • 尽可能使用确定性检查，再为模糊标准加入智能体审阅。 • 要求证明产物，例如日志、截图、基准曲线或变更文件。 • 挖掘过去会话，并把反复出现的经验提升为项目指令。 这就是“使用编码智能体”和“工程化一个自主编码系统”之间的区别。前者给你一段对话。后者给你一个运行框架。 仍然会坏掉的地方 仍然会坏掉的地方 这些都没有消除困难问题。智能体仍然会走捷径。仍然会提前停止。仍然会高估完成度。仍然会产出自信但薄弱的计划，尤其是在近期论文、陌生基准，或训练分布之外的系统上。 更信任它们并不能解决这个问题。更好的控制系统可以。目标、循环、评测器、确定性检查、可视化产物和会话记忆，都是让自主性变得可观察、可纠正的方法。 方向已经很清楚。编码智能体的未来，取决于围绕更强模型构建更好的编排：工程师要设计条件，让智能体可以安全运行数小时或数天，同时仍然产出可验证的工作。 目标给智能体方向，但循环让工作活下去。这个区分很重要，因为模型经常会在真正任务完成前停下来。它们可能达到轮数上限、失去信心、耗尽上下文，或者判定一个局部方案已经足够。 循环是外层控制系统。它会唤醒、检查进展、运行检查、把结果与目标对比，并在目标尚未达成时，把下一条指令送回给智能体。最简单的形式，是 Ralph 循环模式：一个编码智能体加一个确定性条件。更灵活的形式，则包含一个能推理进展并决定下一步的评测智能体。 长时间运行的自主性，不是一段连续不断的智能行为，而是在控制层监督下反复努力。智能体仍然可能失败，但循环让系统能注意到失败并继续推进，而不是悄悄宣称胜利。 规划是专业能力进入系统的地方 这场课中最强的主题之一是：规划仍然关键。你可以让前沿模型生成计划，但在把任务交给自主循环之前，你仍然需要检查计划、挑战假设，并把成功标准变得更锋利。 这会形成一种有用的分工。更强的规划模型可以帮助定义目标、识别缺失约束，并组织评测结构。等计划清楚之后，可以由另一个执行模型来运行实现。实践中，这意味着工程师不应该再把“模型”想成单一选择。模型选择会变成架构决策。 有些模型更擅长规划。有些更擅长执行。有些是更便宜的评测器。有些更擅长基于视觉的审阅。好的编排器会允许你替换这些角色，而不是等待某一家厂商提供完美的编码智能体界面。 可视化产物成为控制界面 当许多智能体同时运行时，终端记录无法扩展。一旦你有多个会话并行工作，原始文本就会变成理解进展的糟糕界面。 实时产物很重要，因为一个包含损失曲线、基准分数、任务状态、截图、成本估算和近期决策的仪表盘，能让人类更好地监督自主系统。产物会变成决定何时介入的控制界面，而不是事后生成的报告。 最有用的模式，是把存储和呈现分开。Markdown 或知识库可以存储持久证据、日志、笔记、计划和结果。HTML 产物可以把这些状态渲染成可视化、可交互的东西。智能体可以搜索 Markdown，人类可以监控产物。 对界面和产品工作来说，视觉线索尤其强大。参考截图比文字更精确地传达设计意图，而具备视觉能力的评测器可以把实现与参考图进行对比。这能减少常见失败：智能体技术上实现了请求的组件，却错过了间距、层级、对齐或产品感。 会话挖掘把使用记录变成记忆 另一个重要洞察是，过去的智能体会话是丰富的工作流数据来源。如果一个智能体反复以同样方式失败、忘记运行同一个检查、使用错误路径，或者重复尝试同一个坏命令，这种模式不应该埋在日志里。 会话挖掘会把这些记录变成操作规则。智能体可以扫描最近 30 天的工作，找到反复出现的失败模式，并建议更新项目指令、知识库经验或智能体规则。团队可以用这种方式逐步改进运行框架，而不需要手动记住每一个错误。 目标是让本地环境变得更聪明，而不是从零训练一个模型。智能体指令文件里的一条小规则，就能防止未来会话反复失败，尤其当这条规则是项目专属规则时。 一个实用运行模型 对 AI 工程师来说，正在形成的工作流大概是这样： • 在启动完整自主运行之前，先用一个小而便宜的子集开始。 • 写一个包含可衡量成功标准、明确约束，以及在可能情况下包含轮数或时间预算的目标。 • 分离执行者和评测器，避免把实现和判断压缩成同一个角色。 • 在长时间运行循环开始之前，先定义外部验证器。 • 尽可能使用确定性检查，再为模糊标准加入智能体审阅。 • 要求证明产物，例如日志、截图、基准曲线或变更文件。 • 挖掘过去会话，并把反复出现的经验提升为项目指令。 这就是“使用编码智能体”和“工程化一个自主编码系统”之间的区别。前者给你一段对话。后者给你一个运行框架。 仍然会坏掉的地方 这些都没有消除困难问题。智能体仍然会走捷径。仍然会提前停止。仍然会高估完成度。仍然会产出自信但薄弱的计划，尤其是在近期论文、陌生基准，或训练分布之外的系统上。 更信任它们并不能解决这个问题。更好的控制系统可以。目标、循环、评测器、确定性检查、可视化产物和会话记忆，都是让自主性变得可观察、可纠正的方法。 方向已经很清楚。编码智能体的未来，取决于围绕更强模型构建更好的编排：工程师要设计条件，让智能体可以安全运行数小时或数天，同时仍然产出可验证的工作。 原帖链接：https://x.com/omarsar0/status/2065880971031834786 原帖链接：https://x.com/omarsar0/status/2065880971031834786 自主编码正在从“写出更好的提示词”，转向“设计更好的控制系统”。关键变化在于，工程师正在学习如何用目标、评测器、循环和产物把智能体包裹起来，让它们在人类停止输入之后仍能继续工作。 这很重要，因为大多数严肃工程工作都横跨很长时间跨度：需求含糊、约束隐藏、局部失败、上下文变化，以及反复验证。新的前沿方向，是围绕智能体设计系统，让它能够规划、执行、检查自己的工作、从错误中恢复，并在不需要人类持续指挥的情况下继续推进。 本文基于一场 DAIR.AI Academy 关于自主长时间运行编码智能体的课程。我在课上实践讲解了 Claude Code 的 /goal 模式、新的 /loop 命令、验证器、产物和编排模式。本文与 Codex 和 Claude Code 协作完成。 从提示词转向目标设计 Claude Code 的 /goal 这类功能背后的核心想法很简单。编码智能体仍然是执行者，但人类不再逐轮和它互动。相反，人类指定期望的最终状态、证明成功所需的证据、不能违反的约束，以及在可能的情况下指定轮数和预算。 这个目标更像一份契约，而不是一条更长的提示词。弱目标会给模型留下空间，让它提前停止、走捷径，或者重新定义成功；这些在对话记录里看起来合理，但在真实系统里会失败。强目标会给智能体一个可以反复衡量自己的靶子。 工程判断在这里仍然重要。最好的目标会编码领域知识，而这些知识如果不写明，模型就只能猜。对研究实验来说，这可能意味着目标基准分数、留出评测、必须满足的损失曲线，以及结果必须超过初始基线的规则。对界面任务来说，这可能意味着参考截图、具体布局约束，以及浏览器验证步骤。模型可以执行，但人类仍然定义“完成”到底意味着什么。 评测器成为一等组件 长时间运行的智能体，除了目标之外还需要第二个角色。这个评测器可以是另一个编码智能体、充当评审的 LLM、脚本、测试套件、基准运行框架，或者它们的组合。关键设计选择，是让评测器匹配任务。当成功条件清晰时，确定性检查更好。类型检查、单元测试、代码风格规则、集成测试和基准脚本，只要能清楚表达条件，就应该使用。 当成功条件模糊时，智能体评测器就会变得有用。脚本可以告诉你测试是否通过，但它很难判断一份生成的研究报告是否连贯，一个实现是否忠实遵循论文，或者一个界面是否符合设计意图。这里，评测器会受益于语言能力、判断力，有时还需要视觉能力。 实用模式是：用确定性检查做底线，再用智能体评测做更高层审阅。这个组合能减少“幻觉式成功”，同时仍允许系统在无法被测试断言干净表达的任务上保持自主性。 验证器定义信任边界 更深层的要点是：只有当系统拥有可靠验证器时，自主性才有效。编码智能体可以生成计划、实现功能，并解释为什么它认为工作已经完成，但这种解释不应该被当成证据。证据来自外部检查，而且这个检查不能轻易被智能体用语言绕过去。 对代码来说，验证器可能是测试套件、类型检查器、基准、浏览器运行、截图对比，或者可复现实验脚本。对研究工作来说，可能是留出评测、复现表格、损失曲线，或者相比基线有所提升的基准分数。对设计工作来说，可能是参考截图加视觉审阅步骤。验证器会把一个长时间运行的智能体，从自信的文本生成器，变成一个可以被托付更多时间的系统。 大多数捷径都出现在这个边界上。如果验证器含糊，模型往往会满足任务最容易的解释。如果验证器太窄，模型可能过拟合验证器而错过更广泛的意图。因此，一个好的自主工作流需要分层验证：便宜的确定性检查捕捉基础失败，高层审阅捕捉需要判断力的失败。一些前沿模型已经能实现一定程度的验证，但根据我的研究，仍然存在明显的 OOD（分布外）问题：当你分配给智能体的验证任务落在训练分布之外时，模型会明显吃力。 验证器仍然是开放研究方向，但我预计更多公司会开始在这个领域投入大量资源。面向企业的微调验证器需求也很高。 循环让自主性更持久