知识库与工作流:个人与团队

来源:所有者 2026-11-02 的决定(docs/hub-r4-progress.md 决定 131),由 Claude 整理成方案,所有者同日答复全部采纳;方案中的 14 个待定问题均按建议定下。本页是实施依据;各阶段的任务页在 docs/hub-r4-tasks/ 下,模型与合约的改动仍由合约负责人按本页落实。

结论

  • 知识库与工作流(原“任务包”)都只分两个空间:个人与团队。两边用同一套格式、存储与索引,区别只在谁能读。
  • 个人空间两边都放:Circle 本机一份,可选与 Hub 双向同步,同一成员的多台 Circle 共用;方式由本人选择(仅本机,或同步到 Hub)。
  • 个人空间由本人授权:默认只有本人可读;本人可把整个空间或某个目录授权给管理员或指定成员,随时收回。
  • 提交共享不审核:Hub 按程序检查依据、引文、来源与重复,并扫描凭据,通过即合并为团队的新版本;纠错靠撤回。Hub 仍不调用模型。
  • “任务包”在界面上改称“工作流”:工作流页分“工作流”(带验收的 pack)与“通用技能”(通用的 skill,没有验收)。工作流 = 技能 + 验收。英文与代码仍叫 pack。
  • 产品线改为可选:没有产品包也能建库;版本差异从版本历史中选择,不手填哈希。

需求(所有者原话)

  1. R1 只分两种:“从目前的团队知识库和个人知识库来看应该就只分这两种”。
  2. R2 索引一致:“是否能做到现在团队知识库的效果”,即个人也有知识树、出处核验、搜索、被引用次数与版本。
  3. R3 不依附产品包:“没有包哪里来的产品线?”
  4. R4 版本有意义:“你是打算从什么版本呢?通用 hub 平台会有这些吗”。
  5. R5 导入分清个人与团队:“这个导入知识是本地的还是团队的,怎么区分”“导入知识也放入一起设计”。
  6. R6 按账户区分“本人”:管理员与成员都用用户名加密码登录,账户由管理员添加,令牌绑定成员(决定 130)。
  7. R7 两边都放、双向同步:“两个都放,前提是circle支持知识库,也支持知识库同步,同步是hub和circle双向的(多客户端可共享,用户自己选择方式)”。
  8. R8 不审核:“不需要审核”。
  9. R9 个人空间由本人授权:“可以读,也就是说用户个人数据库设置权限,共享给管理员或者给其他人”。
  10. R10 工作流同样分个人与团队:“任务包我这么看也分为个人和团队,设计应该是和知识库一样的”;定名:“1.用工作流 2.工作流标签里面分为两种,一种是通用的skill 一种是我们的packs”。

仍然有效的约束

  • C1 Hub 只核验、不生成,不调用模型;归纳与提取在 Circle 一侧做(决定 15、26)。
  • C2 依据只能是可解析的引用,引文必须逐字出现在来源中(B01、hub/refs)。
  • C3 记录只追加,纠错靠撤回,不改写历史(决定 62)。
  • C4 内容寻址:条目与树按内容哈希标识,未变的子树共享(K01)。
  • C5 用个人凭据读取的来源不能作为团队知识的依据(拒绝码 personal_source)。
  • C6 团队、产品和业务系统的内容,不存在与无权限分开答;别人个人空间的内容对调用方看不出有没有(D05 R[3])。
  • C7 核心代码不写产品名,产品内容放在包里。
  • 决定 60:编译与评审中不用关键词规则,也不按关键词检索候选来源。

两个空间

  个人空间 团队空间
存放位置 Circle 本机;可选同步到 Hub Hub
谁能读 默认只有本人;本人可按目录授权给管理员或指定成员 全体成员;产品目录只给该产品线的读者
怎么写 本人经自己的 Circle 或控制台写入 提交共享通过即合并、管理员导入、产品包同步
收什么 已核验的条目,也收未核验的笔记与判断(标“未核验”) 只收已核验的条目,或有人署名的声明
数量 每个成员一个 每个 Hub 一个

