

最近在做 AI Agent 的开发时，一个越来越明显的变化是：

**模型本身能回答什么，已经不是全部；它能连接哪些真实世界的数据和工具，越来越重要。**

搜索、数据库、代码执行都已经是比较常见的 Agent Tool，但航空出行其实也是一个很典型的专业数据场景。

比如用户问：

> “10 月 1 日准备从上海浦东飞广州白云，先帮我找几个航班，比较一下延误风险；临近出发时，再看看机场天气。”

这个问题看起来只有一句话，背后却至少包含了几个独立任务：

查机场对航班、比较候选航班的延误风险；进入出发前 48 小时后再看机场未来天气，到了出发当天还可能继续查询实时航班动态。

最近我们把航班管家 DAST 的航空数据能力接入 MCP 后，也重新思考了一个问题：

**当 AI Agent 面对多个专业数据 Tool 时，怎样让它不仅“能调用”，还知道“什么时候应该调用哪个”？**

## 先看一下航班管家 DAST MCP 目前提供什么

航班管家 DAST 目前同时支持 Remote MCP 和本地 STDIO 两种接入方式。本文主要以 Remote MCP 为例，公开 Endpoint 为：

`https://fly.huoli.com/mcp/dast_mcp`

目前包括 9 个航空数据 Tool，覆盖航班查询、天气、预测、轨迹以及民航运行统计等场景。

对应关系大致如下：

| 用户需求 | Tool |
|---|---|
| 指定航班动态 | `dast_flight_dynamic` |
| 两个机场之间的航班 | `dast_flight_route` |
| 餐食、Wi-Fi、座椅、舒适度 | `dast_flight_happy` |
| 未来延误、取消风险 | `dast_delay_rate` |
| 机场未来天气 | `dast_future_weather` |
| 位置、高度、速度、飞行轨迹 | `dast_flight_path` |
| 全国单日民航运行情况 | `dast_flight_overview_daily` |
| 机场运行统计 | `dast_airport_operation_statistics` |
| 航司运行及机队数据 | `dast_airline_operation_statistics` |

看起来只是 9 个工具，但真正让 Agent 稳定使用起来，问题并没有“接口通了”这么简单。

## 一个真实任务，需要连续调用多个 Tool

还是看刚才那个场景：

> “10 月 1 日准备从上海浦东飞广州白云，先帮我找几个航班，比较一下延误风险；临近出发时，再看看机场天气。”

Agent 首先要识别：

这不是“查询某个航班状态”，而是一个**机场对 + 日期 + 航班列表**的问题。

因此第一步应该调用：

`dast_flight_route`

找到候选航班以后，如果需要比较未来运行风险，再调用：

`dast_delay_rate`

但机场天气并不是任何未来日期都能直接查。当前机场未来天气 Tool 的有效查询窗口是未来 48 小时，因此只有临近出发时，才应该继续调用：

`dast_future_weather`

到了出发当天，再查具体航班：

`dast_flight_dynamic`

于是同一个旅行需求，并不一定要在一次会话里把所有 Tool 全部调用完，而可能按照时间阶段形成这样的调用链：

```text
现在规划行程
    ↓
dast_flight_route
    ↓
候选航班
    ↓
dast_delay_rate
    ↓
比较未来延误 / 取消风险

进入出发前 48 小时
    ↓
dast_future_weather
    ↓
机场天气

出发当天
    ↓
dast_flight_dynamic
    ↓
实时航班状态
```

这里其实还多了一层 Routing 问题：

**Agent 不仅要知道“该调用哪个 Tool”，还要知道“这个 Tool 现在是不是到了可以调用的时间窗口”。**

这也是我们做 MCP 之后感受比较明显的一件事：

**Tool 最好对应“用户意图”，而不是简单对应后端已有接口。**

如果把多个类似能力都塞进一个大而全的 `flight_query`，参数会越来越多，description 越来越长，返回结构也越来越复杂，Agent 最后反而更难判断真正应该调用什么。

