[Feedback] update_goal 占位参数约定不明确，模型完成 Goal 时容易反复调用失败

[SWQXDBA]

问题概述

一次实际长任务会话中，模型已经完成业务任务，但调用 update_goal(action="complete") 关闭 Goal 时，反复携带仅适用于 edit 的参数，导致多次失败。

模型误调用是直接原因；希望反馈的是：工具参数说明与错误提示缺少明确的占位值约定，容易使模型误调用后继续重复失败，增加无效轮次与用户干预成本。

环境与观察范围

• macOS，DeepSeek Harness 桌面应用 / Web GUI；本次会话为 Codex / GPT 模型工具调用环境。
• 应用版本号未记录。依据为实际工具返回，以及安装包内 @deepseek-ai/dsh-tool-goal 执行器的只读检查。
• 未验证其他模型或版本的发生频率，未完整追踪 provider adapter 的 Schema 转换链路。

失败调用

在 active Goal、业务任务完成且 revision 有效的前提下，模型提交了类似参数（Goal ID 已匿名化）：

{
  "action": "complete",
  "blocked_reason": "",
  "goal_id": "<existing-goal-id>",
  "max_goal_rounds": 16,
  "objective": "",
  "revision": 2
}

返回：

objective and max_goal_rounds are valid only with action edit

16 是当前 Goal 的轮次上限。模型错误地把当前值当成可以随调用携带的参数。收到错误后仍多次提交同类参数，并一度错误判断为严格 Schema 阻止关闭操作。最终需要读取实现才能修正调用。

错误信息准确指出了字段限制，但在本次会话中未能帮助模型有效自我恢复。

成功调用

改用执行器支持的占位值后成功：

{
  "action": "complete",
  "blocked_reason": "",
  "goal_id": "<existing-goal-id>",
  "max_goal_rounds": 0,
  "objective": "",
  "revision": 2
}

实际返回 phase: "complete"、activation: "disarmed"、revision: 3；原 maxGoalRounds: 16 保持不变。

Goal 完成状态迁移在本次会话中能正常执行，问题集中在模型可见参数契约及误调用后的恢复体验。

实现观察

安装包中的 dsh-tool-goal 执行器已有如下语义：

function hasText(value) {
  return value !== void 0 && value !== "";
}
function hasRoundCap(value) {
  return value !== void 0 && value !== 0;
}

空字符串与 0 可作为未提供字段的占位值。但本次模型可见的参数说明仅强调 objective / max_goal_rounds 适用于 edit，未说明在需要补齐参数的工具调用环境中应填 "" / 0。

以上为安装包实现观察；未验证当前仓库 HEAD 或所有 provider 的 Schema 适配行为。

改进建议

1. 字段说明明确占位约定：非 edit 操作省略 objective / max_goal_rounds；若 Schema 要求填充，则使用 objective: ""、max_goal_rounds: 0。非 blocked 的 blocked_reason 同理。
2. 提供按 action 的最小调用示例，尤其是 complete，避免模型复制当前 Goal 的 cap 和 objective。
3. 校验错误携带直接修复提示，例如：For action complete, omit objective and max_goal_rounds; if required by your tool schema, use objective="" and max_goal_rounds=0. 状态未变时可说明 Goal 仍为 active。
4. 检查严格 Schema 适配后的模型可见契约是否与 optional / sentinel 语义一致；条件允许时考虑按 action 区分 Schema 或拆分操作。
5. 补充回归测试：覆盖省略可选字段、空值占位、非零 cap 被拒绝且错误可操作，以及误调用后能正确重试的集成场景。

希望作为工具调用可用性 / model recovery 问题处理，降低长任务完成后陷入无效 Goal 调用循环的概率。

[Vsonic12138]

补充一份量化数据支持这个反馈，并补两点原帖未覆盖的情况。

规模（本机 123 个会话的全量工具调用统计，DSH Desktop 0.2.0-rc.2）

指标	值
update_goal 调用	64
失败	38（59%）
使用过 update_goal 的会话	14
至少失败一次的会话	14（100%）
最差会话	8 次调用 8 次失败
失败的 action 分布	complete 21、resume 17
失败调用携带的 max_goal_rounds	8（21 次）、30（14 次）、6（3 次）——都是该 Goal 当前的真实上限
成功调用携带的 max_goal_rounds	0（26 次，全部）

也就是说：在这份样本里，complete / resume 唯一能通过的是 max_goal_rounds: 0（或省略）；模型只要把 get_goal 里看到的上限原样回填，就是 100% 失败。

补充 1：resume 同样中招，占 38 次失败中的 17 次

原帖只提到 complete。resume 走另一条分支，报错文案更长：

objective and max_goal_rounds are valid only with action edit; blocked_reason is valid only with action blocked

本机 17 次 resume 失败全部是这一条。失败调用的参数构成：26/38 是「objective 为空、只回填了正数 max_goal_rounds」，另 12/38 还带了 objective 正文。

补充 2：真正的触发点是不对称的校验

你在帖子里引用的两个谓词正好说明了这一点：

function hasText(value)     { return value !== undefined && value !== "" }
function hasRoundCap(value) { return value !== undefined && value !== 0 }

两个字符串字段传 "" 会被当成"未提供"而放行，数值字段只要非 0 就直接判死。于是同一个「把 schema 里声明过的参数全部填充」的模型行为，在 objective / blocked_reason 上无害、在 max_goal_rounds 上致命——而 get_goal 返回的 maxGoalRounds 恰恰是模型最容易顺手回填的那个值。

同类问题（另一个工具，已单独反馈）

subagent 的 provider / model / reasoning_effort 也是「schema 声明 + 仅部分场景适用」的可选参数，传空字符串即硬报错：本机 117 次委派中 27 次失败，单个会话 14/14 全失败 —— #9662。

两处的共同点：模型会填充所有声明过的可选参数，而执行器对"不适用但已提供"的字段选择报错而不是忽略；并且报错都不含"该怎么改"，模型只能盲试。

建议（都属低成本）

1. 非 edit action 时忽略 objective / max_goal_rounds：它们在该 action 下没有意义，也谈不上危险输入。若坚持报错，至少把契约写进错误信息——本 action 下请省略该字段或传 0。
2. 报错点名「当前 action + 被拒绝的字段 + 正确写法」，让模型能一轮自纠。本机那个 8/8 全失败的会话说明现状下它做不到。