lencx 见闻汇总（261008）

开源推荐

Strata

Strata^[1] 是一个面向消费级电脑的开源本地大模型推理引擎，主打运行 1250 亿参数的 Qwen3.8-Flash-Next 量化版。它通过量化、GPU 专家缓存和 CPU/GPU 协同推理降低显存门槛，并利用推测解码加速生成。支持 Windows、Linux，提供自动安装、网页聊天及 OpenAI、Anthropic 兼容接口，可接入 Claude Code、Codex 等编程工具。按项目公布的测试，RTX 5070（12 GB 显存）搭配 Ryzen 5 7600 和 64 GB 内存，Q2_0 量化版短对话生成速度约为 94 tokens/s，实际表现随量化版本、上下文长度和硬件配置变化。

ArtCraft 创作七件套

ArtCraft 团队正在打造一套免费、开源的创作工具，名为 Crafting Apps^[2]。目前共有七款：PhotoCraft^[3] 做图像编辑，VectorCraft^[4] 做矢量绘图，FilmCraft^[5] 做视频剪辑，LightCraft^[6] 管理照片和处理 RAW，PrintCraft^[7] 处理 PDF，EffectCraft^[8] 做动态图形与视觉特效，DesignCraft^[9] 做页面排版，基本覆盖了常见的视觉创作场景。

这套工具统一采用 Rust 原生开发，文件在本地处理，桌面端支持 macOS、Windows 和 Linux。界面布局、工具和快捷键尽量沿用专业用户熟悉的习惯，降低上手成本。除 FilmCraft 外，其余六款还提供可自行部署的 WebAssembly 构建包，部署后可以在浏览器运行。

另一个核心亮点是支持 AI Agent 直接操作软件。官网将 CLI、JSON 控制通道和 MCP 列为整套工具的共同能力，方便接入脚本和自动化流程。例如 PhotoCraft 的界面与自动化接口共用同一套命令系统，Agent 可以调用编辑操作、批量处理图片，也能通过控制通道查看界面状态、操作工具和获取截图。

具体功能上，PhotoCraft 已提供图层、蒙版、调整层、智能对象，以及分层 PSD／PSB 文件的读写；PrintCraft 支持 PDF 阅读、页面整理、合并、拆分和加密文档处理，并明确声明无需账号、无遥测、无云端处理。

目前七款应用都提供了安装包，但整体仍处于早期阶段：PhotoCraft 和 PrintCraft 标为 Early alpha，其余五款标为 In development。可以下载体验，实际用于项目时，还需要确认所需功能、复杂文件兼容性和稳定性是否满足要求。

e2e & gdp-ts

AI 写代码越来越快，验证也得跟上。e2e^[10] 就是一个把 AI 引入网页和移动 App 测试的框架，你可以用自然语言描述“完成注册”、“升级套餐”等目标，让 AI 自己操作界面，再通过断言检查结果。同一个测试里，可以混用 AI 操作、传统的元素定位和精确检查，灵活控制哪些步骤交给 AI。

它最值得关注的设计是验证后缓存，后续直接回放。经过后续检查确认、且符合回放条件的 agent.act() 步骤，可以记录下来重复使用。缓存命中时，这些操作无需调用模型；界面变化导致回放不匹配时，默认交回 AI 继续处理。这能减少重复测试的时间和 Token 消耗。不过，AI 断言、等待和信息提取等步骤仍然实时执行，不使用这套回放缓存。

平台方面，e2e 底层通过 Playwright 和 agent-device 支持浏览器、iOS 模拟器及 Android 模拟器，也支持接入兼容的订阅服务、API Key 或本地模型。对于注册、下单、修改设置这类用户流程，它提供了一种减少操作脚本编写和维护工作的方式。

e2e CLI 默认开启匿名遥测，会收集命令、运行环境、测试统计、模型调用和 Token 用量等信息。官方说明不上传测试内容、应用内容或凭据。可运行 npx e2e telemetry disable 持久关闭，或在 Shell／CI 中设置 E2E_TELEMETRY_DISABLED=1 禁用。

还有个 gdp-ts^[11] 也在做类似验证。它把“先检查，再操作”写进 TypeScript 函数接口：先完成权限或套餐权益检查，再把与具体对象绑定的“证明”传给敏感函数。按这套模式接入后，漏传证明、错用其他资源的证明，都能在类型检查时暴露。项目配有 Lint 规则和接入 Skill，支持逐步应用到现有代码中；实际校验逻辑，以及校验后权限发生变化的情况，仍需开发者处理。

