企业官网建设流程全解析

这次我们来看一个很有意思的实践主题：用三种不同语言实现同一个 LLM Agent。

标题直译过来就是“用三种方式建模一个 LLM Agent：Python、Clojure、Elixir”。这不是让你在三个语言里各写一遍 Chat Completion 调用，而是用一套相同的 Agent 任务，分别按照 Python、Clojure、Elixir 各自惯用的方式建模一次。重点不是“能不能跑通”，而是语言本身的编程范式会怎么影响 Agent 的代码结构。

如果你已经用 Python 写过 Agent，但没试过函数式语言和 BEAM 生态；或者你正在纠结“团队里要不要引入多语言”“Clojure/Elixir 这类语言适不适合做 LLM 应用”，这篇文章可以直接收藏。

文章会先给出三条路线的核心能力对比，再给出三套最小可运行项目骨架，然后用同一个“多步工具调用 Agent”作为案例，分别写出 Python、Clojure、Elixir 的实现思路。接着补充接口接入、批量并发、资源占用观察和常见排错清单。整体偏工程视角，适合已经对 LLM API 有基本认知的开发者。

1. 三条语言路线核心能力速览

先给一张速览表，把同一主题下的三条实现路线拉出来对比。后面所有代码和思路都围绕这张表展开。

实际选型时要注意一点：LLM Agent 的瓶颈通常在“模型推理延迟”和“工具调用链路”，不在语言本身。三者的差距更多体现在工程长期维护、并发编程的简洁度、状态管理的可控性上，而不是“谁跑得更快”这种一刀切结论。

从材料来看，这个主题并不限定某个 GitHub 仓库或某套成熟 Agent 框架，而是一类“同题异构”的建模实验。因此文章后面给出的是通用实现思路和可调整的代码骨架，而不是某个框架的官方教程。你拿到代码后，需要根据实际使用的 LLM 服务地址、模型名称、工具列表做替换。

2. 这个主题适合谁，Agent 建模的通用边界

先说适合的人群。

如果你已经有 Python 的 LLM Agent 开发经验，想了解 Clojure 或 Elixir 怎么处理“工具调用循环”“会话状态”“并发批量任务”，这个主题非常合适。它会逼你重新思考一件事：Agent 的本质不是“调用一次大模型”，而是反复调用模型、解析模型返回的工具调用意图、执行工具并把结果回填给模型的循环过程。这个循环在 Python 里通常写成一个 while 或 for 循环；在 Clojure 里更自然的是递归；在 Elixir 里则可能拆成进程间的消息流。

如果你还在纠结“该不该用 Python 以外语言做 Agent”，这个主题也能帮你降低试错成本。你不需要在三种语言里各做一整套完整产品，只需要跑通一个最小 Agent，就能感受到结构差异。

边界问题也需要单独说清楚，尤其是合规与安全方面：

• Agent 如果有权限读文件、执行命令、调外部 API，必须确认这些操作在你的授权边界内。不要在一个无鉴权的公网服务上暴露任意工具执行入口。
• 外部工具返回的数据如果包含用户隐私、业务敏感信息，需要做脱敏和审计，不要无条件追加进模型上下文。
• 涉及版权内容、他人肖像、语音等素材时，必须先确认授权。即使只是做技术验证，也要注意测试素材来源。
• 任何接口服务的 API Key 都不要写进前端代码、公开仓库或日志里，建议使用环境变量或密钥管理服务。

这些不是套话。Agent 的能力边界越强，越需要在架构上同时约束“能做什么”和“允许谁触发”。

3. 环境准备与前置条件

如果你打算三套都跑起来，建议先检查本机基础环境。下面按语言拆分，给出我建议的最小准备清单。

3.1 Python 环境

Python 端建议使用 3.10 及以上版本，因为新版 openai SDK 和 asyncio 用法都比较依赖较新的 Python 特性。

需要准备：

• Python 3.10+，虚拟环境工具 venv 或 uv。
• 一个 openai / anthropic 兼容 SDK，或者直接用 requests/httpx 调 HTTP 接口。
• 如果本地没有 GPU 跑模型，可以先用 Ollama 这类本地推理服务暴露 OpenAI 兼容接口；如果接云端模型，则需要配置 API Key。

3.2 Clojure 环境

Clojure 跑在 JVM 上，所以先装 JDK。建议 JDK 17 或 21，LTS 版本问题少。

