拜耳作物科学如何基于 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% 的用户问题。

ADE 运行在 Amazon Bedrock AgentCore 上，这是一项 AWS 服务，可使用任意框架或模型大规模构建、连接和优化智能体。AgentCore 让团队能够专注于智能体行为，而不是自行构建和运营智能体托管、会话隔离和工具访问层。推动这一选择的 AgentCore 三项能力包括：隔离每个用户会话的托管运行时；通过 AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）实现由 AWS Identity and Access Management（IAM）限定范围的工具访问，从而将身份验证和授权保持在智能体代码之外；以及与框架无关的设计，让团队可以自带 LangGraph 编排并自行选择模型。

为准备上线并在之后运营 ADE，Bayer 与 AWS Unified Operations 合作。此次合作提供了一名指定的 Technical Account Manager（TAM）和一名生成式 AI Domain Specialist Engineer（DSE），他们从设计到生产阶段作为 ADE 团队的延伸开展工作。TAM 作为 Bayer 的战略顾问，带来了对 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 runtime，这是 Amazon Bedrock AgentCore 的一项能力。

Amazon Bedrock AgentCore runtime 托管智能体，并且由于该运行时与框架无关，团队直接在其上运行自己基于 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 模式将模型代码和文档转换为存储在中央注册表中的技能定义，因此智能体可以依据模型的实现而非通用模型知识来回答模型特定问题。

当育种者问：“为什么我的表型分析工作流昨天失败了？”，Supervisor 会分类意图并将请求路由到 Troubleshooting Agent。该智能体在 CloudWatch 中读取工作流的遥测数据，并通过 AgentCore Gateway 从 CDE API 读取其状态，识别故障点，并通过 Supervisor 返回诊断结果（图 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 改为向 AgentCore Gateway 注册 OpenAPI 规范，由后者将 REST 操作作为 MCP 工具暴露。添加或更改 API 变成了模式和网关配置的变更，而不是部署新服务器。

工具模式和描述也会消耗输入令牌，并与用户请求和检索到的上下文竞争。ADE 按专家智能体限定工具范围，而不是给每个智能体提供完整目录。对于更大的目录，AgentCore Gateway 支持语义工具搜索，因此智能体可以找到相关工具，而无需在每一轮加载整个目录。

原则：按智能体限定工具目录范围。每个工具定义都会增加令牌并扩大模型的决策空间。

5. 将复杂能力从工具提升为智能体

可视化最初是作为由其他智能体调用的工具。随着其不断扩展，它需要自己的数据检索、图表选择逻辑、重试、错误处理，以及决定是生成图表还是返回现有仪表板。团队将其迁移为专门的 Visualization Agent。该智能体在 AgentCore Code Interpreter 中使用 matplotlib 和 Plotly 按需生成图表，并通过 Amazon S3 与其交换数据；AgentCore Code Interpreter 是 Amazon Bedrock AgentCore 的一项能力，提供沙盒化的代码执行环境。当预构建仪表板是更好的答案时，该智能体会返回现有的 Amazon Quick 或 Power BI 资产。

原则：工具执行有界操作。当某项能力开始拥有状态、重试、规划、策略或呈现决策时，应将其建模为智能体。

为生产环境准备 ADE

随着构建工作迈向发布，重点从设计转向可运维性：检测智能体故障、归因推理成本，以及加固部署。

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

监督者架构会将一个用户请求转化为一连串模型调用、工具调用和智能体交接。即使每个 HTTP 请求都成功，最终答案仍可能出错。ADE 直接遇到了这一问题：应用异常处理器捕获了智能体错误，并返回了被监控计为成功的响应。团队与 DSE 复现该问题后，在失败路径内添加了自定义 CloudWatch 指标，并针对智能体特定条件设置了告警：工具调用错误、限流、模型超时和结构化输出验证失败。跟踪和调用日志会跨监督者和专家智能体跟踪每个请求。

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

成本归因：将账单归因与请求级遥测相结合

