如果说前面几篇在解决：

Prompt Chaining → 怎么做

Parallelization → 做得快

Reflection → 做得对

那么这一篇要解决的是一个更本质的问题：

AI做的这些事情，怎么真正“产生价值”？

答案只有一个：

它必须能影响现实世界。

而 Tool Use，就是这一步。

---

一、没有 Tool Use 的 AI，本质还是“聊天机器人”

我们先讲一个非常现实的认知误区。

很多人会觉得：

“我的AI已经可以分析患者、给建议，很强了”

但本质上，它仍然只是：

读取文本

生成文本

它没有能力做任何事情。

---

举个医疗场景

用户问：

“这个患者最近的肿瘤指标怎么样？”

没有 Tool Use：

👉 模型只能“猜”或基于历史上下文回答

有 Tool Use：

👉 模型可以：

查询EHR

获取最新检验结果

再进行分析

---

👉 这就是本质差别：

Tool Use 把 AI 从“解释世界”，变成“操作世界” (Agentic Design)

---

二、Tool Use 的本质模型

如果用工程语言描述，它其实是一个闭环：

LLM → 决定调用工具 → 执行工具 → 获取结果 → 再推理

展开来看，其实是四个步骤：

---

1️⃣ Tool Definition（工具定义）

告诉模型：

这个工具是干什么的

有哪些参数

---

2️⃣ Tool Invocation（工具调用）

模型决定：

什么时候用工具？用哪个？

---

3️⃣ Tool Execution（工具执行）

系统执行：

API调用

数据查询

代码执行

---

4️⃣ Result Integration（结果整合）

工具返回结果 → 再喂给模型 → 生成最终输出 ()

---

👉 这一整套，本质上就是：

把LLM嵌入一个“执行系统”中

---

三、回到场景：患者全病程管理

我们直接用你最重要的业务来拆。

---

❌ 没有 Tool Use

输入：患者描述

输出：随访建议

问题：

没有真实数据

无法更新

无法执行

---

✅ 有 Tool Use

Step1: 查询患者EHR（Tool）

Step2: 获取检验结果（Tool）

Step3: 分析风险（LLM）

Step4: 写入随访计划（Tool）

---

👉 这时候，AI系统具备了：

数据读取能力

数据写入能力

系统联动能力

---

四、最基础的代码实现（Function Calling）

我们直接上最核心的工程实现。

---

1️⃣ 定义工具（关键）

tools = [

{

“name”: “get_lab_results”,

“description”: “获取患者最新检验结果”,

“parameters”: {

“type”: “object”,

“properties”: {

“patient_id”: {“type”: “string”}

},

“required”: [“patient_id”]

}

}

]

---

👉 注意：

这里不是写给人看的，是写给模型看的。

---

2️⃣ 模型决定是否调用工具

response = client.chat.completions.create(

model=”gpt-4o”,

messages=messages,

tools=tools

)

---

如果模型判断需要调用：

{

“tool_call”: {

“name”: “get_lab_results”,

“arguments”: {

“patient_id”: “123”

}

}

}

---

3️⃣ 执行工具

def get_lab_results(patient_id):

return query_ehr(patient_id)

---

4️⃣ 把结果再喂回模型

messages.append({

“role”: “tool”,

“content”: result

})

---

👉 然后模型再生成最终答案

---

五、一个完整的医疗链路

我们把它和前面的模式组合一下。

---

示例：自动随访生成系统

def pipeline(patient_id):

Step1: 调工具拿数据

lab = get_lab_results(patient_id)

pathology = get_pathology(patient_id)

Step2: Prompt Chaining分析

structured = extract_patient_info(lab, pathology)

risk = risk_analysis(structured)

Step3: Reflection校验

risk_checked = reflect_risk(risk)

Step4: 写回系统（Tool）

save_followup_plan(patient_id, risk_checked)

return risk_checked

---

👉 这个结构非常重要：

Tool Use 不只是“调用API”，而是嵌入整个Agent流程

---

六、Tool Use 的三种典型能力

从系统角度看，所有工具可以分成三类：

---

1️⃣ 感知工具（Read）

👉 获取信息

查询EHR

获取检验报告

拉取影像

---

2️⃣ 推理工具（Process）

👉 计算 / 分析

风险模型

评分系统

统计分析

---

3️⃣ 行动工具（Act）

👉 改变世界

写入医嘱

发送随访通知

创建任务

---

👉 这三类构成：

Agent 的“感知 → 思考 → 行动”闭环 (Jaymin West)

---

七、最容易被忽略的：Tool 设计

很多系统失败，不是因为模型不行，而是：

工具设计太差

---

❌ 常见错误

1. 一个“万能工具”

tool(name=”ehr”, mode=”get/update/delete/…”)

👉 LLM会崩溃（参数太复杂）

---

2. 参数过多

👉 模型不知道怎么填

---

3. 描述不清晰

👉 模型不知道什么时候用

---

八、正确的 Tool 设计原则

---

1️⃣ 单一职责

get_lab_results

get_patient_profile

save_followup_plan

---

2️⃣ 参数最小化

👉 只保留必要字段

---

3️⃣ 用例驱动设计

给模型“示例调用”：

{

“patient_id”: “123”

}

👉 实测可以显著提升调用准确率 ()

---

4️⃣ 面向“模型理解”，而不是“工程优雅”

这是一个反直觉点：

工具不是给人用的，是给LLM用的 (Agentic Thinking)

---

九、生产级系统必须解决的3个问题

---

1️⃣ 安全（最重要）

沙箱执行

权限控制

审批机制

👉 否则风险极高 ()

---

2️⃣ 错误处理

超时

重试

fallback

---

3️⃣ 可观测性

每一次工具调用都要记录

可回溯

---

👉 Tool Use 是最大“风险面”

---

十、和前面模式的关系

现在你可以看到整个系统开始成型：

---

Prompt Chaining

👉 定义流程

Parallelization

👉 提升效率

Reflection

👉 提升质量

Tool Use

👉连接现实世界

---

组合后：

任务拆解 → 并行执行 → 结果校验 → 工具执行 → 状态更新

---

👉 这已经不是AI应用，而是：

一个完整的智能系统

---

十一、一个更深的理解

很多人会把 Tool Use 理解为：

“让AI调API”

但更本质的是：

你在给AI“手”和“眼睛”

没有工具 → AI只是大脑

有了工具 → AI成为“行动体”

如果说：

Reflection 让AI对结果负责

那么 Tool Use 的意义是：

让AI对现实世界负责

这一步，决定了你的系统：

是一个“AI助手”

还是一个“AI系统”

---

一句话总结

没有 Tool Use 的 Agent，只是更聪明的聊天机器人；有了 Tool Use，才是真正的软件系统。