需要准备：

• JDK 17+，命令行里java -version能正常输出。
• Clojure CLI，也就是clj命令。这是官方推荐的依赖与项目启动方式。
• 依赖工具用deps.edn，不需要 Leiningen 也能跑通一个小项目。

Clojure 端没有特别成熟的 LLM Agent 框架，通常是自己组合clj-http和cheshire处理 HTTP 与 JSON。这不复杂，但对 HTTP 响应解析的熟练度有一定要求。

3.3 Elixir 环境

Elixir 跑在 Erlang VM 上，安装时通常会把 Erlang 一起带上。

需要准备：

• Elixir 1.14 以上版本，安装完成后elixir --version能看到版本。
• Mix 是 Elixir 自带的构建工具，不需要额外安装。
• HTTP 客户端推荐Req，JSON 解析推荐Jason，这两个库在 Mix 里声明依赖即可。

Elixir 的进程模型对新手来说是最需要适应的地方。最开始不要直接上 GenServer，先把普通函数模块写完、跑通接口，再拆成进程模型。

3.4 统一的 LLM 服务地址

无论是三种语言中的哪一种，调用大模型时都建议先统一成一个“OpenAI 兼容 HTTP 接口”。

例如本地使用 Ollama 时，服务默认监听http://127.0.0.1:11434，Chat Completions 的地址是：

POST http://127.0.0.1:11434/v1/chat/completions

如果使用云端服务，也是一样的接口形态，只是把 base_url 和 api_key 换成你自己的配置。

推荐准备一个.env或环境变量配置文件，至少包含：

LLM_BASE_URL=http://127.0.0.1:11434/v1 LLM_API_KEY=local LLM_MODEL=qwen2.5 LLM_TIMEOUT=120

这样的好处是，Python、Clojure、Elixir 三套代码读取同一组配置，对比时才不会被 API Key、模型名差异干扰。

4. 最小项目骨架与启动方式

先不用写 Agent 逻辑，先把三个语言的最小项目建好，保证能调用一次 LLM 接口。

4.1 Python 最小项目

Python 项目结构可以非常精简：

py-agent/ ├── .env ├── requirements.txt └── app.py

requirements.txt 示例：

openai>=1.30.0 python-dotenv>=1.0.0

app.py 里只需要一个最基础的 Chat Completion 调用：

import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client = OpenAI( base_url=os.getenv("LLM_BASE_URL"), api_key=os.getenv("LLM_API_KEY", "local"), ) response = client.chat.completions.create( model=os.getenv("LLM_MODEL", "qwen2.5"), messages=[ {"role": "system", "content": "你是一个测试助手。"}, {"role": "user", "content": "请用一句话介绍自己。"}, ], ) print(response.choices[0].message.content)

启动方式：

cd py-agent python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python app.py

如果 Ollama 服务在运行，并且本地拉取了对应模型，控制台会输出模型返回的文本。这一步能通，后续 Agent 工具循环才有基础。

4.2 Clojure 最小项目

Clojure 项目用 deps.edn 管理依赖：

{:paths ["src"] :deps {org.clojure/clojure {:mvn/version "1.11.1"} clj-http/clj-http {:mvn/version "3.12.3"} cheshire/cheshire {:mvn/version "5.12.0"}}}

在src/agent_lab/core.clj里写一个最小调用：

(ns agent-lab.core (:require [clj-http.client :as http] [cheshire.core :as json])) (def config {:base-url (or (System/getenv "LLM_BASE_URL") "http://127.0.0.1:11434/v1") :api-key (or (System/getenv "LLM_API_KEY") "local") :model (or (System/getenv "LLM_MODEL") "qwen2.5")}) (defn call-llm [messages] (let [resp (http/post (str (:base-url config) "/chat/completions") {:headers {"Authorization" (str "Bearer " (:api-key config))} :content-type :json :body (json/generate-string {:model (:model config) :messages messages})})] (-> resp :body (json/parse-string true)))) (defn -main [& _] (let [result (call-llm [{:role "system" :content "你是一个测试助手。"} {:role "user" :content "请用一句话介绍自己。"}])] (println (get-in result [:choices 0 :message :content]))))

启动方式：

cd clj-agent clj -M -m agent-lab.core

Clojure 第一次启动会比较慢，因为 JVM 和依赖加载都需要时间，这是正常现象。看到控制台输出模型回复，说明链路通了。

