架构文档总跟不上代码？AWS 用 Amazon Bedrock AgentCore 做了一条自动维护流水线
AWS 与一家全球金融服务公司合作，基于 Amazon Bedrock AgentCore 搭出一条自动化架构文档流水线：智能体读取代码库、生成架构图、写入知识库以支持语义检索，并接入现有 CI/CD。方案自 2026 年第一季度起已在生产环境运行，用于维护其电子交易平台的架构文档。
架构文档为什么总是过期
架构文档一直是软件开发里最难缠的问题之一。团队花几个小时手工画图，上线几周后这张图就作废了。文档一旦落后于代码，就会形成一个个“知识孤岛”：新人上手慢，合规审计也跟着变麻烦。
AWS 给出的解法是搭一个自主智能体：由它自己分析代码库、生成架构图，并持续维护一份可搜索的文档。整条链路靠迭代优化和自我纠错运转，把代码分析、图表生成和自动发布串成一条流水线。支撑它的 Amazon Bedrock AgentCore，是 AWS 用来大规模构建、连接和调优智能体的平台，不绑定框架，也不绑定模型。
下面是一家全球同业经纪商（在主要金融市场开展经纪业务）的落地方式：如何搭建自动化架构文档流水线，并与现有的持续集成与持续交付（CI/CD，即代码提交后自动跑测试、构建、部署的一整套流程）打通。方案由三块能力组成：
- AgentCore 负责代码分析；
- Amazon Bedrock Knowledge Bases 提供语义搜索，也就是按意思检索，而不是按关键词逐字匹配；
- AWS CodePipeline 负责持续部署。
这套方案与这家金融公司共同开发和验证，从 2026 年第一季度起已在生产环境运行，用于维护其电子交易平台的架构文档。
对正在用 AI 辅助写代码的团队来说，这其实是同一件事的另一面：代码产出速度上去了，配套的文档与理解成本也必须交给工具接管，否则“氛围编程”只会把知识债越堆越高。
手工维护文档的四个痛点
开发团队在架构文档上遇到的问题，主要集中在四个方面：
- 手工流程极其耗时。 用统一建模语言（UML）或 Mermaid 这类格式画一张完整的架构图，非常费时费力。代码库一大，这种方式就撑不下去了。
- 文档很快过时。 代码每天都在变，文档更新总是滞后。几周之内，图表就不再反映真实情况，也没法再用来支撑决策。
- 形成知识孤岛。 团队成员一旦离职，口口相传的经验就消失了，遗留系统变成“黑盒”。新开发者只能靠逆向工程去读代码，上手变慢，组织的知识也跟着流失。
- 留下合规缺口。 安全审查和审计都需要最新的架构图，文档过时就会带来合规风险，拖慢认证进度。
在微服务架构里，这些问题还会叠加：要防止级联故障，理解服务之间的依赖关系就格外重要。
方案概览
这套方案借助 AgentCore 构建了一个自主智能体，用来分析 .NET 代码库，并自动生成完整的架构图。智能体运行在 AWS CodePipeline 中，由代码提交到 AWS CodeCommit 仓库时触发。
生成的图和元数据会被导入 Amazon Bedrock Knowledge Bases，从而支持对所有架构文档进行语义搜索和自然语言查询。这样一来，你对架构现状的掌握更清晰，也能从这份可见性里挖出实际的业务价值。
关键组件
方案整合了几个 AWS 服务，组成一条顺畅的工作流：
| 服务名称 | 职责 |
|---|---|
| Amazon Bedrock AgentCore | 为自主文档智能体提供无服务器运行环境，负责智能体的生命周期管理、自动扩缩容和工具编排，你不需要管理底层基础设施。 |
| AWS CodePipeline | 编排从代码提交到文档发布的端到端流程，直接对接 AWS CodeCommit，每次推送到主分支都会触发文档生成。 |
| Amazon Simple Storage Service (Amazon S3) | 存储生成的图、托管文档网站，提供持久存储和全球访问能力。专用的 Architecture Diagrams 存储桶存放可缩放矢量图形（SVG）文件、Mermaid 源文件和图的元数据，同时充当 Amazon Bedrock Knowledge Bases 的向量存储后端。 |
| AWS CodeBuild | 执行流水线的各个阶段，包括依赖安装、智能体调用和构建产物准备。 |
| Amazon Bedrock Knowledge Bases | 作为生成的架构文档的检索和展示层。 |
架构图的元数据、Mermaid 源文件和说明文字都存放在 Amazon S3 里，再通过 Amazon Titan Text Embeddings 模型导入知识库。以 Amazon S3 作为向量存储，就能实现语义搜索和自然语言查询。
下面的架构图展示了整个系统的设计——从代码推送到 AWS CodeCommit，到生成图表，再到导入 Amazon Bedrock 知识库的完整流程。
图 1：从 AWS CodeCommit 到图表生成再到 Amazon Bedrock Knowledge Bases 导入的整体系统设计
关键要点
- 核心思路是让智能体接管架构文档的生成与维护，而不是靠人手工画图、手工更新。
- 方案由三块能力拼成：AgentCore 做代码分析，Bedrock Knowledge Bases 做语义检索，CodePipeline 做持续部署。
- 手工维护文档的四大痛点——耗时、过时、知识孤岛、合规缺口——都是这条流水线要解决的对象。
- 对 AI 辅助编程团队而言，代码产出越快，文档和理解成本越需要工具接管，否则知识债会越积越多。
这套方案把架构文档的生成与检索串成一条 CI/CD 流水线：代码一提交，智能体自动读代码、画图、入库，团队成员用自然语言就能问出架构细节。它已在生产环境维护某金融公司电子交易平台的架构文档。
工作流如何跑起来
整个流程可以概括为：代码提交触发流水线，智能体分析代码并产出图表，随后发布到 S3 并导入知识库，供语义检索使用。
关键要点
- 手工画图、文档过时、知识孤岛、合规缺口，是架构文档的四个典型痛点，微服务架构下还会被放大。
- 这套流水线用 AgentCore 做代码分析、Amazon Bedrock Knowledge Bases 做语义搜索、AWS CodePipeline 做持续部署，三段各司其职。
- 输入是 .NET 代码库，触发点是 AWS CodeCommit 的主分支推送，产物是 SVG 图、Mermaid 源文件和图表元数据。
- 图表与元数据存放在 Amazon S3 的专用存储桶，同时充当知识库的向量存储后端，经 Amazon Titan Text Embeddings 模型导入后支持自然语言查询。
- 方案自 2026 年第一季度起已在生产环境运行，维护的是该金融公司电子交易平台的架构文档。
- 对 AI 辅助编程团队来说，代码写得越快，文档与理解成本越需要工具来接管。
这条流水线是怎么跑起来的
整个流程串起来看，其实是一次标准的 CI/CD 触发加一步智能体分析：
- 开发者提交代码：把改动推送到 AWS CodeCommit（AWS 托管的 Git 代码仓库）。
- 流水线被拉起：AWS CodePipeline 检测到提交，开始按预设阶段编排整个流程。
- 构建阶段执行：AWS CodeBuild 负责装依赖，并在这一步调用智能体。
- 智能体分析代码库：AgentCore 读取并解析 .NET 代码库，输出架构图和配套的元数据。
- 产物落盘：生成结果写入 Amazon S3 的 Architecture Diagrams 存储桶，包含 SVG 矢量图、Mermaid 源文件（用文本语法描述图表的格式，方便后续修改和版本管理）以及元数据。
- 向量化入库：这些内容再经 Amazon Titan Text Embeddings 转成向量，导入 Amazon Bedrock Knowledge Bases。
- 随查随用：团队成员可以直接用自然语言提问，也可以做语义搜索，从架构文档里找答案。
需要说明的是，第 6 步的向量化和入库，让架构文档从「一堆静态文件」变成了「可检索的知识」——这是它比传统文档生成方案更实用的地方：文档不只是被生成出来，还能被问出来。
对做着 AI 编程、氛围编程这类实践的团队来说，这条链路的启发在于：把重复性的、容易腐化的工程维护工作，交给能读代码的智能体去跑。文档随代码更新，人只需要在需要的时候提问。