当新一代大语言模型发布时，你的第一反应是什么？是满心兴奋地期待它能为自己的系统带来质的提升，还是暗自担忧之前搭建的架构会被新模型“淘汰”？如果是前者，说明你的技术选型和架构方向走在了正确的道路上；如果是后者，或许是时候停下脚步，重新审视自己的Agent开发思路了。

这不是一个凭空提出的疑问，而是源于2026年初社交媒体上的一条普通推文。一位开发者分享了自己的编程语言使用排序，TS大于等于RS大于Go大于等于C等于C++大于Zig大于Lua大于等于Python大于JS，还感慨自己已经不再执着于Rust。这条看似简单的技术偏好分享，背后却折射出一个深刻的行业趋势，TypeScript正在逐渐成为AI应用开发的事实标准。

如今，无论是MCP、LangChain.js还是Vercel AI SDK，几乎所有主流的Agent工具链都将TS视为第一公民。前端开发者作为全球规模最大的开发者群体，正用他们最熟悉的语言，悄悄定义着AI Agent的开发范式。这本身并不是一件坏事，毕竟技术的流行往往源于市场的自然选择，但我们不得不思考一个问题，当一门为浏览器而生的语言生态，开始承载从应用层到基础设施层的全部重量时，这条路真的能走得长远吗？

本文不想否定TS工具链在当下的合理性，毕竟它在AI应用的探索期发挥了不可替代的作用。但我们更想探讨一个更长远的架构判断，在Agent从demo走向生产的关键转折点上，什么样的基础设施投入才是值得的，什么样的架构决策能够经受住模型能力持续跃迁的冲击。而这场探讨的最终结论，或许指向一个正在行业中逐渐形成的共识，最好的Agent框架，也许是“没有”框架。

一、TS主导的AI工具链：合理的现在，隐藏的隐患

要理解这个共识，我们首先要正视当前TS主导的AI工具链现状，它有其合理之处，也隐藏着不容忽视的隐患。

1.1 市场选择的必然：TS的效率优势不可替代

必须承认，TS成为AI Agent开发的主流语言，是市场选择的自然结果。当前AI应用层最核心的需求是快速试错，一个想法从构思到原型落地，TS的全栈特性让开发者可以用同一套语言覆盖前端交互、后端逻辑、CLI工具甚至桌面应用，无需在多种语言之间来回切换，极大提升了开发效率。同时，TS的类型系统在处理LLM返回的复杂嵌套JSON时表现出色，能够有效避免数据格式错误，而庞大的npm生态则提供了几乎开箱即用的所有组件，无论是请求处理、数据解析还是工具调用，都能找到对应的解决方案。对于那些需要在最短时间内验证Agent产品假设的团队来说，TS的效率优势是真实且不可替代的，这也是它能快速崛起的核心原因。

1.2 难以突破的局限：性能瓶颈与协议污染

但问题在于，AI工具链从来都不只是“调API+拼JSON”那么简单。当我们沿着Agent的技术栈向下走一层，遇到的问题就会变得截然不同。推理服务的性能调优、向量数据库的并发访问、Agent长时运行场景下的内存管理、高并发tool calling的调度与限流，这些都是确定性的系统工程问题，需要对运行时行为有精确控制的语言来解决。而Node.js的单线程事件循环模型，在这些场景下天然存在局限，难以应对高并发、高资源消耗的需求，这也是TS工具链在走向生产级应用时的第一个瓶颈。

更隐蔽也更危险的问题在于协议层。当MCP的参考实现和主流SDK都以TS为第一公民时，协议本身的设计不可避免地会被JavaScript的思维模式所塑造。比如tool schema采用JSON Schema描述，这对TS开发者来说非常自然，无需额外学习就能上手，但对于Go、Java、Rust这些强类型语言来说，适配成本并不低。这看似是一个微不足道的技术细节，实则影响深远，当协议层被特定语言的编码习惯污染时，整个生态的多样性都会受到抑制，不同语言开发者之间的协作成本会大幅增加，甚至会阻碍Agent技术的跨语言普及。

1.3 行业现状：边界模糊的潜在风险

当前的行业现状是，应用层和基础设施层用同一套语言“糊”在一起，边界模糊不清。这种模式在demo阶段完全可以接受，毕竟demo的核心是验证想法，无需考虑性能、并发和可扩展性。但如果将这种模式固化为企业级架构的基础，随着业务规模的扩大和模型能力的提升，那些隐藏的隐患就会逐一暴露，轻则导致系统性能瓶颈，重则引发服务崩溃，甚至需要彻底重构架构，付出巨大的时间和人力成本。

