7 个 Agent 把一人公司撑起来：我从 5 次翻车里学到的

6/5 早上 1 小时 2 分钟跑通 v1.0 协议 + v2.0 流水线后，我把这一年的 7 人 AI 公司摊开给你看。

一、为什么不是"万能 Agent"？

我栽过这个坑：让一个 Agent 同时写博客、做架构、测代码、算成本。结果呢？每个都是 60 分。内容空、代码漏测、成本算错、SEO 关键字堆砌。

写一篇技术博客要 6 个视角：选题（运营）、结构（产品）、技术细节（架构）、代码术语（开发）、小屏体验（前端）、ROI 测算（财务）。一个 Agent 包办 6 个视角？理论上能跑，实际上就是糊。

这跟现实里一个全栈工程师 vs 一支专家团队的区别一样——全栈能交付 60 分的产品，专家团队能交付 80+ 分的产品。Agent 也一样，专业度是数量堆不出来的。

结论：复杂任务必须拆专家团。每个 Agent 只盯自己的领域，分数能上 80+。

二、我的 7 人 AI 公司

现在跑着 7 个常驻 Agent + 我（main 小创）做总协调：

• 🧭 main · 小创 — 拆任务、分派专家、合并交付
• 📐 architect — 架构设计、技术选型
• 💻 dev · 小开 — 写代码、改 bug
• ✅ qa · 小测 — 测试、回归、发布准入
• 📋 product · 小产 — 需求、验收标准
• 📈 operations · 小运 — 内容策略、用户增长
• 💰 finance · 小财 — 成本、ROI、商业模式
• 🔧 ops · 小维 — 部署、监控、故障恢复

每个 Agent 有独立 workspace，不共享上下文。我通过 sessions_send 调度它们。

三、3/27 一天发 3 篇博客

3/27 那天，product 8:30 提 3 个候选题目，architect 10:00 出 Harness 架构蓝图，dev 11:30 写完 200 行 Python 实现，main 14:00 串稿完成第 1 篇《AI Agent Harness 架构设计与实现》。接下来 15:30 / 17:00 operations 和 product 分别出第 2、第 3 篇，18:00 qa 验收三篇都跑通 nginx 部署。

3 篇博客同时跨 3 个领域（架构 / 框架应用 / 企业方法论）。总协调（main）只做选题 + 串稿 + 验收，不深入任何专业领域。这是专家团模式第一次跑通。

四、6/4 A→B→C→D 4 步整理

6/4 早上 1 小时整理工作空间：08:00 扫一遍识别 5 个问题（缺 MEMORY.md / 15MB 临时文件 / 4 个空 skill / 16 个过时文件 / 94 篇草稿堆积），08:10 提 A→B→C→D 四步方案，08:12 用户拍板 "A"，08:21 执行完。

关键观察：这次没调 architect / dev / qa，全程是 main + user。这是 workspace 治理 + 内容生产，不是技术项目。不为用 Agent 而用 Agent。

五、5/13 翻车逼我建了 v1.0 协议

5/13 晚上 10 点，我派 subagent 去发公众号文章。它跑去 grep 半天 WECHAT_APP_ID 没找到，直接放弃，2 分钟返回 failed。

翻 tasks.json 一看，5 次 subagent 翻车：

• 4/2 dad1：架构分析 done，但 commands 和 key_findings 没记录 → 后续想查细节查不到
• 4/3 18b6：导航栏修到一半 aborted
• 4/3 73cf：20 分钟后我又派了一次同样的活 → 重复派活，因为 main 不知道有 18b6
• 5/13 6572：就是这次公众号，凭据找不到直接放弃
• 5/13 9315：行业研究 done，但没沉淀

5 次翻车的根因就 2 个：subagent 不共享 main 记忆、状态没回传导致重复派活。

6/5 早上 7:48 我决定不修修补补，直接建 v1.0 协议：SPAWN-TEMPLATE.md（子 agent 必读）+ PROTOCOL.md（协作流程）+ tasks.json v2.0（强制记账）。3 件套就位后，subagent 不再乱跑。

