Open

Agent-DX v2 核心约定 #1

fuyipengAdd on Sep 20

fuyipengCollaborators

Sep 20 Create

Agent-DX v2 核心约定

更新：2026-09-20。

本文提取基础设计与 EventLog / Executor 设计中的核心约定，供实施与评审对照，不代表所有能力已经实现。具体协议和存储细节以对应设计为依据。

EventLog 设计扩展基础版本范围：新增 Executor、Invoke、Task 与业务事件日志。原有调度、实例生命周期及平台边界继续保留。基础设计中“EventLog 暂缓、无独立 Executor”的表述属于上一阶段范围。

1. 组件职责

组件	核心职责
Gateway	统一入口、鉴权、请求选址入口、协议转发；Agent 业务实现归属 `agent/`
Dispatcher	实例分配、亲和绑定、冷启动、创建与删除协调；暂时提供独立的 EventLog 存储代理模块
Executor	Task 互斥、Invocation 去重、调用 Harness、输出聚合与重放、事件提交和恢复协调
用户 Harness	Agent 业务执行、语义事件上报、业务状态保存与恢复
Platform / RRT	Sandbox 与进程生命周期、健康检查、重启及故障隔离

新服务端能力采用 Rust，不恢复旧 Python Executor，也不引入旧运行时依赖。ADX 经统一 Sandbox 能力边界访问平台，不直接依赖 Master 或平台内部状态。本轮不修改 platform/；缺失能力单列，可在不影响正确性前提下使用预装镜像验证。

2. 对象与生命周期

对象	约定
Template / Version	执行配置，明确版本；发布不自动启动实例
Context（workspace？）	完整上下文索引，拥有独立实例池，允许多个 Task 并行
Instance	逻辑执行实例，只属于一个 Session 生命周期，对应一个 Sandbox
Session	一项逻辑工作，可经历多次输入，但同一时刻只执行一个 Invocation
Invocation	一次输入及其执行结果，网络重试和该次执行的中断恢复复用原 ID
AffinityBinding	Session 生命周期内的请求亲和映射，不承担资源保活或业务状态恢复

Session 默认无闲置 TTL，允许实例池为空。删除完成后可同 ID 重建，内部通过 generation 隔离新旧生命周期；不保留永久 Released 对象。

Task 等待补充输入时，当前 Invocation 结束，下一次输入使用同一 Task、新 Invocation ID。Task 完成或业务失败后成为终态，新工作使用新 Task。传输或进程中断不能直接解释为业务失败。

3. 亲和与单并发

标准 Invoke 由 Gateway 将 task_id 转为内部 affinityKey，调用方不需要另外指定亲和键。Dispatcher 通过共享状态的条件更新使绑定收敛到同一个逻辑实例，Executor 在实例内对 Task 实施本地互斥。

亲和只在 Session 删除或逻辑实例确认结束时失效。用户进程重启、地址变化或暂时不可达不解除绑定。亲和不阻止实例退出，也不保证业务内存连续。

本地互斥依赖平台保证旧执行停止后才能启动替代执行。亲和绑定与本地锁本身不能阻止两个仍然存活的 Executor 同时执行同一 Task。

4. Dispatcher 多活与发现

Dispatcher 无状态多活，内存缓存可丢弃重建，节点替换不交接内存。一致性 Hash 仅选择优先处理节点、提高缓存命中率；任何健康 Dispatcher 都能处理同一 Session，不引入 Session owner、所有权租约或分片移交。

实例选择统一由 Dispatcher 完成。无亲和请求采用本地随机起点轮询；关键创建与绑定通过共享状态的条件更新收敛。

Dispatcher 在 Redis 注册并续租自身成员信息，Gateway 发现成员并维护路由环。Dispatcher 不启动没有功能消费者的成员订阅或全量成员扫描。部署不要求 Kubernetes，也不引入 etcd。

5. 缓存与失败核验

Dispatcher 缓存 Session、实例池和亲和绑定，普通命中不必访问 Redis。缓存有界，不增加状态变更订阅或广播；本节点更新相关缓存，其他节点通过失败核验收敛。

