作者: Phodal Huang 2026年2月5日 11:39

这不是一个从“我们决定做 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 应用的迫切性，有两方面原因：

1. 线上事故：某项目使用百度版 Semantic Kernel 时出现问题，百度计划将该项目迁移到低代码平台，类似的 AI Agent 在其他项目中也存在。
2. 异构算力环境：企业内部存在大量国产算力资源，但缺乏统一管理和复用机制。

由于我们不生产 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。