拜耳作物科学如何借助 AWS Unified Operations，在 Amazon Bedrock AgentCore 上构建智能体决策引擎

AWS ML Blog 2026-10-26T15:53:00.044559

植物育种决策依赖的数据横跨基因组学、田间试验、图像、环境条件和模型输出。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 主要看重三项能力：托管运行时，为每个用户会话提供隔离；通过 Amazon Bedrock AgentCore 的 AgentCore Gateway 实现 IAM（身份与访问管理）范围内的工具访问，让身份验证和授权留在智能体代码之外；以及框架无关的设计，团队可以自带 LangGraph 编排，自行选择模型。为准备上线并在之后持续运营 ADE，Bayer 与 AWS Unified Operations 展开合作。

项目配备了专属技术客户经理（TAM）和生成式 AI 领域专家工程师（DSE），他们从设计阶段一直参与到生产上线，相当于 ADE 团队的延伸成员。TAM 作为 Bayer 的战略顾问，对 Bayer 的运营模式和业务优先级已有深入理解；DSE 则带来 AWS 在生成式 AI 领域的专业经验。团队每周开三次技术例会，在会上评审并做出设计决策。DSE 通过参与逐步掌握了 ADE 工作负载和 Bayer 团队的工作方式，因此给出的技术建议既符合 AWS 服务的实际行为，也贴合 Bayer 的具体场景。本文就沿这条路径展开：先讲 ADE 的架构，再讲建设过程中做出的五个设计决策，然后讲为上线所做的准备工作，最后讲上线后如何运维。

架构总览

ADE 分为四层：用户体验层、智能体编排层、专家智能体层，以及这些智能体调用的工具和数据源（图 1）。

用户通过 React 网页前端访问 ADE，请求先经过 Microsoft Entra ID 的身份代理，再到达各智能体。GitHub Actions 负责构建智能体容器镜像、推送到 Amazon Elastic Container Registry（Amazon ECR），并部署到 AgentCore runtime——这是 Amazon Bedrock AgentCore 的一项能力。Amazon Bedrock AgentCore runtime 承载智能体运行，由于该 runtime 不绑定特定框架，团队可以直接在上面跑自己基于 LangGraph 的编排逻辑。

团队选 LangGraph，是因为它用显式的图结构表达控制流，并支持为多步工作流做检查点（checkpoint）。LangGraph 负责编排整个工作流，入口是一个 Supervisor Agent（主管智能体）：它先对每个请求分类，再挑选合适的专家智能体，当一个问题横跨多个领域时，还把各自的结果汇总起来。

数据面按职责拆分。Amazon DynamoDB 存放 LangGraph 的检查点状态；Amazon Aurora PostgreSQL 存放会话记录、用户反馈和分析数据；Amazon ElastiCache 负责缓存智能体响应，并设置过期时间（TTL）。

Amazon S3 中的领域内容由 Amazon Titan Text Embeddings V2 生成嵌入向量，并存入 Amazon OpenSearch Serverless 建立索引，供检索增强生成（RAG）使用。Amazon CloudWatch 负责采集运行时和应用遥测数据。AgentCore Gateway 把后端 API 以模型上下文协议（MCP）工具的形式开放给智能体调用，同时把认证和授权留在智能体代码之外，不侵入业务逻辑。

图 1：基于 Amazon Bedrock AgentCore 的智能体决策引擎架构

ADE 目前在生产环境运行着 22 个专业智能体，每个智能体只负责一个领域，配有各自的工具和数据源。举例来说：领域专家智能体通过 RAG 回答概念性问题；运营智能体从 CDE 获取实时工作流状态和结果；故障排查智能体分析运营遥测数据；可视化智能体负责生成图表或返回已有仪表盘。

拜耳的“模型即技能”（Models as Skill）模式针对具体客户，把模型代码和文档转换成技能定义，存入中央注册表。这样一来，智能体回答模型相关问题时，依据的是模型的实际实现，而不是通用的大模型知识。

