我从 DeepSeek Harness 的讨论区里，反推出了一套端云协同 Agent 的架构

先交代下我是怎么注意到这事的。

最早是在 V2EX 上刷到过 Offer快 创始人的一些踪迹——当时这个产品就很神秘，一个叫 OfferKuai 的 AI 求职 Agent，号称能 7×24 全自动替你筛岗、投递、跟 HR 沟通。官网写的是全流程自动化求职，但诡异的是，这团队几乎不发声，没有大规模开放测试，媒体报道也都是"内测中"、"暂停下载"的状态，原定 2026 年 4 月 30 日上线的 GUI 版本跳票了，官网切到维护状态。

但有个细节我一直记着：Offer快 在小圈子里一直在更新，据用过的人说，也一直没被平台封过。一个第三方工具能在 BOSS直聘、智联、猎聘的风控底下长期跑，靠的是什么架构？我一直很好奇，但这个团队查不到任何技术资料。

今天在逛 DeepSeek Harness（DSH）的 GitHub 讨论区时，我意外看到了三个连号的讨论帖：#3631、#3632、#3633，报告人都是 yamingmou，署名是 OfferKuai Team / Founder: Zhaofeng (Yaming)。

署名方是 OfferKuai 的团队，在 DSH 的讨论区里提 bug？而且提的还是这种质量——问题描述精准、复现步骤清晰、带脱敏证据行、明确标注了 “Confirmed empirically”（经验证）。这不像普通用户反馈，更像一个把 DSH 用在生产级分布式场景里的团队才会踩到的坑。

于是我顺着这三个讨论帖反向推导，越推越觉得能对上。这三个 bug 单看是 DSH 的框架缺陷，连起来看，几乎是一套"端云协同 Agent"架构的间接施工图。

下面把我推导的过程和结论写出来，供大家拍砖。

---

先看这三个讨论帖到底在说啥

#3633：多实例并发写，会话日志静默损坏

当壳（desktop shell）和 dsh web 两个实例共用同一个 ~/.dsh home，各自维护独立的 seq 计数器，向同一个 session.jsonl.zstd 追加，导致 seq 乱序。证据行：line 37058: expected seq 693898, got 683973。

关键信号：桌面壳 + dsh web 同时跑，共用同一个 home。

#3632：孤儿 inbox 操作导致 UI 硬失败

日志受损后，残留 agent/inbox/spliced 事件，removedCount > 0 但 inbox 为空（孤儿撤回）。持久化层接受这份日志，但 UI 渲染硬失败，"Load earlier"永久空白。证据行：seq 199843: {"type":"agent/inbox/spliced","data":{"target":"next-turn","start":0,"removedCount":1,"inserted":[]}}。

关键信号：深度使用了 DSH 的 Agent Inbox 机制（sub-agent 派发任务、splice/claim 那套）。

#3631：aborted turn 导致 history paging 冻结

会话以 aborted turns 结束时，前端 History Paging 读取"断尾"事件（orphan tool call、缺失 surface 事件），无法构造合法的 UI 消息对象 → 分页挂起。

关键信号：aborted turn 是常态——用户高频干预 Agent 的执行。

---

我的推导：一套"端云协同的分布式多 Agent 系统"

把这三个讨论帖拼起来，再对照官网上描述的能力（全网职位检索、7×24 自动沟通、代投代聊、敏感人工介入），架构轮廓就清晰了。

推导一：端侧有 DSH 实例在跑

3633 里明确出现了"desktop shell"——这是跑在用户自己设备上的 DSH 实例。

必须跑在端侧，是因为要操作的是招聘平台的 GUI（BOSS 客户端、浏览器等）。如果在云端用无头浏览器跑，平台风控一眼识破——IP 集中、行为模式化、设备指纹单一。只有跑在用户自己的设备上，操作才看起来像"一个真实求职者在用自己的电脑"：

• IP 是用户 IP
• 设备指纹是真实的
• 操作时间符合人类作息
• 行为统计特征分散在千家万户

这与官方宣传和媒体体验稿的描述基本对得上——中华网的体验稿里写过"屏幕右下角一个极小的胶囊"，这个胶囊就是端侧 DSH 实例的 UI 载体。

