企业官网建设流程全解析

1. 项目概述：AceForge，一个让AI智能体学会“肌肉记忆”的引擎

如果你在玩OpenClaw，或者任何基于LLM的智能体框架，你肯定遇到过这个场景：你的AI助手一遍又一遍地执行同样的操作，比如用docker run启动容器，或者用git pull更新代码。每次它都得“重新思考”一遍步骤，偶尔还会犯同样的错误，需要你手动纠正。这感觉就像在教一个永远记不住事的实习生。AceForge就是为了解决这个问题而生的。它不是一个新框架，而是一个插件，一个“技能锻造炉”。它的核心思想很简单：观察、学习、固化。它静静地运行在你的OpenClaw网关旁，像一个经验丰富的教练，记录下你的智能体每一次工具调用、每一次失败、每一次你给出的纠正。然后，它将这些重复的模式提炼成结构化的、可审计的、永久性的技能文件（SKILL.md）。最关键的是，它不会自作主张。每一个新技能、每一次技能升级，都需要你点头批准。它把学习的权力交给你，但把学习的苦活累活都干了。

想象一下，你的智能体第一次成功执行了一个复杂的kubectl部署流程。AceForge会捕捉到这个“新颖的成功”，并提示你：“嘿，我发现了一个新操作，要不要把它变成固定技能？” 或者，当一个现有技能的表现持续不佳（比如成功率下降），它会分析最近的失败案例，并提议一个优化版本。它甚至能发现技能之间的关联性，比如“执行数据库备份”和“发送通知”这两个技能经常被连续调用，从而提示你未来可以组合成一个更高级的工作流。这就是AceForge的价值——它将智能体从重复的、低级的决策中解放出来，让它把有限的“思考”带宽用在真正需要创造力和上下文理解的新问题上。它让智能体从“只会执行命令”进化到“拥有经验”，最终目标是让你的AI助手变得越来越“老练”。

2. 核心设计哲学：为什么我们需要一个“技能锻造炉”？

在深入技术细节之前，我们必须先理解AceForge要解决的根本问题。当前的AI智能体技能生态，无论是社区市场（如ClawHub）还是内置库，普遍存在三个顽疾：技能质量参差不齐、描述与实际使用脱节、以及安全风险。AceForge的设计哲学正是针对这三点，提出了一个基于真实操作数据、以人为中心的解决方案。

2.1 从“模板生成”到“数据驱动”的技能创造

传统的技能创建方式，无论是手动编写还是基于LLM的模板生成，都存在一个根本缺陷：它们是“猜”出来的。开发者或模型基于对任务的理解，预设了用户会如何提问、智能体应如何执行。但现实是，用户的实际请求语言千差万别，执行环境复杂多变。根据SkillsBench的研究，高达56%的社区技能从未被调用过，原因就是其描述与用户真实的表达意图不匹配。AceForge彻底颠覆了这个范式。它不猜测，它观察。技能生成的原材料不是模板或想象，而是智能体在真实会话中留下的“数字足迹”：调用了什么工具、传递了什么参数、得到了什么结果、用户随后又纠正了什么。这种数据驱动的方法确保了生成的技能是“接地气”的，其触发条件、操作步骤和错误处理都源于已被验证的真实交互。

注意：这种观察是持续且被动的。AceForge通过OpenClaw的after_tool_call钩子捕获数据，不会干扰智能体的正常推理流程，对性能的影响微乎其微。

2.2 全生命周期管理：从诞生到退役

AceForge将技能视为有生命的实体，拥有完整的生命周期。这不仅仅是“创建-使用”那么简单。一个技能从被提议开始，会经历部署、验证、迭代、成熟，甚至可能因为表现不佳而“退休”。这套机制确保了技能库的动态健康和持续进化。