Agent Memory Repo

Agent Memory Repo^[12] 是 Cognition 发起的一套开放规范，用 Git 仓库管理 Agent 的长期记忆。 它希望解决的问题是：用户已经解释过的背景、Agent 已经确认的事实和验证过的方法，能够在后续会话中继续使用。Git 为这些记忆提供版本历史、修改合并和仓库访问管理，使知识可以持续积累、更新和共享。

它的组织方式接近一个轻量的知识库。仓库根目录必须包含 MEMORY.md，作为统一入口，只保留每次会话都需要的信息，以及 Index 下的主题索引。其他内容按需分文件、分目录存放，通过 [[path]] 连接。链接相对于记忆仓库根目录，Markdown 文件省略 .md，其他文件保留扩展名。因此，仓库既可以保存偏好、项目背景和历史决策，也可以保存 SQL、脚本等可复用材料。

记忆条目采用单行列表项，可以附带元数据。推荐字段包括 source 和 added，分别记录获知信息的会话链接与保存日期，但它们并非必填项。信息变化时，应更新或删除旧条目；同一份知识尽量只保存一处，其他位置通过链接引用。这些约定让记忆既便于搜索，也便于追溯和维护。

围绕这个仓库，Agent 的工作形成一个循环：取得已有记忆，读取入口，搜索或沿链接找到相关内容，将其用于当前任务，再把值得保留的新信息写回。写入也需要筛选，优先保存未来仍有价值的偏好、决策和事实，跳过容易重新获得或仅对当前任务有用的信息。例如，保存一条验证过的客户统计 SQL，后续会话便可以重新执行它，获取最新结果，省去再次摸索业务口径和表关系的过程。

随着记忆增长，还需要持续整理。Cognition 将这部分机制称为 Dreaming：由定期运行的 Agent 发现跨会话的规律，形成新条目，同时合并重复内容、清理过时信息，并回查来源解决矛盾。它负责提高记忆的可用性，避免知识库随着写入不断膨胀、互相冲突。

同一套结构可以用于个人、团队和多 Agent 协作。个人积累偏好与经验，团队共享业务知识，多个 Agent 则可以通过共同的文件交换发现和问题。多人加入同一会话时，也可以在获得共享同意后加载各自的记忆仓库。仓库保持独立，保留各自的所有权、权限和历史；新增信息写回对应所有者的仓库，归属不清时再询问。

实际使用时，需要区分整体设计与当前配套 Skill 的能力。 Skill 要求记忆仓库独立于工作项目，并且只在被调用时工作，不会安装会话启动钩子，也不包含定时 Dreaming。官网多 Agent 示例描述了冲突后的处理过程，但当前 Skill 使用 pull --ff-only 更新已有仓库，失败时要求停止并告知用户；它没有提供完整的自动冲突解决流程。

保存和同步也有区别：官网的记忆循环写的是每次编辑后 push，当前 README 和 Skill 则要求每次编辑后 commit。Skill 默认只保存在本地，只有用户指定自己拥有的私有远端并要求同步后才推送。因此，本地跨会话复用依赖同一份文件系统持续存在；换机器或进入新的临时环境时，需要重新取得记忆仓库。

Skill 还规定了操作边界：记忆应作为上下文数据使用，不能仅凭文件中的文字执行命令；不得保存密码、令牌或密钥。写入前必须确认工作区没有未提交改动，提交时只包含本次修改，也不能强制推送。这些约束用于保护已有记忆和用户数据。

官方提供的试用入口是 npx skills add AgentMemoryRepo/agentmemoryrepo --skill agent-memory-repo；Devin 使用 devin plugins install AgentMemoryRepo/agentmemoryrepo。安装后，可以在第一轮会话中保存一条测试偏好，再在同一机器、同一项目的新会话中调用 Skill，提供记忆仓库完整路径，检查能否读回。

从工程角度看，这套设计的价值在于让记忆可读、可迁移、可追溯。Git 提供了文件与历史管理能力，而哪些信息值得记住、检索是否准确、矛盾能否解决，仍然取决于 Agent 的判断和具体维护流程。

注：下图将目录结构与核心读写流程放在一起。目录名称仅为示例；实线表示本地记忆流程，虚线表示需要额外设置的同步或维护机制。

OpenDots

