企业官网建设流程全解析

最近被问到一个很有意思的问题：ChatGPT 能不能替我登录网站、订票、填表、办各种杂务？紧接着的第二句话往往是：那我的密码不是全被它看到了吗？

这是一个典型的两难场景。一方面，AI Agent 的价值恰恰在于“替你做事”，而很多事的第一步就是登录；另一方面，密码这种敏感信息一旦交给模型、传给第三方，风险就完全失控了。事实上，很多人在看到“AI 可以代操作浏览器”这类能力时，只是兴奋，却忽略了一个关键问题：它凭什么能安全地替代我登录？

这篇文章想把这个问题讲透。核心判断是：所谓“代登录办杂务且不泄露密码”，并不是什么魔法，而是建立在会话隔离、凭证托管、协议委托和最小权限这四个工程机制之上。读完之后你会明白，ChatGPT 这类浏览器 Agent 真正安全的用法是什么，以及如果你想在自己的项目里实现类似的“代办 Agent”，应该怎么设计。

这篇内容适合三类读者：想理解 AI 浏览器代理安全边界的开发者，正在做 RPA 或 Agent 平台的工程师，以及关心账号安全的普通用户。文章会从原理讲到实现，从代码样例讲到排错清单，尽量让每个环节都能落地。

1. 这篇文章真正要解决的问题

先还原一下场景。假设你打开 ChatGPT 的浏览器操作类功能，让它帮你去某个购物网站下单，或者去某个政务平台提交材料。很快你就会遇到第一个问题：目标网站需要登录。此时摆在你面前的有两个选择：

第一个选择，把账号密码告诉 AI。这显然有问题。模型运行在远程服务端，这意味着密码要经过网络传输、在服务端处理，还要面临日志记录、训练数据隔离、服务商数据政策等一系列不可控因素。即便官方承诺不记录，作为一个有安全常识的开发者，你也很难接受把高价值网站的密码交给第三方。

第二个选择，不登录，只让 AI 操作公开页面。但这个限制太死了。真实世界里，订机票需要账户积分，查工作台需要企业 SSO，管理云服务器需要控制台权限。不能登录，Agent 的可用场景就少了一大半。

于是，真正的问题浮出水面：能不能让 AI 完成“登录后可执行的任务”，但又在架构上避免让 AI 接触密码？答案是能。而且答案不是靠“信任模型不偷看”这种自我安慰式的假设，而是靠系统设计。密码不该成为一个被传递的字符串，而应该被转换成一种限时、限范围、可撤销的凭证。

这个思路听起来不复杂，但真正在工程里落地时，会发现很多细节值得深入。比如：会话文件应该由谁生成？Agent 能拿到什么权限？会话过期后如何处理？双因素认证怎么配合？这些内容会在后文逐个展开。

2. Agent 代操作网站的原理：从“替你看”到“替你点”

要理解“不泄露密码”的设计，先得理解浏览器 Agent 是怎么替用户操作网站的。

传统自动化工具，比如早期的 RPA（机器人流程自动化），通常是把操作步骤录制成脚本，再按固定路径执行。它的逻辑是“录屏回放”，适合流程稳定的任务。而 AI Agent 不一样。它不是执行固定脚本，而是理解自然语言任务，然后把任务拆解成一系列页面操作：打开页面、读取表单、填写内容、点击按钮、检查结果。

这个过程依赖三个核心组件：

第一是视觉识别或 DOM 解析。Agent 需要“看到”页面上的元素。常见的实现方式包括分析 HTML 结构、读取无障碍树，或者直接对页面截图做视觉推理。视觉推理的好处是能处理 Canvas、图片验证码等非标准元素，但成本更高，稳定性也更难保证。

第二是浏览器控制层。Agent 需要真正操作一个浏览器实例。ChatGPT 的云端浏览器、OpenAI Operator 这类产品，本质上都是把浏览器跑在云端容器里，由模型控制键盘鼠标事件和网络请求。

第三是登录状态管理。很多网站的核心数据都在登录墙后面，Agent 必须携带一个有效的会话。这个会话可以来自用户手动登录后保存的 Cookie，可以来自 OAuth 授权后的临时令牌，也可以来自企业内部的单点登录票据。

