Agentic AI, 基于 Dify x OceanBase 的实践

作者：梁博文、康慨
前言：从贡献者视角看趋势

作为在 Dify 主仓提交代码数第七位的贡献者，梁博文过去两年做了大量 VDB 对接、自动化测试、RAG 流水线、Function Calling、CLI 与 SDK 的优化等 AI 应用相关工作。今天不谈晦涩代码，只谈我们踩过的坑、看到的趋势以及 OceanBase 为什么成了我们眼中“被低估的生产级基座”。
01. Dify 之于 Agentic AI

Agent 构建模式：低代码（Low-code）还是高代码（High-code）？
在探讨 AI Agent 应用时，存在持续大量的相关讨论，例如 Agent 与 Agentic 的关系、工作流 Workflow 的构建方式、Agent 构建模式应该是低代码还是高代码等。那么到底什么才是构建 AI Agent 应用的关键点呢？从 AI Agent 的发展趋势可以略知一二。最大的区别就是从原来单个无状态的问题变成了一个更有符合上下文的、有状态的、间接的、直接性复杂问题上下文，然后进行循环，分解、行动、决策、循环。

综上所述，构建 Agent 的关键因素是如何将相关能力转化为可交付、可扩展的产品，以满足不断增长的市场需求。通过产品化，Dify 能够更有效地将 AI 技术转化为实际应用，这也是其在全球范围内获得更广泛用户基础和更高市场接受度的真正原因。
Agent 转变 - AI Agents vs Agentic AI

从 Generative 到 Agentic 的转变，有四个关键方向：上下文感知（Contextual Cognition）、自适应学习系统（Adaptive Learning Systems）、分层目标执行（Hierarchical Goal Execution）、协作交互框架（Collaborative Interaction Framework）。在过去两年间，我们已经构建了相当多的 Agent 应用，当前阶段我们需要的不是研究如何构建一个 Agent，而是构建一种智能范式，从实体形态向方法渗透传递，因此需要更重视价值交付与场景上下游需要，更多让渡局部的决策权力和上下文，最终形成一种方法向应用体系渗透。因此 Agentic AI 可以更有梯次地运用发现（Findings），从上下文感知（Context Awarness）中决策，并采取行动。

从 Generative 生成式到 Agentic 智能体式

从上文可以得出从 Generative 生成式到 Agentic 智能体式，最大的区别就是从原来单个无状态的问题变成了一个更有符合上下文的、有状态的、间接的、直接性复杂问题上下文，然后进行循环，分解、行动、决策、循环。因此我们不再仅仅关注提示（Prompt）与回答（Answer）之间的一一对应关系及 Prompt Engineering 能力，而是能够以一个更开放、更有预期的形态，更深度的构建上下文进行行为与决策。
基于对平台需求的总结，我们确定了以下几个关键方向，这些方向是平台必须支持的：
1. Looping
平台需要将复杂问题和子问题进行拆分（Sub-tasking），以实现对整体问题和各个子问题的高效处理。因此对于局部和整体问题，平台应提供一个循环机制，即 Dify 的新式循环 Looping。
2. Building Sub-Contexts
随着子任务下不断出现新发现和新进展，我们要把它补充到 Sub-Contexts 中。
3. Termination
有了新发现以后，我们需要对单一问题、子问题和总问题进行推理和决策，基于一些条件确定 Termination，最终完成整个循环。
4. Execution
在归因后结束循环时，需要进一步用工具加强行为跟逻辑，因此也需要 Execution 的支持。

从图中可以看出，左侧红蓝色的部分描述了 Agents 的形态，右侧展示了平台需要支持的能力。
Agentic AI 对能力平台的需求分解

综上所述，为了支持 AgenticAI 的高级功能，平台必须提供一个强大的基础架构，以满足从子任务处理到循环、推理、决策和执行的全方位需求，这不仅涉及到技术层面的实现，也包括对用户交互和应用场景的深入理解。

• 更可靠和可扩展的运行时框架；
  
• 更易用的 Agentic 混合编排能力：实现人与智能的混合编排；
  
• 更强大的上下文支持：支持复合的、多层次的、多阶段的上下文处理；
  
• 更强大的知识检索：支持更有层次的、更成体系的知识运用；
  
• 更多样的插件组件支持和更开放的生态补充：平台及中间件需要很多的插件支持和生态补充，构建一个强大的生态系统和周边生态支持至关重要。
  

Dify 对 Agentic AI 的新能力支持

