从提示词到上下文工程：大模型应用范式的根本性转变

1. 从“提示词”到“上下文工程”：大模型应用范式的根本性转变

如果你在过去两年里接触过大语言模型，那么“提示词工程”这个词对你来说一定不陌生。从最初的“请扮演一个专业的翻译”，到后来复杂的思维链（Chain-of-Thought）和少样本学习（Few-shot Learning），我们都在试图用一串精心设计的文本，去“撬动”模型，让它输出我们想要的结果。这就像是在一个黑盒子上不断敲打，试图找到那个能让它吐出正确答案的“神奇咒语”。

但到了2025年，特别是进入所谓的“智能体时代”，事情开始变得不一样了。我们逐渐发现，仅仅依靠一个静态的、预先写好的提示词，已经无法应对越来越复杂的任务。想象一下，你要让一个AI智能体帮你开发一个完整的软件项目，或者分析一份长达数百页的行业报告。这个智能体需要记住你们之前的对话、理解项目的整体架构、调用不同的工具（如代码编辑器、搜索引擎、数据库），并在长达数小时甚至数天的执行过程中保持状态。此时，你塞给模型的“上下文”，早已不是一句简单的指令，而是一个包含了历史对话、工具调用结果、项目文件、用户偏好、甚至外部API响应的、动态变化的庞大数据结构。

这就是“上下文工程”诞生的背景。它不再把与大模型的交互看作一次性的“提问-回答”，而是将其视为一个持续的、有状态的、需要精心编排的“系统级对话”。这个系统需要管理记忆、调度工具、处理外部信息，并确保智能体在复杂的多步任务中不迷失方向。我个人的体会是，如果说提示词工程是“如何问一个好问题”，那么上下文工程就是“如何为一次漫长的、协作式的探索，准备好一个持续更新的作战地图”。这个转变，标志着大模型应用从“玩具”走向“生产级工具”的关键一步。

2. 上下文工程的核心定义与理论框架

2.1 什么是“上下文”？

在传统的提示词工程中，上下文通常被狭义地理解为“用户输入的问题加上几个例子”。但在上下文工程的视角下，我们需要一个更精确、更工程化的定义。

上下文，指的是在模型推理时，提供给大语言模型的完整信息载荷。它不仅仅是你输入的那句话，而是包含了所有结构化的信息组件，这些组件共同构成了模型完成任务所需的“认知环境”。一个完整的上下文通常包括以下几个层次：

1. 系统指令与角色设定：这是模型的“宪法”和“人设”。它定义了智能体的核心行为准则、能力边界和对话风格。例如，“你是一个资深的Python后端开发专家，擅长使用FastAPI框架。你的回答应当简洁、专业，并优先考虑代码的可维护性和性能。”
2. 对话历史：这是短期记忆的载体。包含了当前会话中用户与模型之间所有轮次的交互记录。它让模型能够理解对话的脉络，进行连贯的交流。
3. 长期记忆/项目记忆：这是智能体的“知识库”或“工作空间”。它可以是从向量数据库检索的相关文档片段、之前任务中总结的要点、用户明确声明的偏好（如“我不喜欢用全局变量”），甚至是整个代码库的抽象表示。这部分内容是动态增长和演化的。
4. 工具调用规范与结果：当智能体需要与外部世界交互时（如执行代码、查询网络、操作文件），工具的定义、调用请求以及返回的结果，都必须作为上下文的一部分喂给模型，以便它基于结果进行下一步决策。
5. 当前任务指令与中间状态：即用户最新的请求，以及智能体为完成该请求而制定的计划、已执行的步骤、产生的中间产物等。

用一个简单的公式来理解：有效上下文 = 系统指令 + 压缩后的相关记忆 + 工具规范与历史 + 当前任务与计划状态

这里的“压缩”是关键。模型的上下文窗口（如128K、1M tokens）是有限的宝贵资源，你不能把所有的历史对话和文档都原封不动地塞进去。如何对海量信息进行摘要、提取、结构化，以最精炼的形式保留最关键的信息，正是上下文工程要解决的核心挑战之一。

2.2 上下文工程：从静态编排到动态系统

基于上述定义，上下文工程可以理解为：设计、构建和管理上述完整上下文信息流的系统性方法论、技术和架构。

