全球文明进程重大事件日报AI极客实战案例日报
今天最值得中国 AI 从业者关注的，是两条线同时从「模型有多聪明」转向「约束与分发」：一边是有人把 3 个 Agent 实例管成一条可验收的交付流水线，一边是官方 Agent 运行时把能力变成了 4200+ 个可一键安装的插件。
用 3 个并行 Agent 实例 + git worktree 隔离 + 飞书多维表格任务队列，1 人 3 周交付一套 12 万的企业 AI 客服系统
01｜案例是什么？
一位后端出身的开发者接了一套企业 AI 客服系统，报价 12 万、承诺 3 周交付。他没有招人，而是把项目切成一块块不超过 2 小时人工工作量的模块，每个模块交给一个并行运行的 AI Agent 实例，用 git worktree 给每个实例一个独立目录和分支，用一张飞书多维表格当任务队列，用 CI 当合并门禁。作者自述开发环节约八成代码由 Agent 完成；10-01 发布的这篇文章，是他对读者提问「你用的什么 Agent」的完整回答——拆开三个实例的上下文、工具与模型分档，并交代哪四类活他一条都没交出去。
02｜为什么今天值得关注？
- 两篇合起来才闭环：09-30 的前作给商业结果（报价 12 万 / 交付 3 周 / 自己投入 10 天 / 成本 2–3 万），10-01 的这篇给工程细节（worktree 生命周期、乐观锁、心跳超时、CI 门禁）。「结果 + 方法」能同时公开的中文案例并不多。
- 为什么以前不容易做：单个 Agent 能写代码不稀奇，难的是多个实例同时跑——谁在做哪个任务、任务做废了怎么退、实例崩了谁来收。以前这三件事要自建调度框架，维护成本比写业务还高。
- 为什么现在变得容易：① 把模块切到「不超过 2 小时人工工作量」之后，验收口变成了单测 + 类型检查这种机器可判定的东西，信任被换成了可验证；② 便宜档模型足够覆盖 CRUD，作者自述一开始全用最强档，几天后发现八成任务根本用不上；③ 一张多维表格 + 几十行轮询脚本就够，不需要工作流引擎。
03｜案例的前世今生
前世。2024–2025 年「AI 写代码」的主流粒度是函数级补全：人是主体，模型是加速器。那时的卡点不是模型不够聪明，而是三件事都缺——没有隔离（多个人或多个 Agent 会互相覆盖文件）、没有验收（改完不知道对不对）、没有回收（分支和临时目录越堆越多）。
发展。① 长上下文与工具调用趋于稳定，模型能自己跑命令、自己读报错；② 终端型 Coding Agent 出现，把「写—跑—改」闭环交回模型自己；③ git worktree 这个 2015 年就有的 git 能力被重新发现——它是最便宜的「一个任务一个完整工作区」，比复制目录干净，比 stash 可控；④ CI 成为机器可判定的门禁，「不绿不合」这句话第一次真正可执行。
今生。案例的作者做了两件关键的选择：把模块切分粒度绑定到「人工 2 小时」而不是「代码行数」，把并发实例数绑定到自己的 review 带宽而不是机器性能。他明确写到：加到第 4 个实例之后，产出不是变快了，而是变成排队等我看，总交付时间一点没少。这是一个来自实践的结论，不是理论推演。
下一步可能怎么发展（分析 / 推演）。任务卡里的「验收标准」会从自然语言描述逐步走向可执行测试；「一个人管 3 个实例」的形态会走向「一个团队共享一张任务表」；这套约束有可能被包装成可复用的交付模板或服务，成为外包公司的方法论资产。以上属于推演，不是作者原文结论。
04｜原始资料
- 一手原文本篇（2026-10-01）《读者问「你用的什么 Agent」：3 个 AI 员工的分工表和工具链》
https://juejin.cn/post/7691203094870491176 - 一手原文前作（2026-09-30）《3 个 AI Agent 交付一个企业项目：4 人团队 2 个月，我 3 周做完》
https://juejin.cn/post/7690841638806421538 - 作者主页王中阳讲AI · 掘金
https://juejin.cn/user/2189882892232029/posts
05｜作者是谁？
掘金作者「王中阳讲AI」，主页自述为「技术总监 | 杭州智航星辰，12 年互联网技术老兵」。在本案例中，他的身份是这套流程的实际使用者与项目交付方，属于一手实践者。
06｜解决了什么真实问题？
这个案例必须从需求侧理解，而不是从技术侧。
中小软件外包最常见的形态是：一家传统企业要一套管理系统或客服系统，预算 10–20 万，常规工期 1–2 个月，交付方配 4 人（2 后端 + 1 前端 + 1 测试）。客户的痛点是慢、贵、改不动；交付方的痛点是人力被钉死在确定性劳动上——真正的判断题只有一小块（架构、权限、事务边界），其余大量是 CRUD、页面、接口对接、测试用例。
作者的做法就是把这块「确定性劳动」整段交给 Agent，把判断题全部留在自己手里，并用 CI 守住质量底线。他给出的边界也很清楚：这套只适合业务逻辑清晰、CRUD 占比高、且代码能被自动验证的企业应用。
07｜完整技术栈
| 模型 | 作者刻意不点名（原文明确说明「这一层换得最快，几个月就变一次」），只给出分档原则：逻辑分支多、并发路径复杂的模块用强的一档；CRUD、管理后台页面、测试用例用便宜的一档。本文不编造具体型号。 |
| 工具 | git worktree（工作区隔离）、飞书多维表格（任务队列）、CI（单测 + 类型检查门禁）、RAG 知识库（运维段上下文）、一个几十行的轮询回收脚本 |
| 框架 / 语言 | 原文未限定；作者背景为 Go / 后端技术栈 |
| API | 原文未提及具体接口形态 |
| 数据库 | 原文未公开 |
| 部署 | 原文提到「发布单 + 回滚脚本 + 流水线」，具体平台未公开 |
| MCP / Agent 形态 | 原文未使用 MCP；形态是「终端型 Coding Agent 实例 + 外部任务表」 |
08｜完整 Workflow
每一步的分工逻辑是：Agent 出初稿和量，人做判断题和门禁。作者反复强调，「初稿本身不值钱，值钱的是它不会累」，但评审这一步他一步没省。
09｜它到底是怎么实现的？
剥开业务内容，这套流程真正的技术内核是三个机制：
机制一：隔离 —— worktree 的生命周期管理。每个任务一个独立目录 + 独立分支，失败直接丢掉整个 worktree，不用回滚主干。作者踩到的两个细节：任务重跑时用 attempt 递增避免撞上旧目录；AGENT_CONTEXT.md 是未跟踪文件，git worktree remove 不带 --force 会被 git 拒绝。更重要的是回收纪律——「一个项目下来累计创建了 300 多个 worktree」，最终合进主分支约 180 个模块（作者自述占累计数六成左右）。
机制二：抢占 —— 状态机要做，但真正的原子手段是乐观锁。任务状态只留五个取值：待分派 → 进行中 → 待评审 → 已验收 / 已阻塞。作者特别指出，状态约束本身是 read-then-write，两个实例同一瞬间读会同时看到「待分派」，挡不住重复领；真正让第二个写失败的是 version 字段——写回时带上读到的 version，与表里一致才写成功，不一致就重读重来。他还点出了一个容易被忽略的竞态源：回收脚本和自己的人工 review 回填也是写者，如果这两个写者不走 versioned write，就可能在实例刚写完结果的瞬间把状态盖掉。
机制三：回收 —— 心跳与超时打回。心跳每 5 分钟写一次，写在单独一个「不抬 version」的字段上；30 分钟没有心跳即自动打回「待分派」，阈值取心跳间隔的 6 倍，任务跑慢一点不会被误杀。轮询间隔放到 60 秒以上，原因是表格没有 webhook，只能定时拉，且要避开接口频次限制。
此外还有一条工程纪律：合并前一律过 CI，单测加类型检查，不绿不合，Agent 写的代码和人写的走同一套门禁。作者认为这才是「敢不敢让 AI 写代码」的真正前提。
10｜手把手复现
Step 0（本文补充的建议）。先确认你的项目能被自动验证：有测试、能本地跑起来、错了当天能发现。没有测试覆盖的老系统，这套流程不适用。
Step 1。项目拆解：每个模块的粒度控制在「你自己写不超过 2 小时」。超过就继续切——这一步同时决定 worktree 的存活时间能不能按小时回收。
Step 2。为每个模块写一张任务卡，落进一张多维表格：任务号、模块名、状态、接单实例、接单时间、心跳、version、attempt、worktree 路径、验收标准、产出分支。
Step 3。批量建 worktree 并注入上下文：给每个实例一份 AGENT_CONTEXT.md，写清本次任务模块、验收标准与硬约束（只改本目录文件 / 接口契约见 docs/api-contract.yaml 不得自改 / 不得改权限判定与事务边界 / 完成后写回任务表且禁止自己点合并）。
Step 4。启动实例：同一时刻最多 3 个（数量按你自己的 review 带宽定），每个实例只在被分配到的 worktree 里干活。
Step 5。写一个几十行的轮询脚本：60 秒以上扫一次表，超过 30 分钟没心跳的任务打回「待分派」。作者强调这个脚本是纯轮询，只做扫表 + 打回，不承担编排职责。
Step 6。合并门禁：走 CI 单测 + 类型检查，不绿不合。
Step 7。合并后立刻回收：git worktree remove --force + git worktree prune。
Step 8。明确划红线：权限判定 / 事务边界 / 幂等设计、架构决策、对外接口契约、不可逆操作（改 schema、删数据、首次上生产）四类不交给 Agent。
Step 9（本文补充的建议）。数据脱敏：客户模块名与验收标准属于交付物，进第三方表格前先替换成模块代号。
11｜Prompt / Code / Config
原作者公开的内容（原文直接给出）：
- worktree 创建 / 回收脚本（含幂等判断、
--force说明、回收后的 prune） - AGENT_CONTEXT.md 上下文注入模板（任务模块 + 验收标准 + 四条硬约束），原文以 heredoc 形式给出
- 任务卡 JSON 示例（含 task_id / module / status / claimed_by / claimed_at / last_heartbeat / version / attempt / worktree / 验收标准 / 产出）
- 回收逻辑说明：几十行轮询脚本，60 秒以上间隔，30 分钟无心跳打回
原作者未公开的内容：具体模型型号、系统提示词全文、CI 配置文件、业务代码。
硬约束原文（四条，摘自 AGENT_CONTEXT.md 示例）：
# 硬约束 1. 只改动本目录下的文件 2. 接口契约见 docs/api-contract.yaml，不得自行修改 3. 不得改动权限判定与事务边界相关代码 4. 完成后把状态写回任务表，禁止自己点合并
说明：以上分类为「原作者公开」，本文未做任何补写或改写。原文中作者明确将示例标注为「示例任务卡 / 按你的项目改」。
12｜踩坑
以下均为作者在原文中自述的踩坑，本文未独立复现：
- worktree 只建不删，两周就能把磁盘和
git worktree list拖成一屏屏垃圾——worktree 是完整工作区检出，必须边用边回收。 - AGENT_CONTEXT.md 未跟踪，
git worktree remove不带--force会被 git 拒绝。 - 状态字段的抢占是 read-then-write，挡不住同一瞬间的重复领；必须靠 version 乐观锁。
- 没有超时打回，实例崩在中间任务永久卡死，而你看到的还一直是「进行中」。
- 心跳写结论前要重读一次 version，否则任务跑几十分钟后开局读到的版本号早已过期，每次写回都失败。
- 全用最强档模型纯烧钱——作者自述八成任务用不上那个能力。
- 合规细节：客户模块名和验收标准属于交付物，进第三方表格前先脱敏成模块代号。
13｜中国用户能不能直接做？
| 国内访问 | 可以。掘金 / 飞书 / git 托管 / CI 全部国内可用，本案例不依赖任何境外服务。 |
| 注册 | 飞书多维表格需飞书账号（个人可注册）；git 平台与 CI 自选（Gitee / GitCode / 企微自建均可）。 |
| API | 原文未点名模型。若要落地，接一家国产模型的 API 即可（DeepSeek / Kimi / GLM / Qwen 均提供 OpenAI 兼容接口，充值即用）。 |
| 成本 | 工具侧近乎 0（飞书表格免费额度 + git + 自建或免费 CI）。token 成本作者自述包含在单项目 2–3 万成本内，未拆分。 |
| 技术门槛 | 🔴 开发者级 要会 git 分支与 worktree、要能写测试、要能配 CI。作者自己的判断是：门槛不在技术栈，在你敢不敢把项目切得足够细。 |
14｜国产替代方案
| 原方案 | 作者刻意不点名模型，可视为「强推理档 + 便宜档」的抽象分档。 |
| 中国用户方案 |
已验证（作者原文明用）：git worktree 做隔离、飞书多维表格做任务队列、CI 做门禁、心跳 + version 乐观锁 + 超时打回这套机制。 官方支持：DeepSeek / Kimi / GLM / Qwen 均提供 OpenAI 兼容 API，可作为「强 / 便宜两档」的落点。 本文推测（未验证）：用维格表 / 腾讯文档智能表格替代飞书多维表格；用国产 Coding Agent CLI（如 Qwen Code、CodeGeeX、TRAE 等）替代原文的终端型 Agent。 |
必须区分的部分：作者已验证的是「机制」，不是「型号」。把「强档用 DeepSeek / 便宜档用某小参数模型」写成已验证结论是错的——原文根本没写型号。
15｜中国企业可以怎么用？
- 企业场景 1：中型管理系统的乙方交付。CRM、工单、审批、数据看板这类「判断题只占一小块」的项目，把 CRUD 与后台页面交给 Agent，架构与权限判定留人，用 CI 保证底线。这是案例本身的场景。
- 企业场景 2：企业 IT 的 backlog 消化。用同一套任务卡机制把内部需求池里的低风险改造（表单调整、报表新增、后台页）批量推进，每个改动都过 CI 门禁；因为改动小、可回滚，风险可控。
- 企业场景 3：集成商 / 外包公司的产能放大器。同一张任务表管理多个客户项目，按客户隔离 worktree 与知识库；注意作者提的脱敏要求——客户模块名和验收标准不能直接落进第三方表格。
16｜中国消费者可以怎么用？
这个案例本质是 B 端交付流程，对纯消费者的直接适用性有限。但对个人有三个务实用法：
- 个人接单者（自由开发者）：把同一套约束搬到自己接的小项目上——后台管理系统、数据看板、门店小程序后台，先开 1 个实例跑通，再逐步加。
- 小团队内部工具：把「重复出现的运营小需求」（导出报表、字段调整、页面文案批量改）做成任务卡 + Agent 的固定流程。
- 自学者：把这套流程当作真实工程训练场——它训练的不是写代码，而是切分、验收、回滚的工程判断力。
17｜如何变成一个赚钱的项目？
产品化。最直接的「产品」不是软件，而是可复用的交付物：任务卡模板 + worktree 脚本 + CI 配置基线 + AGENT_CONTEXT.md 模板，打包成一份「Agent 交付启动包」。它不需要服务器，交付即用。
服务化。把流程本身卖给外包公司：帮他们搭「任务表 + worktree + CI 门禁 + 超时回收」，解决的是「老板不敢让 AI 碰客户代码」这个信任问题。
咨询化。帮企业找「哪些模块可以切出去」——这一步恰恰是最难的：切不细，Agent 就只是个贵的自动补全。
培训化。这是本案例最顺滑的变现路径：完整的方法论 + 一段真实可演示的脚本 + 一个能当场跑出 PR 的练习，天然适合 60 分钟 Workshop。
内容化。拆成系列内容：任务卡怎么设计 / 乐观锁为什么必要 / 什么活绝对不能交出去 / 并发上限为什么是 review 带宽。每一篇都是可独立传播的工程判断。
行业化。把「可切模块清单 + 验收标准库」按行业沉淀——电商后台、教育教务、门店管理、SaaS 客服，各行业能切的模块并不相同。
18｜变现路径
| 路径 | 客户 | 产品 / 服务 | 收费方式 | 难度 |
|---|---|---|---|---|
| 项目交付 | 中小企业 | AI 客服 / 管理系统 | 项目制（作者自述 12 万 / 单） | 中 |
| 流程咨询 | 软件外包公司 | 搭「任务表 + worktree + CI 门禁」 | 项目制 | 中 |
| 模板产品 | 独立开发者 / 小团队 | 任务卡模板 + 脚本 + CI 基线包 | 一次性 / 订阅 | 低 |
| 培训 | 外包团队 / 企业 IT | Workshop / 内训 | 按人 / 按场 | 低 |
这是分析，不是保证收益。除第一行为作者自述外，其余均为本文推导；不得据此承诺任何收入。
19｜如果我是一个中国独立开发者（7 天 MVP）
假设：1 个人、预算有限、有基础编程能力、使用国产模型 API。
- Day 1：选一个自己熟的小项目（后台管理 / 数据看板），确认它能跑、能加测试。不能自动验证的项目直接换掉。
- Day 2：把它切成「人工 ≤2 小时」的模块，写成任务卡表（飞书多维表格），定义五态状态机并加上
version字段。 - Day 3：写 worktree 创建 / 回收脚本 + AGENT_CONTEXT.md 模板（含四条硬约束），先把建、删、prune 跑顺。
- Day 4：接一家国产模型 API，用 1 个实例跑 2 个 CRUD 模块，打通「领任务 → 写码 → CI → 回写状态 → 合并 → 回收」。
- Day 5：补心跳字段与 30 分钟超时打回脚本；故意 kill 一个实例，验证任务能被自动打回而不是永久卡死。
- Day 6：跑一个需要判断的模块，验证自己划的红线守不守得住（权限判定 / 事务边界 / 接口契约 / 不可逆操作）。
- Day 7：复盘账：失败模块的原因分布、每个模块实际 token 成本、review 时间占比；据此决定要不要开第 2 个实例。
20｜如何迁移到其他行业
21｜培训课程设计
| 课程名称 | 《Agent 交付流水线：把项目管理从「盯人」改成「盯任务卡」》 |
| 适合人群 | 2 年以上开发经验的外包开发者、企业 IT、技术负责人 |
| 建议时长 | 半天（可拆分为 30 分钟 Demo + 60 分钟 Workshop） |
| 30 分钟 Demo | 现场把一个真实模块写成任务卡，让 Agent 写码，故意让 CI 卡住一次，再演示一次超时打回 |
| 60 分钟 Workshop | 学员自带一个小项目，切出 2 个模块，各自跑出 2 个 PR（含一次失败回收） |
| 半天课程 | 加讲四块：worktree 生命周期与回收纪律、乐观锁与心跳阈值、红线划定（哪四类活不交出去）、成本与 review 带宽核算 |
| 课程目标 | 学员能够独立搭建「任务卡表 + worktree 隔离 + CI 门禁 + 超时回收」的最小流水线 |
| 现场 Demo | 任务卡设计 → 上下文注入 → CI 拦截 → 超时打回（四段，每段可独立演示） |
| 学员练习 | 为一个真实模块写出验收标准与四条硬约束（这两项是学员最容易写空的地方） |
| 课后作业 | 用 1 个实例完成一个真实模块并提交 CI 记录 + token 消耗账 |
| 企业迁移 | 选定一个内部系统作为试点，产出可复用的验收标准库与红线清单 |
22｜培训师点评
23｜最终判断
（作者自述已成交）
这是案例属性描述，不是「最佳案例排名」。
DeepSeek Harness + dsh-market：官方 Agent 运行时里的插件市场，目录已收录 4200+ 个插件
01｜案例是什么？
DeepSeek 在 8-13 开源了官方 Agent 运行时 DeepSeek Harness（口号是「一切皆插件」：工具是插件、终端是插件、Agent 循环是插件、连交互界面也可以是插件），9-29 发布 v0.2 预览版并把 macOS / Windows 桌面安装包放上官网，普通用户下载登录就能用。第三方开发者在它之上做出了插件市场 dsh-market：用户在 Harness 的设置页里就能浏览、搜索、一键安装社区插件，并管理更新、备份与还原。这个市场在 2026-10-02 00:11（北京时间）发布了 v1.66.8，其插件目录已收录 4200+ 个插件。
02｜为什么今天值得关注？
- 窗口内的事实（可核实）：dsh-market v1.66.8 发布于 2026-10-01T16:11:48Z，即北京时间 10-02 00:11；同一窗口内多个社区外壳项目在推送：awesome-dsh-plugin（10-02 00:27）、dsh-web（10-01 18:34）、dsh-TUI（10-02 12:17）、deepseek-harness-desktop（10-02 11:06，均为北京时间）。
- 为什么是现在：v0.2 把插件安装从命令行搬进了图形界面（输入 npm 包名即可装、停用、卸载），并给符合条件的用户发了 6 元体验赠金（有效期至 10-06）。插件从「开发者玩具」变成了「普通用户的使用方式」。中文媒体转述官方口径称，按模型 API 用户统计，约 60% 的 Harness 用户使用过第三方插件。
- 为什么以前不容易：v0.1 只能命令行启动，用户要自己装环境、配 API Key、在终端敲指令——对开发者不算什么，对普通人是硬门槛；插件散落 GitHub 各处，不知道哪个好用、怎么装、装完怎么更新。
- 变化点：插件第一次变成了有目录、有安装器、有兼容性声明、有更新与回滚语义的分发对象。
03｜案例的前世今生
前世。2025 年以来的终端型 Coding Agent 把「工具调用」做成了智能体的一等公民；MCP 解决了「怎么把外部能力接进来」，但每个客户端各接各的，能力无法跨客户端分发。开发者做的小工具大多只能发个仓库求 star。
发展。2026-08-13，DeepSeek Harness v0.1 以 MIT 协议开源（官方仓库现为 241,847 Star / 29,030 Fork）；随后社区在其上长出多种外壳——桌面端、TUI、Web 聚合、插件目录、皮肤与预设包。这段时间的主题不是「模型更强」，而是补齐分发与治理：兼容性怎么声明、更新怎么不误伤、来源不明怎么拦住。
今生。v0.2 预览 + 桌面安装包 + 图形化插件管理 + 创造模式（用自然语言让 Harness 自己写插件），加上社区市场的 4200+ 插件目录，插件生态从「技术概念」走到了「用户采纳」。
下一步可能怎么发展（分析 / 推演）。官方插件市场落地后，可能出现插件的质量分级与来源标记；企业侧会出现「私有插件市场」——把内部工具打包成插件分发给全员，并治理「谁能装、装哪个版本、怎么回滚」；插件的商业化会从「开源换 star」走向付费增强与企业定制。以上为推演，非事实。
04｜原始资料
- 官方仓库deepseek-ai/deepseek-harness（MIT，241,847 Star / 29,030 Fork）
https://github.com/deepseek-ai/deepseek-harness - 官方发布dsh-v0.2.0-rc.2 Release，发布于 2026-09-29T09:42:36Z（北京时间 09-29 17:42）
https://github.com/deepseek-ai/deepseek-harness/releases - npm 包@deepseek-ai/dsh（latest 0.2.0-rc.2，2026-09-29T09:56Z 发布）
https://www.npmjs.com/package/@deepseek-ai/dsh - 官方产品页https://deepseek.com/harness
- 插件市场dsh-market/dsh-market（MIT，5,252 Star）；v1.66.8 发布于 2026-10-01T16:11:48Z
https://github.com/dsh-market/dsh-market ｜ https://dshmarket.com - 插件目录https://awesome-dsh-plugin.com （GitHub：awesome-dsh-plugin/awesome-dsh-plugin，17,560 Star）
- 中文媒体分析（二手，2026-10-01 12:51《梁文锋开始「送Token」了》）
https://www.sohu.com/a/1083065736_360352
05｜作者是谁？
- 官方侧：deepseek-ai/deepseek-harness 是 DeepSeek 官方仓库（MIT 协议、官方产品页 deepseek.com/harness）。项目负责人姓名、立项时间等信息来自中文媒体转述的「投资人交流会纪要」类内容，本文不将其作为事实引用。
- 生态侧：dsh-market 由第三方组织账号维护（具体个人身份未公开确认）；社区桌面外壳有多家团队在做（anywhere-labs、dataelement、dsh-tauri 等），各自独立维护、非官方产品。无法确认的不猜。
06｜解决了什么真实问题？
用户侧的问题：智能体「能聊不能干活」，缺的不是模型，而是可组合的能力和拿到能力的入口。企业想把自己的内部工具接进 Agent，过去要自己写工具、自己维护版本。
开发者侧的问题：做出来的小工具有能力、没渠道——只能发仓库求 star，用户装上之后怎么更新、出问题怎么退，全都没标准。
Harness + 插件市场解决的是能力的分发：能力做成插件 → 进目录 → 用户在设置里一键装 → 有兼容性声明、有更新检查、有备份还原。这条链路走通之前，插件只是代码；走通之后，插件才是产品。
07｜完整技术栈
| 模型 | DeepSeek 官方模型；社区外壳普遍支持接入第三方模型供应商（具体清单以各项目 README 为准，本文不转述未逐项核实的清单） |
| 运行时 | DeepSeek Harness 本体（TypeScript，MIT） |
| 插件市场 | dsh-market（TypeScript，npm 包名 dshmarket，MIT） |
| 语言 / 环境 | Node.js ≥ 20；市场要求宿主 dsh web ≥ 0.1.0-rc.6 |
| 分发 | npm（官方 CLI 包 @deepseek-ai/dsh；市场包 dshmarket） |
| 协议 | MIT（官方仓库与 dsh-market 均为 MIT，已核） |
| MCP / 插件 | 插件机制即 Harness 的扩展方式；engines.dsh 或 lockstep @deepseek-ai/dsh-* peers 用于声明版本要求 |
| 部署 | 本地桌面端（macOS / Windows 安装包）或本地 Web UI；无云端强依赖 |
08｜完整 Workflow
09｜它到底是怎么实现的？
这个案例最值得抄的不是功能列表，而是三个工程决策（均来自 dsh-market 的 README 自述）：
决策一：兼容性「只隐藏确认不匹配的」。插件卡片显示 engines.dsh 或 lockstep @deepseek-ai/dsh-* peers 声明的宿主版本要求；可选的过滤器只隐藏已确认不匹配的条目，未声明版本、格式错误、不可用、只在 GitHub 上的条目仍然可见——而不是替用户「猜它不兼容」。这是一个很克制的产品判断：宁可少过滤，不可误杀。
决策二：更新语义防「静默替换」。从压缩包安装的插件，只会从它自己的来源更新；目录里一个只是同名的条目永远不会被当成它的更新。这正是 v1.66.8 修的问题（PR #770：压缩包安装的更新不再被同名 npm 包整个替换）。对一个「一键安装」的市场来说，这条语义决定了用户敢不敢点更新。
决策三：中国下载区域的 GitHub 路由回退。README 自述：在中国下载区域，Git refs、README 内容、头像各自维护自己的回退顺序，并记住上次可用的路由。这条对国内用户有直接体感——它决定了插件市场在弱网/受限网络下是否可用。
辅助设计：备份还原是 merge 语义而非覆盖（备份之后装的插件不会被清掉），写入前校验、失败回滚；把「我为什么装了这个插件」的备注、分组、收藏都存本地（不发送到任何地方）；未处理的通知可以「本次启动内忽略」，而不是每次刷新都再提醒一次。
10｜手把手复现
Step 1。安装 Harness：从官方产品页下载 macOS / Windows 桌面安装包，或使用 npm 包 @deepseek-ai/dsh。
Step 2。配置模型：桌面端走「登录即用」；命令行模式需在设置里配置模型与 API Key。首次启动会引导选择供应商并录入密钥。
Step 3。安装插件市场，然后重启 dsh web：
dsh plugin --profile web add dshmarket
重启后打开 设置 → 插件市场。注意 README 明确要求宿主 dsh web ≥ 0.1.0-rc.6：在更旧的宿主上市场会自我禁用并在浏览器控制台说明原因。
Step 4。浏览目录并一键安装：关注卡片上的宿主版本兼容提示；大部分插件安装后刷新页面即可生效，无需重启。
Step 5。用创造模式写自己的第一个插件：在 Agent 预设里进入创造模式，用自然语言描述需求（例如「给我写一个稿件检查器插件」），让它读取插件开发 skill、生成代码并安装。此步骤来自媒体对官方演示的转述（演示中生成番茄钟插件用时约 5–6 分钟），本文未独立复现。
Step 6。备份：把当前 profile 的插件清单与配置导出为可读 JSON，或配置 WebDAV 每日自动备份 / 私有 Gist 同步。
11｜Prompt / Code / Config
项目公开的（可直接引用）：
- 插件市场安装命令：
dsh plugin --profile web add dshmarket - 宿主版本要求：
dsh web ≥ 0.1.0-rc.6 - npm 包名：
dshmarket（市场）、@deepseek-ai/dsh（官方 CLI） - 插件兼容性声明字段：
engines.dsh、lockstep@deepseek-ai/dsh-*peers
未公开 / 本文未获取的：插件清单（manifest）的完整字段规范、创造模式的系统提示词、目录抓取与刷新机制的具体实现。本文不编造这些细节。
12｜踩坑
来自项目 README 的明确提示（可信度较高）：
- 桌面端自带的 dsh 可能比 npm 装到的更旧，导致插件市场入口不出现——README 直接点名了这个问题（对应仓库 issue #139）。遇到「设置里没有插件市场」，先查宿主版本。
- 市场自身也可能被第三方渠道「静默替换」：v1.66.8 修的就是「压缩包安装的更新被同名 npm 包整个替换」。
来自第三方索引站整理、本文未独立核实（请自行验证后再采信）：
- 以 git 源码方式安装插件时，pnpm ≥ 10 会拒绝执行 git 依赖的 prepare 脚本，需要在 profile 的 workspace 配置里显式授权——这等于允许该包代码在你的机器上执行，建议同时锁 commit。
- 社区插件数量庞大且质量参差，移动端与桌面端环境差异大，多数插件未必逐项适配。
13｜中国用户能不能直接做？
| 国内访问 | 官方仓库与官网可访问。原始下载走 GitHub，国内可能不稳定——dsh-market README 自述已针对中国下载区域做 GitHub 路由回退（Git refs / README 内容 / 头像各自维护回退顺序）。此项为项目自述，本文未实测。 |
| 注册 | 桌面端需登录 DeepSeek 账号；命令行模式需在设置里配置模型与 API Key。 |
| API | DeepSeek 开放平台充值即用。中文媒体转述：符合条件的用户可领 6 元体验赠金，有效期至 10-06。 |
| 成本 | 0 元可跑：桌面端 + 开源插件 + 赠金额度，足够体验完整的一次 Agent 任务流程。长期成本按 token 计。 |
| 技术门槛 | 🟢 直接用 桌面端 + 一键装插件部分：普通用户可上手。 🟡 有一定门槛 命令行模式：需 Node ≥ 20 + 配置 API Key。 🔴 开发者级 写插件 / 做私有市场：需 TypeScript 或 JS 基础。 |
14｜国产替代方案
这个案例本身就是国产方案。它的可类比对象不是「某个可被替代的海外产品」，而是 Claude Code / Codex 系的插件与 Skill 生态、以及 MCP 的工具接入方式。
| 对照项 | Claude Skills / MCP 生态、OpenAI Codex 与终端型 Agent 工具链 |
| 本案例的差异 | 国产客户端 + 国产模型 + 国产（社区）插件市场的完整闭环：桌面安装包、登录即用的账号体系、中文界面、以及社区自建的插件目录与市场。 |
| 说明 | 「谁替代谁」在这条线上并不成立。本文不做「某国产方案已完全兼容某海外生态」这类未经核实的表述。 |
15｜中国企业可以怎么用？
- 企业场景 1：内部工具插件化。把 HR、财务、客服团队反复要用的内部工具做成插件，放进 Harness 分发给全员，替代「每人自己配一遍工具链」。价值在于统一入口与统一版本。
- 企业场景 2：数据不出本地的桌面 Agent。合同、报价、报表在本地目录里处理，Agent 在本地执行——这是桌面型 Agent 相对云端 Agent 的天然优势，对数据敏感型企业尤其相关。
- 企业场景 3：把交付物做成插件随交付给客户。软件公司可以把「配置器 / 初始化器 / 数据迁移脚本」做成插件，客户在自己环境里一键装。注意：这意味着要承担插件的兼容性与更新责任。
16｜中国消费者可以怎么用？
- 把 Harness 当「能动手的桌面助手」：整理混乱表格、生成可编辑的汇报 PPT、批量处理本地文件（官方宣传与媒体实测均提到这类办公场景；具体效果本文未实测）。
- 用社区插件补齐具体能力：按目录里的实际条目选（成本追踪、通知、图像识别等方向），一装一卸都在设置页完成。
- 用创造模式把「我每天重复的那件事」做成工具：这是普通人第一次可以不写代码就自造工具——但需要能清楚描述需求与验收标准。
17｜如何变成一个赚钱的项目？
插件产品化。找一个足够窄、足够痛的场景（某个行业的报表口径、某类文件的批处理），做成插件。路径是「免费核心 + 付费增强 / 企业定制」，而不是一上来收费。
企业私有市场。给企业做内部插件目录与治理：谁能装、装哪个版本、怎么回滚、怎么审计。这是 IT 部门的真实需求，也是插件生态里最可能先赚到钱的位置——因为它解决的是责任问题，不是效率问题。
咨询与实施。帮企业把现有内部工具接进 Harness，并做安装安全评估（插件是以本机权限运行的代码）。
培训与内容。面向普通用户的「桌面 Agent 上手」课；面向开发者的「插件开发 + 兼容性声明 + 分发」课。
模板与预设。可移植的 Agent 预设包本身就是一个可分发的商品形态——把「一套能干活的环境」做好，比单卖一个插件更有粘性。
18｜变现路径
| 路径 | 客户 | 产品 / 服务 | 收费方式 | 难度 |
|---|---|---|---|---|
| 插件产品 | 个人 / 团队 | 单点能力插件 | 免费 + 付费授权 / 捐赠 | 中 |
| 私有插件市场 | 中大型企业 IT | 内部插件目录 + 版本与权限治理 | 项目制 + 年费 | 高 |
| 咨询实施 | 企业 | 内部工具接进 Harness + 安装安全评估 | 项目制 | 中 |
| 培训 | 个人 / 企业 | 上手课 / 插件开发课 | 按人 / 按场 | 低 |
这是分析，不是保证收益。生态处于早期，暂无已验证的收入案例可引用。
19｜如果我是一个中国独立开发者（7 天 MVP）
- Day 1：装桌面端，让它真实完成一件你的工作（整理一份表格或生成一份 PPT），记录 token 消耗与失败点。
- Day 2：装 dsh-market，浏览目录，挑 3 个与你日常最相关的插件装上，观察它们解决的是不是你真实的问题。
- Day 3：用创造模式做第一个插件：解决一件你自己每天重复的事（越小越好）。
- Day 4：把它打磨到「别人也能装」：写清用途、默认值、最低 dsh 版本要求，处理第一次使用的空白状态。
- Day 5：确定分发方式（npm 包或 GitHub），写清安装命令；顺手做一次自检——安装时会不会请求超出需要的权限。
- Day 6：找一个真实用户（同事或社群）试用，只记录一件事：他第一次装失败在哪里。
- Day 7：决定方向：继续做通用插件（拼分发），还是转做某个行业的私有市场 / 定制（拼交付）。
20｜如何迁移到其他行业
21｜培训课程设计
| 课程名称 | 《桌面 Agent 与插件：让 AI 从「会聊」变成「能干活」》 |
| 适合人群 | 上半场：普通职场人；下半场：有 JS / TS 基础的开发者 |
| 建议时长 | 半天（可拆为 30 分钟 Demo + 60 分钟 Workshop） |
| 30 分钟 Demo | 装桌面端 → 装插件市场 → 一键装 2 个插件 → 用创造模式现场生成一个自己的插件 |
| 60 分钟 Workshop | 每位学员写一句话描述「我每天重复的一件事」，现场做成插件并跑通 |
| 半天课程 | 加讲四块：插件分发与版本声明、更新与回滚语义、安装安全评估（插件以你的权限运行）、企业私有市场的治理设计 |
| 课程目标 | 学员能够独立安装并写出一个可用的插件，并能判断「这个插件敢不敢装」 |
| 现场 Demo | 「描述 → 生成 → 安装 → 使用」四步闭环，一步不断 |
| 学员练习 | 为一个插件写出正确的兼容性声明与失败提示（多数人会漏掉宿主版本） |
| 课后作业 | 发布一个自己写的插件，并收集至少一次真实用户反馈 |
| 企业迁移 | 选出 3 个内部高频工具，评估哪些值得做成插件分发 |
22｜培训师点评
23｜最终判断
（生态早期）
这是案例属性描述，不是「最佳案例排名」。安装门槛低，做插件与做私有市场的门槛高，两者差异很大。
今日 AI 实战观察
今天这两个案例放在一起看，有一个共同的转向：竞争点从「模型有多聪明」移到了「约束与分发」。
案例 01 里，作者没有回答「你用什么模型」，而是回答「上下文、工具、模型怎么叠」。真正让他敢把约八成代码交出去的，不是模型变强，而是两件很朴素的东西：CI 不绿不合这条机器可判定的门禁，和 git worktree 带来的可回收隔离。他甚至把并发上限从机器能力改判成了自己的 review 带宽——加到第 4 个实例，产出不是变快，而是排队等他看。这句话说明 AI 编程的瓶颈已经不在生成侧，而在验收与回滚侧。
案例 02 里，官方 Harness 的价值也不在模型，而在插件：一个把「能力」变成可安装、可更新、可回滚对象的分发机制。社区市场把 4200+ 个插件收进一个目录，中文媒体转述官方口径称约 60% 的用户使用过第三方插件。这同样是约束与分发的问题——能力一旦可分发，个人开发者才第一次有了产品化的可能。
更值得注意的是两边的「不做什么」都写得很清楚：一边列出四类绝不交给 Agent 的活（权限判定、架构决策、对外契约、不可逆操作），一边给插件加上兼容性声明、更新语义和安全提醒。这种克制不是保守，恰恰是这两套东西能进入生产的原因——先写清楚边界，再谈自动化。
对个人开发者来说，这落到两件具体的事上：把交付切成可验证的小块，以及把重复劳动做成可分发的插件。两件事的门槛都不高，但都需要先承认一件事——人不再负责产出，人负责验收。
（本段基于今日两个案例的事实展开；文中「60%」为媒体转述的官方口径，未经独立验证。）
今日商业机会雷达
机会 1｜「Agent 交付流水线」搭建服务
- 客户：软件外包公司、企业 IT 部门
- 实现方式：飞书/其他多维表格任务卡 + git worktree 隔离 + CI 门禁 + 心跳超时回收
- 解决的是：「老板不敢让 AI 碰客户代码」这个信任问题
- 可能商业模式：项目制流程搭建 + 内训
机会 2｜企业内部插件目录与治理
- 客户：中大型企业 IT
- 实现方式：Harness + 私有插件市场 + 版本/权限/回滚治理 + 安装安全评估
- 解决的是：责任与审计问题，而非效率问题——所以更可能先收到钱
- 可能商业模式：项目制实施 + 年费运维
机会 3｜行业预设包 + 插件组合
- 客户：某个垂直行业的从业者
- 实现方式：把「一套能干活的环境」（预设 + 若干插件 + 使用说明）打包分发
- 解决的是：普通人不知道从哪个插件开始装的问题
- 可能商业模式：一次性售卖 + 社群订阅
这是基于案例的商业模式分析，不代表已经验证的商业成功。三个机会中没有任何一个在本文中被证明已经赚到钱。
今日「个人变现机会」
如果一个人每天投入 2–4 小时，今天这两个案例分别对应一条路径：
路径 A（交付侧，源自案例 01）。用「任务卡 + worktree + CI 门禁」的约束，接 1–2 万元级的小型管理系统 / 数据看板。关键建议：先只开 1 个 Agent 实例跑通，再考虑加第二个——因为你的 review 带宽才是真上限。省下的时间不是用来接更多单，而是用来沉淀验收标准库。
路径 B（生态侧，源自案例 02）。在 4200+ 插件的目录里找一个「我还得手动做、目录里没人做」的空白点，做成插件；分发走 npm 或 GitHub，先用免费换真实反馈，再考虑付费增强或企业定制。这条路径的独特之处在于：它是今天少数几个「不需要客户、不需要报价、不需要交付会议」就能开始的位置。
不建议做的：同时铺开三条以上路径，或者在没有测试覆盖的存量系统上直接上多实例并行。
不承诺收益，也不虚构收入。以上为基于今日案例结构推导的方向，未经验证。
原始资料
案例 01 · Agent 交付流水线
- 一手原文掘金 · 读者问「你用的什么 Agent」：3 个 AI 员工的分工表和工具链（2026-10-01）
- 一手原文掘金 · 3 个 AI Agent 交付一个企业项目：4 人团队 2 个月，我 3 周做完（2026-09-30）
- 作者主页掘金 · 王中阳讲AI
案例 02 · DeepSeek Harness 插件生态
- 官方仓库github.com/deepseek-ai/deepseek-harness（MIT；241,847 Star / 29,030 Fork；创建 2026-08-13）
- 官方发布dsh-v0.2.0-rc.2（2026-09-29T09:42:36Z = 北京时间 09-29 17:42）
- npm@deepseek-ai/dsh（latest 0.2.0-rc.2）
- 官方产品页deepseek.com/harness
- 插件市场github.com/dsh-market/dsh-market（MIT；5,252 Star）｜ v1.66.8（2026-10-01T16:11:48Z = 北京时间 10-02 00:11）｜ dshmarket.com
- 插件目录github.com/awesome-dsh-plugin/awesome-dsh-plugin（17,560 Star）｜ awesome-dsh-plugin.com
- 社区外壳anywhere-labs/dsh-desktop（29,768 Star）｜ dataelement/dsh-desktop（11,494 Star）
- 媒体分析（二手）搜狐 · 梁文锋开始「送Token」了（2026-10-01 12:51）
窗口内信号（未计入案例，仅作背景）
- qwen-code v0.24.7-nightly.20261001（2026-10-01T22:01Z = 10-02 06:01 CST）——nightly 构建，非稳定发布，不构成案例。
- LangBot v4.11.0-beta.6（2026-10-01T18:50Z = 10-02 02:50 CST）——Release 说明仅含 compare 链接，无可核实的变更内容。
- tianma-if/edgeever v1.96.0（2026-10-01T15:22Z = 10-01 23:22 CST）——AI 原生知识库 + 原生 MCP，1,941 Star；体量偏小，未达收录标准。
- Tencent/WeKnora、dify、RAGFlow、FastGPT、bisheng、bytedance/deer-flow、volcengine/OpenViking 等：窗口内无新 Release（已逐仓库核查 API）。
数据真实性说明
一、本文核实为事实的部分（可复现的核验方式）
- 所有仓库的 Star / Fork / 创建时间 / 最后推送时间 / 协议 / Release 发布时间，均通过 GitHub REST API 直连查询获得，未依赖搜索结果或第三方站点。
- deepseek-ai/deepseek-harness：MIT、241,847 Star、29,030 Fork、创建 2026-08-13T11:56:32Z、最后推送 2026-09-29T09:41:57Z。
- dsh-market/dsh-market：MIT、5,252 Star、v1.66.8 发布于 2026-10-01T16:11:48Z（北京时间 10-02 00:11）。
- @deepseek-ai/dsh 的 全部 29 个版本及发布时间来自 npm registry 原始接口；latest 为 0.2.0-rc.2（2026-09-29T09:56Z），0.2.x 首版为 0.2.0-rc.1（2026-09-28T12:34Z）。
- dsh-market README 中关于「4200+ 插件」「宿主版本要求 dsh web ≥ 0.1.0-rc.6」「兼容性声明字段」「更新语义」「中国下载区域路由回退」等描述，均引自该仓库 README 原文。
- 掘金两篇原文的发布时间（2026-09-30 / 2026-10-01）与作者身份，均通过原作者主页交叉核对。
二、作者 / 项目自述、本文无法独立验证的部分
- 案例 01 的全部商业数字：单项目报价 12 万、交付周期 3 周、自己投入 10 天、成本 2–3 万、利润率 75% 以上、对照传统外包 20 万 / 4 人 2 个月——该数据来自作者自述，无法独立验证。作者未提供合同、验收或财务凭证。
- 案例 01 的工程量数字：累计创建 300 多个 worktree、最终合并约 180 个模块、开发环节约八成代码由 Agent 完成——均为作者自述，无法独立验证。
- 案例 02 的「约 60% 用户使用第三方插件」：来源为中文媒体对「DeepSeek 官方披露」的转述，未找到官方原文，按转述口径引用，未经独立验证。
- 案例 02 的 6 元赠金与额度换算：同样来自上述媒体转述，未在官方渠道独立核实。
- 「创造模式约 5–6 分钟生成一个插件」：来自媒体对官方演示的转述，本文未复现。
- 项目负责人、内部立项时间、投资人交流会纪要等未经公开渠道可核实的背景信息，本文一律未作为事实引用。
三、本文的分析与推演部分
- 两案例的「下一步可能怎么发展」「如何变成赚钱的项目」「迁移方向」「7 天 MVP」「课程设计」——均属本文分析与推演，非事实陈述。
- 案例 01 的 Step 0、Step 9、国产模型分档建议、多维表格替代品建议——均为本文补充，已在文中对应位置标注。
- 案例 02 的安全风险提示（插件以本机权限运行）为本文补充的通用判断。
- 「今日 AI 实战观察」「商业机会雷达」「个人变现机会」中的商业判断，均为基于案例结构的分析，不代表已验证的商业成功，不构成任何收益承诺。
四、明确排除的来源（内容农场与自动聚合站）
本期检索过程中，中文搜索结果被大量 SEO 内容农场与 AI 自动聚合站污染，以下站点内容全部剔除、未作为任何依据：
- 尧图系内容农场：tzjp.cn、bryh.cn、kwkr.cn、xxmr.cn、mtrt.cn、mhpq.cn、qwbw.cn、pcrn.cn、mzlw.cn、hqwc.cn、mhpn.cn、lpqz.cn、rrmt.cn、pgsr.cn、mfbz.cn、mwwr.cn、nlpx.cn、sheratonhq.com
- 英文伪权威 / 自动生成站点：chatgate.ai、heatdrop.ai、dshfind.com、aideveloper44.com、news.lavx.hu、deepusecase.com、choosely.ai、dev.to 上的疑似自动生成贴
- 判断依据：这些站点的共同特征是——无作者身份、无原始资料链接、代码示例为占位符（如去掉引号的 JSON）、大量「三平台一键脚本」式伪代码、跨站点重复同一模板。其中 dshfind.com 等索引站提供的插件信息与 GitHub API 数据存在版本号矛盾（如列出 v0.4.x，而实际仓库为 v1.66.x），因此仅作线索、不作为事实依据。
- 另需提示：案例 01 作者所在的掘金账号，其文章带有明显的个人品牌与内容营销风格（大量「面试官问…」类选题）。本文对该账号的处理方式是：工程细节部分如实引用并标注为自述，商业数字一律标注「无法独立验证」。
五、本期未收录说明
本期严格按「宁缺毋滥」执行：在筛出的约 20 个候选条目中，除去内容农场与新闻/产品发布类内容后，剩余候选大多不满足「有 Workflow + 可实现过程 + 可复现」的底线（多数为纯项目更新、方法论文章或无一手来源的二手转述）。最终收录 2 个，已达本期上限；没有第三个案例达到收录标准，也未为凑数降低标准。
六、本期质量自检
- 严格 1–2 个案例，无凑数
- 案例均为窗口内新内容 / 新更新
- 找到一手作者或官方项目
- 链接均指向具体页面
- 每案例均含 Workflow 与实现拆解
- 区分事实 / 自述 / 分析 / 推演
- 说明模型、工具、成本、门槛
- 分析国产替代与国内可用性
- 企业场景与消费者场景各 ≥ 3 条
- 变现路径表已标注验证状态
- 培训课程可落地（含时长与练习）
- 明确排除内容农场来源