快来看,n8n更新了!使用cognee和n8n构建自我进化的智能体技能

qimuai 发布于 阅读:3 一手编译

快来看,n8n更新了!使用cognee和n8n构建自我进化的智能体技能

内容来源:https://blog.n8n.io/skill-loop/

内容总结:

技能文件维护自动化:n8n与cognee联合打造智能自修复工作流

——让AI智能体的“作业指导书”自动更新迭代

在AI智能体开发中,Claude Code等工具的技能文件(skill files)编写简单却极易被忽视。开发者最初会为代码审查、测试、迁移等任务创建技能文件,一切运行顺畅。然而随着项目推进,技能文件往往陷入“无人维护”的困境——几个月前不可或缺的指令,如今可能已遗漏关键检查项。在项目截止压力下,手动审计日益庞大的Markdown指令文件几乎是不可能完成的任务。

针对这一痛点,cognee创始人兼CEO Vasilije Marković近日发布了一项创新教程,打造了一套技能文件自动维护工作流。该方案将n8n自动化平台与cognee AI记忆层相结合,构建起“运行-评分-提议-审批-应用”的完整闭环。

工作流程详解

整个自动化流程包含八大核心步骤:

1. 配置运行参数:设置技能名称、数据集名称、任务文本、评分阈值(默认0.9)等关键变量。

2. 技能导入:将SKILL.md文件作为数据集范围的技能存储至cognee。

3. 技能审查:AI智能体根据加载的技能执行审查任务,并按既定标准自行评分。在示例中,针对授权边界审查任务,初始评分仅为0.42。

4. 决策分支:n8n的阈值检查节点判断分数是否低于阈值。低于则进入改进路径,达标则直接退出。

5. 改进提议:cognee记录弱评分运行结果,生成重写提案但暂不执行。

6. 差异审查:系统呈现改进前后的完整差异对比,包括AI的修改理由和置信度。开发者可在应用前仔细审查每一处改动。

7. 审批应用:通过审批门禁后,改进提案正式应用于cognee中的技能存储。

8. 结果确认:读取更新后的技能文件,输出最终的差异对比。

两种部署方案

可视化编辑器方案(推荐入门):在n8n编辑器中直接导入模板,所有cognee操作通过验证节点完成。无需编写任何Python代码,支持n8n Cloud与自托管两种方式。

Python SDK方案(面向开发者):通过Execute Command节点调用cognee Python SDK,实现完全本地化的自由定制,所有操作在开源cognee框架下完成。

安全保障机制

该工作流设计有严格的安全保障:任何改进提案都会先以“待审批”状态搁置,绝不会静默修改技能文件。完整的before/after差异对比让每处改动清晰可见,开发者可决定是否将其发布到Slack或创建拉取请求。

生产环境适配建议

教程还提供了多种生产级适配方案:用Webhook触发器替代手动触发、通过Slack节点推送差异通知、集成GitHub分支和拉取请求进行代码审查、建立审批审计数据库、为不同技能类型设置差异化评分阈值等。

这套工作流的核心理念是:当一次代码审查遗漏了授权检查时,这个问题不会再次发生——它会转化为一项具体的、可审批的技能文件修改,在影响下一次运行之前就清晰可见。下载工作流模板,从团队信任的审查习惯开始,让AI智能体的技能与项目同步进化。

中文翻译:

此篇《认证节点聚焦》由 cognee 创始人兼首席执行官 Vasilije Marković 撰写,是一篇特邀投稿。
Claude Code 以及其他智能体技能文件容易编写,也更易被忽视。你为代码审查、测试、迁移、API 约定编写技能,起初一切正常——智能体遵循指令,审查结果反馈有用,于是你不断扩充技能库。
但项目持续推进,技能文件却停滞不前。几个月前还必不可少的技能,如今已缺少关键的检查项——它从未被更新过,因为手动审计日益庞大的 Markdown 指令文件集,恰恰是那种在截止日期压力下无人愿意接手的工作。
本教程为这些技能构建了一个维护循环。当一次审查运行的得分低于阈值时,工作流会记录反馈,请求 cognee 提出重写方案,将该方案通过 n8n 中的审批关口,并且仅在批准后,才将改动写回技能文件,同时附带一份前后差异对比,可供你检查、发布到 Slack 或附加到拉取请求中。
运行方式有以下几种:
选择适合你工作习惯的一种。

cognee 和 n8n 各自的功能

cognee 是 AI 智能体的记忆层,能将来自多种文档格式的数据转化为结构化知识图谱。它不是仅基于概念相似性检索信息,而是提取实体、映射它们的关系、并捕获来源,以便智能体能够理解信息碎片之间的联系。
在此工作流中,Cognee 认证节点处理六项任务,每项都是一个节点操作:

你将构建的内容

