Bayer Crop Science 如何基于 Amazon Bedrock AgentCore 和 AWS Unified Operations 构建智能体决策引擎

作物育种决策依赖于涵盖基因组学、田间试验、图像、环境条件和模型输出的数据。Bayer Crop Science 会针对不同作物、地区和团队，使用这些数据运行数百种机器学习（ML）模型配置，每次运行都需要可重复且受治理。为满足这一要求，Bayer 构建了 Connected Decision Engine (CDE)，用于部署、编排、监控和复用 ML 工作流。CDE 为育种人员、分析师、研究人员、数据科学家和数据工程师提供了一致的分析运行方式，同时保留执行历史记录和运营控制。

随着采用范围扩大，瓶颈从运行工作流转向理解工作流。要解释某个结果，就得从 API、文档、元数据存储、控制面板和日志中拼凑上下文。用户想知道工作流为何失败、模型做了什么或结果来自哪里，仍然必须知道该检查哪个系统。为弥合这一差距，Bayer 构建了 Agentic Decision Engine (ADE)，这是一个基于 CDE 的多智能体自然语言界面。主管智能体会将每个问题路由给专用智能体，专用智能体从相关系统检索上下文，用户无需浏览运营技术栈即可获得答案。在第一阶段，ADE 无需工程师介入即可解决约 80 percent 的用户问题。

ADE 运行在 Amazon Bedrock AgentCore 上。这项 AWS 服务支持使用任何框架或模型大规模构建、连接和优化智能体。借助 AgentCore，团队可以专注于智能体行为，而不必自行构建和运维智能体托管、会话隔离和工具访问层。三项 AgentCore 功能促成了这一选择：托管运行时可隔离每个用户会话；通过 AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）实现由 AWS Identity and Access Management (IAM) 限定范围的工具访问，将身份验证和授权置于智能体代码之外；以及与框架无关的设计，使团队能够采用自己的 LangGraph 编排方式和模型选择。

为准备发布并在此后运营 ADE，Bayer 与 AWS Unified Operations 合作。此次合作配备了一位指定技术客户经理（TAM）和一位生成式 AI 领域专家工程师（DSE），从设计到投入生产，他们都作为 ADE 团队的延伸参与工作。作为 Bayer 的战略顾问，TAM 对 Bayer 的运营模式和业务重点已有深入了解。DSE 则具备 AWS 生成式 AI 领域的专业知识。团队每周举行三次技术站会，共同审查并作出设计决策。DSE 深入了解了 ADE 工作负载及 Bayer 团队的运作方式，因此提供的技术指导兼顾 AWS 服务行为和 Bayer 的具体情况。本文将介绍这一历程：ADE 架构、构建期间作出的五项设计决策、为平台投入生产所做的准备工作，以及发布后的运营方式。

架构概览

ADE 分为四层：用户体验层、智能体编排层、专业智能体层，以及这些智能体调用的工具和数据源（图 1）。用户通过 React Web 前端访问 ADE，请求先经过 Microsoft Entra ID 身份代理，然后才到达智能体。GitHub Actions 构建智能体容器映像，将其推送到 Amazon Elastic Container Registry (Amazon ECR)，再将其部署到 AgentCore 运行时——这是 Amazon Bedrock 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 Gateway 将后端 API 作为模型上下文协议 (MCP) 工具提供给智能体，并将身份验证和授权逻辑置于智能体代码之外。

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

ADE 在生产环境中运行 22 个专业智能体，每个智能体专注于一个领域，并配有自己的工具和数据源。例如，Domain Expert Agent 通过 RAG 回答概念性问题。Operational Agent 从 CDE 检索实时工作流状态和结果。Troubleshooting Agent 分析运行遥测数据。Visualization Agent 生成图表或返回现有仪表板。面向客户的 Models as Skill 模式会将模型代码和文档转换为技能定义，并存储在中央注册表中，因此智能体能够根据模型的实际实现，而非通用模型知识，回答特定于模型的问题。

当育种人员询问“我的表型分析工作流昨天为什么失败了？”时，主管智能体会对意图进行分类，并将请求路由到 Troubleshooting Agent。该智能体通过 AgentCore Gateway 读取 CloudWatch 中的工作流遥测数据以及 CDE API 返回的状态，找出故障点，并通过主管智能体返回诊断结果（图 2）。育种人员无需直接搜索日志。借助 Troubleshooting Agent，过去需要花一个多小时手动查找日志并等待工程师支持的诊断工作，现在不到 10 分钟即可完成。

图 2：ADE 请求流程：意图分类、缓存查找、专业智能体路由和响应

通往生产环境的五项设计决策

Unified Operations TAM 和 DSE 作为工作团队成员参与了以下决策，而非事后才作为升级处理的联系人介入。这样，Bayer 就能在确定设计方案之前，依据 AWS 服务的实际行为逐项验证，同时保留对架构的所有权和最终决策权。

1. 将编排状态外置，不要把运行时视为无状态

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

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

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

Bayer 采用 Microsoft Entra ID 作为用户身份标准，而 ADE 的服务则使用 AWS 原生机制相互授权。团队没有强行让一个令牌跨越所有信任边界，而是为每个边界指定了各自的机制。

