新智元報(bào)道

【新智元導(dǎo)讀】當(dāng)Agent數(shù)量增多時(shí)，管理混亂成為難題。OpenRath提出用Session作為核心，代替Agent為中心的設(shè)計(jì)，使多個(gè)Agent能共享狀態(tài)，實(shí)現(xiàn)更清晰的協(xié)作與控制。

Agent越來(lái)越多，Session卻越來(lái)越亂。

這是幾乎所有人把多智能體系統(tǒng)真正跑大之后，都會(huì)撞上的一堵墻。

一個(gè)Agent維護(hù)一份上下文，另一個(gè)Agent又復(fù)制一份歷史；一個(gè)任務(wù)分叉出好幾條推理路徑，最后沒(méi)人說(shuō)得清哪條分支產(chǎn)出了最終答案；模型調(diào)用、工具執(zhí)行、沙箱環(huán)境、長(zhǎng)期記憶各管各的狀態(tài)——demo 跑得挺好，可當(dāng)系統(tǒng)擴(kuò)到幾十上百個(gè) Agent，調(diào)試、復(fù)現(xiàn)、編排全部開(kāi)始失控。

最近，一個(gè)來(lái)自清華大學(xué)與中山大學(xué)的團(tuán)隊(duì)（Rath Team）把他們的解法開(kāi)源了，叫OpenRath：這是一個(gè)像PyTorch的多智能體、多會(huì)話運(yùn)行時(shí)。

它的主張是：別再圍著Agent轉(zhuǎn)了。真正該被當(dāng)成一等公民的，是Session。

官網(wǎng)：https://www.openrath.com/

文檔：https://docs.openrath.com/

博客：https://blog.openrath.com/

GitHub：https://github.com/Rath-Team/OpenRath

開(kāi)源協(xié)議：BSD-3-Clause ｜ 當(dāng)前版本：v1.2.1（PyPI）

目前OpenRath已在PyPI發(fā)布到 v1.2.1，pip install openrath就能裝，BSD-3-Clause協(xié)議，官網(wǎng)、文檔、博客、GitHub一應(yīng)俱全。

本文將從「為什么」一路講到「怎么用」，重點(diǎn)拆OpenRath和AutoGen、LangGraph這些框架到底不一樣在哪——以及它為什么敢借PyTorch的名字。

Agent運(yùn)行時(shí)用「聊天記錄」思考

第一性問(wèn)題：當(dāng)Agent真的動(dòng)了手，證據(jù)該存在哪？

第一代大模型應(yīng)用，可以概括成「提示詞進(jìn)、回答出」。Agent系統(tǒng)改變了這條邊界。

一個(gè)有用的Agent不只是產(chǎn)出文本。它會(huì)檢索、規(guī)劃、調(diào)用工具、讀文件、寫(xiě)代碼、查API、跑測(cè)試、操作瀏覽器，有時(shí)還會(huì)改動(dòng)外部狀態(tài)。ReAct讓推理和行動(dòng)在一個(gè)循環(huán)里交替，Toolformer 讓模型學(xué)會(huì)何時(shí)調(diào)用工具，再到Model Context Protocol把工具變成協(xié)議級(jí)的邊界，這條線一直在往前走。

可一旦Agent真的對(duì)世界動(dòng)了手，一個(gè)運(yùn)行時(shí)層面的問(wèn)題就冒出來(lái)了：這些動(dòng)作的證據(jù)，到底存在哪？

如果一次工具調(diào)用讀了文件，我們需要它的參數(shù)和結(jié)果；如果它改了倉(cāng)庫(kù)，我們需要diff；如果它跑在某個(gè)沙箱里，我們需要沙箱的身份；如果它失敗重試了，我們需要那條失敗路徑；如果有人批準(zhǔn)或否決了某個(gè)動(dòng)作，我們需要那個(gè)校驗(yàn)信號(hào)。一份聊天記錄頂多敘述這些事，卻不足以還原這些事。

舉個(gè)具體例子。

