如果你最近在和 AI 编程助手、多智能体框架打交道一定感受过一种强烈的反差官方 Demo 里 Agent 像个熟练工真到了自己项目里却总是“左脚绊右脚”——同样的问题第一天踩完坑第二天接着踩。为了解决这个问题行业内近一年给出了一个共同的演进方向把可复用的经验封装成 Skill让 Agent 不用每次从零思考。各类 Skill 仓库、Skill 脚本、Skill 管理插件如雨后春笋般出现Codex Skill、Claude Code Skill、LangGraph Skill 这些词也频繁出现在检索热词里。但谷歌近期被广泛讨论的一篇论文《WikiSkill》在 Skill 热潮之上又补了一个很少被点破的关键问题只生产 Skill 并不够真正决定 Agent 上限的是 Skill 背后的经验有没有被结构化保存以及这些经验能否持续回流到新 Skill 的生成过程中。论文给出的解法是在 Agent 的 Skill 体系旁边增加一个“Wiki 层”像维基百科那样管理 Agent 的过往经验让它成为 Skill 的“事实底座”从而显著提升 Skill 的生成质量和长期效果。这里先说我的判断WikiSkill 不是一个“又一个 Skill 模板库”而是把 Agent 知识管理的核心矛盾从“我有没有这个 Skill”推向了“我这个 Skill 的可信证据是什么”。如果你正在编写 Agent 应用、开发插件或者想在自己的多智能体系统里建立一套可持续发展的技能体系这篇文章会比较值得读。下面我会分三部分来讲先解释 Skill 和 Wiki 层到底解决什么问题再拆解 WikiSkill 的核心流程最后给出你在本地项目里落地一个最小 WikiSkill 方案的完整示例和排错建议。1. 这篇文章真正要解决的问题1.1 为什么 Skill 突然成为 Agent 工程的核心话题早期 Agent 的常见形态是“大模型 一堆系统 Prompt”。这样的做法在简单任务上效果不错一旦任务类型多起来问题就很明显每次执行都要把全部过程重新推理一遍同样的错误会在多个会话里反复出现。比如写一个数据清洗脚本第一次因为没处理空值而报错第二次换了数据源照样会踩同一个坑因为模型并没有记住上一次失败的教训。Skill 的出现就是为了解决这个问题。Skill 在 AI Agent 语境里可以理解为一组可复用的“任务处理经验包”它可能是 Prompt 模板也可能是一个可执行函数还可能是一段与工具结合的工作流。它的核心价值在于把一次成功的解题过程沉淀下来下次遇到同类问题直接调用而不是让模型重新想一遍。这就是为什么过去一年里无论 OpenAI 的 Codex、Anthropic 的 Claude Code还是开源的多智能体框架 LangGraph都把 Skill 作为一等公民。开发者也越来越意识到Agent 的能力不等于模型推理能力而等于“模型推理 可复用技能库”的综合水平。1.2 现有 Skill 管理方式的三类缺陷但 Skill 普及之后新的问题很快暴露出来而且比“没有 Skill”更麻烦。第一只存结果不存经验。很多技能库里放的都是最终版 Prompt 或完成态脚本。它们看起来功能完整但缺失了一个关键信息这个 Skill 为什么被设计成现在这样它试过哪些错误路径它的边界条件是什么没有这些过程信息Skill 就像一个没有病历的患者只看到结论无法判断这个结论在什么条件下成立。第二只存成功不存失败。技能生成通常只保留成功轨迹失败的尝试被直接丢弃。但失败记录恰恰是补充约束条件最重要的素材。一个数据导入 Skill如果只记录“最终成功的方法是先校验再入库”而不记录“没有校验时会把脏数据写进生产库”那么它的稳定性就无从谈起。第三只存孤岛不回流。大多数 Skill 是一次性提炼的。Skill 上架之后它的执行反馈、新失败模式、参数变化不会自动回到知识层去修正原始描述。时间一长Skill 库就像没人维护的内部文档文档还在但里面的描述已经和真实情况脱节了。1.3 WikiSkill 论文给出的答案WikiSkill 的核心思路是把上述三个缺陷用一个“中间层”同时解决。这个中间层就是论文标题里的“Wiki 层”。从材料描述的合理推断来看它的定位非常清晰Wiki 层存储的不是 Skill 本身而是 Skill 背后的经验条目Skill 只是这些经验条目在特定任务上的可执行投影。换句话说论文认为当我们说“显著提升 Skill 效果”时提升的根源不是生成算法的改变而是因为技能生成前有了可检索、可校验、可追溯的经验底座。模型不再凭空发明一个 Skill而是基于 Wiki 层里的真实案例、失败教训和验证记录去生产 Skill。这听起来像把知识库和技能库拼接在一起但 Wiki 层在论文里承担的角色要重要得多——它是整个 Agent 知识系统的“登记簿”也是技能质量的“裁判所”。2. 从一次任务到一条技能先理解 Agent Skill 的基本形态2.1 Skill 的最小定义要理解 WikiSkill先要把 Skill 本身拆开。一个标准 Skill 至少包含四部分触发条件什么情况下使用它通常是一个语义描述比如“当用户要求生成 API 测试代码时”。可执行内容Prompt 模板、代码脚本或工具调用流程。参数与约束输入输出格式、环境要求、资源限制。验收标准怎样算执行成功通常结合一组测试样例。很多开发者在初期会把 Skill 等同于“一段 Prompt”。这个理解不完全错但在生产环境很容易出问题。因为 Prompt 只能约束模型的文本行为如果 Skill 需要调用外部工具、处理结构化数据、执行脚本就必须有更严密的定义。2.2 目前最常见的两种 Skill 编码方式第一种是自然语言说明书型。比如 Claude Code 里常见的 SKILL.md用 Markdown 文件描述技能的使用方法、注意事项、示例。它的优点是易读、易维护人可以直接审查缺点是执行时容易出现歧义模型解读不稳定对复杂任务尤其明显。第二种是结构化代码型。用 Python、TypeScript 或 JSON 描述技能逻辑参数、工具、步骤都是显式声明的。它的优点是精确、可测试、可复用缺点是开发成本高非程序员很难参与而且一旦程序逻辑过重Agent 的灵活性会下降。在实际工程项目里更合理的做法是“说明书 代码”混合用结构化声明定义接口和触发条件用自然语言补充推理策略和经验边界。这种形态在 WikiSkill 的论调下特别重要因为 Wiki 层最终要服务的正是这样一个结构清晰的 Skill 体系。2.3 判断 Skill 质量的三条标准很多团队在积累 Skill 时都会问一个问题“到底什么样的 Skill 算好”我的答案是三条标准缺一不可。第一能稳定触发。同一个任务跑十次至少八九次能正确命中这个 Skill而不是偶尔想起来偶尔想不起来。这是检索层面的要求。第二能安全组合。Skill 不是独立存在的它往往要和其他 Skill 或工具一起工作。比如“生成测试代码”这个 Skill可能需要“读取项目结构”“运行 pytest”“解析错误日志”三个 Skill 协作。两个 Skill 之间不能有相互冲突的隐含假设。第三能容忍环境变化。如果依赖固定目录、固定版本、固定文件结构那么环境一变Skill 就废了。好的 Skill 会把环境差异抽象成参数把默认逻辑和边界条件分开处理。3. WikiSkill 论文核心思想为什么需要“Wiki 层”3.1 一个来自生产环境的类比解释 Wiki 层之前先用一个接近开发者的例子说明。假设一个团队里来了新成员他的任务是写数据库迁移脚本。第一次他犯了个错把攻击性操作直接执行在了生产库上。第二次他学聪明了先在临时库验证。第三次他遇到了新表结构又踩了坑花半天时间搞明白“外键依赖需要先锁表”。如果这个团队只有一个技能库那他最多往里塞一条“写迁移脚本步骤”。但这条技能对新员工的价值有限因为后面还会遇到各种新情况。而如果团队把他这段经历写进一份“Wiki 经验页”记录操作步骤、错误案例、验证后的最佳实践那么下一个人遇到类似问题时既能查到方法论又能看到真实失败案例中的约束条件踩坑概率会低很多。WikiSkill 论文里的 Wiki 层本质上就是把“团队经验 Wiki”搬到了 Agent 系统内部。它不是一个放 Skill 的仓库而是一个放“Agent 经验”的条目库。Skill 是从条目库中提炼出来的可执行产物。3.2 Wiki 层的定位与核心机制Wiki 层需要解决的问题可以拆成四个方面。第一个方面是经验登记。Agent 在一次任务执行后无论成功还是失败都会产出一条经验记录。论文会把这些原始信息转换为结构化的 Wiki 条目。原始记录是执行日志Wiki 条目则是经过提炼的信息单元类似把流水账改写成案例摘要。第二个方面是检索匹配。当 Agent 收到新任务时不会直接在整个学习空间里做一次无差别搜索而是先在 Wiki 层里查询与当前任务语义相近的经验条目。检索结果会以“参考上下文”的形式输入到生成链路中。这一步决定了技能生成是否存在“盲目生成”。第三个方面是技能合成。拿到 Wiki 条目后Agent通常由一个专门的生成器承担开始把经验条目转化为 Skill。注意这里的生成不是从空白开始而是基于 Wiki 条目已经总结好的触发条件、执行步骤、失败模式、验证结果来写技能内容。这样一来生成的技能天然具备“经验依据”。第四个方面是反馈回流。Skill 实际执行后产生的新结果会再次更新 Wiki 层。成功时就强化原条目失败时就新增一条失败模式。这形成了一个持续运转的闭环Wiki 层的条目随着 Agent 的持续使用不断进化。我目前主要根据论文的公开描述和讨论来梳理这套流程一些内部模块命名可能与原文不完全一致但整体结构对理解主流程已经足够。3.3 为什么“Wiki 层”能显著提升 Skill 效果这里有一个值得展开的机制解释传统 Agent 一次任务完成后生成的 Skill本质上是“单样本提炼”。它是基于一条轨迹总结出来的泛化能力有限。假如这次任务的数据刚好比较特殊提炼出的 Skill 就容易被带偏。而 Wiki 层提供的是“多样本融合”。同一个任务类型可能在 Wiki 层里有十条经验条目有的来自成功案例有的来自失败案例有的来自不同数据集。生成 Skill 时这些条目共同参与判断得出的结论就不是凭单一案例拍脑袋而是经过多条证据交叉验证的。这就很容易解释“显著提升效果”的来源技能的命中率更高生成的逻辑更稳定遇到新场景时的适配能力也更强。更关键的是由于 Wiki 条目是可读的文本结构开发者可以直接审查一条 Skill 背后引用了哪些经验不信的话可以直接回溯原始记录。这一点对生产环境非常重要——AI 生成的东西如果完全不可审计很难让人放心上线。4. 核心流程拆解从原始经验到可用 Skill详细拆开 WikiSkill 的流程可以分成四个阶段。每个阶段都有输入、处理和输出也都有各自的工程关注点。4.1 阶段一原始轨迹沉淀输入是 Agent 的完整执行记录包括用户指令、推理过程、工具调用、返回结果、最终答案。这里的重点是全量保存尤其是失败的试错路径。很多团队只保存成功轨迹理由是“失败的一次没有价值”。但在 WikiSkill 的思路下失败轨迹的价值一点不比成功轨迹低。它至少能提供两类信息一是边界条件——说明什么问题在什么情况下会出错二是纠错信号——说明什么手段不能解决这个问题避免后续的 Agent 重蹈覆辙。工程上这个阶段只需要做到一件事为每次任务执行生成一份统一格式的日志并落盘到经验存储区。日志结构可以设计为{ session_id: session_20250226_001, timestamp: 2025-02-26T10:00:00Z, task_id: task_create_dag, user_request: 生成一个 Airflow DAG每小时同步 PostgreSQL 数据到 HDFS, model_family: gpt-4o, trajectory: [ {step: parse_request, action: read_user_input, result: ok}, {step: inspect_sources, action: read_project_files, result: ok}, {step: init_dag, action: write_python_script, result: failed}, {step: fix_dependency, action: update_python_script, result: ok} ], final_status: success, outcome_notes: 第一次失败是因为 task_id 参数名不一致修正后成功 }4.2 阶段二经验结构化原始轨迹的格式适合机器读取但不适合作为生成 Skill 的参考。下一步就是把它转换成 Wiki 条目。Wiki 条目的典型字段大致如下entry_id唯一标识。task_type任务类型。trigger_condition什么情况下该经验可用。context环境、数据形态、限制条件。verified_steps验证过的可行步骤。failed_patterns历史上出现过的失败模式。upstream_skills与该经验相关的既有 Skill。quality_score当前条目的可信度评分。这一步的价值在于它把“发生了什么事”转换成了“什么条件下该怎么做什么条件下不该怎么做”为后面的技能生成扫清了障碍。4.3 阶段三技能合成与验证得到 Wiki 条目后生成器会按需拉取相关条目生成 Skill 草稿。这里需要注意生成的不是最终版而是候选版。候选 Skill 必须经过验证器检验。验证的方式通常有两种。一种是用一组覆盖不同输入条件的测试用例检查 Skill 在不同数据下能否得到预期结果另一种是把这个 Skill 放到一个独立的模拟任务环境里观察它在真实执行链路上的表现。只有通过验证的 Skill 才能进入生产目录。论文里对这一步的强调其实暗含一个判断如果没有验证闭环那么 Wiki 层和普通知识库没有本质区别有了验证闭环Wiki 层才能成为一个“可信经验来源”。4.4 阶段四执行反馈回流这是整套机制最容易忽略、也最重要的一环。Skill 上线后在真实任务中被反复使用。每一次真实执行的反馈都应该更新到关联的 Wiki 条目中。如果 Skill 执行平稳就为条目增加一条正向证据提升质量分数如果 Skill 在某个新情况下跌跌撞撞甚至失败就增加一条失败模式并考虑是否触发新一轮的 Skill 修正。这样形成的闭环是经验 → Wiki → Skill → 执行结果 → 再回流到 Wiki。整个过程不需要人工频繁介入系统自身就能保持知识的持续更新。这才是论文中“显著提升 Skill 效果”能够长期维持的原因。5. WikiSkill 与其他 Skill 知识管理方案的对比很多开发者会问我已经有了向量知识库或者已经有了 Skill 仓库还需要 Wiki 层吗先明确一点这些方案并不是严格互斥的。向量知识库擅长的语义检索Skill 仓库擅长可执行单元的管理而 Wiki 层擅长的是“经验的可解释沉淀和回环校验”。它们所处的层次不同解决的问题不同。我用一张表来说明它们的差异。能力维度传统 Skill 目录向量知识库Wiki 层方案保存内容可执行的 Prompt / 脚本高维向量结构化、可读、可追溯的经验条目更新方式人工编写或单次提炼批量索引人工 Agent 持续写回检索方式标签匹配语义相似度语义 上下文 规则混合可解释性弱弱强具备文档级别的可审查性对生成 Skill 的帮助直接复用提供参考上下文既能检索又能校验还能溯源长期过期风险高中低反馈会持续纠正条目从这张表能看出 Wiki 层的独特价值。它不是替代向量库也不是替代 Skill 目录而是作为两者之间的一层“经验治理结构”。如果把 Skill 目录看作“编译后的产物”把向量知识库看作“候选信息池”那么 Wiki 层就是“经过验证和登记的经验数据库”。另外近期讨论度很高的 Codex Skill、Claude Agent Skills、LangGraph 等框架其实和 WikiSkill 都不冲突。它们解决的是“技能如何定义、如何调用、如何编排”的问题而 WikiSkill 解决的是“技能的经验来源从哪来、如何维护”的问题。一个好的 Agent 工程通常需要两者同时存在。6. 在本地项目中落地一个最小 WikiSkill 方案思路清楚了动手验证才踏实。下面我会用最小可运行的方式在本地实现一个简化版 WikiSkill 闭环。它不依赖任何大模型服务只需要 Python 3.10 和标准库。核心目的是帮助理解层次关系。我们先定义目录结构wikiskill_demo/ ├── wiki/ # Wiki 层 │ └── entries.jsonl # 经验条目 ├── skills/ # Skill 目录 │ └── registry.json # Skill 注册表 ├── logs/ # 原始轨迹落盘 ├── wiki_layer.py # Wiki 层核心操作 ├── skill_builder.py # 基于经验生成 Skill ├── executor.py # 模拟执行器 └── run_example.py # 端到端示例6.1 Wiki 层核心模块wiki_layer.py负责经验条目的写入、查询和更新。import json WIKI_FILE wiki/entries.jsonl class WikiLayer: def __init__(self, wiki_file: str WIKI_FILE): self.wiki_file wiki_file self.entries self._load() def _load(self) - list[dict]: try: with open(self.wiki_file, r, encodingutf-8) as f: return [json.loads(line) for line in f if line.strip()] except FileNotFoundError: return [] def _save(self): with open(self.wiki_file, w, encodingutf-8) as f: for entry in self.entries: f.write(json.dumps(entry, ensure_asciiFalse) \n) def register_experience(self, task_type: str, trigger: str, verified_steps: list[str], failed_patterns: list[str], context: str | None None, predecessor_skill: str | None None) - str: 把一次任务执行沉淀为 Wiki 条目 entry_id fwiki-{len(self.entries) 1:04d} entry { entry_id: entry_id, task_type: task_type, trigger_condition: trigger, context: context or {}, verified_steps: verified_steps, failed_patterns: failed_patterns, predecessor_skill: predecessor_skill, quality_score: 0.8, execute_count: 0, } self.entries.append(entry) self._save() return entry_id def search(self, task_type: str, top_k: int 3) - list[dict]: 按任务类型查询最相关的经验条目 candidates [e for e in self.entries if task_type in e[task_type]] candidates.sort(keylambda e: e[quality_score], reverseTrue) return candidates[:top_k] def feedback(self, entry_id: str, success: bool, note: str ): 执行反馈写回 Wiki 层 for entry in self.entries: if entry[entry_id] entry_id: entry[execute_count] 1 if success: entry[quality_score] min(1.0, entry[quality_score] 0.02) else: entry[quality_score] max(0.1, entry[quality_score] - 0.05) entry[failed_patterns].append(note) self._save() return raise KeyError(entry_id)这里的关键点有两个register_experience是把单次执行轨迹浓缩成 Wiki 条目的实现。真实项目里这一步可以由 LLM 完成把复杂的轨迹转成简洁的描述。当前示例只保存结构化信息已足够演示流程。search采用了最简单的字符串匹配。真实项目里应该替换为向量检索或混合检索这样语义相近但关键词不同的经验才能被召回。6.2 Skill 构建模块skill_builder.py负责根据 Wiki 条目生成 Skill 注册项。在真实系统中候选技能由 LLM 生成这里我用一个确定性的模板模拟。import json SKILL_REGISTRY skills/registry.json def build_skill_from_wiki(wiki_entry: dict) - dict: 根据 Wiki 条目生成 Skill 注册数据 skill_id fskill-{wiki_entry[entry_id].split(-)[-1]} skill { skill_id: skill_id, name: fexecute_{wiki_entry[task_type]}, trigger: wiki_entry[trigger_condition], steps: wiki_entry[verified_steps], guardrails: [ f若出现以下情况不要直接执行{p} for p in wiki_entry[failed_patterns] ], source_wiki: wiki_entry[entry_id], version: 1, status: candidate, } return skill def save_skill(skill: dict): try: with open(SKILL_REGISTRY, r, encodingutf-8) as f: registry json.load(f) except FileNotFoundError: registry [] # 如果同源技能已存在则进入候选状态等待验证 registry [s for s in registry if s.get(source_wiki) ! skill[source_wiki]] registry.append(skill) with open(SKILL_REGISTRY, w, encodingutf-8) as f: json.dump(registry, f, ensure_asciiFalse, indent2) return skill6.3 执行器与端到端示例executor.py模拟一个执行 Agent。它接收任务类型和任务描述先从 Wiki 层检索经验再尝试按经验步骤执行。class Executor: def __init__(self, wiki: WikiLayer): self.wiki wiki def execute(self, task_type: str) - dict: related_entries self.wiki.search(task_type) if not related_entries: return {status: not_found, message: Wiki 层没有相关经验需要探索} entry related_entries[0] steps entry[verified_steps] # 这里简化执行能查到经验就视为执行成功 # 真实项目中应调用工具链并采集返回值 self.wiki.feedback(entry[entry_id], successTrue) return { status: success, used_entry: entry[entry_id], used_steps: steps, }最后是run_example.py演示完整闭环。from wiki_layer import WikiLayer from skill_builder import build_skill_from_wiki, save_skill from executor import Executor wiki WikiLayer() # 第一步模拟一次任务执行后把成功经验写入 Wiki 层 entry_id wiki.register_experience( task_typecreate_api_tests, trigger当用户要求为新写的 FastAPI 接口生成 pytest 测试时, verified_steps[ 读取接口路由定义和请求模型, 识别需要 mock 的外部服务, 生成 pytest 测试文件, 运行测试并修正断言, ], failed_patterns[ 未 mock 外部服务时测试会真实发请求耗时且不稳定, 断言硬编码了真实时间值导致时间变更后测试失败, ], context{framework: FastAPI, test_runner: pytest}, ) # 第二步基于 Wiki 条目构建 Skill 候选 skill build_skill_from_wiki(wiki.entries[-1]) save_skill(skill) # 第三步模拟用户再次提出同类需求Agent 先查询 Wiki 层 executor Executor(wiki) result executor.execute(create_api_tests) print(result)运行方式cd wikiskill_demo python run_example.py预期输出类似{status: success, used_entry: wiki-0001, used_steps: [读取接口路由定义和请求模型, 识别需要 mock 的外部服务, 生成 pytest 测试文件, 运行测试并修正断言]}这个最小示例虽然简单但已经具备 WikiSkill 闭环的全部核心动作经验写入、Wiki 检索、Skill 构建、执行反馈。真实落地时只需要把三个地方替换为生产级组件用 LLM 替代人工经验精简用向量库替代字符串搜索用真实工具链替代模拟执行。6.4 Skill 声明文件示例如果要在 Claude Code 或类似支持 Skill 声明文件的环境中使用还需要生成一个可读的 Markdown 或 JSON 描述文件。下面的 JSON 展示了一个 Skill 声明标准结构。{ schema_version: 1.0, skill_id: skill-0001, name: create_api_tests, description: 为 FastAPI 接口生成 pytest 测试, trigger_examples: [ 给这个接口写测试, 生成 pytest 测试用例, 为 API 补测试 ], dependencies: [], steps: [ 读取接口路由定义和请求模型, 识别需要 mock 的外部服务, 生成 pytest 测试文件, 运行测试并修正断言 ], guardrails: [ 必须 mock 外部服务禁止真实调用, 断言时间不能硬编码 ], source_wiki_entry: wiki-0001 }这个文件的价值在于它会随 Skill 一起进入版本管理。后续任何人看到这个 Skill都能基于source_wiki_entry找到原始经验条目实现可审计。7. 常见问题与排查思路WikiSkill 听起来很美但落地时有很多细节容易被忽略。下面是几个我在实际咨询和开发中常见的问题整理成排查表。问题现象可能原因排查方式解决方案Skill 总是无法触发Wiki 条目的触发条件描述太窄或检索方式单一检查检索日志看看查询命中了什么扩充触发条件同义词升级为向量检索Skill 在部分场景下结果不稳定生成 Skill 时只引用了单条 Wiki 条目检查source_wiki字段的引用数生成时强制引用至少 2-3 条相关经验Wiki 条目越攒越多质量下降缺少去重和校验机制统计相似条目比例建立条目去重流程定期合并同类项Agent 执行时上下文过大一次性把太多 Wiki 条目注入 Prompt查看发送给模型的上下文长度限定检索条数和摘要长度失败经验写入后导致 Skill 变得保守失败模式过度泛化Agent 不敢执行查看 guardrails 的规则强度给失败模式加“条件标签”只在相同条件下生效反馈回流没有生效没有把 Skill 执行结果关联回 Wiki 条目检查执行日志和 Wiki 的 exec_id 关联在执行链路中强制写入反馈事件多人协作时 Wiki 冲突频繁缺少条目所有权和变更审批查看条目操作历史引入分级更新机制重要条目需要评审其中最容易出问题的是“失败经验过度泛化”。很多 Agent 在某个项目里因为外部服务不可用而失败就把“禁止调用外部服务”写进 Skill 的约束里。这个结论在当时的场景下是对的但放到其他项目中就成了错误约束。Wiki 层解决这个问题的方法是给失败经验增加上下文标签比如“外部服务不可用2025-01 生产环境”而不是直接写一条无上下文的规则。8. 工程实践与工程建议如果你准备在自己的项目里落地 WikiSkill 思路下面几条建议值得提前考虑。8.1 先在“任务日志”上建立闭环再考虑算法很多人一上来就想把 Wiki 检索做成高精度的向量召回结果折腾了两周连最基础的经验回流都没有。我更推荐的做法是先确保每个 Agent 任务都能生成结构化日志再基于日志做简单的规则匹配。闭环跑通之后再逐步引入 embedding、聚类、验证器等更复杂的组件。8.2 Skill 必须是“经验的可执行投影”写 Skill 时不要从零编写而是先从 Wikipedia 条目中搜索相关经验再基于经验生成。这条原则是 WikiSkill 的核心也是很多人容易忽略的地方。如果你发现自己写 Skill 时完全没参考任何历史经验那和写一段普通的自动化脚本没什么区别算不上真正的 Skill。8.3 重视失败模式的分类失败模式不要写成一条笼统的“不要这样做”而是分成四类资源不可用、数据格式不符、边界条件缺失、业务规则理解错误。不同类型对应不同的处理策略有的需要在 Skill 里增加前置校验有的需要修改执行顺序有的需要回退给用户确认。分类越细后续触发规则就越准确。8.4 建立 Skill 的版本与回滚机制Skill 也是一种代码资产。每次更新都要触发版本号递增并在注册表中保留旧版本。当一个新版本在实际执行中效果下降时可以快速回滚。Wiki 层的条目同样需要版本管理但它的版本不用太频繁只要保证“可追溯”即可。8.5 小团队从单任务类型开始如果是一个三五人的小团队想验证 WikiSkill 是否适合自己可以从一个任务类型开始。比如只处理“日志分析”或“代码审查”这一种任务跑通“日志 → Wiki → Skill → 执行 → 反馈”的闭环观察效果再扩大范围。平台化设计容易陷入过度设计单点闭环反而是检验思路最好的方式。9. 总结与后续学习方向WikiSkill 这篇论文最值得学习的不是某一个具体的模块而是它把 Agent 技能开发从“凭感觉写 Skill”变成了“基于经验治理生产 Skill”。过去我们认为 Skill 是一次性的产出现在更合理的理解是Skill 是 Wiki 层长期演化的副产品经验库越丰富Skill 越稳定。如果你想继续深入建议按三个方向走。第一个方向是检索机制优化。试着把 Wiki 层的字符串匹配替换为向量检索再用 Rerank 模型提升召回精度。这是提升体验最直接的手段。第二个方向是验证器设计。现在的 Skill 验证大多靠人工或简单测试用例论文里更合理的做法是设计一个独立的验证器用一组基准任务持续评估 Skill 的稳定性。你可以研究如何为不同任务类型构建自动化评估集。第三个方向是多 Agent 知识协同。在一个多智能体系统里不同 Agent 产生的经验如何合并、冲突如何消解、权限如何控制这些都是 Wiki 层需要回答的问题。这一块工程复杂度最高但收益也最大。最后给你一个可以马上动手的路径打开你手头 Agent 项目的代码先加一个experiences/目录把每次任务执行的关键结果和失败原因落盘再写一个十行的查询函数。别小看这一步你已经建立起“经验层”的雏形了。剩下的就是在它之上不断长成真正的 Wiki 层。