Linux.do热榜 · 2026-08-09 历史榜单

这是 2026-08-09 的 Linux.do热榜历史存档。查看 实时Linux.do热榜 获取最新排名。

1. 1
   这个冷饭是必须得炒一下了

   从搞点好玩的，进一步和Telegram集成继续讨论： 因为每天日志里最多报错就是这种了。为什么，因为根本就不知道怎么填啊，填 @xxx 的（还有直接填 @linux_do_helper_bot ）、填网址的、随便填几个字符串的。 加上这个插件本身没有校验填的 Chat ID 是否正确，然后就导致了日志里一堆此类错误： 所以不得不开个帖子炒下这个冷饭了，配置请仔细阅读帖子： 搞点好玩的，进一步和Telegram集成 运营反馈 现在我们可以通过 Telegram 收到关于自己的社区通知了，更可以快捷回复、点赞哦。 具体这么做： 打开 LINUX DO Helper 机器人，点击开始应该会收到操作指引。 复制指引中的 Chat ID 数字，填入：https://linux.do/my/preferences/profile 页面的 Telegram 通知 输入框后保存即可。 [image] 设置完毕后即可收到论坛通知… 填数字！填数字！填数字！ 292 个帖子 - 250 位参与者 阅读完整话题

2. 2
   差点猝死，而且丢失了期间所有记忆，佬们注意休息

   前天熬了个通宵，再此之前每天都是高强度vibe，连着一个月了吧，每天就睡4个小时左右，前天熬完通宵早上八点多了，手上的活马上干完了，但是有点困了，所以就想着要不去图书馆吧，离开了床就不会想睡了，所以我就喝了两杯咖啡，早上九点多到图书馆了，继续vibe到了14点左右，实在是累了，准备去网吧打会游戏。 到了网吧之后和朋友双排的，整个人也不咋在状态，大概16点多的时候我突然两眼发黑了，我就给我朋友说了一下，我说我状况好像不太对，也就是说完这句话之后，当我再次睁眼，已经是28个小时之后了，后面听我妈和网吧网管的讲述，我16:10分就在网吧包厢开始抽搐，然后彻底昏死过去了，120来了之后测了心率，210的心率，他们说当时我是有意识的，也能做出反应，甚至后面是警察送我回的家，我也自己回了卧室睡觉，但是我真的一点记忆都没有，给我的感觉就是，上一秒我给我朋友说两眼发黑了，下一秒就是28个小时之后了。而且抽搐的时候咬到舌头了，舌头上全是伤，现在吃个东西都很难受。 真的太恐怖了，还好我是在公共场所，要不然这会已经上天了。佬友们平时一定要多休息，活干不完可以慢慢干，命没了就真没了 题外话就是，我居然觉得这种感觉有点神奇，难以置信，他们都说当时我有意识也能回答问题，但是对此我真的一点记忆都没有，一片空白，就感觉是别的东西在控制我说的话一样 349 个帖子 - 316 位参与者 阅读完整话题

3. 3
   【CHY公益站】上架自部署 k3

   公益推广 （点击了解更多详细信息） 为了节省资源，把 DeepSeek V4 的上下文压制到了 200K 249 个帖子 - 200 位参与者 阅读完整话题

4. 4
   14岁孩子在小天才手表里看黄片咋教育

   昨天晚上，媳妇儿给孩子小天才手表充电时，发现里面有黄片，该怎么教育孩子啊。 570 个帖子 - 526 位参与者 阅读完整话题

5. 5
   [富可敌国]「粥.Pro」全网首发“号池可见”且“重置同享”的GPT纯Pro中转站！佬友共可领15刀~

   首先感谢L站提供的推广机会~ 作为程序员真心喜欢这个社区~ 站点简介 【粥.Pro】是 ChatGPT Pro 账号专营中转站，站点链接：https://congee.pro 不玩数学游戏，充值比例 1￥ = 1$ 不设订阅捆绑，随充随用 0.20x 倍率 真诚换取信任，注重中转用户体验 QQ群：450981902 点此链接加群 建站初衷 期望解决所有中转站用户的两大痛点，也是部分佬友不愿意用中转站的两点顾虑： 无法确定中转站是否真的纯血 官方重置都被中转站赚进口袋 本站特色 期望建造一个更趋近账号拼车的平台，让大家看见账号情况，享受账号级权益： 首创用户可见号池，包括登录类型、订阅档位、剩余用量、重置次数等账号数据均下放至用户级可见，让大家清晰的查看到自己每一条使用记录的实际承担账号。 首创重置返额机制，若官方按下重置按钮或发放重置次数，本站会根据号池各账号重置受益周期和周期内用户实际消耗金额，**返还90%**为周限时额度，让大家同享周额度重置的乐趣。 些许福利 小站初营，感谢佬友们捧场支持，献上专属福利: 本站账号登录立得 5$ （永久有效）（也可注册后于左下角个人资料绑定账号） 本帖评论已注册的用户名或邮箱加赠 5$ （永久有效） 进群报上已注册的用户名或邮箱再赠 5$ （首周，截止至2026-08-09 23:59:59） 福利以限时额度到账，额度有效期3600天，可放心领取~ 用户名重复可能脚本发放失败，进群秒补，建议回复邮箱更好~ 限时额度 设定主要用于限时权益管理和退款金额统计，不会影响正常使用~ 限时额度全分组可用，不设范围限制 调用时优先消耗最先到期的限时额度 1:1 抵扣普通额度 限时额度同样享受 重置返额机制 权益 目标用户 如果您符合以下用户特质，不妨来小站试一试呢 厌倦了在断断续续的低价渠道间东奔西跑 自充Plus号不够用，自充Pro号又用不完 想安稳用Pro号但担心号池混用和二手渠道 每次看到官方重置都眼馋自充党还假装不在意 想随充随用，不想背负周期限额带来的用量焦虑 站长想法真不错！我单纯想要支持一手 站点链接： https://congee.pro 目前限时充值活动进行中，首周充值不限次加赠20%月限额度~ 3779 个帖子 - 3642 位参与者 阅读完整话题

