24 篇博文 含有标签「Agent」

面向资深后端工程师，深入 Agent 架构中的推理与执行分离模式。

从单体 Agent 的困境说起​

假设你构建了一个简单的 ReAct Agent：LLM 在同一个循环中同时完成「思考做什么」和「具体怎么做」。代码往往长这样：

while True:
    thought = llm.generate(f"当前状态：{state}，下一步做什么？")
    action = parse_action(thought)       # 执行工具调用
    result = execute_tool(action)
    state += f"\n执行结果：{result}"

看起来简洁，但部署到生产后会遇到一系列问题：

• 调试困难：一个失败的步骤到底是推理错了还是执行错了？日志里 Thought/Action/Observation 混在一起，难以定位根因。
• 测试困难：你想 mock 工具调用来测试推理逻辑，但推理和执行在一个函数里，只能端到端测试。
• 上下文污染：上一次执行的冗余输出挤占了下一次推理的窗口。
• 无法重放：生产环境出了 bug，你想重放当时的推理链路——但执行结果不可重复（API 超时、数据库状态变了）。

这些问题的根源在于：推理（Reasoning）和执行（Execution）是两种不同的关注点，却被耦合在了同一个循环中。

本文是 Agent 协议系列的第二篇，前篇《Function Calling 诞生的背景》探讨了函数调用能力的起源，本篇聚焦更通用的协议层——MCP。

为什么需要 MCP？​

Function Calling 解决了「LLM 如何调用外部函数」的问题，但它有一个根本性局限：每个模型厂商的函数定义格式不同。OpenAI 有 tools 参数，Anthropic 用 tools 但 schema 略有差异，Google Gemini 用 tools / tool_config，Llama 系列模型需要特定的 prompt 模板。

这意味着你的工具代码需要为每个模型写一个适配层。更麻烦的是，工具本身的注册、发现、安全策略并没有一个统一的标准——每个 Agent 框架都在自己造轮子。

MCP（Model Context Protocol） 就是来解决这个问题的。它由 Anthropic 提出，本质上是一个通用的、模型无关的上下文与工具交互协议，定义了 LLM 应用与外部工具/数据源之间的标准通信方式。

引言​

上一篇我们聊了 Function Calling 诞生的背景——LLM 为什么必须学会调用函数。这篇更进一步，把问题摊开：

一个只会输出文本的模型，如何长出"眼睛"、"手"和"记忆"？

• 联网搜索给它眼睛，让它看到训练数据截止之后的世界；
• 文件读写给它手，让它能在真实工作环境中留下成果；
• 记忆功能让它跨越会话，记住你是谁、上次做到哪一步。

这三项能力，加上代码执行和 MCP 协议的标准化，构成了今天所有 AI Agent 的地基。本文逐项拆解它们的原理、实现路径和工程上的坑。

本文是对腾讯云开发者社区文章《一文讲透如何构建 Harness——六大组件全解析》（作者：李伟山）的阅读总结与深度解读。原文详细拆解了 AI Agent 工程中最重要的概念之一——Harness，本文在保留核心观点的同时做了结构化的梳理。