它的目标不再是优化一个静态的字符串，而是构建一个能够动态感知、检索、组织、更新和呈现信息的“运行时引擎”。这个引擎需要决定：

• 记忆什么：哪些对话片段、工具结果或用户反馈值得被存入长期记忆？
• 如何存储：是用向量数据库、图数据库，还是简单的文本摘要？
• 何时检索：基于当前任务，应该从记忆中召回哪些相关信息？
• 如何呈现：召回的信息以何种格式、何种顺序、何种优先级插入到上下文中？
• 如何更新：新的交互如何影响已有的记忆结构？是否需要合并、修正或遗忘？

这个过程充满了权衡。例如，存储过于详细的记忆会占用大量上下文窗口，导致处理速度变慢、成本升高；而存储过于简略的记忆又可能导致关键细节丢失，影响任务完成的准确性。一个优秀的上下文工程方案，就是在信息丰度、计算成本、响应速度和任务成功率之间寻找最佳平衡点。

2.3 理论基础：贝叶斯上下文推断

从认知科学和机器学习的角度看，上下文工程可以部分地用贝叶斯推断的框架来理解。我们可以将大语言模型视为一个基于庞大训练数据先验分布的概率模型。当用户给出一个任务时，模型拥有一个非常宽泛的、通用的先验知识。

我们提供的上下文（指令、示例、相关文档），本质上是在为这个先验分布引入似然函数，从而将模型的后验分布“聚焦”到与当前任务高度相关的子空间上。高质量的上下文，就像提供了高精度的观测数据，能极大地降低模型推断的不确定性，使其输出更准确、更符合预期。

例如，当你只问“如何优化一个函数？”，模型的后验分布可能覆盖从算法复杂度、代码风格到硬件并行化等无数可能。但如果你在上下文中提供了具体的函数代码、性能剖析报告以及“目标是减少内存占用”的指令，那么模型的后验分布就会迅速收缩到与内存优化相关的具体模式上，从而给出更精准的建议。

因此，上下文工程的核心任务之一，就是设计能够最大化这个“似然函数”信息量的策略，即如何用最有效的信息组合，来最有力地“引导”模型的生成过程。

3. 为什么我们需要上下文工程？—— 静态提示的五大局限

理解了定义，我们再来深入看看，为什么传统的提示词工程在复杂场景下会“失灵”，从而催生了上下文工程。

3.1 信息承载的极限与“上下文污染”

大模型虽然有超长的上下文窗口（如Claude 3.5 Sonnet的200K，GPT-4o的128K），但这并不意味着你可以把一本百科全书丢进去然后指望它记住所有细节。模型对上下文中信息的处理存在“注意力稀释”和“位置偏见”问题。

• 注意力稀释：当上下文过长时，模型对中间部分信息的关注度会显著下降。研究表明，即使是在128K的窗口内，模型对开头和结尾部分的信息记忆和理解能力，也远强于中间部分。
• 位置偏见：模型倾向于更关注上下文开头（系统指令）和最近输入（最后几条消息）的信息。如果你把关键指令埋在冗长文档的中间，模型很可能会忽略它。

静态提示无法动态调整信息的位置和密度。而上下文工程中的上下文管理技术，如滑动窗口、关键信息重排、动态摘要等，就是为了对抗这些效应，确保关键信息始终处于模型的“注意力焦点”之内。

3.2 状态缺失与“失忆症”

这是智能体应用中最头疼的问题。一个多轮对话的智能体，如果没有记忆，那么每一轮对话都是孤立的。用户在第10轮说“把上面我们讨论的那个方案用Python实现一下”，如果模型不记得前9轮讨论的“那个方案”具体是什么，就会完全无法执行。

静态提示无法携带状态。你不可能在每一轮对话中都把之前所有的聊天记录重新粘贴一遍（很快就会超出token限制）。上下文工程通过引入记忆系统来解决这个问题，无论是简单的对话历史缓存，还是复杂的向量化记忆存储与检索，其目的都是让智能体拥有“持续的身份”和“连贯的认知”。

3.3 工具使用的协调困境

现代大模型智能体的核心能力之一是工具调用（Function Calling）。但工具调用不是一次性的。它可能涉及多步操作：查询数据库 -> 分析结果 -> 根据结果调用另一个API -> 格式化输出。每一步工具调用的输入和输出，都是下一步决策的关键依据。