当育种人员问：“我昨天的表型分析工作流为什么失败了？”，主管智能体会先判断意图，再把请求转给故障排查智能体。后者从 CloudWatch 读取该工作流的遥测数据，通过 AgentCore Gateway 调用 CDE API 获取状态，定位故障点，最后经由主管智能体返回诊断结果（图 2）。整个过程中，育种人员不需要自己去翻日志。有了故障排查智能体，过去要花一个多小时手动查日志、等工程师支持才能拿到的诊断，现在 10 分钟内就能完成。

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

走向生产环境的五个设计决策

AWS 统一运营团队的技术客户经理（TAM）和交付解决方案工程师（DSE）作为工作组成员参与了以下决策，而不是事后才被拉进来救火。这样拜耳可以在拍板之前，先拿每个设计去验证 AWS 服务的实际行为，同时架构的所有权和最终决定权始终留在拜耳手里。

1.

原文：

1. 将编排状态外部化，不要假设运行时是无状态的

AgentCore 运行时提供相互隔离的会话，在会话生命周期内跨多次调用保留执行上下文。但这种上下文并不是多步骤工作流的持久化存储。ADE 将 LangGraph 的检查点写入 DynamoDB，这样图（graph）在横向扩展、重启或跨会话边界后仍能恢复，而不必依赖某一个执行环境始终在线。

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

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

Bayer 统一采用 Microsoft Entra ID 作为用户身份来源，ADE 的各服务之间则用 AWS 原生机制互相授权。团队没有强行让同一个令牌跨越所有信任边界，而是为每个边界单独配置机制。

团队与 DSE 一起梳理了每一跳的令牌约定。

原则： 智能体系统中的身份故障往往集中在用户身份、智能体身份和工具身份之间的切换点。应当在每一跳明确定义签发方（issuer）、受众（audience）、声明（claims）、作用域（scopes）和凭证有效期，而不是把一个对某个边界有效的令牌直接复用到下一个边界。

3. 把模型选择当作接口契约

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

原则：对于使用工具的智能体来说，模型选型受制于整个接口：工具调用、结构化输出、流式行为、推理特性、延迟、配额可用性，以及特定于模型的请求语义。新模型并不自动就是可直接替换的选项。

4. 先控制工具面，别让它反过来控制提示词

CDE 管理着 500 多个模型配置。如果为每个 API 单独建一个 MCP 服务器，会带来部署、认证和版本管理的额外负担。ADE 的做法是把 OpenAPI 规范注册到 AgentCore Gateway，由它把这些 REST 操作暴露为 MCP 工具。这样，新增或修改一个 API 就变成改 schema 和网关配置，而不用再部署一个新服务器。

工具 schema 和描述也会消耗输入 token，还会和用户请求、检索到的上下文争抢空间。ADE 按专家智能体来限定工具范围，而不是把完整目录塞给每个智能体。目录较大时，AgentCore Gateway 支持语义化工具搜索，智能体可以按需找到相关工具，不必每轮都加载整个目录。

原则：按智能体限定工具目录。每一条工具定义都会增加 token，并扩大模型的决策空间。

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

可视化一开始只是被其他智能体调用的一个工具。随着能力增长，它需要自己的数据检索、图表选择逻辑、重试、错误处理，还要判断是生成新图表，还是返回已有的仪表板。团队把它拆出来，做成了专门的 Visualization Agent。

这个智能体在 AgentCore Code Interpreter 里用 matplotlib 和 Plotly 按需生成图表，并通过 Amazon S3 交换数据。AgentCore Code Interpreter 是 Amazon Bedrock AgentCore 的一项能力，提供沙箱化的代码执行环境。如果预制仪表板更合适，它就返回已有的 Amazon Quick 或 Power BI 资产。

