* 本文原创发布于差评孵化的商业财经类帐号 " 知危 "
过去一年，AI 开始逐渐从 " 对话 " 向 " 行动 " 演进，技术走得很快，能够直接操作电脑，处理复杂任务的 " 桌面智能体 " 正成为新的技术前沿和竞争焦点。
2026 年 1 月 13 日，Claude 发布了 Cowork，成为第一个普通人能用图形界面操控电脑文件的 Agent；一个多星期后，MiniMax 发布 Agent 2.0 版本，定位 " AI 原生工作台 "，不仅上线了桌面端，支持 Mac 和 Windows，还推出了面向垂直场景的 " 专家模式 "。
桌面端的优势似乎显而易见：能操作大量本地文件，处理复杂长链路的任务，可能是真正深入人办公场景的最佳环境。但同时面临着诸如复杂环境适配，上下文更长，性能延迟和安全性等难题。我们想知道，行业是如何解决这些难题的，以及，桌面 Agent 到底能多大程度的深入到用户，还是成为一个产品过渡的自嗨模式？
知危与 MiniMax Agent 2.0 团队核心成员，研发负责人阿岛、产品负责人寻鹭进行了一场对话，他们从产品、技术、组织和行业等层面，详细地解答了我们的疑问，并且坦率地承认，" 现在，没有一家 Agent 企业敢说自己有壁垒。"
如果你是非 AI 从业者，这场对话会让你触碰未来，如果你是 AI 领域从业者，那这场对话一定是你不容错过的前沿思考。
以下是对话原文，知危进行了不改变原意的编辑。
：我们选择在此时上线并不是受同行发布的节奏影响，因为不可能在一周内赶出这种产品。
其实我们早在 2025 年 9 月初就有了 Expert（ 专家 ）模式和增加 Context（ 上下文 ）的想法，10 月份在内部推行 " Agent 实习生 " 验证成功后，12 月 15 日正式立项投入。
我们在大模型创业公司中算比较精干的， Minimax 的模型和产品线布局最广，涵盖三个模态及对应产品。尽管公司有 不到 400 人，但具体到每个产品上，我们可能都是以一对十（ 同行 ）的比例在作战。
比如这次的桌面端，实际上是 3 个同学用一个月的时间就开发出来的。整个 Agent 团队的研发力量非常精干，如果加上产品经理，总共也就 4 个人左右。
Agent 实习生目前已经在公司内部普及和扩散，成了大部分同事离不开的工具。
2.0 版本涉及更多的环境，从之前的网页端扩展到桌面端，可以利用本地工作区和更多文件来干活。
然后是质量上的提升，通过专家系统，无论是官方还是 UGC 做的，都能将专业知识和流程打包成专家 Agent，去高质量完成原本需要领域专家支持的任务。
2.0 版本源于我们公司的内部版本（ 内部称为 Agent 实习生 ）的外化，我们对 2.0 的定位是它能像助理或实习生一样，在工作流中完整地完成任务并交付结果。基于此，它需要延伸出获取充分 Context 的能力。比如内部同事办公场景下，Agent 需要能获取到内部各种 SaaS、IT、HR、财务、大数据，以及研发用到的监控、报警、代码仓库等所有软件工具的 Context。
第二个就是它需要具备相应领域的专业知识。换句话说，财务、人事、研发、GPU Infra、文本算法和视频算法的助理，它们之间非常不一样。只有做到这一点，助理在用户场景下才真正有用，能交付有价值且高度可用的任务结果。而不是说依然需要人类输入大量上下文并重度参与，交付出一个自动化程度低、不可用的结果。
从对外角度看，我们做桌面端是因为它是当前获取用户 Context 并操作环境的最佳方式，这样才能真正嵌入工作流，像助理一样帮用户交付结果。助理的特点是你交给它任务，它还你结果，你不需要时时刻刻盯着它，且你可以帮助它进步。第二点它是领域助理，这就是我们外化推出来的"专家"能力。以上这两个核心输入，也部分回答了 2.0 是如何生长出来的问题。
所以先后顺序是研发团队、产品团队、 GPU Infra 团队、 HR 团队、 投资和财务团队，最后是销售团队。我们的经验是，一套能让大家真正用起来且产生依赖的产品，必须具备本地环境、充分的 Context（ 上下文 ）、通过 OAuth 接入的云端环境，以及针对研发、HR、财务或销售等差异化需求所提供的 Expert 专业知识。
有了桌面端之后，用户可以直接选中文件夹进行操作。比如摄影师处理视频素材，或者用户盘里有八千张照片需要整理，直接操作本地文件夹比上传再下载八千张图片到网页端的流程要好得多。第二个桌面端解决的问题是，它能更好地实现浏览器托管场景，让 AI 模拟人的点击操作，在网页上完成重复动作。比如每天自动爬取 TikTok、Twitter 等热门社媒网站上对公司和产品的评价，并在发现负面信息时及时提醒。
这种场景如果放在 Web 端做，由于我们是通过沙盒来实现，加上 IP 洁净度等限制，很容易被拦截。但在桌面端启动浏览器时，它是可以用用户本身的浏览器来操作的，所以跑通网页托管的整个流程会更加流畅、自然。现在无论是自动监控社媒，还是自动发布帖子，都会比以前更加顺畅。
确实，现在操作速度还比较慢，包括像 ChatGPT Atlas 的操作也比较慢。浏览器托管的速度问题和它的理解效率问题，是大家一直需要去优化的方向。
对于手机端 APP ，我们一直做得比较轻，没有把专家模式等重模式搬上去。原因在于，我们观察到用户使用 Agent 的方式与常规 Chatbot 主打搜索、写作不同，它更多是 C 端用户在解决工作场景中长程、重复且繁琐的操作。这类任务时间跨度大，不是在手机上发起后能即时得到回答的用法，如果只是即时需求，用户也不需要求助 Agent。此外，在手机端操作网页或软件会受到系统及应用权限的严格限制，挑战更高，所以目前我们不太会触碰这一块。
但你不太可能在一个通用的沙盒里去满足各种各样需求。比如我们的服务对象如果是算法工程师或 Reddit 上 LocalLLaMA 社区的爱好者，他们机器上可能装了好几块 A100，这显然不是沙盒能解决的问题。如果希望 Agent 对专业用户在特定场景下真正好用，桌面端就有不可替代的优势，包括之前提到的 Context。
桌面端还有一个至关重要的优势：长期的 Context 沉淀与记忆构建。在桌面端，我们并不是只依赖用户指定的单个文件。随着 Agent 在用户电脑上运行时间的增长，它会越来越了解用户的上下文，并自动构建关于该用户及其工作环境的 Memory。很多时候，你甚至不需要重新上传或详细说明，只需给出指令，只要是你过去曾经操作过或存在于环境中的事情，它就能直接处理。这种深度环境感知和记忆积累是 Web 端无法实现的，因为 Web 端缺乏这种持续且原生的运行环境。
最后必须强调：今天 Agent 进步的最大瓶颈之一是 Agent Infra（ 可以简单理解为智能体的基础设施 ）。
但在你的本机，它就是你的个人电脑，代表你的个人身份。在这里操作浏览器或处理事务，身份对标非常明确，不会存在这方面的问题。
我们横向对比了所有获取网页信息的 Agent，无论是像 Browser Use 这样专业的、Manus 这样通用的，还是 ChatGPT、Claude Code 等。最终结果是，在 Cloudflare 这种网络安全服务商的反爬、反垃圾机制面前，成功率普遍不高。即便人类接管去点验证码插件，也很有可能因为被识别出不是真实的桌面环境而无法通过。这就是目前 Agent Infra 面临的现实挑战。
我个人的观点是，未来人类行为和基础设施都会面向 AI 重新组织，届时会有更不一样的形态和更好的方式来验证 Agent 的代理身份。但就目前而言，桌面端形态在这些方面是难以替代的。
而真正的 " 通用 " 应该是能够深入并覆盖各种专业场景。正是为了实现这种高阶的通用性，我们才必须开发 " 专家 " 能力和桌面端。因为只有深入到每个人的具体专业环境、调用高性能硬件并理解其特定的工作流，Agent 才能在各种垂直领域都把活儿干好。
换句话说，我们的目标是通过深度专业化的能力，最终达成真正意义上的、全场景的通用。
比如写公众号。在你的本地环境，Agent 可以内化你过往积累的大量素材、写作习惯和风格，并索引历史资料，在你写新文章时直接给出一个高度契合的初稿。这种深度的个性化能力，云端沙盒是无法实现的。相对而言，云端沙盒擅长的是那种完全脱离个人环境的任务，比如"去网上收集 100 双耐克鞋的信息"，只需要通用互联网访问能力。
这意味着它不能只靠一个死板的预设框架，而必须是一个优雅、灵活、可路由且可插拔的专家模式。举个例子，金融领域的 Deep Research 关注的是研报和实时行情数据；而法律领域则需要接入完全不同的判例数据库、法规接口，且国内外的法律逻辑也大相径庭。如果只用一个固定的通用框架，由于预接的 Data Source API 偏向性（ 比如偏金融 ），它在法律场景就无法深入。所以，我们现在的自定义模式允许用户叠加更多 " 专家 "，本质上是通过这种高灵活性的框架，在各个垂直领域实现真正的、深度的通用化交付。
增长的关键首先在于产品要达到极佳的效果并真正解决问题，其次要运营起相应的口碑和社群，建立良好的品牌，并基于实际的使用案例进行传播。
因此，我们的增长路径会更接近 Cursor 或 Lovable 等海外产品的成长模式。
针对垂直领域和专精 Agent，我们在获取用户和提升渗透率上面临挑战。因此，Expert 模式的下一个目标是产出更多 PGC 和 PUGC 内容，同时想办法激励更多 UGC 专家涌现。在这个过程中，我们希望用户是因为有一个明确的问题或特定领域的诉求来使用 MiniMax Agent，而不是拿到一个看似无所不能、却让人不知道该拿它来做什么的通用产品。
Cursor 和 Lovable 增长策略的核心点在于：首先抛开常规手段，最关键的是能抓取并定义一个极具潜力的新场景。这种对场景的创新定义能力，决定了其后续做 PUGC 增长时能够具备极高的初始势能，并在起步阶段就达成非常强悍的结果反馈。
另外，Base44 自建了一整套数据库和云端托管，基于这些观察，我认为增长的核心在于两点：产品定义足够新颖，能在初期形成强大的势能，产出极具说服力的结果。通过真实用户的 Use Case 进行口碑传播和扩圈，而非通过大规模买量吸引非核心用户。投流获取的流量往往伴随着高流失率，只有让核心用户带动的裂变，才能保证增长的质量和精准度。
要形成增长势能，首先需要明确核心场景。关于这一点，我们在海外已有明确的认知：海外用户在 Vibe Coding 以及视频、图文创意素材方面有极强的诉求，因此我们在 PGC Expert 的打造和引流方向上有清晰的指引。
在国内市场，由于 MiniMax Agent 上线相对较晚（ 去年 10 月上线，近期才正式增加交流与露面 ），目前我们仍处于对国内用户行为的分析与拆解阶段。
在未来一两周内，随着我们推出的 Expert 方向和新动作，大家会看到更清晰的思路。同时，我们也正通过观察目前逐渐沉淀下来的核心用户，研究如何进行转化，并学习如何借由他们深入国内特定场景，从而找到更适合国内环境的用户裂变点。
所以下周我们会做的一件事，就是通过增加示例 Query 和展示过往优秀产物，让用户对专家的能力有明确预期，知道类似的输入能得到什么样的结果。我们更倾向于站在 C 端产品的视角，通过优化交互和用户友好型的迭代，而不是靠一对一咨询的形式，来缩短用户与 AI 能力之间的距离。
最近我也面试过一些候选人，其中一位从 2023 年 GPT-3.5 阶段就开始做 Automation 和 Workflow，在当时算非常领先。但迫于生存压力，他们本想做通用的产品，最后只能转而成为垂直领域的信息爬取专家，比如做销售线索或简历筛选。最终他们搭建了一套深入行业的 Workflow，盈利表现不错，但规模也因此受限。如果他想切入另一个行业，就必须按照这个模式重新再做一遍。
所以，我们对未来的判断很明确：我们要选前者，而不是做后者。
我们公司不依赖那种规模受限的垂直生意，这是前置判断。其次，我们也不是要做一个无人问津的 " 阳春白雪 "，像寻鹭刚才提到的，我们认为走前者的路径，通过 Expert 模式、Agent 的自我进化以及 Agent Infra 的演进，能够获取足够的 Context 和 Memory，最终在用户领域做得越来越好。这不仅依赖于底层模型的进步，更取决于多模态理解模型（ VLM ）的突破。虽然现在浏览器操作慢、效果不佳是因为 VLLM 仍落后于大语言模型，但我们看到 VLLM 也在快速进步。归根结底，这在于是否相信 Scaling Law 和摩尔定律，如果相信，我们坚定选择前者。
如果跳出产品本身，从 AI 工具化的未来方向来看，企业自建 Agent 的现象确实会长期存在。任何具备资源和技术信念的企业，在意识到 Agent 能显著提效时，第一反应往往是观察外部方案随后拉起内部团队自研。这是一种正常的商业决策，尤其在涉及核心业务逻辑时。
如果是为了快速获得 PMF（ 产品与市场契合，产品马上就能出售获利 ），切入金融、医疗等垂直场景确实更高效。他们往往通过大量的模板、路由工程和固定的 Workflow 来保证稳定性，这在底层逻辑上可能并不是一个开放的 Agent 框架，而是一个深度的行业工具。
针对垂直与通用的争议，我们坚持深耕通用框架。我们的核心目标不是停留在表面的"万能"，而是通过构建一个更高阶、更稳健的底层框架，能够容纳并理解用户长期积累的复杂数据，而不仅仅是单次任务的片段信息，并且能够无缝深入到各种本地、云端甚至复杂的企业生产环境。
这种进化的成功取决于两个核心维度的交汇：一是人的接受度，即个体对 AI 等新事物的开放心态与驾驭能力；二是技术的成熟度，即模型与 Agent 性能的实质性飞跃。
即使在 MiniMax 这样的技术驱动组织中，资深工程师初期也会因为固有的经验路径而对 Cursor 等 AI 工具产生抵触与不信任。
因此，通用平台的发展不能只停留在浅层功能，而应支持用户在认知转变后实现深度的协作进化。我们内部推行 " AI First " 和 " Agent 友好 " 的原则，要求无论是研发、财务还是产品，都要主动将 Context 和知识体系结构化，确保 Agent 能够无缝获取信息并发挥巨大的效率杠杆作用。这种 " AI 原生 " 的工作习惯，让环境变得易于被 Agent 理解和调用，才是释放 AI 潜力的关键前提。
我们会打造这样一套产品和框架，去帮用户往这个方向实现，但前提是用户得有这个思维，得愿意这么做。这就像 Everett Rogers 提出的创新扩散理论里说的，从 Innovator（ 创新者 ）到 Early Adopter（ 早期采用者 ）有一个过程。
我们觉得现在还处于早期，大家的 Mindset（ 思维 ）在进步，能力也在进步。它一定会有个临界点，就是当能力进步到所有人无法忽视的时候。
拿我们团队举例，现在我根本不需要去建议任何一个同学用 Claude Code，大家已经深刻体会到它的威力了。但在最开始那个时间点，我得告诉大家，而且得把这件事弄得足够简单。
所以我觉得整个演化逻辑是：最前面是技术进步，带动一部分领先者的 Mindset（ 思维 ）改变，当这部分人拿到实实在在的收益被其他人看到后，接下来的 Infra 和所有人的组织方式才会围绕它发生变化。我们的产品就是要在这种演化过程中，跟随并推动这种成长。
以表单应用为例，很多时候是产品直接通过 Vibe 快速搭建出雏形，再由设计师接入调整样式，随后便直接上线。大家在 Agent 首页看到的许多表单应用、运营位应用以及 PGC Expert，其实并非出自开发之手，而是产品利用Cursor和高效协同模式快速实现的。而且有想法的开发人员也会针对特定场景提出很有价值的应用方案。所以至少在我们的团队里面，这个合作的模式正在消解传统的权责边界。
在分工上，大家依然保留着传统职能，比如产品经理仍会承担大量的竞品调研、用户研究以及 Query 分析等基础工作。但在处理具体的某个产品化 Feature，或是面对一些比较紧急的需求时，分工形式就与传统的互联网大厂不太一样。
这种协作的结果是大家打破了原有领域的思维定式。因为 Agent 类产品具有 " 技术与产品高度合一 " 的特性，研发不能只钻研技术，产品也不能只考虑功能，双方都会有端到端的视野和双边思维。但是也都有各自擅长的地方，毕竟每个人的精力和擅长领域终究有限。
因此，Agent 团队会面向真实的内部用户场景去构建自己的 Benchmark。比如我们构建的 Benchmark 往往针对当前市面上所有 Agent 都做不好的挑战性任务（ 得分可能仅在三四十分左右 ）。这些任务并非凭空想象，而是从用户的真实痛点中发掘出来的。所以我们构建的 Benchmark 更能代表真实世界的分布，从而指引其转化为适合模型训练的标准。
以我们最近开源的 VIBE Benchmark 为例，它专门用于评估模型在全栈开发（ 包括 Web、移动端、桌面端 ）上的表现。这一成果结合了产品视角的输入与研发团队的专业深度，因为研发团队最懂服务端和 WEB/APP 开发的本质。
在 Vibe coding 开发能力的定义上，我们和模型团队共同确立了"全栈开发"的目标。这体现了双方的核心关系：模型任务与能力的定义必须具备用户视角，才能产生真正的生产价值；而模型能力的提升又直接支持了 Agent 的需求，使其做得更好。
这也是为什么桌面端和网页端的记录没有同步，因为两者的工具和文件工作区是完全隔离的，这主要是出于安全和隐私的考虑。
针对本地执行命令行可能带来的安全挑战，我们主要通过产品设计和权限边界控制来应对。这并非新鲜课题，像 Cursor 等成熟 IDE 已有完备的机制。我们的设计参考了行业标准，尤其在处理权限申请时，会明确询问用户是 " 仅限本次允许 " 还是 " 始终允许 "。当 Agent 涉及操作未授权的文件夹、进入新的工作区，或执行之前未允许过的命令时，都会触发弹窗让用户进行 Double Check。目前我们拥有一个固定的高风险命令列表，并结合模型进行判断，未来还会根据用户反馈持续补充这一列表，进一步加强在安全和权限边界上的交互，确保 Agent 的行为在用户知情且可控的范围内。
技术上最核心的保护对象是数据。相比于容易通过程序命令备份和恢复的开发环境，数据的损失往往是不可逆的。因此，我们让大模型进行智能判断：首先，优先寻找可逆的操作方案来替代不可逆操作，比如用"移动到回收站"代替"直接删除"；其次，如果操作确实不可逆且无法替代，则判断是否可以先备份再执行。在完成这些前置逻辑后，模型会判断是否需要提示用户确认，并同步给出命令的解释以及存在的风险说明。
目前，" 移动到回收站 " 功能已在最新版本支持，服务端也已下发风险提示逻辑，前端 UI 正在紧锣密鼓地适配中。
首先是 AI Creator，对于不熟悉 Sub-agent、Instruction、Skills 或 MCP 配置的普通用户，我们提供了一个 AI 驱动的创建工具。用户只需提供非结构化的知识（ 如一段 SEO 专家的文本资料 ），AI 就能自动解析并完成复杂的后端配置。以 SEO 专家为例，AI Creator 可以自动将任务拆解并配置成三个协同工作的 Sub-agent，同时自动配齐对应的 Skill 和调度指令，明确它们之间如何协作。这种方式的优势在于，它迅速将用户的专业经验转化为可执行的 Agent 架构，而不需要用户具备任何技术背景。
AI Creator 的核心价值在于将复杂的 SOP 自动转化为最优架构。用户只需将已有的知识库或 SOP 发给 AI，它就能在我们这套功能强大但配置相对复杂的专家框架中，自动匹配出最优的 Sub-agent 组合、Skill 定义和指令集。用户无需手动编辑繁琐的文档或参数。
如果发现专家执行效果不佳，只需像聊天一样告诉 AI：" 它在某处处理得不好，帮我修改一下提取逻辑或解决方案。"
我们在制作 PGC 专家时也发现，最有效的调优方式并非手动改代码，而是通过对话引导 AI 迭代。因此，我们将这套内部实战经验沉淀到了 AI Creator 框架中，让普通用户也能以自然语言交互的方式，打磨出生产级别的专家。
除了 AI Creator，我们还提供了手动配置模式。这种模式特别适合有经验的 " 深度玩家 " 或已有积累的用户。如果用户此前在 Claude code 或其他 Agent 平台上已有成熟的 Prompt、Sub-agent 设定或 Skill（ 技能 ），可以直接 " 丢 " 进我们的框架中进行复用，实现无缝搬迁。
无论是 AI 自动生成的还是手动搬迁的专家，调优过程都极其简便。用户只需通过自然语言反馈，AI 就会辅助用户完成指令和逻辑的迭代优化。
但其实测试下来还算好。就像有用户问理解图片和视频会不会很费积分，其实这种理解类任务反而不太会，因为这类工具的消耗是比较容易控制的。
当然，如果是生成类任务，确实是另外一个量级，也跟任务复杂度直接挂钩。
除此之外，我们一直在优化积分消耗。比如之前为保证最终效果，一些环节会让 Agent 做大量的自动化测评，后来我们增加了 " 用户确认项 "，用户可以选择是完全交给 Agent 去跑测试，还是由自己来做测试并把观察到的点反馈给 Agent，从而更高效、更省积分地完成修改。
虽然积分消耗逻辑目前还比较初级，但我们会持续增加它的透明度和用户友好度。比如最近收到不少关于整理文件夹等场景的反馈，我们会不断优化这些具体场景的消耗速率。其实这跟我们内部做 Agent Benchmark 的逻辑是一致的：我们不会为了追求一个极致的结果而不计成本。在我们评估一套新框架时，除了看任务得分，也会严格考察任务时长和 Token 消耗：如果得分很高但 Token 消耗增加了 5 倍，那我们并不认为这是一个好的方案。
就像淘宝在电商时代通过支付宝这个创举，利用第三方托管解决了支付这一核心 Infra，电商的另一个核心 Infra 是履约，比如快递和电子面单，Agent 领域也需要类似的底层支撑。
所以，理想的 Agent Infra 应该是：首先是身份认证，要能像担保支付一样，确认 Agent 是安全且代表用户本人的。第二个是像电商履约链路一样，连接各种服务和 SaaS。这包括企业内部 SaaS 和用户常用的外部软件，比如 Notion、外卖、医疗、线上办公相关的文档、IM、邮件、日历，甚至财务系统和支付。
在有身份认证的前提下，信息提供方式也会改变。现在的网页是提供给人看的 HTML，未来也许会有专门提供给 Agent 的格式；或者随着 VLM 的进步，HTML 依然存在，但会从面向 SEO 优化转向面向 Agent 优化。比如为了让 Agent 快速导航，HTML 的标签需要变得更具语义化。
总结一句话，就是所有的基础设施、软件服务和人们的 Mindset，都将面向 AI 和 Agent 来重新定义和提供。我坚信这件事情一定会发生。
以制作视频为例，如果用一个 Single Agent 挂载所有 Skills 来做，效果会很差：首先它的上下文会 " 爆炸 "，其次满载了各种杂乱信息的上下文会分散它的注意力，工具集也会变得非常臃肿，很难把活儿干细。采用 Sub-agent 结构的好处就在于 " 专注与共享 "，比如你可以把导演、脚本分镜、素材生成、后期剪辑分别交给不同的子 Agent。虽然它们各司其职，但因为共享同一个工作区，并且都能调用 Memory 工具，所以它们能拥有同样的上下文记忆。这种模式既保证了信息的同步，又让每个子 Agent 能够专注于自己的专业环节，把事情做得更深、更好。
此外，因为每个 Sub-agent 拥有独立的 Context Window，不容易触发上下文压缩总结。大家应该都知道，一旦触发压缩，模型就非常容易 " 降智 "。其次是Sub-agent 具备不可替代的 " 并发能力 "。比如你需要同时创作 3 个分镜，或者同时调研 10 家上市公司。如果你只用一个 Single Agent 配一堆 Skills，它只能像排队一样一家一家做过去，既慢又做不深。
所以这两点最关键：一是专注，通过上下文隔离让任务做得更深、更好；二是能更好地处理并发。
那么 Skills 适合什么场景呢？Skills 适合那种不需要做得特别深、一个任务就解决一件具体事情的场景。比如说，帮我处理一个 Excel，具体用什么 Python 函数，或者需要什么样的 Excel 风格。所以 Skills 这种形式，它更像是一个知识库动态加载的 System Prompt。
当一个 Agent 在处理一件事（ 比如文档处理 ）时，它可能会面临不同的情况，一会儿是 Excel，一会儿又是 PDF 或 Word。这种时候你根据需要去动态加载对应的能力，一次只做一件事，就很合适用 Skills。
对于外部用户，并非所有企业的数据都在即时通讯工具里，云端可能更多起备份作用。
桌面端是我们拓展 Context 和环境的第一步，将 Web 端需要手动上传的形式转变为可以直接操作本地文件，这对于很多小型机构或个人来说已经是非常大的进步，因为他们的资料往往还是存在本地电脑里。
未来我们也希望能利用更多应用和云盘里的上下文环境，这也是我们后续追求的目标。
我们内部目前是通过 API 封装来实现深度接入的。针对企业级场景，我们考虑以 ToB 模式应用，因为这需要企业管理员提供密钥授权才能调用 API。对于像 Notion、Slack 这种 OAuth 或 MCP 授权已相对成熟的平台，我们会尽快接入。我们的终极目标是接入用户所有的 Context。这正是我提到的 Agent Infra 的构建过程：不仅是 Agent 应用层的努力，更是整个行业甚至线下服务（ 如麦当劳的点餐 MCP ）向 AI 进化的过程。我们将尽可能全、尽可能快地接入这些能力。
这需要所有组织达成共识，认同 Agent 的价值，并齐心协力开放工具、API 和权限接口。因此，Context 的获取分为两步：第一步是努力接入已有的 API 或 MCP 开放应用；而更难的第二步则是，当常用的 SaaS 接入完成后，进一步深入将不再仅仅是软件或技术问题，而是涉及到组织架构与企业管理的深层挑战。
核心在于该公司的基础设施（ Infra ）是否对 Agent 友好，以及组织管理上是否乐于拥抱 " 由 AI 替代人工节点 " 的形式。
以数据分析为例，在我们内部，数仓平台与飞书 OAuth 完全打通，权限体系和使用流程非常顺畅，这使得从 Text-to-SQL 到自动生成报告的闭环效率极高。这种顺畅源于我们数据环境相对纯粹，且组织逻辑上更倾向于用 AI 解决问题。
将这一套 Agent 经验平移至大公司时，会面临显著的现实挑战：首先是存量组织与流程的惯性，大公司往往已有成熟细致的人工团队和固定流程，在资源充足的情况下，替代动力可能不如初创公司迫切；其次是系统碎片化与权限复杂度，大厂内部不同部门、组织间的平台与工具往往高度割裂，难以统一接入，导致开发适配 Agent 的基础设施周期漫长，且权限控制极其复杂，极大增加了面向 " Agent 友好 " 工具转换的难度。
还有一个现实痛点：ROI（ 投入产出比 ），在大公司维度下，当人力资源相对充足时，管理层会权衡：投入大量研发资源去开发工具接口、梳理复杂的权限边界以及界定责任归属，其最终带来的效率提升是否值得？这种涉及权限体系重构和责任控制的决策，往往很难在短期内快速推进。
即使去问大厂做 Agent 的团队，或者在 Demo Day 上问那些做 Agent 的团队，也没有人能很好地回答这个问题。大家可能会说有某个行业的 know-how、能把垂直领域做深，或者有好的客户关系能推到企业里，但这些其实都不构成壁垒，大家一定会互相 overlap。所以从我们的角度来说，只能说我们想得更深，做得更新，并且把它落地得更快。
不管是 Anthropic、Gemini 还是 OpenAI，他们之间都没有壁垒。Claude 3.0 做得很差，但 3.5 专注编程方向做出来了，到 4.0 的时候结合 Claude Code 更是惊艳；大家本也以为 Gemini 很差，结果 Gemini 3 也是专注 Vibe Coding 追了上来起来。目前 OpenAI 的领先优势正被不断蚕食。未来如何发展谁也没法预料。
本质上，在一个技术的快速上升期，除非技术停滞，否则没有任何人能够拥有壁垒。唯一的壁垒就是你有没有组织优势：有没有相应的人才能保持足够强的认知，有没有相应的底层 Infra，以及整个团队去执行和实现它的技术能力。这其实就是 Anthropic 和 Gemini 能追上来的原因。比如 Gemini，最根本原因的是创始人直接下场写代码，如果没有这一点，其他努力都是白费心机。
其中关于 Agent 的 " 记忆 " 功能，正处于规划阶段。展开做 Memory 其实有很多维度：是做长期的、全局的记忆，还是针对特定对话的、可快速清洗和编辑的短期记忆？是侧重于用户的人格画像、专业领域画像，还是基于用户工作流中沉淀的 Knowledge、SOP 以及工具使用习惯？这背后涉及非常多样的更新和清洗机制。目前我们还在内部权衡各种做的方法和维度，等之后正式上线，我们会有一个更清晰的形式来向大家说明这套机制具体是如何 Work 的，以及它如何帮助大家更高效地使用 Agent 来解决问题。
第二个方向是主动性，在我们内部实践中，Agent 任务的触发可以通过 Trigger 的方式主动运行，但现在的产品还是需要你输入一段东西，或者至少设一个定时任务它才能执行，还没有那么 Active，缺乏主动性。所以后续我们也想在接入更多应用后，能够基于一些 Webhook 技术去触发 Agent 做更加主动的行为，而不是让它只是在界面上等待你给它输入命令。
第三个方向是会让它更易用。我们发现，这种复杂的 Agent 要在更多场景达到 production ready，对用户的友好性非常重要。举个例子，之前用户不一定能准确描述需求，或者只有一个模糊的想法，我们会有一个 clarification 的环节向他澄清意图。以前这个环节只是抛出一个 Markdown 渲染的大长段文字，正常用户看到要回答七个问题，很难手打大段文字说明需求。但今天我们做了 Generative UI，并设计了一些规范，让 Agent 在这种情况下出的是表单形式。原来的五六个问题变成了三步表单，你只需要点选，它就能根据指令做下一步任务，不需要再用文字回答。通过这种友好的交互，让用户提供更多需求并澄清意图，能让我们最后出来的结果更贴合用户的需要。
最后是提供更多的 PGC 和 PUGC 的 Expert，我们也会进一步鼓励 UGC 的生态。我们终归希望用户来用的时候，不是面对一个好像能解决所有问题的通用 Agent，而是带着自己明确要解决的问题。
在具体技术趋势上，无论是做 Desktop 还是接入各种 OAuth，我们都希望获得更多 Context 并构建 Memory，让用户越用越顺手，甚至包括自动提示用户去生成专家，这源于 Agent 能够自进化。
确实，Agent 的下一个重要方向将是自举（ Self-bootstrapping ）与自我进化。即 Agent 不仅能为用户创造专家，还能根据反馈自我改进。
我们希望达到的下一步目标是：Agent 能够主动观察用户的满意度，并在发现表现不佳时，主动提议具体的修改点。这代表着 Agent 不再是一个 " 死 " 的配置，而是一个能与用户不断互动、在工作流中实时进化的实体。以代码编写为例，它能自动纠正那些繁琐的格式错误，而不需要人类反复叮嘱。
目前，我们公司内部处理用户反馈和问题的流程已经由 Agent 自己完成并给出建议。所以，我们正在推进的下一步，就是让 Agent 根据这些反馈自动优化自身。
虽然行业内目前仅有一部分人意识到这一点，但这将是 Agent 真正深度融入人类生产力的关键。
（ 访谈全文完 ）
撰文：流大古 & Rick
编辑：大饼
如果您觉得本文还不错
欢迎关注差评孵化的商业财经类账号：知危（ ID:BusinessAlert ）