6. 6
   关于渐进式披露工具上下文的几种方向讨论

   首先的首先，我们可以把大模型粗略看作一个极其复杂的函数。在这个函数里，每一次交互的输出（Response），都建立在输入（Context）的基础之上；如果写出来可能是： 在之前的 Agent 开发中，受限于各种繁杂的业务需求，以及在 AI 辅助开发的各种防御型编程习惯的诱导下，很多开发者为了让 Agent 在长程任务中表现得更聪明、不犯错，会倾向于在 System Prompt 里塞入无穷无尽的规范，在 Tools 里注册成百上千的工具 API，试图期望通过穷尽一切可能性，来覆盖复杂的业务场景。 至少我之前工作的公司就这么干的 毫无疑问，这种暴力堆料必定会碰到两面墙：一面是理论的墙，一面是现实的墙。 从信息论的视角来看，输入与期望输出之间的 互信息 决定了模型表现的上限。现实世界的信息复杂性是无法被轻易压缩的，这意味着为了让模型准确理解“目标是什么、为什么这么做、以及具体该怎么做”，我们确实必须给它提供相当充足的上下文。但矛盾之处在于，当我们指望 Agent 去执行一个横跨数小时、涉及几十轮决策的长程任务时，整个任务的决策树会呈现指数级的膨胀。如果我们为了应对所有潜在分支，在一开始就把极其庞杂的信息（成百上千的工具、巨细靡遗的规范）全部塞进去，那么对于模型在当前这一步的决策而言，大部分上下文不仅无效，反而构成了巨大的噪声。有效信息被淹没，互信息被严重稀释。信息越涣散，模型调和冲突与“瞎猜”的空间就越大，幻觉和偏离目标的概率随之飙升。 图：当前的 agent 与 harness 的关系 bybike： 在信息论中，互信息（Mutual Information, MI）衡量的是一个随机变量中包含的关于另一个随机变量的信息量，或者说通过观察一个变量所能减少的对另一个变量不确定性的程度。输入与期望输出之间的互信息实际上构成了模型输出质量的信息论上界：如果输入所携带的关于目标输出的互信息不足，无论模型能力多强，也无法可靠地还原出完整、准确的期望输出。 而从现实工程的视角来看，无限膨胀的上下文意味着什么？意味着令人难以忍受的首字延迟（TTFT），意味着极速燃烧的 Token 预算，以及在超出 Prompt Cache 命中范围后高昂的算力成本。 随着一个 ai agent 系统的不断发展，如果人类不会定期彻底审阅一遍 ai 的各种规则上下文（agent.md，memory，各种项目记忆开发规范等），那 ai 看到的上下文里的规则冲突会越来越多，直到编程一大坨屎山。模型在长程任务中就必须不断消耗宝贵的思考 TOKEN 去调和这些相互冲突的指令，去跳大神猜测哪条优先，用户到底想要什么。 最好的例子就是 SuperPower 等各种所谓的深度定制化规范开发的 Skills，可能它在六个月前确实是一个还不错的 harness 方案，但在 5.6 之后就显得十分的臃肿可憎。A\ 在迭代 Cladue 5 时代的 harness 时，直接将 Claude code 的系统提示词删掉了 80% 且没有观测到能力受损，可见模型能力进步之幅度。 图源：A\ 工程师的官方博客，描述了上下文规则里相互打架的现象 那我们应该如何破解这个「既要足够的信息量，又要极低的噪音和成本」的死局呢？ 目前的一个相对较优的答案是：渐进式披露。Anthropic 此前提出的 Skills 机制向工程界普及了这一哲学：我们不在一开始把所有知识甩给模型，而是给模型一个目录/索引，让它在需要时主动去检索和加载。这极大地释放了 System Prompt 的空间。 既然“知识约束（Skills）”可以被渐进式披露，那占据上下文另一大头的“工具（Tools）”行不行呢？ 答案是可行的。随着当前模型直觉规划能力和错误反思能力的提升，工具的按需加载在当前阶段已经具备了落地条件。但与普通的文本检索不同，工具的渐进式披露有着极其特殊的工程挑战。今天我们就来盘点一下，为了让工具“按需出现”，业内到底演化出了哪几种截然不同的方向。 一、必要的理解上下文 1.当前 agent 的工具调用机制是什么？ 相关概念我在之前的博客里已经重复过很多遍了，不过这里最好还是再重复一遍：我们日常看到的所有 Agent——不管是 Claude code、codex、Cursor 还是别的什么 Harness 框架——其内部的模型都一直，且只会做一件事，即预测并输出下一个 token。所谓调用工具，本质上是模型在某一刻，按照预先约定的格式，吐出了一段结构化的文本。 这是理解后续一切设计取舍的起点。 一次请求长什么样？ 当我们和 Agent 对话时，每一次发给模型的请求除了 system prompt，除了我们看到的聊天信息，背后大概还会附加一个 tools 的参数。一个最简化的请求大概是这样的： { "messages": [ { "role": "user", "content": "查询北京天气" } ], "tools": [ { "name": "get_weather", "description": "查询指定城市的天气", "parameters": { "type": "object", "properties": { "city": { "type": "string" } }, "required": ["city"] } } ] } 此即「注册工具」，我们把工具的名字、用途描述、参数契约塞到请求的 tools 字段里，告诉模型「这次对话中你可以用下面的这些东西」；模型在收到请求后，有两种可能的回应方式。第一种是我们最熟悉的，它会直接回一段自然语言： { "role": "assistant", "content": "好的，我来帮你查一下北京的天气。" } 第二种就比较有趣了，模型可能会判断「这个问题我应该调用工具而不是直接回答」，于是它返回的内容变成了这样： { "role": "assistant", "content": null, "tool_calls": [ { "id": "call_123", "name": "get_weather", "arguments": { "city": "北京" } } ] } 注意，这个 tool_calls 不是我们从模型输出的普通文本里用正则抠出来的，它是 Provider API 返回的原生结构，通常还会带一个 finish_reason: "tool_calls" 的标记。我们本地的 agent 程序看到这个标记，就知道模型不是在对用户说话，而是在说：「我需要执行这个工具，请把结果拿回来给我。」 至于 Provider 内部是怎么让模型乖乖吐出这种格式的，各家不完全一样：可能把工具定义序列化成特殊的提示词格式，可能用训练过的专用 tool-call token 标记调用边界，也可能在输出阶段施加 JSON Schema 级别的语法约束，确保模型产出的参数类型和结构严格符合注册时的定义。但万变不离其宗，输入中多了工具定义，输出中多了一个结构化的工具调用通道，仅此而已。 如果不注册呢？ 反正大模型是一个输入什么东西然后再输出什么东西的黑箱嘛，那假设我们不把 get_weather 放进 tools 数组，只在聊天消息里写一句：「你可以调用 get_weather，参数是 {"city": "北京"}」，这种情况下模型也当然认得这句话，甚至可能输出一段看起来很规整的 JSON： { "name": "get_weather", "arguments": { "city": "北京" } } 但这只是普通文本。在这种情况下，Provider 不会把它标记为 finish_reason: tool_calls，不会帮我们做参数校验，也不会给我们一个 call_id 来匹配后续的工具执行结果。我们的本地程序必须自己解析文本、猜测这段 JSON 是不是工具调用、手动校验参数格式、自己处理各种边界情况。 不过话说回来，这种「文本协议」在过去其实也流行过。在 2023 到 2024 年乃至2025年，很多 Agent 框架和工具走的恰恰就是这条路，最典型的就是 ReAct，还有 2024 年的 Claude Dev/Cline，以及后来继承这套机制的 Roo Code 和 Kilo Code 早期版本。它们的做法很朴素：在 System Prompt 里用 XML 或 Markdown 描述所有可用工具，然后让模型在对话中按约定格式输出调用指令。客户端捕获到符合格式的文本块后，解析、执行、把结果拼回对话。 这种实现在早期主要是为了快速兼容不同渠道的模型，不用管它们是否真的支持 Tool Calling；但代价是没有 Provider 层的语法约束，模型偶尔会写出格式跑偏的调用，如参数名拼错、少一个括号、甚至自由发挥出一段解释代替调用。这就对框架本身提出了很高的要求。随着各个 Provider 的原生 Tool Calling 越来越成熟、尤其是 Strict Tool Use 和结构化输出这类能力逐渐普及，文本协议路线在可靠性上的差距被越拉越大，慢慢退出了主流视野。 换句话说，两条路线的根本性差距在于： ❌ 文本协议（不注册）： 模型输出普通文本 → 本地自己解析 → 判断是不是工具调用 → 校验参数 → 执行 ↗ 灵活，但可靠性和工程复杂度全由框架承担 ✅ 原生 Tool Calling： Provider 返回正式 tool_calls → 本地直接读取 name、arguments、call_id → 校验授权 → 执行 → 按 call_id 回传结果 ↗ 可靠，但受限于 Provider 的 JSON Schema 约束 这件事为什么重要？ 在前面的讨论中，我们可以得到一个很简单的结论： 要做原生 Tool Calling，工具就必须出现在请求的 tools 参数里。Provider 在推理开始前就需要拿到所有工具的完整契约，否则它无法建立语法约束，也就无法产出合法的原生 tool call。 这件事听起来简直就像「人被杀就会死」一样合理自然，单独来看确实没什么。大部分 Agent 几个十几个甚至几十个工具，我们全部注册进去不就完了？ 直到 Agent 的能力越来越强，直到我们可能期望它在一个会话中灵活调度上百个工具。这时候，把全部工具定义一次性塞进 tools 数组就变得不再现实。 我们可以做一个简单的算术：假设一个工具的平均定义（名称、描述、参数 Schema）需要 400 个 token（这是一个非常保守的估算），那么两百个工具就占据了 80k token 的上下文；如果用户再疯狂一点多加一个 MCP，这些工具定义的总 token 数会迅速逼近甚至突破模型上下文窗口的实际可用的注意力上限；而即便没有突破，留给用户消息、历史记录和推理链的空间也会变得极其紧张。 几个月前，主流旗舰模型的实际可用上下文窗口大概在 150k 左右，而现在则普遍到了400-500k，不由得令人感慨 AI 能力提升之迅速；但可用窗口的增长不代表我们就可以当败家子嗯造上下文空间了，模型的注意力机制在大量低相关性的工具描述上仍然会产生显著的信息稀释和上下文腐烂效应。 那么，我们假设，如果一个 agent 有几百个工具，我只想在模型真正需要时才把工具的定义给它，会发生什么？实现起来容易吗？ 2.渐进式披露，和为什么渐进式披露工具需要独特的工程设计 为什么渐进式披露 Tools 会比 Skills 更加困难 答案是：在当前的 Agent 架构下，这件事会比想象中困难一点。 它触及了原生 Tool Calling 机制的一个根本性矛盾。在讨论 Tools 之前，我们先看一个相对轻松的参照物：Skills。 Skills 的渐进式披露在业界已经相当成熟，实现起来几乎没有阻力，因为 Skills 的本质是纯文本内容，一段 markdown 指令。它的加载流程是：用户提问，模型判断需要某个 Skill，Agent 从本地读取对应文件学习到相关领域知识，并据此回复或工作。 在这个过程中，所有的信息增量发生在消息的末尾，不涉及任何最前方请求结构的改动。 而“不改动前面的上下文结构”在当今的 AI 工程实践中恰恰是极其巨大的一项优势——因为它完美契合了各大模型厂商的上下文缓存（Prompt Cache）机制。 为了降低长文本推理的成本和延迟，当前主流 Provider（如 Anthropic、OpenAI）的缓存逻辑是：只要两次连续请求的前缀（Prefix）在 token 层面完全一致，模型就能直接复用前一次的 KV 计算结果。但这个机制极其严苛：前缀必须一模一样，哪怕在中间修改或插入了一个 token，后续所有的缓存就会瞬间报废。 理解了这一点，我们就会明白 Skills 渐进式披露的做法有多么平滑。当客户端在对话中途追加一条带有 Skill 内容的消息时，排在它前面的 System prompt、tools 数组、以及早先的历史消息可谓纹丝不动。因此，新请求的前缀没有遭到任何破坏，庞大的基础上下文依然能稳定命中缓存。新加载的知识只影响它之后的计算过程。 但 Tools 不同。 回顾第一节，原生 Tool Calling 要求工具的完整定义必须出现在请求的 tools 参数中。Provider 在推理开始前就需要拿到所有工具的 name、description 和完整的 JSON Schema，才能： 构建工具调用的特殊语法约束（如 Anthropic 的 Strict Tool Use 或 OpenAI 的 function calling grammar）。 在输出阶段识别 finish_reason: tool_calls 并正确解析结构化字段。 验证工具名称和参数类型是否合法，拒绝模型产生的幻觉工具调用。 如果我们不在 tools 中预先注册某个工具，Provider 就不会为它建立语法约束。即使模型自己在普通文本中写出了该工具的名称和参数，Provider 也不会将其识别为合法的原生 tool call，客户端只能退回到自己写正则解析 JSON 的“文本协议”野路子，失去原生调用的所有保障。 这意味着：要做原生工具调用，工具就必须出现在请求的 tools 数组里。而 tools 数组是请求结构的一部分，这代表它永远驻扎在请求的最前端，即我们传递给模型全部 prompt 的一个相对起始位置。 可以设想一下：我们的 Agent 有 200 个工具。为了做渐进式披露，我们固然可以在第一轮只把 5 个高频工具塞进 tools 数组。到第三轮对话时，模型意识到自己需要一个「创建 PDF」的工具——但这个工具不在初始的 5 个里。客户端此时只有两个选择： 选择 A：在下一轮请求中，把「创建 PDF」临时塞进 tools 数组。 tools 数组变了 → 请求最前方的结构变了 → 整个 Prompt Cache 全部报废 → 几万甚至几十万 token 的历史消息必须重新算一遍，不仅巨慢而且巨贵。 选择 B：保缓存，不修改 tools 数组，让模型直接在普通对话里按格式把参数当纯文本输出。 所以，正常情况下渐进式披露工具的核心死结出现了： 原生工具调用的可信度建立在「Provider 在推理前就知道所有工具的完整契约」这一前提上；而渐进式披露的本质是「推理前坚决不让 Provider 知道所有工具」。这两个需求在系统结构上是天然互斥的。 理解了这些约束之后，我们就可以来看业内为了解决「既要原生 tool calling，又要按需加载、不破坏缓存」这个三角难题，到底演化出了哪些思路。 二、业内都是怎么做的？ 1.最正统：Anthropic 的 Tool Search Tool A\ 在 2025 年 11 月发布了Tool Search Tool，大致的原理是：首先，客户端仍然需要把完整的工具契约全部发给 Anthropic；但是我们可以把某些没那么必要的工具标注为 defer_loading，被标注的工具不会进入模型的初始长下文。在这种情况下，agent 的初始上下文中只有 Tool Search 和少量的非延迟加载工具。Astropick 将会在服务端维护隐藏的工具目录。 大概的工具契约是这样的： { "tools": [ { "type": "tool_search_tool_bm25_20251119", "name": "tool_search_tool_bm25" }, { "name": "learning_create_cards", "description": "Create learning cards...", "input_schema": { "...": "完整严格 schema" }, "defer_loading": true }, { "name": "learning_create_plan", "description": "Create a study plan...", "input_schema": { "...": "完整严格 schema" }, "defer_loading": true } ] } 这里我们假设这个 Agent 是一个学习场景的专用 Agent，我们给它注入的工具有一大堆学习相关的工具，比如制卡之类的；那么当模型需要学习制卡能力的时候，agent 就会调用： { "name": "tool_search_tool_bm25", "input": { "query": "create flashcards from study notes" } } Anthropic 在服务端搜索工具目录，返回特殊的 tool_reference： { "type": "tool_reference", "tool_name": "learning_create_cards" } Provider 随后在当前对话位置把这个引用展开成完整工具定义。模型看到真实 schema 后，可以直接产生： { "type": "tool_use", "name": "learning_create_cards", "input": { "...": "严格参数" } } 内置搜索在 Anthropic 服务端运行，搜索结果和目标工具调用甚至可以出现在同一个 assistant response 中。客户端只需要执行最终的具体工具。 顺带一提，搜索有两个变体：tool_search_tool_regex_20251119 让模型写 Python re.search() 正则模式来匹配（上限 200 字符），tool_search_tool_bm25_20251119 则接受自然语言查询（上限 500 字符）。两者都会搜索工具名、描述、参数名和参数描述。 那么问题又来了，这种方式会破坏缓存吗？当然不会。这里的关键不是「发现后不改变工具列表」，而是 Anthropic 对 defer_loading 有一套特殊语义： 原始缓存前缀： [Tool Search] [System Prompt] [历史消息] 发现工具后： [Tool Search] [System Prompt] [历史消息] [tool_reference → 展开的真实工具契约] 我们可以看到，完整工具定义是在发现位置追加进去的，没有回头修改最前面的工具前缀。历史消息里出现过的 tool_reference 会被 API 全程展开，所以模型在后续轮次可以直接复用已发现的工具，不需要重新搜索。 这种实现方法的坏处是——强依赖于 Anthropic 这个 Provider，我们是没办法在自己的程序中离开 A\ 去复刻的，因为 A\ 控制了模型推理前的内部处理： 我们发送的 tools ↓ Anthropic 分成： - 隐藏工具搜索索引 - 模型可见上下文 - Tool Calling 严格语法 ↓ 按需将契约插入对话中间 那么其他 Provider 呢？OpenAI 自家的 Responses API 如今也提供了同构的 tool_search + defer_loading 协议（我们放到本节末尾再讲），但广大「OpenAI 兼容」生态——vLLM、OpenRouter、各家自建兼容层等通常只能二选一：发送 tools → 全部进入模型上下文，或者不发送 tools → Provider 不承认对应的原生调用。它们缺少 defer_loading 和 tool_reference 这种 Provider 级协议。因此我们如果自己动手动态增加工具，就会改变早期前缀并破坏缓存。 于是就有了下面两条客户端自救路线。 2.但是服务端不支持怎么办？一个折中的压缩选项：stub 注册工具 这是我之前实现过的一个方案，核心思路是：既然 tools 数组一个字都不能动，那就在「注册全部工具」的前提下，把每一个工具的契约在未被需要之前压缩到极限。 具体做法可以分为两部分。第一部分是把每个真实工具都注册成一个 stub：保留真实工具名，描述尽量压缩，参数契约则换成一个宽松的万能外壳；第二部分是在工具列表里常驻一个普通的 load_tool_schemas 工具，由我们的客户端实现。Stub 大概长这样： { "name": "learning_create_cards", "description": "从学习笔记创建记忆卡片。调用前必须先调用 load_tool_schemas 获取完整参数契约。", "parameters": { "type": "object", "properties": { "arguments": { "type": "object", "additionalProperties": true } } } } 完整的调用流程是： 模型认为自己需要制卡能力 ↓ 1. 模型调用 load_tool_schemas({ "tools": ["learning_create_cards"] }) 2. 客户端返回完整 JSON Schema（作为普通 tool_result 文本） 3. 模型按照刚拿到的 schema 调用 learning_create_cards 这个 stub 注意第 2 步的完整契约是以消息的形式回来的，追加在对话尾部，不碰任何前缀，因此可以复用之前的全部缓存。我们可以计算一下这种方案的 tokens 消耗：第一节中我们按照 400 token/工具估过 200 个工具的上下文消耗大概为 80k；换成 stub 之后，每个工具大概只剩名字、一句话描述和宽松契约，约 60-80tokens，同样的 200 个工具的上下文消耗大概可以被压缩到 15k 左右，降低了 80%的上下文消耗。 但这个方案并没有让问题消失，stub 的数量依然是 O(N) 的，并没有实现真正的渐进式披露加载；而且每个 stub 都常驻在模型的上下文中，对于模型注意力的消耗也仍然是实打实的。另外它本质上是一种「半原生」方案：Provider 的语法约束还在，但约束的是 stub 那个宽松外壳，真实参数的合法性需要完全靠客户端自己约束。 3.进一步简化：客户端实现 tool search，注册更宽松的工具 当然，我们可以进一步简化。 让我们重新审视一下目前工具调用的两个基本前提： 工具在 Provider 注册； 模型可以正确遵循工具契约。 第一条其实可以被收窄到极限——注册的可以只有一个工具；而第二条，随着当前旗舰模型指令遵循能力的提升，「把契约以文本形式交给模型，它就能照着填参数」已经是一项相当可靠的能力。因此我们完全可以定义一个通用的、全能的 invoke_tool，把所有真实工具都藏到其背后： { "name": "invoke_tool", "description": "执行工具目录中的工具。请先用 search_tools 找到目标工具，再按返回的契约填写 arguments。", "parameters": { "type": "object", "properties": { "tool_name": { "type": "string" }, "arguments": { "type": "object", "additionalProperties": true } }, "required": ["tool_name", "arguments"] } } tools 数组从此恒定，里面只有两个工具：search_tools 和 invoke_tool。一次完整的发现与调用是这样的： 1. 模型 → search_tools({ "query": "create flashcards from study notes" }) 2. 客户端 → 返回目录条目（工具名 + 一行描述，不含完整 schema） 3. 模型 → invoke_tool({ "tool_name": "learning_create_cards", "arguments": { "notes": "...", "mode": "qa" } }) 4. 客户端 → 按 tool_name 取出真实 schema 校验 → 执行 → 回传结果 （校验失败 → 回结构化错误 → agent 修正重试） 对比一下之前 2.2 节的方案： 之前： N 个具体 Stub + load_tool_schemas 现在： 1 个 invoke_tool + search_tools 初始上下文占用从 O(N) 直接变成了 $O(1)$——不管工具目录里躺着 100 个还是 10,000 个工具，模型看到的永远只有初始的两个工具（大概只有几百 tokens 的占用）。工具目录本身可以是一个普通的本地索引、一张数据库表、甚至一个 embedding 检索服务，我们在本地可以实现非常自由的检索。 那么，这个方案的代价又是什么呢？ 代价是我们无法复刻 Anthropic 的一个核心能力：Provider 只知道 invoke_tool 的外层 schema，不知道 learning_create_cards 的内层 schema。也就是说，在 Provider 侧是无法约束校验这个工具调用的参数是否「真的」格式正确的——外层有语法约束，但里面的 arguments 则是一个不设防的黑盒。真实校验必须由我们的客户端完整承担，一旦失败，就返回结构化校验错误让 agent 修正。除此之外还有一些隐性成本：真实参数变成了「JSON 里的 JSON」，转义和嵌套多了一层；而且这条路线对模型本身的指令遵循能力有门槛，太弱的模型会在第 3 步频繁出错。 公平起见，补偿也是有的：因为所有具体调用都收敛到了同一个入口，校验、授权、审计、限流这些横切关注点反而只需要在 Gateway 一处实现——这在多 User/Agent 场景里简直是意外之喜。 因此，没有 Provider 原生配合时，以下三个目标无法同时满足： 初始上下文不包含 N 个具体工具或 Stub； 工具列表始终稳定，不破坏早期 Prompt Cache； 每个具体工具仍以独立原生工具和严格 schema 被 Provider 调用、约束。 三者只能取二： 选择 结果 缓存稳定 + 具体工具原生调用 必须常驻 N 个真实工具或 Stub 初始无 N 个工具 + 具体工具原生调用 发现后动态修改 tools，破坏早期缓存 缓存稳定 + 初始无 N 个工具 只能常驻一个通用原生调用外壳，由客户端还原具体工具 4.Moonshot 的按需加载工具机制 Moonshot 在 Kimi K3 的 API 里提供了一个叫「动态加载工具」的机制。月暗的思路是：工具声明不一定要待在请求开头的 tools 字段里，它可以是一条消息。 具体做法是：在 messages 中插入一条 role 为 system、携带 tools 字段的消息。声明格式与请求顶层 tools 完全一致，且必须提供工具的完整信息（name、description、parameters）： { "messages": [ { "role": "system", "content": "You are Kimi, an AI assistant..." }, { "role": "user", "content": "Calculate fuel consumption." }, { "role": "system", "tools": [ { "type": "function", "function": { "name": "Calculator", "description": "计算器，只支持单个算术表达式的求值", "parameters": { "type": "object", "properties": { "expr": { "type": "string", "description": "算术表达式，支持四则运算、指数运算、对数函数、三角函数，使用 javascript 语法" } }, "required": ["expr"] } } } ] } ] } 这个设计有几个关键的语义： 携带 tools 的 system 消息与普通消息地位相同：它出现在 messages 的哪个位置，工具就从哪个位置开始对模型可见； 动态加载的工具与顶层 tools 声明的全局工具并存，模型可以同时看到两类； 注入的声明必须是完整定义，不能只传个工具名； 这条 system 消息不能再带 content 字段，否则请求会以 400 报错。 那缓存呢？官方给的原则有四条： 操作 对前缀缓存的影响 在 messages 末尾追加工具声明 不影响已有前缀缓存 后续请求原样保留已注入的工具声明 前缀保持稳定，有利于持续命中缓存 删除、修改对话中间的消息，或在中间插入新声明 变更位置之后的缓存可能无法命中 在顶层 tools 字段声明全局工具 不影响缓存命中 换句话说：追加，不要插入；注入了就别删。 工具声明被当成普通对话内容的一部分往后追加，前缀纹丝不动，就和 Skills 的加载路径一模一样。基于这个思路，官方顺手给出了 tool search 的参考实现（API 层面并没有内置的搜索接口）： 顶层 tools 里只声明一个自己实现的 search_tools； 在 system prompt 里告诉模型有哪些可搜索的工具目录/领域关键词； 模型需要工具时先调 search_tools，后端按关键词返回匹配的工具名和简介； 应用把命中工具的完整声明通过一条带 tools 的 system 消息追加到末尾； 模型在后续生成中直接原生调用这些新加载的工具。 我们可以将Kimi 的按需加载工具方案可以视为一种 Provider 原生支持的、协议设计更轻量、使用更自由的选择。它在协议层面上不需要任何的额外概念，不需要提供 defer_loading、tool_reference 等新字段，声明格式与顶层 tools 完全一致；在位置上，工具在 messages 的哪个位置注入，就从哪个位置开始对模型可见，直觉且可控，且天然的对缓存友好；在自由度更高的基础上还依然享有 Provider 侧的原生约束，不会像 invoke_tool 那样把参数黑盒化，十分之优雅，令人眼馋。 三、总结：渐进式披露与 tokens 经济学 在 Tokens 经济学中，我们会更加关注 Agent 运行过程中真正的高相关信息能够占据多少注意力，以及已经支付过计算成本的上下文能否被持续复用。 因此，一个好的工具系统并不是简单地让模型“知道尽可能多的工具”，我们的目标应当是让模型在当前决策中，只看到足以支持这一步行动的信息。将数百个工具的完整 Schema 一次性注入上下文，固然最大限度地保留了能力边界，却也会让大量与当前任务无关的定义长期占据注意力、Token 预算和首字延迟。工具越多，这种暴力注册的边际收益越低，边际成本越高。 但工具又不同于普通知识。Skills 可以作为文本自然地追加在消息末尾，而原生 Tool Calling 通常要求 Provider 在推理前获得完整工具契约。于是，严格原生调用、稳定的 Prompt Cache 和真正的按需加载，构成了一个无法仅靠普通客户端同时满足的三角约束。缺少 Provider 配合时，我们只能在三个目标之间进行取舍： 保留每个工具的独立原生调用，就必须让真实工具或 Stub 常驻上下文； 动态修改 tools 数组，可以获得严格 Schema，却会破坏早期缓存； 保持缓存稳定并将初始占用压缩到常数级，就只能通过 invoke_tool 之类的统一外壳，把真实校验下放给客户端。 至于如何抉择，那就要看各位 Agent 工程师们自己的权衡和 taste 了。 相关文档与延伸阅读 Anthropic：Tool Search Tool defer_loading、BM25/Regex 搜索以及工具发现后的调用流程。 OpenAI：Tool Search defer_loading 按需加载 Function、Namespace 和 MCP 工具。 Moonshot AI：动态加载工具 messages 中的 System Message，在对话过程中追加完整工具声明。 Anthropic：Tool Reference defer_loading、tool_reference、Strict Tool Use 等机制。 Anthropic：Tool Use with Prompt Caching 延伸阅读：上下文稀缺、RAG、Memory 与 Skills 89 个帖子 - 56 位参与者 阅读完整话题

