AI 的下一阶段，可能是让模型学会自己变强，这也是今年被频繁讨论的 RSI 方向。

Evolvent AI 创始人胡梦康认为，RSI、Self-Evolving Agent、Auto Research，叫法不同，本质上都是同一件事：让 AI 自主迭代。区别在于，选择从生产链路中的哪个环节切入。

这家公司成立于 2026 年初，由 OWL 框架的核心作者、港大博士生胡梦康创立，团队全员研究员背景。Evolvent AI 主要搭建 Self-Evolving Agent Infrastructure，通过规模化构建任务环境，让 Agent 在真实任务中与环境交互、获得反馈并积累数据，从而持续学习和提升能力。他们最终希望打造的，是一个能够持续学习、自我进化的 AI Scientist 系统。

技术上，胡梦康对 Self-Evolution 落地有信心。但商业上，他承认这个方向的爆发还需要时间。市场的天平正偏向「模型吃掉所有应用」，但他更倾向于相信，未来每家应用公司都可能拥有面向自身场景的专属模型。Evolvent AI 希望服务更多客户，成为 Agent 进化过程中的数据基础设施供应商。

胡梦康把这个方向叫做「Evolution as a Service」。在那个时代到来之前，谁能帮 Agent 更快地进化，谁就占住了生态位。

以下是 Founder Park 与胡梦康的对话，经编辑整理。

采访 | 万户

编辑 | 夏天朱俊熹

⬆️关注 Founder Park，最及时最干货的创业分享

Founder Park 正在持续寻找值得被看见的 AI 团队与项目。

我们将通过「AI 产品市集」、内容报道、社群分发等方式，帮你触达早期用户、获得真实反馈，以及建立关键连接。

如果你正在做 AI 相关的事，欢迎和我们聊聊。

01 LLM 是缸中之脑，

Agent 才是未来

Founder Park：你的研究经历跨越了好几个阶段，从 NLP、具身智能到 Agent。这条研究路线是怎么形成的？

胡梦康：2019 年本科入学后，我最早做的是知识图谱、TableQA 等偏 NLP 和 Symbolic AI 的方向，当时主流范式还是 Pre-training、Fine-tuning。2022 年前后，GPT 系列模型展现出很强的 Few-shot 泛化能力，Codex 也让代码生成成为一个很重要的研究方向，我开始转向 LLM 与 Coding 的结合。

后来申请到港大后，我进入具身智能方向，研究如何把大模型用于 Robotic Planning，并做了 EmbodiedGPT。之前我觉得，未来会需要一个可以处理各种日常任务的机器人。但当时机器人落地很难，大量精力花在和「大脑」无关的东西上。大家讲机器人的大小脑，大脑大概就是大模型，小脑是 Low-level Control 的能力。很多人花大量时间在 Low-level Control 上，但我还是比较喜欢大脑。

于是我就开始想，什么场景是基于大脑就可以完成的？就想到了互联网。所有在电脑里可以闭环的任务，都适合用一个大脑来解决。

当时我受到一篇叫「World of Bits」的论文（http://proceedings.mlr.press/v70/shi17a/shi17a.pdf）影响，觉得可以对整个互联网进行建模，让 Agent 在里面探索。想了两条路线：一是 Agent 在电脑上执行任务并把它闭环；二是把所有电脑上的任务都建模成一个清晰的 World Model，有了 World Model 之后它就可以被系统性优化。

2023 年入学后，我逐渐从 Physical World 转向 Digital World，开始系统研究 Agent、World Model 和合成环境，最终延伸到今天关注的 Self-Evolving 和 RSI。

这条路线表面上看是在不断换方向，但背后的问题其实一直没有变：如何让模型从只会处理静态文本，走向能够与环境交互、理解反馈，并在真实任务中持续改进的 Intelligence。

Founder Park：2023 年大家还在聊怎么用提示词工程让模型更好地交付任务，你们已经把 Agent 作为主要方向了。基于什么判断？

胡梦康：首先这本身是一种取舍。那时候做 Workflow、做 Prompt，可能是对落地而言更现实可行的路径。但一个更本质的事情是，能不能把这种需要 engineering 的东西，内化到模型里面，也就是后来比较常见的 Autonomous Agent 的范式。

之所以敢做这样的判断，是因为泛化能力。做 Prompt Engineering、做 Workflow，是把人的思维编码到软件里，但未来你可能都不需要软件了。

从 LUI（Language User Interface）这个角度延伸，能不能通过 LUI 让它直接把某个任务做完？比如让它帮我发邮件，我不希望它返回一个草稿再让我自己贴上去，我希望它能直接发掉。LUI 也会让过往基于 GUI 的软件发生变化，以前各种用户路径都是人的 Know-how，未来可能这些都会被颠覆了。

从技术角度来看，LLM 终归是一个「缸中之脑」。我们想把它的能力边界放得更大，甚至未来和机器人结合，让它真正有物理意义上的手和脚。从技术角度出发，一定要做 Agent。从需求角度来看，Agent 也是更切实可行的路线。

Founder Park：确定方向之后，具体做了哪些研究？

