从 Chatbot 到 Task Runner：智能体工作流到底解决什么

一次对话不够用的时候

你可能已经有过这样的体验：问一个 Chatbot 问题，它回答得不错；但当你想让它「帮我查一下上周的销售数据，按区域汇总，然后写进周报草稿」时，它只能告诉你怎么做，而不能替你做。

任务性质在这里发生了变化。聊天是一问一答，任务是一连串动作——查数据、做判断、调接口、检查结果、必要时重试，最终交付一个可用的产出。从 Chatbot 到能跑完一条任务链路的 Task Runner，中间隔的是一整套工程架构，而非参数规模。

这篇文章要讨论的就是这条链路：智能体工作流（Agentic Workflow）到底在解决什么问题，它和 Chatbot 有什么本质区别，以及在工程上怎么一步步落地。

1. 从对话到执行：一次范式迁移

1.1 Chatbot 的边界

Chatbot 的核心循环很简单：接收输入 → 生成回复 → 等待下一轮输入。它的成功标准是「回答是否相关、是否有用」。即便加入了检索增强生成（RAG）和工具调用，Chatbot 仍然是一次性的——每次对话是独立的，没有内部状态需要持久化，没有跨步骤的失败恢复，也不需要「交付」一个确定性的结果。

这种模式适合知识问答、内容生成、代码补全等场景。但当你需要系统不只是「说」而是「做」的时候，Chatbot 的局限就开始显现：

• 没有任务拆解能力——复杂目标需要用户自己拆成多个问题
• 没有持久状态——系统不知道「上周」是哪几天，也不知道你已经问了什么
• 没有执行闭环——给出建议后不会验证建议是否可行
• 没有可恢复性——中途出错只能让用户重新开始

1.2 Task Runner 的本质

Task Runner 是 Chatbot 在架构层面的自然延伸。它保留了 LLM 的语言理解和推理能力，但在外层增加了一组工程组件，使得系统能够：

1. 理解目标：将模糊的用户意图转化为可执行的任务描述
2. 制定计划：将任务分解为有序的子步骤
3. 调用工具：在每一步执行具体的动作（查数据库、调 API、写文件）
4. 维护状态：跟踪每一步的执行结果和整体进度
5. 检查与恢复：发现错误后尝试重试或调整计划
6. 交付结果：最终输出一个可验证的、完成度可度量的产出

LangChain 在 2025 年底发布的《State of Agent Engineering》报告显示，57.3% 的受访者已在生产环境部署了智能体，而正确性和可靠性（32%）是首要挑战，其次是响应时间（20%）[1]。这意味着行业已经过了「能不能做 Agent」的阶段，正在面对「怎么让 Agent 可靠运行」的工程问题。

2. 核心差异：四个维度的对比

从 Chatbot 到 Task Runner，变化远超「加一个工具调用」。从四个关键维度做对比：

更本质的区别在于「控制权」。Chatbot 把控制权留在用户手里——用户决定问什么、什么时候结束。Task Runner 在受控边界内自主推进——系统决定下一步做什么、遇到错误怎么办、什么时候算完成。这种控制权的转移，是架构设计中最需要谨慎处理的部分。

3. 架构模式：从 ReAct 到多层编排

学术界和工程界已经总结出多种智能体工作流的架构模式。理解这些模式有助于在实际项目中做出合理的架构选择。

3.1 ReAct 模式：最基本的循环

ReAct（Reasoning + Acting）是目前最广泛使用的智能体模式。它的核心是一个循环：

思考（Thought）→ 行动（Action）→ 观察（Observation）→ 思考（Thought）→ ...

模型在每一步先推理当前状态，然后选择一个工具执行，观察执行结果后继续推理，直到任务完成或判断需要终止。

// ReAct 模式伪代码
while (!task.isComplete()) {
  const thought = llm.reason({
    task,
    history,
    availableTools
  })
 
  if (thought.shouldStop) break
 
  const observation = await tools[thought.action].execute(thought.params)
  history.push({ thought, action: thought.action, observation })
}

ReAct 的优势是简单直接，适合「简单、直接的任务」[2]。它的局限在于没有全局规划——模型走一步看一步，容易在长链路任务中迷失方向或陷入循环。实测数据显示，ReAct 在简单任务上表现良好（约 85% 准确率），但在复杂多步骤任务上准确率会下降[2]。

3.2 Plan-and-Execute 模式：先规划后执行

为了解决 ReAct 缺乏全局视野的问题，Plan-and-Execute 模式将任务拆成两个阶段：

1. 规划阶段：LLM 根据任务目标生成一个有序的执行计划
2. 执行阶段：逐步执行计划中的每个步骤，必要时可以重新规划

// Plan-and-Execute 模式伪代码
const plan = await planner.generatePlan(task)
 
for (const step of plan.steps) {
  const result = await executor.execute(step, context)
 
  // 检查是否需要重新规划
  if (result.requiresReplan) {
    const newPlan = await planner.replan(task, plan, result)
    plan.steps = newPlan.steps
  }
}

Plan-and-Execute 在准确率上优于 ReAct（约 92%），但代价是更高的 token 消耗和延迟（3000-4500 tokens vs 2000-3000 tokens）[2]。它适合「复杂的多步骤任务」和需要高准确率的场景。

3.3 编排模式：Supervisor、Pipeline 与 Swarm

当单个 Agent 无法胜任复杂任务时，就需要引入多 Agent 编排。微软 Azure Architecture Center 和 Google Cloud 都发布了各自的编排模式指南[3][4]，以下是几种核心模式的对比：

实际项目中，这些模式经常混合使用。一个典型的周报生成工作流可能是：Pipeline 负责「采集→清洗→分析→撰写」的主链路，Supervisor 在分析阶段根据数据量动态分配多个分析 Worker，最后通过一个审校 Agent 做质量检查。

