【开发者来信栏目导语】 本栏目为旅行Agent开发者生态共建专栏，定期收录一线酒旅开发者、渠道运维、Agent 搭建者的落地开发日志、对接复盘、功能适配笔记。内容仅做技术交流、行业开源参考，所有组件能力、接口能力，仅为开发者对接使用。

先看效果

内部范围商旅服务验证：5-15 人 小公司搭一个「老板不在也能跑」的差旅自动化。
第 3 周跑通时，老板出差在外，商务群里扔了一句「我 26 号去上海，要住外滩附近一晚」。1 分钟内群机器人推了一张卡片：

┌──────────────────────────────────────────┐
│ 🏨 丽呈美丽居酒店（上海城市中心外滩店） │
│ 📅 7/26 - 7/27 · 行政大床房 · 单早 │
│ 💰 ¥490/晚（平台协议价，原价 ¥584） │
│ ✅ 免费取消截止 7/25 18:00 │
│ 👤 预订人：商务部
│ 🔗 [一键批准] [查看详情] [改选同价位] │
└──────────────────────────────────────────┘

老板在高铁上点了「一键批准」，卡片自动同步到了飞书审批流，2 小时后订单回执推回群。月底对账时导出一张 Excel，自动按项目分摊——技术成本归到「产品研发」，销售拜访归到「客户拓展」。

图 2 是一张飞书审批面板（同样是 ASCII 还原）：

┌──────────────────────────────────────────────────────┐
│ 📋 差旅申请 编号 TR-2026-07-001 │
├──────────────────────────────────────────────────────┤
│ 申请人 XX（销售部） │
│ 出差日期 7/26 - 7/27（1 晚） │
│ 出差目的 上海客户拜访 │
│ 关联项目 华东区客户拓展 Q3 │
│ 预算 ¥ 600 / 晚 │
│ 选中酒店 丽呈美丽居酒店（行政大床房） │
│ 协议价 ¥490 / 晚（节省 ¥240） │
│ 取消政策 7/25 18:00 前免费 │
│ 审批人 老板 / 财务（自动路由） │
│ 订单状态 已批准 · 待出票 │
└──────────────────────────────────────────────────────┘

1. 写在前面

我们公司是 5-15 人量级——做 ToB 工具 + 内容 + 一点咨询服务。整个公司没差旅主管、没财务共享中心。老板就是我，我一个人兼销售、运营、产品、财务。3 个员工经常出差：销售去客户现场，运营去见合作伙伴，我去谈合作方。

差旅这件事在 2025 年之前是这样运转的：
触发：员工主动打开平台；
形态：登录 → 搜索 → 选。

而现在：
触发：群机器人听到关键词主动推；
形态：飞书群 → 关键词 → 候选卡片。

2026 年 3 月，我决定自己动手做这件事——给公司搭一个内部商旅服务。目标 3 个：

1. 统一平台：3 个员工 1 个入口，1 套价格基准
2. 按项目分摊：差旅费自动归到对应项目，不月底手工算
3. 老板不在也能跑：员工出差申请不用等老板微信秒回

听起来很简单，对吧？但你试着做的时候会发现，OPC 公司做这件事跟大公司完全不一样——

• 大公司 1000 人以上，可以谈 B2B 协议价（10-20 万/年起步价）
• OPC 公司 10 人以下，没议价权——任何供应商看到你的体量都懒得理你
• 大公司有 IT 部门搭系统，OPC 公司老板自己可能就是 IT
• 大公司审批流走 OA，OPC 公司老板在高铁上只能用手机批

所以 OPC 公司需要的不是「企业级商旅平台」，是「老板不在也能跑」的轻量服务。

这次跑通用的是一款完全开源的酒店 MCP 工具——RollingGo Hotel MCP，致力于为所有 AI Agent 开发者提供开箱即用的实时酒店数据能力。

如果这个项目对你的开发有帮助，欢迎前往 GitHub 点亮一颗 Star ⭐。你的支持是这个开源项目持续迭代数据覆盖、优化接入体验、共建旅行 AI 开放生态的核心动力。
项目仓库：GitHub | https://github.com/RollingGo-AI/rollinggo-hotel-skill

