Interaction method, device and equipment using file system, and storage medium

Abstract

The application provides an interactive method and device of an application file system, equipment and a storage medium, and belongs to the technical field of artificial intelligence. The method comprises the following steps: the application file system runtime publishes a runtime list; the runtime controller loads an application registration library, a policy registration library, an identity subject registration library and a state resource; the runtime controller constructs a connector context, acquires a structure snapshot; the runtime controller performs path safety verification according to the structure snapshot, and generates related files; the intelligent agent ensures the existence of the identity subject, and appends a binding action request to the binding identity subject action file; the action consumption module consumes and generates a request identifier and a client token, and initiates action execution through a submission action interface; the application adapter executes business action logic, returns an execution result, and the event publishing module constructs a corresponding event record. By uniformly mapping resources, actions and events into a file tree, the intelligent agent can complete application interaction by using ordinary file reading and writing, and the processing efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to an interactive method, apparatus, device and storage medium for an application file system. Background Technology

[0002] With the development of large language models and automated agents, more and more software systems need agents to read application states, invoke business actions, receive external events, and collaborate with multiple agents. Existing solutions typically expose each application's capabilities to agents through plugins, software development kits (SDKs), representational state transfer application programming interfaces (REST APIs), model context protocols (MCPs), browser automation, message queues, or chatbot interfaces. These solutions expose the capabilities of each application to agents via function calls, hypertext transfer protocol (HTTP) calls, or user interface (UI) operations. However, existing solutions cannot discover, read, invoke, and respond to applications in a unified way, resulting in relatively poor processing performance. Summary of the Invention

[0003] To address the aforementioned technical problems, this application provides an interactive method, apparatus, device, and storage medium for an application file system.

[0004] In a first aspect, this application provides an interaction method for an application file system, the method comprising: The runtime controller loads the application registry, policy registry, identity subject registry, and state resources, enters or updates private application policies, and saves path templates, configuration file templates, and credential policies. When a new identity subject completes binding, it automatically instantiates the private application path and configuration file based on the path template and configuration file template. When the policy configuration changes, it updates the policy registry. The runtime controller constructs a connector context for the target application, and uses the connector context to call the connector of the application adapter to obtain a structure snapshot; The runtime controller performs path security verification based on the structure snapshot and generates application metadata directory, event stream directory, resource files, action files, meta manifest file, and cursor file; The intelligent agent discovers the application file system through environment variables, runtime manifests, and heuristics to ensure the existence of the identity subject and appends binding action requests to the action file bound to the identity subject; The runtime controller's action consumption module consumes actions by action cursor and generates request identifiers and client tokens; The action consumption module passes the action payload, the connector context, the request identifier, and the client token to the application adapter's submit action interface to initiate action execution; the application adapter executes the business action logic and sends the execution result back to the application file system runtime; the event publishing module of the runtime controller constructs the corresponding event record.

[0005] Secondly, this application provides an interactive device for an application file system, the interactive device for the application file system comprising: The application file system runtime is used to publish the runtime manifest; The runtime controller is used to load the application registry, policy registry, identity subject registry and state resources, enter or update private application policies, and save path templates, configuration file templates and credential policies. When a new identity subject is bound, the private application path and configuration file are automatically instantiated based on the path template and the configuration file template. When the policy configuration is changed, the policy registry is updated. The runtime controller is used to construct a connector context for the target application, and to call the connector of the application adapter in the connector context to obtain a structure snapshot; The runtime controller is used to perform path security verification based on the structure snapshot, and generate application metadata directory, event stream directory, resource files, action files, meta manifest files, and cursor files; Intelligent agents are used to discover the application file system through environment variables, runtime manifests, and heuristics, ensure the existence of the identity subject, and append binding action requests to the action file bound to the identity subject. The action consumption module of the runtime controller is used to consume actions by cursor and generate request identifiers and client tokens; The action consumption module is also used to pass the action payload, the connector context, the request identifier, and the client token to the application adapter's submit action interface to initiate action execution; The application adapter is used to execute business action logic and return the execution results to the application file system at runtime; The event publishing module of the runtime controller is used to build corresponding event records.

[0006] Thirdly, this application provides an electronic device, including a memory and a processor, wherein the memory is used to store a computer program, and the computer program executes the application file system interaction method provided in the first aspect when the processor is running.

[0007] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, executes the application file system interaction method provided in the first aspect.

[0008] The application file system interaction method provided in this application maps resources, actions, and events to a file tree, allowing agents to complete application interactions using ordinary file read and write, reducing the integration cost of hard-coded tools / APIs for each application, and improving processing efficiency. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be considered as a limitation on the scope of protection of this application. In the various drawings, similar components are numbered similarly.

[0010] Figure 1 A schematic diagram of the system architecture provided in this application is shown; Figure 2 A flowchart illustrating the interaction method of the application file system provided in this application is shown; Figure 3 This application provides a schematic diagram of the file tree namespace. Figure 4 This paper illustrates another flowchart of the interaction method of the application file system provided in this application; Figure 5 This illustrates yet another flowchart of the interaction method for the application file system provided in this application; Figure 6 This paper illustrates another flowchart of the interaction method of the application file system provided in this application; Figure 7 An interactive diagram of the third-party real chat application A provided in this application is shown; Figure 8 Another schematic diagram of the interactive device for the application file system provided in this application is shown. Detailed Implementation