胡梦康：最开始，模型能力还比较弱。LLM 的使用方式基本是输入一个 Prompt、输出一个回答，不会像现在 Agent 一样进行多轮的工具调用。所以第一步是研究如何让 LLM 具备更强的任务规划能力。第一篇论文叫 Tree-Planner，基于树结构增强 Agent 的规划能力。

接着，我开始思考更核心的问题。首先是在 Agent 运行时怎么管理好上下文，当时叫 Context Management，现在大家叫 Context Engineering。

另一个方向则是探讨如何对整个互联网进行建模。后来发现很难，Agent 的数据其实是环境，并没有人显式去建模。所以做了 AgentGen 的论文，自动化生成环境和任务来训练模型，训出来的模型比当时的 GPT-4o 还强。

这几乎是 2024 年一整年的探索。到 2024 年 10 月，模型整体水位达到阈值，Claude 系列的模型已经可以执行一些日常任务。但缺少充分发挥模型能力上限的 Harness，我们就开始搭建，不到半年时间，2025 年 3 月发了 OWL。

02 转向 Infra 层，

是因为通用 Agent 的壁垒越来越薄

Founder Park：回头来看，OWL 项目是你们沿着这条路线做的一次尝试吗？

胡梦康：算是应运而生。我们那时候需要在框架上做很多工作，补足模型能力，打很多补丁来约束模型的行为。比如模型有时候会在某个步骤卡住，你需要设计一个 Recovery 机制。有时候它的输出格式不对，需要做解析和重试。

现在回头看，Harness 层需要做的事情越来越少了，很多部分都是模型自身的能力在驱动。

Founder Park：某种意义上，当时包括 OWL 在内的很多 Agent 项目，现在看是不是都有点类似于「苦涩的教训」的再演绎？

胡梦康：是一个角度，但大家在过程中沉淀的东西都有价值。

做模型训练，你能感知模型能力水位在哪。做 Harness，你能更清楚模型哪一块做不好，比如它 Planning 不够好，还是工具调用不稳定，还是长程记忆有问题。这种「模型能力的手感」非常重要。

这个项目给我带来的最大认知是一个闭环。之前偏学术，反馈来自学术界。但 OWL 是真正触达客户的，当时触达的用户群体大概有小一万人，怎么做 Harness 工程、怎么做一个和模型能力真正相交的 Agent 产品，这些都是现在非常稀缺的经验。

另外，OWL 是一个工程属性非常重的工作。之前我的经历里学术 VS 工程大概是 7:3，OWL 差不多是 1:1，甚至工程还占大头。这对我现在的创业有非常大的帮助。

但 OWL 的爆火并没有让我立马创业。通用 Agent 很难定义，它到底是创业公司的机会还是基础模型公司的机会，当时非常不明确。所以我当时加入了基础模型后训练团队，想搞清楚模型能力到底还有什么欠缺。

Founder Park：为什么之后进一步把方向聚焦到了 Self-Evolving？

胡梦康：进入基础模型后训练团队之后，我沿着 Agent Post-training 探索。但发现即便在最前沿的团队，Agent 训练的瓶颈还是在于有没有足够好、足够多的环境。全世界真正有这种洞察的人很少。

2026 年年初，我们组建了团队，开始更聚焦地研究 Self-evolve。从 2022 年到 2026 年，我们的信念一直是，Agent 会是一个全新的物种，会对人类的生产生活带来极大的变革。

核心理念非常简单。如果你的 Agent 可以自进化，那其实不需要一个非常复杂的 Agent Framework 和 Learning Loop，它可能非常简单，自己把自己需要的能力补全。

这个观点其实和 LeCun 不谋而合，真正的智能应该是可适应的智能（Adaptable Intelligence），可以更快地学习新东西。衡量它的标准不是当下能力的绝对值，而是学会一个新任务的速度。

我们公司的名字叫 Evolvent，本身就是 Evolve 的衍生词。这个名字大概是去年 9 月份定的，今年很多人会往 Self-Evolving 的方向做研究，开始往生产方向走。

当然每家公司做的事不一样，有的会做 Harness 这一层的 Evolving，有一些在做 Memory 的 Evolving，一些在做 Skill 的 Evolving。我们目前更关注的还是模型训练这一层。

Founder Park：Evolvent 想做的是 RSI 这个大方向在 Agent 层的一个具体落地吗？

胡梦康：Self-Evolving、RSI、Auto Research 这些方向，在我们看来本质上都指向同一个问题：能不能让 AI 参与到改进 AI 自身的过程中。当然，在当前阶段，这里的 AI 主要还是指 LLM。

但如果要更严格地定义 RSI，我认为关键不只是系统有没有自动跑训练，还要看新的 Intelligence 是否真的从旧的 Intelligence 基础上生长出来。也就是说，经过一轮系统改进后，模型的性能是否超过原始模型，并且这种提升能否进一步增强下一轮改进过程。