一個(gè)軟件任務(wù)：研究Agent讀了issue、檢索了筆記；編碼Agent改了倉(cāng)庫(kù)；沙箱跑了測(cè)試；校驗(yàn)Agent否決了第一版補(bǔ)丁，于是工作流分叉；記憶后端記下這次失敗，免得以后重犯。如果這些事件散落在各自的日志里，那么最終答案幾乎是最不重要的產(chǎn)物，真正有價(jià)值的，是那條「工作如何一步步推進(jìn)」的證據(jù)鏈。

這就是OpenRath的出發(fā)點(diǎn)：把Session當(dāng)成證據(jù)的載體，而不只是聊天歷史。

為什么是Agent Cluster

單個(gè)Agent會(huì)膨脹成一個(gè)巨大的prompt，于是要把它拆開(kāi)。

早期一個(gè)Agent基本夠用：接收輸入、理解任務(wù)、調(diào)用工具、返回結(jié)果，像個(gè)增強(qiáng)版聊天機(jī)器人。但真實(shí)任務(wù)很快超出單個(gè)Agent的邊界。

一個(gè)像樣的軟件工程任務(wù)，往往要拆成需求理解、資料檢索、架構(gòu)設(shè)計(jì)、代碼實(shí)現(xiàn)、測(cè)試驗(yàn)證、結(jié)果審查。不同環(huán)節(jié)要的能力并不一樣——有的擅長(zhǎng)規(guī)劃，有的擅長(zhǎng)寫(xiě)碼，有的擅長(zhǎng)挑錯(cuò)。繼續(xù)讓一個(gè)Agent全包，它就會(huì)膨脹成一個(gè)巨大的prompt和一個(gè)越來(lái)越混亂的上下文窗口。

于是有了Agent Cluster：讓Planner、Researcher、Coder、Reviewer、Executor、Memory Agent各司其職，圍繞一個(gè)復(fù)雜目標(biāo)協(xié)作。

多個(gè)專(zhuān)業(yè)Agent圍繞共享的Session協(xié)作：各自讀取當(dāng)前狀態(tài)、完成局部任務(wù)、把結(jié)果寫(xiě)回，供下一個(gè)Agent接力。

可一旦真把它跑起來(lái)，難題就冒出來(lái)了：這些Agent怎么共享上下文？某個(gè)結(jié)論到底來(lái)自哪個(gè)Agent、哪條分支、哪次工具調(diào)用？一個(gè)Agent出了錯(cuò)，能不能回滾到對(duì)應(yīng)分支重來(lái)？

說(shuō)白了，Agent Cluster真正的挑戰(zhàn)，從來(lái)都不在「造更多Agent」——難的是管住這些Agent之間的狀態(tài)怎么流動(dòng)。

OpenRath多問(wèn)了一句

別人解決Agent之間怎么說(shuō)話，它問(wèn)說(shuō)完之后誰(shuí)擁有這份工作。

多智能體這個(gè)詞，常讓人想到一個(gè)群聊：一個(gè)Agent提議，一個(gè)批評(píng)，一個(gè)執(zhí)行，一個(gè)主管決定什么時(shí)候收尾。這個(gè)模式有用，但不夠。

這條路上已經(jīng)有不少工作：AutoGen把多Agent對(duì)話做成了一個(gè)實(shí)用的編程模型；CrewAI把Agent團(tuán)隊(duì)和更結(jié)構(gòu)化的流程分開(kāi)；LangGraph用圖狀態(tài)和supervisor節(jié)點(diǎn)來(lái)表達(dá)路由與控制。它們都解決Agent之間怎么說(shuō)話。

OpenRath接著往下問(wèn)了一句：Agent們說(shuō)完話之后，誰(shuí)來(lái)?yè)碛羞@份工作的狀態(tài)？

