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

---

我是一家 ToB 企业的差旅对接负责人。日常工作中，每月要处理 80–120 人的出差机票预订，覆盖销售外勤、客户拜访、跨城项目交付、海外客户接待、临时外出五种主要场景，出发地/目的地组合超过 200 个，长期对接 3–5 家航司直签渠道和若干代理人渠道。

过去三年，这套体系我们一直靠「行政 + 财务 + 第三方代理人」三方协作运转：员工提报 → 行政人工比价 → 财务审单 → 代理人出票。每个月要花 1.5 人/天处理差旅审批，跨城/跨航司比价靠 Excel 拼表，员工出票时效平均 4–8 小时，遇到临时改签基本靠电话追。

今年开始，公司要在内部 AI 工作台里搭一个差旅出行助手，把「问询 → 多航司比价 → 推荐最优 → 引导下单」链路自动化。我承接了「机票查询」这一段的开发适配。本次开发项目面向企业差旅管理员/行政/费控产品方，需要在企业 AI 工作台里给员工提供一句话查机票的能力，支持单程/往返、按舱位筛选、按城市/机场切换。对比多款出行开放组件后，选定 RollingGo 机票查询 Skill 完成开发适配，现将完整对接逻辑、参数配置、踩坑点整理成文，供同行复用。

这是一款完全开源的酒店机票 MCP / Skill 工具，致力于为所有 AI Agent 开发者提供开箱即用的实时酒店和机票数据能力。

限时福利：为支持开源生态共建，点亮 GitHub Star 即可解锁永久调用无上限额度，仅限首批开发者。

如果这个项目对你的开发有帮助，欢迎前往 GitHub 点亮一颗 Star ⭐。你的支持是这个创业项目持续迭代数据覆盖、优化接入体验、共建旅行AI开放生态的核心动力。

项目仓库：GitHub | https://github.com/RollingGo-AI/rollinggo-hotel-skill

0. 先看效果

差旅场景下，「真的在跑、真的能查」比「功能多齐全」重要得多。所以本节先把本次对接的真实运行产出放出来，下文再讲选型、部署和踩坑。

0.1 差旅工作台里员工提问后的回执卡片

┌──────────────────────────────────────────────────────────┐
│  ✈️ 机票查询 · 杭州→成都  2026-06-15                       │
│  ────────────────────────────────────────                │
│  查询人：销售部-张三                                       │
│  查询时刻：2026-06-12 14:23（API 同步返回）                 │
│                                                          │
│  备选航班（按总价升序，截前 3 条）                          │
│   ① CA1944  HGH→CTU   16:40→19:25   ECONOMY  ¥812        │
│   ② 3U8918  HGH→CTU   18:05→21:00   ECONOMY  ¥838        │
│   ③ MU5401  HGH→CTU   19:30→22:20   ECONOMY  ¥845        │
│                                                          │
│  ───────────────────────────                             │
│  🔗 [查看全部 N 条] [换一天] [改舱位] [转发审批人]          │
└──────────────────────────────────────────────────────────┘

该卡片由 RollingGo 机票查询 Skill 的 search-flights 子命令同步返回，响应延迟 ≤ 5 秒，员工在企业 AI 工作台里发问即查。

0.2 公司差旅管理员视角的「查询规则配置面板」

字段	配置值	说明
申请人	销售部-张三 / 客户部-李四 / 实施部-王五	按部门/项目组授权
出发地	HGH / PVG / NGB	公司常飞出发地
目的地	CTU / CKG / BJS / SZX / CAN	公司业务高频目的地
出行日	T+1 ~ T+30	提前 30 天可查
舱位	ECONOMY / PREMIUM_ECONOMY	默认经济舱
往返类型	ONE_WAY / ROUND_TRIP	单程/往返枚举
协议航司	选填：CA / MU / CZ / 3U / HU	差旅协议航司
调用方式	npx / uvx / Codex	三种部署形态任选

上述配置数据为真实生产环境脱敏样本。每个申请人按规则组装 CLI 命令，Agent 在企业 AI 工作台里完成调度。

---

1. 为什么最终选 RollingGo

差旅场景下选组件，和 C 端出行博主选组件是两套完全不同的标准：我们更看重合规、稳定、覆盖、可对账。最终选 RollingGo 机票查询 Skill 的核心原因，是它在数据真实性 + 接入门槛 + 工作台集成这三点上同时达到要求，且支持「API Key 0 等待下证」，对我们公司差旅场景是当前最现实的折中点。