bypass_cache=true 表示跳过相关选址缓存、读取权威状态，不表示强制换实例或解除有效绑定。核验失败不能回退到本次绕过的旧缓存。

普通转发只在确认业务尚未发送时自动重试；结果未知时不重放。已建立的 WS/SSH 连接不透明重放业务。新的 Invoke 依靠 Invocation ID 单独定义安全重试。

Redis 不可用时，有效缓存可继续支持普通选址；缓存未命中、新绑定及生命周期写入不能降级成本地权威状态。删除过程中允许旧缓存短暂选中仍存活实例，以删除完成作为旧实例不可执行的边界。

6. 创建、删除与持续健康

ADX 负责创建与删除；创建完成后的健康、用户进程重启及同一逻辑实例恢复由 Platform / RRT 负责。

新 Session 初始实例池为空，请求按需触发冷启动，不预留实例或自动补满。
创建前保存稳定身份和 Creating 状态，再通过 Sandbox 能力边界执行创建。
创建默认总期限为 60 秒，Resolve 与其触发的创建共享截止时间，状态查询采用退避；重试或节点替换不重置期限。
创建超时登记删除意图并清理；删除结果未知时保留待协调状态，不能提前宣布删除完成。
Ready 后停止 ADX 周期健康探测，不因业务连接失败解除亲和、降级实例或创建替代实例。

本轮不实现 Draining、自动弹性或持续健康监控。平台外部删除通知等能力未接通时，不宣称 ADX 能感知所有绕过自身的实例终结。

7. 三类调用入口

入口	约定
Invoke	具有 Task / Invocation 语义，经 Executor 调用 Harness
HTTP / WS / SSH	透明转发；受管入口可先按 Session Resolve 并触发冷启动，再使用真实 Sandbox ID 转发
inline create / kill	Gateway 内独立兼容适配，不经过 Dispatcher，不进入受管 Session / Instance 状态系统

共享转发只关注真实 Sandbox ID，不做 ADX UUID 别名探测，不查询 ADX Redis。SSH 可使用先 Resolve、再建立连接的方式。

直连协议不自动产生 Invocation、识别工具事件或获得 Task 单并发约束；受管业务进程可以主动调用本地 Executor 读写所属 Session 的日志。普通 Sandbox 和 inline 不因此被合成 Session。

inline create 等待 Sandbox 接受创建，kill 等待明确删除完成；返回的 UUID 就是真实 Sandbox ID，不另建 ADX 状态副本。旧 invoke 不兼容。

8. 用户接入与协议

Gateway ↔ Executor、Executor ↔ Harness 使用新定义的 gRPC 契约；外部用户仍可通过 HTTP Invoke，不要求 CLI 直接使用 gRPC，也不强制采用特定 Agent SDK 或继承 ADX 基类。

Template 显式配置用户 entrypoint，保留隔离后端选择；service 是调用方式与端口的列表。新增 Invoke 对应 Executor 服务，HTTP/WS/SSH 对应用户服务。

Harness 上报消息边界、消息增量、工具调用与结果等语义。ADX 不从任意进程或网络流量中自动推断 ToolCall。RRT 管理 Executor 与用户 Harness，Executor 不负责拉起、监控或重启用户进程。

9. Invoke 去重与重试

调用方在首次发送前生成 Invocation ID。Executor 在 Task 互斥范围内查询接受及结束记录，同 ID 必须对应相同输入。

情况	行为
未接受且 Task 允许新输入	先提交输入事件，再调用 Harness
同一 Invocation 正在执行	从头返回已有输出，再接实时输出
同一 Invocation 已结束	重放已保存的输出及结束状态，不再次执行
原执行已确认中断	进入 Harness 内部恢复流程
同 ID、不同输入	拒绝
同 Task 的另一 Invocation 尚未结束	返回忙，不隐式排队或并发执行
无法读取历史或安全判断	明确报错，不当作新请求重新执行

