建工集团1+3+N智能体平台：三类智能体如何共用知识底座

建工集团推进智能体应用，难点往往不是能否生成一份文档，而是方案、投标和项目管理团队能否在各自权限内，使用可信且一致的知识。规范更新后，历史方案仍能否安全复用？投标承诺能否传递给项目团队？合同和现场资料分散在不同系统时，风险提示由谁确认？如果每个部门各建一套工具，这些问题很容易随着应用增加而放大。

“1+3+N”可以作为一种平台建设框架：以 1 个统一平台承载公共技术与治理能力，以方案、投标、项目管理 3 类智能体服务不同业务任务，以 N 个按主题或权限组织的知识库沉淀资料。它不是固定产品规格，也不意味着所有文档都要集中开放；重点是让知识有共同的管理规则，让不同任务有清晰的使用边界。

为什么需要共用知识底座

建工企业的业务链条长，同一项目的资料会经历投标准备、方案编制、合同签订和现场履约等多个阶段。知识复用通常面临三类障碍：

• 资料分散且格式不一。 规范可能是 PDF，历史方案是文字文档，招标文件包含扫描件和表格，合同则分布在合同系统或项目档案中。
• 同一资料的适用范围不同。 历史方案可以提供经验，但其中引用的标准、施工条件和项目参数未必适用于当前工程；招标文件和合同的访问权限也可能不同。
• 业务动作缺少衔接。 投标阶段识别出的工期承诺、关键技术要求和风险事项，如果没有经过确认并传递给项目团队，后续管理仍需重新梳理。

知识底座的价值，是为资料建立可检索、可追溯、可授权、可更新的共同基础。它不能替代业务判断，也不等于把所有文件放进同一个目录；真正需要统一的是数据接入、元数据、权限、版本和使用规则。

“1+3+N”各自负责什么

这里的“N”不应简单理解为知识库数量越多越好。库的划分应服务于资料生命周期和权限管理：例如，企业级规范库可以供多个业务场景按权限使用，项目合同库则需要限制访问范围。平台可以提供统一检索入口，但检索结果仍须遵循各知识库及原始业务系统的授权规则。

方案智能体：辅助编制，不替代专业审核

方案智能体适合处理资料查找、章节提纲、类似工程经验比对和初稿整理等工作。例如，编制专项施工方案时，它可以根据项目条件检索相关规范条文与经审核的历史案例，并提示引用来源。

其关键边界是：历史方案只能作为参考，不能直接视为当前工程的合规依据。 智能体应展示规范名称、版本和相关条文位置；涉及适用性、计算结果、现场条件及审批要求的内容，仍须由专业人员核实。若资料缺失或版本无法确认，应提示人工补充，而不是自行填补关键参数。

投标智能体：围绕招标要求组织工作

投标智能体可辅助提取招标文件中的资格条件、技术要求、评审要点和时间节点，并与企业授权使用的业绩、资质材料及历史投标资料进行匹配，形成待核对清单。

它与方案智能体可以共用规范库和经授权的历史项目知识，但工作目标不同：前者重点支持技术方案，后者重点识别响应要求和遗漏风险。报价、资格符合性、承诺条款以及最终投标文件，仍应由相应负责人审查；历史中标资料也不能证明当前项目一定符合要求。

项目管理智能体：结合合同与现场状态

项目管理智能体可以围绕进度、合同义务、会议纪要、变更及问题台账提供辅助，例如汇总临近节点、检索相关合同条款、整理待办事项，并向指定责任人发出提醒。

与前两类智能体相比，它更依赖持续更新的业务数据。仅靠静态文档，无法可靠判断某项工作是否已完成。对需要回写项目系统、创建工单或触发正式通知的动作，应设置授权、人工确认和操作留痕，避免把模型生成的判断直接当成业务事实。

异构资料怎样进入知识底座

统一接入不意味着使用同一种解析方式。企业需要根据资料类型处理内容，并保留原文位置和业务上下文。

一条可执行的接入流程可以是：资料登记与授权 → 格式解析 → 内容校验 → 元数据标注 → 分段与建立索引 → 权限配置 → 试检索 → 发布维护。扫描件需要识别文字，复杂表格和图纸可能需要专门处理；解析结果应经过抽样校验，不能假定所有格式都能准确转换。

每份资料至少应能回答几个问题：从哪里来、属于哪个项目或专业、谁负责维护、当前是什么版本、哪些人可以使用。检索回答最好同时返回原文片段及所在章节、页码等定位信息；定位信息能否准确提供，取决于解析质量和源文件格式。

当资料更新、作废或权限变更时，底座还要同步更新索引及访问规则。特别是规范和合同，不能只增加新版本而忽略旧版本状态，否则智能体可能同时检索到相互冲突的内容。

三类智能体如何复用，而不是互相复制

知识复用有两条路径：一是多个智能体按权限读取同一份经过治理的资料；二是前一环节形成的经确认业务成果，转交给下一环节使用。

以一个示意项目为例：

1. 投标智能体从招标文件中整理技术要求、工期节点和待确认问题，投标负责人核对并形成正式响应清单。
2. 方案智能体读取获准使用的响应清单、相关规范和类似工程资料，辅助编制技术方案；专业人员核实项目条件与引用依据。
3. 项目管理智能体在合同签订后，结合合同、经确认的投标承诺和项目计划，生成履约事项清单，交由项目负责人确认责任人与节点。
4. 项目执行中形成的变更、问题和经验，经审核、脱敏及权限配置后，再决定是否纳入可复用知识。