总结来说，Dify 对 Agentic AI 的新能力支持响应体现在以下几个方面：
1. 插件市场的扩展：Dify 将增强其插件市场，以纳入第一方和第三方的能力，从而补充和完善平台的功能。
2. Loop 新式循环：构建一个能够进行任务分解、决策和执行的局部循环机制。每个环节都将利用更丰富的上下文信息，以实现分布式感知和提示驱动的决策。
3. Agent 智能体嵌入：Dify 将集成 Agent、Tooling、Function Calling、MCP 等多种能力，以在局部和全局层面提供更灵活的调度和行为增强。
通过这些措施，Dify 旨在打造一个更加健壮和灵活的 Agentic AI 平台，该平台将能够适应不断变化的业务需求和技术进步，同时为用户提供一个全面、开放且可扩展的解决方案。
Dify 与中间件组件的基本架构

面对企业级应用需求，Dify 在中间件基本架构层承担的角色主要有以下三个：

• API Service：全能型后端，Agent 运行载体，承载所有同步请求，需要高并发、低延迟的数据库连接；
  
• Worker Service：知识库处理，包括异步任务（如文档解析、Embedding 生成）的调度和执行，依赖分布式锁、任务队列以及大容量存储，以保证任务可靠分发与重试
  
• Plugin Daemon Service：插件市场解耦后，该服务承担了大量外部系统（数据库、向量库、第三方 API）的连接与编排工作，进一步放大了对存储和缓存的访问压力。
  

因此，Dify 在以上三个层面对中间件能力都有强烈诉求，整体可归纳为以下三部分：

• Database：文档片段存储、应用元数据、丰富的上下文、会话记录等，依赖一体化的 Database 具体提供支持;
  
• Cache：分布式锁、Celery 异步任务分发；
  
• VDB：向量检索、关键字检索、混合检索、知识库文档片段等多模态检索能力。
  

如果对 Dify 进行压测，可以发现，面对海量的知识检索和会话消息数，大模型的服务负载没有预期中大，更多负载集中在 API 及 Plugin Daemon 对  Database 的连接上，大量的上下文、读写操作、并发数，影响了能够服务的范围与并发数，因此选择一款合适的向量数据库变得尤为关键。
就 Vector DB 来说，Dify 对每一种向量数据库的支持力度都比较规范，能够统一关键字检索、全文检索、向量检索、混合检索、文档过滤等多种能力，并且当前支持的向量数据库多达26种。其中，Dify CI 自动化测试覆盖的 VDB 包括：OceanBase（AK、向量、全文检索）、某 DB （AK、Official SaaS、向量）等。其中对于 OceanBase 和某 DB 两个比较流行的分布式数据库，OceanBase 已优先支持全文索引。
RAG：Dify 与 VDB （OceanBase 为例）的联动

对于 Dify 的 RAG Retrival、DataSet、RAG 2.0 Pipeline (DataSources)、Plugins 等服务对于 Vector DB 的检索需求，OceanBase 基本可以完全满足，实现 All-in-One-AI DB。OceanBase 作为一款支持向量化的原生分布式通用数据库，支持应用数据库、Cache（OBKV - Redis）、混合检索（标量+向量+全文）、关键字检索等丰富的功能和使用场景，对基于 Dify 的 AI 应用实现提供了一站式能力支持。
混合检索：Dify 需要在 Embedding 层面进行语义统一，因此需要向量检索能力，其次需要关键字检索能力匹配关键字，OceanBase 4.3.3 在去年年低已支持关键字检索，并且今年 OceanBase 4.3.5.1 也支持了全文检索。在同时支持向量检索、全文检索、元数据过滤的基础上可以实现混合检索，并结合 ReRanker Models 和 Embedding Models 进行重排，基本满足向量化场景的使用需求。
高维向量：作为一款 OLTP 性能显著的数据库，OceanBase 对于元数据过滤可以完美支持，同时也已经支持了高维向量支持需求，目前最新版本 OceanBase V4.4.0 最高支持 16000 维。
多模态向量：支持 Key、Embedding 模型等更广泛的向量类型。
多索引检索向量：支持多索引检索，以实现 Embedding 的不同表现。
分词策略：可以大大增强全文索引性能。
管理工具支持：有 OBD、OMS、OCP、obdiag、OBShell、ob-operator、ODC 等多种黑屏与白屏工具，实现部署、数据迁移、监控告警、扩缩容等从部署到运维的数据全生命周期管理，满足开发者、企业用户、个人用户等多种用户在各种应用场景的使用需求。
SQL 化运维：对于开发者而言，不仅支持 Python 进行操作，也支持 SQL 化操作，运维操作更加便易。
可扩展性：可实现透明水平扩展，支持业务快速地扩缩容。
通过 OceanBase 的 All-in-One-AI DB 能力，Dify 在 RAG 2.0 时代实现了“一套 SQL 打天下”，让企业专注于业务创新而非基础设施拼图。

