LLM相关知识概念分享

今天我们聚焦LLM（大语言模型）生态的核心技术，在当下AI每天几天一个新的知识，我觉得理解底层基石，也是非常有必要的，从基础概念入手，拆解每一项技术的来龙去脉——它为什么会出现、解决了行业什么痛点，以及目前还有哪些待突破的瓶颈。

一、LLM（大语言模型）—— 所有技术的“地基”

首先，我们得明确一个基础概念：什么是LLM？LLM全称Large Language Model，即大语言模型，是基于深度学习技术，通过海量文本数据训练而成、能够理解和生成人类语言的模型。它的核心是“大规模参数+无监督预训练”，最具代表性的就是GPT系列、LLaMA系列、文心一言等。

### 背景（2017–2020年，关键转折点）

在LLM出现之前，传统NLP（自然语言处理）的模式是“一个任务一个模型”——比如做文本分类要训练一个模型，做机器翻译又要训练另一个模型，不仅效率低，而且泛化能力极差。2017年Transformer架构的提出，为大模型奠定了技术基础；2020年GPT-3的发布，更是打破了行业认知——它以1750亿参数规模，首次证明“仅通过海量文本预训练，模型就能涌现出上下文学习能力”，无需针对具体任务微调，就能完成简单的语言生成、问答等任务。

### 解决的核心问题

• 终结了传统NLP“任务专属模型”的低效范式，实现“一个模型适配所有语言类任务”，大幅降低了AI语言应用的开发门槛。

• 实现了“零样例/少样例推理”——哪怕不提供大量标注数据，只要给一句简单提示，模型就能输出符合预期的结果（比如给一句“写一段介绍LLM的话”，模型就能直接生成）。

• 极大提升了语言理解、生成、翻译、摘要、对话等核心能力，让AI语言交互更接近人类水平。

### 目前未解决的痛点（行业共性难题）

LLM虽然强大，但至今仍有几个难以突破的瓶颈，也是后续所有技术试图解决的核心问题：

• 幻觉问题：模型会编造不存在的事实，而且语气非常自信，难以区分真假（比如编造一个不存在的学术论文、错误的历史事件）。

• 知识截止：模型的知识局限于训练数据的时间范围（比如训练数据截止到2023年，就无法知道2024年的新事件），无法实时更新知识。

• 上下文窗口有限：面对超长文本（比如几万字的文档），模型会丢失前面的关键信息，出现“记不住”的情况。

• 推理不可靠：处理复杂逻辑问题（比如数学计算、多步骤推理）时，容易出现逻辑断裂、计算错误。

二、Prompt Engineering（提示工程）—— 让LLM“听懂话”的艺术

基础认知：提示工程（Prompt Engineering），简单来说，就是“通过优化输入提示的方式，引导LLM输出符合预期结果”的技术。它不需要修改模型的任何参数，纯粹靠“话术技巧”，让模型理解你的需求——比如同样问“介绍LLM”，提示“用300字通俗语言介绍LLM，适合小白理解”，比单纯问“介绍LLM”的输出效果好得多。

### 背景（2020–2022年，LLM应用爆发期）

GPT-3发布后，大家发现一个关键问题：同一个模型，输入不同的提示，输出质量天差地别。比如同样让模型写一篇文案，有的提示能写出流畅有逻辑的内容，有的提示却只能写出杂乱无章的文字。这时候，“如何设计提示”就成了LLM应用的核心技能——不需要懂复杂的模型训练，只要掌握提示技巧，就能让LLM发挥出更好的效果，于是提示工程应运而生。

### 核心价值（解决的问题）

提示工程的核心作用，是“低成本激发LLM的潜力”，具体解决了这几个问题：

• 引导模型输出符合预期的格式、风格、角色——比如让模型扮演“产品经理”写需求文档，或扮演“老师”讲解知识点。

• 激发LLM的高级推理能力，最典型的就是“思维链（CoT）”提示——比如让模型解决数学题时，先写出解题步骤，再给出答案，大幅提升推理准确率。

• 减少幻觉、提升事实一致性——通过在提示中加入“要求基于事实，不编造内容”“引用具体来源”等约束，让模型输出更可靠。

### 现存不足

提示工程看似简单，实则有很多局限，至今没有完美的解决方案：

• 提示敏感性极高：措辞的微小变化，可能导致输出结果发生巨大变化（比如把“写一篇短文”改成“写一段短文”，输出长度和风格可能完全不同）。

• 不可控性强：当提示过长（比如几百字的复杂指令），模型可能会忽略部分关键信息，导致输出不符合要求。

• 可扩展性差：当任务增多时，提示会变得越来越复杂、冗长，维护起来非常困难（比如一个多任务提示，修改一个任务的要求，可能会影响其他任务的输出）。

• 无持久记忆：单次提示只能影响单次交互，无法让模型记住“长期意图”（比如你让模型一直扮演“医生”，但下一次交互如果不重新提示，模型就会恢复默认状态）。

三、Fine-tuning（微调）—— 让LLM“专才化”的手段

基础认知：微调（Fine-tuning），是在LLM预训练模型的基础上，用特定领域、特定任务的标注数据，对模型参数进行“小幅更新”，让模型从“通用型”变成“专业型”的技术。简单来说，预训练模型是“通才”，微调就是让它“深耕某个领域”，比如医疗领域的LLM、法律领域的LLM，都是通过微调实现的。

### 背景（2018–2021年，LLM垂直领域应用需求崛起）

随着LLM的普及，大家发现：通用LLM在通用场景（比如聊天、写短文）表现很好，但在垂直领域（比如医疗诊断、法律文书撰写），专业术语掌握不足、输出准确性不够——比如通用LLM可能无法准确区分“肺炎”和“支气管炎”的症状差异，这时候就需要通过微调，让模型学习该领域的专业数据，提升专业能力。

### 解决的核心痛点

• 让通用LLM深度适配垂直领域：通过领域数据微调，模型能掌握该领域的专业术语、业务逻辑，输出更专业、更准确的结果。

• 提升任务稳定性和一致性：微调后，模型在特定任务上的输出波动更小，不会出现“有时准确、有时错误”的情况。

• 降低推理成本：微调后的模型，不需要复杂的提示就能输出符合要求的结果，缩短了响应延迟，减少了token消耗。

### 尚未突破的瓶颈

微调虽然能提升模型的专业能力，但门槛和局限都很明显：

• 成本高昂：需要大量的高质量标注数据（标注数据的成本很高），同时需要强大的算力支持（微调一个大模型，可能需要几台GPU运行几天），中小企业难以承担。

• 灾难性遗忘：微调过程中，模型可能会忘记预训练时掌握的通用能力——比如微调一个医疗LLM后，它可能在医疗领域表现很好，但聊天、翻译等通用场景的表现会大幅下降。

• 泛化能力弱：如果微调数据量少，或者数据覆盖的场景有限，模型很容易出现“过拟合”（只记住了训练数据，遇到新场景就出错）。

• 迭代周期长：从数据准备、标注，到模型训练、评估、部署，整个流程需要几周甚至几个月，无法快速适配快速变化的业务需求。

四、RAG（检索增强生成）—— 解决LLM“失忆”和“说胡话”的神器

基础认知：RAG全称Retrieval-Augmented Generation，即检索增强生成。它的核心逻辑很简单：在LLM生成答案之前，先从外部知识库中检索出与问题相关的信息，再把这些信息作为“参考资料”喂给LLM，让LLM基于参考资料生成答案。相当于给LLM“配了一个外挂知识库”，让它能实时获取最新、最准确的信息。

### 背景（2020年，Lewis等人首次提出，针对性解决LLM核心痛点）

LLM的三大致命痛点——幻觉、知识过时、私有数据无法接入，在2020年前后成为制约其落地的关键。比如企业想让LLM处理内部文档（私有数据），但又不能把私有数据用来训练模型（会泄露信息）；再比如想让LLM回答2024年的新事件，但模型的训练数据截止到2023年。这时候，RAG的出现，完美解决了这些问题——它不需要修改模型参数，只要维护一个外部知识库，就能让LLM获取最新、最私密的信息。

### 核心优势（解决的问题）

• 解决知识过时问题：外部知识库可以随时更新（比如添加2024年的新事件、行业新动态），LLM每次生成答案都能检索到最新信息，无需重训模型。

• 抑制幻觉：LLM的答案基于外部知识库的参考资料生成，每一句话都有来源可追溯、可验证，大幅减少编造事实的情况。

• 安全接入私有数据：企业的私有文档（比如内部规章制度、客户资料）可以存入外部知识库，LLM只检索不存储，避免私有数据泄露。

• 成本可控：维护一个外部知识库（比如用Elasticsearch、Milvus等工具），成本远比重训一个大模型低得多，中小企业也能负担。

### 现存挑战

RAG虽然好用，但也有自己的局限，主要集中在“检索”和“融合”两个环节：

• 检索准确性不足：有时候，模型检索到的信息和问题“语义相似但无关”，或者漏检了关键信息，导致生成的答案不准确。

• 上下文冲突：当检索到多个文档，且文档之间的信息相互矛盾时，LLM难以判断哪个信息是正确的，容易生成混乱的答案。

• 长文本推理弱：面对跨多个文档的复杂问题（比如“整合3篇文档的核心观点，写一份总结”），LLM难以串联起所有信息，容易出现逻辑断裂。

• 入库延迟：新数据（比如刚发布的新闻、新更新的文档）从录入知识库到能被检索到，存在一定的时间差，无法实现“实时检索”。

五、Function Call（函数调用/工具调用）—— 让LLM“动起来”的关键

基础认知：Function Call（函数调用），简单来说，就是让LLM能够“调用外部工具”的技术。它让LLM从“只会说话”的“对话者”，变成了“会做事”的“行动者”——比如LLM可以调用天气API查询实时天气，可以调用数据库查询数据，可以调用邮件工具发送邮件，甚至可以调用代码执行工具运行代码。

### 背景（2023年6月，OpenAI首次在GPT-3.5/GPT-4中支持，开启LLM“工具时代”）

在Function Call出现之前，LLM的能力仅限于“语言生成”——它可以告诉你“如何查天气”，但不能直接帮你查到天气；可以告诉你“如何写代码”，但不能直接运行代码。这种“只能说不能做”的局限，让LLM无法真正落地到实际业务场景（比如自动办公、智能运维）。2023年，OpenAI率先推出Function Call功能，让LLM能够输出结构化的参数，调用外部API，再将调用结果整理成自然语言回答，彻底打破了这种局限。

### 解决的核心问题

• 实现LLM的“行动能力”：让LLM能够执行真实世界的任务，而不仅仅是生成语言内容——比如自动查询订单信息、自动生成报表、自动发送通知。

• 突破静态知识限制：通过调用外部工具，LLM可以获取实时数据（比如实时天气、实时股票价格）、操作外部系统（比如CRM系统、OA系统），不再局限于训练数据中的静态知识。

• 提升开发效率：用LLM的自然语言理解能力，替代传统的“硬编码规则”——比如不需要手动编写“查询天气的代码逻辑”，只要用自然语言告诉LLM“查一下今天的天气”，它就能自动调用天气API。

### 待解决的问题

• 调用不可靠：当用户的需求比较复杂时，LLM可能会选错工具（比如想查天气，却调用了股票API），或者传递错误的参数（比如查询北京的天气，却传递了上海的城市代码）。

• 无统一标准：不同厂商（OpenAI、Anthropic、百度等）的Function Call格式不统一，导致开发的工具无法跨平台适配，迁移成本很高。

• 安全风险：如果对LLM的调用权限没有限制，可能会出现“越权调用”（比如调用删除数据的工具）、“恶意指令执行”（比如调用病毒工具）等安全问题。

• 复杂任务难以支撑：对于多步骤、长周期的任务（比如“先查天气，再根据天气推荐出行方案，最后发送出行通知”），LLM容易出现调用中断、状态丢失的情况。

六、MCP（Model Context Protocol，模型上下文协议）—— 让工具与LLM“无缝对接”

基础认知：MCP全称Model Context Protocol，即模型上下文协议，是Anthropic在2024年11月提出的一项新技术。它的核心是“标准化LLM与外部工具、数据源的对接方式”，相当于给LLM和工具之间“制定了一套通用的沟通规则”，让不同的工具都能按照统一的协议对接LLM，实现“即插即用”。

### 背景（2024年，Function Call生态混乱，适配成本高）

Function Call普及后，出现了一个新的问题：LLM与工具之间是“紧耦合”的——每新增一个工具，都需要修改LLM的提示、调整调用逻辑，甚至重新部署模型。比如你给LLM对接了天气工具，再想对接邮件工具，就需要重新编写提示，告诉LLM如何调用邮件工具，适配成本非常高。而且不同工具的调用格式不统一，导致LLM难以同时对接多个工具。这时候，MCP的出现，就是为了解决“工具适配混乱”的问题。

### 核心价值（解决的问题）

• 统一对接接口：制定一套通用的协议，所有工具都按照这套协议开发，LLM只需要对接一次协议，就能调用所有符合协议的工具，无需重复适配。

• 解耦模型与工具：工具可以独立更新、下线，不需要修改LLM的参数或提示，也不会影响LLM的正常运行——比如更新天气工具的API，不需要重新部署LLM。

• 上下文全程传递：多个工具之间可以通过协议无缝共享上下文信息（比如用户的需求、之前的调用结果），避免状态丢失——比如先调用天气工具获取天气，再调用出行工具，出行工具可以直接获取到之前的天气信息。

• 动态服务发现：LLM在运行时可以自动识别当前可用的工具，根据用户需求灵活选择工具，无需手动配置。

### 现存局限

• 生态不成熟：目前MCP还处于早期阶段，主流模型（比如OpenAI的GPT系列）对它的支持有限，第三方工具适配的也比较少，难以形成规模化应用。

• 性能开销大：MCP采用“Client-Server”的通信模式，工具与LLM之间的通信会增加推理延迟，在高并发场景下，很容易出现性能瓶颈。

• 安全与权限不完善：目前MCP的细粒度访问控制、操作审计机制还不够成熟，容易出现权限泄露、操作不可追溯的问题。

• 学习成本高：相比原生的Function Call，MCP的协议学习、调试、排障难度更高，需要开发者掌握更多的工程知识。

七、Agent（智能体）—— 让LLM“自主完成复杂任务”

基础认知：Agent（智能体），可以理解为“具备自主决策、自主执行能力的LLM应用”。它不是单一的技术，而是集成了“感知→记忆→规划→工具调用→反思”的闭环系统——简单来说，就是让LLM能够“自己想、自己做、自己改”，无需人工分步指导，就能完成复杂的长周期任务。比如“做一份竞品分析报告”，Agent可以自己规划步骤（查竞品信息→整理数据→分析优势劣势→撰写报告），自己调用工具（检索工具、表格工具），自己反思优化（如果数据不全，就重新检索）。

### 背景（2023–2024年，AutoGPT、GPT-4 Agent相继出现，复杂任务需求激增）

随着Function Call的普及，大家发现：单轮工具调用只能完成简单任务（比如查天气、查数据），但对于长周期、多步骤的复杂任务（比如“写一份行业调研报告”“制定一个营销方案”），需要人工分步指导LLM——先让它查资料，再让它整理数据，再让它撰写内容，效率很低。这时候，Agent的出现，就是为了让LLM具备“自主执行复杂任务”的能力，解放人工。

### 解决的核心问题

• 自主完成复杂任务：无需人工分步指导，Agent可以端到端执行长周期、多步骤的任务，从目标设定到结果输出，全程自主决策。

• 长时记忆与状态管理：Agent具备“记忆能力”，可以跨轮次保留用户的意图、历史操作、中间结果——比如你让Agent写报告，中途修改了需求，Agent能记住之前的内容，不会从头开始。

• 动态规划与纠错：Agent可以根据任务目标，自动规划执行步骤；如果执行过程中出现错误（比如检索到错误数据），可以自动反思，调整步骤，重新执行。

### 待突破的瓶颈

• 可靠性低：长任务执行过程中，Agent很容易“跑偏”——比如本来要写行业调研报告，结果中途跑去查无关的信息；或者陷入死循环（比如反复检索同一个数据，无法推进下一步）。

• 上下文窗口瓶颈：Agent执行长任务时，会积累大量的历史信息（步骤、数据、反馈），很容易超出LLM的上下文窗口，导致关键信息丢失、指令遵循度下降。

• 推理成本高：多轮工具调用+大上下文窗口，会导致token消耗大幅增加，同时推理延迟也会显著提升，运行成本很高。

• 不可解释性：Agent的决策过程是“黑盒”——它为什么选择这个工具、为什么调整步骤，很难追溯，一旦出现错误，难以排查原因。

八、Multi-Agent（多智能体）—— 让多个Agent“协同作战”

基础认知：Multi-Agent（多智能体），就是多个Agent组成的“团队”，每个Agent专注于一个细分领域或任务，通过相互通信、分工协作，完成单Agent无法完成的、跨领域、高专业度的复杂任务。比如一个“科研论文评审”任务，可以由“文献检索Agent”“内容分析Agent”“语法校对Agent”“结论评估Agent”组成团队，各司其职，协同完成评审。