同步(R7)

  • 方式由本人选择:“仅本机”时个人空间只在这台 Circle 上,Hub 不保存,任何人都读不到;“同步到 Hub”时 Circle 与 Hub 双向同步,本人的其他 Circle 经 Hub 取得同一份个人空间。可以随时切换;从“同步到 Hub”切回“仅本机”时,Hub 清除这些内容,记录只留哈希,相关授权随之失效。
  • 同步什么:条目与原文都按内容哈希标识、写入后不改;同步就是互相补齐对方缺少的对象,再移动“当前版本”指针,做法与 Git 相同。
  • 冲突:两台设备离线时各自改了同一条目,同步后两个新版本都保留并标为“有冲突”,由本人在 Circle 或控制台中选定一个;选定本身也是一次修改。不按“后写覆盖”自动取舍,避免静默丢失。
  • 核验:Circle 在本机用与 Hub 相同的确定性程序核对引文与路径;同步到 Hub 时 Hub 重新核验,不采信客户端的结论。
  • 前提:Circle 目前没有结构化的知识存储,需要新增本机知识库(存储、全文索引、版本)和同步;条目格式与同步接口写进合约,两边共用同一组测试样例。

授权(R9)

  • 默认只有本人可读。本人可以把整个个人空间或其中一个目录授权给全体管理员或指定成员,只读;对方在浏览和搜索中看到“来自某人的个人空间”。
  • 授权需要已同步到 Hub,因为别人经 Hub 读取;仅本机的内容不能授权,只能提交共享到团队。
  • 本人可随时收回;收回后对方不能再读,但已读过或已引用的内容无法追回,界面写明。授权与收回都写入记录。
  • 被授权的条目仍归本人:本人修改或撤回后,对方看到的随之变化。要让条目归团队所有,走提交共享。

条目(个人与团队相同)

部分 内容
陈述 一句话的知识,加可选的结构化数据
种类 沿用现有 7 种:定义、行为、用例、缺陷、观察、步骤、教训
依据 引用列表:来源加逐字引文,或一条已有条目;Hub 逐条核对
适用条件 产品线、版本、环境等,可为空(空 = 未声明);产品线从必填变为这里的一个可选维度
位置 所在空间的目录路径,可为空(未归类)
发布信息 谁、何时、经哪次会话或导入写入;取代了哪一条
状态 已核验、未核验、已撤回、被取代

条目按内容哈希标识,写入后不改;修改就是写一条新条目,并标明它取代哪一条。核对的是引文与路径,陈述的含义仍记为判断,不因核验抬高等级(决定 62)。

来源与组织

  • 原文(网页快照、文件、业务系统读取结果、会话摘录)按内容哈希存放,也分个人与团队。
  • 用个人账号读取的来源只留在个人空间(C5):引用它的条目既不能授权给他人,也不能提交共享,须先经团队连接重新读取并核对引文。
  • 上传的文件进个人空间,按本人授权可见;作为团队依据时由上传人署名,来源类型记为“声明”,团队条目上显示署名人(改写决定 62 中“上传不作团队根据”)。
  • 每个空间是一棵目录树,目录可以自己建。产品包变成团队空间里的一个挂载:发布产品包时挂上“/产品/产品线/版本线”这一支,骨架与同步沿用现有机制;没有产品包时团队空间照样可用。
  • 同一条知识只放在一个位置,其他地方用引用指向它,不复制。

索引(两个空间共用)

索引 用途 做法
目录 浏览 现有的内容寻址树
全文 搜索陈述、数据与引文 PostgreSQL 自带的 GIN 索引:文本按两字切分后存为数组再建索引,不加扩展和依赖;不用向量
引用 被引用次数、谁引用了它 现有引用索引扩展到个人空间;个人条目的引用只有本人可见
维度 按种类、状态、适用条件、来源类型筛选 记录索引

搜索框的范围可选个人、团队、共享给我的或全部,结果标出可见范围;仅本机的条目由 Circle 在本机搜索,Hub 不接收这些搜索词。搜索只用来找线索,不进入判定:任务中仍按地址读取,全文检索只给人和 Circle 的问答使用(决定 60)。

提交共享与写入团队

  • 提交共享:本人选一条已核验的个人条目发起。Hub 检查四项:依据都能解析、引文逐字一致、来源可以共享、与团队条目不重复;另做凭据扫描(决定 60 R8)。通过即合并为团队空间的一个新版本,不审核(R8),个人原条目保留;未通过时条目留在个人空间,附拒收码与原因。仅本机的条目提交时连同所需原文一起上传。
  • 去重:只与团队空间比对,不跨个人空间比对,不透露他人是否有同样的内容。
  • 写入团队:管理员从产品包声明的来源导入,或经团队连接读取业务系统;产品包脚本或 Circle 起草条目,Hub 按同样的方式核对。
  • 纠错:撤回后读取方看到“已撤回”,以它为依据的条目随之标出(沿用 grounds_withdrawn)。管理员可撤回任何团队条目;提交人可撤回自己提交的条目。
  • 导入两个入口(R5):管理员的“导入团队知识”从产品包声明的来源导入团队空间;成员的“导入个人知识”把本人的文件导入个人空间。按钮按角色显示,悬停提示写明进入哪个空间、谁能看到。

