accessiBe推出Code Agent，将无障碍审查嵌入GitHub拉取请求流程

数字无障碍解决方案提供商accessiBe近日宣布推出Code Agent，该功能可将无障碍审查直接嵌入GitHub拉取请求（Pull Request）环节，在代码编写阶段即完成检测与修复建议。目前该功能已面向符合条件的accessFlow客户开放测试版。

根据介绍，Code Agent会在拉取请求打开或更新时自动运行，也可随时手动触发。它依据WCAG 2.2 AA标准对代码进行审查，能够定位到引发问题的具体代码行，并在拉取请求中直接以内联方式提出修复建议，呈现形式与团队成员的审查评论一致。开发者可以选择接受、拒绝或在讨论串中进一步沟通，未经开发者审核的代码不会被合并。

该工具支持团队设置严重程度阈值，并排除特定文件或规则，以避免审查意见过多而失去实用性。团队还可以将Code Agent设为合并前的必过检查项，与现有的测试和代码规范检查流程并列。目前Code Agent支持原生HTML/JavaScript、React和Next.js，并允许团队覆盖框架检测结果。

accessiBe首席执行官Robert Lopez表示：“无障碍应当成为软件构建的方式，而不是事后叠加的环节。每一个在代码发布后才到达开发者手中的问题，其修复成本都高于在编写阶段解决，并且会让风险在生产环境中停留更长时间。Code Agent在工程师的工作环境中运行，使问题在发布之前就被捕获。”

从行业背景来看，无障碍问题的产生源于代码本身，但传统上它们通过代码之外的渠道到达工程团队——工单、截图或参考编号，而非具体的代码行。当问题反馈到开发者手中时，代码往往已经发布，团队也已进入下一个迭代周期。Code Agent试图将审查环节前移，放置在与测试、代码规范和构建相同的拉取请求环境中，让开发者在仍处于文件编辑状态、仍对发布内容拥有决定权时完成修复。

Code Agent运行在accessiBe统一的底层无障碍引擎之上，该引擎同时驱动其平台的其他产品：用于运行时修复的accessWidget、accessFlow的监控与修复工具，以及用于自动化扫描和审计历史的accessScan。这意味着在拉取请求中提出的修复方案，与网站上线后所依据的衡量标准保持一致。

将无障碍检测嵌入开发工作流是近年来企业软件领域的一个明确趋势。此前，多数无障碍方案侧重于网站上线后的扫描与修复，属于被动响应模式。而随着合规要求趋严和开发流程的左移，将无障碍检查纳入持续集成与持续交付（CI/CD）管道，正在成为企业级开发工具链的组成部分。accessiBe此次推出的Code Agent，正是这一趋势在具体产品层面的落地。

目前该功能处于测试阶段，其实际效果、对开发效率的影响以及与主流代码托管平台的集成深度，仍有待更多团队使用后的反馈验证。