文档导航
企业服务

企业工作流

将模型、知识、工具、审批和业务系统连成工作流。

本页目录
  1. 先理解完整链路
  2. 第一步:只选一个试点流程
  3. 第二步:画清当前人工流程
  4. 第三步:确定模型输入边界
  5. 第四步:创建服务专用 Key
  6. 第五步:先实现只读版本
  7. 第六步:把业务动作封装成工具
  8. 第七步:增加人工审批
  9. 第八步:做离线验收
  10. 第九步:小范围上线
  11. 典型场景
  12. 上线后持续监控
  13. 最小交付清单

企业工作流不是简单地给员工一个聊天窗口,而是把模型、企业知识、工具权限、审批和业务系统连成可追踪的执行链路。ZCloudAPI 负责统一模型入口、用量和路由,企业应用负责身份、知识、工具和审批。

ZCloudAPI 企业工作流

先理解完整链路

Employee Employee BusinessApp BusinessApp Identity Identity Knowledge Knowledge ZCloudAPI ZCloudAPI Model Model Approval Approval Tools Tools 提交业务任务 校验用户和部门权限 检索允许访问的资料 发送模型请求和上下文 路由到目标模型 返回分析或工具计划 高风险动作等待人工确认 审批通过 调用 CRM / 工单 / 代码仓库 返回结果并写入审计记录

不要让模型直接拥有所有数据库和业务系统权限。工具调用应由企业应用验证参数、身份和审批状态后执行。

第一步:只选一个试点流程

第一次落地不要同时接入所有部门。选择一个满足以下条件的流程:

  • 每周重复发生,人工耗时可以统计。
  • 输入和输出相对标准化。
  • 出错后容易发现和回退。
  • 能先从只读或人工确认开始。
  • 有明确的业务负责人。

推荐试点:客服工单总结、内部知识问答、代码仓库只读分析、销售会议纪要整理。

把目标写成可验收的句子,例如:

在不自动发送客户消息的前提下,把单张客服工单的资料检索和回复草稿时间从 15 分钟降到 5 分钟。

第二步:画清当前人工流程

  1. 记录任务从哪里进入,例如工单系统、表单或群消息。
  2. 记录员工需要查哪些系统和文档。
  3. 标出每一步输入、输出和负责人。
  4. 标出涉及客户数据、个人信息、合同或财务数据的步骤。
  5. 标出哪些动作可以撤销,哪些动作不可逆。
  6. 记录当前平均耗时、成功率和返工率。

没有当前流程和基线指标,就无法判断 AI 上线后是否真正改善业务。

第三步:确定模型输入边界

为每类数据明确处理规则:

数据类型 是否进入模型 推荐处理方式
公开产品资料 可以 版本化并记录来源
内部 SOP 按权限 检索时继承部门和文档权限
客户联系方式 尽量不直接传 先脱敏,只保留完成任务需要的字段
密码、私钥、API Key 不可以 在进入提示词前拦截
合同和财务数据 审批后 限定模型、用途、保存期限和访问人员

同时确定请求和响应需要保存多久、谁能查询、什么时候删除或归档。

第四步:创建服务专用 Key

  1. 在 ZCloudAPI 创建一条只给该工作流使用的 Key。
  2. 名称使用 部门-流程-环境,例如 support-ticket-prod。
  3. 只开放经过测试的模型。
  4. 设置独立额度和告警阈值。
  5. 把 Key 放入服务器 Secret,不下发到员工浏览器。
  6. 开发、测试和生产分别创建 Key。
  7. 用 /v1/models 和最小请求验证生产 Key。

这样可以单独查看该流程的用量,也能在异常时只停用这一条链路。

第五步:先实现只读版本

第一版建议只做:

用户提问
-> 企业应用校验身份
-> 按权限检索知识
-> 调用 ZCloudAPI
-> 返回答案和引用来源
-> 人工决定下一步

