先理解它是什么。
DeepSeek Harness（dsh）是 DeepSeek 开源的 Agent 运行系统。其 MIT 许可代码采用基于 Cordis 的插件组合方式：默认循环、模型连接、工具、会话等都有明确的替换位置。本文研究这一设计如何影响产品能力与用户控制。
研究对象是开发者预览版。官方说明它仍快速变化、尚未安全审计；本文没有运行厂商软件或做性能对测。以下业务任务和实验均为教学推演。[官方定位] [预览边界]
贯穿任务：把十份访谈变成有依据的产品建议。
读授权目录中的访谈，找出共同问题和反例，给每个结论标出原文位置，保存内部草稿。外部发布需要授权。完成标准是材料覆盖、引用可追溯、文件已保存；不是只生成一段像报告的文字。
- 目标范围与完成证据
- 输入材料与任务状态
- 判断与行动模型、工具、权限
- 反馈结果、失败与纠偏
- 交付文件、引用与验收
本站教学简图。判断与行动会循环；这五项并非 DeepSeek 的官方五层架构。
01 / 先把“换模型”之外的选择看见。
一套 Agent，可以怎样被重新组合？
把十份访谈放进一个目录，让 AI 找出共同问题并给出原文证据。它可能需要读文件、提取片段、归纳结论、保存报告。模型负责判断；文件访问、会话记录、工具执行和输出方式由运行系统组织。
DeepSeek Harness 把这些能力放在可组合的插件树里，连默认 Agent Loop 都由插件提供。Profile 表达一种组装，Bundle 提供一组部件，后续配置可以替换或补充。Cordis 通过服务依赖启动插件，并在卸载时撤销相关注册。
这里要分清三个东西：换模型改变判断者；换工具改变可采取的行动；换运行策略改变什么时候行动、怎样保存和何时停止。Cordis 的 Context 是服务容器，LLM Context 是模型收到的信息，两者不是一回事。
产品上要决定什么
先定位任务卡在哪一层，再决定改模型、资料、工具还是运行策略。不要因为可替换，就一次换掉所有部件。
放到你的工作中
如果结论没有引用，先补一个返回访谈编号与段落位置的读取工具，再用相同任务检查证据完整率。模型与输入样本保持不变，才能看清这个改动的价值。
02 / 每一步都要接住上一步的真实结果。
一句需求，怎样成为连续工作的系统？
在默认循环中，输入进入队列；系统准入这一批输入，组装提示词与工具，准备模型调用，再从日志派生实际请求。模型如果请求工具，系统执行工具并记录结果，随后决定是否需要下一步。
“正在运行”“被阻断”“被取消”和“发生错误”是不同状态。源码会在轮次结束时记录原因，也支持在停止检查点接住尚未完成的工作。模型输出一段最终回答，不足以证明业务目标已经达到。
把这个过程翻译成用户体验：用户应知道现在读到哪里、遇到了什么障碍、自己补充的信息何时生效，以及最终交付的是完整报告还是部分成果。
产品上要决定什么
设计继续和停止的条件，同时设计停止后用户还能拿到什么。
放到你的工作中
访谈助手读到第 7 份文件时发现损坏，应保留已读取材料的证据，指出缺少的文件。把“报告已生成”与“十份材料均被覆盖”分开显示。
03 / 进度让人安心，事实记录让工作可追溯。
为什么不能只保存聊天气泡？
dsh 区分持久的 Session 事实和运行中的 Agent 事件。工具调用、结果和轮次结束属于可回放记录；实时状态和输出片段服务于当前界面。模型请求由会话日志投影构造，运行时还检查相应一致性。
这一设计让我们可以问：模型当时究竟拿到了哪些资料？一次失败是发生在工具执行前，还是结果回传后？取消的是本轮工作，还是整个会话？这些问题无法仅靠最后一句答案解释。
记录也有边界。官方生命周期文档明确指出，如果进程在持久结果提交前硬中断，实时输出不一定留下完整的持久记录。可观察并不等于所有细节永远不会丢失。
产品上要决定什么
让界面状态、可恢复记录与真实业务结果各自有清楚的含义。
放到你的工作中
报告引用保留访谈编号和原文位置；保存失败时显示“内容已生成，文件未保存”，并给出已有内容。不要把一个转圈动画结束当成文件落盘成功。
继续学原理：为什么 Agent 任务不能只存聊天记录？同一个 Agent 怎样服务 CLI、IDE 与桌面端？怎样让 Agent 自主，又不让你失去控制？
04 / 能连接一个工具，不等于每次都能使用它。
自动化越多，行动边界越要具体。
DeepSeek 的工具请求会经过执行前策略、守卫、实际执行、执行后处理与结果记录。前置策略可以让动作继续、拒绝或请求审批；独立守卫可以进一步拒绝，普通放行不应覆盖它的拒绝。
审批服务把结果区分为一次允许、拒绝、取消和应答不可用。只有一次允许能够授权该操作。无人应答和用户取消，不会被解释成默认同意。
这三个层次需要分开设计：插件是否在宿主中可用，工具是否暴露给某个 Agent，这次具体动作是否有权限。沙箱另外约束动作能影响的环境；审批弹窗本身不提供系统隔离。
产品上要决定什么
用具体动作、资源和结果写权限合同，同时规定无应答时怎样结束。
放到你的工作中
访谈目录只读；报告只写入 output 目录；向外部系统发布需要授权。若审批通道不可用，就留下内部草稿与未发布状态，而不是把内容发出去。
05 / 压缩要保住任务，不只保住字数。
材料越来越多，怎样继续而不丢掉依据？
长任务不断产生资料、工具输出和中间结论。DeepSeek 把压缩设计为可替换的能力：既可以在上下文压力下处理，也可以响应明确的上下文溢出；工具结果剪枝与摘要是不同手段。
压缩过程记录开始、摘要或替换范围与结束。模型看到的是经过投影的有效上下文，日志继续保留相关事实。这样可以研究一次信息取舍怎样影响后续工作，而不是把历史无痕删短。
具体到访谈研究，应该优先保留任务目标、结论到来源的对应关系、反例和未解决问题。重复日志可以缩短，支撑一个关键判断的原文则可能需要重新按引用读取。
产品上要决定什么
同时检查上下文大小、证据召回、关键约束和最终结果。
放到你的工作中
用同一批访谈对比“完整材料”和“摘要加原文索引”两种输入。若成本下降却丢了少数用户的反例，这个压缩策略就不能只凭节省 token 判定成功。
依据：上下文压缩
继续学原理：它刚读过文件，下一步为什么又忘了？怎样在正确时刻，把正确资料交给模型？Agent 应该记住什么，又应该忘掉什么？
06 / 委派的不只是模型，也可能是一套完整运行系统。
一个 Agent 可以把任务交给另一套 Agent。
DeepSeek 的子任务接口支持不同提供方，包括进程内子 Agent，以及 Codex、Claude Code 等产品后端。提供方声明自身能力，不能支持的请求应明确拒绝，避免表面接受却悄悄忽略约束。
固定版本的 Codex 后端会为自包含任务创建新的临时线程，运行一个轮次，再返回最终答案或有限诊断。它并不会把子系统所有工具活动与原始过程复制回父会话。更换子任务后端因此会改变上下文、控制权和证据边界。
这种组合并不自动提高质量。任务需要独立拆分，输入应足够明确，合并结果要有规则，并且父任务必须知道如何停止子任务、核对产物和处理部分失败。
产品上要决定什么
先定义委派合同，再决定用多个 Agent。
放到你的工作中
让三个子任务分别提取三组访谈的证据，要求统一返回“问题、原文、编号、反例”。主任务负责合并与核验，不允许子任务直接覆盖最终报告。
07 / 调度负责何时开始，工作流负责怎样组织工作。
“以后自动做”，需要哪些真正的机制？
dsh 的工作流能力可以运行编排脚本并启动子任务；它区分完成、取消与错误，要求释放运行资源并等待子任务停稳。展示中的阶段名称并不等于实际执行的依赖顺序。
调度则向原有会话投递后续任务，支持延时、绝对时间和固定间隔。绝对时间有明确时区约定；错过重复周期时采用补偿规则，而不是把所有漏掉的周期无限补跑。
“提醒已保存”与“未来一定执行”不同。需要有存活的运行环境、可用的资料权限与明确的交付渠道。离开网页、停止宿主或遇到审批，都可能改变实际执行条件。
产品上要决定什么
把自动化拆为触发、材料、执行、异常、交付与停止六部分。
放到你的工作中
每次检查新访谈先比较文件清单；没有变化就结束，有变化才提取证据并更新内部草稿。重复触发不重复发布，材料缺失要显示缺口，停止后不再调度新工作。
08 / 一个改动、一份证据、一个可以解释的取舍。
把这些机制变成自己的产品实验。
选择访谈研究任务，先固定十份教学材料和完成标准：每个结论至少有原文依据，反例不能丢，草稿必须保存在指定目录。记录当前耗时、人工复核量和失败位置。
第一轮只改证据读取工具，第二轮再比较上下文策略，第三轮才考虑子任务拆分。每轮使用同一组样本，记录未完成、错误引用、越界动作与成本，保留能解释差异的轨迹。
这些是本站设计的产品实验，不是 DeepSeek 的官方基准或实测成绩。开源让实现更可检查，是否适合你的业务仍要由真实任务与验证结果回答。
产品上要决定什么
把“我觉得更聪明了”改写为可复核的改进结论。
放到你的工作中
一份合格报告应能说清：改了哪个部件；哪些样本变好；哪类失败仍存在；代价是什么；怎样回退。用它支撑下一次产品取舍。
来源与版本边界
下面均来自 DeepSeek 官方仓库的同一固定提交。来源描述的是实现及合同，产品建议属于本站分析。已有 Codex、Claude Code、Pi、Grok Build 与 Hermes 的研究保留各自版本和日期。
- 官方定位与许可证 ↗
说明项目身份、开发者预览与 MIT 许可。
README.zh.md - 整体架构与插件组合 ↗
说明 Profile、Bundle、事件、服务与默认循环的关系。
docs/architecture.zh.md - Cordis 的服务、事件与生命周期 ↗
说明依赖注入与注册项卸载。这里的 Context 是服务容器。
docs/cordis-primer.zh.md - Agent 循环实现 ↗
核对步骤准入、请求构造、继续、停止和取消。
packages/core/agent-loop/src/agent.ts - 会话事实与实时事件 ↗
区分持久记录与实时协调；不是每个实时片段都会即时持久化。
docs/agent-lifecycle.zh.md - 工具执行流水线 ↗
说明执行前策略、守卫、执行、结果处理与记录。
docs/tool-execution-pipeline.zh.md - 审批服务实现 ↗
核对一次允许、拒绝、取消和应答不可用的处理。
packages/interaction/user-approval/src/index.ts - 上下文压缩 ↗
说明压缩记录、范围、剪枝和恢复；不证明摘要永不丢信息。
docs/subsystems/compaction.zh.md - 子任务与提供方 ↗
说明子任务能力合同、提供方和取消传播。
docs/subsystems/subagent.zh.md - Codex 子任务后端 ↗
说明临时线程、单次运行、最终答案和诊断的回传边界。
packages/subagent/subagent-codex/README.zh.md - 工作流的运行与清理 ↗
说明编排、结果、取消和资源释放。
docs/subsystems/workflow.zh.md - 会话内调度 ↗
说明时间、固定间隔与错过周期的规则；不等于独立云服务。
docs/subsystems/schedule.zh.md - 官方预览版使用边界 ↗
官方说明尚未安全审计，不应视为生产就绪软件。
SAFETY.zh.md