演講嘉賓｜沈桐

編輯 ｜Kitty

策劃 ｜QCon 全球軟件開發(fā)大會

在大模型應用開發(fā)過程中，如何將研究成果與軟件工程緊密結合，并解決新領域中的新問題是開發(fā)者面臨的重大挑戰(zhàn)。在 InfoQ 舉辦的QCon 全球軟件開發(fā)大會（北京站）上，字節(jié)跳動研發(fā)工程師沈桐發(fā)表了題為《AI 應用開發(fā)的破局之路：字節(jié)跳動 Eino 框架實踐》的分享，他重點介紹字節(jié)跳動 Eino 框架在 “組件” 抽象和業(yè)務編排方面的創(chuàng)新實踐，提供 Eino 框架在大規(guī)模生產(chǎn)環(huán)境中的應用價值與實踐經(jīng)驗參考。

預告：將于10 月 23 - 25 召開的 QCon 上海站設計了「Agentic AI」專題，將深入探討 Agentic AI 的核心技術，包括自我學習、決策制定、情境理解以及多智能體合作等關鍵能力。并分析智能代理 AI 如何提升行業(yè)生產(chǎn)力，為各個行業(yè)帶來革命性的改變。敬請關注。

以下是演講實錄（經(jīng) InfoQ 進行不改變原意的編輯整理）。

AI 應用框架

開發(fā)框架作為基礎設施，我們應該如何理解它？

我們首先有一個金字塔，金字塔底端是一個大模型。大模型是一個突破性的技術，有這個技術作為起點，使得我們很多一些之前不能做的需求成為可能，給我們的企業(yè)打開了很多可以探索的方向。

我們在做這些新需求時，會遇到很多比較重復的典型問題，對這些問題的解決需要不斷實踐，是我們發(fā)現(xiàn)和解決問題的過程。

基于這些實踐經(jīng)驗，我們可以把解決問題的這些認知積累成一個框架，這個框架就可以幫助我們更好地應對未來重復出現(xiàn)的問題。

所以 AI 應用框架，等于是以大模型技術的突破作為基礎，在解決這些新的需求場景的實踐過程中，通過解決和提煉重復問題而產(chǎn)生的認知和解決問題的框架?；谶@個框架，我們以后可以更好地開發(fā)應用，所以這個框架可以作為我們的基礎設施來出現(xiàn)。

AI 應用框架也差不多。首先它是技術驅動的，必須要站在大模型技術不斷進展的前沿，因為它可以探索我們解空間的可能性，這是第一個前提。第二點是基于真實的需求，是通過實際出現(xiàn)的場景來驅動的。第三點是基于這些真實需求的提煉，我們可以把認知沉淀下來，比如以 API 的方式、設計的方式、功能的方式在這個框架內部傳遞出來。最后通過時間的檢驗來看我們的認知是不是能真的幫助我們解決實際的問題，實現(xiàn)真實的需求，以此作為一個循環(huán)來提升這個框架作為 AI 應用基礎設施的能力。

那么什么是 AI 應用？這是我們需要首先回答的一個問題。這個圖就是我們目前的 Eino 框架，在支持自己的內部和外部的一些需求之中，我們沉淀出來的所謂的認知。我們認為 AI 應用就是一個圍繞大模型的信息流，中間的框叫 ChatModel，就是大模型。

為什么會有這么一個認知？首先是來源于大模型的根本特性，因為它是可以做信息的生成，無中生有把信息給你搞出來。因為它核心的特性，所以我們的 AI 應用一定是針對信息的處理過程。比如說我們的大模型為了能夠更好地無中生有給出一些有價值的信息，我們還是需要把一些相關的有價值信息給到大模型，畢竟我們之前都知道垃圾進垃圾出的道理。雖說大模型是垃圾能夠進，也會突出一些相對比較好的一些信息，但我們還是需要更好的信息給大模型來才會有更好的效果。所以我們會有前置的一些信息檢索和信息增強等節(jié)點來給大模型比較好的輸入和上文。

