DeepSeek Harness 怎样把模型的一次回答变成可继续执行的任务
内容提要
本文以Java金额比较测试修复为例，介绍DeepSeek Harness如何将模型回答转化为可执行任务：流式工具调用需完整生成后才执行，避免半成品；工具可并行执行，但结果按模型顺序提交；Session通过surface索引决定模型可见消息，压缩时以摘要替换区间并保留原始日志；中断恢复区分“未开始”与“结果未知”，后者需先核对再重试。核心是形成可检查的执行闭环。
延伸解读
流式工具调用为何要等完整生成
文章指出，模型流式输出工具调用时，参数是分段到达的，前一块可能只有部分 JSON。Harness 选择等整个流结束后再执行工具，而不是一看到工具名和看似合法的片段就调用。这样做牺牲了一点延迟，但避免了执行参数不完整的半成品动作，也让“哪次模型输出触发了操作”有明确的因果记录。
并行执行不等于乱序提交
工具可以并行运行，但结果提交严格按模型给出的调用顺序。调度器只信任工具自身的并发安全声明，不会替工具分析业务冲突；提交时若前一个结果未就绪，后面的结果也要等待。这保证了日志和下一次模型上下文保持模型顺序，代价是慢调用可能造成队头等待。
Session 可见消息与原始日志分离
Harness 用 surface 索引决定模型下一次能看到哪些消息，而不是把整个事件日志原样塞给模型。压缩时，摘要节点替换选定区间，原始日志仍保留，审计可沿事件序号回溯。替换区间还会检查工具调用与结果是否配对，避免切断协议关系。压缩能省上下文，但会引入信息损失，也不减少原始日志存储。
中断恢复要区分“未开始”与“结果未知”
恢复时，若日志中没有调用开始记录，补 TOOL_NOT_STARTED，提示可重试；若已有开始记录但没有结果，补 TOOL_OUTCOME_UNKNOWN，要求先核对外部状态，尤其对可能有副作用的操作不要盲目重试。文章强调，这只基于已保存日志分类，不能保证外部操作恰好执行一次，文件系统变化与日志并不在同一事务中。
Q&A
DeepSeek Harness 为什么不在流式输出中一检测到工具调用就立即执行？
因为流式响应中工具调用的参数是分段到达的，可能只生成了半截 JSON。如果提前执行，可能使用不完整或错误的参数。Harness 会等待整个流结束，将完整的 assistant 消息（包括工具调用）先追加到 Session 日志，然后再启动工具执行，从而保证因果顺序和参数完整性。
DeepSeek Harness 如何保证并行工具调用的结果按模型给出的顺序提交？
调度器允许工具主体并行运行，但结果提交严格按模型调用顺序进行。它使用 slots 和 committed 指针：只有当前应提交位置的结果已就绪时才提交，即使后面的调用先完成也要等待，从而避免队头等待影响日志顺序。
Session 的 surface 索引在 DeepSeek Harness 中起什么作用？
surface 是当前模型可见消息的有序索引，指向原始事件日志。它决定下一次模型请求能看到哪些消息，例如用户消息、assistant 消息和配对的工具结果，而过滤掉 step/start 等内部运行事件。deriveMessages() 从 surface 推导消息，实现日志保留完整过程、模型只看到必要内容。
DeepSeek Harness 的压缩机制是如何工作的？会删除原始日志吗？
压缩插件将一段历史总结成较短的检查点消息，通过 surfaceOp: 'replace' 在 surface 中替换选定区间，并保留与原始事件的关联。原始日志不会被删除，只是模型下一次请求看到的是摘要加保留的近期历史，审计仍可回溯原始内容。压缩时会检查区间两端的工具调用与结果是否配对，避免切断协议关系。
任务中断后，DeepSeek Harness 如何区分“工具未开始”和“结果未知”？
恢复时检查日志中是否有 tool/call 记录：如果没有开始记录，则标记为 TOOL_NOT_STARTED，提示可以重试；如果已有开始记录但没有配对的 tool/result，则标记为 TOOL_OUTCOME_UNKNOWN，说明无法确认结果。对于结果未知的情况，只读或幂等操作才考虑直接重试，可能有副作用时需先核对外部状态再决定。
DeepSeek Harness 如何形成一个可检查的执行闭环？
闭环包括：模型提出动作后，Harness 形成消息并记录到 Session；执行器调度工具并记录实际结果；下一次请求从日志的可见索引重建消息，模型基于真实结果继续判断。关键设计包括流截断时不执行半成品调用、并发时保持结果顺序、历史过长时替换可见内容、中断时保留未知状态而不伪造成功。