一個(gè)生產(chǎn)級(jí)的Agent Cluster，需要決定：當(dāng)前這個(gè)Session該交給哪個(gè) Agent、它該看到什么上下文、讀了哪些記憶、下一條命令在哪個(gè)沙箱跑、繼續(xù)之前需要什么校驗(yàn)信號(hào)。這些都是控制平面的問(wèn)題，靠往群聊里再加一個(gè)角色是解決不了的。OpenRath的答案是：讓Session成為路由的單位，讓Session Graph成為那張控制平面——Agent、工具、工作流、記憶、沙箱位置，都在這張圖上交匯。

一句話：Agent集群不是群聊，而是建立在持久Session狀態(tài)之上的運(yùn)行時(shí)控制平面。

這也是為什么，從Agent數(shù)量×Session數(shù)量兩個(gè)維度看，多智能體系統(tǒng)會(huì)分成四象限：

單Agent單Session是ChatGPT式聊天；多Agent單Session是子代理協(xié)作；單Agent多Session是OpenClaw式分支扇出；而多Agent多Session（MAMS），正是OpenRath面向的方向。

OpenRath把這套思路稱(chēng)為MAMS（Multi-Agent Multi-Session）。它的判斷很干脆：真正需要被fork（分叉）、merge（合并）、復(fù)用、追蹤的，是整條Session數(shù)據(jù)流——而非某個(gè)Agent內(nèi)部那份各自維護(hù)的消息列表。

換個(gè)說(shuō)法：大多數(shù)框架攢的是一屋子聰明的工人，OpenRath先把工位、工單和流水線建好。用官方那句話說(shuō)就是——Agent是工人，Session才是工作本身。

像PyTorch一樣搭A(yù)gent集群

這不是蹭名字。

PyTorch之所以好用的三個(gè)設(shè)計(jì)，OpenRath一一對(duì)應(yīng)搬了過(guò)來(lái)。

OpenRath最聰明的一步，是把深度學(xué)習(xí)開(kāi)發(fā)者最熟的那套抽象，整套搬到了Agent系統(tǒng)上。

PyTorch為什么好用？因?yàn)樗褟?fù)雜計(jì)算拆成了清晰的積木：Tensor是流動(dòng)的數(shù)據(jù)，Module/Layer是變換這份數(shù)據(jù)的可組合單元，device決定算在哪，而整張計(jì)算圖是跑起來(lái)才長(zhǎng)出來(lái)的。OpenRath給Agent系統(tǒng)做了幾乎一一對(duì)應(yīng)的映射：

核心映射：Tensor→Session、Module/Linear→Workflow/Agent、Device→Sandbox / Backend、Parameter→Memory、Function→Tool、控制流→Selector。

下面三節(jié)，正是把這張表里最關(guān)鍵的三組對(duì)應(yīng)，從術(shù)語(yǔ)對(duì)照講成為什么這么設(shè)計(jì)。

這套映射不是噱頭。把它拆開(kāi)，PyTorch真正教給OpenRath的，其實(shí)是三件事——下面三節(jié)，正好是理解OpenRath的三根支柱。

支柱一：Agent是變換層 ，不是全能助手

Layer不持有數(shù)據(jù)；Agent也不持有狀態(tài)。

PyTorch里，nn.Linear不是一個(gè)應(yīng)用，它只是一層變換：吃進(jìn)一個(gè)Tensor，吐出一個(gè)Tensor。一個(gè)網(wǎng)絡(luò)的本事，來(lái)自很多這樣的層被疊起來(lái)。

OpenRath把Agent設(shè)計(jì)成了同一種東西。Agent就是Session上的一層變換。它的核心，就是一條forward(session) -> session的路徑：進(jìn)來(lái)一個(gè)Session，出去一個(gè)Session。

關(guān)鍵在于，變換層不止一種。同樣是forward(session) ->session這個(gè)形狀，可以裝下完全不同的活兒：

• 一個(gè)Agent調(diào)工具、改workspace里的文件，把執(zhí)行結(jié)果寫(xiě)回Session；

• 一個(gè)Compressor把跑了幾十輪的長(zhǎng)會(huì)話壓縮成一條精簡(jiǎn)消息（官方example第 8課就是它）；

