贾扬清离开英伟达一个月后再创业。新公司叫 Intent Lab，核心产品是一套名为 Fleet 的自主 AI 团队系统。2026 年 7 月 28 日，Intent Lab 公布了三项早期成果：把 GLM-5.2 推理速度提升 6.3 倍、从零构建通过 600 万项测试的数据库引擎、打造通过形式化验证的 Agent 文件系统。三项工作均由 Fleet 端到端自主完成，无人工干预。
Fleet 不是编程助手，是工程团队
过去两年涌现了大量 AI 编程工具：GitHub Copilot 补全代码，Cursor 辅助重构，Claude Code 执行多步编程任务。这些工具的共同特点是"辅助人类写代码"——人类负责设计架构、定义接口、规划任务，AI 负责生成实现。
Fleet 想做的是更上层的 abstraction。贾扬清在 X 上写道："模型现在写代码已经很快了，但从'能跑的代码'到'能放心投入生产并维护多年的软件'，中间仍有距离。我们想补上这一层。"
Intent Lab 将 Fleet 的工作流程拆解为六个环节：
理解（Understand）：大多数项目始于模糊的意图。Fleet 与用户共同明确目标，将其转化为具体结果，并确定验收标准。
设计（Design）：Fleet 权衡架构方案的 tradeoff，确定接口和数据结构，记录每个设计决策对系统其余部分的影响。
协调（Coordinate）：将项目拆分为可独立管理的子任务，管理任务间的依赖关系。
构建（Build）：在编码过程中根据新发现的信息同步更新架构设计和代码实现，使方案与运行系统保持一致。
验证（Verify）：从形式化证明到运行时故障注入，多种方式持续验证。
演进（Evolve）：软件上线后，Fleet 监控实际运行表现，将使用情况和成本信息反馈到设计中。
这六个环节构成了一个闭环：意图进入，生产级软件输出，然后持续维护。区别于单次代码生成，Fleet 强调的是"长期维护生产系统"的能力。
第一项成果：GLM-5.2 推理速度从 102 提升到 647 token/s
Fleet 接到的第一个任务：重新设计英伟达 TensorRT-LLM 的代码，让 GLM-5.2 在 Grace Blackwell 计算节点上运行，并自主寻找、实现和验证优化方案。
TensorRT-LLM 本身已经经过英伟达大量优化。在这个基础上再提速，难度很高。Fleet 从四个层面入手，逐步叠加优化效果：
内核层（Kernel）+24%：Fleet 通过内核融合减少内核启动次数，并让 Agent 直接生成 PTX 和 SASS 指令级代码，绕过编译器的限制，将量化操作折叠进 norm 计算中。这一层把推理性能提升 24%。
运行时层（Runtime）+16%：利用 Host-to-Device 批处理实现稳态解码零拷贝。优化前，每个解码步需要进行约十次主机到设备的元数据拷贝；优化后降为零。
通信层（Communication）+18%：Fleet 将集合通信的 all-reduce 操作、残差相加和 RMSNorm 融合为一个操作。这消除了每层一次额外的内核启动和一次完整的内存往返。
推测解码（Speculative Decoding）×4.0：加入优化后的 DSpark drafter，每步提出多个候选 token 并一次性验证。这一步将推理速度进一步提升约 4 倍。
四个优化叠加后的端到端效果：
| 配置 | 输出速度 |
|---|---|
| 原版 TensorRT-LLM | 102 token/s |
| + 内核/运行时/通信优化 | 161 token/s |
| + DSpark 推测解码 | 647 token/s |
647 token/s，端到端提升 534%（即 6.3 倍）。Intent Lab 称这是目前 GLM-5.2 达到的最快推理速度。整个过程没有人工介入。
优化策略本身也是自主生成的。Fleet 先做 Roofline 分析确定性能上限，再识别瓶颈，提出优化方案，验证效果。验证失败的方案被丢弃并重试，验证通过的方案保留并进入下一轮。这套循环自动运行，直到性能不再提升。
第二项成果：一句指令构建数据库引擎
Fleet 的第二个任务是系统现代化（Modernization）：从一条初始指令出发，构建一个与 SQLite 外部行为完全兼容的数据库引擎。
关键约束：Fleet 参考的是 SQLite 测试集而非其现有源代码和文档，以测试集作为验收标准。整轮运行产生 8720 万个输出 token，最终通过全部 600 万项验收测试。全部使用开源模型时，成本约 350 美元（约合 2368 元人民币）。
这个任务展示的是"行为兼容的从头重建"：外部接口和行为完全匹配既有系统，内部架构从零设计。对工程团队来说，这类任务的工作量通常大到无人愿意排期——这正是 Intent Lab 想切入的场景。
第三项成果：带形式化验证的 Agent 文件系统
第三个任务（Creation 类）是构建 AgentFS，一个面向 AI Agent 的分布式文件系统。这个任务最能体现 Fleet 的验证能力。
AgentFS 的性能数据（mdtest 测试基准）：
| 操作 | 相对 EFS 倍数 |
|---|---|
| 目录和文件创建 | 45 倍 |
| 文件读取 | 30 倍 |
| 目录状态查询 | 626 倍 |
| 文件状态查询 | 625 倍 |
在 Agent 高频使用的状态查询操作上，AgentFS 的速度达到 AWS EFS 的 626 倍。这种性能差异来源于架构选择：AgentFS 专门针对 Agent 的读写模式（频繁状态查询、低频大文件传输）做了优化，而 EFS 是通用网络文件系统。
验证方面，Fleet 在 31 个模型中检查了约 190 万个可达状态，覆盖不同的并发序列、系统崩溃和竞态条件。此外还完成了约 300 项集成测试，以及故障注入和模糊测试。开发过程中，形式化验证自主发现并修复了瞬态数据损坏漏洞。
这个结果的意义在于：AI Agent 自主构建的文件系统，在正确性上通过了传统软件工程中最严格的形式化方法验证。
创始团队：Lepton AI 原班人马
Intent Lab 的创始团队延续了 Lepton AI 的核心阵容。贾扬清（Yangqing Jia）是 Caffe 深度学习框架的创建者，曾任职阿里云副总裁、Facebook AI 研究院。联合创始人白俊杰（Junjie Bai）是 ONNX 的共同创建者，李响（Xiang Li）是 etcd 的创建者，Casber Wang 也是早期成员。
2023 年贾扬清创立 Lepton AI，提供 GPU 云服务和 AI 推理平台。2025 年 4 月英伟达以约 7 亿美元收购 Lepton，更名为 DGX Cloud Lepton。收购后据媒体报道，该平台在 2025 年中期已基本停止对外运营，核心调度器开源承诺未能兑现。贾扬清在离开英伟达约一个月后创办 Intent Lab。
团队背景解释了 Fleet 的技术方向选择。贾扬清在 AI 基础设施领域积累了十余年经验（Caffe → Facebook AI → 阿里云 → Lepton → 英伟达），这条路径从"管理计算"自然延伸到"构建系统"。Caffe 和 ONNX 解决的是模型定义和互操作问题，Lepton 解决的是推理部署问题，Intent Lab 要解决的是软件生产本身的自动化问题。
Fleet 与现有 Coding Agent 的区别
目前主流的 AI 编程工具可以按自主程度分几个层次：
补全层：GitHub Copilot、Codeium。在 IDE 中补全单行或小段代码，人类做所有架构决策。
任务层：Cursor、Windsurf。能执行多步编程任务（重构函数、修复 bug），但工作范围限于人类定义的上下文。
Agent 层：Claude Code、Codex CLI、Devin。能自主完成一个完整任务（实现一个功能、修复一个 issue），包括读代码、改代码、跑测试，但仍限于单次任务交付。
系统层：Fleet 要做的。从模糊意图出发，自主完成架构设计、任务拆分、编码、验证、部署、持续维护的完整闭环。
Fleet 的差异化在于两个维度。第一个是范围：不只是写代码，而是承担完整工程团队的角色。第二个是验证深度：不只跑单元测试，而是用形式化验证、故障注入、模糊测试等方法保证系统正确性。
从三项早期成果看，Fleet 目前展示的能力偏向底层系统软件（推理引擎、数据库、文件系统），这些领域对正确性和性能的要求极高，恰好是形式化验证和自动化测试能发挥最大价值的地方。
行业意义
Intent Lab 的定位回应了当前 AI 编程领域的一个核心争论：AI 能否超越"辅助工具"角色，成为真正的自主系统？
三项成果的共同特点是：任务规模大（8720 万 token、600 万项测试、190 万状态验证），领域硬核（推理引擎优化、数据库重建、文件系统形式化验证），完全自主（无人工干预）。如果这些数字可靠，说明 AI Agent 的能力边界正在从"代码生成"扩展到"系统构建"。
贾扬清在官网上写道："过去五十年，软件是为最广阔的市场构建的，你需要弯曲自己的工作流去适应它。这种情况即将结束。"这句话指向的是一个愿景：每个组织、每个工作流都能获得定制化的软件系统，而构建这些系统的成本由 AI Agent 大幅降低。
Intent Lab 目前正在寻找首批企业客户，优先接手"工程量太大、长期没人排期"的项目。这个市场定位很明确：不与 Cursor、Copilot 竞争日常编码辅助，而是瞄准企业内部积压的大型系统工程项目。
当然，三项早期成果都是 Intent Lab 自行选择和公布的演示案例。在实际企业环境中，需求更模糊、约束更复杂、遗留代码更混乱，Fleet 能否保持同样的自主度和可靠性，需要更多独立验证。