Appearance
跨系统内容搬运的三个陷阱：保真、颗粒度权限、分类扩展
第二部 · Agent 实践 · 第24章
撰写日期：2026-07-08
结论
把 Agent 生成或经手的内容从一个系统搬到另一个系统，看起来是最没有技术含量的一步，但恰恰是这一步最容易在无声无息中丢东西——丢的不是任务成败，而是内容的保真度、权限判断的准确性，或者分类体系的一致性。
搬运类任务的验收标准不该是"目标位置能看到一条记录"，而应该是"内容、权限归属、分类三者都和预期一致"。这三者任何一个悄悄跑偏，都不会在当次任务里报错，会在下一次有人打开这份内容、下一次权限审计，或者下一次基于分类做自动化时才暴露。
1. 内容本身已经是"原生对象"时，不要先转成文本再搬
一个常见的搬运路径是：读取源内容 → 转换成通用格式（比如 Markdown）→ 用目标系统的导入接口重新生成。这条路径对纯文本内容没问题，但源内容如果本身包含图片、内嵌卡片、附件这类富媒体块，格式转换这一步的编解码器往往只为文本优化，遇到非文本块要么丢弃、要么降级成占位符——任务执行完看起来成功了（目标位置确实出现了一份新内容），实际已经丢了信息，而且丢失是静默的，不会报错。
| 搬运路径 | 适用场景 | 风险 |
|---|---|---|
| 导出为通用格式 → 目标系统导入 | 源内容是纯文本，或源本身就是外部文件（本地 md、外部草稿） | 富媒体块经过格式转换后被丢弃或降级，且不会报错 |
| 用平台原生的"复制 / 移动对象"接口 | 源内容本身已经是目标系统同类平台里的一个原生对象（哪怕在另一个空间/租户下） | 只能搬运"同类对象"，搬不了跨平台、跨内容类型的内容 |
判断走哪条路径，只需要问一句：源内容现在是不是已经是某个系统里的一个原生对象？ 是，就优先找这个系统"复制/移动对象"一类的原生接口，不经过格式转换；不是（比如是一段本地文本或聊天记录），格式转换导入才是唯一路径，这时候要在转换前确认内容里有没有非文本块，有的话提前告知用户这类块会丢失，而不是搬完才被动发现。
2. 颗粒度不匹配的权限：粗粒度访问推不出细粒度访问
这类搬运任务经常需要指定一个具体的目标位置（某个子分类、某个具体节点），而不是随便放在系统默认的根位置。实测中发现：对整个目标空间/知识库有访问和写入能力，不代表对空间里某一个具体的子节点也有编辑权限——这是两层独立的权限判断，前者满足推不出后者也满足。指定精确目标位置时被拒绝，报错内容通常只提示"目标位置无权限"，容易被误读成"这次操作整体不可行"。
这和 自动化的权限边界与最后一公里 里"UI 权限 ≠ API 权限"是同一类问题的不同表现，但结局不同：那次是跨租户身份模型永久不满足，无论怎么重试都是死路，只能走降级交付；这次是同租户内的颗粒度差异，本质是"当前身份还没被授予那一小块权限"，一旦补齐就能立刻成功，值得设计一个可以恢复的分级方案，而不是直接判定任务失败：
| 层级 | 做法 | 什么时候用 |
|---|---|---|
| 第一层：精确到位 | 直接指定目标子节点搬运 | 默认先试，多数时候这一层就成功 |
| 第二层：安全默认位置保底 | 目标子节点权限不足时，退到空间的默认/顶层位置完成搬运，保证内容先落地、不悬空 | 第一层被拒绝、且不确定权限什么时候能补齐 |
| 第三层：权限补齐后二次归位 | 找到有权限的人补一次授权，或当前身份申请到位后，对已经落地的内容再执行一次"移动到目标位置" | 内容已经安全落地之后，不阻塞在这一步等待 |
遇到目标位置权限报错，先确认这是"这一个具体位置权限不够"还是"整个操作类型都不被允许"，两者的处理路径完全不同——前者可以分级降级，后者要参考"权限边界"那篇手记，直接走人工降级交付。
3. 分类体系缺一类时，不要往最近的桶里硬塞
搬运到有固定分类体系的目标系统时，新内容的主题经常不完全落在现有分类里——分类体系里只有相邻但不同的类型，没有专门覆盖这次内容主题的那一类。这时候最省事的做法是套用"最接近"的现有分类，但这个省事的选择会污染分类数据本身：往后任何基于分类做的自动化（按分类路由、按分类生成报表、按分类分配责任人）都会把这份内容算错地方，而且这个错误不会自己暴露，只会在专门核对某个分类下所有内容时才被发现。
| 遇到的情况 | 图省事的做法 | 更该做的做法 |
|---|---|---|
| 内容主题接近但不等于任何一个现有分类 | 挑最接近的现有分类硬套 | 提出"这里应该新增一个分类"，跟决策者确认后再扩展分类体系 |
| 分类体系是团队共用的规范，不是自己能单方面定的 | 自己悄悄按新理解归类 | 分类体系一旦扩展，要同步更新到所有使用这份规范的地方（包括驱动 Agent 归类判断的规则本身） |
分类体系本身是一种共享的长期记忆，扩展它的成本应该只落在"确认要不要新增一类"这一步，而不是每次都用某个内容去将就它。 这条经验和 Team Memory 系统设计 里"记忆生命周期"的逻辑相通：分类规则也需要随着新内容类型出现而演进，而不是一成不变。
我的判断
三个陷阱表面上互不相关（保真、权限、分类），但根子是一件事：搬运类任务的执行层看起来是确定性的"调接口"，实际上每一步都藏着一个需要判断的决策点——要不要转换格式、报错代表权限不够还是操作不可行、要不要扩展分类。把这些判断点显式列出来、给每个判断点设计好默认动作和人机交接方式，搬运任务才能在"看起来跑通"和"真的没搬丢东西"之间画等号。