CubePlex 与 Dify：长期工作的 Agent 与按场景构建的 App

Agent 产品正在形成两种不同的使用方式。

Dify 从具体场景出发。团队先定义客服、知识问答、合同审核或报告生成等问题，再为每个问题配置模型、Workflow、Knowledge 和工具，最后发布成 Web App、API、嵌入页或 MCP 服务。用户选择一个 App，然后在它规定的能力范围内完成任务。Dify 的开源代码和使用说明可在 GitHub 与官方文档中查看。

CubePlex 从长期工作的 Agent 出发。个人或团队在一个 Workspace 中持续使用同一个 Agent，把不同类型的工作交给它。这个 Agent 长期保留角色设定、记忆、Skills 和 MCP 连接，并在需要时操作可持续使用的电脑环境。用户面对的不是一组按场景切换的 App，而是一个逐渐熟悉团队工作方式的 Agent。CubePlex 同样提供开源代码和产品文档。

这一区别决定了两款产品如何组织能力、状态和协作。

Dify：先定义场景，再发布 App

Dify Studio 的主要交付对象是 App。开发者使用 Workflow 或 Chatflow 编排模型调用、知识检索、工具、条件分支和人工确认，再把确认过的版本发布给终端用户。Workflow 适合有明确输入、步骤和输出的自动化流程；Chatflow 在同一套编排能力上增加对话状态。

这种结构要求团队先明确应用解决什么问题。客服助手和合同审核工具通常是两个 App，各自拥有独立的 Prompt、流程、知识和发布入口。应用的建设者负责调整能力并发布版本，使用者负责提交输入、查看结果，不需要参与应用本身的配置。

Dify 的 New Agent 把更开放的 Agent 能力加入了这套 App 模型。开发者可以为 Agent 配置模型、Prompt、Skills、Files、Tools 和环境变量，再把它发布成独立 Chat App，或作为 Agent 节点放进 Workflow。Capability 定义 Agent 能做什么，Task 定义一次运行要完成什么。

New Agent 可以在 Build 阶段运行命令、安装程序和读写文件。Build 中标记为 Persistent 的文件和安装内容会进入 Agent 的后续版本；已发布运行中新产生的文件和安装内容则是临时的，不会反过来改变 Agent 本身。Prompt、Skills 和 Tools 也只能在 Configure 或 Build 中修改，终端用户不能通过一次对话永久改变已发布 Agent 的能力。

因此，New Agent 扩大了单个 Dify App 可以处理的任务范围，但产品关系没有改变：团队仍然先建设和发布 Agent，用户再通过 Web App、API 或 Workflow 节点调用它。

CubePlex：一个 Agent 承接持续变化的工作

CubePlex Workspace 的主要对象不是待发布的 App，而是个人或团队正在使用的 Agent。

Workspace 保存 Agent 的 Persona，并绑定可用的 Skills 和 MCP 连接。个人记忆只对当前用户在当前 Workspace 可见，Workspace 记忆由成员共享，组织记忆用于组织范围的信息。成员打开新的对话，或从 Web、Slack、飞书等入口发起任务时，仍然使用这个 Workspace 的 Agent 配置，不需要为研究、写作、运维或开发分别创建应用。

这并不意味着所有工作都必须塞进一个无限延长的聊天记录。CubePlex 仍然使用不同的对话和 Topic 划分任务上下文；长期复用的是 Agent 的角色、能力、记忆和治理规则。任务可以分开，Agent 不必每次重新配置。

Agent 在执行任务时可以使用 Sandbox 操作文件、运行命令和安装工具。当前实现会根据协作方式把 Sandbox 绑定到用户、群聊会话或 Topic，而不是让整个 Workspace 的所有成员无条件共用同一个文件系统。对应作用域中的工作环境可以跨运行继续使用，群聊和 Topic 也可以按照协作边界共享或隔离 Sandbox。

因此，CubePlex 的长期状态分成两个层次：Workspace 负责团队共用的 Agent 配置、记忆和权限；用户、会话或 Topic 范围的 Sandbox 保存对应工作的文件与工具环境。成员面对的是同一个 Workspace Agent，但用户身份、对话上下文和执行环境仍有明确边界。

两种产品从不同位置开始一次工作

	Dify App	CubePlex Workspace Agent
用户如何开始	先选择一个针对具体场景发布的 App	进入 Workspace，直接把不同工作交给同一个 Agent
能力如何组织	每个 App 配置自己的 Prompt、Workflow、Knowledge 和工具	Persona、Skills、MCP 与记忆围绕 Workspace Agent 长期组织
谁改变能力	Editor 建设并发布，终端用户使用已发布版本	Workspace 成员在权限与审批规则下持续使用和维护 Agent
运行后的变化	已发布 New Agent 的运行不会修改 Agent 本身	Agent 配置和记忆持续存在，Sandbox 状态在对应作用域中保留
更适合的工作	边界明确、可以产品化和重复交付的业务场景	类型持续变化、需要长期上下文和电脑操作的个人或团队工作

这也是用户体验上的直接差异。

在 Dify 中，团队通常会为不同业务问题提供不同入口。用户需要知识库问答时打开问答 App，需要生成报告时调用报告 Workflow，需要客服支持时进入客服 Chat App。每个入口都代表一套经过建设和发布的能力。

在 CubePlex 中，用户通常先进入自己的 Workspace，再告诉 Agent 当前要做什么。Agent 可以根据任务选择已有的 Skills、MCP 和文件工具。今天分析代码、明天整理会议材料、之后继续跟进部署问题，这些工作可以放在不同对话中，但继续复用同一个 Agent 的长期设定和记忆。

模型能力提升降低了场景编排的必要性

场景化 App 的前提，是团队需要提前把任务路径设计清楚：为一个问题编写专用 Prompt，连接对应的知识库和工具，再用 Workflow 固定执行步骤。模型规划和工具调用能力有限时，这种方式可以用人工编排换取稳定结果。代价是每增加一类需求，都可能需要建设、测试和发布一个新的 App。

随着模型在任务理解、规划和工具使用上的能力提升，越来越多的内部工作不再需要专门编排一套流程。团队可以把经过授权的 MCP、Skills、记忆和文件环境交给一个通用 Agent，由用户直接描述目标，Agent 自己选择方法和工具。例如，同一组代码仓库、文档和项目管理工具，可以用于排查故障、准备发布、整理需求或审查代码，不必分别制作四个 App。

CubePlex 围绕这种使用方式组织产品。Skills 保存团队已经验证的方法，MCP 连接业务系统，Memory 保存个人与团队背景，Sandbox 保留任务产生的文件和工具环境。模型升级后，这些长期积累的上下文和能力可以继续由同一个 Workspace Agent 使用；团队也不必逐个重做已经发布的场景应用。

Dify 仍然适合高频、边界明确并且需要稳定输入输出的流程，特别是需要向大量终端用户发布固定入口时。对于需求持续变化的工程、运维、研究和内容工作，提前把每类任务做成 App 会增加建设与维护成本，通用 Agent 更适合作为团队的日常工作入口。

因此，团队可以先在 CubePlex 中为 Workspace Agent 配好 MCP、Skills、记忆、Sandbox 和权限，让它处理不断出现的新任务。只有当某项工作已经足够稳定，需要固定流程并交付给更大范围的用户时，再把它做成 Dify App。对正在评估 Dify alternative 的团队，CubePlex 提供的是覆盖范围更广的起点：先建立一个能够长期工作的 Agent 环境，再决定哪些场景值得单独产品化。