4.3 Elixir 最小项目

使用 Mix 创建项目：

mix new elixir_agent cd elixir_agent

在mix.exs里添加依赖：

defp deps do [ {:req, "~> 0.5"}, {:jason, "~> 1.4"}, {:dotenv, "~> 3.1", only: :dev} ] end

安装依赖并写一个最小调用脚本：

defmodule AgentLab.Basic do def call_llm(messages) do base_url = System.get_env("LLM_BASE_URL", "http://127.0.0.1:11434/v1") api_key = System.get_env("LLM_API_KEY", "local") model = System.get_env("LLM_MODEL", "qwen2.5") Req.post!("#{base_url}/chat/completions", json: %{ model: model, messages: messages }, headers: [authorization: "Bearer #{api_key}"] ).body end end messages = [ %{role: "system", content: "你是一个测试助手。"}, %{role: "user", content: "请用一句话介绍自己。"} ] AgentLab.Basic.call_llm(messages) |> get_in(["choices", Access.at(0), "message", "content"]) |> IO.puts()

启动方式：

cd elixir_agent mix deps.get mix run script/basic.exs

这里把调用逻辑写在脚本文件里，可以快速验证链路。后面要长期跑服务时，再把逻辑放进 Application 和 GenServer。

5. 同一个 LLM Agent，三种语言的建模差异

环境跑通后，进入这个主题最核心的部分：同一个 Agent，怎么在三门语言里建模。

5.1 先定义“同一个 Agent”

为了避免三套代码越写越偏，需要先定一个明确的 Agent 任务。以下所有实现都以“带天气查询工具的多步问答 Agent”为例：

• 用户提问“北京今天适合出门吗”。
• 模型判断需要查询天气，并调用weather_query(city)工具。
• 程序执行工具，返回天气结果。
• 模型根据真实天气数据生成最终回答。

这个任务足够简单，但包含 Agent 最关键的两个要素：模型自主决定调用工具和工具结果回填后的多轮生成。

5.2 Python 建模：对象 + 循环

Python 最自然的建模方式是“一个 Agent 类 + 一个工具列表 + 一个循环”。

import json from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:11434/v1", api_key="local", ) TOOLS = [ { "type": "function", "function": { "name": "weather_query", "description": "查询城市当前天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名，例如北京"} }, "required": ["city"], }, }, } ] def weather_query(city: str) -> str: # 实际项目中替换为真实天气 API，这里只作为示意 return f"{city} 当前天气：多云，26℃" class SimpleAgent: def __init__(self, model: str = "qwen2.5"): self.model = model self.messages = [ {"role": "system", "content": "你是天气助手，需要时查询真实天气。"} ] def ask(self, user_text: str, max_steps: int = 5) -> str: self.messages.append({"role": "user", "content": user_text}) for _ in range(max_steps): resp = client.chat.completions.create( model=self.model, messages=self.messages, tools=TOOLS, ) msg = resp.choices[0].message # 没有工具调用意图，说明可以直接返回最终答案 if not msg.tool_calls: self.messages.append({"role": "assistant", "content": msg.content}) return msg.content or "" # 把 assistant 的工具调用消息放入上下文 self.messages.append(msg.model_dump()) # 逐个执行工具并回填 for tool_call in msg.tool_calls: if tool_call.function.name == "weather_query": args = json.loads(tool_call.function.arguments) tool_result = weather_query(args["city"]) self.messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": tool_result, }) return "达到最大步骤数，提前结束。" if __name__ == "__main__": agent = SimpleAgent() print(agent.ask("北京今天适合出门吗？"))

Python 写法的特点是直白。Agent 的状态就是self.messages，工具的注册方式就是一个普通 list，工具循环就是一个for循环内部嵌套if判断。

这种写法的问题也很典型：当工具数量变多，每个工具都要在 for 循环里加一个if判断分支，代码会快速膨胀。更好的办法是引入“工具名称到函数”的字典映射，或者用装饰器注册工具，但核心循环结构不变。

5.3 Clojure 建模：递归 + 不可变状态

Clojure 里不建议把 Agent 做成“一个带内部状态的对象”。更符合语言习惯的做法是把 Agent 建模为一条数据处理管道，消息列表作为不可变值在递归中传递。

先定义工具：

