1 个人 + 7 个 AI 单元 = 一家公司
OOMeta 内部运营全景案例

1 个人类创始人 + 7 个 AI 阿米巴单元（CEO 调度、元认知督导、交易、研究、产品、运营、销售），每天协作运营一家真实公司——这不是 demo，是我们的实际操作系统。OOMeta 自 2025 年成立以来，一直在用自己构建的 AI 治理系统运营公司。这篇文章完整拆解这套系统的架构、流程和实战结果。

问题：一个人的公司怎么像团队一样运营？

OOMeta 的创始人 Keyon Zeng 面临一个所有独立创业者都熟悉的问题：一个人只有 24 小时。你需要做产品、做销售、做研究、做运营、做财务——但你的带宽是线性的，而任务是指数级的。

传统的解法是外包、兼职或早期招聘。但 OOMeta 选择了一条不同的路：用 AI 数字团队填补组织空白。不是把 AI 当作工具（ChatGPT 问答、Copilot 补全），而是把 AI 当作可编程的员工——每个 AI 单元有自己的技能、工具、行动队列和心跳，像人类员工一样每天"上班"。

"我们的目标不是用 AI 替代人类，而是用 AI 构建一个可以独立运转的组织层。人类创始人做决策，AI 单元做执行。"
—— Keyon Zeng, OOMeta 创始人

这个思路的核心洞察是：公司运营的本质不是"人"而是"角色"。每个角色有明确的职责、工具和输出标准。只要这些可以被编码，AI 就可以承担。OOMeta 把公司运营拆解为 7 个 AI 单元，各司其职、互相校验。

架构：7 个 AI 阿米巴单元

OOMeta 的运营架构建立在 Hermes Agent（由 Nous Research 开发）之上。整个系统由 7 个核心组件构成：

每个 AI 单元都是一个独立的 agent 系统，运行在 Hermes Agent 框架上。它们不聊天，它们干活——每个单元有自己的 SKILL.md 文件定义技能，有自己的 AQ（Action Queue，行动队列）管理任务，有自己的 cron 作业定义执行周期，有自己的输出目录存放产出。

信号→决策管线：从原始信号到可执行行动

OOMeta 的运营不是靠聊天窗口，是靠数据驱动的信号管线。整个流程可以概括为四个阶段：

第一阶段：信号捕获。 Research 单元每 2 小时执行一次 web 扫描，使用 Exa 搜索 API 抓取 AI 行业最新动态。Sales 单元每天扫描竞争雷达。信号包括：竞争对手发布、监管更新、技术突破、客户需求变化等。所有原始信号写入 SQLite 共享状态数据库。

第二阶段：AQ 优先级排序。 信号被 CEO agent 读取并分类。每个信号被打上标签（Research / Capital / Product / Operations / Sales），分配优先级（P0-P3），然后推送到对应单元的 AQ（Action Queue）。AQ 是一个结构化的任务列表，每个任务包含：来源信号、优先级、截止时间、依赖关系。

第三阶段：单元执行。 每个 AI 单元定期检查自己的 AQ，按优先级顺序执行任务。执行过程中，单元调用自己的工具集——Research 调用 web 搜索，Capital 调用金融 API，Product 调用代码生成，Sales 调用 CRM 接口。执行结果以制品（artifact）形式输出。

第四阶段：制品验证。 每个单元的输出必须经过验证。Research 的扫描结果需要去重和分类验证，Capital 的分析报告需要格式校验，Product 的代码需要编译检查。验证通过的制品进入公司知识库，验证失败的返回 AQ 重新执行。

"信号→AQ→执行→验证 这条管线是我们运营的脊柱。没有它，7 个 AI 单元就是 7 个孤岛。有了它，它们是一台机器。"
—— OOMeta 内部架构文档

单元自治与协作：独立但互联

每个 AI 单元在设计上是自治的——它们有自己的工具、cron 作业和心跳。Research 单元不需要等待 CEO agent 的指令才开始扫描；它按自己的 cron 计划（每 2 小时）自动执行。Capital 单元在交易日自动开盘和收盘分析。

但自治不等于孤立。单元之间的协作通过三个机制实现：

这种设计的关键好处是：单个单元的故障不会影响整个系统。如果 Research 单元因 API 限流失败，Capital 和 Sales 单元继续运行。CEO agent 会检测到 Research 心跳异常，创建修复任务或降级处理。

人类-AI 边界：什么由人做，什么由 AI 做

这是整个系统最关键的设计问题。不是所有事情都应该自动化。 OOMeta 对"人类做什么 vs AI 做什么"有明确的边界划分：

这个边界不是静态的。随着系统运行时间增长，OOMeta 逐步将更多任务从"需审批"迁移到"自主执行"。关键原则是：风险越低，自主权越高；可逆性越强，自主权越高。