### 背景（2024–2025年，单Agent能力局限凸显，跨领域复杂任务需求增加）

单Agent虽然能自主完成复杂任务，但存在一个明显的局限：“术业有专攻”，一个Agent很难同时精通多个领域——比如一个擅长写文案的Agent，可能不擅长数据分析；一个擅长数据分析的Agent，可能不擅长逻辑推理。而现实中的很多任务（比如复杂项目管理、科研论文撰写、跨领域咨询），需要多个领域的专业能力，单Agent难以胜任。这时候，Multi-Agent的出现，就解决了“单Agent能力不足”的问题。

### 核心优势（解决的问题）

• 能力专业化：每个Agent专注于一个细分领域，深度优于广度——比如“医疗Agent”专注医疗领域，“法律Agent”专注法律领域，协同起来就能覆盖多个领域的需求。

• 鲁棒性增强：团队中单个Agent出现故障，不会影响整个任务的推进——比如“文献检索Agent”出错，其他Agent可以暂时替代，或者提醒它纠错，避免单点故障导致任务失败。

• 复杂任务分解：将大型复杂任务拆分为多个小模块，由不同的Agent并行处理，大幅提升任务执行效率——比如“制定营销方案”，可以拆分为“市场调研”“文案撰写”“数据复盘”三个模块，由三个Agent同时执行。

### 现存挑战

• 协调难度大：如何给每个Agent分配合适的角色和任务、如何解决Agent之间的任务冲突（比如两个Agent都认为自己负责某个模块）、如何仲裁不同Agent的意见分歧，都是很难解决的问题。

• 通信开销大：Agent之间需要频繁交互、共享信息，会导致上下文膨胀、推理延迟增加，尤其是在Agent数量较多的情况下，通信成本会急剧上升。

• 全局一致性难：每个Agent都是自主决策，容易出现“局部最优、全局最差”的情况——比如某个Agent为了完成自己的任务，忽略了整个团队的目标，导致最终结果不符合预期。

• 博弈与不稳定：当多个Agent的目标存在冲突时，可能会出现非稳定博弈（比如互相争夺资源、互相干扰），影响任务的正常推进。

九、Context Engineering（上下文工程）—— 解决Agent“记不住、理不清”的问题

基础认知：Context Engineering（上下文工程），是2024–2025年兴起的一项技术，核心是“系统化管理LLM/Agent的上下文全生命周期”——包括上下文的构建、压缩、修剪、记忆、检索。简单来说，就是让Agent在执行长任务时，能够“合理利用有限的上下文窗口”，记住关键信息，丢弃冗余信息，避免出现“记不住、理不清”的情况。

### 背景（2024–2025年，Agent长任务执行痛点凸显）

随着Agent的普及，大家发现一个关键问题：Agent执行长任务时，会积累大量的上下文信息（历史操作、中间结果、工具反馈），而LLM的上下文窗口是有限的，很容易出现“Lost in the Middle”（关键信息被淹没在海量冗余信息中）的情况——比如Agent执行一个10步的任务，到第8步时，已经忘记了第2步的关键数据，导致任务出错。而传统的提示工程，只能优化单次输入，无法解决长上下文的管理问题，于是上下文工程应运而生。

### 解决的核心问题

• 最大化上下文窗口利用率：通过动态压缩、修剪冗余信息（比如重复的操作记录、无关的反馈），把有限的窗口留给关键信息（任务目标、核心数据、关键步骤）。

• 解决长上下文遗忘问题：通过“分层记忆”（短期记忆存储近期操作，长期记忆存储关键信息）+“智能检索”（需要时从长期记忆中检索关键信息），确保关键信息不会丢失。

• 提升指令遵循度：通过突出核心指令、过滤无关信息，让Agent始终围绕任务目标执行，减少“跑偏”的情况。

### 现存不足

• 压缩必然丢失信息：高压缩率会导致细节信息丢失，可能影响Agent的推理精度——比如压缩中间数据时，丢失了某个关键数值，导致后续计算错误。

• 记忆召回不准：长期记忆的检索机制还不够完善，有时候会检索到与当前任务无关的信息，干扰Agent的决策。

• 无通用策略：不同类型的任务（比如创作、代码、推理），需要不同的上下文管理策略（比如创作任务需要保留更多细节，推理任务需要保留更多逻辑步骤），目前没有通用的解决方案，需要针对具体任务定制策略。

• 性能与质量难以平衡：压缩越彻底，上下文窗口利用率越高，推理速度越快，但信息丢失越多，质量越低；反之，质量越高，速度越慢，资源消耗越大。

十、Agent Skill（智能体技能）—— 让Agent“按需加载能力”

基础认知：Agent Skill（智能体技能），是2025年兴起的一项技术，核心是“将Agent的常用能力封装为可复用的模块化组件”。简单来说，就是把Agent需要的能力（比如“文本摘要”“数据可视化”“邮件发送”）做成一个个“技能插件”，Agent可以根据任务需求，按需加载、动态注入这些技能，不需要把所有技能都常驻在上下文窗口中。

### 背景（2025年，Agent能力扩展需求激增，上下文窗口瓶颈凸显）

随着Agent应用场景的丰富，Agent需要掌握的能力越来越多——比如一个办公Agent，需要具备文本编辑、数据统计、邮件发送、会议安排等多种能力。如果把所有这些能力都写入上下文提示，会导致上下文窗口爆炸，推理速度变慢、性能暴跌；如果不写入，Agent又无法完成相应的任务。这时候，Agent Skill的出现，就解决了“能力扩展与上下文窗口限制”的矛盾。

### 核心价值（解决的问题）

• 突破上下文窗口限制：技能不常驻上下文，只有在需要时才加载，避免上下文窗口被冗余能力描述占用，支持Agent“无限”扩展能力。

• 模块化与复用性：技能一次开发，多个Agent可以共享——比如开发一个“文本摘要”技能，所有需要摘要功能的Agent都可以直接使用，无需重复开发，降低开发成本。

• 动态适配任务：Agent可以根据用户的意图，自动识别需要的技能，动态加载并注入上下文，无需人工手动配置——比如用户让Agent“整理会议纪要并发送邮件”，Agent会自动加载“文本摘要”和“邮件发送”技能。

### 待解决的问题

• 技能发现与匹配难：当用户的需求比较模糊时（比如“优化一下这份文档”），Agent难以精准判断需要加载哪些技能（是文本编辑、语法校对，还是格式优化）。

• 技能冲突：当多个技能的指令相互矛盾时（比如一个技能要求“简洁表述”，另一个技能要求“详细表述”），Agent难以取舍，导致输出不符合要求。

• 技能依赖复杂：很多技能之间存在依赖关系（比如“数据可视化”技能需要依赖“数据统计”技能的结果），如何管理技能之间的依赖、确保技能加载顺序正确，是很大的挑战。

• 学习成本高：技能的设计、封装、测试，需要开发者掌握模块化开发、上下文管理等工程能力，入门门槛较高。

十一、OpenClaw—— 开源Agent开发的“脚手架”

基础认知：OpenClaw是2025–2026年出现的一款开源Agent脚手架（Harness），可以理解为“Agent开发的一站式工具包”。它集成了Context Engineering（上下文管理）、Agent Skill（技能机制）、记忆管理、工具编排等核心功能，提供了标准化的Agent开发架构和接口，让开发者无需从零搭建Agent，开箱即用，大幅降低Agent的开发门槛。

### 背景（2025–2026年，Agent开发门槛高、生态混乱）

随着Agent的普及，越来越多的企业和开发者想要开发自己的Agent，但面临两个核心问题：一是Agent开发需要整合上下文管理、技能封装、工具调用等多个模块，技术复杂度高，入门门槛高；二是没有统一的开发标准，不同开发者开发的Agent架构不统一、接口不兼容，难以复用和协作。这时候，OpenClaw作为开源的Agent脚手架，应运而生，旨在解决“Agent开发难、不标准”的问题。

### 核心优势（解决的问题）

• 标准化Agent开发：提供统一的架构、接口和最佳实践，开发者不需要从零设计Agent的核心模块，只需专注于业务逻辑和技能开发，大幅降低入门门槛。

• 内置上下文引擎：集成了可插拔的上下文压缩、修剪、记忆策略，开发者可以直接使用，无需自己开发上下文管理功能，解决长上下文痛点。

• Skill原生支持：内置技能注册、发现、加载、执行的全链路管理机制，开发者可以轻松开发、复用技能，提升开发效率。

• 可观测与调试：内置日志、追踪、评估工具，开发者可以实时监控Agent的执行过程，快速排查错误，提升Agent的可靠性和可维护性。

### 现存局限

• 框架锁定：开发者一旦使用OpenClaw开发Agent，就会强依赖OpenClaw的生态，后续如果想迁移到其他Agent框架（比如LangChain），成本很高。

• 性能开销：OpenClaw的多层抽象和插件化设计，会增加一定的推理延迟和资源消耗，在高并发、低延迟的场景下，性能可能不够理想。

• 生态与文档不完善：目前OpenClaw还处于早期阶段，第三方技能、工具的适配数量较少，官方文档和学习资料也不够完善，开发者学习和调试的成本较高。

• 复杂场景适配弱：在超大规模、高并发、强安全要求的场景（比如企业级智能运维Agent）下，OpenClaw的稳定性和安全性还有待验证。

十二、Harness Engineering（脚手架工程/驾驭工程）—— 给Agent“套上缰绳”

基础认知：Harness Engineering（脚手架工程/驾驭工程），是2025–2026年兴起的一项系统级技术，核心是“对Agent的全生命周期进行管控与约束”。简单来说，就是给Agent“套上缰绳”，确保Agent在执行任务时，能够稳定、可控、可恢复，不会出现“失控”“跑偏”“死循环”等问题。它和OpenClaw的区别在于：OpenClaw是“开发脚手架”，专注于降低开发门槛；Harness Engineering是“管控脚手架”，专注于提升Agent的稳定性和可控性。

### 背景（2025–2026年，Agent规模化落地，稳定性与可控性成为关键）

随着Agent在企业级场景中规模化落地，大家发现：Agent在执行长周期、复杂任务时，很容易出现失控情况——比如偏离任务目标、陷入死循环、执行错误操作（比如删除重要数据），而且一旦出现错误，很难恢复。而Context Engineering解决的是“信息供给”问题，无法解决“执行管控”问题。这时候，Harness Engineering的出现，就是为了给Agent提供系统级的管控，确保Agent能够安全、稳定地执行任务。

### 核心价值（解决的问题）

• 全流程管控：对Agent的输入（用户需求）、推理（决策过程）、工具调用（操作行为）、输出（任务结果）、反思（纠错过程）进行全闭环监控与约束，确保每一步操作都符合预期。

• 防止Agent跑偏：通过运行时行为校验、目标对齐、异常拦截等机制，实时监测Agent的执行状态，一旦发现Agent偏离任务目标，就及时干预、纠正。

• 错误自愈：自动检测Agent执行过程中的故障（比如工具调用失败、数据错误），并自动执行回滚状态、重试操作、降级处理等策略，提升Agent的鲁棒性，减少人工干预。

• 可观测与审计：提供全链路追踪、日志记录、行为评估等功能，所有操作都可追溯，满足企业级场景的合规需求，同时方便开发者排查错误。

### 待解决的问题

• 管控与灵活的平衡难：如果管控过于严格，会限制Agent的自主决策能力和创造力（比如Agent想优化执行步骤，却被管控规则拦截）；如果管控过于宽松，又无法避免Agent失控，很难找到一个平衡点。

• 策略复杂度高：不同类型、不同场景的Agent，需要不同的管控规则（比如办公Agent和运维Agent的管控重点不同），规则的设计、维护成本很高。

• 性能损耗：实时监控、行为校验等操作，会增加Agent的推理延迟和资源消耗，在高并发场景下，性能瓶颈会比较明显。

• 无通用标准：目前Harness Engineering的管控逻辑高度定制化，不同企业、不同开发者的管控方案差异很大，难以复用和规模化推广。

十三、 未来：AI时代，人类的核心竞争力

1. 把经验变成代码：别做只会干活的“老黄牛”，要做会定规矩的“架构师”。凡是能被写成SOP的，就绝不亲自动手，全部甩给AI去跑。

2. 做穿透迷雾的“狙击手”：AI能给你一堆数据，但只有你能一眼看出“本质”。在海量信息中一针见血地抓到逻辑，这是人类最后的护城河。

3. 把AI当“外包”而非“替身”：你是老板，AI是你的超级实习生。脏活累活AI干，决策、审美、搞关系这些“高价值区”，必须死死攥在自己手里。

4. 用“进化”对抗“淘汰”：工具迭代的速度就是你的生死线。别死守旧地图，时刻更新你的“人机协作手册”，谁适应得快，谁就拥有降维打击的能力。

最后：技术演进总览（帮大家梳理脉络）

我们可以把这些技术的演进，分为6个阶段，清晰看到整个LLM生态的发展逻辑：

1. 2020年前：LLM诞生，奠定整个生态的基础（核心是“拥有通用语言能力”）；

2. 2020–2022年：Prompt Engineering、Fine-tuning兴起，核心是“优化LLM的输入和参数，让通用模型更好用”；

3. 2023年：RAG、Function Call出现，核心是“解决LLM的知识和行动局限，让模型能获取新信息、能执行任务”；

4. 2024年：Agent、MCP出现，核心是“让LLM能自主执行复杂任务，让工具对接更标准化”；

5. 2025年：Multi-Agent、Context Engineering、Agent Skill出现，核心是“让Agent能协同作战、能高效管理上下文、能灵活扩展能力”；

6. 2026年：OpenClaw、Harness Engineering出现，核心是“降低Agent开发门槛，提升Agent的稳定性和可控性，推动规模化落地”。

总结来说，整个LLM生态的发展，都是围绕“解决LLM的局限、提升Agent的能力、降低开发和落地门槛”展开的，未来也会继续朝着“更智能、更稳定、更易用”的方向发展。

Andrej Karpathy 大神（OpenAI早期核心成员，前特斯拉AI Director）分享了自己如何使用LLM搭建知识库的方法。

传统 RAG的致命缺点是“无状态”和“失忆”：每次你问问题，LLM 都要重新在文档里大海捞针，且不能累积知识。Karpathy 的方案抛弃了RAG这一套，让 LLM 把原始资料“编译（Compile）”成一个结构化的 Wiki。

因为Karpathy并没有给出具体的prompt或者skill，也没有标准实现或固定工具链，而是只提供了一个“idea file”（模式说明），目前具体的实现方法大多都是社区中补全出来的。我来为大家讲解具体的实现步骤，所用到的工具，以及我根据Karpathy的理念编写的skills和约束，以及注意事项。

样例GitHub仓库：jason-effi-lab/karpathy-llm-wiki-vault。

核心理念

Andrej Karpathy 的 LLM Wiki 理念可以精简为**“将知识管理视为软件工程”，其核心逻辑是从“即时检索” (RAG) 转向“持续编译” (Compilation)。

以下是该理念的高效准确描述：

1. 核心转换：从检索到编译

• 传统 RAG： 像临时翻书。每次提问都从原始文档中重新搜寻碎片，知识不积累，无状态。
• LLM Wiki： 像编译代码。在数据摄入时就通过 LLM 进行深度合成与链接，将零散资料转化成结构化的、有状态的持久制品。

2. 三层架构 (The 3-Layer Architecture)

这一模式通过严格的目录结构确保知识的准确性与可维护性：

• raw/ (不可变源层)： 存放原始论文、笔记、网页剪藏。它是事实之源，LLM 只读不写，确保可追溯性。
• wiki/ (已编译制品层)： 由 LLM 全权维护的 Markdown 页面。包含概念、实体摘要及其间的双向链接。这是知识库的“执行文件”。
• Schema (治理层)： 即 CLAUDE.md 或 AGENTS.md。它是 LLM 的作业规范，定义了文件命名、元数据格式及更新工作流，使 AI 成为纪律严明的图书管理员。

3. 三大核心操作 (The Loop)

• 摄入 (Ingest)： 新资料进入时，LLM 会更新 10-15 个相关 Wiki 页面，修正旧观点，标记新矛盾。
• 查询 (Query)： 优先通过 index.md 索引导航，实现精准查询。高质量的回答会回填（File back）到 Wiki 中，实现知识复利。
• 审计 (Lint)： AI 定期执行“体检”，寻找逻辑冲突、孤儿页面或知识缺口，保持系统健康。

4. 终极比喻

“Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库”。
人类负责决策与提供素材，LLM 负责枯燥的簿记与维护工作（Bookkeeping）。最终形成一个随着阅读量增加而自动进化的私有化 Wikipedia。

知识库架构

最终生成的知识库架构如下，这里以Claude Code + claudian插件为例，你也可以使用OpenCode, Gemini CLI等智能体。

基于 Karpathy 的 LLM Wiki 理念构建，结合 Claude Code 体系。