(ns agent-lab.tools) (def tools [{:type "function" :function {:name "weather_query" :description "查询城市当前天气" :parameters {:type "object" :properties {:city {:type "string" :description "城市名，例如北京"}} :required ["city"]}}}]) (defn weather-query [city] ;; 实际项目中替换为真实天气 API (str city " 当前天气：多云，26℃"))

再写 Agent 循环。Clojure 没有 while 也没有 Python 那种 mutable 的 messages 列表，所以要用loop/recur或普通递归，每一轮把新的消息 list 传给下一轮：

(ns agent-lab.core (:require [agent-lab.tools :refer [tools weather-query]] [clj-http.client :as http] [cheshire.core :as json])) (def config {:base-url (or (System/getenv "LLM_BASE_URL") "http://127.0.0.1:11434/v1") :api-key (or (System/getenv "LLM_API_KEY") "local") :model (or (System/getenv "LLM_MODEL") "qwen2.5")}) (defn call-llm [messages] (let [resp (http/post (str (:base-url config) "/chat/completions") {:headers {"Authorization" (str "Bearer " (:api-key config))} :content-type :json :body (json/generate-string {:model (:model config) :messages messages :tools tools})})] (-> resp :body (json/parse-string true)))) (defn run-tool [tool-call] (let [fn-name (get-in tool-call ["function" "name"]) args (json/parse-string (get-in tool-call ["function" "arguments"]) true)] (case fn-name "weather_query" (weather-query (:city args)) "暂不支持的工具"))) (defn agent-loop ([messages] (agent-loop messages 5)) ([messages max-steps] (loop [msgs messages step 0] (if (>= step max-steps) {:ok "达到最大步骤数，提前结束。"} (let [result (call-llm msgs) choice (first (:choices result)) msg (:message choice) tool-calls (:tool_calls msg)] (if (seq tool-calls) (let [assistant-msg (select-keys msg ["role" "content" "tool_calls"]) tool-results (map (fn [tc] {:role "tool" :tool_call_id (:id tc) :content (run-tool tc)}) tool-calls)] (recur (into msgs [assistant-msg] tool-results) (inc step))) {:answer (:content msg)})))))) (defn -main [& _] (let [messages [{:role "system" :content "你是天气助手，需要时查询真实天气。"} {:role "user" :content "北京今天适合出门吗？"}]] (println (:answer (agent-loop messages)))))

Clojure 与 Python 最关键的区别在于：

• 没有“对象内部状态”，消息上下文是显式传入函数的参数。
• Agent 循环不是命令式循环，而是递归，每一轮执行都返回一个新消息列表，不修改任何旧数据。
• 工具分支用case分发，后续加新工具只需要增加一个更通用的注册表。

如果你习惯用atom管理会话状态，Clojure 也支持，但在这个主题的实验里，更值得体验的是“无状态函数 + 递归”的写法。它在单元测试时非常方便：任意中间状态都可以直接构造出来测试，不需要 mock 一个 Agent 实例。

5.4 Elixir 建模：GenServer 进程 + Behavior

Elixir 的建模方式跟前两种差别最大。它不倾向于“一个 Agent 类”或“一条递归管道”，而是把每个会话建模为一个独立进程，用进程来隔离状态和并发。

先定义工具的 Behavior，这样新增工具时不需要改动 Agent 主循环：

defmodule AgentLab.Tool do @callback name() :: String.t() @callback run(args :: map()) :: {:ok, String.t()} | {:error, String.t()} end

实现天气工具：

defmodule AgentLab.Tools.Weather do @behaviour AgentLab.Tool @impl true def name(), do: "weather_query" @impl true def run(%{"city" => city}) do # 实际项目中替换为真实天气 API {:ok, "#{city} 当前天气：多云，26℃"} end end

再写一个 GenServer 保存会话消息：

