A企业架构与TOGAF在Agent技能设计中的指导方法研究

引言：AI Skill设计的"巴别塔"困局

当下的AI Agent生态，正陷入一种似曾相识的混乱。

举个例子，去年在帮一家保险公司梳理Agent技能库时，就撞见了一个典型的混乱场景：100多个Skill横七竖八地堆在一起——有的直接调API，有的内嵌业务逻辑，有的把数据获取和分析揉成一团。问架构师这些Skill怎么分类，回答干脆利落：“按安装顺序排的”。再问两个Skill之间数据怎么流转，回答更干脆：“各写各的”。一个股票监控Skill自己爬数据、自己做分析、自己发消息，三件事耦合在同一个脚本里。换一个场景想复用其中的分析逻辑？做不到，只能重写。

这不是个例。几乎所有率先部署AI Agent的企业都面临同样的困境：Skill越堆越多，越堆越乱。缺乏统一的能力域划分，缺乏标准化的数据接口，缺乏清晰的组合规则，缺乏可复用的构建块沉淀。

听起来很熟悉？没错——这正是企业架构在20年前要解决的问题。当年企业信息化的混乱，和今天AI Skill的混乱，本质上是一回事：没有架构约束的开发，必然走向无序。

4A企业架构（业务架构BA、数据架构DA、应用架构AA、技术架构TA）加上TOGAF的构建块思想，为Agent Skill设计提供了一套经过验证的方法论。本文试图建立这二者之间的映射框架，并用实际案例说明其可行性。

4A映射框架：四个问题驱动Skill设计

企业架构的核心是四个问题：做什么（BA）、数据怎么流（DA）、用什么组合（AA）、底层怎么支撑（TA）。这四个问题同样适用于Skill设计。

BA：Skill能力域划分

BA层解决的是“干什么”的问题。简单来说，就是把企业的能力拆成一个个可以独立编排的业务能力块，每个块对应一个或一组Skill。

以金融行业为例，将AI能力划分为6个能力域：

每个能力域是一个高内聚的Skill集合。能力域之间的边界由业务流程决定——知识检索和数据分属不同能力域，因为它们的业务语义和用户角色不同；但知识检索配合报告生成可以组装成更复杂的业务流程。

DA：Skill间的数据流设计

DA层关心的是数据怎么流。这里面最关键的决策，其实就一个：Skill之间交换数据时，到底用什么样的格式和协议。

实践中的通用做法是采用JSON Schema作为Skill间数据交换的契约：

• 每个Handler声明输入Schema和输出Schema
• 上游Handler的输出Schema必须兼容下游Handler的输入Schema
• 非兼容的连接需要通过Adapter Skill桥接

这种设计保证了Skill组合的数据安全性。在实际生产中，遇到过两个值得记下来的教训：

• 评分引擎的输出直接喂给报告生成器，但评分结果缺少置信度字段，导致报告措辞过于绝对。修复方式是在ScoringEngineHandler的输出Schema中增加confidence字段，并要求下游Handler根据置信度调整输出语气。
• 文档解析输出的数据结构包含嵌套的表格数据，数据分析Handler无法直接消费。解决方案是引入一个FlattenAdapter Skill，将嵌套结构展平为二维表格格式。

AA：Skill的组合关系

AA层解决的是怎么组合——决定了Skill的组装粒度和复用边界。

这里采用三层组装模式：

• 原子Skill：单个Handler完成单一功能，如OCRParserHandler做发片识别
• 复合Skill：多个原子Skill按流程编排，如尽调报告 = OCR解析 + 数据分析 + 报告生成
• 场景Skill：面向最终用户的端到端体验，如企业尽调智能体 = 用户交互 + 尽调报告 + 风险评分

组装的关键约束是：复合Skill只能调用原子Skill或子复合Skill，不能跨层直接调用Handler。这保证了每一层都有明确的抽象边界。

TA：技术架构支撑

TA层解决的是底层怎么支撑的问题。核心是三个选择：

• Skill运行时：选择支持Skill热加载和版本管理的运行时
• 编排引擎：选择支持DAG编排的流程引擎
• 状态管理：选择支持Skill间状态共享的存储方案

在具体实践中，选用了Phase-Orchestrator作为编排引擎，它支持4-Phase强制链式调用和条件分支。状态管理采用结构化JSON传递，在每个Phase的入口和出口进行schema校验。

TOGAF构建块思想：Skill的可复用单元

4A给出了Skill的架构框架，TOGAF的构建块（Building Block）思想则给出了Skill的可复用设计规范。

什么是构建块

TOGAF定义的构建块有两个核心特征：

• 功能内聚：一个构建块封装一组紧密相关的功能
• 接口标准：构建块通过标准接口对外暴露能力，内部实现对外不可见

这与Skill设计的要求完全一致。一个设计良好的Skill应该是一个标准的构建块：内部封装具体的Handler逻辑和数据访问，外部只暴露输入输出接口。

构建块的分类

TOGAF将构建块分为两类：

• 架构构建块（ABB）：定义能力边界和接口规范，类似于接口
• 解决方案构建块（SBB）：ABB的具体实现，类似于实现类

在Skill体系中，这对应两个层次：

ABB/SBB分离带来了两个直接好处：

• 实现可替换：同一个ABB可以有多种SBB实现，根据场景选择最适合的实现
• 接口驱动开发：先定义ABB（接口），再开发SBB（实现），降低开发耦合

构建块的组合规则

TOGAF的组合规则对Skill设计有三条约束：

• 单一职责：一个Skill只做一件事。违反此规则的典型表现是股票监控Skill同时做数据获取和分析
• 依赖显式声明：Skill的依赖关系必须在配置中声明，不允许隐式依赖
• 数据流方向单一：Skill之间的数据流必须是单向的，不允许循环依赖

实战案例：企业尽调智能体

以企业尽调智能体为例，展示4A + TOGAF如何指导一个完整Skill系统的设计。

BA层：定义能力域

企业尽调需要6个能力域覆盖：

DA层：设计数据流

6个能力域的数据流向：

文档解析 → 数据分析 → 评分决策 → 报告生成
知识检索 → 评分决策
评分决策 → 可视化
报告生成 ← 可视化

每个箭头代表一条JSON数据流，每条数据流都有对应的Schema约束。

AA层：组合Skill

两层组装：

• 原子层：6个Handler各自作为原子Skill
• 复合层：企业尽调Skill = 文档解析 + 数据分析 + 评分决策 + 报告生成

知识检索和可视化作为可选增强，不纳入核心流程。

TA层：技术选型

• 编排引擎：Phase-Orchestrator，4-Phase链式调用
• 状态管理：结构化JSON，Phase间传递
• 运行时：Python 3.10 ，Skill热加载

经验总结：从方法论到实践的三个教训

• 第一，架构要先行，但不求完美。先建立4A的骨架，让每个Skill至少知道自己属于哪个能力域、数据从哪来往哪去。细节在迭代中补齐，但框架不能缺。
• 第二，构建块粒度由业务决定，不由技术决定。一个股票分析Skill之所以应该拆分为数据获取 + 分析 + 通知三个Skill，不是因为技术上做不到合一，而是因为业务上存在独立复用这三个能力的场景。
• 第三，Schema是Skill间的契约，不是建议。松散的接口约定会随Skill数量增长而崩溃。只有强制执行Schema校验，才能确保Skill组合的可预测性。

4A和TOGAF不是新概念，但将它们系统性地映射到Agent Skill设计，当前实践尚少。希望本文的框架能为AI Agent的架构化发展提供一个起点。