How Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operations

拜耳作物科学如何基于Amazon Bedrock AgentCore与AWS统一运营构建智能决策引擎 | 人工智能

拜耳作物科学如何基于Amazon Bedrock AgentCore与AWS统一运营构建智能决策引擎

作物育种决策依赖于涵盖基因组学、田间试验、影像数据、环境条件和模型输出的多源数据。拜耳作物科学针对不同作物、地区和团队，运行数百种机器学习（ML）模型配置，每次运行都需要可重复且受控。为满足这一需求，拜耳构建了连接决策引擎（CDE），这是一个用于部署、编排、监控和复用机器学习工作流的系统。CDE为育种专家、分析师、研究人员、数据科学家和数据工程师提供了统一的分析运行方式，同时保留执行历史和操作控制。

随着应用规模扩大，瓶颈从运行工作流转移到理解工作流。解释结果需要从API、文档、元数据存储、仪表板和日志中拼接上下文。如果用户想了解工作流为何失败、模型的作用或结果来源，仍需知道要检查哪个系统。为弥补这一差距，拜耳构建了智能决策引擎（ADE），这是基于CDE的多智能体自然语言接口。监督智能体将每个问题路由给专业智能体，专业智能体从相关系统检索上下文，用户无需遍历操作堆栈即可获得答案。在第一阶段，ADE在无工程师介入的情况下解决了约80%的用户问题。

ADE运行在Amazon Bedrock AgentCore上，这是AWS用于构建、连接和优化智能体的规模化服务，支持任意框架或模型。AgentCore使团队能够专注于智能体行为，而非构建和运营自己的智能体托管、会话隔离和工具访问层。三个AgentCore功能促成了这一选择：隔离每个用户会话的托管运行时、通过AgentCore网关实现的AWS IAM作用域工具访问（Amazon Bedrock AgentCore的一项功能），该功能将认证和授权移出智能体代码，以及框架无关的设计，使团队能够使用自己的LangGraph编排和模型选择。

为准备ADE的上线及后续运营，拜耳启用了AWS统一运营。此次合作提供了指定的技术账户经理（TAM）和生成式AI领域专家工程师（DSE），他们从设计到生产阶段作为ADE团队的延伸进行协作。作为拜耳的战略顾问，TAM对拜耳的运营模式和业务优先级有深入理解。DSE则带来了AWS上的生成式AI领域专业知识。每周三次技术站会中，团队审查并做出设计决策。DSE深入了解ADE工作负载及拜耳团队的运作方式，因此技术指导既反映AWS服务行为，也结合拜耳的业务背景。本文将记录这一历程：ADE架构、构建过程中做出的五个设计决策、为生产环境准备平台的工作，以及上线后的运营方式。

架构概览

ADE 由四层组成：用户体验层、代理编排层、专业代理层，以及代理调用的工具和数据源（图1）。用户通过 React Web 前端访问 ADE，请求需经过 Microsoft Entra ID 身份代理后才能到达代理。GitHub Actions 构建代理容器镜像，推送到 Amazon Elastic Container Registry（Amazon ECR），并部署到 Amazon Bedrock AgentCore 的 AgentCore 运行时环境。

Amazon Bedrock AgentCore 运行时环境托管代理，由于该运行时环境与框架无关，团队可以直接在其上运行基于 LangGraph 的编排系统。团队选择 LangGraph 是因为其基于显式图结构的控制流和多步骤工作流的检查点机制。LangGraph 编排工作流，以 Supervisor Agent 作为入口点，对每个请求进行分类，选择专业代理，并在问题涉及多个领域时合并结果。数据平面按职责划分：Amazon DynamoDB 存储 LangGraph 检查点状态，Amazon Aurora PostgreSQL 存储会话记录、用户反馈和分析数据，Amazon ElastiCache 缓存代理响应并设置生存时间（TTL）。Amazon Simple Storage Service（Amazon S3）中的领域内容通过 Amazon Titan Text Embeddings V2 嵌入，并在 Amazon OpenSearch Serverless 中建立索引以实现检索增强生成（RAG）。Amazon CloudWatch 捕获运行时和应用遥测数据。AgentCore 网关以 Model Context Protocol（MCP）工具的形式向代理暴露后端 API，并将身份验证和授权逻辑保留在代理代码之外。

图1：基于 Amazon Bedrock AgentCore 的 Agentic Decision Engine 架构

ADE 在生产环境中运行 22 个专业代理，每个代理专注于特定领域并拥有独立的工具和数据源。例如，Domain Expert Agent 通过 RAG 回答概念性问题，Operational Agent 从 CDE 获取实时工作流状态和结果，Troubleshooting Agent 分析运行时遥测数据，Visualization Agent 生成图表或返回现有仪表板。针对特定客户的“模型即技能”模式将模型代码和文档转换为存储在中心注册表中的技能定义，使代理能够根据模型实现而非通用模型知识回答模型相关问题。

