Agentic AI, Built on Dify x OceanBase in Practice

Foreword: Viewing the Trend from a Contributor’s Perspective

As the seventh-ranked contributor by commit count in Dify’s main repository, Liang Bowen has done a great deal of AI-application work over the past two years: VDB integrations, automated testing, RAG pipelines, Function Calling, and CLI and SDK optimizations. Today we won’t talk about obscure code—only the pitfalls we’ve stumbled into, the trends we’ve seen, and why OceanBase became, in our eyes, an “underrated production-grade foundation.”

01. Dify in Relation to Agentic AI

Agent-building approach: Low-code or High-code?

When discussing AI Agent applications, there’s a steady stream of related debate—for example, the relationship between Agent and Agentic, how to build a Workflow, and whether the agent-building approach should be low-code or high-code. So what exactly is the key to building AI Agent applications? We can glean some insight from the development trend of AI Agents. The biggest difference is the shift from the original single, stateless problem to a more contextual, stateful, indirect, and increasingly complex problem context, which is then looped over—decompose, act, decide, loop.

In summary, the key factor in building an Agent is how to turn the relevant capabilities into deliverable, scalable products that meet the ever-growing demands of the market. Through productization, Dify can more effectively translate AI technology into real-world applications—which is the true reason it has gained a broader user base and higher market acceptance worldwide.

The Agent Shift - AI Agents vs Agentic AI

The shift from Generative to Agentic has four key directions: Contextual Cognition, Adaptive Learning Systems, Hierarchical Goal Execution, and Collaborative Interaction Framework. Over the past two years, we’ve already built quite a few Agent applications. What we need at the current stage is not to research how to build a single Agent, but to build an intelligent paradigm—one that transmits and permeates from an entity form into a method, and therefore places greater emphasis on value delivery and on the upstream and downstream needs of the scenario, ceding more local decision-making power and context, until ultimately a method permeates into the application system. Thus, Agentic AI can apply Findings in a more layered way, decide based on Context Awareness, and take action.

From Generative to Agentic

From the above, we can conclude that in the shift from Generative to Agentic, the biggest difference is the move from the original single, stateless problem to a more contextual, stateful, indirect, and increasingly complex problem context, which is then looped over—decompose, act, decide, loop. Therefore, we no longer focus solely on the one-to-one correspondence between Prompt and Answer or on Prompt Engineering ability; instead, we build context more deeply, in a more open and more anticipatory form, to drive behavior and decisions.

Based on our summary of the platform’s needs, we identified the following key directions that the platform must support:

1. Looping
The platform needs to decompose complex problems and sub-problems (sub-tasking) to efficiently handle both the overall problem and each sub-problem. Therefore, for both local and overall problems, the platform should provide a looping mechanism—Dify’s new-style Looping.

2. Building Sub-Contexts
As new findings and new progress continually emerge under sub-tasks, we need to add them to the Sub-Contexts.

3. Termination
With new findings in hand, we need to reason and decide about the single problem, the sub-problems, and the overall problem, determining Termination based on certain conditions to finally complete the entire loop.

4. Execution
When the loop ends after attribution, we need to further strengthen behavior and logic with tools, so Execution support is also required.

As the figure shows, the red-and-blue part on the left describes the form of Agents, while the right side shows the capabilities the platform needs to support.

Decomposing Agentic AI’s Demands on a Capability Platform

In summary, to support Agentic AI’s advanced features, the platform must provide a powerful infrastructure that meets the full range of needs—from sub-task processing to looping, reasoning, decision-making, and execution. This involves not only technical implementation but also a deep understanding of user interaction and application scenarios.

• A more reliable and scalable runtime framework;
• More usable Agentic hybrid orchestration: enabling the hybrid orchestration of humans and intelligence;
• Stronger context support: supporting composite, multi-level, multi-stage context processing;
• Stronger knowledge retrieval: supporting more layered, more systematic use of knowledge;
• More diverse plugin-component support and a more open ecosystem: the platform and middleware need extensive plugin support and ecosystem complements; building a powerful ecosystem and surrounding support is crucial.

Dify’s New Capability Support for Agentic AI

In summary, Dify’s response in supporting new Agentic AI capabilities is reflected in the following aspects:

1. Expanding the plugin marketplace: Dify will enhance its plugin marketplace to incorporate first-party and third-party capabilities, complementing and refining the platform’s functionality.

2. The new-style Loop: building a local looping mechanism capable of task decomposition, decision-making, and execution. Each step leverages richer contextual information to achieve distributed perception and prompt-driven decision-making.

3. Agent embedding: Dify will integrate Agent, Tooling, Function Calling, MCP, and other capabilities to provide more flexible scheduling and behavior enhancement at both the local and global levels.

