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

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

1. 1
   有些东西大家就别搬来搬去了

   写这个公告并不是去回应什么，只是请大家不要再去把一些不好的东西往站里搬，真的你喜欢就多待会好了。这就是本帖最大的诉求。 事情我们早就收到反馈了，如果非要说几句：成也域名，败也域名，一个实名的域名 whois 就注定了上限。不出意外，也许你们能看到一些较L站规则离谱的规则 无需做什么，祝你们愉快。接着奏乐接着舞～ 389 个帖子 - 350 位参与者 阅读完整话题

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

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

3. 3
   昨天在海边救了一个小男孩，后续

   继这个话题后续： 昨天在海边救了一个小男孩，今天上门了，怎么处理，急！！！ 搞七捻三 孩子父母带着孩子来了，带了些东西（有酒，肉，水果还有啥来）还有1000的红包，本想着东西都留着，红包不要的，对方很明确多次拒绝，所以钱也留下了，口头上说了下一起出去吃饭，我对象值班没在家也就没去吃饭，在家聊了会天，这就是最终的结局了。 最重要的是，也是我的心得吧，分享给佬友： 173 个帖子 - 172 位参与者 阅读完整话题

4. 4
   昨天在海边救了一个小男孩，今天上门了，怎么处理，急！！！

   L友们，昨天在海边救了一个小男孩，小孩是由爷爷带着的，救完后爷爷非要留联系方式就留了个手机号，今天早上疯狂打电话加微信，要位置，说要来我说， 应该马上就上门了，应该会带很多东西吧，如果给东西给钱，要不要留？没经历过这事，怎么办才好？ 急！！！ 158 个帖子 - 153 位参与者 阅读完整话题

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

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

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

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

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

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

8. 8
   快来领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以证明真实性。 2500 个帖子 - 2446 位参与者 阅读完整话题