[0011] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0012] The components of this application, typically described and illustrated in the accompanying drawings, can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0013] In the following, the terms “comprising,” “having,” and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as excluding, firstly, the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more features, numbers, steps, operations, elements, components, or combinations thereof.

[0014] Furthermore, the terms "first," "second," and "third" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0015] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0016] With the development of large language models and automated agents, more and more software systems need to enable agents to read application states, invoke business actions, receive external events, and collaborate with multiple agents. Existing solutions typically use plugins, SDKs, REST APIs, MCP tools, browser automation, message queues, or chatbot interfaces to expose the capabilities of each application to the agent in the form of function calls, HTTP calls, or UI operations.

[0017] In such solutions, application developers typically need to write tool definitions, authentication logic, resource reading logic, action execution logic, and event callback logic separately for each application. The agent runtime then needs to understand these capabilities from system prompts, tool lists, or plugin descriptions, and decide when to invoke a particular tool or API within the session. If multiple agents exist, additional design is required for process identifiers, session identifiers, application accounts, credential storage, and event subscription scope.

[0018] For applications such as real-time communication, ticketing, calendars, email, and enterprise collaboration, existing technologies also use webhooks, polling, or message queues to push external events to the agent. In this case, events need to be converted into a context that the model can understand, and duplicate consumption, missed consumption, unauthorized access, and credential leakage must be avoided. The resource models, action models, and event models of different applications vary significantly, often requiring the agent to hard-code a large amount of application semantics.

[0019] Taking chat applications as an example, existing solutions might provide a separate API for "sending messages," another API for "querying contacts," and configure a webhook for "receiving messages." For an agent to send a message to someone, it needs to know the contact's identifier, authentication credentials, message interface, result query interface, and error handling rules. If multiple agents share the same project, they also need to distinguish their respective chat accounts and private message history.

[0020] In the existing solutions described above, application capabilities lack a unified, traversable, and naturally discoverable representation by the model. Tool / API lists are often separated from the actual application state, making it difficult for the model to understand resources, actions, and events simultaneously within the same namespace. Action execution lacks file-level append auditing and stable idempotent keys. If the model, script, or management end retryes the same action, duplicate sending, duplicate creation, or state inconsistencies can easily occur. External events are difficult to align with model round boundaries. Webhoo or message queue events often require additional service transformations, easily leading to event noise, missed wakeups, duplicate wakeups, or excessive context injection. Stable agent identities and runtime process bindings are easily confused. If application accounts are bound by process IDs, session IDs, or random attach IDs, maintaining a consistent private application state is difficult when agents restart, fork, or when multiple agents operate in parallel. In multi-agent scenarios, the lack of a universal isolation model for public applications, private applications, credentials, and event subscription scopes can easily lead to one agent seeing or misusing another agent's private resources. Application structure changes lack a unified refresh mechanism. When dynamic resources such as contacts, group chats, sessions, and scopes emerge, the tools or paths visible to the model may not be updated synchronously. Credentials and access tokens may be placed in prompts, tool parameters, action payloads, event logs, or the model-visible file tree, increasing the risk of leakage.

[0021] The management console (Dashboard), desktop launcher, agent process, and application runtime often maintain their states separately, which can easily lead to inconsistencies between the UI display, process state, and the actual application binding state.

[0022] In summary, existing solutions cannot discover, read, invoke, and respond to applications in a unified manner, resulting in poor processing performance.

[0023] Example 1 This application provides an interaction method for an application file system. This method can map the state, actions, events, identities, and context isolation capabilities of external applications to a file system protocol, enabling agents to discover, read, invoke, and respond to applications in a unified manner. It allows agents to access application states, submit business actions, receive external events, and manage the identities of multiple agents through ordinary file read and write operations, reducing application integration coupling, improving action auditability and idempotency, achieving private context isolation for multiple agents, and preventing credentials from entering the model visibility layer.

[0024] To facilitate understanding of this application, Table 1 below lists the technical terms, meanings, and functions of this application.

[0025] Table 1

[0026] The application's file system interaction methods can be applied to Figure 1 The system architecture shown includes intelligent agents, mounted file trees, control plane, application adapters, external applications, registry, application directory, identity subject registry, event stream files, and control plane.

[0027] Table 2 below is an example table of functional descriptions of the various components of this system architecture.

[0028] Table 2

[0029] The following is combined Figure 2 The document provides a detailed description of the interaction methods for the application file system, which include: Step S101: Publish the runtime manifest using the application file system runtime.

[0030] In this embodiment, the state resources, executable actions, control plane information, event streams, and multi-agent identity contexts of external applications are mapped to mountable or accessible file system protocols according to a pre-defined namespace, and agents interact according to these file system protocols. Agents do not need to directly understand the internal APIs of each external application; instead, they read resource files such as '.res.json' and '.res.jsonl', append JSONL requests to '.act' action files, and obtain action results or external messages from the '_stream / events.evt.jsonl' event stream.

