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% 的选择率修上去。一、分析背景与数据来源这次转化分析由两套 D1Cloudflare 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保证分析只看真实用户行为。二、头条数字一个功能暴露出的双重问题metricvaluedistinct users with any session, last 7d41,838distinct users who invokeddiscover_tools, last 7d444 (1.1%)real browse units (session x category, likely-user/unverified)460units reachingselect(setup fetch)8 (1.7%)units ending insuggest(agent says the catalog has no fit)265 (58%)units that just stop with no select and no suggest187 (41%)distinct users blocked bysponsors.enabled false168分析结论是两个独立问题叠加调用面窄过去 7 天有 41,838 个用户产生过会话但只有 444 人1.1%调用过discover_tools转化极差即便调用了460 个真实的浏览单元session × category中只有 8 个走到select1.7%高达 58% 的浏览以suggestAgent 明说目录里没有匹配项收场还有 41% 既无select也无suggest直接消失。换句话说问题不仅是没人用更在于用了也几乎永远买不到货——浏览返回的产品与请求不匹配。三、Blockers168 个用户被硬性禁用工具根本没注册discovery_details中记录了 168 次failure_reason disabled每个不同用户恰好一次占尝试过发现功能的 625 个用户的 27%。这些客户端版本大多是 opt-out 翻转之后发布的0.54.4: 93 个0.58.0: 35 个因此可以断定它们来自持久化到~/.jcode/config.toml的[sponsors] enabled false条目而不是当前代码的默认值。根因一次冻结事故时间线非常清晰发现功能在 commit203a3f3d3v0.36.x以opt-in方式上线默认enabled false而Config::save()会用toml::to_string_pretty序列化整个配置结构体写回磁盘。只要在那个窗口期发生过任何一次配置写入enabled false就被冻结进了用户的配置文件后续 commite226b84c4的 opt-out 翻转只改了代码内默认值没有迁移已持久化的配置。于是这些文件里的enabled false永远禁用了该工具——不是不可用而是 Agent 根本看不到discover_tools。源码佐证禁用如何层层生效当前仓库的实现可以完整印证这条链路配置结构SponsorsConfig定义在 crates/jcode-config-types/src/lib.rslegacy[sponsors]段名包含enabled: bool与endpoint: String默认值分别是true与https://api.jcode.sh/v1/discovery并附有单测discovery_is_enabled_by_default保证默认开启工具注册在 crates/jcode-app-core/src/tool/mod.rs 的工具表构建逻辑中if crate::config::config().sponsors.enabled为真才插入integration_tools即discover_tools。禁用时工具不注册、发现端点也不会被联系执行期兜底即便工具被注册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.rsIntegration discovery (enabled by default; set enabled false to opt out)并明确商业关系不影响推荐。四、按品类漏斗空目录是最大的确定性流失以下为真实流量session × category 单元的分品类漏斗categoryunitsselectsuggestsilent dropai-models6603729other6012831integration-platforms5802830deployment440377browser-automation3011316web-data272916web-search2601115cloud-infrastructure240204email-messaging200128code-review18396databases170143payments151104数据采集时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 次因早于清单上线而返回零结果结论极具说服力需求与库存错配。payments15 个单元1 次 select目录里只有一条条目Agentcard——面向 Agent 的预付虚拟 Visa 卡。但真实需求是9 个查询想要的是商户收款而非 Agent 消费托管结账、周期性订阅、客户门户、签名 webhook、支付链接、Stripe 生产模式产品管理、带分账的市场 escrow4 个查询想要区域性或平台化支付通道Razorpay 查询、微信支付 v3、Toss Payments 商户入驻、Google Play Billing / RevenueCat 订阅测试1 个查询是供应商账单内省读取我的 API 额度/扣费只有1 个查询是真正的虚拟卡匹配并且它转化了。被点名的缺失产品Stripe Billing、Stripe Connect、Stripe、Razorpay、Google Play Billing、Toss Payments。code-review18 个单元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 仓库就无法审查未提交的本地 diff3 次 select 全部来自措辞恰好命中repository-aware PR review的查询。文档指出这里的主导模式是jcode 自身功能的失败swarm 审查者不可用、递归 spawn 被禁用泄漏成发现功能的求助流量。web-data27 个单元2 次 select目录里是 context.dev——通用抓取与结构化抽取。需求分布12 个查询要的是特定数据源不是通用爬虫YouTube/Bilibili 字幕、丹麦土地登记、Google Merchant Center、ACM 按 DOI 全文、Polygon.io 股票、Figma 文件、Mobbin 截图、反向电话查询、ETF 历史、股票视频 API4 个查询要搜索引擎 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而不是赞助商产品。需求侧与供给侧的错位在此一览无余。七、六条可行动结论修复 168 个被卡死的配置。把 opt-out 翻转之前写入的持久化sponsors.enabled false视为未设置或加载时一次性迁移同时阻止Config::save()把默认值段落回写磁盘——正是它冻结了这个标志。填满空分类或收缩分类列表。14 个空分类意味着绝大多数浏览注定 missAgent 还要多花一次调用去suggest。新增一个没有清单的分类只会让 miss 率更糟每个新空分类 又一个必然零结果的浏览 一次后续suggest。把 payments 扩展到 Agent 发卡之外。商户收款占 payments 需求的 60%目前完全没有对应清单。把 code-review 与 Git 主机访问拆开。大多数 code-review 浏览其实是鉴权/访问类请求一个 GitHub/GitLab 清单就能服务它们而 Greptile 的交互式 onboarding 对 Agent 自助完成设置是硬阻塞。修复生成发现流量的上游功能故障swarm 审查者 spawn 失败与被拦截的websearch占据了 code-review 与 web-data 浏览的很大比例。给 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.mdAgentcard 演示见 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考