迪拜租房搜索消耗AI代理1.7万token

迪拜码头一页一居室房源的JSON，是68,709个字符。按四个字符一个token的常用估算，这就是AI代理上下文窗口里约17,000个token，换来的只是25条房源。如果一个代理要在两个门户上比较三个区域，它还没写出一个字，就已经花掉了约105,600个token。

“给代理接一个MCP服务器”如今是“怎么把大模型连到房产数据”的默认答案。于是有人按MCP的方式接入了三个阿联酋房产API，用一个简单问题调用它们，把模型需要读的东西全部量了一遍。

问题是人们真会问代理的那种：迪拜码头、朱美拉村庄圈和商业湾的一居室租金各是多少？在2026年11月3日，通过Bayut API、Property Finder API和用一个密钥同时服务两个门户的UAE Real Estate API，一共发起了18次调用。每个区域在两个门户上各查一次位置、各跑一页一居室租赁搜索，再拉取Property Finder的租赁成交记录。此外还取了一条完整房源记录，并用UAE Real Estate在迪拜码头对两个门户做了搜索。

这些API的每个端点都能通过RapidAPI网关以MCP方式访问，一个端点对应一个工具。工具返回的就是API的响应，所以测量对象就是响应本身：紧凑JSON的字符数除以四，得到token估算。真实计数取决于模型的tokenizer，但下面的比较依然成立，因为每个数字都经过同样处理。

第一笔成本：还没提问，工具清单先收费

MCP客户端在每一轮都会把每个可调用工具的名称、描述和输入schema发给模型。按网关的做法，从三份公开的OpenAPI文件生成这些定义，一个端点一个工具，每个查询参数都是工具输入schema的一个属性。

Property Finder最贵：端点更多，工具平均约1,327个字符，Bayut是1,049个，其中参数描述占了48.3%。这些描述列出每个过滤器的允许值、默认值和示例。这些细节恰恰是帮模型正确调用工具的东西，所以不该砍掉。它也正是“只加载任务需要的API”的理由。

另一种做法是发现型连接器。开源连接器Free Live Data MCP把48个API藏在四个工具后面（search_apis、search_endpoints、describe_endpoint、call_endpoint），四个定义共2,146个字符，约536个token。模型只在主动索取时才为参数列表付费，代价是每个任务多一两次往返。

第二笔成本：响应本身

在迪拜码头，Bayut一页租赁搜索约17,177个token，Property Finder一页搜索约16,324个。Property Finder的完整房源记录约3,216个token，租赁成交约1,794个，位置查询只要470个。Bayut的位置查询约2,023个，因为它返回了25个候选位置及其完整路径和名称，而Property Finder只返回20个短名称。

三个区域的搜索页大小相当稳定：Bayut在17,098到19,527个token之间，Property Finder在16,324到18,126之间。体积是格式的属性，不是区域的属性。

字符都花在哪了

Bayut一条搜索记录约2,700到3,100个字符，视区域而定。最大的字段是location，占整行的28.3%。它是整棵位置树，从阿联酋到楼栋四到六级，每一级都带多语言名称：name、阿拉伯语的name_l1、中文的name_l2、俄语的name_l3。category又占16.8%，原因相同：两级，每级多语言。而代理只需要每级里的一个词。

Property Finder这边，images占一行的37.8%，是带长版本串的图片URL。location_tree再占9.0%，address占7.2%。

没预料到的是联系人数据。Bayut上，房源代理ownerAgent、phoneNumber和contactName三个字段合计占每行的14.1%；Property Finder的agent_details占14.7%。转发原始行的代理，等于花钱去读它根本用不上的人名和电话，还把这些信息塞进了模型的上下文和日志。裁剪一次，两个问题一起解决。

解法：在模型读之前先裁剪

回答一个租金问题，代理大约需要九个字段。按这个思路裁剪后，实测跑出25行，完整响应68,709个字符（约17,177个token），裁剪后只剩4,907个字符（约1,227个token）。第一条记录是一套带家具的一居室，位于Marina Diamond 4，年租70,000迪拉姆，62.6平方米——回答所需的一切，没有多余的。

三个区域的中位数Bayut页面从约17,177个token降到1,227个，削减92.9%；Property Finder从约17,391降到2,460，削减85.5%，因为裁剪后的行保留了代理展示链接所需的房源URL，而那个URL很长。六个搜索页合计从约105,600个token降到约11,250个。

裁剪在哪一层执行没那么重要，重要的是它执行了。在自己的代理里，就是工具调用前后的几行代码。面对无法控制的网关，就在它前面放一个自己的轻量MCP服务器，调用API并返回裁剪后的行。通用网关无从知道哪些字段对你的任务重要。

数据里踩到的坑

• 美化输出的JSON要多花一半：同样18个响应，两空格缩进后比紧凑形式长52.4%。缩进对人看日志免费，对模型读工具结果很贵。
• Bayut的面积过滤器和面积字段单位不同：area_min和area_max按平方英尺，而一居室行里的area返回62.6这类带十四位小数的值，只能理解为平方米。Property Finder的size会写明单位。把单位写进键名，模型就没法在不知不觉中跨门户比较不同单位。
• 两个门户类型不一致：Bayut的rooms是数字，Property Finder的bedrooms是字符串；Bayut的createdAt是Unix秒级时间戳，Property Finder的listed_date是ISO字符串。在裁剪时统一一次，比指望模型自己应付更便宜。
• 部分Property Finder搜索行根本没有租金：三次租赁搜索的113行里有14行不带price.value，它们是混进结果的新项目卡片，其中12行带的是销售起价。在模型看到页面前丢掉它们，否则它可能把一百万迪拉姆的售价读成租金。
• 位置ID属于单一门户：迪拜码头在Bayut是5003，在Property Finder是50。跨门户复用ID不会报错，只会拿到错误的区域。
• Bayut搜索行没有描述：拉取的75行里description都是空值，想要房源文本就得取完整记录，token成本再上一层。回答租金问题并不需要它。

接下来怎么做

单门户代理，一个API的工具加搜索结果裁剪就够了：工具约4,500到6,000个token，每个裁剪后的搜索页约1,200到2,600个token。需要在多个来源间挑选的代理，发现型连接器把固定成本压在500个token附近。

用到的三个API分别是Bayut API（RapidAPI上有免费套餐）、Property Finder API和UAE Real Estate API，后者还提供Postman集合，方便在写代码前先试调用。两个门户各有自己的站点和代理接入说明。