拜耳作物科学上线多智能体查询系统：生产化核心难点在提示词之外

拜耳作物科学管理着数百种机器学习模型配置，覆盖基因组、田间试验、图像和环境数据。育种人员、分析师和研究员需要反复运行这些工作流，但真正的瓶颈不在执行——而在理解。一个育种人员想知道'我的表型分析工作流昨天为什么失败了'，他得知道去哪个系统查日志、哪个API看状态、哪份文档解释模型行为。拜耳在已有的Connected Decision Engine（CDE）之上构建了一个多智能体自然语言接口ADE，用22个专业智能体分别负责概念问答、工作流状态查询、故障诊断和可视化，由一个监督智能体做意图分类和路由。

AWS官方博客记录了五个设计决策，其中最值得注意的并非架构本身，而是生产化阶段暴露的真实失败。第一个：ADE的异常处理器捕获了智能体内部错误并返回了格式正常的响应，监控把这些计为成功。一个监督架构把一次用户请求变成模型调用、工具调用和智能体交接的链条，最终答案可以完全错误，而每个HTTP请求都返回200。团队在故障路径内加入自定义CloudWatch指标和针对特定条件的告警——工具调用错误、限流、模型超时、结构化输出校验失败——才把传输成功和任务成功区分开。第二个：团队在构建期间评估了带推理模式的新版模型，发现该版本的工具调用与结构化输出的组合和ADE的智能体实现不兼容。DSE确认了这一约束，团队保留了当前模型发布。文章将此总结为一条原则：对使用工具的智能体来说，模型选择受完整接口约束——工具调用、结构化输出、流式行为、推理特性、延迟、配额可用性和模型特定的请求语义，更新不等于即插即用。

其余三个决策同样指向生产化的具体摩擦：编排状态必须外化到持久存储（DynamoDB存LangGraph检查点），否则扩缩容或重启后多步工作流无法恢复；用户身份（Microsoft Entra ID）、服务间授权（AWS IAM）和下游工具访问（AgentCore Gateway出站授权）必须各自独立定义令牌契约，因为身份失败集中在用户身份、智能体身份和工具身份的转换处；工具目录必须按智能体作用域裁剪，因为每个工具定义都消耗输入令牌并扩大模型的决策空间——CDE管理超过500种模型配置，若每个API配一个专用MCP服务器，部署、认证和版本管理开销巨大，改为通过Gateway注册OpenAPI规范后，团队称每API集成开销降低超过99%。

文章自报的结果包括：ADE第一阶段约80%的用户问题无需工程师介入即可解决，故障诊断从超过一小时缩短到十分钟以内，提示前缀缓存使输入令牌成本降低20–30%，上线后超过100名用户使用了ADE。这些数据均为拜耳和AWS自报，未披露测量方法、样本量或对照条件。文章结论将核心经验概括为一句话：生产化工作的大部分在提示词之外——持久状态、身份边界、工具作用域、任务级可观测性、成本归因和上线就绪。