ChatGPT Work 这类工作代理最近被讨论最多的一个能力就是可以代替用户登录网站办杂务而且不需要把密码交给 AI。很多人听到这句话会先怀疑不给密码AI 怎么登录这恰恰是整个方案最关键的切入点。它要解决的并不是“AI 能不能记住你的密码”而是“在 AI 拥有网页操作能力的同时如何让密码始终留在你自己的控制范围内”。这个方向最值得关注的不是“能不能登录”而是登录之后的权限边界。日常杂务往往涉及表单、下载、更新状态、跨系统同步每一步都可能改变真实业务数据。如果实现方式只是简单地把账号密码塞给代理那代理越强大风险反而越大。下面我按实际落地的顺序把“代登录网站办杂务且不泄露密码”这个问题拆开讲。会覆盖常用机制、环境准备、单任务验证、批量处理、日志审计以及常见坑点。1. 先搞清楚“代登录”到底解决了什么问题1.1 为什么不能直接把密码交给 AI密码是长期凭证。它不像一次性的验证链接也不像短期令牌只要泄露出去除非你手动改密码否则它一直有效。而 AI 代理在处理任务时密码可能会出现在三种地方任务描述里、系统日志里、模型上下文中。如果代理是一个运行在本地的开源脚本密码可能留在环境变量或配置文件中。如果代理是一个云端服务密码可能会被传输到远端。最危险的情况是代理在推理过程中把密码当普通文本处理随后写入日志或调试信息。这类泄露不一定是恶意行为更多时候是工程疏忽。很多自动化方案会把“登录”和“操作”混在一起。代理需要登录就让它自己填密码看起来方便但账号的完整权限等于全部交给了这个代理。代理只是一个软件它没有人类的判断力。一旦页面出现误导性按钮或任务描述有歧义它可能执行你完全没打算做的操作。所以“代登录但不泄露密码”不是套路而是安全底线。ChatGPT Work 这个方向真正要做的是把账号操作能力拆分出来只给代理完成特定杂务所需的最小权限。1.2 和开发任务相比网站杂务的风险更高ChatGPT Work 和 Codex 这类开发向代理放在一起看时很多人会低估网站杂务的复杂度。Codex 操作代码仓库时有 Git 版本控制、diff 审查、测试用例保护改错了可以回滚。但网站杂务不一样它操作的是外部系统。比如你在一个后台管理系统里把订单状态改成“已发货”这个动作没有 diff也没有测试环境。执行错了只能靠对方系统是否提供逆向操作来决定能不能恢复。再比如批量下载报表代理需要处理登录态、分页、筛选条件、文件命名、超时重试。看起来是重复劳动但每一步都可能因为页面结构变化、Cookie 过期、权限不足而失败。所以网站杂务的“代登录”方案核心要回答三个问题代理如何获得登录态而不是获得密码代理能操作哪些页面和功能如何限制代理执行完任务后有没有日志和结果可审计这三个问题比“AI 能不能打开网页”重要得多。1.3 适合交给 AI 的杂务和不适合的任务适合的任务通常满足这些条件动作明确、结果可验证、失败影响小、重复度高。常见的有登录后台下载每日报表把外部系统数据同步到表格定时检查某个页面状态并生成提醒在工单系统里更新状态批量填写格式统一的表单从固定几个页面收集公开信息或本系统内数据不适合一上来就自动化的任务包括支付、转账、删除数据、修改权限、公开发布内容、批量修改核心资料。这些不是不能做而是必须加人工确认节点并且谨慎设计权限。2. 不泄露密码的登录机制会话、授权和本地注入2.1 思路一本地浏览器会话与用户手动登录最常见的做法是让用户先在真实浏览器里登录一次然后把登录后的会话状态保存到隔离环境中。代理启动后加载这个会话直接操作“已经登录的页面”整个过程不读取密码。这种方式最直观的好处是密码根本不会进入代理的任务流。你打开浏览器在密码管理器里填充账号密码登录完成代理接手后续操作。代理看到的是已登录的页面它不需要也不应该知道密码字段里填的是什么。这个方案适合个人使用尤其是内部系统、后台管理、数据导出这类场景。要注意的是会话状态会被保存成一个文件或 Cookie 集合这个文件本身也需要保护。不能放在会被网络同步的公共目录里也不能被其他任务误读。我一般会把浏览器自动化环境单独放到一个隔离目录里和平时用的浏览器配置文件分开。这样代理跑的登录态、缓存、Cookie 不会和日常上网混在一起也不会因为浏览器日常使用导致 Cookie 被重置。2.2 思路二OAuth 授权和短期令牌如果目标网站支持开放接口比如 OAuth 2.0那么更稳妥的方式是用“授权码 短期访问令牌”代替密码。代理不需要知道你的账号密码只需要拿到一个临时令牌。这个令牌可以限制作用域比如只能读取数据、只能导出报表不能修改配置也可以设置有效期到期自动失效还可以随时撤销。这个机制比直接给密码安全得多原因很简单令牌是“有限权限 短生命周期”密码是“完整权限 长期有效”。哪怕令牌泄露影响窗口也有限。当然OAuth 方案需要网站配合不是所有网站都提供 API。很多传统后台系统根本没有开放接口只能走浏览器会话这条路。2.3 思路三服务端隔离与任务接口当任务不是个人使用而是团队或生产环境里的定时任务时不能靠每个人本地保存会话。比较合理的做法是由一个后端服务统一管理登录态和令牌代理只通过任务接口获取执行任务所需的临时凭证。比如服务端可以保存一份加密的会话数据代理需要执行任务时由服务端创建一个短期授权限定只能访问某个页面和某个接口。代理不需要看到明文密码也不一定需要看到完整 Cookie。任务完成或超时后这次授权立即失效。这种架构还方便做审计。谁执行了什么任务、什么时候执行、结果如何都记录在服务端。出问题时可以回溯而不是靠猜。2.4 几种方案的对比方案密码是否交给 AI安全性实现成本适用场景本地浏览器会话否较高低个人自动化、内部系统OAuth / API 令牌否高中支持开放接口的系统服务端统一管理否较高较高团队任务、定时任务、生产环境直接把密码给代理是低低任何场景都不推荐选哪种取决于目标网站能力、任务复杂度、运行环境和你愿意付出的维护成本。但底线是一致的不要让 AI 拿到明文密码。3. 实操前需要准备的环境和条件3.1 环境准备隔离、浏览器、会话目录开始之前先把环境规划清楚。我建议至少准备以下几项独立的工作目录用来存放代理配置、会话文件、输出文件和日志。一个专门用于自动化的浏览器建议使用 Chromium 内核浏览器方便控制。密码管理器用来在用户手动登录时填表密码不进入代理任务。日志级别设置为可调试但要注意脱敏。如果任务需要访问内网系统先确认你是否有对应网络权限以及目标系统是否允许自动化操作。不要在生产环境、公共电脑或共享账号下做这类实验。一旦操作出错影响范围会扩大。3.2 权限设计最小权限才是真正的安全很多人以为“不泄露密码”就够了实际上还要控制“登录之后能做什么”。比较稳妥的做法是如果目标系统支持多角色账号不要用管理员账号跑日常杂务。单独建一个受限账号只给这个账号分配任务所需的权限。比如导出报表的账号不能有删除权限更新状态的任务账号不能有用户管理权限。会话有效期也要控制。有些系统支持设置 Cookie 过期时间尽量设置成短一点。任务跑完手动清理会话不要长期挂在生产系统上。还可以从代理侧做限制只允许访问固定域名、固定路径任务定义里禁止打开其他 URL。代理如果出现误操作至少网络边界能兜住。3.3 选一个最小任务做验证第一次跑不要选复杂任务。选一个“登录后台下载一份今天的数据报表”或者“登录内部系统把某个工单状态更新为处理中”这种低风险、结果明确的任务。最小任务的好处是容易判断成功失败。出错时你能很快定位是登录问题、页面解析问题、权限问题还是输出路径问题。如果第一次就上复杂的多步骤任务失败时根本不知道从哪查起。4. 单任务跑通从授权到杂务完成4.1 推荐的授权流程按照以下顺序来基本不会乱在自动化浏览器里手动访问目标网站。用密码管理器或手动方式完成登录。确认登录成功后保存当前会话状态。确保保存过程中没有记录明文密码。启动代理加载会话状态。让代理打开目标页面确认它能识别当前登录状态。执行目标任务检查结果。为什么让用户手动登录这一步因为登录动作留在了用户端密码没有经过代理的提示词和日志。代理加载的是“已经登录的浏览器状态”而不是“登录动作”。如果在第一步就发现目标网站不支持保存会话或每次访问都要求二次验证那就要把人工确认节点设计进流程里。比如代理遇到验证码时暂停等你手动处理后再继续。4.2 任务定义要包含哪些字段任务不能只写一句“帮我导出报表”。要让代理明确知道目标、边界和成功条件。下面这个 JSON 只是示例具体字段以你使用的工具为准{ task_id: report-20250416, site: https://example.com/admin, goal: 进入报表页面导出今日订单数据保存到 output/reports, success_condition: output/reports 下生成文件页面出现导出成功提示, timeout_seconds: 120, retry: 1, must_not: [ 删除任何数据, 修改订单状态, 打开非 admin 域名 ] }success_condition很重要。代理不是执行完就结束它需要检查是否真的拿到了结果。没有成功条件代理可能以为任务完成了实际输出是空的。must_not是给代理划红线。虽然不能完全依赖但至少让它在任务开始时知道哪些动作绝对不能做。4.3 验证成功与否单任务跑完后不要只看日志里的“完成”。我一般会检查这几项目标动作是否完成文件是否生成状态是否改变。是否有额外动作代理有没有打开其他页面有没有做了任务定义之外的操作。输出是否可读文件格式、编码、目录是否符合预期。日志是否干净日志里有没有记录到密码、完整 Cookie 或临时令牌。会不会重复执行如果再次运行同样的任务会不会产生重复数据。如果这些都通过再考虑把任务放到更长时间的回归测试里。5. 批量杂务怎么处理队列、失败重试和审计日志5.1 不要一上来就开批量跑通单条任务后最容易犯的错误就是直接上大批量。一次性把 100 个任务丢给代理结果并发太高、目标网站风控、文件同名覆盖、账号被锁到处都是问题。建议先跑一个 3 到 5 条任务的小样本。观察三件事每条任务平均耗时多少。失败率有多高。系统资源占用是否正常。稳定了再逐步增加到几十条。批量任务不是把单任务复制一百遍它需要考虑排队、并发上限、失败重试、输出命名、结果汇总。5.2 失败重试和幂等性批量任务里重试不能盲目。首先看失败原因是网络超时、登录态过期、页面结构变化还是业务规则不允许。每种原因的处理方式不一样。网络超时可以重试但如果任务在服务端已经执行成功只是响应超时重试就会产生重复数据。比如“提交一个申请”和“发送一封邮件”重试可能导致重复提交。所以在设计任务时要判断它是否幂等。幂等任务可以放心重试比如“把状态设置为已完成”重复执行结果一样。非幂等任务必须加去重逻辑。可以用任务 ID 查询目标系统里的状态确认没有提交过再执行。输出文件的命名也要考虑。如果每条任务生成一个文件按任务 ID 或时间戳命名避免覆盖。如果必须使用固定文件名要单独处理。5.3 审计日志不能省批量任务离不开审计日志。日志至少要记录任务 ID、开始时间、结束时间、执行结果、失败原因、耗时、操作页面和输出文件。但日志绝不能记录敏感信息。密码、完整 Cookie、访问令牌、请求头里的 Authorization 字段都不能写进日志。如果一定要记录必须脱敏。有条件的可以在任务执行前后各自保存一次页面快照。这样出问题时可以对比操作前后状态知道代理到底碰到了什么、改了哪里。这个比事后猜有用得多。审计日志平时看没什么用但一旦出现“某个数据被改了”“某个任务没有执行”“某个文件被覆盖”它就是第一排查入口。6. 常见报错和排查顺序6.1 登录失败或登录态过期出现登录失败先不要怀疑是密码错了。按这个顺序排查会话或 Cookie 是否已经过期。页面是否出现了验证码、二次验证或设备确认。目标系统是否检测到异常环境并强制退出。账号是否被锁定或停用。最后才看密码和账号信息。很多登录失败其实是会话失效而不是密码错误。如果你用的是本地浏览器会话方案重新手动登录一次再保存会话通常能解决。这里特别提醒不要为了“让代理顺利通过”去关闭目标网站的验证码或多因素认证也不要想办法绕过。这些机制是保护账号的绕过去等于给自己挖坑。正确做法是让代理遇到验证码时暂停由用户完成验证后继续。6.2 页面元素变化导致任务失败网站一旦改版或者某个按钮的 ID 变了代理可能找不到目标元素。这类问题在批量任务里非常常见。排查时先看代理卡在哪一步。如果是找不到某个按钮或输入框优先更新选择器。如果页面上有 iframe需要先切换进去。如果页面是异步加载需要加等待条件而不是盲目调大超时。还有一个容易忽略的点有些系统对不同用户展示不同页面版本也就是 A/B 测试。同一个后台管理员和普通用户看到的按钮位置可能不一样。如果代理用了一个账号的页面样式去操作另一个账号的页面也会失败。6.3 任务卡住或速度过慢任务卡住时先看是“一直没反应”还是“正在执行但很慢”。可以用日志判断当前步骤。常见原因包括页面弹窗挡住了操作。上传或下载文件导致浏览器等待。内存或 CPU 占用过高。目标网站服务响应慢。输出目录不可写或磁盘已满。不要一卡住就调大超时。超时只是让任务多等一段时间真正的问题可能没解决。先定位卡在哪个步骤再决定怎么处理。6.4 输出结果异常如果代理执行完但没有生成预期输出先确认输入数据是不是有问题。页面没有数据、筛选条件错误、日期范围不对都会导致空结果。再看权限。代理登录的账号可能没有导出权限或者只能看到部分字段。最后检查参数。输出路径、文件命名、导出格式、时间戳字段任何一项配置错都会让结果看起来“执行成功但输出无效”。7. 边界和避坑哪些杂务不适合代登录7.1 高风险操作必须有人工确认有一些操作再方便也不要直接让代理自动执行包括支付、转账、删除记录、修改用户权限、公开发布内容、批量覆盖数据。不是说这些永远不能自动化而是必须设置人工确认节点。比如代理先把所有操作准备好生成一个待确认列表用户检查后点确认代理再继续。这样既保留了效率又给了兜底。如果代理工具不支持人工确认节点那就不要让代理碰这类任务。宁可多花几分钟手动做也不要拿真实业务数据冒险。7.2 网站服务条款和账号风险很多网站的服务条款禁止自动化脚本或自动登录。即使你拥有账号使用自动化工具也可能触发风控、封号、限制功能。所以落地前要先确认两件事目标系统是否允许自动化你有没有授权去操作这些数据如果是公司内部系统要和管理员确认是否有自动化接口或合规流程。如果只是个人账号也要看网站条款是否允许使用第三方工具。这类风险很隐蔽。很多代理刚开始跑得很正常跑几天后账号被锁才发现是自动化行为被系统识别了。别等出问题再处理提前问清楚。7.3 不要试图绕过验证码和安全机制验证码、多因素认证、设备绑定都是账号保护机制。代理如果遇到这些合规的做法是暂停并请求用户介入而不是想办法绕过。很多代理工具会建议关闭验证码、延长会话有效期、添加“万能密码”之类的旁路逻辑这类做法既不安全也不稳定。它只是让测试看起来更顺利实际把账号暴露在更高风险里。安全的流程可以设计成代理尝试执行任务。遇到验证码或二次验证自动暂停。通知用户手动验证。用户完成后代理继续执行。这样的体验虽然没有“全自动”那么顺滑但不会破坏安全边界。7.4 不是所有网站都支持会话复用有些网站把 Cookie 设置为 HttpOnly有些设置了 Secure 标志有些还会检测 UA 或 IP 变化。你保存了会话换一个浏览器上下文或换台机器可能立刻失效。还有一类网站每次登录后都会刷新令牌旧会话被主动踢掉。这种情况下任何“保存会话”方案都不稳定只能走短时人工登录或者官方 API。所以在选任务前先花时间测试目标网站的会话稳定性。不要等到批量任务跑到一半才发现所有会话都过期那就很被动了。ChatGPT Work 这类工作代理能不能安全落地关键不在 AI 本身而在你为它设计的凭证边界。把密码留在用户手里把临时会话和最小权限交给代理再把每一步操作写进审计日志这套思路比任何单一工具都重要。先单任务、再批量先低风险、再碰敏感操作很多问题其实不会出现。真正值得长期盯住的是登录之后代理会不会多走一步、多改一处以及出了问题能不能第一时间从日志里定位。