对话MiniMax Agent团队：“没有Agent企业敢说自己有壁垒”（上）

过去一年，AI 开始逐渐从 “ 对话 ” 向 “ 行动 ” 演进，技术走得很快，能够直接操作电脑，处理复杂任务的 “ 桌面智能体 ” 正成为新的技术前沿和竞争焦点。

2026 年 1 月 13 日，Claude 发布了 Cowork，成为第一个普通人能用图形界面操控电脑文件的 Agent；一个多星期后，MiniMax 发布 Agent 2.0 版本，定位 “ AI 原生工作台 ”，不仅上线了桌面端，支持 Mac 和 Windows，还推出了面向垂直场景的 “ 专家模式 ”。

桌面端的优势似乎显而易见：能操作大量本地文件，处理复杂长链路的任务，可能是真正深入人办公场景的最佳环境。但同时面临着诸如复杂环境适配，上下文更长，性能延迟和安全性等难题。我们想知道，行业是如何解决这些难题的，以及，桌面 Agent 到底能多大程度的深入到用户，还是成为一个产品过渡的自嗨模式？

知危与 MiniMax Agent 2.0 团队核心成员，研发负责人阿岛、产品负责人寻鹭进行了一场对话，他们从产品、技术、组织和行业等层面，详细地解答了我们的疑问，并且坦率地承认，“ 现在，没有一家 Agent 企业敢说自己有壁垒。”

如果你是非 AI 从业者，这场对话会让你触碰未来，如果你是 AI 领域从业者，那这场对话一定是你不容错过的前沿思考。

以下是对话原文，知危进行了不改变原意的编辑。

知危：其实桌面 Agent 也有一些同行开始做了，MiniMax Agent 2.0（ 以下简称 2.0 ）发布的前一周，Claude Cowork 就发布了，所以 2.0 最初的契机是什么？产品研发经历了什么样的过程？

阿岛：我们选择在此时上线并不是受同行发布的节奏影响，因为不可能在一周内赶出这种产品。

其实我们早在 2025 年 9 月初就有了 Expert （ 专家 ）模式和增加 Context （ 上下文 ）的想法，10 月份在内部推行 “ Agent 实习生 ” 验证成功后，12 月 15 日正式立项投入。

我们在大模型创业公司中算比较精干的， Minimax 的模型和产品线布局最广，涵盖三个模态及对应产品。尽管公司有 不到 400 人，但具体到每个产品上，我们可能都是以一对十（ 同行 ）的比例在作战。

比如这次的桌面端，实际上是 3 个同学用一个月的时间就开发出来的。整个 Agent 团队的研发力量非常精干，如果加上产品经理，总共也就 4 个人左右。

Agent 实习生目前已经在公司内部普及和扩散，成了大部分同事离不开的工具。

知危：所以 2.0 想解决的最核心问题是什么？

寻鹭：一句话概括：希望通过新的端和更专业的知识水平，帮用户解决更多事情，干更多的活。

2.0 版本涉及更多的环境，从之前的网页端扩展到桌面端，可以利用本地工作区和更多文件来干活。

然后是质量上的提升，通过专家系统，无论是官方还是 UGC 做的，都能将专业知识和流程打包成专家 Agent，去高质量完成原本需要领域专家支持的任务。

知危：能不能更细致地解释 Agent 2.0 的产品结构？对于大多数人来说，还是相对陌生。

阿岛：本质上，我们认为 1.0 阶段的很多 Agent 只能完成单环节任务，更像是一个 Demo。我们更希望看到它在生产力中真正发挥作用，这意味着它必须嵌入工作流。

2.0 版本源于我们公司的内部版本（ 内部称为 Agent 实习生 ）的外化，我们对 2.0 的定位是它能像助理或实习生一样，在工作流中完整地完成任务并交付结果。基于此，它需要延伸出获取充分 Context 的能力。比如内部同事办公场景下，Agent 需要能获取到内部各种 SaaS、IT、HR、财务、大数据，以及研发用到的监控、报警、代码仓库等所有软件工具的 Context。

第二个就是它需要具备相应领域的专业知识。换句话说，财务、人事、研发、GPU Infra、文本算法和视频算法的助理，它们之间非常不一样。只有做到这一点，助理在用户场景下才真正有用，能交付有价值且高度可用的任务结果。而不是说依然需要人类输入大量上下文并重度参与，交付出一个自动化程度低、不可用的结果。

