模型之外皆属Harness：Deepseek下场，国内AI竞争主战场为何变了？

2026年5月中下旬，Deepseek内部组建了全新的Harness团队，方向为代码智能体产品，内部对标Anthropic旗下的Claude Code。前Jane Street明星量化工程师崔天一在3月加入该团队，资深研究员陈德里公开证实并负责招聘。在Deepseek的招聘JD中，明确写着一个公式：“Model + Harness = Agent”。当基础大模型的能力逐渐拉平，单纯拼参数的时代正在过去。Deepseek亲自下场组建工具链团队，标志着国内AI竞争的主战场正从“炼大模型”转向“造工具链与办公落地”。

Deepseek为何亲自下场做Harness？

在很长一段时间里，开发者对Deepseek的期待停留在开源更强大的基础模型上。但代码能力强不等于开发者会将其作为生产力工具。真正改变工作方式的不是聊天框里的代码回答，而是能进入终端、理解项目、读写文件、运行命令、修复错误的工程智能体。在官方出手前，开发者社区已基于Deepseek模型做出了各类开源终端Agent。Deepseek此时组建Harness团队，意在掌握接口设计权与训练数据闭环，将社区踩出的路收编为官方主干产品。

要理解这一战略意图，必须先弄清楚Harness到底是什么。对于非技术背景的读者而言，“Harness”这个词可能有些陌生。在Deepseek的公式中，模型负责推理，Harness负责其他一切。Harness原本在工程领域有“马具”或“安全带”的意思，引申到AI领域，它指的是Agent的“运行时基础设施”。

为了更通俗地理解，我们可以把大模型比作一个高智商打工人的“大脑”和“智力”，而Harness就是这名打工人的“岗位职责说明书、KPI考核标准、办公防爆墙以及工具箱”。它不是运行前组装的“脚手架”，也不是提供构建块的“框架”，而是一个持续运行的系统。它负责编排执行循环，分发工具调用，管理上下文，执行安全检查，并负责错误恢复与状态持久化。大模型本身是无状态、无环境交互能力的，它只能接收文本输入并输出文本。而Harness弥补了这些缺陷，让模型能够真正与外部世界交互，执行具体任务。

为什么基础模型公司必须亲自掌握这套运行时？核心在于Agent产品不仅是模型能力的出口，更是模型能力的训练场。Deepseek的JD中强调“实现模型与Harness的共同进化”。在真实的复杂任务中，模型会遇到各种由于环境限制、工具返回异常导致的失败。Harness记录这些失败轨迹，能够反哺模型训练，形成飞轮效应。如果任由社区代建，模型厂商将失去最核心的应用层数据反馈，沦为单纯的算力与权重提供商。

从工程角度看，优化Harness比单纯优化Prompt更能决定Agent的成败。据技术专家分析，在Agent运行中，工具输出占Agent在上下文中实际看到内容的67.6%，而系统提示词仅占3.4%。这意味着模型的大部分“视野”被工具调用的结果占据。如果Harness对工具输出的格式处理不当，或者未能有效压缩冗余信息，模型就会陷入“上下文腐烂”，导致后续推理质量急剧下降。

更致命的是复合错误问题。一个包含10个步骤、每步可靠性为99%的Agent过程，端到端成功率约为90%；当任务复杂度提升到50步时，成功率暴跌至60%。在真实的代码库维护或企业办公自动化场景中，几十个步骤的连续操作是常态。此时，模型本身的推理能力再强，也无法弥补概率上的累积损耗。只有通过Harness中的错误处理与恢复机制，才能在步骤失败时进行重试或路径修正。这正是Harness的工程价值所在，也是Deepseek必须亲自下场的原因。

腾讯做连接器，阿里做前端渗透：大厂工具链的差异化路径

Deepseek的转向并非孤例。据行业媒体报道，强化Agent能力已成为国产基础大模型2026年的重要发展方向。基础模型逐渐沦为“水电煤”，竞争主战场转向应用层。国内其他大厂也在通过工具链寻找差异化卡位，但路径各不相同，这背后反映了各家生态禀赋和目标用户的差异。

腾讯在2026年6月打出了企业Agent新底牌，推出WorkBuddy企业版。其核心定位是全场景职场智能体桌面工作台，主打从个人提效走向组织协同。WorkBuddy企业版支持多Agent并行与业务系统Connector接入，试图抢占AI办公统一入口。腾讯的卡位逻辑依托于其庞大的企业微信与腾讯云生态。对于大型企业而言，AI办公的痛点不在于单点工具的极致体验，而在于能否打通内部孤立的办公系统。腾讯通过做连接器，让Agent能够直接调度企业数据与流程，侧重于组织级的协同与复杂任务交付。这种路径的优势在于壁垒高，一旦接入企业核心业务流程，替换成本极大；挑战则在于需要极强的企业服务能力和定制化支持。

