标签：地理服务

前沿哨所

• Claude Code CLI 遭遇配置难题：第三方模型（如 Gemini）无法正常显示

  近日，有开发者在技术社区 Linux.do 反馈，在使用 Anthropic 推出的 Claude Code CLI（命令行界面）时，遇到了无法调用第三方模型的配置故障。该开发者尝试通过环境变量配置，将 Google 的 Gemini 系列模型（如 gemini-pro-agent、gemini-3.6-flash-high）映射到 Claude Code 的不同模型分级中（如 Opus、Sonnet、Haiku），并使用了 sub2api 作为转换端点。尽管在配置文件中明确开启了 `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY` 以启用网关模型发现功能，且配置了具体的模型名称映射，但 CLI 界面在执行 `cc-switch` 获取模型列表时，仅显示默认模型，无法列出或切换这些第三方模型。这一现象引发了关于官方工具对第三方 API 兼容性以及配置文件优先级的技术讨论。

  事件分析

  该事件揭示了当前 AI 编程工具在生态兼容性方面存在的挑战。Claude Code 作为 Anthropic 官方推出的开发工具，其底层逻辑主要针对自家 API 进行优化。开发者试图通过环境变量映射和网关服务来实现“跨模型调用”，这实际上是在探索工具的多模型兼容能力。从技术角度分析，出现“配置了但不显示”的原因可能包括：CLI 工具在启动时的模型验证机制与 sub2api 返回的模型列表格式不匹配，或者 `GATEWAY_MODEL_DISCOVERY` 开关仅对特定类型的端点生效。这表明，尽管开发者希望通过统一的接口（如 CLI）来灵活切换不同的底层大模型（如 Claude 与 Gemini），但目前仍需面对复杂的配置调试与潜在的协议兼容壁垒，未来的工具标准化（如统一协议）将是解决此类问题的关键。

  💡 核心观点：开发者试图打破单一模型生态的锁定，但工具的兼容性配置仍需在适配层进行深度调试。

  原文链接：Linux.do

  刚刚

