LangGraph、AutoGen、CrewAI选型笔记：状态、流程、多Agent与Human-in-the-loop

企业在选Agent框架的时候，很容易从GitHub Star、模型支持数量和Demo效果开始比较，但真正做过项目的人，还是会关注到一些更具体的问题。比如在一项投行尽调任务中，Agent需要先读几十份材料，再查询内部知识库和业务系统，发现数据缺失后重新取数，中途还要等待人工确认，最后生成报告并把结果写回系统。任务一旦拉长，就不能只考虑模型的推理能力，还要考虑流程走到哪一步、失败后从哪里恢复、多个Agent怎么协作，以及哪些操作必须由程序或人工接管。

LangGraph、AutoGen和CrewAI的差异，就藏在这些问题里。

LangGraph：把长任务拆成一张可恢复的状态图

LangGraph就像一张会保存进度的流程图，开发者把检索、判断、工具调用、人工确认等步骤做成节点，再用边决定下一步往哪里走。它最有辨识度的能力是Checkpoint，流程每运行到一定阶段，就保存当前State。服务器异常、工具调用失败或者人工暂时没有审批，都可以从已有状态继续运行，而不必重新执行整条任务。Thread用于隔离不同任务，Interrupt允许在敏感节点暂停，Time Travel则能回到历史Checkpoint重新执行或调试。

这种设计很适合授信审批、投研尽调、复杂客服、软件研发等长链路任务，步骤越多、分支越复杂，状态管理的重要性越高。相应的，团队也需要自己把业务流程想得足够清楚，例如哪些状态需要保存，异常从哪里恢复，哪个节点允许模型决定下一步，哪个节点必须按固定规则运行。LangGraph给开发者留下了很大的控制空间，也把更多工程工作留给了开发团队。

AutoGen：多Agent协作逐步走向显式流程

AutoGen流行起来，和它对多Agent协作的支持关系很大。

一个Agent负责规划，一个负责检索，一个负责写代码，再由另一个Agent检查结果，它们通过异步消息不断交换信息。AutoGen 0.4进一步采用Actor式架构和事件驱动机制，让不同Agent可以相对独立地运行和通信，这套模式很适合研究、软件开发以及需要多角色动态协商的任务。

2026年，微软已经把AutoGen置于维护模式，并将后续能力集中到Microsoft Agent Framework。新的框架保留多Agent协作，同时增加Workflow、Checkpoint、Human-in-the-loop、类型安全和遥测等能力。开发者既可以让Agent动态判断下一步，也可以把关键业务路径写成明确的Workflow。

这种变化很符合企业项目的发展轨迹，早期Demo允许多个Agent充分自主协作，进入生产以后，付款、审批、风控、数据修改等环节通常需要固定路径和明确边界。Agent Framework目前提供顺序、并行、Handoff、Group Chat等多种编排方式，适合微软技术栈较重，或者计划建设大型多Agent系统的团队。

CrewAI：角色任务驱动的轻量编排

前两种框架偏工程结构，CrewAI则更接近企业熟悉的团队分工。

它以Role、Goal和Task定义Agent，研究员负责找资料，分析师负责判断，审核Agent负责检查，再由Crew把这些角色组织起来。Flows则继续负责状态、事件和流程流转。

这种抽象比较容易理解，业务团队和开发团队也容易一起讨论。市场研究、内容生产、销售分析、客服辅助等任务通常可以很快搭起来。复杂度继续上升以后，例如大量异常分支、长时间等待、严格回滚，开发团队仍然需要补充更细的状态和运行控制。

企业上线后，问题会落到执行、权限和审计

框架把任务编排起来之后，Agent还要真正接触企业系统，这里往往比模型本身复杂。

很多ERP、财务软件、柜面系统和老旧C/S客户端没有完整API，即使有API，Agent也不能拿着一个高权限账号随意调用，任务运行几十步以后，还要处理凭证、审批、异常重试和审计记录。

国内几家大厂近两年的产品变化也很能说明这种需求，腾讯云ADP同时提供Workflow和Multi-Agent能力，华住用38条工作流承接住中服务，伊利则把导购、下单、营销拆成多个智能体，蚂蚁数科今年发布Agentar金融智能体专家团，让不同金融数字专家围绕完整业务任务协作。

权限也开始被单独设计，例如阿里云Agent Identity给每个Agent配置独立身份和访问策略，凭证不直接暴露给模型，系统还能记录Agent以什么身份访问了哪些资源。

到了没有API的系统，执行层还需要另一类能力。RPA、Browser Use、Computer Use等技术可以操作网页和桌面软件，把模型生成的计划转成具体动作。国内一些企业级自动化厂商也在沿这条路线扩展，让智能体负责理解和调度，成熟流程继续由已经验证过的自动化组件执行。金智维的Ki-AgentS与K-APA就是其中一种组合，Ki-AgentS负责任务理解、工具调用和多智能体编排，K-APA及既有RPA流程承接网页、桌面端和无API系统里的高频操作，敏感步骤可以暂停等待人工确认，执行轨迹进入日志和审计体系。

这类架构在金融业已经跑了相当长时间，银河期货的数字员工体系覆盖50多个场景，每天运行3000多条流程，核心执行准确率达到99.97%；国金证券随后把Ki-AgentS应用到尽调、制度核对、运维告警等场景，跨系统长链路操作成功率超过95%，项目也从试点扩展到近百个智能体。

把腾讯、蚂蚁、阿里以及这类RPA+Agent路线放在一起看，企业Agent的技术栈正在逐渐分层，上面是模型和Agent负责理解与判断，中间是Workflow管理任务流转，下面由API、RPA等工具进入业务系统，外围再加身份、权限、人工审批和审计。

框架选型最终要回到业务复杂度

一个企业项目如果还在验证阶段，业务角色清晰、希望快速跑出多Agent原型，CrewAI上手会更快；如果任务流程很长，需要频繁暂停、恢复和回溯，LangGraph的状态机制更合适；企业已有较深的微软技术栈，或者准备建设规模化多Agent体系，Microsoft Agent Framework更值得重点评估。

到了财务、金融、政务、制造等核心流程，框架本身只占架构的一部分。系统有没有API、Agent能拿到什么权限、任务失败如何恢复、敏感操作由谁确认、每一步能否留下记录，这些问题会直接决定一个Agent能不能长期运行。

2026年的企业Agent选型，技术团队需要同时看两个方面：一是Agent怎样思考和协作，二是它怎样安全地进入真实业务系统。