OzBrain 开源:Agent 与团队共享知识库,跨 Agent 协作的真实工程新样本

项目作者 社区讨论中开头直接给出他的 vision——"I think agent-first chat interfaces will be a primary software modality and busy dashboard/UI will go away."agent-first 范式会成为主流,busy dashboard / UI 会消失。这条判断比 typical HN 帖要激

项目作者 社区讨论中开头直接给出他的 vision——"I think agent-first chat interfaces will be a primary software modality and busy dashboard/UI will go away."agent-first 范式会成为主流,busy dashboard / UI 会消失。这条判断比 typical HN 帖要激进得多,但背后的逻辑成立——如果 agent 是 primary user,所有为人设计的 dashboard / UI / notes 工具就失去意义,真正需要的是"agent 协同的 knowledge base"。 具体痛点他自己已经撞过——他在 build 一个 Voice AI for older people 时,要 passing .md files around、keep track of which version 是 most recent、coordinate agents writing to shared docs,这套流程"pain in the ass"。最后他 build OzBrain 来 solve 这个问题——hosted markdown storage right in Supabase,所有 agent 都有 Supabase access,可以 read、write、update、refer knowledge as they build and improve。 75 founder friends 的调查结果揭示了这个痛点普遍到什么程度——26/75 自建(都是各种 Frankenstein)、32/75 痛但没解、剩下的可能是用 Notion / Confluence / Google Docs 这类为人类设计的工具凑合。Frankenstein 生态的核心问题是维护成本——创始人要花大量时间维护自己的 Obsidian vault、markdown repo、cron job stitching,而这些维护工作本身不产生业务价值。OzBrain 把维护成本降到零,所有 knowledge management 由 OzBrain 平台负责,用户只需要 read、write、update。

二、OzBrain 的核心功能

OzBrain 的功能设计直接对应企业 Agent 落地的几个关键需求。

• 第一条,create a central place for agent reasoned knowledge to live。Knowledge 不是分散在每个 agent 的 memory 或 prompt 里,而是集中存储在一个 shared corpus。这意味着 cross-agent 协作时,任何一个 agent 学到的东西都能立即被其他 agent 看到。

• 第二条,be agnostic about what apps / agents connect to it。OzBrain 通过 standard API / MCP 接入,任何 coding agent 都能用,不绑死在某个 vendor。这是 enterprise 多 vendor 环境的关键要求——Anthropic / OpenAI / Google 的 coding agent 应该都能 share 同一份 knowledge corpus。

• 第三条,capture everything and track it so I can audit it。每一条 read / write / update 都进 audit log,user 能看到"哪个 agent 在什么时候写了什么"。这条 capability 对企业 IT 合规至关重要——任何对 knowledge corpus 的修改都要可追溯。

• 第四条,enable teams, collaborators or partners to share brains。多人多 agent 共享同一份 brain,不是单 agent 单 user 的私有笔记。这是 multi-agent enterprise 协作的关键基础设施。

• 第五条,handle conflicts so many agents in the same article doesn't blow up。多个 agent 同时写同一篇文章时,OzBrain 必须 handle conflict resolution,不能简单地 last-write-wins。这条 capability 直接对应 TradingAgents 的 decision-log memory 设计——version control 是 shared knowledge 的基础设施。

• 第六条,refactor knowledge into more token friendly chunks and map the index well。Shared knowledge corpus 可能很大,agent 调用时不能 dump 整个 corpus——必须 chunk + index,让 agent 按需 retrieve。这条 capability 对应 Decispher 的 Context Engine 设计——verified data-access contract 加上 chunked indexing。

• 第七条,close the knowledge loop so new thinking supersedes old thinking across the corpus。Don't erase, depreciate and link。新知识不能直接覆盖旧知识,要 depreciate + link,这样 audit trail 完整。这条 capability 对应 Warp 的 self-improving skill——skill 文件演化是 explicit + reviewable + mergeable 的,不是 silent overwrite。

