org2AI/ORG2 是什么？

ORG-2 是一个本地优先的 Rust 桌面应用，用来运行、记录和回放多个编码智能体的会话。它试图回答一个 Git 回答不了的问题：这行代码为什么存在。

org2AI/ORG2 可以商用吗？

可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。

org2AI/ORG2 还在维护吗？

在维护。仓库最近一次提交在 4 天前。

org2AI/ORG2 是用什么编程语言写的？

主要是 TypeScript（依据 GitHub 的语言统计）。

ORG-2 评测：智能体编码会话的记录系统，支持回放与 AI blame

Q: org2AI/ORG2 还在维护吗？

在维护。仓库最近一次提交在 4 天前。

秒懂

它是什么？: ORG-2 是一个本地优先的 Rust 桌面应用，用来运行、记录和回放多个编码智能体的会话。它试图回答一个 Git 回答不了的问题：这行代码为什么存在。
适合谁用？: ORG-2 适合那些已经让编码智能体参与日常开发、并且需要向团队或客户解释每一行代码由来的团队。它不适合只想快速跑一个智能体、不关心过程记录的开发者，因为 AGPL-3.0 和本地优先的架构意味着你要么接受开源义务，要么自己托管服务。
能商用吗？: 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
还在维护吗？: 在维护。仓库最近一次提交在 4 天前。
用什么语言写的？: 主要是 TypeScript（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月8日 · org2AI/ORG2

Git blame 不够用了，问题出在智能体

当人类写代码时，Git blame 已经足够回答“谁改了这一行”。但智能体写代码时，一个提交背后可能是几十次工具调用、多轮提示词、甚至跨会话的记忆。Jira 只看到工单，Codex 只看到自己的会话，GitHub 只看到提交的行。ORG-2 的定位就是把这些碎片拼成一条完整的轨迹。它的目标用户不是单个开发者，而是需要向团队、审计或客户解释代码来源的组织。README 里有一句话点明了动机：“code written on Monday is legacy by Friday”，智能体速度下，周一写的代码周五就过时了，传统工具跟不上这种节奏。

记录的不是 diff，是决策链

ORG-2 的核心机制是把每次智能体会话变成一条可回放的轨迹。这条轨迹包含消息、工具调用、文件编辑和命令输出，全部同步在一条时间线上。它不满足于展示最终 diff，而是把“人类要求了什么、智能体理解了什么、实际做了什么”三者关联起来。这就是它所谓的 AI blame：从一行代码回溯到驱动它的会话、工具调用和决策。Git blame 只能告诉你谁碰过这行，AI blame 试图告诉你为什么碰。实现上，内置的 Rust harness 负责本地执行，而外部 CLI 的会话则通过导入和回填来纳入记录。这种设计意味着记录覆盖范围取决于导入器的完整性，而 README 提到支持 10 多个应用和 15 多个 CLI，但具体列表被截断，需要到仓库确认。

本地优先的 Rust 运行时，体积控制在 100MB 内

ORG-2 用 Rust 和 Tauri 构建，强调 local-first 执行，磁盘占用低于 100MB。这对桌面应用来说是一个明确的设计选择：不依赖云端服务，会话数据留在本机。内置的 Rust harness 可以直接用现有的 API key 和 agent 订阅运行智能体，不需要额外配置服务器。Tauri 意味着前端是 Web 技术，但后端是 Rust，启动速度和内存占用通常优于 Electron 方案。对于需要处理长会话轨迹回放的场景，本地存储减少了网络延迟，但也带来了多设备同步的问题。README 提到团队协作和跨设备共享会话，这部分依赖自托管 Supabase，且标注为 WIP。也就是说，单机使用是成熟的，团队协作功能还在建设中。

从安装到运行，路径是下载即用

安装方式很直接：从 GitHub Releases 下载对应平台的安装包。macOS Apple Silicon 有 dmg，Windows 有 exe 和 MSI，Linux 有 AppImage 和 deb。没有提供 Homebrew 或 apt 仓库，这意味着更新需要手动下载或依赖应用内更新机制（README 未提及）。运行后，你可以选择用内置 Rust harness 启动新会话，或者导入其他 CLI 的历史会话。支持的 CLI 包括 Cursor CLI、Claude Code、Codex、Kiro CLI、GitHub Copilot、OpenCode、Antigravity、Kimi Code CLI 等。配置方面，README 提到“使用你现有的 API keys 和 agent 订阅”，但没有给出具体的配置文件名或环境变量，这部分需要安装后查看应用内文档。

设计模式与资源感知，是亮点也是负担

ORG-2 不止记录，还提供主动干预能力。Design Mode 允许在原生 WebKit 浏览器中检查实时页面，选中元素后把精确的页面上下文发送给智能体，让它直接修复。这比手动复制 HTML 片段更准确，但也意味着你必须信任智能体对页面上下文的解读。另一个特性是资源感知执行：智能体可以根据 CPU、RAM 和人类注意力可用性来调整行为。这听起来聪明，但实现复杂度高，而且 README 没有说明具体如何配置阈值。对于普通用户，这些特性可能增加学习成本。如果你只需要记录和回放，这些额外功能可能成为干扰。

AGPL-3.0 许可证，对商业团队是硬约束

ORG-2 采用 AGPL-3.0 许可证。这是一个强 copyleft 许可证，要求任何修改版本在网络服务中使用时必须开放源代码。对于内部工具，这可能不是问题，但如果你打算基于 ORG-2 构建商业产品，或者修改后以服务形式提供给外部用户，就必须仔细评估义务。README 提到团队协作功能依赖自托管 Supabase，这意味着如果你部署协作服务，整个服务栈可能都受 AGPL 约束。这不是法律建议，但工程团队在采用前应该咨询法务。相比之下，如果只是本地使用，不修改代码，AGPL 的影响较小。许可证的严格性可能会让一些企业团队转向替代方案。

替代方案：从单一工具到自建管道

ORG-2 的替代品不是某个单一工具，而是你现有的工具链。比如，你可以用 Codex 自己的会话记录加上 Git 提交信息来手动追溯，但这需要跨工具切换，正是 ORG-2 想消除的痛点。另一个方向是自建管道：用 CI 系统抓取智能体的 stdout 日志，用 Elasticsearch 索引，再用 Kibana 可视化。这种方法灵活，但需要大量工程投入，而且无法自动关联工具调用和文件编辑。还有一个选择是使用商业的 AI 开发平台，它们可能提供内置的会话管理，但通常绑定特定智能体，不支持 20 多个 CLI。ORG-2 的差异化在于它试图做“系统记录”，而不是又一个智能体 IDE。如果团队已经深度使用多个智能体，这种跨工具的统一记录才有价值。

编辑结论

ORG-2 适合那些已经让编码智能体参与日常开发、并且需要向团队或客户解释每一行代码由来的团队。它不适合只想快速跑一个智能体、不关心过程记录的开发者，因为 AGPL-3.0 和本地优先的架构意味着你要么接受开源义务，要么自己托管服务。采用前先验证三件事：你的智能体 CLI 是否在支持列表内，历史会话导入是否覆盖你使用的工具，以及团队协作功能是否依赖自托管 Supabase，因为 README 明确标注该部分为 WIP。若这些条件成立，ORG-2 提供的轨迹回放和 AI blame 是目前少有的、能把智能体行为纳入工程审计的方案。

官方来源

社区笔记