阿里则另辟蹊径，选择在Web端降低自动化门槛。阿里开源了纯前端浏览器内GUI Agent框架PageAgent。这一框架无需后端部署，一行代码即可让网站集成AI操作员能力。阿里的卡位逻辑在于赋能Web开发者，让任何网页秒变AI原生应用。在大量传统企业系统无法提供API接口的现实下，通过前端DOM操作实现自动化，是一条务实的降维打击路径。这种路径的优势在于轻量、易集成，能够快速覆盖海量长尾网站；但前端DOM结构频繁变动也可能带来稳定性挑战，对Harness的错误恢复能力提出了更高要求。

对比来看，各家不再单纯比拼模型跑分，而是根据自身的生态禀赋构建工具链。腾讯做连接器，阿里做前端渗透，Deepseek则从开发者最刚需的代码工程场景切入。这种分化表明，国内AI行业已经认识到，没有完美的通用Agent，只有在特定场景下通过厚重的Harness工程打磨出的垂直解决方案。对于企业采购而言，选择哪家工具链，本质上是在选择哪种自动化路径：是深度绑定办公生态，还是灵活嵌入现有Web系统，或是赋能开发者的工程工作流。

Viktor的2000万美元ARR证明：企业愿意为自主执行付费

工具链的成熟，正在改变AI参与办公领域的范式。原生Copilot的逻辑是“起草并等待人类完成”，AI生成一段文案或一段代码，最后一步仍需人工介入修改和执行。这种模式下，AI只是一个提效工具，无法真正替代劳动力。企业员工需要时刻盯着AI的输出，进行校验和落地，这实际上增加了认知负担。

海外市场已经出现了范式转移的明确信号。作为海外趋势参照，波兰AI办公自动化公司Viktor定位为Slack内的AI员工，在无销售团队的情况下实现了2000万美元年化收入（ARR），服务3万家企业，并于2026年5月获7500万美元A轮融资。Viktor的模式代表了新型AI员工的终局形态：拥有云端电脑，能长时间持续作业，牢牢把握海量上下文，直接交付结果。

Viktor定位为Tier 3 AI Coworker，这意味着它处理的不再是简单的问答，而是营销审计、广告管理、线索研究等需要多步骤、长时运行的复杂任务。企业端对这种无需人类最后确认、能长时间持续作业的AI存在巨大付费意愿。这种商业数据的爆发，证明了办公自动化的价值锚点已经从“辅助生成”转移到了“自主执行”。

国内厂商布局Harness与Agent工具链，正是为了承接这一趋势。当Harness能够提供足够的安全护栏、状态持久化和错误恢复能力时，AI就能从需要人类时刻盯着的“实习生”，变成可以独立交付工作成果的“外包商”。企业采购的关注点也将从模型参数大小，转向Agent能否稳定运行8小时而不崩溃，能否自动处理API限流与网页结构变更。对于开发者而言，这意味着构建AI应用的焦点将从“如何写好Prompt”转向“如何设计稳健的运行时环境”。

Token爆炸与“厚框架”的工程壁垒

转向工具链竞争后，企业采购和开发者在实际落地中面临的挑战并未减少，反而更加聚焦于工程层面。

首当其冲的是Token爆炸问题。长时运行的Agent在“思考、行动、反馈”的循环中，极易因冗余的工具输出导致上下文迅速膨胀。开发者社区广泛讨论这一难题，认为这不仅推高了推理成本，更会导致模型注意力分散，任务失败率骤升。例如，在执行一个网页数据抓取任务时，如果Harness将整个网页的HTML源码原封不动地塞入上下文，模型很快就会迷失在冗余信息中，忘记最初的任务目标。因此，Harness的上下文压缩与记忆管理能力，成为企业采购时的核心考量指标。一个优秀的Harness必须知道哪些历史信息可以丢弃，哪些工具返回结果需要摘要，这考验的是深厚的工程架构能力，而非模型本身的智力。

这也引发了开发者对“套壳”薄框架的警惕。如果大模型厂商推出的Harness只是简单的API封装，提供基本的对话窗口和工具调用接口，将缺乏实际的调试价值。生产环境中的脆弱性，要求Harness必须具备沙箱隔离、细粒度权限控制、断点续传等“厚框架”特性。只有具备深厚工程壁垒的运行时，才能真正解决企业级应用的稳定性需求。例如，在代码执行场景中，Harness必须提供安全的沙箱环境，防止模型生成的恶意代码破坏宿主系统；在长时任务中，必须支持断点续传，避免因网络波动导致整个任务从头再来。

此外，地缘政治因素为国产Harness留出了巨大的市场真空。Claude Code等海外顶尖工程智能体产品对中国大陆及中资企业实施访问限制。国内开发者在无法直接使用这些顶尖工具的情况下，只能寻求国产替代。Deepseek组建Harness团队，不仅是对技术趋势的跟进，更是对这一庞大替代需求的响应。

对于企业采购和开发者而言，理解Harness的价值，意味着在选择AI产品时，不再被炫酷的对话演示所迷惑，而是去追问它的错误恢复机制是什么，上下文管理策略是什么，以及它能否真正融入现有的工作流。在工具链竞争阶段，企业应优先考察厂商的工程交付能力和生态兼容性，而非单纯比较模型跑分；开发者则应关注Harness框架的开放程度和调试工具链完善度，选择能够提供深度可控运行时的平台。