两种Harness设计哲学——Claude Code的单体循环 vs DeepSeek Harness的微内核，以及我们的底座会怎么选
从去年研究 Claude Code，到这两个月追着 DeepSeek Harness 读文档，两套 harness 我都拆得差不多了。它们解决的是同一组问题，给出的答案却经常截然相反。作为 dsh 系列的最后一篇，把两者放在一起对比一下，也说说如果重做我们的底座，我会怎么选。
子代理与长任务——DeepSeek Harness的Session与Activation，Plan、Goal、Jobs为什么都只是插件
回头看我们线上最难查的两个问题，都和「长流程」有关：一个是首聊导览里，模型嘴上答应了却不执行；另一个是一次失败被写进了记忆，Agent 从此对这件事永久拒答。带着这两个问题去读 DeepSeek Harness 的子代理和长任务设计，答案其实就藏在它反复强调的两条原则里。这是 dsh 系列的第六篇。
Agent的取消与错误恢复——DeepSeek Harness的一次调用一次尝试，以及等待静止而不是竞速抛弃
做语音陪伴产品，取消是家常便饭：用户一张嘴，Agent 就得立刻闭嘴。可「停下来」远比看起来难，停不干净会留下迟到的旧消息、泄漏的连接；重试也一样，叠两层重试就成了重试风暴。DeepSeek Harness 在取消和重试上的设计非常克制，这是 dsh 系列的第五篇。
工具调用为什么要走管线——DeepSeek Harness的单调守卫、并行调用的fail closed与大输出spill
我们的底座里，自己写的 function calling 和 MCP 接进来的工具走的是同一条管线。但线上还是踩过两个和工具有关的坑：一个是工具缓存掩盖了真实的重试，一个是 few-shot 示例和 schema 对不上导致衔接失效。带着这两个坑去读 DeepSeek Harness 的工具管线，发现它对「工具」的边界划得非常清楚。