用ChatGPT会话驱动Pi：MCP与Computer Use实践

为什么需要“持久会话”？

AI 编码代理 Pi 的能力并不差，但真正影响使用体验的往往不是模型本身，而是会话之间的上下文断裂。每次重新开始对话，之前的工具配置、项目背景、正在推进的任务进度都会丢失，用户被迫反复复述同样的信息。

这一痛点并非 Pi 独有。围绕 AI 代理的“记忆”与“编排”，社区已经出现了多种思路：有的依赖长上下文窗口硬扛，有的靠 RAG 外部检索，有的则试图把会话本身变成一个可管理的对象。本文讨论的方案属于后者——通过 ChatGPT tasks 把离散的 Pi 会话组织成持续运行的流程，并用 MCP 工具和 Computer Use 补齐能力缺口。

需要补充的背景：什么是 AI 编码代理与 MCP？

AI 编码代理（Coding Agent）指的是能自主执行代码相关任务的智能系统，它不只是回答编程问题，还能读写文件、运行命令、调用外部服务，从而完成从需求到交付的闭环。这类代理的效果不仅取决于底层大模型的能力，还取决于它能否在多次交互中保持对项目和任务状态的正确理解。MCP（Model Context Protocol）是由 Anthropic 提出的一种开放协议，旨在统一大模型与外部工具、数据源之间的连接方式。开发者可以按 MCP 规范编写“工具服务器”，让模型以标准化接口调用文件系统、数据库、API 等资源。MCP 的出现降低了每个代理单独适配工具的成本，使工具生态具备可复用性，这也是本文方案能够把 Pi 与外部能力高效拼接的前提。

核心机制：ChatGPT tasks 作为会话编排层

该方案的出发点很直接：不把 Pi 当作一个“问答机器人”，而是当作一个需要被调度的长期工作者。ChatGPT tasks 在这里扮演编排层的角色，负责记录任务状态、触发新的 Pi 会话，并在会话之间传递必要的上下文。

这样做的价值在于把“上下文保持”从模型能力问题转化为工程问题。模型不需要记住一切，编排层负责在恰当的时候把恰当的信息喂进去。相比单纯依赖更大的上下文窗口，这种方式在长周期任务中更可控，也更容易调试——出问题时可以定位到具体是哪一次会话、哪一段上下文出了问题。

连接 MCP 工具：让 Pi 具备外部行动能力

MCP（Model Context Protocol）工具接入是这个方案的关键一环。Pi 本身擅长代码相关的推理，但要把推理落地为实际动作——读写文件、调用 API、操作外部服务——就需要 MCP 提供的工具接口。

你可能没注意到，工具接入的顺序和粒度会显著影响稳定性。如果一次性挂载过多工具，模型在选择时容易犹豫甚至误用；而工具过少又会导致任务无法闭环。实践中更稳妥的做法是按任务类型分组挂载，让每次会话面对的工具集保持精简。这一点与目前主流的 AI 代理工程经验一致：工具数量和质量同样重要。

需要补充的背景：工具选择中的“上下文税”

在 AI 代理工程中，每挂载一个工具，工具的名称、描述和参数模式都会占用模型的上下文窗口，这种开销常被称为“上下文税”。当工具数量膨胀时，模型需要在众多候选工具中进行选择，不仅消耗更多 token，还容易产生歧义或误调用；同时工具描述之间的语义重叠会进一步降低选择准确率。因此，业界逐渐形成“按需分组、动态加载”的实践：根据当前任务类型只暴露最相关的一小组工具，任务切换时再替换工具集。这与本文提到的“按任务类型分组挂载”思路一致，目的是在能力覆盖和选择稳定性之间取得平衡，而非追求工具数量最大化。

Computer Use 作为兜底桥梁

并非所有操作都有现成的 MCP 工具。原文提到的“bridge gaps with computer use”正是针对这类情况——当缺乏专用工具时，通过 Computer Use 直接操作图形界面来完成任务。

这是一种务实的取舍。Computer Use 的可靠性通常低于结构化工具调用，速度也更慢，但它的覆盖面几乎不受限制。把它当作兜底手段而非首选路径，可以在不牺牲稳定性的前提下扩展 Pi 的能力边界。判断标准很简单：有 MCP 工具就用工具，没有才退回到 Computer Use。

需要补充的背景：Computer Use 的工作原理与局限

Computer Use 是指让 AI 模型通过截图理解图形界面，并模拟鼠标点击、键盘输入等操作来完成任务的技术路径。它不依赖目标软件提供 API 或专用工具，因此理论上可以操作任何有图形界面的程序，覆盖面极广。但其局限也很明显：每一步操作都需要截屏、识别、决策、执行，循环链路长，导致速度慢；界面元素识别可能出错，弹窗、加载延迟、动态布局都会引入不确定性；此外，涉及敏感操作时还面临权限和安全风险。因此 Computer Use 更适合作为缺少结构化工具时的兜底手段，而不是日常首选。判断标准正如原文所述：有 MCP 工具就用工具，没有才退回到 Computer Use。

“不丢上下文地交付工作”意味着什么

原文强调的最终目标是 deliver work without losing context。这句话拆开来看包含两层要求：一是任务能真正完成并产出可交付结果，二是完成过程中积累的上下文不会在交付时蒸发。

第二点常被忽视。很多 AI 工作流的产出看似完成了，但过程信息散落在多次会话里，无法复用也无法审计。把会话组织成有状态的流程后，上下文本身成为资产——下一次类似任务可以站在上一次的肩膀上，而不是从零开始。

这套方案适合谁

这种编排思路更适合任务周期长、上下文依赖重的场景，比如持续维护一个代码仓库、跟踪一组需要反复调整的配置、或者处理涉及多个外部系统的流程。对于一问一答式的轻量需求，引入编排层反而增加复杂度。

从更宏观的角度看，这个案例反映的是 AI 代理领域的共同方向：模型能力之外，如何组织会话、连接工具、管理状态正在成为决定实际效果的关键变量。Pi 与 ChatGPT tasks 的组合只是一种具体实现，背后的编排思路具备更广的参考价值。