9. 9
   gpt掺水检测器，千次测试0误报，从此告别掺假！[附实战案例] 4.0.0重大更新

   本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 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) 有重要更新，使用前请阅读末尾的“8.10更新 这是一个gpt5.6专用的掺水检测器，可以检测你填入的api有没有将模型偷偷路由成其他的。且支持持续检测 检测主要分两类，第一类是目前比较强力的juice检测 有12%显示当前申报模型是因为低档每8次high请求会带三次low请求，而low思考强度luna，terra和sol是一样的，去除这部分，juice哪怕只请求一次，探测率也接近100% https://github.com/chen-006/gpt56_api_detector/releases/download/v4.0.0/gpt.v4.0.0.7z 第二类是概率探针 一个基于概率分布识别任意模型真假的项目，从此告别掺假！ 然后是各25次luna，terra，假阴性率为0 网络错误多是因为在外面，连的手机热点 https://github.com/chen-006/gpt56_api_detector/releases/download/v4.0.0/gpt.v4.0.0.7z 以下是本地plus号的中档报告参考 本次还更新了以下防反探测措施 接下来是最重磅的：新增了探针生成器，见帖子人人都能自己做探针了！自定义探针生成器！ 目前有默认低中高三个档位，而且可以自定义请求的探针，次数，思考强度，并发等。 可以在codex里挂一个定时任务让它读取本项目的文件夹，定时汇报解答疑问，非常方便 截至帖子发出已经差不多48小时内只睡了3小时了，因为真的没想到突然火起来，还答应了佬们要尽快更新。实现过程中踩了很多坑，有新想法又想加进去。我又是那种有事情不完成就睡不着的人，所以可能还有些小bug佬们积极反馈。如果有帮助的话点个星吧！ 项目大概就是这样，介绍完了。 接下来顺便跟佬们分享两个实战案例 大约是7月25号的时候我用juice测出了aihub @AIHUB 聚合站的a014分组sol路由了luna。当时我刚用aihub，也没有办法联系站长，于是只是在自己写的自动路由里拉黑了这个分组，没有管下去。 之后我一直有挂持续监控，持续监测aihub的低价分组。期间也没再出过问题，直到8月4号凌晨，ai跟我报告又出了问题 我一查，发现又是这个a014分组的。于是又联系了站长，从截图看这次上游疑似又甩锅更上游，还跟站长爆发了一定程度的冲突。并且这次上游还使用了更恶劣的脚本随机路由 最后大家不要误会，这个aihub是一个聚合很多上游的“二次中转”，据我实测下来，出问题的上游分组只是极少数，而且站长非常负责任，此次事件之后估计也永久拉黑a014分组了。 8.9补充 @ishadows 佬讨论，他之前给了我一个站点，这个站点非常牛逼，堪称第一个明显看得出在有意识地反探测的站点 这个站点会识别关键词，从而选择性路由真模型，使用经典的juice探针测试sol high。它返回的是正常的40，但是如果把juice探针中的一个“juice number”换成juiice nummber“。它就会返回异常值48，而可信端仍返回40 目前对于这个站点只能采用概率探针测试，也只有中高档的概率探针才能拦住他。低档或者juice是显示通过的。gpt掺水检测器，千次测试0误报，从此告别掺假！[附实战案例] 4.0.0重大更新 - #90，来自 ishadows 这是mouu的 各种探针迟早容易被针对，攻方的最大问题是，探测方为了证明自己探针的有效性，必须做大量冒烟测试以防止误杀好站点。但掺水方只需要做一个简单的识别去路由真模型。自制探针就可以解决这个问题，人人都能做，防止掺水识别探针人人都能自己做探针了！自定义探针生成器！ 只要做的比识别规则加的快，掺水端就防不过来 8.10更新 目前已经有实际证据表明，检测不通过不一定是中转主动掺水，也可能是官方风控导致路由低级模型 【夜间科研成果】果汁值和概率层测试，可能确实存在点问题 开发调优 这个风控的机制很神秘，目前还量化不出来具体是怎么判定的。有的佬用官方账号组的号池试着没问题，但有的佬用官方账号组的号池也会测出不通过。 风控可能是因为ip不好/反代/并发数量过多等多种原因导致。目前我也复现了在特别高并发的情况下，之前检测一直没毛病的可信站点也出现了检测不通过的情况。但就目前来说，默认的档位8并发还没有试过不通过。 所以目前结论就是 如果检测不通过：可能是中转掺水，但也有可能是各种原因被官方风控导致路由到了低级模型 如果检测通过：基本没问题 至于检测不通过的情况，中转自证也很简单，拿出当时检测的请求对应的号池截图甚至视频，这是最有效的办法。 133 个帖子 - 63 位参与者 阅读完整话题

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

    首先的首先，我们可以把大模型粗略看作一个极其复杂的函数。在这个函数里，每一次交互的输出（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 96 个帖子 - 62 位参与者 阅读完整话题

11. 11
    【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已死“的观点包含大量主观见解，不要砂我 45 个帖子 - 40 位参与者 阅读完整话题

