/**
 * DAG 执行引擎 — 核心调度器
 */
import type { DAGNode, LLMConnector, LLMConfig, WorkflowResult } from '../types.js';
import type { DAG } from './dag.js';
export interface ExecutorOptions {
    connector: LLMConnector;
    agentsDir: string;
    llmConfig: LLMConfig;
    concurrency: number;
    inputs: Map<string, string>;
    /** 每步完成的回调 */
    onStepComplete?: (node: DAGNode) => void;
    onStepStart?: (node: DAGNode) => void;
    /** 一批并行步骤开始前的回调 */
    onBatchStart?: (nodes: DAGNode[]) => void;
    /** 一批并行步骤全部完成后的回调（按顺序） */
    onBatchComplete?: (nodes: DAGNode[]) => void;
    /** resume 模式: 跳过这些步骤（使用 context 中已有的输出） */
    skipStepIds?: Set<string>;
    /**
     * 对话式返工：对指定步骤注入"用户修改意见 + 上一版产出"，让该专家在原稿基础上
     * 按意见修改重做（而非从零重写）。配合 --resume --from <stepId> 使用。
     */
    feedback?: {
        stepId: string;
        text: string;
        previousOutput?: string;
    };
}
export declare function executeDAG(dag: DAG, options: ExecutorOptions): Promise<WorkflowResult>;
/**
 * 按输入规模动态抬高"首次尝试"的超时：大输入（系统提示 + 渲染后的任务，含上游注入的
 * 长文本）往往意味着更长的处理/生成时间。与其让它第一次必超时、再靠 retry 把 timeout
 * x1.5 慢慢爬上来，不如一开始就给足，减少首跑失败——这对粘贴大段 PRD/文档的激活场景尤其重要。
 *
 * - 仅在用户未显式设置 timeout 时生效（显式值，含 0=不限时，原样尊重）。
 * - 在 provider 默认值之上叠加，单独设上限；retry 仍可在此基础上继续 x1.5。
 * @param defaultTimeout provider 默认超时 ms（API 120s / CLI·ollama 600s），0=不限时
 * @param inputChars 系统提示 + 用户消息的字符数
 */
export declare function dynamicInitialTimeout(defaultTimeout: number, inputChars: number): number;
/**
 * 步骤因超时/连接中断耗尽重试后，给用户可操作的修复指引（按 provider 定制）。
 * 把"streaming terminated / timeout"这种死胡同变成"下一步该怎么做"，是激活漏斗里
 * 用户决定去留的关键一刻。
 */
export declare function timeoutFailureHint(provider: string): string;
/**
 * 构造"对话式返工"追加块：把用户意见（必有）和上一版产出（可选）拼到任务后面，
 * 指示专家在原稿基础上按意见修改、只动该动的地方、输出完整结果。
 */
export declare function buildFeedbackBlock(feedback: string, previousOutput?: string): string;