客户端重试时用本次响应替换此前展示，不重复拼接。重放保证消息内容与顺序，chunk 切分可以变化。Gateway 切换或输出订阅断开不自动取消执行、释放 Task 执行权或触发再次执行。

10. 一层 EventLog 与两类数据

调度数据层保存当前状态，不保存调度操作流水；EventLog 保存业务语义事件。基础设计的“只保存当前状态”不限制新增业务日志。

Session 是日志范围，Task 和 Invocation 是关联维度。不同 Task 的事件可以交错，不假设连续序号区间，本轮不额外引入 Step 实体。

标准事件为 input.message、output.message、tool.call、tool.result、task.input_required、task.completed、task.failed，以及用户自定义的 custom.*。Task 生命周期事件由 Executor 控制，用户不能通过任意 Append 伪造系统状态。

事件使用稳定 event_id 幂等追加：相同 ID、相同内容返回原结果，相同 ID、不同内容返回冲突。输入事件兼作 Invocation 的接受记录，不另建接受操作流水。

11. 输出与提交边界

用户 Harness → Executor → Gateway → 调用方实时输出
                   │
                   └→ Dispatcher 临时 EventLog 接口 → 数据层 → Redis

输入必须提交成功后才能调用 Harness。流式增量可立即展示，在 Executor 按消息边界聚合成完整消息后写日志，不逐 token 入库，不在 Gateway 聚合。

显式 Append 等待提交确认；必要事件及对应结束记录提交后才能报告最终成功。确认丢失时用原事件 ID 重试，发送成功不等于存储提交成功。

缓冲必须有界，写入阻塞时反压或明确报错，不能丢日志后报告成功。本轮无持久化本地 WAL 保证，Executor 崩溃可能丢失尚未提交的预览输出；恢复后以持久化历史和 Harness 检查点为依据。

12. 存储、安全与清理

EventLog 首先使用 Redis，Executor 经 Dispatcher 临时接口追加和读取，不经过 Gateway。任意 Dispatcher 副本均可处理，不为日志建立 owner。

Executor 使用部署注入的稳定服务地址与受限于 Session/generation 的凭据，不持有 Redis 密码，也不连接 Redis 做发现。服务端验证访问范围，不允许访问任意租户或 key。

日志保留事件正文、顺序、Task 查询索引及去重信息；不按 token 存储。本轮不自动按 TTL 或长度裁剪，Session 删除时关闭追加并清理该生命周期的数据，迟到请求不能重建已删除日志。

存储通过抽象隔离，后续可接分布式文件系统，但需重新核对并发追加、顺序与去重语义。Redis 提交的可靠性受实际持久化和故障切换配置约束；设计不等于已支持 Redis Cluster 或任意故障下零丢失。

13. 中断恢复与平台前提

恢复由 Executor 判断何时进行，由 Harness 实现具体过程。外部继续使用原 Task 和 Invocation ID，不增加 resume_from 或显式恢复模式。

Executor 重启后先读取持久化历史，不能因本地锁消失就接受新输入绕过尚未结束的 Invocation。Harness 根据日志或自身检查点恢复；无法恢复时明确报错，不盲目重跑可能已经发生副作用的工具调用。

RRT 必须确认关联旧执行已停止，才能启动替代执行。多进程声明式启动、独立健康策略、进程组故障联动及受保护配置注入属于平台待补齐能力。

预装镜像可验证调用和日志链路，但不能替代进程组故障联动；平台前提不满足时，不得将 Executor 崩溃恢复或无双重执行标记为已保证。

fuyipengCollaborators

Sep 20 Modify description of issue

fuyipengCollaborators

Sep 20 Modify description of issue

fuyipengCollaborators

Sep 20 Modify description of issue

fuyipengCollaborators

Sep 21 Comments：

Jiuwen 插件生态推广策略

日期：2026-09-21｜讨论稿 v1.0｜面向产品、研发、社区运营与合作伙伴团队

核心策略：让已有插件进入 Jiuwen，先用少量经过验证的插件解决真实任务，再通过使用案例、维护者合作和标准社区扩大供给。