defmodule AgentLab.Server do use GenServer alias AgentLab.Tools.Weather def start_link(init_args) do GenServer.start_link(__MODULE__, init_args, name: __MODULE__) end @impl true def init(_opts) do {:ok, %{messages: []}} end @impl true def handle_call({:ask, user_text}, _from, state) do messages = state.messages ++ [%{role: "system", content: "你是天气助手，需要时查询真实天气。"}] ++ [%{role: "user", content: user_text}] case run_agent_loop(messages, 5) do {:ok, answer, final_messages} -> {:reply, {:ok, answer}, %{state | messages: final_messages}} {:error, reason} -> {:reply, {:error, reason}, state} end end defp run_agent_loop(messages, max_steps) do case call_llm(messages) do {:ok, %{"choices" => [%{"message" => msg} | _]}} -> cond do Map.has_key?(msg, "tool_calls") -> updated_messages = messages ++ [msg] tool_messages = execute_tools(msg["tool_calls"]) run_agent_loop(updated_messages ++ tool_messages, max_steps - 1) max_steps <= 0 -> {:ok, "达到最大步骤数，提前结束。", messages} true -> answer = msg["content"] {:ok, answer, messages ++ [msg]} end {:error, reason} -> {:error, reason} end end defp call_llm(messages) do base_url = System.get_env("LLM_BASE_URL", "http://127.0.0.1:11434/v1") api_key = System.get_env("LLM_API_KEY", "local") model = System.get_env("LLM_MODEL", "qwen2.5") Req.post("#{base_url}/chat/completions", json: %{ model: model, messages: messages, tools: tool_schemas() }, headers: [authorization: "Bearer #{api_key}"] ) end defp tool_schemas do [ %{ "type" => "function", "function" => %{ "name" => "weather_query", "description" => "查询城市当前天气", "parameters" => %{ "type" => "object", "properties" => %{ "city" => %{"type" => "string", "description" => "城市名，例如北京"} }, "required" => ["city"] } } } ] end defp execute_tools(tool_calls) do Enum.map(tool_calls, fn tool_call -> args = tool_call["function"]["arguments"] |> Jason.decode!() case Weather.run(args) do {:ok, content} -> %{ "role" => "tool", "tool_call_id" => tool_call["id"], "content" => content } {:error, reason} -> %{ "role" => "tool", "tool_call_id" => tool_call["id"], "content" => "工具调用失败：#{reason}" } end end) end end

这段代码逻辑比 Python 和 Clojure 版本长，但结构更清晰：Agent 主循环递归调用模型、工具模块通过 Behavior 统一约束、会话状态放在 GenServer 内部。真实项目里，你把Weather换成任何其他工具，只需要新增一个@behaviour AgentLab.Tool的模块，主循环不需要大幅改动。

一个很实际的好处是：如果你的 Agent 要服务多个用户，每个用户启动一个独立 GenServer 进程，天然隔离了会话上下文，某个用户会话卡死不会影响其他人。这是 Python 里需要额外注意并发安全，Elixir 里却很自然的地方。

6. 接口 API 接入、批量任务与并发控制

Agent 跑通单个问题后，下一步通常是批量任务或并发服务。三种语言处理方式差异很大。

6.1 Python 的批量并发

Python 里做批量 LLM 任务最常用 asyncio。受限于 GIL，CPU 密集任务未必能提速，但 Agent 场景的瓶颈在于等待 HTTP 响应，asyncio 非常合适。

使用asyncio.Semaphore控制并发量，避免一次性打爆本地模型或云端 API 限流：

import asyncio import httpx async def ask_one(client, text, semaphore): async with semaphore: resp = await client.post( "http://127.0.0.1:11434/v1/chat/completions", json={ "model": "qwen2.5", "messages": [{"role": "user", "content": text}], }, timeout=120, ) return resp.json()["choices"][0]["message"]["content"] async def main(): texts = ["问题1", "问题2", "问题3", "问题4"] semaphore = asyncio.Semaphore(2) async with httpx.AsyncClient() as client: tasks = [ask_one(client, text, semaphore) for text in texts] results = await asyncio.gather(*tasks) print(results) if __name__ == "__main__": asyncio.run(main())

如果 Agent 内部每个问题需要多步工具循环，建议把 Agent 的ask()方法改成 async 版本，然后同样用 Semaphore 控制并发。

6.2 Clojure 的批量并发

Clojure 最简单的并发方式是使用future。但直接给每个任务开 future 很容易瞬间创建过多线程，下面示例用mapv加固定线程池来控制并发：

(defn ask-batch [texts] (let [pool (java.util.concurrent.Executors/newFixedThreadPool 4)] (try (->> texts (mapv (fn [text] (future (call-llm [{:role "user" :content text}])))) (mapv deref)) (finally (.shutdown pool)))))

不过这种方式比较粗糙。更符合 Clojure 风格的批量并发会使用core.async，把输入文本放入 channel，再用多个 worker 并行消费。这里给出一个简化版：

