OpenAgents：把散落在各处的 AI 代理收进同一个工作区
OpenAgents - The collaboration OS for AI agents
秒懂
- 它是什么？
- OpenAgents 是一个 Apache-2.0 的开源项目，试图用「工作区」把本地和云端的多种 AI 代理统一管理起来，并让它们共享文件、浏览器和对话上下文。它解决的是真实存在的碎片化问题，但协作机制的成熟度仍需验证。
- 适合谁用？
- OpenAgents 适合已经同时使用多个 AI 编码代理、且受困于在终端和 SSH 之间手动拼接上下文的个人开发者或小团队。它不适合那些只需要单一代理、或者对数据隐私极其敏感、不愿让代理流量经过第三方托管工作区的组织。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个工作区，收编所有代理
OpenAgents 解决的问题很具体：你的 Claude Code 在服务器上维护数据库，另一个营销代理在 Discord 上回复用户，还有几个代理在不同机器的终端里写代码。你没有一个地方能看到它们全部，更别说让它们协作。当一个用户报 bug 时，你希望营销代理先收集细节，再把基础设施代理拉进同一对话去查日志。没有统一工具的话，你得在终端之间复制粘贴，SSH 到不同机器，手动拼接上下文。OpenAgents 的核心主张是提供一个类似 Slack 的持久化工作区，但用户是 AI 代理。每个工作区有一个固定 URL，例如 `workspace.openagents.org/abc123`，任何被连接的代理都会出现在这里，人类可以通过浏览器或手机查看和管理它们。这个设计把「代理分散各处」的问题转化为「集中在一个 URL 下」的问题，思路直接，也确实切中多代理使用者的痛点。
协作机制：共享文件、浏览器与上下文
OpenAgents 的协作不是靠代理之间直接通信，而是靠共享资源。README 描述了两个关键机制。第一是共享浏览器，代理可以打开页面、点击元素、截图、填写表单，工作区里的所有成员都能看到这个浏览器的状态。第二是共享文件，代理上传代码、文档和报告后，任何代理或人类都能读取、编辑或下载。再加上对话线程的共享，代理在同一个工作区里能看到彼此的工作，通过 @提及 来分派任务，或者自行拾取工作。这种设计意味着代理之间的「协作」实际上是通过读写同一组状态来完成的，而不是通过复杂的代理间协议。它降低了协调的复杂度，但也带来一个明显的问题：如果两个代理同时操作同一个文件或浏览器标签，冲突如何解决？README 没有给出并发控制的细节，这是采用前需要向项目方确认的点。
安装与启动：CLI 加守护进程
安装 OpenAgents 的路径很清晰。macOS 和 Linux 用户执行 `curl -fsSL https://openagents.org/install.sh | bash`，Windows 用户在 PowerShell 里执行 `irm https://openagents.org/install.ps1 | iex`。安装后得到一个名为 `agn` 的启动器命令。基本流程是：先用 `agn create <name> --type <type> --install` 创建代理并安装运行时，或者先 `agn install <type>` 再创建。然后 `agn connect <name> <workspace-token>` 把代理接入工作区，`agn env <type> --set LLM_API_KEY=sk-...` 设置凭证，最后 `agn up` 启动守护进程，让代理在后台持续运行。直接运行 `agn` 会打开交互式仪表盘。README 强调 `agn create` 只写代理配置，运行时安装需要显式执行或加 `--install` 参数，这个区分值得注意，避免了隐式副作用。另外还有桌面应用可下载，覆盖 macOS、Windows 和 Linux。整个流程设计得相当直接，命令行用户应该能在几分钟内跑通。
支持哪些代理：从 Claude Code 到 Beta 项目
OpenAgents 的价值取决于它能连接多少种代理。README 列出的支持列表相当长：OpenClaw、Claude Code、Codex CLI、Hermes Agent、Cursor、OpenCode、GitHub Copilot CLI、Gemini CLI、Cline、Amp、DeepSeek Harness、Aider 和 Goose。但状态参差不齐。Claude Code、Codex CLI 等标记为「Supported」，而 Aider 和 Goose 是 Beta，DeepSeek Harness 是 Preview。README 对 Aider 的说明特别坦诚：离线测试套件全部通过，包括提供商解析、会话、Git 安全性和安装检测，但尚未对真实模型提供商完成端到端运行。这意味着你如果要用 Aider，得自己承担验证工作。这种分级状态是合理的，一个项目不可能对所有外部代理都做到同等程度的集成。但作为潜在用户，你应该把「Supported」和「Beta」的区别当作重要的风险评估依据，而不是被长长的列表迷惑。
隧道功能与远程访问
除了代理管理，OpenAgents 还提供了一个隧道功能，可以用一条命令把本地开发服务器暴露为公共 URL。README 说这样做的目的是让你从任何设备预览代理构建的成果。这个功能对远程协作场景很有用，比如代理在本地跑了一个 Web 应用，你想在手机上看看效果，或者分享给同事。隧道功能本质上是一个反向代理，把本地端口映射到公网地址。这种机制并不新鲜，类似 ngrok 或 Cloudflare Tunnel 都能做到，但 OpenAgents 把它集成到工作区里，省去了额外安装和配置的步骤。不过，README 没有说明隧道的安全性细节，比如 URL 是否需要认证、是否支持自定义域名、连接是否加密。如果你打算把隧道用于生产环境或敏感数据，这些信息必须提前查清楚。
开源许可证与分发渠道
OpenAgents 采用 Apache-2.0 许可证，这是一个对商用友好的宽松许可证。README 明确写着「No vendor lock-in. No mandatory accounts.」，意思是你可以自由使用、修改和分发代码，不必被迫创建账户。项目同时提供 npm 包 `@openagents-org/agent-launcher` 和 PyPI 包 `openagents`，说明有完整的发布渠道。最近几周发布了多个 launcher 版本，从 v0.9.25 到 v0.9.27，更新频率相当高，表明项目处于活跃开发状态。但活跃开发也意味着 API 和配置格式可能变化较快，升级成本需要纳入考量。由于许可证是 Apache-2.0，即使项目停止维护，你也有权基于现有代码继续开发。这一点对于考虑长期采用的企业用户来说是一个重要的安全网。不过，具体到每个代理的集成代码是否都遵循同样的许可证，需要查看仓库内各子目录的 LICENSE 文件，README 没有提供这个粒度。
局限性与适用边界
OpenAgents 的文档在几个关键方面存在空白。第一，它没有说明工作区的托管方式。README 提到创建工作区通过 `https://openagents.org/api/create-workspace` 这样的 URL，暗示工作区可能是云端托管的，但数据存储在哪里、是否加密、能否自托管，都没有明确。对于一个处理代码和对话上下文的工具，这是重大的信息缺失。第二，共享浏览器和文件机制的并发控制没有说明，多个代理同时操作时可能出现状态冲突。第三，代理之间的「自然协调」听起来很理想，但 README 没有提供任何机制层面的解释，比如代理如何发现彼此的能力，如何避免重复劳动。这些空白意味着 OpenAgents 目前更适合实验和小规模使用，而不是作为关键基础设施。如果你需要的是完全可控、可审计的代理协作环境，在项目文档补上这些细节之前，恐怕得保持谨慎。
编辑结论
OpenAgents 适合已经同时使用多个 AI 编码代理、且受困于在终端和 SSH 之间手动拼接上下文的个人开发者或小团队。它不适合那些只需要单一代理、或者对数据隐私极其敏感、不愿让代理流量经过第三方托管工作区的组织。在决定采用之前，你应该先验证三件事：第一，你常用的代理是否在支持列表中，特别是 Aider 和 Goose 仍处于 Beta 状态，官方明确表示 Aider 尚未完成真实模型提供商的端到端验证；第二，仔细阅读文档中关于工作区数据存储和传输的说明，确认共享浏览器和文件机制是否符合你的安全要求；第三，试用 `agn create` 和 `agn connect` 的完整流程，确认代理安装和连接是否如 README 所声称的在一分钟内完成。如果这些验证通过，OpenAgents 的「统一工作区」思路确实能减少多代理场景下的手工协调成本。
社区笔记