Busabase × Jan
Jan 知识库
本地推理与团队知识，各有清楚边界
Jan 已有本地模型、项目文件和 MCP 工具。团队需要共同使用与维护知识时，Busabase 提供共享 Doc 和结构化业务记录。连接远程服务前，先决定哪些资料允许离开本机。
接入指南 →
哪些资料留本机，哪些交给团队
按资料用途划边界，比按文件格式划边界更实用。个人推理笔记、未授权合同和离线参考资料可以留在本机；团队一致使用的产品说明、服务政策和已接受结论适合进入共享知识。一个项目可以同时使用两层资料，无需把整个本地文件夹上传才能开始。
对每类资料明确谁可以读、谁可以改，以及答案需要展示哪些来源。Doc 承接完整说明，Base 承接会变化的事实。Jan 在需要团队信息时查询指定空间，输出记录链接；无需团队资料的个人任务继续使用本地上下文。
知识放在哪里，由谁维护
政策 Doc
保存完整规则、适用对象、例外与依据，由政策负责人维护解释。
知识 Base
每个持续维护的事实一条记录：稳定键、值、来源 URL、负责人、适用范围与状态，关联对应政策 Doc。
更新 Skill
保存读取、取证与提案方法，指导 Agent 怎样处理资料，不授予数据访问权。
结果记录
把任务关联到产物链接、决定与未决核查，下一次运行读取真实结果，不从任务结束推测事实已通过。
本地模型、工具调用和远程数据是三次选择
选本地模型决定推理运行位置；启用远程 MCP 决定能向哪个服务发请求；Busabase 授权决定账号可以读取或修改什么。三者分别核对。首次验证使用不含敏感内容的已知记录，确认模型具备工具调用能力、认证成功且返回正确空间，再扩大到实际资料范围。
共享知识更新，不需要重传所有项目文件
发现旧产品说明时，先找到它的共享记录与来源，只修改有新证据的字段或段落。审核人看到旧值、新值和修改原因；接受后，后续 Jan 任务读取正式版本。保留本地文件与共享记录的引用关系，让个人资料不因一次修正被意外公开。
交接时留下可核对的结果
读取结果要能定位到具体记录，说明用了哪个来源、适用什么范围，不能只交一段没有出处的答案。提出修改时，返回 ChangeRequest 链接及涉及字段，让负责人能够直接看旧值、新值和修改理由。变更获得接受后，再返回正式记录并核对结果；有提案、有审核决定、正式值已更新，是不同的产物。接收任务先读取这些产物，遇到尚未接受的结论，继续按原正式记录处理。若资料已经失效，保留旧结论的适用范围与历史，由负责人补充新依据，而不是让下一位 Agent 自行猜测。
从一条已有事实完成首轮验证
- 01
选择一条已经维护、有明确来源的政策或事实，先指定负责人，再要求 Agent 修改。
- 02
读取当前记录，让 Agent 返回来源、适用范围与版本。确认它引用的是目标资料，再允许写入。
- 03
提出有边界的更新，展示旧值、新值、原因与依据。需要人审时保持提案，等有权限的决定后再接受。
- 04
从新任务重新读取正式记录，核对数值和来源；被拒绝或未解决的修改不进入正式答案。
连接与权限边界
Jan 支持远程 HTTP/SSE MCP 与 OAuth PKCE。它的工具权限设置可以批准工具调用，也有全局允许选项；这不会设置 Busabase 的记录权限。本地推理也不表示远程 MCP 请求留在本机：选定的查询和结果会经过所连接的服务。
可调整的对话指令
仅使用已连接空间中的团队政策 Doc 和已接受产品记录，回答时附记录链接。不要上传本地项目文件。共享事实过期时，提出有来源的修正，并展示生成的 ChangeRequest。
连接前的常见问题
使用本地模型，远程 MCP 资料也不出本机吗？
不会。模型执行位置和远程工具通信是两件事。先确定允许发送的资料，把私人本地文件排除在工具请求范围外。
会替代原生记忆吗？
原生上下文继续服务执行，个人偏好保持私有。只共享确实需要别人读取、核对或维护的知识。
怎样验证一次有用的循环？
读取一条已有记录，返回链接与来源；提出一项证据支持的修正，查看变更，再重读被接受的记录。有提案链接不代表正式记录已经变化。