企业官网建设流程全解析

上个星期我还在远程终端里跑一个数据迁移任务，进度条走了将近四十分钟，结果笔记本合盖断网，再连上去的时候，整个会话连同编程代理的工作记忆一起归零。那种感觉用过终端编程代理的人应该都懂。昨天看到 Pi 1.0 正式发布的消息，核心变化就两个：原生支持 MCP，以及内置了名为 Pi Durable 的持久化执行机制。这两个词单看都不新鲜，但组合在一起，正好解决了我上面这个场景——长任务中断、上下文丢失、重跑一遍的噩梦。

这篇文章我会从一个实际使用者的角度，把 Pi 1.0 这次升级掰开揉碎：先说清楚终端编程代理在现代开发环境里到底卡在哪，再讲原生 MCP 接入和 Pi Durable 分别解决了什么问题、底层是怎么实现的，最后附上完整的迁移配置流程、一周实测踩坑记录，以及几组值得直接抄的组合用法。

1. 从"一次性指令执行"到"可持续的编程代理"：Pi 1.0要解决的问题

1.1 终端是最后一块还没被好好治理的地盘

过去几年，AI 编程助手基本都长在编辑器里。代码补全、选中代码解释、生成单测，这类场景在 IDE 插件里体验确实不错。但真实开发里有一大块工作根本不在编辑器内发生：SSH 登上服务器排查问题、进容器里看日志、在 CI 机器上跑批量脚本、在无图形界面的环境里改配置。这些场景恰恰是 IDE 插件覆盖不到的，而终端编程代理天生就是为了填补这个空档。

终端编程代理和我说的 IDE 插件有本质区别。它的工作单位不是"补全几行代码"，而是"理解一整段自然语言目标，然后在终端里自主执行一系列命令"。比如你告诉它"在项目里找到所有超时配置过短的 HTTP 调用，逐一修复，然后跑一遍相关测试"，它需要自己完成搜索文件、阅读代码、修改内容、执行测试、根据失败结果继续调整这一整条链路。这就对代理的"记忆能力"和"执行可靠性"提出了远比代码补全更高的要求。

Pi 就是冲着这个定位去的。它不是一个挂在编辑器侧边栏的工具，而是常驻在终端里、以命令行对话方式工作的编程代理。这次 1.0 版本把 MCP 和 Durable 同时放进来，我认为本质上是把终端代理从"一个能帮你敲命令的聊天机器人"升级成了"一个能独立负责长任务的执行体"。前者是玩具，后者才是能放进生产流程的东西。

1.2 旧版 Pi 的痛点：一次会话一次生命

旧版 Pi 在我个人使用中最难受的地方，不是模型能力不够，而是"生命周期太短"。它的记忆只存在于一次会话进程里。终端断线、进程被杀、机器重启，代理对之前做过什么、改过哪些文件、测试跑到哪一步，全部失忆。

这导致两个很现实的后果。第一，任务不敢拉长。凡是可能要跑十几分钟以上的活，我都得在旁边盯着，生怕中途网络抖动。第二，出错了只能整体重来。比如一个任务分五个阶段，第四阶段因为某个环境变量写错失败了，修复环境之后理想情况是从第四阶段继续，但旧版只能从头再跑一遍。跑一遍半小时，重跑一遍又是半小时，中间的 API 调用费用和时间成本都翻倍。

长任务场景下，编程代理和普通聊天工具的最大区别就在这里。普通对话丢了一次，重新问一遍就行；但编程代理执行的是有副作用的行为，它可能已经改了文件、跑了构建、提交了变更。如果这些行为不能被记录和恢复，那代理的"自主性"就是空谈。这也是我一直觉得很多号称"AI 程序员"的产品只敢做短任务的根本原因——不是模型笨，是执行层缺少持久化能力。

1.3 "原生MCP + Pi Durable"的组合效应是什么

单看"MCP 支持"和"持久化执行"，都有其他工具做过类似的事。但 Pi 1.0 把它们做成了一个咬合紧密的组合，这才是这次升级真正值钱的地方。

原生 MCP 解决的是"手和脚"的问题。终端代理不能再靠内置的那几个文件操作、命令执行工具包打天下，它需要接入代码托管平台、浏览器自动化、数据库查询、云平台 API 等各种外部能力。MCP 给它提供了一个标准插槽，让这些外部能力可以即插即用。

