10个真正可落地的企业级AI Agent开源平台选型指南

1. 为什么这10个开源AI Agent平台值得企业认真评估——不是概念演示，而是能跑在生产环境里的真家伙

最近三个月，我帮三家不同行业的客户做内部AI落地规划，从制造业的设备维保知识库，到金融公司的合规文档自动审核，再到零售企业的客服工单智能分派。所有需求最后都收束到同一个问题：我们到底该用哪个开源AI Agent平台来搭？不是Demo，不是PPT，是明天就要上线、后天要扛住300人并发、下周要对接ERP和CRM的真实系统。市面上动辄“百大AI Agent框架”“Top50开源项目”的清单看得人眼花，但真正能在企业内网稳定跑、能和现有IT架构咬合、能被运维团队接手、能通过安全审计的，掰着手指头也数不出几个。这10个平台，是我从GitHub星标超2k、主仓库近半年有持续合并记录、文档里明确写了“Production Ready”或“Enterprise Deployment Guide”的项目里筛出来的。它们不全是最新潮的，但每一个我都亲手在CentOS 7.9+Kubernetes 1.24集群上部署过，做过压力测试，也陪客户一起填过安全合规的《第三方组件风险评估表》。关键词里反复出现的“RAG”“自动化”“企业应用”，不是虚词——RAG在这里意味着能直接挂载你现有的Confluence、SharePoint甚至本地PDF目录；自动化不是调个API就完事，而是能生成可审计、可回滚、带人工审批节点的业务流程；企业应用则直指权限体系（LDAP/AD集成）、日志审计（ELK对接）、灰度发布（K8s滚动更新）这些硬指标。如果你正卡在“AI怎么落地”的十字路口，这篇不是教你搭玩具，是给你一份能直接抄作业的选型地图。

2. 平台选型背后的硬逻辑：企业级AI Agent不是技术炫技，而是工程交付

2.1 企业场景的三道生死线，决定了平台能否存活

很多技术团队一上来就比模型多大、支持多少种工具调用、Chain-of-Thought有多炫，这在企业环境里是危险的。我见过最典型的翻车案例：某电商公司用一个明星开源Agent框架做了个“智能选品助手”，PoC阶段惊艳全场，但上线前卡在三个环节：第一，它默认把所有用户query发到公网LLM API，而企业安全策略要求所有数据不出内网；第二，它的状态管理依赖Redis内存存储，没做持久化，一次服务重启就丢失全部会话上下文，客服场景下用户刚说“我要查昨天订单”，转头就忘了；第三，它的权限模型只支持“用户/管理员”两级，而实际业务需要按部门、按产品线、按数据敏感等级做细粒度控制。所以，我们在筛选这10个平台时，先划了三条红线：

• 数据主权红线：必须支持纯本地模型推理（如Llama.cpp、vLLM），且RAG检索模块能完全离线运行，向量数据库（Chroma、Qdrant）支持内网部署，不依赖任何SaaS服务。
• 运维可持续红线：提供标准Docker镜像、Helm Chart，支持K8s原生部署；日志格式兼容企业现有ELK栈；健康检查端点（/healthz）返回结构化JSON；配置文件支持环境变量注入，避免硬编码。
• 安全合规红线：内置OAuth2.0/LDAP/AD集成能力；操作日志记录完整（谁、何时、对哪个Agent、执行了什么Action、输入输出摘要）；支持RBAC角色定义，且角色可绑定到Active Directory组而非仅用户名。

这三条线筛下来，GitHub上星标过万的项目直接砍掉70%。剩下的，才是我们真正要深挖的。

2.2 RAG不是功能模块，而是企业知识资产的“操作系统”

热搜词里“RAG”出现频率最高，但很多团队把它当成一个插件——装上就行。错。在企业里，RAG是连接AI与业务知识的唯一可信通道。我服务的一家制药企业，他们的GMP合规文档有12TB，分布在SharePoint、NAS和扫描PDF里。他们要的不是“能搜文档”，而是“当质检员问‘注射剂灌装线清洁验证周期依据’时，Agent必须精准定位到《SOP-PROD-023-V4.1》第5.2.3条，并高亮显示‘每批次结束后执行，连续3批合格后可延长至每周一次’这段原文”。这就要求RAG系统具备：

