DeepSeek Harness 解决的核心问题，是多轮模型调用、工具执行与会话状态之间的协调：输入何时进入请求，工具结果如何写回历史，请求失败后从哪里重试，上下文压缩后保留哪些信息，以及任务中断后能够恢复到什么状态。

围绕这些问题，框架将运行过程拆分为插件装配、回合驱动、会话日志、工具管道和异常处理。分析其架构的关键，在于各部分的状态边界，以及这些边界提供的保证与限制。

本篇文章限定在提交 477b4f4205（2026 年 9 月 25 日）对应的实现。

1. 插件装配

插件是 DeepSeek Harness 的核心能力，插件的配置决定 Agent 的运行能力。

DeepSeek Harness 通过 Cordis 插件组织运行能力。Cordis 提供 Context、Service、Plugin 和 Event 等抽象，插件通过依赖注入与事件系统协作，并由框架管理生命周期。

LLM 服务、Session、Agent、AgentLoop 和工具注册表等基础组件，由 bundle 统一挂载。启动时，dsh 以 profile 为入口加载配置，按 id 定位配置行，并替换对应的整段 config。

这里的配置语义是整段替换，而非字段级合并。覆盖某个组件的配置时，原配置中未被保留的字段也可能随之消失。

插件装配因此直接影响 Agent 的实际行为：模型服务是否可用、哪些工具被注册、哪些事件处理器参与执行，都取决于最终加载的插件与配置。仓库包含某项能力，并不等于当前运行实例已经启用该能力。

这种设计便于替换组件和组合能力，但也让执行逻辑分布在多个插件中。分析一次请求的行为，需要同时查看核心循环、插件注册关系和最终生效的配置。

2. 核心循环

Agent 循环是 Agent 的核心逻辑，其主要区分回合、步骤与请求重试。

从实际的工作逻辑上来看，agent-loop 负责驱动模型与工具之间的循环。其主要执行路径包括：

1. 准备模型请求，解析配置并选择适配器。
2. 投影系统提示词，提交本次需要进入历史的用户输入。
3. 从会话构造请求，接收并累积流式响应。
4. 将 assistant 消息写入 Session。
5. 执行模型提出的工具调用，并将结果交给后续模型请求。
6. 在没有工具调用或满足结束条件时，结束本轮执行。

理解这条路径，需要分三个层次：

• turn：由用户输入驱动的回合。
• step：回合内部的执行边界。
• 请求尝试：一次实际发往模型的调用，失败后可以在同一个 step 内重试。

因此，step 不能简单等同于一次网络请求。重试可能产生多次请求尝试，但不应重复消费输入或重复提交用户消息。

Agent 维护 next-turn 和 next-step 两个队列，分别承接下一回合与下一步的输入。队列修改以 agent/inbox/spliced 事件写入 Session，待处理输入可以从日志投影恢复。

这一设计区分了「系统已经收到消息」和「模型已经消费消息」。

执行过程中到达的补充要求，需要在相应边界进入后续请求。它不能自动改变已经发出的模型请求，也不能撤销已经发生的工具副作用。输入排队与执行取消因此属于不同机制。

将队列变化写入日志，还能避免恢复时只找回聊天记录，却丢失尚未处理的输入。

3. Session

Session 机制实现了运行记录与模型历史分离。

Session 被设计为只追加的事件日志，事件通过递增序列号确定顺序，以 type 区分类型，以 body 保存内容。

日志不仅记录用户与 assistant 消息，也记录请求失败、输入队列变化、工具执行和压缩过程等运行事实。

但日志中存在的事件，不一定进入模型上下文。

真正发送给模型的 messages，由 Session 的 surface 通过 deriveMessages() 重建，再冻结为不可变请求。只有进入 surface 的消息事件参与历史投影；assistant/attempt 等运行记录不会自动成为模型消息。

这一分离有两个作用：

• 保留排障信息：请求失败与恢复过程可以完整记录，而不必全部占用上下文窗口。
• 允许调整可见历史：压缩或替换模型上下文时，仍能保留原始事件。

Session 的 append 还会检查 JSON 可序列化性、事件规则及 surface 替换的合法性，以减少无法持久化或无法正确投影的数据进入日志。

日志恢复不等于外部动作回滚

只追加日志为审计与状态重建提供了基础，但不能单独保证任意中断点都能无损恢复。

例如，工具已经修改文件，但结果尚未写入 Session 时进程退出，外部环境与日志之间就可能出现状态差异。恢复日志可以还原已提交的记录，却不能仅凭「缺少结果」判断工具没有执行。

因此，恢复能力需要区分：

• 已提交事件及其投影的恢复；
• 外部副作用的确认与处理。

后者还依赖工具的幂等性、状态检查能力或额外的事务机制，不能仅由 Session 的追加式设计推导出来。

4. 工具管道

工具管道实现了从模型意图到受控执行。

工具注册表只向模型暴露 name、description、parameters 等白名单字段。执行函数、超时设置和并发属性保留在运行时。

这将模型侧的工具描述与运行时的执行控制分开：模型负责提出调用，框架负责判断调用是否可执行，以及如何执行。

一次工具调用依次经过：

1. 解析模型生成的参数。
2. 查找当前 Agent 可见的工具。
3. 通过 tools/pre-execute 进行执行前检查，允许或拒绝调用。
4. 进入 tools/execute 包装链。
5. 通过 tools/post-execute 处理结果。
6. 将结果写回 Session，供后续模型请求使用。

权限检查、执行包装和结果处理因而拥有独立的介入位置，不必全部写进工具函数。

并发执行与顺序提交分离

同一条 assistant 消息可能提出多个工具调用。调度器通过工具的 isConcurrencySafe 属性分类：

• 明确返回 true 的调用进入并行池。
• 其他调用作为独占屏障处理。

并发是显式声明的能力，未声明安全的工具不会默认并行执行。

工具本体可以并发，但准备、后处理、tool/result 写入及附加 context 入队，按模型调用顺序提交。这样可以避免工具完成时间的随机性直接改变会话中的结果顺序。

代价是可能出现等待：后面的工具即使先完成，也需要等待前面的调用提交。并发能够缩短部分执行时间，却不保证结果可以立即进入历史；提前完成的结果还可能需要暂存。

此外，提交顺序稳定不等于外部副作用确定。并发工具是否真正安全，仍取决于它们是否访问共享状态、是否存在执行依赖，以及并发声明是否准确。

5. 安全隔离

DSH 在实现上让审批与执行限制分别生效，以实现安全隔离。

Harness 的沙箱模式包括：

type SandboxMode =
  | 'read-only'
  | 'workspace-write'
  | 'danger-full-access'

策略涉及文件路径权限、命令执行限制和权限提升。工具可以通过 justification 与 sandbox_permissions 请求提升权限，再由 approval 机制处理审批。

基础 bundle 默认挂载 workspace-write 文件沙箱与 ask 审批策略；sandbox-policy 将当前文件操作模式解析给实际后端。

这一结构包含三个不同层次：

• 工具可见性：模型能够提出哪些调用。
• 执行审批：某次调用是否获得许可。
• 后端隔离：获准执行后，实际能够访问哪些资源。

三者不能相互替代。审批通过只说明动作获得许可，不代表执行环境具有无限权限；模型看不到某个工具，也不能据此证明其他工具无法访问相同资源。

安全边界最终取决于策略配置与实际后端的共同约束，而不只是沙箱模式的名称。

6. 异常收敛

异常是应用中很常见的东西，也是 Harness 的重点处理对象。

DSH 通过重试、压缩与取消各自处理不同问题。

6.1 请求重试

通过请求重试来保留失败记录，避免重复提交输入。

模型请求失败后，系统先写入 assistant/attempt，再交给 agent/request-error 瀑布链处理。

llm-retry 根据适配器提供的 retry policy，判断错误类型、重试次数与退避方式。计划重试与实际启动分别记录为 llm/retry 和 llm/retry-started。

重试在同一个 step 中重新准备请求，不重复提交首次用户消息。这一边界避免了网络层重试演变成会话层的重复输入。

分别记录重试计划与启动，也使日志能够区分“决定重试”与“已经开始下一次尝试”。

6.2 上下文压缩

上下文压缩实现了替换可见历史，保留原始事件。

自动压缩在 agent/pre-step 检测上下文压力，并记录：

• compaction/start
• compaction/summary
• compaction/end

随后，系统将选中的连续历史区间替换为一个 checkpoint 用户消息。

这里发生的是 surface replace：模型可见历史缩短，原始日志仍然保留。因此，压缩减少的是请求上下文，不等于同步减少持久化存储。

压缩也引入了信息损失的可能。原始约束即使仍在日志中，只要没有进入摘要或剩余 surface，后续模型就无法直接使用。压缩是否有效，除了看上下文长度，还取决于任务目标、限制条件和未完成事项是否得到保留。

6.3 取消

通过取消来传递停止信号，而非撤销既有结果。

AbortSignal 贯穿回合、请求和工具，使取消信号能够沿执行链传递。

但信号传递不等于立即停止所有动作。工具是否及时退出，取决于其是否检查并响应取消；已经完成的文件写入或远端操作，也不会因 AbortSignal 自动回滚。

取消机制提供的是停止继续执行的控制路径，外部副作用的撤销仍需要独立实现。

7. 小结

DSH 的 Harness 实际上是一种架构的取舍，其取舍考量的是可追溯性与运行成本。

如下的机制共同形成了 DeepSeek Harness 的主要工程取舍：

DeepSeek Harness 的核心价值，是将 Agent 执行中的关键状态显式化：输入有队列，执行有边界，请求有可见历史，工具有调度与审批，失败有独立的处理路径。

这些机制使多轮任务能够被追踪、检查和恢复，同时也明确了框架的能力边界：日志恢复不能替代副作用确认，顺序提交不能替代并发安全，权限审批不能替代环境隔离，上下文压缩也不能保证信息无损。

以上。

本篇文章代码基线采用 DeepSeek Harness 版本 0.1.2-alpha.1，提交时间为 2026 年 8 月 28 日；Pi 采用 853a80d2。这里的 Pi 指 pi-agent-core 中的官方 Agent Loop。

就循环究竟在什么时刻结束这个问题，很多 Agent 框架把结束判断写成一个条件：

while (hasToolCalls) {
  // ...
}

在 Demo 中这种循环也够用。进入生产环境后，你会发现会很多问题：

• 模型没有调用工具，是否代表任务完成？
• 工具执行完了，模型是否还需要解释结果？
• 用户在工具执行期间发来 steering，应该进入当前轮还是下一轮？
• 输出触达 token 上限后，工具参数还能不能执行？
• 某个工具宣布任务完成，其他并行工具怎么办？
• Agent 进入 idle 后，Goal Driver 能不能再次唤醒它？
• Plan mode 退出，是结束当前循环，还是切换下一次请求的策略？
• 进程崩溃后，日志里尚未闭合的 turn 应当如何解释？

DeepSeek Harness 和 Pi 的工程路线不同，或者说 DeepSeek Harness 更复杂，也更能满足复杂场景的需求。

DeepSeek Harness 将结束拆成多层状态，并把事件日志作为重建依据。Pi 保留了更扁平的循环结构，把 steering、follow-up 和 post-turn stop 暴露成回调。前者适合多插件、持久恢复和长期任务；后者适合轻量嵌入，控制路径也更容易读懂。

