标题: 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%。团队测试了一系列模型，下降结果都很明显。
这是为什么呢？答案就在于前面提到的上下文混乱问题。当组装的上下文包含整个聊天对话信息时，不只是我们发送的请求，还有模型

标题: cursor写前端真厉害啊
作者: #愉快的保姆
板块: #搞七捻三
编号: 1543945
帖子: https://linux.do/t/topic/1543945
时间: 2026-01-30 14:20:26
摘要:

感觉cursor写前端好简单了代码质量比trae之类的高好多噢

标题: 度日如年 这个熏的我头疼可以申请工伤鉴定吗
作者: #再看一集
板块: #搞七捻三
编号: 1543947
帖子: https://linux.do/t/topic/1543947
时间: 2026-01-30 14:20:40
摘要:

申请工伤认定。
半年没换过的鞋，这哪是上班，这是在渡劫。
感觉空气里都有颗粒感，吸一口提神醒脑，吸两口原地升天。这味道，辣眼睛。
#职场历险记 #生化武器

标题: anyrouter下午挂了么
作者: #zachQ
板块: #搞七捻三
编号: 1543949
帖子: https://linux.do/t/topic/1543949
时间: 2026-01-30 14:21:28
摘要:

这周从周一坚持到了周五，今天下午挂了么，开始疯狂500错误了

标题: Codex 更新： web_search 实时查询
作者: #MineMine
板块: #开发调优
编号: 1543954
帖子: https://linux.do/t/topic/1543954
时间: 2026-01-30 14:22:32
摘要:

Grok 的解释应该是对的，默认的 cached 方式从 OpenAI 内部数据库查询，不访问互联网，更快一些，而 live 模式查询互联网信息。

默认是 cached，前两天触发后确实挺快的，也可以调整成从互联网获取实时数据，修改为
web_search = "live"

标题: 代理速度异常缓慢
作者: #Xuyufenfei
板块: #开发调优
编号: 1543955
帖子: https://linux.do/t/topic/1543955
时间: 2026-01-30 14:22:44
摘要:

请教一下大佬，搞了一台纯v6的小机， XTLS + reality协议搭了一个代理，移动数据流畅使用，但是一连上家里的wifi速度就变慢，可是上传速度却正常，睡了一觉，早上醒来速度又正常了，然后过了一个小时，速度又慢了，这是为啥ps:现在换了Hysteria2，速度还行

标题: 公益站anyrouter api
作者: #yqlxj
板块: #福利羊毛
编号: 1543961
帖子: https://linux.do/t/topic/1543961
时间: 2026-01-30 14:23:55
摘要:

贡献500刀的一个api，大家蹬蹬.
sk-w8jDhQfMvMj6hFNfJ5ZyhUJWozB0zmxxJCT28veLbwUanYxz

标题: [持续优化中]看你的月薪在古代值几两银子？
作者: #氯雷他定
板块: #开发调优
编号: 1543964
帖子: https://linux.do/t/topic/1543964
时间: 2026-01-30 14:24:08
摘要:

新增画像生成、添加消费力预警和跨时空点评功能！
体验地址：https://silver.lz-t.top/
开源地址：https://github.com/liu-ziting/SilverEra