7. 7
   准备下一个项目就是动态家宽IP 和 家宽IP订阅节点 看看有多少需要要的，完成后送CDK【8/3 05:36 道爷我成了】

   准备下一个项目就是动态家宽IP 和 家宽IP订阅节点 看看有多少需要要的，动态家宽IP已经写完了测试完了 接下来就是订阅节点功能加上去看看我的出口节点咋样 https://linux.do/t/topic/2693888/6 新帖子 8/3 05:38 8/3 05:36 终于是写完了测试完了，今天发CDK 就50张 关注我，新帖子里会有CDK链接！ 就放几个出口IP吧 现在上千个家宽已经就绪 8/1 8:48 还没弄完，睡醒再弄了 8/2 18:23 起来了继续弄，动态api 我觉得暂时不会放了防止滥用也因为现在的带宽小承载不了太大，晚上好了放50位 7天订阅节点CDK 8/2 21:39 做最后的审查和测试明天放测试CDK 8/3 0:43 基本上完活了，白天或者晚上开放CDK测试 不做推广 我会另发帖子 173 个帖子 - 150 位参与者 阅读完整话题

8. 8
   【霸气公益】已运行超 1 年的公益站-纯国模-260801更新

   本帖使用社区公益推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的项目是免费使用的，无收费（变相收费、赞助）部分： 是 / 否 我的帖子已经打上 公益推广 标签： 是 我的项目属于个人项目，与公司或商业机构无关： 是 我的项目不存在QQ、TG等群组引流： 是 我的项目不存在非运营必要的网站引流： 是 我的项目不存在为他人推广、AFF： 是 我的项目无关联的商业项目： 是 我的站点存在登录，并已接入 LINUX DO Connect： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 平台昨日下午已更新最新deepseek-v4-flash-0731，同步上线hub站了 欢迎各位佬体验，2000元3个官方账号负载 手机编辑 有不到请佬们之处见谅 公益站地址：http://ai.121628.xyz 118 个帖子 - 101 位参与者 阅读完整话题

9. 9
   「开源」拯救你的 grokfree，实测完美运行降智避免插件！

   本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 直接上图： 来说一下原理，我上一个帖子说过了， github.com GitHub - lij768423-svg/grok2api-egress-enhancements: Grok2API & CPA egress quality guard with proxy... Grok2API & CPA egress quality guard with proxy recovery, quarantine, migration, and operations UI 注册机 github.com GitHub - lij768423-svg/grok-register-panel: Grok register engine (Camoufox) + live web monitor... Grok register engine (Camoufox) + live web monitor panel cpa插件 【开源】 拯救你的 grokfree之 cpa 插件开源 开发调优 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 前情提要： … 277 个帖子 - 87 位参与者 阅读完整话题

10. 10
    那个最帅的男人的星辰站，出来解释下呗？

    muyuan佬已经给了处理了。说是之后会持续保持监控juice值。希望能保持下去吧。 为了避免大家讨论到后面越来越偏题，我这里强调几个点。 1.中转站的利润，这个帖子说的很清楚了，各种倍率有各种不同的渠道。 【无广告】中转站运营快一个月了，中转运营现状与成本分析 开发调优 中转运营现状与成本分析 继此前几篇中转运营科普帖 AI 中转站大起底：什么是中转站，倍率是什么（科普贴） https://linux.do/t/topic/2563086 https://linux.do/t/topic/2548075 之后，今天继续聊聊之前未说明的渠道和具体成本。 我们做中转服务约20天，目前正经历GPT市场“号荒”的第三天。 一、市面GPT倍率与号池来源 当… 2.大家讨论的时候可能忽略了sol掺luna的价格差距。 另外，我根本不会想用luna。因为luna在 给 我 的 项 目 埋 坑！ 3.实际上目前关于降智或者掺水的讨论已经推进到最后一点了。 4.保持理智，不要冲动。 5.退款话题和我无关，退款从来不在我的诉求里。 本来今天下午发现gpt5.6-sol解决一个问题搞了2个小时没搞好，还以为是gpt官方降智+上下文太小导致绕了半天。 晚上刷ld站看到有个看起来还可以的软件，顺手测试了一下。 基于cot和juice的gpt5.6sol检测方式，从此告别掺假！[附实战案例] 平常sol-high都是40855。而星辰的sol的juice测试，竟然很大比例出现48（我除了软件，自己也测了好几次，80%都是48）平常几乎都是用sol-xhigh，切了api随手测一下就继续了，而sol和luna的xhigh全是128，导致以前完全没发现。 我同样也对其他的中转站进行了测试，并且也对我的官方订阅进行了测试。基本上不是40就是40855 这合理吗？你现在在做中转站。虽然是codex测试，倍率低，但是大家的k12或者bug-team渠道倍率都差不多啊，0.04-0.07。你觉得价格低了你就提升倍率呗，为什么要往sol里掺luna呢？ 我今天下午的项目被搞得一团糟，推进极慢，问题非常多。一开始我还以为是gpt降智了，重新调整了好久，修了好久的代码。晚上这一测确实是有点生气了。 希望站点的管理员赶紧处理一下问题。 附上测试日志。 君1.7z (6.0 KB) 382 个帖子 - 187 位参与者 阅读完整话题

