面条的草稿箱

  1. 不止是酷炫动效:设计工程中那些“看不见”的细节在社交媒体上,提到“设计工程师”(Design Engineer),大家往往会联想到那些惊艳丝滑的动效和充满创意的视觉组件

    不止是酷炫动效:设计工程中那些“看不见”的细节

    在社交媒体上,提到“设计工程师”(Design Engineer),大家往往会联想到那些惊艳丝滑的动效和充满创意的视觉组件。视觉效果直观、容易传播,但这也让不少人对这个岗位的认知产生了偏差。

    一个优秀界面的背后,真正决定体验上限的,往往是那些看不见的工作

    性能与响应度:将操作反馈从几百毫秒甚至几秒压缩到极致,让界面感知不到延迟。
    无障碍与包容性:支持减弱动态效果(Reduced motion)、优化键盘焦点指示、合理扩大点击热区(Hit areas),确保所有人都能舒适使用。
    极端场景与细节打磨:列表项悬停时的微小间隙防误触、可变字体的渲染平滑度、OKLCH 色彩空间的适配,以及多语言环境下的排版与格式自适应。

    在早期初创公司,你可能要打通从设计到落地的整条链路;在成熟团队,你可能深耕在更细分的体验模块。但核心逻辑从未改变:产品是做给人用的,解决的是真实世界的问题。

    做出一套惊艳的动效固然很酷,但花上一下午去死磕一个极少数人才能感知到的可访问性 Bug,或是为了提升一点点首屏加载速度而反复优化,同样是设计工程不可或缺的基石。

    真正顶级的用户体验,往往就藏在这些看不见的地方。

    原文阅读:https://jakub.kr/writing/the-invisible-side-of-design-engineering

    #设计工程 #用户体验 #前端开发 #交互设计 The invisible side of design engineering

  2. AI 时代给年轻开发者的六条建议:写代码已经不够了有人问资深工程师 Matthias Endler,今天会给年轻开发者什么建议

    AI 时代给年轻开发者的六条建议:写代码已经不够了

    有人问资深工程师 Matthias Endler,今天会给年轻开发者什么建议。他的回答出人意料——几乎与代码无关。

    学会做产品。 即使 LLM 能写大部分代码,市场仍然需要能理解用户需求、设计方案、根据反馈迭代的人。这项能力不随技术更替而贬值。

    学会学习。 当信息唾手可得,真正稀缺的是批判性思维和基于数据做决策的能力。理解底层原理,远胜于死记硬背和简单的模式匹配。

    学会沟通。 能把想法讲清楚、能激发他人协作的人,影响力是成倍放大的。别做独狼。

    成为问题解决者。 当所有人都用同样的工具时,拉开差距的是你解决问题的速度和质量。选一个问题,深入领域,建立快速反馈循环,不断迭代。

    拥有不止一项技能。 只会写代码的人很容易被替代。把编程能力和你真正感兴趣的领域结合起来——比如健身、金融、教育——这会大幅缩小你的竞争圈。好奇心驱动的探索比纯靠意志力更持久。

    本质上什么都没变。 上一代人或许仅凭编码能力就能找到工作,但最优秀的开发者从来都不只是写代码。工具变强了,意味着"写代码"本身不再是护城河,你必须锻炼其他肌肉。

    🔗 https://endler.dev/2026/advice-to-young-developers/

    #开发者成长 #AI时代 #职业建议 #软技能 #产品思维 Advice to Young Developers

  3. 算力战国策:拆解主流 AI 芯片的技术哲学与架构之争在摩尔定律与登纳德缩放定律放缓后,AI 算力迎来爆发

    算力战国策:拆解主流 AI 芯片的技术哲学与架构之争

    在摩尔定律与登纳德缩放定律放缓后,AI 算力迎来爆发。大模型计算本质上是海量的矩阵乘法(GEMM / GEMV),而决定性能天花板的从来不是单纯的峰值算力,而是数据移动速度——即如何攻破“内存墙”(Memory Wall)

    各大芯片巨头对此给出了截然不同的答卷,形成了当下六大主流 AI 芯片路线:

    ---

    1. NVIDIA GPU:极致通用与生态壁垒

    核心哲学:高度并行的通用处理器。通过 CUDA 保留统一的编程模型,将硬件复杂度包装在 SM 与 Tensor Core 背后。
    架构亮点:通过硬件管理缓存与海量线程(Warp)隐藏访存延迟;从 Blackwell 到 Rubin,引入 TMEM、异步 TMA 与微缩精度(FP4/NVFP4)。
    扩展体系:NVLink + NVSwitch 构建低延迟共享内存域;机架级(如 NVL72 / NVL576)坚持采用无源铜缆背板,以极低功耗实现高达 130 TB/s 的全对全互联。
    护城河:二十年积累的 CUDA 开发者生态与深度优化的算子库(FlashAttention、CUTLASS 等)。

    2. Google TPU:脉动阵列与编译器至上

    核心哲学:专为矩阵乘法而生的专用机器。剔除硬件调度器、分支预测和缓存,把每一拍的调度完全交给 XLA 编译器。
    架构亮点:权重常驻(Weight-Stationary)的 MXU 脉动阵列,搭配纯软件管理的暂存内存(VMEM/CMEM);引入 SparseCore 处理非规则的 Embedding 与推荐负载。
    扩展体系:以 3D-Torus(环面拓扑)为核心,配合独创的 Palomar OCS(3D-MEMS 光电路交换机),实现无需停机的动态拓扑重构与近万卡级(Ironwood / TPU v8)超大规模 Scale-up Pod。

    3. AMD Instinct:先进封装与开源联盟

    核心哲学:CU 核心架构保持稳健,把算力红利押注在 3D 堆叠封装(TSMC SoIC)与更大容量的 HBM 上。
    架构亮点:首创 3D 堆叠 GPU 与 CPU+GPU 统一内存架构(MI300A);配备 256MB 超大 Infinity Cache 缓解访存压力。
    扩展体系:推进开放互联标准 UALink 与以太网 RDMA 标准(UEC/UET),在 Helios 机架上正面迎击 NVL72。
    软件生态:以 ROCm、HIP、Triton 和 vLLM 为抓手,依托开源社区追赶 CUDA 性能。

    4. Cerebras WSE:不切晶圆的极速怪兽

    核心哲学:内存墙源于把晶圆切成小芯片。Cerebras 直接把整块 300mm 晶圆做成单颗芯片(46,225 mm²)。
    架构亮点:片上拥有 90 万个数据流核心和 44GB 超高速 SRAM,内部聚合带宽高达 21 PB/s,无 HBM 瓶颈。
    应用场景:极限追求单 Token 的生成延迟(Decode 速度远超 GPU 数倍),但受限于 SRAM 成本与容量,更适合作为极致低延迟的专用推理节点。

    5. AWS Trainium:云端全栈性价比

    核心哲学:芯片是云服务的组件,只需在 AWS 内部体系内战胜采购 NVIDIA 的成本。
    架构亮点:借鉴 TPU 的脉动阵列与 OpenXLA 体系,同时在硬件层面原生集成 CC-Core(集合通信核心),让通信与计算在硅片上真正完全并发。
    扩展体系:自研 NeuronSwitch 扁平互联 + Nitro EFA/SRD 弹性以太网,支撑了 Anthropic 百万卡级别的超大规模集群。

    6. Groq LPU:消除一切不确定性的纯静态架构

    核心哲学:移除所有硬件仲裁器、缓存与动态调度,打造完全确定性(Deterministic)的处理器,执行时间在编译期精确到周期。
    架构亮点:片上全 SRAM 空间流式处理,数据如流水线般穿过功能切片;多卡之间无需交换机,纯静态编译路由。
    最终归宿:单卡容量极小、扩展成本高,其低延迟推理技术最终被英伟达吸收,作为超低延迟推理协处理器协同工作。

    ---

    💡 核心趋势与行业共识

    1. 单芯片算力趋同,系统工程定胜负:各家旗舰的单芯片 FP8/FP4 峰值已十分接近,竞争焦点彻底转向机架级互联(Scale-up 域大小)、光电混合交换与液冷系统工程。
    2. 两极化的内存博弈:一条路是以 HBM 为代表的大容量路线(满足长上下文与大批次吞吐);另一条路是以纯 SRAM 为代表的高带宽路线(追求单用户极致低延迟)。
    3. 软件范式收敛:从早期的手写专用底层算子,正逐步向 Triton、MLIR、XLA 等现代编译中间层收敛,软硬件解耦正在打破单一供应商的生态锁定。

    🔗 原文链接:https://www.jacobpeake.com/ai-chip-architectures

    #AI芯片 #半导体架构 #NVIDIA #TPU #大模型算力 AI Chip Architectures

  4. 代码不再是瓶颈:Anthropic 发布的「AI 原生软件工程(SDLC)实战手册」随着 Claude Code 等 Agent 编码工具的普及,编写代码的时间被大幅压缩至数小时

    代码不再是瓶颈:Anthropic 发布的「AI 原生软件工程(SDLC)实战手册」

    随着 Claude Code 等 Agent 编码工具的普及,编写代码的时间被大幅压缩至数小时。然而,传统的软件开发生命周期(SDLC)仍按“人类速度”运行——繁复的需求对齐、人工逐行 Code Review 和层层审批,反而成为了团队新的生产力瓶颈。

    Anthropic 官方近期梳理了一套完整的 AI-Native SDLC 转型框架,将传统的线性研发流程重构为以 Markdown 产物驱动的自治闭环

    ---

    🔄 六大阶段的关键演进

    1. 规划(Plan)|意图即代码
    • 告别漫长繁琐的 PRD 编写,业务人员通过与 Claude 头脑风暴直接生成 intent.md(意图文件)。
    • 机器可读、人类可审,提交至 Git 即可直接驱动下一阶段。

    2. 设计(Design)|需求与设计合二为一
    • 结合团队沉淀的规范库(Skills),Claude 基于 intent.md 快速产出 spec.md
    • 安全、合规与 UX 约束在生成设计时即刻生效,而非等到几周后的评审会议才被发现。

    3. 构建(Build)|计划驱动与组织记忆
    Plan Mode:必须先生成并确认 plan.md 才能落代码,杜绝 Agent 盲目编码。
    团队记忆库:通过 CLAUDE.md 和 Skills 固化团队规约;借助 Hooks 建立不可逾越的确定性防线。
    并行作战:配合 Git Worktree 和专有子 Agent(Subagents),单名工程师可同时调度多个任务。

    4. 测试(Test)|让 AI 自查自纠
    反馈闭环:为 Agent 配备自动化测试与 UI 视觉对比工具,要求“跑通测试才算 Done”,并禁止 AI 擅自修改测试用例以掩盖 Bug。
    Continuous Evals:在 CI 中引入 Agent 评估套件,像测代码一样回归测试提示词与配置。

    5. 部署(Deploy)|双向审查与严格卡点
    • AI 参与 PR 自动化多维度评审,并支持直接根据 @claude 评论修复代码;人类工程师重点聚焦于“业务意图”与“系统风险”。
    生产门禁:AI 的自主权终止于生产部署关卡,核心发布动作仍由 Hooks 拦截并等待人工最终授权。

    6. 运维(Maintain)|自主闭环的起点
    • 当监控指标(如 CI 失败率、5xx 错误)出现统计学异常时,自动化脚本唤醒 Claude 进行故障诊断并生成修复 PR 或新的 intent.md
    • 结合即时通讯工具(Claude Tag),实现告警自动排查、知识沉淀与自主闭环。

    ---

    核心总结:AI 原生 SDLC 的本质,是把研发流程从“人写代码、人走流程”,升级为“AI 负责闭环执行、人类把控关键治理与评判”的全新协作范式。

    🔗 原文链接:https://claude.com/blog/the-ai-native-sdlc-playbook

    #AI开发 #SDLC #ClaudeCode #软件工程 #人工智能 The AI-Native SDLC playbook | Claude by Anthropic

  5. 腾讯微信开源通用多模态向量模型 WeMM-Embedding:刷新 MMEB-v2 榜单,已在微信多业务落地腾讯微信视觉团队近日开源了通用多模态嵌入模型家族 WeMM-Embedding,论文与模型权重现已全面公开

    腾讯微信开源通用多模态向量模型 WeMM-Embedding:刷新 MMEB-v2 榜单,已在微信多业务落地

    腾讯微信视觉团队近日开源了通用多模态嵌入模型家族 WeMM-Embedding,论文与模型权重现已全面公开。

    🌟 核心亮点

    全模态统一表征:支持文本、图片、视频、视觉文档以及任意图文交错(Interleaved)混合输入,并支持灵活调整输出向量维度。
    2B/4B/9B 多尺寸覆盖
    2B 规格:表现强劲,性能已超越此前 8B 级别的开源 Baseline。
    9B 规格:在多模态检索与表征权威评测榜单 MMEB-v2 上取得 80.6 分,刷新综合 SOTA 纪录。
    两阶段训练架构:先通过大规模多模态数据完成空间对齐,再利用高质量精选数据、细粒度相关性监督与跨尺度知识迁移进行优化。
    工业级实战验证:不仅在微信内部 26 项基准测试和 14 组线上 A/B 测试中表现优异,目前已在视频号、微信公众号、朋友圈及电商搜索/推荐等核心场景规模化上线。

    ---

    🔗 相关链接

    • 论文页面:https://huggingface.co/papers/2608.24053
    • 模型集合:https://huggingface.co/collections/tencent/wemm-embedding
    • GitHub 开源地址:https://github.com/Tencent/WeMM-Embedding

    #多模态 #Embedding #腾讯 #开源模型 #微信团队 Paper page - WeMM-Embedding: WeChat Multi-Modal Embedding Technical Report

  6. 从“生成报告”到“解决复杂任务”:Apodex 1.1 正式发布传统的 AI 深度搜索往往以生成一份结构化报告为终点,但科研、金融和法律等领域的真实工作,通常在写完报告后才刚开始——清洗脏数据、选择方法、编写运行代码、根据中间结果调整方案,并保证每项结论都能经得起溯源检验

    从“生成报告”到“解决复杂任务”:Apodex 1.1 正式发布

    传统的 AI 深度搜索往往以生成一份结构化报告为终点,但科研、金融和法律等领域的真实工作,通常在写完报告后才刚开始——清洗脏数据、选择方法、编写运行代码、根据中间结果调整方案,并保证每项结论都能经得起溯源检验。

    针对这一痛点,Apodex 正式推出了 Apodex 1.1,旨在将 AI 从单纯的“问答工具”升级为能够处理长周期、多阶段复杂任务的在线工作台。

    ---

    核心亮点一览

    1. 真实环境下的长链路执行

    不再回避复杂的专业格式(CSV、PDF、分子结构等)。模型在真实的文件与代码环境中运行,自主处理异常并完成端到端的数据分析与交付。

    2. 支持运行中随时介入(Human-in-the-loop)

    复杂任务难免需要中途调整。Apodex 1.1 允许用户在任务执行的任意阶段添加新需求或新数据,系统会自动保留有效的中间产物并重新规划后续路径,无需从头再来。

    3. 任务分解与执行状态全透明

    拒绝黑盒等待。基于底层 AgentOS,系统会实时展示当前的执行计划、完成步骤、生成的产物与异常重试情况,让长耗时任务清晰可控。

    4. 自主异步多智能体团队(Agent Team)

    在 Deep Discover 模式下,模型会自主将复杂任务拆解并分发给多个子智能体并行探索。中间结果实时回流至主任务,大幅缩短复杂探索的等待耗时。

    5. 关键结论独立审查(Statement Review)

    将“内容生成”与“结论审核”解耦。针对数据推论、文献引用和计算结果进行独立的交叉校验与证据链追溯,显著降低幻觉风险。

    6. 开源支持与端侧部署

    除了网页端完整版,团队还推出了可本地部署的 35B Apodex 1.1 Mini,并开源了开箱即用的终端智能体框架 FrontierAgent(支持 macOS / Linux 单命令运行)。

    ---

    🔗 原文链接:https://www.apodex.com/blog/apodex-1.1-scaling-agentic-intelligence-for-complex-work

    #人工智能 #AI智能体 #Apodex #大语言模型 #深度研究 Apodex | Self-Evolving Heavy-Duty Solver

  7. AI Agent 框架如何实现崩溃自愈?深入 Pi 的 Durable Harness v2 架构设计在构建复杂且长周期的 AI Agent 系统时,进程崩溃、外部 API 超时以及并发冲突是不可避免的挑战

    AI Agent 框架如何实现崩溃自愈?深入 Pi 的 Durable Harness v2 架构设计

    在构建复杂且长周期的 AI Agent 系统时,进程崩溃、外部 API 超时以及并发冲突是不可避免的挑战。开源 AI Agent 工具库 Pi(earendil-works/pi)发布了其核心执行引擎 AgentHarness v2 的设计规范,全面重构了 Agent 的持久化、并发与容错模型。

    ---

    核心设计亮点

    1. 确定性持久化与崩溃恢复(Durable Runs)
    预写意图(Intent-first):在执行任何副作用(LLM 请求、工具调用)之前,必须先持久化一条意图记录;执行完成后再将结果作为节点提交。
    零中间态:无论是调用中断、系统崩溃还是上下文超限,重启后都能根据日志精确定位到最近的安全边界进行恢复或重试,绝不产生不一致的脏状态。

    2. Lanes(多泳道并行架构)
    • 引入类似 Git 分支的 Lane 概念。一个会话(Session)拥有唯一的共享对话树,但可以在上面并发运行多个独立的 Lane(如 Slack 频道下的不同 Thread)。
    • 每个 Lane 拥有独立的 Leaf 指针与操作日志,保证多任务互不干扰且免受竞态冲突影响。

    3. 对 KV Cache 极度友好的追加模式(Append-Only Context)
    • 运行中所有交互和配置修改均以追加(Append)形式进入上下文,避免因中间插入导致模型端 KV Cache 失效,显著降低 Token 消耗与延迟。
    • 只有在显式触发压缩(Compaction)时才做重整。

    4. 单步驱动与确定性测试(Deterministic Stepping)
    • 支持 manual 驱动模式:Agent 的每一个网络请求、工具执行、Hook 回调和存储写入都会在虚拟门控前暂停。
    • 开发者和测试套件可以一步步单步调试,任意注入输入或模拟崩溃,彻底消除异步 Agent 系统的难以复现的隐蔽 Bug。

    5. 清晰的职责分离
    Session Tree:只负责只增的对话与事实树,不掺杂编排逻辑。
    Operation Logs:记录状态机流水,专为崩溃恢复服务。
    Hooks 与 Events 分立:Hooks 负责拦截与修改执行流,Events 负责单向、实时的 UI 状态订阅。
    多存储后端:原生适配内存、JSONL 与 SQLite,并向下兼容 v3 格式。

    ---

    对于正在探索长时间运行 Agent、多分支 Agent 或企业级容错工作流的开发者来说,Pi 的 Harness v2 提供了一套非常严谨、工业级的状态机与架构参考范式。

    完整设计文档:https://github.com/earendil-works/pi/blob/harness-v2/j4/packages/agent/docs/harness-v2.md

    #AIAgent #系统架构 #开源项目 #LLM #状态机 pi/packages/agent/docs/harness-v2.md at harness-v2/j4 · earendil-works/pi

  8. 别再死磕终端界面了:AI 时代,我们该重新拥抱原生 GUI长久以来,开发者群体对终端(CLI)与终端图形界面(TUI)有着近乎执念的情怀

    别再死磕终端界面了:AI 时代,我们该重新拥抱原生 GUI

    长久以来,开发者群体对终端(CLI)与终端图形界面(TUI)有着近乎执念的情怀。我们习惯了用 ASCII 字符画窗口,忍受终端里生硬的滚动、选词和无障碍支持。但资深安全研究员与开发者 Thomas Ptacek 近日撰文直言:是时候停止编写新的 TUI,全面转向原生图形界面(Native GUI)了。

    为什么我们曾执着于 TUI?

    作者指出,CLI(命令行接口)具备不可替代的组合能力,永远不会过时;但 TUI(终端用户界面,如借助 Curses、Ratatui 等构建的字符界面)本质上是 70 年代哑终端与调制解调器时代的产物。开发者之所以青睐 TUI,往往不是因为终端天生更优越,而是过去开发原生 GUI 的学习成本和琐碎代码实在令人望而却步。

    在终端里,开发者需要费尽心思去模拟原生控件早已完美实现的基础特性:平滑滚动、拖放交互、多窗口浮动、图片渲染以及无障碍(a11y)支持。

    AI 彻底打破了原生 GUI 的门槛

    以往编写 SwiftUI、GTK 或 WinUI 需要掌握大量繁重的平台细节,但现在通过 Claude、Codex 等 AI Agent,构建原生界面的难度被降到了极低:

    • 作者在几乎没有手写 UI 代码的情况下,快速“召唤”出了一批自用原生 Mac 工具:Markdown 渲染器、SageMath 公式计算器、基于 SQLite 的 AI 音乐播放器、状态栏遥控器等。
    • 原生框架天生具备一致的设计语言、流畅的交互与完善的语义无障碍树,开发体验与最终成品质量远胜在终端中“打补丁”。

    驳斥几个常见的 TUI 迷思

    1. “TUI 信息密度高、键盘流效率高”:GUI 同样可以做到极高密度和纯键盘操作(如彭博终端),只是以往少有人专门为 Geek 定制。
    2. “TUI 方便 SSH 远程管理”:生产环境真正需要的是健壮的 CLI,完全可以由本地原生客户端(类似 Emacs TRAMP 的模式)来驱动远程交互。
    3. “TUI 更轻量、跨平台”:如果是为了自己顺手打造的小工具,为兼顾跨平台而牺牲全部交互体验并不划算。

    结语
    AI 正在消除前后端与图形界面的开发鸿沟。如果你依然习惯于把自用工具限制在黑黢黢的终端字符里,不妨尝试让 AI 为你的小脚本生成一个原生 GUI——这很可能会彻底改变你与计算机交互的方式。

    https://sockpuppet.org/blog/2026/08/20/stop-making-tuis/

    #软件开发 #原生应用 #SwiftUI #TUI #人工智能 Stop Making TUIs

  9. 你的网站对 AI 智能体友好吗?Vercel 推出评估工具 Is Agentic随着 AI Agent(智能体)逐渐成为网络内容的重要消费者与使用者,网站不仅要为人类设计,也需要对 AI 更加友好

    你的网站对 AI 智能体友好吗?Vercel 推出评估工具 Is Agentic

    随着 AI Agent(智能体)逐渐成为网络内容的重要消费者与使用者,网站不仅要为人类设计,也需要对 AI 更加友好。Vercel 联手 Ora 推出了 Is Agentic,一个专门评估网站“Agent 就绪度”(AI Agent Readiness Score)的在线测试工具。

    核心亮点:

    多维度能力检测:评估 AI Agent 在网站上的发现、检索、理解与交互体验。主要涵盖服务端渲染(SSR)、清晰的语义化结构、规范的 HTTP 响应及可恢复的错误处理等基础指标。
    动态匹配,不滥扣分:根据网站实际能力进行推荐项检测(如 API、OAuth 认证、GraphQL、MCP Server 支持等)。若网站本就不包含特定接口,不会因此扣分。
    具象化诊断与路径观察:不仅给出具体改进建议,还会记录 Agent 实际浏览该网站时的操作路径与遇到的阻碍(Friction)。
    面向 Agent 优化输出:支持直接以 Markdown、JSON API 形式读取报告,并提供了专属的 MCP(Model Context Protocol)Server,方便将检测能力直接集成到各类 Agent 工作流中。

    输入网址即可快速测试你的网站对 AI 智能体的易用程度,并获取针对性的优化建议。

    访问地址:https://is-agentic.com

    #AIAgent #Web开发 #Vercel #MCP #开发者工具 Is Agentic: AI Agent Readiness Score for your Site and App

  10. 让 AI 也能做出极简可爱的吉祥物:IP as Logo Skill为产品设计一个辨识度高、圆润可爱的 IP Logo 往往需要多次打磨

    让 AI 也能做出极简可爱的吉祥物:IP as Logo Skill

    为产品设计一个辨识度高、圆润可爱的 IP Logo 往往需要多次打磨。开源项目 ip-as-logo-skill 为具备生图能力的 AI Agent 提供了一套结构化的设计规范,帮助你一键生成可以直接商用的极简 IP 角色。

    🌟 核心亮点

    严控设计复杂度:遵循极简与微拟物(Neo-skeuomorphism)美学,主体由 4~7 个基础圆形几何构成,默认采用「2 种 IP 主色 + 1 种纯色背景」的三色搭配。
    精心调校的构图:角色默认从左下角或右下角探出并占据画面 85%~95%,避免传统居中构图的呆板感。
    标准化的生图流程:Agent 会先梳理产品背景并提供 3 种设计方向,确认后一次性生成 6 张不同构图的独立高清候选图,无需繁琐调试提示词。
    纯净的 Prompt 策略:提示词专注描述画面视觉元素,不包含 “logo/icon” 等干扰词,充分释放图像模型的生成质感。

    🛠️ 兼容性与安装

    支持 Codex、豆包、Coze、Manus、YouMind、Gemini Apps、Replit Agent 等支持图像资产输出的 Agent 环境。

    通过 Agent Skills CLI 一键安装:

    npx skills@latest add s1dashu/ip-as-logo-skill
    


    项目采用 MIT 协议开源,生成内容均可免费商用。此外,作者还提供了免费的在线图库 ipaslogo.com,无需配置即可直接下载现成素材。

    🔗 项目地址:https://github.com/s1dashu/ip-as-logo-skill

    #开源项目 #AIAgent #Logo设计 #AI生图 #设计工具

  11. 开源模型实现端到端自我提升:Ornith-1.5 正式发布Ornith 正式推出了 Ornith-1.5 模型家族,将此前的“自我脚手架(Self-Scaffolding)”机制拓展为完整的端到端自我进化闭环

    开源模型实现端到端自我提升:Ornith-1.5 正式发布

    Ornith 正式推出了 Ornith-1.5 模型家族,将此前的“自我脚手架(Self-Scaffolding)”机制拓展为完整的端到端自我进化闭环。模型不再单纯依赖人工标注数据,而是能够自主生成新任务、构建评估脚手架,并通过强化学习(GRPO)持续进行自我迭代与能力突破。

    ---

    核心技术亮点:自我驱动的学习闭环

    在每个训练周期中,Ornith-1.5 协同优化三个关键环节:

    1. 自主出题(Task Generation):根据历史解决记录,生成处于能力边界前沿、有效且具有多样性的新挑战。
    2. 构建脚手架(Scaffold Construction):自主设计解题策略、工具链和评估环境,并加入防作弊与对齐奖励机制。
    3. 策略优化(GRPO RL):通过解答方案的反馈,联合优化出题质量、脚手架有效性与模型解题策略,实现能力螺旋上升。

    ---

    三种规格模型与性能表现

    Ornith-1.5 覆盖了大中小三种参数规格,在代码生成、复杂推理与 Agent 任务上均有亮眼表现:

    Ornith-1.5-397B(旗舰 MoE)
    在 Terminal-Bench 2.1 取得 86.1 分,DeepSWE 取得 56.0 分,整体性能比肩 Claude Opus 4.8,并全面超越同体量的开源模型(如 DeepSeek-V4-Flash 与 GLM-5.2)。

    Ornith-1.5-35B(轻量 MoE,单 Token 仅激活 3B)
    在 Agent 编程和代码基准(如 SWE-Bench Verified)上大幅领先同量级对手,甚至显著超越了多款 30B 级别的稠密模型。

    Ornith-1.5-9B(端侧 Dense)
    专为边缘设备优化,提供手机端量化版本(支持 iPhone 与 Android),在紧凑体积下展现出越级打怪的推理与代码能力。

    ---

    🔗 阅读原文https://ornith.ai/ornith_1_5.html

    #人工智能 #开源大模型 #强化学习 #AI编程 Ornith-1.5: From Self-Scaffolding to Self-Improvement

  12. 通俗解读:什么是 AI 时代的「Agent Harness」?业界常用一个极简公式来定义智能体:Agent = Model + Harness

    通俗解读:什么是 AI 时代的「Agent Harness」?

    业界常用一个极简公式来定义智能体:Agent = Model + Harness

    如果把大模型(Model)比作攀登者的核心力量,那么 Harness(原意为登山安全带/挽具) 就是为你提供支撑、挂载工具并确保安全的整套装备。

    在 AI 领域,Agent Harness 是为模型提供运行环境的软件外壳。它主要承担四个核心职能:

    1. 系统提示(System Prompt):像给新员工的工作指引,规范模型在特定场景下的行为准则。
    2. 工具挂载(Tools):为模型提供搜索、写代码、发邮件等能力接口,并由模型自主判断何时调用。
    3. 自主循环(Agentic Loop):构建「理解任务 ➔ 调用工具 ➔ 评估结果 ➔ 自主修正 ➔ 交付成果」的完整工作流闭环。
    4. 模型转换层(Translation Layer):抹平不同大模型(OpenAI、Anthropic、开源模型等)的接口差异,支持灵活切换与混用。

    为什么 Harness 越来越重要?
    大模型往往掌握在少数巨头手中,但 Harness 可以开源并运行在本地。借助像 Pi、OpenClaw 这类中立的开源框架,用户能够将控制权掌握在自己手中,按需定制属于自己的 AI 工作流。

    阅读原文:https://earendil.com/posts/what-is-a-harness/

    #AI智能体 #Agent #人工智能 #开源技术 What is a Harness? | EARENDIL

  13. 告别合盖中断:为 AI 编程智能体打造的专属后台运行环境 Herdr在使用 Claude Code、Codex 等 AI 编程助手时,许多人经常遇到两个痛点:一旦合上笔记本电脑或断开连接任务就会中断;同时跑多个 Agent 时,很难及时发现哪一个正在等待输入确认

    告别合盖中断:为 AI 编程智能体打造的专属后台运行环境 Herdr

    在使用 Claude Code、Codex 等 AI 编程助手时,许多人经常遇到两个痛点:一旦合上笔记本电脑或断开连接任务就会中断;同时跑多个 Agent 时,很难及时发现哪一个正在等待输入确认。

    Herdr 正是为解决这些问题而生的智能体运行时(Runtime)。它作为一个后台服务运行,接管终端会话,让你的 AI 智能体可以全天候自主工作。

    核心特性

    后台常驻,合盖不掉线:终端直接运行在 Herdr 后台服务中,即使关闭电脑屏幕、网络断开甚至系统重启,会话与分屏布局都能完整保留并继续执行。
    状态感知,告别逐屏排查:自动识别每个窗格中 Agent 的实时状态(工作中 / 等待输入 / 空闲),当某个 Agent 需要人工确认时一目了然,无需在多个终端间来回切换。
    Agent 原生协作:提供统一的 CLI 与 Socket API,不同的 Agent 可以自主分屏、相互唤起并协同处理复杂任务。
    开箱即用,无缝兼容:无需改变原有的使用习惯,开箱支持 Claude Code、Cursor、Codex、Copilot 等 20 多种主流 Agent CLI,单二进制文件支持 macOS、Linux 和 Windows。

    安装只需一行命令即可接入现有的开发流,让 AI 智能体真正具备独立持续干活的能力。

    原链接:https://herdr.dev/

    #AI编程 #Agent运行时 #开发者工具 #ClaudeCode #终端工具 Herdr: the runtime coding agents run on

  14. fx:仅 6MB 的极简原生 AI 编程 Agent不同于动辄数十兆、界面复杂的“终端 IDE”,fx 是一款用 Zig 语言编写的超轻量 AI 编程助手与 CLI 工具,专注于极致性能与易嵌入性

    fx:仅 6MB 的极简原生 AI 编程 Agent

    不同于动辄数十兆、界面复杂的“终端 IDE”,fx 是一款用 Zig 语言编写的超轻量 AI 编程助手与 CLI 工具,专注于极致性能与易嵌入性。

    核心亮点:

    极小体积与资源占用:编译二进制仅约 6.4 MB,内存占用在个位数 MB 级别,非常适合资源受限环境与沙箱密集部署。
    瞬时冷启动:冷启动时间仅需约 10 微秒,输入前无冗余 I/O 操作,完美适配脚本化与程序调用。
    纯粹的 Shell 体验:摒弃繁复的 TUI 绘制,保留原汁原味的 Unix 命令行滚动交互体验。
    高效节省 Token:精简系统提示词(System Prompt)与工具集设计,不仅显著降低 Token 消耗,还进一步优化了首字生成延迟(TTFT)。
    Wasm 与生态扩展:支持编译为 WebAssembly 直接在浏览器或沙箱运行,并支持通过 MCP、插件与技能进行灵活扩展。
    开源与模型中立:采用 Apache-2.0 协议,支持本地模型、API 网关及各大商业大模型。

    体验与文档:https://fx.sh/

    #开源项目 #AI编程 #Agent #Zig #CLI工具 fx - Tiny, open, native coding agent

  15. Cloudflare 推出 Kitesurf:专为 AI Agent 打造的轻量级浏览器传统的浏览器(如 Chromium)是为人类设计的,包含了大量 AI 并不需要的组件(如标签页、主题、平滑滚动等),这使得它们非常消耗内存和计算资源

    Cloudflare 推出 Kitesurf:专为 AI Agent 打造的轻量级浏览器

    传统的浏览器(如 Chromium)是为人类设计的,包含了大量 AI 并不需要的组件(如标签页、主题、平滑滚动等),这使得它们非常消耗内存和计算资源。为了解决这个问题,Cloudflare 团队基于其 Workers 平台构建了一款专门针对 AI 代理(Agent)的新型浏览器——Kitesurf

    核心亮点

    专为 AI 优化:抛弃了人类才需要的视觉与交互开销,专注于 Token 数量、上下文窗口、可扩展性以及成本。
    极致的资源节省:与 Chromium 相比,在执行网页截图和 HTML 提取等常见任务时,Kitesurf 的 CPU 占用减少了 3 倍以上,内存占用减少了 4 到 7 倍,大幅降低了运行成本。
    构建在边缘网络:完全运行在 Cloudflare Workers 之上,利用 Rust 编译的 Wasm 模块和 Dynamic Workers 技术,实现极高的隔离性与无状态运行。
    兼容现有工具:支持 CDP(Chrome DevTools Protocol)协议,你可以直接配合 Puppeteer、Playwright 以及各类 MCP 客户端使用。

    虽然目前 Kitesurf 的首帧渲染时间比 Chromium 稍慢(约 1.7 倍),且暂不支持 WebGL、视频播放等复杂功能,但对于高并发的网页内容提取、截图及自动化任务,它是一个极具性价比的轻量化选择。

    Kitesurf 目前已在 Browser Run 开放免费 Beta 测试,并计划在成熟后开源。

    https://blog.cloudflare.com/kitesurf/

    #Cloudflare #AIAgent #浏览器 #开发者 #技术资讯 Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers

  16. 超越 Git:Zed 推出专为 AI 协作打造的版本控制系统 DeltaDB代码的诞生正逐渐从“提交(Commit)”转向“对话(Conversation)”

    超越 Git:Zed 推出专为 AI 协作打造的版本控制系统 DeltaDB

    代码的诞生正逐渐从“提交(Commit)”转向“对话(Conversation)”。传统的 Git 机制已无法满足人与人、人与 AI 代理(Agent)之间的高频实时协作。为此,现代编辑器 Zed 宣布推出全新的版本控制系统——DeltaDB

    与通过 Commit 捕获代码快照的 Git 不同,DeltaDB 的核心理念是将开发过程中的每一次微小操作(Delta)都记录下来。它的主要特性包括:

    记录每一次操作:不仅是 Commit,DeltaDB 会捕获每一次编辑并赋予其唯一身份,支持随时回溯任意时刻的代码状态,并允许多人与 AI 共同实时修改同一文件。
    代码与对话无缝绑定:版本控制不再只针对代码,还包括促成这些代码的对话。你可以从任意一行代码追溯到生成它的讨论上下文,AI 也可以借此理解代码的设计初衷。
    消除繁琐的协作仪式:无需等待 Commit、Push 和 Pull Request。团队成员可以随时加入正在进行的工作区,直接与 AI 或同事交流,让沟通在编写代码的瞬间发生。

    DeltaDB 旨在让 Git 和 CI 回归它们最擅长的安全检查与发布功能,而把日常协作留给更实时的工具。该系统预计在几周内开启 Beta 测试。

    原链接:https://zed.dev/blog/introducing-deltadb

    #DeltaDB #Zed #版本控制 #协同开发 #AI时代 Software Is Made Between Commits

  17. anydoc:毫秒级将主流文档转换为干净 Markdown 的 Rust 利器anydoc 是由网页解析平台 Firecrawl 开源的一款极速文档转换库

    anydoc:毫秒级将主流文档转换为干净 Markdown 的 Rust 利器

    anydoc 是由网页解析平台 Firecrawl 开源的一款极速文档转换库。它完全基于 Rust 编写,旨在将 Word、PowerPoint、Excel、PDF、EPUB、RTF 及 CSV 等多种主流文档格式,统一转换为干净、规范的 GitHub 风格 Markdown(GFM)。

    核心亮点:

    极致性能:纯 Rust 编写,不依赖重量级 AI 模型或外部云服务,单次转换的中位数时间小于 5 毫秒。
    📦 多端支持:除了 Rust 原生库外,还提供了 Node.js、Python 绑定以及开箱即用的 CLI 命令行工具。
    🤖 AI Agent 友好:支持作为 Agent Skill 一键集成(例如使用 npx skills),方便 AI 智能体直接读取和理解本地文档。
    🔍 智能格式检测:通过文件头字节自动识别格式,即使文件后缀名错误也能精准转换。
    📊 基准测试领先:在与 Pandoc、Docling、MarkItDown 等工具的对比测试中,anydoc 在格式支持完整度与转换速度上表现十分抢眼。

    无论是用于构建 LLM 知识库的数据预处理,还是日常的文档清理,anydoc 都是一个非常高效的开发者工具。

    项目地址:https://github.com/firecrawl/anydoc

    #Markdown #Rust #文档转换 #开发工具 #开源项目 GitHub - firecrawl/anydoc: Convert Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV, and PDF to clean Markdown. Built in Rust…

  18. 让 AI 自主付费:Cloudflare 推出面向 Agent 的可编程钱包在 AI 时代,智能体(Agent)想要尝试新的 API 或付费内容并不容易

    让 AI 自主付费:Cloudflare 推出面向 Agent 的可编程钱包

    在 AI 时代,智能体(Agent)想要尝试新的 API 或付费内容并不容易。它们既没有稳定的身份去注册,也无法像人类一样直接绑定信用卡,这大大限制了“智能体商业”的发展。

    为了解决这一痛点,Cloudflare 宣布推出 Cloudflare Wallets,为 AI 智能体提供原生的支付与身份验证方案。

    核心设计与功能:

    双层钱包架构
    账户钱包 (Account Wallets):由人类账号所有者管理,负责资金充值与规则制定。
    虚拟钱包 (Virtual Wallets):分配给 AI 智能体使用。人类可以为其设置“零花钱”限额、白名单和单次交易上限,让 AI 在可控风险内自主测试不同的 API 服务。
    微支付支持:结合 Monetization Gateway,钱包利用 x402 协议实现了将支付信息直接附加在 HTTP 请求中,极大地简化了机器对机器的交易流程。
    可读的智能体身份:用户可以为自己的账户申领 cloudflare.pay 域名。AI 智能体在访问服务时,可以通过如 research.example.cloudflare.pay 这样的可读标识公开身份,便于商家提供试用额度或进行白名单管理。

    Cloudflare Wallets 的推出,意味着未来互联网将迎来一个专为 AI 设计的、无缝的“机器原生”交易市场。

    原链接:https://blog.cloudflare.com/wallets/

    #Cloudflare #AI智能体 #数字钱包 #网络支付 #微支付 Announcing Cloudflare Wallets: The programmable wallet for the agentic Internet

  19. 深入浅出 Chrome DevTools Protocol (CDP):浏览器自动化的幕后功臣当你在 Chrome 中按下 F12 打开开发者工具,查看网络请求、调试 JS 代码或模拟手机时,你是否好奇过这个面板是如何与浏览器核心进行通信的?答案就是 CDP(Chrome DevTools Protocol,Chrome 开发者工具协议)

    深入浅出 Chrome DevTools Protocol (CDP):浏览器自动化的幕后功臣

    当你在 Chrome 中按下 F12 打开开发者工具,查看网络请求、调试 JS 代码或模拟手机时,你是否好奇过这个面板是如何与浏览器核心进行通信的?

    答案就是 CDP(Chrome DevTools Protocol,Chrome 开发者工具协议)。它是所有 Chromium 系浏览器(包括 Chrome、Edge、Brave、Arc 等)对外的控制接口。无论是开发者面板本身,还是 Puppeteer、Playwright 等自动化测试框架,甚至是最新的 AI 浏览器 Agent,底层都依赖 CDP。

    什么是 CDP?

    CDP 是一个基于 JSON 的通信协议,通常通过 WebSocket 传输。它将浏览器的控制权划分为多个不同的“域”(Domains):

    Page:负责控制页面导航、截屏等。
    Network:观察和拦截网络请求与响应。
    Runtime:执行 JavaScript 代码并获取控制台输出。
    Input:模拟底层的鼠标、键盘和触摸输入。
    Target:发现并连接到不同的页面、Iframe 或 Service Worker。

    为什么直接操作原生 CDP 非常困难?

    虽然发送 JSON 指令看起来很简单,但维护浏览器状态却极其复杂:

    1. 动态生命周期:页面导航会销毁旧的 JavaScript 执行上下文并创建新的上下文。一旦发生跳转,之前的对象 ID 和引用都会失效。
    2. 多进程架构(Site Isolation):为了安全,浏览器会将跨站点的 Iframe 放在不同的渲染进程中。在 CDP 中,这意味着它们会被作为不同的 Target 暴露,你需要自己管理复杂的 Session 树。
    3. 协议演进快:CDP 的方法会随着 Chromium 的更新而频繁变动,维护兼容性成本极高。

    因此,在实际开发中,更推荐使用 Playwright 或 Puppeteer 这样成熟的库。它们帮我们处理了繁琐的等待、定位和生命周期管理,只在需要更底层能力时才向外暴露 CDP 会话。

    理解 CDP 的工作原理,能让我们在构建浏览器自动化工具或浏览器 AI Agent 时,做出更合理的架构设计。

    原文链接:https://x.com/kylejeong/status/2078196340216185127

    #浏览器自动化 #Chrome #CDP #开发者工具 #Web开发

  20. 为什么 MCP 服务器难以部署在 Serverless 架构上?随着大模型生态的发展,MCP(Model Context Protocol,模型上下文协议)成为了连接 AI 助手与外部工具的热门选择

    为什么 MCP 服务器难以部署在 Serverless 架构上?

    随着大模型生态的发展,MCP(Model Context Protocol,模型上下文协议)成为了连接 AI 助手与外部工具的热门选择。然而,在实际部署中,开发者很快就会遇到一个棘手的架构问题:MCP 服务器默认是有状态的(Stateful)

    1. 单客户端的尴尬限制

    在最基础的 HTTP/SSE(Server-Sent Events)实现中,服务器通常会将连接通道(Transport)保存在内存变量中。这意味着,一旦有第二个客户端尝试连接,前一个客户端的连接就会被迫中断。

    2. 内存常驻与 Serverless 的冲突

    即便我们通过引入 ID 标识来管理多个连接,依然无法解决核心问题——连接状态依然保存在服务器的内存中。

    这种“有状态”的特性,直接把 Serverless 部署方案(如 Vercel、AWS Lambda)排除在外。因为 Serverless 函数在请求结束后会随时销毁实例,导致内存中的连接状态丢失。要维持连接,你只能选择 VPS 等需要持续运行的服务器,这增加了运维成本。

    3. 如何实现无状态化?

    目前最可行的解决方案是将状态外置。我们可以将 Transport 信息存储到像 Redis 这样的键值数据库中。

    通过将状态抽离到 Redis,MCP 服务器成功实现了无状态化(Stateless),从而能够自由地部署到 Vercel 等 Serverless 平台上。Vercel 官方开源的 mcp-on-vercel 项目正是采用了这种架构设计。

    思考

    虽然通过 Redis 解决了部署问题,但这无疑增加了系统的复杂度。我们不禁会想:在协议设计之初,是否应该让客户端去承担更多的状态维护,从而避免让服务端背上数据库的包袱?

    ---

    原文链接:https://www.aihero.dev/the-problem-with-mcp-stateful-server

    #MCP #Serverless #系统架构 #Redis #AI开发 The Problem With MCP: Stateful Servers

1px