两种实现都能工作。它们承担的系统复杂度不同，结束语义自然不会相同。

五层边界

讨论 Agent Loop 时，我们需要先定义好「结束」，否则代码里的 completed、turn_end、agent_end 很容易被混为一谈。

DeepSeek Harness 实际存在五层边界。

第一层是模型请求结束。

Provider 流式输出完成，可能给出正常停止、工具调用、最大 token、错误或取消。这里的判断逻辑是：当前 HTTP 请求或模型流结束了吗？

第二层是 step 结束。

一个 step 包含一次模型调用，以及该响应发起的一整批工具执行。工具执行结束后，step 才算关闭。模型若调用了普通工具，系统通常还欠一次模型回访，因此 step 结束不代表 turn 结束。

第三层是 turn 结束。

DeepSeek Harness 中，一个 turn 可以包含多个 step，大概如下：

用户输入
→ 模型调用
→ 工具批次
→ 模型回访
→ 工具批次
→ 模型最终输出

以上为一个 turn。turn 结束需要同时满足两项条件：

1. 模型不再欠一次回复；
2. next-step inbox 没有待处理输入。

第四层是 driver activity 结束。

一个 driver 可以连续处理多个 turn。当前 turn 关闭后，如果 inbox 里还有普通 follow-up，driver 会直接打开下一 turn。只有队列耗尽，driver 才回到 idle。

第五层是长期工作流结束。

Goal Driver 可以监听 idle，检查持久 Goal 状态，再调用 followup() 开启新 turn。Plan mode 也可能跨越多个 turn 持续生效。因此，idle 只描述当前 activity；它无法回答长期目标是否完成。

Pi 的层级少一些。一次 assistant 响应与随后执行的工具批次，会对应一个 turn_end。工具回访模型时，Pi 再开启下一次 turn。内部队列耗尽后发出 agent_end，当前 invocation 至此结束。

从语义上看：

• DeepSeek Harness 的 step 接近 Pi 的 turn；
• DeepSeek Harness 的一次 driver activity 接近 Pi 的一次 Agent Loop invocation；
• DeepSeek Harness 的 Goal Round 位于 driver activity 外层；
• Pi 的长期 Goal 通常由宿主或扩展继续调度。

术语相似，粒度相差一层。如果日志消费端忽略这一点，统计出的 turn 数、工具往返次数和任务完成率都会失真。

驱动收敛

DeepSeek Harness 的入口：

while (await this.turn()) {
}

turn() 返回 true，driver 继续处理下一 turn；返回 false，driver 收敛；抛出异常时，异常会被 driver 边界容纳，随后进入 idle。

短代码背后有一套完整的 phase 状态机：

idle
maintenance
running

running 保存：

• 当前 turn；
• 当前 step；
• AbortController；
• wakeRequested。

maintenance 同样持有取消信号和唤醒锁存，只是对外状态仍显示为 idle。这种设计解决了一个经常被忽略的竞态：Agent 处于维护任务时收到新消息，新消息不能立即启动第二个 driver，也不能静默丢失。系统先将唤醒意图锁存，维护结束后检查 inbox，再决定是否重启。

取消路径也有类似处理。

如果一个 waking input 到达时，现有 activity 已经被 abort，这条消息会被重分类到 next-turn。它不能加入一个正在收敛的旧 turn。send() 在插入 inbox 前读取 aborted 状态，避免 inbox observer 触发重入取消后改变分类结果。

这段细节很像传统并发状态机，而不是常见的聊天循环。它处理的是输入归属问题：一条消息必须属于当前 step、下一 step 或下一 turn，重入事件不能改变已经作出的边界判断。

whenIdle() 也没有简单等待某个固定 Promise。它反复比较 activityDone：

do {
  await (activity = this.activityDone)
} while (activity !== this.activityDone)

等待期间如果 activity 被新的 driver 替换，调用方会继续等待。否则 whenIdle() 可能在旧 driver 结束、新 driver 已经启动的窗口里提前返回。

在多插件环境中，idle 是一个可观察状态，也是一种同步承诺。这个承诺需要覆盖重启竞态，不能只看某次异步任务是否 resolve。

Turn 状态机

DeepSeek Harness 在领取输入之前写入 turn/start。

pre-step 可能拒绝输入，系统提示组装可能抛错，首步消息也可能被插件改写为空。无论发生哪种情况，日志中都存在一个完整 turn，并由唯一的 turn/end 收口。

turn 内部维护两个变量：

• turnEnds：当前已知的结束原因；
• target：本轮 pre-step 应领取 next-turn 还是 next-step。

第一个 step 从 next-turn 开始。后续 step 转向 next-step。普通用户 prompt 因此拥有独立 turn，工具附加上下文、运行时 context 和 steering 则可以进入当前 turn 的下一 step。

一次循环大致经历以下过程：

创建 step 编号
→ 从 inbox 领取消息
→ 组装系统提示和运行时 context
→ 执行 agent/pre-step
→ 记录 step/start
→ 写入 user/message
→ 调用模型并执行工具
→ 记录 step/end
→ 判断是否继续

如果 agent/pre-step 返回 reject，turn 以 blocked 结束，模型不会被调用。

如果首个 step 的消息为空，turn 以 completed 结束，也不会消耗模型请求。这覆盖了一个边缘场景：wakeup 已经打开 turn，随后消息被移除，或者 pre-step 插件把消息改写为空。边界既然已经建立，日志仍需闭合。

如果某个 step 已经产生结束结果，但下一次 pre-step 没有消息，循环退出。若仍有消息，就继续执行。

这里需要留意 turnEnds 与 stepEnd 的关系。step() 可以返回：

• completed；
• max-tokens；
• null。

null 表示工具执行完毕，模型还欠一次回复。它是继续循环的协议状态，和错误、未知结果没有关系。

turn 的结束判断由「模型债务」与「消息债务」共同决定。模型债务来自 tool call，消息债务来自 inbox。只检查其中一项都会出错。

停止钩子

DeepSeek Harness 在 turn 准备收口时触发 agent/turn-stopping。

这个扩展点没有返回 true 或 false。插件如果希望 turn 继续，需要向 next-step 写入消息。hook 执行完成后，核心循环重新检查 inbox：

turn 已经可以结束
→ next-step 为空
→ 触发 agent/turn-stopping
→ 再次检查 next-step
→ 为空则关闭
→ 非空则进入下一 step

这是数据驱动的方式。

多个插件都能监听 stopping。如果采用 shouldContinue(): boolean，组合规则会立刻变得棘手：

• 任意插件返回 true 就继续？
• 所有插件都返回 true 才继续？
• 后执行的插件能否覆盖先执行的结果？
• 插件决定继续，却没有提供下一步输入，模型该看到什么？
• 插件决定停止，但另一个插件已经排入 steering，谁的优先级更高？

DeepSeek Harness 用 inbox 消除了大部分布尔值合并问题（这个设计和 Golang 的竞态处理逻辑类似，使用类似消息队列来处理竞态）。继续执行必须产生一条可消费的数据。最终判定依赖队列状态，而非插件调用顺序。

当然，这也是需要代价的。

插件作者需要理解 inbox target、turn 边界和 wakeup 语义。一个简单的「再跑一次」操作，需要构造 UserMessage 并写入正确队列。框架学习成本高于直接回调。

这种成本在单体应用里可能显得繁琐。进入可恢复、多插件、可审计系统后，显式消息通常比隐式布尔控制更可靠。日志和调试工具能看到「为什么继续」，而不是只看到某个 hook 曾经返回 true。

Step 债务

step() 最关键的职责，是判断模型是否还欠一次回复。

模型流结束后，BlockAssembler 给出 finish 状态。如果 finish 是 error 或 aborted，系统先触发 agent/request-error waterfall。插件可以选择 retry。没有 retry 动作时，代码抛出结构化 LlmError。

正常组装出 assistant message 后，判断顺序如下：

1. finish 为 max-tokens，返回 max-tokens；
2. 没有 tool call，返回 completed；
3. 存在 tool call，执行整批工具；
4. 工具批次声明 concluded，返回 completed；
5. 普通工具批次返回 null。

顺序不能随便改。

最大 token 状态在工具解析之前返回，因此响应中即使出现 tool call，也不会被执行。截断输出可能包含不完整的 JSON 参数。某些流式解析器会尝试补全 JSON，补全后甚至能通过 schema 验证，但语义字段可能已经缺失。执行这类调用会产生真实副作用。

DeepSeek Harness 的选择偏保守：整轮以 max-tokens 收口，等待外部策略决定是否继续。

Pi 采用另一种处理。stopReason === "length" 且消息包含工具调用时，它会给所有工具生成错误结果，说明参数可能被截断，没有实际执行，然后把这些结果交回模型。模型有机会在下一 turn 重发完整调用。

两者的恢复能力不同。

DeepSeek Harness 保留了清晰的 durable turn reason，运维侧能准确识别 token ceiling。自动继续需要 Goal Driver、用户输入或其他插件参与。Pi 更倾向在当前 invocation 内自我修复，模型可能马上重发工具调用。

我在具有写操作的 Agent 中会选择 DeepSeek Harness 的策略。达到输出上限本身意味着模型状态不完整，自动延续可能重复前一批操作。只读研究型 Agent 可以采用 Pi 的方式，失败工具结果能减少一次人工干预。

粘性结果

DeepSeek Harness 的 max-tokens 具有粘性。

某个 step 达到上限后，插件仍可能在 turn-stopping 阶段补入 steering，让 turn 再执行几个 step。后续 step 即使正常完成，最终 turn/end 仍然保留 max-tokens。

判断逻辑是：

if (
  turnEnds === null ||
  turnEnds.kind !== 'max-tokens'
)
  turnEnds = stepEnd

这里记录的是整个 turn 的质量，而非最后一次 step 的结果。

如果不做粘性处理，可能产生如下日志：

step 1: max-tokens
step 2: 插件要求继续
step 3: completed
turn/end: completed

消费端会丢失曾经发生的截断。监控系统无法统计 token ceiling，Goal Driver 也可能把这轮当成完整成功并继续自动调度。

把 turn reason 视为聚合结果后，合并规则就需要专门设计。DeepSeek Harness 当前只对 max-tokens 做了优先保留。错误和取消会直接离开主流程，不参与后续合并。

如果未来加入诸如 partial、policy-warning、budget-exhausted 等状态，简单覆盖会越来越脆弱。更稳妥的方向是为 reason 建立显式优先级或累积 facts，再由投影层生成最终 reason。当前 union 规模尚小，现有实现足够清楚。

工具收口

DeepSeek Harness 允许工具通过结果上的 concludesTurn 宣布当前 turn 可以收口。

工具批次采用 OR 聚合：

任意一个已提交结果 concludesTurn === true
→ 整批 concluded === true

它表达的是「模型默认不再欠一次工具结果回访」。

concludesTurn 没有直接打断同批工具，也没有清空 next-step：

• 已启动的并行工具继续运行；
• 结果按模型调用顺序提交；
• additionalContexts 写入 next-step；
• 同期到达的 steering 也写入 next-step；
• 只要 next-step 非空，turn 仍会进入下一 step。

因此，工具结束能力属于软收口。它取消了自动回访债务，无法压过已经存在的消息债务。

这套语义适合权威型工具。例如某个交互工具已经取得用户最终决定，或者某个提交工具已经完成不可逆事务，模型没有必要再生成一段中间解释。工具可以建议收口，同时保留系统上下文和用户 steering 的优先级。

