标题: 【CLIProxy】该凭证暂无可用模型 该认证凭证可能尚未被服务器加载或没有绑定任何模型
作者: #linux.do
板块: #搞七捻三
编号: 1543887
帖子: https://linux.do/t/topic/1543887
时间: 2026-01-30 14:06:41
摘要:

这是啥原因，俩号都是，还有就是有没有买anti号的渠道或者Geminipro的，我的cpa上就一个codex认证文件 其他都用不了

标题: 【开源自荐】由于嫌弃claude code，我开发了这个绘图网站
作者: #liu juntao
板块: #资源荟萃
编号: 1543894
帖子: https://linux.do/t/topic/1543894
时间: 2026-01-30 14:08:05
摘要:

上个帖子

  
    
    
    
      小红书小绿书神器来了！【开源自荐】 
  

开发调优
    
  
  
    平时喜欢自己画一些信息图，感觉很好看，所以搓了个项目专门用来使用大香蕉生成信息图。我和cc联合，天下无敌！  
内置12个模板。 
网站内可以配置api直接用，也可以复制prompt，粘贴到gemini或者flow之类的生成。 
佬友们有新的模板也欢迎贡献！ 
在线地址：https://nano-info.aizhi.site/ 
github地址： liujuntao123/…
  


开发的这款文章配图web工具，收到了很多佬友的点赞，因此决定加大力度，网站又做了很多升级！
下面是一些相关介绍。
1. 历史管理
网站内置了完善的历史管理，而且为了隐私，所有的记录都只存在你的浏览器本地。你生成的每一张图、每一句 Prompt，都会被妥善保存。随时查看，随时取用。
2. 提示词探索：拒绝“灵感枯竭”
我集成了 banana-prompt-quicker 的优秀提示词库。你可以一键探索，看中了直接收藏，直接应用。全程非常丝滑。
3. 模版化配图：治愈你的“选择困难症”
针对不同的场景，网站有四套核心模块：

文章配图： 20 多种模版。封面图要不要带标题？出几张图？分辨率多少？全部可视化勾选。
小红书专场： 专门适配了 XHS 的审美，10 多种模版，封面、结尾图、信息布局，一通点选就能搞定。
信息图： 如果你想把干巴巴的文字变成直观的图表，这里有 10 多种布局等着你。
表情包： 做了个一键切图和下载的小工具。方便的做表情包，灵感来源于：GitHub - Tansuo2021/gemini-3-pro-image-preview: Gemini 3 Pro - AI 绘图工作台 (Web Client)

如何使用网站
网站地址：Nano kit - 绘图工作台
开源地址：liujuntao123/nano-kit
配置API
如果想使用网站内的文章配图、小红书配图以及信息图功能，需要配置文本生成的大模型 API，用于撰写提示词。
如果想要在网站内直接生图，则还需要配置图片生成 API，如果不在网站内生图，而是复制提示词去一些别的渠道生图，则不需要配置图片API。
使用
这里不需要做过多介绍，网站的功能一目了然，通过不同的侧边栏进入不同的功能模块，只要配置好了 API，都能直接使用的。

（私藏）免费渠道推荐
对于我来说，AI 生图更多是个人兴趣，还没到必须要花大钱的地步，更何况Nano banana pro还不便宜。相信很多网友和我一样，并不愿意为“非刚需”生图付出高昂的订阅费。
所以，下面推荐两个我私藏的官方的“大善人”渠道：

Google Gemini 官方：
这个不必多说。Gemini Pro 每日的额度相当慷慨，而且支持 2K 分辨率。
Google Flow：
这简直是目前的“纯纯大善人”。Gemini Pro 在这里不仅无限额度，还支持一次出四张图，速度极快，支持2k分辨率。
但是，它也有硬伤： 目前只支持 16:9 和 9:16，不支持正方形和其他尺寸。不过看在它免费且大方的份上，这点小瑕疵完全可以忍受。
地址为：Flow

什么？你没有gemini pro？拜托这里可是L站，随便搜一搜就能知道怎么获取了。
如果觉得有用，欢迎佬友们点赞和给star

标题: 1Password会员怎么能找到合适的价格
作者: #Liu.su
板块: #搞七捻三
编号: 1543896
帖子: https://linux.do/t/topic/1543896
时间: 2026-01-30 14:08:39
摘要:

