01
普通上传
适合常见输入文件直接提交,先进入受控上传链路,再进入后续处理或人工确认环节。
File Upload & Result Delivery
重点说明用户会实际接触到的上传、处理和下载体验。
ExecFabric 当前已经支持把 输入文件、批次状态、处理产物和结果下载 接成一条对客户可理解的执行链路。重点不是“能不能传文件”,而是 文件进入后如何被受控处理,并把结果按交付边界交回来。
01
适合常见输入文件直接提交,先进入受控上传链路,再进入后续处理或人工确认环节。
02
如果文件较大,可以按分片方式上传,避免一次性传输失败后整包重来。
03
文件不是传完就消失,而是归入批次,便于后续处理、追踪和结果对照。
04
如果任务产出的是文件,平台可以把结果文件作为正式产物入口交给客户下载。
End To End
客户在当前项目开放的上传入口提交输入文件,入口形态以具体交付项目为准。
文件会先进入受控批次,方便后续处理、追踪和结果对照。
平台按当前项目配置决定是直接处理、等待处理器执行,还是进入更长的业务流程。
用户可以直接看到“这一批文件当前到了哪一步”。
如果任务会产出 Excel、报表、汇总文件或其他正式结果,平台会把它整理成可交付入口。
用户拿到结果文件后,可以继续下载、复核,或进入下一段业务动作。
Template Result
像月度报表、模板报表、集团汇总表这类场景,平台最终交给客户下载的,不应是中间 CSV 或中间结果表,而应是按交付要求生成后的成品文件。
先复制标准模板文件,再按批次或月份重命名,然后把结果数据写入模板工作表,最后把这份成品文件作为正式产物回传给用户下载。
Chat Binding
当前做法不是让脚本去扫整个上传目录,也不是让它靠文件名碰运气,而是把这次上传形成的批次号显式挂到当前对话执行里。
用户现在可以直接在对话执行底部快捷区点击“上传文件”,按钮紧挨“上传脚本”,旁边的说明图标会提示这批文件会绑定到当前会话。
上传完成后,当前对话会保存这次 uploadBatchId。当用户确认执行某个 Skill 时,后端会把这批文件的快照一并带进这次执行。
脚本运行时会收到当前批次号、输入文件列表和批次目录信息,所以它处理的是当前这次确认执行绑定的文件,而不是别的历史批次。
| 环节 | 当前怎么做 | 作用 |
|---|---|---|
| 上传文件 | 前端生成受控批次 | 保证文件先进入可追踪批次,而不是散落上传。 |
| 触发对话 | 当前会话带上 uploadBatchId | 明确这次执行到底要消费哪一批输入。 |
| 确认执行 | 后端回填 fileService 快照 | 让执行器拿到批次号、目录和输入文件清单。 |
| 脚本运行 | 只读取当前绑定批次 | 避免误读别的批次、别的客户或别的历史文件。 |
| 脚本里直接读什么 | 当前含义 |
|---|---|
EXECFABRIC_UPLOAD_BATCH_NO | 当前绑定批次号,用来判断这次执行到底消费哪一批输入。 |
EXECFABRIC_UPLOAD_INPUT_FILES_JSON | 当前批次输入文件数组,脚本可以直接拿到 fileName、fileId、大小等信息。 |
EXECFABRIC_UPLOAD_FILE_SERVICE_JSON | 完整的文件服务快照,包含 batchNo、inputFiles 等上下文。 |
EXECFABRIC_SKILL_INPUT_PAYLOAD_JSON | 本次执行的完整输入载荷,里面同样会保留 uploadBatchId 和 fileService。 |
当前 Python / Shell 执行器都会把这些变量注入运行环境。如果用户重新上传了一批新文件并再次确认执行,新的批次就会覆盖旧批次。脚本应始终按当前执行上下文里的批次信息读取输入,而不是凭“最新文件”这种不稳定规则处理。
Fit
| 场景 | 为什么适合 | 适合程度 | 说明 |
|---|---|---|---|
| 先上传原始文件,再生成报表 | 输入和输出都是文件 | 当前已适合 | 例如结果表、汇总表、导出文件、处理后产物。 |
| 文件较大,担心一次传输失败 | 需要更稳定的上传方式 | 当前已适合 | 可按大文件分片方式处理,而不是整包重试。 |
| 需要保留一批输入文件的处理状态 | 便于追踪批次和结果 | 当前已适合 | 平台强调批次视角,而不是只显示“上传成功”四个字。 |
| 只需要文本问答,不涉及文件 | 文件链路不是重点 | 不必强行使用 | 这类场景先看智能执行和 AI 推荐路径即可。 |
Current Scope
Safety Rule
Next Read
文件链路只是交付链的一部分。结合客户流程、交付物与文档入口、客户接入准备清单查看,更容易完整评估项目。