从 Loop Engineering 看 MateClaw Goal：不要再手动追问 Agent，让系统自己推进

原创于 2026-06-17 06:09:08 发布 · 340 阅读

5 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#MateClaw #Loop #harness #Goal #AI Agent

AIAGENT 专栏收录该内容

19 篇文章

订阅专栏

在这里插入图片描述

最近 AI Coding 圈里有一个词很热：Loop Engineering。

这个词不是在说“写一个 while 循环”，也不是把 prompt 包进脚本里反复调用。更准确地说，它讨论的是：当 Agent 已经能执行任务、调用工具、修改代码、读取系统状态之后，人的工作不再只是“写下一条 prompt”，而是设计一个能持续推动 Agent 的系统。

Addy Osmani 在 2026 年 6 月的文章《Loop Engineering》里把它讲得很直白：过去我们自己一轮一轮提示 Agent，现在要设计一个系统来替我们提示 Agent。这个 loop 需要目标、定时或触发机制、工作隔离、技能、工具连接、子 Agent，以及能保存“做完什么、接下来做什么”的状态。

这和过去的 Prompt Engineering 有本质区别。

Prompt Engineering 关心的是：

这一轮怎么问，才能让模型答得更好？

Loop Engineering 关心的是：

如何让 Agent 在目标未完成时继续推进，
在完成时停下来，
在不确定时验证，
在失控前耗尽预算？

这个问题很适合拿 MateClaw 的 Goal 系统来分析。因为 Goal 本质上就是把“人每轮追问”变成“运行时自动推进”的一层状态机制。

1. Loop Engineering 的关键，不是“自动运行”

很多人看到 loop，第一反应是定时任务、cron、后台脚本。

但这只是最表层。

真正难的是这几个问题：

Agent 怎么知道自己在做同一个长期目标？
它怎么判断这轮有没有推进？
它怎么知道还差哪几项？
它什么时候应该继续，什么时候应该停止？
它继续执行时，下一轮 prompt 从哪里来？
它跑太久、太贵、太偏时，系统怎么兜住？

如果没有这些约束，loop 很容易变成“自动烧 token 的 prompt 重试器”。

所以 Loop Engineering 更接近一套 Agent Runtime 设计，而不是一个 prompt 技巧。

2. MateClaw Goal：把目标变成员工的运行状态

MateClaw 里的 Goal 不是聊天窗口里的一个标签，也不是简单的待办事项。

它更像数字员工的一种运行状态。

用户说一个长期任务时，可以要求员工调用 setGoal，把目标锁进当前 conversation。一个 goal 至少包含：

字段	作用
title	目标短标题，用于 UI 展示
description	完整任务描述
exitCriteria	LLM 可读的退出判据
turnBudget	最多允许执行多少轮
llmCallBudget	最多允许消耗多少次 LLM 调用
autoFollowupEnabled	未完成时是否自动继续

从 Loop Engineering 角度看，这一步非常关键：先把“我要做什么”从一次性 prompt 里拿出来，变成可持久化、可评估、可恢复的状态。

没有这个状态，Agent 每一轮都像重新开始。用户也只能不断提醒它：“刚才那个任务继续做”“你还差测试没跑”“别忘了最后要写文档”。

Goal 的意义就是把这些提醒交给系统。

在这里插入图片描述

3. 从完成度分数到 Checklist：Loop 必须有可验证准则

早期很多 Agent 会用一个完成度分数表示任务进展，比如 0.7、0.8。

这个分数看起来有用，但在真实任务里很模糊：

0.8 是什么完成了？
还差哪一步？
是部署没做，还是测试没过？
下一轮应该继续做什么？

MateClaw v1.5.0 把 Goal 推进成 checklist 机制：目标会被拆成一组可以逐条验证的准则。

Evaluator 有两种模式：

模式	作用
bootstrap	目标还没有准则时，把目标拆成 checklist
verdict	已有 checklist 时，逐条判断是否通过

完成判定也变得确定：只有所有准则都通过，Goal 才算完成。

