在上一篇 LangChain 核心组件之 Agent 有介绍到模型。模型其实是一个很粗泛的概念，放到任何领域都有立身之地， 比如各种建模，经济增长模型，Covid 感染模型等。但来到 AI 时代，会不会只要有人一开口说模型便默认为大语言模型(LLM)呢？而如今的 LLM 模型又基本就是 Transformer 模型，所谓的模型开源只是开放了一堆的 Token 的权重值，不同源软件开源，拿过来能随意定制使用。

大语言模型更像是人类知识的压缩包，可用它生成多种形式的内容，比如文本、图像、音频等。模型在生成内容的过程中，还支持下面几种形式的交互

1. 工具调用：可以引导模型通知 Agent 调用工具，如计算，互联网搜索，API 调用等
2. 结构化输出：模型本身就支持按照约定的规则格式化输出内容
3. 多模态：不仅能生成文本，还能生成图像、音视频等
4. 推理：模型可以进行推理，如数学计算、逻辑推理等，就是经常看到的 Thinking 的过程

最初在 Llama3 刚发布的年代，在使用 MCP 时还要查哪个模型支不支持工具使用，现在基本上以上特性是模型的标配了。现在几大商业模型就是 OpenAI 的 GPT， Anthropic 的 Claude，Google 的 Gemini, Musk 的 Grok 在下一梯队。国外的模型选择很清晰，反而中国的大语言模型众多， 仿佛不出个自己的大语言模型就像个互联网公司。

经过了一番 LangChain 的学习之后，我们开始跟随 LangChain 的官方文档系统性的学习。首先是它的核心组件，包括 Agents, Models, Messages, Tools, Short-term memory, Streaming, 和 Structured output. 现在从 Agents 开始。

创建 Agent

create_agent 是可用于正式产品中创建 Agent 的函数， 它返回的是一个 langgraph.graph.state.CompiledStateGraph 对象，而非一个 XxxAgent 样的东西。所以它创建的是一个状态图，图吗，就有顶点和边，Agent 就是这个图中移动，比如在 Model 和 Tools 之间往复, 或在中间加入的互动的(Human-in-the-loop).

LangGraph 把与模型，工具，以及人的交互做成一个图还是很表意的，下面是来源于官方文档的表示 Agent 的状态图。

Java 24 也是一个过渡版本, 还是到下面两个链接中找相应的更新

1. JDK 24 Release Notes - Major New Functionality
2. OpenJDK JDK 24 Features

IntelliJ IDEA 对 Java 24 Language level 描述是

1. 24 - No new language features
2. 24 (Preview) - Flexible constructor bodies, simple source files, etc.

把上面第二个链接中的特性列出来

Java 24 中列出的特性恰如其版本一样，有 24 条，因其是一个过渡版本，多数为非正式特性，也就为什么 IntelliJ IDEA 从语言特性上把 Java 标记为 No new language features. 其实也不然，个人觉得有两个正式特性值得关注，即 Class-File API 和 Stream Gathers。

所谓大语言模型的记忆功能，就是要在说当前这句话的时候让 LLM 知道整个对话的上下文。比如说与人对话

1. A: 给我讲个笑话
2. B: 有一天，有人问你：“你喜欢什么？”, 你回答：“我喜欢一切……只要不叫‘考试’。” 😄 够快，够短，有没有让你会心一笑？
3. A: 再来一个
4. B: 问：海里面最怕什么？ 答：脱水。

#3 当 A 问 "再来一个" 时候，B 因为有基于前面对话的上下文，所以能理解 "再来一个" 来一个笑话，而不是一个妞什么的，也记得曾经讲过一个笑话，而不 至于重复之前的笑话。如果突然有一天 A 对 B 突兀的说 "再来一个"，B 就会有些傻眼了，AI 在没有上下文的情况也是一样。

不过人与人之间对话的上下文是互相的，两方的共同记忆，双方都是建立在你知道我问了什么，你自己回复了什么的基础之上的。而于大语言模型的对话时， 大语言模型是没有记忆的，就好像和一个失忆的人对话一样，记忆责任全在一方，你和 LLM 每一次对话时都要不停的唠叨：

