Knosis

knowledge+gnosis

Knosis（knowledge + gnosis）是面向 agent 的知识底座：既能让个人 agent 从日常使用轨迹里累积知识，也能让 agent 在企业级任务上累积对任务和数据的理解。每条知识都带来源、证据和状态，可审计、可撤回、可继承。

Personal Agent → Enterprise Agent → 知识体系
两类场景

同一套知识层，服务个人与企业

知识的格式、证据、内化、选取与继承是同一套；区别只在知识从哪里来、拿去做什么。

Personal agent

从你自己的 agent 会话里累积知识

Codex、Claude Code 的会话变成标准轨迹，agent 从中提取能被环境反驳的知识、验收入库，下次会话通过 MCP 自动取用。

kb collectATIF v1.7git 回滚MCP
进入 Personal Agent →
Enterprise agent

在企业任务和数据上累积理解

在 benchmark 或业务数据上，agent 边做边把对数据和任务的理解写成知识，用反馈、检查和工具验证，再继承给同类新任务。

9 类异构数据OSI 本体dev 反馈评测
进入 Enterprise Agent →
主打

知识在执行中产生，在环境里验证

不同于从文档出发的 wiki 式知识库，Knosis 的知识由 agent 在做任务时总结出来，每一条都要拿数据、工具或反馈去支持或反驳。失效的知识可以撤回并向下游传播。

Discovery 发现agent 在数据或轨迹上探索，把发现写成带条件、带来源的知识单元 κexplore · extract
Internalization 内化证据支持或反驳；去重、矛盾处理、构建知识体系refine · consolidate
Use 使用按任务选取知识进入决策，记录引用了哪些知识decide · MCP
Inherit 继承知识库独立于工作区，新任务可继承全部或只继承元知识与 skillkb merge · --kb
知识体系

不止一张清单：知识图谱、流程图等多种形式

同一批知识单元被组织成知识体系树、知识图谱（KG）、流程图、派生图、规则与公式卡片，以文件形式存进知识库，可以在命令行、MCP 和本网站上查看。每个节点、每条边、每个步骤都引用它来自的知识单元。

知识体系树kb/outline.yaml

分几块、各讲什么？场景 → 数据间关系 → 具体对象。

agent · organize
知识图谱kb/graph.json

有哪些对象、它们是什么关系？每条边引用说了这件事的单元。

