01
普通上传
适合常见输入文件直接提交，先进入受控上传链路，再进入后续处理或人工确认环节。
File Upload & Result Delivery
文件上传 / 结果下载
Execution Input / Output很多真实任务不是只返回一段文本，而是要接文件、处理文件，再交回结果文件。
重点说明用户会实际接触到的上传、处理和下载体验。
ExecGov 当前已经支持把 输入文件、批次状态、处理产物和结果下载 接成一条对客户可理解的执行链路。重点不是“能不能传文件”，而是 文件进入后如何被受控处理，并把结果按交付边界交回来。
普通上传大文件分片批次状态结果下载
EXECGOV // FILE FLOWDOC 09
const fileFlow = ['file_upload', 'batch_track', 'process', 'result_download']const largeFileFlow = ['init', 'chunk_transfer', 'merge_complete']const resultPolicy = 'controlled_result_delivery'
FILES IN / TRACEABLE PROCESS / RESULTS OUT
02
大文件分片
如果文件较大，可以按分片方式上传，避免一次性传输失败后整包重来。
03
批次状态
文件不是传完就消失，而是归入批次，便于后续处理、追踪和结果对照。
04
结果下载
如果任务产出的是文件，平台可以把结果文件作为正式产物入口交给客户下载。
End To End
从上传到拿到结果，一条链路怎么理解
01. 提交输入文件
客户在当前项目开放的上传入口提交输入文件，入口形态以具体交付项目为准。
02. 文件进入受控批次
文件会先进入受控批次，方便后续处理、追踪和结果对照。
03. 按项目规则处理
平台按当前项目配置决定是直接处理、等待处理器执行，还是进入更长的业务流程。
04. 查看批次与状态
用户可以直接看到“这一批文件当前到了哪一步”。
05. 生成结果产物
如果任务会产出 Excel、报表、汇总文件或其他正式结果，平台会把它整理成可交付入口。
06. 下载或继续使用
用户拿到结果文件后，可以继续下载、复核，或进入下一段业务动作。
Chat Binding
在对话执行里上传文件后，脚本怎么知道该读哪一个文件
不是靠脚本自己去猜
当前做法不是让脚本去扫整个上传目录，也不是让它靠文件名碰运气，而是把这次上传形成的批次号显式挂到当前对话执行里。
页面入口已经收口
用户现在可以直接在对话执行底部快捷区点击“上传文件”，按钮紧挨“上传脚本”，旁边的说明图标会提示这批文件会绑定到当前会话。
确认执行时会带入当前批次
上传完成后，当前对话会保存这次 uploadBatchId。当用户确认执行某个 Skill 时，后端会把这批文件的快照一并带进这次执行。
脚本拿到的是这次执行的文件快照
脚本运行时会收到当前批次号、输入文件列表和批次目录信息，所以它处理的是当前这次确认执行绑定的文件，而不是别的历史批次。
| 环节 | 当前怎么做 | 作用 |
|---|---|---|
| 上传文件 | 前端生成受控批次 | 保证文件先进入可追踪批次，而不是散落上传。 |
| 触发对话 | 当前会话带上 uploadBatchId | 明确这次执行到底要消费哪一批输入。 |
| 确认执行 | 后端回填 fileService 快照 | 让执行器拿到批次号、目录和输入文件清单。 |
| 脚本运行 | 只读取当前绑定批次 | 避免误读别的批次、别的客户或别的历史文件。 |
| 脚本里直接读什么 | 当前含义 |
|---|---|
EXECGOV_UPLOAD_BATCH_NO | 当前绑定批次号，用来判断这次执行到底消费哪一批输入。 |
EXECGOV_UPLOAD_INPUT_FILES_JSON | 当前批次输入文件数组，脚本可以直接拿到 fileName、fileId、大小等信息。 |
EXECGOV_UPLOAD_FILE_SERVICE_JSON | 完整的文件服务快照，包含 batchNo、inputFiles 等上下文。 |
EXECGOV_SKILL_INPUT_PAYLOAD_JSON | 本次执行的完整输入载荷，里面同样会保留 uploadBatchId 和 fileService。 |
当前 Python / Shell 执行器都会把这些变量注入运行环境。如果用户重新上传了一批新文件并再次确认执行，新的批次就会覆盖旧批次。脚本应始终按当前执行上下文里的批次信息读取输入，而不是凭“最新文件”这种不稳定规则处理。
Fit
什么场景更适合走这条链路
| 场景 | 为什么适合 | 适合程度 | 说明 |
|---|---|---|---|
| 先上传原始文件，再生成报表 | 输入和输出都是文件 | 当前已适合 | 例如结果表、汇总表、导出文件、处理后产物。 |
| 文件较大，担心一次传输失败 | 需要更稳定的上传方式 | 当前已适合 | 可按大文件分片方式处理，而不是整包重试。 |
| 需要保留一批输入文件的处理状态 | 便于追踪批次和结果 | 当前已适合 | 平台强调批次视角，而不是只显示“上传成功”四个字。 |
| 只需要文本问答，不涉及文件 | 文件链路不是重点 | 不必强行使用 | 这类场景先看智能执行和 AI 推荐路径即可。 |
Current Scope
当前适用范围
- 不是所有项目都默认开放上传中心，要看当前交付范围。
- 如果项目包含文件处理，可以提供文件上传与结果下载链路。
- 如果项目涉及长耗时任务，结果返回方式会按项目体验设计继续增强。
- 文件链路是业务数据处理入口，不等于脚本热更新入口。
Safety Rule
使用时需要注意的安全边界
- 客户只能看到自己项目开放的文件入口和结果产物。
- 不同客户之间不会共享上传结果或下载入口。
- 平台优先保证租户边界、结果可追踪和交付可说明。
- 如果结果涉及更高安全要求，平台会按项目边界控制可见范围和下载方式。
Next Read
交付物与接入资料
文件链路只是交付链的一部分。结合客户流程、交付物与文档入口、客户接入准备清单查看，更容易完整评估项目。