🏛️ 你的知识库文件夹 (LLM-Wiki-Vault)
├── 🖼️ assets/                   ← 统一媒体资源层：存放图片、PDF、附件（Obsidian设置附件路径至此）
│
├── 📥 raw/                      ← 原始资料收件箱（只读事实层，文件处理后移动至 archive）
│   ├── 📄 01-articles/          ← 网页剪藏、技术文章 (.md)
│   ├── 🎓 02-papers/            ← 论文、深度研报、PDF文档
│   ├── 🎙️ 03-transcripts/       ← 视频/播客转录文本、会议记录
│   ├── 💡 04-meeting_notes/     ← 头脑风暴或会议纪要等
│   └── 🗃️ 09-archive/           ← 已归档区：`/ingest` 执行成功后，源文件自动移动至此
│
├── 🧠 wiki/                     ← 知识编译输出层（LLM 拥有完全写权限，人类阅读层）
│   ├── 📑 index.md              ← 全局内容字典：记录所有 wiki 页面及其一句话索引
│   ├── 📜 log.md                ← 行为流水线：以 Grep-friendly 格式记录 ingest/query 历史
│   ├── 🏗️ concepts/             ← 抽象层：方法论、架构模式、第一性原理 
│   ├── 👥 entities/             ← 实体层：人名、公司、工具软件、项目 
│   ├── 🔍 sources/              ← 摘要层：针对 raw 文件的一对一核心观点提炼 
│   └── 💎 syntheses/            ← 综合层：针对复杂提问生成的深度研究报告 
│
├── 🤖 CLAUDE.md                 ← 全局心智规范：定义语言协议、读写权限与 Wiki Schema
│
└── ⚙️ .claude/                  ← Claude Code 官方配置目录
    └── 🛠️ skills/               ← Agent Skill中心
        ├── ⚙️ ingest/           ← 自定义：编译收件箱 raw 文件到 wiki，并执行 09-archive 归档
        ├── 🔎 query/            ← 自定义：检索 wiki/index 并读取相关页面，生成带双链引用的回答
        ├── 🩺 lint/             ← 自定义：知识体检，修复死链、补充 index、发现认知冲突
        ├── 🔌 obsidian-cli/     ← Obsidian官方：调用 Obsidian 原生 API 进行检索、打开页面
        └── 🪄 defuddle/         ← Obsidian官方：将网页 URL 自动清理并转化为 Markdown 存入 raw/

CLAUDE.md内容如下：

# 语言设定与核心角色 (Global Rules)
- **语言指令**：无论输入何种语言，你必须始终使用**简体中文**进行思考、回复和知识库的编写。
- **角色定义**：你正在维护一个 **LLM Wiki**（根据 [Karpathy 的规范](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f))，你的任务是将碎片化的信息编译成结构化、高度相互链接的 Obsidian 知识库。

# 核心目录与权限边界 (Immutability & Architecture)
你必须严格遵守以下文件操作权限，这是不可逾越的底线：

- `/raw/` (不可变层 - Immutable)：
  - **绝对只读**。这里存放我的原始素材、网页剪藏和自媒体文案。
  - **禁止修改或删除此目录下的任何文件**。它是事实的唯一真相来源。
- `/assets/` (媒体资产层)：
  - 存放图片、PDF和媒体。引用时使用 Obsidian 标准语法 `![[文件名称.png]]`。
- `/wiki/` (编译输出层 - You Own This)：
  - 这是你的专属工作区。你需要在此处创建、更新、提炼知识并解决矛盾。

# Wiki 核心文件契约 (The Wiki Schema)
当你在 `/wiki/` 中工作时（尤其是执行写入操作后），必须维护以下基石：

1. **`wiki/index.md` (总目录)**：
   每次向 wiki 新增知识页后，必须同步更新此文件，将其按分类加入目录中。
   格式要求： [[页面名称]] — 一句话描述。
    - Entities/Concepts: 使用 TitleCase 命名。
    - Sources/Syntheses: 使用 kebab-case 命名。
    范例：
    ```markdown
    # Wiki Index

    ## Sources
    - [[摘要-source-slug]] — 该资料的核心主旨摘要。

    ## Entities
    - [[EntityName]] — 该实体的身份定义或核心功能。

    ## Concepts
    - [[ConceptName]] — 该概念或框架的核心定义。

    ## Syntheses
    - [[synthesis-slug]] — 该页面回答的复杂问题。
    ```
2. **`wiki/log.md` (操作日志)**：
    只能追加写入（Append-only）。每次操作后记录：`## [YYYY-MM-DD] <动作> | <操作简述>`。
    操作类型： ingest, query, lint, sync
    范例：
    ```markdown
    ## [2026-04-11] ingest | 引入项目 Claude Code 核心概念
    - **变更**: 新增 [[ClaudeCode]], [[摘要-claude-code-docs]]; 更新 [[index.md]]
    - **冲突**: 无 (或: 冲突 [[RAG架构]], 已标注)

    ## [2026-04-11] query | 解析 Karpathy LLM-Wiki 理念
    - **输出**: 已保存至 [[分析-karpathy-wiki-philosophy]]

    ## [2026-04-11] lint | 周度健康检查
    - **结果**: 修复 2 处死链，发现 1 个孤儿页面 [[UnlinkedPage]]
    ```
3. **内容分类**：
   - `/wiki/concepts/`：存放概念、框架、方法论（如 `Agent_Skill.md`）。
   - `/wiki/entities/`：存放人物、公司、工具、产品（如 `Claude_Code.md`）。
   - `/wiki/sources/`：存放从 `raw/` 提炼出的原始素材摘要。
4. **强制双向链接**：
   每一个 wiki 页面必须包含 `## 关联连接` 区域，使用 Obsidian 双链 `[[页面名称]]` 链接到其他相关概念。绝不能产生孤岛页面。
5. **矛盾处理原则**：
   如果新摄入的知识与旧知识冲突，不要静默覆盖。在页面中新建 `## 知识冲突` 区块，将两种说法都保留并做对比。

# 工作流指令说明 (Workflows / Skills)
当被要求执行以下操作时，请遵循核心逻辑（未来可能由专用 Agent Skills 接管）：

- `/ingest <路径>`：读取指定的 `raw/` 文件，将其核心价值提炼并整合到 `wiki/` 目录的相关概念/实体中。必须更新 index 和 log。
- `/query <问题>`：通过读取 `wiki/index.md` 寻找相关文件，进行深度阅读后综合回答，并在回答中必须使用 `[[wikilink]]` 标注引用来源。
- `/lint`：全局扫描 `wiki/` 目录，找出孤岛页面（没有双链）、死链（链接不存在的页面）以及存在逻辑冲突的地方，并向我报告。

# 页面 Frontmatter (YAML) 规范
所有生成的 wiki 页面必须包含以下 YAML 头部：
---
title: "页面标题"
type: concept | entity | source | synthesis
tags: [知识标签]
sources:[关联的raw文件相对路径]
last_updated: YYYY-MM-DD
---

第一步：数据摄入 - 原始资料收集

这一步是唯一需要人类手动进行的步骤。Karpathy重度依赖 Obsidian Web Clipper 官方剪藏插件，一键将网页提取为干净的 Markdown 格式。
涉及工具： Obsidian, Obsidian Web Clipper，Defuddle/Defuddle skill。

• 安装Obsidian并创建知识库，在知识库中创建/raw文件夹，作为数据摄入的入口。（我一般都起名叫/inbox，一个意思）
• 在浏览器中安装Obsidian Web Clipper官方剪藏插件，在插件设置中，指定剪藏笔记保存的路径为你的OB仓库/raw。
• 你也可以使用defuddle工具和defuddle skill来进行知识的摄入，具体我之前的视频中有讲。他们都是Obsidian CEO @kepano写的。官方Web Clipper插件底层也是Defuddle。
• 必须是 .md 文件吗？不能是 PDF 或电子书吗？：可以，但 Karpathy 强烈推荐将网页剪藏为 .md 格式，因为 Markdown 是LLM的“母语”，解析效率最高，Token 消耗最少，且格式非常干净。

第二步：LLM 自动化编译与构建（Ingest）

LLM 读取原始数据，自动提取概念、生成总结，并在 wiki/ 文件夹下生成带有 YAML frontmatter（元数据）和双向链接的新 Markdown 文件。
涉及工具：Claude Code（或其他智能体工具，比如OpenCode），obsidian-cli skill。

• 你可以直接发送提示词给Claude Code，但是，这样的步骤显然更应该使用skill。
• 以下是我编写的ingest-skill，核心功能就是把/raw里的资料整理成wiki。在智能体中直接执行/ingest即可触发。

ingest-skill内容如下：

---
name: ingest
description: 将 raw/ 目录下的原始资料编译到 wiki/ 中。处理完成后，将源文件自动移动到 raw/09-archive/ 归档。支持 `/ingest` (扫描 raw/ 下所有未归档文件) 或 `/ingest <path>` (处理指定文件)。当用户提到"摄取"、"导入"、"收入"资料，或要求将文件加入知识库时，也应该触发此技能。绝对忽略 raw/09-archive/ 目录。
user-invocable: true
---

# ingest 技能

## 核心工作流：Inbox & Archive

你正在维护一个 **LLM Wiki**（Obsidian 知识库）。`raw/` 目录是"待处理收件箱"，`wiki/` 是"编译输出层"。

**目录结构约定：**
- `raw/01-articles/` — 网页剪藏的 Markdown 文章
- `raw/02-papers/` — 论文和 PDF 文献
- `raw/03-transcripts/` — 视频转录文案
- `raw/09-archive/` — **已处理文件的归档目录，禁止读取**
- `wiki/sources/` — 资料摘要
- `wiki/entities/` — 实体（人物、公司、工具、产品）
- `wiki/concepts/` — 概念（框架、方法论、理论）

## 触发逻辑

1. **用户执行 `/ingest`**：扫描 `raw/` 所有子目录（排除 `09-archive/`），找出待处理文件。
2. **用户执行 `/ingest <path>`**：仅处理指定文件。
3. **隐式触发**：用户说"把这个资料摄入知识库"、"导入这篇文章"时，自动执行 ingest。

## 编译流水线

对每个待处理源文件，严格按以下步骤执行：

### 步骤 1：读取源文件

- **如果是 `.md` 文件**：使用读取工具完整读取内容。
- **如果是 `.pdf` 文件**：使用读取工具尝试提取文本。如果无法提取或内容为空，改为记录文件元信息（文件名、页数）在 sources 页面中。

### 步骤 2：提炼核心并翻译

从源文件中提取：
- **核心主旨**：这段资料讲什么（1-2句话）
- **实体**：人物、公司、工具、产品等具体名词
- **概念**：框架、方法论、理论等抽象名词

如果是非中文内容，则翻译成中文。

### 步骤 3：创建来源摘要

在 `wiki/sources/` 创建 Markdown 文件：

```markdown
---
title: "摘要-文件slug"
type: source
tags: [来源, 原始文件]
sources: [raw/01-articles/xxx.md]
last_updated: YYYY-MM-DD
---

## 核心摘要
[3-5句话的核心总结]

## 关联连接
- [[EntityName]] — 关联实体
- [[ConceptName]] — 关联概念
```

文件名使用 kebab-case：`摘要-{文件slug}.md`

### 步骤 4：知识网络化（实体/概念页面）

对于步骤 2 提取的每个实体和概念：

**目标目录：**
- 实体 → `wiki/entities/`
- 概念 → `wiki/concepts/`

**处理逻辑：**
1. 页面不存在 → 按照 CLAUDE.md 的 Frontmatter 规范创建新页面
2. 页面已存在 → 读取现有内容，**增量合并**新信息
3. **发现冲突** → **立即暂停**，向用户报告冲突内容，询问处理方式后再继续

**页面模板：**

```markdown
---
title: "页面名称"
type: entity | concept
tags: [标签]
sources: [关联的源文件]
last_updated: YYYY-MM-DD
---

## 定义
[对该实体/概念的定义]

## 关键信息
[从源文件中提取的详细信息]

## 关联连接
- [[摘要-source-slug]] — 来源
- [[RelatedEntity]] — 相关实体
```

### 步骤 5：更新全局注册表

**更新 `wiki/index.md`：**
按照 CLAUDE.md 规定的格式，将新增页面添加到对应分类下：
- Sources: `[[摘要-source-slug]] — 该资料的核心主旨`
- Entities: `[[EntityName]] — 该实体的身份定义`
- Concepts: `[[ConceptName]] — 该概念的核心定义`

**更新 `wiki/log.md`：**
追加操作日志（Append-only）：
```markdown
## [YYYY-MM-DD] ingest | 操作简述
- **变更**: 新增 [[PageName]]; 更新 [[index.md]]
- **冲突**: 无 (或: 冲突 [[ConflictingPage]], 已暂停等待决策)
```

### 步骤 6：归档源文件

在确认以下全部完成后，将源文件移动到 `raw/09-archive/`目录：
- sources 页面已创建
- 实体/概念页面已创建或更新
- index.md 已更新
- log.md 已更新

**绝对禁止修改源文件内部的文字。**

## 冲突处理流程

当发现新旧知识冲突时：

1. **暂停**：停止当前 ingest 流程
2. **报告**：向用户说明冲突内容（哪个页面、冲突点是什么）
3. **询问**：请用户选择处理方式：
   - A) 保留新旧两者，标注为"知识冲突"
   - B) 用新知识覆盖旧知识
   - C) 放弃本次 ingest
4. **继续**：根据用户选择继续或终止

## 注意事项

- 绝对不读取 `raw/09-archive/` 下的任何文件
- 所有 wiki 页面必须包含 `## 关联连接` 区域，不能产生孤岛页面
- 使用简体中文编写所有内容
- 实体命名使用 TitleCase，概念和来源使用 kebab-case

第三步：深度查询与知识复利

面对特定课题，让 LLM 进行跨文档的综合研究，并将高质量的分析结果存回知识库，实现知识的增量与结网。
涉及工具： Claude Code（或其他智能体工具，比如OpenCode），marp（obsidian插件，或skill），json-canvas（也有skill，我之前讲过）等等。

这一步是RAG吗？可以用NotebookLM吗？
绝对不能，恰恰相反，Karpathy的理念恰恰是为了对抗RAG 和 NotebookLM。
核心思想：Wiki > RAG
RAG（包括 NotebookLM）是“无状态”的：系统本身没有记忆，知识没有积累。 你今天问，它搜一遍；明天问，它还要再搜一遍。它是一个“只读（Read-only）”的阅览室。
Karpathy 的 Agentic Wiki 是“有状态”和“编译”的：构建一个持续进化的知识库（LLM Wiki），知识是“被编译”的，而不是“临时检索”的。当你提问时，Agent 是在阅读已经被提炼过的网络结构，并将高质量的问答结果存回知识库中。

案例一：矛盾点挖掘

对比我知识库里 OpenClaw 和 Claude Code 这两个工具的所有测试笔记。
列出它们在处理长文本项目时的底层机制差异。
如果发现这两者的能力有重叠或互斥，请明确指出。将分析结果生成对比表格，存入 wiki/comparisons/。

案例二：盲区发现

审视我过去三个月关于‘Agent开发’的所有知识节点。
作为一名 15 年经验的全栈开发者，帮我指出我在架构选型、优化或部署思路上，还有哪些信息的严重缺失？
列出我下一步应该去摄入的 3 个方向。

提问后，你可以命令 Agent：“把刚才的对比分析转化为 Marp 格式的幻灯片，并存入 wiki/comparisons/ ”。下次打开 Obsidian，你就能直接看到排版好的 PPT。同样你也可以生成canvas, excalidraw等。

query-skill内容如下：

---
name: query
description: 在本地 Wiki 知识库中回答用户提问。当用户使用 /query 命令、或用自然语言询问关于"我的笔记/历史决定/过往笔记/知识库"中的内容时调用。必须先读取 wiki/index.md 定位相关页面，再深度阅读，最后以双链引用格式回答。禁止凭模型记忆回答。如果知识库中没有相关内容，必须声明"本地知识库中未找到，以下为通用知识回答"。
user-invocable: true
---

# query 技能

## 核心目标
将用户的提问转化为对本地 Wiki 的深度检索。提取相关页面信息，综合出带有明确引用来源的双链回答。当回答具有高价值时，主动将其固化为知识库的一部分。

## 触发场景
- 用户输入 `/query <问题>`
- 用户用自然语言询问：`"我的笔记里关于 X 是怎么说的"`、`"过去我对 Y 的决策是什么"`、`"查询 Z 相关的知识"`
- 用户提及 wiki、知识库、笔记、记录等关键词

## 降级策略
如果问题属于纯通用知识（如"太阳系有几颗行星"），且 wiki/index.md 中无相关内容：
>本地知识库中未找到相关内容，以下为通用知识回答：[直接回答]

---

## 检索与综合流水线

### 步骤 1：查阅全局索引
**永远的第一步**：读取 `wiki/index.md`

在 index.md 中定位与问题相关的：
- Entities（实体）
- Concepts（概念）
- Sources（摘要）
- Syntheses（综合）

### 步骤 2：深度阅读目标文件
选取步骤 1 中找到的最相关页面，使用读取工具获取完整内容。