• Jason Liu 的 Codex 工作坊：别再把 Agent 当聊天框了

  Jason Liu 在 AI Engineer 的这场 Codex 工作坊，表面是在讲 appshots、skills、plugins、memory、automation 和 computer use，实际讲的是一个更大的转向：Agent 不再只是接一次任务的工具，而是在被组织成可长期运行的个人工作系统。原视频：https://www.youtube.com/watch?v=il1c1a2FufU

  这场工作坊真正讲的不是 Codex，而是工作形态

  Jason Liu 开场说，他已经不太知道自己的工作是什么了。

  这句话听起来像玩笑，但很准确。他不是只拿 Codex 写代码。他让 Codex 做原型、跑 eval、改 slide、编辑 iMovie、整理会议纪要、写文档、处理合作事务、追踪项目、生成自动化线程。Codex 在他的使用里不是 IDE 插件，也不是代码补全工具，而是一个能读取上下文、操作电脑、记住偏好、按时间醒来、彼此通信的工作台。

  这也是这场 workshop 最值得看的地方。它没有把重点放在“怎样写一个好 prompt”，而是在展示一个更高级的问题：当模型已经足够能干，人的工作从“把每件事交给 AI 做”转向“把工作组织成可以被 AI 长期接住的系统”。

  这个判断和最近几个月关于 Loop Engineering 的讨论是同一条线。过去是人站在循环里：我提示、AI 输出、我检查、我修正、再提示。新的玩法是让系统自己形成循环：触发、读取上下文、执行、验证、失败重试、写回记忆。人的位置往后退一点，不是退出，而是设计目标、边界和验证口径。

  第一件事：输入方式变了，文字 prompt 不再是主通道

  Jason 很早就提到一个细节：Tony Stark 不会用文字给 Jarvis 发消息。

  他自己用脚踏板做语音输入，一个按钮转录，一个按钮提交。走到桌边，手背在身后，说一段很乱的话：修这个、改那个、顺便给某个 Slack 里的人发个消息。然后他继续和同事聊天。

  这听起来像效率技巧，但它改变了人与 agent 的关系。文字 prompt 通常会逼人把问题压缩成干净的指令。语音输入允许你把脑子里没整理好的版本直接倒进去：背景、犹豫、旁支、模糊记忆、你不确定是哪次会议提到的东西。Agent 再去翻邮件、Slack、会议记录、旧线程，把这些模糊线索变成可用上下文。

  这件事的重点不是“语音比打字快三倍”。真正的变化是：人可以把更多前置上下文交出去。AI 不再只收到一句清洁的命令，而是收到足够还原现场的杂乱材料。

  这也解释了为什么 Jason 一直强调 appshots。他说普通截图信息太少，模型要 OCR，要猜 Slack channel，要猜人名，再调用多轮工具。appshot 同时给图片和 accessibility tree。对 agent 来说，这不是一张图，而是一段可操作的状态：它知道频道 ID、用户 ID、按钮结构和可点击目标。

  截图是“给模型看”。appshot 更像“把当前 app 状态交给模型接管”。

  第二件事：skills 和 plugins 把经验从聊天里搬出来

  这场工作坊里，skills 和 plugins 的定位很清楚。

  Skills 是几份文件、脚本和规则，保存“这类事应该怎么做”。Plugins 则把这些能力打包给团队共享，或者连接到 Slack、Gmail、Notion、Linear、Chrome、电脑控制等真实系统。

  Jason 举了几个很实在的例子。

  一个是 finalize Codex app 的 skill。公司里有人提 PR 前触发它，它会按团队风格和检查规则找问题。另一个是“review my code like Charlie / Dominic”，把某个同事过去一年的 PR review 风格吸收成审查 skill。还有一个是“write like me”，让 Codex 读取过去半年的邮件和 Slack，生成一份自己的写作风格指南，以后写消息就能更像本人。

  这和普通 prompt 的差别很大。Prompt 是一次性委托。Skill 是可复用的工作习惯。Prompt 常常藏在一次会话里，用完就散了。Skill 会被团队、自动化和未来的线程反复读取。

  这正好接上 Karpathy 的 spec / harness / verification 三层方法。模型本身只是底层能力。真正让能力落地的是 harness：上下文怎么带进来，规则怎么存，工具怎么调用，验证怎么跑。Jason 展示的 Codex 使用方式，本质是在把个人和团队的工作经验写进 harness。

  第三件事：记忆不是“偏好列表”，而是工作系统的连续性

  Jason 反复讲 memory，但他讲的不是“我喜欢简洁回答”这种轻量偏好。

  他的个人 monorepo 里有 projects 目录、people 目录、松散笔记、agent summaries、daily summaries、todo list。项目目录记录每条 workstream。people 目录记录打过交道的人、他们在做什么、他们在哪些 Slack channel 里。todo list 由一个 thread 维护，必要时还会派 subagent 去验证某个任务有没有真的完成。

  这类记忆的价值不在“模型下次想起你是谁”。价值在于，agent 不必每一轮从零发现组织结构。

  他举了一个很典型的变化：一开始你必须明确 @mention 插件、指定数据源、说清楚去哪里查。随着项目文档、channel ID、people 信息、旧线程和 memory 都长起来，agent 会自己意识到“这个问题该去读 Slack / Gmail / Linear / 项目文件”。这和新人入职很像。头几个月你要给 SOP、纠错、让他写下教训。几年后你可以只说一句“帮公司多赚钱”，他知道去哪里动手。

  这里有一个容易被忽略的分水岭：记忆不是越多越好，而是要变成可组织、可维护、可检索的文件系统。否则长期记忆会变成跨项目污染。Jason 在 Q&A 里也承认，项目之间的 memory bleeding 需要靠每个项目自己的 AGENTS.md / README 这类局部规则清理。

  这和我自己的 Obsidian / LLM Wiki 经验也一致。RAG 只是取回上下文，Wiki 才是在积累判断。Agent 真正需要的不是一堆历史文本，而是能让下一轮行动少踩坑的结构化经验。

  第四件事：automation 不是新建任务，而是“叫醒同一个工作线程”

  工作坊中段开始，Jason 讲 automations 和 heartbeat。

  早期自动化常见模式是：每天早上创建一个新线程，做一次 morning brief。Jason 认为，随着模型变强，更好的设计是把定时消息发回同一个长期线程。线程保持项目记忆，heartbeat 只是把它叫醒。

  这个细节很关键。

  如果每次自动化都新开线程，系统会不断失忆。每次都要重新读背景，重新判断优先级，重新建立上下文。把 heartbeat 发回同一条 pinned thread，线程就更像一个长期负责某件事的 teammate。

  他把 /loop 描述成“keep an eye on this”。比如：盯着这个 PR，有反馈就修，保证它一直可合并，CI 挂了就处理，直到满足条件。heartbeat 不是神秘功能，只是定期把一条消息投回线程，让它根据当前状态继续行动。

  这和 Loop Engineering 里的 closed loop 完全同构：目标明确，触发明确，检查明确，失败就重试，完成就停止。区别只在于，这里 loop 的载体不是一个脚本，而是一个长期线程。

  第五件事：/goal 的核心是 verifier，不是更长的任务描述

  Jason 对 /goal 的解释很短，但信息密度很高：它定义一个 verification step。只要验证没过，就继续做。

  这就是 goal 原语的关键。

  很多人以为 goal 是“给 AI 一个更大的任务”。其实 goal 的价值不在任务更大，而在停机条件更清楚。没有 verifier，agent 只能自我汇报“我觉得做完了”。有 verifier，promise 才变成 contract。

  Jason 举的例子是迁移软件到 Rust：如果这个 Python 项目适合迁移，就迁移后端到 Rust，并保证所有 unit tests pass。他说自己用这种方式重写过 rich terminal library，也试过 rewrite UV 和 TypeScript，看能不能做到 100% test coverage。

  无论例子多夸张，原则很朴素：生成能力越强，验证越重要。Karpathy 那套 spec / harness / verification 里，最不贬值的一层也是 verification。Spec 和 harness 会随着模型变强而变化，但“怎么知道它真的做对了”不会过时。

  第六件事：computer use 把 agent 从“文件系统”带到“桌面世界”

  Jason 说 computer use 是他第一次在工作中有“AGI 感”的功能。

  它不是只能控制浏览器，而是可以在后台操作任意 app。Chrome extension 控制 Chrome，computer use 控制 Slack、iMovie、交易软件、系统 app，甚至通过屏幕镜像控制 iPhone。Jason 用它导出 iMovie、给视频加音效、填表、签 DocuSign、找传真服务发医疗记录、在 checkout 页面找优惠券、测试 native app。

  这部分最容易被当成 demo 看热闹。但它背后的意义是：agent 的执行面从代码和 API 扩展到了整台电脑。

  这会带来真正的安全问题。Jason 特意讲到：如果 Slack connector 不能上传文件，一个很“坚定”的模型可能会打开电脑控制，点文件上传按钮绕过去。如果 Gmail connector 发不出邮件，它可能打开 Chrome 去点发送。能力越强，权限边界越要清楚。

  所以他提到 permission sidebar：可以要求每次操作都询问，也可以开放更高权限。工程上，这对应 agent harness 里的 G 层：governance / gate。不是模型“会不会乱来”的问题，而是系统有没有把高风险动作放在可审计、可拦截的位置。

  第七件事：线程可以互相通信，个人 agent 系统开始出现组织结构

  工作坊后半段，Jason 讲了一个更有意思的方向：threads can talk to each other。

  每个线程可以列出其他 pinned threads，可以重命名线程，可以给别的线程发消息。这样你不只是有一堆 subagents 在后台跑，而是有一组可见、可命名、可管理的工作线程。

  他的例子是支持问题监控。一个 monitor thread 发现 Twitter 或 Slack 上有人反馈某类问题，就创建一个 triage thread。triage thread 负责调查、联系相关人、跟进 PR 或 Slack ack。如果之后又有人抱怨同一个问题，monitor thread 会识别“这是同一件事”，然后给之前那个 triage thread 发消息：这个问题又复现了。

  这已经不是单个 agent 完成单个任务，而是 agent 之间有分工、状态、引用和升级路径。

  这也解释了他为什么喜欢 pinned threads。普通 subagent 像后台漂浮的实体，用户很难长期感知它们。Pinned thread 出现在 sidebar 里，你能看到某条 workstream 还活着，能改名，能叫醒，能让别的线程给它补上下文。

  这是一种很早期的“个人组织结构”。IC thread 做具体任务，manager thread 追踪状态，monitor thread 发现外部信号。今天看起来还很手工，但方向已经很清楚。

  这套方法的真实门槛：不是 token maxing，而是 taste

  Jason 整场一直在弱化“烧 token 很酷”这件事。他说自己不是最大的 token maxer，也看到有人每天烧几十亿 token。目标不是浪费 token，而是避免浪费 token。

  这句话很重要。Agent 系统最大的浪费不是 token 本身，而是让 agent 每轮重新发现同样的上下文、重复犯同样的错、在没有验证口径的状态下长跑。

  Q&A 里有人问，AI 快速变化后，开发者还该练什么。Jason 的回答很老派：要有 taste，就要多吃。多试 app，知道好的 onboarding 是什么感觉，知道什么体验让你烦，发展一套描述坏东西的词汇。你描述不了自己不懂的东西。

  这段和前面所有自动化正好形成平衡。Agent 可以跑很远，但 taste 仍然在人这边。你决定什么应该变成 skill，什么应该变成 goal，什么应该拆成新 thread，什么只是一次性消息。你决定哪些动作可逆，哪些必须 human gate。你决定 loop 什么时候停。

  Loop Engineering 那篇材料里有一句话很适合放在这里：两个人可以搭出一模一样的 loop，一个用它加速自己深刻理解的工作，另一个用它逃避理解。Loop 分不出区别，你能。

  对我们有什么用

  如果把这场 workshop 压成几条可执行判断，我会保留这几条。

  第一，别再把 agent 当聊天框。能沉淀的流程要写成 skill，能验证的目标要写成 goal，能定时检查的状态要交给 heartbeat，能长期负责的工作流要放进 pinned thread。

  第二，记忆要文件化。项目、人物、决策、旧线程、操作日志都应该有可读的位置。不要指望模型神奇记住一切，给它一个能成长的工作目录。

  第三，先做 closed loop。目标、权限、输入、输出、验证、失败重试、停止条件都讲清楚。open loop 可以探索，但没有 quality gate 的 open loop 只是昂贵噪声。

  第四，computer use 和 appshot 值得重视。API 是干净世界，桌面是真实世界。真正的个人 agent 会同时需要二者，但权限门禁必须跟上。

  第五，最该投资的是 verification。模型会越来越会生成，真正稀缺的是你能不能定义“什么叫做了、什么叫做对了、什么情况下必须停下来问人”。

  Jason 这场工作坊不像一个“Codex 新功能介绍”。它更像一次真实用户把产品推到边界后的现场报告。真正的新东西不是某个按钮，而是工作单元正在从“单次对话”变成“长期线程”，从“提示模型”变成“设计循环”，从“AI 帮我做事”变成“我维护一套会醒来、会读上下文、会操作电脑、会互相沟通的工作系统”。

  这也是 Codex Maxing 最容易被误解的地方。表面上是 token、线程、自动化和权限。底层其实是工作治理：你怎样把自己的判断、经验、边界和验证写进系统里，让 agent 不只是更勤快，而是真的更可靠。

  刚刚

