
拜耳以22个专业智能体连接分析平台,保留原有执行管控
据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服务行为检验设计,并把工作负载知识延续到生产运行。