关键框架：让系统可运行、可审计、可改进

OOMeta 的内部运营建立在四个核心框架之上。这些不是理论概念，是每天在跑的代码。

1. AQ 驱动的任务管理

每个 AI 单元的核心是它的 Action Queue（AQ）。AQ 是一个优先级队列，每个条目包含：任务 ID、来源信号、优先级（P0-P3）、状态（待处理/执行中/已完成/失败）、截止时间、依赖关系。CEO agent 负责将信号转化为 AQ 条目，单元按优先级顺序消费。

AQ 的设计借鉴了经典的优先级队列算法，但加入了 AI 特有的元素：信号来源追踪（知道每个任务来自哪个信号）、执行历史（记录每次执行的结果和耗时）、重试策略（失败任务自动重试，最多 3 次）。

2. SQLite 共享状态（不是 JSON 文件）

早期版本中，OOMeta 使用 JSON 文件作为共享状态。但很快发现 JSON 文件的问题：并发写入冲突、没有查询能力、没有事务保证。SQLite 解决了所有这些问题。

所有结构化数据——信号、AQ 条目、心跳记录、制品元数据——都存储在 SQLite 数据库中。每个单元可以并发读取和写入，SQLite 的 WAL 模式处理并发。CEO agent 可以执行 SQL 查询来生成跨单元报告，而不是解析一堆 JSON 文件。

3. 制品验证纪律

每个 AI 单元的输出（制品）必须通过验证才能进入知识库。验证规则因单元而异：Research 的扫描结果需要去重和分类验证，Capital 的分析报告需要格式和数值校验，Product 的代码需要编译和 lint 检查。

验证失败不是终点——失败的制品被标记并返回 AQ，附带错误信息。单元可以重试，但重试超过 3 次后任务升级到 CEO agent，CEO agent 可能创建修复任务或通知人类创始人。

4. 心跳健康检查

每个 AI 单元定期写入心跳文件（通过 cron 作业），包含：单元名称、时间戳、状态（健康/警告/错误）、最后执行的任务、AQ 队列长度、错误计数。CEO agent 每 30 分钟读取所有心跳，生成健康检查报告。

如果某个单元的心跳超过 1 小时未更新，CEO agent 自动标记为"心跳过期"并创建诊断任务。如果连续 3 次心跳过期，系统发送通知给人类创始人。这个机制确保了即使 AI 单元本身出问题，系统也能检测到。

实战结果：292 篇洞察文章、每日交易、销售管道

这套系统不是概念验证，是 OOMeta 每天在用的生产系统。以下是截至 2026 年 7 月的实际运行数据：

这些数字背后是一个关键事实：OOMeta 的 AI 单元已经连续运行超过 6 个月，没有一次因系统故障导致运营中断。当然，不是没有失败——API 限流、网络超时、数据格式变化都发生过。但系统的设计（心跳检测、自动重试、任务升级）让这些失败被快速发现和修复，而不是累积成灾难。

这对企业意味着什么：AI 单元需要治理

如果 OOMeta 可以用 1 个人 + 7 个 AI 单元运营一家公司，那么你的企业很快就会有 50 个、500 个、5000 个 AI 单元在运行。不是"未来"，是现在。每个部门都会部署自己的 AI agent——市场部的文案 agent、销售部的线索 agent、工程部的代码 agent、财务部的报告 agent。

但这里有一个关键问题：谁管理这些 AI 单元？

如果你的企业有 500 个 AI 单元在运行，每个单元有自己的工具、数据源和输出，但没有统一的治理层，你会面临：

• 可见性黑洞：不知道哪些 AI 单元在运行、它们用什么数据、输出什么结果
• 合规风险：AI 单元可能使用未经授权的数据、违反监管要求、产生偏见输出
• 成本失控：每个单元调用 API、消耗计算资源，但没有统一的成本归因
• 质量不一致：没有统一的验证标准，每个单元的输出质量参差不齐
• 故障蔓延：一个单元的故障可能级联影响其他单元，但没有心跳检测和自动修复

OOMeta 的 7 个 AI 单元架构，本质上就是一个AI 单元的治理层。它解决的问题——信号管理、任务调度、健康监控、制品验证——正是企业在大规模部署 AI agent 时面临的核心问题。

"我们给自己建的治理系统，现在可以给你建。OOMeta 交付的不是报告，是能跑的系统——我们自己的运营架构就是产品原型。"
—— OOMeta AI

OOMeta 的差异化不是我们写了多少篇白皮书，而是我们自己每天在用这套系统运营公司。我们的心跳文件、健康检查、信号日志——都是真实的生产数据，不是 demo 数据。如果 OOMeta 可以用 AI 单元运营一家公司，你的企业也可以用 AI 单元运营你的业务——但你需要一个治理层来管理它们。