MissionFlows 與工作流程：自適應智能體執行如何取代靜態 DAG

Traditional workflow engines assume the execution path is known before the first step runs. Airflow DAGs, Temporal workflows, and Prefect pipelines all encode a graph of tasks with edges that represent control flow. When step three fails, you retry step three. When a condition evaluates false, you follow the predefined else branch.

Agentic systems break that assumption. Instead of defining the path, you define a mission and let an LLM-backed agent decide the steps at runtime. If SFTP fails, the agent tries an API. If credentials expire, it refreshes them. If the primary endpoint is down, it selects a fallback. The mission stays constant. The execution path emerges.

This shift creates new infrastructure problems. How do you observe a workflow that writes itself? How do you version control execution logic that lives in prompts instead of YAML? How do you recover from failure when there is no predefined retry branch?

What a Workflow Gives You

A workflow engine provides three guarantees:

1. Deterministic execution graph. You can visualize the DAG before it runs. Every node and edge is explicit.
2. Checkpoint boundaries. State is saved at task boundaries. Retry logic is declarative.
3. Audit trail. You know which tasks ran, in what order, and what they returned.

These guarantees make workflows debuggable. When a pipeline fails, you open the UI, see the red node, inspect the logs, and fix the task. The failure surface is bounded by the DAG structure.

What a MissionFlow Trades Away

A MissionFlow replaces the DAG with a goal and a set of guardrails. The agent receives a mission like "ensure this file reaches the destination securely before 17:00 and verify processing." It does not receive a list of steps.

The agent decides:

• Which protocol to use (SFTP, API, S3 presigned URL).
• How to handle credential expiration (refresh token, request new credentials, escalate to human).
• What constitutes success (file transferred, checksum verified, downstream system acknowledged).

The execution path is not predetermined. It is discovered through reasoning steps that depend on runtime context: API availability, credential validity, network conditions, and the agent's interpretation of the mission.

This introduces three new failure modes:

1. Reasoning drift. The agent misinterprets the mission and pursues a path that satisfies the literal goal but violates implicit constraints.
2. Unbounded exploration. Without explicit guardrails, the agent may try dozens of approaches, consuming tokens and time without converging.
3. Non-reproducible failure. The same mission with the same inputs may produce different execution paths, making debugging harder.

Observability Without a DAG

Traditional workflow UIs render a graph with nodes colored green or red. You see the execution path at a glance. MissionFlows need a different observability model.

Trace Logs of Reasoning Steps

Instead of task boundaries, you log reasoning steps:

{
  "mission_id": "file-transfer-20261013-1847",
  "step": 3,
  "reasoning": "SFTP connection failed with timeout. Checking for alternative endpoints.",
  "action": "query_service_registry",
  "result": "found API endpoint with valid credentials",
  "timestamp": "2026-10-13T18:47:23Z"
}

Each step captures:

• What the agent observed (SFTP timeout).
• What it decided (query service registry).
• What it did (called the registry API).
• What it learned (found an alternative endpoint).

This log structure replaces the DAG visualization. You reconstruct the execution path by reading the trace.

State Checkpoints Mid-Reasoning

Workflows checkpoint at task boundaries. MissionFlows need to checkpoint mid-reasoning because the agent may decide to pause, request human input, or wait for an external condition.

A checkpoint includes:

• The mission definition.
• The reasoning trace so far.
• The current context (credentials, endpoints, partial results).
• The agent's next planned action.

If the agent crashes or times out, you can resume from the last checkpoint. The agent re-reads the trace, re-evaluates the context, and continues.

Guardrails as Executable Constraints

Without explicit guardrails, an agent may pursue any path that satisfies the mission. Guardrails are constraints that limit the search space:

• Allowed tools. The agent can call sftp_transfer, api_upload, and s3_presigned_url, but not ssh_exec.
• Credential scope. The agent can refresh tokens but cannot request new API keys.
• Time budget. The agent must complete the mission within 30 minutes or escalate.
• Approval gates. If the agent wants to use a fallback endpoint not in the approved list, it must request human approval.

Guardrails are enforced by the orchestration layer, not the LLM. The agent proposes actions. The orchestrator checks them against the guardrails before execution.

Failure Recovery Without Predefined Retry Logic

In a workflow, retry logic is declarative:

task: transfer_file
  retry:
    max_attempts: 3
    backoff: exponential

In a MissionFlow, the agent decides whether to retry, try a different approach, or escalate. The orchestrator does not know in advance what "retry" means because the execution path is not fixed.

Agent-Driven Retry

The agent observes a failure, reasons about the cause, and decides the next action:

• If the failure is transient (network timeout), retry the same action.
• If the failure is permanent (invalid credentials), try a different approach.
• If the failure is ambiguous (500 error), inspect logs or query a monitoring system.

The orchestrator logs the agent's reasoning and enforces guardrails, but it does not dictate the recovery strategy.

Escalation Boundaries

When the agent cannot make progress, it escalates. Escalation is a guardrail:

• If the agent has tried three different approaches and all failed, escalate to a human operator.
• If the agent needs to use a tool outside the approved list, request approval.
• If the mission deadline is approaching and the agent is not confident it can complete, escalate early.

Escalation boundaries prevent unbounded exploration. They turn a potentially infinite search into a bounded one with a human in the loop.

Versioning Mission Definitions

Workflows are versioned as code. You commit a YAML file to Git, and the workflow engine executes that version.

MissionFlows are versioned as prompts and guardrails. The mission definition includes:

• The goal statement (natural language).
• The guardrails (allowed tools, credential scope, time budget, approval gates).
• The context schema (what information the agent receives at runtime).

Versioning a mission means versioning the prompt template and the guardrail configuration. Changes to the prompt can change the execution path without changing the code.

Prompt Drift

A workflow DAG is deterministic. The same inputs produce the same execution path. A MissionFlow is not. The same mission with the same inputs may produce different execution paths if the LLM's behavior changes (model update, temperature setting, token budget).

To mitigate prompt drift:

• Pin the LLM version and parameters.
• Log the full prompt and response for every reasoning step.
• Run regression tests that validate the execution path for known scenarios.

Regression tests for MissionFlows are harder than for workflows because the execution path is not fixed. You test outcomes, not paths.

Architecture: Orchestrator, Agent, and Tool Layer

A MissionFlow system has three layers:

The orchestrator is stateful. It maintains the mission state, the reasoning trace, and the checkpoint history. It does not reason. It enforces constraints and logs decisions.

The agent is stateless. It receives the mission, the current context, and the reasoning trace. It returns the next action. The orchestrator decides whether to execute that action based on guardrails.

The tool layer is also stateless. Each tool is a function that takes parameters and returns a result. Tools do not know about missions or agents. They are reusable primitives.

Example: File Transfer Mission

# Mission definition
mission = {
    "goal": "Transfer file to destination securely before 17:00 and verify processing",
    "guardrails": {
        "allowed_tools": ["sftp_transfer", "api_upload", "s3_presigned_url"],
        "credential_scope": "refresh_only",
        "time_budget_minutes": 30,
        "approval_required_for": ["unlisted_endpoints"]
    },
    "context": {
        "file_path": "/data/export_20261013.csv",
        "destination": "partner-system",
        "deadline": "2026-10-13T17:00:00Z"
    }
}

# Orchestrator loop
while not mission_complete(mission):
    reasoning_step = agent.reason(mission, context, trace)
    if violates_guardrails(reasoning_step, mission.guardrails):
        trace.append({"step": "rejected", "reason": "guardrail violation"})
        continue
    result = execute_tool(reasoning_step.action, reasoning_step.params)
    trace.append({"step": reasoning_step.step, "action": reasoning_step.action, "result": result})
    context.update(result)
    checkpoint(mission, trace, context)

The orchestrator does not know in advance whether the agent will use SFTP or an API. It enforces the guardrails and logs the trace. The agent decides the path.

Trade-Offs: When to Use MissionFlows

MissionFlows are not a replacement for workflows. They are a different abstraction for a different class of problem. If your pipeline is stable and the failure modes are well understood, a workflow is simpler and more debuggable. If your pipeline needs to adapt to changing conditions and the failure modes are unpredictable, a MissionFlow may be worth the complexity.

Technical Verdict

Use MissionFlows when the execution path cannot be predetermined and the agent needs to adapt based on runtime conditions. This applies to integration scenarios with multiple fallback options, incident response where the root cause is unknown, and data pipelines that span heterogeneous systems with varying availability.

Avoid MissionFlows when the execution path is stable and the failure modes are well understood. The observability and debugging complexity is higher. You lose the deterministic execution graph that makes workflows easy to reason about. If your pipeline runs the same way every time, a traditional workflow engine is simpler and more reliable.

Expect to invest in observability infrastructure. You need trace logs of reasoning steps, checkpoint management, guardrail enforcement, and escalation boundaries. The tooling for MissionFlows is less mature than for workflows. You will build custom instrumentation.

Start with guardrails. Without explicit constraints, agents explore unbounded search spaces. Define allowed tools, credential scope, time budgets, and approval gates before you deploy a MissionFlow to production.

Source Links

• From Workflows to MissionFlows (Dev.to)