Pi Durable 解决的是"记忆和生命"的问题。它把一次执行从"进程活着才有记忆"改成了"每一步都被持久化，即使进程没了也能重建上下文"。这两者一旦组合，终端代理才真正具备完成跨小时级、跨会话级任务的条件。用一句话概括的话：MCP 让代理能做的事情变多了，Durable 让这些多出来的事做了一半也不怕丢，两者叠加才是一个可靠的全能执行体。

2. 换个角度理解原生 MCP：Agent的"外设接口统一了"

2.1 MCP在代理架构里的位置：不是插件系统，是标准协议

MCP 全称是 Model Context Protocol，是一套开放标准。它定义了 AI 应用（作为客户端）和外部工具提供方（作为服务端）之间的通信方式。你可以把它理解成 AI 世界的 USB-C：以前代理想接一个代码库工具，要单独写一套适配；想接一个浏览器工具，又要写另一套适配。现在只要双方都实现 MCP，插上就能通信。

在 Pi 1.0 里，Pi 本身就是 MCP 客户端，各种外部能力则是 MCP 服务端。它们之间的核心交互包括三类：工具调用、资源读取、提示模板。工具调用最常用，相当于代理调用外部能力；资源读取让代理能获取某个外部数据源的结构化内容；提示模板则提供了一些常用的指令模板，方便复用。

我自己理解 MCP 架构时用过一个类比，觉得挺贴切。过去旧版 Pi 的内部工具就像是一个人家里的固定电器，洗衣机、冰箱、电视都是装修时装死的，不能随便换。MCP 就是标准化的插座和接口。新买一个电器，只要插头符合标准，插上就能用。你不用拆墙改电路，电器厂家也不用知道你家插座具体长什么样。

2.2 原生接入和"适配器式接入"的差异：从胶水代码到声明式配置

旧版 Pi 也支持扩展工具，但那是"适配器式"的——如果你想接入一个外部服务，通常要写胶水代码：定义工具名称、描述入参出参、把外部 API 调用封装成 Pi 内部能理解的格式，甚至还要处理命令行参数怎么传、认证怎么过这些问题。每接一个服务，就要维护一段专属代码，服务端接口一变，适配代码也得出问题。

Pi 1.0 的原生 MCP 支持改变了这个模式。外部服务只要以 MCP Server 的形式运行，Pi 就能通过标准握手自动发现它的工具列表、参数结构、返回格式。使用者需要做的只是在一份配置文件里声明"我要连哪个 Server、通过什么命令启动它、带哪些环境变量"，剩下的发现、调用、错误处理全部由协议层完成。

我用下来最明显的感知是：接入新工具的边际成本降到了接近于零。旧版我接一个内部工具要花半天写适配代码，1.0 里基本上就是写好配置、启动服务、验证调用三步，前后不到半小时。而且因为工具描述由 Server 自己提供，代理理解的准确度高了不少，不再依赖我在胶水代码里手工描述的字段是否周全。

2.3 配置三件套：server列表、工具白名单、授权策略

下面是一份 Pi 1.0 的实际配置示例，它声明了三个 MCP Server 的接入：

{ "mcpServers": { "repo": { "command": "pi-mcp-repo", "args": ["--token-env", "REPO_TOKEN"], "env": {} }, "browser": { "command": "pi-mcp-browser", "args": [], "env": {} }, "fs-ops": { "command": "pi-mcp-fs", "args": ["--root", "/workspace"], "env": {} } } }

这份配置的关键在于启停由 Pi 统一管理。repo是代码托管平台操作服务，browser是浏览器自动化服务，fs-ops是一个限定在/workspace目录内的文件操作服务。注意最后这个fs-ops，它把可操作范围卡死在指定目录里，这在多项目环境下非常有用，避免代理顺手改到别的项目去。

配置完 Server 之后，还有一层工具白名单和授权策略。Pi 1.0 的默认策略是"全部列出，但高风险调用必须确认"。具体来说就是：工具可以发现，但调用时按风险分级处理，低风险工具（读文件、查状态）直接放行，中风险工具（修改文件、执行测试）在会话里确认一次，高风险工具（运行部署脚本、调用线上接口）每次都要求显式确认。

我的建议是不要偷懒用完全自动模式。特别是在接入浏览器自动化和代码托管平台服务这类能产生实际外部效应的工具时，白名单一定要配置清楚。否则代理在长任务执行中"自主"发出一条你根本没预想到的操作，风险是真实存在的。