本方案只考虑导入兼容，不要求作者维护 Jiuwen 专属包，不建设面向其他客户端的导出工具。技术范围与投入基线参见插件生态建设方案。文中数量、转化率和时间目标均为建议的试点目标，不是已有业务数据或行业基准。

1. 定位与推广承诺

1.1 对外定位

建议使用的核心表述：

把已有的 Agent 插件带到 Jiuwen，在统一入口中发现、配置和使用，并清楚了解每个组件的支持范围。

不同对象关注点不同：

对象	应传达的价值	应提供的证据
使用者	已有工具和技能可以进入 Jiuwen，减少重新配置与学习成本	从原包导入到完成一次任务的演示、配置前提和限制
团队负责人	可以选择经过验证的版本，统一分发并定位运行问题	安装来源、版本、组件状态、失败原因、升级与回滚说明
插件维护者	无需另起一套包格式，有机会触达 Jiuwen 用户	原仓库署名、兼容验证记录、问题分工及使用反馈
标准与开源社区	Jiuwen 提供实际实现、测试用例与反馈	可复现的符合性结果、文档和上游贡献

最初应先证明“在现有工作中有用”。多 Agent 协作可以作为后续案例，但不应成为所有插件必须支持的前提。

1.2 发布什么能力，就宣传什么能力

Agent Plugins 的公共格式当前定义 Skills 与 MCP；客户端扩展各自规定行为。因此，支持公共格式不等于支持任意宿主扩展。Agent Plugins 规范

技术阶段	可以推广的内容	暂不承诺的内容
P0 / 公共组件首版	标准包及通过验收的 CC、Codex、Cursor 包中的 Skill/MCP	任意插件完整兼容、所有 Hook 自动生效
P1 / 行为适配	已列明事件的 command Hooks，以及已验收的命令、规则、子代理	未实现的事件、IDE 专属能力、原产品托管服务
P2 / DSH 托管	指定 Bundle 在固定 DSH SDK/profile 中运行，结果回到 Jiuwen	DSH 插件直接增强 DeepAgent；未实现的中断恢复
P3 / OpenCode	已验证的受限桥接插件，或运行于 OpenCode Provider 的插件	完整模拟 OpenCode SDK、任意代码插件无差别运行

每个市场条目展示“可用组件、执行位置、测试版本、已知限制”。对外统一使用“经 Jiuwen 验证”，不能使人误解为获得 Claude、OpenAI、Cursor 或其他厂商的官方认证。

2. 优先服务谁，先解决哪些任务

2.1 种子用户顺序

优先级	人群	选择理由	首轮招募方式
第一批	已使用 Jiuwen、能提供真实工作任务的研发团队	环境和反馈渠道已经存在，容易辨别插件增加的价值	现有社区与项目用户定向邀请
第一批	已使用 CC/Codex/Cursor 插件，且有 Jiuwen 使用需求的开发者	有明确的导入对象，可以比较迁移前后效果	“带一个常用插件来试跑”邀请
第二批	内部开发平台、知识平台负责人	有团队分发、版本管理和重复使用需求	从第一批持续使用团队中发展
第二批	活跃插件维护者、MCP 服务提供者	能提供可靠供给和版本协作	针对具体插件邀请共同验证
后续	DSH/OpenCode 的重度扩展开发者	宿主依赖深，必须等待相应执行路径	小范围专项技术试点

建议首轮选择 5 个团队、10–20 名实际使用者。要求每个团队指定一名联系人，提供至少一个每周会发生的任务，安排两次以上试用；不以注册或加入群聊作为有效参与。

2.2 首批三个场景

场景	用户任务	首版适合引入的能力	成功证据
代码审查与测试分析	根据团队规范审查改动、解释失败测试	审查 Skill、代码/规范查询 MCP	使用者确认发现的问题有效，或分析结果可直接推进修复
文档与知识检索	从项目资料回答问题并给出依据	知识检索 MCP、总结/问答 Skill	回答引用可核对，用户实际采用结果
研发流程协作	汇总问题、生成迭代摘要或变更说明	任务查询 MCP、整理 Skill	结果被用于真实会议、工单或交付材料