看到这里，你应该明白了：“代登录”并不等于“把密码交给 AI”。“登录”这个动作和“持有会话”这个状态，其实是两件事。密码只是获得会话的手段之一，而且是最敏感的手段。理想设计下，密码只在用户自己的浏览器里出现一次，换来一个会话凭证，之后 Agent 与网站交互时携带的是这个凭证，而不是密码本身。

所以，下一节要讨论的，就是如何把这套流程工程化。

3. “不泄露密码”到底靠什么实现：四种机制拆解

3.1 会话隔离：密码只在你的浏览器里

最直接的做法是：密码根本不出现在 Agent 的运行环境里。

具体流程是这样的：用户在自己的本机浏览器中打开目标网站，正常输入账号密码并完成登录。登录成功后，浏览器会把会话信息写入 Cookie、localStorage 或 IndexedDB。此时把这份浏览器上下文保存成一个文件，交给 Agent 加载。Agent 启动时直接恢复会话，就相当于已经登录。整个过程里，密码从头到尾只存在于用户本机的浏览器进程内存中，没有经过 Agent 的代码，也没有发送给第三方。

这种模式最容易被理解，也最适合个人场景。但它的缺点是会话会过期，Cookie 失效后需要用户重新登录一次。如果你的任务是低频、短时、单次执行，这已经足够了。

3.2 凭证托管：把密码交给保险箱，而不是 AI

如果你开发的是一个 Agent 平台，需要服务多个用户，就不能让用户每次手动保存 Cookie 了。这时候可以用凭证托管的方式。

把密码保存在用户授权的密码管理器或企业密钥管理服务中，Agent 运行时并不直接读取密码，而是由凭证服务在受限环境里完成登录动作，再将得到的短期会话交付给 Agent。换句话说，密码的持有者和使用会话的执行者是分离的。Agent 只知道自己拿到了一个“已登录的浏览器上下文”，永远不知道密码本身。

这里的关键点在于权限边界。凭证服务应该对 Agent 端做严格的身份认证，并且记录每一次凭证取用行为。即便是企业内部的机器人账号，也建议把密码轮换周期缩短，降低泄露后的影响范围。

3.3 协议委托：OAuth / OIDC 让 Agent 拿临时令牌

另一种更“标准”的方案是使用 OAuth 2.0 或 OIDC 授权协议。这种方式不需要保存密码，也不共享 Cookie，而是通过授权码流程，让用户授权 Agent 访问有限范围内的资源。

流程类似于微信扫码登录第三方网站：用户在自己的设备上确认授权，授权服务器返回一个短期访问令牌，Agent 使用令牌调用目标网站提供的接口。密码自始至终只存在于授权服务器和用户之间，Agent 拿到的是一个 scope 受限、有效期短、可随时撤销的令牌。

这种方式最安全，但前提是目标网站必须支持 OAuth 或提供公开 API。现实是大量老旧的业务系统只支持表单登录，连验证码都难以绕过。因此，在企业内部环境中，会话隔离和凭证托管反而更常见。

3.4 最小权限与审计：Agent 只能做“允许的事”

无论用哪一种机制，最后都离不开最小权限原则。即使 Agent 已经登录，也不意味着它可以为所欲为。

在实际工程中，通常会有一个任务白名单。Agent 只允许对特定站点、特定路径、特定接口发起操作。比如允许创建订单，但不允许修改支付账号；允许读取工单列表，但不允许删除工单。这个白名单既可以在浏览器扩展层做，也可以在网关层做。

同时，每一次 Agent 执行的操作都要有审计日志：什么时间、由哪个任务触发、访问了哪个 URL、提交了什么表单、获得了什么结果。一旦出现异常，可以快速定位到具体的行为链。

四条机制放在一起，才是完整的“代登录且不泄露密码”方案。少了任何一环，都会留下风险。

4. 环境准备与前置条件

如果看完原理，你想在自己机器上跑通一个最小实验，先准备环境。这里用的方案是会话隔离模式，也就是“用户登录 + Agent 复用会话”。

推荐的自动化框架是 Playwright。它支持持久化浏览器上下文，可以很方便地把登录状态保存成 JSON 文件，并在下次启动时恢复。与 Selenium 相比，Playwright 的 API 更新现代，对现代浏览器的特性支持更好，而且自带自动等待机制，写出来的脚本更稳定。

