TL;DR：Open Executive 是 Sente Labs 开发、采用 Apache-2.0 许可的真实开源项目：当前 README 描述一个统一 Executive 编排 8 个专业智能体，并使用 ChromaDB 检索、SQLite 情景记忆和单实例调度器；截至 2026 年 9 月 4 日，仓库约有 3,614 stars、47 次提交，最近一次推送在 9 月 2 日。网上流传的“公司用 AI 裁掉开发团队，被裁者报复造出 AI CEO”没有公司名、当事人身份或项目方确认，项目自己的材料也没有这段起源，不能当成已证实事实。它目前更接近可自托管的高管顾问与工作流系统，不是能独立拥有公司授权、承担责任或替代真实 CEO 的法律主体。
这个故事太适合传播了：基层被要求用 AI 提效，甚至因 AI 被裁；开发者反手把同一套自动化逻辑指向高管层。
但项目是真的，不代表复仇故事也是真的。把两者分开之后，Open Executive 仍然值得看——它把战略、财务、人力、法务、运营、营销、产品和董事会沟通放进一个多智能体系统，具体展示了哪些“高管工作”已经可以被软件重新组织。
🎬 视频版（B站） ｜ 🎧 音频版（7 分 19 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇
先把复仇爽文和开源项目分开
Reddit 原帖称，发帖者的一些朋友在一次“AI Transformation”中被解雇，于是共同开发 Open Executive，用来替代 CEO 和其他高管。帖子没有给出雇主名称、被裁开发者身份、劳动记录或项目成员声明。
随后 HN 和多家二次报道沿用了这个标题。到 9 月 2 日，TechRadar 的报道也明确承认：雇主和 CEO 没有被点名，Open Executive 自己的公开材料并没有把项目描述成对某次裁员的报复。
Sente Labs 官网则直接把 Open Executive 列为公司开发的开源产品，并提供“预约工作会议”的服务入口。公司定位是帮助组织研发和部署多智能体系统。
这些证据支持三个不同结论：
- Open Executive 项目真实存在；
- “朋友被 AI 裁掉”的说法真实出现在 Reddit；
- 两者之间的因果关系尚未得到可核验材料支持。
把这段起源理解为社区转述或营销叙事更稳妥。它也可能最终被当事人证实，但在证据出现之前，不能写成新闻事实。
《听懂 AI》第 023 期节目封面。节目先讨论复仇故事为何流行，本文进一步核对仓库当前代码、项目方定位和起源证据。
Open Executive 当前到底是什么
项目 README 把它描述为“虚拟高管团队”：用户只和一个统一的 Executive 交流，内部编排器根据问题调用相关专家，再把多份分析合成为一份口径一致的回答。
当前默认的 8 个专家角色是：
- Chief Strategy Officer：竞争、并购、市场定位和目标；
- Chief Financial Officer：财务模型、融资、单位经济和现金流；
- Chief HR/People Officer：招聘、薪酬、绩效和文化；
- General Counsel：合同、知识产权、雇佣法基础和合规；
- Chief Operating Officer：流程、供应商和运营扩张；
- Chief Marketing Officer：市场进入、品牌、传播和公关；
- Chief Product Officer：路线图、优先级和产品战略；
- Board Communications Director：董事会材料、投资者关系和治理沟通。
系统不是每次固定让 8 个角色全部回答。编排器按问题选择相关专家，允许并行调用，再统一合成。项目当前默认 claude-sonnet-4-6 负责 Executive 和多数专家，战略、财务、法务及董事会等深度推理角色可使用 claude-opus-4-7。
八个专家为什么还要对外只说一种声音
真实高管会议常出现多个立场：财务关心现金，产品关心用户，法务关心责任，市场关心窗口。如果把 8 段模型输出直接堆给用户，得到的可能是相互矛盾的清单。
Open Executive 增加统一编排器，让它决定咨询谁、如何处理冲突、哪些内容进入最终回复。用户看到的是一个 Executive 人格，而不是内部的多智能体记录。
图中结构依据 2026 年 9 月 4 日的 README 与 main 分支整理。它说明软件如何组织信息，不证明建议质量等同于真实高管团队。
这种设计能减少重复和口径冲突，也会把权力集中到编排器的系统提示、路由规则和合成方式。谁定义目标、什么指标优先、哪些风险必须上报，都会影响最终建议。
“一个统一声音”不等于客观共识。它只是把内部差异隐藏在最终回复之前。
它如何使用公司资料，而不是每次凭空回答
项目为每个专家提供两层检索资料。第一层是仓库内置的商业管理 Markdown，在启动时写入 ChromaDB；第二层是用户上传的公司文档，切分后存进独立的 company_docs 集合。
README 把内置资料称为“MBA-level”甚至“Harvard MBA-level knowledge”。这是项目方的产品定位，不是哈佛商学院认证，也没有公开独立评测证明它达到某种 MBA 水平。
检索内容会放进用户轮次，而不是动态写入缓存系统提示。这样有利于提示缓存稳定，也让公司背景能够随每个问题变化。
但数据边界必须看部署方式。默认使用 Anthropic API 时，模型调用仍会把相关上下文发送给服务提供商；“自托管”主要表示应用、数据库和向量库由自己运行，不自动等于所有推理都离线。
当前 main 分支已经支持 OpenRouter 和 OpenAI-compatible 本地服务，可将部分或全部角色路由到 Ollama、LM Studio、vLLM 或 llama.cpp。README 同时提醒，本地模型没有 Anthropic 的服务端搜索、提示缓存和扩展思考等同等能力，较小模型的工具路由质量也可能下降。
情景记忆让它记住“上个月说过什么”
每次回复后，后台会用较轻量的 claude-haiku-4-5 提取关键决策、项目和建议，写入 SQLite。下次会话开始时，相关历史以 <past_decisions> 区块加入上下文。
这解决了普通聊天机器人每次从零开始的问题，也带来新的治理要求。模型提取的“决策”可能遗漏条件、把建议误记成批准，或让已经撤销的计划长期影响后续回答。
因此，情景记忆需要来源、时间、批准状态、修改记录和删除机制。真正的公司决策库不能只保存模型总结，还要能回到原始会议、文件和责任人。
调度器可以主动提醒，但当前有单实例限制
Open Executive 不只回答问题。内置调度器会认领到期事项，主动触发跟进和提醒。数据库使用 UPDATE … RETURNING 防止同一进程重复领取任务。
README 明确警告，API 目前必须按单实例运行；在没有给调度器增加额外协调机制前，不能直接水平扩容。多个进程可能重复触发提醒。
这条工程限制很有代表性。把聊天机器人变成主动管理系统以后，难点不只是生成一段好文字，还包括幂等、权限、重复发送、失败重试、审计和撤销。
项目最新架构已经加入多种消息集成、审计记录、访问控制和站外发送的确定性防刷屏机制。它仍在快速开发：仓库创建于 6 月 11 日，0.1.0 在 6 月 30 日发布，9 月 2 日仍有代码推送。
最高 85% 缓存命中率也是项目方声明
README 称，系统提示被拆分成 Executive 人格、公司资料和知识索引等稳定块，经过前几轮对话后，提示缓存命中率最高可达约 85%。
“最高”不等于所有部署的平均值。实际缓存率取决于会话长度、公司资料是否频繁变化、专家路由、模型和提供商支持。项目没有在 README 中提供完整测试样本、分布或成本对照。
正确表述应是“项目声称最高约 85%”，而不是“使用它一定节省 85% 成本”。缓存命中还只影响输入处理的一部分，不代表总延迟或总费用同比下降同样比例。
它能自动化哪些高管工作
信息密集、结构清楚、可复核的工作最适合交给这类系统：整理竞争资料、比较预算情景、准备董事会初稿、追踪既有决定、汇总跨部门风险、提醒到期事项。
这类工作在现实组织里常由高管、幕僚、分析师和运营人员共同完成。多智能体系统可以降低第一版材料和信息协调的成本，让小团队获得过去只有大公司才有的分析界面。
项目还支持 Web、命令行、Slack、邮件、Telegram、Google Chat 和 Discord 等入口。它不再只是一个网页问答 demo，而是在尝试接入组织日常工作。
不过，仓库存在、功能齐全和建议可靠是三件事。当前公开材料没有给出长期企业案例，证明系统在资本配置、裁员、重大合规、危机沟通或并购等高风险决策中达到真实高管水平。
它为什么还不是“AI CEO”
CEO 不只是生成战略建议。真实职位包含董事会授权、对外代表、资源承诺、劳动关系、监管沟通和责任承担。具体法律要求随公司注册地和治理结构变化，不能简单概括成“法人必须是自然人”或“AI 永远不能签字”。
Open Executive 自己的官网写得更克制：系统可以提出、执行或上报被授予范围内的事项，但“判断性决定留给人类”。
这意味着更准确的产品类别是“高管顾问与组织工作流系统”。它可以参与决策准备，在获得工具权限后执行部分动作，却仍需要人类或法人治理机构决定权限、批准高风险事项并承担后果。
如果公司真的把最终决定交给模型，责任不会因为界面上写着 Executive 就消失。董事会、管理人员和系统部署者仍需要解释谁授权、依据什么资料、哪些警告被忽略，以及为什么采取该行动。
为什么大家愿意相信“被 AI 裁员后复仇”
因为真实世界已经出现高压的 AI 采用命令。2025 年 8 月，Coinbase CEO Brian Armstrong 在播客中说，公司为工程师购买 AI 编程工具后，要求所有人迅速注册和尝试；周末会议上，没有合理理由仍未完成的人被解雇。
TechCrunch 报道也强调，被解雇人数看起来不多，要求的首先是注册和试用，不是因为工程师已经被模型直接取代。这个真实事件不能证明 Open Executive 的起源，却解释了复仇叙事为什么显得可信。
许多组织把“是否使用 AI”变成基层员工的新绩效信号，却很少用同一标准审视管理汇报、审批和信息转述。Open Executive 把高管层也纳入自动化讨论，因此天然能引发情绪共鸣。
Sente Labs 也从这种传播中获益。官网既展示开源项目，也提供咨询与部署服务。说复仇故事“就是营销骗局”同样超出证据；更准确的判断是，未经证实的故事为一个真实商业团队的开源产品带来了显著关注。
真正应该评测的不是“像不像老板”
判断 Open Executive 是否有用，需要把口才和决策质量分开。可以设计可重复的企业情景，检查它是否发现关键约束、引用正确资料、量化不确定性、处理专家冲突，并在缺少信息时主动停下。
还要测试权限与安全：恶意公司文档能否提示注入，外部邮件能否诱导系统越权，调度器是否重复执行，离职人员资料是否被继续使用，审计日志能否解释每项行动。
高风险任务必须保留人工批准和双人复核，尤其是付款、解雇、合同、公开声明和监管提交。系统提供的 General Counsel 只是模型角色，不能替代有执业资格、了解具体司法辖区的律师。
最后比较真实成本：模型 API、向量库、部署、数据清理、权限配置、安全审计和人工复核加起来，是否真的低于现有流程；不能只用缓存命中率或“八个高管全年在线”来估算。
比替换 CEO 更有意思的方向
这类工具未必只能服务传统自上而下的公司。合作社、员工持股团队、开源社区和工会也可以用它汇总提案、模拟预算、记录承诺和暴露冲突。
关键区别不在软件本身，而在谁设定目标、谁拥有资料、谁批准行动、收益归谁。把 AI 放在一个人手里，可能只是让权力更集中；把同一套分析能力交给多个利益相关者，也可能降低集体协作成本。
Open Executive 最值得看的，不是它能不能假装成 CEO，而是它把管理工作划分为可观察的模块：分析、检索、记忆、协调、提醒、执行和审计。哪些模块可以自动化，哪些必须由人承担，终于可以被更具体地讨论。
复仇故事为项目带来了流量，代码则留下了更实在的问题：如果高管工作也能被分解和评测，组织应该用什么标准证明每一层管理确实创造了价值？
收看本期节目
原始资料与延伸阅读
本文由《听懂 AI》第 023 期整理而成，仓库和传播状态核对至 2026 年 9 月 4 日。项目架构、8 个角色、模型、许可、记忆、调度器和缓存声明来自 Open Executive 当前 README 与源码；stars、提交数和更新时间为 GitHub 当日快照。裁员复仇起源只有 Reddit 发帖者转述，项目方未确认，按未经证实故事处理。HN 评论仅作为社区观察，关于组织治理与合作社的内容属于编辑性分析。
- SenteLabsAI：Open Executive——当前源码、README、Apache-2.0 许可、架构与运行限制。
- Sente Labs：官方网站——项目方对 Open Executive、自托管、人工判断边界和咨询服务的描述。
- Reddit：CEO fired developers to make room for AI——复仇起源的传播源之一；未提供可独立核验的雇主与开发者身份。
- Hacker News：CEO fired developers to make room for AI——关于 CEO 责任、代码安全、合作社与项目用途的社区讨论。
- Eric Hal Schwartz，TechRadar，2026-09-02：Developers reportedly lost their jobs in an AI Transformation — their response was to automate the C-suite——明确指出雇主未被命名，项目材料未把自身描述为裁员报复。
- Julie Bort，TechCrunch，2025-08-22：Coinbase CEO explains why he fired engineers who didn't try AI immediately——真实的强制 AI 采用案例，用于解释传播语境，不是 Open Executive 起源证据。
- Apache Software Foundation：Apache License 2.0——项目仓库 LICENSE 所使用的许可文本。
资料说明：本文没有把 GitHub stars 当成产品质量证明，也没有独立运行项目或评测其商业建议正确率。“Harvard MBA-level knowledge”和“最高 85% 缓存命中率”均保留项目方声明属性。具体公司治理与法律责任随司法辖区而异，本文不构成法律意见。