WikiSkill：让AI Agent技能在实战中自我进化的经验复用机制

如果你最近在关注 AI Agent 相关的技术很可能已经刷到过 “Skill”、“Codex Skill”、“Claude Code Skill” 这些词。简单说Skill 就是把一类任务的执行经验固化下来让大模型下次直接按套路执行不用再从零思考。这个思路很好用但很多人实际跑起来会发现一个问题Skill 是静态的每到一个新环境、新需求还是要人工去改脚本、补提示词踩过的坑还是会被反复踩。这次谷歌有一篇论文就是这个方向名字叫 WikiSkill。它提出的思路非常直接给 Skill 加一个 “Wiki 层”让智能体在执行任务的过程中把经验沉淀下来下次遇到类似任务直接检索复用。换句话说Skill 不只是“写出来”的而是可以在使用中自己“长出来”的。读完这篇论文我对整个 Agent 技能体系的看法变化很大这篇博客就把 WikiSkill 的核心机制、最小可验证流程、接口设计思路和落地时要注意的边界一次性讲清楚。在开始之前先给一个整体判断WikiSkill 不只是一个论文概念它更像是一套可以落地到现有 Agent 工程里的设计模式。如果你已经在写 Skill或者正在规划 Agent 的批量任务系统这套“任务执行 → 经验沉淀 → 技能复用”的闭环非常值得参考。1. WikiSkill核心能力速览能力项说明定位面向大模型 Agent 的经验复用框架 / 方法论核心机制为 Skill 增加独立的 Wiki 经验层任务执行后自动沉淀经验任务开始前检索并注入相关经验主要功能技能封装、经验条目管理、相似经验检索、上下文注入、技能持续进化支持平台Linux / macOS / Windows 均可只要能跑 Python 或对应 Agent 框架显存占用不涉及模型推理显存实际开销主要在模型调用 token 与本地存储存储方案可用 SQLite / JSON 起步大规模检索可接入向量数据库是否有 API论文本身不强制但可以自行封装 REST API 或函数调用接口是否支持批量任务支持经验沉淀和技能复用天然适合批量流水线适合场景Codex Skill 开发、Claude Code Skill 开发、Agent 工作流优化、批量任务平台、个人效率工具上手成本低不依赖特定模型把现有 Skill 流程改造成“先检索后执行、执行后沉淀”即可从公开资料看WikiSkill 更偏向于一套可复现的 Agent 设计方法。如果你想马上体验不需要等官方整合包完全可以用现有框架把这条链路搭出来。2. 为什么 Skill 需要“进化”而不是“一次性编写”在进入 WikiSkill 细节之前先对齐一个问题Skill 到底是什么它和 Agent 有什么区别以及它现在的核心痛点在哪里。现在的 AI Agent 已经具备了调用工具、读取文件、执行代码、访问网页的能力但是 Agent 本身并不知道“怎么做效率最高”。Skill 就是解决这个问题的把你处理某类任务的步骤、提示词、代码模板、工具调用方式打包成一个可复用的技能包。比如常见的有日志分析 Skill、PPT 生成 Skill、代码审查 Skill、简历筛选 Skill本质上都是在给模型一套标准作业程序。但现在的 Skill 体系有一个明显短板经验是单向流动的。人写好一个 Skill模型照着执行执行得好不好、有没有新的坑Skill 本身不会记录。尤其是当你给 Agent 布置批量任务时前 100 个任务可能踩了同一个坑第 101 个任务继续踩。你作为一个开发者需要不断手动维护 Skill这违背了“让 Agent 自己工作”的初衷。这里其实有一个很关键的技术判断Skill 的进化能力取决于能否把任务结果转化成可检索的结构化知识。如果你只是让 Agent 把结果写进日志那不叫进化那叫记录。真正的进化是模型执行完一个任务之后能够提炼出“这类问题原本会卡在哪、我是怎么绕过去的、下次遇到什么特征可以优先尝试什么方案”并且把这些结论以一种标准格式存下来。等下一个类似任务到来时系统自动把相关结论注入上下文让模型不用重新摸索一遍。WikiSkill 的切入角度就在这里。它把“进化”拆成了两个可操作的动作第一沉淀。每次任务完成后把本次任务的目标、关键问题、处理步骤、验证结果、经验教训整理成一条结构化条目写入 Wiki 层。第二复用。新任务开始时先到 Wiki 层做一次检索找出最相关的历史经验把检索结果拼进任务上下文辅助模型决策。这两个动作看起来简单但设计得当的话你会发现 Skill 的效果是叠加的。一开始可能只是一套普通的 Codex Skill跑了几十个任务之后这个 Skill 就变成了一个带着实战经验库的智能体技能效果自然比静态 Skill 好一截。3. WikiSkill 的机制拆解Skill 层、Wiki 层与经验封装WikiSkill 从结构上可以拆成三层来理解。3.1 Skill 层可执行的动作模板这一层就是我们常见的 Skill 本身通常是目录结构、提示词、脚本和工具描述的组合。在 Codex 和 Claude Code 这类产品里Skill 一般是一个文件夹里面有说明文件、示例代码、工具调用约定。它是“怎么做”的骨架但只靠这一层是不具备进化能力的因为它是静态资产。3.2 Wiki 层结构化的经验库Wiki 层是 WikiSkill 的核心增量。它不关心具体的脚本实现只关心“这个任务在真实环境中表现如何”。每一条 Wiki 条目都应该有一个清晰的结构我建议至少包含以下几块任务类型这条经验适用于哪一类任务比如“Python 项目依赖冲突排查”。问题触发条件什么环境下容易出现问题比如“requirements.txt 锁定版本冲突时”。处理步骤解决问题的顺序包括命令、参数、工具选择。验证方式如何确认问题真正解决避免“看着好了实际没修好”。结果状态成功、失败、部分成功以及风险提示。使用限制这条经验在什么边界内有效比如“仅适用于 pip 管理的项目”。这种结构的好处是检索时可以直接命中“问题触发条件”和“任务类型”注入到模型上下文后模型可以迅速理解当前场景与历史场景的匹配度。如果不做结构化直接丢一段对话日志进去模型的可用性会受到较大影响。3.3 执行器负责检索、注入和沉淀执行器是 Wiki 层与 Skill 层之间的调度器。它的工作流程是接收新任务解析出任务类型与关键参数。根据任务描述到 Wiki 层检索相似经验。把相似经验注入系统提示词或用户消息中。调用模型和 Skill 中的工具完成执行。任务结束后将本次执行的观察结果格式化为 Wiki 条目。这里最值得注意的一点是沉淀过程不要只让模型自己总结还需要叠加程序化规则。比如你可以在任务结果里固定要求输出“是否解决了原始问题”“过程中遇到过哪些错误”“最终采用的方案”然后由程序把这些字段组装成 Wiki 条目。模型负责内容产出程序负责结构标准化两个各干各的活效果最稳。从论文的表述方式看Wiki 层之所以叫 “Wiki” 而不叫 “Memory” 或 “Database”重点在于它强调的是可编辑、可版本化、可多人协作的知识库。它不是藏在向量数据库里的隐形记忆而是可以随时打开、修改、审核的经验文本。这种设计对工程团队尤其重要你可以在 Agent 自动沉淀之后再安排人工或自动化规则去校验、合并、清理低质量条目让经验库保持在一个健康状态。4. 本地验证环境准备虽然 WikiSkill 是论文方法但如果你想在自己的机器上跑通这套机制并不需要等官方开源包。这里给出一套通用的环境准备清单所有版本号和路径都可以按你实际项目调整。4.1 基础环境操作系统Linux / macOS / Windows 均可。Python 3.10 或更高版本用于跑沉淀脚本和 API 服务。Node.js 18如果你用的是 Claude Code 或类似 Node 生态工具。可用的模型访问通道OpenAI 兼容接口、Anthropic 接口或本地模型服务都可以。磁盘空间Wiki 层只是文本和 JSON 文件初期占用很小预留几百 MB 足够。4.2 目录结构建议建议在项目中单独划出一个wiki/目录与 Skill 脚本分开管理。agent-project/ ├── skills/ │ ├── log-analyzer/ │ │ ├── SKILL.md │ │ ├── tools/ │ │ └── examples/ │ └── code-review/ │ ├── SKILL.md │ ├── tools/ │ └── examples/ ├── wiki/ │ ├── entries/ │ │ ├── 20250101-log-analysis-001.md │ │ ├── 20250101-log-analysis-002.md │ │ └── 20250102-dependency-conflict-001.md │ └── index.json ├── scripts/ │ ├── write_wiki_entry.py │ ├── search_wiki.py │ └── agent_runner.py └── data/ ├── inputs/ └── outputs/这个结构把技能、经验、脚本、数据四类资产彻底分开。后续做批量任务时inputs和outputs目录管理会非常顺手。4.3 最小依赖如果只是想验证流程建议先不要引入向量数据库直接从 JSON 或 SQLite 起步pip install fastapi uvicorn requests如果后续 Wiki 条目数量超过几千条再考虑引入向量检索比如本地部署一个轻量级向量库或者调用外部 Embedding API。不要一开始就把系统设计复杂。5. 跑通最小闭环任务执行 → 经验沉淀 → 技能复用WikiSkill 最重要的价值体现在闭环上。这里我给你一个可验证的最小流程你可以用任何 Agent 框架实现它核心逻辑是一样的。5.1 第一步设计一个实验任务先选一个你能快速判断结果好坏的场景比如“让 Agent 写一个 Python 脚本扫描指定目录下的日志文件统计 ERROR 级别的关键字出现次数并输出 CSV”。这个任务看起来简单但第一批任务大概率会出现编码问题、路径分隔符问题、正则表达式误判问题。这些都是可以用来沉淀经验的素材。5.2 第二步无经验基线测试不注入任何 Wiki 经验直接让 Agent 完成任务。记录以下指标是否一次成功。是否出现与目标无关的多余操作。最终输出格式是否符合预期。这一步很重要因为后续对比时需要它作为基线。5.3 第三步定义 Wiki 条目的 JSON 结构沉淀经验时建议先用统一 JSON 结构再落盘成 Markdown。这里给一个最小可用的 schema 参考{ id: 20250101-log-analysis-001, task_type: 日志分析, title: 日志文件编码gbk导致读取报错, trigger_condition: 当输入日志路径中的文件为Windows平台生成且未指定encoding时, steps: [ 先探测文件编码使用chardet或直接指定encodingutf-8, errorsignore, 对csv输出统一使用utf-8-sig编码避免Excel打开乱码 ], verification: 检查脚本在gbk与utf-8两种日志文件上都能输出正确行数, status: success, constraints: 仅适用于纯文本日志不适用于二进制日志, created_at: 2025-01-01T12:00:00Z }这种结构在后续检索时非常有用因为trigger_condition可以直接作为语义检索的比对字段。5.4 第四步编写沉淀脚本沉淀脚本接收任务原始信息和 Agent 的执行反馈格式化为一个 Wiki 条目。下面是一个通用的 Python 模板import json import uuid from datetime import datetime, timezone def create_wiki_entry(task_meta, execution_result): 把一次任务执行结果沉淀为一条Wiki经验。 实际使用时请根据你的Agent返回结构调整字段映射。 entry { id: f{datetime.now(timezone.utc).strftime(%Y%m%d)}-{uuid.uuid4().hex[:8]}, task_type: task_meta.get(task_type, 未知任务), title: execution_result.get(title, 未命名经验), trigger_condition: execution_result.get(trigger_condition, ), steps: execution_result.get(steps, []), verification: execution_result.get(verification, ), status: execution_result.get(status, unknown), constraints: execution_result.get(constraints, ), created_at: datetime.now(timezone.utc).isoformat() } # 写入JSON索引 with open(wiki/index.json, a, encodingutf-8) as f: f.write(json.dumps(entry, ensure_asciiFalse) \n) # 同时写入一个Markdown文件方便人工审查 md_path fwiki/entries/{entry[id]}.md with open(md_path, w, encodingutf-8) as f: f.write(f# {entry[title]}\n\n) f.write(f- 任务类型{entry[task_type]}\n) f.write(f- 触发条件{entry[trigger_condition]}\n) f.write(f- 处理步骤\n) for step in entry[steps]: f.write(f - {step}\n) f.write(f- 验证方式{entry[verification]}\n) f.write(f- 使用限制{entry[constraints]}\n) f.write(f- 状态{entry[status]}\n) return entry if __name__ __main__: # 这里替换为你的Agent实际返回结果 task {task_type: 日志分析} result { title: 日志文件编码gbk导致读取报错, trigger_condition: 日志文件为Windows平台生成且未指定encoding, steps: [使用encodingutf-8, errorsignore读取, CSV输出使用utf-8-sig编码], verification: 在两种编码文件上均能输出正确行数, status: success, constraints: 仅适用于纯文本日志 } create_wiki_entry(task, result) print(Wiki entry created.)这个脚本的核心价值在于把不可控的模型输出转化为可控的结构化经验。每次任务跑完执行器调用一次Wiki 层就多一条经验。5.5 第五步编写检索注入脚本当新任务到来时先从 Wiki 索引中检索相似条目再把相关经验注入到模型上下文。这里给一个最简单的关键词检索版本import json def search_wiki(task_description, top_k3): 基于任务描述关键词在Wiki索引中检索相关知识。 这是最小实现生产环境建议改用向量检索。 with open(wiki/index.json, r, encodingutf-8) as f: lines f.readlines() scored [] query_terms set(task_description.lower().split()) for line in lines: entry json.loads(line) text f{entry[task_type]} {entry[title]} {entry[trigger_condition]} score sum(1 for term in query_terms if term in text.lower()) if score 0: scored.append((score, entry)) scored.sort(keylambda x: x[0], reverseTrue) return [entry for _, entry in scored[:top_k]] def build_injected_prompt(task_description): related search_wiki(task_description) if not related: return task_description context 以下是从历史经验库中检索到的相关处理经验请优先参考\n\n for entry in related: context f【经验】{entry[title]}\n context f触发条件{entry[trigger_condition]}\n context 处理步骤\n for step in entry[steps]: context f- {step}\n context f验证方式{entry[verification]}\n context f使用限制{entry[constraints]}\n\n return context 当前任务 task_description if __name__ __main__: new_task 读取一个Windows项目日志目录下的所有log文件并统计错误数 prompt build_injected_prompt(new_task) print(prompt)你可以把这个build_injected_prompt的输出作为最终发给模型的 Prompt。模型看到历史经验后大概率会直接生成带编码处理的脚本而不是先踩一遍坑再修正。5.6 第六步效果对比运行带 Wiki 经验注入的流程再与第二步的基线对比首轮成功率是否提升。生成代码是否更接近最终可用状态。是否需要人工干预。从工程经验看只要 Wiki 层积累了几条高质量经验后续同类任务的首轮成功率通常会有比较明显的提升。如果你发现没有提升问题一般出在检索匹配质量、经验条目质量、或者提示词注入的位置不对需要逐项排查。6. 批量任务与 Wiki 条目的工程化管理WikiSkill 在单个任务上只是锦上添花在批量任务上才是真正的降本工具。一批任务跑 500 次如果前 50 次沉淀的经验能被后 450 次复用整体效率和稳定性都会上一个台阶。6.1 批量流水线设计一个合理的批量流水线至少应该包含下面几个阶段输入预处理读取一个inputs/目录下的素材生成任务列表。经验检索每个任务开始前检索 Wiki。Agent 执行调用模型与工具完成任务。结果校验程序化校验关键输出是否有效。经验沉淀对成功与失败任务都分别生成 Wiki 条目。6.2 失败任务也要沉淀工程上最容易忽略的一点是失败任务的经验可能比成功任务更有价值。建议给失败任务单独打上statusfailed标签记录失败现象与当前尝试过的无效方案。这样后续任务可以避免重复尝试被证明无效的路径。6.3 并发写入控制如果脚本支持并发多个任务同时写wiki/index.json会出现写冲突。两种常见方案第一种是用 SQLite 替代 JSON 文件利用数据库事务保证写入原子性。第二种是写一个独立的队列进程所有 Agent 执行完成后统一由沉淀脚本串行写库。这里给一个建议性的队列入口伪代码# 伪代码实际实现需要按你的框架调整 import queue wiki_write_queue queue.Queue() def agent_done_callback(task_id, result): wiki_write_queue.put({ task_id: task_id, result: result }) def wiki_writer_worker(): while True: item wiki_write_queue.get() if item is None: break create_wiki_entry(item[result][task_meta], item[result][execution_result])这种解耦方式可以让 Agent 执行流程不被 Wiki 写入阻塞同时保证写入是串行的。6.4 条目质量的分级策略随着条目增多低质量经验会稀释检索效果。一种简单可行的做法是给 Wiki 条目加一个可信度字段比如verified该经验已经被人或自动化测试验证过。unverified该经验仅由单次执行产生可能存在偶然性。deprecated该经验已经失效不应该再被检索引用。检索时优先返回verified条目。这样做的好处是即使 Agent 自动沉淀了大量低质量经验也不会直接影响任务效果。7. 接口 API 设计与外部工具接入如果你的 Wiki 经验库希望被多个 Agent、多个服务共用最直接的方式是把它封装成 REST API。下面给出一个使用 FastAPI 的最小参考实现具体字段和路径可以根据你的项目调整。7.1 写入接口# app.py 片段仅示意 from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class WikiEntry(BaseModel): task_type: str title: str trigger_condition: str steps: list[str] [] verification: str status: str unverified constraints: str app.post(/wiki/entries) def create_entry(entry: WikiEntry): # 实际实现中这里调用你的写入脚本 return { status: ok, id: generated-entry-id }7.2 检索接口app.get(/wiki/search) def search_wiki_endpoint(q: str, top_k: int 3): # 实际实现中这里调用你的检索脚本 results [ { id: 20250101-log-analysis-001, title: 日志文件编码gbk导致读取报错, trigger_condition: 日志文件为Windows平台生成且未指定encoding, steps: [使用encodingutf-8, errorsignore读取, CSV输出使用utf-8-sig编码] } ] return {results: results[:top_k]}7.3 curl 调用示例保存好上面的接口后可以用一个简单的 Python 脚本验证批量写入和检索是否正常curl -X POST http://127.0.0.1:8000/wiki/entries \ -H Content-Type: application/json \ -d { task_type: 日志分析, title: CSV输出Excel打开乱码, trigger_condition: 输出csv文件被用户用Excel打开时, steps: [写入csv时使用utf-8-sig编码], verification: Excel打开无乱码, status: verified }curl http://127.0.0.1:8000/wiki/search?qwindows%20日志%20编码top_k3如果你的 Agent 本身是脚本化运行也可以不通过 HTTP直接以 Python 函数方式调用search_wiki和create_wiki_entry。这样网络开销更小更适合批量流水线。API 化最大的价值在于Agent 和日志分析工具、定时任务调度器、可视化面板都能共用同一套经验库。8. 资源占用与性能观察WikiSkill 不涉及大模型推理的显存占用主要开销集中在三个地方经验条目的存储、检索计算、以及注入上下文时多消耗的 token。8.1 Token 消耗这是最需要关注的一点。因为每条 Wiki 经验注入到 Prompt 里都会占用上下文窗口。如果一次任务注入 5 条经验每条经验大约 200 到 400 个 token一次就会多消耗 1000 到 2000 个 token。单次看不多但批量任务跑起来token 成本会线性增加。常见的优化方式检索时降低 top_k先默认返回 2 到 3 条高质量经验。注入前做摘要截断只保留steps和constraints忽略时间戳、标题等字段。对verified条目才做全文注入其余只注入标题和链接。8.2 检索延迟如果使用关键词检索几千条以内基本不需要优化响应时间可以忽略。如果条目量达到数万条建议接向量检索用 Embedding 模型把trigger_condition和steps向量化再走最近邻搜索。更稳妥的做法是混合检索关键词检索保证精确性向量检索保证召回率两者结果做加权合并。这套方案在本地环境也能跑起来关键看你对实时性的要求。8.3 存储与备份Wiki 层本质上是一堆文本文件和索引应该纳入版本管理。建议在 Git 仓库中单独开一个分支或者子目录放 Wiki每次批量任务跑完做一次提交。这样一旦经验库被污染可以快速回滚到上一个稳定版本。需要观察的关键指标包括经验条目总数、各任务类型的数量分布、验证通过率、检索命中率、注入后任务首轮成功率。这些指标不需要额外系统直接由沉淀脚本附带输出到日志即可。等到数据足够多你才能验证 WikiSkill 在你自己场景里到底提升了多少。9. 常见问题与排查方法问题现象可能原因排查方式解决方案Agent 任务完成后不生成 Wiki 条目执行器没有调用沉淀接口或模型返回内容缺少必要字段检查执行器日志确认是否走到沉淀步骤在 Agent 主流程中强制加入沉淀步骤缺少字段时补默认值检索不到相关经验任务描述用词与trigger_condition差异过大打印检索结果日志检查关键词匹配情况改用向量检索或在沉淀时补充同义词字段注入经验后效果反而变差检索到了低质量或不相关的经验检查注入内容的条目 id 和匹配得分限制只注入verified条目提高阈值增加人工审核环节并发写入时 index.json 损坏多个进程同时写入同一文件检查是否出现半行 JSON改用 SQLite或用队列串行写入上下文窗口溢出注入经验过多或单条经验过长查看 Prompt token 统计降低 top_k对经验做摘要截断批量任务中后段效果不稳定经验库被单一类型的低质量条目污染统计各任务类型条目数和验证通过率清理低质量条目给条目增加类型白名单API 服务启动失败端口被占用或依赖缺失查看 uvicorn 报错日志换端口启动按错误安装依赖模型不按经验里的步骤执行注入位置靠后或经验与系统提示词冲突检查最终发给模型的 Prompt 顺序将经验注入放在系统提示词和工具描述之后、用户任务之前这里要特别提醒一句Wiki 经验只是一段文本模型是否严格参考并不保证。如果关键步骤必须强制执行应该把该步骤写成工具调用约束或代码验证规则而不是只依赖模型的“自觉”。10. 最佳实践Skill 进化工程的合规与边界WikiSkill 说起来很简单但在真实工程里落地有一些边界必须提前立好。10.1 先从小场景验证再横向扩展不要一上来就给所有 Skill 加 Wiki 层。建议先选一个任务类型清晰、结果可自动校验的场景比如日志分析、批量文件重命名、代码格式修复。跑通闭环之后再逐步推广到其他 Skill。这个顺序能让你在早期就发现检索、注入、沉淀中的问题避免后期大规模整改。10.2 经验库必须可审计Agent 自动沉淀的经验不一定正确。因此 Wiki 层不能做成一个黑盒而应该是一个可以随时打开、审阅、回滚的知识库。每一个条目都要记录来源任务 ID、创建时间、验证状态。如果某个经验被证实无效直接标记deprecated而不是删除这样可以保留历史证据。10.3 版权与隐私合规如果你用 WikiSkill 处理文档、代码、音视频或者人物相关素材需要额外注意版权和授权问题。Wiki 条目不单单是文本存储如果它包含了原始素材中的关键片段、代码片段、或者个人标识信息后续被其他任务检索复用等于把你的输入数据二次传播了。所以在沉淀脚本里应该默认对原文做脱敏和摘要化处理不要整段复制原文。涉及人脸、声音、肖像、隐私数据时必须确保你有合法的处理与传播授权并且只在授权范围内使用。10.4 自动化越权风险让 Agent 自己决定沉淀什么、执行什么虽然效率很高但也带来越权风险。比如一个 Agent 在代码仓库里自动提交变更如果它把“绕过测试直接提交”的经验写进 Wiki 并被后续任务复用后果可能很严重。因此建议对 Skill 和 Wiki 设置权限级别核心系统的操作经验必须经过人工验证才能被复用。10.5 版本控制Wiki 层应该像代码一样做版本管理。每一次批量任务结束后把新增和修改的条目提交一次。回溯问题时可以直接查看某个时间点的经验库状态。这个习惯在经验库条目超过几百条后尤其重要。11. 总结与下一步WikiSkill 的核心贡献是把 Skill 从“静态脚本”升级为“可持续进化的经验系统”。它的关键设计是一套独立的 Wiki 层用结构化条目保存任务执行过程中产生的经验在下一次任务开始时检索并注入上下文最终形成“越用越好用”的闭环。如果你的工作流里已经有 Agent 批量任务我建议你从三步开始第一先定义一种任务的 Wiki 条目结构不要贪多只服务一个高频场景。第二写一个最小沉淀脚本和一个检索注入脚本把“执行→沉淀→复用”这条链路跑通。第三积累至少几十条任务结果后对比首轮成功率的变化。如果效果正向再扩展更多 Skill如果效果不明显优先检查条目质量和检索匹配策略。这个方向接下来可以扩展的点也不少。比如把 Wiki 检索从关键词升级为向量检索、给 Wiki 条目做自动去重和冲突检测、在不同 Agent 框架之间共享经验库、或者把经验库做成多人团队可编辑的服务。本质上Agent 的学习能力不一定要靠微调模型通过外部经验库做“运行时进化”成本更低效果也更可控。建议把这个思路收藏备用尤其是你准备写自己第一套 Skill 的时候。先用一篇小 Skill 验证闭环再逐步放大这个方向很值得投入。