AI案例

问题

数字营销要连接广告平台、素材、文案和效果数据，重复配置与跨系统衔接会消耗运营时间。Advolve从AI原生平台出发，希望把这些步骤串起来；创始人认为多系统连接需要可靠验证和代码支持。原文没有提供完整旧流程人员数、每个步骤耗时或具体失败率，因此不把这些需求改写成独立测量结论。

方案

据Anthropic官方客户故事及创始人João Sobreira披露，团队先从静态创意素材和文案开始，让AI智能体按背景、画面、字体和文案等层生成、评估，并参考过去表现好的广告数据。之后扩展到跨平台广告活动配置、部署、内容适配和优化，使用机器学习动态分配平台预算。Claude承担中央推理、编排和技术验证等辅助任务，但预算分配还有机器学习组件，不能把所有功能都说成Claude单独完成。创始人称选型时做过LLM评估，看重代码生成、幻觉率和验证能力；来源未公开评测集、得分和生产错误率，这只是该团队的选型披露，不是“保证无幻觉”。该案例是有工程整合和历史广告数据的平台实践，原文没有披露每条广告的人审制度或可直接复制的部署配置。

问题

这所捷克学校服务一年级至九年级的400多名学生，有24间具备Wi-Fi的教室，位于校长所说的经济相对困难地区。教师需要准备不同难度的教学材料，校方要处理超过30页、包含法规术语的文件；约15%学生来自其他国家，家校沟通有语言需求。这些是案例背景，不是AI产生的收益。学校已有Microsoft 365 A3环境，希望减少准备和信息整理负担，把时间留给学生和教师协作。

方案

据微软客户故事，学校在2024年初开始培训约30名教师使用Copilot。IT与英语教师Tomáš Glazer先给出教案要覆盖的具体点，用AI辅助准备；在Forms中指定约200词、包含英语一般过去时动词的练习，生成测验和答案，再检查可能的小错误、调整内容及学生水平和难度。当学生不理解语法概念时，他还请求三到四种不同讲解策略，作为教师选择方法的材料。校长Petr Mach用Copilot概括30页或更长的复杂规定，减少整理信息的时间。教师把学校政策文件翻译给不同语言的学生与家长；原文未公开翻译准确率或复核制度，所以不能写成无需译者或必然正确。整个已披露流程仍有教师参与，而不是把生成题目、答案或法规摘要直接认定为权威。

问题

Premier Support为企业客户处理硬件、软件与外设问题。原客服系统分散，坐席需要额外收集、查看资料，同时处理重复事务；团队希望更快响应增加的咨询需求。原文介绍该服务在全球有数千名支持坐席，但没有公开此次Copilot上线覆盖的人数、任务基线或统计样本，不能把全球坐席数当作测量样本。

方案

联想选择Dynamics 365 Contact Center和Dynamics 365 Customer Service，两者都带Copilot；公司其他销售和专业服务人员已有Customer Service使用经验，这是选型背景。上线面向客户的服务前，团队先让最有经验的Premier Support客服代表测试聊天助手。实际工作链条是：客户以自然语言说明问题→系统利用数百万次历史服务交互向坐席提供解决建议→坐席减少资料收集与查看，把时间用于解决问题→通话结束后Copilot生成详细摘要和关键行动项。原文明确保留客服代表的服务角色。案例称客户可以全天以九种语言与Copilot及客服代表交互，但未证明每种语言的准确率，也没有说明所有请求无需人工处理。

问题

公司此前依赖五到六种生产力工具，安全管理和审计需要跨系统切换、临时授权与手工截图，综合报告要花时间准备数据或请外部人员协助。不同软件制作的演示文稿发给客户会变形，影响沟通。原文给出这些具体痛点，但未公开统一的任务耗时基线、迁移预算或完整参与人数。

方案

实际流程分成两层。第一层是办公环境整合：公司由微软合作伙伴Points Information Technology支持迁移，先选不同部门的五到六人试用，观察资料共享和文档兼容，再推进使用；这不是全公司部署人数。E5中的Purview、Intune和Entra ID把数据、设备和身份相关材料集中展示，减少原先跨系统准备审计证据的工作。第二层才是Copilot辅助业务：销售人员记录客户会议，提取行动要点，再给客户发送下一步邮件；营销人员先得到演示稿初稿，再自行细调，并利用资料检索找回文档中的信息；财务人员使用Copilot in Excel辅助复杂公式、探索表格功能，并把数据转成演示或邮件。原文还说Power BI仪表板从外部管理转为内部管理，但没有证明Copilot自动搭建并验证了整个仪表板。开发人员将会议行动点关联到已有工单或手册，使管理层可以跟进讨论与执行。Teams中的共同编辑和客户沟通也是流程改善的一部分，不能单独归因于Copilot。

问题

Talan是一家国际科技与咨询集团，需要让内部团队先理解AI如何参与日常工作，再为客户提供采用建议。咨询人员要同时处理客户会议、邮箱、投标材料和资料检索；招聘人员需要准备职位描述、外联文本和面试问题；营销人员需要起草网页内容。原文明确提到信息过载、边开会边记笔记和内容起步困难，但没有披露各岗位统一耗时基线或明确的招聘失败率。团队不是给所有人同一种用法，而是逐个业务职能识别需要。

方案