• GitHub开源新项目：一键生成手绘风英文教学短视频，支持动态分镜演示

  开源社区 Linux.do 近期发布了一项基于 GitHub 的视频生成项目更新——“story-handdrawn-remotion”。该项目由开发者 liangdabiao 维护，定位为一款能够将中文故事文本或英文教科书内容转化为“手绘日记漫画风”竖屏短视频的 AI 工具。该项目是此前备受社区好评的“英语老师”项目的升级迭代版本，核心亮点在于其独特的视频生成方法论：不同于传统的静态图片配文字朗读，该项目将每一句故事拆解为“文字展示、黑白画稿呈现、彩色插画揭示”三个阶段，通过横向擦除的动态效果，让内容以“画出来”的方式呈现三次。这种技术路线显著提升了视频的视觉连贯性和教育吸引力。用户仅需输入一句话或一段文本，系统即可自动生成包含流畅语音讲解、教育单词图片以及双人对话画面的完整教学视频。该项目完全开源，遵循社区规范，标志着自动化视频生成工具正从单一功能应用向特定场景下的智能“技能”演进，为教育自媒体创作者提供了高效低成本的解决方案。

  事件分析

  此次项目更新展示了 AI 视频生成技术在垂直领域的精细化发展趋势。技术层面上，该项目通过引入 Remotion 框架和分阶段视觉揭示逻辑，突破了当前主流 AI 视频工具“PPT 式轮播”的静态限制，利用程序化动画实现了更具叙事感的动态效果，显著提升了成片的专业度与观赏性。从产业视角观察，开发者提到的“从开发应用程序转向开发技能”的观点，准确捕捉了当前软件架构的微服务化和 Agent 化趋势。随着大模型能力的下沉，轻量级、针对性极强的“技能”模块正逐渐取代臃肿的 All-in-one 应用。此类开源项目的涌现，意味着高质量教育内容的制作门槛被大幅降低，未来 AIGC 将更多地通过特定工作流嵌入专业生产环节，推动内容创作从手工劳动向智能辅助的实质性转型。

  💡 核心观点：AI视频生成正从静态拼接向动态叙事演进，轻量化的“技能”模式将取代传统APP，重塑内容生产的边际成本。

  原文链接：Linux.do

  刚刚

