在过去的十年之中, 可谓是AI的代名词。然而当下, 一组非常残酷的数据已然呈现在眼前: 在2025年的时候, 上月活跃贡贡献者已然被超越, 并且其中AI相关仓库所占的比例超过了60%等。这是为何呢? 原因在于AI开发的下半场已然发生了变化。
往昔众人认为AI开发便是训练模型, 凭借此来达成卓越成就。然而及至Agent时代, 其核心并非“训练”, 而是“使模型能够可靠地去执行复杂任务”。你来思考一下, 在Agent的工作流程当中, 用户意图被转化为JSON格式, 接着调用工具, 之后回传结果, 再加以验证, 最后进行修复——这个“验证 - 修复”的循环占据了80%的时间。
动态类型在此处变成了最为巨大的坑, 代码倘若不运行起来, 你便无法知晓是否存在错误, Agent需要自行去读取运行时错误进而进行修正, 这恰似让它在黑暗的迷宫里撞墙来尝试错误, 每一次碰撞都会浪费一次LLM调用, 既昂贵又缓慢, 然而呢? 编译时就能够检查出94%的类型错误, 这等同于给Agent开启了上帝视角, 所有的墙壁、路径都清晰明了。
这儿, 就是那个展现降维打击效果的所在之处, 也就是类型安全。通过借助Zod, 从大语言模型输出一直到业务逻辑这块儿, 所有的数据格式早在写代码之前就已经确定僵化了。智能体根本不需要去猜测, 直接依照契约来行事, 这样一来幻觉就减少了很多。与之作为对比的是, 虽说也能够进行校验, 可是前端以及中间件还得另外去做桥接工作, 而原生的链路, 是更为简短的。
有一种杀手锏是异步并发, Agent常常会同时调用五六个工具, 像查天气、搜文档、发邮件之类, Node.js的事件驱动模型处理几百个并发请求都不会出现阻塞情况, 存在第三方库不兼容问题, 还有GIL限制, 以及嵌套回调让人头疼, 经过实际测试, 针对同一个任务, TS处理并发平均能快2到3倍, 是这样的情况吗?
更重要的是全栈达成统一, 其涵盖命令行、Web面板、浏览器插件、桌面端, 需用一套语言全部包揽。前端的React, 连同后端、CLI工具、扩展都是它。在生态环境中, 几乎成为Agent的标配, 而在这些领域的绑定则更为繁重。
还有一个容易被人忽视的要点, 那就是JSON亲和力, LLM与外界进行交流所采用的通用协议是JSON, 其类型系统自然而然地与JSON相对应，不存在语法上的冲突, 其dict提取需要额外进行类型断言, 在编译的时候根本无法确保键值是存在的, 总而言之, 当LLM输出格式变得越来越具有类型化的时候, TS就是最为自然的翻译官。
数据不会说谎。在前20的AI Agent项目当中, 70%会使用, 然而仅占20%。在YC X25创业公司里, 有60%到70%会选择。主流框架诸如, AI SDK等等, 均将TS视为一等公民。就连持该阵营观点的, 其JS版本增速也更为迅速。
然而, 先别急于宣称非要死不可。模型训练以及数据科学, 它的确依旧是无法被别的事物所取代的, NumPy、相关生态就明摆在那儿呢。到了2026年, 真正占据主流地位的方案乃是混合架构, 其中一部分负责计算层面, 涵盖推理、数据处理等方面；另一部分负责编排方面, 进行工具的调度、状态的管理、UI的设计。这两部分借助MCP协议亦或是REST API来实现通信, 各自履行好自身的职责, 各尽其责。
比如说, Uber, 采用 JS 版本, 采用这一种。要是新项目对于你们团队而言全员都是特定背景的, 那么, 就不妨先从框架以及工具调用这类方面的规范化着手进行。然而, 倘若这算是一个新项目亦或是属于全栈团队类型的, 那就要优先去考虑, 哪怕是至少得从编排层这个层面起始。
末尾来讲些切实可行的。若要构建一套“TS编排加上计算”的体系，挑选AI SDK以及Next.js能够迅速产出Web型Agent；于复杂多Agent运用情景下, 它对工作流、RAG、并行任务予以支持。优先进行类型定义, 借助Zod将所有工具参数、输出格式、状态快照全都确定下来。针对并发设计运用.all并行调用工具, 依据事件驱动来管理消息流转情况。在那边把推理以及数据处理封装成为微服务, TS借助HTTP2或者gRPC调用过去, 类型一致性依靠proto文件或者JSON进行共享。
你会发觉, 其静态类型自身便是测试, 编译得以通过便减少了大半的漏洞。再者配合开展端到端测试, 借助追踪执行链路, Agent稳定到令人安心。
终究而言, Agent进行开发时, 处于最底层的那种需求, 乃是要在LLM无法进行控制的输出范围之内, 将确定性实现最大化。其类型系统给予了工业化级别的安全气囊保障。它就如同发动机一般重要, 也类似方向盘和刹车一样关键。要是没有发动机, 车辆根本无法开动, 然而要是缺少了方向盘和刹车, 那么车辆行驶得越快, 便会越危险。
这事儿你怎么看？是继续坚守还是拥抱？评论区聊聊你的选择。