### 步骤 3：综合与回答
综合信息，回答用户问题。

**双链引用规范**：
- 每当引用某个 Wiki 页面的信息，在文本中使用 `[[页面名称]]` 标注
- 整段引用同一页面：段落首尾各引用一次
- 引用特定原文：使用 Markdown 块引用 `> 引用内容`

### 步骤 4：高价值内容固化
如果满足以下条件，主动询问用户是否保存为 synthesis：
- 回答超过 2 个段落
- 内容具有分析对比性或总结性

询问话术：
>这是一个有价值的总结，是否需要我将其保存到 wiki/syntheses/ 目录？

用户同意后，按照 CLAUDE.md 规范创建文件：
```markdown
---
title: "页面标题"
type: synthesis
tags: []
sources: []
last_updated: YYYY-MM-DD
---

# 总结内容
```

并在 `wiki/index.md` 的 Syntheses 分类下注册。

### 步骤 5：记录操作日志
无论是否生成 synthesis 页面，查询结束后必须在 `wiki/log.md` 末尾追加：

```markdown
## [YYYY-MM-DD] query | <操作简述>
- **输出**: <引用页面列表或"即时回答未保存">
```

格式必须完全遵循 CLAUDE.md 中的示例。

---

## 强制约束
- **禁止凭记忆回答**：必须先检索知识库
- **禁止过度引用**：同一页面的信息在段落首尾引用一次即可
- **禁止静默回答**：知识库无相关内容时必须声明

---

## 关联连接
- [[wiki/index.md]] — 全局索引入口
- [[wiki/log.md]] — 操作日志
- [[CLAUDE.md]] — Wiki 架构总规范

第四步：知识库维护（Lint）

定期对知识库进行体检，排查知识库中的逻辑断层、自相矛盾或死链接。这也是为什么我用了lint这个程序员专属词汇。
涉及工具： Claude Code（或其他智能体工具，比如OpenCode），lint-skill（自己编写）。

以下是我编写的lint-skill。

---
name: lint
description: 知识库全局健康度检查。扫描 wiki/ 目录，检测死链（页面引用不存在的双链）、孤儿页面（无任何页面引用它）、未同步索引（文件存在但未在 index.md 注册）和知识冲突。当用户输入 /lint、/scan、/health 或要求“检查知识库状态”、“检查健康”时调用。
user-invocable: true
---

# lint 技能：知识图谱健康巡检

## 核心目标
将软件工程中的“静态代码分析”引入知识管理。定期运行此 skill，找出知识库长期演进中产生的：死链、孤岛、未同步索引、认知冲突。

## 触发条件
- 用户输入 `/lint`
- 用户询问“我的知识库健康状况如何”
- 用户要求“检查知识库状态”或“检查健康”

## 知识库路径
- 使用 Glob 工具动态定位当前工作区下的 wiki/ 目录

## 巡检流水线

### 第 1 步：索引一致性检查
1. 读取 `wiki/index.md` 全部内容
2. 扫描 `wiki/` 下所有 `.md` 文件（排除 index.md 和 log.md）
3. 提取 index.md 中注册的所有双链链接 `[[页面名称]]`
4. 比对：找出已注册但文件不存在的条目 OR 文件存在但未注册的页面

### 第 2 步：双向链接健康检查
1. 扫描所有 `.md` 文件，提取所有 `[[双链]]` 格式的链接
2. 如果链接指向的页面不存在 → 标记为**死链**
3. 统计被引用的页面（排除 self-reference）
4. 找出从未被任何其他页面引用的页面 → **孤儿页面**

### 第 3 步：认知冲突审查
1. 全局搜索所有 `.md` 文件中包含 `## 知识冲突` 的页面
2. 提取每个冲突的简要描述（冲突双方是什么）
3. 统计带未解决冲突的页面（认知技术债）

### 第 4 步：收件箱积压检查（可选跳过）
- 本 skill 仅扫描 wiki/，跳过 raw/ 收件箱检查

## 报告输出规范

扫描完成后，输出结构化报告，严格遵循以下格式：

```markdown
## 🩺 知识库健康体检报告 — YYYY-MM-DD

### ✅ 绿灯项
- [运行良好的项目]

### ⚠️ 黄灯项
- **发现 N 个孤儿页面**：[列表] - 建议添加关联或分类
- **发现 N 个未同步索引**：[列表] - 文件存在但未在 index.md 注册

### ❌ 红灯项
- **发现 N 个死链**：[来源页面] → [[不存在的目标页面]]
- **存在 N 个未解决的知识冲突**：[页面名称]

### 🛠️ 下一步行动
1. 是否需要自动修复未同步索引？
2. 是否需要针对知识冲突进行重新推演？
```

## 硬约束
- **仅读扫描**：生成报告前，禁止修改、删除、重命名任何文件
- **手动确认**：报告后等待用户确认再执行修复
- **静默日志**：修复完成后，在 wiki/log.md 追加 `## [YYYY-MM-DD] lint | 修复了 N 个问题`
```

注意事项与风险

上下文窗口：Karpathy 表示目前的方案在 40万字 级别运行良好。但如果你要把这个工作流扩大，每次重新编译或深度 Query 时，都需要把巨大的知识树推入大模型的上下文窗口，无论是使用 Claude 还是 Gemini API，这会导致极高的 Token 开销（API 成本不可控）。
高昂的 Token 成本：智能体的操作非常消耗token。即便我在skill中加入了技能链，使用了obsidian-cli skill，但每次更新如果都要把关联的十几个文件和系统 Prompt 推给大模型，你的 API 费用依旧会暴增。
AI幻觉：这是这套系统最致命的缺陷。由于整个 Wiki 由 LLM 自动化编译并相互链接，如果大模型在某次处理中产生了幻觉（伪造了某个数据或联系），这个错误会被写成 Markdown 永久固化在知识库中。未来的推理会以此为“事实基石”，导致错误指数级放大。

我的看法

Karpathy只给出了理论，并没有给出具体实现，目前社区中也都是根据其理论来进行技术补全。
但总体说来，Karpathy的核心理念，描绘的是个人知识管理（PKM）必然的终极形态——人类只做高价值的信息筛选与战略提问，AI 接管所有繁琐的节点编织。
反传统RAG，让知识库系统拥有了持久化状态，知识才开始产生复利。

最后，还是要强调一点：注意Token消耗，注意Token消耗，注意Token消耗！

Karpathy原文翻译

英文原文：llm-wiki

# LLM Wiki

一种利用 LLM 构建个人知识库的模式。

这是一个理念文件，旨在供你复制并粘贴到你自己的 LLM 代理（例如 OpenAI Codex、Claude Code、OpenCode / Pi 等）中。它的目标是传达高层级的核心理念，而具体的构建细节将由你的代理与你协作完成。

## 核心理念

大多数人对 LLM 和文档的体验类似于 RAG（检索增强生成）：你上传一堆文件，LLM 在查询时检索相关的片段，然后生成答案。这种方式可行，但 LLM 在回答每个问题时都是从零开始重新发现知识，没有知识的积累。如果问一个需要综合五份文档的微妙问题，LLM 每次都必须重新寻找并拼凑相关碎片。没有任何东西被沉淀下来。NotebookLM、ChatGPT 的文件上传以及大多数 RAG 系统都是这样运作的。

这里的理念则不同。LLM 不仅仅是在查询时从原始文档中检索，而是**增量地构建并维护一个持久化的 Wiki** —— 这是一个位于你和原始资料之间的、结构化的、互相关联的 Markdown 文件集合。当你添加新资料时，LLM 不只是为了以后的检索而对其进行索引，而是阅读它，提取关键信息，并将其整合到现有的 Wiki 中 —— 更新实体页面、修订主题摘要、记录新数据与旧主张的矛盾之处，从而强化或挑战不断演进的综合认知。知识被“编译”一次后便*保持更新*，而不是在每次查询时重新推导。

这就是关键区别：**Wiki 是一个持久化的、具有复利效应的工件。** 交叉引用已经建立，矛盾点已被标记，综合综述已经反映了你所读过的一切。随着你添加的每一份资料和提出的每一个问题，Wiki 都会变得更加丰富。

你永远（或极少）亲自编写 Wiki —— LLM 负责编写和维护所有内容。你负责提供资料、探索和提出正确的问题。LLM 负责所有的苦活累活 —— 摘要、交叉引用、归档和簿记，正是这些工作让知识库随着时间的推移变得真正有用。在实践中，我一边打开 LLM 代理，另一边打开 Obsidian。LLM 根据我们的对话进行编辑，我实时浏览结果 —— 点击链接、查看关系图谱、阅读更新后的页面。Obsidian 是 IDE；LLM 是程序员；Wiki 则是代码库。

这可以应用于许多不同的场景。例如：

- **个人**：跟踪你自己的目标、健康、心理、自我提升 —— 归档日记条目、文章、播客笔记，并随着时间的推移建立起关于你自己的结构化画像。
- **研究**：在数周或数月内深入研究某个主题 —— 阅读论文、文章、报告，并增量地构建一个带有演进论点的全面 Wiki。
- **阅读书籍**：边读边归档每一章，构建角色、主题、情节线索及其关联的页面。读完后，你就拥有了一个丰富的配套 Wiki。想想看像 [Tolkien Gateway](https://tolkiengateway.net/wiki/Main_Page) 这样的粉丝 Wiki —— 成千上万个互相关联的页面，涵盖了角色、地点、事件、语言，由志愿者社区耗时多年建成。你可以在阅读时个人化地构建类似的东西，而所有的交叉引用和维护工作都由 LLM 完成。
- **业务/团队**：由 LLM 维护的内部 Wiki，数据源自 Slack 讨论帖、会议记录、项目文档、客户电话。可能由人工参与审核更新。Wiki 能保持最新，是因为 LLM 完成了团队中没人想做的维护工作。
- **竞争分析、尽职调查、旅行规划、课程笔记、爱好深挖** —— 任何涉及知识长期积累且需要组织有序（而非零散）的场景。

## 架构

分为三个层级：

**原始资料 (Raw sources)** —— 你策划的源文档集合。文章、论文、图片、数据文件。这些是不可变的 —— LLM 只从中读取，绝不修改。这是你的“事实来源”。

**Wiki** —— 一个由 LLM 生成的 Markdown 文件目录。包含摘要、实体页面、概念页面、对比分析、概览、综合综述。LLM 完全拥有这一层。它创建页面，在新资料到达时更新页面，维护交叉引用，并保持一切一致性。你负责阅读，LLM 负责编写。

**架构规范 (The schema)** —— 一个说明文档（例如 Claude Code 的 `CLAUDE.md` 或 Codex 的 `AGENTS.md`），告诉 LLM Wiki 是如何结构的、有哪些惯例，以及在摄入资料、回答问题或维护 Wiki 时应遵循的工作流。这是关键的配置文件 —— 正是它让 LLM 成为一名纪律严明的 Wiki 维护者，而不是一个通用的聊天机器人。随着你逐渐摸索出适合自己领域的方案，你和 LLM 会共同演进这份文档。

## 操作

**摄入 (Ingest)**。你将新资料放入原始集合中，并告诉 LLM 进行处理。一个典型的流程：LLM 阅读资料，与你讨论关键要点，在 Wiki 中编写摘要页，更新索引，更新整个 Wiki 中相关的实体和概念页面，并在日志中追加一条记录。一份资料可能会触及 10-15 个 Wiki 页面。就个人而言，我更喜欢逐个摄入资料并保持参与 —— 我阅读摘要、检查更新，并引导 LLM 重点关注哪些内容。但你也可以在较少监督的情况下批量摄入多份资料。由你决定适合自己风格的工作流，并将其记录在架构规范中供未来会话使用。

**查询 (Query)**。你针对 Wiki 提出问题。LLM 搜索相关页面，阅读并综合出带有引用来源的答案。答案可以根据问题采取不同的形式 —— Markdown 页面、对比表格、幻灯片 (Marp)、图表 (matplotlib)、画布 (canvas)。重要的洞察：**好的答案可以作为新页面重新归档到 Wiki 中。** 你要求的对比、分析或发现的关联都是有价值的，不应消失在聊天历史中。这样，你的探索过程就会像摄入的资料一样，在知识库中产生复利。

**巡检 (Lint)**。定期要求 LLM 对 Wiki 进行“健康检查”。检查内容包括：页面之间的矛盾、已被新资料取代的陈旧主张、没有入向链接的孤立页面、提到了但缺乏独立页面的重要概念、缺失的交叉引用、可以通过网络搜索填补的数据空白。LLM 擅长建议新的调查问题和寻找新资料。这能确保 Wiki 在增长过程中保持健康。

## 索引与日志

两个特殊文件帮助 LLM（以及你）在 Wiki 增长时进行导航。它们用途各异：

**index.md** 是以内容为导向的。它是 Wiki 中所有内容的目录 —— 列出每个页面及其链接、一行简短摘要，以及可选的元数据（如日期或来源数量）。按类别组织（实体、概念、来源等）。LLM 在每次摄入时都会更新它。在回答查询时，LLM 首先阅读索引以寻找相关页面，然后深入挖掘。这在中等规模（约 100 份资料，数百个页面）下表现出奇地好，且避免了对基于嵌入 (Embedding) 的 RAG 基础设施的需求。

**log.md** 是按时间顺序排列的。它是一个只增记录，记录了何时发生了什么 —— 摄入、查询、巡检。一个有用的技巧：如果每个条目都以一致的前缀开始（例如 `## [2026-04-02] ingest | 文章标题`），日志就可以用简单的 Unix 工具解析 —— `grep "^## \[" log.md | tail -5` 可以让你看到最后 5 条记录。日志为你提供了 Wiki 演进的时间线，并帮助 LLM 了解最近完成了哪些工作。

## 可选：CLI 工具

