Trane 用 3 至 4 周把 20 分钟的多屏暖通诊断做成 20 秒自然语言问答，口径 60 倍，交付链条覆盖会话隔离、工具网关与可观测三段。 领域锚定 前置部署 Forward Deployed Engineer（FDE）能从这条复盘里直接拿走三件事：多角色应答的拆分方式、会话级隔离的做法、以及端到端追踪为什么必须第一天就打开。 Trane Technologies 是全球暖通空调（HVAC）设备厂商，年营收超过 210 亿美元，业务覆盖 100 多个国家，管理数百万台联网设备；Trane Cloud 汇聚这些设备的实时遥测。 这篇复盘由 Trane 数字工程总监 Senthil Chinnaiyan、数字系统架构师 Subbha Praveen Tadisetty 与亚马逊云科技解决方案架构师联名发表于 2026 年 9 月 22 日，属客户团队自述的一手交付材料。 前置部署 Forward Deployed Engineer（FDE）可据此评估自己项目里同类瓶颈的取数路径长度，而不是只看一个效果倍数。 原做法：一条运营答案要翻 20 分钟 改造前的瓶颈不在数据量，而在取数路径：设备遥测、性能分析、故障告警、能耗曲线分散在不同系统，运维人员要在多个仪表盘之间交叉核对、逐层下钻菜单，才能拼出一条可用结论；对 FDE 来说，这段路径长度就是交付要压缩的目标。 Trane 把这段耗时定为 20 分钟以上，即 1200 秒以上，并指出它带来的连锁代价是纠正动作被推迟，进而影响能效与运维表现。 更麻烦的是角色的分歧：现场技师要制冷剂压力、故障码与逐级排查流程，客户经理要在线率、省钱机会与组合趋势，楼宇业主要效率评分与可持续指标，而老系统对三种人给同一套界面。 前置部署 Forward Deployed Engineer（FDE）在客户现场最常遇到的就是这类需求：不是缺功能，而是同一条数据要按角色翻译成不同答案。 新做法：单轮自然语言问答，20 秒给答案 Trane 工程团队在 3 至 4 周内做出可演示原型，把 20 分钟的多屏诊断流程压缩成 20 秒的自然语言单轮交互；按 1200 秒对 20 秒计算，时间降幅 98.3%，口径为 60 倍的时间到洞察（time-to-insight）提升。 技术栈是 Amazon Bedrock AgentCore 加 Strands 框架，基础设施用 AWS Cloud Development Kit（AWS CDK）以代码形式声明；选型理由是 Strands 负责智能体行为与编排，AgentCore 负责托管运行时、记忆、工具网关与生产基础设施。 服务端并没有做成单体智能体，而是拆成 5 个各自受独立系统提示约束的专职助手：Resources Assistant 取资料、Knowledge Assistant 答设备原理与合规问题、Analytics Insights Assistant 查实时遥测、Expert Advisor 做方案选型、Navigation Assistant 给准确的链接与工具入口。 这一步是可扩展性的关键：新增数据源或工具只影响对应助手的发布管线，不必让全系统走同一次发布。 四个设计决定：网关、microVM、记忆、可观测 第一是工具网关。Trane 用 AgentCore Gateway 把 Trane Cloud 的内部 API 暴露成 MCP 兼容工具，按能力域分组并接入 Amazon OpenSearch Service；网关集中处理鉴权与 schema 转换，将来的 CRM 与工单系统走同一层接入，不用再写一遍对接逻辑。 第二是会话隔离。AgentCore runtime 把每个用户会话放进独立 microVM，各自有独立 CPU、内存与文件系统，会话结束即终止并清理；现场技师的会话与楼宇业主的会话在计算层面物理隔离。 第三是会话记忆。AgentCore memory 提供开箱即用的短期会话状态，过期生命周期为 90 天，替代了自建向量数据库与自定义上下文窗口管理代码。 第四是可观测。AgentCore Observability 把智能体发起的工具调用逐条追踪并落到 Amazon CloudWatch，用来在多步推理链里定位失败。 这四点对应 Trane 自己总结的四类架构挑战：集成、逻辑与执行的分离、跨排查会话的上下文、以及多工具编排下的失败定位。 前置部署 Forward Deployed Engineer（FDE）可以把这四条直接当成架构评审清单，逐条问自己的交付有没有对应能力。 为什么不自己搭：ECS 与 Lambda 的对比判据 团队在选型阶段评估过把智能体托管在 Amazon Elastic Container Service（Amazon ECS）和 AWS Lambda 上，结论是这条路要自己补三件事：会话隔离、自动扩缩容逻辑、以及按会话计费。 最终选定 AgentCore 的四条判据是：托管运行时省掉集群供给与闲置成本；内置会话记忆省掉外部向量库；AgentCore Gateway 的原生工具编排把现有内部 API 直接变成智能体可用工具；框架无关的设计让团队可以继续用 Strands SDK 而不被专有编排层锁定。 计费口径值得记一笔：Trane 只为会话期间的活跃算力付费，智能体工作流里常见的工具调用长等待不会累积成本。 前置部署 Forward Deployed Engineer（FDE）在做托管与自建对比时，可把 Trane 这四条判据当成分界条件，而不是结论。 上线节奏：先让要求最高的用户内测 Trane 的发布路径是三段：3 至 4 周做出原型并向干系人演示；先开放给内部现场技师做 beta；按反馈修准确率与可用性问题，再对外发布给 Trane Cloud 客户。 选现场技师当第一批用户是刻意的：他们跑的是最苛刻的诊断流程，真实条件下的准确率缺口最快暴露。 同一套智能体后端接进其他企业应用耗时不到 1 天，原因是微服务已解耦、工具统一收在 AgentCore Gateway 后面。 前置部署 Forward Deployed Engineer（FDE）如果只抄架构不抄这个节奏，最容易跳过内部内测，把准确率缺口直接暴露给客户。 一次真实的生产排障：从 traces 到缺失的 Secret 开发期间工具调用持续失败，且失败在单次调用里看不出规律。团队打开 CloudWatch 里的智能体追踪，确认多次调用是同一个失败模式，最终定位到 AWS Secrets Manager 里一个缺失的 Secret；补上后失败消失。 这个案例的价值在于失败归因的分支：一个错误答案可能来自缺失的 API 凭据、格式异常的工具体响应，或者模型幻觉，没有端到端追踪就分不清是哪一类。 请求链路的鉴权也值得对照：用户查询带 JWT 进入 AgentCore runtime，由 AgentCore Identity 按 OpenID Connect（OIDC）发现端点校验令牌，记忆层注入历史上下文，智能体再以 OAuth 2.0 机器对机器认证触发独立的 MCP Server，MCP Server 并行查 OpenSearch 等系统，最后由 Amazon Bedrock 上的 Claude 模型合成结果并通过 Server-Sent Events（SSE）流式返回。 护栏与权限：两层分工 应用层用 Amazon Bedrock Guardrails 做四件事：内容过滤拦有害输出、主题拒绝策略把智能体约束在运营域内、敏感信息过滤在返回前识别并脱敏 PII、提示攻击检测防越狱绕过系统提示。 基础设施层靠两条：Trane 的角色权限模型限制每个用户只能取授权范围内的数据；AgentCore runtime 的每会话 microVM 隔离在计算层降低跨租户数据泄漏风险。 前置部署 Forward Deployed Engineer（FDE）要记住这个分工：合规约束必须同时落在提示层与运行时层，只做其中一层不够。 Trane 自己承认的局限与未覆盖场景 第一，60 倍只有时间口径。文章说明该数字来自 Trane 内部与技师为期数周的基准测试，没有给出样本量、方差或分位数，也没有公布诊断准确率的百分比。 第二，评估门禁尚未上线。用 AgentCore Evaluations 以自动准确率阈值卡发布被列为下一步工作，也就是说当前的发布把关仍靠人工修反馈。 第三，授权逻辑还没声明化。替换 Runtime 里自定义授权代码、改用 Policy 做工具级访问决策同样列在下一步，因此现阶段的工具级审计能力有限。 第四，会话记忆过期固定为 90 天，跨季度的长周期上下文不在覆盖范围内。 第五，文章未给出成本数字，ECS 与 Lambda 的对比也是定性判断，没有同场景实测数据。 前置部署 Forward Deployed Engineer（FDE）在引用这条复盘时务必带上口径：60 倍是时间倍数，不是准确率或成本倍数。 实用结论：谁该行动、怎么做、何时适用、怎么退出 该行动的是正在做企业级智能体交付、且用户角色分歧明显的团队：如果同一条数据要回答技师、客户经理、业主三类人的问题，Trane 的五助手拆分可以照搬。 第一步是分层而不是先接模型：把内部 API 通过 AgentCore Gateway 之类的能力域网关暴露成 MCP 兼容工具，让智能体逻辑与工具执行分开部署、各自有明确的归属边界。 第二步是从第一天就打开端到端追踪。Trane 的缺失 Secret 案例说明，没有 invocation traces，多工具链上的失败只能靠猜；有追踪时同一失败模式可以跨调用比对。 第三步是按原型、内部最苛刻用户 beta、修准确率、对外这四段推进，不要跳过内部内测直接面向客户发布。 适用条件是三条同时成立：用户角色与权限分层明确、需要把实时遥测与文档检索合并在一次回答里、且数据敏感度高到必须做会话级隔离。 退出与回滚的余地来自两个设计选择：Strands 与 AgentCore 是框架无关的组合，MCP Server 又能独立部署，因此可以只换运行时或托管层而不动工具层；把工具层保留为开放标准，长期才有换供应商的空间。 如果团队已经在 ECS 或 Lambda 上自建了会话隔离、扩缩容与按会话计费，留在原栈也合理，Trane 的四条判据是评估依据而非迁移命令。 原始来源： https://aws.amazon.com/blogs/machine-learning/how-trane-gets-building-insights-60x-faster-with-amazon-bedrock-agentcore/