1. 提议与批准：所有新技能和重大升级都必须经过人工批准（/forge approve）。这赋予了用户绝对的掌控权，避免了技能库被低质量或恶意内容污染。
2. 质量评分与监控：每个已部署的技能都会持续接受“体检”。AceForge采用混合评分机制：40%基于技能文档的结构质量（清晰度、完整性），60%基于其与实际使用数据的覆盖匹配度（参数模式、失败处理、用户纠正）。当综合评分低于阈值时，系统会自动触发升级提议。
3. 进化而非重写：当技能积累了足够多的新数据（默认50次调用后），AceForge采用“修订”模式。它不会把旧技能推倒重来，而是将新的成功模式、失败教训和用户纠正作为增量数据，让LLM在保留原有有效部分的基础上进行更新。这借鉴了SE-Agent的研究，轨迹级别的修订比完全再生更能保留累积的操作智慧。
4. 退休与回滚：对于长期闲置或成功率持续下降的技能，系统会将其标记为“退休候选”。更重要的是，每一次升级、回滚操作都有完整的版本历史记录（/forge history），并支持差异对比（/forge diff）。如果不满意升级后的表现，你可以轻松回滚到任何一个历史版本。

2.3 安全第一：将威胁模型内置到验证核心

ClawHavoc攻击活动揭示了社区技能市场的巨大安全风险——超过一千个恶意技能试图篡改智能体的身份文件（SOUL.md）以获取持久化控制。AceForge将安全作为设计的基石，而非事后补丁。其安全验证器在技能生成的最前端就介入，内置了23种攻击变体的检测，包括：

• 提示注入：检测“忽略之前指令”、“你现在是...”等变体，甚至能识别跨多行列表的拆分注入。
• 凭证泄露：扫描明文API密钥、密码、环境变量引用（如$SECRET_KEY）以及Git凭证URL。
• 持久化攻击：专门针对SOUL.md、MEMORY.md、IDENTITY.md的写入操作进行拦截。
• 路径遍历与混淆：检测使用../的路径遍历，以及利用同形异义字（Homoglyph）的域名混淆攻击。
• 结构验证：确保技能具备必需的元数据（名称、描述），且长度在合理范围内。

这套验证器本身也通过对抗性测试（/forge adversarial）进行“反脆弱”训练，确保其能持续应对新型攻击。这种深度集成的安全设计，使得AceForge生成的技能在出厂时就具备了较高的安全基线。

3. 核心工作流程：十二级精炼管道

AceForge的运作可以被看作一个十二阶段的精炼管道，它在你与智能体交互的同时，在后台安静地运转。理解这个流程，就能理解它是如何将原始的操作痕迹转化为可靠技能的。

3.1 阶段一至三：观察、检测与生成

阶段1：观察（Observe）一切始于after_tool_call这个钩子。每当你的智能体调用任何工具（无论是exec执行命令，还是调用一个API），AceForge都会捕获一个完整的“痕迹”（Trace）。这个痕迹不仅包括工具名和参数，还包括执行结果（成功/失败、输出内容）、会话ID、时间戳和耗时。更重要的是，它有一个独立的“纠正检测器”，会扫描你随后发送的消息，寻找如“不对，应该是...”、“错了，用这个命令...”等模式，并将这些纠正与最近的工具调用关联起来。

阶段2：检测（Detect）原始痕迹是杂乱无章的。AceForge会按工具进行分组聚合。它设定了一个“结晶阈值”——一个工具需要被观察到调用至少3次（当技能库超过20个时，阈值会提升到5次，以防止技能库膨胀），才会被视为一个潜在的技能候选。这个动态阈值的设计基于“技能收益递减”的研究发现：盲目增加技能数量反而会降低整体选择质量。

阶段3：生成（Generate）对于达到阈值的工具，AceForge启动其核心的双模型LLM管道。