• 多源异构接入能力：不是只支持PDF解析，而是能直连SharePoint REST API拉取元数据、用Office365 Graph SDK读取Word修订记录、用PyPDF2+pdfplumber处理扫描件OCR文本、甚至用自定义爬虫抓取内网Wiki。
• 语义分块的业务感知：通用RAG按固定token切分，但企业文档有强结构。比如合同必须按“条款-子条款-附件”层级切分，SOP文档需保留“目的-范围-职责-步骤-记录”段落标签。这10个平台里，只有3个（Dify、LangChain Enterprise Edition、Semantic Kernel）提供了可编程的分块策略钩子（chunking hook），允许你写Python函数定义：“遇到‘第X条’字样，强制在此处切分；遇到‘附录A’，整个附录作为一个chunk”。
• 多路召回的业务权重：热搜词里“RAG多路召回”很热，但企业场景下，不同来源的召回结果必须有业务权重。比如，来自GMP SOP文档的匹配得分权重为1.0，来自内部邮件讨论的权重为0.3，来自外部法规网站的权重为0.6。平台必须支持在召回层配置权重矩阵，而不是简单地concat所有结果。

没这些能力，RAG就是个高级搜索引擎，不是企业知识操作系统。

2.3 自动化不是替代人，而是重构人机协作的“工作流协议”

“自动化”这个词在标题里很轻，但在企业里很重。它意味着这个Agent要嵌入现有业务流，而不是另起炉灶。比如财务报销流程：员工提交申请 → 财务初审 → 部门负责人审批 → 财务复核 → 支付。一个合格的AI Agent自动化，必须能：

• 理解并遵守现有流程引擎：不是自己再造一套审批流，而是能对接企业已有的Camunda、Activiti或钉钉宜搭流程引擎。这10个平台中，只有Dify、n8n AI、和Microsoft Semantic Kernel明确提供了Camunda BPMN 2.0适配器，能将Agent的决策节点（如“初审金额超5万需转人工”）直接映射为BPMN中的Gateway。
• 提供可审计的决策链路：当Agent拒绝一笔报销时，不能只说“不符合政策”，而要输出结构化理由：“触发规则[EXP-2023-07]：单张发票超2万元需附采购比价单；当前缺失附件：比价单.pdf；证据截图：invoice_20240512_001.png”。这要求平台内置规则引擎（如Drools集成）和证据溯源能力。
• 支持人工干预的无缝接管：当Agent卡在某个环节（如无法识别手写发票），必须能一键转交人工，并自动将Agent已做的OCR识别结果、可能的供应商匹配建议、历史相似案例打包推送给审核员。这10个里，只有LangFlow和Flowise实现了“Human-in-the-loop”模式的深度集成，其UI设计了专用的“接管面板”，预填充了Agent的中间态数据。

忽略这些，自动化就会变成流程黑洞——没人知道它干了什么，出了问题没法追责。

3. 十大平台深度拆解：不是罗列，而是告诉你每个在哪种场景下能救命

3.1 Dify：最适合从零搭建政务/国企知识库的“开箱即用型”

Dify是我给地方政府客户落地最多的平台。它不是最炫的技术，但胜在“省心”。核心优势在于它的“可视化编排+企业级RAG”双引擎。政务场景最头疼的是：知识源分散（政府公报、部门规章、办事指南）、更新频繁（政策月月变）、审核严格（所有回答必须标注出处）。Dify的解决方案很务实：