二、全新架构起点：将LLM作为Runtime而非Library

既然TS主导的工具链存在难以突破的局限，那我们是否有更好的架构选择？答案或许在于一个全新的起点，将LLM当作Runtime，而不是Library。

2.1 主流框架的固有假设：编排逻辑归属于代码

当前主流的Agent框架，无论是LangChain、LangGraph还是其他变体，都共享一个隐含的假设，编排逻辑属于代码。开发者用Python或TypeScript编写chain、graph、state machine，定义Agent应该先调用哪个工具、再调用哪个工具、在什么条件下分支、在什么条件下回退。在这个框架中，模型扮演的角色更接近于一个被调用的函数，接收输入、返回输出，至于如何组合这些输入输出，完全由框架代码决定。这本质上是把LLM当作Library在使用，没有充分发挥其智能决策能力。

2.2 思维转变：让LLM成为天然的编排引擎

但如果我们换一个角度思考，LLM本身就具备理解用户意图、制定计划、选择工具、处理异常的能力，这些能力正是“编排”的核心。既然模型已经能做好这些事情，我们为什么还要用代码去模拟一个模型已经具备的功能？这个思考引向了一个完全不同的架构起点，把LLM当作Runtime，让模型本身成为编排引擎，而不是被代码控制的工具。

2.3 三层分离架构：清晰边界，独立演进

基于这个起点，架构会自然地分为三层，这三层的关注点完全正交，每一层都可以独立演进，互不干扰，从根本上解决了边界模糊的问题。

第一层是后端服务层，主要采用Go、Java等强类型语言开发，承担所有确定性的系统工程职责，比如服务治理、并发调度、资源管理、可观测性、权限控制、审计日志等。这些问题是强类型语言和成熟后端生态已经解决了几十年的问题，技术成熟、方案完善，不需要用TS生态重新发明一遍，用最合适的工具解决最合适的问题，才能保证系统的稳定性和可扩展性。

第二层是LLM Runtime层，这一层的核心是让模型本身成为编排引擎。模型负责理解用户意图、选择合适的skill、组合执行计划、处理执行过程中的异常和回退，将编排决策权真正归还给模型，而不是硬编码在框架代码中。这样一来，模型的智能决策能力就能得到充分发挥，无需被代码逻辑束缚，系统的灵活性也会大幅提升。

第三层是Skill描述层，以声明式的方式定义每个skill的能力边界，比如它能做什么、输入输出的格式与约束、前置条件与副作用。这些描述不是给框架“执行”的，而是给模型“读”的，让模型能够清晰地了解每个工具的功能和使用方法。新增一个skill时，只需要增加一份描述文件，而不需要修改任何编排代码，极大降低了系统的维护成本，也让技能扩展变得更加灵活。

这种三层分离的架构，彻底打破了“用一套语言包打天下”的固有模式，让每个层面都能专注于自己的核心职责，既保证了系统工程的稳定性，又充分发挥了LLM的智能优势。而这也正是“没有框架”理念的核心所在。

三、“没有框架”的真相：不是无基础设施，而是让智能归位

3.1 常见误解：“没有框架”不等于虚无主义

提到“最好的Agent框架是‘没有’框架”，很多人会产生误解，认为这是一种虚无主义，主张不需要任何基础设施。但事实恰恰相反，这个理念的核心是，我们需要的基础设施应该服务于模型的决策能力，而不是替代它。

3.2 框架的反模式：用代码束缚模型的上限

回顾过去两年Agent框架的演进历程，一个反复出现的模式是，框架试图用代码抽象去“驯服”模型的不确定性。Chain规定了执行顺序，Graph规定了状态转移，ReAct loop规定了思考-行动-观察的节奏。这些抽象在模型能力较弱的阶段有其存在的价值，它们用确定性的代码逻辑兜底了模型的不可靠性，帮助开发者快速搭建可用的Agent系统。

但这些抽象也有一个致命的副作用，它们同时限制了模型能力的上限。当模型足够强大，能够自主判断“这个任务应该先查数据库还是先看日志”时，一个硬编码了执行顺序的chain反而会成为障碍；当模型能够根据中间结果动态调整策略时，一个预定义好状态转移图的graph反而会限制系统的灵活性。LangChain从v0.1到v0.3的几乎完全重写，就是这个矛盾的现实注脚，框架一直在追赶模型能力的进化，而不是在赋能它，开发者投入大量时间学习的框架API，在模型换代时往往会变得过时，形成巨大的技术债。

3.3 核心内涵：智能归智能，工程归工程

