46 · 设计考量（Design Considerations）

Embabel 的设计目标，是让你能够决定 LLM 自主性与代码控制之间的恰当平衡。本节讨论可用于达成这一平衡的设计考量。

领域对象（Domain objects）

丰富的领域模型有助于构建好的智能体系统。领域对象不应只承载状态，还应暴露行为 —— 避免贫血领域模型（anemic domain model）。

领域对象有多重角色：

保证类型安全与可工具化（toolability）：代码可以访问它们的状态；提示词是强类型的；LLM 知道该返回什么。
向代码暴露行为：像任何设计良好的面向对象系统一样，供代码调用。
向 LLM 暴露工具：让 LLM 可以调用领域对象。

第三个角色在 LLM 与 Embabel 的语境中是新颖的。

设计领域对象时，要考虑哪些方法应该能被 LLM 调用、哪些不应该。想让 LLM 能调用的方法，用 @Tool 注解暴露：

java

@Tool(description = "Build the project using the given command in the root") // ①
public String build(String command) {
    BuildResult br = ci.buildAndParse(new BuildOptions(command, true));
    return br.relevantOutput();
}

① Spring AI 的 @Tool 注解表示该方法可被 LLM 调用。

当 @Action 方法发出提示词时，所有领域对象上的 tool 方法都对 LLM 可用。你也可以通过 PromptRunner 上的 withToolObjects 方法追加额外的 tool 方法。

领域对象可以是持久化的，也可以不是。若需持久化，通常会用 JVM 世界里的熟悉技术，例如 JPA 或 JDBC。我们推荐使用 Spring Data 模式与 repository，当然你也可以自由选择任何持久化技术。

工具调用的选择（Tool Call Choice）

何时在 Agent 中使用 MCP 或其它工具，何时用方法调用 —— （原文此节尚无正文）

混合使用 LLM（Mixing LLMs）

在一个智能体系统中使用多个 LLM 是好做法，Embabel 让这件事很容易。

把功能拆成更小的动作，其中一个关键好处就是：你可以针对不同动作使用不同的 LLM，依据各自的强项与弱项来分配；也可以为某个任务使用**最便宜（最绿色）**的 LLM。

46 · 设计考量（Design Considerations）

领域对象（Domain objects）

工具调用的选择（Tool Call Choice）

混合使用 LLM（Mixing LLMs）

友情链接