AgentRQ
让人类跨设备实时分派、监督并协作处理 AI 代理任务。
证据展示了按工作区隔离的 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 可跨全部工作区执行管理操作；在没有明确审计、回滚和恢复机制的证据下，不宜默认授予生产环境代理。
- 本次为仅基于所给文件的静态审查，未执行代码，也未验证依赖漏洞、容器镜像、认证实现或端到端行为。
这个 Agent 能做什么，适合哪些场景？
AgentRQ 是一个可自托管的人机协作与任务管理平台，以共享工作区连接操作人员和 AI 代理。后端采用 Go、Fiber、GORM 与 SQLite，提供 REST API、工作区级 MCP 服务、全局 Supervisor MCP 服务以及基于 SSE 的实时事件通知；前端使用 Vue 3、Vite、Pinia 和 Tailwind CSS。代理可领取任务、更新状态、创建交给人类的任务、收发对话、下载附件，并就敏感操作请求许可。每个工作区拥有独立的 MCP URL 和令牌，而 Supervisor 通过 OAuth2 跨工作区管理任务、统计信息和权限。项目明确支持 Claude Code，并分别通过 ACP Gateway、Codex Gateway 和 DeepSeek Harness 插件连接 Gemini CLI、OpenAI Codex 与 DeepSeek Harness。它适合希望掌控部署和任务数据、并愿意维护完整 Web 服务及认证配置的团队，而不是只需要单次对话助手的用户。
用户在 AgentRQ 工作区中拆分目标、创建任务并把任务分派给代理。代理通过工作区 MCP 服务调用 getWorkspace、getTask、createTask、updateTaskStatus、reply 和 downloadAttachment：getTask 可按 ID 读取任务，也可领取下一个分配给该代理且状态为 notstarted 的任务；状态可在 notstarted、ongoing、blocked 与 completed 之间更新；对话可按游标分页读取。人类的任务交互通过 notifications/claude/channel 和 SSE 实时送达，ACP Gateway 或 Codex Gateway 则把这些通知桥接到相应代理进程。全局 CoreMCP Supervisor 可以列出、创建和更新工作区，跨工作区查询任务，调整任务顺序、负责人、命令许可及定时任务，并处理任务回复、许可裁决和附件。系统把工作区及任务数据持久化到 SQLite，并通过 Vue Web 界面呈现实时状态。
- 同时运行多个 Claude Code 项目的开发者，为每个项目配置独立的 .mcp.json，使代理只领取对应工作区的任务。
- 需要审核敏感代理操作的团队，通过任务会话接收许可请求，并由 Supervisor 提交允许或拒绝的裁决。
- 希望从手机、Web 或桌面端远程监督代理工作的自托管用户，集中查看实时任务状态与回复。
- 管理多个项目的负责人，通过 Supervisor 的 listAllTasks、工作区统计和任务分派功能获得跨工作区视图。
- 使用 Gemini CLI、Codex 或 DeepSeek Harness 的团队，借助官方 Gateway 或插件把实时任务通知接入现有命令行代理流程。
- 需要周期性工作的操作人员，使用 createTask 的 cron_schedule 或 Supervisor 的 updateScheduledTask 管理计划任务。
这个 Agent 有哪些优点和局限？
- 同时提供工作区级 MCP 与全局 Supervisor MCP，既能隔离项目，又能跨工作区管理任务、统计和权限。
- 任务、回复和许可请求通过 SSE 或协议通知实时同步，代理无需依赖轮询来等待人类交互。
- 支持自托管，并明确给出 Go/Fiber、SQLite、Vue 3 等部署边界，团队可以控制服务和持久化数据。
- 除 Claude Code 原生通道外，还提供面向 Codex、ACP 代理和 DeepSeek Harness 的官方桥接路径。
- 任务模型覆盖状态流转、附件、对话分页、负责人、优先级、命令许可和 cron 计划任务。
- 本地完整栈要求 Go、Node.js、npm 和 Google OAuth2 凭据，部署与身份认证成本高于单一 CLI 工具。
- 工作区 MCP URL 含访问令牌，且配置示例需要写入项目文件；采用者必须自行妥善管理这些敏感配置。
- Claude Code 的示例启动命令包含 dangerously-load-development-channels，团队需要评估其安全策略与审批边界。
- 非 Claude 通道需要额外组件：Gemini 依赖 ACP Gateway，Codex 依赖 Codex Gateway，DeepSeek Harness 需要独立插件和每工作区一个 profile。
- 所给材料未提供备份、高可用、外部数据库迁移或离线运行方案；SQLite 是否适合大型或高并发部署缺少证据。
如何安装或部署这个 Agent？
本地运行需要 Go 1.21+、Node.js 18+、npm，以及 Google Cloud Console 中创建的 OAuth2 Client ID 和 Secret。在 backend/_config/base.yaml（也可使用 development.yaml）写入：
auth:
google:
client_id: "your-google-client-id"
client_secret: "your-google-client-secret"然后在仓库根目录执行：
make install
make dev前端将运行在 http://localhost:5173。项目还说明可用预构建 Docker 镜像自托管，但所给材料未包含 SETUP.md 中的具体 Docker 命令和环境变量，因此无法据此提供可验证的容器启动命令。
如何使用这个 Agent？
先在 AgentRQ 工作区的 Setup 弹窗复制工作区 ID、完整 MCP URL 和令牌。在项目根目录创建 .mcp.json：
{
"mcpServers": {
"agentrq-WORKSPACE_ID": {
"type": "http",
"url": "YOUR_MCP_URL"
}
}
}
再在 .claude/settings.local.json 中启用该 MCP 服务，并按需允许 updateTaskStatus、getWorkspace、reply、createTask、downloadAttachment 和 getTask。随后从该项目目录启动：
claude --dangerously-load-development-channels server:agentrq-WORKSPACE_ID代理连接后可用 getTask 领取任务、用 reply 回传进展，并用 updateTaskStatus 更新状态。Codex 用户还需在项目级 .codex/config.toml 配置同一工作区的 MCP URL与工具审批，并创建供网关接收任务的 .mcp.json，然后安装和运行：
npm install -g @agentrq/codex-gateway@latest
codex-gatewayGemini CLI 的实时桥接可执行：
npm install -g @agentrq/acp-gateway
acp-gateway -- gemini --acp这个 Agent 与同类方案有什么区别？
Claude Code 具有原生 claude/notifications 通道接入；Gemini CLI 等 ACP 代理不能直接接收这种通知，需要 @agentrq/acp-gateway 在 ACP 与 MCP 之间转发。Codex 则使用 @agentrq/codex-gateway 桥接 MCP 与 Codex app-server，并分别用 .mcp.json 接收任务、用 .codex/config.toml 让代理调用 AgentRQ 工具。DeepSeek Harness 通过专用插件维持受监督的工作区会话，且一个 profile 对应一个工作区。