MiniMax 怎么做 Agent：Model-Harness 协同只是第一步，还有 Inference-Harness 协同

模型即产品，今天已经发展成模型即 Agent 了。

模型公司做 Agent 独特的优势在于：它能把 agent harness 和模型推理放在同一个团队里协同设计。Harness 端的每一个决策，system prompt 怎么写、tool calling 怎么组织、错误怎么处理，都直接影响推理端的缓存命中率、调度效率和 token 消耗。

MiniMax 过去这一年的 agent 实践，并不是一步到位的。它最初只是一个内部飞书 bot，随后逐步演化为桌面应用 MiniMax Code，最终跑通了一条“训练—服务”闭环：模型先在自己的 harness 里完成训练，再通过 harness 去服务用户，而用户的实际行为又会沉淀成训练信号，继续反哺下一轮模型。这套闭环，说到底，就是模型公司设计 Agent 时最核心的那层逻辑。

模型公司怎么看待 model-inference-harness-agent 之间的关系，MiniMax DevRel 负责人 Vincent 在 AGI Playground 2026 上的演讲，分享了他们在 Agent 层面的实践和心得。

编译整理自大会演讲，内容经编辑调整。

01

MiniMax Agent，

起源于内部的 Agent 实习生

今天要分享的是，我们在模型实验室内部是怎么看待 agent 的。

模型就是我们的产品，这一点没变过。但问题是，模型公司为什么还需要 agent？怎么设计自己的 agent？我们做了一年，走过了几个阶段。

最早是去年五六月份，我们做了一个云端 agent（agent.minimax.com），跟 Manus 类似，有自己的 Linux 沙箱和虚拟机，能帮用户做网站。用的是传统 tool calling，但已经能操作沙箱、运行 shell 脚本了。那个更像 demo。

真正让 agent 在公司内部扎根的，是我们叫「Agent 实习生」的东西。它以 bot 的形式在我们的日常办公软件里透出。Agent 实习生从一开始就不只是给工程师用的，公司里所有人都在用它--工程、HR、市场、财务。

销售每天都要面对来自不同国家的潜在客户，消息内容还不能千篇一律，几乎每一条都得重新斟酌。于是，他干脆让 Agent 实习生先去研究每个人的背景，再翻一翻对方过去发过什么内容，最后生成更贴合场景的个性化文案。设计师那边的用法则更直接。她们用 Cursor 做 vibe coding，把设计还原过程中卡住的问题直接放到代码分支里解决，再提交给前端同学。产品和客服的场景更杂一些，Agent 实习生会帮产品经理处理用户投诉邮件，查后台任务 trace，判断积分消耗是否合理，顺手给出退还比例建议，然后把邮件发出去执行。计算平台的同事也频繁用它来分析告警——毕竟大模型推理相关的告警指标变化太快了。数据分析的同事则表示，它已经替代掉传统写 SQL 的那部分工作；HR 用它来搜学校、筛简历，效率直接翻了 10 倍。还有人干脆拿它自动写代码：需求列表一整理完，agent 就自己全自动往下写实现。

我觉得最有意思的一个变化是心态上的。有个工程师说得很好：「我们可能做的就是让 agent，让我们的实习生去创造一个能干这件事情的实习生。」它不再是一个工程师了，相当于是一个 leader。虽然我们现在叫它实习生，但我们觉得某一天它就会像一个数字员工一样。

这些内部实践推动了下一步。我们发现云端 agent 不够用——很多工作流实际上在本地电脑上。所以我们把它做成了桌面应用，发布为 MiniMax Code，能控制用户的电脑，但不需要是工程师才能用。

同时我们也发现 M2 系列模型，特别是 M2.1 和 M2.5，跟第三方开源 harness 配合效果很好，主要是 OpenClaw 和 Hermes。我们跟这些社区合作很紧密，优化了模型在它们里面的表现。这背后的原因是，MiniMax 的模型是通用型的，不只是编程或数学好，也擅长操作电脑、做管理性任务，加上性价比高。

这就到了今天：我们的新模型 MiniMax M3，以及 MiniMax Code。

02

Agent 怎么帮模型优化和迭代？

讲 agent 怎么帮训练和服务之前，先解释一个简单的问题：一个基础模型公司到底在做什么？归根到底就两件事——训练模型，然后把模型服务出去。

训练的输入是算力、数据、gyms（训练环境）和训练算法。服务的输入是算力加推理算法。不是说有了模型权重和几块 GPU 就能把模型服务出去，推理服务背后有大量困难的工程。

Agent 在这里面的位置分两种。直接的方式是让模型帮我们做研发，写更好的训练算法，写更好的推理算法。

