Align DeepSeek Harness article narrative

content/posts/deepseek-harness-architecture-evaluation.md

@@ -1,6 +1,6 @@
 ---
 {
-  "title": "DeepSeek Harness：全插件化 Agent 运行时与评测现状",
+  "title": "DeepSeek Harness 通过插件组装 Agent 运行时",
   "summary": "从一个 greet 工具的完整生命周期出发，分开解释启动装配、请求调用、事件记录和协议边界，再核对 DeepSeek Harness 的架构取舍与公开评测证据。",
   "date": "2026-08-14",
   "updated": "2026-08-14",
@@ -14,23 +14,21 @@
 }
 ---
 
-# DeepSeek Harness：全插件化 Agent 运行时与评测现状
+> DeepSeek Harness 目前适合进入持续观察和隔离试点。在兼容性、发布稳定性和 Agent 任务评测补齐前，它不适合作为组织级默认 Harness。
 
-> 一句话结论：DeepSeek Harness 已经展示出一套有辨识度的“全插件化 Agent 运行时”，适合持续观察与隔离试点；在兼容性、发布稳定性和 Agent 任务评测补齐前，不适合作为组织级默认 Harness。
+## 本文解释 DeepSeek Harness 的运行机制和采用边界
-
-## 调研范围
 
 本文面向理解大模型、API 和基本工具调用，但尚不了解 Cordis 或 Agent Runtime 内部结构的读者。它回答三个问题：DeepSeek Harness 实际如何组装和运行 Agent；它与常见 coding agent 系统的关键差异是什么；当前公开证据是否足以支持观察、试点或正式采用。
 
 调研冻结在 2026 年 8 月 14 日，目标代码固定为提交 [`47f943859bef60e4160492346772ded9b24f765a`](https://github.com/deepseek-ai/deepseek-harness/tree/47f943859bef60e4160492346772ded9b24f765a)。横向对照也固定到同日抓取的 Codex、Gemini CLI 与 OpenHands 提交。本文不评价 DeepSeek 模型能力，不使用 GitHub star 数作为成熟度证据，也不把不同项目、不同模型、不同任务下的数字拼成排行榜。
 
-## 项目位置与必要概念
+## DeepSeek Harness 是一套 Agent 运行外壳
 
 DeepSeek Harness（命令名 `dsh`）不是一个模型，也不是某个单独工具的封装。它是一个 **Agent Harness**：负责把模型、工具、会话状态、执行循环、权限策略和用户入口组装成一个可以持续运行的 Agent 应用。
 
 先建立四个最小概念：
 
-| 名称 | 白话解释 | 在 dsh 中负责什么 |
+| 名称 | 简要定义 | 在 dsh 中负责什么 |
 |---|---|---|
 | Agent | 能接收目标、调用模型和工具、保留状态并继续工作的程序 | 一个 Agent 由模型、工具、会话和执行循环共同组成 |
 | Agent Harness | 承载 Agent 的运行外壳 | 启动组件、接收请求、管理状态、执行工具并暴露 Web/协议入口 |
@@ -41,7 +39,7 @@ dsh 主体是 TypeScript monorepo，运行在 Node.js ESM 环境；冻结提交
 
 理解这套架构最重要的前提是把两个问题分开：**启动装配**回答“哪些组件存在、谁依赖谁、谁随谁卸载”；**请求执行**回答“用户的一条消息在已经启动的组件之间怎样移动”。Cordis 插件树主要回答前一个问题，不是用户请求的调用顺序。
 
-## 一次完整的 `greet("Ada")` 走查
+## `greet` 工具展示了完整的插件生命周期
 
 假设现有 Profile 已经包含 LLM、工具注册表、会话、Agent loop 和 Web/ACP/SDK 入口。我们只增加一个虚构示例包 `@acme/dsh-greet-tool`，让模型能够调用 `greet`。下面代码根据官方教程的工具插件写法精简；它只演示插件机制，不是仓库已经发布的包。
 
@@ -77,13 +75,13 @@ export function apply(ctx: Context) {
 
 这个工具从配置到卸载会经历六个连续阶段。
 
-### 第一阶段：配置先决定“准备挂载什么”
+### 配置先决定要挂载的插件
 
 dsh 不会直接把某一个 YAML 文件原样交给 Cordis。它先读取 Profile 指定的有序 Bundle，依次应用各 Bundle 的 patch，再叠加 Profile 自身 patch、Harness home patch 和本次命令行 `--patch`，最终得到一组有效配置行。`greet-tool` 是其中一行；它的 `id` 是稳定身份，`name` 指向要加载的模块。[CLI 组合参考](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/apps/cli/reference/README.md)
 
 如果后层 patch 命中同一个 `id`，该行的 `config` 会整体替换，不是字段级深合并。这里的配置合成只回答“本次启动要挂载什么”，尚未执行任何用户请求。
 
-### 第二阶段：Loader 创建 Fiber，`inject` 决定何时启动
+### Loader 创建 Fiber，`inject` 决定插件何时启动
 
 启动器创建根 `Context` 并挂载 Loader。Loader 解析 `@acme/dsh-greet-tool`，为这次插件挂载创建一个 Fiber。Fiber 不是线程或操作系统进程，而是 **一个插件实例的运行时句柄**：它记录父上下文、配置、依赖、状态、注册的 effect 和清理过程。
 
@@ -91,39 +89,39 @@ dsh 不会直接把某一个 YAML 文件原样交给 Cordis。它先读取 Profi
 
 `apply` 中的 `ctx.tools.register(...)` 把 `greet` 的名称、参数 schema、返回值渲染和执行函数注册到工具运行时。该注册本身属于一个 effect；Cordis 会记住对应的 disposer，以便插件卸载时自动注销工具。[进入 Harness 教程](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/docs/cordis-tutorial/07-into-the-harness.zh.md)
 
-### 第三阶段：用户请求进入已经启动的 Agent
+### 用户请求进入已经启动的 Agent
 
 用户通过 Web、ACP 或 SDK 输入“向 Ada 问好”。入口适配器把消息交给对应 Agent 的 inbox。Agent loop 取得待处理输入，从会话日志派生历史，加入系统提示和当前可用工具 schema，然后进入一个 model step。此时 `greet` 已经是工具列表中的一项；Cordis 不再决定模型是否调用它，Cordis 只保证工具已经正确注册。
 
 模型可以直接回答，也可以产生工具调用。这个例子中，模型返回 `greet({"name":"Ada"})`，于是 Agent loop 把调用交给统一 Tools Runtime。
 
-### 第四阶段：工具经过统一执行管线
+### 工具调用经过统一执行管线
 
 工具调用不会从模型直接跳进示例函数。标准路径依次经过 `tools/pre-execute`、审批、guard、`tools/execute`、工具本体、`tools/post-execute` 和结果固化。若某项策略返回 `ask`，但当前入口没有可用审批 answerer，系统会拒绝而不是静默放行。[Tools README](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/packages/core/tools/README.md)
 
 `greet` 执行后返回 `Hello, Ada!`。Tools Runtime 将结果交回 Agent loop，Agent loop 再把它放入下一次模型请求。模型据此生成最终回答，例如“已向 Ada 问好”。这就是 Agent loop 所负责的“模型 → 工具 → 模型”循环。
 
-### 第五阶段：SessionEvent 在旁路记录事实
+### SessionEvent 在旁路记录执行事实
 
 用户消息、step 开始、模型消息、工具调用、工具结果和最终回答会分别追加为 `SessionEvent`。它不是调用链中的“下一台服务器”，也不负责把工具结果转发给模型；它是执行过程中形成的 durable fact。模型历史、resume、fork、轨迹视图、持久化和 UI 投影都从同一事实源派生。[持久化说明](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/packages/session/session-persistence/README.md)
 
 如果进程在工具调用期间中断，恢复逻辑会检查日志：工具尚未真正开始，可以安全标记失败；工具可能已经产生副作用但没有留下结果，则标记“结果未知”，提示模型先验证外部状态，避免盲目重试。这解释了事件日志为什么与执行链同样重要，但二者仍是不同关系。
 
-### 第六阶段：配置或依赖变化时自动撤销
+### 配置或依赖变化会触发自动撤销
 
 Fiber 的主要状态为 `PENDING → LOADING → ACTIVE → UNLOADING`，加载失败时进入 `FAILED`。如果 `tools` Service 暂时消失，已经激活的 `greet-tool` 会卸载自己的 effect，回到等待依赖的状态；服务恢复后重新加载。如果配置行被删除，旧 Fiber 完成清理后进入 `DISPOSED`，不能再次启动。HMR 则卸载旧实例，再根据新模块挂载替代实例。[Cordis 生命周期教程](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/docs/cordis-tutorial/02-lifecycle-and-effects.zh.md) [组合与 HMR](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/docs/cordis-tutorial/06-composition-and-hmr.zh.md)
 
 卸载时，`greet` 的工具注册、事件监听、子插件和通过 `ctx.effect()` 管理的定时器或连接都会执行 disposer。插件不需要在每个退出分支手工寻找自己曾经注册的对象。这个“注册与撤销属于同一生命周期”是 Cordis 最核心的工程价值。
 
-到这里可以用一句话复述完整过程：**配置决定挂载 `greet-tool`；`inject` 让它等待 `tools`；Fiber 激活后注册工具；Agent loop 在一次请求中让模型调用它；SessionEvent 记录事实；依赖或配置变化时 effect 自动撤销。**
+完整过程可以概括为：**配置决定挂载 `greet-tool`；`inject` 让它等待 `tools`；Fiber 激活后注册工具；Agent loop 在一次请求中让模型调用它；SessionEvent 记录事实；依赖或配置变化时 effect 自动撤销。**
 
-## 启动装配：Profile 如何变成运行中的插件
+## Profile 会被逐层合成为运行中的插件
 
-![启动装配：谁被创建、谁等待谁；这不是请求调用顺序](/articles/deepseek-harness-architecture-evaluation/dsh-startup-assembly.svg)
+![启动装配会创建 Fiber 并等待服务依赖；这不是请求调用顺序](/articles/deepseek-harness-architecture-evaluation/dsh-startup-assembly.svg)
 
 这张图只回答启动问题。可以把它拆成配置层和运行时层。
 
-### 配置层：Profile、Bundle 与 patch
+### Bundle、Profile 和 patch 共同产生有效配置
 
 - **Bundle** 是可复用的默认插件组合，例如一组基础服务和工具。它贡献配置行或 patch，但运行时不会把整个 Bundle 当成不可拆的黑盒。
 - **Profile** 是一种产品或运行形态的入口。它选择有序 Bundle，并附加自己的 patch，例如组合 Web 或 headless 版本。
@@ -132,21 +130,21 @@ Fiber 的主要状态为 `PENDING → LOADING → ACTIVE → UNLOADING`，加载
 
 合成结果是一组带 `id` 的配置行。每行通常包含 `name`、`config`、`inject` 和 `disabled` 等字段。稳定 `id` 让 Loader 判断一项变化是在更新已有节点，还是删除旧节点后增加新节点。
 
-### 运行时层：Context、Loader 与 Fiber
+### Context、Loader 和 Fiber 管理运行实例
 
 根 `Context` 是进程内能力和事件的访问入口；Loader 根据有效配置加载模块，并把每次挂载变成 Fiber。官方教程支持函数、带 `apply` 的对象和 `Service` 子类三种插件形态。`apply(ctx, config)` 只描述插件向当前上下文贡献什么，启动器和 Loader 负责实际挂载。[第一个 Cordis 插件](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/docs/cordis-tutorial/01-first-plugin.zh.md)
 
 Fiber 负责把一次插件应用变成可观察、可等待、可失败、可卸载的运行实例。它记录所需 Service 的具体实现；提供方变化时，Cordis 可以比较依赖并只重载受影响的插件，而不是重启整个进程。
 
-### 依赖层：Service 与 `inject`
+### Service 和 `inject` 管理服务依赖
 
 Service 是插件提供给其他插件的具名能力，例如 `ctx.llm`、`ctx.tools` 和 `ctx.sessions`。消费者声明 `inject: ['tools']`，只表示“我需要工具服务”，不绑定某一个具体提供包。部署可以替换 provider，而消费插件代码无需改变。
 
 `inject` 是硬依赖：缺失时 Fiber 保持 `PENDING`。可选能力则不应写入 `inject`，而是在使用处通过 `ctx.get(...)` 探测。服务名称共享一个命名空间，这也意味着大型部署必须治理名称、提供方和配置来源。
 
-## 请求执行：一次消息如何经过 Agent loop
+## 一条消息会在已经启动的组件之间流转
 
-![一次 greet 请求：消息在已启动组件之间移动，SessionEvent 是记录旁路](/articles/deepseek-harness-architecture-evaluation/dsh-greet-request.svg)
+![一次 greet 请求会在已经启动的组件之间流转，SessionEvent 位于记录旁路](/articles/deepseek-harness-architecture-evaluation/dsh-greet-request.svg)
 
 这张图只回答运行问题。系统已经完成装配，因此请求链中不再出现 Profile、Bundle 和 Loader：
 
@@ -159,7 +157,7 @@ Service 是插件提供给其他插件的具名能力，例如 `ctx.llm`、`ctx.
 
 dsh 同时存在两类容易混淆的“事件”。`SessionEvent` 是写入会话日志的 durable fact，承担重建、恢复和投影；`agent/pre-step`、`agent/request`、`tools/pre-execute` 等 live event 或 waterfall 是运行时扩展点，插件可以监听、修改、放行或短路当前过程。前者回答“发生过什么”，后者参与“现在怎样继续执行”。
 
-## 插件树、依赖图和调用链不是同一张图
+## 插件树、依赖图和调用链表示三种不同关系
 
 | 关系 | 它回答的问题 | `greet` 例子 |
 |---|---|---|
@@ -169,9 +167,9 @@ dsh 同时存在两类容易混淆的“事件”。`SessionEvent` 是写入会
 
 所谓“Cordis 插件树”首先是一套运行实例的所有权结构；再叠加 `inject` 后，形成服务依赖图。一次请求的调用链则发生在这些实例都准备好之后。三者可能涉及相同插件，但箭头含义不同，不能用一棵树同时表示。
 
-## Web、ACP、SDK、MCP 与 Cordis 的边界
+## Web、ACP、SDK、MCP 和 Cordis 连接不同边界
 
-![DeepSeek Harness 的进程与协议边界](/articles/deepseek-harness-architecture-evaluation/dsh-protocol-boundaries.svg)
+![Web、ACP、SDK、MCP 和 Cordis 连接不同边界](/articles/deepseek-harness-architecture-evaluation/dsh-protocol-boundaries.svg)
 
 先看进程边界，再看协议名称：Web、ACP 和 SDK 把请求从外部送入 Agent；MCP 把外部工具送入 Tools；Cordis 位于 dsh 的 Node.js 进程内部，负责组件装配，不是远程协议。
 
@@ -185,7 +183,7 @@ dsh 同时存在两类容易混淆的“事件”。`SessionEvent` 是写入会
 
 Profile、Bundle 和 patch 不在表中，因为它们是部署配置方式，不是通信协议。ACP 也不等于完整 Web 产品面：它只暴露自动化基线；SDK 线协议当前没有版本协商和单 prompt 取消；MCP 当前不桥接 Resources 和 Prompts。[ACP 协议契约](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/packages/acp/acp/README.md) [SDK 线协议](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/packages/sdk/protocol/README.md) [Web Connection](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/packages/client/connection/README.md) [MCP client](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/packages/mcp/mcp-client/README.md)
 
-## 架构判断
+## DeepSeek Harness 的主要价值来自扩展边界和生命周期管理
 
 1. **最值得关注的是扩展边界。** dsh 允许替换的不只包括工具和模型适配器，还包括会话、Agent loop、工具注册表、策略、持久化和 UI。Profile、Bundle 与 patch 可以逐层改写配置，比“在固定 Agent 核心外围加插件”更激进。
 2. **Cordis 解决的是组合变化。** Fiber、Service、`inject` 和 effect 让插件能随配置与依赖变化安全地加载、等待、卸载和重建；它并不替代 Agent loop。
@@ -193,9 +191,9 @@ Profile、Bundle 和 patch 不在表中，因为它们是部署配置方式，
 4. **工程质量证据多于效果证据。** 仓库有高覆盖率单元测试、keyless snapshot、真实 API e2e 入口、Web 性能/压力 runner 和 CI runner benchmark；但在冻结范围内没有发现公开的 Agent 任务成功率成绩。
 5. **现在的合理动作是观察或隔离试点。** Developer Preview、兼容性主动破坏、会话格式 v0、无正式 GitHub Release，以及缺少可复现的目标任务评测，都会阻断生产级采用。
 
-## 这套设计解决了什么
+## 这种设计同时带来可替换性、可恢复性和安全边界
 
-### 运行时结构也可以替换
+### Profile 和插件可以替换运行时结构
 
 许多 Agent 产品把模型、会话和 loop 固定在核心，只开放工具、MCP、Skill 或 Hook。dsh 把替换面进一步下沉：可以用不同 Profile 组成 Web 或 headless 产品，也可以替换会话后端、工具策略、模型适配器乃至 Agent loop。对于需要研究不同上下文策略、执行器、持久化或交互面的团队，这能减少 fork 主干的压力。
 
@@ -207,19 +205,19 @@ Profile、Bundle 和 patch 不在表中，因为它们是部署配置方式，
 
 但事件溯源不能自动解决格式演进。当前 `SESSION_FORMAT_VERSION = 0`，持久化协调器会拒绝无法升级的旧格式或更新格式；在 Developer Preview 阶段，这意味着长生命周期会话不应被当作稳定资产。试点需要固定提交，并接受迁移、导出或放弃历史的可能性。
 
-### 安全策略是可组合能力，但不是全局护栏
+### 安全策略可以组合，但不会自动覆盖所有工具
 
 默认权限预设把 `workspace-write + ask` 与 `danger-full-access + never` 组合成两个选择，审批缺失时 fail-closed；这比把“是否询问”散落在每个工具内更清晰。[Permission presets](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/docs/subsystems/permission-presets.md)
 
 需要注意的是，策略 seam 只有在工具主动接入或部署增加 `tools/pre-execute` 策略时才生效。官方 Web 工具说明明确指出，它的两个工具本身不会请求 `ctx.approval`，也没有持久 URL 或域名授权；需要确认的部署必须另外挂载策略。[Web tool](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/packages/web/tool-web/README.md) 因此，不能仅凭“系统有 approval 与 sandbox 包”推断所有能力都受到同等保护。
 
-## 安装与扩展门槛
+## 使用和扩展 DeepSeek Harness 仍有明显门槛
 
 体验入口很短：官方给出的 Web 启动方式是 `npx @deepseek-ai/dsh web`，默认监听 `127.0.0.1:3080`。如果从源码开发，则需要 Node.js `^22.19.0` 或 `>=24.0.0`、仓库锁定的 pnpm 11.7，完成依赖安装和构建后再通过 `pnpm dsh web` 启动。[README](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/README.md) [开发指南](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/docs/development.md)
 
 扩展有两条路径。已有能力的轻量改造，可以先用 `dsh --profile web --dump-config` 查看最终配置，再按配置行 ID 用 patch 整体替换；新增模型、工具、策略、会话后端或 loop，则需要实现 Cordis 插件，把它加入 Bundle/Profile，并同时处理服务依赖、事件或 waterfall、effect 清理和测试。后者不是“放入一个脚本即可”的低成本插件：当前项目仍处于 Developer Preview，配置 inventory 又不能完整回答某一行由哪层引入，因此试点需要固定提交、锁定插件版本，并为每个自定义插件建立组合测试和升级回滚检查。
 
-## 与常见 Harness 的差异
+## DeepSeek Harness 暴露了更多运行时替换点
 
 下表比较的是同一生命周期上的架构边界，不是产品效果排名。冻结版本分别为 [Codex `053dda6`](https://github.com/openai/codex/tree/053dda6b897887c0bbd8efa5d4952a4380dbb5e4)、[Gemini CLI `1ac3377`](https://github.com/google-gemini/gemini-cli/tree/1ac3377395868295e128b96726d605a900b5946b) 与 [OpenHands `4f465f3`](https://github.com/All-Hands-AI/OpenHands/tree/4f465f3ccada5271a3bbe4a0148941b0c40d243b)。
 
@@ -233,15 +231,15 @@ Profile、Bundle 和 patch 不在表中，因为它们是部署配置方式，
 
 dsh 试图把 Harness 自身变成可动态组合的研究与产品平台。如果团队只需要一个成熟 coding agent，深度可替换性未必能抵消兼容与运维成本；如果团队正在建设多种执行器、策略、持久化或交互形态，它提供了值得借鉴的边界设计。
 
-## 相关评测与验证现状
+## 公开证据尚不能证明 Agent 任务效果
 
-### 没有发现公开的 Agent 任务成绩
+### 冻结范围内没有公开的 Agent 任务成绩
 
 本文把“公开 Agent 能力评测结果”限定为同时具有明确任务或数据集、指标与分母、已测量结果。按此口径，在冻结提交的 README、`BENCHMARK.md`、文档、工作流和相关文件中，没有发现 SWE-bench、Terminal-Bench、AgentBench 或 GAIA 等任务的公开成绩。
 
 [`BENCHMARK.md`](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/BENCHMARK.md) 只有一条运行说明：通过 Python SDK 启动 `jsonrpc-agent` minimal variant，并为独立任务使用不同 workspace 与 session ID。它是 benchmark 接入口，不是评测方案或成绩。这个结论严格限于 2026 年 8 月 14 日的冻结仓库与官方公开页面；准确表述是“在该范围内未发现”，不是“项目从未评测”。
 
-### 仓库已有三类相关评测资产
+### 仓库包含三类工程评测资产
 
 | 类型 | 任务与指标 | 是否有仓库内正式成绩 | 能说明什么 |
 |---|---|---|---|
@@ -251,13 +249,13 @@ dsh 试图把 Harness 自身变成可动态组合的研究与产品平台。如
 
 仓库还包含单元测试、keyless snapshot、Web Chromium snapshot、真实组合测试与可选真实 API e2e。开发文档强调 CI 对 package source 执行逐文件 100% coverage，但也明确指出 coverage 只是必要条件，不能单独证明行为质量。[开发指南](https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/docs/development.md)
 
-### 边界验证不能填补效果证据
+### 本地验证只能说明工程链路可以运行
 
 冻结提交曾在 macOS arm64 上完成 typecheck；针对 Agent loop、工具管线、会话持久化和用户审批的 35 个测试文件、890 个用例通过；10 万 chunk 压力用例在补齐 Playwright Chromium 后通过，一次观测到的最大主线程延迟约 40.4 ms、计划交互延迟约 1.4 ms，低于仓库 250 ms 门槛。
 
 这些结果只证明该提交在单台机器上的构建合约、定向组件测试与一次前端压力复现。没有运行真实模型任务、全量测试、Docker、跨平台矩阵或同任务对照；长历史性能脚本没有完成。因此它们不能填补 Agent 任务效果证据的缺口，也不应升级为官方成绩。
 
-## 风险与采用门槛
+## 当前证据只支持观察和隔离试点
 
 | 门槛 | 当前状态 | 证据 | 判断 |
 |---|---|---|---|
@@ -269,13 +267,13 @@ dsh 试图把 Harness 自身变成可动态组合的研究与产品平台。如
 
 如果进入隔离试点，建议固定 `47f9438` 或新选定提交，使用可丢弃 workspace，保留默认 `workspace-write + ask`，逐项确认 Web、文件、shell 与外部服务能力是否真正接入审批策略，并把会话导出与版本切换当作可失败项。试点只能回答“它是否适合我们的具体任务和运维方式”，不能用一次成功演示替代采用评审。
 
-## 建议
+## 团队现在适合进行受限试点
 
 现在可以把 dsh 纳入架构观察清单，并安排一个受限试点；不应直接替换现有生产 Harness。观察重点应放在三处：插件树对多产品形态的复用是否真的降低 fork 成本；事件日志能否让恢复、审计和 UI 投影保持一致；工具策略在自定义插件和 Web 能力接入后是否仍然 fail-closed。
 
 从“试点”升级到“采用评估”至少要看到三项变化：项目给出更稳定的发布与迁移政策；在固定模型、工具、预算和任务集下产生可复现的目标任务结果；团队完成插件供应链、权限、数据与回滚审查。任一项缺失，都应继续停留在观察或隔离环境。
 
-## 来源与复现说明
+## 本文结论来自冻结源码和公开资料
 
 - 目标仓库：[deepseek-ai/deepseek-harness](https://github.com/deepseek-ai/deepseek-harness)
 - 冻结提交：[`47f943859bef60e4160492346772ded9b24f765a`](https://github.com/deepseek-ai/deepseek-harness/tree/47f943859bef60e4160492346772ded9b24f765a)

public/articles/deepseek-harness-architecture-evaluation/dsh-greet-request.svg

@@ -1,5 +1,5 @@
 <svg xmlns="http://www.w3.org/2000/svg" width="1440" height="860" viewBox="0 0 1440 860" role="img" aria-labelledby="title desc">
-  <title id="title">DeepSeek Harness greet 请求调用图</title>
+  <title id="title">一次 greet 请求会在已经启动的组件之间流转</title>
   <desc id="desc">用户请求进入已经启动的 Agent，模型调用 greet 工具并返回结果；SessionEvent 在下方记录事实，但不是调用链的下一跳。</desc>
   <defs>
     <style>
@@ -21,7 +21,7 @@
     <marker id="arrow-gray" markerWidth="10" markerHeight="10" refX="8" refY="3" orient="auto" markerUnits="strokeWidth"><path d="M0,0 L0,6 L9,3 z" fill="#7a8c86"/></marker>
   </defs>
   <rect class="bg" width="1440" height="860" rx="32"/>
-  <text class="title" x="64" y="64">一次 greet 请求：消息在已启动的组件之间怎样移动</text>
+  <text class="title" x="64" y="64">一次 greet 请求会在已经启动的组件之间流转</text>
   <text class="subtitle" x="64" y="98">这是一张运行时调用图；Profile、Bundle 和 Fiber 装配已经完成。</text>
 
   <rect class="box" x="58" y="168" width="180" height="106"/>

public/articles/deepseek-harness-architecture-evaluation/dsh-protocol-boundaries.svg

@@ -1,5 +1,5 @@
 <svg xmlns="http://www.w3.org/2000/svg" width="1440" height="860" viewBox="0 0 1440 860" role="img" aria-labelledby="title desc">
-  <title id="title">DeepSeek Harness 协议边界图</title>
+  <title id="title">外部协议连接 Agent、工具和进程内插件</title>
   <desc id="desc">Web、ACP 和 SDK 从外部驱动 Agent；MCP 把外部工具接入 Tools；Cordis 位于 dsh 的 Node 进程内部，负责组件装配而不是远程通信。</desc>
   <defs>
     <style>
@@ -21,7 +21,7 @@
     <marker id="arrow-orange-start" markerWidth="10" markerHeight="10" refX="1" refY="3" orient="auto" markerUnits="strokeWidth"><path d="M9,0 L9,6 L0,3 z" fill="#ca6715"/></marker>
   </defs>
   <rect class="bg" width="1440" height="860" rx="32"/>
-  <text class="title" x="64" y="64">协议边界：谁从哪里接进 Harness</text>
+  <text class="title" x="64" y="64">外部协议连接 Agent、工具和进程内插件</text>
   <text class="subtitle" x="64" y="98">先看进程边界，再看协议名称；Cordis 位于 dsh 进程内部，不是远程协议。</text>
 
   <text class="small" x="62" y="150">dsh 进程外：驱动端</text>

public/articles/deepseek-harness-architecture-evaluation/dsh-startup-assembly.svg

@@ -1,5 +1,5 @@
 <svg xmlns="http://www.w3.org/2000/svg" width="1440" height="860" viewBox="0 0 1440 860" role="img" aria-labelledby="title desc">
-  <title id="title">DeepSeek Harness 启动装配图</title>
+  <title id="title">启动装配会创建 Fiber 并等待服务依赖</title>
   <desc id="desc">Profile、Bundle 和 patch 先形成有效配置，Cordis Loader 再创建插件 Fiber；虚线表示服务依赖，不表示请求调用顺序。</desc>
   <defs>
     <style>
@@ -21,7 +21,7 @@
     <marker id="arrow-orange" markerWidth="10" markerHeight="10" refX="8" refY="3" orient="auto" markerUnits="strokeWidth"><path d="M0,0 L0,6 L9,3 z" fill="#b17220"/></marker>
   </defs>
   <rect class="bg" width="1440" height="860" rx="32"/>
-  <text class="title" x="64" y="64">启动装配：谁被创建、谁等待谁</text>
+  <text class="title" x="64" y="64">启动装配会创建 Fiber 并等待服务依赖</text>
   <text class="subtitle" x="64" y="98">这是一张依赖和生命周期图，不是一次用户请求的调用顺序。</text>
 
   <text class="small" x="66" y="143">第一步：多层配置合成最终插件清单</text>