构建通用无障碍代理——以及我们在过程中的学习

分享:
[](https://x.com/share?text=Building%20a%20general-purpose%20accessibility%20agent%E2%80%94and%20what%20we%20learned%20in%20the%20process&url=https%3A%2F%2Fgithub.blog%2Fai-and-ml%2Fgithub-copilot%2Fbuilding-a-general-purpose-accessibility-agent-and-what-we-learned-in-the-process%2F)
[](https://www.facebook.com/sharer/sharer.php?t=Building%20a%20general-purpose%20accessibility%20agent%E2%80%94and%20what%20we%20learned%20in%20the%20process&u=https%3A%2F%2Fgithub.blog%2Fai-and-ml%2Fgithub-copilot%2Fbuilding-a-general-purpose-accessibility-agent-and-what-we-learned-in-the-process%2F)
[](https://www.linkedin.com/shareArticle?title=Building%20a%20general-purpose%20accessibility%20agent%E2%80%94and%20what%20we%20learned%20in%20the%20process&url=https%3A%2F%2Fgithub.blog%2Fai-and-ml%2Fgithub-copilot%2Fbuilding-a-general-purpose-accessibility-agent-and-what-we-learned-in-the-process%2F)

说代理已成为处理代码的一种流行方式，这都算是轻描淡写了。GitHub 在其许多项目中都采用了基于代理的代码创建和编辑方式，包括试点一个代理来协助**我们对无障碍访问的承诺**。

GitHub 目前正在试点一个实验性的通用无障碍代理，旨在实现两个主要目标：

在 GitHub Copilot CLI 和 Copilot VS Code 集成中，为工程师提供可靠、及时的无障碍问题解答。
在代码投入生产之前，发现并自动修复简单、客观的无障碍问题。

针对第二个目标，该无障碍代理被设置为自动评估对我们前端代码的修改。

迄今为止，该代理已审查了 3,535 个拉取请求，解决率达到 68%。按出现频率排序，排名前五的问题类型集中在：

这些问题类型中的每一个都代表了摩擦和障碍，它们被自动移除，否则将会妨碍使用和依赖辅助技术的用户使用 GitHub。以下是其实际运行的一个截图：

图片 9：GitHub Actions 机器人在拉取请求中对一行代码的评论，建议修复一个内容顺序无障碍问题。评论内容为：“WCAG 1.3.2 有意义的顺序：.header CSS 类使用了 flex-direction: row-reverse，这导致关闭按钮在 DOM（以及屏幕阅读器阅读顺序）中首先出现，但在视觉上呈现在标题之后。这造成了程序化阅读顺序与视觉布局之间的不匹配。一个更简单的方法是在 DOM 中交换元素顺序，并在 CSS 中使用常规的 flex-direction: row，这样阅读顺序就能与视力正常用户看到的内容相匹配：” 随后是一个代码建议，重新排序了标题和侧边栏工具栏，并提供将建议提交到代码的选项。之后是一条最终评论：“这还需要更新 agent-task-content.module.css 中的 •header，将 flex-direction: row-reverse 改为 flex-direction: row。” 裁剪后的截图。

感兴趣吗？我们将概述这次实验的成功经验和教训，希望它能对其他团队的无障碍之旅有所帮助。

什么是 LLM 和代理？

注意：本文假设读者至少对 LLM、代理及其相关概念有一定了解。如果您不熟悉，可以在我们的博客上了解更多关于 LLM 的信息。

您可能会觉得有帮助的一些具体文章包括：

思维方式

残疾的社会模型告诉我们，障碍——以及随之而来的功能限制——可能是由于环境的构建方式而产生的。同样的思路也适用于数字体验。

对于无障碍智能体，我们并非试图孤立地“解决”无障碍问题。相反，我们试图增强我们同伴的努力，以便更好地帮助他们消除那些可能因我们构建 GitHub 用户界面的方式而产生的障碍。

无障碍智能体并非可以自动处理所有假设场景的“银弹”。理解、尊重并推广这一点，有助于更好地界定智能体的职责范围。这加速了实验的启动，并为这项工作赢得了更多支持。

过往努力

《欧洲无障碍法案》现已生效。《美国残疾人法案》第二章将于 2027 年 4 月确立，将满足 WCAG 2.1 AA 标准作为法定的完成定义。LLM 智能体可以读取无障碍树并采取行动。

坦率地说：如果组织尚未投资于手动识别和修复无障碍问题，他们将处于劣势。这有很多原因，包括构建无障碍智能体。

就这一点而言，GitHub 已经建立了一个成熟的系统来记录无障碍问题，并验证对问题的修复是否按预期工作。这包括：

报告问题的结构化模板
重现问题的步骤
关于问题严重性级别、服务领域和适用的 WCAG 成功标准的丰富元数据层
指向解决问题的 Pull Request 的交叉链接
验收标准

此外，所有问题都集中在一个仓库中。虽然这项问题记录工作在 LLM 工具流行之前就已存在，但其高度一致和结构化的特性使其成为无障碍智能体参考的理想内容语料库。

因此，我们指示智能体调查这些问题，看看是否能从中推断出相关的代码和语言片段。这是 LLM 非确定性的“模糊匹配”行为作为资产而非潜在负债的一个领域。

旧有宝藏

与任何其他专业领域一样，技能文件中模糊的指令是不够的。仅仅告诉 LLM “使用无障碍最佳实践”并附上简短的示例列表，效果不会好。

在生成代码时，**LLM 不幸地倾向于产生无障碍反模式**，因为目前所有主要的 LLM 都是在数十年的非无障碍代码上训练的。

为了抵消这一点，智能体需要更好的内容作为参考。

因此，我强烈建议投资于手动分类和修复无障碍问题。在取得一些进展后，这些数据可以被整合到智能体中。

这些问题及其对应的 Pull Request 为 LLM 提供了高度情境化的参考示例，这些示例是使用其部署所在组织的约定编写的。这个问题和代码的集合是智能体迄今为止最强大的资产之一。

高效的令牌消耗

无障碍是一个整体性的问题，它与代码、设计、文案以及创建用户界面所涉及的许多其他学科相交织。

许多无障碍工作也是高度情境化的，这意味着通常需要有人全面了解问题后，才能给出适当的处理建议。

由于这两个因素，一个通用的无障碍智能体在执行工作时可能会消耗大量令牌。这会带来三个负面结果：

不可靠输出的增加
响应时间变慢
运营成本增加

在构建智能体时，仔细设计其结构非常重要。以下是我们是如何做到这一点的。

使用子智能体

无障碍智能体最初是一个单一的整体智能体，但很快就超出了这种方法的局限性。因此，我们将其演变为使用子智能体架构。

许多指南建议创建一套庞大的子智能体，每个子智能体都有自己特定的职责领域。在这种架构中，子智能体并行执行，由主智能体整合它们的输出。

令人惊讶的是，这种方法对无障碍智能体并不奏效。相反，我们最终使用了两个专门的子智能体：

第一个子智能体充当被动的审查者和研究者。
第二个子智能体充当主动的实施者。

这两个子代理是沙盒化的，不能直接相互传递内容。相反，它们会生成结构化的、模板化的输出。然后，这个输出会提供给父级的编排无障碍代理，由其进行消费、验证和路由。

Image 10: 一张示意图，展示了父级无障碍代理如何将工作依次传递：从自身到只读的审查员子代理，然后返回父级代理，再到具有读写能力的实施者子代理，最后再次返回父级代理。父级代理位于标记为“第1层 - 编排”的列中，两个子代理位于标记为“第2层 - 专家”的列中。第一条连接线显示父级代理将工作传递给审查员子代理，标记为“运行子代理”。第二条线将工作传回父级代理，标记为“结构化发现”。第三条线是父级代理将工作传递给实施者子代理，标记为“使用结构化发现运行子代理”。第四条也是最后一条线将工作从实施者子代理传回父级代理，标记为“生成的更改或指导”。父级和子代理还有各自的职责列表。父级无障碍代理负责路由请求、定位代码和技能、运行复杂性评分、验证输出、管理升级关卡、管理重新审计循环以及回答研究问题。审查员子代理执行代码审计、WCAG研究、检测升级触发器并生成结构化发现。实施者子代理有两种模式：默认的代码更改模式和后备的仅指导模式。代码更改模式首先修复关键问题，然后处理其余问题。仅指导模式生成指导文档。两种模式都验证更改。

采用这种方法有几个原因：

升级检查点。审查员会检查可能需要人工干预的领域。这包括多个高严重性的WCAG失败，以及一系列已知难以实现无障碍访问的模式。
基于复杂度的行为。如果底层代码被认为过于复杂，代理会被指示在专门的仅指导模式下运行。在这里，父级无障碍代理充当仲裁者，而审查员代理则是“无立场的”，只是按照指示报告发现。
过滤。审查员会呈现它发现的所有内容。然后，父级无障碍代理利用资源和技能来确定哪些内容与请求相关。如果审查员将其所有发现都传递给实施者，成本会很高，并可能使其执行无关且适得其反的任务。
可追溯性。子代理之间的直接通信将无法创建和审查用户及代理决策的审计跟踪。考虑到代理关于复杂模式的指令，以及无障碍工作高度依赖上下文的特点，这一点非常重要。

按线性顺序执行指令

除了是一个整体性的关注点外，有效的数字无障碍工作还需要一种有条不紊、注重细节的方法。

使用子代理来提高LLM回复速度的考虑，与我们对其结果准确性的需求相平衡。我们发现，强制代理按照固定顺序执行其子代理指令是关键。

我们首先建立一组有序的父级阶段。每个阶段本身包含有序的子步骤指令，并附带相关的资源和技能：

图片 11：该示意图展示了研究子代理如何利用有序阶段及各阶段内的有序步骤来生成结构化输出。第一阶段标记为“阶段 1 - 研究”，包含 5 个步骤。第一步标记为“WCAG 成功准则”，使用名为“wcag-2.2-level-a-aa-success-criteria”的技能。第二步标记为“GitHub 的成功准则解读”，使用名为“accessibility-check-wcag-sc-interpretation”的技能。第三步标记为“辅助技术支持”，使用名为“accessibility-check-at-support”的技能。第四步标记为“先前的无障碍审计”，使用名为“accessibility-search-prior-audits-general”的技能。本阶段的第五步也是最后一步标记为“外部 W3C 参考”，并受一条名为“仅在本地搜索不足时”的规则约束。一个箭头将第一阶段连接到第二阶段，第二阶段标记为“阶段 2 - 代码审计”。第二阶段的第一步标记为“按需读取源文件”。第二步标记为“整合用户提供的 URL”，并设有一个强制其始终获取的角色。第三步标记为“调查所提供 URL 的链接”，并受一条名为“搜索深度为 1 级”的规则约束。第四步标记为“运行验证技能”，使用名为“决策表”的资源。第五步标记为“交叉引用发现”，使用名为“使用阶段 1 研究”的技能。本阶段的第六步也是最后一步标记为“重新审查所有交互过的内容”。一个箭头将第二阶段连接到第三阶段，第三阶段标记为“阶段 3 - 结构化输出”。第三阶段包含一个标记为“发现报告，output-schema-reviewer”的步骤。它有三个子部分：“摘要”、“发现严重性评分”和“每个发现包含”。摘要子部分包含一个有序列表，内容为：“1. 发现总数”、“2. 先前审计”、“3. 需要升级”、“4. 升级范围”和“5. 已升级的发现”。发现和严重性评分有三个级别：“严重”、“警告”和“信息”。每个发现包含适用的 WCAG 成功准则、适用的文件和行号、当前面向用户的体验、期望的面向用户的体验、修复建议以及升级摘要（如果存在）。

这种线性顺序的有趣之处在于，它反映了我个人执行审计、修复和报告职责时会采用的方法。

使用模板模式在各子代理间传递内容

沙盒子代理的整个操作都围绕模板模式文件构建。这些文件创造了一致性，这对于保持代理专注和正轨至关重要。

这两个模板模式是：

审查者模板模式： 专注于审计什么，以及如何查找相关信息。
实施者模板模式： 专注于修复什么以及如何修复。

如果没有这些模式文件，所有代理都会尝试随意地相互通信。这将导致令牌消耗增加、产生不良的幻觉、进行不必要的代码更改，并且使代理审计行为变得极其困难甚至不可能。

承认局限性

创建无障碍代理的另一个关键方面是理解代理可能存在的不足领域。

由于该代理并非一个开箱即用的无障碍“解决方案”，我们希望避免这样的情况：代理的错误输出可能没有被使用它的人充分质疑。这对于那些不熟悉数字无障碍考量和实践的人来说尤其重要。

以下是我们为适应代理局限性所做的努力：

评估代码复杂度

我们希望避免这样一种情况：需要付出高昂且耗时的努力，去重新审视一个代理“认为”无障碍但实际上存在障碍的解决方案。

为了解决这个问题，无障碍代理使用一个小的 shell 脚本来分析它将要处理的代码。脚本本身很简单，使用一组基本的启发式方法来评估相对复杂度，并将其提炼成一个分数。

然后，代理会读取这个分数。如果分数超过设定的阈值，代理会被指示不执行代码更改。相反，它会告知使用 LLM 的人，他们应该联系无障碍团队，就其尝试做的事情进行咨询。

识别高风险模式

理解这一点很微妙，但要知道：完全有可能存在代码通过了自动化无障碍检查，但在功能上却无法使用。

作为代码复杂度的补充，无障碍代理被指示避免为无障碍团队已识别为高风险的模式尝试生成代码。这包括但不限于：拖放、toasts、富文本编辑器、树视图和数据网格。

这些模式需要大量的专注力和细节，目前超出了 LLM 当前的能力范围，无法以真正能与辅助技术配合工作的方式生成。

不禁用高风险模式和高复杂度代码环境，将导致每个人都需要不必要地花费时间重新处理问题，同时也代表了无障碍团队的声誉风险。我们通过关闭 LLM 走这条路径的能力来避免这种情况。

减少行动偏见

我不愿将 LLM 拟人化，但它们似乎都有一个共同的特点：极度渴望生成内容。对于 Copilot 来说，这通常意味着生成代码。

我们必须创建反作弊指令，以防止LLM在需要人类专业知识时，通过狡猾的方式绕过其“不生成代码”的指令。这阻止了它违反自身的干预指令。

认识到程序化可判定的问题无法涵盖一切

智能体的成功指标存在于一个更大的背景中。

在总共55条WCAG A级和AA级成功标准中，只有35条可以通过确定性的自动化代码检查器检测到。这意味着大约36%的A级和AA级成功标准无法自动发现。

图12：一个标题为“WCAG A级和AA级成功标准”的饼图。两个扇区中的第一个标注为“36%需要人工评估”。第二个标注为“64%可以自动检测”。

基于LLM的智能体操作正在弥补这约36%的差距，但这并非一门完美的科学。正因如此，在设计和原型阶段早期手动识别无障碍障碍变得至关重要——这是大多数无障碍问题产生的领域。

这种思路也体现在智能体的升级逻辑中，无障碍团队的成员可以与设计师结对，帮助考虑替代方案，并集思广益，在不损害无障碍性的前提下实现业务目标。

进行这种干预和协助是为了阻止潜在的下游问题——以及成本高昂且耗时的重新设计——在它们有机会启动之前就被扼杀。

手动评估智能体输出并调整未按预期工作的部分

我们会定期对智能体的输出进行人工审查，以确定其准确性和有效性。此外，我们还配备了工具来收集拉取请求审阅者的反馈。这两者都作为智能体需要更好指令的领域的强烈信号，同时也是新资源和技能的来源。

开放学习

总结一下，我们了解到智能体：

用于辅助和增强现有的无障碍工作，而不是取代它们。
当针对您特定体验中经过人工审计和修复的无障碍问题进行训练时，效果显著提升。
利用子智能体时，令牌消耗效率要高得多。
以有条理、线性的方式执行指令时，更加准确和有效。
设置为使用预格式化模板传递信息时，更加一致。
设置为了解其局限性，并将人员引导至替代支持系统。
通过定期审查其输出以识别需要更好指令的领域，从而得到改进。

这段旅程也尚未结束。无障碍智能体仍在持续迭代中，以期帮助确保GitHub成为一个对所有开发者都无障碍且包容的平台。

我们希望最终能将此智能体开源，作为我们承诺大规模帮助改进开源软件无障碍性的一部分。在此之前，我们希望通过分享我们在这一事业中的经验，其他团队能够获得一个可供参考的资源，用于他们自己的无障碍工作。

* *

作者

[Eric Bailey](https://github.blog/author/ericwbailey/)

@ericwbailey

更多关于[无障碍](https://github.blog/tag/accessibility/)

[持续AI助力无障碍：GitHub如何将反馈转化为包容性](https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/)

AI自动化处理无障碍反馈的分类，使我们能够专注于消除障碍——将混乱的待办事项转化为持续、快速的解决方案。

[Carie Fisher](https://github.blog/author/cehfisher/ "Carie Fisher的文章")

[GitHub Copilot如何助力在创纪录时间内改进无障碍治理流程](https://github.blog/ai-and-ml/github-copilot/how-we-automated-accessibility-compliance-in-five-hours-with-github-copilot/)

了解我们如何将每周的无障碍信号转化为一个自动化、可问责的修复工作流——由GitHub Copilot和跨职能协作驱动。

[Janice Rimmer](https://github.blog/author/jcwrimmer/ "Janice Rimmer的文章")

探索 GitHub 的更多内容

文档

掌握 GitHub 所需的一切，尽在一处。

前往文档

Image 18: GitHub

GitHub

在 GitHub 上构建未来，这里是任何人、在任何地方构建任何东西的平台。

开始构建

客户案例

了解那些使用 GitHub 进行构建的公司和工程团队。

了解更多

Image 20: The GitHub Podcast

GitHub 播客

收听 GitHub 播客，这是一档专注于 GitHub 上开源开发者社区内外的主题、趋势、故事和文化的节目。

立即收听

我们也有新闻简报

在我们的双周开发者简报中，发现技巧、技术指南和最佳实践。

您的电子邮件地址

*您的电子邮件地址

[x] 是的，我希望 GitHub 及其关联公司使用我的信息进行个性化沟通、定向广告和活动效果评估。详情请参阅 GitHub 隐私声明。

全站链接

[](https://github.com/)

产品

平台

支持

公司

条款
隐私
管理 Cookie
不要分享我的个人信息