四种入口接入同一个 Agent：协议适配之后，谁负责会话和权限？ (2026)

当 Agent（能够调用工具、执行多步任务的 AI 系统）与 Workflow（由多个步骤组成的工作流）通过多路接入方式进入同一个执行内核之后，最值得检查的，是共享执行内核怎样管理会话，以及应用与框架怎样划分责任。微软在 2026 年 8 月 26 日发布 Microsoft Agent Framework for Python 的 channels（通道）能力，把 OpenAI Responses API、Telegram 聊天、A2A（Agent2Agent Protocol，用于独立 Agent 间协作）和 MCP（Model Context Protocol，用于连接工具与资源）四种接入方式接到同一个 hosting layer（托管层）上。channels 把协议接入的重复工作收进框架，同时让应用继续处理身份映射、授权、存储等宿主策略；并发和故障恢复仍需结合具体宿主设计。1 2

对技术团队来说，现在值得投入的是协议适配层；现在值得验证的是同一项任务在不同接入方式下能否保持正确的会话、权限与结果。把“能接上”直接当成“能上线”，会跳过真正昂贵的工程工作。

先看结论：接入已公开，统一运行仍然依赖应用

方向	这次变化带来的能力	应用仍需承担的工作	成熟度	行动窗口
四种 channels	用不同适配包把 OpenAI Responses API、Telegram 聊天、A2A、MCP 接到 Agent 或 Workflow 1	路由、认证、授权、存储、后台处理与部署	已公开、仍属预发布 3	现在可以做边界适配和小规模试验
共享目标与状态模型	用 `AgentState`（Agent 状态对象） / `WorkflowState`（Workflow 状态对象）解析同一个 Agent 或 Workflow 执行目标 1	决定目标缓存、会话存储与工作流检查点的生命周期	已公开	新项目从独立状态接口开始设计
跨入口续接会话	把不同入口身份映射到同一个 canonical session ID（规范会话标识）1	身份关联、租户隔离、并发控制与撤销策略	快速扩张	先在低风险场景验证串线和重复提交
MCP 与 A2A 组合	一个系统同时连接工具，也能委派给远程 Agent 4 5	分开设计工具权限、Agent 委派权限和任务验收	快速扩张	适合建立协议网关与审计字段
从协议接入外推跨组织长期自治	协议层支持远程 Agent 发现能力、接收任务、返回状态与 artifact（结果工件）4	身份、责任、幂等（重复请求只产生一次对外部系统的改变）、恢复、业务断言（必须满足的业务条件）和人工接管	容易被高估	暂缓高风险写入、扣款和无人审批承诺

表中的“已公开”描述接口、文档或示例已经可以获得；“快速扩张”表示协议、适配器和宿主方案正在增加组合；“容易被高估”表示协议层的通信能力容易被外推成业务层的长期自治。三项标签属于本文的工程判断。

变更发生在协议适配层

微软这次让开发者用一份 Agent 对接多种入口。官方把 Python 包拆成一个共享 hosting 核心和四个通道集成：agent-framework-hosting 提供 Agent、Workflow（由多个步骤组成的工作流）和会话状态辅助能力，另外四个包分别处理 Responses、Telegram、A2A 和 MCP 的协议转换。应用继续使用自己的 Web 框架或原生 SDK，负责路由、认证、授权、存储、后台任务和部署。1

这个分层有一个实际含义：协议适配器可以更换，内部的 Agent 或 Workflow 仍然保留自己的执行模型。微软的 hosting 文档把 hosting library 描述为“协议适配器”：适配器从依赖注入容器取得 Agent，加入协议相关的中间件，把外部请求转换成内部调用，再把结果转换回协议格式。Agent 实现因此可以保持独立于具体协议。2

工程团队可以把这个结构理解成三层：入口层负责接收请求，适配层负责翻译格式，执行层负责运行 Agent 或 Workflow。路由、身份、权限和存储的具体策略，仍由应用决定。框架提供了连接点，应用需要补齐运行规则。

OpenAI Responses、Telegram、A2A 与 MCP 通过适配器进入共享托管层，再连接到 Agent 和 Workflow — *微软官方 channels 架构图把应用自有身份解析器、共享托管层和 Agent / Workflow 的连接关系画在同一张图里。1*

为什么说这是一条运行时趋势

8 月 22 日，MCP 官方路线图把接下来几个月的重点列成五个方向，其中三项直接触及多入口系统：面向长任务的消息原语、统一并加固 HTTP 传输，以及 Agent 身份与企业级安全。路线图还写明，当前 MCP 授权主要围绕“有人在浏览器里批准访问”展开，而越来越多调用方会是带有自身身份的云端 Agent、代表缺席用户行动的 Agent，或需要更窄权限的子 Agent。6

