7 月 29 日，贾扬清宣布启动 Intent Lab，并发布自主 AI 团队 Fleet 的三项早期成果。Fleet 不是编程 Agent，而是试图承担一支完整工程团队从理解需求到持续演进的全流程工作——首个任务就把 GLM-5.2 推理速度提升了 534%。
Intent Lab 对 Fleet 的定位非常明确：它不是只负责编写代码的编程 Agent，而是试图承担一支完整工程团队的工作。
主要负责编写代码——接收需求，输出代码片段。
从理解需求、设计架构、协调任务，到编写代码、测试验证和上线后的持续改进。
Fleet 的工作方式类似一支遵循工程原则的软件团队，整个开发流程包含六个环节：
大多数项目始于模糊意图，Fleet 会先与用户共同明确目标、约束条件和验收标准。验证贯穿全程——综合使用形式化证明、集成测试和运行时故障注入。软件投入生产后，Fleet 继续观察实际表现，将使用情况、性能和成本反馈到设计中，持续改进。
Fleet 的第一个任务是重新设计英伟达大模型推理优化工具 TensorRT-LLM 的代码，让 GLM-5.2 在 Grace Blackwell 计算节点上运行。TRT-LLM 本身已经过大量优化，想进一步提速并不容易。
Fleet 从四个层面入手，端到端推理速度从 102 token/s 提升至 647 token/s：
内核融合 + Agent 生成的 PTX、SASS 代码，减少内核启动开销。
利用 H2D 批处理实现稳态解码零拷贝。
集合通信、残差相加和 RMSNorm 融合处理。
加入 DSpark，一次提出并验证多个候选 token。
整个优化过程由 Fleet 自主推进：先分析性能上限、识别瓶颈，再提出和验证优化方案。未通过验证的方案会被放弃并重新尝试，通过验证的方案则被保留进入下一轮。据 Intent Lab 称，这是目前 GLM-5.2 所达到的最快推理速度，全程零人工介入。
Fleet 的第二个任务是系统现代化——不是修改旧代码，而是在保持外部行为不变的情况下重新设计内部架构。Fleet 没有参考 SQLite 的现有代码和文档，而是把 SQLite 测试集作为验收标准。
Fleet 将工作分给决策、架构设计、编码、测试、审查和质量保障等不同角色，各角色反复协作。整轮运行共产生 8720 万个输出 token，分布如下：
编码不足四成，大量工作用于设计、决策和验证——构建数据库不只是生成代码。
Fleet 最终通过全部 600 万项验收测试。同一套 Fleet 可使用不同模型完成任务，成本差异显著：
Agent 会频繁创建沙箱、扫描目录，并在共享云存储中处理大量小文件。Intent Lab 尝试了亚马逊 EFS 和 S3FS 等现成方案，但这些产品在 Agent 工作负载下均存在限制，因此 Fleet 从头构建了 AgentFS。
注：EFS 列以 1× 为基准，AgentFS 列为相对倍数。mdtest 测试结果；Git 测试分别使用 etcd（小型）和 Kubernetes（大型）代码库，S3FS 未能完整检出 Kubernetes 代码库。
除性能外，AgentFS 接受了严格验证：Fleet 检查了 31 个模型中的约 190 万个可达状态，覆盖不同并发顺序、系统崩溃和竞争情况；完成约 300 项集成测试，以及故障注入和模糊测试。验证过程中，Fleet 发现并修复了一处由编程 Agent 引入的 Bug——该问题可能导致分布式创建和删除操作出现数据损坏。
本文所述三项成果均来自 Intent Lab 自行公布的早期报告，属企业单方披露性质。三个任务由 Fleet 自选、自测、自报，未见第三方独立复测。534% 推理提速和 626 倍性能数字，目前尚需独立验证。读者宜带着"自选自测任务"的背景来理解——Fleet 选择了自己擅长的战场。
同时需注意，贾扬清的履历（Caffe 作者、TensorFlow 联合创始人、阿里云前副总裁、Lepton AI 创始人）意味着这篇报道的技术可信度基线较高，但高基线不等于免验证。
Intent Lab 已公布 Fleet 的详细技术报告，可通过官方渠道了解最新进展。
Intent Lab 官方 → 查看 Fleet 技术报告