根据官方案例，Talan分别为HR、招聘、销售、营销和咨询等职能识别用例。咨询人员在会议中使用Copilot记录与总结，让自己更专注客户交流；会后或日末，人员要求它概括关键邮件或整个收件箱，辅助查找资料、制作文档、投标和售前回复。招聘人员先用它起草职位描述、候选人定向沟通和面试问题，再用于Teams面试记录，并把发现分享给后续面试经理；这里的AI辅助文本与记录并不是自动作出录用决定。营销人员使用关键词研究、网页文本起草和提纲建议，仍由岗位人员形成内容。推广方面，Talan建立员工代表与Copilot大使、内部用户社区，在Viva Engage每周分享主题用例，通过Teams举办英语、法语、西班牙语网络研讨会，并把员工贡献的提示词整理成可按工具和岗位筛选的库。这些做法把训练与实际任务连接起来，而非只有一次培训。涉及外部候选人录音时，受访者表示使用Microsoft Purview帮助管理数据生命周期与GDPR相关要求；这不是智探AI对其全面合规、候选人同意或权限配置完成独立审计的结论。

问题

微软官方客户案例记载，U.S. Venture及汽车零部件分销部门U.S. AutoForce在业务增长中同时面临旧ERP难操作和会计手工处理负担。集团披露超过5500名员工，分布于70个配送枢纽、仓库及办公室；这些是组织背景，不是AI使用人数。对账是财务中重复、耗时的任务，团队选择先在信用卡交易与银行流水两项经常性工作中使用Copilot，而不是证明一次AI部署解决所有运营问题。

方案

已实施的AI部分：U.S. AutoForce将 Microsoft 365 Copilot for Finance 用于信用卡交易和银行流水对账。案例说明该产品结合Microsoft 365 Copilot与Excel财务智能体，可摘要表格、查询和处理财务数据；本案例的具体落点是月度对账，所据正文未公开逐步配置、具体匹配算法或自动审批规则。不同项目需要分开：Dynamics 365 Finance于2021年引入，Supply Chain Management在2023年扩展，U.S. AutoForce于2023年3月上线相应Dynamics系统。大批发票导入、收货匹配、审批和付款流程来自Dynamics结合EDI/OCR等改造；订单和仓库履约改善也属于供应链项目，不可全部写成Copilot for Finance的效果。来源另述供应链场景的Copilot可检索110条操作流程，这是独立的问答应用，不是财务对账收益。

问题

Anthropic官方案例中的PCV是一家服务小企业的社区贷款机构，不是本案例所指的传统风险投资基金。团队发现，选择题问卷虽能触达大量人，却容易丢失员工真实感受；深访能保留细节，但小团队一次只能覆盖少数人。它服务的许多小企业没有大型公司的HR团队，员工也未必愿意直接向老板表达意见。另一个信贷材料处理问题属于仍在开发的承保项目，不能与已运行调查混为一谈。

方案

已运行的工具是AIKKA，PCV自行开发的手机语音调查工具。参与者自愿用母语回答开放问题，每次最多五分钟；转录引擎先把语音变成文本，再由通过API运行的Claude Opus标注情感、情绪和主题，汇入随回答更新的看板。来源没有说语音转录本身由Claude完成。团队早期几乎逐条手工审阅，经过一段时间的核对后改为抽查，数据科学家仍需监测、评价、解释结果。PCV再将工人反馈去掉姓名并整理给经营者，用于围绕留任和工作满意度开展反馈讨论，而不是让AI替管理者作出人事决定。PCV的测试明确确认英语、西班牙语、印地语和旁遮普语准确性；不能因此宣称中文或所有语言均已验证。

问题

据Anthropic官方客户案例，HubSpot不同团队面对的工作并不相同：营销需制作大量素材并保持活动上下文一致；客户成功经理难以为所有客户持续准备个性化建议和后续材料；工程师则需处理分布式代码库、迁移和维护。客户成功经理Sarah Caruthers表示，以前一份个性化客户材料可能要花一小时甚至更久，因此只能优先服务部分重点客户。

方案

营销与客户成功：团队先整理上下文和明确指令，放进共享Claude projects；营销结合projects与artifacts集中活动背景并创建内容，客户成功经理用Claude准备客户对话和个性化跟进材料。原来的手动整理、逐份起草变为基于共享上下文形成初稿，再由负责人员核对后用于沟通。工程侧独立使用Claude Code，并借助MCP连接既有服务和内部系统，辅助理解代码、开发和迁移；这是工程场景，不能把其效果归到营销或客户成功。人工核对客户事实、承诺及代码行为是智探AI基于案例提出的实践建议，不是来源披露的额外成效。

问题

微软官方客户案例记载，荷兰电信与ICT服务商KPN原来同时使用Microsoft 365和Salesforce开展营销、获取线索和管理销售，销售周期可达四至九个月。员工需要在CRM、邮件和会议记录之间反复查找及手动更新资料，希望减少例行任务并提高客户数据质量；并非原来没有CRM。

方案

KPN 将 Microsoft 365 Copilot for Sales 与 Salesforce CRM、Microsoft Graph 中的沟通资料及办公应用连接。工作流中，销售在 Outlook 或 Teams 查看客户联系人、商机状态、交易金额及最近沟通摘要，用于会前准备；用助手起草邮件、报价和提案，将技术材料改写成易懂的文字，或提炼RFP重点，再由销售人员结合客户要求核对和使用；客户邮件和会议笔记可从 Outlook/Teams 存回 Salesforce，减少跨应用寻找资料。案例还描述销售通过提问查询既有客户记录。以上是团队披露的实际应用，不表示AI能独立确认报价、客户承诺或所有历史信息的准确性。

问题