此外，Oceanbase 桌面版是基于 Docker 搭建 Oceanbase 单机版本和可视化管理界面的最简便途径，基于 MCP，使用 Dify 和 Oceanbase 桌面版可以轻松搭建一个完整的 Dify Agent 平台，实现更轻量易用的 RAG 应用，适合初步上手，具体搭建步骤可参考：《Dify + OceanBase + MCP：三剑合璧，轻松构建 RAG 应用》
02. OceanBase For Dify 的一站式能力支持

OceanBase 作为一款支持向量化的原生分布式通用数据库，支持应用数据库、Cache（OBKV - Redis）、混合检索（标量+向量+全文）、关键字检索等丰富的功能和使用场景，对基于 Dify 的 AI 应用实现提供了一站式能力支持。
1. Database
OceanBase 的 DB 能力不仅体现在向量检索与知识库支持，同时也完全兼容 MySQL 协议，因此可以满足上文提到的 Dify 对于中间件的 Database 能力要求，可以高频次访问上下文与维护。目前 OceanBase Github 仓库已经支持了兼容 dify-for-mysql 的分支。仓库地址：
https://github.com/oceanbase/dify-on-mysql
2. Cache（OBKV-Redis）
OBKV-Redis 是基于 OceanBase 开发的完全兼容 Redis 协议的持久化缓存数据，原生继承了 OceanBase 的高性能、事务、分布式、多租户、高可靠等基础能力，可以帮助企业统一技术栈，在满足业务对多模 NoSQL 数据库诉求的同时，减少企业在数据库运维上的复杂度。
3. VDB
支持向量检索、关键字检索、混合检索、知识库文档片段等常用的向量化能力。

OceanBase 与 Dify 的结合为企业提供了一个灵活、可扩展、强大的中间件解决方案，支持从低代码到高代码的全链路 AI 应用开发。不仅在技术上提供了全面的支持，而且在业务层面上也带来了显著的增益，包括简化架构、降低运维成本、增强业务灵活性和扩展性，使得企业能够快速适应市场变化，创新业务模式。
Dify ✖️ OceanBase

生态与企业级产品的支持轮动

作为生产级 Agentic 平台体系，企业用户与设施亟需体系化支持，一方面商业支持提供切实可靠的解决方案支持，一方面开源生态充分扩展能力愿景与体系。Dify 与 OceanBase 的合作不仅在功能层面上具有竞争力，而且在社区参与度和企业级支持方面展现出显著优势，完全满足生产级 Agentic 平台体系的需求。这种合作模式可以为业务带来多方面好处：
开放生态：广泛的社区支持与插件生态
Dify 和 OceanBase 在很多平台都拥有活跃且的开源社区，包括 GitHub、社区论坛、产品官网、Discord 等诸多平台，同时 Dify 还拥有一个包含 387+ 插件的 Dify Marketplace，这为开发者提供了丰富的资源和工具，以扩展和定制应用。
支持能力：企业级支持与培训体系
Dify 企业版具备多租户、可扩展的 FaaS 能力和企业级管控特性，Dify 的合作伙伴/培训体系包含 SaaS、合资格咨询服务、合资格服务提供商、成熟行业解决方案。OceanBase 也提供企业保障版本和社区共建版本，支持多租户、生产级数据保障、管控平台。此外 OceanBase 还提供 OBCE/OBCP/OBCE 认证人才培训体系。因此，Dify 和 OceanBase 都具备企业级支持能力和完整的培训体系，确保企业能够充分学习使用。

03. 应用实践：戒毒人员对话式心理量表初探

Oceanbase + Dify 实现的 ChatFlow

理论说再多，不如一场实战。康慨老师基于实际问题做了一个极具社会意义的应用：对话式心理评估量表。
痛点：传统的戒毒矫治，依赖心理量表（高效但信息单一）和心理咨询（信息丰富但极耗时）。我们希望用 AI 融合两者优点。
解决方案：我们打造了一个对话式 AI，它能像心理咨询师一样，通过自然对话来完成量表评估。
在传统戒毒工作的矫治环节中，获取戒毒人员的信息和背景有心理测评量表和心理咨询（个别谈话）两种方法。量表测试便捷高效，很短时间即可完成，但获取信息单一，评估效果较差；个别谈话获取信息量大，评估效果较好，但费事费力，通过需要1个小时。随着人工智能技术的普及，尝试将大语言模型等 AI 新兴技术与日常戒毒日常工作深度融合，开发对话式量表，融合量表测试的结构化、可量化优势与个别谈话的丰富语境信息，实现更加准确且高效的测评方法。
业务数据处理流程

