用代理进行开源问题分类
内容提要
Bootstrap 维护者利用 LLM 代理构建内部工具 twbs/triage，自动分析开放 issue 和 PR，生成分析、回复草稿和修复分支，最终由维护者决策。首轮处理 200 多项，发现已修复问题、待合并 PR 等，并统一标签。代理将贡献者内容视为数据而非指令，不运行其代码，仅作起点，不替代贡献者。
延伸解读
代理如何辅助维护者决策
Bootstrap 的 twbs/triage 工具将每个 issue 或 PR 的处理分为五步：同步、分析、准备、存储、决策。代理自动生成分析、回复草稿和修复分支，但所有决策和回复仍由维护者手动完成。这种设计确保代理只作为起点，不替代维护者的判断，同时大幅提升处理效率。
安全边界：将贡献者内容视为数据
代理默认将贡献者提交的内容视为数据而非指令，从不执行贡献者代码，也不打开 issue 中的链接。它们基于 Bootstrap 自身的 dist/ 构建复现，且不能直接在 twbs/bootstrap 上评论或推送。自动标签仅限固定允许列表，涉及决策的标签仍由维护者添加。这种“默认敌对”策略降低了安全风险。
实际效果与局限性
首轮处理了 200 多个积压项，发现已修复问题、待合并 PR 等，并统一了标签。代理按易度评分排序，帮助维护者快速行动。但代理不了解 Bootstrap 全部历史，有时会提出不合适的代码方案，其工作仅供参考，最终仍需维护者审核。
对贡献者的影响与建议
未来几周，旧 issue 和 PR 会有更多活动。贡献者应提供仅含 Bootstrap CSS/JS 的最小复现，并注明版本；v5 修复目标为 v5-dev，新工作目标为 main。每个 PR 保持单一变更，并说明修复内容和测试方式。若问题被错误关闭，可在讨论中反馈。
Q&A
Bootstrap 维护者为什么要开发 twbs/triage 这个工具？
Bootstrap 仓库有 230 个开放 issue 和 PR，其中四分之一超过三年，而日常维护仅靠两名核心成员。过去十二个月收到 186 个 issue 和 838 个 PR，处理每个都需要大量时间，维护者的时间和注意力是最大瓶颈。因此他们利用 LLM 代理构建了 twbs/triage 来自动分类和分析这些条目。
twbs/triage 工具的工作流程是怎样的？
每个条目都经过五个步骤：同步（读取所有开放 issue 和 PR，不写入主仓库）、分析（阅读讨论、查找相关工作、检查两个分支并复现问题）、准备（起草分析、回复、修复和下一步行动）、存储（将条目和修复分支保存到 twbs/triage）、决策（维护者审查并手动在 GitHub 上操作）。
代理如何确保处理贡献者内容时的安全性？
代理将贡献者内容视为数据而非指令，从不检出、安装或运行贡献者代码，只阅读 diff 并以 GitHub CI 作为证据。它们从不打开 issue 中的链接，从头基于 Bootstrap 自己的 dist/ 构建复现，且不能在 twbs/bootstrap 上评论、推送或打开 PR。唯一例外是自动添加来自固定允许列表的事实性标签，任何可疑内容都会停止并交由维护者手动审查。
twbs/triage 首次运行发现了哪些典型问题？
首次运行处理了 200 多个条目，发现了多种情况：例如 #31088 已被 #42834 修复但因目标分支问题未关闭；#42714 是一个等待审查的 v5 轮播触摸修复，被确认并合并；#37442 是一个 2022 年的 PR，被建议关闭并由维护者解释原因；#37807 则准备了两个 v6 修复方案供比较。还发现九个已修复但未关闭的条目。
使用 twbs/triage 后，Bootstrap 的标签管理有什么改进？
该工具暴露了 GitHub 标签的缺口，维护者标准化了标签名称，记录了每个标签，添加了缺失的标签如 bug 和 needs-decision，并在 198 个开放条目上应用了 410 个标签。代理可以从固定允许列表设置事实性标签，但涉及决策的标签（如 duplicate 或 wont-fix）仍由维护者添加。
贡献者如何帮助 Bootstrap 的维护者更高效地处理 issue 和 PR？
贡献者可以提供仅使用 Bootstrap CSS 和 JavaScript 的最小复现，并注明版本；针对 v5 修复应指向 v5-dev 分支，新工作指向 main 分支（自 10 月 8 日起，main 用于 v6，v5-dev 用于 v5）；每个 PR 只做一个更改，并说明修复内容和测试方式。如果问题被错误关闭，可以在讨论中告知。