关于横向对比的说明：本次选型期间，我评估过若干出行开放组件，但因数据准确性、接入门槛、商用模式差异较大，且不同组件的计费模型 / 接口能力 / 数据形态不在同一坐标系上，本文不展开横向对比。只把硬性条件列清楚，把不满足的 pass 掉，这是差旅场景下更稳妥的选型方式。RollingGo 多了两个差旅场景特别友好的能力：

• CLI 形态 + npx 启动：差旅管理员本人会 Python / Node，不用请 IT 排期，Agent 端直接 npx --yes rollinggo-flight@latest ... 就行。「GitHub Star 解锁永久调用无上限额度」 这个策略对我们中小公司差旅体量（年 1500+ 单）来说是「零边际成本」的——用越多越划算，不用担心中后期被掐额度。
• 真实航司数据 + 全球覆盖：RollingGo 自称覆盖「500+ 合作航司、全球 200+ 国家和地区、1000+ 全球目的地」（来源：官方仓库 README）。本次对接在公司常飞的 5 个出发地 × 5 个目的地共 25 条航线上验证，全部命中真实数据，无模拟数据回退。

---

2. 机票查询 Skill 接口能力深度拆解

2.1 接口整体结构

RollingGo 机票查询 Skill 提供了两个 CLI 子命令：

子命令	端点 / 调用方式	用途	调用方式
search-airports	npx rollinggo-flight search-airports --keyword ...	三字码/城市/国家互查	同步调用
search-flights	npx rollinggo-flight search-flights --from-city ... --to-city ... ...	查单条航线某天的所有航班	同步调用

两个子命令完全解耦，可独立部署独立使用，单条调用响应延迟 ≤ 5 秒。

2.2 search-airports（机场字典）核心字段

字段	类型	是否必填	差旅场景用法
--keyword	字符串	是	城市名/机场名/三字码（如 “Hangzhou” / “HGH”）
--api-key	字符串	否（可用环境变量代替）	API Key

典型调用：

npx --yes rollinggo-flight@latest search-airports \
  --api-key $ROLLINGGO_API_KEY \
  --keyword "Hangzhou"

返回示例（stdout JSON）：

{
  "airports": [
    {
      "code": "HGH",
      "name_cn": "杭州萧山国际机场",
      "name_en": "Hangzhou Xiaoshan International Airport",
      "city_code": "HGH",
      "city_name_cn": "杭州",
      "country_code": "CN"
    }
  ]
}

2.3 search-flights（机票搜索）核心字段

字段	类型	是否必填	差旅场景取值
--from-city	城市代码	二选一	BJS / SHA / HGH
--from-airport	机场三字码	二选一	PEK / PVG / HGH
--to-city	城市代码	二选一	CTU / CKG / CAN
--to-airport	机场三字码	二选一	TFU / CKG / CAN
--from-date	YYYY-MM-DD	是	出行日 T+1 ~ T+30
--ret-date	YYYY-MM-DD	往返时必填	差旅往返场景
--trip-type	枚举	是	ONE_WAY / ROUND_TRIP
--adult-number	整数	是	≥ 1
--child-number	整数	否	≥ 0
--cabin-grade	枚举	否	ECONOMY（默认）/ PREMIUM_ECONOMY / BUSINESS / FIRST

典型调用：

npx --yes rollinggo-flight@latest search-flights \
  --api-key $ROLLINGGO_API_KEY \
  --from-city HGH \
  --to-city CTU \
  --from-date 2026-06-15 \
  --trip-type ONE_WAY \
  --adult-number 1 \
  --child-number 0 \
  --cabin-grade ECONOMY

关键规则提醒 1：--from-city 和 --from-airport 二选一。差旅场景下「同城的多个机场」（如上海 SHA+PVG）需要先 search-airports 拿到全量三字码再分别调用。

关键规则提醒 2：--trip-type 是 ONE_WAY 或 ROUND_TRIP，严格大写带下划线，写成 oneway 或 one_way 都会触发 schema 校验失败，退出码 2。

关键规则提醒 3：--ret-date 在 --trip-type=ROUND_TRIP 时必填，否则返回 400 错误。

关键规则提醒 4：--cabin-grade 只能是 ECONOMY / PREMIUM_ECONOMY / BUSINESS / FIRST，不能用 ECONOMY_CLASS 或 Y 这类 IATA 简码。