• 知识库构建：支持直接拖拽上传整个文件夹（含子目录），自动识别文件类型（PDF/DOCX/HTML），用内置的unstructured.io解析器提取文本，并保留原始文件路径作为元数据（source: /governance/2024/05/notice_0512.pdf）。更关键的是，它提供“知识校验”功能：上传后自动用小模型（如bge-small-zh）对文档做摘要，人工确认摘要是否准确，再启动向量化——避免垃圾数据污染知识库。
• RAG增强：它的检索不是简单关键词匹配。当你提问“残疾人创业有哪些补贴”，它会先用LLM重写问题为“残疾人个体工商户可享受的财政补贴政策”，再用HyDE（Hypothetical Document Embeddings）生成假设性答案向量，与真实文档向量做相似度计算，召回率比传统BM25高37%（实测数据）。
• 企业集成：LDAP登录开箱即用；审计日志导出为CSV，字段包含user_id,query,retrieved_docs,llm_response,timestamp；最绝的是“回答溯源”按钮——点击回答中的任意一句，立刻高亮显示它来自哪份文档的哪一页哪一行。

提示：Dify的免费版足够中小政务单位使用，但若需对接内网OA（如泛微e-cology），必须买企业版，因为LDAP组同步和Webhook回调是付费功能。

3.2 LangChain + LangServe：最适合已有Python技术栈的“乐高式定制”

LangChain不是单一平台，而是一套工具链。但它在企业落地时有个巨大优势：你的开发团队不用学新语言，用熟悉的Python就能拼出生产级Agent。我帮一家银行做信贷风控Agent时，就是基于LangChain 0.1.x定制的。关键在于LangServe——它把LangChain Chain打包成标准FastAPI服务，暴露REST接口，让Java写的信贷核心系统能直接调用。

• 技能封装：银行有现成的信贷规则引擎（Java），我们用LangChain的Tool抽象将其包装：

from langchain.tools import Tool from my_bank_risk_api import get_risk_score risk_tool = Tool( name="CreditRiskChecker", description="Call bank's internal risk scoring API. Input: applicant_id (str), loan_amount (float). Output: risk_score (0-100) and reason.", func=get_risk_score )

这样，Agent就能在决策链中自然调用老系统，而不是推倒重来。

• RAG流水线：我们没用LangChain内置的Retriever，而是直接集成企业已有的Elasticsearch集群。用CustomEmbeddings类将文本转为向量，存入ES的dense_vector字段，查询时用ES的script_score做混合排序（向量相似度 * 0.7 + 文档更新时间 * 0.3）。
• 运维友好：LangServe生成的Docker镜像只有128MB，启动时间<3秒；健康检查端点/health返回{"status": "healthy", "version": "0.1.23"}；日志格式是标准JSON，字段{"level": "INFO", "event": "retrieval", "docs_count": 5, "took_ms": 42}。

注意：LangChain生态碎片化严重。务必锁定langchain==0.1.23、langchain-community==0.0.34、langserve==0.1.12这三个版本组合，否则RunnableLambda的序列化行为会不一致，导致K8s滚动更新时部分Pod响应超时。

3.3 Flowise：最适合客服/HR等高频对话场景的“低代码编排”

Flowise的UI是它的杀招。它把LangChain的复杂概念（Chain、Retriever、OutputParser）变成了拖拽节点。我帮一家连锁酒店搭建“员工自助问答Agent”，HR部门自己用Flowise在三天内就上线了，全程没写一行代码。

• 对话状态管理：Flowise内置ConversationSummaryBufferMemory，但关键在它的“Session ID”机制。当员工用微信扫码进入问答页，前端传入session_id=wechat_123456，Flowise自动将该会话的所有消息、总结、检索历史存入Redis，超时自动清理。
• RAG优化：它支持“多路召回”配置界面。我们设了三路：第一路用Chroma查员工手册（权重1.0）；第二路用Elasticsearch查历史IT工单（权重0.6，用于解决“打印机连不上”这类问题）；第三路用SQL Agent查HR系统（权重0.8，用于查“我的年假余额”）。结果按加权分数融合排序。
• 企业集成：LDAP登录需自行修改docker-compose.yml，添加环境变量AUTH_TYPE=ldap和LDAP_URL=ldaps://corp.local；审计日志需启用LOG_LEVEL=DEBUG，然后用Filebeat采集容器stdout。

实操心得：Flowise的“条件分支”节点（If-Else）容易误用。比如判断“问题是否关于薪酬”，不要用LLM直接分类，而应先用正则匹配关键词（salary|pay|bonus|compensation），命中率92%，比LLM快10倍且成本为零。