Pi 的工具终止采用 AND 聚合：

return finalizedCalls.length > 0 &&
  finalizedCalls.every(
    finalized => finalized.result.terminate === true
  )

只有非空批次中的每个 finalized result 都带有 terminate: true，整批才终止。

并行批次中，一个工具不应单方面吞掉其他工具结果。Pi 要求整批达成一致，语义更保守。DeepSeek Harness 允许一个权威工具宣布收口，扩展能力更强，也更依赖工具契约。

选择 OR 还是 AND，取决于 terminate 的业务含义。

如果它代表「任一工具发现全局终止条件」，OR 合理，比如用户取消、权限拒绝、事务已完成。

如果它代表「当前工具不需要模型处理自己的结果」，AND 更稳妥，因为其他工具可能仍需模型解释。

DeepSeek Harness 通过 next-step 上下文缓和了 OR 的侵略性，但无法覆盖所有情况。假设两个并行工具都成功，一个写数据库并 concludes，另一个返回一份需要模型分析的报告，又没有追加 context。模型回访会被跳过。工具注册规范需要限制哪些工具可以 conclude，不能把它当成普通便利字段。

顺序提交

DeepSeek Harness 的工具调度器还有一项容易被忽略的约束：执行可以并行，提交保持模型顺序。

调度器维护：

• nextToStart；
• started；
• committed；
• inFlight；
• 按调用位置排列的 slots。

并行工具完成时，只把结果放入对应 slot。commitReady() 从 committed 开始，连续提交已经就绪的结果。后面的工具先完成，也要等待前面的 slot。

这会增加尾部等待时间，但能保证：

• tool/result 顺序稳定；
• additional context 顺序稳定；
• replay 结果稳定；
• 插件观察顺序稳定；
• 同一模型响应在多次运行中的日志结构更一致。

模型生成了 A、B、C 三个调用。若 C 最先完成，直接提交 C 会让后续上下文受网络时序影响。对于事件溯源系统，这类非确定性会扩大恢复和测试成本。

Pi 的并行执行也使用 Promise.all 保留输入数组顺序，最终 tool result message 按原调用顺序发出。两套系统都接受并行执行带来的延迟收益，同时拒绝完成时序污染模型上下文。

DeepSeek Harness 额外支持动态重分类。并行池补充新任务前，会重新读取工具当前 execution mode。前一个工具可能修改注册表，使后续工具从 parallel 变成 exclusive。调度器会停止补充，等待当前池排空，再把 exclusive call 留给下一个 barrier。

这种灵活性会增加 scheduler 状态数量。适合「工具本身能改变工具环境」的 Harness。工具目录完全静态时，预先分组会更简单。

取消语义

工具执行期间的取消，比模型流取消复杂得多。

DeepSeek Harness 的原则可以概括成三条：

1. 停止补充尚未启动的调用；
2. 清空已经启动的调用；
3. 为因取消而跳过的工具写入合成错误结果。

已启动工具可能已经产生副作用，框架不能假装它没有运行。调度器等待这些调用 settle，并按模型顺序提交结果和 additional contexts。

未启动工具则写入一对完整事件：

tool/call
tool/result(error: aborted before dispatch)

这样可以维持模型工具协议的配对关系。恢复和 replay 时，每个模型产生的 tool call 都有对应结果。

内部 scheduler failure 的处理更克制。它停止新 dispatch，等待已经启动的调用结束，然后抛出第一个失败。它不会为剩余调用伪造结果。因为 scheduler failure 与用户取消不同，系统无法确认未提交调用处于什么语义状态。伪造恢复结果可能掩盖调度器缺陷。

这里体现出事件日志的核心要求：日志不只服务 UI，它还是恢复协议。任何 synthetic event 都需要有确定语义。为了让数组长度好看而补事件，会污染后续决策。

Pi 的实现更偏运行时事件流。工具执行异常会被转换成 error tool result，随后继续进入上下文。取消时顺序模式会在每次工具后检查 signal，平行模式也会停止准备后续调用。它的核心目标是把本次 invocation 的 message stream 完整交给调用方，持久日志的闭合约束没有 DeepSeek Harness 那么强。

原因体系

DeepSeek Harness 的 TurnEndReason 包含六种核心结果：

• completed；
• blocked；
• max-tokens；
• aborted；
• error；
• interrupted。

这些状态回答的是整个 turn 如何结束。

completed 覆盖正常文本停止、工具要求收口，以及首步为空。它不承诺长期 Goal 完成。

blocked 来自 pre-step reject。输入可能已经被 inbox 领取，但策略层拒绝进入模型调用。driver 当前会停止，其他尚未领取的普通 prompt 可以继续留在队列。

max-tokens 表示至少一个 step 达到输出上限。它保留为 turn 级质量信号。

aborted 携带取消原因，包括 user、parent、hook 和 disposed。持久导入还可能出现 legacy cause。

error 保存结构化 LlmFailure。LlmError 的信息原样保留，其他异常会被压平为 errorChain 文本，并使用 UNKNOWN code。

interrupted 由持久化恢复层产生。进程崩溃后，后端发现一个开放 turn，会用该状态闭合。live loop 不会主动写入它。

把 crash repair 与 runtime abort 分开很有必要。abort 表示程序收到了取消请求，并有机会执行清理；interrupted 表示生命周期突然消失。两者对副作用审计、重试决策和用户提示都有不同含义。

Pi 主要保留 assistant message 的 stopReason：

• stop；
• length；
• toolUse；
• error；
• aborted。

它更接近最后一次模型调用的结束事实。DeepSeek Harness 的 reason 聚合了多 step turn 的结果。一个字段偏 provider，一个字段偏业务生命周期。

从监控角度看，Pi 的 stopReason 更利于分析模型行为；DeepSeek Harness 的 turn reason 更利于分析任务执行。生产系统通常两类数据都需要。DeepSeek Harness 通过 assistant/message、request events 和 turn/end 同时保留两层事实，日志体积也会更大。

Goal 外循环

长期 Goal 无法靠核心 turn 的 completed 判断。

DeepSeek Harness 采用外围 Round Driver。它监听 Agent 进入 idle，然后检查：

• Agent 实例是否仍然有效；
• inbox 是否存在竞争中的普通 prompt；
• Goal 是否存在；
• Goal phase 是否为 active；
• 当前 activation 是否 armed；
• 已启动 round 数是否低于上限。

满足条件后，Driver 构造一条来源为 goal 的 user message，并调用 agent.followup()。新消息进入 next-turn，打开全新的 turn。

时序如下：

turn/end(completed)
→ agent/status: idle
→ Goal Driver 读取持久状态
→ flush
→ followup(goal round)
→ turn/start

这种结构给每个 Goal Round 一个完整、独立、可恢复的生命周期。进程在两个 Round 之间退出，恢复时可以从最后一个闭合 turn 继续判断。一个覆盖几十轮的巨大 while 会让持久化边界、用户抢占和异常恢复都更困难。

Goal 还维护 phase 与 activation 两组状态。

持久 phase 描述业务状态：

• active；
• complete；
• blocked；
• paused。

进程内 activation 描述自动续行授权：

• armed；
• disarmed。

把两者拆开可以处理 resume 和 fork。一个持久 Goal 仍然 active，不代表新进程应该自动继续消耗预算。恢复后的 active Goal 默认 disarmed，需要人类再次授权。否则某次服务重启可能让多个历史任务同时复活。

达到最大 Round 数时，Goal 会进入 blocked，并记录 round-limit。max-tokens、Agent error、flush failure、driver failure 会 disarm。取消路径也会 pause 或 disarm，防止 idle 后被 Goal Driver 再次拉起。

这里采用了 fail-closed 策略。长期自治任务遇到状态不确定时停止续行。对成本敏感、有写权限的 Agent，这是合理默认值。自动重试可以放在更高层，由持久预算和幂等策略约束。

Goal 收尾

Goal 状态改为 complete 或 blocked 后，当前 turn 通常还会再调用一次模型。

update_goal 工具会修改持久状态，并通过 deferred context 注入收尾指令。工具结果与 <goal_complete> 或 <goal_blocked> context 进入下一 step，模型生成最终面向用户的说明。之后 turn 以 completed 结束。Agent 进入 idle，Goal Driver 读取到非 active phase，不再唤醒。

这解决了状态完成与用户可见输出之间的时间差。

如果 update_goal(complete) 直接 conclude turn，持久状态已经完成，用户界面可能只看到工具卡片，没有自然语言总结。若让模型先写总结再更新状态，模型或进程可能在总结期间失败，Goal 又会保持 active。

DeepSeek Harness 先提交状态，再执行展示收尾。恢复时即便缺少最终文本，Goal 也不会重复工作。用户体验层可以根据 complete 状态补一条提示，或者提供重新生成总结的操作。

代价是 complete 后多一次模型调用，也会增加少量 token 和延迟。我认为这笔成本合理。长期任务的最终输出属于交付结果，不能依赖 UI 猜测工具状态。

Pi 双循环

Pi 的 runLoop() 使用内外两层循环。

内层条件为：

hasMoreToolCalls || pendingMessages.length > 0

它处理工具回访和 steering。外层负责 Agent 本来要停止时的 follow-up。

一次内层迭代包括：

prepareNextTurn
→ 处理 pending steering
→ 调用模型
→ 执行工具
→ 发出 turn_end
→ shouldStopAfterTurn
→ 拉取新的 steering

内层耗尽后，系统调用 getFollowUpMessages()。存在 follow-up 时，将它们设置为 pending，重新进入内层。没有 follow-up 时发出 agent_end。

Pi 提供三个高杠杆控制点：

• getSteeringMessages()；
• getFollowUpMessages()；
• shouldStopAfterTurn()。

这套接口很适合嵌入应用。

steering 处理当前 activity 内的即时干预；follow-up 处理 Agent 自然收口后的补充工作；shouldStopAfterTurn 提供宿主级截停。扩展作者不需要理解持久 inbox，也不需要创建新的状态投影。

复杂度被交给宿主。多个扩展共同提供 follow-up 时，需要上层决定合并方式。进程恢复后，回调内部的临时状态如何重建，也由应用实现。若不同扩展分别定义 Goal、Plan 和审批流程，结束语义会逐渐碎片化。

Pi core 的目标是提供一个小而可组合的运行时。它没有承诺统一的长期任务协议。这个边界和 DeepSeek Harness 的产品定位并不相同。

失败路径

Pi 遇到 assistant error 或 aborted 时，会发出 turn_end 和 agent_end，然后结束当前 invocation。

DeepSeek Harness 会先区分流 finish error、显式 abort 和普通异常。

请求错误可以进入 agent/request-error waterfall。插件能够依据 provider、failure、retry policy 和 signal 决定 retry。重试发生在同一个 step 内，重新创建 assembler，再发一次请求。外部 turn 和 step 边界保持不变。

这种设计使日志更紧凑，但需要谨慎处理重复请求。前一次失败若已经在 provider 侧产生计费，session 中可能只有请求重试后的最终 assistant message。底层观测系统需要独立记录 attempt，不能只靠 conversation event log 统计模型调用次数。

Pi 通常由 stream implementation 或上层配置承担 retry。Agent Loop 接收到的 final message 已经带有 stopReason。职责划分更轻，调用方也更容易替换模型层。

