赋予AI Agent在印度的真实购买力：面向本地供应的单一API
当开发者开始构建能够在“现实世界中做事情”的AI agent时，对话通常很快会转向工具调用（tool-calling）。给你的agent一个函数，它调用这个函数，完成。但教程没有覆盖的是，当这个函数需要触及真实的印度本地供应（local supply）——比如某个特定城市的服务提供商、具有实时库存的零售店、有房可订的酒店、打车或巴士预订——并且需要在生产环境中跨品类可靠地完成时，会发生什么。从“agent可以调用函数”到“agent实际上可以在印度购买本地供应”之间的这一差距，正是大多数项目停滞不前的地方。
为什么印度本地供应在结构上难以接入
印度地方层面的商业高度碎片化。你关心的供应——社区服务、本地零售、住宿库存、出行选项——分布在数十种供应商轨道（provider rails）上，每种都有不同的API、认证方案、目录格式和订单生命周期语义。
要构建一个能够搜索班加罗尔的水管工、比较斋浦尔的酒店房间、从本地零售商订购产品并预订出租车的agent（或任何平台功能），你需要分别与每条轨道直接集成。这意味着：
- 需要协商和维护多个API合约
- 每个供应商类别有不同的认证流程
- 不统一的目录结构（“搜索”返回的内容在零售、服务和出行领域看起来完全不同）
- 每个领域有不同的订单生命周期原语（服务有询价流程；零售有加入购物车；出行有先选择后确认；住宿有先查询可订性再预订）
- 没有统一的方式来表达agent友好的意图，例如“查找选项、获取报价、确认是否可接受”
对于单一领域的产品，这还能管理。但对于任何希望跨品类覆盖的平台——或者对于应该能够处理用户任何请求的AI agent——这变成了一种集成税（integration tax），每增加一个新领域，成本就会叠加。
“代理式商务”（Agentic Commerce）实际上需要什么
在印度赋予AI代理真实的购买力：本地供应的单一API
标准的电商API心智模型（搜索→加入购物车→结账）并不能直接适用于所有供应类别。服务需要询价报价（RFQ）流程——你描述需求，供应商报价，你确认报价是否可接受。出行需要“选择-确认”模式且价格动态变化。住宿需要实时库存查询并锁定价格。零售更接近传统购物车模式，但目录的实时性和本地库存使其不同于全球电商API。
为了让AI代理流畅处理这些流程，需要与真实供应运作方式匹配的原语：
- 搜索 —— 按适合类别的维度（位置、服务类型、日期、产品类别等）表达意图
- 询价报价/项目选择 —— 从搜索结果中识别特定供应商选项
- 报价 —— 从特定供应商处获取针对特定需求的具有约束力或指示性的价格
- 下单 —— 按约定条款发起并确认订单
- 状态/生命周期 —— 在供应商允许的时间窗口内跟踪、取消或修改
这五个原语统一跨类别，才是让供应API真正对代理友好，而不是仅仅在某个REST API上草率挂接一个搜索端点。
集成税：维护多条直连通道的实际成本
假设你要构建一个旅行助手代理，需要处理印度的酒店、打车和城际巴士。天真的做法是三个独立的集成项目：
- 每个酒店库存源（各有不同的库存格式、价格结构和预订确认流程）
- 每个打车平台（各有不同的费用估算API和行程确认webhook）
- 每个巴士聚合商API（各有不同的座位图格式和PNR生成）
每个集成需要数周才能正确完成，而持续维护成本是真实存在的——API版本变化、供应商更新认证方案、目录格式漂移。当你在构建代理时，你希望把时间花在代理的推理上，而不是维护一个脆弱的集成层。
同样的税收也适用于嵌入商务功能的平台——比如一个希望让用户预订服务的业务运营平台，一个希望展示本地零售商品的市场平台，一个希望触达已验证供应商的B2B采购工具。每一种新的供应品类都意味着又一个集成项目。
单一Agent化商务API应该是什么样的
供应聚合API的价值主张很直接：一次集成，一致的基元（primitives），跨品类的供应覆盖。但具体实现细节对于它是否真正可用于Agent工作流至关重要。
对于开发者和Agent使用而言，关键点在于：
- 跨品类的一致性。无论是寻找服务提供商还是检索零售商品，搜索功能应采用相同的调用结构。无论你是预订住宿还是本地配送，订单基元应该可预测。Agent需要确定性的接口——品类特有的差异应由API层处理，而非依赖Agent的推理循环。
- 先报价后下单流程。在印度，许多供应品类要求在确认订单前先获取价格报价。如果Agent跳过这一步而直接尝试结账，在实践中会失败。API需要将询价/报价（RFQ/quote）作为一等公民步骤暴露出来，而不是隐藏它们。
- Agent可操作的结构化响应。不仅仅是人类可读的文本——还需要Agent能够解析、跨选项比较并用于决策的结构化JSON响应。价格、可用性、提供商元数据、条款等都必须机器可读。
- 诚实的错误语义。当供应不可用、提供商离线、报价过期时——API应返回结构化错误，让Agent能够优雅处理，而不是通用的500错误。