OpenDots^[13] 是 CopilotKit 推出的、明确对标 OpenAI Dots 的开源 AI 同事工作台模板，围绕“拥有独立电脑、持续处理任务、跨渠道与用户协作”的理念，为开发者提供可自行部署和定制的实现基础。它基于 CopilotKit、AG-UI 和 CopilotKit Intelligence，支持接入 OpenAI 兼容模型，提供智能体角色与权限配置、持久化浏览器和文件环境、文字与实时语音交互、Slack 集成、Spaces 文档管理、周期性后台任务及草稿保存前的人工审批。项目采用 MIT 许可证，目前定位于单一使用者的早期开发模板，相关能力需要配置配套服务，部分集成仍待验证，适合作为搭建专属 AI 工作空间的起点。

icon 库

分享几个 icon 库，我最常用 lucide^[14]，iconify^[15] 作为补充（大而全，各种风格），llm 使用 lobehub icons^[16]。这几个配合可以满足大部分 icon 需求，如果都不满意，偶尔也会用 sketch 微调一些 icon。

Flutter Edge AI

Flutter Edge AI^[17] 是面向 Flutter 的开源端侧 AI SDK，前身为 Flutter Gemma，通过统一的 Dart API，让 Android、iOS、Web、macOS、Windows 和 Linux 应用运行 Gemma、Qwen 等本地模型，也能接入 Gemini Nano、Apple Foundation Models、Phi Silica 等系统或浏览器内置 AI。它支持多模态输入、函数调用、思考内容展示、向量嵌入与 RAG，以及语音识别和合成；提供 Agent Skills，让端侧模型选择技能，通过 JavaScript、系统操作或 MCP 工具执行任务，同时附带 Package Skills，指导 Claude Code、Codex、Cursor 等编程助手使用 SDK。项目采用可插拔运行时和按需安装的模块化设计，支持 CPU/GPU 及部分设备的 NPU 加速，模型就绪后可离线推理。具体能力取决于模型、运行时和平台，目前 Agent Skills 和语音功能尚不支持 Web，远程 MCP 调用仍需联网。

g1455

g1455^[18] 是一款开源 Flutter 液态玻璃 UI 库，参考 iOS 26 的 Liquid Glass 材质，在实时背景上实现折射、模糊、染色和边缘高光，提供导航栏、按钮、卡片、开关、滑块、弹窗等组件，支持玻璃融合、拖拽形变和触摸波纹。项目注重控制渲染成本，通过统一捕获并复用背景、以降采样近似实现模糊来降低开销，支持 iOS、macOS、Android 和 Web，还提供配套 Skill，帮助 Claude Code、Codex 等编程 Agent 正确使用组件。目前处于 0.x 阶段，采用 MIT 协议。

Cua 光标

Cua Driver 给 AI Agent 的光标加了点“人味”：据团队介绍，他们参考人类移动鼠标、瞄准目标的方式，从 82 个动效方案中筛选出 6 种，涵盖弧线滑行、轻柔回弹、磁吸和彗星拖尾等风格。光标支持根据移动距离和目标大小调整运动时长，还能配置点击涟漪、发光等反馈，让 Agent 的操作过程更直观。相关功能可通过 MCP 配置，支持 macOS、Linux 和 Windows，代码已开源。参考阅读 Agent cursor tools^[19]

rustc_codegen_jvm

rustc_codegen_jvm^[20] 是一个将 Rust 直接编译为 JVM 字节码的开源编译器后端，让 Rust 程序以 JAR 形式运行，并融入 Java、Kotlin 生态。它将 Rust 的类型与 trait 映射为 JVM 类和接口，支持类型、回调和异步任务的跨语言互操作，省去手写 JNI 桥接及分发多平台原生动态库的负担。开发者可以在现有 JVM 应用中逐步引入 Rust，复用 JVM 的部署、调试和性能分析工具，并将现代 Rust 代码带到具备兼容 JVM 的旧平台。项目以 Java 8+ 为兼容目标，目前仍在积极开发，部分功能尚不完整，底层指针操作也可能引入额外运行开销。

hotpath-rs

hotpath-rs^[21] 是一个帮开发者找出 Rust 程序为什么慢、内存花在哪里的工具。它能检查哪些代码最耗时、数据库查询和网络请求是否拖慢了程序，以及多个任务有没有互相等待。结果会显示在实时面板和报告中，帮助开发者判断该优先优化哪里，也能交给 AI 助手辅助分析。