版本与引用

  • 每个空间一条版本历史:每次写入、合并或撤回产生一个新版本,记录谁、何时、因何;旧版本保留(决定 69)。
  • “版本差异”从版本历史中选“从”和“到”,默认上一版本与当前版本,列出新增、修改、删除的条目及其路径。
  • 知识版本是空间的历史快照;产品版本是条目的适用条件。产品目录下按版本线浏览沿用现有机制,那是筛选,不是知识版本。
  • 任务开始时锁定团队空间的当前版本,以及发起人个人空间在 Hub 上的当前版本;仅本机的条目不进入 Hub 上的任务。
  • 引用是内容寻址的地址(tree:<根>/<路径>@<条目>),知识更新后旧引用仍指向原来的内容;每次被用到时重核引文并记录漂移(决定 62)。
  • 依据须对结果的全部读者可读:团队条目,或已授权给这些读者的个人条目;否则先提交共享或补授权,提交结果时才受理。
  • 不回灌:条目的依据须是原文或业务系统的读取结果,不能只是 Circle 自己先前的结论;前一个平台的经验是,评审结论回灌后,后续评审只会复读。
  • 团队条目的被引用次数只计团队可见的结果,不含个人空间里的引用。

工作流(原任务包)

通用技能(skill)是通用的 harness 概念:一个带 SKILL.md 的目录,说明“怎么做”,由模型按需读进会话,不规定做成什么样才算完成,也没有任何一方检查结果。工作流在一个技能之外加上了 Hub 的验收:

组成 通用技能 工作流
怎么做(SKILL.md) 有 有,Circle 照样读进会话
输入(slots.schema.json) 无 一次任务需要哪些输入
验收(requirements.json、checks.json、functions/) 无 结果要满足的要求;Hub 在沙箱里运行检查脚本逐项判定,“未知”不计为通过
正反样例(samples/) 无 证明检查能区分对错
版本 无,复制即用 发布前做发布校验,每个任务锁定所用版本
使用范围 无 管理员按成员分配
  • 页面:导航“任务包”改为“工作流”。页面分两栏:“工作流”(workflow 种类)与“通用技能”(skill 种类,以后也放同步上来的个人技能)。工作流标题的悬停提示:规定做法与验收要求;由 Circle 执行,Hub 按验收要求判定结果。每个工作流的详情页把“验收要求”放在醒目位置。不画节点图,避免与按节点执行的编排工作流混淆。
  • 产品包与系统包不是工作流:产品包放到“知识库”,称“产品知识来源”;系统包放到“连接”,称“业务系统接入”。四个种类的界面用语由合约词表生成。
  • 说法:选一个工作流启动任务;任务按工作流的验收要求判定结果。英文与代码仍叫 pack,list_task_packs 等协议名不变。
  知识库 工作流与通用技能
个人空间 个人条目,Circle 本机,可选同步到 Hub 个人工作流与通用技能,Circle 本机,可选同步到 Hub
团队空间 团队条目,在 Hub 上 团队工作流与通用技能,发布在 Hub 上,按使用范围分配
授权 按目录授权给管理员或指定成员读取 按工作流或技能授权给管理员或指定成员使用
提交共享 核验依据、引文、来源与重复,扫描凭据;不审核 即“发布到团队”:沿用发布校验(结构、沙箱运行、引用),扫描凭据;不审核
版本 每次写入一个知识版本 每次发布一个版本(沿用现状)
任务中 开始时锁定知识版本 开始时锁定工作流版本(沿用现状)
纠错 撤回 停用或退役(沿用现状)
  • 个人空间先开放工作流与通用技能;产品与业务系统两类关联团队连接与凭据,只在团队空间。
  • 发布到团队沿用现有的“发布权”:它是权限,不是逐次审核;没有发布权的成员可以把个人工作流授权给指定成员使用。
  • 个人工作流跑出的结果只对发起人和被授权使用该工作流的人可见;发布到团队后按使用范围共享。
  • Circle skills/ 目录里的技能照常在本机使用;要同步或共享,补上 pack.json,作为个人的通用技能同步到 Hub。

