超越对话记录：有意设计上下文

你请 AI 智能体继续一项工作。这个简单请求背后，是不断积累的消息、工具定义、搜索结果、文件和决策。接下来应该让模型看到哪些内容？在 NanthAI，我们围绕这个问题做产品，已有数月。

亦发表于 [9][10].

Pi 及其母公司 Earendil 现在正通过 MCP 发现和 Codemode，为这个问题投入新的工程力量。他们近期的文章，对我们在 NanthAI 中一直推进的方向是一个受欢迎的补充。[1][2]

前两篇文章是详细的技术案例研究。这里，我们重温其中的核心思想，并结合 Pi 近期的工作探索下一层问题。出发点很简单：智能体能够访问的信息和能力，应远多于每次提示词中必须携带的内容。

我们在五月发表的文章奠定了基础。本文在此基础上对照探讨 Pi 的方法。

本文将这些思路联系起来：工具运行前加入什么，执行期间哪些内容到达模型，以及之后哪些内容仍有用。

对话在增长，负担也在增长。

简单的聊天应用通常会在每条新消息中附上此前的对话。加入工具后，结果也进入历史。加入集成后，每次请求还可能附带完整的工具目录。能力和历史都会让提示词增长。

亦发表于 [10].

基线方案回放累积的历史。NanthAI 从对话、记忆和可恢复的证据中准备上下文。

对话记录有明确目的：让人跟上交流过程。模型请求的目的则是提供模型当前行动所需的信息。这两种视图有重叠，但不必完全相同。用户可以保留可读的历史，同时由运行环境准备更聚焦的工作上下文。

NanthAI 将可读对话与其背后的证据和运行时状态分开。原始产物保留工具结果。精简记忆携带有用信息及其来源引用。上下文组装为下一次请求选择适当材料。

亦发表于 [10].

更大的上下文窗口和提示词缓存可以与这种架构配合。更大的窗口提供容量，缓存可降低重复前缀的费用，而上下文组装首先决定什么内容值得占用这些容量。这是一项信息设计选择，即使模型能力更强，仍然重要。

给智能体一个入口。

亦发表于 [9].

技能是可发现的工作流知识包。简短描述帮助模型识别何时使用它，完整指令说明如何完成工作。工具则是可执行的操作：搜索、读取、计算、创建或更新。一个技能可能需要多个工具，多个技能也可以共享同一工具配置组。

在 NanthAI 中，加载技能会引入工作流指令，并启用所需的工具配置组。技能将任务与执行所需的指导和能力联系起来。

设想一个研究报告请求。目录让智能体获得足够的信息，来发现合适的技能。加载技能会引入研究流程及其所需能力。如果后续工作需要其他能力，另一个技能可以扩展当前工具集。模型一开始就有办法找到所需内容。

NanthAI 使用技能启用指导和工具配置组。Pi 在技能之外增加了单个 MCP 工具的发现机制。

Pi 通过精简的服务器描述、工具搜索和检查来实现 MCP 发现。智能体发现单独的声明后，可以通过 Codemode 使用它们，或启用工具进行直接调用。Pi 也支持按需加载指令的技能。[3][5]

因此，比较不只是问谁会延迟加载工具。NanthAI 将工作流知识与工具组明确关联。Pi 的 MCP 发现让智能体能在单个工具之间作更精细的选择。两者都将“知道某项能力存在”与“加载其完整细节”分开。

亦发表于 [9].

“工具记忆”应能回溯到证据。

亦发表于 [10].

工具产物是执行记录：请求了什么，返回了什么，包括文件或错误。工具记忆是对记录中有用证据的较小表示，带有指向来源的链接。上下文组装选择哪些消息、记忆、引用和精确细节进入下一次生成。

对话记录、产物、记忆和组装后的上下文各有用途，来源引用将它们联系起来。

假设工具生成一份 CSV，智能体解释了结果。下一轮模型可能只需要结论和文件引用。之后，用户要求查看某个数字对应的精确行。精简记忆给系统提供了返回原始产物的路径。摘要之所以有用，是因为证据仍可恢复。

这种区分也有助于处理时间。日历空闲情况可能很快过时，生成文件的标识则可能长期有用。因此，工具记忆携带时效和溯源信息。组装器可以区分当前证据和旧观察，而不会仅因为两者都在对话中，就将它们视为同等权威。

亦发表于 [10].

保留证据，选择传递的内容。

工具一旦运行，上下文问题就会改变形态。搜索或 API 调用可能返回数百条记录，但回答只需少量事实。Pi 的 Codemode 在这里提供了尤其有用的对照。

MCP 为工具连接智能体提供统一方式。智能体如何将工具呈现给模型，则是另一项设计选择。Earendil 的 MCP 文章和 The New Stack 的报道具体说明了这种区别：一项集成可以处于可用状态，却不必从一开始就让每个模式定义占据提示词。[1][2]

智能体编写 JavaScript，调用工具、连接或筛选回复，再输出选定内容。中间值可以保留在脚本内，因此模型无需接收每个完整回复，也能继续推进计算。[4]

Pi 可以在一次操作内部精简中间回复。NanthAI 跨请求选择并复用证据。

亦发表于 [10].

区别在于介入环节。Codemode 可以在中间数据首次到达模型前将其精简。我们的记忆和组装机制决定哪些内容带入后续请求。NanthAI 的专用工具已经在内部处理数据；通用工具循环则返回每个工具产生的载荷。

这些是在同一信息流不同阶段使用的相关技术。Pi 的贡献为我们提供了另一个审视该信息流的有用位置。

