AI personal agent真实互联网竞赛：从沙盒到实战的技术拆解

1. 一场把AI代理拉进真实互联网的竞赛，到底在比什么

第一次看到“The first ever competition of AI personal agents on the internet”这个标题时，我的第一反应不是“又一个AI比赛”，而是“终于有人把AI代理从沙盒里拽出来了”。过去两年，我们见过太多在受控环境里跑分的Agent评测：固定的网页、预设的API、干净的输入输出。但真实互联网不是这样的——它有验证码、有动态渲染、有反爬策略、有登录态过期、有页面结构随时改版。一个AI personal agent能不能在真实互联网上完成任务，和它在benchmark上拿多少分，完全是两回事。

这个竞赛的核心价值就在这里：它把“AI personal agent”这个还停留在概念阶段的东西，放到了一个有真实摩擦力的环境里。所谓personal agent，我理解就是那种能代表你个人去执行任务的AI代理——帮你订票、填表、比价、收集信息、操作后台。它和普通的chatbot最大的区别是：chatbot只输出文本，agent要输出动作，而且动作要在真实系统里生效。

适合谁来关注这个内容？三类人。第一类是正在做AI agent搭建的开发者，你需要知道真实环境下的失败模式长什么样。第二类是做自动化测试、RPA、爬虫的工程师，你会发现AI agent正在吃掉你们的一部分工作，但也在暴露新的问题。第三类是对AI应用落地感兴趣的产品和技术负责人，你需要判断这个方向现在到底能用到什么程度。

我下面会从竞赛的设计逻辑、AI personal agent的核心技术栈、真实互联网环境下的实操难点、以及我自己踩过的坑这几个角度，把这个标题背后的东西拆开讲。不是复述新闻，而是讲清楚一个从业者看到这件事时，脑子里应该转哪些念头。

2. 竞赛设计背后的逻辑：为什么“真实互联网”是分水岭

2.1 从沙盒评测到真实环境，差的不只是难度

先说清楚一个概念。AI agent的评测，业内大致分三代。

第一代是静态任务评测，比如给一个固定的网页快照，让agent提取信息或者点击某个按钮。这种评测的问题是，agent可以靠记忆和模式匹配过关，它不需要理解页面，只需要见过足够多的类似结构。

第二代是模拟环境评测，比如用Playwright起一个本地服务，页面是动态生成的，但网络是干净的，没有验证码，没有CDN拦截，没有登录风控。这种评测能测出agent的规划能力，但测不出它在真实摩擦下的鲁棒性。

第三代就是这次竞赛代表的真实互联网评测。页面是真的，网络是真的，反爬是真的，登录态是真的，甚至页面加载速度波动都是真的。这时候agent面对的不再是“能不能理解任务”，而是“能不能在不确定环境里持续完成任务”。

这个差别有多大？我举个例子。在模拟环境里，agent点击一个按钮，元素定位到了就成功了。在真实互联网上，你点击一个按钮，可能遇到：元素被广告遮挡、页面还没渲染完、点击触发了新标签页、点击后弹出了cookie同意框、点击后要求登录、点击后触发了人机验证。每一个分支都是一个独立的失败点，而agent必须在没有人工干预的情况下自己处理。

提示：如果你正在做agent开发，建议尽早把测试环境从本地mock切换到真实站点。哪怕只跑一个简单的信息采集任务，你也会发现失败率高得超出预期。

2.2 为什么是“personal agent”而不是“general agent”

标题里用的是personal agents，不是general agents。这个措辞很讲究。

General agent的目标是通用任务，什么都能干。但通用意味着没有边界，评测标准很难定，而且容易陷入“什么都能做一点，什么都做不好”的困境。Personal agent的目标是代表特定用户完成特定领域的任务，它有明确的用户上下文、偏好、权限边界。

这个定位带来的技术差异是巨大的。Personal agent需要处理的是：用户的登录态怎么安全地传给agent、用户的偏好怎么编码进决策、用户的隐私数据怎么在任务执行中不被泄露。这些问题在general agent里往往被忽略，但在personal agent里是核心。

我自己的经验是，做personal agent最难的不是任务规划，而是状态管理。用户今天登录了某个网站，agent记住了cookie，明天cookie过期了，agent能不能自己发现并提示用户重新登录？用户在一个任务中途改了主意，agent能不能中断当前流程并回滚？这些在demo里看不出来，但在真实使用中天天发生。

2.3 竞赛的评判维度，我猜会看什么

虽然具体规则我没有拿到，但基于这类竞赛的常见设计，评判维度大概率包括这几项：

这里面我最看重的是异常恢复。因为任务完成率可以通过反复重试来刷，但异常恢复能力是刷不出来的。一个agent在遇到登录墙时是直接失败，还是能识别出“需要用户介入”并给出清晰提示，这体现的是工程成熟度。

3. AI personal agent的核心技术栈拆解

3.1 感知层：怎么“看懂”一个真实网页