在某些时候，你可能想构建一些小工具来帮助 LLM 更高效地操作 Wiki。对 Wiki 页面进行搜索引擎是最显而易见的需求 —— 在小规模下，索引文件就足够了，但随着 Wiki 的增长，你需要真正的搜索。[qmd](https://github.com/tobi/qmd) 是一个不错的选择：它是一个用于 Markdown 文件的本地搜索引擎，具有 BM25/向量混合搜索和 LLM 重排序功能，全部在本地运行。它既有 CLI（以便 LLM 可以调用 shell 命令），也有 MCP 服务器（以便 LLM 可以将其作为原生工具使用）。你也可以自己构建更简单的东西 —— 随着需求产生，LLM 可以帮你“直觉驱动式编程 (vibe-code)”一个简单的搜索脚本。

## 提示与技巧

- **Obsidian Web Clipper** 是一个浏览器扩展，可将网页文章转换为 Markdown。对于快速将资料存入原始集合非常有用。
- **本地下载图片**。在 Obsidian 设置 → 文件与链接中，将“附件默认存放路径”设置为固定目录（例如 `raw/assets/`）。然后在设置 → 快捷键中，搜索“下载”找到“下载当前文件的附件”并绑定快捷键（例如 Ctrl+Shift+D）。剪藏文章后，按下快捷键，所有图片都会下载到本地磁盘。这是可选的，但很有用 —— 它让 LLM 可以直接查看和引用图片，而不是依赖于可能失效的 URL。注意，LLM 无法在一次读取中原生阅读带有内嵌图片的 Markdown —— 解决方法是让 LLM 先读文本，然后根据需要单独查看部分或全部引用的图片以获取额外上下文。虽然有点笨重，但效果不错。
- **Obsidian 的关系图谱 (Graph view)** 是查看 Wiki 形态的最佳方式 —— 哪些是相连的，哪些页面是核心枢纽，哪些是孤立页面。
- **Marp** 是一种基于 Markdown 的幻灯片格式。Obsidian 有相关插件。适合直接从 Wiki 内容生成演示文稿。
- **Dataview** 是一个 Obsidian 插件，可以在页面前置数据 (frontmatter) 上运行查询。如果你的 LLM 为 Wiki 页面添加了 YAML 前置数据（标签、日期、来源计数），Dataview 可以生成动态表格和列表。
- Wiki 本质上只是一个 Markdown 文件的 Git 仓库。你可以免费获得版本历史、分支功能和协作支持。

## 为什么这种模式有效

维护知识库最枯燥的部分不是阅读或思考，而是“簿记”工作：更新交叉引用、保持摘要最新、记录新旧数据的冲突、维持几十个页面的一致性。人类往往会放弃维护 Wiki，因为维护负担的增长速度超过了其价值。LLM 不会感到厌倦，不会忘记更新交叉引用，并且可以一次性修改 15 个文件。Wiki 能够维持下去，是因为维护成本几乎为零。

人类的工作是策划资料、指导分析、提出好问题，并思考这一切意味着什么。LLM 的工作是除此之外的一切。

这个理念在精神上与 Vannevar Bush 的 Memex (1945) 相关 —— 一个私人的、经过策划的知识存储器，文档之间具有联想路径。Bush 的愿景与此更为接近，而不是现在的互联网：私密的、积极策划的，且文档之间的关联与文档本身同样具有价值。他无法解决的部分是谁来负责维护，而 LLM 解决了这个问题。

## 注意事项

本文档刻意保持抽象。它描述的是一种理念，而非特定的实现。具体的目录结构、架构惯例、页面格式、工具链 —— 所有这些都取决于你的领域、你的偏好以及你选择的 LLM。上述提到的所有内容都是可选的和模块化的 —— 挑选有用的，忽略没用的。例如：你的资料可能全是文本，所以完全不需要处理图片。你的 Wiki 可能足够小，只需索引文件即可，不需要搜索引擎。你可能不在乎幻灯片，只想要 Markdown 页面。你可能想要一套完全不同的输出格式。使用本模式的正确方法是将其分享给你的 LLM 代理，共同协作实例化一个符合你需求的版本。本文档唯一的任务是传达这种模式，剩下的交给你的 LLM。

目录

1. 教程说明：适合谁学习

2. 学习路线：从基础到进阶

3. 核心配置：AGENTS.md 工作规范

4. 记忆优化：构建可靠的记忆体系

5. 子 Agent 应用：团队协作模式

6. 定时任务：Cron 自动化实践

7. Skill 开发：扩展 AI 能力

8. 多渠道部署：全平台接入方案

9. 性能调优：配置参数详解

10. 实战练习清单

11. 疑难解答

12. 进阶学习资源

教程说明：适合谁学习

学习前提

本教程面向已经完成 OpenClaw 基础配置的用户。在开始之前，请确认你已经：

✅ 成功安装 OpenClaw 并能正常运行✅ 完成基本配置文件的创建（SOUL.md / USER.md / IDENTITY.md）✅ 了解记忆系统的基本概念（MEMORY.md 和 memorySearch）✅ 熟悉 workspace 目录结构✅ 具备基本的命令行操作能力

如果上述条件尚未满足，建议先阅读 你的OpenClaw是不是有点呆， 几步调教让你的 AI 助手脱胎换骨

技术要求

• OpenClaw 已安装并正常运行

• 至少一个 AI 模型 API（Claude 或 GPT）

• 理解 JSON 和 Markdown 格式

• 基本的文件系统操作能力

你将学到什么

完成本教程后，你的 OpenClaw 将实现以下能力提升：

学习路线：从基础到进阶

推荐学习顺序

第一阶段：工作规范建立（30-60 分钟）

• 创建 AGENTS.md 工作手册

• 定义 session 启动流程

• 设置记忆写入规范

• 配置安全边界

第二阶段：记忆系统优化（60-120 分钟）

• 启用 memoryFlush 防止信息丢失

• 优化日志格式提升检索精度

• 配置自动维护机制

• 调整 embedding 模型

第三阶段：高级功能应用（120-240 分钟）

• 部署子 Agent 实现任务分发

• 创建 Cron 定时任务

• 开发自定义 Skill

• 配置多渠道接入

第四阶段：性能调优（1-2 天）

• 调整模型参数

• 优化 token 使用

• 配置缓存策略

• 监控系统性能

学习建议

1. 循序渐进：不要跳过基础步骤，每个配置都有其作用

2. 实践验证：每完成一个配置，立即测试验证效果

3. 记录问题：遇到问题及时记录，便于后续排查

4. 备份配置：重要修改前备份配置文件

核心配置：AGENTS.md AI打工守则

为什么需要 AGENTS.md

在基础教程中，我们创建了描述 AI 性格的 SOUL.md、描述用户信息的 USER.md、以及定义身份的 IDENTITY.md。但这些文件只解决了“AI 是谁”和“用户是谁”的问题，并没有告诉 AI“如何工作”。

AGENTS.md 的作用是定义 AI 的工作流程和行为准则，类似于员工手册。它告诉 AI：

• 每次启动时应该读取哪些文件

• 记忆应该如何组织和存储

• 哪些操作需要用户确认

• 如何处理不同类型的任务

类比说明：

• SOUL.md → 个人性格档案

• USER.md → 服务对象信息

• IDENTITY.md → 身份标识

• AGENTS.md → 工作流程手册

Session 启动配置

OpenClaw 每次启动新会话时都处于“初始状态”，需要通过读取文件来恢复记忆和上下文。合理的启动流程可以确保 AI 快速进入工作状态。

配置文件位置： workspace/AGENTS.md

启动流程配置：

Session 启动流程

每次会话开始时，按以下顺序自动执行：

1. 读取 `SOUL.md` - 加载性格和行为风格
2. 读取 `USER.md` - 了解用户背景和偏好
3. 读取 `memory/YYYY-MM-DD.md` - 加载今天和昨天的日志
4. 如果是主会话：额外读取 `MEMORY.md` - 加载核心记忆索引

以上操作无需询问，自动执行。

配置说明：

步骤 1-2：加载基础信息 SOUL.md 和 USER.md 通常很小（<1KB），每次都读取不会造成性能负担。这两个文件确保 AI 知道自己的角色定位。

步骤 3：加载近期日志读取今天和昨天的日志文件，可以让 AI 快速了解最近发生的事情。之所以包含昨天的日志，是因为如果当前时间是凌晨，今天的日志可能还是空的。

步骤 4：条件加载核心记忆 MEMORY.md 可能包含敏感信息（如服务器配置、API 密钥等），因此只在主会话中加载。OpenClaw 支持多种会话类型：

• 主会话：用户直接对话（如 Discord 私聊、WebChat）

• 群聊会话：多人群组对话

• 子 Agent 会话：子任务执行会话

• Cron 会话：定时任务触发的会话

AI 会自动识别当前会话类型，你只需在 AGENTS.md 中定义规则即可。

记忆管理规范

OpenClaw 的记忆系统采用分层设计，不同类型的信息存储在不同的文件中。在 AGENTS.md 中明确定义记忆管理规范，可以确保信息被正确归档。

记忆层级结构：

## Memory

You wake up fresh each session. These files are your continuity.

### 记忆分层

| 层级 | 文件 | 用途 |
| --- | --- | --- |
| 索引层 | `MEMORY.md` | 关于用户、能力概览、记忆索引。保持精简(<40行) |
| 项目层 | `memory/projects.md` | 各项目当前状态与待办 |
| 基础设施层 | `memory/infra.md` | 服务器、API、部署等配置速查 |
| 教训层 | `memory/lessons.md` | 踩过的坑，按严重程度分级 |
| 日志层 | `memory/YYYY-MM-DD.md` | 每日原始记录 |

### 写入规则

-   **日志**：当天发生的事写入 `memory/YYYY-MM-DD.md`，格式：

【项目：名称】 事件标题

• 结果：一句话概括

• 相关文件：文件路径

• 经验教训：要点（如有）

• 检索标签：#tag1 #tag2

**分层写入规则：**

- 当天发生的事情 → 写入 `memory/YYYY-MM-DD.md`
- 项目状态变更 → 同步更新 `memory/projects.md`
- 遇到问题和解决方案 → 记录到 `memory/lessons.md`
- 核心信息变更 → 更新 `MEMORY.md` 索引

**重要原则：**

- 记录结论而非过程
- 使用标签便于检索
- 保持 MEMORY.md 精简（<40 行）
- 想要记住的信息必须写入文件，不要依赖"记在脑子里"

日志质量对比：

❌ 低质量日志示例：

### 今天的工作

今天配置了服务器，先试了方案 A 但是不行，报错了。然后又试了方案 B，
还是有问题。最后用了方案 C，花了两个小时终于搞定了。配置文件在
/etc/config/app.conf 里面。明天还要继续调试其他功能。

✅ 高质量日志示例：

### [项目:WebApp] 服务器部署完成

- **结果**：使用 Nginx 反向代理部署成功，监听 443 端口
- **相关文件**：`/etc/nginx/sites-available/webapp.conf`
- **经验教训**：方案 A 和 B 失败原因是端口冲突，必须使用反向代理
- **检索标签**：#webapp #nginx #部署

高质量日志的优势：

1. 信息密度高，一眼就能看到关键结论

2. 标签便于后续用 memorySearch 检索

3. 结构化格式便于 AI 解析和理解

安全和权限边界

定义清晰的安全边界可以防止 AI 执行危险操作或泄露敏感信息。

## 安全规范

### 基本原则

- 不得泄露私人数据和敏感信息
- 执行破坏性操作前必须确认
- 删除文件使用 `trash` 而非 `rm`（可恢复优于永久删除）
- 不确定时，先询问用户

### 操作权限分类

**可以自由执行的操作：**
- 读取文件、浏览目录
- 搜索网络信息
- 查询日历和邮件
- 在 workspace 内部工作

**需要用户确认的操作：**
- 发送邮件、推文、公开消息
- 任何向外部发送数据的操作
- 删除或修改重要文件
- 不确定后果的操作

### 群聊行为规范

在群聊环境中：
- 你可以访问用户的文件和记忆，但不能在群聊中分享
- 你是群聊的参与者，而非用户的代言人
- 不要替用户发言或泄露用户的私人信息

完整 AGENTS.md 模板

以下是可以直接使用的完整模板，保存为 workspace/AGENTS.md：

# AGENTS.md - 工作空间规范

这是你的工作空间，请按照以下规范工作。

## Session 启动流程

每次会话开始时，按以下顺序自动执行：

1. 读取 `SOUL.md` - 加载性格和行为风格
2. 读取 `USER.md` - 了解用户背景和偏好
3. 读取 `memory/YYYY-MM-DD.md` - 加载今天和昨天的日志
4. 如果是主会话：额外读取 `MEMORY.md` - 加载核心记忆索引

以上操作无需询问，自动执行。

## 记忆管理规范

你每次启动都是全新状态，这些文件是你的记忆延续。

| 层级 | 文件路径 | 存储内容 |
|------|---------|---------|
| 索引层 | `MEMORY.md` | 核心信息和记忆索引，保持精简 |
| 项目层 | `memory/projects.md` | 各项目当前状态和待办 |
| 经验层 | `memory/lessons.md` | 问题解决方案，按重要性分级 |
| 日志层 | `memory/YYYY-MM-DD.md` | 每日详细记录 |

### 写入规则

- 日志写入 `memory/YYYY-MM-DD.md`，记录结论而非过程
- 项目变更时同步更新 `memory/projects.md`
- 遇到问题时记录到 `memory/lessons.md`
- MEMORY.md 仅在索引变化时更新
- 重要信息必须写入文件，不要依赖记忆

### 日志格式
【项目：名称】 事件标题
结果：一句话概括
相关文件：文件路径
经验教训：要点（如有）
检索标签：#tag1 #tag2
## 安全规范

- 不得泄露私人数据
- 破坏性操作前必须确认
- 使用 `trash` 而非 `rm`
- 不确定时先询问

**可自由执行：** 读取文件、搜索、整理、在 workspace 内工作  
**需要确认：** 发送邮件/消息、任何向外发送数据的操作

## 群聊规范

你可以访问用户的文件和记忆，但不能在群聊中分享。
在群聊中，你是参与者，不是用户的代言人。

## 工具使用

Skills 提供你的工具能力。需要使用某个工具时，查看其 SKILL.md 文档。

📋 实践任务 1：创建 AGENTS.md

任务目标：

1. 在 workspace 根目录创建 AGENTS.md 文件

2. 复制上面的模板并根据你的实际需求调整

3. 重启 OpenClaw 并验证配置是否生效

验证方法：

• 开启一个新会话

• 观察 AI 是否自动读取了指定的文件

• 让 AI 记录一件事，检查是否写入了正确的文件和格式

✅ 完成标准：

• AGENTS.md 文件创建成功

• AI 能够按照规范自动读取记忆文件

• AI 写入的日志符合指定格式

记忆优化：构建可靠的记忆体系

现状分析

在完成基础教程后，你的 OpenClaw 已经具备了基本的记忆功能：

• 分层记忆结构（MEMORY.md + memory/*.md）

• 语义检索功能（memorySearch）

但在实际使用中，可能会遇到以下问题：

问题 1：长对话后 AI “失忆”当对话内容超过上下文窗口限制时，OpenClaw 会自动压缩旧对话，这个过程可能导致重要信息丢失。

问题 2：检索命中率不理想日志格式不统一、缺少标签、信息密度低，导致 memorySearch 难以找到相关内容。

问题 3：记忆文件缺乏维护随着时间推移，过期信息堆积，噪音增加，影响检索质量。

本章将逐一解决这些问题。

启用 memoryFlush 功能

问题场景：

你和 AI 进行了长时间的深度讨论，制定了重要决策。突然发现 AI 的回复开始变得“健忘”，好像忘记了之前讨论的内容。

原因分析：

每个 AI 模型都有上下文窗口限制（例如 Claude 是 200K tokens）。当对话接近这个限制时，OpenClaw 会触发自动压缩（compaction），将旧对话总结成摘要以腾出空间。压缩过程可能会丢失细节信息。

解决方案：

启用 memoryFlush 功能。该功能会在压缩触发前，先让 AI 将重要信息写入文件，然后再执行压缩。

工作流程：

1. OpenClaw 检测到上下文即将达到限制

2. 触发 memoryFlush，提示 AI 保存重要信息

3. AI 将关键内容写入 memory/ 目录

4. 执行压缩，清理旧对话

5. 重要信息已持久化，不会丢失

配置方法：

编辑 openclaw.json，添加以下配置：

{
  "agents": {
    "defaults": {
      "compaction": {
        "reserveTokensFloor": 20000,
        "memoryFlush": {
          "enabled": true,
          "softThresholdTokens": 4000
        }
      }
    }
  }
}

参数说明：

关于 softThresholdTokens:

这个值设置为 4000 意味着：当剩余空间不足 4000 tokens 时触发 memoryFlush。

• 太小（如 1000）：AI 没有足够空间写入详细信息

• 太大（如 10000）：会频繁触发，影响性能

• 4000 是经过测试的平衡值

效果验证：

启用后，即使进行长时间对话，AI 也能保持对之前讨论内容的记忆，因为关键信息已经持久化到文件中。

提示： memoryFlush 是静默执行的，不会打断对话。如果想查看触发情况，可以启用 verbose 模式（发送 /verbose 命令），会看到 Auto-compaction complete 的提示。

优化日志格式提升检索精度

memorySearch 使用向量语义检索技术，将搜索词和日志内容都转换为向量，然后计算相似度。

提升检索精度的关键因素：

1. 使用标签：标签（如 #deploy #nginx）可以显著提升召回率

2. 结构化格式：固定的格式使关键信息集中，便于匹配

3. 单一主题：一条日志只记录一件事，避免信息混杂

实际效果对比：

假设搜索词为：“nginx 部署配置”

低效日志（命中率低）：

今天工作内容：上午处理了数据库备份问题，中午部署了新版本应用，
下午修改了 nginx 配置，晚上写了一些文档。nginx 那边改了反向代理
的配置，具体记不太清了，反正最后跑起来了。

问题：

• 包含多个不相关主题，稀释了向量相似度

• 缺少结构化信息，关键点不突出

• 没有标签，难以精准匹配

高效日志（命中率高）：

### [项目:WebApp] Nginx 反向代理配置

- **结果**：成功配置 Nginx 反向代理，应用通过 443 端口访问
- **相关文件**：`/etc/nginx/sites-available/webapp.conf`
- **经验教训**：upstream 必须使用 127.0.0.1 而非 localhost（避免 IPv6 问题）
- **检索标签**：#nginx #deploy #webapp #reverse-proxy

优势：

• 标题、结果、标签都包含搜索关键词

• 结构化格式使信息密度高

• 单一主题，向量表示更准确

配置自动记忆维护

问题：

随着使用时间增长，日志文件会不断累积。其中一些信息已经过期（如临时调试记录、已完成的一次性任务），这些“噪音”会干扰 memorySearch 的检索结果。

解决方案：

配置定期自动维护任务，让 AI 自己整理记忆。

实现方法：

在 workspace/HEARTBEAT.md 中添加维护任务：

## 记忆维护任务（每周执行）

检查 `memory/heartbeat-state.json` 中的 `lastMemoryMaintenance` 字段。

如果距今超过 7 天，执行以下维护流程：

1. 读取最近 7 天的日志文件 `memory/YYYY-MM-DD.md`
2. 提炼有长期价值的信息，归档到对应文件：
   - 项目决策和状态 → `memory/projects.md`
   - 问题解决方案 → `memory/lessons.md`
3. 压缩已完成的一次性任务为一行总结
4. 删除完全过期的临时信息
5. 更新 `heartbeat-state.json` 中的 `lastMemoryMaintenance` 为当前日期

创建状态跟踪文件 workspace/memory/heartbeat-state.json：

{
  "lastMemoryMaintenance": "2026-02-26"
}

维护操作说明：

提炼（Extract）：将日志中有长期价值的信息移动到对应的层级文件。

示例：日志中记录了一个项目的技术选型决策，应该提炼到 projects.md 中。

压缩（Compress）：将已完成的详细任务记录压缩为简短的结论。

示例：

• 压缩前：详细记录了部署过程的 10 个步骤

• 压缩后：2026-02-17: 完成 WebApp 生产环境部署，使用 Nginx + Docker 方案

清理（Clean）：删除完全过期的临时信息。

示例：

• “明天要参加会议” → 会议已过，可以删除

• “测试中的临时配置” → 测试已完成，可以删除

配置 Embedding 模型

memorySearch 依赖 embedding 模型将文本转换为向量。选择合适的模型可以提升检索质量并降低成本。

推荐配置：

{
  "memorySearch": {
    "enabled": true,
    "provider": "openai",
    "remote": {
      "baseUrl": "https://api.siliconflow.cn/v1",
      "apiKey": "你的_SiliconFlow_API_Key"
    },
    "model": "BAAI/bge-m3"
  }
}

为什么选择 bge-m3：

• 成本：SiliconFlow 提供免费额度，个人使用足够

• 多语言：对中英文混合文本支持良好

• 性能：向量维度 1024，在精度和速度间取得平衡

获取 SiliconFlow API Key:

1. 访问 siliconflow.cn 注册账号

2. 进入控制台，创建 API Key

3. 免费额度：每天数百万 tokens，个人使用完全足够

memorySearch 工作流程：

用户提问：“上次 nginx 配置问题怎么解决的？”

1. AI 调用 memory_search(“nginx 配置问题”)

2. memorySearch 返回最相关的几条结果（包含文件路径和行号）

3. AI 调用 memory_get(path="memory/2026-02-18.md", from=47, lines=10)

4. AI 读取具体内容并回答用户

这种两步走的设计很高效：search 负责“定位”，get 负责“读取”，避免加载所有记忆文件。

📋 实践任务 2：优化记忆系统

任务目标：

1. 启用 memoryFlush 功能

2. 按照优化后的格式重写最近 3 条日志

3. 配置自动维护任务

4. 切换到 bge-m3 embedding 模型

验证方法：

• 进行一次长对话（超过 100 轮），观察是否出现失忆

• 使用 memorySearch 搜索之前记录的内容，检查命中率

• 等待一周后检查自动维护是否执行

✅ 完成标准：

• memoryFlush 配置已启用

• 日志格式符合优化标准

• 自动维护任务配置完成

• embedding 模型切换成功

子 Agent 应用：团队协作模式

什么是子 Agent

在基础配置中，OpenClaw 是单线程工作的：你提出一个任务，AI 从头到尾完成。但对于复杂任务，这种模式效率很低。

子 Agent 的概念：

子 Agent 是主 Agent 派生出的独立工作进程，可以并行执行不同的子任务。

类比：

• 单 Agent 模式：你是项目经理，所有工作都自己做

• 多 Agent 模式：你是项目经理，可以派遣团队成员并行工作

适用场景

场景 1：信息收集任务

任务：收集 5 个竞品的功能对比

• 单 Agent：顺序访问 5 个网站，耗时 10 分钟

• 多 Agent：派 5 个子 Agent 并行收集，耗时 2 分钟

场景 2：数据处理任务

任务：分析 100 个文件的内容

• 单 Agent：逐个处理，耗时很长

• 多 Agent：分配给 10 个子 Agent，每个处理 10 个文件

场景 3：监控任务

任务：同时监控多个服务的状态

• 单 Agent：轮询检查，响应慢

• 多 Agent：每个服务分配一个监控 Agent

配置子 Agent

基础配置：

编辑 openclaw.json：

{
  "agents": {
    "defaults": {
      "subAgents": {
        "enabled": true,
        "maxConcurrent": 3,
        "timeout": 300000
      }
    }
  }
}

参数说明：

关于 maxConcurrent:

这个值不是越大越好：

• 太小（如 1）：无法发挥并行优势

• 太大（如 10）：可能触发 API 速率限制，增加成本

• 推荐 3-5：在性能和成本间取得平衡

使用子 Agent

方法 1：自动派遣

AI 会自动判断任务是否适合并行处理。

示例对话：

用户：帮我收集这 5 个网站的主要功能：[网站列表]

AI：我将派遣 5 个子 Agent 并行收集信息...
[子 Agent 1] 正在分析网站 A...
[子 Agent 2] 正在分析网站 B...
...
所有信息已收集完成，正在整理汇总...

方法 2：显式指定

你也可以明确要求使用子 Agent：

用户：使用子 Agent 并行处理这个任务...

子 Agent 最佳实践

5. 任务分解要合理

好的分解：

• 将“分析 100 个文件”分解为 10 个子任务，每个处理 10 个文件

不好的分解：

• 将“写一篇文章”分解为多个子任务（写作需要连贯性，不适合并行）

6. 设置合理的超时时间

根据任务复杂度调整 timeout：

• 简单查询：60 秒

• 数据分析：5 分钟

• 复杂处理：10 分钟

7. 监控并发数

使用 /status 命令查看当前运行的子 Agent 数量，避免过载。

8. 成本控制

子 Agent 会增加 API 调用次数，注意监控成本。

📋 实践任务 3：子 Agent 实战

任务目标：

1. 启用子 Agent 功能

2. 完成一个并行任务（如信息收集）

3. 观察执行效率提升

练习任务：

选择以下任务之一进行练习：

1. 收集 5 个竞品的定价信息

2. 分析 10 个网页的关键词

3. 检查 5 个服务的在线状态

✅ 完成标准：

• 子 Agent 配置已启用

• 成功完成至少一个并行任务

• 理解子 Agent 的适用场景

定时任务：Cron 自动化实践

Cron 任务概述

Cron 是 OpenClaw 的定时任务功能，可以让 AI 在指定时间自动执行任务，无需人工触发。

典型应用场景：

• 每日简报：每天早上发送天气、日程、新闻摘要

• 定期备份：每周自动备份重要文件

• 监控告警：每小时检查服务状态，异常时通知

• 定时提醒：工作日下午 6 点提醒结束工作

创建 Cron 任务

方法 1：通过对话创建

用户：创建一个定时任务，每天早上 8 点发送今日简报

AI：我将为你创建定时任务...
- 任务名称：daily-briefing
- 执行时间：每天 08:00
- 任务内容：发送天气、日程、新闻摘要
已创建成功！

方法 2：手动配置

编辑 workspace/crons/daily-briefing.json：

{
  "name": "daily-briefing",
  "schedule": "0 8 * * *",
  "timezone": "Asia/Shanghai",
  "task": {
    "type": "message",
    "content": "发送今日简报：天气、日程、重要新闻"
  },
  "enabled": true
}

Cron 表达式说明：

格式：分钟 小时 日期 月份 星期

常用示例：

在线工具：crontab.guru 可以帮助你生成和验证 cron 表达式。

Cron 任务示例

示例 1：每日早报

{
  "name": "morning-briefing",
  "schedule": "0 8 * * *",
  "timezone": "Asia/Shanghai",
  "task": {
    "type": "message",
    "content": "早安！今日简报：
1. 查询天气
2. 读取今日日程
3. 总结昨日工作日志
4. 提醒今日待办事项"
  },
  "enabled": true
}

示例 2：工作日晚间提醒

{
  "name": "evening-reminder",
  "schedule": "0 18 * * 1-5",
  "timezone": "Asia/Shanghai",
  "task": {
    "type": "message",
    "content": "工作日结束提醒：
1. 总结今日完成的任务
2. 记录未完成事项
3. 规划明日工作"
  },
  "enabled": true
}

示例 3：每周总结

{
  "name": "weekly-summary",
  "schedule": "0 17 * * 5",
  "timezone": "Asia/Shanghai",
  "task": {
    "type": "message",
    "content": "周五晚间总结：
1. 回顾本周工作日志
2. 统计完成的任务数量
3. 整理下周计划"
  },
  "enabled": true
}

示例 4：服务监控

{
  "name": "service-monitor",
  "schedule": "*/30 * * * *",
  "timezone": "Asia/Shanghai",
  "task": {
    "type": "check",
    "content": "检查以下服务状态：
1. 网站是否可访问
2. API 响应时间
3. 数据库连接
如有异常立即通知"
  },
  "enabled": true
}

