Agent 升级后，谁来复验文档任务？
一项文档任务已经验收：员工让 Agent 根据项目材料生成周报，结果保存在团队空间里，项目成员可以打开。过了一段时间，Agent 或连接器升级了。产品方说编辑器正常，集成方说接口能调用，业务同事却发现结果没有放进原来的项目目录。此时，应该找谁复验？
这是一个假设场景。它揭示的采购问题是：首次交付有人负责，不代表每次变化以后仍有人对完整任务负责。评估文档产品、SDK 和 Agent 时，建议把“谁提供什么”再往前推一步，约定“谁改变什么、交什么验证记录、由谁确认可以继续使用”。
先画清交付范围，再谈升级责任
企业内部团队直接使用文档、空间和组织权限，可以先看办公套件私有部署。这条路线交付的是协作平台。已有业务系统需要嵌入编辑、预览或文档处理能力，则应单独评估文档中台与 SDK 接入。
这不是两种叫法的差别。石墨文档中台开发文档明确区分：业务系统负责用户、文件、权限相关的业务流程，文档中台负责编辑器、预览渲染、格式处理和文档协作。加入 Agent 后，还需要落实任务如何转成调用、如何选择资料、如何处理结果的连接部分。它可能由企业自建，也可能由集成服务方提供，采购时应写出实际承接者。
以下是可用于采购沟通的责任划分建议，不代表石墨或任何 Agent 已提供特定连接器、升级服务或服务等级承诺。实际范围应由项目方案和交付约定确认。
三份“通过”，回答的是三个问题
- 产品提供者：自身能力是否按说明工作？
例如变更涉及编辑器或文档服务，应说明受影响能力、版本范围和自身验证结果。企业需要的是可对应到当前交付版本的说明，不能用另一个环境的演示代替。
- 连接维护者：原来的调用关系是否仍然成立？
例如 Agent 的工具参数、调用方法或结果处理有变化，维护者应核对文件标识、身份传递、保存位置和异常处理是否仍符合原约定。只证明某个接口返回正常，尚未回答这些映射有没有改变。
- 企业验收负责人：业务同事能否完成原来的任务？
由企业指定的负责人组织相关方，在约定环境中复跑任务并收集证据。业务代表确认资料与结果，IT 核对身份和访问范围；最终由明确的负责人签收。采购不一定要增加三个供应商，但不能把这三层确认都写成含糊的“系统正常”。
版本号可以帮助缩小检查范围，却不能替代这些证据。例如，采用语义化版本规范的软件以公开 API 为兼容性讨论对象，并区分不兼容修改、兼容新增和修正。该规范并没有替企业定义“周报任务验收通过”。先核实组件是否采用这套规则，再阅读它的具体变更说明；不要从一个版本号推导整条业务流程可用。
用一次升级，把责任交接跑出来
仍以虚构的周报任务为例。首次验收时保存一份基线：所用 Agent 与模型配置、连接器及文档服务版本、测试账号角色、样例资料、输出位置和通过条件。测试材料使用可公开的虚构内容，避免把生产资料复制进供应商排障记录。
- 升级前：发起方列出变化。写清改了哪个组件、为什么改、影响哪些调用，通知负责连接和验收的人。若模型无法固定版本，至少保留可获得的模型标识、关键配置和测试时间，明确这一限制。
- 试验环境：先确认接口，再复跑任务。验证可以读取指定资料并生成结果，再检查周报是否回到约定目录、项目成员是否能打开、无权账号是否被拒绝。生成内容可能有措辞差异，验收应比较事实、来源和关键内容是否满足要求，不能只比文字完全相同。
- 签收前：把失败归到具体环节。若编辑器可用而结果落错目录，先查连接中的文件与目录映射；若同一账号直接访问和经 Agent 访问表现不同，保留两条路径的证据共同定位。症状只能提供排查线索，不能直接判定是哪一方的责任。
- 验证未通过：停止扩大使用范围。保留已确认可用的人工操作路径。是否回退组件，应先核实数据与配置兼容性，再按既定变更流程决定；不能假设“装回旧版本”就能恢复全部数据。
这里新增的不是再做一遍产品演示，而是验证一次真实的责任交接：谁发出变更通知，谁提供组件记录，谁处理连接差异，谁有权确认企业任务恢复可用。
采购附件可以从这一段开始
本任务的受测组合、测试环境、账号角色和通过条件作为验收基线留存。任一相关组件或连接配置变化时，由变更发起方说明影响并通知约定人员；产品提供者提交自身验证依据，连接维护者提交适配检查结果，企业指定负责人组织完整任务复验并记录结论。未通过时，记录剩余问题、处理负责人和可用替代路径。通知时间、支持周期、费用及回退条件，由双方按项目实际情况另行确认。
这段文字是需求讨论样例，不能替代项目服务条款。尤其要补上姓名或岗位、接收通知的渠道以及可访问的证据位置，否则“共同负责”仍容易变成无人收尾。
把问题带进下一次演示
如果你为内部团队采购 Drive 或私有化办公平台，先选择一项日常文档任务，再让方案提供者说明：未来 Agent 入口换了，哪些已存文档、权限和操作路径仍由原平台承接，哪一段连接需要重新验证。若目标是把文档能力嵌进现有应用，则另列 SDK、业务系统和连接维护的交付范围。
可在预约演示时带上当前系统、拟接入方式、一项样例任务和计划变化的组件，请方案方围绕这条链路确认产品范围与复验安排。先把持续可用的责任写清楚，才更容易判断一次演示之后，方案是否适合长期使用。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。