4A企业架构+TOGAF如何指导Agent Skill设计
引言：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设计。
┌───────────────────────────────────────────────────────────────┐
│ 4A → Skill 映射框架 │
├───────────────────────────────────────────────────────────────┤
│ │
│ BA 业务架构 │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Skill的业务能力域划分、价值链映射 │ │
│ │ → 回答"这套Skill体系解决什么业务问题" │ │
│ └────────────────────────────┬────────────────────────────┘ │
│ │ │
│ DA 数据架构 │ │
│ ┌────────────────────────────▼────────────────────────────┐ │
│ │ Skill的数据流、信息交换标准 │ │
│ │ → 回答"Skill之间数据怎么流转、用什么格式" │ │
│ └────────────────────────────┬────────────────────────────┘ │
│ │ │
│ AA 应用架构 │ │
│ ┌────────────────────────────▼────────────────────────────┐ │
│ │ Skill的组合关系、依赖图谱 │ │
│ │ → 回答"哪些Skill可以组装、依赖关系是什么" │ │
│ └────────────────────────────┬────────────────────────────┘ │
│ │ │
│ TA 技术架构 │ │
│ ┌────────────────────────────▼────────────────────────────┐ │
│ │ Skill的运行时、工具链、基础设施 │ │
│ │ → 回答"Skill跑在什么环境上、需要哪些依赖" │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└───────────────────────────────────────────────────────────────┘
用表格更清晰地展示每一层的核心映射关系：
| 架构层 | 核心问题 | Skill映射 | 示例 |
|---|---|---|---|
| BA 业务架构 | Skill解决什么业务问题？ | 按能力域分组：协同办公、内容生产、数据智能、系统运维等 | "数据智能"域包含客户画像、股票监控、财务智能等Skill |
| DA 数据架构 | Skill间数据如何流转？ | 统一数据格式(Markdown/JSON)，标准化数据源→转换→消费管道 | 搜索Skill输出Markdown，报告Skill消费Markdown生成PDF |
| AA 应用架构 | Skill如何组合复用？ | 构建依赖图谱，上层组合下层，同类可替换 | 日报Skill = 搜索 + 摘要 + PDF转换 + 消息推送 |
| TA 技术架构 | 运行环境与基础设施？ | 运行时(Node.js/Python/Bash)、外部API、认证体系 | 飞书Skill依赖OAuth 2.0，股票Skill依赖行情API |
BA：从业务能力域出发
BA层的核心工作是"能力域划分"。不要按技术实现分类Skill，要按业务价值分类。一个"协同办公"能力域下面，飞书日程、企业微信待办、钉钉审批虽然对接不同平台，但解决的是同一个业务问题。反过来，"飞书套件"把日历、文档、消息、任务捆在一起，看似整齐，却掩盖了能力域的本质。
正确的做法是先画出业务能力地图，再把Skill填进去。缺失的能力域意味着需要新建Skill，同一域内的重叠Skill意味着需要合并或分层。实践中我们发现，7个能力域（协同办公、内容生产、数据智能、系统运维、开发工具、消息通道、娱乐生活）足以覆盖70+个Skill的分类。
DA：让数据在Skill间自由流动
数据架构解决的是Skill之间的"对话协议"。两个Skill要协作，必须约定数据格式。在实践中我们确立了几条规则：文档类输出统一用Markdown，API数据交换统一用JSON，时间字段统一用ISO 8601，用户标识统一用开放平台ID。同时识别出三类数据角色：数据源Skill（搜索、行情接口）、数据转换Skill（摘要、画像生成）、数据消费Skill（报告推送、告警通知）。数据流向必须是"源→转换→消费"，不允许消费Skill直接做原始数据采集——这跟数据仓库的ODS→DWD→ADS分层是一个逻辑。
AA：构建可组装的Skill图谱
应用架构关注的是Skill之间的组合与依赖。核心原则是：上层Skill必须组合下层Skill，绝不重复实现下层逻辑。一个股票监控Skill自己写爬虫——违反了这条原则。正确做法是依赖"搜索Skill"获取数据，自己只负责分析逻辑。这样当搜索能力升级（比如换了更快的API），所有上游Skill自动获益。
依赖分为强依赖和弱依赖。强依赖意味着Skill无法独立运行（如报告Skill依赖PDF转换），弱依赖意味着功能降级但可用（如故障排查Skill对平台套件的依赖是可选的）。在实际部署中，强依赖必须标注在Skill元数据中，弱依赖可以按环境条件加载。
TA：基础设施决定Skill的上限
技术架构层容易被忽视，却决定了整个Skill体系的天花板。需要明确四个子层：运行时层（Node.js网关、Python脚本引擎、Bash命令行、浏览器自动化）、工具链层（Git、tmux、curl、Chromium）、基础设施层（Skill注册中心、记忆系统、消息路由器）和外部集成层（飞书/企微/钉钉/GitHub等开放平台）。每一层的选型都影响Skill的可移植性和可扩展性。比如，如果一个Skill强依赖Chromium的特定版本，它在无头服务器上的部署就会受限。
TOGAF构建块思想：从原子能力到多智能体联动
TOGAF将架构元素分为架构构建块（ABB）和解决方案构建块（SBB）。映射到Skill体系：ABB是原子级Skill，不可再分；SBB是组合Skill，由多个ABB组装而成。更进一步，多个SBB可以再次组合，形成解决特定行业场景的"组合的组合"；而跨Agent之间的协同编排，则构成了多智能体联动场景。
┌─────────────────────────────────────────────────────────┐
│ ABB → SBB → 组合的组合 → 多智能体联动 │
│ │
│ ABB(基础Skill): 消息发送、搜索、文件读写... │
│ │ │
│ ▼ 组合 │
│ SBB(组合Skill): 任务流编排、文档管道、故障诊断... │
│ │ │
│ ▼ 再组合 │
│ 业务域Skill: 股票监控、日报生成、客户画像... │
│ │ │
│ ▼ 跨Agent编排 │
│ 多智能体场景: 投研生产线、编码军团、故障响应中心... │
└─────────────────────────────────────────────────────────┘
以"投研生产线"为例：L1层的搜索Skill和行情Skill是ABB；L2层的报告模板引擎是SBB；L3层的投研报告生成是业务域Skill；L4层面，投研报告+股票监控+客户画像+日报推送组成完整的生产线，多个Agent各司其职。
构建块思想的核心价值是复用。统计表明，一个核心L1 Skill（如消息推送）被5个以上的L3 Skill依赖。如果没有构建块分层，每个L3 Skill都自建消息推送逻辑，改一个通知格式就要改5个地方。有了构建块，改一次，全部受益。
L0-L4五层分类体系
结合4A思想和构建块复用原则，我们设计了L0到L4的五层分类模型：
┌───────────────────────────────────────────────────────────┐
│ L4 多智能体联动 │ 编码军团、投研生产线、故障响应中心 │
│ │ 跨Agent协作、分布式执行 │
├───────────────────┼───────────────────────────────────────┤
│ L3 业务域编排 │ 股票监控、日报生成、客户画像、投研报告 │
│ │ 完整业务流程、有状态管理 │
├───────────────────┼───────────────────────────────────────┤
│ L2 组合Skill │ TaskFlow引擎、文档管道、渠道配置 │
│ │ 跨域集成、可复用模式 │
├───────────────────┼───────────────────────────────────────┤
│ L1 基础Skill │ 飞书套件、企微套件、搜索、GitHub... │
│ │ 单域封装、可直接调用外部API │
├───────────────────┼───────────────────────────────────────┤
│ L0 原子能力 │ 浏览器、Web搜索、文件读写、Shell执行... │
│ │ 工具原语、不嵌入任何业务逻辑 │
└───────────────────┴───────────────────────────────────────┘
| 层级 | 数量 | 复用度 | 开发成本 | 行业属性 |
|---|---|---|---|---|
| L0 | ~15 | 极高 | 低 | 全行业通用 |
| L1 | ~50 | 高 | 低-中 | 全行业通用 |
| L2 | ~8 | 中 | 中 | 全行业通用 |
| L3 | ~6 | 低 | 高 | 行业专用 |
| L4 | ~2 | 低 | 极高 | 视场景而定 |
一个关键规则：L3及以上Skill必须依赖L2和L1，绝不重复实现下层逻辑。L0层绝不嵌入业务逻辑。这保证了85%的Skill是跨行业通用的，行业特殊性只体现在L3和L4层。
无边界信息流：Skill间的信息破壁
TOGAF的III-RM参考模型有一个核心愿景：无边界信息流——信息应该在正确的时间、以正确的格式、交付给需要的人或系统，不受组织边界和技术边界的限制。
映射到Skill体系，这意味着：一个分析结果不应该被锁在生成它的Skill内部，而应该能被任何需要它的Skill消费。具体落地需要三件事：
第一，统一数据格式。 Markdown作为文档标准，JSON作为API标准，ISO 8601作为时间标准。任何Skill的输出都应符合这三项标准之一。
第二，解耦数据源与数据消费。 搜索Skill只负责"获取"，分析Skill只负责"加工"，推送Skill只负责"送达"。一个典型的信息流是：外部数据源→搜索层→分析层→分发层。搜索Skill获取新闻，摘要Skill提炼要点，报告Skill生成简报，消息Skill推送到飞书或企微——四个Skill各司其职，数据沿管道流动。
第三，记忆层打通跨会话壁垒。 很多Skill的输出需要持久化。加入记忆层（长期记忆文件、每日日志）后，今天的分析结果可以成为明天的上下文。一次投研报告中的行业判断，下次生成同类报告时自动引用。这是更高层次的无边界——时间维度的信息流。
实战案例：四个垂直行业的Skill蓝图
4A架构不是纸上谈兵。以下展示教育、医疗、法律、地产四个行业的Skill设计思路，每一条都遵循BA→DA→AA→TA的自上而下推导。
教育行业：课程编排与学情追踪
BA层识别出三个核心能力域：课程管理、学情追踪、教学资源。DA层的数据标准是：课程用JSON Schema描述，学习进度用时间序列数据，作业用Markdown。AA层组合方案：学情追踪Skill = 飞书多维表格（数据源）+ 摘要Skill（分析）+ 消息推送（通知家长）。TA层需要日历API集成和分数采集接口。
医疗行业：健康监测与就诊编排
BA层能力域：健康监测、预约管理、病历解读。DA层：健康指标用FHIR标准格式，预约数据走医院HIS接口，病历文本用Markdown存储。AA层：健康监测Skill = 可穿戴设备数据源 + 阈值告警引擎(L2可复用) + 企微卡片推送。TA层需要医疗设备对接和隐私合规（数据脱敏是前提）。
法律行业：合同审查与案例检索
BA层能力域：合同审查、法规检索、案例分析。DA层：合同用结构化JSON描述风险条款，法规数据用法条编号索引，案例用Markdown摘要。AA层：合同审查Skill = 文档解析(L1) + 风险识别引擎(L2) + 修订建议生成(L3)。这个场景的价值在于，L2层的风险识别引擎可以同时服务合同审查和合规检查两个L3 Skill，体现构建块复用。
地产行业：房源匹配与市场分析
BA层能力域：房源搜索、市场分析、贷款计算。DA层：房源用GeoJSON描述位置属性，行情数据用时间序列，贷款参数用结构化JSON。AA层：市场分析Skill = 地图POI搜索(L1) + 趋势分析(L2) + 区域报告生成(L3)。其中L2趋势分析引擎与金融行业的股票趋势分析同构，可跨行业复用。
四个行业的共性在于：L0和L1层完全通用（搜索、消息、文档、地图），L2层的模式引擎（告警、分析、模板）高度可复用，行业差异集中在L3层的业务规则和L4层的协作模式上。这正是4A架构的价值所在——用分层隔离变化，用构建块沉淀复用。
回过头看，一个常见的误区是"先写Skill再想架构"。这种做法在Skill数量很少时看不出问题，一旦超过20个，就会遇到开头描述的困境：重复建设、数据孤岛、组合困难、难以演化。正确做法是"架构先行"：先做完BA能力域梳理，再开发Skill；先定DA数据格式标准，再做跨Skill集成；先画AA依赖图，再决定组合方式；先确认TA运行环境，再选技术路线。先慢后快，整体效率反而更高。
还有一个实际建议：建立Skill注册中心。每个Skill在注册时必须声明四项元数据——所属能力域(BA)、数据输入输出格式(DA)、依赖的其他Skill(AA)、需要的运行时环境和API密钥(TA)。这四项声明就是Skill的"架构身份证"，有了它，Skill的发现、复用、替换才有据可依。没有注册中心的Skill体系，就像没有资产目录的仓库——东西都在，但谁也找不到。
总结：从IT治理到AI治理
企业架构思想从IT时代传承到AI时代，其核心没有变：用结构化思维对抗复杂性。4A告诉我们要分层思考（从业务到技术），TOGAF告诉我们要用构建块组合（而非从零开始），无边界信息流告诉我们要让数据自由流动（而非锁在孤岛里）。
变化的是治理对象：从数据库和中间件，变成了Agent Skill和提示词；从SOA服务契约，变成了Skill间的JSON数据格式；从ESB企业服务总线，变成了消息路由器和记忆系统。不变的是方法论：先做业务能力域划分（BA），再定义数据流转标准（DA），然后设计组合依赖图谱（AA），最后选型基础设施（TA）。
AI Agent生态正处在从"能用"到"好用"的拐点。能写一个Skill不难，难的是让100个Skill有序共存、可组合、可演化。企业架构不是AI开发者的负担，而是避免"巴别塔"重演的脚手架。当Skill数量突破临界点时，有没有架构，决定了生态是繁荣还是坍塌。
Agent Skills 开源生态
本文涉及的技能和框架已开源，欢迎 Star / Fork / PR：
| 仓库 | 内容 | 协议 | 链接 |
|---|---|---|---|
| financial-ai-skills | 104个金融AI技能，零API费 | MIT | https://github.com/yuzhaopeng-up/financial-ai-skills |
| teleagent-skills | 5个通用Agent技能(评分引擎/证据链/数据聚合/可视化/NL2Query) | Apache 2.0 | https://github.com/yuzhaopeng-up/teleagent-skills |
| agent-cluster-comm | 5层集群通信技能(L1-L5) | Apache 2.0 | https://github.com/yuzhaopeng-up/agent-cluster-comm |
| skill-framework | 208技能分类体系+L0-L4框架+YAML模板 | MIT | https://github.com/yuzhaopeng-up/skill-framework |
| fintech-h5-demos | 12个零依赖金融H5演示 | MIT | https://github.com/yuzhaopeng-up/fintech-h5-demos |
AI生成
Top comments (0)