AI Workflow Runtime

AI Workflow Runtime vs Chatbot：从对话入口到可控执行系统

当 AI 从回答问题进入执行业务，关键不再是聊天界面，而是一个可审计、可恢复、可治理的 workflow runtime。

作者： davyhung&codex

摘要

过去两年，许多企业 AI 产品都从 chatbot 开始：用户输入一句话，系统返回答案、文档摘要、检索结果或操作建议。这类产品能够快速验证需求，也容易被用户理解。但当 AI 开始处理真实业务流程，例如生成采购单、更新 CRM、发送邮件、审批合同、处理文件、调用内部系统时，单纯的聊天界面很快会遇到结构性瓶颈。

Chatbot 解决的是“如何对话”，AI workflow runtime 解决的是“如何把工作可控地执行完成”。

两者并不是同一层级的替代关系。Chatbot 更像交互层，负责理解自然语言、收集参数、解释结果；workflow runtime 更像执行层，负责状态管理、任务编排、工具调用、人工审批、失败恢复、日志追踪和权限治理。对于知识问答、FAQ、轻量咨询，chatbot 往往足够；对于多步骤、跨系统、有副作用、需要审计的任务，workflow runtime 才是更接近生产级 AI 产品的底座。

本文将系统比较 AI workflow runtime 与 chatbot 的定义、架构、适用场景、工程差异与迁移路径，并说明为什么企业 AI 产品通常会走向一种混合架构：前台是 chat，后台是 runtime。

1. 先澄清：Chatbot 和 Workflow Runtime 不是同一种东西

Chatbot 是以对话为中心的人机交互形态。它通常由聊天界面、会话上下文、提示词模板、模型调用、检索增强生成（RAG）和消息流组成。其核心目标是让用户通过自然语言获得一个可理解的响应。ChatGPT、企业知识库问答、客服机器人、文档问答助手，都属于这一类形态的典型代表。[1][2][3]

AI workflow runtime 则是以任务执行为中心的运行时系统。它关注的不是回复是否自然，而是任务是否按照预期完成：每一步是否有状态记录，失败后能否重试，外部系统调用是否可追踪，高风险动作是否需要审批，执行过程是否可审计。[6][7][8]

两者的根本差异可以概括为：

维度ChatbotAI Workflow Runtime
核心对象消息、会话、回复任务、节点、状态、事件
主要目标回答问题、解释信息、完成对话执行业务流程、恢复失败、留痕审计
状态管理会话上下文为主持久化任务状态与事件历史
工具调用通常作为对话增强能力作为受控执行节点
失败处理重新提问或重新生成重试、补偿、从失败节点恢复
权限边界以内容安全为主内容安全 + 动作安全 + 系统权限
适用场景FAQ、知识问答、轻量咨询审批、写入、跨系统编排、长任务

一个简单判断是：如果用户要的是“答案”，chatbot 是合理入口；如果用户要的是“事情被完成”，runtime 才是核心基础设施。

2. 为什么 Chatbot 不足以承载生产级 AI 执行

Chatbot 的优势很明显：交互自然、实现快、用户学习成本低。它适合处理模糊输入，也适合把复杂系统包装成一个更容易理解的对话入口。

问题在于，企业流程通常不是一次回答就结束。真实业务往往包含以下特征：

  • 多步骤：例如读取文件、抽取字段、校验规则、生成结果、等待审批、写入系统。
  • 跨系统：例如同时访问 ERP、CRM、数据库、对象存储、邮件、工单系统。
  • 有副作用：例如发送、删除、覆盖、支付、提交审批、修改客户资料。
  • 需要恢复：例如第三步失败后，不能从头重跑所有步骤。
  • 需要审计：例如必须知道谁批准了什么、模型看到过哪些上下文、系统执行了哪些动作。

在这些条件下，把所有逻辑塞进 prompt、session memory 和 function calling，短期看似可行，长期会造成三个问题。

