企业官网建设流程全解析

1. 从"skills"这个热词说起：它到底在解决什么问题

最近一段时间，"skills"这个词在技术社区里出现的频率高得离谱。不管是在讨论 Google Cloud 上的 Agent 构建，还是在聊 GKE 集群里的自动化任务编排，甚至是在 Genkit 这类 AI 应用框架的语境下，大家都在反复提到一个词——Agent Skills。如果你只是偶尔刷到这些讨论，可能会觉得这又是一个新造的概念，跟之前那些"插件""工具调用""函数注册"没什么本质区别。但真正上手用过之后，你会发现它解决的问题其实非常具体：让一个 Agent 知道自己在什么场景下该做什么事，并且能把这件事做对。

我最初接触这个概念是在一个 GKE 上的运维自动化项目里。当时的诉求很简单：希望有一个 Agent 能根据集群的实时状态，自动判断是该扩容、该重启某个 Pod，还是该触发一次滚动更新。最开始的做法是把所有逻辑写在一个巨大的 prompt 里，把所有可能的操作都列出来，让模型自己去选。结果就是，模型经常在不需要扩容的时候扩容，在该重启的时候去改配置，整个系统的行为极其不稳定。后来换成了 Agent Skills 的思路，把每一种能力拆成独立的 skill，每个 skill 有自己的触发条件、执行逻辑和边界约束，整个系统的可靠性立刻上了一个台阶。

这就是 skills 的核心价值所在：它不是简单的工具注册，而是一种带有语义约束的能力封装。一个 skill 不仅仅告诉 Agent "你能调用这个函数"，更重要的是告诉它 "你在什么情况下应该调用这个函数，调用时需要注意什么，调用之后应该期待什么结果"。这个区别听起来很细微，但在实际项目里，它直接决定了 Agent 是能用还是不能用。

从 Google Cloud 的生态来看，Agent Skills 这个概念和 Genkit 框架的结合尤其紧密。Genkit 本身是一个用于构建 AI 应用的开发框架，它提供了工具定义、流程编排、模型调用等基础能力。而 Agent Skills 则是在这个基础上，进一步抽象出了一层"能力语义层"。你可以把 Genkit 理解成一套工具箱，而 Agent Skills 则是告诉 Agent "什么时候该用哪把工具、怎么用、用完怎么判断结果对不对"的那套说明书。

对于正在做 Agent 开发的团队来说，理解 skills 的设计理念比学会某个具体 API 更重要。因为 skills 的本质是一种架构模式，它解决的是"如何让 Agent 的行为可控、可预测、可维护"这个根本问题。不管你用的是 Google Cloud 的 Agent Builder，还是自己在 Genkit 上搭一套，甚至是用其他框架，这套思路都是通用的。

接下来的内容，我会从实际项目的角度出发，把 Agent Skills 的设计思路、落地步骤、常见坑点、以及和 GKE、Genkit 这些具体技术的结合方式，完整地拆一遍。不管你是刚接触 Agent 开发的新手，还是已经在做相关项目但遇到了瓶颈的工程师，应该都能从中找到可以直接用的东西。

2. Agent Skills 的本质：不是工具调用，而是能力语义封装

2.1 为什么"函数注册"式的做法在真实项目里会崩

很多人第一次接触 Agent 开发时，理解是这样的：我有一堆函数，把它们注册给模型，模型根据用户输入决定调用哪个函数，然后我执行函数并把结果返回给模型，模型再生成最终回复。这个流程在 demo 里跑得很好，但一到真实项目就会出问题。

问题出在哪儿？出在模型对函数的理解是扁平的。在模型眼里，所有注册的函数都是平等的选项，它只能根据函数名和描述来猜测什么时候该用哪个。当函数数量少、场景简单时，这种猜测还能凑合。但一旦函数数量超过十个，或者多个函数的功能有重叠，模型就开始乱选了。

