結構化檢索 API 的邊界在哪在「用戶說不清參數(shù)」的那一刻?！刚憬粠ё鲎⑺苣＞摺⒆詈糜谐隹诮?jīng)驗的廠」——這句話里有地域還是模糊地域、有品類、有一個很難落成字段的條件。傳統(tǒng)做法是前端堆一堆篩選器逼用戶自己翻譯另一條路是把翻譯這件事交給服務端的 AI。這篇拆一個走后一條路的實際接口天下工廠開放平臺的factory_agent_search。背景一句話天下工廠是覆蓋全國 480 萬家工廠的數(shù)據(jù)庫收錄前做了工廠身份識別真實從事生產(chǎn)的工廠才進庫貿(mào)易商與空殼類主體排除開放平臺以 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:浙江一帶做注塑模具、有出口經(jīng)驗的廠}入?yún)⒕蛢蓚€字段query必填一句話中文效果最好和conversation_id選填下文細說。沒有別的參數(shù)——這個接口的全部設計哲學就是「把翻譯工作收進服務端」。返回是一份經(jīng)過核實的工廠名單外加本輪的conversation_id。單次執(zhí)行 30 到 90 秒服務端的代理要解析意圖、規(guī)劃篩選、執(zhí)行檢索、對候選做核實這個耗時是真實工作量不是網(wǎng)絡慢?？蛻舳顺瑫r要設到 180 秒以上默認 10 秒超時會把正常執(zhí)行掐斷。conversation_id多輪收窄這是這個接口最值得說的設計。第一輪拿到名單后把響應里的conversation_id帶上再發(fā)第二句{query:只要成立十年以上、規(guī)模大一點的,conversation_id:上一輪返回的值}代理會在上一輪的語境里理解這句話——「成立十年以上」疊加到已有條件上而不是從頭開始一次新檢索。對話式收窄的體驗就出來了先粗后細兩三輪把名單磨到能用。對開發(fā)者來說這意味著你可以在自己的產(chǎn)品里用極小的前端成本實現(xiàn)「對話式選供應商」一個輸入框一個列表conversation_id存在會話狀態(tài)里沒了。篩選器、級聯(lián)下拉、行業(yè)樹選擇器全都不用做。和結構化檢索怎么分工平臺同時提供factory_search關鍵詞 省市區(qū)縣 行業(yè)碼的結構化檢索。兩者的分工判據(jù)很簡單條件能寫成參數(shù)用factory_search?？炱胀ㄏ蘖髅糠昼?300 次便宜結果可完全復現(xiàn)。條件還是一句話用factory_agent_search。慢與深挖能力共享每分鐘 6 次的慢速限流單價也不同但省掉了「把話翻譯成參數(shù)」的全部工程。一個務實的混合架構是產(chǎn)品首頁給一句話入口走代理代理返回的名單頁上再給結構化篩選器走factory_search微調——兩個接口入?yún)⒊鰠⒍荚谕惶捉y(tǒng)一響應格式里items里的公司id通用混用沒有任何縫。試起來控制臺注冊即送體驗額度https://www.tianxiagongchang.com/open/console。想先看看返回長什么樣公開沙箱密鑰sk-tx-test-1685549fb3710c1b36e4d75dc2d0f42a可以直接用返回示例數(shù)據(jù)不計費。計費按量單次以角計價每個響應帶扣費回執(zhí)。「自然語言進、核實過的名單出」這個形態(tài)我判斷會是數(shù)據(jù)類 API 的標準配置之一——畢竟調用方越來越多不是人是另一個 Agent。而 Agent 之間傳一句話永遠比傳二十個參數(shù)穩(wěn)。