招投标响应

一份招标文件动辄几百页，资格要求在第二章、技术需求在第四章、评分办法在附件、格式规范散在通知里。漏掉一条实质性条款就可能废标——前面投入的所有工作一起归零。

第二个痛点是素材。历史标书、项目案例、资质证书、人员证明存在不同人的电脑和不同年份的文件夹里。每次投标都要在群里问一遍"某某项目的验收报告谁手上有"。

历史标书正文、技术方案、案例描述这类长文本进通用知识库；资质证书清单、人员证书、业绩台账这类表格数据进结构化知识库。

区分的理由很实际：找"2023 年之后的同类项目业绩"是一次字段查询——按年份、按行业、按金额筛选，答案应该是确定的。把这类数据塞进通用知识库做语义检索，会返回"相近"的业绩，而投标场景里"相近"等于错。

解析招标文件时，用 LLM 节点、输出格式选 JSON，把每条要求落成固定字段：出处章节、要求原文、类型（资格／技术／商务／格式）、是否实质性条款。

为什么一定要结构化：因为这份清单后面要被机器回扫。如果它是一段自由文本，回扫就只能靠模型"再读一遍"，而模型读第二遍未必和第一遍结论一致。结构化之后，回扫是确定的匹配操作。

这一步用自主型智能体在沙箱里执行：按响应点清单逐章检索素材、组织内容、生成初稿文件。它能读写文件、能跑代码，处理几百页招标文件加多份素材是任务量级的工作，不适合一问一答。

在任务页可以看到它规划了哪几章、每章调用了什么素材。中途发现某一章的方向不对，直接追加指令即可。

初稿完成后，用代码执行节点把响应点清单与标书正文逐条匹配，输出未覆盖项与偏离项。

这是确定性检查，不依赖模型"觉得"写全了。漏项应该在这一步暴露，而不是在开标现场由评委指出来。

标书正文、响应点对照表、偏离说明与素材引用清单一并写入云盘。下次投同类项目，这批产物就是新一轮的素材来源——标书库是自己长出来的，不需要专门立项去建。