ZeroClaw 技能库自维护机制解读后台 Skill Review Agent 的提示词与实现【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclawZeroClaw 在每一轮对话结束后都会运行一个不可见的技能审查进程Skill Review Agent它复盘刚结束的对话判断是否需要对已安装的技能库做出增删改。本文以crates/zeroclaw-runtime/src/skills/review_prompt.md这份审查 Agent 的系统提示词为骨架结合其背后的 Rust 实现review.rs、skill_manage.rs 与配置定义 schema.rs讲清楚审查 Agent 的角色定位、技能格式标准、触发信号、操作优先级、安全边界以及如何配置和调优这一自改进机制。读完你将掌握 ZeroClaw 技能库越用越准的内部工作原理并能为自己的部署定制审查策略。一、背景什么是 ZeroClaw 的后台 Skill Review Agentreview_prompt.md的第一段明确了审查 Agent 的定位You are running as ZeroClaws background SKILL REVIEW agent. Your job is to look at the conversation that just finished and decide whether anything that happened should change the installed skill library.几个关键约束被写死在提示词里后台运行它不延续用户可见的对话用户看不到审查 Agent 的直接输出只看到一行采取了哪些动作的摘要。预算意识摘要只有一行所以审查 Agent 要么做出值得展示的修改要么什么都不做。注意区分审查的是技能库是否需要变化而不是对用户问题的继续回答。在源码中这份提示词通过include_str!直接编译进二进制// crates/zeroclaw-runtime/src/skills/review.rs#L13 const REVIEW_PROMPT: str include_str!(review_prompt.md);并且在组装审查输入时会在提示词末尾追加本轮会话的失败技能提示fn build_review_input(failed_slugs: [String]) - String { let hint if failed_slugs.is_empty() { Hint: no skill executions failed this session..to_string() } else { format!( Hint: these skills FAILED this session — investigate before patching: {}, failed_slugs.join(, ) ) }; format!({REVIEW_PROMPT}\n\n---\n\n{hint}\n) }这段代码review.rs说明审查 Agent 并非凭空判断而是携带了本轮哪些技能执行失败的上下文作为强信号。二、技能格式标准agentskills.io 规范与 SKILL.md提示词规定 ZeroClaw 技能遵循 agentskills.io 标准每个技能位于~/.zeroclaw/workspace/skills/slug/由一个带 YAML front-matter 的SKILL.md文件定义--- name: example-skill description: One-line summary used at skill discovery. version: 0.2.0 license: MIT --- # Example Skill The Markdown body holds the actual instructions the agent reads when this skill activates...要点拆解front-matter 是技能的身份证name发现/引用用、description一行摘要用于技能发现、version、license等元数据都在这里声明。Markdown 正文才是技能本体技能激活时 Agent 读取的就是这段正文。可选同级目录references/参考资料、templates/模板、scripts/可执行脚本。类级技能原则Class-level skills提示词给出了一个非常重要的设计哲学——小而精的类级技能集而不是一长串单次会话的条目The goal is a SMALL set of CLASS-LEVEL skills, each rich and well-documented — NOT a sprawling list of single-session entries.它给出的正反例非常直观❌ 错误fix-bug-with-foo-on-tuesday把某个具体 bug 命名为技能✅ 正确debugging 一个references/foo-quirks.md支持文件也就是说技能应该按一类任务组织具体细节下沉到 references/ 文件而不是为每一次偶发问题新建技能。这一规范塑造的是审查 Agent 如何更新HOW to update而不是是否更新WHETHER to update。源码侧constants.rs 固化了对该规范的文件名约定pub const SKILL_MANIFEST_FILENAME: str SKILL.md; // 规范清单文件 pub const SKILL_DEPRECATED_MANIFESTS: [str] [SKILL.toml, manifest.toml]; // 兼容旧格式 pub const SKILL_SCAFFOLD_SUBDIRS: [str] [scripts, references, assets]; // 脚手架子目录 pub const SKILL_ARCHIVE_DIR_NAME: str _deleted; // 归档根目录从源码结构看ZeroClaw 的加载器mod.rs 中的load_skills_from_directory_uncached优先尝试SKILL.toml→manifest.tomlregistry 格式→SKILL.md说明SKILL.md是规范标准而 TOML 清单是向后兼容的旧格式新写入一律使用SKILL.md常量名即证。三、审查 Agent 的触发信号Signals to act on提示词明确列出以下任意一条都足以触发一次技能库变更动作。信号类别具体表现处理方式风格/语气/格式纠正stop doing X、this is too verbose、dont format like this、remember this把教训写进管理该任务的技能正文让下一轮会话一开始就知道工作流/步骤纠正用户纠正了操作的顺序或步骤把纠正编码为相关技能正文中的坑pitfall或显式步骤出现非平凡技巧有分量的技术、修复、workaround、调试路径或工具用法模式浮现记录到未来的会话会去找的地方技能本身出错本轮被调用的技能缺步骤、过时或内容错误立即修补该技能提示词特别强调技能 FAILED 是强信号但不是唯一信号。要分析失败原因——是技能本身错了还是环境错了只有前者才是技能问题。源码中loop_.rs 在回合结束后从历史中提取失败技能列表并传给审查 forklet failed_slugs: VecString crate::skills::improver::extract_skill_executions_from_history(history) .into_iter() .filter_map(|(slug, ok)| if ok { None } else { Some(slug) }) .collect();这正对应build_review_input中追加的 these skills FAILED this session — investigate before patching 提示审查 Agent 会优先调查这些失败技能。四、操作优先级Preference order从补丁到新建的决策树提示词给出了一个严格的决策顺序——选择最靠前的、匹配当前信号的行动PATCH 当前加载或最近调用的技能回看会话中 Agent 调用过的技能如果某个技能覆盖了新学习的领域优先补丁它——它是正在起作用的技能。PATCH 现有 umbrella伞形技能用skills_list和skill_view找到覆盖该领域的类级技能添加小节、pitfall 或扩宽 description。在现有 umbrella 下添加支持文件通过skill_manage的write_file动作写入references/、templates/或scripts/下的文件并在 umbrella 的 SKILL.md 正文中加一行指针。三种合法文件类型references/topic.md—— 会话级细节错误记录、复现配方、provider 怪癖或浓缩知识库引用的研究、API 文档、领域笔记templates/name.ext—— 供复制修改的起始文件配置样板、脚手架、已知良好示例scripts/name.ext—— 可重复执行的动作验证脚本、fixture 生成器、确定性探测。创建新的类级伞形技能仅当现有技能都不覆盖该类别时才创建。命名必须是类级别的绝不能是具体 PR 号、错误字符串、功能代号、孤立库名或fix-X / debug-Y / audit-Z-today这种会话产物。如果这个名字只对今天的任务有意义那就是错的——回到 1/2/3。源码中skill_manage.rs 正是按此契约实现的write_file动作的file_path参数被硬性限定在三个前缀内const ALLOWED_FILE_PREFIXES: [str] [references/, templates/, scripts/];超出前缀、包含..或空字节的路径会被直接拒绝且单个文件内容上限为MAX_FILE_BYTES 256 * 1024字节。这从工具层面保证了支持文件只能落在规范允许的目录结构里。五、不要捕获的内容Do NOT capture提示词专门列出四类禁止沉淀为技能的内容因为它们会变成持久的自我设限在环境变化后反噬环境依赖型失败缺二进制、全新安装报错、迁移后路径不匹配、command not found、未配置的凭据、未安装的包。用户能修好这些——它们不是持久规则。对工具或功能的负面断言browser tools do not work、X is broken、cannot use Y from execute_code。这些会固化成为 Agent 在问题修复数月后仍在引用的拒答。会话内已自行消失的瞬时错误重试能成功时该学的教训是重试模式而不是原始失败本身。一次性任务叙事用户让总结今日市场或分析这个 PR不属于值得建技能的工种。一个重要的补充规则如果工具因环境设置失败应该把修复方案安装命令、配置步骤、要设置的环境变量记录到现有的 setup/troubleshooting 技能下而绝不要以这个工具不能用作为独立约束。六、Nothing to save. 与行动方式How to act提示词指出Nothing to save.是真实选项但不应是默认如果会话顺利、无纠正、无新技术就直接回复Nothing to save.并停止否则就要行动。审查 Agent 可用的工具被刻意收敛为三个源码 review.rs工具类型作用skills_list只读列出已安装技能名称、版本、一行描述用于寻找候选 slugskill_view只读读取单个技能的 SKILL.mdfront-matter 正文预览及 references/templates/scripts 下的支持文件清单skill_manage可写执行patch原子重写 SKILL.md、write_file新增支持文件、archive移入 .archive/关于patch的具体纪律提示词强调提供完整的新文件内容YAML front-matter Markdown 正文保持 front-matter 中必填的name字段不变保留正文的 Markdown 结构——只增改内容除非现有正文确实错误否则不要推倒重写reason参数要具体——它会成为技能审计轨迹audit trail的一部分。源码实现与之一一对应。patch在写入后立即执行变更后审计post-mutation audit先做轻量 YAML front-matter 校验再用与加载器/安装器相同的audit_skill_directory_with_options跑完整审计任何一步失败都会回滚到写入前的快照skill_manage.rsif !report.is_clean() { restore_snapshot(md_path, pre_snapshot.as_deref()).await; return Err(format!( Patch wrote but skill failed audit (rolled back): {}, report.summary() )); }同时patch会经过 improver.rs 的SkillImprover冷却检查如果技能处于冷却期updated_at距今小于cooldown_secs补丁会被拒绝并返回 Skill deploy is on cooldown — try again later。测试用例skill_manage_patch_blocks_when_skill_is_on_cooldown专门验证了这一行为。成功的补丁还会在 front-matter 中写入updated_at、improvement_reason等审计字段并在正文追加!-- Improvement:注释块见测试skill_manage_patch_atomically_updates_md的断言。七、后台审查 fork 的源码实现原理review_prompt.md描述的是审查 Agent 的行为规范而 review.rs 是承载它的执行引擎。核心入口是maybe_run_skill_review其执行链值得逐段拆解。7.1 三重门控先于一切的成本控制在 fork 被真正拉起之前有三个逐级递减的检查总开关config.enabled为false直接返回——这是一个默认关闭的 opt-in 功能配置默认值见下文。递归守卫通过task_local!的SKILL_REVIEW_ACTIVE标记防止嵌套触发——如果审查 fork 本身又触发了回合后 hook会递归烧掉大量 LLM token 直到超时守卫让它立即返回review.rs。迭代预算should_trigger统计历史中role tool的消息数每条代表一次完成的工具调用达到nudge_interval_iterations阈值才触发阈值为0时禁用基于迭代的触发review.rs。配套的单元测试覆盖了这三种门控should_trigger_zero_threshold_disables、should_trigger_fires_at_threshold、should_trigger_holds_below_threshold。7.2 受限工具集与静默运行审查 fork 通过ScopedToolRegistry::assemble组装刻意只用预先构建的 3 个工具skills_list、skill_view、skill_manage并关闭所有汇编扩展无 peripherals、无 MCP、无技能注入、无记忆条带且不应用真实 agent 的 allow/deny 策略——源码注释解释得很清楚真实策略可能丢弃某个技能工具而默认策略下汇编内置过滤是恒等函数能精确复现这 3 个工具。fork 的运行参数同样指向少花 token、别打扰用户temperature: Some(0.3)—— 低温度减少发散silent: true—— 注释写明 low so the fork doesnt rambleparallel_tools: false—— 对有写能力的 fork 强制顺序执行max_tool_iterations取自config.max_review_iterations默认 8封顶 fork 的 LLM 成本channel_name: skill_review、approval: None—— 无人类介入。7.3 一行摘要的生成审查结束后summarize_actions负责把动作压缩成用户能看到的一行摘要review.rs优先级为从collected_receipts中解析动作收据Patched skill x、Wrote references/y.md for skill x、Archived skill z收据为空时从 fork 自身的 tool 消息历史中解析注意父回合的工具消息会被过滤防止泄漏成假摘要见测试summarize_actions_ignores_parent_turn_tool_messages都没有时回退到最终文本第一行最多 80 字符用floor_char_boundary避免多字节字符切片 panic。若摘要为空例如审查 Agent 回复了Nothing to save.则什么都不打印。7.4 配置项与默认值审查 fork 的全部行为由[skills.skill_improvement]配置段控制schema.rs默认值如下配置键类型默认值含义enabledboolfalse启用后台技能审查 fork。必须显式开启opt-in因为该功能允许回合后技能变更cooldown_secsu643600同一技能两次审查之间的最小间隔秒是对任意技能补丁的持久限速nudge_interval_iterationsu3210当前运行累计达到该数量的工具调用迭代后触发一次审查0禁用基于迭代的触发max_review_iterationsu328审查 fork 自身允许的最大工具调用迭代数封顶 fork 的 LLM 成本在用户配置如zeroclaw.toml中的写法示例[skills.skill_improvement] enabled true cooldown_secs 3600 nudge_interval_iterations 10 max_review_iterations 8注意两个联动点触发入口在 loop_.rs 要求config.skills.skill_improvement.enabled为真而skill_manage的补丁路径还会再查一次config.enabledSkill improvement is disabled (enabled: false)。另外审查 fork 复用config.skills.allow_scripts作为变更后审计的脚本策略——如果脚本被禁用写入带脚本的技能会审计失败并回滚。八、安全设计审查 Agent 的写权限边界因为审查 fork 拥有对技能库的写权限ZeroClaw 在工具层做了多层防御skill_manage.rsslug 校验拒绝空 slug、含..、含/、含\、以.开头的 slug从源头阻断路径穿越测试skill_view_rejects_path_traversal覆盖了../etc/passwd、foo/bar、.hidden等输入符号链接防御技能目录本身是 symlink 时拒绝操作SKILL.md是 symlink 时拒绝 patch写入目标存在 symlink 时拒绝写入。原因是canonicalize会穿透 symlink导致starts_with检查被绕过规范路径边界技能目录必须位于规范化后的 skills 根目录之内写入目标父目录、归档目录同理变更后审计与回滚patch与write_file写入后立即用加载器同一套审计逻辑复查失败则回滚patch 恢复快照write_file 恢复旧字节或删除新文件归档命名archive把技能移到 skills 根下的.archive/重名时追加 UTC 时间戳如{slug}-20260919T012345Z避免覆盖。这些设计保证即使审查 Agent 的 LLM 输出出现幻觉或恶意内容也无法逃出技能目录、无法穿透 symlink、无法绕过脚本策略且任何破坏审计的写入都会被原子回滚。九、最佳实践与调优建议结合提示词与源码为你的 ZeroClaw 部署给出可落地的建议先开启审查再观察摘要[skills.skill_improvement] enabled true后每轮结束会打印一行动作摘要patched debugging · wrote file for debugging据此判断审查 Agent 是否在按你的预期工作。审查 fork 在用户回复之后才运行不会拖慢交互loop_.rs 特意在后台工作前先输出最终回复。用冷却值控制补丁频率如果你发现技能被过度改写调大cooldown_secs希望技能更快吸收反馈则调小。注意冷却针对单个技能是持久限速。调校触发频率nudge_interval_iterations控制多少轮工具调用后触发一次审查。长任务可以调低更频繁复盘短交互可以调高以减少 fork 开销设为0可完全禁用基于迭代的触发。封顶审查成本max_review_iterations默认 8是对 fork 的硬预算。如果审查 Agent 经常半途而废可适度上调如果心疼 token就保持默认或下调。把知识放进 references/ 而不是新建技能审查 Agent 会把会话中的具体怪癖写进references/topic.md——这是提示词反复强调的类级技能 支持文件模式请顺着这个方向引导它例如在技能正文里写遇到 provider 特例时记录到 references/provider-quirks.md。不要手动教它捕获环境错误提示词明确禁止把 command not found 之类环境失败沉淀为技能如果某技能常因环境失败正确做法是把修复步骤安装命令、配置项写进该技能的正文或 references/。结语review_prompt.md本质上是一份技能库策展人的岗位说明书它定义了审查 Agent 观察什么信号、怎么归类优先级、边界在哪不捕获清单、三个受限工具、以及如何安全落笔patch 纪律、审计、回滚。配合 review.rs 的执行引擎与 skill_manage.rs 的安全工具集ZeroClaw 把从对话中学习并改进自身工具库做成了一个默认关闭、可配置、有成本上限、有安全护栏的自治闭环。理解了这份提示词与它的实现你就掌握了让 ZeroClaw 技能库持续进化的正确操作方式。【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ZeroClaw 技能库自维护机制：解读后台 Skill Review Agent 的提示词与实现
ZeroClaw 技能库自维护机制解读后台 Skill Review Agent 的提示词与实现【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclawZeroClaw 在每一轮对话结束后都会运行一个不可见的技能审查进程Skill Review Agent它复盘刚结束的对话判断是否需要对已安装的技能库做出增删改。本文以crates/zeroclaw-runtime/src/skills/review_prompt.md这份审查 Agent 的系统提示词为骨架结合其背后的 Rust 实现review.rs、skill_manage.rs 与配置定义 schema.rs讲清楚审查 Agent 的角色定位、技能格式标准、触发信号、操作优先级、安全边界以及如何配置和调优这一自改进机制。读完你将掌握 ZeroClaw 技能库越用越准的内部工作原理并能为自己的部署定制审查策略。一、背景什么是 ZeroClaw 的后台 Skill Review Agentreview_prompt.md的第一段明确了审查 Agent 的定位You are running as ZeroClaws background SKILL REVIEW agent. Your job is to look at the conversation that just finished and decide whether anything that happened should change the installed skill library.几个关键约束被写死在提示词里后台运行它不延续用户可见的对话用户看不到审查 Agent 的直接输出只看到一行采取了哪些动作的摘要。预算意识摘要只有一行所以审查 Agent 要么做出值得展示的修改要么什么都不做。注意区分审查的是技能库是否需要变化而不是对用户问题的继续回答。在源码中这份提示词通过include_str!直接编译进二进制// crates/zeroclaw-runtime/src/skills/review.rs#L13 const REVIEW_PROMPT: str include_str!(review_prompt.md);并且在组装审查输入时会在提示词末尾追加本轮会话的失败技能提示fn build_review_input(failed_slugs: [String]) - String { let hint if failed_slugs.is_empty() { Hint: no skill executions failed this session..to_string() } else { format!( Hint: these skills FAILED this session — investigate before patching: {}, failed_slugs.join(, ) ) }; format!({REVIEW_PROMPT}\n\n---\n\n{hint}\n) }这段代码review.rs说明审查 Agent 并非凭空判断而是携带了本轮哪些技能执行失败的上下文作为强信号。二、技能格式标准agentskills.io 规范与 SKILL.md提示词规定 ZeroClaw 技能遵循 agentskills.io 标准每个技能位于~/.zeroclaw/workspace/skills/slug/由一个带 YAML front-matter 的SKILL.md文件定义--- name: example-skill description: One-line summary used at skill discovery. version: 0.2.0 license: MIT --- # Example Skill The Markdown body holds the actual instructions the agent reads when this skill activates...要点拆解front-matter 是技能的身份证name发现/引用用、description一行摘要用于技能发现、version、license等元数据都在这里声明。Markdown 正文才是技能本体技能激活时 Agent 读取的就是这段正文。可选同级目录references/参考资料、templates/模板、scripts/可执行脚本。类级技能原则Class-level skills提示词给出了一个非常重要的设计哲学——小而精的类级技能集而不是一长串单次会话的条目The goal is a SMALL set of CLASS-LEVEL skills, each rich and well-documented — NOT a sprawling list of single-session entries.它给出的正反例非常直观❌ 错误fix-bug-with-foo-on-tuesday把某个具体 bug 命名为技能✅ 正确debugging 一个references/foo-quirks.md支持文件也就是说技能应该按一类任务组织具体细节下沉到 references/ 文件而不是为每一次偶发问题新建技能。这一规范塑造的是审查 Agent 如何更新HOW to update而不是是否更新WHETHER to update。源码侧constants.rs 固化了对该规范的文件名约定pub const SKILL_MANIFEST_FILENAME: str SKILL.md; // 规范清单文件 pub const SKILL_DEPRECATED_MANIFESTS: [str] [SKILL.toml, manifest.toml]; // 兼容旧格式 pub const SKILL_SCAFFOLD_SUBDIRS: [str] [scripts, references, assets]; // 脚手架子目录 pub const SKILL_ARCHIVE_DIR_NAME: str _deleted; // 归档根目录从源码结构看ZeroClaw 的加载器mod.rs 中的load_skills_from_directory_uncached优先尝试SKILL.toml→manifest.tomlregistry 格式→SKILL.md说明SKILL.md是规范标准而 TOML 清单是向后兼容的旧格式新写入一律使用SKILL.md常量名即证。三、审查 Agent 的触发信号Signals to act on提示词明确列出以下任意一条都足以触发一次技能库变更动作。信号类别具体表现处理方式风格/语气/格式纠正stop doing X、this is too verbose、dont format like this、remember this把教训写进管理该任务的技能正文让下一轮会话一开始就知道工作流/步骤纠正用户纠正了操作的顺序或步骤把纠正编码为相关技能正文中的坑pitfall或显式步骤出现非平凡技巧有分量的技术、修复、workaround、调试路径或工具用法模式浮现记录到未来的会话会去找的地方技能本身出错本轮被调用的技能缺步骤、过时或内容错误立即修补该技能提示词特别强调技能 FAILED 是强信号但不是唯一信号。要分析失败原因——是技能本身错了还是环境错了只有前者才是技能问题。源码中loop_.rs 在回合结束后从历史中提取失败技能列表并传给审查 forklet failed_slugs: VecString crate::skills::improver::extract_skill_executions_from_history(history) .into_iter() .filter_map(|(slug, ok)| if ok { None } else { Some(slug) }) .collect();这正对应build_review_input中追加的 these skills FAILED this session — investigate before patching 提示审查 Agent 会优先调查这些失败技能。四、操作优先级Preference order从补丁到新建的决策树提示词给出了一个严格的决策顺序——选择最靠前的、匹配当前信号的行动PATCH 当前加载或最近调用的技能回看会话中 Agent 调用过的技能如果某个技能覆盖了新学习的领域优先补丁它——它是正在起作用的技能。PATCH 现有 umbrella伞形技能用skills_list和skill_view找到覆盖该领域的类级技能添加小节、pitfall 或扩宽 description。在现有 umbrella 下添加支持文件通过skill_manage的write_file动作写入references/、templates/或scripts/下的文件并在 umbrella 的 SKILL.md 正文中加一行指针。三种合法文件类型references/topic.md—— 会话级细节错误记录、复现配方、provider 怪癖或浓缩知识库引用的研究、API 文档、领域笔记templates/name.ext—— 供复制修改的起始文件配置样板、脚手架、已知良好示例scripts/name.ext—— 可重复执行的动作验证脚本、fixture 生成器、确定性探测。创建新的类级伞形技能仅当现有技能都不覆盖该类别时才创建。命名必须是类级别的绝不能是具体 PR 号、错误字符串、功能代号、孤立库名或fix-X / debug-Y / audit-Z-today这种会话产物。如果这个名字只对今天的任务有意义那就是错的——回到 1/2/3。源码中skill_manage.rs 正是按此契约实现的write_file动作的file_path参数被硬性限定在三个前缀内const ALLOWED_FILE_PREFIXES: [str] [references/, templates/, scripts/];超出前缀、包含..或空字节的路径会被直接拒绝且单个文件内容上限为MAX_FILE_BYTES 256 * 1024字节。这从工具层面保证了支持文件只能落在规范允许的目录结构里。五、不要捕获的内容Do NOT capture提示词专门列出四类禁止沉淀为技能的内容因为它们会变成持久的自我设限在环境变化后反噬环境依赖型失败缺二进制、全新安装报错、迁移后路径不匹配、command not found、未配置的凭据、未安装的包。用户能修好这些——它们不是持久规则。对工具或功能的负面断言browser tools do not work、X is broken、cannot use Y from execute_code。这些会固化成为 Agent 在问题修复数月后仍在引用的拒答。会话内已自行消失的瞬时错误重试能成功时该学的教训是重试模式而不是原始失败本身。一次性任务叙事用户让总结今日市场或分析这个 PR不属于值得建技能的工种。一个重要的补充规则如果工具因环境设置失败应该把修复方案安装命令、配置步骤、要设置的环境变量记录到现有的 setup/troubleshooting 技能下而绝不要以这个工具不能用作为独立约束。六、Nothing to save. 与行动方式How to act提示词指出Nothing to save.是真实选项但不应是默认如果会话顺利、无纠正、无新技术就直接回复Nothing to save.并停止否则就要行动。审查 Agent 可用的工具被刻意收敛为三个源码 review.rs工具类型作用skills_list只读列出已安装技能名称、版本、一行描述用于寻找候选 slugskill_view只读读取单个技能的 SKILL.mdfront-matter 正文预览及 references/templates/scripts 下的支持文件清单skill_manage可写执行patch原子重写 SKILL.md、write_file新增支持文件、archive移入 .archive/关于patch的具体纪律提示词强调提供完整的新文件内容YAML front-matter Markdown 正文保持 front-matter 中必填的name字段不变保留正文的 Markdown 结构——只增改内容除非现有正文确实错误否则不要推倒重写reason参数要具体——它会成为技能审计轨迹audit trail的一部分。源码实现与之一一对应。patch在写入后立即执行变更后审计post-mutation audit先做轻量 YAML front-matter 校验再用与加载器/安装器相同的audit_skill_directory_with_options跑完整审计任何一步失败都会回滚到写入前的快照skill_manage.rsif !report.is_clean() { restore_snapshot(md_path, pre_snapshot.as_deref()).await; return Err(format!( Patch wrote but skill failed audit (rolled back): {}, report.summary() )); }同时patch会经过 improver.rs 的SkillImprover冷却检查如果技能处于冷却期updated_at距今小于cooldown_secs补丁会被拒绝并返回 Skill deploy is on cooldown — try again later。测试用例skill_manage_patch_blocks_when_skill_is_on_cooldown专门验证了这一行为。成功的补丁还会在 front-matter 中写入updated_at、improvement_reason等审计字段并在正文追加!-- Improvement:注释块见测试skill_manage_patch_atomically_updates_md的断言。七、后台审查 fork 的源码实现原理review_prompt.md描述的是审查 Agent 的行为规范而 review.rs 是承载它的执行引擎。核心入口是maybe_run_skill_review其执行链值得逐段拆解。7.1 三重门控先于一切的成本控制在 fork 被真正拉起之前有三个逐级递减的检查总开关config.enabled为false直接返回——这是一个默认关闭的 opt-in 功能配置默认值见下文。递归守卫通过task_local!的SKILL_REVIEW_ACTIVE标记防止嵌套触发——如果审查 fork 本身又触发了回合后 hook会递归烧掉大量 LLM token 直到超时守卫让它立即返回review.rs。迭代预算should_trigger统计历史中role tool的消息数每条代表一次完成的工具调用达到nudge_interval_iterations阈值才触发阈值为0时禁用基于迭代的触发review.rs。配套的单元测试覆盖了这三种门控should_trigger_zero_threshold_disables、should_trigger_fires_at_threshold、should_trigger_holds_below_threshold。7.2 受限工具集与静默运行审查 fork 通过ScopedToolRegistry::assemble组装刻意只用预先构建的 3 个工具skills_list、skill_view、skill_manage并关闭所有汇编扩展无 peripherals、无 MCP、无技能注入、无记忆条带且不应用真实 agent 的 allow/deny 策略——源码注释解释得很清楚真实策略可能丢弃某个技能工具而默认策略下汇编内置过滤是恒等函数能精确复现这 3 个工具。fork 的运行参数同样指向少花 token、别打扰用户temperature: Some(0.3)—— 低温度减少发散silent: true—— 注释写明 low so the fork doesnt rambleparallel_tools: false—— 对有写能力的 fork 强制顺序执行max_tool_iterations取自config.max_review_iterations默认 8封顶 fork 的 LLM 成本channel_name: skill_review、approval: None—— 无人类介入。7.3 一行摘要的生成审查结束后summarize_actions负责把动作压缩成用户能看到的一行摘要review.rs优先级为从collected_receipts中解析动作收据Patched skill x、Wrote references/y.md for skill x、Archived skill z收据为空时从 fork 自身的 tool 消息历史中解析注意父回合的工具消息会被过滤防止泄漏成假摘要见测试summarize_actions_ignores_parent_turn_tool_messages都没有时回退到最终文本第一行最多 80 字符用floor_char_boundary避免多字节字符切片 panic。若摘要为空例如审查 Agent 回复了Nothing to save.则什么都不打印。7.4 配置项与默认值审查 fork 的全部行为由[skills.skill_improvement]配置段控制schema.rs默认值如下配置键类型默认值含义enabledboolfalse启用后台技能审查 fork。必须显式开启opt-in因为该功能允许回合后技能变更cooldown_secsu643600同一技能两次审查之间的最小间隔秒是对任意技能补丁的持久限速nudge_interval_iterationsu3210当前运行累计达到该数量的工具调用迭代后触发一次审查0禁用基于迭代的触发max_review_iterationsu328审查 fork 自身允许的最大工具调用迭代数封顶 fork 的 LLM 成本在用户配置如zeroclaw.toml中的写法示例[skills.skill_improvement] enabled true cooldown_secs 3600 nudge_interval_iterations 10 max_review_iterations 8注意两个联动点触发入口在 loop_.rs 要求config.skills.skill_improvement.enabled为真而skill_manage的补丁路径还会再查一次config.enabledSkill improvement is disabled (enabled: false)。另外审查 fork 复用config.skills.allow_scripts作为变更后审计的脚本策略——如果脚本被禁用写入带脚本的技能会审计失败并回滚。八、安全设计审查 Agent 的写权限边界因为审查 fork 拥有对技能库的写权限ZeroClaw 在工具层做了多层防御skill_manage.rsslug 校验拒绝空 slug、含..、含/、含\、以.开头的 slug从源头阻断路径穿越测试skill_view_rejects_path_traversal覆盖了../etc/passwd、foo/bar、.hidden等输入符号链接防御技能目录本身是 symlink 时拒绝操作SKILL.md是 symlink 时拒绝 patch写入目标存在 symlink 时拒绝写入。原因是canonicalize会穿透 symlink导致starts_with检查被绕过规范路径边界技能目录必须位于规范化后的 skills 根目录之内写入目标父目录、归档目录同理变更后审计与回滚patch与write_file写入后立即用加载器同一套审计逻辑复查失败则回滚patch 恢复快照write_file 恢复旧字节或删除新文件归档命名archive把技能移到 skills 根下的.archive/重名时追加 UTC 时间戳如{slug}-20260919T012345Z避免覆盖。这些设计保证即使审查 Agent 的 LLM 输出出现幻觉或恶意内容也无法逃出技能目录、无法穿透 symlink、无法绕过脚本策略且任何破坏审计的写入都会被原子回滚。九、最佳实践与调优建议结合提示词与源码为你的 ZeroClaw 部署给出可落地的建议先开启审查再观察摘要[skills.skill_improvement] enabled true后每轮结束会打印一行动作摘要patched debugging · wrote file for debugging据此判断审查 Agent 是否在按你的预期工作。审查 fork 在用户回复之后才运行不会拖慢交互loop_.rs 特意在后台工作前先输出最终回复。用冷却值控制补丁频率如果你发现技能被过度改写调大cooldown_secs希望技能更快吸收反馈则调小。注意冷却针对单个技能是持久限速。调校触发频率nudge_interval_iterations控制多少轮工具调用后触发一次审查。长任务可以调低更频繁复盘短交互可以调高以减少 fork 开销设为0可完全禁用基于迭代的触发。封顶审查成本max_review_iterations默认 8是对 fork 的硬预算。如果审查 Agent 经常半途而废可适度上调如果心疼 token就保持默认或下调。把知识放进 references/ 而不是新建技能审查 Agent 会把会话中的具体怪癖写进references/topic.md——这是提示词反复强调的类级技能 支持文件模式请顺着这个方向引导它例如在技能正文里写遇到 provider 特例时记录到 references/provider-quirks.md。不要手动教它捕获环境错误提示词明确禁止把 command not found 之类环境失败沉淀为技能如果某技能常因环境失败正确做法是把修复步骤安装命令、配置项写进该技能的正文或 references/。结语review_prompt.md本质上是一份技能库策展人的岗位说明书它定义了审查 Agent 观察什么信号、怎么归类优先级、边界在哪不捕获清单、三个受限工具、以及如何安全落笔patch 纪律、审计、回滚。配合 review.rs 的执行引擎与 skill_manage.rs 的安全工具集ZeroClaw 把从对话中学习并改进自身工具库做成了一个默认关闭、可配置、有成本上限、有安全护栏的自治闭环。理解了这份提示词与它的实现你就掌握了让 ZeroClaw 技能库持续进化的正确操作方式。【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