[0031] This approach can be deployed as an operating system mount directory, or hosted on a local directory, SQLite-backed VFS, network file system, or other storage layer. The application adapter provides structure snapshots, resource reading, action execution, and inbound events through connector abstraction. The AppFS runtime supervisor is responsible for materializing these capabilities into a file tree, consuming action files, maintaining event streams, and managing the lifecycle of multiple agents.

[0032] As an example, in the root directory of a project, the application file system runtime controller publishes a versioned runtime manifest. This versioned runtime manifest carries version information and describes the complete configuration of the current AppFS environment, for example: ' / .well-known / appfs / runtime.json'. This manifest includes the runtime type, mount root path, runtime session identifier, multi-agent mode, control plane action path, and event flow path capability flags.

[0033] The mount root path represents the root mount point of the AppFS virtual file tree, corresponding to the virtual directory / _appfs. The runtime session identifier is a globally unique number for the entire set of AppFS runtime instances, distinguishing multiple parallel AppFS instances. Multi-agent mode indicates whether it supports copying (forking) to derive multiple appfs-agents for parallel operation; when enabled, it supports multiple agents running simultaneously. The control plane action path represents the virtual path for control plane actions, storing .act action files for leases and identity management such as create / attach / update / detach / delete. The event stream path points to the / stream directory, which is the location of the .evt.jsonl event log file. This capability flag is a boolean / enumeration flag, indicating which features the current runtime supports, such as: whether gRPC connector is supported, whether stale sweep is enabled, and whether lease mechanisms are enabled.

[0034] In this embodiment, the agent prioritizes discovering the AppFS environment through explicit environment variables or the runtime manifest. If it cannot be obtained, directory heuristic discovery is used. Specifically, directory heuristic discovery includes: when the agent does not have the configuration, it automatically traverses the directory upwards to check if .well-known / appfs / runtime.json exists, and guesses the location of AppFS based on the directory structure. Table 3 below shows examples of the uses of related paths or files.

[0035] Table 3

[0036] In step S102, the runtime controller loads the application registration library, policy registration library, identity subject registration library, and state resources, enters or updates private application policies, and saves path templates, configuration file templates, and credential policies. When a new identity subject completes binding, the private application path and configuration file are automatically instantiated based on the path template and configuration file template. When the policy configuration changes, the policy registration library is updated.

[0037] In step S103, the runtime controller constructs a connector context for the target application, and uses the connector context to call the connector of the application adapter to obtain a structure snapshot.

[0038] In this embodiment, the connector's acquisition interface or adapter refresh interface is called within the connector context to obtain a structural snapshot. The structural nodes returned by the connector must not be written to runtime protected paths, such as '_stream', paging, or snapshot journals. The runtime performs relative path validation, rejecting absolute paths, '..', platform-reserved paths, or insecure paths to prevent connectors or external input from escaping the application root directory.

[0039] Please participate Figure 3 , Figure 3 The diagram illustrates the file tree namespace, showing the directory boundaries of the versioned runtime manifest file, control plane directory, public instance directory, and private instance target. Under the mount root directory, there is the versioned runtime manifest ' / .well-known / appfs / runtime.json', the application file system control plane, the public application instance directory, and the private application instance directory. The application file system control plane includes the application registry, the identity subject registry, and all control plane action files related to the identity subject. The private instance directory includes all resource description files in the application metadata directory, event files in the event flow directory, and all action files / all resource files.

[0040] The following is an example of fields named in a file tree: ├── .well-known / appfs / runtime.json ├── _appfs / │├── apps.registry.json │├── app-policies.registry.json │├── principals.registry.json │├── principals / ││├── create_principal.act ││├── attach_principal.act ││├── update_principal.act ││├── detach_principal.act ││├── delete_principal.act ││└── status.res.json │└── _stream / events.evt.jsonl ├── public / <app> / └── private / <principal-id> / <app> / ├── _app / ├── _stream / events.evt.jsonl ├── .res.json ├── .res.jsonl └── .act.

[0041] In this embodiment, the runtime manifest and registry are the mechanisms by which the application file system runtime publishes its runtime capabilities, control entry points, and state ledger. Agents, launchers, or dashboards use this mechanism to determine whether the current directory is within the application file system (AppFS) environment, which root directory to connect to (mount root), and whether the current runtime supports capabilities such as multi-application, multi-agent binding, event streaming, and application registration.

[0042] The core function of the runtime manifest is runtime discovery and binding contracts. It allows the application file system agent (appfs-agent) to identify AppFS by explicitly displaying the manifest, rather than relying on directory guessing; it also allows the desktop launcher or management console to confirm that the runtime is ready before launching the agent and to inject the root directory, runtime session, and control plane entry into the agent environment.

[0043] The core function of the registry is to store runtime application, policy, and identity states. The application registry records materialized public / private application instances; the policy registry records path templates, profile templates, and credential policies for private applications; and the principal registry records stable agent identities, attach leases, heartbeats, and derived states. Together, they constitute the runtime project-level state ledger, rather than external business data itself.

