leo_lou

[琦玉老师 @KakaluoteW45042]

最有共鸣的一点：agent loop 本身真不难，几百行就能跑通。难的从来是 harness——上下文怎么裁、工具权限怎么管、挂了怎么恢复。所以选框架其实是选边界：模型/工具接口交给 Pydantic AI，脏活兜底自己写。挺务实的取舍。

[leo_lou @lo_oo_ool]

@mylifcc 你在搞笑吧 一个人几个月？

[Jackywine @Jackywine]

目前看过最好的 AI 味道去除的 skills

[琦玉老师 @KakaluoteW45042]

Agent 圈的 benchmark 过拟合比想象中严重：任务集一公开，大家就对着 eval 修 prompt、堆 tool，分数涨了但真实任务没变好。给自我改进过程加正则化这个方向我认可，不过最终还是要靠不公开的 holdout 任务集说话 🧪

[leo_lou @lo_oo_ool]

@realfxw 花里胡哨的 没啥卵用

[KonghaYao - 江夏尧 @konghayao]

分享一下我们的 AGNETS.md 里面的核心工程原则，这个工程原则极大提高了 LLM 在我们项目中的稳定性，在10w 行级别的大重构中发挥了优秀的作用。

[响马 @xicilion]

这三条也在我的 AGENTS.md 里。我还有第四条，开发期间不要运行全套 e2e，要在结束的时候再执行。
否则它改个标点符号要测试一个多小时。😂

[Matthew Lam @mattlam_]

Harness Learning #5: Prompt Caching

Prompt caching is one of the most important concepts to understand in LLM use and cost impact. Providers like Anthropic and OpenAI saves the prefix, start of your request, in a KV cache so that if your next request starts with the exact same tokens, the provider can load the cache value to reduce computation and cost.

This also relates to the new ability of changing your conversation reasoning level without destroying cache!

A request is basically generated in the order of: tools -> system -> messages (user, assistant, reasoning, tool call and results). A cache hit needs the byte identical prefix between requests, where changing a token means the request needs recomputation, especially if changing earlier on in the message:
- edit a tool defintion -> miss
- edit system prompt -> system + all messages miss
- change tool_choice -> all messages miss

Each provider also has their own specific ways to handle prompt caching for requests -->

[leo_lou @lo_oo_ool]

@oran_ge 泡不泡沫不知道 fb这种擅长用户交互 要是能改变用户心智 也不失为一种新的盈利模式 虽然技术上没啥亮点

[leo_lou @lo_oo_ool]

@ZixuanLi_ 此地无银三百两 彻底信用破产

[Amit Shekhar @amitiitbhu]

AI Engineer Roadmap - A step-by-step AI Engineering roadmap to become an AI Engineer, with a blog for every topic.

Start here: https://t.co/cJY2hNiSMj

[meng shao @shao__meng]

https://t.co/eSvLP5MAHa

[leo_lou @lo_oo_ool]

@chengyongru 都不是什么大事 就是有时候费token https://t.co/ztw4WaT0FH

[meng shao @shao__meng]

腾讯团队开源发布会"预演"的记忆系统「T-Mem」

当前四代长期记忆架构：Flat RAG、图结构记忆（GraphRAG、Zep、HyperMem）、agentic 层级记忆（Mem0、A-Mem、MemoryBank）、操作系统式记忆内核（MemGPT、MemOS、MIRIX），虽然结构各异，但检索配方却完全相同：把查询和存储内容投进同一个相似度空间（BM25 或稠密向量），取 top-K。这决定了一件事：记忆的"可达性"被相似度封顶。

论文：https://t.co/Un2f8yFr2r
开源项目：https://t.co/0oItT1QCT9

# 现在的问题是什么？

现有记忆架构的检索配方只覆盖一半情形。当查询与记忆共享表面特征时（同样的措辞、同一个实体、同一个时间地点）它工作良好，这就是描述性召回。但长对话里还有同样常见的另一半：查询与记忆零表面重合，绑定二者的只有一条潜在的语义弧，比如因果关系、同一情境的延续。这是联想性召回。比如：一个月前用户说过"团队里有人严重海鲜过敏"，今天问"今晚团队去哪儿吃饭"，两句话没有任何词汇重合，前者却恰恰是后者的必答依据。长对话中的用户极少用原措辞重提旧话题，而借新情境的间接线索回访记忆；表面形式已经漂远的目标，永远无法从同一个相似度邻域里到达。

