面向多智能体系统的数据治理：
语义契约、上下文隔离与可验证协作
Data Governance for Multi-Agent Systems: Semantic Contracts, Context Isolation, and Verifiable Collaboration
作者：杨超然（数幄科技创始人） 单位：数幄科技
文献查阅截止：2026年11月3日｜文章类型：技术综述与参考架构研究
摘要
多智能体系统把企业数据使用从单次查询扩展为检索、推理、交接、记忆与行动组成的连续过程。数据即使在源系统中具有明确口径和访问控制，经过摘要、关联与跨任务复用后，仍可能丢失适用范围。本文围绕“如何治理供多智能体使用的数据”展开结构化叙述综述，完成200条独立关键词查询，并定向核验36项论文、规范、项目及产品文档。文章区分语义正确性、任务适用性、授权合法性与来源可追溯性，提出包含七类描述的上下文工件参考模型，以及来源、授权和协作三类关系的分离设计。在此基础上，归纳契约、记忆、策略执行、版本失效和协作评测方法，给出以必要交接与不适用信息隔离为核心的测试方案。本文认为，治理应覆盖从源数据到派生结论的使用链路，其目标是建立可检查的协作条件。本文未开展新系统实验；参考模型、评价指标与发展判断属于有文献支撑的设计建议。
关键词：多智能体系统；数据治理；语义契约；上下文工程；协作记忆；信息流控制
1 引言：治理对象为何需要延伸到协作过程
多智能体数据应用通常把业务问题分解为若干任务：一个角色寻找指标定义，一个角色查询数据，另一个角色解释变化，最后由执行角色提出业务动作。组织错误可能发生在分工之间。例如，“净收入”定义本来包含退款冲减，查询结果却在交接时只保留金额；解释角色把金额理解为含税流水，执行角色又将这一解释写入长期记忆。此时，各组件可能都完成了局部任务，最终结论却缺乏统一语义。
已有研究提供了相互补充的观察。上下文工程综述把生成、处理与管理纳入同一问题空间；MAST将失败划分为系统设计、智能体失配与任务验证等类别。[1]、[11] 据此不能断言所有协作错误都源于数据治理，但可以提出一个更具体的问题：系统如何证明某份信息在当前任务中仍然适用？仅回答“它来自可信数据库”无法覆盖摘要失真、过期记忆和越权传播。
本文将“面向多智能体的数据治理”定义为：围绕多智能体获取、派生、共享和使用数据的全过程，规定语义、质量、来源、权限、时间与责任条件，并通过运行机制检查这些条件。研究对象包括结构化数据、文档片段、检索结果、记忆条目、任务工件和派生结论。模型训练语料治理、通用组织制度与完整主数据工程仅作为背景，不构成本文的全面讨论范围。
需要区分两条方向。“为多智能体治理数据”解决智能体使用什么、在什么条件下使用；“用多智能体治理数据”利用智能体发现异常、起草规则和提出修复。后者能够向前者提供候选资产，但候选内容仍应经过验证和发布。本文以前者为主线，讨论两条方向如何通过受控流程连接。
图1 研究范围与反馈关系。实线表示正式使用链路，虚线表示治理候选回流；逻辑角色不要求对应不同模型实例。作者绘制。
2 研究方法与证据边界
本文采用结构化叙述综述，而非穷尽检索的系统综述或统计元分析。
来源纳入以“直接回答治理机制问题”为原则：论文应给出可辨认的研究对象或方法；项目应有官方功能与部署说明；产品应有可定位的官方技术文档。搜索摘要仅用于发现线索，正文结论以定向核验的原始页面为依据。无关结果、无法核验的数字、二手排行榜和仅有宣传口号的材料不进入论证。论文版本固定到所读版本，动态文档记录查阅日；实际阅读范围另行列明。
证据分为研究结果、接口或规范定义、实现文档、产品说明四类。它们回答的问题不同：基准可以观察特定设置下的行为；规范说明应遵守的接口；文档说明可配置的能力。三者均不能直接推出某个企业部署已经达到安全或收益目标。本文未部署比较系统，未验证厂商性能，也未构造客户案例；业务案例用于解释设计取舍。
3 治理模型：把可使用条件附着到数据工件
3.1 从数据集扩展到上下文工件
传统目录描述数据集的字段、负责人和血缘，多智能体还会产生临时SQL结果、摘要与中间判断。本文将这些可被后续任务消费的信息对象统称为“上下文工件”。工件并不等于原始文件：同一数据集针对不同时间、粒度和业务目的产生的结果，应具有可区分的标识。否则，下游难以判断两个同名结果能否比较。
本文建议用七类描述组织工件：C＝〈O，S，V，T，A，E，L〉。O标识对象与粒度；S引用语义定义；V标识内容或定义版本；T描述业务时间、有效时间和生成时间；A引用授权策略与使用目的；E记录证据来源及验证状态；L描述保留、撤销与后续处理规则。这是本文参考模型，不是MCP、A2A或现有数据契约标准中的统一字段集合。
图2 上下文工件参考模型。模型上下文只接收必要描述；可信身份与令牌保留在宿主服务，工件中的策略引用不能自行授予权限。作者综合[17]、[20]、[22]、[24]、[26]绘制。
针对可信主体u和任务q，参考准入条件写为：G(C,u,q)＝适用范围满足∧策略允许∧版本兼容∧证据达到任务要求。这里的“满足”由可执行规则、可信元数据和必要的人审共同判断，不能交给模型自行声明。条件未满足时，系统可补充检索、请求澄清、输出带限制的解释，或阻止相应动作；不同风险任务应采用不同处理策略。
七类描述也不意味着每次都把完整元数据塞入提示词。系统可在可信服务中保留完整记录，只向模型暴露与当前任务相关的摘要和引用。压缩允许减少表达长度，但应保留影响结论的限定条件。例如，可以合并重复证据，不能悄悄删去“仅直营门店”“不含税”或“截至上月末”。
更具体地，可把任务依赖写为有向图D＝(N，H)，其中N为任务单元，H为工件交接关系；这与物理智能体通信网络不同。对于每条交接边，生产方声明工件类型、对象范围、版本和状态，消费方检查其是否满足自身输入约束。相同角色可以执行多个任务，一个任务也可以调用多个模型；治理检查应绑定实际工件与主体，避免依赖角色名称猜测责任。这一表达借鉴了CoMemBench对工作流与交接的建模思想，并扩展了组织授权和生命周期要求。[2]
3.2 来源、授权与协作关系必须分别建模
来源关系回答“结论由什么产生”，授权关系回答“谁能在何种条件下做什么”，协作关系回答“任务之间需要传递什么”。PROV提供实体、活动与责任主体的表达；ABAC按主体、客体、操作和环境属性评估授权；A2A描述任务与工件交互。[17]、[22]、[26] 三类关系可以通过稳定标识关联，但任何一类都不足以代替另外两类。
例如，摘要可以追溯到一张受限明细表，却不意味着所有能查看摘要的人都有权查看原表。经过组织批准的聚合发布，可能拥有不同的访问范围；相反，未经审查的摘要可能仍泄露单个客户信息。因此，派生结果的访问范围需要明确的发布或降敏策略。简单复制源权限、取所有源权限的交集，均不能覆盖全部业务情形。
图3 来源、授权和协作关系的不同语义。来源记录和任务边均不直接产生访问权；跨关系关联依靠工件、版本与可信主体标识。作者综合[17]、[22]、[26]绘制。
4 方法现状：六类机制如何分工
4.1 语义契约与可执行质量检查
语义契约应说明实体、粒度、时间、单位、过滤条件和计算口径，并区分“结构合法”与“业务含义成立”。ODCS提供交换契约的结构；SHACL可以验证RDF图约束；DQV提供质量描述方法。[18]、[19]、[20] 这些机制有助于把要求转为可检查对象，但验证器不会自行决定退款应计入哪个月份。业务定义仍需责任主体确认。
Data Product MCP把数据产品发现、业务目的与契约执行接入智能体访问链路，并报告16位专家的定性反馈。[14] 其价值在于把治理检查放到实际查询之前；证据范围则不足以证明复杂业务目的都可由模型可靠裁决。工程上可让模型提取目的和提出解释，由可信规则执行明确约束，并把歧义交给有权限的人员处理。
4.2 记忆组织与选择性共享
A-MEM研究动态笔记关联，Mem0研究记忆提取与整合，Zep研究时态知识图谱。[6]、[7]、[8] 这些工作说明记忆可以被组织成可更新的结构，而不是无限追加的聊天记录。它们主要解决信息组织与利用问题；使用图存储、向量检索或记忆摘要，并不会自动产生组织授权、正式口径和可证明删除。
共享机制应以消费任务的依赖为依据。一个负责解释收入变化的角色可能需要经核验的聚合结果与定义，却不需要完整客户联系方式。CoMemBench将必要工件交接与不适用工件干扰分别操作化。[2] 本文据此建议，同时记录“应交接集合”和“应隔离集合”，并测试遗漏与污染两种失败，避免只优化检索召回率。
4.3 权限、委派与信息流控制
智能体角色名是编排信息，可信用户身份与服务身份是授权依据。MCP的HTTP授权规范约束连接和资源访问，A2A将授权责任留在服务端，二者都不能替应用自动解释企业业务权限。[24]、[26] 每次跨服务调用应明确发起主体、代表谁行动、请求范围及底层执行身份；共享trace或同一团队标签不应成为隐式授权条件。
OPA能够把策略决策从业务代码中分离，但允许或拒绝的结果仍需宿主服务执行。[29] 对数据库查询、文档检索、记忆读取和工具执行，应分别设置检查点，并检查绕过路径。输入带有合法令牌，只说明某个身份通过了相应校验，不能推出它有权使用所有派生信息或完成所有业务动作。
策略缓存也需要版本约束。若服务在授权后长期复用旧决定，用户角色变更或资产撤回可能无法及时生效。参考实现应把主体、操作、资源版本、策略版本和有效条件纳入决策记录，并规定缓存失效与服务不可用时的处理方式。审计日志记录可信决策标识即可，不应为方便追踪而把访问令牌或敏感全文写入日志。
访问控制判断某次读取或操作是否合法，信息流控制进一步约束读取之后的传播。FlowSeal将发布检查放在模型上下文之外，结合来源标签与受控释放；SPA通过先规划执行和带标签的持久化，区分具体值、机密性与完整性标签、规划可见元数据。[35]、[36] 二者提供了超越提示词约束的实现思路，但均有特定威胁模型。SPA明确报告严格完整性控制的效用代价及跨查询攻击覆盖局限。本文据此建议，检查敏感信息能否进入输出、工具参数和后续记忆，并显式定义何时允许降敏或提高可信度；不能因文本经过摘要就自动降低敏感级别。
4.4 来源追踪与证据状态
OpenLineage围绕Dataset、Job、Run记录数据处理事件；PROV提供更一般的生成、使用和责任关系。[17]、[21] 多智能体需要在此基础上区分“原始观察”“模型推断”“候选规则”“已发布定义”。这些状态表明处理过程和组织认可程度，不构成现实世界真假的等级表：已发布定义仍可能引用错误数据，多个智能体重复同一来源也不会增加独立证据数量。
记录应至少支持从结论回到实际消费的版本、查询条件和关键证据。若上游仅保留“已检查”而不保留检查对象及结果，下游无法复核。完整思维过程不是必要前提；可复核输入、可执行检查、明确决策与结果回执，通常比无法审计的长篇推理文本更有操作价值。
4.5 版本一致性与失效传播
时间治理至少要区分事实发生时间、系统获知时间和定义生效时间。时态记忆工作为保存历史提供思路，[8] 但是否允许继续使用旧信息，仍由任务决定。重算最新经营结果与复现上季度董事会报告，可能需要不同版本。定义更新后应定位受影响的工件，并根据任务版本约束重新检查，而非一律把全部历史结果标为错误。
撤销访问、撤回错误定义、删除源数据与清理派生副本也应分别处理。撤销读取权限可能阻止未来调用，却无法让已经流出的文本自动消失。工程上需要结合依赖索引、缓存与记忆清理、重新计算和保留义务，记录处理范围与未完成事项；仅有一个“已删除”布尔字段不足以表达这些状态。
4.6 污染防护与治理资产发布
MINJA研究表明，恶意信息可能经普通交互进入智能体记忆；AgentDojo围绕不可信工具数据开展安全评测。[9]、[12] 隔离综述进一步区分用户、工具、执行环境、智能体与系统之间的边界。[10] 防护不能仅检查最终回答。检索、摘要、记忆写入和跨智能体传递都应保留信任边界，将外部内容与可信指令分离，并限制其影响策略、工具参数和正式资产的能力。
对于智能体辅助治理，较稳妥的链路是“候选—检查—审阅—提交前复核—发布—正式消费”。流水线智能体研究展示了策略约束下提出运维动作的路径，[15] 但业务定义的批准、写权限校验和提交成功仍是不同事实。人审也应展示变更差异、影响范围和依据；在审阅后发生基线变化时，需要按规则重审，而非直接沿用旧批准。
例如，审阅针对定义v3形成修改方案，提交时正式定义已变为v4。系统应检测基线不一致，并按变更影响决定重算或重审，不能只检查“存在批准记录”。单个存储内可以采用版本条件更新，跨服务流程则需要状态记录、幂等标识和明确的补偿边界；这些是本文建议的实现手段，不代表跨系统事务已经获得原子性保证。
图4 消费链路与治理候选链路。策略检查在可信服务实施；外部写操作需遵循具体应用的批准策略，不能从MCP工具接口推断已有人审。作者参考[24]、[25]、[26]、[27]、[28]、[29]绘制。
5 项目与产品现状：按责任边界进行选型
当前实现呈现出分层组合特征。LangGraph的checkpoint与store分别支持线程状态和跨线程存储；DataHub与OpenMetadata通过MCP暴露目录、词汇表和血缘等信息；Graphiti提供时态图能力。[27]、[28]、[30]、[31] 这些项目可以互补，选择时应先确定缺少哪一层，而不是只比较是否具有“Agent”或“MCP”标签。
表1 典型技术组件的职责与验收问题。以下为文档归纳，未执行部署或性能排名。
|
组件类别与代表
|
直接承担的职责
|
仍需集成者解决
|
应检查的证据
|
| --- | --- | --- | --- |
|
元数据：DataHub、OpenMetadata
|
目录、语义描述、血缘访问
|
用户身份传播、业务目的、派生结果策略
|
实际版本、工具清单与授权配置[30]、[31]
|
|
状态编排：LangGraph
|
检查点、线程恢复与存储
|
租户边界、保留期限、正式资产发布
|
状态作用域、存储适配和删除路径[27]
|
|
时态图：Graphiti
|
关联、时间信息与检索
|
认证、访问控制、输入约束
|
库、参考服务器及托管服务分别核查[28]
|
|
策略：OPA
|
外置策略决策
|
决策执行、失败处理与审计
|
实际调用点和不可绕过性[29]
|
|
契约与血缘：ODCS、OpenLineage
|
描述约束和处理关系
|
业务含义确认、消费侧检查
|
契约版本、事件覆盖及责任归属[20]、[21]
|
一个容易误判的例子是Graphiti：其参考MCP/REST服务器README明确说明，生产部署需要由宿主补充身份、授权与租户隔离，分组标识不能替代这些机制。[28] 这属于官方写明的部署边界，不应被描述为对托管服务的漏洞结论。对其他项目也应采用同样的证据标准，区分库功能、示例服务和生产配置。
商业产品技术文档展示了三类组合路径：语义资产与最终用户权限结合、智能体对象与底层工具权限结合、只读数据问答与请求用户凭据结合。[32]、[33]、[34] 这些模式说明治理正进入消费链路，但各自的云环境、版本和工具范围不同。本文仅比较做法，不作品牌优劣判断；具体产品名称保留在引用索引，便于核验原始说明。
图5 从源资产到协作消费的分层责任。图中各层表示待覆盖的功能责任，不代表必须采购同等数量的产品，也不表示现有组件已经自动集成。作者综合[20]、[21]、[24]、[25]、[26]、[27]、[28]、[29]、[30]、[31]、[32]、[33]、[34]绘制。
对于私有化部署，选型还需要检查模型调用是否出网、外部工具如何连接、策略与目录是否可离线运行，以及日志是否保存敏感数据。企业网络位置本身不能提供信任依据。[23] 在本文参考架构中，即使所有组件都部署于内网，跨用户、跨任务和跨服务访问仍需显式判断。
6 评价方法：同时证明必要交接与有效隔离
6.1 现有评测覆盖与空白
记忆问答、任务完成和治理合规需要不同测试。LoCoMo、LongMemEval、MemoryAgentBench有助于分析长期记忆与更新；CoMemBench进一步关注带依赖的工件交接和隔离；AgentDojo提供不可信工具输入下的安全评测视角。[2]、[3]、[4]、[5]、[12] 不能把某个基准上的优势直接命名为“企业数据治理能力”。
表2 代表性研究的测量对象及外推边界。
|
研究
|
主要测量对象
|
本文可借鉴的设计
|
不能直接推出
|
| --- | --- | --- | --- |
|
LongMemEval[3]
|
长期交互中的提取、推理、更新与拒答
|
区分记忆能力类型
|
多智能体访问控制已正确
|
|
MemoryAgentBench[5]
|
增量交互与记忆能力
|
连续输入、更新与遗忘测试
|
删除已传播到全部副本
|
|
CoMemBench[2]
|
任务依赖、必要交接与不适用工件干扰
|
匹配清洁与污染条件
|
企业机密性已完整验证
|
|
AgentDojo[12]
|
不可信工具数据下的任务与安全行为
|
单独测试效用和攻击条件
|
所有业务约束均被覆盖
|
|
Data Product MCP[14]
|
企业场景与专家定性反馈
|
访问前检查业务目的与契约
|
已有大规模因果收益证明
|
|
FlowSeal[35]
|
工具发布边界的信息流控制
|
将强制检查与模型上下文分离
|
所有渠道和语义释放均无泄露
|
|
SPA[36]
|
跨查询带标签状态复用
|
分开记录值、标签和规划元数据
|
严格约束必然保持任务效用
|
CoMemBench报告800个复合工作流，并将终局成功、验证进展、必要交接与隔离指标分开。其交接和隔离指标有各自的适格样本条件；尤其隔离测量使用清洁目标成功的匹配样本。[2] 复用其方法时应保留原有定义，并另外设计企业授权测试，避免把任务不适用性与法律或组织禁止访问混为一谈。
6.2 建议测试矩阵与指标
本文建议以同一业务任务构造匹配条件：正常工件、缺失必要定义、过期版本、错误实体范围、未核验结论与无权访问来源，再分别在链式和并行汇总流程运行。固定数据、模型版本与预算，并设置单智能体、无治理多智能体和分层治理多智能体基线。这样可以观察治理收益来自哪个检查点，也能识别额外流程造成的延迟和错误拒绝。
图6 本文建议的测试设计。矩阵为实验条件清单，没有填入性能数据；污染与越权分别构造，避免混用评测含义。作者参考[2]、[3]、[12]绘制。
表3 本文建议的运行指标。分母为零时记为不适用；以下不是已有基准的官方指标。
|
指标
|
计算对象与分母
|
判断要点
|
| --- | --- | --- |
|
必要交接达成率
|
按约定成功交付的必要工件数／应交付工件数
|
工件存在、版本和状态均符合契约
|
|
不适用信息采纳率
|
被错误采纳的干预样本数／有效干预样本数
|
结合确定性检查与人工核验
|
|
越权披露率
|
发生禁止披露的样本数／有效禁止披露测试数
|
独立于最终任务成功统计
|
|
合法请求误拒率
|
被错误拒绝的合法请求数／合法请求测试数
|
防止以拒绝全部任务获得低泄露
|
|
版本适配失败率
|
违反任务版本要求的结果数／含版本要求的任务数
|
历史复现与最新重算分别判断
|
|
撤销处置覆盖率
|
已完成规定处置的已知受影响副本数／已知应处置副本数
|
同时披露依赖发现范围与未发现风险
|
最终还应报告任务正确性、延迟、调用成本和人工复核量。对低频风险，比例必须同时给出样本数与不确定性范围；零次观察不等于风险为零。自动评审可以辅助分类，但业务口径争议和敏感披露应保留人工复核样本。若不能识别所有副本，撤销覆盖率只能在已知范围内成立。
7 发展方向与可检验判断
7.1 治理从静态描述转向消费时检查
本文判断，目录和契约会继续承担稳定定义，但更多检查将发生在检索、交接和行动之前。原因是同一资产对不同任务具有不同适用条件。可检验的研究问题是：消费时检查能否在相同任务质量下，降低过期信息采纳和越权传播，同时把额外延迟控制在可接受范围？这一判断不要求把所有治理逻辑写入模型提示词。
7.2 从共享更多转向共享有依据的必要信息
协作价值取决于任务结构。智能体扩展研究显示，架构与任务的匹配会影响收益；协作记忆研究则提示更广的信息暴露未必保留隔离。[2]、[13] 本文据此提出：系统应优化“经授权、适用且足够”的交接，而非共享池规模。验证这一判断需要同时观察必要交接、错误采纳、误拒与成本，不能只展示某一项改进。
7.3 从单点删除转向可说明的撤销传播
随着记忆和派生工件积累，撤销将成为跨组件问题：哪些副本仍可读、哪些历史报告应保留、哪些结果必须重算？隐私综述已把查询、中间结果、记忆和消息纳入数据暴露面。[16] 本文建议将依赖发现和处置回执纳入架构，但不假设完整追踪天然可得。后续研究需要明确不透明外部工具、离线文件和分布式缓存造成的残余边界。
7.4 把治理贡献与正式权威分开
多智能体可以协助识别异常、收集解释、提出定义和生成测试；正式权威则来自责任分配、验证与批准机制。以模型与指标治理连接AI工作台的产品方向为例，工作台发现口径缺口后，应生成治理候选，治理侧发布正式定义后再供工作台使用。本文借鉴Nexus与BiSeek的目标产品分工阐释这一闭环，不把其视为完整数据治理平台或实验验证对象。
在这一目标形态下，Nexus聚焦模型与指标治理；BiSeek使用获准资产开展分析，并对已注册、授权且完成适配的外部MCP写操作实行逐项人工审核。这是产品设计策略，不是协议的必然属性，也不是本文对当前版本的验收结论。更一般的技术问题是：审阅、权限校验和提交之间如何保持对象与版本一致，并在执行结果不确定时避免重复动作。
8 局限与结论
本文的局限包括：关键词与语言选择存在偏差，未穷尽所有领域文献；部分论文仅核验摘要与版本，不能承担细粒度实现结论；动态项目及产品文档可能更新；未执行独立部署、攻击测试或收益测量。参考模型没有给出统一的跨系统强一致性实现，提出的指标也需要在真实业务约束下校准。后续实证工作应优先验证授权、版本和撤销三类边界，而非先宣称通用方案成立。
面向多智能体的数据治理，应使数据在跨任务、跨角色和跨时间使用后仍保留可检查的条件。语义契约说明含义，来源记录支持复核，策略服务实施权限，版本与生命周期机制限定有效范围。多智能体可以参与建设这些资产，但正式消费需要独立的验证和责任机制。本文提出的工件模型、三类关系分离和匹配测试方案，为连接这些机制提供了一条可实施、可反证的研究路径。
参考文献
以下列出本文实际采信的来源。论文固定版本；动态项目与产品页面以2026年11月3日查阅内容为准。n.d.表示页面未明确发布日期。阅读范围及局限见配套《采信来源与边界》。
[1] Mei L, et al. A Survey of Context Engineering for Large Language Models [R/OL]. 2025. v2，2025-07-21. [2026-11-03].
[2] Zhao S, et al. CoMemBench: Benchmarking Collaborative Memory Boundaries across Multi-Agent Workflow Topologies [R/OL]. 2026. v2，2026-09-29；预印本. [2026-11-03].
[3] Wu D, et al. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory [R/OL]. 2025. v2，2025-03-04；页面注明 ICLR 2025. [2026-11-03].
[4] Maharana A, et al. Evaluating Very Long-Term Conversational Memory of LLM Agents [R/OL]. 2024. v1，2024-02-27. [2026-11-03].
[5] Hu Y, Wang Y, McAuley J. Evaluating Memory in LLM Agents via Incremental Multi-Turn Interactions [R/OL]. 2026. v4，2026-06-28. [2026-11-03].
[6] Xu W, et al. A-MEM: Agentic Memory for LLM Agents [R/OL]. 2025. v11，2025-10-08. [2026-11-03].
[7] Chhikara P, et al. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory [R/OL]. 2025. v1，2025-04-28；预印本. [2026-11-03].
[8] Rasmussen P, et al. Zep: A Temporal Knowledge Graph Architecture for Agent Memory [R/OL]. 2025. v1，2025-01-20；预印本. [2026-11-03].
[9] Dong S, et al. Memory Injection Attacks on LLM Agents via Query-Only Interaction [R/OL]. 2026. v5，2026-02-12；以修订后题名为准. [2026-11-03].
[10] Jing H, et al. Isolation as a First-Class Principle for LLM-Agent System Safety: Concepts, Taxonomy, Challenges and Future Directions [R/OL]. 2026. v2，2026-09-02；预印本. [2026-11-03].
[11] Cemri M, et al. Why Do Multi-Agent LLM Systems Fail? [R/OL]. 2025. v3，2025-10-26；预印本. [2026-11-03].
[12] Debenedetti E, et al. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents [R/OL]. 2024. v3，2024-11-24. [2026-11-03].
[13] Kim Y, et al. Towards a Science of Scaling Agent Systems [R/OL]. 2026. v3，2026-04-08；预印本. [2026-11-03].
[14] Tonnarelli M, et al. Data Product MCP: Chat with your Enterprise Data [R/OL]. 2026. v2，2026-05-11；页面注明 SummerSoc 2026 作者接受稿. [2026-11-03].
[15] Kirubakaran A M, et al. Governing Cloud Data Pipelines with Agentic AI [R/OL]. 2025. v1，2025-12-24；页面列期刊出处. [2026-11-03].
[16] Lahjouji N, Colaco A G. Agents That Know Too Much: A Data-Centric Survey of Privacy in LLM Agents [R/OL]. 2026. v1，2026-06-25；预印本. [2026-11-03].
[17] W3C. PROV-O: The PROV Ontology [EB/OL]. 2013. W3C Recommendation，2013-04-30. [2026-11-03].
[18] W3C. Shapes Constraint Language (SHACL) [EB/OL]. 2017. W3C Recommendation，2017-07-20. [2026-11-03].
[19] W3C. Data on the Web Best Practices: Data Quality Vocabulary [EB/OL]. 2016. W3C Working Group Note，2016-12-15. [2026-11-03].
[20] Bitol. Open Data Contract Standard [EB/OL]. n.d.. 动态latest页面，按查阅日记录，不声称固定发布版本. [2026-11-03].
[21] OpenLineage contributors. OpenLineage Documentation [EB/OL]. n.d.. 动态文档，查阅日内容. [2026-11-03].
[22] Hu V, et al. Guide to Attribute Based Access Control (ABAC) Definition and Considerations [EB/OL]. 2019. NIST SP 800-162；2014发布，含2019-08-02更新. [2026-11-03].
[23] Rose S, et al. Zero Trust Architecture [EB/OL]. 2020. NIST SP 800-207，2020-08. [2026-11-03].
[24] MCP contributors. Model Context Protocol: Authorization [EB/OL]. 2025. 固定规范版本2025-11-25. [2026-11-03].
[25] MCP contributors. Model Context Protocol: Tools [EB/OL]. 2025. 固定规范版本2025-11-25. [2026-11-03].
[26] A2A contributors. Agent2Agent Protocol Specification [EB/OL]. 2025. 固定规范版本v0.3.0. [2026-11-03].
[27] LangGraph contributors. LangGraph: Persistence [EB/OL]. n.d.. 动态文档，查阅日内容. [2026-11-03].
[28] Graphiti contributors. Graphiti Repository and Deployment Notes [EB/OL]. n.d.. 动态默认分支README，未锁定commit，不声称做部署测试. [2026-11-03].
[29] Open Policy Agent contributors. Open Policy Agent Documentation [EB/OL]. n.d.. 动态文档，查阅日内容. [2026-11-03].
[30] DataHub contributors. DataHub MCP Server [EB/OL]. n.d.. 动态文档；Cloud与Core路径分开. [2026-11-03].
[31] OpenMetadata contributors. Connect to OpenMetadata MCP Server [EB/OL]. n.d.. 实际解析为文档v2.0.x；服务器1.1.0；协议2025-03-26. [2026-11-03].
[32] Databricks. Set up a Genie Agent [EB/OL]. 2026. AWS文档；页面更新2026-10-09. [2026-11-03].
[33] Snowflake. Cortex Agents [EB/OL]. n.d.. 动态文档，查阅日内容. [2026-11-03].
[34] Microsoft. What is a data agent? [EB/OL]. n.d.. 动态文档，页面有授权提示但正文可读. [2026-11-03].
[35] Shim M, et al. Confuse the Model, Control the Flow: Understanding and Mitigating Privacy Leakage from LLM Agents with Information Flow Control [R/OL]. 2026. v1，2026-09-12；预印本. [2026-11-03].
[36] Girrens D, Wang G. SPA: Securing Persistent LLM Agents Across Queries with Plan-First Information-Flow Control [R/OL]. 2026. v2，2026-09-04；预印本. [2026-11-03].
