A real DSH tool turn powered by Spark Ultra and an Astron-exported SKILL

#ai #agents #opensource #workflow

Astron Agent can export a workflow as SKILL.md, while DeepSeek Harness (DSH) discovers skills under project skill directories. The useful integration point is not a slide-to-slide format comparison: it is whether another model can read that exported capability and autonomously decide when to use it.

We tested that path with iFlytek Spark 4.0Ultra. The user prompt described only the goal—save a memory through the Astron workflow and immediately recall it—and named no tool. Spark selected the complete DSH tool sequence itself:

skill → pwsh → pwsh

The recorded session completed four model steps. All three tool results were successful. The published Astron workflow returned HTTP 200, provider code 0, and two parsed events, and the recalled text contained the test marker.

What the sequence actually means

This is an observed model decision chain, not a hard-coded three-command script.

skill: Spark recognized that the exported astron-memflywheel capability matched the goal and asked DSH to load its instructions.
First pwsh: after reading the instructions, Spark constructed the loopback HTTP call that invokes the real Astron workflow.
Second pwsh: after receiving a non-error result, Spark chose an additional execution/check before answering.
Final model step: Spark stopped calling tools and summarized the observed results.

The tool patch exposed only skill and pwsh, but neither the prompt nor the patch prescribed their order or call count. “Autonomous” therefore means Spark chose the next action within that bounded tool set from the goal and each returned result. It does not mean unrestricted autonomy, model training, or a native Astron–DSH integration.

A second, post-portability run makes this distinction measurable. In a read-only DSH sandbox, the same public runner discovered astron-memflywheel, and Spark selected only skill → pwsh before answering. That turn completed in three model steps with 2/2 non-error tool results and the recall marker present. The original second pwsh was therefore a model-chosen extra action in that turn, not a requirement encoded by the runner or Skill.

DSH does not require a DeepSeek-only key

DSH's provider layer can use an OpenAI-compatible API. The public example registers Spark with a small patch:

- id: llm-pi-ai
  config:
    providers:
      iflytek-spark:
        displayName: iFlytek Spark Ultra
        apiKeyEnv: IFLYTEK_SPARK_API_PASSWORD
        api: openai-completions
        baseURL: http://127.0.0.1:8788/v1
        models:
          - id: 4.0Ultra
            name: Spark 4.0 Ultra
            contextWindow: 32768
            maxTokens: 4096

- id: agent-default-model
  config:
    provider: iflytek-spark
    model: 4.0Ultra

The loopback compatibility process forwards the request to Spark's official OpenAI-compatible HTTP endpoint at https://spark-api-open.xf-yun.com/v1/chat/completions. It uses the console APIPassword through the Authorization: Bearer ... header. This is different from the WebSocket credential set made of APPID + APIKey + APISecret.

For the tested DSH release, the local adapter also normalizes the final streamed finish_reason when Spark omits it. It binds only to 127.0.0.1 and does not log authorization headers or request bodies.

Keep the operational export private

An Astron-exported operational skill can contain the workflow endpoint, flow ID, and authorization header required to call the published application. Those values should not be exposed to the model or committed to Git.

The reproducible bundle therefore separates two artifacts:

a sanitized, model-visible skill that only calls a loopback bridge;
the private Astron export under an ignored .runtime/ directory, read only by that bridge.

The same separation applies to the Spark password, which stays in IFLYTEK_SPARK_API_PASSWORD. The repository contains placeholders and environment-variable names, never a credential value.

The complete runtime chain

goal-only prompt
  → DSH
  → Spark 4.0 Ultra
  → skill(astron-memflywheel)
  → pwsh
  → loopback Astron bridge
  → published Astron workflow API
  → MemFlywheel save + recall
  → tool result returned to Spark
  → final answer

The demonstration patch limits the available tools to skill and pwsh, but it does not tell Spark which tool to call first or how many calls to make. That order came from the model as it consumed each real result.

Reproduce it

The public example contains the requested spark-ultra.patch.yml and portable run-dsh-spark.ps1, plus the compatibility proxy, sanitized skill, and local bridge files needed to understand the full chain.

This positions Astron as a low-code workflow and SKILL factory, while DSH remains the agent harness and the model remains replaceable. The value is the working boundary between them—not a claim that the integration is native.