我见过一个典型的案例：一个客服 Agent 注册了"查询订单""修改地址""取消订单""发起退款"四个函数。用户说"我昨天买的东西不想要了"，模型有时候调"取消订单"，有时候调"发起退款"，有时候甚至先调"查询订单"再调"修改地址"。原因很简单，这四个函数在模型看来都是"处理用户对订单的不满"，它分不清哪个才是正确的第一步。

Agent Skills 要解决的就是这个问题。它不是在函数层面做文章，而是在能力语义层面做文章。一个 skill 不仅仅是一个可调用的函数，它包含了几个关键要素：

• 触发条件：什么情况下这个 skill 应该被激活
• 前置约束：执行这个 skill 之前需要满足什么条件
• 执行逻辑：具体做什么
• 后置验证：执行完之后怎么判断结果是否符合预期
• 失败处理：如果执行失败或者结果不对，应该怎么回退

这五个要素合在一起，才构成一个完整的 skill。而普通的函数注册只覆盖了第三个要素。

2.2 Skill 的语义边界：让 Agent 知道"不该做什么"

这一点是我在实际项目里体会最深的。一个好的 skill 定义，不仅要告诉 Agent 能做什么，更要告诉它不能做什么。

举个例子，在一个 GKE 运维 Agent 里，我们有一个 skill 叫"scale_workload"，用于调整工作负载的副本数。如果只写"这个 skill 可以调整副本数"，模型可能会在流量低谷时把副本数调到 0，导致服务完全不可用。但如果在 skill 定义里加上约束："副本数不得低于 2，且调整幅度单次不得超过 50%"，模型的行为就会稳定得多。

这种约束不是写在代码里的硬校验，而是写在 skill 描述里的语义约束。模型在决定是否调用这个 skill 时，会参考这些约束。当然，代码层面的硬校验也必须有，两者是互补关系。语义约束减少模型犯错的可能性，硬校验兜住模型犯错后的后果。

在 Genkit 里，你可以通过 tool 的 description 字段来承载这些语义约束。但要注意，description 不是越长越好。我试过写一个 500 字的 description，结果模型反而抓不住重点。后来总结出来的经验是：核心约束用短句列出来，每条不超过 20 个字，最多 5 条。比如：

调整工作负载副本数。 约束： - 副本数范围 2-20 - 单次调整幅度不超过 50% - 调整前需确认当前无进行中的发布 - 流量高峰期禁止缩容

这种格式模型理解起来最稳。

2.3 Skill 和 Tool 的区别：一个类比

如果用生活化的类比来解释，Tool 就像是给你一把锤子，告诉你"这是锤子，可以敲钉子"。而 Skill 则是告诉你"当你要把钉子钉进木板时，用这把锤子，敲的时候要垂直，力度要适中，如果钉子歪了要先拔出来重敲"。

Tool 是能力本身，Skill 是能力的正确使用方式。在 Agent 开发里，模型不缺能力，缺的是"什么时候该用什么能力、怎么用才对"的判断力。Agent Skills 补的就是这块。

从架构上看，一个 Skill 通常包含：

这张表是我在实际项目中总结出来的映射关系。你会发现，Genkit 的 tool 机制只直接覆盖了"执行逻辑"这一块，其他四块都需要你自己在设计层面补上。这就是为什么很多人用 Genkit 做出来的 Agent 不稳定——他们只做了 tool 注册，没做 skill 设计。

3. 在 Google Cloud 上落地 Agent Skills 的完整路径

3.1 环境准备：GKE 集群和 Genkit 项目的初始化

如果你打算在 Google Cloud 上做 Agent Skills 的落地，最顺手的组合是 GKE + Genkit。GKE 提供运行环境，Genkit 提供开发框架。下面是我实际用下来比较稳的一套初始化流程。

首先是 GKE 集群的创建。如果你只是做开发测试，用 Autopilot 模式最省心，不用管节点池的配置。但如果是生产环境，建议用 Standard 模式，因为 Agent 类工作负载对资源的要求比较特殊，需要精细控制。

gcloud container clusters create agent-skills-cluster \ --region us-central1 \ --num-nodes 3 \ --machine-type e2-standard-4 \ --enable-autoscaling \ --min-nodes 2 \ --max-nodes 10