大模型給出信息之后，我們需要一些相關的節(jié)點處理這些信息，利用這些信息，或者把這些信息最終給到人去消費，整個過程是由幾個基本元素構成的，這些框就是所謂的節(jié)點，這些節(jié)點都有同樣的特性，都是信息處理節(jié)點。它們還有一個區(qū)分點是不同節(jié)點處理信息的方式是不一樣的，信息處理模式是由這些不同的節(jié)點而有區(qū)別的。我們會把不同節(jié)點的信息處理模式抽象為一個組件，這是第一點。

再往外來看一點，連接這些節(jié)點的是有一些線，這些箭頭的連接方式會有不同，會有分叉、匯聚、分支的判斷和選擇，會有環(huán)的結構。這些不同的連線方式代表的是對不同的信息處理節(jié)點的控制方向以及節(jié)點之間數(shù)據(jù)傳遞的模式。這也是我們做應用時需要經(jīng)常解決的問題，就是如何讓這些信息有效地在節(jié)點之間流動，以及如何流動。

最終我們再站出來看整體這個圖，這個圖很典型，它是一個我們做應用時會非常常用的模式，就是先召回信息，再由模型做信息生成，然后由這個工具節(jié)點去處理信息，給出反饋，再由模型根據(jù)這些反饋進一步做生成。其中有一個環(huán)的結構，ChatModel 跟原信息之間有一個分支，構成一個環(huán)。這個結構是叫 react 的模式，就是由模型生成，由工具執(zhí)行，再把反饋信息給模型，這樣反復不斷地根據(jù)反饋給出最終結果的范式。

這個范式是有兩個節(jié)點、一個分支和幾條線就可以構成的，它也可以作為我們一個大應用的子結構。這些類似這種 react 的范式，也是我們在應用開發(fā)時需要反復使用或者反復沉淀和理解的一些復合組件。

總結起來，我們 AI 應用的框架為了解決應用開發(fā)的問題，有三個點需要處理。一個是說有哪些節(jié)點，有哪些信息處理的范式可以作為節(jié)點、作為組件來出現(xiàn)，這是第一個問題。

第二個問題是說節(jié)點之間信息流轉的方式方向，以及數(shù)據(jù)的映射的方式是什么樣的，怎樣盡簡單清晰和完備地描述出這些信息流轉的方式，這是第二個問題。

第三個問題是我們會根據(jù)最佳實踐，根據(jù)我們的科研成果，根據(jù)我們的業(yè)務場景去沉淀一些常用、復合、有效的整體框架。

先看第一個點，就是我們有哪些組件去處理不同的信息處理方式。這是一個可枚舉的組件列表，比如說我們中間的這三個，一個是大模型，一個是 Retriever，就是所謂的信息召回。第三個是工具，就是我們怎么去處理信息，然后給出處理信息的結果。還會有其他類型的信息處理組件，每一個組件都是一個接口，一個抽象，它代表的是某一類信息處理模式。

有了組件的抽象列表后，我們作為開發(fā)者就可以比較清晰地知道我應該用哪些節(jié)點構成應用的信息處理節(jié)點，這是第一點。

第二點，既然有了 ChatModel，就是大模型的抽象信息處理模式，那么里面我們可以用哪些具體組件實現(xiàn)或者具體的服務提供方，幫我們真正實現(xiàn)大模型也好，Retriever 也好，這些接口的。我們會有另外一個列表，針對每一個組件抽象都會有組件的實踐列表，可以滿足組件抽象的信息處理模式。我們在真正編排和開發(fā) AI 應用時，就可以在里面選擇自己合適的組件。

所以作為框架來說，我們提供的價值是首先定義了一個組件的抽象列表，可以讓開發(fā)者能夠很清楚、一目了然地知道我有哪些可能性可以做。第二個是我們提供了針對每一個組件抽象的實踐列表，是一些比較常用的，經(jīng)過驗證比較好用的具體實踐，可以開箱即用。

如何去把這些不同的信息處理節(jié)點連起來，就是以一種合適的方式讓控制流和數(shù)據(jù)流能夠流轉。這就等于是編排，所以編排就等于是說在節(jié)點之間構建聯(lián)系，可以這么簡單理解。

這個圖的三個元素，一個元素是節(jié)點，各個框是我們的節(jié)點，邊上就是節(jié)點之間的有效連線，分支是不同的下游選擇器，這三個基本的元素就已經(jīng)可以完整描述一個有向圖，可以把我們任意的業(yè)務場景信息流，用這三個基本元素去做完備的描述。