12. 12
    最高的山，停止对我检测脚本的污蔑

    事情起于这个帖子那个最帅的男人的星辰站，出来解释下呗？ 当时有人用我的juice检测脚本测出了君的星辰站（中转收费站）在sol模型里掺了luna，正常sol high的juice只有40或40xxx，他引发了大家的激烈讨论。 后来该中转站长在那个帖子下回应了，说可以退款。但回应的时候还引用了一个人网页版soljuice测出了48然后说“结果如下”那个最帅的男人的星辰站，出来解释下呗？ - #178，来自 user792 那个最帅的男人的星辰站，出来解释下呗？ - #180，来自 user792 不是不是，星辰站问题已经解决完了吗？ 他突然发布了个帖子 给大家看一下号池记录吧，我觉得可以终结这个话题了 搞七捻三 关于这位佬要的解释继续讨论： 今天上午我也自测了一下，给大家看一眼 先看所谓的掺假记录 [ef8c8bd2d284d1f828340b0243758a9c] 记住这个时间 2026-08-06 11:59:00 再看调用日志 [image] 最后看号池日志 [image] 结束，接着奏乐接着舞 给看不懂的佬稍微说明下，之前那个帖子拿着 GitHub - chen-006/… 然后就是“散了吧，散了吧”，装死不回 直到可能是l站对富可敌国的回复时间限制快到了 此贴为针对 爱伦·坡 帖子的回应 此时我就想默默问一句，如果juice检测有问题，为什么我本地的plus号跑了1400条请求0误报？这还不算我没有记录下来的近万条 https://github.com/chen-006/gpt56_api_detector/releases/download/v4.0.0/gpt.v4.0.0.7z 如果juice有问题，为什么后续很多人用了同样的测试法，测其他站点都是通过？给大家看一下号池记录吧，我觉得可以终结这个话题了 - #35，来自 zhx47 如果juice有问题，为什么佬们从来没有在官号上测出juice异常？？ 那个最帅的男人的星辰站，出来解释下呗？ 搞七捻三 反正我从来没见过codex里有48 juice的sol 忍了一下午了还是想说，我用sol xhigh的价格用luna？【OOIOO】 搞七捻三 [AIHUB]暂时关闭充值与调用 严格处理参水事件！！ 搞七捻三 再者逻辑也是严重不成立的 最好的自证办法从来都是拿到反馈掺水佬友那天的原始请求，的上游号池截图，并且那个佬友从一开始就已经在强调了。但是为啥不回应？ 君的公益站名声在外，我刚进l站就已经耳熟能详，站长做了那么多公益，相信不是恶意去掺水，去破坏佬友们的使用体验。 还说自己公关不好，隔壁ooioo都被喷成啥样了。人设也是公关的一部分要我说（） 忍了一下午了还是想说，我用sol xhigh的价格用luna？【OOIOO】 搞七捻三 [image]） （六编：不行了忍不了了，快一天了，够给你面子了。我就点名了，OOIOO，8号下午到晚上，你家sol xhigh是自动路由到luna xhigh的，你们到底处不处理？不会又要嘴上冷处理，实际上dream coding了吧？还是… 116 个帖子 - 93 位参与者 阅读完整话题

13. 13
    拼夕夕省钱实录

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

14. 14
    奥特曼，你搞砸了一切。（原标题：那个最帅的男人的星辰站，出来解释下呗？）

    再次编辑一下帖子，从隔壁hlool佬得到的结果，哪怕是官方sol-high确实也有可能得到48的juice值。当时真的有可能是奥特曼搞砸了一切。 我在这先给muyuan佬道个歉。 当时没等到号池记录和后续监控网站我确实对这个事情越发怀疑，但是目前来看真的没法依靠juice值下定论。我的判断还是太武断了。 【夜间科研成果】果汁值和概率层测试，可能确实存在点问题 开发调优 muyuan佬已经给了处理了。说是之后会持续保持监控juice值。希望能保持下去吧。 为了避免大家讨论到后面越来越偏题，我这里强调几个点。 1.中转站的利润，这个帖子说的很清楚了，各种倍率有各种不同的渠道。 【无广告】中转站运营快一个月了，中转运营现状与成本分析 2.大家讨论的时候可能忽略了sol掺luna的价格差距。 另外，我根本不会想用luna。因为luna在 给 我 的 项 目 埋 坑！ 3.实际上目前关于降智或者掺水的讨论已经推进到最后一点了。 4.保持理智，不要冲动。 5.退款话题和我无关，退款从来不在我的诉求里。 本来今天下午发现gpt5.6-sol解决一个问题搞了2个小时没搞好，还以为是gpt官方降智+上下文太小导致绕了半天。 晚上刷ld站看到有个看起来还可以的软件，顺手测试了一下。 gpt掺水检测器，千次测试0误报，从此告别掺假！[附实战案例] 4.0.0重大更新 平常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) 386 个帖子 - 188 位参与者 阅读完整话题

15. 15
    佬们，想换工作了，怎么学习 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 位参与者 阅读完整话题

16. 16
    长这么大，才知道雨蝶是啥

    如图，具象化了： 37 个帖子 - 35 位参与者 阅读完整话题

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

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

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

    本帖使用社区公益推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的项目是免费使用的，无收费（变相收费、赞助）部分： 是 我的帖子已经打上 公益推广 标签： 是 我的项目属于个人项目，与公司或商业机构无关： 是 我的项目不存在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 位参与者 阅读完整话题

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 60 个帖子 - 54 位参与者 阅读完整话题

