快来看,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 或附加到拉取请求中。
运行方式有以下几种:
选择适合你工作习惯的一种。
- 在 n8n 编辑器中可视化构建(从这里开始): 每一个 cognee 步骤——导入、审查、提议、审查差异、应用——都是 cognee 认证节点上的一个操作,而 n8n 负责评分、审批关口和差异对比。无需 Python、无需 Shell、无需编写脚本:导入模板,连接到 cognee 服务器,即可运行。你使用哪个服务器取决于你如何运行 n8n:
- 在 n8n Cloud 上,使用 Cognee Cloud。这是最快的配置,无需托管任何内容。
- 如果你自行托管 n8n,请使用你自己的 cognee 服务器,将所有内容保留在内部。
- 使用 cognee SDK 构建: 此构建通过一个小型运行器直接调用 cognee Python SDK(
remember、search、improve_skill),并通过 n8n 的 Execute Command 节点连接。你可以掌控和定制循环的每一步,全部基于开源版的 cognee。
两种方式产生相同的结果——一次低分的运行转化为对技能文件的可审批编辑——并且都使用相同的示例:一个代码审查技能和一个授权边界审查任务。
本文将主要讲解如何在编辑器中从模板进行可视化构建。如果你更倾向于通过代码驱动循环,请跳转至文末“使用 Python SDK 自托管构建”部分讨论的 SDK 构建方式。
cognee 和 n8n 各自的功能
cognee 是 AI 智能体的记忆层,能将来自多种文档格式的数据转化为结构化知识图谱。它不是仅基于概念相似性检索信息,而是提取实体、映射它们的关系、并捕获来源,以便智能体能够理解信息碎片之间的联系。
在此工作流中,Cognee 认证节点处理六项任务,每项都是一个节点操作:
- 导入技能 —— 将
SKILL.md存储为数据集范围内的技能 - 审查技能 —— 加载该技能后运行审查任务(智能体式补全)
- 提议改进 —— 记录低分运行并生成提议的重写方案
- 获取提议 —— 获取修改前后内容、原理和置信度
- 应用改进 —— 应用已批准的提议
- 获取技能 —— 读取更新后的技能
n8n 则负责围绕这些任务的所有编排:协调、评分、阈值检查、审批关口、差异对比、通知和分支。
该工作流不会静默地重写你的技能文件。提议总是先生成,在应用任何内容之前,提议的文本是可见的,并且由你在 n8n 工作流中决定下一步操作。
你将构建的内容
可视化工作流会将一次得分低于阈值的智能体运行,转化为对 Markdown 技能文件的可审查、可审批的更新。
它执行以下步骤:
- 导入技能 将本地的
code-review技能加载到 cognee 中 - 审查技能 加载该技能后运行审查任务
- 审查返回一个分数
- 是否改进? 将分数与阈值进行比较
- 提议改进 记录反馈并创建一个提议(不应用)
- 获取提议 获取修改前后内容以供审查
- Code 节点构建差异对比;是否批准? 关口做出决定
- 应用改进 写入已批准的更改
- 获取技能 + 显示技能差异 确认并输出结果
示例是一个授权边界审查:被审查的代码按 ID 检索数据集,智能体应标记出它从未检查该数据集是否属于已认证用户、从未处理记录缺失的情况、也没有针对所有者/非所有者/缺失情况的测试。
开始之前
- 安装有 Cognee 节点(v0.5.1 或更高版本)的 n8n 实例。从本地 n8n 实例出发,在编辑器的节点面板中直接搜索“cognee”,然后点击安装。详情请参阅认证安装文档。
- 一个配置了 LLM 和嵌入提供者的 cognee 服务器,因为审查和提议步骤需要调用模型。最简单的选择是 Cognee Cloud,它完全托管且无服务器化,因此无需安装任何内容,模型和嵌入提供者也已为你处理妥当。你也可以连接到自托管的 cognee 实例,但需要自行配置这些提供者。无代码的技能操作使用 cognee 的
/api/v1/skill端点,这些端点可供自托管实例使用,并正在向 Cognee Cloud 推出。
准备好为你的智能体添加持久化记忆了吗?尝试通过云部署(无服务器或私有基础设施)使用 cognee,或与 cognee 预约电话讨论本地部署方案。 - 在 n8n 中的 Cognee API 凭证(Credentials → New → Cognee API):输入你的服务器的基础 URL(不带末尾的
/api)和 API 密钥。对于 Cognee Cloud,直接从 platform.cognee.ai 上的租户仪表板复制这两个值。
工作流中的所有操作均在 n8n UI 中完成(无需终端命令)。
步骤 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"
}
skill_name/skill_markdown—— 要运行和改进的技能(内联)task_text—— 加载技能后要执行的审查任务score_instructions—— 智能体用于对其自身审查进行逐维度评分的评分标准;节点将这些评分转换为一个单一的scorescore_threshold—— 跳过改进路径所需的最低分数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_procedure 与 proposed_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。一次遗漏的授权检查 → 一次具体的、已批准的、针对相关指令的编辑。
各部分职责
可视化构建的全部意义在于:你无需编写一行代码即可运行整个循环。
调整可视化构建的方法
演示保持审批流程简单,以便端到端检查循环。对于生产环境,请将演示控制替换为:
- 由 Claude Code、你的 CI 流水线或其他智能体运行器触发的Webhook 触发器
- 一个Slack 节点,用于发布
skill_delta_markdown数据包——差异对比、推理过程、置信度——以供审查 - 一个等待节点或 Webhook 回调,用于暂停直到有人批准
- 一个GitHub 分支和拉取请求,替代直接应用,使技能更改通过正常的代码审查流程
- 一个数据存储表,用于记录已接受和已拒绝的提议,形成审计追踪
- 针对不同技能类型的不同阈值——安全相关审查更严格,格式类审查可放宽
职责分工保持不变:n8n 负责编排、评分、审批、通知和审计追踪;认证节点负责记忆、检索、提议生成、提议审查和应用。
使用 Python SDK 自托管构建
如果你是一名熟悉终端且希望整个循环完全在本地、免费运行开源版 cognee 的开发者,那么 advanced/ 模板适合你。它通过 Python SDK(cognee.remember、cognee.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.
- Visual building in the n8n editor (start here): Every cognee step — ingest, review, propose, review the diff, apply — is an operation on the cognee verified node, and n8n handles the scoring, the approval gate, and the diff. No Python, no shell, no scripts to write: import the template, connect it to a cognee server, and run. Which server you use depends on how you run n8n:
- On n8n Cloud, use Cognee Cloud. It's the fastest setup, with nothing to host.
- If you self-host n8n, use your own cognee server to keep everything in-house.
- Building with the cognee SDK: This build calls the cognee Python SDK directly (
remember
,search
,improve_skill
) from a small runner, wired into n8n through Execute Command nodes. You own and customize every step of the loop, all on open-source cognee.
Both produce the same outcome — a weak run becomes an approvable edit to a skill file — and both use the same example: a code-review
skill and an authorization-boundary review task.
Most of this post walks through visual building in the editor from a template. If you'd rather drive the loop from code, jump to the SDK build discussed at the end under the section “Self-hosted with Python SDK build”.
What cognee and n8n each do
cognee is a memory layer for AI agents that turns data from multiple document formats into structured knowledge graphs. Instead of retrieving information based solely on conceptual similarity, it extracts entities, maps their relationships, and captures provenance so agents can understand how pieces of information are connected.
In this workflow the Cognee verified node handles six jobs, each a node operation: - Ingest Skill — store a
SKILL.md
as a dataset-scoped skill - Review Skill — run the review task with that skill loaded (agentic completion) - Propose Improvement — record the weak run and generate a proposed rewrite
- Get Proposal — fetch the before/after procedure, rationale, and confidence
- Apply Improvement — apply the approved proposal
- Get Skill — read the updated skill back
n8n handles everything around those: orchestration, scoring, the threshold check, the approval gate, the diff, notifications, and branching.
The workflow never quietly rewrites your skill files. A proposal is always created first, and the proposed text is visible before anything is applied, and you decide what happens next in your n8n workflow.
What you will build
The visual workflow takes a sub-threshold-scoring agent run and turns it into a reviewable, approvable update to a Markdown skill file.
It runs these steps: - Ingest Skill loads the local
code-review
skill into cognee - Review Skill runs the review task with the skill loaded - The review comes back with a score
- Should Improve? checks the score against the threshold
- Propose Improvement records feedback and creates a proposal (not applied)
- Get Proposal fetches the before/after for review
- A Code node builds the diff; the Approved? gate decides
- Apply Improvement writes the approved change
- Get Skill + Show Skill Delta confirm and output the result
The example is an authorization-boundary review: the code under review retrieves a dataset by ID, and the agent should flag that it never checks whether that dataset belongs to the authenticated user, never handles a missing record, and has no tests for the owner / non-owner / missing cases.
Before you start - n8n instance with Cognee node (v0.5.1 or higher) installed. From a local n8n instance, search for “cognee” right from the editor's Node panel, then click install. Details in verified-install docs.
- A cognee server with an LLM and embedding provider configured, since the review and proposal steps call the model. The easiest option is Cognee Cloud, which is fully managed and serverless, so there is nothing to install and the model and embedding providers are handled for you. You can also connect to a self-hosted cognee instance, but you will need to configure those providers yourself. The no-code Skill operations use cognee’s
/api/v1/skill
endpoints, which are available for self-hosted instances and are being rolled out on Cognee Cloud.
Ready to add persistent memory to your agents? Try cognee with Cloud deployment (serverless or private infrastructure) or book a call with cognee to discuss on-prem solutions. - Cognee API credentials in n8n (Credentials → New → Cognee API): enter your server’s Base URL, without a trailing
/api
, and API key. For Cognee Cloud, copy both values directly from your tenant dashboard at platform.cognee.ai.
Everything in the workflow itself happens in the n8n UI (no terminal commands needed).
Step 1: Configure the run
The workflow starts with a Manual Trigger (or a Webhook Trigger in production) and a Demo Controls Set node. This is where you set the values you adjust most while testing:
JSON
{ "skill_name": "code-review", "dataset_name": "n8n-skill-self-improvement", "skill_markdown": "", "task_text": " ", "score_instructions": "Grade your own review per dimension (coverage, correctness, ...) from 0.0 to 1.0.", "score_threshold": 0.9, "approved": "1" }
skill_name
/skill_markdown
— the skill to run and improve, inlinetask_text
— the review task to run with the skill loadedscore_instructions
— the rubric the agent uses to grade its own review per dimension; the node turns those grades into a singlescore
score_threshold
— the minimum score required to skip the improvement pathapproved
— whether the proposal passes the approval gate ("1"
in the local demo)
Step 2: Ingest the skill (verified node)
The Ingest Skill operation posts the inline SKILL.md
to cognee and stores it as a dataset-scoped skill:
JSON
{ "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"] }] }
The returned dataset_id
is reused by the later Get steps.
Step 3: Review the skill against a real task (verified node)
The Review Skill operation runs an agentic completion with the skill loaded. The query is the task plus the score_instructions
rubric, so the agent reviews the change and grades its own review. The node parses that into a flat result:
JSON
{ "score": 0.42, "missing_instruction": "No explicit owner / non-owner / missing-dataset test requirement", "result_summary": "Flagged the ownership gap but missed the test matrix", "dimensions": [{ "name": "coverage", "score": 0.4 }, { "name": "correctness", "score": 0.45 }] }
That score
is what the next step branches on.
The sample task is the authorization-boundary review. With the skill loaded, the agent returns a structured review that flags the missing ownership check, the missing 404 handling, and the missing owner/non-owner/missing-dataset tests.
Step 4: Let n8n decide whether to improve
The Should Improve? IF node compares the review’s score
(from Review Skill) to the threshold:
score < score_threshold
If the review scored below the threshold, the workflow takes the improvement path. If the score meets or exceeds the threshold, it routes to No Improvement Needed and exits cleanly. The threshold lives in n8n, is visible and adjustable, and is easy to swap for a stricter evaluator (an LLM-as-judge node, a CI score) without touching the cognee steps on either side of it.
The split of responsibility: the agent grades its own review against the score_instructions
rubric, the verified node parses those per-dimension grades into one score
, and n8n owns the threshold decision.
Step 5: Propose an improvement (verified node)
The Propose Improvement operation records the weak run and asks cognee for a rewrite. Crucially, it creates a proposal but does not apply it:
JSON
{ "items": [ { "kind": "skill_run", "run_id": "82a14c99…", "success_score": 0.42 }, { "kind": "skill_improvement_proposal", "proposal_id": "48d6f3f3-430f-460c-bf5b-2987086a43dd", "status": "proposed" } ] }
The proposed change stays in a holding state until n8n decides what to do with it. A single weak review can never silently rewrite your instructions.
Step 6: Review the diff before approving (verified node)
This is the step that makes the loop safe. The “Get Proposal” operation returns the proposal’s full before/after, plus the model’s rationale and confidence:
JSON
{ "proposal_id": "48d6f3f3-430f-460c-bf5b-2987086a43dd", "skill_id": "a49f5ceb-fe79-5094-bee6-ee1de4d45671", "confidence": 0.93, "rationale": "Clarifies and tightens existing rules so agent outputs strictly-structured, minimal issue reports focused on authorization, tests, and audit logging…", "old_procedure": "# code-review …", "proposed_procedure": "# code-review …" }
A Code node turns old_procedure
vs proposed_procedure
into a unified diff (skill_delta_markdown
) which makes it ready to drop into a Slack message or a PR. Here’s the real change from this run (excerpt):
Diff- Read the diff file-by-file and hunk-by-hunk. - Do not run or apply changes. + Do not run, apply, or modify code. Do not mutate state. 3. Authorization and data-access checks: - Apply one of these two patterns and verify the diff shows it: - - Caller-side validation (preferred if get_dataset doesn't accept a requesting user): + Caller-side validation is REQUIRED unless the get_dataset-enforces-acl pattern is present: 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 + If the check is missing or weakened, mark the issue Critical and supply the exact pseudo-diff. + 12. Failure-evidence handling: turn a "return get_dataset(requested_dataset)" example into a + Critical issue with the caller-side patch, repro steps, and a short-term mitigation. + 13. Enforcement checklist: before finishing, confirm every issue has the required fields.
The ownership-check lines were already in the skill — what changed is the framing: a “preferred” pattern became required, a Critical severity now fires when the check is missing, and two enforcement sections were added.
Step 7: Apply the approved change (verified node)
The Approved? IF node checks the approval flag. In the demo that’s the approved
control; in production you’d replace it with a Slack message plus a Wait-for-webhook approval (see the sticky note on the canvas).
On approval, Apply Improvement updates the stored skill in cognee (status flips to applied
):
JSON
{ "items": [{ "kind": "skill_improvement_proposal", "proposal_id": "48d6f3f3…", "status": "applied" }] }
Step 8: Confirm the result
Get Skill reads the skill back so you can confirm the new procedure is live, and Show Skill Delta emits the final skill_delta
/ skill_delta_markdown
. One missed authorization check → one concrete, approved edit to the instruction that was responsible for missing it.
Who does what
The whole point of the visual build: you run the entire loop without writing a line of code.
Ways to adapt the visual build
The demo keeps the approval flow simple so the loop is easy to inspect end to end. For production, swap Demo Controls
for:
- Read the diff file-by-file and hunk-by-hunk. - Do not run or apply changes. + Do not run, apply, or modify code. Do not mutate state. 3. Authorization and data-access checks: - Apply one of these two patterns and verify the diff shows it: - - Caller-side validation (preferred if get_dataset doesn't accept a requesting user): + Caller-side validation is REQUIRED unless the get_dataset-enforces-acl pattern is present: 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 + If the check is missing or weakened, mark the issue Critical and supply the exact pseudo-diff. + 12. Failure-evidence handling: turn a "return get_dataset(requested_dataset)" example into a + Critical issue with the caller-side patch, repro steps, and a short-term mitigation. + 13. Enforcement checklist: before finishing, confirm every issue has the required fields.
- A Webhook Trigger fired by Claude Code, your CI pipeline, or another agent runner
- A Slack node that posts the
skill_delta_markdown
packet — diff, rationale, confidence — for review - A Wait node or webhook callback that pauses until someone approves - A GitHub branch and pull request in place of the direct apply, so the skill change goes through normal code review
- A datastore table for accepted and rejected proposals, for an audit trail
- Different thresholds per skill type — tighter for security-adjacent reviews, lighter for formatting
The division of labor stays the same: n8n owns orchestration, scoring, approval, notifications, and the audit trail; the Verified Node owns memory, retrieval, proposal generation, proposal review, and application.
Self-hosted with Python SDK build
If you are a terminal-comfortable developer who wants the whole loop running locally for free against open-source cognee, the advanced/
template is for you. It does the same six cognee jobs through the Python SDK (cognee.remember
, cognee.search
with AGENTIC_COMPLETION
, and improve_skill
) driven by a small runner script and n8n Execute Command nodes:
Bash
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 excludes executeCommand
by default for security, so this build enables it explicitly. It’s the most hackable version and never leaves your machine — the trade-off is the terminal setup. See advanced/README.md
for the environment variables and run instructions.
A maintenance loop that keeps pace with the project
Agent skills are most valuable when they reflect how the project works today — not how it worked when someone first wrote the instruction file. This workflow gives that problem a structure: run, score, propose, review the diff, approve, apply. An authorization check that slipped through a review doesn’t have to slip through again — it becomes a specific, approvable edit to the skill, visible before it shapes the next run.
Download the workflow template, install the Cognee verified node and start with the visual build and one skill – a review habit your team already trusts. Let the workflow show you exactly how the skill changes after feedback, then move onto the advance template.
文章标题:快来看,n8n更新了!使用cognee和n8n构建自我进化的智能体技能
文章链接:https://news.qimuai.cn/?post=4446
本站文章均为原创,未经授权请勿用于任何商业用途