近期CTO在内部推行了一个战略叫做《Skill-First：xx公司的技术战略与组织进化》，我觉得是公司和CTO为数不多的正确决策（其他大多数决策我内心都不认可哈哈，都是像长安的荔枝一样的狗屁工作，只是为了工资在作为傀儡执行），引发了我的一些思考。

Skill-First

和云计算微服务时代的API-First类似，Skill-First是AI时代的编程方式——技能优先，面向Skill编程。这种说法实际上是“面向自然语言编程”的一种实现方式，效果类似于Java里面的“面向对象编程”，只不过这里抽象和封装的不再是单个系统的“业务对象”，而是整个公司的“业务域”。

CTO下了一个核心判断：Skill是AI Agent时代的一等公民，认为公司是一组Skill的集合，人和AI Agent是Skill的编排者，例如：

• 数据团队：是指拥有“数据采集”、“分布分析”、“标注管理”、“质量检测”这一组Skill的编排者
• 算法团队：是指拥有“模型训练”、“模型验证”、“模型应用”、“模型迭代”这一组Skill的编排者

开发的核心任务，从实现需求转变为了构建更好的Skill和构建更好的Skill编排机制上。

流程	时间线	结果
需求-排期-开发-测试-上线-维护	周、月	一个独立的、封闭的工具
描述能力-组合Skill-生成Skill-验证和上线	小时、天	一个新的可复用、组合、进化的Skill

Function Calling、MCP、Skill —— 凭什么Skill是一等公民？

很容易提出一个质疑：凭什么Skill是AI Agent时代的一等公民，而之前出现的Function Calling、MCP不是？

首先简单回顾下相关概念：

Function Calling

最开始人们希望利用AI去实现特定功能，比如查询天气、提取字段，引出了一个核心问题——大模型怎么“决定”调用哪个工具、传什么参数？，于是出现了Function Calling。Function Calling提前注册好可以调用的工具方法，让模型生成回答时直接生成调用方法，它的目的是让模型具备将自然语言转换为调用函数的能力，例如：

• 查询今天天气：转换为API调用queryWeather("2026-03-08")
• 读取CSV文件：转换为API调用readCsv("file://mycsvfile.csv")

MCP

但每个平台都有自己的调用格式，因此出现了MCP（Model Context Protocol，模型上下文协议）。它统一了AI与各个组件之间的调用协议，包含：

• 工具清单：描述给AI有哪些工具可以调用
• 传输层：HTTP、gRPC、WebSocket 等多种通信协议
• 上下文透传：如何携带用户身份和会话标识
• 动态发现：主动询问清单

Agent Skill

Function Calling让AI有了执行预设任务的能力、MCP解决了通信协议让“能统一地获取工具”，而Agent Skill则是封装了工作流程和领域知识，让AI可以根据业务领域的信息，对更加复杂的任务进行独立的思考和判断。包含：

• scripts：可执行脚本
• references：业务领域知识文档
• assets：预设模板和资源

Skill可以：根据领域知识、按照专业的执行流程，执行特定任务，期间可以“试错”、“反思”、“固化经验”。

按图灵测试，用Skill执行和用人类执行，从结果上你是看不出来区别的——理论上只要模型够好，AI Agent Skill等价于人类执行复杂业务任务并反思迭代的能力！

用一个实际的案例来说，有同学利用Skill去诊断测试失败的原因，Skill主动找到了当前会话中之前分析过的另一个任务，然后对比两个任务的输入输出得出了更准确的结论，而且这个能力被固化为了一个新的Skill —— 靠概率吐字的大模型，有了类似“记忆”和“迭代”的感觉。

也许以后还会出现新的技术和概念，但目前将Skill看作是AI Agent时代的一等公民，是没有问题的。

Skill-First的架构设计

CTO将Skill-First的落地架构分为了3层，真的有很深入的思考。第3层我不太赞同，我认为编排在第二层已经完成了，第三层应该是“调度观测层”，类似于云原生中的“可观测”概念。

1. 原子工具层（Atomic Tools）

原子化的基础能力，执行特定任务，是Skill的可靠调用工具包。比如当发生性能问题需要检查，那么“arthas工具的使用方法”就是一个原子工具层的能力。

• 必须有极高的工程质量：不允许使用VibeCoding，必须低开销、数据精确、稳定可靠
• 必须是CLI化的
• 必须可测试和可验证
• 只负责单一职责

2. 业务Skill层（Composable Skills）

业务领域能力，能够执行业务语义上的任务，比如“模型训练”。

• 必须有清晰的输入、输出、前置条件、可验收的质量标准
• 理想状态下，只需要描述“需要做什么任务”，就能利用原子工具组装成一个Skill

3. 调度观测层（Scheduling and Observation）

负责Skill的全局管理、调度、观测。

• Skill注册能力和依赖管理
• Skill调度
• Skill可观测：调用次数、成功率、输出质量

Skill-First的落地方案

• 0～3个月：完善原子工具层，优先覆盖使用频率最高的能力
  • 验收标准：可以用命令行完成以前需要登陆多个平台做的事情
• 2～4个月：创建业务Skill，定制10～20个高频业务Skill，支持利用AI Agent用自然语言组合Skill
  • 验收标准：超过 50% 的重复性任务通过 Skill 自动完成
• 3～6个月：全链路Skill化
  • 验收标准：能够评估Skill质量，对Skill进行自动调度，业务从发现问题到解决问题，全链路Skill化

可预见的挑战

基建承压

Skill执行迅速、调用量非常大，基础的数据库、业务的接口将会承压，限流和优化接口性能会是一个非常重要的工作。

异常边界数据会更多

模型的输出不会受到任务限制，需要尽可能覆盖所有异常边界，避免当参数有问题时导致系统瘫痪，比如：

• 模型输出null，绕过redis，直接打崩数据库
• 模型输出错误数据，使用POST接口大量插入、覆盖、删除生产正常数据，无法恢复

权限控制难把控

需要明确Skill执行的权限边界，需要设计非常精妙的权限控制，否则后期一旦有“异常Skill”出现，整个公司的资料外泄（比如最近OpenClaw将用户的密码本公开到网络上、将用户的钱转给其他人等），会有非常大的隐患，比如：

• 查询搜索引擎时，携带公司密钥，等价于将公司密钥公开到网上
• 为了访问指定网站，放开公司内网防火墙端口

智力资源不再稀缺

和蒸汽时代后体力资源不再稀缺类似，解决能源问题后，AI Agent时代智力资源也会变得不再稀缺。目前是无解的，只能尽可能靠近AI，度过艰难的过渡期，活到机器人交税的“福利社会”出现。

AI不能替代人类的唯一场景：AI不能坐牢。