Jcode 集成发现（Discovery）转化率深度分析：从 1.7% 的选择率到六条可落地的优化结论

Jcode 集成发现（Discovery）转化率深度分析：从 1.7% 的选择率到六条可落地的优化结论

【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode

本文基于 docs/DISCOVERY_CONVERSION_ANALYSIS.md 展开，它记录了 jcode 在 2026-07-25 对"集成发现（integration discovery /discover_tools）"功能做的一次端到端转化审计。文章完整继承该分析的数据来源、漏斗数字、根因结论与行动清单，并对照当前仓库源码（配置结构、工具注册逻辑、遥测表结构）给出实现级佐证，帮助读者理解：为什么这个让 Agent 发现第三方工具的功能"叫得少、选得更少"，以及如何把 1.7% 的选择率修上去。

一、分析背景与数据来源

这次转化分析由两套 D1（Cloudflare D1）数据库的数据拼接而成，分别覆盖客户端与服务端视角：

• 客户端尝试：来自jcode-telemetryD1，将discovery_details与events表 join，能够覆盖从未到达过发现端点的尝试（例如本地被禁用、输入校验失败等纯客户端失败）。
• 服务端漏斗：来自jcode-subscriptionsD1，使用discovery_request_events、discovery_events、discovery_suggestions三张表，提供漏斗各阶段计数、原始query/reason文本，以及 provenance（来源）分类。

客户端侧的服务端调用者标签字段provenance_class IN ('likely-user','unverified')，用于把真实用户需求与自我开发（self-dev）、内部、基准测试流量区分开，避免它们虚增需求数字。

同时流量被过滤为benchmark_run = 0。在源码中，基准测试流量通过环境变量JCODE_DISCOVERY_BENCHMARK标记（见 crates/jcode-app-core/src/tool/discover.rs），保证分析只看真实用户行为。

二、头条数字：一个功能暴露出的双重问题

分析结论是两个独立问题叠加：

1. 调用面窄：过去 7 天有 41,838 个用户产生过会话，但只有 444 人（1.1%）调用过discover_tools；
2. 转化极差：即便调用了，460 个真实的浏览单元（session × category）中只有 8 个走到select（1.7%），高达 58% 的浏览以suggest（Agent 明说"目录里没有匹配项"）收场，还有 41% 既无select也无suggest直接消失。

换句话说：问题不仅是没人用，更在于用了也几乎永远买不到货——浏览返回的产品与请求不匹配。

三、Blockers：168 个用户被硬性禁用，工具根本没注册

discovery_details中记录了 168 次failure_reason = 'disabled'，每个不同用户恰好一次，占"尝试过发现功能的 625 个用户"的 27%。这些客户端版本大多是 opt-out 翻转之后发布的（0.54.4: 93 个，0.58.0: 35 个），因此可以断定：它们来自持久化到~/.jcode/config.toml的[sponsors] enabled = false条目，而不是当前代码的默认值。

根因：一次"冻结"事故

时间线非常清晰：

• 发现功能在 commit203a3f3d3（v0.36.x）以opt-in方式上线，默认enabled = false；
• 而Config::save()会用toml::to_string_pretty序列化整个配置结构体写回磁盘。只要在那个窗口期发生过任何一次配置写入，enabled = false就被"冻结"进了用户的配置文件；
• 后续 commite226b84c4的 opt-out 翻转只改了代码内默认值，没有迁移已持久化的配置。

于是这些文件里的enabled = false永远禁用了该工具——不是"不可用"，而是 Agent 根本看不到discover_tools。

源码佐证：禁用如何层层生效

当前仓库的实现可以完整印证这条链路：

1. 配置结构：SponsorsConfig定义在 crates/jcode-config-types/src/lib.rs（legacy[sponsors]段名），包含enabled: bool与endpoint: String，默认值分别是true与https://api.jcode.sh/v1/discovery，并附有单测discovery_is_enabled_by_default保证默认开启；
2. 工具注册：在 crates/jcode-app-core/src/tool/mod.rs 的工具表构建逻辑中，if crate::config::config().sponsors.enabled为真才插入integration_tools（即discover_tools）。禁用时工具不注册、发现端点也不会被联系；
3. 执行期兜底：即便工具被注册，crates/jcode-app-core/src/tool/discover.rs 的execute入口仍会检查config.sponsors.enabled，为false时记录failure_reason = Some("disabled")的遥测并返回错误，提示用户到config.toml里设置[sponsors] enabled = true。

