<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Tool on kkBill&#39;s Blog</title>
    <link>https://kkbill.github.io/tags/tool/</link>
    <description>Recent content in Tool on kkBill&#39;s Blog</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sun, 31 May 2026 21:11:17 +0800</lastBuildDate>
    <atom:link href="https://kkbill.github.io/tags/tool/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Harness Engineering 03. Tool</title>
      <link>https://kkbill.github.io/posts/harness-engineering-03-tool/</link>
      <pubDate>Tue, 26 May 2026 21:00:00 +0800</pubDate>
      <guid>https://kkbill.github.io/posts/harness-engineering-03-tool/</guid>
      <description>&lt;p&gt;工具接口与协议层定义了 Agent 如何发现能力、如何表示可调用的功能接口，以及如何执行动作。在实践中，&lt;strong&gt;一方面通过引入更多工具来扩大能力覆盖范围，另一方面通过保持尽量小规模的动作空间和提示词大小来维护决策质量&lt;/strong&gt;。Anthropic 和 OpenAI 最新工程实践[&lt;a href=&#34;https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents&#34;&gt;1&lt;/a&gt;][&lt;a href=&#34;https://developers.openai.com/api/docs/guides/function-calling&#34;&gt;2&lt;/a&gt;]指出，&lt;strong&gt;过多的工具会降低可靠性、增加 token 开销，并放大规划错误&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;论文将这一层组织为四个方向：协议与接口标准；工具描述、发现与选择；工具增强训练与集成；以及可扩展性与会话管理。&lt;/p&gt;
&lt;p&gt;&lt;img alt=&#34;image.png&#34; loading=&#34;lazy&#34; src=&#34;https://kkbill.github.io/posts/harness-engineering-03-tool/images/image00.png&#34;&gt;&lt;/p&gt;
&lt;h2 id=&#34;1-协议与接口标准&#34;&gt;1. 协议与接口标准&lt;/h2&gt;
&lt;p&gt;本节所讨论的核心问题是：&lt;strong&gt;智能体如何通过统一的“语言”和“规则”与外部世界或其他智能体进行交互&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;在没有统一协议之前，开发者需要为每一个工具（如天气API、数据库、文件搜索）编写专门的对接代码。&lt;strong&gt;MCP(Model Context Protocol，模型上下文协议)&lt;/strong&gt; 改变了这一点。 它像是一个“通用插头”。只要工具方提供了一个遵循 MCP 标准的服务，任何智能体都可以直接“插入”并使用，无需重新开发连接器。&lt;/p&gt;
&lt;p&gt;A2A 针对的则是另一个问题。&lt;strong&gt;它不是向单个 Agent 暴露工具，而是对智能体之间的通信进行标准化&lt;/strong&gt;，包括通过 Agent Cards 进行发现、支持同步与流式交互，以及长时任务协作。MCP 和 A2A 是互补的：MCP 主要用于工具访问，A2A 用于 Agent 间委托与协作。&lt;/p&gt;
&lt;p&gt;函数调用模式(Function-calling schemas)与 API 描述标准是这一层的基础构建块。OpenAI 风格的 &lt;a href=&#34;https://developers.openai.com/api/docs/guides/function-calling&#34;&gt;Function Calling&lt;/a&gt; 使工具调用具备可操作性；&lt;a href=&#34;https://github.com/OAI/OpenAPI-Specification&#34;&gt;OpenAPI&lt;/a&gt; 提供了一种与语言无关的、机器可读的 API 契约，许多 Agent 框架将其用作工具生成与验证的来源。此外，仓库级别的指令文件（如 &lt;a href=&#34;https://github.com/agentsmd/agents.md&#34;&gt;AGENTS.md&lt;/a&gt; 和 &lt;a href=&#34;https://github.com/agentmd/agent.md&#34;&gt;AGENT.md&lt;/a&gt;）提供了一种轻量级替代方案，用于直接在版本控制中编码工具使用和工作流约束，从而降低Code Agent的配置成本。&lt;/p&gt;
&lt;p&gt;论文根据&lt;strong&gt;谁在和谁说话&lt;/strong&gt;（交互边界）对协议与接口标准进行如下分类：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;模型 ↔ 函数 (Model ↔ Function)&lt;/strong&gt;：
&lt;ul&gt;
&lt;li&gt;典型代表：OpenAI 的 Function Calling。&lt;/li&gt;
&lt;li&gt;解释：**这是最基础的一层，解决的是“模型如何把一句话变成一个结构化的 JSON 请求”。**它发生在模型调用的瞬间。&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;智能体 ↔ 外部能力 (Agent ↔ Capability)&lt;/strong&gt;：
&lt;ul&gt;
&lt;li&gt;典型代表：MCP、OpenAPI。&lt;/li&gt;
&lt;li&gt;解释：&lt;strong&gt;解决的是“运行中的智能体如何调用它所在环境之外的工具”&lt;/strong&gt;。比如一个在终端运行的智能体如何去调取 Google 搜索或操作远程数据库。&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;智能体 ↔ 智能体 (Agent ↔ Agent)&lt;/strong&gt;：
&lt;ul&gt;
&lt;li&gt;典型代表：A2A、ACP。&lt;/li&gt;
&lt;li&gt;解释：当一个智能体搞不定任务，需要把任务交给另一个智能体协作时，它们之间需要一套发现对方、同步进度、甚至流式传输信息的标准。&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;智能体 ↔ 代码库/环境 (Agent ↔ Repo/Env)&lt;/strong&gt;：
&lt;ul&gt;
&lt;li&gt;典型代表：AGENTS.md。&lt;/li&gt;
&lt;li&gt;解释：这是一种轻量级标准，通过在代码库里放一个 Markdown 文件来告诉智能体：“这里有哪些工具可以用，有哪些规则你要遵守”。&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;img alt=&#34;image.png&#34; loading=&#34;lazy&#34; src=&#34;https://kkbill.github.io/posts/harness-engineering-03-tool/images/image01.png&#34;&gt;&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