实现步骤:

  1. 企业应用接收登录用户和任务。
  2. 根据用户身份过滤可访问知识。
  3. 只把相关片段放入模型上下文,不发送整个数据库。
  4. 提示模型输出答案、引用和不确定项。
  5. 把模型、耗时、用量、资料来源和用户记录到业务审计日志。
  6. 收集员工的接受、修改和拒绝反馈。

只读版本稳定前,不要让模型自动写入 CRM、发邮件或执行代码发布。

第六步:把业务动作封装成工具

需要执行动作时,每个工具只做一件事,并明确参数。例如:

{
  "tool": "create_support_draft",
  "arguments": {
    "ticket_id": "T-20260805-001",
    "language": "zh-CN",
    "tone": "professional"
  }
}

企业应用收到工具调用后必须:

  1. 校验调用用户是否有权限。
  2. 校验参数类型、长度和允许值。
  3. 重新读取关键业务状态,避免使用过期上下文。
  4. 判断是否需要人工审批。
  5. 使用真实用户或受限服务账号执行。
  6. 保存执行前后状态和结果。
  7. 把必要结果返回模型,继续后续步骤。

模型只提出工具调用建议,真正权限判断必须在企业应用侧完成。

第七步:增加人工审批

建议按风险分三档:

风险等级 示例 执行方式
低 搜索资料、生成摘要 可以自动执行
中 生成客户回复、创建工单草稿 人工确认后提交
高 付款、删除数据、发布代码 指定审批人,多重校验并保留回滚

审批页面至少显示:

  • 原始任务和发起人。
  • 模型准备执行的动作。
  • 关键参数和影响对象。
  • 使用了哪些资料。
  • 预计风险和回滚方式。
  • 同意、拒绝和修改入口。

第八步:做离线验收

  1. 从历史任务中选取一批有代表性的样本。
  2. 隐去不需要的敏感字段。
  3. 让 AI 流程跑完整批次,但不执行真实写操作。
  4. 由业务人员对正确性、完整性和风险评分。
  5. 记录失败类型,并修改提示词、检索或工具校验。
  6. 设定上线门槛,例如正确率、人工介入率和单任务成本。

不要只挑成功案例展示。边界情况和失败案例决定系统能否上线。

第九步:小范围上线

  1. 先开放给一个团队或少量内部用户。
  2. 给每个用户和流程设置额度与并发上限。
  3. 高风险动作全部保留人工审批。
  4. 每天检查错误率、成本和用户反馈。
  5. 准备关闭开关,可以立即停用模型调用或具体工具。
  6. 达到验收指标后再逐步扩大范围。

典型场景

场景 AI 负责什么 人负责什么 第一版建议
客服工单 总结问题、查 SOP、生成回复草稿 审核并发送 只生成草稿
销售线索 查 CRM、总结沟通、生成跟进建议 决定是否触达 不自动联系客户
代码维护 阅读仓库、生成修改、运行测试 Review、审批和合并 从只读分析开始
数据分析 生成 SQL、解释指标变化 确认口径和决策 使用只读数据库账号
合同审阅 抽取条款、标出差异和风险 法务判断和签署 不自动给出结论

上线后持续监控

指标 说明
任务成功率 无需返工即可完成的任务比例
人工介入率 需要审批、修改或人工接管的比例
平均处理时长 从任务进入到最终完成的时间
单任务模型成本 输入、输出和重试产生的总费用
工具调用失败率 参数校验、权限、业务系统错误的比例
可追溯率 是否能还原用户、输入、资料、模型、审批和工具结果

最小交付清单

企业试点至少应交付:

  • 一张当前流程和目标流程图。
  • 数据分类与模型输入边界。
  • 服务专用 Key、模型列表、额度和轮换方案。
  • 工具接口、权限校验和参数校验规则。
  • 人工审批页面和回滚方案。
  • 离线测试集、验收指标和失败案例。
  • 运行日志、用量看板和异常告警。
  • 试点范围、负责人和紧急停用流程。

需要设计具体企业接入方案时,请联系 support@zcloudapi.com,说明行业、试点流程、预计用户数、数据来源和需要连接的业务系统。