这个过程中的关键，不是让三个智能体自由传递全部对话，而是为交接成果定义状态、责任人和版本。例如，投标阶段的初步识别结果不应自动成为项目履约指令；只有经业务人员确认、并与最终合同核对后的事项，才适合进入正式管理流程。

五项统一管控能力

统一技术栈：减少重复建设

统一技术栈主要指共同使用身份认证、数据连接、知识检索、智能体编排、日志和接口规范等基础能力，不要求所有场景采用完全相同的模型或界面。

这样做有助于减少各部门重复采购、重复接入和后续维护成本。选型时应关注平台能否对接现有项目、合同及文档系统，是否支持替换模型和检索组件，以及新增场景是否需要大规模重复开发。

数据管理：让知识可信且可控

数据管理不仅是上传文件，还包括资料分级、项目隔离、版本维护、质量检查和生命周期管理。应先明确资料归属和维护责任，再决定哪些内容可跨部门复用；对于敏感合同、报价及个人信息，还要结合企业制度确定访问、脱敏和留存规则。

特别需要区分两类权限：用户能否查看原始资料，以及智能体能否在当前任务中使用该资料。检索、生成结果、缓存和导出环节都应纳入权限控制，避免通过摘要间接泄露受限内容。

模型管理：按任务选择并持续评测

模型管理应覆盖模型选择、调用权限、版本记录、使用成本和效果评测。简单的资料分类、条款提取和复杂的方案推理，对模型能力与成本的要求可能不同，不必所有任务都使用同一配置。

评测应采用企业授权的代表性任务，分别检查检索是否找到正确资料、引用是否准确、输出是否遗漏关键条件，以及在资料不足时能否明确提示。模型、提示词、知识库或检索策略发生重要变化后，也应重新抽样验证。

推送管理：只把有效信息交给合适的人

项目提醒需要结合事件来源、责任人、时间和业务状态。比如，合同节点提醒应说明依据的合同版本、对应事项和建议处理人，并允许负责人确认、退回或调整。

推送不宜只追求数量。对重复提醒、已关闭事项和误报，应设置合并、关闭与反馈机制；涉及正式通知或对外沟通时，应遵循既有审批流程。

闭环管理：让结果可追踪、可纠正

闭环至少包括任务发起、资料检索、结果生成、人工审核、执行反馈和记录归档。平台应记录使用了哪些资料版本、生成结果由谁确认、后续是否执行，以及错误如何修正。

用户反馈也不应直接无审核地写回知识库。正确做法是将问题分流：资料过期由知识责任人更新，检索错误由技术团队调整，业务规则不清则由业务负责人确认；通过审核后再发布新的知识或规则。

实施时先建什么

第一步：选一个可验证的高频任务

不必一开始覆盖全部工程业务。可以选择资料相对集中、业务负责人明确、结果容易核对的任务，例如招标要求提取，或特定专业方案的规范检索。

试点前应确定基线：当前一次任务需要多少人工时间、常见遗漏是什么、由谁审核，以及哪些结果绝不能自动执行。没有基线，后续很难判断平台投入是否带来实际改善。

第二步：先治理最小知识范围

围绕试点任务整理一批有明确来源和授权的资料，建立版本、项目、专业、保密级别和责任人等必要字段。先验证解析质量、检索准确性和权限隔离，再逐步扩大资料范围，比一次性导入大量未经整理的文件更容易发现问题。

第三步：打通一个业务闭环

试点不应停留在“问答效果不错”。应让结果进入实际工作流程：例如，招标要求清单由投标负责人审核，修改意见被记录，确认后的条目再按规则交给方案团队。暂时无法对接业务系统时，也可以先采用人工确认和受控导出的方式验证流程。

第四步：复用能力，逐场景扩展

当资料维护、权限控制和审核流程稳定后，再接入其他智能体或更多项目。扩展时优先复用已有身份、检索、日志和评测能力，同时保留各业务场景独立的提示规则、审批责任与权限范围。

哪些条件不成熟时不宜扩围

以下情况出现时，应先补齐管理基础，而不是直接增加知识库或智能体数量：

• 没有资料责任人。 文件谁上传、谁审核、谁更新都不明确，底座很快会混入过期或错误内容。
• 项目与人员权限不清。 无法区分可共享资料和受限资料时，跨部门检索可能带来信息泄露风险。
• 关键资料版本混乱。 招标澄清、合同补充协议或规范版本无法可靠识别时，生成结果难以作为业务依据。
• 业务流程没有审核出口。 对方案、投标承诺或系统回写等高风险结果，若无人负责确认，不宜开放自动执行。
• 缺少可验证的数据和指标。 如果无法核对正确性、引用来源和人工修改量，仅凭使用次数难以判断实际价值。
• 系统接口与运维条件不足。 无法稳定获取项目状态、处理权限变更或追踪操作日志时，应限制实时提醒和跨系统动作的范围。

对于数据敏感、网络隔离或有特定部署要求的企业，还需要在选型阶段核查模型部署方式、数据流向、日志保存、备份恢复及供应商运维权限。具体采用本地、专有环境还是其他部署方式，应由业务、信息安全和技术团队共同评估。

如何衡量落地成效

平台成效应同时看效率、质量、风险和维护投入，避免只统计生成文档数量。

对建工集团而言，“1+3+N”的建设重点不是先凑齐三个智能体和若干知识库，而是先建立一套可信的知识与责任机制：资料有来源、使用有权限、结果有依据、动作有人确认。只有这些基础能够在一个真实场景中稳定运行，平台化复用才有机会降低重复建设成本，并逐步支撑从投标到履约的业务协同。