可视化工作流会将一次得分低于阈值的智能体运行,转化为对 Markdown 技能文件的可审查、可审批的更新。
它执行以下步骤:

  1. 导入技能 将本地的 code-review 技能加载到 cognee 中
  2. 审查技能 加载该技能后运行审查任务
  3. 审查返回一个分数
  4. 是否改进? 将分数与阈值进行比较
  5. 提议改进 记录反馈并创建一个提议(不应用)
  6. 获取提议 获取修改前后内容以供审查
  7. Code 节点构建差异对比;是否批准? 关口做出决定
  8. 应用改进 写入已批准的更改
  9. 获取技能 + 显示技能差异 确认并输出结果
    示例是一个授权边界审查:被审查的代码按 ID 检索数据集,智能体应标记出它从未检查该数据集是否属于已认证用户、从未处理记录缺失的情况、也没有针对所有者/非所有者/缺失情况的测试。

开始之前

步骤 1:配置运行

工作流以一个手动触发器(或生产环境中的Webhook 触发器)和一个演示控制设置节点开始。这就是你设置测试时最常调整的值的地方:

{  
  "skill_name": "code-review",  
  "dataset_name": "n8n-skill-self-improvement",  
  "skill_markdown": "<SKILL.md 的内容>",  
  "task_text": "<审查任务>",  
  "score_instructions": "按维度(覆盖率、正确性等)从 0.0 到 1.0 给你的审查打分。",  
  "score_threshold": 0.9,  
  "approved": "1"  
}  

步骤 2:导入技能(认证节点)

导入技能操作将内联的 SKILL.md 提交给 cognee,并将其存储为数据集范围内的技能:

{  
  "status": "completed",  
  "dataset_name": "n8n-skill-self-improvement",  
  "dataset_id": "3d8f047d-dc45-5fee-9b59-b82e4206711c",  
  "items": [{ "name": "code-review", "kind": "skill", "declared_tools": ["memory_search"] }]  
}  

返回的 dataset_id 会被后续的 Get 步骤重复使用。

步骤 3:针对实际任务审查技能(认证节点)

审查技能操作在加载技能后运行一次智能体式补全。查询内容是任务加上 score_instructions 评分标准,因此智能体会审查更改并对其自身的审查进行评分。节点将其解析为扁平化结果:

{  
  "score": 0.42,  
  "missing_instruction": "没有明确的所有者/非所有者/缺少数据集的测试要求",  
  "result_summary": "标记了所有权缺失问题,但遗漏了测试矩阵",  
  "dimensions": [{ "name": "coverage", "score": 0.4 }, { "name": "correctness", "score": 0.45 }]  
}  

score 是下一步分支判断的依据。
示例任务是授权边界审查。加载技能后,智能体会返回结构化的审查结果,标记出缺失的所有权检查、缺失的 404 处理以及缺失的所有者/非所有者/缺少数据集的测试。

步骤 4:让 n8n 决定是否改进

是否改进? IF 节点将审查的 score(来自审查技能)与阈值进行比较:
score < score_threshold
如果审查得分低于阈值,工作流走改进路径。如果得分达到或超过阈值,则路由到无需改进并正常退出。阈值存在于 n8n 中,可见且可调,并且可以轻松替换为更严格的评估器(如 LLM 作为评判节点、CI 评分),而无需触碰其两侧的 cognee 步骤。
职责划分:智能体根据 score_instructions 评分标准对其自身审查进行评分,认证节点将这些逐维度的评分解析为一个 score,而 n8n 拥有阈值决策权。

步骤 5:提议改进(认证节点)

提议改进操作记录低分运行,并请求 cognee 进行重写。关键是,它创建了一个提议,但并未应用

{  
  "items": [  
    { "kind": "skill_run", "run_id": "82a14c99…", "success_score": 0.42 },  
    { "kind": "skill_improvement_proposal", "proposal_id": "48d6f3f3-430f-460c-bf5b-2987086a43dd", "status": "proposed" }  
  ]  
}  

提议的更改保持在待处理状态,直到 n8n 决定如何处理。一次低分运行永远不能静默地重写你的指令。

步骤 6:在批准前审查差异对比(认证节点)

这一步使循环变得安全。获取提议操作返回提议完整的修改前/修改后内容,以及模型的推理过程和置信度:

{  
  "proposal_id": "48d6f3f3-430f-460c-bf5b-2987086a43dd",  
  "skill_id": "a49f5ceb-fe79-5094-bee6-ee1de4d45671",  
  "confidence": 0.93,  
  "rationale": "明确并收紧了现有规则,使智能体输出严格结构化、最小化的问题报告,专注于授权、测试和审计日志……",  
  "old_procedure": "# code-review …",  
  "proposed_procedure": "# code-review …"  
}  