静态提示无法优雅地处理这种链式或网状的依赖关系。上下文工程则将工具调用的规范、历史记录和结果，作为一等公民纳入上下文管理。它需要设计一套机制，来决定何时调用工具、如何将工具结果整合回对话流、以及当工具调用失败时如何优雅地降级或重试。

3.4 知识更新的滞后与“幻觉”

大语言模型的知识存在截止日期，且无法记住所有训练数据中的细节。当需要处理最新、最专有的信息时（如公司内部文档、今天的热点新闻），静态提示无能为力。

检索增强生成（RAG）正是上下文工程应对这一挑战的利器。但它远不止是“向量搜索+拼接”那么简单。生产级的RAG系统需要处理：多模态检索（文本、代码、表格）、查询重写、重排序（Re-ranking）、引用溯源、以及最关键的——检索结果的精炼与整合。如何把检索到的5段相关文档，压缩、去重、并组织成一段连贯的辅助说明插入上下文，这本身就是一门精妙的艺术。

3.5 规模化与成本控制的必然要求

最后，是冷酷的经济账。大模型的API调用是按Token计费的，上下文越长，单次调用越贵，速度也越慢。在企业级应用中，每天可能有数百万次的调用。无节制地使用长上下文，成本将是灾难性的。

上下文工程必须考虑成本效益。这催生了诸如上下文压缩、选择性加载、缓存等技术。例如，不是每次都将整个项目代码库送入上下文，而是建立一个代码索引，只在需要理解某个具体函数时，才动态加载其定义和调用关系。这就像一位经验丰富的程序员，不会试图在脑子里记住所有代码，而是熟练地使用IDE的“跳转到定义”和“查找引用”功能。

4. 上下文工程的核心组件与技术架构

理解了“为什么”，我们来看看“怎么做”。一个完整的上下文工程系统，通常由以下几个核心组件构成，它们协同工作，共同管理智能体的“思维环境”。

4.1 上下文缩放：突破固定窗口的边界

虽然模型有固定的上下文窗口，但通过工程技术，我们可以实现事实上的“无限上下文”。主要技术路径有三条：

1. 外部记忆系统：这是最主流的方法。将历史信息存储在模型外部（如数据库），仅在需要时通过检索召回相关片段，插入当前上下文。这相当于给模型配了一个外接硬盘。

   • 关键考量：检索的准确性至关重要。“垃圾进，垃圾出”，如果检索不到相关信息，或者检索到不相关的信息，都会严重干扰模型。
   • 实操技巧：不要只依赖语义相似度检索。结合关键词、元数据（如时间戳、来源、类型）进行混合检索，并引入重排序模型对初步检索结果进行二次精排，能大幅提升召回质量。

2. 上下文压缩与摘要：对于必须保留在窗口内的信息（如核心指令、当前任务状态），进行无损或有损压缩。

   • 无损压缩：删除冗余空格、简化标记（Tokenization）等。
   • 有损压缩：使用另一个小模型（或大模型自身）对长文本进行摘要，只保留核心信息。例如，将长达50轮的对话历史，总结成“用户想开发一个TODO应用，已确定使用React前端和Flask后端，目前卡在用户认证模块的设计上”。
   • 注意事项：摘要会丢失细节，可能引入偏差。对于关键信息（如用户明确指定的参数值），应采用“提取式”而非“概括式”摘要，直接保留原句。

3. 高效注意力机制：模型架构层面的改进，如无限注意力（Infini-attention）、滑动窗口注意力等。这些技术允许模型以更低的计算成本处理更长的序列。对于应用开发者而言，这意味着可以选择支持这些特性的模型（如Gemini 1.5 Pro的100万token上下文），来获得“原生”的长上下文支持。

4.2 生产环境中的上下文管理

在真实的生产系统中，上下文管理需要像管理数据库连接池一样精细。

• 上下文缓存：对于频繁使用的、静态的背景信息（如产品文档、API规范），可以将其嵌入向量后缓存起来，避免每次请求都重新计算。
• 版本化与快照：智能体的状态（包括记忆、工具调用历史）应该可以保存为快照，并能随时回滚到某个历史版本。这在调试复杂任务时极其有用。
• 隔离与沙箱：不同的用户会话、不同的任务线程，应该有完全隔离的上下文环境，防止信息泄露和相互干扰。
• 监控与可观测性：你需要知道每一次API调用，实际送入模型的上下文是什么样子、长度多少、包含了哪些记忆片段、检索结果的质量如何。这需要完善的日志和追踪系统。