当育种者询问“为什么我的表型分析工作流昨天失败了？”时，Supervisor Agent 会识别意图并将请求路由到 Troubleshooting Agent。该代理通过 AgentCore 网关从 CloudWatch 读取工作流遥测数据，并通过 CDE API 获取工作流状态，定位故障点后通过 Supervisor 返回诊断结果（图2）。育种者无需直接搜索日志。借助 Troubleshooting Agent，原本需要手动搜索日志并等待工程师支持超过一小时的诊断流程，现在可在 10 分钟内完成。

图2：ADE 请求流程：意图分类、缓存查询、专业代理路由和响应

路向生产的五大设计决策

统一运营 TAM 和 DSE 作为工作组成员参与了以下决策，而非事后作为升级点。这使拜耳能够在承诺采用方案前，针对 AWS 服务行为测试每个设计，同时保持对架构和最终决策的掌控权。

1. 将编排状态外部化而不将运行时视为无状态

AgentCore 运行时提供隔离会话，可在会话生命周期内的多次调用之间保持执行上下文。该上下文不是多步骤工作流的持久化存储。ADE 将 LangGraph 检查点写入 DynamoDB，使图在扩展事件、重启或会话边界后能够恢复，而无需依赖某个执行环境持续可用。

原则：使用运行时会话进行主动执行，将恢复或重建工作流所需的状态持久化到耐用服务中。

2. 企业身份、网关访问和下游授权分离

拜耳采用 Microsoft Entra ID 作为用户身份标准，而 ADE 的服务通过 AWS 原生机制相互授权。团队没有强制在每个信任边界使用统一令牌，而是为每个边界设计了独立的机制。

Entra ID 仍是用户身份的来源。AWS 身份和访问管理 (IAM) 负责服务间调用的授权。AgentCore 网关的出站授权处理对下游 CDE 服务的访问。一个请求拦截器 AWS Lambda 函数执行自定义验证，并传递下游工具所需的授权属性。团队与 DSE 在每个跳转点上协商了令牌契约。

原则：代理系统中的身份失败通常集中在用户身份、代理身份和工具身份之间的转换点。应在每个跳转点定义颁发者、受众、声明、作用域和凭证生命周期，而不是在下一个边界重复使用仅对前一个边界有效的令牌。

3. 将模型选择视为接口契约

在构建过程中，团队评估了启用了推理模式的新版本模型。对于该版本，ADE 依赖的工具使用和结构化输出组合与其代理的实现方式不兼容。DSE 确认了该限制，团队因此在发布中保留了当前模型。

原则：对于使用工具的代理，模型选择受完整接口约束：工具调用、结构化输出、流式行为、推理功能、延迟、配额可用性和模型特定请求语义。更新的模型不会自动成为即插即用的替代品。

4. 在工具控制提示之前控制工具表面

CDE 管理超过 500 种模型配置。每个 API 配置专用的 MCP 服务器会增加部署、认证和版本管理的开销。ADE 而是将 OpenAPI 规范注册到 AgentCore 网关，网关将 REST 操作暴露为 MCP 工具。添加或修改 API 变为模式和网关配置变更，而非新服务器部署。

工具模式和描述也会消耗输入令牌，并与用户的请求和检索的上下文竞争。ADE 通过专业代理限定工具访问，而非为每个代理提供完整目录。对于更大规模的目录，AgentCore 网关支持语义工具搜索，使代理能够在每次交互中无需加载完整目录即可找到相关工具。

原则：按代理限定工具目录。每个工具定义都会增加令牌消耗并扩展模型的决策空间。

5. 将复杂功能从工具提升到代理

可视化最初是作为其他代理调用的工具而存在的。随着其发展，它需要拥有自己的数据检索、图表选择逻辑、重试机制、错误处理，并决定是生成图表还是返回现有仪表板。团队将其迁移至专用的可视化代理。该代理通过 AgentCore Code Interpreter（Amazon Bedrock AgentCore 提供的沙箱代码执行环境），使用 matplotlib 和 Plotly 生成按需图表，并通过 Amazon S3 与之交换数据。当预构建仪表板是更优选择时，代理会返回现有的 Amazon Quick 或 Power BI 资产。

原则：工具执行有界操作。当某种能力开始拥有状态、重试机制、规划、策略或展示决策时，应将其建模为代理。

为 ADE 的生产环境做准备

随着构建接近发布阶段，重点从设计转向可操作性：检测代理故障、归因推理成本、强化部署。

可观测性：衡量任务失败，而不仅是异常

监督器架构将一个用户请求转化为模型调用、工具调用和代理交接的链条。即使每个 HTTP 请求都成功，最终答案仍可能是错误的。ADE 直接遇到了这种情况：应用程序异常处理器捕获了代理错误并返回了监控系统计为成功的响应。在 DSE 重现问题后，团队在失败路径中添加了自定义 CloudWatch 指标，并为代理特定条件（如工具调用错误、限流、模型超时和结构化输出验证失败）设置了告警。追踪和调用日志会跟随每个请求穿越监督器和专用代理。

原则：区分传输成功与任务成功。代理可观测性应展示任务是否完成、哪个代理或工具改变了结果，以及响应是否使用了预期来源。

成本归因：将计费归因与请求级遥测结合

