## 核心发现：生产级AI代理的实战数据 monday.com在Amazon Bedrock上运行名为Sphera的内部AI代理系统，该系统已深度融入其工程团队。数据显示，**90%的开发者每月使用AI编码工具**，相比半年前的约50%几乎翻倍。每位工程师的PR吞吐量提升超过50%，这些数据均来自monday.com的内部生产环境，而非实验性项目。 ## 三个层级的AI工程实践 monday.com将AI工程分为三个层级： - **L1 助理层**：AI作为结对编程伙伴。工程师使用Cursor处理快速反馈式工作，Claude Code处理重型任务。采用率同比接近翻倍。 - **L2 技能与子代理层**：团队构建可复用的代理处理重复工作，工程师仍处于主导地位。这是当前大部分工作运行的层级，也是PR吞吐量提升的关键所在。 - **L3 多代理层**：完全自主的代理端到端交付任务，工程师负责编排。代理从看板领取任务，通过Slack和monday沟通，与人类共同交付代码。 ## Sphera：代理即队友 monday.com的Sphera系统颠覆了传统作业队列的概念。其首页是一个**团队页面**，人类与代理混合排列，每个代理拥有个人资料、管理者、职责范围和绩效评分。核心代理Atlas的角色是“软件工程师”，任务是从看板领取工单、编写PR、交付功能——与人类开发者共享同一待办列表。 这种设计并非装饰，而是**数据模型**。每个代理拥有稳定身份，贯穿Slack、GitHub和monday.com。人类可以像对待同事一样标记、指派、代码审查或停用代理。真正产生价值的代理都隶属于真实团队，承担实际工作，并对结果负责。 ## 架构与部署 整个系统运行在Amazon Bedrock上，针对monday.com**十年历史的老代码库**进行了大量改造。系统包含数百个微前端和微服务，覆盖数百万付费用户。代理提交的每个PR都会进入一个用户期待持续运行的生产系统。与绿场项目不同，在企业级SaaS中运行代理需要应对真正的值班、客户和合规要求。 monday.com的实践表明，**生产级AI代理的落地关键在于身份化、团队集成和渐进式自主**。通过将代理视为团队成员而非任务执行者，他们成功实现了从辅助到半自主再到全自主的工程效率跃升。
在监督微调（SFT）中，为训练数据构建高质量思维链（CoT）推理轨迹往往成本高昂且不切实际，导致许多开发者直接跳过推理步骤，仅使用输入输出对进行训练。然而，推理能力是Amazon Nova 2系列模型的核心优势，能显著提升编码、数学等复杂任务的性能。本文提出一种名为**自我蒸馏推理（Self-Distilled Reasoning, SDR）**的方法，为缺乏推理轨迹的数据集生成思维令牌，无需依赖外部教师模型。SDR的核心思路是复用基础Amazon Nova 2 Lite模型自身的思维链作为推理替代，从而在提升目标任务性能的同时缓解灾难性遗忘。实验在三个基准测试上验证了SDR的有效性：相比普通SFT，SDR在目标性能上表现相当或更优，且显著保留了通用能力；而模型合并虽能保留通用能力，但会牺牲SFT带来的性能增益。这一发现与自我蒸馏（self-distillation）领域的最新研究趋势一致，即模型在训练过程中从自身提取信息能带来额外收益。本文还提供了实践建议，包括何时选择SDR、如何平衡推理开销与性能提升，以及未来结合强化微调（RFT）的可能性。对于使用Amazon Nova 2定制服务的开发者而言，SDR提供了一条低成本、高效益的路径，让思维模型能力在特定领域落地成为可能。
AWS DeepRacer 是一款基于强化学习的 1/18 比例自动驾驶赛车，旨在帮助开发者入门机器学习。然而，出厂时预装的操作系统（如 Ubuntu 16.04 和 20.04）已停止支持，限制了设备的持续使用。为此，AWS 发布了开发者引导加载程序（bootloader），允许用户安装自定义操作系统，从而延长设备寿命。 该引导加载程序基于开源项目 shim，支持安装第三方 Linux 发行版、添加自定义硬件驱动、运行现代软件栈，甚至开发新型车辆算法原型。启动时，设备会通过内置灯光以摩尔斯电码闪烁“DEVELOPER MODE”作为视觉提示，确保用户知晓设备处于开发者模式。流程完全可逆，用户可随时恢复出厂配置。 这一更新主要面向熟悉 Linux 启动流程和证书管理的开发者，尤其有助于社区成员创建和分发自定义 AWS DeepRacer 安装镜像。对于一般用户，AWS 建议继续使用官方支持的软件，但提供了文档供高级用户参考。 此举反映了 AWS 对硬件开放性的重视，在 AI 教育硬件领域具有示范意义——设备不应因软件过时而沦为电子垃圾。通过开放引导加载程序，AWS 不仅延长了现有设备的生命周期，也为开发者提供了更灵活的探索空间，可能催生更多基于 DeepRacer 的创新实验和教学项目。
供应链团队常面临数据充足但时间不足的困境：仪表盘能显示异常，却难以自动生成可执行的决策建议。本文将演示如何结合 **Amazon Quick** 与 **NVIDIA NeMo Agent Toolkit**，构建一个从数据洞察到缓解方案的端到端代理工作流。 ## 痛点：从“看到问题”到“解决问题”的鸿沟 企业供应链规划人员发现供应商延迟时，需手动核查采购订单、库存、客户承诺、合同条款、物流选项及审批策略，才能决定下一步行动。传统仪表盘虽能揭示问题，但无法将信号转化为可靠、可追溯的决策流程。 ## 解决方案：双平台协同架构 **Amazon Quick** 为业务用户提供单一对话式工作空间，整合结构化数据与非结构化企业知识（来源包括 Amazon S3、Google Drive、SharePoint、Confluence 等），并通过 100 多个预构建动作连接器（如 Outlook、Slack、Jira）及 **Model Context Protocol (MCP)** 调用外部代理工作流。 **NVIDIA NeMo Agent Toolkit** 作为开源、框架无关的库，可连接、评估、优化 LangChain、LlamaIndex、CrewAI、Microsoft Semantic Kernel、Google ADK 等框架构建的代理，为后端提供强大的推理与工具调用能力。 ## 实战案例：供应链风险缓解工作流 1. **诊断触发**：规划员在 Amazon Quick 聊天界面提出“某供应商延迟，应如何应对？” 2. **代理工作流**：NeMo Agent Toolkit 自动调用供应链工具，检查订单状态、库存水平、替代供应商、运输时效等，并基于规则验证推荐方案。 3. **结果呈现**：返回排序后的缓解计划，附带每项建议的证据链（如“建议加急订单，因库存仅够 3 天，替代供应商交货期需 5 天”）。 ## 适用人群与价值 - **供应链运营领导者/分析师**：可直接在 Amazon Quick 中从仪表盘上下文跳转到具体行动方案。 - **工程领导者/开发者**：可参考如何用 NeMo Agent Toolkit 构建后端代理工作流，并与现有系统集成。 通过这种组合，企业能将数据洞察转化为可重复、可审计的决策自动化，显著缩短响应时间。
## 概述 Couchbase 在构建 AI 辅助开发助手 Capella iQ 时，面临单一模型架构在灵活性、弹性和客户偏好多样性上的挑战。通过采用 **Amazon Bedrock** 并集成 **Anthropic 的 Claude 系列模型**，Couchbase 成功打造了一个多模型推理架构，实现了高可用、可扩展且模型无关的 AI 服务。 ## 架构设计 Capella iQ 的架构部署在 AWS 控制平面内，横跨 **us-east-1** 和 **us-west-2** 两个区域，确保高可用性。核心微服务运行在 **Amazon EKS 集群** 上，包括： - **cp-api pod**：接收开发者请求并编排推理调用，通过 VPC 接口端点转发至 Amazon Bedrock。 - **cp-internal-api pod**：处理服务间通信和模型路由逻辑。 - **cp-ns pod**：管理命名空间级配置，如模型供应商设置、租户覆盖和偏好。 推理流量通过 **Amazon VPC 接口端点** 私有连接至 Bedrock 运行时，并利用 **跨区域推理** 功能在 us-east-1、us-east-2 和 us-west-2 之间实现自动故障转移和负载分发。 ## 多模型策略的动因 Couchbase 选择多模型架构主要基于以下考虑： - **灵活性**：支持不同客户对模型供应商的偏好。 - **弹性**：在流量突发时通过跨区域推理分散负载。 - **韧性**：单一模型故障时自动切换，提升服务可用性。 ## 实际收益 在生成环境中，该架构显著降低了推理延迟和成本，同时简化了运维。通过模型无关的设计，Couchbase 能够快速迭代模型选择，无需重构整个系统。 ## 小结 Couchbase 的案例展示了如何利用 Amazon Bedrock 构建生产级的多模型 AI 架构，在保持高性能的同时，满足企业级应用对可靠性和灵活性的严苛要求。对于需要构建类似 AI 助手的团队，模型无关的架构设计和跨区域推理是值得借鉴的关键实践。
## 从传统BI到智能体AI：Tradeshift的转型之路 在AI驱动的企业服务领域，数据分析能力的升级往往意味着竞争力的跃迁。近日，全球领先的应付账款与电子发票合规平台 **Tradeshift** 分享了其从自研BI工具迁移至 **Amazon Quick** 的实践经验，揭示了智能体AI如何重塑企业分析流程。 ### 旧工具的瓶颈：数据量激增下的无力感 Tradeshift 服务于70多个国家的买卖双方，其网络每天处理数百万笔交易。随着业务扩张，自研BI工具逐渐暴露短板：单次查询最多支持1万行数据、计划报告上限25MB、仅保留6个月历史数据——这些限制使大规模趋势分析、异常检测和预测建模几乎无法实现。更关键的是，维护该工具消耗了团队约50%的人力资源，严重拖慢了产品创新节奏。 ### Amazon Quick的智能体AI方案 Amazon Quick 是一个智能体AI工作空间，能够连接企业所有应用、工具和数据。其核心功能包括： - **聊天代理**：通过自然语言进行数据问答； - **流程自动化**：无需编码即可编排多步骤工作流； - **研究报告**：跨多源自动生成长篇分析报告。 这些能力基于AWS企业级安全架构构建，为Tradeshift提供了替代方案。 ### 成果：性能飞跃与成本优化 迁移后，Tradeshift 取得了显著成效： - 查询响应时间**最高提升30倍**； - 总拥有成本**降低40%**； - 原本仅用于内部支持的嵌入式分析，转型为可直接**创收的产品**。 这一转变不仅解放了工程资源，更让业务用户能够通过自然语言直接获取洞察，真正实现了数据民主化。 ### 行业启示：AI原生分析正成为标配 Tradeshift 的案例是传统BI向智能体AI演进的一个缩影。在数据量持续膨胀、业务决策速度要求更高的背景下，具备自然语言交互和自动化工作流能力的AI平台，正逐步取代臃肿的遗留系统。对于希望释放数据价值的企业而言，拥抱智能体AI不再是一道选择题，而是一道生存题。
销售代表平均只有40%的时间花在真正销售上，其余时间被CRM更新、潜在客户研究、邮件起草和工具切换吞噬。Amazon Quick作为一款AI工作助手，能将问题转化为答案、答案转化为行动、行动转化为成果，帮助销售团队在浏览器、桌面应用或Microsoft 365等日常工具中，把更多时间还给销售。 ## 从线索到成交，全程AI赋能 **线索评分与优先级排序**是销售流程的第一道坎。面对CRM里成百上千的线索，哪些值得今天跟进？Quick通过连接CRM、邮件、网页分析和支持系统，自动分析参与度信号，动态排序购买意向，让销售代表聚焦高价值机会。自定义聊天代理还能从内部文档、商机详情和账户历史中提取上下文，提供精准建议。 **客户联系与沟通**同样被AI优化。Quick能根据客户画像和过往互动，自动生成个性化邮件草稿，甚至建议最佳联系时机。在Outlook中，销售代表可直接调用Quick生成跟进邮件摘要，无需手动整理。 **交易推进与CRM更新**是另一大痛点。Quick可实时记录通话要点、自动填充CRM字段，并基于对话历史生成下一步行动建议。例如，在会议结束后，Quick能自动创建任务、更新机会阶段，甚至提醒跟进关键决策人。 ## 行业验证与落地价值 3M、AWS全球销售和Amazon等企业已在使用Quick释放销售潜力。AWS全球销售团队通过Quick将洞察交付时间缩短了数倍，Amazon则在数千用户中部署了Quick Suite。这些案例表明，AI销售助手不仅能提升个人效率，更能规模化地加速交易周期、增强客户忠诚度。 ## 结语：时间是最稀缺的资源 销售的本质是建立信任与推动决策，而非填表。Amazon Quick将繁琐的行政工作自动化，让销售代表回归核心价值——与客户对话、理解需求、提供解决方案。对于追求增长的企业，这或许正是下一个效率杠杆。
Amazon QuickSight 正式推出 **Free Form（自由格式）仪表盘的移动端布局**，让用户在手机或平板上查看数据时无需再手动缩放或横向滚动。对于依赖仪表盘做日常决策的团队来说，这无疑是一个提升效率的重要更新。 ## 痛点：桌面仪表盘在手机上的“水土不服” 过去，当团队在晨会间隙查看营收、在会议之间回顾管道指标，或是在旅途中监控运营数据时，常常需要反复捏合缩放才能点击那些原本为大屏设计的控件。这种体验不仅耗时，还容易出错。而 Amazon QuickSight 此次推出的 Mobile Layout 正是为了解决这一痛点。 ## 核心机制：自动适配，无需作者修改 Mobile Layout 的核心逻辑很简单：当系统检测到设备视口（viewport）尺寸较小（如手机或平板），会自动将桌面端的自由格式仪表盘渲染为**单列、连续滚动**的视图。每个可视化组件会填满屏幕宽度，同时保持原始宽高比，并且依然支持交互。 更关键的是，仪表盘的**作者不需要做任何额外修改**，这一功能即可生效。读者在手机或平板上打开仪表盘时，就能立刻获得流畅、无摩擦的数据访问体验。 ## 关键能力：连续滚动与分组感知 - **连续滚动**：所有可视化组件按顺序堆叠在单列中，每个组件填满屏幕宽度，且保持原始宽高比——纵向组件保持高长，横向组件保持宽长。 - **分组感知渲染**：自由格式仪表盘中常会出现重叠的可视化组件（例如 KPI 数值叠加在彩色背景上）。Mobile Layout 能够识别组边界，将属于同一组的组件作为一个整体渲染，保留原有的层次设计。 - **读者控制**：在 QuickSight 移动应用中，读者可以通过控制选项进一步调整视图。 ## 可用性与优化建议 目前，**Mobile Layout 已在所有支持的 AWS 区域上线**。虽然该功能开箱即用，但官方建议仪表盘作者可以进一步优化，以确保移动端的显示效果达到最佳。例如，适当调整组件的尺寸和布局，避免过小的文字或元素。 ## 行业意义：移动 BI 体验再升级 在移动办公日益普及的今天，BI 工具的移动端体验已成为企业选型的重要考量。Amazon QuickSight 的这一更新，直接降低了用户在移动设备上使用仪表盘的门槛，使得数据分析能够真正融入日常工作流的每一个环节，而不再局限于办公桌的电脑屏幕。
Smartsheet 是一款企业级工作管理平台，被数十万组织所信赖。随着企业团队采用 AI 代理，这些代理需要结构化地访问 Smartsheet 等系统中的数据，但大多数系统并非为此而设计。为了弥合这一差距，Smartsheet 在 AWS 上构建了一个远程模型上下文协议（MCP）服务器，使 AI 客户端能够直接访问其数据和功能。Amazon Quick 和 Claude Desktop 等 AI 助手通过自然语言帮助用户与 Smartsheet 交互，分析项目数据、更新任务、创建表格、管理工作区等。企业还在为无需人工提示即可运行的工作负载构建自定义 AI 代理。这些 AI 代理可以自主工作，通过 MCP 在 Smartsheet 中进行协调，例如捕获需求、接取任务、附加测试结果、起草文档等。它们与人类同事使用相同的表格，将原本需要数周的工作流程压缩到数天甚至数小时。 MCP 服务器连接到 Smartsheet 现有的 API 和中央智能层，并在此基础上添加了 AI 优化接口，旨在最小化 Token 成本、防止幻觉，并帮助大语言模型（LLM）可靠地处理企业数据。自上线以来，Smartsheet 通过这些优化节省了超过 30 亿个 Token（基于内部遥测数据）。 ## 架构概览 统一的 MCP 层同时服务于内部和外部代理。Smartsheet 自家的 Smart Assist（产品内 AI 体验）和 Amazon Quick 等外部连接的 AI 客户端运行在相同的基础设施上，共享相同的工具、优化和智能栈。这种对等性是刻意的架构选择：Smartsheet 一次构建，所有代理客户端立即受益。 数据路径中关键的 AWS 服务包括： - **AWS Fargate**（用于 Amazon ECS）：运行无状态服务器容器。 - **Amazon Kinesis Data Streams** 和 **Amazon Managed Service for Apache Flink**：用于将变更事件摄入到 Amazon S3。 - **Amazon Bedrock** 和 **Amazon Neptune**：用于 LLM 推理和知识图谱。 ## 安全与治理 Smartsheet 的 MCP 服务器在 AWS 上实现了细粒度的安全控制。每个 AI 客户端都经过身份验证和授权，确保只能访问其被允许的数据和操作。通过集成 AWS Identity and Access Management（IAM）和 Smartsheet 自身的权限模型，企业可以精确控制 AI 代理的访问范围。 ## 扩展与部署 利用 AWS Fargate 的弹性，MCP 服务器可以根据负载自动扩展。Smartsheet 采用持续部署流水线，确保更新快速且可靠地推送到生产环境。事件流架构通过 Kinesis 和 Flink 处理高吞吐量的变更数据，保证实时性。 ## AI 特定优化 Smartsheet 在 MCP 服务器中设计了多项 AI 优化： - **Token 成本优化**：通过精简 API 响应、缓存常用查询和压缩上下文，大幅减少每次调用的 Token 消耗。 - **幻觉缓解**：结合结构化数据源和知识图谱（Amazon Neptune），LLM 在生成回答时能引用真实数据，减少编造信息的风险。 - **可靠的企业数据访问**：MCP 服务器提供一致的接口，使 LLM 能够以低错误率执行创建、读取、更新、删除操作。 ## 总结 Smartsheet 在 AWS 上构建的远程 MCP 服务器展示了如何将企业级工作管理平台与 AI 代理无缝集成。通过统一的架构、强大的安全治理和针对 AI 的优化，Smartsheet 不仅提升了自身产品的智能化水平，也为企业客户构建自定义 AI 工作流提供了坚实基础。这种模式有望成为未来企业 AI 集成的参考架构。
## 托管知识库：企业级 AI Agent 搜索的三大支柱 Amazon Bedrock 近日宣布 **Managed Knowledge Base** 正式全面可用（GA），这是一项完全托管的代理检索服务，旨在帮助企业快速构建基于自有数据的 AI Agent 和生成式应用。传统上，构建企业级知识库需要团队自行拼合数据连接器、解析器、向量存储、知识图谱和检索逻辑，再将其投入生产环境，整个过程往往耗费数天甚至数周。而 Bedrock 托管知识库通过三大支柱——**简化设置**、**更智能的检索**和**生产就绪**——大幅降低了这一门槛。 ### 简化设置：从零到首次检索只需几分钟 开发者以往需要分别采购和搭建数据摄取管道、向量/图存储以及检索基础设施，这意味着要管理多个独立服务、不同的计费模型和速率限制，并将它们拼凑成连贯的流水线。Managed Knowledge Base 将这一复杂性彻底抽象化：你只需配置一个知识库，服务就会自动处理后续所有环节——从通过原生连接器摄取企业数据，到为你管理向量存储。 目前，该服务提供了 **6 个原生连接器**，包括 Amazon S3、Microsoft SharePoint、Atlassian Confluence、Google Drive、Microsoft OneDrive 和 Web 爬虫。此外，还提供**直接摄取 API**，用于处理不在支持来源中的文档。通过 AWS 管理控制台即可快速上手，无需选择模型，智能默认设置让你在几分钟内完成首次检索，而以往搭建类似管道通常需要数天甚至数周。 ### 更智能的检索：高精度与灵活定制 在简化基础之上，Managed Knowledge Base 并未牺牲检索质量。它支持多种检索增强策略，包括**嵌入模型**、**重排序器**和**分块策略**的灵活选择，开发者可以根据业务需求调整这些参数以获得最佳召回率。例如，对于需要高精度的场景，可以使用重排序模型对初步结果进行二次排序；对于多模态文档，系统能够解析并处理混合内容。 这种智能检索能力让知识库能够应对复杂查询，在多样化的内容间进行推理，从而为 AI Agent 提供更准确的上下文。 ### 生产就绪：安全、可观测与弹性扩展 生产环境对知识库的要求远不止于功能。Managed Knowledge Base 内置了**文档级访问控制**（ACL），确保不同用户只能访问其授权范围内的数据。同时，服务提供完整的**可观测性**和**安全**机制，并自动处理弹性扩展，无需手动规划容量。 ### 代码示例：快速上手 AWS 官方提供了 Python 代码示例，展示如何通过 SDK 创建知识库并执行检索。以下是一个简化流程： 1. **创建知识库**：指定名称、存储配置（如 OpenSearch Serverless）和嵌入模型。 2. **添加数据源**：通过 S3 连接器或直接摄取 API 导入文档。 3. **同步并查询**：调用 `retrieve` 或 `retrieveAndGenerate` API 获取相关段落。 ```python import boto3 bedrock_agent = boto3.client('bedrock-agent') # 创建知识库 response = bedrock_agent.create_knowledge_base( name='MyEnterpriseKB', roleArn='arn:aws:iam::123456789012:role/BedrockKBExecutionRole', knowledgeBaseConfiguration={ 'type': 'VECTOR', 'vectorKnowledgeBaseConfiguration': { 'embeddingModelArn': 'arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0' } }, storageConfiguration={ 'type': 'OPENSEARCH_SERVERLESS', 'opensearchServerlessConfiguration': { 'collectionArn': 'arn:aws:aoss:us-east-1:123456789012:collection/my-collection', 'vectorIndexName': 'my-index', 'fieldMapping': { 'metadataField': 'metadata', 'textField': 'text' } } } ) ``` ### 行业影响与展望 作为 AWS 在生成式 AI 领域的重要布局，Bedrock Managed Knowledge Base 直接回应了企业落地 AI Agent 时最大的痛点——**数据基础设施的碎片化**。通过将连接器、存储、检索和安全整合为一项托管服务，AWS 不仅降低了开发门槛，更让企业能够将精力集中在业务逻辑和模型优化上。 未来，随着更多数据源连接器的加入（如数据库、CRM 系统）以及对多模态检索的深度支持，该服务有望成为企业构建 RAG（检索增强生成）应用的首选基础设施。对于正在探索 AI Agent 落地的团队而言，现在正是试用 Managed Knowledge Base 的最佳时机。
xAI 的 Grok 4.3 现已通过 Amazon Bedrock 正式可用，为构建智能体和 AI 工作流的团队带来一款在长输入上可靠推理的模型。该模型支持可配置的推理努力级别（无/低/中/高），允许用户根据任务灵活平衡速度与深度：简单分类用“无”保持低延迟，合同分析等复杂任务用“高”以获得深度推理。Grok 4.3 拥有 **100 万 Token 上下文窗口**，可处理长篇文档和持续多轮对话；支持文本和图像输入，并具备强大的工具调用与指令遵循能力，非常适合智能体场景。 根据 xAI 的数据，Grok 4.3 在多项基准测试中表现领先：在 **Artificial Analysis Omniscience 基准**上排名第一，**幻觉率最低**；在 **Tau2 Telecom 基准**（客服工具调用）和 **Vals AI 案例法与企业金融基准**（文档理解）上也均位列榜首。xAI 还宣称该模型位于“智能-成本帕累托前沿”，每美元提供的智能是其他前沿模型的 2 到 10 倍。 在 Amazon Bedrock 上，Grok 4.3 运行于新一代推理引擎 Mantle，确保高性能。开发者可通过 Bedrock API 快速集成，实现基础聊天、结构化输出、图像输入、有状态多轮对话等能力。 ### 关键能力一览 - **可配置推理努力**：按请求设置 none/low/medium/high，同一模型适配从快速分类到深度分析的全范围任务。 - **低幻觉率**：在 Omniscience 基准中排名第一，适合对准确性要求高的企业场景。 - **百万级上下文**：100 万 Token 窗口，轻松处理整本小说或复杂文档。 - **多模态输入**：支持文本和图像，输出为文本。 - **工具调用与结构化输出**：原生支持函数调用，便于构建智能体和结构化数据提取。 ### 快速上手示例 通过 Amazon Bedrock 使用 Grok 4.3 的 Python 示例（使用 boto3）： ```python import boto3 bedrock_runtime = boto3.client('bedrock-runtime') response = bedrock_runtime.converse( modelId='xai.grok-4.3', messages=[ { 'role': 'user', 'content': [{'text': 'Explain the concept of reasoning effort in AI models.'}] } ], inferenceConfig={ 'maxTokens': 1000, 'temperature': 0.7, 'additionalModelRequestFields': { 'reasoning_effort': 'high' } } ) print(response['output']['message']['content'][0]['text']) ``` 开发者可通过 `additionalModelRequestFields` 传入 `reasoning_effort` 参数，实现细粒度控制。 ### 行业影响 Grok 4.3 的加入进一步丰富了 Amazon Bedrock 的模型生态。对于企业用户，低幻觉率和可配置推理意味着可以更放心地将模型应用于法律、金融等高风险领域。而 xAI 强调的“每美元智能”性价比，也可能推动更多中小团队尝试前沿模型。 随着智能体工作流日益复杂，Grok 4.3 的百万上下文和工具调用能力使其成为构建长流程、多步骤任务的理想选择。未来，xAI 与 AWS 的合作或将带来更多专属优化与集成。
餐厅每月平均漏接 150 通电话，其中约 60% 是顾客想下单或订座。这些电话多集中在晚餐时段，正是服务员最忙的时候。本文介绍如何利用 Amazon Bedrock AgentCore 和 Amazon Nova 2 Sonic 构建语音订餐系统，自动接听电话并完成从问候到确认的完整流程。 ## 系统架构三层分离 系统分为 **电话层**、**代理层** 和 **后端层**。电话层通过 Amazon Chime SDK Voice Connector 提供 SIP 中继和免费号码，音频经 SIP 网关通过签名的 WebSocket 连接流向代理层。代理层使用 Amazon Nova 2 Sonic 处理实时语音，支持转录、轮流对话和打断。后端层通过 **模型上下文协议 (MCP)** 与代理连接，管理菜单、购物车、订单和门店信息。 分层设计的关键优势在于：**订餐逻辑与通信渠道解耦**。未来添加移动应用或自助点餐机等新渠道时，无需重写后端；同时 MCP 作为开放标准，后端变更也不影响代理层。 ## 核心技术亮点 - **Amazon Bedrock AgentCore**：托管并运行代理，支持文本和音频双向输入输出，在单一双向流中处理转录、轮流对话和打断。 - **Amazon Nova 2 Sonic**：提供实时语音能力，确保通话自然流畅。 - **MCP 集成**：代理通过 MCP 工具调用后端服务，实现菜单查询、下单等操作。 - **通话预热**：在电话振铃期间预先启动代理会话，用户接听后无延迟感。 ## 部署与实现 完整堆栈通过 **AWS Cloud Development Kit (AWS CDK)** 部署，包括： - 电话侧：Amazon Chime SDK Voice Connector 提供 SIP 中继和免费号码。 - 代理侧：Amazon ECS on AWS Fargate 运行 SIP 网关，将电话呼叫桥接到代理。 - 后端：标准 RESTful 服务，通过 MCP 暴露接口。 ## 行业意义 餐厅电话漏接问题长期存在，传统方案如增加人手或鼓励在线下单都各有局限。本方案直接解决“只想打电话”的顾客需求，且架构灵活，可扩展至其他行业。对于 AI 语音应用开发者，该方案展示了 **AgentCore + Nova 2 Sonic + MCP** 的组合能力，为构建实时语音交互系统提供了参考范式。
房地产金融领域的文档处理复杂且高度依赖人工，影响关键业务决策的效率。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.