第一，状态不可控。聊天上下文不是可靠的任务状态存储。模型可能遗忘、压缩、误读上下文，也难以保证每一步都有可复盘的事件记录。

第二，失败不可恢复。如果第七步调用外部系统失败，系统需要知道前六步是否已经执行、哪些副作用已经发生、是否可以局部重试、是否需要补偿。单纯的对话流很难天然支持这些能力。

第三，权限不可治理。当模型可以调用工具时，真正的风险已经从“说错话”扩展到“做错事”。生产系统不能让模型直接拥有写权限，而应通过工具白名单、参数校验、审批门、服务账号隔离和审计日志间接执行动作。[15][16][28]

因此，chatbot 可以是入口，但不应是所有业务执行逻辑的容器。

3. Workflow Runtime 的核心价值：把 AI 放进可控执行系统

AI workflow runtime 的价值不在于让模型更会聊天，而在于把模型能力放进一个可执行、可追踪、可恢复、可治理的系统中。

一个典型 AI workflow runtime 至少应包含以下能力：

能力说明
任务编排将复杂任务拆成节点、分支、循环、并行任务和等待事件
状态持久化记录每一步输入、输出、状态、错误和事件历史
工具调用通过受控适配器调用 API、数据库、文件系统、SaaS 或本地工具
人工审批对高风险动作加入 human-in-the-loop 审核
失败恢复支持重试、补偿、超时处理、从失败节点继续执行
权限治理以最小权限执行工具调用，隔离模型与系统写权限
可观测性记录 logs、metrics、traces、审计事件和执行成本
版本管理管理流程、节点、提示词、模型和工具版本变化

在这个结构里，模型只是 runtime 中的一个能力组件。确定性逻辑交给代码、规则和状态机；不确定性判断交给模型；危险动作交给审批门；外部调用交给工具层；全流程由 runtime 记录和控制。

这与 Temporal、AWS Step Functions、Azure Durable Functions、Google Cloud Workflows 等工作流系统的设计思路一致：它们都强调状态、编排、持久化、重试、恢复和可观测性，而不是把系统能力集中在一次模型响应里。[6][7][8][9]

4. 架构差异：消息驱动 vs 状态驱动

Chatbot 通常是消息驱动架构。用户发出一条消息，系统拼接上下文，检索资料，调用模型，然后返回答案。

用户Chat UIConversation ServiceSession MemoryRAG / RetrieverPrompt BuilderLLM

这种架构适合短链路交互，但它的主语是“消息”。

Workflow runtime 是状态驱动架构。用户请求只是触发器，核心系统围绕任务状态运行。任务可以暂停、等待审批、重试、恢复、回放、审计。

用户 / 上游系统API / Event GatewayWorkflow RuntimeState Store / Event HistoryTask Queue / WorkersPolicy / Approval GatesLogs / Metrics / Traces / AuditLLM StepTool AdaptersHuman ReviewERP / CRM / DB / SaaS / Local Files

这种架构的主语是“任务状态”。

生产级 AI 产品往往采用混合架构：

用户自然语言请求Chat UI / API意图识别 / 参数澄清Workflow Runtime确定性节点LLM 判断节点工具调用节点人工审批节点状态与事件历史可观测性与审计外部系统

也就是说，聊天界面负责理解和沟通，runtime 负责执行和控制。对于企业 AI，这通常比“把所有事情都做成一个聊天机器人”更稳定。

5. 适用场景：什么时候用 Chatbot，什么时候用 Runtime

更适合 Chatbot 的场景

Chatbot 更适合低副作用、短链路、以信息交付为核心的场景，例如：

  • 客服 FAQ。
  • 文档问答。
  • 政策解释。
  • 内部知识库检索。
  • 产品说明助手。
  • 内容生成建议。
  • 数据分析解释。
  • 轻量咨询与引导。

