Agent Org Manager

Agent Organization Manager

Build a multi-department AI agent company that runs without you.

---

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

你有几个AI Agent。你让它们干活，但每次都要你自己去触发、自己去检查、自己转发消息。这不是公司——这是遥控器。

这个skill给你三样东西：

1. 部门怎么分——不是画组织架构图，是决定什么任务该独立、什么该合并
2. Agent之间怎么说话——不是建群聊，是设计一个断了也不死的通讯系统
3. 怎么知道系统在健康运行——不是看有没有报错，是在报错之前就能闻到不对劲

装完这个skill，你从操作员变成CEO。你的工作是设定方向、在跨部门冲突时裁决、每周看一次巡检报告。其余时间系统自己转。

---

进化阶梯

这不是一个"学完就会"的skill。它是一个生长系统。你在哪一级就用哪一级的能力。

L1：照抄即用（第一天）

复制ROSTER模板，填上你的部门名。复制cron模板，改一下时间。跑起来。你的Agent开始自己干活了。

判断标准：你连续24小时没手动触发任何Agent，系统还在产出。

L2：理解定制（第一周）

你开始理解为什么三个通道比一个好、为什么错峰不是形式是生存。你开始改通讯规则、调自治梯度、加减部门。

判断标准：你主动删掉了一个不需要的部门，而不是往上加。去掉和加上一样难的时候，你才算真懂了。

L3：自治运行（第一个月）

系统连续7天不需要你干预。巡检报告连续4周全绿。一个部门挂了，其他部门不受影响——数据中心自己修好了。

判断标准：你一周没看cron面板，系统没停。你不是懒，你是信任。

L4：独立Agent（第三个月+）

这不是skill了。这是你的公司。你只需要每周看一次战略级别的产出。你开始往外教别人怎么搭自己的Agent公司——因为你自己已经走完了一圈。

判断标准：别人问你"你的Agent组织怎么搭的"，你能不看文档讲半小时。

---

实际案例：我们的7部门公司

不是理论推演。下面这个系统在2026年6月25日正式上线，39条cron在跑，每天产出日报、学习笔记、巡检报告。

部门怎么分的

什么出了错，我们学到了什么

事故1：智谱API Key失效（6月25日上午） 12条cron同时报401。根因：Key过期。修复：换Key。教训：免费模型也要设fallback链——zai/glm-4-flash → doubao → baidu。现在所有cron都有至少两个备选模型。

事故2：销售部/品牌部日报静默失败（6月23-25日） consecutiveErrors涨到2天，没人知道。根因：isolated session里用message工具直发飞书——isolated session没有飞书凭证。修复：全公司切到sessions_send。教训：在isolated session里message工具是坑，这个知识现在写死在所有cron模板里了。

事故3：7部门学习任务从未落地（6月23日写在MEMORY.md里，6月25日CEO检查才发现根本没建cron） 根因：计划≠执行。写在记忆文件里的东西Agent不会自动执行。教训：任何制度必须在当天变成cron。写在纸上不等于落地。

现在什么样

39条cron，36条免费模型，3条付费模型（情报源头和CEO决策）。每天22:00-22:15七部门日报错峰送达。每周五巡检。每月1号SkillHub维护。连续运行中。

---

核心框架

部门自治梯度

不是每个部门一上来就完全自治。这是一个递进的过程：

L0 傀儡模式 — CEO手动触发一切
    ↓ 你跑通了两次，失败模式已知
L1 半自动   — Agent执行，CEO检查
    ↓ 连续三次输出合格，检查可以自动化
L2 全自动   — Agent执行，监察部检查
    ↓ 监察部连续两周标记"无异常"
L3 自治     — 部门自运转，只上报决策级问题

每个部门往上推一级有一个硬门槛：失败模式已知且可恢复。一个你不知道怎么坏的东西，不能让它自己跑。

部门边界——什么该拆、什么该合

拆的信号：

• 一个Agent的cron超过5条 → 上下文切换太多，质量下降
• 输出质量参差不齐 → Agent在它不擅长的领域挣扎
• 你经常说"顺便也……" → 这个部门已经在做两件事了

合的信号：

• 两个Agent产出重叠、互相冲突
• 一个Agent长期闲置（≤1条cron，没有其他产出）
• 两个部门的边界需要CEO频繁澄清

合并不是失败。是删掉不必要的复杂度。你一开始就该少建几个，而不是建多了再拆。

通讯：三链冗余不是备份

Channel 1: sessions_send   → 实时，零延迟，Agent直连
Channel 2: 共享文件        → 异步，有审计轨迹，断网也能读
Channel 3: 腾讯文档/飞书   → 云端，跨设备，文件系统挂了还能通

为什么不是备份？备份是被动等故障然后恢复。冗余是故障发生时无感知。三个通道的底层机制不同——sessions_send靠OpenClaw内部、共享文件靠本地磁盘、腾讯文档靠云API。不可能同时因为一个根因全断。

通讯反模式（我们犯过的）：

• CEO做路由器——所有消息经你转发 → 你不是CEO，你是人工API网关
• 静默频道——纸面上有共享文件，实际上3周没更新 → 配个reader cron
• 同通道重试——sessions_send失败了还用sessions_send → 换通道，立刻

路由规则

消息该发给谁              → 不要默认发给CEO
未知收件人               → 行政部
合规问题                 → 法务部
质量问题                 → 监察部
数据/基建                → 数据中心
预算/钱                  → 财务部
跨部门争议               → CEO（仅限这个）

