别再纠结 Codex 对决 Claude Code 了，Goal Buddy 终于解决了两者的问题

中文العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский
AAI LABS
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00这位是蜗牛盖瑞，他发现了一个市场空白，想建立一个蜗牛约会平台
00:00:04但因为他动作超级慢，所以他想让 Claude Code 自主处理他的长期任务
00:00:09幸运的是，AI 代理在处理长期任务方面已经变得非常出色，Claude Code 有一个
00:00:13goal 命令，可以让代理一直运行直到任务完成，但在我们的
00:00:18测试中，我们发现 goal 命令有很多问题，由于盖瑞最近刚经历过
00:00:22离婚，我们希望他快乐，所以我们找到了一个真正能解决这个问题的开源工具
00:00:28它不仅适用于 Claude Code，也适用于 Codex，传播爱心，就像你妈妈
00:00:32肯定和你那位有工作的兄弟一样爱你。Claude Code 之前发布了一个名为
00:00:38goal 的命令，可以让代理持续工作直到达到某个条件。我们没有在
00:00:42频道里介绍过这个，但你可能已经知道了。在此之前，有一个名为 Ralph Wiggum 的插件
00:00:47非常受欢迎，它本质上做了同样的事情。它使用钩子将提示词
00:00:52循环反馈给 Claude Code，直到条件真正满足。但问题是，这些条件必须是
00:00:57精确匹配，因为 Ralph 循环使用 shell 脚本来检查条件，字面意义上就像
00:01:02机场安检人员，因为你的男士香体喷雾超过了行李
00:01:06限制就不让你通过。goal 命令的工作方式不同，它接收条件和目前的对话内容
00:01:11并将其交给一个小模型，也就是 Haiku，这个模型会智能地评估任务是否完成
00:01:17它会返回一个“是”或“否”的决定，而“否”则告诉 Claude 继续迭代同一个任务，就像你老板
00:01:22让你优化用户体验，因为他自己在页面上找不到按钮一样。所以这使得
00:01:27评估变得主观，对于那些我们无法独立量化的事情，这是一个真正的改进
00:01:32goal 命令对于很多任务确实有效，但它仍然有很多问题。第一个问题是
00:01:37它不使用任何知识库或文件系统来跟踪任务进度，而且因为它
00:01:42不这么做，代理唯一的真理来源就成了对话上下文。这可能会触动
00:01:47你，因为当年就是你爸把加密货币的财富写在便利贴上，然后从冰箱上掉下来
00:01:52丢了。一旦会话因为任何原因结束且 goal 未完成，你当然可以使用
00:01:58Claude 的 resume 命令，goal 不会丢失，但它了解进度停在哪里的唯一方法就是
00:02:03对话上下文，而且由于这个命令是针对长期任务而非简单任务的，中间可能会
00:02:08变得一团糟。当然，随着 goal 运行几个小时，上下文膨胀和达到压缩上限
00:02:13在某个时候注定会成为真正的问题。在压缩之后，代理的输出会变差
00:02:18它开始表现得像我奶奶，因为患有痴呆症，她开始忘记
00:02:22频道的名字了。我需要你们为她看看上一个视频。另一个问题是它不会
00:02:27将任务分解成更小的任务。相反，它只是使用主代理自己进行任务分解
00:02:32就像 Claude Code 通常做的那样，所以没有结构化的计划，代理可能会丢失
00:02:37还要做什么的记录。即使这在某些情况下效果很好，但一个不清晰的
00:02:42“完成”定义对于代理来说从来不是正确的事情。goal 完全依赖
00:02:47模型来评估完成情况，所以它在某些情况下可能没那么有效。它比
00:02:52使用脚本完全严格的 Ralph Wiggum 要好，但至少应该有一些指标
00:02:56能告诉代理“完成”看起来是什么样子的，就像你那个一直说
00:03:01“再拍一张”直到整个活动结束的婚礼摄影师一样。这就是 goal 的不足之处，这些事情
00:03:05看起来可能没什么，但当投入到真正繁重的工作流中时，它们会带来一些严重的问题
00:03:10现在，Goal Buddy 这个工具诞生的唯一目的就是让 goal 命令真正发挥
00:03:16它应有的作用。它解决了我们刚才谈到的所有问题，但并没有得到
00:03:20它应有的关注，考虑到它有多么有用。它就像性感的保姆，只不过不是在
00:03:25调情，而是在照顾你的长期任务。goal 不会在本地保留工作状态
00:03:30所以这个工具修复了这一点，并且实际上强制 goal 读取和更新本地状态，而不是依赖于
00:03:36聊天历史，它还以证明结束，这样代理在开始之前就知道“完成”是什么样子
00:03:42为了跟踪进度，它还包含一个完整的仪表板，你可以在代理工作时
00:03:46观察它。为了处理这一切，它建立在三个代理之上，分别是
00:03:51侦察兵、工人和法官，基本上就是一个 Y Combinator 的创业团队，一个负责做所有工作，一个
00:03:56看着他做，还有一个在 Twitter 上评价他们两个。安装非常直接，只要
00:04:01复制安装命令并粘贴到你的项目文件夹中。它将作为一个插件安装
00:04:06同时适用于 Claude Code 和 Codex。一旦你开始一个新的会话，你就可以看到该命令
00:04:10可用。所以这三个代理每个都有严格定义的角色和访问级别，因为这个
00:04:16工具也为 Codex 构建，所以代理是在 TOML 而不是标准的 Markdown 中定义的。这
00:04:21第一个代理是法官，它只有读取权限。它会怀疑地分析困难的决定，比如有风险的
00:04:26范围、矛盾的来源和其他模式，以确保任务安全完成。它的
00:04:31指令禁止编辑，因为它只存在于做出判断，别无他用。由于它的
00:04:36任务非常关键，所以这个代理的推理能力被设置为最高，以确保决定做出得当
00:04:42这就像你在深夜里连续四个小时编写发给你暗恋对象的短信一样。
00:04:47在完成工作后，它会返回一个包含批准和拒绝决定的 JSON 结构
00:04:52以及理由。侦察兵是另一个只读代理，它映射活跃任务
00:04:57并为它创建一个紧凑的证据收据。由于它的工作只是检查任务的状态
00:05:02它的推理努力保持在较低水平，就像你最喜欢的脱衣舞俱乐部保镖一样。它根本不在乎
00:05:07那么多。然后还有工人代理，它是唯一拥有编辑权限的代理。它做实际的工作，且
00:05:12一次只允许执行一个任务。还有一个 PM 角色，即主线程
00:05:17协调工作流。它的表现就像一个实际的项目经理，做最少量的工作
00:05:22它是唯一能真正将任务标记为完成的权威。核心工作流始于表达
00:05:27任务的意图，用正确的词语，而不是像我们人类通常那样含糊其辞，而是用一种
00:05:33代理可以正确理解的方式。然后定义预言机。预言机本质上是一个可观察的
00:05:38信号，它确定了结果。它是系统进行迭代以查看任务是否可以
00:05:43被标记为完成或不完成的标准。它可以是任何东西：测试套件、浏览器演练、任何人工制品的基准测试，或将我的微波炉变成时间机器的代码
00:05:49因为为什么不呢？AI 代理现在什么都能做。下一步是表面化
00:05:54它将任务分解为可操作的步骤，创建仪表板，并将任务映射
00:06:00为可视格式。最后一块是 PM，在这种情况下他是经理，并保持 goal 运行
00:06:06直到最终审计将目标标记为达到。要使用 Goal Buddy，你只需运行 goal prep 命令
00:06:11这是初始化工作流的命令，你定义你想要它实现的目标。它
00:06:16首先确保代理已安装并准备好使用。它然后启动工作流，但与
00:06:21原生的 goal 命令不同，它非常有自我意识，并且首先通过询问你问题来消除其自身的歧义
00:06:27这样你就可以清晰地定义实现，就像你那多疑的妻子一样
00:06:32它会一直问问题直到它理解了为止。第一步专注于创建 goal 文件，它放置
00:06:38原始请求以及我们的答案，然后将其映射到代理可理解语言中的
00:06:43正确目标。它包含所有信息的摘要，然后定义预言机
00:06:48这是最重要的部分。此任务的预言机很简单：所有测试必须通过并具有
00:06:53正确的行为。这种目标是具体的，因为它可以被程序化地
00:06:57评估，不像你昨晚的借口，你妻子根本不信。Goal Buddy 将整个工作流分解
00:07:03为小的可执行任务。这些被称为片段，但在现实世界中，大小在这里不重要
00:07:08因为小片段并不意味着小任务，它意味着安全、易于验证
00:07:14并且可以单独运行的内容。它在文档中也显式定义了安全切片大小。它创建
00:07:19了 state.yaml，它跟踪项目和任务，并定义 PM 循环的样子。state.yaml 由
00:07:26所有的目标和规则组成，所有任务按 ID 和分配的代理分解。它包含
00:07:31一个用于跟踪活动任务的字段。它还提到了链接的仪表板。它列出了所有的待办
00:07:36任务和进行中的任务。在我们的例子中，侦察兵代理目前正在进行中，并正在映射所有
00:07:42的文件和端点。所以要开始循环，你只需复制这个命令并运行它。它指示 Claude
00:07:47设定执行 goal.md 文件中所有内容的目标。从那里开始，它会像国王一样挑选第一个
00:07:52活跃任务，然后召唤其下属代理来执行它。一旦侦察兵完成了
00:07:58工作，它就会更新进度文件并将所有发现记录在一个单独的目录中
00:08:03它还会将看板从活动更新为已完成。然后循环挑选下一个任务，将其标记为
00:08:08活动，并启动法官代理。法官会批判性地审查发现并将报告序列化
00:08:13为最少数量的垂直片段，也就是工人要独立执行的任务分解
00:08:18它然后更新切片计数并相应地更新状态文件。每个任务
00:08:22明确列出允许的文件、如何验证它们以及何时停止。这就是它定义每个片段的方式
00:08:28这样代理就有了明确的预期输出、检查和所有必要的细节。然后一个接一个地
00:08:33初始化工人代理并开始处理第一个片段。每个代理的进度都可以通过仪表板跟踪
00:08:39你会知道每个任务在做什么，哪个代理是活动的，哪些任务在排队，以及
00:08:44哪些完成了，所以你不必亲自监控，可以真正给你的孩子
00:08:48他们需要的时间。一旦所有任务完成，它就会以 PM 的身份执行最后一次审计
00:08:53确保所有测试都已正确进行。审计完成后，它会将法官
00:08:58代理的最终审计任务标记为完成，然后将目标标记为完成。在此之后，你必须开始
00:09:03祈祷并希望那些代理没有产生幻觉。总的来说，考虑到复杂性
00:09:09和我们给它的应用程序的规模，这运作得相当好。但我们认为可以添加更有效的并行化
00:09:13因为它完全是顺序执行的。它一次处理一个任务，根本没有利用
00:09:18Claude Code 的并行化能力。Dario 看到这个会很失望
00:09:23但鉴于它规划工作流的程度，它确实工作得很好。另外，如果你喜欢我们的内容
00:09:28考虑按下“点赞”按钮，因为它有助于我们创建更多这样的内容并接触到更多
00:09:33的人。我们还想在更通用的东西上测试 Goal Buddy，比如设计 UI，看看它是
00:09:38如何处理无法程序化评估的任务。之前的测试是在具有明确通过和失败标准的特定工作流上进行的
00:09:44但就像你从理发师那里得到的新发型一样，有些任务
00:09:49确实没有标准。所以我们首先给通常的 goal 命令一个模糊的提示。它初始化了目标
00:09:54任务，咨询了顾问，并很快给出了一个网站。因为懒惰，它只是创建了一个简单的 HTML 页面
00:10:00并且没有使用任何框架。但落地页看起来并不坏。所以我们给了完全相同的提示给
00:10:05Goal Buddy。一旦它开始，它遵循了相同的工作流，并给了类似的提问会话
00:10:10来澄清意图。在这里，Goal Buddy 实际上还询问了技术栈。通常
00:10:14我会称这为拍马屁，但因为我认真对待我的 AI 代理，我称之为彻底。同样地，它
00:10:20创建了看板和 goal.md 文件，并将我们的原始请求翻译成了一个正确的目标。它还
00:10:26正确识别了预言机，但前一个任务中的预言机很简单，只需要通过所有
00:10:31测试。这一个有不同的目标。它定义当开发服务器启动并运行时，任务即为完成
00:10:36并且浏览器演练确认所有部分如定义工作。这就是它如何将
00:10:41不可量化的任务变成可量化的东西。它也再次创建了 state.yaml，其中包含预言机
00:10:47规则、代理和所有列出的任务，然后以同样的方式开始工作。它花了比
00:10:52正常的 goal 命令更长的时间，但它最终正确地实现了应用程序。这对于盖瑞来说不会是
00:10:57问题，但你在此期间应该做些俯卧撑，我能看出你变胖了
00:11:02相比之下，整个网站的表现明显优于简单的 goal 命令所创建的内容
00:11:07如果你真的想成为一名 AI B2B SaaS 创始人，喜欢构建而不是只看教程
00:11:12那么你应该成为 AI Labs Pro。你会在这里见到像我们团队这样志同道合的极客
00:11:17以及视频中的资源和许多其他好东西。链接会在描述中，
00:11:22你可以看看。这带我们来到了视频的结尾。如果你想支持频道
00:11:27并帮助我们继续制作这样的视频，你可以通过使用下面的“超级感谢”按钮来做到。一如既往
00:11:32感谢观看，下次见

