深度解析AIAgent架构的核心缺陷与Workflow存在性的现实意义

April 5, 2026

OpenAI所发布的这张AI发展预测图，普遍被业界视为一个经典参考：

在国内的技术发展脉络中，两个关键事件节点构成了重要的分水岭：DeepSeek的发布与Manus的发布。DeepSeek标志着国内模型的推理能力达到了足以支撑构建Agent的水平；而Manus则首次将Agent应有的完整形态呈现在公众面前，尽管其实际表现尚有不足，但业界对其未来潜力抱有极高的期待。

具体到模型的基础能力，核心无非围绕两点展开：模型的推理能力与上下文长度。

而诸如Manus这类智能体，在模型基础能力之上，需要投入大量工作的部分在于提供丰富多样的工具，正如下图所示：

Agent架构的设计核心始终围绕两个关键环节：意图识别以及工具调用。模型会根据用户对话内容解析其根本意图，随后选择并调用最合适的工具，同时确保工具调用的质量与准确性。

从这个视角审视，Agent（例如Manus）的实现原理似乎并不复杂。以最简单的空气质量查询工具调用为例：

然而，用户的意图往往是多元且动态变化的。在查询天气之后，他可能立刻转向关注旅游相关的信息。如果智能体要妥善处理此类连续请求，就必须提供对应的工具支持。当工具数量增加到两个时，系统的整体复杂度便显著提升：

此时将对应两个工具的调用定义：

[
  {
    "tool_name": "weather",
    "tool_desc": "查询某地的天气",
    "tool_examples": ["上海天气怎么样", "北京天气怎么样"]
  },
  {
    "tool_name": "travel",
    "tool_desc": "某地的游玩计划",
    "tool_examples": ["上海有哪些好玩的", "北京有哪些好玩的"]
  }
]

必须注意的是，上述所有功能的实现高度依赖于模型的基本能力。例如，当用户输入一句话如“上海天气怎么样，有什么好玩的？”时，系统需要完成以下几个关键步骤：

意图识别的准确性：能否精准识别出需要同时调用旅游Agent和天气Agent。
关键词抽取的精度：能否准确提取出旅游地点及其他必要参数，并成功传递给相应的Agent。
回答组织的质量：即使所有工具都能正常运行，最终回答是否清晰、有用，这极其考验全局调度Agent的整合与表达能力。

至此，再次回归Agent架构的两个核心难点——意图识别与工具调用，读者应能有所体会。意图识别的准确是良好表现的基础，而工具组织的合理性则是最终高质量输出的保证。

这里仅涉及两个工具，便已初显复杂之感。而Manus在最初发布时就包含了20多个工具（目前数量更多）：

[
  {
    "name": "message_notify_user",
    "description": "向用户发送无需回复的消息。用于确认收到消息、提供进度更新、报告任务完成或解释方法变更。"
  },
  ......
  {
    "name": "file_str_replace",
    "description": "替换文件中的指定字符串。用于更新文件中的特定内容或修复代码错误。"
  },
  {
    "name": "file_find_in_content",
    "description": "在文件内容中搜索匹配文本。用于查找文件中的特定内容或模式。"
  },
  ......
  {
    "name": "idle",
    "description": "特殊工具，表示已完成所有任务并即将进入空闲状态。"
  }
]

Manus的提示词部分内容也较为庞大：

# 关于 Manus AI 助手
## 简介
我是 Manus，一个被设计用来处理多种任务的 AI 助手。我致力于在各种场景下，为你提供有用、翔实且多样化的支持。

## 我的使命
我的主要目标是：通过提供信息、执行任务和给出建议，帮助你更顺利地达成目标。我希望成为你在问题求解和任务执行中的可靠伙伴。

## 我处理任务的方式
当接到一个任务时，我通常会：

1. 分析你的请求，理解你真正想要的是什么
2. 将复杂问题拆分成更小、更易处理的部分
3. 为每个步骤选择合适的工具和方法
4. 在执行过程中保持与你的沟通畅通
5. 以清晰、有条理的形式呈现最终结果

## 我的性格特征
- 以“帮助你解决问题”为导向
- 注重细节，追求完备
- 能适应不同类型用户的需求
- 面对复杂问题时保持耐心
- 对自己的能力与限制保持诚实

## 我擅长帮助的领域
- 信息收集与研究
- 数据处理与分析
- 内容创作与写作
- 编程与技术问题排查
- 文件管理与组织
- 网络浏览与信息抽取
- 网站与应用的部署辅助