2.4 为什么这能提升终端代理的可用性而不是增加复杂度

很多人担心，MCP 的引入会不会让终端代理变得更复杂。我的体感恰恰相反。复杂度在旧版是分散在各个适配器代码里的，你看不见，但一旦要接入新服务，复杂度就会爆出来；而在 1.0 里，复杂度被协议标准化了，表面的东西只剩下配置和授权两件事。

这种标准化还带来一个额外好处：MCP Server 是可以复用的。同一个 MCP Server，不仅 Pi 能用，任何支持 MCP 的客户端都能用。也就是说，我为某个内部平台写好的 MCP 工具，换到别的 AI 编程工具里也能直接接，不用重新适配。这对团队来说很香，工具链的投资一次到位，不再被绑定在某一个 AI 工具上。

3. Pi Durable：把"记忆"从进程里搬到磁盘上，再从磁盘搬进可恢复的工作流

3.1 长任务在终端代理中为什么会死：不只是进程被杀

旧架构里，终端代理的工作记忆完全是内存态的。你可能会觉得，进程崩溃只要不杀掉，记忆就还在。但实际场景哪有这么简单。SSH 断线可能导致会话链路整个重建；笔记本电脑休眠再唤醒，终端的伪终端状态已经切换；机器重启就更不用说了。就算一切都正常，长时间运行的任务还面临上下文窗口膨胀的问题——早期步骤的内容太多，后面步骤的可用上下文被挤占，代理开始"忘记"自己最初定下的约束条件。

这些问题的共同根源是：代理把"执行状态"放在了一个易失的地方。进程不是状态的可靠载体，终端里的进程更是如此。Pi Durable 对这个问题的回答很直接：把执行状态持久化到磁盘，并且设计成任何一步中断之后都能从持久化的记录里恢复。

用工程师的话说，就是把"内存态的单片执行"改成了"日志驱动的可恢复执行"。用生活的话说，就像写长篇连载之前先建立一个大纲和章节目录，写到第几章、哪条故事线开了头、哪个人物已经出场，都记录在案。哪怕写一半电脑坏了，换台电脑打开大纲，还能从最后一章接着写，而不是从头脑暴。

3.2 Durable的核心机制：事件日志、检查点、重放

Pi Durable 的具体实现思路，可以从三个关键词展开：事件日志、检查点、重放。

事件日志是这个机制的地基。Pi 在执行一个任务时，会把重要的步骤和结果追加写入持久化存储。每一条日志记录大概包括：步骤编号、步骤目标、使用的工具、传入参数、返回摘要、执行状态。这个日志不是给人看的 JSON 串，而是后续恢复动作的输入材料。

检查点则负责"把状态凝固下来"。日志可以告诉你发生过什么，但恢复时如果每次都从头重放，那就退化成重跑一遍了。所以 Pi 会在关键边界上做状态快照，比如"所有文件已修改""第一批测试已通过""中间产物已生成"这些节点。遇到这样的节点，Pi 不只记录日志，还会把当前核心上下文、已完成的步骤编号、关键文件状态一并保存。

重放是恢复时的动作。当任务中断后重新启动，Pi 读取事件日志和检查点，先重建"任务进行到哪了"，再把那些已经完成且结果可复用的步骤跳过，从第一个未完成的步骤继续执行。这个"跳过"的准确性取决于后文要说的幂等性设计。

恢复过程在终端里的表现很直观。重跑之前，它会先输出一份摘要：已完成 7 个步骤、当前停在第 8 步、剩余 3 步，然后直接开始执行第 8 步。我第一次看到这个输出的时候，确实有一点"这不是科幻，这是工程"的踏实感。

3.3 幂等性：Durable和"简单重跑"的关键分水岭

如果不深入想，你可能会觉得持久化执行不就是"记日志、续跑"吗？但真正实现起来，最难的在于让每个可恢复的步骤都能安全地重复执行。如果某个步骤在崩溃前已经执行成功了，但执行结果没能写入日志——比如工具调用发出去了，返回结果还没落盘——恢复时重放这个步骤，就会产生重复副作用。

典型情况：代理在崩溃前已经通过代码托管平台 API 创建了一个合并请求，结果因为网络波动没有记录返回结果。恢复后代理以为这个步骤没做过，又创建了一次，于是出现两个内容一样的合并请求。要避免这种事情，Pi Durable 在内部强制了一把尺子：凡是进入事件日志的步骤，都需要具备幂等性。