所以 Automated Training、Optimization 和 Research & Discovery 之间还是有层次差异。Automated Training 更像是把已知训练流程自动化。Optimization 是在既定 Search Space 里寻找更优策略。Research & Discovery 则是让系统改变 Search Space 本身，发现新的问题、提出新的 hypothesis，并带来可验证的能力增量。这个时候，评价目标不只是最终 Reward R 有多高，还要看一次 Research Intervention 是否真正带来了 Improvement ΔR。

Founder Park：为什么选择做 RSI 的基础设施和 Evolution OS？

胡梦康：如果拆整个行业的生产链路，第一步肯定是数据，第二步是 AI 怎么训练自己，第三步是它怎么给自己做 Evaluate，第四步可能是 Evaluate 完之后，再去做 Agent 的 Harness Engineering。有些人研究的 Self-Evolving，可能就在这个阶段。

基础设施大家都要用，而且能比较早期就创造价值。我们内部叫「Evolution as a Service」，把 Agent 自我进化所需要的一切基础设施，变成一个标准化的服务。不只 Serving 基座模型厂商做训练，也 Serving 应用层团队做产品优化，甚至 Serving 每个人的 Personal Agent 做个性化适配。在这个基础上衍生出来的形态，我们叫它 Evolution OS。

03 Agent 基建离模型更近，

更容易迭代

Founder Park：做 Infra 层算不算从应用层「倒退」了一步？

胡梦康：不是倒退，是挖得更深。

我们现在做的其实是一条完整的 Agent Evolution Stack。第一层是 Data，包括 Agent 要完成什么 Task、在什么 Environment 里运行，以及最后用什么 Verifier 或 Rubric 判断它有没有做好。再往上一层，是怎样利用这些 Experience 去 Evolve Agent。最后还需要 Evaluation，判断这一轮改进到底有没有形成真实的能力增量。

从认知角度看，做应用是在逆向模型能力，模型做不好什么你就去补什么，你是被动的。做基础设施是在正向定义模型能力，你构建什么样的环境和数据，就决定了模型能学会什么能力。我们更容易摸到模型能力前沿的水位。等终局到来时，我们也更能提前把握机会。

所以从应用走向 Infra 不是往后退，而是从「怎么把今天的模型用好」，走向「怎么让明天的模型变得更强」。

Founder Park：面向 Agent 做基建，会不会担心离用户场景太远？

胡梦康：我反而觉得这两件事并不矛盾。

基础设施如果完全脱离真实应用，当然会变成自嗨。所以我们一直非常关注应用层产生的真实信号：什么场景开始出现 PMF，用户在什么任务上真正愿意付钱，Agent 在哪里频繁失败，这些都会反过来告诉我们下一阶段应该做什么样的 Environment、Data 和 Evaluation。

但基础设施有一个好处，就是它的复用周期通常比具体产品形态更长。

去年大家可能在讲 MCP，今年开始讲 Skill，Harness，明年还会有新的 Agent 抽象层。应用层的产品架构可能会随着范式变化不断重写，但一些更底层的东西，比如任务怎么定义、环境怎么运行、Experience 怎么产生、能力怎么 Evaluation，不会因为上层换了一个名字就失效。所以我们更关注的是那些跨范式仍然成立的底层要素。

Founder Park：范式从 LLM 切到 Agent 后，当初给 LLM 做基建的公司位置就尴尬了。你们会担心自己也遇到这个问题吗？

胡梦康：我们从一开始就不希望绑定在某一种模型形态或者某一个技术范式上。我们真正服务的不是「今天这个 LLM」，是 Intelligence 的整个 Evolution Loop。

无论未来底层是更大的 Foundation Model、Agent System，还是新的 Architecture，有几个问题始终存在。这个系统现在的能力边界在哪里？下一步应该学什么？怎样获得新的 Experience？怎样 Training？怎样 Evaluation？这一轮改进究竟有没有让它真正变强？这些问题不会因为从 LLM 变成 Agent 就消失。

所以我们希望构建的是一套更底层的 Evolution Infrastructure。它当然会不断迭代，今天可能是 Data、Environment、Training 和 Evaluation，未来可能还包括 Harness、Memory、Serving，甚至 Architecture Search。但核心不变，帮助一个 Intelligence System 持续发现自己的 Frontier，并跨过它。

第一性原理的判断是，Agent 带来的生产关系变革在于，过去用时间乘以工作稀缺性衡量劳动价值，但 Agent 不是这样的。Agent 可以疯狂开并行，真正受限的是推理引擎和消耗多少 Token。未来经济体系中相当一部分可能是 Agent 自己做闭环、自己执行、自己交付、自己赚钱。怎么给它定价、怎么让它自进化、能不能有一个帮它做增长的平台，这些需求不是建立在人之上，而是建立在 Agent 之上。

我们瞄准的是那个最远的方向，虽然可能很快就会发生。

Founder Park：那在 Agent 的 Self-Evolving 闭环里，人的角色会是怎样的？

胡梦康：我觉得人的角色会逐渐从「每一步怎么做」，变成「最终往哪里走」。

今天很多 Agent 还是 Human-in-the-loop。人告诉它做什么、下一步怎么做、哪里错了，然后它继续执行。但真正的 Self-Evolution 不应该一直依赖这种高频干预，人的角色应该逐渐上移。