这里有几个参数值得说明。machine-type选 e2-standard-4 是因为 Agent 工作负载通常是内存敏感型的，模型调用和上下文管理会占用较多内存，4GB 是起步配置。enable-autoscaling是必须的，因为 Agent 的负载波动很大，有时候一批任务进来需要快速扩容，有时候长时间空闲需要缩容。

集群建好之后，接下来是 Genkit 项目的初始化。Genkit 支持 Node.js 和 Go 两种语言，我这边用 Node.js 比较多，因为生态更成熟。

npm install -g genkit-cli mkdir agent-skills-demo && cd agent-skills-demo npm init -y npm install genkit @genkit-ai/googleai

初始化完成之后，你需要配置模型访问。Genkit 支持多种模型后端，在 Google Cloud 环境下，用 Vertex AI 是最自然的选择。

import { configureGenkit } from 'genkit'; import { vertexAI } from '@genkit-ai/vertexai'; configureGenkit({ plugins: [ vertexAI({ projectId: 'your-project-id', location: 'us-central1', }), ], logLevel: 'debug', enableTracingAndMetrics: true, });

enableTracingAndMetrics这个选项我强烈建议打开。Agent 的行为调试非常依赖 trace，没有 trace 你根本不知道模型为什么选了某个 skill、为什么没选另一个。这个后面会详细讲。

3.2 Skill 的定义：从"能做什么"到"该怎么做"

环境准备好之后，核心工作就是定义 skill。我以 GKE 运维场景为例，完整走一遍 skill 的定义过程。

假设我们要定义一个"检查 Pod 健康状态"的 skill。最粗糙的做法是直接写一个函数：

