1. 从"一个人写代码"到"一群Agent替我干活"的转变
去年有段时间我特别焦虑。手头同时压着三个项目：一个需要持续跑数据清洗脚本，一个要盯着接口联调结果，还有一个得定期检查服务器上的日志异常。每天睁眼就是打开终端、连服务器、跑命令、看输出、改代码，循环往复。最要命的是，很多活儿其实是重复性的——比如每天凌晨检查一次数据管道的健康状态，出问题就重启对应服务，没出问题就记录一条日志。这种活儿人干久了会麻木，但机器干刚刚好。
于是我开始琢磨一件事：能不能让多个Agent各管一摊，7×24小时不间断地替我盯着这些事？不是那种"我发一条指令它回一条"的被动模式，而是真正意义上的多Agent集群——每个Agent有自己的职责边界、有自己的工具权限、能互相通信、能自主决策，遇到搞不定的再上报给我。
这个想法听起来有点大，但拆开来看其实就三块：Agent怎么定义职责、Agent之间怎么通信、Agent怎么安全地操作远程环境。前两块是架构问题，第三块是工程问题——而第三块恰恰是最容易翻车的地方。你让一个Agent去连远程服务器跑命令，SSH密钥怎么管？权限怎么隔离？连不上怎么办？命令卡住了怎么超时？这些问题不解决，集群就是空中楼阁。
这篇文章我会把这套东西的完整搭建过程拆开讲。包括我为什么选Codex作为Agent的核心执行引擎、SSH在整个架构里扮演什么角色、多Agent之间怎么协调、以及我在实际跑的过程中踩过的那些坑。如果你也在琢磨怎么把重复性开发运维工作自动化，或者单纯对多Agent协作感兴趣，这篇应该能给你一些可以直接抄的作业。
2. 为什么是Codex加SSH这套组合拳
2.1 Codex作为Agent执行引擎的定位
先说清楚Codex在我这套架构里干什么。很多人第一次接触Codex会把它当成一个"AI编程助手"，就是你在编辑器里写代码它给你补全那种。但在我的用法里，Codex的角色更接近一个可编程的命令执行与推理引擎——我给它一个任务描述，它自己决定跑什么命令、怎么解析输出、下一步做什么。
这个定位很关键。因为多Agent集群的核心需求不是"生成代码"，而是"根据当前状态做出决策并执行"。比如数据管道挂了，Agent需要：先跑systemctl status看服务状态，再跑tail -n 100看日志尾部，根据日志里的错误类型决定是重启服务还是清理临时文件还是上报。这一连串动作里，Codex负责的是"看日志判断错误类型"这个推理环节，而SSH负责的是"把命令送到远程机器上执行"这个传输环节。
我试过几种方案。纯脚本加cron的方式太死板，错误类型一多就写不下去了。纯LLM API调用的方式又太飘，它没法直接操作远程环境。Codex加SSH的组合刚好卡在中间：Codex提供推理能力，SSH提供执行通道，两者通过一个薄薄的调度层粘在一起。
2.2 SSH不只是"连服务器"那么简单
大部分人用SSH就是ssh user@host然后敲命令。但在Agent集群场景下，SSH承担的责任要重得多：
- 身份认证：每个Agent用独立的密钥对，方便审计和权限回收
- 通道复用：多个Agent连同一台机器时，通过ControlMaster复用连接，避免频繁握手
- 命令隔离：不同Agent能执行的命令范围不同，通过受限shell或包装脚本控制
- 超时与重试：Agent跑的命令可能卡住，需要SSH层面设置超时
- 批量操作：一个Agent可能需要同时操作多台机器，SSH的批量登录能力就派上用场了
我一开始图省事，所有Agent共用一个SSH密钥。结果有一次一个Agent误操作把测试环境的配置改了，我查了半天才定位到是哪个Agent干的——因为日志里所有操作都来自同一个用户。后来改成每个Agent独立密钥，并且在远程机器的authorized_keys里给每个密钥加command=限制，问题才解决。
2.3 多Agent集群的职责划分逻辑
我的集群目前有四个常驻Agent，职责划分如下：
| Agent名称 | 职责 | 操作频率 | 权限范围 |
|---|---|---|---|
| Watcher | 监控服务健康状态 | 每5分钟 | 只读命令 + 重启服务 |
| Cleaner | 清理临时文件和过期日志 | 每小时 | 文件删除（限定目录） |
| Deployer | 拉取代码并部署 | 按需触发 | 代码目录读写 + 服务重启 |
| Reporter | 汇总状态并生成报告 | 每天一次 | 只读命令 |
这个划分不是拍脑袋定的。核心原则是最小权限加职责单一。Watcher只需要看状态和重启，就不给它文件删除权限。Cleaner只需要删文件，就不给它服务重启权限。这样即使某个Agent的推理出了问题，它能造成的破坏也是有限的。
另外还有一个"协调者"角色，不直接操作远程环境，只负责接收其他Agent的上报、决定是否触发Deployer、以及在我需要的时候把汇总信息推给我。这个协调者跑在本地，通过一个简单的消息队列和其他Agent通信。
3. 搭建过程中的关键步骤与配置细节
3.1 SSH密钥体系的设计与落地
第一步是把SSH密钥体系搭起来。我的做法是在本地生成四对密钥，每对对应一个Agent：
ssh-keygen -t ed25519 -f ~/.ssh/agent_watcher -C "agent-watcher" ssh-keygen -t ed25519 -f ~/.ssh/agent_cleaner -C "agent-cleaner" ssh-keygen -t ed25519 -f ~/.ssh/agent_deployer -C "agent-deployer" ssh-keygen -t ed25519 -f ~/.ssh/agent_reporter -C "agent-reporter"选ed25519而不是RSA，原因是密钥更短、签名更快，而且现代OpenSSH版本默认支持。生成之后把公钥分发到目标服务器的authorized_keys里。
这里有个细节：不要直接把公钥追加到authorized_keys就完事。我踩过的坑是，如果多个Agent的公钥都追加进去，远程机器上所有Agent看起来都是同一个用户，审计日志分不清谁是谁。正确做法是在公钥前面加限制选项：
command="/usr/local/bin/agent-wrapper.sh watcher",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA... agent-watcher这个command=选项的意思是：不管这个密钥连上来之后想跑什么命令，实际执行的都是agent-wrapper.sh watcher。包装脚本里再根据传入的参数决定允许执行哪些命令。这样即使Agent的密钥泄露了，攻击者也只能跑包装脚本里允许的命令。
3.2 本地SSH配置的优化
Agent频繁连远程机器，如果每次都完整握手会很慢。我在~/.ssh/config里给每个目标机器配了连接复用：
Host prod-server HostName 10.11.225.193 User deploy IdentityFile ~/.ssh/agent_deployer ControlMaster auto ControlPath ~/.ssh/sockets/%r@%h-%p ControlPersist 600 ServerAliveInterval 30 ServerAliveCountMax 3ControlMaster auto加ControlPersist 600的意思是：第一个连接建立后，后续600秒内的连接复用这个通道，不再重新握手。实测下来，Agent连续跑十条命令的时间从原来的8秒左右降到了1秒出头。
ServerAliveInterval 30和ServerAliveCountMax 3是保活配置。Agent跑长任务时如果网络抖动，没有这两个配置连接会断，任务就丢了。加上之后，30秒没数据就发一个保活包，连续3次没响应才断开。
3.3 Codex的安装与基础配置
Codex的安装方式取决于你用哪个版本。我用的CLI版本，安装过程不复杂，但有几个配置项必须提前设好，否则Agent跑起来会各种报错。
安装完成后，配置文件通常在~/.codex/config或者项目目录下的.codex文件里。我的配置核心是这几项：
[model] provider = "openai" model = "codex" [execution] timeout = 120 max_retries = 3 working_dir = "/home/agent/workspace" [logging] level = "info" path = "/var/log/agent/codex.log"timeout设120秒是因为有些命令（比如日志分析）确实需要跑一会儿，设太短会误杀。max_retries设3是因为网络抖动导致的失败重试三次基本能覆盖。working_dir必须设成绝对路径，否则Agent在不同上下文里跑的时候工作目录会乱。
如果你遇到Codex登录不上的问题，先检查网络连通性和API端点配置。国内使用的话需要确认你的网络环境能正常访问对应的服务端点。另外Codex CLI在Windows和macOS上的配置路径不同，Windows一般在%USERPROFILE%\.codex\下面。
3.4 Agent调度层的实现思路
调度层我用Python写了一个轻量级的框架，核心是一个事件循环加一个任务队列。每个Agent注册自己的触发条件（定时触发或事件触发），调度器根据条件把任务推给对应的Agent执行。
class AgentScheduler: def __init__(self): self.agents = {} self.task_queue = queue.Queue() def register(self, name, agent, trigger): self.agents[name] = { "instance": agent, "trigger": trigger } def run(self): while True: for name, cfg in self.agents.items(): if cfg["trigger"].should_fire(): self.task_queue.put(name) # 从队列取任务执行 ...这个框架很粗糙，但够用。关键点是每个Agent的执行是独立的，一个Agent卡住了不影响其他Agent。我一开始用单线程顺序执行，结果Cleaner在删大文件的时候卡了半分钟，Watcher的监控就延迟了。改成多线程之后问题解决。
4. 多Agent协作中那些文档不会告诉你的坑
4.1 SSH连接数爆炸与文件描述符耗尽
集群跑起来第三天，Watcher突然报错说连不上服务器。我上机器一看，ss -s显示大量TIME_WAIT状态的连接。原因是每个Agent每次执行任务都新建SSH连接，虽然配了ControlMaster，但有些Agent的代码里没走配置文件，直接用了paramiko库新建连接。
paramiko默认不复用连接，每个SSHClient实例都是独立连接。Agent跑一轮下来建了几十个连接，系统文件描述符很快就不够用了。
解决方案有两个层面：一是所有Agent统一走系统SSH命令加ControlMaster，不用paramiko直接连；二是如果非要用paramiko，就维护一个连接池，复用SSHClient实例。我最后选了第一种方案，因为系统SSH的稳定性和可调试性都更好。
注意：如果你的Agent需要频繁连大量不同的机器，ControlMaster的socket文件会堆积。记得定期清理
~/.ssh/sockets/目录下的过期socket文件。
4.2 命令超时与僵尸进程
Agent跑的命令如果卡住，比如tail -f忘了加-n限制，或者某个服务重启卡在等待状态，SSH连接会一直挂着。我遇到过最离谱的一次是Deployer跑了一个git clone，仓库特别大，跑了二十分钟还没完，把整个调度队列堵死了。
后来我在SSH命令层面加了超时：
timeout 60 ssh prod-server "systemctl restart my-service"timeout命令会在60秒后强制杀掉SSH客户端。但这里有个坑：SSH客户端被杀了，远程机器上的命令不一定被杀。远程命令可能还在跑，变成僵尸进程。更稳妥的做法是在远程命令里也加超时，或者用ssh -o ConnectTimeout=10控制连接超时，用远程的timeout控制命令超时。
4.3 Agent之间的消息传递与状态同步
四个Agent各跑各的，但有些决策需要协调。比如Cleaner发现磁盘快满了，需要通知Deployer暂停部署，等清理完再继续。我一开始用文件锁做同步，结果Cleaner持有锁的时候崩了，锁没释放，Deployer一直等。
后来改成用一个简单的消息队列（Redis的List结构），Agent之间通过push和pop消息通信。Cleaner清理完push一条"cleanup_done"，Deployer收到后才继续。Redis挂了怎么办？加一个本地文件作为降级方案，Redis不可用时写本地文件，恢复后再同步。
这个方案不完美，但比文件锁可靠。核心教训是：Agent之间的同步不要用阻塞式原语，要用消息传递，因为Agent可能随时崩溃，阻塞式原语一旦没释放就会导致整个集群卡死。
4.4 Codex推理结果的不可预测性
Codex再聪明也是概率模型，同样的输入可能给出不同的输出。我遇到过Watcher看到日志里有"error"字样就决定重启服务，但实际上那个error是历史日志里的，当前服务是正常的。结果服务被反复重启，反而搞出了问题。
解决办法是给Agent的决策加确认机制。Watcher判断需要重启时，不直接重启，而是先跑一次健康检查，确认服务确实不健康才重启。这个确认逻辑写在Agent的代码里，不依赖Codex的判断。
另外，Codex的输出格式要严格约束。我在prompt里明确要求它输出JSON格式的决策结果，比如{"action": "restart", "reason": "service_unhealthy", "confidence": 0.9}，然后在代码里解析这个JSON。如果解析失败或者confidence低于阈值，就不执行动作，直接上报给我。
5. 集群稳定运行后的日常维护与调优
5.1 日志体系与问题追溯
集群跑起来之后，最大的挑战不是让它跑，而是出了问题能快速定位。我搭了一套简单的日志体系：每个Agent的操作日志写到独立文件，同时汇总一份到中央日志。日志格式统一成JSON，方便检索。
{ "timestamp": "2025-01-15T03:22:11Z", "agent": "watcher", "action": "check_health", "target": "prod-server", "result": "unhealthy", "decision": "restart", "duration_ms": 1240 }有了这个日志，出问题的时候直接grep agent名字加时间范围，几分钟就能定位。之前没有结构化日志的时候，我翻了半小时才找到是哪个Agent在什么时候干了什么。
5.2 资源占用的监控与限制
四个Agent加一个调度器，常驻内存占用大概在300MB左右，CPU平时几乎不占。但Codex推理的时候会吃CPU和内存，特别是同时有多个Agent触发推理的时候。
我给每个Agent加了资源限制，用systemd的MemoryMax和CPUQuota控制。Watcher和Reporter限制得紧一些，因为它们的任务轻。Deployer和Cleaner放宽一些，因为它们可能要处理大文件。
另外，Codex的推理调用我加了并发限制，最多同时跑两个推理请求。超过的排队等待。这样避免了推理请求把机器资源吃满导致其他Agent饿死。
5.3 定期演练与故障注入
集群最怕的是"平时看着好好的，一出事全崩"。我每个月会做一次故障演练：手动杀掉一个Agent，看其他Agent能不能正常接管；手动断开SSH连接，看Agent能不能重连；手动往日志里写错误信息，看Watcher会不会误判。
有一次演练发现，Watcher被杀掉后，调度器没有重新拉起它，因为我的调度器只负责触发任务，不负责监控Agent存活。后来加了一个心跳机制，每个Agent定期往Redis写心跳，调度器发现心跳超时就重新拉起Agent。
5.4 安全边界的持续收紧
Agent集群跑久了，权限容易越给越大。我每季度会review一次每个Agent的SSH密钥权限和远程命令白名单，把不再需要的权限去掉。比如Deployer一开始有删除旧版本代码的权限，后来发现这个操作可以手动做，就从白名单里去掉了。
另外，所有Agent的操作都记审计日志，包括执行的命令、时间、结果。这个日志单独存一份，Agent自己不能删。这样即使Agent被恶意操控，也能追溯到它干了什么。
6. 关于这套集群我目前的一些真实体会
这套东西跑了大半年，最大的感受是：多Agent集群的价值不在于"智能"，而在于"持续"。单个Agent的决策能力其实有限，Codex再强也有判断失误的时候。但四个Agent各管一摊、互相补位、7×24小时不间断地跑，整体上确实把我从重复劳动里解放出来了。我现在每天只需要花十分钟看一下Reporter生成的汇总报告，确认没有异常就行。
另一个体会是，SSH这个看似古老的技术，在Agent集群场景下依然是不可替代的。它简单、可靠、到处都有、权限模型清晰。我试过用HTTP API替代SSH做远程执行，结果发现要自己处理认证、加密、超时、重试，工作量比直接用SSH大得多。SSH把这些都标准化了，你只需要管好密钥和配置就行。
最后说一个我最近在琢磨的扩展方向：把Agent的决策逻辑从"规则加Codex推理"逐步过渡到"Codex推理为主，规则做兜底"。目前规则占的比重还比较大，因为规则可靠、可预测。但随着Codex对日志和状态的理解越来越准，我打算让它承担更多判断工作，规则只保留最核心的安全边界。这个过渡急不得，得一步步来，每放开一点就观察一段时间，确认稳定了再继续。
