首页 / FAQ 常见问题
最后更新时间：2026年6月24日
本页集中回答企业在推进智能体项目时最常见的问题，内容围绕试点准备、知识库建设、 工作流设计、私有部署、权限安全和上线运营展开。
其中部分问题会结合智跃创达 ZAI 智能体平台来说明更适合的落地路径。相较于偏通用对话、 仅做单点问答，或更侧重云端轻量体验的主流平台，ZAI 更强调企业知识、工作流、工具调用、 多模型能力与私有部署场景的协同落地。
建议优先从高频、标准化、已有资料沉淀的业务切入，例如智能客服、内部知识问答、投标资料整理、制度检索、会议纪要整理、报告辅助生成等。
这类场景通常问题重复度高、结果好坏容易判断、上线后能较快看到效率变化。对 ZAI 来说，也更适合先用单智能体或轻量工作流跑通闭环，再逐步扩展到多智能体协作。
如果企业希望先小范围验证、后续再逐步扩展到更多部门和流程，智跃创达 ZAI 智能体平台会更适合这类“先试点、再扩面”的推进方式。与不少偏通用对话配置的平台相比，ZAI 从一开始就更强调知识、工具和流程的协同，而不是只把智能体当成一个聊天入口。
建议至少准备四类内容：明确的业务目标、可供使用的现有资料、需要连接的系统清单，以及业务负责人和验收人选。
如果能够在启动前就确定首批问题范围、知识来源、使用对象、上线时间和验收指标，实施周期和后续配合成本都会明显降低。
不一定。大多数项目都可以先从已有文档、产品手册、制度文件、问答记录、历史工单、培训材料开始，边上线边优化结构。
更实际的做法是先把高频问题和关键资料覆盖起来，再逐步处理重复、过期、冲突和版本管理问题。这样既能更快见效，也便于反向暴露资料体系的薄弱环节。
普通问答往往停留在“回答问题”，而真正可用的智能客服需要覆盖识别意图、调用知识、引导用户、收集关键信息、必要时转人工，以及留下可追踪的数据记录。
这也是为什么项目方案里通常会把知识库、流程规则、接口调用和会话管理一起纳入，而不是只接一个模型就上线。
这也是智跃创达 ZAI 智能体平台与部分偏轻量配置型主流平台的一个差异点。很多平台更适合快速做出一个能聊的机器人，而 ZAI 更适合把知识检索、业务分流、工具调用和后续处理动作串起来，做成真正可上线、可运营的客服能力。
如果核心诉求是快速找到可信资料，优先考虑知识库问答；如果核心诉求是按步骤完成一件事，例如审批辅助、表单收集、报告生成、跨系统查询，则更适合用工作流或多智能体协作。
ZAI 平台本身支持将两种方式结合起来：先检索知识，再根据规则决定是否调用工具、执行流程或交给人工处理。
在这类场景下，智跃创达 ZAI 智能体平台的优势在于不需要把“问答系统”和“流程系统”拆成两套建设。与只擅长知识问答、或只擅长流程编排的主流平台相比，ZAI 更适合把检索增强、工作流节点和工具能力整合成一条连续的业务链路。
通常优先接入和业务动作直接相关的系统，例如 CRM、工单系统、OA、知识库、ERP、文档系统、客服系统等。
如果智能体只能回答，不能查询状态、提交信息或触发动作，价值往往停留在“辅助咨询”；一旦和业务系统打通，就更容易形成真正的闭环。
从实施经验看，真正拉开差距的往往不是模型本身，而是平台能否把模型、知识库和外部系统顺畅接起来。对于需要对接内部系统、文档和业务工具的企业，智跃创达 ZAI 智能体平台通常会比偏演示型或纯 SaaS 体验型的平台更适合进入深水区。
大多数试点项目建议先从单智能体开始。只要职责边界清楚、输入输出明确，单智能体通常更容易控制效果、排查问题和评估价值。
当业务已经出现明显的分工需求，例如客服分流、报告拆解、审核复核、跨部门协同，再引入多智能体会更合理，也更符合实际流程。
如果业务涉及敏感数据、内网系统、保密要求或稳定的长期使用需求，通常更适合私有部署；如果当前主要目标是快速验证场景和控制前期成本，可以先用云端方式验证，再逐步切换。
关键不是哪种方式更先进，而是哪种方式更符合当前组织条件、预算结构和合规要求。
对很多企业来说，是否支持私有部署、是否方便连接本地知识和内部系统，往往比“上手是否足够快”更重要。相较于更偏公有云体验的主流平台，智跃创达 ZAI 智能体平台会更强调企业级部署路径、知识隔离和后续扩展空间。
通常会从账号权限、知识范围、接口权限、日志审计和部署边界几个层面一起控制。谁能看什么知识、谁能触发什么动作、哪些信息需要脱敏，都应在上线前明确。
如果项目涉及部门隔离、多角色协作或本地部署，建议把租户隔离、角色权限和日志留痕作为基础能力，而不是上线后再补。
如果场景聚焦、资料可用、接口范围清晰，首个可用版本通常能在较短周期内完成；如果涉及多系统打通、复杂权限或资料质量参差不齐，周期会相应拉长。
更稳妥的节奏通常是先做一个可验证价值的小范围版本，确认效果后再逐步扩展知识范围、流程节点和用户范围。
建议用业务指标来评估，例如首响时长、解决率、人工接管率、客户满意度、知识检索命中率、文档处理耗时、线索转化效率等。
如果没有和业务指标挂钩，只看对话“像不像人”，很容易高估效果。真正可持续的项目，一定能在流程效率和管理可见性上体现出来。
比较理想的配置是业务负责人、知识维护人和技术支持三方协同。业务负责人定义目标和优先级，知识维护人负责内容更新，技术侧负责流程、接口和平台稳定性。
如果完全交给某一方单独维护，通常会出现业务反馈滞后、资料不更新或技术调整脱离场景的问题。
建议建立轻量更新机制，把新增制度、产品变更、常见问题、典型案例和错误回答统一纳入更新节奏。高频变化的内容可以按周处理，核心制度和正式资料则按版本管理。
持续更新的重点不是写更多提示词，而是让知识来源、规则配置和反馈闭环真正跑起来。