深入解析AI Agent架构的局限性与工作流解决方案的优劣

April 5, 2026

首先，OpenAI提出的这张AI发展预测图，在行业内具有相当的参考价值：

对于国内AI发展进程而言，有两个关键节点可以视为分水岭：DeepSeek的发布与Manus的发布。DeepSeek标志着国内大模型在推理能力上达到了足以支撑Agent应用的水平；而Manus则首次向业界展示了Agent应有的完整形态。尽管其早期表现不尽完美，但它极大地提升了市场对AI 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所使用的提示词（Prompt）部分内容也相当庞大：

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

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

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

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

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

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

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

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

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

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

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

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

这些组件共同构成了极高的系统复杂度，加之后续上下文工程的应用也极其复杂，这并不利于初学者更好地理解和学习Agent的核心原理。从学习目的出发，早期的OpenManus版本结构相对简单，是一个不错的分析对象。我们今天便以此为例进行拆解，依然从意图识别和工具调用的角度切入。

AI密集型架构的隐忧

Agent架构是典型的AI密集型（AI Max）架构：其核心原则是凡是能用AI解决的部分，就全部交给AI处理。这对应着那句常见的话：告诉我你要什么，不要告诉我怎么做，其含义是模型最终将为结果的全过程负责。

然而，这种设计存在一定的**“取巧”**成分。因为模型具体“如何做”实际上已经通过预定义的工具（如Function Calling或MCP协议）规划好了。因此，更准确的说法应当是：

赋予我足够的能力（即工具集），并清晰告知你的目标。之后的过程你无需干预，我将自行根据你提供的工具来完成任务。如果任务失败，大概率是因为工具能力不足（数量不够或功能不全），小概率是我（模型）在调度上出现了失误。

所以，工具不仅决定了Agent能力上限，也严格划定了其能力边界。如果工具能力不支持某些操作，例如缺少支付接口或复杂检索功能，那么Agent在这些方面的表现必然不佳。

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

这里需要再次强调，意图识别的准确性至关重要，预定义工具集的完备性同样关键。它们背后依赖的是一套系统性的模型提示词工程，这套提示词决定了模型如何调用工具。这正是Agent架构的核心精髓：规划（Planning） + 记忆（Memory） + 工具调用（Tool Use）。其中，记忆与意图识别关系密切，但在简单场景下，记忆的重要性相对较低。这三个核心组件具体指：

规划（Planning）：包括任务分解、子任务生成及过程中的自我反思与调整。
记忆（Memory）：涉及长期记忆的存储与上下文管理，主要用于处理需要历史信息的复杂任务。
工具（Tool Use）：通过API或外部工具来扩展Agent的能力边界（例如网络搜索、文件操作、代码执行等）。

下面这张图较为经典且全面地阐释了Agent的工作机制：

其工作流程可以概括为：一、你拥有一系列工具（通过Function Calling或MCP预定义的工具集），每个工具都有详细的功能说明。当用户发起对话，例如询问“今天几号，天气如何”时，这些工具描述会被送入模型。二、模型进行意图识别，发现用户意图是查询天气，这恰好匹配工具库中的某个工具。随后，模型提取关键参数（如地点、日期）并准备调用该工具。三、获得工具调用的结果后，将其回传给模型。模型结合完整的对话上下文，组织并输出最终的自然语言回答。至此，一个完整的单次调用流程结束，逻辑清晰明了。从中可以看出，尽管工具开发是主要工作量，但调度环节的架构设计是整个系统运行的准入基础。这便引入了Think（思考） + Act（执行）模式。

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只需处理天气和旅行两类需求，其逻辑会非常清晰：意图混淆的概率低，且工具数量极少。但这个简单的例子已经具备了多工具支持、多步调用以及结果汇总回答的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循环实现

基于以上组件，我们可以实现一个最小化的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会主动忽略该部分。其内部执行流程如下：

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

调用计划：
1. 调用 weather(city=上海, date=下周末)
2. 调用 travel(city=上海, date=下周末)

二、工具执行 系统根据调用计划，首先请求天气API，获得结果（例如：“上海下周末多云，有阵雨，温度 26-30℃”）。随后将该结果以特定格式追加到对话上下文中。接着，重复此逻辑，调用旅游工具并获得景点推荐结果。

三、生成最终回答 此时，模型的上下文包含了：

用户的原始需求。
天气查询结果。
景点推荐结果。模型将整合所有这些信息，组织成一段连贯的自然语言回答，例如：

下周末上海预计多云有阵雨，气温在26-30℃之间，出行建议室内与短途户外活动相结合。
您可以考虑第一天参观上海博物馆、漫步南京东路，晚上欣赏外滩夜景；第二天可以选择前往迪士尼乐园或崇明岛亲近自然。

以上便是一个极简版Agent的完整执行过程。

结语

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

这一切在理论上显得非常美好，但在实际生产中，当前的Agent技术往往难以直接满足企业级应用的需求。Agent的真实境遇是怎样的呢？

从技术架构层面分析，Agent高度依赖于意图识别与工具调用之间的完美配合。然而，这套架构存在两个固有缺陷：

第一，执行效率较低 为了确保决策的稳定性和准确性，模型常常需要进行多轮思考、确认或反思，这会消耗大量的Token。意味着成本高昂，因此在处理复杂任务时（例如让Manus制作一个PPT），经常出现Token耗尽而任务未完成的情况。

第二，结果需要试错与确认 并非模型经过缜密思考后，其输出结果就必然可靠可控。事实往往并非如此，这意味着Agent给出的结果好坏，通常需要用户进行二次确认和校验。

从这个角度看，Agent目前更适合人机协同（Human-in-the-loop）的场景，例如AI编程中的结对编程（Pair Programming），这也是为什么Cursor这类编程Agent能够流行起来。另一个推论是，既然Agent适合在反复交互和调教中完成任务，那么它就不太适合需要一次性给出高度稳定、可预期结果的场景。因此，在现阶段的生产级应用中，凡是要求输出稳定性的AI功能，大多不会采用纯粹的Agent模式。

当前生产环境应用更广泛的是AI工作流（Workflow）。它通过预设的标准作业程序（SOP），将任务拆解为明确的步骤，并在每个步骤中注入领域知识（例如调用特定API的规范、数据校验规则），从而有效解决模型输出的不确定性问题，确保结果的一致性和可预期性。以前文的天气工具为例，一个旅行规划Workflow会强制执行为“机票查询→天气检查→景点推荐”三个标准化步骤，每个步骤都严格遵循预定义的业务逻辑和数据源，而非依赖模型的自由发挥。

从商业和实用视角总结：Agent模式更具融资潜力与想象空间，而AI工作流则更擅长解决具体的实际问题。无论是技术团队对前沿技术的好奇心，还是风险投资对颠覆性故事的偏好，都使得许多公司不得不讲述Agent的故事。 AI Agent的故事确实非常吸引人，并且其演示成本可以很低——一个仅包含天气和旅行两个工具的Demo Agent就能制作出令人惊艳的宣传视频，因为它背后暗示着无限的扩展可能性。然而在现实中，客户可能需要的是100%可靠的机票价格查询和精确的天气数据，此时模型的“创造性发挥”反而成为不必要的风险。

综上所述，在接下来的很长一段时间里，我们将在AI的确定性（通过工作流保障） 与创造性（通过Agent激发） 之间进行权衡与选择。两者各有其适用的舞台，理解它们的优劣与边界，对于构建实用的AI应用至关重要。