2026-09-24 补测：文章发布后，我用真实模型把这套框架的完整公司流程跑了一遍——招募、编制、执行、终交付卡全程，以及四个卡点，见第五节。
多 Agent 框架的通病是演示能跑、长跑就散：聊到第三轮丢上下文，进程一停就恢复不了，最后一个「全自动团队」退化成几个必须有人盯着的对话框。港大数据智能实验室（HKUDS）7 月 1 日开源的 OpenOPC 换了个问法——不是「怎么让 Agent 互相发消息」，而是「怎么把 Agent 当员工管起来」：先招人建组织（Self-Built），再派活跑流程（Self-Run），最后复盘沉淀（Self-Grown）。84 天拿到 1,714 星、319 个 fork，中文圈已经有几篇通稿在转，但都停在 README 的翻译层面。
我把它整包拉下来，跑通了初始化、34 个 CLI 子命令和那个像素办公室 UI，量了它的数据库、测试和人才池，复现了一条 9 月 22 日刚上报的恢复崩溃；后来又借到一个真实模型的 key，把它整套公司流程完整跑了一遍。结论先给：它的组织学是真材实料，员工学是借来的，而它现在最要命的地方是「跑完之后的恢复」。
一、它把「公司」做成了什么东西
README 讲的是三个词（自建、自跑、自长），但打开代码，真正被反复推敲的是另一个东西：一条工作项（WorkItem）的状态机。它把「谁在什么时候能干什么」全部压进一个 Phase 枚举——14 个状态、4 个看板列、50 条合法转移，而且看板列、当前负责人、能不能跑、裁决结果全部由 phase 用纯函数推出来，不再各处各写一套判断。
源码注释把动机交代得很直白：这个 Phase 替换掉了旧版「status 加 5 个 metadata 子状态」（activation_state、lifecycle_state、review_state、manager_release_state、review_execution_state）互相打架的写法，改成「一个枚举值对应一种具体处境，转移表在每次写入时强制校验」。跨层同步（task 状态、角色会话状态、调度器唤醒）则交给 phase 转移钩子，注释里还写清了它的边界：钩子只做「尽力收敛」，不做事务一致，工作项写入才是唯一真源。
这套东西落到磁盘上就是那张数据库：我建了个空库跑起来，50 张表、70 个索引、590 个字段（空库 736 KiB）。表名基本是组织学的词汇：delegation_runs、delegation_work_items、role_runtime_sessions、seat_states、work_item_decisions、approval_records、execution_checkpoints、reorg_proposals、runtime_permission_grants。它还有自己的通信层：角色之间不是直接调函数，而是往文件式工作区 .opc-comms/ 里写收件箱、会议记录和共享记忆，好处是可审计、可重放、阻塞时能被唤醒。
另外两个细节值得记一笔。一是「员工从哪来」：5 个外部 agent 适配器（Claude Code、Cursor、Codex、OpenCode、JiuwenSwarm），但你跑 opc agents list 会发现表格里分了两栏——只有 JiuwenSwarm 的两种形态既支持 Task 又支持 Company，其余四个在 Company 栏是 no。也就是说所谓「公司」目前基本跑在它自己的原生运行时上。二是自演化：每个员工跑完活会往 employee_evolution.json 里落经验和评审偏好，同一个模式被记到第 2 次就蒸馏成可复用的 skill（LEARNED_SKILL_THRESHOLD = 2）。
它自己的路线图也把债摊开写了：7 条优先级里，第一条是「角色级技能还不能在界面上选」，最后一条是「运行时打磨：恢复、检查点、执行进度可视化」，另外还自认「CLI 不如 Office UI 完整，终端侧的编辑与检查是后续工作」。一个愿意在 README 里承认「CLI parity 还没做到」的项目，通常比通稿里的它更可信。
它还把「公司治理」直接做成了命令行：AI 自己觉得组织架构该调整，得走 opc propose-reorg 提交一个带理由和变更集的提案，等人 approve-reorg 才生效；自主度是分档的（我这边看到的是 bounded 模式，风险不超过 medium 才自动放行，置信度阈值 0.7）；整个组织可以打包成 .opcpkg 导出、安装、卸载。这套「AI 提案、人批」的写法，比大多数 Agent 框架里那句「human-in-the-loop」要具体。
二、我实测到的东西
下面这张表是这次动手的产出，方法和数字都可以复现。
| 我测的 | 方法 | 结果 |
|---|---|---|
| 装起来 | opc init |
一次通过：载入 11 个角色、预检 6 个外部 agent（本机 0 命中）、生成 config/memory/skills/agent_homes 目录树 |
| 界面 | opc ui |
起得来，200，「OpenOPC Pixel Office」；Phaser 3.90 跑 1.2 MB + 主包 1.37 MB + 6 套角色精灵 + 7 套配色 + 中英双语 |
| 安全闸门 | 在未信任仓库里跑 CLI | 先 fail closed 提示 opc trust add；信任后放行；再往 .opc/config 里多放一个文件，立刻又被拦（提示「信任后配置权威已变更」） |
| 代码形状 | 逐文件统计 | 243 个文件 204,663 行；store.py 单文件 32,354 行（1.41 MB）、engine.py 21,295 行、company_mode.py 20,376 行，三个文件占全仓 Python 的 21% |
| 测试体量 | pytest 全量跑 | 156 个测试文件 130,761 行，是库代码的 64%；3,059 个用例跑完用了 45 分 04 秒：3,033 通过 / 8 失败 / 18 跳过 |
| 失败归因 | 逐条复跑 | 4 条是本机环境（缺 websockets、沙盒文件系统不支持硬链接）、1 条重跑就过、2 条是仓库自己的不变量 lint 红了、1 条我没能归因到环境 |
| CI 覆盖率 | 读 workflow | 官方 CI 只跑 6 个文件、30 个用例，占全部 3,059 个的 1.0% |
| 一条崩溃 | 直接调它的函数 | 复现 9/22 上报的恢复失败：12 个合法 turn type 里没有 verify，canonical_work_item_turn_type_for_kind("verify") 返回的是 execute |
| 数据库膨胀 | 用它的引擎量 | 每个任务都存一份完整组织拓扑：3 角色 20.3 KB、11 角色 74.5 KB、21 角色 157.8 KB |
| 一条上游报告 | 按声明版本复跑 | 复现不出来：报告说远程 MCP 必挂，我用它在 pyproject 里声明的 mcp 1.30.0 直连公共 DeepWiki MCP，握手成功 |
| 端到端公司运行 | 真实模型跑满全流程 | 3 角色组织跑通「招募 → 编制 → 执行 → 终交付卡」，产物落盘 929 字节简报 + 25 个协作 md，花费见第五节 |
那 8 条失败里最值得看的是两条「仓库自己的 lint 红了」。第一条叫「状态单一真源」的不变量测试：它扫源码，禁止有人绕过 phase 通道直接改任务状态（原话是「会造成跨层状态不同步」），我跑的时候它报出 company_mode.py:10886 直接写 .status = TaskStatus.CANCELLED、10905 直接写 .status = TaskStatus.FAILED——而它自己的白名单注释里写着「company_mode.py 已不再直接写这两个状态，9 处写入全部改走 transition_work_item」。更巧的是，这两行代码正好落在 9 月 11 日那笔「评审反馈完整性」修复新增的路径上（评审员没给理由就驳回 → 自动重试两次 → 重试耗尽把评审卡置为失败）。也就是说：它三周前为了修「驳回理由丢失导致 worker 空转」而新写的分支，恰好踩回了它自己用 lint 看守的那条老病根，而这条 lint 不在 CI 的 30 个用例里，所以没人拦得住。另一条红的 lint 是测试夹具命名的守卫，它在自己的一个测试文件里抓到一处违规。这两条都不是沙盒问题，任何人在任何机器上 clone 下来跑都会看到。
那张安全闸门的表值得单独说，因为它是这个仓库里最容易被人忽略、却最说明工程成熟度的一处。上游 8 月 11 日收到过一个安全报告：OpenOPC 默认加载项目目录里的 .opc/config，而这份配置可以指定 MCP 启动命令、远程 MCP 地址、LLM 的 api_base 和 api_key_env——也就是说，你 clone 一个别人的仓库、在里面敲一条 opc chat，就等于让对方仓库里的文件决定「跑什么进程」和「把你的 key 发到哪个地址」。报告给复现、给受影响 commit、指出仓库当时连 SECURITY 政策都没有。8 月 26 日修复落地，并且我这次实测到的行为是这样的：先拦住、要求你 review 后手动 opc trust add，信任记录绑的是配置指纹，我只要再改一次配置就立刻重新拦截。这条链路是我这次评测里质量最高的部分。
三、186 个「AI 员工」是怎么来的
README 里最抓人的是人才池：186 个岗位模板，涵盖工程、设计、营销、金融、游戏。我数了一遍，并且和它的上游做了逐路径比对。
| 人才池构成 | 数量 |
|---|---|
| 仓库里的岗位 md 文件 | 197 |
| 带 YAML 头的真模板 | 186 |
与 msitarzewski/agency-agents 路径一一对应 |
165 |
| 上游嵌套目录被拍平或改名 | 20 |
| 仓库真正自建 | 1（general-default-employee.md） |
| 上游现有模板 / 本地缺失 | 321 / 缺 156 |
| 抽样 7 个做内容比对 | 4 个逐字节相同，3 个只差 1–10 字节 |
agency-agents 是一个 154,385 星的人才模板库，OpenOPC 的致谢里也如实写了「本仓库包含的所有人才模板均导入自 agency-agents」。我抽样的差异长这样：把上游的 ## Identity & Role Definition 改成 ## Role Definition，或者补一个文件末尾的换行——几乎没有实质改写。剩下 11 个不带模板头的文件里，10 个是上游 examples/、strategy/ 目录的说明文档被一起拍平放了进来，还有一个是 Pull Request 模板。
这不是「抄」，MIT 协议下导入并且署名，合规。但读者需要知道的是：它卖给你的员工，和你在别的项目里随手能拿到的员工是同一批；而因为导入时间停在 7 月，上游的模板如今已经涨到 321 个，本地缺了 156 个。真正属于它自己的，是上面第一章那套状态机——那是别人没有、也没法直接拿的。这一点在我第五节的实跑里被验证得更清楚：自动招募挑出来的两个「员工」，正是那两个模板。
四、现在的它，卡在哪
9 月 22 日，两位用户在同一个项目上提了三条崩溃报告，全部开放、全部零回复，而仓库最后一条提交停在 9 月 11 日：
- 原生工作项在 LLM 流式调用卡住时会永久挂起，调度器每 5 秒打印一次「claim skip」，可以空转 23 分钟直到有人手动杀进程；
- 一旦你为此杀了进程，
delegation_runs里会留下一个没释放的租约，之后每一条恢复路径（opc exec --resume、UI 的会话恢复）都会撞上「live company runtime Task requires an explicit run or attempt fence」这道为「保护活任务」而设的闸门——报告作者的原话是「这道闸门在进程死掉之后保护的是尸体」；
- 自定义组织里「经理把活派给下属」这种最常见的结构，恢复时直接抛「WorkItem identity changed before commit」。
我复现的是第 3 条的近亲：verify 是这套系统里的一等公民（company_mode.py 里出现 11 次，qa_ready 门、依赖检查、投影 id 都在用），但它不在规范 turn type 集合里，于是所有「按 kind 映射 turn type」的通用助手都会把它悄悄降级成 execute，下游 guard 拿一个错的默认值去比对真实业务类型，于是「本来没问题的恢复」每次都失败。这不是玄学，是集合里少了一个字符串。
还有一处容易被忽略的不对称：整个 docs/ 里唯一的中文文档是那份 JiuwenSwarm 接入说明（10.7 KB），其余文档全是英文。JiuwenSwarm 是国产的自组织蜂群框架，也就是说「把外部 Agent 接进公司模式」这条路径，目前是为中文用户准备的——而它也确实是唯一能进 Company 模式的外部执行体。
把 issue 和 PR 一起算，有 28 个外部账号在这个项目里留过东西，其中 15 人提过 PR——社区是活的。但另一边，30 条 issue 里有 11 条至今零评论，8 条还开着的报告一条回复都没有。对一个 84 天的新项目来说，这是「用户比维护者跑得快」的典型形状。
生态那边的信号也一致：33 个 PR 里合并了 13 个，其余长期挂着——包括 8 月 27 日就提出来、直接修「最终交付后会话永久卡死」的 #53；一位贡献者的 Shadow Mode（把真人承包商当员工接进流水线）PR 被关掉后，他干脆自己开源成独立包 OpenOPC-Shadow-Adapter，20 天不到 120 星，卖点是「一台机器同时打多份工」。
五、真跑一遍：招募、编制、执行都成了，卡点在后半段
光看代码不够，我借了一个真实模型（xiaomi/mimo-v2.6-flash，走 CommandCode 的 OpenAI 兼容端点），在仓库自带的 3 角色组织 research-report-studio 上把它跑了一遍：首席分析师 → 研究员 → 报告产出。
前半段跑通了，而且是真跑通：staffing 检查点 → 自动招募 → 确认编制 → 执行 → 交付。首席分析师读了任务、写了产物，brief.md 落在工作区（929 字节，含三条可执行建议，内容是能看的）；.opc-comms/ 下生成了 25 个协作文件（给 owner 的 4 封信、团队记忆、草稿板）。自动招募挑出来的两个员工，就是第三章里那两个借来的模板：研究员用了 Codebase Onboarding Engineer，报告产出用了 Technical Writer。整场 20 次模型调用，输入 239,882 token、输出 12,838 token，主执行回合 7 分 48 秒；按这个模型费率折算大约 0.04 美元。顺带一句：cost_records 里记的成本全是 0.0，因为 litellm 不认识这个端点的定价。
后半段每一步都撞墙，而且四个卡点全部可复现、全部不是我的环境问题：
- 无头模式会卡死在工具审批提示上。默认自主度是「medium 以下自动放行」，但「读取工作区之外的路径」被单独判为需要人点，提示打到标准输出等人输入；后台跑没有交互终端，于是永久阻塞——数据库里三条
tool_permission检查点至今还是 pending 状态。加--approval-level full-access可以绕过。
- 为解卡杀掉进程，留下僵尸租约：
delegation_runs那行保持status=running、lifecycle_status=active、controller_lease_generation=5，对应工作项永远停在running。这正是第四章里那三条报告描述的现场。
- 带审批级别的恢复直接崩，报错与上游报告逐字一致：
CompanyRunControllerLeaseLost: live company runtime Task requires an explicit run or attempt fence，位置在「给运行中的公司任务持久化原生权限配置」那一步；把--approval-level去掉，同一条恢复命令就正常返回。也就是说这道为防误写而设的闸门，卡住的恰好是恢复路径自己。
- 终交付确认这张卡，命令行答不了。我用自然语言回复「我完全同意这次交付」、又试了「approve」，都不消费这张卡：每回一次就新生成一个交付工作项，旧卡变成
superseded，运行再次停回awaiting_owner。CLI 里唯一的检查点提交命令只服务组织改组（approve-reorg），通用卡片没有入口——也就是说，完整闭环目前只能在那个像素办公室界面里点出来。
对照组在这里最有意思：维护者自己 9 月 11 日的实跑记录里写着，「尚未实跑所有 company profile 的规划、编制、并行派工、owner 审批、返工、崩溃接管与最终交付完整生命周期」，并且注明那一轮的三次实跑没有启动正式的公司调度器。我这次启动了；结果是前半段（规划、编制、执行）确实能用，后半段（审批、返工、崩溃接管）三段各撞一个真实缺陷。
还有两条附带观察。一是 3 角色组织里，被录用的研究员和报告产出一个工作项都没拿到——首席分析师在自己的首个回合里把活干完了，和上游报告里那个「CEO 自己干、不派给下属」的 corporate 形状一模一样，也就是说多角色的编制在真实运行里未必真的分出去。二是一次公司运行会改写 .opc/config，从而让工作区信任指纹失效，下一条命令行必须先重新 opc trust add 才能执行——这是第二章那条安全加固的副作用，安全上没错，但对无头自动化是个持续的绊脚石。
六、判断和边界
值得学的：状态机单一真源、跨层钩子写清一致性边界、fail-closed 的工作区信任、把内部审计文档（docs/ 里 6 份带日期的审计与迁移记录，最长 37 KB，逐条对比姊妹项目 Talen 的正确性修复并注明血缘）直接放在公开仓库里。测试写了 13 万行，这个比例在同类项目里少见。
要打折的：它是「AI 公司」的骨架，不是劳动力。员工模板是借的且已经落后上游两个多月；外部 agent 里只有 Jiuwen 能进 Company 模式（而 JiuwenSwarm 的 0.2.4b4 根本不在 PyPI 上，安装要靠一个 GitHub 固定 commit 加一份 --overrides 把依赖顶到 gitcode 上的另一个仓库）；3,059 个测试只有 30 个进了 CI；README 里那张「七层架构」的表被 HTML 注释包住了，浏览器里根本看不到，中文版连这段注释都没有。
谁该用：想研究「多智能体怎么管起来」的人，这个仓库值得逐文件读，它的债务和设计都写在明处。想在生产里跑「全自动公司」的人先别——我这次跑下来，前半段能用、后半段全是恢复问题，而恢复恰恰是自动化最不能缺的能力。当「带审批和完整审计轨迹的单 Agent 工作台」用（Task 模式），风险小得多。
局限说明：端到端这次是用真实模型跑的（组织是 3 角色的自定义预设，模型是 MiMo V2.6 Flash），但「返工、审批、崩溃接管」三段各撞一个缺陷，完整闭环没能收口；那 8 条测试失败逐条复跑归因如上，没归因清楚的 1 条我照实写出来，不作为项目缺陷计入。Playwright 浏览器工具与 chromadb 在 aarch64 musl 上没有预编译包，我按缺失处理。
同类项目此前评测过的：把多个 AI 组队成开发团队的 oh-my-openagent 走的是「角色技能包 + 命令行编排」，GreatCTO 押的是「69 个岗位一次买齐」，ECC 卷的是「工程纪律」。OpenOPC 是这四家里唯一把「恢复」当第一性问题做的，也是目前唯一还没把恢复做成的。