这套架构在抗封上天然占便宜。 不是反检测技术有多黑，而是执行本来就分散在千家万户的真实设备上——平台风控看到的是一群正常求职者的行为特征，只不过这些"求职者"是 AI 驱动的。要识别，只能从行为统计学层面下手，成本高、误杀率高，一般平台懒得动。

推导二：云侧也有 DSH 实例在做编排

3633 里同时出现了"dsh web"——这是跑在服务端的 DSH 实例。

云侧负责什么？重推理：

• 简历解析与结构化
• JD 匹配度计算
• 沟通话术生成
• 面试协调策略
• 跨用户的知识沉淀

端侧负责什么？执行：

• GUI 自动化操作（点击、输入、截图）
• 本地数据隔离（简历、沟通记录在用户设备）
• 实时决策（什么岗位投、什么话术发）

这大概就是"端云协同"四个字的实际落法。端侧不是哑终端，云侧也不是什么中央大脑，两边靠 DSH 的会话日志协同。

推导三：每个招聘平台是一个 sub-agent

3632 暴露了深度使用 agent/inbox/spliced——这是 DSH 的 sub-agent 派发机制。

最自然的架构是：

                 ┌─────────────┐
                 │   主 Agent  │ (云端 DSH 实例)
                 │  (求职策略)  │
                 └──────┬──────┘
                        │ inbox 派发
          ┌────────────┼────────────┐
          ▼            ▼            ▼
   ┌──────────┐ ┌──────────┐ ┌──────────┐
   │Boss 子Agen││智联 子Agent│ │猎聘 子Agent│ (端侧 DSH 实例)
   └──────────┘ └──────────┘ └──────────┘

主 Agent 负责统筹：分析用户简历、拆解求职意图、制定投递策略。

每个平台的 sub-agent 负责执行：GUI 操作、平台特定话术、状态跟踪。

这套拆法的直接收益：

1. 平台隔离：BOSS 的 GUI 改版了？只更新 BOSS sub-agent 的适配器，不影响其他平台
2. 并发执行：DSH 的 parallel-safe 调用走有界滚动池（默认 maxParallelToolCalls=10），多个平台的投递可以真正并行
3. 有序提交：DSH 保证工具结果按模型原序提交，模型看到的对话结构永远自洽

推导四：aborted turn 高频出现是产品设计，不是 bug

3631 暴露了 aborted turn 是常态。

为什么？因为产品哲学是"敏感人工介入"——这可能是整套设计里最值得注意的一点。

它不是让 AI 全程无人值守，而是在关键节点设置了决策检查点。Agent 在运行过程中，遇到它判断为"敏感"的情况，会主动中止当前操作，把决策权交还给用户：

• 遇到薪资谈判环节 → 中止，提醒用户确认期望薪资
• 遇到"为什么离职"这类敏感问题 → 中止，等用户亲自回答
• 遇到面试时间确认 → 中止，让用户自己定时间
• 遇到一个"擦边"岗位（匹配度不高但有意思） → 中止，让用户拍板

这不是让用户手动中止 Agent——而是 Agent 自己检测到敏感场景，主动把控制权交还用户。用户不需要盯着屏幕，只需要在收到提醒时做决策。

这套设计把"自动化效率"和"用户主权"做了切割。重复性劳动（筛岗、投递、初次打招呼）交给机器，决策性环节（薪资、敏感回答、面试确认）留给人类。

对底层框架来说，这意味着 aborted turn 是高频率事件——每一次人工介入都会产生一个 aborted turn。DSH 的取消机制虽然严谨（cancel(cause) 清 pending、协同中止 signal、turn/end 记 aborted(user/parent)），但前端的 History Paging 显然没跟上——遇到这些"断尾"事件时，UI 挂起了。

---

这套架构的技术收益

1. 合规：端侧执行 + 可审计日志

端侧执行 + 用户明确授权 + append-only 可审计日志，是"AI 代投代聊"里相对好辩护的形态。

DSH 的会话模型是 append-only 事件日志——所有操作可回放、可审计。真要跟平台掰扯，有几个点能站住：

