llm+agent，使用与 OpenAI 兼容的 API 格式

文章目录LLM Agent 是什么信息流LLM 本身是无状态的处理器和Agent 的“记忆“怎么理解网页版的 ChatGPT 或 Claude 本身就是一个封装好的 Agent 系统。如果真的“只有 LLM”会怎样agent 记忆agent短期记忆和长期记忆agent记忆存在哪里举例假设你有一个包含 100 个文件的项目你想让 AI 帮你改一个登录 BugAgent 是如何被写出来的。记忆自动拼接上下文什么时候查询数据库什么时候调用”LLM什么时候不在调用llm?MCPModel Context Protocol模型上下文协议MCP 的核心架构mcp客户端mcp服务器资源MCP 实际上是一种基于 JSON-RPC 的通信JSON-RPC 是什么API 和 JSON-RPC 是什么JSON-RPC 数据包的**“运输方式”**stdin/stdout 或 HTTPSSE (Server-Sent Events) 是一种“单向常连”技术。它允许服务器在建立连接后像源源不断的流水一样主动把数据推送到客户端Agent而不需要客户端反复询问sse与普通http区别流式Streaming是数据传输方式SSE 是实现流式的一种技术判断是否是MCP 客户端 (如支持mcp的Agent)判定一个服务器是否为 MCP 服务器的“三个标准”MCP 服务器的作用MCP 是 Agent 和外部工具之间的桥梁/调度中心。如果工具在 MCP 上直接调用函数。如果工具在外部服务通过 HTTP / gRPC / RPC 调用为什么 MCP 可以统一调用工具agent怎么知道有哪些工具llm怎么知道有哪些工具agent调用工具怎么知道要输入哪些内容哪些参数例子Agent 怎么知道发给哪个 LLM 给agent配置哪个llm就用哪个Agent 发送请求到llm,需要 配置LLM 的哪些参数举例messages 列表 Prompt只是格式化成多条消息。system role 设定模型身份/行为规则。user role 用户输入/任务。assistant role 也是 Promptmessages的一部分模型自身的角色主要用于记录 LLM 自己之前的输出让模型理解上下文、保持连贯性怎么实现工具才能让agent调用tool/list 返回的内容是 Schema 还是工具列表以及谁生成 SchemAPIApplication Programming Interface应用程序接口API 的核心就是提供一套调用规则让程序可以互相“说话”,互相调用不管它们是在同一台电脑上还是分布在不同的电脑、甚至不同城市的服务器上。程序之间沟通的接口和规则本地调用Local API / 同一台机器IPCInter-Process Communication进程间通信(1) 管道Pipe / Named Pipe一条只能本地用的单向通信通道就像把两个程序用一条水管连起来stdio 是程序的默认 I/O 接口管道是操作系统提供的通信通道它可以把一个程序的 stdio 接到另一个程序的 stdio 上从而实现数据传递(2) 共享内存Shared Memory消息队列Message Queue套接字Socket / Unix Socket就是 程序之间开通的一条“电话线”通过它发送和接收数据网络通信 vs 本地通信远程调用Remote APIAPI 是怎么实现的实现 API本质是定义一套“规则和通道”告诉其他程序如何访问你的功能。API 技术栈就是3层模型API设计(接口长什么样)-通信协议-数据格式api 设计接口长什么样。 REST、GraphQL、RPC是 三种 API 思想每种 API 思想对应的实现技术/框架API 的第一层接口定义Interface需要什么参数返回什么数据等第二层通信协议数据怎么在网络上传输第三层数据格式数据怎么表示协议Protocol是什么规定了两台计算机或程序之间如何通信、交换信息。怎么传输三种 API 思想实现的api的调用方式API 交互标准OpenAI 定义了一套如何与大模型对话的接口规范如 /v1/chat/completionsmessages 里的角色有哪些systemuserassistantFunction Call 的本质role: function可选 → 标识这是工具调用结果什么是 SDK Software Development Kit开发工具包什么叫 “兼容 OpenAI API”使用与 OpenAI 兼容的 API 格式什么意思OpenAI API标准Model模型参数“调用 API 不一定要写 URL”URL 只是使用 HTTP REST 思想定义的api的调用方式为什么“写了 URL 就是调用 API”。属于http rest思想设计api后的调用方式为什么 OpenAI SDK 换 URL 就调用别的 APIhttp rest形式调用api时换url就是换api了。还可以使用openai sdk是因为别人的api的参数和返回结果与openai一样OpenAI 在 2023 年之后给 AI 应用开发定义了一套“事实标准de-facto standard”OpenAI 推动的“工具调用Tool Calling / Function Calling接口标准”Function Calling / Tool Calling 标准JSON Schema 作为工具参数标准SDK Software Development Kit软件开发工具包Chat Message 协议OpenAI 还定义了 对话消息结构标准后来 Anthropic 提出了 Model Context Protocol (MCP)。把 OpenAI Function Calling 的思想扩展成跨工具协议OpenAI后来又加了一条标准模型输出必须符合指定 JSON Schema现在 AI 行业的架构是什么样目前 AI 行业形成了 两套标准体系Agent框架典型功能工具调用记忆任务规划等Agent 框架里的 任务规划Planning和任务拆分Task Decomposition核心其实不是复杂算法而是 让 LLM 先当“规划器”再当“执行器”任务拆分实现方式Prompt-based Planning最常见任务拆分实现方式ReAct最经典 Agent 方法。Thought → Action → ObservationAgent 框架里的真实代码结构任务拆分方式Plan-and-Execute更稳定LLM Agent 是什么“LLM Agent”其实是目前 AI 领域很火的组合它把 大语言模型LLM, Large Language Model 和 助手/智能体Agent 的能力结合起来让模型不仅“会说”还“会做”信息流LLM 本身是无状态的处理器和Agent 的“记忆“怎么理解网页版的 ChatGPT 或 Claude 本身就是一个封装好的 Agent 系统。如果真的“只有 LLM”会怎样agent 记忆agent短期记忆和长期记忆# 1. 接收到用户的新问题 user_input 我去年在上海买的那把雨伞是什么颜色的 # 2. 调取【短期记忆】看看刚才咱们聊了啥 short_term_context memory_cache.get_recent_chat(limit5) # 结果发现刚才在聊今天的天气没提到雨伞。 # 3. 触发【长期记忆】检索因为短期记忆里找不到“雨伞” # 开发者逻辑如果短期没结果就去翻“向量数据库”这个大档案柜 long_term_record vector_db.search(query上海 雨伞 颜色, top_k1) # 结果发现2025年的一条记录显示“在上海买了一把【蓝色】折叠伞”。 # 4. 【主动管理】开发者设计的“拼装逻辑” # Agent 把搜到的档案、刚才的话、和你的新问题拼在一起 final_prompt f 你是 AI 助手。 已知背景长期记忆{long_term_record} 最近对话短期记忆{short_term_context} 用户的新问题{user_input} 请根据以上信息回答。 # 5. 最后把这个“大包”发给 LLM天才厨师 response LLM.generate(final_prompt) # 6. 【存入逻辑】开发者决定这句话值不值得记一辈子 if 记住 in user_input or 偏好 in user_input: vector_db.save(user_input) # 存进档案柜agent记忆存在哪里举例假设你有一个包含 100 个文件的项目你想让 AI 帮你改一个登录 BugAgent 是如何被写出来的。记忆自动拼接上下文什么时候查询数据库什么时候调用”LLM什么时候不在调用llm?记忆拼接历史上下文什么时候查询什么时候调用llm什么时候不在调用llmMCPModel Context Protocol模型上下文协议MCP 的核心架构mcp客户端mcp服务器资源MCP 实际上是一种基于 JSON-RPC 的通信JSON-RPC 是什么API 和 JSON-RPC 是什么JSON-RPC 数据包的**“运输方式”**stdin/stdout 或 HTTPSSE (Server-Sent Events) 是一种“单向常连”技术。它允许服务器在建立连接后像源源不断的流水一样主动把数据推送到客户端Agent而不需要客户端反复询问sse与普通http区别流式Streaming是数据传输方式SSE 是实现流式的一种技术判断是否是MCP 客户端 (如支持mcp的Agent)判定一个服务器是否为 MCP 服务器的“三个标准”MCP 服务器的作用MCP 是 Agent 和外部工具之间的桥梁/调度中心。如果工具在 MCP 上直接调用函数。如果工具在外部服务通过 HTTP / gRPC / RPC 调用为什么 MCP 可以统一调用工具统一注册所有工具在 MCP 上注册包含名字、接口类型、参数格式统一调度agent根据function_call按照json_rpc格式发送到mcp服务器mcp服务器自动路由到对应工具统一返回把工具执行结果按照json_rpc的格式返回agentagent解析后把工具执行结果封装成 rolefunction 消息返回 LLM安全与权限控制MCP 可以限制哪些工具可调用api/json-prcagent怎么知道有哪些工具llm怎么知道有哪些工具agent调用工具怎么知道要输入哪些内容哪些参数Agent 是通过工具的参数 schema LLM 语义理解自动推断并填充工具参数的-------------------- | User | ------------------- | v ------------------- | Agent Controller | ← 负责循环控制、判断是否继续执行 ------------------- | ---------------- | Planner / Task | ← 负责拆解复杂任务、生成子任务 ---------------- | --------v-------- | LLM | ← **实际决策者** | (Reasoning) | - 决定下一步做什么 | | - 选择调用哪个工具 | | - 填充工具参数 ---------------- | ---------v--------- | Tool Executor | ← Agent执行层负责调用工具 ------------------ | ---------v--------- | Tools | ← 外部能力API / DB / Python / File System ------------------ | ---------v--------- | Observation | ← 工具返回结果回传给 LLM ------------------ | ---------v--------- | Memory | ← Agent状态管理 | (short/long-term) | 记录上下文、中间结果 ------------------- | --------------------- 循环回 LLM例子{ name: get_weather, description: Get weather information for a city, parameters: { type: object, properties: { city: { type: string, description: city name }, unit: { type: string, enum: [celsius, fahrenheit] } }, required: [city] } }Agent 怎么知道发给哪个 LLM 给agent配置哪个llm就用哪个Agent 发送请求到llm,需要 配置LLM 的哪些参数一般来说Agent 通过 API 调用 LLM需要提供 三个核心参数参数作用Provider / Base URL就是模型运行在哪个服务器的地址它通常指 LLM 提供商的 API 接口地址告诉 Agent 要把请求发送到哪台服务器让 LLM 收到任务API Key / Access Token身份验证用来让 Agent 授权访问 LLM 类似客户端要验证有资格访问服务器Model ID告诉服务器用哪个模型来处理请求比如gpt-5.2、claude-instant-1可选参数max_tokens、temperature、top_p 等生成控制参数Provider / Base URLAPI Key / Access TokenModel ID举例messages 列表 Prompt只是格式化成多条消息。system role 设定模型身份/行为规则。user role 用户输入/任务。assistant role 也是 Promptmessages的一部分模型自身的角色主要用于记录 LLM 自己之前的输出让模型理解上下文、保持连贯性怎么实现工具才能让agent调用def mcp_executor(tool_call: dict) - dict: tool_name tool_call[tool_name] params tool_call.get(parameters, {}) # 找到对应工具 tool next(t for t in mcp_tools if t[name] tool_name) # 执行函数 try: result tool[func](**params) return { tool_name: tool_name, status: success, result: result } except Exception as e: return { tool_name: tool_name, status: error, result: str(e) }tool/list 返回的内容是 Schema 还是工具列表以及谁生成 SchemAPIApplication Programming Interface应用程序接口API 的核心就是提供一套调用规则让程序可以互相“说话”,互相调用不管它们是在同一台电脑上还是分布在不同的电脑、甚至不同城市的服务器上。程序之间沟通的接口和规则广义理解任何一种程序可以调用另一个程序功能的方式本地调用Local API / 同一台机器同一台电脑上的不同程序本质上就像远程调用IPCInter-Process Communication进程间通信(1) 管道Pipe / Named Pipe一条只能本地用的单向通信通道就像把两个程序用一条水管连起来stdio 是程序的默认 I/O 接口管道是操作系统提供的通信通道它可以把一个程序的 stdio 接到另一个程序的 stdio 上从而实现数据传递(2) 共享内存Shared Memory消息队列Message Queue套接字Socket / Unix Socket就是 程序之间开通的一条“电话线”通过它发送和接收数据网络通信 vs 本地通信远程调用Remote APIAPI 是怎么实现的实现 API本质是定义一套“规则和通道”告诉其他程序如何访问你的功能。API 技术栈就是3层模型API设计(接口长什么样)-通信协议-数据格式api 设计接口长什么样。 REST、GraphQL、RPC是 三种 API 思想REST、GraphQL、RPC是 三种 API 思想。规定 API 应该“怎么组织和表达功能”但不规定具体技术细节每种 API 思想对应的实现技术/框架API 思想实现技术 / 框架示例特点RESTDjango REST FrameworkPython、Flask-RESTfulPython、Spring BootJava、Express.jsNode.js用框架定义资源和操作接口快速生成 REST APIGraphQLApollo ServerJavaScript、GraphenePython、Hasura自动生成 GraphQL API、AbsintheElixir提供 GraphQL 查询解析和执行能力实现客户端指定字段的数据请求RPCgRPCGoogle、ThriftApache、JSON-RPC、XML-RPC提供远程函数调用接口实现跨语言的服务调用API 的第一层接口定义Interface需要什么参数返回什么数据等第二层通信协议数据怎么在网络上传输第三层数据格式数据怎么表示API 思想实现技术 / 框架通信协议数据格式RESTDjango REST Framework、Flask-RESTful、Spring Boot、Express.jsHTTP / HTTPSJSON / XML / YAMLGraphQLApollo Server、Graphene、Hasura、AbsintheHTTP / HTTPSPOST 请求、WebSocket订阅、 SSEJSONRPCgRPC、Thrift、JSON-RPC、XML-RPCgRPC → HTTP/2Thrift → TCP/HTTPJSON-RPC / XML-RPC → HTTP/HTTPSUnix Socket / 管道ProtobufgRPC、自定义二进制Thrift、JSON / XML协议Protocol是什么规定了两台计算机或程序之间如何通信、交换信息。怎么传输通信协议按传输方式分为非流失传输和流失传输分类协议示例特点非流式 / 请求-响应HTTP / HTTPS、JSON-RPC / XML-RPC客户端发请求服务器返回响应通信一次结束流式 / 持久连接WebSocket、SSE、gRPC流模式建立连接后可以持续传输数据多次收发协议通信方向持久连接用途特点WebSocket双向客户端 ↔ 服务器是连接建立后一直保持聊天、游戏、实时通知客户端和服务器都可以随时发送消息建立连接后数据传输开销小SSE单向服务器 → 客户端是服务器可以持续推送实时通知、新闻更新客户端只能接收服务器推送不能直接发数据基于 HTTP三种 API 思想实现的api的调用方式API 思想API 长什么样调用方式示例核心特点REST资源 URLGET /users/123操作资源GraphQL查询语句query { user(id:123){name} }查询数据结构RPC函数调用getUser(123)调用远程函数API 交互标准OpenAI 定义了一套如何与大模型对话的接口规范如 /v1/chat/completionsOpenAI 定义了一种“程序怎么调用大模型”的 API 写法后来几乎所有模型公司都照着做了。所以它被称为 事实标准de facto standard。messages 里的角色有哪些systemuserassistantFunction Call 的本质{role: assistant, content: 我需要查天气。, function_call: {name: get_weather, arguments: { \city\: \Beijing\ }}},role: function可选 → 标识这是工具调用结果工具调用的结果在 OpenAI 的 Chat API 里会以 role “function” 的消息形式返回给模型模型再根据这个内容生成回答。工具调用的结果不是直接文本而是 rolefunction 的消息传回给模型模型再把它整理成用户可读的回答。什么是 SDK Software Development Kit开发工具包什么叫 “兼容 OpenAI API”使用与 OpenAI 兼容的 API 格式什么意思OpenAI API标准Model模型参数“调用 API 不一定要写 URL”URL 只是使用 HTTP REST 思想定义的api的调用方式为什么“写了 URL 就是调用 API”。属于http rest思想设计api后的调用方式为什么 OpenAI SDK 换 URL 就调用别的 APIhttp rest形式调用api时换url就是换api了。还可以使用openai sdk是因为别人的api的参数和返回结果与openai一样OpenAI 在 2023 年之后给 AI 应用开发定义了一套“事实标准de-facto standard”OpenAI 推动的“工具调用Tool Calling / Function Calling接口标准”Function Calling / Tool Calling 标准JSON Schema 作为工具参数标准JSON Schema 在工程里的三个典型用途。很多人第一次看到会懵因为它其实是在说 Schema 一种机器可读的接口说明书SDK Software Development Kit软件开发工具包Chat Message 协议OpenAI 还定义了 对话消息结构标准后来 Anthropic 提出了 Model Context Protocol (MCP)。把 OpenAI Function Calling 的思想扩展成跨工具协议OpenAI后来又加了一条标准模型输出必须符合指定 JSON Schema现在 AI 行业的架构是什么样AI应用层 (ChatGPT / AI产品 / AI SaaS) ↓ Agent框架层 (LangChain / LlamaIndex / CrewAI / AutoGPT) ↓ Agent协议层 (OpenAI Tool Calling / JSON Schema) ↓ 模型层 (OpenAI / Anthropic / Google / Meta) ↓ 算力层 (Nvidia GPU / 云计算)目前 AI 行业形成了 两套标准体系Agent框架典型功能工具调用记忆任务规划等Agent 框架里的 任务规划Planning和任务拆分Task Decomposition核心其实不是复杂算法而是 让 LLM 先当“规划器”再当“执行器”任务拆分实现方式Prompt-based Planning最常见任务拆分实现方式ReAct最经典 Agent 方法。Thought → Action → Observation在 Thought → Action → ObservationReAct 模式 里Thought LLM 内部生成的意图 / 下一步计划Action 调用工具rolefunctionObservation 工具执行结果返回模型rolefunctionObservation 就是把 Action 执行后的结果返回给 LLM让 LLM“看到”这个结果再继续推理。Agent 框架里的真实代码结构任务拆分方式Plan-and-Execute更稳定