Dify:面向企业级LLM应用开发的现代化全栈框架深度技术解析

在线体验各类最新模型,更有模型 免费Token 额度领取!
立即体验
简介: 当 AI 应用从 Demo 走向生产,问题已不再只是模型效果,而是工程化与系统能力。本文从架构与实现机制出发,深入解析 Dify 作为 LLM 应用平台的设计思路、核心能力与边界,并探讨其在企业级场景中的真实价值与演进方向。

此篇文档 AI 内容占比约 75% ,阅读耗时约 15 分钟。内容核准:管鑫荣


随着大模型能力的快速成熟,构建一个“能跑起来”的 AI 应用已经不再困难。真正的挑战,正在从模型效果本身,转移到工程化与系统化层面:应用如何持续演进?Prompt、数据与流程如何被治理?AI 能力又该如何融入既有业务体系,而不是停留在 Demo 阶段?

在这一背景下,单纯的 LLM 调用工具或开发框架,已难以满足企业级需求。越来越多团队开始关注:是否存在一种平台形态,能够在模型之上,提供更完整的应用构建、运行与管理能力。

本文将以 Dify 为核心分析对象,从系统架构、关键机制与工程取舍的角度,深入解析其在 LLM 应用开发领域的定位与设计思路,并结合实际落地场景,探讨其能力边界与可能的演进方向。


01

架构总览:分层解耦与模块化设计的工程实践



Dify 的整体架构采用典型的三层分离式架构(Three-tier Architecture),即控制台(Console)、Web前端(Frontend)与服务API层(Backend API),并通过清晰的职责划分实现高内聚、低耦合。


架构分层图示


86a4d0c841db4448a662b98471596a57.png


该架构的核心优势在于:


  • 横向扩展能力强:各子系统可独立部署、水平扩容。


  • 故障隔离性好:一个组件崩溃不会直接影响其他功能。


  • 便于持续集成与发布:每个模块可独立测试、灰度发布。


关键数据结构设计


在底层数据模型层面,Dify 通过 Account 模型实现了对多租户(Multi-tenancy)上下文的动态绑定,这是整个系统的基石。以下为结构化示意代码


