躬行笔记 » 别只顾着跟ChatGPT聊天了，手把手教你给AI装上“麒麟臂”：深度解析 Agent Skill 是个啥

最近这大半年，我也没少折腾大模型。咱们搞运维的，原本以为也就是写脚本、搬服务器、调参数，结果现在还得被迫学习 Prompt Engineering（提示词工程），甚至得研究怎么让 AI 替我们干活。

只要你稍微深入玩过一点 AI，肯定遇到过这种抓狂的情况：你问 ChatGPT，“帮我查一下线上数据库里用户表最后一条记录是什么”，它一本正经地回复你：“对不起，我是一个人工智能助手，无法访问您的私有数据库……”

这时候你就想把键盘砸了。我们要的不是一个只会陪聊的吉祥物，我们要的是能干活的！能跑 SQL 的！能重启 Pod 的！能查日志的！

这就是今天我要跟大伙唠的——Agent Skill（技能）。

说得玄乎点，这是 AI 的“感知与执行能力”；说得通俗点，这就是给“脑子在云端”的大模型，装上了“手和脚”，让它能伸进我们的生产环境里搞破坏……啊不，搞建设。

今天不扯那些虚头巴脑的概念，咱们就从代码和架构层面，把这个 Skill 到底是个什么鬼，怎么写，有什么坑，一次性给它扒干净。文章可能有点长，建议先收藏，回头蹲坑的时候慢慢看。

所谓的“大脑”与“手”

咱先得把思维转过来。以前我们写运维平台，逻辑是死的。

if CPU > 90% then alert()

这是规则。

现在用了 Agent，逻辑是活的。

User: "CPU 好像炸了，你去看看" -> Agent (思考): "用户说 CPU 炸了 -> 我应该查一下监控 -> 我需要调用 Prometheus 的 API -> 拿到数据后分析一下"

看到没？中间那个“调用 Prometheus API”，就是 Skill。

大模型本身（比如 GPT-4, Claude, DeepSeek）只是一个推理引擎。它像是一个刚毕业的、读过全世界所有书但被关在小黑屋里的博士生。他懂 Linux 内核原理，懂 TCP/IP 握手，但他没法碰到你的键盘。

Agent Skill，就是你递给这个博士生的一把螺丝刀，或者一台连接了内网的终端。

从技术实现上看，Skill 到底是什么？

别被那些 LangChain、AutoGPT 之类的框架名词吓唬住了。剥去外壳，Skill 的本质就三样东西：

函数（Function）：真正干活的代码。
Schema（描述）：告诉 AI 这个函数是干嘛的，需要传什么参数。
工具调用协议（Function Calling）：AI 决定调用这个函数时，怎么传递指令。

一个最简单的 Skill 解剖

咱们搞技术的，不看代码心里不踏实。

假设我想让 Agent 帮我把一个很长的 Unix 时间戳转换成人类能看懂的时间。AI 其实自己也能算，但经常算错（大数学家嘛）。最靠谱的是调用 Python 的 datetime 库。

如果你要封装这样一个 Skill，它在代码里长这样（伪代码，意会即可）：

# 1. 这是真正干活的函数
def get_current_time(timezone="Asia/Shanghai"):
    """获取当前系统的格式化时间"""
    import datetime
    return datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")

# 2. 这是给 AI 看的“说明书” (Schema)
tool_definition = {
    "name": "get_current_time",
    "description": "当用户询问现在几点，或者需要获取当前时间戳时使用此工具。",
    "parameters": {
        "type": "object",
        "properties": {
            "timezone": {
                "type": "string",
                "description": "时区字符串，默认为 Asia/Shanghai"
            }
        }
    }
}

注意那个 description。这才是 Agent Skill 的灵魂！

咱们写代码，注释是给人看的，代码是给机器跑的。
但是在 Agent 的世界里，注释（描述）是给 AI 看的，直接决定了它会不会用这个工具。

如果你把 description 写成 func_time_01，AI 根本不知道这是啥，它可能就会在那胡说八道。如果你写成“获取当前时间”，当用户问“现在几点”时，大模型内部的概率分布就会指向这个工具。

这一步，其实就是所谓的 Function Calling 流程：

用户问：“现在几点？”
大模型一看手中的工具箱（Prompt 里塞进去的 Schema 列表），心想：“嘿，get_current_time 这个工具好像对口。”
大模型不直接回答用户，而是输出一个特殊的 JSON：{"tool": "get_current_time", "args": {"timezone": "Asia/Shanghai"}}。
你的程序（Agent 运行时）拦截到这个 JSON，去执行真正的 Python 函数。
拿到结果 "2025-02-24 15:30:00"，再把这个结果塞回给大模型。
大模型看到结果，最后告诉用户：“现在的北京时间是 2025-02-24 15:30:00”。

