别再写 if/else 了：让 LLM 自己决定调用哪个函数
<h2 id="前言">前言</h2><p>书接上文，今天我们来讨论上一篇文章遗留的问题：当一次性给大模型多个函数时，它到底怎么判断该调用哪一个？这个问题，在 AIOps、智能排障、客服问答、数据分析这类场景里特别常见。本文继续用理论结合时间，拿一个线上故障排查的例子，掰开揉碎了讲清楚：当有多个工具同时可用时，LLM 是怎么做决策的，以及我们代码里到底该怎么写</p>
<h2 id="实战例子">实战例子</h2>
<p>先上代码：多函数function call</p>
<h4 id="函数作用">函数作用</h4>
<p>假设现在手里有 3 个函数</p>
<ul>
<li>
<p>1）获取 Pod 状态，主要通过describe 查看 k8s pod，<code>get_pod_status</code></p>
<ul>
<li>Pod 是否 Running</li>
<li>有没有 CrashLoopBackOff</li>
<li>重启了多少次</li>
<li>最近事件里有没有探针失败、OOM、镜像拉取失败</li>
</ul>
</li>
<li>
<p>2）获取业务日志，通过调用日志平台接口获取对应日志，<code>get_business_log</code></p>
<ul>
<li>接口为什么返回 500</li>
<li>有没有空指针</li>
<li>有没有数据库超时</li>
<li>有没有调用下游失败</li>
</ul>
</li>
<li>
<p>3）获取操作系统监控数据，通过调用prometheus获取底层监控，<code>get_system_metrics</code></p>
<ul>
<li>CPU 是否打满</li>
<li>内存是否不足</li>
<li>磁盘是否写满</li>
<li>网络流量是否异常</li>
</ul>
</li>
</ul>
<h4 id="函数描述">函数描述</h4>
<ul>
<li>获取 Kubernetes Pod 的状态、重启次数和事件信息，用于排查 Pod 启动失败、异常重启、探针失败等问题</li>
<li>获取业务服务日志，用于排查接口报错、代码异常、数据库超时等问题</li>
<li>获取节点操作系统监控数据，用于排查 CPU、内存、磁盘、网络资源瓶颈问题</li>
</ul>
<p>函数描述非常重要，LLM主要靠它来指导模型决策以及函数选取</p>
<h4 id="定义三个函数">定义三个函数</h4>
<pre><code class="language-python">import json
from datetime import datetime, timedelta
def get_pod_status(namespace: str = "default", pod_name: str = ""):
return {
"namespace": namespace,
"pod_name": pod_name,
"status": "CrashLoopBackOff",
"restart_count": 5,
"node": "10.10.1.23",
"events": [
"2026-04-20 11:42:11 Readiness probe failed: connection refused",
"2026-04-20 11:42:25 Container restarted",
"2026-04-20 11:42:25 Last State: Terminated, Reason: OOMKilled"
]
}
def get_business_log(service_name: str = "", start_time: str = "", end_time: str = ""):
if not start_time:
start_time = (datetime.now() - timedelta(minutes=30)).strftime("%Y-%m-%d %H:%M:%S")
if not end_time:
end_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
return {
"service_name": service_name,
"time_range": {
"start_time": start_time,
"end_time": end_time
},
"logs": [
"2026-04-20 11:41:02 order-service create order failed: java.lang.NullPointerException",
"2026-04-20 11:41:03 order-service db timeout when inserting order record",
"2026-04-20 11:41:04 order-service retry failed, return HTTP 500"
]
}
def get_system_metrics(node_ip: str = "", start_time: str = "", end_time: str = ""):
if not start_time:
start_time = (datetime.now() - timedelta(minutes=30)).strftime("%Y-%m-%d %H:%M:%S")
if not end_time:
end_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
return {
"node_ip": node_ip,
"time_range": {
"start_time": start_time,
"end_time": end_time
},
"metrics": {
"cpu_usage": "91%",
"memory_usage": "93%",
"disk_usage": "58%",
"network_rx": "110MB/s",
"network_tx": "76MB/s"
}
}
TOOL_MAP = {
"get_pod_status": get_pod_status,
"get_business_log": get_business_log,
"get_system_metrics": get_system_metrics,
}
</code></pre>
<h4 id="定义工具描述">定义工具描述</h4>
<pre><code class="language-python">tools = [
{
"type": "function",
"function": {
"name": "get_pod_status",
"description": "获取 Kubernetes Pod 的运行状态、重启次数和事件信息，用于排查 Pod 异常重启、启动失败、探针失败、CrashLoopBackOff 等问题。",
"parameters": {
"type": "object",
"properties": {
"namespace": {
"type": "string",
"description": "Pod 所在命名空间，默认 default"
},
"pod_name": {
"type": "string",
"description": "Pod 名称或者工作负载名称"
}
},
"required": ["pod_name"]
}
}
},
{
"type": "function",
"function": {
"name": "get_business_log",
"description": "获取业务服务日志，用于排查接口报错、HTTP 500、代码异常、数据库超时、调用下游失败等问题。",
"parameters": {
"type": "object",
"properties": {
"service_name": {
"type": "string",
"description": "服务名称，比如 order-service"
},
"start_time": {
"type": "string",
"description": "查询开始时间，格式 YYYY-MM-DD HH:MM:SS"
},
"end_time": {
"type": "string",
"description": "查询结束时间，格式 YYYY-MM-DD HH:MM:SS"
}
},
"required": ["service_name"]
}
}
},
{
"type": "function",
"function": {
"name": "get_system_metrics",
"description": "获取节点操作系统监控数据，包括 CPU、内存、磁盘和网络使用情况，用于排查节点负载高、资源瓶颈、系统卡顿等问题。",
"parameters": {
"type": "object",
"properties": {
"node_ip": {
"type": "string",
"description": "节点 IP 地址"
},
"start_time": {
"type": "string",
"description": "查询开始时间，格式 YYYY-MM-DD HH:MM:SS"
},
"end_time": {
"type": "string",
"description": "查询结束时间，格式 YYYY-MM-DD HH:MM:SS"
}
},
"required": ["node_ip"]
}
}
}
]
</code></pre>
<h4 id="模型决定调用">模型决定调用</h4>
<p>下面这段代码，是整篇文章最核心的部分。</p>
<ul>
<li>把用户问题和工具列表发给模型</li>
<li>如果模型决定调用函数，就执行对应函数</li>
<li>把函数执行结果再喂给模型，让它输出最终结论</li>
</ul>
<pre><code class="language-python">import json
from litellm import completion
def run_agent(user_query: str):
messages = [
{
"role": "system",
"content": (
"你是一个线上故障排查助手。"
"请根据用户问题自主选择最合适的工具。"
"如果一个工具不足以定位问题，可以继续调用其他工具。"
"回答时要基于工具返回的事实，不要编造。"
)
},
{
"role": "user",
"content": user_query
}
]
while True:
response = completion(
model="doubao-seed-2.0-pro",
messages=messages,
tools=tools,
tool_choice="auto"
)
message = response.choices.message
tool_calls = message.tool_calls
if not tool_calls:
return message.content
messages.append(message)
for tool_call in tool_calls:
tool_name = tool_call.function.name
tool_args = json.loads(tool_call.function.arguments or "{}")
print(f" {tool_name} args={tool_args}")
tool_func = TOOL_MAP
tool_result = tool_func(**tool_args)
messages.append(
{
"role": "tool",
"tool_call_id": tool_call.id,
"name": tool_name,
"content": json.dumps(tool_result, ensure_ascii=False)
}
)
</code></pre>
<h4 id="验证结果">验证结果</h4>
<p>选取了4个不同的问题，查看llm调用函数的情况</p>
<pre><code class="language-python">if __name__ == "__main__":
test_queries = [
"我的 order-service Pod 一直重启，帮我看看怎么回事",
"下单接口一直返回 500，帮我查一下日志",
"节点 10.10.1.23 最近特别卡，帮我看下是不是资源打满了",
"order-service 返回 500，而且 Pod 也反复重启，帮我整体分析一下"
]
for idx, query in enumerate(test_queries, start=1):
print(f"\n===== 测试 {idx} =====")
print(f" {query}")
answer = run_agent(query)
print(f" {answer}")
</code></pre>
<h4 id="参考输出">参考输出</h4>
<p>并不是每一次运行都是同样的内容，这里只展现本次运行llm的输出</p>
<pre><code class="language-text">===== 测试 1 =====
我的 order-service Pod 一直重启，帮我看看怎么回事
get_pod_status args={'pod_name': 'order-service'}
get_business_log args={'service_name': 'order-service', 'start_time': '2026-04-20 11:30:00', 'end_time': '2026-04-20 11:45:00'}
get_system_metrics args={'node_ip': '10.10.1.23', 'start_time': '2026-04-20 11:30:00', 'end_time': '2026-04-20 11:45:00'}
经过排查，order-service Pod 持续重启的原因如下：
### 根因分析
1. **Pod 进程被强制终止**：Pod 状态为 CrashLoopBackOff，累计重启5次，进程终止原因是 `OOMKilled`（内存溢出被系统Kill），进程退出后导致就 绪探针探测失败报 connection refused，触发自动重启。
2. **业务代码异常**：服务运行时存在业务报错，包括空指针异常、订单数据插入数据库超时、重试失败返回HTTP 500，这类异常会导致服务资源占用异 常升高，是引发内存溢出的诱因之一。
3. **节点资源瓶颈**：Pod 所在节点10.10.1.23在故障时间段CPU使用率达91%、内存使用率达93%，节点本身负载极高，进一步加剧了Pod的资源紧张问题 ，加速触发OOMKill。
### 修复建议
1. 优先修复业务代码中的空指针异常、数据库超时问题，优化资源占用逻辑；
2. 调整 order-service Pod 的内存limit配置，适当调高内存上限；
3. 可将该Pod临时调度到其他低负载节点运行，同时对10.10.1.23节点进行资源扩容或者清理节点上多余的负载。
</code></pre>
<pre><code class="language-text">===== 测试 2 =====
下单接口一直返回 500，帮我查一下日志
get_business_log args={'service_name': 'order-service'}
根据查询order-service服务的业务日志，下单接口返回500的原因已经定位到：
1. 订单创建逻辑触发了Java空指针异常（NullPointerException）
2. 插入订单记录到数据库时出现数据库超时问题
3. 超时重试多次失败，最终接口返回HTTP 500错误
如果需要进一步排查数据库超时的根因，可以提供数据库所在节点的IP查询系统资源负载，也可以查询order-service服务的Pod运行状态确认是否存在服务本身资源不足、异常重启等问题。
</code></pre>
<pre><code class="language-text">===== 测试 3 =====
节点 10.10.1.23 最近特别卡，帮我看下是不是资源打满了
get_system_metrics args={'node_ip': '10.10.1.23'}
根据查询到的节点10.10.1.23最近30分钟的系统监控数据：
1. CPU使用率达91%，内存使用率达93%，二者均处于极高负载状态，这是导致节点卡顿的核心原因
2. 磁盘使用率为58%，处于正常水平
3. 网络入流量110MB/s、出流量76MB/s，也处于较高负载水平
当前该节点确实是CPU和内存资源几乎被打满导致运行卡顿，建议尽快排查占用资源过高的进程或Pod，进行资源扩容或者异常进程查杀。
</code></pre>
<pre><code class="language-text">===== 测试 4 =====
order-service 返回 500，而且 Pod 也反复重启，帮我整体分析一下
get_pod_status args={'pod_name': 'order-service'}
get_business_log args={'service_name': 'order-service', 'start_time': '2026-04-20 11:30:00', 'end_time': '2026-04-20 11:45:00'}
get_system_metrics args={'node_ip': '10.10.1.23', 'start_time': '2026-04-20 11:30:00', 'end_time': '2026-04-20 11:45:00'}
### 故障整体分析结论
#### 1. Pod反复重启原因
order-service的Pod当前处于`CrashLoopBackOff`状态，累计重启5次，直接原因是**内存溢出被系统杀死（OOMKilled）**，同时Pod就绪探针检测失败（ 连接被拒绝），进一步触发了Pod反复重启。
所在节点`10.10.1.23`的资源水位极高：CPU使用率91%、内存使用率93%，节点资源瓶颈是触发Pod OOM的重要诱因。
#### 2. 接口返回500原因
业务日志显示故障时间段内存在两类错误：
- 代码层面存在空指针异常（`java.lang.NullPointerException`）
- 订单插入操作触发数据库超时，重试失败后直接返回HTTP 500错误。
#### 临时恢复建议
1. 优先调整order-service的容器内存配额，同时调度到资源充足的节点
2. 修复代码空指针问题，优化数据库插入逻辑（增加超时时间/分库分表/异步插入）
3. 对`10.10.1.23`节点进行负载清退，降低节点资源使用率。
</code></pre>
<p>4组问题，llm选择了不同的、它自主决策的函数来解决对应的问题。在多函数场景里，模型并不是瞎选，而是很像运维工程师排查问题一样：</p>
<ul>
<li>先判断问题在哪一层</li>
<li>再决定调哪个工具</li>
<li>如果证据不够，就继续补证据</li>
<li>最后基于事实做总结</li>
</ul>
<p><img alt="illustration-02" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202604/1416773-20260421164916401-185171684.png" class="lazyload"></p>
<h2 id="原理解析">原理解析</h2>
<h4 id="llm-语义匹配">LLM 语义匹配</h4>
<p><img alt="illustration-03" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202604/1416773-20260421164923497-665974856.png" class="lazyload"></p>
<p>LLM 在多函数场景下的选择逻辑，本质上是拿用户问题的语义去匹配函数描述的语义，LLM会关注用户当前到底在问什么，每个函数的作用、输入参数、适 用场景分别是什么</p>
<p>然后模型会判断：</p>
<ul>
<li>哪个函数最像解决这个问题的工具</li>
<li>需不需要调用函数</li>
<li>调用时参数该怎么补齐</li>
<li>如果一个函数不够，后面还要不要继续调别的函数</li>
</ul>
<p>function call 的关键不只是有没有函数，更关键的是怎么描述函数，函数写得像说明书，模型就选得准，函数写得像谜语人，模型就容易整活</p>
<p>到这里，有为老哥可能还会继续追问：所谓的语义匹配，到底匹配的是啥？</p>
<p>模型在决策时，通常会综合下面几个维度：</p>
<ul>
<li>
<p>问题里的关键词和上下文：</p>
<ul>
<li>“Pod 重启” 更容易命中 <code>get_pod_status</code></li>
<li>“接口 500” 更容易命中 <code>get_business_log</code></li>
<li>“节点很卡” 更容易命中 <code>get_system_metrics</code></li>
</ul>
</li>
<li>
<p>函数 description 的场景描述，如果你把“用于排查什么问题”写得清楚，模型就更容易做出准确判断</p>
</li>
<li>
<p>参数是否容易从当前上下文中提取，比如用户明确说了 <code>10.10.1.23</code>等操作系统类的资源，那模型就更容易触发监控工具</p>
</li>
<li>
<p>系统提示词里的行为约束，如果你在 system prompt 里明确要求：先查事实，再下结论；必要时可以多次调用工具，模型一般会严谨许多</p>
</li>
</ul>
<p>function call 的效果，不是只取决于模型本身，也取决于你的工具定义和提示词设计</p>
<h4 id="让模型更聪明">让模型更聪明</h4>
<p>如果你发现模型老是选错函数，先排查下面几个点</p>
<p><img alt="illustration-04" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202604/1416773-20260421164932094-1304039715.png" class="lazyload"></p>
<ul>
<li>
<p>1）description 写得太短，这是最常见的问题</p>
<ul>
<li>
<p>不要只写：</p>
<ul>
<li>获取日志</li>
<li>获取监控</li>
</ul>
</li>
<li>
<p>而要写成：</p>
<ul>
<li>获取业务服务日志，用于排查接口报错、代码异常、数据库超时等问题</li>
<li>获取节点操作系统监控数据，用于排查 CPU、内存、磁盘、网络资源瓶颈问题</li>
</ul>
</li>
</ul>
</li>
<li>
<p>2）函数边界不清晰，如果两个函数看起来都像什么都能查，模型就容易纠结，所以工具设计最好做到：</p>
<ul>
<li>每个函数负责一类证据</li>
<li>不同函数之间边界清楚</li>
<li>尽量不要让多个函数 description 大面积重叠</li>
</ul>
</li>
<li>
<p>3）参数名太抽象，像这种参数：<code>id</code> <code>name</code> <code>target</code>，看着万能，实际上很坑，应该改为具体指某一类资源，实在有重名，那就疯狂叠下划线<code>pod_name</code> <code>service_name</code> <code>node_ip</code>，参数名越具体，模型越不容易理解歪。</p>
</li>
<li>
<p>4）提示词没告诉模型：可以连续调用多个工具，如果 system prompt 没写这句话，模型有时会保守，只调一个函数就停，所以建议明确告诉它：</p>
<ul>
<li>如果一个工具不足以定位问题，可以继续调用其他工具</li>
<li>回答必须基于工具返回的事实</li>
<li>不要在没有证据时直接下结论</li>
</ul>
</li>
<li>
<p>5）最后就是选择llm，应该选择那种更擅长推理的，参数更多的llm</p>
</li>
</ul>
<h2 id="总结">总结</h2>
<p>多个函数 同时存在时，LLM 不是随机选函数，而是在做语义匹配和工具决策</p>
<p>在排障场景里，这个能力尤其有价值，因为问题往往横跨 Pod、应用、系统多个层面。你不需要再维护一大堆僵硬的 if/else 规则，只需要把工具边界、description、参数定义写清楚，模型就能像一个会查证据的助手一样，自己决定先调哪个函数，必要时再继续补充调用</p>
<p>当然，真要上生产，审计、超时、权限、限流这些工程能力，一样都不能省</p>
<h2 id="联系我">联系我</h2>
<ul>
<li>联系我，做深入的交流</li>
</ul>
<p><img alt="" width="500" height="200" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202411/1416773-20241121135740959-1907948957.png#" class="lazyload"></p>
<p>至此，本文结束</p>
<p>在下才疏学浅，有撒汤漏水的，请各位不吝赐教...</p>
</div>
<div id="MySignature" role="contentinfo">
<p>本文来自博客园，作者：it排球君，转载请注明原文链接：https://www.cnblogs.com/MrVolleyball/p/19902499</p>
<div>本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须在文章页面给出原文连接，否则保留追究法律责任的权利。 </div><br><br>
来源：https://www.cnblogs.com/MrVolleyball/p/19902499
頁:
[1]