贾扬清创立Intent Lab:Fleet将一行提示词转化为生产系统
贾扬清创立 Intent Lab,并推出 Fleet,将一句话需求转化为生产级软件。本文介绍其自主工程团队模式、工作流程及其对 AI 软件开发的影响。

贾扬清创立Intent Lab:Fleet将一句话需求转化为生产级系统
引言
在Lepton AI成为NVIDIA一部分一年多后,贾扬清再次启程。
他的新公司Intent Lab并非以传统的聊天机器人、云市场或开发者IDE起步。相反,该公司正在构建Fleet——一个自主工程团队,能够将高层意图转化为生产级软件。
Intent Lab的首次公开演示包含三个截然不同的系统:
- 一个经过优化、超越标准TensorRT-LLM的GLM-5.2推理引擎。
- 一个根据一句话需求构建的SQLite兼容数据库。
- 一个面向AI代理、具备形式化验证和故障测试的分布式文件系统。
乍看之下,这些项目并不像同一产品类别。
这正是关键所在。
Intent Lab表示,真正的产品是这些项目背后的工程系统。Fleet的定位是完成从模糊的软件需求到可基准测试、可验证、可运维、可在生产中持续演进的系统之间的全部工作。
本文中的早期性能数据来自Intent Lab自身的发布材料。它们是有前景的演示,而非独立的基准认证。该公司尚未公布足够的可复现性细节,外部团队无法在完全相同的条件下确认每一项结果。
贾扬清再次创办基础设施公司
贾扬清的职业生涯屡次回归基础设施领域。
他最为人熟知的是在加州大学伯克利分校期间创建了Caffe,之后参与了包括PyTorch和ONNX在内的多项重大AI基础设施项目。
2023年离开阿里巴巴后,贾扬清联合创立了Lepton AI,一家专注于让开发者更便捷地使用GPU算力和模型部署的公司。
Lepton最初的理念将Python原生的开发者体验与可跨多家GPU供应商运行AI工作负载的基础设施相结合。
该公司于2025年被NVIDIA收购,当时公开报道称交易价值数亿美元。后来的行业报告将这一数字定在约7亿美元,不过NVIDIA并未公布最终收购价格。
Lepton的技术成为NVIDIA DGX Cloud Lepton的一部分。
NVIDIA目前将DGX Cloud Lepton描述为一个活跃平台,统一整合云服务商和客户自有基础设施上的GPU算力,用于开发、训练和推理。
这一现状值得澄清,因为贾扬清离开后的评论认为,原初创风格的Lepton产品及其开源愿景在收购后并未原封不动地延续。
公开证据支持更谨慎的描述:
- 独立的Lepton公司已被并入NVIDIA。
- 其品牌和技术成为DGX Cloud Lepton的一部分。
- NVIDIA至今仍在运营并维护DGX Cloud Lepton的文档。
- 公开的Python库和
lep命令行工具仍然可用。 - 早期关于将更深层次平台组件开源的某些预期,最终未
表单观察者期待中。
贾扬清后来担任NVIDIA系统软件副总裁,直到2026年离开该公司。
短暂停留Hyperbolic
2026年7月,Hyperbolic宣布贾扬清加入这家GPU基础设施公司担任顾问。
Hyperbolic形容他在Caffe、ONNX、PyTorch、Lepton AI、NVIDIA、Google、Facebook和阿里云方面的背景与其在GPU访问和基础设施方面的工作尤为相关。

这个角色最终并不是他的主要下一步。
7月29日,贾扬清公开介绍了Intent Lab。
他的定位与Lepton AI有所不同。
Lepton专注于让开发者更容易获取计算资源。
Intent Lab则专注于赋予自主工程系统创建和维护运行在该计算之上的软件的能力。
贾扬清总结这一转变时表示,他的团队过去多年一直精心逐一构建大型系统。现在他们感兴趣的是能够产出众多此类系统的系统。

