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

知危：桌面 Agent 是比较新颖的产品形态，又涉及用户的私人数据输入，用户难免会有存储安全和隐私安全方面的担忧，MiniMax 如何解决这些安全隐患？

寻鹭：MiniMax Agent 的运行时（ Agent Loop ）以及与大模型的交互是在云端进行的，但它的所有工具环境包括命令行执行、本地文件读取、文件操作以及浏览器操作全都在用户的本地完成。

这也是为什么桌面端和网页端的记录没有同步，因为两者的工具和文件工作区是完全隔离的，这主要是出于安全和隐私的考虑。

针对本地执行命令行可能带来的安全挑战，我们主要通过产品设计和权限边界控制来应对。这并非新鲜课题，像 Cursor 等成熟 IDE 已有完备的机制。我们的设计参考了行业标准，尤其在处理权限申请时，会明确询问用户是 “ 仅限本次允许 ” 还是 “ 始终允许 ”。当
Agent 涉及操作未授权的文件夹、进入新的工作区，或执行之前未允许过的命令时，都会触发弹窗让用户进行 Double
Check。目前我们拥有一个固定的高风险命令列表，并结合模型进行判断，未来还会根据用户反馈持续补充这一列表，进一步加强在安全和权限边界上的交互，确保
Agent 的行为在用户知情且可控的范围内。

阿岛：从技术层面看，我们对命令安全性的控制主要关注其是否具有破坏性或不可逆性。首先通过基于规则的第一层过滤，确保高召回率以兜底风险，但可能覆盖不全、没那么灵活或有一定的误伤概率；其次通过大模型智能判断进行第二层识别以提高准确率。

技术上最核心的保护对象是数据。相比于容易通过程序命令备份和恢复的开发环境，数据的损失往往是不可逆的。因此，我们让大模型进行智能判断：首先，优先寻找可逆的操作方案来替代不可逆操作，比如用“移动到回收站”代替“直接删除”；其次，如果操作确实不可逆且无法替代，则判断是否可以先备份再执行。在完成这些前置逻辑后，模型会判断是否需要提示用户确认，并同步给出命令的解释以及存在的风险说明。

目前，“ 移动到回收站 ” 功能已在最新版本支持，服务端也已下发风险提示逻辑，前端 UI 正在紧锣密鼓地适配中。

知危：不只是普通用户，即便对于专家级用户，在 Agent 2.0 中构建 “ 专家 ” 可能也不是容易的事情，或者会很繁琐，确实有门槛，MiniMax 如何让用户更轻松地构建“专家”？

阿岛：针对如何帮助用户基于长期积累的 Context 生成专家，我们目前主要提供两种路径，重点解决配置门槛问题。

首先是 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 就会辅助用户完成指令和逻辑的迭代优化。

知危：接入本地计算机 Context，会带来推理成本暴增吗？

寻鹭：确实，大家可能会担心 Agent 场景因为接入了用户个人电脑的数据，输入量变大，成本会比以前的产品高很多。

但其实测试下来还算好。就像有用户问理解图片和视频会不会很费积分，其实这种理解类任务反而不太会，因为这类工具的消耗是比较容易控制的。

当然，如果是生成类任务，确实是另外一个量级，也跟任务复杂度直接挂钩。

阿岛：本地环境的 Context 并不会导致上下文暴增。虽然用户本地可能有很多数据，比如一个一万字的文档，但我们的 Agent 并不是简单地一次性读入这整整一万字。它会根据用户的具体意图，更多地通过检索的形式去获取最相关的段落。所以，在本地处理数据，本质上并不会比其他场景产生更大的消耗差异或负面影响。

知危：说实话，用户真的不好判断积分（ 使用 2.0 会有积分的消耗 ）的消耗情况，这不是单纯以 token 多少付费。

寻鹭：官方这边也一直在持续优化消耗速率，目标是让用户的任务能在一个
ROI 比较高的区间内完成。比如下周我们要发布的一个功能就是做模式的 Routing。因为很多时候任务复杂度不高，Agent
完全可以自动调用“高效模式”快速搞定，不一定非要调用昂贵的 Pro 模式。