• 第八条,keep user data safe and secure。Knowledge corpus 是企业最敏感的资产之一,security 是基础设施级要求。

• 第九条,be easy enough to use that you don't have to have any technical knowledge。OzBrain 自己宣称对非技术用户友好,这与同类工具的差别是 Vercel vs AWS——OzBrain 像 Vercel,同类工具像 AWS,OzBrain 处理 easy-to-use trade-off,同类工具给 power + flexibility 但要求技术投入。

三、OzBrain 反映的企业 Agent 知识共享现实

把 OzBrain 跟同期几个独立产品放在一起,可以看到 Agent shared knowledge 正在从"开发者 DIY"过渡到"标准化基础设施"。

跨 session 学习是 Decispher 给的样本——LongMemEval 89% accuracy on oracle split +38x token reduction。Decispher 解决 single agent 跨 session memory。

跨 agent 共享是 OzBrain 给的样本——shared corpus across agents and team。OzBrain 解决 multi-agent + multi-user shared knowledge。

跨 vendor 共享是 Warp self-improving skill 间接给出的样本——Warp 用的 Claude Platform 是 vendor-specific,但 skill 文件作为 cross-vendor standard 是更通用的设计。Skill 是 procedural and stable,跨 vendor 都适用。

跨组织共享是 Bubs.co 类产品的方向——OzBrain 提到 enable teams, collaborators or partners to share brains,意味着知识 corpus 可以跨组织边界,合作方也能看到部分 shared knowledge。

四个层次的共享能力合起来形成 Agent shared knowledge 的完整工程基线。OzBrain 在 cross-agent + cross-team 这层提供 immediate solution,其他三层要么靠 OzBrain 扩展实现,要么靠其他产品补充。

四、企业 Agent 共享知识库的具体落地 checklist

把 OzBrain + Decispher + Warp + TradingAgents 四件套合起来,企业 Agent 共享知识库的设计应该满足如下 checklist。

• 第一条,knowledge corpus 必须中央化。不能在每个 agent 内部存储 knowledge,所有 agent 必须读写 shared corpus。Centralization 是 cross-agent + cross-session + cross-team 的基础。

• 第二条,knowledge corpus 必须 vendor-agnostic。通过 standard API / MCP / SQL 接入,不能绑死在某个 vendor。Vendor lock-in 是 enterprise 多 vendor 环境的最大障碍。

• 第三条,knowledge 必须 token-friendly chunked。Large corpus 必须 chunk + index,agent 按需 retrieve,而不是 dump 整个 corpus。这条对应 Decispher 的 Context Engine 设计。

• 第四条,knowledge 必须 audit-tracked。每一次 read / write / update 进 audit log,user 能看到"哪个 agent 在什么时候写了什么"。Audit trail 是合规的最低要求。

• 第五条,knowledge 必须 conflict-resolved。多 agent 写同一篇文章时必须有 explicit conflict resolution 策略,不能 silently overwrite。Conflict resolution 对应 TradingAgents 的 version-aware decision-log memory。

• 第六条,knowledge 必须 depreciate-not-overwrite。新思考 supersede 旧思考时,旧知识 depreciate 而不是 erase,link 起来。Depreciation 让 audit trail 完整,跟 Warp skill 的 explicit review + merge 一致。

• 第七条,knowledge 必须 secure。Corpus 是企业最敏感资产,encryption at rest / in transit + access control + audit log 是必备。

• 第八条,knowledge 必须 easy-to-use。Power + flexibility 是次要,first-time-success 才是关键。OzBrain 走 Vercel-like 路线,同类工具走 AWS-like 路线,企业落地应该选 first-time-success 高的产品。

• 第九条,knowledge 必须 agent-agnostic。任何 agent framework 都能接,不能只支持一个 vendor。Anthropic / OpenAI / Google / open-source 都应该 native 支持。

