先看证据
手机上的一个小需求，暴露了代理工作的边界
Simon Willison 于 2026 年 10 月 12 日发布 web-edit 0.1a0。这是一个用 Python 编写的网页文件浏览与编辑应用，起因是他用手机通过 Codex Remote 操作项目时，想修改凭据文件，却不希望文件内容再经过 LLM。作者让 Codex 和 GPT-6 Astra Extra High 帮忙构建这个工具，设想由代理启动应用，再由自己从手机浏览器访问并编辑文件。
这个需求看起来只是少传一份文本，背后却是代理工作流里常被混为一谈的两件事：让模型协助完成工作，不等于让模型必须接触工作涉及的所有数据。web-edit 选择把“代理帮忙准备工具”和“人处理秘密内容”拆开。需要注意的是，发布材料表达的是预期用法，并不能证明某次完整的凭据编辑流程已经经过安全验证。
文件仍然要被读取，只是换了处理者
web-edit 启动后，浏览器界面围绕一个指定文件夹提供文件浏览、读取和保存能力。用户可以创建和编辑 UTF-8 文本文件，保存时由应用把内容写回文件，材料还提到保存前会检查文件是否被外部修改。按这个机制，凭据可以由用户在浏览器中处理，而不必进入模型上下文。
这不是一套让文件操作凭空消失的设计，而是把执行操作的主体从模型换成了应用和用户。web-edit 进程仍然能够访问它所服务的目录，能够连接到网页服务的人也就获得了一个文件操作入口。因而，模型没有看到凭据，并不自动意味着凭据不再暴露，风险仍取决于进程权限、目录范围和服务的可达性。
移动端不是外观细节，而是这条路径能否成立
这个工具的关键场景从一开始就在手机上，因此编辑器选择会直接影响工作流是否可用。Willison 采用 CodeMirror 6，而不是 Monaco，理由是他认为 Monaco 当时的移动端体验还不够理想。这里的取舍不是给桌面工具加一个窄屏布局，而是让用户能在代理远程工作时，确实用手机完成那一步人工编辑。
web-edit 也不只提供文本编辑：它支持多文件上传，并带有进度显示和失败重试，还能预览小于 2 MB 的图片。这些功能让它更像一个轻量文件工作台，而不是专为凭据设计的单一输入框。不过，这些能力描述的是工具覆盖的操作范围，不等于它已经适合团队级文件管理。0.1a0 是初始 alpha 预览版，材料没有提供足够依据来判断它的稳定性或长期维护能力。
默认只听本机，远程访问要另作决定
部署参数让“从手机访问”这句话有了具体边界。web-edit 默认监听 `127.0.0.1`，默认端口是 `9000`，命令行提供配置监听地址、端口和允许主机名的选项。作者设想让应用通过 Tailscale 从手机访问，但这不等于应用默认已经对网络开放，也不意味着 Tailscale 自动替应用提供了身份验证。
0.1a0 没有内置身份验证，而应用能够读写启动时指定的目录。若要让另一台设备访问，负责人需要明确服务实际监听在哪个地址、哪些设备可以连接，以及应用被授予了多大的文件范围。材料没有给出一套完整的安全部署配置，也没有说明访问控制应如何设置。因此，“走 Tailscale”应被理解为作者设想的网络路径，而不是已经由应用保证的安全属性。
把便利留给代理，把权限收回到部署者手里
web-edit 展示了一种实用的人机分工：代理可以生成或启动工具，用户再通过工具完成不希望模型参与的操作。它的价值不在于赋予代理更多处理秘密的能力，而在于提供一条不必把敏感文本送进模型的路径。对个人远程工作而言，这种拆分可能减少不必要的数据暴露，也让人能继续利用代理协助项目中的其他工作。
这项收益成立的前提，是部署者把它当作一个拥有文件能力的服务，而不是一个天然安全的编辑器。较稳妥的判断是只让它访问完成任务所需的目录，并在开放远程访问前确认网络侧的访问范围。若用途涉及团队凭据管理，0.1a0 的 alpha 状态和无身份验证都是直接的限制。它解决的是“凭据是否必须进入模型上下文”，没有替部署者解决“谁能访问文件、应用能触及哪里”。