Built from the inside out: How AWS Professional Services became a frontier team first

从内部构建：AWS专业服务团队如何成为前沿团队 | 人工智能

AWS专业服务（AWS ProServe）将项目周期从数月压缩到数天，不是通过在现有流程中添加人工智能（AI）工具，而是通过从根本上重建我们交付的方式，从内部开始。这种转变与我的同事Swami Sivasubramanian在《前沿团队如何重塑AI原生开发》中所描述的相呼应：真正的生产力提升来自于重新想象软件的构建方式，而不是在现有工作流程上叠加AI。

在本文中，我将分享AWS ProServe如何成为前沿团队，使这一转变成为可能的实践，以及您的工程组织可以从我们的经验中借鉴什么。

一个已经完成这项工作的合作伙伴

构建一个前沿团队是每个组织都可以做到的事情。对于希望加速推进的客户，AWS ProServe是一个合作伙伴，其顾问已经在日常工作中融入了AI原生开发。

AI原生开发的速度是传统咨询节奏所无法应对的。过去需要数月完成的工作现在压缩到数天，节奏也随之改变：更紧密的循环、更快的反馈、在构建过程中做出更多决策。帮助客户以这种速度运作，需要顾问了解哪些决策可以快速做出，哪些需要谨慎的人类判断，以及如何在执行速度加快时保持高质量。这种直觉来自于实际完成工作。

我们的驱动因素与Swami所描述的一致：让顾问摆脱非编码的负担（文档编写、协调、状态报告、重复的搭建工作），这些负担消耗了每次项目中的大部分时间。这使得人类判断能够集中在真正推动结果的地方。因此，我们采取了前沿团队的做法。我们投资于代理上下文，围绕代理擅长的工作重新组织任务，并停止将AI视为助手。我们开始将AI视为基础。

我们的先锋团队：APEX

Swami的博客描述了亚马逊团队进入AI原生开发的三种路径：一个先锋计划、一个结构化的冲刺和一个现场实验。AWS ProServe最初就是从先锋计划开始的。

我们的Agentic AI ProServe Experiences团队（APEX）有一个明确的使命：重新设计ProServe的交付方式。APEX构建了ProServe交付代理，这是一个涵盖需求、架构验证、实施、安全审查、测试和部署的多代理系统。一个监督代理在每个生命周期阶段协调专门的子代理。

交付代理是ProServe实施AI-DLC（AI驱动的开发生命周期）的方式。AI-DLC由AWS现场团队构建，通过数百次与客户的实际工作坊进行开发和优化。AI原生开发是基础，AI-DLC是AWS构建的流程，用于在完整的交付生命周期中，为我们自己和客户运行这一流程。

APEX在自己的生产工作负载上验证了这一模式。交付代理现在在全球的项目中与人类顾问并肩工作，APEX验证的模式正在成为ProServe默认的交付方式。这不是一个试点。这就是我们实现规模化交付的方式。

典型的 ProServe 合作流程遵循一种熟悉的咨询节奏：在长文档中进行发现阶段，通过研讨会讨论架构决策，以冲刺周期进行实施，在阶段边界进行测试和安全审查。每一次交接都会引入延迟，每一个文档都是为了人类阅读而编写，而非其他用途。

重新设计改变了每一个步骤。需求从文本转移到结构化规范，人类和代理都可以阅读，成为事实来源，而非副产品。过往合作中的架构标准和经验被编码成指导文件，代理可以持续使用。实施方式从贡献者依次处理任务转变为顾问将范围明确的任务同时分配给多个代理。测试和安全审查被提前到构建循环中，代理在任何人类审查开始之前，都会在本地验证输出并自我纠正。状态报告和协调开销几乎完全消失。

总体效果是：实现持续流动，人类的判断集中于优先级排序、验证和高风险决策。

使用交付代理构建交付代理

APEX 使用与提供给客户相同的 AI 原生实践来构建交付代理。一个功能请求进入系统后，代理生成结构化任务单、生成代码，并通过我们集成 GitLab 的 DevOps 管道运行自动化测试。在人类审核并批准后，更改将被部署。

人类负责判断：优先级排序、验证质量、批准高风险决策。代理负责搭建框架。低风险决策可以自主运行。人类的关卡集中在判断至关重要的地方。

