拜耳如何把多Agent分析平台推向生产

Bayer Crop Science 给机器学习平台加了一层多智能体入口：用户直接问工作流为什么失败、结果从哪里来，系统负责找 API、查日志、读文档。第一阶段，约 80% 的用户问题无需工程师介入。

这个案例值得读的地方，在于它把 Agent 上线后的麻烦讲得比较具体：会话状态怎么保存，身份怎么跨系统传递，模型升级为什么会卡住，以及 HTTP 全部成功时，任务为什么仍然可能失败。

自然语言入口，应该接在什么样的平台上

Bayer 原有的 Connected Decision Engine（CDE）已经负责机器学习工作流的部署、编排、监控和复用，管理超过 500 个模型配置。育种分析涉及基因组、田间试验、影像和环境数据，每次运行都需要可重复、可追溯。

后来卡住用户的，是理解执行过程。回答一个失败原因，可能要同时翻 API、文档、元数据、仪表盘和日志。Agentic Decision Engine（ADE）就在这些系统之上增加了自然语言入口。

它的入口是 React 网页，请求先经过 Microsoft Entra ID 身份代理。Supervisor Agent 判断意图，再交给对应的专家 Agent；跨领域的问题由它汇总结果。生产环境共有 22 个专家 Agent，包括查知识的 Domain Expert Agent、查实时状态的 Operational Agent、分析故障的 Troubleshooting Agent，以及处理图表的 Visualization Agent。

例如，用户询问昨天的表型分析工作流为何失败，排障 Agent 会读取 CloudWatch 遥测，并通过 AgentCore Gateway 查询 CDE API。作者报告，这类诊断从过去超过 1 小时的查日志、等待工程师支持，缩短到了 10 分钟以内。

ADE 的作用，是让用户更容易查询和操作已有平台。

这里的基础很关键：CDE 已经具备执行历史、运行接口和治理能力，Agent 才有可靠的信息可查。另一个定制方案叫 Models as Skill，它把模型代码和文档转成技能定义，放入中央注册表，让回答依据具体实现，减少拿通用模型知识解释内部模型的偏差。

为什么状态、身份和工具要分别设计

ADE 运行在 Amazon Bedrock AgentCore 上，使用自带的 LangGraph 编排。AgentCore 提供会话隔离、托管运行环境和工具访问层，LangGraph 则负责显式流程图与检查点。

会话能保留执行上下文，但不能承担持久化恢复。ADE 把 LangGraph 检查点写入 DynamoDB，以便扩容、重启或跨会话后继续执行。Aurora PostgreSQL 保存会话记录、反馈和分析数据；ElastiCache 按 TTL 缓存回答。知识内容则从 S3 经 Amazon Titan Text Embeddings V2 向量化，进入 OpenSearch Serverless，供检索增强生成（RAG）使用。

身份同样分层处理：Entra ID 识别用户，IAM 授权服务间调用，AgentCore Gateway outbound authorization 处理下游 CDE 访问，Lambda 请求拦截器负责自定义校验和传递授权属性。团队逐跳确认令牌的 issuer、audience、claims、scopes 和凭证有效期，避免把上一层有效的 token 直接带到下一层。

工具接入也有取舍。团队把 OpenAPI 规范注册到 AgentCore Gateway，由网关将 REST 操作暴露成 Model Context Protocol（MCP）工具，减少逐个部署 MCP server 的工作。每个专家只拿自己需要的工具；工具目录更大时，网关支持语义工具搜索，避免每轮加载完整目录。

原因很直接：工具定义也消耗输入 token，还会增加模型选错工具的机会。

Visualization 最初只是一个工具，后来承担了数据获取、图表选择、重试和错误处理，团队才把它升级为独立 Agent。它在 AgentCore Code Interpreter 沙箱里运行 matplotlib、Plotly，通过 S3 交换数据，也可以直接返回已有的 Amazon Quick 或 Power BI 仪表盘。

这种拆分有明确触发条件：能力开始自行管理多步决策，才需要独立编排。

上线最容易漏掉的，是「请求成功但任务失败」

