Plugins and automations

KsADK 0.8.5 provides local-first plugin lifecycle operations, ecosystem host bridges, platform resource plugins, Scheduler Lite, and a shared conversation surface. Released Agents and precisely identified historical Bundles remain on their original paths and do not require a Runtime rebuild or upgrade.

Studio and Hosted UI pin the versioned Conversation v1 headless module from @kingsoftcloud/ksadk-web@0.3.12. Release artifacts are rebuilt from the public npm package and pass source, browser, and artifact audits. Each cloud environment still needs its control plane, resource authorization, and Runtime image verified against the boundaries below.

0.8.5 delivery and installation boundaries

Studio uses a managed full DSH Core/Profile and renders plugin settings in its own interface. Codex plugins retain native App Server ownership. Installing a plugin makes it available in the workspace; bind the required skills and MCP capabilities to the Agent before use. Multiple UI plugins have independent entries; opening settings does not select the IM plugin automatically.

Codex cloud delivery freezes plugin bytes and admitted references into immutable artifacts associated with the Agent version. It requires compatible control-plane artifact APIs and storage; an unsupported endpoint blocks deployment instead of silently dropping plugins. It does not copy desktop OAuth credentials. Cloud MCP OAuth and credential management are deferred. A skill being present does not prove its MCP server is connected or authenticated.

Knowledge bases, long-term memory, and Skill Center enter the same Build/Activation path through official platform resource plugins. Studio stores resource connection identifiers without writing AK/SK values or runtime tokens into the Agent spec. The Build freezes the connection reference, resource type, and plugin digest; Runtime resolves the connection using account, region, and platform-injected credentials. Knowledge is exposed as read-only retrieval tools, memory recall and writes follow the Agent policy, and Skill Center supplies skill discovery and loading. A visible bound state means that configuration entered the Agent Revision; it does not grant server-side authorization or prove current network reachability.

The universal Python wheel includes Web 0.3.12 and built Studio pages. The installer resolves the Python dependencies declared by pyproject.toml, while the wheel itself does not contain Node/Codex/DSH binaries, community plugins, or credentials. Extras provide additional capabilities; a fully disconnected installation also requires a prepared dependency wheelhouse and native toolchains. Existing cloud Agents are unchanged until explicitly rebuilt and redeployed.

The managed DSH toolchain pins Node.js 22, DSH 0.1.7-rc.1, and pnpm@11.7.0. Studio packaging installs that version with the bundled Node/npm runtime. If developers override AGENTENGINE_PNPM_BIN, it must point to the same verified version.

Choose an integration mode

KsADK does not define a third private package, manifest, or ABI. Plugins do not change Kernel contracts: a new Runtime is a coarse-grained AgentProvider in a standard DSH Bundle, while Codex plugins stay under App Server ownership.

Reuse the Codex and DSH data planes

Both ecosystems retain their native hosts; neither is converted into a private KsADK plugin format:

The Codex manifest reader accepts official camelCase and compatible snake_case spellings, but rejects alias collisions. Local, Git, and npm sources must resolve to immutable coordinates: Git requires a full commit SHA and npm requires an exact semver; host-reported integrity is retained in the source snapshot. Only selected components reach the Agent. Because Codex does not currently expose a verifiable hook-trust API, a Build that selects hooks is blocked rather than bypassing the host trust prompt.

The DSH capability sidecar binds a random loopback port, uses a process-only bearer lease, and bounds request, argument, result, concurrency, deadline, and Node-heap resources. Cancellation reaches the Cordis AbortSignal; Profile mutation, disable/uninstall, and Studio shutdown revoke UI leases, cancel active calls, and clean up the complete sidecar process group. The shipped ten-method dsh-agent-provider-host/v1 ABI remains unchanged. Tool projection uses a separate standard mcp.connector/v1 data plane so existing Bundles keep working.

The capability endpoint also publishes an in-memory provider MCP Resource that can be added directly to a Harness/Plugin Agent's MCP bindings. A Build locks only the Profile, descriptor, inventory, and tool-filter identity. PluginHost reacquires and fences the endpoint/bearer lease for every new Agent activation, so neither address nor credential enters Catalog files, the Agent spec, Bundle, or plugin lock. A Profile change withdraws the old Resource first, and an old Build fails closed on digest mismatch.

The local capability host requires Node.js >= 22.19 and the KsADK-pinned DSH release. It never falls back to an arbitrary DSH CLI from PATH.

DSH client UI and the Channel page

Studio runs a managed full DSH Core/Profile. The official @kingsoftcloud/dsh-channels-client is a wheel-owned web client bundle. Its dsh.client.inject entry uses @deepseek-ai/dsh-app-studio and registers a Channels workspace slot in Studio. It mounts the UI only; it does not start a Channel API/worker or bundle the Channel service into the Python wheel.

Studio installs and enables this bundle in the background after its HTTP service is ready. Set KSADK_STUDIO_CHANNEL_DEFAULT=0 to disable automatic activation. A failed first activation does not block the Studio shell; restart Studio or explicitly enable the bundle from plugin settings to try again. An explicit disable is preserved instead of being undone on the next launch. The Channels page then calls the independently deployed Channel service through the local Studio API; Studio and high-code Agents share the outbound-WSS ksadk.connector protocol.

