题主在概念上确实混淆的不行，但是确实async/await这个东西继承了我软从VB6开始的光荣传统（易学难精）。工作中确实没有碰到几个真正搞的明白的同事（轮子哥，I大这种论外）。

首先，题主需要搞明白一个概念，就是async不是函数声明的一部分。从调用者的角度来看，不存在async这个东西。

async是一个专门给编译器的提示，意思是该函数的实现可能会出现await。async并不是表明这个方法是异步方法，而是标明这个方法里有异步调用。至于为啥要有这个提示，而不是编译器发现函数实现里有await的时候就自动加上async标志，这是定义语言标准时的选择，C#（这个feature）的作者也许认为这样写让作者更明确的意识到自己在实现一个包含异步调用的函数。（我瞎猜的）

下面举两个例子

Task<int> DelayAndCalculate1(int a, int b)

{

    return Task.Delay(1000).ContinueWith(t => a + b);

}

async Task<int> DelayAndCalculate2(int a, int b)

{

    await Task.Delay(1000);

    return a + b;

}

这两个函数（不算函数名的不同），在函数声明上是完全没有区别的。只是其中一个在实现中使用了await，所以C#语法要求我们必须在标示async。

从调用者的角度来看，这两个函数完全一致（而且行为也一致），都可以使用await关键词unwrap Task类型的返回值（其实这里有一个叫做GetAwaiter的约定，这里不展开说）。

另一个佐证就是interface的定义中不能写async，因为如上所述，async不是函数声明，而其实编译函数实现的提示。

<img src="https://pic2.zhimg.com/50/v2-9a4354b91340bde2391e5b6406c05eb2_hd.jpg" data-rawwidth="680" data-rawheight="221" class="origin_image zh-lightbox-thumb" width="680" data-original="https://pic2.zhimg.com/v2-9a4354b91340bde2391e5b6406c05eb2_r.jpg">

最后回到题主的问题为啥有了async还要写await，其实真正重要的是await（和其他异步的实现，如例子中的DelayAndCalculate1），有没有async反而确实不重要。

那么可不可以如题主所说的设计一个语法糖，不需要写Task<int>而写async int呢？答案是当然可以这么设计，但这就只是单纯的让编译器自动把async int翻译成Task<int>而已，C#的作者单纯没有这么设计而已（因为这会使得函数的返回值和声明时不同，我个人也觉得这会导致更大的confusion）。因为一个返回Task<int>的函数，不只可以用来await，还有很多别的玩法，语言应该给予开发人员解开和不解开的自由。最简单的例子：

async Task<int> ComplexWorkFlow()

{

    Task<int> task1 = DoTask1();

    Task<int> task2 = DoTask2();

    Task<int> task3 = DoTask3UseResultOfTask1(await task1);

    Task<int> task4 = DoTask4UseResultOfTask2(await task2);

    return await DoTask5(await task3, await task4);

}

我用短短几行实现了一个相对复杂的工作流，task直接的dependency很明确的表达在代码里，并且task1和task2可以并行执行，task3和task4可以并行执行（事实上更好的写法可以让task1->task3完全并行与task2->task4）。核心思路就是只有当某个task的执行结果需要被使用的时候才解开这个task的值（等它执行完毕）。