除此之外，我们一直在优化积分消耗。比如之前为保证最终效果，一些环节会让
Agent 做大量的自动化测评，后来我们增加了 “ 用户确认项 ”，用户可以选择是完全交给 Agent
去跑测试，还是由自己来做测试并把观察到的点反馈给 Agent，从而更高效、更省积分地完成修改。

虽然积分消耗逻辑目前还比较初级，但我们会持续增加它的透明度和用户友好度。比如最近收到不少关于整理文件夹等场景的反馈，我们会不断优化这些具体场景的消耗速率。其实这跟我们内部做 Agent Benchmark 的逻辑是一致的：我们不会为了追求一个极致的结果而不计成本。在我们评估一套新框架时，除了看任务得分，也会严格考察任务时长和 Token 消耗：如果得分很高但 Token 消耗增加了 5 倍，那我们并不认为这是一个好的方案。

知危：您多次强调 Agent Infra 的重要性以及对当前 Agent 发展的限制，行业当前现状到底是怎么样的，距离理想状态还有多远？

阿岛：Agent
Infra 目前确实还处于非常早期的状态。首先从协议标准和交互方式的角度，在我看来，MCP 也不是一个特别完备的定义，其实并不特别适合
Agent，我相信还会有新的标准出现，大家也在不断尝试。另外一个角度是大家要提供面向 Agent 的能力，这种能力可以是
MCP，也可以是一个更完备的定义，比如带有脚本和 API 的 Skill，核心是这些能力要能提供出来。

就像淘宝在电商时代通过支付宝这个创举，利用第三方托管解决了支付这一核心 Infra，电商的另一个核心 Infra 是履约，比如快递和电子面单，Agent 领域也需要类似的底层支撑。

所以，理想的 Agent Infra 应该是：首先是身份认证，要能像担保支付一样，确认 Agent 是安全且代表用户本人的。第二个是像电商履约链路一样，连接各种服务和 SaaS。这包括企业内部 SaaS 和用户常用的外部软件，比如 Notion、外卖、医疗、线上办公相关的文档、IM、邮件、日历，甚至财务系统和支付。

在有身份认证的前提下，信息提供方式也会改变。现在的网页是提供给人看的
HTML，未来也许会有专门提供给 Agent 的格式；或者随着 VLM 的进步，HTML 依然存在，但会从面向 SEO 优化转向面向
Agent 优化。比如为了让 Agent 快速导航，HTML 的标签需要变得更具语义化。

总结一句话，就是所有的基础设施、软件服务和人们的 Mindset，都将面向 AI 和 Agent 来重新定义和提供。我坚信这件事情一定会发生。

知危：专家的提示词设计有两点值得注意，一个是专家下还会设置 Sub-agent，这种双层结构的好处是什么？

寻鹭：这种 Sub-agent 结构和单一 Agent（ Single Agent ）或 Skills 的模式相比，核心好处在于：子 Agent 更适合处理那些领域性强、非常具体的任务。子 Agent 可以被看作是一个专注特定领域的 “ 小专家 ”，它能够配备专属于这一块任务的工具和 Skills。Skills 并不是只能挂在最上面那一层，子 Agent 同样可以拥有自己的 Skills。

以制作视频为例，如果用一个 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。

寻鹭：Agent 与 Sub-agent 之间并非只有单纯的并行执行，而是支持基于 SOP 的序贯协作。以深度调研（ Deep Research ）场景为例，系统会先启动调研
Agent 生成多份分散文档，随后由报告专家接手进行整合并添加图表，最后交给排版专家输出精美的 PDF 或 Word
格式，形成一条完整的流水线。至于更高自主性的多智能体交流，也有一些例子，例如国外的 “ 德州扑克 ” 专家或国内未来可能考虑上线的 “ 狼人杀
”、“ 打麻将 ” 等应用，通过在指令中设定游戏规则，多个智能体可以在规则框架下进行互相交流、对抗或协作。用户既可以作为旁观者观察这套 “
赛博生态 ”，也可以作为玩家参与其中。