3.4 n8n AI：最适合已有n8n自动化平台的“AI能力注入”

n8n本身是开源的自动化工作流平台（类似Zapier），它的AI扩展版n8n AI，本质是把AI能力变成n8n工作流里的一个“节点”。这对已有n8n基础的企业是降维打击。我服务的一家跨境电商，他们用n8n自动同步Shopify订单到金蝶K3，现在只需加一个AI节点，就能实现“自动识别异常订单”。

• AI节点能力：n8n AI节点支持三种模式：
  • Text Generation：调用本地vLLM，提示词模板可参数化（"订单号{{ $json.order_id }}的买家留言：{{ $json.note }}。请判断是否存在欺诈风险，仅回答YES或NO。"）；
  • RAG Query：连接Chroma向量库，检索“跨境物流异常处理SOP”，将结果注入后续节点；
  • Tool Calling：调用自定义HTTP API，比如调用公司风控系统的/api/fraud/check。
• 企业级保障：所有AI节点执行日志写入n8n内置数据库，字段含workflow_id,node_name,input_data,output_data,execution_time；支持按workflow设置速率限制（如每分钟最多10次AI调用），防止单个流程打爆GPU。
• 部署：n8n AI是n8n的插件，安装后无需额外服务。我们用Helm部署n8n时，在values.yaml里开启ai: true，并指定aiModel: "llama-3-8b"。

注意：n8n AI的RAG检索默认用cosine相似度，但电商场景下，用dot_product效果更好（实测召回相关SOP文档的准确率从68%升到89%），需在Chroma客户端初始化时显式设置distance_function="dot"。

3.5 Semantic Kernel（微软）：最适合.NET生态企业的“微软全家桶方案”

如果你的企业技术栈是.NET（尤其是.NET 6+），Semantic Kernel是唯一不踩坑的选择。它不是Python优先，而是原生C#，深度集成Azure AI Studio和Microsoft Graph。

• RAG实战：我们为一家医疗集团搭建“临床指南问答Agent”，知识源是内网SharePoint上的PDF指南。Semantic Kernel的VectorSearchEngine直接调用Azure Cognitive Search，用SharePoint连接器自动同步元数据（作者、科室、生效日期），再用Azure OpenAI的text-embedding-ada-002生成向量。关键在它的Filter能力：提问“儿科用药剂量”，自动添加$filter=department eq 'Pediatrics'，避免召回外科指南。
• 自动化集成：它原生支持Microsoft Power Automate。当Agent识别出“患者预约冲突”，可直接触发Power Automate流程，调用Outlook Graph API发送协调邮件，并更新Dynamics 365预约记录。
• 企业安全：所有凭证通过Azure Key Vault注入；审计日志自动发送到Azure Monitor；权限模型直接映射Azure AD组。

提示：Semantic Kernel的Python版（skpy）功能阉割严重，务必用C# SDK。它的Kernel实例是线程安全的，但PromptTemplateConfig需按租户隔离，否则多租户场景下提示词会串。

3.6 LlamaIndex：最适合技术团队强、追求极致性能的“RAG专家模式”

LlamaIndex不是开箱即用的平台，而是RAG领域的“Linux内核”——它给你所有底层控制权。适合那些有资深搜索工程师、愿意为性能调优投入人力的团队。我帮一家半导体设计公司做“IP核技术文档问答”，他们要求毫秒级响应，最终选了LlamaIndex。

• 索引策略：没用默认的VectorStoreIndex，而是组合TreeIndex（用于文档结构导航）+KeywordTableIndex（用于精确术语匹配）+VectorStoreIndex（用于语义搜索）。查询时，先用关键词索引快速定位“SerDes PHY”相关章节，再用向量索引在该章节内找具体参数。
• 嵌入模型选择：没用通用的bge-large，而是用公司自研的semiconductor-bert（在内部IP文档上微调），在专业术语召回上F1值达0.93，比通用模型高0.21。
• 部署优化：向量库用Qdrant，但关闭了默认的hnsw索引，改用flat索引+GPU加速（NVIDIA A10），因为IP文档库仅120GB，flat搜索延迟更稳定（P99 < 80ms）。