The Channel UI and protocol client are maintained in ksadk-python and shipped in the wheel; DSH Core/Profile remains owned by the managed toolchain. Navigation, workspace slots, and mounting use DSH extension points instead of editing minified static assets.

Develop a DSH Bundle

Developers do not need a DeepSeek Harness source checkout or local build. Install the pinned, managed DSH CLI from public npm, then create, validate, test, and pack a standard DSH Bundle:

agentengine plugin toolchain status
agentengine plugin toolchain install
agentengine plugin create ./my-provider --name @example/my-provider
agentengine plugin validate ./my-provider
agentengine plugin test ./my-provider
agentengine plugin pack ./my-provider --output-dir ./artifacts

The generated project is an ordinary npm package using DSH dsh.bundle.patch and Cordis composition; it does not contain ksadk-plugin.yaml. validate and test exercise install, projection, disable, enable, and uninstall in a temporary Profile. pack uses the pinned pnpm toolchain and npm files semantics to produce a .tgz.

Install the packed Bundle into an isolated Profile and use the same DSH lifecycle commands:

agentengine plugin install ./artifacts/example-my-provider-0.1.0.tgz \
  --accept-host-permissions
agentengine plugin disable @example/my-provider
agentengine plugin enable @example/my-provider
agentengine plugin uninstall @example/my-provider

The release gate installs the pinned DSH toolchain from public npm and validates a generated Bundle, its .tgz, and the package-format and installation boundary of the official Codex subagent package:

KSADK_DSH_TOOLCHAIN_E2E=1 \
uv run --extra all pytest -q tests/e2e/test_dsh_managed_toolchain_e2e.py

This check does not claim that the P2-06 DSH Codex Bundle/child Provider execution path is complete. A separate real external Node AgentProvider runs install, two stateful turns, disable, a broken update with rollback, re-enable of the old executable package, and uninstall in one managed Profile.

A local DSH source build may differ when it contains unreleased changes. Normal plugin development, CI, and publishing always use the pinned npm version as the compatibility baseline. Only DSH core contributors validating the next release should set KSADK_DSH_BIN explicitly; a version mismatch fails closed. KsADK wraps the official commands and does not copy the DSH compiler.

Manage Codex plugins

Codex App Server owns plugin discovery, installation state, and uninstall operations. KsADK calls the host protocol and does not interpret or execute plugin code:

agentengine plugin codex list
agentengine plugin codex info <plugin-id>
agentengine plugin codex install <plugin-id> --accept-host-permissions
agentengine plugin codex uninstall <plugin-id>

The bridge returns a typed unavailable error when Codex App Server is missing. Installation confirms that the plugin runs with the current system user's host permissions; plugin authentication remains in Codex.

Manage a DSH Profile

An isolated DeepSeek Harness Profile owns DSH plugins. Install, enable/disable, update, and uninstall operations call managed native dsh plugin; each mutation runs host configuration preflight. A directory or .tgz is frozen into a SHA-256-addressed immutable source. Digest drift fails closed before enable, update, or projection, and a failed update restores the old manifest, lock, state, and executable package:

export KSADK_DSH_HOME=/path/to/isolated/dsh-home
export KSADK_DSH_PROFILE=web

agentengine plugin list
agentengine plugin install <bundle> --accept-host-permissions
agentengine plugin disable <bundle-name>
agentengine plugin enable <bundle-name>
agentengine plugin profile
agentengine plugin uninstall <bundle-name>

agentengine plugin dsh ... remains only as a compatibility alias for early scripts.

A DSH bundle may run install scripts, so host permissions require explicit confirmation. An AgentProvider appears in the Runtime selector only after handshake, permission, conversation-projection, and execution conformance pass.

The DSH capability sidecar currently requires POSIX process-group isolation. Windows and cloud deployment fail closed until process-tree cleanup and Node Profile materialization can be verified; the host never degrades to parent-only termination.

Create a local scheduled task

Studio's Automations page supports once, interval, and cron schedules with IANA timezones. A task can be enabled, disabled, edited, deleted, or run immediately; its detail view shows the next run and occurrence history. The Automations tab on an Agent detail page scopes both listing and creation to that Agent.

Integrate the conversation surface

ConversationSurface advertises accepted inputs, ConversationInput submits only allowed fields, and ConversationItem represents text, reasoning, tools, approvals, A2UI, and unknown output. Studio, Hosted UI, and custom clients merge live and replayed data with the same item identity.

The core renderer provides a generic fallback. Provider-specific UI uses a controlled Renderer or A2UI surface. Unknown items remain visible and non-interactive: clients must not drop them or turn unrecognized data into an action. An approval item is writable only when it carries a durable revision; clients keep an item read-only when revision is missing.

The surface becomes stable and writable only after the shared Web package, Studio, Hosted UI, and independent-client browser E2E gates pass.

Compatibility and release gates

A game extension can use one DSH Bundle to combine Tool, Store, Renderer/A2UI, and Studio slots, or contribute a dedicated AgentProvider for a complete game loop. It does not change the Kernel protocol and is not marked supported before permission, lifecycle, conversation-projection, and rollback tests pass.