企业官网建设流程全解析

这次我们来看一个在智能体开发圈突然火起来的方法——WikiSkill。它来自一篇被很多开发者转发的论文，核心思路一句话能说清：把 Agent 每次执行任务获得的经验，沉淀到一个可检索、可复用的“Wiki 层”，让 Skill 越用越强，而不是每次从零开始。

如果你平时用 Claude Code、Codex 这类编程 Agent，或者正在做 Agent 工作流、研究智能体自我进化，那 WikiSkill 这个方向值得你花 20 分钟看完这篇文章。我会先把它的核心机制拆开讲清楚，然后给出一套可落地的本地复现思路，包括怎么设计 Wiki 层、怎么测效果、怎么接入现有 Agent 流程，以及最容易踩的坑。

先说结论：这篇论文的价值不在“又发明了一个新模型”，而在于它把经验管理这件事从“提示词工程”提升到了“系统设计”的层面。它解决的不是 Agent 能不能干活的问题，而是Agent 能不能越干越好的问题。下面进入正文。

1. 核心能力速览

从材料看，WikiSkill 的核心贡献是在传统 Skill 层之上加了一层更容易检索、更结构化的“Wiki”记忆层。它和普通“给 Agent 一个经验文档”的区别在于：Wiki 层不是人写的静态文档，而是 Agent 执行完任务后自动提取、自动更新、按需检索的动态经验库。

2. 为什么“Wiki 层”是这次的关键

要理解 WikiSkill 的价值，得先理解当前 Agent 开发的一个痛点。

现在很多人用 Claude Code、Codex 这类工具，已经开始积累 Skill。所谓 Skill，可以理解为一段结构化的指令或脚本，告诉 Agent“遇到某类任务时，按什么步骤做”。比如一个“写 Python 单元测试”的 Skill，规定了测试框架、命名规则、断言风格。这确实比每次重新描述需求高效，但有一个明显天花板：Skill 本身不会自主进化。

遇到一个新任务，Agent 执行完后可能积累了新的经验，比如“这个仓库里的测试需要先启动 mock 服务”，但 Skill 里没有记录。下次执行同类任务时，Agent 大概率会重复踩坑。做 Agent 开发的朋友应该深有体会——如果 Skill 不带记忆，那 Agent 的“进化”就无从谈起。

WikiSkill 的做法是在 Skill 之上加一个 Wiki 层，它实际上是一个结构化的经验仓库。每次任务结束，Agent 把关键经验、决策过程、失败原因、可复用的代码片段提取出来，写入 Wiki 层；下次遇到新任务时，Agent 先检索 Wiki 里相关条目，再结合检索结果生成或选择 Skill 来执行。

换句话说：

• 普通 Skill= 给 Agent 一本工具书。
• WikiSkill= 给 Agent“笔记 + 工具书 + 索引系统”，而且这本笔记是 Agent 自己写的、实时更新的。

这种“执行 → 萃取 → 沉淀 → 检索 → 再执行”的闭环，就是 WikiSkill 被称为“进化”机制的原因。它不是一次性的能力增强，而是可持续积累的 Agent 知识系统。

3. 适用场景与使用边界

3.1 适合谁用

从论文动机和 Skill 生态来看，WikiSkill 最适合这三类人：

第一类是深度使用编程 Agent 的开发者。你在项目里已经积累了多个 Skill，但发现不同任务之间经验不互通。比如昨天解决了 Vue 项目中组件懒加载的问题，今天做另一个 Vue 项目时 Agent 又开始乱来。有了 Wiki 层，这类经验就能自动沉淀并复用。

第二类是跑长期自动化任务的运维或数据工程师。任务是周期性的、步骤复杂的，比如每天抓取网页、清洗数据、生成报告。Agent 如果能把每天执行的细节沉淀下来，几天后它的执行效率和稳定性会明显提升，因为昨天的坑今天就避开了。

第三类是研究 Agent 自我进化的技术人员。你是冲着“进化”两个字来的。WikiSkill 提供了一套可观察、可评估的经验管理机制，比起调提示词，实验点更清晰。

3.2 不适合的场景

对单次任务、一次性对话，不需要 WikiSkill。你问一次“这段代码哪里错了”，Agent 答完就结束了，没有长期记忆需求。