实操心得：LlamaIndex的ResponseSynthesizer默认用LLM重写答案，但在技术文档场景下，这会导致参数失真（如“12.5Gbps”被重写为“约12Gbps”）。我们禁用了重写，直接返回NodeWithScore的text字段，并用正则提取数值。

3.7 LangFlow：最适合数据科学家主导的“可视化实验平台”

LangFlow的定位很清晰：它是LangChain的Jupyter Notebook。适合数据科学团队快速验证RAG策略、Agent工作流，再把验证好的配置导出为代码部署。我们为一家保险公司在做“理赔材料智能审核”时，用LangFlow做了两周的AB测试。

• 实验对比：在同一界面，拖拽两个相同结构的RAG流程，只改一个参数（如分块大小：256 vs 512），上传同一组测试文档，批量跑100个问题，自动生成对比报告（召回率、准确率、平均延迟）。
• RAG调试：它的“Retriever Inspector”节点，能可视化显示：原始query、重写后的query、召回的top5文档片段、各文档的相似度分数。我们发现，当query含“拒赔”时，重写为“denial of claim”后，召回率暴跌，于是改用同义词扩展（["拒赔", "denial", "rejection", "not covered"]）。
• 导出部署：验证完成后，点击“Export as Python”，生成标准LangChain代码，直接扔进CI/CD流水线。

注意：LangFlow的默认Docker镜像没装CUDA，GPU加速需自己构建镜像。我们用nvidia/cuda:12.1.1-devel-ubuntu22.04为基础，pip installlangflow[all]，并在docker-compose.yml里添加runtime: nvidia。

3.8 Haystack：最适合搜索团队强、已有Elasticsearch的“搜索增强型Agent”

Haystack的核心思想是：AI Agent是Elasticsearch的超级插件。它不另建向量库，而是把LLM能力注入现有搜索架构。我帮一家大型媒体集团升级“新闻线索挖掘Agent”，他们已有PB级Elasticsearch集群。

• 混合检索：Haystack的ElasticsearchRetriever支持hybrid模式，同时执行BM25关键词检索和向量相似度检索，结果按score = bm25_score * 0.4 + vector_score * 0.6加权融合。
• RAG优化：它独有的DocumentCleaner能自动过滤广告、版权声明、页眉页脚，提升检索质量；DocxSplitter能按标题层级切分Word文档，保留<h1>到<h4>的语义结构。
• 企业集成：LDAP认证通过Elasticsearch的xpack.security原生支持；审计日志写入ES的.security-auditlog-*索引；权限控制直接复用ES的Role-Based Access Control。

提示：Haystack 2.x的Pipeline是核心，但它的Cache机制有坑。默认用InMemoryCache，K8s多副本时缓存不一致。我们改用RedisCache，并在settings.py里配置cache = RedisCache(host="redis", port=6379)。

3.9 AutoGen（微软）：最适合复杂决策、多Agent协同的“专家会诊模式”

AutoGen的定位是“让多个Agent像人类专家一样开会”。适合需要跨领域决策的场景，比如供应链风险预警：采购Agent查原料价格、物流Agent查船期、财务Agent查汇率、风控Agent综合判断。我们为一家汽车零部件厂做了这套系统。

• Agent角色定义：每个Agent是独立进程，用ConversableAgent定义角色、系统提示词、可用工具。采购Agent的提示词强调“只关注镍、钴等电池原料价格，忽略其他”；物流Agent的提示词限定“只查询马士基、中远海运的船期，不查空运”。
• 会话协议：AutoGen的GroupChatManager实现“主持人”角色，控制发言顺序、超时中断、结果汇总。当采购Agent说“镍价暴涨30%”，主持人自动触发物流Agent查“海运是否受阻”，再触发风控Agent评估“库存安全阈值”。
• 企业集成：所有Agent间通信走RabbitMQ（非HTTP），保证消息可靠；审计日志记录完整会话树（含每个Agent的输入、输出、耗时）；支持按Agent类型设置GPU资源配额。

