Posts

原文： “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 四段各自只做一件事： ...