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

拜耳作物科学的育种决策依赖基因组、田间试验、影像、环境条件和模型输出等多源数据，团队在作物、区域和团队之间运行数百套机器学习模型配置，每轮运行都要求可复现、可治理。为此拜耳先建了 Connected Decision Engine（CDE）用于部署、编排、监控和复用 ML 工作流。随着使用量增长，瓶颈从"跑工作流"转向"理解工作流"：要解释一个结果，用户得自己拼凑 API、文档、元数据、仪表盘和日志中的上下文。Agentic Decision Engine（ADE）就是为填补这一缺口而建，它在 CDE 之上提供多智能体自然语言界面，由监督智能体把问题路由给专业智能体，专业智能体从对应系统取回上下文后直接给出答案。首阶段约 80% 的用户问题无需工程师介入即可解决。 ADE 运行在 Amazon Bedrock AgentCore 上，团队因此不必自建智能体托管、会话隔离和工具访问层。架构分四层：React 前端经 Microsoft Entra ID 身份代理进入智能体；GitHub Actions 构建容器镜像并推送至 Amazon ECR，再部署到 AgentCore runtime；团队在 runtime 上直接运行自有的 LangGraph 编排，由 Supervisor Agent 分类请求、选择专业智能体并在跨域问题时合并结果。数据面按职责拆分：DynamoDB 存 LangGraph checkpoint，Aurora PostgreSQL 存会话记录、用户反馈与分析数据，ElastiCache 做带 TTL 的响应缓存，S3 中的领域内容经 Amazon Titan Text Embeddings V2 嵌入后索引到 OpenSearch Serverless 供 RAG 使用，CloudWatch 采集运行时与应用遥测，AgentCore Gateway 把后端 API 以 MCP 工具形式暴露给智能体。 生产环境共运行 22 个专业智能体，各自绑定单一领域、工具和数据源。Domain Expert Agent 通过 RAG 回答概念性问题，Operational Agent 从 CDE 取实时工作流状态与结果，Troubleshooting Agent 分析运维遥测，Visualization Agent 生成图表或返回已有仪表盘。Models as Skill 模式把模型代码和文档转成技能定义存入中央注册表，使智能体基于模型实现而非通用模型知识作答。以"我昨天的表型工作流为什么失败"为例，监督智能体识别意图后转给 Troubleshooting Agent，后者经 AgentCore Gateway 读取 CloudWatch 遥测和 CDE API 状态，定位失败点并回传诊断，原本需要一小时以上手动查日志并等待工程师支持的诊断缩短到 10 分钟以内。 构建过程中有五个关键设计决策。其一，编排状态外置：AgentCore runtime 的隔离会话保留执行上下文，但不作为多步工作流的持久存储，ADE 把 LangGraph checkpoint 写入 DynamoDB，以便在扩缩容、重启或会话边界后恢复。其二，分离企业身份、网关访问与下游授权：用户身份沿用 Entra ID，服务间调用由 IAM 授权，AgentCore Gateway 出站授权负责访问下游 CDE 服务，Lambda 请求拦截器做自定义校验并传递下游工具所需的授权属性。其三，把模型选择视为接口契约：团队评估过一个开启推理模式的新模型版本，但其工具调用与结构化输出的组合与现有智能体实现不兼容，因此本次发布保留当前模型。其四，先控制工具面再控制提示词：CDE 管理超过 500 套模型配置，ADE 不按 API 逐个建 MCP server，而是把 O…