标题: 万能的佬友们，需要酒店或者餐饮发票怎么搞？
作者: #TianJianJun
板块: #搞七捻三
编号: 1644244
帖子: https://linux.do/t/topic/1644244
时间: 2026-02-25 10:10:41
摘要:

如题，年会奖品需要发票报销，但是手里没有合适的发票，怎么搞？

标题: 我这边想收gpt4o mini模型
作者: #fengsanle
板块: #搞七捻三
编号: 1644245
帖子: https://linux.do/t/topic/1644245
时间: 2026-02-25 10:10:48
摘要:

我最近需要跑沉浸式翻译 量会比较大 但是公益站点目前基本没有能跑沉浸式翻译的 要不然就是限速比较高 所以我这边想用积分大量收一点 就只要求不限速 能稳定 具体好商量

标题: 【Deep Research 拆解系列】02：一个问题是怎么变成一份报告的
作者: #yelixin_117
板块: #文档共建
编号: 1644248
帖子: https://linux.do/t/topic/1644248
时间: 2026-02-25 10:11:26
摘要:

02：一个问题是怎么变成一份报告的

承接上篇：Deep Research 系统依赖四个机制协同工作——主动澄清、问题拆解、反思循环、来源追踪。四个机制缺任何一个，系统就会在某类问题上走偏。
这篇以 LangChain Open Deep Research 为参照，看这四个机制在一个具体的开源实现里长什么样。

全流程一览
你发出一个问题，框架依次经过四个阶段，最终产出一份报告：
flowchart TD
    U[/"用户发送问题"/] --> A
    A["① 澄清：判断问题边界是否清晰"] -->|"需要追问"| Q[/"向用户追问"/]
    Q --> U
    A -->|"可以继续"| B["② 规划：生成结构化研究简报"]
    B --> C["③ 调查：Supervisor 拆解并分配课题"]
    C --> D["Researcher 并行执行，搜索 · 阅读 · 推理"]
    D --> E["压缩摘要，交回 Supervisor"]
    E -->|"仍有空白，继续调查"| C
    E -->|"研究完成"| F["④ 综合：生成最终报告"]
    F --> R[/"输出报告给用户"/]

四个阶段，每一个对应一个明确的职责边界。

四个阶段：设计意图与失效边界
① 澄清
做了什么：框架首先判断问题边界是否清晰。如果问题模糊，它会主动追问。这一步可以关闭直接跳过。
为什么：一个问题往往有多种合理的解读方向。系统如果直接选一个方向推进，它选的不一定是你真正关心的。追问一次成本低；调查完发现方向错了，成本高。

缺少它：方向在起点就偏了，之后的执行越精确越错
还是那只跌了 15% 的股票：你没说最关心什么，系统默认你想要宏观分析，交出一份利率政策报告。但你当时最需要知道的，是这个跌幅有没有改变持有逻辑——该不该今天卖。方向在问题阶段没对齐，调查再深也是偏的。


② 规划
做了什么：你的消息被转化成一份研究简报：核心目标是什么、需要覆盖哪些维度、已知的前提是什么。这份简报不是复述原话，而是对"你真正需要知道什么"的结构化提炼。
为什么：Supervisor 在整个调查阶段会反复参照这份简报来决策——调查哪些课题、判断进展够不够。没有简报，每次决策都是临时起意，没有统一基准。

缺少它：调查在进行，但没有人知道终点在哪
没有简报的 Supervisor 会根据上一轮发现即兴决定"接下来查什么"——容易在某条有趣的线索上越走越深，同时遗漏掉同等重要的其他维度。调查看起来在持续，实际上没有收敛方向。


③ 调查
做了什么：Supervisor 拿着简报把任务拆解成若干课题，分配给多个 Researcher 并行执行。每个 Researcher 独立搜索、阅读、追线索，完成后压缩成摘要交回。Supervisor 读完所有摘要做一个判断：够了吗？不够就针对性补充，够了就结束。这个循环在两个条件下终止：Supervisor 自主判断发现已足够，或达到预设的调查轮次上限。
为什么：网状问题需要多维度同时推进——拆解后并行，各维度互不等待。每轮结束后 Supervisor 统一反思，新发现可以改变下一轮的方向，而不是一开始就锁死所有路径。两层终止条件并存，防止调查无限延伸——模型被要求做深度研究，它的自然倾向是持续推进，没有硬性边界就不会主动停下。

