API | 面条的草稿箱

keep.md：把收藏夹变成「可被 AI 直接读取」的 Markdown APIkeep.md 主打一个简单但实用的思路：把你在各处保存的链接，统一存成 Markdown，并提供 API + Agent 技能，让它们能随时被你的工作流或智能体当作上下文调用

Tue, 10 Feb 2026 00:46:58 GMT

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.

Open Responses：让 LLM 接口真正“可互通”的开放规范Open Responses 是一个开源规范与生态，目标是基于 OpenAI Responses API 的理念，建立多模型提供方可互操作的统一接口层

Fri, 16 Jan 2026 05:36:14 GMT

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.

Tool Search Tool：让大规模工具库“按需加载”当你的系统里有上百甚至上千个工具时，把所有工具定义一次性塞进上下文，会带来两个典型问题：既浪费上下文窗口（50 个工具就可能吃掉 1–2 万 token），也会让模型在 30–50 个工具以上更容易选错工具

Thu, 15 Jan 2026 06:42:34 GMT

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_pattern、pattern_too_long、too_many_requests、unavailable

与 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设计

Claude API Docs

Tool search tool

Claude API Documentation