从对外角度看，我们做桌面端是因为它是当前获取用户 Context 并操作环境的最佳方式，这样才能真正嵌入工作流，像助理一样帮用户交付结果。助理的特点是你交给它任务，它还你结果，你不需要时时刻刻盯着它，且你可以帮助它进步。第二点它是领域助理，这就是我们外化推出来的“专家”能力。以上这两个核心输入，也部分回答了 2.0 是如何生长出来的问题。

知危：所以你们内部推行使用 “ Agent 实习生 ” 的时候，发生了什么？是怎么扩散的？

阿岛：扩散过程首先是从最熟悉这些工具的技术和产品团队开始的。核心在于思维的转变：每当开始一项工作时，首先不是怎么用 Agent，而是思考 Agent 是否能解决；如果不能，它缺什么能力？

所以先后顺序是研发团队、产品团队、 GPU Infra 团队、 HR 团队、 投资和财务团队，最后是销售团队。我们的经验是，一套能让大家真正用起来且产生依赖的产品，必须具备本地环境、充分的 Context（ 上下文 ）、通过 OAuth 接入的云端环境，以及针对研发、HR、财务或销售等差异化需求所提供的 Expert 专业知识。

知危：Agent 2.0 特别强调 Context（ 上下文 ）的重要性，那么本地计算机提供的 Context，相比浏览器、手机等有哪些不同和优势？

阿岛：从用户视角看，Agent 是你的代理或助理。在严肃的工作场景中，2.0 和手机上只解决简单知识查询的大模型不同，我们希望真正像助理一样解决工作以及未来生活中的问题。如果你有一个人类助理，你不会觉得它只用手机就能完成专业工作，这是不可能的。

寻鹭：从 Web 端转到桌面端，主要解决了 Web 端无法处理的问题。首先是文件上传的限制，以前 Web 版本如果需要用户的文件，只能靠手动上传。但出于速度和固有速率的限制，网页应用通常会设置上限，不允许用户上传 5G 大小或多达 30 个以上的文件。对于有代码仓库的用户，或者做图文创意、有大量视频图片素材的用户来说，在 Web 场景下根本没办法把这么多文件打包上传。

有了桌面端之后，用户可以直接选中文件夹进行操作。比如摄影师处理视频素材，或者用户盘里有八千张照片需要整理，直接操作本地文件夹比上传再下载八千张图片到网页端的流程要好得多。第二个桌面端解决的问题是，它能更好地实现浏览器托管场景，让 AI 模拟人的点击操作，在网页上完成重复动作。比如每天自动爬取 TikTok、Twitter 等热门社媒网站上对公司和产品的评价，并在发现负面信息时及时提醒。

这种场景如果放在 Web 端做，由于我们是通过沙盒来实现，加上 IP 洁净度等限制，很容易被拦截。但在桌面端启动浏览器时，它是可以用用户本身的浏览器来操作的，所以跑通网页托管的整个流程会更加流畅、自然。现在无论是自动监控社媒，还是自动发布帖子，都会比以前更加顺畅。

确实，现在操作速度还比较慢，包括像 ChatGPT Atlas 的操作也比较慢。浏览器托管的速度问题和它的理解效率问题，是大家一直需要去优化的方向。

对于手机端 APP ，我们一直做得比较轻，没有把专家模式等重模式搬上去。原因在于，我们观察到用户使用 Agent 的方式与常规 Chatbot 主打搜索、写作不同，它更多是 C 端用户在解决工作场景中长程、重复且繁琐的操作。这类任务时间跨度大，不是在手机上发起后能即时得到回答的用法，如果只是即时需求，用户也不需要求助 Agent。此外，在手机端操作网页或软件会受到系统及应用权限的严格限制，挑战更高，所以目前我们不太会触碰这一块。

知危：关于运行 Agent 2.0 的环境，为什么不采用目前常见的云端沙盒，而更多依赖用户的本地电脑环境？

阿岛：云端沙盒除了有被风控拦截问题，从更专业的角度看，它本质是面向通用场景的。举个简单的假设，比如专业的视频剪辑团队，肯定配有非常好的机器、超大内存和高性能 GPU，或者是 Mac Ultra 系列这种拥有大统一内存和 APU 的设备。只有这样，在跑 FFmpeg 这种视频处理任务时，才能达到很好的性能。

但你不太可能在一个通用的沙盒里去满足各种各样的需求。比如我们的服务对象如果是算法工程师或 Reddit 上 LocalLLaMA 社区的爱好者，他们机器上可能装了好几块 A100，这显然不是沙盒能解决的问题。如果希望 Agent 对专业用户在特定场景下真正好用，桌面端就有不可替代的优势，包括之前提到的 Context。