2. 选型过程

不点名具体竞品做横向打分——OPC 公司选型跟大公司不一样，我用的是「硬性条件筛选法」。

我自己定的 3 条硬性条件：

• 条件 1：必须能嵌入 OPC 公司已经在用的钉钉/飞书（员工不想装新 APP，这是我第一个砍掉的选项——需要员工下载独立 APP 的全部不要）
• 条件 2：必须支持「按员工部门 / 项目」打标签分类（差旅费要按项目分摊，不能事后 Excel 处理——Excel 处理是 0.5 人/天/月的根源）
• 条件 3：必须能「以小搏大」——5-15 人小公司也要能拿到某种形式的协议价（哪怕只是平台通用协议价，5-15 人没有议价权，必须靠 MCP 这种聚合方案拿到平台层协议价）

凡是要企业资质 + 流水抽佣的组件，直接放弃——5-15 人 OPC 没有「企业资质」概念，年营收过了 100 万才有 HR 愿意帮你办。

凡是要员工下载独立 APP 的组件，直接放弃——5-15 人小公司推 APP 比登天还难。

按这 3 条筛下来，完全满足的方案凤毛麟角。最终留下来的是酒店 MCP 形式——它满足条件 1（嵌入飞书/钉钉群机器人就行）、条件 2（标签分类是接口层的，不是 BI 层）、条件 3（聚合多家平台协议价，不强求 OPC 自己谈）。

注：选型过程中我主动放弃了 3 个常见选项——不点名具体厂家，避免引发争议。放弃的共同原因是：5-15 人 OPC 没有企业资质、没 IT、推不动 APP。这 3 个条件里任何 1 个不满足，整个方案就废了。

3. 接口能力深度拆解

酒店 MCP 的接口能力我数了一下，主要由 3 大功能组成。下面逐个拆。

3.1 酒店搜索

最常用的接口，调用频率占80%。

参数	含义	我常用的值
place	目的地	城市名或地标名（上海外滩）
checkInDate / checkOutDate	入住 / 离店	YYYY-MM-DD
adultCount	成人数量	1（销售经常一个人出差）
budget	预算上限	600-800 元/晚（打工人差旅）
starRatings	星级范围	3.0,5.0（不限最高星）
preferredTags	偏好标签	商务 / 早餐 / 健身房
requiredTags	必备标签	免费取消

调用一次接口，返回 5-15 家候选酒店的结构化数据。我实测下来响应时间稳定在 1.5-2.5 秒——比销售自己刷平台快得多（这些平台要加载图片 + 各种广告，人要 30 秒才能比较 3 家）。

3.2 酒店详情

销售选中一家之后调用这个接口，看具体房型 + 价格 + 取消政策。

字段	含义	关键性
roomName	房型名（高级大床房）	决定房型是否匹配
currentPrice	实时价格	决定是否还在预算内
cancellationPolicy	取消政策	OPC 内部商旅最关键字段——5-15 人没有议价权，靠免费取消政策做兜底
breakfastIncluded	是否含早	销售出差对含早很敏感
bookingUrl	预订链接	给员工跳转用

我专门看了一下 cancellationPolicy 这个字段——它是字符串嵌套 JSON，解析要小心。3.4 链路里我会单独说这个坑。

3.3 酒店标签

OPC 公司差旅跟个人差旅最大的区别是「标签标准化」——销售要「商务 + 早餐 + 健身房」，运营要「亲子 + 套房 + 早餐」，我（老板）要「安静 + 商务 + 健身房」。

标签族	常用值
设施	商务中心 / 健身房 / 游泳池 / SPA / 停车场
餐饮	含早 / 含晚餐 / 客房送餐 / 酒吧
房间	套房 / 家庭房 / 无烟房 / 连通房
服务	免费取消 / 24h 入住 / 机场接送 / 外币兑换
亲子	婴儿床 / 儿童乐园 / 家庭友好