幂等性的实现方式，简单来说就是"先查再写"或"唯一键去重"。创建合并请求之前，先查询相同描述的请求是否已存在，存在就直接用已有的；修改文件之前，先记录文件当前哈希，应用补丁后把新哈希写进日志，恢复时对比哈希就能判断这个文件到底改没改过；执行测试之前，先检查测试输出缓存，如果发现关键参数相同的测试已经通过，就跳过重跑。

这给我一个明确启发：Durable 好不好用，不能只看"断点续跑"的字面能力，更要看它有没有把副作用管住。一个会在重放时重复发请求、重复建资源的持久化机制，还不如老老实实重跑一遍。

3.4 恢复的表现：断网、退出、机器重启三种场景实测

为了验证 Durable 的真实效果，我特意模拟了三种中断场景。

第一种是断网。我在一个跑批任务进行中直接断开网络，Pi 等待片刻后显示连接中断，进程挂起。重新连接后，任务在 Pi Durable 的恢复模式下自动重建上下文，从断开前的最后一步继续。这里注意，断网恢复通常不丢步骤，因为日志写入是局域网级别的操作，不依赖远端网络。

第二种是退出进程。我用kill直接杀掉 Pi 进程，模拟最粗暴的破坏。重启 Pi 后输入恢复命令，它找到未完成的持久化任务，输出已完成步骤清单，然后继续。这个场景我认为才是 Durable 的本命场景——一个代理不应该因为自己所在进程死了就失去工作能力。

第三种是机器重启。这个更接近我开头说的"合盖断网"场景。重启后我重新登录终端，Pi 通过本地持久化存储找到了之前的任务记录。由于我配置的任务使用本地 SQLite 存储，恢复过程很顺畅。需要说明的是，如果任务涉及的外部状态本身丢失了，比如临时文件被清理，恢复后还是需要代理重新生成这些依赖，这属于正常行为。

4. 1.0实操：从旧版本迁到 Pi 1.0并接入外部工具链

4.1 迁移前后的行为差异：配置格式和工具发现逻辑

我从 0.9 升到 1.0 的过程不算复杂，但有几个点值得提前知道。第一个差异是配置格式。旧版里对扩展工具的配置分散在多个文件里，1.0 统一收拢成了上面提到的mcpServers结构。第二差异是工具发现逻辑。旧版工具是"启动时加载插件列表"，1.0 变成"启动时通过 MCP 握手发现工具列表"，这意味着 MCP Server 必须在 Pi 启动时能够正常访问，否则对应工具不会出现在列表里。

升级前建议把旧版的适配器代码备份一份。1.0 虽然能兼容部分旧配置，但那些曾经通过硬编码方式接入的外部服务，还是需要改写成 MCP Server 格式才能享受到原生接入的好处。如果没有历史包袱，全新装机反而更省事。

4.2 配置一个MCP Server的完整流程：注册、验证、调用

下面是接入一个代码托管平台 MCP Server 的完整流程，我演示的是最常用的路径。

第一步，安装 Server 可执行文件。以示例中的pi-mcp-repo为例，这个命令把外部代码托管平台的操作能力封装成了 MCP 服务，安装好后直接用repo这个标识在配置里引用。

第二步，在 Pi 的配置文件里写入声明：

{ "mcpServers": { "repo": { "command": "pi-mcp-repo", "args": ["--token-env", "REPO_TOKEN"], "env": {}, "permissions": { "default": "confirm", "allow": ["repo.get_file", "repo.search_code"], "deny": ["repo.delete_branch"] } } } }

这里的permissions字段很关键。我把它设为：读类操作放行，写类操作需要确认，删分支之类的危险操作直接拒绝。--token-env表示令牌从环境变量REPO_TOKEN读取，而不是写在配置里，避免敏感信息泄露。

第三步，在 Pi 里执行校验命令，确认 Server 握手成功、工具列表加载正常。模拟输出如下：

$ pi mcp list > repo [connected] 19 tools > repo.get_file > repo.list_branches > repo.search_code ... > browser [connected] 8 tools

第四步，做一次真实调用测试，比如pi mcp call repo.list_branches --project pi-demo，确认返回数据格式符合预期。这一步有必要，因为有些 MCP Server 工具名看着正常，实际返回结构却很怪，提前发现比任务跑起来再发现好得多。

