从 Codex `/goal` 到 MateClaw Persistent Goal：AI 员工为什么需要“长期目标状态”

MateCloud微服务

384人浏览 · 2026-05-22 14:40:21

MateCloud微服务 · 2026-05-22 14:40:21 发布

OpenAI Codex CLI 官方 Slash Commands 文档里，/goal 的用途是“set, pause, resume, view, or clear a task goal”，也就是给 Codex 一个在较大任务运行期间持续跟踪的 persistent target。这个功能很小，但方向很大：AI Agent 不应该只回答当前这句话，而应该能在多轮里记住自己到底要完成什么。

在这里插入图片描述

1. `/goal` 背后的变化：从“问一句”到“交付一个目标”

过去我们使用 AI coding agent，大多是这样的：

帮我改这个文件
帮我解释这个函数
帮我修这个测试
帮我生成一个 PR 描述

这类任务通常是一轮或几轮对话就能完成。真正麻烦的是另一类任务：

把这个项目迁移到新框架，并保持测试通过
修复这个跨模块 bug，直到 CI 变绿
完成部署、健康检查、回滚预案和文档更新
调研资料、整理结论、生成报告，再补齐引用

这些任务不是“回答问题”，而是“持续推进”。它们需要：

一个清晰目标；
可验证的完成条件；
中途状态；
预算和停止规则；
进度评估；
必要时自动继续；
完成后留下记录。

Codex /goal 把这个方向说清楚了。官方文档将 /goal 列为 Codex CLI 内置 Slash Command，用来设置、暂停、恢复、查看或清除任务目标；用法包括 /goal <objective> 创建目标、/goal 查看当前目标、/goal pause/resume/clear 控制目标状态。官方文档还强调，Codex 会把 goal attached 到 active thread，让任务运行时持续跟踪它。

换句话说，/goal 不是普通 prompt，它更像一个“任务契约”。

2. MateClaw 为什么也做 Goal

MateClaw 的核心产品概念是“数字员工”。一个员工不应该只是被动回答消息，它应该知道：

我现在在做什么；
我为什么做这件事；
还差什么；
什么时候算完成；
什么时候应该停下来让用户决定；
这个任务完成后如何沉淀进记忆。

所以 MateClaw 最近一组提交集中在 persistent goal：

b8062410 docs: add user guide for the persistent-goal feature
e72e3f5c feat(goal,ui): inline set-goal prompt, terminal system-line, sidebar dot
5327b534 fix(goal,ui): wire evaluating halo, followup mark, dedupe system-line icon
08ea126f fix(goal): real evaluator, retry refactor, hardened node + extra edges
8222b6c8 fix(goal): emit goal_evaluated on every GoalEvaluationNode skip path
996a9319 fix(goal,ui): gate inline prompt by real long-task signal; soften copy
07de99cd fix(goal): give reasoning models enough budget for the evaluator JSON

这不是简单加一个“待办事项”。它把目标变成了 conversation 级状态。

3. MateClaw 的 Goal 长什么样

MateClaw 没有把 Goal 做成一个很重的弹窗，也没有让用户切到一个独立页面才能看见状态。

它的产品设计很克制：assistant 头像旁边的一圈光环。

在这里插入图片描述

这张本地截图里可以看到几个关键点：

会话中出现了 setGoal、addGoalCriterion、completeGoal 等工具调用结果；
目标完成后有轻量 system line 提示；
输入框上方有 “这件事要不要设成目标，我帮你跟着？” 的 inline prompt；
目标不是强打扰 banner，而是内嵌到聊天流和头像状态里。

MateClaw 文档里把它描述为：Goal 不是一个新的 tab，也不是 banner，而是员工的一种状态。你只要看到头像旁边的环，就知道这段对话有一个 active goal。

4. 后端：Goal 不是 prompt，而是数据库状态机

MateClaw 的 Goal 后端主要由几部分组成：