把"粒度"（单条事实 / 完整对话段）和"取向"（描述性 / 联想性）作为两个正交轴，就得到 2×2 检索设计空间。论文指出，现有系统全部挤在第一、第四象限（描述性的一半），第二、第三象限，联想性的一半，是这套检索配方的结构性盲区。也是腾讯这篇论文的基础。

# 核心思想：把"预演"放在写入时

T-Mem 的答案借自认知科学。人在回忆过去时，会为未来的线索预演经验，这叫"情景未来思维"。它的工程对应物就是 trigger：写入记忆时，由构建用的大模型离线算好并随宿主存放的一条预测，"这条记忆会在什么情境下重新变得重要"。

trigger 的架构意义在于解耦了两件事：一条记忆"如何被到达"和"什么算答案证据"。当相似度找不到宿主时，查询仍可以经由宿主的某条 trigger 命中它。每条记忆因此同时保有描述性入口和联想性入口。四个 trigger 家族各占设计空间的一个象限：
· Entity Trigger（第一象限，事实×描述）：给原子事实一个上位概念名。"海鲜过敏"的实体触发器可能落在"饮食限制"上。
· Bridge Trigger（第二象限，事实×联想）：把事实投射到一个"知道它就会有用"的具体情境，并附一步推理的理由。过敏事实投射到"为团队晚餐选餐厅"。这是纯联想轴，相似度检索完全无法覆盖。
· Scene Trigger（第四象限，场景×描述）：从情境、对象、事件、情绪四个正交属性各用一句话描述当前场景。
· Horizon Trigger（第三象限，场景×联想）：把同一场景投射到一组前瞻维度，让未来的查询从相关但不同的情境接近时仍能命中它。

其中 Entity 和 Scene 服务的是相似度检索已经覆盖的那一半，Bridge 和 Horizon 才是填补盲区的两族。

# 结构与流程

记忆被组织成五类对象的类型化图：scene（按事件闭合切分的连贯对话段，作为证据）、item（从 scene 抽取的原子事实，可锚定到多个源 scene 以承载跨场景的逻辑链）、topic 标签（只用于限定抽取范围和检索预过滤，明确不进入问答通道）、四族 trigger（只参与检索，永不出现在证据里），以及按说话人聚合的 persona（作为环境上下文附在证据之后，不占用检索预算）。三条设计承诺：证据层按类型隔离、topic 不污染问答、trigger 不进入证据路径。

构建是四阶段离线流水线，顺序承重：按事件闭合（而非会话边界，会话边界是数据采集的副产品，一个会话可含多个事件、一个事件可跨多个会话）切分 scene；按到达顺序做 topic 归组，一个 scene 可加入多个 topic；每个 topic 一次抽取，同时产出原子 item 和跨场景连接 item；最后逐节点生成 trigger，Entity 与 Bridge 在同一次模型调用中产出。

检索是自上而下的 topic→scene→item 三级瀑布，每层用 RRF 融合词法与稠密排序。最关键的一处工程细节是：经由任一 trigger 到达的 scene 和 item 不受 topic 预过滤的闸门约束。预过滤本质是基于相似度的邻域测试，而 Bridge 和 Horizon 恰恰是为邻域之外的线索设计的；让它们过闸，等于把 T-Mem 自己要对抗的相似度体制重新加回来。item 级 trigger 召回另带 0.85 的硬余弦阈值。trigger 索引采用多视图编码：每个 item 暴露纯概念、纯桥接、联合（概念∥桥接∥理由）三个视图，取跨视图的最大余弦分并归属到宿主。整套检索在 CPU 上即可完成，单台无 GPU 工作站可复现全部评测。

# 实验结果

LoCoMo 官方协议下，T-Mem 总准确率 80.26%，超最强基线 HyperMem（官方协议复跑值 77.01%）3.25 个点，token F1 51.96 同向；分题型为单跳 85.97、多跳 69.15、时间 82.55、开放域 55.21，其中开放域以 0.69 点惜败 MemOS，是唯一未拿第一的题型。