对强约束的合规场景，也要慎用。Wiki 层自动提取经验，意味着 Agent 会把执行过程中的某些信息写入持久化存储。如果任务涉及用户隐私、商业机密、未公开数据，未经过滤就直接写进 Wiki 层，会带来数据泄露风险。

3.3 使用边界与合规提醒

这一点必须单独说清楚。WikiSkill 实际上是一个“Agent 自学习”机制，它让 Agent 记住了执行过程中的经验，这意味着：

• 代码仓库内容可能被写入 Wiki 层，包括注释、变量名、业务逻辑，如果仓库是商业项目，要评估是否允许这么做。
• 操作数据可能被记录。比如 API 返回的字段、数据库结构、文件路径，这些都属于敏感信息。
• 人与 Agent 的交互内容也可能被沉淀。如果 Agent 在客户环境使用，需要遵循当地的数据保护法规。

所以我的建议是：Wiki 层一定要设计成可审计、可清理、可隔离的。可以给 Wiki 层加“敏感词过滤”“白名单字段”“定期归档”机制，避免经验库变成泄密库。在自己本地个人项目中验证没问题，但推到团队或生产环境前，想清楚数据的归属和访问控制。

4. 环境准备与前置条件

从论文复现的角度看，WikiSkill 本质上是一个围绕 LLM 的胶水层框架，它依赖你现有的 Agent 运行环境。验证它不需要特殊硬件，纯文本场景下 CPU 就能跑。

4.1 系统与软件要求

4.2 通用检查清单

在准备环境时，按这个顺序检查一遍：

1. 确认 Python 版本，命令行执行python --version。
2. 确认能访问 LLM 接口，设置好OPENAI_API_KEY或ANTHROPIC_API_KEY环境变量，或者确认本地 Ollama 已启动。
3. 确认网络能不能拉取依赖，国内环境建议配置 PyPI 镜像。
4. 确认一个空的实验目录，后续 Wiki 层数据文件会生成在这里。

4.3 安装依赖示例

下面给出一套通用 Python 依赖安装命令，实际包名以你选择的向量库和框架为准：

# 创建虚拟环境 python -m venv wikiskill_env source wikiskill_env/bin/activate # Windows 使用 wikiskill_env\Scripts\activate # 安装基础依赖（按实际项目调整包名） pip install langchain chromadb openai anthropic pydantic # 如果使用本地模型，可以安装 ollama 的 Python 客户端 pip install ollama

如果你的项目直接依赖 Claude Code 或 Codex 生态，则把重点放在确认 CLI 工具已登录、可用即可，WikiSkill 通常以“脚本 + 数据目录”的方式挂载进来。

5. WikiSkill 核心机制拆解

在动手写代码前，先把你需要实现的模块在脑子里过一遍。WikiSkill 本质上由四个模块组成：

5.1 经验提取器（Experience Extractor）

任务执行完成后，经验提取器负责从执行轨迹、最终结果、错误信息中抽取“值得记住”的内容。论文里强调的不只是“成功经验”，也包括“失败经验”。一次失败尝试往往比五次成功尝试更有复用价值。

抽取时可以关注四类信息：

• 任务的目标和约束条件。
• 执行过程中遇到的关键障碍。
• 解决方案和具体步骤。
• 可复用的代码片段或命令。

5.2 经验索引器（Indexer）

抽取出的经验要写入 Wiki 层，不能只用文档堆着。每条经验要有结构化的元数据，包括：适用场景、任务类型、涉及的工具、时间戳、与旧经验的差异。

索引器决定了一条经验能否被快速、准确地检索到。一个最简单的实现就是给经验生成“标签”和“摘要”，存到向量数据库里，用语义检索来找。

5.3 技能生成器（Skill Generator）

这是 WikiSkill 被讨论最多的地方：检索到相关经验之后，Agent 不是直接拿经验去填提示词，而是先尝试生成/更新 Skill。

比如 Wiki 里存了三条关于“处理 PDF 表格”的经验，技能生成器会综合这三条经验，生成一个更通用的“技能”：包括处理步骤、工具推荐、常见报错和解决方案。这个合并、精简的过程就是“进化”的体现——多条零散经验被归纳成了一条高密度 Skill。

5.4 评估与反馈循环（Evaluator）