## Tool Routing 不能完全依赖模型“自己悟”

MCP Tool 数量少的时候，靠 Tool name 和 description，模型通常能完成基本选择。

但工具越来越多后，边界开始接近。

比如：

“这个航班怎么样？”

到底是在问实时状态？

还是延误风险？

还是 Wi-Fi、餐食和座椅？

甚至可能是在问现在飞到哪了。

所以我们最终选择把 Tool Routing 显式写进 Agent 文档。

例如：

```text
航班号 + 航班动态
→ dast_flight_dynamic

未来延误 / 取消概率
→ dast_delay_rate

位置 / 高度 / 速度 / 轨迹
→ dast_flight_path

餐食 / Wi-Fi / 舒适度
→ dast_flight_happy
```

这其实和传统 API 文档不太一样。

以前开发者会主动读文档，然后判断：

> 这个需求应该请求哪个接口。

现在这个判断发生在 Agent 运行时。

如果边界不明确，常见的结果有两个：

一个是选了一个“差不多能回答”的 Tool；

另一个是为了保险，一次调用多个相关 Tool。

对于存在调用成本和时延的数据服务来说，第二种情况尤其需要控制。

## Schema 正确，不代表业务参数就正确

航空数据还有一个特别典型的问题：

**日期。**

从 Schema 看：

```text
date = YYYY-MM-DD
```

非常简单。

但对于航班动态和机场对查询，这里的日期定义为：

**航班出发机场当地自然日。**

全国、机场、航司运行统计使用的则是：

**北京时间自然日。**

所以用户说：

> “查一下明天的 CA1831。”

Agent 不能简单拿服务器当前时间 +1 天。

它还要理解：

这个“明天”到底应该基于哪里的自然日。

这里有一个很值得专业数据 MCP 开发者注意的点：

> **Schema 只能验证参数格式，不能完全表达业务语义。**

一个日期字符串即使 100% 合法，也可能在业务上错一天。

因此专业 Tool 的 Agent 文档里，除了 `string / required / enum`，还必须补充：

日期解释、时区规则、相对时间转换等语义。

## 预测类数据还要约束 Agent“怎么说”

另外一个典型例子是延误预测。

假设 Tool 返回：

```text
delayRate_30min = 12.2%
```

技术上很好理解：

这是“延误 30 分钟以上的预测概率”。

但 Agent 最后输出的是自然语言。

它不能把：

> 延误概率为 12.2%

改写成：

> 这个航班会延误 30 分钟。

前者是预测，后者变成了确定事实。

因此给 Agent 的规则里，还需要明确：

**预测数据如何表达。**

类似的边界还包括：

计划时间 ≠ 预计时间 ≠ 实际时间；

天气预报 ≠ 已发生天气；

当前运行数据 ≠ 历史统计结果。

这已经不只是传统意义上的 API 字段文档，而是在定义：

**Agent 应该怎样理解和表达专业数据。**

## 有些 Tool 调用结束，任务其实才刚开始

前 6 个查询类 Tool，大部分会直接返回 JSON。

但全国民航、机场和航司运行统计这 3 类报表 Tool，返回的是一个 **1 小时有效**的 Excel 下载链接。

Agent 后面的流程其实是：

```text
调用 Tool
→ 获取 file_url
→ 下载 Excel
→ 读取“数据说明”
→ 判断目标 Sheet
→ 核对统计口径
→ 读取数据
→ 组织回答
```

所以对文件型、报表型 Tool 来说，不能只设计：

> 调用后返回什么？

还要设计：

> Agent 拿到结果以后下一步应该怎么处理？

这也是我们后来认为 `agent.md` 很有价值的原因。

`tools/list` 解决的是：

**Tool 现在怎么调用。**

传统开发者文档解决的是：

**人怎么接入和调试。**

而 Agent 文档更关心：

**Agent 在什么场景下应该如何使用这些 Tool。**