比如我希望一个 Agent 在某一类考试上做到接近满分，人可以定义这个长期目标，同时规定安全边界、资源预算和一些最基本的约束。但中间到底先提升哪一个能力、做什么数据、设计什么实验、怎么训练、哪一次尝试值得继续，应该越来越多地交给 Agent 自己完成。

所以理想状态是，人定义目标和边界，Agent 负责 Discovery 和 Optimization。

今天人类研究员还在决定模型下一步学什么。长期来看，我们希望 Agent 能够自己发现自己的 failure mode、自己提出 hypothesis、自己产生 learning signal，再决定下一轮怎么改。

当然，人不会完全消失。越是长期运行、权限大的系统，越需要独立的 evaluation、安全边界和最终 accountability。

04 Agent 数据的交付更复杂，

要造一个动态的世界

Founder Park：LLM 数据比较容易理解，Agent 的数据核心包括哪几个部分？

胡梦康：一共三个部分。第一个是 Agent Environment，在这个环境下有什么工具、环境的初始状态是什么样，比如一个 Email Agent 的邮箱里有哪些邮件。多个 Environment 组合在一起是一个场景，比如 HR 的 Agent 可能有邮箱、Slack 和各种 Tool。

第二部分是 Agent 的 Task，给它什么任务让它执行，以及有哪些约束。

第三部分是对应的验证器，怎么判断任务有没有成功执行、完成得有多好。

所以 Agent Data 和传统数据最大的区别是，传统数据的基本单位可能是一条 Sample，Agent Data 的基本单位更像一个可以被运行的实验。

难点在于，不是要把这些东西机械生产出来。首先要做 Frontier Discovery，找到当前模型恰好不会、但又可以通过训练学会的 capability gap。再把这个 gap 转化成具体的 Task、Environment 和 Verifier。

这里还需要区分两类数据。用于训练目标模型的数据，关注的是让模型学会某个具体能力。而用于训练 RSI System 本身的数据，更像研究轨迹，需要记录我们为什么判断这是一个值得解决的 gap，提出了什么假设，设计了什么实验，采取了什么干预措施，最后有没有带来可验证的 improvement ΔR，以及下一步应该怎么决策。

Founder Park：哪一部分壁垒比较高？

胡梦康：如果从 Engineering Workload 来看，Environment 往往是最重的一部分。需要投入精力多，要对场景有足够认知，甚至要在真实环境、真实数据、真实工作流里反推洞察，然后才可以 scale up。

因为一个好的 Environment 不是把几个 API 接起来就结束了。你需要正确模拟 State Transition、Tool Behavior、外部事件以及真实工作流，还必须能够 Reset、Replay、Scale，支持模型反复 Rollout。

但如果从 Research 的角度看，Task 和 Verifier 同样关键。如果环境对，但任务差，Agent 可能通过奖励破解就做对了。任务好，但环境不真实，Agent 学不会处理真实世界的任务。没有一个好的验证器，也没法得到足够好的轨迹。这几个部分的重要性是一样的，但投入精力和技术壁垒还是环境最高。

所以我们内部不会把它理解成三个独立的数据组件，而是一套完整系统。Environment 通常最重，Task 和 Verifier 决定它最终有没有研究价值。

Founder Park：验证器这个环节，跟姚顺雨之前说的 AI 下半场有关联吗？

胡梦康：算是一个衍生。大家一直讲 Competitive Programming、Math，因为定义非常清晰的。Competitive Programming 基于单元测试，Math 基于结果对不对，观测空间很小。但 Agent 不同，需要执行很多步，很多任务没办法用客观的、观测空间很小的东西来评判。

所以 Verifier 只是其中一部分。更完整地看，其实是 Environment、Task 和 Verifier 一起定义了一个 Evaluation Setup。

我觉得 Agent Data 一个很重要的工作，就是把真实世界里那些模糊、开放的问题，变成一个模型可以运行、可以获得 Feedback、也可以被可靠 Evaluation 的问题。

Founder Park：怎么判断 Agent 是真的在自进化，而不是过拟合了特定评测集？

胡梦康：这个问题在 AutoResearch 里特别重要，因为 Research Agent 不只是回答问题，它甚至可以修改 Data、Training Pipeline、Harness 和 Environment。它的权限越大，Reward Hacking 的空间也越大。最危险的情况是，Capability 本身并没有提升，系统提升的只是用来衡量 Capability 的指标。

举个具体例子，比如我们想让模型自己训练自己，这个时候它会有一个验证集。如果它能看到这个验证集，那就可以针对性地造更多同领域数据，这个过程其实就是在做过拟合。

所以这里不能只靠 Rubric 里写几条红线，更重要的是把 RSI Infrastructure 本身设计好。我们的思路是把训练、推理、部署、Sandbox、Evaluation 这些环节全部做成标准服务。Research Agent 只通过标准 API 提交实验、生成数据、发起训练、提交 checkpoint，并获得有限反馈。

