从定义出发

每个人对 AI Agent 的定义都略有不同。

一些人将 agent 定义成完全自主的系统，能在较长的时间内独立运行，能使用各种工具来完成复杂的任务。

另一些人将 agent 指代更具流程化的实现，它们按照预先定义的工作流（workflow）执行。

Anthropic 将所有这些变体归类为 agentic systems，但是在 workflows 和 agents 之间划定了重要的架构区别：

  • workflows 是指通过预定义的代码路径来编排 LLM 与工具的系统
  • agents 是指由 LLM 动态地指导和决策自己的流程和工具使用方式的系统，始终由 LLM 来掌控完成任务的方式

Agent 版本

在项目初期，我们就致力于构建一个完全自主、可持续迭代的 AI Agent，LLM 将参与任务执行的全流程。从目标的定义、任务的拆分和执行、策略的选择再到工作流程的动态调整，期望这些步骤全都交由 LLM 来参与并执行。

我们的系统设计目标很“简单”：当用户说一句“帮我运营 Twitter 账号”，Agent 就能自动搞定从策划到执行的全流程。整个流程可以拆成三个关键环节，每个环节都遇到了现实的挑战。

（btw：当时大家普遍还沉浸在 GPT 带来的震撼中，对 LLM 实际应用场景的局限性认识尚浅。而采用 Workflow 工作流架构这类更务实的解决方案，是在经历了实践后才逐渐形成的共识。）

整体流程

第一环节：目标定义

当用户丢过来一个模糊目标时，Agent 首先会判断这个目标在借助当前已知信息和工具的基础上是否可实现。

已知信息和工具：是根据业务需求预先定义的一些描述内容。比如：Twitter Agent 可以借助于浏览器插件能力获取当前用户的账户信息、搜索推文、发送评论等

如果用户的目标是注定不可能实现的，比如：“我要一夜暴富”，则直接反馈给用户并且终止流程。

如果用户的目标是可以借助于现有工具实现的，但是还缺失一些细节信息以支撑目标完整执行，则 Agent 会继续追问用户补充细节直至定义出一个清晰可执行的目标。

比如用户就说了一句“帮我运营 Twitter 账号”，Agent 可能会识别出需要补充的信息有：运营的具体目标是什么？是增加粉丝数、提高互动率，还是其他指标？然后，目标受众是谁，这会影响内容的方向和策略。接下来是内容策略相关的问题，比如内容主题、发布频率、是否使用图片或视频等多媒体元素。时间框架也是一个关键点，用户希望在多长时间内看到结果。等等等等

存在的问题：

  • 可行性误判：LLM 对“可实现性”的判断依赖训练数据的统计特征，而非真实业务逻辑。存在假阳性和假阴性的问题

    比如在 Twitter 运营场景中：

    • 假阳性案例：用户要求“每月自然增长10万真实开发者粉丝”，系统误判为可行（未考虑账号冷启动阶段的实际增速上限）
    • 假阴性案例：用户提出“通过技术教程提升互动率”，系统错误拒绝（因训练数据中缺少垂直领域成功案例）

    可行性的误判直接导致后续流程全链失效

  • 信息补全的无止尽追问：LLM 可能无法有效识别所有必要信息，或者追问的顺序和方式不合理，导致用户流失。例如，用户可能需要回答太多问题，感到繁琐而放弃

  • 上下文信息丢失：就算已知信息和工具能力的描述再全面，用户补充的信息再细致，LLM 都可能存在误判以及最终定义的目标缺失关键信息的问题。这将直接影响后续所有流程的执行质量和成功率

第二环节：任务拆解

当有了一个清晰可执行的目标之后，就需要把这个复杂的目标拆解成多个子任务，然后以合理的方式组织起可执行的任务链。

假设当前的目标是“关注 AI 领域的最新进展，以一天 20 条评论的频率积极的在评论区友好互动，以增加账号的曝光度”，系统需要拆解出可执行的任务链，理想情况是：

搜索 AI 领域的推文 -> 分析推文内容 -> 生成评论内容 -> 发布评论 -> 反馈调整

但实际 LLM 在这一步的表现及其不稳定，效果也及其差劲。

存在的问题：

  • 拆分的任务不合理。就算严格要求按最小粒度拆分，很多时候还是会把一些子任务拆分的很宽泛、不具体，导致后续不可执行
  • 复杂的目标无法通过简单的线性流程来表达，而现阶段 LLM 在表达复杂的流程控制的能力上效果很弱，这也注定了现阶段能应对的目标场景极其有限

第三环节：执行与调整

