工具接口与协议 (T)
ETCLOVG 之 T 层：外部能力如何被描述、发现、调用。协议标准、工具发现与选择、工具增强训练、可扩展与会话管理。
本节对应综述《Agent Harness Engineering: A Survey》§4，是 ETCLOVG 七层的第二层。该层定义 agent 如何发现能力、表示可调用 的 affordance、并跨异构运行时边界执行动作。综述指出该层处在两个相互竞争目标之间的断层线上：一方面通过暴露更多工具提升 能力覆盖，另一方面通过保持动作空间与 prompt 足迹的精简来维护决策质量——生产系统的工程经验反复报告，过大的工具菜单会 降低可靠性、增加 token 开销、放大规划错误。综述分四个互补方向。
协议与接口标准
综述认为，与其按厂商谱系或发布时间线比较标准，不如按其跨越的集成边界归类。四条边界如下（对应综述 Table 1）：
| 集成边界 | 代表标准 | 传输 | 类型化 | 运行时发现 | 长程 |
|---|---|---|---|---|---|
| Model ↔ Function | Function calling | JSON | ✓ | ✗ | ✗ |
| Agent ↔ 外部能力 | MCP | JSON-RPC | ✓ | 部分 | ✗ |
| OpenAPI | HTTP | 部分 | ✗ | ✗ | |
| Agent ↔ Agent | A2A | JSON-RPC | ✓ | ✓ | ✓ |
| ACP / ANP | HTTP | ✓ | ✓ | ✓ | |
| Agent ↔ Repo／环境 | AGENTS.md / AGENT.md | Markdown | ✗ | ✗ | ✗ |
要点：MCP 采 host-client-server 架构、以 JSON-RPC 类型化交换 tools/resources/prompts，其实际价值不止 schema 级互操作， 更在于生态流动性——构建者可复用不断扩张的 server 目录，而非为每次部署实现定制连接器。A2A 针对相邻边界：标准化 opaque agentic 应用间的通信，含 Agent Cards 发现、同步与流式交互、长程任务协作。二者互补而非重叠（MCP 主工具／上下文访问， A2A 主 agent 间委派）。Function calling 与 OpenAPI 是基础构件；AGENTS.md 等仓库级指令文件为代码 agent 提供把 工具用法与工作流约束直接编码进版本控制的轻量方案。
工具描述、发现与选择
协议定义调用如何发生后，下一瓶颈是每步应当浮现并选择哪些工具。综述梳理的代表工作：
| 系统 | 关注点 |
|---|---|
| EasyTool | 从大库存中选取合适工具的挑战 |
| AnyTool、CRAFT | 自动构造／精修工具用管线，降低人工规约负担 |
| MetaTool | benchmark 显示工具检索与调用质量跨域、跨查询形态差异显著 |
| MCP-Zero、ToolRet、ToolRegistry | 把检索感知的编排与 registry 质量视作下游成功的一阶决定因素 |
| SkillRouter、SkillRet | 把工具选择延伸到可复用 skills——从大而重叠的技能库检索正确的过程性模块 |
系统层两条设计原则：其一，“更少但更好的工具”常胜过暴力堆工具，因为它同时缩小 prompt 熵与 planner 分支；其二， 发现管线必须自适应——静态全局工具列表无法适应快速演化的仓库或多租户企业部署。
工具增强训练与集成
第三个方向从运行时编排转向模型能力获取：Toolformer（自监督学习何时／如何插入 API 调用）、Gorilla 与 ToolLLM/ToolBench（更大工具语料 + 指令微调 + 执行导向监督）、ToolkenGPT／CREATOR（token 级或 controller 式集成 以提升调用格式保真与规划稳定）。生产侧这些模型能力通常与框架级运行时栈（LangChain、Semantic Kernel、smolagents）配对。 编码 agent 还暴露更语义的一类工具：静态分析器、类型检查器、solver 验证器、证明助手、补丁等价／故障定位检查器——Ugare & Chandra (2026) 称之为 agentic code reasoning（agent 探索仓库、推理代码行为而不必执行），其对工具层的含义是：自动推理 工具应返回证据性产物（trace、证明义务、反例、结构化证书）而非黑盒 yes/no。综述结论：工具能力由预训练/微调信号、接口 schema 质量、运行时选择策略共同决定，只改一个组件收益有限。
可扩展与会话管理
长程下的反复运维挑战是会话管理。有状态工具会话提升连续性但增加簿记复杂度，尤其在调用被并行化或跨多 agent 委派时； 失败模式包括陈旧句柄、重试间工具状态不一致、冗长工具 trace 导致的窗口饱和。有效 harness 因此需要工具会话的 显式生命周期控制、有界的工具上下文注入、以及能把错误归因于 planner 逻辑或接口／协议失败的可观测 hook。评估侧有 BFCL、 StableToolBench、API-Bank、TaskBench 等 function-calling 基准；规划／执行结构见 ReAct、LLMCompiler、MCP Code Execution。