你有没有想过把自己日常工作中那些最机械的网页操作全部交给 AI 助手去做这句话放在两年前可能还只停留在“大模型帮你写回复邮件”的层面。但今天随着 ChatGPT、Kimi、Trae 等工具纷纷把“对话能力”升级为“执行能力”AI 已经可以代替我们打开浏览器、进入业务系统、查看待办、填写表单、提交审批。业界给这类能力起了很多名字Work、Agent、Copilot、Autopilot名称不同本质是一样的AI 从“给你答案”变成“替你办事”。一个绕不开的问题随即出现AI 要登录我的网站账号才能办事那我是不是得把密码告诉它这是我在和一些技术团队交流时听到最多的顾虑。很多人因为这一步的信任问题直接把 AI 自动化方案拒之门外也有一些人为了效果真的把密码写进提示词里制造了严重的安全隐患。这篇文章想做的就是把这个问题的正确解法拆开讲清楚AI 代理完全可以替你登录网站、办理杂务但你不需要把密码交给它。先说结论真正进入生产环境的 Agent 自动化方案依赖的不是模型多么聪明而是身份授权链路设计得足够稳。你给 AI 的应该是“钥匙”而不是“密码”钥匙可以随时收回密码一旦泄露就很难作废。下面我会用通俗的概念解释、可运行的代码示例和一套完整的安全清单把这件事讲透。1. 这篇文章真正要解决的问题先聊一下为什么这个题目值得专门写一篇文章。如果你只是让 AI 帮你生成一段文字那不存在安全问题。你复制粘贴结果AI 接触不到任何账号资源。但 AI 代理办公的场景完全不同它需要在目标网站里执行真实操作比如打开企业 OA、查询待办、拉取报表、填写周报、提交工单。这时候 AI 必须“拥有”某种身份否则系统不会允许它访问。于是就有了两种做法。一种是把账号密码告诉 AI。这是最直觉、也最危险的做法。密码一旦进入模型上下文就可能被记录到日志、被缓存、被网络链路中的第三方看到甚至可能在模型服务端留存。更麻烦的是你无法精确控制它用这个密码去访问什么也无法在事后证明某次越权操作不是你本人做的。另一种做法是让 AI 只在“已授权的会话环境”里工作密码始终保存在用户手里。用户在浏览器里正常登录一次系统把登录后的会话状态保存下来AI 代理拿着这个会话状态去执行操作但不知道密码也不接触密码。这个方法听起来简单但很多人不知道它为什么安全、以及如何落地。这篇文章要解决的核心问题就是如何让 AI 代理获得网站的“办事能力”但不获得网站的“密码凭证”。我更想强调的是这不仅是技术问题还是信任模型问题。一个合格的 AI 办公自动化方案必须满足三个条件可授权Agent 只在指定范围和时限内操作、可审计每一步操作都能追溯、可撤销随时收回 AI 的操作能力。下文的所有内容都会围绕这三条展开。谁最应该读这篇文章第一每天被网页重复操作困扰的办公用户想用 AI 减少琐事第二正在评估或开发 Agent 自动化工具的开发者需要把安全边界设计进架构第三负责效率工具选型的技术负责人需要判断一个 Agent 工具能不能进入企业环境。2. 关键概念会话、Cookie、OAuth 与 Agent 授权在进入代码之前必须先把几个概念理解清楚。很多人在密码问题上钻牛角尖是因为把“登录”理解得太简单了。2.1 为什么 AI 不需要密码也能登录你先想一个日常场景你早上打开浏览器进入某个管理系统发现不需要输入账号密码因为它记住了你的登录状态。这种“记住登录”的背后是浏览器保存了一个会话凭证最常见的形态是 Cookie。密码的作用其实只发生在登录那一刻。你输入密码后服务器验证通过会给浏览器签发一个凭证。之后浏览器访问其他页面时只需要带上这个凭证服务器看到有效凭证就直接放行。也就是说“登录成功”的本质不是服务器记住了你的密码而是服务器认可了你持有的凭证。这个事实非常关键。它意味着只要 AI 代理所在的浏览器环境里有一份有效的会话凭证它就能帮你办理已经登录状态下的全部琐事而不需要知道密码是什么。2.2 会话与 Token 的区别为了把概念理清我用一个类比你把家门的钥匙交给临时保洁保洁能进门打扫但不知道你家门锁的密码。这里的门锁密码就是密码临时钥匙就是会话凭证。密码可以长期有效泄露后只能换锁临时钥匙可以只给一天用完了可以自动失效。技术层面的几个概念可以简单对比如下概念通俗解释密码是否可见安全特点密码用户身份的长期证明是泄露后危害范围大需要立即修改Session Cookie服务器下发的临时通行证否有有效期可作废Token / OAuth 授权带权限范围的访问令牌否可以限定 scope可设置过期时间浏览器用户数据目录一个独立的浏览器环境否可与主浏览器隔离可整体删除你可能注意到Session Cookie 和 Token 都不需要让“使用者”知道密码。这正是在 AI 代理场景中最重要的安全基础把密码的用途从“每次访问都需要”变成“只在授权时使用一次”。2.3 Agent 凭什么能“办事”接下来要理解的是 Agent 的定位。在一个最小闭环里Agent 可以拆成三个部分一是意图理解层。它负责接收你的指令比如“帮我查一下今天的待办数量”。二是工具调用层。它决定调用哪个函数访问哪个系统比如调用一个get_dashboard_todo的工具函数。三是浏览器执行层。它通过浏览器自动化工具打开页面、读取内容、点击按钮。在这三层中真正需要身份认证的是第三层。只要第三层的浏览器环境里存在有效会话Agent 就能完成整个流程。而第一层和第二层完全不需要知道密码。这就解释了为什么“AI 代办网站杂务”和“把密码交给 AI”是两件可以完全分开的事情。3. 适用场景与边界哪些杂务适合交给 AI 代理市面上已经有越来越多的工具在尝试“AI 代操作网页”这个方向比如各类 Work 产品、浏览器自动化插件、企业 RPA 平台。不管名称怎么变判断标准是一致的这个任务适不适合交给 AI 代理不取决于 AI 能不能做而取决于风险边界。3.1 适合委托的杂务类型第一类是查询与汇总类。比如每天早上进入公司系统查看待办数量、审批状态、报表数据又比如登录多个网站把分散的数据汇总到一处。这类任务以读取为主即使出问题也有重新检查的机会。第二类是重复填写类。比如把固定模板的内容填进表单、提交周报、发送例行公告。这类操作的输入内容往往是固定的只要模板正确风险就很低。第三类是定时巡检类。比如定期检查某个页面是否更新、某项服务是否正常。这类任务让 AI 按计划执行比人工盯着高效得多。3.2 不建议委托的任务类型与之相对的有三类任务不建议放开权限。第一类是支付与资金操作。即使 AI 很聪明也不代表它不会在某个页面上点错按钮。资金操作需要最高一级的人工确认。第二类是删除、修改核心数据。比如删除数据库记录、批量修改用户信息、变更权限配置。这类操作一旦出错恢复成本很高应该强制人工确认。第三类是涉及第三方个人隐私数据的操作。AI 代理执行操作时会读取页面内容如果这些内容包含他人隐私就需要评估处理依据和合规要求不能只是为了效率就放开。3.3 一个简单的判断标准如果你不确定某个任务是否适合交给 AI 代理可以用三个条件来判断可回滚。操作出错了能不能恢复原状。查询、表单提交这类通常可以直接删除不可恢复不建议。可审计。AI 的每一步操作是否有日志记录。如果没有日志你无法确定它到底做了什么就会失去事后的追踪能力。可撤销。你能否在任意时刻收回 AI 的访问权限。如果不能说明授权链路设计有缺陷不应该投入使用。把这三个条件写进需求评估清单比单纯讨论“模型强不强”要重要得多。4. 环境准备与前置条件下面进入实操环节。我选择用 Playwright 作为演示工具因为它是目前做浏览器自动化比较成熟的方案支持 Chromium、Firefox、WebKitAPI 设计也比较清晰。即使你最后决定使用其他工具甚至直接使用商业 Agent 产品下面涉及的原理同样适用。4.1 运行环境本示例的核心环境如下版本请以实际项目为准Python 3.9 或更高版本Playwright 浏览器自动化库目标测试网站建议使用测试环境或低风险站点一台本地开发机器这里特别提醒一句不要在真实生产系统上直接做首次验证。先用测试账号、测试网站把流程跑通再评估是否对真实业务开放。关于授权和安全边界永远保持“先测试、后生产、最小权限”的原则。4.2 安装依赖# 创建虚拟环境推荐 python -m venv agent-demo source agent-demo/bin/activate # Windows 下使用 agent-demo\Scripts\activate # 安装 Playwright pip install playwright # 安装 Chromium 浏览器内核 playwright install chromium如果安装过程中遇到网络下载失败可以参考 Playwright 官方文档的离线安装方式。这一步只需要保证一个可用的浏览器内核即可。4.3 准备一个测试账号为了演示你需要准备一个测试网站账号。这个账号可以是你在某个低风险网站注册的普通账号也可以是本地开发环境的账号。重要的是整个验证过程不要使用你最重要的核心账号。有的网站对自动化登录有风控策略首次人工登录时可能触发验证码。这属于正常现象验证码的意义就是在真实性上做把关。在测试环境里可以优先选择没有强风控的站点来跑通流程。5. 完整示例构建“不知密码”的 AI 网页代办流程现在开始搭建完整流程。整个流程分为三步人工登录保存会话、AI 代理复用会话执行任务、授权撤销与会话清理。5.1 第一步人工登录并保存会话状态第一步的关键是让用户自己在浏览器窗口里完成登录然后把登录后的会话状态保存到本地文件。这段代码从头到尾都不会读取密码输入框的内容。# 文件路径scripts/save_session.py from playwright.sync_api import sync_playwright def save_login_session(session_file: str session_state.json): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) context browser.new_context() page context.new_page() # 打开目标网站登录页由用户本人完成登录 page.goto(https://example.com/login) # 脚本暂停等待人工登录完成后回车 input(请在浏览器窗口中完成登录然后回到终端按回车继续...) # 将当前上下文的存储状态保存为 JSON 文件 context.storage_state(pathsession_file) print(f会话状态已保存到 {session_file}其中不包含明文密码。) browser.close() if __name__ __main__: save_login_session()需要说明的是storage_state保存的是当前浏览器上下文里的 Cookie、LocalStorage 等会话数据。保存这个文件相当于保存了一把“临时钥匙”。它和密码的区别在于你可以删除文件让它立即失效也可以在系统中主动注销账号来作废对应的会话。实际文件内容类似下面这样里面不是密码而是站点签发的会话数据{ cookies: [ { name: session_id, value: abc123..., domain: example.com, path: /, expires: 1735689600 } ], origins: [] }这个 JSON 文件就是 AI 代理后续访问网站的凭证来源。你不需要把它交给大模型只需要让浏览器执行层读取它。5.2 第二步AI 代理复用会话执行任务会话保存之后AI 代理就可以在无头浏览器里加载这个会话执行具体的网页杂务。# 文件路径scripts/agent_task.py from playwright.sync_api import sync_playwright SESSION_FILE session_state.json def get_todo_count(): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context(storage_stateSESSION_FILE) page context.new_page() # 访问需要登录后可见的工作台首页 page.goto(https://example.com/dashboard) page.wait_for_selector(#todo-count, timeout10000) count page.inner_text(#todo-count) print(f当前待办数量{count}) browser.close() return count if __name__ __main__: get_todo_count()这段脚本执行了几个关键动作一是用headlessTrue启动无头浏览器让 AI 在后台执行任何需要登录页面的操作。二是用storage_stateSESSION_FILE恢复登录态相当于把之前保存的“临时钥匙”交给了浏览器环境。三是等待页面元素出现读取数据。在真实项目里你可以在page.goto之后继续添加更多操作例如填写表单、点击按钮、上传文件等。只要这些操作是由工具函数触发的Agent 就能在“不知道密码”的前提下完成整套流程。5.3 第三步撤销授权与会话清理会话凭证不能永久保存。建议把“撤销授权”做成一个独立工具随时可以调用。# 文件路径scripts/revoke_session.py import os def revoke_session(session_file: str session_state.json): if os.path.exists(session_file): os.remove(session_file) print(已删除会话文件AI 代理将无法继续访问。) else: print(会话文件不存在无需处理。) if __name__ __main__: revoke_session()除了删除本地文件更彻底的撤销方式是在目标网站内部执行“退出登录”操作。因为有些网站的 Cookie 即使被删除服务端可能仍然维护着会话记录。如果只删本地文件理论上服务端会话可能还有残留。真正要撤回权限时应该同时做两件事删除本地凭证、在目标系统里主动注销。bash 方式同样有效适合在自动化任务结束或异常时立即清理# 清理本地会话状态AI 代理立即失去登录能力 rm -f session_state.json把这段清理逻辑挂在任务完成后的钩子里或者定时任务里可以避免会话文件长期躺在磁盘上。6. 运行结果与效果验证现在把上面三个脚本组合起来跑一遍完整流程。6.1 运行命令# 第一步人工登录并保存会话 python scripts/save_session.py # 第二步AI 代理复用会话执行任务 python scripts/agent_task.py # 第三步验证撤销能力 python scripts/revoke_session.py python scripts/agent_task.py6.2 预期结果第一次运行agent_task.py时如果页面正常加载并在控制台打印出待办数量说明会话复用的方式可行。脚本本身不需要从任何地方读取密码。最后一次运行agent_task.py时因为会话文件已经被删除页面通常会跳转到登录页或者因为找不到#todo-count元素而抛出超时异常。这正是我们想要的结果权限确实被收回了。6.3 如何确认“没有泄露密码”这是整个方案里最容易忽视的一步。你可以打开session_state.json搜索是否包含你使用的密码字段。正常情况下文件里只有 Cookie 和 LocalStorage 数据不应该出现密码明文。如果某个网站把密码或敏感信息写入了 LocalStorage那么这个站点本身就不适合用这种方案代理。你可以测试多个站点选用只通过会话 Cookie 管理登录的目标系统。这个检查动作应该写进自动化流程的验收清单里而不是只在第一次验证时做一次。后续每次更换会话文件都应该重新确认。7. 常见问题与排查思路在实际跑通这个方案时下面几个问题出现频率最高。问题现象可能原因排查方式解决方案Agent 访问时跳转到登录页会话过期或 Cookie 失效查看会话文件是否存在检查目标网站登录态重新执行首次登录脚本保存新会话弹出验证码或滑块验证网站风控识别到自动化环境观察浏览器指纹减少高频请求降低执行频率或引入人工确认环节二次验证2FA导致中断登录需要手机验证在首次人工登录时完成验证后再保存将会话有效期和 2FA 策略一并纳入方案会话文件被误提交到代码库没有配置忽略规则检查 git 状态和仓库历史将 session_state.json 加入 .gitignore权限范围过大会话包含该账号的所有权限评估任务实际需要的接口和数据为 Agent 使用单独受限账号AI 上下文里出现敏感页面数据页面内容被完整传给大模型审查调用链和模型日志只提取最小必要字段脱敏后再传递删除会话后仍能访问系统服务端会话未真正注销在目标系统中查看活跃会话主动调用注销接口或退出登录逐个说一下最需要注意的两个问题。第一个是验证码。自动化环境的浏览器特征和普通用户不同很多网站会触发验证。这不一定代表你的方案有问题而是说明目标系统的安全策略比较严格。一个常见的缓解方式是把高验证频率的任务降低到人工可接受的频次或者让 AI 代理在遇到验证码时暂停并通知用户处理。第二个是服务端会话残留。删除本地文件只能让 AI 代理失去访问能力但如果服务端没有注销会话理论上仍存在潜在风险。所以在生产环境里服务端的主动注销永远是第一选择本地文件清理只是兜底。8. 最佳实践与工程建议讲完可运行的示例再聊一些更贴近生产环境的工程建议。这些建议不是空泛原则而是把“不泄露密码”这条底线落实到具体技术决策上。8.1 使用独立账号和独立浏览器配置不要让 AI 代理使用你的主力账号。推荐的做法是为 AI 代理申请一个低权限账号或者至少使用一个独立的浏览器用户数据目录。这样即使会话泄露影响范围也被限制在一个独立环境内。启动独立浏览器配置的命令示例# 为 AI 代理创建独立的浏览器用户数据目录 google-chrome --user-data-dir/path/to/agent-profile --remote-debugging-port9222这个独立配置目录里的 Cookie、缓存、密码库都与日常浏览器隔离。AI 代理操作过程中产生的历史记录、下载文件也不会污染你的主浏览器环境。8.2 会话文件加密存储session_state.json本质上是可以访问网站的“钥匙”。如果这份文件被未授权的人拿到对方就能冒充你登录目标系统。因此会话文件必须加密存储并且严格限制文件权限。在团队协作项目中更推荐把会话文件交给专门的密钥管理系统保管而不是放在共享代码目录。代码仓库中至少要确保# .gitignore session_state.json *.session.json8.3 限制 AI 代理的最小权限最小权限原则在这里有两层含义。第一层是账号权限。给 AI 代理使用的账号应该只拥有完成任务所需的最少权限。如果它只是查询待办就不该拥有修改配置的权限。第二层是会话语义范围。不要让 AI 代理在同一个会话上下文里访问所有网站。不同的任务使用不同的会话文件任务完成后立即注销。这样可以把单次泄露的影响范围控制在最小。8.4 记录操作日志AI 代理的每一次网页点击、表单填写、页面跳转都应该有日志记录。日志至少包含三部分操作时间、操作内容、目标 URL。有了日志你才能在异常发生之后还原当时的执行过程判断是模型决策错误、页面结构变化还是外部环境问题。对于企业场景建议把日志接入统一的审计系统与账号体系打通。这既是安全要求也是合规要求。8.5 高风险操作设置人工确认即使 AI 代理已经学会了某个流程也不要让它完全自动执行高风险操作。设计一个“人工确认”环节AI 完成表单填写后把最终内容发回给用户确认用户点击同意后AI 才执行真正的提交。这个模式可以用一个很简单的任务队列实现AI 代理生成待办事项人工确认后放行执行结果记录回队列。成本不高但能挡住很多误操作。8.6 定期轮换与主动撤销会话凭证长期有效会增加泄露风险。建议制定一个会话轮换周期比如每周重新登录一次并更新会话文件。发现异常操作时立即执行删除本地文件加服务端注销的双重撤销。在企业场景里还应该监控 AI 代理账号的异常行为例如非常规时间登录、批量下载、访问高敏感页面等。这些行为指标能帮助你在风险发生前就介入。9. 总结与后续学习方向把整篇文章的要点浓缩一下其实就三句话第一AI 代理登录网站办事不需要密码。它需要的是一份可撤销、有时效、有边界的会话凭证。第二安全边界不是靠模型自觉而是靠工程链路设计。独立账号、最小权限、日志审计、双向撤销这些传统 Web 安全的手段在 Agent 时代不仅没有过时反而更加关键。第三对个人用户来说先跑通“人工登录保存会话、Agent 复用会话执行、随时撤销授权”的最小闭环已经比把密码硬塞给 AI 安全一个数量级。如果你接下来想继续深入可以从这几个方向入手学习 Playwright 的页面交互与等待策略理解 OAuth2 的授权码流程与令牌过期机制尝试在项目中引入独立的密钥管理服务和审计日志关注主流 Agent 工具的权限隔离设计。AI 代办办公杂务一定会越来越普及。越是在这个时候越要守住一条底线工具可以代替你操作但不应该代替你拥有密码。拥有密码的永远只能是你自己。