这是我带团队把 Agent / RAG 从 Demo 推到生产过程中整理的一份决策清单，重点在选型、避坑和评估。
我是 Gavin，模酷科技（ModalCube）的主理人，全栈方向，这两年主要在带团队做 AI 产品落地——给客户做模型选型、Agent 编排、RAG 知识库这些事。
写这份东西的起因很简单：2025 年下半年开始，找我聊"想上个 AI"的客户突然变多，但十个里有八个开口就是"我想做个像 XX 那样的 Agent"，对底下的工程取舍基本没概念。聊多了我发现，大家踩的坑高度重复——选型拍脑袋、RAG 检索糊弄、上线了没法评估好坏、Demo 惊艳生产翻车。
所以把这些反复讲的东西落成文档，主要写给：想给业务接 AI 但不知道从哪下手的老板 / 产品，以及刚上手 Agent 的工程师。
- 一、先看清楚：这波到底是不是泡沫
- 二、框架选型横评（LangGraph / CrewAI / AutoGen / Dify / RAGFlow）
- 三、选型决策树：30 秒定位你该用哪个
- 四、RAG 实战：检索这一层做不好，全盘皆输
- 五、Eval：Day 1 就要建评估集，这是生死线
- 六、MCP：2025-26 的新赛道，资源很散
- 七、十个最常见的坑（附自查清单）
- 八、报价锚点：一个 AI 项目大概多少钱
- 九、怎么挑外包/技术合作方（避免被"蹭概念"的坑）
- 数据来源
- 贡献
- License
- 关于 & 服务
我不喜欢喊"AI 改变一切"，但有几个数我会拿给客户看，让他判断节奏：
| 指标 | 数据 | 出处 |
|---|---|---|
| 企业整合 AI Agent 的比例 | 2025 年 < 5%，Gartner 预测 2026 年底达 40% | Gartner |
| 全球 AI Agent 市场规模 | 约 109–118 亿美元 | 多家行业报告区间 |
| 复合增长率（CAGR） | 约 46%–50% | 多家行业报告区间 |
我的解读，去掉宣传水分：
- 40% 这个数，是"整合了"不是"用好了"。 大多数企业 2026 年的状态会是"接了个 Agent 进来、在跑、但价值待验证"。真正把准确率/效率做出可量化收益的，是少数。这恰恰是机会窗口。
- 别被"全员替代"忽悠。 现阶段能稳定落地、ROI 算得清的，集中在几个场景：客服/工单、知识库问答（内部 wiki、产品文档、法规手册）、文档处理（合同/报告抽取）、研发提效。其它的，先做 PoC 验证再说。
- 节奏建议：先用一个小而真的场景跑通"检索 → 生成 → 评估 → 上线监控"这条链路，把方法论建起来，再横向铺。一上来就想做"什么都能干的超级 Agent"，基本必翻。
这五个是我现在做项目最常对比的。先说结论：没有最好的框架，只有匹配你团队和场景的框架。 下面都是实打实用下来的体感。
| 框架 | 一句话定位 | 上手难度 | 控制力 | 最适合 | 我踩到的短板 |
|---|---|---|---|---|---|
| LangGraph | 用「图/状态机」编排复杂 Agent 流程 | 偏高（要写代码） | 强 | 多步骤、有分支/循环/人审的复杂 Agent | 概念偏抽象，学习曲线陡；调试要花时间 |
| CrewAI | 多 Agent 角色协作（role-based） | 低 | 中 | 快速搭"多个角色分工"的 multi-agent | 抽象封得较死，想做精细控制会顶到天花板 |
| AutoGen | 微软出品，多 Agent 对话范式 | 中 | 中 | 研究/原型、Agent 之间对话协作的实验 | 偏研究气质，生产化（稳定性/可观测）要自己补 |
| Dify | 可视化低代码，搭 RAG+Agent 应用平台 | 很低 | 中低 | 非深度定制、想快速出活、给业务自助搭 | 深度定制有边界；复杂逻辑迟早要"跳出可视化" |
| RAGFlow | RAG 专精，文档理解/版面解析强 | 中 | 中（聚焦 RAG） | 文档密集型知识库（合同、报告、扫描件） | 不是通用 Agent 框架，编排能力不是它的主场 |
社区热度参考：Dify 约 14 万 star、RAGFlow 约 8 万 star（GitHub，2026-06 量级），这俩在国内中文场景的生态和文档都比较友好，是很多团队的起点。
我自己的取舍习惯：
- 要可控、要长期维护、逻辑复杂 → LangGraph。代码即文档，后面交接和迭代最省心。
- 多个角色分工、想快速出 multi-agent 原型 → CrewAI 起手，验证完再决定要不要换更可控的底座。
- 业务方想自己搭、IT 想统一管控 → Dify。把它当"AI 应用的低代码平台"，特别适合先把场景跑起来。
- 核心痛点是"文档读不准"（PDF、表格、扫描件、版面乱）→ RAGFlow 的解析能力是加分项。
- AutoGen 我更多用在内部做实验、验证多 Agent 协作思路，落生产会再包一层。
一个常被忽略的点：框架是可以换的，被锁死的往往不是框架，是数据和评估方法。 所以下面两章（RAG 检索 + Eval）才是真正决定成败的地方。
你现在最缺的是什么？
│
├─ 我要快速给业务跑个能用的 Demo，团队不强
│ └─→ Dify（可视化先跑起来，验证场景价值）
│
├─ 我的核心痛点是"文档/资料读不准、检索不对"
│ └─→ RAGFlow 做检索层 (+ 上层用 LangGraph/Dify 编排)
│
├─ 我要做多步骤、带分支/循环/人工审核的复杂 Agent
│ └─→ LangGraph（控制力换学习成本，值）
│
├─ 我想搭"多个角色分工协作"的 multi-agent，且要快
│ └─→ CrewAI 起步
│
└─ 我在做研究/探索多 Agent 协作范式
└─→ AutoGen
⚠️ 不管选哪个，下面两件事都不能省：
1) 混合检索 + Reranker（见第四章）
2) Day 1 就建 Eval 集（见第五章）
90% 的"AI 答得不准"，根因不在大模型，在检索召回的内容根本就不对。喂给模型的料是错的，再强的模型也救不回来。下面是我做 RAG 知识库的五个必做项，按重要性排：
只用向量检索（语义相似）有个致命问题：精确匹配的词、专有名词、型号、编号经常召不回来。 比如用户问"X-200 的保修条款"，向量可能给你一堆"语义相近但型号不对"的段落。
正确做法是 向量检索 + 关键词检索（BM25）混合，再把两路结果融合（常用 RRF，Reciprocal Rank Fusion）。语义和精确匹配各补各的短板。
- 关键词侧：Elasticsearch / OpenSearch 自带 BM25。
- 向量侧：Milvus、Qdrant、或直接用 Postgres 的 pgvector（量不大时这个最省事，一个库搞定）。
混合检索召回 Top 20-50 之后，用一个 Reranker 模型把最相关的重新排到前面，再取 Top 3-5 喂给大模型。这一步通常是"花最小力气、提升最明显"的优化。
- 开源：BAAI bge-reranker（FlagEmbedding），中文效果不错、能私有化。
- 商用 API：Cohere Rerank，省事但要走外网/付费。
每条回答必须能回链到原文出处（哪个文档、哪一段）。两个原因：一是用户能核对、信任度直接上一个台阶；二是出了错你能定位是检索错了还是生成错了。没有引用追溯的 RAG，本质是个不可调试的黑盒，我一般不让它上线。
知识库是活的——文档天天在改。一定要支持增量更新（只重新嵌入变化的部分），并处理好删除/版本问题。我见过不少项目一开始图省事每次全量重建，数据一多就卡死、成本也失控。
检索准不准、答得好不好，不能靠人肉拍脑袋说"感觉还行"。要有量化指标。这是最被忽略、也最致命的一环。
RAG 自查表（每条都该是"是"）
- 用了混合检索（向量 + BM25），不是只有向量？
- 召回后过了一道 Reranker？
- 每条回答都能点开看到原文出处？
- 文档更新走的是增量，不是全量重建？
- 切块（chunking）策略是按语义/结构切的，不是粗暴按字数硬切？
- 有一套固定的评估集能跑分，不是靠"试几条感觉一下"？
这一章我想重点说，因为它是最值钱、又最常被跳过的。
我带项目有个铁规矩：Eval 集在 Day 1 就建，不是上线前才补。 原因很简单——没有评估集，你所有的"优化"都是盲目的。换个 prompt、换个 reranker、调个 chunk 大小，到底变好还是变坏？没有量化基准，你只能"感觉"，而感觉在 AI 项目里基本等于赌博。
怎么建：
- 早期靠人工攒：和业务一起，挑 30-100 条真实高频问题，写上"标准答案 / 期望召回的文档"。这步偷不得懒，质量比数量重要。
- 持续从线上捞：上线后把真实用户问题、踩雷的 bad case 不断回灌进评估集，让它越来越像真实分布。
- 每次改动都跑分：任何改动（模型、prompt、检索参数）先对评估集跑一遍，看分数升降再决定上不上。
测什么：
| 维度 | 看什么 |
|---|---|
| 检索质量 | 该召回的文档有没有被召回（命中率 / recall） |
| 答案忠实度 | 回答有没有"编"、是不是严格基于检索到的内容（faithfulness，防幻觉） |
| 答案相关性 | 答得切不切题 |
| 引用正确性 | 标的出处是不是真支撑这句话 |
趁手的开源工具：
- Ragas — RAG 评估几乎是事实标准，忠实度/相关性这些指标开箱即用。
- DeepEval — 像写单测一样写 LLM 测试，能塞进 CI。
- promptfoo — 对比不同 prompt / 模型的输出，做选型实验很顺手。
上线后还要继续： 加监控和可观测（每次调用的检索结果、token、延迟、命中的文档、用户反馈都要能查），这样线上出问题才定位得到，而不是干瞪眼。
一句话记住：Demo 看气质，生产看 Eval。 区分"玩具"和"产品"的，就是有没有这套评估体系。
MCP（Model Context Protocol）是 2025-26 起来的新东西——简单说，它想做"AI 应用连接外部工具/数据源的标准接口"，让 Agent 接外部能力时不用每个都重写一套对接。
我的态度：值得关注，但别上头。 现在这块生态还很散、资源零碎，标准也还在演进。我的建议：
- 内部探索、做工具集成实验 → 可以试，能省一些重复对接的活。
- 关键生产链路 → 先观望，等生态再稳一点，别拿核心业务当小白鼠。
入门看官方就够：modelcontextprotocol.io、GitHub 组织。
按我见到的频率排，前几个几乎人人中招：
| # | 坑 | 怎么破 |
|---|---|---|
| 1 | Demo 惊艳，生产翻车 | 因为没 Eval。Day 1 建评估集，按真实分布测。 |
| 2 | 只用向量检索 | 上混合检索（向量 + BM25）+ Reranker。 |
| 3 | 没有引用追溯 | 每条回答必须能回链原文，否则不可调试。 |
| 4 | 切块太粗暴 | 按语义/文档结构切，别只按固定字数硬切。 |
| 5 | 拿大模型当万能 | 检索喂错料，模型再强也白搭。先修检索。 |
| 6 | 没监控/可观测 | 上线即"黑盒"，出错无从查起。从 Day 1 埋点。 |
| 7 | 盲目追最大/最贵的模型 | 先用评估集选"够用且便宜"的，成本差几十倍。 |
| 8 | 想一步到位做超级 Agent | 先做一个小而真的场景跑通整个流程，再扩。 |
| 9 | 知识库全量重建 | 改成增量更新，否则数据一多就崩。 |
| 10 | 被"蹭概念"的供应商带偏 | 看具名客户 + 具体数字，不看 PPT（见下章）。 |
上线前自查清单（打印出来逐条过）
- 有 30+ 条真实问题组成的 Eval 集，且能一键跑分
- 检索是"混合 + Reranker"，不是裸向量
- 每个回答可回链原文出处
- 有幻觉/忠实度指标在盯着
- 有线上监控（检索内容、延迟、成本、用户反馈可查）
- 知识库支持增量更新
- 模型是"按评估选出来的够用款"，不是"听说最强的那款"
- 有明确的 bad case 回灌机制
被问最多的问题。给个市场区间锚点（不是报价单，具体看范围），让你心里有谱、也好识别离谱报价：
| 阶段 | 典型范围 | 周期 | 你应该得到什么 |
|---|---|---|---|
| PoC 验证 | 约 1–3 万 | 2–4 周 | 一个能验证"这事 AI 到底行不行"的可跑原型 + 评估数据 |
| 落地产品 | 约 3–8 万 | 2–3 个月 | 能上线给真实用户用的产品，带监控和评估体系 |
| 复杂集成 / 私有化 | 按范围另议 | 看范围 | 私有部署、数据不出域、深度集成、SLA（大客户场景，具体聊） |
几个提醒：
- 强烈建议先做 PoC。花一两万块两三周，验证"准确率/效率到底能到多少"，比上来就砸大项目理性得多。AI 项目最大的风险是"做出来发现达不到预期"，PoC 就是来排这个雷的。
- 报价里要包含 Eval 和监控。如果一份方案只字不提"怎么评估好坏、上线怎么监控"，这价是虚的——后期填坑的钱会更多。
- 代码和数据归属写进合同。这是底线，下一章细说。
AI 火了之后，蹭概念的供应商特别多。PPT 一个比一个炫，真到交付就露馅。我给个筛选法，照着问，能筛掉一大半：
该信的信号：
- ✅ 拿得出具名客户 + 具体数字（"给 XX 做的知识库，准确率从 60% 提到 90%""工单处理效率提升 X 倍"）。能说出名字和数字的，才是真干过。
- ✅ 主动跟你聊 Eval 和监控，而不是只吹模型多强。
- ✅ 愿意先做 PoC 验证，而不是逼你一次性签大单。
- ✅ 代码 100% 归你、托管在你自己的 Git，不锁平台。
- ✅ 报价透明，范围、周期、交付物写清楚。
该警惕的信号：
⚠️ 全程只有概念和 Demo 视频，问案例就含糊其辞。⚠️ 闭口不谈怎么评估效果、上线怎么维护。⚠️ 代码不给、部署在它的平台、想迁走要加钱——典型的平台锁定。⚠️ 报价拍脑袋、不肯拆解。
- 企业 AI Agent 整合比例（2025 < 5% → 2026 底 40% 预测）：Gartner。
- 全球 AI Agent 市场规模（约 109–118 亿美元）、CAGR（约 46%–50%）：多家行业市场报告区间，数字按公开区间取值。
- 框架 star 数（Dify ≈ 14 万、RAGFlow ≈ 8 万）：GitHub，2026-06 量级，会随时间变动。
- 工具/框架链接均为各项目官方 GitHub / 官网。
发现不对的，欢迎提 PR 纠正。
这份清单想长期维护，欢迎 PR：
- 框架/工具有新的、或我写错了 → 直接改表格，附上官方链接。
- 你踩过的坑、好用的 Eval 实践 → 加进对应章节。
- star 数等数据过时 → 帮忙更新。
唯一要求：给真实可用的官方链接，别塞推广软文。 拿不准的工具，宁可不列也别编。
CC0-1.0 — 公共领域贡献。随便抄、随便改、随便用，不用署名。
模酷科技（ModalCube）是广州一家做软件交付的公司，Gavin 主理，全栈开发，口号"AI 工程，说到做到"，已交付 50+ 项目。
AI 这块我们专门做产品落地：模型选型 & Eval、Agent 编排、RAG 知识库——而且坚持 Day 1 就建 Eval 集、上线带监控和可观测，本文里讲的那套方法论，就是我们自己在用的。除了 AI，我们也做小程序、外贸站/工厂站、企业官网、SaaS、全栈开发（Next.js · React · Cloudflare · Postgres）。
为什么有人选我们：
- 透明定价：项目按范围报价，PoC / 创业级 / 私有化都有清晰区间，不玩猜价游戏。
- 代码 100% 归你，托管在你自己的 Git，不锁平台。
- Next.js 高性能，手机端 PageSpeed 90+。
- 上线后 30 天免费维护，可选 SLA。
- 企业法人主体担责，固定团队、直接对接核心工程师，不是接力赛踢皮球。
想做 AI 落地、或只是想聊聊你那个场景到底值不值得做 PoC，都可以找我：
📧 xqi@live.com · 💬 微信 gav1nq · 🌐 https://modalcube.com
 模酷科技·微信 |
 模酷科技·服务号 |