真实网页和实验室网页最大的区别是噪声。一个电商详情页，可能有30%的面积是广告、推荐、弹窗、悬浮按钮。agent如果把这些都当成有效信息，决策就会跑偏。

目前主流的感知方案有三种：

第一种是DOM解析。直接读HTML结构，找元素、找文本。优点是精确、快、便宜。缺点是遇到动态渲染就废了，而且DOM结构一变就失效。我试过用纯DOM方案跑一个新闻站点，第一天能跑，第二天站点改版，选择器全挂。

第二种是视觉理解。截图，然后用多模态模型理解页面。优点是抗改版，人能看到的东西它都能看到。缺点是慢、贵，而且对精细操作（比如点击一个很小的复选框）精度不够。

第三种是混合方案。先用DOM做粗定位，再用视觉做确认和兜底。这是目前我认为最实用的方案。具体做法是：DOM解析出候选元素列表，截图后让模型判断哪个元素对应任务目标，然后回到DOM里执行点击。这样既保留了DOM的精确性，又有了视觉的鲁棒性。

注意：混合方案的关键是“视觉只做判断，不做执行”。执行一定要回到DOM或者坐标点击，否则精度和可复现性都会出问题。

3.2 规划层：任务怎么拆成可执行的步骤

一个personal agent接到“帮我找一下这个月从北京到上海最便宜的高铁票”这个任务，它需要拆成：打开购票网站、输入出发地、输入目的地、选择日期范围、读取结果、比价、返回最优选项。

这个拆解过程，目前有两种主流做法。

一种是静态规划。提前把任务写成workflow，agent按固定步骤执行。优点是稳定、可控、便宜。缺点是只能处理预设任务，遇到变化就断。很多RPA工具就是这个思路。

另一种是动态规划。用LLM做任务分解，每一步根据当前页面状态决定下一步动作。优点是灵活，能处理没见过的任务。缺点是容易跑偏、token消耗大、不可预测。

我实际用下来，最靠谱的是分层规划：高层用LLM做任务分解，产出子目标列表；低层用规则或者小模型做具体动作选择。比如高层决定“现在需要选择日期”，低层就用固定逻辑去操作日期控件。这样既有灵活性，又不会在细节上失控。

这里有个经验：不要让LLM直接输出点击坐标或者CSS选择器。LLM对页面结构的理解是模糊的，它输出的选择器经常是错的。正确做法是让LLM输出“意图”，比如“点击搜索按钮”，然后由执行层去匹配具体元素。

3.3 执行层：动作怎么在真实页面上生效

执行层是最容易被低估的部分。很多人以为agent的核心是大脑，其实手脚同样重要。

真实页面上的动作执行，要处理这些问题：

• 元素定位：用选择器、文本、角色、位置多种方式组合定位，单一方式都不可靠。
• 等待策略：不能死等，也不能不等。我一般用“显式等待+轮询”的组合，先等关键元素出现，再等网络空闲。
• 动作确认：点击后要确认动作生效了，比如URL变了、出现了预期元素、或者出现了错误提示。
• 失败重试：单次失败要能重试，但重试要有上限，避免死循环。

我踩过的一个坑是：agent点击了一个按钮，页面确实跳转了，但跳转到了错误页面。agent没有校验跳转结果，继续在错误页面上执行后续步骤，最后输出了一堆垃圾数据。后来我加了一个每步后置校验，每个动作执行后都检查当前页面是否符合预期状态，不符合就回退重试。

3.4 记忆与状态：personal agent的命门

Personal agent和普通agent最大的区别是它要记住用户。记住什么？登录态、偏好、历史操作、常用地址、支付方式。

这些状态怎么存、怎么用、怎么保证安全，是personal agent的核心工程问题。

我的做法是分三层：

• 会话状态：当前任务的临时状态，比如“已经填了出发地，还没填目的地”。存在内存里，任务结束就丢。
• 用户状态：跨会话的持久状态，比如登录cookie、用户偏好。加密存储，有有效期，敏感操作要二次确认。
• 任务历史：完成过的任务记录，用于优化后续规划。脱敏后存储，定期清理。

提示：登录态的管理是personal agent最容易出安全问题的地方。我的建议是，能用OAuth就用OAuth，不要让agent直接持有用户密码。如果必须持有cookie，一定要加密，并且设置比用户手动登录更短的有效期。

4. 真实互联网环境下的实操难点与应对

4.1 登录墙：agent遇到的第一个真实障碍

几乎所有的真实任务都需要登录。而登录这件事，对agent来说是个大麻烦。

首先是登录方式多样：账号密码、手机验证码、扫码、第三方OAuth、生物识别。账号密码相对好处理，验证码和扫码就需要用户介入。

其次是登录态维护：cookie会过期，token会刷新，多设备登录会互踢。agent需要能检测到登录失效，并且知道什么时候该提示用户。

我的处理策略是：能复用用户浏览器会话就复用，不能复用就走OAuth，实在不行才让用户输入凭据。复用会话的好处是，用户已经在浏览器里登录了，agent直接接管这个会话，不需要处理登录流程。这在技术上可以通过浏览器扩展或者远程调试协议实现。

