自构建智能体：一项 LangChain4j 实验

InfoQ 中文 2026-07-31T17:44:35.211789

我们让代码助手仅凭 LangChain4j 的官方文档，自行设计并实现了一个多智能体编码系统。实验表明，该框架的 API 足够清晰，使 AI 能够“克隆”自己的核心能力；同时，对生成系统的测试也暴露了工具调用上限、模型选择等实际问题。本文记录了完整过程与最终成果。

实验背景：让 AI 构建一个“自己”

我们进行了一项元实验：把 LangChain4j 的文档交给一个代码助手，让它参照文档构建一个智能体系统——具体来说，是设计一个多智能体系统，使其能够像人类工程师或代码助手那样编写、测试和调试代码。

大语言模型（LLM）仅凭文档就能“构建出自己”，这件事本身从两个角度印证了 LangChain4j 的优势：第一，它的 API 足够清晰直观，模型可以无障碍地直接使用；第二，框架提供了充分的协调能力，使生成出来的系统能在真实的调试任务中端到端地跑通。

此外，这个项目也给了我们一个机会，对 LangChain4j 新加入的监控工具做一次压力测试——毕竟，让一个 AI 构建另一个 AI，确实需要时刻盯着它的内部运作。本文会详细介绍实验过程，以及最终生成的项目（代码已发布在这个代码库中）。

通过“氛围编码”让 AI 设计智能体

为了让代码助手参照自己构建一个智能编码器，我们编写了这样一段提示：

通过文档和源代码研究 LangChain4j 智能体框架的 API 和功能，并在此基础上设计一个智能编码器，使其成为你自己的克隆体。

经过几分钟的推理，代码助手认定 LangChain4j 的“监督者模式”最适合这个任务，并给出了一个初步架构。随后，它又设计并实现了 4 个由监督代理调用的子代理，以及相应的系统与用户消息。这些子代理各自负责一类操作：分析现有代码、制定执行计划、按计划实施修改，最后通过编译和运行让代码真正生效。代码助手还为每个代理配备了必要的工具：给“资源管理器”代理提供文件系统访问能力，给“实现者”代理提供代码编辑器，给“执行者”代理提供运行代码的途径。

第一次迭代的成果相当亮眼。如果你用过代码助手，你会发现这基本上就是现实中“专业”助手的工作模式：它们通常执行的操作，与我们实验中 4 个代理模拟的四类动作几乎一致；后续再以监督者的角色协调这些操作来完成任务，也和我们的实现思路如出一辙。

编程助手能够自主设计并实现这样一套系统，说明它至少在高层次上理解了自身的运作机制，并且有能力把这种理解转化为具体的智能体系统设计。

把智能编码器投入实际测试

为了验证这个智能编码器是否真的能干活，我们让它先写了一段包含错误的代码，再用新系统去修复。代码助手生成下面这个 Calculator 类，里面有 4 个存在轻微错误的方法：

public class Calculator {
    public int add(int a, int b) { return a + b; }          // 正确
    public int subtract(int a, int b) { return a - b; }     // 正确
    public int multiply(int a, int b) { return a * b; }     // 正确
    public int divide(int a, int b) { return a / b; }       // 未处理除零
    public int modulo(int a, int b) { return a % b; }       // 未处理除零
}

接着，它又生成了一项测试。测试会把包含 Calculator 类的文件夹克隆到临时目录，然后对这份副本运行 LangChain4j 智能编码器：

// 伪代码示意：克隆文件夹 → 调用 AI 编码生成器修复

现在真正跑一次，看看这个基于常见 LLM 的实现是否靠谱。我们为监督器和编码智能体都配置了 OpenAI 的 gpt-4o——选它的原因是 OpenAI API 是 LangChain4j 默认的 base URL，而 gpt-4o 是默认模型，同时它也支持工具调用。

可惜结果不太理想。运行几分钟后，我们收到了一个错误提示：

Tool call loop exceeded max allowed rounds (100)

显然，大语言模型陷入了工具调用循环，当调用次数超过默认上限 100 后，LangChain4j 中断了整个过程。虽然可以通过 AiServices.maxToolCallingRoundTrips() 调整这个限制，但默认值本身是合理的——一个智能体在同一任务里需要调用工具超过 100 次，这本来就不正常。

幸运的是，我们之前用较旧或不太先进的模型时也遇到过类似问题，所以经验很明确：换一个更现代的模型试试。于是我们改用 gpt-5-mini，重新跑了一遍同样的测试。

几分钟后，系统输出了成功结果——所有错误都被修复，所有测试都通过了。它还把临时目录中的代码正确修改为了修复后的版本。