一个 ADE 请求可能调用多个模型和工具，因此账户级 Amazon Bedrock 支出无法解释单位经济性。团队与 DSE 设计了归因方法，使用三种机制回答不同问题。Amazon Bedrock 应用程序推理配置文件将计费的模型使用归因到应用程序或工作负载。请求元数据和模型调用日志将 token 使用与特定智能体、功能或请求关联起来。IAM 主体归因增加了身份维度。这些机制共同让团队能够估算每次交互的成本、识别高成本智能体，并确定是提示词、检索到的上下文还是工具定义推动了 token 使用。在实践中，依赖 MCP 工具和多次工具调用的 Visualization 和 Operational 智能体消耗了最多 token。

同一遥测在发布准备期间发现了一个具有大量重复输入前缀且没有提示缓存活动的工作负载。对于支持的模型，将稳定指令和工具定义放在可缓存的提示前缀中，可减少重复输入处理，从而降低延迟和 token 成本。对于 ADE，缓存稳定提示前缀将输入 token 成本降低了 20–30%。

安全与发布就绪

IAM 角色按每个 agent 的职责范围进行限定。Troubleshooting Agent 可以读取其诊断所需的运营数据，但无法修改工作流。Domain Expert Agent 可以查询其检索索引，但不能调用无关的 CDE API。在当前生产环境中，ADE 的 agent 响应受以下机制约束：最小权限、按每个 agent 限定的只读工具访问、对 agent 响应的结构化输出校验，以及基于检索到的 CDE 数据和遥测而非开放式生成的答案。Bayer 还计划评估 Amazon Bedrock Guardrails，作为这些控制之上的额外一层，补充 CDE 多轮工作流中已使用的自定义安全检查。

在发布之前，Unified Operations 与 ADE 团队一起开展了 Critical Workload Review 和带有 Generative AI Lens 的 Well-Architected 审查。由于 DSE 已经了解该工作负载，这两项审查都针对 ADE 的具体故障模式、容量风险和部署缺口，而非通用最佳实践。发现的问题包括：supervisor 与 specialist agent 之间的故障可见性缺口、可变的容器镜像标签、镜像可追溯性有限，以及缺少漏洞扫描。团队通过更强的告警、不可变的版本化镜像、Amazon ECR 中的推送时扫描，以及针对未使用镜像的生命周期策略予以应对。

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

发布、运营与后续步骤

Bayer 将 ADE 先发布给一个受控群体，而非一次性向整个组织开放。自发布以来，Bayer Crop Science 已有超过 100 名用户使用 ADE，包括育种人员、分析师、研究人员、数据科学家和工程师。除 22 个 specialist agent 外，ADE 还提供约 20 个 API 工具，并可在扩展过程中托管第三方 agent。通过 AgentCore Gateway 而非为每个 API 单独部署服务器来暴露这些 API，将每个 API 的集成开销降低了 99% 以上。在第一阶段，ADE 已在无需工程师介入的情况下解决了约 80% 的用户问题。

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

此后，合作重点从发布就绪转向持续运营。DSE 继续与团队会面，因此问题分诊和运营审查都从对 ADE 的既有了解出发，而无需重新熟悉。ADE 的关键 CloudWatch 告警（包括前文所述的 agent 专属告警）已接入 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 服务行为测试了这些决策，并将同样的上下文带入生产环境。

如需了解更多，请探索 Amazon Bedrock AgentCore、Amazon Bedrock 成本归因、AWS Well-Architected 生成式 AI 指南 以及 AWS Unified Operations。

作者感谢 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 的 Staff ML Engineer，他通过可扩展平台、代理系统和高级分析帮助塑造 AI 驱动的研发未来。他拥有计算机科学和计算数学背景，专长于构建 AI 和数据平台，使研究人员能够将复杂数据转化为可执行的洞察并加速科学发现。

Mahnoor Hussain

Mahnoor 是一名高级解决方案架构师，专注于生成式 AI 和云架构。她通过将新兴能力转化为涵盖代理系统、治理、安全和云运营的生产就绪解决方案，帮助客户将 GenAI 投入实际运营。她的工作重点是帮助组织从实验走向企业级采用。工作之余，Mahnoor 喜欢与家人共度时光和旅行。

Ram Pamidimukkala

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

Sai Pavan Kasani

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