基础环境如下：

• 操作系统：Windows / macOS / Linux 都可以，本文示例以命令行执行为准。
• Python 版本：3.9 以上。
• 浏览器：Chromium 内核，Playwright 会自动下载对应的浏览器二进制文件。
• 依赖库：playwright，版本以 PyPI 当前稳定版为准，不限定死版本。

建议目录结构：

agent-demo/ ├── scripts/ │ ├── login_once.py # 用户手动登录，生成 session.json │ └── agent_task.py # Agent 加载会话，执行网站任务 ├── session.json # 会话文件，不要提交到 Git └── requirements.txt # 依赖清单

安装依赖的命令：

pip install playwright playwright install chromium

安装完成后，可以在命令行输入python -c "from playwright.sync_api import sync_playwright; print('ok')"验证环境是否正常。如果打印出ok，说明依赖已经可用。

这里要特别提醒：涉及登录、Cookie、令牌的实验，一定要在你有合法授权的测试环境或自己的账号上进行。不要拿别人的网站、未授权的系统做测试，更不要尝试绕过验证码、双因子认证等安全机制。

5. 核心流程拆解

整个安全代办流程可以拆成四个步骤。

5.1 用户完成首次登录，生成会话文件

第一步由用户手动完成。打开目标网站，输入账号密码，通过可能的验证码或双因子认证。这一步的目的是让网站信任当前浏览器，并生成合法的会话凭证。

登录成功后，关闭页面之前，把当前浏览器上下文的 storage_state 保存下来。这个文件里包含的是 Cookie、localStorage 等会话信息，不包含密码。你可以打开文件查看，正常情况下的字段是 Cookie 的 name、value、domain、path、expires 等，不会有 password 字段。

5.2 对会话文件做安全保护

保存下来的 session.json 等同于“已登录状态”。如果它落到别人手里，对方不需要密码就能直接登录你的账号。所以必须像保护密码一样保护它。

建议的做法有几种：把文件放到只有当前用户可读的目录；使用系统密钥管理器或环境变量控制文件路径；设置定时清理机制；在 CI/CD 或服务器环境中把会话文件放到加密卷里。总之，不要让 session.json 进入 Git 仓库，不要上传到公开的存储桶，不要在日志里打印它的内容。

5.3 Agent 加载会话，执行指定任务

Agent 启动浏览器时，不再需要用户输入账号密码，而是直接加载 session.json。Playwright 的new_context(storage_state=...)会恢复登录状态，之后 Agent 就像普通用户一样操作页面。

这个阶段要注意：Agent 的任务指令应该明确、有限。不要写“帮我把账号里的所有操作都做一遍”，而是写“在订单页面创建一笔金额为 X 的订单”。任务越明确，出错范围越小，审计越容易。

5.4 会话失效时，回到第一步

Cookie 会过期，网站在改密码后也会让旧会话失效。如果 Agent 在执行任务时发现页面跳转到登录页，它应该停止操作并通知用户：会话已失效，需要重新登录。

这里不建议让 Agent 自己去“想办法登录”。让模型尝试自动填密码，既容易触发网站风控，也可能把密码带入不可控的流程。正确的做法是中断任务，走用户接管流程，让用户重新登录并刷新会话文件。

这四个步骤构成一个闭环。理解这个闭环之后，代码实现就有方向了。

6. 完整示例与代码实现

下面给出三个代码示例，分别对应会话生成、Agent 执行和 OAuth 委托。前两个是个人场景可运行的最小实现，第三个展示企业场景更安全的标准做法。

6.1 示例一：用户本地登录并保存会话

文件路径：scripts/login_once.py

from playwright.sync_api import sync_playwright LOGIN_URL = "https://example.com/login" SESSION_FILE = "./session.json" with sync_playwright() as p: browser = p.chromium.launch(headless=False) context = browser.new_context() page = context.new_page() page.goto(LOGIN_URL) # 在这里由用户手动输入账号密码，完成登录 # 也可以让浏览器扩展或密码管理器自动填充表单 input("请在页面中完成登录，然后回到终端按回车继续...") # 登录成功后，将当前会话保存到本地文件 context.storage_state(path=SESSION_FILE) print(f"会话已保存到 {SESSION_FILE}") browser.close()