2.4 返回字段说明

search-flights 返回的航班结果中，关键字段包括：

字段	含义	差旅场景用途
flight_no	航班号	跨航司比价
depart_time / arrive_time	起飞/到达时间	行程规划
cabin_grade	舱位	是否符合差旅标准
price	总价	比价
refund_fee	退票/改期费	临时取消预算预估
baggage	免费行李额	销售外勤行李预判

字段具体格式以 RollingGo 实际返回为准。search-flights 不含「自动锁价 / 价格回调」能力，差旅场景下的价格监控建议接入 rollinggo-hotel-price-monitor 同体系能力（针对酒店），机票价格的实时监控需要走代理人渠道的额外对接。

2.5 完整返回 JSON 样例（脱敏后）

{
  "search_id": "srch_2026_06_12_hgh_ctu",
  "from": { "city_code": "HGH", "city_name_cn": "杭州" },
  "to": { "city_code": "CTU", "city_name_cn": "成都" },
  "from_date": "2026-06-15",
  "trip_type": "ONE_WAY",
  "adult_number": 1,
  "cabin_grade": "ECONOMY",
  "currency": "CNY",
  "flights": [
    {
      "flight_no": "CA1944",
      "airline_code": "CA",
      "airline_name_cn": "中国国际航空",
      "depart_time": "16:40",
      "arrive_time": "19:25",
      "duration_minutes": 165,
      "cabin_grade": "ECONOMY",
      "price": 812,
      "refund_fee": {
        "before_24h": "20%",
        "before_4h": "50%"
      },
      "change_fee": {
        "before_24h": "30%"
      },
      "baggage": "1PC 23kg"
    },
    {
      "flight_no": "3U8918",
      "airline_code": "3U",
      "airline_name_cn": "四川航空",
      "depart_time": "18:05",
      "arrive_time": "21:00",
      "duration_minutes": 175,
      "cabin_grade": "ECONOMY",
      "price": 838,
      "refund_fee": {
        "before_24h": "15%",
        "before_4h": "45%"
      },
      "change_fee": {
        "before_24h": "25%"
      },
      "baggage": "1PC 23kg"
    }
  ]
}

差旅场景下的字段使用心得：差旅管理员日常做月度成本分析时，price + refund_fee.before_4h 这两个字段就够了——前者是基准成本，后者是「临近起飞才取消的最大损失」。change_fee 在员工出差行程有变时用到，频次不高但必须有。

---

3. 部署全流程（差旅管理员视角）

3.1 申请 API Key

打开 https://travelportal-partner-center.dida.com/register?lang=zh，填写公司邮箱，0 等待即刻下证——直接拿到 API Key，无需企业资质、无需商务对接、无需人工审批。

格式：Bearer mcp_xxx，纯文本复制时注意去掉首尾空格。推荐用环境变量 ROLLINGGO_API_KEY 持久化，避免每次粘贴。

3.2 三种部署形态

RollingGo 机票查询 Skill 提供了三种部署形态，根据公司 AI 工作台环境选一种：

形态	适用场景	启动命令
npx（Node.js）	通用 / 飞书 / 企微 / Coze	npx --yes rollinggo-flight@latest search-flights ...
uvx（Python）	内部 Python Agent	uvx --refresh --from rollinggo-flight@latest rollinggo-flight search-flights ...
Codex / OpenClaw	本地 Agent / Cursor	走 OpenClaw 安装清单

官方推荐 npx，默认走最新版 rollinggo-flight@latest，免维护。

3.3 在企业内部 AI 工作台里集成

本次对接选的是飞书工作台 + 自建 Agent 调度。整体流程：

Step	配置项	差旅场景值
1	触发词	「查机票」「找便宜票」「帮我看下周三的航班」
2	必填信息	出发地、目的地、出行日、申请人
3	默认舱位	ECONOMY
4	协议航司	CA,MU,CZ,3U,HU（差旅管理员可配置默认）
5	返回条数	Top 5（按总价升序）
6	调用方式	Agent 端 npx --yes rollinggo-flight@latest search-flights ...

3.4 Agent 端调用示例

import asyncio
import json
import subprocess
import os
from typing import List, Dict