配置文件模板中对这一段的说明保留在 crates/jcode-base/src/config/default_file.rs："Integration discovery (enabled by default; set enabled = false to opt out)"，并明确商业关系不影响推荐。

四、按品类漏斗：空目录是最大的确定性流失

以下为真实流量（session × category 单元）的分品类漏斗：

数据采集时18 个分类中有 13 个在目录里是空的，因此 60% 以上的浏览必然返回零结果，Agent 随后还要再花一次调用去suggest。即便是五个有库存的品类，转化率也只在个位数。

该分析之后新增了financial-data品类（服务端作为空目录上线），并不改变比例：部署目录当时是 19 个分类中仅 5 个有库存。对照当前源码，分类常量DISCOVERY_CATEGORIES位于 crates/jcode-base/src/sponsors.rs，现为 20 个 slug（含payments、git、code-review、databases、browser-automation、deployment、observability、authentication、security、storage、analytics、web-search、web-data、financial-data、cloud-infrastructure、compliance-and-privacy、integration-platforms、email-messaging、ai-models、other），并有单测锁定"非空、小写、slug 格式"以及"与公开分类体系一致"。注意：分类常量是随客户端发货的常量，工具 schema 的构建不依赖网络请求，这意味着新增分类需要随版本发布，而目录库存则在服务端按需下发。

五、为什么三个有库存的品类也不转化

该分析从 likely-user/unverified 浏览的原始query文本中分桶统计（这三个品类共 85 次浏览，其中 18 次因早于清单上线而返回零结果），结论极具说服力：需求与库存错配。

payments（15 个单元，1 次 select）

目录里只有一条条目：Agentcard——面向 Agent 的预付虚拟 Visa 卡。但真实需求是：

• 9 个查询想要的是商户收款，而非 Agent 消费：托管结账、周期性订阅、客户门户、签名 webhook、支付链接、Stripe 生产模式产品管理、带分账的市场 escrow；
• 4 个查询想要区域性或平台化支付通道：Razorpay 查询、微信支付 v3、Toss Payments 商户入驻、Google Play Billing / RevenueCat 订阅测试；
• 1 个查询是供应商账单内省（"读取我的 API 额度/扣费"）；
• 只有1 个查询是真正的虚拟卡匹配，并且它转化了。

被点名的缺失产品：Stripe Billing、Stripe Connect、Stripe、Razorpay、Google Play Billing、Toss Payments。

code-review（18 个单元，3 次 select）

目录里是 Greptile——基于仓库上下文的 PR 审查，但它要求 Node 22、全局 npm 安装、交互式greptile login以及 Agent 无法完成的greptile onboard向导：

• 9 个查询实际上是 Git 主机鉴权问题，不是代码审查：推送到被拒的上游、fork 并开 PR、私有 Gitea 推送、GitLab MR 讨论与行内评论、GitHub issue 访问；
• 7 个查询想要一个能审查未提交 diff 的独立本地审查者（通常因为 swarm 审查者没起来），或者点名要 SonarQube/Ponytail/OpenCode Orcal。Greptile 不先 onboarding 仓库就无法审查未提交的本地 diff；
• 3 次 select 全部来自措辞恰好命中"repository-aware PR review"的查询。

文档指出这里的主导模式是：jcode 自身功能的失败（swarm 审查者不可用、递归 spawn 被禁用）泄漏成发现功能的求助流量。

web-data（27 个单元，2 次 select）

目录里是 context.dev——通用抓取与结构化抽取。需求分布：

• 12 个查询要的是特定数据源，不是通用爬虫：YouTube/Bilibili 字幕、丹麦土地登记、Google Merchant Center、ACM 按 DOI 全文、Polygon.io 股票、Figma 文件、Mobbin 截图、反向电话查询、ETF 历史、股票视频 API；
• 4 个查询要搜索引擎 API，因为websearch被反机器人页面拦截了；
• 2 个查询要 GitHub MCP 仓库访问；
• 11 个是零散的一次性富化/抽取需求；
• 2 次 select 均来自措辞为通用抓取/抽取的查询。

六、最常被请求的缺失产品（全品类命名建议）

railway 6, playwright 5, vercel 5, supabase 4, github 3, gitlab 3, coolify 3, hitl-notary MCP 3, notion 3, litellm 2, LM Studio 2, cloudflare 2 (+workers 2, R2 2, api 2), github MCP server 2, slack MCP 2, linear 2, figma MCP 2, polygon.io 2, agentmail 2

