Oscar 是一个开源贡献者智能体架构项目，旨在通过为开源维护创建自动化帮助（即“智能体”）来改进开源软件开发。该项目认为，减少维护大型和小型开源项目所涉及的繁琐工作存在许多机会。
大语言模型（LLM）能够对自然语言（如问题报告或维护者指令）进行语义分析，并在自然语言指令与程序代码之间转换，这为智能体更顺畅地与人员交互创造了新机会。LLM 可能只是整体图景中的一小部分（但却是关键部分）；智能体的大部分操作将是执行标准的、确定性的代码。
Oscar 与许多面向开发的 LLM 应用不同，它根本不试图增强或取代代码编写过程。毕竟，编写代码是软件开发中有趣的部分。相反，其理念是专注于不有趣的部分，例如处理传入问题、将问题匹配到现有文档等。
Oscar 非常具有实验性。我们尚不知道它将走向何方或我们将学到什么。即便如此，我们的第一个原型 @gabyhelp 机器人已经在 Go 问题跟踪器中进行了许多成功交互。目前，Oscar 在 Go 项目的支持下开发。未来某个时候，它可能会（也可能不会）独立为一个单独的项目。
Oscar 项目的具体目标包括：减少维护者解决 issue 的精力（注意解决并不总是意味着修复）；减少维护者解决变更列表（CL）或拉取请求（PR）的精力（注意解决并不总是意味着提交/合并）；减少维护者解决论坛问题的精力；使更多人能够成为高效的维护者。其非目标是自动化掉编码。相反，我们专注于自动化掉维护者的繁琐工作。
维护者的繁琐工作并非 Go 项目独有，因此我们旨在构建一个任何软件项目都可以重用和扩展的架构，构建适合自身项目需求的定制智能体。因此有了 Oscar：开源贡献者智能体架构。具体意味着什么仍在探索中。
到目前为止，我们已经确定了将成为 Oscar 重要组成部分的三项能力：在贡献者交互期间索引并呈现相关项目上下文；使用自然语言控制确定性工具；分析问题报告、CL/PR 和群组讨论，以在提交期间或提交后不久实时帮助改进它们，并适当地标记和路由它们。
LLM 在此有所贡献是合理的，因为开源维护本质上是与使用自然语言的人交互，而自然语言正是 LLM 最擅长的。因此，所有这些都具有 LLM 相关组件并不奇怪。另一方面，所有这些也都由大量确定性代码支持。我们的方法是利用 LLM 擅长的领域——自然语言的语义分析以及从自然语言到程序的翻译——并依赖确定性代码完成其余工作。
以下部分依次探讨这三项重要能力。请注意，我们仍在实验，预计随着时间推移会识别出更多重要能力。
索引并呈现相关项目上下文：软件项目是复杂的庞然大物。只有在最开始时，维护者才可能将所有重要细节和上下文记在脑中，即使可能，这些只存在于一个人脑中，当新贡献者带着错误报告、功能请求或问题到来时也无济于事。为了解决这个问题，维护者编写设计文档、API 参考、FAQ、手册页、博客文章等。现在，维护者不必直接提供上下文，而是可以提供指向已存在书面上下文的链接。充当项目搜索引擎仍然不是维护者时间的最佳利用方式。一旦项目发展到中等规模，任何单个维护者都无法跟踪所有可能相关的上下文，这使得充当项目搜索引擎更加困难。
另一方面，LLM 被证明是构建项目搜索引擎的绝佳平台。LLM 可以分析文档并生成嵌入，这些嵌入是高维（例如 768 维）浮点单位向量，其属性是语义相似的文档被映射到指向相似方向的向量。结合向量数据库来检索与输入向量相似的向量，LLM 嵌入提供了一种非常有效的方式来索引开源项目的所有上下文，包括文档、问题报告、CL/PR 和论坛讨论。当新的问题报告到达时，智能体可以使用基于 LLM 的项目上下文索引来识别高度相关的上下文，例如类似的先前问题或相关项目文档。
我们的原型智能体实现了此功能，并在 Go 仓库中对新问题回复最多十个高度相关的链接，为报告添加上下文。（如果智能体找不到看起来足够相关的内容，它会保持沉默，根本不回复。）在运行智能体的最初几周，我们确定了此类智能体的以下好处：智能体向贡献者呈现相关上下文。新的问题报告重复现有问题报告很常见：新 bug 可能在短时间内被多次报告，或者非 bug 可能每隔几个月被报告。当智能体回复重复报告的链接时，贡献者可以关闭其新报告，然后关注较早的问题。当智能体回复看起来像重复但实际不是的报告链接时，贡献者可以提供额外上下文以区分其报告。例如，在 golang/go#68196 中，智能体回复接近重复后，原报告者评论：“好机器人 :)。根据此问题中的讨论，我理解可能无法做这里建议的事情。如果这样，我仍然建议将问题保持打开一段时间，看看有多少 Go 用户关心这个问题。”另一个例子，在 golang/go#67986 中，智能体回复完全重复后，原报告者评论：“唉，我花了相当多时间搜索现有问题。不确定我怎么错过了[那个]。”
智能体甚至向项目维护者呈现相关上下文。一旦项目达到中等规模，没有人能记住所有上下文，即使是高度专注的项目维护者。当智能体回复相关报告链接时，这消除了维护者查找它所花费的时间。如果维护者完全忘记了相关报告，或者从未见过它（可能由其他人处理），回复就更有帮助，因为它可以指引维护者正确方向，并节省重复早期问题中分析的努力。例如，在 golang/go#68183 中，一位项目维护者针对 Go 编译器错误处理某些畸形标识符提交了 bug。智能体回复了一个几乎四年前提交但被分流为低优先级的相同 bug 的类似报告链接。添加的上下文使得可以关闭较早的 bug，并为提高新 bug 的优先级提供了论据。另一个例子，在 golang/go#67938 中，一位项目维护者针对 Go 覆盖率工具导致编译器报告不正确的子行位置信息提交了 bug。智能体回复了十年前一个较早的相关问题（不正确的行号）以及一个关于覆盖率根本不报告子行位置信息的较新问题。第一个 bug 是重要上下文，第二个 bug 的“修复”是新报告中 bug 的根本原因：当时添加的子行位置信息添加不正确。这些链接精确定位了 bug 的确切代码。一旦确定，也很容易确定修复。
智能体立即与 bug 报告者交互。在所有先前例子中，智能体在报告提交后仅一两分钟就回复，这意味着报告者仍然可用并有足够参与度进行有意义的回应：添加细节以澄清建议、作为重复关闭报告、基于过去报告提高 bug 优先级或识别修复。相反，如果初始报告后数小时或数天（或更久）过去，原报告者可能不再可用、感兴趣或能够提供上下文或额外细节。错误报告后立即是与报告者互动并完善报告的最佳时机。不能期望维护者一直参与这项工作，但智能体可以。
最后，请注意呈现项目上下文是可扩展的，因此项目可以纳入其上下文，无论形式如何。我们原型的上下文源针对 Go 项目定制，从 GitHub 读取问题，从 go.dev 读取文档，从 Gerrit 读取代码审查，以及从 Google Groups（如 golang-nuts）读取讨论，但架构使添加额外源变得容易。
使用自然语言控制确定性工具：第二项重要的智能体能力是使用自然语言控制确定性工具。随着开源项目增长，有用工具的数量增加，跟踪所有工具并记住如何使用每个工具可能很困难。例如，我们的原型包括一个通用设施，用于编辑 GitHub 问题评论以添加或[原文截断]
