今天的主线是“把模型能力变成可运行的控制面”：一边是 Claude Haiku 5.5 这类更便宜、更适合高频调用的小模型，另一边是能直接安装的动画 skill、Grok API 示例、端侧多模态 embedding、个人 Agent Bot 和结构化判断模型。AI 产品的竞争正在从单次回答，转向成本、路由、记忆、权限、验证和本地数据闭环。本次 X List 抓到 36 条推文，证据补充包筛出 29 个候选；HNRSS 的 6 个 feed 本次均返回 502，因此早期信号主要来自 X List，已明确标注证据待补。
一个开源艺术动画 skill，把 35 种艺术风格、9 种解说语法和参数化片段组织成可复用的代码创作流程，适合让 coding agent 制作风格化短片、科普动画和口播视觉。
先打开 GitHub 仓库阅读 README 和 SKILL.md，在终端执行 `npx skills add alchaincyf/huashu-art-motion`，再按项目说明准备 uv、ffmpeg 和 Playwright Chromium。第一次不要直接挑战完整长片，先选一个仓库里的短示例，替换主题、角色、旁白和镜头节奏，运行脚本生成帧或动画；随后用 `qa.py` 做稳定性、效率、动感、流畅度和文字框景检查。白板、Vox、动态文字等语法要先读对应参考卡；讲解员语法需要自备角色素材，口播整片示例是代码快照，不是下载后即可渲染的成片。
它的亮点不是简单套滤镜，而是把风格、镜头运动、角色动作、转场和口播结构沉淀成 agent 能读取的工程资产。README 同时给出样片、风格配方和许可证边界，适合研究如何把一次性提示词变成可复用 skill；不过完整渲染仍有素材、依赖和时间成本，应先跑通短片再投入生产。
xAI 官方开源的实践仓库，提供从基础调用到实时语音智能体、多模态生成和 X 实时数据分析的产品化示例。
先安装 uv，克隆仓库后执行 `uv sync`，按 `.env.example` 建立本地环境文件并填入自己的 xAI API key，再运行 `uv run jupyter notebook examples/` 浏览示例。先挑一个最小 notebook 跑通文本请求，再尝试 voice-examples 或 agent 目录中的实时语音、多模态和数据分析流程；每次只改一个变量，记录延迟、上下文、工具调用和费用。仓库也使用 Git LFS，若需要完整资源要先执行 `git lfs install`。API key 只放在本地环境变量，不要提交到 Git；示例能运行不代表所有地区、模型或额度都默认可用。
它不是营销页上的能力清单，而是把一个 API 能落地成什么样的真实应用拆成 notebook、移动端和 Agent 示例。对开发者来说，最有价值的是可以从单次调用逐步过渡到语音、多模态和实时数据工作流，并观察依赖、密钥、错误处理和测试如何组织；同时也能较早发现官方推荐的接口形状变化。
Google DeepMind 发布的开放多模态 embedding 模型，把文本、代码、图片、视频和音频映射到统一向量空间，面向隐私优先和本地设备上的搜索、RAG 与相似度任务。
https://blog.google/innovation-and-ai/technology/developers-tools/embeddinggemma-2 ↗
https://developers.googleblog.com/embeddinggemma-2-the-developer-guide ↗
先读 Google 官方开发者指南，按任务选择只处理文本和代码的 270M 配置，或加载完整多模态能力的 740M 配置；用 sentence-transformers 6.1.0 或更新版本建立一个小型本地实验，把自己的文档、截图、短音频和视频帧分别编码，写入本地向量库，再用文字查询跨模态召回。第一轮固定 768 维并记录召回质量、内存和延迟，第二轮尝试 Matryoshka Representation Learning 截断到 512、256 或 128 维，比较存储和准确率。再用量化和 8K 上下文做设备测试，先验证离线可用性，不要把官方 benchmark 直接当作自己的业务效果。
它把“本地 RAG”从纯文本搜索推进到跨文字、画面、声音和视频的统一检索，同时仍保持 sub-1B 规模。官方资料给出的模块化加载、向量维度裁剪和低内存路径，意味着移动端或个人电脑也能尝试隐私优先的语义搜索；真正的门槛会转向数据切片、查询提示、向量库设计和端侧延迟，而不只是模型参数量。
Paseo 的开源插件，为每个 Bot 提供独立指令、模型、记忆、例行任务、技能、MCP 工具和连接应用，还能组成由 Chief of Staff 协调的 Bot Team。
先确认 Paseo 版本不低于 0.9.2，再按插件页执行 `$ paseo plugin add oliexe/bots`，或在设置页安装 `npm:@oliexe/paseo-bots`。创建第一个 Bot 时只开一个明确职责，例如资料整理或邮件初筛，配置 provider、model、approval mode 和工作目录；随后手动跑一次任务，查看它的 MEMORY.md 与每日日志，再建立一个低风险 routine。需要接入应用时，先只授权只读工具和单一账号，审查 skills、MCP 与连接应用清单，再逐项开启；涉及发送、删除、付款或外部写入的动作保留审批。不要把“能定时运行”当作安全证明，凭据、relay 和 host 权限仍需自己检查。
它把本地 Agent 从一次性聊天窗口推进成可持续的工作单元：有状态、有记忆、有例行运行，也能把多个角色组合成团队。源码和官方插件页同时说明了权限、连接应用和提议变更需审批等边界，这比只展示一个 Bot 对话界面更接近实际自动化；但它继承底层 Agent 的权限风险，适合从单一只读流程开始。
一款以中国历史人物为主题的 AI 对话猜谜产品，玩家通过连续提问建立线索，最后猜出被隐去姓名的人物。
https://pastecho.neosura.com ↗
https://apps.apple.com/us/app/%E6%97%B6%E7%A9%BA%E5%9B%9E%E9%9F%B3/id6802930227?l=zh-Hans-CN ↗
可以先直接打开官网体验，也可以在 App Store 搜索并安装“时空回音”。进入后从档案馆选择一位人物，先问时代、身份、作品和关键经历等宽问题，再根据回答逐步缩小范围，最后提交猜测；不要一开始就问“你是不是某某”，那样会失去推理过程。体验时把 AI 的回答与人物原典、可靠史料分开记录，看看哪些是有来源的事实、哪些只是产品为了游戏性做的重构。产品公开介绍称包含 100 多位中国历史人物，并强调 AI 解读属性，适合当作互动学习和产品设计样本，而不是历史研究的唯一来源。
它把“和历史人物对话”从单纯角色扮演改成了有目标、有线索、有反馈的推理机制，产品闭环比一个普通聊天机器人更清楚。更重要的是，项目公开讨论了 AI 重构、资料边界和披露责任，提示这类人格化历史产品必须让用户知道“这是解释和模拟，不是本人原声”；这对教育、博物馆和知识产品设计都有参考价值。
TypeSafe 的 Jev 不是用来写长文本的聊天模型，而是接收文本或 JSON 状态，并返回 choice、score、yes/no 及概率等结构化判断，适合放进 Agent 的路由、筛选和审批环节。
先在 TypeSafe 官方文档了解 System One 的请求结构并申请 API key，再按官方 Python 或 TypeScript SDK 示例建立一个最小判断任务，例如把客服请求分到 billing、technical、other，或判断某个工具调用是否需要人工审批。给每个问题写清楚 instructions、criteria 和允许的选项，发送同一批状态，记录 choice、confidence、probabilities、延迟和成本；确认输出稳定后，再把它接到 Agent router、reranker 或 tool-approval middleware。不要让 Jev 直接执行副作用动作，先把它的概率阈值、低置信度分支和人工升级规则写进业务代码，并用真实边界样本做回归测试。
它代表一种和大语言模型不同的控制面思路：模型不负责生成漂亮解释，而是把高频、边界清晰的判断直接返回成程序可消费的类型。这样可以减少自由文本解析和长链路 token 消耗，让“选哪个子 Agent、是否安全、是否升级人工”等决定更容易观测和测试；但它不替代开放式推理，也不能跳过问题定义、校准和错误兜底。
Anthropic 发布 Claude Haiku 5.5，官方将其定位为高吞吐、成本敏感任务的小模型，并称 10 万 token 以内请求的价格比 Haiku 4.5 低 90%，超过 10 万 token 的价格低 50%，现已可在 Claude Platform 及云平台使用。
这不是简单的“新模型更便宜”，而是 Agent 经济模型出现了更清晰的分层：摘要、分类、压缩、实时客服和浏览器子任务可以交给更快的小模型，复杂规划、代码审查和高风险决策再交给更强模型。官方还强调 Haiku 5.5 的 tokenizer、上下文和任务完成方式发生变化，所以不能只拿每百万 token 标价做横向比较；真正应测量的是一次成功任务消耗多少 token、失败重试几次，以及小模型下沉后是否增加人工返工。
对个人开发者，最直接的变化是可以重新设计“强模型做大脑、小模型做流水线工人”的路由。对产品团队，模型选择会进入缓存、并发、延迟、重试和毛利核算，而不是只由算法同事决定。长期看，便宜模型会扩大实时 Agent 和批量自动化的可行范围，但也会让评测、监控和升级策略更重要。
X List 连续推文称 Grok Bot 已能搜索、阅读和监控 X 内容，xAI 官方产品页也把 live X integration 列为能力；当前实际开放范围、账号要求和额度仍应以产品内状态为准。
如果一个 Agent 能持续读取公开帖子、搜索关键词并监控提及，X 就不再只是聊天入口，而会变成可被任务化消费的实时数据流。对研究、舆情、品牌监控和个人信息整理而言，这比手工刷时间线更接近“订阅一个会自己找信息的助手”；但“无需 API”或“无需 X 账户”的社交转述不能直接当作稳定承诺，权限、地区、订阅层级和数据使用政策都会影响实际结果。尤其要区分公开内容读取、代表用户操作和把数据送入模型训练这三件不同的事。
产品侧会出现更多实时监控、摘要和告警工作流，数据平台竞争也可能从 API 接口延伸到原生 Agent 权限。用户需要关注公开帖子、交互输入和模型结果如何被共享与保留；开发者则应为关键词误报、来源追溯、速率限制和账号封禁准备降级路径。这个方向的价值很高，但不能把一次产品演示等同于可依赖的数据基础设施。
X List 分享了一个数据分析 Agent 案例：主模型负责理解问题、编写只读 SQL 并执行查询，独立的审查层负责检查 SQL、权限和结果，再把解释交给用户。
这条信号值得关注的地方不在于又做了一个 Text-to-SQL Demo，而在于它明确拒绝让同一个 LLM 同时当运动员和裁判员。生成模型擅长提出方案，但它也可能为自己的错误找理由；独立审查层则可以使用不同模型、规则、数据库 schema 和权限策略，专门回答“能不能执行、结果是否可信、是否需要升级”。这种拆分把 Agent 从一条黑盒对话链变成多个可单测节点，代价是延迟、调用费用和状态同步都会增加。
企业落地 Agent 时，验收标准会从“回答看起来像对的”转向“生成、审查、执行、解释各有证据”。安全团队可以把工具审批、SQL 只读限制和敏感字段检查放在控制层，业务团队也更容易定位是生成错、审查漏还是数据源错。未来多模型系统未必追求一个模型包办一切，而会更重视角色隔离、互相校验和失败后的人机接管。