这段代码的关键点有两处。

第一，浏览器使用headless=False，让用户能看到页面，手动输入密码。密码不会出现在脚本中，也不会被保存到日志。

第二，storage_state(path=SESSION_FILE)保存的是 Cookie 和 localStorage，而不是明文密码。你可以打开生成的session.json检查，里面不会有类似"password": "123456"的字段。

需要提醒的是：登录环节应该在用户本人可控的设备上进行。如果你在企业环境中使用，登录操作最好由账号持有者在自己的办公设备上完成，而不是由管理员在服务器上代做。

6.2 示例二：Agent 加载会话执行网站任务

文件路径：scripts/agent_task.py

from playwright.sync_api import sync_playwright TASK_URL = "https://example.com/orders/new" SESSION_FILE = "./session.json" # 任务描述：打开新建订单页面，填写标题并提交 with sync_playwright() as p: browser = p.chromium.launch(headless=True) context = browser.new_context(storage_state=SESSION_FILE) page = context.new_page() page.goto(TASK_URL) # 页面加载后，定位表单元素并填写 # 选择器需要根据目标网站实际 DOM 结构调整 page.fill("#order_title", "购买打印纸") page.click("#submit_order") # 等待页面返回结果 page.wait_for_selector(".order-success") print("任务完成，订单已提交") browser.close()

这里有一个需要特别说明的地方：Agent 的程序代码只加载了session.json，没有读取任何密码字段。登录态由浏览器上下文自动恢复。这正是前面说的“身份与密码分离”思想。

示例中的选择器#order_title、#submit_order、.order-success是占位符。真实项目中，你需要先用page.goto打开页面，再用page.locator()去定位实际元素。建议先编写一个探测脚本，把页面上的表单标签名打印出来，再动态调整选择器。

6.3 示例三：OAuth 授权码模式，让 Agent 拿到短期令牌

如果你的目标系统支持 OAuth 2.0，更推荐用授权码模式 + PKCE。用户密码只发送给授权服务器，Agent 拿到的是限时、限 scope 的访问令牌。

from urllib.parse import urlencode import requests AUTH_SERVER = "https://auth.example.com/oauth/authorize" TOKEN_SERVER = "https://auth.example.com/oauth/token" # 第一步：构造授权链接，用户在自己的浏览器中打开 params = { "response_type": "code", "client_id": "agent-client", "redirect_uri": "https://localhost/callback", "scope": "web:order:create web:profile:read", "code_challenge": "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM", "code_challenge_method": "S256", "state": "random_state_123", } auth_url = f"{AUTH_SERVER}?{urlencode(params)}" print("请在浏览器中打开授权链接：", auth_url) # 假设用户授权后，回调地址携带了 code code = "authorization_code_from_callback" # 第二步：后端用 code + code_verifier 换取访问令牌 token_resp = requests.post(TOKEN_SERVER, data={ "grant_type": "authorization_code", "code": code, "redirect_uri": "https://localhost/callback", "client_id": "agent-client", "code_verifier": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk", }) token_data = token_resp.json() access_token = token_data["access_token"] print("Agent 已获得短期访问令牌，scope：web:order:create web:profile:read") print("此令牌不包含用户密码，且可以在授权服务器上随时撤销")

这段代码中的授权链接只是演示，实际需要拼上回调状态校验，并且code_verifier要和授权请求时的code_challenge对应。真实项目里，应该使用成熟的 OAuth 客户端库，不要自己实现 PKCE 加密细节。

OAuth 模式的最大好处是：Agent 拿到的令牌具有明确的 scope 边界，例如只能创建订单、只能读取个人资料。一旦令牌泄露，用户可以到授权服务器上主动撤销，影响范围更小。

7. 运行结果与效果验证

三个示例的运行结果分别验证如下。

先运行登录脚本：

python scripts/login_once.py

终端会提示你在浏览器里登录。完成登录后回车，输出：

会话已保存到 ./session.json

此时检查文件内容，确认没有 password 明文。可以用 grep 或直接编辑打开查看：

grep -i "password" session.json || echo "未发现 password 字段"

