企业官网建设流程全解析

结构化检索 API 的边界在哪？在「用户说不清参数」的那一刻。「浙江一带做注塑模具、最好有出口经验的厂」——这句话里有地域（还是模糊地域）、有品类、有一个很难落成字段的条件。传统做法是前端堆一堆筛选器逼用户自己翻译，另一条路是把翻译这件事交给服务端的 AI。这篇拆一个走后一条路的实际接口：天下工厂开放平台的factory_agent_search。

背景一句话：天下工厂是覆盖全国 480 万家工厂的数据库，收录前做了工厂身份识别（真实从事生产的工厂才进库，贸易商与空壳类主体排除），开放平台以 MCP 与 REST 双通道提供能力，文档在 https://www.tianxiagongchang.com/open/docs。

接口形状

REST 调用：

curl-shttps://open.tianxiagongchang.com/open/v1/capabilities/factory_agent_search\-H"Authorization: Bearer$TIANXIA_API_KEY"\-H"Content-Type: application/json"\-d'{"query":"浙江一带做注塑模具、有出口经验的厂"}'

入参就两个字段：query（必填，一句话，中文效果最好）和conversation_id（选填，下文细说）。没有别的参数——这个接口的全部设计哲学就是「把翻译工作收进服务端」。

返回是一份经过核实的工厂名单，外加本轮的conversation_id。单次执行 30 到 90 秒：服务端的代理要解析意图、规划筛选、执行检索、对候选做核实，这个耗时是真实工作量，不是网络慢。客户端超时要设到 180 秒以上，默认 10 秒超时会把正常执行掐断。

conversation_id：多轮收窄

这是这个接口最值得说的设计。第一轮拿到名单后，把响应里的conversation_id带上再发第二句：

{"query":"只要成立十年以上、规模大一点的","conversation_id":"上一轮返回的值"}

代理会在上一轮的语境里理解这句话——「成立十年以上」叠加到已有条件上，而不是从头开始一次新检索。对话式收窄的体验就出来了：先粗后细，两三轮把名单磨到能用。

对开发者来说，这意味着你可以在自己的产品里用极小的前端成本实现「对话式选供应商」：一个输入框，一个列表，conversation_id存在会话状态里，没了。筛选器、级联下拉、行业树选择器，全都不用做。

和结构化检索怎么分工

平台同时提供factory_search（关键词 + 省市区县 + 行业码的结构化检索）。两者的分工判据很简单：

• 条件能写成参数：用factory_search。快（普通限流每分钟 300 次），便宜，结果可完全复现。
• 条件还是一句话：用factory_agent_search。慢（与深挖能力共享每分钟 6 次的慢速限流），单价也不同，但省掉了「把话翻译成参数」的全部工程。

一个务实的混合架构是：产品首页给一句话入口走代理，代理返回的名单页上再给结构化筛选器走factory_search微调——两个接口入参出参都在同一套统一响应格式里，items里的公司id通用，混用没有任何缝。

试起来

控制台注册即送体验额度：https://www.tianxiagongchang.com/open/console。想先看看返回长什么样，公开沙箱密钥sk-tx-test-1685549fb3710c1b36e4d75dc2d0f42a可以直接用（返回示例数据，不计费）。计费按量，单次以角计价，每个响应带扣费回执。

「自然语言进、核实过的名单出」这个形态，我判断会是数据类 API 的标准配置之一——毕竟调用方越来越多不是人，是另一个 Agent。而 Agent 之间传一句话，永远比传二十个参数稳。