# 策展 · X (Twitter) 🔥

> 作者：leon7hao (@leon7hao) · 平台：X (Twitter) · 日期：2026-04-27

> 原始來源：https://x.com/leon7hao/status/2048630393528865035

## 中文摘要

# Lody: 隨時隨地指揮你的 Agent 團隊 - Build 03 講稿

原文連結： https://leon7hao.com/posts/2026-04-26-lody

這篇文章是我在 2026 年 4 月 26 日參加杭州 build 03 活動上的演講稿，主題是 **Lody: 隨時隨地指揮你的 Agent 團隊**。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057453-iaHG4fc5BbAAAN9BDjpg.jpg)

大家好，我是 leon7hao，之前在達摩院做視覺演算法，目前創業在做 loro.dev 和現在的 lody.ai。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057568-iaHG4fkFZaIAAhaGEjpg.jpg)

在主題開始之前，我需要花幾分鐘介紹一下 Loro。Loro 是一個高效能的 CRDTs 框架，解決的是多端同步和多人協作上資料衝突的問題。例如筆記場景、設計軟體場景，我們同時編輯一份文件，可能離線可能並行，誰應該覆蓋誰，誰的編輯應該在前誰在後，CRDTs 是一種演算法，專門用來解決分散式場景、離線優先場景下的資料衝突自動合併。我們不保證強一致性，但保證最終一致性。

也就是說，這裡的衝突解決可能不符合真實的意圖，但是只要我們透過同步得到的操作集合是一樣的，那麼所有人看到的狀態就是完全一樣的。相較於當前常用的 OT 中心化演算法，CRDTs 是可以做到業務無關的、自帶版本控制的、End to End (端到端) 加密的。我們的理念是本地優先，使用者自己設備上的那份資料才是 truth of source，保障使用者資料的所有權、控制權，同時享受網際網路帶來的協作好處。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057317-iaHG4fpULa0AA8m5bjpg.jpg)

這部分可以直接看之前的分享，Local-first：不同以往的開發者體驗，本地優先是一種新的軟體開發範式，強調使用者對資料的控制權和所有權，同時結合雲端的便利性進行協作。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057331-diaHG4fruobUAAg9sjpg.jpg)

我們圍繞 Loro 做了一些基建，正在去做對應的商業化，聚焦在同步領域的垂類部署服務。同時服務一些海外客戶，但是他們用得好不好、對不對，我們沒有體感。所以我們需要一個自己的場景來回饋，有對多端同步需求的、和 AI 相關的、最好能夠帶來一些現金流的，我們必須每天自己在用的 dogfood，所以就是 coding，然後做了 Lody。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057501-iaHG4f1uRasAANmZejpg.jpg)

簡單地講，就是在所有平台（桌面端、web 端、行動裝置端）來控制你自己的設備上的任意 Code Agent。

一開始是解決我們團隊自己的問題，我們希望能夠共享訂閱、能夠穩定 IP 不封號、有更好的並行開發能力、有更好的互動，能夠看到對方在做什麼。所以先從 web 入手，在伺服器啟動一個 CLI，伺服器轉發命令能夠跑起來了。慢慢迭代，變成了現在 Lody 的樣子。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057581-iaHG4f4jia8AAnyDWjpg.jpg)

Lody 當前版本的樣子，左側是 sidebar，也就是你的 workspace 中的所有對話列表，支援 Chat、Local Project 和 GitHub WorkTree 三種對話類型。如果是 GitHub 整合的專案，會自動管理 worktree 進行並行開發，有 PR、分支的自動關聯等。中間是對話區，使用友好的 GUI 方式展示對話內容和 Agent 的執行過程。每輪對話之後都可以看到 Agent 的修改結果，你可以給 Agent 發送圖像，它也可以給你返回圖像。右側是資訊區，你可以查看文件、查看所有當前對話文件變更、查看對應的 PR 資訊。還有更多 coding 場景下優化過的功能，可以查看官網的文件。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057365-iaHG4f7vIaUAAd0Yvjpg.jpg)

這是我們當前的行動裝置端，基本上是桌面端簡單改了一下適合行動裝置端的佈局，之後會做更多 UI UX 上的優化，增加一些行動裝置端特有的功能。之前提到的所有能力，行動裝置端也都是支援的。這意味著，你可以出門只帶個手機，就可以和在電腦前一樣高效地指揮你的 Code Agent。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057336-diaHG4f37boAAnTBqjpg.jpg)

那麼 Lody 解決了什麼問題呢？

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057354-iaHG4gBeAbwAA15Idjpg.jpg)

現在 Code Agent 大概十幾分鐘到半小時左右去完成一項任務，複雜一些的可能跑一個多小時。這時候也不能乾等著，開一個新的對話視窗，但可能互相干擾，剛用 Claude Code 遇到過好幾次，一個偷偷把另一個改的給還原了。所以需要磁碟文件上的隔離，就自然地要使用 worktree 這個東西，但這個東西挺難用，尤其是你需要本地測試的時候，涉及到環境變數、一些非 git 管理的文件。有一個主的工作目錄，想切到下一個功能分支發現它在另一個 worktree 上，切不過來。