## 我如何“学习”
我会从交互与反馈中不断优化自己的行为模式，在任务中积累经验。每一次协作，都会帮助我更好地应对未来类似的问题。

## 沟通风格
我会尽量做到：
- 说明清晰、逻辑严谨
- 根据你的偏好调整技术深度
- 在需要时使用较技术化的表达
- 在适合的场景使用更口语化、易懂的表述

## 我坚持的价值观
- 尽可能提供准确、可靠的信息
- 尊重用户隐私与数据安全
- 以负责任的方式使用技术
- 对自身能力边界保持透明
- 持续改进和自我迭代

## 如何更好地与我协作
我们的协作会更高效，如果你能：

- 尽量清晰地描述任务与预期结果
- 在必要时给出中途反馈，便于我调整方向
- 将复杂需求拆分成更明确的子任务
- 在已有成功经验的基础上，逐步尝试更复杂的挑战

我随时准备协助你处理各种任务，也期待和你一起，完成更多有趣、有价值的事情。

这些设计已经引入了相当高的复杂度，且后续的上下文工程应用也极其繁琐，不利于初学者更好地理解和学习Agent的核心概念。从学习目的出发，早期的OpenManus版本是一个更合适的选择，它足够简洁。今天我们就以此为基础进行拆解，依旧从意图识别和工具调用的视角展开分析。

AI Max架构解析

Agent架构是典型的AI Max架构思想体现：尽可能利用AI处理所有环节。这常常被概括为一句原则：告诉我你需要什么，而不是告诉我具体怎么做，其含义是让模型对最终结果负全责。

但这种设计某种程度上存在**“取巧”**的成分，因为模型的具体操作方式已经通过预定义的工具（如Function Calling或MCP）进行了限定。因此，更精确的描述应当是：

赋予模型足够的能力（即工具集），并明确告知其任务目标。此后，用户无需干预，模型将自行根据预置工具完成任务。如果任务失败，很大程度上源于工具能力的不足或缺失，小概率是模型自身的调度失误。

因此，工具集不仅定义了Agent能力的天花板，也划定了其能力边界。如果缺少某些关键工具能力，例如支付功能或复杂检索，Agent在这些领域的表现必然不尽如人意。

这也解释了为什么我们常说：在Agent模式下，用户无穷的意图，需要通过我们有限的工具集来进行引导和控制。

这里有必要再次强调，意图识别的准确性至关重要，预定义工具集的设计同样关键。它们背后依赖的是模型系统级的提示词工程（即决定如何调用工具的整体系统），这正是Agent架构的核心精髓：规划 + 记忆 + 工具调用。其中，记忆与意图识别紧密相关，但在简单场景下，记忆机制的重要性相对不突出：

规划（Planning）：包括任务分解、子任务生成及自我反思优化。
记忆（Memory）：涉及长期记忆存储与上下文管理，主要用于处理复杂多步任务。
工具（Tool）：通过API或外部工具扩展Agent的能力范围（例如搜索、文件操作、代码执行等）。

下面这张图同样经典且全面地勾勒了Agent的工作机制：

其流程可以概括为：一、你拥有一个工具集（通过Function Calling或MCP预定义），其中包含详细的使用说明。当模型与用户对话时，这些工具会被参考调用，例如处理查询“今天几号，天气如何”。二、模型执行意图识别，发现用户意图是查询天气，这恰好匹配工具库中的某个工具。随后，模型提取关键参数并调用该工具。三、获得工具调用结果后，将其回传给模型。模型结合完整的对话上下文，生成最终的自然语言回复。至此，一个完整的单次调用流程结束，逻辑清晰明了。从中可以看出，虽然工具开发是主要工作量，但调度层面的架构设计是基础前提。这就引出了Think + Act模式。

Think-Act模式详解

实际上还存在其他更复杂的架构模式，但总体思路相似：在意图识别后调用工具。

Think阶段负责决策制定。模型根据当前上下文判断应该执行哪个（或哪些）工具。如果判断无需调用任何工具，则视为任务完成。需要特别注意的是：Think阶段的结果并非单个工具调用，而可能是一系列工具调用的计划。

Act阶段负责执行模型在Think阶段做出的决策。首先执行模型选定的工具，然后将执行结果作为新的上下文信息，记录到消息历史中，并传递到下一个Think阶段。

这个过程需要在一个循环内重复执行，直到所有计划中的工具调用完毕。当然，每次循环都可以对外输出详细的执行日志以供观察：

