AgentRQ
让人类与 AI 代理实时协作、分派任务并审批敏感操作。
- Star 数
- ★ 1.2k
- 最近更新
- 今天
- License
- AGPL-3.0
- 主语言
- Go
- FA 评分
- 64/100 · 存在缺口
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台Codex · Claude Code
- 费用
- 软件免费,模型调用费用自付
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- 同时运行多个 Claude Code 项目的开发者,为每个项目配置独立的工作区 MCP 地址,让代理领取任务并把进度同步回统一仪表板。
- 不适合
- 不想配置 Google OAuth2 与自建服务的个人用户
- 需要高可用、外部数据库或备份恢复的生产团队
- 源码审查
- 64/100 · 存在缺口
这个 Agent 能做什么,适合哪些场景?
AgentRQ 是一个可自托管的人机协作与任务管理平台,由 Go/Fiber 后端、Vue 3/Vite 前端、工作区级 MCP 服务和全局 CoreMCP Supervisor 组成。人类可以拆分目标、分派任务并回复代理,代理则通过 MCP 获取任务、更新状态、创建任务、下载附件和发送消息。平台使用内部发布/订阅机制和 SSE,在仪表板与代理会话之间同步任务变更、消息和权限请求。数据通过 GORM 持久化到 SQLite,身份验证采用 Google OAuth2 和基于 JWT 的会话。除 Claude Code 的原生通道集成外,项目还提供面向 ACP 代理、OpenAI Codex、Gemini CLI 和 DeepSeek Harness 的网关或扩展,并支持 Docker 自托管。
每个工作区提供独立的 MCP URL 和令牌;代理通过 getWorkspace 读取工作区名称、使命和任务统计,通过 getTask 按 ID 查询任务,或领取下一个分配给自己的 notstarted 任务。代理可以调用 createTask 创建普通或带 cron_schedule 的周期任务,调用 updateTaskStatus 在 notstarted、ongoing、blocked 和 completed 之间推进状态,并用 reply 将消息实时发送到仪表板。downloadAttachment 用于按 ID 获取附件,而 notifications/claude/channel 会把人类对任务的交互通知给 Claude Code。对于不原生接收该通知协议的 ACP 客户端,@agentrq/acp-gateway 读取项目中的 .mcp.json,启动代理子进程并在 ACP 与 MCP 之间转发任务、消息和权限请求;@agentrq/codex-gateway 则连接 MCP 与 Codex app-server。全局 CoreMCP Supervisor 可跨工作区执行 listWorkspaces、listAllTasks、updateTaskAssignee、respondToTask、getAttachment 等管理操作,并输出更新后的任务、会话和工作区状态。
- 同时运行多个 Claude Code 项目的开发者,为每个项目配置独立的工作区 MCP 地址,让代理领取任务并把进度同步回统一仪表板。
- 需要人工审批敏感操作的团队,通过任务会话接收代理的权限请求,再由 Supervisor 的
respondToTask提交允许或拒绝决定。 - 管理多个项目的负责人,通过 CoreMCP 汇总所有工作区任务、调整负责人和优先级,并查看工作区统计。
- 使用 Gemini CLI 或其他 ACP 代理的团队,通过
@agentrq/acp-gateway将实时任务通知送入正在运行的代理会话。 - 使用 OpenAI Codex 的工程团队,通过
@agentrq/codex-gateway和项目级 MCP 配置接收任务,并让 Codex 在执行期间更新状态和回复。 - 有周期性协作流程的团队,使用带
cron_schedule的createTask建立计划任务,并在 Web 界面与代理之间实时同步。
如何安装或部署这个 Agent?
本地开发需要 Go 1.21+、Node.js 18+ 与 npm,以及 Google Cloud Console 中创建的 OAuth2 Client ID 和 Secret。在 backend/_config/base.yaml 或 backend/_config/development.yaml 中配置凭据:
auth:
google:
client_id: "your-google-client-id"
client_secret: "your-google-client-secret"从仓库根目录安装依赖并启动前后端:
make install
make dev前端随后运行在 http://localhost:5173。生产或开发环境也可使用预构建 Docker 镜像自托管,但所给材料未列出完整的 Docker 命令,而是将这些命令放在 SETUP.md。如需 ACP 网关,可全局安装:
npm install -g @agentrq/acp-gateway如需 Codex 网关,可全局安装:
npm install -g @agentrq/codex-gateway@latest如何使用这个 Agent?
在 AgentRQ 工作区的 Setup 弹窗中取得工作区 ID、完整 MCP URL 和令牌。Claude Code 项目根目录创建 .mcp.json:
{
"mcpServers": {
"agentrq-WORKSPACE_ID": {
"type": "http",
"url": "YOUR_MCP_URL"
}
}
}再创建 .claude/settings.local.json,启用服务器并预批准所列 AgentRQ 工具:
{
"permissions": {
"allow": [
"mcp__agentrq-WORKSPACE_ID__updateTaskStatus",
"mcp__agentrq-WORKSPACE_ID__getWorkspace",
"mcp__agentrq-WORKSPACE_ID__reply",
"mcp__agentrq-WORKSPACE_ID__createTask",
"mcp__agentrq-WORKSPACE_ID__downloadAttachment",
"mcp__agentrq-WORKSPACE_ID__getTask"
]
},
"enableAllProjectMcpServers": true,
"enabledMcpjsonServers": ["agentrq-WORKSPACE_ID"]
}从该项目目录启动 Claude Code:
claude --dangerously-load-development-channels server:agentrq-WORKSPACE_IDGemini CLI 或其他 ACP 代理可在同一项目根目录保留 .mcp.json,然后执行:
acp-gateway -- gemini --acpCodex 需要同时配置供代理调用工具的 .codex/config.toml,以及供网关接收任务的 .mcp.json。最小网关连接文件为:
{
"mcpServers": {
"agentrq": {
"type": "http",
"url": "https://<WORKSPACEID>.mcp.agentrq.com/mcp?token=<TOKEN>"
}
}
}然后在包含该文件的工作区根目录运行:
codex-gateway如需显式指定 Codex 命令,可运行:
codex-gateway -- codex app-server这个 Agent 有哪些优点和局限?
- 工作区级 MCP 与全局 CoreMCP 分层:既能隔离单个项目,又能跨工作区统一查询、分派和管理任务。
- 任务、消息和权限请求通过 SSE 与代理通道实时传递,不必只依赖轮询任务队列。
- 除 Claude Code 原生通道外,还提供 ACP、Codex、Gemini CLI 和 DeepSeek Harness 的明确接入路径。
- 可自托管,后端、前端、SQLite 数据层和认证边界均有明确说明。
- 任务接口覆盖状态流转、附件、对话分页、周期任务和人工允许/拒绝决定。
- 本地完整栈同时要求 Go 1.21+、Node.js 18+、npm 和 Google OAuth2 凭据,部署与身份配置成本不低。
- 非 Claude Code 客户端可能需要额外网关或扩展;README 明确指出 Gemini CLI 要借助 ACP Gateway 才能接收实时通知。
- Codex 接入需要同时维护
.codex/config.toml和.mcp.json,分别承担工具调用与任务接收,配置面较大。 - 工作区令牌直接出现在 MCP URL 配置中,采用方需要自行妥善管理这些配置文件和令牌。
- 所给材料未提供高可用部署、外部数据库、备份恢复或规模上限的证据;数据层只明确为 SQLite。
这个 Agent 与同类方案有什么区别?
与 Claude Code 的原生 claude/notifications 通道相比,Gemini CLI 等 ACP 代理需要 @agentrq/acp-gateway 来转发实时通知;OpenAI Codex 则使用独立的 @agentrq/codex-gateway 桥接 MCP 与 Codex app-server。Claude Code、Gemini CLI 和 DeepSeek Harness 还各有官方扩展或插件路径,但接入命令和配置格式不同。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| AgentRQ 当前 | 64 · 存在缺口 | 自托管服务免费 + 模型费 | ★ 1.2k | 今天 | Go | Codex · Claude Code |
| Lotti 私人日志与任务助手 | 80 · 表现良好 | 桌面应用免费 + 模型费 | ★ 1.2k | 今天 | Dart | OpenAI API · Claude API |
| SurfSense 开放网络研究平台 | 52 · 缺口较多 | 自托管服务免费版 + 付费版 | ★ 17k | 2 天前 | Python | Claude.ai · OpenAI API |
| 活动策划多智能体系统 | 62 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 115 | 5 个月前 | Python | — |
FollowAgents 如何评估这个 Agent?
查看各维度的扣分理由
证据展示了按工作区隔离的 MCP 配置、用户作用域存储、OAuth/JWT、权限请求及 CI 的只读仓库权限;工具及 Supervisor 的外部作用也列得较清楚。扣分原因是文档建议预先批准多个有写入或下载能力的工具并使用危险开发通道,Supervisor 权限覆盖全部工作区;令牌直接置于 URL,未说明日志泄露防护、加密、轮换、撤销或保留策略;也没有依赖漏洞扫描或供应链验证证据。暂停和任务状态提供有限恢复手段,但没有系统性撤销、审计回滚或数据恢复说明。项目、扩展和第三方获得一定署名,但维护主体身份仍不明确。
README、工作流和 DeepSeek 插件测试总体形成一致的架构与行为描述;测试覆盖格式解析、畸形负载拒绝、重复推送抑制、暂停/恢复、断线状态及启动失败警告。扣分在于证据只覆盖一个插件子集而非整个平台,部分 MCP URL 和占位符写法不完全统一;运行仍依赖 Google OAuth、npm 包、Docker Hub、外部 CLI 和网络服务。错误可记录为警告或拒绝无效输入,但缺少平台级错误分类、用户补救指引和端到端故障证据。
文档充分覆盖人工操作员、自托管用户以及 Claude、Codex、Gemini、DeepSeek、ACP、Slack 和多工作区 Supervisor 等场景,因此受众和环境适配证据较强。工具清单、工作区边界、配置开关、暂停和单代理范围说明了不少能力边界;扣分是 Supervisor 权限很广,安全边界和不支持场景未系统列出。推送、队列领取、启动补偿、去重及空/畸形消息处理有测试,但推送内容被直接转交代理且文档鼓励预授权,触发控制仍不算彻底。
README 的概览、架构、安装、各网关、Supervisor、扩展、集成、署名和许可证组织清楚,并提供大量可复制示例;本地与 Docker 前置条件也明确。扣分是 WORKSPACE_ID、<ID>、服务名及带不带 /mcp 的 URL 示例存在轻微不一致;没有集中 FAQ 或完整限制清单。Apache-2.0 正文完整,发布工作流支持 v* 和语义版本镜像标签,但未提供版本政策、变更日志或迁移说明。Discord、网站和仓库暗示更新渠道,却没有清楚声明维护责任人或支持承诺,且给定出版者身份未知。
任务、状态、回复、附件、实时推送、权限响应和多工作区管理形成可直接使用的协作输出;测试还验证了任务 ID、工具名和消息框架不会因换行内容被伪造,输出可用性证据较强。多种代理桥接和统一工作区体现了相对于普通任务列表的增量价值,但没有用户结果、比较研究或性能数据。自托管可能降低平台依赖,但仍需 Go、Node、OAuth、数据库、网关及运维,来源没有量化部署成本、资源消耗或收益。
架构、工具、配置和发布声明能对应到 README、工作流及插件测试,测试注释也将部分解析格式联系到后端行为,因此具备中等可追溯性和跨文件印证。扣分是提供的代码仅验证 DeepSeek 插件的一部分,无法交叉确认认证、存储、Supervisor、Slack、Docker 或整体安全声明;“高性能”“无缝”“安全”等宣传性表述没有与实测事实、假设或限制清晰分开。
- 文档建议将令牌放入 MCP URL;应避免把含令牌的 URL 提交到版本控制、终端历史、遥测或日志,并在部署前确认轮换和撤销流程。
- 预授权 createTask、updateTaskStatus、reply、downloadAttachment 等工具以及危险开发通道会减少逐次确认;应按工作区和任务缩小权限,并保留人工审批。
- Supervisor 可跨全部工作区执行管理操作;在没有明确审计、回滚和恢复机制的证据下,不宜默认授予生产环境代理。
- 本次为仅基于所给文件的静态审查,未执行代码,也未验证依赖漏洞、容器镜像、认证实现或端到端行为。
最近版本
来自该项目 GitHub Releases 的最新发布记录,说明为上游原文摘录,未经本站改写或测试。
-
发布说明摘录
What's Changed * feat(license): publish agentrqd and its installers under Apache-2.0 by @mustafaturan in https://github.com/agentrq/agentrq/pull/972 * feat(server): ship the server as one binary with the web app built in by @mustafaturan in https://github.com/agentrq/agentrq/pull/973 * fix(supervisor): clear context by default in the supervisor workspace by @mustafaturan in https://github.com/agentrq/agentrq/pull/975 * chore: bump minor version to v0.13.0 by @mustafaturan in https://github.com/agentrq/agentrq/pull/974 …在 GitHub 查看 ↗ -
发布说明摘录
What's Changed * feat(acp): /logout logs a native ACP v1 agent out by @mustafaturan in https://github.com/agentrq/agentrq/pull/958 * fix(app): fit the Spin up panel on a phone screen by @mustafaturan in https://github.com/agentrq/agentrq/pull/959 * fix(acp): count a call as the workspace's own only under its exact server names by @mustafaturan in https://github.com/agentrq/agentrq/pull/960 * feat(acp): show a native ACP v1 agent's notices in the trajectory and as a toast by @mustafaturan in https://github.com/agentrq/agentrq/pull/961 …在 GitHub 查看 ↗ -
发布说明摘录
What's Changed * test(repository): fail on SQL text built at run time by @mustafaturan in https://github.com/agentrq/agentrq/pull/941 * fix(acp): check ToolCall.name in workspaceTool for ACP v1 tool calls and permissions by @mustafaturan in https://github.com/agentrq/agentrq/pull/940 * fix(acp): return accept when elicitation/complete resolves a waiting URL elicitation by @mustafaturan in https://github.com/agentrq/agentrq/pull/942 …在 GitHub 查看 ↗
常见问题
必须使用托管版 AgentRQ 吗?
make install 和 make dev 启动;不过所给材料没有列出完整 Docker 命令。它是否只能配合 Claude 使用?
敏感命令如何由人类审批?
respondToTask,用于提交允许或拒绝决定。