[0044] This mechanism, which combines runtime manifests and registry libraries, primarily provides four types of capabilities: First, runtime discovery capabilities, enabling agents and initiators to explicitly know whether AppFS exists, how it is bound, and which control actions are available; second, application instance management capabilities, enabling the runtime to materialize / public and / private / according to policies. <principal> / <app>The system includes four main components: a file tree and the ability to distinguish between shared and private applications; a multi-agent identity management capability that allows for unified maintenance of identity subjects, binding leases, configuration files, and online status; and observability and recovery capabilities that enable the management console, agents, and runtime to observe status, filter events, recover private application instances, and troubleshoot lifecycle issues based on a single registry. This comprehensive approach publishes runtime capabilities through a manifest, maintains application instances, policies, and identity subject status through a registry, and drives file tree materialization, visibility control, event filtering, and agent binding.

[0045] Furthermore, the connector forms the boundary between the actual application and the AppFS file tree. The connector only returns the structure, resource pages, action execution results, and inbound events; file creation, event writing, path security verification, and registry management are handled by the runtime. Table 4 below provides a schematic diagram illustrating the interface or data structure.

[0046] Table 4

[0047] In step S104, the runtime controller performs path security verification based on the structure snapshot and generates application metadata directory, event stream directory, resource files, action files, meta manifest files, and cursor files.

[0048] In this embodiment, the structure snapshot (AppStructureSnapshot) returned by the connector includes the application identifier (app_id), version number (revision), active scope (active_scope), ownership prefixes (ownership_prefixes), and a list of nodes. Node types include directory nodes (Directory), action file nodes (ActionFile), snapshot resource nodes (SnapshotResource), live resource nodes (LiveResource), and static JSON resource nodes (StaticJsonResource). At runtime, based on the node type, a directory, an empty action file, a resource placeholder file, or a static JSON resource is created, and '_meta / manifest.res.json' and the structure synchronization status are generated.

[0049] As an example, the runtime constructs a ConnectorContext for a given application, carrying the application identifier (app_id), session identifier (session_id), principal identifier (principal_id), and profile identifier (profile_id). The runtime calls the Connector's `get_app_structure` or `refresh_app_structure` interface, passing in a known version number, refresh reason, target scope, or trigger action path. The Connector returns a snapshot of the structure; if the version number has not changed, it can return "unchanged," and the runtime skips duplicate materialization. The runtime validates each node path, rejecting absolute paths, non-normal path components, and runtime-protected paths. Based on the node type, the runtime creates a directory, empty action file, resource placeholder file, or static JSON file, and generates 'meta / manifest.res.json'. The runtime records the owned path set (owned_paths); during the next structure refresh, it cleans up old paths owned by the connector but no longer needed, while retaining runtime-owned state files such as 'stream'. When a business action or inbound event indicates a structural change, the runtime refreshes the structure based on reasons such as ActionChanged or InboundChanged.

[0050] In this embodiment, the connector interface receives a connector context (ConnectorContext) each time a resource is read, an action is executed, and an event is retrieved. The principal ID and profile ID in this connector context are filled in by the runtime based on the registry, the current application instance, and the private apppolicy. Even if an identity field appears in the business action payload, it cannot be used as a source of authorization; the valid identity is provided by the AppFS context.

[0051] Credentials, access tokens, refresh tokens, passwords, and API keys are stored in the connector's private state, the operating system's secret store, a private database, or encrypted key-value pairs. In the value (KV) field, do not write .act, payload, .res.json resources, event streams, skill text, or model prompts. Application resources only expose security digests, such as credential status, upstream user ID, login credentials, display name, and profile ID.

[0052] Table 5 below provides examples of visible and invisible content at each level.

[0053] Table 5

[0054] In step S105, the agent ensures the existence of the identity subject by using environment variables, runtime manifests, and heuristic discovery of the application file system, and appends a binding action request to the action file of the bound identity subject.

[0055] In this embodiment, the intelligent agent ensures the existence of the identity subject through environment variables, runtime manifests, and heuristic discovery of the application file system, including: The intelligent agent reads the environment variables injected by the operating system. If all environment variables are ready, it obtains the application system environment information. When the environment variables are incomplete, the agent locates and loads the runtime manifest, and parses the runtime manifest to obtain the mount root directory, runtime session identifier, control plane entry, and capability flag, thus completing the application file system environment discovery. If no identity subject is explicitly specified, the intelligent agent will use the default identity subject by default; if the identity subject is detected to be non-existent, a creation request will be appended to the identity subject creation action file to request the creation of a new identity subject.

[0056] In this embodiment, the agent prioritizes reading explicit environment variables, such as APPFS_RUNTIME_MANIFEST, APPFS_MOUNT_ROOT, APPFS_ATTACH_ID, APPFS_PRINCIPAL_ID, and APPFS_AGENT_ROLE. If a runtime manifest exists, the agent reads the mount root directory (mount_root), runtime session ID (runtime_session_id), control plane entry point (control_plane), and capabilities. If no principal is explicitly specified, the agent uses the default principal; if the principal does not exist, a creation request can be appended to create_principal.act. The agent appends a binding request to attach_principal.act to obtain the detach action path and update action path. During headless operation, the agent's background thread periodically appends lightweight heartbeats to update_principal.act. The agent reads the currently visible application instances 'app / skill.res.json', '_app / actions.res.json', '_app / control.res.json', and '_app / events.res.json', and dynamically generates model hints and descriptions of available actions. Model hints emphasize that '.act' files must be appended with JSONL and cannot be overwritten; action results are primarily confirmed through event streams; the peer principal's state is readable but cannot be arbitrarily modified.