除此之外，這三個節(jié)點描述的是控制流，就是我們如何讓信息從最開始的節(jié)點，以我們預定的方式去流轉。還會有數(shù)據(jù)流的處理，我們可以基于字段之間的輸入和輸出之間的類型對齊，以及字段級別的數(shù)據(jù)映射，以及間接的數(shù)據(jù)引用等方式，基于我們的控制流圖去實現(xiàn)數(shù)據(jù)流的合適映射和流轉。

大框圖是由組件的這些直接抽象來構成的，比如說大模型節(jié)點，我可以替換成任何一個模型提供商，這些工具可以換成任何基于我們業(yè)務場景的工具。也就是說我們的編排是面向抽象，我們可以可插拔地把不同的具體實踐給到節(jié)點上。

同時基于面向接口的編排，我們可以做到的一點是這些狀態(tài)，比如數(shù)據(jù)也好，記憶也好，還是上下文也好，或者是我們的知識庫也好，或者是我們圖的狀態(tài)，都可以在整個編排的外部去存儲。在我們整個實例之上，在我們的 function 編排運行時，它是無狀態(tài)的，可以水平擴展的。

下一個是關于數(shù)據(jù)流。我們說了很多，也許感知還不是很強烈。這么一個框架并沒有跟一個普通的工作流框架有什么本質的區(qū)別，好像并不是很明顯。

但我們大模型應用開發(fā)的框架，它的一個核心特點是一定有大模型。大模型有一個特點是它一定是流式的數(shù)據(jù)輸出，所謂的流式還不是一般的流，是一個有序的流，其中每一個元素是整體消息的一部分，是一個分片，這是它的核心特點。所以我們的框架就一定要處理具有這樣特性的數(shù)據(jù)。

我們從各個節(jié)點的數(shù)據(jù)流來看，它會有不同的流處理場景，比如說由一個數(shù)據(jù)流復制到多份數(shù)據(jù)流，以及多份數(shù)據(jù)流自動合并成一份數(shù)據(jù)流。在我們這個圖中有的節(jié)點沒法處理流數(shù)據(jù)，比如說一個工具函數(shù)只能接收一個完整消息，接收不了這種分片形式的數(shù)據(jù)流，那么怎么辦？它能不能進我們的信息流編排？也是可以的，沒問題，我們可以自動把這種分片有序的數(shù)據(jù)流自動合并成一個完整的信息數(shù)據(jù)，交給不能接收流式數(shù)據(jù)的一個節(jié)點，比如一個工具或者一個函數(shù)，它就可以直接處理完整數(shù)據(jù)，而忽略掉流的復雜性。而這種把流自動拼接成完整數(shù)據(jù)的過程是由框架來托管的。

也就是說基于我們框架這種比較完善的流的復制合并、裝箱拼接這些基礎和自動的能力，我們可以做到把大模型這種流式輸出的節(jié)點，以及其他沒法處理流數(shù)據(jù)的節(jié)點，比如說工具或知識庫召回等，以一種無縫的方式編在一張圖里，做在一個應用里，同時保留流式處理的時效性比較高的特征，以及其他的一些傳統(tǒng)節(jié)點的特征。

基于上面這些流的處理能力，我們靠 callback 機制，就可以把每一個節(jié)點無論是流式的輸入輸出，還是非流的輸出能以 callback 的方式向外部發(fā)送事件，所以整個 AI 應用是一個不間斷的事件源。

我們這個框架的名字叫做 Eino。上面說了三個問題，我們的框架是這樣解決的。我們可以先看框架底下有一個 Schema。這一塊是我們對 AI 應用開發(fā)這個領域的一些基礎認知，它有哪些基礎領域模型，是在這里做了定義，包括流的處理也在這里做了定義。

往上一層是組件，組件都有哪些節(jié)點，各自有什么樣的信息處理范式，都是在 Components 層里定義的。我們還會有 Ext，就是擴展倉庫，里面會有針對每一個組件的具體實現(xiàn)。

再往上一層叫 Compose，就是我們的編排層，這里會沉淀剛剛說的第二個問題，就是如何把這些組件節(jié)點以一種合適的方式串起來，是這一層解決的問題。