在这个设计里，我们希望给 Agent 足够大的行动空间。它可以写代码、生成数据、设计实验、训练模型，甚至决定回退到哪个历史 checkpoint。但 official evaluation、grader、test set、data provenance、checkpoint 提交流程和最终 evaluation sandbox 都必须和 research space 隔离开，不能被 Agent 随意读取或修改。

所以防止 Reward Hacking 不是简单防止它看到验证集，更重要的是把 research space 和 evaluation space 分开。我们限制的是边界，不是边界内部的探索。只有这样，才能判断 Agent 优化的是模型能力，还是仅仅优化了评测方法和代理指标。

Founder Park：有人把你们类比成 Agent 版的 Scale AI，差别大吗？

胡梦康：如果只看「都为 Frontier Model 提供数据和基础设施」这一层，这个类比比较容易理解。但我们想解决的问题，其实更靠前一步。

传统数据供应的起点通常是一个已经被定义好的需求。客户已经知道需要什么样的数据，然后大家竞争的是怎么把它高质量、低成本、规模化地生产出来。

但到了 Frontier Model 阶段，越来越难的问题不再是「怎么生产」，变成了下一代模型到底还缺什么数据？

模型能力变化太快了。今天还有价值的数据，下一代模型出来以后可能就已经被解决了。所以我们首先要做的是 Frontier Discovery，判断模型现在会什么、不会什么，哪些 failure mode 已经成为行业共识，哪些 capability gap 甚至还没有被行业发现。

我们不会等客户告诉我们应该生产什么数据，希望比市场更早定义下一代模型需要什么数据。

找到这个 Frontier 之后，才进入第二步，把一个研究假设变成真正可以训练模型的东西。这里才会涉及 Task、Environment、Verifier、Rollout 和规模化的数据生产。从这个角度讲，除了 Agent Data 更复杂，我们和传统数据公司的区别还在于所处数据价值链的位置不同。

Founder Park：你们具体交付的是什么？

胡梦康：很多时候交付的是一套可以直接运行的代码和环境，这是跟传统数据标注最大的区别。比如旅游场景，交付的是包含查天气的接口、查地图的接口、查机票的接口。客户拿到之后，模型可以直接进入这个 Environment 运行，我们可以 Reset、Replay，也可以规模化 Rollout。

有时候会交付很长程的任务和环境，可能需要上百上千个 step 才能解决。比如一个 HR Agent 的任务可能是，连续 30 天管理一个虚拟公司的招聘流程，期间会有候选人放鸽子、部门临时加需求、预算被砍等各种突发情况，Agent 需要动态调整策略。这整个「剧本」实例化后就是一段代码。

有些更前沿的交付，需要花两到三周深入研究客户的真实数据，内部的业务规则、API 的 behavior、用户的反馈行为模式，然后给它构建一个 World Model。比如一个金融场景的客户，我们需要理解他们的风控规则是什么，审批流程是怎样的，哪些操作会触发合规审查。这些东西在公开互联网上找不到，必须从客户的真实业务中去挖掘和建模。

Founder Park：Agent 数据会有品味之分吗？

胡梦康：有，几个关键维度。

第一，区分度。你构造的任务，不同模型跑出来成功率是否足够分散？如果一个任务所有模型都能做到 95%，那这个任务对训练没有价值，Agent 没什么可学的。如果所有模型都只有 5%，那说明任务太难了，Agent 通过探索也学不到什么。真正有价值的 Task 往往处在模型当前 Capability Frontier 附近，它现在还做不好，但通过 Rollout、Feedback 和 Training 有机会逐渐学会。

第二，长程任务的真实性。是不是真的存在一个需要 100 轮的任务？还是只是 10 个简单任务的排列组合？这个区别很大。如果一个「长程任务」只是把 10 个独立的小任务串起来，那完全可以拆开单独解决，没必要做成一个 100 轮的任务。真正有价值的长程任务是那种步骤之间有依赖关系的，前面做的决定会影响后面的选项，中间会有突发情况需要调整策略。

第三，环境是否动态。很多现有的 Agent Environment 是静态的，所有的变化都是 Agent 自己驱动的，Agent 不操作就什么都不会变。但真实世界不是这样的。真实世界会有各种 Agent 无法预料的变化，比如 Email Agent 不应该面对一个静止的收件箱，而应该面对一个动态邮箱，随时会有意想不到的邮件进来，有些是垃圾邮件，有些是紧急事项，有些是之前邮件的回复。Agent 需要在这种动态环境中学会应对。

这些不是招一个标注员就能解决的。你让标注员去标「这个邮件应该怎么回复」，他可以标。但你让他去设计一个动态邮箱环境，让环境在正确的时间以正确的方式产生各种邮件，这需要对模型训练和评测有深刻的理解。需要对模型和框架有直觉、手感、品味。

05 Agent 的 Scaling Law 才刚开始，

未来每家应用公司都可能拥有自己的模型

Founder Park：很多基模厂商内部也在搭建自己的数据和环境团队。它们做的事情和你们有什么区别？双方更多是竞争关系还是互补关系？

胡梦康：我觉得整体上是互补大于竞争。

