拜耳作物科学如何基于 Amazon Bedrock AgentCore 与 AWS Unified Operations 构建智能体决策引擎

拜耳作物科学的植物育种决策依赖基因组、田间试验、影像、环境条件和模型输出等多类数据。其 Connected Decision Engine（CDE）负责部署、编排、监控和复用机器学习工作流，让育种人员、分析师、研究人员、数据科学家和数据工程师以一致方式运行分析，并保留执行历史与运维控制。随着使用规模扩大，瓶颈从“跑工作流”转向“理解工作流”：要解释一个结果，用户得从 API、文档、元数据存储、仪表盘和日志中拼凑上下文，还得知道该查哪个系统。

ADE 的定位与首阶段效果

为填补这一缺口，拜耳构建了 Agentic Decision Engine（ADE），即 CDE 之上的多智能体自然语言界面。Supervisor Agent 将每个问题路由给专业智能体，专业智能体从相关系统检索上下文，用户无需自行浏览运维栈即可获得答案。原文称，第一阶段 ADE 约 80% 的用户问题无需工程师介入即可解决。

架构与运行方式

ADE 分为用户体验、智能体编排、专业智能体和工具与数据源四层。用户通过 React 前端访问，请求经 Microsoft Entra ID 的身份代理后到达智能体；GitHub Actions 构建容器镜像并推送至 Amazon ECR，再部署到 Amazon Bedrock AgentCore runtime。团队选择 LangGraph 是看重其显式图控制流和多步工作流检查点能力，Supervisor Agent 作为入口完成意图分类、专业智能体选择和跨域结果合并。

数据面按职责拆分：DynamoDB 存 LangGraph 检查点状态，Aurora PostgreSQL 存会话记录、用户反馈和分析数据，ElastiCache 以 TTL 缓存智能体响应，S3 中的领域内容经 Amazon Titan Text Embeddings V2 嵌入并索引到 OpenSearch Serverless 用于 RAG，CloudWatch 采集运行时与应用遥测。AgentCore Gateway 将后端 API 以 MCP 工具形式暴露给智能体，并把认证授权留在智能体代码之外。

ADE 在生产环境运行 22 个专业智能体，各自限定一个领域并配有自己的工具和数据源。例如 Domain Expert Agent 通过 RAG 回答概念性问题，Operational Agent 从 CDE 获取实时工作流状态与结果，Troubleshooting Agent 分析运维遥测，Visualization Agent 生成图表或返回已有仪表盘。Models as Skill 模式把模型代码和文档转成技能定义存入中央注册表，使智能体依据模型实现而非通用模型知识作答。原文举例：育种人员问“我的表型工作流昨天为什么失败”，Supervisor 分类意图后路由给 Troubleshooting Agent，后者读取 CloudWatch 遥测并经 AgentCore Gateway 从 CDE API 取状态，定位失败点后经 Supervisor 返回诊断；原本需一小时以上人工翻日志并等待工程师支持的诊断，现在不到 10 分钟。

选择 AgentCore 与 AWS Unified Operations 的原因

原文列出三项 AgentCore 能力：隔离每个用户会话的托管运行时；通过 AgentCore Gateway 实现的 IAM 范围工具访问，使认证授权不进入智能体代码；框架无关设计，允许团队自带 LangGraph 编排和自选模型。拜耳同时引入 AWS Unified Operations，获得指定的技术客户经理（TAM）和生成式 AI 领域专家工程师（DSE），从设计到生产作为 ADE 团队的延伸；每周三次技术站会用于评审和设计决策。

编辑部观察

这是一篇由 AWS 侧讲述的客户架构案例，80% 问题免工程师介入、诊断从一小时以上缩短到 10 分钟均为拜耳与 AWS 方面的说法，原文未给出样本量、统计口径或独立验证。对计划搭建类似系统的团队，可核查的点包括：专业智能体的领域边界是否与现有系统职责对齐、工具访问的授权是否真正留在智能体代码之外、以及缓存 TTL 与检查点状态在故障排查时是否会造成信息不一致。原文提到后续还将展开五项设计决策和生产准备、上线后运维，这些内容在本次材料中未完整给出。