最上面是 Flow 層，是剛才說的第三個問題，如何把我們一些認知的實踐做沉淀，把一些常用的編排模式沉淀成一個復合組件，可以作為其他組件的一個子部分出現(xiàn)。比如說 ReAct，就可以把我們之前遇到過的一些常用的模式給它做出來。

AI 應用實戰(zhàn)

下面我們進入第二部分，走一個比較小的例子，看一下開發(fā)的感覺是什么樣的。

這個例子非常簡單，并不是一個實際生產(chǎn)環(huán)境的例子。這個例子是說我們想安排一個主題樂園的一日游規(guī)劃，需要根據(jù)用戶的需求，比如我是幾個人玩，有沒有孩子，偏好什么樣等，去給我們安排樂園一日的行程。

首先做應用時，前幾步的過程是非常傳統(tǒng)的，跟我們之前開發(fā)的流程沒什么區(qū)別。我們還是需要先做領域的一些東西，需要先把領域模型建出來，定義幾個結構體。

這里就列了一個例子，這個例子是叫 activity，我們先定義一個樂園里的任意一項活動，我們都認為它是一個 activity，包括我們的游樂設施也好，表演也好，甚至餐廳吃飯也好，都是一個 activity，都把它作為一個需要花時間去做事，把它定義出來。

這時跟我們之前做開發(fā)時的唯一一個區(qū)別是，我們在定義這個對象時，需要把這個對象里的這些字段名定義得比較清楚一些，讓模型能夠看懂能夠理解。因為我們這個對象結構體定義以后，大概率是需要給模型作為我們工具的輸入的，所以這是一個需要注意的點。

第二部分跟我們之前開發(fā)也沒什么區(qū)別，就是我們要定義一些 function，所謂的函數(shù) service，就是領域服務。這里也舉了一個例子是說，我們要定義一個函數(shù)獲取這些游樂設施的信息。這是一個工具函數(shù)，未來我們大概率是需要把這個函數(shù)作為一個工具給我們的模型，讓它幫我們查詢需要對應的那些設施的信息。

這個函數(shù)的特點跟我們之前做的沒什么區(qū)別，就是一個普通的函數(shù)，唯一需要滿足的就是工具的定義，它需要有特定的一個入?yún)?，第一個是所謂的 context，第二個是所謂的 request。然后反參是 response 加 error，它是一個 golang 的工具定義的特定范式。

還有一點，既然我們這個函數(shù)它未來大概率是需要由模型拼接它的輸入，這個函數(shù)應該怎么調，它的入?yún)撛趺雌?，是由模型給出的。所以在我們這個函數(shù)的內部需要知道這個函數(shù)的入?yún)⑹悄Ｐ推吹?，也許我們就需要多做一些校驗，或多做一些合適的兜底方式讓入?yún)⒏戏ā?/p>

上面兩步是比較傳統(tǒng)的，無論怎么著都是避不開這兩步。

如果是我們做的是一個 AI 應用，基于 Eino 這樣的框架來做，那么第三步是一個新的步驟，我們需要做的是信息流的建模。我們的 AI 應用既然是一個信息流轉的過程，那么它應該是個什么樣的，這個問題是我們需要在這一步回答的。

首先第一步我們先確定我們的需求到底是什么，比如我們的需求，最終結果是給我們一日的行程規(guī)劃，這是我們產(chǎn)出的產(chǎn)物。

基于這個產(chǎn)物，它的上一步前提是我們需要把一些信息給到模型，這個信息是我要查到樂園的一些比如活動時間表，有什么樣的游樂設施，有什么樣的簡介，有什么樣的身高限制……這些信息我們要給到模型，所以我們需要獲取相關的真實信息，這兩步是必不可少的。

除此之外第三步是一個可選步驟，就是根據(jù)我們人類的解決問題的習慣，有的人習慣先給出一個規(guī)劃，先給出一個列表，里面分 12345，需要先獲取哪些信息，先查樂園開門時間，然后再查設施列表。給出一個計劃，再由模型執(zhí)行這個計劃?；蛘哒f我們是給出一個需求，幫我制定一個一家三口的一致行程。這一步是一個選項，不一定要。

