先说说我为什么会碰这个问题。上个月我在调一个基于LangChain的资讯搜集Agent，目标是让它自动抓取几个行业网站的更新并生成摘要。结果跑了不到一天，Agent要么拿到一堆空壳HTML，要么被WAF拦在门外，要么面对满屏的登录弹窗直接“思考失败”。那几天我改提示词、调超时参数、换浏览器模拟，越调越觉得问题根本不在Agent这边，而在网站本身——很多网站压根没打算让程序好好读它。
后来我索性换了个思路：抛开“爬虫对抗”的旧观念，直接站在网站所有者的角度，去研究“怎样构建一个Agent-friendly的网站”。这个方向反而想通了很多事。今天这篇就把我这段时间的实践整理出来，从Agent怎么“看”网站讲起，到具体改造手段，再到验证方法，全程都是可复用的实操内容。
1. Agent到底怎么“看”你的网站
很多站长对“Agent访问网站”的理解还停留在“爬虫抓网页”的层面。实际上大模型驱动的Agent访问网站的方式，和你我打开浏览器的方式有着本质区别。搞清楚这个区别，才谈得上做Agent-friendly改造。
1.1 从一次真实抓取看Agent的浏览路径
去年年底我帮朋友调试一个房产信息Agent，目标是从某个楼盘列表页提取在售房源。Agent的调用链大概是这样的：先请求首页，解析出各个楼盘的详情链接，再逐个请求详情页，把正文内容交给大模型做结构化提取。听起来很常规对吧？但实际跑起来几乎每一步都在翻车。
首页拿下来之后，Agent拿到的是一个只有几行JS脚本的骨架页面，真正的房源列表是前端通过接口异步渲染的。Agent去找<a>标签，什么也没找到。这就是最典型的问题：Agent不会像人一样自动执行JavaScript并等待页面渲染完。市面上虽然有Playwright这类浏览器自动化工具，但让Agent每次都驱动一个完整浏览器，成本高、速度慢，而且稳定性很差。
第二次尝试我改用了带渲染的抓取方案，用Playwright无头浏览器去打开页面。列表倒是出来了，但页面上有大量的“委托代理”“降价通知”等悬浮组件，加上几十个图片懒加载占位符，整个DOM文本被截断到十几万字符。Agent光解析这个页面就消耗了大量token，而且有效信息被淹没在噪声里。那次任务最后的结果是：一个小时的调用，花了大概3美元的API费用，提取出来的房源信息还有三处明显错误。
1.2 Agent的“阅读”习惯：线性、片段化、无视觉
人类浏览网页时是视觉驱动的，我们扫一眼就能忽略广告、跳过导航栏、直接定位正文区域。但Agent不是这样，它拿到的是经过处理的文本流——要么是curl抓到的原始HTML，要么是经过程序抽取后的正文片段。它的处理方式是线性的，更像是在读一本没有目录、没有排版、插图全变成alt文本的书。
这就带来了几个Agent认知网站时的显著特征：
- 极其依赖文本结构：标题层级、段落关系、链接锚文本，这些在人类眼里只是排版，在Agent眼里是理解页面语义的路标。
- 对噪声极不敏感，但会被噪声干扰：网页里的广告、推荐模块、页脚友情链接，人类会自动忽略，Agent却会把这些内容当正文处理。
- token预算是个硬约束：一个页面5000字还是50000字，对Agent来说不只是速度快慢的问题，直接关系到任务能不能跑通。Token超过上下文窗口，Agent会丢前面的内容，最后给你一个莫名其妙的总结。
这里要强调一个很容易被忽略的点：Agent的上下文窗口不是无限的。即便最新的模型支持超长上下文，长度增加会显著影响推理质量和响应速度，而且费用是线性上升的。所以Agent-friendly的核心目标之一，就是用尽可能少的token传递尽可能多的有效信息。
1.3 为什么“对爬虫友好”不等于“对Agent友好”
传统的爬虫友好通常指：robots.txt写得清楚、静态页面可抓取、链接可追踪。这套规则对搜索引擎爬虫够用，对AI Agent却远远不够。搜索引擎爬虫拿回页面之后，是由算法做关键词匹配和链接分析；而Agent拿回页面之后，是要让大模型“读懂”页面里的业务逻辑和实体关系。
举个例子，传统SEO要求每个页面有唯一的<title>和<meta description>，这对搜索引擎很重要；但对Agent来说，更重要的是页面里有没有清晰的实体标注，比如商品价格、库存状态、发货时间这些关键字段，能不能直接被识别出来。如果这些信息只存在于图片里，或者只靠CSS样式暗示（比如红色表示售罄），搜索引擎可能还勉强过得去，Agent就彻底无能为力了。
另外还有一层差异：搜索引擎爬虫对内容重复的容忍度较高，大不了给你降权；Agent面对重复内容、空转链接、死循环跳转，会直接判定这个网站“不值得信任”，从而放弃整个站点。这意味着Agent-friendly不仅要求“能被抓”，还要求“逻辑清晰、无歧义、可验证”。
2. 网站对Agent不友好的典型症状
在动手改造之前，先学会诊断。这一节列出的症状，我不止一次在实际项目里遇到过。如果你发现自己的站可以被人正常访问，但Agent任务总是失败，大概率是下面这些原因之一。
2.1 “空壳HTML”陷阱
症状：curl拿到的HTML和浏览器里看到的页面完全两回事。页面内容全部由JavaScript动态渲染，源码里只有一个root节点和一堆script标签。
这种站对Agent来说等于不存在。我之前测过一个建站工具生成的营销页面，HTML源码只有12KB，但浏览器渲染出来却有完整的图文排版。Agent去访问的时候，除了一个加载动画的div，什么都提取不到。
要诊断这个问题很简单：用curl -L访问一下页面，把保存下来的HTML打开看看有多少实际内容。如果文本量很小，大概率就是壳。
2.2 登录墙与半登录状态
症状：页面本身不需要登录就能看正文，但一旦被识别为自动化访问，就跳转到登录页或要求输入验证码。这里的“自动化识别”往往不是看UA，而是看请求频率和指纹特征。
更隐蔽的一种是“半登录状态”——部分内容可见，部分内容要求登录，比如列表页可访问但详情页被拦截，或者首页可打开但点击搜索后需要验证。Agent的任务链路一走深，就会断在半路。我在做数据采集类Agent时，经常需要为这种情况专门写“登录预处理”逻辑，但如果网站本身能提供免登录的只读接口，这个问题根本不存在。
2.3 验证码与人机识别
症状：弹出滑块验证、图片点选、或者要求开启JavaScript再访问。Cloudflare的“检查你的浏览器”页面是重灾区。
对Agent来说，滑块验证基本无解，这已经属于对抗范畴了。哪怕有一些打码平台能过，那也不是构建Agent-friendly网站该考虑的方向。反过来，如果网站能对低风险请求直接放行，只在真正可疑的高频请求时才发起验证，Agent就能顺畅访问。
2.4 链接不可预测与内容碎片化
症状：列表页到详情页的链接是通过onclick事件动态生成的，或者页面使用无限滚动加载，没有静态的分页链接。Agent无法从HTML里找到可追踪的URL，自然无法深入爬取。
更麻烦的是内容碎片化，一篇完整的文章被拆成5页分页加载，每一页只有开头部分，要看完整内容必须点击“下一页”。人类不觉得这有什么问题，Agent却会因此无法理解全文，进而产生错误判断。
2.5 语义信息缺失
症状：页面文本里有“库存紧张”“已售罄”“限时优惠”这些状态，但没有对应的结构化标记；价格直接写成“起价999”，没有货币单位和有效期；产品参数用图标和图片展示，完全没有文本描述。
这类页面人类看一眼就懂了，Agent却无法可靠地提取。AI Agent对文本的依赖远超你对视觉的依赖，所有只靠视觉传达的信息，在Agent眼里都是缺失的。
3. 一次完整的Agent友好化改造实操
理论讲完，上实践。这一节我以东哥笔记这个内容站点为例，完整记录了一次Agent友好化改造的过程。改造前这个站的Agent抓取成功率不到30%，改造后稳定在90%以上，单次抓取的token消耗还降了60%。
3.1 第一步：用robo.txt和元数据亮明身份
很多站长觉得robots.txt只是用来防搜索引擎的，随便写两句就行。实际上对Agent来说，robots.txt是它的第一道导航，它需要在这里明确知道“你能去哪、不能去哪、多久来一次合适”。
我的建议是至少包含这三块内容：
User-agent: * Allow: / Disallow: /admin/ Disallow: /cart/ Disallow: /search?* User-agent: GPTBot Allow: / Disallow: /draft/ User-agent: CCBot Allow: /public/第一块给普通爬虫和未识别Agent，明确排除管理后台、购物车、搜索结果页这些无意义的动态页面。第二、三块是给特定厂商的AI爬虫单独开“白名单”，比如OpenAI的GPTBot和Common Crawl的CCBot，这些爬虫遵守robot规范比较自觉。如果哪天你不想被某个AI厂商抓取，可以单独在它的规则下写Disallow: /。
注意一个细节：Disallow: /search?*这一行很多人不会写。搜索结果页是典型的无限URL空间，对Agent是巨大的资源黑洞，一个?page=1和?page=2给Agent返回的内容几乎一样，却在浪费它的预算。把它们屏蔽掉，对你没有任何损失。
3.2 第二步：用sitemap和结构化数据搭建内容骨架
接下来是sitemap。这里不是指传统XML格式的sitemap.xml——那个也重要，但Agent更需要注意的是sitemap里的URL到底稳不稳定。我的经验是：
- URL必须永久有效，不要频繁变动路径；
- 每个URL对应的内容要有明确主体，不要一个URL在PC端显示A内容、在移动端显示B内容；
- 如果内容有版本更新，最好保留固定的“最新版”URL，而不是把版本号写进路径里。
接着是结构化数据，我强烈建议从JSON-LD格式入手。原因很简单：JSON-LD可以放在<head>里，不干扰正文文本，Agent解析起来也比Microdata格式更直接。这是一个标准的Article结构化数据示例：
{ "@context": "https://schema.org", "@type": "Article", "headline": "Agent-friendly网站改造指南", "description": "面向AI Agent的网站架构设计与改造实操", "datePublished": "2025-03-10", "dateModified": "2025-03-18", "author": { "@type": "Person", "name": "东哥" }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/guides/agent-friendly-website" } }这里有个容易被忽视的地方：dateModified不要漏。Agent有时候需要判断信息的新旧，如果你的文章实际上更新过但没有更新这个字段，Agent拿到的就是过时数据。我见过不少站的归档文章全是创建日期，没有任何修改标记，这类信息对做时效性判断的Agent来说等于缺失。
3.3 第三步：正文标记与语义化HTML
真正决定Agent体验的，是正文区域的HTML结构。很多站为了排版好看，把整个页面都用<div>套<div>，正文藏在一层层容器里。对Agent来说，它需要靠标签语义来确定什么才是正文。
我的建议顺序是：
- 用
<article>包裹正文，用<main>包裹当前页面的独有内容； - 标题层级严格按
h1→h2→h3一级级用，不要跳级，不要用h3当正文内的大标题； - 列表项用
<ul>或<ol>，不要用一串<div>加行内符号模拟列表； - 图片必须写
alt文本，这个文本是Agent理解图片内容的唯一通道； - 表格用
<table>加<thead>、<th>标签，不要把表格结构拆成浮动块。
一个硬性要求：关键信息必须同时以文本形式存在。价格、日期、数量、状态这些，绝对不要只出现在图片里。
3.4 第四步：合并碎片，缩短正文路径
然后是我这次改造收益最大的一步：把分页文章合并为单页。我原来有几篇长文章分了三页，改造后合成一页。表面上看单页变大了，但对Agent来说这反而是缩短路径。为什么？Agent不用再走“点击下一页→解析链接→发起新请求→等待响应→提取下一页正文”这条长链路。链路越长，失败概率越高。
合并完之后，我还做了一件事：给每篇文章的正文添加了一个id="main-content"的锚点，并在sitemap里用#main-content作为正文地址。当然标准爬虫不会管锚点，但这个锚点给了我一个自己写Agent解析器的借口——直接定位、直接提取，不用再猜哪部分是正文。
3.5 第五步：提供Agent专用的API入口
如果条件允许，这是最推荐的方案：给网站加一个只读的、返回纯文本或JSON的API端点。你不用做完整的RESTful接口，只需要一个返回规范数据的“阅读端点”就够了。比如：
GET /api/article/slug返回体可以设计成这样：
{ "title": "Agent-friendly网站改造指南", "updatedAt": "2025-03-18", "content": "……全文纯文本……", "tags": ["AI Agent", "网站架构"], "relatedLinks": ["/guides/ai-agent-intro"] }一次请求，所有信息都齐了。Agent不用解析HTML，不用跟CSS和广告模块斗争，整个流程又稳又快。这个API可以不对外宣传，只要在robots.txt里Allow这个路径就行。我改造东哥笔记的时候就加了这样一个端点，从那以后我的Agent任务的成功率直接从72%跳到了95%。
3.6 改造前后的数据对比
贴一组改造前后的实测数据，方便你做参考。测试场景是让同一个Agent收集20篇文章的信息，每篇包括标题、发布时间、正文前200字和标签。
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 请求总次数 | 86 | 41 |
| 单篇平均token消耗 | 8900 | 3400 |
| 任务完成率 | 28% | 94% |
| 平均耗时 | 12分钟 | 5分钟 |
| 信息准确率 | 82% | 99% |
token消耗一下子降了60%以上，这就是结构化数据和API入口的威力。对做AI应用的人来说，这个差距直接换算成API成本，是实实在在的钱。
4. 如何科学验证你的网站是否Agent-friendly
改造完了不能拍脑袋说“应该可以了”，要用一套标准化流程去验证。下面是我现在每次改完一个站都会跑的测试清单。
4.1 用cURL模拟Agent的首次访问
最简单的验证方式是先模拟Agent视角的“第一眼”。打开终端：
curl -s -L -A "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)" \ -o /tmp/dongge.html \ https://example.com/guides/agent-friendly-website然后统计这个文件里的正文文本量：
python3 -c " from bs4 import BeautifulSoup html = open('/tmp/dongge.html').read() soup = BeautifulSoup(html, 'html.parser') for tag in soup(['script', 'style', 'nav', 'footer']): tag.decompose() print(len(soup.get_text(strip=True))) "如果这个数字小于1000，而页面本身应该有3000字以上，说明页面还有内容被JS遮着，或者正文被隐藏了。继续查。
注意-A参数里带了GPTBot的UA。很多网站对不同的UA返回不同的页面版本，有的甚至会因为识别到GPTBot而返回404。所以如果你想验证“真实用户视角下的可抓取性”，可以不带UA参数再试一次。两个结果差异太大，说明站内做了UA区分，这本身就是一个需要注意的信号。
4.2 验证结构化数据的完整性
JSON-LD写没写、写对了没有，有一个快速校验办法——用Google的结构化数据测试工具跑一遍页面URL。它会告诉你哪些字段缺失、哪些类型定义错误。这个工具的校验逻辑比较严格，比你自己肉眼检查靠谱得多。
另外可以写个简单的脚本，抓下页面<head>区域里的JSON-LD块，检查@type和核心字段：
python3 -c " import json, re, urllib.request html = urllib.request.urlopen('https://example.com').read().decode() for match in re.finditer(r'<script[^>]*application/ld\+json[^>]*>(.*?)</script>', html, re.S): data = json.loads(match.group(1)) print(data.get('@type'), data.get('headline'), data.get('dateModified')) "跑一遍能很直观地看到页面到底暴露了多少结构信息。如果输出为空，说明你的结构化数据代码放错位置或者格式有问题。
4.3 用一个真实Agent任务做端到端测试
cURL验证的是“能被抓”，端到端测试验证的是“能被读懂”。我的做法很简单：写一个小Agent，让它访问网站首页，找出最新的一篇文章，提取标题和正文第一段，然后让大模型判断“这个页面是否正常加载了内容”。走一遍完整链路。
from openai import OpenAI import requests from bs4 import BeautifulSoup client = OpenAI() # 1. 抓首页 resp = requests.get("https://example.com") soup = BeautifulSoup(resp.text, "html.parser") # 2. 找出第一条文章链接 first_link = soup.select_one("article a") or soup.select_one("h2 a") if not first_link: print("FAIL: 首页没有定位到文章链接") else: article_url = first_link["href"] print("OK: 找到文章链接 ->", article_url) # 3. 提取文章内容 article_resp = requests.get(article_url) article_soup = BeautifulSoup(article_resp.text, "html.parser") article_body = article_soup.select_one("article") text = article_body.get_text(separator="\n", strip=True)[:500] # 4. 交给大模型做语义完整性判断 response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一个网页质量审查员。判断给定的文本是否是一篇完整文章的起始部分，回复OK或FAIL以及原因。"}, {"role": "user", "content": f"文章标题: {article_soup.title.string}\n正文开头:\n{text}"} ], ) print(response.choices[0].message.content)这个测试脚本有一个很明显的优势：它不是检查“代码有没有”，而是检查“Agent实际跑任务能不能成”。最怕的情况就是页面在cURL验证的时候看起来没问题，一上真实Agent就被反爬策略拦住。端到端测试可以把这个情况暴露出来。
4.4 量化token消耗与成功率曲线
最后我强烈建议你把Agent每次访问页面的token消耗记录下来，做一个成本看板。数据不用多精细，统计下面四个值就够了：
- 单次访问平均token数（过高说明页面内容太杂）
- 任务成功率（低于80%说明站内链路有问题）
- 平均任务耗时（过长说明页面响应慢，或者需要多次跳转）
- 失败任务的重试次数（次数多大概率是被拦截）
我自己留了一套脚本，每周跑一次，把数据记进一个SQLite库，自动生成趋势曲线。改造完之后观察两周，Token曲线明显下降、成功率稳定在90%以上，基本可以宣告Agent-friendly改造达标。
5. 让Agent“愿意来”的运维细节
架构层面的改造做完之后，还有几个运维细节。这些细节不会直接决定“能不能抓”，但会显著影响Agent对你的网站的信赖程度和使用频率。
5.1 响应速度与稳定性
Agent的调用链里有一个隐形指标叫“超时预算”。我这个Agent项目设置的超时是10秒，超过这个时间直接放弃并切换下一个源站。很多站不是被识别为机器人封的，而是响应太慢被Agent主动放弃的。
对Agent来说，稳定比什么都重要。偶尔502可以容忍，频繁的5xx状态码会让Agent调用方直接把你拉进黑名单。最好保证至少99%的请求在3秒内返回。如果你用了类似Nginx的服务，可以看下access log里的响应时间分布，一目了然。
5.2 清晰的限流策略
有些站长为了保护服务器，遇到密集请求直接封IP。这个策略对搜索引擎还好，对Agent非常不友好，因为Agent的出口IP往往是一整段动态IP，封完一个它换一个继续打，最后你损失的是所有Agent的访问能力。
更好的策略是返回HTTP状态码限流，而不是封禁。比如对一个来源IP在一分钟内超过20次请求时，返回429状态码，并附上Retry-After头。Agent调用方看到429会主动退避重试，这个逻辑是标准行为。一次性封IP反而会引发更多无意义的重试，两边都受罪。
5.3 提供人类可读的联系方式
最后这个小细节可能你觉得无厘头，但我认为非常重要：在网站底部放一个真实可用的联系邮箱。你开发或者运营一个Agent应用时，如果它的目标源站出了问题——比如页面结构变了、数据不更新了，你作为开发者第一反应是什么？是找联系方式去沟通。如果网站没有联系方式，只能靠猜和试，效率极低。有一个清晰的联系入口，意味着你给了Agent开发者一个和你协商的空间，这对维持长期合作关系极其重要。
5.4 关注主流AI爬虫的更新动态
OpenAI、Google、Common Crawl这些机构会不定期更新他们爬虫的UA和访问策略。比如GPTBot的UA字符串可能会调整，或者新增了新的爬虫类型。我在项目的requests模块里专门维护了一个“知名AI爬虫UA”的字符串列表，定期更新。如果你在服务端做了UA识别，也建议你持续关注这些更新，别把Agent的UA认成普通爬虫给误伤了。
6. 从“防爬”思维转向“共生”思维
回头看我自己的经历，这个项目真正让我想明白的，不是“怎么让Agent抓我的网站”，而是整个思维方式的转变。
过去做网站防爬，核心思路是“怎么区分人和机器，然后把机器挡在外面”。但AI Agent时代，机器本身就是你的用户。一个Agent在你的网站上顺畅地获取信息，意味着你的内容正在被整合进某个AI产品的答案里，这对内容方来说其实是曝光和流量。与其花力气去“防”，不如把一部分资源花在“友好化”上。
这中间有一个平衡要拿捏：不想被恶意爬虫抓走的数据，还是该做权限控制；但面向公开内容的区域，让Agent少走弯路、低消耗地获取信息，是一种双赢。
我现在的做法是：管理后台、个人中心这类需要身份认证的区域，保持现有的防护逻辑不动；对公开的正文内容，建一条只读的、稳定的、纯文本的通道，专门给Agent使用。这条通道既减少了对服务器资源的消耗，也提升了Agent侧的体验。
如果你也正在被Agent抓取问题折腾，我的建议是别急着上更高级的反爬技术，先回头看看自己的网站对Agent是不是足够友好。就从一个cURL测试开始，看看你的正文能不能在没有浏览器的情况下被完整读取。能读，是一切合作的基础；不能读，那你再牛的提示词工程也救不了。
改造完之后，我的Agent任务成功率从28%涨到了94%，token成本下降了六成。这个收益让我确信了一件事：在AI Agent正在成为重要流量入口的当下，给你的网站做Agent-friendly改造，是性价比最高的一笔基础设施投资。
