自动化的权限边界与最后一公里

第二部 · Agent 实践 · 第16章

撰写日期：2026-07-05

结论

Agent 自动化最常见的断点不是模型能力，而是平台权限模型。

模型能不能做到，一直在变好；权限模型允不允许，不会自己变好。评估自动化方案时，两者应该同等优先级。

这篇手记来自一次真实失败：一条"生成文档 → 归档到知识库指定位置"的自动化链路，内容生产全部成功，最后一步写入被平台拒绝。

案例：UI 权限和 API 权限是两套模型

链路的最后一步是把生成好的文档移入一个协作平台的知识库节点。实测过程：

步骤	结果	说明
读取目标节点	成功	节点级读取一直可用
API 移入 / 创建子节点	拒绝（权限错误）	操作身份对节点"只读"
请用户在 UI 里授予该身份"可管理"	授权成功	协作者列表里可见
重试 API 写入	仍然拒绝	等待权限传播后依旧

原因：该平台的写入 API 检查的是"空间成员"身份，而 UI 里授予的是"节点协作者"权限——两套模型，后者不满足前者。这类身份不在同一租户/组织时，成员身份根本无法获得，API 之路是死的，再多重试也没用。

教训不是"这个平台不行"，而是：UI 上看到的权限，不等于 API 拥有的权限。自动化设计必须假设两者可能不一致。

三个设计原则

原则	做法	反例
写入探测前置	在生产内容之前（或并行）对目标位置做一次最小写入探测，失败早暴露	花大量 token 生成完美内容，最后一步才发现写不进去
降级梯度	全自动 → 半自动（系统准备好一切，人只做一步）→ 纯手动（交付源文件 + 操作说明），每一级都是可接受的交付	把"全自动失败"等同于"任务失败"
失败不丢产物	中间产物本身就是交付物：换通道交付（链接分享、源文件、副本）	因为归档失败，让已生成的内容困在中间状态

这次实践里三条原则的实际效果：内容已生成为平台文档（中间产物保住）；打开链接分享 + 发送源文件（换通道交付）；给用户一份"保存副本 → 拖入目标位置"的一分钟操作说明（半自动降级）。用户视角里任务完成了，只是最后一厘米由人完成。

权限结论要写回长期记忆

权限边界是"查一次、记终身"的事实：它由平台决定，不随重试改变，复撞的成本却是每次一整轮试错。

这次实测结束后，结论立即写回了长期记忆，格式大致是：

<平台/空间>：读取可用（哪些 API）；写入全部不可用（哪些 API、错误码）；
根因：写入检查成员身份，跨组织无法满足；
落地方案：<已验证的降级路径>。

下次任何 Agent 碰到同一目标位置，直接走已验证的降级路径，不再重复撞墙。这和 Team Memory 的逻辑一致（见 Team Memory 系统设计）：值得记的不是"发生过什么"，而是"下次遇到该怎么办"。

我的判断

评估自动化可行性时，我现在的检查顺序是：权限模型 → 数据可达 → 模型能力。恰好和大多数人的直觉相反。

"最后一公里需要人"不是自动化的失败，而是一种合法的产品形态——系统把一小时的工作压缩成一分钟的人工操作，价值已经兑现。追求 100% 全自动而让整条链路报废，才是真正的失败。