缺少拆解：关键线索藏在另一个维度，没有被触碰
系统只搜"XX股票下跌原因"，在这条线上越挖越深。但机构在三周前开始减仓这条线索，只会在"机构持仓动向"这个独立维度里出现。没有拆解，这个维度从未被分配，调查结束了，真正的信号从来没被看到。


缺少反思：第一批结果成为最终答案，合理但表浅
Supervisor 拿到第一轮摘要，看到"板块轮动"的解释，判断"够了"，结束。但板块轮动解释不了这个跌幅——如果它继续追，本应发现公司层面还有一条没走过的线。反思缺失，“合理"被当成了"充分”。


④ 综合
做了什么：所有摘要汇聚到报告生成节点，结合研究简报和全部发现，输出结构化报告。来源追踪贯穿全链路：搜索保留 URL，摘要压缩保留引用，报告标注出处。
为什么：摘要的累积不等于报告。各维度收集的信息片段需要整合成一个自洽的叙事，同时让每条结论指向可查的来源——否则深度调查的结果和一段流畅的生成文本在外观上没有区别。

缺少来源追踪：结论混合事实与生成内容，用户无法区分
报告写道"XX机构减持了 30%"——但这来自哪里？是上周的持仓披露，还是三个月前的 13F 申报？是真实数据还是模型基于上下文生成的内容？没有来源追踪，用户拿到的是看起来有深度的回答，但无法判断哪些部分可以信任。


对应回第一篇的框架
上一篇用一张表格描述了 Deep Research 系统的行为模式。在 Open Deep Research 里，这张表格有了具体的实现对应：




第一篇的机制
Open Deep Research 的实现




确认问题边界
① 澄清：主动追问


把问题结构化为调查计划
② 规划：生成研究简报


拆解问题，分配调查课题
③ 调查：Supervisor 分配任务


多路并行搜索
③ 调查：多个 Researcher 实例并行执行


反思循环
③ 调查：Supervisor 读完摘要后决定继续还是收尾


来源追踪
全链路：搜索保留 URL → 压缩保留引用 → 报告标注出处


综合生成报告
④ 综合：生成最终报告



前三个机制在调查阶段之前或之中发生，来源追踪贯穿全链路，第④阶段是输出。

全流程的轮廓在这里。但每个阶段的"怎么做"，还藏着更多选择和取舍。
澄清和研究简报是怎么生成的？Supervisor 如何判断"研究够了"？Researcher 之间为什么完全隔离、不共享发现？后续几篇各自追一个阶段，逐一拆开看。

← 01：从搜索到研究的距离

标题: 个人桌面助手后端选型求助
作者: #Jackson7362085
板块: #开发调优
编号: 1644249
帖子: https://linux.do/t/topic/1644249
时间: 2026-02-25 10:11:27
摘要:

佬友们，近期准备撸一个定制化的个人桌面助手，企业内部使用，可能之后有定制开发，现在后端选型有点纠结。
核心功能：文件自动化处理、本地知识库检索（RAG）、以及通过 MCP 协议控制第三方服务（浏览器）
运行环境：希望能够常驻后台，资源占用不宜过高，且具备高度的可定制性
目前对几个候选方案的疑虑：

OpenClaw：比较好的插件生态和多端接入，但总觉得太“重”了，系统侵入性强，且在自定义 Agent 逻辑时，感觉在折腾框架多过折腾业务。
Nanobot：非主要是轻量感和对 MCP 协议的纯粹支持。但在工程化方面，它是否足够稳定？
QwenCode 或者其他code cli：作为编程助手它的 Tool Calling 极准，但如果把它作为“常驻后台助理”的后端，是否会存在生态错位？或者说，有没有大佬尝试过将其封装为后台 Service 使用？

此外这些后端是否支持acp协议是否也应该纳入考虑因素

标题: 除了google 邮箱还有什么邮箱比较好？
作者: #Neal John
板块: #搞七捻三
编号: 1644253
帖子: https://linux.do/t/topic/1644253
时间: 2026-02-25 10:12:02
摘要:

