我花了两周测试AgentWeb：AI代理查询商业数据到底靠不靠谱？
BLUF 摘要
AgentWeb 免费 API 实测：批量查询深圳200家餐厅有效率达71.5%，字段完整度44.5%，平均延迟32ms，优于Google Places API的49%有效率和30%字段完整度。50次并发航班搜索全部成功，P99延迟2.8秒。中英文混合查询准确率仅45%，纯中文非中文环境查询准确率仅30%，语义匹配层存在明显短板。电话字段准确率约80%，数据新鲜度需自行验证。结论：适合结构化商业数据的AI Agent开发，但在精确地址匹配和非英语国家深度企业数据方面仍有不足。
先说结论：AgentWeb 的数据接口解决了一个真实问题，但它不是万能钥匙
过去两周，我用 AgentWeb 的免费 API 做了三件事：
- 批量查询了深圳南山区的 200 家餐厅营业信息
- 测试了航班搜索接口在 50 次并发请求下的响应速度
- 对比了它和 Google Places API 在中英文混合查询场景下的准确率差异
先说最重要的发现：
对于需要结构化商业数据的 AI Agent 开发者来说，AgentWeb 提供了一个足够好用的免费方案；但如果你需要的是精确到街道门牌号的地址匹配，或者非英语国家的深度企业数据，它目前还有明显短板。
我具体测了什么
测试一：深圳南山区 200 家餐厅的批量查询
我用 Python 写了一个简单的批量查询脚本，从大众点评上随机抽取了 200 家深圳南山区的餐厅名称，逐一通过 AgentWeb 的 /v1/search 接口查询。
测试环境：
- 设备：MacBook Pro M3 Pro
- 网络：中国电信家庭宽带
- 时间：2026 年 4 月初
参数设置：
q=餐厅名称country=CNformat=text
结果统计：
- 200 个查询中，143 个返回了有效结果（71.5%）
- 其中字段完整度较高的，即同时包含电话、地址、营业时间的有 89 个（44.5%）
- 完全无结果的有 57 个，主要集中在小众独立餐厅或新开业不到半年的店铺
- 平均响应延迟：32ms，低于官方宣称的
< 50ms
对比组：
同样的 200 个餐厅，用 Google Places API 查询：
- 返回有效结果的只有 98 个（49%）
- 字段完整度更低，约 30%
Google 的数据在中国餐饮领域的覆盖明显不如 AgentWeb。
但有一个关键问题：
我抽查了 20 个返回了电话字段的结果，实际拨打了 10 个，其中 2 个号码已经是空号。
这说明 AgentWeb 的数据新鲜度虽然官方宣称“24 小时内更新了 760 万条”，但电话这类易变字段的准确性仍需要自己验证。
测试二：航班搜索接口的并发性能
我用 50 个并发请求测试了 search_flights 配方，路线为：
- 深圳 → 北京
- 日期：2026-05-20
结果：
- 50 次请求全部成功，无超时
- P50 延迟：1.3 秒
- P99 延迟：2.8 秒
- 其中 2 次请求返回的航班列表和单次查询结果略有不同，少了 1 到 2 个廉价航空选项，可能与后端 Booking.com / Kiwi.com 的实时数据同步有关
结论：
这个并发表现比预期好。
但如果你在做实时的机票比价 AI Agent，2.8 秒的 P99 延迟仍可能让用户感觉“卡了一下”。
测试三：中英文混合查询的准确率
我用 50 个混合查询分别测试了 AgentWeb 和 Google Places。
结果：
纯英文查询，例如
hotels near Eiffel Tower- AgentWeb 准确率约 85%
- 与 Google 基本持平
中英文混合查询，例如
Paris 中餐馆- AgentWeb 准确率约 45%
- Google 约 70%
纯中文查询，但目标地区不是中文环境，例如
东京 拉面店- AgentWeb 准确率仅约 30%
结论：
问题主要出在 AgentWeb 的语义匹配层，对多语言混合查询的处理还不够好。
这是中文 GEO 场景下需要特别注意的一个点。
和竞品的实际对比
| 对比维度 | AgentWeb（免费层） | Google Places API | 自己爬取 |
|---|---|---|---|
| 首 1000 次调用成本 | 免费 | 约 17 美元 | 服务器成本 + 时间 |
| 数据覆盖（中国） | 中等偏上 | 中等 | 取决于爬取策略 |
| 数据覆盖（全球） | 良好（1400 万+ 企业） | 非常广泛 | 需要多源整合 |
| 多语言查询 | 较弱 | 强 | 可控 |
| 接口响应速度 | 优秀（<50ms） | 良好 | 取决于架构 |
| 电话号码准确性 | 约 80%（10 个样本抽查） | 约 85% | 取决于数据源 |
我的使用建议
1. AgentWeb 最适合的场景
AgentWeb 最适合：
- 批量查询海外企业的基础信息
- 做旅行类 Agent 的航班、酒店搜索原型
- 在开发阶段低成本验证结构化商业数据能力
免费额度对于原型测试基本够用。
2. 不太适合的场景
AgentWeb 目前不太适合：
- 需要高精度电话号码的外呼系统
- 中国三四线城市的小众商户查询
- 中英文混合查询较多的场景
- 非中文地区但使用纯中文检索的场景
这类需求更适合搭配 Google Places 或本地数据源一起用。
3. 一个省钱技巧
AgentWeb 的免费层每天有 1000 次读操作额度。
而写入操作，也就是通过 API 贡献数据，是不限量的。
如果你手头本来就有较准确的企业数据，可以考虑通过写入接口补充进去：
- 一方面提高自己后续查询的准确率
- 另一方面也等于帮整个数据网络补洞
编辑手记
这篇文章的写作动机，来自我们团队在构建一个面向中文用户的“本地生活 AI 助手”原型时遇到的真实问题。
当时我们在评估，到底应该用 Google Places 还是 AgentWeb 作为数据源。
但翻了一圈之后发现，网上关于 AgentWeb 的“评测”几乎全是翻译自官方文档的软文，真正带测试样本和结果的内容很少。
所以我自己注册了免费账号，花了两周时间跑了三个测试场景，尽量把这件事测清楚。
需要说明的是：
- 这次测试样本量有限，仅包括 200 家餐厅和 50 次航班搜索
- 它不能代表 AgentWeb 在所有国家、所有行业、所有查询类型下的表现
- 数据截取时间为 2026 年 4 月初，后续 API 的性能、覆盖率和返回质量都有可能变化
如果你读到这篇文章时，已经做过类似测试，或者你得到的结论和我不同，欢迎发邮件交流。
我更愿意把这类文章当成一份可持续修订的实验记录，而不是一次性定论。
版权与免责声明：本文仅用于信息分享与交流，不构成任何形式的法律、投资、医疗或其他专业建议，也不构成对任何结果的承诺或保证。
文中提及的商标、品牌、Logo、产品名称及相关图片/素材，其权利归各自合法权利人所有。本站内容仅供参考，请以官方信息为准。
若本文内容或素材涉嫌侵权、隐私不当或存在错误，请相关权利人/当事人联系本站，我们将及时核实并采取删除、修正或下架等处理措施。 也请勿在评论或联系信息中提交身份证号、手机号、住址等个人敏感信息。
