直接答案： 对多数团队来说，用 AGPL-3.0 工具来构建你自己的软件，并不会让你的软件变成 AGPL——许可证约束的是工具本身，而不是你用它写出的代码。真正让人意外的义务是网络条款：如果你修改了工具，并让他人通过网络使用你修改后的版本，你必须向他们提供其源码。本文为通用信息，非法律意见；请结合你的具体情况咨询律师。
开源 AI 编程平台越来越多地以 GNU Affero 通用公共许可证 v3.0 发布。它是一种强 copyleft 许可证，其名声让一些工程负责人对采用 AGPL 工具心存顾虑。这些顾虑大多源于混淆了两件截然不同的事：使用软件，和修改并再分发软件。
AGPL-3.0 是什么，特别在哪
AGPL-3.0 是 GPL 家族中面向网络时代最强的 copyleft 许可证。它带有通常的 GPLv3 义务——当你**传播（分发）**软件或其修改版本时，必须以相同许可证提供对应源码——并额外增加了一个触发条件。
这个新增就是 第 13 条“远程网络交互”（Remote Network Interaction）。依据自由软件基金会发布的许可证正文：如果你修改了程序，并让用户通过计算机网络远程与你修改后的版本交互，你必须给这些用户提供获取你修改版本对应源码的机会。这就是网络条款，它堵上了普通 GPL 留下的“SaaS 漏洞”。
化解多数顾虑的关键区分
这里是团队最常搞错的地方：运行一个程序，与创作它的衍生作品，不是一回事。依据 FSF 的 GNU 许可证常见问题解答，程序的输出通常不受该程序许可证的约束，除非输出本身包含了程序的一部分。
说白了：如果你把一个 AGPL-3.0 编程平台当作工具来写你自己的应用，那你的应用是你的。AGPL 约束的是平台的源码，而不是你用它产出的源码。这与AI 生成代码的版权归谁中的思路一致——工具的许可证与你产出物的归属，是两个独立的问题。
所以真正的风险不是“采用 AGPL 软件会传染我们的代码库”。它更窄、更具体：如果我们修改了工具本身，又如何分发或暴露那个修改版本？
义务何时真正触发
从许可证正文出发，三种大致情形表现迥异。（再次说明：通用信息，非法律意见。）
- 内部、未修改地使用。 你在组织内部运行工具，不修改也不分发。这是最轻的一种；网络条款由“把修改后的版本提供给外部用户”触发。
- 你修改了工具。 一旦改动源码，当你传播修改版本、或依据第 13 条向远程用户暴露它时，copyleft 义务就附着到这些改动上。
- 你把它作为网络服务提供。 如果你托管一个修改版本并让外部用户通过网络与之交互，第 13 条要求你向他们提供你所做修改的对应源码。
关键的轴不是“内部 vs. 外部”，而是未修改地使用 vs. 修改并暴露。
实用合规清单
- 盘点 你技术栈中哪些 AI 工具是 AGPL-3.0，包括传递性组件。
- 隔离 工具与你的产品：确认你的应用是把它当作独立的服务/工具来调用，而不是把它的源码拷进你的代码。
- 追踪修改。 如果你 fork 或打补丁，把这些改动保持可识别并纳入版本控制。
- 确定暴露方式。 如果你可能把修改版本通过网络提供给外部用户，就计划公开你所做修改的对应源码。
- 保留声明 与许可证文件；不要删除署名或 LICENSE。
- 做法务审查，再据此进行任何商用部署。参见直接答案：AGPL-3.0 对 MonkeyCode 意味着什么以及能否商用。
MonkeyCode 的定位
MonkeyCode 的仓库以 GNU AGPL-3.0 发布，意味着代码可审计、可 fork，并附带上述义务。对多数“运行它来开发自己软件”的采用者而言，这是一种可管理、被充分理解的安排——与许多开源基础设施工具的画像相同。许可证指南给出了事实性概述与法务审查边界，而什么样的开源 AI 编程平台才算为团队准备好了讲的是采用落地层面。
结论
AGPL-3.0 比 MIT 或 Apache-2.0 更严格，但对常见情形——用工具来构建你自己的产品——它并不触及你的代码。唯一需要审慎的地方是“修改 + 网络暴露”，此时第 13 条要求你分享改动的源码。盘点你的 AGPL 工具、让任何修改保持可识别、尽早确定暴露模式，并让律师就你的部署确认具体细节。
本系列相关文章
来源边界： AGPL-3.0 的义务依据自由软件基金会发布的许可证正文与 GNU 许可证常见问题解答（核验于 2026 年 7 月 20 日）归纳，作为通用教育性信息解读。本文不构成法律意见，许可证解释取决于你的具体事实——在据此进行商用部署前，请咨询合格律师。MonkeyCode 的许可证以其公开仓库为准，应对照当前 LICENSE 文件确认。