MissionFlow
一种以目标（mission）加护栏代替静态 DAG 的 Agent 执行范式，由 LLM 驱动的 Agent 在运行时动态选择执行动作与路径，强调动态涌现而非预定义步骤。
时间轴 (近 90 天)
MissionFlow 用「目标 + 护栏」替代 DAG，Agent 在运行时自行决定协议、凭证处理和成功标准，执行路径动态涌现而非预先定义。
MissionFlow 模式引入三种新的失败模式：推理漂移、无界探索、不可复现的失败。
MissionFlow 的可观测性不记录任务边界，而是记录推理步骤，每步捕获观察、决策、动作、结论四类信息，以替代 DAG 可视化并通过 trace 重建执行路径。
传统分布式追踪（如 OpenTelemetry 的 span/trace 模型）以调用跨度为单位，假设操作有明确的开始、结束和父子关系，无法直接映射 MissionFlow 的推理轨迹；实践中通常采用 ReAct 风格的步骤序列作为记录单元。
MissionFlow 的状态检查点在推理中途进行，包含 mission 定义、推理轨迹、当前上下文和下一步计划，用于 Agent 崩溃或超时后恢复。
传统工作流中重试逻辑是声明式的（如 max_attempts: 3、backoff: exponential），而 MissionFlow 中 Agent 自行根据失败原因判断重试、换方法或升级。
MissionFlow 的回归测试应断言结果不变量而非执行路径，因为同一 mission 有多条合法路径；路径级别的软断言可作为护栏而非正确性判据。
MissionFlow 系统分为三层：有状态的编排器（接收 mission、执行护栏、记录推理、管理检查点、处理升级）、无状态的 Agent（推理并提议工具调用）、无状态的工具层（执行动作并返回结果）。
缓解提示漂移需要固定 LLM 版本和参数、记录每一步完整 prompt 和响应、运行回归测试；但模型供应商的静默更新和工具返回格式的变化同样会导致漂移，因此 prompt、模型版本、参数和工具 schema 应作为一组不可变配置一起版本化。
当 Agent 尝试三种方法均失败、需要白名单外工具，或截止时间临近且信心不足时，应升级给人工处理；升级边界将潜在无限搜索变为有人参与的有限搜索。
全部知识事实 (10)
MissionFlow 用「目标 + 护栏」替代 DAG，Agent 在运行时自行决定协议、凭证处理和成功标准，执行路径动态涌现而非预先定义。
50%待验证MissionFlow 模式引入三种新的失败模式：推理漂移、无界探索、不可复现的失败。
50%待验证MissionFlow 的可观测性不记录任务边界，而是记录推理步骤，每步捕获观察、决策、动作、结论四类信息，以替代 DAG 可视化并通过 trace 重建执行路径。
50%待验证传统分布式追踪（如 OpenTelemetry 的 span/trace 模型）以调用跨度为单位，假设操作有明确的开始、结束和父子关系，无法直接映射 MissionFlow 的推理轨迹；实践中通常采用 ReAct 风格的步骤序列作为记录单元。
50%待验证MissionFlow 的状态检查点在推理中途进行，包含 mission 定义、推理轨迹、当前上下文和下一步计划，用于 Agent 崩溃或超时后恢复。
50%待验证传统工作流中重试逻辑是声明式的（如 max_attempts: 3、backoff: exponential），而 MissionFlow 中 Agent 自行根据失败原因判断重试、换方法或升级。
50%待验证MissionFlow 的回归测试应断言结果不变量而非执行路径，因为同一 mission 有多条合法路径；路径级别的软断言可作为护栏而非正确性判据。
50%待验证MissionFlow 系统分为三层：有状态的编排器（接收 mission、执行护栏、记录推理、管理检查点、处理升级）、无状态的 Agent（推理并提议工具调用）、无状态的工具层（执行动作并返回结果）。
50%待验证缓解提示漂移需要固定 LLM 版本和参数、记录每一步完整 prompt 和响应、运行回归测试；但模型供应商的静默更新和工具返回格式的变化同样会导致漂移，因此 prompt、模型版本、参数和工具 schema 应作为一组不可变配置一起版本化。
50%待验证当 Agent 尝试三种方法均失败、需要白名单外工具，或截止时间临近且信心不足时，应升级给人工处理；升级边界将潜在无限搜索变为有人参与的有限搜索。
50%