桌面端还有一个至关重要的优势：长期的 Context 沉淀与记忆构建。在桌面端，我们并不是只依赖用户指定的单个文件。随着 Agent 在用户电脑上运行时间的增长，它会越来越了解用户的上下文，并自动构建关于该用户及其工作环境的 Memory。很多时候，你甚至不需要重新上传或详细说明，只需给出指令，只要是你过去曾经操作过或存在于环境中的事情，它就能直接处理。这种深度环境感知和记忆积累是 Web 端无法实现的，因为 Web 端缺乏这种持续且原生的运行环境。

最后必须强调：今天 Agent 进步的最大瓶颈之一是 Agent Infra（ 可以简单理解为智能体的基础设施 ）。

知危：为什么这么说？

阿岛：比如刚才说到了关于风控拦截或身份验证的方面，这叫 Agent Auth。即 Agent 作为你的个人助理，如何能真正代表你的身份？在云端沙盒上，它无法真正代表你，因为它不是你个人的机器，没有你的 IP 指纹、User Agent 等信息，产生的操作更容易引发安全性讨论。

但在你的本机，它就是你的个人电脑，代表你的个人身份。在这里操作浏览器或处理事务，身份对标非常明确，不会存在这方面的问题。

我们横向对比了所有获取网页信息的 Agent，无论是像 Browser Use 这样专业的、Manus 这样通用的，还是 ChatGPT、Claude Code 等。最终结果是，在 Cloudflare 这种网络安全服务商的反爬、反垃圾机制面前，成功率普遍不高。即便人类接管去点验证码插件，也很有可能因为被识别出不是真实的桌面环境而无法通过。这就是目前 Agent Infra 面临的现实挑战。

我个人的观点是，未来人类行为和基础设施都会面向 AI 重新组织，届时会有更不一样的形态和更好的方式来验证 Agent 的代理身份。但就目前而言，桌面端形态在这些方面是难以替代的。

知危：如何理解云端沙盒本质是面向通用场景的，却又无法满足很多需求，这是否矛盾？Agent 2.0希望面向通用还是垂直场景？

阿岛：云端沙盒所谓的“通用”往往意味着只能处理浅层的、所有人适用的简单任务。

而真正的 “ 通用 ” 应该是能够深入并覆盖各种专业场景。正是为了实现这种高阶的通用性，我们才必须开发 “ 专家 ” 能力和桌面端。因为只有深入到每个人的具体专业环境、调用高性能硬件并理解其特定的工作流，Agent 才能在各种垂直领域都把活儿干好。

换句话说，我们的目标是通过深度专业化的能力，最终达成真正意义上的、全场景的通用。

比如写公众号。在你的本地环境，Agent 可以内化你过往积累的大量素材、写作习惯和风格，并索引历史资料，在你写新文章时直接给出一个高度契合的初稿。这种深度的个性化能力，云端沙盒是无法实现的。相对而言，云端沙盒擅长的是那种完全脱离个人环境的任务，比如“去网上收集 100 双耐克鞋的信息”，只需要通用互联网访问能力。

寻鹭：回顾去年，行业内所谓的 “ 通用 Agent ” 大多停留在 “ 啥都能做一点 ” 的 Demo 阶段。比如我们早期的 Lightning 和 Pro 模式，内置了几个处理 Deep Research、PPT 或网页开发的 Sub-agent，这只能算浅层的通用。但在去年下半年，通过访谈法务、财务等职能部门，我们发现真正的 “ 通用 ” 必须达到 Production Ready（ 生产就绪 ） 的标准。

这意味着它不能只靠一个死板的预设框架，而必须是一个优雅、灵活、可路由且可插拔的专家模式。举个例子，金融领域的 Deep Research 关注的是研报和实时行情数据；而法律领域则需要接入完全不同的判例数据库、法规接口，且国内外的法律逻辑也大相径庭。如果只用一个固定的通用框架，由于预接的 Data Source API 偏向性（ 比如偏金融 ），它在法律场景就无法深入。所以，我们现在的自定义模式允许用户叠加更多 “ 专家 ”，本质上是通过这种高灵活性的框架，在各个垂直领域实现真正的、深度的通用化交付。

知危：Agent 2.0 的产品形态比较新颖，您希望如何提升用户认知并带动用户增长？

阿岛：Agent 2.0 这种产品绝不是互联网时代的买量产品，它首先不会完全受限于手机端，其次它深耕于生产力场景，而非娱乐或搜索这类浅层的通用场景。

