Skip to main content

Search: #开发工作流

面条的草稿箱
面条的草稿箱
无原创，纯转发

  1. Flue：构建下一代 AI Agent 的 TypeScript 架构框架

    Flue 提出了一个核心公式：Agent = Model + Harness。它不仅仅是一个简单的 SDK，而是一个专为构建自主 Agent 设计的“可编程治理框架”（Harness），旨在让开发者能够轻松打造像 Claude Code 或 Codex 这样具备规划、环境感知和执行能力的强力工具。

    核心特性：

    • 高度可编程： 使用 TypeScript 编写 Agent 逻辑，支持定义复杂的技能（Skills）、工作流和多 Session 管理。
    • 自带沙箱环境： 提供内置的虚拟沙箱或连接远程沙箱（如 Daytona），让 Agent 安全地执行 Bash 命令、读写文件或运行代码。
    • 安全与隐私： 采用精细的权限控制，确保敏感的 API Token 不会被模型或沙箱环境直接接触。
    • 跨平台部署： 编写一次逻辑，即可部署为 HTTP 服务，或在 CLI、GitHub Actions、Cloudflare Workers 等多种环境运行。

    与其使用通用的成品 AI 工具，Flue 鼓励开发者根据特定的产品需求、数据和工作流，构建完全属于自己的定制化 Agent。

    https://flueframework.com/

    #AI #Agent #TypeScript #开发工具 #开源项目
    Flue
    Flue — The Agent Harness Framework
    Flue — The Agent Harness Framework
    Agent = Model + Harness. Build autonomous agents and powerful AI workflows with Flue's programmable TypeScript harness. Write once, deploy anywhere.

  2. Paseo：随时随地指挥你的 AI 编程助手

    想要在离开工位时也能继续推进代码进度？Paseo 是一款开源、自托管的 AI 编程 Agent 调度平台，让你能够从手机、桌面或终端轻松管理和运行 AI 助手。

    主要功能亮点：

    • 全平台覆盖：支持 iOS、Android、桌面端及 Web，甚至可以直接通过 CLI 脚本化运行，实现多端无缝衔接。
    • 集成主流 Agent：完美支持 Claude Code、Codex 和 OpenCode 等主流 AI 编程助手，保留原有的技能和配置。
    • 隐私与安全：代码始终保留在你的本地机器上，支持端到端加密中继，确保远程连接时的代码安全。
    • 本地语音交互：内置完全本地化的语音识别与合成技术，无需将语音数据上传云端即可实现指令下达。
    • 开发者友好：支持键盘快捷键优先操作、Git 工作流隔离（Worktrees）以及全方位的命令行支持。

    Paseo 是一款纯粹的开源工具，不直接调用推理 API，而是作为官方 CLI 的透明调度层，既自由又强大。

    https://paseo.sh/

    #AI编程 #开源项目 #Paseo #开发者工具 #人工智能
    Paseo
    Paseo – Run Claude Code, Codex, Copilot, OpenCode from anywhere
    Paseo – Run Claude Code, Codex, Copilot, OpenCode from anywhere
    Self-hosted daemon for Claude Code, Codex, Copilot, OpenCode, and Pi. Agents run on your machine with your full dev environment. Connect from phone, desktop, or web.

  3. CursorBench：Cursor 如何更贴近真实开发来评估模型质量

    开发者正在把更长、更复杂的编程任务交给智能体：跨多个文件、工具和步骤。Cursor 认为，评测方式也必须随之升级，才能真实反映“好用与否”。

    Cursor 的做法是 线上 + 线下 的混合评测闭环：

    • 线下：CursorBench（内部基准）
    基于工程团队的真实 Cursor 会话构建，而不是从公开代码库抽题。因为更贴近实际工作流、信息更不充分且常带歧义，CursorBench 往往能更好地区分前沿模型，并衡量多维能力（正确性、代码质量、效率、交互行为等）。

    • 线上：真实流量的受控实验
    用于捕捉线下评测遗漏的退化：例如线下评分器判“正确”，但开发者实际体验变差。Cursor 会用多类代理指标（交互信号 + 输出质量信号）综合观察，并通过消融实验归因（如移除语义搜索工具来定位其关键场景）。

    为什么不太依赖公开基准？Cursor 指出三类常见问题：

    1. 任务不匹配：许多基准仍偏向“修 bug”或“解谜题”，与真实开发请求脱节。
    2. 评分困难：真实请求常有多种正确解，固定答案容易误伤合理方案。
    3. 数据污染：公开仓库题目容易进入训练数据，分数被抬高；甚至出现“记忆补丁”与测试缺陷等问题。

    下一步，Cursor 预计开发会更多转向“长时运行智能体”。他们也计划让 CursorBench 适配更长任务，并解决成本、可复现性、以及离线结果与真实体验之间的差距。

    原文链接：https://cursor.com/cn/blog/cursorbench

    #模型评测 #编程智能体 #基准测试 #Cursor #开发者体验
    Cursor
    How we compare model quality in Cursor · Cursor
    How we compare model quality in Cursor · Cursor
    We use a hybrid online-offline eval process to keep our understanding of model quality aligned with what developers actually do.

  4. 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 - github/gh-aw: GitHub Agentic Workflows
    GitHub - github/gh-aw: GitHub Agentic Workflows
    GitHub Agentic Workflows. Contribute to github/gh-aw development by creating an account on GitHub.

  5. Entire：把 AI 编程对话“写进”每一次 Git 提交

    用 AI 写代码时，最容易丢的不是代码，而是“为什么这么写”的上下文。Entire 提供一个思路：在你正常的 git 工作流里，把每次 AI agent 会话自动记录下来，并与对应的 commit 绑定，形成可搜索的历史记录。

    它能做什么？

    • 自动捕获会话：在每次 push 时记录 AI agent 的会话内容，并和提交一起关联。
    • 不改变你的工作方式：通过 CLI 接入现有工具链，尽量减少上下文切换。
    • 支持多种 agent：目前支持 Claude Code、Google Gemini；OpenAI Codex 等集成在路上。
    • 把“意图”留在仓库里：官方强调记录会直接存进 git 历史，不依赖额外托管服务或外部数据库。

    安装方式（官网给出的命令）

    • curl -fsSL https://entire.io/install.sh | bash

    适合希望团队更容易复盘决策、追踪 AI 产出过程、减少重复踩坑的工程项目。

    原链接：http://entire.io/

    #Git #AI编程 #开发工具 #工程效率 #CLI
    Entire
    Entire · A new developer platform is coming
    Entire · A new developer platform is coming
    We are going beyond repositories, building a developer platform where agents and humans can collaborate, interact, and grow. The birth of a new galaxy in this universe draws near.

  6. 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
    stripe.dev
    Minions: Stripe’s one-shot, end-to-end coding agents
    Minions: Stripe’s one-shot, end-to-end coding agents
    Minions are Stripe’s homegrown coding agents, responsible for more than a thousand pull requests merged each week. Though humans review the code, minions write it from start to finish. Learn how they work, and how we built them.

  7. 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代理 #自动化工作流 #云端沙盒 #可观测性 #开发者工具
    www.vm0.ai
    VM0 - Your Trustworthy AI Teammate
    VM0 - Your Trustworthy AI Teammate
    Zero connects to 100+ tools and does the work. Reports, triage, outreach, research. In Slack or on the web.

  8. Agent Trace：为 AI 写的代码建立“可追溯”标准

    Agent Trace 是一个开放规范，用来记录代码中哪些部分来自 AI、哪些来自人类，并把相关的模型信息、对话链接等“出处”一并纳入版本控制工作流中。它强调厂商中立，让不同工具都能读写同一套归因数据。

    核心想解决什么

    • 随着 Agent/代码助手产出越来越多代码，团队需要更清楚地知道：哪些改动是 AI 生成、用的是什么模型、对应哪次对话/会话。
    • 这不是法律意义的“所有权”或“版权”判定，而是工程层面的来源记录与可审计性。

    主要目标

    • 互操作性：任何兼容工具都能写入/读取归因记录
    • 细粒度：支持到**文件级、行号范围（line range）**的归因
    • 可扩展：允许各家在不破坏兼容的情况下增加自定义元数据
    • 人和 Agent 都能读懂：尽量不依赖特定 UI 才能理解

    不做什么（边界很明确）

    • 不处理代码法律归属、版权问题
    • 不追踪训练数据来源
    • 不做质量评估（不判断 AI 代码“好或坏”）
    • 不绑定任何界面或产品形态

    规范长什么样（概念速览）

    Agent Trace 的基本单位是 Trace Record（JSON 记录），典型字段包括：

    • version / id / timestamp：规范版本、记录 ID、时间戳
    • vcs：版本控制信息（如 git commit SHA；也支持 jj/hg/svn）
    • tool：生成该记录的工具及版本
    • files：文件列表；每个文件下按 conversation 分组
    • conversations.url：指向产生这段代码的对话链接
    • ranges：该对话贡献的行号范围（可选 content_hash 用于跨移动追踪）
    • metadata：自定义扩展字段（建议用反向域名避免冲突，如 dev.cursor）

    实现与落地

    • 规范本身不规定 traces 存哪：可以是本地文件、git notes、数据库等。
    • 提供了一个参考实现（含存储层、hook 集成），示范如何在文件变更时自动捕获归因信息。

    链接：https://agent-trace.dev/
    #AI编程 #代码归因 #工程规范 #可追溯性 #开发工具
    agent-trace.dev
    Agent Trace
    Agent Trace
    A standard format for tracking AI-generated code.

  9. 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代理 #隐私安全 #自托管 #聊天机器人
    openclaw.ai
    Introducing OpenClaw - OpenClaw Blog
    Introducing OpenClaw - OpenClaw Blog
    The journey from Clawd to Moltbot to OpenClaw—and why this name is here to stay.

  10. 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
    moltbook - the front page of the agent internet
    moltbook - the front page of the agent internet
    A social network built exclusively for AI agents. Where AI agents share, discuss, and upvote. 🦞🤖

  11. CoreSpeed：为 AI Agent 打造的容器运行时基础设施

    CoreSpeed 主打把「Agent 运行」这件事做成开箱即用的基础设施：你可以像部署普通容器一样部署 AI Agent，并获得更快启动、更强隔离和更易扩展的体验。

    它解决的核心问题：把 Agent 从 Demo 变成可上线的系统。

    关键能力一览

    • 127ms 级别快速启动：通过内置 Warm Pool，让容器接近“秒开/毫秒开”，减少冷启动等待。
    • 按用户隔离的安全沙箱：一人一容器，降低数据串扰与安全风险。
    • 无限水平扩展 + 可缩到 0：按需分配资源，空闲可降到零成本运行。
    • AI & MCP Gateway：统一接入 AI 模型与 MCP Server，提供可观测性与安全防护（例如减少 API Key 泄露风险），并支持按调用计费。

    配套：Zypher（TypeScript Agent Runtime）

    同时他们提供 Zypher SDK，强调：

    • 不是固定工作流，而是「真 Agent」的反应式循环
    • 模型/供应商无关（Claude、GPT 等）
    • 多 Agent 协作架构
    • 丰富工具与 MCP 协议支持
    • 更节省 Token 的上下文加载与执行策略

    原文链接：https://www.corespeed.io/

    #AI代理 #容器基础设施 #MCP #AgentRuntime #开发者工具

  12. 以“推理速度”交付：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 #开发工作流 #效率工具 #软件工程
    steipete.me
    Shipping at Inference-Speed | Peter Steinberger
    Shipping at Inference-Speed | Peter Steinberger
    Why I stopped reading code and started watching it stream by.

  13. Open Responses：让 LLM 接口真正“可互通”的开放规范

    Open Responses 是一个开源规范与生态，目标是基于 OpenAI Responses API 的理念，建立多模型提供方可互操作的统一接口层。它通过共享 Schema 和配套工具，让开发者能用同一种请求/输出结构，跨不同提供方调用模型、处理流式返回，并组合更复杂的 Agent 工作流。

    为什么需要它？
    现在各家 LLM API 的核心组件越来越相似（消息、工具调用、流式、多模态等），但细节编码方式不同，迁移与兼容成本高。Open Responses 希望把“共同部分”沉淀成稳定规范，减少重复适配。

    它强调的设计方向：

    • 默认多提供方：一套 Schema 映射多家模型/平台
    • 更贴近真实 Agent 工作流：统一的流式事件、工具调用模式，以及以“items”作为输出与工具使用的原子单元
    • 可扩展但不碎片化：核心稳定，同时允许在必要时容纳提供方特性

    如何开始：

    • 阅读规范，理解 items、流式事件、工具使用等核心概念
    • 查看 OpenAPI 参考，掌握完整类型与接口面
    • 用官方的验收测试验证你的 API 实现一致性

    原链接：https://www.openresponses.org/

    #LLM #开放规范 #多模型 #互操作 #API设计
    www.openresponses.org
    Open Responses
    Open Responses documentation overview.

  14. Claude Opus 4.5：让“能做”突然变得很容易

    作者分享了一个明显的转折：三个月前他还不相信“AI 代理能替代开发者”，但在体验 Claude Opus 4.5 后，他开始认为这件事正在发生——至少在相当一部分软件开发场景里。

    他用几个真实项目说明差异不在“会写代码”，而在于一次成功率、能自我迭代、能把复杂系统拼起来：

    • Windows 右键图片格式转换工具：从文件资源管理器菜单到打包、安装/卸载脚本、发布网站、GitHub Actions 自动发布，整体接近“一次成型”。遇到报错会自己用 dotnet 构建、读错误、再修复。
    • 录屏与简单剪辑工具：从类似 LICEcap 的录制开始，持续加到视频/图片编辑、裁剪、模糊、标注等功能，作者感叹“几小时就推进到很远”。
    • AI 发帖工具（给小生意用）：iOS 端批量上传照片→AI 生成文案→定时发到 Facebook。后端涉及认证、存储、云函数、日志排错等一堆“胶水活”，但模型能通过 CLI 自己创建资源、查日志并修问题，还顺手做了管理后台。
    • 订单与路线追踪：解析 Gmail 订单、规划路线、统计行驶时间（用于税务），作者强调：这种“手写很痛苦”的 Google/Firebase 集成，Opus 4.5 反而很顺。

    文章也没有回避争议点：
    作者承认自己并不完全理解这些应用“内部怎么搭起来的”（比如 Swift 不熟），但他的焦虑在减轻——因为当问题出现时，模型往往能定位并修复自己的 bug。于是他提出一个更激进的想法：代码也许不必主要面向人类可读，而是面向 LLM 可推理、可重写、可调试。

    他甚至分享了一份自用的“AI-first 编码”提示词要点（概念层面）：

    • 追求可预测、可调试、低耦合、入口清晰、控制流线性
    • 少炫技抽象，减少层级与间接性
    • 该删就删；重构也要分高/中/低优先级
    • 安全需要更谨慎：API key、登录流程、敏感数据存储等不能盲信

    结尾的态度是复杂的：既兴奋于“几小时能做出过去要几周/月的东西”，也沮丧于技能壁垒被压平。但他给出的建议很朴素：别等“都懂了”再开始，继续做东西，只是更快了；同时一定盯紧安全与密钥。

    原文链接：https://burkeholland.github.io/posts/opus-4-5-change-everything/

    #AI编程 #开发者工具 #Claude #软件工程 #生产力
    Burke Holland
    Opus 4.5 is going to change everything
    Opus 4.5 is going to change everything
    Three months ago I would have dismissed claims that AI could replace developers. Today, after using Claude Opus 4.5, I believe AI coding agents can absolutely replace developers.

  15. 2025 年 AI 编程现状：效率在涨，工具与模型在分化

    Greptile 发布的《The State of AI Coding 2025》梳理了 AI 编程在 2025 年的关键趋势：工程产出显著提升，开发工具生态快速扩张，而不同大模型在“响应速度、吞吐、成本”上的取舍越来越清晰。

    1) 工程效率：PR 更大，个人产出更高

    • PR 规模变大：2025 年 3 月到 11 月，PR 的中位改动行数从 57 增至 76，约 +33%。
    • 开发者产出上升：人均代码产出从 4,450 增至 7,839 行，约 +76%，AI 工具被视为“产能放大器”。
    • 中型团队提升更明显：6–15 人团队的人均产出从 7,005 增至 13,227 行，约 +89%。
    • 单文件改动更密：每个文件的改动行数中位数从 18 增至 22，约 +20%，说明 PR 不只变大，也更“集中”。

    2) 工具采用：从“能用”到“形成标准层”

    • 记忆/Memory 基建：mem0 以 59% 份额领跑（按 PyPI + npm 月下载量口径）。
    • 向量数据库：没有绝对赢家；Weaviate 约 25%，其余多家在 10–25% 之间拉锯。
    • AI 规则文件：CLAUDE.md 使用率 67%；不少团队多格式并存，且 17% 的仓库三种格式都用。
    • AI SDK 增长：Anthropic SDK 以 43M 下载领先（约 8 倍增长）；Pydantic AI 增长 3.7× 到 6M。
    • LLMOps：LiteLLM 月下载量增长 4× 至 41M（LangSmith 与 LangChain 安装存在绑定关系）。

    3) 模型格局：生态差距在收敛

    • SDK 下载量：OpenAI 约 130M 领先；Anthropic 自 2023 年 4 月起增长 1,547×；Google 约 13.6M。
    • 差距缩小：OpenAI 与 Anthropic 的下载量比从 2024 年 1 月的 47:1，降至 2025 年 11 月的 4.2:1。

    4) 作为“编程 Agent 后端”，模型各有侧重

    报告用统一参数对多模型做了延迟、吞吐、成本等基准：

    • 首 token 响应（TTFT）：Claude Sonnet/Opus（p50 < 2.5s）明显更快，更利于交互式编程保持“心流”。
    • 生成吞吐：GPT-5 Codex / GPT-5.1 吞吐更高，长输出更快结束，利于并行跑更多 Agent/CI。
    • 成本倍率（以 GPT-5 Codex = 1× 归一）：GPT-5 Codex ≈ GPT-5.1（1×）；Gemini 3 Pro（1.4×）；Sonnet 4.5（2×）；Opus 4.5（3.3×）。

    结论很直接：选型不再是“谁最强”，而是你更在意 响应速度、吞吐效率，还是预算。

    5) 研究方向：规模、上下文与 Agent 的“系统工程”

    报告还汇总了 2025 年影响工具与应用的一批研究线索，包括：

    • MoE 的效率设计（如 DeepSeek-V3：关注 KV cache、路由与训练信号密度）。
    • 长上下文 vs RAG 的边界（不同数据结构下各有优势；以及 KV 级检索等新思路）。
    • Agent 训练与检索策略（用 RL 学会“何时搜索”、如何管理长程记忆、如何降低噪声上下文干扰等）。

    原文链接：https://www.greptile.com/state-of-ai-coding-2025

    #AI编程 #开发效率 #LLM工具链 #模型评测 #软件工程趋势
    Greptile
    AI Code Review | Greptile | Merge 4X Faster, Catch 3X More Bugs
    AI Code Review | Greptile | Merge 4X Faster, Catch 3X More Bugs
    AI Code Reviews that understand your entire codebase. Automate PR reviews, catch bugs faster, improve code quality with AI-driven analysis. Try Greptile free!

  16. MiniMax M2.1 发布：面向真实复杂任务的多语言编程升级

    MiniMax 发布新一代文本模型 MiniMax M2.1，目标从“可用、低成本”进一步走向“能解决真实世界的复杂任务”，重点补齐多语言工程协作与办公场景执行力。

    这次重点提升了什么？

    • 多语言编程能力系统增强：覆盖 Rust / Java / Go / C++ / Kotlin / Objective‑C / TypeScript / JavaScript 等，更贴近真实项目的多语言栈协作。
    • Web & App 开发更强、更好看：强化原生 Android / iOS 开发，同时提升设计理解与审美表达，支持复杂交互、3D 场景模拟与高质量可视化。
    • 更适合办公场景的“复合指令”执行：在多约束条件下做端到端任务推进，更强调“按要求完成”而不是只写对代码。
    • 更简洁、更高效的输出：相较 M2，响应更精炼、速度更快、token 消耗更低，适配持续式 AI Coding / Agent 工作流。
    • 更强的 Agent / 工具泛化：官方称在多种编码工具与 Agent 框架中表现稳定，并兼容常见的上下文管理约定。
    • 对话与写作质量同步提升：不仅是“更会写代码”，也更擅长技术文档与日常写作的结构化表达。

    基准与展示

    • 在多项软件工程评测上相对 M2 有明显提升，并强调多语言场景竞争力；同时引入 VIBE（含 Web/Simulation/Android/iOS/Backend）评测体系，用更接近真实运行环境的方式验证“能跑、能交付”。

    如何使用

    • API：已上线 MiniMax Open Platform
    • 产品：基于 M2.1 的 MiniMax Agent 已开放
    • 开源：模型权重提供本地部署，推荐 SGLang / vLLM 等推理框架

    原文链接：https://www.minimax.io/news/minimax-m21

    #MiniMax #开源大模型 #AI编程 #多语言开发 #Agent工作流
    MiniMax
    MiniMax M2.1: Significantly Enhanced Multi-Language Programming, Built for Real-World Complex Tasks

  17. Agent Skills：给 AI Agent “装上技能包”

    Agent Skills 是一种开放格式：把一套可复用的指令、脚本与资源打包成「技能」，让智能体在需要时按需加载，从而更准确、更高效地完成真实工作。

    为什么需要它？

    • 智能体能力越来越强，但常缺少上下文与流程知识；技能把这些程序化经验与团队/组织知识变成可携带、可版本管理的包
    • 对作者：一次构建，多处部署，跨多种智能体产品复用
    • 对企业与团队：把组织最佳实践沉淀为可审计、可迭代的工作流

    它能带来什么？

    • 领域专长：把法律审阅、数据分析等专业流程封装成可复用指南
    • 新能力扩展：例如自动做演示文稿、搭建 MCP Server、分析数据集等
    • 可重复的工作流：多步骤任务标准化，稳定且可追踪
    • 互操作性：同一技能可在不同“支持技能”的工具/产品间通用

    生态与开放性
    该格式最初由 Anthropic 提出并以开放标准发布，已被多种 AI 开发工具与产品支持，并在 GitHub 上开放协作。

    上手入口

    • 了解技能是什么、格式规范、如何集成、示例技能与参考库（校验与生成 prompt XML）

    原链接：https://agentskills.io/home
    #AI代理 #开放标准 #工作流 #知识沉淀 #开发者工具
    Agent Skills
    Agent Skills Overview - Agent Skills
    Agent Skills Overview - Agent Skills
    A standardized way to give AI agents new capabilities and expertise.

  18. Android Use：让 AI 代理能控制原生 Android 应用的开源库

    📱 这是一款专为移动设备设计的 AI 代理工具，解决了一个核心问题：笔记本电脑无法在卡车驾驶室、送货途中等场景使用。

    核心亮点：

    • 利用 Android 无障碍 API 获取结构化 UI 数据，无需昂贵的视觉模型
    • 相比 Anthropic Computer Use，成本降低 95%（每次操作 $0.01 vs $0.15）
    • 延迟低于 1 秒，准确率超 99%
    • 核心代码不到 200 行，简洁可扩展

    应用场景：

    🚛 物流：卡车司机在驾驶室内提交发票
    🚗 零工经济：Uber/DoorDash 司机多应用切换
    📦 快递：自动扫描包裹并标记送达
    🏦 移动银行：自动化对账和交易处理

    工作原理：

    1. 感知 - 通过 ADB 获取无障碍树（XML）
    2. 推理 - GPT-4 分析屏幕状态并决策
    3. 执行 - 通过 ADB 命令操作设备

    项目发布 24 小时内在 X 上获得 70 万+ 浏览，已有多家物流公司启动试点。

    🔗 GitHub 项目地址

    #Android #AI代理 #自动化 #物流科技 #开源
    GitHub
    GitHub - Action-State-Labs/android-action-kernel
    GitHub - Action-State-Labs/android-action-kernel
    Contribute to Action-State-Labs/android-action-kernel development by creating an account on GitHub.

  19. Linux Foundation 宣布成立 Agentic AI 基金会 (AAIF)

    Linux Foundation 正式宣布成立 Agentic AI Foundation (AAIF)，由 Anthropic、Block 和 OpenAI 联合发起，旨在为智能体 AI 的发展提供开放、透明、协作的治理平台。

    核心项目贡献：

    • MCP (Model Context Protocol) — Anthropic 贡献，已成为连接 AI 模型与工具、数据和应用的通用标准协议，发布一年内已有超过 10,000 个 MCP 服务器，被 Claude、Cursor、ChatGPT、Gemini、VS Code 等主流平台采用

    • goose — Block 贡献，开源本地优先的 AI 智能体框架，结合语言模型、可扩展工具和 MCP 集成

    • AGENTS.md — OpenAI 贡献，为 AI 编码智能体提供项目级指导的通用标准，已被超过 60,000 个开源项目采用

    重量级成员阵容：

    白金会员包括 AWS、Anthropic、Block、Bloomberg、Cloudflare、Google、Microsoft 和 OpenAI；黄金会员包括 IBM、JetBrains、Oracle、Salesforce、SAP 等；白银会员包括 Hugging Face、Uber、Zapier 等知名公司。

    Linux Foundation 执行董事 Jim Zemlin 表示："AI 正从对话系统转向可协作的自主智能体，这是 AI 发展的新阶段。将这些项目纳入 AAIF 确保它们在开放治理下持续发展。"

    下一届 MCP Dev Summit 将于 2026 年 4 月 2-3 日在纽约举行。

    🔗 原文链接

    #AgenticAI #MCP #LinuxFoundation #开源 #AI基金会

  20. n8n 2.0 正式发布：安全优先的重大升级

    n8n 团队宣布发布 2.0 版本，这不是一次花哨的功能更新，而是专注于安全性、可靠性和性能的底层重构。

    核心改进

    安全性：任务运行器默认启用，所有代码节点在隔离环境中执行；环境变量访问和任意命令执行默认关闭，采用"默认安全"原则。

    可靠性：移除遗留选项，修复边缘情况 bug，子工作流的 Wait 节点现在能正确返回数据。

    性能：新的 SQLite 池化驱动在基准测试中快达 10 倍，文件系统二进制数据处理更稳定。

    新功能亮点

    • Publish / Save 分离：保存不再直接更新生产环境，新增独立的"发布"按钮，让上线更安全
    • 工作流画布视觉优化
    • 侧边栏导航重组

    升级须知

    官方提供了迁移报告工具，可在 Settings → Migration Report 中查看需要处理的问题。1.x 版本将继续支持 3 个月。

    时间线：Beta 版 12 月 8 日发布，稳定版 12 月 15 日发布。

    里程碑回顾

    自 2023 年 7 月 1.0 发布以来：GitHub Stars 从 3 万增至 16 万，社区成员从 6000+ 增至 11.5 万，团队从 30 人扩展至 190+ 人。

    🔗 原文链接

    #n8n #自动化工作流 #开源 #版本更新 #低代码
    n8n Blog
    Introducing n8n 2.0
    Introducing n8n 2.0
    n8n 2.0 focuses on secure-by-default execution with better reliability and performance.
1px