Glean新增成果版本触发器：发布了新版本，下游Agent读到哪一版？

Glean于2026年11月3日的567版本记录中介绍：当一份Glean成果（artifact）发布新主版本时，可以自动运行Agent。在构建器选择New artifact version内容触发器，并指定要监听的成果。本文于11月5日核验。

这条发布说明未给出完整事件载荷、重送次数、顺序保证、版本快照读取方式或历史补发合同。它也没有说任意文字编辑或保存草稿都会形成这类事件。接入时应使用真实界面和可取得的记录确认这些条件，不能由名称推导实现细节。

以下字段、流程与演练均为本站建议。若平台没有提供其中某项证据，应记录缺项，并缩小自动执行范围，而不是假设产品里存在相应API。

逐版处理适合需要保留每次正式变更依据的任务，例如为每版内部周报形成一份对应说明。只处理最新适合当前状态看板，但也必须解释被跳过的版本。两种策略会产生不同结果，不能等发生乱序后才临时决定。

不能只凭事件到达时间判断新旧。发布顺序和队列顺序可能不同；项目应采用来源实际提供的版本顺序或经核实的发布记录。版本标识只是引用时，也不要自行按字符串大小排序。

两种策略都应在结果中保留实际使用的来源引用。若允许改为读取最新内容，应明确说明这次任务已换了输入，不能把第三版分析标成第二版的结果。

官方内容触发器文档说明，运行基于激活用户的数据与权限，事件内容可以作为输入，运行历史可供查看。这些通用说明不等于本次新触发器一定提供可直接读取的历史快照。应先用测试成果检查实际能够取得什么。

如实际接口只能打开当前内容，无法取得事件对应的历史版，逐版自动处理就缺少必要输入。可以先保存可用证据并转交，或由业务明确采用仅最新策略。不要让模型凭记忆补出丢失版本。

可保留快照时，也要遵守资料授权与留存规则。任务记录应标出读取时点和内容依据；一个哈希只能帮助比较内容，不能证明来源权限、生效状态或业务正确性。

以下演练未执行。假设测试成果R为内部周报，A2、A3仅是教学版本标签，不是产品字段或版本命名规则。下游只生成测试摘要，输出到独立位置S，不对外发送、不改业务记录；使用有权访问R与S的测试账号。

重复与乱序是要模拟的故障，不是本文声称Glean必然会出现的行为。若平台无法注入事件，可在自建下游处理层模拟，并写明测试只覆盖这一层。不能用下游测试证明托管触发器的投递合同。

最后逐项核对输入版本、任务状态和实际输出。一次运行显示完成，只说明运行状态；摘要是否对应正确版本、是否写到允许位置，仍需结果证据。

最容易检查的起点是单向交接：监听R，输出S，S不再回写被监听的R。确实需要双向更新时，画出依赖关系，定义来源与派生内容的区别、停止条件及最大连续运行次数。不要仅靠提示词要求不要循环。

去重范围也要先明确。同一来源版本给不同授权用户生成不同结果，可能是两项合法任务；同一用户、同一目标的重送才可能应关联原任务。接入方定义去重键时，应覆盖业务范围、来源版本、目标及处理类型，并保证并发时不会同时放行重复写入。具体幂等实现可查本站已有指南。

若输出请求超时，保留原任务与目标记录，先查询是否已保存。结果未知时，不生成新任务号再次发布。也不要为了判断能否重复而请求无关用户的结果，查询入口仍须检查当前权限。

新版发布后旧版结果是否保留、撤回或标为历史，由业务规则决定。删除原成果不自动证明下游副本已删除；若有撤回要求，另行追踪派生输出并核验传播。

先准备一份测试成果、两次主版本发布记录、可用的输入证据和独立输出位置。确认能识别版本后，再选处理策略，完成上述故障演练。无法核实历史读取、投递或恢复能力时，先生成草稿，并把缺项交给平台支持或系统负责人确认。

企业需要AI随心创协助梳理AI／FDE实施时，可以带上现有成果流转图、脱敏样本和期望下游动作，讨论工具接入、版本交接与试点验收。服务范围以本站企业AI服务页为准。