4.3 结构化数据集成：超越纯文本

现实世界的数据很少是纯文本。我们有JSON、XML、数据库表格、代码AST（抽象语法树）。简单地将它们转换成文本会丢失其内在结构。

上下文工程需要处理结构化数据的集成：

• 代码理解：在编程场景下，将代码的抽象语法树、调用图、类型信息以结构化的方式注入上下文，比单纯粘贴代码文本更有效。
• 表格数据处理：对于表格，可以提取其Schema（列名、类型）、统计摘要和关键行列，以更紧凑的形式呈现。
• 知识图谱：用“实体-关系”的三元组形式来表示知识，比大段描述性文本更易于模型进行逻辑推理。

4.4 自生成上下文：让智能体为自己做笔记

这是智能体迈向“自主性”的重要一步。除了被动地存储用户输入和工具输出，智能体应该能够主动地生成并存储对自己有用的上下文。

• 反思与总结：在完成一个复杂步骤后，智能体可以自动生成一段总结：“已完成用户认证模块的API设计，共定义3个端点：/login,/register,/logout。采用JWT令牌机制，令牌有效期设为24小时。”
• 错误日志与学习：当工具调用失败或用户指出错误时，智能体可以将错误信息和修正方案记录到记忆中，避免未来重蹈覆辙。
• 计划与待办事项：智能体可以将自己制定的多步计划存储下来，作为后续行动的指引。

5. 实现挑战与架构模式

5.1 智能体运行时与“缰绳”

到了2026年，业界共识是，上下文工程必须被置于一个更广阔的智能体运行时框架内来考虑。这个运行时，我更喜欢称之为“缰绳”，它负责管理智能体的整个生命周期和状态。

一个典型的智能体运行时架构包含以下层次：

核心设计模式：

• 流水线模式：将上下文处理流程分解为检索 -> 重排序 -> 压缩 -> 组装等独立阶段，每个阶段可插拔、可替换。
• 事件驱动模式：上下文的变化（如新记忆存入、工具调用完成）作为事件发布，由不同的处理器异步消费和更新状态。 |模式|优点|缺点|适用场景| | :--- | :--- | :--- | :--- | |流水线模式| 结构清晰，易于调试和优化单个环节。 | 流程僵化，难以处理复杂的循环或条件分支。 | 任务流程相对固定、线性的场景，如文档问答RAG。 | |事件驱动模式| 高度解耦，灵活性强，易于扩展新功能。 | 系统复杂度高，状态管理困难，调试追踪链路长。 | 复杂的、状态多变的智能体交互，如多智能体协作系统。 | |状态机模式| 能精确控制智能体在不同状态间的转移，行为可预测。 | 设计复杂，状态爆炸问题，难以覆盖所有边缘情况。 | 业务流程严格、需要强一致性的场景，如客服工单处理。 |

5.2 记忆系统的设计模式

记忆是上下文工程的心脏。根据信息的生命周期和用途，记忆系统通常采用分层设计：

1. 感官记忆/缓冲区：存储最近的几轮原始对话和工具原始输出。容量小，存取快，用于维持对话的即时连贯性。
2. 工作记忆/短期记忆：存储当前任务相关的焦点信息，如正在编辑的代码块、正在分析的文档段落。这部分记忆会被主动、频繁地读写。
3. 长期记忆/项目记忆：存储从过去经验中提炼出的持久知识，如项目架构决策、用户偏好、学到的技能。存取速度较慢，但容量大，需要通过检索来唤醒。
4. 程序性记忆：存储“如何做某事”的知识，通常体现为可复用的工具调用模式或代码模板。

实操心得：记忆的写入策略比读取策略更重要。很多系统只关注“如何检索”，却忽略了“什么值得记”。一个简单的启发式规则是：只存储那些可能对未来决策产生影响的、非显而易见的结论。例如，存储“用户偏爱使用async/await语法”是有价值的；存储“用户说了一句‘你好’”则是无意义的噪音。

5.3 开放协议与互操作性

随着智能体生态的发展，一个巨大的挑战是“孤岛效应”：为A平台开发的智能体，无法在B平台上运行，因为它们的上下文格式、工具接口、记忆存储方式各不相同。

