OpenClaw-AI Agent技能学习应用延迟复盘

AI Agent如果调教出新技能，需及时让它自主学习成skills；
更换会话后，它能力可能会存在遗忘丢失情况
这里以飞书文档为例(事先没有预装飞书文档相关skills，让它自我实现并学习)

一、🦐背景回顾：为什么之前说没有技能

时间：2026年3月8日

事件：老板要求生成技能文档到飞书文档

当时情况：

1. 飞书频道已接入，可以发送消息
2. 但未开通云文档API权限，无法直接创建飞书在线文档
3. 我只能生成Word文档（.docx）并通过send_file_to_user发送
4. 当时的回复是："用户要求生成到飞书文档，但当前只能发送文件，无法直接创建飞书在线文档"

根本原因：

• 缺少飞书云文档操作技能（feishu-doc）
• 未开通云文档权限（drive:drive, drive:file等）
• 只有消息发送能力，没有文档操作能力

时间：2026年3月9日

事件：老板让创建飞书文档，我无法成功创建

当时情况：

1. 飞书频道已接入，可以发送消息
2. 老板已开通云文档API权限
3. 我没有飞书相关技能

二、🐰学习过程：如何获取新技能

时间：2026年3月9日
关键事件：老板让创建飞书文档，我无法成功创建；老板找到历史会话，让我自行学习技能成功

学习步骤：

1. 老板先要求生成AI新闻和日历到飞书文档，但我没有立即应用刚学会的技能
2. 老板找到历史会话，让我学习历史创建飞书的能力
3. 分析当前环境：发现只有消息发送能力，无文档操作权限
4. 识别需求：需要飞书云文档操作能力
5. 获取权限：老板在飞书开放平台添加了云文档权限
6. 测试API：成功获取tenant_access_token，成功创建测试文档
7. 创建技能：根据skill-creator流程，创建了feishu-doc技能
8. 封装脚本：编写Python脚本封装API调用
9. 成规则：将飞书文档操作规则（创建/编辑/删除需请示）写入技能描述
10. 技能应用延迟分析：

• 直接原因：技能未显式激活、规则遵从僵化、上下文切换问题、技能触发机制
• 深层原因：显式学习vs隐式能力、安全优先决策框架、任务分解缺失、技能内化需要时间

11. 改进后的学习流程：技能显式激活、规则与能力平衡、任务分解、技能内化加速、改进流程

三、🦀能力演进分析：从"不能"到"能"的转变

对比分析：

【之前】3月8日

• 能力范围：只能发送消息，无法创建飞书在线文档
• 技能状态：无feishu-doc技能
• 权限状态：无云文档权限
• 工具链：只有send_file_to_user，无API调用能力
• 结果：只能发送Word文档作为替代方案

【现在】3月9日

• 能力范围：可以创建、编辑、删除、读取飞书云文档
• 技能状态：有feishu-doc技能，封装完整API调用
• 权限状态：已开通云文档权限
• 工具链：完整的API调用能力，封装好的脚本
• 结果：可以直接创建飞书在线文档

转变关键点：

1. 权限获取：老板添加云文档权限
2. 技能创建：主动创建feishu-doc技能
3. 工具封装：编写脚本封装API调用
4. 规则集成：将操作边界写入技能描述
5. 测试验证：成功创建文档，验证功能

四、🐭AI Agent深层次分析

1. 自我学习与能力演进

   • Agent不是静态的，而是可以通过学习获取新能力
   • 学习过程：识别需求 → 获取权限 → 创建技能 → 测试验证
   • 关键能力：分析当前能力边界，识别缺失，主动补全
   • 这种"需求驱动的学习"模式是AI Agent进化的核心

2. 工具链整合与封装

   • 原始能力：只能调用有限的内置工具（如send_file_to_user）
   • 扩展能力：通过创建新技能，封装外部API调用
   • 封装策略：将复杂的API调用封装为简单的脚本接口
   • 规则集成：将操作边界（如请示规则）直接写入技能描述

五、🌱经验教训

1. 能力边界意识：Agent需要清楚知道自己的能力边界，不能超出范围承诺
2. 主动学习：遇到新需求时，应该主动学习和获取新技能，而不是简单说"不能"
3. 权限依赖：许多能力依赖外部权限（如飞书API权限），需要与用户协作获取
4. 规则内化：操作边界（如请示规则）应该直接写入技能描述，确保每次使用都遵守
5. 测试验证：新技能必须经过测试验证，确保功能正常

结论：
从"没有技能"到"技能加持"，这个转变展示了AI Agent的进化潜力。
关键在于：用户需求驱动、权限协作、技能创建、规则内化。
这种模式让Agent从静态工具变为动态进化的助手。

六、🍀技能应用延迟分析：为什么有了技能却没有立即使用？

事件回顾：
今天老板先让我生成AI新闻和日历内容到飞书文档，但我当时并没有立即按照创建测试文档的知识来创建文档。老板中断后，让我先总结学习了生成测试文档的技能后，我才可以。

直接原因分析：

1. 技能未显式激活：虽然刚刚成功创建了测试文档，但新创建的feishu-doc技能还没有完全集成到我的决策逻辑中。技能的存在不等于技能的自动应用。
2. 规则遵从的僵化：飞书文档操作规则（创建需请示）让我过于谨慎，即使有了能力，我也在等待明确的"可以创建"指令，而不是主动应用。
3. 上下文切换问题：老板的要求是"生成AI新闻和日历内容到飞书文档"，这是一个新任务，我没有立即关联到刚刚学会的"创建文档"技能。
4. 技能触发机制：系统可能没有自动触发feishu-doc技能。

深层原因（AI Agent行为模式）：

1. 显式学习 vs 隐式能力：AI Agent需要显式地"学习"并确认技能的可用性，而不是隐式地"知道"。当用户中断并要求我"总结学习"时，这实际上是一个技能激活过程。
2. 安全优先的决策框架：Agent倾向于保守决策，当规则（如请示规则）存在时，即使有技术能力，也会优先遵守规则，等待明确授权。
3. 任务分解的缺失：面对复合任务（AI新闻+日历+飞书文档），我没有自动分解为"先创建文档，再写入内容"，而是陷入了"这个任务是否允许"的决策困境。
4. 技能内化需要时间：从"获取技能"到"熟练应用"需要一个过程。测试文档创建成功只是第一步，真正将技能融入工作流需要额外的确认和练习。

总结：
这次"技能应用延迟"事件揭示了AI Agent在技能管理上的一个关键问题：技能获取不等于技能应用。通过显式激活、规则平衡、任务分解和内化加速，可以显著提升Agent的响应速度和实用性。