• 一個(gè)Agent在跑之前recall記憶、跑之后commit記憶，相當(dāng)于給這次會(huì)話做了一次「索引與歸檔」；

• 你也可以寫(xiě)一個(gè)只做摘要、只做校驗(yàn)、只做改寫(xiě)的Agent。

它們對(duì)外都是同一個(gè)接口，于是能像神經(jīng)網(wǎng)絡(luò)的層一樣任意堆疊、任意嵌套。這正是Workflow（對(duì)應(yīng)nn.Module）的意義：子類(lèi)只要實(shí)現(xiàn)一個(gè)forward(session) -> session，里面就能串聯(lián)多個(gè)Agent、fork Session、壓縮上下文、調(diào)用工具、分發(fā)到子工作流。因?yàn)槊恳粚舆M(jìn)出都是 Session，Workflow能像nn.Module一樣層層包起來(lái)，每層不必重新發(fā)明一套狀態(tài)格式。

管上百個(gè)Agent，于是從拼提示詞變成了搭模塊。Layer不持有數(shù)據(jù)，數(shù)據(jù)是 Tensor；Agent 也不持有狀態(tài)，狀態(tài)是Session。

這里還藏著一個(gè)容易被忽略的好處。因?yàn)锳gent不擁有整個(gè)世界——Session loop仍是引擎，Sandbox仍是執(zhí)行位置，Memory仍是獨(dú)立store——所以單個(gè)Agent的場(chǎng)景足夠簡(jiǎn)單，同一個(gè)Agent又能被原樣塞進(jìn)更大的 Workflow，不用改一行。

至于工具本身，OpenRath抽象成了FlowToolCall：一手攥著給模型看的name / description / JSON schema，一手攥著真正在Python里執(zhí)行的行為，讓工具長(zhǎng)什么樣」和工具干什么始終待在一起。內(nèi)置了文件、shell、代碼執(zhí)行工具，stdio的MCP工具也能直接適配進(jìn)同一個(gè)循環(huán)。底層還有個(gè)清晰的分層：FlowToolCall是flow層模型可見(jiàn)的函數(shù)，BackendTool*才是沙箱后端真正消費(fèi)的載荷。

支柱二：Sandbox與Memory是「可插拔后端」

把后端寫(xiě)死，等于把模型焊在CPU上。

PyTorch第二個(gè)聰明的地方，是把「算在哪」從「算什么」里剝了出來(lái)。同一份模型代碼，.to("cuda")就上GPU，換個(gè)后端就換塊卡，計(jì)算邏輯一行不用動(dòng)。device / compute backend是可插拔的。

OpenRath把這個(gè)思想用在了兩個(gè)最容易被寫(xiě)死的地方：執(zhí)行環(huán)境和長(zhǎng)期記憶。

Sandbox（對(duì)應(yīng) Device）——工具到底在哪運(yùn)行。很多框架把「對(duì)話歷史」和「工具實(shí)際執(zhí)行的位置」分開(kāi)管，模型以為自己還在某個(gè)工作區(qū)，shell或容器其實(shí)早就切走了。

OpenRath把Sandbox綁在Session上：工具跑在Session當(dāng)前的backend上，返回的Session會(huì)記住自己的執(zhí)行位置，不會(huì)悄悄漂移。

而它真正的巧思，是把Sandbox做成了可插拔的backend：本地進(jìn)程始終可用（session.to("local", spec="./")），容器化的OpenSandbox是可選項(xiàng)（pip install "openrath[opensandbox]"），未來(lái)任何第三方執(zhí)行后端，只要接到同一套 Session placement 模型后面就能用。執(zhí)行環(huán)境，從此不再硬編碼進(jìn)某一個(gè) shell。

Memory（對(duì)應(yīng) Parameter）——跨運(yùn)行保留的記憶。

它是獨(dú)立的一層持久狀態(tài)，能綁定到 Agent、運(yùn)行前 recall、運(yùn)行后 commit；既不像工具結(jié)果那樣用完即棄，也不只是塞進(jìn) prompt 的幾行文本。