调用这个接口先确认标签字典——OPC 公司的差旅助手必须在已知标签里筛，不能靠大模型硬猜。

3.4 跟单链路

完整链路是「搜索 → 详情 → 监控 → 提醒」四步：

步骤	接口	触发
1. 搜索候选	searchHotels	员工在群里说「我要去 XX 出差」
2. 选房型 + 价格	getHotelDetail	群机器人推送 5-10 家候选
3. 价格监控	rollinggo-hotel-price-monitor	员工点了「先帮我盯着」
4. 降价提醒	推送	监控任务触发阈值

第 3 步是这个 POC 真正的关键——5-15 人 OPC 没议价权，没法谈协议价，唯一能做的就是「等降价」。监控任务让员工出差前 3 天开始盯，比直接订便宜 8-15% 是常态（按我实测的 11 次监控数据）。

3.5 跨平台价格对比

OPC 公司差旅第三个隐藏价值是「跨平台价格可见」。员工订酒店时，常常发现同一个酒店在 3 个平台报 3 个价——平台 A ¥1,800、平台 B ¥1,750、平台 C ¥1,720。

平台	标价	MCP 聚合后建议价
平台 A	¥1,800	—
平台 B	¥1,750	—
平台 C	¥1,720	¥1,580（平台通用协议价）
员工原始选择	平台 A ¥1,800	—
改用 MCP 建议	—	¥1,580（省 ¥220）

单次节省 ¥220，3 个员工 1 年出差 20 次 = ¥4,400——这个数看起来不大，但它是「零成本」省下的（员工只是改了选平台的习惯）。

3.6 历史价对比

酒店 MCP 的另一个能力是「历史价对比」——同一酒店在 30 天内的价格曲线。我让 AI 助手在出差前 7 天先查一次价格，等价格跌到 30 天均价的 85% 以下再订。

时点	价格	相对 30 天均价
30 天前	¥1,650	-3%
14 天前	¥1,720	+1%
7 天前	¥1,800	+6%
3 天前	¥1,580	-7%（达标）
今天	¥1,610	-5%

按这个策略订，11 次监控数据平均省 12%——比单纯「找最便宜」高效 3-5 倍。

4. 部署全流程

整个 POC 用了 3 周，3 周的里程碑大概是这样：

周次	目标	关键产出
第 1 周	跑通「搜索 → 详情」两步	飞书群机器人能推酒店卡片
第 2 周	联调「监控 → 提醒」两步	降价后自动推送到群
第 3 周	接入审批流	飞书审批面板 + 项目分摊 Excel

第 1 周：基础接入

第 1 步是官方申请，0 等待，填好信息直接拿到专属 Key.

第 2 步是飞书/钉钉机器人配置。飞书这边是建一个「商旅小助手」群机器人，配置一个 webhook；钉钉那边是建一个「商旅」群机器人，配置一个 access_token。两个群都要加销售、运营、老板（我）3 个人。

第 3 步是接入酒店搜索接口。我让 AI 落地助手在群里「听到」出差关键词就触发——比如「我要去上海出差」、「帮我订明天深圳的酒店」。

第 2 周：联调监控 + 降价提醒

第 1 步是单独起一个定时任务（用现有 heartbeat 机制），每 4 小时跑一次「我关注的酒店」列表的价格。

第 2 步是设置降价阈值——OPC 公司的阈值建议：

场景	阈值
销售出差	比当前价降 10% 提醒（销售对价格敏感度高）
运营出差	比当前价降 15% 提醒（运营愿意等）
老板出差	比当前价降 5% 提醒（老板时间更贵）

第 3 步是推送渠道——降价后推到群里 + 私聊提醒员工。

第 3 周：审批流 + 项目分摊

第 1 步是飞书审批面板——员工在群里点「一键批准」时，自动生成一张审批单，推送到飞书审批流。

第 2 步是项目分摊——员工在群里申报出差时必须填「关联项目」字段。这个字段是 OPC 公司差旅管理的核心——没这个字段，月底对账又回到 Excel。