如果必须让agent自己登录，我会把登录流程单独封装成一个模块，和任务执行解耦。登录模块负责检测登录态、执行登录、处理验证码提示。任务模块只关心“我现在是登录状态吗”，不关心怎么登录的。

4.2 动态渲染与反爬：页面不是静态的

现代前端框架让页面变得极其动态。你打开一个页面，HTML里可能什么都没有，所有内容都是JS渲染出来的。agent如果只读初始HTML，会读到一片空白。

应对动态渲染，核心是等待正确的时机。我的做法是：

1. 等待DOMContentLoaded，确保基础结构有了。
2. 等待网络空闲，确保主要请求完成了。
3. 等待目标元素出现，确保要操作的东西渲染出来了。
4. 如果目标元素一直不出现，截图看看是不是被反爬拦截了。

反爬是另一个问题。有些站点会检测自动化工具，返回假页面或者直接封禁。应对方式包括：使用真实浏览器指纹、控制请求频率、模拟人类操作节奏。但我要说清楚，这些手段要在合法合规的前提下使用，尊重站点的服务条款。

4.3 异常处理：真实环境没有“正常路径”

在实验室里，agent走的是happy path。在真实互联网上，happy path是少数，大部分时间在处理异常。

我整理过一份常见异常清单，这里分享一部分：

这份清单我建议每个做agent的人都维护一份自己的版本，因为不同站点、不同任务遇到的异常是不一样的。

4.4 成本控制：token不是免费的

真实互联网任务比实验室任务消耗大得多。因为页面复杂、步骤多、异常多，每一步都要调模型，token消耗很容易失控。

我做过一个粗略测算：一个中等复杂度的信息采集任务，如果每步都调GPT-4级别的模型，大概要消耗5万到10万token。如果任务失败重试，消耗翻倍。这个成本在demo阶段可以接受，但规模化就撑不住。

控制成本的手段有几个：

• 分层用模型：简单判断用小模型，复杂规划用大模型。
• 缓存中间结果：同一个页面多次分析，结果可以缓存。
• 减少无效步骤：优化规划逻辑，避免绕路。
• 设置预算上限：每个任务设定token上限，超了就停。

提示：我见过很多agent项目在demo阶段很惊艳，一上量就崩，核心原因就是成本模型没算清楚。建议在开发早期就把成本监控做进去。

5. 从竞赛看AI agent的落地边界

5.1 现在能做什么，不能做什么

基于我对这类竞赛和实际项目的观察，AI personal agent目前的能力边界大致是这样的：

能稳定做的：信息采集、表单填写、简单比价、内容监控、定期报告。这些任务步骤明确、异常可控、对实时性要求不高。

能做但不够稳的：多步骤跨站点任务、需要登录的复杂操作、涉及支付的流程。这些任务异常分支多，需要较多人工兜底。

基本做不了的：需要人类判断的模糊任务、涉及敏感权限的操作、对抗性强的场景。这些要么技术上不成熟，要么风险太高。

这个边界不是固定的，随着模型能力和工程手段的进步在移动。但作为从业者，要清楚当前的位置，不要过度承诺。

5.2 对开发者的启示

如果你在做AI agent相关的东西，这次竞赛传递了几个信号：

第一，真实环境能力是下一个竞争点。benchmark分数已经不够看了，能不能在真实互联网上跑通任务，才是分水岭。

第二，工程能力比模型能力更重要。模型大家都能用，但怎么处理登录、怎么应对异常、怎么控制成本，这些工程细节决定了产品能不能用。

第三，personal agent的隐私和安全是硬约束。用户把登录态交给你，你就承担了责任。这块做不好，产品走不远。

5.3 我自己的踩坑记录

最后分享几个我在做agent过程中踩过的坑，都是真实教训。

第一个坑：过度依赖单一模型。早期我把所有决策都交给一个大模型，结果模型一波动，整个agent就崩。后来改成多模型冗余，关键决策用两个模型交叉验证，稳定性好了很多。

第二个坑：忽略页面加载时序。有次agent在页面还没渲染完就执行操作，点了个空。后来加了严格的等待策略，但等待又不能太长，否则效率低。这个平衡点要靠实测找。

第三个坑：没有做动作回滚。agent执行到一半失败了，前面的操作已经生效，比如已经提交了表单。后来我加了事务性设计，关键操作要么全做要么全不做，避免留下脏状态。

第四个坑：低估了验证码的频率。我以为验证码是偶发的，实际跑下来发现某些站点几乎每次都会触发。后来把验证码处理做成了标准流程，检测到就暂停并通知用户，而不是反复重试。

这些坑说起来简单，但每一个都是花了不少时间才填上的。AI personal agent这个方向，技术上限很高，但工程下限很低。能不能做成，往往不取决于你用了多强的模型，而取决于你有没有把那些琐碎的、不性感的工程问题解决好。