上周，我用一条约 2000 字的 Prompt，让大模型调研“固态电池量产进度”。模型写到第三页开始补造信息，对比 A 公司和 B 公司时，还把不同维度的参数放到了一起。
我又补上“请严格基于事实”“不要幻觉”等要求，结果没有明显改善。
问题出在任务被塞进了一次对话。检索、核验、比较和写作同时发生，任何一步偏离，错误都会一路带到最终报告。复杂调研需要的不是更长的指令，而是一套能退回、能重试、能留下证据的流程。
长 Prompt 卡住的是流程控制
新浪看点在 2026 年 7 月 21 日发布的文章中，将当年的变化概括为从“模型能力竞赛”走向“系统级智能落地”。另一份 2026 年 7 月的 Agent 工具调研覆盖了 35 款产品，涉及编码、通用自主、办公职场、企业平台和特定领域五类场景。
工具名单会继续变化，值得关注的是任务组织方式。简单问答常见的流程只有一条线：
输入 → 检索 → 生成 → 输出
调研任务走不通这条直线。资料可能不够，也可能互相矛盾；字段没有对齐时，报告写得越流畅，错误反而越难发现。
在 Dify 的工作流或 LangGraph 的图式编排中，可以先设置三个状态：
Searching：检索资料并保存来源；Evaluating：检查覆盖范围、证据和字段完整度；Synthesizing：根据通过审计的材料生成报告。
状态之间由条件控制。证据不足就回到 Searching，发现冲突则补充检索，满足门槛后才进入 Synthesizing。如果业务方把信息覆盖率门槛设为 80%，评估节点只有达到这个自定义阈值才放行。这里的 80% 是流程参数，并非通用行业标准。
这套逻辑与 《LangGraph 多 Agent 客服：先把状态和路由管住》 相同：模型负责处理当前节点，编排层负责决定下一步往哪里走。
Kollab 的 2026 年团队工具对比还提到，项目历史、品牌语调和工作偏好不应在每次调用时重新解释。放到调研流里，对应的做法就是把问题拆解、来源列表和审计结果写入状态，别反复塞回 Prompt。
先把事实放进四个盒子
查询改写：先拆问题，再开始搜
用户输入“调研 2026 年固态电池量产进度”后，查询改写节点先将任务拆成 5 个子问题，例如电解质材料进展、关键厂商量产时间表、能量密度实测数据等。
拆解结果可以并行发送给 Perplexity、Google Search API 和企业内部知识库。每条返回内容都应保留来源链接、发布时间和对应的查询词，方便后续审计。
内部知识库仍然要处理切块和重排序。如果进入上下文的材料本身不完整，后面的 Agent 再多也补不回来。相关配置可以参考 《RAG 调优别急着换模型：先检查这 7 处配置》。
审计节点：只找没有证据的句子
审计 Agent 不负责润色，它只做一件事：把初步结论与检索片段逐条对照。
结论里出现了原始材料没有的数字或时间点，就标记为“证据不足”；多个来源互相矛盾，则保留冲突并退回检索节点。退回时还要附上原因，例如“缺少量产口径”或“样品数据与量产数据混用”。
把审计拆成独立节点后，每次返工都有记录。相比让生成模型在同一段对话里自查，这种方式更容易定位问题。
对比矩阵：字段对齐后再动笔
调研报告最容易出错的地方，是用 A 公司的“量产时间”去对比 B 公司的“能量密度”。解决办法是先让模型输出受 Schema 约束的 JSON，而不是直接写成段落。
{
"company": "",
"product": "",
"electrolyte_route": null,
"mass_production_time": {
"value": null,
"source": ""
},
"energy_density": {
"value": null,
"source": ""
},
"evidence_status": "待核实"
}
公司和产品作为行，材料路线、量产时间、参数和风险作为列。找不到的信息保留为 null 或“待核实”，不要根据上下文补齐。这样才能保证不同公司的同类字段处在同一位置。
合成节点：最后才写报告
经过检索、审计和字段对齐，最终节点拿到的已经是一组带来源的结构化材料。这时 Prompt 只需要规定读者、语气、篇幅和引用格式。
处于“待核实”状态的字段不应写成确定事实；存在来源冲突的内容，则明确列出不同口径。报告的可读性由合成节点处理，事实边界由前面的状态和 Schema 管住。
省下 Prompt，不等于省下调用成本
状态机允许流程回退，也会增加模型调用次数。尤其是“检索—评估—重新检索”这条循环，Token 消耗和等待时间都可能上升。
可以按节点难度做模型路由。查询改写、字段提取和格式转换，可交给 Qwen2.5-7B 或 Llama-3-8B 量化版；审计和综合汇总，再使用 Claude 3.5、GPT-5 等能力更强的模型。具体组合仍要结合 API 单价、上下文长度和实际可用性测试，不能预先承诺固定的节省比例或延迟结果。
流程上线后，至少要记录节点调用次数、Token 用量、退回原因和来源数量。还要设置停止条件：资料长期冲突或反复检索仍无结果时，转给人工处理，避免 Agent 在循环里持续消耗资源。
真正要维护的是状态、证据和退出条件
一条可用的自动化调研流，可以压缩成四步：
状态定义 → 转换条件 → 结构化中间产物 → 最终合成
Prompt 仍然重要，只负责当前节点的局部任务。任务边界、重试路线、证据门槛和输出 Schema，应由编排层接管。
把 Agent 当作需要 SOP 的执行者，会自然逼出几个关键问题：为什么退回、引用了哪条证据、字段为什么为空、流程何时停止。只有这些问题能被追踪，自动化调研的结果才值得交给下一位同事继续使用。
