OpenOPC
HKUDS/OpenOPC加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个场景：你在深夜突然有一个绝妙的创业想法——做一款面向 Z 世代的 AI 社交应用。你需要的不仅是写代码，还有市场调研、产品设计、竞品分析、商业计划、甚至视频宣传片。传统方式下，你需要组建团队、分配任务、协调沟通，一个人根本扛不住。
OpenOPC（Open One-Person Company）给出了另一种答案：它不帮你找一个 AI 助手，而是帮你凭空建起一整家公司，招募不同岗位的 AI 员工，分配任务，驱动协作，然后从每次执行中学习成长。
这个项目来自香港大学数据科学实验室（HKUDS），在 GitHub 已斩获超过 1710 颗星和 318 个 Fork，MIT 协议开源，正在快速迭代中（最新版本 0.2.4b4）。
OpenOPC 是一个基于多 Agent 协作的"AI 原生公司操作系统"——你描述目标，它自动招募 AI 员工、编排任务流程、沉淀组织记忆，让一个人也能运营一家完整公司。
2023-2024 年，以 ChatGPT 为代表的 LLM 让"一个人+AI 工具"的效率大幅提升。但这套范式有一个根本瓶颈：单一 Agent 的能力天花板。当任务需要跨领域协作——比如开发一个 App 同时需要产品、研发、设计、市场——单 Agent 的"万金油"策略往往顾此失彼。
行业因此出现了两个方向：一是以 AutoGen、CrewAI 为代表的"任务流水线"——预先定义好角色顺序，线性执行；另一个是以 MetaGPT、ChatDev 为代表的"虚拟软件公司"——多个 Agent 扮演不同角色，通过 SOP 协作。OpenOPC 属于后者，但走得比大多数竞品更远：它不只是一个软件开发公司，而是一个覆盖金融、教育、电商、内容、客服等九大行业的通用 AI 组织框架。
OpenOPC 的核心团队来自香港大学，其技术路线深受微软研究院 AutoGen 和元智能体（MetaGPT）的影响，但在组织持久性和自我进化上有独特设计。
OpenOPC 的运作围绕三个紧密耦合的机制展开，这是理解整个系统的钥匙：
拿到一个目标后，OpenOPC 首先要做的是找到对的人。它内置了"人才市场"（Talent Market），里面预置了九大行业（AI 技术、软件开发、金融投资、销售增长、内容媒体、行业助理、会计财务、品牌电商、教育培训）的岗位模板。每个岗位有明确的技能描述（skill_refs）和角色定位。
当你输入"帮我做一份 VC 投资备忘录"时，OpenOPC 会自动分析任务需求，从人才市场招募：项目经理（PM）负责分解任务并把控质量，行业研究员负责收集数据并撰写报告，财务分析师负责建模和估值，PPT 设计师负责美化输出。这不是固定流水线，而是动态选人——老员工保留上下文记忆，新员工保持全新视角。
团队组建完毕后，真正的挑战才刚刚开始。真实工作中的协作不像流水线那样线性——任务会阻塞、会返工、会涌现新需求、会遇到"这个人不知道那个人在做什么"的沟通断层。
OpenOPC 为此设计了两套机制：
第一：动态协作编排。 每个工作项（Work Item）都有状态机，从「待办」到「执行中」→「待审核」→「返工」→「完成」，每个阶段的转换由 Manager Agent 主导（执行/分派/审核/整合/返工五种模式）。分解任务时，Manager 会画出依赖 DAG（有向无环图），明确谁必须在谁之前完成、谁可以并行推进。当某个角色遇到阻塞（blocker），系统会自动触发升级流程，由 Manager 决定是等待、换人还是拆分任务。
第二：实时可视化。 OpenOPC 提供两套界面来让人类"旁观"这家 AI 公司的运作：看板视图（Kanban Board）展示每个工作项的状态和负责人；动画办公室视图（Office View）则让每个 Agent 化身一个角色出现在虚拟办公室中，实时显示它们在做什么。
光完成任务不够，重要的是越来越聪明。OpenOPC 在每次执行后做两件事：
成果归因。 不是把功劳记给整个"公司"，而是精确追踪每个工作项的结果，识别哪些角色贡献最大、哪些决策导致了返工。这形成了一个组织层级的经验数据库，下次遇到类似任务时，系统会优先选派表现好的 Agent。
轨迹蒸馏。 原始执行轨迹充满噪音（试错、中断、回退），OpenOPC 会提取其中的关键决策点和成功模式，转化为结构化的组织记忆（Organizational Memory）。随着使用时间增长，OpenOPC 对你的业务理解越来越深，输出质量也随之提升。
OpenOPC 的代码库组织得相当规整，整体分为以下几个层次：
| 目录 | 职责 |
|---|---|
opc/engine.py | OPC Engine — 核心编排器，连接各层，协调任务分发与状态管理 |
opc/core/ | 核心业务逻辑：Agent 管理、任务调度、记忆存储 |
opc/channels/ | 多通道集成 — 支持钉钉、飞书、Discord、Email、Matrix、MoChat 等IM平台 |
opc/layer0_interaction/ | 交互层 — Coordinator（协调器）和 Message Bus（消息总线），处理与外部 Agent 的通信 |
opc/database/ | SQLite 持久化存储（aiosqlite 异步） |
opc/plugins/office_ui/ | Web 界面 — 基于 React 的 Office UI，浏览器访问 localhost:8765 |
config/ | YAML 配置：LLM 路由、Agent 选择、公司架构模板 |
.opc/prompts/talent/ | 角色 prompt 模板库，定义各岗位的行为规范 |
skills/core/ | 核心 Skill 系统，Agent 的能力扩展机制 |
关键技术选型：
openai/gpt-5.4，通过 OpenRouter API 路由。配置文件 .opc/config/llm_config.yaml 支持自定义 provider 和 fallback 策略。agent_config.yaml 中配置优先级顺序。provider_base.py 接口。browser_navigate、browser_snapshot 等），支持 MCP（Model Context Protocol）服务器扩展。pydantic-settings）。
uv）# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# 初始化 OpenOPC（填写 API Key）
opc init
# 启动 Web UI
opc ui
# 浏览器打开 http://localhost:8765
# Windows PowerShell
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
opc init --no-external-agent-preflight
opc ui
环境要求： Python >= 3.10，推荐 3.12。Office UI 启动需要 Chromium 浏览器（python -m playwright install chromium）。
| 维度 | 评估 | 说明 |
|---|---|---|
| 容器化 | ❌ 不支持 | 无 Dockerfile 和 docker-compose.yml，无法容器化部署 |
| Web UI | ✅ 支持 | opc ui 一键启动，基于 React 的 Office UI |
| 配置复杂度 | ⭐⭐ 中等 | 需要配置 LLM API Key，但有 init 向导 |
| 外部 Agent 依赖 | ⚠️ 较多 | Claude Code、Codex 等外部 Agent 需单独安装配置 |
| 快速部署 | ⚠️ 部分支持 | CLI/Web UI 可快速本地运行，但不支持一键部署到服务器 |
| 生产环境 | ⚠️ 有门槛 | 缺少 Docker + 持续运行机制，适合开发者本地探索 |
部署结论： quick_deploy = "partially_supported"。Web UI 和 CLI 体验流畅，适合本地快速探索。但缺乏 Docker 支持、没有进程管理/监控机制，不适合直接用于生产环境。团队使用建议配合 tmux/systemd 守护进程。
OpenOPC 的 README 展示了三个官方演示视频，覆盖典型场景：
特别值得注意：OpenOPC 不仅仅服务于软件/AI 领域，它的角色模板覆盖了教育、电商、客服、房产、法律等实体行业，这意味着它的野心是成为一个通用的 AI 组织引擎，而非特定垂直领域的工具。
1. LLM 成本不可忽视。 OpenOPC 的运作依赖大量 LLM 调用——每个 Agent 每次任务都调用 API。在 Self-Run 模式下，任务可能被反复分解、审核、返工，实际 token 消耗可能远超用户预期。对于高频使用的用户，API 费用是需要提前评估的成本项。
2. 外部 Agent 稳定性问题。 OpenOPC 大量依赖 Claude Code、Codex 等外部 CLI Agent。这些工具本身还在快速迭代，版本兼容性和稳定性参差不齐。README 中专门提到遇到问题时先执行 opc agents preflight <agent> 检查环境。
3. 组织记忆的双刃剑。 Self-Grown 的设计很美好，但组织记忆的积累需要时间。初期使用时，OpenOPC 的表现可能不如经过多轮迭代后的"成熟"状态，存在冷启动问题。
4. 多 Agent 协作的不确定性。 当 Agent 数量增加、任务依赖关系变复杂时，协作开销（通信、等待、同步）可能抵消并行收益。部分用户反馈长任务链容易出现"Agent 空转等待"的情况。
适合谁： AI 开发者、研究者，以及希望探索"一个人+AI 团队"工作模式的先锋用户。对于需要跨领域协作的复杂任务（如创业初期做 MVP、市场调研、制作商业计划），OpenOPC 提供了一套完整的组织框架。
不适合谁： 追求简单问答或单任务执行的用户（这类需求直接用 ChatGPT/Cursor 更高效）；需要稳定生产级部署的企业用户（当前版本缺乏容器化和运维支持）。
技术亮点： 分层模块化架构、LiteLLM 统一路由、多 IM 通道集成、Skill + Agent 双层扩展机制，以及独特的"组织记忆"设计——这些让它在众多 Multi-Agent 框架中具有鲜明的辨识度。
如果你对"AI 原生公司"这个概念感兴趣，OpenOPC 值得 clone 下来跑一跑 demo，亲身感受一家 AI 公司的运作方式。
分析时间：2026-09-22 | 数据来源：GitHub API + 仓库源码 | Stars: 1710 | Forks: 318 | License: MIT