上面是我們大概的流程，基于此，第二個我們需要解決的問題是在信息流里大模型要干什么，大模型的角色是什么？因為我們是 AI 應用，這是繞不開的一個問題，所以我們做了一個回答。第一點，大模型需要給出一個行程規(guī)劃，它需要根據(jù)我們一個 prompt，根據(jù)格式去給出一個規(guī)劃。

第二點，大模型需要發(fā)起工具調用，所謂發(fā)起是指它需要決定要調哪個工具，獲取什么信息，以及需要給工具一些什么樣的入?yún)⑷カ@取對應的信息。

第三步也是一個可選，如果我們選擇了先去制定計劃，再去完成計劃的這種解決問題的方式，那么模型需要干第三個事情就是它需要給出一個計劃，我們才能執(zhí)行。

下一步，我們再去基于上面給出決策的答案，選擇一下模型。這里大概選了一下，我們需要一個推理模型把這些信息整合起來，給出一個最終結果。這里選擇了 DeepSeek R1。同時我們還需要一個可以發(fā)起 funtion call 的模型幫我們拼接這些工具調用的入?yún)?，這里選了豆包模型去做。

第四點，我們最終決定一下，第一問里面的可選步驟我們要不要做，也就是先制定一個計劃再去干活。這里就決定要做，因為它比較符合我個人的習慣。