团队曾测试一个开启 reasoning mode 的新版模型，却发现它的工具调用与结构化输出组合，不兼容 ADE 当时的实现，最终保留原模型发布。原文没有披露具体模型和版本，因此不能据此判断某个模型的普遍能力。

它能说明的是，升级 Agent 模型需要验证完整接口：tool calling、structured output、streaming、推理功能、延迟、配额以及请求语义。

监控也踩过类似的接口陷阱。应用捕获 Agent 异常后返回了响应，监控便把请求记为成功，实际任务却没有完成。团队随后在失败路径增加自定义 CloudWatch 指标，分别监控工具调用错误、限流、模型超时和结构化输出校验失败，并用 trace 和调用日志串起 Supervisor 与专家 Agent。

HTTP 成功，只能证明请求得到响应，不能证明用户的问题得到解决。

成本归因则组合了三类信息：Amazon Bedrock application inference profiles 归集应用或工作负载账单，request metadata 和 model invocation logging 关联具体 Agent、功能及请求，IAM principal attribution 补充身份维度。实际观察中，依赖 MCP 和多次工具调用的 Visualization、Operational Agent 消耗 token 最多。

他们还发现，大量稳定的输入前缀被重复处理，却没有使用 prompt cache。把固定指令和工具定义放进受支持模型的可缓存前缀后，输入 token 成本下降了 20–30%。这不是整个系统总成本下降的比例。

上线前，团队补上不可变的版本化镜像、Amazon ECR scan on push、镜像生命周期策略和更强的告警。GitHub Actions 负责构建镜像、推送 ECR 并部署到 AgentCore runtime。负载测试还发现过网络故障导致空响应的问题。最终，团队与 AWS Unified Operations 共同解决了 35 个上线阻塞项。

我的判断

我认可它对工程边界的处理。现有 Agent 工具按职责只读授权，排障 Agent 不能修改工作流，知识 Agent 不能随意调用其他 CDE API，再配合结构化输出校验和来源约束，适合先承担查询、解释和排障工作。Amazon Bedrock Guardrails 仍是计划评估的补充层，不能算作已经上线的能力。

但效果数字需要保留条件。原文报告超过 100 名用户使用 ADE，约 80% 的问题无需工程师介入，却没有说明问题总量、统计周期、正确率评估方式和问题难度分布。「无需工程师」不能直接当作「回答正确」。

通过 Gateway 接入约 20 个 API 工具，单 API 集成开销下降超过 99%，同样缺少工时口径和详细对照。它支持减少重复接入工作的方向，不能直接用于估算一般团队的收益。

这个案例还有组织投入前提。AWS Unified Operations 配置了 Technical Account Manager（TAM）和生成式 AI Domain Specialist Engineer（DSE），每周参加 3 次技术站会，并参与设计、上线审查和持续运维。关键告警接入 AWS Incident Detection and Response 后，Incident Management Engineers 会在 5 分钟内介入；安全事件另有 AWS Security Incident Response 支持。这些投入也是运行效果的一部分。

相比单 Agent 配少量工具，22 个专家带来了更多路由、状态和追踪工作。原文没有两种方案的对照数据，不能证明一般团队也该采用这个规模。它更有价值的经验，是按职责收窄工具权限，再根据实际复杂度决定是否拆分。

能拿来做什么

• 给已有分析平台增加 AI 问答时，可以先覆盖工作流状态、结果溯源和失败诊断。前端提供统一入口，后端保留原有权限与执行记录，让答案能够关联到具体运行和数据来源。
• 给 Node 服务接入工具调用模型时，把工具调用、结构化输出、流式响应和超时行为纳入升级验证。即使模型更新，也要确认原有调用链能够完整走通。
• 为 Agent API 增加任务结果指标，区分工具失败、输出校验失败和正常完成，并让一次请求能追踪到具体 Agent、工具和模型调用。捕获异常后返回响应的路径尤其需要检查。
• 优化 token 成本前，先按请求记录输入、输出及工具调用情况。确认固定指令和工具定义存在大量重复后，再评估所用模型的 prompt cache 支持，别直接套用案例中的降本比例。