Frontier Lab 当然会有非常强的内部 Data 和 Environment Team，因为这些能力直接决定模型迭代速度。但他们首先服务的是自己的模型研究路线，当前这版模型哪里不行，下一版模型要解决什么问题。

我们的视角稍微不同。我们会同时观察不同 Frontier Model，去判断哪些 Failure Mode 是某一个模型特有的，哪些其实代表整个行业正在接近的 Model Frontier。

所以我们希望承担的是更外部的一层 Data Research，提前发现下一代模型还缺什么能力，再和 Frontier Lab 一起把这个 Research Hypothesis 变成 Task、Environment、Verifier 和最终可以训练的数据。

这也是为什么我们和客户很多时候是 Co-design，不是传统意义上的数据外包。真正有价值的部分往往发生在数据生产之前：这个问题值不值得做？它是不是 Frontier？什么样的 Evaluation 才真的代表 Capability Gain？

还有一个好处是 Evaluation Independence。当 Data、Training 和 Evaluation 全部发生在同一个 Loop 里，很容易产生 leakage 或 reward hacking。作为外部团队，我们可以提供一套相对独立的 benchmark 和 evaluation view。

Founder Park：基础模型公司以 Agent 形式给用户交付任务时，也在积累任务数据。如果数据飞轮已经在跑了，你们提供的数据会不会没有飞轮跑得快？

胡梦康：我觉得这两种数据解决的是不同问题。

环境的价值是可重放，有一个完整工作环境的话，大模型就可以重复在里面做训练。比如 Coding 场景，执行 A 代码和执行 B 代码的结果完全不一样。用户飞轮收集上来的只有执行 A 的结果，因为用户当时选了 A。如果你想知道执行 B 会怎样，就需要把环境重建出来做重放。

真实用户数据真正的价值在于提供洞察，有些边界 case 非常反直觉但又合理，模型自己合成不出来，因为它没法泛化到分布外的东西。比如某个客户反馈说，Agent 在周五下午发的催款邮件回复率特别低。这个 insight 你让模型自己想是想不出来的。这些 insight 对我们来说是种子，我们基于种子去扩充整个 environment。围绕「发邮件的时机」这个维度去构建更丰富的环境变量，合成各种变体和数据，让 Agent 能学会时机选择。

真实数据负责发现问题，Environment 负责把一个问题变成可以反复学习的实验。

Founder Park：对 Agent 来说，是不是今年才是数据 scaling 时代的开始？

胡梦康：确实才开始。一方面 Agent 的数据飞轮还没完全形成，另一方面数据复杂度比 LLM 高很多。比如在某一个时间点，执行 A 代码和执行 B 代码对应两条完全不一样的数据，怎么用更少的数据训练好能力，本身就比较难。

而且 Agent 环境的产能还没跟上。以前你要获取代码相关数据，直接去 StackOverflow 爬就行，质量很高，量也很大。但 Agent environment 在公开渠道根本找不到。去哪找一个完整的「HR 招聘环境」或者「金融风控环境」？这些东西从来没有被系统性地构建过。

我们测试发现，Coding 能力并不能泛化到日常任务。很多人觉得代码 Agent 做得好，那用同样的方法去做其他任务应该也行。但实际上不是这样。代码任务有一个很好的特性，输出是确定性的，可以用测试用例验证。但日常任务不是，发一封邮件「好不好」没有标准答案，订一个航班「对不对」取决于用户的偏好。你终归需要针对不同场景构建各种环境来辅助训练。

所以 Agent 时代真正稀缺的，是能够规模化产生 Experience 的 Environment。而这些应用场景和真实的环境恰恰是非常分散的。

如果从这个角度出发，未来不一定只有几个巨头的超大模型，也可能会有大量针对特定场景优化到极致的专业模型，百花齐放的生态，所有应用公司都会变成模型公司。

Founder Park：通俗点理解，相当于最后每一家应用公司，都会围绕自己的业务场景拥有一个专属模型？

胡梦康：我觉得长期会出现一个非常重要的分层。

Foundation Model 负责提供非常强的通用智能，但一个模型真正进入具体业务以后，面对的是一个非常特殊的 Task Distribution。

同样是 Agent，金融、Coding、销售、科研，它们需要的 Tool、SOP、Latency、Cost 和 Error Tolerance 完全不同。

如果一家应用公司拥有足够多的真实交互数据、Environment 和 Feedback，它就有条件把通用模型进一步 Post-Train 成更适合自己业务的专属模型。

这个专属模型不需要在所有评测基准上超越前沿大模型，它只需要在自己的业务数据分布上，做到效果更好、成本更低、速度更快，并且能够随着业务持续迭代适配。

Founder Park：今年各种新模型都在针对 Agent 做能力优化，通用 Agent 会被模型厂商吃掉吗？Harness 这一层还有多少空间？

胡梦康：我觉得大量通用 Agent 能力最终会被 Foundation Model 厂商吸收。因为通用能力本身就是 Frontier Model 能力的一部分。Tool Use、Browser Use、Coding、Planning，这些一旦被证明是普遍有价值的能力，模型厂商一定会通过 Pre-Training、Post-Training 或 Harness 把它们做进去。

