开物 KAIWU 保存项目、任务、审批和执行记录。本文讨论的是它怎样把已批准的任务交给 DeepSeek Harness（DSH）执行，并把结果带回工作台。开物的 Web 应用不直接取得任意 Shell 执行权限。
适配需要处理两个边界：Web 请求不能自行授予机器写入权限；执行结果返回后，要能查到对应的任务版本、批准和尝试记录。下面保留截至 2026 年 8 月 29 日的实现与验证记录，不代表今天重新完成了生产复测。
用独立 Bridge 隔开 Web 请求与机器执行
开物决定任务怎样进入执行，DSH 在自己的运行环境中完成工作。
开物保存目标、约束、验收标准、写入需求和批准证据，同时记录任务交给哪个 Harness、结果是否已确认。
DSH 在自己的权限模型和沙箱中读取仓库、调用工具、运行命令并返回结果。API Key 不由开物的 Web 应用持有。
适配进程放在 bridges/deepseek-harness。Bridge 从 Outbox 读取获批任务，调用 DSH 自动化入口，再把启动、完成或失败事件写回 Inbox。Laravel 控制器不直接启动执行器。
用 Quest 发出任务，用 Event 返回执行记录
工作台向执行器发送 kaiwu.quest/v1，执行器通过 kaiwu.event/v1 返回记录。
Quest 是任务协议，包含稳定 ID、项目、目标、约束、风险等级、写入需求、批准证据和验收标准。Event 是事件协议，保存状态、发生时间、执行会话和结果摘要。提示词只是其中一部分。
人工创建或 AI 生成 Quest
↓
开物保存目标、约束与风险
↓
写入型任务等待人工批准
↓
kaiwu.quest/v1 Outbox
↓
DeepSeek Harness Bridge
↓
DSH 在独立进程与沙箱中执行
↓
kaiwu.event/v1 Inbox
↓
开物投影执行状态并等待结果确认
更换 Harness 时，Adapter 负责翻译这两份协议，项目、审批和审计模型可以继续使用。新的适配器也必须执行批准检查。
原创方法示意，依据正文绘制；不是软件截图或实测结果。
执行前重新检查批准和写入范围
Bridge 对每份 Quest 重新核对批准证据。仅仅在目录中发现任务文件不能证明获批；缺少证据时拒绝执行，需要写入的任务也不能按只读任务处理。
权限映射保持简单：requires_write=false 对应 DSH 的 read-only，需要写入且已经批准的任务才进入 workspace-write。API Key 只存在于进程环境中，不写入 Git、Quest 或事件日志。
规划写入任务和批准写入是两次不同操作。批准由人给出，证据随 Quest 一起保存，供执行前检查和事后核对。
分别保存重试，并允许事件状态重放
Bridge 对 dispatch 加锁，原子写入执行状态，并使用稳定的事件 ID。重复同步同一个事件不会新增业务记录，但仍会重新更新对应状态。
事件落库成功后，状态更新仍可能失败。如果同步器发现事件已存在就跳过全部处理，Quest 会保留旧状态。下一次同步重新应用这个事件，才能补上失败的状态更新。
每次重试使用新的 attempt 和 dispatch 身份。第一次失败记录保留在时间线中，便于比较批准、启动、失败位置和后续上下文变化。
区分源码标签、可安装包与验证过的运行方式
截至 2026-08-29，DeepSeek Harness 的 GitHub 最新源码标签是 0.1.2-alpha.1，但没有对应的 npm/PyPI 可安装主包；当前可安装版本分别是 npm CLI 0.1.1-rc.2 和 Python SDK 0.1.1rc1。开物因此把生产 Adapter 固定到经过验证的 CLI 0.1.1-rc.2，而不是追逐一个只有源码标签的版本。
这次升级通过 PR #6 合并到 KAIWU main，生产提交为 8458504c7b34c5e85f00fe79fd78205fbe9391dc。kaiwu.denghy.cn 已公开显示 RC.2 PINNED，项目源代码、生产 release 和页面版本文案保持一致。
兼容性测试发现，SDK wheel 虽然补上了 macOS arm64 runtime，却无法加载开物要求的 Bash 沙箱插件；npm CLI 也需要显式补足官方 peer 依赖。开物选择失败关闭：自动模式只选择经过验证、带完整沙箱配置的 CLI，SDK 保留为显式诊断路径，不会静默降级成无沙箱执行。
升级预览版需要分别检查安装包、启动配置、权限插件、协议和项目测试。GitHub 出现源码标签，不能证明包管理器已提供可安装版本，也不能证明该包适合当前 Bridge。
验证覆盖协议与无密钥路径，真实模型质量仍未测试
开物 DSH 适配的验证覆盖 Bridge 单测、Quest/Event 协议、权限映射、幂等同步、Laravel 测试、前端构建、网站服务端渲染、静态导出和依赖审计。升级过程实际读回了 CLI 0.1.1-rc.2 和完整沙箱配置；GitHub 两套 CI 通过后才合并并重新构建生产站。
验证过程没有调用真实模型，也没有使用或保存 API Key。因此可以确认的是：协议、门禁、进程边界和无密钥执行路径能够按设计工作；不能据此声称已经完成真实模型任务的端到端质量评测。
后续升级要守住的边界
这次实现把批准、任务协议、执行进程和历史事件分别保存。DSH 升级后，仍需检查谁批准任务、允许写入哪里、失败怎样返回、重试是否保留旧记录。
协议和无密钥测试通过后，下一项未完成的验证仍是真实模型任务：它能否在规定权限内完成工作，并提供可验收的结果。
项目站：kaiwu.denghy.cn