前几天在跟同行探讨多租户 Agent 平台的架构设计时，发现一个很有意思的现象：很多人在面对 LLM 应用编排时，依然带着传统的框架执念。一上来就试图引入各种厚重的生态，比如完整的 Spring AI 体系或者 LangChain 的各类高级组件（比如 @AiService 和 @Tool）。
然而，当业务场景变成“千级 Agent、动态配置、毫秒级按需装载”的时候，这些在单体应用中大放异彩的框架，往往成了阻碍工程扩展性和系统稳定性的累赘。
如果你最近有去扒一扒 Anthropic 泄露的 Claude Code CLI 源码，或者关注过 Pi 这种极简 Agent，你会发现那些真正顶级的工程团队在 Agent 架构上都在做减法：抛弃臃肿的编排黑盒，拥抱最纯粹的控制流。
本文将以 Java 服务端为背景，记录如何剥离 AI 框架的“语法糖”，仅仅依靠 LangChain4j-Core 的底层原语，手搓一个支持 MCP (Model Context Protocol)、纯数据驱动且能支撑高并发的动态 Agent Loop 引擎。
一、 阶段一：千级 Agent 平台的工程痛点
在构建 SaaS 级的 Agent 平台（或者说一个 Local Token Hub）时，系统通常要承载海量且配置各异的虚拟助手。每次请求，网关都要根据请求头的 agent_id，将特定的系统指令（Skill）、专属工具（Tool）组装好并喂给模型。
如果此时采用高层框架的静态绑定模式，会暴露出几个工程上的致命伤：
- 静态工具绑定与动态调度的错位： 传统框架要求你将工具写死为 Java 类的方法。但在平台场景中，Tool 往往只是存放在数据库里的 OpenAPI 描述或是 JSON Schema。我们需要的是“元数据先行，按需加载”，而不是预编译。
- 资源与 Context 开销： 为几千个 Agent 初始化几千个包含 Memory Provider、Chat Memory、Agent Executor 的重量级常驻对象，服务器的堆内存很快就会被撑爆。
- 黑盒化与控制流丧失： 当你需要深度接入 MCP，或是需要对每次 Tool Call 进行细粒度的 Token 计费、权限沙箱校验时，被框架完全接管的 ReAct Loop 会让你寸步难行。
二、 阶段二：大道至简的 Agent Loop
“An autonomous agent is just an LLM + tools + a loop.”
这句话堪称 Agent 工程化里的一句箴言。剥离掉所有包装，Agent 的执行层本质上就是一个 While 循环。
我们要做的，是在每次 API 请求到达时，执行以下“三位一体”的动态组装，并送入循环：
* Skills (技能)：根据 agent_id 提取 System Prompt（比如从 SKILL.md 中解析），作为上下文基调。
* Tools (本地工具)：将数据库里配置的 API 描述转化为 LLM 能懂的 JSON Schema。
* MCP (模型上下文协议)：连接外部数据源，将其提供的能力动态拉取并合并到工具列表中。
三、 核心实现：基于原语的“微内核”架构
作为一个开发者，我们要实现的是一个“微内核”的调度引擎。这里我们只引入 langchain4j-core 的底层原语，借用它抹平各家大模型 API 差异的能力，但控制流完全由我们自己掌握。
1. 依赖约束
我们不需要庞大的依赖树，只需要核心层即可：
<dependency>
<groupid>dev.langchain4j</groupid>
<artifactid>langchain4j-core</artifactid>
<version>0.35.0</version>
</dependency>
<dependency>
<groupid>dev.langchain4j</groupid>
<artifactid>langchain4j-open-ai</artifactid>
<version>0.35.0</version>
</dependency>
2. 动态 Agent Loop 引擎
以下代码展示了如何实现一个无状态、纯数据驱动的微型引擎：
import dev.langchain4j.data.message.*;
import dev.langchain4j.model.chat.ChatLanguageModel;
import dev.langchain4j.model.openai.OpenAiChatModel;
import dev.langchain4j.agent.tool.ToolSpecification;
import dev.langchain4j.agent.tool.ToolExecutionRequest;
import dev.langchain4j.model.output.Response;
import com.fasterxml.jackson.databind.ObjectMapper;
import java.util.ArrayList;
import java.util.List;
public class DynamicAgentLoopExecutor {
// 全局复用无状态的 LLM Client
private final ChatLanguageModel chatModel;
public DynamicAgentLoopExecutor(String apiKey) {
this.chatModel = OpenAiChatModel.builder()
.apiKey(apiKey)
.modelName("gpt-4o")
.temperature(0.3)
.build();
}
/**
* 核心 Agent Loop (网关每次请求的无状态入口)
*/
public String runAgent(String agentId, String userMessage) throws Exception {
// ==========================================
// 1. 渐进式发现与 Context 构造
// ==========================================
// 从存储加载当前 Agent 的 Skill (System Prompt)
String systemPrompt = loadSystemPromptFromDb(agentId);
// 动态构造 Tool Schema，不依赖任何 @Tool 注解
List<toolspecification> dynamicTools = new ArrayList<>();
dynamicTools.add(ToolSpecification.builder()
.name("get_weather")
.description("获取指定城市的天气")
.addParameter("city", dev.langchain4j.agent.tool.JsonSchemaProperty.STRING)
.build());</toolspecification>
// 假如有 MCP 接入，这里直接调用 MCP Client 获取远端工具列表并 append 进来
// dynamicTools.addAll(mcpClient.listTools());
List<chatmessage> chatHistory = new ArrayList<>();
chatHistory.add(SystemMessage.from(systemPrompt));
chatHistory.add(UserMessage.from(userMessage));</chatmessage>
// ==========================================
// 2. 意图匹配与 ReAct 循环执行
// ==========================================
int maxIterations = 10; // Token Budget 与死循环熔断
while (maxIterations-- > 0) {
// 提交 LLM 推理
Response<aimessage> response = chatModel.generate(chatHistory, dynamicTools);
AiMessage aiMessage = response.content();
chatHistory.add(aiMessage);</aimessage>
// 如果模型未发起 Tool Call，直接完成文本输出
if (!aiMessage.hasToolExecutionRequests()) {
return aiMessage.text();
}
// 拦截到 Tool Call，进入执行侧的分发
for (ToolExecutionRequest toolRequest : aiMessage.toolExecutionRequests()) {
String toolName = toolRequest.name();
String toolArgsJson = toolRequest.arguments();
String toolResult = "";
try {
// 工程分化点：本地沙箱调用 vs 远程 MCP 调用
if (isLocalTool(toolName)) {
toolResult = executeLocalTool(toolName, toolArgsJson);
} else {
// toolResult = mcpClient.callTool(toolName, toolArgsJson);
toolResult = "Mock MCP Result";
}
} catch (Exception e) {
toolResult = "Error: " + e.getMessage();
}
// 将执行结果(Observation)封装追加，进入下一轮迭代
chatHistory.add(ToolExecutionResultMessage.from(
toolRequest.id(), toolName, toolResult
));
}
}
throw new RuntimeException("Agent iteration limit exceeded");
}
// ... 省略 mock 的辅助方法 ...
}
这段百行代码的优势在于：它是绝对无状态（Stateless）的。一千个 Agent 的配置只是存放在数据库里的静态文本，在调用时才进行内存 Context 构造，用完随 GC 销毁，非常契合 Serverless 和高并发网关的诉求。
四、 延伸思考：MCP、Skill 与“嵌入派”的胜利
在研究这段手搓的 Agent Loop 时，很容易让人联想到 Anthropic 推出的 MCP 标准。
对于多租户平台来说，MCP 就是一个面向 LLM 的微服务架构。在上面的代码逻辑中，LLM 其实并不关心 dynamicTools 中的某个工具是在当前宿主机执行的原生代码，还是通过网络请求转发到某台 MCP Server 上的。在引擎的视角，MCP 仅仅是提供了一堆动态的 ToolSpecification。
这再次印证了之前关于“大模型嵌入派”的观点：将 LLM 作为决策中枢（Router），自下而上地将其嵌入到可控的系统架构中。
太阳底下没有新鲜事，以前微服务架构下积累的限流、熔断、调用链追踪经验，在这个微内核 Agent 架构下依然有着极高的借鉴意义。你可以在上面的 While 循环中，轻易地插入 Token Budget 检查、权限拦截（沙箱控制）和分布式日志。
五、 结语
有时候，过于 FOMO（Fear of Missing Out）的心态会让我们在面对技术演进时，盲目去追求一些看似大而全的权威框架，这反而会损失工程决策的质量。
把 LLM 当成 CPU 内核，把 Prompt/Skill 当作指令集，把 Tool 和 MCP 当成系统调用，你会发现，设计一个高可用的 Agent 框架，跟一门编程语言最终要实现如何自举的设计哲学几乎完全一致。
面对千级 Agent 的工程挑战，扔掉那些过度封装的框架，回归到最基础的 Agent Loop。在确定性的架构上去嵌入大模型的能力，不断将其沉淀为系统的稳定模块，这或许才是我们面对这一轮技术浪潮时，最不该焦虑且最踏实的演进路线。
印象中，这已经是这两年以来，自己第4次相对正式的设计和实现特定业务场景下Agent平台了。虽然每次都会有一些不同的业务背景和技术栈，但是问题的本质一直都没有改变。而有显著的改变的是，通过vibe coding,我们可以非常快速的把整个平台扶上线。
上周刚刚发布的GPT-5.6出来以后，很多开发者发出了”是时候把gstack, superpowers卸载了“的感慨。虽然开发者社区总是喜欢短期内高度阶段技术进步的影响，模型的嵌入和折叠外部能力的速度未必如他们口中呼喊的那么快，但从工程角度来看，在这个不断萃取和沉淀的过程中，随着螺旋上升不断调整和适应新的底座和新的能力，才是我们在这个时代最应该关注的事情。
