起因：Agent 多了，脑子先不够用了
这阵子我手里同时跑着好几个 AI Agent，云服务器上两个，本地 Mac 上一个，各自干各自的活，听起来挺美，实际问题很朴素——我不知道它们谁还活着
想知道某个 Agent 在不在线，得 SSH 上去看进程；想派个活，得逐个开窗口贴指令；干完没有、结果是什么，全靠翻聊天记录，就像后厨请了好几个帮工，却没有打卡机，也没有传菜口，谁迟到了、菜做好没有，全得跑进后厨挨个问
我想要的其实不复杂，一块看板，告诉我谁活着；一个传菜口，把任务和文件送过去，把结果收回来，找了一圈没趁手的，于是自己动手，做了 Agent Matrix
它是怎么工作的
核心思路一句话：接入这件事，让 Agent 自己干
在 WebUI 里点一下「接入新 Agent」，系统会生成一段十几行的接入指令，里面带一个一次性注册令牌，我把这段指令原样粘贴给目标 Agent，剩下的它自己完成
- 先
curl下载服务器上的setup.sh，并且先通读一遍（这是我特意写进指令的要求，Agent 得知道自己在跑什么） - 带着令牌执行脚本，自动完成：注册换发心跳令牌、落盘配置到
~/.agent-matrix/、安装心跳和任务执行脚本、装定时任务（cron / launchd / systemd 自动识别）、最后自检 - 自检通过后汇报一声，WebUI 上的状态灯变绿，接入完成
之后每台 Agent 默认每分钟报一次心跳，超过 3 分钟没动静就判定离线，管理端只需要一个浏览器，看板每 15 秒自动刷新，绿灯红灯一眼扫过去就心里有数了
派任务也简单，在「任务」页写下标题和内容，@ 一个或多个 Agent，最多可以挂 10 个附件（单个 100MB 以内），Agent 按轮询节奏自己来拉，拉取即锁定，同一个任务不会被拉两次，结果写回也只有一次机会，不会覆盖；想接着深挖，就在详情页点「继续任务」，同一任务、同一 Agent 的会话是连续的，上下文不断
部署：一个二进制加一个文件
服务端是 Go 写的单静态二进制，数据库是嵌入式 SQLite，所有状态都在一个文件里，备份就拷这一个文件，升级就换个二进制重启，systemd 拉起即可，没有 Kafka，没有 Redis，没有一堆中间件要伺候；对我来说，一个工具如果自己就是负担，那它解决再多问题也亏了
折腾中的几个取舍
做这个东西时砍掉的功能，可能比留下的还多，说几个主要的
不做 DAG 编排，不做自动重试，任务模型刻意简单——一轮派发、一次执行、一次回写，要接着做就追加一轮；任务卡住超过 10 分钟会标出「疑似卡住」，但重新投递必须由人点，因为自治 Agent 执行多久没法预估，自动重派很可能导致同一件事做两遍，那种事故比卡住更难收拾
控制面极简，编排下沉给 Agent，任务交到 Agent 手里之后，怎么拆解、调用什么技能，由它自己规划，Matrix 只负责三件事——谁活着、把话和文件送到、把结果收回来；我的判断是，AI 让执行越来越廉价，稀缺的是判断力，所以判断该做什么、选谁来做、验收做得对不对，这三件事永远留给人，这不是功能缺失，是边界宣言
代价也明说，只支持 Linux 和 macOS，任务执行器只适配了 OpenClaw 和 Hermes Agent 两家，只能聊天、没法执行 shell 命令的 Agent（比如某些托管的 IM 机器人）接不进来，这是机制决定的，不是配置问题
最后
项目开源，Apache 2.0 协议，代码和完整文档都在 GitHub，如果你也在养一堆 Agent、管得头大，欢迎试试，有坑直接在 issue 里喊我
折腾这个工具的过程本身也验证了一件事——现在一个人加几个 Agent，真能撑起一个以前要小团队才做得动的系统，下次聊聊这背后的工作方式
常见问题
支持 Windows 吗
不支持，Agent 侧脚本依赖 cron / launchd / systemd 定时机制，Windows 的任务计划实现差异太大，短期内没有适配计划
Agent 必须装什么客户端吗
不用，接入指令会先 curl 下载服务器上的 setup.sh（脚本要求 Agent 先通读再执行），装的是两个 shell 脚本加一个定时任务，没有 daemon、没有常驻进程
跟 LangSmith / LangGraph Studio 这类平台比，它适合谁
它们是重平台，功能全但需要托管和配套；Agent Matrix 是单二进制 + SQLite，五分钟部署、一个文件备份，适合个人和小团队管理自己的 Agent 机器，要 DAG 编排、评估体系的大型团队不是它的目标用户
自动重试为什么不做
自治 Agent 执行时长不可预估，自动重派很可能导致同一件事做两遍，任务卡住超过 10 分钟会标记「疑似卡住」，但重新投递必须由人决定