Through these measures, Dify aims to build a more robust and flexible Agentic AI platform—one that can adapt to ever-changing business needs and technological progress while offering users a comprehensive, open, and scalable solution.

The Basic Architecture of Dify and Its Middleware Components

Facing enterprise-grade application needs, Dify plays three main roles at the basic middleware-architecture layer:

• API Service: an all-around backend and the runtime carrier for the Agent, handling all synchronous requests; it needs high-concurrency, low-latency database connections;
• Worker Service: knowledge-base processing, including the scheduling and execution of asynchronous tasks (such as document parsing and Embedding generation); it relies on distributed locks, task queues, and large-capacity storage to guarantee reliable task distribution and retries;
• Plugin Daemon Service: after the plugin marketplace was decoupled, this service took on a large amount of connection and orchestration work for external systems (databases, vector stores, third-party APIs), further amplifying the access pressure on storage and cache.

Therefore, Dify has strong demands for middleware capabilities at all three of these levels, which can be summarized into the following three parts:

• Database: document-chunk storage, application metadata, rich context, session records, and so on—relying on an integrated Database to provide concrete support;
• Cache: distributed locks, Celery asynchronous task distribution;
• VDB: multimodal retrieval capabilities such as vector search, keyword search, hybrid search, and knowledge-base document chunks.

If you stress-test Dify, you’ll find that, when facing massive knowledge retrieval and session-message counts, the large model’s service load is not as heavy as expected; more of the load is concentrated on the API and Plugin Daemon’s connections to the Database. Large volumes of context, read/write operations, and concurrency all affect the scope and concurrency that can be served, so choosing a suitable vector database becomes especially critical.

As for the Vector DB, Dify’s support for each vector database is fairly standardized, able to unify keyword search, full-text search, vector search, hybrid search, document filtering, and other capabilities; it currently supports as many as 26 vector databases. Among them, the VDBs covered by Dify’s CI automated testing include: OceanBase (AK, vector, full-text search), a certain DB (AK, Official SaaS, vector), and others. Of the two popular distributed databases—OceanBase and the certain DB—OceanBase has prioritized full-text index support.

RAG: The Interplay Between Dify and a VDB (Using OceanBase as an Example)

For the vector-DB retrieval needs of Dify’s services—RAG Retrieval, DataSet, RAG 2.0 Pipeline (DataSources), Plugins, and so on—OceanBase can essentially fully satisfy them, achieving an All-in-One-AI DB. As a vectorization-capable, natively distributed general-purpose database, OceanBase supports application databases, Cache (OBKV-Redis), hybrid search (scalar + vector + full-text), keyword search, and a rich set of other features and use cases, providing one-stop capability support for building AI applications on Dify.

Hybrid search: Dify needs to unify semantics at the Embedding layer, so it requires vector-search capability, and then keyword-search capability to match keywords. OceanBase 4.3.3 supported keyword search late last year, and this year OceanBase 4.3.5.1 also supports full-text search. On the basis of simultaneously supporting vector search, full-text search, and metadata filtering, it can achieve hybrid search, and combine ReRanker Models and Embedding Models for reranking—essentially meeting the needs of vectorization scenarios.

High-dimensional vectors: as a database with notable OLTP performance, OceanBase can perfectly support metadata filtering, and it already supports high-dimensional vectors; the latest version, OceanBase V4.4.0, supports up to 16,000 dimensions.

Multimodal vectors: support for a broader range of vector types, such as Key and Embedding models.

Multi-index vector retrieval: support for multi-index retrieval to achieve different representations of Embeddings.

Tokenization strategies: can greatly enhance full-text index performance.

Management-tool support: a variety of CLI and GUI tools—OBD, OMS, OCP, obdiag, OBShell, ob-operator, ODC, and more—achieve full-lifecycle data management from deployment to operations, including deployment, data migration, monitoring and alerting, and scaling, meeting the needs of developers, enterprise users, and individual users across various application scenarios.

SQL-based operations: for developers, OceanBase supports not only Python operations but also SQL-based operations, making operations more convenient.

Scalability: it can achieve transparent horizontal scaling and supports rapid scaling for the business.

Through OceanBase’s All-in-One-AI DB capabilities, Dify achieves “one set of SQL to rule them all” in the RAG 2.0 era, letting enterprises focus on business innovation rather than piecing together infrastructure.

In addition, OceanBase Desktop is the simplest way to set up a single-node OceanBase plus a visual management interface based on Docker. Based on MCP, you can easily build a complete Dify Agent platform using Dify and OceanBase Desktop to create a lighter, easier-to-use RAG application—well suited for getting started. For detailed setup steps, see: Dify + OceanBase + MCP: A Three-Way Combo for Easily Building RAG Applications

02. One-Stop Capability Support: OceanBase For Dify