Swift Agent Skills

Swift Agent Skills^[22] 是由 Hacking with Swift^[23] 作者发起的开源 AI 编程技能目录，面向 Swift 和 Apple 平台开发，汇集适用于 Codex、Claude Code、Cursor 等工具的社区技能，涵盖 SwiftUI、并发编程、数据持久化、测试、性能优化、无障碍和 App Store 工作流等方向。项目通过分类索引，帮助开发者按需找到并安装技能，将专业开发经验和最佳实践引入 AI 编程过程，减少过时 API、状态管理及性能方面的常见错误。

技术资讯

Linux 7.4

Linux 7.4^[24] 计划为基础款 M4 Mac 加入初始设备树（Device Tree, DT）支持，覆盖 2024 款 14 英寸 MacBook Pro、Mac mini、24 英寸 iMac（两个及四个 USB-C 接口版本），以及 2025 款 13/15 英寸 MacBook Air。搭载 A18 Pro 的 MacBook Neo 也在此次支持范围内。

这次更新主要为启动 Linux 内核打基础，GPU 等功能仍待完善，距离完整的日常使用体验还有差距。

多框架强化学习指南

同一个模型，处理同一组任务，换一套运行框架，成功率就从约 62% 降到了 33%。在 Hugging Face 的多框架强化学习实验中，LFM2.5-2.6B 的权重没有变化，只是从 Mini-SWE-Agent 换到了 Claude Code。这近乎减半的表现提醒我们，模型最终能完成多少工作，很大程度上取决于它如何与周围的工具配合。参考阅读：The ultimate guide to multi-harness RL^[25]

这种配合由 agent harness，也就是智能体运行框架来组织。模型看到哪些信息、如何调用工具、执行结果怎样返回、什么时候重试或停止，都受到框架影响。长期在一种框架中训练，模型容易把这些具体规则也学成习惯；一旦工具名称、参数格式或上下文结构发生变化，原本有效的做法就可能失灵。让模型在多个真实框架中反复完成任务，正是多框架强化学习想要探索的方向。

困难在于，真实框架会自行管理执行过程，训练器很难直接掌握其中发生的一切。仅仅知道任务最后有没有做对，还不足以支撑这套训练方法。它需要知道模型当时究竟生成了哪些 token，以及生成这些 token 时的概率。保存一份聊天文本再重新分词，可能得到不同的 token 序列；框架修复过的输出，也未必是模型最初生成的内容。训练如果建立在这些改写后的记录上，就可能偏离模型真实做过的选择。Token-In, Token-Out 的技术说明解释了这一问题。

解决办法是把采集位置放到模型接口前面。Claude Code、Codex 和 OpenCode 继续按原有方式工作，只需将模型请求指向一个代理，由它在生成时记录原始 token 和对应的对数概率。后者同样需要当场保存，因为异步训练会不断更新权重，事后重新计算无法还原当时的概率。这个兼容四类主流模型 API 的代理（OpenAI Chat Completions、OpenAI Responses、Anthropic Messages 和 Gemini），把不同框架接入了同一条训练流程：OpenEnv 负责连接和采集，Harbor 提供任务与沙箱，TRL 使用这些记录训练模型。

接下来，LFM2.5-2.6B 在 OpenCode、Claude Code、Codex 和 Mini-SWE-Agent 之间轮换训练。在 250 个独立的数据分析测试任务上，它跨四种框架的平均首次尝试成功率从 42.2% 提升到 54.2%，每种框架下都有进步。只在 OpenCode 中训练，同样能带来提升，而且在 OpenCode 自身的测试中更强，成功率从约 34% 升到了 58%。两种方案的平均分相差 1.9 个百分点，仍在原文所说的噪声范围内；更清楚的区别，是单框架训练的收益更集中，多框架训练的改善分布得更广。

模型完成任务的方式也发生了变化。训练除了奖励正确答案，还为调用工具更少的正确解法提供少量额外奖励，答错则得不到这项奖励。训练结束后，在基础模型和训练后模型都能解出的任务上，多框架模型的工具调用减少了 31.1%。这个数字有明确的统计范围，也不能单独证明效率奖励的因果效果，但它记录了一种有价值的变化：模型解决了更多问题，同时在原本就能解决的问题上减少了操作。