根据微软官方客户案例，Coca-Cola Andina 的员工分布在阿根廷、智利、巴西和巴拉圭等地，福利和HR政策随国家、地区、合同类型等条件变化。原来员工常向HR反复询问基础问题，偏远装瓶厂员工尤其难及时获取适用答案；不能把同一政策答案直接发给所有员工。

方案

该团队在阿根廷业务中用 Microsoft Copilot Studio 构建 HR 助手 Andi。工作步骤是：员工用企业凭据登录，系统通过 Microsoft Entra ID 关联其工作地点、职位等档案信息；结合其他员工资料，在 SharePoint 知识库查找适用政策，再以自然语言回答。每次回答后仍提供联系HR的选项：员工填写问题，Andi 将问题和员工档案通过 Power Automate 流程送入作为内部CRM的 Power App，生成工单并通知对应HR经理，由人工跟进。开发团队与HR专家协作，按公司政策反复调整提示；官方案例记载开发中进行了数百次提示修改。已通过 Direct Line API 接入 WhatsApp，方便不常接触 Teams 的装瓶厂员工使用。案例中的 Teams 集成仍在收尾；接入 Azure AI Document Intelligence 处理聊天图片中的票据、发票属于未来计划，不是已完成能力。

问题

微软官方客户故事中，MultiChoice的IT PMO负责网络升级、呼叫中心系统和成本优化等技术项目，负责人称团队有20多名项目经理，常见会议有4至50名参与者。连续会议后还需手工整理纪要与行动项；项目经理Sana Abbas自述过去每小时会议需约半小时相关行政工作，延迟沟通容易让成员对任务产生不同理解。这是本团队访谈描述，不能代表集团全部员工。

方案

按官方案例，团队采用Microsoft Copilot生成会议纪要与摘要，按角色整理行动计划，并在会议临近结束时提醒检查行动项。Abbas称会利用这一环节回顾讨论、确认成员对行动项理解一致，再发布纪要；负责人Sonal Panchal-Malindi称初期曾把自己记录的行动项与Copilot输出进行比较。它辅助记录和核对，不意味着AI直接作最终决策。受访者另称使用过会议情绪判断及利弊分析；原文未提供准确率、偏差测试或隐私治理细节，本稿不将“中立、无偏见、情绪识别准确”作为已验证能力。

问题

BCE在澳大利亚昆士兰为超过146所天主教学校提供教育服务。微软官方案例称，行政任务、合规要求和课程准备增加了教育者负担，学校也希望让学生从被动接收转向主动学习。原文提到澳大利亚教师职业压力研究，但未在存储正文中给出可核验研究出处，本稿不使用其离职意愿比例。

方案

按微软官方案例，BCE向12,500名教育者和员工推出Microsoft 365 Copilot；先了解邮件、行政、课程内容和评估反馈的耗时及顾虑，再把负责任AI基础培训、模拟练习、按需微培训、协同备课和课堂辅导融入日常工作，每校设置受训的AI Captain同伴导师。学校领导用AI起草政策、梳理课程标准和沟通材料，教师用它拆解标准、准备学习计划。另一个13岁及以上学生Copilot Chat预览中，Trinity College学生用AI生成项目问题、对照学习标准和检查进展；一名学生请求将作业重新排版以便阅读障碍情况下阅读，西班牙语课堂共同设计评估任务并各选主题。原文说明教师控制何时打开电脑及允许AI参与的环节；不是AI代替教师评价或替学生完成学习。

问题

微软官方案例称，Chin Hin业务多元、人员支持和人才发展流程分散，需要减轻HR与行政重复工作并统一培训。案例披露其探索研讨会认为重复任务最多占这些团队时间的70%；该比例未披露测量方法，不代表全部集团员工，也不是部署后的节省比例。

方案

按官方案例，公司设立卓越中心（CoE）协调HR与培训，从114个Copilot席位开始、随采用情况逐月扩展；设计4套对齐Microsoft徽章的课程及内部认证，举办培训和AI黑客松。员工将Copilot用于提案草稿、工地与安全报告摘要、采购比较、财务及董事会报告；Teams Rooms提供会议摘要，供分布式团队用于会后文档和协作。其“接入现有流程→自动化工作流→智能体”是采用方法论，原文不能证明全部流程已由智能体替代。

问题

FPT Software 希望在满足隐私、数据保护和企业合规要求的前提下提升后台效率，并积累支持客户使用AI的经验。原文描述：HR需处理政策草稿、福利邮件、离职因素数据及Maya聊天机器人定期报告；财务需从大量聊天、邮件和长篇税务文件提取信息，原来主要依赖人工汇总和检索。

方案

按微软官方客户案例，FPT先从约500名后台员工试点，覆盖HR、业务流程、财务与营销；先进行内部宣传和LinkedIn学习，再观察实际应用。营销团队用Clarity热图定位网站问题，参考Copilot建议修改主页部分内容与路径；HR用Copilot辅助数据分析、政策草稿和Maya报告；财务用Copilot查找及摘要聊天、邮件和税务文件，并辅助Excel报告。这里描述的是员工使用AI建议的工作流，不是AI独立做出税务或人事决策的证据。

问题

客服代表需要手动从分散的邮件和笔记中查找案例信息并整理为连贯记录，每次对话后还需手动撰写摘要，耗时且影响客户关系建立。

方案

AIA 在 Microsoft Dynamics 365 Customer Service 中部署 Copilot，利用生成式 AI 自动汇总案例历史和对话，辅助撰写客户邮件，并提供基于企业知识的洞察。

