AvioBook用Amazon Bedrock AgentCore做一个"调机数据分析师"
AvioBook在AWS上用一周时间搭出多智能体概念验证：把AvioBook Connect里每架航班的聊天记录和事件日志，变成航空公司经理和签派员能用自然语言提问并拿到证据的答案，还能顺带检查延误代码填得对不对。
AI解读：航空公司调机（turnaround，飞机落地到下次起飞之间的时间）每延误一分钟，大约损失 20 美元；一架中型航司每天飞 200 班，平均调机时间缩短 2 分钟，一个月大约值 24 万美元。这是AvioBook和AWS在文章里给出的估算基线。
问题是数据一直在，但用不上。AvioBook Connect从 2018 年就在航司服役，每个航班有一个flightroom（类似每班一个实时聊天室），自动推送飞机变更、延误、新飞行计划、登机进度，也记录机组和地面人员的对话。这些记录是带时间戳的，但以前只能靠人翻历史、手动对照延误代码。
AvioBook的做法不是做一个万能助手，而是按角色拆成两个智能体：一个给负责准点率的航司经理，查历史数据和延误代码是否填错；一个给运行控制中心（OCC）签派员，查实时航班和中断影响。每个用户只能接触自己角色对应的智能体。
技术上，智能体跑在Amazon Bedrock AgentCore的runtime上，用AgentCore memory保留会话上下文，通过AgentCore Gateway以MCP工具的方式访问数据；底层数据在S3里按航司分区存Parquet，用Athena查询、Glue Data Catalog管schema。每个请求带JWT，绑定到具体航司账号和区域。
延误代码校验是当成"第二意见"而不是自动改正。因为延误代码要进合规报告，智能体只负责把代码和底层事件序列对不上的地方标出来，最终判断仍由航司经理做。AvioBook强调Connected Analytics是咨询性软件，不在飞机的适航认证系统内，不自动执行操作。
AvioBook说一周的联合开发就验证了架构可行，并准备把它产品化。文章还提到此前一个欧洲中型航司在一个夏季避免了超过 4000 小时延误，其中 124 小时直接来自减少电话和手动来回确认；后续他们想加入的是主动异常告警，让智能体自己盯着数据发现问题。
AvioBook（泰雷兹集团旗下公司）在AWS上做了一套叫Connected Analytics的概念验证：把AvioBook Connect里的运行数据变成航司经理和签派员能用自然语言提问、并附上证据的回答。AvioBook Connect是它的航班和地面运行沟通平台，2018 年就已投入航司使用，当前API平台于 2025 年上线。
问题在于，AvioBook Connect把每个航班组织成一个flightroom，也就是每班一个实时聊天室。API会往房间里推送飞机变更、延误、新飞行计划、登机进度等自动化事件，同时保留围绕这些事件的对话。但AvioBook说，收集数据和使用数据是两回事：历史数据超过一个短窗口就不容易访问，每个问题都意味着手动查询或提数据提取请求，而航司利润薄，很少养得起专职分析团队。
这篇发布在AWS机器学习博客上的文章由AvioBook产品经理Petra Lafond和Tech Lead Maarten Cardinaels与AWS合写，描述的是概念验证和设计思路，不是已全面交付的产品。
延误一分钟大约 20 美元，2 分钟对中型航司约合每月 24 万美元
AvioBook给出的估算基线是：延误在登机口每分钟大约让航司损失 20 美元，燃油、机组成本、登机口费用、错过转机以及对当天其余航班的连锁影响都还没算进去。对一家每天飞 200 班的中型航司，如果调机是起飞环节的硬约束，平均调机时间缩短 2 分钟，一个月大约值 24 万美元。
文章还提到，夏季一个欧洲中型航司避免了超过 4000 小时的延误，其中 124 小时直接来自减少电话沟通和手动来回确认。AvioBook的说法是，随着流程合规更稳定，还能再找回 2 到 4 分钟，对同一家航司最高约合每月 49.5 万美元。这些数字是AvioBook和AWS在文章里给出的，属于公司自述。
两个角色各配一个智能体，底层数据按航司隔离
Connected Analytics要做两件事：用自然语言和运行数据对话，以及做智能体式的延误代码校验。AvioBook没有做一个通用助手，而是按角色拆成两个智能体：面向航司经理的负责历史分析和延误代码校验，面向OCC签派员的负责实时运行查询和中断影响。每个智能体限定在自己的角色范围内，用户只能接触自己有权使用的那个。
身份绑定是设计重点。每个问题都绑定到一家航司的身份和一家航司的数据。请求从前端经Amazon API Gateway的WebSocket API进来，Lambda Authorizer用Amazon Cognito校验JWT；通过验证的请求触发Lambda，调用AgentCore runtime上对应的智能体。runtime用JWT做入站认证，token里带用户身份，所以每个请求都绑定到具体航司账号和一个AWS区域。
运行链路是：智能体先更新AgentCore memory里的会话上下文，再通过AgentCore Gateway以MCP调用工具；工具由Lambda实现，向Amazon Athena发查询；Athena从AWS Glue Data Catalog解析表结构，扫描S3桶里按航司分区的Parquet数据。后台有Glue crawler和ETL作业把新来的JSON转成Parquet，并注册schema。
- AgentCore runtime提供部署智能体和MCP服务器的全托管计算环境。
- AgentCore memory让智能体记住过往交互，跨会话保持对话上下文。
- AgentCore Gateway作为智能体流量的单一安全入口，暴露MCP目标供智能体调用工具。
延误代码校验只给第二意见，不自动改
延误代码校验复用同一条数据访问路径：智能体把记录的延误代码和底层事件序列做对比，标出看起来不一致、或者本该填多个代码的情况，定位成供航司经理复核的"第二意见"，而不是自动改正。AvioBook解释，延误代码要进内部和外部报告，一个系统如果判定某个代码填错了，这就不只是分析问题，而是航司的合规问题，所以智能体的角色是支持判断，不是替人做判断。
AvioBook还说明了延误代码本身的局限：编码通常在时间压力下由一个人完成，主要归因于主导延误；即使允许填多个代码，导致主导延误的上游事件往往根本没被编码。代码可以按规则填对，但仍然误导对实际发生了什么的判断。
责任边界也写明了：每个回答都基于智能体检索到的运行数据，证据和回答一起呈现，用户可以追溯结论；智能体输出只是起点，由人复核并对运行决策负责。Connected Analytics位于飞机适航认证系统之外，是咨询性软件，不自行执行操作。
架构选择：按角色拆智能体、把数据访问做成MCP工具、复用现有AWS数据栈
AvioBook说，决定用AgentCore之前先评估了智能体编排、会话管理和工具访问的选项，结论是把AgentCore runtime、memory、Gateway当作不用自建的托管积木。随后与AWS进行了一周集中联合开发，搭出多智能体概念验证，验证了架构、数据访问模式和智能体设计，这也是AvioBook有信心把Connected Analytics产品化的原因。
几个设计选择被明确点出：按角色建不同的智能体，让每个智能体的范围窄、工具相关，行为比一个什么都能做的助手更容易推理；把数据访问作为MCP工具通过AgentCore Gateway暴露，让智能体和数据层解耦，以后加工具和数据源不必重新架构；数据继续放在S3配Athena和Glue Data Catalog，用AvioBook已在用的AWS数据服务，而不是另起一套分析栈。
下一步是主动告警
文章说，同一套基础自然延伸到主动异常告警：用户定义关心的条件，比如某个流程耗时过长、某个站点正在形成延误模式、或某个航班画像需要关注，智能体盯着进来的数据，匹配到就抛出来。这会把Connected Analytics从回答问题扩展到在人们想到问题之前把该问的问题提出来。
因为数据已经通过AgentCore Gateway里的模块化工具可访问，告警可以复用查询智能体用的同一数据层，不需要单独的数据管道。模块化设计也留了空间给新角色加智能体、接入新数据源。