这些场景的共同点是：即使回答不完美，通常也可以通过追问、重试或人工确认来修正，系统不会直接产生高风险副作用。

更适合 Workflow Runtime 的场景

Workflow runtime 更适合多步骤、跨系统、有副作用、需要审计的场景，例如：

  • 合同审阅后发起审批。
  • 根据邮件内容创建 CRM 记录。
  • 读取文件、抽取信息、生成报告并归档。
  • 自动生成采购单并等待人工确认。
  • 工单跨系统流转。
  • 营销活动生成后进入审核与发布流程。
  • 法务、人事等高风险流程中的 AI 辅助执行。
  • 本地文件处理、桌面自动化和敏感数据最小外发场景。

这些场景的共同点是：系统不只是“说”，而是“做”。一旦 AI 执行动作，就必须关心权限、审批、恢复和审计。

6. 工程差异：延迟、成本、恢复和可观测性

6.1 延迟目标不同

Chatbot 通常优化首字节时间和响应流畅度。用户希望尽快看到回答。

Workflow runtime 更关注端到端任务完成时间、任务成功率和失败恢复时间。某些流程可能需要几分钟、几小时，甚至等待人工审批几天。此时“立即回答”并不是最重要的指标，“正确完成并可追踪”才是核心指标。

6.2 成本结构不同

Chatbot 的主要成本通常来自模型 token、检索、上下文窗口和并发调用。

Workflow runtime 的成本还包括状态存储、任务调度、队列、日志、追踪、审计、重试、人工审批和外部系统调用。它不一定更便宜，但能把原本隐形的人力排错成本、失败处理成本和合规风险成本显性化。

6.3 失败处理不同

Chatbot 失败后，常见处理是重新生成、重新提问或转人工。

Workflow runtime 需要更精细的失败处理：

  • 节点级重试。
  • 幂等键。
  • 超时控制。
  • 补偿逻辑。
  • 从失败节点继续执行。
  • 手动介入后恢复。
  • 执行历史回放。
  • 错误上下文保留。

这也是 durable execution、state machine、orchestration 等工作流系统长期存在的原因。[6][7][8]

6.4 可观测性不同

Chatbot 的观测重点通常是对话质量、命中率、满意度、召回质量和模型输出。

Workflow runtime 的观测重点更工程化：

  • 每个节点的输入输出。
  • 每次模型调用的 token、成本、延迟。
  • 每次工具调用的参数、结果、错误。
  • 每个审批动作的审批人、时间和意见。
  • 每条任务链路的 trace。
  • 每次失败的根因和恢复方式。

OpenTelemetry、OpenLineage 等可观测性和数据血缘工具的普及，说明现代 AI 系统已经不再只是 prompt engineering，而是完整的软件工程与运营体系。[17][18]

7. 安全与合规：从内容安全走向动作安全

Chatbot 的安全问题主要集中在内容层面，例如错误回答、幻觉、敏感信息泄露、越权回答等。

Workflow runtime 的安全问题更复杂，因为系统可能真的执行动作。风险从内容安全扩展为动作安全：

  • 模型是否能调用某个工具？
  • 工具参数是否经过校验？
  • 写操作是否需要审批？
  • 模型是否接触了不必要的敏感上下文？
  • 外部系统凭据是否与模型隔离？
  • 日志中是否记录了敏感数据？
  • 用户是否可以复盘系统为什么执行某个动作？

在监管语境下，这些问题会进一步涉及个人信息保护、数据安全、网络安全、生成式 AI 服务治理、GDPR、EU AI Act、NIST AI RMF 等要求。[20][21][22][23][24][25][26][27]

因此，企业 AI 产品不能只依靠“安全提示词”。更稳妥的做法是把治理能力做进 runtime：

  • 对工具进行白名单管理。
  • 对高风险动作加入人工审批。
  • 对模型上下文做最小化发送。
  • 对执行链路做完整审计。
  • 对日志和事件历史设定保留策略。
  • 对流程版本、模型版本和提示词版本进行管理。
  • 对外部系统调用使用最小权限服务账号。

从这个角度看，workflow runtime 不只是工程组件，也是治理组件。

8. 产品选型：不是所有 AI 产品都需要复杂 Runtime

并不是每个 AI 产品都应该一开始就建设完整 runtime。过早引入复杂工作流系统，可能会降低迭代速度。

更实际的判断方式是看产品的“成功标准”。

成功标准更适合的主架构
用户能快速获得答案Chatbot
用户能完成一次信息查询Chatbot + RAG
用户能通过自然语言触发简单动作Chatbot + 受控工具调用
系统需要完成多步骤任务Workflow runtime
系统需要写入外部系统Workflow runtime
系统需要人工审批Workflow runtime
系统需要失败恢复Workflow runtime
系统需要审计和合规留痕Workflow runtime
系统既要自然语言入口，又要稳定执行Chat + Workflow runtime

一个实用规则是：

如果产品的核心 KPI 是回复质量，优先优化 chatbot；如果核心 KPI 是任务完成率、失败恢复率、审计通过率和执行 SLA，优先建设 workflow runtime。

9. 从 Chatbot 迁移到 Workflow Runtime 的路径

从 chatbot-centric 迁移到 workflow-runtime-centric，不应一次性推倒重来。更稳妥的方式是逐步把执行逻辑从对话层剥离出来。

第一步：识别高价值意图

先找出那些已经不是“问答”的用户意图。例如：

  • “帮我整理这些文件并生成报告。”
  • “把这封邮件里的客户信息录入 CRM。”
  • “检查合同风险点，没问题就发起审批。”
  • “根据这些资料生成报价单，并发给销售负责人确认。”

这些意图通常已经包含任务、工具、流程和责任边界。

第二步：把工具调用节点化

不要让模型直接决定并执行全部动作。应将工具调用拆成结构化节点：

  • 输入参数。
  • 参数校验。
  • 执行权限。
  • 执行结果。
  • 错误处理。
  • 是否需要审批。
  • 是否允许重试。

模型可以负责判断和生成，但执行必须由 runtime 接管。

第三步：引入状态与恢复

当流程开始跨多个系统，就需要记录任务状态：

  • 当前执行到哪一步。
  • 每一步输入输出是什么。
  • 哪些副作用已经发生。
  • 哪一步失败。
  • 是否可以重试。
  • 是否需要人工处理。
  • 失败后从哪里恢复。

这一步通常是从 demo 走向生产系统的分界线。

第四步：加入审批和审计

对写入、覆盖、删除、发送、提交、支付等动作，应加入 human-in-the-loop。审批记录不应只是聊天记录，而应成为 workflow event history 的一部分。

第五步：保留聊天入口，但不让聊天承载执行逻辑

迁移完成后，chatbot 仍然有价值。它负责理解用户意图、解释流程状态、收集缺失参数、展示结果。但业务执行逻辑应进入 runtime。

10. iAgent7 语境下的产品定位

对于 iAgent7 这类面向工作流执行的产品，关键叙事不应是“又一个 AI chatbot”，而应是：

让 AI 从回答问题进入可审批、可恢复、可追踪的工作执行。

这一区分很重要。因为用户真正的痛点通常不是“缺少一个聊天窗口”，而是：

  • AI 生成结果后还需要人工复制粘贴。
  • 自动化一旦失败就难以恢复。
  • 本地文件、桌面操作和内部流程无法安全接入。
  • 高风险动作缺少审批。
  • 执行过程无法复盘。
  • 敏感上下文不应无限制发送给模型。
  • 多步骤任务无法稳定闭环。

因此，iAgent7 官网文章可以把核心表达集中在三个关键词上：

  1. Reviewable：关键动作可审阅、可批准、可拒绝。
  2. Recoverable：失败后可定位、可重试、可从节点恢复。
  3. Local-first：尽量在本地处理，只向模型发送必要上下文。

这比单纯强调“AI 助手”“智能对话”“自动生成”更能体现 runtime 产品的差异。

结论

Chatbot 是 AI 产品最自然的入口，但不是所有 AI 产品的终局。它适合回答问题、解释信息、处理轻量交互；但当 AI 进入真实业务执行，系统就必须具备状态、工具、审批、恢复、审计和治理能力。

AI workflow runtime 的价值，在于把大模型从一个回答引擎，放进一个可控执行系统。它让确定性逻辑由代码和状态机管理，让不确定性判断由模型辅助，让高风险动作由人工审批把关，让跨系统调用通过工具层执行，让全过程留下可复盘的证据链。

因此，企业 AI 产品的关键问题不是“要不要 chatbot”，而是：

哪些能力留在对话层，哪些能力必须下沉到 runtime。

更成熟的架构不是用 workflow runtime 取代 chatbot，而是让两者分工：chat 负责交互，runtime 负责执行。前者让 AI 更容易使用，后者让 AI 更值得信任。

参考文献

[1] OpenAI. ChatGPT. https://openai.com/index/chatgpt/

[2] Microsoft Azure. Build a retrieval-augmented generation chatbot. https://learn.microsoft.com/en-us/azure/app-service/scenario-ai-chatbot-retrieval-augmented-generation

[3] Patrick Lewis, Ethan Perez, Aleksandra Piktus, et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. https://arxiv.org/abs/2005.11401

[4] Shunyu Yao, Jeffrey Zhao, Dian Yu, et al. ReAct: Synergizing Reasoning and Acting in Language Models. https://arxiv.org/abs/2210.03629

[5] Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, et al. Toolformer: Language Models Can Teach Themselves to Use Tools. https://arxiv.org/abs/2302.04761

[6] Temporal Technologies. Temporal Documentation. https://docs.temporal.io/

[7] Amazon Web Services. AWS Step Functions Developer Guide. https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html

[8] Microsoft Azure. Durable Functions overview. https://learn.microsoft.com/en-us/azure/azure-functions/durable-functions/durable-functions-overview

[9] Google Cloud. Workflows overview. https://docs.cloud.google.com/workflows/docs/overview

[10] Apache Airflow. https://github.com/apache/airflow

[11] Argo Workflows Documentation. https://argoproj.github.io/workflows/

[12] Kubeflow Pipelines overview. https://www.kubeflow.org/docs/components/pipelines/overview/

[13] Prefect Documentation. https://docs.prefect.io/v3/get-started/quickstart

[14] LangGraph. https://github.com/langchain-ai/langgraph

[15] Anthropic. Tool use overview. https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview

[16] Model Context Protocol Specification. https://modelcontextprotocol.io/specification/2025-06-18

[17] OpenTelemetry Documentation. https://opentelemetry.io/docs/

[18] OpenLineage. https://openlineage.io/

[19] Rasa Documentation. https://rasa.com/docs/

[20] 中华人民共和国个人信息保护法. https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm

[21] 中华人民共和国数据安全法. https://www.cac.gov.cn/2021-06/11/c_1624994566919140.htm

[22] 中华人民共和国网络安全法. https://www.cac.gov.cn/2016-11/07/c_1119867116.htm

[23] 生成式人工智能服务管理暂行办法. https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm

[24] General Data Protection Regulation. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng

[25] Artificial Intelligence Act. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng

[26] NIST AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework/ai-risk-management-framework-resources

[27] NIST AI 600-1 Generative AI Profile. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

[28] OWASP Top 10 for Large Language Model Applications. https://owasp.org/www-project-top-10-for-large-language-model-applications/

[29] OWASP Top 10 for Agentic Applications 2026. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[30] iAgent7 Official Website. https://www.iagent7.com/en-US/

2026-06-08Desktop AI Workflow Builder：让桌面 AI 从会操作走向可控执行