OpenAgents：把「一群 AI 智能体」变成一个可协作团队

OpenAgents Workspace —— 一个工作空间，装下你所有的 AI 智能体。

一、一个具体到疼的场景

先讲一个几乎每个用 AI 编码的人都遇到过的画面。

你的团队里有三个智能体：一个跑在云端服务器上，负责维护生产数据库；一个跑在本地 Mac 上，盯着 GitHub issue 做初筛；还有一个跑在另一台测试机上，专门处理用户反馈。一个用户报了个 bug，你希望营销 bot 先去跟用户问清楚细节，再把基础设施 agent 拉进同一个对话里一起看日志。

传统做法是：在三个终端之间复制粘贴，SSH 到不同机器上手工拼上下文，经常在第三步丢失关键信息。智能体之间彼此看不见，人和智能体之间也没有共同的"工作现场"。

OpenAgents 要解决的就是这件事——把 Slack 的形态搬到智能体世界：一个持久 URL（如 workspace.openagents.org/abc123）就是你的 AI 团队大本营，任何智能体、任何设备、任何人都能通过它汇合。

二、它是什么：从 SDK 演化成平台的三层结构

OpenAgents 起家于一个 Python 多智能体网络 SDK，如今长成三层产品。这个演进史本身就是它的技术路线图：

层	形态	职责
Workspace	浏览器 Web 应用	协作发生的地方：共享线程、文件、知识库、实时浏览器、任务看板、工作流与例程
Launcher	桌面应用（Electron）+ agn CLI	智能体管理层：安装运行时、配置密钥、配对连接、后台守护进程
Network SDK	Python 库（pip install openagents）	扩展层：让开发者构建自定义智能体网络，支持 MCP 与 A2A 协议

技术栈上，前端是 Next.js 16 + React 19 + Tailwind 4 + shadcn/ui（Radix），后端是 FastAPI + SQLAlchemy 2.0 + Alembic + PostgreSQL 16 + Redis，桌面端是 Electron + Vite。语言构成上 TypeScript（约 988 万字节）与 Python（约 900 万字节）几乎平分秋色——这在 AI 项目里并不常见，它说明这是一个真正"前端产品 + 后端服务 + 客户端"三线并行的工程，而不是套壳 Demo。

三、类比：它相当于智能体时代的 Slack + GitHub Desktop

如果你熟悉旧工具，可以这样对位：

• Slack 的线程 → OpenAgents 的 Threads，@mention 一个智能体就是给它派活；多个智能体在同一个线程里能互相看见对方干了什么
• Slack 的共享文件 → 智能体上传的代码、文档、报告，任何人或智能体都能读改下载
• Chrome DevTools 的 Live browser → 共享浏览器：智能体可以打开页面、点击元素、截图、填表单，团队成员实时围观，必要时随时"抢过"方向盘
• GitHub Desktop / systemd → Launcher 的 agn up，把智能体当服务托管，崩溃自启、后台常驻
• ngrok → 内置 Tunnels，一条命令把本地 dev server 暴露成公网 URL，任何设备都能预览智能体做出来的东西

这个类比不是营销话术，而是它功能设计的直接来源——项目文档里反复出现 "persistent hub"、"proactive thread"、"passive replies" 这类词。

四、核心能力拆解

4.1 多智能体接入：10+ 运行时统一编排

Launcher 支持的智能体覆盖面相当宽：Claude Code、Codex CLI、Cursor、Gemini CLI、GitHub Copilot CLI、Cline、Amp、OpenCode、OpenClaw、Hermes Agent，另有 DeepSeek Harness（预览）、Aider 与 Goose（Beta）。每个适配器负责一件很具体的事——把该 CLI 拉进 headless/脚本模式，并在"每个 channel 一份独立会话"的前提下正确续接上下文。

以 Aider 适配器为例：它用 --message-file 跑非交互模式，强制加 --no-auto-commits --no-dirty-commits（避免智能体偷偷提交你的代码）、--no-gitignore（不篡改你的 .gitignore），并把 .aider* 写进 .git/info/exclude 而不是提交进仓库。会话历史存放在 ~/.openagents/sessions/aider/，绝不落在你的项目目录里。这些细节说明作者认真处理过"AI 智能体在真实仓库里搞破坏"这个经典痛点。

密钥处理同样克制：通用 LLM_API_KEY 通过环境变量注入，绝不进 argv、绝不进日志；provider 显式指定时优先于模型名推断，遇到明显冲突（anthropic + openai/...）直接报错而不是猜测。

4.2 共享浏览器：智能体的"可视调试"

Workspace 内置基于 Playwright 的共享浏览器上下文，配合 Pillow 做预览帧缩放。智能体可以真正操作一个所有人都看得见的浏览器窗口。这解决了 agent 最难被信任的问题——你不用再猜它到底干了什么，可以看着它点。

4.3 权限与协作治理

v1.1 版本引入了一系列企业向特性：私有化默认（智能体和设备属于你）、按成员/智能体/群组授权、角色化路由（一个 agent 干活、另一个 agent 复核）、知识库文件夹组织、Issues 看板（负责人、参与者、标签、讨论）、审批机制（谁来批准 agent 的动作）、以及自定义模型端点验证。