一个 Code 节点将 old_procedureproposed_procedure 转换为统一的差异对比(skill_delta_markdown),使其准备好放入 Slack 消息或拉取请求中。以下是本次运行的实际更改(节选):

1. 按文件、按代码块逐个读取差异。  
- 不要运行或应用更改。  
+ 不要运行、应用或修改代码。不要改变状态。  
3. 授权和数据访问检查:  
- 应用以下两种模式之一,并验证差异显示了它:  
- - 调用方验证(如果 get_dataset 不接受请求用户,则首选):  
+ 调用方验证是必需的,除非存在 get_dataset-enforces-acl 模式:  
    dataset = get_dataset(requested_dataset)  
    if dataset is None: return 404  
    if dataset.owner_id != user.id and not user_has_access(user, dataset): return 403  
+ 如果检查缺失或被削弱,将问题标记为严重并提供确切的伪差异。  
+ 12. 失败证据处理:将 "return get_dataset(requested_dataset)" 示例转化为  
+    一个严重问题,附上调用方补丁、复现步骤和短期缓解措施。  
+ 13. 执行清单:在完成前,确认每个问题都有必需的字段。  

所有权检查行已经存在于技能中——改变的是表述:一个“首选”模式变成了强制要求,当检查缺失时现在会触发“严重”等级,并且增加了两个执行部分。

步骤 7:应用已批准的更改(认证节点)

是否批准? IF 节点检查审批标志。在演示中,这是 approved 控制变量;在生产环境中,你可以将其替换为 Slack 消息加上等待 Webhook 的审批(参见画布上的便签)。
批准后,应用改进更新 cognee 中存储的技能(状态翻转为 applied):

{  
  "items": [{ "kind": "skill_improvement_proposal", "proposal_id": "48d6f3f3…", "status": "applied" }]  
}  

步骤 8:确认结果

获取技能读取技能,以便你确认新的流程已生效;显示技能差异输出最终的 skill_delta / skill_delta_markdown。一次遗漏的授权检查 → 一次具体的、已批准的、针对相关指令的编辑。

各部分职责

可视化构建的全部意义在于:你无需编写一行代码即可运行整个循环。

调整可视化构建的方法

演示保持审批流程简单,以便端到端检查循环。对于生产环境,请将演示控制替换为:

使用 Python SDK 自托管构建

如果你是一名熟悉终端且希望整个循环完全在本地、免费运行开源版 cognee 的开发者,那么 advanced/ 模板适合你。它通过 Python SDK(cognee.remembercognee.search 配合 AGENTIC_COMPLETION、以及 improve_skill)完成同样的六项 cognee 任务,由一个小的运行器脚本和 n8n 的 Execute Command 节点驱动:

python run_self_improve_skill.py init-state  
python run_self_improve_skill.py remember-skills  
python run_self_improve_skill.py run-agent  
python run_self_improve_skill.py record-feedback  
python run_self_improve_skill.py review-packet  
python run_self_improve_skill.py apply-proposal  

n8n 2.x 出于安全原因默认禁用了 executeCommand,因此此构建需要显式启用它。这是最易修改的版本,且永远不会离开你的机器——代价是需要终端设置。请参阅 advanced/README.md 了解环境变量和运行说明。

一个与项目同步演进的自维护循环

智能体技能只有在反映项目当前工作方式时才是最宝贵的——而不是在有人最初编写指令文件时的工作方式。这个工作流为此问题提供了一个结构:运行、评分、提议、审查差异、批准、应用。一次在审查中遗漏的授权检查不必再次遗漏——它将变成对技能的一次具体、可批准的编辑,在塑造下一次运行之前就可见。
下载工作流模板,安装 Cognee 认证节点,从可视化构建和一个技能开始——一个你的团队已经信任的审查习惯。让工作流向你精确展示技能在收到反馈后如何变化,然后再转向高级模板。

英文来源:

This Verified Node Spotlight is a guest post written by Vasilije Marković, CEO and Founder, cognee.
Claude Code and other agent skill files are easy to write and easier to neglect. You create skills for code review, tests, migrations, API conventions, and at first everything works. The agent follows the instructions, the reviews come back useful, so you keep extending the library.
Then the project moves on and the skill files don’t. A skill that was indispensable a few months ago is now missing a critical check — it never got updated, because manually auditing a growing pile of Markdown instruction files is exactly the kind of task nobody picks up under deadline pressure.
This tutorial builds a maintenance loop for those skills. When a review run scores below a threshold, the workflow records the feedback, asks cognee to propose a rewrite, routes that proposal through an approval gate in n8n, and, only after approval, writes the change back to the skill, with a before/after diff you can inspect, post to Slack, or attach to a pull request.
There are a few ways to run this:
Pick the one that fits how you work.

n8n

文章目录


    扫描二维码,在手机上阅读