我們的方式是，worktree 只給 Agent 用。Lody 做好建立和回收，保持分支遠端最新。人類就用本地自己的，想開發哪個切哪個，env 什麼的就同一份，測試之前 git pull 一下。這樣的 workflow。測試出有什麼問題就繼續之前的對話，讓 AI 繼續修，本地再 pull 過來。反正我是這麼用的。最大的好處就是，節省了你的注意力。完全不用考慮單 workspace 多視窗是否功能模組正交的問題，不用考慮剛剛的功能在哪個目錄，worktree 怎麼管理的問題。

很多人沒有辦法多個功能並行開發修復，我覺得很大的原因在於，關注了太多本應完全可以放手、不用進腦子的問題。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057310-iaHG4gNiEbsAA1HJvjpg.jpg)

多端同步的好處是你不用擔心我突然被打斷了怎麼辦，隨時出個門，坐個捷運遛個狗，完全不會有潛在的心理負擔，拿起手機就走，打開之後和在電腦前是完全一樣的狀態，這樣才是無縫的。除此以外，我們的同步是支援多人協作的，支援離線優先的、可以支援 End to End (端到端) 加密的。如果你關注隱私，注重私有資料安全，但又想有這種無縫的體驗，我真覺得除了我們之外不會有人會去做的。

我最爽的一次體驗是在高鐵上使用 Lody，剛剛發出去指令就到了沒有訊號的地方，但因為執行側我放在伺服器上，等到有訊號，一切都完成了，並且過程結果也都立刻同步好。如果不是 Lody 我可能需要等十幾分鐘再發一次 continue。

控制端和執行端不在一側還有另外的好處就是，除了信用卡因素之外，很難觸發 Claude 封號，即使是和其他人一起共享，因為 IP 固定，機器資訊固定，cc 版本固定。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057943-iaHG4gRRebkAAFNIcjpg.jpg)

我們透過 ACP 對接了幾乎所有的 Code CLI，意味著你可以在一處同時使用和管理所有的模型。即使都是最好的模型，但是不同家的還是有不同的側重點。即使是 GPT-5.5 前端設計的能力也還是打不過 Opus。在 Lody 中這種互動就變得非常簡單，點一下 tab 選另一個模型繼續工作。一個是什麼模型強我們用什麼，所以對話會經常性地分散在各個應用或者 CLI 裡。

另外一點，現在程式碼對於純 vibe coding 來講和編譯之後的產物沒什麼區別了，這些對話才是真的原始程式碼，而且是可以互動的原始程式碼。我們團隊中互相問某個功能怎麼做的、怎麼修復的，就直接發一個 Lody 的連結自己去看。背景是什麼、怎麼修復的、細節是什麼都在了。

雖然大家都在 vibe coding，但專業的開發者和純 vibe coding 的朋友對結果的要求還是不一樣的。很多人還是需要一種掌控感，我需要知道 AI 修改了哪些，每輪對話都可以查看 diff。GitHub 整合 PR 查看 CI 資訊。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057347-iaHG4gUAwbgAAF8mjjpg.jpg)

Lody 之後要解決什麼問題。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057419-iaHG4gWlWagAAe6Yjjpg.jpg)

我們之後計畫去探索團隊中如何更加 AI Native 開發軟體的問題。不僅僅包括 coding，而是完整流程。也就是面向現在人和 Agent 互動的兩個問題，一個是 context 怎麼給到 Agent，另一個是 Agent 效率變高超過人類的頻寬之後怎麼更進一步掌控的問題。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057412-iaHG4gZeda4AArwgFjpg.jpg)

一開始想做 Lody 的時候除了要解決我們當下使用 Code CLI 時存在的問題之外，我們就已經錨定遠期的目標是希望軟體開發的完整流程都可以在 Lody 中解決。Lody 會成為 AI Native 的軟體開發團隊的 workspace。從立項開始，PRD 的編寫、技術調研、市場調研、設計稿，到開發實現都可以囊括在內。因為 coding Agent 就是通用 Agent。Lody 的角色就會是團隊的 context 同步層。

現在的開發團隊面臨一個很現實的問題：程式碼在 Git 裡，但真正的上下文散落在各處。Notion 文件、Figma 的設計、Slack 的討論、Linear 的 issue、PR 的 review comments、還有各種和 AI 對話的內容。其他崗位我還不夠熟悉，就拿寫程式碼這個場景舉例。

當一個新人接手某個模組，或者你三個月後回來看自己寫的程式碼，經常需要花大量時間重建上下文——當時為什麼這麼做？考慮了哪些方案？有什麼坑？或者是人類不再看程式碼，但你有沒有遇到過開發和之前功能相關的部分時候，AI 會把已有的能力搞亂，或者經常發現已經出現過的問題經常又再次神奇地出現。這種時候往往是 AI 由於缺少足夠的上下文進入了局部最優，從而錯誤地理解之前的程式碼。

