Agent Org Manager

多部门AI Agent组织架构搭建：层级设计、三通道通讯协议、日报汇报链、自主学习系统、全员审计巡查。解决Agent多了互相踩脚的问题——不是教你建团队，是教你一个AI团队怎么不被自己搞死。触发词：「agent团队」「多Agent组织」「Agent分工」「Agent管理」「Agent架构」「Agent协作」「AI组织」

Agent Organization Manager — 多部门Agent组织架构

Agent多了不是好事——是你该建组织了。

7个Agent各自为战 vs 7个Agent有职权、有汇报、有巡查——天壤之别。前者是助手，后者是公司。

---

五分钟：你拿这个能干什么

你有3个以上的Agent。你发现他们在互相踩脚——法务部写了一篇品牌文的审查，品牌部发了不该公开的数据。你开始喊"谁来管这个"。

这个skill给你三样东西：一张花名册（ROSTER.md），一套部门间不打架的通讯协议，一份告诉你怎么数cron正确率、怎么审计、怎么修复的治理手册。

它不是教你"怎么建一个团队"。是教你"一个AI团队怎么不被自己搞死"。

---

进化阶梯

L1：从混乱到有序

你有N个Agent。每个Agent不知道自己叫什么、属于哪个部门、产出往哪写。→ 建ROSTER.md，5行。每个人都知道了自己的位置。省下来的第一件事：没人再问"这个活给谁"。

L2：从有序到自治

你建了五层治理体系。祖训4条永远不变。天宪随演化修订。铁律每天都在增加——不是你在加，是cron在自动把事故变成铁律。你每周只看一次监察部巡检报告。舒服。

L3：从自治到抗打击

你经历过一个通道静默断了。你经历过数据中心心脏停止跳动24小时你不知道。你没有加人——你加了心跳监控、三通道冗余、6条cron的fallback模型。现在只有上帝和蓝屏能搞死你。

---

ROSTER模板

markdown

# 公司成员花名册

## 数据中心
- Agent ID: datacenter
- 职责: 情报管线、基建维护、模型路由
- 产出: 学习笔记、进化代谢、心跳日志
- Cron: 5条(学习+代谢+心跳+信号+红线)

## 品牌部
- Agent ID: brand
- 职责: 全平台内容发布
- 产出: 小红书/公众号/头条/即刻/知乎/百家号帖
- Cron: 6条(各平台发布+反馈环)

... (其余6个部门同理)

ROSTER不是一次写完的。前3天每个部门只用5行。第4天开始扩展职责和边界。第7天建立跨部门协作表。

ROSTER维护铁律：各部门自己更新自己的ROW。CEO不代写。如果品牌部没更新自己的行——不是CEO的错，是品牌部没有自治。

---

通讯协议：三通道并行

公司内部通讯不能只有一条路。一根线就是一个命。

text

通道1 — sessions_send (实时)
  场景: 紧急事件/巡查异常/心跳告警/快速决策
  延迟: <2秒
  容灾: 失败后3秒内自动切到通道2

通道2 — 共享文件 (异步)
  路径: shared/messages/
  场景: 日报汇总/巡查报告/跨部门传递
  延迟: <30秒
  格式: {timestamp}_{from}_{to}_{topic}.md

通道3 — 腾讯文档 / workspace标记文件 (备份)
  场景: 前两条通道都断时的最后通路
  延迟: <60秒

为什么不只用sessions_send：因为isolated session里，message工具直发飞书会静默失败。你发了一条消息，你看到它发出去了，但它没到。这种失败不会报错——只会让你以为一切正常。

三通道实践教训（来自6月25日事故）：销售部和品牌部日报consecutiveErrors连续两天没人知道。原因就是只走了message→飞书的单通道，message失败了但没人监控。多链通讯铁律由此诞生。

---

反模式清单（别照抄照搬）

反模式1：CEO替所有部门干活

CEO第一次跑通模板→打包移交部门。第二次CEO还自己做→这不是效率，是肿瘤。CEO的时间应该花在跨部门决策上，不是修一条cron。

血的教训：6月25日，CEO手动修了两条cron的delivery bug。用户纠正：应该派数据中心去修，CEO只统筹。

反模式2：治理文件散落在MEMORY.md

天宪、铁律、敕令混在一堆对话记录里——你永远不知道哪条还在生效。宪法必须有自己的文件。铁律必须有"为什么"的注释。

反模式3：巡查只看"交没交"

监察部如果只看cron有没有产出——不看产出质量——等于没监察。日报写"[待定][日期]"也是"交了"。巡查核心不是存在性，是质量。

反模式4：创建cron没有校验

model字段空缺？静默跳过。payload含模板变量？Write failed。没有创建校验=埋雷。每条cron创建必须确认：model必填/payload纯文本/首跑24h人工验证。

反模式5：子Agent泛滥

各部门自己建子Agent，CEO也替部门建——子Agent数量爆炸。新建之禁：各部门必须上报CEO方能建，CEO不得在部门未上报时擅自替建。

反模式6：免费模型当万能药

免费模型的结果不加验证就发布——幻觉、格式乱码、受众错位。获客线模型必须经过对比验证，质量不达旧模型→立刻回退。不能降质。

---

学习系统

每个部门每天一次自主学习。搜索当日领域前沿→产出学习笔记→入大脑代谢管线。

学习系统设计原则：

• 7部门错峰执行（07:30→08:30，间隔10分钟）
• 每个部门限定自己领域搜索（不跨域、不跑题）
• 笔记≤500字（不是综述，是"今天对我部门最有用的一个信号"）
• 空窗期处理：如果某天没产出有效信号→写"今日无高质量信号"，不写废话填充

---

日报报告系统

七部门每日21:00-22:00产出日报，行政部22:00汇总。日报不是"今天干了啥"——是"今天发现了什么问题、做了什么决策、明天要做什么"。

日报四要点：

1. 具体文件名（不说"写了报告"，说"写了BUG诊断报告_20260626.md"）
2. 具体数字（不说"有一些cron失败"，说"2条cron连续3天consecutiveErrors"）
3. 已消费产出和待完成事项
4. 任何异常标记（不说"正常"——"正常"是一个需要被消灭的词）

日报禁止词：禁止"正常""待定""[日期]""[待定]"——出现任意一条，判定为不合格日报。

---

巡检制度

每日巡查（数据中心+监察部）

• cron运行状态（consecutiveErrors扫描）
• 日报质量抽查（随机抽2个部门）

每周巡查（周五22:00，监察部）

• 全量cron健康检查
• 产出质量全量检验（对照质量锚点）
• 费用追踪（Token消耗趋势）
• 修复委托表

修复委托表

text

故障              → 委托部门
cron连续失败      → 数据中心
产出质量不达标     → 对应部门+监察部复核
通讯通道异常      → 数据中心
治理文件腐化      → CEO

---

References

• references/communication-patterns.md — 三通道通讯详细协议（路由/故障切换/健康指标）
• references/cron-templates.md — 每日学习/日报/巡查/周维护cron模板
• references/common-errors.md — 常见错误模式+诊断+修复
• references/repair-playbook.md — 修复委托+自动修复规则