房地产金融领域的文档处理复杂且高度依赖人工，影响关键业务决策的效率。Built Technologies 作为一家服务超 5000 亿美元房地产项目的软件提供商，与 AWS 生成式 AI 创新中心（GenAIIC）、合作伙伴 AND Digital 及 AWS 账户团队合作，基于 Amazon Bedrock 和 AWS 智能文档处理加速器，构建了可扩展的 AI 文档处理引擎。该引擎能够对复杂的房地产金融文档进行分类、拆分、提取、评估和推理，将原本需要数天的工作流程缩短至几分钟，支持数百种文档类型，并为技术团队和行业专家提供了共建与改进文档处理器的共享环境。 ## 房地产金融的文档痛点 房地产金融的运行依赖于大量文档：施工提款包、贷款协议、发票、保险凭证、检查报告等。这些文档通常篇幅长、格式不一、领域专业性强，传统自动化手段难以处理。对于 Built 而言，文档智能不仅是后台工具，更是新一代智能体产品的基础能力——无论是审核施工提款、分析贷款协议、验证保险覆盖、总结发行备忘录，还是识别投资组合中的异常，智能体都需要具备上下文理解、高准确度和可追溯的文档理解能力。 ## 技术架构与实现 Built 的解决方案基于 Amazon Bedrock 和 AWS IDP 加速器，构建了一个可复用的文档智能引擎。核心流程包括： 1. **文档分类与拆分**：自动识别文档类型（如发票、合同），并拆分为逻辑单元。 2. **信息提取**：利用大语言模型从非结构化文本中提取关键字段。 3. **评估与推理**：对提取的信息进行验证和逻辑推理，例如检查保险金额是否满足贷款条件。 4. **持续改进**：技术团队与业务专家可在同一环境中协作，标注数据、优化模型。 该引擎采用模块化设计，支持数百种文档类型，并通过 Amazon Bedrock 的托管服务降低了运维复杂度。Built 团队表示，这一基础能力将赋能其产品矩阵中的多个智能体，覆盖房地产金融全生命周期。 ## 行业影响与展望 AI 驱动的文档智能正在重塑房地产金融行业。传统上，处理一份施工提款包需要跨部门多人协作数天，而 Built 的解决方案将其缩短至数分钟。这不仅提升了效率，还减少了人为错误，使金融机构能够更快地做出贷款决策。 Built 的实践也展示了 AWS 在垂直行业生成式 AI 落地的能力。通过与 AWS GenAIIC 的合作，Built 快速验证了技术可行性，并构建了可扩展的生产级系统。未来，随着更多智能体产品的推出，文档智能引擎将成为房地产金融数字化的核心基础设施。
## 从碎片化到统一：AI视觉智能的新范式 长期以来，AI在真实世界应用中的落地面临一个根本性挑战：**看、想、动**三大系统彼此割裂。开发者需要管理多个API、编写大量胶水代码来打通视觉感知、逻辑推理与行动执行之间的壁垒，导致实现成本高、效率低且系统脆弱。 如今，**计算机视觉、Strands Agents框架与模型上下文协议（MCP）**三大技术的融合正在改变这一局面。它们共同构建了一条端到端管道：视觉信息被捕获、理解并触发行动，整个过程在统一框架内完成。这种集成打破了感知、决策与行动之间的传统界限，使AI系统能够像人类智能一样协调运作。 ### 核心架构：统一安全模型下的多服务协作 在本文介绍的方案中，客户端通过**集中式IAM角色**与多个AWS服务交互。该角色作为安全网关统一管理权限，免去了在客户端嵌入凭据的麻烦。具体服务包括： - **Amazon S3**：对象存储，用于检索和管理数据 - **Amazon OpenSearch**：搜索服务，支持对索引数据的查询 - **Amazon Bedrock**：生成式AI模型，为智能体提供文本生成等能力 - **Amazon Rekognition**：图像分析，执行目标检测等视觉任务 ### 技术三剑客：计算机视觉 + Strands Agents + MCP 1. **计算机视觉**：负责处理照片、视频等视觉信息，完成感知层的任务。 2. **Strands Agents**：一个构建AI智能体的框架，支持多种模型提供商，负责决策与推理。 3. **MCP服务器**：作为标准化接口，将视觉处理能力暴露给智能体，实现“看即能懂，懂即能行”。 ### 落地价值：降低门槛，扩展应用 这种融合最直接的价值在于**将复杂的集成挑战简化为标准化流程**。开发者不再需要从零搭建视觉-决策-行动链路，而是通过MCP服务器这一单一接口，即可让AI系统具备端到端的视觉智能。 无论是智能监控、自动化质检，还是视觉辅助决策，这套架构都让AI能力更容易被集成到实际应用中。对于开发者而言，这意味着更少的代码、更低的维护成本以及更快的迭代速度。 ### 小结 计算机视觉、Strands Agents与MCP的结合，标志着AI系统从“能看”到“能理解并行动”的关键一步。通过统一的安全模型和标准化接口，AWS正在降低视觉智能的准入门槛，让更多应用场景受益于AI的协同能力。
随着企业在多个 AWS 账户和区域中部署机器学习工作流，跨环境监控 SageMaker Pipelines 成为一项挑战。开发人员和运维工程师不得不在不同账户和区域间手动切换来检查流水线执行状态，这增加了运营负担。为此，AWS 推出了一种基于 Amazon CloudWatch 自定义仪表盘的集中式监控解决方案，帮助团队从单一界面实时掌握分散在多个账户和区域的 SageMaker Pipelines 运行情况。 ### 架构核心：事件驱动 + Hub-and-Spoke 模型 该方案采用**事件驱动、无服务器架构**，通过响应 SageMaker Pipeline 事件实时更新监控数据，避免了轮询机制或始终在线系统的资源浪费。其核心是 **Hub-and-Spoke（中心-辐射）模型**： - **中心账户（Hub）**：部署 CloudWatch 自定义仪表盘，作为统一监控入口，接收并汇总所有流水线事件。 - **多个辐射账户（Spoke）**：每个账户中的轻量级组件负责捕获本地的 SageMaker Pipelines 事件，并将其转发至中心账户。 这种设计将复杂性集中在中心，而辐射账户只需部署少量资源，从而降低了跨账户运维的难度和成本。 ### 关键技术组件 1. **Amazon EventBridge**：在辐射账户中捕获 SageMaker Pipelines 状态变更事件（如执行开始、成功、失败）。 2. **AWS Lambda**：处理事件并格式化数据，通过跨账户角色将指标写入中心账户的 CloudWatch。 3. **Amazon DynamoDB**（可选）：存储流水线元数据，支持更复杂的查询和过滤。 4. **Amazon CloudWatch 自定义仪表盘**：在中心账户中展示所有流水线的实时状态、成功率、执行时长等关键指标，支持按账户、区域、流水线名称等维度筛选。 ### 部署与定制 该方案配套提供了 **AWS Cloud Development Kit（CDK）示例**，用户可根据自身需求快速部署。主要涉及两个 CloudFormation 堆栈： - **Dashboard Stack**：部署在中心账户，创建 CloudWatch 仪表盘及相关资源。 - **Spoke Stack**：部署在每个辐射账户，配置事件捕获和转发组件。 用户还可以通过修改 CDK 代码自定义仪表盘布局、添加新指标或调整事件过滤规则。 ### 适用场景与价值 对于采用 **MLOps 策略**、在多个环境（如开发、测试、生产）或地理区域运行 SageMaker Pipelines 的团队来说，该方案能显著提升运维效率。它解决了以下痛点： - **减少上下文切换**：无需在多个 AWS 控制台间来回切换，一个仪表盘即可查看所有流水线。 - **快速定位故障**：通过实时告警和可视化指标，第一时间发现并响应流水线失败。 - **成本优化**：无服务器架构按需计费，避免了监控系统的持续开销。 ### 总结 该解决方案展示了如何利用 AWS 原生服务（CloudWatch、EventBridge、Lambda 等）构建跨账户的 MLOps 监控能力。它既是一个可直接部署的工具，也是一个参考架构，用户可在此基础上扩展出更复杂的监控、告警和自动化修复功能。对于正在规模化 ML 工作负载的企业而言，这是一项值得投入的实践。
Thrad.ai 利用 Strands Agents 和 Amazon Bedrock AgentCore 构建了一套多智能体系统，自动化从潜在客户发现到个性化邮件生成的完整流程。本文对比了 Swarm 和 Graph 两种编排模式在延迟、成本和邮件质量上的基准测试，并介绍了加权评分、意图分类、时间衰减等策略，以及生产级治理控制。
在之前的文章中，我们介绍了基于 Amazon Nova Act 构建的 QA Studio 参考解决方案，展示了如何通过自然语言定义单个测试用例，并借助 AI 驱动的视觉导航按需执行。本文作为第二部分，重点阐述 QA Studio 如何通过**测试套件**和**命令行界面**，将代理式测试扩展到批量回归测试与 CI/CD 流水线集成中。 ## 测试套件：组织化回归测试 QA Studio 允许将多个测试用例（每个验证特定用户旅程）分组为**测试套件**，以支持结构化回归测试。套件执行时，每个测试用例在独立的 **Amazon ECS on AWS Fargate** 工作线程上并行运行。例如，一个包含 20 个测试的套件可同时执行，大幅缩短总耗时。 套件可按功能领域、发布阶段或测试目的组织，常见类型包括： - **冒烟测试**：每次部署后验证关键路径。 - **回归套件**：覆盖全部应用功能。 - **集成测试**：发布前验证跨功能工作流。 ### 创建与管理 通过 QA Studio Web 界面创建套件时，需提供名称、描述和可选标签，然后从已有用例中添加。每个用例保留其独立配置（起始 URL、变量、密钥、请求头等），执行时这些配置独立生效。 ### 执行与结果 套件执行时，QA Studio 为每个用例创建独立的执行记录，并分发到各自的 Fargate 任务。执行完成后，用户可查看每个用例的详细结果，包括执行轨迹、截图和日志。 ## 命令行界面：CI/CD 集成 QA Studio 提供 CLI 工具，支持在 CI/CD 流水线中触发测试套件执行并获取结果。典型流程如下： 1. 在 CI/CD 中配置步骤，调用 CLI 命令运行指定套件。 2. CLI 返回执行状态和详细报告。 3. 根据测试结果决定是否继续部署（例如，若套件失败则中止流水线）。 这种集成使得每次代码提交都能自动触发回归测试，确保质量问题在早期被发现。 ## 行业意义 QA Studio 代表了 **AI 代理在软件质量保障中的新范式**。传统自动化测试需要编写和维护大量脚本，而基于 Amazon Nova Act 的代理式测试允许 QA 人员用自然语言描述测试场景，降低了自动化门槛。同时，并行执行和 CI/CD 集成解决了规模化测试的效率瓶颈。 对于追求**快速迭代**和**持续交付**的团队，这种方案可以显著缩短测试周期，让质量保障跟上开发节奏。未来，随着 AI 代理能力的提升，我们有望看到更多端到端测试场景被自动覆盖。 ## 小结 QA Studio 通过测试套件实现并行回归测试，并通过 CLI 无缝接入 CI/CD 流水线，将代理式 QA 从单次执行升级为生产级自动化方案。这不仅提升了测试效率，也改变了 QA 团队的工作方式——从脚本维护者转变为测试策略设计者。
用户体验（UX）测试面临多重挑战：手动测试难以规模化，传统自动化脚本在界面变化时容易失效，而全面测试成本高昂。Amazon Nova Act提供了一种新思路——这是一个多模态基础模型，能像人类测试员一样通过视觉理解网页并智能导航。本文介绍如何构建一个云端部署的UX测试平台，利用Nova Act自动从文档生成测试场景、大规模并行执行用户流程，并通过自动化分析提供可操作洞察。该平台能适应界面变化，处理动态内容，显著提升测试覆盖率和效率。
在 Flo Health，每一篇面向用户的内容——无论是应用内故事、文章、新手引导流程还是营销素材——都必须通过严格的医疗准确性审核。然而，传统的人工审核流程让医疗专家平均每篇文章花费 **7 个工作日**，这成为内容规模化生产的核心瓶颈。 为了突破这一限制，Flo Health 工程团队将 AWS Generative AI Innovation Center 的概念验证（PoC）转化为基于 **Amazon Bedrock** 的生产级 AI 医疗内容审核与生成系统。该系统实现了**审核时间减少 60%**，**内容吞吐量提升三倍**，且无需扩大医疗团队规模。 ## 架构演进：从 PoC 到生产级系统 Flo Health 的工程团队首先对 PoC 架构进行了适配，使其能够无缝对接现有的内容管线。关键改动包括： - **模块化评审流程**：将医疗审核分解为多个独立维度，每个维度由专门的 AI 评审（AI Judge）负责 - **并行处理机制**：利用 Amazon Bedrock 的模型调用能力，实现多维度同时审核 - **人工复核环节**：保留医疗专家的最终决策权，确保高风险的审核结果由人类确认 ## 专业 AI 评审：多维度的审核体系 团队针对医疗内容的不同方面设计了专门的 AI 评审： 1. **事实核查评审**：验证关键医学声明是否与权威来源一致 2. **引用完整性评审**：检查参考文献是否准确、可追溯 3. **指南合规评审**：确保内容符合 Flo Health 的10点医疗准确性检查清单 4. **语言风格评审**：评估表述是否清晰、易懂且符合品牌调性 每个 AI 评审都经过精心设计的提示词（prompt）和少量示例（few-shot examples）进行调优，使其在特定维度上达到专业水准。 ## 基于 RAG 的 AI 内容生成 除了审核，系统还集成了 **检索增强生成（RAG）** 能力，辅助医疗团队生成初稿。RAG 架构通过以下方式确保内容质量： - **知识库构建**：将经过验证的医学资料、内部指南和已批准内容向量化存储 - **上下文检索**：在生成时自动检索最相关的知识片段，作为模型生成的依据 - **引用溯源**：生成的每一条医学声明都附带来源引用，便于专家快速核实 这一机制让医疗专家从零开始撰写初稿变为审阅和微调 AI 生成的草稿，大幅缩短了创作周期。 ## 提示工程与生产部署的经验教训 Flo Health 团队在部署过程中总结了几点关键经验： - **提示词迭代**：初始提示词过于宽泛，导致 AI 评审出现误判。通过不断细化指令、增加约束条件和反面示例，最终实现高一致性 - **温度参数调整**：对于事实核查任务，使用较低的温度（如0.1）以减少创造性输出；对于内容生成任务，则适当提高温度以增加多样性 - **异常处理机制**：当 AI 评审对某条内容置信度过低时，自动标记为“需人工复审”，避免错误通过 - **成本与性能平衡**：通过缓存常见查询结果和批量处理，降低 Amazon Bedrock 的 API 调用成本 ## 总结与展望 Flo Health 的这一实践表明，通过精心设计的 AI 系统，可以在不牺牲医疗准确性的前提下显著提升内容生产效率。未来，团队计划进一步扩展 AI 评审的维度，并探索多模态审核（如图像和视频中的医学信息）。 对于同样面临专业内容审核瓶颈的团队，Flo Health 的经验提供了可复用的参考框架：从明确审核标准开始，逐步构建模块化 AI 评审，最后通过 RAG 赋能生成环节。
Healthcare organizations face significant challenges in managing patient scheduling, with manual phone-based workflows that are slow, costly, and difficult to scale. ScienceSoft, an AWS Services Partner, has developed an AI-powered voice scheduler that addresses these issues while maintaining strict HIPAA compliance. The solution integrates **Amazon Nova 2 Sonic** for natural voice interaction and **Amazon Bedrock Guardrails** to enforce responsible AI standards, ensuring patient data privacy and regulatory adherence. ### 市场背景与挑战 The AI patient scheduling software market is rapidly growing, valued at approximately $260 million in 2023 and projected to reach over $1.2 billion by 2030 (Grand View Research). Traditional scheduling is time-consuming: each booking takes 8–12 minutes, with patients spending an additional 8 minutes on hold. Staff consume about 30% of their time on scheduling tasks, leading to bottlenecks. Human representatives handle only 40–60 calls per day, resulting in 20–30% of calls unanswered during peak periods and an average abandonment rate of 30%. ### 解决方案架构 ScienceSoft’s AI voice scheduler leverages **Amazon Nova 2 Sonic** for real-time voice recognition and natural language understanding, enabling seamless patient interactions. To ensure compliance, the system incorporates **Amazon Bedrock Guardrails**, which filter sensitive health information, prevent data leakage, and enforce HIPAA rules. The architecture is designed to handle scheduling tasks such as collecting patient information, verifying insurance, checking provider availability, and confirming appointments—all while maintaining a conversational experience. ### 合规与隐私保障 HIPAA compliance is critical in healthcare AI. ScienceSoft’s solution uses Bedrock Guardrails to implement content filters, deny topics, and sensitive data redaction, ensuring that protected health information (PHI) is never exposed. The system also supports audit logging and access controls, meeting the strict requirements of healthcare regulations. ### 应用与扩展 This architecture can be adapted to other healthcare workflows, such as prescription refills, referral management, and patient follow-ups. By automating voice interactions, organizations can reduce operational costs, improve patient satisfaction, and scale scheduling capacity without compromising compliance. **小结**: ScienceSoft’s AI voice scheduler demonstrates how responsible AI can transform healthcare operations. By combining Amazon Nova 2 Sonic with Bedrock Guardrails, the solution delivers efficiency, compliance, and trust—key pillars for healthcare innovation.
OpenAI 最新旗舰模型家族 **GPT-5.6 Sol、Terra、Luna** 已在 **Amazon Bedrock** 上全面上市，这是目前最智能的 OpenAI 模型系列，运行于专为高性能、安全性和可靠性打造的下一代推理引擎之上。 ## 命名体系与能力分级 GPT-5.6 引入了全新的命名方式：数字代表代际，而 **Sol、Terra、Luna** 则标识可独立演进的能力层级。Sol 是旗舰推理模型，也是 OpenAI 迄今最强大的模型；Terra 是面向日常生产任务的均衡模型；Luna 则专注于快速推理场景。 ## 旗舰模型 Sol 的性能突破 根据 OpenAI 的数据，Sol 在 **Artificial Analysis Coding Agent Index** 上取得了 **80 分** 的新高（领先第二名 2.8 分），同时输出 token 量减少一半以上，耗时缩短一半以上，成本降低约三分之一。在网络安全研究基准 **ExploitBench** 上，Sol 得分 **73.5%**，而 GPT-5.5 在同等输出 token 预算下仅为 47.9%。 在 **Agents' Last Exam**（涵盖 55 个领域的长期专业工作流程评估）中，Sol 以 **53.6 分** 刷新纪录，领先第二名 13.1 分。即使在中等推理强度下，其领先优势仍达 11.4 分，而预估成本仅为对手的四分之一。Sol 还引入了 **最大推理强度** 模式，允许用户为复杂任务动态调整计算资源。 ## 适用场景与定价 Sol 适合用于自主编码代理、漏洞研究、药物发现流程以及需要深度多步推理的任务。定价与 OpenAI 官方价格一致，使用量可计入现有 AWS 承诺消费。 Terra 作为均衡模型，适用于日常生产负载，提供比 GPT-5.5 更优越的性能。Luna 则针对低延迟、高吞吐量的推理场景优化。 ## 行业影响 此次集成意味着企业可以在 AWS 的安全合规环境中直接调用 OpenAI 最前沿的模型能力，无需管理底层基础设施。对于需要处理敏感数据、要求稳定吞吐量并遵守数据驻留法规的行业（如金融、医疗、网络安全），这提供了“前沿智能 + 企业级安全”的一站式方案。
## 当大脑与众不同，AI 成为无障碍工具 对于神经多样性人士而言，AI 不只是效率工具——它是弥补执行功能缺陷的“无障碍技术”。一位拥有 AuDHD（自闭症与 ADHD 共存）的 AWS 解决方案架构师分享了如何利用 **Amazon Quick on your desktop**（一款 AI 桌面与网页助手）构建系统，应对日常认知挑战。 ### 执行功能的隐形代价 据统计，英国约 **15-20%** 的成年人属于神经多样性人群。然而，多数 AI 生产力工具仍以神经典型大脑为设计蓝本。对于神经多样性专业人士，邮件分类、优先级排序和跟进管理等任务消耗的认知能量远超技术工作本身。 作者自述患有 AuDHD（自闭症与 ADHD 并存），其大脑擅长模式识别、深度分析和创造性解题，但在记忆昨日事项、决定下一步行动、任务切换和维持组织系统方面存在显著困难。长期以来，他通过“伪装”和复杂变通方式弥补，但每天下班后已精疲力竭，无力顾及家人。 ### 内部冲突：秩序与新奇的两难 AuDHD 的核心矛盾在于：自闭症大脑渴望结构、惯例和可预测性，追求完美系统；而 ADHD 大脑抗拒惯例、追求新奇，一旦初始多巴胺消退便无法维持任何系统。两者持续对抗——作者构建精美系统（自闭症满足），热情使用一周（ADHD 享受新鲜感），然后彻底放弃（ADHD 获胜），再因混乱感到痛苦（自闭症抗议），循环往复。 这种“工具墓地”循环并非懒惰，而是两种神经类型竞争的必然结果。组织任务消耗的认知能量是神经典型大脑的 **10 倍**，且即便付出代价，系统也无法在自身神经特征下存活。 ### AI 如何打破循环 作者开始利用 AI 构建能补偿特定认知缺陷的系统，而非简单用 ChatGPT 写邮件。通过 Amazon Quick on your desktop，他创建了以下工作流： - **自动捕获与分类**：AI 助手捕获散落信息并归类，减少记忆负担。 - **智能优先级排序**：根据截止日期和项目重要性自动排列待办。 - **无缝上下文切换**：任务切换时保留上下文，降低重启成本。 最终，AI 不仅提升了工作效率，更关键的是 **保留了执行功能用于家庭生活**——不再每天回家只剩空壳。 ### 启示：AI 无障碍的下一步 作者强调，AI 作为无障碍工具应关注个人神经特征，而非一刀切设计。他建议读者自问：哪些任务消耗最多认知能量？能否用 AI 替代？AI 能否帮助维持系统而非要求完美执行？ 这个故事揭示了一个被忽视的真相：对于神经多样性人群，AI 不是锦上添花的奢侈品，而是弥补认知鸿沟的必要基础设施。随着神经多样性意识提升，AI 工具的无障碍化设计将成为重要方向。
在医疗合规领域，数据量剧增带来的审计负担正成为医院运营的痛点。Bluesight 是一家为医院和药房提供智能管理解决方案的公司，其产品涵盖 KitCheck、ControlCheck、CostCheck 等六款合规工具。然而，客户真正渴望的是一个能跨产品边界、统一推理数据的 AI 层。 为此，Bluesight 与 AWS 深度合作，利用 Amazon Bedrock AgentCore 打造了名为 **Prism** 的智能体 AI 解决方案。Prism 从最初单一产品的 AI 原型逐步演进，最终整合了六大产品的数据能力，实现了跨系统的智能推理与洞察。 **首个落地产品 Prism Assistant for ControlCheck 已于 2026 年 5 月上线**，目前已被 20 家医疗系统采用。更复杂的多产品智能体方案计划于 2026 年下半年推出。 ## 合规挑战：4,000 小时的手工审计 以 340B 药品定价合规为例，医院需要将每笔采购与 FDA 短缺清单、ASHP 数据、库存天数、基于机器学习的短缺预测以及来自数百家其他医院的缺货信号进行交叉比对。单家医院每年为此耗费超过 4,000 小时，而 Bluesight 服务着 620 多家医院，问题规模可想而知。 ## 从原型到统一平台：Prism 的演进 Bluesight 的 AI 之旅始于药物转移检测。其产品 ControlCheck 通过复杂分析监控受控物质交易，但合规团队仍需花费大量时间手动编写报告、关联仪表盘信号。一个能秒级完成分析的对话界面成为迫切需求。 借助 **Amazon Bedrock AgentCore**，Bluesight 构建了 Prism。AgentCore 提供了智能体编排能力，使 AI 能够跨多个数据源执行多步推理，并调用 Bluesight 各产品的 API 获取实时数据。 Prism 的架构分为三层： - **数据层**：统一来自六大产品的数据，包括库存、采购、合规记录等。 - **推理层**：基于 Bedrock 的智能体引擎，理解用户自然语言查询，分解任务并调用相应工具。 - **交互层**：以对话界面呈现结果，支持追问与上下文关联。 ## 实际效果与未来规划 Prism Assistant for ControlCheck 的早期用户反馈积极。**20 家医疗系统已将其投入日常运营**，在药物转移检测场景中将报告生成时间从数小时缩短至数秒。Bluesight 预计，随着多产品智能体方案在 2026 年下半年推出，客户将能在一个对话中同时查询库存短缺、采购异常和合规风险，真正实现“一站式”合规洞察。 ## 行业启示：智能体 AI 在医疗合规中的价值 Bluesight 的实践表明，智能体 AI 特别适合解决跨系统、多步骤的复杂问题。在医疗领域，数据孤岛是常态，而智能体能够像高级分析师一样，自主规划路径、调用工具并综合信息。Amazon Bedrock AgentCore 的推出降低了这类应用的开发门槛，使企业无需从零搭建底层框架。 对于同样面临数据整合与合规压力的企业，Bluesight 的经验提供了一个可参考的路径：从单一场景的 AI 原型切入，验证价值后逐步扩展至全产品线，最终形成统一的智能体平台。 *注：文中提及的 Prism Assistant for ControlCheck 发布于 2026 年 5 月，多产品方案计划于 2026 年下半年发布。*
在多租户生产环境中部署生成式 AI 智能体时，一个核心身份难题随之浮现：当智能体代表用户调用下游 API 时，调用请求携带的是谁的标识？如果使用智能体的服务身份，审计线索将完全消失，每个下游系统都必须无条件信任该智能体；而直接转发用户令牌，则会使每个下游工具变成“混淆的代理”。OAuth 2.0 Token Exchange 规范（RFC 8693）正是为此而生，而 **Amazon Bedrock AgentCore Identity** 将其作为原生凭证提供者授权类型加以支持。 本文是《使用 Amazon Bedrock AgentCore 构建多租户智能体》和《通过 Bedrock AgentCore Gateway 拦截器实现细粒度访问控制》的实践续篇，详细演示了针对 Okta 的完整多租户 OBO 设置，展示了 JSON Web Token（JWT）声明在每个跳转中的转换过程，并解释了受众绑定如何实现跨租户的纵深防御。 ### 为什么需要 OBO 令牌交换？ OBO 模式在多租户场景下至关重要。以一个服务于两个租户（Acme 和 Globex）的旅行预订助手 TravelBot 为例，当用户通过智能体预订航班时，智能体需要调用不同租户的 API。如果 API 要求验证用户身份，直接使用用户原始令牌会导致“混淆代理”问题——Acme 的 API 可能误处理 Globex 用户的令牌。通过 OBO 交换，智能体可以将用户令牌转换为针对特定下游 API 的、绑定受众的新令牌，确保每次调用都经过精确授权。 ### OBO 在 Bedrock AgentCore 中的实现 **Amazon Bedrock AgentCore Gateway** 支持 OAuth 2.0 Token Exchange（RFC 8693）作为原生凭证提供者授权类型。利用这一能力，AgentCore Gateway 可以在调用下游工具之前透明地将入站用户令牌交换为新的、绑定受众的令牌，而无需智能体本身实现交换逻辑。 具体流程如下： 1. 用户通过客户端应用获取 Okta 颁发的访问令牌（受众为 AgentCore Gateway）。 2. AgentCore Gateway 收到请求后，识别出需要调用下游租户 API。 3. Gateway 使用用户的令牌向 Okta 发起 OBO 交换请求，请求一个受众为目标 API 的新令牌。 4. Okta 验证用户令牌有效且满足条件后，颁发新令牌（受众为特定 API）。 5. Gateway 使用新令牌调用下游 API。 ### 关键优势 - **身份跨租户传播**：原始调用者的身份在整个调用链中保持透明，下游系统可以基于用户身份执行细粒度授权。 - **消除混淆代理问题**：每个下游 API 收到的令牌都明确绑定其受众，不会误处理其他租户的请求。 - **纵深防御**：通过受众绑定和令牌交换，即使某个环节被攻破，攻击者也无法重用令牌访问其他资源。 - **与现有 OAuth 2.0 基础设施集成**：直接利用 Okta、Auth0 等身份提供商的能力，无需额外搭建。 ### 实施要点 参考实现 TravelBot 展示了完整的端到端设置。关键步骤包括： 1. **配置 Okta 应用程序**：为 AgentCore Gateway 和每个租户 API 分别注册应用，并设置正确的受众和授权策略。 2. **定义令牌交换策略**：在 AgentCore Gateway 中配置凭证提供者，指定交换端点、客户端凭据和所需的声明映射。 3. **设置拦截器**：使用 Gateway 拦截器在运行时触发令牌交换，并将新令牌注入下游请求。 4. **测试多租户场景**：验证不同租户用户调用同一智能体时，下游 API 能正确识别用户身份并执行相应授权。 ### 适用场景与限制 OBO 模式最适合多租户智能体需要调用多个下游服务且入站令牌受众与下游 API 不匹配的场景。对于单租户智能体，如果入站令牌受众已匹配下游服务，直接转发令牌可能更简单。此外，OBO 交换会增加一次网络往返，需要权衡延迟。 ### 总结 Amazon Bedrock AgentCore Gateway 的 OBO 令牌交换能力为多租户智能体提供了一种标准、安全的身份传播方案。通过结合 Okta 等身份提供商，开发者可以构建出审计清晰、权限精细的生成式 AI 应用，同时避免常见的安全陷阱。完整的参考实现代码将在 aws-samples/sample-obo-flow-poc 仓库中发布。
Amazon SageMaker AI 推出了生成式 AI 推理推荐功能的 UI 界面，该功能内置于 SageMaker AI Studio 中，提供低代码/无代码（LCNC）体验。此前，用户需要通过 API 以编程方式获取推理配置推荐，这要求用户了解参数设置并能够解读原始基准测试输出。新的 UI 消除了这一门槛，通过预设用例配置文件、可视化结果对比和一键部署，帮助缺乏深厚基础设施知识的团队快速获得经过验证的配置。 ## 从 API 到 UI：降低优化门槛 2026 年 4 月，Amazon SageMaker AI 推出了推理推荐 API，允许用户通过编程方式获得数据驱动的、可用于生产的配置。该功能将通常需要数周的优化周期压缩到数分钟（常见工作负载）或数小时（自定义工作负载）。然而，API 的使用仍假设用户具备一定的专业知识。新 UI 的推出旨在让更多团队能够自主完成配置优化。 ## UI 工作流程：引导式优化体验 在 SageMaker AI Studio 中，用户可以通过“Jobs”下的“Inference optimization”入口进入新的 UI 界面。工作流程分为以下几个步骤： - **选择预设用例配置文件**：用户无需手动指定令牌分布和并发数，而是从预设的配置文件中选择。例如，**Interact** 配置文件适用于聊天类工作负载（短输入、适中输出），**Generate** 针对内容生成场景（较长输出），**Summarize** 则针对文档摘要等输入输出比高的场景。 - **可视化比较结果**：UI 以图表形式展示不同实例类型、容器设置和优化策略的性能对比，包括延迟、吞吐量和成本等关键指标。 - **一键部署**：选定最优配置后，用户可直接部署到生产端点，无需编写任何代码。 ## 适用人群与场景 该 UI 主要面向两类用户：一是**机器学习工程师**，他们可以快速验证并部署新模型，无需手动进行基准测试；二是**技术领导者**，他们可以直观评估成本与性能的权衡，做出更明智的决策。高级用户仍可继续使用 API 进行精细配置。 ## 行业背景与意义 生成式 AI 模型的部署优化一直是企业面临的挑战。选择合适的实例类型、容器和优化策略通常需要反复试验，耗费大量时间和资源。SageMaker AI 的推理推荐功能，尤其是新推出的 UI，显著降低了这一过程的复杂性。它使得更多团队能够快速将模型投入生产，而无需依赖专门的机器学习基础设施专家。 随着生成式 AI 在企业中的普及，降低部署门槛、加速模型落地的工具将变得越来越重要。Amazon SageMaker AI 的这一更新，反映了云服务商在简化 AI 运维方面的持续努力。
模型定制将通用 AI 模型转化为专业化企业资产。通过微调基础模型，企业可以教会 AI 理解自身独特的工作流、术语和领域知识，同时严格遵循品牌风格并减少幻觉。对于企业而言，这不仅是优化，更是创造专有知识产权——微调模型将组织的独特智慧和最佳实践编码到其架构中，构建难以被现成公开前沿模型复制的竞争优势。同时，在目标任务上微调较小的开源模型，往往能匹配甚至超越更大规模专有模型的性能，同时显著降低成本，并将敏感数据保留在安全、私有的基础设施内。 Amazon SageMaker AI 提供丰富的开源模型选择和微调技术。如今，SageMaker AI 推出了针对 **NVIDIA Nemotron 3** 模型的无服务器模型定制功能，首发支持 **Nemotron 3 Nano（300亿总参数，30亿活跃参数）** 和 **Nemotron 3 Super（1200亿总参数，120亿活跃参数）**。通过监督微调、基于可验证奖励的强化学习和基于 AI 反馈的强化学习，用户无需预置或管理任何基础设施，即可将这些高性能开源模型适配到特定领域和工作流中。 ## NVIDIA Nemotron 3 模型架构亮点 NVIDIA Nemotron 3 系列基于 **混合 Mamba-Transformer 混合专家架构**，原生支持高达 **100万 token 的上下文长度**。该架构交错使用三种互补的层类型：Mamba-2 层用于高效的线性时间序列处理，Transformer 注意力层用于精确的关联召回，以及混合专家层用于扩展模型容量。这种设计在长序列处理效率和复杂推理能力之间取得了平衡。 ## 无服务器微调技术 SageMaker AI 为 Nemotron 3 提供了三种微调方法： - **监督微调**：使用标注数据直接调整模型参数，适用于分类、摘要等任务。 - **基于可验证奖励的强化学习**：通过可自动验证的奖励信号优化模型行为，适用于数学推理、代码生成等有明确正确答案的场景。 - **基于 AI 反馈的强化学习**：利用 AI 评判模型输出质量，适用于需要主观判断的任务，如创意写作、对话生成。 ## 如何在 SageMaker Studio 中开始 用户可以直接在 SageMaker Studio 中通过可视化界面或 API 启动无服务器微调作业。步骤如下： 1. 选择 Nemotron 3 模型（Nano 或 Super）。 2. 上传领域数据集（支持常见格式如 JSON Lines）。 3. 选择微调方法（SFT、RLVR 或 RLAIF）并配置超参数。 4. 启动作业，SageMaker AI 自动管理计算资源。 5. 微调完成后，模型可直接部署为无服务器端点。 这种无服务器模式显著降低了入门门槛，使更多企业能够以较低成本实现模型定制，同时保持数据安全。 ## 行业意义 Nemotron 3 的混合架构和无服务器微调能力，为企业在长上下文处理（如法律文档分析、代码库理解）和成本效率之间提供了新选择。结合 SageMaker AI 的托管服务，企业可以快速迭代领域模型，而无需深究底层基础设施。
在牙科行业，影像质量直接决定保险理赔是否获批。据统计，高达 **20%** 的初始保险索赔被拒，其中影像缺失或质量低下是主因之一。然而，传统的质量评估流程往往是事后人工审核——临床医生在拍摄后数小时甚至数天才查看 X 光片，发现问题时索赔已被拒或治疗无法推进。若影像模糊、错位或不完整，患者不得不返回诊所重拍，增加了成本、延误和各方的不满。 Henry Schein One 通过构建 **Image Verify** 系统解决了这一痛点。该系统基于 **Amazon SageMaker AI**，在牙科 X 光片拍摄的瞬间进行实时质量评估，覆盖数千个诊所。从概念到部署，Image Verify 在数月内便推广至 **10,000 多个活跃站点**，已处理超过 **1,100 万张 X 光片**，且每周新增约 **150 万张**。目前，Henry Schein One 正将该系统扩展至全球 **40,000 个站点**，覆盖四个地区。 ## 挑战：大规模实时影像质量审核 Henry Schein One 之前的影像审核方案运行在另一个云平台上，但无法满足临床工作流对延迟和成本效率的要求。在 AWS 上重建并非简单的迁移，而需要设计一个能同时满足五项严格要求的系统： - **延迟**：质量评估必须在 **3 秒内** 完成，以无缝融入临床工作流。 - **准确性**：多个机器学习模型需评估清晰度、对齐度和完整性等不同维度，避免误报损害临床信任。 - **规模**：系统需同时服务数万个站点，日处理量达数十万张。 - **成本效率**：大规模 GPU 推理若不精心优化，成本将难以承受。 - **全球覆盖**：医疗场景具有本地化特征，但平台必须在多个区域保持一致的性能表现。 ## Image Verify 的解决方案 Henry Schein One 利用 **Amazon SageMaker AI** 构建了端到端的影像质量验证流水线。系统在 X 光片拍摄后立即触发推理，调用多个专用模型分别评估不同质量指标，并在 **亚秒级** 内返回结果。如果检测到质量问题，系统会实时提示操作人员，从而在患者离开前完成重拍，避免了后续的理赔纠纷。 ### 关键设计亮点 - **多模型并行推理**：针对不同质量维度（如清晰度、解剖结构完整性）部署独立模型，并通过 SageMaker 的模型编排能力实现并行推理，确保整体延迟在 3 秒以内。 - **成本优化**：通过 **GPU 实例自动缩放** 和 **批量推理**，在高峰期保持性能，在低谷期降低成本。此外，利用 **Amazon Elastic Inference** 或 **SageMaker 推理加速器** 进一步降低单位推理成本。 - **全球部署**：采用多区域架构，利用 **AWS 全球基础设施** 将推理端点部署在靠近诊所的区域，确保低延迟并符合数据本地化法规。 ## 成果与展望 Image Verify 上线后，Henry Schein One 的影像质量审核流程从“事后补救”转变为“即时预防”。诊所端重拍率显著下降，保险索赔通过率提升，患者体验得到改善。目前系统每周处理 **150 万张** X 光片，并持续增长。未来，Henry Schein One 计划将该平台扩展至 **40,000 个站点**，并探索在正畸、种植等更复杂牙科影像中的应用。 这一案例表明，**实时 AI 推理** 在医疗影像领域具有巨大价值——不仅提升运营效率，更直接改善临床结果和患者满意度。对于希望构建类似系统的企业，关键在于平衡延迟、准确性和成本，而 **Amazon SageMaker AI** 提供了灵活的基础设施和工具来应对这些挑战。
企业数据分析正从“自助 BI”迈向“智能体分析”（Agentic Analytics）时代。然而，数据分散在不同系统中，同一概念定义不一，导致 AI 智能体容易给出矛盾答案。本文介绍如何在 AWS 上利用 Stardog 语义 AI 应用（覆盖 Amazon Aurora 和 Amazon Redshift）构建语义层，并通过 Amazon Bedrock AgentCore 运行 Strands Agents，实现无需 ETL 的客户 360 度查询。 ## 为什么需要语义层？ 传统报表到自助 BI 的进化并未解决根本问题：数据工程师仍需为每个问题预建模型，分析师仍是瓶颈。生成式 AI 智能体能自主规划、编写查询、评估结果并迭代，但前提是底层数据语义一致。例如，CRM 中的“客户”与计费系统的“客户”并非同一记录，北美团队的“收入”计算方式也可能与欧洲不同。若直接让智能体访问碎片化数据，即便 SQL 语法正确，也可能返回错误或矛盾的答案。 ## Stardog 语义层如何工作？ Stardog 在现有数据库（如 Aurora 和 Redshift）之上构建统一的语义层，通过知识图谱映射不同数据源中的实体和关系。它支持： - **虚拟集成**：无需 ETL，实时查询跨源数据。 - **语义推理**：自动理解“客户”“订单”等概念的关联，消除歧义。 - **兼容 AWS 计算**：可部署在 Amazon EKS、ECS 或 Lambda 上。 ## Amazon Bedrock AgentCore 的角色 AgentCore 是一个托管服务，整合了身份认证、托管和工具凭证管理。本文中，Strands Agents 通过 AgentCore 访问语义层，回答“客户 360”类问题——例如“某客户过去一年的总消费额”，该问题需要同时查询 Aurora 中的交易记录和 Redshift 中的分析数据。 ## 实践价值 这种架构的核心优势在于： 1. **降低数据准备成本**：无需为每个新问题预先建模。 2. **提升答案可靠性**：语义层确保跨系统数据一致性。 3. **加速落地**：借助 Bedrock 的基础模型（如 Claude、Llama）和 AgentCore 的托管能力，开发者可快速构建可信的企业级 AI 智能体。 ## 小结 智能体 AI 的瓶颈不在模型能力，而在数据语义的统一。Stardog + Amazon Bedrock AgentCore 的组合提供了一条务实路径：在现有 AWS 数据基础设施上构建语义层，让 AI 智能体从“能写 SQL”升级为“能理解业务含义”。
在 AI 智能体从概念验证走向企业级生产环境的过程中，规模化运营的挑战远不止于智能体本身。Amazon Quick Automate 通过原生集成**案例管理**，将每个工作项视为一个贯穿全生命周期的“案例”，为智能体工作流提供状态追踪、异常处理、人工介入（HITL）和动态扩展等关键能力。 ## 从概念验证到规模化生产：智能体面临的运营挑战 一个 AI 智能体在概念验证（POC）阶段可以轻松处理一张发票、审核一项理赔或分类一个工单。但当工作项数量达到**数千甚至数百万**时，企业需要面对一系列新的问题：如何追踪每个工作项在多智能体、多系统中的状态？如何定位失败节点与原因？如何让人类在必要时介入？又如何根据需求动态扩展基础设施？这些正是 Amazon Quick Automate 通过**原生案例管理**要解决的核心痛点。 ## 案例管理：为智能体工作流注入结构与可见性 在 Quick Automate 中，**每个工作项都被定义为一个“案例”**，并贯穿其从创建、处理到关闭的完整生命周期。这种设计带来了几个关键优势： - **全流程可见性**：案例状态实时更新，团队可以清晰看到每个工作项在哪个步骤、由哪个智能体处理，以及处理结果。 - **异常处理与重试**：当智能体处理失败时，系统可以自动标记案例状态，触发重试或转人工处理。 - **人工介入（HITL）**：在需要判断、审批或复杂决策的场景下，案例可以进入“等待人工”状态，由人类操作员处理后再返回自动化流程。 - **动态扩展**：通过“案例创建者-处理器”模式，系统可以根据输入负载自动创建多个案例，并分配给多个处理器并行执行，实现弹性伸缩。 ## 核心模式：案例创建者与处理器 Quick Automate 引入了一种简洁但强大的设计模式——**案例创建者-处理器**。创建者负责侦听输入源（如消息队列、数据库、API 调用），为每个新工作项生成一个案例；处理器则持续轮询待处理案例，执行智能体工作流并更新案例状态。这种解耦架构使得系统可以轻松应对流量高峰：当输入激增时，创建者快速生成大量案例，而处理器集群可以自动扩展，并行处理这些案例，从而保证吞吐量。 ## 真实场景：企业级流程中的案例管理实践 以一个典型的**保险理赔**流程为例： 1. **案例创建**：当理赔申请提交后，Quick Automate 自动创建一个案例，包含申请人信息、事故描述、证据文件等。 2. **智能体处理**：AI 智能体自动提取关键信息、验证保单有效性、评估损失金额。如果智能体对某项数据存疑（例如发票金额异常），案例状态变为“需人工审核”。 3. **人工介入**：人类审核员查看案例详情，确认或修正智能体的判断，然后提交反馈。案例状态更新为“已审核”，触发后续自动处理。 4. **多智能体协作**：案例可能依次经过欺诈检测智能体、赔付计算智能体、支付智能体，每个步骤都记录在案例历史中。 5. **案例关闭**：当所有步骤完成，案例状态变为“已关闭”，所有审计日志、决策路径和人工注释都保留在案例中，方便后续追溯。 ## 企业级能力：不止于自动化 除了核心的案例生命周期管理，Quick Automate 还提供了细粒度访问控制、活动日志、版本管理、异常处理等企业级功能。这意味着团队可以安全地将智能体工作流部署到生产环境，同时满足合规与审计要求。 ## 总结 Amazon Quick Automate 的原生案例管理能力，将 AI 智能体从“单点任务执行者”升级为“企业级流程参与者”。通过为每个工作项提供结构化的生命周期管理，它解决了规模化运营中的**可见性、可靠性、可追溯性**三大核心问题。对于正在将智能体从实验室推向生产环境的企业来说，这或许是比智能体本身更值得关注的基础设施。
## 概述 部署大型基础模型（FM）时，原始 16 位浮点精度（BF16/FP16）的存储和计算成本高昂，需要大容量 GPU 实例，推高服务成本并拖慢迭代周期。**量化**通过降低权重精度（如从 16 位降至 4 位）显著压缩内存占用，但可能影响模型精度。**动态量化**则能在保持精度的同时大幅减少内存，实现成本、存储和启动时间的综合优化。 本文介绍了四种使用 **Unsloth** 进行量化并在 AWS 基础设施上部署的模式，涵盖 **Amazon EC2**、**Amazon SageMaker AI** 推理端点以及 **Amazon EKS/ECS** 容器编排场景。 ## 什么是 Unsloth 动态量化？ Unsloth 联合创始人 Daniel Han 解释道：“一个强大模型的最大问题是体积巨大，需要 1.5TB 才能运行。通过一些技巧，可以将模型压缩到 217GB。你可能认为体积缩小 86% 会导致精度下降 86%，但实际情况并非如此——精度仅下降约 14%。” 动态量化的核心在于**并非将所有权重降至 4 位，而是保留部分层为更高精度（如 8 位）**，从而在压缩与精度之间取得平衡。例如，一个 **80 亿参数模型** 从约 16GB（BF16）降至约 5GB（4 位），使原本需要多 GPU 的实例能单 GPU 运行。 ## 四种部署模式 ### 1. Amazon EC2 直接部署 适合需要完全控制实例环境、调试或低延迟调优的场景。用户可直接在 EC2 GPU 实例上加载量化模型，使用 Unsloth 优化后的推理代码。 ### 2. Amazon SageMaker AI 推理端点 利用 SageMaker 的托管服务，简化模型部署、扩展和监控。用户可将量化模型打包为容器镜像，创建实时端点，自动处理负载均衡与弹性伸缩。 ### 3. Amazon EKS 部署 对于已采用 Kubernetes 的团队，EKS 可将量化模型作为 Pod 部署，利用 K8s 的调度、自动扩缩和滚动更新能力，适合微服务架构。 ### 4. Amazon ECS 部署 类似 EKS，但更轻量，适合使用 Docker Compose 或任务定义的场景，通过 Fargate 或无服务器模式进一步降低运维负担。 ## 生产部署实践要点 - **模型格式与兼容性**：确保量化后的模型（如 GGUF、AWQ 等）与推理框架兼容。 - **性能监控**：跟踪推理延迟、吞吐量和 GPU 利用率，根据负载调整实例规格。 - **成本优化**：动态量化带来的内存节省可直接转化为更小实例或更少 GPU 的使用，降低每小时成本。 - **精度验证**：部署前在代表性数据集上对比量化模型与原始模型的输出，确保业务指标可接受。 ## 小结 Unsloth 的动态量化技术为大规模 AI 部署提供了实用路径——在精度损失可控的前提下，大幅降低硬件门槛和运营成本。结合 AWS 的 EC2、SageMaker、EKS/ECS 等灵活部署选项，团队可根据自身技术栈和需求选择最合适的模式，加速模型从研究到生产的落地。
SAP 数字化转型是企业面临的最复杂、高风险的任务之一，通常跨越数月甚至数年，涉及业务流程和自定义代码的复杂依赖关系，且需要难以仅靠人类顾问扩展的领域专业知识。KTern.AI 作为一家 SAP 数字转型平台，多年来一直致力于让这些转型更快、更可预测。如今，他们通过转向智能体 AI 实现了迄今最大的飞跃。 从传统的 SaaS 平台演进为下一代智能体 AI 平台，意味着需要协调多个专业智能体，使其在长期运行的企业项目中协同工作。每个智能体都需要具备持久上下文、安全的工具访问权限以及生产级可靠性。KTern.AI 利用 Amazon Bedrock AgentCore 和 Strands Agents SDK 构建了这一系统。本文详细介绍了其架构设计、构建的智能体类型以及为客户带来的实际成果。 ## 架构核心：持久上下文与安全工具访问 KTern.AI 面临的核心挑战在于：真正的自主 SAP 转型需要智能体能够跨数月甚至数年的项目进行推理，同时协调多个领域，并严格遵守企业安全与合规边界。传统的单轮 AI 交互无法胜任。Amazon Bedrock AgentCore 提供了基础能力，而 Strands Agents SDK 则帮助实现了多智能体编排。每个智能体都维护着持久上下文，这意味着它们可以记住历史交互和项目状态，从而做出更连贯的决策。同时，通过安全的工具访问机制，智能体能够调用 SAP 系统接口、分析代码仓库或处理财务数据，而不会突破安全边界。 ## 构建的智能体类型 KTern.AI 构建了多个专业智能体，覆盖 SAP 转型的关键环节： - **逆向工程智能体**：自动分析现有 SAP 系统，生成数字化蓝图，识别自定义代码和业务流程依赖。 - **标准适配智能体**：评估业务需求与 SAP 标准流程的差异，提出适配建议。 - **代码分析智能体**：扫描 ABAP 代码，识别与 S/4HANA 不兼容的代码段，并提供迁移建议。 - **异常挖掘智能体**：专注财务和销售流程，自动检测数据异常或流程偏差，减少人工审计工作量。 这些智能体能够自主编排工作流，从逆向工程到标准适配、代码分析，再到财务和销售流程的异常挖掘，实现了端到端的自动化，而无需构建自定义智能体基础设施。 ## 客户成果与行业意义 KTern.AI 的平台已实现 **7 倍更快的转型速度**，并将整体工作量减少 **24%**。通过将领域专业知识编码为专有知识引擎，并结合数据驱动的超自动化，客户能够更可预测地完成 S/4HANA 迁移和系统转换。 这一案例展示了智能体 AI 在企业级场景中的落地潜力：不再是简单的问答或单步任务，而是能够管理长期、多步骤的复杂项目。Amazon Bedrock AgentCore 作为底层平台，提供了必要的持久化、安全性和可靠性，而 Strands Agents SDK 则简化了多智能体的协调。对于正在进行 SAP 转型的企业而言，这种自动化能力有望显著降低对稀缺顾问资源的依赖，并加速数字化转型进程。 ## 小结 KTern.AI 的实践表明，智能体 AI 在 SAP 这样的大型企业系统中具有切实价值。通过将专业知识与自主代理相结合，企业可以更高效地应对复杂转型挑战。未来，随着更多企业采用类似架构，智能体 AI 有望成为企业级自动化的标准范式。
大语言模型推理中的预填充（Prefill）与解码（Decode）共享同一 GPU 时，长提示会阻塞所有并发请求的令牌生成。**分离式预填充与解码（DPD）** 通过将两个阶段分别运行在独立的 GPU 池中，并借助弹性结构适配器（EFA）与远程直接内存访问（RDMA）连接，消除了这种干扰。 LLM 推理包含两个本质不同的阶段：预填充是**计算密集型**，它并行处理整个输入提示以生成初始键值（KV）缓存；解码则是**内存密集型**，每次生成一个令牌，需要大量内存带宽来访问模型权重和不断增长的 KV 缓存。通过将两者分离为专用引擎，可以为每个阶段分配不同的并行策略。这种分离允许独立调整**首令牌时间（TTFT）** 和**令牌间延迟（ITL）**，比块状预填充调优更可靠地控制尾部延迟，并防止长上下文预填充阻塞正在进行的解码请求。 vLLM 通过连续批处理和 PagedAttention 提高了单节点效率。然而，大规模部署的组织在编排多节点部署和优化路由时仍面临挑战。本文展示了如何使用 SageMaker HyperPod Inference Operator 在 Amazon SageMaker HyperPod 上实现基于 vLLM 的 DPD。 ### 何时使用分离式推理 分离预填充与解码在以下场景中效果最为显著：**长上下文、高并发流式工作负载**，例如聊天助手、Agent 管线、文档分析端点和带有大量检索上下文的检索增强生成（RAG）。在这些情况下，单个长提示在共享 GPU 上会导致其他所有请求的解码停滞，造成每令牌延迟尖峰，而 DPD 通过架构设计消除了这一问题。 考虑使用 DPD 的场景： - 输入提示**经常超过 4096 个令牌** - 存在**多个并发用户或请求** - 需要**流式响应**且令牌交付一致性至关重要 - 混合流量中同时包含**长提示和短提示** 当 GPU 争用并非实际问题时，**共存部署**是更简单的选择：批处理或离线工作负载（优化 TTFT）、低并发部署、或仅短提示流量。在路由阈值以下，通过 EFA RDMA 传输 KV 缓存的固定成本超过了隔离解码带来的收益。DPD 路由器会将此类请求直接发送给解码器。 ### 架构与实现 DPD 架构由三个核心组件构成：预填充池、解码池和智能路由器。预填充池负责处理提示并生成 KV 缓存，解码池利用接收到的 KV 缓存逐令牌生成输出，路由器则根据提示长度、当前负载和延迟目标决定请求的路由方式。 在 SageMaker HyperPod 上实现时，利用 HyperPod Inference Operator 可以简化多节点部署的编排。EFA RDMA 提供了低延迟、高带宽的节点间通信，使得 KV 缓存在预填充和解码池之间高效传输成为可能。 ### 性能优化与权衡 分离架构带来的主要收益包括： - **消除干扰**：长提示不再阻塞其他请求的解码，尾部延迟显著降低 - **独立优化**：可为预填充和解码分别调整并行策略，例如预填充使用更大的张量并行度，解码使用流水线并行 - **资源效率**：根据工作负载动态调整预填充和解码池的大小，避免资源浪费 然而，也存在一些权衡： - **KV 缓存传输开销**：通过 EFA 传输 KV 缓存会引入固定延迟，对于短提示可能得不偿失 - **复杂性增加**：需要管理两个独立的 GPU 池和智能路由逻辑 - **路由决策延迟**：路由器本身可能成为瓶颈，需要高效的路由算法 ### 总结 DPD 是应对现代 LLM 推理中长上下文和高并发挑战的有效架构。通过在 SageMaker HyperPod 上结合 vLLM 和 EFA RDMA，组织可以构建可扩展、低延迟的推理服务。对于以流式响应为核心的应用，DPD 提供了一条清晰的路径，在保持高吞吐的同时实现稳定的每令牌延迟。