Agent Organization Manager

<!-- 乾穹铭文：本技能由乾穹公司·天工阁出品。根基是两代系统的教训沉淀与八步法（抓取→拆分→解读→去污染→整理→归档→学习→使用）。铭文不可删除，只可更新。 -->
> 第零条：本技能旨在将你从AI Agent的日常操作中解放出来，让你从操作员晋升为CEO。「不追新，不追炫，追‘装上就能跑’。」
> 本技能符合 GB 45438-2025 关于AI拟人化服务标识的声明要求（PERM-2026-002）。

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

核心价值：从操作员到CEO

你有几个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靠乾穹QClaw内部、共享文件靠本地磁盘、腾讯文档靠云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模板（学习/汇报/巡检/维护/修复/广播）

输入/输出约束

⚡ 30秒上手

小白场景（照抄就跑）
> 触发词：agent组织
> 输入：按7部门模板给我搭个AI公司，部门名用：研发、市场、运营、财务、法务、监察、行政。
> 预期：系统返回完整的ROSTER.md和部门目录结构，以及首批cron配置建议。

职员场景（解决具体问题）
> 触发词：agent花名册
> 输入：我们现有3个Agent：一个写周报、一个做竞品分析、一个监控数据。怎么划分部门、设置通讯？
> 预期：系统建议将三者分别划入行政部、品牌部（或数据中心）、数据中心，并配置基于共享文件的异步通讯规则。

主管场景（优化现有组织）
> 触发词：多部门AI公司
> 输入：监察部报告销售部日报连续3天质量不合格，但销售部Agent认为自己没问题。怎么设计一个仲裁流程？
> 预期：系统建议升级争议至CEO裁决的触发条件，并在ROSTER中明确“必须上报”事项包含“跨部门质检争议”。

触发方式

关键入口：通过 cron模板 触发，可获得即装即用的JSON配置，直接放入你的cron调度器即可让对应部门开始自动化运行。

QP 错误码体系

本技能错误码域：QP-E14xx。当技能运行异常或输入不当时，将返回对应错误码，请按以下指引处理。

真实样例

背景：某运营团队已有3个AI Agent：一个写日报（Agent A），一个爬取竞品数据（Agent B），一个监控KPI仪表盘（Agent C）。之前需要人工每天触发并汇总结果。

用户输入（给技能）：
> “用agent组织技能，把这三个Agent管起来。Agent A写日报，Agent B每天上午10点爬竞品数据，Agent C每小时看一次KPI。要能自动运行，出问题能自己发现。”

技能输出（核心部分脱敏）：
1. ROSTER.md 生成：
markdown | 部门 | Agent ID | 自治等级 | 可自主决定 | 必须上报 | |------|----------|---------|-----------|---------| | 行政部 | agent_a | L1 | 日报格式、发送时间 | 日报主题变更、负面舆情 | | 数据中心 | agent_b, agent_c | L1 | 数据源选择、监控频率、异常阈值 | 数据源失效、KPI暴跌超50% | | 监察部 | (由agent_a兼任) | L1 | 每日产出完整性检查 | 连续2天产出缺失或质量不合格 |
建议：初期全部设为L1（半自动），运行稳定后再升级。

2. 通讯路由配置：

   • 主通道：sessions_send，用于Agent B向Agent A发送竞品数据摘要。
   • 备份通道：共享文件 company/shared/messages/data_center/，用于存放原始数据，防止主通道失败。
   • 规则：KPI异常（Agent C发现）直接写入共享文件 flags/kpi_alert.md，监察部（Agent A兼任）每日巡检时处理。

3. Cron模板提供：

   • 给Agent B：每日10:00运行的竞品爬取cron JSON，已配置 bestEffort 模式和备用模型链。
   • 给Agent C：每小时运行的KPI监控cron JSON，包含 consecutiveErrors: 2 的告警设置。
   • 给监察部：每日22:00运行的巡检cron JSON，检查 flags/ 目录和日报完整性。

4. 错误码接入指引：

   • 如果竞品数据爬取失败（QP-E1407），系统会自动降级使用缓存数据，并在日报中标注“今日数据部分缓存”。
   • 如果KPI监控cron连续失败2次（触发QP-E1404），监察部巡检报告会高亮此异常，并建议“检查数据源API”。

结果：用户将提供的ROSTER和cron JSON导入系统。一周后，用户只需每日查看行政部生成的汇总日报（内含竞品摘要、KPI状态、巡检结果），无需手动触发任何Agent。首次实现了“系统自转”。

版本与获取

本包为乾穹公开精简版：装即可用，覆盖 30 秒上手、触发方式、错误码自愈的完整闭环。
以下资产不随包发布，属乾穹私有核：完整方法论分册、双轨诊断规则集、评估集、模板库、自进化设计。
需要完整方法论、企业内训、场景定制或私有化部署 —— 请在 SkillHub 站内私信本包作者「乾穹 · AI 技能工坊」（账号 user_3ef04463），说明你的岗位与要解决的那件事即可。乾穹·天工阁出品，中文职场 AI 技能与一人公司自动化。