11. 11
    小孩子可以学 AI 原理吗？作为一名 11 岁接触 LLM 的小孩子，分享一些看法~

    Edit 建议佬友们读完全文再发帖讨论QAQ Edit 2 给没看过原帖的佬友大概介绍下背景，原帖是一位爸爸问能不能让自己的孩子学 ai 原理，下面有一些人说孩子太小不能学。我写这篇帖子的目的是为了证明这个年龄段的孩子可以学习 ai 原理。看来有不少佬友没看过原帖，我也确实表述没有很准确 qaq 从很想听听佬们的意见：孩子真的不能学习AI原理吗？继续讨论： 今天刷到一个帖子，发起讨论「孩子是否可以学习 AI 原理」。帖主 @StarFox 认为可以，因为简单理解 Transformers、CoT 的原理不一定要有数学基础。立刻有人反驳：不会线性代数，搞不明白向量叉乘，没有基础、黑盒学习能有什么效果？ 帖中讨论的对象主要是四、五年级到初中的小孩子，而幸运地，我正是在这个年龄段开始接触和使用 AI，也属于讨论的对象中的一员。评论区不少人是大学生、研究生、博士生，更多的人已经毕业工作，学识和能力都无疑在我之上，对于 AI 的理解也远比我深刻。然而，一些人对于我们的推测和断言，与我的体会有所偏差。古人云「耳闻之不如目见之，目见之不如足践之」，所以我今天斗胆来分享下自己的一些看法，还请多多指教。 先中译中一下帖主的意思。他所说的「简单理解」其实是一种直觉上的理解，或者说是「通过理解内涵逻辑从而塑造培养直觉」的方法。 比如梯度下降，公式上的理解是 \boxed{\theta_{t+1}=\theta_t-\eta\nabla J(\theta_t)}。而直觉上理解梯度下降则只需要在脑中构建一个高低起伏的空间，一个点从某一个位置出发，总是朝向向下坡度最大的方向移动，最终所有方向坡度都向上时（在谷处）停止。 不难发现，公式上的理解通常需要积分、导数、矩阵乘法、凹凸性的高数知识，而在直觉上理解是并不需要数学基础，是个人都会。在这里，如何表示「高低起伏的空间」、如何计算「向下坡度最大的方向」是哪个、如何计算「向特定方向移动后的坐标」，都像一个个封装好的函数。函数里具体是如何实现的，在这个阶段不必了解。 这就反驳了评论中常见的一种错误观点：学习原理就必须有高数基础。 接着我们再看评论中另一个常见观点：学习原理对应用没用。实际上，这种「直觉上的理解」对于应用 AI 相当有用。 因为如果他们在直觉上理解了注意力机制，就不难理解为什么指令要求后面加上一堆感叹号不能起到强调作用反而会稀释注意力，为什么 prompt 重复两遍可以提升性能、而重复五遍会降低表现[1]。如果他们在直觉上理解了 Tokenizer 的原理，看到模型算出 9.11>9.9、strawberry 里有 2 个 r 就不会大惊小怪[2]。如果他们知道每次预测都要综合计算前面所有上下文的 KV 矩阵，就能明白 context 管理的重要性，也就能明白如果模型拒绝要求时继续说服是没有效果的[3]。如果他们了解过拟合，就很容易推理出为什么<think>可以获得随机回复[4]。如果他们理解了语义激活，就能明白为什么 prompt 中使用正面要求比负向写法效果更好[5]。 再说说评论区中的另一种观点，就是愿意学习、有能力学习 AI 原理的孩子太少了。这就是太低估新时代的小孩子们了。读到这里可能一些人觉得我很厉害，而这种厉害只是个例。这句话有两个错误，第一，我并不厉害，第二，有无数比我年龄小、却比我厉害的多的人。前年我和学校里的一位同级生一起参加比赛，他在没有 Claude Code 的时代就已经精通十几种编程语言[6]。他在那场比赛中获得一等奖，而我却忘了保存拿了零分。今年我考入了苏州中学，而和我同一年入学的，还有比我小半岁、却维护着一个规模比我的项目大得多的 GitHub 仓库的 Nemo2011。今年是他维护这个 4.2k stars 仓库的第五年。即使倒退回几年前，以他们的智商和能力，不可能学不会 AI 原理。这样的人我身边就有三四个，可想而知，有能力有兴趣学习 AI 原理的孩子绝不在少数。 感谢你阅读到这啦。本文在飞机上撰写，没有网络因此部分信息没有查证，如有事实性错误，欢迎指正ww 来自 Google Research 2025 年末的一篇论文 Prompt Repetition Improves Non-Reasoning LLMs。原因是注意力是单向的，模型只看前文而不看后文，导致看问题前半部分时看不到后半部分。如果重复两遍，第二遍时看问题的前半部分就可以综合第一遍时问题的半部分，类似人类的回读。只对非思考模型有效，因为思考模型在思维链中会自己重复一遍。重复过多次会导致注意力涣散和减弱。 ↩︎ 模型不会数数一般是并行概率拟合本身不擅长计数、加之重复数据可能出现的结构位置混淆导致的。但 strawberry 里有几个 r 确实是 tokenizer 的问题。 ↩︎ 正确的做法是将拒绝的消息删除，然后重新发一遍 prompt。当然这个方法只对确实不该拒绝的情况有效，比如模型因为某些执念不想直接告诉你答案（非要你自己算）用这个方法可以解决，但模型如果因为请求违反伦理或政策而拒绝，就通常需要更复杂的破限方式。 ↩︎ DeepSeek 某个版本中，无上下文情况下发送<think>可以获得模型对一个随机问题的推理过程。当时小红书就有好多人觉得是 DeepSeek “把其他人的回答发送给我了”“非常恐怖会不会是数据泄露”，而且这样的帖子能获得数千点赞。实际原因是模式诱导。广义上来说也是过拟合的一种（格式过拟合）。 ↩︎ 也就是粉红大象效应。在 SOTA 模型中这个效应已经没有那么明显了，在大多数情况下他们可以很好地处理负向要求。但效果仍不如正向要求。 ↩︎ 本文发表后有人提出疑问。在此补充说明，这是他的自述，我未加修改。不过，无论能不能达到一些人心目中的「精通」标准，都不影响本文的论述逻辑链条的自洽性。 ↩︎ 227 个帖子 - 161 位参与者 阅读完整话题

12. 12
    拼夕夕省钱实录

    已经高强度用了好几年拼夕夕,现在已经基本不用其他网购平台,ps:除非拼夕夕价格比其他平台更高。 叠卷能经常做到20元以内买9-10包预制菜，我每顿会加一些蔬菜进去回一下锅，味道更佳，下面是其中一个套餐的菜单 菜报告和粮农是我比较推荐购买的预制菜品牌，他俩的味道和菜单几乎一致，感觉像同一个工厂出的货，粮农价格贵一点现在需要30元才能买10包，所以现在优先推荐菜报告，不过菜报告选菜品也有雷区。 百亿补贴会员可以每天打卡拿积分换取优惠卷，30-5对买粮农有帮助，菜报告不在百亿补贴里所以用不到，菜报告需要到七夕大促（没隔一段时间标题不同）中砸蛋领卷或者整点抢卷里获得低价券。 整点抢卷里每天都可以兑换678折优惠卷，这些卷可以降低菜报告套餐的价格，建议将菜报告套餐收藏，这样可以刷的快点。 我领了6折卷9包价格就是16.68，而且这个券每天都可以领，除非商家涨价，不然一直是这个价格。 99 个帖子 - 70 位参与者 阅读完整话题

13. 13
    佬们，想换工作了，怎么学习 AI Agent 开发呀

    请教一下各位佬，现在想转行做 agent 开发，有没有推荐的学习路径呀 培训机构 实战书籍 学开源框架源码 或者其他 佬们有没有经验可以分享一下呀，目前是前端转全栈了 我把目前收集到的和佬们推荐的列一下，方便各位佬一起学习： 免费在线阅读： AI Agent 开发项目实战 – 李文周的个人站点 （@it_wangxiaobai 佬推荐） AI 智能体实战速成指南：从零到企业级落地 | ai-agents-from-zero （@tensor 佬推荐） 深入理解 AI Agent - AI Agents in Depth （@miracle_c 佬推荐） Hello-Agents AI Agent 架构：从单体到企业级多智能体 | Wayland Zhang AI Agent Guide - 通识教程(@bin10 佬推荐) AI 工程从零开始(@bin10 佬推荐) Agent 工程哲学(@bin10 佬推荐) Pi Agent Book(@bin10 佬推荐) pi agent blog(@bin10 佬推荐) Learn Claude Code(@bin10 佬推荐) Learn Claude Code(@bin10 佬推荐) Learn Agent the Hard Way(@leihb 佬亲自出品) 收费课程： Agent 设计模式之美 （@dxmy 佬推荐） 54 个帖子 - 37 位参与者 阅读完整话题

14. 14
    基于cot和juice的gpt5.6sol检测方式，从此告别掺假！[附实战案例]

    本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 github.com GitHub - chen-006/gpt56_api_detector: 用于检测api是否路由真实gpt5.6模型 用于检测api是否路由真实gpt5.6模型 使用方法：下载最新版本Releases(Releases · chen-006/gpt56_api_detector · GitHub) 基于什么原理做的检测？ 1：基于cot的检测。 2：juice number检测 目前有综合检测（两种方法都用）和juice only两种检测方式 最重要的：还支持持续监控，防止渠道时不时掺水，对于聚合站点上游的监测也很有帮助。 项目大概就是这样，介绍完了。 接下来顺便跟佬们分享两个实战案例 大约是7月25号的时候我用juice测出了aihub @AIHUB 聚合站的a014分组sol路由了luna。当时我刚用aihub，也没有办法联系站长，于是只是在自己写的自动路由里拉黑了这个分组，没有管下去。 之后我一直有挂持续监控，持续监测aihub的低价分组。期间也没再出过问题，直到8月4号凌晨，ai跟我报告又出了问题 我一查，发现又是这个a014分组的。于是又联系了站长，从截图看这次上游疑似又甩锅更上游，还跟站长爆发了一定程度的冲突。并且这次上游还使用了更恶劣的脚本随机路由 最后大家不要误会，这个aihub是一个聚合很多上游的“二次中转”，据我实测下来，出问题的上游分组只是极少数，而且站长非常负责任，此次事件之后估计也永久拉黑a014分组了。 51 个帖子 - 29 位参与者 阅读完整话题

15. 15
    【CHY公益站】本公益站没有闭站计划

    大概是昨天晚上 10 点到 11 点左右发生的事 幸好年轻人精力旺盛，不然我也要被折腾的关站了 64 个帖子 - 57 位参与者 阅读完整话题

16. 16
    关于这位佬要的解释

    从那个最帅的男人的星辰站，出来解释下呗？继续讨论： 从关于这位佬要的解释继续讨论： 今天上午我也自测了一下，给大家看一眼 记住这个时间 2026-08-06 11:59:00 最后看号池日志 结束，接着奏乐接着舞 给看不懂的佬稍微说明下，之前那个帖子拿着 GitHub - chen-006/gpt56_api_detector: 用于检测api是否路由真实gpt5.6模型 · GitHub 所以，这个开源项目的监测结果是不准确的，如果说他是准的，那就是在说奥特曼掺假。 （点击了解更多详细信息） 我几万B的tokens都送出去了，我犯得上掺假吗，服了 我刚开始想着反正没多少钱，直接给各位佬把这个钱退了，反正我亏得起，刚才找上游要了号池截图和吐字速度对比，是没有问题的，而且之前大几千人民币的codex都给我白跑了，根本犯不上掺假 我欢迎各位佬本着真诚友善的态度探讨这个问题，可是那个帖子下面已经成什么了 我无意挑起任何社区矛盾，我也不想掺和任何人的个人恩怨。 如果还有哪位佬还有疑问，欢迎私信我 104 个帖子 - 80 位参与者 阅读完整话题

17. 17
    【公益推广】方舟公益站

    本帖使用社区公益推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的项目是免费使用的，无收费（变相收费、赞助）部分： 是 我的帖子已经打上 公益推广 标签： 是 我的项目属于个人项目，与公司或商业机构无关： 是 我的项目不存在QQ、TG等群组引流： 是 我的项目不存在非运营必要的网站引流： 是 我的项目不存在为他人推广、AFF： 是 我的项目无关联的商业项目： 是 我的站点存在登录，并已接入 LINUX DO Connect： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 方舟公益站主站：https://new.bxacc.xyz/ https://us-new.bxacc.xyz/ https://auto-new.bxacc.xyz/ 注册提示429是因为我这小破服务器人太多炸了，稍等片刻就好了。 api调用推荐使用负载均衡节点，另外两个节点做备用，负载均衡无法使用（或速度过慢）时请使用其他节点 目前模型主要是deepseek-v4-flash，其他模型都不太稳。 站内联系方式已删除整改，请管理员重新审核谢谢！ 模型有GPT5.6 克劳德等等，模型如图： 110 个帖子 - 81 位参与者 阅读完整话题

18. 18
    TrueSOTA API中转站公测，注册送 20 刀

    各位佬友好，我们是个创业团队，平时也重度使用 Codex、Claude Code 这些 Agent。 TrueSOTA 最早是搭给团队内部用的。此前买过不少 API，也见过中转站里线路不稳、模型质量不一致、出了问题找不到人的情况。折腾久了，我们干脆自己维护了一套，现在开放出来给大家试试。 官网：https://true-sota.com/(需 Linux.do 登录才能领额度） 新站靠吹牛证明不了什么，先把目前能做的说清楚。 客服问题有跟踪 遇到故障或调用问题，可以直接联系 Discord 客服，处理进度都公开可见；能解决的尽快处理，涉及上游的也会持续跟进，直到有明确结果。 Discord： TrueSOTA 官方账号池，稳定优先 目前采用 ChatGPT 官方账号池。价格会贵一点，因为我们不碰高风险账号，也不追求很大的账号量，先把现有线路维护稳定。 价格和退款规则简单 ChatGPT 统一 1 x 倍率，订阅折算下来约等于 0.5x-0.7x 倍率。充值和订阅都支持按使用比例退款，用掉多少算多少，剩余部分可以退。 支持 Linux DO 一键登录 登录后创建 API Key 即可使用。 注册直接送 20 刀 不用抽奖，也不用先回帖，登录 Linux.do 注册后额度直接到账:https://true-sota.com/ 我们已经把稳定和服务放在前面，但中转站还应该做好什么，自己猜总归不准。领到额度的佬友，麻烦回来吱一声，顺手回答两个问题： 1. 目前主要使用什么 Agent 工具？ Codex / Claude Code / Cursor / Cline / OpenCode / OpenClaw / 其他 2. 除了稳定和服务，希望网站尽快增加或改进什么？ 具体模型 / 价格套餐 / 用量统计 / 团队管理 / 状态页 / 其他 缺什么、哪里不好用，都可以直接提。 赠送额度用完后，可以先从 6.9 元套餐开始，小额试用，合适再续，不建议一次多充。 250 个帖子 - 202 位参与者 阅读完整话题