你把 SOP 写成 Skill，合成数据训进模型，那个 Skill 就没价值了。比如「帮我订机票」这种通用能力，现在可能需要一个专门的 Skill 来实现，但未来模型自己就会了。Harness 层里很多东西确实越来越薄。

但有一部分东西很难被通用模型一次性内化，就是具体环境里的专属知识和经验。比如一家公司的审批流程、内部 SOP、Tool Usage Pattern、风险偏好、客户分布、历史 Failure Mode，这些东西不是通用互联网数据的一部分，还会不断变化。

所以我觉得未来真正长期存在的不是一层静态 Harness，可能是一套 Adaptation Layer。它不断观察 Agent 在企业 Environment 里的表现，把新的 Experience 转化成 Memory、Workflow、Data，甚至进一步变成 Post-Training。

深入垂直场景后，情况也会有所不同。法律文书审查、医疗影像分析等相对标准化的场景，有明确的规则和评价标准，可以由一批创业公司来做。面对非标准化的企业流程，适配过程会复杂得多。按照我们对一些客户的了解，中间链路很长，写一个 Prompt 很难解决，很多时候还需要做后训练。

这意味着，未来最前沿模型 90 分，小的开源模型通过公司内部 workflow 适配和后训练，能达到 90 分以上。训练成本是一次性投入，未来每次执行任务的 token 消耗和 API 成本都更低。不是所有人都需要用最前沿的模型，大企业可能更倾向于训练自己的专属小模型，又便宜又好用。

06 Evolution as a Service，

服务的是 Agent 全生命周期

Founder Park：你们在公司最开始就连续发布了 5 个开源项目，最近又开始做 Self-Evolution 和 RSIBench。回头看，这些开源项目和你们今天的主线是什么关系？（注：详细项目参见 evolvent.co）

胡梦康：回头看，4 月那一批项目更像是我们在 Self-Evolution 这个大方向上的一组早期 probe，而不是五个彼此独立的产品。

我们当时在同时摸几个问题。ClawMark 和 Terrarium 在研究长期运行的 Agent 到底需要什么样的动态 Environment 和 Evaluation。当时我们设计了 HR、金融、医疗甚至 EDA（芯片设计）等垂直场景的评测，覆盖面很广。AuthBench 在看 Agent 的权限边界。Skill Laws 在研究 Tool 和 Skill 数量 Scale 以后会发生什么。BenchRouter 更多是在解决 Benchmark Infrastructure 的标准化问题。

我们后面的工作开始越来越靠近 Self-Evolution。6 月我们做了一套 agent population 的 collective evolution experiment，让不同 Agent 的尝试、失败和经验可以被后面的 Agent 继承。再往后做 RSIBench-Data，我们直接问，一个 Agent 能不能自己发现需要什么数据、生成数据、真实训练一个模型，再通过独立 Evaluation 判断这一次 Training 有没有让模型变强。

Founder Park：这些项目是你们过去积累提炼出来的，还是专门花精力去做？

胡梦康：我们不是先列一个产品 Roadmap，再按季度往下做。更像是围绕 Self-Evolution 这个长期问题不断做 Research。每做完一层，就会暴露下一层 Bottleneck。

最早做 Evaluation，会发现静态 Benchmark 不够，所以开始做 Living Environment。当这个问题暴露出来之后，我们就会集中精力把这些项目闭环掉。再往后，我们开始进一步问，今天这个 Frontier 还是 Researcher 在定义，那未来能不能让 Intelligence 自己发现下一步应该学什么、自己构造 Experience，并验证这一轮 Improvement 有没有真正让自己变强？这才自然把我们带到了 RSI。

Founder Park：谁能定义出新的 benchmark，并且基于这个新的 benchmark 提供数据，是不是某种意义上今天能跑通商业闭环？

胡梦康：Benchmark 本身不是商业闭环，但它是我们理解 Model Frontier 的一个非常重要的接口。真正有价值的事情不是「再造一个 Benchmark」，在于能否通过 Research 判断，下一代模型到底还不会什么。所以我们现在很多客户合作其实是一条完整链路：Frontier Discovery → Benchmark → Training Data。

Founder Park：定义新的 benchmark 的能力算不算一个壁垒？

胡梦康：我觉得再具体一些，壁垒是 Research 能力和 Frontier Discovery 能力。所以真正稀缺的，是能不能在共识出现之前，发现下一代模型还没有解决的问题。

Founder Park：现阶段商业模式还是以 to B 数据交付为主？

胡梦康：是的，目前客户既有基座模型厂商，也有做应用层的公司。基座模型厂商需要训练数据和评测体系，应用层公司需要针对自己场景的训练环境。不同客户可能会有不同的应用层产品，关注的数据不一样。所以大部分情况下，我们还是会按照客户需求去匹配相应的数据。

