PostgreSQL码农集散地

这个 2MB 的项目与我的"AI 屠龙刀"理念竟如出一辙

一、前言:为什么我会"认真研究"一个 4 star 的新项目

上周在开放原子的opentenbase杭州站活动中分享了周六的会议我爆出了 AI “屠龙刀” 的秘密

会上碰到了老朋友易景数据创始人老章,现场跟我演示了他们刚刚开源的 GitHub 项目:HaloTech-Co-Ltd/hk2,4 stars,2.2MB,创建不到一个月。描述写:

"Halo Kernel Knowledge, aka hk2 - a knowledge-base (KB) driven coding agent"

关键词是 "KB 驱动" 。

我自己的 AI 屠龙刀理念,内核三条:

  1. 载体不重要,沉淀在载体上的才值钱(LLM / Agent / 联网是塑料,记忆/经验/SOP/技能是金)
  2. 用进废退(积累 / 迭代进化 / 遗忘三位一体)
  3. 多 profile 虚拟专家团(DomainOS)

读完 hk2 的 README,我心里"咯噔"一下——这个中国公司(易景科技)用 207 个 JS 文件,把"KB 当真相源"这个思想结构化、可编程地实现了。跟我理念高度对齐,但介质不同。

我决定认真深读它,把"它做对了什么、我想借鉴什么"挖出来。

二、HK2 在做什么:3 句话讲清楚

  1. 每次你敲一句话,HK2 先在 KB 里搜一圈(per-request knowledge graph)
  2. 搜到的内容拼成一个图谱,塞进 LLM 的 system prompt
  3. LLM 永远在"已检索"状态起步,而不是"agent 决定要不要检索"

听起来简单?核心创新在 "自动 + 预填" 这两个字——它把检索从"agent 的 lazy 行为"变成"系统的 eager 行为"。

三、HK2 跟我的 AI 屠龙刀对照(11 维度)

我用 11 维度对比了 HK2 和我自己的 AI 屠龙刀(我部署了 cognee + 75 个 skill + 多 profile),结果让我意外:

维度
我的 AI 屠龙刀 / cognee
hk2
异同
KB 是中心
✅
✅(README 第 4 行直接写)
完全同
存储介质
PG + pgvector + AGE 图
纯 JSON + 自写 BM25
不同
向量检索
✅ 主要
❌ 没有
不同
知识图谱
AGE 图
JSON {nodes, edges}
思路同,介质不同
图内容
实体关系(语义)
代码结构(调用/继承/导入)
不同语义层
三空间划分
没有
Holy / Eden / Index
hk2 独有
最高准则
没有
hk2-supreme-code
 永久条目
hk2 独有(可借鉴)
KB 优先硬约束
soft prompt
soft tool result hint
思路一致
per-request 上下文
cognee recall()
buildRequestGraph
 拼 system prompt
思路一致
多语言代码解析
不擅长
14 种 tree-sitter + 正则回退
hk2 强
存储性能
适合大项目
JSON,大项目可能慢
我占优

最让我惊艳的是: HK2 跟我不是替代关系,而是同一个思想的两个实现路径。

四、HK2 最让我想借鉴的两点(已落地到我自己的屠龙刀)

借鉴 #1:hk2-supreme-code 永久宪法条目(已落地)

HK2 的设计:

  • 最多 100 条规则
  • 每条 ≤200 字符
  • 注入 system prompt 第一段
  • 所有 KB 内容都不能违反
  • 当 Eden 知识与 Supreme 冲突,Eden 永久退役(supersededBy)

我做了什么:立刻在 /root/.hermes/profiles/digoal/skills/supreme-code/ 落地 skill,加 3 条核心宪法:

$ python3 supreme_code.py add "复盘、反思、总结、沉淀:每件事做完必留笔记..." --scope all
✅ sc-001 已添加
$ python3 supreme_code.py add "灵性比听话重要:综合报告宁可少写一个领域..." --scope writing
✅ sc-002 已添加
$ python3 supreme_code.py add "数据校验:每个数据有来源,不编造不凑数..." --scope all
✅ sc-003 已添加
$ python3 supreme_code.py inject
# Supreme Code (MUST OBEY — 不可违反)
1. [sc-001] 复盘、反思、总结、沉淀:...
2. [sc-002] 灵性比听话重要:...
3. [sc-003] 数据校验:...

为什么这条最值得借鉴:它解决"agent 越改越偏离用户原始诉求"的问题,方法是"用代码强制优先级",不是用 prompt 提示。 SOUL.md 是软约束,Supreme Code 是硬约束。

借鉴 #2:Per-request knowledge graph prefill(已落地)

HK2 的杀手锏: 每个用户消息来时,先把 KB 内容组装成一个图谱塞进 LLM system prompt。LLM 永远在"已检索"状态起步。

