# 拜耳以22个专业智能体连接分析平台，保留原有执行管控

- Source: MechNext — https://mechnext.eu/zh/article/52-bayer-adds-22-agent-natural-language-access-to-its-analytics-platform
- Published: 2026-10-25
- Updated: 2026-10-25
- Category: Industry News
- Language: zh (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=pl, ?lang=ru)

> 据AWS案例介绍，拜耳作物科学在Amazon Bedrock AgentCore上构建了Agentic Decision Engine，以自然语言查询工作流状态、模型结果和故障原因。平台通过专业分工、只读工具、身份授权及监控支持生产运行。

据AWS发布的案例介绍，拜耳作物科学构建了Agentic Decision Engine（ADE），让用户以自然语言访问分析平台。该系统运行于Amazon Bedrock AgentCore，连接原有Connected Decision Engine（CDE）。后者继续承担受治理的分析执行职责，前者负责获取和组织回答所需的上下文。

CDE用于部署、编排、监控和复用机器学习工作流，同时保留执行历史与操作控制。分析范围包括基因组学、田间试验、影像、环境条件及模型输出。此前，相关信息分散在接口、文档、元数据、仪表板和日志中，ADE将这些来源接入自然语言交互。

### 以专业分工组织查询

ADE在生产环境中运行22个专业智能体。领域专家通过检索增强生成获取资料；操作智能体读取CDE工作流的状态和结果；故障排查智能体分析遥测；可视化智能体提供图表或仪表板。监督智能体根据问题选择专业角色，再汇总其返回的结果。

系统还采用Models as Skill模式，把模型代码及文档转化为集中注册的技能。这样，关于模型行为的回答可以依据实现细节。CDE管理着超过500种模型配置，代码、文档与运行数据因此都属于ADE需要连接的上下文。

用户界面采用React，并通过Entra ID身份代理接入。LangGraph承担监督编排，负责请求分类、专业智能体选择和结果合并。交付流程使用GitHub Actions构建镜像，推送至ECR，再部署到AgentCore Runtime。

数据存储按用途安排：Aurora PostgreSQL保存会话、反馈及分析数据，ElastiCache缓存响应。S3中的内容通过Titan Text Embeddings V2和OpenSearch Serverless支持检索增强生成。CloudWatch收集遥测，为运行观察和故障分析提供信息。

### 会话延续与权限边界

拜耳选择AgentCore，考虑了托管会话隔离、经Gateway提供的IAM权限范围控制，以及对其LangGraph编排和模型选择的支持。会话在自身生命周期内保留上下文，系统同时另行持久化编排状态，以支持跨越单个会话的继续处理。

具体而言，ADE把LangGraph检查点存入DynamoDB，使流程在扩容、重启或跨会话边界后能够恢复。这里保存的是编排检查点，而用户会话、反馈和分析记录由其他存储承担。案例将这些机制分别列为架构组成部分。

身份与授权也分布在不同边界：Entra ID提供用户身份，IAM授权服务之间的调用，Gateway的出站授权控制下游CDE访问。Lambda请求拦截器验证请求并传递授权属性，团队与AWS领域专家共同明确了各边界的令牌契约。

生产系统采用最小权限、按智能体限定的只读工具和结构化输出验证。故障排查智能体可以读取遥测与工作流状态，却不能修改工作流；领域专家不能调用与其职责无关的接口。回答所依据的运行信息来自检索到的CDE数据及遥测。

### 工具接入与模型选择

ADE通过向AgentCore Gateway注册OpenAPI规范，将REST操作公开为MCP工具，无须为每个接口单独建立服务器。系统提供约20个API工具，并将工具分配给相应专业智能体，以限制输入令牌数量和工具选择范围。

Gateway还支持面向更大工具目录的语义搜索。案例报告，其每个API的集成开销减少了超过99%。这一数字描述的是该项目报告的集成结果，系统架构仍包含权限设置、专业角色划分以及下游访问控制等具体安排。

