Gemini 4 Argon：长时间运行的 AI 任务，怎样才算真正交付
Gemini 4 Argon 支持后台执行和长篇输出。创始人需要验收完整结果、任务状态、人工审核、数据留存与实际成本。
Google 于 10 月 13 日向开发者开放 Gemini 4 Argon。官方文档描述了共享的百万 token 上下文窗口，以及通过后台执行生成超过常规同步请求 65,536 token 限制的内容。对于要交付研究材料、技术方案或合同评估草稿的产品，这很诱人：客户提交任务、离开页面，稍后回来取结果。但“模型可以在后台继续输出”和“客户收到可信赖的完整成果”是两件事。
本文面向考虑推出长任务功能的非技术创始人和小团队。你会得到一份任务验收约定、一个具体场景和可复用的上线表。核心判断是：提供商把交互标记为完成，并不等于客户任务完成；产品还必须拿出完整、可审核的成果，或者诚实呈现失败状态。下文案例和门槛是建议的测试方法，不是 YBuild 的实测结论。若用户只需即时短答，就没有必要为了新模型能力把流程改成后台作业。
1. 把模型发布信息改写成客户承诺
按 Google 的模型说明，Argon 可接收文本、图片、视频、音频和 PDF，输出文本；它列有函数调用、结构化输出、文件搜索、代码执行，以及预览中的电脑操作能力。同时，图片生成和 Live API 并不支持。这些是可用的组件清单，不代表每位客户都需要一百万 token 的报告，也不证明长报告前后没有矛盾。
先写清用户实际委托的工作。“根据五份获准使用的资料，草拟一份供采购经理审核的供应商评估”比“用最强模型做深度工作”更能验收。注明读者是谁、报告要支持什么决定、资料范围、交付时间与格式。实时客服对话里，一份几分钟后才到的长答案可能违背产品承诺；需要第二天审阅的工作文件，则可能适合后台执行。前提是客户能够离开再返回、知道任务处于什么阶段，并看清“正在生成”和“已经通过审核”的区别。
迁移指南解释了超长输出如何分段继续。它改变的是可行的输出长度和执行方式，不能替应用管理客户授权、通知、费用、文件范围及故障恢复。浏览器关闭、提供商暂停、资料中途修改、最后一节未成功拼接，都仍是产品团队要负责的情形。把“AI 会把工作做完”写到销售页之前，先请构建者演示这些状态。Google 的发布介绍列有复杂领域的性能主张。它可以让你决定是否试验，不能替你的客户文件、审核标准和等待时间做预测。第一轮只选一项边界清楚、能由人判断结果的工作。测试材料中还应有缺失或互相冲突的资料，因为模型对简单样本写得流畅，不足以说明它会在证据不足时停下来。
2. 分清四个容易被“完成”掩盖的概念
交互是模型提供商记录的一次请求及执行过程。产品任务是你的应用记录的客户目标、资料权限、状态、负责人和交付物。输出步骤是交互生成的一部分；长输出可能包含多个步骤。验收则是产品按预先写好的规则判断，拼接后的成果是否可以交给客户使用。四者相关，但不能互换。模型交互完成时，报告仍可能缺少引用、用了旧文件，或尚未经过合格人员审核。Google 的后台执行文档写明，设置 background: true 后会返回交互 ID，客户端可以轮询状态、接续进度或重新连接。文档列出 in_progress、requires_action、completed、failed 和 cancelled 等状态。应用还需要自己的任务状态：已提交、准备资料、运行中、等待客户操作、拼接结果、等待审核、已验收、已拒绝、已归档。具体名称可调整，但界面和客服工具都必须如实反映阶段。
一个绿色的“完成”徽标太容易混淆。它表示模型写完了，服务器拿齐所有输出段落，文件成功生成，审核员认可，还是客户已经下载了最新版本？对用户说“生成完成，待审核”，往往比“项目完成”更有帮助。状态页最好标明上次核对时间，特别是客户断线后，应用重新取回结果的情况。
交互 ID 是恢复线索，不是客户查看别人任务的通行证。应用必须把它绑定到自己的任务和租户记录，查询时仍做正常的账号鉴权。若客服能查看任务，也应只给履职所需的状态与来源信息；默认打开全部私密原文既没必要，也可能违背客户承诺。
3. 开始生成前，先定义完整交付物
长输出最隐蔽的错误，是应用把“目前收到的文字”直接当成最终文件。Google 的Argon 长输出说明指出，超过 64K token 的结果可能经过多个续写阶段，每阶段会增加一个 model_output 步骤；交互完成后，调用方需要把所有相关文本拼接起来。如果应用漏取最后一段、在拼接处重复一段，或下载文件少了结论，即使模型端完成了，客户收到的仍是残缺品。
发送请求前列出交付结构。供应商评估可能需要执行摘要、条件对照表、证据附录、待确认问题和资料版本。验收规则包括必需章节、重要断言的依据、内部一致性、语言，以及对未知事实的清晰标记。字数本身不是质量指标。资料无法回答关键问题时，一段有依据的“无法确定”可能比十页笃定的推荐更正确。
Google 的结构化输出文档说明可要求符合指定结构的结果。但字段齐全，不等于业务判断正确。一个 JSON 对象即便能够解析，仍可能把不存在的合同条款归给供应商。用 schema 防止字段缺失，再用独立的资料核查字段内容；同时保留人能阅读的决策记录与来源链接。
给输入和输出都留版本。至少记录资料快照或稳定 ID、验收规则版本、模型 ID、关键生成设置与拼接程序版本。若生成期间资料更新，不能悄悄混用新旧证据。要么按原快照完成并标明时间，要么明确创建新任务版本。创始人无需亲自设计数据库，但应要求团队能解释：客户看到的那份文件，究竟根据什么资料制作。
可以显示进度预览，但必须让用户一眼认出它尚不可用。部分文字很容易在最终的限制条件出现前就被复制进邮件。预览宜标注“不可作为最终结果”，并在可行时暂时关闭正式导出。若产品无法清楚区分草稿片段和最终文件，宁可等拼接及校验结束再展示。
4. 让任务状态围绕客户控制设计
后台执行解决的是连接容易中断的问题，不会自动设计你的产品界面。官方文档说明，普通 HTTP 连接可能超时，交互 ID 可用于以后取回结果。客户需要的却不止一个加载圈：任务名称、提交时间、资料范围、当前状态、是否需要自己操作，以及安全离开和返回的入口。通知只需说明状态变化；不要把敏感生成内容放进邮件标题或手机推送预览。
requires_action 要单独处理。模型调用工具可能需要确认，或缺少必须的信息。界面应说清楚等待客户决定什么、不回复会怎样，不要一律显示“AI 正在思考”。暂停中的任务可能失效，迟来的回答也可能引用过期资料。用普通语言说明等待期限，并允许客户拒绝某个动作，同时保留之前的任务记录。
取消和重开同样需要定义。客户在运行中取消时，之后才到的提供商结果不能被应用当成已批准交付。如果客户换了一组文件重新开始，应该生成新任务版本，而不是覆盖旧记录。保留足够解释争议的历史，同时遵守约定的留存期限。取消生成，不代表提供商已经忘记收到的输入，也不等于应用里存着的派生文本已经删除。
Interactions API 概览说明可用previous_interaction_id 关联服务端会话历史；但工具、系统指令和生成设置只属于当前交互，需要时应再次指定。技术上这是一条参数规则，产品上却关乎承诺：后续请求不能悄悄失去供应商限制、输出标准或审批条件。请构建者演示第二轮请求的实际配置。客户看到的是同一个项目，规则就应持续有效。
短暂超时也不能让应用重复提交收费任务。建议先在应用里记录“准备创建的任务”，再关联提供商 ID；如果请求结果不确定，先核对已有记录和提供商状态，再决定重试。这是应用层的要求，不是模型自动提供的保证。若流程会调用工具或产生外部文件，重复执行的后果更需要事先演练。
5. 一个必须允许停下来的具体场景
假设 CedarBrief 是一家虚构的两人公司，帮小型采购团队比较软件供应商。客户上传五份获准使用的方案 PDF，要求明天拿到决策备忘录。文件里有价格表、服务条款和互相冲突的保修表述，团队因此考虑使用较长的后台任务。CedarBrief 没有 Argon 实测数据；它需要验证：系统能否交出可审核的草稿，不捏造价格、不漏掉取消条款，也不把完成通知发错人。
测试材料包括一份普通方案、一张扫描价格表、一页已被替换的旧报价，以及缺失的服务等级附件。合格备忘录要识别旧报价、链接当前条款、把缺少的附件列为未解决事项，并在补齐关键证据前避免给出最终供应商推荐。审核员检查拼接后的完整文件，而非页面上的局部预览。验收目标不是“交互状态变成 completed”，而是“产品交付了范围正确、内容完整、能看清不确定性的草稿”。
接着让客户提交后关掉浏览器。再次登录时，应看到同一个任务标题、资料快照和真实状态。如果生成已完成，应用应取回全部输出步骤，只拼接一次，并标记“待审核”；刷新页面不能额外创建第二次付费交互。如果提供商失败，页面应说明草稿不可用，提供重试或联系客服的路径，并按已承诺的留存规则处理资料。
再加入资料变化：销售人员在任务运行时上传新版价格表。除非它属于客户先前批准的快照，现有任务不能暗中使用新文件。客户可以决定以哪一版条款重新发起任务。旧备忘录可以标记“已过时”，但不应装作它从未存在。“最新版本”必须有可核对的来源，而不能是新旧材料的未知混合。
最后测试拒答：附件缺失时，模型仍可能写出很流畅的推荐。如果界面把它标成“已批准”，就是产品失败。正确状态是列出尚待确认的事实，让客户补充或暂停。这是虚构场景，用来检验提供商输出与客户决策之间的交接，并不是说 Argon 一定会犯这个错误。
6. 把留存、隐私和访问写进任务约定
长任务常涉及长文件；后台执行还意味着提供商需要暂存交互，供应用日后取回。Google 的后台执行说明称，默认 store=true 会在项目存储中保存七天；即使 store=false，为了取得结果仍会保存 24 小时。这是提供商侧的说明，不包括应用日志、文件仓库、邮件系统、备份或客户自己下载的副本。不能因为设置了一个参数，就宣称“任何内容都不会存储”。
为这项功能画一张数据清单：原文件、提取文本、提交的提示、提供商交互、局部输出、最终文件、审核意见、遥测和备份。逐项写明存放位置、可访问角色、保留期限，以及删除和导出各意味着什么。多组织产品还要证明，猜到交互 ID 也无法访问其他客户的任务。客服查看敏感内容应受角色限制，并留下记录。“只是草稿”不是忽略这些问题的理由。
Interactions API 文档提供可选的服务端会话状态管理。让提供商保留历史，或每次自行发送完整历史，会改变留存与故障恢复方式。把实际选择写在供应商任务说明里。如果客户合同要求更窄的数据处理边界，应查看提供商与部署配置的具体约定，不能从模型名称推断。创始人至少应要求团队用一个示例任务演示完整数据流和删除请求。通知内容要克制。“草稿已准备好供审核”通常就够了。把开头一段发到共享邮箱，可能泄露客户资料。同样要检查进度预览、分析系统和错误日志。故障报告应能指出任务、阶段和下一步，而无需把私密 PDF 复制进客服工单。若客户需要审计记录，事件表应区分谁查看了内容、谁改变了状态。
留存还影响体验。如果偶尔使用的客户回来时，提供商结果已过期，应用必须说明自己是否仍有最终文件、任务是否要重新运行、重跑是否另计费用。不能仅凭提供商保存交互七天，就推定可以向客户承诺七天的完整服务；应用自己的任务记录和交付文件可能需要不同的期限。
7. 把验收质量、等待时间和成本一起算
Argon 迁移指南建议按工作负载测试低、中、高思考等级，必要时提高输出预算，超过 64K token 的输出使用后台执行。它也指出旧的显式缓存调用不适用；缓存文档说明隐式缓存及缓存命中 token 的查看方法。这些会影响成本和等待时间，但不能代替客户验收来决定最佳配置。先准备一组固定的代表性任务。把提供商调用、续写阶段、重试、审核分钟数、资料修补和客服处理都算入“得到一份被接受的成果”的成本。以同类任务的总投入除以实际被接受的任务数，而非仅看每 token 价格或 HTTP 成功率。分别记录从提交到可审核文件、等待客户回应、审核到最终验收的时间。更便宜的 token 若换来大量人工改稿，服务未必更便宜。
价格页及注明时间的模型指南提供预算输入，也提示有阶段性价格；它们不是永久报价，更不是利润预测。向客户定价前，应确认自己账号适用的费率。超长输出可能消耗大量输出和思考 token。让模型“尽可能多写”只会让账单难以预测，还可能把真正的结论埋在冗长文本里。还要看容量。速率限制文档说明限制随模型和使用层级而变。内部只有一名测试者跑通，不代表十名客户都能在截止时间前提交大任务。记录排队时间，以及容量不足时用户实际看到的失败状态。若当前层级撑不起承诺，就限制受理量、安排运行时段，或延后推出功能；不能无限期显示“处理中”。
质量评估按任务规则来：必需章节是否齐全、关键主张是否有依据、不确定性是否标出、有无未经许可的外部动作、拼接是否完整、审核员要花多少力气。按文件类型和资料难度分组，避免平均值掩盖扫描表格和冲突条款。小样本中没有观察到严重错误，是开始，不等于生产风险为零。停止条件应在看结果之前写好。
8. 一张创始人也能使用的验收表
把这张表交给开发者和最终批准客户交付的人。它是本文建议的工作文档，不是 Google 认证的检查清单。试点开始前填写右列；暂时没有证据的格子可以保留“未确认”，因为这本身就能阻止草率上线。
| 验收关口 | 应留存的证据 | 创始人要作的决定 |
|---|---|---|
| 客户任务 | 用户角色、目标决定、截止时间、获准资料 | 真的需要长任务吗？ |
| 输入边界 | 资料 ID 与版本、权限、排除项目 | 这些资料可以处理吗？ |
| 执行记录 | 应用任务 ID、提供商交互 ID、模型与配置版本 | 断线后能找回同一次运行吗？ |
| 状态含义 | 已提交、运行中、待操作、失败、拼接中、待审核 | 每个标签都真实吗？ |
| 完整性 | 所有输出步骤、必需章节、无重复拼接 | 是否已有完整文件可审核？ |
| 证据 | 重要断言旁的来源、明确标出的未知事项 | 审核者能复核推荐吗？ |
| 控制 | 取消、修改、拒绝动作、创建新版本 | 客户能安全改变方向吗？ |
| 数据生命周期 | 提供商和应用的留存、访问、导出、删除、通知内容 | 符合销售承诺吗？ |
| 经济性 | 被接受任务成本、审核时间、排队与重试 | 这项服务值得持续运营吗？ |
| 恢复 | 提供商失败、结果到期、重复提交、资料变更 | 能恢复且不虚报完成吗？ |
每一行都指定负责人。创始人负责客户承诺和预算，工程人员负责拼接与状态核对，合格审核者判断证据是否足够，隐私或安全负责人核查处理边界。小团队里一人可以兼任，但责任不能因此消失。供应商若说“模型会自动处理”，就请它用刻意设置的困难样本现场演示。
表格应与一份实际任务记录放在一起。即使不是开发者，也应能讲清：客户批准了哪些资料、提供商是否完成、拼接是否成功、审核员拒绝了什么、客户最后拿到哪版文件。若团队只能拿出绿色状态徽标的截图，试点还没证明交付能力。
9. 接纳真实客户任务前，先演练失败
在安全的测试环境中做几项小演练：提交后断网、取回结果中断、提供商执行失败、一份资料不可用、人工确认迟迟不到，以及变更资料版本后重新发起任务。除非另有批准的测试配置，不要把真实客户资料或外部写入动作带进演练。目的在于检查用户看到的状态与保留下来的证据，不是宣称提供商永远不会失败。
必须单独测结果拼接。按长输出说明，Argon 的长回复可能有多个 model_output 步骤。设置一个关键末节只在后续步骤出现的样本，确认下载文件恰好包含它一次、中间结果没有被标成最终文件、局部取回失败不会覆盖已经完整的成果。任务记录里应有拼接程序版本，出错时才查得清楚。
还要测 requires_action：用户应看见请求内容、可能后果、拒绝入口和期限。提供商 failed 与业务审核未通过要分开，前者是没能生成，后者是生成了文件但不符合验收规则；客服处理方式不同。取消后不能继续把迟到结果发给客户，但留存数据仍按既定生命周期处理，不能暗示点击取消等于全部删除。
最后测一种“模型没错、产品却错了”的情况：预览隐藏关键限制、下载链接损坏、完成通知发给错误账号，或展示旧资料却不标日期。这些属于应用缺陷，不是模型基准测试会发现的问题，对客户同样有害。扩大试点前，至少让审核员在受控样本中找到并解释一类这种缺陷；若团队连测试中都看不见它，生产环境更难响应。
10. 什么时候不该做长输出功能
客户确实需要较大的交付文件、能容忍等待，而且有人具备审核资格时，长后台任务才值得考虑。研究资料包、技术迁移方案和多文件比较可能符合条件。实时聊天回复、紧急客服答复、低风险摘要通常不符合。内容更多，可能只增加审核负担。Argon 提供很大的窗口，不代表产品必须把它填满。
如果团队说不清“合格成果”是什么，不能固定来源版本，无法保护访问，或没有失败后的恢复路径，就应暂缓发布。模型能力不能让一个模糊承诺变得可衡量。先推出范围较窄、有人接手的工作流，也许更稳妥。若现有短稿流程已经可靠，还应把长任务与这个基线比较，而非默认“写得更长”就是进步。
今天可以先写一页试点说明：一项客户任务、一套获准资料、一份验收规则、每个状态转移的负责人，以及一次恢复演练。请构建者同时展示成功交付和失败或残缺的运行。只有当团队能解释客户拿到什么、哪些仍不确定、取得一份合格成果花了多少成本、用户怎样停止或修改，才扩大适用范围。后台执行的价值，是让工作可以在屏幕之外继续，而产品仍能在屏幕之内对结果负责。