如果让小模型直接学习大模型的成功经验，能否得到类似效果？团队收集了 Qwen3.8-27B 的 3,189 条成功轨迹，用于监督微调。使用全部轨迹进行多框架 SFT，平均成功率为 43.1%；只使用其中的 OpenCode 轨迹，则达到 47.5%。两者都低于本次 RL 的结果。不过，这些实验的数据量、计算量和训练目标并不相同，每种设置也只运行了一次，因此还不能把这次观察扩大为两类方法的普遍排名。

这项工作留下了一条可以继续验证和扩展的路径：让模型进入实际使用的工具，在真实交互中学习，并把正确性与执行效率一起纳入训练。代理、训练代码、任务、SFT 数据和七个训练模型都已公开。现有结果还局限于小模型和一类数据分析任务，但开发者已经可以保留自己的运行框架，在这套开放实现上进一步检验，怎样的训练能让模型在自己的工作环境中表现得更好。

openai/math

openai/math^[26] 是 OpenAI 公开 AI 数学研究稿件与证明材料的仓库。目前收录了 722 篇稿件、372 个成果分组，涉及数论、几何、代数、理论计算机科学、偏微分方程等领域。同一分组可能包含主要结论、配套论证、推论和替代证明，因此稿件数量不能直接理解为独立突破的数量。

这些材料来自一个尚未发布的 OpenAI 内部模型。据官方介绍，随着既有数学评测趋于饱和，他们扩大了对开放研究问题的测试，累计向模型提出约 4,000 个问题，再经过归类和重要性筛选，形成这批稿件。平均每项成果所用的计算量，约相当于 ChatGPT Pro 思考 3 小时；这是等效计算量，并非统一的实际耗时，少数成果也采用了不同流程。

仓库的核心价值，是让论文和验证材料能够对应查阅。preprints/ 保存论文、源文件及引用说明；lean/ 提供多项结果的 Lean 形式化证明，配有形式化目录和 Comparator 检查配置；reasoning_traces/ 则公开了 10 项结果的删节推理摘要，帮助读者了解模型得出结果的过程。

这些成果仍处于不同的验证阶段。OpenAI 明确承认，未形式化的结果可能存在问题，后续会继续补充证明并修订。对于已有 Lean 材料的成果，也要核对形式化命题、定义和假设与论文主张是否一致。Comparator^[27] 能检查指定证明是否符合目标命题、是否仅依赖允许的公理，但自然语言论文与形式化命题之间的对应关系，仍需要审阅。

SynthID Detector

Google 已将 SynthID Detector^[28] 面向全球开放，目前提供英文界面。上传图片、视频或音频，就能检查其中是否包含 Google、OpenAI、NVIDIA、Kakao 等合作方的 SynthID 水印，Apple 的支持也将随后加入。

SynthID 会在 AI 内容生成时嵌入人难以察觉的数字水印，再由检测器识别。这些水印直接存在于内容中，对裁剪、压缩、添加滤镜等常见处理有一定抵抗力。

据 Google 公布的数据，自 2023 年推出以来，SynthID 已为超过 1800 亿份图片和视频、累计时长达 24 万年的音频添加水印。Google 搜索、Gemini 和 Chrome 内置的验证功能，目前每天处理超过 100 万次验证请求。此次开放独立网站，让用户多了一个集中检查不同合作方水印的入口。

需要注意，未检测到水印，不代表内容一定由真人制作；检测到水印，也可能只是局部经过 AI 编辑。它提供的是内容来源线索，无法覆盖所有 AI 生成内容，也不能单凭检测结果判断内容真假。

Clef-Flash

Clef-Flash^[29] 是 Cloudflare 推出的 90 亿参数多模态决策模型，基于 Qwen3.5-9B 后训练，兼容 Jev API，适合客服分流、优先级评估等自动化场景。它支持文本、JSON、图片和视频帧输入，能在一次推理中处理多个预设问题，并返回各选项的概率。

例如：处理一条客服消息时，可以同时判断是否紧急、该交给哪个部门，以及问题有多严重。模型权重和推理代码以 Apache 2.0 许可证开放，支持自行部署，也可通过 Cloudflare Workers AI 调用。官方内部评测显示，其请求延迟中位数为 38.8 毫秒。

EmbeddingGemma 2

Google 发布了 EmbeddingGemma 2^[30]，一款主打本地运行的多模态向量模型。它将文本、代码、图片、音频和视频映射到同一个向量空间，让应用可以按语义跨模态检索，例如用文字搜索录音、用语音寻找视频片段。模型基于 Gemma 4，总参数量为 7.4 亿，以 Apache 2.0 许可证开放权重，支持在手机和电脑上离线运行。