随着 ProServe 的交付团队在项目中采用交付代理，他们将学到的经验反馈回去，使其在每一个项目中变得更加精准。这就是亚马逊的构建方式。我们运行自己的产品，观察哪里出错，并加以修复。

使这一切得以实现的五个实践

Swami 的博客中提到的五个实践现在定义了我们在 ProServe 内部如何运行 AI-DLC：

放慢节奏以加快速度。前沿团队在加速之前进行投资，先构建代理上下文并标准化实践，然后再让速度产生复利效应。APEX 一次性进行了这项投资，因此我们可以直接传递这种肌肉记忆，而不是要求每个客户从头开始。

大力投资代理上下文。指导文件和架构标准是每个合作项目中的一级成果。上下文越丰富，代理就能更安全地行使自主权。

为代理提供任务，而不是照顾它们。构建者维护一个稳定的任务积压清单，并同时运行多个代理，异步审查输出。

使用规范作为事实来源。规范驱动开发是默认的工作流程。规范不是文档，而是代理构建的合同。

将测试前置。代理在输出到达人类审查者之前，会在本地进行验证并自我纠正。

在客户环境中进行 AI 原生交付

在客户项目中，交付代理与人类顾问并肩工作。他们一起完成整个生命周期的工作，从规划到部署，针对客户选定的业务成果。指导原则是：人类提供意图，AI 进行创建，人类进行验证。

客户可以保留对基础模型的选择权，并可以使用自己的数据和工具扩展系统。

校准不是可选的，但你不需要从零开始。团队需要时间来建立对代理能胜任工作的信任，将复杂的工作分解为可验证的任务，并重新构建适合人工智能使用的工件。我们在参与过程中直接转移这种肌肉记忆，从而缩短了学习曲线。

工作流程是不变的。工具只是辅助手段。我们使用 Kiro、Amazon Bedrock AgentCore 和 Strands，但堆栈本身并不是提高生产率的原因。只有当工作流程围绕工具重新设计时，工具才能产生复利效应。

以结果为导向。传统的咨询公司按时间和材料收费，激励的是持续时间而非影响。我们转向了与生产部署业务成果挂钩的固定价格合作模式。当商业模式与客户需求一致时，其他一切都会随之跟进。

实际成果

“我们采用了 Amazon Application Recovery Controller（ARC）的新 Region Switch 功能，以简化我们的多区域弹性方法。Region Switch 用声明性计划取代了自定义故障转移编排，这些计划协调了跨服务的扩展、数据库切换和 DNS 路由。Kiro 与 AWS 专业服务交付代理合作，将数周的待办事项创建压缩到几小时内，将代码交付速度提高了 60%，并在每个交付物中确保了一致的质量。我们的区域切换测试按计划执行，并且我们能够在备用区域运行。这让我们对这种方法为客户提供的速度和可靠性更加有信心。” Matt McKeever，LexisNexis Legal & Professional 基础设施与运营首席技术官。

入门指南

动手工作坊：AWS 解决方案架构师主持 AI-DLC 工作坊，为期两到五天，展示如何在你自己的堆栈上进行原生 AI 开发。已有数百位客户参与其中。

生产环境合作：当你准备将业务用例投入生产时，AWS ProServe 将进入旅程。我们的顾问和交付代理会与你的团队一起嵌入，交付生产成果，同时构建组织能力以持续和扩展该实践。到结束时，你将拥有在生产中运行的系统，并且有受过培训的内部倡导者准备继续推进。

“我们的解决方案架构师一直在这一变革的前线，与客户在 AI-DLC 工作坊中手把手合作，重新构想他们构建软件的方式。一旦团队亲身体验了原生 AI 开发，他们就不想回到过去的方式了。AWS 专业服务将这种势头规模化，并将其转化为实际操作。” Shaown Nandi，AWS 技术部副总裁。

许多组织都有待实现的成果，工程团队也已准备好以不同的方式工作。这条路不是更多的实验，而是在一个已经通过自身生产工作负载验证了该方法的团队支持下，进行坚定的执行。

联系你的 AWS 账户团队或访问 AWS 专业服务网页，以更快地开始交付生产成果。

作者简介

'"`