# api\models\account.py
class Account(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    username = db.Column(db.String(80), unique=True, nullable=False)
    
    _current_tenant = None
    def set_current_tenant(self, tenant_id: int):
        self._current_tenant = tenant_id
    def get_current_tenant(self) -> Optional[int]:
        return self._current_tenant


:此处为逻辑示意。_current_tenant 是一个非持久化属性,用于在请求生命周期内临时存储当前访问的租户环境。它与数据库中的 tenant_id 字段解耦,避免了频繁查询带来的性能开销。


这一设计巧妙地解决了多租户场景下的“身份与角色分离”难题:同一个用户可以在多个组织中拥有不同角色(如管理员、成员、访客),且每次请求都能根据上下文自动切换至正确的租户范围。



02

核心机制深度剖析



多种索引方式:平衡精度与成本的智能检索架构


检索增强生成(RAG)是提升LLM问答准确率的关键技术。然而,语义搜索(Semantic Search)依赖向量数据库,计算成本高昂;而关键词匹配虽快,却易忽略语义关联。


Dify 提出多种索引方式

模式

查询方式

适用场景

高精度

使用向量嵌入,支持 Vector Search、Full-Text Search 和 Hybrid Search 三种检索方式

高精度问答、复杂意图理解

经济

仅支持倒排索引(inverted index)的全文检索

快速响应、低成本、轻量级查询


索引选择设计


以下为示意代码


# api\core\rag\index_processor\index_processor_base.py
   class BaseIndexProcessor(ABC):
       @abstractmethod
       def extract(self, extract_setting: ExtractSetting, **kwargs) -> list[Document]:
           ...
       @abstractmethod
       def clean(self, dataset: Dataset, node_ids: list[str] | None, with_keywords: bool = True, **kwargs):
           ...
       @abstractmethod
       def index(self, dataset: Dataset, document: DatasetDocument, chunks: Any):
           ...
       @abstractmethod
       def retrieve(
           self,
           retrieval_method: RetrievalMethod,
           query: str,
           dataset: Dataset,
           top_k: int,
           score_threshold: float,
           reranking_model: dict,
       ) -> list[Document]:
           ...


混合检索


Dify 知识库还引入了混合检索机制,即同时执行全文检索和向量检索。它包含一个重排序步骤,根据用户的查询从两种搜索结果中选择最佳匹配结果。



可视化工作流引擎:基于JSON Schema的流程编排实现


工作流是 Dify 的核心竞争力之一。它允许开发者通过拖拽界面构建包含多个节点的 AI 处理链,包括:

  • LLM 调用节点
  • 工具调用节点(Function Calling)
  • 条件分支节点(If/Else)
  • 循环节点(For Loop)
  • 异常处理节点



流程定义设计


使用标准 JSON Schema 定义流程结构,可用于版本控制、Diff 对比与 CI/CD 集成。以下为示意代码


{
  "id": "workflow-1",
  "name": "Customer Support Assistant",
  "nodes": [
    {
      "id": "node-1",
      "type": "llm",
      "prompt_template": "Answer based on context: {{context}}",
      "model": "gpt-4"
    },
    {
      "id": "node-2",
      "type": "function_call",
      "function_name": "get_customer_order_status",
      "arguments": { "customer_id": "{{input.customer_id}}" }
    },
    {
      "id": "node-3",
      "type": "conditional",
      "condition": "{{result.status}} == 'pending'",
      "true_node": "node-4",
      "false_node": "node-5"
    }
  ],
  "edges": [
    { "from": "node-1", "to": "node-2" },
    { "from": "node-2", "to": "node-3" }
  ]
}


执行引擎实现原理


工作流执行器基于显式状态机模型,工作流运行和每个节点执行都会记录详细状态(如 pending / running / succeeded / failed 等)。以下为示意代码


# api\core\app\apps\workflow\app_runner.py
class WorkflowAppRunner(WorkflowBasedAppRunner):
      ...
    @trace_span(WorkflowAppRunnerHandler)
    def run(self):
        system_inputs = SystemVariable(
            files=self.application_generate_entity.files,
            user_id=self._sys_user_id,
            app_id=app_config.app_id,
            workflow_id=app_config.workflow_id,
            workflow_execution_id=self.application_generate_entity.workflow_execution_id,
        )
        variable_pool = VariablePool(
            system_variables=system_inputs,
            user_inputs=self.application_generate_entity.inputs,
            environment_variables=self._workflow.environment_variables,
            conversation_variables=[],
        )
        graph_runtime_state = GraphRuntimeState(variable_pool=variable_pool, start_at=time.perf_counter())
        graph = self._init_graph(
            graph_config=self._workflow.graph_dict,
            graph_runtime_state=graph_runtime_state,
            workflow_id=self._workflow.id,
            tenant_id=self._workflow.tenant_id,
            user_id=self.application_generate_entity.user_id,
            user_from=user_from,
            invoke_from=invoke_from,
            root_node_id=self._root_node_id,
        )
        task_id = self.application_generate_entity.task_id
        channel_key = f"workflow:{task_id}:commands"
        command_channel = RedisChannel(redis_client, channel_key)
        self._queue_manager.graph_runtime_state = graph_runtime_state
        workflow_entry = WorkflowEntry(
            tenant_id=self._workflow.tenant_id,
            app_id=self._workflow.app_id,
            workflow_id=self._workflow.id,
            graph=graph,
            graph_config=self._workflow.graph_dict,
            user_id=self.application_generate_entity.user_id,
            user_from=user_from,
            invoke_from=invoke_from,
            call_depth=self.application_generate_entity.call_depth,
            variable_pool=variable_pool,
            graph_runtime_state=graph_runtime_state,
            command_channel=command_channel,
        )
        persistence_layer = WorkflowPersistenceLayer(...)
        workflow_entry.graph_engine.layer(persistence_layer)
        for layer in self._graph_engine_layers:
            workflow_entry.graph_engine.layer(layer)
        generator = workflow_entry.run()
        for event in generator:
            self._handle_event(workflow_entry, event)


工作流状态图


9fe7d43ca2bc4640aa4b02dbae84fe9a.png


函数调用集成:打通AI与真实世界的能力边界


现代智能体不仅需要“思考”,还需要“行动”。Dify 支持函数调用(Function Call)机制调用外部服务,如查询订单、发送邮件、调用ERP接口等。



插件系统设计


以下为示意代码


class Plugin:
    def __init__(self, config: dict):
        self.config = config
    def call(self, function_name: str, args: dict) -> Any:
        method = getattr(self, function_name, None)
        if not method:
            raise ValueError(f"Function {function_name} not found")
        return method(**args)
# Example: OrderPlugin
class OrderPlugin(Plugin):
    def get_order_status(self, order_id: str) -> dict:
        return requests.get(f"https://api.example.com/orders/{order_id}").json()


与LLM协同调用流程


在设计层面,Dify 插件系统通常包含以下安全考量:

安装前:限制来源(Marketplace/官方/合作伙伴)、验证 manifest 与版本、检查依赖/唯一标识;

安装后:通过权限模型限制能不能用 Tool/Model/Trigger/Endpoint/Storage 以及用多少资源;

调用时:所有敏感调用都通过内网守护进程 + 内部 API 通道,带 API Key、租户上下文和严格的结构校验;


多租户身份与权限管理:基于角色的访问控制的工程实现


在传统单租户系统中,权限通常由用户直接决定。但在 SaaS 场景下,用户可能同时属于多个组织,且每个组织内的权限不同。Dify 采用基于角色的访问控制(Role-Based Access Control, RBAC)结合上下文感知会话管理,实现细粒度的权限隔离。


权限模型设计


以下为示意代码


class Role(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(50), nullable=False)  # "admin", "editor", "viewer"
    description = db.Column(db.Text)
    permissions = db.Column(db.JSON)  # JSON array of permission strings
class UserTenantRole(db.Model):
    user_id = db.Column(db.Integer, db.ForeignKey('account.id'), primary_key=True)
    tenant_id = db.Column(db.Integer, db.ForeignKey('tenant.id'), primary_key=True)
    role_id = db.Column(db.Integer, db.ForeignKey('role.id'))


关键点:UserTenantRole 表是连接用户、租户与角色的枢纽,支持一个用户在不同租户中有不同角色。



会话上下文绑定机制


在 Flask 请求上下文中,Dify 使用自定义中间件动态注入当前租户信息,以下为示意代码:


@app.before_request
def load_current_tenant():
    if g.user and hasattr(g.user, '_current_tenant'):
        # 已设置,则跳过
        return
    # 从 JWT token 或 Header 中提取 tenant_id
    tenant_id = request.headers.get('X-Tenant-ID') or get_jwt_claims().get('tenant_id')
    if tenant_id:
        g.current_tenant = tenant_id
        g.user.set_current_tenant(tenant_id)


将租户上下文与用户身份解耦,避免因依赖单一全局变量而导致的污染风险。这种机制确保了即使两个用户同名,只要租户不同,其操作范围也完全隔离。


错误处理机制:构建韧性系统的全链路防御体系


在生产环境中,任何环节都可能失败。Dify 构建了多层次的错处机制,贯穿从模型调用到应用逻辑的每一层。Dify 的错误处理采用分层设计:


  1. 模型调用层: LLMErrorLLMBadRequestErrorProviderTokenNotInitError
  2. 配额管理层: QuotaExceededErrorAppInvokeQuotaExceededError
  3. 限流层: InvokeRateLimitError
  4. 工作流执行层: 节点级错误捕获,支持错误分支(Error Handler Node)
  5. HTTP API层: 统一异常映射到标准 HTTP 状态码


以下为示意代码


# api\core\errors\error.py
class LLMError(ValueError):
    """Base class for all LLM exceptions."""
    description: str | None = None
    def __init__(self, description: str | None = None):
        self.description = description
class LLMBadRequestError(LLMError):
    """Raised when the LLM returns bad request."""
    description = "Bad Request"
class ProviderTokenNotInitError(ValueError):
    """
    Custom exception raised when the provider token is not initialized.
    """
    description = "Provider Token Not Init"
    def __init__(self, *args, **kwargs):
        self.description = args[0] if args else self.description
class QuotaExceededError(ValueError):
    """
    Custom exception raised when the quota for a provider has been exceeded.
    """
    description = "Quota Exceeded"
class AppInvokeQuotaExceededError(ValueError):
    """
    Custom exception raised when the quota for an app has been exceeded.
    """
    description = "App Invoke Quota Exceeded"
class ModelCurrentlyNotSupportError(ValueError):
    """
    Custom exception raised when the model not support
    """
    description = "Model Currently Not Support"
class InvokeRateLimitError(ValueError):
    """Raised when the Invoke returns rate limit error."""
    description = "Rate Limit Error"




03

性能分析



以下分析基于源码结构与工程常见模式,重点在于识别潜在热点路径,而非给出绝对性能结论。


从 dify 当前实现来看,Dify 的性能主要集中在几条典型热路径上:


  • 请求入口 + 限流(AppGenerateService.generate / PipelineGenerateService.generate


  • 应用生成器 + Runner(Chat / Completion / Agent / AdvancedChat / Workflow)


  • 工作流引擎(GraphEngine.run + WorkerPool


  • RAG 检索(RetrievalService.retrieve 及各 IndexProcessor.retrieve



本章中涉及的代码片段与类结构,均为基于 Dify 开源实现的结构化示意与工程抽象,并不保证与当前版本源码逐行一致。


入口层:App 生成服务


# api\services\app_generate_service.py
class AppGenerateService:
    @classmethod
    @trace_span(AppGenerateHandler)
    def generate(cls, app_model, user, args, invoke_from, streaming=True, root_node_id=None):
        quota_charge = unlimited()
        if dify_config.BILLING_ENABLED:
            quota_charge = QuotaType.WORKFLOW.consume(app_model.tenant_id)
        max_active_request = cls._get_max_active_requests(app_model)
        rate_limit = RateLimit(app_model.id, max_active_request)
        request_id = RateLimit.gen_request_key()
        try:
            request_id = rate_limit.enter(request_id)
            if app_model.mode == AppMode.COMPLETION:
                return rate_limit.generate(CompletionAppGenerator.convert_to_event_stream(...), request_id)
            elif app_model.mode == AppMode.AGENT_CHAT or app_model.is_agent:
                ...
            elif app_model.mode == AppMode.WORKFLOW:
                ...
        except Exception:
            quota_charge.refund()
            rate_limit.exit(request_id)
            raise
        finally:
            if not streaming:
                rate_limit.exit(request_id)


性能关键点:


  • 每个请求都会:
  • 进行计费额度校验(可能访问计费服务/Redis);
  • 最大并发活跃请求控制RateLimit)。


  • 所有模式(Chat / Completion / Agent / Workflow / AdvancedChat)都走这条入口,是全局热点。


应用生成器 & Runner:Chat / Completion / Agent / AdvancedChat


以 Chat 模式为例(Completion/Agent/AdvancedChat 结构类似):

  1. AppGenerateService.generate → ChatAppGenerator.generate
  2. ChatAppGenerator.generate:
  • 校验、清洗 query
  • 解析文件(FileUploadConfigManager + file_factory);
  • 获取 app config & tracing (TraceQueueManager);
  • 初始化 ChatAppGenerateEntity
  • 新起 worker 线程 _generate_worker
  1. ChatAppRunner.run:
  • 组织 prompt(organize_prompt_messages);
  • 敏感内容检测(moderation);
  • RAG 检索(DatasetRetrieval.retrieve);
  • 再次组织 prompt(带 context);
  • ModelInstance.invoke_llm
  • 处理流式结果。


相关文件:

  • /api/core/app/apps/chat/app_generator.py::generate
  • /api/core/app/apps/chat/app_runner.py::run
  • /api/core/app/apps/completion/app_runner.py::run
  • /api/core/app/apps/agent_chat/*
  • /api/core/app/apps/advanced_chat/*


性能关键点:

  1. Prompt 构造 & 多次 DB 访问
  • 多处调用 ConversationService.get_conversationdb.session.scalar(select(App)...)
  • organize_prompt_messages 可能对 inputs / files / memory 做多次处理;
  • AdvancedChat / Agent 会在同一次请求中多次组织 prompt。
  1. 敏感词检测 & Hosting Moderation
  • moderation_for_inputs + check_hosting_moderation 都会额外调用模型或规则引擎;
  • 在高 QPS 下会显著增加整体延迟。
  1. RAG 检索嵌入在请求里
  • 每次请求如果挂了 dataset,就会调用 DatasetRetrieval.retrieve(内部走向量库、过滤、重排);
  • 这是典型的 IO & CPU 热点。
  1. LLM 调用
  • ModelInstance.invoke_llm 是最重 IO,包含 HTTP + token 计数.


工作流 & AdvancedChat:GraphEngine 热路径


文件:/api/core/workflow/graph_engine/graph_engine.py

  • 构造时绑定:
  • GraphRuntimeState(变量池、ready_queue、response_coordinator)
  • WorkerPool(多线程执行节点)
  • EventManager + Dispatcher + ExecutionCoordinator + ErrorHandler
  • run()
def run(self) -> Generator[GraphEngineEvent, None, None]:
    self._initialize_layers()
    is_resume = self._graph_execution.started
    ...
    start_event = GraphRunStartedEvent()
    ...
    self._start_execution(resume=is_resume)   # 启动 WorkerPool & Dispatcher
    yield from self._event_manager.emit_events()
    ...
    # 根据 is_paused / aborted / has_error / 部分异常决定 Final Event


性能关键点:

  • GraphEngine.run() 中的事件循环;
  • WorkerPool.start()/check_and_scale() 内的队列长度 / worker 伸缩;
  • 每个 Node 的 _run()(LoopNode、ToolNode、LLM 节点等)。


RAG 检索:RetrievalService.retrieve 热点


文件:/api/core/rag/datasource/retrieval_service.py


with ThreadPoolExecutor(max_workers=dify_config.RETRIEVAL_SERVICE_EXECUTORS) as executor:
    futures = [ ]
    retrieval_service = RetrievalService()
    if query:
        futures.append(executor.submit(retrieval_service._retrieve, ..., attachment_id=None, ...))
    if attachment_ids:
        for attachment_id in attachment_ids:
            futures.append(executor.submit(retrieval_service._retrieve, ..., attachment_id=attachment_id, ...))
    if futures:
        for future in concurrent.futures.as_completed(futures, timeout=3600):
            if exceptions:
                for f in futures:
                    f.cancel()
                break
...
if exceptions:
    raise ValueError(";\n".join(exceptions))
return all_documents


各 IndexProcessor(paragraph_index_processor.py / qa_index_processor.py / parent_child_index_processor.py)的 retrieve 最终都调用这里。


性能关键点:

  • 对每个 query 和每个附件 ID 使用线程池并行 _retrieve
  • _retrieve 内部:
  • 调用向量库 / keyword 索引;
  • 可能再调用 rerank 模型。


RAG Pipeline:批处理热路径


  • /api/services/rag_pipeline/pipeline_generate_service.py
  • /api/core/app/apps/pipeline/pipeline_generator.py

PipelineGenerator.generate 会:

  • 为每个 datasource_info 构造 RagPipelineGenerateEntity
  • 在 PUBLISHED_PIPELINE 且非 retry 场景,会:
  • 创建 Document 记录;
  • 记录流水日志 DocumentPipelineExecutionLog
  • 对 “在线调试 / retry” 直接在当前进程 _generate
  • 对正常发布 pipeline 则构造 RagPipelineInvokeEntity 列表,交给 Celery(RagPipelineTaskProxy(...).delay())后台跑。


性能关键点:

  1. 单 Pipeline 多 Datasource 串行
  • 对每个 datasource 独立创建 Document + ExecutionLog,会有 N 次 DB commit;
  • 对大量 datasource 的 Pipeline,会形成明显的 DB 写热点。
  1. 后台任务线程池
  • Pipeline 实际 indexing 工作在 Celery worker 中完成,HTTP 路径只负责触发;
  • 性能取决于 worker 数量 & 每 worker 内部的 GraphEngine / IndexProcessor 表现;



04

Dify 技术演进路线:从“可用”到“可规模化”的平台进化



从当前的架构与性能特征来看,Dify 已经完成了 AI 应用平台的“第一阶段目标”——即让 LLM 应用能够以工程化、平台化的方式被构建、部署和复用。但在企业级场景中,这仍只是起点,其技术演进路径也呈现出较为清晰的阶段性特征。


在短期演进方向上,Dify 的重点仍将集中在 稳定性与可控性 上。这包括对高并发模型调用的调度优化、更细粒度的缓存与限流策略、以及在工作流执行过程中对异常、重试与失败补偿机制的进一步完善。这一阶段的核心目标,并非提升单点性能极限,而是提升系统在复杂负载下的“可预测性”。


在中期层面,平台能力的进一步抽象将成为关键。随着 AI 应用数量与复杂度的提升,Dify 需要在多租户隔离、资源配额、应用级治理以及跨团队协作方面提供更强的支撑能力。这意味着其内部模型管理、数据访问与工作流执行机制,将逐步从“应用友好型设计”向“平台治理型设计”演进。


从更长期的视角来看,Dify 的演进方向很可能不止于“AI 应用构建工具”,而是逐步向 AI 应用中枢平台 靠拢。在这一阶段,Dify 更重要的价值不再是单个应用的构建效率,而是作为企业内部 AI 能力的统一入口,承担模型能力复用、数据与知识沉淀、以及对外服务暴露的职责。


需要强调的是,这一演进路线并不意味着 Dify 会试图覆盖所有自动化或业务编排能力。相反,其更合理的发展路径,是在保持 AI 应用层专注度的同时,通过开放接口与生态机制,与流程自动化、系统集成类平台形成清晰分工,从而共同支撑企业级 AI 系统的长期演进。



05

结语



Dify 的成功并非偶然,而是源于对企业级AI应用复杂性的深刻理解工程化思维的极致贯彻。其核心价值体现在:

  1. 通过多种索引方式、错误处理、缓存策略等手段,在性能与可靠性之间取得合理平衡
  2. 提供可视化的开发体验,降低非专业工程师的入门门槛
  3. 将多租户(Multi-tenancy)架构、权限、配置、可观测性等“非功能性需求”前置为第一优先级
  4. 坚持模块化设计,支持未来功能拓展


未来的大型语言模型应用不应再是“一堆提示词+API调用”的拼凑体,而应是具备可维护性、可审计性、可复用性的软件系统。Dify 为此提供了坚实的技术范本。




🚀 🚀 阿里云 EDAS 也提供了一键部署 Dify 的能力,快访问下方链接体验吧!

https://edasnext.console.aliyun.com/#/home?regionNo=cn-hangzhou&tab=marketplace&marketDetail=dify



目录
相关文章
|
6月前
|
人工智能 监控 API
从零构建企业级AI应用:Dify平台深度实践指南
本文深度评测Dify——一款开源、生产就绪的LLM应用开发平台。它填补了LangChain等工具库与OpenAI Assistants API之间的空白,以声明式配置、可视化工作流、企业级RAG、多模型网关和完备监控,助力团队一周内交付AI应用,兼顾可控性、效率与可扩展性。
|
8月前
|
人工智能 监控 数据可视化
大厂都在用的测试基础设施:深度解析Dify工作流引擎的设计哲学与最佳实践
Dify作为开源大模型应用开发平台,凭借其低代码可视化工作流引擎,正成为大厂智能测试基础设施核心。一体化架构与企业级安全设计,实现测试流程高效、可靠自动化。支持接口、性能、视觉等多场景测试,助力AI能力深度融入研发流程,显著提升交付质量与速度。
|
6月前
|
人工智能 数据可视化 Serverless
国产之光:Dify何以成为国内Workflow Agent开发者的首选工具
随着 LLM 技术发展,将LLM从概念验证推向生产时面临诸多挑战,如复杂Prompt工程、长上下文管理、缺乏生产级运维工具及快速迭代难等。Dify旨在通过融合后端即服务(BaaS)和LLMOps理念,为开发者提供一站式、可视化、生产就绪的解决方案。
1925 4
|
4月前
|
人工智能 自然语言处理 Nacos
Dify 官方上架 Nacos A2A 插件,补全双向多智能体协作能力
Nacos 官方为 Dify 平台打造了双向 A2A 协议集成方案,通过两个互补插件填补 Dify 在 A2A 协议支持上的空白。
1030 42
|
5月前
|
存储 缓存 测试技术
RAG 三大架构评测:在成本与准确度之间的权衡
本文从成本视角剖析RAG三大架构:向量RAG(高效低成本)、GraphRAG(高准低效高成本)、PageIndex(高准高成本)。指出当前基准测试过度关注准确率,忽视延迟、吞吐量与单次查询成本等生产关键指标,提出以延迟为先、匹配查询复杂度、计算TCO的选型框架。
1068 6
|
5月前
|
人工智能 运维 自然语言处理
最近一年Agent产品演进趋势及用户洞察
深度盘点 2025-2026 年 AI Agent 产品变革,揭示从“对话”向“行动”的范式转移。通过分析 Manus、Claude Cowork 及阿里千问等案例,阐述行业如何基于用户的“工具饥渴”与执行痛点,打造具备自主规划与桌面操作能力的智能体,重塑人机协作新形态。
702 7
|
6月前
|
安全 API 数据库
Dify 开源 LLM 应用开发平台企业级 Docker Compose 部署手册
本文为企业级 Dify 生产部署指南,聚焦 Docker Compose 方案,涵盖环境准备、安全安装、双模式部署、前后端配置及加固优化,适用于私有化与生产场景,不涉及 Kubernetes。
3943 7
|
6月前
|
人工智能 搜索推荐 数据库
从零搭建RAG系统:原理剖析+代码实践,解锁大模型“记忆力”新姿势
RAG(检索增强生成)为大模型配备“外接大脑”,通过连接专属知识库,提升回答准确性。广泛应用于医疗、法律、客服等领域,兼具专业性与可解释性。本文详解其原理、实战步骤与优化技巧,助你快速构建个性化AI助手。
2194 12

热门文章

最新文章