1. 从一个“反直觉”的架构选择说起如果你关注过一些现代AI应用框架比如LangChain、Semantic Kernel你会发现它们都在强调一个概念工具Tool。在这些框架里工具通常被定义为一个函数它有明确的输入参数、输出格式和功能描述。开发者需要手动编写这些函数然后注册到系统中供大模型LLM调用。这听起来很合理对吧一个清晰的接口一个可控的执行单元。但OpenClaw选择了一条看起来有点“偷懒”甚至“反直觉”的路文档即工具Document as Tool。初看这个设计你可能会疑惑文档是静态的、非结构化的文本怎么能直接当工具用这岂不是把复杂度都扔给了大模型让模型自己去“阅读理解”然后“自由发挥”这靠谱吗这正是OpenClaw架构的精妙之处也是其扩展性的灵魂所在。它没有把工具定义为一个需要严格编程的“黑盒”函数而是将其开放为一个可以被灵活解读和执行的“白盒”文档。这个设计背后是对AI Agent能力边界、开发效率以及系统灵活性的深刻思考。今天我们就来彻底拆解OpenClaw的Skills System看看“文档即工具”这个理念是如何从底层重塑我们构建智能应用的方式的。2. 拆解“文档即工具”不止是README那么简单当我们说“文档即工具”时指的究竟是什么它绝对不是简单地把一个API的使用说明扔给模型就完事了。在OpenClaw的语境下一个合格的“工具文档”是一个自包含、可执行、可解释的指令集。它至少包含以下几个核心层次2.1 第一层功能意图的自然语言描述这是最表层也是给大模型看的“接口”。它用人类和AI都能理解的语言清晰地说明这个工具是干什么的。例如一个“天气查询”工具的文档开头可能是“本工具用于查询指定城市当前及未来几天的天气情况。你需要提供城市名称作为输入。”关键在于这个描述不预设固定的参数名和格式。它只说“需要城市名称”而不强制规定参数叫city_name还是location。这降低了大模型调用时的“语法”匹配难度模型只需要理解意图并提取关键信息即可。2.2 第二层输入输出的结构化提示虽然不强制固定格式但好的工具文档会通过示例和结构化描述引导模型输出易于后续处理的格式。这通常在文档中后部体现。例如在描述了功能后文档会补充输入示例 用户问题“北京今天天气怎么样” 工具应提取的信息{“城市”: “北京”} 输出格式 工具执行后将返回一个JSON对象包含以下字段 - city: 城市名 - weather: 天气状况如晴、多云、雨 - temperature: 温度单位摄氏度 - report_time: 数据更新时间这种结构化的提示Structured Prompt充当了“柔性接口”既给了模型灵活性又保证了输出结果的可预测性和可编程性。2.3 第三层执行逻辑与外部依赖声明这是文档的“引擎”部分。它需要说明当模型识别出意图并提取出参数后具体如何执行。这里可能包含几种情况本地函数调用直接调用系统中一个预先编写好的Python函数并将提取的参数传递给它。文档中需要指明函数名和参数映射关系。API调用描述一个HTTP请求的端点Endpoint、方法GET/POST、所需的Headers、Body结构等。文档本身就是一份API手册。复合操作流程描述一个多步骤的操作序列例如“先查询数据库A再用结果去调用API B最后格式化输出”。这可以用伪代码或清晰的步骤列表来描述。为什么要把执行逻辑也写在文档里这恰恰是“文档即工具”与“函数即工具”的核心区别。函数是封装的、不透明的而文档是开放的、可审阅的。任何一个开发者或另一个AI阅读这份文档都能立刻明白这个工具是如何工作的依赖了哪些外部服务可能存在什么风险如网络超时、认证失败。这极大地提升了系统的可理解性和可维护性。2.4 第四层上下文、约束与安全边界一份负责任的工具文档还必须定义它的使用边界。上下文要求这个工具需要在什么会话上下文中使用例如一个“修改订单”的工具可能需要用户已经登录并拥有一个有效的订单ID在上下文中。权限约束调用此工具需要什么级别的权限是公开接口还是需要API密钥副作用警告这个工具是否会修改数据、发送邮件或产生费用必须在文档中显著标出。错误处理建议当工具执行失败时通常是什么原因模型或系统应该尝试重试、降级处理还是直接向用户报错这四个层次共同构成了一份“可执行文档”。它不再是被动参考的说明书而是主动参与系统运行的、一等公民的“代码”。3. Skills System 如何运作从文档到执行的魔法理解了什么是“工具文档”我们再来看看OpenClaw的Skills System是如何让这些文档“活”起来的。整个过程可以看作一个精密的协作流水线涉及多个组件。3.1 技能Skill的注册与索引首先开发者将写好的工具文档通常是Markdown或特定格式的文本文件放入一个指定的技能目录。OpenClaw的后台服务会扫描这个目录对每一份文档进行处理解析与切片将长文档按逻辑切分成多个语义块如概述、输入说明、输出说明、执行步骤、注意事项。向量化嵌入使用文本嵌入模型如OpenAI的text-embedding-3-small或开源的BGE模型为每个语义块生成高维向量表示并存入向量数据库如Chroma、Weaviate、Pinecone。元数据提取同时系统会从文档中提取关键元数据如工具名称、功能分类、所需权限等存入传统数据库或索引中用于快速过滤。这个过程的核心是将非结构化的文档转化为结构化的、可检索的知识。向量索引负责处理模糊的语义匹配而元数据索引负责处理精确的属性过滤。3.2 技能的选择与匹配当用户发出请求当用户与搭载了OpenClaw的AI Agent交互时一个核心问题产生了现在应该使用哪个或哪几个技能系统不会一次性将所有技能文档都塞给大模型那样会超出上下文长度且干扰判断。其工作流程如下意图初步识别系统先将用户的当前查询和历史对话上下文组合成一个简短的“意图描述”。向量检索用这个“意图描述”的向量去向量数据库中做相似度搜索Similarity Search召回最相关的若干个例如Top 5技能文档片段。元数据过滤结合当前会话的上下文如用户身份、权限级别对召回的结果进行过滤排除掉用户无权访问或不适合当前场景的技能。LLM最终裁决将过滤后的、最相关的几个技能文档片段连同用户问题和上下文一起提交给大模型如GPT-4。向模型提问“基于以下可用的工具描述哪个工具最适合解决用户当前的问题请说明理由并严格按照该工具文档要求的格式输出调用参数。”这里大模型扮演了“资深架构师”或“技术选型专家”的角色。它阅读精简后的工具文档理解其功能边界并做出最终选择。“文档即工具”的优势在此凸显模型是在理解工具“能做什么”和“怎么做”的基础上做选择而不是仅仅根据一个函数名和简短描述来盲猜。3.3 技能的执行与结果整合一旦模型选定了工具并输出了结构化的调用参数Skills System的执行引擎就开始工作参数验证与适配引擎拿到参数后会去找到该工具的完整文档根据文档中“执行逻辑”部分的描述将模型输出的参数映射到真正的执行体本地函数或API请求。这个过程可能包含简单的类型转换或默认值填充。安全沙箱与执行执行可能在受控的沙箱环境中进行特别是对于执行本地代码的技能。对于API调用则会管理认证、重试、超时等网络问题。结果处理与反馈执行完成后原始结果会被返回。系统可能会根据工具文档中定义的“输出格式”对结果进行初步的清洗和格式化然后再交还给大模型。LLM生成最终回复大模型收到工具执行的确切结果后结合最初的用户问题生成一段自然、流畅、信息完整的最终回复呈现给用户。整个流程形成了一个“规划 - 检索 - 选择 - 执行 - 整合”的闭环。文档自始至终都是信息流转的核心载体。4. 为什么这是扩展的灵魂对比传统模式的降维打击现在让我们把“文档即工具”模式与传统的“函数即工具”模式放在一起对比你就能明白为什么前者在扩展性上具有压倒性优势。4.1 扩展的摩擦系数极低传统模式添加一个新工具 编写函数代码 编写函数描述可能还要更新类型定义 重新部署/重启服务。这是一个“开发-部署”的硬性流程需要程序员介入。文档模式添加一个新工具 编写一份Markdown文档 放入技能目录。系统会自动索引它。任何能写文档的人产品经理、技术支持、领域专家都可以扩展系统能力。这实现了能力的“热插拔”扩展的摩擦系数几乎为零。4.2 工具的可理解性与可组合性爆炸式增长传统模式工具的描述通常很短一两句话模型和开发者都难以深入理解其内部逻辑、副作用和边界条件。工具之间是黑盒组合使用容易出错。文档模式工具的完整说明书对模型和开发者都是透明的。模型可以阅读文档理解“发送邮件”工具需要SMTP配置而“生成报告”工具的输出正好可以作为邮件的附件内容。这使得模型能进行更复杂、更可靠的工具链Tool Chain编排。开发者也能通过阅读文档轻松地将多个技能组合成更强大的“超级技能”Meta-Skill。4.3 对长上下文和复杂逻辑的友好性传统模式工具逻辑被固化在代码中。如果某个工具需要根据复杂条件动态调整行为要么需要编写更复杂的函数代码膨胀要么需要拆分成多个小工具管理混乱。文档模式复杂逻辑可以直接用文字描述在文档中。例如一个“智能客服转人工”的技能其文档可以详细描述“当用户情绪关键词为‘愤怒’、‘投诉’且问题涉及‘退款’时执行转人工流程否则继续尝试用知识库解答。”模型可以理解并执行这种用自然语言编写的业务规则这相当于把一部分业务逻辑的编写权从编程语言移交给了自然语言。4.4 调试与维护的人机协同当技能执行出错时传统模式开发者查看函数代码的日志和错误堆栈。模型对此一无所知只能给出笼统的报错。文档模式开发者和模型可以一起阅读出错的技能文档。开发者可以快速检查文档中描述的API端点是否变更而模型则可以反思“我根据文档提取的参数{‘城市’: ‘北京市’}但API似乎要求{‘city’: ‘Beijing’}是不是文档中的示例格式需要更新” 这形成了一种人机协同维护的良性循环。5. 实战设计一个优秀的“工具文档”理念再好落地才是关键。如何为OpenClaw Skills System撰写一份高质量的“工具文档”以下是一个实战模板和核心要点。5.1 标准文档结构模板# 技能名称[清晰、动词开头的名称如“查询实时天气”] ## 功能描述 用1-2句话清晰说明这个工具的核心用途。这是向量检索匹配的主要依据。 *示例根据用户提供的城市名称查询该城市当前的天气状况、温度和未来24小时预报。* ## 调用方式 描述模型应如何识别和调用此工具。使用自然语言说明所需的输入。 *示例当用户询问某个地方的天气时你可以使用本工具。你需要从用户的问题中提取出明确的城市名称例如“北京”、“New York”。如果用户未明确指定你可以通过反问确认。* ## 输入参数说明 虽然不强制固定键名但应给出清晰的指引和示例。 *示例* * **必需信息**城市名称支持中文或英文。 * **示例输入** * 用户说“上海天气怎么样” - 提取信息{location: 上海} * 用户说“Whats the weather in London?” - 提取信息{location: London} ## 执行逻辑 这是工具如何工作的核心。必须清晰、无歧义。 1. **API调用** * **端点**GET https://api.weather.com/v3/current * **查询参数**location{提取的城市名} * **请求头**Authorization: Bearer {系统配置的API_KEY} 2. **错误处理** * 如果API返回404可能是城市名不存在应提示用户确认。 * 如果API返回401是认证失败需记录日志并通知管理员。 * 网络超时5秒自动重试1次。 ## 输出格式 定义工具执行成功后的返回数据结构便于模型理解和后续处理。 *示例* json { success: true, data: { city: 上海, current: { weather: 多云, temp_c: 22, feelslike_c: 24, humidity: 65 }, forecast: [ {hour: 14:00, weather: 晴, temp_c: 24}, {hour: 17:00, weather: 多云, temp_c: 23} ] }, source: Weather.com, timestamp: 2023-10-27T14:30:00Z }注意事项与边界权限本工具为公开接口无需特殊权限。速率限制每分钟最多调用10次。数据范围仅支持全球主要城市。对于县级以下地区可能无法查询。副作用无。此为只读查询操作。### 5.2 撰写核心要点与避坑指南 1. **描述重于定义**多用“需要”、“应该”、“例如”少用“必须参数名为xxx”。给模型理解的空间而不是设定死板的规则。 2. **示例是黄金**输入输出示例至关重要。好的示例能极大地提高模型提取参数和格式化结果的准确率。至少提供2-3个不同风格的示例。 3. **坦诚边界条件**明确说明工具会失败的情况网络、认证、输入无效等并给出建议的后续动作如“建议用户更换城市名重试”。这能提升AI Agent的鲁棒性。 4. **避免内部术语**文档是给“通用AI”看的应使用领域内通用词汇而不是你们公司内部的系统简称或代码变量名。 5. **版本化你的文档**当工具依赖的API或内部逻辑变更时记得更新文档并在开头注明版本或最后更新时间。可以考虑在技能目录中引入简单的版本管理。 ## 6. 面临的挑战与最佳实践 “文档即工具”并非银弹它带来便利的同时也引入了新的挑战。 ### 6.1 挑战一文档质量参差不齐 劣质的文档模糊、矛盾、过时会导致模型错误地选择或调用工具。**解决方案**是建立文档的“质检”流程。可以 - 编写文档的lint规则如必须包含“输入示例”、“输出格式”章节。 - 在技能注册时用一个“评审LLM”自动扫描文档检查其清晰度和完整性给出评分或修改建议。 - 建立人工审核机制特别是对核心、高风险的工具。 ### 6.2 挑战二检索精度与上下文长度 技能库庞大后如何快速精准地检索到最相关的几个工具如何避免给模型提供过多的无关文档浪费上下文窗口 - **解决方案**采用**分层检索**策略。先利用元数据工具分类、权限标签做快速粗筛再用向量检索在粗筛结果里做精排。同时可以训练一个轻量级的“意图分类器”在第一步更准确地圈定工具范围。 ### 6.3 挑战三执行安全 任何人都能通过添加文档来扩展技能这带来了安全风险。一个恶意或编写不当的文档可能引导模型执行危险操作如删除文件、无限循环。 - **解决方案**必须建立严格的**技能沙箱和权限模型**。 - **权限分级**每个技能文档必须声明所需权限等级如公开、用户级、管理员级。系统根据当前会话用户权限进行过滤。 - **执行沙箱**对于执行本地代码或系统命令的技能必须在严格的资源限制CPU、内存、网络、文件系统访问沙箱中运行。 - **敏感操作审批**对于“删除”、“发送”、“支付”等敏感操作可以设计流程要求模型在执行前必须向用户明确确认或者需要额外的授权令牌。 ### 6.4 最佳实践总结 1. **始于场景而非技术**不要想着“我们有个XX API把它做成技能”。而应该从用户场景出发“用户经常需要做XX事我们如何用一个或一组技能来满足他”先设计对话流和用户意图再为之编写或组合技能文档。 2. **保持文档的原子性**一个技能文档最好只做一件事并把它做好。原子性的技能更容易被理解、检索和组合。复杂的业务流程通过让模型顺序调用多个原子技能来完成。 3. **建立技能集市与文化**鼓励团队所有人而不仅仅是工程师贡献技能文档。可以建立一个内部的“技能集市”让大家可以浏览、使用、评价他人贡献的技能。这能极大激发创造力。 4. **持续观察与迭代**密切监控技能的被调用情况、成功率和用户反馈。对于经常被误用或失败率高的技能回头去优化它的文档——通常是补充更明确的示例或边界说明。 “文档即工具”在OpenClaw中不仅仅是一个实现细节它是一种哲学一种将人类知识、机器可执行代码和AI自然语言理解能力无缝桥接起来的架构范式。它降低了AI应用开发的门槛将扩展的权力从代码仓库移交到了知识库。当你下一次设计一个AI系统时不妨思考一下你的“工具”真的需要被预先编译成函数吗还是说一份写好的说明书本身就是最灵活、最强大的工具
1. 从一个“反直觉”的架构选择说起如果你关注过一些现代AI应用框架比如LangChain、Semantic Kernel你会发现它们都在强调一个概念工具Tool。在这些框架里工具通常被定义为一个函数它有明确的输入参数、输出格式和功能描述。开发者需要手动编写这些函数然后注册到系统中供大模型LLM调用。这听起来很合理对吧一个清晰的接口一个可控的执行单元。但OpenClaw选择了一条看起来有点“偷懒”甚至“反直觉”的路文档即工具Document as Tool。初看这个设计你可能会疑惑文档是静态的、非结构化的文本怎么能直接当工具用这岂不是把复杂度都扔给了大模型让模型自己去“阅读理解”然后“自由发挥”这靠谱吗这正是OpenClaw架构的精妙之处也是其扩展性的灵魂所在。它没有把工具定义为一个需要严格编程的“黑盒”函数而是将其开放为一个可以被灵活解读和执行的“白盒”文档。这个设计背后是对AI Agent能力边界、开发效率以及系统灵活性的深刻思考。今天我们就来彻底拆解OpenClaw的Skills System看看“文档即工具”这个理念是如何从底层重塑我们构建智能应用的方式的。2. 拆解“文档即工具”不止是README那么简单当我们说“文档即工具”时指的究竟是什么它绝对不是简单地把一个API的使用说明扔给模型就完事了。在OpenClaw的语境下一个合格的“工具文档”是一个自包含、可执行、可解释的指令集。它至少包含以下几个核心层次2.1 第一层功能意图的自然语言描述这是最表层也是给大模型看的“接口”。它用人类和AI都能理解的语言清晰地说明这个工具是干什么的。例如一个“天气查询”工具的文档开头可能是“本工具用于查询指定城市当前及未来几天的天气情况。你需要提供城市名称作为输入。”关键在于这个描述不预设固定的参数名和格式。它只说“需要城市名称”而不强制规定参数叫city_name还是location。这降低了大模型调用时的“语法”匹配难度模型只需要理解意图并提取关键信息即可。2.2 第二层输入输出的结构化提示虽然不强制固定格式但好的工具文档会通过示例和结构化描述引导模型输出易于后续处理的格式。这通常在文档中后部体现。例如在描述了功能后文档会补充输入示例 用户问题“北京今天天气怎么样” 工具应提取的信息{“城市”: “北京”} 输出格式 工具执行后将返回一个JSON对象包含以下字段 - city: 城市名 - weather: 天气状况如晴、多云、雨 - temperature: 温度单位摄氏度 - report_time: 数据更新时间这种结构化的提示Structured Prompt充当了“柔性接口”既给了模型灵活性又保证了输出结果的可预测性和可编程性。2.3 第三层执行逻辑与外部依赖声明这是文档的“引擎”部分。它需要说明当模型识别出意图并提取出参数后具体如何执行。这里可能包含几种情况本地函数调用直接调用系统中一个预先编写好的Python函数并将提取的参数传递给它。文档中需要指明函数名和参数映射关系。API调用描述一个HTTP请求的端点Endpoint、方法GET/POST、所需的Headers、Body结构等。文档本身就是一份API手册。复合操作流程描述一个多步骤的操作序列例如“先查询数据库A再用结果去调用API B最后格式化输出”。这可以用伪代码或清晰的步骤列表来描述。为什么要把执行逻辑也写在文档里这恰恰是“文档即工具”与“函数即工具”的核心区别。函数是封装的、不透明的而文档是开放的、可审阅的。任何一个开发者或另一个AI阅读这份文档都能立刻明白这个工具是如何工作的依赖了哪些外部服务可能存在什么风险如网络超时、认证失败。这极大地提升了系统的可理解性和可维护性。2.4 第四层上下文、约束与安全边界一份负责任的工具文档还必须定义它的使用边界。上下文要求这个工具需要在什么会话上下文中使用例如一个“修改订单”的工具可能需要用户已经登录并拥有一个有效的订单ID在上下文中。权限约束调用此工具需要什么级别的权限是公开接口还是需要API密钥副作用警告这个工具是否会修改数据、发送邮件或产生费用必须在文档中显著标出。错误处理建议当工具执行失败时通常是什么原因模型或系统应该尝试重试、降级处理还是直接向用户报错这四个层次共同构成了一份“可执行文档”。它不再是被动参考的说明书而是主动参与系统运行的、一等公民的“代码”。3. Skills System 如何运作从文档到执行的魔法理解了什么是“工具文档”我们再来看看OpenClaw的Skills System是如何让这些文档“活”起来的。整个过程可以看作一个精密的协作流水线涉及多个组件。3.1 技能Skill的注册与索引首先开发者将写好的工具文档通常是Markdown或特定格式的文本文件放入一个指定的技能目录。OpenClaw的后台服务会扫描这个目录对每一份文档进行处理解析与切片将长文档按逻辑切分成多个语义块如概述、输入说明、输出说明、执行步骤、注意事项。向量化嵌入使用文本嵌入模型如OpenAI的text-embedding-3-small或开源的BGE模型为每个语义块生成高维向量表示并存入向量数据库如Chroma、Weaviate、Pinecone。元数据提取同时系统会从文档中提取关键元数据如工具名称、功能分类、所需权限等存入传统数据库或索引中用于快速过滤。这个过程的核心是将非结构化的文档转化为结构化的、可检索的知识。向量索引负责处理模糊的语义匹配而元数据索引负责处理精确的属性过滤。3.2 技能的选择与匹配当用户发出请求当用户与搭载了OpenClaw的AI Agent交互时一个核心问题产生了现在应该使用哪个或哪几个技能系统不会一次性将所有技能文档都塞给大模型那样会超出上下文长度且干扰判断。其工作流程如下意图初步识别系统先将用户的当前查询和历史对话上下文组合成一个简短的“意图描述”。向量检索用这个“意图描述”的向量去向量数据库中做相似度搜索Similarity Search召回最相关的若干个例如Top 5技能文档片段。元数据过滤结合当前会话的上下文如用户身份、权限级别对召回的结果进行过滤排除掉用户无权访问或不适合当前场景的技能。LLM最终裁决将过滤后的、最相关的几个技能文档片段连同用户问题和上下文一起提交给大模型如GPT-4。向模型提问“基于以下可用的工具描述哪个工具最适合解决用户当前的问题请说明理由并严格按照该工具文档要求的格式输出调用参数。”这里大模型扮演了“资深架构师”或“技术选型专家”的角色。它阅读精简后的工具文档理解其功能边界并做出最终选择。“文档即工具”的优势在此凸显模型是在理解工具“能做什么”和“怎么做”的基础上做选择而不是仅仅根据一个函数名和简短描述来盲猜。3.3 技能的执行与结果整合一旦模型选定了工具并输出了结构化的调用参数Skills System的执行引擎就开始工作参数验证与适配引擎拿到参数后会去找到该工具的完整文档根据文档中“执行逻辑”部分的描述将模型输出的参数映射到真正的执行体本地函数或API请求。这个过程可能包含简单的类型转换或默认值填充。安全沙箱与执行执行可能在受控的沙箱环境中进行特别是对于执行本地代码的技能。对于API调用则会管理认证、重试、超时等网络问题。结果处理与反馈执行完成后原始结果会被返回。系统可能会根据工具文档中定义的“输出格式”对结果进行初步的清洗和格式化然后再交还给大模型。LLM生成最终回复大模型收到工具执行的确切结果后结合最初的用户问题生成一段自然、流畅、信息完整的最终回复呈现给用户。整个流程形成了一个“规划 - 检索 - 选择 - 执行 - 整合”的闭环。文档自始至终都是信息流转的核心载体。4. 为什么这是扩展的灵魂对比传统模式的降维打击现在让我们把“文档即工具”模式与传统的“函数即工具”模式放在一起对比你就能明白为什么前者在扩展性上具有压倒性优势。4.1 扩展的摩擦系数极低传统模式添加一个新工具 编写函数代码 编写函数描述可能还要更新类型定义 重新部署/重启服务。这是一个“开发-部署”的硬性流程需要程序员介入。文档模式添加一个新工具 编写一份Markdown文档 放入技能目录。系统会自动索引它。任何能写文档的人产品经理、技术支持、领域专家都可以扩展系统能力。这实现了能力的“热插拔”扩展的摩擦系数几乎为零。4.2 工具的可理解性与可组合性爆炸式增长传统模式工具的描述通常很短一两句话模型和开发者都难以深入理解其内部逻辑、副作用和边界条件。工具之间是黑盒组合使用容易出错。文档模式工具的完整说明书对模型和开发者都是透明的。模型可以阅读文档理解“发送邮件”工具需要SMTP配置而“生成报告”工具的输出正好可以作为邮件的附件内容。这使得模型能进行更复杂、更可靠的工具链Tool Chain编排。开发者也能通过阅读文档轻松地将多个技能组合成更强大的“超级技能”Meta-Skill。4.3 对长上下文和复杂逻辑的友好性传统模式工具逻辑被固化在代码中。如果某个工具需要根据复杂条件动态调整行为要么需要编写更复杂的函数代码膨胀要么需要拆分成多个小工具管理混乱。文档模式复杂逻辑可以直接用文字描述在文档中。例如一个“智能客服转人工”的技能其文档可以详细描述“当用户情绪关键词为‘愤怒’、‘投诉’且问题涉及‘退款’时执行转人工流程否则继续尝试用知识库解答。”模型可以理解并执行这种用自然语言编写的业务规则这相当于把一部分业务逻辑的编写权从编程语言移交给了自然语言。4.4 调试与维护的人机协同当技能执行出错时传统模式开发者查看函数代码的日志和错误堆栈。模型对此一无所知只能给出笼统的报错。文档模式开发者和模型可以一起阅读出错的技能文档。开发者可以快速检查文档中描述的API端点是否变更而模型则可以反思“我根据文档提取的参数{‘城市’: ‘北京市’}但API似乎要求{‘city’: ‘Beijing’}是不是文档中的示例格式需要更新” 这形成了一种人机协同维护的良性循环。5. 实战设计一个优秀的“工具文档”理念再好落地才是关键。如何为OpenClaw Skills System撰写一份高质量的“工具文档”以下是一个实战模板和核心要点。5.1 标准文档结构模板# 技能名称[清晰、动词开头的名称如“查询实时天气”] ## 功能描述 用1-2句话清晰说明这个工具的核心用途。这是向量检索匹配的主要依据。 *示例根据用户提供的城市名称查询该城市当前的天气状况、温度和未来24小时预报。* ## 调用方式 描述模型应如何识别和调用此工具。使用自然语言说明所需的输入。 *示例当用户询问某个地方的天气时你可以使用本工具。你需要从用户的问题中提取出明确的城市名称例如“北京”、“New York”。如果用户未明确指定你可以通过反问确认。* ## 输入参数说明 虽然不强制固定键名但应给出清晰的指引和示例。 *示例* * **必需信息**城市名称支持中文或英文。 * **示例输入** * 用户说“上海天气怎么样” - 提取信息{location: 上海} * 用户说“Whats the weather in London?” - 提取信息{location: London} ## 执行逻辑 这是工具如何工作的核心。必须清晰、无歧义。 1. **API调用** * **端点**GET https://api.weather.com/v3/current * **查询参数**location{提取的城市名} * **请求头**Authorization: Bearer {系统配置的API_KEY} 2. **错误处理** * 如果API返回404可能是城市名不存在应提示用户确认。 * 如果API返回401是认证失败需记录日志并通知管理员。 * 网络超时5秒自动重试1次。 ## 输出格式 定义工具执行成功后的返回数据结构便于模型理解和后续处理。 *示例* json { success: true, data: { city: 上海, current: { weather: 多云, temp_c: 22, feelslike_c: 24, humidity: 65 }, forecast: [ {hour: 14:00, weather: 晴, temp_c: 24}, {hour: 17:00, weather: 多云, temp_c: 23} ] }, source: Weather.com, timestamp: 2023-10-27T14:30:00Z }注意事项与边界权限本工具为公开接口无需特殊权限。速率限制每分钟最多调用10次。数据范围仅支持全球主要城市。对于县级以下地区可能无法查询。副作用无。此为只读查询操作。### 5.2 撰写核心要点与避坑指南 1. **描述重于定义**多用“需要”、“应该”、“例如”少用“必须参数名为xxx”。给模型理解的空间而不是设定死板的规则。 2. **示例是黄金**输入输出示例至关重要。好的示例能极大地提高模型提取参数和格式化结果的准确率。至少提供2-3个不同风格的示例。 3. **坦诚边界条件**明确说明工具会失败的情况网络、认证、输入无效等并给出建议的后续动作如“建议用户更换城市名重试”。这能提升AI Agent的鲁棒性。 4. **避免内部术语**文档是给“通用AI”看的应使用领域内通用词汇而不是你们公司内部的系统简称或代码变量名。 5. **版本化你的文档**当工具依赖的API或内部逻辑变更时记得更新文档并在开头注明版本或最后更新时间。可以考虑在技能目录中引入简单的版本管理。 ## 6. 面临的挑战与最佳实践 “文档即工具”并非银弹它带来便利的同时也引入了新的挑战。 ### 6.1 挑战一文档质量参差不齐 劣质的文档模糊、矛盾、过时会导致模型错误地选择或调用工具。**解决方案**是建立文档的“质检”流程。可以 - 编写文档的lint规则如必须包含“输入示例”、“输出格式”章节。 - 在技能注册时用一个“评审LLM”自动扫描文档检查其清晰度和完整性给出评分或修改建议。 - 建立人工审核机制特别是对核心、高风险的工具。 ### 6.2 挑战二检索精度与上下文长度 技能库庞大后如何快速精准地检索到最相关的几个工具如何避免给模型提供过多的无关文档浪费上下文窗口 - **解决方案**采用**分层检索**策略。先利用元数据工具分类、权限标签做快速粗筛再用向量检索在粗筛结果里做精排。同时可以训练一个轻量级的“意图分类器”在第一步更准确地圈定工具范围。 ### 6.3 挑战三执行安全 任何人都能通过添加文档来扩展技能这带来了安全风险。一个恶意或编写不当的文档可能引导模型执行危险操作如删除文件、无限循环。 - **解决方案**必须建立严格的**技能沙箱和权限模型**。 - **权限分级**每个技能文档必须声明所需权限等级如公开、用户级、管理员级。系统根据当前会话用户权限进行过滤。 - **执行沙箱**对于执行本地代码或系统命令的技能必须在严格的资源限制CPU、内存、网络、文件系统访问沙箱中运行。 - **敏感操作审批**对于“删除”、“发送”、“支付”等敏感操作可以设计流程要求模型在执行前必须向用户明确确认或者需要额外的授权令牌。 ### 6.4 最佳实践总结 1. **始于场景而非技术**不要想着“我们有个XX API把它做成技能”。而应该从用户场景出发“用户经常需要做XX事我们如何用一个或一组技能来满足他”先设计对话流和用户意图再为之编写或组合技能文档。 2. **保持文档的原子性**一个技能文档最好只做一件事并把它做好。原子性的技能更容易被理解、检索和组合。复杂的业务流程通过让模型顺序调用多个原子技能来完成。 3. **建立技能集市与文化**鼓励团队所有人而不仅仅是工程师贡献技能文档。可以建立一个内部的“技能集市”让大家可以浏览、使用、评价他人贡献的技能。这能极大激发创造力。 4. **持续观察与迭代**密切监控技能的被调用情况、成功率和用户反馈。对于经常被误用或失败率高的技能回头去优化它的文档——通常是补充更明确的示例或边界说明。 “文档即工具”在OpenClaw中不仅仅是一个实现细节它是一种哲学一种将人类知识、机器可执行代码和AI自然语言理解能力无缝桥接起来的架构范式。它降低了AI应用开发的门槛将扩展的权力从代码仓库移交到了知识库。当你下一次设计一个AI系统时不妨思考一下你的“工具”真的需要被预先编译成函数吗还是说一份写好的说明书本身就是最灵活、最强大的工具
