凌晨三点，三百位 AI 同事里有七位没回消息

栏目：05 · 生产级 Agent 运维

晚上十一点，第一位客服 Agent 上线。值班员老周问了它三个问题，回答都很顺；产品经理截了张图，群里收获了一排大拇指。

一个月后，公司已经有三百位 AI 同事：售前有自己的接待员，售后有自己的排障助手，十二个业务组各有不同的知识和权限。凌晨三点十七分，监控说其中七位不再回复。

群里立刻出现了七个熟悉的问题：它们分别跑在哪？用的还是昨天那份配置吗？是 Agent 卡住、运行环境停了，还是模型服务超时？重启会不会丢掉正在处理的任务？最重要的是——另外二百九十三位，真的都没事吗？

老周忽然怀念起只有一个机器人时的晚上。那时“重启一下”是一种方案；现在，它更像一种抽奖。

一位 AI 同事是 Demo，三百位是一支队伍

规模放大的不只是数量，还有配置差异、运行状态、日志、资源消耗和恢复风险。

如果每位 Agent 都靠一段散落的启动命令出生，那么三百位同事就会拥有三百段口述历史：有人换过模型，有人多挂了一个目录，有人的密钥留在终端历史里，还有人只存在于某台机器的后台进程中。事故发生时，值班员首先要考古，然后才能救火。

Agent Compose 做的第一件事，是把这些口述历史变成声明。每位 Agent 使用哪个 provider、镜像、workspace、工具、Skill、volume 和调度方式，都写进同一种 Compose 模型；daemon 则成为运行状态的统一事实源。

agent-compose.yml
        │  声明“应该有什么”
        ▼
      daemon ───── project / agent / sandbox / run
        │                         │
        ├── 状态与资源             ├── 日志与错误
        └── 生命周期操作           └── 调度与事件

于是上线不再是让三百个人分别敲三百条命令，而是一次校验、一次应用：

agent-compose config --quiet
agent-compose up

这里有一个容易被宣传口号藏掉的细节：up 统一应用项目定义，并不等于不顾机器容量，瞬间塞进一万个常驻进程。sandbox 可以在工作真正到来时创建；如果业务要求预热一批实例，也应该通过 API 或自动化按容量分批执行，并设置并发上限。一键管理的价值，是入口统一、结果可查，而不是把资源规律变没。

七位没回消息，先别急着叫醒三百位

老周先看全局状态，而不是逐台机器碰运气：

agent-compose ps --all --json
agent-compose ps --status stopped,failed --verbose
agent-compose stats

这三条信息回答不同问题：资产清单里有哪些 sandbox；哪些已经停止或失败；仍在运行的实例是否出现异常资源占用。机器可读的 JSON 输出还可以交给监控系统统计，不必让人盯着表格数到三百。

接着只沿着异常对象向下钻：

agent-compose logs <agent-or-sandbox-id>
agent-compose inspect sandbox <sandbox-id> --json

日志说明“它最后做了什么”，检查结果说明“控制面认为它现在是什么状态”。两者必须分开：模型请求失败，不一定代表 sandbox 已死；sandbox 停止，也不能靠再问模型一次来证明。

最终，七个异常被分成了三类：两个只是上游模型超时，任务按既定重试策略重新投递；三个 sandbox 被意外停止，可以批量 resume；另两个反复失败，保留日志和现场后退出自动恢复，交给值班员检查配置与依赖。

agent-compose sandbox resume <sandbox-id-1> <sandbox-id-2> <sandbox-id-3>

恢复动作针对七位异常同事，不波及另外二百九十三位。故障处理从“整组重启”变成了“筛选、诊断、分类、处置”。

所谓自愈，不是看见红灯就无限重启

把 ps --json、日志、生命周期命令和控制面 API 接进监控后，可以构成一条自动恢复链：

定期或按事件检查 → 识别异常状态 → 收集日志与运行信息 → 按策略恢复 → 再次验证 → 超过阈值后通知人

这时，Agent Compose 提供的是稳定的控制面和可组合的操作原语；团队的自动化负责决定业务策略。策略至少应该回答四个问题：什么状态算故障？什么情况允许自动恢复？最多尝试几次？何时停止折腾现场并通知人？

因此，“自愈”不该写成一个永不失败的魔法按钮。没有次数上限的重启会制造故障风暴；没有退避的重试会把上游压垮；没有日志留存的重建会抹掉证据；没有容量判断的批量拉起，可能把七个故障扩大成三百个。

一条可信的恢复策略更像这样：

发现异常
  ├─ 短暂请求失败 ── 有界退避后重试任务
  ├─ sandbox stopped ── 恢复并做健康验证
  ├─ sandbox failed ── 保存证据，按策略重建或重新运行
  └─ 连续失败超过阈值 ── 停止自动动作，通知值班员

自动化负责处理已知故障，人负责判断未知故障。后者不是自动化失败，而是生产系统应有的刹车。

“一万个 AI 同事”真正考验什么？

把三百改成一万，YAML 行数并不是最难的问题。配置完全可以由模板或业务系统生成，项目也可以按团队、权限边界和故障域拆分。真正需要提前设计的是：daemon 与 runtime 的容量、模型服务配额、镜像分发、workspace 和 volume、凭据隔离、监控基数，以及故障恢复时的并发与退避。

Agent Compose 不替这些问题编造一个无限大的答案。它把不同 provider、不同触发方式和不同 runtime 放进一致的声明与生命周期模型，让运维系统终于有一个可以校验、查询、操作和审计的对象。

这也是它和“写个脚本启动 Chatbot”的区别：脚本解决一次启动；控制面管理它从定义、运行、观测、故障到退出的整段生命。

天亮以后，老周只重启了三位同事

早上八点，业务负责人问：“昨晚三百个 Agent 是不是全挂了？”

老周把运行记录放到群里：七个异常，两个任务重试成功，三个 sandbox 恢复成功，两个因连续失败转人工处理；其余二百九十三个没有被重启，也没有被事故操作打扰。

这份回答比“已经好了”多了几个数字，也多了一条完整证据链。

当 AI 同事只有一位，我们关心它会不会回答；当它们成为一支队伍，我们还要关心谁定义了它、谁能调用它、它现在在哪里、失败后发生什么。Agent Compose 的生产级价值，不是把“一万个”写进标题，而是让一万个 Agent 仍然能够被当作工程系统管理：批量上线而不失去边界，局部故障而不惊动全员，自动恢复而不放弃证据。

能力边界说明：本文中的声明应用、状态查询、JSON 输出、日志、资源统计以及 sandbox 批量生命周期操作均对应 Agent Compose 的控制面能力；大规模配置生成、告警规则与自动恢复策略需要结合实际基础设施和外部自动化建设。当前不应把它表述为原生的副本数控制器或无条件自动重启机制。