在每个子任务的执行阶段，都会经历以下过程：

  1. 检查该任务的前置条件是否满足。告知 LLM 当前完整的上下文信息和已执行任务的结果，以及当前任务的详情，来判断是否满足执行的前置条件
  2. 如果存在缺失信息，Agent 通过追问的方式让用户补充完整，直至满足任务执行的前置条件
  3. Agent 利用现有信息和工具，填充工具的调用参数，然后交由程序执行对应工具，来完成实际任务的执行
  4. 执行完成之后，不管成功还是失败，将当前任务的执行结果更新至上下文中。接着根据最新的所有信息，判断目标是否实现。若判断目标已完成，则成功终止流程；若判断未完成，则根据当前所有已知信息，考虑对接下来的任务重新进行规划（当前任务执行成功则按原计划进行，执行失败才需要重新规划后续流程）
  5. 重复以上过程，直至目标实现

存在的问题：

  • 任务是由 LLM 生成的，任务的前置条件也是由 LLM 思考得出的。不稳定因素的叠加，导致最终效果很不可控
  • 同样存在信息补全的无止尽追问问题，以及上下文信息丢失的问题
  • 任务流程的动态调整阶段，同样会存在第二环节任务拆解中存在的问题
  • 在迭代执行的过程中，有可能陷入动态流程调整的循环中出不来，导致目标永远无法实现

现阶段的瓶颈

  • 幻觉问题：LLM 生成的内容可能不准确或虚构，这在需要精确执行任务的 Agent 中会导致错误决策
  • 输出不稳定：LLM 的输出不稳定不仅体现在结果的随机性差异上，还表现在输出不符合预期结构，直接导致程序解析失败，无法继续运行。虽然可以通过调整 temperature 参数或者结合一些工程化的手段（比如使用 function_call、重试）来让输出更趋于稳定，但模型本身的随机性难以彻底消除
  • 上下文信息丢失：长文本处理中的遗忘问题，特别是在长对话或多步骤任务中，LLM 可能忘记之前的步骤或信息。就算上下文长度并不长，LLM 在生成内容时也可能遗漏人类所认为的关键信息，这一点可以通过 prompt 优化的方式改善，但无法完全避免
  • 复杂逻辑推理能力有限：LLM 在处理需要多步骤逻辑推理或数学计算的任务时表现不佳。比如，分解复杂问题、规划子任务时可能出现错误。这可能需要结合符号逻辑系统，但 LLM 自身的能力不足以处理复杂逻辑链

上述问题虽然可以通过一些手段得到改善（主要是 prompt 调优以及合理的工程实践方案），但归根到底更依赖于模型本身能力的提升

Workflow 版本

经过上述实践，我们认识到现阶段 LLM 的能力还难以支撑一个完全自主的智能系统 —— 特别是在动态决策流程方面的局限性尤为明显。基于这一认知，我们转向了更可控的 Workflow 工作流架构，以此来构建更可靠的 AI 产品。

AI Agent 的 Workflow 模式是一种通过编排多步骤任务流程来实现复杂目标的方法。它通过将任务分解为可管理的子任务，结合规则、工具调用、决策逻辑和外部系统交互，最终完成端到端的目标。

整体架构

node 是 workflow 的最小执行单元，它封装了基础的功能实现，借助 node 的输入输出和不同 node 之间的连接结构，最终驱动着整个 workflow 的运行。

系统支持以下模式：

  • 顺序执行模式：任务按固定顺序执行，前一步的输出是后一步的输入
  • 并行模式：同时执行多个独立子任务（如同时调用多个API）
  • 分支模式：根据条件（如用户意图、数据状态）选择不同执行路径
  • 事件驱动模式：由外部事件（如用户输入、系统消息）触发特定流程。适用于：实时交互、异步任务处理等场景
  • 循环迭代模式：通过循环迭代直到满足终止条件（如达到最大轮次或结果符合预期）

更多的扩展功能也能在上述的基础上很方便的集成进来，比如：第三方 API、数据持久化和检索、RAG 的应用等

借助于这些模式，我们能够根据具体业务场景以代码方式构建相应的工作流。在这种架构下，AI 能力作用于节点的输入输出，而非整体流程的控制，从而让产品效果更加可靠

面临的挑战

  • 复杂性管理：随着业务功能的增加，工作流的逻辑复杂度呈指数级增长（如多分支、循环、并行、异常处理），节点间的依赖关系难以清晰定义
  • 性能和资源优化：节点数量的膨胀导致内存占用飙升，需要合理优化节点的调度机制和生命周期管理
  • 成本效益：LLM 调用成本随流程复杂度线性增长（如多轮生成和推理），需要合理优化 LLM 使用策略来平衡效果和成本

上述问题都可以通过合理的优化方案来解决，比如通过模块化设计将子流程封装为可复用的组件、引入适当的缓存机制等。总的来说，实践证明，基于 workflow 架构开发 AI 产品是一种行之有效的方案。