OpenHuman 安全边界：安装脚本、OAuth 授权和本地记忆应该怎么检查
OpenHuman 的吸引力在于它能连接你的模型、记忆、文件、日历、邮箱和其他工具。但这也意味着，评估 OpenHuman 不能只看回答质量，还要看它获得了哪些权限、数据流向哪里、错误记忆如何修正，以及高影响动作有没有确认步骤。
图示：个人 AI 接入邮箱、日历、文件和外部动作前，应该先通过权限边界、审计记录和人工确认这几道门。
这是一份中文用户可以执行的检查清单。你可以把它放在第一次安装、第一次接入集成、第一次允许写入外部系统之前各跑一遍。
先确认安装来源，而不是复制陌生命令
OpenHuman 仍在快速迭代，安装包、脚本和版本说明都可能变化。更稳的做法是从 OpenHuman 页面、GitHub README 和 GitBook 文档交叉确认，不要直接复制社交媒体、目录站或第三方文章里的旧命令。
如果你使用终端安装脚本，至少先确认脚本来自 tinyhumansai/openhuman 仓库，并记录执行时间、系统版本和安装输出。公司设备或包含敏感资料的主力电脑，建议先在测试环境或低风险账号上试跑，不要一开始就接入全部真实数据。
把产品登录和 OAuth 授权分开看
登录 OpenHuman 只是第一步。邮箱、日历、知识库、代码仓库和协作工具通常会走各自的 OAuth 授权流程。你需要单独检查每个连接器申请了哪些权限，是否包含写入、删除、发送、邀请、创建日程等高影响能力。
第一次接入时，优先选择一个低风险数据源。先验证读取是否正常，再观察 Memory Tree 或 Vault 里是否出现可理解的摘要。不要同时连接多个账号，否则一旦结果异常，很难判断是哪个来源、哪个权限或哪个同步环节出了问题。
本地记忆可读，不代表可以忽略审阅
OpenHuman 的 Memory Tree 和 Obsidian / Markdown 记忆方式很适合审阅，但“可读”只有在你真的打开检查时才有意义。首次同步后，建议重点看三类内容：它是否正确识别了人物和项目，是否把过期信息写成当前事实，是否把敏感片段摘要得过细。
如果发现错误记忆，先修正或删除，再继续扩大接入范围。长期记忆系统最怕早期错误被不断复用；一次错误的项目背景、联系人偏好或会议结论，可能在后续任务里反复影响输出。
高影响动作必须保留人工确认
读取资料、生成摘要和写入本地草稿是一类风险；发送邮件、创建日程、修改知识库、提交代码或通知外部成员是另一类风险。后者应该保留人工确认，尤其是在你还没有完全理解权限边界和记忆质量之前。
一个安全的上线顺序是：先只读验证，再允许写入本地 Vault 或草稿，最后才考虑外部动作。每进入下一阶段，都应该有回滚方式，例如撤销授权、删除连接器、清理本地记忆或恢复 Vault 备份。
团队使用时要先定规则
如果 OpenHuman 会接触公司资料、客户信息、会议内容或项目代码，个人习惯就不够了。团队至少要约定哪些数据可以接入，哪些账号只能只读，哪些动作必须人工确认，记忆文件由谁审阅，以及离职、项目结束或客户要求删除数据时如何处理。
这类规则越早写清楚，后续越不容易把“试用工具”变成“无人负责的数据副本”。OpenHuman 的长期记忆能力越强，数据治理就越不能靠临时感觉。
最小安全清单
安装前，确认来源来自OpenHuman 官网、GitHub 或 OpenHuman 文档。接入前，只选一个低风险数据源，并确认 OAuth 权限范围。同步后，打开本地记忆或 Vault 检查摘要质量。允许写入前，先限定到本地草稿。允许外部动作前，保留确认步骤和撤销路径。
如果这五步都能稳定执行，OpenHuman 才更适合进入更真实的个人工作流。否则，先不要追求“全量连接”，先把权限、记忆和回滚跑通。
下一步阅读
本站已经整理了 隐私与安全、集成上线清单、快速开始 和 OpenHuman 安装后不要急着提问，先跑通第一轮记忆同步。建议先按这些页面建立最小闭环，再逐步扩大数据范围。
资料来源：本文基于 OpenHuman 页面、tinyhumansai/openhuman GitHub README、OpenHuman GitBook、独立指南与新闻报道做中文原创整理。涉及安装命令、权限行为和版本变化，请以当前仓库与实际客户端为准。