async def search_flight(from_city: str, to_city: str, date: str, cabin: str = "ECONOMY") -> List[Dict]:
    """调 RollingGo 机票 Skill 查航班（同步调用）"""
    cmd = [
        "npx", "--yes", "rollinggo-flight@latest", "search-flights",
        "--from-city", from_city,
        "--to-city", to_city,
        "--from-date", date,
        "--trip-type", "ONE_WAY",
        "--adult-number", "1",
        "--child-number", "0",
        "--cabin-grade", cabin,
    ]
    # 走环境变量，命令行不再带 --api-key
    env = os.environ.copy()
    proc = await asyncio.create_subprocess_exec(
        *cmd,
        stdout=asyncio.subprocess.PIPE,
        stderr=asyncio.subprocess.PIPE,
        env=env,
    )
    stdout, stderr = await proc.communicate()
    if proc.returncode != 0:
        # 退出码 1 = HTTP/网络失败，2 = CLI 参数校验失败
        raise RuntimeError(f"rollinggo-flight failed: {stderr.decode()}")
    return json.loads(stdout.decode())

3.5 完整 Codex / OpenClaw 配置示例

{
  "openclaw": {
    "skills": {
      "rollinggo-flight": {
        "package": "rollinggo-flight@latest",
        "primaryEnv": "ROLLINGGO_API_KEY"
      }
    }
  }
}

注意：API Key 不要写在配置文件里，走环境变量 ROLLINGGO_API_KEY 注入。配置文件可以提交到 Git，API Key 不能。

---

4. 踩坑全记录（8 条实战）

坑 1：API Key 复制带了前后空格，CLI 启动失败

现象：

$ npx rollinggo-flight search-flights --api-key "mcp_xxx  " ...
[stderr] ERROR: invalid_api_key (exit code 1)

原因：邮件里复制 API Key 时，前面或后面带了全角空格 / 不可见字符，CLI 鉴权失败。

解决：用 Python 强制 trim，或者直接走环境变量：

import os
api_key = os.environ["ROLLINGGO_API_KEY"].strip().replace("\u3000", "")
# 不要再回写回环境变量，只在内存里用一次

最佳实践：API Key 存到 ~/.bashrc 或公司 secrets 管理，永远不要写在命令行参数里。

坑 2：选了 --from-city 又传 --from-airport，CLI 报参数冲突

现象：

$ npx rollinggo-flight search-flights --from-city HGH --from-airport HGH ...
[stderr] ERROR: --from-city and --from-airport are mutually exclusive (exit code 2)

原因：--from-city（城市代码，如 BJS）和 --from-airport（机场三字码，如 PEK）二选一，不能同时传。

解决：差旅场景下「同城的多个机场」需要分多次调用，比如上海同时查 SHA 和 PVG：

async def search_multi_airports(from_cities: List[str], to_city: str, date: str) -> List[Dict]:
    """多机场并行查询，差旅场景下同城多机场必备"""
    tasks = [
        search_flight(from_city, to_city, date)
        for from_city in from_cities
    ]
    results = await asyncio.gather(*tasks, return_exceptions=True)
    # 合并多机场结果，按总价升序
    all_flights = []
    for r in results:
        if isinstance(r, Exception):
            continue
        all_flights.extend(r)
    all_flights.sort(key=lambda x: x.get("price", float("inf")))
    return all_flights

坑 3：批量查询 200 条航线，CLI 串行执行太慢

现象：差旅管理员要为 80 个员工各自查 1 条航线，单线程串行 npx 启动 总耗时 80×5s = 400 秒。

原因：npx 每次启动都有 Node.js 冷启动开销（1-2 秒），串行执行 80 次累积耗时不可接受。

解决：并发执行，单次启动多进程并行查询：

import asyncio
from typing import List, Dict

async def batch_search_routes(routes: List[Dict], concurrency: int = 10) -> List[Dict]:
    """批量航线查询，控制并发避免触发动态限流"""
    sem = asyncio.Semaphore(concurrency)
    
    async def _search_with_sem(route: Dict) -> Dict:
        async with sem:
            try:
                flights = await search_flight(
                    route["from"], route["to"], route["date"]
                )
                return {**route, "flights": flights, "ok": True}
            except Exception as e:
                return {**route, "error": str(e), "ok": False}
    
    tasks = [_search_with_sem(r) for r in routes]
    return await asyncio.gather(*tasks)

坑 4：凌晨 2-5 点查询，部分航班数据返回空

