同一天，贾扬清、吴恩达等分别官宣创业，Agent有了新方向？

机器之心编辑部 今天，AI 创业圈格外热闹 —— 贾扬清、吴恩达以及 Sonia Joseph（ Meta FAIR JEPA 团队核心研究员）在同一天官宣创业。 三位创始人，三条完全不同的赛道。 贾扬清的创业项目名叫 Intent Lab。他们想做的不只是更强的 Coding Agent，而是一支能够从理解需求、设计架构到交付和持续演进的软件工程 AI 团队，把软件开发的整个生命周期交给 Agent。 吴恩达的新公司 LearnVector，则将目光投向教育，希望借助 AI 打破「一对多」教学模式的局限，为每个人提供可信赖、真正个性化的学习向导，把 AI 从「给答案」变成「帮助成长」。 而 Sonia Joseph 创立的 World Mechanics，则瞄准物理世界，试图构建面向科学模拟和机器人等复杂系统的可解释基础模型，让 AI 不只是理解数字世界，也能可靠地理解和预测现实世界。 软件工程、教育、物理世界，三家公司选择了三个截然不同的入口，但都代表了各自团队对下一代 AI 应用的判断。 下面，我们分别来看。 Intent Lab：把一句需求， 变成一个软件系统 Intent Lab 的核心主张不是「再做一个更会写代码的 agent」，而是把编码 agent 没覆盖的那段路接管掉：从一句模糊的 Intent 开始，到生产级软件落地之间，包括澄清目标、做设计、拆任务、协同依赖、实现、验证和上线后的持续演化。 Intent Lab 把它称为一个「autonomous fleet」，并强调 coding agents 会写代码，但不能独立建成整个系统；fleet 的价值在于补上质量验证和性能验证，把意图闭环到生产级软件。换句话说，它卖的不是单次代码生成，而是一种「工程组织外包给 agent 团队」的能力。 为了证明 Fleet 并不是一个简单的代码生成工具，Intent Lab 展示了三个不同方向的实验案例。它们分别对应软件生命周期里的三个阶段：优化已有系统（Optimization）、现代化旧系统（Modernization），以及创造全新的软件基础设施（Creation）。这三个案例背后，其实是在展示同一个趋势：AI Agent 正在从「辅助开发者写代码」，走向「承担完整的软件工程任务」。 第一个案例是 Optimization：让 AI 自主优化已经高度成熟的 TensorRT-LLM 推理系统。 Intent Lab 选择 TensorRT-LLM 作为实验对象，并不是因为它容易优化，恰恰相反，这是一个非常苛刻的挑战。TensorRT-LLM 已经是 NVIDIA 生态中经过大量工程经验打磨的高性能推理框架，底层涉及 GPU kernel、运行时调度、通信效率等多个复杂环节。对于人类工程师来说，在这样的系统上继续提升性能，需要深入理解整个技术栈，并进行大量实验。 Fleet 的任务不是接受工程师提前指定的优化方向，而是只接收一个目标：重新设计 TensorRT-LLM 的代码，使其运行更快。随后，Agent 自主完成性能分析，寻找系统瓶颈，提出优化方案，修改代码，并通过验证不断迭代。 在这个过程中，Fleet 找到了四类主要优化方向。第一类是 Kernel 层面的优化，通过 kernel fusion、生成 PTX/SASS 等底层代码调整，减少计算过程中的额外开销；第二类是 Runtime 优化，通过调整推理执行流程，提高运行效率；第三类是 Communication 优化，通过减少通信和内存交换成本，让计算链路更加顺畅；第四类则是 speculative decoding（推测解码），通过并行预测多个 token，提高生成速度。 最终，Fleet 将 TensorRT-LLM 的输出速度从原始版本的约 102 tokens/s 提升到了 647 tokens/s，实现约 6.3 倍的性能提升。更值得注意的是，Intent Lab 强调，这个过程并不是由人类工程师逐步指导完成，而是由 Fleet 自主发现优化空间、执行修改并完成验证。这意味着 AI Agent 开始具备的不只是代码生成能力，而是对复杂软件系统进行分析、实验和持续改进的能力。 第二个案例是 Modernization：让 AI 从零构建一个兼容 SQLite 的数据库系统。 如果说第一个案例是在已有系统上寻找性能突破，那么第二个案例面对的是软件工程中更困难的问题：如何理解和重建一个复杂的已有系统。 现实世界中，大量企业软件都面临类似挑战。很多核心系统运行多年，积累了大量历史代码和业务逻辑，但缺少完整文档，也很难由原团队重新维护。传统的软件现代化过程往往需要工程师花费大量时间理解旧系统，再逐步迁移和重构。 Intent Lab 让 Fleet 挑战了一个更加极端的任务：在没有 SQLite 源代码、没有内部设计文档的情况下，仅通过外部行为，重新构建一个能够兼容 SQLite 的数据库引擎。 Fleet 获得的唯一目标是：构建一个数据库系统，可以通过所有 SQLite 的测试用例，并且性能达到或超过原系统。 这意味着 Fleet 不能简单复制已有实现，而必须像一个真正的软件团队一样，从行为出发理解系统。它需要不断分析输入和输出之间的关系，设计架构，实现功能，再通过测试验证是否符合预期。 在整个过程中，Fleet 内部形成了类似真实工程团队的协作方式：有负责架构设计的 Agent，有负责编码的 Agent，有负责测试、审核和质量保证的 Agent。不同角色并不是一次性完成任务，而是在整个开发周期中持续协作和反馈。 最终，Fleet 成功完成了 SQLite 兼容数据库的构建。这个案例展示了 AI Agent 的另一种能力：它不只是修改已有代码，而是能够通过理解一个系统的外部行为，重新创造一个具有相同行为的新系统。这对于未来的软件迁移、遗留系统改造具有非常大的想象空间。 第三个案例是 Creation：为 AI Agent 时代创造新的分布式文件系统。 前两个案例分别对应「优化」和「改造」，第三个案例则进一步走向创造：如果未来 AI Agent 本身成为软件系统的重要使用者，那么它们需要的软件基础设施，可能也会和过去完全不同。 Intent Lab 选择的方向是分布式文件系统。 传统文件系统主要是为人类和应用程序设计的，但 AI Agent 的工作方式完全不同。未来，一个 Agent 可能会同时运行大量 sandbox，频繁创建、读取、修改大量小文件，并在云环境中进行高强度的数据操作。现有的 Amazon EFS、S3 等存储方案虽然成熟，但并不是为这种 Agent 工作负载优化的。 因此，Fleet 的目标是从零设计一个面向 Agent 的分布式文件系统。 这个系统需要解决的不只是速度问题，还包括正确性和稳定性问题。Fleet 需要设计存储架构，验证并发行为，并确保在各种异常情况下系统依然可靠运行。 实验结果显示，Fleet 构建的 AgentFS 在多个文件操作场景中实现了数量级提升。例如，在部分目录和文件操作测试中，相比传统方案提升达到几十倍甚至数百倍。同时，Fleet 还通过形式化验证、故障注入和大量测试来保证系