一、前言

          从 Agent 具备使用工具的能力，一直到 MCP 协议的出现，是工具逐渐走标准化和协议统一的过程。工具设计技术难度不大，这里将结合任务型 Agent 的实际应用，深入探讨工具设计时需要考虑的关键因素：

• 工具怎么定义？通常工具被定义为接口函数，但同时可以是大模型调用、一段代码等。

• 在工具调用过程中，涉及多个不同工具的集成与调用，参数值的格式定义与适配是确保系统兼容性与调用成功率的关键环节。由于各类工具对外暴露的接口规范、数据结构和序列化方式各不相同，必须建立统一的参数描述与转换机制。

• 工具的执行结果是直接返回原始输出，还是由大模型进行摘要总结？如果使用者希望查看工具的原始执行结果，应采用何种更优的交互形式来呈现，例如通过表格、格式化SQL、代码高亮等方式提升可读性与用户体验？

• 个别工具（如执行时间长的异步工具）参数需要用户确认怎么处理？

二、工具领域模型

​         任务型 Agent 的工具调用具有异步执行特性，工程上抽取了”工具组“的概念，异步工具组由提交（submit）、查询（query）和中止（terminate）三个工具组成，同步工具组仅由提交（submit）工具组成，如图：

1）工具 prompt 描述

​      “工具 prompt 描述”是在准备 prompt 过程中填充的工具的描述信息，示例如下：

=工具编码：submitOptimizeTask
*工具描述: 提交优化任务
*参数列表:
       id:ID,必填,
       name:名称,必填,
       taskDesc:描述,非必填,
       ---------------- 以下参数只能成对出现一个 ----------------
       A:这是参数A的描述
       B:这是参数B的描述
       
       C:这是参数C的描述
       D:这是参数D的描述
       ---------------- 以下参数只能成对出现一个 ----------------
       extra:扩展信息,非必填

从示例中看出工具的描述信息不能通过代码结构化实现，所以单独存储到 promptValue 字段中，这样不仅能减小 prompt 上下文的 token 数量，还能保留工具参数的可描述性。

2）工具参数值格式

​      在基于 Reflection 自主规划模式下，执行计划（参考《任务型Agent：工具详细设计》文章）的节点可具象化成 function 类型节点。当一个工具执行结束后，大模型会根据工具执行结果刷新当前执行计划的结构，刷新过程中会填充“下一个待执行”节点的参数。那么核心问题来了：节点（工具）的参数值以什么格式组装到执行计划节点中？工具格式设计需兼顾大模型的理解能力、上下文 token 的节省，以及工程解析的便捷性。

任务型 Agent 工具参数值采用如下格式来组装：

参数名1:[参数值1,参数值1]|参数名2:参数值2|参数名3:{参数名a:参数值a|参数名b:参数值b...}|参数名4:[{参数名a:参数值a|参数名b:参数值b...}...]...

3）工具的抽象

​      在执行计划中，节点可根据不同的 Agent 模式定义为 function、agent 或多 function 组合等形式。从更高层次的抽象视角来看，无论是面向 function 的流程编排，还是具体的单个 function，均可视为节点的不同具象表现。更进一步，函数签名、变量命名等细节，也已可由大模型通过自主学习生成。这引发了一个更深层的问题：大模型是否具备自动生成工具的能力？然而，无论抽象层级多高，最终仍需落地到具体的工程框架中。实践中我们发现，抽象层级越低的 Agent，越难以适应未来模型能力的演进和业务需求的变化。这印证了那句理念：Less code, more intelligence。但在这条演进路径上，团队往往不可避免地陷入两种极端观点的博弈之中：

• 理想化的观点：工程代码尽量抽象，少做些逻辑限制，事情都交由大模型来做。

• 业界采用最多的观点：因大模型能力有限，工程代码出现了各种“分治”和“兜底”的场景，多少智能多少人力。

相信在不久将来，随着大模型能力的提升，理想化的观点会划清“业务”和“框架”的职责界限。

4）工具执行状态机

      工具执行由异步框架来驱动，执行状态机由系统推进，非大模型驱动。

三、MCP

         Function Call 概念最早由 OpenAI 于 2023 年 6 月提出，旨在将其深度集成至大模型能力中，通常与特定大模型厂商的技术栈紧密绑定。而 MCP（Model Context Protocol）则是由 Anthropic 公司于 2024 年 11 月 25 日正式推出的开放协议。可以这样理解：MCP 的目标是打破平台壁垒，为跨模型、跨平台的工具调用提供统一的标准接口，从而实现更灵活、可互操作的 AI 系统集成。因此，MCP 与传统 Function Call 在设计理念和适用范围上存在本质区别。

        本项目所实现的工具机制，本质上可视为一种自定义的 MCP 流程。具体而言，在 Spring 容器启动过程中，通过解析带有自定义注解的 Bean 完成工具的注册与加载。新工具的接入方式示例如下：

@Component
@ToolGroup(name="ptimize")
public class Optimize {
    
    @ToolMethod(name = "submitOptimize")
    public Result submit(Request request) {
        //......
    }
    
    @ToolMethod(name = "queryOptimize")
    public Result query(Request request) {
        //......
    }
    
    @ToolMethod(name = "terminateOptimize")
    public Result terminate(Request request) {
        //......
    }
}

四、思考

1）用户与工具的交互

​      任务型Agent下异步工具往往执行比较久，造成用户等待和试错成本较高，所以执行成本高的工具在执行之前需要用户确认一下“方案”（比如参数填写是否符合预期等），流程如下：

再浅谈一些经验：

• 工具参数尽量内置化，有些异步工具参数比较复杂，曾遇到过50个以上都有，这种情况下大模型出现幻觉概率会很大，参数不全时若频繁地反问用户会极大降低用户的体验。参数多的工具在对话框弹出表单更适合用户。

• 工具参数是由大模型根据上下文提取的，与传统工程显示传递不太一样，要转变这个思维。但有些场景下交给大模型存在训练成本，能方便工程传递的尽量使用工程手段。

2）MCP 未来设想

      看到过一段话，自行理解：

所以未来很有可能每个企业都有自己的MCP Server市场，在MCP Server市场里分门别类，每类MCP Server有专门的研发团队负责，不用太需要考虑统一返回格式，不用考虑开发语言统一。运营、市场、产品等业务方有业务需求或者有新的产品功能需求时，可以通过统一界面用大白话快速构建AI应用，MCP+LLM来实现业务编排，实现PRD既产品（PRD as a Product）的新的开发模式。

附：摘自《万字长文告诉你如何基于MCP实现AI应用架构新范式转型》

3）工具池与 prompt 上下文限制的矛盾

      随着 Agent 可调用工具的增多，Prompt 中工具候选集的扩张将直接导致上下文 Token 数量增长。业界常采用基于意图识别的工具预筛选机制以缓解此问题，但该方案引入了额外的分类逻辑与系统复杂性。