OpenOPC深度拆解：自建自营自成长的个人AI原生公司
OpenOPC深度拆解：自建自营自成长的个人AI原生公司
当所有人都在卷单 Agent 的能力上限时，HKUDS 用一个项目回答了另一个问题：怎么让一群 Agent 像一家公司那样持续运转、并在跑的过程中越来越聪明。
OpenOPC 来自香港大学数据智能实验室（HKUDS）。它的 tagline 只有一句话——Build Your Personal AI-Native Company: Self-Built, Self-Run, Self-Grown。这三件事——自建、自营、自成长——不是营销词，而是项目架构的三根支柱，对应三个独立机制：组织配员、动态协作编排、组织记忆沉淀。
理解 OpenOPC 的关键不在它的 UI 多好看，而在它怎么把「多 Agent 系统」从「一群会聊天的 Agent」升级为「一家有组织、有汇报关系、会从项目中学习的公司」。下面把这套架构逐层拆开。
本文提纲
- OpenOPC 想解决什么问题
- 三机制全景图：自建 / 自营 / 自成长
- 自建：把组织架构当成可推导的产物
- 自营：工作项状态机 + 依赖 DAG
- 自成长：归因到角色 + 经验档案 + 共享 playbook
- 两种执行模式：Task 与 Company
- Office UI 设计哲学：Workspace / Office / Org 三页
- 工程实现亮点：文件布局、审批分级、频道矩阵
- 与同类项目的关系：站在哪些肩膀上
- 上手与路线图
OpenOPC 想解决什么问题
多 Agent 协作这件事，市面上的主流方案大多停留在两类：
- 预设工作流编排：人类提前画好 DAG，Agent 按节点跑。问题是一旦遇到没预想到的卡点，整个流程要么卡死要么乱套。
- 自由对话式协作：几个 Agent 丢进同一个 chat，靠消息往来推进。没有职责边界、没有汇报关系、没有对结果的责任归属。
OpenOPC 想做的第三条路是：像一家真公司那样运转。一家公司有组织架构、有岗位、有 KPI、有复盘、有新人入职继承老员工经验——但所有这些不是人类预设的，是从任务目标动态推导出来的。九大垂直领域都被纳入覆盖范围：AI 技术与研究、软件开发、金融投资、销售增长、内容与媒体、行业助理、会计与财务、品牌与电商、教育与培训。
这个定位决定了它的核心张力：既要全自动，又要可控；既要动态协作，又要责任清晰；既要复用经验，又要避免组织记忆被全局污染。三机制就是为了同时平衡这三组张力。
三机制全景图：自建 / 自营 / 自成长
MERMAID_BLOCK_0
三件事形成闭环：自建根据目标搭组织，自营驱动组织执行，自成长把执行结果反哺给组织（更新角色经验和共享手册），让下一次自建时能复用更聪明的员工。下面分别讲。
自建：把组织架构当成可推导的产物
大多数多 Agent 框架里，组织架构是写死的——几个 Agent、各自什么角色，都在配置文件里。OpenOPC 的关键反差是：给定目标，先推导需要哪些角色，再决定每个角色由谁担任。
具体两步：
- 起草组织架构图——从任务需求推导出所需的角色与汇报结构。也就是说，组织架构不是「我先有几个 Agent」决定的，而是「这件事需要哪些岗位」决定的。
- 填补每个角色——由一个招聘 Agent 在「复用现有员工」和「从人才池招募新人」之间做选择。
第二步是真正有意思的地方。OpenOPC 区分两类员工来源：
- 有经验的员工：携带以往项目塑造的经验档案，带着上下文入职。
- 新员工：从人才池招募，提供一张白纸，需要时再学习。
这就意味着组织不是一次性的——它会随项目积累。下次启动新任务时，招聘 Agent 可以复用之前跑过类似项目的老员工，让他们的经验直接进入新任务。这条机制让组织的「集体经验」成为可复利资产。
UI 上对应：Org → Team 编辑角色图谱、Org → Employees 在空缺角色上招募人才、Team Roster → Deploy 把已录用员工变成办公室中可见的 Agent。
自营：工作项状态机 + 依赖 DAG
团队搭好之后，真正的难点是：怎么让一群 Agent 在不确定性下高效协作。OpenOPC 的答案是工作项状态机加依赖 DAG，再加两层阻塞处理。
工作项状态机
每个工作项（work item）有一个当前阶段，阶段决定三件事：
MERMAID_BLOCK_1
这种「状态驱动」的好处是协作不再靠消息互相喊，而是靠状态机驱动：每个工作项在哪一列、谁负责、能不能动，都从阶段显式推导出来。看板与办公室视图实时渲染这一编排过程。
管理者的五种执行模式
管理者（manager）角色负责拆解工作项、分派、评审结果，覆盖五种模式：
| 模式 | 含义 |
|---|---|
| execute | 自己直接执行 |
| delegate | 委派给下级角色 |
| review | 评审下级产出 |
| integrate | 集成多个子项 |
| rework | 返工不合格产出 |
这五种模式不是抽象概念——它们对应状态机的具体阶段转换。delegate 把工作项的所有权转移到下级，review 是下级完成后管理者接管决策，rework 把工作项打回上一阶段。依赖解除与驳回都作为结构化的阶段转换传播，消除了临时的人为协调。
依赖 DAG
拆解定义了一个依赖 DAG：
- 相互独立的工作项并行推进——不会因为一个慢任务拖累整条线。
- 有依赖的工作项等待前置项完成——避免抢跑导致返工。
这条 DAG 是动态可变的：管理者可以在运行中再拆、再合并。和写死的工作流编排相比，这套方案把「流程图」变成了「运行时可演化的图」。
两层阻塞处理
真实任务会卡。OpenOPC 在两个层面处理阻塞：
- 团队内部：一条阻塞消息会暂停发送者，并激活最适合解决该问题的角色。这是组织内的自愈——卡住的角色主动呼叫，知道该找谁的角色被动接管。
- 团队之外：当阻塞超出团队权限（比如需要决策、需要外部资源），运行时上报给人类所有者，在真正需要时引入人类判断。
第二个层面是关键设计：不是所有事都全自动，而是有结构化的人类介入点。max_auto_approve_risk 这个配置项（low/medium/high/critical）决定了 Agent 无需询问就能执行的最高风险等级，把「自动」和「可控」做成可调旋钮。
自成长：归因到角色 + 经验档案 + 共享 playbook
执行完一件事，怎么让组织变聪明？这是大多数多 Agent 系统最薄弱的地方——跑完就完，下次又是从零开始。OpenOPC 用两条原则处理。
把结果归因到正确的角色
把功劳记给整个公司学不到任何东西。这是 OpenOPC 一句关键的判断。
所以它做了两件事：
- 把用户反馈解析为针对每位员工的评估——反馈不是「这公司做得不错」，而是「这个角色在这个工作项上做得如何」。
- 只更新负责了相关工作项的角色——功与过都落到应得之处。
这意味着组织记忆不是一团模糊的「公司知识」，而是每个角色有自己清晰的、和它实际参与的工作项绑定的评估记录。
把执行轨迹提炼为知识
执行轨迹（trajectory）噪声太大，不能直接学。OpenOPC 做两层提炼：
- 私有经验档案：把每个角色的任务提炼为高信号的经验教训，存入它自己的 profile。下次该角色再处理类似任务，可以参考自己的过往经验。
- 共享 playbook：把反复出现的经验从私有档案提升为共享作业手册。新员工从入职起即可继承——这是组织知识随时间复利增长的关键。
MERMAID_BLOCK_2
这条链路让组织记忆有了层级：私有的、个体的经验先沉淀；反复出现的、跨角色的经验才提升为公共手册。这种「先私有后公共」的提炼路径避免了组织记忆被全局污染——一个角色在某次任务里的偶发经验不会无差别扩散到所有人身上。
UI 上对应：自成长发生在每次运行结束后，下次 Org → Employees 招募时，老员工携带的经验档案会出现在候选详情里。
两种执行模式：Task 与 Company
OpenOPC 概念上有两种执行模式，对应两种使用强度。
Task 模式：单 Agent 工作台
类 LobeChat 的单 Agent 工作台，可选用五种执行 Agent：
| Agent | 来源 |
|---|---|
| OpenOPC Native | 内置运行时 |
| Codex | OpenAI codex CLI |
| Claude Code | Anthropic claude CLI |
| Cursor | Cursor agent |
| OpenCode | OpenCode CLI |
Task 模式适合一次性、直接的工作：
uv run opc chat -p demo --mode task --agent codex \
"Refactor this module and run focused tests"
这里的设计取舍很关键：OpenOPC 不重新发明执行引擎，而是允许复用已有的编码 Agent CLI。agent_config.yaml 里配命令名、参数、超时、会话复用、审批行为。这意味着你在 Task 模式下用的 Codex/Claude Code 还是它们自己，OpenOPC 只是提供了一个统一的项目、会话、看板管理层。
Company 模式：多 Agent 公司
uv run opc chat -p demo --mode company --company-profile corporate \
"Plan, implement, review, and document this feature"
一句话简报会变成一个运行时会话加一组由角色负责的工作项。Corporate 是内置架构预设，也可以加载已保存的自定义组织架构。
Company 模式下，角色可以通过配置指定偏好的外部 Agent——也就是说，公司里的某个角色可以用 Codex 跑代码，另一个角色可以用 Claude Code 做评审。这是把「单 Agent 工具选择」提升到「公司级角色分工」的关键一步：执行 Agent 是工人，角色是岗位，组织是工厂。
Office UI 设计哲学：Workspace / Office / Org 三页
OpenOPC 的 UI 不是聊天框加点按钮，而是围绕「公司」这个隐喻设计的三个页面。
| 页面 | 在这里做什么 |
|---|---|
| Workspace | 主工作界面：会话列表、看板、聊天、任务详情、角色进度、通讯、团队驾驶舱 |
| Office | 可视化办公室地图：Agent 以角色形象出现，可选中、移动、分配座位、查看详情 |
| Workspace 右侧面板 | Chat、Agents、Info、Comms、Team 五个页签 |
Chat 页签展示父级对话、运行时进度卡片、检查点回复；Agents 页签展示角色汇总（活动/等待/待定/完成），可以看到每个角色当前在用什么工具、负责哪个工作项；Comms 是角色收件箱——会展示未读/已读/已发消息、会议、决策与最近的通讯故障；Team 是运行时驾驶舱，能看审批、未读通讯、恢复状态、停止控件。
这套设计的核心隐喻是：你不该用「监视 Agent 日志」的方式监督一个公司。你应该用「查看组织状态、查看团队进度、查看成员通讯」的方式监督它。UI 的每一个区域都对应公司里一个真实存在的观察点。
办公室页面的「像素动画」值得专门说一句——它来自 OpenOPC 致谢的 pixel-agents-hq/pixel-agents，把每个 Agent 显示为有状态、有当前任务、有正在使用的工具的角色形象。这不只是装饰，而是让「谁在干什么」这件事变得一眼可见。多 Agent 系统最大的认知负担就是「现在到底谁在干什么」，可视化的回报远超成本。
工程实现亮点：文件布局、审批分级、频道矩阵
文件布局：运行时状态与交付物分离
OpenOPC 把运行时/配置状态与交付物工作区文件分开存放：
| 路径 | 含义 |
|---|---|
.opc/config/ |
由 opc init 从 config/ 复制而来的本地配置 |
.opc/memory/ |
全局与项目级 Markdown 记忆 |
.opc/projects/<project>/ |
项目运行时元数据与任务存储 |
.opc/ui_state.db |
Office UI 的聊天、频道与可视化 Agent 状态 |
../OpenOPC_workplace/<project>/ |
默认项目工作区，Agent 把持久的项目文件写到这里 |
../OpenOPC_workplace/<project>/.opc-comms/ |
Company 模式内部通讯信箱、会议与工具结果暂存区 |
这条分离的价值是：Agent 写出的代码、文档、交付物和它自己的运行时状态完全分开。如果你要 commit 交付物到 git，不会把 .opc/ 的运行时状态污染进来；反之要重置运行时状态，也不会动到交付物。OPC_HOME 环境变量可以把 .opc/ 整个挪到仓库之外。
审批分级：风险等级 + 工具首次使用提示
.opc/config/system_config.yaml 的 autonomy 部分控制 Agent 无需询问就能执行多少操作。核心旋钮是 max_auto_approve_risk：
autonomy:
max_auto_approve_risk: medium # low | medium | high | critical
allow_native_tool_auto_approval: true
tool_first_use_approval: true # 每个工具首次使用时总是询问
每次原生工具调用在运行前都会做风险分级：
- 已知的破坏性命令（
rm -rf、drop table、force-push）和敏感关键词（凭据、部署）为high/critical，总是上报给人类。 - 白名单中的安全前缀（
ls、git status等）为low。 - 其余为
medium，在自动批准前会经过 LLM 审查。
四个档位对应四种使用场景：
medium（默认）：平衡——普通命令无提示，危险命令上报。low：严格——不在白名单的任何操作都要审批。推荐用于共享或生产机器。high/critical：宽松——仅用于可随时丢弃的沙箱。
每个工具首次使用时总会提示（除非在 tool_approval_exemptions 中），用户的「始终允许」选择会累积到项目级白名单。这套机制的设计哲学是：不是「全自动 vs 全人工」的二选一，而是「按风险分级 + 按工具学习」的可演化授权。
外部 Agent 集成：把已有工具当工人用
Task 模式可以显式选择执行 Agent：
opc chat -p demo --mode task --agent codex "Implement the change"
在 Company 模式下，角色可以通过角色配置或 Org 角色检查器指定偏好的外部 Agent。角色的执行策略可以是 auto、native 或 external，并可选地指定偏好的外部 Agent。
这是 OpenOPC 一个非常重要的取舍：它不试图取代 Codex / Claude Code / Cursor 这些已有的编码 Agent，而是把它们当作执行工人——OpenOPC 自己负责组织、委派、评审、记忆，让这些工具在公司结构里干活。
频道矩阵：把公司接入通讯工具
OpenOPC 支持把它的运行时接入外部通讯频道：
| 提供方 | 安装 extra | 运行方式 | 必填字段 |
|---|---|---|---|
| 飞书 | channels-feishu |
WebSocket | app_id、app_secret |
| TG | channels-TG |
polling | token |
| Slack | channels-slack |
socket | bot_token、app_token |
| Discord | channels-discord |
socket | token |
| 钉钉 | channels-dingtalk |
socket | client_id、client_secret |
| 邮件 | channels-email |
polling | IMAP/SMTP 字段 |
| Matrix | channels-matrix |
sync/polling | homeserver、access_token |
channels-qq |
socket | app_id、secret |
|
channels-whatsapp |
bridge | bridge_url |
|
| Mochat | channels-mochat |
bridge | base_url、claw_token |
关键设计：入站发送者列表默认拒绝。空 allow_from 会拒绝所有入站消息——这是安全默认值，不是 bug。每个提供方装好后用 opc channels start -p demo 启动，或用 opc run -p demo 跑常驻引擎加频道运行时。
浏览器工具：原生 Playwright
原生浏览器工具基于 Playwright，包括 browser_navigate、browser_snapshot、browser_click、browser_type、browser_wait_for、browser_scroll、browser_select_option、browser_evaluate、browser_take_screenshot、browser_close。在 system_config.yaml 中可配 embedded / chrome / auto 三种模式。
MCP 服务器可添加到 system_config.yaml 的 mcp_servers 下。本地服务器用 stdio 命令；远程服务器用 HTTP/SSE 风格 URL。发现的工具以服务器前缀注册，避免命名冲突——这是一个工程上很务实的细节，避免不同 MCP 服务器暴露同名工具时打架。
与同类项目的关系：站在哪些肩膀上
OpenOPC 的致谢章节值得专门看一眼，因为它说明了这个项目站在哪条脉络上：
- openai/codex：启发了实用的编码 Agent 工作流与执行模式。这就是 Task 模式外部 Agent 集成的源头。
- BloopAI/vibe-kanban：启发了以看板为中心的 Agent 工作管理与任务可见性。这是 Workspace 看板视图的灵感来源。
- msitarzewski/agency-agents：提供了人才模板的基础。OpenOPC 仓库内所有人才模板都导入自此。这就是「招聘 Agent 从人才池招募新人」那条机制实现的基础。
- HKUDS/nanobot：启发了面向技能的 Agent 设计与
SKILL.md风格的组织方式。这是 OpenOPC 同实验室前作，技能结构由此而来。 - pixel-agents-hq/pixel-agents：启发了以像素动画办公室可视化 Agent 活动的方式。这是 Office 视图的来源。
这条脉络说明了 OpenOPC 的定位：不是重新发明每个组件，而是把已有最佳实践组装成一个完整的「公司」抽象——执行引擎来自 Codex/Claude Code、任务可视化来自 vibe-kanban、人才模板来自 agency-agents、技能结构来自自家 nanobot、可视化来自 pixel-agents。OpenOPC 的贡献是把它们组织成「自建-自营-自成长」的闭环。
上手与路线图
5 分钟上手
推荐用 uv 安装（Python >=3.10，示例用 3.12）：
# macOS
brew install uv
cd /path/to/OpenOPC
uv python install 3.12
uv venv --python 3.12
source .venv/bin/activate
# 装项目、装浏览器、初始化、起 UI
uv pip install -e .
uv run python -m playwright install chromium
uv run opc init
# 编辑 .opc/config/llm_config.yaml 填 API key
uv run opc ui
默认打开 http://localhost:8765。三条命令覆盖三种使用方式：
# 交互式 CLI
uv run opc chat -p demo
# 一次性 Task 模式
uv run opc chat -p demo --mode task --agent codex \
"Refactor this module and run focused tests"
# Company 模式
uv run opc chat -p demo --mode company --company-profile corporate \
"Plan, implement, review, and document this feature"
# 非交互脚本 / CI 风格
uv run opc exec -p demo --mode task --agent native --json \
"Summarize the current repo status"
opc exec 配 --json 让 OpenOPC 可以塞进 CI/CD——这是把多 Agent 公司接入自动化管道的入口。
路线图：现在的缺口在哪
OpenOPC 自己在路线图里很坦白地列了当前的开发重点，每项都对应早期使用中发现的真实缺口：
| 领域 | 计划方向 |
|---|---|
| 角色级技能 | 当前 skill_refs 已支持，Org UI 展示元数据；下一步让用户在 Org 页面直接选哪些技能挂载到哪些角色 |
| 秘书设置 | 让秘书成为更强的配置与记忆管家：负责 OPC 系统记忆、分析与对比项目、引导式 YAML 配置 |
| Company 模式频道 | 让外部频道从简单聊天入口升级为更丰富的 Company 模式工作流——角色感知通知、结构化审批、跨平台协作 |
| CLI 对齐 | CLI 当前可用，但 Office UI 仍是更完整的界面；后续让 CLI 也能做组织编辑、Company 模式检查、故障恢复 |
| TUI | CLI 对齐成熟后再考虑完整终端 UI；在此期间 Office UI 仍是主界面 |
| 市场与预设 | 更多架构预设、可招募的人才包、导入导出工作流、社区组件市场 |
| 运行时打磨 | 持续改进恢复、检查点、执行进度可见性、可视化文档 |
最新的迭代节奏（截至 2026 年 7 月）聚焦在韧性——Company 模式会话恢复更顺畅、Office UI 实时更新更快、审批机制更智能（会话授权持久化、低风险动作自动通过、延迟决策可用）。这说明项目正在从「能跑」走向「长时间稳定跑」——这正是多 Agent 系统从 demo 走向生产的关键一跃。
一个判断：OpenOPC 真正的差异化在哪
读完整个项目，OpenOPC 真正的差异化不在 UI，也不在外部 Agent 集成，而在它对「组织」这个抽象的处理方式。
市面上的多 Agent 框架大多把 Agent 当原子——几个 Agent、什么角色、怎么协作，都从配置文件读。OpenOPC 把组织当成一等公民：组织架构是从目标推导的、员工是可以复用或招募的、工作项是带状态机和依赖关系的、结果是归因到具体角色的、经验是私有先沉淀再提升为共享的。
这种处理方式的代价是复杂度——它远比「N 个 Agent 进一个 chat」复杂。但回报也是相对应的：它让多 Agent 系统第一次具备了「组织级学习能力」。一个角色在某次项目里学到的经验，会沉淀在它的私有档案里；反复出现的经验会进入共享 playbook，被新员工继承。这意味着组织不只是「这次跑得快」，而是「下一次跑得更快」。
这条路径的终点不是「更强的 Agent」，而是「一家会成长的公司」。在一个所有人都忙着卷单 Agent 能力的时代，OpenOPC 选了一条更难但可能更有长期价值的路。
作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
浙公网安备 33010602011771号