增长的关键首先在于产品要达到极佳的效果并真正解决问题，其次要运营起相应的口碑和社群，建立良好的品牌，并基于实际的使用案例进行传播。

因此，我们的增长路径会更接近 Cursor 或 Lovable 等海外产品的成长模式。

寻鹭：用户可能并不是因为知道 MiniMax 是一个通用产品才被吸引，而是因为在某个帖子中看到它做营销、社媒监控或特定领域的工作非常好用才过来的。

针对垂直领域和专精 Agent，我们在获取用户和提升渗透率上面临挑战。因此，Expert 模式的下一个目标是产出更多 PGC 和 PUGC 内容，同时想办法激励更多 UGC 专家涌现。在这个过程中，我们希望用户是因为有一个明确的问题或特定领域的诉求来使用 MiniMax Agent，而不是拿到一个看似无所不能、却让人不知道该拿它来做什么的通用产品。

Cursor 和 Lovable 增长策略的核心点在于：首先抛开常规手段，最关键的是能抓取并定义一个极具潜力的新场景。这种对场景的创新定义能力，决定了其后续做 PUGC 增长时能够具备极高的初始势能，并在起步阶段就达成非常强悍的结果反馈。

另外，Base44 自建了一整套数据库和云端托管，基于这些观察，我认为增长的核心在于两点：产品定义足够新颖，能在初期形成强大的势能，产出极具说服力的结果。通过真实用户的 Use Case 进行口碑传播和扩圈，而非通过大规模买量吸引非核心用户。投流获取的流量往往伴随着高流失率，只有让核心用户带动的裂变，才能保证增长的质量和精准度。

要形成增长势能，首先需要明确核心场景。关于这一点，我们在海外已有明确的认知：海外用户在 Vibe Coding 以及视频、图文创意素材方面有极强的诉求，因此我们在 PGC Expert 的打造和引流方向上有清晰的指引。

在国内市场，由于 MiniMax Agent 上线相对较晚（ 去年 10 月上线，近期才正式增加交流与露面 ），目前我们仍处于对国内用户行为的分析与拆解阶段。

在未来一两周内，随着我们推出的 Expert 方向和新动作，大家会看到更清晰的思路。同时，我们也正通过观察目前逐渐沉淀下来的核心用户，研究如何进行转化，并学习如何借由他们深入国内特定场景，从而找到更适合国内环境的用户裂变点。

知危：目前用户对 Agent 的认知似乎还处于早期阶段？我们了解一些做 Agent SaaS 的企业，他们最大的痛点是由于企业或个人不确定 Agent 到底能做什么，导致需求与技术无法完全匹配，使得 SaaS 公司不得不像咨询公司一样去介入。相比之下，MiniMax 作为一个通用平台，可能很难像垂直 SaaS 那样提供类咨询的服务，大部分场景需要靠用户自己挖掘，您是如何看待这个问题的？

寻鹭：如果是针对 C 端用户，我们会想方设法尽可能缩短用户从进入到使用的路径。目前 Agent 页面缺乏问答指引和示例 Query，用户看到简单的文字介绍或浏览量，并不清楚实际产物效果。

所以下周我们会做的一件事，就是通过增加示例 Query 和展示过往优秀产物，让用户对专家的能力有明确预期，知道类似的输入能得到什么样的结果。我们更倾向于站在 C 端产品的视角，通过优化交互和用户友好型的迭代，而不是靠一对一咨询的形式，来缩短用户与 AI 能力之间的距离。

知危：目前业内普遍认为 Agent 的切入点应先聚焦于企业垂直领域，其核心竞争力体现在两个维度：一是 SaaS 厂商的先发优势，通过多年积淀的固化流程实现对业务场景的深度覆盖；二是垂直 AI 公司的专业深度，通过深耕金融、法律、医疗等高门槛行业建立技术护城河。MiniMax 作为底层大模型厂商如何在保持通用能力的同时，和在 “ 流程闭环 ” 与 “ 行业深度 ” 有优势的竞争对手竞争？

阿岛：这里的核心在于我们对未来的判断：未来人类的组织和基础设施是会围绕 AI 与 Agent 重新构建以达到 AGI，还是由 AI 和 Agent 去迎合现有的组织与基础设施？这是一个核心的判断。在此前提下，我们要明确的是，想追求真正的 AGI，做一个具备强大智能且能广泛满足用户深度需求的产品，还是想做一个收入和盈利都还不错、甚至仅仅是一块生意层面的业务？