原则：工具执行的是有边界的操作。当一项能力开始涉及状态、重试、规划、策略或呈现方式的决策时，就应该把它建成智能体。

为 ADE 的生产上线做准备

随着构建工作逐步走向上线，团队的重点从设计转向了可运维性：如何发现智能体故障、如何归因推理成本、如何加固部署。

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

在 supervisor 架构里，一次用户请求会被拆成一条链路：多次模型调用、工具调用和智能体之间的交接（handoff）。即使每个 HTTP 请求都成功，最终答案也可能出错。ADE 就直接踩过这个坑：应用的异常处理器捕获了智能体错误，返回的响应却被监控系统当成了成功。团队用 DSE 复现问题后，在故障路径里加了自定义 CloudWatch 指标，并针对智能体特有的状态设置告警：工具调用错误、限流、模型超时，以及结构化输出校验失败。追踪（trace）和调用日志会跟踪每一次请求，贯穿 supervisor 和各个专家智能体。

原则是：把传输成功和任务成功区分开。智能体可观测性应该能回答三个问题——任务是否完成、是哪个智能体或工具改变了结果、响应是否来自预期的数据源。

成本归因：把账单归因和请求级遥测结合起来

一次 ADE 请求可能调用多个模型和工具，所以光看账户级的 Amazon Bedrock 支出，无法解释单位经济性（unit economics）。团队和 DSE 一起设计了归因方案，用三种机制回答不同的问题：

三者结合，团队就能估算每次交互的成本、找出昂贵的智能体，并判断 token 消耗到底来自提示词、检索到的上下文，还是工具定义。实践中，依赖 MCP 工具、需要多次工具调用的 Visualization 智能体和 Operational 智能体消耗的 token 最多。同样的遥测还发现，在上线准备期间有一个工作负载存在大段重复的输入前缀，而提示词缓存（prompt cache）却完全没有被命中。

对于支持的模型，把固定不变的指令和工具定义放进可缓存的前缀提示词（prompt prefix）里，可以减少重复的输入处理，从而降低延迟和 token 成本。ADE 通过缓存这段稳定的前缀，把输入 token 成本压低了 20% 到 30%。

安全与上线准备

IAM 角色按每个智能体的职责做了权限划分。Troubleshooting Agent 可以读取诊断所需的运营数据，但无权修改工作流；Domain Expert Agent 能查询自己的检索索引，但不能调用无关的 CDE API。

目前在生产环境中，ADE 的智能体响应受以下机制约束：

Bayer 还计划评估 Amazon Bedrock Guardrails，作为这些控制措施之上的又一层防护，与 CDE 多轮工作流中已有的自定义安全检查形成互补。

上线前，Unified Operations 与 ADE 团队一起做了关键工作负载评审（Critical Workload Review），并用生成式 AI 视角（Generative AI Lens）做了 Well-Architected 评审。由于 DSE 团队此前已经很了解这套工作负载，两场评审都聚焦 ADE 特有的故障模式、容量风险和部署缺口，而不是泛泛的最佳实践。

评审发现的问题包括：主管智能体和专家智能体之间的故障可见性存在缺口、容器镜像标签可变、镜像溯源能力有限、缺少漏洞扫描。团队的应对措施是加强告警、改用不可变版本化镜像、在 Amazon ECR 中启用推送即扫描（scan on push），并为不再使用的镜像配置生命周期策略。

DSE 还与团队一起复核了扩缩容和配额需求。负载测试既验证了应用本身及其服务配额，也暴露出一个网络故障模式——该故障会导致返回空响应，团队在正式上线前完成了修复。到上线时，团队与 Unified Operations 一起跟踪并解决了 35 个阻塞项。

上线、运维与后续计划

Bayer 没有一次性向全组织开放 ADE，而是先面向一个受限群体（gated group）发布。