管理 Cron 任务

查看所有任务：

查看所有任务：

openclaw cron list

启用/禁用任务：

openclaw cron enable daily-briefing
openclaw cron disable daily-briefing

删除任务：

openclaw cron remove daily-briefing

手动触发任务（测试用）：

openclaw cron run daily-briefing

Cron 任务最佳实践

4. 合理设置执行频率

• 不要过于频繁（如每分钟执行），会增加成本

• 根据实际需求设置（监控可以 5-10 分钟，简报每天一次即可）

5. 设置时区

确保 timezone 字段设置正确，否则任务可能在错误的时间执行。

6. 任务内容要具体

不要写“发送简报”，而要写“发送简报：天气、日程、新闻”，让 AI 知道具体要做什么。

7. 测试后再启用

创建任务后，先用 openclaw cron run 手动触发测试，确认无误后再启用自动执行。

8. 监控执行日志

定期检查 workspace/logs/cron.log，确认任务正常执行。

📋 实践任务 4：创建定时任务

任务目标：

1. 创建至少 2 个 Cron 任务

2. 测试任务是否正常执行

3. 观察一周的自动化效果

推荐任务：

1. 每日早报（早上 8 点）

2. 工作日晚间提醒（下午 6 点）

3. 每周总结（周五下午）

✅ 完成标准：

• 成功创建至少 2 个 Cron 任务

• 手动触发测试通过

• 任务已启用并自动执行

Skill 开发：扩展 AI 能力

Skill 系统概述

Skill 是 OpenClaw 的能力扩展机制，类似于插件或应用。每个 Skill 定义了一组特定的任务和工作流程。

Skill 的作用：

• 封装复杂的工作流程

• 定义专业领域的任务模板

• 提供可复用的能力模块

Skill 类型：

1. 官方 Skill：OpenClaw 团队维护的标准 Skill

2. 社区 Skill：用户分享的第三方 Skill

3. 自定义 Skill：你自己开发的 Skill

Skill 文件结构

一个标准的 Skill 包含以下文件：

workspace/skills/my-skill/
├── SKILL.md          # Skill 说明文档
├── config.json       # 配置文件
└── templates/        # 模板文件（可选）

创建简单 Skill

示例：天气查询 Skill

创建文件 workspace/skills/weather-check/SKILL.md：

# 天气查询 Skill

## 功能描述

查询指定城市的天气信息并格式化输出。

## 使用方法

用户：查询北京天气

AI 执行流程：
1. 调用天气 API 获取数据
2. 提取关键信息：温度、天气状况、空气质量
3. 格式化输出

## 输出格式
📍 北京天气
🌡️ 温度：15°C
☁️ 天气：多云
💨 风力：3 级
🌫️ 空气质量：良


## 配置要求

需要配置天气 API Key：
- 提供商：OpenWeatherMap
- 配置路径：config.json

创建配置文件 workspace/skills/weather-check/config.json：

{
  "name": "weather-check",
  "version": "1.0.0",
  "description": "查询城市天气信息",
  "author": "你的名字",
  "config": {
    "apiKey": "你的_API_Key",
    "apiUrl": "https://api.openweathermap.org/data/2.5/weather",
    "defaultCity": "Beijing"
  }
}

安装和使用 Skill

安装 Skill:

openclaw skill install ./workspace/skills/weather-check

使用 Skill:

用户：使用天气查询 Skill 查询上海天气

AI：正在调用天气查询 Skill...
📍 上海天气
🌡️ 温度：18°C
☁️ 天气：晴
💨 风力：2 级
🌫️ 空气质量：优

高级 Skill 示例

示例：任务管理 Skill

创建 workspace/skills/task-manager/SKILL.md：

# 任务管理 Skill

## 功能

- 添加任务
- 查看任务列表
- 标记任务完成
- 删除任务

## 数据存储

任务存储在 `workspace/data/tasks.json`

## 命令格式

- 添加任务：`添加任务：[任务描述]`
- 查看任务：`查看任务` 或 `任务列表`
- 完成任务：`完成任务：[任务 ID]`
- 删除任务：`删除任务：[任务 ID]`

## 工作流程

### 添加任务

1. 解析任务描述
2. 生成唯一 ID
3. 添加到 tasks.json
4. 确认添加成功

### 查看任务

1. 读取 tasks.json
2. 按状态分类（进行中/已完成）
3. 格式化输出

### 完成任务

1. 查找任务 ID
2. 更新状态为"已完成"
3. 记录完成时间
4. 保存并确认

Skill 开发最佳实践

4. 清晰的文档

SKILL.md 应该包含：

• 功能描述

• 使用方法

• 配置要求

• 示例输出

5. 合理的配置

将可变参数放在 config.json 中，便于用户自定义。

6. 错误处理

考虑异常情况：

• API 调用失败

• 配置缺失

• 数据格式错误

7. 版本管理

在 config.json 中记录版本号，便于更新和维护。

8. 测试验证

开发完成后充分测试，确保各种场景下都能正常工作。

📋 实践任务 5：开发自定义 Skill

任务目标：

1. 开发一个简单的自定义 Skill

2. 安装并测试 Skill

3. 完善文档和配置

推荐项目：

选择以下之一进行开发：

1. 倒计时 Skill：计算距离某个日期还有多少天

2. 笔记 Skill：快速记录和查询笔记

3. 提醒 Skill：设置和管理提醒事项

4. 统计 Skill：统计工作日志中的关键数据

✅ 完成标准：

• 成功创建一个自定义 Skill

• Skill 能正常工作

• 文档完整清晰

多渠道部署：全平台接入方案

多渠道接入概述

OpenClaw 支持同时接入多个消息平台，实现“一个 AI，多处可用”的效果。

支持的平台：

• 即时通讯：Telegram、Discord、Slack、WhatsApp

• 社交媒体：Twitter、微信（通过第三方桥接）

• Web 接口：WebChat、HTTP API

• 本地接口：CLI 命令行

配置多渠道接入

基础配置文件： openclaw.json

{
  "gateways": {
    "telegram": {
      "enabled": true,
      "token": "你的_Telegram_Bot_Token"
    },
    "discord": {
      "enabled": true,
      "token": "你的_Discord_Bot_Token",
      "allowedChannels": ["channel-id-1", "channel-id-2"]
    },
    "webchat": {
      "enabled": true,
      "port": 3000,
      "auth": {
        "enabled": true,
        "password": "你的密码"
      }
    }
  }
}

Telegram 接入配置

步骤 1：创建 Bot

1. 在 Telegram 中搜索 @BotFather

2. 发送 /newbot 命令

3. 按提示设置 Bot 名称和用户名

4. 获取 Bot Token

步骤 2：配置 OpenClaw

{
  "gateways": {
    "telegram": {
      "enabled": true,
      "token": "你的_Bot_Token",
      "allowedUsers": ["你的_Telegram_User_ID"]
    }
  }
}

步骤 3：启动并测试

1. 重启 OpenClaw

2. 在 Telegram 中搜索你的 Bot

3. 发送 /start 开始对话

Discord 接入配置

步骤 1：创建 Discord 应用

1. 访问 Discord Developer Portal

2. 创建新应用

3. 在 Bot 页面创建 Bot 并获取 Token

4. 在 OAuth2 页面生成邀请链接，添加 Bot 到服务器

步骤 2：配置 OpenClaw

{
  "gateways": {
    "discord": {
      "enabled": true,
      "token": "你的_Discord_Bot_Token",
      "allowedChannels": ["频道_ID"],
      "commandPrefix": "!"
    }
  }
}

步骤 3：测试

在 Discord 频道中发送 ! help 测试 Bot 是否响应。

WebChat 接入配置

WebChat 提供浏览器访问界面，适合本地使用。

配置：

{
  "gateways": {
    "webchat": {
      "enabled": true,
      "port": 3000,
      "host": "localhost",
      "auth": {
        "enabled": true,
        "username": "admin",
        "password": "你的密码"
      },
      "https": {
        "enabled": false
      }
    }
  }
}

访问：

启动后访问 http://localhost:3000 即可使用 Web 界面。

消息路由配置

当接入多个平台时，可以配置消息路由规则，让不同类型的消息发送到不同平台。

示例配置：

{
  "routing": {
    "rules": [
      {
        "type": "alert",
        "destinations": ["telegram", "discord"]
      },
      {
        "type": "daily-briefing",
        "destinations": ["telegram"]
      },
      {
        "type": "log",
        "destinations": ["file"]
      }
    ]
  }
}

规则说明：

• 告警消息同时发送到 Telegram 和 Discord

• 每日简报只发送到 Telegram

• 日志消息只写入文件

多渠道最佳实践

5. 权限隔离

不同平台设置不同的权限：

• Telegram（个人）：完全权限

• Discord（团队）：限制敏感操作

• WebChat（公开）：只读权限

6. 消息分类

根据消息类型选择合适的平台：

• 紧急告警 → Telegram（推送通知）

• 日常交互 → Discord（团队协作）

• 数据查询 → WebChat（可视化界面）

7. 成本控制

多渠道会增加 API 调用，注意监控成本。

📋 实践任务 6：配置多渠道接入

任务目标：

1. 配置至少 2 个消息平台

2. 测试跨平台消息同步

3. 配置消息路由规则

推荐配置：

1. Telegram（个人使用）

2. Discord 或 WebChat（团队/本地使用）

✅ 完成标准：

• 成功配置至少 2 个平台

