循环工程、上下文工程和图工程
上下文工程、循环工程和图工程的兴起加强了将数据作为受管理产品而非不受管理的技术资产来对待的理由。
AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
AI系统的语言正在发生变化。提示工程（Prompt Engineering）在生成式AI的早期占据主导地位，因为大多数应用都涉及人类向模型发出指令并获得响应。随着AI系统变得更加智能，提示只是一个更大架构的一小部分。因此，当前的讨论已经转向上下文工程（Context Engineering）、循环工程（Loop Engineering）和图工程（Graph Engineering）。
这些术语描述了同一个问题的不同方面。上下文工程决定了AI系统在做决策时知道什么。循环工程决定了它如何行动、评估结果并继续工作。图工程决定了它如何理解连接环境中的关系、依赖和后果。
虽然这些概念通常作为AI工程模式来讨论，但它们也揭示了一个更深层次的数据问题。一个代理仅仅因为组织将数据放在数据仓库、数据目录、湖仓一体、向量数据库或文档存储库中，就无法可靠地运行。代理必须理解数据代表什么、为什么存在、谁拥有它、如何访问它、适用哪些质量期望以及它是否适合该任务。这些都是数据产品问题。
上下文工程、循环工程和图工程的兴起加强了将数据作为受管理产品而非不受管理的技术资产来对待的理由。这也为开放数据产品标准系列及其AI代理优先SDK（AI Agent First SDK）创造了明确的角色。它们共同提供了定义产品、组织产品组合、表达关系、对齐术语和控制可重复工作流的机器可读结构。
1、上文工程需要产品上下文
上下文工程已经发展成为比提示工程更广泛的学科。2025年的一项研究调查将其定义为在推理过程中提供给大型语言模型信息的系统优化。该调查围绕上下文检索、上下文生成、上下文处理和上下文管理来组织该领域。它还将这些基础与检索增强生成（Retrieval-Augmented Generation）、记忆系统、工具集成推理和多代理系统联系起来。大型语言模型上下文工程综述
这个定义很重要，因为它将注意力从单个指令的措辞转移开。模型的响应取决于该指令周围的完整信息环境。对于业务代理，此环境可能包括客户记录、产品定义、运营策略、质量测量、服务承诺、先前的决策、最近的事件以及可用于操作的工具。
工程挑战不是将尽可能多的信息放入模型的上下文窗口。更多信息不会自动产生更好的推理。系统必须选择相关材料，删除不必要的细节，保留来源，并以模型可以正确解释的结构呈现信息。
大多数当前的上下文实现仍然严重面向文档。用户提出问题，检索系统搜索文档或文本片段，并将语义最相似的段落插入提示中。这种方法为代理提供了证据，但很少为代理提供对证据背后产品的可靠理解。
检索到的段落可能描述客户交易表。它不一定告诉代理该表是否属于已批准的产品、是否满足新鲜度目标、支持哪些消费者或是否适用法律限制。它可能无法识别所有者、批准的访问方法或证明创建该产品的业务目标。
产品感知的上下文系统必须回答更广泛的问题。它应该解释数据产品的设计目标、支持的用例、所有者、访问方式、适用的质量和服务承诺以及控制其使用的策略。它还应该显示产品如何连接到其他产品、业务目标、运营信号和性能指标。
开放数据产品规范（Open Data Product Specification，ODPS）提供了这种产品级结构。它通过机器可读元数据描述数据产品，涵盖访问、质量、服务水平、许可、定价、治理和产品策略。因此，产品定义不仅包含技术描述。它包含负责任的消费所需的运营和业务含义。开放数据产品规范4.1
开放数据产品目录（Open Data Product Catalogs，ODPC）将此上下文扩展到单个产品之外。它将产品放在目录和产品组合中，以及目标、用例、KPI和信号。开放数据产品词汇表（Open Data Product Vocabulary，ODPV）为这些结构提供共享术语。ODPS、ODPC和ODPV共同将上下文从一组松散相关的文本片段转变为机器可读的产品环境。开放数据产品标准系列
这种区分改变了代理的工作方式。代理可以检索权威的产品定义，而不是检索文档并试图推断产品的目的。它可以检查产品的质量和服务承诺，而不是猜测来源是否足够新。它可以在每个任务中针对共享词汇表解析术语，而不是独立解释术语。
当上下文包含显式的产品、承诺和关系而非仅文本时，上下文工程变得更加可靠。
2、数据产品成为受治理的上下文提供者
数据产品通常被描述为打包用于消费的数据。在代理环境中，此定义需要更进一步。数据产品成为受治理的上下文提供者。
产品提供数据，但还提供解释和使用该数据所需的信息。这包括其目的、所有权、接口、质量期望、服务承诺、法律条件、定价和战略一致性。这些元素帮助代理确定该产品是否适合当前任务。
此产品边界很重要，因为上下文需要问责。当代理从通用搜索索引接收文档片段时，该片段的责任通常不清楚。当它通过定义好的数据产品接收信息时，存在可识别的所有者和明确的消费协议。
同样的原则适用于底层产品不是传统表格资产时。数据产品可能公开API、流、模型就绪特征集、分析服务、事件馈送或其他访问组件。重要的是产品提供对有用数据和消费所需上下文的稳定、受治理的接口。
这为组织提供了管理代理上下文的实用方法。组织可以公开具有机器可读描述的已批准产品，而不是允许每个代理团队构建独立的提示集合、文档索引和隐藏假设。代理然后可以从目的和操作条件已知的产品中选择上下文。
产品组合成为下一个级别的上下文。产品组合包含与业务计划相关的产品、目标、用例、信号、证据和关系。它为代理提供有限的操作环境，而不是对不相连的企业信息进行无限制的访问。
3、循环工程将模型调用转变为操作流程
上下文决定了代理在特定时刻知道什么。循环工程决定了代理对该知识的处理方式。
Anthropic将代理描述为在完成任务时指导自身流程和工具使用的模型。实际上，代理通过循环运行。它计划、行动、观察结果、调整方法，并重复直到任务完成或需要人工输入。实践中的可信代理
因此，代理系统的质量较少依赖于一个模型响应，而更多依赖于围绕它的重复过程的设计。弱循环允许代理在没有明确限制的情况下继续、重复失败的操作、接受未经验证的输出或在没有审查的情况下进行重大更改。更强的循环定义验证、重试限制、证据要求、升级路径、人工检查点和完成标准。
循环工程涉及受控迭代。它将一系列模型调用和工具操作转变为可观察的操作流程。
这个想法直接映射到数据产品交付。数据产品不会在某人创建YAML文件或在目录中发布条目时变得可靠。它通过一个循环过程，在该过程中，解释源材料，生成产品候选，验证其结构，识别缺失信息，审查治理期望，并批准或退回结果以进行进一步工作。
因此，数据产品既是工件也是操作循环中的对象。
考虑一个被要求从业务文档创建数据产品候选的代理。代理必须首先提取产品事实并识别可能的消费者、用例、所有者和信号。然后，它可以生成最小的产品定义，根据ODPS模式进行验证，将其术语与ODPV进行比较，并在目录中搜索类似或相关产品。
当所有权、质量或服务信息缺失时，循环不应默默地编造它。代理应记录差距、请求输入或将产品路由以供审查。一旦提供了缺失的信息，代理就可以生成其余的产品组件并准备结果以供批准。
价值不是来自说"生成ODPS文件"的提示。它来自围绕该生成的受控过程。
开放数据产品配方规范（Open Data Product Recipe Specification，ODPR）草案解决了此操作层。它定义了供应商中立、机器可读的可重复数据产品交付标准。它通过描述如何声明、配置、验证、审查和移交这些工件的工作来补充ODPS、ODPC、ODPG和ODPV。开放数据产品配方规范
ODPR在产品和产品周围的过程之间做出了重要区分。ODPS定义数据产品是什么，而ODPR定义涉及该产品的工作应如何进行。
这种分离防止产品规范成为执行脚本。它还防止工作流隐藏在本地代码、私有提示或未记录的团队习惯中。配方成为可移植的工作流契约，人员、SDK、CI/CD系统、MCP服务器和代理都可以解释。
ODPR包括交付流程、产品交接流程、基于触发器的流程、运行时配置文件、验证门、上下文策略和审查期望。这些元素为围绕数据产品的循环工程提供了所需的结构，而不会将标准绑定到一个代理框架或技术堆栈。
4、循环工程也需要证据
代理循环不应仅通过模型的置信度或其产生答案的能力来衡量进度。它需要外部证据表明操作达到了预期结果。
对于数据产品工作流，证据可能包括成功的模式验证、通过质量检查、确认的访问连接性、已解析的词汇表引用、已完成的审查门和已批准的发布决定。这些结果为循环提供可观察的状态。
这很重要，因为代理在多个回合中操作，并且在工作时经常修改其环境。Anthropic关于评估代理的指南指出，工具使用、状态变化和适应性使得代理比单回合模型响应更难评估。因此，可靠的评估必须检查轨迹和中间结果，而不仅仅是最终答案。揭秘AI代理评估
同样的原则适用于数据产品交付。精致的产品描述不是产品就绪的证据。就绪必须来自针对产品声明的需求和组织的审查标准的检查。
机器可读的产品规范和配方为循环提供了这些外部参考。代理不再针对模糊的自然语言期望评估自己的工作。它针对模式、契约、声明的门和审查状态评估结果。
这改变了模型的角色。模型处理解释、生成和适应，而周围的系统控制验证、状态、批准和发布。
5、图工程保留业务关系
上下文检索通常将信息视为一组单独的对象。图工程从关系是信息的一部分这一假设开始。
图可以表示产品支持用例、为目做贡献、提供KPI、响应外部信号、依赖另一个产品或继承治理条件。这些连接通常比孤立的节点承载更多的业务含义。
微软的GraphRAG工作展示了这对AI系统的重要性。基线检索通常依赖于问题和文本片段之间的语义相似性。当回答问题需要连接分散在多个源中的信息或理解大量集合中的主题时，这种方法会遇到困难。GraphRAG通过提取实体、关系和主张，将它们组织成图和社区层次结构，并在检索期间使用这些结构来解决这个问题。Microsoft GraphRAG
图改变了系统可以检索的内容。它可以通过连接的实体移动并使用它们周围的关系，而不是只找到与问题最相似的文本。微软的实现包括用于实体中心问题的本地搜索、关于整个集合的问题的全局搜索，以及其他将图结构与源文本结合的查询模式。GraphRAG查询引擎
同样的逻辑适用于数据产品组合。向量搜索可能找到描述中包含与"客户留存"类似语言的产品。图可以显示留存目标由流失KPI衡量，该KPI依赖于多个运营信号，并且这些信号来自特定的数据产品。
图还可以揭示其中一个产品未达到其新鲜度目标。然后它可以显示哪些用例、KPI和目标依赖于该产品。这不仅仅是检索。它是结构化的后果分析。
开放数据产品图（Open Data Product Graphs，ODPG）为ODPS系列提供了这种关系层。它允许产品与目标、用例、KPI、信号、治理对象和其他组合关系连接。ODPG将这些关系与单个产品定义分开，这允许ODPS文件保持可移植性，同时更广泛的组合图围绕它们发展。开放数据产品标准系列
图工程在整个数据产品生命周期中都很有用，因为它保留了普通目录和文档检索通常会扁平化的关系。在发现期间，代理可以从业务目标移动到连接的用例、信号和产品。在产品设计期间，相同的图可以揭示缺失的依赖关系、相互竞争的产品提案或服务于重叠目的的产品。在治理期间，它可以显示哪些用例和KPI依赖于质量、新鲜度或服务水平失败的产品。
相同的关系结构支持产品组合决策。与多个战略目标、用例和运营信号相关的产品可能比服务于狭隘本地需求的产品获得更多关注。当团队提议更改、替换或退役产品时，图提供了一种方法来跟踪对依赖产品、计划和结果的可能影响。
因此，图不仅仅是组合的可视表示。它成为用于评估优先级、依赖关系和后果的推理系统的一部分。
6、声明的图与推断的图不同
数据产品系统中的图工程有两个可能的起点。系统可以从文档推断图，或者组织可以通过机器可读关系声明图。
当组织有大量非结构化源材料时，推断的图很有用。GraphRAG等系统从文本中提取实体和关系，并将它们组织成支持检索的结构。这有助于代理检测尚未以结构化形式可用的连接。
限制在于推断的关系仍然是模型生成的解释。它们需要来源、置信度信息、验证和审查。产品与业务目标之间的推断连接可能是合理的，但不代表已批准的组织决策。
声明的图提供了不同级别的权限。ODPG关系可以声明特定产品支持已定义的用例或为特定目标做出贡献。此关系成为受管理组合的一部分，而不是在检索期间进行的临时推断。
最强的方法结合了两者。AI可以从业务文档、产品描述、策略文件和运营证据中提取候选关系。这些候选可以进入审查循环，由人员或治理规则批准、拒绝或修改它们。批准的关系成为声明的ODPG图的一部分。
推断的图帮助组织发现可能的含义，而声明的图记录接受的含义。
这种区分对于在受监管、战略或高影响环境中操作的代理很重要。代理需要知道它是在遵循提取的假设还是已批准的关系。
7、三个学科形成一个操作系统
上下文工程、循环工程和图工程解决了同一操作问题的不同部分。上下文工程确定代理在当前任务中需要哪些信息以及如何选择、结构化和呈现该信息。循环工程定义了代理如何从一个操作移动到下一个操作、如何检查结果、如何响应失败以及何时停止或请求人工审查。图工程提供了关系结构，使代理能够理解依赖关系、跟踪多步骤连接并评估操作的更广泛影响。
可靠的数据产品环境需要这三个学科协同工作。没有受控循环的上下文为代理提供了相关信息，但没有可靠的操作流程。没有足够上下文的循环在不完整或不合适的证据上产生有纪律的执行。没有图的上下文和循环仍然使代理对组合的视图碎片化，使其难以识别间接依赖关系、共享目标或下游后果。
这三个学科共同创造了更强大的基础。上下文提供产品事实、业务含义、策略和当前状态。图将这些事实连接到产品、用例、目标、信号和治理结构。循环使用这两者来指导操作、验证、升级和改进。
这就是ODPS系列提供一致架构模型的地方。ODPS描述单个数据产品。ODPC描述围绕它的目录和组合。ODPG描述跨产品和业务对象的关系。ODPV对齐系统中使用的语言。ODPR描述可重复的过程、交接、控制和审查阶段。
这些规范不与代理框架竞争。它们在它们之下提供可移植的产品、上下文、图和工作流层。
8、SDK将规范转变为代理能力
当标准的结构可通过可执行操作获得时，它们对代理变得有用。
开放数据产品SDK（Open Data Products SDK）为规范系列提供通用运行时。它允许开发人员、平台和代理验证产品定义、检查目录、遍历图、生成产品候选、执行配方、解析支持结构，并为模型上下文生成紧凑表示。开放数据产品Python SDK
这为代理开发人员提供了一种替代方案，无需将每个规则直接嵌入系统提示。当代理可以调用验证函数时，它不需要将完整的ODPS模式复制到每个上下文窗口中。当它可以在ODPC中搜索时，它不需要将整个目录插入提示中。当它可以在ODPG中遍历时，它不需要从散文中推断每个关系。
同样的原则适用于工作流执行。代理可以解释声明所需步骤、验证门、输入、输出和审查条件的ODPR配方，而不是将操作过程隐藏在框架特定代码中。
这减少了不必要的上下文，同时增加了控制。模型接收当前任务所需的信息，而确定性工具处理验证、搜索、图遍历和状态转换。
SDK的MCP接口将此方法扩展到代理环境。MCP工具允许代理调用功能，而无需将其完整实现或支持文档放入提示中。模型可以请求产品验证、目录搜索、图遍历或配方操作并接收结构化结果。
这是上下文工程的实用表达。系统将权威信息保留在模型之外，仅检索所需内容，并使用工具进行不应依赖于自由形式推理的操作。
9、实际数据产品示例
考虑一个支持政府能效计划的代理。传统的检索系统可能会索引策略文件、政策、消费报告、数据集、会议记录和技术文档。当用户提出问题时，系统检索相似段落并要求模型产生答案。
产品感知系统将为代理提供更结构化的环境。ODPC将描述该计划、其业务目标、用例、KPI、利益相关者、信号和所需的数据产品。ODPG将能源消耗产品、天气产品、费率产品、检查产品和建筑参考产品连接到它们支持的用例和结果。
ODPS将描述每个产品的所有权、访问方法、质量期望、服务水平、治理规则和战略目的。ODPV将对齐组合中的消费、效率、建筑类型、报告期、异常和费率等概念。ODPR将描述如何生成、验证、审查、改进和发布新产品。
SDK将允许代理检查组合、识别缺失的产品、搜索现有产品、遍历依赖关系、验证产品定义、生成候选并准备审查材料。
假设天气产品未达到其新鲜度目标。面向文档的上下文系统可能仍会检索最新的天气记录，而未意识到该产品已违反其声明的承诺。
图感知系统可以识别每个依赖于该产品的用例、模型、KPI和目标。循环感知系统然后可以挂起受影响的输出、运行验证步骤、选择已批准的后备方案、请求审查并记录结果决策。
上下文解释了天气产品是什么以及它是否仍然合适。图揭示了什么依赖于它。循环控制响应。这是这三个学科的综合价值。
10、对数据产品组织的战略意义
当前的讨论经常将上下文工程、循环工程和图工程视为改进代理的方法。这个观点是准确的，但不完整。这些学科也揭示了组织管理数据方面的弱点。
上下文工程暴露了没有含义、所有权和消费指导的数据的局限性。图工程暴露了不显示依赖关系或业务后果的孤立目录条目的局限性。循环工程暴露了不控制操作行为的静态治理文档的局限性。
答案不应该是另一个将这些问题隐藏在应用程序代码中的代理框架。组织需要一个介于业务意图、受治理的数据和代理执行之间的明确层。
开放数据产品标准系列提供了这样一层的组件。ODPS使单个数据产品易于理解。ODPC使更广泛的组合易于理解。ODPG使关系易于理解。ODPV使语言保持一致。ODPR使操作过程显式化。SDK将这些结构转变为代理能力。
此定位也改变了数据目录的角色。传统的目录帮助人们找到技术资产。代理就绪的产品组合必须帮助机器确定哪些产品适合目的、适用哪些约束、哪些关系重要以及应该遵循哪个工作流。
因此，未来的目录不仅是搜索界面。它是上下文系统、图和操作循环的一部分。
11、从代理访问到代理就绪
给予代理对数据的访问权限不会使数据代理就绪。访问只是要求之一。代理就绪需要机器可读的含义、清晰的所有权、声明的接口、可衡量的质量、服务承诺、策略条件、共享词汇表、关系结构和受控的操作过程。它还需要允许代理在不猜测的情况下检查和操作这些元素的工具。
这就是数据产品思维成为AI架构核心的地方。数据产品提供有界、可计费的消费单元。产品组合围绕业务需求组织这些单元。图连接它们。配方控制它们周围的工作。SDK将它们暴露给运行时系统。
上下文工程、循环工程和图工程之所以变得突出，是因为AI系统需要的不仅仅是提示。它们需要结构化的知识、受控的操作和明确的关系。
数据产品为该结构提供可管理的单元。ODPS系列提供通用语言。SDK将该语言转变为代理可以使用的操作。
结果是，代理从搜索大量企业信息转向在受治理的数据产品系统内操作。
原文链接：What Do Loop, Context, and Graph Engineering Have to Do With Data Products?
汇智网翻译整理，转载请标明出处