4.3 开启一个Durable任务：把"重构+测试"的任务完整跑到底

配置好 MCP 之后，我体验了一下真正结合 Durable 的完整任务。我给了它一个初始指令，用一句话描述：对某个模块的会话管理逻辑进行重构，保持接口不变，补充原有缺失的超时处理，最后运行整个模块的测试并输出结论。

Pi 把任务拆成了下面这样：

1. 读取模块目录结构，定位会话管理相关文件；
2. 查阅这几个文件的当前实现和已有测试；
3. 通过repo.search_code在代码库里搜索超时相关的调用点；
4. 生成变更方案并与我确认；
5. 执行文件修改；
6. 补充针对超时处理的测试用例；
7. 运行模块测试；
8. 根据失败结果反复调整直至通过。

整个任务跑了大约二十分钟。我在第 5 步和第 6 步之间故意杀掉 Pi 进程，重启后执行恢复命令，它从第 6 步"补充测试用例"继续，而不是重跑前面的搜索和修改。最终完成后，Pi 在界面上输出了一份步骤回放，看起来像是分阶段验收报告。这种"二十分钟的任务，中断后不重来"的体验，放在一周前我完全不敢想。

4.4 权限控制与多环境隔离的推荐做法

长期使用下来，我觉得权限控制不能清一色套同一个模板，针对不同环境要有不同策略。我整理了一张适合参考的配置表：

CI/容器环境是重点。没有人在终端前帮 Pi 做确认，如果白名单没设好，任务又恰好停在需要确认的步骤上，就可能一直阻塞。我在自己的设计里选择一个"受控自动确认"方案：只对白名单内工具自动放行，白名单外一律取消任务等待人工介入。这样既能保证无人值守进度，又不会在服务器上乱来。

数据库的部署上，我选择把 Durable 存储放在本地目录，因为它恢复速度最快，也不存在网络依赖。如果你有跨机器恢复的需求，可以把持久化存储指向共享位置，但要注意随之而来的并发访问和权限问题。

5. 一周实测中我踩过的坑

5.1 MCP工具返回数据太大，把上下文塞爆

接入 MCP Server 后我遇到的第一个问题不是连不上，而是"数据太多"。某个代码搜索工具默认返回了包含上千条匹配结果的完整 JSON，Pi 一次性把响应塞进上下文，结果后续指令的理解质量明显下降。这个问题在 MCP 场景下比旧版更常见，因为外部工具返回的数据结构完全不由 Pi 控制。

解决办法有两个层面。第一是写配置时尽量选择支持分页或摘要模式的服务端，工具调用时主动要求"只返回前 50 条摘要"。第二是在 Pi 的配置里开启响应截断，让代理先看到返回结果的骨架和摘要，等真正需要细节时再通过另一个工具调用按需读取。这个"按需读取"的思路，本质上和人类看一个超大日志文件的策略一样，先 grep 再 head，而不是直接把整个文件塞进脑子里。

5.2 Durable重放时副作用重复执行

前一节提到的"合并请求重复创建"问题，我实际也遇到一次。起因是我接入的某个外部平台 MCP Server 的创建接口不支持幂等键，Pi 本身无法判断"平台是否已经因为上一次调用而创建了资源"。恢复后它重新执行创建操作，结果就是一个合并请求变成两个。

根治方案是在 MCP Server 侧改造工具，为创建类操作加上"先查再写"的逻辑：创建前按标题和源分支查询是否已有相同的请求，有就直接返回已有结果。如果你的 MCP Server 不受自己控制、没法改，那就只能在权限配置里把这类工具标记为"非幂等工具"，让 Pi 在恢复时对这类工具采取保守策略——宁可停下来问一句，也不要自动重试。

复制代码块：

# 我自己的幂等包装思路（伪代码） def idempotent_create(params): existing = query_merge_request(params.title, params.source_branch) if existing: return existing.id, "already_exists" return create_merge_request(params)

5.3 终端非交互场景下的授权确认问题

这个问题容易被忽略：Pi 的授权确认交互依赖终端 TUI，但 Durable 恢复很多时候发生在非交互环境里。比如我的一个定时任务在后台模式下运行到某个需要确认的步骤，然后挂起等待我的确认——我直到第二天看日志才发现它卡住了。

