多智能体+MCP：酒店团队预订AI方案实战

酒店团队预订长期困在邮件往返和手工报价里。一个婚礼或会议的房间询价，往往需要销售协调员反复确认库存、核算价格、起草合同，耗时数小时甚至一天。AI/MCP Agent™ 平台发布的团队预订案例展示了一条新路径：用两个各司其职的智能体，通过 MCP 协议接入酒店管理系统，把询价到提案的流程压缩到秒级。

两个智能体，两种分工思路

这个方案最值得琢磨的地方，是它没有把所有任务塞给一个"全能智能体"。

第一个角色是集团运营智能体，它的职责是算账。通过 MCP（一种为智能体提供真实工具调用的开放标准）连接酒店 PMS 系统后，它被授权使用三个工具：查询可用房、预订房间、以及核算团队总价。接到询价后，它负责解析房型、房间数量和入住需求，确认库存真实存在，然后返回一个具体的团队报价总额。据视频演示，该智能体面对"15 间大床房、两晚、企业团建"的询价，能直接调取 PMS 数据确认可用性并给出真实价格。

第二个角色是收益与合同智能体，它的特点恰恰相反——它没有任何工具。运营智能体完成定价后，这个专家接手，基于传入的具体数字进行推理，复述房间块信息，附加标准条款（押金、截止日期、取消政策），组装出一份可直接发送的提案。它的指令明确要求"只用交给它的费率，绝不编造新数字"。

这种"一个有工具、一个纯推理"的搭配，打破了"智能体必须接工具才有价值"的惯性思维。有些环节的核心能力就是谨慎的组装和判断，而非外部调用。

MCP（Model Context Protocol） 是由 Anthropic 于 2024 年底提出的开放协议，旨在为大型语言模型和智能体提供一种标准化的方式来调用外部工具和数据源。在此之前，智能体接入不同系统（如数据库、CRM、日历）往往需要为每个系统单独编写适配代码，接口风格各异、维护成本高。MCP 相当于为"智能体调用工具"这件事定义了统一的插头和数据格式：工具提供方只需实现一次 MCP 服务端，任何支持 MCP 的智能体都能直接使用。这也解释了为什么文中同一套双智能体流程能够同时接入酒店 PMS 和基于 SIP 的电话服务商——两者只要各自暴露 MCP 接口，智能体端无需改动。

PMS（Property Management System，酒店物业管理系统） 是酒店日常运营的核心软件，管理着房态库存、房价、预订、入住退房、账务等关键数据。酒店前台看到的"这间房今晚是否可订"、销售拿到的"团队协议价"，本质上都来自 PMS。因此当智能体要回答"15 间大床房两晚是否可订、总价多少"时，它必须实时查询 PMS，而不是依赖训练时记忆的静态知识——这正是 MCP 工具调用存在的意义。

结构化交接：多智能体协作的关键约束

多智能体系统的经典难题是：智能体之间如何传递信息而不失真？

该平台用一个叫"多智能体流程设计器"的可视化画布来编排。流程从左到右：接收询价 → 运营智能体定价 → 合同智能体起草 → 完成。每个方框对应一个智能体，调色板中提供条件分支和并行再汇合等积木块，整个过程零代码。

真正让两个智能体咬合的是结构化输出的契约机制。运营智能体产出一个结构化的"房间块定价"对象，合同智能体声明同一结构作为输入。运营智能体确认房间并打包好费率和总价，合同智能体接收的恰好是这些数字——提案永远与实际报价一致，不会出现报价 8000 元、合同写 10000 元的情况。

平台自动完成从一个专家到下一个专家的传递。每次运行后，聊天历史面板还会显示整次运行的精确成本，方便在测试阶段监控花费。

