AI Agent技能协议：MCP标准与skills命令原理详解
2026/9/9 10:27:00
1. 为什么要手写XPath：从实际场景说起
做Web自动化和爬虫的同学，大概率都经历过这种尴尬时刻：在浏览器里用XPath Helper或DevTools右键“Copy XPath”复制出来的路径，长到能把人逼疯——/html/body/div[3]/div[2]/div[1]/div[2]/div[3]/div[2]/div[2]/div[1]/div[1]/h3/a，这玩意儿在上线后页面稍有改动就必挂无疑。而且换个环境、换套测试数据，可能就定位不到了。但如果你能看懂原理、自己手写XPath，就能写出短小精悍、容错率高的定位表达式，页面加个div、改个class层级，你的脚本照样稳如磐石。
我自己在这条路上踩过不少坑。最开始写爬虫和自动化测试脚本，全靠录屏工具自动生成的XPath来定位，结果就是“今天能用，明天就废”，维护成本高得让人崩溃。后来花了时间系统梳理了XPath语法，才逐渐养成手写路径的习惯——这不仅是一个技术动作，更是一种思维方式：你会开始主动分析页面的层级结构、元素的语义特征，而不是被动接受工具给出的冗余结果。
2. XPath基本语法：先把这几个节点概念吃透
2.1 节点、路径和轴：XPath的三大基石
XPath，全称XML Path Language，说白了就是用一种路径表达式在XML/HTML文档中“按图索骥”找节点的语言。既然是路径，就要先搞清楚地图上有什么。
先看一个最常见的HTML片段：
<html> <body> <div class="content"> <h3>这里是标题</h3> <a href="/article/123">点击查看文章</a> </div> <div class="footer"> <span>版权信息</span> </div> </body> </html>在这个结构里，XPath把每个标签都看作一个节点。节点之间的关系主要有三种：父节点（上层的直接包含者）、子节点（下层直接包含的）、兄弟节点（同一父节点下的同层节点）。比如说，div是h3和a的父节点，h3和a互为兄弟节点，div是body的子节点，同时body又是div的父节点。理解了这层家族关系，XPath的路径逻辑就顺了。
节点之间通过这些关系串起来，就形成了“路径”。路径的写法类似你在文件系统里找文件，核心语法就几个：/表示绝对路径，//表示相对路径（从任意位置开始找），.表示当前节点，..表示父节点，@表示属性，*表示任意元素节点。
2.2 绝对路径与相对路径：一个关键分水岭
这是手写XPath首先得过的一道坎。
绝对路径是以/开头的路径，从文档根节点开始逐层定位：
/html/body/div[1]/h3这种写法优点是直观，缺点是页面结构一变就崩。浏览器复制出来的XPath基本都是这种，层级深、带索引号，看着都头大。
相对路径以//开头，表示从文档任意位置开始查找匹配的节点：
//div[@class='content']/h3这个表达式的意思是：在整个文档中，先找到所有class属性等于content的div，然后取它们的h3子节点。页面头部加个导航栏、body里多嵌一层容器，都不会影响它，因为它是按语义特征找的，不是按物理位置找的。
我的建议是，日常工作中一律优先写相对路径。只有一种情况适合用绝对路径：你很明确这个页面的DOM结构极其稳定，比如自己团队维护的内部系统，页面迭代频率低，且结构简单到一眼看穿。但即便如此，养成写相对路径的习惯也不亏——因为哪天需求变了，你不需要重写定位。
注意：
//div在浏览器控制台可以查到很多结果，但在自动化脚本的find_element系列方法中，必须保证结果唯一，否则会直接报错。所以写XPath时，心里要默认一个潜规则：写出来的表达式在页面上只能命中一个元素，或者你明确知道它命中多个元素时只取第一个。
2.3 谓语（方括号）的优先级：先定位再过滤
很多新手写XPath时容易犯一个错误，把过滤条件写在了错误的位置。其实方括号[]作为谓语，是拿来过滤节点的，它的优先级很高，紧贴在它前面的节点类型（或轴）上。
拿这个例子来说：
//div[@class='nav']/a[1]这个表达式的执行顺序是：先找所有符合class='nav'的div，再找这些div下的a子元素，最后取a里的第一个。谓语[1]作用在a上，不是作用在div上。如果你想取所有div中的第一个div下的a，要写成：
(//div)[1]/a加了括号，就把“所有div”这个集合先括起来，然后取第一个，再下钻到a。这个括号的差异，我在面试和带新人时反复强调过——它就是XPath里最容易踩的隐藏坑之一。
还有个细节，XPath的索引是从1开始的，不是0。这和大多数编程语言的数组下标完全不同。写习惯了JavaScript、Python的人，可能下意识写[0]，那结果就是永远找不到节点。这一点务必记牢。
3. XPath核心功能与手写技巧：从定位到过滤
3.1 属性定位：class、id、href的常见写法
属性是HTML元素最直观的特征。用属性来定位，是手写XPath的第一选择。
基础写法：
//input[@id='username'] // 通过id定位输入框 //div[@class='card'] // 通过class定位卡片容器 //a[@href='/article/123'] // 通过精确链接定位a标签这里有一个很重要的知识点：@后面跟的是原始HTML属性名。HTML里class属性在XPath中就是@class，不需要额外转换。但要注意CSS选择器里的.表示class、#表示id，XPath里没有这种简写，必须老老实实写@class='xxx'。
有时候页面元素的class值是一长串，比如class="header nav main-wrapper clearfix"，这类动态拼接的class往往会包含变化的标识。这时候精确匹配@class='header nav main-wrapper clearfix'很容易因为顺序变化或删减而失效。更稳妥的写法是用contains()：
//div[contains(@class, 'main-wrapper')]这种写法只要class里包含main-wrapper这个子串就能命中，前端怎么调整其他样式类都不影响定位。
3.2 文本定位与a元素文字包含的完整写法
文本内容是定位的另一个极为实用的维度，尤其是对于a、span、button这些标签。热搜里“xpath a元素文字包含定位怎么写”问的就是这个场景，这属于日常工作中高频中的高频。
XPath里定位文本，有两个核心函数：text()用于精确匹配文本内容，contains()用于模糊匹配包含关系。实际开发中，精确匹配的场景反而少，因为页码、时间戳、用户昵称这些动态信息经常让文本发生变化。
最常见的写法，按需求强度排列：
精确文本匹配一个链接文字：
//a[text()='登录']包含文字匹配一个带前缀或后缀的链接：
//a[contains(text(), '登录')]如果文字的层级不固定，比如文字被包在span标签里，而你要定位的是外层的a，就需要用到.//这种相对路径：
//a[contains(., '登录')]这里的.代表当前节点的全部文本内容，包括所有子孙节点。假如HTML是<a><span>登录</span><i class="icon"></i></a>，那么//a[contains(text(), '登录')]就定位不到，因为text()在a这个节点层面拿到的是直接文本节点，而“登录”在span里。用contains(., '登录')就能无视层级，直接匹配所有文本内容。
再举一个典型场景：搜索页面里有很多带数字的“下一页”按钮，文字是“下一页1”“下一页2”。如果要定位包含“下一页”的a标签：
//a[contains(., '下一页')]这种写法能覆盖各种动态拼接的情况，只要文字里有“下一页”三个字就能命中。
实操心得：
contains(text(), 'xxx')和contains(., 'xxx')这两者的区别，我用一句话总结：前者是“只看自己这一层的文字”，后者是“连子孙的文字一起算”。在真实页面里，元素内部套span、i、b的情况太常见了，所以contains(., 'xxx')的适用面更广。但也要注意，contains(.)可能因为匹配到子孙节点里你不知道的文字而产生误伤，使用前最好在控制台里用$x('...')验证一下命中数量。
3.3 层级与位置：找兄弟、找父级、按序号定位
手写XPath时，很多时候单靠当前元素的属性没法唯一确定，得靠它的“邻居”或“长辈”来定位。
找父节点：比如你要点的按钮没有独立id，但它的父容器有明确的class：
//div[@class='btn-group']/button[contains(., '提交')]找前一个兄弟节点：
//span[@class='label']/following-sibling::input[1]following-sibling::这个轴的直观理解是“当前节点后面所有的兄弟节点”。配合谓语[1]就能取到紧跟其后的那一个。这个场景在表单里非常常见——label和input往往不是父子关系，而是相邻兄弟。
找后一个兄弟节点，用preceding-sibling::：
//input[@name='email']/preceding-sibling::label[1]按序号定位列表项：
//ul[@class='list']/li[2] // 第2个li //ul[@class='list']/li[last()] // 最后1个li //ul[@class='list']/li[position()>3] // 索引大于3的所有li这两个轴方法的手写频率很高，尤其是表单校验场景：错误提示文字往往在输入框的后面，你想根据错误提示定位到对应的输入框，就得往前找兄弟；反之亦然。
3.4 多属性组合与逻辑运算：精确度不足时的兜底方案
当单一条件无法唯一定位时，就用逻辑运算把多个条件组合起来。XPath支持and、or、not三种逻辑操作符。
两个条件必须同时满足：
//input[@class='input-text' and @placeholder='用户名']两个条件满足其一即可：
//input[@id='mobile' or @name='phone']排除某个条件：
//input[@class='input-text' and not(@disabled)]逻辑组合是处理动态页面、多版本页面、多环境部署时最有效的武器。比如测试环境和生产环境的某个页面，老版本用class='btn'，新版本用class='button primary'，你就可以写：
//button[contains(@class, 'btn') or contains(@class, 'button')]3.5 通配符与常见函数速查
XPath里还有一些小而美的语法，用好了能省不少事：
*：匹配任意元素节点。//div/*表示div下所有直接子元素。@*：匹配任意属性。//input[@*]表示所有带任意属性的input。starts-with()：匹配开头子串。//a[starts-with(@href, '/article/')]可以筛掉外部链接。ends-with()：匹配结尾子串，但这个函数在部分浏览器和XPath 1.0环境里不支持，使用前要注意兼容性。normalize-space()：去除首尾空格并合并连续空格。//span[normalize-space()='用户名']能防住源代码里换行缩进带来的空格干扰。count()：统计节点数量。//ul[@class='list']/li[count(../li)=5]这种组合虽然少见，但在动态列表校验中有奇效。
这些函数配合谓语使用，能覆盖至少九成的定位场景。
4. 实操过程：从一个真实页面开始手写XPath
4.1 第一步：打开开发者工具，分析DOM结构
理论知识说再多，不如实操来得直观。我们拿一个典型的博客文章列表页来演示完整流程。
假设页面长这样：顶部是导航栏，中间是文章列表，每篇文章的标题是一个h3，内部有一个a标签，链接指向详情页；每篇文章还有一个阅读量，显示在span标签里，class为read-count。
第一步是打开浏览器开发者工具（F12），点击Elements面板左上角的箭头图标（选择器工具），在页面上点击“文章标题”这个元素。此时Elements面板会高亮对应的HTML代码。然后你右键这个节点，在菜单里选“Copy”下的“Copy XPath”，先看下工具给出的原始结果——大概率是一长串带绝对路径索引的表达式。
我们不要直接用它，而是把它当作“反面教材”，分析它的缺点：层级深、带硬编码索引、对DOM变更极度敏感。
4.2 第二步：从根节点开始逐层手写，边写边验证
在Console面板里，用$x()函数可以快速验证XPath表达式是否有效。
我的习惯是分段拼接，每写一步就验证一步。
先验证是否能定位到所有的文章标题链接：
$x('//div[@class="post-list"]//a')如果返回了一组节点，再验证标题级别的定位：
$x('//div[@class="post-list"]//h3/a')如果命中数量正确，再核实“每一篇文章的相对位置”，比如第二篇文章的标题：
$x('(//div[@class="post-list"]//h3/a)[2]')此时括号不能用错，这个表达式的逻辑是“先把所有匹配文章标题链接的节点取成一个集合，再取第二个”。如果不加括号写成//div[@class='post-list']//h3/a[2]，语义就变成了“取每个h3下的第二个a链接”——结果完全不同。
4.3 第三步：用文本和函数增强鲁棒性
有时候光用class不够，因为设计稿一改，class可能就变了。我们可以在已写好的表达式上逐步演进，把硬编码的层数替换成语义特征。
场景一：列表容器的class可能会变化，但标题文字“深入理解XPath”是稳定不变的：
//a[contains(., '深入理解XPath')]场景二：标题文字里包含了部分动态内容，比如“深入理解XPath（2025版）”：
//a[starts-with(normalize-space(.), '深入理解XPath')]场景三：需要通过文章链接来定位阅读量对应的元素，也就是先找链接，再找它父容器下的兄弟节点：
//a[contains(., '深入理解XPath')]/ancestor::div[@class='post-item']//span[@class='read-count']这里的ancestor::轴很实用：它的意思是“从当前节点向上找所有祖先节点，然后按条件过滤”。直接把范围扩大到“文章的整个卡片容器”，再在卡片内部找阅读量文本。
4.4 第四步：将表达式整合进自动化脚本
在Selenium中使用这些表达式，要区分不同方法：
from selenium import webdriver from selenium.webdriver.common.by import By driver = webdriver.Chrome() # 精确文本定位 driver.find_element(By.XPATH, "//a[text()='登录']") # 包含文本定位 driver.find_element(By.XPATH, "//a[contains(text(), '登录')]") # 包含全部后代文本定位 driver.find_element(By.XPATH, "//a[contains(., '登录')]") # 多条件组合定位 driver.find_element(By.XPATH, "//input[@class='input-text' and @placeholder='用户名']") # 父级定位：先找到包含指定文本的按钮，再往上找所在表单 driver.find_element(By.XPATH, "//button[contains(., '提交')]/ancestor::form") # 兄弟节点定位：通过label的for属性，或通过相邻关系 driver.find_element(By.XPATH, "//label[contains(., '邮箱')]/following-sibling::input[1]")而在requests + lxml的爬虫方案中，同样一套表达式原样可用：
from lxml import html import requests resp = requests.get('https://example.com', headers={'User-Agent': 'Mozilla/5.0'}) doc = html.fromstring(resp.text) # 提取所有文章标题 titles = doc.xpath('//div[@class="post-list"]//h3/a/text()') # 提取包含指定文字的链接href link = doc.xpath("//a[contains(., '深入理解XPath')]/@href") # 提取阅读量 counts = doc.xpath('//span[@class="read-count"]/text()')这段代码里有几个值得注意的地方：
- 用
resp.text来构建文档对象时，如果页面编码是GBK或GB2312，最好先用resp.content.decode('gbk', errors='ignore')解码，否则中文文本匹配容易失败。 text()在lxml中返回的是该节点下的直接文本节点列表。如果目标元素内部还有子标签，用.更稳妥，但要取字符串时最好配合string()或.strip()处理空白。- lxml的
xpath()方法返回的是列表，查不到节点时返回空列表，不会抛异常。所以取数据时要加判断，避免索引越界。
4.5 XPath Helper的下载与使用：手写时的心头好
XPath Helper是Chrome浏览器上的一款XPath调试插件，热度一直很高。它的核心价值在于：你在页面上选中一个元素，它会显示对应的XPath表达式；或者你输入一个自定义的XPath，它在当前页面高亮所有命中的元素，并显示命中数量。
安装方式有几种：
第一种，Chrome应用商店搜索“XPath Helper”直接添加（需要能访问商店环境的情况下）。第二种，从GitHub仓库下载crx文件手动安装。第三种，如果公司内网环境无法访问商店，还可以使用Tampermonkey油猴脚本，或者直接用DevTools的Console里$x()替代——功能上其实覆盖了绝大部分需求，只是少了弹层高亮的体验。
安装完成后，浏览器右上角会出现XPath Helper的图标。使用方法是：按住Shift键并鼠标悬停在某个元素上，会看到一个浮动面板显示该元素的XPath；点击面板左下角的“Query”按钮，可以输入自定义表达式；按Enter执行，页面上所有命中元素会被黄色高亮框标记出来，同时面板显示命中数量。
我实际使用中最依赖的是它的“实时编辑”功能：在面板里输入表达式，不用刷新页面，直接在当前页面上看结果。写XPath时，我会开着这个面板，一行一行尝试修正，命中数量从几十个缩减到几个、再到唯一一个，链路非常顺滑。
实操心得：XPath Helper默认显示的是绝对路径，这个不用管。你要做的是把绝对路径作为起点，在面板里手动改成相对路径，观察高亮区域和数量的变化。这种“看得见摸得着”的调试方式，比盲写表达式再跑脚本高效太多了。
5. 常见问题与排查技巧实录
5.1 元素存在但XPath却定位不到，怎么排查
这是最高频的问题。遇到这种情况，我有一套固定的排查顺序：
第一步，检查是否在iframe里。页面上有嵌入的编辑器、地图、广告时，经常用iframe嵌套。XPath默认只查询顶层文档，看不到iframe内部。解决方法是先切换到对应框架：
driver.switch_to.frame('iframe的id或name') # 定位完成后再切回 driver.switch_to.default_content()第二步，检查表达式在Console里能否命中断言。在Chrome的Console里输入：
$x('//a[contains(., "登录")]')如果返回空数组，说明表达式写得有问题，或者当前页面不是你预想的版本。此时直接在Elements面板里搜索关键文字，确认目标元素到底长什么样。
第三步，确认元素是否在Shadow DOM内部。越来越多的组件库使用Shadow DOM封装，普通XPath是穿透不进去的。这种情况要么改用CSS选择器配合shadow-root方式操作，要么在XPath无能为力时直接用JavaScript执行器定位。
第四步，确认元素是否可见。visibility:hidden、display:none、opacity:0这些样式会导致Selenium无法交互。此时XPath能查到元素，但click()会报“element not interactable”。解决方案是用JavaScript执行点击：
btn = driver.find_element(By.XPATH, "//button[contains(., '提交')]") driver.execute_script("arguments[0].click();", btn)5.2 元素动态加载导致定位不到，怎么办
现在的前端页面很多是异步渲染的，数据和元素都不是页面加载完就立刻出现。面对这种情况，XPath本身没有“等待”能力，你需要配合显式等待：
from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC element = WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.XPATH, "//div[@class='post-list']//h3/a[1]")) )显式等待会轮询DOM，直到元素出现或超时。这里有一个经验：用presence_of_element_located表示“元素在DOM里存在”，而用visibility_of_element_located表示“元素可见且可以交互”。如果在等待之后仍然找不到，检查网络请求是否失败，或者接口返回的数据结构是否有变化。
5.3 动态id和class频繁变化，如何维持稳定性
很多现代前端框架会生成带随机字符串的id或class，比如id="ember123"、class="sc-8hjs90-0 dGHiZb"。这种值每次刷新都可能变化。
应对策略有三个：
避免用动态值做精确定位，用starts-with()或contains()做模糊匹配。
通过稳定的定位线索间接定位。比如某个按钮的父级表单class是稳定的，按钮本身class是动态的，那就定位父级再向下找。
如果页面没有任何稳定的锚点，那就退一步，用“文本内容”配合“相对位置”的组合定位。
//div[contains(@class, 'product-card')]//button[contains(., '加入购物车')]这种写法依赖的是“语义层级”，不依赖具体class值或序号。
5.4 同一表达式命中多个元素，如何收窄
用$x()或者Selenium的find_elements时，会发现表达式匹配了多个元素。收窄的手段按优先级排列：
- 增加更精确的属性条件
- 增加父级或祖先级别的限定条件
- 用
position()或last()缩小范围 - 用文本内容限制
命中多个不一定就是错的，如果你明确要操作第一个，用find_element（单数）默认取第一个就行。但如果你要操作每个匹配项，就用find_elements遍历。
5.5 网页结构复杂，层级嵌套太深，手写太痛苦怎么办
现在的页面动辄七八层嵌套，完全手写确实繁琐。我自己的处理思路是“抓大放小”：
先定位到最近的有稳定标识的祖先节点，进入这个祖先后，再查内部元素。用XPath的//相对路径，不需要把中间所有层级都写出来。
比如DOM结构是/html/body/div/div/div[2]/div/div[3]/div[2]/form/div[1]/input，但form有唯一的id属性，直接写：
//form[@id='search-form']//input[@name='keyword']这样完全不用关心form外面的层级怎么变化。
6. 关于手写XPath的个人经验总结
最后分享几个我长期实操下来觉得最值得记住的点：
第一，XPath不是背出来的，是查出来的。我写XPath时，浏览器DevTools的Elements面板始终是打开状态，右边是Console，随时用$x()验证。这个“写一段、验证一段、修正一段”的循环，是手写XPath最高效的工作方式。
第二，优先使用文本和语义特征，而不是层级位置和索引。索引意味着一个页面上无意义的物理位置，而文本和class表达的是这个元素“是什么”。物以类聚的页面组件千变万化，但“这个按钮的字是什么”很少变。
第三，contains(., '关键词')和contains(text(), '关键词')的区别，建议大家在项目里都实测一次。多花一分钟搞清楚这个细节，后面能省掉无数个“为什么定位不到”的深夜排查。
第四，写XPath时不要贪图一步到位。复杂页面分三步定位——先到稳定的容器，再定位容器内的目标，最后用文本或属性收窄到唯一元素。每步都验证，降低了出错的概率，排查问题也更容易定位到具体是哪一段失效。
手写XPath是一项很底层的技能，虽然现在有不少基于AI的智能定位方案，但理解了路径的构建逻辑后，你在任何工具、任何框架里都能快速定位元素。这个能力不会因为工具的升级而过时，反而会帮你在遇到问题时多一套排查思路。下次再遇到浏览器帮你生成的长路径，不妨删掉，试试手写一条路径的感觉——你会发现，页面在你眼里开始变得透明了。