20. 20
    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 元套餐开始，小额试用，合适再续，不建议一次多充。 251 个帖子 - 203 位参与者 阅读完整话题

21. 21
    星辰站这件事其实很好解决的，为什么要一直困难化呢？

    本来今天起床之后看到有这么多消息，我就感到星辰站的这件事已经有结果了 此贴为针对 爱伦·坡 帖子的回应 搞七捻三 不是不是，星辰站问题已经解决完了吗？继续讨论： @Allan 关于退款 当时已经对一部分用户进行了退款到余额，或者原路返回到充值渠道，但是我发现这个事情没那么简单，所以我叫停了退款，并发了公告，并按照最开始的帖子，开始复现这个所谓的证明我掺假的过程。 这是我展示复现流程的帖子 很明显：这个所谓的检测工具，把 gpt plus账号的5.6sol响应识别成了非sol了，gpt降智在所难免… 结果就是：啊~~原来是这样。 再次声明：我不针对人，我针对的永远都是事情。 @user792 我本来非常不想要把你的站点挂起来的，因为你的最开始创建的那个公益站，是我进入L站之后认识的第一个公益站。。虽然我没用，但是我还是很感谢你作为第一批的公益站主能够给佬友们福利！ 然后让我们继续这次事件，首先，我一开始确实想着能够退款就退（在我第一次发截图到tg群里申请退款的时候），但是后来在事情慢慢发酵之后，我想的却不是退款了，而是我一直在强调的态度问题。 此贴为针对 爱伦·坡 帖子的回应 当时已经对一部分用户进行了退款到余额，或者原路返回到充值渠道，但是我发现这个事情没那么简单，所以我叫停了退款，并发了公告，并按照最开始的帖子，开始复现这个所谓的证明我掺假的过程。 对于这件事，我想我可能已经重复过很多遍了，我是在tg群发出退款通知的时候第一个发送截图的，但你直到现在都没有回应这个问题。 那么： 为什么没有退到我的款？ 群里的客服，管理到底是干嘛用的？ 这是态度问题，哪怕你能够给出一个合理的解释，我也能够接受，甚至是你和我说下次充值会有折扣，那么我也可以勉强接受，但是你甚至没有回复，而且你群里的管理也没有任何一个人进行回复，在之后还把我的消息删了（这些都是在你说暂停退款之前的事情） 此贴为针对 爱伦·坡 帖子的回应 可以加售后群在群里问，一般这时候就会有客服帮你解决 关于这个，我也已经在上面解释了 然后是关于掺水的事情，一开始我还没有意识到这件事，我只是觉得api用起来很卡，一直502 503。所以我还以为自己网络问题导致的网络波动所以进展不好，差不多用了200余额吧，项目一直都没啥进展，导致拖延了三天。 二编：看到了关于奥特曼搞的即使官渠也会有问题，所以这不是你的错 你说上游掺水，那没关系，作为中转站被上游掺水很正常，但是你作为站长需要的是对这样的事件做出一个合理的解释，补偿另说。但是你连一个合理的解释都没有，这就是会令大多数佬友气愤的原因。 [AIHUB]暂时关闭充值与调用 严格处理掺水事件！！ 搞七捻三 你可以看看其他的站是怎么做的，我不想调侃你关于你的站排名的事情，但是这是有目共睹的，为什么它的站能够做到第一，这些都是有原因的。这也不是唯一一个会直接站出来面对的站，也有其他这么做的，你也能够看到，所以就不一一举例了。 并且为什么你在帖子发出这么久之后才做了回应呢？已经三天了，难道你才刚刚看到帖子吗？ 人应该真诚一点，想要通过中转站赚钱，那就是通过中转站赚钱，没什么不好说的。 然后，请不要随意去嘲讽任何一个开源作者的作品，开源不易，而开源社区需要每个人都为爱发电。如果他的作品有问题，你可以拿出证据石锤，但是如果你直接这样 此贴为针对 爱伦·坡 帖子的回应 很明显：这个所谓的检测工具，把 gpt plus账号的5.6sol响应识别成了非sol了，gpt降智在所难免，测不准也能接受。 我不可能为一个并不靠谱的检测工具的检测结果买单。 去评价一个佬友的开源作品的话，他当然会气愤 最高的山，停止对我检测脚本的污蔑 搞七捻三 那个最帅的男人的星辰站，出来解释下呗？ 当时有人用我的juice检测脚本测出了君的星辰站（中转收费站）在sol模型里掺了luna，正常sol high的juice只有40或40xxx，他引发了大家的激烈讨论。 后来该中转站长在那个帖子下回应了，说可以退款。但回应的时候还引用了一个人网页版soljuice测出了48然后说“结果如下”那个最帅的男人的星辰站，出来解释下呗？ - #1… 并且你所做出的检测已经是距离事发十几个小时之后的事情了，暂且不猜测你专门用了plus号池来测试，就中转站在你和他说了之后，也会换回plus号池吧？人家不傻，想要做生意有点暗地里的操作是很正常的。 有佬友在帖子下面甚至都不敢留言，因为害怕被举报。虽然我不知道这是什么原因，但是我觉得这很奇怪… 总结一下。 最后，我能够发帖的时候，我的目的就已经不是为了那点退款了，站里的佬友们会用你的中转站是因为信任你，请不要将佬友们的信任当做你的筹码，我们需要的是真正的处理问题的态度…而不是敷衍的解释和带过… @user792 少点自负吧… 剧透 三编，死士们可以一直来举报，我不怕举报 身正不怕影子斜 146 个帖子 - 77 位参与者 阅读完整话题