主力邮箱是gmail邮箱， 而hotmail用来做一些乱七八糟账户验证登录哟娜，但几个hotmail的登录都像是薛定谔家的，时不时的登录不上去，决定放弃它了。还有比较好用的邮箱吗？

标题: qwen3.5系列一大波新模型上新30b模型吊打200b模型
作者: #Ningbainb
板块: #前沿快讯
编号: 1644257
帖子: https://linux.do/t/topic/1644257
时间: 2026-02-25 10:12:29
摘要:

继旗舰模型 Qwen3.5-397B-A17B 首次开源后，我们进一步丰富了开源矩阵：
 Qwen3.5-122B-A10B：与 27B（Dense）持续拉近中小模型与顶尖闭源模型的差距，在复杂 Agent 任务（如多步推理、工具调用、跨应用操作）中表现尤为亮眼。
 Qwen3.5-35B-A3B：已全面超越 Qwen3-235B-A22B 与 Qwen3-VL-235B-A22B —— 智能进步的关键，从来不是堆参数，而是更优架构 + 更高质量数据 + 强化学习（RL）的有效协同。
 Qwen3.5-27B（Dense）：小尺寸高能效，显著降低大模型使用门槛。
欢迎在 GitHub、Hugging Face 或魔搭社区下载模型，进行研究与微调！
同时，Qwen3.5-Flash API 已正式上线阿里云百炼！
 Qwen3.5-Flash：是与 35B-A3B 对齐的托管生产版本，默认支持 100万 tokens 上下文长度，内置官方原生工具链（无需额外集成）。
快来模型广场体验吧～
来源通义实验室官方小红书

标题: openclaw大家都用大龙虾做什么呢
作者: #hyang90
板块: #开发调优
编号: 1644263
帖子: https://linux.do/t/topic/1644263
时间: 2026-02-25 10:14:05
摘要:

想入坑大龙虾，但是又不知道我需要用他做什么，所以来问问大家，你们都用大龙虾做什么呢

标题: 有什么去ai视频水印的办法吗
作者: #greppro
板块: #资源荟萃
编号: 1644284
帖子: https://linux.do/t/topic/1644284
时间: 2026-02-25 10:19:04
摘要:

ai生成的视频右下角都有【ai生成】 怎么才能去掉 不压画质

标题: 【抽奖】 抽一个 GLaDOS 30天 Basic 会员
作者: #CCat
板块: #福利羊毛
编号: 1644294
帖子: https://linux.do/t/topic/1644294
时间: 2026-02-25 10:20:25
摘要:

奖品详情：
[奖品]：GLaDOS 30天 Basic 会员
提供对应账号的订阅链接
 活动时间：
截止时间：大概2026/02/26 10:00
 参与方式：
在本帖下回复任意内容，点个赞就更感谢了。
 抽奖规则：
每位用户仅允许参与一次。
使用官方抽奖工具随机抽取中奖者。
 注意事项：
本活动将在活动截止时间后关闭回帖，以确保公正性。
中奖者将在活动结束后 12 小时内在本帖公布，并通过私信通知领奖方式。
所有规则及抽奖结果由活动发起人和论坛管理团队最终解释。
期待您的积极参与，祝您好运！如有任何疑问，欢迎随时联系抽奖发起人。

标题: 如何区分包是使用pacman还是yay安装
作者: #bcmray
板块: #搞七捻三
编号: 1644314
帖子: https://linux.do/t/topic/1644314
时间: 2026-02-25 10:23:45
摘要:

我得到了一个含 Arch Linux - Package Search 的链接，应该使用pacman安装还是yay安装？如何区分该用哪个安装？
新人上路arch，希望佬友门多多指教QWQ

标题: 为什么最近新出的AI模型还会上50米洗车问题的当
作者: #Debris
板块: #搞七捻三
编号: 1644319
帖子: https://linux.do/t/topic/1644319
时间: 2026-02-25 10:24:40
摘要:

在23和24年左右的时候，很多模型对类似的弱智吧问题还是有点困难的，但是后来就没怎么听到类似的问题了。为什么突然最近出了这个50m洗车的问题让这么多模型翻车啊。是我没注意呢，还是说这个问题单纯不在训练语料里面？