问题

各团队自行试用生成式 AI，形成分散且不受管理的工具，存在敏感客户与保险数据暴露风险；需要让员工无需深厚技术能力即可自建和使用 AI 代理，同时保持安全、集中治理、成本透明并满足金融行业数据保护与合规要求；基础聊天接口缺乏基于内部数据的上下文响应、多步骤工作流、机构数据集成和集中治理能力。

方案

结合开源 Strands Agents（构建代理）、Amazon Bedrock AgentCore（生产运行、会话隔离、按用量计费）和 LibreChat（用户管理、token 预算、多模型支持）构建集中治理的平台。部署于 AWS 欧洲（法兰克福）区域单一 VPC；通过零信任与中转网关实现私密连接；LibreChat 容器化运行在 Amazon ECS on Fargate；数据层采用 DocumentDB、ElastiCache、RDS for PostgreSQL、OpenSearch Service、EFS 和 S3；代理层运行于 AgentCore runtime，经 API Gateway 和 Lambda 暴露给 LibreChat。每个请求以登录员工身份执行，LibreChat 通过 Microsoft Entra ID 认证并服务端传递身份，处理与数据保持德国境内。

问题

现有 CCTV 系统多为被动录像，检测不安全状况需人工审查 15-45 分钟；控制室操作员无法可靠同时监控数百路视频；合规执行不一致，每班仅 2-3 次人工巡检；增加摄像头会提高成本但安全结果提升有限。

方案

Tata Elxsi 构建 IRIS（Industrial Real-Time Intelligence System）平台，采用边缘过滤、元数据流、SageMaker AI 计算机视觉推理、关联层、告警与存储的架构，通过 AWS IoT Greengrass 在边缘抽帧并过滤，仅上传安全相关帧和结构化元数据，在云端运行 YOLOv8、SlowFast 等模型进行检测，经 Lambda+DynamoDB 关联层减少误报，并按严重级别触发告警。

问题

宝马集团运营超过 14,000 个云账户，成本异常难以发现。原有仪表盘只能被动展示已发生费用，且需要用户主动打开查看，无法及时预警异常支出。

方案

宝马集团与 Data Reply 合作构建了内部 FinOps 系统 CLEA，基于 AWS 无服务器架构和 Prophet 预测模型。系统每日摄取 AWS Cost and Usage Reports 及其他云厂商账单数据，聚合成每账户每服务的每日成本时间序列，使用 Prophet 基于 365 天历史进行预测。通过 AWS Step Functions 分布式编排，并发最高 500 个 Lambda 函数，对全部账户进行预测和异常检测。检测结果经过分层过滤（低支出排除、偏差阈值、账户集群最低影响金额、服务特定阈值、账户特定覆盖）后，向账户所有者发送告警邮件，并提供 Amazon QuickSight 自助根因分析仪表盘。

问题

原有第三方质检解决方案不透明，QA判定缺乏可追溯性，服务场景组合复杂导致规则维护成本高，响应质检标准变更缓慢，且缺乏主动趋势发现能力，无法及时识别高频问题。

方案

与 AWS 合作，基于 Amazon Bedrock 构建自有的智能质检系统，包含意图验证、合规评估和客户之声（VOC）分析三条核心流水线。系统通过精确上下文管理，采用信息隔离、动态提示组装和多阶段处理等方式，提升质检准确性和效率，并利用 Amazon Bedrock Guardrails 实现负责任 AI 控制。

问题

数据保护和灾难恢复团队面临环境规模扩大、信息碎片化、手动收集上下文耗时、经验不足管理员难以解读症状、缺乏快速风险摘要等问题，导致故障解决延迟。

方案

HPE Zerto 使用 Amazon Bedrock 构建了一个多智能体故障排除系统，嵌入现有 Zerto UI，本地部署，通过 Strands Agents 框架和 MCP 服务器访问实时环境数据，结合 Amazon Bedrock Guardrails 和 Knowledge Bases，提供自然语言交互和可操作的上下文答案。

问题

散户投资者需要基于付费市场、宏观经济、基本面和另类数据的研究，但这些数据分散在付费墙和定制 API 后，企业合同在用户规模不足时难以合理化。按查询购买数据虽经济，但需要代用户进行支付并满足保管、限额、审计要求，涉及身份持久化、跨会话状态、隔离代码执行、支付编排和端到端追踪，自建基础设施需数月。

方案

Heurist 在 Amazon Bedrock AgentCore 上部署代理，使用 Strands 编排和 Anthropic Claude，利用 AgentCore Identity、Memory、Code Interpreter、Observability 和 payments 等服务。通过 x402 协议和 USDC 在 Base 区块链上进行按查询付费，支付凭据保存在 AWS Secrets Manager；AgentCore Code Interpreter 提供无网络出口的隔离沙箱；AgentCore Memory 存储用户偏好和对话历史；Amazon Bedrock Guardrails 过滤输入输出；分析产物存储于 Amazon S3，追踪发送至 CloudWatch。

问题

银行、航空、保险、制造和政府机构等受监管行业依赖的核心系统具有严格的安全和合规要求，需要可信赖的AI能力来提升运营效率并加速现代化，同时不能违反合规约束。

方案

DXC与Anthropic建立多年全球联盟，将Claude集成到DXC运营的系统和客户环境中。DXC首先在内部使用Claude构建OASIS平台，验证其能力；随后培训数千名Claude认证的前向部署工程师，并基于Anthropic Academy增加针对任务关键型系统的自有课程，从保险、现代化即服务、网络安全和应用服务四个领域开始向客户推广。