这很像 Loop Engineering 的“done condition”。一个 loop 如果没有明确退出条件，就无法稳定运行。它要么太早结束，要么一直继续。Checklist 的价值不是 UI 好看，而是把“完成”从一句主观判断变成可验证对象。

在这里插入图片描述

4. Final Answer 之后再评估：不阻塞用户，但更新状态

MateClaw 的 GoalEvaluationNode 不是在回答前挡住用户。

它的设计是：员工这一轮 final answer 已经流式输出给用户后，后台再跑评估节点。评估节点读取当前目标、最近上下文和这轮最终回答，然后调用 evaluator 判断：

哪些 checklist 已通过；
哪些还没通过；
是否继续；
是否完成；
是否耗尽预算。

这点很重要。

很多 Agent 系统把“生成答案”和“判断答案”混在一起，结果模型很容易自己给自己打高分。Loop Engineering 里更稳的做法，是把执行者和评估者拆开。MateClaw 这里虽然仍然可以使用 LLM evaluator，但它通过单独的 GoalEvaluationService、结构化输出和事件记录，把“做事”和“判定”拆成两个阶段。

这就是 loop 的反馈环：

Agent 执行
  -> 输出结果
  -> evaluator 判断
  -> 写入 goal event
  -> 决定完成 / 继续 / 停止

5. autoFollowup：系统替用户发起下一轮

Loop Engineering 最核心的一步，是让系统替人推进下一轮。

MateClaw 的 GoalFollowupService 做的就是这件事。

当 evaluator 判断目标还没完成，并且 autoFollowupEnabled=true 时，系统会生成一条 follow-up prompt，追加到对话末尾，让员工重新进入执行图。

如果目标已有 checklist，follow-up 不会只说一句“继续”。它会明确列出剩余未通过的准则，例如：

5/8 criteria passed. Remaining:
- C6 ...
- C7 ...
Take the next concrete step on the remaining criteria.

这和人工追问的区别很大。

人工追问经常是模糊的：“继续做”。系统追问可以带上当前状态：“还差 C6 和 C7，优先处理剩余准则”。这才是 loop 能持续推进的原因。

6. Budget：Loop 不能无限跑

Loop Engineering 另一个现实问题是成本。

Addy Osmani 在 Loop Engineering 文章里也提醒，自动循环很早期，而且必须注意 token cost。这个提醒很实际。因为 loop 一旦能自己继续，就意味着它也能自己持续消耗。

MateClaw Goal 里有两个预算：

turnsUsed >= turnBudget
或
agentLlmCallsUsed + evalLlmCallsUsed >= llmCallBudget

任一条件触发，目标进入 exhausted，不再继续评估和自动 follow-up。

这让 loop 从“自动执行”变成“有边界的自动执行”。企业落地时，这个边界非常重要。否则 Agent 不是员工，而是一个没有工时限制、没有预算意识、没有停止条件的后台进程。

7. 事件时间线：Loop 必须可观察

一个能自己推进的 loop，如果没有事件记录，就很难进入生产。

MateClaw 为 Goal 设计了事件时间线，比如：

created
evaluated
followup_injected
criterion_added
completed
exhausted
abandoned

这让每个目标的运行过程可以被追踪：什么时候创建、什么时候评估、为什么继续、为什么完成、为什么耗尽预算。

从工程角度看，事件时间线比“最终回答”更重要。因为 Agent 一旦进入长期任务，它的价值不只是最后说了什么，还包括中间怎么判断、怎么推进、怎么停止。

在这里插入图片描述

8. Memory：Loop 结束后要留下东西

Loop Engineering 里还有一个容易被忽略的点：loop 需要外部状态。

模型上下文本身不是可靠记忆。长任务跑完后，如果结果只存在一次会话回答里，后续 Agent 很难复用。

MateClaw 的 Goal 在完成时会把总结同步到长期记忆。这样一个 loop 的产物就不只是“这一轮回答”，而是能进入后续对话和员工记忆系统。

这对企业场景很关键。

例如：