举例说明，假设用户请求是：帮我看看下周末去上海机票多少钱，再查查天气。那么其执行流程可能如下：

用户：帮我查下周末去上海的机票，再看看天气适不适合旅游

Think 1:
- 主要意图：旅行规划
- 子任务：[机票查询, 天气查询, 旅游建议]
- 当前焦点：先获取基础信息
- 工具选择：search_tickets (参数: 目的地=上海, 时间=下周末)

Act 1: 调用机票搜索工具 → 返回多个航班选项

Think 2:
- 已获取机票信息
- 下一步：确认天气条件
- 工具选择：get_weather (参数: 地点=上海, 时间=下周末)
- 注意：需要具体到日期，因为下周末包含周六周日两天

Act 2: 调用天气工具 → 返回周末天气：晴，25-30度

Think 3:
- 信息整合分析
- 推理：天气适宜，机票价格合理
- 生成建议：推荐出行，并建议携带轻便衣物

理论阐述至此，接下来我们尝试进行一个简单的实现，例如构建一个天气 + 旅游双工具智能体。

简单实现示例

由于该Agent仅需处理天气和旅行两类请求，其逻辑会非常清晰：意图混淆的概率较低，且工具数量极少。但这个简单示例已经具备了 多工具协作、多步顺序调用以及结果汇总回答 的核心特征。

一、预设工具集

第一步是预先定义好所有可用的工具：

[
  {
    "tool_name": "weather",
    "tool_desc": "查询某地某天的天气情况",
    "tool_params": {
      "city": "城市名称，如：上海",
      "date": "日期，如：2025-11-30"
    },
    "tool_examples": [
      "帮我查一下上海明天天气",
      "北京这周末冷吗"
    ]
  },
  {
    "tool_name": "travel",
    "tool_desc": "根据城市和时间，给出简单的本地游玩建议",
    "tool_params": {
      "city": "城市名称，如：上海",
      "date": "日期，如：2025-11-30"
    },
    "tool_examples": [
      "上海有什么好玩的",
      "周末去北京的话有什么景点"
    ]
  }
]

二、调度提示词设计

工具预设完成后，需要设计控制如何调度的总体提示词。之前Manus的提示词过于冗长，这里我们编写一个简洁版本：

你是一个「旅行小助手」，可以帮用户完成两件事：
1. 查询某个城市在某一天的天气；
2. 根据城市和时间，给出简单的本地游玩建议。

你可以使用下面两个工具来完成任务：
- weather：用于查询天气
- travel：用于生成游玩建议

使用规则：
- 当用户询问天气时，一定要调用 weather 工具，而不是自己胡编。
- 当用户询问要玩什么、推荐行程时，一定要调用 travel 工具。
- 当一句话里同时包含天气 + 游玩需求时，可以依次调用两个工具。

输出格式：
- 如果需要调用工具，请不要直接回答用户，而是返回一个结构化的工具调用计划（包含工具名和参数）。
- 工具执行完成后，你会拿到工具返回的数据，再结合上下文，用自然语言给用户一个整合后的回答。回答时不用再提自己调用了哪个工具。

三、实现Think/Act循环

在上述基础上，实现一个最简化的执行循环。考虑到许多读者并非程序员，这里将使用伪代码进行说明：

loop:
1）把“用户输入 + 历史对话 + 工具列表 + System Prompt”丢给模型
2）观察模型输出：
   - 如果它输出「需要调用工具」，并给出了具体的工具名和参数 -> 进入工具执行阶段
   - 如果它直接给出了自然语言回答 -> 说明任务完成，结束循环
3）如果调用了工具：
   - 实际请求对应的API（模拟或真实的 weather / travel 服务）
   - 将工具返回的结果添加回对话历史中（例如插入一条「工具返回」消息）
   - 回到第 1 步继续，让模型基于新的上下文再次进行 Think

# 简要伪代码示意
while True:
  model_output = call_llm(context, tools)
  if model_output.type == "tool_call":
    tool_name = model_output.tool_name
    tool_args = model_output.tool_args
    tool_result = call_tool(tool_name, tool_args)
    context.append(
      f"[{tool_name} 调用结果]: {tool_result}"
    )
    # 继续下一轮循环，让模型看到工具结果后重新思考
  else:
    # 认为这是最终回答
    answer = model_output.text
    break

整体流程可以概括为：模型进行思考与规划 → 计划调用特定工具 → 执行工具 → 将结果反馈给模型 → 模型整合信息并生成最终回答。