DeepSeek Harness 将 request header、adapter defaults、request context 和 conversation surface 都纳入 session 语义，retry 与恢复自然更靠近 loop。架构更重，换来统一的请求重建能力。

请求序列

DeepSeek Harness 每次构建请求时都会比较当前 header 与 session 中的 baseline。

header 包含：

• provider 和 model；
• reasoning effort、max tokens 等调用配置；
• adapter materialized defaults；
• system prompt；
• tool schemas。

首个 header 记录为 initial 或 resume。配置变化时记录 change。显式开始新消息序列或 surface replacement 后，会记录 series。

结束判断和 request series 没有直接控制关系，但它影响「同一个上下文连续体」的解释。Goal 的自动 Round 可以标记 startsRequestSeries: true，让每轮长期任务拥有独立请求序列。缓存、展示和重放层因此能识别边界。

如果只依靠 turn start 判断新序列，会把工具回访、用户 follow-up、Goal Round 和 compaction 后续请求全部归入一种语义。DeepSeek Harness 单独记录 series，是在为后续缓存和重建保留信息。

成本是日志事件更多，header equality 与 canonicalization 也必须稳定。工具 schema 排序、空字段处理或 adapter defaults 若不规范，可能制造大量无意义 change 事件。代码使用 canonical header 和 deep freeze，正是在控制这种漂移。

日志消费

消费 DeepSeek Harness 日志时，先问清业务方想判断哪一层结束。

判断一次模型调用完成，应读取 step 内的 assistant message、stream finish 和 usage。

判断 turn 是否闭合，应寻找配对的 turn/start 与 turn/end。只有 assistant message 不够。pre-step reject、空 turn、异常和 crash repair 都可能产生不同结构。

判断当前 Agent 是否暂无活动，应读取 status 或等待 whenIdle()。最后一条 turn/end 仍不足以证明 idle，因为 driver 可能已经打开下一 turn。

判断长期 Goal 是否结束，应读取 Goal phase。complete、blocked 和 paused 都会停止自动 Round，业务含义各不相同。

判断 Plan 是否退出，应读取最新 plan/mode.active。看到 exit_plan_mode 调用，只能说明模型提出了退出请求。审批可能被拒绝，pending intent 也可能尚未在 pre-step 提交。

判断会话以后是否还会运行，需要观察 Agent 是否 disposed、是否从 registry 移除，以及外围 scheduler 是否仍能发送消息。idle 和 completed 都没有永久性。

Pi 的消费方式更简单：

• assistant stopReason 描述模型调用；
• turn_end 描述一次模型与工具批次；
• agent_end 描述当前 invocation；
• Goal、Plan 和工作流完成度读取具体扩展状态。

即使已经收到 agent_end，宿主仍然可以再次调用 Agent Loop。它同样不具备永久终止含义。

工程取舍

DeepSeek Harness 为结束判断支付了较高复杂度。

它需要：

• phase 状态机；
• inbox 分类；
• wake latch；
• 平衡的 turn 和 step 事件；
• surface projection；
• request header 重建；
• crash repair；
• Goal activation；
• Plan boundary intent；
• 有序工具提交。

这些机制会增加代码量、测试矩阵和插件开发门槛。一个简单聊天产品采用全套设计，投入可能超过收益。

它适合以下场景：

• 会话需要跨进程恢复；
• Agent 拥有高风险工具；
• 多个插件会同时 steering；
• 需要长期 Goal 与预算控制；
• 日志需要审计和 replay；
• Plan、审批和执行必须跨边界保持一致；
• 子 Agent 和父 Agent 存在取消传播。

Pi 的循环更适合：

• 单次 invocation 生命周期清晰；
• 宿主已经拥有自己的持久化层；
• 扩展数量有限；
• 工作流由应用统一控制；
• 希望快速接入多模型与工具；
• 对 session event vocabulary 没有强约束。

Pi 的小核心减少了框架内部状态。业务一旦开始增加 Goal、审批、自动 follow-up、并发工具策略、恢复和预算，宿主会逐步补齐类似机制。复杂度没有消失，只是落在不同层。

团队选择框架时，不应只比较 Agent Loop 文件有多少行。要看系统准备把「继续运行的权力」放在哪里。

DeepSeek Harness 把权力分散给模型 finish、工具结果、inbox、生命周期 hook 和外围持久状态机，并通过事件日志协调。Pi 把权力集中在当前循环和几个宿主回调中，扩展层可以自行定义更高层协议。

设计建议

如果我们团队要自行实现 Agent Loop，我会保留以下原则。

第一，区分模型结束、工具批次结束、用户 turn 结束和长期任务结束。类型和事件名也要分开，避免一个 done 字段横跨所有层级。

第二，继续执行需要携带数据。插件要求再跑一轮时，应提交 steering 或 follow-up message。单独返回布尔值会让调试和组合越来越困难。

第三，工具调用后的模型回访应被建模为债务。普通工具结果产生一次回复债务，conclude 或 terminate 可以消除债务，steering 又会重新增加消息债务。用这套视角设计状态机，比堆叠 if (hasToolCalls) 更稳定。

第四，最大 token 需要独立结果，且不要执行疑似截断的工具参数。自动修复可以存在，但必须显式记录恢复过程。

第五，并行工具允许乱序完成，持久结果应按模型顺序提交。除非协议明确支持乱序 tool result，否则不要让网络时序改变上下文。

第六，取消必须区分已启动与未启动调用。已启动工具要排空或记录未知结果，未启动工具需要完整的 synthetic result，具体选择取决于日志协议。

第七，idle 不能充当长期完成信号。Goal phase、workflow state 和 Agent lifecycle 应拥有独立状态。

第八，模式切换要提交在请求边界。Plan、权限、模型路由和工具目录的变化，都不应在一个已开始的请求批次中途生效。

第九，恢复后的自动续行默认关闭。长期 Agent 会消耗资金，也可能修改外部系统。新进程接管旧任务时，应重新取得授权或租约。

第十，结束原因需要兼顾机器消费。completed、blocked、max-tokens、aborted、error、interrupted 这类结构化 union，比一段自然语言错误更适合监控、重试和审计。

架构落点

DeepSeek Harness 把结束判断分布在四个控制面上。

模型输出控制 step：还有没有工具回访债务。

inbox 控制 turn：还有没有当前轮待处理消息。

driver 控制 activity：队列耗尽后是否进入 idle。

Goal 与 Plan 控制工作流：idle 后是否开启新 Round，下一请求采用哪种策略。

Pi 将更多判断放在同一个运行循环里。工具调用和 pending steering 驱动内层循环，follow-up 驱动外层循环，shouldStopAfterTurn 提供宿主截停点，队列耗尽后发出 agent_end。

DeepSeek Harness 更接近一个事件溯源的 Agent Runtime。Pi 更接近一个可嵌入的 Agent 执行内核。

评价两者没啥意义，我们需要关注的是其系统边界。

如果产品只需要一次 prompt 驱动的工具循环，Pi 的结构更容易维护。若产品已经出现跨轮 Goal、审批、恢复、多插件 steering 和高风险工具，DeepSeek Harness 的分层会减少后期协议冲突。

Agent Loop 最难处理的部分，从来都不是让模型继续调用工具。真正消耗工程时间的是：它为什么继续、谁允许它继续、失败后还能不能继续、恢复后应不应该继续，以及日志能否解释它曾经做过的每一次选择。

以上。

DeepSeek Harness 把模型、工具、会话、沙箱、文件系统、Agent 循环、调度和 UI 都交给插件。

系统没有一块承载业务能力的固定内核，Cordis 只维护上下文、服务注册、事件分发、依赖激活和副作用回收；Agent 能做什么，由启动时挂入的一棵插件树决定。

传统的插件有注册容易，撤销困难；初始化容易，失败回滚困难；全局单例容易，局部覆盖困难等问题，而 Cordis 把这些困难收进了运行时语义，Harness 再用 session、agent 和 preset 的业务约束补齐它。

今天聊了一下 DeepSeek Harness 的核心 Cordis 架构以及 Cordis 所谓「时空可组合」，究竟怎样落到代码里，又为何适合 Agent Harness 这类持续变化的运行时。

插件的历史

插件架构的历史并不短。Eclipse 在二十多年前已经把 IDE 拆成插件、扩展点和扩展，宿主声明可扩展位置，其他插件通过清单贡献菜单、编辑器和处理逻辑。

OSGi 更进一步，给 bundle 配置安装、启动、停止、更新和卸载生命周期，再通过共享服务注册表完成发布、查找和绑定。服务离开注册表时，依赖方必须跟着处理动态变化。

今天看 Cordis，能找到这些设计的清晰痕迹：动态服务、生命周期、注册表、声明式依赖、事件通知都已有成熟先例。

Cordis 没有发明插件系统。

它简化并重新组合了这些概念，让它们适合 TypeScript 应用内的细粒度组装。OSGi 的部署单元是 bundle，模块、生命周期、服务和安全各有一层；Cordis 的执行单元是 Fiber，一个函数或一个 Service 子类就能成为插件。Eclipse 的扩展点通常由宿主定义结构化清单，Cordis 让服务和类型化事件直接成为扩展面。Agent 运行时里的工具、提示词片段、模型适配器和审批策略变化频繁，如果每次扩展都要引入重量级模块边界，团队很快会绕过框架，重新写回几个全局数组。

Cordis 官方仓库把自己定位为「Meta-Framework of Spatiotemporal Composability」。

从源码看，「元框架」表示它不规定 Agent、Web 服务或机器人该有什么组件，只提供构造框架所需的基础语义。DeepSeek Harness 在其上定义 sessions、tools、llm、agents 等服务，又用这些服务组装产品。Cordis 与 Harness 的关系更接近运行时机制和领域框架，而非通用插件平台与插件集合。

DeepSeek Harness 还把 Cordis 源码直接放进 vendor/，固定在明确的上游提交，并将包名重映射到 @deepseek-ai 命名空间。

项目维护的本地修改包含 Fiber 重入卸载加固、配置更新事务、HMR 精确监听、延迟配置解析等。这增加了维护成本，也换来了框架层的可审计性。Agent 能执行 Shell、修改文件、访问网络，插件生命周期出错会留下进程、监听器、终端模式或权限状态。

此时依赖一个本地的代码白盒，会让人放心一些。

调用链路图

简单的调用图如下所示：

最小内核

Cordis 的根对象是 Context。它同时承担依赖容器、插件挂载入口和事件入口。

服务通过稳定名称出现在 ctx 上，例如 ctx.tools、ctx.llm、ctx.sessions。插件声明 inject 后，Cordis 只有在所需服务可用时才激活它；服务消失，依赖插件也会进入卸载或等待状态。配置文件中条目的先后顺序因此不承担启动顺序，依赖关系才承担。

这种处理解决了传统插件系统的第一个顽疾：隐含初始化顺序。

常见实现会遍历插件数组，依次调用 init。当工具依赖文件系统、文件系统依赖沙箱、UI 又依赖会话时，数组顺序就变成一套没有类型、没有诊断的依赖图。后来插入一个插件，顺序约束可能跨越几十个文件。

Cordis 把需求写进 inject，Fiber 会为每项依赖保存当前实现；缺少依赖时保持 PENDING，依赖齐备后进入 LOADING 和 ACTIVE。启动失败则进入 FAILED。状态机至少让故障有了准确位置。

Context 还是一个代理对象。

