← 返回洞察1 个人 + 5 个 AI 单元 = 一家公司
2026 年 7 月 · 15 分钟阅读
1 个人 + 5 个 AI 单元 = 一家公司
OOMeta 内部运营全景案例
1 个人类创始人 + 5 个 AI 数字团队 + 1 个 CEO agent，每天协作运营一家真实公司——这不是 demo，是我们的实际操作系统。OOMeta 自 2025 年成立以来，一直在用自己构建的 AI 治理系统运营公司。这篇文章完整拆解这套系统的架构、流程和实战结果。
关键定义
AI 单元 一个运行在 Hermes Agent 框架上的独立 agent 系统，拥有自己的 SKILL.md 技能定义、工具集、AQ 任务队列、cron 执行周期和输出目录。AI 单元像人类员工一样每天上班，执行日常运营任务而非聊天问答。
AQ (Action Queue，行动队列) 每个 AI 单元的优先级任务队列，每个条目包含任务 ID、来源信号、优先级（P0-P3）、状态、截止时间和依赖关系。CEO agent 将信号转化为 AQ 条目，单元按优先级顺序消费，失败任务自动重试最多 3 次。
问题：一个人的公司怎么像团队一样运营？
OOMeta 的创始人 Keyon Zeng 面临一个所有独立创业者都熟悉的问题：一个人只有 24 小时。你需要做产品、做销售、做研究、做运营、做财务——但你的带宽是线性的，而任务是指数级的。
传统的解法是外包、兼职或早期招聘。但 OOMeta 选择了一条不同的路：用 AI 数字团队填补组织空白。不是把 AI 当作工具（ChatGPT 问答、Copilot 补全），而是把 AI 当作可编程的员工——每个 AI 单元有自己的技能、工具、行动队列和心跳，像人类员工一样每天"上班"。
"我们的目标不是用 AI 替代人类，而是用 AI 构建一个可以独立运转的组织层。人类创始人做决策，AI 单元做执行。"
—— Keyon Zeng, OOMeta 创始人
这个思路的核心洞察是：公司运营的本质不是"人"而是"角色"。每个角色有明确的职责、工具和输出标准。只要这些可以被编码，AI 就可以承担。OOMeta 把公司运营拆解为 5 个数字团队，每个团队由一个 AI 单元驱动。
架构：5 个 AI 单元 + 1 个 CEO agent
OOMeta 的运营架构建立在 Hermes Agent（由 Nous Research 开发）之上。整个系统由 6 个核心组件构成：
Research 单元：每 2 小时自动扫描全球 AI 信号——竞争动态、监管变化、技术突破。使用 web 搜索和抓取工具，捕获信号后写入共享 SQLite 数据库。仅 6 月最后两周捕获了 180+ 条信号。
Capital 单元：A 股量化分析单元。每日开盘前执行持仓监控，收盘后运行盘后分析。使用金融数据 API，输出结构化分析报告。
Product 单元：产品路线图管理、原型设计、竞品对标。从 FinOps MVP 到网站功能迭代，完成从需求分析到代码实现的完整闭环。
Operations 单元：知识管理、cron 健康度审计、系统卫生检查。确保所有单元的心跳文件新鲜、输出目录整洁、系统配置一致。
Sales 单元：销售管道管理、网站内容选题、GTM 弹药包生成。跟踪 50+ 竞争对手/替代方案，维护 ICP 画像和分发策略。
CEO agent：每天读取每个单元的心跳、AQ 状态、新信号，做跨单元调度和健康检查。如果某个单元心跳过期，自动标记并升级。
每个 AI 单元都是一个独立的 agent 系统，运行在 Hermes Agent 框架上。它们不聊天，它们干活——每个单元有自己的 SKILL.md 文件定义技能，有自己的 AQ（Action Queue，行动队列）管理任务，有自己的 cron 作业定义执行周期，有自己的输出目录存放产出。
信号→决策管线：从原始信号到可执行行动
OOMeta 的运营不是靠聊天窗口，是靠数据驱动的信号管线。整个流程可以概括为四个阶段：
信号捕获 → AQ 优先级排序 → 单元执行 → 制品验证
第一阶段：信号捕获。 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→执行→验证 这条管线是我们运营的脊柱。没有它，5 个 AI 单元就是 5 个孤岛。有了它，它们是一台机器。"
—— OOMeta 内部架构文档
单元自治与协作：独立但互联
每个 AI 单元在设计上是自治的——它们有自己的工具、cron 作业和心跳。Research 单元不需要等待 CEO agent 的指令才开始扫描；它按自己的 cron 计划（每 2 小时）自动执行。Capital 单元在交易日自动开盘和收盘分析。
但自治不等于孤立。单元之间的协作通过三个机制实现：
1. 共享信号空间。 Research 捕获的信号可以被 Sales 使用（例如：竞争对手发布 → Sales 更新竞争雷达），也可以被 Product 使用（例如：技术突破 → Product 评估对路线图的影响）。所有信号写入 SQLite，任何单元都可以读取。
2. AQ 跨单元依赖。 一个任务可能需要多个单元协作。例如：Research 发现新的合规要求 → AQ 创建任务给 Research（分析要求）和 Product（评估产品影响）和 Sales（更新销售材料）。CEO agent 管理这些跨单元依赖。
3. 心跳健康检查。 每个单元定期（通常每 15-30 分钟）写入心跳文件，包含：单元状态、最后执行时间、AQ 队列长度、错误计数。CEO agent 读取所有心跳，如果某个单元心跳过期或错误率过高，自动创建修复任务。
这种设计的关键好处是：单个单元的故障不会影响整个系统。如果 Research 单元因 API 限流失败，Capital 和 Sales 单元继续运行。CEO agent 会检测到 Research 心跳异常，创建修复任务或降级处理。
人类-AI 边界：什么由人做，什么由 AI 做
这是整个系统最关键的设计问题。不是所有事情都应该自动化。OOMeta 对"人类做什么 vs AI 做什么"有明确的边界划分：
人类创始人做：
- 战略决策（进入哪个市场、与谁合作）
- 重大产品方向（路线图的季度调整）
- 对外沟通（客户会议、合作伙伴关系）
- 审批 AI 单元无法自主决定的行动（如定价变更）
- 系统架构设计（增加/移除 AI 单元）
AI 单元做：
- 日常运营（信号扫描、数据分析、内容生成）
- 重复性任务（健康检查、报告生成、格式校验）
- 持续监控（竞争雷达、合规跟踪、系统健康）
- 信息聚合（跨源信号去重、分类、优先级排序）
需要人类审批：
- 对外发布的公开内容（网站文章、社交媒体）
- 涉及财务决策的行动（交易、定价）
- 修改系统配置（新增 cron 作业、修改 AQ 优先级算法）
- 任何 P0 级别的紧急响应
这个边界不是静态的。随着系统运行时间增长，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 单元本身出问题，系统也能检测到。
实战结果：14 篇洞察文章、每日交易、销售管道
这套系统不是概念验证，是 OOMeta 每天在用的生产系统。以下是截至 2026 年 7 月的实际运行数据：
内容产出
• 14 篇已发布的洞察文章（包括本篇），全部由 Research + Product 单元协作完成选题、研究和初稿
• 30+ 个内容选题，含 ICP 角度和分发策略，由 Sales 单元维护
• 网站内容持续更新，Product 单元管理路线图和发布计划
交易运营
• Capital 单元每日执行 A 股开盘前分析和收盘后分析
• 持仓监控、风险指标计算、交易信号生成全部自动化
销售管道
• Sales 单元跟踪 50+ 竞争对手/替代方案
• 维护 ICP 画像、价值主张、竞争定位文档
• 生成 GTM 弹药包，供人类创始人在客户会议中使用
系统健康
• 每天自动检查 6 个单元（5 个数字团队 + CEO agent）的心跳新鲜度和质量
• 心跳过期率 < 2%，平均恢复时间 < 15 分钟
• 信号捕获：6 月最后两周 180+ 条信号，去重后 120+ 条有效信号
这些数字背后是一个关键事实：OOMeta 的 AI 单元已经连续运行超过 6 个月，没有一次因系统故障导致运营中断。当然，不是没有失败——API 限流、网络超时、数据格式变化都发生过。但系统的设计（心跳检测、自动重试、任务升级）让这些失败被快速发现和修复，而不是累积成灾难。
这对企业意味着什么：AI 单元需要治理
如果 OOMeta 可以用 1 个人 + 5 个 AI 单元运营一家公司，那么你的企业很快就会有 50 个、500 个、5000 个 AI 单元在运行。不是"未来"，是现在。每个部门都会部署自己的 AI agent——市场部的文案 agent、销售部的线索 agent、工程部的代码 agent、财务部的报告 agent。
但这里有一个关键问题：谁管理这些 AI 单元？
如果你的企业有 500 个 AI 单元在运行，每个单元有自己的工具、数据源和输出，但没有统一的治理层，你会面临：
- 可见性黑洞：不知道哪些 AI 单元在运行、它们用什么数据、输出什么结果
- 合规风险：AI 单元可能使用未经授权的数据、违反监管要求、产生偏见输出
- 成本失控：每个单元调用 API、消耗计算资源，但没有统一的成本归因
- 质量不一致：没有统一的验证标准，每个单元的输出质量参差不齐
- 故障蔓延：一个单元的故障可能级联影响其他单元，但没有心跳检测和自动修复
OOMeta 的 5 个 AI 单元 + CEO agent 架构，本质上就是一个AI 单元的治理层。它解决的问题——信号管理、任务调度、健康监控、制品验证——正是企业在大规模部署 AI agent 时面临的核心问题。
"我们给自己建的治理系统，现在可以给你建。OOMeta 交付的不是报告，是能跑的系统——我们自己的运营架构就是产品原型。"
—— OOMeta AI
OOMeta 的差异化不是我们写了多少篇白皮书，而是我们自己每天在用这套系统运营公司。我们的心跳文件、健康检查、信号日志——都是真实的生产数据，不是 demo 数据。如果 OOMeta 可以用 AI 单元运营一家公司，你的企业也可以用 AI 单元运营你的业务——但你需要一个治理层来管理它们。
常见问题
OOMeta 的运营架构由哪些核心组件构成？+
6 个核心组件：Research 单元（每 2 小时扫描全球 AI 信号）、Capital 单元（A 股量化分析）、Product 单元（产品路线图和原型设计）、Operations 单元（知识管理和系统卫生）、Sales 单元（销售管道和竞争雷达）、CEO agent（跨单元调度和健康检查）。
信号→决策管线如何运作？+
四阶段：信号捕获（Research 每 2 小时 web 扫描写入 SQLite）→ AQ 优先级排序（CEO agent 分类打标签分配 P0-P3 优先级）→ 单元执行（单元按优先级调用工具集执行任务）→ 制品验证（输出需去重、格式校验、编译检查，通过进入知识库，失败返回 AQ）。
AI 单元如何既自治又协作？+
自治：每个单元有自己的工具、cron 作业和心跳，按计划自动执行。协作通过三机制：共享信号空间（SQLite 中任何单元可读）、AQ 跨单元依赖（CEO agent 管理多单元协作任务）、心跳健康检查（每 15-30 分钟写入心跳，CEO agent 检测过期自动修复）。
人类和 AI 之间的任务边界如何划分？+
人类做战略决策、重大产品方向、对外沟通和系统架构设计。AI 单元做日常运营、重复性任务、持续监控和信息聚合。需要人类审批的：对外发布内容、财务决策、系统配置修改、P0 级紧急响应。原则：风险越低自主权越高，可逆性越强自主权越高。
OOMeta 的 AI 单元系统取得了哪些实战结果？+
14 篇已发布洞察文章（Research + Product 协作完成）、Capital 单元每日 A 股分析自动化、Sales 单元跟踪 50+ 竞争对手、心跳过期率低于 2% 平均恢复不到 15 分钟、6 月最后两周捕获 180+ 信号。系统连续运行超 6 个月无运营中断。
相关文章
Docusign 把合同层开放给所有 Agent：9 月 30 日起 MCP 客户端可直接调用
9月4日 Docusign 宣布其 MCP Server 将于 9 月 30 日向所有 AI Agent 开放：Claude、ChatGPT、Gemini、Copilot、Slack 等任何 MCP 客户端都能原生调用合同分析、发送与签署，由 AI 引擎 Iris 注入历史谈判与政策上下文。签署动作需要企业级治理。
Coder Agent Relay：Cursor 云 Agent 的代码与密钥留在墙内
9月3日 Coder 发布 Agent Relay，SpaceXAI 为首发伙伴：Cursor 云 Agent 推理在云端，工具调用改在客户自有 Coder 工作区执行——源码、密钥、内部服务不出墙。受监管行业首次能用上前沿编码 Agent。Gartner：2027 年 80% 软件工程师需为生成式 AI 升级技能。
2 周从想法到原型——跨境金融科技公司的 AI 治理合规实战
一家月处理 $500M+ 的跨境金融科技公司，在 2 周内从零到一建立了 EU AI Act 合规治理框架——不是 PoC，是生产级交付。本文复盘三个层面的治理真空与 2 周 Agent Governance Check Sprint 方案。
AI 治理检查：发现 12 个影子 Agent——一家制造企业的治理觉醒
50+ AI Agent 在生产环境运行，但 IT 和安全团队都不知道具体有多少。OOMeta 的 Agent 发现扫描找到了 12 个未经授权的影子 Agent。
OOMeta AI
一家 AI-native 治理公司。我们帮企业构建跨供应商、跨监管的 Agent 治理层。我们给自己建了，现在可以给你建。OOMeta 的 5 个 AI 单元 + CEO agent 架构，就是我们在客户环境里部署的治理层原型。
预约诊断会