模块	作用
`GoalController`	REST 接口：创建、查询、暂停、恢复、放弃、追加准则、查看事件
`GoalManagementTool`	员工可调用的系统工具：`setGoal` / `addGoalCriterion` / `completeGoal` / `getGoalStatus`
`GoalServiceImpl`	状态机、预算、事件写入、审计、乐观锁
`GoalEvaluationService`	调 evaluator LLM 输出 `score/gap/completed`
`GoalEvaluationNode`	接在 ReAct / Plan-Execute 的终点后，做每轮目标评估
`GoalFollowupService`	判断是否要注入下一轮 follow-up prompt
`mate_agent_goal`	目标本体表
`mate_agent_goal_event`	目标事件追加日志

这说明 MateClaw 的 Goal 不是把“请记住目标”塞进 system prompt，而是落到了数据库和状态机里。

MateClaw Goal 状态机

V120__agent_goal.sql 里定义了两张表：

mate_agent_goal：保存 title、description、exitCriteria、status、turnBudget、llmCallBudget、进度分数、自动续跑配置等；
mate_agent_goal_event：追加记录 created、evaluated、followup_injected、completed、exhausted、paused、resumed、abandoned 等事件。

还有一个很重要的约束：一个 conversation 同一时刻最多一个 active goal。

MateClaw 没有靠前端判断，而是在 H2 / MySQL 迁移里用 generated column + unique index 保证并发安全。终态目标可以保留历史，但新的 active goal 不会和旧 active goal 冲突。

5. 四个系统工具：员工自己能管理目标

MateClaw 给员工暴露了四个内置工具：

工具	作用
`setGoal`	为当前 conversation 创建 persistent goal
`addGoalCriterion`	在不中断目标的情况下追加完成准则
`completeGoal`	显式标记目标完成
`getGoalStatus`	查询当前目标状态、进度、预算和 gap

例如用户可以直接说：

请立刻调用 setGoal 工具，title="部署博客到 fly.io"，turnBudget=10，autoFollowup=true。

这和 Codex /goal <objective> 的语义非常接近：用户给出一个长期目标，系统把它绑定到当前会话，并在后续运行中持续追踪。

但 MateClaw 多了一层企业化语义：这个 goal 绑定 conversation、agent、workspace、createdBy，并经过权限校验和审计记录。

6. 每轮回答之后，GoalEvaluationNode 接管

MateClaw 的一个关键设计是：评估发生在 final answer 已经发给用户之后。

也就是说，用户不会因为 evaluator 慢而看不到回答。

执行顺序大致是：

用户请求
→ 员工推理 / 计划 / 调工具
→ 产生 final answer
→ 用户先看到回答
→ GoalEvaluationNode 读取 active goal + 最近上下文 + final answer
→ GoalEvaluationService 调 evaluator 输出 JSON
→ GoalService 写入 progress / gap / event
→ 决定 completed / exhausted / continue / auto-followup

Evaluator 的输出很克制：

{
  "score": 0.0,
  "gap": "还缺少部署验证",
  "completed": false
}

score >= 0.95 或员工调用 completeGoal 时，目标进入 completed。预算耗尽时进入 exhausted。中间状态写入事件时间线。

7. Auto-followup：不是让模型失控，而是受预算约束地继续

长期任务最怕两种极端：

每一步都要用户催，AI 只是高级问答框；
AI 无限自循环，成本和风险不可控。

MateClaw 的 auto-followup 走中间路线。

GoalFollowupService 会同时检查：

autoFollowupEnabled 是否开启；
evaluator 是否判断 continue；
score 是否低于 0.95；
follow-up cooldown 是否满足；
turnBudget 是否还有空间；
agent + eval LLM 调用是否低于总预算的 90%。

满足条件才会注入下一条用户消息：

Continue working on the goal. Still missing: {gap}
Take the next concrete step.

这让员工表现得像“自己知道继续做下一步”，但又不会无限跑。

8. UI：低打扰，但状态明确

MateClaw UI 里主要有三个 Goal 组件：

GoalAvatarRing.vue：头像光环，显示 active / evaluating / completed / exhausted；
GoalSetInlinePrompt.vue：当系统判断这可能是长任务时，轻量询问是否设为目标；
GoalSystemLine.vue：目标完成或耗尽时，在消息流里插一条系统线。

它不是用大弹窗抢用户注意力，而是把目标状态藏在工作流本身：

active：橙色进度环；
evaluating：呼吸光晕；
completed：短暂绿色提示；
exhausted：红橙提示；
auto-followup：消息头像旁标记一个 ↻。