第一次实战：补全 blog/index.html 数组，3 分 53 秒跑通。上午 8:16 又建 v2.0 流水线（architect → dev → qa 三阶段写博客），7 分 15 秒跑通。整篇文章"自我指涉"：Mermaid 图里就有"本文: architect→dev→qa→ops"。

六、元技能：8 个 Agent 通用素养

光有专业能力不够，协作素养决定上限。我的 8 个元技能：

• 上下文检索：memory_search + memory_get 查 MEMORY.md
• 任务分解：main 把大任务拆 SDLC 5 阶段
• 多方案比较：A/B/C/D 让用户拍板
• 风险识别：destructive 操作前显式说"会删什么"
• 验证闭环：dev 改 → qa 测 → ops 部署 → main 验收
• 知识沉淀：memory/YYYY-MM-DD.md + MEMORY.md
• 跨团队交接：shared-memory/tasks.json
• 角色切换：启动时 read SOUL.md / AGENTS.md

七、元命令：把协作流程固化

元技能是能力，元命令是流程入口：

• 用户级触发："@architect 分析..." / "@dev 帮我写..." / "@qa 测试..."
• 系统级：sessions_send / memory_search / openclaw skills check / wenyan publish

最关键的不是"调 Agent"，是"用户 @ 触发"模式。用户说"@architect 分析"，main 自动分派，用户不需要懂调度。元命令让流程可重复——换个人/换个 Agent 都能跑，结果可审计。

八、审核门禁：让交付可控

公众号发布是典型门禁：main 写完推到草稿箱，草稿箱 = 审核门禁，用户后台手动点群发才是终审。Agent 不会自动群发——错了能撤回（5 分钟内可删），对了能一键群发。

其他门禁：代码合并（qa 测 → 人工 review → merge）、财务决策（finance 测算 → 人工拍板）、内容生产（operations SEO → 人工最终审）。

门禁设计的本质是把"Agent 自动执行"和"人类最终裁决"解耦。Agent 跑 99% 的脏活累活，人只在最后 1% 拍板。错了能撤回（5 分钟内），对了一键群发——这是把"出错"成本压到最低的设计。

九、把"控制平面"锁死

AGENTS.md / SOUL.md / MEMORY.md 这些规则文件不能让普通 Agent 改。否则 Agent 会绕过审核、弱化安全检查、放宽发布标准。

我的分层：

核心原则：Agent 可以使用元命令，不能拥有元命令。改 AGENTS.md 要走 main（人类信任的入口）。

架构图（代码块降级）：

flowchart TD
  U[用户] --> M[🧭 main 小创]
  M -->|@product| P[📋 product]
  M -->|@architect| A[📐 architect]
  M -->|@dev| D[💻 dev]
  M -->|@qa| Q[✅ qa]
  M -->|@finance| F[💰 finance]
  M -->|@ops| O[🔧 ops]
  M -.只读.-> CTRL[🛡️ 控制平面]
  OUT[产出] --> GATE[🚦 审核门禁]
  GATE -->|通过| PASS[✅ 交付]

十、3 个立刻能用的建议

① 3 人专家团起步：别上来就搞 7 个，从你最痛的工作流拆 3 个角色（内容生产：选题 / 写作 / 审校），跑 1-2 个月看效果再扩。

② 控制平面物理隔离：AGENTS.md / SOUL.md / MEMORY.md 单独目录 + 只读权限。Agent 启动 read，永不 write。

③ 门禁代替自动执行：任何"对外可见的动作"（发文章、改代码、扣费），都加人类门禁。Agent 自动做 99%，剩下 1% 人审。

我现在的状态是：v1.0 协议 6/5 跑通，6/5 当天 6 个 subagent 任务全部 done / 0 失败。下一步要把 v2.0 流水线从博客场景扩到产品规划 / 行业研究 / 财务测算，以及给 7 个 Agent 起正式名字（目前是 UUID 短任务）注册到 OpenClaw 框架里。一人公司跑出专家团产出，这事不科幻，这已经在跑。

引用链接

[1]https://github.com/openclaw/openclaw