心爱的蓝色大肥鱼，期许你能够不畏惧潮流的变化，轻快的悠游来去于时代之中。
取得长山老师授权了哦！
Deepseek Harness （DSH）热热闹闹的，劲头也感染到我身上。
学了几天后，我发了一条短评，在NS被 mjj 们骂得很惨哈哈哈，简单谈谈一下为什么我认为 DSH 骨子里是一个很 Web3 的产品，以及 AI 和 Web3 你中有我我中有你不可分割。
过去有段时间，我一直在做 Web3 基础设施与自主 Agent 的交叉研究，之前在曼昆区块链、RWA 研究院等专栏发过几篇深度长文，文章也上过 ME 的 Banner。
早在 AI 进入大众视野前，Web3 就早早开始押注机器支付、Agent 交换协议、链上身份、零知识证明等概念。保持跟踪下来，我也从谷歌的 A2A 一直跟到 X402 ，再到现在的 AP2 ，以及阿里等大厂加入的战局。后续我会写一篇文章来讨论这件事。
也正因这种思维惯性，每次看到新的 AI 产品，我的第一反应总是：这个 Agent 处在系统拓扑的什么位置？它的状态和权限归谁所有？它怎么和外面的世界打交道？
行业早早认定了 Agent 迟早会开始替人寻找服务、与别的 Agent 协商、调用付费能力，甚至在事先授权的范围内完成交易，成为字面意义上的智能代理，为人完成一系列的事情。今天的一切研究方向，以我们看，本质上都是朝着这个终局狂奔。
但在到达那一天之前，身份、通信、授权和支付等一堆工程硬伤会同时砸过来。偏偏各家巨头、地区和垂直行业绝无可能立刻坐到一张桌子上接受同一套方案。标准没共识，应用层没普及，老登们各自画地为牢的存量蛋糕还要分（MPP 就是个活生生的例子）。
经过多年的发展，机器支付以及 Agent 的概念大大方方地在大众面前驻足。但整体而言，仍然需要一套通吃的解决方案。让我们看看已有的工具：Claude Code 与 Codex 更侧重于编程，OpenClaw 是一个炒作，Hermes的开发者明显不关注这件事，他们作为 Agent 交互世界每个阶段的典范，都没有尝试进一步，去回应与世界交互之后的支付、分配、通讯，以及那个崭新世界留下的权力分配问题。
就在这个当口，DeepSeek Harness 出现了。它从理念到设计，让我觉得像一条鱼一样，在各个方案、生态和利益间游动，有着无限可能，就是行业要的答案。
“一切皆插件”看似是个老概念——早年的 Coze 也是打着插件市场的旗号拉拢开发者，但最终不得不困在中心化平台的一隅，死死按住了开发者的想象空间与商业闭环。DSH 会重蹈覆辙吗？我认为不会。
众多没有展开的讨论在我的短评中被忽略，跳了很多逻辑，最后写得很放松
“上个链就很好解决了。相信大鲸鱼，相信相信的力量。”
当然，文章已经发布评论区大家的批评很猛烈。有人问这连个 Token 都没有跟 Web3 有什么关系，有人说 Pi 早就在做高度可扩展的 Harness，也有人指出，协议终究会收敛，钱包和支付服务本来就应与 Agent 解耦，谁会把钱交给一个概率模型随便花。
所以我觉得有必要写一篇长评，来好好说说我的观点。
正巧，之前在我老师的介绍下，得以认识并加入到 ANP 开源技术社群的国内 Builder 群，这段时间有幸和 ANP 项目的负责人长山老师简单交流。
长山老师谈到，他们过去把产品接入 OpenClaw 和其他 Harness 时，总觉得配合别扭，换成 DeepSeek Harness 后却“简直飞起来”。
诶，我眼睛一下就亮了。
它正好击中了短评另一个属于工程的，没有想到却很重要的地方。现在的 Agent 几乎都能装插件、接 MCP、挂外部工具，为什么协议开发者仍会明显感觉到，有些东西只是被塞进去了，有些东西却终于找到了自己的位置？
首先还是要回到实践上。模型和工具的关系不是随插随用的乐高，Harness 就是模型的“专武”。专武选得对不对，战斗力天差地别。同时，Harness 对于模型做什么能做得更好，也有着举足轻重的作用。基于这样的原因，目前大部分的 Harness 都被厂商善意地将技能点锁死并专精在编程，剩下一点还算的话就是创意写作了。环境、连接、流程的自主选择和控制没有留给用户，没有留给开发者的余地。也就 Pi 做得更好一些。
其次，我说它“很 Web3”，并不是因为它自带区块链、钱包或 Token。它没有这些东西。我说的是正是这样的一种结构：底层保留一套较薄的共同语法，让不同主体实现、部署和组合上层能力，也让使用者保有替换、迁移和退出的余地。经济层面上，身份、支付和创作者关系将来有机会脱离单一平台继续存在。
两者互补，进而让长山老师觉得“飞起来”。
而 DSH 之所以会长出这种结构，我看了 Tianyi Cui 的推特，推断他们大概没有想到“要做 Web3”，是因为它面对的是同一时期从两个方向压向 Harness 的不确定性。上层的 Agent 协议和经济规则还没有答案，下层的企业与行业需求又高度分化。夹在中间的运行时如果提前把某个模型、某条 Loop、某种会话、某套权限和一种支付逻辑写死，很可能在未来到来以前就先迅速老死在半路上了。
Claude Code 和 Codex CLI 不正面临着迅速老去的问题吗？行业已经不再需要被厂商规训好的预制菜，大家迫切需要的是把自己的行业经验，炼化成最趁手的兵器。
于是，这篇长评想找到的是这么一个 DeepSeek Harness 最值得讨论的地方——它主动选择了一个更薄、也更耐久的位置。
让我详细展开。
法无定法
要讲透这事，我们得先把思维拉回交易的原点，从一个极常见的场景聊起。
用户对 Agent 说：“帮我买两张演唱会门票，总价不要超过两千元。”
现在的模型听懂这句话毫无压力，但在真实世界里执行起来却步步维艰。原平台没票了，能不能跳到二级票务平台？票价符合预算，但加收 30 块手续费，要不要打断用户重新确认？位置极度靠后，Agent 有没有权自行放弃？购票需要实名，能向第三方披露身份证的哪些字段？付款失败后重试几次？
这一连串追问，直接撕开了意图表达、受限授权［1］、身份验真、长周期状态管理等一整套全新的交互模式。
Doc Searls 提出的「意图经济」将这套交易模式抽象并理论化，形成了这么一门站在买方角度，探讨怎样重新获得主动权的学问。［2］
消费者可以直接告诉市场自己需要什么、接受什么条件、愿意付多少钱，供应方围绕这些明确意图作出响应，而不是被动等待中心化巨头通过爬取浏览、点击和定位数据，在算法黑盒里猜你的欲望。
到了我们所处的 Personal Agent 时代，Searls 与时俱进，将意图经济和交易模式的形态说明地更加清晰，指出替个人表达意图的 Agent 应当由个人拥有和运行。留在大型公司的封闭系统里、主要依靠监控数据推测用户的助理，很可能只是把注意力经济做得更精细，从而进一步加强垄断地位——这就是监控资本主义和平台资本主义的终极形态了。［3］
理论很丰满，现实很骨感。刷过 OpenClaw、Hermes 几轮热潮之后，人们发现我们不会天然进入那套未来的交易模式，意图经济也不会自然而然地生长出来。平台自己的购物 Agent 也许比旧推荐算法更懂得诱导用户，甚至能在对话中即时修改报价、排序和表达方式。〔注1〕
唯有当 Agent 能够跨平台行动，且用户死死握住数据权、授权凭据和迁移退出权时，真正的意图经济才有可能落地。
为了那个开放、光明的未来，我们需要落到工程上解决一些问题。
在 Agent 上，问题和解法很明确，我们需要一套分层协议。幸运的是解法已经有了很多。
-
A2A 是最先出现的分层协议，最早提出如何处理不同 Agent 怎样发现彼此、发布能力、交换消息并管理长时间任务。它的 Agent Card 类似一张机器可读名片，任务则具有状态，可以持续更新、等待输入或认证，也可以通过流式连接和推送通知跨越很长时间。［4］
-
AP2 关心的是用户究竟授权了什么。用户不在场时，可以事先签署带有价格、时间和其他条件的意图凭据，Agent 满足条件后再生成具体购物凭据。［5］Google 在 2026 年把 AP2 捐赠给 FIDO Alliance，后续标准化也在尝试把安全委托、可验证授权和交易执行分开。［6］
-
MPP 与 x402 更靠近支付请求本身。两者都利用 HTTP 402 的挑战—凭据—重试流程，让软件在调用 API 或数字服务时直接完成付款并取得回执；MPP 把不同支付方式放进共同协议，x402 目前的实践则以按请求支付和稳定币结算最为突出。［7］［8］
-
ANP 的目标更宽。它试图为开放的 Agent 网络提供身份、发现、描述、安全消息和支付等协议，［9］其 1.1 版本已经把消息能力拆成身份与发现、直接消息、群组消息、端到端加密、附件和跨域通信等多个配置层。〔注2〕
显然，有的协议负责管路通信，有的负责能力背书，有的负责授权验真，有的负责账本清算。未来几乎不可能出现一个大一统协议包揽全部环节。
面对这个判断，反方最有力的意见是，今天看上去纷繁的协议，往往会在竞争中收敛。
很有道理，开发者不会永远乐于为十套接口维护适配层，市场也会追求规模和网络效应。
但回顾计算机史，收敛通常发生在某一层，而不是提出一种万全法。 HTTP 的大一统没有干掉 DNS、TLS、OAuth 和底层的 TCP。同样，当机器支付进入个人零售、企业采购和跨国服务时，背后的合规、税务和授信逻辑也绝不可能收敛为单套代码。
更现实的情形，是某些层逐步稳定，另一些层继续竞争，旧协议与新协议在相当长时间内共存。于是，从反面出发，这个方面的意见反而使得我们更加确定会有这么一个时期，多个协议会同时存在，仿佛一个电缆束一样要介入到我们的 Agent 中。
至于评论区提出的“钱包应与 Agent 解耦”，谷歌在推行 AP2 时就交过学费，把购物 Agent、凭据提供商和支付处理器从物理上切开，Agent 连银行卡号都摸不到。
但需要指出的一点是，解耦不等于互不相干。Agent 仍要读取授权条件、挑选服务、发起请求、等待确认、调用受限的支付能力、保存回执、处理失败，再把状态反馈给用户。钱包可以独立，支付服务可以独立，通信协议也可以独立，进入一项具体任务后，它们仍要被组织成一条可以恢复、取消和追踪的执行链。如何组织，这便又为 Agent 提出了更高的要求。〔注3〕
网络协议处理参与者之间怎样协作，Harness 处理单个参与者内部怎样行动。至少应当确认的是，前者越开放，后者越需要允许差异存在。否则所谓 Agent 网络最后仍会退化成一家平台，把所有参与者吸进同一套账户、数据和工作流中。
不确定性还从另一个方向涌来。
律师处理的基本对象是客户、案件、事项、证据、期限和利益冲突；工厂面对的是设备、工单、班组权限、安全联锁和异常升级；企业采购围绕供应商、预算、审批链、合同、交付和付款节点运转。不同行业的需求汇聚到一个工具上，开发者们再把这些内容都翻译成同一种 Thread、Session、Tool Result 和 Approval，短期能跑，长期会留下越来越厚的翻译层。
Claude Code、Codex、WorkBuddy 这类完成度很高的产品就是这样。它们并没有做错第一步，若用户安装以后还要自己挑选循环、存储、会话和沙箱，Agent 很难完成早期普及。
问题出现在它们进入千行百业之后。通用产品的默认逻辑越完整，行业灌输自身经验时就越容易碰到产品墙，转移其他工具方向上又是一笔成本。
上层协议还在生长，下层业务又拒绝统一。两股力量最后都落到 Harness 身上，成为目前一定要解决的问题：
究竟是替所有人给出一套完整答案，还是保留足够多的变化位置，让协议和行业各自把答案带进来？
势无定势
在这个时间点的这个问题下，DeepSeek 自觉或不自觉地，用新生的 DeepSeek Harness 的诞生交出一份答卷。
DeepSeek 对 DSH 的介绍很直接。Agent 等于模型加 Harness，模型、工具、技能、会话、沙箱、存储、循环、调度和界面都由插件提供，开发者可以通过配置选择、替换或扩展这些能力，无需修改 DSH 源码。系统提示词、推理、工具调用、子 Agent 调度和上下文注入则进入追加式会话日志，恢复、分叉、搜索与回放共享同一条事件流。［10］［11］
所谓「一切皆插件」。
上述的那些宛如天书的文字已经让困于现有工具的开发者们兴奋不已，star数秒突破10万。而翻开架构文档，「一切皆插件」的原则和精神会更加清楚。简而言之，模型适配器、工具注册表、会话日志甚至连 Agent Loop 自己都在这套基于 Cordis 搭建的插件树中。插件向共享上下文提供服务、类型化事件和可回收的副作用，卸载时相应注册随生命周期撤销。具体到运行时，会话从空配置开始，依次叠加基础组合包、其他组合包、Profile 和本地 Patch，最终打印出的配置行都可以被上层覆盖，组合起来是相当方便随意的。［12］［13］
如果你用过锤子手机，或者自定义模块类似的设计，你一定会担忧这个「不可能三角」，即组件自由替换，基础配置如服务接口、事件语义、依赖和生命周期和语言之间的矛盾。不过幸运的是，显然 Tianyi Cui 及其带领团队在语言的选择上足够老道，Cordis 留下的组成语法让所有模块运行的非常守规矩。这也就给了 DSH 放开的空间。
到了使用者手里时，循环如何推进、会话放在哪里、工具如何加载、状态如何更新、接口如何匹配、沙箱怎样执行、事件如何安排，以及界面最后长成什么样就变得如鱼入水一般自由畅快。
中国开发者就这样飞了起来。
这种自由放在普通工具上不一定醒目，但放在协议接入上更是明显。
DSH 的扩展手册专门定义了 external protocol driver。一个协议驱动可以创建或恢复 Agent，把远端请求映射为继续执行或取消，接入 Agent、Session 和持久化服务，并持续观察会话事件流。消息入口、长期状态、取消、回执与界面更新因此有了不同落点。［14］
不过，只要目标是让两个 Agent 发出一条消息，DSH 并不构成必要条件。ANP 团队曾经用“一段 Prompt、一个 HTTP 函数”把 OpenManus 和 OWL 接进协议。事实证明，通信可以做得很轻，任何能够增加工具的 Agent 都有机会成为网络端点。
DSH 的优势从通信变成长期关系以后才逐渐显出来。
长山老师参与的 dsh-awiki，真正有意思的地方并不在于又给模型增加了几个收发消息的工具。它把身份、密钥仓库、消息数据库、缓存与本地状态放进 DSH 的 Host 服务和能力提供者中。同一个 DID［15］ 可以跨 DSH 重启恢复，也能被根 Agent 与子 Agent 共同使用；联系人、未读消息和历史记录则由本地 SQLite 持续保存。［16］
于是，身份不再是一段工具返回值，远端消息也不再只是临时塞进上下文的一块文本。它们成为这个 Agent 节点长期携带的身份和状态。外部协议负责传来消息，DSH 的会话、持久化和权限系统继续决定这条消息在本地怎样被处理。
所以 ANP 飞得更早了一点。
顺手为长山老师在 awesome-dsh-plugin 里开辟新分类的 dsh-awiki 打 Call！
OpenAI 当初公开覆盘 Codex App Server 时也表达了类似的感受。他们最初尝试把 Codex 暴露成 MCP Server，后来发现 VS Code 所需的 Diff 更新等丰富会话语义很难映射到 MCP。这反过来证明，作为现有 Agent 重要工具的 MCP 没法覆盖完整运行时的全部需求。当客户端还要持续还原进度、Diff、审批和线程状态时，接口就需要贴近 Harness 自身的事件与生命周期。［17］
从另一个方面出发，前面我们谈到的千行百业的 AI 实践凸显出实践本身的变化概率高、行业差异大、由不同责任主体掌握，并且需要独立演进的能力，这时「一切皆插件」可替换面便越深越好。
但也不是最深最好。如果将所有内容都变成乐高，事情就走向另一个极端，项目只会背上一身兼容债。DSH 的价值取决于它所选择的接缝是否正好落在未来会反复变化的位置，模型、循环、会话、存储、沙箱、协议和界面恰好都符合这些条件。〔注4〕
先扩大运行时的定义空间，再去补稳定性和兼容性。这个方向更适合一个答案尚未收敛的时期，也会更早承担组合复杂度。
推特上开始挖 TianyiCui 的经历，放在这里其实提供了一点有趣的旁证。
他的 GitHub 主页同时置顶 DeepSeek Harness 和《背包问题九讲》。公开报道显示，他加入 DeepSeek 前曾在 Jane Street 从事多年软件开发与研究，涉及股票和固定收益，随后共同创办量化机构 TSY Capital。
背包问题要求在约束下组织状态和转移，交易基础设施又长期面对策略变化、执行、风险、回放与故障，显然，这两者的经历赋予他一种先整理边界、再容纳变化的基础设施工程气质。
经常变化的策略不该与长期运行的系统绑死。模型会换，协议会换，行业流程也会换。
基础设施的寿命往往来自一种克制，它不该替上层决定太多。
如果你有耐心，还能有足够的技术储备能够看懂看到这里，有个工具在你脑子里的既视感一定很强。
那就是 Pi 。
先驱
想到 Pi 不是我的直觉，是我看到L站一个帖子讨论时如闪电击中我的想法。
Pi 的官方口号正是“让 Pi 适应你的工作流，而不是让工作流适应 Pi”。［18］
它保持一个极简 Harness，通过扩展、技能、提示模板、主题和 Package 改造。开发者可以增加命令、工具、模型提供方、工作流和界面，也可以通过 RPC 和 SDK 把它嵌进其他应用。Pi 甚至有意不把 Subagents 和 Plan Mode 等功能全部固化为默认能力，让不同使用者安装或写出自己的版本。［18］
所以，Pi 正是我前面花老鼻子力气说明的，和 DSH 一样，是开发者困于现有工具的解决答案。
它同样允许深度改造，也已经形成包目录和真实的多 Agent、工作流、法律技能等社区扩展。某些 Pi Package 可以执行代码并改变 Agent 行为，安全提示甚至直白地要求使用者审查源码。［19］
所以我要说清楚 DSH 是更对的答案，就要检查它与 Pi 的差别。
具体到工程安排上，Pi 的常用 SDK 入口是 createAgentSession()，调用者可以驱动会话、订阅事件、改变模型与工具，也可以通过运行时工厂重建与工作目录有关的服务。仅凭这个入口，就足以让开发者把 Pi 嵌入其他应用，接收外部请求并持续运行。［20］
两者的距离还在变化。2026 年 8 月 29 日，Pi 仓库加入了 Chord；8 月 31 日，coding-agent 已有将一项 RPC 通道替换为 Chord 服务的提交。Chord 是可以独立使用的应用组合运行时，已经处理服务依赖、提供者替换、状态复制和远程服务边界。插件可以拆成运行在后端、终端或浏览器中的不同部分，再由宿主组织生命周期。［21］
Pi 因而也在向多服务、跨进程的组合环境延伸。Chord 将传输和应用协议留给宿主选择，应用可以通过自己的适配器连接远端服务。［21］
我认为，这代表以 Pi 为首的面向开发者工作流的开源 Agent 工具，越来越注意到工作流内团队协作、组织架构的重要性。从来就没有，也不会有一个人的 OPC 能做成事情的。
沿着这个道路， DSH 更鲜明的特点，在它一整套运行时组装路径上。模型、循环、会话、存储和界面在同一套插件体系中占据各自位置，Bundle 将代码和配置一起分发，Profile 决定采用哪些组合，企业再用 Patch 覆盖本地差异。开发者面对的是一份可以逐层更换的运行配置。［12］
这种路径也有自己的约束。DSH 把受支持的 Node 应用统一到 dsh 命令和命名 Profile，Pi 则提供直接嵌入应用进程的 SDK。统一组装入口有利于维护同一套运行契约，进程内嵌入则便于接到已有程序中。两者各自保留了不同位置的自由。［12］［20］
一个通信协议要接入这样的环境，身份、消息、会话恢复与执行权限可以分别交给相应组件。DSH 的扩展手册还为外部协议驱动列出了 Agent、Session 和持久化的连接方式。协议作者仍须编写适配，但远端请求在哪里进入、任务怎样继续或取消、记录怎样保存，都有公开的落点。前面的 dsh-awiki 已经沿着这些位置做出了具体产品。［14］［16］
这种安排最吸引我的地方，在于接通网络以后，行业仍能保留自己的内部逻辑。一家企业可以更换模型、存储和审批实现，同时维持对外约定的任务接口；合作方只需遵守双方接受的协议与业务约定，无须跟着更换整套系统。
所以我仍然看好 DSH 对行业与协议基础设施的接入安排。Pi 也在扩大组合空间，两者的长期差距，要从实际接入中观察。更换一层能力会牵动多少代码，插件依赖能否被检查，升级时旧会话能否继续工作。DSH 把这些问题放进公开的组装路径，给行业团队留下了继续改造的条件。
对一款希望活得比模型和协议更久的工具，能够让今天接入的业务在明天继续演进，比替所有使用者选好同一套流程更重要。
可一个空的、再灵活的 Agent 也不会凭空理解律师、工厂或支付网络。
它们只能把路铺好，路上跑的是车还是马仍然取决于行业。
向行业走去
行业经验以及个体工作流的制作，与在 Agent 上的应用，本质是知识编译和自动化工作。
在 ANP Builder 群中探讨时，群友们的讨论在知识编译与自动化演进角度得出了非常深入的见解。
大家没有停在 Cordis 可以替换多少组件，而是往前追问这些 Prompt、SOP 和 Skill 是谁写出来的，怎样维护，成熟以后会不会逐步变成不再消耗 Token 的传统代码？
在大家的设想里，一项工作可能最初由人直接写 Prompt。样本积累以后，模型开始协助生成和修改 Prompt。流程渐渐稳定，模型把它整理成结构化步骤。条件、状态和转移关系足够清楚时，部分内容进入状态机。高度确定的环节最后成为普通代码。相邻层都走到确定性终点后，还可以继续合并。
相关研究业已相当成熟。StateFlow 把复杂任务表示为状态机，将流程推进与状态内的具体求解分开，在多个基准中同时改善成功率和成本。［22］Compiled AI 把模型放在编译阶段生成经验证的代码，运行时不再调用模型，以灵活性换取可预测、审计和成本优势。［23］Compile, Then Page 则把企业 SOP 编译成可执行伪代码，由受能力约束的运行时逐帧推进，模型负责其中仍需语义理解的部分。［24］〔注5〕
到最后，研究得到了反直觉的结论，即“Prompt 终将消失，所有 Agent 都会编译成代码”。但是现实显然没有如研究的意。
很多行业，如我最熟悉的法律，判断长期依赖语境，经验与价值权衡，几乎无法被完整枚举。有些流程即使可以编码，业务变化太快，维护确定性系统的成本反而高于保留模型判断。另一条路线仍会继续增强 Agent 在运行时的规划、自我检查和工具选择能力。
再加之过渡时期的存在，更可靠的前景，是不同成熟度的能力长期共存。
DSH 在其中仍然是处于 Harness 们的老位置，处理的是横向组合，在技术分层上没错。DSH 没有替行业生产知识，也没有发明一个更高层的智能。它改变的是，知识一旦被生产出来，能否以独立组件进入运行时，能否被替换、分发、测试和继续演进。
DSH 的十一份工程 Skill 是最好的体现。它们覆盖代码审查、提交检查、文档同步、国际化、PR 合并、证据留存以及清理思维过程残留等工作，帮助团队里原本散落在工程师习惯、代码审查和临场沟通中的经验，变成可版本化、可调用、可检查的组织资产。
而当行业和 Agent 结合，这不就是 FDE 吗？
Palantir 对 Forward Deployed Software Engineer 就是这样描述的，工程师直接嵌入客户环境，配置平台并解决具体业务问题。［25］现场工作最有价值的部分正是客户专属代码、临时 Prompt、接口脚本、项目文档，以及工程师记在脑子里的例外，这往往也是最难复用的部分。
DSH 对 FDE 的意义因此就更加重大，让普通律师、医生或班组长不必成为 Cordis 开发者，只要参与的是产品逻辑的定义就好，直接帮助他们回到站在一旁对着程序员指手画脚的地位，告诉 FDE 边界是怎样的，即哪些能力可以公开，外部请求能带入哪些数据，哪一步需要内部批准。
行业知识由此同时决定了工具怎样在企业里工作，以及它怎样与企业外部协作。
这也是我为何坚持，基础设施层的深度替换总体上是好事。
软件工程中的复杂度并不会因为界面做得漂亮就全部消失。通用产品可以把复杂度藏在默认逻辑里，代价是每个行业、每家企业、每位用户都要学习并绕着这套逻辑工作。行业发行版把更多成本提前交给研发者，完成一次架构、适配、测试和验证，再由大量使用者共同摊薄，再借由 FDE 以更低的成本和代价进入每一个员工的电脑里。
确实，有些复杂度可以通过更好的设计直接消除，错误的抽象也会制造纯粹的浪费。不过，当差异稳定地重复出现，软件产品线的做法确实是建设共同核心资产和变化点，［26］以较高的前期投入换取一系列产品的低成本派生。SEI 对软件产品线的研究也强调，组装基础设施和核心资产需要先付成本，随后才能在多个产品之间摊销。
站在这里，我们可以想的更远些。
当这些行业知识不再只是一次项目里的临时成果，而能够被打包、组合和升级，此时，DSH 的形态又会是什么样子？
千行百业的 Yocto
看到这里，你会和我一样自然而然地流出一个观点，DSH 之上会出现千行百业自己的 DSH 。
这就好比 Yocto 在各个行业的样子。
Yocto 首页有一句很出名的话：它不是一套嵌入式 Linux 发行版，而是帮开发者创建定制发行版。［27］
项目提供工具、元数据和协作体系，让硬件支持、图形界面、中间件、应用和发行版配置分别进入不同 Layer，再按产品需要组合。［28］
会发现 DSH 的组合包、Profile 和 Patch 也具有相似的生产逻辑。
组合包携带一层代码与配置，Profile 决定哪些包按什么顺序组成可启动环境，上层 Patch 继续覆盖企业和项目差异。组合包是作者分发的单元，Profile 才是用户实际启动的产品。［12］
因此，我们拿历史对比，DSH 自身更像 Agent 时代的 Yocto。法律、制造、金融、科研和办公领域做出来的完整产品，才接近各自的发行版。
法律发行版可以围绕客户、案件、事项、证据和期限组织会话，让利益冲突检查、律师复核与客户隔离分别进入权限、存储和沙箱，界面呈现案件工作台，而不是要求律师学习 Coding Agent 的对话逻辑。
制造发行版可以把设备状态、工单、班组权限、安全联锁和异常升级放到系统中心。模型参与分析，确定性安全规则留给传统代码与受限执行环境，车间人员看到的仍是熟悉的设备和工单。
Agent 商务发行版则可以让身份、通信、授权、报价、付款和回执分别落到适合的服务中。协议团队维护通用层，行业服务商规定业务流程，企业再覆盖额度、供应商、数据位置和审计要求。
这些发行版还可以彼此合作。采用 DSH 的采购 Agent，可以向基于 Pi 的供应商 Agent 询价。双方把商品字段、交付标准、认证方式和任务状态约定清楚，各自的模型、数据库与审批流程继续留在内部。A2A 为不同框架之间的任务交换提供共同接口，具体业务约定仍由参与者补齐。［4］
Profile 负责组合本地运行环境。部署者再配置对外身份、服务端点和访问策略，行业发行版才会成为可参与协作的服务。DSH 的深层可替换性因此有了另一项用途，企业调整内部系统时，可以尽量保持合作方已经依赖的外部约定。
抽象地说，这正是软件产品线最希望建立的结构。
一个由 Profile 组装出的法律 Agent，可以保留自己的案件对象、复核流程和保密制度，同时向外公开可提供的服务、调用端点和授权条件。制造企业也可以把安全联锁与设备状态留在内部，只向采购方或供应链伙伴返回任务进度和交付结果。
A2A 所接受的正是这类异构节点。双方使用什么框架、模型、记忆和工具都可以不同，协作时只交换约定好的能力、任务与结果。对面的 Agent甚至无须使用 DSH。［4］
这样看，DSH 的 Profile 既是一套行业产品的配置，也可能组装出 Agent 网络中的一个具体节点。FDE 以后交付的内容，也会从内部工作流继续延伸到对外身份、能力说明、授权边界和服务接口。
DSH 更像一套节点生产体系：行业负责决定每个节点内部怎样工作，开放协议负责让不同节点继续合作。
但 Yocto 的经验也给这个判断提了醒。
Layer 越多，依赖、版本与冲突越难管理。Yocto 对此的解法，是建立 Compatible Layer 状态和自动检查工具，让第三方 Layer 证明自己符合结构要求，并能与生态中的其他部分组合。［29］［28］
行业完全可以自己造“红帽”，但不能让每个行业都重造一遍包签名、依赖诊断、版本规则和迁移工具。DeepSeek 上游要维护共同语法，协议和基础设施团队提供通用组件，行业专家与 FDE 生产领域层，软件公司负责测试、支持和升级。只有分工形成，底层自由才会变成上层简单。
这时，“一切皆插件”开始产生另一个后果。
当行业经验、支付能力、存储服务、工作流和整套发行版都能成为独立分发单元，插件就不再只是给软件增加一个按钮。它可能成为被发现、计量、购买和持续维护的能力。
盈利问题，就很重要了。
活到决赛圈
DeepSeek Harness 发布后的极短时间，社区插件涌现的数量级极其夸张。
官方 GitHub 讨论区专门设置了“Show Your Plugins”分类，模型接入、MCP 管理、界面改造、移动端、长期记忆、兼容诊断等项目不断出现；社区还做出了一键浏览和安装插件的市场，以及类似订阅源的同步工具。DSH 官方仓库也主动要求插件作者添加 dsh-plugin 话题，方便外界发现。［30］
“一切皆插件”确实释放了创造欲。它还没有证明这些作品能活多久。
依旧想的更远些。
产品制作完成，交付之后的工作粗略拨来便有版本更新、安全漏洞、规则更新，依赖冲突等等问题需要解答。商业上的运作只会有过往而不及。
成本和代价，不会因为项目开源就消失的。
所以，前面所说的 Yocto 式发行版还缺少一个重要部件，回报。
回报在哪里呢？就在行业经验被产品化，产品获得收入，收入反哺维护，持续维护再把一次性的经验变成长期资产——这条链路能够走下去的道路中。
开源可以成为这条回路的起点。它降低试验和分叉门槛，让行业不用先向一家厂商申请许可。［31］可一个要对企业生产负责的发行版，很难永远只依靠作者的业余时间。光有“人人都能造红帽”还不够，造红帽的人也得有钱继续更新红帽。
这就很自然地联想到当年 Coze 的问题。
一轮智能体创作热潮已经尝试过“创作—上架—收费”这条路。只不过出发点是基于平台开始，开发者不必分别建设整套系统，而专心打磨自己的工具。用户则可以在同一处发现、购买和调用能力，审核、履约和责任出现问题时，还有一个明确的平台主体站在中间。
但 Coze 褪下热潮的教训也很清楚。创作者一切都依附于平台，一切也都由平台决定。一旦停止平台投流或者平台站位转型导致竞争失败，一切就烟消云散。
正如现在没多少人再理会 Coze 了一样。
DSH 显然面对的情况不同。随插件而建立的能力，理论上可以被各种环境挑拣采用。但仍然的，它还没有特别成熟，但快遇到经济上的问题，爆发一批行业的实践了。
如果每一项能力最终都只能进入唯一商店、使用唯一账户并服从唯一运行平台，DSH 在技术上获得的组合自主性，就会在经济层重新被收回去。
所以要站在 DSH 的视角随它进退，问题因此不在于要不要平台。审核、结算、客服、争议处理都需要某种组织承担。真正需要重新划定的是，哪些服务可以由市场集中提供，哪些关系应当能够随创作者和用户一起迁移。
成熟的插件生态已经给出不少经验。
Visual Studio Marketplace 不只提供搜索和下载。它验证发布者身份，为扩展包签名，对新版本进行恶意软件、运行行为和密钥扫描，发现风险后还可以下架、加入阻止名单并自动卸载；企业则能够限制可安装的扩展，或者部署自己的私有市场。［32］
Atlassian Marketplace 又把定价、许可、付款、收入分成和持续支持纳入同一套合作体系。开发者出售的已经不只是一个压缩包，还包括更新、兼容和服务承诺。［33］
这些市场的经验说明，从“插件可以分发”走到“插件可以形成稳定生意”，中间隔着一整套制度。市场要帮助用户找到东西，也要回答东西卖出的售后问题。
而要注意的是，这种问题的探讨要更加极端，因为 Agent 时代还会把“插件”变成一个更宽的商品概念。
Skills、SOP、API接口，或是 DSH 开放的每一个环节，都可以称为插件，都可以称为商品。于是在这里，交易的规则千奇百怪。一份合同审查技能适合按许可证或订阅收费，远程数据服务可能按次计量，本地插件要接受更严格的安全审查，就更别谈完整发行版则更接近SaaS了。
顺带一嘴的是，在这样的商业模式下，FDE 和知识编译落地更加轻易了些。
为了更加形象地理解我在说什么，再来设想一笔采购。
有家企业把已经脱敏的数据交给自己的 Agent，要求寻找数据清洗能力，预算不超过五十元，数据不得离开指定区域，输出不符合质量标准就停止后续调用。
Agent 可以通过 A2A 的 Agent Card 或 ANP 的 Agent Description 这类广播发现服务读取服务方的身份、能力、端点和认证方式，［4］［34］筛选符合要求的本地插件或远程服务。
接下来，它要核对发布者签名、适配的 DSH 版本、需要获得的权限、数据处理位置和历史评价。本地插件需要说明是否读取磁盘、访问网络或接触凭据；远程服务则要说明数据将被发送到哪里、多久返回结果，以及失败时怎样处理。
用户事先签署的授权凭据可以写明预算、用途、数据条件和有效期限。AP2 使用 Mandate 与可验证凭据记录用户的指令；［35］MPP 和 x402 则让 Agent 在调用 API 或数字服务时接收支付要求、完成付款并取得回执。［7］［8］
DSH 在这笔交易里负责本地执行。它可以把插件放入相应沙箱，也可以通过协议驱动接入远程 Agent；会话、执行过程和回执则进入持久化系统。官方扩展手册已经允许外部协议驱动创建或恢复 Agent，将远端请求映射为继续执行或取消，并接入 Agent、Session 和 Session Persistence。［14］〔注6〕
运行结果通过约定的验证后，款项才可以结算或继续支付。失败时，市场还要负责退款、停止订阅、记录争议，或者把责任转交给提供服务的发行版厂商。〔注7〕
在这个设想下，市场需要一条包含创作者身份、能力描述、版本兼容、权限隔离、计量定价、授权凭据、支付结算、许可范围、质量评价、售后支持、退款争议和责任承担的完整的制度链。这是值得收费的抽象原因。
而 DSH 在其中的作用便是它能够起作用，这已经足以让盈利回环有机会发生了。
很 Web3，很 AI
上述的那笔采购让能力提供者获得了收入，发行版的维护账单却还分散在它依赖的组件里。一套法律发行版可能用着别人的身份插件、存储后端、协议驱动和通用 Skill。客户向最终服务商付费，上游维护者未必因此多获得一分钱。基础组件一旦停更，发行版仍得自己接手兼容、安全和故障。
于是，前面那条盈利回环还要往上游延伸，收入怎样继续支持共同组成产品的人？
在这里， Drips 提供了一份现成的实验。
这个建立在以太坊上的开源资助协议，允许维护者认领项目，选择接受资金的维护人员和上游依赖，并设定分配比例。资金进入项目后按这些规则继续分配。被支持的项目也可以配置自己的分配关系。谁应当得到多少回报，由参与者作出安排，协议负责执行。［36］
2023 年 9 月，Radworks 通过一项国库资助计划，安排在一年内向 30 项关键依赖提供按提案计约 100 万美元的支持，资金由 USDC 和 RAD 组成。［37］Drips 随后的项目记录列出了这套分配网络，其中包括通用 Git 库 libgit2。最终产品需要长期依靠的公共组件，由此进入了一份有资金安排的维护名单。［37］
放到 DSH 生态，可以设想一种更贴近商业交付的安排。行业服务商从订阅或技术支持收入中划出维护预算，定期支持关键组合包；组合包作者再按约定支持自己的底层依赖。客户照常向服务商付款，维护预算另行分配，无需让每一次工具调用都成为链上交易。
传统赞助与合同付款当然可以承担这种责任。Drips 的特点在于，把多个独立项目的分配安排接到一套共同执行的资金协议中，减少逐一转付与核账的重复工作。它不会替发行版找到客户，也不会从代码依赖里自动算出公平价格。真实需求、销售收入和分配约定，仍要由参与者建立。
这个历史的例子我们没有办法从现有的商业逻辑中寻找，只有在 Web3 的语境下我们能看到 Drips ，这便使 Web3 与 DSH 多了一处很具体的联系。代码可以由不同团队组合，维护资金也可以沿各方选定的依赖关系持续回流。对行业发行版而言，上游有人修漏洞、跟协议、维护接口，才有条件兑现向客户承诺的长期支持。〔注8〕
这些关系超出了任何一个本地运行时。
当然，对于这种组织形式，我们有一个更加旁大的知识体系围绕着 DAO 这三个字母展开，在本文我就按下不表了。
企业可以各自保存记录，合作方还需要一套共同核验的方法。Web3 提供了这样一种组织方式，将部分身份、验证与资金规则放到多个参与者可以读取和校验的公共基础设施上，让企业继续掌握内部系统，同时减少对某一家市场后台的依赖。
回顾 ERC-8004《Trustless Agents》草案，这个方向更加清晰。它分别设置身份、信誉与验证注册表，面向缺乏既有信任关系的 Agent 协作，并将支付留在协议范围之外。企业可以读取这些记录，再结合自己的规则决定接受任务、要求额外验证，或者拒绝往来。注册信息和验证反馈提供判断材料，接单责任仍由企业承担。［38］
行业团队若采用这类公共记录，可以为 DSH 编写相应的读取与验证组件，将结果交给本地工作流和权限策略。公共网络帮助各方核对关系，DSH 承载企业怎样使用这些信息。Drips 展示的资金分配，也可以由独立的财务或资助流程完成。它们可以分别演进，通过明确的接口衔接。
这些安排共同指向我所说的 Web3 气质。不同主体保留内部实现，同时接受共同规则来维持外部合作。
以太坊继续提供了一个很适合澄清“有中心”和“去中心化”关系的参照。
以太坊拥有严格的共同规范。不同团队用不同语言维护多个执行客户端和共识客户端，所有实现都要遵守同一套规则；客户端多样性降低了单一代码库成为全网故障点的风险。［39］影响多个客户端或应用的变更，则通过 EIP 描述和协调。
因此，去中心化从来不等于没有共同规则。问题在于，规则控制多少，谁能实现，谁能部署，谁决定最终产品，以及谁有权修改规则。
DSH 在逻辑上有明确中心。Cordis 的服务、事件、依赖、生命周期和配置语义构成共同语言。它在实现和部署上放得更开，模型、循环、会话、存储、沙箱和界面可以由不同组件提供，本地与企业部署者也能选择自己的组合。行业团队因此获得更多产品塑造空间。
治理层仍然很集中。DeepSeek 的贡献指南目前不接受外部 Pull Request，维护团队规模也很小。同一份文件又明确表示，官方仓库里的包并不天然比社区包更重要，社区可以沿自己的方向建设插件。架构开放、源码开放和治理开放在这里处于不同阶段。［30］
DSH 与以太坊还有一个根本差别。以太坊的多个客户端必须对共享状态形成一致结果，某个节点无法任意改规则后仍留在同一网络。DSH 主要提供本地和企业运行时，一家律所换自己的 Loop，不必等另一家工厂同意。它强调的是部署者的组合自主权，没有全网共识、共享状态和原生资产，因此也不是一套 Web3 网络。
我仍然愿意说它“很 Web3”。它把共同中心压在较薄的组成语法上，把实现、部署、组合和退出的空间交给更多主体。再往经济层延伸，身份、能力和交易关系有机会摆脱单一平台的完整控制。
这个判断也要接受现实压力。DeepSeek 官方仍把 DSH 标为 Developer Preview，明确提示核心插件和 API 会继续演进。［10］当前架构已经包含会话格式的分版本读取与相邻版本迁移，保留源文件并生成后继版本。［40］能否稳定维护这条迁移链，仍是行业长期部署要检验的工作。
但社区已经开始遇到高度组合化的工程账单。有开发者报告，持久化会话在恢复时出现事件序列问题，导致会话无法加载；围绕第三方事件、插件缺失和会话恢复，社区也在讨论怎样保留未知事件并在插件重新安装后恢复投影。这些是特定版本和场景下的报告，不能被夸大成整个架构已经失败，却足以说明，插件可以写入持久状态以后，版本和迁移就不再是小事。
另一些社区项目开始制作 dsh-doctor 一类离线诊断工具，检查 Profile、插件、依赖和会话问题，希望在启动或安装前发现故障。这个现象很像 Yocto 的 Compatible Layer 机制：自由组合一旦进入生产，就需要兼容矩阵、自动测试和诊断工具跟在后面。
安全成本同样不能略过。深层插件可能在宿主进程里执行代码、注册工具、读取会话或接触凭据。Pi 的包目录会提示第三方 Package 可以执行代码并影响 Agent 行为，［19］DSH 也把 MCP Server 命令视为沙箱外的可信可执行代码，不默认启用。
“一切皆插件”因此必须支付一笔工程税，即稳定的服务和事件契约、可迁移的会话格式、组合包兼容测试、依赖锁定、包签名、权限清单、供应链审查［41］、故障回滚，以及让社区参与核心接口演进的治理程序。
这些问题不是架构哲学旁边无足轻重的脚注。它们决定 DSH 能否从开发者预览走进长期生产。
它们也没有推翻深层替换的方向。相反，工程税之所以出现，正因为 DSH 把过去藏在单一产品内部的变化权交了出来。要做的是让上游、协议团队、发行版作者和 FDE 在研发阶段把税交掉，不要把 Provider 冲突、会话迁移和包安全甩给普通用户。
回到最初的问题，DeepSeek Harness 的未来感并不在于它提前猜中了未来。
它没有押注某一种模型永远最好，没有认定某一套 Agent Loop 会统治所有任务，也没有替身份、通信、授权和支付选出唯一协议。它甚至没有假设所有行业最终都会长成同一种聊天框。
它选择把这些变化最快、差异最大、责任主体最分散的部分，留成正常的替换位置。
这让它能够同时接住两个时代问题。今天，企业需要把自己的对象、流程、权限和知识灌进 Agent；明天，Agent 又要带着人的意图进入一个协议、支付和服务不断变化的经济网络。协议亲和、FDE 产品化、Yocto 式发行版、插件市场和 Web3 式退出权，都是同一项架构选择向不同方向长出的结果。
DSH 能不能成为长期基础设施，目前还没有答案。Pi 证明相邻路线同样有强大的开放性，Codex 证明稳定 Core 也能形成优秀生态，平台市场则证明集中治理在履约和信任上拥有现实效率。DeepSeek 还要把接口守住，让会话活过版本更新，让第三方组件通过兼容与安全检查，也要让社区对共同语法拥有更实质的参与方式。
可它已经把问题摆在了一个很耐看的位置。
DSH 不必成为所有人共同使用的那一款 Agent。它可以更像 Yocto，允许法律、制造、金融、科研和 Agent 商务各自长出发行版。真正成熟以后，普通律师、采购员和车间班组长大概不会知道 Cordis 是什么。他们只会发现，这套工具从一开始就在用自己熟悉的对象和流程工作。
若有一天，他们还得亲手排查插件依赖、修复会话格式、理解 Provider 为什么互相冲突，问题也不在用户的数字素养。
只是这个行业的发行版，还没做好。
所以大肥鱼加油吧，我相信你能游去你要去的地方。
除另有说明外，本文文字及作者自制图表采用 CC BY-SA 4.0 国际许可协议发布。
转载、改编及商业使用应当适当署名、注明来源和修改情况，改编成果应采用相同或兼容许可。
文中第三方图片、商标、引文及另行标注的材料不在本许可范围内。
文章使用AI辅助生成图片并进行格式调整，保证全文内容为我本人方寒真人写作。
注释
〔注1〕“意图经济”有两种相反的使用方向：Searls 强调买方借助自己的工具表达需求；Chaudhary 与 Penn 则讨论平台借助大模型收集、塑造并交易意图。两者的分歧在于谁掌握代理关系，而不只是推荐是否准确。参见［2］［42］。
〔注2〕协议术语须对应版本：AP2 的2025年发布材料使用 Intent／Cart Mandate，v0.2 改用 Checkout／Payment Mandate，并区分开放与闭合阶段。本文采用的 ANP 1.1 与后续 Messaging 1.2 也应分别阅读；后者的规范发布状态与产品实现状态并不相同。参见［5］［35］［43］。
〔注3〕会话恢复与外部交易重试是两回事：支付或购票重试需要请求标识与回执来避免重复执行；卸载插件也不会自动撤回已发生的外部操作。追加日志与插件生命周期管理不能替代幂等、事务或业务补偿。参见［44］［13］［40］。
〔注4〕Parnas 的信息隐藏原则主张围绕可能变化的设计决策划分模块，而非照搬处理步骤；RFC 1958 则从互联网架构角度讨论异构系统与端到端原则。两者分别提供了理解“替换接缝”和“共同接口”的历史参照。参见［45］［46］。
〔注5〕三项研究的编译对象与运行方式不同，不能合并为“所有 Agent 最终不再调用模型”的结论。Compiled AI 的确定性路径仍有前期生成、验证和更新成本；其混合路径以及另外两项研究，仍为运行期模型求解保留位置。参见［22］［23］［24］。
〔注6〕DSH 的 SandboxMode 描述文件系统副作用范围，网络与进程可见性不由这一模式一并保证。因此，采购设想中的数据驻留要求还需核对网络出口、后端部署和插件执行位置。参见［47］。
〔注7〕HTTP 402 状态码本身没有规定托管、验收和退款规则；x402 的结算时机还取决于具体支付方案。这里的“验收后结算”属于需要另行实现的业务安排，延后结算不等于自动获得质量争议处理机制。参见［48］［8］。
〔注8〕共同维护并非只有链上路径：Open Collective 通过公开预算与财政托管支持开源项目，Drips 也已与 Open Source Collective 衔接。这里可区分的是持续资助这一共同问题，以及 Drips 用共享协议执行跨项目分配的具体方式。参见［49］［50］［36］。
参考
［1］《OAuth 2.0 Rich Authorization Requests: RFC 9396》[S/OL]，RFC Editor，https://www.rfc-editor.org/rfc/rfc9396.html（访问日期：2026年10月4日）。
［2］Doc Searls：《The Real Intention Economy》[EB/OL]，2024年12月30日，https://doc.searls.com/2024/12/30/the-real-intention-economy/（访问日期：2026年10月4日）。
［3］Doc Searls：《Personal Agentic AI》[EB/OL]，2024年10月25日，https://doc.searls.com/2024/10/25/personal-agentic-ai/（访问日期：2026年10月4日）。
［4］《Agent2Agent Protocol Specification》[EB/OL]，Agent2Agent 项目，latest 在线规范，https://a2a-protocol.org/latest/specification/（访问日期：2026年10月4日）。
［5］《Announcing Agent Payments Protocol (AP2)》[EB/OL]，Google Cloud，2025年9月16日，https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol（访问日期：2026年10月4日）。
［6］Stavan Parikh：《We’re donating Agent Payments Protocol to the FIDO Alliance to support the future of secure, agentic payments.》[EB/OL]，Google，2026年4月28日，https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/（访问日期：2026年10月4日）。
［7］《Machine Payments Protocol》[EB/OL]，MPP 项目，https://mpp.dev/（访问日期：2026年10月4日）。
［8］《HTTP 402》[EB/OL]，x402 官方文档，https://docs.x402.org/core-concepts/http-402（访问日期：2026年10月4日）。
［9］《Agent Network Protocol Technical White Paper》[EB/OL]，Agent Network Protocol 项目，1.1 版文档路径，https://agent-network-protocol.com/specs/1.1/white-paper（访问日期：2026年10月4日）。
［10］DeepSeek：《DeepSeek Harness》[EB/OL]，https://www.deepseek.com/en/harness/（访问日期：2026年10月4日）。
［11］DeepSeek：《Session》[EB/OL]，master 分支文档，https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/session.md（访问日期：2026年10月4日）。
［12］DeepSeek：《Architecture》[EB/OL]，master 分支文档，https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.md（访问日期：2026年10月4日）。
［13］DeepSeek：《Cordis Primer》[EB/OL]，master 分支文档，https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/cordis-primer.md（访问日期：2026年10月4日）。
［14］DeepSeek：《Extension Cookbook》[EB/OL]，master 分支文档，https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/cookbook/extension-cookbook.md（访问日期：2026年10月4日）。
［15］W3C：《Decentralized Identifiers (DIDs) v1.0》[S/OL]，https://www.w3.org/TR/did-core/（访问日期：2026年10月4日）。
［16］《@awiki/dsh-plugin》[EB/OL]，AgentConnect/dsh-awiki 项目仓库，README；Rust SDK 版实现说明，https://github.com/AgentConnect/dsh-awiki（访问日期：2026年10月4日）。
［17］《Unlocking the Codex harness: how we built the App Server》[EB/OL]，OpenAI，2026年2月4日，https://openai.com/index/unlocking-the-codex-harness/（访问日期：2026年10月4日）。
［18］《Pi》[EB/OL]，Pi 项目，https://pi.dev/（访问日期：2026年10月4日）。
［19］《Pi Packages》[EB/OL]，Pi 项目，main 分支文档，https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/packages.md（访问日期：2026年10月4日）。
［20］《SDK》[EB/OL]，Pi 项目，main 分支文档，https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/sdk.md（访问日期：2026年10月4日）。
［21］《Chord》[EB/OL]，Pi 项目仓库，main 分支 README，https://github.com/earendil-works/pi/blob/main/packages/chord/README.md（访问日期：2026年10月4日）。
［22］Yiran Wu, Tianwei Yue, Shaokun Zhang, et al.：《StateFlow: Enhancing LLM Task-Solving through State-Driven Workflows》[EB/OL]，arXiv，2024年4月10日，arXiv:2403.11322v3，https://arxiv.org/html/2403.11322v3（访问日期：2026年10月4日）。
［23］Geert Trooskens, Aaron Karlsberg, Anmol Sharma, et al.：《Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation》[EB/OL]，arXiv，2026年4月6日，arXiv:2604.05150v1，https://arxiv.org/html/2604.05150v1（访问日期：2026年10月4日）。
［24］Chenglin Yu, Li Yin, Ying Yu, et al.：《Compile, Then Page: Executable SOP Programs and a Capability-Gated Runtime for Procedural LLM Agents》[EB/OL]，arXiv，2026年7月13日，arXiv:2607.11346v1，https://arxiv.org/html/2607.11346v1（访问日期：2026年10月4日）。
［25］Palantir：《A Day in the Life of a Palantir Forward Deployed Software Engineer》[EB/OL]，2020年11月2日，https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1（访问日期：2026年10月4日）。
［26］Felix Bachmann, Paul C. Clements：《Variability in Software Product Lines》[R/OL]，Software Engineering Institute, Carnegie Mellon University，2005年9月1日，CMU/SEI-2005-TR-012，https://www.sei.cmu.edu/library/variability-in-software-product-lines/（访问日期：2026年10月4日）。
［27］Yocto Project：《The Yocto Project》[EB/OL]，https://www.yoctoproject.org/（访问日期：2026年10月4日）。
［28］Yocto Project：《Understanding and Creating Layers》[EB/OL]，Development Tasks Manual，dev 版，https://docs.yoctoproject.org/dev/dev-manual/layers.html（访问日期：2026年10月4日）。
［29］Yocto Project：《Yocto Project Compatible Layers》[EB/OL]，https://www.yoctoproject.org/development/yocto-project-compatible-layers/（访问日期：2026年10月4日）。
［30］DeepSeek：《Contributing》[EB/OL]，master 分支文档，https://github.com/deepseek-ai/deepseek-harness/blob/master/CONTRIBUTING.md（访问日期：2026年10月4日）。
［31］Open Source Initiative：《The Open Source Definition》[EB/OL]，https://opensource.org/osd（访问日期：2026年10月4日）。
［32］Microsoft：《Extension runtime security》[EB/OL]，Visual Studio Code 文档，2026年9月30日更新，https://code.visualstudio.com/docs/configure/extensions/extension-runtime-security（访问日期：2026年10月4日）。
［33］Atlassian：《Atlassian Marketplace apps: Pricing, payment, and billing》[EB/OL]，2025年6月17日更新，https://developer.atlassian.com/platform/marketplace/pricing-payment-and-billing/（访问日期：2026年10月4日）。
［34］《ANP Agent Description Protocol Specification》[EB/OL]，Agent Network Protocol 项目，1.1 版文档路径，https://agent-network-protocol.com/specs/1.1/agent-description（访问日期：2026年10月4日）。
［35］《Agent Payments Protocol (AP2)》[EB/OL]，AP2 项目，v0.2 文档，https://ap2-protocol.org/（访问日期：2026年10月4日）。
［36］Drips：《Drips Documentation》[EB/OL]，https://docs.drips.network/（访问日期：2026年10月4日）。
［37］Becca：《Radworks Gives $1M to FOSS Dependencies with Drips》[EB/OL]，Drips，2023年11月8日，https://www.drips.network/blog/posts/radworks-gives-1m-to-foss-dependencies-with-drips（访问日期：2026年10月4日）。
［38］Marco De Rossi, Davide Crapis, Jordan Ellis, Erik Reppel：《ERC-8004: Trustless Agents》[EB/OL]，Ethereum Improvement Proposals，2025年8月13日创建，Draft；核验时仍为草案，https://eips.ethereum.org/EIPS/eip-8004（访问日期：2026年10月4日）。
［39］《Client diversity》[EB/OL]，ethereum.org，https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/（访问日期：2026年10月4日）。
［40］DeepSeek：《Session Persistence》[EB/OL]，master 分支文档，https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/persistence.md（访问日期：2026年10月4日）。
［41］SLSA：《Provenance》[EB/OL]，规范 v1.1，https://slsa.dev/spec/v1.1/provenance（访问日期：2026年10月4日）。
［42］Yaqub Chaudhary, Jonnie Penn：《Beware the Intention Economy: Collection and Commodification of Intent via Large Language Models》[J/OL]，Harvard Data Science Review，2024年12月30日，Special Issue 5；DOI：10.1162/99608f92.21e6bbaa，https://hdsr.mitpress.mit.edu/pub/ujvharkk/release/1（访问日期：2026年10月4日）。
［43］《ANP Messaging 1.2 Profile Index》[EB/OL]，Agent Network Protocol 项目，Messaging 1.2；含尚未稳定发布的 P6 配置，https://agent-network-protocol.com/specs/1.2/message/（访问日期：2026年10月4日）。
［44］《Making retries safe with idempotent APIs》[EB/OL]，Amazon Builders’ Library，https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/（访问日期：2026年10月4日）。
［45］D. L. Parnas：《On the Criteria To Be Used in Decomposing Systems into Modules》[J/OL]，Communications of the ACM，1972年，15(12)：1053–1058；DOI：10.1145/361598.361623，https://wstomv.win.tue.nl/edu/2ip30/references/criteria_for_modularization.pdf（访问日期：2026年10月4日）。
［46］《Architectural Principles of the Internet: RFC 1958》[S/OL]，RFC Editor，https://www.rfc-editor.org/rfc/rfc1958.html（访问日期：2026年10月4日）。
［47］DeepSeek：《Process Sandbox》[EB/OL]，master 分支文档，https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/sandbox.md（访问日期：2026年10月4日）。
［48］《HTTP Semantics: RFC 9110》[S/OL]，RFC Editor，第15.5.3节，https://www.rfc-editor.org/rfc/rfc9110.html（访问日期：2026年10月4日）。
［49］Open Collective：《Introduction》[EB/OL]，https://docs.opencollective.com/help/about/introduction（访问日期：2026年10月4日）。
［50］Becca：《Open Source Collective and Drips》[EB/OL]，Drips，2024年9月30日，https://www.drips.network/blog/posts/open-source-collective（访问日期：2026年10月4日）。
