最近大模型圈子可谓是神仙打架,OpenAI 搞出 GPT-5.5,DeepSeek 推出 V4。但对于我们这些在一线搞架构的“老炮儿”来说,比模型本身更让人头疼的,是怎么让 AI 真正、稳定地用好我们的系统。
过去这段时间,MCP(Model Context Protocol)火得一塌糊涂。它的初衷很好:把各种 API 包装成统一的协议喂给 AI。但随着业务复杂度上升,一个致命的架构痛点暴露无遗——上下文膨胀 (Context Inflation)。
1. 痛点:被 MCP 撑爆的上下文与暴涨的账单
很多开发者在实际项目中踩过这个坑:为了让 AI 懂业务,一口气接入了十几个 MCP 服务器。结果呢?
- 智商掉线:每次调用,几万 Token 的 API 描述和参数定义被无脑塞进上下文。AI 面对庞杂的“字典”,连最基本的推理都做不好了。
- 成本刺客:这些毫无区分度的前置上下文,每次交互都要消耗真金白银。
- 维护地狱:底层接口一变,所有的适配器代码都要跟着改,技术债越堆越高。
在我们打磨 有鱼智界(全能 AI 员工)的架构时,也深刻体会到:AI 缺的从来不是数据,而是结构化、场景化的“行动指南”。
这就好比你招了一个实习生,你不能把公司所有的系统源码和数据库表结构全扔给他,然后指望他自己去领悟。你需要给他的是一本 SOP(标准作业程序)。
2. 谷歌的破局:Agent Skill 到底是个啥?
为了解决这个痛点,谷歌官方近日开源了 Agent Skills 仓库 (github.com/google/skills)。
官方定义是:“一种简单开放的格式,用于赋予智能体新的能力和专业知识”。用人话来说,它就是一份按需加载的 Markdown 格式的 SOP。
让我们通过一张图来看看传统 MCP 工具调用与 Agent Skill 的架构差异:
graph TD
subgraph 传统 MCP 架构 (上下文膨胀)
A[User Query] --> B(LLM Agent)
B -->|加载所有可用工具| C{MCP Servers}
C -->|巨量 API 定义 Token| B
B --> D[混乱的推理与执行]
end
subgraph Agent Skill 架构 (按需精准加载)
E[User Query] --> F(LLM Agent)
F -->|语义路由 / 意图识别| G[Skill 知识库]
G -.->|仅加载命中场景的 Markdown SOP| F
F --> H[精准调用底层 API / 工具]
end
style C fill:#ffcccc,stroke:#ff0000,stroke-width:2px
style G fill:#ccffcc,stroke:#00aa00,stroke-width:2px
Agent Skill 的设计哲学只有两点:
- 轻量化:用 Markdown 写,不仅人能看懂,模型解析起来也毫无压力。
- 按需加载:别一股脑儿全塞进去,AI 遇到什么场景,就临时拉取对应的 Skill 文档。
3. 拆解 Google Cloud Skills 仓库:不止是 API,更是架构思维
这次谷歌一口气放出了覆盖 AlloyDB、BigQuery、Cloud Run、GKE 等核心服务的 13 项技能。但作为架构师,我更看重的是它里面包含的三大架构支柱技能:
- Security(安全性):教 AI 如何做 IAM 权限控制、数据加密。
- Reliability(可靠性):教 AI 什么是高可用、容错机制。
- Cost Optimization(成本优化):教 AI 怎么省钱。
这才是最硬核的地方!传统的 Tool 只是告诉 AI “做什么 (What)”和“怎么做 (How)”,而 Agent Skill 编码了“为什么这么做 (Why)”。
你不是在教 AI 调接口,你是在给 AI 注入高级架构师的决策逻辑。当 AI 拥有了这些“软技能”,它在生成代码或部署服务时,就不会搞出一个满是安全漏洞、浪费资源的垃圾架构。
4. 总结与思考:从“外挂工具”走向“专业附体”
谷歌开源 Agent Skill,标志着 AI 应用开发正在从粗放的“API 堆砌时代”走向精细化的“知识工程时代”。
相比于 RAG(被动检索)和微调(迭代太慢),Skill 提供了一个极佳的折中方案:它具有业务逻辑的迭代速度,又能主动将专业知识注入给大模型。
作为开发者,我们现在要做的,不仅是暴露 API,更是要学会编写优秀的 Skill。把我们在过去 10 几年里踩过的坑、总结的经验,固化成一份份 Markdown SOP。只有这样,AI 才能真正从“懂对话的玩具”蜕变为像 有鱼智界 这样能够独当一面的“数字员工”。
未来已来,你的 Agent 准备好装载新技能了吗?