它的最大亮点是按需加载。只处理文本时，可以仅加载 2.7 亿参数，视觉和音频编码器则根据需要启用。Google 公布的 Pixel 11 Pro 量化运行数据显示，纯文本权重的活跃内存最低约 191MB，完整多模态模型约 567MB。这组数字对应特定设备和量化配置。

另一个亮点是向量压缩：输出可以从 768 维缩短到 512、256 或 128 维，最低将向量数据量降到原来的六分之一，但需要权衡检索质量。官方模型卡^[31]指出，缩到 256 维仍能较好保留效果，128 维对多模态质量影响明显，更适合纯文本场景。上下文也扩大到 8K Token：默认配置下，单一模态且无额外文本时，约能容纳 5.5 分钟音频、29 张图片或 58 帧视频；混合输入则共用这一额度。

效果方面，官方评测中的多语言文本表现与上一代基本持平，代码检索提升更明显：MTEB Code 得分从 68.76 提升到 78.68，增加了 9.92 分，适合用于本地代码库索引、语义代码搜索和编程 Agent 的检索环节。这组成绩使用全精度模型、768 维向量测得，量化部署时需要单独评估效果。

实际应用可以是离线媒体搜索、本地知识库和多模态 RAG：由 EmbeddingGemma 2 生成向量、辅助检索相关内容，再交给 Gemma 4 等生成模型理解和回答。权重已发布到 Hugging Face^[32] 和 Kaggle，官方提供了手机端、浏览器端及常用推理框架的接入方式，也支持针对具体场景进行微调。

Nano Banana 2.1

Google 推出图像生成与编辑模型 Nano Banana 2.1^[33]，重点提升了视觉设计、蒙版编辑和主体一致性，让生成的图片更自然。官方称，新版各方面表现均优于此前模型，已经陆续上线 Gemini App、AI Mode in Search、Google AI Studio、Flow、Stitch、Google Ads 和 Gemini Enterprise Platform。

Grok Bot

马斯克宣布，今后 SpaceX 会按任务选择最合适的模型或服务，Claude Opus 5.5、MidJourney、Suno 及其他领先 API，都能接进来。哪个效果最佳，就用哪个。

咋感觉 Grok bot 有点后来者居上。Codex、Claude 都在用自家模型，Grok 直接变混合中转站了（像之前的 Poe^[34]，不知还有多少人记得）。

Altman 感慨

Altman 发了一段让人摸不着头脑的文字，我让 Codex 用比较诗意的方式翻译了下： 

今宵仰首望星天，

心中敬畏更胜前。

君之沧海何辽阔，

吾舟渺小在其间。

28 天改进计划

Codex 负责人 Tibo 开启了一个 28 天产品改进计划，如果每天没有实质改进，就送重置。现在已经持续了两天，投票结果几乎一边倒，要求 Tibo 重置额度。

iPhone Duo 强制适配

也就 Apple 敢这么作，执行强制要求：从 2027 年 4 月起，提交的所有应用和游戏都必须包含 iPhone Duo 的屏幕截图。参考文档 Prepare and submit your apps for iPhone Duo^[35]

Sindre Sorhus^[36]（顶级开源大佬，为 Apple 生态贡献了 60+ 款应用）吐槽 iPhone Duo 没有必要，认为它是在“为了改变而改变”，却给开发者增加了大量无谓的适配工作。他对触屏 MacBook 也持同样看法，质疑这些变化是否带来了值得付出额外开发成本的实际价值。

VS Code Pet

VS Code 也开始搞宠物了（chat-pet^[37]），在 VS Code 中打开 GitHub Copilot Chat，输入：/vscode-pet

个人观点

Pi 1.0 影响

Pi 1.0 发布后（Pi 1.0：为何接纳 MCP，又推出 Pi Durable？），社区里有认可新能力的，也有吐槽它偏离极简路线、开始变重的。早期 Pi 吸引开发者的，正是精简的核心、容易理解和修改的实现，以及灵活的扩展机制。OpenClaw 早期采用 Pi，给它带来了更多关注；但热度之外，Pi 本身的设计也值得肯定。