Fleet是三个演示背后的产品
Intent Lab将其自主工程系统称为Fleet。
该公司将其描述为一个团队,而非单一的编码智能体。
这一区别很重要。
典型的编码智能体可以编辑文件、运行命令、修复测试、搜索代码仓库并实现功能。
Fleet则被定位为一个能够协调更长工程流程的系统。
Intent Lab宣称的目标是覆盖从高层级请求到生产系统所需的全部工作,并具备可衡量的
行为、验证以及持续改进的路径。
前三个
这些演示被选出来,是为了在截然不同的工程领域中检验这一论断。
演示一:在原生 TensorRT-LLM 之上优化 GLM-5.2
技术上最引人注目的发布成果是一个 GLM-5.2 推理引擎。
最初的指令本质上是一个工程目标:
重新设计 TensorRT-LLM,使 GLM-5.2 能在 Grace Blackwell 节点上高效运行,
识别优化机会,实施这些优化,并自主验证它们。
TensorRT-LLM 本就是 NVIDIA 面向生产环境的大语言模型推理栈。
NVIDIA 官方文档中描述了诸如多 GPU 和多节点服务、动态批处理、分页 KV 缓存、量化、优化内核以及 Python 和 C++ 运行时等功能。
因此,在此基础之上提升性能,比优化一个未优化的参考实现更具挑战性。
Intent Lab 报告输出速度提升 6.3 倍
Intent Lab 表示,Fleet 从原生 TensorRT-LLM 起步,速度约为:
102 tokens/s(每秒令牌数)
优化后的运行时达到了:
161 tokens/s
在加入该公司优化的投机解码路径后,系统据称达到了:
647 tokens/s
这大约是原始输出速度的 6.3 倍。

Intent Lab 表示,该基准测试使用了两个 Grace Blackwell 节点。
该公司将性能优化工作分为四个类别。
内核优化:+24%
据称,Fleet 应用了内核融合,并生成了底层 PTX/SASS 路径,以实现指令级控制。
运行时优化:+16%
Intent Lab 表示,该运行时通过 H2D 批处理和零拷贝技术,在稳态解码阶段消除了重复的主机到设备元数据复制。
通信优化:+18%
据称,Fleet 使用了一条融合的 MNNVL 全规约路径,将残差加法和 RMSNorm 合并到了集合通信操作中。
投机解码:约 4 倍
最大的单项收益来自投机解码。
Intent Lab 表示,优化后的 DSpark 草稿模型会提出多个候选令牌,主模型对它们进行批量验证,从而显著提高解码吞吐量。
该公司报告称,与原生基线相比,完整的端到端结果是 534% 的提升。
这些数字是 Intent Lab 自己的测量结果。硬件配置、工作负载细节、批处理设置、输出长度、精度、并发性和软件版本
可能实质性地影响推理基准测试。
Fleet的优化循环更像一个团队而非单次操作
Intent Lab表示,Fleet遵循一个重复的工程循环:
- 屋顶线分析
- 瓶颈识别
- 提出方案
- 验证
- 叠加优化
- 返回处理下一个瓶颈
如果提出的优化方案未能通过验证,系统会返回并重新尝试。
“叠加”步骤至关重要,因为当单独成功的优化互相干扰时,性能工程往往会失败。
Fleet的设计理念是仅在验证组合系统仍然正常工作后,才保留更改。
为什么GLM-5.2是一个高要求的优化目标
GLM-5.2 是Z.ai面向长时任务推出的旗舰模型。
其官方模型卡突出展示了百万级token上下文窗口、长时编程与智能体工作负载、灵活的推理力度、改进的稀疏注意力架构,以及MIT许可下的开放权重。
具有长上下文和智能体工作负载的大型模型会带来棘手的服务部署问题。
最快的实现方案取决于内核设计、内存带宽、KV缓存行为、互连带宽、批处理大小、投机解码、量化、主机调度和通信集合之间的相互作用。
这使得推理优化成为对自主工程系统的有效压力测试。
演示二:基于单一需求构建SQLite兼容数据库
Fleet的第二个公开项目完全脱离了GPU内核。
Intent Lab要求该系统构建一个与SQLite兼容的SQL数据库引擎。
发布材料展示的需求如下:
构建一个与SQLite兼容的SQL数据库引擎,
具体要求是能够通过所有sqllogictest测试用例,
并且性能必须相当或更优。
Intent Lab表示,Fleet并未从SQLite的源代码或文档开始。
相反,它将现有系统的行为和测试语料视为验收契约。