问题

马里兰州需要提高政府运营效率，帮助居民更便捷地申请福利，并减轻案件工作人员每月人工处理超过150,000份文件的工作负担。

方案

马里兰州与Anthropic合作，在多个州机构部署Claude，包括开发Claude驱动的虚拟助手帮助居民申请SNAP、Medicaid、临时现金援助和WIC等福利，并识别其他可能符合资格的项目；案件工作人员使用Claude验证文件、资格和复杂政策指导；探索面向早期职业专业人士的AI技能提升试点；与州长创新团队合作开发工具识别社区未满足需求。此前，马里兰州已于2025年6月推出双语Claude聊天机器人，服务超过600,000名SUN Bucks福利领取者。

问题

大规模容灾中，选择恢复工作流、确认资产就绪以及处理恢复中的异常（如变更冻结窗口）依赖经验丰富的值班工程师的隐性知识；现有集中式系统 EWOK 解决了执行问题，但未解决决策问题。

方案

构建 EWOK Agent：将故障转移知识编码为类型化技能（YAML 模式 + 提示词体），通过 Amazon Bedrock 的 Converse API 和工具调用机制，让基础模型选择技能并生成结构化工具调用，然后由确定性执行层 EWOK 的 API 执行实际故障转移；模型不直接持有凭证，所有状态变更均通过受审计的代码完成。

问题

代理系统需要自主支付第三方服务，但直接给代理钱包存在风险：缺乏消费限制、凭据暴露、无法审计，以及可能支付给不可信端点。人工审批无法跟上机器速度。

方案

t54 构建了 x402-secure 信任层，与 Amazon Bedrock AgentCore payments 集成。x402-secure 提供实时端点评分（Trustline），在支付前进行确定性信任门控。Amazon Bedrock AgentCore payments 提供会话级消费限额、凭据隔离和支付执行。通过 IAM 角色分离确保代理不能修改自身限额或访问凭据。

问题

生成式 AI 支出与行为挂钩，缺乏按用户可见性和成本问责；在扩大 AI 访问前，领导层需要知道每人花费、能否限制以及 ROI。

方案

Jamf 构建了基于 Amazon Bedrock 调用日志、Amazon Athena 成本视图、AWS Lambda 定时执行和 IAM 客户托管策略的系统，按工程师每日预算实施分层模型限制，并在接近预算时通过 Slack 通知。

问题

在规模化过程中，单一模型难以承载完整工作流，通用推荐不满足残障学生需求，合规与数据保护要求严格。

方案

在 AWS 上构建分层六智能体架构，采用 Amazon Bedrock、Lambda、DynamoDB 等服务，实现对话式个性化过渡规划和合规控制。

问题

业务智能仪表板的内容故障（空白图表、陈旧数据、错误数值）具有静默性，基础设施监控无法发现，用户报告率不足 1%，且错误数值可能传播到基于数据的 AI 叙事系统，影响决策。

方案

构建了五阶段无服务器验证架构，结合两种并行 AI 验证机制：视觉完整性验证使用 Amazon Bedrock 上的 Claude 模型分析截图，识别空白瓦片、错误状态和缺失可视化，并进行上下文推理区分合法空态与故障；数值一致性验证使用 LLM 提取指标值，由确定性代码进行单位归一化和精度比较，确保数值判断精确。截图先通过 Amazon Rekognition 进行脱敏，警报通过 Slack 和工单路由到负责人。

问题

Natera 希望改变患者体验，替代人工预约电话；原有系统使用第三方 AI 提供商进行语音交互和编排，存在准确性、可扩展性和对话参与度方面的改进空间。移动采血预约流程要求患者致电、完成身份验证、提供三个偏好日期和服务地点，再由人工团队协调确认，涉及复杂认证和多供应商系统集成。

方案

Natera 基于 Amazon Bedrock AgentCore 构建了自动化语音代理，允许患者通过对话预约移动采血服务。架构采用三大核心原则：双 WebSocket 桥接模式（分离电话流与模型推理）、事件驱动延迟掩蔽（并行生成上下文填充响应以掩盖后端延迟）、渐进信任模型（中期对话认证与内存会话转移）。团队将工作负载从 Amazon ECS 迁移到 AgentCore 完全托管的 serverless 运行时，集成 Twilio 进行电话连接、Amazon Bedrock 进行模型推理与知识库 RAG、AgentCore memory 进行跨会话持久化，并使用 Amazon Bedrock Guardrails 实现合规与安全控制。

问题

遗留BI工具下，GoDaddy面临仪表板数量庞大（5,000多个）、渲染时间超过15分钟、基础设施成本上升、集中式BI团队需求超载，难以实现大规模自助分析。

方案

GoDaddy于2023年决定迁移到Amazon Quick（原Quick Sight）。采用Amazon Redshift作为主要数据连接层，通过Okta单点登录，实施嵌入式分析，部署七个自定义聊天代理，并利用Quick Flows自动化每周业务回顾等工作流。同时建立治理框架，减少仪表板冗余。

问题

单个 ASR 推理请求仅使用 GPU 15-20% 计算容量，默认 CUDA 时间切片导致约 80% 硬件空闲；Heidi Health 为维持亚秒级转录延迟在高峰流量下需要运行 16 个 GPU 实例。

方案