最后是效果评估。每次 Agent 带着 Wiki 检索结果去执行任务，执行完应该对比“用 Wiki 之前的执行效果”和“用 Wiki 之后的执行效果”。评估标准可以是完成率、步骤数、报错次数、人工修正次数。

这一步很容易被忽略，但它才是“进化”的闭环。没有评估，你无法知道 Wiki 层到底是帮了忙还是拖了后腿。

6. 一个可落地的 WikiSkill 最小实现

下面给出一套极简但完整的本地实现思路。它不依赖 GitHub 上的具体仓库，而是按照论文思想从零写一个核心流程，适合你用来验证“Wiki 层到底有没有用”。

6.1 第一步：定义 Wiki 条目数据结构

from dataclasses import dataclass from datetime import datetime from typing import List @dataclass class WikiEntry: entry_id: str title: str task_context: str # 适用场景描述 key_steps: List[str] # 关键步骤 pitfall: str # 踩过什么坑 solution: str # 怎么解决的 code_ref: str # 可复用的代码或命令 created_at: str tags: List[str]

这个结构对应论文里的“结构化经验”理念。每条经验不是一个长篇大论，而是有明确字段的知识点。

6.2 第二步：经验写入与检索

以 Chroma 做向量检索示范。每写入一条经验，同时存原始文本和向量索引：

import chromadb from chromadb.utils import embedding_functions client = chromadb.PersistentClient(path="./wiki_store") collection = client.get_or_create_collection( name="wikiskill_entries", embedding_function=embedding_functions.DefaultEmbeddingFunction() ) def save_experience(entry: WikiEntry): doc_text = f"{entry.title}\n{entry.task_context}\n{entry.solution}" collection.add( documents=[doc_text], metadatas=[ {"tags": ",".join(entry.tags), "created_at": entry.created_at} ], ids=[entry.entry_id] ) def search_experience(query: str, top_k: int = 3): results = collection.query(query_texts=[query], n_results=top_k) return results["documents"][0]

有了这个底层，你的 Agent 就能在每次任务开始前先检索历史经验，然后在系统提示词里注入检索结果。

6.3 第三步：把 Wiki 检索结果注入 Agent 工作流

这里以最简方式演示，假设你用 OpenAI API 或 Anthropic API 直接调用：

def build_agent_prompt(user_task: str) -> str: related_experiences = search_experience(user_task, top_k=3) experience_text = "\n\n".join([ f"经验{i+1}：{exp}" for i, exp in enumerate(related_experiences) ]) return f""" 你是一个带经验记忆的智能体。执行任务前，先参考历史经验。 【本轮任务】 {user_task} 【Wiki 历史经验】 {experience_text} 要求：优先参考经验，但不要盲目照搬；如果发现新问题，记录新的经验，留给后续任务使用。 """

把这段“注入提示词”的逻辑接进你日常用的 Claude Code 或 Codex 工具链，就完成了最小可行验证。这时候 Wiki 层是“只读”的，你的 Agent 已经能回忆起之前的经验了。

6.4 第四步：把“新经验”回写 Wiki

回写逻辑是闭环的核心。建议在 Agent 每完成一个任务后，单独调用一个“经验总结”函数：

summary_prompt = f""" 刚才执行的任务是：{task} 执行过程摘要：{execution_log} 执行结果：{result} 请总结出一条值得复用的经验，包括： 1. 适用场景 2. 关键步骤 3. 遇到过的问题 4. 解决方案 输出为 JSON 格式。 """ # 调用 LLM 获取结构化经验 # 解析 JSON 后生成 WikiEntry 对象 # 调用 save_experience() 写入向量库

这一步就是把“执行记录”变成“结构经验”的过程，也是 WikiSkill 里最有价值的部分。你不需要用户手动去写经验，Agent 自己就能提炼、压缩、入库。

7. 验证 WikiSkill 实际效果：AB 测试与指标设计

很多人装完 WikiSkill 之后只会在 Wiki 里存几条经验，然后就不知道下一步该干嘛。验证 WikiSkill 是否有效，核心方法是做 AB 测试，不是“感觉变强了”就完事。

7.1 测试任务集

准备 10 到 20 个相同类型的任务。建议选任务执行结果可以客观量化的工作。