一个 ADE 请求可能调用多个模型和工具，因此账户级的 Amazon Bedrock 花费无法解释单位经济性。团队与 DSE 一起设计了归因方法，采用三种机制来回答不同问题。Amazon Bedrock 应用推理配置文件将计费模型使用归因于特定应用或工作负载。请求元数据和模型调用日志将令牌使用与特定代理、功能或请求关联。IAM 主体归因增加了身份维度。这些机制共同使团队能够估算每次交互的成本、识别昂贵的代理，并确定提示、检索上下文或工具定义是否驱动令牌使用。实际上，依赖 MCP 工具和多次工具调用的可视化代理和运营代理消耗了最多的令牌。

相同的遥测数据在发布准备期间揭示了一个工作负载，其特征是存在大量重复输入前缀且没有提示缓存活动。对于支持的模型，将稳定的指令和工具定义放置在可缓存的提示前缀中，可以减少重复输入处理，从而降低延迟和令牌成本。对于 ADE 来说，缓存稳定的提示前缀使输入令牌成本降低了 20-30%。

安全性与发布就绪性

IAM角色的权限范围限定于每个代理的职责。故障排除代理可以读取诊断所需的运行数据，但无法修改工作流程。领域专家代理可以查询其检索索引，但不能调用无关的CDE API。目前在生产环境中，ADE代理的响应受到最小权限原则的管控，每个代理仅能访问只读工具，代理响应需通过结构化输出验证，且答案基于检索到的CDE数据和遥测信息，而非开放式生成。拜耳还计划评估Amazon Bedrock Guardrails作为额外的控制层，与CDE多轮对话流程中已使用的自定义安全检查形成补充。

上线前，统一运营团队与ADE团队共同进行了关键工作负载审查和架构最佳实践审查（包含生成式AI视角）。由于DSE已了解该工作负载，两次审查重点针对ADE特有的故障模式、容量风险和部署缺口，而非通用最佳实践。审查结果发现监督代理和专家代理之间故障可见性不足、容器镜像标签可变、镜像可追溯性有限以及缺少漏洞扫描等问题。团队随后采取了更强的告警机制、不可变的版本化镜像、在Amazon ECR中实现推送即扫描，并为未使用镜像制定生命周期策略。

DSE还与团队共同审查了扩展性和配额需求。负载测试验证了应用及其服务配额，并暴露了一种网络故障模式会导致空响应，团队在生产事件前已修复该问题。到上线时，团队已与统一运营团队共同解决35个阻碍项。

上线、运营与后续计划

拜耳选择将ADE先向受限用户组开放，而非一次性向整个组织全面开放。自上线以来，拜耳作物科学部门的100多名用户已使用ADE，包括育种专家、分析师、研究人员、数据科学家和工程师。在22个专家代理的支持下，ADE对外提供约20个API工具，并可通过AgentCore网关托管第三方代理。通过AgentCore网关暴露API而非为每个API部署专用服务器，使每个API的集成开销降低了99%以上。在第一阶段，ADE在无工程师介入的情况下已解决约80%的用户问题。

CDE仍然是分析任务的受控执行层。ADE在其之上增加了自然语言交互层，使用户无需了解底层系统的具体位置或接口，即可查询工作流状态、结果、模型行为和故障信息。

随后的工作重点从上线准备转向持续运营。DSE继续与团队保持沟通，问题分类和运营审查基于对ADE的现有了解，而非重新熟悉系统。ADE的关键CloudWatch告警（包括前述的代理专用告警）已接入AWS事件检测与响应服务。当告警触发时，AWS事件管理工程师将在5分钟内介入，并基于工作负载上下文开展处理，而非从零开始。在安全方面，AWS安全事件响应团队在潜在或实际安全事件期间为团队提供支持，因此ADE在运营和安全问题上均具备AWS监控与响应覆盖能力。

在代理到代理的通信功能已经实现的基础上，拜耳公司接下来的焦点是混合云代理互操作性。团队正在探索如何让运行在不同环境中的代理能够自主发现并相互通信，而无需人工配置。

结论

拜耳公司并未用ADE取代其原有的分析平台，而是让CDE的查询和操作更加便捷。大部分生产工作都超出了提示范围：包括持久化状态、身份边界、工具作用域、任务级可观测性、成本归属以及发布就绪性。拜耳公司拥有该架构并主导了所有相关决策。通过AWS统一运营团队指定的DSE和TAM，团队在设计阶段将这些决策与AWS服务行为进行验证，并将相同的上下文延续到生产环境。

如需了解更多内容，请查阅Amazon Bedrock AgentCore、Amazon Bedrock成本归属、AWS Well-Architected生成式AI指南以及AWS统一运营相关资源。

作者谨此感谢石思杰（Sijie Shi）、乔治·戈梅斯（Jorge Gomes）、纳文·雷迪（Naveen Reddy）、伊戈·丰塞卡（Iago Fonseca）、马特乌斯·席尔瓦（Mateus Silva）和苏希米塔·贾鲁古拉（Sushimitha Jarugula）在ADE的设计、开发和发布过程中所做的贡献。

关于作者

'"`