基礎(chǔ)安裝自帶零依賴的本地后端，把數(shù)據(jù)存在.openrath/memory/，不用 LLM 也能做BM25詞法檢索；

配了embedding就能用向量排序；想要更強(qiáng)的，可以接OpenViking這類(lèi)外部記憶服務(wù)。和Sandbox一樣，Memory同樣是可插拔backend——recall不綁死在某一個(gè)數(shù)據(jù)庫(kù)上。

這一招對(duì)自帶本地狀態(tài)的團(tuán)隊(duì)尤其友好：你已經(jīng)有自己的容器調(diào)度、有自己的向量庫(kù)或知識(shí)庫(kù)，不必推倒重來(lái)，只要把它包成一個(gè)backend接進(jìn)去，就能復(fù)用OpenRath的整套Session / Workflow抽象。說(shuō)到底，把執(zhí)行環(huán)境和記憶都做成可換的device，OpenRath才能讓狀態(tài)、執(zhí)行、記憶、編排彼此解耦到足以各自替換，卻又都串在同一個(gè)流動(dòng)的值——Session——上。

支柱三：Session Graph是動(dòng)態(tài)圖

PyTorch的圖是跑起來(lái)才長(zhǎng)出來(lái)的，OpenRath的Session Graph也是。

PyTorch還有第三個(gè)讓人上癮的設(shè)計(jì)：動(dòng)態(tài)圖（define-by-run）。它不要求你先把整張計(jì)算圖畫(huà)死再喂數(shù)據(jù)，而是代碼跑到哪、圖就長(zhǎng)到哪。控制流就是普通的Pythonif/for，靈活到可以在運(yùn)行時(shí)根據(jù)中間結(jié)果改變走向。

OpenRath的Session Graph，是同一個(gè)性格的東西。

先看Session長(zhǎng)什么樣。它遠(yuǎn)不止一串聊天記錄——而是一張結(jié)構(gòu)化的chunk表，大致是這個(gè)形狀：

Session├─ chunks: [ {role: system,     ...},          # Agent 指令也是一條 chunk│            {role: user,        text: "..."},│            {role: assistant,   text: "..."},│            {role: tool_result, name, args, result} ]  # 工具證據(jù)├─ placement: "local" / "opensandbox"          # 這一段在哪執(zhí)行├─ lineage:   parent / fork / merge 關(guān)系        # 我從哪條分支來(lái)└─ usage:     token 用量

它能fork出分支，能detach切斷父鏈，能merge合并，還能序列化成JSONL直接交給下一個(gè)Workflow。而這張由fork / merge織出來(lái)的圖，是Agent們跑起來(lái)、一步步演化出來(lái)的，并非事先畫(huà)死的劇本——這正是「動(dòng)態(tài)圖」的含義。

Session沿著fork / merge演化，每一步都留下血緣；工具運(yùn)行環(huán)境則由Sandbox backend綁定。這張圖不是預(yù)先編排好的，而是隨Agent運(yùn)行實(shí)時(shí)生長(zhǎng)。

為什么這件事對(duì)Agent Cluster是決定性的？因?yàn)榧阂?guī)模一大，你遲早要回答：這個(gè)結(jié)論到底是哪個(gè)Agent、走哪條分支、調(diào)哪次工具、在哪個(gè)workspace產(chǎn)出的？散落的日志答不了，一張帶血緣的動(dòng)態(tài)圖能答。Session Graph于是從實(shí)現(xiàn)細(xì)節(jié)升格成了集群的可觀測(cè)層與控制層：路由、復(fù)現(xiàn)、回滾、審計(jì)，全在同一張圖上做。

幾十行，把這套東西跑通

抽象講再多，不如看一段能跑的代碼。

下面這個(gè)最小例子（取自官方README的最小完整工作流），把Session、Sandbox、Tool、Agent、Memory、Workflow、Compressor一次性串了起來(lái)：