Key Takeaway

Goal Buddy 通过引入状态持久化机制和三代理协作框架，弥补了 Claude Code 和 Codex 在处理复杂长期任务时缺乏结构化规划与任务进展跟踪的问题。

Highlights

  • Goal Buddy 解决了原生 Claude Code 的 goal 命令在长期任务中缺乏状态持久化和任务分解能力的缺陷。

  • 该工具通过侦察兵（Scout）、工人（Worker）和法官（Judge）三个专用代理协作，实现了结构化的长期任务管理。

  • Goal Buddy 强制要求在本地保存 state.yaml 文件以跟踪任务进度，不再仅依赖于易丢失的聊天上下文。

  • 预言机（Oracle）定义通过可验证的测试或浏览器行为，将不可量化的模糊需求转化为了程序可评估的目标。

  • 该工具支持 Claude Code 和 Codex，并提供完整的仪表板以可视化查看各个代理的任务执行情况。

  • 在处理 UI 设计等无明确测试标准的任务时，Goal Buddy 通过彻底的意图澄清和预言机设置，产出了比标准 goal 命令更高质量的代码。

Timeline

原生 goal 命令的局限性

  • 原生 goal 命令完全依赖对话上下文跟踪进度，导致长时间运行后容易因上下文压缩丢失信息。
  • 缺乏文件系统层面的状态管理，一旦会话中断，代理难以准确恢复任务状态。
  • 无法将复杂任务有效分解，完全依赖主代理的自我分解，缺乏结构化的计划。
  • 完成定义的评估完全依赖 Haiku 模型的主观判断，缺乏客观指标。

