从架构视角拆解：阿里两款千问办公产品的底层分野

2026年，阿里启动企业级Agent产线大整合，以QoderWork为底座重构出独立的千问办公桌面端。这一调整在品牌层面完成了向千问大旗的收拢，却也带来了一个技术层面的困惑：独立发布的千问办公与通义千问App里的办公模式，既然都冠以千问之名，且都在解决办公场景下的自主规划与工具调用，它们的底层Agent架构是否已经在整合中趋同？通过对本地安装的两个应用进行静态反编译与运行时追踪，我们发现了令人意外的答案：两者在上层业务能力上汇合，底层Agent loop却依然彻底分叉。

产线整合背景与产品演进脉络

阿里在Agent探索初期经历了典型的内部赛马阶段。2025年下半年至2026年初，多条业务线并行下注：开发者与桌面生产力线由智能编程平台Qoder衍生出桌面级通用智能体QoderWork，主打Electron宿主、本地Worker隔离与MCP协议扩展；协同办公线推出内置于钉钉生态的悟空；云端执行线侧重多模态流程复用；通义千问客户端则基于qwen-agent框架内置了具备搜索、代码执行、文件分析能力的办公模式。多线分流在跑通场景验证的同时，也导致了严重的同质化竞争。2026年7月，阿里正式启动三大企业级智能体的全面整合，以QoderWork为技术与架构底座，重组升级为面向未来的独立桌面端千问办公。

技术架构层面的核心差异

从技术架构来看，两款产品虽然都遵循标准的Agent执行范式——大模型接收指令后返回tool_use，宿主调度执行并回填上下文进入下一轮迭代——但这种概念层的一致只是通用抽象。在具体的代码实现、进程边界与协议设计上，两者完全独立。千问App的办公模式运行在Chromium框架之上，Agent入口位于agent_host/bundle.cjs，采用内嵌的Agent循环与ApprovalReview机制。而独立千问办公基于Electron 37.10.3框架，完整继承了QoderWork的Worker Harness体系，通过@ali/qoder-agent-sdk-next建立任务通道，由独立Worker进程执行AgentLoop、schedule_tool_calls与上下文压缩流水线。宿主框架、Agent入口、进程模型三维度均存在本质差异。

代码实现与执行轨迹的实证分析

进一步的代码逆向分析揭示了更深层的差异。千问App磁盘版本4.1.0.175的核心是独立的agent_host.app和libagent_runtime.dylib动态库，bundle.cjs内包含基于query2()的主循环逻辑，实现了decideNext、executeToolUseBatchesStreaming、ToolLoopTracker、分级压缩与token预算控制等完整机制，但整个bundle内不存在任何Qoder SDK或Worker痕迹。千问办公版本0.1.8则显式引入@ali/qoder-agent-sdk-next 1.0.20，运行时由Electron主进程通过UnifiedChatExecutor建立任务通道，由独立Worker进程加载qoder-worker-runtime.obf.mjs执行压缩流水线，最终通过SessionEventProcessor异步持久化至SQLite数据库。在相同任务的实际运行中，千问App以扁平JSONL文件逐行追加事件，而千问办公通过本地SQLite精确落盘事件分片，数据结构复杂度差异显著。

代码血缘与架构分叉的启示

从代码血缘来看，千问办公与QoderWork共享62个直接依赖包，QoderWork的37份SQL migration脚本在千问办公安装包内完全一致，UnifiedChatExecutor、SessionEventProcessor等核心控制器代码逐字节同源。这充分证明千问办公是产线整合后直接继承并改版自QoderWork的产品，延续了Qoder的Worker Harness体系；而在整合过程中，通义千问App内部原有的qwen-agent架构并没有与Qoder体系合并。虽然不排除两者未来在集团统一的模型网关、用户账号体系或遥测监控层逐步共享基础设施，但就当前版本而言，实际情况可以清晰概括为：组织与业务能力合流，底层Agent loop各自独立。这一结论对企业AI落地具有重要参考价值——在选型与集成时，不能仅凭品牌命名判断技术同源性，需要深入理解底层架构设计。

本文通过代码级逆向分析，揭示了阿里两款千问办公产品在底层技术架构上的彻底分叉。对于企业AI落地实践而言，这一案例提醒我们：产品名称的趋同并不等同于技术架构的统一，Agent系统的选型与集成需要穿透表面功能，深入理解其底层的Agent loop设计、进程模型与执行引擎。组织与业务的合流固然重要，但底层架构的独立性往往决定了系统长期演进的技术上限。