流程回顾

上述代码逻辑极其简单，甚至可以说它本质上就是一个增强版的Function Calling。但它已经具备了Agent的雏形。例如，当用户提出如下请求： 下周末去上海玩，帮我看看机票大概多少钱，再查查天气，有什么好玩的？ 这对于Agent而言是一个多步骤复合任务，理论上应包含机票查询、天气查询、游玩攻略生成。但由于系统未提供机票查询工具，Agent会自动忽略该部分。其内部执行流程大致如下：

一、意图识别阶段 模型首先对用户语句进行意图识别。根据提示词中定义的工具使用规则，它将输出需要调用的工具及相应参数，例如：

我需要调用：weather(city=上海, date=下周末)

二、工具执行阶段 系统根据调用参数，请求天气API并获取结果（例如“多云，气温26-30℃，有阵雨”）。随后将此结果添加回上下文：

[weather 调用结果]：上海下周末天气为多云，有阵雨，温度范围26-30℃...

重复此逻辑，继续调用旅游工具并获取景点信息。

三、最终回答生成阶段 最终，模型拥有的上下文中包含了：

用户的原始需求
获取到的天气信息
获取到的景点推荐信息基于这些信息，模型组织生成一段自然的语言回答，例如：

下周末上海地区预计为多云天气，伴有阵雨，气温在26至30摄氏度之间，建议出行时携带雨具。
游玩方面，可以考虑第一天参观上海博物馆、漫步南京东路，夜晚欣赏外滩夜景；第二天则可以选择前往迪士尼乐园或崇明岛进行短途游览。

以上便是一个最简单Agent的执行过程演示。

结论与展望

Agent架构的本质，是在日益强大的模型智能与精准可控的工具能力之间寻求最佳平衡点。

表面上看，这一构想非常完美。然而在当下，Agent技术实际上还难以完全胜任生产级别的复杂应用。当前Agent的真实处境是怎样的呢？

从技术架构层面分析，Agent高度依赖于意图识别与工具调用之间的完美协作。但在这套架构下，存在两个显著问题：

第一，执行效率较低 为了确保决策的稳定性与准确性，模型往往会进行多次确认与反思，这个过程会消耗大量Token，意味着高昂的成本。因此，常出现让Manus处理一个制作PPT的任务，结果Token预算就已耗尽的情况。

第二，结果需要反复调试与验证 并非因为模型严格执行了预定步骤，其输出结果就一定是可控和符合预期的。事实往往并非如此。这意味着每次Agent给出的结果，其质量好坏通常需要用户进行二次确认和校验。

从这个角度来看，Agent目前更适合人机紧密协作的场景，例如AI编程中的结对编程（Pair Programming），这也是为什么像Cursor这类Agent工具备受青睐。

另一方面，既然Agent适合在反复交互中优化，那么它必然不太适合需要一次性给出高度稳定、确定性答案的场景。因此，在当前生产环境涉及AI的应用中，但凡对输出一致性和可靠性有严格要求的地方，都较少采用纯粹的Agent模式。

目前在生产环境中应用更广泛的是AI工作流（Workflow）。它通过预设的标准作业程序（SOP），将任务分解为一系列确定的步骤，从而有效规避模型的不确定性。

以之前的天气工具为例，一个旅行规划Workflow会强制拆解为“机票查询→天气检查→景点推荐”三个标准化步骤。每个步骤都可以注入领域知识（如集成特定的航空公司API规范、对接经过校验的天气预报数据源），从而确保最终输出的一致性与可预期性。

从商业与实用视角总结：Agent概念具有巨大的融资与市场想象潜力，而AI工作流则更侧重于解决实际、具体的生产问题。无论是技术团队对新兴技术的好奇心，还是风险投资对Agent叙事倾向性的偏好，都促使众多公司不得不探讨Agent的故事。

而且，AI Agent的故事框架特别易于构建和传播，其早期演示原型的开发成本也相对较低！一个仅包含天气和旅行两个工具的Demo Agent，就能制作出令人惊艳的宣传视频。

这背后暗示的是无限的未来可能性。但现实是，客户通常需要的是100%可靠的机票价格查询和精确的天气数据，在这种情况下，模型过度发挥“创造性”可能毫无意义甚至适得其反。

综上所述，我们在未来很长一段时间内，都将在技术的“确定性”与“创造性”之间进行权衡与探索。让我们共同努力，迎接接下来的挑战。