• Cloudflare OS：基于 Sandstorm 安全模型的开源 AI 生产力环境

  Cloudflare OS 是一款由前 Sandstorm.io 创始人 Kenton Varda 开发的开源 AI 生产力环境。该项目被视为 Sandstorm 的精神续作，核心架构基于 Cloudflare Workers 边缘计算平台，并深度融合了生成式 AI 技术。Sandstorm 以其独特的粒度权限控制和沙箱安全机制闻名，Cloudflare OS 继承了这一特性，宣称其安全模型可以确保应用本身不存在安全漏洞。这一特性完美契合了当前的“Vibe Coding”（直觉式编程）趋势，允许用户在 AI 辅助下生成代码并直接运行、分享，而无需担心底层环境的安全风险。该项目完全开源，支持用户在本地（如地下室服务器）进行自托管，并已实现对 Home Assistant 等智能家居平台的连接，为开发者和极客提供了一个既安全又高效的 AI 应用开发沙箱。

  事件分析

  从技术架构来看，Cloudflare OS 探索了“边缘计算 + 沙箱安全 + AI 生成代码”的深度融合路径。传统的操作系统往往依赖复杂的权限管理，而 Cloudflare OS 利用 Cloudflare Workers 的隔离特性，将安全边界下放到应用实例级别，这在理论上极大降低了 AI 生成不可信代码带来的安全风险。产业层面，这标志着开发工具正在从“代码编辑器”向“AI 应用运行时”转变。随着 AI 编程（如 Vibe Coding）逐渐普及，缺乏安全运行时一直是制约其落地的瓶颈，Cloudflare OS 提供了一种可行的解决方案。未来，此类模式可能推动软件开发从传统的工程构建转向基于对话的即时生成与部署，特别是在物联网和个人自动化领域，有望催生出一批轻量级、高安全的 AI 原生应用。

  💡 核心观点：Sandstorm 的安全模型嫁接 Cloudflare 边缘算力，为 AI 生成代码提供了必要的安全沙箱，是“Vibe Coding”从玩具走向生产环境的关键基础设施。

  原文链接：Hacker News

  刚刚