5. 工程落点：最小可用架构

一个最小智能体工作流不需要复杂的框架。核心组件和它们各自解决的问题如下：

// 最小智能体工作流骨架
interface AgentWorkflow<TInput, TOutput> {
  // 任务输入
  input: TInput
 
  // 计划生成（可以是 LLM 动态生成，也可以是预定义模板）
  plan: TaskStep[]
 
  // 执行引擎
  execute(): Promise<TOutput>
 
  // 状态查询
  getStatus(): WorkflowStatus
 
  // 日志查询
  getLogs(): ExecutionLog[]
}
 
interface TaskStep {
  name: string
  tool: string
  params: Record<string, unknown>
  dependsOn?: string[]
  retryPolicy?: { maxRetries: number; retryOn: string[] }
  requiresConfirmation?: boolean
}

关键原则：每一步都应能记录 trace（输入、输出、耗时、状态），方便失败后复盘。这是 LangChain 报告中提到的另一个数据点——89% 的组织已经在使用某种形式的遥测，62% 使用逐步日志[1]。可观测性是生产环境的基本要求，而非锦上添花。

6. 选择指南：什么时候该用 Agent，什么时候不该

并非所有场景都需要 Agent 工作流。以下表格帮助做判断：

总结成一句话：适合 Agent 的场景通常有明确目标、可调用工具、可验证结果和可恢复的失败路径。不适合一开始交给 Agent 的场景，是高权限、不可逆、强合规或结果难以验证的任务。

7. 落地检查清单

当你的团队准备从 Chatbot 升级到 Task Runner 时，可以用以下清单做自查：

任务定义

• 任务目标可以用一句话描述清楚（如果描述不清，先做需求澄清）
• 任务的输入和输出都有明确的类型定义
• 任务的完成标准是可验证的（不是「用户满意」这种模糊标准）

计划与执行

• 步骤数量在可控范围内（初期建议不超过 10 步）
• 每个步骤都有明确的输入、输出和超时时间
• 步骤之间的依赖关系是清晰的（哪些可以并行，哪些必须串行）

工具与权限

• 每个工具都有参数校验和错误处理
• 工具调用的权限边界是明确的（最小权限原则）
• 不可逆操作有人工确认环节

状态与可观测性

• 任务状态可以被查询（pending / running / completed / failed）
• 每个步骤的执行日志被持久化（包括输入、输出、耗时、错误）
• 失败后可以回溯完整执行链路

失败处理

• 每个步骤都定义了重试策略（重试次数、重试条件）
• 整体任务有超时保护
• 有降级方案（Agent 失败后可以优雅地回退到人工处理）

8. 常见误区

在帮助团队落地智能体工作流的过程中，有几个误区值得提前指出：

误区一：越复杂的架构越好。 早期实现不需要多 Agent。一个 Agent 稳定完成一类任务，比同时设计多个角色更有价值。多 Agent 编排引入的复杂度（通信、状态同步、错误传播）远超大多数早期项目的需求。

误区二：Agent 应该完全自主。 生产环境中，关键操作需要人工确认。这不会降低用户体验，反而增加了系统的可信度。「人工在环」（Human-in-the-Loop）是工程成熟度的体现，而非能力缺陷。

误区三：用框架就能解决问题。 框架（LangGraph、CrewAI、OpenAI Agents SDK 等）提供了有用的抽象，但它们不解决任务定义、权限边界和失败处理的设计问题。先用原生 API 跑通一个最小工作流，再考虑引入框架。

误区四：Token 成本不重要。 在规划阶段，一个任务可能消耗 3000-4500 tokens，如果涉及多次重试或多 Agent 通信，成本会成倍增长。早期就应该监控每个任务的 token 消耗，建立成本基线。

9. 下一步

智能体工作流是一个正在快速演进的领域。从 Chatbot 到 Task Runner 的迁移不是一步到位的——它更像是一个渐进过程：先让 Chatbot 能调用工具，再加工具增加状态管理，然后加状态管理引入任务编排，最后根据规模决定是否引入多 Agent。

每一个阶段都应该在当前架构稳定之后再推进到下一个阶段。跳过中间步骤直接搭建复杂架构，是大多数 Agent 项目失败的原因。

下一篇我们会讨论智能体工作流中的状态管理设计——如何在步骤之间传递上下文、如何处理状态回滚、以及如何让任务在中断后恢复执行。

参考资料

[1] LangChain. State of Agent Engineering. 2025. https://www.langchain.com/state-of-agent-engineering

[2] James Li. ReAct vs Plan-and-Execute: A Practical Comparison of LLM Agent Patterns. 2024. https://dev.to/jamesli/react-vs-plan-and-execute-a-practical-comparison-of-llm-agent-patterns-4gh9

[3] Microsoft Azure. AI Agent Orchestration Patterns. 2026. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns

[4] Google Cloud. Choose a Design Pattern for Your Agentic AI System. 2026. https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system

[5] Developers Digest. 7 AI Agent Orchestration Patterns Every Developer Should Know. 2026. https://www.developersdigest.tech/blog/seven-ai-agent-orchestration-patterns

[6] arXiv. Agentic Artificial Intelligence: Architectures, Taxonomies, and Challenges. 2026. https://arxiv.org/html/2601.12560v1

[7] Vellum. The 2026 Guide to AI Agent Workflows. 2025. https://www.vellum.ai/blog/agentic-workflows-emerging-architectures-and-design-patterns

[8] Machine Learning Mastery. 7 Agentic AI Trends to Watch in 2026. 2026. https://machinelearningmastery.com/7-agentic-ai-trends-to-watch-in-2026/