1. You Said No MCP (earendil.com)
Pi 对 MCP 支持的转变及其核心机制 Codemode
本文解释了 Pi 如何从最初明确拒绝支持 Model Context Protocol (MCP) 转变为将其纳入核心功能,并详细介绍了由此引入的关键机制——Codemode。
1. 为什么 Pi 改变了对 MCP 的立场?
Pi 团队之所以改变态度,主要基于以下原因:
- 协议的进化:MCP 协议本身在不断发展,不再是过去那个难以使用的协议。
- 从扩展到核心:虽然 MCP 可以作为插件运行,但将其纳入核心功能可以使 Pi 更容易实现某些功能(如 Jev 的集成),并允许 Pi 在协议演进过程中发挥影响力,而非仅仅作为旁观者。
- 解决组合性问题:传统的 MCP 存在难以进行工具组合(composition)的问题。许多 MCP 服务器倾向于返回纯文本以优化 token 效率,而 Pi 希望 MCP 能够像 OpenAPI 一样,通过文档进行智能发现并返回结构化数据。
2. 什么是 Codemode?
Codemode 是 Pi 引入的一个特殊机制,旨在解决工具调用的编排与协调问题。
- 运行环境:在执行工具时,通常分为“bash 运行端”和“harness 运行端(agent 循环端)”。Codemode 运行在受信任的 harness 端。
- 功能定位:它是一个沙盒环境,允许 Agent 使用 JavaScript 来灵活地组合和编排多个工具调用。这意味着 Agent 可以决定工具执行的顺序,并利用编程逻辑将不同工具的结果进行处理。
- 状态管理:Codemode 的状态维护在会话转录(session transcript)中,而不是文件系统中。
- 技术实现:使用 JavaScript(可通过 WASM 实现)既保证了灵活性,又提供了必要的保护。
3. MCP 与 Codemode 的协同效应
将 MCP 引入核心并结合 Codemode,解决了现代 LLM 在工具使用上的痛点:
- 适应新模型特性:现代模型支持延迟工具加载(deferred tool loading)和推理级别变化。Codemode 可以让工具被配置为仅在需要时加载,或仅作为 Codemode 特有的工具使用。
- 复杂的自动化流:通过 Codemode,用户可以编写逻辑复杂的任务。
实际应用示例: 文章通过一个案例展示了 Codemode 的强大功能:用户要求分析 Linear 任务追踪器中评论者的情绪。
- 工具组合:Codemode 同时调用了 Linear MCP(用于获取 Issue 和评论)和 Jev(一个分类模型)。
- 逻辑处理:通过 JavaScript 编写循环,遍历所有 Issue,提取评论,调用模型进行情绪判定(如:中立、轻微挫败、高度愤怒),最后汇总统计结果。
- 结果存储:判定结果直接存储在 Codemode 的上下文(如
frustration变量)中,方便后续直接追溯,无需重新获取数据。
总结
Pi 通过将 MCP 纳入核心并推出 Codemode,实现了从简单的“工具调用”向“复杂任务编排”的转变。这种架构不仅提升了工具的使用效率,还为构建高度自动化的 Agent 工作流提供了强大的编程能力。