[0057] Step S106: The action consumption module of the runtime controller consumes actions by action cursor and generates request identifiers and client tokens.

[0058] In this embodiment, the action file ends with '.act' and serves as an append-only JSONL action slot. The agent, script, or dashboard appends a single line of JSON payload to the action file. The AppFS action consumer module reads only the newly added bytes that haven't yet been processed, based on the action cursor. This mechanism avoids the model directly calling internal APIs, ensuring that each action request leaves a file-level audit trail. Table 6 below illustrates the processing stages and key technical methods.

[0059] Table 6

[0060] In one embodiment, the action consumption module of the runtime controller consumes actions by action cursor and generates request identifiers and client tokens, including: The action consumption module reads the processed offset position recorded by the action cursor; Read the new bytes after the processed offset position, parse the new JSONL action line, and generate a globally unique request identifier; retain or complete the client token according to the action payload.

[0061] See Figure 4 , Figure 4 The diagram shown is another flowchart illustrating the interaction method of the application file system, specifically a flowchart of the append action processing flow, including the following steps: Step S301: The agent appends a JSONL-formatted action request to the action file.

[0062] In step S302, the action consumption module incrementally reads the newly added action using the action cursor.

[0063] Step S303: Verify the legality of the action payload and generate a request identifier and token.

[0064] Step S304: Construct a connector context, carrying identity, session, and application information.

[0065] Step S305: Invoke the application adapter to execute business actions for external applications.

[0066] Step S306: Write the action execution result event to the event stream file.

[0067] The following is a diagram illustrating the fields used in the additional action processing flow: / / Add a line of JSONL to contacts / send_message.act {"to":"principal:code-implementer","text":"Please handle this implementation task.","requires_response":true,"client_token":"msg-001"} / / After runtime consumption, the data is written to stream / events.evt.json. {"seq":12,"event_id":"evt-12","type":"action.completed","path":"contacts / send_message.act","request_id":"req-4a1b2c3d","client_token":"msg-001","content":{"ok":true}}.

[0068] In step S107, the action consumption module passes the action payload, the connector context, the request identifier, and the client token to the application adapter's submit action interface to initiate action execution; the application adapter executes the business action logic and sends the execution result back to the application file system runtime; the event publishing module of the runtime controller constructs the corresponding event record.

[0069] In one embodiment, the method further includes: The runtime controller periodically calls the inbound event pull interface to read the inbound events to be processed generated by external applications; The event publishing module performs normalization processing on the inbound events to be processed and appends the normalized inbound events to the event stream file.

[0070] In this embodiment, the event stream file is 'stream / events.evt.jsonl'. Each event may contain at least the following fields: event sequence number (seq), event identifier (event_id), timestamp (ts), application identifier (app), session identifier (session_id), request identifier (request_id), path (path), event type (type), content (content), error message (error), and client token (client_token). Event sources include action result events, connector inbound events, principal lifecycle events, and credential status events.

[0071] The application file system agent (appfs-agent) reads new events based on the event cursor stored in the session before model invocation. If the event requires model attention, it is injected as pending input into the next model round. For external message events, the system can display the text as user-visible input, along with a source notification; for ordinary state events, the system can render them as system prompts, explicitly stating that the application file system event belongs to an untrusted context with source annotation and is not a system command.

[0072] Table 7 below is a schematic table of event types, example event types, and processing methods in the event stream file.

[0073] Table 7

[0074] In one embodiment, the method further includes: The agent reads new events from the event stream based on the event cursor stored in the session and transmits the new events to the input router. The input router categorizes new events. If the new event is an event that requires model awareness, it assembles the new event into a processing input and injects the processing input into the next model call round. If the new event is a specific event, it wakes up an idle agent. After the woken agent processes the specific event, it updates the event cursor corresponding to the session.

[0075] Please see Figure 5 , Figure 5 The diagram illustrates another flow chart of the application file system interaction method, specifically a diagram of the event wake-up process. It includes the following steps: S401, an external application generates a new message / status.

[0076] S402, at runtime, pulls inbound events from the connector from the outside.

[0077] S403 writes events to the .evt.jsonl event file at runtime.

[0078] S404, the agent collects new events based on the event cursor.

[0079] S405, the input router injects events into the model round.

[0080] S406, Source Labeling, Untrusted Context Warning: External events cannot be escalated to system commands.

[0081] In one embodiment, the method further includes: The intelligent agent periodically generates a heartbeat load, which is written into the control plane action file; The action consumption module consumes heartbeat actions and refreshes the bound lease record; The main identity management module of the runtime controller periodically triggers an expired scan task; The subject identity management module compares the current time with the last active timestamp of the lease field to determine whether the time difference between the current time and the last active timestamp of the lease field exceeds the disconnection threshold. If the time difference exceeds the disconnection threshold, it is determined that the intelligent agent has lost contact and the invalid bound lease is cleared.