插件直接读取 ctx.tools 时，反射层会检查它是否声明过依赖，并沿 Fiber 父链解析实现。未声明就读取会抛错；声明了但当前上下文不可用，也会抛出另一类错误。这种约束防止依赖藏在任意函数深处。源码里依然提供 ctx.get(name) 读取可选服务，区别在于调用方显式接受服务可能不存在。

这里的「服务定义、服务提供方、消费方」三种角色被完整建模。比如文件系统能力不能只写一个接口，也不能只挂一个本地实现。定义方稳定调用协议，提供方接入本地目录或远程沙箱，消费方把能力变成模型可见工具。Harness 把这组关系称为 capability seam。替换沙箱时，Shell、PTY、LSP 只要依赖同一能力面，就能整体迁移到新的执行环境，消费方无需知道提供方运行在本机还是远端。

「一切皆插件」有一个前提是：一切产品能力皆由插件贡献，Cordis 自身仍保留插件得以存在的机制。上下文代理、Fiber 状态机、服务存储、事件总线和 Loader 属于元层。

这并不是系统里没有内核，更准确的说，应该是，内核不拥有模型、工具和循环等产品特权。

空间组合

同一个进程里，服务名称必须稳定，实例又不能全局唯一。两个 Agent 可能选择不同模型、不同工具集、不同 persona 和不同沙箱。如果 ctx.llm 永远指向一个全局对象，插件替换只发生在进程级，无法满足多会话并存。

Cordis 的 Context.isolate 为指定服务名创建一个 realm 标签。服务注册和查找都以该标签定位，同名服务可以在不同子上下文里各自存在。两个 isolate 调用传入同一标签时会加入同一 realm；使用新标签时彼此隔离。子上下文通过原型继承父上下文，隔离映射按层遮蔽，因此局部配置不需要复制整棵容器。

这解释了「空间可组合」的第一层：组合具有位置。插件挂在哪个上下文，决定它提供的服务、注册的监听器和持有的副作用在哪个范围可见。传统依赖注入容器也有 singleton、request、session 等 scope，Cordis 的差异在于作用域与插件树、事件过滤、资源所有权使用同一个 Context 表达。开发者无需在四套 API 之间同步身份。

DeepSeek Harness 又增加了 dsh-scope。它用不透明对象作为 scope key，维护父子关系，并创建带路由身份的事件 receiver。注册视图沿父链向下继承：Agent 能看到所属 preset 的提示词和工具。事件则沿链向上接纳：preset 级监听器能收到其下 Agent 的事件，兄弟 Agent 互不串线。这是第二层空间结构，解决的是领域身份，而非单个服务名的 realm。

为何需要两层？isolate 处理「哪个 tools 服务实例」，dsh-scope 处理「同一工具注册表里，哪些注册项对当前 Agent 可见」。前者适合替换提供方，后者适合对注册内容分层。把所有差异都做成独立服务实例，会放大内存和初始化成本；把所有差异都塞进一个全局注册表，又会让过滤规则散落在调用点。这两层模型把实例隔离和内容路由分开了。

Agent preset 是空间组合的完整应用。一个 preset 的 Cordis 配置会挂在一个长期存在的 scope 下，Agent 创建时把自己的 scope key 绑定到该 preset。相同 preset 的并发首次使用通过 single-flight 共享一次挂载，后续 Agent 复用这份组合。文件变化后，新会话加入新一代组合，已有会话保留原来的代际。这个策略避免会话运行中途突然更换工具或提示词，代价是旧代际要保留到整棵运行时退出，配置频繁变化时内存会按代际增长。

源码还专门审计 preset 子树是否把服务发布到了 root realm。发生这种泄漏时，第二个会话挂载同一 preset 会与第一个冲突，所谓会话级组合也会退化成进程全局状态。DeepSeek Harness 在发布 Agent 前拒绝这种配置。空间隔离若只靠约定，迟早会被一个没有 isolate 的 provider 穿透；运行时审计比文档警告可靠。

这套空间模型存在认知成本。插件作者要同时理解 Context 父链、服务 realm、业务 scope 父链和事件过滤方向（当然，在当前 Vibe Coding 盛行的时代，也可以作者不理解，直接让 AI 来搞）。

在认知不清楚的时候，常见的错误往往表现为某项能力「看不见」或意外泄漏，类型系统无法证明运行时挂载位置。DeepSeek Harness 用 preset 挂载审计、包级 invariant 和真实组合测试降低风险，却没有消除模型复杂度。团队若只需要单进程单 Agent，直接引入整套空间语义会显得过重。

时间组合

插件能挂载只是静态组合。运行期间服务上线、配置改变、插件失败或上下文销毁，系统还要回到一致状态。Cordis 用 Fiber 和 effect 管理这条时间轴。

每次插件应用都会产生一个 Fiber。Fiber 记录父上下文、原始配置、解析后配置、依赖实现快照、生命周期状态和 disposables。插件调用 ctx.effect() 注册副作用，effect 的执行结果返回 disposer。事件监听、服务提供、子插件和访问器最终都进入这套所有权体系。Fiber 卸载时按注册的逆序执行清理，并等待异步清理达到静止状态。

逆序本身不是一个特别要讲的事情，因为这是必须的。

若插件先启动子进程，再注册输出监听，最后暴露服务，销毁时应先撤销服务，停止新请求，再移除监听，最后结束进程。资源创建顺序的反向通常就是依赖安全的拆卸顺序。

传统插件常给出一个 deactivate() 钩子，把所有清理责任推给作者；漏掉一个定时器或事件监听，热加载几次便出现重复执行。Cordis 让每次注册同时产生撤销动作，框架持有所有权。

DeepSeek Harness 的 vendor 版本进一步处理了重入场景：effect 在执行 setup 前先登记所有者包装；插件发布事件时，观察者可能同步卸载它；异步 cleanup 已经开始后，其他调用者仍能等待同一次清理；Fiber 处于 UNLOADING 时拒绝创建新 effect。这些代码看起来全是繁琐的边界处理，但为了保证生命周期并发的安全，一个都不能少。否则插件的热卸载就只是个玩具，没法真正落地。

依赖变化也属于时间组合。某个服务被提供后，反射层通知所有声明该依赖的 Fiber 重新检查；条件满足便激活。服务撤销后，依赖方会卸载并回到等待。OSGi 早已采用动态服务注册表，Cordis 的新意主要在于把动态依赖、作用域上下文和 effect 所有权压进一个很小的进程内模型。代价同样继承自 OSGi：任何持有服务引用越过生命周期的代码，都可能在提供方撤销后继续调用过期对象。Cordis 保存加载时的实现快照，却无法替业务代码管理逃逸引用。

Loader 把时间组合延伸到配置。DeepSeek Harness 的 profile 由多层 bundle patch 叠加：基础 bundle、模式 bundle、profile patch、home patch、命令行 overlay。patch 按 id 定位条目，配置采用整块替换。整块替换要求用户重述保留字段，使用上稍显笨重，却避免深度合并规则在数组、表达式和删除语义上制造歧义。

配置热更新时，Loader 先导入候选插件，再卸载旧实例并应用候选；候选失败会恢复旧插件或旧配置。Group 对一批子条目并发启动，收集全部结果，只要一项失败就删除新增项并重建旧配置。Include 读取候选文件、在副本上应用 patch、完成树协调后才提交缓存。用户 patch 语法错误或新插件启动失败时，最后一棵可用树继续运行。

这已经接近配置事务，却不能等同于数据库事务。

插件 effect 可能调用外部 API、创建远端资源、发送消息；disposer 只能做补偿，无法保证外部世界回滚。Loader 能保证自己管理的树和服务注册恢复，无法撤回所有不可逆副作用。插件开发规范仍要限制初始化期行为，把外部写入延迟到真正的业务请求，或者设计幂等键和补偿路径。

时间组合还带来可观的测试面积。挂载成功只是第一条路径，还要覆盖依赖晚到、依赖撤销、初始化失败、卸载重入、异步清理、热更新失败、回滚再次失败。DeepSeek Harness 要求注册项证明 disposal，产品可见插件还要通过真实 Loader 组合测试。这个成本无法靠框架消失，只能被框架集中暴露。相比线上出现幽灵监听器和半更新状态，还是愿意支付这部分测试费用。

事件契约

插件之间只靠服务调用，会把所有扩展都变成接口方法。宿主每增加一项策略，就要修改服务定义。Cordis 同时提供类型化事件，并区分 emit、parallel、serial、bail 和 waterfall。

DeepSeek Harness 最依赖的是 waterfall。它的监听器拿到 next，调用后把控制权交给下一层，不调用就截断链条。模型请求、工具执行和轮次控制都能被插件包裹。审批策略可以在工具执行前拒绝，重试插件可以包围模型流，日志插件可以观察前后状态。它与 Koa 一类中间件链相似，但事件名和 Context 过滤让同一个分发器覆盖多个能力域。

waterfall 也最容易出错。一个只想记录日志的监听器忘记调用 next()，整条能力链便被短路。DeepSeek Harness 把「必须调用 next()」写进项目级规则，并在事件文档里记录 dispatch mode。类型能保证参数，却很难保证 continuation 一定执行。代码评审和组合测试仍是主要防线。