对话式量表业务流程的数据来源主要包含个别谈话和量表测试。个别谈话一般为非结构化形式，通过对文本信息进行信息提取整合成结构化数据。量表的个人评测结果一般为数字，是比较规整的结构化形式，但为了提高评估质量，需要专业人士结合每个人的情况进行评判及信息拓展，测评结果会从结构化形式的数值信息变成非结构化数据，最终实时生成结构化评分与非结构化文本摘要存储在数据库中。由于戒毒场所遍布全省，地理分布比较广，需要进行较大规模的分布式部署，同时有数据安全与并发需求，因此选用了具备向量化能力的原生分布式通用数据库 OceanBase。
系统架构

对话式量表实现的系统架构一共包含三层：

• 数据层（Data Service）：OceanBase 分布式数据库（结构化数值 + 非结构化文本统一存储）
  
• 服务层（Local Server）：Dify 框架 + Docker 容器化部署
  
• 模型层（LLM Model Service）：
  – 主对话引擎：阿里云通义千问大语言模型
  – 多 Agent 协同（规划中）
  ▸ Agent-1：负责对话生成与追问；
  ▸ Agent-2：负责个人信息调用与数据规整；
  ▸ Agent-3：负责评分、摘要与知识库回写。
  

数据处理流程

对话式量表整体的数据处理流程从上传文档到最终生成总体问答成果一共分为四个步骤：
Step 1：上传自编量表 → 文档处理 → 问题列表标准化；
Step 2：多轮 Chatflow 对话施测 → 大模型动态细化处理问题 → 受测者自然语言回答 → 生成对话问题；
Step 3：问题模板化 → 大模型评分 → 生成结构化得分 + 非结构化访谈纪要；
Step 4：结果写入 OceanBase → 同步至个体知识库矫治方案 → 对接教育矫治核心业务系统。

ChatFlow 编排设计

ChatFlow 的编排设计共分为文档解析、对话、评分、存储四个节点，每个节点都有独立的功能实现：

• 文档解析节点：PDF / DOCX → 结构化题库
  
• 对话节点：LLM 追问、澄清、情感识别
  
• 评分节点：维度得分 + 风险预警
  
• 存储节点：结果落库 + 知识库更新
  

应用示例

对话式量表的实际测评界面如下图所示，在页面开始处输入戒毒人员姓名，即可开始测评流程。通过不断的交互对话，最终获取测评所需的具体信息与资料。

应用效果及后续规划

对话式量表融合了个体谈话和量表测试两者优点，在满足了戒毒工作需求的同时又完美衔接现有执法系统：

• 保留量表的标准化评分，可通过对话补充情境化、个性化信息；
  
• 对话过程全程留痕，可回溯、可审计；
  
• 评分与访谈纪要自动入库，减少人工誊录错误；
  
• 支持离线/在线双模式，适应封闭管理区网络环境；
  
• 支持分所与分队批量施测，结果实时汇聚至省局指挥中心；
  
• 可与现有执法办案系统无缝衔接，自动生成个体教育矫治方案。
  

本项目以“对话式心理量表”为切入点，尝试用大语言模型弥合传统量表与个别谈话之间的鸿沟，实现戒毒人员心理评估的智能化、精细化与高效化，目前已初步完成原型验证。后续将持续迭代题库和临床反馈与实证研究，动态优化自编量表；引入语音、微表情等多维数据，完成多模态输入，提高评估精度；并进行全链路加密，对敏感信息分级脱敏，确保符合司法部数据安全规范。
下一步计划将对话式量表应用在业务核心系统中，针对对话式量表产生的问答资料，形成针对每个个人的个体心理矫治文档，存储到知识库形成针对个体的教育矫治方案，最终汇总融合为个体知识库的教育矫治方案，用于干警进行文档查阅。通过不断完善和优化教育矫治方案，最后对接核心业务系统戒毒执法体系。

04. 生态协同与未来展望

Dify  + OceanBase 可以满足开发者不同场景的使用需求。
开发者可以利用 Dify 快速构建和迭代上层应用，同时依靠 OceanBase 统一处理结构化数据、缓存和向量检索，从而将更多精力聚焦于应用本身的逻辑与创新，减少在底层异构组件维护上的耗时。30 分钟即可上线可演化的 Agentic 应用，欢迎社区小伙伴一起探讨更多的场景实践~

最后为大家推荐这个 OceanBase 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个Star，都是我们努力的动力。

来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除