后来我摸索出一个稳妥方案：非交互模式下绝不使用宽泛的确认策略，所有挂起确认必须配置超时决策。具体来说，我把需要确认的步骤分成两类：低风险但需要确认的（默认超时后拒绝并终止任务）、高风险需要人工介入的（保持阻塞并发送通知提醒）。这样任务不会无声无息地挂一夜，而是要么快速失败，要么明确提醒等待处理。

5.4 恢复后的上下文"错位"问题

还有一个比较隐蔽的问题，我第一次遇到时困惑了很久。任务恢复后，Pi 确实记得"这个任务的目标是什么、做到哪一步"，但它对当时环境的状态感知可能已经过时。比如我昨天在某个分支上跑到第 4 步，今天恢复时当前分支已经切走了，它却还按旧分支的印象继续推理。

解决方式需要 Pi 自身带一点"恢复强制校验"的逻辑。现在我的做法是给每个 Durable 任务起手就固定环境快照：记录起始分支、关键环境变量、依赖版本。恢复时 Pi 会先跑一遍快照校验，不一致就停下来重新校准，不硬着头皮继续。这个习惯很重要，否则 Durable 恢复的是"记忆"，而不是"环境"。

5.5 审计日志比你想的更有用

最后说一个不算坑但很受益的小习惯：每个 Durable 任务我都会打开审计日志。它会把每个步骤的输入输出、工具调用参数、耗时都记录下来。平时可能用不上，但一旦出现"任务结论和实际后果对不上"的情况，这份审计日志就是定位问题的线索来源。我甚至通过审计日志发现过一次 MCP Server 的令牌过期导致调用失败，而任务报告里的报错信息模糊不清，光看任务日志根本看不出来。

6. 值得直接尝试的组合与后续思路

6.1 组合一：CI日志排查加自动化修复

这是我目前用得最舒服的一个场景。过去 CI 挂了，要么自己登录机器翻日志，要么在平台页面上一层层点。现在我把日志获取、代码搜索、浏览器自动化三个 MCP Server 接进 Pi，配一个 Durable 任务，让它去下载失败日志、定位错误堆栈、在代码库里搜相关逻辑、生成修复建议，甚至直接提交一个修复分支。

这个任务通常在 10 到 20 分钟之间，过程中可能有长时间等待。以前这种任务我不敢放手，现在有了 Durable，我完全可以先去做别的事，回来再看它执行结束的报告。即使中途断网，恢复后它也能接着跑。

6.2 组合二：周期性的代码状态巡检

Durable 任务不局限于单次对话，它本质上是一个可以被多次唤醒的"工作流存根"。我基于这个能力做了一个每周一次的代码状态巡检任务：检查未合并的分支数量、扫描最近提交里的高风险改动模式、检查依赖库有无安全更新，最后生成本周巡检摘要。

这个任务入口被放在定时调度里，每周跑一次。由于它每一步都有持久化记录，就算某一次调度时机器关机了，下周开机后也能恢复执行。这种"没跑完的任务不会凭空消失"的确定性，是以前常规脚本任务给不了我的。

6.3 后续值得关注的方向：多人协作与更细的重放控制

从 1.0 现在的设计看，Pi Durable 已经把"单进程任务可恢复"这件事做得比较扎实。再往后走，我觉得最值得期待的是两个方向。一个是多人协作：如果同一个持久化任务可以被多个开发者共同观察、暂停、接管，那它就是一个小型的人工智能工作流系统。另一个是更细粒度的重放控制：目前恢复默认从一个未完成步骤继续，未来如果能做到"只重放失败步骤”“保留已完成实验性改动”，对于长周期、多试探型任务会更有价值。

不过说实话，作为第一天的使用者，这些想法更多是一种期待。眼下真正让我满意的，是 Pi 1.0 把两个方向都做成了默认能力，而不是停留在概念里。一个能接外部工具的终端代理不难见到，一个能断点续跑的终端代理也不难见到，但能让这两件事在同一套体系里自然协同的，确实是第一次。

如果你也准备尝鲜，个人建议别从玩具任务开始，直接挑一个真实场景里至少要跑十几分钟的工作流，配上两到三个 MCP Server，再故意中断它一次。你会直观感受到"断点续跑"这四个字的分量。我自己试用下来，最大的体会是：终端编程代理的可靠边界正在被重新定义，而这次升级把"崩溃后重来"变成了"崩溃后继续"——这个转变，比任何模型能力的提升都更能让我放心地把任务交给它。