As a vectorization-capable, natively distributed general-purpose database, OceanBase supports application databases, Cache (OBKV-Redis), hybrid search (scalar + vector + full-text), keyword search, and a rich set of other features and use cases, providing one-stop capability support for building AI applications on Dify.

1. Database
OceanBase’s DB capability is reflected not only in vector search and knowledge-base support, but also in full compatibility with the MySQL protocol. It can therefore meet the Database-capability requirements Dify has for middleware, mentioned above, with high-frequency context access and maintenance. The OceanBase GitHub repository already supports a dify-for-mysql-compatible branch. Repository address:

https://github.com/oceanbase/dify-on-mysql

2. Cache (OBKV-Redis)
OBKV-Redis is a persistent cache built on OceanBase that is fully compatible with the Redis protocol. It natively inherits OceanBase’s high performance, transactions, distribution, multi-tenancy, high reliability, and other foundational capabilities, helping enterprises unify their tech stack—satisfying the business’s need for a multi-model NoSQL database while reducing the complexity of database operations.

3. VDB
Support for common vectorization capabilities such as vector search, keyword search, hybrid search, and knowledge-base document chunks.

The combination of OceanBase and Dify provides enterprises with a flexible, scalable, and powerful middleware solution that supports full-chain AI-application development from low-code to high-code. It provides comprehensive support not only technically but also at the business level, delivering significant gains—including simplified architecture, lower operations costs, and enhanced business flexibility and scalability—enabling enterprises to quickly adapt to market changes and innovate their business models.

Dify ✖️ OceanBase: Rotating Support Between Ecosystem and Enterprise-Grade Products

As a production-grade Agentic platform system, enterprise users and infrastructure urgently need systematic support: on one hand, commercial support provides practical and reliable solution support; on the other, the open-source ecosystem fully expands the capability vision and system. The collaboration between Dify and OceanBase is competitive not only at the feature level but also shows significant advantages in community participation and enterprise-grade support, fully meeting the needs of a production-grade Agentic platform system. This collaboration model can bring multiple benefits to the business:

Open ecosystem: broad community support and a plugin ecosystem

Dify and OceanBase have active open-source communities on many platforms, including GitHub, community forums, product websites, Discord, and more. Dify also has a Dify Marketplace containing 387+ plugins, providing developers with rich resources and tools to extend and customize applications.

Support capability: enterprise-grade support and a training system

The Dify Enterprise edition offers multi-tenancy, scalable FaaS capabilities, and enterprise-grade governance features. Dify’s partner/training system includes SaaS, qualified consulting services, qualified service providers, and mature industry solutions. OceanBase likewise offers an enterprise-assurance edition and a community-co-build edition, supporting multi-tenancy, production-grade data assurance, and a governance platform. In addition, OceanBase provides an OBCA/OBCP/OBCE certification and talent-training system. Therefore, both Dify and OceanBase have enterprise-grade support capabilities and complete training systems, ensuring that enterprises can fully learn and use them.

03. Application Practice: A First Look at a Conversational Psychological Scale for People in Drug Rehabilitation

ChatFlow Built with OceanBase + Dify

No amount of theory beats a real-world battle. Teacher Kang Kai built a deeply meaningful application based on a real problem: a conversational psychological assessment scale.

Pain point: traditional drug-rehabilitation treatment relies on psychological scales (efficient but yielding single-dimension information) and psychological counseling (information-rich but extremely time-consuming). We wanted to use AI to fuse the strengths of both.

Solution: we built a conversational AI that, like a psychological counselor, completes scale assessments through natural conversation.

In the treatment stage of traditional drug-rehabilitation work, there are two methods for gathering information and background on the people in rehabilitation: psychological assessment scales and psychological counseling (individual interviews). Scale tests are convenient and efficient and can be completed in a very short time, but they yield single-dimension information and have relatively poor assessment quality; individual interviews yield a large amount of information and better assessment quality, but they are laborious and time-consuming, often requiring an hour to complete. With the spread of AI technology, this project attempts to deeply integrate emerging AI technologies such as large language models with the daily work of drug rehabilitation, developing a conversational scale that fuses the structured, quantifiable advantages of scale tests with the rich contextual information of individual interviews—achieving a more accurate and efficient assessment method.

Business Data-Processing Flow

The data sources of the conversational scale’s business flow mainly include individual interviews and scale tests. Individual interviews are generally unstructured, and their textual information is extracted and integrated into structured data. Scale assessment results for an individual are generally numeric—a fairly tidy structured form—but to improve assessment quality, professionals need to make judgments and expand the information based on each person’s situation, so the assessment results turn from structured numeric information into unstructured data, ultimately generating structured scores and unstructured text summaries in real time and storing them in the database. Because drug-rehabilitation facilities are spread across the entire province and are geographically dispersed, a fairly large-scale distributed deployment is needed; combined with data-security and concurrency requirements, this led to the choice of OceanBase—a vectorization-capable, natively distributed general-purpose database.