最近在使用1password，15天的试用马上到期了，用着还挺顺手的，有没有合适的渠道能买个会员的，现在有三种方案，一是海鲜市场买一个，不知道这个价格是什么渠道来的。二是GitHub学生包送password（存疑）。三是家庭组合租。不知道佬友有没有合适的方案推荐一下。还有开源自建就比较麻烦了，先不考虑

标题: clawdbot、moltbot、openclaw又又又改名了
作者: #openmind
板块: #前沿快讯
编号: 1543910
帖子: https://linux.do/t/topic/1543910
时间: 2026-01-30 14:11:05
摘要:

这次又被谁告了 
佬们有啥好玩的用法分享分享，我现在服务器部署、千问模型、飞书sdk，很多功能都得开发skill、脚本扩展，可玩性不高（好在全程可以让它自己开发，加了些拉取技术咨询、定时任务、发送消息的skill）
不过千问不太聪明，有啥免费的国内厂商或者api代理玩玩不

标题: 怎么炒股？（纯小白）
作者: #kikikiaunh
板块: #搞七捻三
编号: 1543915
帖子: https://linux.do/t/topic/1543915
时间: 2026-01-30 14:12:33
摘要:

我想炒股玩玩，但是不知道什么流程，使用什么软件，什么银行卡，有佬可以分享下吗？

标题: 医疗常识哪个模型回答的更好
作者: #Duane
板块: #搞七捻三
编号: 1543916
帖子: https://linux.do/t/topic/1543916
时间: 2026-01-30 14:12:53
摘要:

不知道佬友们以前生病会不会百度？咳嗽两下，一搜百度，晚期了。 
现在就想知道有没有好用的模型，在这方面比较突出的？Doubao/kimi/Qwen/GPT/Gemini…想听听佬们常用的。
主要是想搜一些症状表现，心里有个大概；
话说后脑勺出现红疹子，我用了gemini，还是挺会安慰人的，告诉我大概率是热的，然后教我怎么判断，逐步排查。

标题: anyrouter无法使用 求大佬
作者: #takagavvasum1re
板块: #开发调优
编号: 1543921
帖子: https://linux.do/t/topic/1543921
时间: 2026-01-30 14:13:56
摘要:

标题: 【小声蛐蛐】如果把Kimi官方赠送的Coding Plan集中到一起
作者: #zd1737
板块: #搞七捻三
编号: 1543925
帖子: https://linux.do/t/topic/1543925
时间: 2026-01-30 14:15:11
摘要:

小声蛐蛐，kimi官方送这么多coding plan，如果中奖的都集中在一起是不是可以组一个公益站，爽用一个月kimi 2.5

标题: Google 自動化兩強對決：Gemini Schedule Action vs. Workspace Studio
作者: #cow
板块: #搞七捻三
编号: 1543926
帖子: https://linux.do/t/topic/1543926
时间: 2026-01-30 14:15:14
摘要:

如果你還沒使用過 Gemini Schedule Action，那你已經趕不上 Google 的步伐。 Google 在去年12月為workspace推出了強大的 Workspace Studio。這兩個究竟差在哪？
 Gemini Schedule Action (已推出一段時間)
定位：「聰明隨身秘書」。個人化的對話式指令，幫你「記住」並「執行」未來的任務。
特色： 只要會說話就能設好，適合處理單點式的任務。
案例： 「Gemini，這週五下班前，幫我總結信箱裡所有跟『專案進度』有關的信，並草擬一份進度報告。」
 Workspace Studio (2025 年底新登場！)
定位：「AI 代理人工廠」。 企業級的低程式碼開發平台，用來打造會自動跑、會做決定的「AI Agent」。
特色： 它可以像畫流程圖一樣，串聯數個 Google 服務與第三方工具。
案例： 有人填表單，AI 判斷條件，自動插單到主管日曆，上傳附件到雲端。
 場景大對比：週五的週報地獄
Gemini Schedule Action：
「Gemini，每週五下午 4 點幫我寫週報。」
 效果： 到時間時，AI 會主動跳出來說：「嘿！週報我寫好了，你要看看嗎？」
Workspace Studio：
流程設定： 4 點自動抓 Sheet 數據，AI 轉成圖表，自動寄給老闆。
 效果： 4 點一到，報表已經躺在老闆信箱了，你人可能已經在去吃晚餐的路上。
 總結