权限与安全

事项 规则
个人空间谁能读 默认只有本人;未获授权的人查询时,回应与条目不存在相同(C6)。选“同步到 Hub”时服务器的数据库和备份中有这些内容,悬停提示写明
团队空间谁能读 全体成员;产品目录沿用产品线读者的规则
内容中的凭据 提交共享和授权时都做凭据扫描,命中则拒收,条目留在个人空间
成员停用与删除 停用:个人空间冻结,授权暂停,恢复后照常。删除:清除 Hub 上的个人空间内容,记录只留内容哈希;本机副本由该 Circle 处理
容量 每个成员在 Hub 上的个人空间默认 1 GiB,管理员可调整
任务隔离 任务只读发起人自己的个人空间,以及已授权给发起人的内容

改动范围

层 改动
模型(contracts/model.json,合约负责人) 新增空间(个人、团队)与授权;条目的产品线改为适用条件中的可选维度(改 K01 R[4]);提交共享、授权、同步的记录类型与拒收码;条目状态、同步方式的词表;同步接口;包种类的界面用语(工作流、通用技能、产品知识来源、业务系统接入);改写决定 25、决定 62 的相应条款
records 新迁移:全文索引(两字切分 + GIN)、按空间与授权的索引;已应用的迁移不改
knowledge 按空间的当前版本指针;同步(补齐对象、移动指针、标记冲突);授权检查;产品包挂到团队空间的产品目录;提交共享的检查、去重与合并
runs 开始时锁定团队与个人空间的版本;提交结果时检查依据的可见范围;个人工作流结果的可见范围
server 控制台知识库页分个人、团队、共享给我的三栏,加搜索、版本选择、提交共享与授权管理;导入分两个入口;工作流页分工作流与通用技能两栏,产品包与系统包分别移到知识库与连接
Circle(另一仓库) 本机知识库与个人工作流、通用技能的存储、全文索引与版本;本机确定性核验;与 Hub 的双向同步与冲突处理;同步方式的设置
现有数据 不迁移、不改哈希:现有产品树作为团队空间的产品目录显示,现有包作为团队工作流、通用技能、产品知识来源或业务系统接入,原有引用照常可解析

分阶段

  1. 工作流改名(不改结构):界面“任务包”改称“工作流”,分工作流与通用技能两栏;产品包与系统包分别移到知识库与连接;词表的界面用语随之改。
  2. Hub 空间:空间与授权、统一条目、全文搜索、从版本历史选择差异、导入两个入口;个人空间先只在 Hub 上,经控制台和 Circle 读写,暂不同步。
  3. 提交共享:自动检查、去重、合并、拒收码;依据可见范围的规则;提交人撤回;个人工作流发布到团队。
  4. Circle 与同步:Circle 本机知识库与个人工作流、通用技能,本机核验,双向同步与冲突处理,同步方式的设置与切换。
  5. 收尾:上传文件署名、原文归档、成员停用与删除的处理、容量限制。

实施状态

本表保留上述原始设计,按决定 140 的实施块更新;完整验收与合并状态由 Claude 记录。以下仅为本分支状态。

收尾项目 当前状态 对应决定及边界
上传文件署名 第一块已获 Claude 审查通过 决定 140,变基后提交 6bfccf9a;本人明确确认、精确采集隔离、未署名拒收、团队声明来源与署名人显示;合成验证通过,未作真实业务验证
原文归档与引文定位 第二块及修正已获 Claude 审查通过 决定 131、140,合约清单 9f4eb42b 已批准,修正提交 94babcda 已通过;空间/文件夹分页、显式保存、精确打开、全部匹配与上下文、转义 HTML、当前权限附件下载;本机合成检查与截图,未作真实业务验证
成员停用与恢复 第三块已获 Claude 审查通过 决定 122、140,提交 d2b57f63;同事务账号锁、私人分享暂停及恢复、团队副本保留;已合入同步入口与账户提交锁
容量调整与提示 第四块已实现,待 Claude 审查 决定 133、140,合约清单 591c4f47 已批准;记录重算旧用量、精确 MB/GB 输入、统一显示与拒收事实、同锁调额;已合入精确同步计量与容量准入
成员删除 第五块已本机实现,待 Claude 最终审查 决定 140,提案 d437875f 已批准;复用同步 purge,署名/归档/私人包纳入清除,永久墓碑、摘要审计、旧凭据及代次拒绝;团队与既有精确运行持有者保持原权限;实际失败、定向复查与截图见任务页