一次部署问题排查完成后，沉淀成运维经验；
一次客户需求分析完成后，沉淀成客户偏好；
一次项目重构完成后，沉淀成团队知识；
一次流程执行完成后，沉淀成可复用 SOP。

Loop 如果不沉淀，就只是自动化。Loop 能沉淀，才开始像组织能力。

9. MateClaw 里的五层 Loop 结构

在这里插入图片描述

把 MateClaw Goal 拆开看，它对应了 Loop Engineering 的五层结构：

Loop 层	MateClaw 对应实现	解决的问题
目标层	GoalEntity / setGoal / exitCriteria	明确 loop 为什么运行
执行层	ReAct / Plan-and-Execute / 工具调用	让 Agent 能采取行动
评估层	GoalEvaluationService / checklist verdict	判断是否完成
循环层	GoalFollowupService / followup_injected	未完成时继续推进
治理层	budget / events / terminal status / memory	控制成本、审计过程、沉淀结果

这个结构说明一件事：Loop Engineering 不是单点功能，而是 Runtime 能力。

只有 goal，没有 evaluator，会变成待办事项。

只有 evaluator，没有 auto-followup，会变成事后评分。

只有 auto-followup，没有 budget，会变成失控循环。

只有 budget，没有事件时间线，出了问题也很难复盘。

这些东西合在一起，才是一个能在企业里跑的 Agent loop。

10. 和 Codex / Claude Code 的 `/goal` 思路有什么关系

Addy Osmani 在文章里提到，Codex 和 Claude Code 都开始出现 /goal、/loop、scheduled task、hooks、skills、worktrees、subagents 这类能力。

这些能力背后的共识是一样的：Agent 不再只是“你问我答”的聊天框，而是一个可以被循环驱动的执行体。

MateClaw 的差异在于，它不是只围绕代码仓库，而是按企业 Agent Runtime 来组织：

数字员工有 Role / Goal / Backstory；
Goal 是 conversation 级运行状态；
evaluator 和 follow-up 接入 StateGraph；
工具调用、MCP、Skills、审批、审计可以放进同一套执行链；
Web Console、Desktop、IM Channels 等入口可以共享同一类目标管理逻辑。

也就是说，MateClaw 不是把 Loop Engineering 做成一个命令，而是把它放进企业数字员工系统里。

11. 我的理解：Prompt 仍然重要，但 Prompt 不再是系统边界

Loop Engineering 并不是说 prompt 不重要。

相反，好的 loop 仍然依赖好的 prompt。只是 prompt 的位置变了。

以前 prompt 是系统本身。你写得好，结果就好；你停下，Agent 也停下。

现在 prompt 更像 loop 里的一个部件：

初始 prompt 定义目标；
evaluator prompt 定义判断标准；
follow-up prompt 推动下一步；
skill prompt 固化项目经验；
system prompt 约束角色和工具边界。

真正的系统边界变成：状态、准则、工具、预算、事件、记忆。

这也是为什么 MateClaw Goal 值得单独看。它没有停留在“让 Agent 多回答几轮”，而是把多轮推进拆成了工程对象。

结语

如果说 Prompt Engineering 是“怎样和模型说话”，那么 Loop Engineering 更像是“怎样设计一个能持续工作的 Agent 系统”。

这个系统要有目标，要有执行，要有验证，要能继续，也要能停止。它还要留下事件、记忆和审计线索。

MateClaw Goal 的实现说明了一个方向：企业 Agent 的关键能力，不是把聊天框做得更像人，而是把目标、执行、评估、预算和记忆串成一个可运行的闭环。

未来强模型会继续变强，但真正决定企业 Agent 是否可用的，可能不是某一次回答有多聪明，而是这个 loop 是否足够清楚、可控、可复盘。

摘要

本文从 Loop Engineering 的概念出发，分析 MateClaw Goal 如何把“人手动追问 Agent”变成可持久、可评估、可预算、可停止的运行时闭环。文章结合 checklist、GoalEvaluation、autoFollowup、事件时间线和长期记忆，说明企业 Agent 真正需要的不只是好 prompt，而是能持续推进并受控退出的 loop。