🚗 本周「十字路口」的嘉宾是 Pyromind 创始人 / CEO Kevin Ding。Pyromind 所在的赛道，常被称作 RL as a Service，也就是强化学习即服务、或后训练即服务。公司前不久完成天使轮融资，投资方包括高瓴、百度风投、蓝驰、Atypical 等机构。
但在 Kevin 看来，RL as a Service 只是起点，不是终点。他在节目里说，Service 只解决了一半问题；真正要让 Agent 在生产环境中持续改进，还需要把训练、奖励、反馈、部署和数据回流串成一条可以自动循环的管道——也就是 Pyromind 正在押注的 AutoRL。
我们也聊到了 Pyromind 的真实落地场景：工业质检、工艺参数优化、GUI Agent、Coding Agent，以及企业里那些 ROI 明确、数据足够富集、好坏标准相对清楚的生产问题。
同时，这期也会讨论一个非常现实的问题：企业 AI 到底怎样才能不是项目制咨询？
Kevin 坦诚，第一次进入客户场景时，FDE 的工作不可省：要理解数据制式、评价基准、业务流程和奖励信号。但 Pyromind 追求的是让这部分工作在相似模态和相似场景中逐渐递减，把一次性交付沉淀成可以横向复制的 AutoRL 管道。
Kevin 重点分享了他们的新工作 PyroDash：一个由 4B 小模型、强基座模型和协作引擎组成的大小模型协作架构。Kevin 认为，这背后对应的是一个更大的判断：需求世界是多元的，不是所有问题都应该被收拢到一个中心化大模型里解决。
这期适合所有关心 AI Agent、后训练、企业智能、工业 AI 和 AI infra 的朋友。
微信收听播客：
小宇宙收听播客：
🎬 视频播客已同步上线于 @Koji杨远骋 的视频号、小红书、哔哩哔哩、Youtube 等平台
快问快答
👦🏻 Koji
请问 Kevin 你的年龄？
👨🏻💻 Kevin
我是 94 年的，32 岁。
👦🏻 Koji
请问你的求学经历？
👨🏻💻 Kevin
伦敦国王学院 King's College London。
👦🏻 Koji
MBTI 和星座是？
👨🏻💻 Kevin
如果是按测试结果来看是 INTJ，但是我的感觉可能在 I 和 E 之间。星座是摩羯。
👦🏻 Koji
一句话介绍一下 Pyromind。
👨🏻💻 Kevin
最终定位就是一个 AutoRL，它跟现在大家一直在讨论的 RSI 这个方向，其实相当于是一个比较具象化的实现路径。
👦🏻 Koji
融资情况呢？
👨🏻💻 Kevin
我们是去年公司成立之后就做了一轮，投资机构包括高瓴、百度风投、蓝驰，还有 Atypical。
👦🏻 Koji
目前团队的规模是？
👨🏻💻 Kevin
我们现在有 20 多个人。
👦🏻 Koji
现在收入和利润方便讲吗？
👨🏻💻 Kevin
具体数值就先不 share 了，但是现在我觉得比较振奋人心的一点是，我们初步跑通了 PMF。
👦🏻 Koji
什么样的 PMF 跑通了？
👨🏻💻 Kevin
两个方向。
一个方向就是证明我们提供 AutoRL 这种方式实现的 RSI 在生产环境是有价值的，它的商业模型至少是成立的。
第二点就是它的可扩展性。在横向的场景和客户的复制上，我们的工作量是逐步递减的。
👦🏻 Koji
明白，咱们在创业之前做过些什么呀？
👨🏻💻 Kevin
我之前其实有很多精力是放在偏 Infra 这里的。我之前在阿里云，也做了弹性 GPU 实例，包括训练 GPU 的这些集群。
AI 终局为何是 Agent 蜂群？
👦🏻 Koji
当时是看到了什么样的机会，决定创业做 Pyromind？
👨🏻💻 Kevin
当时我的想法是，模型预训练这个事情，到现在为止其实远远没有到终结的时候。
当时看到一个趋势，就是到 2025 年下半年，看到无论社区、硅谷还是国内的技术圈，大家都在讨论 AI 可能要进入下半场。下半场的说法就出现了两个方向。
一个方向是认为我们继续沿着预训练走，ASI 到来的形式会是一个超级庞大的、中心化的模型，它能够解决绝大多数场景里面的问题，效果还足够好。
另一个方向是，它最终 ASI 的形态会是一个服务化的形态，是一个 Agent 蜂群的形态。
我个人更偏向于后者，因为我觉得这个更实际。
我们这个世界上需要被 AI 解决的问题和场景，无论是从当下时间点看，它就已经是无穷无尽的了。同时，随着时间的推移，它还会不断产生新的场景，而且场景本身也不是静态的。
在这样的模式下，我们尝试用一种有限参数的模型去泛化掉无限的场景，至少在 Transformer 架构上实现还是蛮有挑战的。
👦🏻 Koji
到目前为止又过去了一年多，你有看到一些信号，让你感觉一开始的 bet 越来越成立了吗？
👨🏻💻 Kevin
首先从理论上，我们看到第二条路必然成立。我不能证伪第一条路，但我能论证的是，第二条服务化的路线是一定成立的，因为需求一直都在那里，并且一直在增长。
这一年我看到的一个变化是，大家为什么现在去提 RSI，而在之前热度没有那么高。这其实就是服务化带来的一个结果。因为部署的 Agent 变多了，我们可以想象一下，正常一个人日常带了几十个 Agent 去做一件事，是不可能有精力去维护每一个 Agent 的演进的。
RSI 被需要，是因为 Agent 现在开始多起来了。当我们把一个个 Agent 嵌入到场景里面的时候，对它最终的衡量方式是它得在一定的时间轴上表现都符合预期。
实现的方法就是 Agent 需要自我迭代，Agent 本身需要有自我改进的能力才能做到这件事。
RLaaS 只解决了哪一半？
👦🏻 Koji
所以一开始做 Pyromind 的时候，就想到了要用 AutoRL 去做 RSI 吗？还是在过程中慢慢浮现出来的？
👨🏻💻 Kevin
实话说，其实是过程中浮现出来的。
我们去关注后训练这个场景，一方面是我们自己本来就在看这个方向，另一方面，后训练这个事情对我们自己影响也比较大。你会发现，以 RL 为代表的后训练技术，其实是拿到环境的反馈然后去更新，它是一个持续的过程。
对我们自己研判方向，我们团队也是这样子的。我们在创立之初，认为做到 RL as a Service，做到一个扁平的 service 形态，其实就已经差不多能满足这些 Agent 部署的要求了。但我们后来发现这依然是不够的。因为 service 面向的对象终归还是要有一个 Developer 在那边去驱动 Agent 去改进的。
在这个阶段我们才去想，其实 service 只解决了一半的问题。我们真正把 RSI 跑起来要解决两个问题，一个是 Training Infra，一个是奖励。
所以我们就开始规划 AutoRL 要怎么跑起来，同样的，奖励就纳入了我们的 scope。
👦🏻 Koji
能用一个具体的客户例子讲讲，只单独做 RL as a Service，和做 AutoRL，具体的服务内容有什么不同吗？
👨🏻💻 Kevin
比较好的例子是我们在 GUI Agent 领域的一个客户。他们下游有很大的消费级部署量，会不断收集到很多用户特定的需求，以及他们自己的产品迭代需求。
我们一开始提供的 RL service 是给他们提供了一个 Studio，把一个通用的 training pipeline 固定下来。但他们依然需要不断投入自己的算法工程师去更新 Agent 本身，我们只帮他们把训练这件事情解决得很好。
因为一个训练要完整解决、完成一版模型更新，除了需求侧的分析、算法设计和训练，后端的 Infra 也要被解决。当时我们把 Infra 的问题全部帮他们解决掉了，但他们依然没有摆脱要投入大量人力去搞这件事情。
到了第二期，我们将 GUI 方向的奖励做好后，发现这个 loop 其实是可以自动化跑起来的。只要他们末端部署的 Agent 能源源不断地收上来用户在真实环境下的反馈，我们就在想，为什么不让它自主地循环跑起来。所以我们在第二期给他们推了 EchoMind 这套产品。
👦🏻 Koji
现在提供的主要产品有两个：一个是 Pyromind Studio，另一个是 EchoMind。可以分别介绍一下它们是什么样的产品吗？
👨🏻💻 Kevin
Studio 是我们提供的解决训练 Infra 的 Serverless 服务。我们会在 Studio 上实现大量训练所依赖的逻辑节点。
之所以强调是逻辑节点，因为开发者在配置节点时不需要关心物理机上的实现，他们更多只是配置训练的参数。逻辑节点横向是支持 scaling 的，单卡算力、单台到多台，都可以在一个逻辑上扩展，扩展工作是由我们完成的。对于训练开发者来说，只需要把训练参数以及像 DP size、TP size 配备好就可以了。
对于 EchoMind 这套产品，我们把刚才叙述的整个 RSI 流程都包在了背后。我们给用户透出的是一个 proxy（一个代理的 URL），这个 URL 只要插入到某一个 Agent 里面，就可以源源不断地把 Agent 在真实环境下的轨迹抓取下来，形成一个相对整齐的数据集。
这个数据集通过奖励结构，生成 training pipeline 进行训练，拿到结果后再部署回去。这一套流程全部被 EchoMind 包起来了。
谁最适合 AutoRL？
👦🏻 Koji
Pyromind 现在典型的客户画像是什么？
👨🏻💻 Kevin
我们筛选客户时，核心是看他们是否需要真实世界的数据。并且，这些真实世界的数据首先要产生于生产场景，其次最好是在现有模型的能力之外。这对于模型效果的提升最明显。
我们当时在想，哪里的 Real-World Data 最富集？我们当下有一些比较重要的客户集中在工业领域，比如英伟达上游的这些企业。
他们有个特性，经过过去几年的制造 1.0、2.0 改造，企业内的数字化做得很不错，长期的生产也积累了非常可观的数据。这是一个指标。
第二个指标是，工业场景对于自己的精益生产是有定义的。收上来的数据天然带有相对明确的好坏标签，标注的问题在生产环节就被天然解掉了。
与此同时，毕竟这也是商业行为，我们也要衡量 ROI。在这三个条件都满足的情况下，产业链上的工业客户是一个比较好的画像。
👦🏻 Koji
工业客户是一类。还有其他典型的客户画像吗？
👨🏻💻 Kevin
还有像 Agent 或者是和具身相关的。
具身相关的我们也会看，但当下来看，具身是一个相对独立的板块。我们的目标还是去做后训练驱动的 RSI，当下在偏软的领域肯定会做得更快。因为具身还需要去考虑硬件部分，这是一个更复杂的问题。
👦🏻 Koji
在给企业做 RL，不管是 RL as a Service 还是做 AutoRL 的过程中，最花时间、最花钱的是什么部分？
👨🏻💻 Kevin
最花时间的实际上是初次进入一个场景时的 FDE 工作。虽然我们做 RSI，但我们并不排斥完全的 FDE，因为要让 RSI 渗透到某一个场景，初次进入时的冷启动阶段是不可省的。
我们需要把他们场景里面的数据制式、评价基准，与我们自己的 Reward Agent 或 Reward Model 适配到场景上，这比较花时间。
但好处是，在这类行业中，初次冷启动虽然需要做一些工作，但后面 scaling 起来，工作量是递减的。这是我看到的一个比较好的现象。因为做奖励这个事情，最终还是会收拢到模态上，在相似模态上，其实有相当一部分工作是可以复用的。
👦🏻 Koji
去年大批做 RL as a Service 的公司，现在大家都和你们一样，慢慢开始做 AutoRL 或者叫自己的 RSI 了吗？
👨🏻💻 Kevin
我觉得大家是有分化的。因为对于下半场的需求来说，它非常丰富且宽广。
比如我们同期去看的一些公司，比较出名的像 Applied Compute，到现在已经更往前走了一步。他们会提供一个非常完整的服务基础设施，把 Agent Serving 这些东西全部都做了。它面向的可能是几个头部的企业，把企业内所有和 Agent、AI 相关的东西全部包揽。这是一个路线。
另一个路线是近期比较出名的 Trajectory，它是 DeepMind 的人出来搞的一家非常优秀的公司。他们做的东西和我们的理念相似度相对会高一些，他们就是单纯地去做 RL。同时跟 Mercor、Clay、Harvey 也有一些合作。
他们的定义跟我们会相对相似，我们更期望做到的是 Auto 这件事情。我们去把无状态的 RSI 能力提供出去，做成可以平台化的东西。
👦🏻 Koji
无状态的？
👨🏻💻 Kevin
对。这两个分支的属性不同：前者 Applied Compute 相当于把企业里面所有的场景全部包掉了，是一个更宽并且更重的方式，它是在一个企业内纵向去 scaling；而后者 Trajectory 的方向是只把训练这一件事情做好，横向去 scaling。我们更倾向于用后者。
我们对环境的理解是，它原本在 coding 领域是一个非常典型的东西。你提供一个 compiler，每生成一个新的代码片段去 compiler 跑一下，都能够拿到一个比较强的奖励信号，判断它是否通过。它的特性是，跟你本身生产环境里面的这些信息是不耦合的，是可以被抽离出来的。
但对于实际的生产环境，这样的环境非常有限。比如刚才提到的 GUI 类的 Agent，想把每个用户的特定需求做好，是不能脱离它的用户上下文存在的。如果脱离了，就缺乏生产价值；如果跟用户上下文耦合在一起，它就是一个有状态的环境。
所以我们要去做的事情，是在这么长的链路里，找到可以横向 scaling 的无状态的东西。这个东西不单纯是一个 environment，而是一个 AutoRL 的管道。
你给它喂数据，它拿到数据后通过 Reward Agent 及 Reward Model 拿到 Reward Signal，去迭代一轮。这个 AutoRL 管道以及 reward 本身是无状态的，跟生产上下文不耦合。
👦🏻 Koji
这里