当智能体（Agent）加入社区

来源: 博客文章
作者: Thabang Mashologu
发布时间: 2026/9/25 09:28:21
原文链接: https://blogs.eclipse.org/post/thabang-mashologu/when-agents-join-community

---

Stephen O’Grady 最近提出，AI 智能体（AI agents）可能正在成为新的 新造王者（New Kingmakers）。他的观点是，智能体不再只是帮助开发者编写软件。它们正越来越多地自行选择技术、框架和服务，这意味着过去几十年间向开发者转移的一部分权力，如今可能正在再次转移。

我认为这一论点对开源（open source）还有另一层含义。随着智能体成为软件开发的参与者，如果开源社区允许它们参与那些原本设计为由人类治理的流程，会发生什么？

如果允许 AI 智能体（AI agents）参与，现有的人类治理（human governance）将如何运作？

这是我不断回到的问题。如果社区选择欢迎智能体，那么同样的治理应当适用。可能需要改变的是这些规则被表达得有多明确，以便智能体能在其中运作，同时又不模糊一个事实：人类仍然是决策者，并对项目最终接受什么负有最终责任。一个可能的答案是，治理越来越需要成为一种接口（interface）。这不是传统软件意义上的接口，也不一定是一种新的文件格式（file format）或另一项标准。我指的是更根本的东西：治理需要成为人类和机器都能发现、理解并在其中行动的东西。

这听起来可能像是一个微妙的区别，但我不认为它是。在开源历史的大部分时间里，我们有一个相当直接的心智模型。人们编写代码。人们提交议题（issue）和拉取请求（pull requests）。人们审查贡献。人们成为维护者（maintainers）。人们投票。人们做出决策。并且人们为这些决策负责。开源项目和基金会在过去几十年中发展出的治理结构（governance structures），都是围绕这一模型构建的。

这一模型正在开始改变。

AI 智能体已经可以读取代码仓库（repositories）、修改代码、运行测试、提交拉取请求、回应审查评论，并与项目周围的系统交互。O’Grady 指出了一种更广泛的转变：从数据库到开发基础设施的各种产品，正在专门为智能体重建，而智能体正越来越多地做出过去属于开发者的技术选择。

我所说的“参与者”，并不是指智能体会像人一样成为社区的成员。我指的是更实际的情形。如果社区允许，智能体可以贡献工作、与项目基础设施交互、准备提案、收集信息、回应其他参与者，并可能发起对项目产生后果的行动。

但参与不是权威，当然也不是问责（accountability）。

这些区别将非常重要。

行动能力不等于决策权威

智能体让我印象深刻的一点是，它们的行动能力与决策权威之间的差距正在扩大。一个智能体可能从技术上讲有权限执行某个动作，但实际上并没有做出该动作背后决策的权威。

对于人类，我们早已理解这一点。贡献者可以提交拉取请求，但这并不意味着他们可以合并它。维护者可能对代码仓库有写入权限（write access），但这并不意味着他们可以单方面改变项目的治理。项目负责人可能能够做出某些决策，而其他决策则需要投票、共识或某种形式的集体批准。技术权限和组织权威不是一回事。

智能体使这一区分变得更加重要，因为它们行动的能力可能远大于单个人类。它们可以持续运行、与许多系统交互、处理海量信息，并以机器速度执行动作。这些都不会赋予它们权威。

行动能力不等于决策权威。

我认为这可能会成为智能体时代（agentic era）的定义性原则之一。而在它之下还有另一个问题：智能体代表谁行动，谁为它所做的事情负责？

智能体可能代表个人贡献者、公司、项目团队，或者未来由社区自身运营的某种自动化服务行动。这些是实质上不同的情况。因此，身份（identity）、委托（delegation）和问责也成为治理问题的一部分。智能体不仅需要知道它被允许做什么。社区可能还需要知道是谁授权它这样做，以及谁仍然对结果负责。

开源已经拥有很多答案

有趣的是，open source communities（开源社区）已经完成了许多艰巨的工作。我们有 governance documents（治理文档）、contribution processes（贡献流程）、defined roles and responsibilities（明确的角色与职责）、maintainers（维护者）和 project leaders（项目负责人）、elections（选举）、review requirements（审查要求）、intellectual property processes（知识产权流程）以及 security processes（安全流程）。我们有关于个人何时可以行动、决策何时需要 collective agreement（集体共识）的规则。我们花了数十年时间，弄清楚人的社区如何协作生产软件，同时分配权力、保持问责并解决分歧。