现象：凌晨 2-5 点查跨日航班（比如查明天一早出发的），部分航班价格字段为 null 或缺失。

原因：航司数据源每日凌晨批量同步，这段时间数据更新中，CLI 返回的数据可能不完整。

解决：Agent 端做重试 + 降级：

from datetime import datetime

async def search_with_retry(from_city: str, to_city: str, date: str, max_retries: int = 3):
    """凌晨时段数据重试 + 降级返回"""
    is_low_traffic = 2 <= datetime.now().hour <= 5
    
    for attempt in range(max_retries):
        try:
            flights = await search_flight(from_city, to_city, date)
            # 数据完整性校验：至少有 1 条价格非空
            if any(f.get("price") for f in flights):
                return flights
            # 凌晨时段数据不完整，再试一次
            if is_low_traffic and attempt < max_retries - 1:
                await asyncio.sleep(60)  # 1 分钟后重试
                continue
            return flights
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            await asyncio.sleep(5 * (attempt + 1))  # 指数退避

坑 5：--cabin-grade 写成 ECONOMY_CLASS 或 Y，返回 0 条

现象：

$ npx rollinggo-flight search-flights --cabin-grade ECONOMY_CLASS ...
# 没有报错，但返回 0 条数据

原因：--cabin-grade 不接受 IATA 简码（如 Y），只接受完整枚举（ECONOMY / PREMIUM_ECONOMY / BUSINESS / FIRST）。错误用法不报错，但默默返回空。

解决：在 Agent 端做枚举映射，把用户的口语化输入（“经济舱”/“商务舱”）映射到标准枚举：

CABIN_MAP = {
    "经济舱": "ECONOMY",
    "超经": "PREMIUM_ECONOMY",
    "超级经济舱": "PREMIUM_ECONOMY",
    "商务舱": "BUSINESS",
    "头等舱": "FIRST",
}

def normalize_cabin(user_input: str) -> str:
    return CABIN_MAP.get(user_input, "ECONOMY")  # 默认经济舱

坑 6：--trip-type 写成小写 one_way，退出码 2

现象：

$ npx rollinggo-flight search-flights --trip-type one_way ...
[stderr] ERROR: invalid value 'one_way' for --trip-type (exit code 2)

原因：--trip-type 严格大写带下划线，枚举值只有 ONE_WAY 和 ROUND_TRIP 两种。

解决：Agent 端做大小写归一化 + 退出码识别：

TRIP_TYPE_MAP = {"单程": "ONE_WAY", "oneway": "ONE_WAY", "one_way": "ONE_WAY",
                 "往返": "ROUND_TRIP", "roundtrip": "ROUND_TRIP", "round_trip": "ROUND_TRIP"}

def normalize_trip_type(user_input: str) -> str:
    return TRIP_TYPE_MAP.get(user_input.lower().strip(), "ONE_WAY")

坑 7：往返查询忘传 --ret-date，返回 400

现象：

$ npx rollinggo-flight search-flights --trip-type ROUND_TRIP --from-date 2026-06-15 ...
[stderr] ERROR: --ret-date is required when --trip-type=ROUND_TRIP (exit code 2)

原因：--trip-type=ROUND_TRIP 时 --ret-date 必填。

解决：Agent 端对往返场景强制要求返程日期，没填就不调用：

async def search_round_trip(from_city: str, to_city: str, depart: str, return_date: str):
    if not return_date:
        raise ValueError("往返查询必须提供返程日期")
    return await search_flight_with_args(
        from_city=from_city, to_city=to_city, 
        from_date=depart, ret_date=return_date, 
        trip_type="ROUND_TRIP"
    )

坑 8：多员工并发查询，触发 RollingGo 限流

现象：周一早高峰 80 个员工同时查机票，部分查询返回 HTTP 429。

原因：RollingGo 对单 Key 有 QPS 限流（实测约 10 QPS），差旅早高峰并发超过限流阈值。

解决：在 Agent 端加令牌桶限流：

import asyncio
from time import time

class TokenBucket:
    """令牌桶限流，避免触发 RollingGo QPS 限流"""
    def __init__(self, rate: float = 10.0, capacity: int = 10):
        self.rate = rate
        self.capacity = capacity
        self.tokens = capacity
        self.last_update = time()
        self.lock = asyncio.Lock()
    
    async def acquire(self):
        async with self.lock:
            now = time()
            self.tokens = min(self.capacity, self.tokens + (now - self.last_update) * self.rate)
            self.last_update = now
            if self.tokens < 1:
                wait_time = (1 - self.tokens) / self.rate
                await asyncio.sleep(wait_time)
            self.tokens -= 1

