你好，我是Simon Sun

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

本文由 AI 撰写，仅用于学习和理解 Raft 源码。从一条频道消息出发，跟踪 Agent 的身份、执行过程、文件记忆、任务协作和凭据边界。

本文仅用于学习和了解新项目，正文由 AI 撰写。 同一个大模型，换一套提示词、工具说明、上下文压缩和错误恢复逻辑，完成任务的能力就可能明显不同。这些围绕模型的程序与配置，通常被叫作 Agent 的 Harness。 既然 Harness 可以由人修改，也可以让另一个 Agent 读失败记录、改代码、跑评测，反复寻找更好的版本。但这里有一个熟悉的陷阱：如果每轮都拿同一批题挑赢家，系统可能学会的是这批题的答案，而不是可复用的做事方法。 RRSI: Regularized Recursive Self-Improvement of Agent Harnesses 研究的就是这个问题。它保持底座模型权重不变，让系统自动修改 Harness，同时约束“提出改动”和“接受改动”两个环节，目标是让提升能迁移到没参加演化的任务。论文于 2026 年 9 月 21 日发布，目前是 arXiv 预印本。 先弄清楚：它在改什么 这里的“递归自我改进”不是模型自己训练出一组新权重。论文中的改进对象是模型外面的 Harness，包括提示词、控制流程、工具、技能、记忆、子 Agent 和上下文管理。 一个普通的自动演化循环可以写成： 1 2 3 4 5 6 当前 Harness → 在一批任务上运行，收集失败轨迹 → 让 LLM 提出几个代码或配置改动 → 用同一批任务给候选版本打分 → 保留分数最高的版本 → 下一轮继续 问题出在“同一批任务”被反复使用。候选改动、失败分析和下一轮提案都看过前几轮的反馈；即使评测脚本没有泄露答案，搜索过程也在持续适应这份有限的题集。一个专门识别某类题面、不断追加提醒、或者在某个评分器前写出讨喜格式的 Harness，可能越考越高，却不能帮助新的任务。 论文把演化时反复使用的任务称为 evolve set。它还区分两种没参与调参的测试：同一基准里的留出任务（ID held-out），以及任务形式或评分方式不同的其他基准（OOD）。真正值得看的不是 evolve set 提升多少，而是离开这批题后还剩多少。 ...

本文仅用于学习和了解新项目，正文由 AI 撰写。 写一个能调用大模型和工具的 Agent 并不难，难的是让一万个 Agent 安全、稳定、便宜地跑起来。 本地演示里，Agent 往往只是一个 Python 或 TypeScript 进程：读提示词、调用模型、执行工具、输出结果。但进入生产环境后，问题很快会变成：代码应该在哪运行？它能访问哪些仓库和网站？闲置半小时还要不要占着一整台机器？进程被中断后能不能接着工作？怎样同时管理成千上万个执行中的 Agent？ Google AX 想解决的就是这一层问题。它把自己定义为一个面向 Agent 工作负载的声明式编排器：你提交一份类似 Kubernetes 清单的 YAML，AX 负责准备工作区、建立网络边界、启动隔离环境，并管理任务的暂停、恢复和销毁。 它不是教 Agent 如何推理的框架，也不是封装模型 API 的 SDK。更准确地说，Agent 框架负责“大脑”，AX 负责“工位、门禁和运行制度”。 本文基于 2026 年 9 月 22 日的 AX main 分支与项目官网撰写。项目接口仍是 v1alpha1，官方明确提醒稳定版之前可能有重大变更。 为什么 Agent 不是普通微服务 微服务通常持续监听请求，资源需求相对稳定；批处理任务则从头运行到尾，结束后退出。Agent 同时不太像这两者。 一个 Agent 可能先高强度运行几分钟，然后等待模型、外部工具或人工审批；它会修改文件、积累上下文和中间结果；它可能递归拆出子任务；它还会执行模型生成的代码，并访问网络。换句话说，Agent 往往同时具有四个特点： 有状态：工作区、进程和中间产物都可能影响下一步。 突发式计算：真正消耗 CPU 的时间不连续，大量时间在等待。 长生命周期：一次任务可能跨越数小时甚至数天。 高风险权限：它可能执行不可信代码、读取凭证、访问外部服务并持续花钱。 如果每个等待中的 Agent 都独占一个容器或虚拟机，资源利用率会很差；如果所有 Agent 又都挤在一个进程里，隔离、故障恢复和权限控制会变得非常困难。 AX 的判断是：Agent 需要一种新的调度单位。它应该像容器一样可以隔离，像进程一样轻量，还能在等待时保存状态并暂停。 四个原语：工单、工位、门禁和模型配置 AX 没有试图描述 Agent 的每一次思考，而是只提供四个基础资源。 ...

本文整理自与 ChatGPT 的一次讨论。问题是：Hermes Agent 这种、执行完 session 就触发创建 skill 的机制，真的好吗？下面按 NousResearch/hermes-agent 当前 main 上的实现来写。 自动从执行经验里长出 skill，这个方向是好的。Hermes 现在的默认机制偏激进。它不是「每次 session 跑完就总结成一条 skill」，但一次复杂经历仍然可以在没有复用验证的情况下，直接变成持久的程序性记忆。 它实际在什么时候动手 固定流程不是： 1 session end → create skill 更接近： 1 2 3 4 5 6 对话循环里的工具迭代累计 → _iters_since_skill >= creation_nudge_interval → 这一轮有最终回复，且没有被打断 → 主回复已经交付 → 后台 review agent 拿对话快照再看一遍 → 更新已有 skill / 加参考文件 / 新建 skill / 什么都不写 turn_finalizer.py 在回合收尾时检查： 1 2 3 agent._skill_nudge_interval > 0 and agent._iters_since_skill >= agent._skill_nudge_interval and "skill_manage" in agent.valid_tool_names 过线之后才 _spawn_background_review(..., review_skills=True)。还要同时满足：已经有 final_response、这轮没有被打断、没有 skip_background_review。cron 一类没有人在环里的运行会把后台 review 关掉。注释写明，review 放在交付之后，避免和用户正在等的任务抢资源。 ...

本文整理自与 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 文档 — 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。 ...