MetaFlywheel: DSH Plugin Providing a Meta-Problem Modeling (MPM) Cognitive Flywheel Engine

DSH (DeepSeek Harness) plugin ecosystem aims to extend agent capabilities by composing row plugins. For building LLM agents that require rigorous reasoning paths and problem management, MetaFlywheel provides a resident cognitive engine that translates Meta-Problem Modeling (MPM) theory into executable code logic.

MetaFlywheel is an LLM agent runtime implementation of the Meta-Problem Modeling (MPM) cognitive flywheel. It is not a standalone npm package, but a Cordis composition row plugin hosted by DSH. Its core value lies in transforming a problem methodology paper into a resident engine responsible for continuous bookkeeping, autonomous review, and guiding problem resolution.

Core Capabilities¶

The plugin provides a complete problem lifecycle management mechanism:

Six-stage problem lifecycle: A problem goes through generation (G), framing (F), solving (S), convergence (C), sedimentation (D), and excitation (E), forming a spirally ascending cognitive flywheel.
Dual convergence criteria: It distinguishes “understanding the problem” (δ) from “a solution reaching the goal” (ε), identifies convergence types such as misframed convergence and vague convergence, and handles three undecidable cases.
Metabolic ledger and general ledger principle: Each tool call automatically accumulates a metabolic cost, and off-ledger calls without an active in-floop issue are blocked by a tool-level gate.
Mentor rule layer: Includes normative enforcement mechanisms such as evidence gates, misframing guards, general-ledger hard gates, and stagnation issue selection.
Resident inspection: Periodically detects stale issues, stagnation states, and quantitative drift signals, and parks delayed delivery during sleep periods.
Individual-layer five bricks:
- Principal thinking style: Records original judgment phrasing and constrained objects, supporting timestamp overrides and oscillation guards.
- Unverified list: Survives across generations, requires retirement conditions to be specified, and write-off requires evidence.
- Hit backflow: Records each hit and its handling; the unhandled count must be visible.
- Endogenous agenda: Calculates “what should be done” based on ledger state; level is L2.
- Adoption backflow: Records genuine adoption behavior; loopback rate is calculated separately from post-hoc chain patches.

Installation and Activation¶

The plugin depends on the DSH host environment. After installation, restart the host to activate the engine.

One-click installation¶

The official installation script is recommended (requires network connectivity to GitHub):

# Windows PowerShell
irm https://raw.githubusercontent.com/NBagent-dev/metaflywheel/main/install/install.ps1 -OutFile install-mfw.ps1; .\install-mfw.ps1

Manual mounting¶

Copy the engine files to the user configuration directory:
- engine/host.js → ~/.dsh/mpm/engine/host.js
- install/cordis.patch.user.example.yml → ~/.dsh/mpm/cordis.patch.user.yml
Edit the composition patch file and insert the engine line:

    - insert:
      - id: mpm-flywheel
        name: file:///<你的HOME>/.dsh/mpm/engine/host.js

Sync the engine (if an update is needed): run powershell -ExecutionPolicy Bypass -File install/sync-engine.ps1.

Bundle form¶

Since v0.1.1, the plugin supports the DSH Bundle contract:

dsh plugin add metaflywheel

After activation, the plugin injects 16 tools into the system, including mpm_generate (generation), mpm_frame (framing), mpm_solve (solving), and mpm_converge (convergence).

Typical Usage and Configuration¶

After successful installation, you can verify the merged configuration as follows:

# 检查配置叠加情况
dsh --dump-default-config

The plugin registers with the ID mpm-flywheel. If mounted via a composition patch, ensure the path is correct. The plugin automatically injects a self-snapshot into the system prompt, including problem state, metabolic summary, and individual-layer five-brick data.

Applicable scenarios and notes¶

Applicable scenarios: Complex agent tasks that require a strict distinction between “understanding the problem” and “solving the problem”, or workflows that require recording the agent’s decision rationale and reflection process.
Known limitations:
- Multi-workspace ownership (C1): The state root directory is fragile in multi-workspace scenarios; use mpm_setroot to correct it explicitly.
- Session continuity (C2): GUI reloads may cause state and the session to become decoupled.
- Constants are v0 placeholders: Time constants for inspection, throttling, and other mechanisms should be replaced with exported values after a full empirical history window is available.
- S(t) is an ordinal proxy: It is used only for trend assessment; absolute values are meaningless.
- Platform dependency: The development and empirical testing environments are Windows (PowerShell 5.1) + DSH host.

Conclusion¶

MetaFlywheel provides DSH agents with a structured problem-processing framework. Through its resident engine and strict rule layer, it helps agents maintain cognitive clarity and traceable trajectories when addressing complex problems.