22. 22
    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 位参与者 阅读完整话题

23. 23
    中转站百科第二集：怎么上手开一个中转站？（科普贴）

    中转站百科第一集：什么是中转站，倍率是什么（科普贴） 开发调优 AI 中转站大起底：什么是中转站，倍率是什么 本帖看前说明： [ai-relay-h-batch-a-001-01-use-case-stylized-concept.-asset-type-wide-horiz] “中转站”这个词，在 AI API 圈子里已经存在很久了。 基本上很多人都知道这个名词，但是由于技术门槛、部署成本，或者其他原因，并没有真正自己部署过，所以对其中很多细节并不清… 上一期，我们讲了关于中转站的一些介绍 近期论坛里面的帖子已经到了很离谱的程度了，全都是：我想开中转，怎么做/公司想开，怎么做/中转选哪里服务器啊什么的巴拉拉的 （点击了解更多详细信息） 第二步，确定要做了：号池从哪来？我怎么成上游了？ （点击了解更多详细信息） 第三步，我要买什么服务器？怎么挑选服务器？ （点击了解更多详细信息） 第四步，关于号池的进一步细节讲解。 （点击了解更多详细信息） 第五步，获客从哪里来，我要怎么赚大钱？ （点击了解更多详细信息） 第六步，防止自己的中转站被攻击。 （点击了解更多详细信息） 第七步，怎么开通自己的收费方式 （点击了解更多详细信息） 现在也没有想好还有什么东西要去普及的。 32 个帖子 - 27 位参与者 阅读完整话题

24. 24
    [AIHUB]暂时关闭充值与调用 严格处理掺水事件！！

    有任何问题我们都正面回应 我们就是二手贩子 没什么不能回应的 有问题解决问题 我想我的初心是正向的 但是越来越觉得这个事情做错了 错的不是我 是这混乱的行业 从昨天开始不断有人跟我反馈 luna映射的问题 我一直在找一个能百分百监测套壳的方法 我觉得我们太垃圾了 连最起码的监管都做不好 居然本末倒置把问题抛给了相信我们的用户 从入驻一直到商家评价第一 这个时间太短了 我们被捧得太高了 高到看不到我们的不足了 写下沉重的几行话 我们要开始负重前行了 我们做严格的上游结算模式和监测套壳问题 我想好好做 我想赚钱 我想赚良心钱 我不想同流合污 给我一点时间 这期间暂停充值 暂停调用 开放退款渠道 谢谢大家的信任 另：如有百分百监测是否套壳、参水的方法 请私信我 采用即奖励口令红包1000r 68 个帖子 - 55 位参与者 阅读完整话题