最终愿景是把 evolution 做成标准化服务。Agent 在训练阶段实时需要什么样的环境，我们就给它创造什么样的环境，并且进一步去提升 Agent 能力。你可以想象一个 API，Agent 说「我现在需要一个包含动态邮箱和日历系统的环境，来练习日程管理」，我们就实时给它生成这个环境。这个框架是 Agent-Friendly 的，最终用户可能不是人，而是 Agent 自己来调用。

Founder Park：所以你们最终讲的 Evolution-as-a-Service，具体是什么？

胡梦康：我觉得今天很多 AI Infrastructure 都是在服务单次推理或者单次训练，但我们希望服务的是整个进化周期。最简单地说，客户给我们的不是「帮我标多少条数据」，是一个 Model、一个真实的业务任务分布，以及一个它希望提升的目标。Evolution-as-a-Service 真正想做的，是把「怎样让一个智能变得更强」本身变成一种基础设施能力。今天很多步骤还是 Researcher 在操作，未来它当然应该是 Agent-Native 的。理想状态是 Agent 自己发现「我现在缺什么能力」，自己调用这些数据做实验，最后通过独立 Evaluation 判断这轮 Evolution 是否有效。

07 创业是一个无限游戏

Founder Park：团队现在什么状态？

胡梦康：正式员工十个人左右。整体画像都是偏研究员，大家之前不管是模型训练、Evaluation 还是 Infrastructure，都做过非常多的探索。

Researcher 团队大部分人在定位当前 Frontier Models 还解决不好的问题，以及建设背后的 Infrastructure。比如怎么在 Infra 层面避免 Reward Hacking、设计更多比较有趣的 Agent task。

Data 团队严格来讲和 Researcher 团队是不分家的。我们的 Researcher 和 Data 团队通常会更多做数据，这不能叫数据标注，更像数据生产。还是会有一些同学在 Supervise 模型，如果有 Reward Hack，就需要去做一些改进。本质上不是在做标注，是在像 Supervise AI 做一些事情。

Founder Park：从学术到真正下场创业、做商业化交付，感受是什么？

胡梦康：学术到落地比想象中远。从上往下看，学术探索离真实的产品和商业化有很大的 gap，你以为你的论文解决了一个重要问题，但到了产品层面发现还有十几个工程问题、用户体验问题、商业模式问题需要解决。

但从下往上看，从用户需求出发，怎么 Identify 到一个真正核心的问题，然后持续投入研究构成护城河。这个 Critical Thinking 能力是学术训练给我们的，非常宝贵。很多创业者容易追热点、追风口，但学术训练让你能沉下心来想，这个问题的本质是什么？什么方法是根本性的解法？

学者创业的独特之处是，你在做一个东西还没有出现的时候就先 Create 出来，然后找落地、找用户、做商业化闭环。链路很长，但我们内部对这种全链路闭环非常兴奋。从最前沿的研究一直做到客户交付，每个环节都是自己走过的。

Founder Park：今年会有焦虑吗？

胡梦康：每天都焦虑。但焦虑也带来动力，每天早上醒来还是非常兴奋，要去做这些事。焦虑和兴奋往往是同一件事的两面。

关键是不要把无意义的焦虑传导给团队。不能说「我们现在很着急，要赶紧出成果」，这没有任何价值，只会让团队慌。而是给大家清晰的 vision，让大家知道什么是正确的、什么是重要的。如果方向是对的，速度自然会起来。情绪管理是创始人核心能力之一，你的情绪会传染给整个团队，你焦虑团队就焦虑，你沉稳团队就沉稳。

Founder Park：你怎么定义创业的成功或者失败？

胡梦康：失败是一个很难定义的事情。创业最大的好处是你可以脱离一些框架，去探索自己真正认为有价值的东西，相信这个有价值的东西会变成一个在商业上对人类有价值的东西，它会是一个无限游戏。

这也是之前谢赛宁老师的观点，研究是一个无限游戏，我们也觉得创业是一个无限游戏。我们获得的正向反馈永远都是在发现未知的东西、在探索过程中获得的。一拨人一起去探索未知，你会获得一种归属感。只要还在做这些东西并且方向没有偏离，就不是失败。

从更实际的角度讲，我们相信 Agent 未来会成为经济体系下的一个主体，它自己可以闭环应该做的事情。未来可能不是人去赚钱，而是 Agent 去赚钱，Agent 赚钱给人花。在那个时代下，我们做的 Infrastructure、我们做的 Evolution as a Service，会在那个时候有一席之地。我会把这个定位成我们成功的一个信号。

Founder Park：对学者创业有什么建议？

胡梦康：一定要 Open-minded。做学术的人有时会觉得一些特别杂的事情价值低、不值得做，跑销售、做运营、处理行政，觉得这些跟技术无关。但创业不一样，创业是唯结果论的，只要能 work 就行。有些看起来很「low」的方法，如果能带来客户、带来收入，那就是好方法。

要让自己做全链路闭环，每个环节都有清晰感知。创始人先自己趟一遍 0 到 1 的路，自己写代码、自己跑客户、自己做运营，才知道什么画像的人过来能帮你做 1 到 100。如果你自己没走过这条路，你招来的人做得好不好你都判断不了。这种 0 到 1 的经验非常宝贵，后面很难再获得了。