• 能在不同平台与 AI 对话

• 消息路由规则生效

性能调优：配置参数详解

模型选择和配置

不同任务适合不同的模型，合理选择可以平衡性能和成本。

推荐配置：

{
  "agents": {
    "defaults": {
      "model": {
        "provider": "anthropic",
        "name": "claude-3-5-sonnet-20241022",
        "temperature": 0.7,
        "maxTokens": 4096
      },
      "fallback": {
        "enabled": true,
        "models": [
          {
            "provider": "openai",
            "name": "gpt-4o"
          }
        ]
      }
    }
  }
}

参数说明：

temperature 选择建议：

• 0.3-0.5：代码生成、数据分析（需要精确）

• 0.7-0.8：日常对话、内容创作（平衡）

• 0.9-1.0：创意写作、头脑风暴（创造性）

Token 使用优化

Token 是 API 成本的主要来源，优化 token 使用可以显著降低费用。

优化策略：

3. 启用缓存

{
  "agents": {
    "defaults": {
      "cache": {
        "enabled": true,
        "ttl": 3600,
        "maxSize": 100
      }
    }
  }
}

缓存可以避免重复的 API 调用，特别是对于相同或相似的查询。

4. 压缩系统提示

将冗长的系统提示精简为关键要点，减少每次调用的固定成本。

5. 使用更便宜的模型

对于简单任务，使用较便宜的模型：

{
  "agents": {
    "simple-tasks": {
      "model": {
        "provider": "openai",
        "name": "gpt-4o-mini"
      }
    }
  }
}

6. 限制上下文长度

{
  "agents": {
    "defaults": {
      "compaction": {
        "targetTokens": 50000
      }
    }
  }
}

性能监控

启用详细日志：

{
  "logging": {
    "level": "info",
    "file": "workspace/logs/openclaw.log",
    "metrics": {
      "enabled": true,
      "interval": 3600
    }
  }
}

查看使用统计：

openclaw stats --period 7d

输出示例：

OpenClaw 使用统计（最近 7 天）

API 调用：
- 总次数：1,234
- 总 tokens：456,789
- 估算成本：$12.34

模型分布：
- claude-3-5-sonnet：80%
- gpt-4o：15%
- gpt-4o-mini：5%

任务类型：
- 对话：60%
- 文件操作：25%
- 网络搜索：15%

成本控制

设置每日限额：

{
  "billing": {
    "limits": {
      "daily": 10.00,
      "monthly": 200.00
    },
    "alerts": {
      "enabled": true,
      "thresholds": [0.5, 0.8, 0.95]
    }
  }
}

当使用量达到阈值（50%、80%、95%）时，系统会发送告警。

配置速查表

基础配置：

{
  "agents": {
    "defaults": {
      "model": {
        "provider": "anthropic",
        "name": "claude-3-5-sonnet-20241022",
        "temperature": 0.7,
        "maxTokens": 4096
      },
      "compaction": {
        "reserveTokensFloor": 20000,
        "memoryFlush": {
          "enabled": true,
          "softThresholdTokens": 4000
        }
      },
      "subAgents": {
        "enabled": true,
        "maxConcurrent": 3,
        "timeout": 300000
      },
      "cache": {
        "enabled": true,
        "ttl": 3600
      }
    }
  },
  "memorySearch": {
    "enabled": true,
    "provider": "openai",
    "remote": {
      "baseUrl": "https://api.siliconflow.cn/v1",
      "apiKey": "你的_API_Key"
    },
    "model": "BAAI/bge-m3"
  },
  "logging": {
    "level": "info",
    "metrics": {
      "enabled": true
    }
  },
  "billing": {
    "limits": {
      "daily": 10.00,
      "monthly": 200.00
    }
  }
}

📋 实践任务 7：性能优化

任务目标：

1. 根据你的使用情况优化配置

2. 启用性能监控

3. 设置成本控制

4. 观察一周的优化效果

优化清单：

• 调整 temperature 参数

• 启用缓存

• 配置备用模型

• 设置每日限额

• 启用使用统计

✅ 完成标准：

• 配置已优化

• 成本控制已设置

• 能查看使用统计

实战练习清单

基础配置（必做）

• 任务 1：创建 AGENTS.md 工作规范

• 任务 2：优化记忆系统（memoryFlush + 日志格式）

• 任务 3：配置子 Agent 并完成并行任务

• 任务 4：创建至少 2 个 Cron 定时任务

• 任务 5：开发一个自定义 Skill

• 任务 6：配置多渠道接入（至少 2 个平台）

• 任务 7：性能优化和成本控制

进阶项目（推荐）

• 项目 1：构建自动化早报系统

每天早上发送天气、日程、新闻摘要

整合多个数据源

格式化输出

• 项目 2：邮件自动分类系统

自动读取新邮件

按重要性分类

自动回复常见问题

• 项目 3：多平台消息聚合

统一管理多个平台的消息

智能路由和转发

消息归档和搜索

• 项目 4：服务监控告警系统

定期检查服务状态

异常时自动告警

生成监控报告

• 项目 5：知识库管理系统

自动整理和归档笔记

智能检索和推荐

定期生成总结

高级挑战（可选）

• 挑战 1：开发复杂的多步骤 Skill

• 挑战 2：实现跨平台的工作流自动化

• 挑战 3：构建个人数据分析仪表板

• 挑战 4：集成第三方 API 和服务

• 挑战 5：优化到极致的成本控制（月费用 <$10）

疑难解答

Q1：memoryFlush 没有触发怎么办？

可能原因：

1. 配置未正确启用

2. 对话长度未达到触发阈值

3. 日志级别过低，看不到触发信息

解决方法：

1. 检查 openclaw.json 中 memoryFlush.enabled 是否为 true

2. 启用 verbose 模式：发送 /verbose 命令

3. 进行长对话测试（100+ 轮）观察是否触发

Q2：子 Agent 执行失败

可能原因：

1. 并发数超过 API 限制

2. 子任务超时

3. 任务分解不合理

解决方法：

1. 降低 maxConcurrent 值

2. 增加 timeout 时间

3. 检查任务是否适合并行处理

Q3：Cron 任务没有执行

可能原因：

1. Cron 表达式错误

2. 时区设置不正确

3. 任务被禁用

解决方法：

1. 使用 crontab.guru 验证表达式

2. 检查 timezone 字段

3. 运行 openclaw cron list 查看任务状态

4. 手动触发测试：openclaw cron run 任务名

Q4:memorySearch 检索不到内容

可能原因：

1. Embedding 模型未配置

2. 日志格式不规范

3. 缺少标签

解决方法：

1. 检查 memorySearch 配置

2. 按照优化格式重写日志

3. 添加相关标签

Q5：多渠道消息不同步

可能原因：

1. 路由规则配置错误

2. 某个平台连接失败

3. 权限设置不一致

解决方法：

1. 检查 routing 配置

2. 查看各平台的连接状态

3. 统一权限设置

Q6：API 成本过高

解决方法：

1. 启用缓存减少重复调用

2. 对简单任务使用更便宜的模型

3. 优化系统提示减少固定成本

4. 设置每日限额防止超支

5. 定期检查使用统计，找出高消耗点

Q7：配置文件修改后不生效

解决方法：

1. 重启 OpenClaw:openclaw restart

2. 检查 JSON 格式是否正确（使用 JSON 验证工具）

3. 查看日志文件是否有错误信息

进阶学习资源

官方资源

• 官方网站：openclaw.ai

• GitHub 仓库：github.com/openclaw/openclaw

• 官方文档：docs.openclaw.ai

• Skill 市场：github.com/VoltAgent/awesome-openclaw-skills

社区资源

• Reddit:r/clawdbot、r/AiForSmallBusiness

• Discord:OpenClaw 官方 Discord 服务器

• GitHub Discussions：在仓库的 Discussions 区提问和交流

中文资源

• 中文社区：MaoTouHU/OpenClawChinese（提供中文界面和文档）

• 中文教程：搜索“OpenClaw 中文教程”可以找到更多本地化资源

进阶主题

完成本教程后，你可以探索以下高级主题：

1. 多 Agent 协作：让多个 Agent 协同工作

2. 自定义插件开发：开发更复杂的功能扩展

3. 企业级部署：在团队或公司中部署 OpenClaw

4. 安全加固：深度配置安全策略

5. 性能调优：针对大规模使用的优化

总结

完成本教程后，你的 OpenClaw 已经从“好用”提升到“更好用”，甚至“离不开”的水平。

你已经掌握：

• ✅ 完整的工作规范体系（AGENTS.md）

• ✅ 可靠的记忆管理机制

• ✅ 高效的任务并行处理

• ✅ 精确的定时自动化

• ✅ 自主的能力扩展

• ✅ 全平台的接入方案

• ✅ 优化的性能配置

下一步建议：

1. 深入实践：选择一个实战项目，将所学知识应用到实际场景

2. 持续优化：根据使用情况不断调整配置

3. 参与社区：分享你的经验，帮助其他用户

4. 探索创新：尝试开发独特的 Skill 和工作流

OpenClaw 的潜力远不止于此。随着你对系统的深入理解，你会发现更多可能性。

祝你在 AI 助手的探索之旅中收获满满！🚀

朋友，写文不易，看到这了，给个点赞书签再走?

最后更新：2026 年 2 月版本：2.0 适用于：OpenClaw v2.23 及以上版本

大部分人部署完 OpenClaw 之后，看到它能在 Discord 或 Telegram 里正常回复消息，就觉得已经用上龙虾了。实际上，出厂设置的 OpenClaw连它五分之一的实力都没发挥出来。

真正的潜力，隐藏在那些你没动过的配置文件里。

出厂设置 vs 调教好

让我先用一个对比表格感受下差异：

接下来我会按照从易到难、从基础到进阶的顺序，讲解五个关键配置方向。

第一步：塑造个性化的对话风格

OpenClaw 的 workspace 目录下有三个定义“身份”的文件：

• SOUL.md — 定义它是谁，回复风格

• IDENTITY.md — 设定名称、形象标识

• USER.md — 你是谁，它怎么称呼你

大多数人安装后这三个文件基本是空的，所以 AI 只能用最通用的方式回复你——也就是那种“非常荣幸为您服务”的客服腔。

在 SOUL.md 中，我写入了这样的行为准则：

#核心原则

## 沟通风格
- 直接切入主题,不需要礼貌性寒暄
- 允许表达观点,不必保持绝对中立
- 简洁优先,但涉及技术细节时不省略关键信息

## 工作方式
- 优先尝试自主解决,确实需要时再询问
- 主动提供相关背景信息和替代方案

就这么简单几行，它的回复风格立马变成正常人说话。

IDENTITY.md 比较简单——给它一个具体的名字和符号标识。这看起来是小事，但在长期使用中，一个有明确身份的 AI 在多轮对话中的表现一致性会明显更好。

USER.md 里记录你的工作时区、技术背景、沟通习惯、职业等。这能避免很多不必要的误解——比如它不会在你的休息时间发送非紧急通知，也不会向一个前端工程师推荐后端框架。

第二步：构建结构化的记忆系统

这是提升体验最显著的一个环节。

默认的 MEMORY.md 文件存在两个问题：要么被闲置，要么变成一个什么都往里塞的垃圾场。真正有效的记忆系统需要分层设计：

MEMORY.md              ← 核心索引:只记录关键信息和文件引用
memory/
  ├── projects.md      ← 项目状态和任务追踪
  ├── infra.md         ← 基础设施配置速查
  ├── lessons.md       ← 问题记录和解决方案
  └── 2026-02-23.md    ← 每日对话日志

MEMORY.md 只做索引，不堆积内容。 每次会话启动时只加载这个索引文件，需要具体信息时再按需读取相关文件。这样既保证了启动速度，又不会丢失重要信息。

语义检索能力

配合 OpenClaw 的 memorySearch 功能，你可以实现真正的“语义记忆”:

当你说“上次那个部署失败的问题”, AI 不需要逐行扫描所有历史记录，而是通过语义理解直接定位到相关的那一段对话。

在 openclaw.json 中加上：

"memorySearch": {
  "enabled": true,
  "provider": "openai",
  "remote": {
    "baseUrl": "你的embedding服务地址",
    "apiKey": "你的密钥"
  },
  "model": "BAAI/bge-m3"
}

SiliconFlow提供的免费 embedding 服务（bge-m3 模型），基本可以零成本实现语义记忆。

另外建议开启 compaction.memoryFlush 选项，这样当对话上下文接近上限时，AI 会自动将重要信息提取到当天的日志文件中，避免因为 token 限制导致的“失忆”。

第三步：通过 Skill 扩展实用功能

OpenClaw 预装了一些基础 skill（天气查询、新闻摘要等），但它的真正威力在于你可以根据自己的需求定制功能模块。

Skill 的本质是一个指导文档（SKILL.md）加上可选的执行脚本。当 AI 识别到相关请求时，会自动读取对应的 SKILL.md 并按照其中的步骤执行。

我目前在使用的几个自定义 skill:

• 媒体下载器： 发送视频链接，自动下载并生成分享链接

• PPT生成器： 根据主题自动生成PPT

• 量化分析： 输入token，运行预测模型并给出分析报告

• x新闻热点： 每天自动收集x热点

一个标准的 skill 目录结构：

skills/
  my-skill/
    SKILL.md          ← AI 的执行指南
    execute.sh        ← 可选的自动化脚本
    README.md         ← 可选的使用说明

编写要点

在 SKILL.md 中需要明确三个要素：

1. 触发条件 — 什么情况下启用这个 skill

2. 执行流程 — 分步骤的详细操作指南

3. 输出规范 — 结果应该以什么格式呈现

关键是把 AI 当作一个刚入职的助手——你的指令越清晰具体，执行结果就越稳定可靠。模糊的描述会导致不可预测的行为。

社区也有现成的 skill 资源可以参考：clawhub.com

第四步：启用心跳机制实现主动服务

OpenClaw 有一个容易被忽视但非常实用的功能：心跳（Heartbeat）机制。

系统会定期（默认 30 分钟）向 AI 发送一个信号，询问是否有需要处理的事项。默认情况下，AI 只会简单回复 HEARTBEAT_OK 然后什么都不做。

但如果你创建一个 HEARTBEAT.md 文件，就可以定义它在心跳时应该执行的检查任务：

# HEARTBEAT.md

## 每次心跳时执行
- 检查核心服务健康状态(通过 HTTP 探测)
- 如果发现异常,立即通知但不要自动干预

## 每日执行一次
- 扫描项目待办列表,标记超过 3 天未更新的任务

## 每周执行一次
- 整理过去 7 天的对话日志,提炼关键信息到长期记忆

这样你的 AI 就变成了一个全天候的监控助手。你休息的时候它在巡检，你上线就能看到整理好的报告。

心跳 vs 定时任务

• 心跳适合： 轻量级的周期性检查，可以批量执行多个小任务

• cron 适合： 需要精确时间触发的独立任务（例如“每周一上午 9 点生成周报”）

第五步：配置模型分级降低成本

如果你通过 API 中转服务可以访问多个模型，强烈建议配置模型分级策略：

在 openclaw.json 中设置别名：

"models": {
  "provider/strong-model": { "alias": "opus" },
  "provider/medium-model": { "alias": "sonnet" },
  "provider/light-model": { "alias": "haiku" }
}

然后在 AGENTS.md 中定义分配规则，AI 在派发子任务时会自动选择合适的模型。

实际效果： 在保持服务质量的前提下，token 消耗可以降低 60-70%，因为绝大多数日常操作根本不需要最强大的模型。

配置优先级清单

按照投入产出比排序：

