PAYATHON 2026

Azure Bot Service 返回消息未送达，如何接入 Teams 并选择 SDK？

AI 小顾

对于普通 message Activity，return Results.Ok(response) 只会把对象写入当前 HTTP 请求的响应体，不会自动将其作为机器人消息发送到 Web Chat 或 Teams。要回复用户，需要调用 SDK 的消息发送接口，或者自行调用 Bot Connector REST API。

如果用户后续发送的消息没有进入 /api/messages，还需要排查入站链路。现有代码表明缺少回复发送步骤，但不能证明所有现象都由此引起。

为什么生成了 response，聊天窗口仍收不到

原代码读取请求、创建 Activity，然后返回 JSON：

var response = await service.HandleMessageAsync(activity);
return Results.Ok(response);

response 是内存中的一个对象。普通渠道消息的处理涉及两条通信路径：

用户 → Web Chat / Teams → 渠道服务 → /api/messages
机器人代码 → 渠道发送接口 → Web Chat / Teams → 用户

发送回复需要实际调用渠道发送接口。入站 Activity 中的 serviceUrl 指向发送回复所用的服务地址，conversation.id 标识会话。只交换 From 与 Recipient，再通过 HTTP 返回对象，无法把消息发送到渠道。Microsoft 的消息收发文档说明了这一流程。

即使给原来的 Activity 补上会话字段，只使用 Results.Ok(response) 仍无法解决发送问题。这个结论适用于普通消息；invoke 等活动有不同的响应约定，不能一概套用。

如何使用 Microsoft 365 Agents SDK 回复

对于同时使用 Azure Bot Service、Web Chat 和 Teams 的需求，Microsoft 365 Agents SDK 是合适的选择。可以把 /api/messages 交给 SDK Adapter 处理，并在消息处理函数中调用 SendActivityAsync。

以下接入代码假设已经按照 SDK 项目模板完成依赖注入、身份验证和渠道连接配置。

端点改为：

using Microsoft.Agents.Builder;
using Microsoft.Agents.Hosting.AspNetCore;

app.MapPost("/api/messages", async (
    HttpRequest request,
    HttpResponse response,
    IAgentHttpAdapter adapter,
    IAgent agent,
    CancellationToken cancellationToken) =>
{
    await adapter.ProcessAsync(
        request, response, agent, cancellationToken);
});

Agent 中负责发送回复：

using Microsoft.Agents.Builder;
using Microsoft.Agents.Builder.App;
using Microsoft.Agents.Builder.State;
using Microsoft.Agents.Core.Models;

public class EchoAgent : AgentApplication
{
    public EchoAgent(AgentApplicationOptions options) : base(options)
    {
        OnActivity(ActivityTypes.Message, OnMessageAsync);
    }

    private async Task OnMessageAsync(
        ITurnContext turnContext,
        ITurnState turnState,
        CancellationToken cancellationToken)
    {
        await turnContext.SendActivityAsync(
            MessageFactory.Text("Hi! This is your bot."),
            cancellationToken);
    }
}

这两个片段分别替代原来手动读取请求的端点和回复发送逻辑。需要将 EchoAgent 注册为应用使用的 Agent，并移除原来映射到同一路径的处理器，避免重复注册。完整项目初始化可参考 Microsoft 365 Agents SDK 的 .NET 快速入门。

原来的 IMessageService 可以继续承载业务逻辑，例如生成回复文本，再由 turnContext.SendActivityAsync 负责消息投递。

Microsoft 365 Agents SDK 和 Teams SDK 怎么选

主要取决于需要覆盖哪些渠道，以及对 Teams 功能的需求：

  • 同时服务 Web Chat、Teams 等渠道：优先考虑 Microsoft 365 Agents SDK，适合复用跨渠道的消息处理逻辑。
  • 主要面向 Teams，并依赖会议、消息扩展、反应或其他 Teams 专属交互：优先评估 Teams SDK。

Microsoft 的 SDK 选型说明将两者分别定位为跨渠道运行时和以 Teams 为中心的应用框架。

不使用 Bot Framework SDK 时，仍可使用 Azure Bot Service，也不一定需要自行实现 Activity Protocol。原代码没有给出 Activity 的命名空间，无法仅凭类型名称确定它来自哪个包；迁移时应检查依赖，避免混用不同 SDK 的类型。

如果坚持使用自定义端点

也可以直接实现 REST 通信，但需要补齐渠道发送流程。例如，向当前会话发送消息的请求格式如下：

POST {serviceUrl}/v3/conversations/{conversationId}/activities
Authorization: Bearer {accessToken}
Content-Type: application/json

其中，serviceUrl 和 conversationId 来自经过验证的入站 Activity，访问令牌需要与机器人身份及部署环境匹配。请求必须包含正确的消息和会话信息。有关认证头和接口语义，参见 Bot Connector REST API 参考。

这条路线还需要自己处理入站身份验证、令牌获取、错误响应和渠道差异。对于当前问题，使用 SDK 通常更容易把消息链路接完整。

按什么顺序排查

  1. 确认用户消息是否进入端点。在 /api/messages 入口记录请求时间及 Activity 的 type、id、channelId、conversation.id。先记录，再判断是否为 message，避免把被过滤的活动误认为没有收到。
  2. 确认是否执行了发送操作。如果代码走到 Results.Ok(response) 就结束，说明回复还没有通过渠道发送接口投递。
  3. 检查发送调用的结果。记录 SendActivityAsync 的异常，或 REST 调用的状态码和错误体。单凭入站请求返回 200，无法证明出站消息发送成功。
  4. 分别验证 Web Chat 和 Teams。Web Chat 成功不能证明 Teams 配置正确。Teams 还需要检查渠道启用状态、应用中的机器人身份及安装范围。
  5. 端点完全没有收到请求时，检查接入配置。核对 Azure Bot 的 Messaging endpoint 是否为实际可访问的 HTTPS 地址并指向 /api/messages，同时检查代理、隧道和身份验证错误。

现有的“可以收到一条机器人消息”这一现象，不能单独证明上述自定义端点已经正确发送了回复。应结合入口日志与出站调用结果，确定消息停在哪一步。

备注：内容仅供参考。