结构化检索 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\-HAuthorization: Bearer$TIANXIA_API_KEY\-HContent-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 之间传一句话永远比传二十个参数稳。