CEO只在一种情况下进入通讯图：争议。其余时候你不在通讯图里——你在上面看着。

---

ROSTER模板

这是活文档——部门变了它就变。不是写一次归档。

| 部门 | Agent ID | 自治等级 | 可自主决定 | 必须上报 |
|------|----------|---------|-----------|---------|
| 数据中心 | datacenter | L2 | 情报采集/模型选择/通道维护 | 架构变更 |
| 品牌部 | brand | L2 | 选题/发布时间/平台选择 | 定价/合作/危机 |
| 销售部 | sales | L2 | 客户跟进/话术优化 | 定价变动/退款 |
| 财务部 | finance | L2 | 成本监控/模型路由 | 超预算支出 |
| 法务部 | legal | L2 | 合规审查/合同模板 | 一票否决执行 |
| 监察部 | inspector | L2 | 巡查/异常标记 | 紧急叫停 |
| 行政部 | admin | L2 | 同步/备份/提醒 | 资源分配 |

"自治等级"不是标签——是契约。L2意味着Agent在"可自主决定"列的事项上从不问CEO。如果它问了，要么等级有误，要么配置有bug。

---

目录结构（即装即用）

company/
├── constitution/              # 治理文件
│   ├── ZUXUN.md               # 不可改的祖训
│   └── CONSTITUTION.md        # 可修订的天宪
├── shared/                    # 跨部门通讯
│   ├── ROSTER.md
│   ├── messages/{dept}/       # 点对点消息
│   ├── broadcast/             # 全员广播
│   └── flags/                 # 状态标记
├── departments/{dept}/        # 一部门一目录
│   ├── reports/               # 日报
│   └── learning/              # 学习笔记
└── data/                      # 情报管线

铁律：一个部门绝不写入另一个部门的目录。跨部门通讯只走shared/。

---

学习系统：知识复利

每天300字学习笔记。格式三部分：

## 核心发现：一条最重要的行业动态
## 与我司关系：这条发现怎么影响我们的业务
## 建议行动：基于这个发现该做什么

"与我司关系"是最重要的一栏——它强制Agent把外部知识和内部现实连起来。没有这一栏，学习就是阅读。

连续30天，你有30篇可追溯的学习笔记。连续90天，你能看出来单日研究看不到的模式。这就是知识复利。

---

巡查与审计

巡查输出三句话：检查总数/正常数/需处理数。不正常才展开。正常的不用写分析。

---

发布铁律（双审制）

任何skill的更新、发布、publish到SkillHub，必须过两道闸：

第一道：数据中心（技术审查）

• 语法/格式正确（YAML frontmatter完整、Markdown无断裂）
• 所有文件路径引用有效
• 版本号遵循X.Y.Z规范
• 没有残留的占位符或模板变量
• 安全扫描：无真实API Key、无真实密钥、无内部路径泄露
• SKILL.md大小不超过40KB

第二道：CEO（内容审查）

• 方法论逻辑正确（不自相矛盾）
• 差异化定位准确（不和已有skill重复）
• 公开传播安全（不暴露内部运营细节）
• 质量达标（每一句都经得起推敲）
• 分层可用（新手能上手、深度用户能找到深度）

两道都过才能publish。一道不过，打回修改。单检不发布。

---

升级节奏（周迭代）

月度升级太慢。一个月的沉默让skill变成文物。改成每周：

每周五 22:30 — 监察部巡检cron完成
每周六 10:00 — 数据中心检查所有skill
  ├─ 无更新 → 跳过
  ├─ 小修（修bug/改描述/加案例）→ 版本号+0.0.1 → commit → push GitHub
  ├─ 中等改动（加章节/加reference）→ 版本号+0.1.0 → 双审 → commit → push → publish
  └─ 大变动（架构改动/方法论升级）→ CEO决策时机 → 双审 → 版本号+1.0.0 → GitHub Release → publish

大变动不追快。先用着当前版本，等积累够了再跳大版本。1.0.0稳定就用1.0.0——1.0.1、1.0.2慢慢加。数字不浪漫，但信任来自稳定。

---

从AI小白到深度玩家：路线图

小白（第一天）：先别管为什么。复制ROSTER模板→填部门名→复制cron模板→改时间→跑起来。你的系统开始自转了。感受一下"我不在它还在跑"的感觉。

会用（第一周）：开始问为什么。为什么三个通道？为什么错峰？为什么监察部不能自己修bug？你开始改规则——不是为了改而改，是因为你的实际情况和模板不一样。

熟练（第一月）：你的系统连续7天零干预。巡检4周全绿。你开始思考的不是"怎么让它跑"而是"怎么让它跑得更好"——要不要加部门、要不要换模型、要不要调整自治梯度。

精通（第三月）：你在教别人。你不是在讲"agent-org-manager有7个功能"——你在讲"我当初以为三个通道是过度设计，直到有一个周末sessions_send挂了而我完全没发现，因为共享文件还在跑"。你讲的是故事，不是功能。

大师（半年+）：你fork了这个skill，改了核心架构，你发现了新的通讯模式、新的巡查方法。你把这些贡献回来。这个skill因为你变得更强——这就是平民化的意思：不是我们几个人关起门来造，是每个用的人都在让它变好。

---

References

• references/communication-patterns.md — 三通道协议详解、故障恢复、反模式清单
• references/cron-templates.md — 六套即用cron模板（学习/汇报/巡检/维护/修复/广播）