比如：

• 用 Python 脚本处理 20 个 CSV 文件，记录每个文件的成功/失败情况。
• 对一批 Markdown 文档做格式转换，记录报错次数。
• 让 Agent 修复一组已知 bug 的代码库，记录修复用时和正确率。

7.2 对照组设计

对比 A/B/C 三组的指标。A 组是基线，B 组验证“检索历史经验”有没有用，C 组验证“经验自动进化”有没有用。这是最能说明 WikiSkill 价值的实验设计。

7.3 核心指标

• 任务完成率：任务成功结束的比例。
• 平均耗时：从启动任务到完成的时间。
• 平均干预次数：需要人工介入纠错的次数。
• 首次成功率：一次成功，不需要重试的比例。

如果你跑完 20 条任务，B 组或 C 组的首次成功率明显高于 A 组，那 WikiSkill 的经验沉淀机制就在起作用。如果指标无差异，那大概率是 Wiki 检索质量太低，或者任务本身的复杂度不足以体现经验价值。

7.4 失败原因排查

AB 测试做出来没效果时，优先检查三点：

1. 检索是否准确：看看搜出来的前 3 条经验是否是“真正相关”的经验。
2. 经验是否可执行：Wiki 里存的经验到底是“高密度的解决方案”还是“废话总结”。
3. 提示词注入是否有效：Agent 是否真的把经验当回事，还是干脆忽略了。

实际项目中 90% 的失效场景，都出在“经验质量太差”或“检索不相关”上，而不是框架本身有问题。

8. 接口 API 设计与批量任务集成

如果你需要把 WikiSkill 做成一个团队可用的服务，或者接入现有自动化系统，建议按下面这组接口来设计。

这里给出通用 API 模板，具体路径和参数按你的实现调整：

# FastAPI 示例 from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class ExperienceQuery(BaseModel): task: str top_k: int = 3 class ExperienceSave(BaseModel): entry_id: str title: str task_context: str key_steps: list pitfall: str solution: str tags: list @app.post("/wiki/search") def search_experience_api(query: ExperienceQuery): docs = search_experience(query.task, query.top_k) return {"code": 0, "data": docs} @app.post("/wiki/save") def save_experience_api(entry: ExperienceSave): save_experience(WikiEntry(**entry.dict())) return {"code": 0, "message": "saved"}

8.1 批量任务设计

WikiSkill 的批量任务场景通常有两种：

离线批量经验提取：你有大量执行日志，想一次性把经验灌进 Wiki 层。这时候不需要实时调 Agent，可以按“日志文件分批 → 并行调用 LLM 总结 → 写入 Wiki”的流程处理。

批量任务时调用 Wiki 经验：如果一批任务有 1000 个文件要处理，每个任务执行前都调用 Wiki 检索，要注意性能。建议给检索接口加上缓存，同类任务的检索结果可以复用。

8.2 失败重试机制

批量任务中最怕的不是失败，是连续失败但 Agent 不长记性。有了 Wiki 层，你就可以设计一个更聪明的重试策略：

• 第一次失败，把错误信息写入临时区；
• 重试前先调用 LLM，基于错误信息生成一条“失败经验”；
• 把这条经验注入提示词，再重试一次；
• 如果仍失败，保留经验但停止重试，让人工介入。

这样做的好处是同一批任务中，前面任务踩过的坑能实时传给后面的任务，批量任务的收敛速度会快很多。

9. 资源占用与性能观察

9.1 显存与内存

WikiSkill 本身不消耗显存。真正消耗资源的是你接入的 LLM：

• 你用的是 API 调用（OpenAI / Anthropic）：显存 0，但每次调用有费用。
• 你用的是本地 Ollama / vLLM：显存取决于模型大小，7B 模型量化后大约需要 6GB 显存，13B 模型大约需要 10GB。
• 向量检索（Chroma / FAISS）：纯内存即可，10000 条经验量级下，内存占用通常不超过 500MB。

9.2 检索质量的观察点

Wiki 层的检索质量，直接关系到最终效果。实操中重点看一个指标：检索结果和当前任务的相关度。

可以这样观察：在 Agent 执行任务前，把检索出的前 3 条经验打印到日志里。人工看一眼这些经验是不是“多少沾点边”。如果十条任务有七条搜出来的经验完全无关，先别急着调 Agent，优先调检索策略。