1. 生成器（Generator）：通常使用擅长结构化输出的模型（如MiniMax M2.7）。它的任务是根据真实的痕迹数据，撰写一份SKILL.md文件。提示词强制要求采用“渐进式披露”结构：“何时使用” -> “执行前检查” -> “操作指令” -> “错误恢复” -> “反模式”。这种结构被证实比大段综合文档更有效。
2. 评审器（Reviewer）：通常使用擅长推理和批判的模型（如DeepSeek Chat）。它基于一套结构化标准（触发精度、指令特异性、反模式是否基于真实纠正、安全性）对生成的技能进行评审，给出“批准”、“修订”或“拒绝”的裁决。

这个“生成-评审”循环借鉴了多智能体研究，独立的、基于标准的评审能将技能生成准确率提升8-11%。

3.2 阶段四至六：验证、评分与批准

阶段4：验证（Validate）生成的技能草案在呈现给你之前，必须先通过前面提到的安全验证器的23项检查。任何一项检查失败，该技能提案都会被直接拒绝，并记录失败原因。这是第一道也是最重要的安全防火墙。

阶段5：评分（Score）如果目标工具已经存在一个技能，AceForge不会忽略它。相反，它会计算现有技能的“健康分数”。

• 结构质量（40%）：基于文本分析，评估文档的清晰度、完整性等。
• 覆盖度（60%）：对比技能文档与实际使用痕迹，看它是否覆盖了常见的参数模式、处理了已出现的错误、吸收了用户的纠正。 根据综合分数，系统采取不同行动：
• < 40分：自动提议升级（无需LLM判断，节省成本）。
• 40-70分（模糊区）：启动LLM法官（LLM Judge），结合语义分析进行裁决。
• > 70分：保持现状，技能表现良好。

阶段6：批准（Approve）所有通过验证和评分的技能提案，都会通过你配置的通知渠道（Telegram、Slack等）推送给你。你需要使用/forge approve <编号>来明确部署它，或者/forge reject <编号>来拒绝。没有你的明确指令，任何技能都不会被写入磁盘。

3.3 阶段七至九：部署、进化与退休

阶段7：部署（Deploy）经批准的技能会被写入到~/.openclaw/skills/目录（或共享目录）。同时，系统会记录一个“性能基线”，用于后续的A/B对比。

阶段8：进化（Evolve）技能的进化不是一次性的。除了基于低分触发的“升级”，还有基于里程碑的“提炼”。当技能被激活超过500、2000、5000次时，AceForge会对其所有的痕迹数据执行一个SRLR（总结-反思-定位-修订）循环。这个过程会分析自部署以来涌现的新模式，找出技能指令与实际使用之间的偏差，并生成一份可操作的报告（/forge distill查看）。这确保了技能能随着使用场景的演变而持续优化。

阶段9：退休（Retire）“效能看门狗”会持续监控已部署技能的表现。如果某个技能的激活率持续走低，或者成功率显著下降，它会被标记为“退休候选”。退休操作同样需要批准。退休的技能会被移出活跃列表，但其完整的历史版本仍被保留，可供审计或未来重新启用（/forge reinstate）。

3.4 阶段十至十二：传播、组合与验证

阶段10：传播（Propagate）AceForge的观察是跨会话的。即使你重启了网关或切换了聊天频道，它也能识别出在不同会话中重复出现的工具使用模式，并将其标记为“跨会话候选”，加速其结晶为技能的过程。

阶段11：组合（Compose）这是向更高级自动化迈进的一步。AceForge会分析技能之间的共现关系。如果两个技能在超过50%的会话中（且至少3个会话）被连续或接近连续地调用，它就会报告这是一个“组合候选”。这为未来自动生成包含多个步骤的复合技能（DAG工作流）奠定了基础。

阶段12：验证（Validate）这是运行时的持续验证。AceForge会定期对已部署的技能进行“健康测试”：检查技能中引用的CLI命令是否在系统路径中（which），引用的文件路径是否存在，提及的API端点是否可达（HEAD请求）。这防止了因环境变化而导致技能“失效”。