agent · structure
流程图kb/flows/*.json

某类任务按什么步骤做、在哪检查、在哪分支？由 procedure、method 与 skill 组成。

agent · structure
派生图derived_from · merged_into

哪条知识由哪些推出、并入或替换？撤回沿它向下游传播。

Knosis 计算
规则与公式卡片rule · formula

每个对象上有哪些规则和公式？按知识图谱的实体分组。

Knosis 计算
看九个数据集合成的知识总图 → 知识体系怎么构建
特点

知识，不是记忆，也不是 skill

判别标准只有一条：能不能被环境中的证据反驳。能被反驳的才算知识。三者 Knosis 都管，但分开存放、分开评价。

memoryskillknowledge（Knosis）
内容发生过什么、看到过什么怎么做一件事关于环境 / 数据的带条件断言
能否判真假只是记录看好不好用能，可被支持或反驳
价值标准能检索到任务成功正确性与收益分开衡量
和读者的关系绑定某个 agent和读者能力有关真假不依赖读者，收益依赖读者
怎么更新追加改写证据驱动：接受、收窄条件、撤回并向下游传播

可审计

每条知识有来源（数据位置、工具调用、反馈题目、轨迹步骤）和证据链。

可撤回

父单元被撤回，派生出的后代跟着撤回或失效；数据指纹变了，旧证据自动过期。

正确 ≠ 有用

按任务选取是单独一步；有没有用写成 usage 元知识，由 dev 反馈和消融检验。

不绑定 agent

Knosis 不自己当 agent：同一份知识库可以给 Codex、Claude Code 或任何 MCP 客户端读。

知识层与内化 →

kb + evidence、知识单元 κ，以及知识库如何保持正确、不重复、不矛盾。

知识体系 →

跨数据集的知识总图，以及 Demo 与结果：每个 benchmark 一次完整运行，抽出的每条知识和证据。
Personal agent

让你的 agent 记住已经验证过的东西

你和 Codex、Claude Code 的每次会话都留下轨迹：跑过的命令、看到的输出、踩过的坑、修好的办法。Knosis 把这些轨迹变成一份个人知识库，里面是能被环境反驳的断言，持续保持正确，并在下次会话里自动取用。

开始使用 → 看一个个人知识库
从轨迹到知识

会话里的一步，变成一条可核查的知识

轨迹统一成 ATIF v1.7。提取知识的 agent 引用到具体步骤；只有轨迹本身给出了结果（比如命令输出），才记为支持证据。

evidence/traces/rollout-…-7f2a.jsonATIF v1.7
1
user
跑一下 SpreadsheetBench 的测试
2
agent · exec
pytest -q tests/test_adapter_spreadsheetbench.py
ModuleNotFoundError: No module named 'openpyxl'
3
agent · exec
pip install openpyxl==3.1.5
Successfully installed openpyxl-3.1.5
4
agent · exec
pytest -q tests/test_adapter_spreadsheetbench.py
2 passed in 2.67s
extract
collect/knosis-env-openpyxl
knosis 环境跑 SpreadsheetBench 测试需要 openpyxl；缺少时报 ModuleNotFoundError，装 openpyxl 3.1.5 后通过。
condition
本机 conda env knosis，Python 3.11
provenance
evidence/traces/rollout-…-7f2a.json#step/2 ; #step/4
toolinstanceverified
support · data
step 4 输出：安装后 2 passed

示意：一次会话里 agent 会提取出的知识长这样。

日常闭环

收集、验收、内化、复用

每天一条命令。每次收集都是本地知识库里的一次 git 提交，任何改动都能查看、能回退。

收集

找最近的会话，跳过已收集、在知识库里运行的、工具调用太少的

kb collect --since 1d
验收

新单元必须引用本次轨迹、不新增检查问题；不过就重试一次，仍不过就 git 回退

knowledge check
内化

去重、处理矛盾，再把知识串成大纲：场景 → 关系 → 对象

knowledge consolidate
复用

下次会话通过 MCP 先读大纲再检索；写入前自动检查

install --kb ~/kb
轨迹来源

读你已经在用的 agent

解析器自己实现，不依赖外部库。每一行来源记录都记账（映射、计数或跳过），没测过的格式版本会给出提示，而不是悄悄解析错。

Codex

rollout 会话：消息、思考摘要、工具调用与按 call id 配对的输出

CLI 0.147 · 0.149 · 0.160 · 0.163

Claude Code

按 message id 合并分块记录，按 tool_use_id 配对结果，子 agent 一并挂上

2.1.x · subagents

OpenAI messages

任何以聊天消息（含工具调用）记录日志的框架，JSON 或 JSONL

role · content · tool_calls

逐步记录

ReAct 风格的逐步记录：每步的思考、代码与环境反馈（如 AppWorld）

instruction · steps · success

ATIF v1.7

Agent Trajectory Interchange Format；Knosis 所有轨迹都存成这个格式，也可直接读入

schema_version ATIF-v1.7

Who&When

带人工标注的多 agent 失败日志：检验从轨迹得到的知识能否正确归因失败

184 logs · agent / step labels
记什么

只记能被环境反驳的知识

会记下

  • 项目约定：目录结构、入口、测试怎么跑
  • 数据的坑：编码、缺失值、不唯一的键
  • 工具与命令在这台机器上的实际行为
  • 报错的原因，以及怎么解决的
  • 方法：如何发现或验证某类知识

不会记

  • 用户偏好与对话记忆（无法被环境反驳）
  • 一次性的具体任务答案
  • 闲聊
  • 密钥、token 与口令
  • 轨迹支持不了的说法保持 inferred，不会标为 verified
开始使用

三条命令

# install
git clone https://github.com/Eason-nuosen/Knosis && cd Knosis
conda env create -f environment.yml && conda activate knosis

# personal knowledge base (a local git repo)
knosis kb init ~/kb
knosis kb collect --kb ~/kb --since 1d              # Codex
knosis kb collect --kb ~/kb --since 1d --source claude
knosis install --kb ~/kb                            # MCP

# browse it
knosis knowledge outline --ws ~/kb
knosis knowledge select --ws ~/kb --text pytest

MCP 服务 · 16 个工具

knosis mcp --ws ~/kb：先看大纲再检索；写入前自动检查，引入新问题就拒绝。

knowledge_outlineknowledge_graphknowledge_selectknowledge_traceknowledge_indexknowledge_skillsknowledge_addknowledge_updateknowledge_candidatesknowledge_checkknowledge_verifyevidence_addtool_listtool_cardtool_runworkspace_next

同一个坑，不再踩第二次

知识本来就在你的会话里。Knosis 把它留下、核查，再交还给 agent。

看一个个人知识库 →知识层如何工作
Enterprise agent

让 agent 先弄懂你的数据，再给答案

在 benchmark 或业务数据上开一个工作区。agent 先探索，把对数据和任务的理解写成知识，用 dev 反馈、可执行检查和工具验证，再带着这些知识作答；知识库随后继承给同类新任务。

看演示结果 → 支持的数据
13个数据入口
9类异构数据
11个 benchmark 完整跑通
OSI本体标准
异构数据

同一套知识层，跑在 9 类数据上

导出器把任务变成工作区里的数据与题目，GT 留在原始目录；打分器统一接口，dev 反馈与测试评测共用。

工作区

探索、抽取、修订、决策

Knosis 逐阶段驱动 agent（或 agent 读 AGENTS.md 自己推进）。每个阶段都验收并提交 git；agent 看不到测试答案，也不能运行评测。

01explore

摸清数据，提出候选断言

02extract

写成带条件与来源的 κ，快照 K_0

03refine × n

提交 dev 预测，读逐题反馈，修订知识

04consolidate

去重、矛盾、体系；每步验收或回滚

05decide

选取知识作答测试题，记录用到哪些知识

每个工作区有反馈预算；dev 与测试题不重叠；反馈可以给答案，也可以只给对错。
企业语义

agent 能检验的 OSI 本体

OSI（Open Semantic Interchange）是面向企业数据的开放语义层标准。Knosis 的本体按它的三层组织，上层建立在下层之上；每个元素和其他知识一样带证据、可撤回。

L3
映射

哪些列对应哪个业务概念

orders.cust_id→Customerorders.amount→Revenue
建立在 ↓
L2
概念

业务概念与它们之间的关系

Customerplaces →OrderRevenue=Σ Order.amount
建立在 ↓
L1
语义模型

表、列、主键、表间关联、度量

customersPKcust_idordersFK →customers.cust_id

企业已有的语义模型可以导入（可去掉 GT），由 agent 在数据上检验，修正或撤回不成立的部分。

评测

知识正确，不等于有用

knosis eval 分开报告三件事；同一工作区的 fork 对照不同知识对同一任务的作用。

task

任务指标

每个 benchmark 的官方指标（EM / F1、RMSE、AUROC、准确率…），附参照基线。

correctness

知识正确性

在 GT 允许的地方给知识本身打分，结果不回给 agent。

usage

知识引用

每个答案用了哪些知识，用到与没用到时的正确率。

noneK_inheritK_0K_finalws fork --drop
架构

四层 + 工作区

数据层

13 个数据入口；GT 软隔离

知识层

kb（κ、OSI 本体、skill、大纲）+ evidence

工具层

sql、profile、joins、tabpfn、fit、newton、sheet、autoschemakg、ultra

决策层

任务指标 + 知识正确性 + 引用统计 + 参照基线

knosis ws init tabarena healthcare_insurance_expenses \
       --out ws/tab --dev 100
knosis ws run ws/tab --agent codex --rounds 2 --consolidate
knosis eval ws/tab
knosis kb merge ws/tab --kb kb-tab      # keep the knowledge
knosis ws init tabarena <another> --kb kb-tab --kb-scope method

接入自己的数据

一个数据集就是 loader、导出器、打分器三个小文件，各自注册一次即可。见仓库 docs/extending.md。

知识层与内化

每条知识，都带着证据

两大块：kb 放结论，evidence 放过程。内化让知识库在不断增长时仍保持正确、不重复、不矛盾、成体系。

知识体系的组成形式

同一批知识，五种组织方式

内化不止于一张知识清单。同一批知识单元被组织成五种形式，各自回答一个问题。它们都不新增断言：每个节点、每条边、每个步骤都引用它来自的知识单元，由 Knosis 检查引用。

知识体系树kb/outline.yaml

分几块、各讲什么？场景 → 数据间关系 → 具体对象。

agent · organize
知识图谱kb/graph.json

有哪些对象、它们是什么关系？每条边引用说了这件事的单元。

agent · structure
流程图kb/flows/*.json

某类任务按什么步骤做、在哪检查、在哪分支？由 procedure、method 与 skill 组成。

agent · structure
派生图derived_from · merged_into

哪条知识由哪些推出、并入或替换？撤回沿它向下游传播。

Knosis 计算
规则与公式卡片rule · formula

每个对象上有哪些规则和公式？按知识图谱的实体分组。

Knosis 计算

点卡片看 NewtonBench 的真实例子。structure 一步的验收：知识图谱至少引用 60% 的活跃对象知识，流程图至少引用 60% 的 procedure / method / skill，不改动任何单元，所有引用都指向活跃单元。

kb/知识主体
knowledge/知识 = units + ontology，读取时合在一起
units.jsonlκ：对象知识 + 元知识（method / usage）
ontology/OSI 标准的 3 层本体，适配企业数据
skills/使用流程：引用知识，讲怎么做
outline.yaml知识体系：场景 → 数据间关系 → 具体对象
evidence/来源与验证全过程
ledger.jsonl证据账本：支持 / 反驳 / 无法判定 / 不适用，附数据指纹
checks/可执行检查（SQL / Python），重跑并记证据
feedback/dev 题反馈记录（给答案 / 只给对错），带预算
traces/来源轨迹（ATIF v1.7）
consolidate.jsonl内化记录：合并、收窄、撤回、替换、归纳

一条知识 κ = (内容, 形式, 条件, 来源, 状态)

下面是演示里 agent 真实写出的一条：


      

        
content知识内容：自然语言、公式或三元组

        
form表达形式，7 种（见下）

        
scope粒度：对象知识 3 种 + 元知识 2 种

        
condition成立条件与已知例外

        
provenance来源：data/…、tool:…、feedback:…、traces/…#step/n

        
status由 agent 写，Knosis 检查它与证据是否矛盾

        
check可执行检查，knowledge verify 重跑

        
derived_from父单元；撤回沿派生链传播

      

    


    

      

        
form · 形式
知识用什么形态表达，共 7 种。例子用示意的 orders / customers 两张表。

        

          
finding观察到的现象

            

            
3% 的 orders.amount 为负值

          
fact确定的事实

            
ordersPKorder_id
唯一，无空值

          
rule带条件的规律

            
IFstatus = 'refund'
THENamount < 0

          
schema结构：表、键、本体元素

            
orderscustomerscust_idN : 1

          
formula公式 / 方程

            
E = mc2
F = G m1m2r2
Revenue = Σ amount − Σ refund

          
tool工具的行为与限制

            
>>> ws["C2"] = "=A2+B2"
>>> ws = reload(path)
>>> ws["C2"].value
None
openpyxl 写入的公式不会重算

          
procedure步骤型表达

            
  1. 按候选键分组计数
  2. 查重复与空值
  3. 判断表的粒度

        

      


      

        
scope · 粒度
对象知识说环境；元知识说知识：怎么得到它、怎么用好它。

        

          
元知识 META关于知识本身

          

            
method怎么得到知识
发现或验证某类知识的方法；可以带可执行检查，并且能脱离原工作区运行。
例：「判断表的粒度：按候选键分组计数，查重复和空值」
产生 · 验证 ↓ 对象知识

            
usage怎么用好知识
某条知识或 skill 对什么任务、什么读者有效；由 dev 反馈和消融支持或反驳。
例：「用到知识 X 的题 0/1，没用到的 3/4 → 标为 contested」
选取 → 任务

          

        

        

          
对象知识 OBJECT关于环境 / 数据

          

            

              
instance具体对象
一行、一个节点、一条边、一列
例：「订单 1042 金额为负，但状态是 paid」

            

              
relation对象间结构
join、包含依赖、本体关系
例：「orders.cust_id ⊆ customers.cust_id，多对一」

            

              
dataset整份数据
规律、分布、公式
例：「amount 右偏，取对数后近似正态」

          

          
instancerelationdataset细 → 粗

        

      


      

        
status · 状态
由证据驱动的生命周期。状态由 agent 写，Knosis 检查它与证据账本是否一致。

        

        
证据的四种判定：supportrefuteundeterminednot_applicable· 数据指纹变化后证据过期

      

    


    
usage 管有没有用，skill 管怎么做

    

      
usage 单元（元知识）skill

      
是什么「知识 X 对任务 T、读者 R 有没有用」的断言把若干知识组合成的解题流程

      
存放kb/knowledge/units.jsonl（scope=usage）kb/skills/*/SKILL.md

      
讲不讲对错讲，可被 dev 反馈或消融反驳不讲，只讲步骤

      
例子NGDBench 演示：用到「类别归一化」的聚合题 1 题全错、没用到的 4 题对 3 题，这条 usage 单元被标为 contested，之后默认不再被选取NewtonBench 演示的 discover-positive-force-law：引用 18 条知识的定律发现流程

    

  


  

    
内化

    
让知识库保持正确、不重复、不打架、成体系

    
内化是一组作用在 kb 上的算子。agent 判断内容，Knosis 检查不变式；每步验收不过就回滚，通过后把操作记进 evidence/consolidate.jsonl。

    

      
已实现
verify 验证
重跑可执行检查、记证据；状态必须与证据一致，数据指纹变了证据过期。

      
已实现
dedup 去重
同一对象上内容相近的单元合并为一条；旧 id 留 merged_into 别名。

      
已实现
conflict 矛盾处理
互斥的断言：收窄条件让两条各自成立、用新证据裁决、或按版本替换；未决的标 contested。

      
已实现
organize 构建体系
把单跳知识串成「场景 → 关系 → 对象」；归纳出的上位规律必须写明出处并再验证。

      
部分
archive 归档
撤回、失效、已合并的单元不进默认检索，都不删除；按 usage 自动归档还没做。

      
为什么要内化
知识库会越收越多：同一件事被重复记下、新证据推翻旧结论、环境变了旧知识过期。不整理，检索到的就是重复、互相打架、彼此孤立的知识。

    

  

  







  

    

      

        
知识体系

        
知识，内化成体系

        
每个知识库内化成五种形式：知识体系树、知识图谱、流程图、派生图、规则与公式卡片。每个节点、每条边都引用它来自的知识单元。

      

    

    

      

        
九个 case 合成的一张知识图谱

          
九个知识库按数据集加前缀合成一个总库，再跑一遍内化：去重、处理矛盾、结构化。颜色代表数据集；白色节点是被多个数据集的知识共同引用的「桥」。

          

        

        

        

      

    

    

      
Demo 与结果

      
九类数据，各一个经典 case

      
每个 case 展示一道题的完整链路，以及内化后的知识：知识图谱、流程图、知识体系、派生图、规则与公式卡片。

      

      
全部 benchmark 的结果（含更多数据集）
        

        
「收窄」是矛盾处理时改写条件，让两条知识各自在不同条件下成立。

      
演示由 Codex（gpt-6.1-sol，reasoning effort medium）驱动。每个设置只跑一次、题量很小，数字只说明流程跑通与现象，不构成统计结论。