MCP

原文： “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 本身的问题。 ...

本文整理自与 ChatGPT 的一次讨论。讨论的出发点是：有一个很贵的 API，调用一次可能要 100 美元。这种调用不该由 Agent 自己决定要不要打，必须由人明确审核；审核结果 Agent 不能模拟，也不能伪造。 普通对话框里的 “Yes” 解决不了这个问题。Claude Code 那种逐条权限确认，拦的是本地命令和文件写入，人就坐在同一台机器前。100 美元一次的外部 API 要的是另一条边界：人在模型碰不到的地方，对这一次、这一组参数、这一笔金额签字，执行层只认这张签字。 这件事更准确的名字是带外人工授权（out-of-band human authorization）。Human-in-the-loop 只说明“环里有人”，没有说明这个人的同意能不能被模型伪造。 模型只能提出调用 安全边界要拆成四段，而且后三段都不能跑在 LLM 里面： flowchart TD Agent["Agent / LLM 提出 expensive_api"] --> Gateway["Authorization Gateway / MCP Server"] Gateway --> Policy{"Policy Engine 这笔请求是否允许进入审批"} Policy -- "拒绝" --> Deny["直接失败，不建审批单"] Policy -- "需要人批" --> Request["创建 approval_request 冻结 tool、参数、金额、request_id"] Request --> Pause["暂停，不调用 API"] Pause --> Human["独立 Approval Service Web / App / Slack / 推送"] Human -- "人批准" --> Cap["签发一次性授权"] Cap --> Check["Gateway 验签、验绑定、验未使用"] Check -- "全部匹配" --> API["expensive API"] Check -- "任一不匹配" --> Deny 四段各自只做一件事： ...

来源： 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。 ...

MiroThinker 1.7 在长问题推理领域取得了SOTA的成绩，优秀的成绩是由强Model与扎实的Harness共同组成的，本文是对其Harness实现中的关键工程优化的记录。 前置背景 MiroThinker 是一个深度研究型 Agent —— 给一个复杂问题（“今天 arxiv 上 cs 的论文标题是什么”），它会自己拆任务、搜索、抓网页、跑 Python 验证，最后输出 \boxed{答案}。底子是经典 ReAct：每回合 LLM 思考 + 工具调用，结果回写历史，循环 200~300 次直到收敛。 256K 上下文 + 单任务最多 300 次工具调用，对工程是不小挑战。运行时整体长这样： flowchart TD Task["task_description (用户问题)"] --> Loop subgraph Loop ["Orchestrator 主循环 (≤200/300 turns)"] direction TB For["for turn in 1..max_turns:"] S1["① LLM 思考 → tool_call"] S2["② ToolManager → MCP Server (search / python / scrape / ...)"] S3["③ keep_tool_result：裁剪远端工具结果"] S4["④ ensure_summary_context：token 预估刹车"] S5["⑤ rollback / 中间答案池"] For --> S1 --> S2 --> S3 --> S4 --> S5 end Loop --> Condition{"结束条件"} Condition -- "成功 \boxed{}" --> Success["输出最终答案"] Condition -- "跑满 / 上下文满" --> Failure["generate_failure_summary"] Failure --> Restart["重启 attempt（≤3 次）"] 下文按"护栏机制 → 工具层 → 上下文处理"三块展开。 ...