8 月 27 日，微软发布 Agent Harness 生产化文章，把同一个 Agent 拆成共享 Agent factory（工厂）和 console（命令行）、hosted（托管）、evals（评测）三个轻量宿主。官方示例在 hosted 宿主中关闭文件访问与 shell，把本地检查和托管评测分成不同运行路径；Agent 定义保持一致，宿主周围的权限、观测和部署策略随环境改变。7

把 8 月 22 日的路线图、8 月 26 日的 channels 和 8 月 27 日的宿主实践放在一起，可以看到同一条工程主线：Agent 框架正在把“同一个执行目标如何进入不同环境”当成独立的工程问题。协议层开始讨论 Agent 身份和长任务，框架层开始提供多入口适配，宿主层则按环境重新划定权限和观测边界。这个方向比新增一个聊天入口更值得关注。1 6 7

这里的“执行目标”指通道请求最终要调用的 Agent 或 Workflow 对象。AgentState 把 Agent 执行目标与会话存储放在一起；WorkflowState 则从实例、工厂或构建器中取得 Workflow 执行目标。两者为不同通道的处理器提供一致的目标解析方式。目标可以在请求之间缓存，也可以在每次请求时重新创建。1

跨入口续接的关键在于身份解析器。微软的示例把一个经过认证的用户和入口身份映射到会话 ID：Responses 客户端与 Telegram 用户得到同一个规范会话标识时，两个入口就能加载同一个 AgentSession（保存会话状态的对象）；两个入口得到不同标识时，两个历史会话就会分开。这个映射函数由应用实现，授权和并发控制也由应用实现。1

团队把入口 ID 直接当作用户身份时，系统就会把“某个入口里的标识”误当成“已经认证的主体”。当应用再用这串标识查询共享会话时，入口标识相同、可猜或被伪造的请求就可能跨越租户和用户边界；认证后的主体、租户和会话授权应先绑定，再决定能加载哪些历史。

共享一个 Agent 与共享一段安全会话，属于两层设计。应用还要回答四个问题： 2. 两个入口能否同时修改同一份会话状态？ 3. 一个入口撤销授权后，另一个入口的续接标识是否立即失效？ 4. Workflow 的检查点应该按用户、租户、任务，还是按入口分别保存？

这些问题必须由应用给出具体答案。团队如果把入口 ID 直接当作用户身份，应用就可能把“同一个人从不同入口继续对话”错误地实现成“同一串字符串可以访问全部历史”。

MCP 和 A2A 建立的是两种不同的调用关系

Model Context Protocol（MCP）解决 Agent 与工具、资源和工作流的连接。MCP 官方文档把它定义为连接 AI 应用与外部系统的开放标准，外部系统可以提供数据源、工具和专用工作流。MCP 的典型方向是：一个 AI 应用调用一个服务器暴露的工具，读取资源，或者取得可复用的提示。5

Agent2Agent Protocol（A2A）解决独立 Agent 之间的协作。A2A 官方文档把 Agent Card（Agent 卡片）定义为能力、接口、协议版本和安全要求的描述；客户端据此选择远程 Agent，再通过任务 ID 跟踪进度、追加信息和结果 artifact。远程 Agent 可以保留自己的内部记忆、工具和实现细节，调用方只依赖对外的工作契约。4

这两个协议可以出现在同一条链路里。例如，在一条设想的订单流程中，主 Agent 通过 MCP 读取订单系统，再通过 A2A 委派给负责退款审核的远程 Agent。主 Agent 看到的是两个不同的关系——前者像调用一个工具，后者像把一项有生命周期的工作交给另一个执行主体。A2A 官方文档也把 MCP 与 A2A 分成 Agent-to-tool 和 Agent-to-agent 两层。4

微软的 MCP 示例把边界写得更细：mcp_to_run(...) 把经过验证的 MCP 参数转换成 Agent Framework 输入，mcp_from_run(...) 把执行结果转换成 MCP 内容块；一个工具调用仍然返回一个最终的 CallToolResult，进度通知和实验性的延迟任务由应用负责。示例还明确提醒：该示例的本地端点采用无认证配置，MCP 传输层的 session ID 只用于传输会话，用户授权仍需由应用完成。8

A2A 的服务器示例也把任务存储、执行器和身份绑定放在应用代码里。微软提供的示例使用原生 A2A SDK 的 AgentExecutor、事件队列和任务存储，再用 AgentA2AAdapter 转换 Agent Framework 的输入输出；示例中的 a2a:{tenant}:{context_id} 只是演示用的会话键，代码注释要求外层服务器在多用户场景中完成认证与授权。9

这正是多通道架构的工程边界：适配器负责让消息进入正确的执行模型，应用负责决定谁能调用、状态存在哪里、任务失败后怎样处理。