事件的持久性也被刻意分层。agent/* 和 tools/* 事件用于活跃运行时的拦截；会话事件追加到日志，承担恢复、fork、UI 回放和模型历史投影。DeepSeek Harness 规定「模型可见即已记录」：进入模型请求的输入必须能从 session log 重建。插件若偷偷修改 prompt 却不产生会话事实，重放结果会漂移，问题也无法审计。

这条约束说明，一切皆插件并不意味着一切皆事件。直接能力调用放进 Service，策略和拦截放进实时事件，需要持久化的事实进入 session log。三类通信各自承担调用、扩展和历史。将它们混成一个全局 event bus，短期代码更少，长期会失去时序语义和数据权威。

Agent 适配

Agent Harness 比普通 Web 服务更需要动态组合。模型供应商会变，工具权限随工作区变化，子 Agent 的执行环境可能与父 Agent 不同，UI 还要消费同一份流式过程。如果主循环直接 import 每个能力，任何替换都会改循环；循环逐渐成为依赖最多、风险最高的文件。

DeepSeek Harness 的默认 agent loop 仍然存在，但它也是一个服务提供方。循环读取 session log 生成历史，组装插件贡献的 prompt 和 tool schema，通过 agent/request 进入模型适配器，再经过工具流水线记录结果。扩展点围绕步骤、请求、工具和停止阶段布置。新功能通常挂到这些事件或注册表，项目规则甚至要求修改 agent loop 时同步更新架构文档。

我赞成这种限制。循环承担控制流，频繁承载产品策略后会迅速腐化。压缩上下文、重试、审批、工具超时、计划模式、子 Agent 调度都可以有自己的生命周期与配置。它们进入循环的接口必须少且稳定。插件化不会自动获得解耦，真正起作用的是 DeepSeek Harness 为能力选择了明确的 seam，并拒绝消费方特有逻辑污染定义层。

UI 作为插件也有实际意义。Web 和 headless profile 在共享 base bundle 上增加不同条目，后者可以完全不启动服务器。UI 驱动 ctx.agents，订阅 session/event 渲染状态，没必要成为循环的一部分。服务端、CLI、ACP 和浏览器界面可以共享会话及 Agent 语义，同时保留自己的传输和展示逻辑。

插件树还提供自省基础。Fiber 保留名称、状态、依赖和 effect 元数据，DeepSeek Harness 能实现查看、挂载、卸载自身插件的能力。对 Agent 而言，这比普通应用更敏感：模型可以通过工具改变运行时，错误配置可能直接扩大权限。源码中的 sandbox 和 approval 仍是独立能力，插件架构没有天然安全性。自修改必须受工具权限、配置校验和作用域审计约束。

架构代价

第一项代价是启动与运行时开销。每个插件产生 Fiber，服务访问经过 Proxy 和反射解析，事件分发要执行作用域过滤，注册项还要保存 disposer 与诊断元数据。对于 LLM Agent，单次模型请求通常以百毫秒到秒计，这些 JavaScript 调度开销很难成为主要瓶颈；高频 token chunk、文件扫描或终端字节流若全部穿过通用事件总线，成本会被放大。DeepSeek Harness 把流式模型输出定义为能力语义，但大量数据处理仍应留在具体 provider 内，事件只承载必要扩展点。

第二项代价是故障面扩大。插件初始化可以同步抛错、异步拒绝、等待缺失服务，也可能在 disposer 中失败。Group 并发启动缩短时间，却会带来多个兄弟同时失败的 AggregateError。DeepSeek Harness 的 boot 会等待 Loader 结算，审计所有启用条目是否加载与激活，失败时先 dispose 部分构造的上下文，再退出。少做任何一步，都可能让终端停留在 raw mode，或者让后台 watcher 继续运行。

第三项代价是配置成为编程接口。cordis.yml 支持 !!js 表达式，条目可以按环境禁用，配置会在依赖激活后求值。灵活性很高，静态分析能力随之下降。表达式读取服务时，求值时机与上下文位置都会影响结果。DeepSeek Harness 只允许 config 和 disabled 使用插值，其他元数据保持字面量，并让错误尽早暴露。这仍要求运维人员理解插件依赖和 patch 覆盖语义，配置文件已经超出普通 YAML 参数表的复杂度。

第四项代价是生态兼容。Cordis 的服务名和事件类型提供了源码级协议，插件版本升级仍可能修改配置、事件 payload 或生命周期假设。DeepSeek Harness 目前处于预发布阶段，仓库规则允许直接拒绝旧磁盘格式，也没有承诺 session 格式兼容。现在的可组合性主要服务于同一发行版内的替换和扩展，尚不能推导出跨版本插件 ABI 稳定。

第五项代价是组织治理。一切都能成为插件后，团队容易把每段十几行逻辑都拆成包，形成依赖图膨胀、文档分散和测试启动缓慢。DeepSeek Harness 用 package 分组、Service Definition/Provider/Consumer 角色、每包 README、运行时 invariant 和真实组合测试控制边界。这些规范本身就是成本。小团队若没有维护扩展生态或多 profile 的需求，模块化函数加显式依赖可能更合适。

历史对照

从 OSGi 看 Cordis，动态服务和生命周期联动已有先例。服务注册、发现、撤销后触发依赖变化，这条主线几乎一致。Cordis 值得学习的新点，是把资源清理统一成 effect，并让子插件、服务、监听器都归属于同一个 Fiber。OSGi 的 bundle 生命周期更完整，也更重；Cordis 选择应用内细粒度对象，失去了类加载隔离、标准版本解析和安全层，获得了低门槛组合。

从 Eclipse 看 DeepSeek Harness，profile 与 bundle patch 很像部署时组装，Service 和事件类似扩展点。差异在于 Eclipse 扩展通常围绕稳定宿主能力，DeepSeek Harness 连 agent loop 和 UI 都可替换，核心插件与第三方插件共享同一挂载机制。这个平权减少了特权内核，风险也更集中到协议治理：循环能被替换，不代表任何替代循环都遵守 session log、权限和工具时序约束。

从依赖注入容器看，Cordis 的服务解析并不陌生。新的组合来自 DI 与生命周期的绑定。普通容器负责构造对象，定时器、监听器和子进程仍由业务代码清理；Cordis 把注册动作收敛成 effect。空间 scope 与时间 ownership 同时存在，插件才能在某个 Agent 范围内挂载，并随该 Agent 完整撤销。

从微内核看，DeepSeek Harness 的内核确实很轻，但其 Loader 和配置协调已经承担不少平台职责。它要解析模块、等待依赖、处理 HMR、执行事务式更新、保存最后可用树、输出诊断。这提醒我，微内核减少的是业务特权，不会减少生命周期复杂度。能力越动态，内核对失败语义的要求越高。

Cordis 的贡献可以概括为一种紧凑的组合坐标：Context 决定插件位于哪里，Fiber 决定插件在何时有效，Service 负责直接能力，Event 负责横切协作，effect 负责撤销。DeepSeek Harness 在这个坐标系上加入 Agent scope、持久会话事件和配置事务，使其能承载多会话、多 profile 与热更新。

工程取舍

当我想要用类似架构时，会先确认三个条件，基于这三个条件判断来是否采用。

其一，能力确实需要独立替换，至少存在两个生产提供方或明确的外部扩展需求。

其二，同一进程需要多套组合并存，或者运行期间需要可靠更新。

其三，团队愿意为卸载、回滚和真实组合测试持续付费。

缺少这些条件，插件框架容易沦为复杂的工厂模式。

能力切分要从消费方开始。先列出谁调用、调用时需要哪些稳定语义，再设计 Service Definition；随后实现 provider，最后把面向模型的 schema、展示和错误文本留给 consumer。接口只有一个内部调用者时，保留私有闭包，不急着升格为公共 service。可替换性必须由真实替代者证明。

所有注册都要有明确所有者。注册工具、提示词片段、适配器、监听器时同步返回 disposer；卸载测试要观察注册项确实消失。涉及异步资源时，dispose 完成的定义要包含子进程退出、队列排空和 watcher 关闭，不能只发出取消信号。DeepSeek Harness 对 Fiber quiescence 的处理值得照搬。

配置更新要区分内存一致性和外部副作用。Loader 可以恢复旧树，插件初始化若已经创建云资源，回滚需要业务补偿。规则可更保守一些：挂载阶段只做校验和本地注册，外部写操作放到带幂等标识的运行阶段。确实要在初始化创建资源时，必须让 disposer 能识别部分完成状态。

作用域要控制在两种以内。实例隔离与注册可见性已经足够表达多数 Agent 场景，再增加租户、请求、工作区、角色四套独立 scope，调试成本会失控，需要根据实际业务需求和必要性来判断。当需要新增维度时，先判断它属于服务实例选择、注册过滤、持久数据权限还是请求参数。很多所谓新 scope，其实只是一次显式参数传递。

事件也要克制。需要唯一返回值的调用用 Service，需要持久恢复的事实写 session log，需要多个插件观察或包裹的阶段才用事件。waterfall 必须把短路当成公共协议，监听器顺序也要有测试。事件名虽然能降低导入耦合，却会增加时序耦合；后者通常更难排查。

小结

DeepSeek Harness 选择 Cordis，解决的主要矛盾是 Agent 能力变化速度与运行时一致性之间的冲突。模型、工具、沙箱和 UI 都可以替换并不稀奇；这些能力可以在局部作用域内共存，能随依赖变化启停，能在配置失败后保留旧树，卸载时还能回收监听器、服务和子插件，才构成可用的插件架构。

它也没有抹平工程风险。Proxy 隐藏了查找路径，双层 scope 增加理解成本，热更新无法回滚任意外部副作用，预发布阶段也缺少跨版本兼容承诺。团队采用这套思路时，应复制它的生命周期纪律和能力边界，别只复制「一切皆插件」的目录结构。

源码给我们一些启发，把插件设计的评审顺序倒过来：先问如何撤销，再问如何注册；先证明局部挂载不会泄漏，再讨论全局复用；先定义失败后保留哪一棵树，再讨论热更新速度。做到这些，时空可组合才是一组可以验证的运行时语义。

这套架构个人理解是想往 Agent 的实时「自生长」，通过 AI 的能力在使用过程中让自己更强大。

逼逼这么多，主要还是在这个过程中学习一下，说实话，有了 DeepSeek Harness，想自己开发一个专属的 Agent ，快捷方便了很多，eg且这是 MIT 协议的。

以上。

参考资料

• DeepSeek Harness 架构文档
• Cordis：Meta-Framework of Spatiotemporal Composability
• OSGi Service Layer
• OSGi Architecture
• Eclipse Plug-in Architecture

在我们和 AI 聊天中，AI Chat 都采用了一种「打字机」式效果的实时响应方式，AI 的回答逐字逐句地呈现在我们眼前。

在实现这个功能的技术方案选择上，不管是 DeepSeek ，还是腾讯元宝都在这个对话逻辑中选择了使用 SSE，如下面 4 张图：

这是为啥，它有什么优势，以及如何实现的。

SSE 的优势

因为它在该场景下的优势非常明显，主要是以下 4 点：

1.场景的高度匹配。

AI 对话的核心交互模式是：

1. 用户发起一次请求（发送问题）。
2. AI 进行一次持续的、单向的响应输出（生成回答）。

SSE 的单向通信（服务器 → 客户端）模型与这个场景高度切尔西。它就像一条专门为服务器向客户端输送数据的「单行道」，不多一分功能，也不少一毫关键。

相比之下，WebSocket 提供的是全双工通信，即客户端和服务器可以随时互相发送消息，这是一条「双向八车道高速公路」。为了实现 AI 的流式回答，我们只需要其中一个方向的车道，而另一方向的车道（客户端 → 服务器）在 AI 回答期间是闲置的。在这种场景下使用 WebSocket，无异于「杀鸡用牛刀」，引入了不必要的复杂性。用户的提问完全可以通过另一个独立的、常规的 HTTP POST 请求来完成，这让整个系统的架构更加清晰和解耦。

2.HTTP 原生支持，与生俱来的优势

SSE 是建立在标准 HTTP 协议之上的。这意味着：

• 无需协议升级：SSE 连接的建立就是一个普通的 HTTP GET 请求，服务器以 Content-Type: text/event-stream 响应。而 WebSocket 则需要一个特殊的「协议升级」（Upgrade）握手过程，从 HTTP 切换到 ws:// 或 wss:// 协议，过程相对复杂。
• 兼容性极佳：由于它就是 HTTP，所以它能天然地穿透现有的网络基础设施，包括防火墙、企业代理、负载均衡器等，几乎不会遇到兼容性问题。WebSocket 有时则会因为代理服务器不支持其协议升级而被阻断。并且云服务商对于 Websocket 的支持并不是很完善。
• 实现轻量：无论是前端还是后端，实现 SSE 都非常简单。前端一个 EventSource API 即可搞定，后端也只需遵循简单的文本格式返回数据流。这大大降低了开发和维护的成本。

3.断网自动重连，原生容错

这是 SSE 的「王牌特性」，尤其在网络不稳定的移动端至关重要。

想象一下，当 AI 正在为我们生成一篇长文时，我们的手机网络突然从 Wi-Fi 切换到 5G，造成了瞬间的网络中断。

• 如果使用 WebSocket：连接会断开，我们需要手动编写复杂的 JavaScript 代码来监听断开事件、设置定时器、尝试重连、并在重连成功后告知服务器从哪里继续，实现起来非常繁琐。
• 如果使用 SSE：浏览器会自动处理这一切。EventSource API 在检测到连接中断后，会自动在几秒后（这个间隔可以通过 retry 字段由服务器建议）发起重连。更棒的是，它还会自动将最后收到的消息 id 通过 Last-Event-ID 请求头发送给服务器，让服务器可以从中断的地方继续推送数据，实现无缝的「断点续传」。当然，Last-Event-ID 的处理逻辑需要服务端来处理。

这种由浏览器原生提供的、可靠的容错机制，为我们省去了大量心力，并极大地提升了用户体验。

4. 易于调试

因为 SSE 的数据流是纯文本并通过标准 HTTP 传输，调试起来异常方便：

• 我们可以直接在浏览器地址栏输入 SSE 端点的 URL，就能在页面上看到服务器推送的实时文本流。
• 我偿可以使用任何 HTTP 调试工具，如 curl 命令行或者 Chrome 开发者工具的「网络」面板，清晰地看到每一次数据推送的内容。

而 WebSocket 的数据传输基于帧，格式更复杂，通常需要专门的工具来调试和分析。

使用 SSE 实现「打字机」效果

1.后端——调用大模型并开启「流式」开关

当后端服务器收到用户的问题后，它并不等待大语言模型生成完整的答案。相反，它在调用 LLM 的 API 时，会传递一个关键参数：stream=True。

这个参数告诉 LLM：「请不要等全部内容生成完再给我，而是每生成一小部分（通常是一个或几个‘词元’/Token），就立刻通过数据流发给我。」

下面是一个使用 Python 和 OpenAI API 的后端伪代码示例：

from flask import Flask, Response, request
import openai
import json

app = Flask(__name__)

# 假设 OpenAI 的 API Key 已经配置好
# openai.api_key = "YOUR_API_KEY"

@app.route('/chat-stream')
def chat_stream():
    prompt = request.args.get('prompt')

    def generate_events():
        try:
            # 关键：设置 stream=True
            response_stream = openai.ChatCompletion.create(
                model="gpt-4", # 或其他模型
                messages=[{"role": "user", "content": prompt}],
                stream=True 
            )

            # 遍历从大模型返回的数据流
            for chunk in response_stream:
                # 提取内容部分
                content = chunk.choices[0].delta.get('content', '')
                if content:
                    # 关键：将每个内容块封装成 SSE 格式并 yield 出去
                    # 使用 json.dumps 保证数据格式正确
                    sse_data = f"data: {json.dumps({'token': content})}\n\n"
                    yield sse_data

            # (可选) 发送一个结束信号
            yield "event: done\ndata: [STREAM_END]\n\n"

        except Exception as e:
            # 错误处理
            error_message = f"event: error\ndata: {json.dumps({'error': str(e)})}\n\n"
            yield error_message

    # 返回一个流式响应，并设置正确的 MIME 类型
    return Response(generate_events(), mimetype='text/event-stream')

if __name__ == '__main__':
    app.run(threaded=True)

在这段代码中，有几个关键点：

1. stream=True：向 LLM 请求流式数据。
2. 生成器函数（generate_events）：使用 yield 关键字，每从 LLM 收到一小块数据，就立即将其处理成 SSE 格式（data: ...\n\n）并发送出去。
3. Response(..., mimetype='text/event-stream')：告诉浏览器，这是一个 SSE 流，请保持连接并准备接收事件。

2.SSE 格式的约定

后端 yield 的每一条 data: 都像是一个个装着文字的信封，通过 HTTP 长连接这个管道持续不断地寄给前端。

前端收到的原始数据流看起来就像这样：

data: {"token": "当"}

data: {"token": "然"}

data: {"token": "，"}

data: {"token": "很"}

data: {"token": "乐"}

data: {"token": "意"}

data: {"token": "为"}

data: {"token": "您"}

data: {"token": "解"}

data: {"token": "答"}

data: {"token": "。"}

event: done
data: [STREAM_END]

看 DeepSeek 和腾讯元宝的数据格式，略有不同，不过有一点，都是直接用的 JSON 格式，且元宝的返回值相对冗余一些。 且都没有 data: 的前缀。

3.前端监听并拼接成「打字机」

前端的工作就是接收这些「信封」，拆开并把里面的文字一个个地追加到聊天框里。

<!-- HTML 结构 -->
<div id="chat-box"></div>
<input id="user-input" type="text">
<button onclick="sendMessage()">发送</button>

<script>
    let eventSource;

    function sendMessage() {
        const input = document.getElementById('user-input');
        const prompt = input.value;
        input.value = '';

        const chatBox = document.getElementById('chat-box');
        // 创建一个新的 p 标签来显示 AI 的回答
        const aiMessageElement = document.createElement('p');
        aiMessageElement.textContent = "AI: ";
        chatBox.appendChild(aiMessageElement);

        // 建立 SSE 连接
        eventSource = new EventSource(`/chat-stream?prompt=${encodeURIComponent(prompt)}`);

        // 监听 message 事件，这是接收所有 "data:" 字段的地方
        eventSource.onmessage = function(event) {
            // 解析 JSON 字符串
            const data = JSON.parse(event.data);
            const token = data.token;

            if (token) {
                // 将新收到的文字追加到 p 标签末尾
                aiMessageElement.textContent += token;
            }
        };

        // 监听自定义的 done 事件，表示数据流结束
        eventSource.addEventListener('done', function(event) {
            console.log('Stream finished:', event.data);
            // 关闭连接，释放资源
            eventSource.close();
        });

        // 监听错误
        eventSource.onerror = function(err) {
            console.error("EventSource failed:", err);
            aiMessageElement.textContent += " [出现错误，连接已断开]";
            eventSource.close();
        };
    }
</script>

这段代码主要有如下的点：

1. new EventSource(...)：发起连接。
2. eventSource.onmessage：这是主要的处理函数。每当收到一条 data: 消息，它就会被触发。
3. aiMessageElement.textContent += token;：这就是「打字机」效果的精髓所在——持续地在同一个 DOM 元素上追加内容，而不是创建新的元素。
4. eventSource.close()：在接收到结束信号或发生错误后，务必关闭连接，以避免不必要的资源占用。

EventSource 的来源与发展

在 SSE 标准化之前，Web 的基础是 HTTP 的请求-响应模型：客户端发起请求，服务器给予响应，然后连接关闭。这种模式无法满足服务器主动向客户端推送信息的需求。为了突破这一限制，开发者们创造了多种「模拟」实时通信的技术。

1. 短轮询：这是最简单直接的方法。客户端通过 JavaScript 定时（如每隔几秒）向服务器发送一次 HTTP 请求，询问是否有新数据。无论有无更新，服务器都会立即返回响应。这种方式实现简单，但缺点显而易见：存在大量无效请求，实时性差，并且对服务器造成了巨大的负载压力。
2. 长轮询：为了改进短轮询，长轮询应运而生。客户端发送一个请求后，服务器并不会立即响应，而是会保持连接打开，直到有新数据产生或者连接超时。一旦服务器发送了数据并关闭了连接，客户端会立即发起一个新的长轮询请求。这大大减少了无效请求，提高了数据的实时性，但仍然存在 HTTP 连接的开销，并且实现起来相对复杂。
3. Comet：一个时代的统称：在 HTML5 标准化之前，像长轮询和 HTTP 流（HTTP Streaming）这样的技术被统称为 Comet。 Comet 是一种设计模式，它描述了使用原生 HTTP 协议在服务器和浏览器之间实现持续、双向交互的多种技术集合。 它是对实现实时 Web 应用的早期探索，为后来更成熟的标准化技术（如 SSE 和 WebSockets）奠定了基础。

随着 Web 应用对实时性要求的日益增长，需要一种更高效、更标准的解决方案。

• WHATWG 的早期工作：SSE 机制最早由 Ian Hickson 作为「WHATWG Web Applications 1.0」提案的一部分，于 2004 年开始进行规范制定。
• Opera 的先行实践：2006 年 9 月，Opera 浏览器在一项名为“Server-Sent Events”的功能中，率先实验性地实现了这项技术，展示了其可行性。
• HTML5 标准化：最终，SSE 作为 HTML5 标准的一部分被正式确立。它通过定义一种名为 text/event-stream 的 MIME 类型，让服务器可以通过一个持久化的 HTTP 连接向客户端发送事件流。 客户端一旦与服务器建立连接，就会保持该连接打开，持续接收服务器发送的数据。

SSE 的本质是利用了 HTTP 的流信息机制。服务器向客户端声明接下来要发送的是一个数据流，而不是一次性的数据包，从而实现了一种用时很长的「下载」过程，服务器得以在此期间不断推送新数据。

其返回内容标准大概如下：

event-source 必须编码成 utf8 的格式，消息的每个字段都是用”\n”来做分割，下面 4 个规范定义好的字段：

1. Event: 事件类型
2. Data: 发送的数据
3. ID：每一条事件流的ID
4. Retry: 告知浏览器在所有的连接丢失之后重新开启新的连接等待的事件，在自动重连连接的过程中，之前收到的最后一个事件流ID会被发送到服务器

在实际中，大概率不一定按这个标准来实现。对于一些重连的逻辑需要自行实现。

现在大部分的浏览器都兼容这个特性，如图：

参考资料：

1. en.wikipedia.org/wiki/Server…
2. learn.microsoft.com/zh-cn/azure…
3. www.cnblogs.com/openmind-in…
4. javascript.ruanyifeng.com/htmlapi/eve…

以上。

我自己也深度使用了，包括文章撰写和代码输出，说实话，思考的过程确实惊艳了我。它的思考逻辑比我更完善，推导路径也更显性。

但今天我们聊的不是这些「高光时刻」，而是我们在实际使用过程中常常遇到的不可用场景：

“服务器繁忙，请稍后再试。”

是的，DeepSeek 的繁忙（也可以叫故障？）提示几乎成了高频词。无论是免费用户还是付费 API 调用者，都可能在关键时刻遭遇「空文本返回」、「响应超时」、「重试多次仍异常」等问题。

1. DeepSeek 的可用性表现

首先我们看一下官方的记录： https://status.deepseek.com/

总结起来如下：

• 网页/API 性能异常（Web/API Degraded Performance）
  • 持续时间： 2025 年 1 月 27 日至今（2 月 5 日仍在监控中）
  • 影响范围： API 和网页服务同时出现性能下降，部分用户请求超时或失败。从实际使用体验来看，基本属于不可用的状态了，但是官方的状态还是可用，仅性能问题，这里的状态指标和实际还是有一些出入。
• API 持续故障（Major outage/Partial outage）：
  • 持续时间：2025 年 1 月 27 日到 2 月 5 日
  • 影响范围：持续影响 API 调用，故障持续时间较长，作为一个付费的能力，这是不合格的。
• 网页对话服务不间断故障：
  • 持续时间：2025 年 1 月 27 日到 1 月 31 日
  • 影响范围：持续影响网页用户的使用，在用户的反馈中

从结果来看，DeepSeek 还没有做好应对海量用户的情况，不管是从资源部署，还是工程建设方面，都不是一个合格的状态。

在写这篇文章的时候，除了第一次正常返回，后续都是「服务器繁忙，请稍后再试。」 如下图所示：

从用户能看到的表象来看，自 2025 年 1 月底至 2 月初，DeepSeek 多次出现服务中断：

• 深度思考与联网搜索功能失效：用户使用核心功能时频繁提示「技术原因暂不可用」，仅保留基础对话能力。
• API 服务波动：付费用户调用接口时返回空文本或延迟异常，甚至因「服务器资源紧张」暂停充值。
• 注册与登录拥堵：因恶意攻击导致注册功能瘫痪。

DeepSeek 官方将问题归因于突发流量、系统升级适配、底层基础设施波动，并强调「稳定性是首要任务」。但用户更直观的感受是：服务可用性不足，容错机制缺失。

2. AIGC 产品和互联网产品的天然差异

DeepSeek 作为一个 AIGC 的产品，其和传统的互联网产品就存在天然的差异：

2.1 响应时间与计算资源消耗

传统互联网产品

• 主要依赖数据库查询、预定义的业务逻辑和缓存，响应时间通常较短，且可预测。
• 计算资源需求相对稳定，系统可扩展性较强。

AIGC 产品

• 依赖深度学习模型进行推理，计算量大，响应时间较传统产品长，且可能因模型复杂度、输入长度等因素波动。
• 需要强大的 GPU 计算资源，服务器负载高，可能导致响应延迟或服务不可用。
• 可能需要异步处理或流式输出（如 ChatGPT 的逐字生成），以改善用户体验。

2.2 可靠性与稳定性

传统互联网产品

• 由于功能是规则驱动的，系统行为可预测，崩溃或异常情况较少。
• 依赖负载均衡、CDN、数据库复制等机制，保障高可用性（通常可达 99.99% 以上）。

AIGC 产品

• 生成式AI的输出不确定，在不同运行环境、不同模型版本下可能产生不同结果，影响用户体验的一致性。
• 可能受到模型崩溃、推理失败、内存爆炸、API 速率限制等问题的影响，导致服务不可用或部分功能异常。
• 需要额外的故障检测、自动重试、回退机制（如降级到预定义模板或缓存内容）来提升系统可用性。

2.3 可控性与一致性

传统互联网产品

• 业务逻辑是确定性的，相同输入通常会产生相同输出，保证用户体验的一致性。虽然有「千人千面」的算法，但是其本质上是可控的
• 开发人员可以精确控制系统行为，便于调试和优化。

AIGC 产品

• AI 生成内容的不可预测性导致相同输入可能产生不同的输出，影响可控性和一致性。
• 需要温度参数（Temperature）、Top-K 采样等技术来调整生成稳定性，但仍无法完全保证一致性。
• 可能需要缓存机制、提示词优化（Prompt Engineering）或微调模型来提高可控性。

2.4 可扩展性

传统互联网产品

• 主要依赖水平扩展（如增加服务器、数据库分片）来提升性能。
• 由于业务逻辑固定，扩展后的系统可保持较高的一致性。

AIGC 产品

• 由于深度学习推理的计算密集型特性，水平扩展难度较高，需要依赖专用硬件（如 GPU）。
• 高并发场景下，可能需要分布式推理、模型量化、边缘计算等优化策略来提升可扩展性。
• 可能采用多级缓存（如存储常见问题的预生成答案，在产品中是否能使用待确认）来减少推理开销。

2.5 错误处理与恢复机制

传统互联网产品

• 由于逻辑清晰，错误通常可以通过日志分析、异常处理机制快速排查和修复。
• 具备回滚机制，当系统发生故障时，可以回退到稳定版本。

AIGC 产品

• 由于模型的黑箱特性，错误较难追踪。
• 可能需要人机协同（Human-in-the-loop）机制，让人工审核关键任务的生成内容。
• 需要自动调整机制（如 RAG，Retrieval-Augmented Generation），结合外部知识库提高准确性。

2.6 可维护性与升级

传统互联网产品

• 代码和数据库可以模块化升级，通常只影响部分功能。
• 版本管理清晰，可通过灰度发布、A/B 测试等方式进行平滑更新。

AIGC 产品

• 模型升级可能导致行为变化，新模型可能生成完全不同的内容，影响可用性。
• 需要持续微调（Fine-tuning）或增强检索（RAG），以适应新需求。
• 可能需要模型版本管理（如 OpenAI API 的 GPT-4.0 vs. GPT-3.5），让用户可选择不同模型版本，以保证兼容性。

AIGC 产品在系统可用性上面临更大的挑战，主要在于响应时间、可靠性、可控性和错误处理等方面。为了提升可用性，需要结合缓存优化、模型优化、人工审核、错误监测、版本管理等策略，从而确保系统的高效性和稳定性。

3. 借鉴传统互联网产品的可用性策略

在面对 DeepSeek 这样 AIGC 产品的可用性挑战时，我们可以借鉴传统互联网产品的高可用性策略。以下是三种核心策略：隔离、限流和弹性扩展，它们对于提升整体服务的稳定性和可靠性至关重要。

3.1 隔离

隔离 是指将不同类型的流量、服务和资源进行物理或逻辑上的分离，以减少单点故障的影响，提高系统的稳定性。

（1）传统互联网产品的隔离策略

• 数据库读写分离：使用主从数据库架构，将读请求和写请求分离，提高数据库吞吐能力。
• 微服务架构：将不同的业务模块拆分为独立的微服务，避免单个模块的故障影响整个系统。
• 多数据中心部署：在不同地域部署多个数据中心，确保某个数据中心故障时，服务仍然可用。

（2）AIGC 产品中的隔离策略

• 模型推理服务隔离：不同的 AI 任务（如文本生成、代码补全、图像生成）使用独立的推理服务，以避免相互影响。
• 缓存与实时推理分离：对于常见问题或高频请求，使用缓存存储预生成的答案，减少对 AI 推理的依赖。
• 免费用户和付费用户隔离：将高优先级的计算资源分配给付费用户，确保他们在高负载时仍能获得稳定的服务。
• 企业用户和个人用户隔离：针对企业用户的部署资源和个人用户的资源做隔离，甚至对于企业用户做多个隔离泳道。

（3）隔离策略解决的问题

• 减少单点故障，避免某个服务异常影响整个系统。
• 优化资源利用，确保高优先级任务不会被低优先级任务拖累。
• 提高系统韧性，即使部分服务故障，核心功能仍可正常运行。

（4）隔离策略的注意事项

• 隔离的粒度需要合理设计，过度拆分可能导致管理复杂度上升，系统之间的通信成本增加。
• 监控与调度，确保不同隔离层的资源调度合理，避免出现某些区域资源过载，而其他区域资源空闲的情况。

3.2 限流

限流 是指在高并发情况下，对请求进行限制，以防止系统过载，保障关键用户和服务的稳定性。

（1）传统互联网产品的限流策略

• 令牌桶/漏桶算法：限制请求速率，确保系统不会被短时间内的流量高峰压垮。
• IP 级限流：对单个 IP 地址的请求频率进行限制，防止恶意爬虫或 DDoS 攻击。
• 用户级限流：根据用户级别（普通用户、VIP 用户）设置不同的 QPS 上限。

（2）AIGC 产品中的限流策略

• API 访问限流：对于 DeepSeek 这样的 AI API，限制每个用户的最大请求频率，防止个别用户占用过多计算资源。以及对于 IP 的访问限流。
• 任务队列管理：对于高计算消耗的任务（如长文本生成、复杂代码推理），采用任务排队机制，避免瞬时请求超载。排队机制在文生图的场景下属于通用方案，以 MJ 为例，其商业模式就在于任务数，任务能力的不同，底层还是资源的不同。
• 用户限流：以某种代币的方式发放给免费用户，使其有一定的使用次数限制，增加浏览器指纹等用户级的限制，减少用户的并发使用情况，以及增加对话数的限制等。
• 动态限流：根据服务器的当前负载自动调整限流策略，在资源紧张时降低 QPS，在资源充足时放宽限制。

（3）限流策略解决的问题

• 防止系统崩溃，确保 AI 服务在高并发情况下仍能稳定运行。
• 优化资源分配，优先保证高价值用户的服务体验。
• 抵御恶意攻击，防止 DDoS 攻击或恶意爬取 API 造成的资源滥用。

（4）限流策略的注意事项

• 限流策略需要动态调整，不能一刀切，否则可能导致正常用户体验下降。
• 需要提供合理的错误反馈，例如「当前请求过多，请稍后重试」而不是简单的「服务器错误」。
• 与缓存结合使用，对于常见请求，优先返回缓存结果，减少对 AI 推理的调用次数。这个点在产品层面需要考虑，确实，和传统互联网产品相比，缓存在 AIGC 产品中的使用需要更谨慎一些。

3.3. 弹性扩展

弹性扩展 是指根据实际流量动态调整计算资源，以提高系统的可用性和响应速度。

（1）传统互联网产品的弹性扩展策略

• 自动扩容：使用云计算（如 AWS Auto Scaling、Kubernetes HPA）自动增加或减少服务器实例。
• 负载均衡：使用 Nginx、CDN、反向代理等技术，将流量均匀分配到不同的服务器节点上。
• 冷/热数据分离：将访问频率高的数据放入高速缓存，减少数据库查询压力。

（2）AIGC 产品中的弹性扩展策略

• GPU 资源动态调度：由于 AI 推理高度依赖 GPU，可以采用动态 GPU 分配策略，根据请求量调整 GPU 负载。
• 多模型并行推理：对于高负载场景，可以部署多个副本的 AI 模型，采用负载均衡策略分配请求。
• 推理任务分批处理：对于大规模生成任务，采用批处理方式，提高计算效率，减少单次推理的成本。

（3）弹性扩展策略解决的问题

• 避免资源浪费，在低流量时减少计算资源，降低运营成本。
• 提升系统吞吐能力，在高流量时快速扩展计算能力，确保服务稳定。
• 提升响应速度，减少高并发情况下的请求排队时间，提高用户体验。

（4）弹性扩展策略的注意事项

• 扩容速度需要优化，如果扩容响应过慢，可能导致短时间内大量请求失败。
• 成本控制，GPU 计算资源昂贵，需要权衡服务质量与成本。
• 监控与预警，需要实时监控系统负载，提前预测流量高峰，避免突发情况导致系统崩溃。

AIGC 更多的问题还是算力资源的问题，从 DeepSeek 的服务器 IP 来看，其使用的是华为云，后端推理算力不确定是哪家的。基于多云的弹性调度是一个可以考虑的方案，当然，前提是成本能够扛得住。

4. 从故障看 AIGC 可用性策略的四大核心矛盾

1. 算力需求与资源调度的失衡
   AIGC 模型的推理成本极高。当用户量激增或遭遇攻击时，弹性伸缩能力不足可能直接导致服务崩溃。

2. 功能复杂度与稳定性的博弈
   DeepSeek 的「深度思考」依赖多模态数据处理和强化学习技术，但功能越复杂，系统耦合性越高，单点故障风险越大。

3. 用户预期与容灾能力的落差
   用户对 AIGC 的期待是「类人级响应」，但实际服务常因网络抖动、模型加载延迟等问题降级为「机械式回复」。

4. 商业化压力与技术投入的冲突
   尽管 DeepSeek 登顶多国应用商店榜单，但其快速扩张可能透支了技术团队的运维能力，导致故障频发后被迫暂停 API 充值。

DeepSeek 的故障并非个例，而是 AIGC 行业集体面临的挑战。从技术角度看，模型能力与系统稳定性需同步进化；从用户角度看，容忍度与预期管理同样关键。

未来，AIGC 服务的竞争不仅是「谁更聪明」，更是「谁更可靠」，特别是在企业应用的场景。毕竟，再惊艳的思考过程，若总以「服务器繁忙」收场，终将消磨用户的耐心与信任。

以上。