一个能够填写网页表单上所有文本字段的 Claude AI agent，在尝试上传三张图片时，在最后一步戛然而止，这暴露了 Desktop App 在文件上传处理方面一个未公开的限制。这一失败至关重要，因为它将一个看似完整的端到端自动化流程变成了一个需要人工接手的过程，迫使开发者重新思考如何构建 AI 驱动的工作流。
为什么现在会出现这个问题
Claude agents 在三种环境中运行：命令行界面 (CLI)、Visual Studio Code 扩展或独立的 Desktop App。在 CLI 中，agent 可以从添加到会话的目录中读取文件并顺利上传。Desktop App 则不具备这种行为。即使 agent 将文件写入其自身的临时文件夹，应用也会拒绝上传，理由是引用了一个从未在公开文档中出现的“共享”文件的内部定义。
当一名用户构建了一个自动化流程——填写表单、点击“保存草稿”并尝试上传三张图片时，这种差异便显现了出来。文本字段填充得完美无缺，但上传步骤每次都会返回错误。
开发者们尝试过的方法
- 将文件添加到应用创建的会话文件夹中。
- 使用让 agent 可以查看宿主文件夹的 directory-connect 工具。
- 直接在聊天窗口中上传图片。
- 创建一个手动上传文件夹，并将表单指向该文件夹。
所有这些方法都产生了相同的拒绝错误。用于显示文件选择对话框的浏览器窗口在桌面自动化模式下以只读模式运行。agent 虽然能看到对话框，但无法在其中点击或输入路径，因此 UI 自动化技巧均告失败。
一个脆弱的“后门”
唯一成功的方法是利用 Windows 剪贴板：
- 使用 PowerShell 脚本将目标文件复制到剪贴板。
- agent 发送 Ctrl + V 按键指令。
- 浏览器接收到粘贴事件并上传文件。
这种 hack 手段虽然有效，但它会清空用户的剪贴板，仅限于 Windows 系统，并且可能会随着 Desktop App 的任何更新而失效。对于生产流水线来说，这并不是一个可持续的解决方案。
这一限制的真实含义
核心问题并非软件漏洞，而是一个未公开的层面：它将文件权限视为宿主应用程序的属性，而非简单的文件系统标志。在 CLI 中，agent 继承了进程的读取权限，因此会话中可见的任何文件都可以上传。而在 Desktop App 中，运行时环境隔离了 agent 的文件系统视图，仅允许符合隐藏“共享”标准的文件通过。
由于该限制已植入 Desktop App 的架构中，因此依赖 UI 操作或临时文件夹的变通方法均未奏效。
可靠的解决方案
如果工作流需要上传文件，开发者有三个可靠的选择：
- 从 CLI 运行 agent。 该环境遵循会话的文件系统权限，无需额外步骤即可上传。
- 使用 VS Code 扩展。 该扩展镜像了 CLI 的权限模型，允许 agent 读取并上传编辑器可见的文件。
- 将上传步骤交给人工。 快速的两分钟手动操作，胜过花费数小时去设计一个脆弱的变通方案。
选择前两种方案意味着在 Desktop App 之外运行自动化流程。
总结
Claude AI agent 的文件上传能力在不同运行时并不通用；它取决于 agent 的启动方式。为了实现可靠的自动化，请将 CLI 和 VS Code 扩展视为唯一能可靠遵循文件系统权限的环境。使用 Desktop App 时，请预留人工接手的环节，或接受脆弱的剪贴板 hack 手段。忽视这一区别可能会让一个流畅的端到端脚本变成一场代价高昂的调试工作。