• 用户是自己授权的（不是入侵平台）
• 操作是透明的（每次代投、每次代聊都有日志）
• 行为是拟人化的（端侧执行，平台风控看到的是"勤奋求职者"特征）
• 敏感环节是人工确认的（不是 AI 擅自做主）

另一个有用的点是 DSH 的崩溃恢复机制——文件尾部撕裂写能被识别、补写合成收尾事件，用户设备断电、进程被强杀后，会话日志仍能恢复到一致状态。审计要的就是这个。

2. 抗封：行为分散在千家万户

端侧 GUI 自动化 + 拟人化操作（随机移动轨迹、非线性鼠标移动、变数操作间隔）+ 频率智能控制，这套组合在 RPA 风控领域是被验证过的"像真人"方案。

平台要封，只能从行为统计学层面识别（投递频次、沟通模式、时段分布），成本高、误杀率高。这就是为什么这类工具能在平台眼皮底下长期跑——大概率不是没被检测，而是检测成本太高、误杀率太高，平台选择了"睁一只眼闭一只眼"。

3. 扩展：平台即 sub-agent

Sub-agent + Inbox 机制让每个平台的适配器可以独立迭代。BOSS 的 GUI 改版？只更新 BOSS sub-agent。猎聘的 API 调整？只更新猎聘 sub-agent。

而且 DSH 是模型无关的——支持 DeepSeek、Anthropic、OpenAI、Gemini 等所有主流 LLM。不会被锁定到某一个模型供应商，可以针对不同类型的任务（简历解析 vs 话术生成 vs 匹配判断）选用最合适的模型。

---

但这套架构的劣势和挑战，才是真问题

1. 底层框架尚未 production-ready

DSH 自身还在 rc.8，官方明确说"v0.1 包含兼容性破坏性变更，插件 API 和 config schema 均尚未稳定"。

在 rc.6/rc.7 阶段就深度使用，意味着要么在内部维护了 DSH 的 fork，要么在应用层做了大量防御性封装。

3633 的会话级锁问题，目前 DSH 还没有修复。这意味着应用层必须自己做 flock 或单实例守卫——给端侧和云侧分配独立的 ~/.dsh home，但这又引入了跨 home 的会话同步问题。

2. 端云协同的会话一致性是开放问题

3633 暴露的问题如果不解决，端云双侧 DSH 实例在同一个 user 的 session 上并发写，迟早会大面积触发 seq gap。

临时 workaround 是给端侧和云侧分配独立的 ~/.dsh home。但这样又引入了跨 home 的会话同步问题——端侧执行的动作，云侧怎么实时感知？云侧下发的策略，端侧怎么即时生效？

这是分布式系统里经典的"最终一致性"难题。这个团队既然能在生产环境踩到这个坑，说明他们要么已经有了一套自研的同步机制，要么正在 DSH 的上层做大量的封装工作。

3. 孤儿状态的级联风险

3632 暴露的问题是系统性的：只要日志受损，inbox 状态机就可能产生孤儿操作。

端侧设备意外退出（用户关电脑、断网、强杀进程）在生产环境是高频事件。这意味着应用层必须自己做 inbox 一致性校验——而 DSH 目前的修复流水线只覆盖 surface 事件（tool call 要有对应的 tool result），不覆盖 control 事件（agent/inbox/spliced 的内部一致性）。

这就是为什么 #3632 能在 rc.6/rc.7 阶段存活。DSH 的 foldSurface() 通过了（surface 事件层面无异常），seq 连续、JSON 合法，持久化层接受这份日志。但 UI 层在消费时遇到了自己无法处理的状态——orphan 的 removedCount——且没有防御性编程，直接静默失败。

这里其实牵出一个 Agent 框架设计的普遍问题：当底层保证数据严格一致时，上层 UI 必须容忍数据层的"合法但异常"状态。agent/inbox/spliced 的孤儿操作正好把这个问题具象化了，原帖里那句 “Data-layer strictness and UI-layer tolerance should be aligned”（数据层的严格与 UI 层的容错应当对齐）说得很准。

---

延伸一下：这可能是执行类 Agent 的一个典型范式

抛开"求职"这个具体业务不谈，这套实践其实等于给整个 Agent 基础设施领域提供了一个生产级的、分布式多写入者的压力测试样本。

