# 聊天 Goal

Goal 让目标跨普通聊天轮次保持有效。当前 agent 使用会话的工具、模型、权限和历史执行任务。一次聊天成功结束后，runtime 为仍 active 的 Goal 发起下一轮普通聊天。完成候选使用独立的只读验收轮次；普通工作轮次不会每轮运行 judge。聊天模式不嵌套工作 agent。

## 开始与规划

输入 `/goal <目标>`，或使用 **Programs → Workflow → goal → Use**。表单启动聊天 Goal，不执行 Python Workflow。也可以明确要求 agent 创建 Goal。

agent 使用 `todo_create`、`todo_update` 和 `todo_list` 维护多步骤工作计划。Goal 工作期间创建的 todo 关联目标及其 revision。todo 修改成功后，Goal 详情刷新计划进度，回合结束时再次核对。进度通知失败不会撤销已经保存的 todo。目标独立于计划保存：全部勾选不能单独证明目标已完成。

agent 调用 `update_goal(status="complete")` 前，必须用当前实际证据核实每项要求。这个短操作只提交候选，不直接把 Goal 标记为已完成。关联 todo 尚未完成时拒绝提交；全部完成的 todo 计划也会触发一次验收，同一计划不会反复自动触发。简单目标不必为了形式创建 todo。

标记显示“验收中”时，独立的普通聊天轮次逐项检查原目标和 todo 要求。仅提供受信的内置检查工具，并继续遵循原有权限。shell、写操作和 Goal 修改工具不会提供给验收轮次。需要执行测试或查询外部系统时，验收返回缺少的证据，由工作 agent 在正常权限和预算下补充。

验收必须返回逐项判断和已记录的证据引用。成功读取保存文件内容摘要，会话证据和验收回复也保存摘要。标记已完成前，runtime 重新检查目标要求、用户控制版本、todo、未结束执行、未知效果及引用证据。暂停、编辑、取消、新用户要求和证据变化都会阻止过期成功。缺证据时返回普通工作，执行失败则保留可恢复状态。语义验收仍是独立模型判断，不保证绝对正确；完成描述核实时的结果，不会自动开始持续监控。

## 控制执行

页面重载后，Goal 详情保留目标、状态、用量和进度。没有 todo 时，标记和详情省略待办进度，不显示占位文字，保留 Goal 状态。通过普通聊天输入补充要求，遵循已有排队或插入当前执行的选择。

- `/goal`：读取当前状态。
- `/goal pause`：保存暂停状态，并请求取消当前执行。
- `/goal resume`：恢复暂停目标，继续累计用量。
- `/goal verify`：对最近已结束的工作独立验收，不直接标记目标已完成。
- `/goal edit <目标>`：保存新 revision 并暂停，准备好后显式恢复。
- `/goal clear`：取消目标。
- `/goal budget max_turns=10 max_tokens=10000`：修改上限，零表示移除对应上限。

Goal 默认不限制执行轮数。只有显式设置正数 `goal.max_turns` 或启动时轮数预算才有上限；达到上限不表示完成。进度标记显示 todo 完成情况，不显示执行轮数。已有 Goal 保留保存的预算，可用 `/goal budget max_turns=0` 移除旧轮数上限，不重置工作或用量。显式 token、active-time 和成本限制按累计用量计算。预算耗尽后必须先增加或移除上限才能恢复。等待时间不计入执行时间。自动续轮不会扩大工具权限。

执行失败或取消后停止自动续轮。worker 重启本身不再暂停聊天 Goal：兼容的检查点按自动恢复策略继续，停机时已成功结束的轮次保留持久续轮通知。普通聊天的执行者退出后，即使有未知外部结果，也可以使用独立的受限轮次继续，而不重放旧工具调用。用户暂停、取消、预算耗尽和显式恢复限制仍然阻止自动工作。旧的可恢复暂停状态及缺少已保存恢复来源的 Goal 仍需显式 Resume。通用外部事件唤醒仍是恢复限制。等待或尚未结束的执行不代表目标完成。

`create_goal`、`get_goal` 和 `update_goal` 是短时间的状态操作，不负责执行任务。只有同一个已核实阻塞连续出现至少三轮，且没有独立工作可做时，agent 才能标记 `blocked`。runtime 校验最低轮数；是否为同一个阻塞由 agent 根据证据判断。

## 恢复与计量

内部验收轮次不作为助手回复显示。开始、执行、暂停和验收过程中不增加聊天卡片。Goal 结束时，仅在对应位置保留一个小卡片；点击复用原有 Goal 详情窗口，查看该目标保存的结果、进度和用量。历史详情只读，新目标不会覆盖旧卡片的记录。正常 agent 回复和原始证据保持不变。