Entra ID 仍是用户身份的来源。AWS Identity and Access Management (IAM) 用于授权服务间调用。AgentCore Gateway 出站授权负责处理对下游 CDE 服务的访问。请求拦截器 AWS Lambda 函数执行自定义验证，并传递下游工具所需的授权属性。团队与 DSE 一起梳理了每一跳的令牌契约。

原则：代理系统中的身份验证故障往往集中在用户身份、代理身份和工具身份之间的转换环节。应为每一跳定义签发方、受众、声明、作用域和凭证有效期，而不是在一个边界有效的令牌上重复使用，并将其用于下一个边界。

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

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

原则：对于使用工具的代理，模型选择受完整接口约束：工具调用、结构化输出、流式处理行为、推理功能、延迟、配额可用性以及特定于模型的请求语义。较新的模型并不一定能直接替换旧模型。

4. 在工具集影响提示之前先加以控制

CDE 管理着 500 多种模型配置。为每个 API 部署一个专用 MCP 服务器，会增加部署、身份验证和版本管理方面的开销。ADE 则将 OpenAPI 规范注册到 AgentCore Gateway，由其将 REST 操作作为 MCP 工具提供。添加或更改 API 时，只需修改架构和网关配置，无需部署新服务器。

工具架构和描述也会消耗输入令牌，并与用户请求和检索到的上下文竞争令牌。ADE 按专业代理划分工具范围，而不是将完整目录提供给每个代理。对于较大的工具目录，AgentCore Gateway 支持语义工具搜索，因此代理无需在每轮对话中加载整个目录，也能找到相关工具。

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

5. 将复杂能力从工具升级为代理

可视化最初是由其他代理调用的一种工具。随着功能不断扩展，它需要自行检索数据、选择图表、重试、处理错误，并决定是生成图表还是返回现有仪表板。团队将其拆分为专门的可视化代理。该代理在 AgentCore Code Interpreter 中使用 matplotlib 和 Plotly 按需生成图表。AgentCore Code Interpreter 是 Amazon Bedrock AgentCore 的一项功能，提供沙盒化的代码执行环境；代理通过 Amazon S3 与其交换数据。如果预先构建的仪表板更合适，代理就会返回现有的 Amazon Quick 或 Power BI 资源。

原则：工具执行的是范围明确的操作。当一项能力开始负责状态、重试、规划、策略或呈现决策时，应将其建模为代理。

为 ADE 做好生产准备

随着构建工作逐渐迈向发布，重点从设计转向可运维性：检测代理故障、归因推理成本，并强化部署。

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

主管架构会将一项用户请求转化为一系列模型调用、工具调用和代理交接。即使每个 HTTP 请求都成功，最终答案仍可能有误。ADE 直接遇到了这一问题：应用程序异常处理程序捕获代理错误并返回响应，而监控系统将其计为成功。团队在 DSE 的协助下复现了该问题后，在失败路径中添加了自定义 CloudWatch 指标，并针对代理特定条件设置警报：工具调用错误、节流、模型超时和结构化输出验证失败。跟踪记录和调用日志会贯穿主管代理和各个专业代理，记录每项请求的处理情况。

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

成本归因：结合账单归因与请求级遥测数据

一次 ADE 请求可能会调用多个模型和工具，因此仅查看账户级 Amazon Bedrock 支出，无法说明单位经济效益。团队在 DSE 的协助下设计了归因方案，使用三种机制来回答不同问题。Amazon Bedrock 应用推理配置文件可将计费的模型用量归因至应用或工作负载。请求元数据和模型调用日志可将令牌用量关联到特定代理、功能或请求。IAM 主体归因则增加了身份维度。结合这些信息，团队可以估算每次交互的成本、找出成本高昂的代理，并判断令牌用量是由提示、检索到的上下文还是工具定义所驱动。实际上，依赖 MCP 工具和多次工具调用的可视化代理与运维代理消耗的令牌最多。

同一遥测数据还在发布准备期间发现了一项工作负载：它包含一个反复出现的大型输入前缀，但没有使用提示缓存。对于受支持的模型，将稳定的指令和工具定义放入可缓存的提示前缀，可以减少重复输入处理，从而降低延迟和令牌成本。对于 ADE，缓存稳定的提示前缀将输入令牌成本降低了 20–30 percent。

安全与发布准备

IAM 角色的权限范围与各个代理的职责相匹配。故障排查代理可以读取诊断所需的运行数据，但无法修改工作流。领域专家代理可以查询其检索索引，但无法调用无关的 CDE API。目前在生产环境中，ADE 通过以下方式管理代理响应：遵循最小权限原则、为每个代理配置范围受限的只读工具访问权限、对代理响应进行结构化输出验证，并确保回答基于检索到的 CDE 数据和遥测信息，而非开放式生成。Bayer 还计划评估 Amazon Bedrock Guardrails，将其作为这些控制措施的附加层，以补充 CDE 多轮工作流中已采用的自定义安全检查。