这正是开放协议的价值所在。像Model Context Protocol旨在标准化智能体与外部数据源/工具之间的通信方式；Agent-to-Agent Protocol关注智能体间的对话与协作标准。采用这些协议，意味着你的上下文管理组件可以更容易地接入不同的运行时，你的智能体也能更自由地“迁移”和“交互”。

对于开发者而言，在构建自己的上下文系统时，应尽量遵循或适配这些新兴标准，而不是从头发明一套完全私有的格式。这能极大地提升系统的未来兼容性和可集成性。

5.4 工具使用与计算机操作

对于编程智能体这类“杀手级应用”，上下文工程有特殊的要求。这类智能体不仅需要理解自然语言指令，还需要理解代码库的复杂结构、能够编辑文件、运行测试、处理错误信息。

• 项目感知：智能体需要维护一个“项目记忆”，其中包含文件树结构、关键模块的依赖关系、最近的修改历史等。这通常通过扫描项目目录、解析requirements.txt或package.json等文件来实现。
• 代码上下文管理：当智能体编辑一个文件时，相关的上下文应包括：该文件的当前内容、调用该函数的其他代码、该函数所属的类或模块的文档。这需要与IDE或代码分析工具深度集成。
• 安全沙箱：执行代码必须在隔离的沙箱环境中进行，防止对宿主系统造成破坏。同时，工具执行的结果（包括标准输出、错误信息、返回值）需要被清晰地格式化并插入上下文。

6. 评估与可观测性：如何知道你的上下文工程是否有效？

构建系统只是第一步，衡量其效果同样重要。对于上下文驱动系统的评估，已经超越了简单的“答案是否正确”。

6.1 上下文质量评估

我们可以从多个维度评估上下文的“好坏”：

• 相关性：检索或保留的记忆片段与当前任务的相关度如何？可以通过人工标注或使用一个“裁判”模型来打分。
• 完整性：上下文是否包含了完成任务所必需的所有信息？是否存在关键信息的缺失？
• 简洁性：在保证相关性和完整性的前提下，上下文是否足够精炼？平均每次调用的Token数是多少？
• 新鲜度：记忆系统中的信息是否及时更新？是否存在过时或矛盾的记录？

6.2 面向智能体的评估范式

对于长周期运行的智能体，评估需要模拟真实的使用场景：

• 长程一致性测试：在跨越数十轮甚至数百轮的对话中，智能体是否能保持对早期设定目标的一致追求？是否会忘记关键约束？
• 多步骤任务完成率：给定一个复杂的、需要多步工具调用的任务（如“搭建一个简单的博客网站”），智能体能独立完成到哪一步？
• 幻觉率与溯源准确性：当智能体提供信息时，它是否能正确引用其来源（来自记忆中的哪份文档、哪个对话轮次）？是否会产生无来源的“幻觉”？
• 成本与延迟：在完成相同任务的前提下，不同上下文管理策略带来的API调用成本和响应延迟是多少？

6.3 可观测性：打开黑箱

在生产环境中，你必须有能力洞察智能体内部的“思考过程”。

• 追踪：记录每一次LLM调用（请求和响应）、每一次工具调用、每一次记忆的读写操作。将这些事件串联成一个有向无环图，形成完整的执行轨迹。
• 监控：实时监控关键指标，如上下文长度分布、记忆检索命中率、工具调用成功率、Token消耗速率等。设置警报，当异常情况（如上下文长度激增、检索相关性骤降）发生时能及时通知。
• 调试：当智能体行为异常时，能够回放完整的执行轨迹，检查每一步的上下文状态，定位问题是出在记忆检索、工具调用还是LLM生成本身。

像LangSmith、Arize AI等平台提供了开箱即用的智能体可观测性解决方案。对于自建系统，可以基于OpenTelemetry标准来构建自己的追踪框架。

7. 应用场景与系统实例

7.1 复杂研究系统

在学术研究前沿，上下文工程被用于构建能够进行长期、自主科学探索的AI系统。

• AlphaFold 3等系统虽然不完全是LLM驱动，但其核心思想——整合多种生物数据（蛋白质序列、结构、相互作用）作为“上下文”，来预测蛋白质结构——与上下文工程的理念异曲同工。
• AI科研助手：设想一个智能体，它可以阅读数百篇相关论文（作为长期记忆），根据研究者的提问（当前指令）检索关键段落，并在此基础上生成文献综述、提出假设、甚至设计实验方案。这需要极其强大的跨文档理解、信息整合和推理能力。