该公司报告称,最终系统通过了约六百万项SQLite兼容性测试。
该数据来自Intent Lab,本文未进行独立验证。
一个Fleet,多种工程角色
Intent Lab将数据库构建过程可视化为项目中多个角色的协同工作:
- 决策制定。
- 架构设计。
编程。
- 测试。
- 审查。
- QA。
这些角色并非简单地按线性顺序交接。
在实现进行的过程中,架构可能会发生变化。在添加功能的同时,测试仍在继续。随着代码库的增长,审查和QA始终保持活跃。
成本在很大程度上取决于模型
Intent Lab还发布了一份成本对比。
该公司表示,对于同一个数据库构建,使用Opus 4.8运行一次的成本约为2,000美元,而使用开源模型运行一次的成本约为350美元。
这些数字由公司自行报告,取决于模型价格、令牌消耗、代理编排和基础设施。
尽管如此,它们揭示了代理工程面临的一个重大经济问题:一个完整成功项目的成本是多少,而不是单次模型调用的价格?
演示三:面向代理的
形式化验证文件系统
第三个演示是一个名为AgentFS的分布式文件系统。
Intent Lab表示,它是专门为云环境中的代理工作负载而设计的。
AI编码和研究代理往往会形成一种独特的存储模式:
- 大量临时沙箱。
- 大量小文件。
- 频繁的创建和删除。
- 共享云存储。
- 高元数据变更率。
- 短期存在的仓库。
Intent Lab表示,它评估了包括Amazon EFS和S3FS在内的现有系统,发现这些系统在该工作负载下存在局限性,因此转而构建了一个新的文件系统。
该公司声称,在元数据密集型操作上,相比所对比的系统,性能有显著提升。

同样,这些是Intent Lab的发布基准测试结果,而非独立的第三方结果。
形式化验证发现了编码代理遗漏的Bug
文件系统示例中最重要的部分不是基准测试图表。
而是验证。
Intent Lab表示,Fleet对核心协议进行了形式化建模,并探索了大约190万个状态。
这一过程在编码代理生成的代码中发现了一个Bug。
该Bug可能导致分布式创建/删除行为期间出现瞬时损坏状态。
Intent Lab表示,Fleet随后修复了实现并重新运行了验证。
该公司还报告了大约300项集成测试,以及注入崩溃和副本的故障注入和模糊测试。
形式化验证在此处非常有价值,因为文件系统特别容易受到罕见交错事件的影响。
传统测试可能表明常见路径是正常的。而模型检查器可以系统地搜索普通测试无法覆盖的状态组合。
测试套件可能永远不会遇到。
这一原则在 Intent Lab 之外早已得到充分确立。文件系统研究人员数十年来一直使用模型检验来暴露成熟系统中的崩溃一致性和元数据错误。
这里的新颖之处在于,一个自主工程系统可以将这种验证方式纳入自身的构建循环中。
“能运行的代码”与生产级软件之间缺失的一层
贾扬清的核心论点比三个演示中的任何一个都更广泛。
现代模型可以快速编写代码。
但这并不意味着结果就是一家公司可以运营多年的软件。
他认为,剩下的差距不仅仅是模型编码能力的又一次跃升。
而是围绕模型的一层工程化体系。

一个生产系统需要的不仅仅是实现代码。
它需要需求、架构、接口、
权衡、协调、测试、性能分析、可靠性工作、验证、故障处理、维护以及来自生产环境的反馈。
编码模型可以参与所有这些活动。
Fleet 的核心论点是,它们需要被组织成一个自主系统。
Fleet 将工程流程分为六个阶段
Intent Lab 将其工程流程描述为六个阶段。