第 3 步是月底一键对账——月底最后一天自动跑一个脚本，把所有出差记录按项目分摊，导出 Excel 直接给财务（我）。

第 4-6 周具体时间分配表：

时段	周一	周二	周三	周四	周五	周末
第 1 周	注册 + 机器人配置	接入搜索接口	接入详情接口	联调群机器人	老板自测	—
第 2 周	接入监控任务	配置降价阈值	联调提醒推送	联调心跳	自测 11 次	—
第 3 周	飞书审批面板	项目分摊字段	月底 Excel 导出	老板自测	跑通 1 次真实出差	复盘

注：所有 Agent / Skill / MCP 接入都通过飞书群机器人 + 现有 heartbeat 机制完成，没有写任何代码——这是 OPC 公司的天然优势：员工都在飞书群里，机器人也在飞书群里，整个差旅流在飞书里闭环。

5. 踩坑全记录

3 周 POC 踩了 5 个明显的坑，前 4 个是技术坑，第 5 个是 OPC 公司特有的商业坑。

5.1 API Key 多了一个空格

维度	描述
现象	接入后第一次调用接口，返回 401 Unauthorized
原因	复制 API Key 时末尾多了一个空格
解决	重新复制粘贴，粘贴到文本编辑器先看一遍再配置

这个坑看似低级，但 OPC 公司的痛点在这里放大——大公司有 IT 帮你 debug，OPC 公司老板自己 debug，老板不在公司的时候整个服务直接挂。

为什么 OPC 公司更容易踩这个坑？ 因为 OPC 公司的 API Key 通常是老板自己一个人配置，没走 IT 流程，没代码 review，没「双人确认」机制。所以 OPC 公司配置任何密钥类东西，都必须养成立刻在文本编辑器里看一遍的习惯。

5.2 type 写错

维度	描述
现象	Cursor / Cline 接入时报 type not supported
原因	配置文件里 type 字段写了 http（小写）
解决	改成 streamable-http（MCP 协议规范要求）

这里要强调一下：MCP 协议规范要求必须写 streamable-http，不是 http，不是 sse。我看过网上有些教程写 http，那是错的——照着配必报错。

为什么 OPC 公司更容易踩这个坑？ 因为 OPC 公司的开发者（往往是老板本人）不是专职 Agent 工程师，配 MCP 客户端时容易把 MCP 协议规范和 HTTP 协议规范混——HTTP 协议是 http 没错，但 MCP 协议不是 http。这个区别对专职工程师是常识，对 OPC 老板是踩坑。

5.3 hotelId 跨天失效

维度	描述
现象	监控任务第 2 天再调用详情接口，返回 hotel not found
原因	酒店 MCP 的 hotelId 跟日期是绑定的——7/26 的 hotelId 7/27 调就不认识
解决	监控任务里先重新 searchHotels 拿当天 hotelId，再调详情

这是酒旅接口的通病，不是这个 MCP 独有的——很多 OTA 的酒店 ID 都是日期相关的。OPC 公司做监控任务时必须把「重新搜一次」写进流程。

为什么 OPC 公司更容易踩这个坑？ 因为 OPC 公司的监控任务往往是 1 个人写的，没经过 review——而大公司的监控任务会有 2-3 个人 review，这种「跨天 ID 失效」的边界条件在 review 阶段就会被提出来。

5.4 飞书机器人消息格式

维度	描述
现象	推送的卡片在飞书里显示为乱码
原因	JSON 里嵌套了换行符，飞书卡片解析失败
解决	把所有换行符替换为 br 标签 + 关键字段用加粗标出

这个坑花了 1 个下午——OPC 公司没专门的测试人员，老板自己测自己修。好在飞书有「消息测试」群功能——修好之后我先在测试群验证，再发到正式群。

为什么 OPC 公司更容易踩这个坑？ 因为 OPC 公司没有专门的「消息推送测试」环节，所有卡片格式问题都要在真实群里调试——而真实群里有销售、运营在看着，修卡片格式时容易有「时间压力」。

