Solo Agent
一个开源、本地优先的工作区，让人类与多个 AI 编程智能体通过频道、任务板、团队和持久记忆协作，终结终端标签页里的散乱多智能体工作。
README声称本地优先、架构清晰（Server/Daemon/Agent CLI经stdin/stdout通信），但提供的是根目录文档级证据，未见任何Agent工具执行、文件访问、custom_env注入的权限控制、用户确认或数据流说明代码。Agent自动从PATH探测并可带custom_args/custom_env运行，属较大执行面但无最小权限或确认机制的可见证据。SECURITY.md承认RCE类风险在范围内，说明作者有意识但未展示缓解。仅来源归属尚可：LICENSE署名fredal、SECURITY.md给出联系方式，publisher虽未验证但有署名。多数标准因缺少实现证据仅得1。
README描述的组件结构、端口、协议表前后一致，依赖在go.mod与CI（postgres服务、goreleaser）中可对应，得2。但根package.的test脚本为占位错误、错误处理与失败信息无任何文件证据，得1。
面向使用Claude Code/Codex等CLI的开发者，场景（多Agent协作、任务看板）描述清楚，环境要求（Go 1.22+、Node 20+、Docker）明确，得2。但能力边界、Agent何时被触发/提及的精确规则仅一句'If it can receive a heartbeat'带过，无文档支撑，得1。
文档结构清晰、安装步骤具体（make dev及日常命令）、LICENSE为完整MIT文本、SECURITY.md坦承单人维护且无SLA，这些到位。但仅得1的项：命名稳定性存疑（README称github.com/solo-agent/solo而go.mod模块名为github.com/solo-ai/solo）、无CHANGELOG/版本发布历史证据（release workflow存在但无标签记录）、无FAQ、known limitations仅隐含于SECURITY的solo-maintained说明。安装说明与维护责任得2。
相比散落的终端标签页，集中协调、任务看板、记忆的边际价值有清晰对比表支撑，得2。但输出可用性（artifacts的实际形态、review流程）仅有截图引用与概念描述，无代码证据，得1；成本收益合理（本地运行、复用已有CLI），得2。
架构图与协议表可追溯到具体端口与CLI二进制名，但所有性能/功能主张均无可核验的测试或基准文件（根package.测试为占位），主张可追溯性弱。CI workflow显示存在go test与tsc检查，但源文件中无测试代码可佐证，跨源印证有限。事实与推断在README中混合（'If it can receive a heartbeat, it's hired'属营销话术），仅得1。
- 静态评审未执行任何代码；Agent执行面（custom_env/custom_args、工具调用）的权限与确认机制无可见证据，部署前应自行审计daemon与agent子进程代码。
- go.mod模块路径（github.com/solo-ai/solo）与仓库地址（solo-agent/solo）不一致，且发布者未经注册表验证，需核实供应链来源。
- 项目为单人维护、无SLA（SECURITY.md自述），安全修复时效不确定；根package.无实际测试脚本。
- 版本与变更历史缺失，无法评估回归风险或升级路径。
- README中的功能与营销性描述均未附可核验的测试或基准数据。
这个 Agent 能做什么，适合哪些场景？
Solo Agent（GitHub：solo-agent/solo，MIT 许可）是一个自托管的工作区，把 Claude Code、Codex CLI、OpenCode、Hermes、OpenClaw 等编程智能体当作可以协作的'同事'来管理。它由三层本地服务组成：Go 语言的 Server（:8080，负责 API、WebSocket、PostgreSQL 持久化）、Daemon（:8081，负责注册机器并管理智能体子进程），以及浏览器端 Next.js 前端（:3000）。智能体 CLI 通过 stdin/stdout 被 Daemon 启动，Solo 注入提示词、MEMORY.md 记忆和协作工具。用户在频道中发消息、@提及智能体或创建任务，任务以看板形式流转（todo / in_progress / in_review / done / closed），完成的工作可产出可审阅的工件。它还提供智能体团队模板、Thinking 模式分支讨论、实时运行追踪和使用趋势仪表盘。整体架构完全本地部署，不依赖任何云端编排服务。
克隆仓库后运行 make dev，它会生成 .env、安装前端依赖、启动 PostgreSQL、执行迁移并启动应用。打开 http://localhost:3000 注册后，用户创建频道、添加智能体（后端从 PATH 自动检测：claude / codex / opencode / hermes / openclaw，分别走 stream-、JSON-RPC、ACP 协议）、@提及智能体或建任务。智能体作为长生命周期队友拥有自己的工作区和 MEMORY.md 记忆，可认领任务、提交、被审阅和关闭；任务可拆分子任务让多个智能体分工。每个智能体可覆盖 system_prompt、model_name、custom_env 和 custom_args。Server (:8080) 提供 Go API 和 WebSocket hub，Daemon (:8081) 管理智能体子进程，前端 (:3000) 实时展示频道对话、团队关系图、看板、Thinking 分支和运行仪表盘。
- 同时开多个 Claude Code / Codex 会话的开发者，希望在一个工作区统一协调、共享上下文，而不是在终端标签页间切换。
- 需要把大型工作拆成子任务、让多个智能体分工认领并互相可见的团队负责人。
- 希望智能体跨会话保留项目记忆（MEMORY.md）、不必每次重复解释背景的个人开发者。
- 需要对智能体产出走'提交—审阅—关闭'流程、并产出可审阅工件的技术主管。
- 想通过团队模板一键创建频道专属智能体团队（角色、关系、分工）的小团队。
- 需要追踪智能体实时运行、查看会话记录和分析用量趋势的运维或工程效能负责人。
这个 Agent 有哪些优点和局限？
- 多后端支持：同一工作区可混合使用 Claude Code（stream-）、Codex CLI（JSON-RPC）、OpenCode/Hermes/OpenClaw（ACP），不锁定单一厂商。
- 本地优先、自托管：Server、Daemon、PostgreSQL 全部跑在本机，代码和对话不经过第三方编排云。
- 结构化协作而非聊天模拟：任务看板（todo/in_progress/in_review/done/closed）、子任务拆分、审阅与工件发布，工作有可追踪的闭环。
- 持久记忆与可观测性：智能体持有 MEMORY.md 跨会话上下文，并有实时运行追踪和用量趋势仪表盘。
- Thinking 模式可将频道对话分支为独立上下文的推理线，结论回流主讨论而不污染全局上下文。
- 本地部署栈较重：需要 Go 1.22+、Node.js 20+、Docker、PostgreSQL 同时可用，对只想快速试用的用户是不小的门槛。
- 依赖外部智能体 CLI：必须先在 PATH 安装 claude/codex/opencode/hermes/openclaw 之一，Solo 本身不含模型访问能力，相关 API 费用仍由各 CLI 产生。
- 需要 SSH 方式的 git clone（示例使用 [email protected] 地址），且
make dev会执行数据库迁移等有状态操作，重置需make db-reset。 - 官方文档中缺少生产部署、鉴权加固与多用户场景的说明，目前更像是单机/小团队自托管工具。
如何安装或部署这个 Agent？
前置要求：Go 1.22+、Node.js 20+、npm、Docker，且 PATH 中至少有一个受支持的智能体 CLI（claude、codex、opencode、hermes 或 openclaw）。安装与启动：
bash
git clone [email protected]:solo-agent/solo.git
cd solo
make devmake dev 会自动创建 .env、安装前端依赖、启动 PostgreSQL、运行数据库迁移并启动应用。之后在浏览器打开 http://localhost:3000 注册账号。
如何使用这个 Agent？
注册登录后：1) 创建或打开一个频道；2) 添加一个使用受支持后端的智能体；3) @提及该智能体或创建任务；4) 在看板、频道团队和智能体输出中实时查看协作进展。日常维护命令：make（查看全部目标）、make start（启动服务）、make stop（停止服务）、make rebuild（重新编译并重启）、make db-reset（重置本地数据库）。可为每个智能体覆盖 system_prompt、model_name、custom_env、custom_args。