搜索只负责找到餐厅
AI 代理订餐的关键，是把“大家同意吃饭”推进到“预订确实存在”。
按 RSS 原始摘要，Zest 的 AI concierge 能汇总口味，让餐厅选项进入投票，再完成预约。链路包含候选生成、共同决策和交易提交。
例如4人选中一家餐厅，却没有预订编号，任务仍停在口头约定。
我最初把难点放在对话上。模型会追问预算、距离和忌口，已经像样。看到这段描述后，我更在意投票后谁有权确认，代理能替谁操作。
候选和偏好可以交给模型，提交前要逐项校验约束，提交后要留存凭据。完整代理要对谁吃、何时吃、替谁下单和结果是否生效负责。缺少后两步，推荐只是建议清单。
即使经过3轮聊天，代理能整理出“6人、晚餐、不吃辣”，没有身份确认与回执，交易仍未完成。
授权边界决定闭环能否成立
一笔预订可以执行，授权必须跟着订单落地。
我会把链路拆成5个检查点：锁定时间与人数，确认餐厅可订，校验发起人身份，展示最终条款，明确确认后提交。
代理负责整理候选和草案，写操作受权限控制。代理的自主权应停在提交前，提交动作必须绑定明确的授权范围。
用户只说“订周五晚上”，代理擅自补人数并提交，就是越权；补全信息可以，替人承诺需要边界。
授权应包含参与者、餐厅、时间、人数和金额范围。多人场景还要记录谁参与选择、谁批准预订。确认页应展示即将提交的完整内容。
提交后应返回预订编号、可取消状态和联系人。餐厅满位、支付失败或超时，都要有重试、换候选或人工接管路径。日志要能回答谁提出需求、依据什么提交。
预订编号证明交易存在，取消入口证明代理承担售后。两者缺一，闭环都会断。
独立开发者应从垂直交易链路切入
独立开发者的机会在垂直预约链路，通用搜索界面很难形成稳定价值。
我在《0. 低代码》里讨论过数据编排和平台连接。这次订餐问题更靠近执行：工具解决“能否连起来”，交易组件解决“获准做什么”。
可拆的产品包括偏好收集、候选投票、可用性查询、授权确认、预订回执和取消。聚餐、庆生、团队活动都有固定字段与规则，适合做成可复用组件。
同一流程里，5人聚餐和2人晚餐应共享规则，却需要不同确认页；把人数写死，产品很快失去可信度。
开发者无需重建通用模型。接好服务接口，标准化时间、人数和忌口，再给高风险动作加入确认，就能交付可控流程。收入可围绕成功预约或连接器维护展开。可复用的资产是授权策略、状态机和异常处理，模型只是其中一层。
模型今天能列出3家餐厅，明天也可能直接下单；开发者要守住的，是客户能否理解并控制交易。
我还没想清楚基础代理也能订餐后，独立产品靠什么赢得信任。答案可能在更窄的场景、更清楚的授权，或更可靠的取消流程里。