结构化输出（Structured Output） 指让模型不返回自由文本，而是返回严格符合预定义 schema（如 JSON）的数据对象。在多智能体协作中，这相当于给下游智能体一份带有固定字段的"接口契约"：上游智能体只能填写约定好的字段（例如 room_type、room_count、nightly_rate、total_price），下游智能体也只读取这些字段。相比让智能体用自然语言互相"对话"，结构化交接能显著减少信息在传递中被改写、遗漏或凭空补充的风险。文中"报价 8000 元、合同却写 10000 元"的失真场景，正是无契约交接时最容易出现的问题。

智能体编排（Agent Orchestration） 是把多个智能体按顺序、分支或并行关系组织起来协同完成任务的工程实践。可视化编排器（文中提到的"多智能体流程设计器"）让开发者用拖拽方框和连线的方式定义流程，底层自动处理上下文传递、错误重试和状态管理。对于只涉及两三个角色的线性流程，编排器的价值在于降低工程门槛——无需编写调度代码，就能把"询价→定价→起草"这条链路稳定跑通。

三种落地渠道：网站、坐席辅助与电话

流程测试通过后，保存即发布为一个智能体代码，整个双智能体团队可以投放到客户策划活动的任何场景。据视频介绍，方案支持三种交付方式。

网站嵌入式聊天组件是最直接的一种。会议策划人在酒店官网的聊天框里描述需求——比如"15 间大床房住两晚"——运营智能体确认房间并定价，合同智能体起草提案，策划人当场拿到真实团队价格和可审阅的提案，不必等一天才收到邮件回复。

**坐席辅助（Chat Assist）**面向酒店内部销售协调员。协调员在与策划人对话时，把需求交给 AI 助手，后者运行同一套双智能体流程，准备好回复草稿。协调员审核后加上个性化的温度再发送。智能体负责定价和文书，人负责建立关系、赢得订单。

电话渠道则利用了 MCP 智能体的标准化特性。同一套运营和合同团队可以接入基于 SIP 标准的电话服务商，接听真实来电。策划人直接打电话描述团队需求，通过语音获得可用性、团队价格和提案。电话设置面板管理号码、通话记录和诊断信息。

一套团队，覆盖网站、在线聊天和电话三个入口。

SIP（Session Initiation Protocol，会话发起协议） 是互联网电话领域最通用的信令标准，负责建立、修改和终止语音与视频通话。绝大多数云呼叫中心和 IP 电话服务商都基于 SIP 提供接口。当智能体平台能够通过 MCP 接入 SIP 服务商时，就意味着同一套推理逻辑可以从文字聊天无缝扩展到实时语音场景：来电号码、通话状态、语音转文字与回复合成，都能通过标准协议对接，而不必为电话渠道重写一套智能体。这也是"一套团队覆盖三个入口"在工程上可行的关键。

这个案例的真正启示

抛开酒店行业本身，这个案例对智能体系统设计有几个可迁移的判断。

工具不是越多越好。 运营智能体需要精准的工具调用能力，合同智能体需要零工具的纯粹推理能力。把两者混在一个智能体里，反而可能导致"既能查库存又能编条款"的模糊边界，增加幻觉风险。

结构化交接比自然语言传递更可靠。 智能体之间的接口用数据结构定义——输出方声明产出什么，输入方声明接收什么——比让它们自由对话要稳定得多。

多智能体不必复杂。 两个智能体、一条线性流程，就能覆盖一个真实业务场景。平台提供的分支和并行能力是可选复杂度，不是入门门槛。

智能体系统正从"单兵作战"走向"团队协作"。这个酒店团队预订的案例说明，团队的关键不在于人多，而在于每个角色边界清晰、交接可靠。

背景补充

坐席辅助（Agent Assist） 是一种介于"全自动"与"纯人工"之间的中间形态：AI 不直接面向终端客户，而是在销售或客服人员身旁生成建议回复、摘要或下一步动作，由人审核后再发出。这种模式在酒店、保险、电信等高价值、需要人情味的场景中尤为常见——AI 承担重复性的定价核算和文书起草，人保留最后的判断权和关系维护。它既规避了全自动客服在复杂谈判中的可靠性风险，又能把人工处理单条询价的时间大幅压缩。