面向招投标信息采集的 Agent 工作台，覆盖来源接入、站点识别、规则生成、执行记录、失败修复和原文追溯。
已完成来源接入、Agent 识别、Rule Pack、执行记录和原文库等核心对象设计，采集结果、失败原因和原文来源均可回查。
这是我在北京中数智汇负责的第二个公司业务验证原型，面向标讯采集业务。我负责产品结构、规则与运行模型、交互设计和原型开发，项目仍在开发中。在线演示只使用模拟数据，不含公司、客户或真实标讯信息，也不公开内部代码。
执行记录工作台：统一查看采集状态、产出、失败问题和原文入库结果。
招投标信息来源分散，网站结构差异大且经常变化。人工维护采集规则、核对结果和排查失败都很耗时，运行过程也缺少完整记录。
平台分别管理来源接入、站点识别、Rule Pack、样本审核、采集任务、执行记录和原文库。Agent 参与规则生成和异常修复，人工负责审核，系统保存完整运行记录。
原型已覆盖来源接入、规则管理、任务执行、失败处理和原文查询，正在继续补齐实际运行所需的审核与修复细节。
记录标讯来源、入口 URL、访问限制和站点约束，为页面识别与采集提供统一入口。
统一管理列表页、详情页、增量规则和字段映射；Agent 给出建议，人工审核后启用。
记录每次采集的状态、输出、失败原因和修复动作，结果与问题都能回查。
保存原文、正文、附件和来源地址，方便核对结果与定位问题。
选择：Agent 识别页面结构并生成规则建议，人工审核后再启用；系统保存每次执行的结果、失败原因和修复动作。
理由：页面识别可以交给模型提高效率，但生产规则和采集结果必须有人确认，也必须能回查。
选择：列表页、详情页、字段映射和增量策略统一放进可维护的规则包。
理由：标讯网站会持续变化，规则需要审核、复用、回放和修复，不能只散落在脚本里。
选择：采集结果可以回到来源地址、正文、附件和对应的运行记录。
理由：标讯信息经常需要人工核对；保留原文后，审核和排错不必重新寻找来源。
选择：失败原因、待处理问题、修复动作和重试结果绑定在同一条执行记录上。
理由：采集失败不能只留下一个告警；负责处理的人需要看到上下文，也要知道 Agent 已经做过什么。
下载与当前方向匹配的简历，或通过邮件、电话直接联系。