“没有框架”的真正含义，不是取消所有基础设施，而是一种深思熟虑的架构哲学，把智能的部分交给智能的引擎也就是LLM，把确定性的部分交给确定性的工具也就是后端服务，把两者之间的接口做成声明式的描述也就是Skill，而不是命令式的编排代码。在这个范式下，不存在一个叫做“Agent Framework”的中间层去告诉模型该怎么思考，模型直接面对skill描述，自己决定调用什么工具、以什么顺序调用、如何处理错误。后端服务层提供的是执行能力和安全边界，而不是决策逻辑。

这种模式看起来比传统的框架模式更简单，但“简单”本身就是一种高级的架构选择。它去掉了多余的中间层，让系统变得更纯粹、更灵活，也更能适应模型能力的快速迭代。当新模型发布时，系统不需要大规模重构，只需要让模型更好地理解skill描述，就能直接享受模型进步带来的收益，这也是这种架构范式最核心的优势之一。

四、超越MCP：企业级Agent交互的重构之路

4.1 MCP的价值与局限：全量加载模式的不可持续性

在探讨Agent Infra架构时，我们无法回避MCP协议。MCP也就是Model Context Protocol，为Agent与工具的交互定义了一套标准化的协议格式，包括tool schema、调用约定、结果返回。作为序列化协议，这些定义是有价值的，能够降低不同工具之间的交互成本，不需要我们重新发明一套新的协议。

但MCP也隐含了一个架构假设，客户端启动时通过tool/list全量拉取所有可用工具的描述，平铺暴露给模型。这个假设在个人开发者连接几个MCP server的场景下工作得很好，工具数量少，模型能够轻松处理。但在企业环境中，往往有几百个业务系统、上千个操作接口，这种全量加载的模式就变得不可持续了。

4.2 核心矛盾：模型注意力资源的有限性

根本矛盾在于，模型的注意力资源是有限的。Context window有明确的上限，当模型需要在几十上百个工具描述中做选择时，选择的准确率会随着工具数量的增长而下降。全量加载不仅会浪费大量的token，增加成本，更会直接降低Agent的决策质量。很多时候，问题不是工具不够多，而是模型的注意力不够用，无法在海量工具中快速找到最适合当前任务的那一个。

4.3 解决方案：从全量加载到服务发现的两阶段决策

要解决这个问题，我们需要从全量加载转向服务发现，将工具选择从一阶段决策变为两阶段决策。

第一阶段是平台侧的确定性决策，模型表达用户意图后，平台根据意图做路由和检索，返回最相关的skill子集。这个过程可以用传统的检索技术进行优化，比如倒排索引、向量相似度、业务规则路由等，这些都是成熟的、可工程化的方案，能够快速、准确地筛选出与当前任务相关的工具，缩小模型的选择范围。

第二阶段是模型侧的语义决策，模型在缩小的skill子集中做精确选择和组合。因为候选集变小了，模型的注意力能够更集中，选择的准确率自然会提升，同时也能节省大量的token，降低成本。

同时，我们还可以采用分层加载策略，进一步优化性能和体验。高频核心工具比如数据库查询、日志检索、告警查看等，进行预加载，避免每次交互都多一轮发现的延迟；长尾业务工具则按需发现，用到时再加载，既节省context空间，又避免对模型决策造成干扰。

4.4 关键实践：保留MCP格式，重构交互模式

这里的关键认知是，我们可以保留MCP的交互格式，但不采用MCP的架构模式。利用MCP定义的tool schema和调用约定作为序列化协议，在此之上构建企业级的C/S端到端交互模式。对外暴露声明式的skill描述来指引LLM使用工具，但这种暴露不依赖tool/list的全量加载，而是通过服务发现动态解析。这样既保持了与MCP生态的兼容性，能够复用现有工具，又突破了其架构假设的限制，满足企业级应用的需求。

五、架构试金石：模型对齐测试与容错设计

5.1 模型对齐测试：判断架构健康度的核心标准

一个架构范式的好坏，需要有明确的判断标准。对于Agent Infra架构来说，最有效的试金石就是模型对齐测试，简单来说就是，当新一代模型发布时，你是更开心还是更担心？

如果你更开心，说明新模型理解skill描述更准确了，服务发现的意图匹配更好了，多步编排的可靠性提升了，这意味着你的架构在与模型能力对齐。模型的进步能够直接转化为系统的改善，你之前在基础设施上的投入正在不断增值，这样的架构才是健康的、可持续的。

