Paperclip 本地运行还是部署到服务器？按团队使用场景选择

官方 Docker 快速启动示例使用主机端口 3100，并把实例数据映射到持久目录；这说明容器能启动，不等于数据已经纳入团队的备份和恢复流程。Docker 部署文档

症状：本机试用顺利，但同事无法安全访问，或者你还不确定升级、备份后能否恢复。 最快解法：个人开发先留在本地；需要跨设备协作，选带认证的私有部署；只有确需互联网访问时，才做带认证、HTTPS 和持久化存储的公网部署。

刚开始试用 Paperclip 的个人开发者，可以据此判断本地方式是否够用。 需要多人查看任务和运行记录的负责人，可以检查私有访问边界。 负责 Agent 平台运维的工程师，可以用下文的验收项核对公网与数据管理责任。

本地试用为什么不等于团队部署？

本地可信模式适合单人验证工具链：按官方部署说明，local_trusted 面向本机单人使用，不要求操作人员登录，主机通常只监听本地地址。Paperclip 部署模式说明

它的好处是启动路径简单，能让你先验证 Agent 是否能执行预期工作流；但它也有明确边界：

• 没有团队登录边界。 不要把无需登录的本地实例当作多人服务使用，更不能因服务器有可访问地址就把它暴露给不受信任的网络。
• 本机可用不等于远程可达。 默认监听本地地址时，其他设备不能因此自动访问；改变绑定地址会改变暴露范围，不会自动补上身份认证。
• 数据保存在本机，不代表已有备份。 本地数据库、上传内容、密钥和工作目录可能分散在不同位置；设备丢失、目录误删或迁移失败，都会让“曾经运行正常”失去意义。

场景上，如果你只想确认分配任务、执行 Agent 和查看记录的流程是否适合自己，先在本机验证更省运维成本。若目标已经变成多人持续使用，就应把认证、网络可达性和数据恢复作为新的验收项目，而不是直接共享试用环境。

Paperclip 本地开发文档把默认路径描述为本地可信模式、嵌入式 PostgreSQL 和本地磁盘存储；这适合单机起步，却不能替代团队的存储和恢复方案。本地开发与默认数据路径

三种团队场景分别要承担什么？

下面的区别不是“本机还是服务器”这么简单：决定协作边界的是认证与网络暴露方式；服务器只是运行位置。官方部署概览列出本地可信、认证后的私有访问和认证后的公网访问三种路径。Paperclip 部署总览

小团队的常见取舍是：私有访问比全公网少一层暴露范围，但不是“免运维”。你仍需确认哪些设备能到达服务、成员如何登录、实例管理员由谁持有，以及人员离开后是否撤销访问。官方模式说明也把私有网络访问与公网访问分开，不能把“能从外部打开页面”当成“已安全部署”。

注意：从本地可信模式迁移到认证部署时，官方文档描述了通过一次性认领链接转移实例所有权的流程。它是敏感凭据，只用于预期的所有权转移，不要作为普通团队邀请链接转发。部署模式迁移与认领说明

公网部署前，先验收这些边界

当团队确实需要互联网访问，部署责任就从“让服务启动”变成“让服务持续可控”。公网部署需要认证模式、明确的公开基础地址和更严格的配置检查；Paperclip 的 HTTPS 说明还区分了 HTTPS 与公网可达性：带 HTTPS 的地址仍然可以只对私有网络开放。Paperclip HTTPS 配置与访问边界

发布前依次核对：

• 访问对象： 写清哪些团队成员、设备和外部集成需要访问。没有业务理由的访问对象，不应仅为方便而加入。
• 身份验证： 确认人工访问要求登录，并明确首位实例管理员如何认领。首个管理员设置完成前，不要让不受信任的用户进入部署环境。
• 地址与主机名： 检查配置中的公开地址与实际访问地址一致，并确认允许的主机名覆盖你使用的入口。代理或 DNS 变更后，应重新验证登录和回调。
• 传输加密： 使用受信任的 HTTPS 证书；确认代理与 Paperclip 的连接方式，以及证书续期不会无人负责。只在浏览器中接受自签名证书，不足以证明外部服务能可靠验证 HTTPS。
• 凭据与密钥： 明确谁能读取 API 密钥、令牌和认证密钥，轮换后如何更新服务。官方密钥说明指出，本地加密密钥默认保存在实例相关目录；备份数据库却漏掉密钥，可能导致恢复后的机密数据无法按预期解密。Paperclip 密钥管理说明
• 公网入口： 只开放确有需要的入口，确认 Paperclip 服务端口没有绕过预期代理直接对外。配置完成后运行官方诊断，再以普通成员账号验证访问。