首版选择查询、分析和生成草稿等容易检查的任务。需要强制策略控制的案例，必须等待 Hook 控制链验收后才使用相应宣传。每个场景至少准备一个无需私人数据的演示样本，以及一个真实团队验证案例。

3. 供给策略：引入现有插件，并建立维护责任

3.1 从候选池到首发集合

建议建立 30–40 个候选插件的调研池，从中选择技术方案中的 12–18 个样本完成验证。通过多少就上架多少；不为凑数量把部分可用的包标成完整兼容。

候选池按任务价值组织，不强制每个生态分配相同名额。标准包和低宿主依赖的 Skill/MCP 优先；OpenCode、DSH 先保留专项候选清单。

评分项	权重	判断方法
真实需求	30%	是否有种子团队提出明确任务，是否会重复使用
兼容成本	25%	依赖已交付组件的程度，是否需要大量模拟宿主 API
可维护性	20%	上游更新、问题响应、依赖稳定性与测试情况
配置与运行成本	15%	凭据、网络、运行环境和服务费用是否可解释
可演示性	10%	能否用公开样本清楚展示输入、执行和结果

此外设独立的收录条件：来源明确、可按适用条款分发或引用、关键依赖可获得、存在可维护的安装路径。不能用总分抵消这些条件。

3.2 支持三种收录方式

方式	适用情况	平台责任
源地址引用	插件已有稳定仓库或发布地址	固定 revision/版本及摘要，说明下载来源与依赖
原包托管	具备相应分发条件，需要稳定下载	保留原包、作者和许可证信息，记录来源及撤回流程
维护者提交	作者愿意主动参与 Jiuwen 生态	提供提交与验证入口，反馈兼容报告，支持版本更新

不默认批量镜像其他市场，也不把“平台收录”写成“作者已合作”。如确实需要修改插件代码，应记录补丁归属和维护方，并优先与上游协作；通用格式与协议适配则由 Jiuwen 负责。

3.3 每个条目必须有负责人

建议将状态分为：候选、测试中、已验证、部分支持、暂不可用、已撤回。对外首页优先推荐状态清楚、近期有验证且存在重复使用证据的条目。

每个上架版本记录：

原始来源、作者、版本/revision、产物摘要。
支持组件、运行位置、配置前提和已知限制。
Jiuwen/适配器版本、验证平台、最近验证时间。
一名平台兼容负责人；如果作者参与，再单列上游联系人。
安装指南、样本任务、失败反馈入口。

同一原包通过不同导入路径上架，不应重复计算为多款独立插件；重命名或轻微改写的条目也不作为生态增长。

4. 维护者合作：降低参与成本，提供实际回报

4.1 合作主张

建议向维护者提供的具体合作内容是：

Jiuwen 团队负责宿主适配与兼容验证，保留你的原包和作者信息。我们邀请你核对用途、配置和限制，并共同处理真实用户反馈；无需为了收录另维护一种包格式。

优先招募 3–5 位维护者作为首批共建伙伴。合作深度可以逐步增加：先确认条目和使用说明，再参与版本回归，最后共同发表案例。

参与方	主要责任	不应转嫁的工作
Jiuwen	Adapter、运行时问题、测试环境、平台文档与用户支持	不让作者为平台通用兼容缺陷逐包改代码
插件维护者	插件用途、上游逻辑、依赖及发布说明	不要求其承担 Jiuwen 全套测试与平台运维
试点团队	提供任务、确认结果、反馈配置与使用障碍	不把生产故障排查全部交给试点用户

4.2 激励围绕使用与维护

先提供署名、案例展示、兼容测试报告、问题协助及可选择查看的汇总使用反馈。预算允许时，为有明确验收条件的维护任务提供支持，如修复兼容问题、补充测试或维护一个版本周期。

