当一群人无法就“去哪吃”达成一致时，Zest 的 AI 礼宾代理试图用短信把这件事从头到尾办完：收集口味、给出候选、组织投票、最后下单订位。
发生了什么
据 TechCrunch 报道，Zest 上线了一款 AI agent，定位是餐饮场景的“礼宾”。用户通过短信与它交互，它可以把同行者的口味偏好合并考虑，列出餐厅选项供大家投票，并在结果确定后完成预订。换句话说，它把“提议—协商—决策—执行”这条原本散落在群聊、点评 App 和订位电话里的链路，收进了一个对话式代理中。
为什么重要
订餐看起来是小事，却是 agent 产品少见的“真需求”：它有明确的多方协调成本，有可验证的结果（订上了没有），也天然发生在消息界面里。过去一年，大量 AI 助手停留在问答和生成层面，真正能替用户“办事”的产品并不多，因为办事意味着要对接外部系统、处理不确定性和失败重试。Zest 选择短信作为入口，绕开了 App 下载与学习成本，也把交互压到最低摩擦——用户不需要打开任何新界面，只需要像跟朋友发消息一样说话。
从竞争格局看，这一方向与大型平台的能力存在重叠：地图与点评类应用掌握餐厅数据与预订链路，通用助手则在争夺“默认入口”。创业公司切入的机会，往往不在于模型更强，而在于把某个具体场景的流程打磨得更顺，尤其是多人决策这类平台产品容易忽视的细节。
影响与看点
对用户而言，价值取决于两点：一是偏好汇总是否真的减少了来回拉扯，二是预订成功率与异常处理是否可靠——餐厅满位、时间变更、临时加人，这些才是体验的分水岭。对开发者，Zest 提示了一条务实的产品路径：不做全能助手，而是选一个高频、有明确终点的任务，把对话、协调与外部动作串成闭环。
值得关注的还有商业模式与入口归属。短信渠道降低了获客门槛，但也限制了富交互；一旦用户规模起来，是否会被平台级助手以系统能力覆盖，是这类产品长期要回答的问题。我的判断是：餐饮预订本身不足以构成护城河，真正的壁垒在于多人协调的决策数据与商家侧的履约网络，谁先把这两端跑通，谁才可能把“帮你订餐”变成习惯。