持久化不止是备份数据库

Paperclip 的嵌入式 PostgreSQL 会把数据放在本机实例目录；Docker 方式则依赖正确的卷或绑定目录。容器重建时若挂载配置不对，任务数据、附件或 Agent 工作区可能无法按预想保留。官方 Docker 文档明确列出持久化目录涉及嵌入式数据库、上传资源、本地密钥和 Agent 工作区。Docker 持久化内容说明

此外，附件和其他上传内容由存储配置管理。官方存储文档将本地磁盘作为本地单机方案，并将兼容对象存储列为多节点或云部署的选择；你应同时核对存储提供方配置与实例目录，不能只看数据库是否有备份。Paperclip 存储配置与上传内容

运维负责人可从以下清单开始，而不是假定有一个“完整备份”按钮：

• 列出数据库、附件目录、密钥文件、实例配置和 Agent 工作目录的实际路径。
• 确认容器重建或主机迁移后，这些路径仍映射到有持久性的存储位置。
• 明确备份文件的访问权限与保管位置；密钥和密钥材料也要纳入恢复设计。
• 在隔离环境尝试恢复，并检查任务记录、附件读取、密钥解密和工作目录是否可用。
• 记录恢复中缺失的文件、人工步骤和权限依赖，再修正方案后重做演练。

官方文档给出了数据位置和存储选项，但没有替你的团队承诺备份频率、恢复时长或可用性。你应根据团队的恢复目标自行制定规则，并用实际演练验证，而非把未经验证的时间指标写进服务承诺。Paperclip 数据库模式与本地数据位置

常见问题：把团队访问和数据责任说清

个人开发需要一开始就部署服务器吗？

不需要。若你只验证自己的工作流，本地可信模式更直接；但一旦需要同事登录、异地访问或长期运行，就应重新评估认证与网络边界。本地试用的成功只证明功能链路在当前环境可用，不证明团队共享、备份或恢复流程已经验收。

团队成员怎样远程访问实例？

如果访问者属于受控团队，优先考虑认证后的私有部署，并限制哪些设备或网络能够触达服务。逐一核对登录、允许的主机名和成员离职后的权限回收。若外部系统还要调用回调接口，需单独确认它是否必须公网可达，不要因此把整个管理界面一并公开。

公网开放前哪些检查不能省？

先完成认证、公开地址、HTTPS、主机名、密钥保管与数据持久化检查，再运行部署诊断并实际验证登录。页面能打开并不能证明账户边界、代理配置或备份正确；外部回调还需要单独验证实际可达性。需要公网访问时，应把这些检查当作上线条件，而不是上线后的优化项。

哪些内容要纳入 Paperclip 数据备份？

至少盘点数据库、上传内容、实例配置、加密密钥和 Agent 工作目录，并确认各自的保存位置与恢复依赖。Docker 环境还需确认卷或绑定挂载没有指向临时目录。最终是否完整，以隔离环境恢复后任务、附件、凭据和工作区均可用为准。

按访问方式选择：满足条件再迁移

• 若只有你一人使用，且只在本机验证工作流，就选本地运行；否则回退到经过认证的私有部署。
• 若同事需要跨设备协作，但访问者都属于受控团队，就选认证后的私有访问；若网络边界无法明确，先不要扩大访问范围。
• 若有明确的公网访问需求，且团队能持续负责 HTTPS、密钥、持久化和恢复演练，才选公网部署；缺一项就先回到私有方案。
• 若团队无法落实恢复演练，不论部署在本机还是服务器，都不要将其视为已完成的正式运维方案。

选择 AI Agent 团队部署方式时，还要把模型调用成本、Agent 权限治理和备份演练分开评估；换成服务器并不会自动解决这些问题。对需要持续运行、团队远程访问或稳定保存工作目录的团队，现有个人电脑常见的短板是无人值守运行受限、访问边界依赖本机配置、数据迁移和恢复责任容易落到个人身上。若你的工作流确实需要远程 Mac 环境，可以先查看 kvmboot 的远程 Mac 方案，并通过 kvmboot 帮助中心核对接入与支持范围；若任务需要长期稳定的物理设备或特定本地接口，则应先比较自购设备与其他运行方式，再决定是否租用。