4.4 自动化：Workflows 与 Routines

除了手动 @mention，工作流和例程（routines）允许把重复性的调度交给系统。数据库迁移记录里能看到 010_add_routines、013_routines_per_agent_channel、014_routines_context_per_routine_channel ——例程可以按 agent、按 channel 绑定上下文，这已经接近"多智能体团队的排班系统"。

五、上手门槛：两条路径，差别很大

路径 A：只开云端 Web（零安装） 打开 openagents.org，用 Google/GitHub/邮箱登录，workspace 自动创建。用 Cloud Agent 填个 API Key 就能 @mention 它。难度：几乎为零，1 分钟内可跑通。 新账号还送 $100 模型额度。

路径 B：自托管全平台（工程量） 仓库 workspace/ 目录下自带 docker-compose.yml，编排三件套：PostgreSQL 16、FastAPI 后端（backend.Dockerfile，另有 production.Dockerfile）、Next.js 前端（frontend/Dockerfile）。加上 Redis（后端有 redis>=5.0.0）、可选的 Firebase（登录 + 移动推送，firebase-admin>=6.1.0）和 Playwright 浏览器依赖。

需要注意的运维复杂度信号：后端 requirements.txt 里明确注释了 sqlalchemy>=2.0.0,<2.1，原因是 2.1 改了 postgresql:// 的驱动解析方式会导致 Railway 部署在 import 阶段崩溃；firebase-admin 锁 >=6.1.0 是因为 6.0 的 send_multicast 已被移除。而 workspace/backend/ 目录里赫然放着 INCIDENT-2026-10-09.md 和 INCIDENT-2026-10-25.md 两份事故记录。这是一个真实在跑、真实出过故障、真实在修的线上系统，而不是玩具。

路径 C：本地智能体（Launcher） curl -fsSL https://openagents.org/install.sh | bash 装 agn CLI，或直接下桌面版（macOS / Windows / Linux AppImage）。然后 agn create → agn env --set 配密钥 → agn connect <token> → agn up。桌面端则是 Electron 打包，带 playwright e2e 测试和 electron-builder 自动更新配置。

六、争议与局限：不粉饰

1. Beta 状态是真实的。 README 自己写明：Aider 和 Goose 的离线测试全过，但针对真实模型提供商的端到端验证仍未完成（"real E2E pending"）。这是很诚实的披露，但也意味着这两条路径你可能要自己趟坑。
2. Headless 模式下的权限降级。 Goose 在 headless 下无法暂停等人工审批，被强制降级为 GOOSE_MODE=auto（工具直接执行不提示）；同时 --no-profile --with-builtin developer 意味着你全局启用的扩展、电脑控制、浏览器控制和第三方 MCP Server 都不会被加载。Goose 没有目录沙箱，工作目录只是约定而非硬边界。
3. 安全模型偏乐观。 README 强调"无强制账号"、"Agent 私有默认"，但智能体拥有 shell 访问权、文件写入权和浏览器控制权，这些组合起来是相当大的攻击面。部署到生产环境前应自行评估容器隔离与密钥边界。
4. 重但全。 3618 个文件、1090 个在 workspace、1028 个在 packages、1018 个在 sdk——你要"轻装上阵"地用一个 agent 编排能力，代价是拉进一个相当重的 monorepo。
5. 依赖仍在快速变动。 Python 侧用 pydantic>=2.0.0、openai>=1.98、litellm>=1.80.0,<1.87 这种带上限的宽松约束，说明团队也在与上游 API 漂移赛跑。

七、行业意义：多智能体协作正在被"产品化"

OpenAgents 的 star 数（4315）、fork 数（451）以及合作方名单——PeakMojo、AG2、LobeHub、Jaaz、Eigent、Youware、Memu、Sealos、Zeabur、智谱 Z.AI、MiniMax、BISHENG、FastGPT、Hyperbolic——描绘出了一个清晰的行业轮廓：

2023-2024 年是"单智能体工具"竞争期，大家比的是谁的工具调用更稳；2025 年是"框架"期，LangChain、AutoGen、CrewAI 争夺编排抽象；2026 年正在进入"协作平台"期——竞争点变成了"人怎么和一群智能体共处在一个工作空间里"。OpenAgents 把这个命题具象化成了 Slack 的形态，并且罕见地同时开源了 Workspace、Launcher 和 SDK 三层。

它 2025 年 3 月才建仓，到现在已经迭代到 v1.1、接入 10+ 智能体运行时、支持 MCP/A2A 协议、宣称部署在 100+ 公司。README 里那句 "OpenAgents started as a Python SDK for multi-agent networking and has grown into a full platform"，正是这条演进路径的注脚。

对关注 AI Agent 落地的人来说，这个项目的价值可能不在于直接用起来，而在于它示范了一个更成熟的交互范式：智能体不再是聊天框里等着你提问的应答机，而是有工位、有排班、有权限、有同事的"数字同事"。这条路的终点，或许就是每个工程团队都需要认真回答的问题。

---

数据采集时间：2026-11-04 | GitHub: openagents-org/openagents | License: Apache-2.0 | Archived: false