如果输出未发现 password 字段，说明第一步符合预期。

然后运行 Agent 执行脚本：

python scripts/agent_task.py

如果目标页面跳转到了业务页面并成功提交订单，终端输出：

任务完成，订单已提交

如果 Agent 打开页面后跳转回了登录页，说明session.json已失效。此时不要试图用脚本自动登录，而是回到浏览器重新执行login_once.py。

对于 OAuth 示例，验证重点不是跑通接口，而是检查两个配置文件：授权请求中的scope是否最小化，state参数是否校验收紧。再多做一步：去授权服务器上撤销令牌，确认 Agent 后续调用会收到 401 错误。这能证明令牌是可撤销的，而不是像密码那样难以回收。

8. 常见问题与排查思路

在实际搭建这类系统时，最常见的不是代码报错，而是登录态、风控和自动化环境问题。下面列几个高频问题。

这六类问题里，最值得警惕的是前两类。它们都和“自动化痕迹”与“会话有效性”有关，直接影响任务能否成功执行。遇到问题先看页面 URL 跳到了哪里，再判断是登录态问题还是页面结构问题，不要一上来改代码。

9. 最佳实践与工程建议

如果要在真实项目里落地“代登录且不泄露密码”的 Agent，建议遵守下面这些工程准则。

第一，密码不进代码、不进日志、不进数据库。密码只应该在用户登录的那一刻出现在浏览器进程中。凡是涉及密码的自动化脚本，都应该改造成“用户手动登录 + 保存会话”的模式。如果团队里有人提交了包含密码的代码，要让 Code Review 拦下来。

第二，会话文件按密钥对待。session.json 一旦泄露等同于账号被接管。建议对保存目录设置严格的系统权限，并定期清理过期会话。在服务端场景中，把会话文件挂载到加密卷，并配置自动失效时间。

第三，令牌和 Cookie 都要有生命周期。不要追求“一次登录永久有效”。更合理的设计是：短期会话执行当前任务，任务结束后立即销毁会话；下次任务需要时再让用户重新授权。虽然体验上会多一次点击，但安全收益显著。

第四，Agent 的任务范围要收敛。给 Agent 定义“能做什么”比“不能做什么”更简单。你可以维护一个允许操作的 URL 前缀列表，或者用网关层接口做访问控制。任务成功后记录成功时间、请求参数、执行结果，方便后续审计。

第五，完善审计日志。日志至少要包含任务 ID、关联用户、执行的 URL、提交的表单内容（脱敏）、返回状态、消耗的模型 Token 数。这些日志能帮助你在安全事故发生后快速定位责任边界，也能帮助优化任务指令。

第六，平台条款与合规风险。并不是所有网站都允许自动化脚本访问。即使是自己的账号，也要阅读目标网站的服务条款，了解是否禁止自动化工具。如果是企业内部系统，先确认自动化操作是否偏离了该系统的使用约定。在未授权的情况下，不要对任何第三方网站做自动化探测。

第七，设计“用户接管”通道。当 Agent 遇到验证码、2FA、异常页面时，最安全的做法是暂停并通知用户。用户接管时，可以打开一个实时可见的浏览器画面，自己手动完成关键步骤，再交还给 Agent 继续执行。这个模式在电商、政务、银行类场景下尤为重要。

10. 总结与后续学习方向

回到标题：ChatGPT Work 能够代登录网站办杂务且不泄露密码，本质上是把“登录”变成一次性的授权行为，把“会话”变成可复用、可撤销、限范围的凭证。这个思路并不只适用于 ChatGPT，也适用于任何浏览器类型的 AI Agent。

如果你想继续深入，建议按这个顺序学习：先熟悉 Playwright 的持久化上下文和 storage_state；再理解 OAuth 2.0 的授权码模式和 PKCE 流程；然后研究 Cookie 分类、会话过期机制和常见反自动化策略；最后可以关注 ChatGPT 这类产品的浏览器 Agent 在“用户接管”和“权限白名单”上公开的技术文档。

真正设计一个安全的代办 Agent，关键不在于藏住密码，而在于让密码在整个系统里根本没有流转的必要。希望这篇文章能帮你在下一次做 Agent 方案时，把“登录”和“安全”放在同一条技术路线上思考。