在发布前，Unified Operations 与 ADE 团队一起开展了关键工作负载审查，并结合 Generative AI Lens 进行了 Well-Architected 审查。由于 DSE 已熟悉该工作负载，两项审查都针对 ADE 的具体故障模式、容量风险和部署缺口，而非泛泛地讨论最佳实践。审查发现的问题包括：监督代理与专用代理之间的故障可见性不足、容器镜像标签可变、镜像可追溯性有限，以及缺少漏洞扫描。团队对此采取了相应措施，包括强化告警、使用不可变的版本化镜像、在 Amazon ECR 中启用推送时扫描，以及为未使用的镜像设置生命周期策略。

DSE 还与团队审查了扩展和配额要求。负载测试验证了应用程序及其服务配额，并暴露出一种会返回空响应的网络故障模式；团队在生产活动开始前修复了这一问题。到发布时，团队已与 Unified Operations 一起跟踪并解决了 35 个阻碍项。

发布、运营与后续计划

Bayer 以受限用户组的方式发布 ADE，而不是一开始就向整个组织开放。自发布以来，Bayer Crop Science 的 100 多名用户使用了 ADE，其中包括育种家、分析师、研究人员、数据科学家和工程师。除 22 个专用代理外，ADE 还提供约 20 种 API 工具，并可在扩展过程中托管第三方代理。通过 AgentCore Gateway 而非为每个 API 配置专用服务器来开放这些 API，使每个 API 的集成开销降低了 99% 以上。在第一阶段，ADE 已在无需工程师介入的情况下解决了约 80% 的用户问题。

CDE 仍是受治理的分析执行层。ADE 在其上增加了自然语言层，用户无需了解每个底层系统的位置或界面，即可询问工作流状态、结果、模型行为和故障情况。

随后，合作重点从发布就绪转向持续运营。DSE 会继续与团队定期沟通，因此问题分类处理和运营审查可以基于对 ADE 的既有了解开展，而不必重新熟悉情况。ADE 的关键 CloudWatch 告警（包括前文所述的代理专属告警）已接入 AWS Incident Detection and Response。告警触发时，AWS Incident Management Engineers 会在 5 分钟内介入，并直接基于该工作负载的背景情况开展工作，而非从头开始。在安全方面，AWS Security Incident Response 工程师会在潜在或正在发生的安全事件期间为团队提供支持，因此 ADE 在运营和安全问题上都能获得 AWS 的监控与响应保障。

在代理间通信已经就绪后，Bayer 接下来将重点关注混合云代理互操作性。团队正在探索如何让运行在不同环境中的代理无需手动配置即可相互发现并通信。

结论

Bayer 并未用 ADE 取代其分析平台，而是让 CDE 更易于查询和运营。大部分生产工作都在提示词之外：持久化状态、身份边界、工具范围限定、任务级可观测性、成本归因和上线准备。Bayer 负责整体架构及上述每项决策。通过 AWS Unified Operations 与指定的 DSE 和 TAM 合作，团队在设计阶段根据 AWS 服务的实际行为验证这些决策，并将相同的背景信息延续到生产环境中。

作者谨向 Sijie Shi、Jorge Gomes、Naveen Reddy、Iago Fonseca、Mateus Silva 和 Sushimitha Jarugula 致谢，感谢他们为 ADE 的设计、开发和发布所作的贡献。

关于作者

Subbu Dandamudi

Subbu 是 Bayer 研发部门的 MLOps 负责人。他领导可扩展平台和 AI 能力的开发，并在构建 Connected Decision Engine (CDE) 及其演进为 Agentic Decision Engine (ADE) 的过程中发挥了关键作用，以加速研发领域由 AI 驱动的创新。

Dr. Leo de Melo

Leo 是 Bayer Crop Science 的高级机器学习工程师，致力于通过可扩展平台、智能体系统和高级分析，塑造 AI 驱动的研发未来。他拥有计算机科学和计算数学背景，专长于构建 AI 和数据平台，帮助研究人员将复杂数据转化为可执行的洞见，并加速科学发现。

Mahnoor Hussain

Mahnoor 是一名高级解决方案架构师，专攻生成式 AI 和云架构。她帮助客户将新兴能力转化为可投入生产的解决方案，并在智能体系统、治理、安全和云运营等方面实现生成式 AI 的运营落地。她的工作重点是帮助组织从实验阶段迈向企业级应用。工作之余，Mahnoor 喜欢与家人共度时光和旅行。

Ram Pamidimukkala

Ram 是 AWS 的高级技术客户经理，专攻生成式 AI、智能体工作负载、数据分析、多云和云运营。他帮助组织高效、安全地设计、现代化和迁移工作负载至 AWS 云。作为 Unified Operations 的一员，他的工作重点是构建具有韧性的架构，兼顾性能、成本优化和长期可持续性。

Sai Pavan Kasani

Sai 是 AWS 的生成式 AI 领域专家工程师。作为技术顾问和客户权益倡导者，他帮助团队将生成式 AI 概念验证项目投入生产，尤其专注于智能体 AI 工作负载。他还与客户合作，优化推理并提升成本效率，以支持其生成式 AI 应用扩展。工作之余，Sai 喜欢探索新的咖啡馆并与家人共度时光。