CrewAI替代方案：企业级开源AI操作系统Kortix

当AI代理从单个Python应用走向公司级工作流，开发者会遭遇一个隐形的边界：CrewAI在终端里跑得很干净，但同事会问为什么它看不到上季度的工单，或者谁批准了发给客户的邮件。问题不在于CrewAI不好，而在于框架能覆盖的范围和公司实际需要的系统之间存在结构性缺口。

CrewAI擅长什么，以及它在哪里停住

CrewAI是一个开源Python框架，用于编排角色扮演的自主代理。它给开发者两个原语：Crew是一组基于角色的代理团队，可以协作和委派任务；Flow是事件驱动的工作流，管理状态和控制执行，Flow可以在某个步骤调用Crew。根据CrewAI官方文档，Flows是应用的骨干，Crews是其中的工作单元。

这个形态很适合交付物是一个Python应用、由工程师拥有和运维的场景。夜间研究任务、固定形态的流水线、开发者可以在trace中跟踪的报告——这些都是CrewAI的主场。它还围绕框架提供了商业层，仓库中描述CrewAI AMP Suite增加了托管部署、可观测性、治理、安全和企业支持。据其GitHub仓库，该项目获得约59,700颗星，最新版本1.15.28于2026年10月14日发布。

然而，大多数CrewAI的对比文章都在比较框架与框架。真正决定是否迁移的维度不同：谁拥有运行时，谁拥有记忆。框架回答代理如何在代码中协同工作，然后它就停住了。公司级工作的其余部分仍然留给部署它的团队。

具体来说，框架不覆盖的部分包括：

• 持久共享记忆：框架只保留你告诉它为那次运行持久化的内容。让多人和多个代理共享一份超越每次运行的公司记忆，是需要自己构建的系统。
• 连接整个公司：框架给你调用工具的地方，但连接每个应用、持有凭证、决定哪个代理能碰什么，仍然留在你的应用里。
• 作者之外的审查：在框架中，审查者阅读的是运行代理的代码，代理的输出没有diff可供审批，除非有人构建一个。
• 治理：按资源的权限、审计轨迹和审批门是平台拥有的东西，不拥有运行时的库无法交付这些。
• 非Python工程师的界面：销售或财务的同事要启动一个任务，需要一个别人必须构建的界面。

这些都不是CrewAI的缺陷。它们位于框架所覆盖的层之外，而一旦代理不再属于一个团队的代码库，这些部分就会增长。

Crew与Flow的区别值得展开：Crew对应的是「团队协作」模型，你定义若干具备角色（role）、目标（goal）和背景故事（backstory）的代理，它们通过委派和顺序/层级流程共同完成一个任务；Flow对应的是「状态机」模型，你用 @start、@listen、@router 等装饰器把一串步骤连成有向图，中间的状态在步骤之间显式传递与持久化。二者的关系是：Flow是应用的骨架，负责决定「先做什么、下一步去哪、失败了怎么重试」；Crew是骨架上的肌肉，负责在某一格子里让多个代理协商完成一个具体交付物。理解这一分层是理解后文「边界」的前提——框架能管住图内节点，但图外的东西（记忆、凭证、审批、界面）它不做主。

文中反复出现的「运行时（runtime）」指的是实际承载代理执行的那套基础设施：进程/容器调度、状态存储、工具调用的网络出口、日志与追踪、密钥注入。拥有运行时意味着你决定代理跑在哪、能访问什么网络、状态写到哪里、失败如何重放。相比之下，框架只定义「代理如何协作」这一层抽象。因此「谁拥有运行时」实质是在问：当代理出问题时，是谁有能力停机、限权、回溯审计以及修复数据——如果答案落在使用框架的那个团队之外，公司级治理就无从施加。

其他Python框架共享同一边界

CrewAI不是这条赛道上唯一的框架，而且边界随框架移动，而不是远离。LangGraph是一个低层编排框架和运行时，用于长时间运行、有状态的代理。它的checkpointers保留线程状态，stores保留跨线程数据，因此图可以在失败后恢复并跨交互记忆。这种持久性是真实的，但它仍然是一个你组装的运行时和一个你配置的存储层，所有权问题依然在你这边。