知危：另一点是，提示词 Token 数限制是 5 万，但一般在此规模上下文下，模型表现会受限不是吗？

阿岛：对于设定 5 万 token 的高上限，核心逻辑是不希望人为在框架层面限制用户，尽管模型表现可能在这个量级可能受到影响。在产品设想中，用户基本不会手写如此冗长的提示词，而更多是由 Agent 自动生成并分配关于这部分内容是初始加载，动态加载 Skills，还是放入 Sub-agent 运行。

：设定一个非常大的上限，也是为了兼容复杂的业务场景。例如在需要同时调度
10 个 Sub-agent 的情况下，Instruction 需要详细规定各 Agent 的并行调用逻辑或执行顺序。以 PGC Expert
中的“热点追踪”为例，即便经过压缩，其指令量依然巨大，因为它涉及五六个
Sub-agent，执行中间需要并行对挖掘出的热点话题再做一轮深度研究。但在大多数情况下，如果通过 AI Create
的方式生成指令，token 数通常会自然维持在 5000 左右。

知危：目前Agent 2.0的PGC、PUGC专家中，复杂度比较高的专家实例是什么？

寻鹭：我们海外应用端有一个炒股专家实例，融合了两个热门
GitHub 项目：Trading agents 与 AI hedge fund。首先是 Trading agents
负责的精细化调研阶段，它会抓取海量价格数据、分析各项技术指标并实时监测市场舆情。紧接着进入 AI hedge fund 模式，该流程内嵌了 18
个风格迥异的投资专家（ 如侧重 PE 比率、不同风险偏好或长期持有逻辑等 ），随后由 18 个专家组成 “ 议会 ” 进行内部磋商并投票决策买入与退出时机；最后，由风险专家和管理专家把控全局，并输出高质量的结项汇报。

阿岛：比如我们以 “ 英伟达能不能买 ” 等具体问题为切入点，通过详细调研后，由类似设定好的 “ 巴菲特 ”、“ 芒格 ”、“ 彼得·林奇 ”、“ 木头姐 ” 等 9 位大师组成模拟议会。每位大师根据各自的投资风格（ 如价值投资、成长性分析或风险对冲 ）给出具体的买入/卖出建议、仓位配比以及格式化的逻辑分析。这种模式比盲目满仓更理性，能有效通过多维度分析规避风险。实际测试中，大师们的集体判断往往比个人主观判断更具参考价值，能够帮助理财小白避免掉坑。

知危：我们观察桌面端可能还存在 Context 完整性的限制，比如有些企业的数据可能基本都在云办公软件中，MiniMax 打算如何克服这种限制？

寻鹭：其实在公司内部，我们其实有一个在飞书里运行的 Agent 实习生，只要飞书开放 API 就能较好地接入。

对于外部用户，并非所有企业的数据都在即时通讯工具里，云端可能更多起备份作用。

桌面端是我们拓展 Context 和环境的第一步，将 Web 端需要手动上传的形式转变为可以直接操作本地文件，这对于很多小型机构或个人来说已经是非常大的进步，因为他们的资料往往还是存在本地电脑里。

未来我们也希望能利用更多应用和云盘里的上下文环境，这也是我们后续追求的目标。

阿岛：实际上，我们已经有同事正在开发支持
OAuth 协议的功能，希望实现与其他 SaaS 软件的便捷接入。只要这些 SaaS 软件提供了相应的接口，比如通过 MCP或 OAuth
协议，都可以进行接入。但坦白说，目前像飞书等平台的 MCP 支持还不是特别完善。

我们内部目前是通过
API 封装来实现深度接入的。针对企业级场景，我们考虑以 ToB 模式应用，因为这需要企业管理员提供密钥授权才能调用 API。对于像
Notion、Slack 这种 OAuth 或 MCP 授权已相对成熟的平台，我们会尽快接入。我们的终极目标是接入用户所有的
Context。这正是我提到的 Agent Infra 的构建过程：不仅是 Agent 应用层的努力，更是整个行业甚至线下服务（ 如麦当劳的点餐 MCP ）向 AI 进化的过程。我们将尽可能全、尽可能快地接入这些能力。

