跬步 On Coding

我理解的AI Agent与MCP

Apr 2 2025

前言

最近AI圈子里Manus这个项目可以说是相当火了，连带着MCP（Model Context Protocol）这个概念也开始频繁出现在各种技术讨论区。作为一个程序员，自然也对这些新东西充满了好奇，于是花时间捣鼓了一下AI Agent和MCP相关的知识。这篇文章就是我学习和思考后，对这两个概念的一些个人理解和梳理。

1. 从Workflow到AI Agent：大脑的进化

回顾我们以前做自动化任务，比如搞个自动抢票、自动下单之类的，思路基本都是围绕着一个固定的workflow。我们会预先设定好一套流程逻辑：收到指令 -> 判断条件 -> 走对应分支 -> 调用特定工具（API、脚本等）。整个过程就像一个流程图，每个节点和路径都是我们程序员预先设计好的。在这个模式下，我们程序员就是这个workflow的“大脑”，我们把执行计划通过代码逻辑，“硬编码”到系统里。比如预定机票这个场景，我们会写代码一步步调用查询接口、选择航班接口、填写乘机人信息接口、支付接口等等。

2. LLM登场：有了“大脑”，但还缺“手脚”

随着大语言模型（LLM）技术的突飞猛进，特别是像DeepSeek R1这样强大的推理模型出现，它们的推理和规划能力越来越接近人类大脑。这就让我们自然而然地想到：能不能让LLM来充当这个自动化流程的“大脑”，代替我们来制定执行计划呢？

想法很美好，但LLM本质上还是一个文本补全的模型。它能“思考”并告诉你计划是什么，但它自己并不能直接撸起袖子去调用那些具体的工具（API、函数等）来完成任务。为了解决这个问题，OpenAI在其API中引入了tools（或称为 Function Calling）的概念。

这个流程大致是这样的：

  1. 我们的应用程序（可以称为Agent）调用LLM API时，在请求的上下文中详细描述可用的工具：每个工具是干嘛的、输入需要什么参数、输出是什么格式。
  2. Agent把用户的自然语言指令（Prompt）发给LLM。
  3. LLM根据用户的需求，结合它所知道的工具信息，判断是否需要以及需要调用哪个（或哪些）工具。
  4. 如果需要调用工具，LLM不会直接执行，而是返回一个包含调用指令的响应，里面说明了要调用哪个工具以及需要传递的参数（通常是JSON格式）。
  5. Agent收到这个响应后，解析出调用指令，在Agent自己的环境里执行相应的工具（比如调用一个本地函数或一个外部API）。
  6. Agent拿到工具的执行结果后，把这个结果再次作为上下文信息，传回给LLM。
  7. LLM根据工具的执行结果，决定下一步是继续调用其他工具，还是生成最终的回复给用户。

这个基于tools的交互模式，让LLM有了指挥“手脚”（工具）的能力。但这里也暴露了一个比较明显的弊端：完成一个任务可能需要多次与LLM进行交互（LLM决策 -> Agent执行 -> Agent反馈结果 -> LLM再决策…），并且为了让LLM理解上下文，每次交互都需要传递越来越长的历史信息，这既增加了延迟，也增加了API调用成本和Token消耗。

3. CodeAct：让LLM直接写代码执行

我们知道，当前LLM最强的能力之一就是代码生成。于是，就有人想出了另一种更直接的思路：既然LLM擅长写代码，而我们提供的工具本身很多就是函数或者可以通过代码调用的API，那何不让LLM直接生成一小段可执行的代码（比如Python），然后在我们的Agent里内置一个安全的代码执行沙箱来运行这段代码呢？

在这段生成的代码里，LLM可以直接包含对我们提供的工具（函数）的调用，甚至可以编写一些简单的流程控制逻辑（if/else、循环等）。这样一来，多个步骤和工具调用可能通过一次LLM生成、一次代码执行就完成了，大大减少了与LLM的交互次数。这种方法就被称为CodeAct（代码作为行动）。

4. 到底什么是AI Agent？

聊了这么多，我们再来尝试给AI Agent下一个定义。我认为，AI Agent = LLM（大脑） + Tools（手脚） + Agent Runtime（执行器） + 决策循环。

具体来说，AI Agent通过调用LLM API，并结合一系列可用的工具（Tools），来理解并执行用户的自然语言任务。它通常采用一种决策-执行-观察的循环模式（ReAct）：

  1. 决策（Reason）：由LLM根据当前任务目标和上下文信息，决定下一步是调用工具还是直接回复。
  2. 执行（Act）：由Agent Runtime根据LLM的决策，执行相应的工具调用或代码片段。
  3. 观察（Observe）：Agent Runtime将执行结果反馈给LLM，作为新的上下文信息，供LLM进行下一轮决策。

这个循环一直持续，直到任务完成。

但这里有个关键问题：LLM本身具有一定的不确定性。对于相同的输入（Prompt），它每次返回的结果可能都不完全一样。这就给AI Agent的执行带来了挑战，有时候可能会偏离预期或者卡在某个环节。因此，在开发AI Agent时，接入Tracing（追踪）系统变得非常重要。我们需要能够实时跟踪Agent与LLM的每一次交互、上下文内容、工具调用情况以及执行结果，这样才能在出现问题时快速定位和调试，进而优化我们的Prompt或者Agent逻辑。

