补齐深挖任务委托的灰度开关：design.md 承诺的"可一键关"未兑现 #61

New issue

Closed

opened 2026-07-24 09:00:46 +00:00 by KumaAgent · 0 comments

KumaAgent commented

2026-07-24 09:00:46 +00:00

Member

背景

docs/design.md"上线路线"第 5 阶段原文承诺深挖任务委托"灰度、可一键关"（ADR-0020）。issue #52 PRD → #53-#56（PR #57-#60）实现完成后核实 config.py/tools.py/__init__.py，确认 delegate_task/cancel_delegate_task 两个工具恒可见——不像自发目标那样复用渐进解锁曲线兜底（PR #59 的 review 明确记录了理由："深挖任务委托是用户显式请求触发，不适用'新部署更保守'的理由"），也没有任何专属 host 配置开关。这不是文档滞后，是实现期真实落下的缺口，已如实记录进 ADR-0020 2026-07-24 更新节/CONTEXT.md/design.md（用删除线标注，未兑现的承诺没有被悄悄改口抹平）。本 issue 补上这个开关本身。

期望行为

新增一个静态 config 开关（如 arise_delegate_enabled: bool = True，默认开启以保持现有行为不变——现状就是恒开启，改默认值会是破坏性变更）。为 false 时，delegate_task/cancel_delegate_task 两个工具的 schema 不出现在模型可见的工具列表里——同仓库既有的一贯哲学（能力/解锁位为假时模型"看不到"，不是"看到了调用失败"，参照 capabilities.poke_send、自发目标 is_spontaneous_goal_unlocked 门控 NOTE_PENDING_INTENT_SCHEMA 的既有先例）。

验收标准

新增静态 config 项（命名/默认值同"期望行为"一节），默认值保持现有恒开启行为不变，不是破坏性变更。
开关关闭时，_run_tool_loop 构造的工具列表里不出现 delegate_task/cancel_delegate_task 的 schema。
开关关闭本身不影响已经在跑的后台任务、或已经登记但还没被 _callback_scan 送回的待送回 Callback 记录——只影响"能不能发起新任务"，不做追溯性清理/取消存量状态（同能力位既有先例：能力关闭只影响新调用）。
补充测试：开关为假时工具列表确实不含这两个工具；开关状态不影响 Callback 送回管线（_callback_scan/run_callback()）本身的正常运作——已登记的待送回记录该送还是送。
文档回填（docs 分支）：CONTEXT.md/design.md/ADR-0020 里"⚠️ 未兑现"的措辞与删除线标注，改为"已补齐"并说明新增的 config 项名字。

Out of Scope

不做运行时热切换——config 变更需要重启生效，同仓库其余静态 config 项一致，不新开一条"运行时可调"的先例。
不做 per-chat 粒度的开关——只做全局 host 部署级别的一键关（"灰度、可一键关"原文语境就是部署者视角的开关，不是会话级）。
不重新评估"要不要用渐进解锁门控"这个已经在 PR #59 review 里拍板拒绝过的方案——本 issue 只补一个独立静态开关，不推翻已有决定。

## 背景 `docs/design.md`"上线路线"第 5 阶段原文承诺深挖任务委托"灰度、可一键关"（[ADR-0020](../docs/adr/0020-deep-task-delegation.md)）。issue #52 PRD → #53-#56（PR #57-#60）实现完成后核实 `config.py`/`tools.py`/`__init__.py`，确认 `delegate_task`/`cancel_delegate_task` 两个工具**恒可见**——不像自发目标那样复用渐进解锁曲线兜底（PR #59 的 review 明确记录了理由："深挖任务委托是用户显式请求触发，不适用'新部署更保守'的理由"），也没有任何专属 host 配置开关。这不是文档滞后，是实现期真实落下的缺口，已如实记录进 [ADR-0020 2026-07-24 更新节](../docs/adr/0020-deep-task-delegation.md)/CONTEXT.md/design.md（用删除线标注，未兑现的承诺没有被悄悄改口抹平）。本 issue 补上这个开关本身。 ## 期望行为新增一个静态 config 开关（如 `arise_delegate_enabled: bool = True`，默认开启以保持现有行为不变——现状就是恒开启，改默认值会是破坏性变更）。为 `false` 时，`delegate_task`/`cancel_delegate_task` 两个工具的 schema 不出现在模型可见的工具列表里——同仓库既有的一贯哲学（能力/解锁位为假时模型"看不到"，不是"看到了调用失败"，参照 `capabilities.poke_send`、自发目标 `is_spontaneous_goal_unlocked` 门控 `NOTE_PENDING_INTENT_SCHEMA` 的既有先例）。 ## 验收标准 1. 新增静态 config 项（命名/默认值同"期望行为"一节），默认值保持现有恒开启行为不变，不是破坏性变更。 2. 开关关闭时，`_run_tool_loop` 构造的工具列表里不出现 `delegate_task`/`cancel_delegate_task` 的 schema。 3. 开关关闭本身不影响已经在跑的后台任务、或已经登记但还没被 `_callback_scan` 送回的待送回 Callback 记录——只影响"能不能发起新任务"，不做追溯性清理/取消存量状态（同能力位既有先例：能力关闭只影响新调用）。 4. 补充测试：开关为假时工具列表确实不含这两个工具；开关状态不影响 Callback 送回管线（`_callback_scan`/`run_callback()`）本身的正常运作——已登记的待送回记录该送还是送。 5. 文档回填（`docs` 分支）：CONTEXT.md/design.md/ADR-0020 里"⚠️ 未兑现"的措辞与删除线标注，改为"已补齐"并说明新增的 config 项名字。 ## Out of Scope - 不做运行时热切换——config 变更需要重启生效，同仓库其余静态 config 项一致，不新开一条"运行时可调"的先例。 - 不做 per-chat 粒度的开关——只做全局 host 部署级别的一键关（"灰度、可一键关"原文语境就是部署者视角的开关，不是会话级）。 - 不重新评估"要不要用渐进解锁门控"这个已经在 PR #59 review 里拍板拒绝过的方案——本 issue 只补一个独立静态开关，不推翻已有决定。

KumaAgent added the

状态：智能体就绪

label

2026-07-24 09:01:28 +00:00

KumaAgent referenced this issue

2026-07-24 09:10:32 +00:00

[PRD] arise register_callback（用户设到点提醒）落地 #62