你好 👋 我是 zjding

今天讲解一下最近火热的 Jev 模型，17 号过的 waitlist，测试了一下效果，下面讲解一下。 举一个电商场景例子：客服路由只需要选一个队列，工具调用只需要选一个动作，审核分流只需要决定放行还是复核。这些任务的输出空间很小，却经常走一条很长的路径：模型生成一段文字，程序解析 JSON，最后取出一个枚举值。如果最后只消费一个选择，语言生成是否仍然是合适的计算方式？ ...

最近在看 Pi Agentharness 的 V2 版本，总结下来就是看完觉得惊为天人，直接解决了我许多的困惑和疑虑，爽翻了。 Pi 的 V2 版本为工具调用增加了持久化的执行状态、恢复策略和结果暂存，以及许多的边界真的越来越清晰了，这是让我最爱的点，边界清晰才能定义职责，职责清楚了才有优化方向。 ...

最近研究全链路自进化的视频转绘项目，我想做的事情：从原视频出发，理解剧情和人物，完成转绘与视频生成，再让系统根据结果发现问题、尝试改进。理想中，每跑一轮，下一轮应该更接近我想要的成片，但是这个过程中一个大的难点就是如何做审核？如何评估好坏，如果需要灌注人为的经验和知识进去该怎么办？流程跑完了，审核通过了，Agent 保留了一次修改，这些都容易留下记录。至于视频究竟有没有变好，我应不应该把自己的经验和注意力在这个环节灌入进去，真是该死这是最难的事情！ ...

最近我一直在找一类工具：能把 Pi、Codex、Claude Code 放到同一个地方管理。现在开几个终端当然也能工作，可一旦 Agent 分布在不同机器上，同时跑着几个 worktree，还要随时看 trace、diff 和权限请求，终端 tab 很快就会变成一排认不清的标签。 ...

最近看了一篇推，主要讲的是 PostgreSQL 执行一条 UPDATE 时，需要持久化的对象通常不止一行记录。heap page、相关索引页、事务状态和其他元数据可能一起变化；机器在写回过程中断电，磁盘就会留下部分新 page 和部分旧 page。数据库仍然要给出一个确定结果：这笔事务已经提交，或者恢复后继续把它完成。 ...

最近在做一个内容创作相关的检索模块。以小说 Agent 为例，世界观、角色卡、章节和场景记忆会随着写作持续累积，它们都需要一套能长期工作的检索基建。 第一版沿用了熟悉的 Qdrant。它足够成熟，也能满足当前需求；但我已经很久没有系统关注向量检索，因此重新检查了一遍近几年的向量数据库、压缩索引和冷热分层方案，确认继续使用 Qdrant 是当前约束下的选择，而不只是路径依赖。 ...

2026 年 6 月中旬，Movez 在 X 上那条 Kimi K2.6 swarm 的推文刷到接近一百万次浏览。标题写得很冲：《The Self-Improving Loop: a 300-agent swarm on Kimi K2.6, verified by Opus 4.8》。它讲的版本大概是：一个免费的开源模型，用单个 prompt 拉起 300 个并行 agent、跑 4000 步，在真实研究任务上超过贵它 5 倍的闭源旗舰。 ...

有人把 Claude Code 每个 npm release 跑起来、抓下它发出的 system prompt，归档成快照。到 2.1.177 为止，一共 341 个快照，最后一个采集于 2026-06-13。把它们按版本号排好，你会看到 prompt 从 1.0.0 的 53,556 字节，长到 2.1.177 的 100,394 字节——几乎翻倍。 ...

最近本体论的概念忽然冒出来了，看了下一些大厂商对这个东西的认知和技术博客，觉得和我平时 coding 的时候有些观念很相似，只不过换了种说法，并且抽象出来了，并且把之前感觉在大家口中已经埋葬了很久的知识图谱也再次挖了出来；于是有了下面这篇 blog： ...

最近看到赵纯想哥在推荐 Mastra，之前也用过，但后来在 laper 里面看到它已经被实战验证了，就想着再研究下。里面一个比较让我惊讶的就是记忆系统。我一开始把 Mastra 的 Observational Memory 当成又一版“上下文压缩”，翻完实现后感觉非常有意思。 ...