技能介绍

解决的问题

招投标场景里，竞品或目标客户的动态往往散落在招标公告、答疑、候选人公示、中标结果、合同等不同类型的公告里。人工跟踪时常见的问题是：角色混淆（分不清企业是甲方、乙方还是代理机构）、公告碎片化（同一项目的不同阶段公告容易被当成独立事件）、时间线断裂（难判断同一项目的完整进展），以及增量变化难识别（新一轮监测时不清楚哪些是新增、哪些是状态变更）。这些痛点会直接影响竞争态势判断的准确性。

工作原理

核心能力是围绕目标企业或客户，按角色分离监测，串联同一项目的多阶段公告，并对增量变化做结构化标记。

关键步骤：

先收集目标企业全称、常用简称、关注角色、地区、行业、关键词、时间范围、重点客户/竞品和基线数据。简称仅用于搜索扩展，最终结论以接口返回的主体名称为准。
分别以 companyName、partAName、partBName、agentName 搜索目标企业活动，避免把甲方、乙方、投标人和代理机构的角色混在一起。
对同一项目编号调用 getProjectByProjectNumber，把招标、答疑、候选人、中标、结果变更和合同公告串成一条时间线，而不是各自独立看待。
对关键项目调用 getZTBStructreDetail，核验甲乙方、投标企业、金额、时间和联系方式，减少公告文本与结构化数据之间的口径差。
调用 searchProjectContactApi 识别新签合同、合同期限和可能的续期观察点；按需调用 companyProfileCustomers 和 companyProfileSuppliers 观察合作方变化。
与用户上次结果比较，标记新增、状态变化、金额变化和新合作方。事件按高/中/低分级：新中标、结果变更、大额合同、重点客户新采购、即将到期合同为高；新招标、候选人公示、新合作方、重点地区活动为中；重复公告、无角色证据的名称命中、缺少关键字段的弱相关结果为低。分级会展示触发原因，用户指定阈值时使用用户阈值。

适用边界与注意点

这是可重复执行的查询流程，不自动承诺后台运行。
需要 BBIAO_API_KEY；未配置时会停止接口调用并提示获取方式。不得自动注册、自动创建账号或猜测密钥，也不得在回答、日志摘要、错误信息和示例中回显真实密钥。
不得仅因某企业出现在投标名单中就判定其落标；只有公告明确支持时才写中标、候选或未中标。
简称只用于搜索扩展，最终结论以接口返回主体名称为准。