TL;DR：阿里在 2026 年中启动了企业级 Agent 的产线大整合，以 QoderWork 为底座重构出独立的“千问办公”桌面端。虽然通义千问 App 内置的“办公模式”与独立的“千问办公”在品牌命名、模型调用和办公场景上高度重叠，但本机逆向与运行时取证表明：千问 App 的办公模式采用内嵌自研 Agent 循环，而千问办公完整继承了 Qoder worker harness。两者在上层业务能力上汇合，底层 Agent loop 依然彻底分叉。
一、背景：从多线并进到阿里 Agent 产线大整合
国内大厂在 Agent 探索初期普遍经历了“内部赛马”的阶段。2025 年下半年至 2026 年初，阿里内部在办公与生产力 Agent 赛道上多条业务线并行下注：
•开发者与桌面生产力线：由智能编程平台 Qoder 衍生出桌面级通用智能体 QoderWork（2026 年 1 月上线），主打 Electron 宿主、本地 Worker 隔离与 MCP 协议扩展，能直接操作用户的本地文件与桌面软件，被集团内部定性为具备“操作系统级入口”潜力的关键底座。•协同办公与 SaaS 线：钉钉团队在 2026 年 3 月推出内置于钉钉生态的 悟空，主打企业内部组织协同与 SaaS 审批流。•云端执行与流程线：2025 年 9 月上线的 MuleRun，侧重云端多模态流程复用与全场景任务执行。•消费级与通义主线：通义千问客户端（Qianwen.app）在持续迭代对话能力的同时，也基于通义自身的 qwen-agent 框架，在客户端内部上线了具备搜索、代码执行、文件分析与 Skill 调用的“办公模式”。
多线分流在跑通各场景验证的同时，也导致了严重的同质化竞争与“重复造轮子”。2026 年 6 月中旬，陈宇森出任钉钉 CEO 兼悟空事业部 CEO；7 月初，阿里正式启动三大企业级智能体（QoderWork、悟空、MuleRun）的全面整合。整合策略确立了以 QoderWork 为技术与架构底座——凭借其桌面本地执行能力、最高的活跃度与 Token 消耗量，吸收悟空的协同流与 MuleRun 的云端执行能力，重组并升级为面向集团未来的独立桌面端——千问办公（QwenWorkCN.app）。
这次调整让阿里在品牌层完成了向“千问”大旗的收拢，但也随之带来了技术上的困惑：独立发布的“千问办公”与通义千问 App 里的“办公模式”，既然都冠以千问之名，且都在解决办公场景下的自主规划与工具调用，它们的底层 Agent loop 是不是已经在合并中统一成同一套代码架构？通过对本地安装的两个 App 进行静态反编译与运行时追踪，可以给出确凿的分析结论。
二、直接结论与架构对比
Qianwen.app |
QwenWorkCN.app |
|
agent_host/bundle.cjs |
@ali/qoder-agent-sdk-next |
|
agent_host |
qoder-worker-runtime.obf.mjs |
|
control_request: can_use_tool |
||
thread-events.jsonl |
agents.db |
|
qwen-agent-api.qianwen.com |
gateway.qwenwork.cn |
两端在最外层都遵循了标准的 Agent 执行范式：大模型接收指令后返回 tool_use，宿主环境调度执行对应工具，将 tool_result 回填上下文并进入下一轮迭代。但这种概念层的一致只是 Agent 的通用抽象，在具体的代码实现、进程边界与协议设计上，两者完全独立。
三、本地代码证据：agent_host 与 Qoder Worker 的内核对立
千问 App 磁盘版本为 4.1.0.175（运行时进程加载 4.0.7.171）。其架构核心是独立的 agent_host.app 和底层动态库 libagent_runtime.dylib，运行在独立的工作目录下。格式化其 bundle.cjs 后，可直接看到基于 query2() 的主循环逻辑，内部包含完整的 decideNext、executeToolUseBatchesStreaming、ToolLoopTracker、分级压缩（micro/full compact）、token 预算控制以及中途干预（steer）机制。整个 bundle 内不存在任何 Qoder SDK、Qoder Worker 及其专有通讯协议的痕迹。
千问办公版本为 0.1.8，其底层技术栈则是典型的 Qoder 演进路线。package.json 中显式引入了 @ali/qoder-agent-sdk-next 1.0.20，运行时元数据标注 worker 版本为 1.1.18。其架构分为明显的两层：Electron 主进程通过 UnifiedChatExecutor → create/resumeMainSessionQueryRuntime → SDK query 建立任务通道，再由独立的 Worker 进程加载 qoder-worker-runtime.obf.mjs，在 Worker 内执行 AgentLoop、schedule_tool_calls 与上下文压缩流水线（compression_pipeline），最后通过 SessionEventProcessor 异步持久化至 SQLite 数据库。
四、同一任务的运行轨迹与持久化差异
在相同任务（针对 MyContext 进行深度技术调研）的实际运行中，两者的执行轨迹和事件模型呈现出鲜明的区别：
千问 App 的办公模式完成了 5 轮交互，工具调用链严格按照 WebSearch → WebFetch × 2 → Skill → Bash 的顺序推进。其全生命周期事件以扁平的 thread-events.jsonl 文件记录，逐行追加 call、output、usage 与 turn_completed。
千问办公在 47.5 秒内接收并处理了 998 个流式数据分片（chunk）。其数据结构更为复杂，通过 agents.db 本地 SQLite 数据库精确落盘了 WebSearch × 1、WebFetch × 2 以及独立的 Thinking 与 text 分片。两套系统虽然都完成了自主工具循环，但事件总线、状态机设计以及本地存储机制毫无交集。
五、QoderWork 的代码继承关系
从代码血缘上看，千问办公与 QoderWork 属于同一条演进主线。本地比对显示，千问办公与 QoderWork 共享了 62 个直接依赖包，QoderWork 的 37 份 SQL migration 脚本在千问办公的安装包内完全一致，UnifiedChatExecutor、SessionEventProcessor 等核心控制器代码逐字节同源。
这充分证明：千问办公是阿里在产线整合后，直接继承并改版自 QoderWork 的产品，它延续了 Qoder 的 Worker Harness 体系；而在整合过程中，通义千问 App 内部原有的 qwen-agent 架构并没有与 Qoder 体系合并。
虽然不排除两者未来在集团统一的模型网关、用户统一账号体系或遥测监控层逐步共享基础设施，但就当前发布的客户端版本而言，实际情况可以清晰概括为：组织与业务能力合流，底层 Agent loop 各自独立。
复核路径：
•/Applications/Qianwen.app•/Applications/QwenWorkCN.app•~/Library/Application Support/Qianwen/qwen-agent/•~/Library/Application Support/QwenWorkCN/