我曾经问了这个，你回复过那个，问过这个，你回复过那个......，我现在问一个问题，请基于我们的会话历史作出回答

和机器对话就是这么傻傻的，当对话历史过大的时候因为上下文大小限制的原因，就必须压缩总结之前的对话内容，压缩后总会失真，这就是为什么大语言模型会 不断降智的一个原因。

前段时间 OpenClaw 确实很火，尤其是在中国，它在 2025 年 11 月上线后，最初名字是 Clawbot, 中间更名为 Molbot, 最后定名为 OpenClaw. 我在它 真正火热当中并没有产生多大兴趣去跟风，只最近一个月想看看它到底是个什么东西。弄了个虚拟机装上后，就是可以连接各个大模型， 打通与国外流行的即时通讯 软件，能自动化的就是它的 Cron Jobs.

界面上功能不少，最后发现真正有用的就是那个 Cron Jobs, 比如自己设置了一个每日两次的定时任务，实现的是从监控一个猫收容网上的列表，当发现有新的猫 就发送到指定的 Telegram Bot 上，描述很简单，但 Agent 确实很聪明，不用告诉它细节，它自己知道怎么本地文件来辅助判断是否为新猫。聪明的另一个原因是 OpenClaw 蹭了我 $20 Claude 会员的光。但到 4 月 4 日，Claude 订阅会员不让绑定到 OpenClaw 之后，试用了 Google 免费的 API Key 不怎么理想。

也不想再多折腾，如果只是要一个 Cron Job 的话可以自己用 LangChain 实现一个。听说 OpenClaw 十分耗 Token, 于是对它的提示词有点好奇。 本文将查看一下一个新鲜的 OpenClaw 的提示词长什么样子。

于是又新装了一个 OpenClaw v2026.4.9 版本，使用本地的 Ollama 模型，由于未能成功设置 OpenClaw 使用代理来访问 Ollama API， 于是在 Ollama service 前端放了一个反向代理，该反向代理也是临时用 Vibe Coding 搓出来的。让 OpenClaw 使用通过反向代理 http://localhost:9091 来访问实际的 Ollama http://localhost:11434, 并在反向代理中记录下对 Ollama API 完整的请求与响应数据，使用什么模型都无所谓。

上一篇 LangChain 1.2 入门学习 中使用了特定的 ChatOllama/ChatGoogleGenerativeAI, 或统一的 init_chat_model 方式创建一个与 LLM 的交互程序，并以此基础实现了一个简单的 AI Agent, 工具调用是根据响应中消息格式手工调用的， 会话处理是自己拼接全部对话历史。现在知名的 LLM 都支持推理，所以顺代也用灰色字体显示了 'thinking' 的文本内容。

本文直接学习官方 Quickstart 中的一个 AI Agent, 该 Agent 实现了以下功能

1. 有了上下文，会记忆会话历史
2. 支持调用多个工具
3. 提供结构化一致性的响应数据格式
4. 能通过上下文处理用户特定的信息
5. 跨交互维护会话状态

AI 界日新月异，新名词层出不穷，像 Prompt Engineering, Context Engineering, 到如今又来了 Harness Engineering. 现在最怕两个人出来搞事情， Dario Amodei 和 Andrej Karpathy, 前者宣称 AI 可替代一切，人变得一文不值，后者专造名词。在大语言模型时代，搞机器学习了，专注模型的不用多少人， 多数人还能在 AI 上蹭热点的话就剩下 AI Agent 的这个赛道了，其余就是应用了，例如 Vibe Coding，或更贴近具体业务的应用。

像各大 AI 编程工具，如 Codex, Claude Code, OpenCode, GitHub Copilot， Gemini, Cursor, Antigravity, Trae 本质上都是在比拼各家 AI Agent 的能力。最近火的那个 OpenClaw 也是一个学习 AI Agent 的好范例。

