DeepSeek Harness 异步问答机制：超时、继续执行与延迟回答

DeepSeek Harness v0.2.0-rc.2 实验性加入 Timed User Questions。它要解决的是一个常见的长任务阻塞：Agent 提出问题后，即使仍有不依赖答案的工作，也必须停在原地等待用户。

Timed 模式把一次提问拆成两条结算路径：等待期内的回答继续走原有前台请求；超时后工具返回 pending，Agent 恢复执行，用户稍后的答案再作为持久 Follow-up 进入 Session。

Legacy 与 Timed 的区别

Timed 是显式选择，不会自动替换旧 schema。timeout: -1 仍走阻塞式等待，正整数才启用计时。

为什么需要“两次结算”

原有 Remote Event waterfall 只能结算一次。如果超时后仍让同一个请求活着，迟到回答会与已经返回给模型的 pending 结果竞争。DSH 因此在超时时结束前台请求，再由独立 RPC 接受迟到答案。

持久投影从 Session 中的 Tool Call 与 Tool Result 重建问题状态。pending 或结果未知的问题标记为“已继续但仍可回答”；答案真正准入为 user/message 后才算完成。

Client 接手与倒计时

Host 只在没有回答界面接手时运行 Deadline。Client 打开问题卡片后通过 attachWait 接手，并收到剩余时间。用户开始编辑或选择“慢慢回答”可以冻结本地倒计时；关闭面板不会伪造取消或回答。

本地点击提交并不等于 Host 已接收。若提交恰好与超时竞争，卡片会保留草稿，问题转为可重提状态，用户可以通过迟到回答通道再次提交。

迟到答案如何进入 Agent

接受的答案会带有 user-question-reply 来源、原 Tool Call ID、问题与答案，通过普通 User Message 进入 Inbox。Agent 已经结束当前等待后，答案会在后续步骤中被读取。重新打开冷 Session 时，Host 可以恢复根 Agent 并继续投递。

这意味着迟到答案不是“修改过去”。Agent 在等待期间已经完成的独立工作不会回滚；如果答案推翻了它采用的假设，后续步骤必须显式调整。

pending 不是授权

Timed 模式只适合仍有独立工作可做的问题，例如输出格式偏好、非关键命名或后续阶段选项。以下问题仍应阻塞：

• 删除、覆盖、发布或付款；
• 扩大权限和工作区范围；
• 两种选择会产生不同且不可逆的实现；
• 计划评审和必须由用户确认的安全边界。

没有回答只能表示“暂时未知”，不能表示同意默认选项。

使用建议

1. 先在非破坏性任务中启用 Timed 模式。
2. 把问题拆成“阻塞决策”和“可延迟偏好”。
3. 超时后只继续不依赖答案的步骤。
4. 在日志中保留 Tool Call ID，便于对应迟到回答。
5. 多客户端场景不要把某一设备上的“慢慢回答”视为全局暂停。
6. 检查答案最终是否准入，而不是只看本地提交动画。

参考资料

• DeepSeek Harness v0.2.0-rc.2 Release
• Timed user question two-settlement architecture
• Timed question source changes