Search: #AI代理

面条的草稿箱

1. 5 天前

   聪明人的分工：让昂贵模型做规划，便宜模型去执行
   
   知名开源开发者 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

   

   Agent Skills Overview - Agent Skills

   A standardized way to give AI agents new capabilities and expertise.

2. 17:04 · 2026年5月29日 · 周五

   慢即是快：如何利用 AI 写出更高质量的代码
   
   很多人认为，AI 编程的意义在于“快”——以最快的速度堆砌出勉强能运行的代码，然后匆忙合并发布。但这种“快”往往伴随着低质量和技术债。
   
   实际上，大语言模型（LLM）非常灵活，我们完全可以反其道而行之：利用 AI，用更慢的速度写出质量更高的代码。
   
   以下是这种“慢速 AI 编程”的核心思路：
   
   • 让 AI 成为挑剔的 Review 助手：LLM 极其擅长寻找 Bug。你可以通过设置特定的“技能（Skills）”，让多个不同的模型（如 Claude 和 GPT）同时对你的 PR 进行审查并给 Bug 分级，通过交叉验证有效降低误报率。
   • 主导修复与取舍：根据 AI 反馈的 Bug 列表，优先引导 AI 修复高危和中度漏洞。如果发现架构设计有根本性问题，甚至可以果断放弃现有的 PR 重新构思。
   • 把“修 Bug”当成探索之旅：这种工作流虽然不会提升你的“开发速度”，但常常会帮你揪出代码库中早已存在的历史遗留 Bug。在解决这些问题的过程中，你会编写更多单测，深入理解系统的边缘情况。
   
   这并不是那种吹嘘“10倍效率”的浮躁开发方式，而是一种更健康的编程状态：借力 AI，更严谨、更方法论地对待每一行代码，让代码库保持健康。
   
   下次使用 AI 时，不妨慢下来，试着问问它：“我的这段代码可能会在哪里崩溃？”
   
   https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/
   
   #AI编程 #代码质量 #软件工程 #程序员

   Read the Tea Leaves

   Using AI to write better code more slowly

   A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible. Spew out barely-passable slop, open massive PRs, and merge them unvetted. Ship it! But t…

3. 18:03 · 2026年5月11日 · 周一

   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

   Agent = Model + Harness. Build autonomous agents and powerful AI workflows with Flue's programmable TypeScript harness. Write once, deploy anywhere.

4. 09:13 · 2026年4月25日 · 周六

   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

   

   GitHub - h4ckf0r0day/obscura: The headless browser for AI agents and web scraping

   The headless browser for AI agents and web scraping - h4ckf0r0day/obscura

5. 16:44 · 2026年4月11日 · 周六

   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

   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.

6. 08:13 · 2026年3月13日 · 周五

   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代理 #架构设计 #学习型组织

   Augmentcode

   

   How we hire AI-native engineers now: our criteria

   The most powerful AI software development platform with the industry-leading context engine.

7. 08:19 · 2026年2月12日 · 周四

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

8. 22:31 · 2026年2月10日 · 周二

   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 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.

9. 08:46 · 2026年2月10日 · 周二

   keep.md：把收藏夹变成「可被 AI 直接读取」的 Markdown API
   
   keep.md 主打一个简单但实用的思路：把你在各处保存的链接，统一存成 Markdown，并提供 API + Agent 技能，让它们能随时被你的工作流或智能体当作上下文调用。
   
   它适合这些场景：
   
   • 你保存了一堆资料链接，希望 AI/Agent 能直接读懂内容并引用
   • 你收藏了文档，想让 Agent 辅助写代码、查用法
   • 你保留了长线程/讨论，希望 Agent 自动整理成摘要或草稿
   
   工作方式也很直观：你保存链接 → 系统生成 Markdown → 你的 Agent 读取并使用。
   目前提供 Chrome 扩展（页面显示仍在等待 Chrome 商店审核），并支持接入多种工具/平台（如 n8n、Claude SDK、各类 Agent 等）。
   
   费用信息：免费档包含 50 条链接，付费计划 $10/月起。
   
   原链接：https://keep.md/
   
   #书签管理 #Markdown #API #AI工具 #Agent工作流

   Keep

   

   Keep | Save and search your bookmarks from anywhere

   Keep your bookmarks as markdown and search them from the web, the API, or with your personal AI agent.