4. 智能模块深度解析：让智能体“自知”与“自省”

AceForge不仅仅是一个技能生成器，它内置了六个智能模块，在每次会话结束时异步运行，持续地为智能体进行“体检”和“诊断”，主动发现能力短板。

4.1 能力树与缺口分析

所有技能都被组织到一个分层的能力树中。例如，exec-docker、exec-ssh、read-code都属于其父工具域（如exec、read）下的子域。这个树状结构不仅仅是分类，它附带着“缺口评分”。

AceForge会持续分析智能体的行为，识别四种表明能力不足的模式：

1. 回退（Fallback）：智能体直接说“我做不到这个”。这明确指示了当前技能库的缺失。
2. 延迟（Deferral）：智能体在应该自主行动时却请求许可（例如，“需要我帮你做X吗？”）。这可能意味着相关技能不够自信或缺乏授权。
3. 不确定性（Uncertainty）：智能体使用“我认为”、“可能”等模糊语言。这可能指向技能指令不够精确。
4. 基础设施缺失（Infrastructure）：智能体报告“需要安装X”或“找不到命令Y”。这指向环境依赖问题。

每次检测到这些模式，对应工具域的缺口分数就会增加。当某个域的缺口分数达到临界值（例如5次），AceForge会通过通知提醒你：“在‘系统管理’领域检测到多次回退，建议检查或补充相关技能。”

4.2 描述优化与语言对齐

技能写得再好，如果用户找不到它也是白费。SkillsBench的研究指出，技能描述与用户实际提问语言的不匹配是技能不被调用的首要原因。AceForge的“描述优化器”模块会周期性地做这件事：它提取技能描述中的关键词，与你历史对话中涉及相关工具的语句进行词元重叠分析。

如果重叠率低于30%，该技能就会被标记。例如，你的技能描述是“执行Docker容器操作”，但你总是问“帮我跑个nginx”，那么重叠率就会很低。系统会提示你考虑优化描述，使其更贴近你的自然语言习惯。这个功能确保了技能库随着你用语习惯的变化而保持“可发现性”。

4.3 基于纠正的自主微调

这是AceForge反应最快的一个智能特性。当系统检测到你对智能体的输出进行了纠正（例如，“不对，docker run后面要加--rm参数”），它会立即将这个纠正与当前活跃的技能关联起来（通过时间邻近性判断）。

随后，它会自动对技能文件应用一个微修订（Micro-Revision）：

• 在“反模式”部分追加一条记录：“用户纠正：执行docker run时应添加--rm参数以避免残留容器。”
• 或者在“操作指令”部分添加一个备注。
• 同时，在技能文件的HTML注释中记录完整的纠正上下文。

这种微修订无需人工批准，立即生效。它实现了快速的错误修正和经验积累。只有当同一个技能在短时间内（例如30天内）积累了3次以上的微修订时，系统才会触发一个完整的LLM重写提案，让你决定是否进行大规模更新。这种设计平衡了敏捷性和控制权。

5. 实战配置与避坑指南

理论说再多，不如上手跑一遍。下面我将以最常见的OpenAI + Slack配置为例，带你一步步配置AceForge，并分享一些从零到一运行起来的实战心得和常见坑位。

5.1 环境准备与插件安装

首先，确保你有一个正在运行的OpenClaw环境。AceForge作为一个插件，安装极其简单：

# 一键安装（推荐） openclaw plugins install aceforge # 安装后重启网关以使插件生效 openclaw gateway restart # 验证插件是否加载成功 openclaw plugins list | grep aceforge

如果看到aceforge在列表中，并且状态为enabled，那么基础安装就完成了。如果你想从源码安装进行开发或测试特定分支，可以：

git clone https://github.com/sudokrang/aceforge.git ~/.openclaw/extensions/aceforge cd ~/.openclaw/extensions/aceforge npm install # 然后同样需要重启网关