## MCP 成功，也不等于业务查询成功

还有一个比较容易踩的工程坑。

航班管家 MCP 使用 JSON-RPC 2.0。

业务 JSON 通常位于：

```text
result.content[0].text
```

其中还包含原有的业务 JSON，例如：

```json
{
  "code": 0,
  "msg": "success",
  "data": {},
  "count": 1
}
```

因此在 Remote 模式下，看到：

```text
HTTP 200
```

只能说明 HTTP 请求已经正常返回；即使 MCP 层进一步显示：

```text
isError = false
```

也不能直接认为航班业务查询已经成功。

Agent 仍然需要继续解析 `result.content` 中的业务 JSON，并检查业务 `code` 和真实数据。

换句话说：

**MCP 标准化了 Tool 的调用方式，但不会自动消灭原有 API 体系中的业务状态。**

## 从 API 到 MCP，我们真正重新设计的是什么？

做完这一轮之后，我们对这件事的理解反而越来越简单：

MCP 解决的是：

> **让工具可以被 Agent 调用。**

但一个专业数据 Tool 真正需要解决的是：

> **Agent 知不知道什么时候调用、参数怎么传、数据怎么理解、结果怎么表达。**

因此把已有 API 改造成 MCP 时，最值得重新设计的未必是协议层，而是原来散落在开发文档、客服经验、业务人员脑子里的那一整套**业务语义**。

这也是专业数据进入 Agent 时代之后比较有意思的变化。

过去我们主要是在写：

**API Documentation**

现在可能还要多维护一层：

**Agent Runtime Contract。**

目前航班管家 DAST 同时通过 `tools/list`、开发者文档、`agent.md`、GitHub Repository 等方式维护 MCP 相关信息，其中线上 Tool 定义以实时 `tools/list` 为准，Agent 文档补充 Tool Routing、时间语义、字段解释和行为约束。

对于正在把专业 API 接入 AI Agent 的开发者来说，这些问题可能比“怎么把 MCP Server 跑起来”更值得花时间。

## 相关接入信息

**航班管家 DAST MCP**

产品页：

`https://dast.133.cn/mcp/`

Remote MCP Endpoint：

`https://fly.huoli.com/mcp/dast_mcp`

Remote 鉴权：

`Authorization: Bearer <API_KEY>`

官方 GitHub：

`https://github.com/flight-master-dast/aviation-data-mcp`

Agent 文档：

`https://dast.133.cn/mcp_assets/agent.md`

本地 STDIO / npm：

`npx -y @flightmaster/aviation-dast-mcp`

其中 `DAST_API_KEY` 为必填环境变量。

当前 MCP 提供航班动态、机场对、舒适度、延误预测、机场天气、飞行轨迹以及全国、机场、航司运行统计等 9 项 Tool。线上 Tool 定义如有变化，以实时 `tools/list` 为准。


搜索、数据库、代码执行都已经是比较常见的 Agent Tool，但航空出行其实也是一个很典型的专业数据场景。

# MCP实战：让AI Agent自己查航班、天气和延误风险，航班管家DAST是怎么做的？

**模型本身能回答什么，已经不是全部；它能连接哪些真实世界的数据和工具，越来越重要。**

人工智能

开发工具

后端

航空数据接入MCP后，Agent需掌握9个工具的调用时机、时间窗口与业务语义，如日期自然日规则、预测概率表达、报表型工具的文件下载流程，并区分HTTP成功与业务成功，实现从“能调用”到“会调用”的智能路由。

代码解释

数据库

服务器

GitHub

Agent

JSON

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

# MCP实战：让AI Agent自己查航班、天气和延误风险，航班管家DAST是怎么做的？-腾讯云开发者社区-腾讯云

# MCP实战：让AI Agent自己查航班、天气和延误风险，航班管家DAST是怎么做的？

# MCP实战：让AI Agent自己查航班、天气和延误风险，航班管家DAST是怎么做的？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