虽然 AI 代理在长期任务上有所改进，但原生 goal 命令在处理复杂工作流时暴露出重大缺陷。它没有知识库支持，唯一的真实来源是会话记录。当任务运行数小时导致上下文溢出或压缩时，代理性能显著下降。此外，它缺乏结构化分解，使得定义任务“完成”变得模糊且不可靠。

Goal Buddy 的工作流与代理架构

  • Goal Buddy 强制要求在本地读取和更新 state.yaml 状态文件。
  • 架构由三个专门代理组成：法官负责批判性审计，侦察兵负责任务映射，工人负责实际编辑。
  • 项目经理（PM）角色管理整个工作流，并拥有将任务标记为最终完成的权威。
  • 系统通过定义预言机将预期结果转化为程序可观察的信号。

Goal Buddy 旨在修复原生 goal 命令的缺失状态跟踪问题。它引入了三个代理角色：法官具备最高推理能力以做出决策，侦察兵映射活跃任务并提供证据，工人和唯一的编辑权限代理负责执行。工作流基于明确的任务意图和预言机基准，确保代理在开始前就知晓完成定义。

实际操作与任务执行

  • 通过 goal prep 命令初始化工作流，系统会主动询问问题以消除意图模糊。
  • state.yaml 文件记录了所有目标、规则、已分配的任务 ID 以及仪表板链接。
  • 工作流按片段（Fragment）分解任务，每个片段具有明确的允许文件、验证方式和停止条件。
  • 仪表板实时显示任务队列、当前活动代理及完成进度。

用户通过 goal prep 命令启动 Goal Buddy，系统会进行自我消歧以明确需求。工作流生成的 state.yaml 文件跟踪项目进度，并将任务分解为安全易验证的片段。代理在执行过程中按顺序处理任务，所有进度均可通过仪表板监控，确保了工作流的透明度和可控性。

性能评估与扩展应用

  • Goal Buddy 目前以顺序方式执行任务，尚未充分利用并行化能力。
  • 在处理不可程序化评估的 UI 设计任务时，该工具通过更详尽的意图澄清产出了更高质量的页面。
  • 相比简单提示，该工具虽然耗时较长，但最终产出更符合预期且结构清晰。

尽管目前仅支持顺序执行任务，但 Goal Buddy 在处理复杂应用程序时表现稳定。在 UI 生成测试中，对比原生 goal 命令生成的简单 HTML，Goal Buddy 通过预先确定技术栈和详细的预言机定义，产出了表现更好的前端页面。它将模糊的业务需求转化为了高质量的代码实现。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video