构建通用无障碍智能体——过程中的经验与教训

GitHub 正在测试一个实验性的通用无障碍智能体，旨在帮助工程师更高效地解决数字无障碍问题。该项目有两个核心目标：第一，在 GitHub Copilot 命令行和 VS Code 集成中为工程师提供即时的无障碍问题解答；第二，在代码进入生产环境之前自动捕获并修复简单、客观的无障碍缺陷。目前，该智能体已对 3535 个拉取请求进行了审查，解决率达到 68%。按出现频率排序，最常见的五类问题依次是：确保结构与关系对辅助技术清晰可见；为交互控件提供明确且简洁的名称；确保用户能感知到重要通知；为非文本内容提供文本替代；以及按逻辑顺序移动键盘焦点。每解决一个问题，就减少了一处可能阻碍使用辅助技术用户访问 GitHub 的障碍。

构建过程中，团队特别强调了心态的重要性。他们根据社会模型理解，无障碍障碍往往源于环境设计，因此智能体并非试图独自“解决”无障碍问题，而是增强开发者的能力，帮助他们消除因界面构建方式产生的障碍。智能体并非万能药，合理划定其职责范围有助于快速启动项目并获得更多支持。

GitHub 拥有成熟的无障碍问题记录系统，包括结构化报告模板、复现步骤、严重级别、服务区域、WCAG 成功标准等元数据，以及与修复 PR 的交叉链接。这些高度结构化的问题数据为智能体提供了理想的参考内容。团队指示智能体从历史问题中学习，利用 LLM 的模糊匹配能力而非确定性匹配，从而找到关联的代码和语言片段。

为了提升效率，智能体采用了子智能体架构。最初是单一智能体，但很快因局限性而改为两个专用子智能体：一个负责被动审查和研究，另一个负责主动实施。两者通过模板化输出进行通信，由父智能体协调。这种设计提供了升级检查点、基于复杂度的行为控制、过滤功能和可追溯性。指令按线性顺序执行，镜像人工审计、修复和报告的工作流程。

智能体还通过代码复杂度脚本和高风险模式识别来管理局限。当代码复杂度超过阈值或涉及拖放、富文本编辑器等高风险模式时，智能体不会自动修改代码，而是建议用户咨询无障碍团队。此外，团队特意设置了反游戏机制，防止 LLM 绕过不生成代码的指令。

尽管智能体取得了显著成果，但团队也承认，程序可确定的问题并不能覆盖所有无障碍需求。目前智能体只适用于约 25 个（共 55 个）WCAG A 级和 AA 级成功标准中的一部分。未来，GitHub 计划继续分享经验，帮助其他团队在无障碍之旅中少走弯路。