我做了什么:写了 cognee_per_request_kg.py 工具,直接调主人已部署的 cognee(主人的 6 个 datasets / 113 nodes),每次 LLM 调用前自动 recall 一次:

$ python3 cognee_per_request_kg.py prefill "PostgreSQL 的 HNSW 索引怎么调参?" \
    --dataset cognee_vs_powermem_demo --top-k 3

<!-- Per-request Knowledge Graph (auto-prefilled) -->
<!-- Source: cognee recall() on user message -->

[KG-1] (score=0.000) kind='graph_completion' ...
    根据提供的上下文,没有关于 PostgreSQL HNSW 索引调参的具体内容。

<!-- End KG prefill -->

实操过程中的踩坑(老实记录,SOUL L17):

  • cognee v1 API 关键字错(dataset_ids → datasets → user_id 都没,ACL 走 get_default_user())
  • LLM_API_KEY 没注入,要 source ~/.hermes/profiles/digoal/.env 拿 MINIMAX_CN_API_KEY
  • 主人 cognee_db 的 dataset 名字要用 cognee_vs_powermem_demo,不是 digoal_pg_blog_2026_04(后者在 schema 隔离里)

为什么这条最值得借鉴:它解决了 multi-step retrieval agent 的高成本痛点——agent 不用"决定要不要检索"了,检索是前置工序,不是 lazy evaluation。我那个 cross-domain-insights cron 的 7 个 sub-agent 之前要各自检索,改成 prefill 后能省一半 token。

五、HK2 的"三空间"我打算白嫖(暂未落地)

HK2 把 KB 分成三层:

  • Holy Space:稳定的设计知识、关键算法
  • Eden Space:频繁更新的目录、模式
  • Index Space:BM25 + 图谱 + 各空间索引

Eden 跟 Holy 冲突时,Eden 永久退役(supersededBy 标),不再召回。

这个我没立刻落地,因为我用 cognee 三层记忆架构(holographic + cognee + 三层),但 HK2 这个"冲突自动退役"的机制值得借鉴——cognee 现在的"语义冲突"靠 LLM 自己解决,这里用代码强制,更可靠。

我先沉淀这个思想,等下次再动手实现。

六、HK2 跟我的屠龙刀不是替代,是三层关系

┌─────────────────────────────────┐
│   我的 AI 屠龙刀 (DomainOS)        │
│   - 5 profile 虚拟专家团        │
│   - cron 自动化运营              │
│   - 跨领域思维碰撞              │
│   - 多 Agent 编排              │
│   (主人在云上 7x24)             │
└──────────┬──────────────────────┘
           │ 借鉴 hk2 的
           │  Per-request KG
           │  Supreme Code
           ▼
┌─────────────────────────────────┐
│  hk2 风格 per-profile KB       │
│  - 自己的 Holy/Eden/Index    │
│  - 自动 LLM 学习             │
│  - 三空间冲突退役            │
│  (每个 profile 内部用)        │
└──────────┬──────────────────────┘
           │ 调用的能力层
           ▼
┌─────────────────────────────────┐
│  cognee / mem0 / HNSW        │
│  - 向量检索                   │
│  - 图谱                       │
│  - 内存                       │
└─────────────────────────────────┘

HK2 不是替代品,而是"我某个 profile 内部的 KB 系统实现参考" 。

七、给读者的两个行动建议

  1. 如果你有自己的 KB / 屠龙刀 / DomainOS:
    • 抄 HK2 的 supreme-code 模式,把"不可违反的硬约束"从自然语言段落升级成结构化 JSON
    • 加 per-request prefill,LLM 永远在"已检索"状态起步
  2. 如果你是 HK2 用户:
    • 等它 0.6 stars 再用,4 stars 太早期
    • 关注它的"三空间冲突退役"实现,我会在自己的 cognee 部署里借鉴

八、我的真研究流程(给想做深读的人)

  1. codegraph init — 207 文件 / 2869 节点 / 12465 边,5 秒建索引
  2. 派 sub-agent 深读 — 用 mcp__codegraph__codegraph_explore 找关键节点,154 秒出 40KB 笔记
  3. 亲自验证 — 重要章节自己 read_file 看源码,防止 sub-agent 幻觉
  4. 写主报告 — 整合 sub-agent 笔记 + 自己验证 + 主人哲学对比

总结一句话:HK2 是中国公司在 AI coding agent 领域做的一件思路对、哲学对、但工程还需打磨的事。它不抢我的饭碗,它是给我当师傅的。

下次你写自己的 AI 屠龙刀,记得深读优秀项目,不是为了复用代码,是为了验证思想。

我是 digoal,深读不易,选对方向更难。 KB 当真相源,不是空话,是结构化、可编程的工程实践。