10. 10:19 · 2026年2月1日 · 周日

    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

    Zero connects to 100+ tools and does the work. Reports, triage, outreach, research. In Slack or on the web.

11. 11:11 · 2026年1月31日 · 周六

    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

    A standard format for tracking AI-generated code.

12. 11:09 · 2026年1月31日 · 周六

    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

    The journey from Clawd to Moltbot to OpenClaw—and why this name is here to stay.

13. 14:20 · 2026年1月24日 · 周六

    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 #可审计 #开发工具

    GitHub

    GitHub - tursodatabase/agentfs: The filesystem for agents.

    The filesystem for agents. Contribute to tursodatabase/agentfs development by creating an account on GitHub.

14. 08:51 · 2026年1月22日 · 周四

    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 #开发者工具

15. 08:51 · 2026年1月22日 · 周四

    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

    Ampcode

    

    Tab, Tab, Dead

    We're removing Amp Tab. It is not part of the future we see.

16. 10:00 · 2026年1月18日 · 周日

    以“推理速度”交付：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

    Why I stopped reading code and started watching it stream by.

17. 22:40 · 2026年1月12日 · 周一

    代码变便宜了，但“软件”依旧很贵
    
    AI 工具把“写代码”的门槛打穿了：越来越多人用 CLI/对话式方式，直接描述需求就能生成一个能跑的应用。结果不是 SaaS 的黄金时代，而是“个人软件”的兴起——为某个具体问题快速做一个小工具，用完就丢，像当年的电子表格一样当作临时工作台。
    
    但别误会：代码的成本下降，不代表软件的成本下降。真正昂贵的是把东西做成能长期运行、能承受现实摩擦的系统：维护、边界情况、体验债、数据归属与同步、可靠性与扩展性。周末做出的 CRUD+API Demo 很好看，但银行 CSV 格式一变、网页 DOM 一改、离线与多端同步一上，脆弱性立刻暴露。
    
    当“能写出来”不再稀缺，新的瓶颈转向两件事：
    
    • 分发与注意力：噪音变大，“一下午做出月入五位数”的叙事很多是营销而非可复制路径。
    • 判断力与系统能力：工程师的价值更偏向架构与取舍——知道该如何组织系统、何时做限流/缓存、哪些变量不能乱放、哪些复杂度必须正面处理。
    
    谁会在这波变化中受益？有明确领域痛点的专业人士、需要快速解决内部流程的团队、想替换脆弱手工流程的重度用户，以及愿意为“可控与所有权”而不是“高光界面”买单的人。AI 很能加速，但仍需要像审 PR 一样严格复核：它能产出代码，却不负责让软件在现实中长期站住。
    
    原文链接：https://www.chrisgregori.dev/opinion/code-is-cheap-now-software-isnt
    
    #AI工具 #软件工程 #产品分发 #架构思维 #个人软件

    www.chrisgregori.dev

    

    Code Is Cheap Now. Software Isn’t.

    The barrier to entry for building software has collapsed. The barrier to building something that matters hasn’t moved an inch.

18. 17:21 · 2026年1月12日 · 周一

    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

    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.

19. 16:37 · 2026年1月12日 · 周一

    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产品 #工具调用 #产品架构

    every.to

    

    Agent-native Architectures

    A technical guide for building applications where agents are first-class citizens

20. 15:43 · 2026年1月1日 · 周四

    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.dev

    

    Steel | Open-source Headless Browser API

    Steel is an open-source browser API purpose-built for AI agents.