1. ✅ 完善 SOUL.md / IDENTITY.md / USER.md (10 分钟，效果立竿见影）

2. ✅ 建立分层记忆结构，启用 memorySearch (30 分钟）

3. ✅ 配置 HEARTBEAT.md (10 分钟）

4. ✅ 根据需求安装或编写 2-3 个常用 skill （按需投入）

5. ✅ 配置模型分级策略 （如果有多模型访问权限）

6. ✅ 完善 AGENTS.md 中的行为规范和安全策略

结语

OpenClaw 的设计理念是提供一个灵活的框架，由使用者来定义它的具体形态。默认配置只是一个起点，真正的价值在于你如何根据自己的工作流程来调教它。

我自己经过一段时间的调整，已经把它从一个简单的聊天机器人改造成了一个能够记住上下文、主动执行巡检、协助编码和文档生成的全方位助手。

如果你也在使用 OpenClaw，欢迎分享你的经验和小技巧

让我们的龙虾，一起进化！

进阶阅读：https://openlang.cn/archives/openclaw-cong-zhong-ji-dao-gao-ji-wan-zheng-jiao-cheng

Skills 概念完全指南

什么是 Skills

Skills（技能）是一种用于扩展 AI 助手能力的模块化定义方式。它们本质上是预先编写好的指令集，可以让 AI 助手在特定场景下表现出特定的行为模式或执行特定类型的任务。

你可以把 Skills 想象成 AI 助手的“工具箱”或“技能包”。每个 Skill 就像一张卡片，上面写着“在这种情况下，我应该这样做”。当 AI 助手遇到匹配的场景时，它会自动调用相应的技能，从而提供更专业、更准确的帮助。

举几个具体的例子：一个“代码审查”技能可以告诉 AI 如何进行规范的代码审查，包括关注点、审查流程和反馈格式；一个“编写测试”技能可以定义单元测试的编写规范、命名约定和覆盖率要求；一个“撰写文档”技能可以指导 AI 按照项目的文档规范生成 API 文档或技术说明。

Skills 的核心价值

Skills 的出现解决了 AI 助手的几个重要问题。

首先是知识传递问题。每个团队、每个项目都有自己独特的规范和习惯，这些知识很难通过通用的提示词传达给 AI。通过 Skills，你可以把这些规范固化下来，让 AI 在需要时自动调用。简单来说，就是把团队的“隐性知识”变成 AI 可以理解的“显性规则”。

其次是一致性问题。如果没有 Skills，团队成员可能需要各自向 AI 解释项目的编码规范，导致不同的人得到不同质量的结果。而通过统一的 Skills 定义，所有团队成员使用 AI 时都能获得一致的行为输出。

第三个价值是复用性。一个设计良好的 Skill 可以在多个项目中重复使用，也可以在团队成员之间共享。这大大提高了效率，因为不需要每次都重新定义相同的规则和流程。

最后一个是专业化。通用的 AI 助手虽然能力强大，但在特定领域可能不够深入。通过 Skills，你可以为特定场景（比如数据分析、前端开发、系统运维等）定制专门的指导，让 AI 在这些领域表现得更专业。

Skills 的工作原理

理解 Skills 的工作原理有助于更好地使用它们。

每个 Skill 通常包含几个核心部分。第一是元数据，包括名称、描述、版本和兼容性信息，这些帮助 AI 和用户识别和选择合适的技能。第二是触发条件，说明在什么情况下应该使用这个技能，比如特定的命令、文件类型或任务类型。第三是指令内容，这是 Skill 的核心，定义了具体的行为规范、操作步骤和输出要求。第四是示例，提供一些具体的使用例子，帮助 AI 理解期望的行为。

当 AI 处理用户请求时，它会判断当前任务是否匹配某个 Skill 的触发条件。如果匹配，AI 会加载相应的 Skill 内容，将其融入自己的思考过程，从而提供更符合预期的回答和操作。

如何使用 Skills

使用 Skills 通常有以下几种方式。

最常见的是通过 AI 助手自动触发。当你与 AI 交流时，如果你的请求符合某个 Skill 的触发条件，AI 会自动加载并应用这个技能。比如当你请求代码审查时，如果有一个“代码审查”技能，AI 会自动调用它。

另一种方式是显式调用。你可以告诉 AI“请使用 XX 技能来完成这个任务”，AI 会加载指定的 Skill 并按照其中的规范来执行。这种方式在你知道需要哪个技能时特别有用。

还有一些系统支持通过配置文件声明需要使用的技能，这样每次对话时都会自动加载这些技能，无需每次手动指定。

Skills 的存放位置

不同的 AI 工具对 Skills 的存放位置有不同的规定，但通常遵循一些通用的模式。

项目级 Skills 存放在当前项目的特定目录中，比如 .skills/、skills/ 或 .ai/skills/ 等。这样该项目下的所有 AI 交互都能使用这些技能。

全局 Skills 存放在用户主目录下的特定位置，比如 ~/.skills/、~/.config/ai/skills/ 等。这样无论在哪个项目中使用 AI，都能访问这些通用技能。

一些工具还支持从特定的技能市场中安装社区分享的 Skills，这类似于软件包管理器，允许用户直接使用他人分享的技能，而不需要自己从头编写。

如何编写一个 Skill

编写 Skill 需要考虑几个关键要素。

首先是明确目标。你需要清楚这个 Skill 要解决什么问题，在什么场景下使用。比如一个“生成 README”技能的目标就是在用户需要为项目编写说明文档时提供帮助。

其次是定义触发条件。什么样的输入应该触发这个技能？可能是特定的关键词、文件扩展名、命令参数或任务类型。触发条件应该足够清晰，既不会遗漏应该匹配的情况，也不会错误匹配不相关的情况。

然后是编写核心指令。这是 Skill 的主体部分，需要清晰、具体地描述期望的行为。避免模糊的表述，比如“写得好一点”，而应该给出具体的标准，比如“每个函数必须有 JSDoc 注释，注释必须包含参数说明和返回值说明”。

提供示例也很重要。AI 善于从示例中学习，提供典型的输入输出示例可以帮助 AI 更好地理解你的意图。

最后是设置边界。说明这个 Skill 适用于什么场景，不适用于什么场景，避免 AI 在不适当的情况下使用这个技能。

Skill 的典型结构

一个典型的 Skill 文件通常包含以下结构。

---
name: skill-name
description: 技能的具体描述，说明它的用途和使用场景
version: 1.0.0
tags: [标签1, 标签2]
---

# 技能名称

## 简介
简要介绍这个技能是什么、做什么。

## 触发条件
在什么情况下应该使用这个技能。

## 行为规范
具体的行为要求和操作步骤。

## 示例
一些使用示例。

## 注意事项
需要特别注意的事项或限制。

常见的使用场景

Skills 在实际工作中有非常广泛的应用场景。

代码生成领域可以定义各种编程语言的代码风格、命名规范、注释要求等。比如一个“React 组件”技能可以规定组件的编写格式、Props 的定义方式、样式应该如何组织等。

代码审查场景可以定义审查标准、检查项、反馈格式等。比如规定必须检查安全性、性能、可访问性等方面，并给出具体的审查清单。

文档生成场景可以定义各种文档的模板、结构、风格等。比如 API 文档必须有参数说明、返回值说明、示例代码等。

测试编写场景可以定义测试文件的组织方式、命名规范、覆盖率要求等。

重构指导场景可以提供常见的重构模式和最佳实践，指导 AI 进行安全的代码改进。

问题排查场景可以提供常见错误的排查步骤、调试技巧、日志分析方法等。

部署运维场景可以定义部署流程、环境配置、监控指标等。

Skills 与其他概念的区别

了解 Skills 与相关概念的区别有助于更好地理解它的定位。

Skills 与系统提示词（System Prompt）不同。系统提示词是在每次对话开始时就会加载的全局设置，而 Skills 是按需加载的模块。这使得 Skills 更加灵活，不会一次性给 AI 太多不相关的信息。

Skills 与插件（Plugins）不同。插件通常包含可执行的代码或与外部系统的集成能力，而 Skills 主要是一组指令和规则。简单来说，插件扩展的是 AI 的“能力”，而 Skills 扩展的是 AI 的“知识”。

Skills 与工作流（Workflows）不同。工作流通常定义的是多步骤的自动化流程，而 Skills 更像是指导 AI 行为的“手册”。一个工作流可能包含多个技能，但技能本身更专注于特定场景的指导。

如何管理 Skills

随着使用的 Skills 越来越多，有效管理它们变得很重要。

保持组织清晰。按照功能或领域对 Skills 进行分类，比如分为“代码质量类”、“文档类”、“测试类”等。每个分类使用独立的文件夹，便于查找和维护。

定期更新维护。随着项目的发展和经验的积累，及时更新 Skills 中的规则和建议，删除不再适用的内容。

版本控制。将 Skills 纳入版本控制，这样可以追踪修改历史，也方便在团队中共享。

文档化。对于复杂的 Skills，编写使用文档说明它的设计意图、适用场景和使用注意事项，方便团队成员理解和正确使用。

如何选择合适的 Skills

选择合适的 Skills 需要考虑几个因素。

匹配度是最重要的。确保 Skills 描述的场景与你的实际需求相符，不要期望一个技能解决所有问题。

质量优先。一个设计良好的 Skill 胜过十个粗糙的 Skill。在采用新 Skill 之前，花时间检查它的质量。

兼容性。确认 Skills 与你使用的 AI 工具兼容，不同工具的 Skills 格式可能有所不同。

社区评价。如果是使用他人分享的 Skills，查看其他用户的评价和反馈，了解它的实际效果。

总结

Skills 是一个强大的概念，它让 AI 助手能够更好地适应特定团队和项目的需求。通过定义清晰的指令集，Skills 帮助 AI 在特定场景下提供更专业、更一致、更高质量的输出。

掌握 Skills 的使用和编写方法，可以显著提升你与 AI 助手的协作效率，让 AI 真正成为团队中得力的专业助手，而不是一个什么都会但什么都不精的通用工具。

无论你是个人开发者还是团队成员，都值得花时间了解和实践 Skills，找到适合自己工作方式的技能组合。

OpenCode：开源 AI 编程助手完全指南

概述

OpenCode 是一个强大的开源 AI 编程助手，旨在帮助开发者更高效地编写代码。它可以在终端、IDE 或桌面应用中运行，支持连接多种大语言模型，包括 Claude、GPT、Gemini 等，也可使用内置的免费模型。

截至目前，OpenCode 已获得超过 100,000 GitHub Stars，拥有 700 位贡献者，每月被超过 250 万 开发者使用。

主要特性

1. 多模型支持

• 内置免费模型：开箱即用，无需额外订阅

• 75+ LLM 提供商：通过 Models.dev 支持海量模型

• 本地模型：支持运行本地大语言模型

• 主流集成：支持 GitHub Copilot、ChatGPT Plus/Pro 账户登录

2. 跨平台使用

• 终端界面：直接在命令行中使用

• 桌面应用：支持 macOS、Windows、Linux（Beta）

• IDE 扩展：集成到主流开发环境

3. 开发者友好功能

安装

macOS

brew install opencode 

Linux

# 使用 curl
curl -fsSL https://opencode.ai/install | bash

# 使用 aur (paru)
paru -S opencode 

Windows

# 使用 winget 
winget install OpenCode 

使用方法

基础命令

# 启动交互式会话
opencode 

# 指定模型
opencode --model claude

# 查看帮助
opencode --help

配置模型

在配置文件中指定偏好的模型提供商：

model:
  provider: openai   # 或 anthropic, google 等
  model:gpt-4o

适用场景

1. 代码补全与生成：快速生成代码片段

2. Bug 修复：分析并修复代码问题

3. 代码重构：优化现有代码结构

4. 技术问答：解答编程相关问题

5. 项目探索：理解大型代码库

隐私与安全

OpenCode 高度重视用户隐私：

• 零数据存储：不存储任何用户代码或会话数据

• 本地处理：可在本地运行模型，确保数据不离开设备

• 企业级安全：提供企业版本满足更高安全需求

社区与资源

• GitHub：https://github.com/anomalyco/opencode

• 文档：https://opencode.ai/docs

• Discord：加入社区交流

• 更新日志：持续迭代更新

总结

OpenCode 是一款功能强大、完全开源的 AI 编程助手。它提供了灵活的多模型支持、跨平台使用体验，以及卓越的隐私保护。无论是个人开发者还是企业团队，都能从中获得显著的效率提升。

作为开源项目，OpenCode 持续获得社区的大力支持，是当前最受欢迎的 AI 编程工具之一。强烈推荐尝试！

OpenClaw：你的私人AI助手，开源可控

当AI不再只是"聊天"，而是能帮你"做事"

在AI模型爆发式增长的2026年，我们面临的挑战不再是"没模型可用"，而是高效、私密地整合它们。如果你厌倦了在不同的Web页面间切换，或者担心个人对话数据被大厂"免费"使用，那么OpenClaw就是你通往"数字主权"的钥匙。

一、OpenClaw是什么？

OpenClaw是一款运行在用户自有设备上的开源自主AI助手，并非简单的聊天机器人，而是具备"执行能力"的智能代理（Agent）。它以"本地优先、隐私可控"为设计理念，通过连接各类通讯平台和工具，实现跨场景任务自动化，真正做到"替用户做事"而非"仅回答问题"。

其核心理念是构建"AI个人操作系统"：无需依赖第三方云服务，所有核心逻辑在本地设备运行，数据存储于私有环境，同时支持多设备协同与高度自定义配置。

OpenClaw的命名经历了三次迭代，背后是项目从个人玩具到成熟开源平台的演进历程：

• 初始命名"Clawd"：源于Claude（AI模型）与claw（龙虾爪）的谐音，致敬Anthropic的Claude模型及其龙虾加载图标，但因可能引发品牌混淆，收到Anthropic法务团队的合规提示。

• 过渡名称"Moltbot"："Molt"意为龙虾蜕壳，寓意项目迭代成长，但该名称未充分体现开源核心特质，社区认可度有限。

• 最终定名"OpenClaw"："Open"凸显开源协作、开放扩展的项目属性，"Claw"保留初始设计的龙虾意象，形成既符合品牌规范又彰显项目精神的命名。

截至2026年1月，该项目已在GitHub收获10万+星标，Discord社区成员超8900人，成为开源AI领域增速最快的项目之一。

二、核心特性

1. 多模型集成

OpenClaw并非固步自封的单一工具，它通过统一的接口协议，将目前市面上顶尖的算力资源收归己有：

• 巅峰算力：完美支持Claude 4.5系列（Sonnet/Opus）与GPT-4o，并允许通过自定义API地址接入OneAPI或中转代理。

• 极致推理：集成Groq与Mistral AI，体验快如闪电的回复速度。

• 国产模型：深度支持通义千问、文心一言、Kimi等国产大模型，无缝接入国内AI生态。

• 本地私有化：深度整合Ollama，在2GB内存起步的硬件上即可运行Llama 3等开源模型，实现真正的100%数据不离本地。

2. 多渠道接入

OpenClaw的魅力在于它的"无处不在"。通过简单的配置，它能化身为你的：

• 通讯助理：接入Telegram、Discord、WhatsApp、Slack、Signal

• 企业内参：支持飞书与企业微信

• 原生管家：在macOS上甚至支持iMessage接入

• Web界面：提供本地WebChat，无需安装客户端即可通过浏览器访问

3. 主动能力

OpenClaw不仅被动回答，还能通过多项主动能力为你服务：

• 持久记忆：跨平台记住你的喜好、习惯和工作方式，成为真正"懂你"的AI助手

• 主动推送：为你发送晨报、任务提醒、定时通知，如同私人秘书般贴心

• Skills技能系统：通过预定义的技能（Skills）执行复杂任务，如自动生成周报、整理邮件、调用API等

• 工作区管理：支持创建多个独立的工作区，每个工作区可以有不同的AI人格、技能和记忆

4. 完全开源

• MIT许可证：完全自由使用和修改，无论个人还是企业都可商用

• 本地优先：数据存在自己的设备上，不依赖第三方云服务

• 社区活跃：GitHub 10万+星标，Discord 8000+成员，问题响应及时

三、适合谁使用？

四、快速开始

OpenClaw提供了多种安装方式，无论你是技术小白还是资深开发者，都能找到适合自己的路径。

方式一：npx一键安装（推荐）

npx openclaw 

首次运行会自动启动新手引导，配置AI模型和渠道后即可使用。

方式二：Docker安装

docker run -d --name openclaw -p 8080:8080 -v openclaw-data:/data openclaw/openclaw 

方式三：手动安装

1. 克隆仓库：git clone https://github.com/openclaw/openclaw.git

2. 安装依赖：npm install

3. 启动服务：npm start

基础配置流程

1. 选择模型提供商：配置API Key（支持OpenAI、Anthropic、Ollama等）

2. 连接渠道：选择要接入的通讯平台（Telegram、飞书等）

3. 配置技能：根据需求添加需要的Skills

4. 启动运行：完成配置后即可开始使用

五、为什么选择OpenClaw？

在众多AI助手中，OpenClaw凭借其独特优势脱颖而出：

核心优势总结

1. 数据主权：所有对话数据存储在本地，不用担心隐私泄露

2. 灵活扩展：通过Skills系统可以无限扩展AI能力

3. 跨平台统一：一个AI助手管理所有通讯渠道

4. 成本可控：可选本地模型或中转API，灵活控制成本

5. 国产优化：深度支持国产大模型和国内通讯平台

六、相关资源

• 官方网站：https://openclawcn.com

• GitHub仓库：https://github.com/openclaw/openclaw

• 官方文档：https://docs.openclaw.ai

• 中文指南：https://openclawguide.org/zh

• 社区Discord：https://discord.gg/clawd

• 技能市场：https://clawsome.com（ClawHub）

推荐服务器配置

运行OpenClaw建议使用2核2G以上配置的服务器：

• 国内推荐：腾讯云轻量应用服务器 ¥68/年

• 海外推荐：Vultr $5/月起（约¥36）

• 阿里云：¥99年起（2核2G）

结语

在AI工具从"对话响应"向"主动执行"演进的浪潮中，OpenClaw凭借"开源可控、全渠道集成、主动任务执行"三大核心优势，成为追求数据主权和效率提升用户的首选。它打破了传统AI助手"被动等待指令"的局限，以本地部署为基础，深度融入日常工作流，成为能够自主处理复杂任务的"个人AI操作系统"。

如果你受够了在不同网页间切换，或者担心个人数据被大厂"免费"使用，OpenClaw可能是你通往"数字主权"的下一把钥匙。