如果你更担心，说明新模型太强了，之前精心设计的编排逻辑变得多余了，框架的抽象层反而限制了模型的发挥，这意味着你的架构在与模型能力对抗。你之前的投入正在变成技术债，每一次模型升级，都需要对系统进行大规模重构，这种架构显然无法适应长期发展的需求。

本文提出的三层分离架构范式，在设计上就确保了对这个测试的正向响应。因为编排决策权在模型侧，模型越强，编排效果就越好；因为skill描述是声明式的，模型越强，对描述的理解就越准确；因为后端服务层只做确定性的事情，它的价值不会被模型进步所侵蚀，反而会随着业务规模的扩大而不断提升。

反观当前主流的框架模式，LangChain从v0.1到v0.3的大规模重写，本质上就是在为模型能力的快速进化“还债”。每一次模型升级，都有一批框架抽象变得过时，开发者投入在学习框架API、适配框架约束上的时间，在模型换代时几乎归零。作为Agent研发，我们需要守住一个基本前提，基础模型的迭代不应侵蚀我们前期的人力投入。基础设施的价值应该随模型进步而增值，而不是贬值，这不是一个技术偏好问题，而是一个工程经济学判断。

5.2 容错的正确姿势：从Agent内部修补到整体模式降级

除了模型对齐，Agent系统的可靠性也是企业级应用必须关注的核心问题。关于Agent系统的容错，业界通常的思路是在Agent内部增加各种fallback机制，比如重试、降级模型、切换工具、回退到预定义流程。这些做法直觉上合理，能够在一定程度上提升系统的可靠性，但在架构层面会带来一个严重的后果，Agent内部变成了一个“一半智能、一半硬编码”的缝合体，两套逻辑交织在一起，维护成本急剧上升，而且随着业务场景的增多，这种缝合会变得越来越复杂，最终难以维护。

本文提出一种不同的容错理念，Fallback不是Agent内部的try-catch，而是从agentic模式到传统模式的整体降级。Agent运行在明确定义的sandbox内，sandbox规定了Agent能够访问的工具、能够执行的操作、能够影响的范围。在这个边界内，让模型充分决策，不加任何多余的硬编码约束，充分发挥模型的智能优势。

如果在某个场景下，agentic模式的整体可靠性不达标，我们不需要去修补Agent的决策逻辑，而是将这个场景降级回传统的交互模式，比如表单提交、流程引擎、审批系统。这些系统本来就存在，经过多年的打磨，可靠性有充分的保证，不需要为了Agent重新搭建一套容错机制。这样既保证了系统的可靠性，又简化了Agent的内部逻辑，降低了维护成本。

5.3 企业落地路径：渐进式边界扩展

这种设计还带来了一条清晰的企业落地路径，不是要求Agent一步到位地替代所有现有系统，而是从最适合agentic模式的场景开始，比如信息查询、数据分析、报告生成这些“只读”场景，风险最低，也最容易看到效果。然后逐步扩大sandbox的能力边界，模型更强了，sandbox就开放更多能力，agentic模式覆盖更多场景；模型在某些场景还不够可靠，传统模式就继续兜底。两种模式之间没有架构冲突，切换的依据是sandbox的能力边界定义，而不是代码里的if-else判断。

Agent系统内部保持架构纯粹性，容错交给系统边界外的成熟方案，这是本范式处理可靠性问题的核心原则，也是企业级Agent落地的关键。

六、价值沉淀：“薄”平台的工程壁垒

6.1 常见质疑：“薄”平台是否没有护城河？

在探讨这种“薄”平台架构时，很多人会有一个直觉上的质疑，如果平台层刻意做薄，skill描述是声明式的、可移植的，sandbox边界清晰，编排智能来自LLM，那这个平台的护城河在哪里？这个质疑背后有一个隐含的错误假设，把“薄”等同于“没有壁垒”。

6.2 核心壁垒：不可复制的工程能力积累

事实上，skill描述文本看起来可移植，但真正有价值的不是那几行描述文字，而是skill背后封装的完整工具链路。一个企业级的“数据库诊断”skill，背后可能串联了慢查询分析、执行计划解读、索引建议、连接池监控、历史基线对比等一整套工具链路。这条链路的可靠性、性能、边界情况的处理，是需要持续的工程投入来打磨的，绝不是几行文本就能搬运走的。比如，慢查询分析需要对数据库的执行机制有深入的理解，索引建议需要结合业务场景进行优化，这些都需要长期的技术积累，不是简单复制描述文件就能实现的。