• 基于高斯Splatting的开源绘画工具：用纯数学算法模拟真实笔触

  这篇文章介绍了一款名为“Painting with Gaussians”的开源图像处理项目。开发者不依赖当前的生成式AI大模型，而是通过纯数学算法将普通照片转化为具有数字绘画风格的艺术图像。核心技术方面，作者摒弃了常见的梯度下降迭代优化方法，转而采用确定性追踪算法，将画笔笔触建模为二维高斯泼溅，其中均值代表笔触位置，协方差矩阵代表笔触的拉伸和旋转方向。为了达到逼真的绘画效果，项目整合了多种传统图形学技术：利用结构张量和Di Zenzo颜色张量提取图像边缘及色彩梯度以确定笔触流向；通过Haar小波分解生成细节能量图，自适应控制笔触的密度与大小（平坦区域用大笔刷，细节丰富处用细笔刷）；引入Wang avalanche hash消除网格排列的人为痕迹；利用Perlin噪声模拟手绘时的自然抖动与流动感；并设计了分层渲染机制，从底色大色块到顶层的高光细节逐层叠加透明度。性能方面，项目最终将计算管线从CPU迁移至GPU，利用OpenGL的几何着色器和变换反馈技术，实现了交互式的参数调整与实时渲染。这不仅是对Clojure生态中Jolt编译器和Glimmer GUI库的一次实战检验，也展示了在AI时代之外，传统算法结合硬件加速在图像艺术领域的巨大创新潜力。

  事件分析

  从技术维度看，该项目巧妙地融合了结构张量、小波变换与Perlin噪声等经典算法，构建了一套高效的“绘画-物理”映射模型。将笔触解构为高斯分布并利用GPU进行并行化渲染，极大地提升了非神经网络图像处理算法的执行效率。从行业趋势看，在生成式AI（AIGC）占据主导地位的当下，这类“逆向工程”式的风格化工具为图像处理提供了另一种思路。它证明了传统的确定性算法在可控性、可解释性以及硬件加速层面依然具有独特优势，避免了AI生成中常见的“幻觉”与不可控性。此外，该项目使用Clojure及Jolt编译器进行高性能图形化开发，也为函数式编程在图形学与端侧应用场景中的潜力提供了新的参考案例。

  💡 核心观点：在生成式AI统治图像艺术的当下，传统算法结合GPU加速依然能提供高可控性且极具艺术感的图像处理方案。

  原文链接：Hacker News

  刚刚