最近我也面试过一些候选人，其中一位从 2023 年 GPT-3.5 阶段就开始做 Automation 和 Workflow，在当时算非常领先。但迫于生存压力，他们本想做通用的产品，最后只能转而成为垂直领域的信息爬取专家，比如做销售线索或简历筛选。最终他们搭建了一套深入行业的 Workflow，盈利表现不错，但规模也因此受限。如果他想切入另一个行业，就必须按照这个模式重新再做一遍。

所以，我们对未来的判断很明确：我们要选前者，而不是做后者。

我们公司不依赖那种规模受限的垂直生意，这是前置判断。其次，我们也不是要做一个无人问津的 “ 阳春白雪 ”，像寻鹭刚才提到的，我们认为走前者的路径，通过 Expert 模式、Agent 的自我进化以及 Agent Infra 的演进，能够获取足够的 Context 和 Memory，最终在用户领域做得越来越好。这不仅依赖于底层模型的进步，更取决于多模态理解模型（ VLM ）的突破。虽然现在浏览器操作慢、效果不佳是因为 VLLM 仍落后于大语言模型，但我们看到 VLLM 也在快速进步。归根结底，这在于是否相信 Scaling Law 和摩尔定律，如果相信，我们坚定选择前者。

寻鹭：企业内部许多固化的合规或处理流程，往往并不适合直接用 “ 自主决策 ” 的 Agent 完全替代。目前很多企业的做法是将流程中的某个节点（ 如合规检查 ）替换为大模型节点，这更像是一种规则自动化，而非真正的 Agent。

如果跳出产品本身，从 AI 工具化的未来方向来看，企业自建 Agent 的现象确实会长期存在。任何具备资源和技术信念的企业，在意识到 Agent 能显著提效时，第一反应往往是观察外部方案，随后拉起内部团队自研。这是一种正常的商业决策，尤其在涉及核心业务逻辑时。

如果是为了快速获得 PMF（ 产品与市场契合，产品马上就能出售获利 ），切入金融、医疗等垂直场景确实更高效。他们往往通过大量的模板、路由工程和固定的 Workflow 来保证稳定性，这在底层逻辑上可能并不是一个开放的 Agent 框架，而是一个深度的行业工具。

针对垂直与通用的争议，我们坚持深耕通用框架。我们的核心目标不是停留在表面的“万能”，而是通过构建一个更高阶、更稳健的底层框架，能够容纳并理解用户长期积累的复杂数据，而不仅仅是单次任务的片段信息，并且能够无缝深入到各种本地、云端甚至复杂的企业生产环境。

知危：MiniMax团队在研发Agent实习生的过程，其实是一个不错的企业该如何走向Agent模式的样本，但是似乎很少有企业能做到这么顺畅？

阿岛：传统企业转向 Agent 模式的最大障碍并非技术本身，而是人的思维与组织方式的重塑。这种转变是一个动态进化的过程，正如 Minimax 团队自身在过去一年也经历了从不适应到 “ 离不开 ” 的认知升级。

这种进化的成功取决于两个核心维度的交汇：一是人的接受度，即个体对 AI 等新事物的开放心态与驾驭能力；二是技术的成熟度，即模型与 Agent 性能的实质性飞跃。

即使在 MiniMax 这样的技术驱动组织中，资深工程师初期也会因为固有的经验路径而对 Cursor 等 AI 工具产生抵触与不信任。

因此，通用平台的发展不能只停留在浅层功能，而应支持用户在认知转变后实现深度的协作进化。我们内部推行 “ AI First ” 和 “ Agent 友好 ” 的原则，要求无论是研发、财务还是产品，都要主动将 Context 和知识体系结构化，确保 Agent 能够无缝获取信息并发挥巨大的效率杠杆作用。这种 “ AI 原生 ” 的工作习惯，让环境变得易于被 Agent 理解和调用，才是释放 AI 潜力的关键前提。

我们会打造这样一套产品和框架，去帮用户往这个方向实现，但前提是用户得有这个思维，得愿意这么做。这就像 Everett Rogers 提出的创新扩散理论里说的，从 Innovator（ 创新者 ）到 Early Adopter（ 早期采用者 ）有一个过程。

我们觉得现在还处于早期，大家的 Mindset（ 思维 ） 在进步，能力也在进步。它一定会有个临界点，就是当能力进步到所有人无法忽视的时候。