标题: 千问刚刚发布了4个Qwen3.5新模型
作者: #arch
板块: #前沿快讯
编号: 1644326
帖子: https://linux.do/t/topic/1644326
时间: 2026-02-25 10:26:11
摘要:

千问刚刚发布了4个新模型！
包括 MoE 模型 Qwen3.5-122B-A10B, Qwen3.5-35B-A3B, Dense 模型 Qwen3.5-27B, 以及基模 Qwen3.5-35B-A3B-Base. 加上之前发布的旗舰 Qwen3.5-397B-A17B, Qwen3.5 系列已经集齐了从 3B 激活到 17B 激活的完整产品线.
看介绍，Qwen3.5 是一次重大飞跃，它集成了多模态学习、架构效率、强化学习规模和全球可访问性等方面的突破。
对于本地的开源方案来说，是个最佳的选择。

标题: 第10086次在抖音刷到男女之间有没有纯友谊的帖子，干脆就分享一下自己的见解
作者: #烟火
板块: #搞七捻三
编号: 1644329
帖子: https://linux.do/t/topic/1644329
时间: 2026-02-25 10:26:28
摘要:

RT,刷到过这个话题蛮多次了，看各个评论区里面的人说的也都很有道理，那就从我个人经历上分享一些我个人的看法好了 先给出我的结论：我觉得纯友谊是完全存在的。我认识的也有很多女生，一部分跟我关系相当不错，就我个人来说我对她们要么是打心底觉得欣赏要么是性格很相似所以很投缘，完全没有类似想谈恋爱或者说发生一些什么事情的冲动，我跟她们之间就是非常纯粹的友谊，我们会偶尔一起聚餐一起唱K(不会单独，因为我有对象)，然后我们打游戏也会分享自己的欧非时刻什么的，所以从我个人经历来说我是完全觉得纯友谊是存在的

标题: 咋回事 gitee崩了
作者: #lucky_0625
板块: #搞七捻三
编号: 1644339
帖子: https://linux.do/t/topic/1644339
时间: 2026-02-25 10:28:09
摘要:

咋回事 gitee崩了  Failed to connect to gitee.com port 443 after 21342 ms: Could n
ot connect to server

标题: jetbrains 教育包申请是放水了吗？
作者: #蘅芜梦冷
板块: #搞七捻三
编号: 1644352
帖子: https://linux.do/t/topic/1644352
时间: 2026-02-25 10:30:58
摘要:

刚用去年五六月分注册的 ASU 教育邮箱，申请 Jetbrains 的教育包竟然秒过。提交申请后 ASU 邮箱秒收到了 JetBrains 的验证邮件，点击验证连接后一年教育包就到手了。

