自 ChatGPT 引爆公众认知以来，AI 开始渗透进写作、编程、设计等多个应用场景，推动人类进入“智能体（Agent）”时代。曾经遥不可及的自动化交互，如今正在成为现实。在这背后，一场关于基础设施的重构也悄然展开——从模型能力到部署体验，谁能打通智能 Agent 的“最后一公里”，谁就掌握了这场范式变革的主动权。
正是在这样的背景下，Agent-native PaaS（智能体原生平台即服务）作为一个新物种应运而生，它不仅要满足容器隔离、持续交互等技术需求，更要解放开发者、释放模型潜力。在这个关键转折点，一款 PPT 生成产品 DeckSpeed 仅用两周打造，就登顶 Product Hunt 月榜第一，让我们看到了 Agent 产品从“想法”到“爆款”之间的距离可以被极度压缩。而这款爆款背后的底座，正是由 CoreSpeed 打造的 Agent-native 开发与部署平台。
本期，我们邀请到00后创业者、CoreSpeed 创始人 Milton Yan。他从少年时代玩单片机起步，走过硬件到软件的转型，再到带领团队构建 Agent 运行时基础设施的全过程。我们将与他一同探讨：为何 Agent 产品的真正挑战不是模型能力，而是部署与交付？如何理解“每个用户一个容器”的必要性？在爆款 DeckSpeed 背后，有怎样的系统性工程力量与产品哲学？让我们一起走进这位年轻创始人的思考现场，拆解一个 Agent 时代的系统级创新故事。Enjoy！
- 我们现在一直坚持一个核心原则：只做那些我们有机会做到 10 倍提升的事情，而不是去卷一些“看起来很硬核”的方向。
- 既然每家做 Agent 的公司在部署Agent的时候都需要做容器生命周期管理、用户级路由等编排，并且做这些事情和Agent本身毫无关系，Skillset也与Agent开发者不match，那这就很适合由一家Infra公司来做个轮子，把所有Agent公司的边际成本转变成一家公司的固定成本。
- 做出一个“聪明”的 Agent 已经不再是难点，难的是“上线”——也就是如何真正把它部署到云端。....大多数人“能做 Agent”，但“不能部署 Agent”，更“无法大规模上线 Agent”。我们希望解决的，就是这“最后一公里”的问题。
- 所谓的Agent-native PaaS，不是“优化”，不是“堆叠编排层”，而是彻底舍弃会对Agent性能产生限制的传统组件，重构专门为Agent 设计的基础设施
- 无论是做产品还是做增长都是自己的一套思维，本质上是在道的层面深度思考过，于是在器和术的层面有一种野蛮劲儿，我很喜欢。
01 “爱折腾”的00后辍学创业，完成Agent开发平权和部署平权
ZP：从少年时期玩单片机到大学在黑客松夺冠，哪些关键节点最塑造了您的技术视角与创业基因？
Milton：我从小最想成为的样子就是既是工程师又是企业家。最开始是因为我姥爷，他小时候就开始玩无线电，他小学时候的第一个产品是收音机。我小时候在他的影响下，自己动手做了人生第一个“作品”——收音机，后来我复现了电磁炮、ZVS、特斯拉线圈等经典项目，在学校后山“遥控起爆”炸出蘑菇云。后来我在贴吧和各种国内外的技术社区认识了一帮技术宅朋友，玩单片机。“这些电工活其实很基础，但我那时候想实现一些更有趣更有创造力的东西，很自然地就接触了代码，学了编程。
本科阶段，我最开始读的专业是物联网工程，大半年后发现课程内容我基本上早在初中高中时候就会了，然后就转专业到了信息系统专业，想学点儿新东西。大学期间终于有更多的时间做自己的项目了，大一时候先做了一个可以用 Siri 语音控制的种植箱，很粗糙，但体验做得非常好，在中美创客大赛上一天内拿了十万元奖金，后来我用 SolidWorks 建模，3D 打印出来了外壳和各种结构部件，然后组装好所有传感器，电机和控制模块，把它做成一个接近正式产品的样机，那时候第一次开始接触到投资人。后来我集结了大学里最强的几个CS学生，苏豪，徐径舟，吴子昂，王溯，吕子涵，苑航等人开发了很多个软硬件项目, 拿了很多奖项和奖金，包括ESGrow机器手，滑雪机器人，脑机接口外骨骼机器人，QuickGPT，Speed虚拟专用网络，Meep，可听，知之等。
ZP：您刚才也提到了创业，能谈谈这种创业意识是怎么逐步建立起来的吗？
Milton：创业的意识是出生就有了的，幼儿园的时候就经常给身边的小朋友“分工”，经常幻想他们未来在我公司会扮演什么角色。小学开始我会在网上和生活中会主动结识在各方面有独特技能的人，把他们拉到自己身边。大学时候，学校会给一些好的创业项目分办公室和门面房，我是拿了四五个办公室，然后我在创业园里，把我觉得最强的隔壁友商，和各专业我觉得强的人，全拉进了自己的team，想一起干点儿大事。
做软件之后，节奏完全不一样了。软件是开发周期短、上线快，比硬件更容易做成熟，更容易商业化。从 2022 年ChatGPT 元年开始，我们做了一系列软件产品。其实做的一些GPT套壳没挣多少钱，但我们做的 Speed 虚拟专用网络却带来了四十多万的营收。它卖得很贵很贵，但很受欢迎，因为速度快、稳定性强，用户很买账。我们当时对各种网关协议研究得很深，这也是我们为什么那时候就知道 SSE 在HTTP 1.1协议下有队头阻塞问题等——虽然这些细节很多人不在意，但我们为了把延迟优化到极致，深入研究了这些。
有一天我和苏豪坐在办公室里看着电脑上的账单下饭，说毕业了以后直接创业，因为那时候我们就觉得创业其实是没有风险的一件事：就算一分钱的融资都没有，也能靠做个好产品养活自己至少保证不用去上班。
ZP：您数次在黑客松斩获奖项并发表 SCI/SSCI论文，这些经历如何帮助您识别 Agent 领域的空白？
Milton：我觉得论文本身和奖项本身没什么，经历过这些反而帮助大家祛魅。比如有个比赛要求做目标检测模型，大多数参赛者就直接套官方流程：先用 CPU 预处理、GPU 推理、再 CPU 后处理，然后大部分人认为比赛的重点在于去“卷”模型准确率，要么修改模型，要么喂进去更多更优质的数据，这其实就是在“炼丹”，性能提升是有限的。我们当时的策略完全不同。我们重点优化的是 CPU 和 GPU 的异步协同，让两边都不闲置，从而提升推理速度。效果比别人的方案快出一截。这种“反直觉”的路径选择，后来也成为我们做产品时的底层逻辑。到了做 Agent，很多人会问我们是不是搞模型、做不做强化学习。但我们不认为这是关键。现在的大模型已经足够强，真正的问题是怎么用好它。很多人硬要在一个不适合的问题上“加点 AI”，最后就是形式大于价值，本末倒置。
所以我们现在一直坚持一个核心原则：只做那些我们有机会做到 10 倍提升的事情，而不是去卷一些“看起来很硬核”的方向。这是我们识别机会、判断路径的底层方法论，也是我们在 Agent 领域找到空白点的方式。
ZP：您是如何想到开发Corespeed 这一Agent Native PaaS的灵感的？
Milton：最初的灵感来自我们2024年10月做的两款产品可听和知之，都是面向播客内容生成的自动化工具。虽然它们当时还不是真正意义上的 Agent，使用场景是：在arXiv上或者PitchBook等地方定时获取文章，或者允许用户传入一个文档或链接，系统会先进行 OCR 内容识别，再生成播客脚本，然后给不同角色分配不同的 TTS （Text To Speech）进行配音，并带入给角色预设的 prompt。这本质上是一个流程化的 pipeline/workflow，用户无法用自然语言进行实时编辑或插入干预，所以它并不具备Agent 的“交互性”，以及参与播客的所谓不同角色无非就是封装一些提示词假扮的。
尽管如此，这个产品依然获得了不少用户的认可。我们确实比 Notebook.lm 更早上线了这类功能，可以说在思路上是“平行发现”。但我们也在反思它的潜力和边界：它提升了用户的信息摄取效率，比如帮助快速理解一页 PPT，但归根结底，它仍然是一个内容消费工具。所以我们进一步思考：如果把这些播客角色“人格化”，让他们变成有自己的知识库、自主调用工具、自主思考的 Agent，会发生什么？如果他们不仅能讲内容，还能在过程中与用户互动，甚至支持用户随时插话、提问、纠正，那就不再是听故事，而是真的能够达到咨询级别的“交付级产品”。
于是我们开始尝试构建这样的角色 Agent。我们做了两三个原型，比如Agent化的投资人，教授，通过阅读习惯，阅读的内容，使用的工具等等来收敛Agent，结果发现，即便不依赖 RAG、LangGraph，仅凭大模型本身，就已经足以支持复杂的 reasoning 和 planning。这让我们意识到：做出一个“足够聪明”的 Agent 已经不再是难点，难的是“上线”——也就是如何真正把它部署到云端。实际使用过程中，用户被允许通过Agent写代码，从而完成工具调用并能够提出很多个性化修改需求。不可能让所有用户共用一个 Agent 实例，那就很容易出现串扰、冲突，进而造成隔离性、安全性上的严重问题。
这正是我们决定做 CoreSpeed 的出发点。我们发现，市面上很多所谓的 Agent 产品，其实根本不是“真 Agent”。你只需要看它有没有做到“一个用户一个容器”，如果没有，那它根本谈不上是真正的 Agent。很多所谓“Agent”产品仍然是把大模型当作流水线的工人，而不是决策主体。
而我们想做的，是把大模型变成真正的“执行大脑”——它能自主规划、推理、调用工具。这种架构一旦跑通，不仅能带来性能上 10 倍、100 倍的提升，更能释放大模型真正的能力。但前提是：必须为每位用户提供独立的容器环境。
我们一个一个调研了当时的容器方案，比如 E2B。虽然它有开源和SaaS版本，但开源版本部署成本非常高：你要给AWS 每个Cluster一个月付 6000 美金，对多数初创团队是不现实的。而SaaS版本功能其实很单一，采用者还是得自己做编排。我们当时就在想：既然每家做 Agent 的公司在部署Agent的时候都需要做容器生命周期管理、用户级路由等编排，并且做这些事情和Agent本身毫无关系，Skillset也与Agent开发者不match，那这就很适合由一家Infra公司来做个轮子，把所有Agent公司的边际成本转变成一家公司的固定成本。这样每家Agent团队就能专注Agent业务逻辑本身，而不是重复造编排层的轮子。而我们也确实具备这样的底层能力。我们做Speed虚拟专用网络时就深度掌握了底层网络协议、容器编排和隔离机制，知道如何构建一个高性能、强隔离、可扩展的 Agent运行时平台。
最终，我们的目标是：让各种垂类Agent开发者做出数以万计的交付级Agent轻松上线，不再需要是“懂K8S的人”才能玩得转 Agent。这背后其实也贯穿了我从小到大的信念：找到志同道合的人，一起创造有用的新东西，并让所有人把自己的潜力发挥到极致。这件事对我来说，不是刻意选择的创业方向，而是一个非常连贯的过程。
02 CoreSpeed Agent Native PaaS：构建让 Agent 真正跑起来的重系统
ZP：为什么您认为 2025 年前后是窗口期，从而选择在这个时间点启动 Corespeed？
Milton：这其实是一个技术演进的自然节点。上下文已经足够长了，今天的Agent开发者已经不需要用LangGragh之类的框架了，工具函数，工具调用的范式也逐渐成熟了，包括MCP/A2A协议的出现，都加速了Agent开发范式的成熟，那么现在在本地做出一个Agent已经变得简单许多了，而虽然本地做一个Agent变简单了，上线一个Agent还是很难。
所以2025 年是各种垂类 Agent 爆发的前夜。当有像我们这样构建 Agent 原生Infra的公司出现几家以后，各种垂类 Agent 将开始全面涌现。一个很典型的例子就是OpenManus。Manus发布后GitHub 上立刻冒出各种OpenManus，拉到本地以后立马就可以是一个CopyCat Manus，这种几千、几万 Star 的开发Agent Framework项目一大堆，但为什么市面上没有一万个Agent或者一万个CopyCat Manus？"
原因很简单：他们能在本地跑但不能部署，更别说支撑多用户服务和规模化上线。
这正是我们看到的机会点：大多数人“能做 Agent”，但“不能部署 Agent”，更“无法大规模上线 Agent”。我们希望解决的，就是这“最后一公里”的问题。这，就是我们选择此时此刻启动 Corespeed 的根本原因。
ZP：我也想请教一下，您如何定义 Agent-native PaaS？Corespeed 自称为 PaaS 平台，它和传统 PaaS 有何本质区别？
Milton：我们特别强调的是“原生（native）”。传统 DevOps 和 PaaS 平台是为传统应用设计的，无法原生支持部署Agent的各种特殊需求，并且往往有容器数量上限，使得现在Agent开发者往往需要在现有的DevOps上堆叠很多Orchestrator，工程复杂度飙升，并且Agent 通常使用SSE 协议作为通信协议，而如果基础设施组件不支持 HTTP/2 及以上的协议，传输就会极其卡顿——一个 prompt 发出去，Agent与LLM多轮对话下来可能要等上十几分钟。
所以其实不能用上一代 DevOps 方案来部署Agent。所谓的Agent-native PaaS，不是“优化”，不是“堆叠编排层”，而是彻底舍弃会对Agent性能产生限制的传统组件，重构专门为Agent 设计的基础设施，我们把它称为 Agent-Native Infa，Agent-Native PaaS, AgentOps。Agent 是一个新范式——它不是工具的简单堆积，也不是信息的简单聚合，而是具备自主思考、推理和行动能力的智能体。既然 Agent 是新物种，服务它的 Infra 也必须是全新的，不能套一个旧壳，贴个 AI 标签就了事。CoreSpeed 就是我们为这种未来打造的运行平台，是为智能体而生的基础设施。
ZP：那你们的两款核心产品——Zypher Agent Framework 和 CoreSpeed.io——分别解决了哪些核心痛点？有没有具体场景可以分享？
Milton：这两个产品解决的是 Agent 开发和部署两个环节：
•Zypher 是 Agent 的开发框架，帮助开发者在本地构建强大的 Agent。
•CoreSpeed 是 Agent 的部署平台，帮你把 Agent 稳定、高效、安全地“上线”给成千上万用户。
先说Zypher。它有三个关键能力：
第一，自主工具调用能力。Zypher是一个可组合、可自主调用工具的 Agent开发框架，那其实Zypher本身不加改动的情况下就可以作为一个通用Agent了。在 GAIA Benchmark 上Zypher的跑分目前是全球开源Agent框架里的第一名。开发者只需要在Zypher的工具list里填入工具，无论是开发者自己写的工具，还是接入外部工具，然后通过提示词和权重等手段完成并不断优化对工具的编排即可，这才是Agent开发者最应该做的有意义的事情。
第二，Indexing：Indexing的功能就是对整个代码仓库与运行时上下文进行语义分块和依赖解析，然后给每一个函数、类、配置文件甚至可视化元素建立一张细粒度的知识图谱，完成全局理解。然后当Zypher让LLM生成出新代码和新内容之后，Indexing会按照语义锚点（而不是简单的行号或者diff）把这部分代码和内容精准插入到代码仓库和上下文里合适的位置，保持依赖完整、不破坏作用域、不引入代码风格漂移，随后它会自动添加 import、更新引用、同步测试用例，并在 CI 管道里触发最小影响范围的回归测试。当用户要微调某一部分内容的时候，Zypher通过Indexing会精准找到这部分内容相关的所有代码，依赖和上下文，然后仅把部分子图交给LLM做出修改，再把修改结果Patch回去，确保其他无关模块 0 影响，同时保持代码风格、lint 规则和 commit 规范一致，简而言之就是精准修改局部，不会对其他不需要被修改的部分产生影响。那比如在我们的show case产品Slide Agent：DeckSpeed里的体现就是，“请你把第四页左上角的柱状图改为折线图”，然后你会发现DeckSpeed精准定位到了第四页左上角柱状图的相关代码，然后完成精准微调，改成折线图，charts的风格也和上下文保持了统一，也不会改动到这一页的其他任何部分的内容。那还比如我们最近的一个use case，我五天内见了四次这个team，几个来自暴雪动视的开发者，基于Zypher Framework做了个原型，产品一句话描述就是Cursor for Unity，用户输入一句prompt：“给这个场景加上 light effect、shadow、音效和贴图”，然后Zypher就先通过Indexing在项目中找到与当前场景关联的 GameObject、材质、ShaderGraph 文件及 AudioSource 设置，然后Zypher让LLM 生成的灯光、阴影参数、贴图引用和 AudioClip 代码片段，会被 Indexing 精准插入到对应 Prefab 或脚本中；引用计数、资源路径、Lightmap 设置全部自动更新，最终的结果就是场景立刻焕然一新，但物理碰撞、UI 逻辑、网络同步等无关模块完全不受影响，开发者也无需担心 merge 冲突或资源丢失。
第三，Checkpoint管理，就是允许用户像用Git一样做好版本管理。当one shot start之后产出一个用户80%满意的产出物以后，用户要不断的提出修改意见给agent，human in the loop，然后每一步改动看到结果以后都可以做一次判断，更好了还是更差了，于是checkpoint管理允许用户accept本次修改或者Reject本次修改，让产出物回滚到上一个版本，那么这个功能就是一个基本的智能的体现，llm做出的修改变成了可控的。未来模型能力即使再强，用户仍然是需求的制定者和产出物的把关者，所以Checkpoint管理是agent必备的功能。那这个功能的show case其实有很多了，现在我想给某一页ppt加一个边框，加完以后看到效果发现还不如不加，于是就回滚回去，那其实这个功能Cursor，Trae等等一系列Agent产品都有，然后Zypher是开发框架，希望原生就提供给Agent开发者提供好这个能力，不需要Agent开发者重复造轮子。
ZP：非常具体，那再说说 CoreSpeed.io吧？它解决的到底是哪道“墙”？
Milton：一句话概括Corespeed.io，Agent 产品允许用户写入大量不可信代码（Untrusted Code），所以你必须实现“每个用户一个容器（per user per container）”。
这就引出一系列新需求：保证容器快速的冷启动，用户级的容器路由，容器的动态生命周期管理（不然用户用完后容器挂着不销毁，你的成本就会指数级爆炸）。而传统的Infra和DevOps都服务于传统应用，无法原生支持部署Agent的这些特殊需求，使得现在Agent部署上线的门槛很高，开发者不仅要写Agent逻辑，还得熟练掌握DevOps、K8s、CI/CD等大量基础设施的skill，才能在现有平台上堆叠出一整套Orchestrator来跑通Agent，而这些弯路其实与Agent本身的“智商”毫无关系。和 Agent 解决问题的能力毫无关系。所以我们看到很多产品根本没法上线，用户发一句话，结果 20 分钟才返回初次生成结果。
而 CoreSpeed 做的事情是：砍掉所有影响 Agent 性能的组件，仅基于容器这个基本单元完成了Agent Native的PaaS。保证了容器快速的冷启动，完成了自动扩容，CI/CD，用户级的容器路由，容器的动态生命周期管理等核心能力，全链条重构，保证每个 Agent 都能高效上线，快速运行，原生的Agent Infra会让Agent运行流畅，Agent的用户直观感受到的就是Agent解决问题的速度变快了。我们横向对比测算，原来需要 20 分钟返回某一任务结果的 Agent，迁移到 CoreSpeed PaaS后返回同一任务结果只要 3分钟，未来甚至能做到 1 分钟内返回——这会大幅释放 Agent 产品性能。
03 CoreSpeed改写 Agent 的开发体验：让开发从数月降到 1周
ZP：那么在我们平台上是否有一些面向用户落地的成功Agent应用呢？
Milton：很多人是因为PPT Agent产品DeckSpeed登上了Product Hunt 5月月榜第一关注到我们的，但DeckSpeed其实是由2个开发者基于Zypher Agent Framework 和 CoreSpeed.io在仅仅两周内开发出的产品。
开发团队其实只做了几件事情：用Trae把Zypher项目打开，给Agent写个系统提示词，然后写几个和PPT相关的核心工具——一个排版工具，一个生图工具，一个渲染工具，一个字体工具，一个 Web Scripting 工具，再3分钟写个UI界面。通过系统提示词和工具编排来收敛住Agent的任务边界（而不是能力边界）
在Agent开发上最难的部分，其实不是写工具本身，而是你如何把人类执行任务范式转化成 Agent 能执行的工具调用体系范式。举个例子，DeckSpeed的生图工具代码就十几行，其中一行还是调用 image-1的 API。写工具不难，难的是编排：什么时候该调哪个工具、怎么设计触发规则、如何设定权重——这些才是 Agent 工程的核心。
ZP：DeckSpeed给CoreSpeed带来了什么样的正反馈？
Milton：DeckSpeed带来的信号意义非常强：在 Zypher + CoreSpeed 的组合下，、两周能迅速上线Agent 产品，然后登上 Product Hunt 的日榜和月榜第一，真正靠社区投票拿下的月榜第一，得到了多所名校的背书——包括纽约大学、苏黎世联邦理工的官方支持，北大、斯坦福的教授的主动站台推荐，并且最终在1个月内验证了试用付费转化率高达 27%
ZP：为了未来平台能产出更多像 DeckSpeed 这样的案例，你们接下来有哪些具体的策略？
Milton：我们会重点推动“案例营销”，而不是仓促去做“仓库营销”。也就是说，我们不会浮躁地买PR把Zypher营销成看起来很炫的项目仓库，GitHub的星数仍然是一个商业指标，短期内我会去深挖几个有实际价值、打得透的产品案例，真正跑通开发—上线—用户转化的全流程。比如像前面提到暴雪的那个团队，我们就会重点支持他们的Zypher for Unity项目，把项目打磨成行业爆款，然后利用他们的影响力去反哺平台，带动更多开发者跟进，这才是正向飞轮。Zypher Agent Framework现在也已经成了纽约大学工程学院的Capstone课程项目之一，让NYU的一些学生用Zypher 做出自己的Agent作为期末课程作业，并且NYU，NVDIA，字节跳动等将会配合我们联合发起一系列黑客松活动，让更多开发者用 Zypher 和 CoreSpeed 搭建实用的 Agent 产品。
那前面提到了Cursor for Unity这款Zypher的用例，那我觉得以此为参考，我会希望看到出现一些交互式的3D内容生产-比如Blender/Unreal的场景助手这种东西出现，那首先就和Unity的情况很像，3D 场景的搭建、灯光、材质、粒子特效和动画要在十几种面板间来回跳转，迭代是极慢的，如果你把它们Agent化以后，就可以像 Cursor for Unity一样“一句 prompt”完成复杂改动，场景图是层级树，非常容易做语义定位，并且Blendar/Unreal都支持Python API，可以直接注入CoreSpeed的容器沙盒，并且这些Agent做出来以后用户群本身就是Prosumer，付费意愿付费能力人均软件支出都很高。然后Blender 社区 > 400 万月活，Unreal Market 年交易额 > 2 亿美金，创作者强烈依赖插件，这种情况下对带火Agent背后的Zypher Framework和CoreSpeed都非常重要。
再比如类似的，从建筑领域的CAD，BIM入手，或者视频后期，音频后期等场景，核心就是希望看到“1.复杂度高、2.迭代频次高、3.资产生态丰富的垂直工具通过Zypher来完成Agent化
ZP：那你们筹备中的“硅谷黑客松”活动，会如何加速开发者生态？你们会提供哪些资源和支持？
Milton：字节跳动的Trae的产品力非常强，我们团队也是Trae的重度用户，Trae和Zypher是天然的合作伙伴，开发者可以clone下来Zypher，在Trae里面打开Zypher项目，然后通过自然语言借助Trae写代码，给Zypher Framework装上手和脚（就是工具），然后编排好这些工具，无疑Trae+Zypher能做出Agent，CoreSpeed帮助快速上线Agent，我相信这样的活动一定会出现大量的优秀的Agent产品横空出世。
这三者结合：Trae + Zypher + CoreSpeed，就是完整的一条工具链，从写界面、完成系统提示词和工具编排，到产品部署，无缝衔接。而黑客松的意义在于，帮助开发者在最短时间里形成交付，通过平台自带流量快速试错、尝试商业化，对我们来说，这才是真正的生态推动。
ZP：那对于 CoreSpeed 而言，未来三年里你们最关注的用户核心指标是什么？
Milton：对于一个面向 To Prosumer/B Agent 的 Agent-Native PaaS 来说，更具判断力的核心指标是“容器层级的使用情况”。比如：
•每天启动了多少个容器？
•每个容器的平均使用时长是多少？
这些才是真正能衡量我们 Infra 能力和商业化潜力的数据。因为你只看 Agent 数，不知道它们是否“上线了”“被用了”“有留存”；而看容器启动和持续使用时间，就能清晰看到——
•是否有终端用户真实使用？
•是否具备可交付能力？
•是否存在持续留存与复用？
这些指标决定了平台的实际运营规模，而商业指标（比如平台总营收、Agent 收入）都是在此基础上的后置变量。这种数据的持续增长，才是我们最在意的。
ZP：您经历了从学生到 CEO 的身份转变，在这个过程中有哪些技术或商业上的挑战？有没有走过弯路？又是如何克服的？
Milton：对，其实挑战是每天都在遇到。这问题真要展开说，我一下子也想不起所有细节，但我可以分享一个最近很关键的转变。
我们一直在创业，学生时代也一样。但当时我们的思维是：以“零成本”或者极小成本撬动一件事。那时候我们有任何事儿就自己做，能不花钱就不花钱，经常开心的事情就是别人花了一万美金解决的事情，我们花了200块解决了。但现在作为 CEO，要做的事情完全不一样。比如我们上一轮融资后，过了很长时间只花了 1-2 万美金。我们当时太节省了，也是有点儿“不敢花钱”，总想着“省着点花”。但现在我意识到：CEO 的首要职责，不是节省成本，而是推动业务顺利发展。你资金充裕了，就要敢于投入，把关键路径跑通，再回过头来优化成本。不能因为省钱而拖延执行，把节奏耗没了。这其实对我来说就是从“学生心态”到“CEO 视角”的一次结构性转变。所以，现在的我们不再追求“零成本撬动小事”，而是敢于为实现大目标投入必要成本，承担更大的资源调度责任。
最开始我带领团队谈下一些合作，拿到一些看似很神奇的资源，真的站上更高的平台之后，我意识到，那些站在更高的平台的人，也是要主动撬动资源的，于是我就明白不管今天手里握了几张牌，都无非就是不断制造筹码，不断撬动资源，不断往上爬，只要看清合作的关键，没有谈不拢的交易。以及在今天拿了很有名的机构的融资之后，要对自己要求更高，拿了更多的筹码以后要撬动更多更大的资源。
ZP：可以分享您自己比较感兴趣的几家 AI 领域创业公司吗？
Milton：我最近特别感兴趣的：Cluely，他们创始人是一个被哥大开除的00后。他们最开始的产品叫 Interview Coder，是一个面试作弊工具。我觉得他们非常有洞察力，他们发现操作系统其实可以通过声明和标记来“禁止截图或录屏”。就像你在 Apple Music 播 MV 时截图，MV 区域会变黑，这是系统层的控制。他们就把这个点应用到视频面试场景：把关键窗口声明为不可录制区域，实现“你能看到，但视频会议软件录不下来，于是面试官看不到”。包括Cluely的任务也是 端侧+云端协同完成的，延迟非常低，体验很好。我喜欢他们是因为他们足够野蛮，Day1在创业，Day1对名校和大厂祛魅，无论是做产品还是做增长都是自己的一套思维，本质上是在道的层面深度思考过，于是在器和术的层面有一种野蛮劲儿，我很喜欢。
请注意，此次访谈内容已经过精心编辑，并得到了Milton Yan的认可。欲了解更多关于Milton的信息，敬请访问其官方网站https://corespeed.io/zh。我们也欢迎读者通过留言互动，分享您对本访谈或XX的看法。
Z Potentials 将继续提供更多关于人工智能、全球化市场、机器人技术等领域的创业者访谈。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。
文章来自于微信公众号“Z Potentials”。
