Skip to main content

面条的草稿箱

无原创,纯转发
  1. pure.md:把任意网页稳定转成适合 LLM 的 Markdown(还带“全球缓存”)

    pure.md 提供一个简单的 REST API:只要在任意 URL 前加上 pure.md/,就能更可靠地获取网页内容,并输出对大模型更友好的 Markdown。

    它能做什么:

    更稳定地抓取网页:通过代理网络模拟真实用户行为,降低被识别为爬虫的概率;必要时还会尝试其他镜像来源。
    渲染 JavaScript 重网页/SPA:自动完成 DOM hydration,避免只拿到“空壳 HTML”。
    多格式转 Markdown:支持 HTML、PDF、图片(含识别与摘要)、以及表格文件(如 Excel/Numbers)等。
    面向 LLM 的精简输出:减少页面冗余信息,附带元数据(frontmatter),降低 token 成本、提升推理效率。
    实时搜索(SERP 抓取):把搜索结果聚合成可直接喂给提示词的 Markdown,让应用更“跟得上今天”。
    按需数据抽取:把 GET 换成 POST,即可用内置生成式模型从页面中抽取结构化 JSON(可自定义 schema),或以流式文本返回。

    定价概览:

    • Starter:按量付费(60 req/min;fetch $0.003;search $0.005;不含 GenAI 抽取;含 $1 体验金)
    • Growth:$19/月 + 计量(600 req/min;更低单价;含 GenAI 抽取;每月 $20 免费额度)
    • Business:$99/月 + 计量(3000 req/min;更低单价;含 GenAI 抽取;每月 $100 免费额度)

    原链接:https://pure.md/

    #网页抓取 #Markdown #大模型工具 #内容提取 #数据抽取
  2. Forma 工程系列导读:面向 AI 的“可变结构”数据存储怎么做?

    AI 应用的数据结构变化速度,往往比传统数据库的建表/改表流程快得多:今天模型输出 12 个字段,明天变 30 个,下周又多出几个新字段——一旦数据库 schema 跟不上,轻则延迟飙升,重则直接线上事故。

    这篇导读介绍了 Forma 的核心思路:只存“实际存在”的字段,让 schema 随 AI 输出演进。作者用“小票”做类比:

    • 传统 SQL 表像一张列出所有可能商品的固定格式小票,没买的也要打印 0;新增商品就得重印格式(=改表)。
    • EAV(Entity-Attribute-Value)更像只列出你真正买了什么:薯片、可乐;新增字段就直接加一行(=无需 DDL)。

    当然,EAV 一直被认为是“反模式”,因为查询性能和可维护性都很差。Forma 的目标是:在保留灵活性的同时,把性能与一致性补回来

    Forma 是什么:三件事组合起来

    Forma 面向 AI 时代的存储引擎,核心组合是:

    EAV 模式:新增字段不需要 ALTER TABLE,天然适配快速迭代
    JSON Schema:把“AI 输出”变成可验证的数据契约(写入时校验),提升类型安全与可控性
    PostgreSQL + DuckDB:OLTP/OLAP 分工 + 热冷分层,在成本与性能之间取得平衡

    系列要解决的三个典型问题

    1. AI 数据结构迭代太快

    传统 DDL 流程(提工单→审批→维护窗口→改表)跟不上。系列第 1 篇会讲:JSON Schema + EAV + Hot Table 如何实现“零 DDL、写入即生效、仍然类型安全”。

    2. EAV 的 N+1 查询噩梦

    EAV 读数据常见的问题是:查 100 条记录可能触发 101 次往返,延迟轻松破 1s。系列第 2 篇会讲用 PostgreSQL 的 CTE + JSON_AGG 把 101 次查询压到 1 次,把延迟从 ~1000ms 降到 ~25ms。

    3. 海量历史数据下的一致性与“脏读”担忧

    数据到十亿级后,热冷分层几乎不可避免,但工程上最怕的是:联邦查询时读到未提交/不一致的数据。系列第 3 篇会讲通过 Anti-Join + Dirty Set 机制,做到联邦查询“零脏读”。

    按你的场景选择阅读顺序

    • 做 AI 应用,需要灵活存储:从 Post 1 开始
    • 被 N+1 性能拖垮,想快速降延迟:直接看 Post 2
    • 数据增长、准备上热冷分层 / Lakehouse:看 Post 3
    • 想系统理解整体架构:按 1→2→3 顺序读

    原文链接:https://blog.ltbase.dev/posts/forma/00-introduction-en

    #EAV #JSONSchema #PostgreSQL #DuckDB #Lakehouse
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. Cloud Code:把 OpenCode 变成跑在 Cloudflare 上的专属云端 Agent

    Cloud Code 是一个基于 Cloudflare Workers + Cloudflare Containers 的 TypeScript 项目,把 OpenCode 以容器化方式运行在 Cloudflare 基础设施上,帮助你快速搭建“云端开发/编码 Agent”。

    它能做什么

    一键部署到 Cloudflare(项目提供 Deploy to Cloudflare 入口)
    本地开发友好:用 Wrangler 模拟 Workers 环境,支持 pnpm dev / pnpm start
    可选 Basic Auth 保护:配置 SERVER_USERNAME / SERVER_PASSWORD 后启用,避免未授权访问
    数据持久化(S3/R2):通过 TigrisFS 将对象存储挂载为本地目录
    • 默认挂载到 /root/s3,工作区在 /root/s3/workspace
    • OpenCode 配置也会落到 /root/s3/.opencode,便于状态持久化
    内置 Cloudflared:可把容器内服务通过 Cloudflare Tunnel 暴露到公网,方便调试/临时分享

    运行与部署要点(简版)

    • 依赖:Node.js(推荐 v20+)、pnpm、Wrangler
    • 常用命令:pnpm installpnpm dev(本地)→ pnpm deploy(部署)
    • 若改了 wrangler.jsonc 绑定:记得执行 pnpm cf-typegen 重新生成类型

    原链接:https://github.com/miantiao-me/cloud-code

    #Cloudflare #OpenCode #Workers #容器化 #S3R2 GitHub - miantiao-me/cloud-code: Cloud Code (Cloudflare + OpenCode), running OpenCode on Cloudflare to build a dedicated cloud…
  9. 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 — Personal AI Assistant
  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. 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. 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
  13. 以“推理速度”交付: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
  14. Repogrep:更快地在 GitHub 代码库里找答案

    Repogrep 是一款主打“超快速代码库搜索”的 AI 工具,可在任意公开的 GitHub 仓库中进行检索。你可以直接粘贴仓库链接,或通过关键词搜索,快速定位代码、项目与相关信息。

    适合的使用场景包括:

    • 初次接手项目时,快速摸清结构与关键模块
    • 排查问题时,跨仓库定位相同实现或调用链
    • 做技术调研时,对比不同项目的实现方式

    原链接:https://app.ami.dev/repogrep

    #代码搜索 #GitHub #开发工具 #AI助手
  15. 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设计
  16. Tool Search Tool:让大规模工具库“按需加载”

    当你的系统里有上百甚至上千个工具时,把所有工具定义一次性塞进上下文,会带来两个典型问题:既浪费上下文窗口(50 个工具就可能吃掉 1–2 万 token),也会让模型在 30–50 个工具以上更容易选错工具。Tool Search Tool 的思路是:先只暴露“搜索工具的工具”,其余工具标记为延迟加载;模型需要时先搜索,再把最相关的少量工具定义加载进来使用。

    核心机制(7 步)

    • 请求里先放入工具搜索工具(Regex 或 BM25 版本)+ 少量常用非延迟工具
    • 其余工具定义加上 defer_loading: true(不立即进上下文)
    • 模型需要更多工具时,先调用 tool search
    • 服务端返回 3–5 个最相关tool_reference
    • 这些引用会被自动展开成完整工具定义
    • 模型再从“已发现”的工具里选择并调用
    • 这样既省上下文,又保持工具选择准确率

    两种搜索方式怎么选

    Regex 版tool_search_tool_regex_20251119):查询是 Python 正则,不是自然语言;适合你希望可控匹配(如 get_.*_data(?i)slack)。限制:模式最长 200 字符。
    BM25 版tool_search_tool_bm25_20251119):查询用自然语言;更适合“我想做什么”式的描述。

    两种方式都会搜索:工具名、描述、参数名、参数描述。

    延迟加载的最佳实践

    • 工具搜索工具本身不要设置 defer_loading: true
    • 保留 3–5 个最常用工具为非延迟(提升命中与体验)
    • 工具命名与描述尽量贴近用户常用说法(提升可检索性)
    • 适合场景:工具 >10 个、工具定义 >10K token、工具选择准确率下降、MCP 多服务器(200+ 工具)等
    • 不太适合:工具 <10 个且几乎每次都要用、工具定义非常短

    响应与错误处理要点

    • 响应里会出现 server_tool_use(触发工具搜索)与 tool_search_tool_result(返回引用列表)
    • 常见 400 错误:
    全部工具都 deferred:至少要有 1 个非延迟工具
    引用的工具缺少定义tool_reference 指向的工具必须在顶层 tools 里有对应定义(并通常设为 deferred)
    • 工具搜索执行期错误(仍返回 200):如 invalid_patternpattern_too_longtoo_many_requestsunavailable

    与 MCP、缓存、流式的配合

    • 可与 MCP toolset 结合:用 default_config.defer_loading 控制 MCP 工具默认延迟加载,并可对特定工具覆盖
    • 支持 prompt caching:已发现的工具可在后续轮次复用,不必每次重新搜索
    • 流式返回会把搜索调用与结果作为事件发出,便于前端展示“正在搜索/已找到工具”

    原文链接:https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

    #工具调用 #Agent开发 #上下文优化 #MCP #API设计 Tool search tool
  17. 代码变便宜了,但“软件”依旧很贵

    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.
  18. 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
  19. 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
  20. dotagents:用一个 .agents 目录统一管理各类 AI 工具配置

    dotagents 是一个 CLI/TUI 工具,把项目或全局的 .agents 目录作为“唯一真相源”,自动为不同 AI 工具创建软链接,并支持安装技能(skills)和插件(plugins),方便在多环境之间保持一致配置、可重复执行、易维护。

    你能用它做什么

    • 以 .agents 为中心统一管理:hooks、commands、skills,以及 AGENTS/CLAUDE.md 等说明文件
    • 一键创建软链接,适配多工具(Claude / Codex / Factory)
    • 从本地路径、Git URL、HTTPS URL 安装 skills;并支持从 marketplace 安装 plugins
    • 可随时重复运行,用于补装、修复链接或更新能力集

    快速开始(要求:Bun 1.3+)

    npx @iannuttall/dotagents
    • 或 bunx @iannuttall/dotagents

    链接关系示例

    .agents/AGENTS.md~/.claude/CLAUDE.md
    .agents/commands~/.claude/commands / ~/.factory/commands / ~/.codex/prompts
    .agents/hooks.agents/skills 同步到对应工具目录

    https://github.com/iannuttall/dotagents

    #AI工具 #开发效率 #CLI #Claude #Codex GitHub - iannuttall/dotagents: One location for all of your hooks, commands, skills, and AGENT/CLAUDE.md files.
1px