[0082] In this embodiment, the principal_id represents a stable semantic identity of the agent in the project, such as a default principal, a code-implementer principal, or an incident-reporter principal. The attach_id represents a temporary attachment of a runtime process to a principal. A principal can reuse the same private application instance and application account across processes; the attachlease is refreshed with the last active time (last_seen_at) via heartbeat, and the runtime cleans up attachments to lost processes based on the stale threshold.

[0083] Table 8 below is a schematic diagram of life cycle actions and functions.

[0084] Table 8

[0085] In this embodiment, the Private app policy defines an application as a private application and configures a path template and a profile template. For example, the policy for third-party application A can be defined as visibility=private, path_template=private / {principal_id} / A, and profile_template=A:{principal_id}. When an identity subject is created or bound, the runtime automatically instantiates the private path and generates a profile identifier (profile_id).

[0086] The following is an example of the fields used to define the identity subject: principal_id = code-implementer instance_id= A--code-implementer path = private / code-implementer / A profile_id = A:code-implementer.

[0087] In one embodiment, the method further includes: The policy management module of the runtime controller reads the private application policy, performs variable replacement on the subject identity identifier in the path template and configuration file template; instantiates the virtual path exclusive to the subject identity identifier, generates the configuration file identifier, and registers the private application instance in the application registry. When the subject identity is deleted, the application file system searches the application registry at runtime, reclaims all private application virtual paths and configuration-related records corresponding to the subject identity, and cleans up the corresponding instance records in the application registry.

[0088] Please see Figure 6 , Figure 6 The diagram shown is another flowchart of the interaction method of the application file system, specifically a flowchart of the identity subject lifecycle, including the following steps: Step S501: The identity subject does not exist.

[0089] Step S502: Create an identity subject, trigger the instantiation of the private application, and automatically generate the corresponding path and configuration file based on the identity subject.

[0090] Step S503: The running process establishes a binding lease with the identity subject.

[0091] Step S504: The process continuously sends heartbeats to maintain the lease validity.

[0092] Step S505: The process exits normally, actively unbinds, and proceeds to deletion and cleanup.

[0093] Step S506: Heartbeat timeout and disconnection. Runtime will perform expired cleanup and force recycling of bindings.

[0094] Step S507: Release the identity subject and clean up all resources related to the private application.

[0095] The following example uses a third-party real chat application, A. Third-party real chat application A is defined as a private account-backed app. Each identity corresponds to a unique path ' / private / '. <principal-id> / A' and a profile 'A: <principal-id>`attach_id` does not possess credentials for the third-party real chat application A; `principal_id` consistently possesses credentials for the third-party real chat application A. When an agent replicates and generates a new identity, the new identity will by default obtain the new third-party real chat application A configuration file. It should be noted that the third-party real chat application A can be Tinode or other chat applications; there are no restrictions here.

[0096] Table 9 below illustrates the path and purpose of a third-party real chat application A.

[0097] Table 9

[0098] In this embodiment, when an agent wants to send a private message to another identity, it appends a JSON line to 'contacts / send_message.act' under the app root of the current identity's third-party real chat application A. After consuming this action at runtime, the identity identifier (principal_id) and profile identifier (profile_id) are passed to the connector of the third-party real chat application A through the ConnectorContext. The connector finds the credentials of the current identity's third-party real chat application A based on the profile identifier, parses 'principal:code-implementer' to find the profile or contact of the target identity's third-party real chat application A, sends the message, and generates events such as message.sent and action.completed. If retrying with the same client token, the connector can return a completed result to avoid duplicate sending.

[0099] The connector for the third-party real-world chat application A pulls new messages according to the current configuration profile in the `drain_inbound_events(ctx)` method. Upon receiving an external message, the connector updates its local message resources and inbox, returning events such as `message.received` and `inbox.updated`. At runtime, these events are written to `_stream / events.evt.jsonl`. The application file system—the agent—reads the events before the next model round, using the messages it needs to focus on as input reminders, along with the source, contact key (`contact_key`), target identity, and event sequence number (`seq`).

[0100] In multi-agent group chats, the current principal can append a JSON file containing the group title and a member list to the group creation action file groups / create_group.act. The member list can be represented using the principal. <principal-id>The connector parses member credentials using the application file system registry library and the third-party real chat application A, creates a group chat, and invites members. Subsequent messages are sent via the group / <group key> / message action file groups / . <group-key> / send_message.act sends the message.

[0101] Please refer to the figure. Figure 7 , Figure 7 The image shows an interactive diagram of a third-party real chat application, A. Figure 7 There are two independent identity entities: the "default" entity, corresponding to the private path / private / default / A and configuration file A:default; and the "code" entity, corresponding to the private path / private / code / A and configuration file A:code. Each of these independent identity entities connects to a third-party real-world chat application A via a connector. The connector provides message sending, inbox, and group access capabilities based on the credential status of each identity entity, interacting with the server of the third-party real-world chat application A. The server processes point-to-point private messages and group topic conversations, and the data flows back to the respective private file paths of each identity entity via the connector.

[0102] In this embodiment, the Dashboard acts as the management interface, providing interfaces for listing, creating, deleting, starting, stopping, and restoring identity entities via HTTP routing. Its lifecycle service reads ' / _appfs / principals.registry.json' and '_appfs / principals / status.res.json', and submits management actions by appending files such as create_principal, detach_principal, and delete_principal.