Gemini Schedule Action： 簡單、好上手，適合解決「我想讓 AI 晚點幫我做事」的需求。
Workspace Studio： 強大、系統化，適合「我要設計一套不用管也會動的流程」。
 小提醒： 雖然 Workspace Studio 支援自然語言創建流程，但目前它的理解力還在進化中。稍微繞個彎的複雜邏輯，它可能還會「聽不懂」。建議從簡單的固定流程開始玩起！

标题: 过年买新衣服，大家推荐下冲锋衣
作者: #javalaw
板块: #搞七捻三
编号: 1543934
帖子: https://linux.do/t/topic/1543934
时间: 2026-01-30 14:17:10
摘要:

迫于习俗，过年得搞件新衣服，往年每年都是羽绒服，穿腻了，今年想搞件冲锋衣，坐标江浙沪，无户外徒步的需求，性能上只要防寒保暖就行，以时装特性为主，不要一穿上去就感觉要去荒野求生勇闯无人区的那种风格

标题: 号外 cloudcone 恢复登录了
作者: #bwyun
板块: #搞七捻三
编号: 1543937
帖子: https://linux.do/t/topic/1543937
时间: 2026-01-30 14:18:54
摘要:

自己的两只小鸡上午阵亡了，登录也因为不显示验证码无法登录。
好消息：现在可以显示登录码登录进去了
坏消息：登进去操作小鸡显示： We encountered a problem

标题: 【求助】使用 CLI Proxy API 代理 Antigravity/Codex 模型的生成质量如何？
作者: #zhaowendao
板块: #开发调优
编号: 1543939
帖子: https://linux.do/t/topic/1543939
时间: 2026-01-30 14:19:07
摘要:

各位佬友好！最近我在研究通过 CLI Proxy API 调用 Antigravity、Codex 等平台的方案。比较好奇，对于这类通过逆向或代理方式实现的接口，在实际生产力场景中，这些渠道与 OpenRouter 或官方直连 API 相比，体验上是否存在明显差异？
比方说，这类渠道是否存在所谓的"降智"现象？服务端（如 Antigravity）是否会强制注入额外的 System Prompt，从而导致回答风格发生变化？又或者，我自己注入的 System Prompt 是否会因此失效或效果打折？类似 temperature 这样的参数，是否能够正常生效并如实传递给底层模型？
希望有经验的佬友能分享一下使用心得，感谢！

标题: 求工作流应用推荐
作者: #CodeC
板块: #搞七捻三
编号: 1543940
帖子: https://linux.do/t/topic/1543940
时间: 2026-01-30 14:19:32
摘要:

平时会处理一些excel/word/pdf格式技术协议和合同,需要从文件中提取信息(需要用到AI),然后按格式输入到excel/word格式的模板的固定位置中,有什么好的自动化方式可以实现吗?
文件都是公司加密软件加密过的,只能通过公司office软件打开.

标题: 上下文工程：Agent 时代的核心能力
作者: #0.6
板块: #开发调优
编号: 1543944
帖子: https://linux.do/t/topic/1543944
时间: 2026-01-30 14:20:14
摘要:

本人博客链接: 上下文工程：Agent 时代的核心能力 | 0.6的blog
最近读了不少关于上下文工程的资料，发现一个有意思的现象：OpenAI、Anthropic 这些顶级 AI 团队，对上下文工程的看法出奇地一致。这让我想聊聊这个话题，因为它正在成为 2025 年 Agent 元年最重要的技术方向之一。
从提示词工程到上下文工程的转变
你可能会好奇，2024 年大家还在热议提示词工程，为什么 2025 年突然都在谈上下文工程了？这背后的逻辑其实很清晰。
现在2026年,我们终于可以给他们来个回顾总结了.
随着模型参数和训练数据规模的增长，大模型的基准能力已经发生了质的飞跃。它们不再只是简单的指令遵循工具，而是演变成了复杂应用的推理引擎。这个时候，单纯依靠静态的、一次性的文本提示已经不够了。当我们要构建真正的 Agent 时，大模型是作为推理引擎存在的，如何高效利用模型能力就成了关键问题。而想要充分发挥模型能力，管理好上下文就变得至关重要。
业内现在对上下文工程有个新的定义方式。它不再是单个的用户提示或系统提示，而是一组动态的、可结构化的信息组件。这些组件包括指令、外部知识、工具定义、系统提示、用户提示、历史记忆、当前状态等等。通过特定的算法和架构设计，我们可以动态组装和优化这些组件，在模型的上下文窗口限度内最大化输出质量。
换句话说，提示词工程到上下文工程，是从静态到动态的转变。传统提示工程把上下文视为静态文本，而上下文工程更像是一个动态组装函数，可以根据需求灵活组合信息。它的核心目标是解决一个最优化问题：在有限的上下文窗口内，找到最佳的信息组合，最大化任务完成质量。

