Skip to main content

Search: #开发者工具

无原创,纯转发
  1. Slim Tools:为 AI 智能体减负的统一 MCP 工具网关

    在使用 AI Agent(如 Claude、Cursor 等)时,你是否遇到过因为加载了太多 MCP 或 OpenAPI 工具,导致上下文窗口(Context Window)被严重占用、Token 消耗飞涨的情况?

    Slim Tools 提供了一个巧妙的解决方案:它将所有上游工具统一封装进一个极简的 MCP 接口中。

    核心特性:

    统一入口:无需向 AI 暴露所有工具,只需提供一个 Slim Tools 的 MCP URL(https://slim.tools/mcp)。
    按需探索:AI 代理在运行阶段仅能看到 discover_tools(工具搜索)和 execute_code(沙盒代码执行)两个核心能力。
    高效联动:AI 通过搜索找到匹配的工具,然后在沙盒中运行代码来组合并调用这些上游 API(如 GitHub、Notion、Slack、Figma 等)。
    简化授权:统一管理所有上游服务的 OAuth 授权,无需重复配置。

    通过这种“运行时发现”的设计,AI 代理无需在上下文里“背负”沉重的工具集,不仅让 Prompt 更加清爽,也让 Agent 的响应速度大幅提升。

    原文链接:http://slim.tools

    #AIAgents #MCP #开发者工具 #效率工具 Slim Tools | Tool Orchestration Runtime for AI Agents
  2. 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 — The Agent Harness Framework
  3. 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
  4. 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 – Run Claude Code, Codex, Copilot, OpenCode from anywhere
  5. CursorBench:Cursor 如何更贴近真实开发来评估模型质量

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

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

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

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

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

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

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

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

    #模型评测 #编程智能体 #基准测试 #Cursor #开发者体验 How we compare model quality in Cursor · Cursor
  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 Minions: Stripe’s one-shot, end-to-end coding agents
  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代理 #自动化工作流 #云端沙盒 #可观测性 #开发者工具 VM0 - Your Trustworthy AI Teammate
  8. 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
  9. Vercel AI Gateway 现已支持 Claude Code Max:订阅直连、统一观测

    Vercel 宣布其 AI Gateway 现已支持在 Claude Code CLI 中使用 Claude Code Max 订阅。对开发者来说,这意味着:你可以继续用自己已有的 Anthropic 订阅,不增加额外费用,同时把 Claude Code 的调用统一接入 Vercel 平台,获得更完整的可观测性、用量追踪与监控能力。

    你能获得什么

    沿用现有 Claude Code Max 订阅:照常用 Anthropic 模型,无需额外开销
    统一观测与用量管理:通过 Vercel 平台查看请求、监控使用模式与成本趋势
    更灵活的路由能力:AI Gateway 可作为直通 Anthropic 的代理;必要时也可作为路由器切换到其他提供方(fallback)

    快速配置(核心步骤)

    在你的 shell 配置文件(如 ~/.zshrc~/.bashrc)加入环境变量:

    • 将 Anthropic 入口指向 AI Gateway
    • 用独立的 x-ai-gateway-api-key 做网关鉴权(与 Claude 订阅鉴权并存)

    启动 Claude Code:

    • 运行 claude
    • 登录时选择 Option 1 - Claude account with subscription(使用带订阅的 Claude 账号)
    • 若遇到问题,可先 claude /logout 再重新登录

    工作原理(简述)

    Claude Code 仍然使用 Anthropic 的订阅凭证进行认证,并携带 Authorization 头。由于该头用于 Claude 订阅身份,AI Gateway 采用单独的 x-ai-gateway-api-key 进行自身认证,从而实现两套鉴权机制同时生效。

    原文链接:https://vercel.com/changelog/claude-code-max-via-ai-gateway-available-now-for-claude-code

    #Vercel #AIGateway #ClaudeCode #可观测性 #开发者工具 Claude Code Max via AI Gateway, available now for Claude Code - Vercel
  10. 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 #开发者工具
  11. Amp 宣布下线 Amp Tab:Tab 补全时代正在退场

    Amp 团队宣布将移除 Amp Tab(内联 Tab 补全功能),理由很直接:这不再符合他们看到的未来。

    他们的判断基于一个变化——AI 写代码的占比正在迅速上升:

    • 一年前,代码大多还是人手写
    • 2025 年 6 月发布 Amp Tab 时,Amp 已经在写大部分代码
    • 现在,Amp 负责了他们 90% 的交付代码

    Amp 认为,Tab 补全与传统补全引擎来自“人写为主、AI 辅助”的时代;但这个时代正在结束。越来越多用户的工作方式变成:几天不打开编辑器,也能持续交付代码。瓶颈不再是“写得快不快”,而是“把代码产出、落地得快不快”。

    因此,Amp 将把资源投入到“后补全时代”的方向:默认由智能体(agents)完成大部分编码工作,而不是在输入时做局部补全。

    时间安排:

    • Amp Tab 将继续可用至 2026 年 1 月底
    • 之后如果仍需要内联补全,可考虑:Cursor / GitHub Copilot / Zed

    原文链接:https://ampcode.com/news/tab-tab-dead

    #AI编程 #代码补全 #开发者工具 #智能体 #Amp Tab, Tab, Dead
  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 #开发工作流 #效率工具 #软件工程 Shipping at Inference-Speed | Peter Steinberger
  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设计
  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 #软件工程 #生产力 Opus 4.5 is going to change everything
  15. Ref:给你的 AI Agent 一份“刚刚好”的文档上下文

    做 AI 编程助手最怕两件事:胡编上下文膨胀。Ref 主打的就是把问题变简单——让你的 Agent 能随用随查公共/私有技术文档,只拿“够用且准确”的信息。

    它怎么做?
    Ref 通过 MCP(Model Context Protocol)把文档上下文接到你的 AI 工具里:既有持续更新的公共文档索引,也支持把你的私有资料(如 GitHub 仓库、PDF)纳入检索。

    给 Agent 的两个核心能力:

    search_documentation:面向技术文档的精确搜索,能定位到具体章节,支持公有与私有文档集。
    read_url:读取任意网页或 GitHub 文件内容(可含私有内容),适合顺藤摸瓜跟进链接。

    为什么不是“东拼西凑工具链”?
    你当然可以分别用:代码片段、搜索、爬取、私有代码检索、PDF 检索等工具组合;Ref 的定位是把这些需求尽量合并成一个更统一的入口,减少集成成本与上下文噪音。

    安全与企业能力(官方强调点):

    • SOC2 合规(并提供 Trust Center 与隐私安全说明)
    • 支持 SSO 与 MCP OAuth
    • 提供“主动提示注入防护”(对返回的上下文做注入扫描,仍在开发中)

    定价概览:

    • Free:200 credits(不刷新、不失效,官方估算约 10 周常规使用)
    • Basic:$9/月,1000 credits
    • Team:$9/月/席位,1000 credits/席位(团队共享私有文档索引与统一账单)
    • Enterprise:SSO、SOC2、优先支持、定制化等

    如果你在用 Claude/Cursor/Zed 等工具做工程开发,且经常需要“查最新文档 + 查公司内部资料”,这种“面向文档的上下文层”会比泛用搜索/爬虫更省 token,也更贴近代码场景。

    原链接:https://ref.tools/

    #MCP #开发者工具 #技术文档 #AI编程助手 #RAG Ref - Review every important decision
  16. 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 基建mem059% 份额领跑(按 PyPI + npm 月下载量口径)。
    向量数据库:没有绝对赢家;Weaviate 约 25%,其余多家在 10–25% 之间拉锯。
    AI 规则文件CLAUDE.md 使用率 67%;不少团队多格式并存,且 17% 的仓库三种格式都用
    AI SDK 增长:Anthropic SDK 以 43M 下载领先(约 8 倍增长);Pydantic AI 增长 3.7×6M
    LLMOps:LiteLLM 月下载量增长 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工具链 #模型评测 #软件工程趋势 AI Code Review | Greptile | Merge 4X Faster, Catch 3X More Bugs
  17. 一份配置,多端通用:MCP Config 转换器

    mcp-config 是一个参考实现:把“同一份 MCP Server 配置”一键转换成不同应用所需的配置文件或命令,避免在 Claude Desktop、Cursor、VS Code 等多处重复手工改配置。

    它解决什么问题

    • 只维护一份 MCP Server 定义(支持远程 HTTP / 本地 stdio)
    • 按目标客户端输出对应格式:JSON / CLI / TOML
    • 适配 30+ 客户端格式,减少迁移与同步成本

    怎么用(概念流程)

    • 将仓库的 src/ 复制到你的项目中
    • 使用 getClients() 查看支持的客户端
    • 用 transformConfig({ server, client }) 生成目标客户端需要的配置字符串(例如 Cursor 的 JSON,或 Claude Code 的添加命令)

    支持范围(示例)

    • JSON 类:Claude Desktop、Cursor、Windsurf、VS Code/Copilot、JetBrains、Zed、Warp、Perplexity Desktop 等
    • CLI 类:Claude Code、Amp、OpenAI Codex CLI 等

    适合谁

    • 同时在多个 IDE/客户端里用 MCP 的开发者与团队
    • 想把“配置维护”从手工劳动变成可复用工具链的人

    原链接:https://github.com/iannuttall/mcp-config

    #MCP #配置管理 #开发工具 #TypeScript #效率提升 GitHub - iannuttall/mcp-config: Turn one MCP server setup into the right format for lots of apps.
  18. Bloom:自动化生成“行为评估”的开源框架

    前沿模型的对齐研究离不开高质量的行为评估,但传统评估往往开发周期长、容易“过时”(被训练数据污染或被能力提升绕过)。Anthropic 发布了 Bloom:一个开源的“代理式”评估生成框架,用更快、更可扩展的方式衡量模型是否出现特定不对齐行为。

    Bloom 的核心思路是:研究者只需定义要测的行为(并可提供少量示例与配置),Bloom 就能自动生成大量情境并运行对话,最后给出该行为在不同模型上的出现频率与严重程度。官方结果显示,Bloom 的评分与人工标注有较强一致性,也能把“正常模型”和被刻意设计成异常行为的“模型个体”区分开。

    Bloom 怎么做评估(四阶段流水线)

    理解(Understanding):分析研究者的行为描述与示例,明确“要测什么、为什么测”。
    构思(Ideation):自动生成一批用于诱发目标行为的评估场景(含系统提示、用户设定、环境等)。
    执行(Rollout):并行跑场景,对话中还会模拟用户与工具响应,以更真实地触发目标行为。
    判定(Judgment):评审模型为每段对话打分,并输出套件级总结指标(如诱发率、平均行为强度)。

    与固定题库不同,Bloom 每次运行可生成不同场景,但通过“seed 配置”保持可复现;研究者还能调节模型选择、对话长度、是否使用工具、场景多样性,以及增加如“真实感”“诱发难度”等副指标。

    已发布的基准与一个案例

    Anthropic 同时发布了对 16 个模型的基准结果,覆盖四类对齐相关行为:

    • 迎合性妄想(delusional sycophancy)
    • 受指令驱动的长程破坏(instructed long-horizon sabotage)
    • 自我保存(self-preservation)
    • 自我偏好偏差(self-preferential bias)

    在“自我偏好偏差”案例中,Bloom 复现了系统卡里的模型排序,并进一步发现:在某些模型上,提高推理强度会降低偏差(更多体现为识别利益冲突后拒绝自评)。

    开源地址与技术细节见原文与报告:
    https://www.anthropic.com/research/bloom

    #AI安全 #对齐研究 #模型评估 #开源工具 #大模型 Introducing Bloom: an open source tool for automated behavioral evaluations
  19. Agent Skills:给 AI Agent “装上技能包”

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

    为什么需要它?

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

    它能带来什么?

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

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

    上手入口

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

    原链接:https://agentskills.io/home
    #AI代理 #开放标准 #工作流 #知识沉淀 #开发者工具 Agent Skills Overview - Agent Skills
  20. 如何让 Claude Code Skills 可靠激活

    Claude Code 的 Skills 功能理论上会根据描述自动激活,但实际测试发现激活率仅约 20%,跟抛硬币差不多。作者通过 200+ 次测试,找到了两种有效方案。

    测试结果对比:

    Simple 简单指令:整体成功率仅 20%
    Forced Eval 强制评估:成功率 84%,最稳定
    LLM Eval 预评估:成功率 80%,更快更省钱

    核心发现

    强制评估之所以有效,在于它创建了「承诺机制」:

    1. Claude 必须逐一评估每个 Skill 并给出 YES/NO
    2. 明确表态后才能继续实现
    3. 使用 "MANDATORY"、"CRITICAL" 等强硬措辞增加执行力

    如何选择

    Forced Eval:追求稳定性,不介意输出冗长
    LLM Eval:追求速度和成本,适合单一技能场景

    使用方法:在 .claude/hooks/ 创建对应脚本,并在 settings.json 中配置 hook。如果用 claude-skills-cli,可直接运行:

    pnpm exec claude-skills-cli add-hook
    


    🔗 原文链接

    #ClaudeCode #Skills #开发技巧 #Anthropic #AI工具
1px