GoLang 技术主管 Russ 辞去职务，致力于开发一款聊天机器人，旨在帮助各地不堪重负的开源维护者。
译自 Russ Cox's Next Act: AI-Powered Help Agents for Open Source Projects，作者 David Cassel。
Russ Cox 的下一步行动看起来像是他的最后一步行动，至少在他的人工智能聊天机器人接管之前是这样。
当 Cox 在 9 月卸任 Go 语言技术负责人时，他强调说：“我不会离开 Go 项目……”他在 8 月 1 日的公告中强调。
除了讨论设计、回答问题、倡导 Go 以及“不时”提交问题外——以及“处理一些潜在的新标准库”——Cox 还将重点转向一个有趣的与 Go 相关的新项目，该项目是他 6 月开始的。而 Cox 的更大目标是帮助所有开源维护者实现一种工具架构，该架构可以“将机器可以相当好的处理的各种平凡的事情自动化……”
该主页明确指出：“维护工作不只局限于 Go 项目，因此我们的目标是构建一个任何软件项目都可以重复使用和扩展的架构，构建自己的定制代理以满足其项目的需要。”
在 GitHub 的 README 文件中，将该项目的底层代码描述为用于“创建用于开源维护的自动帮助或‘代理’”的“开源贡献者代理架构”。他们将其命名为 OSCAR——即（O）pen（开源）（S）ource（贡献者）（C）ontributor（A）gent a(R)chitecture（架构）的缩写。
“充当项目搜索引擎仍然不是维护者时间的最佳利用方式”，Oscar 的 README 文件指出。但是，一个自动代理可以随时待命，以便从过去的 issue 报告（以及 pull request/更改列表、文档和论坛讨论）中立即“浮出水面相关的项目上下文”。
README 文件承认该项目“很像一个实验”。但它指出，帮助贡献者的第一个代理原型已经为 Go 编程语言提交的 issue 执行了“许多”成功的交互。
6 月 7 日，Cox 宣布意外推出一个名为 Gaby 的首个原型代理 - 由 Google 的 Gemini LLM 提供支持。其首要任务是什么？当一个 issue 提及特定变更清单号时，自动添加一个超链接。（这促使 Cox 对 Gaby 进行了首次变更 - 告诉它忽略拉取请求，而只专注于编辑 Issues。）
同日，Cox 教会 Gaby 将提交的问题中出现的任何 Google 内部 URL 重写为其公开对应的 URL。几天内，更多功能请求开始出现在讨论中......
Cox 宣布 Gaby 发布的消息引起了热烈反应——包括 133 个赞。
但 Gaby 最大的影响似乎在于它在提交新问题时自动发布它识别为“类似问题”的内容——“最多包含十个高度相关的链接，为报告添加上下文”。（Cox 6 月 7 日的公告指出， Gaby 只会在“发现足够相似的链接时”才发帖。如果没有找到，它将保持安静。）但他也指出，在 Gaby 运营的第一天，它的“相似”链接实际上在提交重复问题时正确地识别出来了。
Gaby 的文档记录，证明该代理的响应“非常有帮助”。一位心存感激的贡献者甚至以“好机器人 :）”作为向 Gaby 表达响应的开场白。
十个星期内，Gaby 已针对近 600 个不同的 Go 议题表达了评论，其中 370 个已关闭，另有 216 个开放。
很快，Go 的议题就有了新的可用标签：“gabywins”。
“针对相关问题进行发帖是一种有限的分析形式，”Oscar 的文档承认， “但我们计划添加其他类型的语义分析，例如确定一个问题主要与性能相关并应添加一个“性能”标签。
“我们还计划探索是否可以对报告进行充分的分析，以确定是否需要更多信息才能使报告有用。” 有一天，代理甚至可以在沙箱中重现错误，以查看它影响了哪些版本——“甚至使用 git bisect 来识别引入错误的提交。”
未来还会有哪些？可能的“扩展目标”包括自动标记问题或联系维护人员以获取关键的变更列表。（并且已经有一些关于 Gemini 的初步实验，以查看它在“从可用工具中选择并调用可用工具以满足维护人员提出的自然语言请求”方面的表现。）
“另一个扩展目标可能是识别何时问题需要更多信息并请求该信息。” 虽然 Gaby 的文档 直言不讳地承认“不能保证今天的 [大型语言模型] 能够很好地工作，以构建该模型的有用版本。” 文档的最后几段甚至提出了 Gaby 有一天会进行“互动对话”的可能性。
“总的来说，我们相信有一些好主意，可以让基于 LLM 的机器人帮助项目维护人员的工作更轻松、更少单调，并且它们正在等待被发现。”
“也有很多不好的想法，必须过滤掉它们。理解差异需要大量的关注、思考和实验。我们还有工作要做。”
“这项工作的一些方面可能涉及 AI/LLM；有些则不会。”
该项目戏谑地指出，它还希望确定 LLM“不应该用于什么”。 但更重要的是，“指导原则是在创建对维护人员有帮助且维护人员喜欢的东西，这意味着在 LLM 有意义且有帮助时使用它们，但在没有意义且没有帮助时不要使用它们。” 因此，例如，它强调其对 LLM 的目标不是让它们取代程序员。“毕竟，编写代码是编写软件的乐趣所在。”
相反，它设想 LLM 成为交互的“一小部分（但至关重要！）”——“专注于不那么有趣的部分，例如处理传入问题、将问题与现有文档匹配等等……”
Oscar 的文档甚至展望了 Gaby 可以托管在其他平台（如 Google 的 Cloud Run）上的那一天，以便它可以与 GitHub 的基于事件的通知服务 Webhook 集成。 Gaby 使用 GitHub 的 REST API 下载问题跟踪器的状态以获取源材料（它还使用项目文档），Oscar 的 README 文件指出。“但架构使其易于添加其他来源。”
在 8 月 1 日的公告中，Cox 分享了他对担任 Go 技术主管 12 年后的角色的理解：“为你们所有人服务，并努力创造合适的条件，让你们所有人都能发挥出最佳水平。”
而且他似乎正在以其他方式继续这项工作——不仅仅是为了 Go 开发人员。 Cox 的公告中还表达了希望 Oscar 相关工作“将发现帮助开源维护人员的方法，这些方法将被其他项目采用，就像 Go 的一些最佳想法被其他项目采用一样。”
目前，Oscar 架构“正在 Go 项目的赞助下开发”，根据其 README 文件。“在未来的某个时刻，它可能会（也可能不会）被拆分成一个单独的项目……”
当 Cox 用一般性术语在他的公告中写道“我对 Oscar 的目标是构建一些有用的东西”，但也“学习一些新东西”——以及“为其他项目制定路线图”时，有一种令人心酸的感觉。 Cox 补充说，“这些是我一直以来对我们在 Go 上的工作所抱有的同样广泛的目标，因此从这个意义上说，Oscar 感觉就像是一种自然的延续。”
到 8 月 15 日，Cox 已经对 Oscar 进行了 13 次提交。