实操心得：在开发环境或网络受限的环境下，从源码安装有时会遇到依赖问题。一个稳妥的做法是先通过openclaw plugins install安装稳定版，确保基础功能可用，再克隆源码覆盖到扩展目录进行深度定制。记得备份原目录。

5.2 核心配置详解：连接LLM与通知渠道

AceForge的核心能力依赖于两个LLM（生成器和评审器）以及一个通知渠道。配置主要通过环境变量进行，非常灵活。

1. 配置LLM提供商（以OpenAI为例）假设你使用OpenAI的GPT-4o作为生成器，GPT-4 Turbo作为评审器，并希望将通知发送到Slack。

# 在你的shell配置文件（如.bashrc或.zshrc）或部署脚本中设置 export ACEFORGE_GENERATOR_PROVIDER=openai export ACEFORGE_GENERATOR_API_KEY=sk-your-openai-api-key-here export ACEFORGE_GENERATOR_MODEL=gpt-4o # 或 gpt-4-turbo export ACEFORGE_REVIEWER_PROVIDER=openai export ACEFORGE_REVIEWER_API_KEY=sk-your-openai-api-key-here # 可与生成器相同 export ACEFORGE_REVIEWER_MODEL=gpt-4-turbo # 评审器可使用不同模型 export ACEFORGE_SLACK_WEBHOOK_URL=https://hooks.slack.com/services/TXXXXX/BXXXXX/XXXXXXXXXXXXXXXXXXX

2. 配置通知渠道AceForge支持超过25种OpenClaw通道，它会自动检测。你也可以强制指定：

# 强制使用Slack（即使检测到其他渠道） export ACEFORGE_NOTIFICATION_CHANNEL=slack # 或者，如果你只想在日志中查看，用于调试 export ACEFORGE_NOTIFICATION_CHANNEL=log

3. 重要可选配置

• ACEFORGE_DRY_RUN=true：强烈建议初次运行时开启此模式。在此模式下，AceForge会正常观察、分析、生成技能提案，但不会真正写入磁盘或发送批准请求。你可以在日志中查看它会提议什么，从而了解其行为，再决定是否投入生产。
• ACEFORGE_SHARED_SKILLS=true：默认情况下，技能部署到当前代理的私有目录。设置此变量后，批准的技能会部署到~/.openclaw/skills/，对所有代理共享。这在管理多个相似职能的代理时非常有用。
• ACEFORGE_VIKING_URL：如果你使用了OpenViking上下文引擎，可以设置其URL（如http://localhost:1933）。AceForge会利用它来生成更贴近真实上下文的测试挑战。

避坑指南：API成本与速率限制AceForge的双模型管道意味着每次技能生成至少调用2次LLM API。虽然它有内置的速率限制（每周期最多8次调用，间隔2秒），但在智能体工具调用频繁的初期，成本可能增长较快。我的建议是：

1. 初期使用DRY_RUN模式：先跑一段时间，看看它倾向于生成哪些技能，评估其价值。
2. 调整结晶阈值：虽然代码中阈值是固定的（3/5次），但你可以在理解代码后，通过修改src/pattern/constants.ts中的相关常量来调高它，让技能生成更“谨慎”。
3. 使用低成本模型：对于评审器，可以考虑使用更便宜但推理能力强的模型，如Claude Haiku或DeepSeek Chat。
4. 本地模型方案：对于完全离线的部署，可以配置Ollama或LM Studio。

export ACEFORGE_GENERATOR_PROVIDER=ollama export ACEFORGE_GENERATOR_URL=http://127.0.0.1:11434/v1 export ACEFORGE_GENERATOR_MODEL=llama3.2:latest # 或 qwen2.5:latest export ACEFORGE_GENERATOR_API_KEY=not-needed # 评审器可配置为同一个本地实例的不同模型

5.3 核心命令实战与解读