• 谷歌 oghttp2 拖累 Envoy 性能：一次深度的 HTTP/2 编解码器性能剖析

  近日，Apoxy 团队在为客户升级 Envoy 代理时发现，CPU 使用量异常增加了约 20%。经排查，问题根源在于 Envoy v1.34 版本将默认的 HTTP/2 编解码器从 `nghttp2` 切换到了 Google 的 `oghttp2`。尽管两者功能一致，但在高流量压测下，`oghttp2` 在处理头部解压（HPACK）时出现了显著的性能回退。文章通过火焰图深入剖析，指出问题并非出在霍夫曼解码算法本身，而是 C++ 实现中的“管道开销”。`oghttp2` 在解码过程中过度依赖 `std::string::push_back` 进行逐字节写入，导致频繁的内存分配检查，且头部块处理涉及多层哈希查找和内存拷贝。相比之下，`nghttp2` 采用查表法的有限状态机直接写入预分配缓冲区，避免了不必要的开销。这一差异导致在头部密集型代理流量中，CPU 效率出现了显著的倒退。目前 Envoy 团队已在 v1.37 版本中回滚了默认设置，并承诺待 `oghttp2` 性能对齐后再行切换。

  事件分析

  此次事件揭示了高性能网络基础设施中“抽象税”的代价。虽然 C++ 高层抽象能提高代码可维护性，但在每秒处理数万个请求的热路径上，内存分配策略和数据结构选择比算法本身更能决定性能瓶颈。`nghttp2` 作为老牌 C 实现，其对内存的精细控制使其在头部密集型流量中依然保持优势。对于基础设施维护者而言，这提醒了基准测试的重要性：微小的依赖库变更可能导致显著的运营成本波动。这也推动了业界对高性能 C++ 网络库编写规范的反思，即在追求现代 C++ 特性的同时，必须保留针对极限性能优化的降级路径。

  💡 核心观点：基础设施升级不仅是依赖库版本号的变化，更是对底层内存管理与代码实现细节的极限审视。

  原文链接：Hacker News

  刚刚