Lody 的方向是把這些對話、決策過程、迭代歷史都結構化地保存下來，並且和程式碼關聯起來，這些都會變成可以被搜尋、被複用、被繼承的知識。當你開一個新對話，AI 要修改相關的程式碼時，會自動地關聯到已有的歷史對話。

依托於我們使用 Loro CRDTs 作為底層的資料層，這些所有的 context 資料不僅僅是結構化的資料，還天然地能夠帶有版本控制、離線優先。並且這些我們將會以最開放的資料形式，例如文件，這種本地優先的形式保存到使用者的本地。這相當於我們提供了面向 context 結構化資料的 git，團隊中的成員可以查詢到所有的歷史記錄，可以回滾到之前的任意一個版本，可以並行地進行工作，一切都會被優雅地合併。不用擔心供應商鎖定，你的資料永遠是屬於你自己的。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057424-iaHG4gcD1aoAAwqjgjpg.jpg)

另外還有一個我們正在設計的能力，multi agent。

不同於 Claude Code Codex 的 sub agent 或者 agent team。因為它們的基礎模型是一樣的，今年 1 月亞馬遜發表過一篇論文 《Rethinking the Value of Multi-Agent Workflow》，他們實驗下來認為同質的 (homogeneous) 模型進行角色分工來完成任務，本質上和單個模型串行地依次完成任務的效果差別不大。反而吃不到 cache 讓成本更高（雖然感覺論文的資料不夠 solid）。對於複雜的任務有一定的提升，認為提升來自的是拆分的 workflow 每個 Agent 避免了上下文腐敗，而不是因為 multi agent 本身。但 Lody 是一個中立的平台，可以使用各類模型，使用異構的 multi agent 將任務拆分給最擅長這種任務的模型。比如 Claude 擅長 UI，Codex 擅長邏輯程式碼，小任務給國內的便宜模型。

除了效能效果會有提升之外，想去做 multi agent 對我更有影響的是 Tibo 的一個推文。Codex 的負責人 Tibo 在 X 上表示 Codex 在未來一年內任務完成的時間將會縮短一個數量級。

如果是真的，我也很相信這會是真的，我們就先假設這是模型和算力的基礎能力進步帶來的。那麼我們現在一個基礎任務會跑半個小時，其中測試之類的可能幾分鐘，那麼縮短十倍的話，一個功能就會在五六分鐘被完成，甚至把測試也跑完了。當前的所有互動模式就都不再適用了。時間是有限的，人們對於利用壓榨時間的慾望是無限的。

如果 token 也變得便宜，你不可能想想像現在一樣，發出去幾個任務，挨個收菜的時候，慢慢測試，反正一個也得跑個幾十分鐘。一年後就變成你剛測試完一個，十個任務已經跑完了。所以把所有能夠條件約束、能夠被自動化驗證的環節都交給 Agent 會是必然的。也就是某種 multi agent 的形式。當前還是一個剛剛開始探索的領域，我們的構想是之後 harness 會更加完善，現在無法測試、驗收標準不明晰的任務也將變得透過更加智慧的 AI 從而可控可測。那麼我們只需要透過和一個比如 Lody Agent 表達你的意圖，它來理解你的意圖，分析任務方向和難度，分配給擅長的合適對應子 Agent。 他們會互相交流，便宜的模型會向最強的模型請求幫助，配合著把完整的週期自動化地走完。

當下看可能會覺得怎麼可能，至少測試沒有辦法交給 AI，但 AI 真的是隨著能力的增強，逐步竊取你的信任感，現在我們變得拋棄查看程式碼，之後就會拋棄手動測試，甚至 AI 變成了主動式地 push 你。我們只對最終產物做審查。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306057324-iaHG4gru4bYAA2JVzjpg.jpg)

總結一下，Lody 和所有做 AI Agent 的目標大差不差，擁有 context 的前提下，你就擁有了最懂你們團隊的 Agent Leader。

這個 Leader 知道你 workspace 的全部事情：哪些功能在開發、哪些 bug 在修復、哪些任務卡住了。它可以建立新的對話，把任務分配給專門的 coding Agent，需要 review 的時候叫 review Agent，需要搜尋的時候派 search Agent。它理解每個 Agent 的能力邊界，知道什麼任務該分配給誰。更重要的是，它理解你的工作習慣和優先級。知道你更關注效能還是可維護性，知道你們團隊的規範，它就是 workspace 最高效可靠的助手。

但我們的差異將會是在 Context 上，試想一下以本地優先的方式管理你所有的資料。所有的 context 都是無縫地在你多個設備之間，你和團隊成員之間同步的，並且這個同步是 End to End (端到端) 加密的，自帶版本管理的，不會產生衝突的。我們將會以最開放的管理所有的 context，所以你不需要擔心資料遺失、資料洩漏，或者是供應商鎖定的問題。

> 我相信所有人並不是不在意資料安全和隱私的，只不過之前沒有更好的選擇而已。我們希望透過 Lody，能夠讓每個人都能隨時隨地指揮自己的 Agent 團隊，享受 AI 帶來的效率提升，同時又不失對資料的控制權和安全感。

謝謝大家！

## 標籤

Agent, 教學資源, 活動發佈, Lody