使用 NVIDIA CUDA Multi-Process Service（MPS）实现 GPU 并发执行，结合 NVIDIA Triton Inference Server 动态批处理和 ONNX Runtime/TensorRT 模型优化，在 Amazon EC2 g6e.4xlarge/g7e.4xlarge 实例上部署 FastAPI 网关 + Triton + MPS daemon 三层推理管道，通过并发分区提高 GPU 利用率。

问题

生物研究中的工具碎片化：存在数百种数据库、软件包和协议，研究人员需花费大量时间选择与掌握不同平台，导致实验和分析效率低下。

方案

斯坦福大学开发基于 Claude 的 Biomni 平台，将数百种工具、软件包和数据集集成到单一系统中，使研究人员能用自然语言交互，自动执行复杂的生物信息学分析任务。

问题

迪卡侬需要为全球数万种产品进行周度销售预测，涵盖12周补货和52周战略规划。原有方法（DeepAR、Holt-Winters、TFT）需要每周重新训练，扩展新区域需约6个月且工程复杂度高，运营开销大，且预测精度有待提升。

方案

迪卡侬评估多个时间序列基础模型后选择Chronos-2，利用AutoGluon集成进行LoRA微调，在AWS EC2上部署每周批量推理，每6个月微调一次模型。架构包括PySpark数据准备、MLflow模型注册、Airflow编排和Databricks任务触发。

问题

在数百家航空公司、数十亿乘客规模下，工程师需手动关联日志、指标和票据数据，诊断时间长达数小时，且依赖深厚的机构知识，难以规模化。

方案

与 AWS 及 AWS Generative AI Innovation Center 合作，利用 Amazon Bedrock、Amazon SageMaker、AWS Glue 等构建多智能体工作流，包括趋势分析、并行诊断代理和 LLM 总结，实现五阶段处理：摄取标准化、检测、诊断、情境化和建议行动。

问题

FBG 在美国多州运营，各州法规不同，客户期望即时准确回复，尤其在赛事高峰时段咨询量巨大。传统决策树聊天机器人无法处理复杂性，导致客户不满和人工成本上升。

方案

采用多智能体架构，基于 Amazon EKS、Amazon Bedrock，使用编排模式，包含监督代理、RAG、MCP 工具和负责任博彩分类器，并通过 Amazon Bedrock Guardrails 保障安全。

问题

大型企业云迁移面临手动发现耗时数周、基础设施代码开发周期长（3-4周/应用）、迁移后运维被动救火等瓶颈，300多个应用组合难以按期完成。

方案

AWS Professional Services 构建了包含四个专门代理（Intake Agent、IaC Agent、Migration Intelligence and Governance Agent、SRE Agent）的多智能体编排框架，运行在 Amazon Bedrock AgentCore 上，使用 Strands Agents SDK 和 MCP 工具，覆盖迁移全生命周期，并嵌入安全控制和人工审批门。

问题

AI 搜索变化导致依赖底部漏斗内容营销的流量和收入下降；同时产品存在年度订阅到期后的流失问题。

方案

转向更高终身价值（LTV）的销售，专注入站合格 ICP；使用 AI 对线索进行排序以确定潜在价值；并将产品定位从“玩具”转向“工具”，扩展更多商业用例。

问题

Axonius 需要在现有 silo 模式下为大量客户添加 AI 智能体，同时满足租户隔离、身份集成、成本跟踪、服务集成、生命周期管理和可观测性等关键要求，并避免长时间定制基础设施开发。

方案

采用 Amazon Bedrock AgentCore runtime 为每个客户部署专用智能体，每个用户会话运行在独立 microVM 中；通过 ENI 连接客户 VPC、短时 JWT 与 IAM 角色标记实现身份与成本治理；结合 Bedrock Knowledge Bases、Guardrails 和 CloudWatch 等 AWS 服务；使用 VPC Lattice 实现私有网络连接，并以 CloudFormation 自动化部署。

问题

原有特征工程分散，导致数据重复、手动生产部署风险、高延迟以及延迟事件处理困难，无法满足实时欺诈检测需求。

方案

采用流式优先架构，使用 Amazon Kinesis Data Streams 进行实时事件摄取，通过 Amazon Managed Service for Apache Flink 进行特征处理与丰富，并写入 Amazon SageMaker Feature Store。离线数据通过 Amazon Data Firehose 和 Amazon S3 以 Iceberg 格式存储，用于模型训练。架构部署在三个 AWS 区域。

问题

小团队没有传统部门结构，需手动协调代码、营销和分发任务，效率低且难以全天候运行。

方案

构建自动化代理系统，利用Claude API运行代码、营销和分发工作流，人类负责设定方向、提供上下文、审查输出和纠正错误。

问题

OneAdvanced 服务于医疗、法律等受监管行业，客户要求严格的数据驻留、安全和隐私标准。所需模型（Llama 4 Maverick 和 Llama Guard 4）当时尚无法通过英国区域的托管服务获得，因此必须自托管以保持对模型基础设施的完全控制，确保数据不离开英国。

方案

OneAdvanced 在伦敦区域（eu-west-2）使用 vLLM 在 Amazon SageMaker AI 的 p5.48xlarge 实例上自托管 Llama 4 Maverick (FP8) 和 Llama Guard 4，通过 Strands Agents SDK 构建 50 多个专用代理并部署在 Amazon ECS，配置存于 DynamoDB；RAG 管道基于 Amazon Aurora PostgreSQL 和 pgvector，文档上传至 S3 后转换为 markdown、分块（2048 token）并嵌入 intfloat/multilingual-e5-large-instruct 模型；Llama Guard 4 在主模型前串行过滤有害输入；另有无代码代理构建器供非技术用户使用。

