用 AI-SDLC 在 Amazon Bedrock AgentCore 上重塑软件交付
软件开发团队基本都已采用敏捷交付模式，阶段划分很明确：需求、梳理、开发、测试、代码审查。每个阶段都存在重复、可预测的工作，比如澄清需求、编写验收标准、拆分工单、制定测试计划、审查拉取请求。AI 编程助手改变了开发阶段，但其余四个阶段仍然依赖人工、交接和口口相传的经验。
Verisk 与 AWS 合作构建了 AI 驱动的软件开发生命周期（AI-SDLC）。AI-SDLC 是一套由专用 AI 代理组成的系统，覆盖软件交付的每个阶段。这些代理接入 Verisk 现有的企业工具链，运行在 Amazon Bedrock 和 Amazon Bedrock AgentCore 上。本文将介绍 AI-SDLC 的架构模式，以及 Verisk 如何在受监管的保险环境中部署它。内容涵盖代理设计、企业工具集成、设计原则、组织采纳和实测结果。
Verisk 是全球保险行业领先的战略数据分析与技术合作伙伴。其业务贯穿保险价值链，从承保和风险评估到理赔管理、欺诈检测和巨灾建模，50 多年来一直帮助财产险和意外险保险公司更明智地做出风险决策。
注：如需包含代码示例的 AI-SDLC 模式参考实现，请参阅《使用 Amazon Bedrock AgentCore 实现 AI 驱动的开发生命周期》。
将 AI 嵌入整个交付生命周期
对多数工程团队来说，AI 辅助只停留在编码环节。其余四个阶段仍是手动或半自动。这会在以下方面造成效率低下：
- 需求（Requirements）：工单全靠人工撰写，验收标准往往写不完整，需要反复澄清好几轮。
- 需求梳理（Grooming）：把功能拆成一个个实现任务，要占用数小时的迭代规划时间，而且各团队产出的质量参差不齐。
- 测试（QA）：每个功能，工程师要花 3–4 小时写测试计划，再花 1–2 天搭自动化。
- 代码评审（Code review）：评审的深度和一致性取决于评审人是否有空、是否熟悉这块代码。
这些环节叠加起来，交付周期往往以周甚至月计；质量检查时松时紧，每次交接都会丢失上下文。
Verisk 的工程管理层提出的问题是：能不能让 AI 智能体（agent）负责每个阶段的生成工作，工程师只负责把关决策，而不是亲自写初稿？答案并不是在流程不变的前提下再堆一堆 AI 工具。Verisk 的做法是重新设计工作流：每个阶段的生成工作交给 AI，决策权留给人类。
方案概览
这套方案包含五个分阶段智能体：需求、需求梳理、开发、代码评审和测试。每个智能体都有明确的范围、约定的触发条件，输出在进入下一阶段之前都要经过人工审核检查点。Verisk 没有依赖一个中央编排器来管理整个生命周期，而是让每个智能体都能独立部署、独立测试、独立优化。
图 1：Verisk 的 AI-SDLC 架构。分阶段智能体从企业工具接收工作流事件，从知识源检索上下文，通过 Amazon Bedrock 调用基础模型进行推理，再把结果写回企业系统；每个阶段切换都由人工审核检查点把关
用到的 AWS 服务和框架：
- Amazon Bedrock AgentCore：托管并运行全部五个代理，提供安全的 MCP 网关访问、会话管理、记忆、可观测性和托管基础设施。
- Claude Code on Amazon Bedrock：为 Developer Agent 提供支持，负责端到端的工单实现——读取编码规范、拆解任务，并生成覆盖全栈各层的代码。
- LangGraph / Strands Agents：开源代理框架，用于在每个代理内部实现多步骤、有状态的工作流。
架构深入解析
四层架构把 Verisk 现有的工具链与 AI 代理能力连接起来。
企业工具层
代理从 Verisk 团队日常使用的系统中读取数据，也将结果写回这些系统：Jira 用于需求和工作流状态，代码仓库用于源码管理和拉取请求，Confluence 用于文档，代码质量工具用于安全和质量分析。Jira 工单的状态流转会触发代理执行，代理的输出则写回相应系统。
Verisk 构建了一个 Atlassian Forge UI 集成，把代理能力直接呈现在 Jira 界面里。工程师管理工单、跟踪工作流状态的同一个环境，就是他们与代理交互的地方。不用学新工具，也不用切换窗口。
集成层（MCP）
工具集成采用模型上下文协议（MCP），通过 MCP 网关统一管理。MCP 提供标准化接口，代理用它来发现和调用工具（Jira 读写、代码仓库读写、API 规范读取、文档读取），不需要为每个代理单独写集成代码。把代理的推理逻辑和工具实现分开，这一点很关键：新增集成时不用改代理代码，工具访问也由中心统一管理和保护。Verisk 往工作流里加一个新工具，只需在 MCP 注册一次，所有代理就都能用上。
AI 代理层（Amazon Bedrock AgentCore）
每个代理都托管在 Amazon Bedrock AgentCore 上，会话管理和扩缩容自动完成。关键基础设施组件包括：
- AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）：为每个智能体提供无服务器托管，无需管理基础设施。
- AgentCore memory（Amazon Bedrock AgentCore 的一项能力）：在多次调用之间保持上下文，让智能体能够进行对话式交互（需求智能体用它和产品负责人反复打磨需求）。
- AgentCore Observability（Amazon Bedrock AgentCore 的一项能力）：对每一次智能体调用做追踪、日志记录和监控，让团队看清每个智能体做了什么、为什么这么做。
知识与上下文层
智能体的输出质量，直接取决于调用时给它的上下文。上下文来自四个地方：Jira 工单（描述和附件）、仓库代码与编码约定、存成 markdown 文件的 API 规范和内部文档，以及上游智能体产出的结果。这些上下文就放在团队已经在用的系统里——Jira 和受版本控制的 markdown 文件——而不是另建一个存储。智能体从这些记录来源读取，也写回同样的地方。
质量靠一个持续运转的反馈闭环来保证。一个需求梳理智能体会检查每一张进来的工单，把缺失或含糊的地方标成待解问题，再和相关干系人对话把它们弄清楚。答案以结构化的验收标准写回工单，这样原始问题和它的结论就留在工作项上，而不是散落在聊天记录里。整个过程不引入额外的上下文存储。权威记录仍然留在 Jira 和仓库里受版本控制的 markdown 中，也就是说，审计线索就是评审者本来就信任的那一套。
人工审核检查点
每一次阶段推进都有门禁。智能体可以生成需求、任务拆解、测试计划或代码改动，但在工程师批准之前，任何东西都不会往下走。这个检查点是一个决定，而不是一次编辑：评审者可以接受、带理由拒绝，或者附上问题把产出退回去。拒绝和提问会成为优化提示词和上下文的训练信号，并被记录在团队本来就会查看的同一份工单历史里。
设计原则
四条原则塑造了整个实现方案，并让系统在受监管环境中始终保持可审计：
- 智能体负责生成，工程师负责决策。 未经人工批准，任何智能体都不能合并代码、关闭工单或晋升制品。自主性的边界由检查点定义，而不是由模型的置信度决定。
- 一个智能体，一个阶段，一个触发条件。 每个智能体职责范围很窄，有明确的调用事件（通常是 Jira 状态流转），并且只有一个输出约定。这样可以把故障限制在局部，每个智能体也能独立测试和单独优化。
- 一切以记录系统为准。 智能体读写的是 Jira、代码仓库、Confluence 和 API 规范，而不是另建一套知识库。上下文能保持最新，因为它本身就是那些制品。
- 让每一步操作都可观测。 每次调用都有追踪和日志，审查者可以还原当时检索了哪些上下文、调用了哪些工具、为什么会生成某个输出。这既是工程要求，也是合规要求。
第一条原则还有一个有用的副作用：每个智能体都能独立部署，所以 Verisk 升级单个阶段时不需要对整个生命周期做回归测试，下线某个智能体也不用拆解整条流水线。
组织层面的推广
技术只是这场变革中较小的一半。Verisk 按阶段逐步推行这套生命周期，从摩擦最大、风险最低的地方开始，让团队自愿加入，而不是一次性强制推行整条流水线。每天使用智能体的实践者后来成了下一个团队的评审者和推动者，他们给出的驳回理由又反过来驱动提示词和上下文的调整，以周为单位迭代。
有两个做法让落地变得具体：
- 把界面放在工作本来就发生的地方。 在 Jira 界面内提供智能体能力，消除了新开发者工作流通常难以推行的工具负担。
- 公开边界。 团队从第一天起就知道智能体会做什么、不会做什么，以及在哪里需要自己批准。赢得信任靠的是可预测性，而不是能力有多强。
可量化的成效
提升最明显的，正是原先最依赖人工的环节。需求澄清的轮次减少了，因为梳理（grooming）智能体在冲刺计划开始前就把需求缺口挑了出来。测试计划编写过去每个功能要花 3 到 4 小时，现在以验收标准和 API 规格为依据，先生成草稿，自动化脚手架也从过去 1 到 2 天的搭建时间中节省出来。代码评审的深度变得稳定，因为评审智能体对所有人执行同一套标准，人工评审者可以把精力放在需要判断的地方，而不是格式和约定检查上。
更大的影响发生在交接环节。以前只存在于评审者脑中或 Slack 对话里的上下文，现在会写回工单，交付周期不再因为每个阶段交接时都要重新摸索而白白拉长。
结语
AI-SDLC 并不是把一堆编码助手硬塞进一个没有改变过的流程里。它是对整个生命周期的一次重新设计，围绕一个简单的分工：智能体在每个阶段产出初稿，工程师负责决策。Amazon Bedrock AgentCore 提供运行这套模式所需的运行时、记忆、网关和可观测性，并具备受监管环境所要求的管控能力；MCP 则让工具集成与智能体逻辑解耦，使系统可以在不重写的前提下持续扩展。
要搭建同样的模式，可以先从一个阶段入手，定义它的触发条件和输出契约，通过 MCP 接入各记录系统，并在每次阶段转换前设置人工检查点。如需带代码示例的参考实现，请参阅 AI-driven development lifecycle using Amazon Bedrock AgentCore。