https://github.com/LodyAI/Lody
你可以将 Lody 理解为支持所有 agent 类型（ codex/claude code/kimi/grok/dsh/opencode...）的 codex app 。但有着
但我们想解决的问题不止于此。
软件系统的复杂度不只存在于代码里。一段代码可能来自某个业务规则、一次线上事故、一位重要客户的兼容要求，或者一个后来已经消失的技术限制。随着项目演进，这些决定一层层叠加，最终形成系统今天的样子。代码保留了结果，却不总能保留形成结果的理由。
这些背景分散在设计文档、PR 、Issue 、会议、Agent 对话和团队成员的记忆中。当成员接手模块、审查改动或准备重构时，困难的往往不只是读懂代码，而是重新理解它背后的业务规则、领域概念、设计取舍和历史决策。
我们希望 Lody 成为软件团队与 Coding Agent 共用的理解层：把对话、代码、任务、文档和历史决策联系起来，帮助团队追溯系统为什么成为今天这样，并判断新的改动会触及哪些既有约束。
对话只是理解项目的起点。Lody 会围绕理解发展任务管理、文档和代码审查等能力。未来，我们希望探索通过插件让用户定义适合自己团队的工具，将其中的数据与项目的其他上下文连接起来，并在团队中同步。
Lody 中的同步方式
Lody 基于 Loro Stack 构建了一套本地优先的同步引擎。大部分协作状态使用 Loro 和 Flock 表示，并通过 Loro Streams 在设备之间同步。它们基于 CRDT ，允许不同副本各自发生变化，并在重新连接后合并。
我们选择 CRDT ，首先是因为希望项目上下文是 local-first 的：设备拥有可以直接使用的本地副本，网络恢复后再同步变化。
应用可以被替换，但数据的留存应当比应用更持久。Agent 和工具会不断变化，团队积累的项目上下文不应该随之消失。开放的数据格式和实现也能降低这些上下文被困在单一应用中的风险。
Loro 的通用数据结构还可以表示评论、富文本文档以及白板等工具需要的协作状态。这让同一套同步引擎有机会承载不同的交互形式，也为未来的社区插件提供共同的数据基础。
Lody 目前还不支持端到端加密，跨设备协作仍然依赖 Lody 的托管同步服务。我们已经完成端到端加密 Workspace 的第一版设计。
我们的方向是让团队与 Agent 共同积累的项目上下文最终由团队掌控。
合作
我们正在寻找二十人以内的软件团队共同试用和完善 Lody 。如果你对团队如何理解、审查和延续 Agent 的工作感兴趣，欢迎联系我们。[email protected]
抽奖
最后将从留言的各位中随机抽取 10 位 V 友赠送价值 $30 的 3 个月的 Lody 会员，感谢大家的支持！
https://github.com/LodyAI/Lody