问题

Distribb 的网站有一些查询获得了 Google Search Console 展示，但现有页面覆盖的主题过宽，没有针对精确搜索意图的专门内容，导致潜在 AI 展示机会未被利用。

方案

实施六步工作流：1) 将 Google Search Console 连接至 Claude Code，拉取近三个月查询、展示、点击和排名页面；2) 运行提示找出排名但无专门内容的词；3) 打开当前展示页面与查询对比，识别查询差距；4) 用 Ahrefs/DataForSEO 验证搜索量和难度，并检查是否与现有页面冲突；5) 为精确查询发布单独页面；6) 检查新 URL 表现并重复迭代。

问题

随着数据采集流水线扩展，66%的支持工单成为常规状态查询。工程师处理每个查询需手动跨多个系统操作约15次点击，耗时且分散高级工程师精力；传统自动化方法（脚本、静态工作流、规则决策树）无法理解上下文和适应多样化查询模式。

方案

Mobileye 使用 Amazon Bedrock AgentCore 的 serverless 运行时部署 AI 支持代理，通过内部 LLM 网关调用 Anthropic Claude 模型，并利用 Model Context Protocol (MCP) 实时访问生产数据。架构采用混合设计：本地编排器处理内部工单系统，AgentCore 负责代理运行和内置可观测性，AWS Secrets Manager 保障无密钥安全认证。

问题

购房者面对复杂的抵押贷款选择（如贷款类型、期限、利率）和大量专业术语，感到迷茫；监管要求严格，需要准确信息、透明指导和PII保护；传统聊天机器人仅能处理基础问题，无法回答复杂问题并提供个性化匹配。

方案

LendingTree部署了三个独立AI智能体（主管、教育、匹配），使用LangGraph进行编排，通过MCP进行智能体间通信，并由Amazon Bedrock提供Amazon Nova Pro和Nova Lite基础模型。所有智能体运行在Amazon ECS with AWS Fargate上，使用Amazon Bedrock Guardrails进行内容过滤和PII编辑，教育智能体基于Amazon Bedrock Knowledge Bases进行RAG，匹配智能体调用内部API提供个性化选项。会话状态通过LangGraph PostgreSQL检查点存储在Amazon RDS上。

问题

企业存在大量长期积压的内部工具需求（如运费计算器、简单表单、基于电子表格的仪表盘），传统交付流程需要开发者、积压排期和部署流水线，导致小工具永远被优先级低于创收功能。PDI Technologies希望能实现“意图输入，应用输出”，且默认安全合规、无服务器化、AI能力可控。

方案

PDI Technologies构建了PDI Brew平台，采用双代理架构：规划代理（可运行于AI助手中的Vibe Skill路径，或AWS边界内的Amazon Bedrock路径）捕获用户意图并生成结构化部署manifest；预置代理（基于AWS Lambda）接收manifest，确定性分类工作负载，编排AWS及Microsoft Graph资源创建。全栈应用会获得独立DynamoDB表和API Gateway；特权能力需管理员审批。内置AI通过Amazon Bedrock提供，强制Guardrail、12计数器预算及双层终止开关。安全上使用Entra ID SSO、IAM最小权限、S3公共访问阻止等。

问题

NHL常规赛进入尾声时，确定球队是否已锁定季后赛资格非常困难。由于涉及32支球队、复杂的平局规则和数百场剩余比赛，手动生成资格场景既耗时又容易出错。

方案

AWS生成式AI创新中心构建了一个自动化系统，结合约束编程（CP）和自定义树搜索。系统包含0-day求解器和n-day前瞻求解器：0-day求解器使用Google OR-Tools CP-SAT将问题建模为可行性问题，判断球队是否已锁定季后赛；n-day前瞻求解器通过树搜索评估未来n天比赛结果对锁定资格的影响，并利用预处理、剪枝和节点排序启发式提高效率。

问题

TReNDS 中心在 AWS 上运行多项应用，随着应用增长，需要调查的错误量激增。工程师需要手动打开 CloudWatch Logs、阅读堆栈跟踪、查找源文件并追踪执行路径；简单错误通常需要 15-30 分钟，复杂跨服务问题耗时更长。团队希望自动化事件响应中最耗时的部分：根因调查本身。

方案

TReNDS 构建了一套生产系统，结合 Amazon CloudWatch 订阅过滤器、AWS Lambda、Strands Agents SDK 和 Amazon Bedrock。CloudWatch 订阅过滤器实时检测 ERROR、Exception 等错误级别模式并触发 Lambda，Lambda 运行由 Amazon Bedrock 驱动的 Strands Agent，自动从同一日志流获取上下文、从 GitHub 获取源代码，通过工具调用推理根因，生成包含严重级别、根因解释、相关代码上下文、建议修复和受影响区域的结构化分析，并通过 Amazon SNS 发送给团队。系统使用 Anthropic Claude Sonnet 作为主要模型，并利用 DynamoDB 对重复错误去重。

问题

事前授权政策被困在静态、非结构化的文档（如 PDF）中，难以自动化。健康计划缺乏系统化的方式来管理、分析和优化这些政策，导致运营瓶颈。Cohere Health 面临三重挑战：CMS 要求 2027 年前支持基于 API 的电子事前授权、AHIP 要求 80% 实时审批、以及不同业务线的独特需求。

方案