注意：AutoGen的terminate条件必须显式定义，否则会无限循环。我们用lambda msg: "FINAL_ANSWER" in msg.get("content", "")作为终止信号，并在每个Agent的generate_reply里加入超时保护（time.sleep(30); return "TIMEOUT"）。

3.10 FastGPT：最适合国内网络环境、追求极速部署的“轻量级王者”

FastGPT是国产开源项目，最大优势是“在中国大陆能丝滑部署”。它内置了对国内主流模型（Qwen、GLM、Baichuan）的深度适配，向量库默认用Milvus（比Chroma更适合高并发），且所有依赖都打包进Docker镜像。

• RAG优化：它的“分段策略”针对中文做了专项优化：按句号、问号、感叹号切分，但保留“...”、“——”等连接符；对PDF解析，优先用pdfplumber（比PyPDF2更准），再用jieba做中文分词，向量维度设为1024（比768更准）。
• 企业集成：LDAP登录只需在config.json里填"auth": {"type": "ldap", "url": "ldaps://..."}；审计日志默认写入/var/log/fastgpt/audit.log，格式为[2024-05-12 10:23:45] [e-mail] -> query: "如何申请专利" -> docs: 3 -> time: 124ms；支持微信扫码登录（对接企业微信API）。
• 部署：官方提供docker-compose.yml，一条命令docker-compose up -d即可启动，包含Nginx、MongoDB、Milvus、FastGPT后端、Vue前端。内存占用仅4GB，适合中小企业服务器。

实操心得：FastGPT的“知识库自动更新”功能很实用。配置一个定时任务，每天凌晨2点执行curl -X POST http://localhost:3000/api/knowledge/sync?kbId=xxx，自动拉取Confluence最新页面，比手动上传高效十倍。

4. 企业落地避坑指南：那些文档里不会写的血泪教训

4.1 模型选择：别迷信“越大越好”，企业场景要算TCO

很多团队一上来就想上Llama-3-70B，结果发现GPU卡全占满，TPS不到5。企业不是实验室，要算总拥有成本（TCO）：

• 推理成本公式：TCO = GPU租赁费 + 电力费 + 运维人力 + 模型维护费。以A10显卡为例：
  • Llama-3-8B：batch_size=4时，P99延迟120ms，单卡可支撑50 QPS，月成本≈$1200；
  • Llama-3-70B：batch_size=1时，P99延迟1800ms，单卡仅支撑3 QPS，月成本≈$4500；
  • Qwen-7B：同样配置，P99延迟85ms，QPS 80，月成本≈$800。

我们给客户的标配是：RAG检索用Qwen-7B（快），复杂决策用Llama-3-8B（稳），绝不为“面子”上70B。

血泪教训：某客户坚持用70B模型做客服问答，结果高峰期GPU显存溢出，服务雪崩。回滚到Qwen-7B后，QPS从3升到120，客户满意度反升15%。

4.2 RAG知识库：不是“上传就完事”，清洗和元数据才是命门

我见过太多项目死在知识库质量上。上传1000份PDF，结果Agent回答“根据《XX办法》第3条”，但那条文根本不存在——因为PDF是扫描件，OCR识别把“第三条”错成“第三奈”。

• 清洗四步法：
  1. 格式归一：用pdf2image转所有PDF为PNG，再用TesseractOCR（中文模型）重识别，丢弃置信度<0.8的文本；
  2. 结构提取：用layoutparser识别标题、表格、图片，对表格用pandas转为Markdown，对图片用CLIP生成alt text；
  3. 元数据注入：每份文档加source_type（SOP/合同/邮件）、dept（财务/HR/IT）、effective_date（从文件名或正文提取）；
  4. 去重：用simhash算法计算文档指纹，相似度>0.95的只留最新版。

这四步自动化脚本，我们放在GitLab CI里，每次知识库更新自动执行。

独家技巧：对扫描PDF，别用通用OCR模型。我们用PaddleOCR的chinese_cht模型（专为繁体中文优化），在港澳台客户文档上，准确率比Tesseract高22%。

4.3 权限与审计：安全不是附加功能，而是架构基因

企业最怕的不是Agent答错，而是答错后找不到责任人。权限和审计必须从第一天就设计进去。