先说直接的。我们在 M2.7 发布时分享过，post-training 团队的工作流大致分五步，其中运行实验和分析实验这两步，可以完全由 M2.7 自主完成。剩下的步骤虽然没有全自动化，也全部有 AI 辅助。

更重要的是，用来做这些研究的 harness 代码本身也是 M2.7 写的。不是人写的。

为什么这件事帮助这么大？在没有 agent 之前，研究员的时间是串行的。提出假设，手动跑实验，花大量时间调试，因为这些实验很难跑，拿到结果，再提下一个假设。大部分时间不是在想新想法，而是在调试。

有了研究 agent 之后，运行和调试这些繁琐但困难的工作被接管了。研究员可以把更多时间花在提出新猜想、跟其他研究员辩论正确方向上。这是一个结构性的变化，不是做得更快，是能同时跑更多想法。

直接做研发只是一半。更有意思的是间接的方式，通过 harness 把训练和服务连成一个闭环。

逻辑是这样的：真实用户通过 MiniMax Code 做真实任务，我们的 harness 收集这些混乱的、长周期的工作流轨迹和环境，然后通过大量数据工程把它们变成可重复、可打分的 gyms，用于强化学习和其他 post-training。

Gyms 是模型训练的下一个关键方向。我们现在已经进入了「经验时代」，模型光在固定数据集和固定数学题上表现好不够了，需要在真实世界的工作中有实际表现。

我们甚至有专门的团队在做这件事。我们雇了金融、法律、医疗等行业的兼职和全职专家，他们的主要工作不是标注数据，而是在自己的专业工作流中使用 MiniMax Code 和 M3 模型。这些使用数据变成真实世界的、高价值的训练信号，进入下一个模型的 RL 训练。

这就构成了一个飞轮：模型训练完成，通过 harness 服务给用户，收集真实使用数据，变成训练信号，训练下一个模型。每转一圈，模型更好，数据质量更高，下一个模型也更好。

03

自研 Agent 比第三方好在哪里？

M3 在写 kernel 优化代码方面很强。Kernel 优化是推理服务的核心——把模型权重和 GPU 结合起来的那段代码。我们的推理团队可以用 M3 来写更好的 kernel 代码，服务 M3 自身。这又是一个自我改进的循环。

M3 本身也是在 MiniMax Code 里训练的，所以它在这个 harness 里天然跑得更好。

但这里面有一个更少人讨论的问题：为什么模型公司要自研 agent harness，而不是只依赖第三方？

用三个层次的协同设计来解释。

Model-Chip co-design 大家已经熟悉了，芯片和模型一起设计，让模型架构更好地在芯片上运行。Model-Harness co-design 也容易理解，模型在 harness 里训练，自然在那个 harness 里表现更好。

但第三种，

，讨论的人少得多。意思是：因为 harness 和推理服务都在我们手里，harness 可以反过来帮推理团队优化服务效率。

怎么帮？更可靠和干净的 system prompt，渐进式技能披露，正确的 tool 调用模式，良好的 tool error 处理。这些看起来都是 harness 端的设计决策，但它们直接影响推理端的需求模式。需求模式更可预测，缓存命中率更高，调度更高效，每个任务消耗的 token 更少。

这也是 Anthropic 不允许订阅用户在第三方 harness 里使用服务的部分原因。一部分是品牌，但另一部分是工程，自研 harness 让他们能更好地控制推理需求的结构。

这是双赢的，也是第三方 harness 做不到的，它们没有推理端的控制权，做不了 Inference-Harness co-design。

在我们的规模上，这些效率收益积少成多。跟单纯依赖第三方 harness 相比，我们能实现高得多的 token 吞吐量。

04

AGI 不是某个模型而是整个闭环系统

回到全景图。Agent 对我们的帮助分两层：直接层面，帮研究员写更好的训练算法，帮推理团队写更好的 kernel；间接层面，自研 harness 让推理服务更高效，同时把真实用户行为变成训练信号。

这个闭环正在收紧。值得想一想，这个系统跑上六个月、一年之后会是什么样子。核心依然是模型，从训练到服务，一切围绕模型。模型依然是产品。但 harness 已经是不可或缺的一环。

我的结论是：

。可以想象，有一天从训练到服务到数据收集再到训练，整个循环在没有人类参与的情况下运转。模型通过自己的 harness 闭合循环，持续改进自身。

对其他模型公司来说，这一年的实践至少指向一个方向：Agent 不是模型的附属品，是连接训练和服务、连接实验室和真实世界的那根轴。设计好这根轴，飞轮才转得起来。