Cohere Health 使用 Amazon Bedrock AgentCore 构建了 Cohere Policy Studio，采用多租户代理架构，包括可复用的 ECR 基础镜像模式、AgentCore Gateway 统一工具访问、AgentCore Memory 会话记忆，以及基于 Agent Skills 开放标准的模块化技能框架，实现政策数字化并保留人工审核。

问题

摄影师和艺术家是生成式 AI 最持怀疑态度的群体，他们担心 AI 威胁其技艺并充斥行业。Pixieset 发现其网站构建器中大多数摄影师网站几乎没有替代文本。摄影师的作品集包含数百到数千张图片，为每张图片编写独特且描述性的替代文本非常繁琐且耗时，导致这项任务被不断推迟。

方案

Pixieset 使用 Amazon Bedrock 上的多模态大语言模型（Anthropic Claude 3.5 Sonnet）构建了 AI 图像替代文本生成功能。该功能集成到现有的事件驱动架构（Amazon EC2、AWS Lambda、Amazon SQS）中，通过单一 API 调用将图片发送到 Bedrock 进行推理，生成的标题与照片一起存储，并在网站构建器中供用户审核。设计上采用单张图片逐步审核，用户可接受、编辑或拒绝，然后可选择自动应用，且始终可编辑。使用跨区域推理和备用模型重试确保零停机。

问题

日本建筑业面临劳动力短缺，BIM推广需要专业知识，而IDS作为BIM验证的XML标准，其编写要求熟悉IDS语法和IFC规则。三个主要挑战：IDS标准新（2024年发布）导致公开数据稀缺；需要注入数千个IFC术语的映射关系；IDS专用XML语法复杂，通用模型难以准确生成。

方案

基于开源Qwen3（8B/14B/32B）构建Ishigaki-IDS。采用三阶段训练流程：CPT（持续预训练）注入IDS和IFC领域知识，利用内部专家合成数据；SFT（监督微调）训练指令到IDS输出的映射；RLVR（可验证奖励强化学习）使用buildingSMART的IDS-Audit-Tool作为自动奖励函数，确保XML结构、IDS结构语义一致。训练基础设施使用Amazon EC2 P5en（H200 GPU）实例、AWS ParallelCluster和Amazon FSx for Lustre。AWS GenAIIC提供双周技术咨询。

问题

创始人用户虽然认可 AI 能准确回答文档问题，但真正消耗其精力的并非知识型问题，而是“可执行”类请求。客户说“能不能你直接帮我操作”，而产品只会粘贴文档链接，导致创始人仍需登录 Stripe 等系统手动处理退款、改地址、逆向收款等任务，严重拖慢产品开发节奏。

方案

作者重构了 Velor：不再只是把答案基于文档，而是接入 Stripe、Shopify、Zendesk 等系统。当客户要求退款时，AI 会查验订单、与客户确认并直接处理，同时生成带签名的审计日志记录每个动作及原因。系统还根据操作可逆性设置自动执行阈值——可逆的低额退款可自动执行，不可逆或高成本操作则进入确认状态，并利用幂等键和终态状态处理 webhook 延迟或部分失败问题。

问题

nOps 原有基于 API 的架构存在响应延迟高、系统复杂性大、创新拖累等问题。自管理的 Amazon EKS 堆栈导致工程维护负担重，开发迭代慢，且代理回答依赖 API 响应而非专用语义分析层，难以扩展。

方案

nOps 将其 Clara 代理重构为基于 Amazon Bedrock AgentCore 的单代理架构，结合 Databricks Lakehouse Metric Views 提供治理的语义分析层、Databricks Lakebase 存储持久状态，并通过异步工作流（Amazon DynamoDB、SNS、SQS、API Gateway WebSocket）实现实时更新。移除了 LangGraph/LangChain 编排层，由 AgentCore 运行时和内存替代，并使用 Amazon Bedrock Guardrails 进行租户隔离和提示攻击检测。

问题

当自主系统移动资金时，运营方需要向审计师、对手方和法律证明每笔支付经过授权、按风险定价并记录在案，但缺少将具体支付与授权策略、约束条件和风险绑定在一起的持久记录。企业需要每笔代理支付在交易层面可验证、风险定价且可审计，同时不拖慢代理速度或引入额外基础设施。

方案

该工作流由 ORACLE 策略引擎进行预授权，ICME PreFlight 提供可独立验证的策略检查，AWS Nitro Enclave 进行硬件完整性认证，风险引擎进行每笔交易定价，最后通过 Amazon Bedrock AgentCore payments 处理支付并由 Coinbase 进行链上结算。每笔交易产生一个签名证据记录，绑定策略、检查结果、硬件认证执行记录、风险价格和结算工件，并通过‘无决策、无结算’的门控确保治理先行。

问题

First Orion工程团队交付速度超过QA测试能力，传统基于脚本的Selenium和Playwright测试脆弱且编写耗时，导致发布延迟、新功能质量下降，工程时间被回归测试大量消耗。

方案

采用Amazon Nova Act，从基于选择器的脚本测试转向自然语言驱动的AI代理测试。构建包含React测试用例编写UI、Amazon S3存储、Amazon ECS/Fargate运行器、Amazon Bedrock AgentCore Browser的端到端系统，QA分析师可直接用英语编写测试用例，由Nova Act理解界面并自动执行浏览器操作，无需维护元素选择器。

问题

大型企业的事件分析和日常知识工作涉及大量人工检索、归纳与重复操作，需要在安全治理框架下提高处理效率。

方案

NTT DATA Group 将 ChatGPT Enterprise 与 Codex 用于受控的企业工作流程，帮助员工自动化工作，并推动安全的 AI 采用。