背景：Agent Skills 正在成为主流交付物
最近几年，AI Agent 把 Skill（技能）变成了最常见的交付物。人人都在写，代码库里堆满了技能，每个人的电脑上还有自己专属的技能。
以下两个新情况随之而来：
- 技能快速膨胀，缺乏治理。 命名撞车、逻辑重复、描述含糊的技能越来越多，没有任何设计把关。
- 应用系统的定义发生漂移。 从“一个系统或模块”变成了一个能通过自然语言触发的“能力单元”。
对应用&技术架构师而言，这带来了不小的挑战。
应用&技术架构的传统职责
应用架构师
传统上，应用架构师是业务与系统之间的桥梁，关注整个应用组合的规划，其职责通常有以下几个方面：
- 业务需求理解：将业务战略和需求转化为应用能力和功能规划
- 应用组合管理: 规划应用生态——哪些该建、哪些该合并、哪些该淘汰
- 应用间交互设计：定义系统间的集成方式、数据流转、接口契约
- 领域划分：划定各应用的业务边界和职责范围
- 非功能需求对齐:确保应用层满足可用性、扩展性、合规性等要求
- 架构评审与治理:评审应用级方案，保证业务与技术的一致
技术架构师
相应地，技术架构师是技术方案的决策者，关注组织的技术体系，其职责通常有以下几个方面：
- 技术选型：评估和选择框架、语言、数据库、中间件、云服务
- 技术标准制定：编码规范、API 风格、日志格式、CI/CD 规范
- 系统技术方案设计： 接口规范、安全策略、部署架构、可观测性
- 跨系统技术问题：性能调优、分布式事务、数据一致性、容错机制
- 新技术引入：技术预研、POC 验证、推广落地
AI 时代的应用架构与技术架构职责
进入 AI Agent 时代后，Skill（技能）正在取代传统的应用成为一种核心交付物。这两个角色的职责也亟需随之演进。
AI 时代的应用架构师
对照应用架构师的传统职责，进入 AI 时代后，他们在 Skill 管理方面应该发挥以下作用：
- 技能定位与边界：定义每个技能解决什么业务问题、不解决什么
- 技能组合规划：规划技能生态——哪些该创建、哪些可合并、哪些该废弃
- 技能间协作设计：定义技能调用关系、输入输出契约、数据流转路径
- 场景覆盖分析：识别业务场景是否有对应技能覆盖，发现覆盖盲区
- 技能粒度决策：拆太细管理成本高，拆太粗复用性差，需要找到合适的粒度
- 用户体验定义：技能以自然语言触发，如何让用户无感知地调用正确的技能
AI 时代的技术架构师
相应地，技术架构师在 Skill 管理方面应该发挥以下作用：
- 技能规范制定: 包括统一命名规范，描述规范；统一目录结构，脚本入口；统一脚本语言；
- 管理规范制定：对技能进行分类管理，形成技能资产
- 质量门槛设定：每个技能必须包含README、用例、错误处理、测试等元素
- 安全与权限框架：设计 tool_guard、file_guard、approval_level 的配置规则
- AI 匹配优化：分析 AI 匹配命中率、冲突率，迭代描述内容和关键词
- 技能可测试性：确保每个技能可独立验证
- 技能可观测性：可以追踪每个技能的使用情况
架构职责对比：
在 AI 时代，应用架构师的核心职责基本可以一一映射：
- 过去他规划应用系统，现在规划的是 Agent 技能；
- 过去定义系统间的 API 接口，现在定义技能间的协作关系，只是触发方式从 API 契约变成了自然语言；
- 过去将业务需求转化为功能，现在转化为技能能力，本质相同但粒度更细、交付更快；
- 过去评审应用架构方案，现在评审的是技能的定位和边界。
相比之下，技术架构师的变化更大：
- 过去他们制定编码规范、API 风格和 CI/CD 规范，现在要制定的是命名规范、描述规范和目录结构——标准化的对象从代码变成了元数据；
- 过去他设计安全策略，现在则要设计的是 skill.json 中的 tool_guard、file_guard 和 approval_level——安全防线从网络边界收缩到了技能权限本身；
- 过去他关注系统的可观测性，现在要追踪的是每个技能的命中率和使用情况。
此外，AI 时代还为他们带来了几项全新的职责，包括：技能资产的分类管理、质量门槛的设定、可测试性的保障。
架构职责变化带来的影响
对于应用架构师而言，他们的职责变化并不是很大，可以实现低成本的迁移，只需要补充大约 20% 新能力。
组合规划、边界界定、集成设计等老本领，几乎可以一对一地映射到技能生态。真正的增量只有三块：
- 粒度决策——一个技能什么时候拆、什么时候并，没有传统经验可循
- 自然语言 UX——“用户界面”变成了“用户会怎么说”，触发体验需要设计师式思维
- 技能编排——从 API 串联变成了“导入→清洗→导出”这种能力链设计
技术架构师的职责变化更大，转型紧迫性更高。这主要是因为许多来自传统职责的经验失效了，像编码规范、API 风格、CI/CD 规范这些老本领在技能管理方面没了用武之地。
而像技能资产的分类管理、质量门槛的设定、可测试性的保障等职责，则完全是在技能生态中自己长出来的需求，过去从未做过。
这意味着，技术架构师转型不是在原地换一块招牌就能完成的。其中护栏设计成为最高的风险项，因为技能会执行真实代码、接触真实凭据等可能带来极大副作用的操作。
技术架构师转型路线
首先是理解 AI 的匹配机制，观察描述怎么影响技能命中率。这是新世界的“物理定律”，是理解技能的基础。
其次是定义好命名和描述规范，这项工作成本低、收益高，可以作为第一份落地产物。
第三项是技能资产的分类管理，保障技能质量，避免重复建设，方便技能分发等。
第四项是安全与权限护栏，因为技能会执行真实代码、接触真实凭据，所以风险很高。这一层要尽快建立。
最后是匹配遥测和持续迭代，跟踪技能使用情况，记录命中率和混淆对，反哺描述优化，形成闭环。
忠告： 技能需要治理，但也别过度治理。技能的灵魂是轻量化、创建速度快。
一句话收尾： AI 时代不需要架构师转行，应用架构师依旧是管好“建什么”，技术架构师依旧是管好“怎么建”，他们之间的分工协作基本也没多少变化，只是因为管理对象有所不同，他们都需要增加几项新技能。