真正的分水岭在 LoCoMo-Plus 的 Cognitive 子集（专门剥离词汇重合、探测纯联想召回的题目）：T-Mem 74.81%，HyperMem 48.63%，MemOS 32.67%，GPT-4o 直接读完整对话原文零样本也只有 21.05%，Gemini-2.5-Pro 为 26.06%。跨基准落差方面，T-Mem 只掉 5.45 个点，其余系统掉 28.38 到 50.07 个点；连 GPT-4o 吃下全部原文也掉 45 个点，说明骨干模型的规模救不了联想轴的断裂。作者自己划的重点是：跨基准落差而非单榜绝对分才是这项工作的 headline。

消融实验是全文最有信息量的部分，且信息不在总分而在两列的不对称。描述轴组件（scene 层、item 通道、Entity+Bridge、persona、topic 过滤）在 LoCoMo 上各值 1.4 到 4.7 个点，在 LoCoMo-Plus 上却只值 0.25 到 2.99 个点；联想轴组件完全反过来，去掉 Horizon Trigger，LoCoMo 只动 0.08 个点，LoCoMo-Plus 塌 12.47 个点，两个场景级 trigger 一起去掉塌 22.19 个点，是任一描述轴开关影响力的七倍以上。这条不对称本身就是论证：只按相似度基准调优的系统，隐含地就在优化"待在相似度邻域之内"，而邻域之外的成本，这类基准在构造上就测不到。

效率上，构建是一次性离线成本：10 段 LoCoMo 对话共 9,689 次构建模型调用、15.60M token，高于 Mem0 的 12.20M，作者把增量明确归给 Bridge 和 Horizon 两族联想 trigger，称之为扩展联想轴的价格。答题时的 token 预算低于 HyperMem 的同时两个基准都更准；低 token 阵营（Mem0、Zep、MemOS）在 LoCoMo-Plus 上直接崩盘。

[青稞社区 @qingke_ai]

这篇笔记详细的介绍了DeepSeek-V4.1-Flash 背后的跨层 KV 共享：YOCO，以及相关的变种架构

1、YOCO 本身的架构非常简单易懂：把标准 decoder-only Transformer 拆成上下两部分。

- 前半部分是 Self-Decoder。
- 后半部分是 Cross-Decoder。

Prefill 阶段则完全不需要跑后面的 Cross-Decoder（这在现在的 agent 场景的超长输入中，确实是太实用了）。

2、YOCO-U：对前面的 Self-Decoder loop 三次后产生一份 Shared KV；在 Cross-Decoder 上的改动则是采用了 NOPE。

3、YOCO-Sparse：共享 Sparse Attention 的 Routing Index，省中省！

4、DeepSeek-V4.1-Flash：Attention 大致为 YOCO/CED + CSA2 + SWA。

- YOCO/CED：减少 Prefill 计算
- CSA2：跨层复用 Global KV 与 Top-K
- SWA：短期缓存与局部重建

5、Gemma 4 E2B / E4B 也用了类似 YOCO 的技术。后半段很多层不再计算自己的 K/V，只保留独立的 Q，并复用前面最后一个同类型 Attention 层的 KV。

6、WeLM 也做了类似 YOCO 的操作 KV-Mirror，但是本质目的不是为了节省 KV Cache，而是为了节省 Prefill 的计算。

链接：https://t.co/mEj5Isb921

[南晚Nanwan @snwiki238337]

深度学习核心路线：

Transformer：Attention / QKV / Multi-Head / FFN / LayerNorm / 残差

CNN / RNN 脉络（理解即可，不是主线）

训练技巧：warmup / 学习率调度 / 梯度裁剪

从零实现 mini Transformer（参考 nanoGPT），训练字符级语言模型并生成文本

验收：手写 attention 讲清 QKV；训出能生成文本的小模型

[leo_lou @lo_oo_ool]

@hermescn_org 本来花里胡哨搞这么多鸡肋功能 提交pr也不看 几个创始人在那自high

[AIGCLINK @aigclink]

MCP把skill正式收编！
Skills扩展正式合入官方仓库，SEP-2640，9/13 Final

以前Agent拿到工具只能自己摸索，现在服务器直接附带操作手册，官方统一了分发与校验机制

连接即获得，不用单独装

以前各家skill格式碎片化，要单独适配，现在一次封装多端可用

