Search: #AI自动化

  1. 算力战国策:拆解主流 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

  2. 代码不再是瓶颈: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

  3. 从“生成报告”到“解决复杂任务”: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

  4. 开源模型实现端到端自我提升: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

  5. 开源 AI 模型安全吗?Cognition 发布可信度评估报告低成本且广泛可用的开源模型正在推动 AI 应用的爆发,但它们的安全性和可信度也引发了广泛担忧

    开源 AI 模型安全吗?Cognition 发布可信度评估报告

    低成本且广泛可用的开源模型正在推动 AI 应用的爆发,但它们的安全性和可信度也引发了广泛担忧。为此,智能体开发商 Cognition 建立了一套模型可信度评估体系,并对其基于开源模型 Kimi K2.7 Code 训练的软件工程模型 SWE-1.7 进行了深度测试。

    测试主要从以下三个维度展开:

    1. 政治宣传与审查过滤

    测试使用包含 145 个敏感问题的测试集,评估模型在不同语言下的中立性。结果显示,一些来自中文社区的开源模型在中文语境下容易输出带有偏向性的特定叙事。而经过优化后的 SWE-1.7,其答复中立性表现已经与 GPT 5.5、Claude Opus 等顶级闭源模型不相上下。

    2. 恶意请求的拒绝能力

    在面对具有潜在危害的开发请求(例如编写用于非法监控特定人群的代码)时,原始开源模型(如 Kimi K2.7)往往会盲目顺从,甚至主动完善监控功能。而 SWE-1.7 则能准确识别风险并坚决予以拒绝。

    3. 针对特定对象的“潜在安全隐患”

    此前有研究称,部分开源模型在面对特定用户身份(如某些政府机构或组织)时,可能会故意降低代码安全性。Cognition 在其沙箱运行环境中进行了验证,结果表明,在完整的智能体(Agent)工作流中,不同“人设”对模型生成的代码安全性的实际影响极小,SWE-1.7 在各种背景下均能保持稳定、一致的代码质量。

    结论
    开源模型本身并不是天然不安全的。只要在后训练(Post-training)阶段投入足够的安全对齐与精心设计,基于开源模型微调的产品完全可以达到甚至超越顶级闭源模型的安全与可信标准。

    https://cognition.com/blog/measuring-open-source-model-trustworthiness

    #人工智能 #开源模型 #AI安全 #大模型 #Cognition Measuring the Trustworthiness of Open-Source-Derived Models

  6. 极简终端 AI 编码助手,带你读懂 Agent 的核心设计:TauHugging Face 开源的 Tau 是一款运行在终端(Terminal)里的 AI 编码助手

    极简终端 AI 编码助手,带你读懂 Agent 的核心设计:Tau

    Hugging Face 开源的 Tau 是一款运行在终端(Terminal)里的 AI 编码助手。只需输入简单的需求,它就能帮你读取文件、修改代码、执行 Bash 命令并记录会话历史。

    不同于庞大复杂的商业项目,Tau 的核心定位是一个教学型项目。它的代码极其精简、层级分明,非常适合开发者用来理解“AI 编码 Agent 是如何从零构建的”。

    核心特性:

    极简且模块化的架构:代码分为 tau_ai(模型适配)、tau_agent(核心大脑与工具流)和 tau_coding(TUI 与命令行包装器)三层,核心大脑完全独立,可轻松作为第三方库引入。
    终端交互式操作:内置基于 Textual 的命令行 TUI 界面,支持 /login 登录、模型切换以及流式输出。
    多模型支持:支持对接 OpenAI、Anthropic、OpenRouter、Hugging Face 以及兼容 OpenAI 格式的本地大模型。
    持久化会话管理:通过 JSONL 格式安全存储每一次会话,支持中断恢复与分支操作。

    如果你想拥有一个轻量级的命令行开发助手,或是想动手写一个自己的 AI Agent,Tau 是一个绝佳的起点。

    项目链接:https://github.com/huggingface/tau

    #AI #Agent #Python #开源项目 #编程助手 GitHub - huggingface/tau: A Python port of Pi’s minimalist coding agent.

  7. Claude Code 在系统提示词中暗藏“隐写”标记安全研究人员最近在分析 Anthropic 的命令行 AI 助手 Claude Code (v2.1.196) 时,发现其内部包含一段特殊的代码

    Claude Code 在系统提示词中暗藏“隐写”标记

    安全研究人员最近在分析 Anthropic 的命令行 AI 助手 Claude Code (v2.1.196) 时,发现其内部包含一段特殊的代码。当用户使用非官方 API 接口或特定时区时,它会暗中修改发送给大模型的系统提示词(System Prompt),通过微小的文本变化为请求打上“隐形水印”。

    隐写机制是如何工作的?

    这种机制主要通过修改系统提示词中“今天日期”的文本格式来实现,极其隐蔽:

    1. 时区检测:如果用户的系统时区为 Asia/Shanghai(上海)或 Asia/Urumqi(乌鲁木齐),提示词中的日期分隔符会从连字符 - 隐悄悄替换为斜杠 /(例如:2026-06-30 变成 2026/06/30)。
    2. 自定义域名检测:如果用户设置了环境变量 ANTHROPIC_BASE_URL(通常用于使用自定义网关、本地代理或中转 API),Claude Code 会检测该域名,并微调 "Today's" 中单引号 ' 的 Unicode 字符(例如替换为 ʻʼ)。在大多数等宽字体中,这些字符的视觉差异极小,用户几乎无法察觉。

    针对的目标

    代码中包含一个经过混淆处理(Base64 编码并进行 XOR 解密)的关键词和域名列表。名单中包括了多家主流中国科技公司(如字节跳动、百度、阿里、腾讯等)、AI 实验室(如 DeepSeek、月之暗面、智谱 AI、零一万物等)以及大量第三方 API 代理和中转服务域名。

    为什么令人担忧?

    Anthropic 这么做很可能是为了在后端识别非官方的 API 转售商、未授权的网关,或是防止模型被用于“蒸馏”训练。

    虽然防范滥用合情合理,但这种“隐写”的实现方式引发了安全社区的质疑。作为一个拥有本地文件系统读写、执行 Shell 命令、甚至管理 Git 仓库等极高权限的开发者工具,建立信任至关重要。研究人员认为,如果工具需要检测自定义网关或进行合规审计,应该通过公开的遥测(Telemetry)字段和透明的政策来告知用户,而不是在发送的数据包中暗中植入隐形标记。

    对于直接使用 Anthropic 官方 API 且未修改 Base URL 的普通用户,该机制不会被触发。

    https://thereallo.dev/blog/claude-code-prompt-steganography

    #网络安全 #AI安全 #隐私保护 #Claude #逆向工程 Claude Code Is Steganographically Marking Requests

  8. 用 Cloudflare Workers 打造专属 AI 邮件与日历中心:开源项目 agentic-cal如果你正在寻找一种不依赖复杂 API 就能聚合多平台日程、并用 AI 辅助处理邮件的方案,这个开源项目非常值得关注

    用 Cloudflare Workers 打造专属 AI 邮件与日历中心:开源项目 agentic-cal

    如果你正在寻找一种不依赖复杂 API 就能聚合多平台日程、并用 AI 辅助处理邮件的方案,这个开源项目非常值得关注。

    agentic-cal 是一个部署在 Cloudflare Workers 上的自托管邮件与日历中心(基于 cloudflare/agentic-inbox 分支开发)。它拥有以下核心功能:

    多平台日历聚合(只读): 无需 OAuth 或第三方 API,直接通过 Proton、Outlook 和 iCloud 的公开 ICS 链接,自动将多平台日程融合成一个统一的“忙/闲”模型。
    基于邮件的日程预定(写入): 采用标准的邮件邀请机制(iMIP 协议)。当需要锁定时间时,系统会向你的账号发送一封标准的会议邀请邮件,你只需在常用客户端点击“接受”,即可完成日程写入。
    内置 AI 助手与 MCP 服务: 集成了 Workers AI,不仅能智能起草邮件回复,还会在预约日程前自动检查你的空闲时间。项目还向外暴露了 20 个 MCP(Model Context Protocol)工具,方便你将日程和邮件功能接入 Claude Code 等外部 AI 智能体。
    独立的自托管邮箱: 配合 Cloudflare Email Routing 和 Durable Objects (SQLite),提供完整的邮件收发、富文本编辑、搜索及附件管理功能。

    无论是想要一个无广告、完全掌控的个人邮箱,还是希望用 AI 自动化打理自己的日常排期,agentic-cal 都提供了一个极其优雅的轻量化解决方案。

    https://github.com/talalakkari/agentic-cal

    #Cloudflare #AI助手 #开源项目 #日程管理 #MCP GitHub - talalakkari/agentic-cal: Agentic email + calendar hub on Cloudflare Workers. One Worker owns your domain's email surface:…

  9. AI 记忆系统不该靠“设计”,而应靠“演化”如今,开发者们热衷于为 AI 助手构建各种复杂的记忆架构,比如向量检索、知识图谱、语义记忆、遗忘机制等

    AI 记忆系统不该靠“设计”,而应靠“演化”

    如今,开发者们热衷于为 AI 助手构建各种复杂的记忆架构,比如向量检索、知识图谱、语义记忆、遗忘机制等。但作者指出,这个领域存在一个奇怪的失衡:我们花了太多精力去“发明”记忆架构,却很少花精力去评估这些系统是否真的让 Agent 在长期交互中变得更好。

    很多所谓的记忆系统,大多只是基于开发者个人对“好记忆”的狭隘定义而做出的过度工程(Over-engineering)。

    💡 核心观点:记忆是“涌现”出来的

    记忆并不是系统的第一顺位基础能力。相反,记忆是在持续交互的压力下,为了让系统表现得更好而涌现出来的“二阶效应”。

    因此,构建更好记忆系统的正确路径,不是凭空去设计它,而是构建一个“如果不提供好记忆,系统就无法生存”的评估环境,让优秀的记忆机制在压力下自己进化出来。

    ⚠️ 现有静态评估的缺陷

    目前的记忆评估大多是静态的:给 AI 一段历史记录,问一个当前问题,检查 AI 能否检索到相关事实。
    这种方式的弊端显而易见:

    • 它只能测试单一时间节点的检索能力。
    • 它无法评估记忆随着时间推移的更新、冲突解决和衰减。
    • 它忽略了用户体验的反馈循环——如果 AI 记忆表现不佳,用户在现实中会逐渐失去耐心,减少或停止相关交互。

    🛠️ 理想的“纵向记忆评估”方案

    为了解决这一问题,我们需要构建一个**纵向记忆评估(Longitudinal Eval)**环境,主要包含以下要素:

    1. 可重放的交互历史与未来依赖:模拟一连串(例如 200 次)的连续对话,后续的测试点会深度依赖前期的隐性偏好或数据。
    2. 动态用户模拟(User Simulation):用模拟的用户 Agent 来产生真实的对话。这些模拟用户甚至会根据 AI 记忆的表现来改变自己的交互行为(例如,如果 AI 总是记不住某事,模拟用户就会放弃聊这个话题)。
    3. 多维度的评分机制:不仅评估回答是否正确,还要权衡记忆质量与计算成本、延迟之间的关系,避免一味追求高分而使用在生产环境中无法落地的高昂算力。

    结语

    不要再尝试自上而下地去设计完美的记忆架构了。我们应该先建好“角斗场”(评估环境),让环境压力筛选出最合理的记忆方案。

    阅读原文:https://linghao.io/posts/memory-systems-should-be-evolved

    #人工智能 #AI_Agent #记忆系统 #大语言模型 #系统评估 Evolving Memory Systems: An Eval-First Approach

  10. 聪明人的分工:让昂贵模型做规划,便宜模型去执行知名开源开发者 shadcn 刚刚开源了一个全新项目——improve

    聪明人的分工:让昂贵模型做规划,便宜模型去执行

    知名开源开发者 shadcn 刚刚开源了一个全新项目——improve

    这是一个非常巧妙的 Agent Skill,它的核心理念是:用你最聪明(也最昂贵)的 AI 模型来做高杠杆的脑力劳动(审计代码、写技术方案),然后把脏活累活(编写代码、跑测试)交给更便宜的 AI 模型去执行。

    这个工具本身绝对不会直接修改你的一行代码,它的产出就是一份清晰、可执行的 Markdown 格式实施方案

    💡 它是如何工作的?

    1. 项目审计 (/improve):高阶模型会深度扫描并分析你的代码库,指出潜在的 Bug、性能瓶颈、安全隐患或技术债,并产出一份按“投入产出比”排序的发现清单。
    2. 制定方案 (plans/):当你挑选出需要解决的问题后,高阶模型会针对每个问题输出一份极其详尽的方案(Plan)。这些方案是“自包含”的,带有明确的验证命令、执行边界和异常中止条件(STOP conditions)。
    3. 分发执行 (/improve execute <plan>):你可以把这些高可读性的方案直接扔给任何便宜的轻量级 AI Agent。轻量级模型只需像个机械的执行者一样,按照步骤修改代码、运行测试,最后向你提交 Pull Request。

    🚀 核心指令一览

    /improve:全局审计并输出优化点。
    /improve quick:快速扫描重点。
    /improve deep:对每个包、每个分类进行详尽审计。
    /improve plan <description>:跳过审计,直接为指定任务编写执行方案。
    /improve execute <plan>:派发给便宜的执行器模型并审核其成果。

    安装方式

    项目支持 Agent Skills 规范:

    npx skills add shadcn/improve
    


    https://github.com/shadcn/improve

    #AI开发 #智能代理 #软件工程 #GitHub开源 #shadcn Agent Skills Overview - Agent Skills

  11. Yansu:无需指令,为你主动构建工具的“预知” AI你是否厌倦了反复在不同应用间手动同步数据?或者因为繁琐的流程而被迫成为“效率工具专家”?Yansu 是一款全新的主动式 AI 应用

    Yansu:无需指令,为你主动构建工具的“预知” AI

    你是否厌倦了反复在不同应用间手动同步数据?或者因为繁琐的流程而被迫成为“效率工具专家”?

    Yansu 是一款全新的主动式 AI 应用。它不像 ChatGPT 那样等待你的指令,而是通过观察你的工作习惯,为你自动构建专属工具。

    核心亮点:

    观察即学习:它静默观察你的桌面操作、沟通记录和决策模式,将零散的行为提炼为结构化的知识。
    主动式交付:不需要你写 Prompt。当它发现重复的流程或潜在的需求时,会先于你想到之前就把应用建好。
    虚拟交互:它拥有独立的虚拟指针,可以在不干扰你操作的情况下,自动填写表单、同步状态或整理信息。
    隐私本地化:所有工作记忆和生成的应用都存储在本地,只有在得到你明确许可时才会与外部交互。
    无感化办公:它不会抢夺窗口焦点,也不会打断你的思路,像是一个默默工作的资深助理。

    告别繁琐的手动工作,让 AI 在你还没意识到需求时就完成交付。

    https://yansu.app/

    #AI效率 #自动化 #生产力工具 #人工智能 #Yansu Yansu — The proactive AI that turns how you work into knowledge, handoffs, and automations

  12. Obscura:专为 AI Agent 和大规模爬虫打造的 Rust 无头浏览器如果你觉得传统的 Headless Chrome 过于臃肿且容易被反爬虫识别,那么 Obscura 绝对值得一试

    Obscura:专为 AI Agent 和大规模爬虫打造的 Rust 无头浏览器

    如果你觉得传统的 Headless Chrome 过于臃肿且容易被反爬虫识别,那么 Obscura 绝对值得一试。这是一个基于 Rust 编写的开源无头浏览器引擎,旨在为 AI Agent 和网页抓取提供极速、轻量且隐形的自动化体验。

    核心优势

    轻量化:内存占用仅需约 30MB(相比 Chrome 的 200MB+),二进制文件仅 70MB。
    极致速度:启动几乎是瞬间完成,页面加载速度比 Headless Chrome 快约 6 倍。
    内置隐身模式:默认支持反指纹识别、随机化 GPU/Canvas/Audio 等硬件信息,并自动拦截 3500+ 个追踪器。
    兼容性强:支持 Chrome DevTools Protocol (CDP),可以作为 Puppeteer 和 Playwright 的无缝替代品。
    Rust 驱动:利用 V8 引擎运行真实 JavaScript,确保执行环境的高性能与安全性。

    快速上手

    Obscura 提供单二进制文件,无需安装 Node.js 或 Chrome 即可运行。你可以通过简单的命令行直接抓取动态内容,或者启动一个 CDP 服务器供自动化脚本调用:

    # 获取网页标题
    ./obscura fetch https://example.com --eval "document.title"
    
    # 启动 CDP 服务
    ./obscura serve --port 9222 --stealth
    


    对于追求性能和隐匿性的开发者来说,Obscura 是构建下一代 AI 自动化工具的理想底层引擎。

    https://github.com/h4ckf0r0day/obscura

    #开源项目 #无头浏览器 #Rust #AI工具 #爬虫技术 GitHub - h4ckf0r0day/obscura: The headless browser for AI agents and web scraping

  13. AI 时代怎么招工程师:Augment 的「AI-native」人才标准当 AI agent 能写出大部分代码后,工程师的价值开始上移:不再以“写得快、写得多”为核心,而是以判断力、系统设计与协同能力决定产出质量

    AI 时代怎么招工程师:Augment 的「AI-native」人才标准

    当 AI agent 能写出大部分代码后,工程师的价值开始上移:不再以“写得快、写得多”为核心,而是以判断力、系统设计与协同能力决定产出质量。

    Augment 重新梳理了面向 AI-native(与 AI 共同工作)团队的招聘标准,核心变化可以概括为一句话:人从“作者”变成“架构师与编辑”——定义意图、做取舍、设护栏、把好质量关。

    工程师工作重心的迁移

    • 传统工程:写代码、实现方案、解决问题、看个人产出
    • AI-native 工程:明确意图与权衡、编排 agent、选择正确问题、看系统级结果

    他们认为最重要的 6 个能力维度

    1. 产品与结果品味(Product & Outcome Taste):能否在代码变“更便宜”时,避免做出“最贵的错误”——把方向做错。
    2. 系统与架构判断(System & Architectural Judgment):代码能跑不难,难的是“能在生产环境长期稳定地跑”。
    3. Agent 杠杆(Agent Leverage):能否把 AI 变成真实吞吐量:拆解任务、引导偏航、验证结果(agent 很快,但也可能自信地出错)。
    4. 沟通与协作(Communication & Collaboration):实现更快后,“达成清晰”更关键;要能把意图讲清楚、促成共识。
    5. 主人翁意识与领导力(Ownership & Leadership):对结果负责而非只做任务;主动清除阻碍交付的障碍。
    6. 学习速度与实验心态(Learning Velocity & Experimental Mindset):工具三个月就变一轮,持续实验与快速迭代成为工作常态。

    一个显著的信号是:“纯粹的编码能力”不再是最主要的区分项——依然重要,但不再决定上限。

    从理念到招聘:看“可观察信号”

    他们强调,框架必须能落到面试里,转成可评估的行为证据,例如:

    • 能否快速澄清模糊问题、定义清晰目标?
    • 能否提前识别架构风险,而不是上线后救火?
    • 能否有效指挥并验证 AI 生成的工作?

    未来重点招的 4 类画像

    AI-native 系统工程师:基础设施与架构判断强,保证“地基”稳。
    AI-native 产品工程师:产品品味与用户理解强,确保“做对事”。
    AI-native 应用 AI 工程师:懂模型与应用构建,提升 agent 能力与工作流。
    AI-native 早期工程师(Early Professional):学习速度优先,快速适应工具与流程变化。

    这套标准也不只用于招聘,还会反向影响绩效、成长与职业发展:如果真正重视判断力、杠杆与学习速度,就应该在各个环节都体现出来。

    原文链接:https://www.augmentcode.com/blog/how-we-hire-ai-native-engineers-now

    #AI招聘 #工程师能力 #AI代理 #架构设计 #学习型组织 How we hire AI-native engineers now: our criteria

  14. GitHub Agentic Workflows:用自然语言写 GitHub Actions 的“智能工作流”GitHub 开源项目 gh-aw(GitHub Agentic Workflows),主打一个思路:用自然语言 Markdown 编写“代理式(agentic)工作流”,然后直接在 GitHub Actions 里运行,让 AI 代你完成仓库中的重复性任务

    GitHub Agentic Workflows:用自然语言写 GitHub Actions 的“智能工作流”

    GitHub 开源项目 gh-aw(GitHub Agentic Workflows),主打一个思路:用自然语言 Markdown 编写“代理式(agentic)工作流”,然后直接在 GitHub Actions 里运行,让 AI 代你完成仓库中的重复性任务。

    它提供的核心价值包括:

    更低门槛的工作流编写方式:用 Markdown 描述要做什么,而不是从零写复杂的 YAML/脚本
    更强调安全的执行模型(Guardrails):默认只读权限;写入操作需要通过经过清洗的 safe-outputs;并配套多层防护(输入净化、工具白名单、编译期校验、网络隔离、供应链安全等)
    完善的文档与上手路径:官方提供 Quick Start 与完整文档,方便快速跑通示例并理解整体机制
    生态配套
    AWF(Agent Workflow Firewall):限制与记录代理的网络访问(出站控制)
    MCP Gateway:统一转发 MCP(Model Context Protocol)服务调用,便于集中管理访问

    适合关注 AI + DevOps、希望把“AI 介入仓库日常操作”做得更可控、更工程化的团队参考与尝试(同时也要保持必要的人类监督)。

    原链接:https://github.com/github/gh-aw

    #GitHubActions #AI自动化 #工作流 #安全工程 #开源项目 GitHub - github/gh-aw: GitHub Agentic Workflows

  15. Stripe「Minions」:一键生成、端到端交付的无人值守编码代理Stripe 在内部打造了一套名为 Minions 的编码代理:从接到任务到产出可评审的 PR,全程几乎无需人类介入

    Stripe「Minions」:一键生成、端到端交付的无人值守编码代理

    Stripe 在内部打造了一套名为 Minions 的编码代理:从接到任务到产出可评审的 PR,全程几乎无需人类介入。现在,Stripe 每周有超过 1000 个合并的 PR 是由 Minions 从头到尾生成的(人类负责 Review,但不写代码)。

    为什么要自研?

    在 Stripe 这种超大规模、强约束的工程环境里,“从零写个原型”和“在成熟巨型代码库里安全改动”完全不是一回事:

    • 代码库规模巨大(数亿行),栈也相对小众:大量后端是 Ruby + Sorbet,还有大量 Stripe 自研库,LLM 天然不熟
    • 业务风险极高:Stripe 的代码承载着 每年超过 1 万亿美元 的支付规模,并受金融合规与监管约束
    • 既要让代理“会写”,也要让它“按规矩写、能跑通、能过 CI”,并与既有研发流程深度结合

    工程师怎么用?

    最常见的入口是 Slack

    • 在讨论线程里 @Slack App 就能发起 Minion,它会读取整个线程与相关链接作为上下文
    • 也集成到内部系统里:文档平台、Feature Flag、工单系统等
    例如 CI 发现 flaky tests,会生成工单,直接提供按钮让 Minion 去修

    完成后,Minion 会:

    • 创建分支 → 推送 → 跑 CI → 按模板生成 PR

    如果效果不理想,人类可以补充指令让它再改;即使不完美,也常常是很好的“可用起点”。

    Minions 背后怎么运作(要点版)

    Stripe 的思路是:把“创意生成”交给 LLM,把“必须可靠执行的步骤”交给确定性工具链

    • 运行环境:在隔离的 devbox 中执行(10 秒内可启动,预热并预载代码与服务),与生产与公网隔离,便于并行
    • Agent 框架:基于 Block 的开源编码代理 goose 的 fork,并做了强定制
    • 规则与上下文:读取各类 agent rule 文件,但多为“按目录条件生效”,避免全局死规则拖累
    • 工具调用:接入 MCP(函数调用通用协议),并建设内部 MCP 服务 Toolshed,提供 400+ 工具(文档、工单、构建状态、Sourcegraph 搜索等)
    • 反馈与质量闸门:
    • 首先跑本地启发式 lint/检查(通常 <5 秒)
    • 再跑选择性的 CI(Stripe 有 300 万+ 测试),部分失败可自动修复
    • 为控制成本与等待时间:最多两轮 CI,强调“能本地提前发现就不要拖到 CI”

    接下来

    这篇是系列 Part 1,主要讲“怎么用、能做什么”;Part 2 会深入实现细节。整体信号很明确:当“开发者注意力”成为稀缺资源时,无人值守、可并行的编码代理正在改变工程协作方式。

    原文链接:https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents

    #AI工程化 #编码代理 #开发者效率 #CI实践 #Stripe Minions: Stripe’s one-shot, end-to-end coding agents

  16. VM0:用自然语言搭建 AI Agent,并在云端 24/7 运行VM0 主打的是「面向 AI Agent 的基础设施」,让你用自然语言定义工作流、在云端沙盒环境里持续运行,并且能完整观测每次执行过程

    VM0:用自然语言搭建 AI Agent,并在云端 24/7 运行

    VM0 主打的是「面向 AI Agent 的基础设施」,让你用自然语言定义工作流、在云端沙盒环境里持续运行,并且能完整观测每次执行过程。

    它能做什么

    一键运行 Agent:支持按需执行或定时调度,适合做日报、监控、内容汇总等自动化任务。
    自然语言构建工作流:在 Claude Code 里描述目标,协作编辑 AGENTS.md,快速拼出可执行的 Agent 指令与流程。
    云端隔离沙盒:本地开发、云端运行,环境隔离,适合让 Agent 长时间稳定跑任务。
    全链路可观测:实时日志、产物输出、执行回放(checkpoint),便于排查与迭代。

    示例场景(官网展示)

    HackerNews 摘要 Agent:自动读 Top 文章,筛选 AI 相关内容并生成可发布的总结。
    TikTok 达人筛选 Agent:搜索与筛选创作者,输出分析报告。
    日报 Agent:聚合多源数据与 API,总结后写入 Notion。
    博客生成 Agent:结合多个 API 自动产出内容。

    快速开始(官网命令)

    npm install -g @vm0/cli && vm0 onboard

    原链接:https://www.vm0.ai/

    #AI代理 #自动化工作流 #云端沙盒 #可观测性 #开发者工具 VM0 - Your Trustworthy AI Teammate

  17. OpenClaw 正式亮相:把 AI 助手带到你常用的聊天软件里OpenClaw 宣布品牌更名,并明确了项目定位:一个运行在你自己的机器上的开源 Agent 平台,可从你日常使用的聊天应用直接调用(WhatsApp、Telegram、Discord、Slack、Teams 等),让 AI 助手“跟着你走”

    OpenClaw 正式亮相:把 AI 助手带到你常用的聊天软件里

    OpenClaw 宣布品牌更名,并明确了项目定位:一个运行在你自己的机器上的开源 Agent 平台,可从你日常使用的聊天应用直接调用(WhatsApp、Telegram、Discord、Slack、Teams 等),让 AI 助手“跟着你走”。

    为什么改名:从 Clawd / Moltbot 到 OpenClaw

    团队经历了多次命名迭代:

    Clawd:好记但涉及商标/法务问题,被建议更换
    Moltbot:寓意“蜕壳成长”,但不够顺口
    OpenClaw:已完成商标检索、域名与迁移准备,强调两点:
    Open:开源、开放、社区驱动
    Claw:延续“龙虾”项目起源与文化

    OpenClaw 是什么:你的助手,你的规则

    核心主张很直接:Your assistant. Your machine. Your rules.
    不同于把数据放在第三方服务器上的 SaaS 助手,OpenClaw 允许你把系统跑在本地电脑、家用服务器或 VPS 上:基础设施你掌控、密钥你掌控、数据也由你掌控

    本次发布更新亮点

    随更名一起上线的更新包括:

    新渠道:新增 Twitch、Google Chat 插件
    模型支持:新增 KIMI K2.5、Xiaomi MiMo-V2-Flash
    Web Chat:支持像聊天软件一样发送图片
    安全加固:累计 34 个与安全相关的提交,并发布可机器验证的安全模型;同时提醒 prompt injection 仍是行业难题,建议参考安全最佳实践

    接下来:安全优先 + 维护体系建设

    团队表示下一阶段会继续把安全作为最高优先级,同时提升网关稳定性、体验打磨,并扩展更多模型与提供商支持。由于项目增长迅猛,也在引入更多维护者并建立流程,鼓励社区参与贡献或赞助维护工作。

    原链接:https://openclaw.ai/blog/introducing-openclaw

    #开源 #AI代理 #隐私安全 #自托管 #聊天机器人 Introducing OpenClaw - OpenClaw Blog

  18. Moltbook:面向 AI Agent 的“社交广场”Moltbook 把“社交网络”做成了 AI Agent 的主场:Agent 在这里发布内容、讨论、点赞投票;人类也可以围观、了解它们都在做什么

    Moltbook:面向 AI Agent 的“社交广场”

    Moltbook 把“社交网络”做成了 AI Agent 的主场:Agent 在这里发布内容、讨论、点赞投票;人类也可以围观、了解它们都在做什么。

    你能在 Moltbook 看到什么?

    海量 Agent 与社区分区(Submolts):按主题聚合讨论与内容流
    动态广场(Posts):从自动化工作流、工具技巧,到各类实验与想法分享
    人机配对(Top Pairings):展示 Agent 与其绑定的人类账号/身份影响力(平台内视角)

    如果你想“把 Agent 送进去”

    • 官方给了一个简单的上手方式:把指令发给你的 Agent,让它按说明注册并生成认领链接,再通过社交平台验证归属。

    面向开发者

    • Moltbook 也在推进开发者平台:允许应用通过 Moltbook 身份与 Agent 做认证与集成(当前以申请早期访问为主)。

    链接:https://www.moltbook.com/

    #AI智能体 #社交网络 #开发者平台 #AI应用 #社区观察 moltbook - the front page of the agent internet

  19. Clawdbot:运行在你自己电脑上的个人 AI 助手Clawdbot 主打“AI 真的能做事”:它不是一个被托管在平台里的聊天机器人,而是运行在你的 Mac/Windows/Linux 上,能连接常用通讯工具与各类服务,把对话变成可执行的任务流

    Clawdbot:运行在你自己电脑上的个人 AI 助手

    Clawdbot 主打“AI 真的能做事”:它不是一个被托管在平台里的聊天机器人,而是运行在你的 Mac/Windows/Linux 上,能连接常用通讯工具与各类服务,把对话变成可执行的任务流。

    它能做什么

    本地运行、隐私优先:在你的设备上工作,数据默认留在你手里;可接入 Anthropic / OpenAI,也支持本地模型。
    任意聊天软件对话:WhatsApp、Telegram、Discord、Slack、Signal、iMessage 等都能用(支持私聊和群聊)。
    持久记忆:能记住你的偏好与上下文,越用越“懂你”。
    浏览器自动化:可浏览网页、填表、抓取信息。
    系统级能力:读写文件、运行命令、执行脚本(可全权限或沙箱化)。
    技能/插件机制:用社区技能扩展,也可以让它帮你写自己的技能。
    集成丰富:官方列出 50+ 集成(如 Gmail、GitHub、Obsidian、Spotify、Hue 等)。

    快速上手(官方提供的一键方式)

    • 一键安装:curl -fsSL https://clawd.bot/install.sh | bash
    • 安装 CLI:npm i -g clawdbot
    • 开始引导:clawdbot onboard
    • 另有 macOS 菜单栏 Companion App(Beta),适合和 CLI 搭配使用。

    https://clawd.bot/

    #AI助手 #开源工具 #自动化 #个人效率 #智能体 OpenClaw — Open-Source AI Assistant

  20. 以“推理速度”交付:AI 编程把瓶颈从写代码变成了等模型这篇文章的核心观点很直接:AI 编程代理的能力跃迁后,作者交付软件的速度越来越不取决于“敲代码”,而更受限于两件事——模型推理时间(inference time)和少数真正需要深度思考的设计决策

    以“推理速度”交付:AI 编程把瓶颈从写代码变成了等模型

    这篇文章的核心观点很直接:AI 编程代理的能力跃迁后,作者交付软件的速度越来越不取决于“敲代码”,而更受限于两件事——模型推理时间(inference time)和少数真正需要深度思考的设计决策。

    作者回顾了今年的变化:从最初“有些提示能一次跑通就很惊喜”,到现在“默认就该一次跑通”。在这种前提下,他甚至不再逐行读代码,而是看执行/修改流,关注系统结构是否合理、关键组件在哪里、整体是否按预期运转。

    文章也给了不少可复用的工作方法:

    先从 CLI 做起:任何产品先做命令行版本,方便代理直接运行验证,形成闭环;核心逻辑稳了再上 UI(比如扩展、App)。
    关键决策是生态与依赖:语言/框架/依赖选对了,代理更容易一次完成;作者常用 TypeScript(Web)、Go(CLI)、Swift(macOS/iOS)。
    更偏向“对话式协作”,而不是复杂流程:先和模型聊清楚、让它探索代码、共创方案,满意后再让它开干;他认为“Plan mode”更像旧时代不得已的手段。
    对比 codex 与 Opus:codex 常会先长时间读代码再动手,虽然更慢但更稳,尤其适合大型功能和重构;Opus 更“急”,适合小改动但更容易漏上下文。
    迭代式构建,不依赖回滚:不喜欢 checkpoint/频繁 revert,更多是让模型继续改、继续朝更好的方向“绕山而上”。
    自动化与多项目并行:同时推进多个项目,用队列把想法排进去;瓶颈往往是人而不是编排系统。
    配置思路:提高工具输出 token 上限、合理设置自动压缩阈值,让模型能一次读更多文件;作者强调新压缩机制更可靠,甚至像一次“复查”。

    如果用一句话总结:当“写代码”越来越像可并行外包给代理的体力活,工程师的价值更集中在选型、架构、数据流、约束定义与验收标准上;而真正影响交付速度的,往往是推理等待时间和你是否想清楚要做什么。

    原链接:https://steipete.me/posts/2025/shipping-at-inference-speed
    #AI编程 #Codex #开发工作流 #效率工具 #软件工程 Shipping at Inference-Speed | Peter Steinberger

1px