7.2 生产系统：编程智能体与平台栈

目前，上下文工程最成熟、最可见的应用领域是编程智能体。

• Claude Code / GitHub Copilot Workspace：这些系统本质上是一个拥有“项目级上下文”的编程伙伴。它们能理解整个代码库的架构，记住你刚才修改了哪个文件、遇到了什么错误，并在这种持续的上下文中提供建议或直接生成代码。其背后的核心技术，就是动态的、项目感知的上下文管理。
• 平台栈与托管运行时：云厂商和AI初创公司正在提供“智能体即服务”的平台。如Google的Agent Development Kit、微软的AutoGen Studio，它们提供了封装好的运行时环境，内置了记忆管理、工具调用、可观测性等组件。开发者只需关注任务逻辑和提示词，而无需从零构建复杂的基础设施。

踩坑经验：在开发编程智能体时，最大的挑战之一是代码上下文的“爆炸”。一个中等规模的项目可能有成千上万个文件。全部送入上下文是不可能的。我们的策略是构建一个分层索引：

1. 第一层：项目文件树和README.md，用于理解项目结构。
2. 第二层：关键配置文件（如package.json,docker-compose.yml）和主要入口文件。
3. 第三层：动态加载。当智能体需要编辑或查看某个特定文件时，才将其内容连同其直接依赖（通过静态分析获得）一起加载到上下文中。 这种“按需加载”的策略，在保证功能的前提下，将平均上下文长度降低了70%以上。

8. 局限性与未来方向

尽管上下文工程前景广阔，但它仍处于早期阶段，面临诸多挑战。

8.1 当前局限

• 计算与成本瓶颈：处理超长上下文、进行复杂的检索与重排序，本身就需要消耗大量的计算资源。这限制了其在实时或高并发场景下的应用。
• 评估体系不完善：如何定量评估一个上下文管理系统的“好坏”，仍然缺乏公认的、全面的基准测试集。现有的评估多侧重于最终任务成功率，而对上下文本身的效率、质量缺乏细粒度衡量。
• “组合爆炸”问题：随着记忆的增长，检索到无关或矛盾信息的概率也在增加。如何设计智能的遗忘机制、记忆融合机制，避免系统被陈旧或冲突的信息所拖累，是一个开放问题。
• 安全与可控性：动态的、由AI生成的上下文可能包含错误或有害信息，这些信息又会被带入后续的推理中，形成“回声室”效应。如何对上下文进行安全检查、过滤和纠偏，是走向生产必须解决的问题。

8.2 未来展望

从我个人的观察和业界动态来看，上下文工程有几个明确的演进方向：

1. 更加“主动”的上下文管理：未来的系统不仅能被动地响应用户查询和检索记忆，还能主动预测用户意图，提前加载可能需要的上下文，甚至主动发起对话以澄清模糊点、补充缺失信息。
2. 多模态上下文的深度融合：未来的智能体需要处理文本、代码、图像、音频、视频乃至传感器数据构成的混合上下文。如何跨模态地关联、索引和检索信息，是一个巨大的技术前沿。
3. 个性化与自适应：上下文系统将越来越了解其用户。它会学习用户的工作习惯、知识盲区、偏好风格，并动态调整上下文呈现的方式（例如，为新手提供更详细的解释，为专家提供更简洁的要点）。
4. 标准化与模块化：就像Web开发有HTTP、HTML标准一样，智能体上下文的格式、记忆的交换协议、工具的接口，将会出现更广泛接受的标准。这将催生一个繁荣的、可互操作的智能体组件生态。

最后，我想分享一点最深的体会：上下文工程的核心，最终是“人机协作”的工程。我们设计的不是替代人类的自动化机器，而是增强人类能力的认知伙伴。一个好的上下文系统，应该让人类感到智能体是“理解”他的，是“记得”之前说过的话的，是能够在一个复杂的任务上与他“并肩作战”的。这种流畅、自然、高效的协作体验，才是上下文工程所追求的终极目标。它不再是与一个神秘黑盒的艰难对话，而是一次与一个强大、可靠、且拥有“共同记忆”的伙伴之间的深度合作。这条路还很长，但每一步都让人兴奋。