寻鹭：获取更多
Context 确实面临巨大挑战。目前我们讨论的仍是具备 API
或能下载到本地操作的工具。但在大型企业中，数据仓库分布在不同平台，且出于隐私安全往往不对外开放。在这种情况下，很多在小环境跑得通的数据分析场景在大型组织里根本无法实现，因为无法打通各个孤立的平台。

这需要所有组织达成共识，认同 Agent 的价值，并齐心协力开放工具、API 和权限接口。因此，Context 的获取分为两步：第一步是努力接入已有的 API 或 MCP 开放应用；而更难的第二步则是，当常用的 SaaS 接入完成后，进一步深入将不再仅仅是软件或技术问题，而是涉及到组织架构与企业管理的深层挑战。

核心在于该公司的基础设施（ Infra ）是否对 Agent 友好，以及组织管理上是否乐于拥抱 “ 由 AI 替代人工节点 ” 的形式。

以数据分析为例，在我们内部，数仓平台与飞书 OAuth 完全打通，权限体系和使用流程非常顺畅，这使得从 Text-to-SQL 到自动生成报告的闭环效率极高。这种顺畅源于我们数据环境相对纯粹，且组织逻辑上更倾向于用 AI 解决问题。

将这一套 Agent 经验平移至大公司时，会面临显著的现实挑战：首先是存量组织与流程的惯性，大公司往往已有成熟细致的人工团队和固定流程，在资源充足的情况下，替代动力可能不如初创公司迫切；其次是系统碎片化与权限复杂度，大厂内部不同部门、组织间的平台与工具往往高度割裂，难以统一接入，导致开发适配
Agent 的基础设施周期漫长，且权限控制极其复杂，极大增加了面向 “ Agent 友好 ” 工具转换的难度。

还有一个现实痛点：ROI（ 投入产出比 ），在大公司维度下，当人力资源相对充足时，管理层会权衡：投入大量研发资源去开发工具接口、梳理复杂的权限边界以及界定责任归属，其最终带来的效率提升是否值得？这种涉及权限体系重构和责任控制的决策，往往很难在短期内快速推进。

知危：现在各家厂商都很卷，也有很多厂商先行做出了桌面端，那么MiniMax如何在当前形势下构建自己的竞争壁垒？

寻鹭：在去年没有那么多团队做 Agent 的时候，可能某些团队还能说自己有一些壁垒，但到了今年，坦白说没有任何一个团队有壁垒。

即使去问大厂做
Agent 的团队，或者在 Demo Day 上问那些做 Agent 的团队，也没有人能很好地回答这个问题。大家可能会说有某个行业的
know-how、能把垂直领域做深，或者有好的客户关系能推到企业里，但这些其实都不构成壁垒，大家一定会互相
overlap。所以从我们的角度来说，只能说我们想得更深，做得更新，并且把它落地得更快。

阿岛：如果模型都没有壁垒，怎么期盼一个 Agent 有壁垒？

不管是
Anthropic、Gemini 还是 OpenAI，他们之间都没有壁垒。Claude 3.0 做得很差，但 3.5 专注编程方向做出来了，到
4.0 的时候结合 Claude Code 更是惊艳；大家本也以为 Gemini 很差，结果 Gemini 3 也是专注 Vibe
Coding 追了上来起来。目前 OpenAI 的领先优势正被不断蚕食。未来如何发展谁也没法预料。

本质上，在一个技术的快速上升期，除非技术停滞，否则没有任何人能够拥有壁垒。唯一的壁垒就是你有没有组织优势：有没有相应的人才能保持足够强的认知，有没有相应的底层
Infra，以及整个团队去执行和实现它的技术能力。这其实就是 Anthropic 和 Gemini 能追上来的原因。比如
Gemini，最根本原因的是创始人直接下场写代码，如果没有这一点，其他努力都是白费心机。