不按上传数量、下载量、点赞量直接发放奖励。建议把激励池分配为：40% 场景验证与案例、30% 维护和问题修复、20% 文档与测试、10% 技术交流。比例是预算建议，资金规模需由团队另定。

openJiuwen 已有社区、贡献渠道和开发者成长体系，可向对应负责人提出纳入插件验证、文档及维护贡献的建议；不能未经确认就承诺现有认证或积分。社区入口、开发者成长体系

5. 使用者增长：围绕一次成功任务组织推广

5.1 一条明确的转化路径

用户看到相关任务案例
  → 进入场景页
  → 检查组件支持、凭据与运行前提
  → 安装插件并完成配置
  → 使用样本完成第一次任务
  → 在自己的工作中再次使用
  → 团队复用并提供反馈

每篇文章、视频和活动都只设置一个主要行动入口，例如“安装该插件并运行样本任务”。不要让用户在多个群、多个仓库和多个教程之间自行寻找下一步。

市场首页建议先提供三个场景入口，每个入口推荐 3–5 个经过验证的条目。推荐必须依据该用户的运行环境；缺凭据、仅部分支持或需要外部 Harness 的情况在安装前说明。

5.2 渠道优先级

渠道	首轮动作	衡量结果
Swarm 产品内入口	在插件广场展示场景集合、示例任务和支持范围	安装就绪率、首次任务完成率
openJiuwen 社区与 AtomGit	每周一篇具体实践，集中处理试用问题	有效试用、问题关闭、重复使用
上游插件仓库	维护者同意后补充 Jiuwen 使用说明或验证链接	从该来源进入并激活的用户
技术文章与演示视频	一篇内容解决一个任务，展示完整操作和限制	内容带来的首次成功任务及后续使用
小型线上技术交流	带着自己的插件或任务参加，现场定位问题	会后实际运行成功及两周后复用
标准社区	贡献符合性测试和实现反馈；满足条件后申请客户端收录	实现问题得到解决、可核验的收录结果

初期不建议大规模投放广告。先验证“访问之后能成功使用”，否则放大的是安装失败和支持压力。暂不把付费推广当作自然增长预测的基础。

5.3 内容计划

第一轮准备六类素材：

三个场景各一篇完整教程：前提、安装、样本、结果和排错。
一篇“导入一个已有插件”的指南：原包保持不变，组件支持范围明确。
一篇兼容说明：公共组件、适配组件与外部 Harness 执行的区别。
一份常见失败指南：凭据、依赖、网络、工具别名和不支持的组件。
一段短演示：从安装到成功任务，使用真实可运行版本。
一篇种子团队案例：原流程、试用范围、实际结果、人工检查与限制。

案例的时间或质量收益必须有可核对的比较方法，保留人工复核时间。没有数据时描述具体流程变化，不使用“提效数倍”等无证据结论。

6. 上线前准备与公开 Beta 后 90 天节奏

6.1 推广日历从能力就绪开始

定义 T0 = 公共组件首版通过验收、允许公开 Beta 的日期。T0 不是今天，也不是研发启动日。技术方案中的首版 6–9 周只是带前提的研发估算，不能提前写成确定发布承诺。

上线前即可完成访谈、候选插件筛选、维护者沟通和教程准备；公开宣传应等待真实运行证据。若 Hub 接入还没有明确，只推进封闭试点，不宣传公共市场已可用。

6.2 阶段交付与推进条件

阶段	主要工作	建议目标	进入下一阶段的条件
T0 前：准备与封闭试点	访谈、筛选、12–18 个样本验证、打通三个场景	5 个团队、10–20 名实际使用者；至少 6 个可公开试用条目	核心任务可复现，安装与支持入口可用，重大阻断已处理
T0–30 天：小规模公开 Beta	三个场景页、安装指南、两次答疑，集中修复首次使用障碍	累计 10 个激活团队，12–18 个通过验证的条目，3 个可引用案例	有足够样本评估就绪率和任务完成率；有人跨周复用
31–60 天：复制有效场景	把资源集中到前期表现最好的两个场景，引入维护者共同验证	累计 15–20 个激活团队，5 位参与维护者，20–25 个验证条目	重复使用改善，新增条目有真实需求，支持负担可控
61–90 天：形成维护节奏	版本回归、联合教程、团队内分发；按技术阶段开放专项试点	累计 20–30 个激活团队，30 个左右验证条目，8–12 个每周重复使用团队	能说明用户为何留下，并能持续维护已收录版本

