这一篇开始编写真实的 Python MCP Server。 示例会同时提供 Tool、Resource 和 Prompt，并分别使用三种方式验证： stdio：客户端启动 Server 子进程。 Streamable HTTP：网络服务的

从本文开始进入 MCP 系列，讨论如何把工具、资源和提示词变成可以被不同语言、进程和 Agent 客户端复用的标准能力。 MCP 解决的是能力标准化和跨应用复用问题。服务端按照统一协议公开工具、资源和提示词，支持 MCP 的客户端就能发现并

AgentState负责描述一次 Agent 运行中有哪些状态，以及节点和 Tool 应该如何读取、更新这些状态。 但是，只有 State 还不等于拥有记忆。如果没有配置持久化组件，一次 invoke() 结束后，下一次调用不会自动恢复上一

Context 适合保存用户 ID、用户名和权限等调用开始时已经确定的数据，在一次运行中通常按只读方式使用。 但是 Agent 运行起来以后，还会不断产生新的内容。例如用户消息、模型生成的工具调用、工具执行结果，以及工具从外部系统得到的数据

前文已经完成本地 Tool、流式工具调用和 Agent API 的介绍。调用 Agent 时，我们一直把用户问题放在 messages 中，但实际应用除了问题本身，通常还需要知道是谁发起了请求。 例如，一个用户询问“告诉我当前用户的年龄”，

上一篇已经介绍了 Tool 的几种定义方式，并使用 bind_tools() 手动完成了一次工具调用循环。非流式调用比较容易理解：模型一次返回完整的 AIMessage，应用从 tool_calls 中读取工具名称和参数，再执行对应函数。

前面创建天气 Agent 时，模型能够判断什么时候查询天气，并把城市名称交给 get_weather()。这个过程看起来像是模型执行了 Python 函数，实际并不是这样。 大模型只负责理解问题、选择工具并生成参数。真正查找工具、调用 Py

上一篇已经使用 langgraph dev 启动天气 Agent，并在 Studio 中看到了模型调用工具的完整过程。但 Studio 主要用于开发和调试，真正开发 Web 页面、后端服务或命令行工具时，程序还需要通过 API 调用 Age