这点很重要。长期任务的 UI 不应该变成第二个项目管理系统，而应该让用户在聊天流里自然知道“它还在跟”。

9. 子员工不能改父目标：多 Agent 协作里的所有权边界

MateClaw 最近还加入了多层子员工委派树和 nested subagent timeline。Goal 和子员工协作之间有一个明确边界：

child agent 看不到 parent 的四个 goal 工具。

原因很简单：goal 是 parent conversation 的状态。子员工可以执行任务、返回结果，但不能擅自改父会话的目标。

这能避免多 Agent 并发时出现混乱：

子员工 A 认为完成了；
子员工 B 认为还没完成；
子员工 C 擅自改了 exitCriteria；
parent 会话不知道谁负责最终状态。

MateClaw 把目标所有权留在 parent，child 是执行体。这是企业级 multi-agent 系统必须有的边界感。

10. 和 Codex `/goal` 的关系：同一个方向，不同落点

Codex /goal 更偏开发者 CLI / IDE 里的长期 coding task：

给当前 thread 一个 persistent target；
支持查看、暂停、恢复、清除；
适合长时间编码任务；
和 Codex 的 permissions、sandbox、status、diff、review 等命令一起工作。

MateClaw Persistent Goal 的落点更偏企业 Agent OS：

goal 绑定数字员工、会话、工作区和用户；
目标状态进入数据库；
每轮 final answer 后有 evaluator；
有预算、事件、审计；
UI 有可见状态；
可以和 ReAct、Plan-and-Execute、多员工委派、Skill、Tool Guard、Channel 结合。

如果说 Codex /goal 是给 coding agent 一张“任务契约”，那么 MateClaw Goal 是把这张契约放进企业 Agent 运行时。

11. 为什么这件事值得关注

很多 Agent 产品还停留在：

模型 + 工具调用 = Agent

但真实工作里更需要：

目标 + 状态 + 评估 + 预算 + 续跑 + 留痕 = 可托付的 Agent

这就是 /goal 和 MateClaw Persistent Goal 共同指向的趋势。

Agent 不只是更会回答，而是开始拥有“持续工作”的状态。

MateClaw 的实现说明，一个企业级 AI 员工至少需要三层能力：

目标层：知道自己要完成什么；
执行层：能计划、调工具、委派子员工；
治理层：能预算、审批、审计、停止、恢复。

Goal 正好把这三层连起来。

结语

Codex /goal 让开发者看到一个新的交互范式：不要每轮重复上下文，把目标交给 Agent，让它围绕目标持续推进。

MateClaw 的 Persistent Goal 则把这个思路往企业场景推进了一步：

目标不是提示词，而是员工状态；不是一句话，而是运行时协议；不是靠记忆碰运气，而是靠状态机、评价器、预算和事件日志来承载。

这也是 MateClaw 最近这组 Goal 相关提交真正有价值的地方。

它让数字员工从“会聊天”继续往前走了一步：

开始记得自己到底在完成哪件事。

所有评论(0)

查看更多评论

MateCloud微服务

@bufegar0

已为社区贡献13条内容

从 Codex `/goal` 到 MateClaw Persistent Goal：AI 员工为什么需要“长期目标状态”

MateCloud微服务

1. /goal 背后的变化：从“问一句”到“交付一个目标”

2. MateClaw 为什么也做 Goal

3. MateClaw 的 Goal 长什么样

4. 后端：Goal 不是 prompt，而是数据库状态机

5. 四个系统工具：员工自己能管理目标

6. 每轮回答之后，GoalEvaluationNode 接管

7. Auto-followup：不是让模型失控，而是受预算约束地继续

8. UI：低打扰，但状态明确

9. 子员工不能改父目标：多 Agent 协作里的所有权边界

10. 和 Codex /goal 的关系：同一个方向，不同落点

11. 为什么这件事值得关注

结语

相关链接

所有评论(0)

温馨提示：您尚未绑定手机号

MateCloud微服务

1. `/goal` 背后的变化：从“问一句”到“交付一个目标”

10. 和 Codex `/goal` 的关系：同一个方向，不同落点