目前业界大多数 Agent 框架（LangChain、AutoGen、CrewAI）的参考实现都是单进程、单用户、单会话的。真正在生产环境跑"端云双侧多实例协同 + 多 Agent 并行执行 + 7×24 不间断"的团队极少。这家团队恰好是这种场景——

• 端侧 DSH 实例：单用户、单设备、但 7×24 运行
• 云侧 DSH 实例：多用户、多会话、高并发
• 两侧对同一 session 并发写
• Sub-agent 跨平台并行执行
• 用户高频干预（abort + 人工决策）
• 端侧设备意外退出常态化

这种场景逼出了 DSH 的三个深层 bug，也顺带指明了 DSH 后续迭代的方向：

1. 会话级锁 / 单实例守卫（解决 #3633）
2. inbox 状态机的一致性校验（解决 #3632）
3. 前端 paging 对脏数据的容错（解决 #3631）

如果把这套架构抽象成通用范式，执行类 Agent 的"端云协同"可以这样分层：

┌─────────────────────────────────────────────┐
│              决策层 (云端)                    │
│  - 任务规划与拆解                             │
│  - 模型推理（LLM）                           │
│  - 全局状态管理与跨用户知识沉淀                │
├─────────────────────────────────────────────┤
│              协同层 (DSH Session)            │
│  - Append-only 事件日志                      │
│  - Sub-agent 派发与 Inbox 机制               │
│  - 崩溃恢复与一致性校验                      │
├─────────────────────────────────────────────┤
│              执行层 (端侧)                    │
│  - GUI 自动化操作                            │
│  - 本地数据隔离                              │
│  - 拟人化行为模拟                            │
│  - 敏感节点人工决策提醒                      │
└─────────────────────────────────────────────┘

这个范式说白了就是三层分工：决策放云端，重推理、集中调度；执行放端侧，拟人化、分散风险；协同靠 append-only 事件日志，可回放、可恢复。

任何需要"长期、自动化、跨平台、拟人化"执行的场景，都可以套这个范式：

• 自动化求职（这个项目正在做的）
• 自动化客服（需要操作多个 CRM 系统）
• 自动化数据采集（需要模拟真人浏览）
• 自动化测试（需要在真实用户环境跑）
• 个人 AI 助手（需要在用户设备上操作各种 App）

---

一点个人判断

这三个帖子最触动我的，是报告本身的写法。

不是那种"软件坏了帮我看看"的泛泛而谈，而是精确到了代码层面——seq gap、agent/inbox/spliced、foldSurface() 这些细节，说明报告人是亲手在写代码、亲手在调 bug、亲手在生产环境跑系统的人。

不管署名是不是真的 OfferKuai 团队，这份报告的质量对框架维护者是有价值的——大多数用户反馈停留在"坏了帮我看看"，而这直接把生产环境的三个问题精确到了证据行。

从技术视角看，"端侧执行 + 云侧编排 + 可审计事件日志"这个组合在合规性和扩展性上是站得住的，真正的技术挑战在于：底层框架还没 production-ready 时，怎么维持端云两侧会话的一致性和稳定性。

从工程视角看，#3633 和 #3632 官方还没修，说明这套场景的优先级还没排上来。对框架维护者而言，这三个报告就是生产环境需求的第一手输入——单进程参考实现覆盖不到的东西，恰好被这类用法暴露出来了。

作为技术观察者，我会持续盯两件事：

一是 DSH 后续版本对 #3633/#3632/#3631 的修复方案（尤其是会话级锁和 inbox 一致性校验的设计取舍）；

二是这套"端云协同、多实例并发写"的用法会不会被更多项目复现。

两个信号任何一个落地，都说明"生产级端云协同 Agent"往前挪了一步。

从几个 GitHub 讨论帖反向推导出一套架构的轮廓，这件事本身就挺有意思的——好的 bug report 里藏着的信息量，往往比作者想说的多。

作为还在学 Agent 的技术人，我更期待看到：DSH 修好这三个 bug，"端云协同"的写法在更多项目里跑通——到那时，执行类 Agent 才算真正进入"替你把事做完"的阶段。在那之前，这三个帖子就是这个方向最早的一批路标。