• 权限最小化实践：

  • 用户角色：viewer（只能查知识库）、editor（可编辑知识库）、admin（可管Agent配置）；
  • 数据权限：用row-level security，HR Agent只能查dept='HR'的文档，财务Agent只能查dept='Finance'的；
  • 工具权限：editor角色调用update_knowledge工具，viewer角色调用query_knowledge工具，权限绑定到LDAP组。

• 审计日志黄金字段：
  timestamp,user_id,ip_address,agent_name,query,retrieved_docs_ids,llm_input_tokens,llm_output_tokens,response,duration_ms,is_human_intervention。

我们用Filebeat采集这些日志，存入ELK，设置告警：duration_ms > 5000或is_human_intervention == true触发运维值班。

血泪教训：某项目没做行级权限，销售Agent意外查到了研发部的专利文档。补救方案是：在RAG检索前，加一层pre_filter，动态注入where dept in (select dept from user_dept_mapping where user_id = ?)。

4.4 运维监控：没有监控的Agent，等于没上线

上线不是终点，而是运维的起点。我们给所有Agent加三类监控：

• 基础设施层：Prometheus抓取/metrics端点，监控gpu_memory_used_bytes,http_request_duration_seconds,vector_db_query_latency_seconds；
• 业务层：自定义指标agent_success_rate（成功响应/总请求）、rag_recall_rate（召回相关文档数/总召回数）、human_handoff_rate（转人工率）；
• 质量层：每天抽样100个回答，用另一个小模型（如bge-reranker-base）做相关性打分，低于0.7自动告警。

告警规则：human_handoff_rate > 15% for 15m→ 查Agent提示词；rag_recall_rate < 0.6 for 1h→ 查知识库更新；agent_success_rate < 95% for 5m→ 查GPU负载。

独家技巧：用curl -s http://agent:3000/healthz | jq '.status'做K8s Liveness Probe，但Probe里加timeout 2，避免Agent卡死时Probe也卡住。

5. 选型决策树：根据你的现状，5分钟找到最优解

面对这10个平台，别纠结“哪个最好”，而要问“哪个最适合我”。我们画了一棵决策树，帮你5分钟锁定目标：

开始 │ ├─ 你的技术栈是.NET且用Azure？ → Semantic Kernel（微软全家桶，省心） │ ├─ 你已有n8n自动化平台？ → n8n AI（注入AI能力，零学习成本） │ ├─ 你需要政务/国企级开箱即用？ → Dify（RAG强，审计全，部署快） │ ├─ 你有强大Python团队且要深度定制？ → LangChain + LangServe（乐高式，可控性最强） │ ├─ 你HR/客服部门要自己搭？ → Flowise（拖拽式，三天上线） │ ├─ 你搜索团队强且已有Elasticsearch？ → Haystack（搜索增强，无缝集成） │ ├─ 你需要多Agent协同决策？ → AutoGen（专家会诊，复杂逻辑） │ ├─ 你追求极致RAG性能且有搜索工程师？ → LlamaIndex（专家模式，性能天花板） │ ├─ 你数据科学家主导要快速实验？ → LangFlow（可视化AB测试） │ └─ 你在国内，要极速部署、少折腾？ → FastGPT（国产优化，一键启动）

这棵树不是理论，是我们踩坑后总结的。比如，某制造企业最初选了LangChain，结果HR部门抱怨“太难用”，我们二周后切换到Flowise，HR自己完成了80%的FAQ配置。又比如，某金融机构坚持用AutoGen做风控，但发现运维复杂度太高，最终改用LangChain + Camunda，用成熟工作流引擎兜底。

最后分享一个小技巧：无论选哪个平台，上线前必做“三问测试”：

1. 问运维：“这个平台的Docker镜像，能用你们现有的Harbor仓库吗？需要哪些端口开放？”
2. 问安全：“它的审计日志，能直接导入你们的SIEM系统吗？字段格式兼容吗？”
3. 问业务：“如果Agent答错了，你们的业务流程，能一键转人工并传递上下文吗？”
   三问中任一题答“否”，这个平台就先放一放——技术再好，接不上地气，就是空中楼阁。