企业官网建设流程全解析

判断企业数据从哪里接入，先看答案需要多新、数据由谁维护，以及 Agent 会不会修改业务系统。设备的激活状态、维修记录和报修结果应从 API 取得；保修政策、排除条款和操作说明适合进入知识库。一条业务问题同时依赖当前数据与解释依据时，让两条路径在同一任务中汇合。

例如用户问：“这台设备 还在保吗，进水能不能保，顺便帮我报修。”序列号对应的购买日期和维修记录来自售后系统，进水条款来自当前版本的保修政策，最后的报修动作又要回到业务接口。若团队使用 ZGI，同一个 Agent 任务可以先查知识，再调用受控工具读取或写入业务系统，无须把三类信息塞进同一数据入口。

概念示意图：知识库提供规则与条款，API提供当前业务状态并承接提交动作。

选择单位缩小到答案字段

很多接入方案从“整个售后系统走 API，整个文档库走检索”开始，边界仍然太粗。把答案拆到字段级更实用。将用户最终会看到、会用于判断或会触发动作的信息逐项列出，来源很快就能确定。

这张表也能处理一些例外。API 可能返回产品说明，知识库也能保存结构化元数据，因此数据格式无法单独决定入口。选择时更应关注权威来源、更新要求、读写动作和失败后果。

当前业务事实从 API 取得

激活状态、维修次数和配件库存会随着业务操作变化。Agent 调用接口时，应把查询时间、设备编号和返回状态一起留下。用户隔天追问时，系统重新查询，而非复用昨天的答案。

接口只开放任务所需字段和动作。查询保修状态不必同时获得修改客户资料的权限，创建报修单也不必暴露整套售后数据库。工具按用途拆小后，参数校验、权限审计和错误处理都会更直接。

规则与解释从版本化资料中检索

保修政策、操作手册和 FAQ 常以文档形式维护。知识库帮助 Agent 从这些资料中找到相关段落，并把文件名、章节、版本和生效日期带回答案。用户问到“进水是否在保”时，系统应展示适用条款，避免只给一句没有出处的判断。

资料更新后，旧版本需要退出默认检索范围，同时保留必要的历史查询能力。若一台设备购买时适用旧政策，任务还要根据购买日期选择对应版本。知识库承载解释依据，版本规则仍由业务方明确。

两条结果相遇时处理时间与冲突

售后 API 显示设备仍在保修期，政策条款却排除了进水损坏。Agent 输出时应把两个结果分开：当前保修状态来自何时的业务查询，排除条件来自哪一版政策。随后说明仍需检测的环节，不能把“在保”和“本次一定免费维修”混成同一个结论。

来源发生冲突时，回到各自的权威系统。设备状态由售后记录确认，政策解释由生效文件确认。缺少任何一项，Agent 都应暂停提交动作并说明缺口。用户确认报修后，Workflow 才把设备编号、问题描述和确认结果交给报修接口。

接入前做一张数据去向表

选十个真实问题，把答案拆成字段，再补上来源、更新时间、权限和失败处理。动态字段连到 API，规则依据连到知识库，写入动作单独设置确认与回执。完成这张表后，团队会得到清晰的数据路径，也更容易发现旧资料、越权接口和重复提交等隐患。

GitHub：https://github.com/zgiai/zgi

Gitee：https://gitee.com/zgiai/zgi