Everything is Context: Agentic File System Abstraction for Context Engineering
Everything is Context: Agentic File System Abstraction for Context Engineering
引言：从模型微调到上下文工程
生成式人工智能（Generative AI, GenAI）正在重塑软件系统的设计范式，其引入的基础模型（Foundation Models）作为预训练的子系统，重新定义了系统架构和运行方式【2512.05470】。如今，挑战已不再是模型的微调，而是上下文工程（Context Engineering）——即系统如何捕获、结构化并治理外部知识、记忆、工具和人类输入，以实现可信的推理【2512.05470】。当前，诸如提示工程（Prompt Engineering）、检索增强生成（RAG）和工具集成等实践仍然零散，产生的上下文工件往往是短暂的、不可追溯的，这限制了系统的可追溯性和问责性【2512.05470】。为了解决这一问题，本文提出了一种文件系统抽象用于上下文工程，其灵感源自Unix哲学“一切皆文件”【2512.05470】。该抽象通过统一的挂载、元数据和访问控制，为管理异构的上下文工件提供了持久化、可治理的基础设施【2512.05470】。这一架构在开源的AIGNE框架中实现，构建了一个可验证的上下文工程管道，包括上下文构造器（Context Constructor）、加载器（Loader）和评估器（Evaluator），在令牌（Token）约束下组装、传递和验证上下文【2512.05470】。随着GenAI成为决策支持中的积极协作者，人类扮演着策展人、验证者和共同推理者的核心角色【2512.05470】。该架构为可问责、以人为中心的AI协作奠定了可重用的基础，并通过两个示例（一个具备记忆能力的Agent和一个基于MCP的GitHub助手）进行了演示【2512.05470】。在AIGNE框架中的实现表明，该架构可在开发和工业环境中落地，支持可验证、可维护且工业就绪的GenAI系统【2512.05470】。
背景与相关工作：上下文工程的兴起
近年来，随着大型语言模型（LLM）和Agent系统的发展，上下文工程正成为软件架构中的核心关切【2512.05470】。上下文工程关注的是如何捕获、结构化并治理外部知识、记忆、工具和人类输入，使LLM和Agent的推理建立在正确的信息、约束和溯源之上【2512.05470】。这与专注于单个指令设计的提示工程不同，上下文工程着眼于整个信息生命周期，包括选择、检索、过滤、构建、压缩、评估和刷新，确保GenAI系统和Agent长期保持连贯、高效和可验证【2512.05470】。工业界框架（如LangChain）已开始将上下文工程视为Agent架构中的结构化过程，并识别出四个关键阶段：Agent将上下文信息写入共享记忆或存储，为给定任务选择最相关元素，压缩选定上下文以适应模型约束，以及隔离最终子集供Agent推理【2512.05470】。类似管道也出现在AutoGen等支持工具使用和记忆增强的框架中【2512.05470】。然而，这些解决方案仍属于临时且实现驱动的，缺乏统一的架构基础来确保可追溯性、治理或对演进上下文的系统处理【2512.05470】。结果，这些步骤中生成的上下文工件往往是短暂的、不透明的且不可验证，带来了上下文腐烂（Context Rot）和知识漂移等挑战【2512.05470】。
在学术研究方面，LLM即操作系统（LLM-as-OS）的范式也应运而生，将LLM视为协调上下文、记忆、工具和Agent的内核【2512.05470】。例如，AIOS项目通过类似操作系统的原语（调度、资源分配、内存管理）来操作多Agent系统【2512.05470】。MemGPT则引入了记忆层次结构，协调短期的上下文窗口和长期的外部存储【2512.05470】。这些工作提供了直观的高层概念模型，但缺乏软件架构抽象来指导如何结构化、共享和治理上下文【2512.05470】。此外，模型上下文协议（Model Context Protocol, MCP）作为一个开放标准，旨在将AI助手与数据源（如内容仓库、业务工具和开发环境）安全连接，以帮助前沿模型产生更相关、更准确的响应【14†source】。MCP遵循客户端-主机-服务器架构，通过JSON-RPC提供有状态的会话协议，专注于客户端与服务器之间的上下文交换和采样协调【14†source】。尽管MCP解决了数据源连接的标准化问题，但它主要关注数据接入，并未直接解决上下文在模型内部的组织、治理和验证问题。
综上所述，现有工作在上下文管理上仍存在不足：要么过于零散（如各种RAG和工具集成方案各自为政），要么缺乏对上下文生命周期的系统治理和验证机制。本文提出的文件系统抽象正是为了填补这一空白，为上下文工程提供一个持久化、可治理的统一基础设施。
文件系统抽象：持久化上下文基础设施
本文的核心贡献是引入文件系统抽象作为上下文工程的架构基础，其灵感源自Unix哲学“一切皆文件”【2512.05470】。在该抽象中，所有异构的上下文来源（记忆、工具、外部知识、人类贡献等）都被视为文件，通过统一的命名空间进行挂载和访问【2512.05470】。这种抽象带来了多方面的架构优势：
抽象与统一接口
文件系统抽象提供了一个简单、统一的接口来管理多样化的上下文资源。无论上下文是向量数据库中的记忆片段、工具函数的定义，还是外部知识库的条目，都可以通过文件路径和标准文件操作（如读取、搜索、写入、执行）来访问【2512.05470】。这种统一接口简化了系统设计，使新上下文源的集成变得像挂载一个新文件系统一样简单。
模块化与封装
文件系统天然支持模块化。每个上下文源可以封装为一个独立的“文件系统”或命名空间，通过挂载点集成到全局上下文中。这种封装性使得不同上下文组件可以独立开发和演进，而不影响整体架构，从而提高了系统的可维护性和可扩展性。
关注点分离
通过将上下文管理与模型推理分离，文件系统抽象实现了关注点分离。模型本身专注于推理，而上下文的获取、组织、治理由文件系统层负责。这种分离使得系统可以针对上下文管理引入专门的机制（如访问控制、元数据管理、审计日志），而不干扰模型的推理过程。
可追溯性与可验证性
文件系统提供了天然的审计和追溯能力。所有对上下文文件的操作（读取、写入、挂载等）都可以记录日志，形成完整的操作历史【2512.05470】。这使得上下文的来源、变更和使用情况都可被追踪和审计，为问责和合规提供了基础。此外，文件系统支持版本控制和快照，可以方便地回滚和验证上下文状态，确保系统的可验证性。
可组合性与演进性
文件系统的层次结构和命名空间支持上下文的组合与嵌套。例如，可以将一个Agent的记忆挂载为另一个Agent的子目录，实现上下文的组合。这种可组合性使得系统可以灵活地构建复杂的上下文结构。同时，文件系统的挂载机制允许在不修改核心架构的情况下引入新的上下文源或工具，支持系统的持续演进。
在具体实现上，该抽象通常体现为一个Agent文件系统（Agentic File System, AFS），它提供一组核心文件操作接口，如列出目录、读取文件内容、搜索文件、写入或更新文件，以及执行文件（用于调用工具）【2512.05470】。每个上下文文件都附带结构化元数据（创建时间、所有者、权限、来源ID、版本等），访问控制策略可以基于路径精细实施，并且每个操作都会生成日志条目，以确保完全的追溯性【2512.05470】。通过这种文件系统抽象，上下文不再是临时的、隐藏的变量，而是显式的、可管理的实体，为后续的上下文工程管道奠定了坚实基础。
上下文工程管道：可验证的上下文生命周期管理
在文件系统抽象之上，本文构建了一个上下文工程管道，用于在模型令牌窗口约束下系统化地组装、传递和验证上下文【2512.05470】。该管道由三个核心模块组成：上下文构造器（Context Constructor）、上下文加载器（Context Loader）和上下文评估器（Context Evaluator），它们协同工作，形成一个可验证、可审计的上下文生命周期管理流程【2512.05470】。
上下文构造器（Context Constructor）
上下文构造器负责根据任务请求或用户提示，从文件系统命名空间中选择、优先排序并压缩上下文工件【2512.05470】。它首先查询挂载的文件系统（例如“/context”路径），获取所有可访问的上下文文件候选。然后，构造器使用相关性度量（如语义相似度、时效性）对每个文件进行评分，并施加严格的访问控制和数据治理约束，确保只有合规的上下文被纳入考虑【2512.05470】。接着，构造器按照相关性从高到低对候选文件排序，并根据令牌预算（$T_{\max}$）决定包含哪些文件【2512.05470】。如果选定的上下文总令牌数超出预算，构造器会对文件内容进行摘要或截断，以满足约束【2512.05470】。最终，构造器输出一个清单（Manifest）（通常为JSON格式），详细列出被选中的文件、它们的顺序以及选择依据（例如基于计算的相关性分数）【2512.05470】。这个清单为后续步骤提供了明确的上下文来源说明，是可审计性的重要组成部分。
上下文加载器（Context Loader）
上下文加载器（在某些实现中也称为Context Updater）负责根据构造器输出的清单，将选定的上下文片段物理地读取并组装成模型的提示缓冲区【2512.05470】。加载器支持两种模式：静态模式（一次性加载全部上下文）和流式模式（逐步增量加载上下文）【2512.05470】。静态模式适用于单轮对话或任务，而流式模式对于多轮对话或大型上下文队列尤为重要，它允许模型在对话过程中动态地接收新的上下文片段，从而适应不断演进的对话状态【2512.05470】。无论哪种模式，加载器都会持续监控令牌使用量，确保总令牌数不超过上限【2512.05470】。如果需要，加载器可以替换或追加上下文片段，以在令牌约束下保持对话的连贯性。每次上下文的注入或更新操作都会被完整记录，包括会话ID、时间戳、来源路径等元数据【2512.05470】。这种日志记录为后续的审计和问题排查提供了依据。
上下文评估器（Context Evaluator）
上下文评估器在模型推理完成后，对模型的输出进行验证，确保其基于提供的上下文是可信和准确的【2512.05470】。评估器首先从模型输出中提取出原子性的陈述或事实，然后将这些陈述与构造器清单中引用的源上下文进行比较【2512.05470】。通过计算模型输出事实与源上下文事实的交集，评估器得出一个一致性置信度分数，用于衡量模型输出与源上下文的吻合程度【2512.05470】。如果置信度低于预设的阈值$\theta$，系统将触发人工介入进行审查【2512.05470】。这种人工介入机制确保了当模型输出可能与事实不符时，有人工专家进行判断和纠正，从而保障结果的可信度。如果置信度满足要求，评估器会将模型输出中验证通过的新知识持久化到长期记忆中（例如写入“/context/memory/...”路径），并附上完整的溯源信息（创建时间、来源清单、版本ID等）【2512.05470】。同时，评估器将本次验证结果追加到事务日志中，以备未来审计和合规检查【2512.05470】。通过这一机制，评估器不仅保证了单次输出的可信，还通过将验证后的知识纳入记忆，实现了系统知识的持续积累和演进。
这三个模块协同工作，形成了一个闭环的上下文工程管道。构造器确保“用正确的上下文”，加载器确保“正确地使用上下文”，评估器确保“上下文被正确地使用”。整个流程在文件系统抽象的支撑下，具有高度的可追溯性和可验证性，为构建可问责、以人为中心的GenAI系统奠定了基础。
实现平台：AIGNE框架与示例
为了将上述抽象和管道付诸实践，作者在开源的AIGNE框架中实现了该文件系统抽象和上下文工程管道【2512.05470】。AIGNE是一个用于构建Agent逻辑和能力的组合式、TypeScript优先的框架【5†source】。它提供了一个多模型适配器（AIGNE Hub），通过统一的API接口支持多种基础模型，使开发者可以灵活地选择和切换模型【5†source】。AIGNE框架本身遵循“一切皆文件”的理念，将上下文、记忆、工具等都视为文件进行管理，从而为上下文工程提供了原生的支持。
在AIGNE框架中，文件系统抽象通过一个核心模块（通常称为AFS）实现，它提供了前述的文件操作接口，并支持将外部数据源（如向量数据库、知识图谱、MCP服务器等）挂载到统一命名空间【2512.05470】。基于此，AIGNE实现了上下文构造器、加载器和评估器三个组件，并将其串联成管道，嵌入到Agent的执行流程中。当Agent接收到任务或用户输入时，首先由构造器从文件系统中选择并准备上下文，然后由加载器将上下文注入模型请求，模型生成响应后由评估器进行验证和记忆更新。整个过程在AIGNE框架的调度下自动完成，同时保留了完整的日志和审计信息。
为了展示该架构的可行性和适应性，论文提供了两个示例：
示例一：具备记忆能力的Agent
该示例演示了一个Agent如何利用文件系统抽象来维护长期记忆，并在多轮对话中持续改进。Agent的记忆被存储在“/context/memory/{agentID}/”路径下，包括用户偏好、历史对话摘要等【2512.05470】。当新的用户请求到来时，上下文构造器会从记忆中检索相关的历史信息（如用户偏好或过去的对话片段），将它们与当前任务相关的知识一起作为上下文提供给模型【2512.05470】。加载器将这些上下文片段组装成提示，模型据此生成响应。评估器则检查模型输出是否与记忆中的信息一致，并将新的有用信息（如用户的新偏好）更新回记忆中【2512.05470】。通过这个循环，Agent展现出类似“记忆”的能力：它能够记住用户过去的交互，并据此调整未来的回答，从而提供更连贯和个性化的体验。
示例二：基于MCP的GitHub助手
该示例展示了如何将文件系统抽象与模型上下文协议（MCP）结合，构建一个能够访问GitHub数据的智能助手。MCP是一个开放标准，用于将AI助手连接到各种数据源（如代码仓库、业务工具等）【14†source】。在本示例中，一个MCP服务器被实现为GitHub的接口，通过MCP协议提供对仓库数据（如代码文件、Issue、Pull Request等）的访问【2512.05470】。该MCP服务器被挂载到文件系统的“/modules/github-mcp”路径下，使Agent能够像访问文件一样查询GitHub数据【2512.05470】。当用户提出与代码相关的问题时，上下文构造器会查询GitHub MCP挂载点，检索相关的代码片段或Issue信息作为上下文【2512.05470】。加载器将这些上下文提供给模型，模型据此生成回答或建议。评估器则验证模型的回答是否与GitHub数据一致，并将有用的结论（如对某个Issue的总结）持久化到记忆中【2512.05470】。通过这个示例，可以看到文件系统抽象能够无缝集成外部数据源（通过MCP），并为Agent提供丰富的上下文，从而显著提升其在专业领域（如软件开发）的实用能力。
这两个示例充分证明了所提出架构的可操作性和适应性。在AIGNE框架的支撑下，开发者可以方便地构建具备持久化记忆和外部数据访问能力的Agent，并且整个上下文工程过程是可验证、可维护的【2512.05470】。这为工业界部署可靠、可信的GenAI系统提供了切实可行的路径。
结论与未来展望
“Everything is Context”这一理念在本文中被赋予了新的内涵：通过将上下文视为文件，我们为上下文工程提供了一个持久化、可治理的统一基础设施。这不仅解决了当前GenAI系统中上下文管理零散、不可追溯的问题，也为构建以人为中心、可问责的AI协作系统奠定了基础。在AIGNE框架中的实现和示例验证了该架构的可行性，展示了其在实际应用中的价值。
展望未来，有几个方向值得进一步探索。首先，上下文治理策略需要更深入的研究，包括如何根据上下文的重要性和敏感性实施细粒度的访问控制、隐私保护和合规审计。其次，随着上下文规模的扩大，高效的上下文检索与压缩算法将变得至关重要，以确保在令牌约束下快速找到最相关的上下文。第三，多模态上下文（如文本、图像、代码等）的统一管理也是未来的一个挑战和机遇，文件系统抽象需要扩展以支持非文本上下文的挂载和检索。最后，随着Agent在复杂任务中扮演更积极的角色，人机协同的上下文工程将变得更加重要，如何设计直观的界面让人类参与上下文的策展和验证，也是值得研究的方向。
总之，本文提出的文件系统抽象和上下文工程管道为构建下一代可信、可控的GenAI系统提供了一个坚实且可扩展的起点。随着这一理念的进一步发展和完善，我们有望看到更加智能、可靠的AI助手在各个领域与人类协同工作，共同创造更大的价值。
讨论回复
0 条回复还没有人回复