[实战] 2026年机械制图规范：从GDT标注到数字化检验计划的技术演进
2026/6/11 2:11:51
六款热门开源Agent框架横向实测：从原型到生产，从单智到协作的选择指南
1. 引入与连接：为什么Agent是AI落地的「最后一公里」？
核心概念：先搞懂「什么是真·AI Agent」
问题背景：2023年至今，大语言模型（LLM）经历了从「爆发期」到「冷静期」的转变——ChatGPT掀起的技术海啸，很快被「幻觉严重」「工具调用能力不稳定」「无法处理复杂多步骤任务」「生产部署困难」四大痛点拉回现实。
问题描述：如果把LLM比作「大脑」，那它现在只是「坐在办公室里空想的大脑」：没有眼睛（感知多模态）、没有手脚（调用工具/执行代码）、没有记忆（上下文窗口有限）、没有协作分工（单干效率低/易出错）、没有监管（安全隐患大）。
问题解决：AI Agent（智能体）就是给这个「空想大脑」装上的「完整躯体+协作系统+安全护栏」——它是一个能够感知环境、理解目标、制定规划、调用工具、执行操作、自我反思、持续迭代的自主系统。
与你已有知识的连接点
不管你是前端/后端开发（需要快速做AI应用原型）、数据分析师/产品经理（需要做复杂的多步骤RAG/自动化分析）、AI研究员（需要探索多agent协作/多模态感知）、企业IT架构师（需要做安全可控的生产级AI系统），你肯定用过或听过以下这些技术：
- API调用：OpenAI/Claude/Llama的API——Agent的核心「大脑」
- RAG（检索增强生成）：Chroma/Pinecone的向量数据库——Agent的「长期知识库」
- 工具链：Python脚本、浏览器自动化工具（Playwright/Selenium）、数据库查询——Agent的「手脚」
- 可视化：Figma、Draw.io——Flowise等可视化Agent框架的灵感来源
学习价值与应用场景预览
读完这篇文章并跟着做实测，你将：
- 掌握六款热门Agent框架的核心能力、优缺点、适用场景——不再被网上的「神吹文」「踩雷文」误导
- 完成每款框架的最小可用原型（MVP）开发——比如：
- 用LangChain做一个「能查天气+发邮件的个人助理」
- 用CrewAI做一个「能写产品需求文档+竞品分析报告的产品团队」
- 用Flowise零代码做一个「基于企业知识库的问答机器人」
- 用LlamaIndex做一个「能处理PDF/Excel/PPT/视频的多模态RAG系统」
- 用GPT Engineer做一个「能从零生成一个React+FastAPI全栈Todo应用」
- 用Haystack做一个「适合企业生产部署的RAG搜索引擎」
- 建立一套完整的Agent框架选型方法论——下次遇到AI落地需求，30分钟内就能选对框架
学习路径概览
这篇文章将按照「知识金字塔构建者」的方法论展开：
- 基础层：六款热门Agent框架的核心概念、直观类比、关键术语
- 连接层：六款框架的核心属性对比、ER实体关系图、交互关系图
- 深度层：六款框架的底层原理、数学模型（如果有）、核心实现细节
- 多维透视：历史发展脉络、生产部署能力、社区生态、局限性与争议
- 实践转化：每款框架的最小可用原型（MVP）开发步骤、环境安装、核心代码
- 整合提升：Agent框架选型方法论、最佳实践Tips、行业发展与未来趋势
2. 概念地图：六款热门Agent框架的整体认知
核心概念与关键术语
在开始之前，先统一一下Agent领域的核心术语——避免不同框架的「定义混乱」（这是Agent领域最大的坑之一！）：
| 术语 | 我的统一（借鉴斯坦福NLP Agent框架定义） | 主流框架的不同叫法 |
|---|---|---|
| Agent | 能够感知环境、理解目标、制定规划、调用工具、执行操作、自我反思的自主系统 | LangChain：Agent；CrewAI：Agent；Flowise：Agent/Chain；LlamaIndex：Agent/Query Engine；GPT Engineer：Project；Haystack：Pipeline/Agent |
| LLM/Foundation Model | Agent的核心「决策大脑」，负责理解目标、生成文本/代码、制定规划 | 所有框架都叫LLM/Foundation Model，部分框架叫LM（Language Model） |
| Memory | Agent的「记忆系统」，分为短期记忆（Short-Term Memory, STM，类似人类的工作记忆，存储在上下文窗口内）和长期记忆（Long-Term Memory, LTM，类似人类的知识库，存储在向量数据库/关系数据库中） | LangChain：Memory；CrewAI：Memory/Short-Term Memory/Long-Term Memory；Flowise：Memory；LlamaIndex：Memory/Storage Context；GPT Engineer：Memory；Haystack：Memory |
| Tool/Toolkit | Agent的「手脚」，分为内置工具（比如天气查询、计算器）、自定义工具（比如Python脚本、数据库查询）、第三方API工具（比如Google Search、Stripe） | LangChain：Tool/Toolkit；CrewAI：Tool/Toolkit；Flowise：Tool；LlamaIndex：Tool/Toolkit；GPT Engineer：Tool；Haystack：Node（部分Node是工具） |
| Planning | Agent的「规划系统」，负责把复杂目标分解成多个简单子任务（Task Decomposition），并对子任务进行排序、优先级调整、重新规划（Re-Planning） | LangChain：Planning/Agent Type（不同Agent Type对应不同的规划策略）；CrewAI：Planning/Task Manager；Flowise：Chain Structure（可视化规划）；LlamaIndex：Planning/Query Transformations；GPT Engineer：Planning；Haystack：Pipeline Structure（线性/非线性规划） |
| Reflection/Critique | Agent的「自我反思系统」，负责检查自己的操作是否正确、结果是否符合目标、是否有幻觉、是否需要重新规划/调整工具调用 | LangChain：Reflection（部分Agent Type支持，比如ReAct、Self-Ask with Search）；CrewAI：Reflection/Critique Agent；Flowise：无内置，需要自定义Chain；LlamaIndex：Reflection（部分Query Engine支持，比如SubQuestionQueryEngine）；GPT Engineer：Reflection/Critique；Haystack：无内置，需要自定义Node |
| Environment | Agent的「生存环境」，比如互联网、企业内网、代码仓库、用户设备等 | 大部分框架没有明确定义，但LangChain的「Playground」、CrewAI的「Crew」、Flowise的「Canvas」可以看作是「模拟环境」 |
六款热门Agent框架的选型坐标系
为了让你更直观地理解六款框架的定位，我画了一个二维选型坐标系：
- X轴：复杂度（从左到右：低→高）——低复杂度=低代码/零代码、快速原型；高复杂度=支持多agent协作、多模态感知、复杂规划、生产部署
- Y轴：场景聚焦（从下到上：通用→垂直）——通用=可以处理各种任务；垂直=聚焦某个特定场景（比如代码生成、RAG）
坐标系中的六款框架如下：
- Flowise：左下角——低复杂度、通用（但其实更偏向「可视化RAG/轻量Agent」）
- LangChain：中左——中等复杂度、通用
- LlamaIndex：中右——中等复杂度、垂直（聚焦RAG/知识管理）
- Haystack：中右——中等复杂度、垂直（聚焦生产级NLP/RAG）
- CrewAI：右上角——高复杂度、通用（聚焦多agent协作）
- GPT Engineer：右上角——高复杂度、垂直（聚焦代码生成/全栈应用开发）
概念之间的关系：对比表格、ER架构图、交互关系图
2.3.1 核心属性维度对比 markdown 表格
这是最核心的对比表格——几乎涵盖了你选型时需要考虑的所有维度：
| 维度 | Flowise | LangChain | LlamaIndex | Haystack | CrewAI | GPT Engineer |
|---|---|---|---|---|---|---|
| 定位 | 可视化低代码/零代码Agent构建平台（原型神器） | 通用Agent/LangChain应用开发框架（生态天花板） | 数据感知Agent/RAG框架（RAG天花板） | 生产级NLP/RAG框架（企业部署首选） | 多agent协作框架（模拟人类团队协作） | 代码生成/全栈应用开发框架（从零生成代码） |
| 核心设计理念 | 「拖拽式构建AI应用，不用写一行代码」 | 「把LLM、工具、记忆、规划等组件拼接起来，像搭积木一样构建AI应用」 | 「让LLM能够理解和使用你的私有数据，不管数据是什么格式」 | 「构建可扩展、可监控、可维护的生产级NLP/RAG系统」 | 「把复杂任务拆分成多个角色明确的子任务，让多个Agent协作完成」 | 「让LLM像人类程序员一样思考：理解需求→制定计划→写代码→测试→迭代」 |
| 支持的LLM | 几乎所有主流LLM：OpenAI（GPT-4o/GPT-4 Turbo/GPT-3.5 Turbo）、Claude（Opus/Sonnet/Haiku）、Llama（3/3.1/2）、Mistral（Large/Medium/Small）、Gemini（Pro/Ultra）、本地模型（Ollama/LM Studio）等 | 同上，支持的LLM数量最多（100+），还有专门的「LLM Wrapper」统一接口 | 同上，支持的主流LLM都有，但更注重「数据感知LLM」（比如微调后的Llama用于RAG） | 同上，支持的主流LLM都有，但更注重「生产级LLM集成」（比如Azure OpenAI、AWS Bedrock的企业级安全集成） | 同上，支持的主流LLM都有，但更注重「角色定制LLM提示词」 | 主要支持OpenAI（GPT-4o/GPT-4 Turbo/GPT-3.5 Turbo）、Claude（Opus/Sonnet）、Gemini（Pro/Ultra），本地模型支持有限（需要较强的本地硬件） |
| 支持的工具 | 内置100+主流工具：天气查询、计算器、Google Search、Bing Search、Wikipedia、Chroma、Pinecone、Weaviate、PostgreSQL、MySQL、Slack、Discord、Email等；也支持自定义工具（但需要写Python代码，然后上传Flowise） | 内置300+主流工具，数量最多；也支持自定义工具（非常灵活，只需要继承BaseTool类，实现_run和_arun方法） | 内置50+主流工具，但更注重「数据工具」（比如PDF解析器、Excel解析器、PPT解析器、视频解析器、图像解析器、数据库查询工具、向量数据库查询工具等） | 内置30+主流工具，但更注重「NLP工具」（比如文本分类、文本摘要、文本翻译、命名实体识别、关键词提取等）和「生产级工具」（比如缓存、监控、日志、重试机制等） | 内置100+主流工具（基于LangChain的Toolkit），也支持自定义工具（非常灵活，和LangChain一样继承BaseTool类） | 内置少量工具（主要是文件系统工具、代码执行工具、版本控制工具Git），也支持自定义工具（但相对麻烦，需要修改框架的核心代码） |
| 记忆系统 | 内置5+主流记忆类型：ConversationBufferMemory（对话缓冲记忆）、ConversationBufferWindowMemory（对话窗口记忆）、ConversationSummaryMemory（对话摘要记忆）、ConversationSummaryBufferMemory（对话摘要缓冲记忆）、VectorStoreRetrieverMemory（向量检索记忆）；可视化配置记忆参数（比如窗口大小、摘要LLM） | 内置10+主流记忆类型，数量最多；也支持自定义记忆（非常灵活，只需要继承BaseMemory类） | 内置「Storage Context」作为统一的记忆接口，支持短期记忆（存储在内存中）和长期记忆（存储在向量数据库/关系数据库/文档存储中）；更注重「结构化长期记忆」（比如知识图谱、文档层级结构） | 内置「MemoryNode」作为记忆节点，支持短期记忆和长期记忆；更注重「生产级记忆」（比如分布式记忆、持久化记忆、记忆压缩） | 内置「Crew Memory」作为统一的记忆接口，支持「共享记忆」（所有Agent都能访问）和「私有记忆」（只有特定Agent能访问）；可视化配置记忆参数（比如是否共享、是否持久化） | 内置「Project Memory」作为统一的记忆接口，支持「需求记忆」（存储用户的原始需求）、「规划记忆」（存储制定的计划）、「代码记忆」（存储生成的代码）、「测试记忆」（存储测试结果）；更注重「迭代记忆」（每次迭代都会更新记忆） |
| 规划系统 | 可视化Chain Structure作为规划系统，支持线性规划、分支规划、循环规划；内置「Agent Chain」支持ReAct、Self-Ask with Search等简单规划策略 | 内置「Agent Type」作为规划系统，支持10+规划策略：ReAct、Self-Ask with Search、Zero-Shot React Description、Conversational React、Plan-and-Execute、OpenAI Functions Agent、Structured Chat Agent、BabyAGI、AutoGPT等；也支持自定义规划策略（非常灵活，只需要继承BaseAgent类） | 内置「Query Transformations」作为规划系统，支持10+查询转换策略：Query Rewriting（查询重写）、SubQuestion Decomposition（子问题分解）、Hypothetical Document Embedding（HyDE，假设文档嵌入）、Multi-Step Query Engine（多步查询引擎）等；更注重「数据感知规划」（比如根据数据的结构自动调整查询策略） | 内置「Pipeline Structure」作为规划系统，支持线性规划、分支规划、循环规划、并行规划；也支持「Conditional Routing」（条件路由）根据用户的查询自动选择不同的处理路径；更注重「生产级规划」（比如可监控的规划、可回滚的规划） | 内置「Task Manager」作为规划系统，支持「Hierarchical Task Decomposition」（层次化任务分解）、「Role-Based Task Assignment」（基于角色的任务分配）、「Re-Planning」（重新规划）、「Task Priority Adjustment」（任务优先级调整）；更注重「多agent协作规划」（比如让Agent之间通过对话协商任务分配和规划） | 内置「Planning Agent」作为规划系统，支持「Hierarchical Task Decomposition」（层次化任务分解）、「Iterative Planning」（迭代规划）、「Self-Correction Planning」（自我修正规划）；更注重「代码生成规划」（比如先写后端API，再写前端组件，最后写测试用例） |
| 自我反思系统 | 无内置自我反思系统，需要自定义Chain（比如在Agent Chain后面加一个「Critique LLM」来检查结果） | 部分Agent Type支持自我反思：ReAct（在每次工具调用后反思结果是否符合预期）、Plan-and-Execute（在执行完所有子任务后反思整个计划是否合理）、Self-Ask with Search（在每次搜索后反思是否需要继续搜索）；也支持自定义自我反思系统（非常灵活） | 部分Query Engine支持自我反思：SubQuestionQueryEngine（在每个子问题回答后反思是否需要继续分解子问题）、Multi-Step Query Engine（在每步查询后反思是否需要继续查询）；也支持自定义自我反思系统 | 无内置自我反思系统，需要自定义Node（比如在Pipeline最后加一个「Critique Node」来检查结果） | 内置「Critique Agent」作为自我反思系统，支持「Task Critique」（任务反思，检查单个Agent的任务完成情况）、「Crew Critique」（团队反思，检查整个Crew的任务完成情况）、「Self-Critique」（自我反思，让Agent检查自己的工作）；也支持自定义自我反思系统 | 内置「Critique Agent」作为自我反思系统，支持「Plan Critique」（计划反思，检查制定的计划是否合理）、「Code Critique」（代码反思，检查生成的代码是否有bug、是否符合最佳实践）、「Test Critique」（测试反思，检查测试用例是否覆盖所有场景、测试结果是否符合预期）；也支持自定义自我反思系统 |
| 可视化能力 | 可视化能力最强：可视化拖拽构建Chain/Agent、可视化预览Chain/Agent的执行流程、可视化查看Chain/Agent的执行日志、可视化查看Chain/Agent的记忆内容、可视化配置所有参数（不用写一行代码） | 可视化能力一般：有LangChain Playground（可以可视化测试Chain/Agent）、有LangSmith（可以可视化监控Chain/Agent的执行流程、查看执行日志、查看记忆内容、查看Token使用情况、查看成本——但LangSmith是闭源的SaaS产品，免费版有使用限制） | 可视化能力较弱：只有LlamaIndex Hub（可以查看和下载其他开发者分享的Query Engine/Tool）、没有内置的可视化执行流程/日志/记忆内容的工具 | 可视化能力较弱：只有Haystack UI（可以可视化测试Pipeline/Agent）、没有内置的可视化监控工具（需要集成Prometheus/Grafana等第三方监控工具） | 可视化能力中等：有CrewAI Playground（可以可视化测试Crew、查看Crew的执行流程、查看执行日志）、有CrewAI Hub（可以查看和下载其他开发者分享的Crew/Agent/Tool） | 可视化能力较弱：只有GPT Engineer UI（可以可视化输入需求、查看生成的代码、查看执行日志）、没有内置的可视化规划流程/测试流程的工具 |
| 生产部署能力 | 生产部署能力一般：可以一键导出Chain/Agent为Python代码、可以一键部署为REST API（FastAPI）、可以一键部署为Docker镜像、但不支持分布式部署、不支持企业级安全集成（比如SSO、RBAC）、不支持可监控的生产级部署（需要集成LangSmith等第三方工具） | 生产部署能力中等：可以导出Chain/Agent为Python代码、可以部署为REST API（FastAPI/Flask）、可以部署为Docker镜像、可以部署为Kubernetes Pods、支持企业级安全集成（比如Azure OpenAI、AWS Bedrock）、但可监控性需要依赖LangSmith（闭源SaaS）、可维护性一般（代码拼接容易出错） | 生产部署能力中等：可以导出Query Engine/Agent为Python代码、可以部署为REST API（FastAPI）、可以部署为Docker镜像、可以部署为Kubernetes Pods、支持企业级安全集成（比如Azure OpenAI、AWS Bedrock）、支持分布式向量数据库（比如Pinecone、Weaviate、Chroma Cluster）、但可监控性一般（需要集成第三方工具）、可维护性一般（代码结构相对复杂） | 生产部署能力最强：专为生产部署设计、可以导出Pipeline/Agent为Python代码、可以部署为REST API（FastAPI）、可以部署为Docker镜像、可以部署为Kubernetes Pods、支持企业级安全集成（比如SSO、RBAC、Azure OpenAI、AWS Bedrock）、支持分布式部署、支持内置的缓存、监控、日志、重试机制、支持可回滚的部署、支持Prometheus/Grafana等第三方监控工具的无缝集成、可维护性强（代码结构清晰、模块化程度高） | 生产部署能力一般：可以导出Crew/Agent为Python代码、可以部署为REST API（FastAPI）、可以部署为Docker镜像、但不支持分布式部署、不支持企业级安全集成（比如SSO、RBAC）、不支持可监控的生产级部署（需要集成LangSmith等第三方工具）、可维护性一般（多agent协作的代码结构相对复杂） | 生产部署能力较弱：主要用于快速原型开发、可以导出Project为Python代码、但部署为生产级应用需要大量的修改（比如添加安全机制、添加监控机制、优化性能）、不支持分布式部署、不支持企业级安全集成 |
| 社区生态 | 社区生态中等：GitHub Stars约30k（截至202X年X月）、GitHub Forks约3k、GitHub Issues约1k、Discord社区约10k人、文档相对完善、有中文文档、有LlamaIndex Hub（可以查看和下载其他开发者分享的Flow/Agent/Tool） | 社区生态最强：GitHub Stars约110k（截至202X年X月）、GitHub Forks约18k、GitHub Issues约8k、Discord社区约50k人、文档非常完善、有中文文档、有LangChain Hub（可以查看和下载其他开发者分享的Prompt/Chain/Agent/Tool）、有LangSmith（闭源SaaS，但免费版有使用限制）、有大量的第三方教程和课程、有大量的企业用户（比如Google、Microsoft、IBM、Salesforce等） | 社区生态较强：GitHub Stars约35k（截至202X年X月）、GitHub Forks约4k、GitHub Issues约2k、Discord社区约15k人、文档非常完善、有中文文档、有LlamaIndex Hub（可以查看和下载其他开发者分享的Query Engine/Tool/Loader）、有大量的第三方教程和课程、有大量的企业用户（比如Uber、Airbnb、Stripe等） | 社区生态中等：GitHub Stars约18k（截至202X年X月）、GitHub Forks约2k、GitHub Issues约1k、Discord社区约8k人、文档相对完善、有部分中文文档、有Haystack Hub（可以查看和下载其他开发者分享的Pipeline/Node）、有大量的企业用户（比如Siemens、Bayer、Deutsche Bank等） | 社区生态较强：GitHub Stars约25k（截至202X年X月）、GitHub Forks约3k、GitHub Issues约1k、Discord社区约12k人、文档相对完善、有部分中文文档、有CrewAI Hub（可以查看和下载其他开发者分享的Crew/Agent/Tool）、有大量的第三方教程和课程、有大量的企业用户（比如Notion、Slack、Discord等） | 社区生态中等：GitHub Stars约50k（截至202X年X月）、GitHub Forks约6k、GitHub Issues约3k、Discord社区约10k人、文档相对完善、有部分中文文档、有大量的第三方教程和课程、但企业用户相对较少（主要用于个人开发者和初创公司） |
| 学习曲线 | 学习曲线最平缓：零代码/低代码、可视化拖拽、文档有大量的视频教程和示例、10分钟内就能做出一个简单的RAG机器人 | 学习曲线中等：需要掌握Python编程、需要理解LLM、工具、记忆、规划等核心概念、文档有大量的示例、但代码拼接容易出错、可能需要1-2天才能做出一个简单的Agent | 学习曲线中等偏陡：需要掌握Python编程、需要理解RAG的核心原理（比如向量嵌入、相似度搜索、查询重写等）、需要理解LlamaIndex的「Storage Context」「Index」「Query Engine」等核心概念、文档有大量的示例、但代码结构相对复杂、可能需要2-3天才能做出一个简单的多模态RAG系统 | 学习曲线中等偏陡：需要掌握Python编程、需要理解NLP/RAG的核心原理、需要理解Haystack的「Pipeline」「Node」「Document Store」等核心概念、文档有大量的示例、但专为生产部署设计，概念相对较多、可能需要2-3天才能做出一个简单的生产级RAG搜索引擎 | 学习曲线中等偏陡：需要掌握Python编程、需要理解多agent协作的核心原理（比如角色分工、任务分配、对话协商、自我反思等）、需要理解CrewAI的「Crew」「Agent」「Task」「Process」等核心概念、文档有大量的示例、但多agent协作的代码结构相对复杂、可能需要2-3天才能做出一个简单的产品团队Crew | 学习曲线最陡：需要掌握Python编程、需要理解全栈应用开发的核心原理（比如前端React、后端FastAPI、数据库PostgreSQL、版本控制Git等）、需要理解GPT Engineer的「Planning Agent」「Code Generator Agent」「Critique Agent」「Test Agent」等核心概念、文档相对较少、示例相对较少、本地模型支持有限、可能需要3-5天才能做出一个简单的全栈Todo应用 |
| 成本（Token使用） | Token使用成本中等：和LangChain差不多（因为Flowise是基于LangChain和LlamaIndex构建的）、但可视化配置可能会导致一些不必要的Token使用 | Token使用成本较高：因为代码拼接容易导致一些不必要的上下文传递、因为部分Agent Type（比如ReAct）需要多次调用LLM和工具、Token使用成本可能会比其他框架高10%-30% | Token使用成本较低：因为更注重「数据感知」（比如只检索相关的数据、只传递必要的上下文）、因为部分Query Engine（比如SubQuestionQueryEngine）可以减少LLM的调用次数、Token使用成本可能会比LangChain低10%-20% | Token使用成本较低：因为专为生产部署设计，内置了缓存机制（可以缓存相同的查询结果）、因为更注重「效率」（比如只检索Top-K最相关的数据、只传递必要的上下文）、Token使用成本可能会比LangChain低20%-40% | Token使用成本较高：因为多agent协作需要多次调用LLM（每个Agent都需要调用LLM）、因为需要多次自我反思、Token使用成本可能会比LangChain高30%-50% | Token使用成本最高：因为代码生成需要大量的Token（生成全栈应用可能需要几十万甚至几百万Token）、因为需要多次迭代、多次自我反思、多次测试、Token使用成本可能会比LangChain高50%-200% |
| 安全性 | 安全性一般：因为是基于LangChain和LlamaIndex构建的、有相同的安全隐患（比如Prompt Injection、Tool Misuse、Data Leakage）、但不支持企业级安全集成（比如SSO、RBAC） | 安全性一般：有内置的安全机制（比如Prompt Guardrails、Tool Validation）、但代码拼接容易导致安全漏洞、支持企业级安全集成（比如Azure OpenAI、AWS Bedrock）、但Prompt Injection、Tool Misuse、Data Leakage等安全隐患仍然存在 | 安全性一般：有内置的安全机制（比如Data Redaction、Tool Validation）、但数据感知容易导致Data Leakage（比如检索到敏感数据后传递给LLM）、支持企业级安全集成（比如Azure OpenAI、AWS Bedrock）、但Prompt Injection、Tool Misuse等安全隐患仍然存在 | 安全性最强：专为企业级安全设计、有内置的安全机制（比如Prompt Guardrails、Tool Validation、Data Redaction、Role-Based Access Control）、支持企业级安全集成（比如SSO、SAML、OAuth2.0、Azure OpenAI、AWS Bedrock）、支持数据加密（传输中加密、存储中加密）、支持审计日志（所有操作都会被记录）、Prompt Injection、Tool Misuse、Data Leakage等安全隐患相对较少 | 安全性一般：因为是基于LangChain构建的、有相同的安全隐患、但不支持企业级安全集成 | 安全性较弱：因为代码执行工具（比如Python REPL）可以执行任意代码、容易导致安全漏洞（比如删除文件、窃取数据、安装恶意软件）、不支持企业级安全集成 |
2.3.2 ER实体关系 mermaid架构图
为了让你更直观地理解六款框架的核心实体之间的关系，我画了一个统一的Agent框架ER实体关系图（六款框架的核心实体都包含在这个图中，只是不同框架的实体名称和关系略有不同）：