标题: 有偿找大佬帮我弄 免费白嫖5年Copilot(Microsoft365可用GPT-5.2
作者: #豆沙包
板块: #开发调优
编号: 1644355
帖子: https://linux.do/t/topic/1644355
时间: 2026-02-25 10:31:11
摘要:

我想白嫖Microsoft365 5年 但是自己只会弄两年的 没有谷歌pay 有没有大佬教一教

标题: 站内好像有一些历史规则 大家一起来整理下吧
作者: #叱咤月海鱼鱼猫
板块: #搞七捻三
编号: 1644357
帖子: https://linux.do/t/topic/1644357
时间: 2026-02-25 10:31:21
摘要:

从开站到现在 似乎有好多新增的规则 不在站内须知的 感觉好像有必要一起整理下 或者已经有大佬整理了吗？

标题: blog-云原生入门~ 开工大吉呀！
作者: #Yjyrichard
板块: #开发调优
编号: 1644364
帖子: https://linux.do/t/topic/1644364
时间: 2026-02-25 10:32:56
摘要:

云原生到底是什么？一个大三学生的理解

最近在研发实习中接触了不少云原生相关的技术栈，发现很多同学对"云原生"这个概念还是比较模糊的。这篇文章尝试用大白话把它讲清楚，也算是对自己学习和实习经历的一个记录。

先聊一个直觉：为什么需要云原生？
假设你写了一个 Web 应用，部署在一台服务器上。某天突然火了，用户暴增，一台机器扛不住了——你得加机器。加了机器之后，代码怎么部署？配置怎么同步？某台机器挂了怎么办？版本更新怎么做到不停服？
这些问题，就是云原生要解决的。
传统做法是"人肉运维"：手动登录服务器、手动部署、手动扩容。云原生的思路是：把这一切自动化、标准化，让应用天生就适合跑在云上。
云原生的定义
云原生没有一个"标准答案"式的官方定义，不同组织在不同时期给出了不同的解释。但核心思想是一致的：

云原生（Cloud Native）是一种软件开发和部署的方法论，目标是充分利用云计算的优势，构建高度可扩展、弹性伸缩、可观测、自动化、高稳定性的应用程序。

注意，云原生不是某一个具体技术，而是一套方法论 + 技术体系的组合。
云原生的核心技术栈
下面是云原生中最核心的几个技术，我用大学生能理解的方式逐个解释。
1. 容器（Container）
一句话理解： 容器就是一个轻量级的、标准化的"打包盒"，把你的代码和它依赖的所有环境一起打包。
你一定遇到过这个经典场景——“在我电脑上能跑啊！”。容器就是来解决这个问题的。Docker 是最常见的容器工具，它把应用及其依赖打包成一个镜像（Image），不管在谁的机器上，只要装了 Docker，docker run 一下就能跑，环境完全一致。
而 Kubernetes（简称 K8s） 是容器的"调度中心"。当你有几十上百个容器要管理时，K8s 负责：哪个容器跑在哪台机器上、挂了自动重启、流量大了自动扩容。可以把它理解为容器的"操作系统"。
2. 微服务（Microservice）
一句话理解： 把一个大应用拆成多个小服务，各自独立开发、独立部署。
传统的"单体架构"就像一个巨大的 Word 文档，所有功能写在一起，改一个地方就得重新发布整个应用。微服务架构则像是把文档拆成多个独立的章节文件，每个团队负责自己的那一块，互不干扰。
比如一个电商系统，可以拆成：用户服务、商品服务、订单服务、支付服务……它们通过 API（通常是 HTTP/gRPC）互相通信。
3. 服务网格（Service Mesh）
一句话理解： 微服务之间的"通信管家"。
当微服务越来越多，服务之间的调用关系变得非常复杂：A 调 B，B 调 C，C 又调 D……这时候就需要处理负载均衡、熔断降级、链路追踪等问题。服务网格（如 Istio、Linkerd）在不修改业务代码的前提下，以"Sidecar"代理的方式自动处理这些通信治理问题。
可以类比为：微服务是一栋栋楼，服务网格是楼与楼之间的道路系统和交通管理。
4. 声明式 API（Declarative API）
一句话理解： 你只需要告诉系统"我要什么"，而不用告诉它"怎么做"。
举个例子，命令式（Imperative）的做法是：
启动 3 个容器 → 配置负载均衡 → 设置健康检查 → ...

声明式（Declarative）的做法是写一个 YAML 文件：
replicas: 3          # 我要 3 个副本
image: my-app:v2     # 用这个镜像
healthCheck: /ping   # 健康检查路径

你把这个文件交给 Kubernetes，它自动帮你达到这个状态。如果某个容器挂了，K8s 发现"当前只有 2 个，但你要 3 个"，就会自动拉起一个新的。这就是声明式的强大之处。
5. 不可变基础设施（Immutable Infrastructure）
一句话理解： 应用实例一旦部署，就不再修改，要更新就重新创建一个新的。
传统做法是"上线后打补丁"——直接登到服务器上改配置、改代码。但这样做容易导致环境漂移（每台机器的状态不一样），出了问题很难排查。
不可变基础设施的思路是：每次更新都重新构建一个全新的镜像和容器，而不是在原有基础上修改。就像你不会去修改一张已经打印好的照片，而是重新拍一张。
6. DevOps
一句话理解： 开发和运维不再是两个独立的团队，而是融合在一起，强调协作和自动化。
DevOps 不是一个工具，而是一种文化和实践。核心目标是通过自动化（CI/CD 流水线、自动化测试、自动化部署）来加速软件的交付周期。
一个典型的 DevOps 流程：
代码提交 → 自动构建 → 自动测试 → 自动部署到测试环境 → 人工验证 → 自动部署到生产环境

7. 持续集成/持续交付（CI/CD）
一句话理解： 代码提交后，自动完成构建、测试、部署的全流程。

CI（持续集成）： 开发者每次提交代码，自动触发构建和测试，尽早发现问题。
CD（持续交付/持续部署）： 通过自动化流水线，将通过测试的代码快速、安全地部署到生产环境。

常见工具：Jenkins、GitHub Actions、GitLab CI、ArgoCD 等。
云原生应用长什么样？
使用上述技术栈构建的应用，就可以称为"云原生应用"。一个云原生应用通常具备以下能力：




能力
说明
背后的技术




弹性伸缩
流量大了自动扩容，流量小了自动缩容
Kubernetes HPA、Serverless


发布自动化
代码合并后自动走完构建-测试-部署全流程
CI/CD、GitOps


自愈能力
容器挂了自动重启，节点挂了自动迁移
Kubernetes 控制循环、声明式 API


可观测性
全方位监控应用的指标、日志、链路
Prometheus、OpenTelemetry、Grafana


跨平台
不绑定某个云厂商，可以在阿里云、AWS、本地机房之间迁移
容器化、开放标准



AI Infra 属于云原生吗？
这是一个值得思考的问题。我的回答是：AI 基础设施正在深度融入云原生体系，但又在推动云原生的边界发生变化。
为什么说 AI Infra 属于云原生？

Kubernetes 已经是 AI/ML 工作负载的事实标准平台。 从模型训练到推理服务，主流方案都跑在 K8s 上。据 CNCF 2025 年报告，41% 的 AI 开发者已经在使用云原生技术。
MLOps 深度依赖云原生技术栈。 模型的训练、版本管理、部署、监控，本质上就是一条 CI/CD 流水线，只不过交付物从"代码包"变成了"模型"。Kubeflow、MLflow、KServe 等主流 MLOps 工具全部构建在 Kubernetes 之上。
容器化和声明式 API 是 AI 工作负载管理的基础。 GPU 资源的调度、分布式训练任务的编排，都依赖 K8s 的能力。

但 AI Infra 也在挑战传统云原生的假设：

计算重心从 CPU 转向 GPU。 传统云原生架构以 CPU 为中心设计，而 AI 工作负载的核心是 GPU，这要求调度器、资源管理、成本优化等都需要重新设计。
数据密集型。 AI 工作负载涉及大规模数据集的存储和流转，对存储和网络带宽提出了更高要求。
有人提出"AI 原生（AI-Native）"的概念。 认为仅仅在云原生之上跑 AI 是不够的，需要从底层架构开始就为 AI 工作负载做专门优化。

所以更准确的说法是：AI Infra 的底座是云原生，但它正在从"Cloud Native"走向"AI Native"，推动基础设施向以 GPU、向量数据库、模型生命周期管理为核心的新范式演进。
CNCF 全景图速览
CNCF（云原生计算基金会）维护了一张 Cloud Native Landscape，这是云原生生态的"全家福"。截至 2025 年底，云原生开发者数量已达 1560 万。全景图涵盖以下主要类别：

应用定义与开发： Helm、Backstage、Dapr
编排与管理： Kubernetes、Crossplane
运行时： containerd、CRI-O、gVisor
配置与供应： Terraform、Ansible、Pulumi
可观测与分析： Prometheus、Grafana、OpenTelemetry、Jaeger
网络与安全： Cilium、Envoy、Falco、Open Policy Agent
存储： Rook、Vitess、TiKV
Serverless： Knative、OpenFaaS
服务网格： Istio、Linkerd

建议亲自打开 landscape.cncf.io 看看，感受一下这个生态的规模。
写在最后
作为一个在校学生，我觉得学习云原生最重要的不是一上来就背概念，而是动手实践：

先学 Docker——学会容器化你的项目
再学 Kubernetes——学会编排和管理容器
然后接触 CI/CD——用 GitHub Actions 给自己的项目搭一条流水线
最后了解微服务、服务网格等进阶内容

云原生不是什么高不可攀的东西，它是当前后端研发工程师的基础技能。越早接触，越早受益。

参考资料：

CNCF Cloud Native Landscape
CNCF State of Cloud Native Development Report