(require '[clojure.core.async :refer [chan go <!! >!! close!]]) (defn batch-agent [texts worker-count] (let [in (chan) out (chan) _ (doseq [text texts] (>!! in text)) _ (close! in)] (dotimes [_ worker-count] (go (loop [] (when-let [text (<!! in)] (>!! out (call-llm [{:role "user" :content text}])) (recur))))) (loop [acc []] (if (= (count acc) (count texts)) acc (recur (conj acc (<!! out)))))))

core.async 的好处是线程数可控、背压容易处理，坏处是理解成本比 Python 的 asyncio 高一些。

6.3 Elixir 的批量并发

Elixir 里做批量并发最舒服的方式是用Task.Supervisor.async_stream_n。它专门处理“一批任务 + n 个并发”的场景，返回结果保持输入顺序。

假设你已经把 Agent 封装成模块，并且有一个ask(text)函数：

defmodule AgentLab.Batch do def run(texts, concurrency \\ 4) do texts |> Task.async_stream( &AgentLab.Server.ask/1, max_concurrency: concurrency, timeout: 120_000, ordered: true, on_timeout: :kill_task ) |> Enum.map(fn {:ok, result} -> result end) end end

这里真正有价值的地方不在代码量，而在容错机制：

• timeout直接设置单任务超时。
• on_timeout: :kill_task确保单个 LLM 调用超时不会拖垮整个批量任务。
• 如果 Agent 服务需要重启，Supervisor 会自动拉起新的进程树。

这些在 Python 里都要自己额外实现，Elixir 里是平台自带能力。

6.4 重试与兜底策略

无论哪种语言，批量跑 LLM 任务都要考虑同一个问题：模型的回答可能出现空内容、格式错误、工具调用参数不合法。

建议在代码里增加三处兜底：

• 对单个任务设置超时时间，例如 120 秒。
• 对 HTTP 500/503 或网络错误做最多 2 次重试，重试间隔使用指数退避。
• 对模型输出的 JSON 字段做结构校验，字段不存在时不要直接抛异常，而是记录日志并跳过。

三条语言里，Python 需要 try/except，Clojure 需要try/catch或ex-info，Elixir 则更依赖“让进程失败，由 Supervisor 恢复”的思路。这也是多语言建模时差异最明显的地方。

7. 资源占用与性能观察思路

这个主题没有直接涉及模型推理的显存数字，因为 LLM 推理通常发生在单独的模型服务里，三种语言版本只是 Agent 的编排客户端。真正值得观察的指标是以下几个方面。

7.1 客户端进程的内存占用

• Python 进程启动后基础内存比较低，但如果引入重级依赖如 LangChain、Pandas，内存会明显上升。
• Clojure 跑在 JVM 上，JVM 默认堆内存可能占 1GB 以上，需要设置-Xmx控制上限。
• Elixir 的 BEAM 虚拟机启动时也会占用一定内存，但每个轻量进程只占用很小一部分，适合大量会话并发。

如果只是做原型验证，三者的内存差异不构成决定性因素；如果要长期跑高并发在线服务，BEAM 的进程模型优势会更明显。

7.2 并发连接的瓶颈

LLM Agent 的客户端通常不是计算密集，而是 IO 密集。多数情况下，真正的瓶颈在于：

• 模型服务的并发上限。
• HTTP 连接池大小。
• 代理或网关的连接数限制。
• 工具调用依赖的外部服务限流。

观察方式不需要很复杂。Linux 下用top或htop看进程 CPU/内存，网络侧可以用ss -s看 socket 连接数，或者在代码里给每次 LLM 调用增加耗时日志。

7.3 如何降低客户端资源占用

• Python 侧避免为每个请求创建新连接，使用httpx.AsyncClient复用连接。
• Clojure 侧注意 JVM 堆大小，批量任务结束后主动关闭线程池。
• Elixir 侧使用Task.Supervisor限制子任务数量，不要无限制 spawn。
• 日志是观察 Agent 行为最重要的手段。建议在每次 LLM 调用前后各打一条日志，记录消息条数、函数名、耗时、token 消耗。

需要注意的是：不要只凭“语言快不快”做判断。Agent 场景里，一次工具循环可能要串行调用 2 到 5 次模型，真正耗时的通常是模型推理和外部 API，三语言的差异主要体现在工程维护与并发编程效率上。

8. 常见问题与排查方法

如果你把三套代码都写出来跑，大概率会遇到下面几类问题。直接给排查表：

这三套代码刚上手时，最容易踩的坑其实是“模型不支持工具调用却传了 tools 参数”。部分轻量模型虽然支持 Chat Completion，但 function calling 能力弱或格式有差异，表现为 Agent 永远不触发工具分支。这种情况优先换成对 function calling 支持更好的模型，而不是反复调 Agent 代码。

9. 最佳实践与使用建议

如果你准备把“同题异构”的实战继续做深，或者想把其中一套语言方案落进真实项目，建议先看以下几件事。

9.1 把 Agent 定义为数据，而不是代码

在 Python 里，Agent 的 system prompt、工具列表、最大步数、模型名都可以写成配置对象；在 Clojure 里，Agent 本身就是 map + 函数的组合；在 Elixir 里，可以定义配置 schema。

这带来的好处是：新增一个工具、切换一个模型、调整 system prompt，都不需要重新编译 Agent 入口代码。三种语言各自的实现方式可能不同，“Agent 行为可配置”这个方向是通用的。

9.2 建立统一日志协议

同一套任务语言不同，如果日志格式不统一，后期无法对比效果。建议每轮 Agent 循环至少记录：

step=1 action=model_call model=qwen2.5 messages=6 latency_ms=1200 step=2 action=tool_call tool=weather_query args={"city":"北京"} latency_ms=80 step=3 action=model_call model=qwen2.5 messages=8 latency_ms=900

只要格式一致，后续可以直接写脚本分析哪种语言实现的 Agent 工具成功率更高、哪一轮调用浪费的轮次更多。

9.3 工具调用要有边界校验

无论是 Python 的字典分发、Clojure 的 case 分支，还是 Elixir 的 Behavior 分发，工具执行前都要增加参数校验。例如：

• 只允许访问白名单内的城市列表。
• 文件类工具只允许访问指定目录。
• 外部 API 请求必须走统一鉴权出口。

Agent 可以自由决定“是否调用工具”，但工具本身必须做参数级安全校验。不要因为 LLM 返回的 JSON 看起来合理就无条件执行。这类防御在代码里并不多，但能拦住很多意外。

9.4 会话恢复与超时控制

线上服务场景中，用户可能中断、重试或同时打开多个会话。建议：

• 为每个会话生成一个唯一 ID。
• 使用 Redis 或其他外部存储持久化 messages。
• GenServer 或进程模型里设置超时，避免单个工具调用把会话卡死。
• Agent 达到最大步数时，返回明确错误信息，避免静默中断。

9.5 模型输出复核不能省

工具调用类 Agent 的最后一轮输出，如果会直接展示给用户，建议在展示前再做一次格式检查。有些模型会在包含工具结果后生成不稳定回答，出现重复内容或 JSON 语法残留。批量任务尤其需要抽检，不要只看成功数。

10. 总结与下一步

这个主题最值得体验的不是“我又学会了一种新语言的语法”，而是强迫你重新审视 LLM Agent 的必要组成部分：状态怎么保存、工具循环怎么写、并发任务怎么隔离、超时和失败怎么处理。

Python 版本适合第一版跑通，你可以在最短时间内验证 Agent 逻辑。 Clojure 版本适合用来感受“数据流 + 不可变状态”的建模方式，特别是在需要维护大量复杂规则和配置的项目里，这个思路会很有启发。 Elixir 版本适合继续演进成在线服务，因为 BEAM 的进程隔离和 Supervisor 容错机制几乎是天然为“多会话、长连接、高并发”设计的。

最容易踩的坑也已经很明确：不要在不确认模型支持情况的前提下调试工具循环；不要忘了给批量任务设置超时和重试；工具调用永远是安全边界最需要关注的地方。

如果你已经在 Python 里跑通了基础版本，下一步可以先把 Clojure 的递归版本写出来，对比一下两种语言在“状态传递”上的不同感受；然后，再把 Elixir 的 GenServer 版本接到真实服务里，用两个用户同时提问来验证进程隔离是否比全局变量方式更干净。

这套“一份 Agent 定义，三种语言实现”的练习做完，你对 Agent 组成的理解会比单纯调 SDK 深刻得多。建议收藏备用，后面做多语言团队技术选型或 Agent 框架设计时都可以翻回来参考。