1. 从知识库问答说起MaxKB 到底解决了什么问题先说一个我这几年的直观感受几乎每家企业都在喊“知识管理”但绝大多数公司的知识资产依然躺在共享文件夹、Wiki、企业微信群里找一份SOP要么翻半天文件夹要么问一圈人。真正把文档变成“能问答、能推理、能执行”的智能服务聊起来容易做起来全是坑。MaxKB 这个名字拆开看就是Max Knowledge Base中文名“麦知问”是飞致云旗下继 1Panel、JumpServer、DataEase 之后又一个开源项目。它解决的第一个核心问题就是把企业内部的知识库变成一个能自然语言问答的机器人——你丢给它一份员工手册、设备运维手册、产品FAQ它就能基于这些材料回答问题而不是靠大模型瞎编。第二个核心问题是在问答的基础上长出“手脚”通过工作流编排、工具调用、智能体串联变成一个能对接企业业务系统的智能体平台。一句话概括MaxKB 私有知识库 大模型引擎 可视化智能体编排。适合谁三类人最值得关注一是企业 IT/数字化部门想低成本落地一个内部问答机器人二是做 RAG 应用开发的工程师想找一个开箱即用、又不绑死云厂商的方案三是售前、实施、SaaS 产品经理需要快速给客户做 PoC 演示。这个项目最大的特点就是开箱即用。它不像 LangChain 那样给你一堆零件让你自己拼而是把“文档解析 - 切片 - 向量化 - 检索 - 大模型生成 - 引用溯源”整条 RAG 链路都做好你只要部署好服务、接一个大模型 API 或本地模型、上传文档最快半小时就能跑起来一个问答机器人。这跟我早期折腾 RAG 的经历形成了巨大反差——那时候用 Python 脚本自己写切片、调 embedding、拼 prompt一个原型搞了一周效果还不稳定。2. 技术底座与架构Spring Boot 为主干的多语言协作2.1 整体架构与模块划分很多第一次接触 MaxKB 的人会先问一个问题它是不是 Python 写的答案是否定的。MaxKB 的主服务基于JavaSpring Boot前端是Vue 3 Element Plus。这和市面上大多数 AI 应用Dify、FastGPT 基本都是 Python/TS 栈很不一样。为什么用 Java我猜最直接的原因是飞致云的技术积淀。他们家的 JumpServer堡垒机、DataEaseBI 工具都是 Java 技术栈团队对 Spring Boot 这套东西的驾驭能力极强包括后续要做企业级的功能组织架构对接、审计日志、高并发、权限体系Java 生态在传统企业 IT 环境里依然是最稳的选择。还有一个现实考量很多国企、金融机构的 IT 标准里Java 技术栈的接受度远比 Python 高交付的时候阻力小很多。从部署架构看MaxKB 的容器镜像包含三个核心组件主应用Java/Spring Boot负责 Web 服务、知识库管理、模型管理、应用编排、API 鉴权、权限管理。向量检索相关能力内置了向量数据库能力同时也支持配置外部向量库如 Elasticsearch 等文档经过 embedding 后写入向量库做相似度检索。前端静态资源打包在同一个镜像里通过 Nginx 直接提供服务。这种单体应用架构的好处是部署极其简单docker-compose 一把梭。坏处是如果你想单独扩展 embedding 服务或者把检索能力拆成微服务就没那么灵活。但考虑到 MaxKB 主要面向企业内部场景单体架构的“够用”和“省心”恰恰是最大优势。2.2 知识库引擎让文档变成可检索的知识切片知识库是 MaxKB 的核心资产。它的工作流大致是上传文档 - 文档解析 - 智能切片 - 向量化Embedding- 写入向量库 - 检索召回。先说文档解析。MaxKB 支持常见的文本类格式TXT、Markdown、PDF、DOCX、HTML、XLSX、CSV还支持 URL 采集输入一个网址抓取网页内容做知识。我在实际使用中PDF 的解析效果是个重点——很多开源工具的 PDF 解析遇到扫描件就废了MaxKB 对数字版 PDF 的效果比较好对扫描件需要 OCR 支持这一点在纯开源版本里尚不完善如果你是做纸质文档数字化建议先用外部 OCR 处理成文本再导入。切片是决定 RAG 效果最关键的一步也是最容易被忽视的一步。MaxKB 的切片参数里有几个关键配置切片最大长度默认值我记得是 400 字左右这个值决定了每个知识片段的上限字数。重叠长度相邻切片之间保留的重叠字数默认 100 字左右。切片分隔符选择可以选择“智能拆分”“按分隔符拆分”“自定义分隔符”。为什么要设重叠因为如果一刀切得太死一句话、一个表格被拦腰切断语义就断裂了。重叠能让上下文保持连续检索时更容易命中完整语义块。但重叠也不是越大越好重叠大意味着存储冗余多、检索噪音多一般来说按 400/100 的比例起步再根据实际效果调。向量化环节MaxKB 不自己做 embedding而是调用你所接入的大模型的 embedding 能力。这就带来一个细节如果你接的是 OpenAI 或通义千问的在线 API向量由云端算好返回如果你接的是本地 Ollama 部署的模型向量就在本地算。这个方案的好处是灵活坏处是你的向量质量完全取决于所选模型。这里有个实用建议国内企业做私有化部署embedding 模型我推荐用Ollama 上的 bge-m3 或 nomic-embed-text中文效果不错而且完全本地运行数据不出内网。2.3 模型接入在线 API 与本地离线模型双轨并行MaxKB 支持的模型接入方式非常宽这也是它在国内企业里受欢迎的原因之一。我简单列一下常见的几类模型渠道说明适用场景Ollama本地部署的 Llama、Qwen、DeepSeek 等数据敏感、无外网环境、成本敏感OpenAI 兼容接口所有提供 OpenAI 格式 API 的服务包括各类国产模型网关已有 API 网关的企业DeepSeek / 通义千问 / 智谱 / 讯飞星火 / Kimi国内主流云厂商模型快速接入、成本可控Azure OpenAI微软云托管的 OpenAI已有 Azure 订阅的外企/合资企业Gemini / Claude海外模型有海外 API 访问条件的场景为什么要强调本地模型这就回到热词里那个很典型的问题Llama 适合国内企业拿来搞知识库问答和私有化 Agent 部署吗我的观点是看场景。如果你企业对数据合规要求极高比如金融、政务、医院所有数据必须留在内网那就只能选本地模型。Llama 3.1 8B 经过量化后部署在 16G 显存的机器上跑中文知识库问答基本能看但效果跟 GPT-4o、DeepSeek-V3 这种级别的模型比有明显差距具体表现是生成内容比较“平”、复杂推理容易逻辑断裂。如果你只是做“文档问答”对生成要求不高Llama 8B 完全够用如果你要做多轮复杂 Agent 工作流建议用Qwen2.5 32B或者DeepSeek 蒸馏模型在本地跑中文能力会更扎实。别迷信 Llama。这是我在多个项目里对比测试后比较确定的结论。还有一类特殊选择通过兼容 OpenAI API 自建模型网关。很多企业已经用 vLLM、xinference 等工具内部部署了模型服务只要提供 OpenAI 风格的 base_url 和 api_keyMaxKB 就能直接对接。这一点非常关键意味着你之前沉淀的模型服务能力不会被浪费。2.4 从问答机器人到智能体平台应用编排的进化逻辑很多人以为 MaxKB 只是做知识库问答但从项目迭代轨迹看它在快速向“智能体平台”进化。从早期版本支持“简单应用”创建问答机器人绑定知识库到后来加入工作流编排再到引入智能体Agent创建、工具箱/函数调用、多应用编排这条路线非常清晰。拿企业实际情况来理解这件事一个纯粹的问答机器人能回答“报销流程是什么”但做不了什么一个智能体则能根据你的问题先查知识库获取制度依据再调用某个业务系统的 API 查询数据最后组织语言给出结果。MaxKB 的工作流编排就是干这个的在画布上拖拽节点把“知识库检索”“大模型对话”“API 请求”“条件分支”串起来让机器人从“会说”变成“会做”。这里也回应一下热词里那个“2026 是工业智能体从概念演示走向工程化落地的分水岭”的说法。我挺认同这个判断。概念演示阶段大家都在秀“AI 能看懂图纸、能对话”工程化落地阶段客户要的是“AI 能不能替我巡检、能不能自动生成工单、能不能跟现有系统打通”。MaxKB 这类平台的价值恰好是降低了工程化门槛——你不用从零写编排引擎不用处理模型调用的并发和容错只需关注业务逻辑本身。3. 实操落地从零搭建一个企业级问答智能体3.1 部署一条 docker 命令跑起来MaxKB 的安装部署在同类产品里算非常省心的。最简单的体验方式docker run -d --namemaxkb -p 8080:8080 -v ~/maxkb:/var/lib/postgresql/data 1panel/maxkb跑起来之后浏览器访问http://服务器IP:8080默认账号密码是admin / MaxKB123..登录后会强制要求改密码。这套体验跟 1Panel 一脉相承对运维非常友好。生产环境建议用 docker-compose 部署把 PostgreSQL、向量存储、主应用都编排好数据目录挂载到宿主机持久化。我一般会顺手做三件事改默认端口8080 太容易被扫描换一个高位端口或者前面套一层 Nginx 做 TLS 终止。设置定时备份MaxKB 的元数据、知识库配置都存 PostgreSQL 里用 crontab 定时pg_dump最稳妥。向量数据也要定期快照。限制外网暴露如果只是内网使用尽量别把 8080 端口映射到公网放内网反向代理就够。注意MaxKB 的老版本默认使用内置的 PostgreSQL 和向量存储。如果你要对接公司已有的 PostgreSQL 或者 Elasticsearch需要在配置文件里显式指定这个要提前规划好别等数据导入之后再迁移。3.2 创建知识库的完整流程与参数优化创建知识库是整个项目的核心竞争力所在我把完整的操作流程和调参心得拆开讲。第一步创建知识库时选择类型。MaxKB 的知识库分成通用型知识库自由上传文档切片和FAQ 知识库用标准问答对维护两种。FAQ 类型其实很好用适合客服话术、制度答疑这种“一个标准答案打天下”的场景维护成本低、命中率高。通用型则适合描述性内容多的文档。我一般是两类混用FAQ 库放高频标准问答文档库放操作手册、规章制度、说明书这类长篇材料。第二步上传文档并设置切片规则。这块的参数直接决定检索质量我踩过不少坑总结下经验切片长度 300-600 字是比较安全的区间。太短100 字会导致语义碎片化召回时上下文不足太长1000 字会导致向量表征被稀释检索精度下降且大模型输入 tokens 浪费。重叠长度设为切片长度的 15%-20%。比如切片 400 字重叠 80 字左右。重叠太少起不到承接作用重叠太多会显著增加切片数量拖慢导入和检索。Markdown 文档一定要开启按标题拆分。MaxKB 支持按 Markdown 标题结构智能切分这样每个切片基本对应一个章节主题语义完整度远高于纯按字数硬切。Convert 后的文档如果是 Word 排好版的也可以利用段落分隔符。第三步导入后用“预览”检查切片质量。我习惯随机抽 5-10 个切片检查重点看有没有上下文被切断的句子、表格被撕碎只留半截、代码块被拦腰截断。如果问题严重就改切片策略重新导入不要傻傻地直接上线。第四步关联模型并做效果测试。知识库建好后在应用里关联一个大模型随便问几个有代表性的问题观察召回内容是否覆盖答案要点。这一步不要急着调 prompt先看检索结果是否准确。3.3 提高检索命中率的实战技巧“怎么提高匹配度”是 MaxKB 社区里被问烂了的问题。我摸索下来影响检索质量的因素按优先级排序是文档本身的可检索性 切片方式 embedding 模型 检索参数 prompt 组织。先说文档质量。很多人忽略了这一点如果原始文档是 PPT 转的图片 PDF、是扫描件、是逻辑混乱的流水账后面怎么调参数都是白费。我在实际项目中会先对文档做“清洗”把多余的页眉页脚、水印、目录页删掉把繁体转简体表格尽量转为 Markdown 表格。这些脏数据清理完检索质量能提升一截。再说检索参数。MaxKB 的应用设置里有关键的参数可调检索模式向量检索 vs 全文检索 vs 混合检索。我强烈建议用混合检索如果版本支持向量找回语义相近的内容关键词检索精确命中专有名词。技术实现上向量检索擅长“语义相近但字面不同”的场景比如“怎么申请年假”和“休假制度”关键词检索则擅长精确匹配设备型号、工单编号、人名地名这种唯一性强的实体。召回数量默认可能只取前 4-5 条实际项目里我会适当调到 8-10 条让大模型有更多上下文可以参考。召回太少信息不足召回太多噪音增加大模型可能被无关内容带偏。相似度阈值低于阈值的切片会被过滤掉。这个值默认有时候偏保守导致召回为空。实践下来设0.3-0.4之间比较合适太高容易漏召回太低会让大模型参考无关联的内容。引用来源开关务必打开“引用来源”让回答后面带上引用的文档片段。这不仅是合规需要更重要的是用户可以自己检验 AI 回答的准确性——在企业落地时这个“可溯源”特性是赢得业务部门信任的关键。还有一招很实用把高频问答沉淀到 FAQ 库。跑一段时间之后把用户问得多、AI 答得差的问题整理成标准问答放进 FAQ 知识库。这种“运营驱动”的方式比反复调参数见效更快。我在一个售后场景里就是靠这个办法把机器人的首答命中率从 60% 左右拉到了 85% 以上。3.4 创建智能体应用从编排到发布接下来是重头戏——创建智能体应用。MaxKB 的应用类型现在不止一种我把它分为三个层次第一层简单问答应用。就绑定一个或多个知识库不做额外编排。适合快速交付的场景比如员工手册问答、产品 FAQ。第二层工作流应用。这是我最推荐企业优先掌握的。整体逻辑是用户提问 - 知识库检索 - 大模型生成 - 可选HTTP 请求 / 分支判断 / 内容审核 - 输出。我举个例子做运维工单助手时我在工作流里加了三个节点第一个节点先检索运维知识库第二个节点条件判断“是否包含故障代码”如果是则调用派单系统的 HTTP API 创建工单第三个节点汇总结果回复用户。整个过程在画布上拖拽完成不需要写后端服务。第三层Agent 智能体。让大模型自主决定调用哪些工具、循环几次。MaxKB 的工具集支持配置 HTTP API 调用OpenAPI 规范导入、函数调用等Agent 的模式适合那些任务路径不可枚举的场景。我个人的体会是能用工作流写死的场景就别上 Agent 的自由发挥因为自由度高意味着失控风险高。Agent 适合做“诊断型”任务比如“根据错误码和日志片段分析故障原因并给出处理建议”这种任务分支多、难以穷举Agent 的自规划能力才有价值。创建完应用后还需要考虑发布方式。MaxKB 提供三种载体网页聊天窗口嵌入 iframe、API 接口调用、嵌入第三方系统。API 方式是企业集成最常用的开放接口文档很标准返回流式和非流式都支持。我做的项目里最常见的一个是接企业微信/钉钉的机器人回调一个是在自研 Web 系统里用 iframe 嵌入问答窗口还有直接把 API 开放给业务系统做智能客服接口。这三条路径 MaxKB 都能走通而且是官方推荐玩法通过嵌入机制把智能体嵌入到现有业务系统。3.5 权限管理与多团队协作企业落地绕不开权限和审计。MaxKB 是企业级应用天然有完善的权限管理功能这是我的加分项这部分单说几点组织架构与角色支持类似 RBAC 的权限模型可以创建不同角色管理员、知识库管理员、普通用户等不同角色能看到不同的应用和知识库。知识库共享多个应用可以引用同一个知识库但不同团队的知识库建议隔离避免无关应用检索到不该看到的内容。我见过客户把薪酬制度文档误传进全员知识库的案例幸好有权限隔离及时发现不然就是事故。操作审计管理员后台可以查看系统操作日志。企业做合规审计时这个功能能帮大忙。有很多人被 “开源” 二字迷惑以为没有企业级功能你用 MaxKB 就不会有这个错觉它的权限体系比大多数开源项目成熟得多。4. 常见问题与排查技巧实录4.1 检索不准、答非所问怎么办这是我被问得最多的一类问题。先给出一个结构化排查清单现象排查方向解决建议回答与文档内容无关检查知识库是否被正确关联、文档是否导入成功在应用设置里确认已勾选正确的知识库检索内容不完整、缺关键信息检查切片是否合理、文档是否是扫描件开启按标题切分检查切片预览回答引用了不相关内容降低召回数量、提高相似度阈值把召回数量从 10 降到 5阈值从 0.3 提到 0.5专有名词、型号匹配不到检查是否用了混合检索确保混合检索开启关键词检索对实体词更友好回答风格怪、结构化差优化提示词在“提示词”里明确回复结构、长度和语气换了问题就一直答不好低频长尾问题沉淀到 FAQ 库或补充关联文档排查时我的固定动作是先看“引用来源”。如果引用的内容本身就对不上问题那就是检索环节的问题跟大模型没关系。如果引用内容是对的但回答错了那就是 prompt 或模型能力的问题。这个二分法能帮你快速定位问题归属不白折腾。4.2 模型接入常见坑接入大模型看起来简单实际上坑不少。第一个坑API Key 配好了但报 401。大部分情况是模型平台要求用Authorization: Bearer key但你在 MaxKB 填 Key 时带了多余的空格或引号。检查一下“模型设置”里的 Key 值前后有没有空白字符。还有一个隐蔽问题有些国产模型平台的 API Key 不是唯一的创建多个应用时容易混淆我建议在命名上把“密钥用途”写清楚。第二个坑Ollama 本地部署后请求超时。Ollama 默认只监听127.0.0.1如果 MaxKB 跑在 Docker 里访问宿主机 Ollama 需要设置OLLAMA_HOST0.0.0.0并开放端口同时 Docker 容器内要用http://宿主机IP:11434而不是localhost。这个网络互通问题是新手最容易卡住的地方。第三个坑embedding 模型和对话模型混用。有些用户会把对话模型的 API Key 填在 embedding 配置里或者混选不同类型的模型。建议 embedding 模型固定用一个稳定版本不要频繁更换因为换 embedding 模型意味着所有知识库都要重新向量化成本不低。4.3 性能、并发与知识库规模的经验值关于规模我直接给一组我用过的参考数据单个知识库导入 500 篇文档、约 2 万多个切片在普通配置的服务器上8C16G SSD文档解析和向量化导入大概需要几十分钟到几小时之后查询响应一般在 2-5 秒内取决于大模型响应速度。如果知识库切片超过 5 万个建议看一下 PG 里数据量、检索耗时必要时分库。并发方面瓶颈主要在模型推理不在 MaxKB 本身。如果你接的是在线 API参考平台的 QPS 限制如果本地 Ollama单张 24G 显卡跑 8B 模型大概能支撑 5-10 个并发请求超过就开始排队变慢。要提升并发就把模型服务独立部署做多副本用负载均衡分发接口层保持无状态。4.4 我踩过的几个印象深刻的坑分享三个真实踩坑经历。第一个是文档切片把表格切碎了。当时导入了一份设备参数表导出预览时发现一个完整表格被切成 4 块检索参数表类问题时老是答非所问。处理方案是把表格转成“问答对”格式的 Markdown 文本再导入模型对表格语义的理解会好很多。第二个是相似度阈值设太高导致大面积“答不上来”。有次我为了控制幻觉把相似度阈值调到 0.7结果用户问什么机器人都提示“知识库中没有相关内容”。后来我意识到检索不到和答错是两回事答错了至少还有参考价值检索不到直接归零。用“召回数量提升 阈值适中 prompt 强调基于参考内容回答”的组合体验反而更好。第三个是同步知识库文档更新时忘了重新向量化。MaxKB 的文档如果是“重新上传”或者“编辑更新”会触发重新切分和向量化这没问题。但有一个细节笔者在某版本的操作中发现知识库引用的文档更新后应用端的召回结果不一定立刻变化需要去“文档列表”里确认同步状态。最好的习惯是每次文档更新后抽查 1-2 个核心相关问题确认效果而不是默认它会自动生效。5. 开源生态与社区运营为什么开源是它最大的护城河MaxKB 的快速迭代能力有一个关键因素——代码完全开源项目的 GitHub/Gitee 仓库、官网社区非常活跃。对于一个基础设施工具开源意味着你手里永远有“源代码兜底”。我在一个私有化项目里遇到过一个 bug提 issue 后官方响应很快社区也给出了临时 patch这种安全感是闭源产品给不了的。跟生态里的同类产品比MaxKB 的定位很清晰比 LangChain 更接近成品、比 Dify 更聚焦知识库场景、比自研更省人力。对比DifyDify 是一个更偏“通用 LLMOps 平台”的项目工作流能力强、插件生态多适合做复杂 AI 应用而 MaxKB 的强项在知识库的导入、切片、检索体验上更细腻更贴近中文企业的文档习惯。国内企业如果主要诉求是“知识库问答”我一般推荐 MaxKB如果是做复杂业务 Agent 应用Dify 会更灵活。对比FastGPT两者都是知识库问答起家、中文生态友好FastGPT 胜在流程编排花样多MaxKB 胜在部署简单和飞致云团队的持续投入。对比RagFlowRagFlow 在文档解析特别是 PDF 深度解析上有技术优势但整体的应用编排、智能体能力没 MaxKB 完整。开源还带来另一个隐性优势人才供给。企业数字化部门想招一个懂 MaxKB 的人学起来成本远比招“LangChain 专家”低——因为它的设计符合常规 IT 人员的直觉界面上就能完成大部分工作这聊胜于无地降低了企业的推广门槛。6. 企业落地策略与扩展方向6.1 从试点到推广的落地节奏我给企业做建议时一般会推荐一条“三阶段走”的路线第一阶段单点突破。选一个价值清晰、知识资产丰富的场景比如“IT 帮助台”“HR 员工服务”人工清洗 50-100 份高频文档接一个在线模型比如 DeepSeek两周内上线用“引用来源”功能建立信任。第二阶段横向复制。跑通之后把方法论复制到其他业务条线——产线知识库、销售知识库、客服知识库。每个条线设一个“知识库运营责任人”负责文档更新、FAQ 沉淀和效果抽检。这个阶段要把权限模型用起来做到知识隔离。第三阶段工作流化与系统打通。在场景稳定后开始接业务系统 API把“问答”升级为“问答 动作”。比如设备运维助手不仅能回答故障处理办法还能一键创建工单、查询备件库存。这时候智能体才真正从“聊天机器人”变成“生产力工具”。6.2 大模型选型的务实建议结合我前面的测试就国内企业选型再给一套相对务实的建议预算充足 非敏感场景直接用 DeepSeek-V3 / 通义千问 qwen-plus 级别的在线 API成本低、效果稳定、无需管硬件。数据敏感 / 私有化要求本地部署 Qwen2.5 32B量化后或 DeepSeek-R1 蒸馏版 32B配合 bge-m3 embedding 模型。32B 级别的模型在 2 张 24G 显卡上能跑效果接近在线入门级模型但中文理解明显优于 Llama 8B。极简硬件 / CPU 部署Qwen2.5 7B Instruct 量化版在 CPU 上能跑但速度较慢适合低频内部场景如果只是给维护团队自己用可以接受。再次强调一个观点别在“开源模型”和“闭源模型”之间搞二极管思维。企业要的不是“开源”的标签而是“数据可控 成本可预期 效果达标”的组合。MaxKB 的双轨接入机制恰好让你可以按场景自由切换——涉密知识用本地模型通用闲聊接入在线模型。6.3 结合 AI 趋势看 MaxKB 的位置从相关热搜词里能看出一个明确趋势2025 年大家聊的还是“知识库问答怎么搭”2026 年话题已经变成了“工业智能体从概念走向工程化”“专业智能体如何搭建”“AI Agent 产品盘点”。这说明一个平台单纯做好“问答”已经不够了必须向“能干活”进化。MaxKB 的进化方向多应用编排、工作流、Agent完全踩在这个趋势上。它正在从一个“RAG 工具”变成“企业智能体的运行时”——定义知识来源、编排处理逻辑、调用外部工具、输出到业务系统。现在这个位置站得稳不稳取决于后续迭代对多 Agent 协作、长期记忆、复杂工具链支持的力度。不管怎么说对使用者而言现在入场学习和落地实践是比较合适的时机——产品成熟度够用又没有卷到闭源厂商垄断的地步。最后说一个我个人反复强调的观点这类开源智能体平台真正的门槛从来不是技术而是文档质量和业务流程梳理。再好的平台面对一堆过期、矛盾、残缺的文档也白搭。我见过太多先买工具、后补文档的翻车案例。正确的顺序是先梳理出 50 个高质量问答对再选工具再上线推广。这个顺序倒过来基本是给自己挖坑。如果你正打算在企业里引入知识库智能体我的建议就是花两周把文档整理好再花一天把 MaxKB 部署起来你会发现开箱即用的体验确实没有吹牛。
开源知识库问答平台 MaxKB：从 RAG 到智能体的企业落地指南
1. 从知识库问答说起MaxKB 到底解决了什么问题先说一个我这几年的直观感受几乎每家企业都在喊“知识管理”但绝大多数公司的知识资产依然躺在共享文件夹、Wiki、企业微信群里找一份SOP要么翻半天文件夹要么问一圈人。真正把文档变成“能问答、能推理、能执行”的智能服务聊起来容易做起来全是坑。MaxKB 这个名字拆开看就是Max Knowledge Base中文名“麦知问”是飞致云旗下继 1Panel、JumpServer、DataEase 之后又一个开源项目。它解决的第一个核心问题就是把企业内部的知识库变成一个能自然语言问答的机器人——你丢给它一份员工手册、设备运维手册、产品FAQ它就能基于这些材料回答问题而不是靠大模型瞎编。第二个核心问题是在问答的基础上长出“手脚”通过工作流编排、工具调用、智能体串联变成一个能对接企业业务系统的智能体平台。一句话概括MaxKB 私有知识库 大模型引擎 可视化智能体编排。适合谁三类人最值得关注一是企业 IT/数字化部门想低成本落地一个内部问答机器人二是做 RAG 应用开发的工程师想找一个开箱即用、又不绑死云厂商的方案三是售前、实施、SaaS 产品经理需要快速给客户做 PoC 演示。这个项目最大的特点就是开箱即用。它不像 LangChain 那样给你一堆零件让你自己拼而是把“文档解析 - 切片 - 向量化 - 检索 - 大模型生成 - 引用溯源”整条 RAG 链路都做好你只要部署好服务、接一个大模型 API 或本地模型、上传文档最快半小时就能跑起来一个问答机器人。这跟我早期折腾 RAG 的经历形成了巨大反差——那时候用 Python 脚本自己写切片、调 embedding、拼 prompt一个原型搞了一周效果还不稳定。2. 技术底座与架构Spring Boot 为主干的多语言协作2.1 整体架构与模块划分很多第一次接触 MaxKB 的人会先问一个问题它是不是 Python 写的答案是否定的。MaxKB 的主服务基于JavaSpring Boot前端是Vue 3 Element Plus。这和市面上大多数 AI 应用Dify、FastGPT 基本都是 Python/TS 栈很不一样。为什么用 Java我猜最直接的原因是飞致云的技术积淀。他们家的 JumpServer堡垒机、DataEaseBI 工具都是 Java 技术栈团队对 Spring Boot 这套东西的驾驭能力极强包括后续要做企业级的功能组织架构对接、审计日志、高并发、权限体系Java 生态在传统企业 IT 环境里依然是最稳的选择。还有一个现实考量很多国企、金融机构的 IT 标准里Java 技术栈的接受度远比 Python 高交付的时候阻力小很多。从部署架构看MaxKB 的容器镜像包含三个核心组件主应用Java/Spring Boot负责 Web 服务、知识库管理、模型管理、应用编排、API 鉴权、权限管理。向量检索相关能力内置了向量数据库能力同时也支持配置外部向量库如 Elasticsearch 等文档经过 embedding 后写入向量库做相似度检索。前端静态资源打包在同一个镜像里通过 Nginx 直接提供服务。这种单体应用架构的好处是部署极其简单docker-compose 一把梭。坏处是如果你想单独扩展 embedding 服务或者把检索能力拆成微服务就没那么灵活。但考虑到 MaxKB 主要面向企业内部场景单体架构的“够用”和“省心”恰恰是最大优势。2.2 知识库引擎让文档变成可检索的知识切片知识库是 MaxKB 的核心资产。它的工作流大致是上传文档 - 文档解析 - 智能切片 - 向量化Embedding- 写入向量库 - 检索召回。先说文档解析。MaxKB 支持常见的文本类格式TXT、Markdown、PDF、DOCX、HTML、XLSX、CSV还支持 URL 采集输入一个网址抓取网页内容做知识。我在实际使用中PDF 的解析效果是个重点——很多开源工具的 PDF 解析遇到扫描件就废了MaxKB 对数字版 PDF 的效果比较好对扫描件需要 OCR 支持这一点在纯开源版本里尚不完善如果你是做纸质文档数字化建议先用外部 OCR 处理成文本再导入。切片是决定 RAG 效果最关键的一步也是最容易被忽视的一步。MaxKB 的切片参数里有几个关键配置切片最大长度默认值我记得是 400 字左右这个值决定了每个知识片段的上限字数。重叠长度相邻切片之间保留的重叠字数默认 100 字左右。切片分隔符选择可以选择“智能拆分”“按分隔符拆分”“自定义分隔符”。为什么要设重叠因为如果一刀切得太死一句话、一个表格被拦腰切断语义就断裂了。重叠能让上下文保持连续检索时更容易命中完整语义块。但重叠也不是越大越好重叠大意味着存储冗余多、检索噪音多一般来说按 400/100 的比例起步再根据实际效果调。向量化环节MaxKB 不自己做 embedding而是调用你所接入的大模型的 embedding 能力。这就带来一个细节如果你接的是 OpenAI 或通义千问的在线 API向量由云端算好返回如果你接的是本地 Ollama 部署的模型向量就在本地算。这个方案的好处是灵活坏处是你的向量质量完全取决于所选模型。这里有个实用建议国内企业做私有化部署embedding 模型我推荐用Ollama 上的 bge-m3 或 nomic-embed-text中文效果不错而且完全本地运行数据不出内网。2.3 模型接入在线 API 与本地离线模型双轨并行MaxKB 支持的模型接入方式非常宽这也是它在国内企业里受欢迎的原因之一。我简单列一下常见的几类模型渠道说明适用场景Ollama本地部署的 Llama、Qwen、DeepSeek 等数据敏感、无外网环境、成本敏感OpenAI 兼容接口所有提供 OpenAI 格式 API 的服务包括各类国产模型网关已有 API 网关的企业DeepSeek / 通义千问 / 智谱 / 讯飞星火 / Kimi国内主流云厂商模型快速接入、成本可控Azure OpenAI微软云托管的 OpenAI已有 Azure 订阅的外企/合资企业Gemini / Claude海外模型有海外 API 访问条件的场景为什么要强调本地模型这就回到热词里那个很典型的问题Llama 适合国内企业拿来搞知识库问答和私有化 Agent 部署吗我的观点是看场景。如果你企业对数据合规要求极高比如金融、政务、医院所有数据必须留在内网那就只能选本地模型。Llama 3.1 8B 经过量化后部署在 16G 显存的机器上跑中文知识库问答基本能看但效果跟 GPT-4o、DeepSeek-V3 这种级别的模型比有明显差距具体表现是生成内容比较“平”、复杂推理容易逻辑断裂。如果你只是做“文档问答”对生成要求不高Llama 8B 完全够用如果你要做多轮复杂 Agent 工作流建议用Qwen2.5 32B或者DeepSeek 蒸馏模型在本地跑中文能力会更扎实。别迷信 Llama。这是我在多个项目里对比测试后比较确定的结论。还有一类特殊选择通过兼容 OpenAI API 自建模型网关。很多企业已经用 vLLM、xinference 等工具内部部署了模型服务只要提供 OpenAI 风格的 base_url 和 api_keyMaxKB 就能直接对接。这一点非常关键意味着你之前沉淀的模型服务能力不会被浪费。2.4 从问答机器人到智能体平台应用编排的进化逻辑很多人以为 MaxKB 只是做知识库问答但从项目迭代轨迹看它在快速向“智能体平台”进化。从早期版本支持“简单应用”创建问答机器人绑定知识库到后来加入工作流编排再到引入智能体Agent创建、工具箱/函数调用、多应用编排这条路线非常清晰。拿企业实际情况来理解这件事一个纯粹的问答机器人能回答“报销流程是什么”但做不了什么一个智能体则能根据你的问题先查知识库获取制度依据再调用某个业务系统的 API 查询数据最后组织语言给出结果。MaxKB 的工作流编排就是干这个的在画布上拖拽节点把“知识库检索”“大模型对话”“API 请求”“条件分支”串起来让机器人从“会说”变成“会做”。这里也回应一下热词里那个“2026 是工业智能体从概念演示走向工程化落地的分水岭”的说法。我挺认同这个判断。概念演示阶段大家都在秀“AI 能看懂图纸、能对话”工程化落地阶段客户要的是“AI 能不能替我巡检、能不能自动生成工单、能不能跟现有系统打通”。MaxKB 这类平台的价值恰好是降低了工程化门槛——你不用从零写编排引擎不用处理模型调用的并发和容错只需关注业务逻辑本身。3. 实操落地从零搭建一个企业级问答智能体3.1 部署一条 docker 命令跑起来MaxKB 的安装部署在同类产品里算非常省心的。最简单的体验方式docker run -d --namemaxkb -p 8080:8080 -v ~/maxkb:/var/lib/postgresql/data 1panel/maxkb跑起来之后浏览器访问http://服务器IP:8080默认账号密码是admin / MaxKB123..登录后会强制要求改密码。这套体验跟 1Panel 一脉相承对运维非常友好。生产环境建议用 docker-compose 部署把 PostgreSQL、向量存储、主应用都编排好数据目录挂载到宿主机持久化。我一般会顺手做三件事改默认端口8080 太容易被扫描换一个高位端口或者前面套一层 Nginx 做 TLS 终止。设置定时备份MaxKB 的元数据、知识库配置都存 PostgreSQL 里用 crontab 定时pg_dump最稳妥。向量数据也要定期快照。限制外网暴露如果只是内网使用尽量别把 8080 端口映射到公网放内网反向代理就够。注意MaxKB 的老版本默认使用内置的 PostgreSQL 和向量存储。如果你要对接公司已有的 PostgreSQL 或者 Elasticsearch需要在配置文件里显式指定这个要提前规划好别等数据导入之后再迁移。3.2 创建知识库的完整流程与参数优化创建知识库是整个项目的核心竞争力所在我把完整的操作流程和调参心得拆开讲。第一步创建知识库时选择类型。MaxKB 的知识库分成通用型知识库自由上传文档切片和FAQ 知识库用标准问答对维护两种。FAQ 类型其实很好用适合客服话术、制度答疑这种“一个标准答案打天下”的场景维护成本低、命中率高。通用型则适合描述性内容多的文档。我一般是两类混用FAQ 库放高频标准问答文档库放操作手册、规章制度、说明书这类长篇材料。第二步上传文档并设置切片规则。这块的参数直接决定检索质量我踩过不少坑总结下经验切片长度 300-600 字是比较安全的区间。太短100 字会导致语义碎片化召回时上下文不足太长1000 字会导致向量表征被稀释检索精度下降且大模型输入 tokens 浪费。重叠长度设为切片长度的 15%-20%。比如切片 400 字重叠 80 字左右。重叠太少起不到承接作用重叠太多会显著增加切片数量拖慢导入和检索。Markdown 文档一定要开启按标题拆分。MaxKB 支持按 Markdown 标题结构智能切分这样每个切片基本对应一个章节主题语义完整度远高于纯按字数硬切。Convert 后的文档如果是 Word 排好版的也可以利用段落分隔符。第三步导入后用“预览”检查切片质量。我习惯随机抽 5-10 个切片检查重点看有没有上下文被切断的句子、表格被撕碎只留半截、代码块被拦腰截断。如果问题严重就改切片策略重新导入不要傻傻地直接上线。第四步关联模型并做效果测试。知识库建好后在应用里关联一个大模型随便问几个有代表性的问题观察召回内容是否覆盖答案要点。这一步不要急着调 prompt先看检索结果是否准确。3.3 提高检索命中率的实战技巧“怎么提高匹配度”是 MaxKB 社区里被问烂了的问题。我摸索下来影响检索质量的因素按优先级排序是文档本身的可检索性 切片方式 embedding 模型 检索参数 prompt 组织。先说文档质量。很多人忽略了这一点如果原始文档是 PPT 转的图片 PDF、是扫描件、是逻辑混乱的流水账后面怎么调参数都是白费。我在实际项目中会先对文档做“清洗”把多余的页眉页脚、水印、目录页删掉把繁体转简体表格尽量转为 Markdown 表格。这些脏数据清理完检索质量能提升一截。再说检索参数。MaxKB 的应用设置里有关键的参数可调检索模式向量检索 vs 全文检索 vs 混合检索。我强烈建议用混合检索如果版本支持向量找回语义相近的内容关键词检索精确命中专有名词。技术实现上向量检索擅长“语义相近但字面不同”的场景比如“怎么申请年假”和“休假制度”关键词检索则擅长精确匹配设备型号、工单编号、人名地名这种唯一性强的实体。召回数量默认可能只取前 4-5 条实际项目里我会适当调到 8-10 条让大模型有更多上下文可以参考。召回太少信息不足召回太多噪音增加大模型可能被无关内容带偏。相似度阈值低于阈值的切片会被过滤掉。这个值默认有时候偏保守导致召回为空。实践下来设0.3-0.4之间比较合适太高容易漏召回太低会让大模型参考无关联的内容。引用来源开关务必打开“引用来源”让回答后面带上引用的文档片段。这不仅是合规需要更重要的是用户可以自己检验 AI 回答的准确性——在企业落地时这个“可溯源”特性是赢得业务部门信任的关键。还有一招很实用把高频问答沉淀到 FAQ 库。跑一段时间之后把用户问得多、AI 答得差的问题整理成标准问答放进 FAQ 知识库。这种“运营驱动”的方式比反复调参数见效更快。我在一个售后场景里就是靠这个办法把机器人的首答命中率从 60% 左右拉到了 85% 以上。3.4 创建智能体应用从编排到发布接下来是重头戏——创建智能体应用。MaxKB 的应用类型现在不止一种我把它分为三个层次第一层简单问答应用。就绑定一个或多个知识库不做额外编排。适合快速交付的场景比如员工手册问答、产品 FAQ。第二层工作流应用。这是我最推荐企业优先掌握的。整体逻辑是用户提问 - 知识库检索 - 大模型生成 - 可选HTTP 请求 / 分支判断 / 内容审核 - 输出。我举个例子做运维工单助手时我在工作流里加了三个节点第一个节点先检索运维知识库第二个节点条件判断“是否包含故障代码”如果是则调用派单系统的 HTTP API 创建工单第三个节点汇总结果回复用户。整个过程在画布上拖拽完成不需要写后端服务。第三层Agent 智能体。让大模型自主决定调用哪些工具、循环几次。MaxKB 的工具集支持配置 HTTP API 调用OpenAPI 规范导入、函数调用等Agent 的模式适合那些任务路径不可枚举的场景。我个人的体会是能用工作流写死的场景就别上 Agent 的自由发挥因为自由度高意味着失控风险高。Agent 适合做“诊断型”任务比如“根据错误码和日志片段分析故障原因并给出处理建议”这种任务分支多、难以穷举Agent 的自规划能力才有价值。创建完应用后还需要考虑发布方式。MaxKB 提供三种载体网页聊天窗口嵌入 iframe、API 接口调用、嵌入第三方系统。API 方式是企业集成最常用的开放接口文档很标准返回流式和非流式都支持。我做的项目里最常见的一个是接企业微信/钉钉的机器人回调一个是在自研 Web 系统里用 iframe 嵌入问答窗口还有直接把 API 开放给业务系统做智能客服接口。这三条路径 MaxKB 都能走通而且是官方推荐玩法通过嵌入机制把智能体嵌入到现有业务系统。3.5 权限管理与多团队协作企业落地绕不开权限和审计。MaxKB 是企业级应用天然有完善的权限管理功能这是我的加分项这部分单说几点组织架构与角色支持类似 RBAC 的权限模型可以创建不同角色管理员、知识库管理员、普通用户等不同角色能看到不同的应用和知识库。知识库共享多个应用可以引用同一个知识库但不同团队的知识库建议隔离避免无关应用检索到不该看到的内容。我见过客户把薪酬制度文档误传进全员知识库的案例幸好有权限隔离及时发现不然就是事故。操作审计管理员后台可以查看系统操作日志。企业做合规审计时这个功能能帮大忙。有很多人被 “开源” 二字迷惑以为没有企业级功能你用 MaxKB 就不会有这个错觉它的权限体系比大多数开源项目成熟得多。4. 常见问题与排查技巧实录4.1 检索不准、答非所问怎么办这是我被问得最多的一类问题。先给出一个结构化排查清单现象排查方向解决建议回答与文档内容无关检查知识库是否被正确关联、文档是否导入成功在应用设置里确认已勾选正确的知识库检索内容不完整、缺关键信息检查切片是否合理、文档是否是扫描件开启按标题切分检查切片预览回答引用了不相关内容降低召回数量、提高相似度阈值把召回数量从 10 降到 5阈值从 0.3 提到 0.5专有名词、型号匹配不到检查是否用了混合检索确保混合检索开启关键词检索对实体词更友好回答风格怪、结构化差优化提示词在“提示词”里明确回复结构、长度和语气换了问题就一直答不好低频长尾问题沉淀到 FAQ 库或补充关联文档排查时我的固定动作是先看“引用来源”。如果引用的内容本身就对不上问题那就是检索环节的问题跟大模型没关系。如果引用内容是对的但回答错了那就是 prompt 或模型能力的问题。这个二分法能帮你快速定位问题归属不白折腾。4.2 模型接入常见坑接入大模型看起来简单实际上坑不少。第一个坑API Key 配好了但报 401。大部分情况是模型平台要求用Authorization: Bearer key但你在 MaxKB 填 Key 时带了多余的空格或引号。检查一下“模型设置”里的 Key 值前后有没有空白字符。还有一个隐蔽问题有些国产模型平台的 API Key 不是唯一的创建多个应用时容易混淆我建议在命名上把“密钥用途”写清楚。第二个坑Ollama 本地部署后请求超时。Ollama 默认只监听127.0.0.1如果 MaxKB 跑在 Docker 里访问宿主机 Ollama 需要设置OLLAMA_HOST0.0.0.0并开放端口同时 Docker 容器内要用http://宿主机IP:11434而不是localhost。这个网络互通问题是新手最容易卡住的地方。第三个坑embedding 模型和对话模型混用。有些用户会把对话模型的 API Key 填在 embedding 配置里或者混选不同类型的模型。建议 embedding 模型固定用一个稳定版本不要频繁更换因为换 embedding 模型意味着所有知识库都要重新向量化成本不低。4.3 性能、并发与知识库规模的经验值关于规模我直接给一组我用过的参考数据单个知识库导入 500 篇文档、约 2 万多个切片在普通配置的服务器上8C16G SSD文档解析和向量化导入大概需要几十分钟到几小时之后查询响应一般在 2-5 秒内取决于大模型响应速度。如果知识库切片超过 5 万个建议看一下 PG 里数据量、检索耗时必要时分库。并发方面瓶颈主要在模型推理不在 MaxKB 本身。如果你接的是在线 API参考平台的 QPS 限制如果本地 Ollama单张 24G 显卡跑 8B 模型大概能支撑 5-10 个并发请求超过就开始排队变慢。要提升并发就把模型服务独立部署做多副本用负载均衡分发接口层保持无状态。4.4 我踩过的几个印象深刻的坑分享三个真实踩坑经历。第一个是文档切片把表格切碎了。当时导入了一份设备参数表导出预览时发现一个完整表格被切成 4 块检索参数表类问题时老是答非所问。处理方案是把表格转成“问答对”格式的 Markdown 文本再导入模型对表格语义的理解会好很多。第二个是相似度阈值设太高导致大面积“答不上来”。有次我为了控制幻觉把相似度阈值调到 0.7结果用户问什么机器人都提示“知识库中没有相关内容”。后来我意识到检索不到和答错是两回事答错了至少还有参考价值检索不到直接归零。用“召回数量提升 阈值适中 prompt 强调基于参考内容回答”的组合体验反而更好。第三个是同步知识库文档更新时忘了重新向量化。MaxKB 的文档如果是“重新上传”或者“编辑更新”会触发重新切分和向量化这没问题。但有一个细节笔者在某版本的操作中发现知识库引用的文档更新后应用端的召回结果不一定立刻变化需要去“文档列表”里确认同步状态。最好的习惯是每次文档更新后抽查 1-2 个核心相关问题确认效果而不是默认它会自动生效。5. 开源生态与社区运营为什么开源是它最大的护城河MaxKB 的快速迭代能力有一个关键因素——代码完全开源项目的 GitHub/Gitee 仓库、官网社区非常活跃。对于一个基础设施工具开源意味着你手里永远有“源代码兜底”。我在一个私有化项目里遇到过一个 bug提 issue 后官方响应很快社区也给出了临时 patch这种安全感是闭源产品给不了的。跟生态里的同类产品比MaxKB 的定位很清晰比 LangChain 更接近成品、比 Dify 更聚焦知识库场景、比自研更省人力。对比DifyDify 是一个更偏“通用 LLMOps 平台”的项目工作流能力强、插件生态多适合做复杂 AI 应用而 MaxKB 的强项在知识库的导入、切片、检索体验上更细腻更贴近中文企业的文档习惯。国内企业如果主要诉求是“知识库问答”我一般推荐 MaxKB如果是做复杂业务 Agent 应用Dify 会更灵活。对比FastGPT两者都是知识库问答起家、中文生态友好FastGPT 胜在流程编排花样多MaxKB 胜在部署简单和飞致云团队的持续投入。对比RagFlowRagFlow 在文档解析特别是 PDF 深度解析上有技术优势但整体的应用编排、智能体能力没 MaxKB 完整。开源还带来另一个隐性优势人才供给。企业数字化部门想招一个懂 MaxKB 的人学起来成本远比招“LangChain 专家”低——因为它的设计符合常规 IT 人员的直觉界面上就能完成大部分工作这聊胜于无地降低了企业的推广门槛。6. 企业落地策略与扩展方向6.1 从试点到推广的落地节奏我给企业做建议时一般会推荐一条“三阶段走”的路线第一阶段单点突破。选一个价值清晰、知识资产丰富的场景比如“IT 帮助台”“HR 员工服务”人工清洗 50-100 份高频文档接一个在线模型比如 DeepSeek两周内上线用“引用来源”功能建立信任。第二阶段横向复制。跑通之后把方法论复制到其他业务条线——产线知识库、销售知识库、客服知识库。每个条线设一个“知识库运营责任人”负责文档更新、FAQ 沉淀和效果抽检。这个阶段要把权限模型用起来做到知识隔离。第三阶段工作流化与系统打通。在场景稳定后开始接业务系统 API把“问答”升级为“问答 动作”。比如设备运维助手不仅能回答故障处理办法还能一键创建工单、查询备件库存。这时候智能体才真正从“聊天机器人”变成“生产力工具”。6.2 大模型选型的务实建议结合我前面的测试就国内企业选型再给一套相对务实的建议预算充足 非敏感场景直接用 DeepSeek-V3 / 通义千问 qwen-plus 级别的在线 API成本低、效果稳定、无需管硬件。数据敏感 / 私有化要求本地部署 Qwen2.5 32B量化后或 DeepSeek-R1 蒸馏版 32B配合 bge-m3 embedding 模型。32B 级别的模型在 2 张 24G 显卡上能跑效果接近在线入门级模型但中文理解明显优于 Llama 8B。极简硬件 / CPU 部署Qwen2.5 7B Instruct 量化版在 CPU 上能跑但速度较慢适合低频内部场景如果只是给维护团队自己用可以接受。再次强调一个观点别在“开源模型”和“闭源模型”之间搞二极管思维。企业要的不是“开源”的标签而是“数据可控 成本可预期 效果达标”的组合。MaxKB 的双轨接入机制恰好让你可以按场景自由切换——涉密知识用本地模型通用闲聊接入在线模型。6.3 结合 AI 趋势看 MaxKB 的位置从相关热搜词里能看出一个明确趋势2025 年大家聊的还是“知识库问答怎么搭”2026 年话题已经变成了“工业智能体从概念走向工程化”“专业智能体如何搭建”“AI Agent 产品盘点”。这说明一个平台单纯做好“问答”已经不够了必须向“能干活”进化。MaxKB 的进化方向多应用编排、工作流、Agent完全踩在这个趋势上。它正在从一个“RAG 工具”变成“企业智能体的运行时”——定义知识来源、编排处理逻辑、调用外部工具、输出到业务系统。现在这个位置站得稳不稳取决于后续迭代对多 Agent 协作、长期记忆、复杂工具链支持的力度。不管怎么说对使用者而言现在入场学习和落地实践是比较合适的时机——产品成熟度够用又没有卷到闭源厂商垄断的地步。最后说一个我个人反复强调的观点这类开源智能体平台真正的门槛从来不是技术而是文档质量和业务流程梳理。再好的平台面对一堆过期、矛盾、残缺的文档也白搭。我见过太多先买工具、后补文档的翻车案例。正确的顺序是先梳理出 50 个高质量问答对再选工具再上线推广。这个顺序倒过来基本是给自己挖坑。如果你正打算在企业里引入知识库智能体我的建议就是花两周把文档整理好再花一天把 MaxKB 部署起来你会发现开箱即用的体验确实没有吹牛。