长上下文的美好愿景与残酷现实
这里就要谈到一个有趣的矛盾了。现在大模型的上下文窗口越来越大，从 256K、400K，到 Gemini 系列的百万级别上下文窗口。按照直觉，我们应该把所有信息都塞进这个超大窗口里，让模型自己处理就好了。
这个想法曾经激发了很多美好的愿景。有了足够大的窗口，你可以把所有工具、文档、指令都扔进提示词，RAG 似乎也不那么必要了。长上下文的出现推动了 MCP 的热潮，让"连接到每一个工具，模型就能做任何工作"的梦想看起来触手可及，也激发了整个 2025 年对智能体的热情。
但实际工程经验和学术研究都告诉我们：更长的上下文窗口并不会自动产生更好的响应。
Anthropic 在他们的文档中明确指出，上下文工程是提示工程的自然演进。提示工程关注如何编写和组织指令来获得最佳结果，而上下文工程则是在大模型推理期间策划并维护最优 token 的策略，它包含的信息远超提示本身。
早期的大模型应用主要针对单次分类或文本生成任务，提示词是工程的主要组成部分。但当我们构建多轮对话的 Agent 时，就需要管理整个上下文的策略了。系统指令、工具定义、MCP 连接、外部信息、权限设置、消息历史等等，这些都会在循环运行中不断生成新数据。上下文工程就是从这些不断演变的信息中，决定什么应该进入有限上下文窗口的艺术和科学。与编写离散提示不同，上下文工程是迭代的，每次传给模型内容时都需要重新策划。
为什么上下文工程如此重要
尽管现在的大模型速度很快，能处理越来越大的数据量，但研究发现，它们和人类一样，会在某个时刻突然失去焦点、感到困惑。
"大海捞针"基准测试揭示了上下文衰减现象：随着上下文窗口内 token 数量增加，模型从中回忆信息的能力会不断下降。虽然不同模型的降级程度不同，但这一特征在所有模型中都会出现。因此，上下文必须被视为边际效应递减的有限资源，就像人类的工作记忆容量一样。
大模型也有自己的注意力预算。解析大量上下文会消耗这个预算，每引入一个新 token 都会在一定程度上消耗注意力。这就要求我们必须仔细策划大模型可用的 token。
这种注意力稀缺性源于 Transformer 架构的底层约束。在 Transformer 中，每个 token 都能关注到上下文中的所有其他 token，产生 N² 级别的配对关系。随着上下文长度增加，模型捕捉这些配对关系的能力自然会被拉伸稀释，在上下文大小和注意力聚焦之间产生权衡。此外，模型从训练数据分布中形成的注意力模式，通常对短序列的处理要比长序列更好。
这些现实因素导致深思熟虑的上下文构建对于构建强大智能体来说非常必要。过分填满上下文，反而可能导致智能体以某种独特的方式失效。上下文会被污染、分散注意力、造成混乱，甚至产生冲突。对于依赖上下文来存储信息、收集信息、思考综合、协调行动的智能体来说，这是一个极其严重的问题。
长上下文的四大陷阱
让我们具体看看长上下文可能导致的问题，然后再讨论如何缓解或避免这些问题。
问题一：上下文污染
上下文污染指的是幻觉或其他错误进入上下文，并被模型反复思考和引用。Google DeepMind 团队在 Gemini 2.5 技术报告中就指出了这个问题。
在实际体验中，如果我们错误地设置了某个设定，但没有及时从上下文中清理，这个设定就会导致后续智能体产生幻觉。上下文中许多部分的目标和摘要会被错误信息污染，这往往需要很长时间才能修正，甚至无法撤销。模型可能会被误导，着眼于实现根本不需要甚至不可能的目标。上下文污染会导致智能体制定荒谬的策略，重复执行错误行为，去追求我们根本不需要的目标。
问题二：上下文分散
上下文分散最常见的情况是上下文变得太长，导致模型过度关注历史信息而忽略了当前任务的核心提示。
在 Agent 的工作流程中，通常是一个循环过程。随着模型不断思考、行动、收集信息、建立历史记录，上下文会不断增长。但过往每一步累积的上下文可能会分散模型的注意力，并没有实际帮助。
以 Gemini 系列模型为例，虽然最大可支持百万级别的 token 上下文，但如何在智能体中有效利用它，依旧是研究热点。在 Agent 设计实践中，相关实验观察到，当上下文超过 10 万到 20 万 token 时，智能体表现会明显下降，倾向于重复其庞大历史中的动作，而不是提出综合且新颖的计划。
这突出了检索时使用长上下文和多步骤生成推理时使用上下文之间的重要区别。智能体不是使用它们的世界知识或内置知识来制定策略，而是着眼于重复其广泛上下文中的过往动作。这导致 Agent 特别容易固步自封，不断尝试同一个方向，面对问题时缺乏思考的灵活性。
研究发现，10 万 token 可以算作有效上下文的一个分界点。只有在有效上下文之内，模型才能最大程度发挥其智能和记忆能力。超过这个窗口，模型的智能会呈指数级下降。对于较小的模型，有效上下文的上限要低得多。例如 Bedrock 的研究发现，3B 到 5B 参数的模型，正确性大概在 32K 左右就开始下降，更小的模型下降得更早。
如果模型在达到上下文窗口上限之前就开始出现异常行为，那么超大的上下文窗口又有什么意义呢？这就是为什么我们需要小心选择模型，并且最重要的是要关注有效上下文长度。
问题三：上下文混乱
上下文混乱是指当我们面对一个问题时，上下文中与这个问题不相关的内容也会被模型参考。
2025 年 MCP 热潮掀起时，愿景看起来很美好：一个强大的模型连接到你的所有服务和工具，自动化完成所有简单重复的任务。这个梦想似乎触手可及，只需要把所有工具描述和 MCP 上下文加载到提示词中就能开始。但实际体验发现，这会是一个很大的问题。即使整合了各种 MCP 工具，上下文混乱依旧会存在。事实证明，太多的工具是一个严重问题。
伯克利函数调用排行榜(Berkeley Function Calling Leaderboard (BFCL) V4)是一个评估模型有效使用工具能力的基准。现在已经发展到第三版，排行榜显示每一个模型在超过指定工具数量时，性能都会下降。此外，伯克利团队还设计了没有提供函数的情况，我们期望模型输出是不调用函数。然而，所有模型偶尔都会调用不相关的函数。
你可以发现，当我们适时减少不相关工具在上下文中的数量时，模型的成功率会有明显提高。如果你把某些东西放到上下文中但没有使用它，模型也同样需要关注它。即使是不相关的信息，或者当前不需要的工具，模型也必须考虑它。
大型模型，特别是推理型模型，在忽略或丢弃多余上下文方面表现得越来越好。但我们也看到，无价值的信息、混乱的信息，甚至冲突的信息，反而会让智能体跌倒，陷入困境。更长的上下文意味着我们可以塞入更多信息，但这种能力在不相关上下文的干扰下，反而会成为缺点。
问题四：上下文冲突
上下文冲突是指在上下文中积累的新信息与其他信息发生冲突。这是上下文混乱更具危害性的版本。这里的冲突上下文不是指不相关的上下文，而是直接与提示词中其他信息产生矛盾的内容。
微软和 Salesforce 团队在一篇论文(https://arxiv.org/pdf/2505.06120)中记录了这一点。团队从多个基准中获取提示词，并将信息分片到多个提示词中。当你使用 ChatGPT 或 Gemini 这种对话式大模型时，有两种方式：一种是在点击回车之前考虑好所有必要细节，一次性发送；另一种是从简单提示词开始，然后不断补充细节，形成多步骤交流。
论文结果显示，分片提示词显著产生了更差的结果，平均下降了 39%。团队测试了一系列模型，下降结果都很明显。
这是为什么呢？答案就在于前面提到的上下文混乱问题。当组装的上下文包含整个聊天对话信息时，不只是我们发送的请求，还有模型