如果我們要做第一步的執(zhí)行計劃，整個信息流的結構就定下來了，它就是底下這個圖，這么一個先計劃執(zhí)行的一個多智能體的信息流結構。這里我先有一個任務，一個最初始的信息輸入，有了這個信息輸入之后，由一個模型，一個計劃智能體給出更多信息，根據(jù)這個任務擴展出一個整體計劃，這里面就是一個任務清單。第二步的是由一個執(zhí)行智能體，根據(jù)這個任務清單給出更多信息，決定我如何去執(zhí)行這些任務。執(zhí)行時要發(fā)起工具調用，以什么樣的入?yún)⑷フ{什么樣的工具，由它去執(zhí)行一步步的計劃，執(zhí)行完之后把這些工具調用的反饋結果給出來，給到我們的重新計劃智能體，由它匯總這些信息，最后按照我們的要求生成最終的結果。

當然這里面會有一個多步循環(huán)，就是我們的重新計劃智能體可以判斷目前信息不夠，目前的計劃需要調整，這時就會有一個重新生成的過程，去生成一個新的任務清單，再去執(zhí)行，再去做最終的判斷。

為什么我們要選擇一個計劃執(zhí)行的信息流范式，有幾個理由。第一個是我們可以為每一個智能體或者每一個模型節(jié)點，選擇一個合適的模型實現(xiàn)，匹配一個比較合適的模型，作為我們的 ChatModel 的輸出，這是第一點。

第二點，它是一個智能體層面的單一職責的原則。我們都知道編程時我們需要單一職責原則，那么這里它是一個智能體層面的單一職責原則的實踐。就是說這個模型它只干計劃的事情，或者只干執(zhí)行的事情，或者只干最終匯總的事情，不干其他的事情，是一個更明確的職責，比較解耦，比較方便我們去做 prompt 的調試或者評測的事情。

最后一點就是它比較符合我們人解決問題的通用模式，是一個處理問題的范式。

基于我們上面這些結論，就是我們要以那樣的方式去建信息流的模型，最后就是如何用這個框架去把我們信息流快速構建出來。這個示意圖是說基于 Eino 框架，我們是一個什么樣的格式，需要什么樣的節(jié)點，節(jié)點之間用什么樣的方式去連線，需要什么樣的分支。

這里會有三個 ChatModel，就是三個大模型節(jié)點，planner、executor 和 reviser。這三個節(jié)點分別輸入一個 message 列表，也就是說模型需要的上文是一個 message 列表。這三個節(jié)點的輸出分別都是單個 message，輸出的是明確的單個消息。

這兩個分支，branch1 是說 executor 執(zhí)行體的輸出會包含一個工具調用，也可能不包含。后者就是說我已經(jīng)把所有工具都執(zhí)行完了，不需要再執(zhí)行工具調用了。所以這個時候會有一個分支，根據(jù) executor 的輸出決定是否應該走工具調用的分支，還是需要把結果直接交給下一個模型 reviser 智能體，由它去輸出，這是第一個分支的作用。

branch2 的作用是 reviser 會決定我需要把這個結果最終給出用戶，或者是經(jīng)過我的判斷說需要重新規(guī)劃重新執(zhí)行，這時就會有一個判斷，branch2 去做這個判斷。

同時這個圖里還會有三個 tolist 節(jié)點，就是連接兩個大模型節(jié)點之間做數(shù)據(jù)轉換的。因為我們的大模型節(jié)點的輸入是一個消息列表，需要多條消息作為上下文，它的輸出是單個消息，因此當我們把兩個大模型節(jié)點連在一起時，需要把單個消息轉換成一個消息列表。所以這里就需要引入三個 tolist 節(jié)點。這時也展現(xiàn)了我們這個框架的一個特點，就是我們的節(jié)點之間的數(shù)據(jù)流轉是明確定義的，每個節(jié)點的輸出和輸入是什么類型，是定義得非常明確的。同時節(jié)點之間的連線，數(shù)據(jù)的流轉也是非常明確的，就是我們能用什么樣的方式，什么樣的結構去流轉，它是根據(jù)我們的輸出和輸入定義的，沒有任何模糊空間。所以我們需要明確定義出如何去轉換這些節(jié)點之間的數(shù)據(jù)。還要定義我們如何把這些 function 函數(shù)封裝成工具給到模型，這也需要我們用代碼的方式綁定工具的。

這里是運行的結果，一個是 planner 如何去給出我們需要執(zhí)行的計劃，下面 executor 如何根據(jù)我們的計劃去一步步調用工具。最后是 reviser，它要如何給出一個答案。這里會有多輪重復，就是多輪循環(huán)的過程。中間這些步驟都是通過流式的方式給出的，最終看時，我們可以看到 console 里是一個字一個字吐，它會不斷告訴我們當前最新的輸出是什么。

這個機制是用我們框架里面的 callback 事件機制，就可以把整個圖執(zhí)行過程之中的所有節(jié)點，它的流式或者非流式的信息能夠及時捕獲到，去做處理。

下面我們再看一個 All-In-One 個人助手的例子，有類似于最近比較火的 manus 的多智能體結構。我們可以類比一下剛剛那個例子，首先可以看到的一個差別很明顯的點。剛才那個例子要查詢的信息是比較專業(yè)的，基于領域之內的。那么個人助手所需要的信息是另外一個領域的信息。它雖然是 All-In-One，也是有特定領域的，一定是有一個范圍的。所謂范圍就是說我的工具是解決什么樣的問題，比如可以有代碼執(zhí)行器，可以有命令行執(zhí)行器，可以有 browseruse、computeruse 這些工具，可以有 MCP 的很多工具。這些工具跟我們上面那個例子是不一樣的，這是第一個區(qū)別。

第二個區(qū)別是它的整個信息流范式也是不一樣的。這個圖是一個示意圖，也是用計劃執(zhí)行這種治理模式。我們還可以用其他模式，比如說可以有多個智能體去做分級代理的模式，比如一個智能體可以負責一個子域，底下可以有多個相關工具，還會有一個總智能體做信息流的分發(fā)，這是一種模式。另一種模式是整體之間是一個平等的方式。但無論如何，它都是有組件和編排組合在一起的，都可以用我們的框架去實現(xiàn)。

我們再總結一下，問題是說我如何開發(fā)一個全能個人助手，這是從一句話需求開始的一個問題。現(xiàn)在我們需要問的另外一個問題是說我們有了這樣的框架后，要解決的問題是什么？

第一個我要確定用什么樣的工具。用什么樣的方式或者什么樣的工具是根據(jù)我們的領域確定的，這是一個問題。

第二個問題是我們如何建信息流的建模，有了這個之后就可以比較快速地把它搭起來，這樣就體現(xiàn)了我們框架作為基礎設施的價值，它可以幫我們很快地從 0 到 100。再到 1000 的話還需要我們自己去努力，它只是說不需要從 0~100，這個過程我們不需要自己去搞了。

AI 應用的未來

我們再展望一下 AI 應用的未來。AI 應用的發(fā)展一日千里，那么我們的 Eino 框架如何能在這種長期快速進展的基礎之上，保持長期的價值？不是說我們來了一個新模型，這個框架意義就不大了。這確實是我們需要考慮的一個點，這里我就嘗試著以個人的理解給出一個討論的點。假設我們的模型未來幾個月或者幾年變得很強，我們還會怎么樣？假如一個特別牛的人就是一個模型。那么在這個情況之下，我們做的應用還需要什么樣的框架？有這么幾個點應該還是需要的。

第一個點是說它還是需要跟人類去互動，因為畢竟是人用這個應用，所以它一定還是需要有人機交互的方式，還是需要有指令遵從的特性。

第二點，它還是需要上下文。無論它是如何牛逼的天才，還是需要有 attention，需要知道自己要解決的問題，需要關注的點，需要的信息輸入是什么，所以它一定會需要記憶，需要信息的召回，需要對世界的感知，需要上下文的管理。

第三點，它還是需要工具，還是需要能有手有腳幫它干事情，它還只是一個信息生成的節(jié)點，而對信息處理的能力，它還是需要工具擴展開來。

最后一點是信息流的編排。無論多么牛的人還是需要跟別人合作的，只要有合作，就一定會有信息的流轉模式，有信息的編排，有解決問題的范式。

所以未來會變的要素是更強的推理，更快的速度，這是沒問題的。不變的要素會有人機交互、有上下文、有工具和信息處理。所以基于這些認知，我們的框架在現(xiàn)在以及未來會有一些重點方向。

這些標紅的節(jié)點就是重點。第一，我們會有為了人機交互而重點開發(fā)，已經(jīng)上線的 interrupt 和 checkpoint，就是圖執(zhí)行的中斷和繼續(xù)的能力，以及我們目前正在探索的多智能體交互的方式。

第二點，我們會拓展工具的內容，比如說我們之前提供的 MCP 的相關能力，以及目前正在開發(fā)的 computer use 這類開箱即用的工具，我們會持續(xù)不斷地擴展。

第三點就是 memory 記憶模塊，上下文模塊，我們也在不斷探索。

最后就是對編排能力的擴展，我們對最近的 workflow 做了很大擴展，可以提供更加靈活的數(shù)據(jù)流的運算方式。 上圖右邊這三個是我們目前開源的三個倉庫，一個是核心庫，一個是擴展庫，一個是應用類庫。大家可以關注一下，跟我們一起去探索 AI 應用的未來。目前這個框架在我們自己內部用得比較廣泛，比如說豆包、抖音、扣子等很多業(yè)務線都在用。

大家會問的一個常見問題是，這個 Eino 框架到底跟 Langchain 這種非常主流的方向之間有什么區(qū)別？如何選型？Langchain 是我們的前輩學習對象，它的生態(tài)成熟度和案例豐富度是毫無疑問非常強的。所以如果我們是 Python 開發(fā)、原型開發(fā)、是科研，那么用 Lang 是沒問題的，它可以很快很方便地幫你做這個事兒。

Eino 的特點是它比較適合大規(guī)模的生產(chǎn)部署，因為它的語言是 golang 的，它目前的使用場景是字節(jié)內部的大流量應用，所以它比較適合需要性能比較高，并行比較高的這種情況。同時 Eino 的編排能力，就是如何把這些節(jié)點串起來的能力上我們是比較強的。所以如果說我們的場景是 golang 或者是大規(guī)模生產(chǎn)，或者比較復雜的應用，那么用 Eino 是一個不錯的選擇。

嘉賓介紹

沈桐，字節(jié)跳動研發(fā)工程師，北大本科畢業(yè)，在字節(jié)跳動工作三年半，近一年在 AI 相關部門聚焦 AI 應用開發(fā)平臺相關工作，是 Eino 開發(fā)框架的核心開發(fā)者之一。

QCon 上海站（10.23-25）干貨拉滿：Agentic AI、具身智能等前沿方向，疊加可觀測、AI 中間件等經(jīng)典領域，熱點技術 + 落地難點一次性搞定！9 折優(yōu)惠 9 月 25 日結束，抓緊時機！單張立省 680 元，掃碼還可以免費領資料包，咨詢票務經(jīng)理 18514549229 了解更多。