• 第十条,knowledge 必须 customizable schema。不同业务需要不同的 knowledge 类型,schema 不能 hardcode——entity / project / decision / learning 都是常见类型。

五、OzBrain 与 self-improving skill 的设计哲学对照

OzBrain 的 close-the-loop 设计("new thinking supersedes old thinking across the corpus")和 Warp 的 self-improving skill 设计("skills are plain files, agents are extremely good at updating them, these updates flow through a normal PR/code-review workflow")看起来很相似,但核心机制不同。

OzBrain 的 loop 是 agent 在 knowledge corpus 里写新内容,旧内容 depreciate + link,audit trail 完整。整个 loop 发生在 knowledge corpus 内,Warp 的 loop 是 skill 文件改动走 PR/code-review,发生在 code repo 内。

两条 loop 路径都解决了 Agent 跨 session / 跨 agent 持续学习的问题,但 OzBrain 更适合"知识管理"场景,Warp 更适合"工作流程自动化"场景。两者可以并存——企业用 Warp self-improving skill 做工程 workflow,OzBrain 做 cross-team 知识共享。

六、Agent-first 范式的真实挑战

OzBrain 反映的 agent-first 范式确实是 future 方向,但落地有几个关键挑战。

• 第一个挑战是 trust。Knowledge corpus 是企业的 collective intelligence,任何 leak 都可能造成 competitive damage。OzBrain 必须 end-to-end encrypt + zero-knowledge proof 才能让 enterprise trust。

• 第二个挑战是 quality control。Knowledge corpus 里的内容质量必须经过某种 review 机制,不能因为 agent 自动写入就让低质量内容沉淀。Warp 的 PR/code-review 流程是 explicit quality gate,OzBrain 的 close-the-loop 设计没有显式 quality gate,只有 audit trail。

• 第三个挑战是 discoverability。Knowledge corpus 越大,agent 越难找到 relevant information。Indexing / semantic search 是 must-have,Decispher 的 Context Engine + Vector DB + BM25 hybrid retrieval 是基线。

• 第四个挑战是版本管理。Knowledge 在 evolution,任何时刻 corpus 的版本必须可以 rollback 到某个时间点。Git-style version control 是基线。

• 第五个挑战是 access control。不同 agent / 不同 team member 对不同 knowledge 的 read / write 权限必须细粒度管理。RBAC (Role-Based Access Control) 是基线。

把这五个挑战答完,OzBrain 类产品才能真正在 enterprise 落地。

七、下一步:Shared Knowledge 成为 Agent 协作的入场券

把这件事放到更大的图景里看,Agent shared knowledge 正在从"开发者个人卫生"过渡到"企业 Agent 协作的入场券"。早期 Agent 部署假设每个 agent 是独立的、knowledge 不共享;后续一年内,任何严肃的企业 Agent 部署都会要求 cross-agent + cross-team + cross-session knowledge sharing,因为不共享的 agent 永远只能完成"个人任务",无法承担"团队级"工作。

OzBrain、Decispher、Warp self-improving skill、TradingAgents decision-log memory——这四个独立产品/模式,在近期几乎同时出现不是巧合,是 Agent 行业走到"shared knowledge 基础设施"阶段的明确信号。enterprise 部署 Agent 时,shared knowledge layer 会成为像 database 一样的必备组件,缺这个组件的 Agent 平台会快速被淘汰。

回到一开始的问题——OzBrain 把"agent + team 共享知识库"这件事第一次用 hosted markdown storage 形态做出来,Darius 的 75 founder friends 调查揭示了 Frankenstein 生态的真实痛点。剩下的是企业 IT 在落地时把十条 checklist + 五个挑战都答完,把 shared knowledge 从"开发者 DIY Frankenstein"升级为"标准化基础设施"。这是 2026 年下半年 Agent 行业走向成熟的标志,也是企业 AI 真正能承担团队级协同工作的入场券。