这不是一个从“我们决定做 AI”开始的故事。我们项目的客户是，某金融公司内部的平台团队。他们并不是一开始就要“做 AI”，而是长期承担着一个更基础、 也更困难的责任：
在业务持续增长、技术不断演进的情况下，如何让应用与架构始终处在可治理、可演进的状态？
在这个前提下，AI 的出现并不是一个独立事件，而是一次新的复杂性冲击。因此，这条主线并不是“从架构治理到 AI”，而是：
从架构治理的方法出发，在平台工程视角下，逐步应对 AI 带来的新型架构问题。
下面的几个阶段，并非产品演进路线，而是在一年多下来，围绕客户真实问题展开的治理路径。
一、平台工程视角下的架构治理：统一框架与黄金路径
在 AI 进入之前，客户平台团队面临的核心问题其实非常传统：
- 技术栈不统一，工程质量高度依赖个人经验
- 架构规范存在于文档中，却难以在代码层面持续生效
- 基础设施重复搭建，平台能力与业务应用之间缺乏清晰边界
我们的切入点，并不是某个具体工具，而是平台工程视角下的架构治理。
1. 把“正确的架构”，变成默认选项
我们和客户一起调研了大量的业务团队，总结了可复用的基础设施，并协助客户构建统一的基于 Java / Spring Boot 开发框架：
- 对接企业内部 PaaS 平台能力
- 将配置、日志、基础可观测性、安全等能力内建到框架中
通过这种方式，架构治理的某些事项不再依赖评审或人工检查，而是通过框架的默认行为自然生效。
2. 黄金路径作为治理载体
在平台工程的理念下，我们强调黄金路径（Golden Path）：
开发者不需要理解所有治理规则，只需要沿着平台提供的默认路径前进。
为使黄金路径可执行，我们建设了以下能力：
- 提供覆盖多 Java 版本的模板工程，将架构规范、技术选型与安全基线固化为默认配置
- 基于代码仓库（Docs as Code），构建框架文档的自动化持续发布体系，确保路径与实现始终一致
- 在黄金路径中默认集成构建、测试、发布与可观测性能力，减少重复集成与人为偏差
架构治理，从“约束人”，转变为“设计路径”。这一阶段，为后续 AI 能力的引入，提供了一个关键前提：
只有在工程体系已经被平台收敛之后，AI 才有可能被系统性治理。
二、AI 能力化：治理对象从“应用”转向“能力”
随着 AI Agent 开始在企业落地，AI 不再只是单个业务系统，而是一种可被反复调用、组合和扩展的能力。如果仍将 AI 当作普通应用来治理，很快就会遇到问题：
- 能力难以复用
- 接口缺乏契约
- 安全与成本边界模糊
对于企业而言，MCP 提供了一个清晰的能力中台故事：它是构建 AI 能力中台的核心支撑，使 AI Agent 拥有可复用、可管理、可放大的能力。 围绕这个愿景，我们实现了三方面的实践：
- 将客户内部唯一具备算力的智能体平台，转换为 OpenAI 兼容接口服务
- 在平台框架中提供 MCP 能力，通过注解快速将传统 AI 服务转换为 MCP 应用
- 利用 AI 协助遗留系统迁移，展示 Agent 在未来企业中的实际应用
结合内部部署的 Qwen 模型，我们向客户演示了其他 AI Agent 如何快速接入现有 MCP 服务，并通过 MCP 客户端展示其能力的组合与落地效果。
三、AI 进入工程深水区：辅助遗留系统迁移与演进
前两步还停留在平台能力建设，而遗留系统迁移将 AI 推向了工程的核心。客户面临大量 Vue 2 向 Vue 3 的迁移压力，传统重写成本极高——如客户供应商估算约需 xxx 人天。受限于金融行业属性，无法使用互联网模型，这种成本显然无法接受。
为此，我们基于 AST + Agent 构建了一个 Workflow 驱动的多 Agent 迁移工具。在真实试点中，这套工具帮助客户节省了约 50% 的人力成本**。即便是对于 xxx 人天的模块，供应商也确认节省一半时间是完全可行的。
在 Vue 2 → Vue 3 的迁移过程中，AI 被引入到真实、复杂的代码场景中，承担了关键任务：
- 依赖分析：辅助分析不同版本之间的依赖差异
- 自动构建修复：基于内部模型能力执行四类基本操作——读取、修改、替换、列目录
- 自动网页错误修复：启动浏览器获取错误信息，由 AI 自动修改代码并构建
从这个角度看，AI 已经直接影响 代码质量和架构演进路径。随之而来的问题也变得无法回避：
当 AI 开始“修改系统本身”，它还能被当作普通工具吗？
答案显然是否定的。从这一刻起，AI 的使用方式、输出质量以及对系统演进的影响，都必须纳入企业架构治理的视野。
四、AI 应用的架构治理：公共能力与平台边界
随着 AI 深度介入工程实践，碎片化问题再次凸显。客户治理 AI 应用的迫切性，有两方面原因：
- 线上事故：某项目使用百度版 Semantic Kernel 时出现问题，百度计划将该项目迁移到低代码平台，类似的 AI Agent 在其他项目中也存在。
- 异构算力环境：企业内部存在大量国产算力资源，但缺乏统一管理和复用机制。
由于我们不生产 GPU 或底层框架，所能提供的企业治理的核心便是 可复用能力。我们尝试构建一个统一的推理框架，一个 Python 基础框架 —— 通过 FastAPI + 内部可复用能力，来实现能力标准化与治理。
问题回到最本质的核心：
能否用架构治理的方法，治理 AI 应用？
答案是肯定的，但前提是明确 能力边界。在实践中，我们逐步将 AI 应用中的共性能力平台化：
- 梳理内部 AI 能力：确保能力可发现、可使用、可演进
- 提供统一推理平台：统一推理接口，降低重复开发成本
- 流程化评审建议：对能力使用和输出提供流程化治理
业务应用只需关注 如何使用能力，而无需关心能力的实现细节或治理机制，从而实现真正的能力中台化和平台化管理。 我帮你把这一部分重写，使逻辑更清晰、语言更凝练，同时突出 AI 可观测性是架构治理的工程化底座，并强调“度量 AI 能力”的核心思想：
五、可观测性与度量：AI 架构治理的工程化底座
当 AI 转化为平台能力时，随之而来的核心问题是：
AI 是否“工作正常”？它的效果和价值如何量化？
传统的日志、指标和链路追踪仍然必要，但已不足以应对 AI 的特殊性。AI 引入了新的不可见维度：
- Prompt 与 Completion：输入输出的内容与质量
- Token 消耗与成本：计算资源与经济成本
- 特定场景指标：如编程任务成功率、生成准确度等
为此，我们将传统可观测体系（日志、PaaS 内部的 OpenTelemetry）与 Agent Trace、Langfuse 等工具结合，构建 AI 可观测化框架：
- 统一 Trace：贯穿应用、网关与模型调用
- 生成过程审计与分析：对每一次 AI 调用进行可追溯记录
- 效果评估与优化：为能力改进和持续优化提供数据基础
这不仅是监控 AI，而是让 AI 成为可工程化度量的对象，让企业能够量化、管理和治理 AI 的使用与价值。
结语：架构治理方法论的自然延伸
回顾这条路径，我们并没有“转型去做 AI”。我们只是把已经验证有效的架构治理与平台工程方法，延伸到了一个新的对象之上。
从系统架构，到平台能力，再到 AI 应用与协作方式，治理的核心始终未变：
让复杂系统可见、可控，并且能够持续演进。
只不过，这一次，被治理的对象，变成了 AI。
或许您还需要下面的文章: