2026 年 5 月，DeepSeek 的招聘页上，热招职位第一位写着「Agent Harness 产品经理」（DeepSeek 招聘页）。一个以模型能力著称的公司，开始招人做编程工具的运行环境。结合它此前没有发布 first-party harness 的事实，这个动作可以理解为 DeepSeek 正在补之前留下的产品空位。
DeepSeek 之前在 coding agent 上的策略是只提供模型和 API，把 harness 留给第三方编程工具。Claude Code、Codex、OpenCode、WorkBuddy 都能接 DeepSeek 的模型，用户自己选工具，DeepSeek 收 API 费用。在模型层竞争时这套逻辑说得通：模型够便宜够好，就能占据底层供给的位置。
但只卖接口的局限很快显现。模型供应商直接能看到的只有一条条 API 调用。模型输出了代码，但用户怎么用工具的、在哪个环节报错了、改了几轮才跑通、哪些代码用户采纳了哪些拒绝了，这些细节掌握在第三方工具及其运行环境里，并不天然回到模型供应商。没有真实编程场景的反馈，模型在复杂任务上的改进就缺了着力点。LangChain 的测试数据印证了这一点：同一个模型，有没有针对性的运行环境配置，在复杂任务上的表现能差 10 到 20 个百分点（LangChain 博客）。
DeepSeek 回头招聘 harness 产品和运行基础设施岗位，赛道的竞争逻辑就露出来了。模型能自主承载完整任务之后，harness 的角色发生了变化：它不只是协助用户调用模型的客户端，也可以成为观测行为数据的仪器。厂商拥有 harness，才有条件在用户授权和数据政策允许的范围内记录模型在真实任务中的行为序列，再把这些数据用于改进模型。
如果这个判断成立，过去半年每种新形态的出现都应该能用数据竞争这条线索来解释。把它们逐个摆开看，事实也确实如此。
最先引人注意的是桌面应用的集中出现。OpenAI 在 2026 年 2 月推出了独立的 Codex 桌面应用，定位是 agent 的指挥中心（Codex app），7 月把它合并进了 ChatGPT 桌面端。当时不少人猜 Codex 项目已经收编，或者命令行工具要退出舞台。但 OpenAI 自己的架构文档写明：命令行工具、IDE 插件、网页端和桌面端底层共享同一套 Codex harness（Codex App Server）。合并的是桌面产品外壳，Codex 产品和 harness 没有因此消失。
那为什么要多做一个桌面应用？从数据角度看答案很直接。命令行在终端里足够灵活，能接入脚本、CI 流程或其他自动化逻辑，资深开发者用得顺手。但对不习惯终端的人，它是一道门槛。桌面应用降低了这道门槛，吸引更多人把开发任务放进厂商的运行环境里。更多用户意味着更多数据。桌面应用还更自然地承载 computer use 和 browser use。2026 年 4 月 Codex 增加了操作系统控制和应用内浏览器（Codex for almost everything），Antigravity 2.0 也把浏览器交互作为核心能力。Agent 每次点击页面、读取网页元素，都会产生传统模型 API 请求本身不包含的交互轨迹。
命令行没有消失，因为它服务的是另一群人，产出的是另一种数据。在终端里跑复杂任务、写自定义 skill、编排自动化流水线的高频用户，往往在解决更复杂的工程问题。从本文的数据框架看，这类轨迹更直接地反映复杂重构和调试中的真实痛点。放弃命令行等于切断这部分数据源。所以厂商的做法是两种入口并行，覆盖不同数据密度的用户群。
比桌面应用更进一步的，是把执行环境本身搬进厂商云端。Claude Code 在 2025 年 10 月上线网页版，任务放在 Anthropic 管理的云环境里执行（Claude Code on the web）。Codex 2025 年 5 月首发时就是云端 agent，每个任务在独立的云沙箱里运行（Introducing Codex）。Cursor 2025 年 5 月推出 Background Agent，运行在远程环境里，后来改名 Cloud Agent，到 2026 年 2 月升级成了完整的虚拟机（Cursor 0.50；Cursor 2.0；Cursor agent computer use）。
三家做这件事的时间线高度重合，而且都是模型厂商或正在往模型层走的公司最先动手。这不是巧合。任务运行在厂商掌控的虚拟机里，厂商就有条件观测工具调用、报错重试和用户批准或拒绝等记录，实际收集范围取决于产品的遥测与数据政策。如果 agent 完全在用户本地跑，且 harness 不另行回传遥测，这些行为细节就留在用户机器上，模型供应商只看到 API 请求。OpenAI 早期选云端架构，Anthropic 补托管云会话，Cursor 把后置代理升级成云虚拟机，从数据竞争角度看，卡位的都是执行环境里的行为数据。模型厂商需要这层数据来改进模型；IDE 厂商跟进，则可以保住长任务场景下的数据入口。
远程控制看起来和上面的数据竞争无关，只是人启动了长任务想去喝咖啡、回来再检查的便利需求。但移动端接入缓解了等待焦虑，让更多长流程任务变得可行。一个持续运行 20 分钟、经历了网络断线重连、多轮测试验证和跨文件修改的任务，暴露的工程场景复杂度，远非一次简单的函数修改可比。从本文的数据框架看，远程控制的价值在于让更长、更复杂的真实数据持续产生。对模型改进来说，这类长任务数据可能比多次短交互更有价值，因为它包含了失败恢复、多步推理和真实工具链摩擦。
桌面应用降低门槛扩大数据入口，命令行留住高质量数据生产者，managed agents 直接拥有执行环境并具备建立数据管道的条件，远程控制让更长更难的数据持续产生。这些形态变化看似各自独立，实则都在同一条数据链上。
数据链上的竞争发生在执行层，但外界最容易看到的是界面层。过去半年，国内外编程工具的界面在迅速趋同。任务列表、审批卡片、diff 预览、状态追踪、多任务看板，这些前端交互模式复刻成本低。Codex 的命令中心、Cursor 的 Agents Window、Antigravity 2.0 的独立客户端、TRAE Work 的任务工作台、ZCode 的桌面环境，在视觉和交互体验上几乎如出一辙。
界面趋同容易制造一个错觉：产品之间可以无感切换了。但界面下方的执行层在加速分化。主流的执行位置有四种：用户本地机器、用户配置的 SSH 主机、厂商提供的托管虚拟机、企业自托管的运行节点。这四种架构除了影响网络稳定性和故障概率，最核心的区别在于执行轨迹首先产生在哪里、由谁控制。本地执行的轨迹首先留在用户环境里，托管虚拟机的轨迹则由厂商基础设施承载；数据是否进一步回传或用于训练，还取决于遥测设置和数据政策。
一个容易误读的例子是远程控制。有一阵子流行一种说法，认为 Cursor 能用手机操控云端任务说明它的远程技术更先进，而 ZCode 和 Codex 的移动端要求本地电脑保持开机是技术欠缺。实际上所有基于本地主机的远程操控都必须依赖宿主机维持运行，ZCode、Codex 和 Claude Code 在这一点上没有差别。Cursor 的手机端同时支持两种模式：控制云端 Agent 时，手机连接厂商云端，不需要本地电脑介入；控制本机 Agent 时，仍然依赖本地主机运行。前一种差异来自有没有 managed agents，跟远程控制技术本身无关。
国内外差异也容易误读。国内产品在界面跟进上确实快。WorkBuddy 团队在访谈中直接说过，看到 Anthropic 推出 Claude Cowork 后意识到「大家的想法很一致」；同一报道还记录，后来的 OpenClaw 热潮推动团队在一周内重构产品并从内测转公测（钛媒体）。Kimi CLI 的开源讨论区里有用户提议引入 skill 机制，理由写着「受 Anthropic 的 Claude Code skill 机制启发」，代码也确实复用了 Codex 的组件（Kimi issue #107；Kimi NOTICE）。这些是真实的跟随证据。
但把国内产品概括为简单模仿不符合事实。字节跳动旗下的 TRAE 在 2025 年 1 月就发布了 IDE，早于 Claude Code 的 2 月和 Codex 的 5 月（TRAE 2025 Unwrapped），随后推出的 TRAE Work 同样具备云端托管执行能力。至少从公开产品形态看，不能据此得出国内外厂商存在显著技术差距；本文样本体现出的差异更多在战略重心：WorkBuddy 深度打通微信、企业微信、飞书和钉钉，ZCode 让任务排队等待闲置推理容量。这些布局同样在搭防线；部分产品重点落在渠道和供给策略上，TRAE Work 则已经进入云端执行环境。
如果把 DeepSeek 的路线视为反面教材，原因是它在 coding agent 上走得最远：没有发布 first-party harness，而是把模型接入第三方工具。执行环境里的数据入口因此掌握在第三方手里，DeepSeek 并不天然获得这些真实场景反馈。现在招聘 harness 产品和基础设施岗位，与它开始补这一层的推断一致，但这不是 DeepSeek 的官方表态，也不能单凭招聘证明原策略已经失败。其他国内厂商至少做了 harness，有条件在用户授权和数据政策允许的范围内接触自己工具里的行为数据；在第三方 coding harness 这条路径上，DeepSeek 直接掌握的仍主要是模型 API 调用。差距不在模型能力，在于能看到的数据深度不同。
评估一个编程工具产品时，再去清点它有没有任务列表、subagent、远程控制或后台任务，已经很难看出差距。这些功能面板复刻成本低，无法体现核心壁垒。想看清工具的真实实力，需要抛开表层的勾选项，关注数据在产品架构中的流动轨迹。
第一个问题：谁掌控执行环境。本地执行的产品，行为轨迹首先留在用户端；如果 harness 不另行回传遥测，模型供应商只能看到 API 请求。具备托管云环境的产品，则让厂商有条件观测 agent 在真实任务中的行为轨迹，实际范围仍取决于遥测和数据政策。不同的执行环境决定了数据首先沉淀在哪个系统里。
第二个问题：数据对谁可见。开源命令行和公开状态文件提高了用户和社区检视执行细节的能力；闭源桌面应用的遥测实现通常无法由外部用户完整审计。作为采购者或使用者，你需要查清操作记录是否回传、由谁可见，以及是否会用于改进模型。
第三个问题：谁在数据飞轮里。在用户授权和数据政策允许的前提下，模型厂商打造运行环境，运行环境收集真实行为反馈来改进模型，更强的模型吸引更多用户使用运行环境，更多用户输出更多高质量数据。这个循环一旦启动，缺乏自有运行环境的参与者就留在循环外面，拿不到持续进化的动能。按照本文的推断，DeepSeek 的风险就在这里：它有模型、有价格优势、有开源生态，但截至核查日缺少 first-party harness 这一层，难以建立同样的数据飞轮。
对产品成熟度的误判，往往来自用界面层的功能去套执行层的实力。一个产品界面精致、功能齐全，但如果托管执行和数据回流没打通，长期竞争力存疑。反过来，一个界面粗糙的产品，如果执行环境握在自己手里，并且在用户授权和数据政策允许下把数据用于改进模型，完全可能在下一个版本里反超。
对于只需要挑个顺手工具的个人开发者，功能列表依然有用。但对于想洞察赛道走向、判断哪家在建长期护城河的观察者来说，界面层传递的信息越来越少，执行层才能展现真正的竞争格局。