知危：Agent 2.0 的下一步是什么？

阿岛：我们会有多个主要努力的方向。第一个方向，是继续完善桌面端设计、做 Experts，涉及 Knowledge 和 Memory 机制的构建，也会涉及思考如何通过 Computer Use 接入更多应用。

其中关于
Agent 的 “ 记忆 ” 功能，正处于规划阶段。展开做 Memory
其实有很多维度：是做长期的、全局的记忆，还是针对特定对话的、可快速清洗和编辑的短期记忆？是侧重于用户的人格画像、专业领域画像，还是基于用户工作流中沉淀的
Knowledge、SOP
以及工具使用习惯？这背后涉及非常多样的更新和清洗机制。目前我们还在内部权衡各种做的方法和维度，等之后正式上线，我们会有一个更清晰的形式来向大家说明这套机制具体是如何
Work 的，以及它如何帮助大家更高效地使用 Agent 来解决问题。

第二个方向是主动性，在我们内部实践中，Agent
任务的触发可以通过 Trigger 的方式主动运行，但现在的产品还是需要你输入一段东西，或者至少设一个定时任务它才能执行，还没有那么
Active，缺乏主动性。所以后续我们也想在接入更多应用后，能够基于一些 Webhook 技术去触发 Agent
做更加主动的行为，而不是让它只是在界面上等待你给它输入命令。

第三个方向是会让它更易用。我们发现，这种复杂的
Agent 要在更多场景达到 production
ready，对用户的友好性非常重要。举个例子，之前用户不一定能准确描述需求，或者只有一个模糊的想法，我们会有一个 clarification
的环节向他澄清意图。以前这个环节只是抛出一个 Markdown
渲染的大长段文字，正常用户看到要回答七个问题，很难手打大段文字说明需求。但今天我们做了 Generative UI，并设计了一些规范，让
Agent
在这种情况下出的是表单形式。原来的五六个问题变成了三步表单，你只需要点选，它就能根据指令做下一步任务，不需要再用文字回答。通过这种友好的交互，让用户提供更多需求并澄清意图，能让我们最后出来的结果更贴合用户的需要。

最后是提供更多的 PGC 和 PUGC 的 Expert，我们也会进一步鼓励 UGC 的生态。我们终归希望用户来用的时候，不是面对一个好像能解决所有问题的通用 Agent，而是带着自己明确要解决的问题。

阿岛：长期来看，我们未来的目标是做一个像个人助理一样的产品，能在生产力场景的
Context 和 Workflow
里为用户交付真正有价值的结果，让用户感觉真的多了几个助理和实习生，自己不用再去干那些琐碎重复的事情，可以专注于更有创意和创造力的事情。我们相信这最终能为用户极大提效，让用户离不开它，我们也得到相应的回报。

在具体技术趋势上，无论是做 Desktop 还是接入各种 OAuth，我们都希望获得更多 Context 并构建 Memory，让用户越用越顺手，甚至包括自动提示用户去生成专家，这源于 Agent 能够自进化。

确实，Agent 的下一个重要方向将是自举（ Self-bootstrapping ）与自我进化。即 Agent 不仅能为用户创造专家，还能根据反馈自我改进。

我们希望达到的下一步目标是：Agent 能够主动观察用户的满意度，并在发现表现不佳时，主动提议具体的修改点。这代表着 Agent 不再是一个 “ 死 ” 的配置，而是一个能与用户不断互动、在工作流中实时进化的实体。以代码编写为例，它能自动纠正那些繁琐的格式错误，而不需要人类反复叮嘱。

目前，我们公司内部处理用户反馈和问题的流程已经由 Agent 自己完成并给出建议。所以，我们正在推进的下一步，就是让 Agent 根据这些反馈自动优化自身。

虽然行业内目前仅有一部分人意识到这一点，但这将是 Agent 真正深度融入人类生产力的关键。