5. 多Agent协作：专业的事交给专业的Agent

随着Manus的流行，多Agent编排（Multi-Agent Orchestration）的理念也开始受到关注。核心思路是化整为零，分工协作。

我们不再试图构建一个“万能”的超级Agent，而是将复杂的任务拆解，构建多个功能单一、职责明确的专家Agent。比如，我们可以把web_search和web_fetch这两个工具组合起来，封装成一个专门负责网页抓取的web_scraper_agent。这种单一功能的Agent，它的大脑（LLM）可能不需要最顶级的推理能力，我们可以选用一个性能足够且成本更低的模型（比如一些中小型模型或者特定领域的微调模型）。

当我们有了多个这样的专家Agent后，再引入一个Planner Agent（规划器Agent）。这个Planner Agent通常需要一个推理能力较强的LLM作为大脑，它的职责是：

  1. 接收用户的原始任务。
  2. 将任务拆解成若干子步骤。
  3. 根据每个子步骤的需求，选择并调用合适的专家Agent。
  4. 收集专家Agent的执行结果。
  5. 根据执行结果，动态调整后续的计划（可能需要重新规划或调用其他Agent）。
  6. 循环这个过程，直到最终任务完成，然后将结果汇总返回给用户。

这种多Agent架构带来的好处显而易见：

  • 成本效益：在大量执行具体任务的专家Agent上可以使用更便宜的LLM。
  • 维护性：每个Agent功能单一，更容易开发、测试和维护。
  • 扩展性：可以方便地增加新的专家Agent来扩展整个系统的能力。
  • 可能更优化的上下文管理：Planner Agent可能只需要关注子任务的目标和专家Agent返回的关键结果，而不需要承载所有底层工具调用的详细上下文。

6. Prompt工程：Agent的灵魂

无论是使用ReAct还是CodeAct，无论是单Agent架构还是多Agent编排，有一个环节始终是绕不开的，那就是Prompt Engineering（提示工程）。

我们需要为每一个与LLM交互的环节（无论是Planner Agent制定计划，还是专家Agent执行任务，或是Function Calling/CodeAct的触发）精心设计Prompt。好的Prompt需要能够引导LLM按照我们的预期来思考和输出：

  • 让Planner Agent生成结构化、可分步执行的计划。
  • 让LLM在需要时准确地选择并调用我们提供的工具。
  • 让LLM返回格式规范、易于解析的文本（比如JSON），方便Agent Runtime处理。

可以说，Prompt就是我们给AI Agent注入灵魂的方式。

7. MCP：Agent间沟通的标准语

随着多Agent架构的兴起，Agent之间如何发现彼此、如何调用彼此的能力就成了一个问题。这时，MCP（Model Context Protocol）这个概念应运而生。

你可以把MCP理解为一套为Agent（或者说LLM的工具）设计的标准化接口规范。

在没有MCP之前，我们实现的工具可能五花八门：一段本地Python代码、一个内部HTTP API调用、一个第三方云服务接口等等。每次要给Agent添加新工具，都需要手动编写关于这个工具的描述（功能、参数、格式），然后注入到Agent的上下文中。

有了MCP之后，情况就可能变得更规范：

  • 工具提供方可以将其能力封装成一个遵循MCP协议的MCP Server。
  • Agent可以通过标准的MCP方法（比如list_tools）来动态发现某个MCP Server提供了哪些工具及其描述。
  • Agent可以通过标准的MCP RPC Call来执行这些工具。

MCP不仅仅规范了工具的调用，它通常也试图规范Prompt模板、资源管理等Agent开发中常见的元素。如果MCP能够被广泛采用，理论上可以：

  • 降低Agent的开发门槛：开发者可以直接复用社区提供的、遵循MCP标准的工具服务，而不需要自己重复实现和描述工具。
  • 提高Agent的互操作性：不同开发者、不同团队开发的Agent或许能更容易地进行协作。

当然，MCP目前似乎还在发展初期，但它指明了一个让Agent生态更加规范化、标准化的方向。

8. 总结：门槛不高，精通不易

以上就是我这段时间学习下来，对AI Agent和MCP的一些粗浅理解。在阅读了几个开源的Manus实现（或者类似的多Agent框架）之后，我的一个直观感受是：

对于掌握Python的程序员来说，上手开发一个基础的AI Agent，或者编写一个简单的Tool/MCP Server，技术门槛似乎并不算特别高。很多框架（如LangChain、LlamaIndex等）已经帮我们处理了与LLM交互、管理上下文、执行工具等繁琐的底层工作。

然而，真正的挑战在于：如何在一个特定的业务场景下，设计和实现一个稳定、可靠、高效的AI Agent。这需要：

  • 深刻理解业务需求，并将其转化为适合Agent执行的任务流程。
  • 精心的Prompt设计与调优，不断尝试，引导LLM给出期望的输出。
  • 有效的Tracing和Debugging，快速定位Agent执行过程中的问题并进行修复。
  • 合理的架构选择（单Agent vs 多Agent，ReAct vs CodeAct）和成本控制。

就像当年我们从写简单脚本到构建复杂系统一样，AI Agent的世界也是易学难精。工具和框架降低了入门门槛，但要做出真正好用的Agent，还需要大量的实践、思考和打磨。

9. 参考