看懂qwen-audio-agent架构Frontend Agent、Orchestration Runtime与Backend Agent的三层设计【免费下载链接】qwen-audio-agentA realtime voice runtime that keeps Agents talking, working, and present. Real-time Voice Runtime for AI Agents项目地址: https://gitcode.com/gh_mirrors/qw/qwen-audio-agentqwen-audio-agent 是一个让 AI Agent 持续说话、持续工作、持续在场的实时语音运行时Realtime Voice Runtime。它的核心是一套清晰的三层架构Frontend Agent前台 Agent负责自然对话Orchestration Runtime编排运行时负责调度任务与权限Backend Agent后台 Agent负责真正执行复杂工作。本文带你用一次语音请求的旅程快速看懂这三层各自做什么、如何协作。为什么语音 Agent 需要分层设计传统语音 LLM方案有个尴尬的体验你说一句它答一句中间不能插话一旦它去查资料、跑任务整场对话就卡住了。qwen-audio-agent 的设计目标就是打破这种等待能直接回答的问题立即用语音回应需要查资料、写代码、跑工具的问题交给后台 Agent 异步执行前台继续陪你聊天任务完成后结果自然地回到当前对话用语音告诉你已经好了。要做到这一点仅靠一个大模型是不够的——对话、调度、执行三种职责必须解耦。这正是三层架构的由来。第一层Frontend Agent —— 负责聊Frontend Agent前台 Agent是你直接听到和说话的那个助手。它由四部分组成实时语音模型 提示词 上下文 工具由 config/frontend-agent/PROMPT.md 定义其核心行为。它的职责边界很明确会做不会做理解输入、自然交流选择后台执行策略调用轻量聊天工具记忆、搜索、笔记等选择、创建或取消后端 Session调用spawn_thinking把复杂任务外包给后台直接操作工具、子 Agent根据任务结果组织回应处理后台私有协议可以把它理解成前台接待寒暄、答疑、确认权限都归它重活不自己扛。第二层Orchestration Runtime —— 负责管Orchestration Runtime编排运行时是系统的调度中枢也是三层里最容易被误解的一层它不包含任何协调大模型全部由代码完成调度与策略判断。它管理的核心对象是Task任务状态流转非常直观queued → running → completed │ └→ delegated → finalizing → completed └────────────→ cancelling → cancelled或 failed主要职责包括任务生命周期排队、执行、委派、完成、取消由task/模块统一管理权限策略后台 Agent 要执行敏感操作时生成权限请求前台转达给用户用户说可以或不允许即可结果投递在安全插入窗口把结果送回对话——比如你正在说话它就等你说完再播报事件与会话维护对话上下文、事件回放和跨连接的状态恢复。在源码中它的核心实现集中在 server/src/orchestration/task-operations.mjs统一的任务提交、查询、取消、权限与补充输入和 server/src/orchestration/session-task-coordinator.mjs每条前台连接的任务观察与投递协调。第三层Backend Agent —— 负责干Backend Agent 是真正办事的 Agent。它在自己的执行环境里工作用自己的模型、工具、MCP 服务器和 Skillsqwen-audio-agent 不干涉它的内部执行步骤。接入方式上它通过统一的BackendPort接口对接协议细节ACP、A2A 或自定义封装在各自的 Adapter 里。目前已支持 Qwen Code、OpenCode、OpenClaw、Codex 等主流 ACP Agent也支持远程 A2A Agent。对前台来说Backend Agent 只收到一条自包含的自然语言指令由spawn_thinking的 objective 传入不接收前台人格、长期记忆或聊天记录——这保证了各层的独立性。一次语音请求的完整旅程非阻塞是灵魂三层协作的精髓在于非阻塞non-blocking你说帮我查一下这个项目最近的安全漏洞顺便总结成一份报告前台 Agent 判断这不是能秒答的问题调用spawn_thinking提交任务编排运行时立即返回受理回执前台马上回答好的我已经开始处理了你可以继续跟我聊天任务进入 owner 队列交给配置的 Backend Agent 异步执行执行期间你可以随时追问进度怎么样了——前台通过get_agent_task_status直接查询完成后结果在安全窗口回流前台自然播报报告已经好了主要有三个发现……整个过程中对话从未中断。这就是Agent 始终在场的技术底座。Gateway 与客户端架构之外的重要配角读架构文档时还有两个概念容易和三层混淆Gateway网关它是框架的服务宿主负责把三层装配起来提供监听、认证、连接管理和协议入口。它不是第四层更像承载三层的机房。客户端Desktop / WebUI / TUI / 手机负责 I/O 与展示通过 Gateway Client Protocol 使用服务。客户端不等于 Frontend Agent——唤醒词、快捷键、窗口管理都归客户端管。这种逻辑三层 部署灵活的设计意味着你可以用桌面内置 Gateway也可以让手机连上独立部署的 Gateway核心组件职责始终不变。如何在源码中定位三层服务端源码按功能归属组织目录与三层逻辑一一对应逻辑层核心目录说明Frontend Agentserver/src/frontend/、server/src/voice/前台指令与工具装配前台会话运行时、音频轮次与播报Orchestration Runtimeserver/src/orchestration/、server/src/task/、server/src/voice/realtime-task-presentation.mjs任务操作、生命周期、权限策略、任务播报Backend Agent 接入server/src/backend/协议无关的 BackendPortadapters/实现 ACP、A2A完整的服务端代码地图见 server/src/README.md概念与部署关系的详细说明见 docs/architecture/overview.zh.md产品边界与不变量见 docs/architecture/deep-dive.zh.md。上图是三层架构在智能座舱示例中的落地框架核心前台 Agent Gateway固定不动客户端和后台 Agent 都可以按场景替换——这正是分层设计的最大红利。常见问题FAQQ三层必须部署成三个独立进程吗A不是。三层是逻辑组件不要求物理分离。Gateway 可以把它们装配进同一个进程后台 Agent 是自有进程还是外部服务都不改变核心职责划分。Q后台 Agent 内部的子 Agent、独立 Session 会增加新的架构层吗A不会。后台内部的子 Agent 和 Session 属于后台私有实现细节全部封装在 BackendPort Adapter 之后对前台和编排运行时完全透明。Q为什么编排运行时不用一个协调大模型A用代码做调度更确定、更快、更可控。编排运行时只执行调度和策略不参与推理所有聪明的部分分别留在前台对话和后台执行两个模型里。Q想深入了解从哪里开始看A先读 docs/architecture/overview.zh.md 建立全局观再按本文的目录表进入 server/src/orchestration/ 看任务如何流转最后看 server/src/backend/ 理解 Adapter 如何把协议细节藏起来。总结qwen-audio-agent 的三层架构可以一句话记住前台负责聊Frontend Agent运行时负责管Orchestration Runtime后台负责干Backend Agent。分层让对话永不阻塞体验始终在场边界让各层可独立替换——换语音模型、换后台 Agent、换客户端都不用动核心代码让调度完全确定性不依赖额外的协调模型。理解了这三层你就抓住了 qwen-audio-agent 架构的骨架后续无论是扩展 Provider、接入新后台还是定制场景都能快速找到正确的落点。【免费下载链接】qwen-audio-agentA realtime voice runtime that keeps Agents talking, working, and present. Real-time Voice Runtime for AI Agents项目地址: https://gitcode.com/gh_mirrors/qw/qwen-audio-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考