export const checkPodHealth = ai.defineTool( { name: 'checkPodHealth', description: '检查 Pod 的健康状态', inputSchema: z.object({ namespace: z.string(), podName: z.string(), }), outputSchema: z.object({ status: z.string(), restarts: z.number(), lastRestart: z.string(), }), }, async (input) => { // 调用 K8s API 获取 Pod 状态 const pod = await k8sApi.readNamespacedPod(input.podName, input.namespace); return { status: pod.status.phase, restarts: pod.status.containerStatuses[0].restartCount, lastRestart: pod.status.containerStatuses[0].lastState.terminated?.finishedAt || 'never', }; } );

这个定义能用，但它只是一个 tool，不是一个 skill。它没有告诉模型"什么时候该检查 Pod 健康状态""检查出来异常之后该怎么办""哪些情况下不应该检查"。

一个完整的 skill 定义应该是这样的：

export const checkPodHealth = ai.defineTool( { name: 'checkPodHealth', description: `检查指定 Pod 的健康状态。 使用场景： - 用户报告服务异常时 - 例行巡检时 - 发布后验证时 约束： - 单次只检查一个 Pod - 命名空间必须存在 - 如果 Pod 不存在，返回明确错误而非重试 输出解读： - status=Running 且 restarts<5 视为健康 - restarts>=5 需要进一步检查日志 - status!=Running 需要触发告警`, inputSchema: z.object({ namespace: z.string().describe('Pod 所在的命名空间'), podName: z.string().describe('Pod 的名称'), }), outputSchema: z.object({ status: z.string(), restarts: z.number(), lastRestart: z.string(), healthy: z.boolean(), }), }, async (input) => { try { const pod = await k8sApi.readNamespacedPod(input.podName, input.namespace); const restarts = pod.status.containerStatuses[0].restartCount; const status = pod.status.phase; return { status, restarts, lastRestart: pod.status.containerStatuses[0].lastState.terminated?.finishedAt || 'never', healthy: status === 'Running' && restarts < 5, }; } catch (error) { if (error.response?.statusCode === 404) { throw new Error(`Pod ${input.podName} 在命名空间 ${input.namespace} 中不存在`); } throw error; } } );

对比一下就能看出区别。第二个版本里，description 承载了大量的语义信息：使用场景、约束、输出解读。这些信息会直接影响模型的行为。而 handler 里增加了错误处理，确保 Pod 不存在时返回明确错误而不是让模型反复重试。

3.3 Skill 的编排：多个 skill 如何协同

单个 skill 定义好之后，接下来的问题是怎么让多个 skill 协同工作。在 GKE 运维场景里，通常需要这样一条链路：检查 Pod 状态 → 如果异常，检查日志 → 如果日志显示是配置问题，检查 ConfigMap → 如果确认是配置问题，触发配置更新。

这条链路如果让模型自己串，很容易串错。我的做法是定义一个"编排 skill"，把这条链路固化下来：

export const diagnosePod = ai.defineFlow( { name: 'diagnosePod', inputSchema: z.object({ namespace: z.string(), podName: z.string(), }), outputSchema: z.object({ diagnosis: z.string(), recommendedAction: z.string(), confidence: z.number(), }), }, async (input) => { // 第一步：检查 Pod 健康状态 const health = await checkPodHealth(input); if (health.healthy) { return { diagnosis: 'Pod 健康，无需处理', recommendedAction: 'none', confidence: 0.95, }; } // 第二步：检查日志 const logs = await checkPodLogs({ namespace: input.namespace, podName: input.podName, tailLines: 100, }); // 第三步：根据日志内容判断问题类型 const analysis = await ai.generate({ prompt: `根据以下 Pod 日志判断问题类型： ${logs.content} 可能的类型：配置错误、资源不足、依赖服务不可用、代码 bug。 只返回类型名称。`, }); // 第四步：根据问题类型给出建议 const actionMap = { '配置错误': '检查 ConfigMap 并更新配置', '资源不足': '调整资源限制或扩容', '依赖服务不可用': '检查依赖服务状态', '代码 bug': '回滚到上一个稳定版本', }; return { diagnosis: analysis.text, recommendedAction: actionMap[analysis.text] || '人工介入', confidence: 0.8, }; } );

这个 flow 把诊断链路固化下来了，模型只在"判断问题类型"这一步参与，其他步骤都是确定性的代码逻辑。这样做的好处是，整个诊断过程可控、可复现，不会因为模型的随机性导致诊断结果不稳定。

3.4 部署到 GKE：容器化和资源配置

Skill 定义好之后，最后一步是部署到 GKE。Agent 应用的容器化有几个特殊点需要注意。

首先是 Dockerfile。Agent 应用通常是长时间运行的服务，需要处理并发请求，所以基础镜像要选对：

FROM node:20-slim WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . # Agent 应用通常需要较大的内存 ENV NODE_OPTIONS="--max-old-space-size=3072" EXPOSE 8080 CMD ["node", "dist/server.js"]

NODE_OPTIONS这个环境变量很关键。Agent 应用在处理长上下文时，内存占用会飙升，默认的 Node.js 内存限制经常不够用。3GB 是我实测下来比较稳的配置，再低就容易 OOM。

接下来是 K8s 的 Deployment 配置：

apiVersion: apps/v1 kind: Deployment metadata: name: agent-skills-service spec: replicas: 3 selector: matchLabels: app: agent-skills template: metadata: labels: app: agent-skills spec: containers: - name: agent image: gcr.io/your-project/agent-skills:latest resources: requests: memory: "2Gi" cpu: "500m" limits: memory: "4Gi" cpu: "2000m" env: - name: GOOGLE_CLOUD_PROJECT value: "your-project-id" - name: NODE_ENV value: "production" readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 10

资源限制这块，requests和limits的差距不要设太大。我见过有人把 requests 设成 512Mi、limits 设成 8Gi，结果 Pod 被调度到资源紧张的节点上，运行时频繁 OOM。比较合理的做法是 requests 设为 limits 的 50%-70%。

4. 踩坑实录：Agent Skills 落地过程中最容易翻车的几个地方

4.1 Skill 描述写得太"聪明"，模型反而不会用

这是我踩过的第一个坑，也是最隐蔽的一个。当时我为了让 skill 描述看起来更专业，用了很多行业术语和缩写。比如把"检查 Pod 的健康状态"写成"执行 Pod 健康探针校验"。结果模型经常不调用这个 skill，因为它不理解"探针校验"是什么意思。

后来我把所有 skill 描述都改成大白话，调用率立刻上来了。模型对自然语言的理解是字面意义上的，它不会像人一样根据上下文推断术语的含义。你写"探针校验"，它就真的以为是在检查某种叫"探针"的东西，而不是在检查 Pod 状态。

这个坑的教训是：skill 描述要用最直白的语言，宁可啰嗦也不要简洁。如果一定要用术语，在描述里加一句解释。比如"执行 Pod 健康探针校验（即检查 Pod 是否正常运行）"。

4.2 多个 skill 功能重叠，模型选择困难

第二个坑是 skill 之间的功能边界不清晰。在一个项目里，我定义了三个 skill：getPodStatus、checkPodHealth、inspectPod。这三个 skill 的功能其实高度重叠，都是获取 Pod 信息，只是返回的字段略有不同。结果模型在这三个之间反复横跳，有时候调这个有时候调那个，行为完全不可预测。

解决方法是合并重叠的 skill，或者明确划分边界。我最后的做法是把三个合并成一个getPodInfo，通过参数控制返回哪些信息。这样模型只有一个选择，行为就稳定了。

如果确实需要多个 skill，那就要在描述里明确写出"什么时候用这个、什么时候用那个"。比如：

getPodStatus: 仅获取 Pod 的基本状态（Running/Pending/Failed），用于快速判断。 checkPodHealth: 获取 Pod 的详细健康信息（包括重启次数、最后重启时间），用于深入诊断。

这种明确的边界划分，模型是能理解的。

4.3 忽略了 skill 执行的幂等性

第三个坑比较技术性，但影响很大。Agent 在执行任务时，可能会因为各种原因重试同一个 skill。如果这个 skill 不是幂等的，重试就会导致副作用。

我遇到过一个案例：一个 skill 用于"重启 Pod"，实现方式是先删除 Pod 再让 Deployment 重建。这个操作本身是幂等的，但问题是，如果模型连续调用两次，第二次调用时 Pod 可能正在重建中，删除操作会失败，然后模型会认为"重启失败"，触发告警。

解决方法是在 skill 层面做幂等性保护。具体做法是在执行前检查当前状态，如果状态已经是目标状态，直接返回成功而不执行操作。

async (input) => { const pod = await k8sApi.readNamespacedPod(input.podName, input.namespace); // 如果 Pod 已经在重启中，直接返回 if (pod.metadata.deletionTimestamp) { return { status: 'restarting', message: 'Pod 正在重启中，无需重复操作' }; } // 执行重启 await k8sApi.deleteNamespacedPod(input.podName, input.namespace); return { status: 'restarted', message: 'Pod 已触发重启' }; }

这个检查看起来简单，但能避免大量的误报和重复操作。

4.4 Trace 没开，出问题只能靠猜

第四个坑是调试相关的。Agent 的行为不像传统程序那样有明确的调用栈，它的决策过程是"黑盒"的。如果不开 trace，出了问题你根本不知道模型为什么选了某个 skill、为什么没选另一个。

Genkit 的 trace 功能可以记录每一次模型调用、每一次 skill 执行、每一次决策的输入输出。开启方式很简单，在 configureGenkit 里设置enableTracingAndMetrics: true就行。但要注意，trace 数据量很大，生产环境需要配置采样率，不然存储成本会很高。

我通常的做法是：开发环境 100% 采样，预发环境 50%，生产环境 10%。出问题时可以临时调高采样率，问题解决后再调回去。

4.5 排查链路：一次典型的 skill 误调用

最后分享一个完整的排查案例。有一次，运维 Agent 在流量高峰期错误地触发了一次缩容操作，导致服务短暂不可用。排查过程是这样的：

第一步，查 trace。找到那次缩容操作的 trace，看模型是在什么上下文下决定调用scaleWorkload的。发现触发原因是"检测到 CPU 使用率下降"。

第二步，查 skill 描述。发现scaleWorkload的描述里只写了"调整工作负载副本数"，没有写"流量高峰期禁止缩容"这条约束。

第三步，查上下文。发现模型在决策时，上下文中确实包含了"当前是流量高峰期"的信息，但因为 skill 描述里没有这条约束，模型没有把这个信息用上。

第四步，修复。在 skill 描述里加上"流量高峰期（工作日 9:00-18:00）禁止缩容"这条约束，同时在 handler 里加上硬校验。

第五步，验证。在预发环境模拟流量高峰期场景，确认模型不再触发缩容。

这个案例的教训是：skill 描述里的约束不是装饰，是模型决策的依据。你写了它就会用，不写它就不会用。不要指望模型自己"聪明"到能推断出你没写的约束。

5. 从 Genkit 到生产：性能优化和成本控制

5.1 上下文管理：别让 skill 描述撑爆 token

Skill 描述虽然重要，但也不是越多越好。每个 skill 的描述都会占用上下文 token，skill 数量多了之后，光描述就能占掉几千 token。这不仅增加成本，还会稀释模型的注意力，导致它抓不住重点。

我的做法是分层管理 skill 描述。核心 skill（高频使用、关键路径上的）写详细描述，边缘 skill（低频使用、辅助性的）写简短描述。具体标准是：

• 核心 skill：描述 100-200 字，包含使用场景、约束、输出解读
• 边缘 skill：描述 20-50 字，只写基本功能

另外，如果 skill 数量超过 20 个，建议做动态加载。根据当前上下文只加载相关的 skill，而不是一次性把所有 skill 都塞给模型。Genkit 本身不直接支持动态加载，但可以通过自定义路由逻辑实现。

5.2 模型选择：不是所有 skill 都需要大模型

Agent 的决策过程可以拆成两部分：路由决策（选哪个 skill）和参数生成（skill 的输入参数是什么）。这两部分对模型能力的要求不一样。

路由决策通常比较简单，只需要理解用户意图和 skill 描述，小模型就能胜任。参数生成则可能需要理解复杂的上下文，需要大模型。

我的做法是混合使用：路由用轻量模型（如 Gemini Flash），参数生成用大模型（如 Gemini Pro）。这样能在保证效果的前提下，显著降低成本。

在 Genkit 里，你可以为不同的 generate 调用指定不同的模型：

// 路由决策用轻量模型 const routeDecision = await ai.generate({ model: 'vertexai/gemini-1.5-flash', prompt: `根据用户输入选择合适的 skill：${userInput}`, }); // 参数生成用大模型 const params = await ai.generate({ model: 'vertexai/gemini-1.5-pro', prompt: `根据用户输入生成 skill 参数：${userInput}`, });

实测下来，这种混合方案能降低 40%-60% 的模型调用成本，而效果几乎没有损失。

5.3 缓存：重复的 skill 调用没必要每次都走模型

Agent 在处理相似请求时，经常会做出相同的决策。比如"检查 Pod 健康状态"这个 skill，如果用户连续问了三个 Pod 的状态，模型的路由决策其实是一样的。这种重复决策完全可以缓存。

我的做法是在路由层加一个简单的缓存：把用户输入做归一化处理（去掉具体名称、时间等变量），然后查缓存。如果命中，直接返回上次的 skill 选择。

const cacheKey = normalizeInput(userInput); const cached = await cache.get(cacheKey); if (cached) { return cached; } const decision = await routeDecision(userInput); await cache.set(cacheKey, decision, { ttl: 300 }); return decision;

这个缓存不需要很复杂，一个内存级的 LRU 就够了。关键是归一化逻辑要设计好，既要保证相似输入能命中，又要避免不同输入误命中。

5.4 监控：哪些 skill 在被用，哪些是摆设

上线之后，一定要监控 skill 的使用情况。我见过很多项目，定义了几十个 skill，实际上只有五六个在被调用，其他的要么是描述写得不好模型不会用，要么是场景根本不存在。

监控指标至少包括：

这些指标可以通过 Genkit 的 tracing 数据聚合出来。我通常会在 Grafana 上做一个看板，每周 review 一次。

6. 一些实战中总结出来的经验

6.1 Skill 的粒度：一个 skill 只做一件事

这是最重要的原则。一个 skill 如果做了太多事，模型就很难判断什么时候该用它。比如"检查并修复 Pod 问题"这个 skill，它既检查又修复，模型在只需要检查的时候也会调用它，导致不必要的修复操作。

正确的做法是拆成两个 skill："检查 Pod 问题"和"修复 Pod 问题"。检查是只读的，可以随便调用；修复是有副作用的，需要谨慎调用。拆开之后，模型的行为就清晰多了。

6.2 错误信息要写给模型看，不是写给人看

Skill 执行失败时返回的错误信息，模型是会读的。所以错误信息要写得让模型能理解，并且能指导它下一步该怎么做。

比如，不要写"Error: ENOENT"，要写"Pod 不存在，请检查 Pod 名称是否正确，或先调用 listPods 获取可用 Pod 列表"。后者模型能理解，并且知道下一步该调用 listPods。前者模型只能看到一堆乱码，然后随机重试。

6.3 定期 review skill 描述

Skill 描述不是写完就完了，需要定期 review。因为业务在变，模型的能力也在变，之前写得好的描述可能过一段时间就不适用了。

我的做法是每个月 review 一次所有 skill 的描述，重点看三个地方：一是调用率低的 skill，看是不是描述有问题；二是误调用率高的 skill，看是不是约束不够；三是业务已经变化的 skill，看描述是否需要更新。

6.4 不要过度依赖模型，能固化的逻辑就固化

Agent 的优势是灵活，但灵活也意味着不确定。对于确定性的逻辑，不要交给模型，直接写成代码。比如"如果 Pod 状态是 Failed，就触发告警"这种逻辑，完全没必要让模型判断，直接写 if-else 就行。

模型应该用在真正需要判断力的地方，比如"根据日志内容判断问题类型"这种模糊匹配的场景。把确定性的逻辑固化下来，既能提高可靠性，又能降低成本。

6.5 测试：skill 的测试和普通函数不一样

Skill 的测试不能只测 handler 的逻辑，还要测模型的行为。具体来说，要测三个方面：一是模型在给定输入下是否会选择正确的 skill；二是模型生成的参数是否正确；三是 skill 执行失败时模型是否能正确处理。

前两个测试需要构造大量的输入样本，然后观察模型的选择。这个工作量不小，但很值得。我通常会用历史数据构造测试集，覆盖常见的用户输入模式。

第三个测试相对简单，可以手动构造失败场景，观察模型的行为。重点看模型是否会无限重试、是否会给出合理的错误提示。

7. 后续可以继续深入的方向

Agent Skills 这个领域还在快速演进，有几个方向我觉得值得继续深入。

一个是skill 的自动发现和组合。现在的做法是人工定义 skill，然后人工编排。未来如果能让 Agent 根据任务自动发现需要的 skill 并组合成 flow，那灵活性会大大提升。Google Cloud 的一些新功能已经在往这个方向走了。

另一个是skill 的版本管理和灰度发布。Skill 描述改了之后，模型的行为会变，这本质上是一次"行为变更"。怎么安全地发布这种变更，怎么在出问题时快速回滚，这些都是需要解决的问题。

还有一个是跨 Agent 的 skill 共享。现在每个 Agent 的 skill 都是独立定义的，但其实很多 skill 是通用的（比如"查询数据库""发送通知"）。如果能有一套标准的 skill 注册和发现机制，让不同 Agent 共享 skill，开发效率会高很多。

我在实际项目里已经尝试了一些简单的共享机制，比如把通用 skill 抽成一个独立的包，各个 Agent 引用。但这种方式还是偏手工，不够自动化。期待后续有更成熟的方案出来。

最后说一个我自己的体会：Agent Skills 的核心不是技术，而是设计思维。你要站在模型的角度去想"它在什么情况下需要什么信息、会做什么判断、可能犯什么错"，然后据此设计 skill 的描述和约束。这个思维方式的转变，比学会某个具体 API 重要得多。技术会变，框架会换，但这种"为模型设计"的思维方式是通用的。