为了更清楚地了解监督者智能体的执行流程，我们还用上了监控功能。LangChain4j agentic 框架在 1.12.2-beta22 版本中引入了让根智能体接口继承 MonitoredAgent 的能力，借此可以监控智能编码器的运行情况。

通过这个接口，我们打印出一份包含智能体调用记录和系统拓扑结构的报告，如图 1 所示。从图中可以很直观地看到智能编码器的实际工作方式：

图 1：基于监督者架构的系统拓扑与执行跟踪截图（由 LangChain4j 可观测性 UI 生成，图片由作者提供）

从监督者到工作流

监督者模式的价值在于自主性，但这种自由也伴随着隐性的成本开销。为了探索能否让系统更高效、更可预测，我们要求代码助手换一种思路，采用基于工作流的方式对智能编码器进行重新设计：

在保留基于监督者的实现的同时，添加第二个实现，使其具备类似的行为，但这次采用更确定性的方式，仅使用 LangChain4j 智能体框架提供的流程模式。具体而言，生成一系列待执行的操作，尽可能复用现有的智能体，并在必要时添加审查循环。

关键要点

本文通过实验对比了两种基于 LangChain4j 的智能体架构：工作流模式与监督者模式，展示了它们在代码生成与调试场景中的速度与自主性权衡。

更确定的架构：五步工作流

这次，我设计了一个更具确定性的架构——一个包含五个步骤的严格序列。前四个步骤与之前的智能体类似，第五个步骤则引入了一个专用的 SummarizerAgent，接管了此前由监督器隐式处理的摘要生成职责。

值得注意的是，规划和执行这两个步骤并不是单个智能体，而是采用循环结构实现。这种设计使得它们能够进行多次迭代，在继续推进之前不断调整和优化工作。

以执行循环为例，它由三个子智能体组成：执行器、评估器和重构智能体。这三个智能体会循环调用，直到评估分数达到足够高的水平，或者达到最大迭代次数为止。在本次实验中，我将“足够好”的分数设定为 80% 的准确率——这是一个较为常见且切合实际的阈值。迭代次数上限设为 5 次，防止在准确率始终无法达标的情况下，产生过多的模型调用和令牌消耗。

测试结果：更快，但拓扑更复杂

对这一替代实现运行与之前相同的测试，结果非常相似。智能编码器修复了所有错误，并通过了所有测试，但这次的执行轨迹呈现出更复杂的拓扑结构——涉及更多的智能体和连线。

图 2：基于工作流的架构的系统拓扑和执行跟踪截图，由 LangChain4j 可观测性 UI 生成（图片由作者提供）

尽管这次涉及的智能体数量更多，但与基于监督器的实现相比，完整调试会话的运行速度反而快了三倍：仅需两分钟，而前者需要六分钟以上。

节省的时间主要来自消除了监督器智能体本身的开销。在监督者模式中，为了协调各类智能体，主智能体必须自主生成所有其他智能体的调用及其相应参数，这一过程产生了大量额外的计算成本。

小结

在本文中，我们探讨了如何利用 LangChain4j 智能体框架，以“氛围编程”的方式构建一个智能代码生成器，让大语言模型（LLM）自行设计并实现整个系统。LangChain4j 的 API 在此过程中表现出两个关键特性：其一，易于使用——LLM 能够自主设计和实现一个复杂的智能编码器；其二，功能强大——足以让代码助手在系统中克隆自身的内部工作机制，从而创造出一种“元智能体编码器”。

我们还观察了该系统在实际调试会话中的运行情况，实时监控其执行过程并可视化其拓扑结构。结果显示：系统利用结构清晰的智能体拓扑，修复了所有错误并通过了全部测试。

最后，通过对比基于工作流的智能体实现与更自主的基于监督器的实现，本次实验清晰地展示了速度与自主性之间的权衡关系。

如何选择：两种模式各有适用场景

当效率、速度和可预测性至关重要时，应选择工作流模式。 工作流模式是一种更严格的方法，执行速度比监督者模式快约三倍。这种效率源于消除了由大语言模型带来的协调开销，转而依赖确定性架构和严格的步骤序列。它非常适合那些可以预先分解为阶段并确定顺序的任务，通常会集成内置的循环结构来实现迭代优化。

当自主性和动态灵活性优先于执行速度时，应选择监督者模式。 监督者模式拥有更强的自主性，允许主智能体在运行时自主生成智能体调用及其相应参数，从而协调所有其他智能体。然而，这种自由伴随着隐性的成本开销，导致运行速度显著下降。

关键要点

查看原文