拜耳作物科学用22个专职智能体在Bedrock上搭建自然语言决策层
AWS官方博客披露，拜耳作物科学在Amazon Bedrock AgentCore上构建Agentic Decision Engine，第一阶段约80%的用户问题无需工程师介入即可解答；22个专职智能体，约20个API工具经网关暴露，每API集成开销降低99%以上。
AI解读：拜耳作物科学的CDE负责部署、编排、监控和复用机器学习工作流，管理超过500个模型配置。随着使用扩大，解释结果和排查失败的负担从运行工作流转向理解工作流。
ADE是多智能体自然语言界面：主管智能体分类请求并路由给专职智能体，后者从对应系统取上下文作答。
技术选择上，ADE用LangGraph做编排，检查点写入DynamoDB；经AgentCore Gateway把OpenAPI规范暴露为MCP工具；模型评估中因工具调用与结构化输出不兼容，保留原模型发布。
生产化重点包括任务级可观测性、按智能体归因推理成本、最小权限工具访问。稳定提示前缀缓存使输入token成本降低20%至30%；一个工作流排查诊断从超过1小时降到10分钟以内。
以上效果为拜耳与AWS在官方博客中的描述，未附独立评测或完整基准数据，80%和成本降幅的适用范围限于其内部部署与第一阶段。
AWS机器学习博客发文，介绍拜耳作物科学（Bayer Crop Science）如何在其Connected Decision Engine（CDE）之上构建Agentic Decision Engine（ADE），并运行在Amazon Bedrock AgentCore上。ADE用多智能体自然语言界面回答用户关于工作流状态、结果、模型行为和失败原因的问题，目标是不再让用户逐个系统查日志和文档。
博文称，ADE生产环境运行22个专职智能体，另暴露约20个API工具，第一阶段约80%的用户问题无需工程师介入即可解决；自上线以来，已有100多名拜耳作物科学的育种人员、分析师、研究人员、数据科学家和工程师使用。这些数字来自供应商与客户联合发布的文章，未见第三方验证。
CDE的瓶颈从执行转向解释
拜耳作物科学的育种决策依赖基因组、田间试验、图像、环境条件和模型输出等数据。CDE用于部署、编排、监控和复用机器学习工作流，管理超过500个模型配置，覆盖不同作物、地区和团队。
随着采用扩大，博文称瓶颈从运行工作流变成理解工作流：想知道某次运行为何失败、模型做了什么、结果来自哪里，用户仍需知道去API、文档、元数据存储、仪表盘和日志中的哪一个系统查看。ADE就是为缩短这段路径而建。
路由架构与部署
ADE分四层：React前端、智能体编排、专职智能体、以及智能体调用的工具和数据源。请求先经用于Microsoft Entra ID的身份代理。GitHub Actions构建容器镜像，推送到Amazon ECR，再部署到AgentCore Runtime；团队在该运行时上直接运行自有的LangGraph编排。
主管智能体作为入口，先分类请求、选择专职智能体，跨领域时合并结果。数据面按职责拆分：DynamoDB存LangGraph检查点，Aurora PostgreSQL存会话记录、用户反馈和分析数据，ElastiCache缓存带TTL的响应，S3中的领域内容用Titan Text Embeddings V2向量化并索引到OpenSearch Serverless供RAG使用，CloudWatch采集遥测。
22个专职智能体各自限定一个领域，拥有独立工具和数据源。例如，领域专家智能体通过RAG回答概念问题，运维智能体从CDE取实时工作流状态和结果，故障排查智能体分析运营遥测，可视化智能体生成图表或返回已有仪表盘。
- 博文示例：育种人员问“我昨天的表型工作流为什么失败”，主管智能体识别意图并路由给故障排查智能体；后者经AgentCore Gateway读取CloudWatch遥测和CDE API状态，定位失败点并返回诊断。
- 同一示例中，博文称原本需要超过1小时人工翻日志并等待工程师支持的诊断，现在不到10分钟。
五项设计取舍
博文列出五项设计决策，AWS Unified Operations的技术客户经理和生成式AI领域专家工程师作为工作组成员参与，拜耳保留架构所有权和最终决定权。
其一，编排状态外置。运行时提供会话隔离，但不作为多步工作流的持久存储；检查点写入DynamoDB，使图能在扩容、重启或会话边界后恢复。其二，身份分边界处理：用户身份由Entra ID负责，服务间调用由IAM授权，对下游CDE服务的访问由AgentCore Gateway出站授权处理，另有Lambda请求拦截器做自定义校验并传递授权属性。
其三，模型选择视为接口约束。团队评估过一个启用推理模式的新模型版本，但其工具使用与结构化输出的组合与ADE智能体实现不兼容，领域专家工程师确认限制后，该版本未用于本次发布。其四，控制工具面：不为每个API部署独立MCP服务器，而是把OpenAPI规范注册到AgentCore Gateway，将REST操作暴露为MCP工具；工具目录按专职智能体限定范围，避免每轮加载全部工具。
其五，复杂能力从工具升级为智能体。可视化最初是被其他智能体调用的工具，随着它需要自己的数据检索、图表选择、重试、错误处理以及“生成图表还是返回现有仪表盘”的判断，团队将其拆为专职可视化智能体，在AgentCore Code Interpreter沙箱中用matplotlib和Plotly生成图表，经S3交换数据。
生产准备：任务成败与成本归因
博文称，上线前的工作重心从设计转向可运维性。一个具体问题是：应用异常处理捕获了智能体错误并返回响应，监控将其计为成功，但最终答案可能是错的。团队与领域专家工程师复现后，在失败路径中加入自定义CloudWatch指标，并针对工具调用错误、限流、模型超时和结构化输出校验失败设置告警。
成本归因方面，一次ADE请求可能调用多个模型和工具，账户级Bedrock支出无法解释单位成本。团队用三类机制组合：Bedrock应用推理配置文件把计费用量归到应用或工作负载；请求元数据和模型调用日志把token使用关联到具体智能体、功能或请求；IAM主体归因增加身份维度。博文称，依赖MCP工具和多次工具调用的可视化与运维智能体消耗token最多。
博文还称，上线准备期间发现一个具有大量重复输入前缀且无提示缓存活动的工作负载；对支持的模型，把稳定指令和工具定义放入可缓存提示前缀后，ADE的输入token成本降低了20%至30%。
- IAM角色按智能体职责限定：故障排查智能体可读诊断所需运营数据但不能修改工作流；领域专家智能体可查其检索索引但不能调用无关CDE API。
- 生产环境采用只读工具访问、结构化输出校验，答案基于检索到的CDE数据和遥测，而非开放式生成。拜耳还计划评估Amazon Bedrock Guardrails作为额外控制层。
- 上线前审查发现的问题包括：主管与专职智能体间失败可见性缺口、容器镜像标签可变、镜像可追溯性有限、缺少漏洞扫描；对应措施包括更强告警、不可变版本化镜像、ECR推送时扫描和未使用镜像生命周期策略。
- 博文称上线前跟踪并解决了35个阻塞项；负载测试暴露了一个返回空响应的网络故障模式，并在生产活动前修复。
上线方式与后续计划
拜耳以受限群体方式上线ADE，未一次性向全组织开放。CDE仍是受治理的分析执行层，ADE在其上增加自然语言层。
运维方面，ADE的关键CloudWatch告警已接入AWS Incident Detection and Response，博文称告警触发后AWS事件管理工程师在5分钟内介入；安全事件由AWS Security Incident Response工程师支持。拜耳下一步关注混合云智能体互操作，探索不同环境中的智能体如何无需手工配置即可发现并通信。
- 博文称，通过AgentCore Gateway暴露API而非为每个API部署专用服务器，使每API集成开销降低99%以上。
- ADE目前可托管第三方智能体，配合22个专职智能体和约20个API工具扩展。