拿我们团队举例，现在我根本不需要去建议任何一个同学用 Claude Code，大家已经深刻体会到它的威力了。但在最开始那个时间点，我得告诉大家，而且得把这件事弄得足够简单。

所以我觉得整个演化逻辑是：最前面是技术进步，带动一部分领先者的 Mindset （ 思维 ）改变，当这部分人拿到实实在在的收益被其他人看到后，接下来的 Infra 和所有人的组织方式才会围绕它发生变化。我们的产品就是要在这种演化过程中，跟随并推动这种成长。

知危：会比较好奇，在 MiniMax，尤其是 Agent 产品的开发中，产品端和研发端是怎么合作的？

寻鹭：团队间的合作机制，主要分为两个层面。在产品与开发的合作中，Agent 团队内部的职责边界正在逐渐模糊。不同于传统互联网大厂由产品给出静态 PRD 后交付给固定开发团队进行交付、测试、上线的模式，目前的合作流程极大缩短了前置距离。产品人员也会直接参与 “ 搓 ” Expert、优化框架或产出 Vibe Coding Demo 等工作，这种协作方式更加灵活且紧凑。

以表单应用为例，很多时候是产品直接通过 Vibe 快速搭建出雏形，再由设计师接入调整样式，随后便直接上线。大家在 Agent 首页看到的许多表单应用、运营位应用以及 PGC Expert，其实并非出自开发之手，而是产品利用Cursor和高效协同模式快速实现的。而且有想法的开发人员也会针对特定场景提出很有价值的应用方案。所以至少在我们的团队里面，这个合作的模式正在消解传统的权责边界。

在分工上，大家依然保留着传统职能，比如产品经理仍会承担大量的竞品调研、用户研究以及 Query 分析等基础工作。但在处理具体的某个产品化 Feature，或是面对一些比较紧急的需求时，分工形式就与传统的互联网大厂不太一样。

阿岛：这种合作模式像是一种“分布式”的协作，虽然每个人在研发或产品等专业领域各司其职，但创意的边界是模糊的。关于产品方向和用户价值的 idea，大家都可以随时抛出来。比如在推出 Experts 框架时，研发端和产品段都感受到原先 Pro 框架的限制而想到了 Expert 这个 idea，技术端看到的是技术框架上的变化，而产品同学则能敏锐地将其转化为真正对用户有价值的落地方法。在具体执行上，研发会同步进行类似 “ 内部实习生 ” 的功能尝试，而产品和设计同学则可能直接通过 Vibe  coding 跑通前端，再由研发承接后续深度开发。

这种协作的结果是大家打破了原有领域的思维定式。因为 Agent 类产品具有 “ 技术与产品高度合一 ” 的特性，研发不能只钻研技术，产品也不能只考虑功能，双方都会有端到端的视野和双边思维。但是也都有各自擅长的地方，毕竟每个人的精力和擅长领域终究有限。

知危：那么 Agent 团队和模型团队的协作关系是怎样的？

阿岛：研发端与模型团队的合作，更多是提供应用层视角的认知与输入。目前模型面临的核心问题是评估与任务设定，而学术界的评估指标（ 如 SWE-bench ）并不能完全代表现实生活中的任务。例如上半年大家都在看 SWE-bench，但现在它已经趋于饱和，且更多代表的是 Bug fix 的能力，也就是从 80 分到 90 分的过程，而无法代表 Vibe Coding 这种从 0 到 1 构建项目、甚至增加 Feature 的能力，增加 Feature 更多代表从 10 分到 80 分的过程，难度显然大很多。

因此，Agent 团队会面向真实的内部用户场景去构建自己的 Benchmark。比如我们构建的 Benchmark 往往针对当前市面上所有 Agent 都做不好的挑战性任务（ 得分可能仅在三四十分左右 ）。这些任务并非凭空想象，而是从用户的真实痛点中发掘出来的。所以我们构建的 Benchmark 更能代表真实世界的分布，从而指引其转化为适合模型训练的标准。

以我们最近开源的 VIBE Benchmark 为例，它专门用于评估模型在全栈开发（ 包括 Web、移动端、桌面端 ）上的表现。这一成果结合了产品视角的输入与研发团队的专业深度，因为研发团队最懂服务端和 WEB/APP 开发的本质。

在 Vibe coding 开发能力的定义上，我们和模型团队共同确立了“全栈开发”的目标。这体现了双方的核心关系：模型任务与能力的定义必须具备用户视角，才能产生真正的生产价值；而模型能力的提升又直接支持了 Agent 的需求，使其做得更好。