System Architecture

The system architecture for the conversational scale comprises three layers in total:

• Data layer (Data Service): the OceanBase distributed database (unified storage of structured numeric values + unstructured text)
• Service layer (Local Server): the Dify framework + Docker containerized deployment
• Model layer (LLM Model Service):
  – Main conversation engine: Alibaba Cloud’s Tongyi Qianwen large language model
  – Multi-agent collaboration (planned)
  ▸ Agent-1: responsible for conversation generation and follow-up questions;
  ▸ Agent-2: responsible for personal-information retrieval and data cleanup;
  ▸ Agent-3: responsible for scoring, summarization, and knowledge-base write-back.

Data-Processing Flow

The conversational scale’s overall data-processing flow, from uploading a document to finally generating the overall Q&A output, comprises four steps:

Step 1: Upload a custom-authored scale → document processing → question-list standardization;
Step 2: Multi-round Chatflow conversational administration → the large model dynamically refines and processes the questions → the respondent answers in natural language → conversational questions are generated;
Step 3: Question templating → large-model scoring → generation of structured scores + an unstructured interview record;
Step 4: Results written into OceanBase → synced to the individual knowledge base’s treatment plan → integration with the core education-and-correction business system.

ChatFlow Orchestration Design

The ChatFlow orchestration design comprises four nodes—document parsing, conversation, scoring, and storage—each with an independent functional implementation:

• Document-parsing node: PDF / DOCX → structured question bank
• Conversation node: LLM follow-up questions, clarification, emotion recognition
• Scoring node: dimensional scores + risk alerts
• Storage node: results landed in the database + knowledge-base update

Application Example

The actual assessment interface of the conversational scale is shown in the figure below. Enter the name of the person in rehabilitation at the start of the page to begin the assessment process. Through continuous interactive conversation, the specific information and material needed for the assessment is ultimately obtained.

Application Results and Follow-up Plans

The conversational scale fuses the strengths of both individual interviews and scale tests, meeting the needs of drug-rehabilitation work while perfectly dovetailing with existing law-enforcement systems:

• It retains the scale’s standardized scoring while supplementing contextualized, personalized information through conversation;
• The entire conversation process leaves a trail, making it traceable and auditable;
• Scores and interview records are automatically stored in the database, reducing manual-transcription errors;
• It supports both offline and online modes, adapting to the network environment of closed-management areas;
• It supports batch administration by sub-facility and squad, with results aggregated in real time to the provincial bureau’s command center;
• It can seamlessly interface with existing law-enforcement and case-handling systems, automatically generating individual education-and-correction plans.

Taking the “conversational psychological scale” as an entry point, this project attempts to use a large language model to bridge the gap between traditional scales and individual interviews, achieving intelligent, fine-grained, and efficient psychological assessment of people in rehabilitation; it has currently completed initial prototype validation. Going forward, we will continue to iterate on the question bank, clinical feedback, and empirical research, dynamically optimizing the custom-authored scale; introduce multidimensional data such as voice and micro-expressions to achieve multimodal input and improve assessment accuracy; and perform end-to-end encryption with tiered desensitization of sensitive information, ensuring compliance with the Ministry of Justice’s data-security standards.

The next step is to apply the conversational scale within the core business system: based on the Q&A material the conversational scale produces, form an individual psychological-correction document for each person and store it in the knowledge base to form an individual education-and-correction plan, ultimately aggregating and fusing these into the individual knowledge base’s education-and-correction plan for officers to reference. Through continuous refinement and optimization of the education-and-correction plans, we will finally integrate with the drug-rehabilitation law-enforcement system that is the core business system.

04. Ecosystem Synergy and Future Outlook

Dify + OceanBase can meet developers’ needs across different scenarios.

Developers can use Dify to quickly build and iterate on upper-layer applications, while relying on OceanBase to uniformly handle structured data, cache, and vector search—thereby focusing more energy on the logic and innovation of the application itself and reducing time spent maintaining heterogeneous underlying components. You can launch an evolvable Agentic application in just 30 minutes. We welcome community friends to explore more scenario practices together~

Finally, we’d like to recommend the WeChat account of Lao Ji, the head of OceanBase open source: “Lao Ji’s Tech Talk.” It continuously publishes all kinds of technical content related to #Database, #AI, and #Tech Architecture. If you’re interested, feel free to follow!

“Lao Ji’s Tech Talk” not only hopes to keep bringing you valuable technical sharing, but also hopes to contribute to the open-source community together with everyone. If you recognize the value of the OceanBase open-source community, light up a little star ✨! Every Star you give is the motivation behind our efforts.