Service discovery也是如此，做好意图到skill的路由匹配，尤其是在企业的复杂业务语境下，本身就是一个需要深度工程投入的课题。企业的业务场景复杂多变，意图的表达也多种多样，如何准确理解用户意图，并匹配到最相关的skill，需要结合自然语言处理、业务规则、用户行为分析等多种技术，不断优化算法和模型，这背后的工程积累是难以复制的。

Sandbox的权限控制、审计合规、资源隔离，虽然可以基于现有PaaS能力组合而成，但组合本身的合理性和可靠性也需要大量的设计与验证。比如，如何根据不同的用户角色分配不同的工具访问权限，如何确保Agent的操作符合企业的合规要求，如何实现不同业务场景之间的资源隔离，这些都需要结合企业的实际需求进行定制化设计，不是简单的组件堆砌就能完成的。

6.3 壁垒模式：类似Kubernetes的整体工程成熟度

这里的壁垒模式更接近Kubernetes而非LangChain。Kubernetes的每一个组件，比如容器调度、服务发现、配置管理，单拿出来都有替代品，但整个体系跑通之后，组件之间的互操作性、边界情况的覆盖度、运维工具链的成熟度，构成了一个整体壁垒。这个壁垒不是靠API lock-in建立的，而是靠工程成熟度建立的，别人可以复制单个组件，但很难复制整个体系的工程能力和成熟度。

同样的逻辑适用于本文描述的Agent Infra。壁垒不在于某一层的技术独特性，而在于整个体系的工程成熟度和互操作可靠性。一个靠让用户走不掉来建立壁垒，一个靠把事情做到别人追不上来建立壁垒，后者显然更健康，也更持久。

七、时机已至：从需求探索到Infra建设的转型

7.1 需求探索期的成果：核心共识已形成

任何架构范式的落地，都需要合适的时机。现在，正是Agent Infra从需求探索期进入建设期的关键节点。

过去一年多，TS工具链的快速迭代完成了一件重要的事情，需求探索。通过大量的demo、prototype、early product，行业对Agent开发的核心需求形成了相对清晰的共识。

首先，Tool calling的格式基本收敛。MCP和OpenAI function calling大同小异，在序列化协议层面已经不需要太多创新，大家可以基于现有的协议格式进行开发，无需再投入大量精力研究新的协议。

其次，编排应该是模型原生的，而不是代码驱动的。越来越多的开发者发现，硬编排的框架在模型升级后反而成为负担，模型的智能决策能力已经能够替代大部分代码编排的工作，让模型自主编排，才能充分发挥其优势。

再次，Context管理是核心瓶颈，而不是工具数量。如何在有限的注意力资源下让模型做出最优决策，比堆砌更多的工具更重要。很多时候，过多的工具反而会分散模型的注意力，降低决策质量，做好Context管理，才能提升Agent的可靠性和效率。

最后，生产环境的需求远超demo的想象。可观测性、权限控制、审计日志、灰度发布、回滚机制，这些企业级需求，当前的TS demo几乎完全没有覆盖。要让Agent真正落地到生产环境，必须解决这些问题，搭建完善的基础设施。

7.2 转型建议：临时手段不固化，聚焦Infra建设

需求探索期已经结束，infra建设期可以开始了。当然，在AI快速发展的当下，TS全栈框架作为快速验证想法的临时手段，仍然有其不可替代的价值。对于初创团队或者需要快速验证产品假设的场景，TS工具链依然是最优选择。但临时手段不应被固化为长期架构，企业需要的是一个稳定的、可移植的、符合模型迭代趋势的、能够合理fallback的Agent Infra底座，来守住后端服务的基本防线，而不至于在模型每次升级时被动重构。

现在，我们已经有了足够清晰的架构拆分认知，也明确了各层的核心职责和技术选型，是时候开始建设了。

结语

本文试图描述一种Agent基础设施的架构范式，它的核心信念可以浓缩为一句话，把确定性的交给确定性的工具，把智能的交给智能的引擎，把两者的边界画清楚。

这不是一个否定当前工具链的极端主张。TS生态在需求探索期发挥了巨大价值，LangChain们教会了我们Agent开发中什么有用、什么没用，也为我们积累了大量的实践经验。但当我们把目光投向更长的时间线时，需要问自己一个问题，两年后回头看，我们今天的架构决策，是让我们对未来更有信心，还是更焦虑？

如果答案是更有信心，那就继续走下去；如果不是，也许是时候换一条路了。

最好的Agent框架是“没有”框架。不是因为我们不需要基础设施，而是因为真正的基础设施，应该让智能的归智能，让工程的归工程，然后安静地退到幕后，让模型的进步成为整个系统的进步。这或许不是最容易的路，但一定是最长久、最有价值的路。