LangChain：工具调用与 Agent——从 Tool 抽象到安全边界

大模型真正走进工程之后，纯问答类应用很快会遇到一个瓶颈：只会聊天，不会做事。
这一篇聚焦 LangChain 里的工具调用与 Agent 抽象，尝试把几件事讲清楚：Tool 到底抽象了什么、Agent 是如何根据描述选择工具、多步决策的，以及在工程实践中应该如何设计安全边界。

当应用需要做的不只是回答问题，而是：

  • 查询内部系统的数据；
  • 修改代码或配置；
  • 调用第三方 API；
  • 执行脚本或本地程序；

就会出现几个常见问题：

  • 如何向模型解释「能做什么」？
    • 不能指望模型自动知道系统里有哪些 API、命令或数据库表；
    • 需要一个统一的方式，告诉模型「有哪些可用工具、分别适用于什么场景」。
  • 如何限制模型「不能做什么」？
    • 比如不允许删除数据、不允许访问某些敏感接口；
    • 工具边界如果不清晰，很容易出现安全隐患。
  • 如何在代码里管理这些工具？
    • 工具列表应该可配置、可审计，而不是散落在业务脚本中的若干 fetch/SQL 片段。

LangChain 的 Tool 抽象，正是为了解决这几个问题。

从概念上看，一个 Tool 至少包含四部分信息：

  • 名字（name）：用于在内部标识这个工具；
  • 描述（description）：用自然语言向模型说明这个工具能干什么、适用于什么场景；
  • 参数结构（schema）：说明调用时需要哪些参数、各自含义与类型；
  • 执行逻辑（call）：在实际系统中，这个工具具体如何执行。

工程层面的好处包括：

  • 工具列表变成一个可以统一管理的「注册表」；
  • 可以对每个工具单独做鉴权、审计、限流等控制；
  • 方便在不同 Agent / 应用之间共享与复用工具。

可以把 Tool 理解为：对外部能力进行的一种「显式声明」，既方便模型理解，也方便工程管控。

3. Agent 的角色：让模型学会「选工具 + 多步决策」

当有了一系列 Tool 之后，下一个问题是：谁来决定在什么时候用哪个工具、用什么参数？

最简单的做法，是在代码层面写 if/else，完全不用 Agent。
但在很多模糊决策场景中，很难把所有分支写死：

  • 用户一句话里既包含查询意图，又包含修改意图；
  • 不同问题需要调用不同组合的工具，甚至可能需要迭代调用。

LangChain 中的 Agent，做的事情可以概括为：

  • 读取当前任务描述与已知工具列表；
  • 通过大模型自己「规划」：
    • 先调用哪个工具、用什么参数；
    • 根据结果，是否需要再调用其他工具；
    • 何时收敛到一个最终答案或结果。

常见的实现思路（例如 ReAct、Plan-and-Execute）都是围绕这个目标展开：

  • 把「思考」「行动」「观察结果」写进 prompt 模板；
  • 用大模型驱动一个循环：思考 → 选工具 → 执行 → 观察 → 再思考。

工程上的关键点在于：

  • 把「工具描述」与「决策逻辑」分开：
    • 前者由 Tool 抽象负责；
    • 后者由 Agent Prompt 与控制循环负责。

一旦允许模型调用真实工具，安全问题就不能只停在 prompt 层面。

需要从几个维度设计边界：

  • 工具白名单与权限控制
    • 明确声明哪些工具可以被某个 Agent 使用；
    • 对于危险操作（删除、写入、外网访问等）设置更高权限或人工确认。
  • 参数验证与约束
    • 在真正执行工具前，对模型给出的参数进行严格校验；
    • 必要时可以「修改/修正」模型建议的参数，或要求模型重新给出更安全的参数。
  • 调用次数与深度限制
    • Agent 循环应有最大步数（防止死循环或过度试探外部系统）；
    • 对单个工具的调用频率与并发数设置上限。
  • 审计与日志
    • 记录每一次工具调用：时间、参数、结果、由哪个 Agent 触发；
    • 为后续追责、调优和安全分析提供数据基础。

LangChain 提供的 Tool / Agent 抽象，只是让「工具调用」这件事更显式、更容易被管控。
真正的安全边界设计，仍然需要结合具体业务和基础设施来完成。

在实践中，有一个容易走向的极端是：把所有需要工具调用的场景都塞进 Agent。

更稳妥的做法是：

  • 如果决策规则清晰，可以在代码里写死，就不必交给 Agent。
    • 例如：根据请求类型决定调用检索还是直接问答，完全可以由业务层用 if/else 控制；
    • 只有在确实需要「模型自己判断并探索流程」时，才需要引入 Agent。
  • 将工具调用分层
    • 底层：清晰的 Tool 定义 + 强约束参数校验；
    • 中层：由服务/业务逻辑协调一部分调用顺序；
    • 顶层：仅在必要时才让 Agent 负责「选择工具组合」。

这样可以避免 Agent 变成一个「黑箱决策器」，把太多可控逻辑丢给模型去猜。

可以用几条简短的原则来概括这篇内容：

  • Tool 抽象的价值在于：统一描述外部能力，方便模型理解、工程审计与权限控制；
  • Agent 的价值在于：在规则难以穷举时，让模型参与到「选择工具 + 多步决策」中来；
  • 安全边界不能只靠 prompt，而应该在 Tool 层引入权限、参数校验、调用频率限制与审计日志；
  • 对于规则清晰可写死的场景，优先用传统代码控制流程，只在真正需要开放式决策时才使用 Agent。

在后续更复杂的 LangChain 应用（例如 RAG + 工具调用、Agent 驱动的长链条工作流）中，只要始终遵循这几条原则，体系就更不容易失控。