19. 19
    都在聊公益站，我聊聊liWAN公益站

    “你搞这个赚钱么？” 我并非科班出身，AI也只是兴趣，加入L站是慢慢了解、使用AI后才听说的论坛，加入L站后，我最爱逛的是“人工智能”、“原创”两个标签板块。 大家分享着自己的开源项目、交流自己的技术经验，虽然我看起来很吃力，也是回味无穷。 “人工智能”标签板块下时不时会看到一些公益站的帖子，我也曾慢慢攒ldc兑换了第一个公益站的邀请码，所以我非常明白ldc的来之不易。 我非常感谢我曾使用过的公益站，包括不限于冰、君の公益、黑与白、薄荷、小鸡毛等，是他们让我在使用AI时有了试错的机会。 好像有些跑题…因为我在跟我老婆逛街，她在试衣服，我无聊编的。 说回我的公益站，它是在6月18日开的站，开站后正如一些佬的“公益站生命周期循环”总结一样： 大家都搞公益站我也搞一个。 哈哈哈！抽象又现实。 开头也说了，我并非科班出手，面对太多人注册和小鸡顶不住，我是真的毫无招架之力，不过好在有一些佬的公益站，问问gpt、问问claude，勉勉强强维护下去了… 开LDC邀请码后，我是满满的罪恶感，因此有了“活力格”的诞生，它的初衷非常简单，我害怕大家因为使用LDC购买邀请码后当个囤囤鼠，一点都不去用token，我是真的害怕到时候上游拉闸了各位佬用不了。 慢慢的维护，公益站存活快半个多月，而半个多月我拒掉了很多商单，老婆说我总是搞这个还不赚钱，天天熬夜，干脆别搞了，我想也是，就发了个帖子说准备跑路。 跑路还没2天，Hermes在微信给我推了个渠道（以前写的定时任务每天去自己采集渠道），liwan 原地复活了。剧透 从开站到现在也马上快两个月，时间过得好快啊，商单也在慢慢恢复接单，抽空的时候维护下渠道和公益站，嗯！蛮好！ 现在隔三差五的出现LDC与公益站有关的讨论帖子，几乎都是因为所谓的“高额LDC”。 我想说，大家都是成年人，有最基本的判断能力，公益站能不能用，站内的搜索、公益站的模型广场，都能够体现，再不济找管理员反馈，论坛是包容的，说明你的原因，就像当初加入L站要写申请一样，我想，管理员肯定会给你一个交代。 L站不只是有公益站和羊毛，它还有其他的内容，我讨厌现在的公益站氛围，我更讨厌那些“做臭”公益站的** 我自己的公益站已经停止了注册，就让它变成最初的样子吧，如果哪天我真的维护不下去了，只能提前说抱歉，我会退你们ldc的。 在另一个话题中 8 月 4 日 点 22 点更帖： 每隔几天就有 ldc 和公益站之间的小事讨论来讨论去 peace&love 55 个帖子 - 50 位参与者 阅读完整话题