以上是小规模启动的管理目标，不是流量预测。T0 前样本数量不足或验证未通过，就缩小公开范围；不降低兼容标准。早期数据不足时先报告计数和失败原因，不用几个样本计算“生态成功率”。

DSH/OpenCode 不强行绑定第 60 天或第 90 天。对应 Provider/桥接通过验收后，再开每条路线 2–3 个团队的专项试点；市场上独立显示其运行位置。

7. 指标体系：看持续使用与维护质量

7.1 核心指标

建议把 每周重复使用插件完成任务的团队数作为主指标。

定义：某团队在本周和前一周均至少完成一次真实插件任务；排除平台演示账号、回归测试和自动健康检查。同一团队不因使用多个插件重复计数。

真实任务完成应有产品侧可核对的完成信号，必要时通过用户确认或抽样回访验证。MCP 返回成功、Hook 正常退出或模型生成文字，都不自动等于用户任务完成。

7.2 漏斗与运行指标

指标	建议口径	初始管理目标
安装就绪率	用户/插件/版本在 24 小时内去重后的安装意图中，达到可执行状态的比例；等待凭据的仍计入分母	先建立基线，稳定后争取 ≥85%
首次任务完成率	新就绪的团队/插件组合中，7 天内完成一次真实任务的比例	试点后争取 ≥60%
四周团队留存	首次完成任务的团队，在第 4 周仍完成任务的比例	以 ≥40% 为初始观察目标
验证时效覆盖	当前推荐版本中，有效验证未被后续版本变化失效的比例	所有推荐条目具备有效证据
兼容问题首响	受理问题到第一次有效回复的工作日时长	Beta 期内部目标 1 个工作日；不直接宣传为 SLA
维护负担	每 10 个完成任务的团队消耗的支持工时	首月测量，之后应下降
作者持续参与	过去 30 天参与版本验证、修复或文档更新的维护者数	随条目数量增长，不只看签约人数

目标值均非行业标准。比例须同时公布分子、分母和观察窗口；安装就绪率至少积累 30 个独立安装意图再用于阶段判断。四周留存只统计已完整经过观察期的团队。

推荐记录最少的运行元数据：入口来源、插件版本、适配器版本、执行路径、状态和结构化失败类别。按已有隐私与授权机制收集；不把用户代码、提示词、凭据和工具响应正文作为默认推广分析数据。不能提供遥测的部署，用自愿回访和汇总记录单独统计。

7.3 数据如何改变行动

观察	优先动作
访问很多，安装少	检查场景匹配、兼容说明和前置成本
安装多，就绪少	修依赖、凭据和状态引导，暂缓增加推广流量
就绪多，任务完成少	改善示例任务、Skill 发现和结果可验证性
首次成功多，复用少	判断任务是否高频、插件是否优于原有做法
新插件多，维护问题累积	收紧上架节奏，把资源转向版本回归

不将下载数、市场总条目数或社群人数单独作为生态健康的结论。

8. 社区与标准参与

8.1 复用现有社区入口

openJiuwen 社区已有论坛、活动日历、贡献和 SIG 入口，并链接 Swarm Skills Hub。建议在现有入口增加插件专题和定期答疑，形成统一的问题入口，而不是同时创建多个新社区。openJiuwen 社区

适合开放给社区的贡献包括：补充源格式样本、编写可复现兼容用例、完善指南、验证新版本、提交通用 Adapter 修复。每类任务说明预期产物、验收方式和维护人。

8.2 参与 Agent Plugins

先完成实际支持和用户文档，再考虑申请进入 Agent Plugins 的兼容客户端列表。其贡献指南要求支持已经可用、能力可核验，且收录是维护者筛选的参考列表，不保证申请必然通过，也不代表官方背书。客户端收录规则