9.3 降本增效策略

• 只对小部分任务开启 Wiki 检索，比如遇到报错时再查，降低平均成本。
• 压缩 Wiki 条目：定期让 LLM 把多条相似经验合并成一条高密度经验。
• 控制检索条数：初始测试 top_k = 1 或 2，看效果后再加到 3。
• 知识过期处理：给 Wiki 条目加时间戳，超过一定时间但一直未被命中的条目，标记为“待复核”，防止经验库腐烂。

10. 常见问题与排查方法

针对“经验越存越多，效果反降”这个现象，多说两句。很多人以为 Wiki 层是“存得越多越好”，实际恰恰相反。经验库是一个强先入先出的系统，旧经验可能曾经有效，但环境变了之后就会失效。所以 Wiki 层一定要设计“知识生命周期”，定时让 LLM 做一次“知识体检”，把过期、重复、冲突的条目合并或降权。

11. 最佳实践与合规建议

11.1 工程化落地建议

先小后大
不要一开始就把所有 Agent 任务都接上 Wiki 层。先选一个任务子集，跑通闭环，确认检索有效，再逐步推广。

经验质量优先于数量
一篇好经验可以顶得上十篇碎碎念。在经验提取的提示词里，明确要求 LLM 少写总结性评价，多写“可选方案、命令脚本、排错路径”。

以目录和标签构建边界
给 Wiki 层按项目或团队分区，避免不同业务场景的经验互相污染。

保留审计链路
Wiki 层不是“随便问问就能记”。我给你强烈建议，每条经验落库时保存“来源信息”，包括任务 ID、执行时间、关联的代码版本，出了问题才查得回去。

11.2 合规与安全边界

因为 WikiSkill 的本质是“Agent 自动记忆”，所以隐私和版权问题要比普通 Agent 场景更敏感。

• 涉及客户数据时，Wiki 层必须关闭自动写入，改为人工审核后入库。
• 涉及未公开的商业代码，建议不要写入第三方 LLM 厂商的 API 请求链路上，除非数据协议允许。
• 如果你做的是“用 Agent 分析漏洞”这类安全研究，Wiki 层可能会保留安全细节。研究成果公开发布前，用常识检查一遍哪些细节不应公开。
• 如果 Wiki 层混入了他人的版权内容，比如大段代码或文档摘录，在团队内复用没问题，对外发布时要格外小心。

一句话总结：让 Agent 变聪明的前提，是确保聪明的方式不带来新的风险。

12. 总结与下一步方向

WikiSkill 这个方向最值得尝试的点，就是它把 Agent 的能力进化从“玄学”变成了“工程”：你不再靠调整提示词来碰运气，而是可以设计一套自动化的经验提取、沉淀、检索机制，让 Agent 在每一次任务后都比上一次好一点。

如果你是第一次落地，建议按这个顺序走一遍：

1. 先准备一个高频重复任务，搭好“检索 → 注入提示词 → 执行 → 总结回写”的最小闭环。
2. 跑一个 AB 测试，对比有 Wiki 和无 Wiki 的首次成功率。
3. 确认效果后，再考虑接入批量任务、设计 API、团队共享。

最容易踩的坑就是“一上来就想做一个完美的经验系统”，结果三天过去还在调向量库参数。更好的方式是先把闭环跑通，哪怕检索用简单的关键词匹配，也比没有经验库强。

后续可以继续扩展的方向不少：给 Wiki 层加入自动化评估与淘汰机制，让经验库自我进化而非只增不减；把 Wiki 从“文本经验”扩展到“结构化工作流”，让 Agent 记住的不只是答案，而是整套处理步骤；或者把 WikiSkill 和 Codex 的 Skill 机制打通，把 Wiki 沉淀出的经验自动编译成可被直接调用的技能脚本。

WikiSkill 目前仍在快速演进。建议对 Agent 开发感兴趣的朋友，持续关注这个方向的后续工作。看完这篇如果你觉得 WikiSkill 对你有用，建议收藏备用，下次给 Agent 接记忆的时候会感谢自己。

核心关键词：WikiSkill、Skill 进化、Wiki 层经验库、Agent 经验复用、智能体自动学习。