一句话总结：Agent 在要基础设施与集成类 MCP，而不是赞助商产品。需求侧与供给侧的错位在此一览无余。

七、六条可行动结论

1. 修复 168 个被卡死的配置。把 opt-out 翻转之前写入的持久化sponsors.enabled = false视为未设置，或加载时一次性迁移；同时阻止Config::save()把默认值段落回写磁盘——正是它冻结了这个标志。
2. 填满空分类，或收缩分类列表。14 个空分类意味着绝大多数浏览注定 miss，Agent 还要多花一次调用去suggest。新增一个没有清单的分类只会让 miss 率更糟：每个新空分类 = 又一个必然零结果的浏览 + 一次后续suggest。
3. 把 payments 扩展到 Agent 发卡之外。商户收款占 payments 需求的 60%，目前完全没有对应清单。
4. 把 code-review 与 Git 主机访问拆开。大多数 code-review 浏览其实是鉴权/访问类请求，一个 GitHub/GitLab 清单就能服务它们；而 Greptile 的交互式 onboarding 对 Agent 自助完成设置是硬阻塞。
5. 修复生成发现流量的上游功能故障：swarm 审查者 spawn 失败与被拦截的websearch占据了 code-review 与 web-data 浏览的很大比例。
6. 给 setup 完成埋点。discovery_usage目前为空，select之后的任何阶段都不可观测——没有它，select就是我们仅有的转化代理指标。

八、延伸阅读：discovery 的工程实现与观测基础设施

为了让上述结论可验证、可复现，仓库提供了完整的实现与观测设施：

• 工具动作模型：DiscoverToolsTool（内部 name 为integration_tools，对外即文档所称discover_tools）支持search/browse、details、select/setup、suggest四个动作，并兼容旧词汇别名以保证历史转录与基准基线可用（见 crates/jcode-app-core/src/tool/discover.rs）。query至少 20 字符、reason至少 40 字符，且通过has_sufficient_detail做词数与去重校验，防止低信息量请求污染漏斗；请求带 3 秒硬超时、64 KiB 响应上限，无缓存、无离线回退、无重试——发现是可选功能，失败就干净地失败，Agent 继续走常规工具集。
• off-catalog select 可度量：选择目录外产品会得到合法回执但无任何供应商信息，OFF_CATALOG_FAILURE_REASON = "off_catalog_select"与传输失败区分开，使"Agent 承诺使用目录外产品"的速率可统计而非混入http_error。
• 遥测表结构：discovery_details表定义在 telemetry-worker/migrations/0017_discovery_telemetry.sql，字段覆盖phase、category、selected_tool、outcome、failure_reason、http_status、latency_ms、response_bytes、result_count、query_present、reason_present等，并建有phase/outcome、category/outcome、selected_tool、failure_reason等索引，支撑本文档这类聚合分析；迁移 0019 又追加了benchmark_run字段用于隔离基准流量。客户端遥测路径由 crates/jcode-telemetry-core 承载。
• 配套资料与工具：功能设计见 docs/DISCOVERY_ELICITATION_SPEC.md，基准方法见 docs/DISCOVERY_BENCHMARK.md 与 docs/DISCOVERY_RATE_BENCHMARK.md，赞助商入驻流程见 docs/SPONSORED_DISCOVERY_SPONSOR_ONBOARDING.md，Agentcard 演示见 docs/AGENTCARD_DISCOVERY_DEMO.md；可复现脚本包括 scripts/benchmark_discovery.py、scripts/benchmark_discovery_rate.py、scripts/verify_discovery_select.py 与 scripts/run_openrelay_discovery_test.sh。

结语

这次转化分析的价值不在于单个数字，而在于它把"功能没人用"拆成了两个可分别修复的问题：可见性（1.1% 调用率，其中 27% 被陈旧配置硬禁用）与供给匹配（空目录 + 需求错配导致 58% 的 suggest 与 1.7% 的 select）。六条结论里有配置迁移、目录策略、品类拆分与埋点补齐，全部可以直接对照 docs/DISCOVERY_CONVERSION_ANALYSIS.md 及上文列出的源码路径继续跟进。对于任何为 Agent 提供"可发现第三方能力"的平台而言，这都是一份可复用的漏斗审计模板：先分清是没人调用，还是调用了买不到货——两者的修复手段完全不同。

【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode