技术专题  /  企业级 AI 基础设施

从一次回答到可恢复任务，解释企业 Agent 的状态、工具、审批和执行边界

核心检索词：工作流智能体、企业 Agent、智能客服、AI 工作流、Agent 工具调用、RAG、人工审批、私有化部署

把大模型接到一个聊天窗口里，用户可以问问题、让它写总结、生成邮件，这已经能带来不错的体验。但企业一旦提出“请查完数据、生成方案、提交审批、写回系统并通知相关人”，普通聊天机器人就会显得不够用了。两者的差别不在于谁更会说话，而在于系统是否把一次对话当成一个可管理、可暂停、可恢复、可审计的业务任务。

聊天机器人交付一句话，工作流智能体交付一个状态

聊天机器人通常以请求和响应为边界，收到消息后生成文本，生成完成后任务就结束。工作流智能体则需要记住任务已经走到哪一步：已经识别了用户意图，已经读取了客户资料，正在等待审批，某个工具调用失败，或者动作已经写回系统。状态不是对话历史的简单累积，而是可被系统读取和推进的任务对象。

没有明确状态，Agent 很容易在多轮对话里重复执行。用户说“继续”，系统不知道是继续生成、继续查询，还是继续提交；接口超时后，模型也不知道写入是否已经成功。生产系统需要为任务分配 ID，记录步骤、输入、输出、审批、错误和重试次数，并让每个步骤具有清晰的完成条件。

产品判断：  聊天机器人关注“说得像不像”，工作流智能体关注“事情是否按边界完成、失败后能否恢复”。

工具调用，是从回答走向执行的分水岭

聊天机器人可以根据知识库回答“如何申请退款”；工作流智能体要先识别订单、校验身份、读取退款规则、判断订单状态、生成申请、等待审批，再把结果写回工单系统。这里的每一步都需要结构化工具、权限和错误语义，不能让模型自由生成一段 SQL 或直接拼接一个接口请求。

图 1｜聊天机器人主要交付文本，工作流智能体需要管理任务状态、工具、权限、审批和结果。

工具必须声明输入类型、必填条件、风险等级、超时、幂等规则和是否有副作用。服务端要重新校验所有参数，不能因为模型输出了正确的 JSON 就放弃安全检查。对涉及金额、客户资料和系统写入的工具，通常还需要动作预览、人工确认或审批节点。

工作流不是把步骤写长，而是把不确定性放在正确的位置

如果流程完全由固定规则组成，普通工作流引擎就足够；如果用户表达复杂、资料分散、下一步需要判断，Agent 可以负责理解意图、选择路径和生成草稿。但确定性节点仍然应该由规则和系统控制，例如金额上限、审批人、权限范围、库存状态和接口幂等。智能体的自由度越大，越需要把边界放在外围。

较好的架构是“模型做计划，工作流做约束，工具做执行，系统做事实”。模型可以提出计划，但每一步要经过状态机或编排器确认；工具返回事实和状态，而不是让模型猜测；工作流记录已完成和待完成的步骤。这样，企业既获得了自然语言交互，也保留了业务系统的确定性。

等待、重试和回滚，决定 Agent 是否能上线

真实业务里，审批不会立即完成，CRM 可能超时，ERP 可能短暂不可用，用户可能在中途离开。Agent 需要能够暂停任务，等待外部事件，再从指定节点继续。重试也不是简单重复调用，必须区分读操作和写操作，并使用幂等键避免重复创建订单、工单或付款申请。

有些动作无法真正回滚，只能通过补偿。例如通知已经发出，不能把邮件收回；库存已经锁定，失败后需要释放；CRM 写入失败，可能要人工补录。工作流智能体要把这些补偿路径显式设计出来，并在用户界面告诉用户当前结果，而不是生成一句“已完成”结束对话。

图 2｜生产级 Agent 要能在多步执行、等待、失败、重试和回滚之间保持状态。

评估 Agent，不能只测最终回答

企业需要测试的不只是文本质量，还包括任务是否拆对、工具是否选对、参数是否正确、权限是否越界、审批是否触发、失败是否恢复以及结果是否写回。评测样本应覆盖正常任务、缺字段、歧义、工具超时、重复执行、权限不足和人工接管。对于高风险动作，宁可多一次确认，也不能只追求自动完成率。

北京宜天信达的企业 Agent 方案适合把知识库、工作流、工具、身份和审计组合成一条可验收的执行链。企业不必一开始就做一个无所不能的超级 Agent，而可以从查询、草稿和任务分派开始，逐步验证状态、权限和恢复能力，再扩大到审批和系统写入。

记忆也需要分层。聊天记忆适合保存用户表达和上下文，任务状态保存步骤和结果，企业知识库保存可共享事实，业务系统保存最终事实。把所有内容都塞进对话历史，既会增加成本，也会让 Agent 把临时说法误当成真实状态。不同类型的数据应该由不同组件负责。

私有化部署时，工作流智能体还要考虑异步任务、消息队列、状态数据库、审计存储和监控，而不仅是模型推理。一个只部署模型的方案无法解释任务为什么停住，也不能保证节点重启后状态不丢。企业应把 Agent 当作业务应用平台，而不是一个更复杂的聊天插件。

工作流智能体的推广路径可以从低风险开始：先做信息查询，再做分析和草稿，随后做任务分派和审批准备，最后再进入自动写入。每一步都要积累评测样本和异常处理经验，等状态、权限和恢复能力稳定后再扩大授权范围。

企业 Agent 的“智能”，要落在可控任务里

一个优秀的聊天机器人可以给出很漂亮的分析，但企业真正愿意付费的通常是任务结果：减少人工录入、缩短审批准备时间、自动整理工单、协助销售跟进或在客服高峰完成分流。任务要有开始条件、完成条件和责任人，Agent 的智能才有业务落点。否则系统再会聊天，也很难证明投入产出。

在私有化部署中，工作流状态和审计数据同样属于重要资产。企业需要知道某个任务使用了哪个模型、引用了哪些资料、调用了哪些工具、谁批准了写入，以及最终系统发生了什么变化。模型输出可以是概率性的，业务记录和审批证据却必须保持确定性。

验收时，可以让业务人员用真实任务从头走到尾，故意制造缺字段、权限不足、接口超时和中途退出，观察 Agent 是否追问、暂停、转人工或恢复。这样的测试比让它回答十个标准问题，更能判断它是不是工作流智能体，而不只是一个高级聊天机器人。

工作流智能体还要有明确的人工接管接口。人工接管不是把任务丢进一个普通工单，而是把计划、已完成步骤、证据、待确认参数和失败原因一起交给人。人工处理后，系统要能继续原任务或安全关闭，避免人和 Agent 各自维护一份状态。

多智能体协作也不能只靠互相发送自然语言。不同 Agent 之间应通过结构化任务和事件传递状态，明确谁拥有任务、谁可以调用工具、谁负责最终结果。否则一个 Agent 以为动作已经完成，另一个 Agent 又重复执行，最终会形成难以审计的隐性链路。

企业 Agent 私有化部署时，模型、向量库、状态库、编排器、工具网关和日志系统应该共同设计。只有把这些组件放在同一套权限和运维框架下，工作流智能体才不会成为一个无法解释、无法升级、无法恢复的黑盒。

工作流智能体的核心指标也和聊天机器人不同。聊天机器人常看响应速度、满意度和连续对话轮数；工作流 Agent 更应该看任务完成率、一次完成率、人工接管率、重复执行率、工具失败率、平均处理时长和异常恢复时间。指标不同，系统的设计目标才不会被“回答得像不像人”带偏。

在实际项目中，还要提前划定 Agent 的行动边界。查询类工具可以自动调用，写入类工具需要参数校验，发送通知、修改订单、触发付款或变更权限则应设置审批或二次确认。边界不是限制智能，而是把不可逆动作放到更可靠的控制面上。

如果企业希望 Agent 持续扩展能力，最好先建立工具目录和统一协议，再逐个接入 CRM、ERP、OA、工单与数据平台。每个工具都要声明输入、输出、权限、幂等性和失败码。这样新增能力时，系统增加的是可组合工具，而不是一堆只能靠提示词维持的临时技巧。

一个实用的落地方法是先选择低风险、规则清晰、结果可验证的任务做试点，例如工单归类、资料补全和会议行动项跟踪。等状态管理、工具调用和人工接管稳定后，再逐步开放写入业务系统的动作。企业 Agent 的能力应在可控边界内逐步增长。

工作流智能体和聊天机器人的真正区别，是它能否对“事情”负责。它不一定每次都自动完成，但必须知道自己做了什么、还差什么、为什么停下，以及如何安全地把任务交给人。