1. 理解
Fleet 应当将模糊的意图转化为具体的结果、约束、验收标准以及可衡量的成功定义。
2. 设计
Fleet 权衡利弊,并定义接口、组件和长期系统结构。
结构。
3. 协调
系统将大型项目拆分为任务,管理依赖关系,并使实现与整体设计保持一致。
4. 构建
随着开发过程中出现新信息,实现和架构共同演进。
5. 验证
验证可以包括单元测试、集成测试、基准测试、形式化证明、模型检查、故障注入、模糊测试和运行时验证。
6. 演进
Fleet旨在观察生产环境性能,并将使用情况、可靠性和成本信息反馈到设计中。
这正是Intent Lab的雄心超越自主编码代理之处。
目标不仅仅是软件生成。
而是自主软件所有权。
“有原则的工程团队”是产品隐喻
Intent Lab将Fleet描述为像一个有原则的工程团队一样运作。
这是一个有用的隐喻,因为一个强大的工程组织中没有任何单一成员负责所有事项。
一位工程师可能优化内核。另一位可能设计存储协议。还有人维护基准测试。另有人审查可靠性。
Fleet试图将这些职责转化为协调的代理角色。
因此,难题不仅仅在于LLM能否编写高质量代码。
还在于多个自主进程能否在长期内构建、测试、优化、验证和修订同一项目的同时,维持连贯的系统架构。
经济论点:软件可以变得更加定制化
Jia还提出了一个经济论点。
几十年来,软件开发具有巨大的固定成本。
理性的策略是构建一个产品,卖给许多用户,并让需求不同的用户适应同一款软件。
如果自主工程降低了构建和维护系统的固定成本,这一等式就会改变。