上线以来，拜耳作物科学（Bayer Crop Science）已有 100 多名用户使用 ADE，包括育种人员、分析师、研究人员、数据科学家和工程师。除了 22 个专用智能体，ADE 还对外提供约 20 个 API 工具，并且随着功能扩展，还能托管第三方智能体。这些 API 通过 AgentCore Gateway 统一暴露，而不是为每个 API 单独配一台服务器，单个 API 的集成工作量因此减少了 99% 以上。在第一阶段，ADE 在没有工程师介入的情况下解决了约 80% 的用户问题。

CDE 仍然是受治理管控的分析执行层。ADE 在它之上加了一层自然语言入口，用户可以直接询问工作流状态、结果、模型行为和失败原因，不必了解每个底层系统在哪里、怎么用。

此后，这项合作的重点从上线准备转向日常运营。DSE 继续与团队定期沟通，所以问题排查和运营复盘都能基于对 ADE 的已有了解展开，不需要重新熟悉一遍。ADE 的关键 CloudWatch 告警（包括前文提到的智能体专属告警）已接入 AWS Incident Detection and Response（事件检测与响应服务）。一旦告警触发，AWS 的事件管理工程师会在 5 分钟内介入，并且从该工作负载的现有上下文入手，而不是从零开始排查。安全方面，出现潜在或正在发生的安全事件时，AWS Security Incident Response 的工程师会为团队提供支持。这样，ADE 的运维问题和安全问题都有 AWS 的监控与响应兜底。

智能体之间的通信已经打通，拜耳接下来的重点是混合云环境下的智能体互操作。团队正在探索：运行在不同环境中的智能体，如何在不做手动配置的情况下互相发现并通信。

结语

拜耳并没有用 ADE 取代原有的分析平台，而是让 CDE 更容易查询、更容易运维。大部分生产化的工作都不在提示词里，而在别处：持久化状态、身份边界、工具权限范围、任务级可观测性、成本归属，以及上线前的各项准备。架构和上述每一项决策，都由拜耳自己掌握。

关于作者

Subbu Dandamudi 是 Bayer 研发部门的 MLOps 负责人。他带领团队开发可扩展平台和 AI 能力，在构建互联决策引擎（Connected Decision Engine，CDE）并将其演进为代理决策引擎（Agentic Decision Engine，ADE）的过程中发挥了关键作用，推动 AI 驱动的创新在研发各部门加速落地。

Dr. Leo de Melo 是 Bayer Crop Science 的资深机器学习工程师，通过可扩展平台、代理系统和高级分析，帮助塑造 AI 驱动的研发未来。他拥有计算机科学和计算数学背景，专注于构建 AI 和数据平台，让研究人员能够将复杂数据转化为可落地的洞察，加速科学发现。

Mahnoor Hussain 是一位高级解决方案架构师，专攻生成式 AI 和云架构。她帮助客户将新兴能力转化为可用于生产的解决方案，覆盖代理系统、治理、安全和云运维等领域，推动生成式 AI 真正落地。她的工作重点是帮助组织从实验阶段走向企业级采用。工作之余，Mahnoor 喜欢陪伴家人和旅行。

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

Sai Pavan Kasani 是 AWS 的生成式 AI 领域专家工程师。作为技术顾问和客户代言人，他帮助团队把生成式 AI 的概念验证推进到生产环境，尤其关注智能体（agentic AI）类负载。随着客户的生成式 AI 应用规模扩大，他也协助他们优化推理、控制成本。工作之余，Sai 喜欢探访新的咖啡馆，也喜欢陪伴家人。

拜耳作物科学（Bayer Crop Science）构建了智能体决策引擎（Agentic Decision Engine，ADE），这是一个运行在 Amazon Bedrock AgentCore 上的多智能体平台。育种人员、分析师和研究人员可以用自然语言向他们的分析平台提问。本文介绍 ADE 的架构、五个设计决策，以及团队如何借助 AWS Unified Operations 将其推向生产环境。

查看原文