将非结构化数据访问转化为具备Schema合约与成本预测的SQL接口，能显著提升AI代理交付的确定性与可控性。
← 第 45 期周报AI OPC / RESEARCH NOTE
创业研究 / 从案例到行动
以SQL与Schema为合约：AI代理公网搜索的严格交付逻辑
Scry不提供自然语言搜索框，而是向AI代理暴露SQL接口与实时Schema。通过查询计划预测成本、拥堵定价控制算力，它为专业服务者展示了如何将不可控的公网信息转化为可计量、可编程的交付物。
收藏研究
01
先读结论
编辑判断值得借鉴其将数据访问转化为严格合约（Schema与Explain）的思路，以及通过拥堵定价与使用条款约束算力滥用的机制。不该照搬其重资产索引底层，一人创业应利用此类API在垂直领域做窄门数据服务。
拥堵定价与严格的查询规则（如必须带LIMIT、禁止全表扫描）是防御算力滥用、维持数据服务商业可行性的关键机制。
一人创业应利用现有重资产数据基础设施（如Scry）的API，在应用层做垂直场景的查询策略封装与洞察交付，而非重建底层索引。
02
把事实放在前面
来源陈述以下内容有原文引用支撑；收入与成效如为作者自述，不等于独立审计。
- F01
Scry是面向代理的公网程序化搜索MCP服务器
核对原文 [S1]
search over the public web, for agents. Connect over MCP (preferred). Scry is
- F02
通过HTTP API发送SQL语句执行只读查询，始终需带LIMIT
核对原文 [S1]
read-only statement in Scry SQL, always with LIMIT (start at 20). Synchronous;
- F03
发送x-scry-explain可获取查询计划、索引分析与预测成本而不实际运行
核对原文 [S1]
sql): the response is the plan and index analysis — parts and granules selected
- F04
条款禁止批量分发结果、重建大量语料或构建竞争性数据集产品
核对原文 [S1]
reconstruction of a substantial portion of a corpus, no building a competing
03
这门生意，如何拆开看
分析与假设这一部分将案例转化为可测试的创业假设，不能视为该公司已披露的经营结果。
01
客户与付费理由
目标客户为构建AI应用的开发者与专业服务者。他们面临的具体问题是AI代理无法可靠、结构化地访问实时公网数据以完成复杂任务。Scry通过提供MCP与HTTP接口，将非结构化网页转化为可SQL查询的关系表，直接解决代理数据获取的确定性与可解释性需求，客户损失在于代理幻觉或缺乏实时数据导致的交付失败。
02
收费与成本结构
采用拥堵定价与API Key鉴权，按查询消耗的算力（读写的行数、字节、时间）计量。开发者需在Dashboard管理Key与账单。对一人创业者而言，主要成本为API调用费，收费单位是查询复杂度与数据量。这种模式将基础设施成本直接与使用强度挂钩，避免了包月模式下的算力滥用亏损。
03
一人交付工作流
交付步骤严格：1.代理调用schema获取实时数据合约与列名；2.发送explain预测查询成本与命中索引；3.执行SQL查询获取结构化数据；4.按需调用rerank重排。人机分工明确：人负责分配搜索策略（选关系、写谓词），机负责执行、流式返回与本地重排。整个流程无浏览器UI依赖，纯API驱动。
04
首批客户从哪里来
首批客户可通过Show HN等开发者社区触达。产品提供一行命令接入Claude Code或Cursor的极简体验，降低了试用门槛。对于基于Scry做窄服务的一人公司，可通过发布解决特定垂直问题的开源工具或Prompt模板，在开发者社区建立专业信任，从而将用户转化为自身服务的付费客户。
05
竞争与切入空间
核心差异在于将公网搜索转化为关系型数据库查询问题，而非向量相似度检索。提供实时Schema发现与Explain成本预测，使AI代理的调用具备可解释性与可预测性，避免盲目扫描。同时，本地模型重排零成本，以及支持递归CTE与不动点图遍历，提供了传统搜索API不具备的复杂推理数据底座。
06
可积累的长期资产
可积累资产包括：对特定数据源Schema与查询模式的深度理解（如Reddit或HN的高效查询模板）、针对垂直场景的Prompt与工具封装、以及基于Scry构建的领域知识图谱或洞察模型。随着查询增多，一人服务者可沉淀出高价值的数据提取工作流与最佳实践，形成越用越准的领域数据壁垒。
04
先用两周，换一个答案
建议实验先验证最脆弱的假设，再决定是否开发。以下阈值是实验建议，需要结合可触达客户和实际预算调整。
01
第1–3天
注册Scry获取API Key，使用Claude Code或Cursor直连MCP接口，跑通HN或Reddit数据查询示例，熟悉Schema发现与Explain机制。
- 继续信号
- 成功执行3次以上不同关系表的SQL查询，并理解explain返回的成本预测。
- 停止条件
- 若API无法连通或核心查询频繁超时，停止评估。
02
第4–7天
选择一个垂直场景（如特定技术栈的HN舆情监控），编写专用SQL模板与Agent Prompt，封装为可复用的MCP工具或HTTP微服务，验证数据交付质量。
- 继续信号
- Agent能根据自然语言指令，自动调用封装工具输出结构化洞察，且查询成本在预期内。
- 停止条件
- 若查询成本过高或数据质量无法满足具体任务需求，停止封装。
03
第8–14天
将封装的垂直数据服务发布到目标开发者社区，提供免费试用额度，收集反馈并优化查询模板与重排逻辑，探索按查询次数或洞察报告收费模式。
- 继续信号
- 获得至少5个早期用户试用，且能稳定交付无报错结果。
- 停止条件
- 若两周内无开发者试用或无法控制单用户查询成本，暂停推广。
05
最可能错在哪里
反方视角低选择性查询导致全表扫描，引发高昂算力成本与拥堵定价惩罚，超出预算。
如何验证 / 在执行任何新查询模板前，强制先调用explain接口，检查预测的读取字节与时间是否在设定阈值内。
无意中违反Scry的使用条款，如批量导出数据构建竞品语料，导致账号被封。
如何验证 / 审查交付给客户的数据量与存储方式，确保仅提供实时洞察结果而非原始大批量语料导出。
Scry底层索引更新延迟或特定数据源缺失，导致交付给客户的数据存在时间盲区。
如何验证 / 对比Scry查询结果与目标网站直接访问的最新数据，校验observed_on时间戳的延迟程度。
06
来源与研究方法
Show HN: 500 TB internet index in ClickHouse, with congestion pricing ↗
scry.io · 原文日期 2026/9/17 · 读取于 2026/9/21
已核对引用与本次读取的公开原文一致；来源陈述不等于独立审计，商业分析及验证计划为 AI 辅助编辑判断。
由 glm-4.7 辅助分析并保存为研究报告。更正线索可通过编辑反馈提交。
把信息收藏下来，把假设拿出去验证。回到第 45 期周报 →