工具接口与协议层定义了 Agent 如何发现能力、如何表示可调用的功能接口，以及如何执行动作。在实践中，一方面通过引入更多工具来扩大能力覆盖范围，另一方面通过保持尽量小规模的动作空间和提示词大小来维护决策质量。Anthropic 和 OpenAI 最新工程实践[1][2]指出，过多的工具会降低可靠性、增加 token 开销，并放大规划错误。
论文将这一层组织为四个方向：协议与接口标准；工具描述、发现与选择；工具增强训练与集成；以及可扩展性与会话管理。
1. 协议与接口标准
本节所讨论的核心问题是：智能体如何通过统一的“语言”和“规则”与外部世界或其他智能体进行交互。
在没有统一协议之前，开发者需要为每一个工具（如天气API、数据库、文件搜索）编写专门的对接代码。MCP(Model Context Protocol，模型上下文协议) 改变了这一点。 它像是一个“通用插头”。只要工具方提供了一个遵循 MCP 标准的服务，任何智能体都可以直接“插入”并使用，无需重新开发连接器。
A2A 针对的则是另一个问题。它不是向单个 Agent 暴露工具，而是对智能体之间的通信进行标准化，包括通过 Agent Cards 进行发现、支持同步与流式交互，以及长时任务协作。MCP 和 A2A 是互补的：MCP 主要用于工具访问，A2A 用于 Agent 间委托与协作。
函数调用模式(Function-calling schemas)与 API 描述标准是这一层的基础构建块。OpenAI 风格的 Function Calling 使工具调用具备可操作性；OpenAPI 提供了一种与语言无关的、机器可读的 API 契约，许多 Agent 框架将其用作工具生成与验证的来源。此外，仓库级别的指令文件（如 AGENTS.md 和 AGENT.md）提供了一种轻量级替代方案，用于直接在版本控制中编码工具使用和工作流约束，从而降低Code Agent的配置成本。
论文根据谁在和谁说话（交互边界）对协议与接口标准进行如下分类：
- 模型 ↔ 函数 (Model ↔ Function)：
- 典型代表：OpenAI 的 Function Calling。
- 解释：**这是最基础的一层，解决的是“模型如何把一句话变成一个结构化的 JSON 请求”。**它发生在模型调用的瞬间。
- 智能体 ↔ 外部能力 (Agent ↔ Capability)：
- 典型代表：MCP、OpenAPI。
- 解释：解决的是“运行中的智能体如何调用它所在环境之外的工具”。比如一个在终端运行的智能体如何去调取 Google 搜索或操作远程数据库。
- 智能体 ↔ 智能体 (Agent ↔ Agent)：
- 典型代表：A2A、ACP。
- 解释：当一个智能体搞不定任务，需要把任务交给另一个智能体协作时，它们之间需要一套发现对方、同步进度、甚至流式传输信息的标准。
- 智能体 ↔ 代码库/环境 (Agent ↔ Repo/Env)：
- 典型代表：AGENTS.md。
- 解释：这是一种轻量级标准，通过在代码库里放一个 Markdown 文件来告诉智能体：“这里有哪些工具可以用，有哪些规则你要遵守”。
2. 工具描述、发现与选择
一旦协议定义了如何进行调用，下一个瓶颈就是应该暴露和选择哪些工具。越来越多的研究工作关注工具文档质量、检索和动态候选剪枝。
- EASYTOOL 分析了从大型工具库中选择合适工具的挑战。
- AnyTool 和 CRAFT 专注于通过自动构建或细化工具使用流水线来减少手动规范负担。
- MetaTool 的基准式评估表明，工具检索和调用质量在不同领域和查询形式之间可能存在显著差异。
- MCP-Zero、ToolRet 和 ToolRegistry 强调检索感知的编排和注册表质量是决定下游 Agent 成败的关键因素。
- 一个密切相关的方向将工具选择扩展到可复用技能，其中 Agent 必须识别相关的程序模块，而不仅仅是紧凑的 API schema。SkillRouter 和 SkillRet 都在大规模上研究了这种技能选择问题，凸显了从大型且重叠的技能库中检索正确技能的必要性。
在系统层面，这些结果强化了两条设计原则。第一，“少而精的工具”通常优于暴力式工具暴露，因为它同时缩小了提示熵（prompt entropy）和规划器分支（planner branching）。第二，发现流水线必须是自适应的：静态的全局工具列表无法扩展到快速演化的仓库或多租户企业部署。
3. 工具增强训练与集成
这一节讨论的是智能体如何从单纯的“调用工具”演进到在模型底层能力层面与工具深度融合。工具能力的获取从“运行时编排”转向了“模型能力习得”，主要涵盖了以下几个技术方向：
- 自主学习何时调用：Toolformer 展示了通过自监督增强技术，让模型学会自主决定在生成的什么位置、以何种方式插入 API 调用。
- 大规模指令微调：Gorilla 和 ToolLLM/ToolBench 通过更大规模的工具语料库、指令微调流水线以及针对 API 使用的执行中心化监督，扩展了这一路线。
- 深度架构集成：ToolkenGPT 和 CREATOR 探索了在 Token 级别或控制器风格的集成，旨在提高调用格式的保真度和规划的稳定性。
- Harness 层的支撑：在生产环境中，这些模型侧的能力通常与 LangChain、Semantic Kernel 和 smolagents 等 Harness 框架配合使用，以提供记忆抽象、路由中间件和工具适配器等。
此外，论文还提到了Agentic Code Reasoning，是因为它代表了工具使用从“外部插件”向“模型内在逻辑协议”演进的高级形态。在编码场景下，工具不再只是简单的计算器或搜索接口，而是静态分析器、类型检查器和证明助手等具有“推理属性”的工具。它被定义为介于“非结构化的思维链（CoT）”与“完全形式化验证”之间的一种半形式化推理方法。这种方法强制智能体陈述前提、追踪程序路径并得出结论，从而在逻辑层面将工具的产出深度嵌入到模型的思考过程中。
4. 可扩展性与会话管理
有状态工具会话提高了任务处理的连续性，但同时也增加了状态管理复杂度，尤其是当多个智能体并行调用或委派工具时，状态同步变得异常困难。本节讨论的就是智能体在执行长程任务时，如何在 Harness 层面管理工具会话的状态与规模。
典型的故障模式包括失效句柄、重试间不一致的工具状态，以及冗长工具轨迹导致的上下文窗口饱和。因此，有效的 Harness 设计需要对工具会话进行显式的生命周期控制、有界工具上下文注入，以及可观测性钩子：
- 显式的生命周期控制：必须有明确的工具会话开启、挂起和关闭逻辑。
- 有界的上下文注入：对工具返回的信息进行截断或过滤，防止上下文爆炸。
- 细粒度的观测钩子：能够区分错误究竟源于智能体的“规划逻辑”，还是底层的“接口故障”。