问题在于，这些治理大多是为人类编写的。人类 contributor（贡献者）

我们开始看到这个问题的各个方面在开源领域中浮现。研究人员提出了 Agent Governance Manifest（代理治理宣言），以使贡献风险、证据要求、人工审查和维护者决策权更加明确。Apache Software Foundation（Apache 软件基金会）正在探索 AGENTS.md 如何为 AI 代理明确贡献规则和人工审批边界，而 TODO Group 则在研究代理如何影响开源管理、贡献工作流、治理和来源。这些都是令人鼓舞的迹象。但它们也指向一个更广泛的问题：除了告诉代理如何安全地贡献之外，我们能否让社区自身的治理对它来说是可理解的？

治理应当约束代理

这也是为什么我对“面向 AI 代理的治理”这个说法持谨慎态度。重点不是创建一个平行系统，让自主代理以某种方式获得独立的治理权。社区现有的治理应当约束代理。

如果社区授权，代理可以准备贡献、收集证据、执行常规检查、确定合适的审查者、传递决策并解释它做了什么。它甚至可能能够在社区明确授权自主行动的领域自主行动。但当它到达属于个人、角色或社区本身的边界时，它就会停下来。

代理不会仅仅因为我们给了它访问 GitHub 的权限就成为决策者。

这听起来显而易见，但我不确信我们当前的基础设施能让自主系统足够清楚地认识到这一点。

为什么开源基金会应当关注

我认为开源基金会特别适合探索这一点，不是因为基金会在良好治理方面拥有某种垄断，而是因为成熟的基金会花了几十年时间将协作转变为明确的制度机制。它们的治理往往有文档记录。角色有定义。流程会公开。决策被期望是透明的。权力是有意分散的。治理本身是协作开发的，而不是由商业平台的产品规则定义的。

这给了基金会一些有价值的东西：可以检查、测试并变得更加明确的真实治理系统。这也给了它们一个潜在重要的中立角色。如果代理日益成为人与软件之间的中介，那么存在一种风险：管理参与的规则会变成少数 AI 平台决定它们应该是什么样子。

开源社区可能应当自己保留对那个边界的控制。这部分是中立性的问题。它也可能日益成为一个主权问题。一个社区应该能够说：这些是我们的角色，这些是我们的规则，这就是这里的权力运作方式，这些是人类或机器可以参与的条件。

代理应当适应社区的治理，而不是反过来。

这是可测试的

好消息是我们不需要从理论上回答所有这些问题。我们可以测试它。

选取少数具有不同治理模式的真实开源项目，给代理一个现实的贡献任务。看看它是否能发现相关规则，确定它被授权做什么以及代表谁，完成任何必需的检查，识别谁控制下一个决策，并认识到何时必须停下来并让人类参与。然后，事后看看人类是否能还原代理做了什么、为什么这样做以及依据谁的授权。

几乎无论结果如何，都会很有趣。也许现有的治理文档完全有效。也许它只是需要变得更加明确。也许我们会发现项目以截然不同的方式表达共同的治理概念。或者也许最终会出现一个互操作性问题，需要一套共同的词汇或规范。

我不会一开始就假设我们需要另一个标准。我会先问：如果那些社区中运作的一些参与者是机器，为人类社区设计的治理是否仍然可理解？

这是一个有趣得多的问题。

当代理加入社区时

O’Grady 的“新新造王者”论点从根本上讲是关于权力动态变化的。代理在决定哪些技术被发现和使用方面正变得越来越有影响力。我认为开源应该问一个关于参与的类似问题：如果那些相同的代理开始与生产软件的社区互动，会发生什么？

我认为答案并不是放任自流，也不是给智能体的每一个动作都加一个人工批准按钮。如果一个社区选择允许智能体参与，那么有趣的空间就存在于这两个极端之间。社区可以授权智能体执行已定义的操作，并在需要人类判断的地方准备或转交决策。权限与委托必须明确，问责仍归属于个人和组织，而智能体在触及自身权限边界时就应停止。

开源从来都不仅仅关乎源代码。它也是一种协作模式，用于在可能永远不会为同一家组织工作的人之间分配权力、建立信任并做出决策。如果社区选择允许智能体参与，那么这套体系可能也需要让它们能够理解。

真正有趣的想法不是为机器制定治理规则，而是让机器能够理解并参与治理，同时不忘谁才是真正的掌权者。