从零搭建你的DeepResearch工作流：实战供应商尽调模板

搜索工具越来越多，但多数人仍停留在"每次用自然语言问一遍"的阶段。真正让团队受益的，是把重复出现的研究任务沉淀成可复用、可版本化的工作流模板。Valyu 在其30天搜索系列的第13天，完整展示了一个真实案例：如何为"供应商准入调研"构建自定义 DeepResearch 工作流，并通过 TypeScript API 调用它。

为什么需要可复用的研究工作流

采购团队在面对新供应商时，问题结构往往固定：这家公司的真实法律实体是谁？它是否真的生产所需产品？有哪些公开报道的风险值得追查？变化的是供应商名称、国家和产品类别，不变的是调研框架和交付格式。

Valyu 将这种情况定义为工作流的理想场景。自定义工作流属于组织私有，可创建、可编辑、可版本化，与平台预置的只读模板不同。它的核心构成包括：

• Prompt（任务声明）：说明要调研什么
• Variables（变量）：运行时可替换的输入字段
• Research strategy（研究策略）：指导从哪里找、如何验证
• Report format（报告格式）：规定输出结构
• Deliverable（交付物）：如 Markdown 报告或 Word 文档
• Tools（工具）：生成 DOCX/XLSX/PPTX 需启用代码执行
• Version（版本）：标识本次运行使用哪套指令

这个区分很关键：策略是"调研指令"而非强制白名单，若需限制搜索范围，应使用请求级别的搜索配置。同样，Prompt 中的截止日期不会生成底层数据的历史快照。

DeepResearch（深度研究） 在这里指的是一种由大模型驱动、可自主规划检索路径并交叉验证来源的研究模式，区别于单轮问答式搜索。传统搜索返回的是链接列表或简短答案，而 DeepResearch 会围绕一个任务声明展开多轮检索：先定位权威来源，再用监管文件与有日期的报道相互印证，最后把证据整理成带引用的结构化报告。

正因为它执行的是多步骤、长耗时的流程，运行成本和时间都远高于普通查询，所以「把研究框架固化下来」才有价值。如果每次都用自然语言重新描述「要查法律实体、要核实产品匹配、要区分事实与分析」，大模型每次的理解都可能略有偏差，交付格式也不稳定。工作流模板把这些指令一次性确定，让不同人、不同时间运行同一任务时得到一致的方法论，而输入变量只负责替换具体的供应商信息。

实战：构建供应商准入调研模板

演示案例把"供应商尽调简报"做成一个组织工作流。四个输入变量分别是供应商名称、国家、产品和审查日期。Prompt 要求：确定正确的法律实体和产品匹配度，识别公开报道的运营、财务、监管、供应链问题，引用证据，区分事实与分析，并列出采购方需直接向供应商确认的问题。

研究策略要求从官方公司页面、年报和监管披露入手，再用政府和监管机构出版物核实具体问题，最后用有日期的可靠报道追踪近期动态。这里有一条值得记住的原则：搜不到结果并不等于风险不存在，缺失信息必须被保留而非掩盖。

报告格式要求五个部分：供应商身份与产品匹配、运营足迹与供应链依赖、证据表、冲突或缺失信息、以及待供应商回答的问题。证据表之所以实用，是因为下一位同事可以打开来源、核对说法，并决定哪些还需要供应商直接答复。

平台会自动从 {variable} 占位符中检测变量行。必须注意键名要与占位符完全一致——{review_date} 需要名为 review_date 的变量，而不是 date 或 reviewDate。

运行、预览与版本管理

保存工作流只是创建了可复用模板，并不会自动启动调研。在界面中点"Run"后填写输入值，平台会展示"将被预填什么"，包括研究模式、策略、报告格式和交付物；点击"Run"才真正开始异步研究任务。

一个容易被忽视的机制是预览端点：它能在不启动调研、不消耗研究额度的前提下解析模板。对于需要先确认参数、再批量执行的团队，这个设计能有效避免因配置错误造成的浪费。

版本管理的边界同样值得强调。文档指出模板版本不可变，发布新版本需要填写变更日志。但版本锁定的是指令，不是答案——来源记录、可用证据和生成措辞在不同次运行间仍可能变化。演示中，团队在第一次运行后修改报告格式（为每个验证问题指定内部负责团队），于是保存为版本2，而 TypeScript 示例显式锁定了版本1。

预览端点（Preview） 的背后是一种「先编译、后执行」的设计思路。模板中的 {variable} 占位符和各类指令需要被解析成一次真实调研任务的完整参数，预览做的正是这一步解析，并把结果原样返回给调用方确认，但不触发任何抓取、检索或模型调用。

对团队来说，这个机制解决的是成本和可重复性两个问题。研究额度通常按任务计费，一次配置错误（比如变量名写错、报告格式没生效）就可能浪费一次完整运行；批量执行前先用预览核对参数，可以把这类错误挡在计费之前。另外，预览结果也可以作为「本次运行将采用什么策略」的书面记录，便于事后追溯。

用 TypeScript 调用工作流

API 侧需要属于该工作流所属组织的密钥。示例使用 Node 22+ 和 valyu-js@2.10.1，默认只执行预览，加上 --run 参数才启动计费的调研任务。

调用 deepresearch.create() 时使用 workflowId、workflowParams 和可选的 workflowVersion。有一条重要约束：不要在同一请求中再传自由格式的 query、researchStrategy 或 reportFormat，这些指令由工作流本身提供，重复传入会导致字段冲突。

脚本会先打印任务 ID 再等待结果，完成后保存 Markdown 报告和 JSON 响应。若等待超时或失败，应先检查该任务状态，而非立即重新发起。Word 文件在结果中有独立的交付状态。

异步任务模型 是理解这段 API 调用的前提。deepresearch.create() 发出请求后，服务端不会在同一个 HTTP 响应里返回最终报告，而是立即给出一个任务 ID，实际的研究在后台排队执行。脚本先打印任务 ID、再轮询等待结果，正是为了适配这种模式。

这种设计带来两条操作纪律：其一，等待超时不代表任务失败，可能只是研究仍在进行，应当先用任务 ID 查询状态，而不是直接重发——重发会产生一次新的付费任务，且可能得到两份重复报告；其二，不同交付物的完成时间可能不同，Markdown 报告和 DOCX 文件在结果对象里各有独立的交付状态，不能因为拿到文本就假定 Office 文件也已生成。

验证结论与常见坑

作者提供了具体验证说明：平台操作完成了工作流创建、一次带 DOCX 交付物的 Standard 任务和版本2的保存；TypeScript 示例通过了严格编译和七项本地 SDK/HTTP 固件测试，覆盖版本锁定、仅预览执行和失败不重提交等路径，但固件测试未执行额外的付费调研。

实际运行返回了一份带引用的报告和已完成的 DOCX。一个有价值的细节是：简报将"由哪个实体签约和开票"标记为未确认，这给了采购一个明确的下一步动作——直接索取签约实体的法定名称和注册信息，而不是假定母公司就是交易对手。

常见问题集中在几处：占位符未填充、日期或数字被拒、私有工作流找不到（密钥所属组织不符）、新版本因缺少变更日志而无法保存、以及生成 Office 文件未启用代码执行。

落地建议

选一个有人会真正审阅的重复性研究任务，把问题和证据要求写一次，创建变量字段，然后在一个真实例子上跑通。用第一次结果改进模板，并把改动记录到新版本里。这个流程的价值不在于自动化本身，而在于把研究规范固化成团队资产。