이미지: AWS ML Blog
重复性工单曾令工程师疲于应付
Mobileye是一家自动驾驶领域企业，已向约1,200款车型供应超过2.3亿颗EyeQ系统级芯片。与这一规模相匹配的是，其内部数据采集与处理流水线每天要接收数千次行车记录会话，由此产生的状态查询请求络绎不绝。
问题在于，每次查询都是一项"劳动密集型"工作。工程师需要经过识别会话、交叉核对可视化工具、验证输出结果、查看日志等步骤才能给出答复，整个过程平均需要点击15次。全部支持工单中有66%属于这类模式化的状态查询。团队曾尝试用脚本或基于规则的自动化来解决，但面对实际请求千变万化的表达方式，效果并不理想。
从PoC验证到正式投产
团队在正式引入前先进行了概念验证（PoC）阶段，目标是工单分类准确率达到95%、响应时间控制在2分钟以内。该智能体使用Anthropic Claude基础模型，并通过Mobileye内部的LLM网关访问Amazon Bedrock。该网关负责管理模型访问的治理与配额。
其中的关键组件是MCP（Model Context Protocol）。通过MCP服务器，智能体可以在推理时实时调用行车数据处理平台的API。得益于此，系统不仅能完成简单分类，还能在2分钟内提供包含会话是否完成、错误详情、调试建议及日志链接等内容的完整答复。
生产架构：打通本地部署与云端
PoC成功后，最大的挑战在于Mobileye的内部工单系统仅在本地部署运行，AWS无法直接访问。为解决这一问题，团队设计了一套跨越两种环境的混合架构。
在本地部署一侧，本地编排器负责提取新工单，并将智能体生成的答复重新写回工单系统。在AWS云端一侧，AgentCore运行时以无服务器方式运行智能体，无需预置服务器即可自动应对流量激增。智能体的调用通过单次API请求完成。AgentCore可观测性功能会追踪从初始请求、MCP工具调用直至最终答复的全过程，记录会话指标、延迟、令牌使用量及调用链路。AWS Secrets Manager负责存储、轮换和检索智能体与后端系统所需的凭证，使终端用户无需直接处理任何凭证信息。
整体工作流分为四个步骤：①本地编排器提取工单，发送给AgentCore运行时中的智能体；②智能体通过MCP服务器实时查询会话数据，并通过LLM网关调用Claude，生成包含链接与建议的完整答复；③本地编排器将答复连同评论和标签一并写回工单系统；④AgentCore可观测性记录整个流程。
实际数据表现
正式投产后记录的数据如下：
- 整体成功率：98%（超出95%的目标）
- 响应时间：从数小时缩短至约1分钟（缩短90%）
- 自动化工单占比：全部工单的66%
- 月处理量：超过100件
Mobileye首席工程师Shay Margalit表示："借助AgentCore，工程师们从常规查询中夺回了数百小时的时间。"
从单一智能体走向全公司平台
成果得到验证后，新的问题随之出现。公司内大多数开发者并没有AWS凭证或基础设施访问权限，因此无法直接向AgentCore部署。为解决这一问题，Mobileye云基础设施团队搭建了一个内部智能体部署平台。
在该平台上，开发团队只需指定智能体代码以及所需的AgentCore功能（如内存、浏览器工具、代码解释器、可观测性、网关等）即可。云基础设施团队会负责配置全部基础设施，包括AWS IAM角色、Amazon S3存储、Amazon CloudWatch监控以及Amazon Cognito身份验证；开发者只需获取预先配置好的bedrock_agentcore.yaml文件，执行一条agentcore deploy命令即可完成部署。
局限性与未公开信息
信息来源中公布的数据与架构均基于Mobileye的内部环境。关于Amazon Bedrock AgentCore的定价及计费方式等成本结构，本次信息来源并未给出具体说明。此外，其本地连接方案是针对Mobileye特殊环境设计的，信息来源中也未包含关于通用适用方法的说明。