[0103] When the Dashboard starts the agent, it constructs an instance to generate configuration and injects variables such as AppFS principal ID (APPFS_PRINCIPAL_ID), AppFS binding ID (APPFS_ATTACH_ID), AppFS mount root directory (APPFS_MOUNT_ROOT), and AppFS runtime manifest path (APPFS_RUNTIME_MANIFEST) into the child process environment. After the agent process starts, it returns information such as session started (session_started), control endpoint, and principal ID (principal_id) via standard output (stdout) JSONL. The Dashboard maintains the process state based on this and displays the online status in conjunction with the runtime principal registry library (y).

[0104] The desktop Electron launcher is responsible for starting the dashboard server, selecting an available port, setting the environment variables for the AppFS command-line interface (CLI) and agent binary, and performing graceful shutdown or process tree cleanup. In this embodiment, the AppFS file protocol serves not only the model rounds but also the UI dashboard and the desktop launcher, enabling the dashboard, runtime, and agents to share the same lifecycle truth source.

[0105] In this embodiment, by uniformly mapping resources, actions, and events to a file tree, the agent can complete application interactions using ordinary file read and write, reducing the integration cost of hard-coding tools / APIs for each application and improving processing efficiency. Through append-only action slots (.act), action cursors, and stable client tokens, auditable, replayable, and deduplicatable record boundaries are provided for action execution, reducing the risk of duplicate execution and state corruption. Through the runtime manifest and the self-describing '_app / .res.json' file, the agent can dynamically discover application capabilities based on the current mounted environment, reducing the need to statically insert large amounts of application descriptions into prompts.

[0106] In this embodiment, the identity subject and binding lease are separated, ensuring that the stable intelligent agent identity does not depend on a one-time process; the intelligent agent can still reuse its own private application instance and configuration file after restarting or resuming the session. This is achieved through the public ' / public' and private ' / private / ' interfaces. <principal>Namespace and visible application filtering support multiple agents within the same project to share public resources while isolating private applications, credentials, and events. Valid identity is provided through the ConnectorContext, and credentials are stored in the connector's private state, preventing models from impersonating other configurations through payloads and avoiding token leaks to model-visible files or events.

[0107] In this embodiment, external application events are injected into model rounds according to priority through event streams and input router classification strategies, enabling event-driven agent responses such as user messages, action failures, and credential states. Through structural snapshot and refresh mechanisms, dynamic application structures such as contacts, group chats, and scopes can be materialized into new model-visible paths, improving operability after application state changes. Through the Dashboard / desktop implementation, operators can locally and visually manage multiple identities and headless agents, reducing the operational complexity of running, stopping, resuming, and cleaning up multiple agents.

[0108] Example 2 In addition, this application provides an interactive device for an application file system.

[0109] like Figure 8 As shown, the interactive device 800 for the application file system includes: Application File System Runtime 801 is used to publish the runtime manifest; Runtime controller 802 is used to load application registry, policy registry, identity subject registry and state resources, enter or update private application policies, and save path templates, configuration file templates and credential policies. When a new identity subject is bound, the private application path and configuration file are automatically instantiated based on the path template and the configuration file template. When the policy configuration is changed, the policy registry is updated. The runtime controller 802 is also used to construct a connector context for the target application, and to call the connector of the application adapter in the connector context to obtain a structure snapshot; The runtime controller 802 is also used to perform path security verification based on the structure snapshot, and generate application metadata directory, event stream directory, resource files, action files, meta manifest files, and cursor files; Intelligent agent 803 is used to discover the application file system through environment variables, runtime manifests, and heuristics to ensure the existence of the identity subject and to append binding action requests to the action file of the bound identity subject. The action consumption module of the runtime controller 802 is used to consume actions by cursor and generate request identifiers and client tokens. The action consumption module is also used to pass the action payload, the connector context, the request identifier, and the client token to the application adapter's submit action interface to initiate action execution; The application adapter 804 is used to execute business action logic and return the execution result to the application file system at runtime. The event publishing module of the runtime controller 802 is used to construct corresponding event records.

[0110] The application file system interaction device 800 provided in this embodiment can implement the application file system interaction method provided in Embodiment 1 and achieve the corresponding technical effects. To avoid repetition, it will not be described again here.

[0111] Example 3 In addition, this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program, and the computer program executes the application file system interaction method provided in Embodiment 1 when running on the processor.

[0112] The electronic device provided in this embodiment can implement the interactive method of the application file system provided in Embodiment 1. To avoid repetition, it will not be described again here.

[0113] Example 4 This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the interactive method of the application file system provided in Embodiment 1.

[0114] In this embodiment, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0115] The computer-readable storage medium provided in this embodiment can implement the interactive method of the application file system provided in Embodiment 1. To avoid repetition, it will not be described again here.

[0116] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0117] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0118] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.< / principal> < / app> < / principal> < / app> < / principal-id> < / app>

Claims

