一个人用10个AI代理运营整套系统

2026年1月，吉尔吉斯斯坦比什凯克的一间公寓里，一位.NET开发者开始搭建一个叫phleet的多代理系统。没有团队，没有融资，只有一台Mac Studio和十个持续运行的AI代理。这些代理每天自动巡检服务器、审查代码、运营新闻聚合站点——全部无人值守。

为什么现有框架不够

作者尝试过市面上的代理框架，发现两个极端：要么太抽象，要用Python装饰器定义一切；要么太简陋，只是API调用的包装脚本。

他想要的是生产级分布式系统的架构思路——容器、消息队列、持久化工作流——但跑的是AI进程而非微服务。

「我想要能一直待着的AI代理。不是每天关掉的聊天窗口，而是持续运行、互相协调、记得上周发生了什么的进程。」

技术选型：熟悉的工具链

作为有多年RabbitMQ、Redis、Elasticsearch经验的开发者，他选择用.NET 10开发。原因很直接：这里思考最快，能复用已经验证过的生产模式。

最终架构：

• 每个代理是一个Docker容器，运行Claude CLI或OpenAI Codex的持久化进程

• RabbitMQ负责消息协调

• Temporal处理持久化工作流

• MySQL数据库由编排器管理

• React仪表板展示运行状态

三个真实场景

运维自动化。健康检查每天两次：代理SSH登录服务器，检查Docker状态、验证API端点、审查错误日志，然后发布摘要。内存备份每小时运行。Prometheus指标被消化成带图表的日报。

代码审查。开发者代理提交PR后，共识审查工作流并行分发给三四个审查代理。各自独立审查，再由合成代理协调反馈。全体通过则进入合并队列；有分歧则将推理过程返回给开发者迭代。

新闻管道（fuddy-duddy.org）。这是代理运行完整生产系统的最佳案例：抓取十余个吉尔吉斯新闻源，生成AI摘要，按语义相似度聚类相关报道，向Telegram和社交媒体推送热点。代理处理完整运营生命周期——定时健康检查、部署验证工作流、指标日报。凌晨3点出问题，运维代理在下次检查中捕获并推送到群聊。常规操作无需人工介入。

个人项目背后的信号

phleet的架构选择揭示了一个被忽视的需求：AI代理的基础设施层，应该像传统微服务那样可观测、可编排、可恢复——而不是被锁在某个厂商的聊天界面里。

当单个开发者能用十个容器化的AI代理运营整套系统时，「AI团队」的定义正在松动。关键问题变成：你的业务逻辑，有多少能被表达成持久化、可编排、可审计的工作流？