换句话说，从CrewAI换到LangGraph，并没有解决“谁拥有整个系统”的问题，只是换了一种组装方式。

替代思路：Kortix，开源AI操作系统

Kortix是代理周围的系统，你从头到尾拥有它。代理、技能、公司记忆、连接器配置和触发器都是你拥有的一个git仓库中的文件，因此公司像代码一样被版本化、可diff、可审计。框架问题在这个仓库内部解决。OpenCode是harness，由文件配置，因此将模型变成代理的那一层不是你被锁定的东西。

每个会话运行在自己的云计算机上，一个会话一个隔离沙箱。每个会话有自己的隔离机器和分支，代理可以安装、运行、破坏任何东西，只有它提交的内容会存活。数千个代理在一个配置上并行，各自在自己的云计算机上。

连接器一键触达3,000+应用，加上MCP、OpenAPI、Postman、GraphQL和原始HTTP。连接器凭证在服务端代理，从不进入机器。在人的层面，按资源的权限面向人员和代理，角色、组和审计轨迹。审批门由你设置，默认关闭直到你开启。

工作通过审查落地。会话工作通过变更请求到达main分支。对代理而言合并默认拒绝，因此没有写提示词的人阅读diff并决定什么发布。同一系统可以从Web应用、CLI、Slack和Microsoft Teams访问，这就是非工程师同事启动工作的方式。

模型选择由你决定：任何模型提供商，用你自己的密钥。可以在Kortix Cloud、你的VPC或自己的本地网络运行。自托管免费。Kortix是开源的：阅读、fork、审计，GitHub上获得20,000+颗星。Kortix文档展示了具体机制。

**MCP（Model Context Protocol）**是Anthropic提出的一套开放协议，用统一的方式把外部工具、数据源和提示模板暴露给模型，使同一个连接器可以被不同客户端复用，而不必为每个模型或框架单独适配。文中提到的OpenAPI、Postman、GraphQL和原始HTTP则属于更传统的集成方式：OpenAPI用规范描述REST接口，Postman集合把一组请求打包成可复用资产，GraphQL让客户端按需取字段。把这几种方式并列，意味着连接器层需要同时吃得下「为模型设计的协议」和「为企业已有的API资产」，否则跨部门接入就会退化成逐个写胶水代码。

如何决策：三个问题

选择取决于工作本身。三个问题可以定夺。

上下文是否超越一次运行？

如果每次运行都从零开始，框架就够了。如果后续运行需要建立在之前学到的东西上，你需要公司拥有的记忆，而不是进程持有的记忆。

谁审查输出？

如果作者自己读，框架就够了。如果第二个人在它改变任何东西之前签字，你需要平台运行的审查门。

谁启动工作？

如果只有写它的工程师启动，框架就够了。如果另一个职能的同事从聊天或表单启动，你需要代码库之外的界面。

当每个答案都落在框架一侧时，保留CrewAI。它对于活在一个应用内部的代理是正确的形态，留下来不会失去什么。当任何一个答案落在系统一侧时，缺失的是一套公司运行的系统，因为不拥有运行环境的库无法添加它。

**「默认拒绝的合并（merge by default denied）」**是一种权限默认值设计：代理产出的改动以变更请求（pull/merge request）形式提出，除非有人在系统里显式批准，否则不会被合入主分支或被下游系统消费。这与「默认允许、出事后撤销」相反，把人工判断放在副作用发生之前。对代理而言这点尤为关键，因为代理的输出不是一段可读的diff本身，而是它执行过的动作——发邮件、改工单、写数据库——所以审查门必须在动作生效前拦截，而不是在事后比对日志。

要点总结

CrewAI作为框架是优秀的，但公司级工作需要的共享记忆、连接器、审查门、治理和非工程师界面超出了框架的覆盖范围。Kortix定位为开源AI操作系统，用git仓库拥有代理、记忆和连接器配置，每个会话在隔离云计算机上运行，通过变更请求和默认拒绝的合并实现审查，支持Web、CLI、Slack和Teams。决策取决于上下文是否超越一次运行、谁审查输出、谁启动工作这三个问题。