Busabase × nanobot
nanobot 知识库
把个人记忆中有用的结论交给团队维护
nanobot 已有持久记忆与历史。业务事实需要跨越一个助手、由同事共同使用时，Busabase 提供共享 Doc 与 Base。个人偏好继续留在原生记忆中，团队知识则带上明确来源和负责人。
接入指南 →
记忆能留下来，团队仍需要知道谁接受了它
会话消息帮助继续对话，历史支持回溯，长期记忆保存偏好和稳定背景，GitStore 提供版本线索。团队业务知识还需要回答：依据是什么，谁维护，适用于谁，是否已经被接受。保存时间更长并不能替代这些责任信息，也无需因此否定原生记忆的价值。
先选择真正需要共享的结论，而不是把 SOUL、USER、MEMORY 全部上传。将完整业务规则写入 Doc，具体事实放 Base；每条记录关联原始来源、负责人及接受状态。个人习惯和私人背景继续留在本地层，团队记录则可由多个成员共同维护。
知识放在哪里，由谁维护
政策 Doc
保存完整规则、适用对象、例外与依据，由政策负责人维护解释。
知识 Base
每个持续维护的事实一条记录：稳定键、值、来源 URL、负责人、适用范围与状态，关联对应政策 Doc。
更新 Skill
保存读取、取证与提案方法，指导 Agent 怎样处理资料，不授予数据访问权。
结果记录
把任务关联到产物链接、决定与未决核查，下一次运行读取真实结果，不从任务结束推测事实已通过。
记忆与正式政策冲突时，保留双方依据
让 nanobot 先读取共享政策，而不是直接按照记忆改写记录。把差异定位到具体字段或段落，说明记忆对应的来源与共享政策当前版本。新的依据确实改变结论时提交变更；证据不足时留下待核项。不要把“之前这样说过”写成团队的批准记录。
下一次任务怎样复用，而不带走全部私人记忆
交接记录链接、适用范围、来源和未决问题，接收任务用自己的身份重新读取。若权限不同或来源失效，明确指出并交给维护者修复。资料更新后，以正式记录为入口继续；个人记忆可以保留旧背景，但不能成为跳过当前版本核对的理由。
交接时留下可核对的结果
读取结果要能定位到具体记录，说明用了哪个来源、适用什么范围，不能只交一段没有出处的答案。提出修改时，返回 ChangeRequest 链接及涉及字段，让负责人能够直接看旧值、新值和修改理由。变更获得接受后，再返回正式记录并核对结果；有提案、有审核决定、正式值已更新，是不同的产物。接收任务先读取这些产物，遇到尚未接受的结论，继续按原正式记录处理。若资料已经失效，保留旧结论的适用范围与历史，由负责人补充新依据，而不是让下一位 Agent 自行猜测。
从一条已有事实完成首轮验证
- 01
选择一条已经维护、有明确来源的政策或事实，先指定负责人，再要求 Agent 修改。
- 02
读取当前记录，让 Agent 返回来源、适用范围与版本。确认它引用的是目标资料，再允许写入。
- 03
提出有边界的更新，展示旧值、新值、原因与依据。需要人审时保持提案，等有权限的决定后再接受。
- 04
从新任务重新读取正式记录，核对数值和来源；被拒绝或未解决的修改不进入正式答案。
连接与权限边界
官方配置文档提供远程 HTTP MCP 与 OAuth 说明，认证及可用路径沿用当前连接指南。记住一条指令不会获得写入权限，Git 历史存在一笔变更也不代表团队已经接受业务事实。下一个任务使用时，要重读共享正式记录。
可调整的对话指令
查找能支持这条记忆结论的共享政策，个人笔记保持私有。若结论与正式政策不同，展示双方来源并提出修正，不静默覆盖政策，也不把记忆当成批准。
连接前的常见问题
GitStore 有变更历史，就代表团队批准了吗？
历史说明发生过变更。团队接受还需要关联到具体事实与依据的授权决定。保留两类轨迹，不把它们当作同一事件。
会替代原生记忆吗？
原生上下文继续服务执行，个人偏好保持私有。只共享确实需要别人读取、核对或维护的知识。
怎样验证一次有用的循环？
读取一条已有记录，返回链接与来源；提出一项证据支持的修正，查看变更，再重读被接受的记录。有提案链接不代表正式记录已经变化。