接入状态与业务可靠性是两套验收

channels 已经具备公开的试用和集成材料：官方包、文档和可运行示例都已公开。Python 自托管文档把相关包标为 prerelease，PyPI 也将 agent-framework-hosting 标为 Alpha，当前版本为 1.0.0a260730。这组证据支持的范围是接口集成和试验；跨入口会话的安全设计，以及一个 Workflow 在网络中断、重复请求或部分结果返回时的业务正确性，属于另一层验收。1 2 3 10

团队在评估时需要把两个坐标分开：

协议成熟度。 入口是否有公开规范，适配器是否能完成格式转换，版本和扩展是否有明确边界。
任务可靠性。 任务是否只产生一次副作用，失败后能否恢复，结果是否满足业务断言，授权变化能否阻断后续动作。

前一项适合通过文档、SDK 和互操作测试判断。后一项必须落到自己的任务集。一个“退款审核”任务完成 A2A 消息交换时，协议层的委派请求已经完成；业务层还要检查退款金额是否正确、订单状态是否更新、审批证据是否留存，以及重试是否造成二次扣款。

微软官方文档也把长时间运行且需要可靠恢复的工作负载单列为 Durable Extension（持久化扩展）的适用方向，并把 Agent、工具和会话存储作为应用基础设施的一部分来配置。这个安排说明，hosting layer 负责把协议接入执行模型，持久化和可靠运行仍然需要额外的宿主设计。2

技术团队现在应该怎样试

先隔离协议适配器

团队可以为内部任务定义自己的输入、状态和结果对象，再在边界层分别转换成 Responses、A2A 或 MCP 所需的格式。内部工作流可以保持与聊天入口解耦，协议升级也只在边界层处理。

适配层至少应该记录协议版本、入口类型、调用方身份、租户、任务 ID、会话 ID、状态变化、输入输出摘要和最终 artifact。记录这些字段的目的，是让团队能够回答“谁在什么入口发起了哪项任务，以及任务最后留下了什么副作用”。

为每个入口划出身份命名空间

应用应该分别保存入口身份与规范用户身份的绑定关系，再由授权策略决定哪些绑定可以共用会话。团队需要把“可以跨入口继续会话”作为显式权限，入口字符串只承担索引作用。

共享同一个规范会话 ID 的并发访问需要并发策略。最简单的策略是同一会话串行执行；需要并行时，应用应当保存版本号、分支关系或冲突状态。Workflow 的 checkpoint（工作流检查点）则要绑定任务和租户边界：用户从另一个入口续接某项任务时，系统只能加载该用户、租户和任务对应的中间状态。

用五条失败路径验收

重复提交： 网络重试再次送达同一个任务时，写库、发信或扣款等副作用（对外部系统的改变）是否只发生一次。
中途失联： 远程 Agent 在执行一半后断开时，调用方是否能拿到最后一个已持久化、带版本号的状态，并把任务交给人工或补偿流程。
跨入口串线： 同一用户从 Telegram 进入时，系统是否只加载获授权的 Responses 历史；入口 ID 猜测是否触发越权读取。
部分结果： A2A 返回部分 artifact 或 MCP 返回错误时，主流程是否暂停、降级或转人工。
授权变化： 用户或租户权限在长任务执行期间收回时，后续工具调用和写入动作能否停止。

这五条路径比“不同协议之间能否完成一次消息交换”更接近上线判断。消息连通性解决了接入门槛，副作用控制和结果验收决定了业务风险。

未来 6–12 个月：适配器可能成为基础配置，控制面更值得比较

在本周材料覆盖的范围内，我的判断是，channels 这类协议适配层可能逐渐成为 Agent 框架的基础配置。这个判断来自三条相互独立、却指向同一宿主问题的证据：MCP 路线图把身份与长任务列为优先方向，Microsoft channels 提供多入口适配，Agent Harness 按环境重新划定权限与观测边界。这是一项值得观察的工程判断，团队仍应以自己的任务集确认。

对本文这个多入口场景，差异会落在状态与控制面。协议适配器解决“消息怎样进入执行层”；平台还要把规范会话身份、租户隔离、任务检查点、授权撤销、重试幂等（重复请求只产生一次副作用）、协议版本和观测记录放进同一套可验证的运行机制。协议数量增加后，平台需要治理的边界也会随之扩大。

这项判断仍然需要各团队用自己的任务集验证。对于低风险的检索、摘要和人工确认流程，团队现在可以接入多个 channels，观察协议转换与会话续接的真实成本。对于写库、发信、付款和修改生产配置，团队应先完成身份、授权、幂等、恢复和人工接管测试，再决定是否放开自动执行。