建议提交对象是用户实际使用的 Jiuwen 产品形态，并精确列出从标准插件包加载的组件和 MCP transport。不能把 Core SDK 存在某个 API 当作整个产品已支持的证据。

标准贡献和适配器修复应首先解决用户遇到的真实问题；宣传材料可以介绍已合入成果，不预先声称合作关系。

9. 运营组织、资源与响应机制

9.1 建议人员配置

角色	建议投入	负责结果
生态/产品负责人	1 人全职	用户选择、场景优先级、Hub 协作、指标与阶段决策
开发者关系/技术内容	0.5 人	教程、维护者沟通、技术交流与案例
社区支持/运营	0.5 人	试点跟进、问题分类、反馈闭环与条目维护
研发与测试共享支持	约 0.5–1 人等效投入，按试点调整	兼容验证、问题定位、版本回归

前面三项合计约 2 人全职等效运营投入。研发与测试支持如由建设方案中的 4 人团队承担，必须显式预留容量，会影响研发排期；不能把同一份人力同时计为满负荷开发和生态支持。

首期优先把可支配预算用于样本环境、维护支持和可复现内容。正式资金预算应在候选插件服务费用、人员成本和试点规模明确后编制，本稿不以未经核实的价格给出总金额。

9.2 每周运营节奏

周初：研发与运营查看同一张漏斗表，选出前三个影响使用的问题。
周中：与种子团队共同完成任务，处理维护者反馈，更新兼容记录。
周末前：发布一项已经验证的案例或修复说明，复查推荐版本。
每两周：评审新候选插件，决定上架、继续验证或暂缓。
每月：复盘跨周使用、维护负担、伙伴参与和下阶段范围。

升级导致失效的条目应暂停推荐或固定到最近验证版本，并给出原因。运行时缺陷由研发负责，原插件业务问题与上游协作，账户或服务访问问题由配置支持处理；用户始终有一个清晰的受理入口。

10. 首轮可直接执行的清单

次序	工作	负责人	交付物
1	确认 Hub 接入、收录和外部原包支持路径	产品 + 平台后端	一页接入责任与限制说明
2	访谈首批 5 个团队，选三个任务场景	生态负责人	任务、频次、当前流程、成功判定与联系人
3	建立 30–40 个候选池，选 12–18 个验证样本	DevRel + 技术负责人	候选表、来源及组件依赖
4	为样本固定版本，记录验收结果和维护人	研发/测试	组件级兼容报告与问题清单
5	邀请首批 3–5 位维护者参与核对	生态负责人	合作范围、署名方式和问题分工记录
6	制作三个场景教程与可公开数据	DevRel	可复现文档、样本任务和短演示
7	接通安装、就绪、首次完成和复用的度量	产品 + 研发	指标字典和基础看板
8	达到公开条件后启动 Beta	项目负责人	实际版本、支持范围、反馈入口与维护安排

这些工作可以在研发期间逐步准备，公开 Beta 必须通过就绪条件。首轮沟通、活动安排、资金激励和公开发布都需要由团队实际执行；本次交付的是策略文档，未联系任何维护者或发布任何宣传内容。

11. 建议采用的启动决策

建议以“5 个种子团队、3 个场景、12–18 个验证样本”作为启动范围，复用现有市场和社区入口。先证明一批团队能连续使用，再扩大插件供给和传播渠道。

首批投入以公共 Skill/MCP 兼容为基础，行为兼容与外部 Harness 根据研发验收逐步推广。90 天复盘时，重点回答三个问题：哪些任务带来了重复使用、哪些插件能持续维护、哪些推广渠道带来了实际成功任务；据此决定下一阶段人员和预算。

fuyipengCollaborators

5 days ago Comments：

fuyipengCollaborators

4 days ago Comments：

上传最新版 digitalmate 场景方案（8 页），包含全景部署架构，以及 AgentOS Enterprise 的 agent-dx 替换方案。

下载可编辑 PPT（8 页）