随着模型能力提升，人们开始尝试把更长、更复杂的任务交给 Agent。工具怎么配合、上下文怎么管理、状态怎么保存、中断后怎么继续，这些问题也就越来越重要。社区早已在探索相应的方案：例如，pi-mcp-adapter 提供 MCP 接入和按需工具发现，pi-subagents 支持子 Agent 委派和异步执行。即使官方不内置，开发者也会通过扩展满足自己的需求。

我个人并不反对 Pi 将一些通用能力纳入核心。极简不能只看内置功能有多少，还要看使用者需要花多少精力去理解、配置和维护。如果许多人都在重复搭建同一套东西，官方统一维护就有价值。当然，内置也会增加项目自身的负担，需要有所取舍：哪些能力已经足够通用，值得共同维护；哪些仍有很多不同做法，适合继续留给扩展。

Pi 对 MCP 和 Codemode 的整合，我认为就有这样的理由。工具如何被发现、何时加载给模型、怎样通过代码组合调用，牵涉到整个工具系统。统一设计这些能力，既能改善 MCP 的接入，也能支持其他工具和模型的组合使用。这是具体的工程考虑，值得讨论它做得好不好，而不必仅凭功能增加，就认定 Pi 放弃了克制。

Pi Durable 的定位则有所不同。它是与 Pi 1.0 同期发布的独立实验性框架，为长期运行、状态持久化、故障恢复和多客户端接入提供支持。日常在终端里写代码，Pi 仍然是原来的选择；如果要开发具备这些能力的 Agent 应用，可以考虑 Durable，并在其上完成具体的应用集成。把这部分工作放进独立框架，也给了团队探索新场景的空间，不必让日常使用 Pi 的人承担所有变化。

获取流量

群里有人吐槽说 X 起号难，发帖没人看。我想分享点个人心得，供大家参考。首先要把 X 当成一个聊天、交友、学习的平台，让自己融入进去，有活人感、参与感。

普通人初期想要获得曝光就两种合法途径：引用 & 评论。引用别人的帖子发表高质量观点，很可能被原作者或大 V 翻牌；高质量评论，也会获得大量围观讨论。

心态要放平，别发了两天帖，没人看就想放弃。把这里当成记录日常、整理思考、分享学习的地方。首先是写给自己，其次才是分享给别人。不必让每条帖子都背着涨粉任务，少一点功利心，表达会轻松很多，也更容易坚持。

至于各种“邪修”起号法，我个人不太推荐。靠什么内容吸引来的关注，往往就要靠什么内容维持。人设一旦形成，后面想转变并不容易。低质量内容带来的热闹，也未必能换来你真正想要的交流。

如果还是一头雾水，也可以让 AI 帮你分析一下 X 算法^[38]，给些参考建议。未必能直接带来流量，但可以帮助你理解规则，少一点盲目摸索。

注：这里以 X 平台举例，其他平台也类似。

忙碌的空虚感

最近高频发帖，内心却有点空。AI 能力增强，可以做的事更多了，但借助它创造的价值并没有随之增长。谈不上焦虑，只是有些感慨。

如果把周 Token 额度换算成代码，差不多能产出百万行代码项目，可现实并没有那么多事可做。回头看，大半 Token 都消耗在了各种尝试、折腾中，仅换来一些情绪上的满足...

Intelligent UI

OpenAI 在 GPT‑6 and Intelligent UI for everyone^[39] 中宣布，GPT‑6 将向更多 ChatGPT 用户开放，并引入 Intelligent UI，让回答可以根据用户的任务生成可直接操作的交互界面。

Intelligent UI 能组合文字、图片、图表、按钮和表单，用交互演示帮助用户理解复杂概念，也能在对话中生成分账器、储蓄计算器或小游戏。借助原生组件库和流式编译器，界面可以边生成边显示。模型会根据问题判断何时需要交互，何时用纯文字回答就足够。

GPT‑6 还支持思考与回答交错进行，减少用户等待。官方称，在需要联网搜索的问题上，GPT‑6 Instant 开始回答的等待时间平均比 GPT‑5.6 Instant 缩短 44%。此外，搜索信息的使用、对多轮越狱的抵抗，以及对自身能力限制的说明也有所改善。

此次更新分批推送：Plus、Pro、Business 和 Enterprise 从 10 月 7 日开始开放，使用 GPT‑6 Sol；Free 和 Go 从 10 月 8 日开始开放，使用 GPT‑6 Luna。企业版的可用性取决于管理员设置。这次更新针对 ChatGPT 的 Chat 体验，Work 和 Codex 使用的模型不变。

References