这整个闭环，才构成了一个完整的 Skill 调用。

生产环境中的 Skill 没那么简单

上面那是玩具。在真实的运维场景里，我们要写的 Skill 复杂得多。

我想想我最近写的一个 Skill，是用在大盘监控助手里的。那个需求是：查某个服务在 K8s 里的日志。

这玩意儿要是写成 Skill，坑不仅多，而且深。

第一个坑：参数的幻觉。

你定义了一个 Skill 叫 fetch_k8s_logs，参数需要 namespace, pod_name, lines。
用户问：“帮我看看支付服务的日志。”
AI 怎么知道“支付服务”对应哪个 Namespace？对应哪个 Pod？

它不知道。所以它可能会胡编乱造一个 namespace="payment-prod", pod_name="payment-service-123"。
这时候你的函数一跑，报错：Pod 不存在。

怎么解决？
这就不单单是一个 Skill 的问题了，这是 Skill 设计模式的问题。通常有两种路子：

写死映射：在 Prompt 里告诉 AI，“支付服务对应的 label 是 app=payment”。
多步 Skill：你得先给 AI 一个 list_pods(keyword) 的技能。AI 得先搜一下，拿到真实的 Pod 名字，再调用 fetch_k8s_logs。

这就是为什么现在的 Agent 看起来有点呆，反应慢，因为它在后台可能默默跑了好几个来回的 Skill。

第二个坑：输出太长，撑爆上下文。

运维的日志，那是没边的。你直接 kubectl logs 一下，几十兆文本出来了。
如果你把这几十兆文本直接 return 给大模型，大模型当场就得 OOM（Token 超限），或者 API 费用直接让你破产。

一个成熟的 Skill，必须对返回值进行裁剪和压缩。
我在写日志查询 Skill 的时候，会在 Python 代码里做个截断：只取最后 2000 个字符，或者用简单的正则提取 Error 关键字周边的行。
你要记住，Skill 的返回值是给 AI 读的，不是给终端显示的。你需要把最核心的信息喂给它，而不是把整个世界塞给它。

第三个坑：安全，安全，还是 TMD 安全。

我之前看过有个哥们，给 Agent 写了一个 exec_shell_command 的通用 Skill。
他在 Description 里写：“执行任意 Shell 命令”。
好家伙，简直是把 root 密码贴在脑门上裸奔。

万一用户（或者 Prompt 注入攻击）诱导 AI 执行了 rm -rf / 呢？或者 cat /etc/passwd？
虽说现在的模型都在做对齐（Safety Alignment），不会轻易干坏事，但作为运维，哪怕有 0.1% 的概率我们也不敢赌啊。

所以，绝对不要写通用的 Shell 执行 Skill。
要写专用的。比如 restart_nginx, clean_log_files, query_mysql_read_only。
把动作限制在最小权限范围内。这就是“原子化 Skill”的概念。

如何设计一个优雅的 Ops Skill？

这部分全是干货，建议做笔记。

我在设计运维 Agent 的技能库时，遵循这么几个原则，这都是血泪换来的教训：

1. 原子性（Atomicity）
一个 Skill 只做一件事。
别写一个 diagnose_system 的超级大函数，里面既查 CPU 又查磁盘还查数据库。
拆开。check_cpu, check_disk, check_db_latency。
让 AI 自己根据情况组合使用。如果用户只问 CPU，它就不需要去骚扰数据库。这也符合微服务的思想嘛。

2. 鲁棒性（Robustness）
你的 Skill 代码必须能扛得住 AI 的胡乱输入。
比如你需要一个 int 类型的端口号，AI 抽风传了个字符串 "8080" 甚至 "default"。
你的代码里要做类型转换和异常捕获。
千万别让 Skill 的报错直接把 Agent 进程搞挂了。如果出错，应该 return 一个清晰的错误信息字符串，比如 {"error": "端口号格式错误，请输入数字"}。
这样 AI 看到错误信息，它甚至会自己反思：“哎呀，我传错参数了，我重新调一次。” —— 这真的很神奇，现在的 LLM 是有自我纠错能力的，前提是你得告诉它错哪了。

3. 描述即代码（Prompt as Code）
刚才说了，Schema 里的 Description 至关重要。
有些复杂的参数，我在 Description 里甚至会写上 Example。
比如：
parameter: status_code
description: "HTTP状态码。例如：200, 404, 500。请不要使用 'success' 这种文本描述，必须是数字。"
你写得越像教幼儿园小朋友，AI 表现得越好。