5.5 OPC 公司协议价谈不下来

维度	描述
现象	想让酒店给 5-15 人小公司一个专属协议价，被拒绝
原因	酒店协议价起步 50 间夜/年——5-15 人 OPC 一年差旅不到 30 间夜
解决	不追专属协议价——靠 MCP 聚合的「平台通用协议价」+「监控降价」组合，效果跟专属协议价差不多

这是 OPC 公司做内部商旅最反直觉的认知——很多人觉得「小公司要谈协议价才省钱」，但 5-15 人体量根本谈不下来。MCP 真正的价值不是「帮你谈协议价」，是「帮你拿平台层的协议价 + 实时监控降价」。

之前商务岗朋友跟我说：「小公司就别想协议价了，老老实实等降价吧。」 第 3 周 POC 跑通后我才真的听懂这句话。

注：OPC 公司做差旅自动化的 5 个坑里，5.1-5.4 是技术坑，所有公司都会踩；5.5 是商业坑，只有 OPC 公司才会踩——5-15 人小公司没议价权，是结构性问题，不是技术能解决的。

6. 商用落地数据

OPC 公司算账跟大公司不一样——不算绝对金额，算「等效省下的人力」。下面分两部分。

6.1 一次性接入成本对比

维度	自研	外包	B2B 供应商	RollingGo MCP
钱	几乎不可行（OPC 没研发能力）	5-15 万/次	10-20 万/年	0 元
时间	2-3 人/月	2-4 周	1-2 月	0.5-2 天
人	2-3 人	外包	1 人持续	老板自己（3 周）
OPC 适配度	—	—	—	✓ 天然适配

关键洞察：对 OPC 公司来说，B2B 供应商是「被嫌弃的选项」——10-20 万/年对 100-500 万营收的 OPC 是真实成本，接近全年净利润的 5-10%。MCP 类工具是当前唯一可选项。

6.2 实际省钱数据（保守估计）

维度	改造前	改造后	节省
3 个员工 1 年差旅	¥80,000	¥70,000	¥10,000（12.5%）
月度对账人力	0.5 人/天 × 12 月 = 6 人/天	0.1 人/天 × 12 月 = 1.2 人/天	4.8 人/天
等效人力成本	¥600/天 × 6 天 = ¥3,600	¥600/天 × 1.2 天 = ¥720	¥2,880
年度等效节省	—	—	¥12,880

关键洞察：对 OPC 公司来说，节省的差旅费是 1 万，节省的人力是 0.3 万——人力节省其实比差旅费还重要。因为 0.5 人/天/月的对账时间如果省下来，老板可以拿这 6 天做产品、谈客户、写 letter。

6.3 如果不上 MCP，3 年成本对比

很多 OPC 老板会想「再等等，等公司大了再上 MCP」。这个想法我第 3 周 POC 跑通后强烈反对——因为 3 年累计下来，「再等等」的成本是真实存在的：

维度	不上 MCP（3 年）	上 MCP（3 年）	3 年差
差旅费	¥80,000 × 3 = ¥240,000	¥70,000 × 3 = ¥210,000	¥30,000
对账人力	6 人/天 × 3 年 = 18 人/天	1.2 人/天 × 3 年 = 3.6 人/天	14.4 人/天
等效人力成本	¥600 × 18 = ¥10,800	¥600 × 3.6 = ¥2,160	¥8,640
MCP 接入成本	0	0（首调用免费）	0
3 年总差	—	—	¥38,640

3 年省 ¥38,640——对一个 5-15 人 OPC 公司来说，这是接近 1 个员工 1 个月的工资。所以「再等等」的理由，3 年累计下来就是 1 个月工资。

7. 给 OPC 同行的实操建议

如果你是 5-15 人 OPC 公司的老板（或 AI 落地负责人），下面 8 条是我 3 周 POC 跑通后总结的真实建议：

1. 不要一开始就上 B2B