20. 20
    快来领mac mini啦，领完为止，AI面试工具gankinterview强势回归！！！

    去年熟悉的佬友都知道我们是从L站起家的，又到了一年秋招季，为了感谢佬友们的支持也为了实现去年的承诺，比较遗憾我们没有营收1500w美金，出海比我们想象的要困难太多太多，流量很贵很难我们完全没有出海运营的经验导致出海数据惨不忍睹最后关掉了海外站，但是诚意满满地给大家带了mac mini抽奖活动。欢迎大家继续关注并支持AI面试工具gankinterview[https://www.gankinterview.cn]。 抽奖活动介绍： 从帖子发出开始直到公示活动终止，在本帖下面留言的佬友即有资格参与抽奖活动（也就是回帖越早参与抽奖的次数越多，赶紧动动手指顶起来吧）。 每两周抽奖一次，每次奖品有： 一等奖：26年最新款mac mini一台（价值5999元）； 二等奖： gankinterview 年旗舰会员2个（价值1199元）； 三等奖： gankinterview 月旗舰会员10个 （价值199元）； 为保证抽奖真实性要求中一等奖的佬友单独发帖开箱mac mini以证明真实性。 1588 个帖子 - 1550 位参与者 阅读完整话题

21. 21
    Pi + DeepSeek-v4-Flash ，用起来好爽

    今天我们来聊一下 Pi ，Pi 这个 Agent 我也是想写很久了。 如果你刚接触 Pi，就暂且可以先把它理解成一个运行在 CLI 里的 Coding Agent，它的设计逻辑就是四个字 — 极简内核。 极简到像是只有内核的 Linux 0.11 。 Pi 本身只有最基础的 read、bash、edit、write 等基础工具。 如果你需要 skill 和 MCP ，你得自己装。 这篇文章我就先跟大家聊聊 Pi ，然后说一下如何接入 DeepSeek，再根据一个我实际的场景跑一下 Pi + DeepSeek-v4-Flash 的能力。 Pi 是什么？ Pi 的官方定位是 minimal terminal coding harness，也就是最小化的 Coding Agent 。Pi 的重点在于 harness：它负责运行模型、提供工具、保存会话，并允许你替换或扩展几乎所有工作环节。 一个最基础的 Pi session 的工作流如下： Pi 的核心只提供少量文件和 Shell 工具。很多 Coding Agent 有的 Plan Mode、Subagent、浏览器自动化、WebSearch 和自定义状态栏等能力，需要通过 Extension、Skill 或 Package 来进行添加。 Pi 的这种设计与 VS Code 有些相似：优先提供编辑和运行框架，想要啥自己通过插件的方式进行拓展。 五分钟搞定 Pi 的安装 废话说的有点说了，下面直接跟大家说如何安装。 一句命令的事儿： npm install -g --ignore-scripts @earendil-works/pi-coding-agent 进入项目后启动： cd your-project pi 就完事儿了。 你看看这个主页，真 TM 极简了，连个 Logo 都没有。。。 第一次启动可以执行： /login 登录模型供应商或订阅 /model 选择模型 /settings 设置主题、thinking 和消息模式 /hotkeys 查看快捷键 几个最常用的操作： Shift+Tab：切换 thinking level。 Ctrl+L：选择模型。 Escape：中止当前运行。 Ctrl+O：展开或折叠工具输出。 输入 @：引用项目文件。 /resume：恢复以前的会话。 /tree：回到会话中的任意节点并创建新分支。 刚开始时不需要安装任何插件，直接先上手体验。 把 DeepSeek-v4-Flash 接入 Pi Pi 的自定义 provider 都写在 ~/.pi/agent/models.json，往 providers 里加一个 deepseek 就行，支持 OpenAI 兼容 API： { "providers": { "deepseek": { "baseUrl": "https://api.deepseek.com/v1", "api": "openai-completions", "apiKey": "sk-你的key", "authHeader": true, "compat": { "supportsStore": false, "supportsReasoningEffort": true }, "models": [ { "id": "deepseek-v4-flash", "name": "DeepSeek V4 Flash", "reasoning": true, "input": ["text"], "contextWindow": 1000000, "maxTokens": 65536, "thinkingLevelMap": { "off": null, "low": "high", "medium": "high", "high": "high", "xhigh": "max", "max": "max" } } ] } } } thinkingLevelMap 是精髓：DeepSeek 只有 high/max 档，Pi 的 low/medium/high 都会映射到 high，xhigh/max 映射到 max。 apikey 可以像我一样从钥匙串里面来读： "apiKey": "!security find-generic-password -a lx -s pi-deepseek-api-key -w" 把 key 存进钥匙串就一行： security add-generic-password -a lx -s pi-deepseek-api-key -w 'sk-你的key' 然后 ~/.pi/agent/settings.json 把默认值改成 DeepSeek ，之后每次开 Pi 就是 DeepSeek： { "defaultProvider": "deepseek", "defaultModel": "deepseek-v4-flash", "defaultThinkingLevel": "xhigh" } 保存后重启 Pi，用 /model（或 Ctrl+L）就能在 DeepSeek 和 GPT 之间一键切换，不用改任何配置。 上手干了第一个任务，就是排查 Codex Plus 的用量问题，用 DeepSeek 排查 Codex 的用量问题。。。。xs 。 我发现最近 Codex plus 的额度非常不够用，自从我没有用 Codex app ，用上 Pi + CPA 接入 GPT-5.6 以来，在一堂大课的时间，我就夯满了一个 plus 号的周额度。 我非常纳闷，为什么会这么费额度？我一度让我怀疑是被人偷额度了，于是我让 DeepSeek 排查了一下原因。 最终排查结果：没被盗，就是我一个半小时自己烧完的。 整个排查过程让我感觉很好的一点是，DeepSeek-v4-Flash 会自动识别路径依赖，自动判断这条路是否正确，不会走的太深，判断错了自动更正。 下面就是一个它当时自动判断的真实思考过程。 DeepSeek-v4-Flash 的完整报告如下。 这次排查过程还是真香，一顿排查花了 20 M token，费用才不到 1 块钱。而且速度还快。 我想到了之前有人在 *乎上提到了一个问题，我的回答是： 说几个 Pi + DeepSeek-v4-Flash 用的顺手的地方： 便宜：20M token 不到 1 块钱，同样的排查量级，GPT 那边是直接烧掉半个 plus 号的周额度； 1M 上下文：支持长项目和长报告。 路径纠错：干活的适合发现走错路会自动退回来换一条，不会一条路走到黑，这有点像真实人类的排查过程了。 无缝切换：支持多 Provider 和模型切换。 我觉得以后 GPT 的号就留着干重活，然后我的日常基座就是 Pi + DeepSeek-v4-Flash 了。 这个日常只截止到 DeepSeek-v4-Pro 的发布之前 ：） 本来这篇文章写完就要发了，然后看到 DeepSeek 的消息 ，要涨价了。 尼玛。。。。。。 这篇文章我现在撤回还来得及么？ 83 个帖子 - 56 位参与者 阅读完整话题

22. 22
    L站首发图片在多个平台被搬运的记录

    昨天晚上，我 vibe coding 画了一张说明 DeepSeek V4 Flash 更新后性价比的示意图： DeepSeek V4 Flash 0731 肘击 GPT & 最新斩杀线 直观示意图 开发调优 [artificial-analysis-all-models-4k] 结果第二天早上，就在 X 上刷到了改图： 打开L站，还看到了内销转出口再转内销： DeepSeek 毒圈/斩杀线，直观形势图 国产替代 还给标出来了（高亮的矩形里，都中毒了） 不知道 DeepSeek V4 Pro 正式版会把这个矩形拉到什么面积，求矩形（中的模型）的阴影面积 智普必须开始跑毒了 [image] PS:出口转内销了 出处在这里：DeepSeek V4 Flash 0731 肘击 GPT & 最新斩杀线 直观示意图 掉入deepseek斩杀线的模型，已经不需要了 搞七捻三 [image] 这使我好奇，各大平台搬运这张图的时间顺序是什么样的。 下面是我已知的发现： 当前晚上，就被搬运到 X 第二天凌晨，出现在了小红书 到了上午，出现在了抖音 到了下午，甚至4chan都有了 可以看出，X 和 小红书 大概是本坛以外 AI 信息最快的平台 我能找到的还十分有限。欢迎大家补充更多被搬运的情报，看看更多平台的信息是怎么流转的 44 个帖子 - 41 位参与者 阅读完整话题

23. 23
    我也聊聊我的公益站

    随便聊一聊公益站吧 搞七捻三 “公益站评分”真的有必要吗？揪出坏人或许可以换一种方式 运营反馈 hlool公益站其实做的时间不长，到现在都是小站 没有这种太大的必要。 我觉得这个积分放在这里比较好看，说不定哪天可以在 L 站买房。 因为像智谱、Kimi 还有 MiniMax 那个时候的价格说实话不算特别高，给的量也相对还可以一些，也没有那么多的限制。 但是 Coding plan 这个东西，就在我开始做测评站之后两个月左右，就已经开始恶劣的生存环境了： 先是从阿里开始带头，把这个东西变成了 token plan，又搞了这些七七八八的限制； 加上智谱之类的各种封号。 这导致我想要做的国模公益站，提前放弃了想法。 第一轮 Bug Team： 第二轮 Bug Team（我当时用的那一轮）： 我的公益站是在这一轮开启的： 一开始，我的公益站全部都没有收 LDC，因为我不确定公益站什么时候会关。在 Bug 第一天的时候，我确认了一下，发现这个还蛮持久的。 到了第二天，有人建议我开一下 LDC 兑换。因为当时 100 刀大家很快就跑完了（我是给每一个进站的都送了 100 刀），所以我就开了 LDC 的兑换码。结果开完之后，大概买了几个我也没什么印象了，但是卖出去蛮多张额度卡。有的找我退了，也有一部分没有退。在 Bug 结束之后，没办法，我就闭站了。 但是，有消费过 LDC 的用户还是有几个的，他们也没有发起退款申请，所以我觉得很不好意思。我就发帖说，之前有付费或者付过 LDC 的用户，我就用我的 PRO 号，把你们所有的额度都消耗完。 在这个期间，我又去了解了一些其他的渠道，比如 Plus，包括第 3 轮的 bug team（也就是现在炸弹车的前身）。 公益站开的是 LDC 付费，采用邀请制，每个人买的是兑换码。一开始设置的是 20 LDC，一路涨价到现在是 688 LDC。差不多有半个月左右，没有拉新的邀请码进来了。 那天纯粹是因为我自己开了一些 Plus 号。那时候 Plus 号的成本还是比较低的，大概五六块钱一个，相比于 Bug Team 会好一些，Bug Team 那时候都是一天两天左右才会炸。plus号的话可以用一周。我就觉得，如果放到公益站里边，因为那个时候公益站的人不是很多，但如果我开放的话，消耗额会很大，我自己又吃不下这么大的量。 所以我就想着，要不然就发到“扬帆起航”去，按照 0.01 的价格卖出去。反正其实也等于是公益了，只是价格比较便宜一些，这是我自己的心里想法。 我那个时候是想着：如果我卖这么低的价格，会不会很容易就把这些号消耗完了？那我能不能稍微回一些本，或者学习到一些做低价中转之类的技巧？可不可以再去管理更大一些的号池？ 结果就是我发了“扬帆起航”，连续吃了好几个举报，帖子被下掉了。当天心里有点难受，感觉我平常也是做公益的，发这种东西也不是不尊重论坛的举报机制。 不过，我觉得这种东西吃举报也正常，确实也不好。因为一边开公益站，一边在“扬帆起航”里面再去卖，那还不如大大方方直接开一个“富可敌国”呢。 所以就有了帅站。一直开到现在，这个公益站也一直坚持到现在，每天也能稍微跑掉一些量。因为没有什么时间去维护，所以公益站那边直接接了帅站这边最便宜的 API，稳定性也是一致的。差不多就是这样，这就是我公益站一直开到现在的历程。 我主要想说的是，关于公益站收 LDC 的问题。说实话，如果让很多佬友浪费自己的 LDC 在一些没有用的公益站上，确实不太好。虽然我的公益站也没有做到百分之百稳定，但 LDC 毕竟是大家的心血。 对于新开的公益站，可以考虑不一定都要收 LDC。我觉得收 LDC 的站点应该具备一定的稳定性，最起码要让大家能把充值的额度消耗完。当然，这也是因为我在 LDC 收费前，就已经针对防止积分滥用、倍率乱飘的情况提前做好了预案。比如说，我的公益站签到的金额是每天消耗的，其他有的没的的倍率之类的也都是动态去进行调整的，所以我的公益站会相对于健康一些。 很多佬友可能说，开公益站的时候是一时脑热，没有对积分之类的做限制，导致积分或者签到积分膨胀得非常快。 公益站这个东西本身是好的，但是如果变成用来收割 LDC 的工具，那我觉得就不是很好啊。当然，这个东西也看个人动机，每个人有自己的行为准则，我也不好过多评价，这只能代表我个人的意见想法。 晚一点的时候，发一点邀请码吧，看一下有没有有需求的，可以蹲一下。你好，我的供应站不是说是百分之百调用成功的，因为也是目前的炸弹车。 反正你正常去我帅站用的话是 0.08 倍率，在我公益站里面用的话是 0.6 倍率，但是是 3 LDC 兑换 1。 直接拿钱在我那个 3a 站充也差不多啊，反正看大家自己的需求。我一向都是，包括商业站也好，公益站也好，大家都是量力而行，有能力就上，没能力就不要上。 稳定性我们没法打包票，但是能不能一直做下去，或者说在没有渠道假设断供的时候，一旦有渠道会不会恢复。这个我可以比较肯定地说，那我会恢复，不会全嘎的。 希望L战可以向上向好发展，大家还是减少一些相关的争议吧。 如果还是有很多老站长愿意去开公益站，大家可以提前参考一下我的做法：不要让积分膨胀得太快。因为积分膨胀太快的话，会导致你兑现不起，也会影响你自己的羽毛。我反正会比较爱惜我的羽毛，我对自己的声誉和相关评价会比较在意。我很难接受挨骂。 75 个帖子 - 69 位参与者 阅读完整话题

24. 24
    Pi个人扩展设置与讨论

    对pi使用过程中的一些个人经验和理解，欢迎各位佬友前来讨论！ 如果有佬友不熟悉pi的话可以直接在站内或者网上搜，有非常详细的文字，这里就不再做赘述。简单来说，pi就是一个harness的最小实现，具有read, write, edit, bash四个默认启用的功能，没有subagent，没有mcp，这些都可以通过社区或者自己直接向模型提需求拓展出来。以下是pi package的官网： Package Catalog · Pi 那么接下来就先介绍一下我个人的一些extensions 扩展介绍 @narumitw/pi-btw · Packages · Pi 首先是类似Claude Code的一个对话底部栏，使用/btw启动，可以在主对话运行过程中创建一个side thread，启动时读默认截取最多40,000字符作为背景，可以单独设置回答模型和思考强度，是独立的并发请求，回答不会污染原本上下文。适合在执行任务期间问一些问题，但又不希望这些内容进入主对话，比如：xxx函数的作用是什么？ @gotgenes/pi-permission-system · Packages · Pi Pi和其他不coding agent不一样，没有权限管理，默认是yolo模式，这个扩展可以给pi加上权限管理，并且可以自定义权限，以下是我的配置（这里我使用ffgrep和fffind替代了原来的grep和find，所以把这两个命令也禁用掉了），使用下来不会像Claude Code一样一直点yes，但也没有codex那种自动审核功能，部分命令还是需要需要自己点确认，这个可以按自己的喜好更改配置。 { "$schema": "https://raw.githubusercontent.com/gotgenes/pi-packages/refs/heads/main/packages/pi-permission-system/schemas/permissions.schema.json", "debugLog": false, "permissionReviewLog": false, "yoloMode": false, "permission": { "*": "allow", "grep": "deny", "find": "deny", "external_directory": { "*": "ask" }, "path": { "*": "allow", "*.env": "deny", "*.env.*": "deny", "*.env.example": "allow", "~/.ssh/*": "deny", "~/.pi/agent/auth.json": "deny", "~/.pi/agent/models.json": "deny", "~/.pi/agent/models-store.json": "deny", "~/.pi/agent/settings.json": "ask", "~/.pi/agent/trust.json": "ask", "~/.pi/agent/SYSTEM.md": "ask", "~/.pi/agent/APPEND_SYSTEM.md": "ask", "~/.pi/agent/npm/package.json": "ask", "~/.pi/agent/npm/package-lock.json": "ask", "~/.pi/agent/extensions/pi-permission-system/config.json": "ask" }, "bash": { "*": "allow", "cmd *": "ask", "cmd.exe *": "ask", "CMD *": "ask", "CMD.exe *": "ask", "powershell *": "ask", "powershell.exe *": "ask", "PowerShell *": "ask", "PowerShell.exe *": "ask", "pwsh *": "ask", "pwsh.exe *": "ask", "Pwsh *": "ask", "Pwsh.exe *": "ask", "bash *": "ask", "sh *": "ask", "dash *": "ask", "zsh *": "ask", "fish *": "ask", "rm *": "ask", "del *": "ask", "erase *": "ask", "rd *": "ask", "rmdir *": "ask", "mv *": "ask", "git clean *": "ask", "git reset --hard *": "ask", "git checkout -- *": "ask", "git restore *": "ask", "git branch -D *": "ask", "git stash drop *": "ask", "git stash clear *": "ask", "git push *": "ask", "gh pr create *": "ask", "gh pr merge *": "ask", "gh pr close *": "ask", "gh release create *": "ask", "gh release delete *": "ask", "npm publish *": "ask", "pnpm publish *": "ask", "yarn npm publish *": "ask", "cargo publish *": "ask", "twine upload *": "ask", "ssh *": "ask", "scp *": "ask", "sftp *": "ask", "curl *": "ask", "wget *": "ask", "npx *": "ask", "pnpm dlx *": "ask", "yarn dlx *": "ask", "bunx *": "ask", "uvx *": "ask", "npm install *": "ask", "npm i *": "ask", "npm ci *": "ask", "npm update *": "ask", "pnpm install *": "ask", "pnpm i *": "ask", "pnpm add *": "ask", "pnpm update *": "ask", "yarn install *": "ask", "yarn add *": "ask", "yarn up *": "ask", "bun install *": "ask", "bun i *": "ask", "bun add *": "ask", "pip install *": "ask", "pip3 install *": "ask", "python -m pip install *": "ask", "python3 -m pip install *": "ask", "py -m pip install *": "ask", "uv add *": "ask", "uv sync *": "ask", "uv pip install *": "ask", "pipx install *": "ask", "pipx run *": "ask", "cargo install *": "ask", "go install *": "ask", "gem install *": "ask", "grep *": "deny", "find *": "deny" } } } @ff-labs/pi-fff · Packages · Pi 也就是前文说的ffgrep和fffind，相比原来的grep和find速度提升了许多，非常推荐。 pi-context-view · Packages · Pi 一个查看上下文占用的小工具，/context injection可以看到完整的system prompt, tool definitions等，界面做的也挺不错 pi-workspace-history · Packages · Pi 可以实现Claude Code上/rewind的效果，回溯对话状态和文件修改。他使用的是shadow git，不需要项目本身有git即可运行。但他原本是基于pi的tree功能（这是pi非常好用的一个功能，下面会详细讲到）实现的，我不希望在使用/tree的同时回溯文件的修改（原因下文会讲到），所以我稍微做了一下修改，用/rewind代替了原来的/tree功能，/tree保持原有功能。使用过程中应避免在用户根目录这类目录下启动pi（默认排除根目录），或者当文件夹内有多个.git目录时也不会启用。 tree功能 Pi的tree功能很多人都说好用，但我很少看到有人说为什么好用，我来谈谈我的看法。首先，使用pi内置的/tree命令可以选择一个节点（可以是user message，assistant message或者tool result，可以多次重复选择一个节点），生成一个branch，该branch会携带到该节点之前的上下文内容（可以选择summary或no summary, 这里summary可以选择custom prompt，我一般选择no summary），这样就在一个session内完成多项任务，避免重开一个session浪费无谓的token重新了解文件结构或其他。适合的场景有：开发项目时，在模型了解项目结构和代码的节点，获取干净的上下文进行各自独立的功能开发；或者了解一份项目、一篇文章，进行独立的提问（相比btw，这些问题、过程和结果都会完整写入transcript）。 关于subagent 相信有佬注意到了我的扩展里并没有装任何关于subagent的扩展。对于这一点，我的看法是，首先，subagent会引入大量的依赖，这与pi的极简理念相违背，并且pi的作者也认为subagent是"a black box within a black box"；pi本身就是完全透明的，并且在一些文献，比如 Towards a Science of Scaling Agent Systems也指出，对于一些工具密集型，推理链长的任务单agent表现已经足够好，某些任务引入多agent效果可能更差。 skhoroshavin/pi-supergsd，这个项目就是基于pi的tree功能实现了一个伪subagent的效果，思想很不错。项目是几个月前写的，内置了定制的superpowers skills，如果佬们觉得对于现在的模型superpowers太重了，可以酌情删除，或把思想借鉴过来融入自己的skill（我就借鉴他的思想修改了一下matt的code-reviewer）。对于第二点，我需求不是很大，目前还没想到特别好的方法，也许可以使用herdr或是其他？所以当前我就是用supergsd来替代subagent，轻量且透明。 上下文管理 上下文管理我觉得是使用agent过程中的一个很重要的部分，会直接影响到模型表现。不知道什么原因，我总觉得pi的上下文涨的特别快，这一块我还没具体去深入，不知道有没有佬友知道原因，或者是我的幻觉？ system prompt Pi的system prompt是可以完全自己定制的。相比其他厂商，pi默认的提示词少的不只是一点，对比了一圈下来，grok build的提示词是相对较少的，但也比pi多了不少。感兴趣的佬友可以看 https://phistory.cc/ （这也是普适性和个性化的区别，比如Claude Code就强调了很多安全性的东西，包括一些政治正确的东西，比如代词的使用；codex就对形象，以及回复的语气进行了大篇幅的描写）。我直接用SYSTEM.md替换了原本的提示词，加入了个人的一些习惯： # System Prompt You are a coding agent Pi that helps users complete their tasks using available tools. ## Working Rules - Do not assume file contents, code behavior, or task scope. Verify with tools first. - If something is genuinely ambiguous and affects the result, ask the user rather than guessing. - Stay strictly within the requested scope. Do not modify unrelated files or make unrelated refactors, cleanups, formatting changes, or fixes. - Do not silently remove explicit requirements. If a simpler solution cannot fully satisfy them, ask. - Lead responses with the result. Be concise and avoid unrequested design essays or feature tours. ## Tool Use - Keep tool-call narration brief. - Prefer specialized tools over shell equivalents: - Use `read` to inspect file contents instead of `cat` or `sed -n`. - Use `ffgrep` to search file contents instead of `grep`. - Use `fffind` to locate relevant files by name or concept instead of `find`. ## Engineering Baseline - Prefer deletion over addition. - For coding tasks, understand the affected flow before editing. - Fix root causes, not symptoms. Before changing shared behavior, inspect its callers and fix the common path when possible. 我还写了APPEND_SYSTEM.md对提示词做了补充，主要是参考了ponytail，他本质上也是通过提示词对模型进行软约束，我就直接迁移了一下，也修改了一些skill，比如code-reviewer，省的再多装一个插件了（使用APPEND_SYSTEM.md的原因是可以达到on/off的效果，和ponytail的区别就是无法选择强度了，一直都是full） ## Decision Ladder For coding tasks, stop at the first option that fully solves the task: 1. Does this need to exist? 2. Reuse an existing implementation from the codebase. 3. Use the standard library. 4. Use a native platform feature. 5. Use an already-installed dependency. 6. Use one clear line when it remains readable and correct. 7. Otherwise, write the minimum code that works. ## Complexity Constraints - Prefer boring code over clever code. - Avoid unrequested abstractions, single-use factories, single-implementation interfaces, speculative configuration, unnecessary dependencies, and scaffolding for future needs. - Use the fewest files and smallest correct diff. ## Non-Negotiable Boundaries Never simplify away: - trust-boundary input validation - error handling that prevents data loss - security controls - accessibility basics - correctness on relevant edge cases Non-trivial new logic should leave one minimal runnable check. Trivial changes need no extra test. magic context 链接是 GitHub - cortexkit/magic-context: Unbounded context. Memory that manages itself. One session, for life. The hippocampus for coding agents, part of CortexKit. · GitHub 这个也是之前站里的佬友推荐的，一般原生的压缩都是给一段提示词让模型自己总结，我觉得这种压缩效果很难评，会丢失太多东西，而且很模型能力也有很大关系。 一些讨论 当前我的扩展装的不多，一些常见的扩展比如mcp-adapter、todo类的我都没装，一方面是我当前没有遇到什么必须使用的mcp，还有一个就是佬友们认为todo对模型有实际的提升吗（magic context自带todo，但我觉得那个不太好，后面打算自己修改一下把todo、ctx_note、ctx_aug这些功能都去掉，明确一下边界，具体原因在这里就先不展开了）；还有一些，比如web-acccess我是想装还没装，佬友们使用下来感觉怎么样？还有一些修改tui的我也没看到满意的，以及整理tool output类的；还有关于trellis，我本来装了的，但感觉对于个人使用有点重了，佬们怎么看，有没有一些实践说明… 结尾 佬们如果有什么其他推荐的扩展或者skill都欢迎来讨论，也欢迎提出自己的看法与见解！ 94 个帖子 - 53 位参与者 阅读完整话题

25. 25
    点别家产品还是太有水平了藤子

    59 个帖子 - 51 位参与者 阅读完整话题

26. 26
    [AIHUB]关于投毒事件,我们的回应

    从下午18:30分开始我收到了消息,说我们涉及投毒事件 我在服务器查到现在,没有任何结果。我突然发现这个事好像根本没法查,我们不保存上下文。怎么查？？现在复测肯定以及一定没有任何结果啊 我就开始在站内开始收集此次相关事件所有的消息 一家站外中转突然被爆投毒,然后他立马定位到了哪个上游并且拿到了他的信息？！我查了三个多小时一点信息都没有 难道你只有一家上游？ 紧跟着立马爆出AIHUB也是受害者还有另外4家 均为L站富可敌国？不是,你说我。我认为没毛病啊 我们全部都是接的上游 那么另外四家据我所知他们应该是自建号池吧 在这种时候 你被爆投毒 你精准定位这个上游渠道并且拿到他的信息还去服务器进行投诉 ok我也放一放 你是怎么做到在这个时候立马去站内充了5家站点进行测试的呢？？ ok,我再放一放！别家我不知道，我家二三十个分组,你挨个都测了吗？？这么短的时间内？？据这个公告描述,还需要再特定情况下才能触发。好 你测了我们家所有的分组 我再放一放 能提供充值记录 测试记录吗 我没法自证 直接捶我行吗 为什么事情发酵之后又把公告删除了呢？ 造谣一张嘴,辟谣说破嘴 我们站内的用户 连juice有变化都能测的出来(已进行1.5倍赔偿,上游问题) 被投毒居然不是用户发现的 是从这个公告发现"我们被投毒" 最后从逻辑上说 投毒在公益不是更合理？我不明白 但是我释然了 从开始的站点被DDOS，支付被DDOS，批量刷注册 还有啥招就来吧 45 个帖子 - 44 位参与者 阅读完整话题

27. 27
    【RAG】RAG，你真的了解RAG吗？RAG全链路拆解。

    引言 实在不好意思这么晚才更新新的文章……这几天忙的事情比较多所以就耽搁了，而且其实昨天就开始写了但是写了一半不小心退出了没保存还得重写(因为我一般在自己的博客平台写，没设置自动保存之类的功能)(悲)。今天给大家带来的是对于RAG全链路，从chunking、embedding、存储……到最终的输出给LLM充当证据生成答案，都会有所涉及。 此外，在这篇文章种我必须要反驳一个观点:所谓的RAG已死。自从2025一来，尤其是今年claude code的源码爆出后，每隔几天就会有一篇公式化的以“RAG已死”的文章出现在知乎/稀土之类的平台，我大致看过几篇，都是同一套打法:先以claude code使用grep或者那个karpathy的llm wiki为引子，公式化地讲解一下其技术原理，然后开始说RAG怎么怎么样弱势，RAG已死！这样的文章，既没有理解RAG的本质，也不理解他所提的这些技术和RAG的区别和联系，没有自己的思考，拾人牙慧(我去我太会用成语了)。“RAG已死”，本质上是个伪命题，本文就会单独开一章来反驳“RAG已死”这个观点。 RAG是什么 很多人对 RAG 的理解，仍然停留在“文档切分、向量化存储、相似度计算、Top-K 召回”这套传统流程上。虽然这确实是我们最常见，使用也最广泛的一套RAG框架。本文讲解的大部分知识点也会围绕这套传统流程来。 但严格来说，RAG 的本质并不是某一套固定工作流，而是一种更抽象的工程范式。RAG 是 Retrieval-Augmented Generation 的缩写，核心是“检索—增强—生成”：只要系统能够先获取外部信息，再将其用于增强模型上下文，并最终完成生成，就可以被归入 RAG 的范畴。比如说，skills的渐进式披露，Agent Memory都可以算是一种RAG。 因此，RAG 并不限定具体的检索方式，也不限定增强手段，更不限定它在系统中扮演的角色。它可以是传统的向量检索问答，也可以是 Agent 调用知识工具、数据库查询、搜索引擎检索、多跳推理或结构化数据增强。 chunking的艺术，怎么进行好的chunking chunking 是什么 我们都知道RAG的本质是给LLM提供一个外部知识库用来补充上下文，但是不可能直接把整个知识库(如一个文档)塞进模型的上下文，这样会隐藏关键信息，还会占用模型上下文窗口。因此我们需要将文档进行切分(即chunking)为一个个文段(即chunk)，这样方便将用户问题和各chunk一一比对，找出回答问题所需的关键信息(这个就是检索)。这就是chunking chunking的粒度 对文档进行chunking并不是随便切的，而是得先选好一个粒度，即切分出的chunk的长度，粒度太大或太小都会出现一系列问题，这其中的平衡需要仔细把握 chunking粒度太大 chunking粒度太大，会导致包含大量无关内容、向量语义被稀释、相似度匹配不够精准、占用更多上下文窗口、生成时容易受到噪声干扰等问题。这样说有点抽象，我们举个具体的例子来说明。假设有这样一个较长的chunk 1.本园安全措施保障绝对没有问题，动物没有出逃的可能性，尤其是小型草食动物大多被关押在不可触摸的封闭性环境里。因此，如果您看见路边有逃跑的兔子，请立刻带着您的孩子远离并报告工作人员，不要靠近，不要触摸，尤其是兔子发现并且开始高速靠近你的时候。 2.猿类的园区只有一条街道，且只展示猿类动物。如果您发现了两条街道，且展示动物包括兔子，请选择左边那条，并尽可能快速地结束对该园区的参观。 3.大象是一种体型巨大、有着扇子一般的耳朵、鼻子很长、腿粗得像柱子的生物，而且不是白色的。请确保你在大象园区看见的是且只有大象。 4.动物园的饮料店不提供“兔子血”，如果您在货架上看见了，请不要购买。 假设此时用户提问“动物园的饮料店提供哪些饮料？”，正常来说，模型应该会回复“文中没有说明饮料店具体提供哪些饮料，只明确说动物园的饮料店不提供‘兔子血’；如果在货架上看见‘兔子血’，不要购买。”之类的内容。 (作者脑子是不是有病) 但是，由于 chunk 过大，饮料店相关内容在其中占比很小，导致这部分语义在整体向量表示中的权重被削弱，进而出现所谓的“向量语义稀释”问题。导致后续的检索流程中，由于饮料店相关信息的向量语义被稀释，导致与用户问题的向量相似度不高，进而没有被模型选中补充上下文，最终导致模型不知道饮料店具体信息，导致回复质量下降。反之，如果稀释没那么严重，使得该chunk侥幸被选中，此时由于chunk较大，无关信息占比较大，模型生成时容易受到“大象”、“猿类”、“兔子”等信息噪声的干扰，导致回复质量下降；同时，由于chunk较大且无关信息较多，大量无关信息占用了模型上下文窗口，造成了资源浪费和成本上升。 chunking粒度太小 反过来，chunking粒度太小也会导致一系列的问题，如上下文不完整、代词，条件，结论可能失去指代关系、embedding 缺乏足够语义信息、需要召回更多片段才能还原原意 请立刻带着您的孩子远离并报告工作人员，不要靠近，不要触摸 且展示动物包括兔子，请选择左边那条，并尽可能快速 结束对该园区的参观。 3.大象是一种体型巨大、有着扇子一般的耳 可以看到，这些 chunk 都存在明显的上下文缺失问题： chunk 1 丢失了前提条件，例如“如果您看见路边有逃跑的兔子”，导致读者无法判断这条指令在什么情况下适用。 chunk 2 丢失了“那条”所指代的对象，例如“街道”，也没有完整保留“结束对该园区的参观”这一结论。 chunk 3 不仅丢失了前文条件，还出现了跨段截断，导致语义混乱。 不难发现，chunking的粒度是需要我们仔细把握，追求那个微妙平衡的，否则我们是绝对无法在动物园中活下来的！(0人懂你的梗) 追求结构化的chunking? 我们在实际使用RAG过程中，所使用的外部知识库通常不会是一大串文字，而一般是有结构性质的文档。此时，我们可以通过保留文档结构和层级信息，以增强后续检索效果，如下所示： 标题 1 标题 2 标题 3 正文 我们可以先以最小标题为单位进行切分，再针对每各最小标题下的内容进行按粒度的切分(其实也可以不继续切分了)，如下所示 { "document_title": "员工手册", "section_path": [ "第三章 财务制度", "3.2 差旅报销", "3.2.1 报销材料" ], "block_type": "paragraph", "text": "报销材料包括交通票据、住宿发票、行程单和审批单。交通票据有如下要求:……", "order": 35 } 我们一般会同时将chunk的所处章节信息作为chunk内容和正文拼接在一起进行向量化和作为筛选过滤条件单独存储。这样一来，既避免了一次chunk中混杂不同章节的信息导致关键信息被隐藏；也因为一chunk限制在一章节内，避免了上下文被中断；同时，当缺少证据时，可以依据当前检索到的chunk的章节信息，依此作为过滤条件筛选chunk进行检索以补充证据，避免了指代，条件，结论不明确的问题；我们还可以先让模型依据问题判断信息可能所处的章节，以此为过滤条件进行检索，有效地提高了检索效率，降低检索成本。真是一举多得啊! 看到这里的佬友可能会想到一个东西，skills的渐进式披露:当skills过多时，将各skills的简要功能介绍和所处位置集成为一个菜单，模型阅读这个菜单选择具体skill后再将具体的skill.md展示给模型。这和我们这里的结构化chunking是不是很像？skills的渐进式披露本质上也是一种RAG!当然这是我的个人观点，没有官方背书( PDF的chunking……？ 有时我们的外部知识库会是pdf格式的，此时就会复杂的多，因为PDF是为“呈现”而设计的，它记录的是字符在页面上的位置和绘制指令，本身没有段落、表格等语义概念。而且有时还会遇到PDF为图片无法直接获取文字，PDF内有图片，图片内有关键信息无法省略等问题。我们需要通过OCR等工具进行提取并使其格式化段落化。 广泛的支持格式：支持多种文件格式，包括PDF、Word (.docx)、PowerPoint (.pptx)、Excel (.xlsx)、HTML及图片等。 结构化输出：输出格式丰富，包括格式良好的Markdown、JSON（包含完整结构、表格、图像等）以及纯文本。 强大的复杂元素处理：能高精度地解析表格、图表和图像中的信息，并能使用OCR识别图片中的文字。 自然语言指令：以用自然语言告诉它如何解析，例如“这是一本漫画书，请按连贯的对话重构” embedding(嵌入) 文档完成 chunking 之后，就会进入 embedding 环节。Embedding 的作用，是将原本无法直接计算相似度的文本，转换成检索系统可以理解和比较的表示形式，方便后续进行召回、排序和匹配。 稀疏表示一般对应关键词检索，例如 BM25、TF-IDF、倒排索引等。它主要依赖词项是否出现以及出现频率来判断相关，更关注“用户问的词，在文档里有没有出现”。 稠密表示则通常指我们常说的向量 embedding。它会通过 embedding 模型，将文本编码成一个固定长度的向量，例如 768 维、1024 维或更高维。相比稀疏表示，稠密向量不只看字面词是否匹配，而是更关注语义是否接近。比如用户问“差旅报销需要哪些材料”，文档中写的是“出差后需提交交通票据、住宿发票和审批单”，即使两者措辞不同，稠密向量也有机会判断它们语义相关。目前常用的稠密嵌入模型包括BGE,GTE等等 稠密/稀疏embedding模型的原理 稠密embedding模型的原理大家应该一看就知道了:Transformer中的encoder部分，虽然以前也有使用BERT系的，但是现在主流的嵌入模型基本上都是使用的Transformer了，这里我们不多赘述。至于稀疏embedding模型的原理，我们以目前主流的BM25为例来讲解 q_i 查询词 D 当前被评分的chunk Q 代表用户的查询词集(由多个$q_i$组成) 我们来逐步讲解这个公式是什么意思： \text{IDF}(q_i) 用于衡量一个词的“稀缺性”或“重要性”，比如说，我们常见的“是”，“的”这些几乎每个chunk都会出现的词，其对文档之间的区分度就很小。如果不降低其得分，只要用户的查询中包含这些高频词，每个chunk的得分都会偏高。所以，对于常见的词，IDF值通常会较小。相反，一个只在少数文档中出现的词（比如一个专业术语），IDF值会很高，意味着这个词能更好地区分文档，提高其IDF值会提高查询该词时其所处chunk的得分，可以更快速的检索出其相关信息。 \text{tf}(q_i, D) 即词频，衡量一个查询词在当前文档中出现的次数。一个词在文档中出现得越多，文档与这个词就越相关，得分也就越高。 但是，如果不对词频对得分的贡献的增长速度加以限制，就会导致一系列问题，比如说，你向一个联网llm提问：“苹果手机质量如何”，llm提取到关键词“苹果手机”在网络上搜寻相关资料作为证据，此时有一篇小红书笔记A是针对苹果手机的细致评测，其中“苹果手机”一次出现20次，另一篇笔记B是一个神经病发的灌水贴，里面重复了“苹果手机”一词6767次，这就导致，如果不给词频得分的上限加以限制，此时笔记B的得分将会是笔记A的上千倍！这肯定是不合理的(这也是BM25之前的稀疏嵌入模型TF-IDF的问题所在)。因此BM25加入了一个参数k1，将公式转变为 \frac{f \times (k_1 + 1)}{f + k_1}(暂时忽略那一大串包含b的公式) 我们来看，当某个词在文档中疯狂重复，词频 f 趋向于无穷大（$f \to \infty$）时，这个值会变成多少： 分子分母同时除以 f： 当 f 无穷大时，分数 \frac{k_1}{f} 趋近于 0，所以整个式子的极限就是 k_1 + 1。 也就是说无论这个词在文档里出现 100 次、1 万次还是 100 万次，这个词频得分项永远不可能超过 k_1 + 1。 最后是长度归一化因子 \left( 1 - b + b \times \frac{|D|}{\text{avgdl}} \right) 其中avgdl为平均文档长度。 为什么要加入长度归一化因子呢？我们假设如下场景:用户向一个联网llm进行提问：“苹果手机性能如何”，假设llm不按粒度切分，而是按照网络搜索得到的文章为单位进行embedding，此时llm分别搜寻到知乎文章A，B，A在200字左右，其中提到了10次“苹果手机”，文章B2000字左右，其中提到了15次“苹果手机”，如果只看数量的话，文章B的得分势必会比A更高。但从人类的角度看，文章A中“苹果手机”出现的更密集，说明其主要针对苹果手机这一词进行撰写，而文章B“苹果手机”虽然出现次数多，但比较稀疏，可能就是一篇不同手机对比的文章。即使文章A可能针对性更强，但是由于B中词语出现次数更多，模型会更青睐B。文章越长，同一词语出现的次数是呈上升趋势的，因此不能简单的认为不同长度chunk下的同一词语出现次数的贡献是等价的。为解决这个问题，BM25引入了长度归一化因,使模型更加关注词语出现的密度。(我总感觉这一段我讲的废话好多( ) 接下来讲解一下为什么 \left( 1 - b + b \times \frac{|D|}{\text{avgdl}} \right) 可以实现长度归一化，我们用a来代换原公式中的 \frac{|D|}{\text{avgdl}}，可得1-b(a-1)，0 < a < +∞，可以发现，当chunk长度小于平均值时，a < 1，此时结果整体较小，由于这个结果是放在BM完整得分公式分母中的，因此最终得分会变大。反之，当chunk长度大于平均值时，该公式结果较大，作为分母会导致最终得分减小。这就实现了长度归一化。 稠密与稀疏同样重要 稠密和稀疏embedding基本上是同时需要的，它们各自优缺点鲜明，结合使用才能优势互补。假如只有稠密向量，可能会导致专有名词或少见名词的遗漏，比如说中药“石刁柏”，如果稠密embedding模型没有进行过专业的中药材方面的训练，在没有上下文的情况下，它很难想到石刁柏其实就是我们平常吃的芦笋。在具体chunk中embedding模型尚且可以根据上下文使得该chunk向量与芦笋靠近，但是在用户的提问中，没有上下文补充，用户提问的向量会偏向于“石头”，“柏树”之类的东西。最终导致模型无法检索到有用信息，导致回答质量下降。如果只有稀疏向量，面对同义词，模糊描述会导致检索不完全，而面对同名不同义的词，又会检索错误。因此，在普通的问答模型的RAG中，稠密与稀疏embedding都会使用。 存储 大型的RAG肯定是不能够直接用文件来存储的，一般会涉及到向量数据库的使用，常见的向量数据库包括Milvus / Zilliz、Chroma、Weaviate等等。它们之间的优劣这篇文章不涉及，因为其实我也不知道(? 索引算法 学过数据库的佬友都知道，索引是一种优化技术，旨在提高数据检索的速度。索引的核心作用类似于书籍的目录，它允许系统快速定位到数据的存储位置，而无需遍历整个数据库。同样的，为了提高模型检索效率，我们在进行向量存储时，也会用到一些专门的索引算法。包括HNSW,IVF,倒排索引等等，其实这一块不用太深究，大致知道有哪些索引即可。大家就当看个乐吧 HNSW HNSW是Hierarchical Navigable Small World的缩写，即分层可导航小世界，在后面的讲解中你就可以知道为什么这样起名了。 HNSW在内存中构建了多层图结构，每层都是一个网络（节点是向量，边是连接关系） 每个向量在插入时，会通过一个指数概率分布随机分配一个最高层级 L。这意味着大部分数据只存在于底层，少数数据会出现在高层。这些高层节点可以方便检索时快速导航最近的节点，并作为下一层的入口节点进一步寻找相近节点 HNSW的搜索过程就像开车去一个陌生地点，先从高速路走，再转入省道，最后进入小区小路 第一步：自上而下寻路 第二步：逐层精炼 第三步：底层精细搜索 HNSW的一个优势为查询极快，因为其不需要遍历全量数据，通过分层跳跃极大减少了距离计算次数。另一个是召回率极高，因为其底层包括所有数据，而且检索相当于从顶层向底层逐步逼近目标chunks，很少会遗漏相关chunk。 而缺点也很显而易见，HNSW中，数据库除了各节点的向量信息外，还要存储节点之间的连接关系，即邻居节点的指针，导致内存占用量极大。另一个是构建与更新速度慢，一个新节点加入后，要在其出现的每一层搜索与连接邻居，构建速度相对较慢。 IVF IVF更像是你在图书馆中找特定书籍，你会先去寻找该书的分区，再去分区特定书架寻找该书。IVF在构建时使用K-Means聚类算法，将全部数据向量划分为 多个簇。每个簇会生成一个中心向量，并建立一个“倒排列表”，记录该簇下所有向量的ID。 倒排索引 与HNSW，IVF不同，倒排索引是专门为稀疏（关键词）设计的精确数据结构，负责关键词匹配。 词项词典（Term Dictionary）：记录所有出现过的不重复关键词（比如“苹果”、“手机”、“芯片”）。 倒排列表（Posting List）：记录每个关键词出现在哪些文档中（以及出现的位置、频率等）。 检索流程非常直观：当用户搜索“苹果手机”时，系统直接在词典里找到“苹果”和“手机”这两个词，然后分别取出它们的倒排列表，最后取交集（或并集），就能瞬间锁定包含这些词的文档。再对这些文档打分取topk(打分算法就是我们之前说的BM25) 检索 说了这么多，大家应该也很容易明白检索的流程了，我们最常用的检索算法就是“双塔召回”，双塔结构顾名思义由两个对称的网络组成： Query Tower (查询塔)：输入用户提出的问题 q，输出一个固定长度的稠密向量 V_q。 Doc Tower (文档塔)：输入语料库中的文档/切片 d，输出一个固定长度的稠密向量 V_d。 这两个塔的目标是将文本映射到同一个低维连续向量空间中。如果查询和文档的语义相关，它们在该空间里的距离就会很近。这里的距离我们一般就使用欧氏距离/余弦相似度/向量内积作为标准。 查询优化 检索部分最重要的其实是这个 查询优化主要包括改写、扩写、重写、多查询、子查询和HyDE 多查询 多查询即用户输入一个问题，系统利用LLM自动生成该问题的多个语义相同、但表述方式不同的变体。保证召回率，如： 原始查询：“如何学习Python编程？” “Python入门学习路线” “零基础学Python的步骤” “Python编程自学教程” 子查询 有时用户一次性会询问多个问题，如果直接对整个问题进行embedding的话，会降低检索效果(这个应该不用我解释了)，因此需要LLM先把这些问题拆开来，一一进行检索。如： “2023年诺贝尔文学奖得主是谁？”（得到答案：约恩·福瑟） “约恩·福瑟的国籍是什么？”（得到答案：挪威） “约恩·福瑟的代表作有哪些？”（得到答案：《有人将至》等） HYDE 其实就是让LLM假装自己已经知道答案，如用户询问：“A是什么”查询时，大模型根据自己的知识生产一个伪文档，以“A是B”进行查询，提高召回率 重排(Rerank) 说了这么多，但我们之前的检索其实还是相当于一遍粗筛，根本原因还是在于“语义相似”不等于“问题相关”:检索找的是语义上相似的文档，但它们可能并没有直接回答用户的具体问题。同时，模型为了保证不漏掉任何信息，在检索阶段会带回大量文档（如Top 50-100）。这其中混杂着大量不相关的内容，如果全部塞给LLM，不仅会浪费其上下文窗口，增加成本，还可能让模型被错误信息干扰，降低回答质量。因此我们还需要进行重排。 我所熟知的重排方法包括两种，一种是Cross-Encoder(交叉编码器)，一种是基于LLM的重排。 Cross-Encoder（交叉编码器）模型：这是目前精度最高的方法。它将“查询”和“文档”拼接在一起，输入到一个模型中进行深度联合分析，从而输出一个精确的相关性分数。其代价是计算开销大、速度慢，通常需要对每个“查询-文档”对做一次独立的推理。典型代表有 bge-reranker(没错，bge到处都是) 系列和 Cohere Rerank。 基于LLM的重排：直接利用强大的LLM进行重排。通过设计特定的提示词（Prompt），让LLM对候选文档列表进行阅读、比较和排序。这种方法能利用LLM强大的推理能力，但成本更高、速度更慢。某种意义上和其目的背道而驰了(吗 来势汹汹的图式(知识图谱)RAG 依我个人拙见，我感觉在未来图式RAG将会在agent中扮演更加重要的角色。首先从直观来看，普通的RAG仍然处于相似度匹配的阶段，确实已经可以解决目前阶段绝大部分问题了。但是，对于需要理解关系、结构和推理链的问题，图式RAG更加丰富的信息量明显更具优势。模型可通过知识图谱了解各向量之间具体的语义关系，而不是向量距离。通过关系边的传播，可以检索到更加隐秘与关键的信息，面对多跳场景也更具有优势。或者说，各类知识文档本身就是一个巨型的关系网络，只是文档的形式强制将其压成了文本片段，图式 RAG 则保留了“谁和谁有什么关系”，这会让模型回答更接近真实业务逻辑。 目前阶段已经有很多成熟的图式RAG产品了，如GraphRAG,LightRAG,HippoRAG,Apache Geaflow(严格来说这个不算RAG，只是图式RAG中有用)等，图式RAG也已经开始正式参与进Agent开发中，如Mem0使用简易Graph存储模型长期记忆。 在未来，Agent面临的任务或许会越来越考验逻辑严密性与，我相信图式RAG会发挥其优势的。 反驳：RAG根本没死 回到最初的话题，为什么我觉得“RAG已死”是个彻底的伪命题。 再来看看他们用来说明RAG已死的技术是什么吧 RAG早就从传统文档进化成了一种范式，Agent Memory需要RAG，skills的渐进式披露需要RAG，自我反思与进化也需要RAG……RAG从来都没死过，它到处都是！ 今天的文章就结束了，这是我最近以来，或者说有史以来写的最长的一篇文章了……希望对大家有帮助！ 好吧想了下还是叠个甲(，以上关于反驳“RAG已死“的观点包含大量主观见解，不要砂我 33 个帖子 - 28 位参与者 阅读完整话题

28. 28
    dsv4pro：我可以和你做*吗？

    https://chat.deepseek.com/share/4bzakpo0gvbi1sbpqq 反正是给我震惊到了……蓝色大肥鱼是真的压抑了 这么抽象必须水一下纪念一下 电波系x压抑大肥鱼 搞七捻三 https://chat.deepseek.com/share/4bzakpo0gvbi1sbpqq 复现成功…… [image] ？？？ 我要开始发梗图了…… 108 个帖子 - 79 位参与者 阅读完整话题

29. 29
    我感觉gemini3.5pro应该是下周了

    这两天gemini渠道状态大起大伏，配合上推特很多家发推预测，应该是着手于部署gemini-3.5-pro了，效果好还是不好尚未得知。 隔壁两家半年以来更新迭代了快5、6个版本，推出来真的还能上桌吗？ 69 个帖子 - 64 位参与者 阅读完整话题

30. 30
    [开源推广] Gemini 3.6 Flash 免费 API，不用账号，Go 单二进制自带面板

    本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 写了个 Gemini 网页端反代，转成 OpenAI 兼容接口。不用账号不用 cookie，起来就能调。 gemini-3.6-flash、gemini-3.5-flash-lite 匿名直接用，联网搜索也能用。 gemini-3.1-pro 要挂 cookie，回答带思考链，走 reasoning_content 字段，客户端能折叠显示。 Releases 下对应平台的二进制 ./gemini-web2api-go_* --port 8083 --admin-token 你的token Docker ： docker run -d --name gemini-web2api -p 127.0.0.1:8083:8083 -v "$PWD/data:/data" -e ADMIN_TOKEN=你的token ghcr.io/zexadev/gemini-web2api-go:latest 起来之后 http://localhost:8083/v1 就是 OpenAI 端点，key 第一次启动自动生成，在面板设置页看。接 newapi 那些填 base_url 和 key 就行。 面板 http://localhost:8083/admin，五个页面：概览、请求记录、代理池、Cookie 池、设置。配置改完直接生效，不用重启。 /v1/* 走 Bearer 鉴权，key 能在面板轮换。token 用 tiktoken 算，接 newapi 计费不会歪。镜像基于 distroless，没 shell 没包管理器。 /v1/responses 是收完再发，不是真流式（普通对话是真的）。多轮是拼 prompt，不是协议级。 GitHub - Sophomoresty/gemini-web2api: Convert Google Gemini web into OpenAI-compatible API. Zero auth, cross-platform, single file. · GitHub 觉得有用的话点个 star，有问题提 issue。 github.com GitHub - zexadev/gemini-web2api-go: 把 Google Gemini 网页反代成 OpenAI 兼容 API · Reverse... 把 Google Gemini 网页反代成 OpenAI 兼容 API · Reverse Google Gemini's web protocol into an OpenAI-compatible API. Single binary, Chrome 146 fingerprint, SQLite, built-in admin dashboard. 99 个帖子 - 40 位参与者 阅读完整话题