Context Infra
组织 context 的 sourcing、存储与加工中心：会议、文档、知识库进来，会议梳理、议题、候选 issue 出去。
Context Infra 持续把组织里散落的 context——会议、飞书文档、知识库、agent session——放进同一个库，加工成可引用、可带走的东西。
它解决什么
散落的文档回到一个列表
飞书里的文档散在各人的云空间、各个知识库、各级文件夹里。平时想找一篇，先得回忆它在哪、是谁建的、在哪个群里发过。
Context Infra 把你有权看的全部文档和知识库节点拉到一处，按原来的文件夹路径还原成一棵树，每个文件夹里按编辑时间倒序。找东西从「回忆它在哪」变成「在一个列表里扫一眼」。
飞书纪要不够用，所以自己加工一份
开完会飞书也给纪要，但它常常漏掉真正有价值的认知，或者内容不全——讨论里最关键的那个判断，纪要里一句话都没有。退回去读逐字稿呢，又太细、噪音多，信噪比很低。
Context Infra 在两者中间补上一层：每场会自动（命中规则的会议纪要一生成就触发）、或者你手动点一下，跑一次 L1 加工，产出一份完整、可回溯的会议梳理——主线、结论、分歧、未决、待办都在里面。它不是摘要，长会的梳理能到上万字；要的是「不丢认知」，不是「短」。
所有的会也在同一个列表里
跟文档同理：你参与过的会按「系列 → 周 → 单场会」排好，每场会下面并排挂着智能纪要、文字记录、会议梳理三样。不用再去翻日历、翻群消息找那场会的纪要在哪。
任意上下文可以压成一个，带着走
「把过去两个月的会压成一份东西，然后带着它干活」——以前这件事只能手工复制粘贴。
现在在图谱页多选（会议、文档、知识库可以混着勾），存成一个 bundle；点「＋ 综合」让模型通读全部材料写一份综合稿；再点「分享」拿到一个链接——把这个链接丢给 ginit 里的 agent，它就带着这些上下文开始对话和干活。完整走法见给 agent 用。
和 Multica、Meeting 的分工
| 管什么 | |
|---|---|
| Context Infra | context 本体：sourcing、入库、加工、context 之间的关系边 |
| Multica | issue 骨架与执行：issue、项目、谁去干 |
| Meeting | 正在发生的那一场：实时转写与会中问答 |
三者的接缝是挂载：context 通过 issue_link 挂到 issue 上，agent 干活时从 issue 那一侧 retrieve。挂载记录会写下 attached_by——人挂的、机器挂的、还是 Dream 加工时挂的——所以人挂的那些记录本身就是机器自动挂载的监督信号。
L0 / L1 两层
- L0 事实轨迹：原样进来的东西。智能纪要、文字记录、文档正文。它只负责"这件事确实发生过、原文长这样"。
- L1 加工产物：模型读完 L0 写出来的东西。会议梳理、原子议题、候选 issue 都是 L1。
两层之间靠边连起来。边是一等公民：产 L1 的同时就落 derived_from，不是事后补的索引——所以溯源不是"尽力而为"，而是数据结构本身就带着。
一条 context 的生命周期
前四步平台自己走（命中触发规则的会自动跑），最后一步必须有人点——候选 issue 默认停在待审，没人批就不会出现在 Multica 上。
权责模型
同一场会，三个动作的权限口径是分开的：
| 动作 | 谁能做 |
|---|---|
| 拉取（L0 入库） | 对这场会有权限的人主动把它「放进来」，记为 sourcer |
| 加工（L1） | 一旦放进来了，平台就能加工，不挑触发者身份 |
| 消费（节点发现） | 别人只看到「已放进来 + 自己有权看」的那部分 |
加工产物由 **bot（应用身份）**创建并挂回原纪要，作者留痕是「Context Infra 应用」而不是任何个人——谁触发的加工，不该写成谁的署名。
孤岛是允许的
拉进来、但还没挂到任何 issue 上的散点会留在库里，不会被当成脏数据清掉。盘点页直接展示孤岛比例——它是个待办量，不是个错误。
评论
正在加载评论…