Goal 详情使用后端当前返回的操作条件。Resume 或 Verify 不可用时显示未满足的条件；刷新状态可重试读取，保留目标和未保存草稿。旧操作结果未知时，End 仍可结束 Goal 意图。未确认操作显示已保存的 ID、工具名、时间和状态；查看执行详情会打开该条执行及其待答审批或问题，不跳到无关的活动选择。

Verify 使用自动完成候选所用的独立普通验收轮次，需要已有结束的工作、关联待办完成、预算可用且没有未确认的相关工作。属于此 Goal 的后台进程仍在运行或结果未知时不能验收，无关资源不会阻止验收。暂停、取消、版本变化和重复请求不能绕过这些条件。

执行时间保留重启前已观察到的工作，不计入离线时段。worker 突然退出时，最后一次持久心跳提供时间下限，之后无法观察的时段显示为未知，不按零处理。迟到用量回执不会重新启动暂停目标的计时。用户显式设置执行时间上限时，未知时段导致无法核实上限便停止新工作；移除该可选上限后可以继续，不增加默认时间或轮数上限。

Goal 区分“旧执行已结束”和“允许开始新聊天”。普通聊天已无执行者、活动子任务和待回答问题时，Resume 可以结束旧的中断轮次，并开始受限的检查轮次。未知效果仍保持未知；Resume 和此前未确认的停止都不声称外部操作已取消。新轮次使用持久身份，避免在创建执行与保存 Goal 之间崩溃后重复创建轮次。检查点不兼容时开始新聊天；临时启动错误或凭据错误不会触发该处理。仅模型请求中断的后台 Job 保留原始输入和资源授权。子任务有未知效果时仍需要检查，不自动重放。Todo 完成不代表目标通过验收。

Provider 请求会修复不完整的工具调用历史，不改写已保存记录。缺失的结果以明确的“结果未知”错误占位补齐，包括历史末尾的调用。已有真实输出优先于占位，重复输出合并并与原调用配对；中断回复的文字保留并明确标注中断。无法配对的工具结果协议项仍保留在历史中，但不发送给 provider。此修复不证明操作失败、不授权重试，也不解除执行恢复限制。

已失去执行者的中断执行仍有外部结果未知时，同一会话的新操作需要针对本次操作的单次审批，bypass 模式和既有 allow 规则也不能免除。真正的内置文件核查工具（`read`、`grep`、`glob`、`list`）可按原有权限读取状态；自定义工具仅使用相同名称不会获得只读信任。审批列出此前结果未知的操作及新操作；未知操作集合改变后必须重新审批。批准不把旧操作标为成功或失败，非交互任务不能批准新副作用。此权限检查同样适用于重启后的新聊天轮次。

聊天 provider 请求在发出前固定 Goal 身份、revision 和价格。最终用量回执即使在暂停或编辑后返回，也计入原 Goal；创建新 Goal 不会把旧请求费用转给新目标。重复回执不重复计费。已发出但缺少用量回执的请求保留为未知，不视为免费。详情同时显示已知小计和未知请求数量。重启后可从账本重建统计，不重新发送 provider 请求。

旧游标统计在下一次归属明确的请求前保留为历史小计，不猜测历史请求的 Goal 身份。计量失败显示未知而不是零。流式部分计数是累计下限，不是额外费用；重复快照不相加，最终回执替换部分小计。

活动 Goal 创建的后台 Job 持久保存其归属，包括后续子任务和跨会话调用。目标会话中无关的 Goal 不承担费用；没有保存归属的存量 Job 保持未归属。Goal 和 Job 的预留额度在同一个计量事务中开始和结算；重启后可以使用已保存回执完成结算，不重复请求。token 或价格信息缺失时，分别保留对应的预留额度。

预算仍是可选设置。显式 token 或费用限额在取凭据、调用 provider 前预留保守额度，并发请求共享同一 Goal 限额，发送前再次检查。token 限额可以降低 provider 的输出上限。请求无法可靠估算、价格未知或服务档位未定价时，不能绕过硬限额；Goal 暂停或显示预算耗尽。尚未发送的预留过期后不能再发送；已经发送的请求不会因时间经过而被视为免费。这些约束要求经过审计的 provider 适配器，不承诺控制未经审计的外部计费行为。

## Python Workflow 兼容

聊天表单保留显式的轮数、token、活跃时间和费用限额；独立 Workflow 角色参数和隔离上下文会明确报错，聊天工作应通过会话设置配置。Rich REPL 的 `/goal` 启动普通 canonical chat，并显示 execution ID。

直接 Python 调用和组合 Workflow 中的 `goal()` 保留已有 work/refinement/judge 合同。这个兼容路径与聊天 Goal 分开，仍接受 `context_mode`、work/judge 模型设置和执行上限。聊天模式使用会话工作模型，不使用单独角色设置。

迁移及实现证据见[工程设计](../reference/design/runtime/goal-and-recovery.zh.html)。