25. 25
    那什么，我来讲解一下，为什么说中转可能自己也很难规避掺水问题

    我就拿我自己的中转举例吧 我们站点的008分组是炸弹车，渠道呢，就是卡team的一个收费bug，可以较低的价格开出多个正价号，但是由于风控，现在很多账号都是30-60分钟左右就失效了，所以叫做炸弹车 而其他的不同的gpt渠道，你可以看到的，都是在打信息差，不是说大家不愿意自建号池。 那么为什么说krril之类的订阅站他们可以稳定的住？ 不是说什么技术力或者其他的能力，全网都断供，没号的时候，你作为稍微有知名度一些的站点，立马就会被慕名而来的流量淹没。你再好的技术，一万rpm打进来的时候都可以吃屁了。 像luna都断开的那几天，我们大概多坚持了2天左右，多个用户都是1000+rpm的去跑luna，作为中转确实很难扛得住这种。 那么在这种情况下，中转最好的方式是什么? 接管子有几个好处： 所以就导致了现在很多中转翻车，掺水了翻车，怎么样了翻车。 我不建议大家对中转、公益抱有技术力，大佬等等之类的看法 github.com GitHub - chen-006/gpt56_api_detector: 用于检测api是否路由真实gpt5.6模型 用于检测api是否路由真实gpt5.6模型 我测试了，脚本是真的，而且非常真，并且我说的现在很多中转掺水也是真的 25倍价差,terra 被偷换成 luna 是 10倍 信任往往就产生在几次崩塌，我相信很多同行，例如aihub等，很少有主观作恶的，确实是因为上游造成的 驱逐不良上游应该是我们该做的，让客户放心也是我们该做的 稍微让富可敌国的口碑好点吧，我们都可以共同受益，减少佬们对富可敌国的敌意。 65 个帖子 - 48 位参与者 阅读完整话题

26. 26
    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 位参与者 阅读完整话题

27. 27
    「女生女装系列」这期是金发精灵4连击~(全身!)|正式超越「神墨」!

    全身，除了头 今日15:17:52 截此图时，正式超越神墨佬「仅4分」 不多说 （点击了解更多详细信息） 按照惯例，一张图喵三下 实在没想到，这是极其古老的内容了，我以为我开始发女装是在暑假之后… 重温了一下我当时说的话… 至于所谓的藏在心里的话，自然是忘却了 想补充一些 不想换手机壳是因为不想花钱 很朴素的理由吧 按我之前说的，我是不希望ai去修改我的肉体的 我的身体他不应该碰的 甚至于包括美白什么的 但我前段时间因为是夏天又不穿衣服，所以身上一堆红点点 甚至有一些好了之后留下的灰暗的伤损 所以会让优化一下 AI改完之后会进一步损失画质，这是我更不愿意看到的 所以往往我不会使用AI 但像这次一样 为了拍全身，我要么延时摄影 要么就是对镜 但是我的镜子又好脏w 然后镜子后面的空间也不大，还有一堆东西 不好 所以从今天起决定 以后要是拍全身的话，我会让ai帮我换一个我喜欢的背景~ 也允许他帮我把这个自拍的动作改成更自然的动作 满足你我的幻想(bushi) 注:拒绝香蕉系列以及gpt 现在你明白当初芙芙为什么说那句话了吗? 哈基米给我科普了性转术语并推荐了一堆动漫 说起来，这张图的精髓我认为是那四个字+一个emoji的文案 看到这里，你不会还不知道是哪四个字和emoji吧… 抱歉，我又食言了，没能在昨天就发 此事也多亏了芙芙帮助 不然我甚至可能发不了这个话题 聚合网站: http://warp-petal.stellafortuna.dpdns.org/ 我又黑化了，可是舍不得任何人 但大家也不能再帮到我了 86 个帖子 - 59 位参与者 阅读完整话题

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

    60 个帖子 - 52 位参与者 阅读完整话题

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

    随便聊一聊公益站吧 搞七捻三 “公益站评分”真的有必要吗？揪出坏人或许可以换一种方式 运营反馈 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 位参与者 阅读完整话题

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. 105 个帖子 - 42 位参与者 阅读完整话题