这次我们来看一个 Cloudflare 刚刚放出来的新项目Kitesurf。它不是又一个 AI 对话助手也不是给普通用户换皮肤的浏览器而是一个专门为 AI 智能体AI Agent设计的浏览器。简单说Kitesurf 的定位是把浏览器从“人看网页的工具”变成“AI 替人干活的基础设施”。如果近几年你在做网页自动化、爬虫治理、RPA 或者 Agent 工具链应该能理解这个需求传统浏览器是为人类点击设计的DOM 结构混乱、弹窗频繁、登录态复杂AI 在里面执行任务经常走着走着就断。Kitesurf 想解决的就是“让 AI Agent 在浏览器里跑得更稳、更可控”这件事。这篇文章我会按 CSDN 读者习惯的顺序来拆先说核心能力速览和适用边界再给一套通用部署启动思路然后展开功能测试、接口 API、批量任务接入、资源占用观察和常见问题排查。目前 Cloudflare 官方还没有放出完整的本地部署文档和全量 API 规范所以凡是涉及具体命令、参数、显存占用的地方我会明确标成“通用模板”或“需以实际项目为准”避免拿推测当事实。1. Kitesurf 是什么为 AI 智能体而生的浏览器1.1 从普通浏览器到 Agent 运行时传统浏览器解决的核心问题是“人如何高效浏览网页”所以它把大量资源花在渲染引擎、标签页管理、书签同步、扩展生态上。AI Agent 的诉求完全不同机器不关心页面好不好看更关心页面结构是否能被程序化理解、任务流程是否稳定、每一步操作是否有完整日志。Kitesurf 想做的就是把浏览器变成 AI 代理的运行时环境。它关注的不是用户点哪里而是页面如何被 AI 结构化成可执行的任务节点浏览器进程如何被沙箱隔离避免一个恶意页面拖垮整个 Agent登录态、Cookie、本地存储这些状态如何在多轮任务中保持一致任务执行过程中的截图、网络请求、控制台日志如何被自动采集和回放外部调用方如何通过 API 或事件机制把新的任务喂给浏览器。这个定位和 Cloudflare 一贯的“安全 基础设施”路线是吻合的。Cloudflare 之前大量能力都在网络边缘层比如 DNS、CDN、WAF、Bot 管理而 Kitesurf 更像是把触角伸向“AI Agent 的工作台”这一层。它和普通用户熟悉的 Chrome、Edge 不是同类产品更接近“面向机器人的浏览器运行时”。1.2 和 Playwright、传统浏览器自动化的区别很多人会想网页自动化不是早就有 Playwright、Selenium、Puppeteer 了吗Kitesurf 的差异化在哪里首先要承认Playwright 这类工具确实足够强大很多 AI Agent 产品底层就是拿 Playwright 驱动浏览器。它们的核心思路是“用脚本控制浏览器”你写page.goto()、page.click()、page.fill()然后等待元素出现再做断言。问题在于这种方式本质上还是“把人类的操作步骤写成代码”遇到动态页面、弹窗、验证码、突然出现的 Cookie 授权条脚本很容易失效。Kitesurf 作为面向 Agent 的浏览器更强调几个层面的能力上下文记忆Agent 在多轮任务里能保留页面状态和业务上下文而不是每次重新加载感知层统一把页面里的文本、表单、链接、按钮统一曝露成适合模型读取的“可操作视图”降低 Prompt 到页面元素的映射成本权限边界Agent 能访问哪些域名、能不能操作表单、能不能下载文件都由控制面统一管理可观测性每次动作的前后状态、截图、控制台日志、网络请求都被记录方便开发者复盘和调试。从公开材料看Cloudflare 自己也一直在做 Bot 防护后台 security 模块里的 bots management 就能识别和管控自动化流量。Kitesurf 这类产品如果做大了必然会和 Bot 识别、反爬策略产生天然关联一方面是自家浏览器跑 Agent另一方面是边缘防护识别“哪些流量来自可信 Agent”。这个交叉点后续会很有意思。1.3 项目定位判读综合目前信息Kitesurf 更适合被理解成**“Agent 基础设施的一层”**而不是终端用户产品。它面向的是开发者、AI 应用团队、自动化服务商你在 Kitesurf 里跑一个 AgentAgent 通过它去访问 Booking、GitHub、Notion、企业 OA 这类站点完成信息收集、表单填写、流程审批。最终用户不直接接触 Kitesurf他们接触的是你基于 Kitesurf 封装出来的业务应用。如果你期待的是“下载一个本地浏览器像 Chrome 一样手动打开页面”那 Kitesurf 现阶段大概率不适合。但如果你正在做 AI 工作流、RPA 替代、爬虫防御对抗或 Agent 平台这个项目值得持续关注。2. 核心能力速览以下是基于公开信息和合理推断整理的速览表。凡是涉及具体数字的目前没有官方详细文档支撑统一标注“需以实际项目为准”不要拿这张表当最终规格。能力项说明项目类型面向 AI 智能体的浏览器运行时 / Agent 基础设施开发方Cloudflare目前处于发布早期阶段核心受众AI 应用开发者、自动化服务商、Agent 平台团队主要功能页面结构化访问、Agent 会话管理、任务执行、权限控制、可观测性从定位看大概率支持 API 驱动推荐硬件本地部署建议至少 4 核 CPU、8GB 内存有 GPU 可加速页面视觉理解需以实际项目为准显存占用不确定如果主要是 DOM 结构化而非视觉模型则对显存要求不高如果引入视觉语言模型做页面理解则需要根据模型规格评估支持平台Linux 服务端部署概率最高是否支持 Windows/macOS 本地运行需以官方发布文档为准启动方式预计支持 Docker / 命令行启动并暴露本地 Web 管理界面或 API 服务是否支持 API大概率支持否则难以作为 Agent 基础设施使用具体端点、鉴权方式需以实际接口文档为准是否支持批量任务理论上可以通过并发浏览器实例或任务队列实现具体并发上限需压测确认适合场景表单自动填写、网页信息采集、Agent 任务编排、企业自动化流程、验证码与登录态管理策略研究这里特别注意浏览器类项目如果只做 DOM 级自动化CPU 和内存是关键显存不是主要瓶颈。但如果 Kitesurf 后续内置了基于屏幕截图的视觉理解模型那 GPU 的压力会立刻上去。选择部署环境前建议先跑一个典型任务观察 CPU、内存、网络吞吐三项指标再决定要不要上 GPU。3. 适用场景与使用边界3.1 适合谁第一类用户是做 Agent 应用开发的团队。如果你的 Agent 需要频繁访问网页、读取信息、提交表单直接让模型调用浏览器 API 比把几千个网站都封装成接口要快得多。Kitesurf 这类浏览器就是为这种“万能接口”形态准备的。第二类是 RPA 和流程自动化服务商。传统 RPA 处理网页自动化时要靠选择器页面改版就得重新配置。基于 AI Agent 的浏览器可以降低对固定选择器的依赖模型根据页面语义决定操作抗页面结构变化的韧性更强。第三类是安全研究和 Bot 防护团队。Cloudflare 自己的 bot management 页面里就有严格模式、验证码、JS 质询等选项。研究 AI Agent 浏览器的行为特征对识别和治理自动化流量非常有参考价值。反过来安全团队也可以评估自家网站的 Bot 防护策略是否能挡住这种新型浏览器。3.2 不适合什么场景如果你只需要“高并发抓取页面源码”用传统爬虫框架加代理池的成本和稳定性现阶段大概率优于 Agent 浏览器。Agent 浏览器的优势是“理解任务、动态决策”不是“以最低成本把 1 亿个 URL 抓完”。如果你的业务对延迟极其敏感比如毫秒级返回也不适合把 Agent 浏览器放在核心链路上。LLM 做页面理解和决策本身就带几十到几百毫秒开销再加上浏览器渲染整体耗时通常以秒计。3.3 合规与安全边界只要涉及 AI Agent 访问网页合规就是绕不开的话题。访问第三方网站前要确认目标网站的 robots 协议和服务条款避免未授权抓取涉及登录的站点必须有账号授权不能用自动化手段绕过验证码、短信校验或风控机制Agent 执行过程中会接触用户数据、Cookie、Token必须做好隔离和脱敏浏览器产生的日志可能包含完整页面请求和敏感输入日志存储要加密、设置访问权限不要把 Kitesurf 用于批量注册、囤票、秒杀、养号等违反平台规则的行为。这个提醒不是套话。浏览器类自动化工具的滥用门槛极低一旦被用于灰黑产后果不只是账号被封还可能触发法律责任。4. AI Agent 浏览器要解决的核心问题4.1 会话与上下文的管理人用浏览器时打开多个标签页大脑里天然清楚哪个页面在做什么。Agent 不行。如果每次调浏览器都开一个全新实例没有会话上下文任务做到一半状态就丢了。Kitesurf 这类浏览器需要在浏览器级别管理“任务级会话”一个任务对应一组页面状态、一组 Cookie、一组历史动作甚至一组模型上下文。这对开发者的价值是你可以在任务中断后恢复现场查看 Agent 执行到哪一步哪一步和预期不符。如果只看日志很难定位问题但如果能从浏览器里回放出当时的页面截图和 DOM 快照调试效率会高很多。4.2 权限与隔离Agent 浏览器比普通浏览器更需要权限控制因为操作者不是人而是一段可能失控的代码。没有边界的话一个 Prompt 被注入恶意指令Agent 可能替用户删库、发邮件、转账。合理的架构应该包括域名白名单Agent 只能访问指定域名操作白名单允许点击、填写、提交还是只允许读取敏感信息隔离密钥、Token、Cookie 不直接暴露给 Agent 的模型上下文会话隔离任务 A 和任务 B 的浏览器状态互相不可见网络隔离沙箱网络限制 Agent 访问内网地址。这些能力如果做得足够细Kitesurf 对团队的价值就不仅是“能开浏览器”而是“让浏览器可以安全地交给 AI 操作”。4.3 自动化稳定性AI Agent 操作网页最大的痛点是“不稳定”。页面加载慢、按钮动态出现、弹窗遮住元素、登录态过期任何一个环节出问题Agent 就卡住。传统自动化靠等待和重试Agent 浏览器靠的是“感知-决策-执行”闭环。稳定性可以从几个维度评估页面加载超时后Agent 是报错还是刷新重试遇到登录态失效Agent 能否感知并重新登录页面出现意外弹窗Agent 能否识别并关闭表单内容填错Agent 能否感知校验失败并修正。这些能力需要浏览器层提供稳定的 API否则 Agent 看不到异常状态自然也无法恢复。4.4 与反爬和 Bot 管理的关系这里要特别点一下Cloudflare 的 bots management 模式里有“严格”一档很多网站开着反爬策略来拦截自动化流量。AI Agent 浏览器如果以正常浏览器指纹运行又表现出高度自动化特征很容易被 Bot 防护系统识别出来。反过来看Cloudflare 同时做 Kitesurf 和 Bot 管理意味着它可以定义“合法 Agent”的识别标准。未来可能出现针对可验证 Agent 的通行机制比如 Agent 浏览器带上数字签名目标站点知道“这是可信 Agent放行”普通人伪造不了。这个方向如果真的落地会比现在的验证码对抗优雅得多。5. 本地部署与服务启动5.1 部署前检查清单由于目前官方还未给出完整的 Kitesurf 一键部署文档这里给一套通用检查清单具体版本号以仓库 README 为准。Linux 服务器建议 Ubuntu 22.04 或 Debian 12CPU 4 核以上内存 8GB 以上磁盘 20GB 以上浏览器内核和依赖会占一定空间开放一个本地端口比如 8080 或 7860用于访问管理界面或 API安装 Docker 和 Docker Compose方便隔离运行确认是否需要在宿主机上安装浏览器依赖如果以独立进程运行需要系统级的 Chromium/Firefox 依赖库。5.2 通过 Docker 启动通用模板容器方式是最稳妥的启动方案。假设项目仓库提供 Docker 镜像典型的启动命令如下# 拉取镜像镜像名与版本以官方仓库为准 docker pull cloudflare/kitesurf:latest # 启动服务 docker run -d \ --name kitesurf \ -p 8080:8080 \ -v /data/kitesurf:/data \ cloudflare/kitesurf:latest参数说明-p 8080:8080把容器内 8080 端口映射到宿主机-v /data/kitesurf:/data挂载数据目录用于保存会话、日志和浏览器快照--name kitesurf容器命名方便后续查看日志和启停。启动后在浏览器访问http://127.0.0.1:8080。如果能看到管理页面或健康检查接口说明服务已启动。如果 8080 端口被占用就换一个宿主端口docker run -d \ --name kitesurf \ -p 18080:8080 \ -v /data/kitesurf:/data \ cloudflare/kitesurf:latest5.3 通过命令行启动通用模板如果你是源码方式安装通常需要先安装 Python 或 Node 依赖。以一个假设的 Python 服务为例# 创建虚拟环境 python3 -m venv .venv source .venv/bin/activate # 安装依赖 pip install -r requirements.txt # 启动服务 python -m kitesurf --host 127.0.0.1 --port 8080如果项目是 Node 版本命令可能是npm install npm run start -- --port 8080具体入口以仓库里的package.json或README为准。首次启动如果报缺系统库比如libnss3、libatk这类浏览器依赖需要先补齐apt-get update apt-get install -y libnss3 libatk1.0-0 libatk-bridge2.0-0 libcups2 libdrm2 libxkbcommon0 libatspi2.0-0 libxcomposite1 libxdamage1 libxfixes3 libxrandr2 libgbm1 libpango-1.0-0 libcairo25.4 验证服务状态不管用哪种方式启动都要做三件事看启动日志里是否有“listening on”或“started”字样请求健康检查接口比如/health或/api/health提交一个最简单的任务确认浏览器实例能真正创建。健康检查示例curl http://127.0.0.1:8080/health如果返回 JSON 或 HTTP 200说明服务活着但不代表浏览器实例可用。还要继续做功能测试。6. 功能测试与效果验证6.1 测试一让 Agent 打开网页并提取信息这是一个最基础的冒烟测试目标确认浏览器能正常创建、导航并返回页面数据。输入示例{ task: 打开 https://example.com提取页面标题和第一段文字 }操作步骤通过 API 或管理界面提交上述任务观察任务状态从 pending 变为 running等待 Agent 执行完成查看任务结果确认是否包含页面标题和正文片段查看浏览器截图或 DOM 快照确认 Agent 确实访问过目标页面。判断标准任务状态正常结束返回内容与页面实际内容一致。常见失败任务一直 pending说明浏览器实例没有创建成功检查资源占用和日志返回内容为空可能是页面加载超时或 Agent 没有正确解析 DOM报 SSL 错误检查目标站点证书和依赖是否完整。6.2 测试二多步任务执行真正的 Agent 浏览器必须能处理多步任务连续执行“打开列表页 - 点击第一条详情 - 提取内容 - 返回列表 - 打开第二条”。输入示例{ task: 在 https://news.ycombinator.com/ 上获取前5个帖子的标题和链接 }判断标准Agent 能正确完成 5 次独立的信息提取任务结果包含 5 条完整记录执行日志里能看到“点击链接 - 等待页面加载 - 提取内容 - 返回列表”的完整动作链。如果这个测试失败优先确认页面元素是否被正确结构化等待页面加载的策略是否合理Agent 是否因为页面结构复杂而“迷路”。6.3 测试三登录态与会话保持很多真实场景需要登录后才能执行任务。测试时准备一个测试账号验证 Agent 能否登录并把登录态保持到后续步骤。操作要点先让 Agent 执行登录任务输入测试账号密码登录成功后提交另一个任务在同一会话里访问需要登录的页面确认第二个任务能正常获取数据而不是跳回登录页。边界提醒测试账号不要使用真实生产账号不要把密码硬编码在 Prompt 里应通过凭证管理模块注入如果目标站点有风控不要尝试绕过验证码。判断标准第一个任务登录完成后后续任务无需重新登录即可访问受保护页面。6.4 测试四页面截图与输出检查Agent 浏览器另一个重要能力是“把执行过程的中间状态留存下来”。测试一个包含截图的流程确认页面完全加载后再截图而不是白屏截图文件名和任务 ID 能对应上截图可以按任务维度归档方便后续审计。这类功能对开发调试很有价值。如果 Agent 最终结果错误开发者可以通过截图快速定位是在哪一步开始跑偏的。6.5 测试五异常容错故意制造异常场景看 Agent 浏览器如何应对目标站点 500 错误页面加载超过 30 秒页面弹出alert()弹窗登录态过期。判断标准任务不会无限挂起错误信息能清楚指出失败原因具备重试机制的任务能自动恢复无法恢复时任务状态明确标记为 failed。7. 接口 API 与批量任务接入7.1 API 驱动方式Agent 浏览器只有可编程才有价值。按常规设计Kitesurf 至少应该提供两类接口任务提交接口接收任务描述返回任务 ID任务查询接口通过任务 ID 查询状态和结果。通用请求示例curl -X POST http://127.0.0.1:8080/api/tasks \ -H Content-Type: application/json \ -d { task: 打开 https://example.com提取页面标题, timeout: 60 }如果接口符合 RESTful 风格返回可能是{ task_id: task_8f3a2b9c1d, status: running }然后通过任务 ID 轮询curl http://127.0.0.1:8080/api/tasks/task_8f3a2b9c1d返回结果可能包含{ task_id: task_8f3a2b9c1d, status: completed, result: { title: Example Domain, content: This domain is for use in illustrative examples in documents. }, screenshot: /data/kitesurf/screenshots/task_8f3a2b9c1d.png }注意以上路径和字段是通用示例实际部署时以官方接口文档为准。7.2 Python 调用示例下面是通用的 Python 调用模板核心逻辑是提交任务、轮询状态、获取结果import time import requests BASE_URL http://127.0.0.1:8080 def submit_task(task_description: str) - str: resp requests.post( f{BASE_URL}/api/tasks, json{task: task_description, timeout: 60}, timeout30, ) resp.raise_for_status() return resp.json()[task_id] def wait_task(task_id: str, interval: int 3, max_retry: int 20): for _ in range(max_retry): resp requests.get(f{BASE_URL}/api/tasks/{task_id}, timeout10) data resp.json() if data[status] in (completed, failed): return data time.sleep(interval) return {status: timeout, task_id: task_id} if __name__ __main__: task_id submit_task(打开 https://example.com提取页面标题) print(task_id:, task_id) result wait_task(task_id) print(result)7.3 批量任务设计如果要在生产环境跑批量任务不要把几百个任务一次性并发提交很容易把宿主资源打爆。更稳妥的做法是引入任务队列控制并发数。建议结构{ queue: [ {task_id: 001, description: 获取页面A标题}, {task_id: 002, description: 获取页面B标题} ], concurrency: 2, retry: 3, timeout_per_task: 60 }调度逻辑从队列取任务并发数限制在 2 到 5 个根据 CPU 和内存动态调整任务失败时记录错误保留快照稍后重试重试时注意幂等性避免重复提交表单造成脏数据。7.4 批量任务中的失败重试批量场景下最怕的不是失败而是失败不重试、重试又重复执行。重试策略建议只重试“可恢复错误”比如超时、网络抖动不重试“业务错误”比如账号权限不足、表单校验失败每次重试记录次数超过阈值标记为 failed所有任务执行前后都输出结构化日志日志至少包含任务 ID、开始时间、结束时间、状态、错误信息。8. 资源占用与性能观察8.1 观察哪些指标浏览器类 Agent 运行时会重点消耗四类资源CPU页面渲染、JS 执行、DOM 解析内存每个浏览器标签页的渲染进程都要占内存磁盘截图、日志、浏览器 UserData 目录持续写入GPU如果启用视觉模型或页面离屏渲染时使用。建议观察命令# 实时查看容器资源占用 docker stats kitesurf # 查看进程级 CPU 和内存 top -p $(pgrep -f chromium | head -1) -o %CPU,%MEM如果长期观察应该用一个简单的 Python 脚本定时采集资源数据并落盘。8.2 性能影响因素并发任务数每多一个并发浏览器实例内存都会明显上涨页面复杂度重 JS 站点比静态页面占用高数倍截图频率每次截图都要处理图像磁盘和 GPU 压力更大是否加载图片如果 Agent 只解析 DOM可以禁用图片加载显著降低带宽和内存是否启用视觉模型启用后 GPU 占用会明显提升需要实测。8.3 降低占用的常用手段控制并发默认 1 个实例跑通流程后再加并发禁用图片、视频等非必要资源加载任务结束时主动关闭浏览器会话释放内存设置单任务超时时间避免异常任务长时间占资源使用无头模式减少渲染开销无头不一定更省但多数场景下有效。8.4 进程残留与端口冲突浏览器类服务最常见的坑是服务关了但浏览器子进程残留在后台继续占内存和端口。排查命令# 查看端口占用 lsof -i :8080 # 查看残留浏览器进程 ps aux | grep -E kitesurf|chromium|chrome | grep -v grep如果确认是残留进程按 PID 清理kill -9 pid9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面打不开端口被占用或服务未启动检查日志和端口监听状态更换端口或重启服务任务一直 pending浏览器实例创建失败 / 资源不足查看任务日志和容器状态释放内存减少并发重启服务Agent 无法打开目标网站网络不通或目标站反爬拦截curl 测试目标站看响应头检查网络策略、代理配置页面标题提取为空页面未加载完成 / DOM 结构特殊查看快照和截图调整等待策略改用页面内容提取登录态无法保持会话没有复用或 Cookie 未持久化检查任务是否使用同一会话指定会话 ID开启 Cookie 持久化批量任务卡住并发过高 / 单任务超时查看 CPU、内存和任务日志降低并发增加超时机制返回结果不稳定页面结构变化导致 Agent 定位失败对比多次执行截图使用更稳定的语义定位增加校验依赖安装失败缺少系统库 / Python 版本不对查看安装日志补齐系统依赖切换 Python 版本CUDA/GPU 相关报错模型需要 GPU 但环境没有nvidia-smi 检查驱动确认驱动版本或改用 CPU 模式API 调用返回 401鉴权配置错误检查请求头补齐 API Key 或 Token排查通用思路先看日志再查资源最后复现。不要上来就重启。日志里如果没有打出错误原因先调高日志级别把浏览器控制台日志、网络请求日志和 Agent 决策日志都打开。10. 最佳实践与合规建议10.1 工程化落地建议第一次接触时不要直接上生产。先搭最小实验环境按“打开页面 - 单步任务 - 多步任务 - 登录态 - 批量任务”的顺序逐步推进。每一步都记录任务描述、输入参数、输出结果、耗时、资源占用形成一份属于自己项目的基线数据。目录结构建议kitesurf/ ├── config/ # 配置文件 ├── inputs/ # 任务输入 ├── outputs/ # 任务结果 ├── logs/ # 运行日志 └── screenshots/ # 执行截图模型文件、输入素材、输出结果分目录管理是基本操作。日志和截图建议按天归档方便回溯。接口服务如果暴露在局域网或公网一定要加鉴权限制访问范围。可以使用 API Key、IP 白名单或先在内网测试环境跑通再考虑对外。10.2 合规与授权提醒每次部署 Agent 浏览器前都要确认清楚你是否有权访问目标网站目标网站的服务条款是否允许自动化操作涉及登录的账号是否经过授权涉及用户数据时是否做了脱敏和访问控制是否会存储 Cookie、Token 等敏感信息存储位置是否安全涉及人脸、声音、版权素材的自动化处理必须确认授权。不要用 Agent 浏览器批量抓取个人隐私信息也不要尝试绕过验证码或风控机制做灰黑产操作。10.3 发布前检查清单如果基于 Kitesurf 封装的产品要上线或商用建议过一遍任务失败时会不会把敏感数据打到日志里浏览器快照是否被无权限人员访问Agent 是否可能被 Prompt 注入诱导执行危险操作批量任务是否有最大并发限制和熔断机制是否保留完整操作审计记录是否在用户协议中明确告知数据采集和处理范围。11. 总结与下一步Kitesurf 这个项目最有意思的点不是“AI 能开浏览器”而是 Cloudflare 试图给 AI Agent 造一层基础设施。它把浏览器从人的工具变成程序员的运行时把会话管理、权限隔离、任务可观测性这些能力下沉到浏览器层方向是对的。如果你打算尝试先验证三件事能否通过 API 提交一个最简单的页面信息提取任务Agent 能否在多步任务里保持稳定不中途卡死登录态能否跨任务保持。最容易踩的坑也集中在这三块任务提交了但不执行、多步任务到一半丢失上下文、登录态没保持导致后续任务全部失败。后续值得继续关注的方向是 Kitesurf 和 Cloudflare 自家 Bot 管理能力的联动。如果它能定义一套“可信 Agent”的访问标准行业里很多验证码对抗的土办法可能会被替代。这篇文章把部署、测试、API 接入和排错思路都过了一遍如果你正在做 Agent 工具链选型建议收藏备用等官方完整文档发布后对照着实测一遍。