今天最值得动手的一条线，是 Agent 从电脑端 CLI 向手机、浏览器和单文件文档扩张：OpenMinis、ego lite、Cindy、Bento 把“能执行”分别落到设备、登录态浏览器和可编辑交付物上；同时推理侧继续围绕本地 Apple Silicon、扩散式生成与 serving 优化压缩成本。 本次 X List 抓到 124 条；Agent Reach 多源证据包在 300 秒限时内未产出，本期🛠️仅纳入已用官方 GitHub、官网、模型卡或文档交叉核验的条目，🌱保留的弱线索标明“证据待补”。
一个面向 iOS/Android 的开源 Agent 应用，把模型、设备上的 Linux shell、浏览器自动化、可扩展 Skills、持久记忆和系统集成放进移动端。
想最快体验，先打开项目 Releases，Android 用户下载最新 APK；想看实现则克隆仓库，README 里按 src/ios、src/android 和 shared 目录分别理解两端结构。首次启动后先配置自己的模型账号或 API，再只授予当前任务需要的权限。可以先让它在工作区里运行一个简单脚本、读取一个本地文件，再测试浏览器操作；涉及健康、日历、通讯录或 HomeKit 时，逐项确认权限和数据边界，不要一上来打开全部系统能力。
它不是把手机当成远程聊天窗口，而是把移动设备本身当作 Agent 的执行环境。官方 README 明确列出设备内 Alpine Linux 沙箱、浏览器自动化、Skills、持久记忆以及 HealthKit、日历、提醒事项、HomeKit 等集成；这种“本地执行 + 原生权限”的组合，正好补上桌面 Agent 到真实生活设备之间的断层。
基于 WezTerm 深度定制的 macOS 终端，提供开箱即用的 AI 编程默认配置、命令生成、错误恢复和多种 CLI 工具配置入口。
macOS 用户可以从 GitHub Releases 下载 DMG 拖进 Applications，也可以执行 `brew install tw93/tap/kakuku`。启动后先运行 `kaku doctor` 检查安装、PATH 和 shell 集成；再运行 `kaku ai` 选择提供商并配置模型。日常使用时在提示符输入 `# 你的自然语言需求`，检查它生成的命令后再执行；命令报错时可用 Cmd+Shift+E 让 Kaku 给出修复建议。把 Claude Code、Codex 或其他 CLI 放进同一个终端后，再比较它和现有终端的操作流是否真的更快。
Kaku 的价值不只是换皮终端，而是把 AI 助手、终端复原、lazygit、远程文件和 Lua 定制放到同一套工作环境里。它基于 WezTerm，仍保留可编程性，却用更明确的 AI 编程默认值降低初始配置成本；而且项目强调开源、无账号，AI 请求只发往用户配置的服务。
开源的桌面与移动端 AI Agent 客户端，支持在 Claude Code、Codex 等 Harness、不同模型和本地工具之间切换，同时保持工作区、记忆、Skills 和工具连续。
不想先编译的话，直接从 cindy.app 下载对应平台版本，首次登录页选择托管服务、已有 Coding Plan、自有 API Key 或 Local mode。建议先用一个无敏感内容的项目测试：授权工作区后，让它完成一个小改动，观察计划、执行和审查分别由哪个 Harness 完成，再尝试中途切换模型。想研究源码则执行 `git clone https://github.com/makecindy/cindy.git`，随后运行 `git submodule update --init --recursive cindy-protocol`、`git lfs pull` 和 `pnpm install`，再按仓库开发文档启动对应应用。
多数 Agent 客户端把模型、Harness 和工作区绑死，Cindy 把它们拆成可以自由组合的层。官方说明既支持现有 Claude Code/Codex 计划，也支持 API Key 和本地模型；客户端本身 Apache-2.0 开源，因而更适合拿来观察“多 Harness 协同”会不会成为下一代 Agent 产品的基础交互。
基于 Chromium 的 Agent 友好浏览器，用隔离 Space 让 Claude Code、Codex、Cursor 等外部 Agent 复用浏览器登录态，同时不抢用户自己的标签页。
先从官网或 GitHub 安装 macOS 应用，首次启动时按需导入 Chrome 的登录数据、书签和扩展。然后在终端执行 `npx skills add citrolabs/ego-lite` 安装 ego-browser Skill；在支持 Skill 的 Agent 中输入 `/ego-browser`，例如让它打开一个页面、读取 Snapshot、填写表单或完成多步导航。先用不涉及付款和隐私的网页测试，确认 Agent 工作在自己的 Space，再逐步放开登录态访问；需要人工接管时，回到浏览器检查每一步，而不是盲目让 Agent 连续提交。
传统 browser-use 或 Puppeteer 往往需要另一个空白浏览器，登录态、验证码和用户标签页都很麻烦。ego lite 把“人用的浏览器”和“Agent 用的隔离空间”放在同一 Chromium 里，并用语义 Snapshot 和批量页面动作减少往返；它不是绑定某一家模型的 AI 浏览器，而是给任意能运行 Skill 的 Agent 提供连接层。
开源的单文件办公套件，Bento Slides 把编辑器、播放器、演示视图和可读 JSON 文档放在同一个 HTML 文件里。
打开 bento.page/slides 直接进入编辑器，或者从 Releases 下载 `Bento_Slides.bento.html`，用现代浏览器打开即可，不需要账号和安装器。先导入或新建几页内容，直接在编辑器里拖拽、编辑、播放并保存；如果要让 AI 改稿，把这个 HTML 文件和修改要求一起交给编码 Agent，让它只改文件顶部的 JSON 文档块，改完重新打开检查布局、动画和图表。分享时直接发送文件，收件人用浏览器打开即可；重要版本建议保留 Git 或文件副本。
Bento 把“文件格式”变成了产品 API：文档数据是明文 JSON，运行时、编辑器和播放器又都随文件携带，避免 PPTX 转换、云端账号和版本兼容问题。官方还为 Agent 提供了文档编辑方式，意味着 AI 不必操纵一个脆弱的桌面 GUI，就能直接读写结构化内容并保留可视化结果。
面向 M 系列 Mac 的本地推理引擎，提供 OpenAI/Anthropic 兼容接口、工具调用、提示词缓存和面向 Agent 工作流的性能优化。
在 Apple Silicon Mac 上先执行 `python3 -m pip install -U rapid-mlx`，或按项目说明使用 Homebrew；然后阅读 README 的启动方式，把它作为本地 OpenAI 兼容端点接到你的编码 Agent 或 API 客户端。先选一个 7B/小型模型验证聊天和工具调用，再打开重复系统提示的任务观察缓存收益，最后才把它接到会改文件或执行命令的长流程。每次升级后重新跑一次工具调用、结构化输出和上下文缓存测试，并记录本机模型、量化方式和并发数，避免把单次宣传 benchmark 当成自己的稳定吞吐。
本地模型真正进入 Agent 工作流，瓶颈不只在首 token 速度，还在工具调用协议、缓存复用、上下文成本和 API 兼容性。推文给出 0.11.0 在重复 6K 前缀上的缓存收益；项目资料则明确覆盖 Apple Silicon、MLX、OpenAI 兼容和工具调用。它因此更像一个可接入现有工作流的本地推理层，而不是只能展示模型输出的 Demo。
腾讯的全场景 AI 工作台，面向调研、数据分析、文档、邮件和演示等办公任务，能拆解步骤、调用多个专家 Agent 并交付文件。
打开 WorkBuddy 后先用一个边界清晰的问题测试，例如“比较三家未上市公司的公开信息并列出证据”，同时上传允许使用的资料。要求它先给出检索路径和来源，再执行深度调研；完成后逐条检查引用、时间和冲突信息，最后让它输出 Markdown、Word 或 PPT。对于财经、招聘、竞品和舆情类任务，明确要求区分事实、推断和待核实内容，不能因为系统能生成漂亮报告就跳过人工交叉验证。确认流程稳定后，再把固定任务保存成可重复的工作流。
这条线的亮点不是“聊天式写报告”，而是把检索、交叉核验、协作角色和交付格式组合成一条流程。官网明确展示了深度研究、竞品矩阵、策略建议以及 Markdown、Word、PPT 产出；对个人用户来说，它适合验证 Agent 是否能从资料搜集走到可复核交付，而不是只看一段摘要。
开源的新标签页扩展，把书签和浏览器命令映射到可视化键盘，并提供拖拽布局、深度主题定制、专注模式和同步能力。
先打开项目主页或 GitHub README，按说明把扩展加载到 Chrome/兼容浏览器的新标签页；第一次使用时只配置十几个最常用书签，给每个键分配稳定的肌肉记忆位置。再设置一个修饰键组合，把切换标签、关闭页面、滚动等命令绑定到字母键，并为高风险页面设置域名白名单。最后试用专注模式、主题和本地备份；如果开启云同步，先阅读权限说明，不要把工作资料或浏览记录直接当作无风险数据上传。
NaiveTab 把浏览器效率从“收藏夹列表”改成了空间化、可记忆的操作面板，命令键和书签键还可以共存。官方 README 给出了键盘映射、拖拽布局、页面命令、域名黑白名单和多语言等具体能力；它不依赖 AI，却很适合作为 Agent 时代的人机协作底层习惯工具。
高性能 LLM/VLM serving 框架的新版本，加入 DSpark 置信度驱动推测解码，并扩展大模型、扩散模型和缓存支持。
有 NVIDIA/AMD GPU 集群的读者先按官方安装文档部署 v0.5.16，并用现有模型跑一组基线，记录输入吞吐、单用户解码、接受长度和显存。然后按 release note 开启 `--speculative-algorithm DSPARK`，同时设置 `SGLANG_RAGGED_VERIFY_MODE=compact`，再用 `--speculative-dspark-block-size` 调整草稿块大小。不要只看单个 tok/s 数字：分别测试短请求、长上下文、不同 batch 和低接受率场景，并检查服务的正确性、尾延迟和回退行为，确认新算法适合你的模型后再进入生产流量。
推测解码的关键不在于“多一个草稿模型”，而在于草稿长度、验证窗口和硬件执行是否匹配。官方 v0.5.16 release note 给出 DSpark 的置信度调度方式和 DeepSeek-V4-Pro 上的测试结果，同时还覆盖 Inkling、LongCat、Mamba/DSA 缓存等 serving 变化；这说明推理优化正在从单一 kernel 竞赛转向模型结构、缓存和服务调度的联合工程。
NVIDIA、Microsoft、Cloudflare 等公司和行业人士围绕“Open Weights and American AI Leadership”公开表达支持，开放权重成为一项同时涉及技术、产业和政策的议题。
这里需要区分开放权重、开放源码和完整开放模型：开放权重允许研究者和企业下载、部署、评测或微调参数，但训练数据、训练代码、基础设施和商业服务仍可能保持闭源。X List 中的讨论也暴露了这场争论的边界——支持开放权重不等于把 CUDA、驱动或全部产品栈开源。真正值得观察的是，签署和公开表态正在把模型可下载性从社区偏好推向企业采购、国家竞争力和监管叙事；未来的竞争可能同时存在于权重开放程度、部署成本、许可条款和闭源服务质量。
对开发者而言，可下载权重会扩大本地部署、行业微调和独立评测的选择；对云厂商和模型公司而言，开放权重会压低通用推理的差异化，迫使它们把优势转到数据、工具链、服务可靠性和生态。采购模型时也不能只看“开源”标签，必须检查许可证、训练数据声明、商用限制、更新机制和安全责任边界。
围绕 Agent Skills 的讨论升温，Anthropic 的工程文章把上下文工程、渐进式加载、工具设计、压缩、持久笔记和多 Agent 协作列为长流程 Agent 的核心方法。
Agent 变强之后，问题不再只是写一句更好的 prompt，而是每一步到底把哪些高信号信息放进上下文。Skills 的元信息可以在会话开始时作为路由线索，真正需要时再加载完整指令、脚本和参考资料；工具则负责让 Agent 按需读取文件、查询数据和恢复状态。这样的设计把提示词、MCP、工具返回值、项目规则、历史消息和外部文件统一成“上下文系统”，也解释了为什么同一个模型换一套 Skills、检索策略和进度记录后，稳定性会明显不同。
AI 应用团队需要把 Skill/工具/记忆当作可测试的软件组件，而不是一次性提示词。未来评测应包含上下文污染、长任务恢复、工具失败、权限边界和跨会话一致性；个人用户也可以把重复工作整理成短元数据加按需参考文件，减少每轮重复粘贴。谁能把上下文管理做成可观察、可回滚、可复用的工程层，谁就更可能在模型能力趋同后保住产品差异。
inclusionAI 发布 LLaDA2.2-flash，模型卡将它定义为面向 Agent 的扩散语言模型，并引入 Levenshtein Editing 的 DELETE/INSERT 控制 token，覆盖长上下文工具使用、多轮交互和错误修正。
自回归模型通常从左到右追加 token，生成早期发生错误后往往要依赖重新生成；扩散式语言模型则可以并行生成，并在序列中间做编辑。LLaDA2.2-flash 的模型卡进一步给出 MoE、128K 上下文和 100B 总参数等信息，说明路线重点不是把“扩散”当成视觉模型的专属技术，而是尝试让 Agent 在工具调用失败、计划变化或输出冗余时局部修改。真正的工程考验仍在推理速度、编辑稳定性、工具协议兼容、长任务评测和硬件成本，不能只凭一条宣传视频判断它会替代自回归模型。
如果可编辑生成在真实工具链中稳定，Agent 可能少做一些从头重写，长上下文任务的错误恢复成本也有机会下降；同时 serving 框架、缓存、评测和训练目标都要适配新的生成范式。对应用开发者来说，近期更适合关注模型卡、推理代码和公开 benchmark 是否持续更新，把它当作值得试验的路线，而不是立刻迁移生产系统。
