Busabase × ZeroClaw
ZeroClaw 知识库
跨会话、跨渠道使用同一份业务知识
Busabase 为 ZeroClaw 提供共享 Doc 与结构化 Base，让多个会话使用同一份业务知识。当前任务的临时上下文继续留在原处；共享政策与业务记录则按使用时的正式版本读取。
接入指南 →
一条政策如何同时服务不同渠道
把渠道对话、工具能力和业务知识分开维护。对话用于理解本次请求，工具配置决定能执行哪些动作，共享政策则解释可以依据什么回答。政策变更后，下一次任务读取同一条正式记录，减少把旧答案复制到另一渠道的机会。政策本身不必复制成每个渠道一份。
维护者在 Doc 中写清政策正文、适用对象和例外，再用 Base 记录政策名称、来源、负责人和有效状态。ZeroClaw 回答时返回具体记录链接；遇到新情况，把问题关联到原政策，而不是在当前聊天里悄悄扩充规则。下一位负责人能看到缺的是事实、政策还是执行权限。
知识放在哪里，由谁维护
政策 Doc
保存完整规则、适用对象、例外与依据，由政策负责人维护解释。
知识 Base
每个持续维护的事实一条记录：稳定键、值、来源 URL、负责人、适用范围与状态，关联对应政策 Doc。
更新 Skill
保存读取、取证与提案方法，指导 Agent 怎样处理资料，不授予数据访问权。
结果记录
把任务关联到产物链接、决定与未决核查，下一次运行读取真实结果，不从任务结束推测事实已通过。
连接成功后，先验证实际可用的工具
先核对 Agent 别名是否声明了所需 mcp_bundles，再重启会话。服务器存在于配置里，不表示当前别名已经获得它；别名获得服务器，也不表示所有工具都可以跳过执行审批。用只读身份核验确认账号和空间，再读取一份已知 Doc，最后才尝试一项有明确范围的变更。
资料缺失时，把问题交回政策负责人
两个渠道的回答不一致时，先比较它们引用的政策版本、适用对象和来源。旧回答可以作为排查线索，但新的正式版本才是下一次读取的入口。来源冲突未解决时，保留冲突说明与下一项核查；不要给整条记录笼统盖上“已确认”。
交接时留下可核对的结果
读取结果要能定位到具体记录，说明用了哪个来源、适用什么范围，不能只交一段没有出处的答案。提出修改时，返回 ChangeRequest 链接及涉及字段，让负责人能够直接看旧值、新值和修改理由。变更获得接受后，再返回正式记录并核对结果；有提案、有审核决定、正式值已更新，是不同的产物。接收任务先读取这些产物，遇到尚未接受的结论，继续按原正式记录处理。若资料已经失效，保留旧结论的适用范围与历史，由负责人补充新依据，而不是让下一位 Agent 自行猜测。
从一条已有事实完成首轮验证
- 01
选择一条已经维护、有明确来源的政策或事实，先指定负责人，再要求 Agent 修改。
- 02
读取当前记录，让 Agent 返回来源、适用范围与版本。确认它引用的是目标资料，再允许写入。
- 03
提出有边界的更新，展示旧值、新值、原因与依据。需要人审时保持提案，等有权限的决定后再接受。
- 04
从新任务重新读取正式记录，核对数值和来源；被拒绝或未解决的修改不进入正式答案。
连接与权限边界
ZeroClaw 的 MCP bundle 与逐工具能力配置决定工具是否可用。按官方 MCP 指南配置和重启，再核对实际加载的工具。服务器连接成功、获准调用工具、业务变更获得接受，是三个独立检查；密钥保存在受支持的凭据配置中。
可调整的对话指令
在另一个渠道回复前，先读取当前服务政策，返回来源与适用范围。需要修改时，提出具体段落和原因；变更被接受前继续使用原正式记录。
连接前的常见问题
为什么服务器已配置，Agent 仍看不到？
核对当前别名的 bundle 授权并重启会话，再检查可用工具。端点配置与逐别名授权分开确认。
会替代原生记忆吗？
原生上下文继续服务执行，个人偏好保持私有。只共享确实需要别人读取、核对或维护的知识。
怎样验证一次有用的循环？
读取一条已有记录，返回链接与来源；提出一项证据支持的修正，查看变更，再重读被接受的记录。有提案链接不代表正式记录已经变化。