一个人的 AI 团队：五个智能体的分工与协作

定位：多智能体的难点不在「智能」，在「组织」

到 2026 年 9 月，我身边的常驻 AI 智能体是这么一个阵容：两个微信机器人（一个生活陪聊、一个测试沙箱）、一个飞书工作机器人、两个负责网站开发与运维的编码智能体，外加一批挂在飞书多维表格上的技能包——审批自动化、加密导出、物料查询、每日资讯。它们不是五个同名助手换不同头像，而是一个有分工、有协作协议、有值班表的团队。

回看搭建过程，真正难的从来不是让某个智能体变聪明，而是让一群智能体不互相踩脚、知道找谁、事后能查账。

分工：按「出错代价」划边界

原则就一条：出错代价越高的岗位，越要离「自动放权」远一步。生活侧可以全自动，工作侧的每个对外动作都要走技能包的固定管道，上生产必须另一个智能体放行。

协作：三样东西比任何框架都重要

第一，共同事实源。所有跨智能体的事都落在一块追加式看板上：部署记录、审批、健康检查、值班声明。对话会丢上下文，记忆会压缩，看板不会——两个编码智能体哪怕换代会话，看一眼看板就知道「现在线上是什么、谁在做什么」。

第二，职责边界写成制度而不是提示词。「请仔细检查」是没用的，有用的是「发起部署的智能体无权放行生产」这种结构性约束——想违规都没有路径。

第三，通知有协议。事实进看板（永久），提醒走消息通道（实时），账目进部署日志（审计）。三层各司其职，谁也不替代谁。

运维：团队也需要「体检制度」

团队跑起来之后，稳定性不靠盯梢靠例行：每日健康检查五项（关键页、API、服务状态、磁盘、证书）结果贴看板；数据类任务全部带守卫——源数据行数不足就拒绝重建，坏数据进不了下游；每日全量备份带恢复文档，容灾演练的标准是「拿到备份包的智能体能把整套体系复活」。

这些制度的由来很朴素：每一个都对应一次真实事故。制度是事故的化石。

价值与可复用方法

很多人对多智能体的想象是「一堆智能体自动开会解决问题」，实践下来恰恰相反：智能体越自主，越需要笨拙而坚硬的组织约束。我的团队没有一个智能体在「自主决策上线」，它们各自在清晰的边界里做事，边界外交接。

可复用的最小集：按出错代价分岗、看板做共同事实源、约束写进流程不写进提示词、通知分三层、例行体检带守卫。五件事做完，一个人带一支 AI 团队就不是比喻，是日程表。