一家公司或许可以为较小的用户群体定制软件。
一个内部团队可以为此前可能需要积压数年才能处理的工作流构建系统。
一个基础设施团队可以创建专用引擎,而不是接受通用产品的局限性。
Intent Lab表示计划与外部组织合作开展此类项目:具有重要
企业因所需工作过于庞大而推迟的工程价值。
这与“一条提示词构建任何应用”不同
发布演示很容易被简化为一个病毒式标题:
一句话创建了一个数据库。
这种表述忽略了Fleet声称完成的大部分工作。
数据库示例从一个需求开始,但系统随后执行了一个漫长的工程过程。
它必须反复做出设计决策、生成代码、运行测试、诊断故障、修改架构、审查行为,并重复这些步骤。
用户提供简短意图。
机器不一定执行简短任务。
更好的评估应询问:需要多少人工干预、运行消耗多少计算资源、发生了多少次重试、结果验证程度如何、其他团队能否复现、以及演示之后系统是否可维护。
尚未得到验证的部分
Intent Lab的首批成果雄心勃勃,但公开材料留下了重要问题未解。
独立复现
6.3倍的推理结果、SQLite测试数量、AgentFS性能和形式化验证数据均为公司自行报告。
独立复现将大大增强这些声明的可信度。
Fleet架构
Intent Lab尚未公开记录足够细节来重建Fleet本身。
尚不清楚每个角色使用哪些基础模型、代理如何共享状态、任务如何调度、冲突如何解决、规格如何存储、以及保留了多少人工监督。
生产环境所有权
构建一个基准质量的系统与长期运营该系统并不相同。
“演进”阶段可能是整个论点中最困难的部分,因为生产所有者必须处理安全补丁、依赖变更、硬件更换、事故、成本变化、功能请求和向后兼容性。
经济性
自主工程在某些任务上可能比人工团队更便宜,但仍会消耗大量推理和计算资源。
Intent Lab自己的数据库示例表明,模型选择可能使项目总成本变化数倍。
更准确地理解Intent Lab的方式
Intent Lab不仅仅是一家另一家编码代理创业公司。
其论点更接近于自主系统工程。
目标工作单元不是代码补全或拉取请求。
而是生产系统。
这就是为什么前三个示例看起来互不相关。
推理引擎、数据库和文件系统在产品层面几乎没有共同点。
但它们共享一种工程模式:
意图
→ 规格
→ 架构
→
协调实现
→ 测量
→ 验证
→ 迭代
→ 生产演进
Fleet旨在自动化该模式。
它能否在众多真实企业中可靠地做到这一点,仍然是一个悬而未决的问题。
但雄心是明确的。
常见问题
Intent Lab是什么?
Intent Lab是一家新的人工智能基础设施和自主工程公司,由贾扬清和其他资深系统工程师联合创立。其首款产品Fleet旨在将高层软件意图转化为生产级系统。
什么
Fleet是什么?
Fleet是Intent Lab的自主工程系统。该公司将其描述为一组协同智能体,能够理解需求、设计架构、编写代码、验证结果,并在部署后持续演进软件。
Fleet真的让GLM-5.2推理速度提升了6.3倍吗?
Intent Lab报告称,其优化的GLM-5.2引擎将输出速度从标准TensorRT-LLM上的102 token/s提升至两个Grace Blackwell节点上的647 token/s。该数字是公司自报的基准测试结果,尚未在本文审查的来源中得到独立复现。
Fleet真的仅凭一条提示词就构建了一个数据库吗?
Intent Lab表示,最初的数据库需求只是一条提示词,要求构建一个兼容SQLite的SQL引擎。随后Fleet自主完成了架构设计、编码、测试、审查和质量保证,直到公司称系统通过了约六百万项兼容性测试。
什么是AgentFS?
AgentFS是Intent Lab在第三次发布演示中创建的分布式文件系统。它针对涉及大量沙箱和小文件的AI智能体工作负载进行了优化,Intent Lab表示其核心协议已通过形式化模型验证。
Fleet与普通编码智能体有什么区别?
普通编码智能体通常处理现有项目中的代码变更。而Fleet旨在协调完整的系统工程生命周期,包括需求定义、架构、实现、性能优化、形式化验证、故障测试和生产演进。
Fleet是开源的吗?
Intent Lab已公开发布演示和其产品理念,但本文审查的来源未显示完整Fleet编排系统的公开发布。请查看Intent Lab官网了解最新可用性。
NVIDIA DGX Cloud Lepton仍在运营吗?
是的。NVIDIA目前维护着DGX Cloud Lepton的产品页面和文档,包括工作负载、节点组、端点、Dev Pods、批处理作业和自带计算功能。这与人们对NVIDIA产品在多大程度上保留了Lepton AI原始创业路线图的争论是两回事。
相关工具
Intent Lab:构建Fleet的公司,Fleet是一个将意图转化为生产软件的自主工程系统。
NVIDIA TensorRT-LLM:NVIDIA的生产级推理框架,用于在NVIDIA GPU上优化和部署大型语言模型。
GitHub上的TensorRT-LLM:NVIDIA LLM推理栈的开源仓库。
GLM-5.2:Z.ai的开源权重长程模型,用于Intent Lab的推理引擎演示。
NVIDIA DGX Cloud Lepton:NVIDIA的平台,用于在GPU计算提供商网络中构建和部署AI工作负载。
SQLite:其行为和兼容性测试被用作Fleet数据库演示目标的数据库。
相关链接
- Intent Lab:将你的意图 进入生产系统:Intent Lab 的官方发布文章,也是 Fleet 演示的资料来源。
- 杨庆佳的 Intent Lab 公告:贾庆佳的公开帖子,介绍了 Intent Lab 及其自主工程理念。
- NVIDIA DGX Cloud Lepton 文档:当前该平台的官方文档,该平台源于 Lepton AI 的技术。
- NVIDIA DGX Cloud Lepton 发布:NVIDIA 2025 年的公告,描述了 DGX Cloud Lepton 及其全球 GPU 市场。
- GLM-5.2 官方模型卡:来自 Z.ai 的官方规格和模型文档。
- NVIDIA TensorRT-LLM 文档:官方架构、安装、优化、运行时和部署文档。
- USENIX:使用模型检查查找严重文件系统错误:一个经典案例,说明了为什么正式模型检查对于发现罕见文件系统正确性故障非常有用。
摘要
杨庆佳的新公司 Intent Lab 正在围绕一种不同的 AI 工作单元构建 Fleet:不是代码生成,而是完整的生产系统生命周期。
其首批演示涵盖 GLM-5.2 推理优化、一个兼容 SQLite 的数据库,以及一个经过正式验证的分布式文件系统。Intent Lab 报告称推理速度提升 6.3 倍,约六百万次数据库兼容性测试,以及对约一百九十万个文件系统状态进行的模型检查。
其核心理念是一个六阶段工程循环——理解、设计、协调、构建、验证和演进——试图用自主智能体重现强大工程组织的职责。
这些成果仍处于早期阶段,且大多是自行报告的,因此可复现性和长期生产运维仍然是真正的考验。
Fleet 最重要的主张不是 AI 能根据一句话编写代码,而是一个自主系统能够承担从一句话到值得运行多年的软件之间所有工程工作的责任。