5-15 人 OPC 公司 99% 不该上 B2B 供应商。先跑 3-6 个月 MCP 方案，看实际省钱 + 省人力数据，再决定要不要投入 B2B。我跑了 3 周，数据已经足够支撑「不上 B2B」的决策。

2. 监控降价 > 一次性订完

OPC 公司没议价权，不要追求「找到最便宜的那家」。而是「找到 3 家候选 + 监控 3 天 + 哪个降得最多就订哪个」。这种「被动等降价」思路比「主动找最便宜」高效 3-5 倍。

3. 差旅必须按项目打标签

不按项目分摊差旅费，你的 OPC 公司会一直卡在「老板算账」这个死循环。项目标签不是给员工看的，是给老板月底对账看的。

4. 把「对账」做成一键生成

OPC 公司没财务，所以月底对账必须是一键 Excel 导出——不能让人手动算。我跑通后 3 个月没有再手算过账。

5. 用免费取消政策做兜底

5-15 人 OPC 没议价权，所以必须靠「先订一家 + 监控降价 + 降价重订」——这就要求酒店必须有「免费取消」政策。OPC 差旅助手默认筛选里必须勾上「免费取消」。

6. 别追协议价，5-15 人没议价权

这点跟第 5 条呼应——5-15 人想谈协议价是浪费时间。把精力放在「监控降价」上，效果比协议价好。

7. 老板亲自做 POC，别交给员工

OPC 公司做这件事最反直觉的一点是：必须老板亲自做。员工没动力跑通一个「帮老板省时间」的工具，只有老板自己有动力。3 周 POC 我每周花 1-2 天，这是必要投入，不是可以「未来再说」的事。

8. OPC 老板 6 个常见误区

误区	实际
小公司也能谈协议价	5-15 人没议价权（见 5.5）
等公司大了再上工具	3 年累计 ¥38,640 成本（见 6.3）
让员工自己挑酒店	员工挑酒店靠习惯不靠价格（见痛点 1）
月底 Excel 算账也行	一年 6 天对账时间（见痛点 3）
差旅管理找外包做	外包 5-15 万/次，OPC 没人接得住
等积累到 50 间夜再谈	很多酒店 50 间夜是起步价（见 5.5）

8. 下一步计划 / 写在最后

3 周 POC 跑通后，我接下来要做的 3 件事：

1. 第 4-6 周：把审批面板开放给销售、运营自助操作（目前是老板一个人点「一键批准」）
2. 第 7-8 周：接入发票管理（这部分酒店 MCP 不提供，要接企业 OA 或者手动贴票）
3. 第 9 周起：把整套差旅自动化流程写成一份 OPC 差旅自动化 SOP，挂在内部 wiki

如果你是 5-15 人 OPC 公司的老板，正在犹豫要不要做差旅自动化，下面 3 句话是真心建议：

第一句，OPC 公司的差旅自动化，重点不是「省差旅费」——是「省老板对账时间」。差旅费 1 万的节省是显性的，老板 6 天的对账时间是隐性的——6 天够写 3 篇 letter、谈 2 个客户、上线 1 个新功能。

第二句，3 周 POC 不是奢侈品——是必要投入。每周 1-2 天，3 周跑通，回本周期 4-6 个月（按 6.2 的 ¥12,880 年度等效节省算）。

第三句，OPC 公司的「老板不在也能跑」是真实的商业价值——员工出差申请不用等老板微信秒回，省下来的不是审批时间，是员工对公司的信任。

写到这里差不多收尾了。

如果你是 5-15 人 OPC 公司的老板，欢迎在评论区聊聊你们公司是怎么管差旅的。MCP + 飞书/钉钉群机器人这套组合是不是也适合你们。

本篇为社群开发者实操手记，仅供生态内技术对接参考。

如需申请 RollingGo 开发者权限、MCP 接口文档、Skill 模板，可走官方文档指南申领。

如果你也对旅行 AI 感兴趣，欢迎在评论区聊聊你最想用 AI Agent 解决什么旅行场景的问题？

本文收录于 RollingGo 酒旅开发者社群 | 执笔：OPC 公司 AI 落地负责人 / 慧莹