FAQ
This page answers the questions that show up most often in public conversations.
This page is for the questions that come up most often during a first conversation, a first product experience, or a first delivery discussion. Its job is not to retell the concept, but to explain the positioning, boundaries, isolation model, hot-update path, CLI / Agent status, local execution model, and current stage in one place.
Positioning
No. It is a platform that lets AI call and execute real capabilities inside rules. The most mature execution asset today is still the Python script, and web-side upload registration already supports Python, Shell, Bat(Cmd), and Node.js. Cloud execution of bat / cmd is enabled only on Windows runtimes.
It fits people who already have scripts, automation work, data-processing needs, or a need to turn those capabilities into one unified entry, one delivery path, and one governance model.
No. The free edition is for individual explorers. It is meant to let them quickly experience capability onboarding, AI scheduling, and execution feedback before moving into team or enterprise collaboration.
No. They share the same execution and security foundation. What changes is the scale of use, the depth of collaboration, and the delivery model.
No. The public story is already split into four layers: the free path, local script-slot expansion, the formal standard team edition, and enterprise / private delivery.
Safety
The platform is explicitly designed so AI works inside rules. Recommendation scope, execution boundaries, manual confirmation, and audit trails are built-in governance layers, not optional decoration.
No. Whether the model is shared SaaS or enterprise single-tenant delivery, customers only see the capabilities they are authorized to use inside their own tenant.
The platform isolates capabilities, data, and permissions by customer boundary by default so different customers remain invisible to one another and do not interfere with each other.
No. The recommendation scope is constrained by both tenant boundary and permission boundary. It is not a model that can recommend whatever it happens to think of.
No. The platform can maintain the default upstream configuration, and a formal tenant can also maintain its own local configuration. If the tenant-local configuration is incomplete, runtime falls back to the platform default. There is now another public-facing layer on top of that: the platform super-admin side maintains the platform model library, tenant admins maintain their own tenant-local model lists, and platform models are granted first to tenants and then to specific users. A model appears in the current user's dialog-execution selector only after the user confirms the announcement. Personal-free regular users still do not need a separate model-list page, and can switch among the models already authorized to them directly inside dialog execution. To avoid sideways exposure of secrets, the full token value is shown only to the configuring side and the other side sees a masked preview.
Delivery
No. Standard team collaboration can usually start through the shared-SaaS formal tenant entry. Private deployment or enterprise delivery only becomes the better path when stronger isolation, intranet access, local bridging, or formal project acceptance is actually required.
Unified wording: the private-deployment test page is available at private-test.execfabric.cn.
No. Once the customer script passes review, sync, registration, and authorization, it can take effect inside the current tenant without redeploying the whole platform.
Not in the default 1.0 path. The platform still keeps review, registration, authorization, and permission-verification steps in place. It does not support bypassing the platform and going live directly.
No. Existing formal pages, external links, and iframe entries can be attached to menus, but adding a new formal frontend page still requires development, packaging, and deployment. Shared SaaS does not let tenants upload arbitrary Vue / JS bundles as formal product pages.
No. After a script update lands, it only takes effect inside the owning tenant. Other tenants do not automatically gain visibility or execution rights.
Not necessarily. If the project needs to handle input files and result artifacts, the platform can provide file upload, batch status, and result-download flows, but whether they are opened still depends on project scope.
The script does not guess. The upload button in the execution quick bar binds the current upload as one uploadBatchId, and during confirmation the backend passes a snapshot of that batch into the script. Python, Shell, Bat(Cmd), and Node.js scripts can read EXECFABRIC_UPLOAD_BATCH_NO, EXECFABRIC_UPLOAD_INPUT_FILES_JSON, EXECFABRIC_UPLOAD_FILE_SERVICE_JSON, and EXECFABRIC_SKILL_INPUT_PAYLOAD_JSON, so they operate on the bound batch rather than some guessed “latest file” in a historical directory.
At minimum, customers should receive the access entry, the account method, customer-usage instructions, and customer-side script hot-update instructions. If the project also includes announcements, customer notices, or result-download entries, those should be explained together.
CLI & Local
No. execfabric-cli already supports login, register, list, run, agent describe, agent bind, and agent start. It is already usable for local onboarding, debugging, and early validation.
Not yet. The local Agent direction is still being strengthened, and for now it should be understood as a local bridge and execution skeleton rather than a finished product line.
Yes, but usually not by exposing local paths directly to the browser. The normal approach is to use the CLI / Agent path as the local execution bridge.
Web-side upload registration already supports Python, Shell, Bat(Cmd), and Node.js text scripts. The page now auto-detects the current cloud runtime and disables bat / cmd on non-Windows environments. CLI-side remote registration also already supports Python, Shell, Bat(Cmd), and Node.js today. Cloud execution of bat / cmd still requires a Windows runtime, while broader asset-type coverage still comes later.
Stage
The enterprise 1.0 delivery mainline, the personal free entry, the minimal CLI bridge, and the external docs site are already usable. They can support public explanation, free-path experience, and part of the real scenario flow.
Not yet in its final form, but the shared-SaaS frontend already exists and the monthly / yearly upgrade path is already present. What remains to be tightened is branding, initialization, and finer menu boundaries.
It should help you feel the execution chain, understand the platform position, and decide whether you belong on the free path, local script-slot expansion, the standard team edition, or enterprise consultation. The current experience page shows Python task_brief_demo.py on the left and Shell clean_log_demo.sh on the right, sourced from the formal free-experience asset directory.
The current flow enters a dedicated result page first, then returns to login and the personal mainline. It no longer depends only on a toast message.
execfabric-hack the formal customer entryNo. It mainly exists for local multi-entry aggregation, joint debugging, and sync. Formal customer entry still means the personal free frontend, the shared-SaaS tenant frontend, or the enterprise-delivery frontend.
Next Read
Continue by goal: Product Overview, Customer Delivery & Usage, the CLI & Local Agent Guide, or direct lead routing.