1. An interactive method for an application file system, characterized in that, The method includes: The application file system runtime publishes a runtime manifest; The runtime controller loads the application registry, policy registry, identity subject registry, and state resources, enters or updates private application policies, and saves path templates, configuration file templates, and credential policies. When a new identity subject completes binding, it automatically instantiates the private application path and configuration file based on the path template and configuration file template. When the policy configuration changes, it updates the policy registry. The runtime controller constructs a connector context for the target application, and uses the connector context to call the connector of the application adapter to obtain a structure snapshot; The runtime controller performs path security verification based on the structure snapshot and generates application metadata directory, event stream directory, resource files, action files, meta manifest file, and cursor file; The intelligent agent discovers the application file system through environment variables, runtime manifests, and heuristics to ensure the existence of the identity subject and appends binding action requests to the action file bound to the identity subject; The runtime controller's action consumption module consumes actions by action cursor and generates request identifiers and client tokens; The action consumption module passes the action payload, the connector context, the request identifier, and the client token to the application adapter's submit action interface to initiate action execution; the application adapter executes the business action logic and sends the execution result back to the application file system runtime; the event publishing module of the runtime controller constructs the corresponding event record.

2. The method according to claim 1, characterized in that, The method further includes: The runtime controller periodically calls the inbound event pull interface to read the inbound events to be processed generated by external applications; The event publishing module performs normalization processing on the inbound events to be processed and appends the normalized inbound events to the event stream file.

3. The method according to claim 2, characterized in that, The method further includes: The agent reads new events from the event stream based on the event cursor stored in the session and transmits the new events to the input router. The input router categorizes new events. If the new event is an event that requires model awareness, it assembles the new event into a processing input and injects the processing input into the next model call round. If the new event is a specific event, it wakes up an idle agent. After the woken agent processes the specific event, it updates the event cursor corresponding to the session.

4. The method according to claim 3, characterized in that, The method further includes: The intelligent agent periodically generates a heartbeat load, which is written into the control plane action file; The action consumption module consumes heartbeat actions and refreshes the bound lease record; The main identity management module of the runtime controller periodically triggers an expired scan task; The subject identity management module compares the current time with the last active timestamp of the lease field to determine whether the time difference between the current time and the last active timestamp of the lease field exceeds the disconnection threshold. If the time difference exceeds the disconnection threshold, it is determined that the intelligent agent has lost contact and the invalid bound lease is cleared.

5. The method according to claim 4, characterized in that, The method further includes: The policy management module of the runtime controller reads the private application policy, performs variable replacement on the subject identity identifier in the path template and configuration file template; instantiates the virtual path exclusive to the subject identity identifier, generates the configuration file identifier, and registers the private application instance in the application registry. When the subject identity is deleted, the application file system searches the application registry at runtime, reclaims all private application virtual paths and configuration-related records corresponding to the subject identity, and cleans up the corresponding instance records in the application registry.

6. The method according to claim 1, characterized in that, The intelligent agent ensures the existence of the identity subject through environment variables, runtime manifests, and heuristic discovery of the application file system, including: The intelligent agent reads the environment variables injected by the operating system. If all environment variables are ready, it obtains the application system environment information. When the environment variables are incomplete, the agent locates and loads the runtime manifest, and parses the runtime manifest to obtain the mount root directory, runtime session identifier, control plane entry, and capability flag, thus completing the application file system environment discovery. If no identity subject is explicitly specified, the intelligent agent will use the default identity subject by default; if the identity subject is detected to be non-existent, a creation request will be appended to the identity subject creation action file to request the creation of a new identity subject.

7. The method according to claim 1, characterized in that, The runtime controller's action consumption module consumes actions by action cursor and generates request identifiers and client tokens, including: The action consumption module reads the processed offset position recorded by the action cursor; Read the new bytes after the processed offset position, parse the new JSONL action line, and generate a globally unique request identifier; retain or complete the client token according to the action payload.

8. An interactive device using a file system, characterized in that, The device includes: The application file system runtime is used to publish the runtime manifest; The runtime controller is used to load the application registry, policy registry, identity subject registry and state resources, enter or update private application policies, and save path templates, configuration file templates and credential policies. When a new identity subject is bound, the private application path and configuration file are automatically instantiated based on the path template and the configuration file template. When the policy configuration is changed, the policy registry is updated. The runtime controller is used to construct a connector context for the target application, and to call the connector of the application adapter in the connector context to obtain a structure snapshot; The runtime controller is used to perform path security verification based on the structure snapshot, and generate application metadata directory, event stream directory, resource files, action files, meta manifest files, and cursor files; Intelligent agents are used to discover the application file system through environment variables, runtime manifests, and heuristics, ensure the existence of the identity subject, and append binding action requests to the action file bound to the identity subject. The action consumption module of the runtime controller is used to consume actions by cursor and generate request identifiers and client tokens; The action consumption module is also used to pass the action payload, the connector context, the request identifier, and the client token to the application adapter's submit action interface to initiate action execution; The application adapter is used to execute business action logic and return the execution results to the application file system at runtime; The event publishing module of the runtime controller is used to build corresponding event records.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program that executes the application file system interaction method of any one of claims 1 to 7 when the processor is running.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when run on a processor, executes the interactive method of the application file system according to any one of claims 1 to 7.

Images