from rath import flowfrom rath.session import Sessionclass ReadmeWorkflow(flow.Workflow):    def __init__(self):        provider = flow.Provider(model="gpt-5.5")# Agent：一層帶 prompt / 工具 / 記憶的變換        self.agent = flow.Agent(            "Use the `word_count` tool, then answer briefly.",            provider, tools=[WordCountTool()], memory="local",        )# Compressor：另一種變換層——把長(zhǎng)會(huì)話壓成一條精簡(jiǎn)消息        self.compressor = flow.Compressor("Compress the run into one message.", provider)    def forward(self, session: Session) -> Session:        self.agent.remember_memory("The user likes compact summaries.")  # 運(yùn)行前寫(xiě)記憶        session = self.agent(session)                                    # 一層變換        self.agent.commit_memory(session)                                # 運(yùn)行后提交記憶return self.compressor(session)                                  # 再疊一層變換# Session 承載數(shù)據(jù)，Sandbox 決定執(zhí)行位置session = Session.from_user_message("Count the words in: OpenRath makes agent clusters traceable.")session = session.to("local", spec="./")out = ReadmeWorkflow()(session)

讀這段代碼，三根支柱全在里面：數(shù)據(jù)是Session，執(zhí)行位置由.to()決定（支柱二），agent和compressor是兩層不同的變換疊起來(lái)（支柱一），而它們?cè)趺创⒋畮讓?，?/code>forward里用普通Python寫(xiě)出來(lái)的（支柱三）。每一步進(jìn)出，都是同一個(gè)Session。

真正動(dòng)態(tài)的地方Selector

把流程寫(xiě)進(jìn)提示詞是焊死，交給Selector才是讓系統(tǒng)學(xué)會(huì)拐彎。

上一節(jié)的forward是寫(xiě)死的順序。但真實(shí)任務(wù)往往要等跑起來(lái)才知道該往哪拐——這時(shí)候就輪到動(dòng)態(tài)圖的「運(yùn)行時(shí)路由」登場(chǎng)。

很多框架的做法是把流程提前編排死：if走A，else走B。

OpenRath的答案是Selector：一個(gè)由大模型驅(qū)動(dòng)的路由器。它在若干個(gè)「會(huì)自我描述」的Workflow之間做選擇，返回下一個(gè)該跑的Workflow，任務(wù)結(jié)束就返回一個(gè)空操作。妙處在于——它讓Agent之間的if/while，依然是普通的Python：

selector = flow.Selector(provider)while not isinstance(    nxt := selector.forward(session, triage, tech, wrapup), flow.EmptyWorkflow):    session = nxt(session)

把流程寫(xiě)進(jìn)提示詞，是把不確定性焊死；交給 Selector，才是讓系統(tǒng)學(xué)會(huì)拐彎。這也正是官方把OpenRath稱(chēng)為"dynamic multi-agent workflow"的底氣：流程從寫(xiě)死的劇本，變成了運(yùn)行時(shí)才定下來(lái)的路由——和PyTorch 動(dòng)態(tài)圖里那句代碼跑到哪、圖就長(zhǎng)到哪是同一種自由。

它現(xiàn)在到底能不能用？

能裝、能跑、能照著學(xué)——不是一份PPT。

最能說(shuō)明問(wèn)題的是它的example/目錄——一條編號(hào)遞進(jìn)的學(xué)習(xí)階梯，每個(gè)腳本只講一個(gè)概念，前一個(gè)的產(chǎn)出正好是后一個(gè)的輸入：

已在GitHub開(kāi)源，BSD-3-Clause協(xié)議，可直接pip install openrath。

• 01_hello_agent：最小程序，構(gòu)造Agent、在Session上調(diào)用、流式輸出

• 02_session_lineage：用fork分叉、detach切斷血緣、查看session graph、導(dǎo)出JSONL

• 03_sandbox_backend：把同一個(gè)Session放到local或opensandbox，看工具在哪執(zhí)行

• 04_tools_builtin/05_custom_tool/06_mcp_tool：內(nèi)置工具、自定義工具、借用MCP工具

• 07_streaming/08_compress/09_memory/10_provider_variation：流式、上下文壓縮、記憶、換模型廠商