而 AI Agent 方面的框架首当其冲就是 LangChain, 它提供了 Python 和 TypeScript 两种语言的支持，网上有人做了个 langchain4j, 这种跟随项目恐怕也坚持不了多久。其他 AI Agent 框架有 [Pydantic AI]， 微软的 AutoGen, Crew AI, AWS Strands Agents. 各大语言模型 OpenAI, Anthropic, Gemini 都有自己的 SDK, 但要开发一个 Multi Agent 的系统更需要一个第三方的 AI Agent 框架来整合各家模型的能力，提供统一的接口和工具，这个框架就是 LangChain.

上一篇 使用 Spring 的 gRPC 服务 学习了如何用 Java SpringBoot 4 + Spring gRPC 实现服务端与客户端， 并且用 Postman 和 grpcurl 命令测试了如何访问 Java 实现的 gRPC 服务，其中还用 Wireshark 抓包工具进一步验证了 gRPC 的通信方式是 Protobuf Over HTTP/2。

完后又突然对 C++ 实现一个 gRPC 服务产生了兴趣，因为现实项目是想要把 C++ 动态库的调用代码独立为一个进程，这时候直接用 C++ 代码调用 C++ 动态库 就是最简单直接的方式，不存在任何数据结构的转换。把这部分实现为一个 C++ 的 gRPC 服务，然后由 Java 的 gRPC 客户端来调用。

下面来看这样一个简单的例子，在 C++ 只实现一个只包含一个同步的 gRPC 的服务，测试将用 grpcurl 命令和 Postman，并且也用 Wireshark 抓包工具验证 gRPC 的通信方式是否依然是 HTTP/2, Protobuf 数据编码肯定没得说了。

人们在跨语言, 跨进程通信方面采用过不少的方案, 交换文件, CORBA, SOAP, 最后得到最广泛应用的是 RESTful API, 交换格式通常用文本格式的 JSON 和 XML. 但作为更高效的通信还是二进制格式, 在 Java 方面, 有过 Java 内置的 RMI, Spring 的 Hessian, Dubbo. 而发展到今天 gRPC 受到了更多的关注, gRPC 的通信协议是 HTTP/2, 编码格式是 Google 高效的 Protobuf.

gRPC 是由 Google 发起的一个远程调用框架, 是 gRPC Remote Procedure Calls 的缩写, 各处的解释是 g 最初是代表 Google, 现在只是像 YAML Ain't Markup Language 类似的命名, 说 g 不再代表 Google, 怎么听起来有点 既要又要的感觉, 怎么都会认为 gRPC 为 Google 的 RPC.

总之, gRPC 是一个高性能的开源统一的 RPC 框架, 能叫做统一是因为它支持多种语方, 如 Go, C++, Java, Python, Node, C#, PHP 等, 多语言支持是 由 Protobuf 格式决定的, 总之它是 Protobuf over HTTP/2, 实现上是用 Protobuf 定义数据结构与服务方法, 再映射成不同语言的代码实现. gRPC 已然成为了 RPC 的标准, 真正意识到它的不一般是在 Postman 中发现了它, 可见其在业界受不到了应用的重视.

Java 22 正式引入了 Foreign Function & Memory API, 简称 FFM API, 它源自于 Project Panama, 旨在用来替代 JNI, 提供更安全，健壮的本地动态库调用方式。之前在一文 Java 22 新特性学习 中跳过了对它的体验， 因为直接用 FFM API 来调用本地代码的话，写起来比 JNI 还更复杂，更别提和 JNA 对比，性能上 FFM API 大致与 JNI 相当，但总比 JNA 要好些， 原因是 JNA 使用了一个与系统相关的中间层动态库。像这种调用本地代码的场景，性能的差异基本体现在本地代码上，调用过程的性能差异一般可以忽略不计.

那时没深入 FFM API 的原因是它用起来过于复杂，这种复杂性应该由第三方库来屏蔽，可是自 Java 22 于 2024-03-19 发布以来目前仍未找到一款类似于 JNA 屏蔽了 JNI 那样的基于 FFM 的第三方库。所以还是事先来体验一下 FFM API 的开发过程，现在可以借助 AI 来引导学习, 并在后面与 JNA 作个性能对比， 只供参考。