组织单元：文件夹 vs 合作伙伴

网盘的世界里，一次对外协作通常表现为"给某个外部邮箱开一个共享文件夹"。这在偶发场景下是最快的做法。

问题出现在关系变长之后。同一家供应商可能对应三个联系人、两个项目目录、一套加密要求、一份历史交付记录——这些东西在网盘里是散的，靠人记住它们属于同一家。

产品把合作伙伴作为一等的管理对象：

合作伙伴（外部企业 / 供应商 / 客户 / 机构）
├── 基本信息      名称、简码、编码、类别、等级
├── 伙伴联系人    外部账号，可精准授权与审计
├── 伙伴管理员    分层分级的管理权限
├── 密钥资料      公钥绑定与配置
├── 收发策略      内外部用户的收发关系与权限
├── 伙伴库        分配给该伙伴的交换目录
└── 交换记录      来自该伙伴 / 发给该伙伴的全部收发记录

这样组织的意义在生命周期上：伙伴从准入、签约、交换、变更到离场，每一个动作都有明确的操作对象。合作终止时"把这家的东西都停掉"是一个可执行的动作，而不是靠人回忆有哪些文件夹曾经共享给过他们。

→ 合作伙伴档案与收发策略

凭据方向：给出去 vs 收进来

这一条最容易被忽略，也是两类产品职责范围的真正分界。

网盘处理的是本方发出的访问权——给外部人一个链接或一个账号。企业间交换里同样有这类动作，但还有一类反方向的：外部企业发给本方一套凭据。

在供应链中游企业尤其明显：客户方规定用他们的 FTP、他们的对象存储、他们的目录规则，账号与密钥由客户发放，本方只能被动适配。这些凭据的现状通常是：

• 散在若干业务人员手中；
• 谁手上有几份说不清；
• 人员变动后是否失效无人确认。

平台把这类外部凭据统一保管与使用——伙伴的 FTP/SFTP 账号、对象存储访问密钥、加密密钥统一由平台托管。业务人员在平台内提交交换任务并查看结果，全程不需要、也无法获取外部凭据。人员变动时无需逐个回收账号，凭据轮换在平台一处完成。

→ 外部账号与密钥集中托管 · 外部凭据托管的安全设计与评审配合

安全处理的顺序

出向与入向的处理顺序不同，而且不可互换：

• 出向：受控入库 → 内容识别 → 敏感内容检查 → 人工审批 → 加密封装。内容检查与审批必须在加密之前完成，因为加密之后不再具备明文内容检查能力。
• 入向：受控隔离 → 外层预检 → 解密验签 → 威胁检测。加密来件必须先解密再杀毒，因为密文阶段的检测能力有限。

两个方向都设放行闸：安全治理通过后方可投递或发布，未通过的文件停留在隔离区。

这个顺序是产品设计的一部分，固化在流程中，而不是交给配置人员判断。

→ 文件出入向安全治理

记录回答的问题不同

协作场景关心的是版本与修改。交换场景关心的是交付责任——被审计或发生纠纷时，要能完整回答"哪个文件、什么时候、谁发的、发给谁、对方取没取"。

产品记录访问会话、文件操作、文件传输、系统管理、身份管理、身份认证、安全检测七类日志，支持条件查询、详情查看与导出，保留时长与归档策略可配置。

还有一件事只有交换场景才在意：上传完成不等于对方已经收到并处理。业务人员常常还要打电话或发消息确认一句"收到了吗"。平台对文件包提取回传提取回执；采用协议直连的交换则由接收方回送成功或失败响应，本方对回执执行签名验签与哈希比对，全部通过后才标记为已送达。

→ 交换全程审计与日志追溯