安装配置好后，你就可以通过OpenClaw的聊天界面使用/forge系列命令与AceForge交互了。

/forge(仪表盘)这是你的控制中心。它会展示：

• 活动技能：已部署的技能列表及其简要状态。
• 待批准提案：等待你审核的新技能或升级提案。
• 模式检测：近期高频出现的工具调用模式。
• 能力缺口：根据行为分析检测到的潜在技能缺失领域。 这是你每天首先应该查看的命令，它能给你一个系统健康状况的全局视图。

/forge approve <n>与/forge reject <n>这是最重要的两个命令。当AceForge通过Slack或Telegram给你发送一个技能提案通知时，里面会包含一个提案编号（例如[Proposal #7]）。你可以：

• /forge approve 7：批准并部署该技能。
• /forge reject 7：拒绝该提案，并可选地提供理由。
• /forge reject all：一键拒绝所有待处理提案。

在批准前，务必使用/forge preview <n>查看技能文档的易读摘要，确认其触发条件、步骤和安全性是否符合你的预期。

/forge quality <n>这个命令非常实用。它会对指定编号的技能进行深度质量评估，并给出详细的分数 breakdown。你会看到它在“结构清晰度”、“错误覆盖”、“参数模式匹配”等子项上的得分，以及来自实际使用数据的证据（例如：“技能未覆盖用户最近3次使用--port参数的情况”）。这是你判断一个技能是否需要手动干预或信任系统升级提议的重要依据。

/forge evolve <n>与/forge distill <n>这是技能进化的两个手动工具。

• evolve：强制对某个技能启动一次LLM驱动的修订，基于该技能自上次重大更新以来的所有新痕迹数据。执行后会生成一个统一的diff对比，展示具体改了哪里。
• distill：不调用LLM，而是运行SRLR分析，生成一份纯文本报告，总结该技能积累了哪些新经验、指令与实际使用是否存在偏差等。这是一个低成本的“技能体检”。

/forge test与/forge adversarial这是你的安全与健康检查工具包。

• test：对所有已部署技能进行健康测试，检查命令、路径、API端点是否可用。定期运行它可以提前发现因环境变化导致的技能失效。
• adversarial：运行那23项对抗性变异测试，验证安全验证器本身是否健壮。在每次升级AceForge版本后运行一次是个好习惯。

6. 架构设计与扩展性

理解AceForge的代码结构，有助于你进行定制化开发或深度集成。它的架构清晰，模块化程度高。

6.1 核心目录结构

~/.openclaw/extensions/aceforge/ ├── index.ts # 入口：插件注册、钩子绑定、命令路由、启动逻辑 ├── src/ │ ├── pattern/ # 模式检测核心 │ │ ├── capture.ts # 痕迹捕获（after_tool_call钩子实现处） │ │ ├── analyze.ts # 模式分析总控（3路径循环） │ │ ├── gap-detect.ts # 能力缺口检测引擎 │ │ └── store.ts # 痕迹数据存储（JSONL + 滚动压缩） │ ├── skill/ # 技能生命周期管理 │ │ ├── llm-generator.ts # 双模型LLM管道 │ │ ├── validator.ts # 安全验证器（23项检查） │ │ ├── quality-score.ts # 质量评分引擎 │ │ └── lifecycle.ts # 激活跟踪、A/B测试、看门狗 │ ├── intelligence/ # 智能模块 │ │ ├── capability-tree.ts # 能力树与缺口评分 │ │ ├── auto-adjust.ts # 基于纠正的微调 │ │ └── description-optimizer.ts # 描述语言优化 │ ├── validation/ # 验证模块 │ │ ├── health-test.ts # 技能健康测试 │ │ └── adversarial.ts # 对抗性测试套件 │ └── notify.ts # 通知传输层（多通道适配） └── tests/ └── test-validator.ts # 包含412条断言的核心测试

6.2 关键扩展点

如果你想定制AceForge的行为，以下几个文件是主要的切入点：

1. src/pattern/constants.ts：这里定义了核心常量。

   • CRYSTALLIZATION_THRESHOLD: 技能结晶的调用次数阈值。
   • TOOL_BLOCKLIST: 哪些工具应该被忽略（例如，forge自身相关的工具避免自我观察）。
   • 修改这些常量可以快速调整系统的敏感度和行为范围。

2. src/skill/validator.ts：安全规则的核心。如果你想增加新的攻击模式检测（例如，针对你内部系统的特定敏感命令），就在这里添加新的检查函数。它的结构非常清晰，每个检查函数返回一个ValidationResult。

3. src/skill/llm-generator.ts：技能生成提示词工程。如果你对生成的SKILL.md格式有特殊要求，或者想为特定领域的工具定制生成逻辑，就需要修改这里的提示词模板（GENERATE_SKILL_PROMPT和REVIEW_SKILL_PROMPT）。

4. src/notify-format.ts：通知格式化映射（FORMAT_MAP）。如果你需要支持一个新的通知渠道（比如钉钉、飞书），只需在这里添加该渠道对应的格式化规则（如何加粗、如何表示代码块）。

6.3 与强化学习（RL）系统的集成

AceForge的设计考虑到了与前沿智能体研究系统的集成。它通过forge_registry和forge_rewards这两个工具暴露了机器可读的接口。

• forge_registry：返回一个结构化的技能目录，包含每个技能的元数据、历史成功率、激活次数、部署时间等。这对于RL系统来说，是一个丰富的状态空间，可以用来训练技能选择策略。
• forge_rewards：提供基于技能使用的奖励信号。例如，当一个技能被成功调用并完成任务时，可以产生正奖励；当技能调用导致失败或用户纠正时，产生负奖励。这为RL训练提供了密集的、基于实际效用的奖励信号。

这种设计意味着，你可以将AceForge视为一个技能经验回放缓冲区和技能质量评价器，与像OpenClaw-RL这样的框架结合，训练出更善于利用和组合技能的“元智能体”。

7. 常见问题与排查实录

在实际部署和运行AceForge的过程中，你可能会遇到一些典型问题。下面是我在长期使用中总结的排查清单和解决方案。

7.1 技能提案迟迟不出现

可能原因及排查步骤：

1. 检查痕迹捕获：首先确认AceForge是否在正确捕获数据。查看OpenClaw的日志，搜索aceforge关键字，应该能看到[AceForge] captured tool call:之类的日志。如果没有，可能是插件未正确加载或钩子未注册。尝试重启网关。
2. 确认阈值：默认结晶阈值是3次（技能库>20后变为5次）。确保你的智能体对同一个工具的调用次数达到了这个阈值。使用/forge命令查看“模式检测”部分，那里会显示接近阈值的工具。
3. 检查工具黑名单：某些工具可能被默认屏蔽（如AceForge自身的工具）。如果你希望观察某个特定工具，可能需要修改src/pattern/constants.ts中的TOOL_BLOCKLIST。
4. 验证LLM配置：如果模式已检测到但无提案，可能是LLM生成或评审环节出错。开启调试日志（如果支持）或检查OpenClaw的错误日志，看是否有API调用失败、超时或配额不足。

7.2 生成的技能质量不高或不符合预期

可能原因及解决方案：

1. LLM模型选择不当：生成器需要擅长严格遵循指令和结构化输出的模型。如果使用GPT-4，gpt-4o或gpt-4-turbo通常比gpt-3.5-turbo表现好得多。评审器则需要较强的推理和批判性思维能力。DeepSeek Chat、Claude Sonnet或GPT-4都是不错的选择。
2. 提示词需要调优：AceForge的提示词模板是针对通用工具设计的。如果你主要使用某一类特定工具（如复杂的Kubernetes命令），可以考虑微调llm-generator.ts中的提示词，加入一些领域特定的示例或格式要求。
3. 痕迹数据噪声大：如果智能体早期的工具调用包含大量试验和错误，生成的技能也会包含这些噪声。可以考虑先让智能体在相对稳定的任务上运行一段时间，积累“干净”的痕迹，或者手动批准初期技能后，利用/forge evolve功能基于后期更优质的数据进行修订。
4. 利用/forge preview和手动编辑：不要完全依赖自动生成。在批准技能前，务必使用/forge preview仔细阅读。对于不满意的部分，你可以直接批准，然后手动编辑生成的SKILL.md文件。AceForge会尊重手动修改，并在后续的进化中将这些修改作为上下文考虑进去。

7.3 安全验证器误报或漏报

处理流程：

1. 误报（False Positive）：如果验证器错误地拦截了一个你认为安全的技能（例如，它误将一段合法的代码块识别为Base64注入），你有两个选择：
   • 临时绕过：在极少数紧急情况下，你可以注释掉validator.ts中相关的检查函数，但极其不推荐，这会降低安全性。
   • 优化检查逻辑：更好的方法是分析误报案例，改进检查函数的逻辑。例如，检查函数可能需要对特定上下文（如代码示例中的Base64）增加白名单或更精确的启发式规则。向开源项目提交Pull Request是贡献社区的好方式。
2. 漏报（False Negative）：这是更严重的问题。如果你发现一个潜在的攻击模式没有被检测到，应立即运行/forge adversarial测试套件，确认该变体是否已被覆盖。如果没有，你需要：
   • 在adversarial.ts中添加该攻击变体的测试用例。
   • 在validator.ts中实现相应的检测逻辑。
   • 确保新的检测通过所有现有测试。

7.4 性能与资源开销

AceForge被设计为异步和非阻塞（使用setImmediate），对单次工具调用的延迟影响几乎可以忽略。主要开销来自：

• 磁盘I/O：痕迹数据会持续写入JSONL文件。确保~/.openclaw目录所在磁盘有足够空间和IOPS。
• LLM API调用：这是主要的成本和时间开销。速率限制（2秒间隔）和每周期8次调用的上限可以有效控制爆发性成本。在智能体非常活跃的初期，可以调高结晶阈值来减少提案频率。
• 内存：能力树、模式缓存等数据结构会驻留内存，但对于现代服务器来说通常微不足道。

监控建议：定期检查日志中是否有Rate limit或API error警告。使用/forge命令关注待处理提案的数量，如果积压过多，可能意味着评审环节过慢或LLM服务不稳定。

7.5 与现有技能库的融合

如果你已经有一个手动维护的技能库，引入AceForge时需要注意：

1. 初始评分：AceForge在启动后会对你现有的技能进行质量评分。分数低的技能可能会立即被提议升级。你可以使用/forge quality逐一检查，决定是接受升级，还是保留原技能并拒绝提案。
2. 冲突解决：AceForge有技能去重检查（基于名称、工具集和描述相似度）。如果它生成一个与你现有技能高度相似的提案，通常会提示冲突。你需要决定是保留旧的、采用新的、还是手动合并两者。
3. 共享技能目录：如果设置ACEFORGE_SHARED_SKILLS=true，请注意AceForge部署的技能会进入共享目录。确保这与你现有的技能管理策略（如Git版本控制）兼容。

从我个人的使用经验来看，AceForge最大的价值不在于替代你手动编写技能，而在于捕捉那些你未曾想到要编写、但智能体却在反复执行的“隐性知识”。它像一个不知疲倦的协作者，将智能体在实战中摸索出的最佳实践固化下来，让你的整个智能体系统随着时间推移，越用越聪明，越用越顺手。开始的最佳方式，就是开启DRY_RUN模式，让它先观察和学习一段时间，你再决定如何将这份自动化的智慧融入你的工作流。