4. 结构化输出
Skill 的返回值最好是 JSON 格式，或者是 Markdown 表格。
虽然 LLM 能理解乱七八糟的文本，但结构化数据能让它更容易提取关键指标。
比如查数据库，返回：
[{"id": 1, "status": "active"}, {"id": 2, "status": "dead"}]
比返回一段自然语言描述要好得多。

一个实战案例：自动封禁异常 IP

咱们来串起来想个场景。

假设我们要搞一个安全运维 Agent。当发现 Nginx 日志里有大量 404 扫描时，自动封禁 IP。

我们需要给 Agent 配备三个 Skill：

Skill A: analyze_nginx_access_log
- 入参：limit (分析最近多少行)
- 功能：读取日志，统计 IP 访问频率和 404 次数。
- 出参：JSON 列表，包含可疑 IP 和对应的攻击次数。
Skill B: check_ip_reputation
- 入参：ip_address
- 功能：调用外部威胁情报 API（比如微步在线），查这个 IP 是不是已知的肉鸡。
- 出参：RiskLevel (High/Medium/Low)。
Skill C: block_ip_iptables
- 入参：ip_address
- 功能：执行 iptables -I INPUT -s {ip} -j DROP（注意权限控制！）。
- 出参：执行结果 Success/Fail。

工作流是这样的：
监控系统报警 -> 触发 Agent -> Agent 调用 Skill A 拿到列表 -> Agent 发现有个 IP 很猛 -> Agent 思考：“我得确认一下这是不是误报” -> 调用 Skill B -> 确认是高危 IP -> Agent 决定：“封了它！” -> 调用 Skill C。

你看，这如果不拆分成 Skill，全写在一个脚本里，逻辑会极其复杂。而且如果我想把封禁策略改成“只封禁海外 IP”，脚本得重写。
用 Agent 的话，我只需要在 Prompt 里改一句话：“只封禁地理位置在海外的高危 IP”，AI 就会自己去想办法（可能需要你再补一个查询 IP 地理位置的 Skill）。

这种灵活性，才是 Agent Skill 的真正魅力。

别高兴得太早：延迟与成本

吹了半天好，也得泼点冷水。

用 Agent Skill 最大的痛点是慢。
用户发一条指令，中间可能涉及 3 次大模型推理 + 3 次 Skill 调用。
现在的 GPT-4o 或者是 DeepSeek V3，哪怕推理速度再快，这么来回倒腾，几秒钟甚至十几秒就过去了。
如果你指望用它来处理高频实时交易，那还是洗洗睡吧。
它适合做离线的、复杂的、决策类的运维任务。比如故障根因分析、配置变更审计、资源巡检。

还有一个是成本。
Skill 的定义（Schema）是每次对话都要塞进 Prompt 里的。
你如果定义了 50 个工具，光是工具描述就占了几千个 Token。每次问答都要带上这几千个 Token，这都是白花花的银子（或者 GPU 算力）。
所以现在的趋势是 RAG for Tools。
如果你的工具库很大，先用向量检索找到相关的 3-5 个工具，再把这几个塞给大模型，而不是一股脑全塞进去。

总结

Agent Skill 说白了，就是 API 的“自然语言接口化”。

以前我们写 API 是给程序员用的，文档写在 Swagger 里。
现在我们写 Skill 是给 AI 用的，文档写在 Schema 的 Description 里。

这对我们运维人员提出了新的要求。以前你只要会写 Python 脚本就行；现在，你得会写“让 AI 能看懂、爱用、用不错”的 Python 脚本。

这玩意儿未来会成为基础设施。
以后你入职一家公司，可能不是问“你们的 CMDB 准不准”，而是问“你们的运维 Agent 都有什么技能？能不能帮我自动排查 K8s CrashLoopBackOff？”

这波浪潮已经来了。咱们做运维的，本来就是干杂活出身，适应能力最强。别把这当成威胁，把它当成咱们手里更强的一把锤子。当你能熟练地编写 Skill，指挥 AI 帮你干掉 80% 的重复性排查工作时，你就可以端着咖啡，看着屏幕上的日志自动滚动，深藏功与名了。

不说了，我得去把那个连不上数据库的 Skill 调试一下，这破 AI 又开始幻觉参数了……

最后，如果你对 AI 运维、Agent 开发、或者是那些奇奇怪怪的生产环境故障感兴趣，欢迎关注我的公众号。咱们一起在运维的泥潭里，仰望 AI 的星空。

公众号：运维躬行录
个人博客：躬行笔记

别只顾着跟ChatGPT聊天了，手把手教你给AI装上“麒麟臂”：深度解析 Agent Skill 是个啥