本期三件事：开源项目 wuphf 用 Markdown + Git 给多 Agent 搭了一个"共享办公室"，发布几周拿了 769 颗 star；Aparna Dhinakaran 拆开了 5 个主流 Agent 框架的上下文管理设计，给出"内存层级"的演进图谱；Apache Fluss 配 Roaring Bitmap 把实时用户画像的延迟从小时压到秒。一个共同的趋势——Agent 落地的下一道关，不在模型，在 Agent 之间的"协作基建"。
前几期我们聊过 Agent 要做小、做小之后怎么稳定跑生产、再之后怎么把账算清楚。这一周看到的几条主线，开始往更细的地方走——多个 Agent 之间怎么协作？它们的"共享记忆"应该长什么样？上下文管理有哪些已知的最佳实践？实时画像这种状态密集型任务怎么提效？
下面是本期的主要内容。
行业动态
wuphf：用 Markdown + Git 给多 Agent 搭一个"共享办公室"
发布几周时间，wuphf 在 GitHub 上拿了 769 颗 star——这个项目想解决一个具体问题：多个 AI Agent（Claude / Codex / OpenClaw 等）跑在各自的 API 后面，互相不知道对方在做什么，重复劳动、上下文丢失、协作不可见。
wuphf 的解法是搭一个"共享办公室"——所有 Agent 读写同一个结构化知识库。知识库后端可选三种：
- Markdown + 本地 Git 仓库（默认）——简单、可审查、可 diff
- Nex（知识图谱）——结构化关系
- GBrain（带向量搜索 + Embedding）——语义检索
更值得说的是默认选了 Markdown + Git 这件事。这和我们 第 2 周周刊 讲过的"Markdown 干翻 5000 万美元的向量库"是同一种工程美学——很多场景里，最朴素的存储 + 最朴素的索引就够用，向量库是过度工程。
项目：github.com/nex-crm/wuphf（769 stars · Go 73% / TypeScript 17%）
Aparna Dhinakaran：5 个主流 Agent 框架的上下文管理对比
Arize 联合创始人 Aparna Dhinakaran 在 X 上发了一份对比——她拆开了 5 个主流 Agent 框架（OpenAI Assistants、LangGraph、Anthropic Computer Use、CrewAI、AutoGen）的上下文管理设计，给出一个共同演进方向：从"全量历史塞 prompt"到"分层记忆"。
她的归纳是这样的"内存层级"：
- 短时记忆（recent turns）——最近几轮对话，全量保留
- 工作记忆（episodic）——当前任务相关的中期状态
- 长期记忆（semantic）——需要持久化的事实知识，向量检索召回
- 元记忆（meta）——Agent 对自己历史决策的索引
这套分层和上一期 Slack 的 Director's Journal 异曲同工——主流 Agent 框架在悄悄收敛到同一种设计。如果你正在搭多 Agent 系统，这是值得参考的"标准件"。
原文：Context Management in Agent Harnesses · Aparna Dhinakaran @ Arize
Apache Fluss + Roaring Bitmap：实时用户画像的"秒级"方案
Giannis Polyzos 在他的 Substack 上写了一份实战复盘——用新晋开源项目 Apache Fluss（实时存储引擎）配上 Roaring Bitmap 编码做用户画像，延迟从小时级压到秒级。
技术细节简单说：
- Apache Fluss 是个为实时分析设计的存储引擎，比 Kafka + 流式数据湖的组合更直接面向"实时画像"这种状态密集型任务
- Roaring Bitmap 是高效的稀疏布尔编码——表示"用户 X 是否属于群组 Y"这种事，比传统集合压缩百倍
组合起来的效果是——千万级用户的"实时多维标签"可以在秒级响应。这是过去需要专门画像系统才能做到的事，现在用开源组件能搭出来。
原文：From Events To Real-Time Profiles On Apache Fluss · Giannis Polyzos
观点看点
Just Eat：多层数据治理的"组合拳"
英国外卖平台 Just Eat 的工程团队写了一份治理实战——他们没用任何"银弹"，而是搭了一个多层组合：
- 业务词典（business glossary）——口径定义
- 数据目录（catalog）——元数据 + 血缘
- 质量信号（quality signals）——自动监测异常
- 语义层（semantic layer）——用户访问的统一接口
他们把这套叫做 "Daedalus" ——希腊神话里建造迷宫的工匠。意思很形象——数据治理不是给迷宫画地图，是搭一组导航工具，让每一类用户都能找到自己要走的路。
这种"工具组合"思路对国内大公司有借鉴价值。国内数据治理常见的失败模式是想搞一个"全能平台"——结果什么都做、什么都做不深。Just Eat 这种"小而专"的工具集思路更可持续。
原文：Daedalus and the Data Labyrinth · Just Eat Takeaway
拾穗解读：Agent 协作的"基建配方"正在收敛
把本期几条放一起看，可以看到一个有意思的趋势——多 Agent 协作的"基建配方"，正在悄悄收敛到几个共同模式。
第 3 周周刊讲的 Slack Director's Journal、第 4 周周刊讲的 Monzo 数据契约、本期讲的 wuphf 共享办公室和 Aparna 总结的"内存层级"——这些项目互相不一定知道对方在做什么，但走出的路径惊人地相似：
- 都意识到"全量历史塞 prompt"不可持续
- 都在做某种"分层记忆 / 共享记忆"
- 都把"上下文该剪掉什么"当一等公民
- 都用"显式契约"代替"隐式约定"
这种多个独立项目自发收敛的现象，往往是一个领域在变成基础设施的信号。就像 5 年前各家数据团队都在自发收敛到 "湖仓一体" 一样。当大家都在解同一个问题、解法又长得很像的时候，意味着这个领域的"标准件"快定型了。
对数据从业者个人来说，这意味着两件具体的事——
第一，"Agent 协作基建"是接下来 12 个月最值得追的方向之一。它不像 RAG 那样卷得已经红海，但又不像更深的研究方向那样和你日常工作距离遥远。正好处于"标准化进行中"的窗口期——早入场的人能享受到设计标准的话语权。
第二，多 Agent 系统的设计能力，会变成新的稀缺技能。不是会调 LangGraph、不是会写 Agent prompt，而是能从架构层面回答：
- 我的 Agent 们应该怎么共享状态？
- 哪些信息该共享、哪些该隔离？
- 上下文剪枝的策略是什么？
- 长期记忆该用什么后端、什么时候召回？
这些问题没有教程，是我们 上周写的"会用模型 5 种能力" 在多 Agent 场景的延伸。
Apache Fluss 那条其实想表达的是另一个旧话题的新版本——实时分析这件事，工具又便宜又好用了。10 年前实时画像是大公司的奢侈品，5 年前是中等公司的难题，今天用开源组件 + 几个工程师能在两周搭出来。国内做用户运营 / 风控 / 营销自动化的团队应该看一眼——你们花在传统画像系统上的钱，可能多花了一个数量级。
最后是 wuphf 给我的一个细节启发——"默认 Markdown + Git"这个选择很有意思。它不是一个技术决定，是个哲学决定——承认大多数 Agent 协作场景的复杂度，没有高到需要图数据库。这种"务实的简朴"，是这一行最稀缺的产品判断。
如果让我给这一期做一句话的收束：Agent 协作的基建已经在收敛，越早学会用"共享记忆 + 显式契约"的人，越早能从"调 prompt"进化到"搭系统"。
说到这里我自己一直在琢磨——如果让我从零搭一个生产级的多 Agent 系统，工程清单上的前 10 件事是什么？ 这是我最近在梳理的下一个题目，有想法的朋友可以加我微信（shisuidata）一起聊。
本周其他值得看的
- Mistral Medium 3.5：法国 Mistral 发布 Medium 3.5，主打远程 Agent 场景。和 DeepSeek V4 一起，本周开源 + 开放权重模型市场再次热闹
- Doing More With Less: Entity-Level Sentiment at Scale：Meltwater 用单次 Transformer 前向传递提取多实体嵌入，推理成本降 45.5%
- Airflow DAG Bundles: Managing DAGs Without Helm Upgrades：S3 后台同步实现 DAG 热重载，30 秒内完成新管道部署
- A Benchmark for Deterministic LLM Outputs：Interfaze 推出新基准，专门测 LLM 在结构化输出场景的确定性——和我们前几天讲的 Eval 设计 互相呼应
我叫石头，在数据行业里摸爬滚打了十几年，这一轮 AI，我也是边看边想。这里写的，就是这些观察——我觉得值得说出来的那部分。
数据来源：
- Data Engineering Weekly #267（部分素材来源）
- 各项目原文链接（见正文）
- HN 本周高分帖单（4/27-4/30）
《数据周刊》每周更新一期，挑数据行业值得看的动态，附拾穗的判断。拾穗数据｜https://ss-data.cc