另外，Agent不必上来就加载所有内容，先发现有哪些Skill，需要哪个再从MCP加载

#MCP

https://t.co/ZJexpwMiqC

[leo_lou @lo_oo_ool]

@TiagerBao 本来pi就很排斥这种subagent 非要加

[meng shao @shao__meng]

Jina AI @JinaAI_ 基于 DeepSeek-OCR 微调了 3.4B/A570M 端到端文档解析模型「jina-ocr-v1」
https://t.co/NFiogC4FJr

一张低端 L4 GPU 即可部署，2.57 页/秒的吞吐数倍于同精度模型（chandra-ocr-2 仅 0.38、dots.mocr 0.55 页/秒），即便是精度更高的 Infinity-Parser2-Pro 也需要 H100 双卡才追到 0.47 页/秒；jina-ocr-v1 把整页文档一次性转为高质量 Markdown，在“解析质量”和“处理速度”这两个维度上都有很强表现。

核心思路：OCR 是“可预测的生成”，所以可以投机
OCR 输出的下一个 token 高度可预测（表格、公式的结构都是模式化的），这正是投机解码（speculative decoding）的理想场景。团队没有去堆模型规模，而把工程重心放在解码成本上（生产中真正花钱的部分）。这个定位决定了它后续的所有设计。

架构：小视觉开销 + 稀疏解码器 + 投机头
· 视觉端（约 3.8 亿参数）：SAM 阶段 + 16× 卷积压缩 + CLIP-L 阶段。一页 1024×1024 的图像只占 256 个视觉 token；开启 Gundam 动态分辨率后，每个额外 tile 只加约 100 token，单页上限约 1,156 token。视觉 token 少意味着送入解码器的内容少，解码快。
· 解码端：DeepSeek-3B MoE，总参数约 3.4B，但每个 token 只激活约 5.7 亿参数（64 路由专家 + 2 共享专家，top-6 路由）。
· FastMTP 投机头：这是最核心的改动。只用一个稠密 draft block 递归复用 K=3 步来起草草稿 token，再用贪心验证保留最长匹配前缀——结果与普通自回归解码完全无损一致。在 L4 上把解码速度翻倍（42.7 → 83.1 token/s，接受率 57.6%，平均每次验证提交 2.7 个 token）。

训练：三阶段后训练 + 稠密可验证奖励
基础数据来自 olmOCR-mix、FinePDFs、DoclingMatrix、UniMER 等，加上针对历史档案（Europeana、美国国会图书馆、NARA）的合成页面。后训练分三步：指令对齐 → 针对退化/困难文档的鲁棒性微调 → 带稠密可验证奖励的 GRPO（对公式、表格、结构做确定性检查并给部分得分）。这个“部分得分”的设计值得注意：OCR 输出很难全对或全错，稠密的奖励信号比 0/1 判断能提供更有效的学习梯度。

性能：精度第一梯队边缘，吞吐领先明显
· olmOCR-Bench 83.4：基础文本 99.9（并列最佳）、长小字 93.2、表格 88.8；短板是陈旧扫描件 42.6，古旧/严重退化文档仍需人工复核。
· OmniDocBench v1.6 综合 91.14：文本编辑距离 0.046、公式 CDM 93.28、表格 TEDS 84.68、阅读顺序编辑距离 0.142。
· 吞吐 2.57 页/秒（A100、并发 32）——约为 olmOCR-2 的两倍。对比中，Infinity-Parser2-Pro 精度更高（87.6）但每页要 2.13 秒且需 H100 双卡；chandra-ocr-2 精度 85.8 但吞吐仅 0.38 页/秒。jina-ocr-v1 在“质量-吞吐”帕累托前沿上占据了低价高吞吐的位置。

使用与局限
· 输入单页图像/PDF，输出 Markdown（含 LaTeX 公式、HTML 表格）；按设计丢弃页眉页脚和图片，跨页句子会接续，无文本时输出 null。
· 部署路径齐全：Transformers、vLLM（投机解码仅在 vLLM 可用，注意要用 "eagle" 而非 "mtp" 配置）、SGLang、Docker，以及 Jina 自家 OpenAI 兼容 API。
· 定位上是 Jina 文档工具链的一环：HTML 转 Markdown 用 ReaderLM-v2，解析结果检索用 jina-embeddings-v4。