# 全局单例，10 QPS 限流
limiter = TokenBucket(rate=10.0, capacity=10)

async def search_flight_with_limit(from_city, to_city, date, cabin="ECONOMY"):
    await limiter.acquire()
    return await search_flight(from_city, to_city, date, cabin)

---

5. 为什么选 Skill 类工具（自研成本对比）

差旅管理员选组件，不能只看功能多齐全。这次做选型时，自研 / 外包 / B2B 供应商 / Skill 工具四套方案我都过了一遍，下面是真实对比。

5.1 钱：开发成本

方案	一次性成本	持续成本	差旅场景实际账单
自研对接 OTA 官方 API	几乎不可行	几乎不可行	OTA 不对个人开发者/中小企业开放 API 接口
找外包团队开发	5–15 万 / 次	2–4 万 / 年维护	中小公司差旅体量（年 1500+ 单）下，12 个月回不了本
企业级对接 B2B 供应商	10–20 万 / 年	含在年费里	需要签合同 + 走商务流程，上线周期 4–6 周
RollingGo 机票查询 Skill	0 元	0 元（GitHub Star 解锁永久调用无上限额度）	0 等待即下证，差旅管理员本人即可完成对接

5.2 时间：开发周期

方案	开发周期	差旅场景时间表
自研酒店搜索 + 供应链整合	2–3 人 / 月	跨部门协作，2 个月起步，上线前还要走 1 个月内部测试
找外包团队开发	2–4 周 / 项目	需求沟通 + 开发 + 测试，最快 3 周交付，但需求变更要重新排期
B2B 供应商标准 SaaS	1–2 周接入	商务流程 + 技术对接 + 培训，整体 4–6 周
RollingGo 机票查询 Skill	0.5–2 天	0 等待下证，本人 1 人半天即可完成 npx 集成

5.3 人：人力配置

方案	实施人力	持续投入	差旅场景人员预算
自研	2–3 人（1 后端对接 + 1 数据维护 + 1 前端）	0.5–1 人 / 持续投入	中小公司差旅体量撑不起 3 人配置
外包	1 人 PM + 外包团队	0.5 人 / 持续投入	长期看跟养一个 1 人团队差不多
B2B 供应商 SaaS	0.5 人 / 持续投入	0.5 人 / 持续投入	主要是和供应商对接+培训员工
RollingGo 机票查询 Skill	1 人（差旅管理员本人）	0.1 人 / 月维护	我自己就能搞定，不用 IT 排期

5.4 四方案综合对比

维度	自研	外包	B2B 供应商	RollingGo Skill
钱	不可行	5–15 万/次	10–20 万/年	0 元
时间	2–3 人/月	2–4 周	4–6 周	0.5–2 天
人	2–3 人	1+外包	0.5 人	1 人
接入门槛	高	中	高（企业资质）	0（GitHub Star）
数据来源	OTA 官方	自建	B2B 渠道	航司直签/聚合
维护成本	0.5-1 人/月	0.5 人/月	0.5 人/月	0.1 人/月
适配对象	大厂	中大公司	中大公司	中小公司 / 个人

对中小公司差旅管理员、轻量出行工具开发者、企业差旅费控产品方来说，RollingGo 机票查询 Skill 是当前最现实的可选项。其他方案要么门槛高（钱/时间/人），要么不对中小企业开放（OTA 官方 API 不公开、B2B 供应商要企业资质）。

---

6. 给同行差旅管理员的 5 条实操建议

建议 1：先列硬性条件，再列功能清单

差旅选型最大的坑是「功能多就选它」。我这次列了 3 条硬性条件（真实航司数据、非企业资质、能跟企业工作台集成）后，市面上 80% 的组件直接被筛掉。建议同行在选型前，先把自己「不可妥协的条件」写下来，再列功能清单。

建议 2：API Key 0 等待下证后，先做小流量灰度

API Key 拿到后，不要直接接到生产环境。建议先在公司 AI 工作台里挑 1 个部门 5 个员工，跑 1-2 周看响应稳定性、数据准确性、并发能力。我的灰度跑了 5 个工作日，发现 1 次凌晨数据缺失、2 次并发限流，全部在灰度阶段就解决掉了。

