Agent 框架够用了，但系统治理呢？

框架回答"怎么想"，平台回答"谁拥有"

选一个 Agent 框架来构建智能体，框架会告诉你：推理图怎么画、角色怎么分、工具怎么接、人工审批卡在哪一步。但它不会回答另一个问题——Agent 运行的系统归谁所有，产出的工作成果谁来审核。这个问题，团队往往到后期才会撞上。

本文对比三种代表性方案：LangGraph、CrewAI 和 Kortix，帮你在选型时看清差异。

两个主流框架：精确控制的代价

LangGraph：底层编排引擎

LangGraph 是一个基于 MIT 协议开源的有状态 Agent 编排框架。它的核心能力包括：持久化执行、人工中断（human-in-the-loop interrupts）、短期与长期记忆、以及配套的 LangSmith 调试部署工具。

你用自己写的 Python 代码定义 Agent 逻辑，自己托管、自己接入模型和工具。框架给你的不是黑盒，而是精确到每一行的控制权——这正是它的价值所在。

CrewAI：多 Agent 协作框架

CrewAI 同样 MIT 协议开源，专为多 Agent 工作流设计。它提供两个核心原语：

• Crews：基于角色的 Agent 团队，支持协作与委派
• Flows：事件驱动的自动化流程，带显式状态和分支逻辑

对于已经在 Python 生态中的团队，CrewAI 是从零到有、让多个 Agent 协作的最短路径之一。

两个框架的共同点：你拥有全部控制权，但也意味着所有基础设施、状态管理、审核流程都需要你自己搭。

Kortix：把系统当代码来治理

Kortix 走了一条不同的路——它是一个开源的 AI 操作系统（AI OS），核心理念是：公司的 Agent、技能、记忆和连接器全部以文件形式存放在一个公司自己拥有的 Git 仓库中。

三个关键设计

1. 每次会话运行在独立的云端计算机上，隔离且可审计
2. Agent 产出的工作以 Change Request 形式提交，附带精确的 diff，由人审核后才能合并到主分支
3. 没有框架需要 import，没有应用需要围绕它构建——仓库本身就是系统

对比一览

维度	Kortix	LangGraph	CrewAI
定位	公司级 AI 操作系统	有状态 Agent 编排框架	多 Agent 工作流框架
开源	是	是（MIT）	是（MIT）
谁运行	公司自持，支持云/VPC/本地	你部署库	你部署应用
共享记忆	仓库中的文件，团队共同版本管理	你自己的存储	每次运行自行持久化
人工审核	Change Request + diff 审核	你编码实现中断逻辑	你编码实现审核逻辑
模型选择	任意模型，自带密钥	模型无关	通过 API 接入任意 LLM

什么时候该选框架，什么时候该选平台？

选框架的场景：单个团队在已有的应用内构建 Agent 行为，Agent 是产品功能的一部分而非公司工作方式。你需要精确控制推理图和状态，像测试普通软件一样测试 Agent。

选平台的信号：当多人、多 Agent 共享同一上下文时，三个问题会同时出现——

问题一：共享状态

多个 Agent 需要同一份公司记忆，多个人需要看到每个 Agent 学到了什么。把状态塞在某个应用内部就不够用了。Kortix 的做法是把记忆作为仓库中的文件，团队共同版本管理和审核。

问题二：工具接入

把 CRM、计费系统、代码托管接入 Agent 逻辑，一直是应用层面的管道工作。但当"哪个 Agent 可以碰哪个工具"的规则需要被审核者阅读时，就需要一个集中管理的层。Kortix 支持 3000+ 应用一键接入，兼容 MCP、OpenAPI、Postman、GraphQL 和原始 HTTP，且连接器凭据在服务端代理，永远不会进入 Agent 的运行环境。

问题三：审核流程

会改变公司关键资产的工作，应该像代码一样落地。在 Kortix 中，每次会话自动创建分支，Agent 以 Change Request 形式提交工作（附带精确 diff），默认拒绝合并，由人来决定什么上线。

实用建议

• 个人项目 / 产品内嵌 Agent：LangGraph 或 CrewAI 是强引擎，上手快、控制细
• 多团队协作 / 公司级 Agent 基础设施：考虑 Kortix 这类平台方案，核心收益是所有权和可审计性
• 混合策略：在 Kortix 仓库中用 LangGraph 或 CrewAI 编写 Agent 逻辑，同时获得平台级的治理和审核能力

框架解决的是"Agent 怎么想"，平台解决的是"系统归谁、谁来审核"。两个问题都需要答案，但答案不在同一个层面。