限制一次任务的工作量

Agent 可能多次调用模型和工具。max-iterations 限制推理与工具调用的循环次数，execution-timeout 限制一次 Agent 执行的时长。

liteflow.agent.max-iterations=100
liteflow.agent.execution-timeout=10m

上面都是默认值。单个组件需要较小循环上限时，可以覆写：

@Override
protected int maxIterations() {
    return 20;
}

maxIterations() 默认返回 -1，使用全局配置；覆写时返回正整数。达到迭代边界不保证业务任务已完成，调用端仍应检查响应和所需产物。

几类超时分别控制什么

配置或扩展点	控制范围
execution-timeout	模型、工具和等待审批的执行阶段，默认 10 分钟
invocation-guard.acquire-timeout	获取会话锁的等待时间，默认 2 分钟
harness.shell.timeout	单次命令执行时限，默认 1 分钟
hitl.confirmation-timeout	一轮人工确认的等待时间，默认 2 分钟
modelExecutionConfig()、toolExecutionConfig()	模型或工具执行的超时与重试策略

一次 Agent 的执行时限不包含等待锁和首次构建运行时的时间，失败清理也可能额外耗时，因此不能把它直接当成 HTTP 接口的最大响应时长。

模型传给 execute 的 timeout 只能缩短服务端命令时限。审批还会受到 Agent 剩余执行时长限制，详见人工确认。

长对话不靠提高迭代次数解决

迭代次数约束一轮任务，模型上下文窗口约束输入容量。对话变长时由压缩机制处理，自建模型应提供真实上下文容量，见长对话与长期记忆。