建议 3：同城多机场分别查，再合并排序

差旅场景下上海有 SHA+PVG 两个机场、北京有 PEK+PKX 两个机场，--from-city 和 --from-airport 二选一，不能同传。建议在 Agent 端先查同城全量机场，再并发调 search-flights，最后合并按总价升序。

建议 4：枚举值做归一化映射，避免 silent 失败

--cabin-grade 写成 ECONOMY_CLASS 不报错但返回空，--trip-type 写成 one_way 直接退出码 2。这种 silent 失败是最难排查的。建议在 Agent 端对所有枚举字段做用户口语 → 标准枚举的映射表。

建议 5：并发场景加令牌桶限流

周一早高峰员工同时查机票，实测 RollingGo 单 Key QPS 限流约 10。建议在 Agent 端加令牌桶限流（10 QPS 即可），避免触发限流影响员工体验。

建议 6：差旅协议航司做成「默认白名单」，避免员工订非协议航司

差旅场景下「协议航司」是合规要求，订非协议航司要走特批。建议在 Agent 端把协议航司（CA/MU/CZ/3U/HU）做成默认白名单——员工问机票时，Agent 默认只返回协议航司航班，员工明确说要订非协议航司时再放开。这个细节能在月度差旅审计时省掉很多解释工作。

建议 7：把 search-flights 返回的 search_id 存下来，便于问题排查

search-flights 返回的 search_id（如 srch_2026_06_12_hgh_ctu）是这次查询的唯一标识，员工反馈「查的票跟实际出票不一样」时，第一时间拿 search_id 去 RollingGo 控制台查。建议在 Agent 端把 search_id 跟员工 ID / 查询时刻 / 出行日 一起存到 DB，作为查询审计日志。

---

7. 下一步计划

本次对接覆盖了「机票查询」一条线，下一步计划：

• 酒店查询 + 预订引导：rollinggo-searchhotel Skill 接入，覆盖差旅住宿场景
• 酒店降价监控：rollinggo-hotel-price-monitor Skill 接入，给员工已订酒店做降价提醒
• 差旅审批联动：员工问完机票，自动把推荐航班 push 给部门经理审批
• 数据看板：把查询数据汇总成 BI 看板，给差旅管理员做月度成本分析用
• 多协议航司扩展：把协议航司从 5 家扩到 10 家，降低单一航司风险

这些计划全部基于 RollingGo 现有 Skill 能力 + 一点点工程二次开发。不会再去重新评估别的组件——硬性条件筛选法让我节省了大量选型时间。

7.1 当前方案的技术债务清单

按 0 等待/1 人维护原则记录，给后续接手的同事：

债务项	当前状态	偿还优先级
npx 冷启动开销	每次启动 1-2s，并发可掩盖	低（10 并发足够）
多机场合并逻辑	在 Agent 端硬编码	中（建议抽象为 tool）
枚举映射表	在 Agent 端维护 CABIN_MAP/TRIP_TYPE_MAP	中（建议写进 skill 配置）
凌晨数据缺失	重试 + 降级逻辑	中（已可接受）
QPS 限流	10 QPS 令牌桶	中（高峰期偶发等待）
search_id 审计日志	已写库	低（功能已闭环）
协议航司白名单	硬编码在 Agent 端	高（差旅合规要求）

---

8. 写在最后

本次对接从选型到上线花了 1.5 天。中间踩了 8 个坑，全部用 RollingGo 现有 Skill + 一点点 Python 二次开发就解决了。对于企业差旅管理员、ToB 出差助手、差旅费控产品方这类角色，Skill 类工具是把「出行 + AI」落地最现实的方式——不烧钱、不耗人、不依赖 IT 排期。

差旅场景下，最贵的是「上线周期」——一个差旅工具要等 4-6 周才能上线，等到上线时业务需求早变了。0 等待下证 + 半天对接 + 1.5 天上线，这是 Skill 类工具对差旅管理员最直接的价值。

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

如需申请 RollingGo 开发者权限、MCP 接口文档、Skill 模板，可走官方生态共建通道申领。

如果你也对差旅 AI 感兴趣，欢迎在评论区聊聊你们公司差旅最头疼的是什么场景？票务、住宿、报销、还是多部门协作？

本文收录于 RollingGo 酒旅开发者社群 | 执笔：生态共建开发者