Skip to main content

Search: #AI工程化

无原创,纯转发
  1. 聪明人的分工:让昂贵模型做规划,便宜模型去执行

    知名开源开发者 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
  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. 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
  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. 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
  6. 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
  7. 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
  8. 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
  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代理 #隐私安全 #自托管 #聊天机器人 Introducing OpenClaw - OpenClaw Blog
  10. AgentFS:为 AI Agent 设计的“可审计”文件系统

    AgentFS 是 Turso 团队开源的 面向 AI Agent 的文件系统:不仅能像传统文件系统一样读写文件/目录,还把 Agent 的状态与行为记录成可查询、可快照的结构化数据,便于调试与复盘。

    它解决什么问题?

    可审计:每一次文件操作、工具调用、状态变更都会写入同一个 SQLite 数据库,可直接用 SQL 追踪“发生了什么”。
    可复现:一个 .db 文件就是完整运行态,支持复制/快照/回滚,用来复现某次执行或做 what-if 实验。
    可迁移:所有内容都封装在单个 SQLite 文件里,易于移动、备份,甚至纳入版本管理。

    包含哪些组件?

    SDK:TypeScript / Python / Rust(程序化访问文件系统、KV、工具调用记录)。
    CLI:初始化与管理 AgentFS;在 Linux 用 FUSE、macOS 用 NFS 挂载到本机目录;也可在沙箱里把它挂载到 /agent
    规范:提供基于 SQLite 的 Agent 文件系统规格(SPEC)。

    使用提醒

    • 官方标注为 ALPHA 阶段:更适合开发、测试与实验环境,关键数据请谨慎上生产。

    原链接:https://github.com/tursodatabase/agentfs
    #AI代理 #文件系统 #SQLite #可审计 #开发工具
  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. 代码变便宜了,但“软件”依旧很贵

    AI 工具把“写代码”的门槛打穿了:越来越多人用 CLI/对话式方式,直接描述需求就能生成一个能跑的应用。结果不是 SaaS 的黄金时代,而是“个人软件”的兴起——为某个具体问题快速做一个小工具,用完就丢,像当年的电子表格一样当作临时工作台。

    但别误会:代码的成本下降,不代表软件的成本下降。真正昂贵的是把东西做成能长期运行、能承受现实摩擦的系统:维护、边界情况、体验债、数据归属与同步、可靠性与扩展性。周末做出的 CRUD+API Demo 很好看,但银行 CSV 格式一变、网页 DOM 一改、离线与多端同步一上,脆弱性立刻暴露。

    当“能写出来”不再稀缺,新的瓶颈转向两件事:

    分发与注意力:噪音变大,“一下午做出月入五位数”的叙事很多是营销而非可复制路径。
    判断力与系统能力:工程师的价值更偏向架构与取舍——知道该如何组织系统、何时做限流/缓存、哪些变量不能乱放、哪些复杂度必须正面处理。

    谁会在这波变化中受益?有明确领域痛点的专业人士、需要快速解决内部流程的团队、想替换脆弱手工流程的重度用户,以及愿意为“可控与所有权”而不是“高光界面”买单的人。AI 很能加速,但仍需要像审 PR 一样严格复核:它能产出代码,却不负责让软件在现实中长期站住。

    原文链接:https://www.chrisgregori.dev/opinion/code-is-cheap-now-software-isnt

    #AI工具 #软件工程 #产品分发 #架构思维 #个人软件 Code Is Cheap Now. Software Isn’t.
  14. Agent-native 应用:把“功能”变成“结果”

    这篇文章提出一种新范式:与其把产品能力写成一堆固定功能,不如构建一个能反复调用工具、直到达成目标的“软件代理(agent)”。核心在于:让代理拥有与用户同等的操作能力(UI 能做的,代理也能通过工具做到),并把工具设计成足够原子化的“积木”。这样,新功能往往不再是写代码,而是写一段描述结果的提示词;同时,用户提出的意外需求会推动系统“涌现”出新用法,并反过来指导你补齐工具与能力缺口。

    五个核心原则

    对等(Parity):任何 UI 动作,代理都应能通过工具实现同样的结果;否则代理会卡死。
    粒度(Granularity):工具是原子能力;“功能”是代理在循环中用工具达成的结果。改行为优先改提示词,而不是重构代码。
    可组合(Composability):有了原子工具 + 对等能力,就能通过新提示词快速拼出新“功能”(开发者/用户都能做)。
    涌现能力(Emergent capability):用户会提你没设计过的需求;代理若能组合工具完成,就是新机会;若失败,则暴露工具缺口。
    持续变好(Improvement over time):通过沉淀上下文(context 文件)与迭代提示词,应用可在不发版的情况下持续变强。

    落地方法(把原则变成工程实践)

    先做“能力地图”:列出用户能做的事,逐项确认代理具备创建/读取/更新/删除(CRUD)能力,避免“能新建不能修改/删除”的断腿体验。
    先原语、后领域工具:先用文件、bash、读写等基础工具跑通;再为高频模式加领域工具,用于效率、校验、术语锚定,但不要把“判断”写进工具里。
    文件作为通用接口:文件天然可读、可审计、可迁移,代理也最擅长操作;内容放文件、结构化高频数据放数据库(或混合:文件作可读真相,DB 做索引与性能)。
    明确完成信号:不要靠“看起来差不多了”判断结束;让工具/编排层返回明确的 complete 信号,避免无限循环或半成品。
    透明的代理行为:工具调用、进度、状态变化要让 UI 可见;“沉默的代理”会让用户觉得坏了。
    把“授权”做成产品能力:根据风险与可逆性决定自动执行还是强确认;尤其是发送邮件、发布内容等高风险动作。

    对移动端的启示

    • 移动应用容易被后台杀死,代理任务却可能很长:需要checkpoint/恢复机制,尽可能在每次工具结果后存档。
    • iCloud 之类的文件同步能让多设备共享“同一工作区”,但要处理冲突与未下载文件等边界。

    原链接:https://every.to/guides/agent-native

    #AgentNative #软件代理 #AI产品 #工具调用 #产品架构 Agent-native Architectures
  15. Steel:为 AI Agent 打造的开源云端浏览器基础设施

    Steel 是一个开源的浏览器 API,用来在云端按需启动并控制“浏览器集群”,让 AI Agent、自动化脚本把能力真正带到网页上运行。

    它适合做什么?

    • 大规模网页抓取与数据采集(也支持更稳定的反爬配置)
    • 自主 Web Agent(下单、订票、填写表单等真实操作流程)
    • 模型训练数据采集、AI 购物助手、RPA/销售自动化、QA 测试、客服自动化

    核心能力概览

    • Sessions API:一行调用启动浏览器会话
    • 自动 CAPTCHA 处理:减少流程中断
    • 代理与指纹控制:降低被识别为机器人的概率
    • 快速启动:平均会话启动时间低于 1 秒(同区域更快)
    • 长会话:单个会话最长可跑 24 小时
    • 上下文复用:保存/注入 Cookies 与本地存储,续跑更顺畅
    • 低改动迁移:Puppeteer/Playwright/Selenium 通过少量改动即可上云
    • 可观测性:提供会话查看器,支持实时/录制回放调试
    • 安全登录:帮助自动化访问需要登录的站点

    价格与开源

    • 提供免费档起步(按浏览器小时/代理带宽/CAPTCHA 计量),也有从个人到企业的多档套餐
    • 项目开源,可本地运行或用 Docker 自托管(官方 GitHub 仓库提供)

    原链接:https://steel.dev/
    #浏览器自动化 #AI代理 #Web抓取 #开源工具 #云基础设施 Steel | Open-source Headless Browser API
  16. 用好编码代理:Claude Code 2.0 的关键功能与“上下文工程”心法

    这篇长文把 Claude Code 2.0 当成一个“能动手的工作台”来拆解:不仅讲新功能,更强调如何用更好的流程与上下文管理,让代理稳定产出。

    1) 先换个视角:你不是“追上更新”,而是“借力变强”

    作者给了一个更实用的框架:

    跟进工具:定期用、定期看更新(不必天天追)。
    深耕领域:懂业务/系统设计/工程习惯,才能把“未知”变成“可提问、可验证”。
    多玩多试:用不同模型做同一件事,快速建立直觉与边界。

    2) Claude Code 2.0 值得关注的体验升级

    一些偏“日常效率”的改动,叠加起来很实用:

    语法高亮 + 更舒服的评审体验(作者因此更愿意在 CLI 里完成 review)
    /context 看上下文占用(建议复杂任务到 60% 左右就交接或压缩)
    Checkpointing(Esc+Esc / /rewind:能回到某个检查点,回滚代码与对话
    Prompt suggestions / 历史搜索(Ctrl + R:减少重复输入
    更快的模糊文件搜索、队列导航、LSP 插件

    3) Sub-agents(子代理)怎么用才不浪费

    作者重点讲了“子代理不是魔法,是上下文与工具调用策略”:

    Explore:偏“只读搜索专家”,适合快速扫代码库、定位文件与线索。
    general-purpose / plan:更像“全能协作者”,通常会继承更多上下文。
    • 关键提醒:不要只依赖 Explore 的摘要。摘要是“有损压缩”,重要文件最好让主代理再读一遍,让信息彼此“交叉注意力”,推理更稳。

    4) 核心概念:Context Engineering(上下文工程)

    代理之所以“烧 tokens”,不是它话多,而是:

    工具调用本身 + 工具返回结果都会进入上下文;
    • 上下文越长,检索与注意力越容易退化(作者称为 context rot / degradation)。

    因此,上下文工程的目标是:

    • 把最相关的信息放进来
    • 控制“噪音”和重复指令
    • 用清晰结构(计划、scratchpad、handoff)对抗跑偏

    5) Hooks / Skills / MCP:把“提示词”产品化

    作者把这三者放在一起看:

    Hooks:在对话生命周期某个节点自动触发脚本(比如 Stop 后自动提醒/继续下一步)。
    Skills:把领域指令与脚本做成“按需加载”的技能包,避免常驻系统提示导致上下文膨胀。
    MCP:连接外部工具/服务,但要注意“工具定义与中间结果”同样会吃上下文与成本;文中也提到用代码执行环境来降低这种膨胀的思路。

    6) 一个很实战的工作流建议

    作者的默认搭配大意是:

    Claude(Opus 4.5)偏执行与沟通:更像结对编程伙伴、反馈快。
    Codex 偏 review/找 bug:更克制、误报少,适合做“第二视角审查”。
    • 面对难功能:先跑一个“可丢弃的草稿版本”,用它暴露模型的偏差,再用更精准的提示第二轮迭代。

    原文链接:https://sankalp.bearblog.dev/my-experience-with-claude-code-20-and-how-to-get-better-at-using-coding-agents/

    #ClaudeCode #编码代理 #上下文工程 #AI工具 #软件工程
  17. 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
  18. 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
  19. 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工作流
  20. GLM-4.7:把“能写代码”推进到“能当搭档”

    Z.ai 发布 GLM-4.7,主打更强的工程落地能力:不仅写得对,还更擅长在真实工作流里(Agent、终端、工具调用)稳定推进任务。

    这次重点提升了什么?

    核心编码与代理式开发:相较 GLM-4.6,在多语言 Agent 编程与终端任务上有明显提升;例如 SWE-bench Verified 73.8%(+5.8)SWE-bench Multilingual 66.7%(+12.9)Terminal Bench 2.0 41.0%(+16.5)。并强调在 Claude Code、Cline、Roo Code 等主流框架中更“好用”。
    Vibe Coding / UI 生成质量:更容易产出更现代、更干净的网页;做幻灯片时布局与尺寸更准确,整体观感更接近可直接交付的作品。
    工具使用能力:工具调用与浏览任务的表现增强(文中提到 τ²-Bench、BrowseComp 等基准),更适合“边查边做”的复杂流程。
    复杂推理与数学:推理能力提升,HLE(Humanity’s Last Exam)42.8%(+12.4,带工具),面向高难问题的稳健性更强。

    一个很实用的新变化:更可控的“思考”机制

    Interleaved Thinking:在回复/调用工具前先思考,提高指令遵循与产出质量。
    Preserved Thinking:在多轮编码代理场景中保留推理块,减少长任务里的信息丢失与前后不一致。
    Turn-level Thinking:按回合开关推理:简单问题更省时,复杂任务更稳。

    如何开始使用

    在线体验:Z.ai Chat 里选择 GLM-4.7
    API:Z.ai 文档提供接入指南(也支持通过 OpenRouter 使用)
    • 本地部署:权重已在 HuggingFace / ModelScope 提供,并支持 vLLM、SGLang 等推理框架
    • 编码代理:可在 Claude Code、Cline、Roo Code、Kilo Code 等工具中使用(订阅用户可按文中指引升级模型名为 glm-4.7

    原文链接:https://z.ai/blog/glm-4.7

    #GLM47 #AI编程 #Agent #工具调用 #推理能力
1px