背景
ima 是腾讯推出的 AI 知识管家，以知识库为基础提供"搜、读、写"一站式体验，支持网页、PDF、Office、Markdown 等 19 种格式的资料入库。2026 年 3 月，ima 上线 Skills 功能：一个官方接入包（OpenAPI + 本地技能配置），让 OpenClaw、WorkBuddy、QClaw 等 Agent 通过 API Key 直接操作知识库与笔记，包括检索资料、导入文档、整理笔记等。
在此基础上，Agent 还可以接入红狐 hub 这类 AI 技能基础设施平台------其 Skills 广场提供上百个数据与内容类 Skill，安装后即可实时拉取微博评论、公众号爆款、小红书榜单等外部数据源。
本文聚焦一个工程问题：如何让一个 Skill 在真实任务反馈中持续进化，而不是反复手改 prompt？ 核心答案是三层结构 + 反馈驱动 + 版本验证。
ima Skills 的接入方式并不复杂：在 ima 客户端完成 Claw 配置后，获取 API Key 写入 Agent 环境变量，即可通过 OpenAPI 调用知识库检索、文档导入等接口。对于开发者而言，真正值得投入的环节不在接入，而在 Skill 本身的迭代治理------这也是本文想展开的部分。
一、Skill 的三层结构
一个 Skill 是目录形式的可版本化能力包，核心入口为 SKILL.md。按 Agent Skills 设计，分为三层：
| 层级 | 内容 | 作用 |
|---|---|---|
| 路由层 | name、description、path | 帮助 Agent 判断任务是否匹配，轻量发现 |
| 指令层 | SKILL.md 正文：Workflow、判断标准、输出约束 | 任务流程与决策逻辑 |
| 资源层 | references/、assets/、scripts/ | 详细文档、样例、模板、可执行代码 |
对应渐进式加载机制：Agent 启动时仅见路由层元信息 → 任务匹配后加载 SKILL.md → 执行中按需读取资源。多 Skill 并存时上下文保持轻量。
这个设计的工程收益是显性的：路由层只有几十 token，Agent 可以同时挂载几十上百个 Skill 而不会撑爆上下文；指令层在任务匹配时才进入上下文，避免无关指令干扰当前推理；资源层按需加载，把高频路径（日常任务）与低频路径（细分场景）分开，整体 token 开销随 Skill 数量近似线性增长而非爆炸式增长。
二、自进化机制：反馈 → 规则 → 写入 → 验证
核心流程四步：
- 记录轨迹：用户原始需求、Agent 初版方案、修改意见、最终采纳版本、结果评价，全部记入任务轨迹。
- 抽象规则：优化器把一次性表达抽象为稳定规则（如"第三天太赶"→"轻松偏好每天 2-3 个停靠点"）。
- 写入正确层级：触发边界问题改路由层 description；流程问题改指令层 Workflow；质量判断新增 Quality checks；细分场景下沉 references/。
- 验证发布：新旧版本对历史任务批量评测，指标更优才发布新版本；过度保守则拒绝并记为负反馈。
任务轨迹是规则抽象的原料，建议结构化记录：
json
{
"task_id": "t-1024",
"user_request": "去京都玩三天，喜欢寺庙、咖啡店，轻松一点",
"draft": "Day 3: 金阁寺、岚山、竹林小径",
"user_feedback": "第三天太赶了，不想频繁换乘，餐厅最好顺路",
"final_accepted": "Day 3: 岚山竹林小径、天龙寺、渡月桥周边",
"rating": "good"
}有了轨迹之后，为什么必须抽象成规则、而不是直接改 prompt？因为一次性表达只对当前任务生效：用户这次说"太赶"，下次可能换一个说法（"节奏太密""走路太多"）。抽象后的规则覆盖的是一类表达，而不是一句话------这正是 Skill 与单次 prompt 的本质区别：prompt 改的是措辞，规则改的是行为。
每一次进化必须回答三个问题：改了哪一层、解决什么问题、用什么结果证明它更好。
三、实战：travel-planner skill 迭代全过程
3.1 v1.0 初始版本
markdown
---
name: travel-planner
description: 基于目的地、日期和偏好，规划多日旅行行程。
---
## Workflow
1. 收集目的地、日期、预算和旅行偏好。
2. 搜索景点、餐厅和交通方式（检索 ima 知识库中的攻略资料）。
3. 按天安排景点。
4. 生成逐日行程。
## Output
每天一个章节。包含景点、美食推荐和交通说明。v1.0 可以生成行程，但存在典型缺陷：景点按天罗列，未考虑区域与交通；用户"轻松一点"的偏好未进入安排。
3.2 反馈抽象为规则
用户反馈："第三天太赶了，我不想频繁换乘，餐厅最好顺路一点。"
抽象结果：
| 用户原话 | 稳定规则 |
|---|---|
| 第三天太赶了 | 轻松偏好下每天 2-3 个主要停靠点，保留缓冲时间 |
| 不想频繁换乘 | 优先同区域景点组合，减少跨区域移动 |
| 餐厅最好顺路 | 餐厅和休息点尽量靠近当天路线 |
3.3 v1.1：修改指令层 Workflow
markdown
## Workflow
1. 收集目的地、日期、预算和旅行偏好。
2. 搜索景点、餐厅和交通方式（检索 ima 知识库中的攻略资料）。
3. 在分配进每天之前，先按地理区域对候选地点做聚类。
4. 估算主要停靠点之间的交通时间。
5. 按用户的节奏偏好匹配每天的密度：
- relaxed: 每天 2-3 个主要停靠点，保留缓冲时间
- standard: 每天 3-4 个主要停靠点
- packed: 每天 4-6 个主要停靠点核心变化：从"景点罗列"变为"区域聚类 → 交通估算 → 密度匹配"三段式流程。
3.4 v1.1：新增 Quality checks
markdown
## Quality checks
在确定行程之前，检查：
- 每天是否基本停留在同一个地理区域内。
- 主要停靠点之间的交通时间是否合理。
- 主要停靠点的数量是否匹配用户的节奏偏好。
- 餐厅和休息点是否安排在路线附近。质量判断标准进入指令层，Agent 输出前自查，而非事后返工。
3.5 v1.2：细分场景下沉资源层
新增 references/family-travel-constraints.md，承载亲子/长辈出行约束（减少换乘、控制步行距离、安排午休等），主 SKILL.md 仅保留触发说明：
markdown
如果用户提到儿童、长辈、婴儿车或行动不便，在确定行程前先读取
references/family-travel-constraints.md。主文件保持轻量，细分规则按需加载。
3.6 定期 compaction：压缩与重构
markdown
# 压缩前（散规则）
- 不要把距离很远的景点放在同一天
- 每天要控制景点数量
- 轻松旅行要留休息时间
- 餐厅要靠近当天路线
- 亲子旅行要减少换乘
# 压缩后（合并为质量标准）
优先保证路线连贯与节奏匹配：每天在地理上保持连贯，按节奏限制主要停靠点数量，
餐厅和休息点靠近路线，亲子行程减少换乘。compaction 检查三类问题：规则重复、长期未触发、应下沉 references 的细节。
3.7 验证决定发布
取一批历史任务，v1.0 与 v1.1 并行生成，对比指标：
-
每天跨区域移动次数是否下降
-
平均交通时间是否减少
-
用户偏好是否被显式满足
-
行程密度是否符合预期
指标更优 → 发布 v1.1；过度保守导致行程内容过少 → 拒绝本次修改，记录为负反馈。
验证环节的伪代码示意：
python
def evaluate(version, history_tasks):
score = 0
for task in history_tasks:
plan = version.generate(task)
score += (
plan.cross_region_moves * 0.3 # 跨区移动次数越低越好
+ plan.avg_transit_time * 0.3 # 平均交通时间越低越好
+ (0 if task.preference_satisfied(plan) else 1) * 0.2
+ density_penalty(plan, task.pace) * 0.2
)
return score
v1_0_score = evaluate(v1_0, history)
v1_1_score = evaluate(v1_1, history)
release = v1_1_score < v1_0_score # 分数越低越好两个常见陷阱：一是拿单次成功案例就发布，样本不足导致过度拟合；二是只关注"变好"的指标，忽略"过度保守"（如每天只排 1 个景点）带来的体验下降。评测必须同时盯住两个方向。
四、踩坑与注意事项
- 反馈写错层级：把细分场景规则硬塞进主 SKILL.md，会导致主文件膨胀、上下文开销上升。细分场景一律下沉 references/。
- 只加不减：迭代多了不 compaction，规则互相矛盾时 Agent 行为漂移。定期压缩、合并、删除是必需操作。
- 验证只看单例：拿一两次成功案例就发布新版本，容易过度拟合。用批量历史任务评测，兼顾"更优"与"不过度保守"。
- 忽略触发边界：路由层 description 不更新，新场景下 Agent 可能根本不调用该 Skill，后续所有迭代都白费。
五、真实案例参考：红狐「微博评论分析」Skill
以红狐 hub 上的「微博评论分析」Skill为样本，观察三层结构的工业级落地：
| 层级 | 实现 | 工程要点 |
|---|---|---|
| 路由层 | name + description | 用户丢来微博链接、需要评论区数据时触发 |
| 指令层 | SKILL.md 任务流程 | 解析链接 → 查询评论 → 排序 → 输出带时间戳的评论列表 |
| 资源层 | 数据管道 + 分页接口 | 实时拉取、身份溯源（昵称跳主页）、翻页浏览 |
该 Skill 累计 1 万多次调用，其"数据新鲜、身份可溯源、翻页浏览"三项能力正是反馈积累成规则的产物------做舆情怕过期存档，于是每条评论带时间戳；有价值评论不在前 20 条，于是支持翻页。
回到 ima 场景：把这类数据型 Skill 与 ima 知识库组合，就形成了"外部数据实时入库 + 库内资料检索 + Agent 输出"的完整链路------例如运营团队让 Agent 每日拉取爆款榜单存入 ima 知识库，再基于库内历史数据生成选题建议。反馈驱动进化的对象，也从单个 Skill 扩展到了整个知识工作流。
总结
Skill 自进化的工程要点可归纳为：
- 三层结构（路由/指令/资源）是进化的坐标系------任何反馈先定位层级再修改。
- 反馈必须抽象成规则，一次性表达不落地。
- 每次进化回答三个问题：改哪层、解决什么、如何证明。
- 定期 compaction 保持 Skill 清晰轻量。
- 验证通过才发布，拒绝过度保守的修改并记录负反馈。
长期来看，Agent 能力提升从"单次 prompt 调整"走向"持续运营 Skills"：模型提供通用推理，ima 知识库提供资料底座，红狐这类平台提供数据管道，Skills 承载可复用程序性知识，最终形成可版本管理、可评估、可回滚、可复用的能力体系。
资料来源
-
「微博评论分析」Skill 官方页面：https://redfox.hk/skills/no/hD2X5aT9?source=csdn
-
红狐 hub Skills 广场：https://redfox.hk/skills?source=csdn