• 11_dynamic_selector：用Selector做if分支和while循環(huán)

從「先讓一個(gè)Agent跑起來(lái)」到「讓一群Agent動(dòng)態(tài)協(xié)作」，11步走完，OpenRath的核心也就理解透了。

安裝也分層：基礎(chǔ)pip install openrath，要容器沙箱加[opensandbox]，要外部記憶加[openviking]，模型則走 OpenAI 兼容的環(huán)境變量或~/.openrath/config.json。

更值得說(shuō)的是這套 example 的設(shè)計(jì)取向：官方強(qiáng)調(diào)，例子的目標(biāo)是產(chǎn)出一份「證據(jù)檔案」，而不是一張截圖。一個(gè)軟件任務(wù)跑完，理想的產(chǎn)物不該只停在一句「成功了」，而該是一整份可回溯的卷宗——

issue 原文 → Session Graph → 調(diào)了哪些工具 → 副作用落在哪個(gè) sandbox → 被否決的那條分支 → 最終采納的補(bǔ)丁 → 測(cè)試結(jié)果 → 這次往 Memory 里寫(xiě)了什么。

這份卷宗，正是「一個(gè) demo」和「一個(gè)能拿來(lái)做技術(shù)報(bào)告的運(yùn)行時(shí)」之間的區(qū)別。按團(tuán)隊(duì)自己的說(shuō)法，他們?cè)趦?nèi)部已經(jīng)用 OpenRath 組織起接近 Transformer 結(jié)構(gòu)的 Agent Workflow——不過(guò)這更偏系統(tǒng)能力驗(yàn)證，還不是公開(kāi) benchmark，這點(diǎn)他們說(shuō)得很坦白。

從持久Session，到Agent Cluster


v1.1讓單個(gè)Agent的工作可追溯，v1.2讓一群Agent的協(xié)作可追溯。

把視野拉遠(yuǎn)一點(diǎn)：OpenRath的版本演進(jìn)本身就是一條干凈的線。v1.1解決「持久」——如果一個(gè)Agent的工作是跨時(shí)間展開(kāi)的，憑什么唯一被保存的只有最終答案？于是有了持久Session，把干活的證據(jù)完整留下。v1.2再抬高一層：讓Session從「單個(gè)Agent事后可查的記錄」，升級(jí)成「能在多個(gè)Agent和工作流之間被路由的對(duì)象」。一行代碼就概括了這個(gè)轉(zhuǎn)變：

session = workflow.forward(session)

它意味著，工作的單位從一個(gè)prompt、一個(gè)答案或一個(gè)Agent角色，挪到了一份持久、可路由的Session狀態(tài)上。

從Prompt 工程

走向系統(tǒng)工程

OpenRath的意義，不只是「又一個(gè)Agent框架」。

它真正想解決的是：當(dāng)Agent Cluster成為主流形態(tài)，開(kāi)發(fā)者能不能像寫(xiě)深度學(xué)習(xí)那樣，獲得一套可組合、可追蹤的工程體驗(yàn)。這正是它借PyTorch之名的底氣——同一套直覺(jué)遷移了過(guò)來(lái)：層是變換（Agent），device可插拔（Sandbox / Memory backend），圖是動(dòng)態(tài)的（Session Graph）。

在PyTorch里，你定義Module，讓Tensor在網(wǎng)絡(luò)中流動(dòng)；在OpenRath里，你定義Agent和Workflow，讓Session在系統(tǒng)中流動(dòng)。剩下的——血緣記錄、工具調(diào)度、沙箱綁定、長(zhǎng)期記憶、動(dòng)態(tài)路由——交給框架。

如果說(shuō)過(guò)去的Agent框架面向的是「一個(gè)智能助手」，那么OpenRath面向的是「一個(gè)智能體系統(tǒng)」。

而這件事的起點(diǎn)，樸素得有點(diǎn)反直覺(jué)——不是再多造一個(gè)Agent，而是先把Session當(dāng)回事。

參考資料：


https://www.openrath.com/

編輯：LRST