去年年底我们团队接了一个挺头疼的需求内部几十张业务表都在 Oracle 里销售、库存、客户、工单全在那套老库上老板想要一个能“用大白话查数据库”的入口比如直接问“上个月华东区销售额环比增长了多少”系统自己就能查出来再回答。最开始我们也想过传统方案把数据导出成文档切块丢进向量库做 RAG。但试了几天就发现路子不对Excel 导出的报表和 PDF 操作手册做问答还行业务数据是活的文档抽出来当天就过期了。后来折腾了几个星期把 Dify、Oracle、MCP 这三样东西串在了一条链路上效果超出了预期。Dify 负责搭 RAG 应用和 Agent 入口Oracle 继续当它的数据仓库MCP 则是打通 Agent 和数据库之间那双手。这套组合跑通之后既能做文档类知识库问答又能让大模型直接“动手查库”也就是现在大家常说的 Agentic RAG 方向。这篇文章就把我们完整的落地过程、踩过的坑、以及每一步为什么这么选型都写清楚给正在做同样尝试的团队一个参考。1. 为什么把 Dify、Oracle、MCP 这三样东西放一起1.1 RAG 不是只能喂文档结构化数据才是企业里最值钱的“知识”很多人一提到 RAG 知识库第一反应就是把 PDF、Word、Markdown 文档切成小段向量化之后塞进数据库。这个思路处理规章制度、产品手册、历史方案没问题但遇到 Oracle 里的业务数据就露怯了。原因很直白文档是静态的业务表是动态的。一个客户表今天 10 万条明天就变成 11 万条一张订单表每秒钟都在写入。你不可能每隔五分钟就把全量数据导出成文档重新走一遍切分和向量化成本实在太高了。更关键的是结构化数据里藏着的答案往往是统计性的比如“华东区 Q3 的退货率”“最近 30 天客单价排名前 10 的商品”。这类问题靠向量检索很难回答因为答案根本不在某一篇文档的某一段话里而是要通过 SQL 聚合计算才能得到。如果硬把这种问题做成文档 RAG模型只能靠想象编一个数字这在企业内部完全不可接受。所以我们在设计阶段就达成了一个共识RAG 要分两条腿走路。一条腿是文档类知识库处理制度、手册、FAQ另一条腿是结构化数据查询通过 Agent 直接操作 Oracle。Dify 知识库流水线管前者MCP Agent 管后者。1.2 Dify 是 RAG 应用和 Agent 编排的“总装车间”选 Dify 而不是从零用 LangChain 搭一套核心原因是效率。Dify 社区版把知识库管理、文本切分、Embedding、检索参数调整、Agent 工作流编排、模型接入这些琐碎的事都封装好了我们不需要重复造轮子。举个例子知识库问答要调的东西其实非常多分段长度设多少、重叠 token 设多少、召回 TopK 取几、相似度阈值卡在哪个值、多路召回怎么合并。这些如果自己用代码实现每个环节都要写一堆调试逻辑。Dify 里就是后台几个配置项的事改了立刻能在线测试这个迭代速度是纯代码方案比不了的。Agent 编排也同理。我们后面要做“先检索业务口径文档、再调用 Oracle 查询工具”这种多步推理流程Dify 工作流里可以用 LLM 节点、知识检索节点、工具节点像搭积木一样串起来每个节点的输入输出都可视化排查链路快很多。1.3 MCP 是给 Agent 装上的“数据库专用手”MCPModel Context Protocol简单说就是一套统一标准解决的是 Agent“怎么调用外部工具”的问题。没有 MCP 之前每个 Agent 框架自己定义一套工具调用格式换个框架就要重写一遍工具层。有了 MCP 之后工具方只需要按照协议实现一个 MCP Server任何支持 MCP 的客户端都能动态发现并调用这些工具。这个性质对数据库接入特别友好。我们把 Oracle 的查询能力封装成几个 MCP 工具Agent 框架只需要通过 MCP Client 连上去就能知道有哪些工具可用、每个工具接收什么参数、返回什么结构。这就像给 Agent 装上了一双能操作数据库的手而且这双手的每个动作都受我们控制可以做权限限制、字段过滤、行数限制。1.4 整体架构一句话总结整套链路如果非要浓缩成一句话Oracle 是数据的源头Dify 负责出入口和流程编排MCP 负责把 Oracle 安全地暴露给 Agent。文档类知识走 Dify 知识库结构化数据查询走 MCP 工具两路在 Agent 对话中汇合用户感知到的就是一个能查文档、能查数据库的智能问答入口。2. Dify 社区版部署镜像拉取失败和数据库选型那些事2.1 部署前的选型Dify 元数据库用什么Dify 官方 docker compose 默认会带上 PostgreSQL 15 和 Weaviate。PostgreSQL 存平台自身的业务数据Weaviate 是向量数据库存知识库的 Embedding 向量。这套开箱即用的组合没问题但我们做了一点调整把向量库换成了 PostgreSQL 的 pgvector 扩展。换的原因很实际团队里没有人维护过 Weaviate而 PostgreSQL 大家都很熟。pgvector 在数据量不大的情况下千万级以内性能完全够用还省掉了一个独立中间件。对标的正好是市面上常见的“FastAPI LangChain LangGraph RAG pgvector”那类方案。Dify 环境变量里提供了向量库类型配置改成VECTOR_STOREpgvector就可以了。2.2 拉取镜像失败的处理链路部署 Dify 过程中遇到的第一道坎就是镜像拉取失败相信不少人都在这一步卡过。现象很典型docker compose up -d执行之后卡在 Pulling 阶段过一会儿报超时docker pull单拉某个镜像也一直转圈。我们的排查链路是这样的。先执行docker info看 Docker daemon 的 registry mirror 配置发现用的是默认官方源。然后修改/etc/docker/daemon.json配置国内可用的镜像加速地址改完记得重启 Docker 服务sudo systemctl restart docker重启之后重新拉取问题基本解决。如果还是慢用docker pull单扯某一个镜像先测试比如docker pull nginx:alpine能快速判断是这个镜像的问题还是网络整体的问题。还有一个容易被忽略的坑是磁盘空间。Dify 全家桶涉及镜像不少nginx、postgres、redis、weaviate、api、worker、web 加起来小几个 GBdocker system df看一下空间是不是不够了有时候镜像拉不下来不是网络问题是磁盘满了。2.3 部署验证与升级注意事项服务起来之后不要急着配模型先做一轮健康检查所有容器状态是否为 healthydocker compose ps看一遍Web 页面是否能正常打开API 服务 5001 端口是否监听首次访问会要求设置管理员邮箱和密码这个初始化必须在同一个网络内完成后续版本更新也要注意。Dify 的在线升级逻辑是备份整个 docker volumes 目录再拉取最新代码和镜像重新部署。我们升级过一次小版本当时遇到 worker 容器反复重启最后排查发现是迁移脚本没有跑完重启后多等了两分钟就好了。升级前一定备份/var/lib/docker/volumes下和 Dify 相关的卷这个操作花不了几分钟但能救命。另外提一句多租户。Dify 社区版从 1.10 左右开始强化了多租户能力一个平台可以开多个空间给不同部门用。我们实际用下来知识库和应用的隔离性够用但要注意向量库是按 tenant 分 collection 还是共享一个 collection这会影响数据隔离的彻底程度生产环境建议重点验证一下。3. RAG 落地第一步打通 Oracle 到 Dify 知识库的 ETL 流水线3.1 先想清楚哪些 Oracle 数据值得进知识库哪些不该进不是所有 Oracle 里的数据都适合进知识库。我们内部定了一个筛选标准适合进知识库的是“解释性、描述性、低频变化”的数据。比如产品规格说明、内部 SOP 操作流程、历史故障处理记录、售后常见问题总结这些内容描述稳定而且需要大模型理解语义之后回答。不适合进知识库的包括订单流水、库存明细、用户个人信息这类事务性、敏感性数据。订单流水价值在于实时统计应该走 SQL 查询个人信息进向量库属于数据合规雷区连碰都别碰。这里有个血泪教训我们一开始想把历史客户咨询记录导进知识库做问答数据里带着客户姓名和联系方式后来被安全部门叫停清洗了一个星期才把敏感字段全部剥离掉。3.2 构建 Oracle 知识库流水线的具体步骤知识库 ETL 的流程可以归纳为四步抽取、清洗、切分、向量化写入。第一步是抽取。我们用 Python 的python-oracledb库连接 Oracle。这个库有 thin 和 thick 两种模式thin 模式不需要安装 Oracle Client纯 Python 实现部署省心。连接的时候推荐直接用 DSN 字符串import oracledb conn oracledb.connect( userknowledge_ro, passwordxxx, dsn192.168.1.20:1521/ORCLPDB1 )抽取数据时如果源表非常大不要一条 SQL 把全表捞进内存。用分页批次拉取单纯用WHERE ROWNUM做分页在数据量大时性能很差11g 里推荐先排序再包一层 ROWNUM12c 以上直接用 OFFSET FETCH-- 11g SELECT * FROM ( SELECT t.*, ROWNUM rn FROM ( SELECT * FROM product_spec ORDER BY update_time DESC ) t WHERE ROWNUM 200 ) WHERE rn 100; -- 12c SELECT * FROM product_spec ORDER BY update_time DESC OFFSET 100 ROWS FETCH NEXT 100 ROWS ONLY;如果表里有 CLOB 字段注意在 Python 里统一转成字符串再处理。Oracle 的 CLOB 读取有时会带特殊的分隔符最好做一次replace(\x00, )之类的清洗。第二步是清洗。我们主要做三件事去 HTML 标签、去多余换行和空格、把数字类型统一格式。这里特别提醒一个坑Oracle 导出数据到 CSV 时身份证号、订单号这类长数字经常变成科学计数法看起来是1.23457E17实际数据已经失真了。解决办法是在 SQL 查询时就把字段转成字符串处理SELECT TO_CHAR(id_card) AS id_card FROM customer;第三步是切分。Dify 上传文档时自带分段功能但用 API 批量写入时要在本地先把文本切好。我们选的是按段落语义切每个 chunk 控制在 500 到 800 字重叠 100 字。如果直接用空格数硬切遇到技术文档里的表格描述会切得稀碎语义全丢了。第四步就是调用 Dify 知识库的创建文档 API把带分段的文本传上去由 Dify 自己完成 Embedding 和入库。这样写的好处是中间任何一步出问题都容易定位不用把逻辑全堆在 Dify 内部。3.3 增量同步策略全量 ETL 只适合第一次初始化后续要跑增量。我们用的策略是基于update_time字段做增量每次只抽取最近更新过的记录。实现上就是一个定时任务每小时跑一次记录上次抽取的最大时间戳。定时任务调度我们直接用的系统 crontab脚本里加一个状态文件保存上次运行时间。增量同步跑了一段时间后发现一个隐蔽问题有些业务表虽然有update_time但历史数据被批量修复过时间戳并没有更新。后来补了一个兜底方案每周日做一次全量校验对比总数和最近 N 条记录发现不一致就触发重跑。增量同步还有个成本考量。每次同步的文本量虽然不大但 Embedding API 是计费的如果表很多、任务很频繁费用不可忽视。我们最后是把多个表的数据合并成一批再调 Embedding 接口减少请求次数成本能降三分之一左右。4. 从“MCP 是什么”到“动手写一个 Oracle MCP Server”4.1 MCP 在 Agent 里扮演什么角色用一句话解释 MCP它就像电脑上的 USB-C 接口。以前每个外设都有自己的充电线现在统一成一个标准接口设备只要支持这个接口就能互联。MCP 干的是同一件事它定义了 AI 应用客户端和工具提供方服务端之间的通信协议。一个 MCP Server 管三件事向外暴露有哪些工具、每个工具的参数格式、以及工具的执行逻辑。Agent 通过 MCP Client 连上 Server 后先获取工具列表和参数 Schema然后在对话过程中根据用户问题决定要不要调用某个工具、传什么参数。整个过程是动态的Agent 不是写死调用某个函数而是“现看菜单点菜”。这个特性对数据库接入太关键了。以前我们给 Agent 接数据库还要在 Agent 配置里手工定义一堆 function schema换个 Agent 框架又得重写一遍。有了 MCPOracle 的能力被封装成标准工具谁来了都能直接用。4.2 快速实现一个 Oracle MCP Server在 Python 里写 MCP Server 推荐用 FastMCP 这个库它对底层协议做了很好的封装代码量非常少。我们第一个版本只用了不到一百行代码。先安装依赖pip install fastmcp python-oracledb然后定义 Server 和工具from fastmcp import FastMCP import oracledb mcp FastMCP(oracle-mcp) DB_USER mcp_ro DB_PASSWORD xxx DB_DSN 192.168.1.20:1521/ORCLPDB1 mcp.tool() def list_tables(schema: str None) - list[str]: 查看当前用户或指定 schema 下有哪些业务表。 with oracledb.connect(userDB_USER, passwordDB_PASSWORD, dsnDB_DSN) as conn: with conn.cursor() as cur: cur.execute( SELECT table_name FROM all_tables WHERE owner :owner ORDER BY table_name , {owner: (schema or DB_USER).upper()}) return [row[0] for row in cur.fetchmany(200)] mcp.tool() def run_query(sql: str, limit: int 50) - list | dict: 执行只读 SQL 查询只允许 SELECT 语句返回最多 limit 行。 sql sql.strip().rstrip(;) if not sql.upper().startswith(SELECT): return {error: 只允许执行 SELECT 查询} with oracledb.connect(userDB_USER, passwordDB_PASSWORD, dsnDB_DSN) as conn: with conn.cursor() as cur: cur.execute(fSELECT * FROM ({sql}) WHERE ROWNUM {limit}) cols [d[0] for d in cur.description] rows [dict(zip(cols, r)) for r in cur.fetchall()] return rows跑起来更简单if __name__ __main__: mcp.run()这个 Server 默认走 stdio 模式调试的时候python oracle_mcp.py就能和 MCP Client 通信。里面我们故意的设计是run_query只允许 SELECT并且在子查询外包了一层 ROWNUM 限制从源头避免 Agent 写出全表扫描的慢 SQL。4.3 工具集设计不只是让 Agent 瞎查 SQL很多人写数据库 MCP Server 只暴露一个通用 SQL 执行工具这样有隐患。通用 SQL 工具自由度太高Agent 一旦生成错误的 SQL或者语义理解偏差查出来的东西就不是用户想要的。更可怕的是如果权限控制没做好可能导致数据泄露或破坏。我们的思路是“通用工具 业务工具”两层设计。通用工具包括list_tables、get_schema、run_query三个负责让 Agent 自己探索数据库结构。但仅靠这三个工具Agent 对业务口径的理解是不够的比如“销售额”到底是订单金额还是实收金额“环比”和“同比”的口径是什么这些知识不在数据库结构里而在人的脑子里。所以我们在 MCP Server 里增加业务级工具把 SQL 藏在函数里Agent 只需要传参数mcp.tool() def get_sales_trend(start_date: str, end_date: str, region: str None) - dict: 统计指定时间段的销售额和订单量可按区域筛选。 sql SELECT TO_CHAR(order_date, YYYY-MM-DD) AS day, SUM(order_amount) AS sales, COUNT(*) AS order_cnt FROM orders WHERE order_date BETWEEN TO_DATE(:start, YYYY-MM-DD) AND TO_DATE(:end, YYYY-MM-DD) if region: sql AND region :region sql GROUP BY TO_CHAR(order_date, YYYY-MM-DD) ORDER BY day # 执行并返回业务工具的好处是Agent 不需要知道表结构也能完成查询我们也能在函数里写死业务口径、权限过滤条件。当然业务工具不能覆盖所有问题所以get_schema和run_query作为补充还是要保留但run_query的执行账号只授予只读权限并且只能访问指定的 schema。安全上还做了一个小措施给 MCP 工具调用加了一层审计日志。每次 Agent 执行了什么 SQL、返回了多少行、耗时多久都记录到一张表里。一方面是为了排查问题另一方面如果领导问“这个 AI 到底查了什么”我们至少有个交代。5. 把 Oracle MCP Agent 跑通对话调库、执行分析的完整链路5.1 从 MCP Server 到 Dify Agent两种接入方式MCP Server 写好了接下来就是让 Agent 应用能用起来。这里我们有两条路都实际验证过。第一种是把 MCP Server 封装成 Dify 自定义工具。Dify 本身支持自定义 OpenAPI 工具我们在 MCP Server 外面套一层 FastAPI把 MCP 的工具映射成 HTTP 接口然后在 Dify 的 Agent 应用里添加这些工具。好处是能直接用 Dify 现成的 Agent 编排、记忆、多轮对话能力坏处是多了一层桥接代码Dify 对 MCP 的原生支持还在完善中。第二种是用 FastAPI LangGraph 搭一个轻量 Agentic RAG由自己的 Agent 通过 MCP Client 直接连 Oracle MCP Server。这样更灵活Agent 的推理链路完全可控适合需要深度定制的场景代价就是很多东西要自己写。两种方式我们做了一个对比对比维度方式一Dify 工具封装方式二自建 Agent MCP Client开发成本低Dify 负责编排高需要写 Agent 循环灵活度受 Dify 工作流约束完全可控多轮记忆Dify 内置自己实现或接 LangGraph运维难度低可视化排查需要自己加日志和监控适合场景项目周期短、非技术团队使用长期迭代、复杂 Agent 应用我们最终生产环境选了方式一Dify 负责用户界面和流程业务工具跑在 MCP Server 里这样交付给业务部门的时候他们能在 Dify 后台自己调整问答提示词不用碰代码。5.2 一个真实的 Agent 会话拆解下面是一个我们系统里真实的对话过程拆开看 Agent 每一步做了什么。用户提问“本月华东区销售额和上月比怎么样”第一步Agent 判断这个问题需要调用数据库工具而不是在文档知识库里找答案。这个判断由 LLM 完成取决于系统提示词里对工具的说明。第二步Agent 可能先调用list_tables看看有哪些表。如果 MCP Server 里的工具说明写得足够清楚比如get_sales_trend的描述里直接写了“统计指定时间段的销售额”Agent 会跳过探索环节直接调用业务工具。第三步Agent 调用get_sales_trend(start_date2025-06-01, end_date2025-06-30, region华东)得到六月份每日销售额再调用同样的工具拿五月份数据然后在最终回复里计算环比。第四步LLM 把工具返回的结构化数字组织成自然语言回答比如“6 月华东区销售额 2.13 亿相比 5 月的 1.87 亿增长 13.9%。”这个链路看着简单但有一个细节经常被忽略Agent 拿到的数据可能不完整或不对比如六月份还没结束日销售额只到 26 号直接和整个五月对比会失真。我们后来在业务工具里加了数据完整性说明函数返回值里带上“截止日期”和“是否完整月份”字段Agent 回答时如果发现数据不完整会自动注明“按当前数据统计”这个细节在内部汇报时很加分。5.3 评测和兜底Query 不能生成时的处理实际运营过程中我们经常遇到一个报错提示“Agent couldnt generate a response. Please try again.” 这类问题的背后原因通常有三个。第一个是模型上下文超长。Agent 一轮对话里既检索了知识库又调用了多个工具加上工具返回的表格数据很容易把上下文塞满。尤其是run_query返回 50 行结果、每行十几个字段的时候token 消耗非常快。我们的对策是把工具返回的行数默认限制在 20 行以内并且让 Agent 在回答里只提炼关键数字不要让原始表格完全进入最终输出。第二个是 MCP Server 返回异常。工具调用超时、数据库连接池耗尽、SQL 执行报错这些异常信息如果原样返回给模型模型可能理解不了于是“思考”半天生成不了回答。我们统一做了异常格式化把错误转成简短的中文说明比如“数据库连接超时请重试”模型看到这个就能生成合理的兜底回答。第三个是模型本身对工具调用格式不稳定。同一个模型有时候会漏传必填参数有时候会把工具名写错。这种情况靠提示词优化只能缓解不能根治。最有效的办法是给工具设默认值、做参数容错另外在 MCP Server 端加一个固定的错误返回结构让模型知道该换个方式调用。我们还在 Dify 的 Agent 设定里加了一条兜底规则如果一轮对话中工具调用失败两次以上不要继续重试直接告诉用户暂时无法查询并建议稍后再试。避免 Agent 死循环消耗 token。6. 真实环境里的坑监听、连接、分页与权限排查6.1 Oracle 监听服务无法启动的排查链路整个项目里最折腾我们的不是 Dify 也不是 MCP而是 Oracle 本身的链路问题。最常见的一个就是监听服务无法启动现象是lsnrctl start执行后报错或者服务起来了但程序连不上。按照下面的排查清单过一遍基本能解决九成问题# 1. 检查监听状态 lsnrctl status # 2. 检查主机名解析 cat /etc/hosts # 3. 检查监听配置 cat $ORACLE_HOME/network/admin/listener.ora # 4. 检查端口占用 netstat -tlnp | grep 1521lsnrctl status显示TNS-01153: Failed to process string之类的错误通常是listener.ora里有不认识的参数或者主机名解析不出来。我们遇到过一次很隐蔽的情况服务器改过主机名/etc/hosts里没有把新主机名映射到 IPOracle 监听起不来加上之后立即恢复。另一个高频原因是端口被占。有的服务器上跑着其他服务占用了 1521 端口或者之前残留的 oracle 进程没杀干净。netstat确认后要么停掉占用进程要么在listener.ora里换一个端口。另外补丁版本也会影响监听稳定性。Oracle 11.2.0.4 这个版本本身有个时期性的补丁更新某些小版本对特定 Linux 发行版存在兼容问题表现为监听经常掉线、服务注册不稳定。如果生产环境可以接受停机时间建议把补丁打到最新的 PSU补丁更新再跑。实际操作中我们通常先看opatch lspatches确认当前补丁情况再决定是否升级。6.2 连接驱动的坑thin/thick、字符集与数据失真Python 连接 Oracle我们用python-oracledb的 thin 模式好处是不用装 Oracle Client可移植性强。但有些高级功能在 thin 模式不支持比如异步连接池的某些行为、特定的 TNS 加密配置。遇到这种情况就要切到 thick 模式它会自动找系统里的 Oracle Client 库oracledb.init_oracle_client(lib_dir/opt/oracle/instantclient_21)字符集是另一个重灾区。Oracle 服务端字符集和 Python 客户端不一致查出来的中文就是乱码。连接参数里强制指定conn oracledb.connect( user..., password..., dsn..., encodingUTF-8, nencodingUTF-8 )如果服务端本身是ZHS16GBK这种设置能保证 Python 侧拿到的字符串是正确的但前提是数据库中保存的中文本来就是合法编码。还有一个前面提过的数据失真问题在数据库里看起来正常的数字字段经过查询导出后变了样。根本原因是数字在数据库里是 NUMBER 类型Python 拿到的是decimal.Decimal或float转成字符串或写入 CSV 时可能触发科学计数法。规范做法是 SQL 里直接TO_CHAR转成期望的格式SELECT TO_CHAR(amount, FM999,999,999.00) AS amount FROM orders;6.3 权限最小化设计给 MCP Server 用的数据库账号权限一定要克制。我们创建了一个mcp_ro用户只授予只读权限CREATE USER mcp_ro IDENTIFIED BY password; GRANT CONNECT TO mcp_ro; GRANT SELECT ON sales.orders TO mcp_ro; GRANT SELECT ON sales.products TO mcp_ro;不授予SELECT ANY TABLE、不授予ALTER、CREATE等写权限。如果某些场景确实需要通过存储过程做复杂查询单独给EXECUTE权限不要让 Agent 直接拼任意 SQL。在应用层面还要再加两道防线。第一道是 MCP Server 里的 SQL 白名单run_query只放行 SELECT 开头且不含分号多语句拼接的 SQL第二道是行数限制任何查询最多返回 100 行。这两道防线能拦住九成以上的意外情况剩下的就靠审计日志兜底出了问题能溯源到具体某一次工具调用。权限这块还有一个容易忽视的点Dify 连接 Oracle 做知识库 ETL 的账号和 MCP Server 用的账号不要是同一个。知识库账号需要读更多表MCP 账号只需要读 Agent 可能用到的几张业务表职责分离哪边出了问题都不至于影响另一边。最后再分享一点小经验整套系统上线跑了一个多月我最深的体会是架构选型固然重要但真正决定体验的是细节。MCP Server 的工具如果超过十个LLM 就经常选错工具工具描述写得含糊Agent 就会反复试探数据库返回结果太多模型就抓不住重点。这些都不是什么高深技术但每一条都能显著影响用户感受。如果你们团队刚准备动手我的建议是分三步走先用 Dify 做一个文档知识库跑通全流程再写一个只有三个工具的 Oracle MCP Server 做“查表、查结构、查数据”最后才扩展到业务工具和 Agentic RAG 的复杂链路。步子别迈太大每一步都跑稳后面反而快。这套东西后续还能延伸的方向也很多比如把 MCP 工具从 Oracle 扩展到其他内部系统、在 Agent 对话里加入市调和竞品分析的外部检索、或者用 LangGraph 把多步分析任务编排成自动化报告。方向是有的但前提是把眼前这套“文档知识库 数据库 Agent”的组合用扎实毕竟企业内部真正高频的需求往往就是这么朴实的一问一答。