这也说明，单凭并行调用无法概括 Codemode 的价值。并行执行可以同时获取多个结果，随后通过程序处理合并这些结果，只输出回答所需的证据。它既改变模型收到什么，也改变调用如何组织。

一份报告，三次上下文决策。

设想请智能体比较两份销售导出数据，并解释哪些客户的变化最大。最终报告需要客户名称、有意义的差异和支持证据。工作流可能接触的行数，远多于报告所包含的行数。

执行前，NanthAI 可以加载相关分析技能并启用其工具。这就是第一篇文章中的能力选择问题。无关的日历或消息指令无需随分析一同进入。

用报告说明三次上下文决策。每列展示相应方法中的一种机制。

执行期间，Codemode 脚本可以通过工具读取两个数据集，按客户连接记录，计算变化，并返回最大的差异。这展示了 Pi 增加的机制：用代码表达多个数据处理步骤，并选择模型接收的输出。[4]

之后，NanthAI 的上下文架构可以保留产物，并将有用的工具记忆带入后续请求。用户要求修改报告时，选定的上下文和来源引用帮助继续工作。任务需要时，可以恢复精确证据。

随着近期的本地运行环境更新，这种分工已经成为产品的一部分。NanthAI 可以将工作派发到 Mac 上已连接的运行环境，包括 Pi。NanthAI 组装相关对话、分支、记忆和产物上下文；Pi 将这些准备好的上下文与自己的运行时指令和工具结合，运行智能体循环，并调用所配置的 LLM 提供商。

NanthAI 准备上下文；Pi 在已连接的 Mac 上运行，调用其配置的 LLM 提供商。回答返回同一段对话。

回到销售报告：在 NanthAI 中请求比较，已连接的 Pi 运行环境就能使用 NanthAI 准备的上下文执行分析。回答返回同一段对话。继续追问时，NanthAI 为下一轮准备相关上下文，运行环境负责执行。我们在上下文组装上的投入，与本地运行环境的能力，就这样汇入同一个工作流。

工作继续，上下文随行。

亦发表于 [10].

当人们比较模型、恢复任务或更换执行环境时，这一点很重要。NanthAI 的共享准备过程汇集相关对话分支、摘要、近期消息、记忆和产物证据。同一套规范准备流程支持云端和本地轮次。

NanthAI 为不同执行路径准备共享上下文。各路径保留自己的工具能力。

设想一场规划对话中的两个分支。一个探索保守预算，另一个制定更进取的方案。各自可能生成不同的电子表格。下一次请求应该使用与用户正在继续的分支关联的文件和假设。对话中最新的文件，不会自动就是正确的文件。

Pi 也通过会话、分支和压缩来保持连续性。Earendil 的 Pi Durable 文章将其工作扩展到带检查点的执行与恢复。[6] 它的上下文和执行设计，应当按其自身的思路来理解。

NanthAI 将共享上下文带入跨客户端、模型和执行路径的产品，其中也包括 Pi 本身。执行引擎可以管理自己的工作会话，同时由 NanthAI 维护共享记录。这就是我们五月所述分离设计的实际价值：工作可以超越任何单一模型会话继续进行。

亦发表于 [10].

为下一个有用步骤构建上下文。

我们五月的文章确立了两个相关原则：逐步呈现能力，有意组装有用历史。Pi 近期的工作带来了另一个有力的实现视角，尤其在工具发现和对工具输出进行计算方面。

共同的问题是：智能体要完成有用工作，必须携带多少信息。各方法在选择什么、何时选择、由系统哪一部分负责决策上有所不同。

侧重点比较：逐步呈现能力、选择性结果，以及工作的连续性。

Cloudflare 和 Anthropic 也发表过关于通过代码执行来调用工具的研究。[7][8] 我们欢迎这个问题受到的关注和工程投入。比较可运行的设计，并借鉴各团队的不同选择，确有价值。

对 NanthAI 而言，这是我们在技能、工具记忆和组装上下文方面持续投入的延续。我们仍然关注这些基础带来的体验：选择想用的模型，让合适的能力触手可及，并让有用的工作成果可供下一步使用。

用 NanthAI 让更好的上下文发挥作用

在 NanthAI 中，这些架构选择成为一个工作空间：选择模型，用技能塑造工作流，处理文件，并在有用上下文随时可用的情况下继续工作。

用一个模型起草，获取另一个视角，再决定对话下一步往哪里走。探索一个分支，同时保留原来的方向。将 Mac 上受支持的 Pi 或 Codex 工作带入手机和浏览器中使用的同一批对话。

我们已为这种体验的基础投入数月。看到 Pi、Earendil 和其他团队为同一问题投入力量和想法，令人鼓舞。围绕更好上下文的工程讨论正变得更加丰富，我们也很高兴能贡献一个可运行的产品及其背后的思考。

以合适的价格，使用你需要的 AI

探索 NanthAI

文章与来源

1. The New Stack: One MCP server used 18,000 tokens before doing anything
2. Earendil: You Said No MCP!（2026年9月29日）
3. Pi documentation: MCP servers and tool exposure
4. Pi documentation: Codemode
5. Pi source: Skills and progressive disclosure
6. Earendil: Pi Durable（2026年10月1日）
7. Cloudflare: Code Mode: the better way to use MCP
8. Anthropic: Code execution with MCP
9. NanthAI: Skills as Tool Gates（2026年5月11日）
10. NanthAI: The Transcript Trap（2026年5月15日）

Pi 标志来自官方 Pi 媒体资料包。技术比较依据 2026年10月审阅的源代码和文档。

亦发表于 LinkedIn.