模型升级没有直接进入发布版本。拜耳测试发现，较新版本开启推理后，与ADE已实现的工具调用和结构化输出组合不兼容，因此保留原有模型。发布选择依据的是该应用中这些功能的实际配合情况。

可视化最初所需的处理逐渐涵盖数据检索、图表选择、重试、错误处理以及是否生成仪表板的决定，因此被设为专业智能体。它在AgentCore Code Interpreter中使用matplotlib和Plotly，通过S3交换数据，并可返回Amazon Quick或Power BI相关资产。

### 从诊断速度到可观测性

故障排查智能体经Gateway读取CloudWatch遥测和CDE状态。根据案例报告，诊断时间从超过一小时缩短到十分钟以内。该结果属于此次部署的报告数据，其上下文是对既有工作流状态和遥测的联合查询。

监控设计也经历了修正：异常处理程序曾使智能体错误在监控中看起来像成功执行。团队随后增加CloudWatch失败指标和告警，让工具错误、请求限流、模型超时以及结构化输出验证问题能够被明确记录和识别。

跟踪数据及调用日志覆盖监督智能体与专业智能体。结合新增失败指标，团队能够观察编排和专业处理中的运行情况。案例所描述的生产准备不仅包括生成回答，也包括使真实失败在监控中得到反映。

成本归因结合Bedrock应用推理配置文件、请求元数据、模型调用日志和IAM主体信息，估算交互成本，并按智能体、功能、请求及身份识别令牌消耗来源。这些记录把交互行为与模型使用情况联系起来。

可视化与操作智能体消耗的令牌最多，涉及MCP工具及多次工具调用。遥测还发现，稳定输入被反复发送，却没有使用提示词缓存。团队缓存稳定的提示词前缀后，据来源报告，输入令牌成本降低了20%至30%。

### 受限开放与生产准备

拜耳先向受限用户群开放ADE，已有超过100名育种人员、分析师、研究人员、数据科学家和工程师使用。案例称，第一阶段约80%的问题无需工程师介入便得到解决。ADE也能够承载第三方智能体。

这些用户通过自然语言访问状态、结果、模型行为与故障信息。执行治理仍由CDE承担，ADE负责连接问题与相关资料。因此，案例中的使用成效对应的是这一分析平台及其已接入的专业角色、工具和运行上下文。

AWS Unified Operations安排了指定技术客户经理和生成式AI领域专家工程师，从设计阶段持续支持到生产。他们每周参加三次技术站会，将AWS服务知识与对拜耳运行环境的了解带入架构讨论和问题处理。

团队进行了Critical Workload及采用Generative AI Lens的Well-Architected审查。拜耳据此强化告警，采用不可变的版本化镜像，启用ECR推送时扫描，并增加镜像生命周期策略。这些措施构成案例所述的上线准备工作。

负载测试还暴露了一个导致空响应的网络问题，该问题在上线前得到修复。案例报告共有35项阻塞问题被解决。上线准备因而同时涉及镜像管理、告警、服务行为以及负载下的响应情况。

### 上线后的支持与后续方向

上线后，领域专家继续参与问题分诊和运行审查。ADE的重要CloudWatch告警，包括针对特定智能体的告警，已接入AWS Incident Detection and Response，使事件响应人员能够利用已有工作负载背景开展处理。

据来源说明，告警触发后，AWS事件管理工程师会在五分钟内介入。遇到潜在或正在发生的安全事件时，AWS Security Incident Response工程师提供支持。此处的五分钟描述人员介入，并未表述为故障解决时间。

拜耳已经具备智能体之间的通信，并在探索混合云互操作性，希望不同环境中的智能体能够发现彼此并通信，而不依赖手工配置。这一跨环境方向仍属于探索，不能视为已完成的混合云部署。

团队还计划在CDE多轮工作流中，结合已有自定义安全检查评估Bedrock Guardrails。架构与决策的所有权始终由拜耳保留；指定领域专家和技术客户经理协助依据AWS服务行为检验设计，并把工作负载知识延续到生产运行。