Curated Reads

原文： “You Said No MCP!” — Earendil 作者： Earendil Engineering · 原文发布日期： 2026 年 9 月 29 日 翻译说明： 本文根据原文 PDF 译为中文，翻译由 AI 完成。正文保留作者的第一人称表述，文中的“我们”指 Earendil 团队。产品行为与判断以原文发表时为准；文末演示已根据补充的会话记录完整呈现，交互式回放请访问原文。 如果你过去访问过 pi.dev，就会看到一条颇为自豪的声明：Pi 不支持 MCP。如果你听过我们谈论 Pi 的播客，也会发现我们不止一次对 MCP 表达过不以为然的态度。Mario 还专门写过一篇文章。然而，现在升级 Pi 后，你会发现 MCP 已经成为受支持的功能。发生了什么？ 事物会变 首先要记住，世界并非一成不变。过去一年，我们一直在关注 MCP，而今天的 MCP 已经不是过去的 MCP 了。不过，单凭这一点，还不足以成为把它纳入核心的理由。你也知道，Pi 拥有很出色的扩展生态，MCP 完全可以做成一个扩展，对吧？甚至可以是一个得到 Earendil 官方认可的扩展。 没错，MCP 确实可以作为扩展存在，而且之前就是如此。如今 MCP 成为核心的一部分，是我们坐下来共同讨论、重新思考后的结果。 到底发生了什么变化？ 我们把 MCP 纳入核心，不只是因为 MCP 本身发生了变化，还因为我们发现，为支持它而需要做出的改动具有普遍的价值。例如，我们为 MCP 做的改动，也让在 Pi 中使用 Jev 变得更加容易。归根结底，Pi 所需要的东西与 MCP 所需要的相当接近：一个以解释器形式提供、可供操作的沙箱。 尽管 MCP 在很多方面都有了改善，但也有不少问题依旧存在。MCP 最大的问题仍然是难以组合。即使有了 Codemode——一个用来组合工具调用的精巧小沙箱——MCP 在这方面也还没有完全兑现承诺。不过，到了现在，这更多是现有 MCP 服务器，以及不同 Agent 运行框架（harness）与这些服务器交互方式的问题，而不完全是 MCP 本身的问题。 ...

来源： OpenAI API 文档 — Programmatic Tool Calling 说明： 本文是基于 OpenAI 官方文档整理的中文译介，保留原文技术结构与关键示例。API 能力可能更新，请以官方文档为准。 程序化工具调用（Programmatic Tool Calling）允许模型编写并运行 JavaScript 来协调可用工具。生成的程序可以并发调用工具、使用循环和条件、组合中间结果，再向模型返回一个更小的最终结果，而不是把每一份原始输出都塞回模型上下文。 这特别适合控制流可预测的多工具阶段，以及中间数据量很大的任务。在 Responses API 中，应用决定是否开放该能力，以及每个工具可被直接调用、程序调用或两者皆可。客户端函数依然由应用执行。在 Agents API 中，这项能力默认开启，托管框架会负责 Agent 循环。 启用前应查看最新模型页面，确认所选模型当前支持该能力。 运行时环境 每段生成的程序都在一个全新、隔离的 V8 运行时中执行。它支持 JavaScript 和顶层 await，但不是 Node.js。运行时不提供： 安装包； 直接网络访问； 通用文件系统； 子进程执行； 控制台； 跨程序执行持久化的 JavaScript 状态。 程序只能通过请求中启用的工具访问外部系统，并用 text(...) 或 image(...) 输出结果。 Responses API 可以在不使用持久代码容器的情况下，将程序化工具调用用于零数据保留（ZDR）工作流。但组织或项目必须已经启用 ZDR；store: false 只代表无状态续传，并不会自行开启 ZDR。实际保留资格取决于完整请求，包括模型、工具和第三方服务。 何时适合使用 当一个阶段的控制流可预测，而且代码能够把多份中间输出压缩为较小的结构化结果时，程序化编排最有价值。 任务形态 推荐方式 单次查询或操作 直接工具调用 过滤、连接、排序、去重、聚合或校验多份结果 程序化工具调用 数据流可预测的依赖调用 程序化工具调用，并明确限制与失败行为 每个结果都会影响下一步判断的自适应搜索或语义评估 直接工具调用 写操作或需要审批的动作 默认直接调用，保留清晰授权边界 最终引用或原生制品校验 默认直接调用；除非程序能保留并验证所有必需项 真正的分界线是“是否需要重新判断”。确定性的协调和缩减适合交给代码；如果每个结果都会改变下一步的语义决策，就应让模型重新参与。 ...

来源： OpenAI API 文档 — Tool search 说明： 本文是基于 OpenAI 官方文档整理的中文译介，保留原文技术要点并对示例做了精简。API 能力可能更新，请以原文为准。 当 Agent 可用的工具越来越多，把所有工具定义一次性塞进模型上下文会带来明显成本：大量参数 Schema 占用输入 Token，工具变更还可能破坏提示缓存。**Tool Search（工具搜索）**解决的正是这个问题——模型在运行时搜索并加载当前任务真正需要的工具，而不是在请求开始时导入完整工具目录。 新发现的工具会被追加到上下文末尾。这种设计尽量保留已有缓存前缀，因此既能降低 Token 消耗，也有助于改善延迟。 在 Responses API 中，tool_search 仅受 gpt-5.4 及之后的模型支持。 快速开始 在 Responses API 中启用工具搜索需要两步： 在 tools 数组中加入 { "type": "tool_search" }。 给希望按需加载的函数或 MCP Server 设置 defer_loading: true。 最小配置如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 { "tools": [ { "type": "namespace", "name": "crm", "description": "用于查询客户与管理订单的 CRM 工具。", "tools": [ { "type": "function", "name": "list_open_orders", "description": "按客户 ID 查询未完成订单。", "defer_loading": true, "parameters": { "type": "object", "properties": { "customer_id": { "type": "string" } }, "required": ["customer_id"], "additionalProperties": false } } ] }, { "type": "tool_search" } ] } 尽量使用命名空间 工具搜索可以作用于延迟加载的单个函数、命名空间（namespace）或 MCP Server。OpenAI 更推荐后两种形式，因为模型主要针对这些搜索界面进行过训练，而且通常能节省更多 Token。 ...

来源： Anthropic Engineering — Demystifying evals for AI agents 好的评估能帮助团队更自信地交付 AI Agent。缺少评估，团队很容易陷入被动循环——只有在生产环境中才能发现问题，而修复一个故障往往又引发新的故障。评估能让问题和行为变化在影响用户之前暴露出来，其价值会在 Agent 的整个生命周期中持续累积。 ...