3dayoff用户8866
用 Harness 统一 Agent 工程
输入“/”快速插入内容
用 Harness 统一 Agent 工程
用 Harness 统一 Agent 工程
用户8866用户88665月16日修改
本文一万六千字，面向人群Agent工程师、AI产品经理、大模型策略产品、投资人及各岗位的领导，包含了当前打造Agent产品的所有方面，涉及到的名词有Context Engineering、Prompt Engineering、Tool call、RAG、Memory、Skill、MCP、ReAct、Workflow、Multi-Agent、Host+Sub Agent、Runtime、Gateway、Policy、Identity、Computer Use、Browser Use、Search、Fetch、Coding、Sandbox、CLI。
本文观点：搭建Agent系统，到底包含什么工作？广义上，Harness工程的意象等同于在打造Agent。狭义上，Harness工程是让Agent系统运转的软件代码。
序
Harness（马具）这个单词，其内涵在于我们如何更好地使用 Agent、使用 LLM，就像驾驭一匹马一样驾驭大语言模型。这个词的出现，并非仅仅是一个比喻，它确实满足了当前工程界对某一类型软件工程的定义。之前我们一直没办法描述或命名我们围绕 LLM（大语言模型）所做的一系列软件工程，而如今借助 Harness 这个词，即便它如此抽象，我们终于可以明确：各类 Agent 产品的工作都可以称为 Agent Harness 工程。
Anthropic在《Effective harnesses for long-running agents》一文中，将Harness定义为让AI代理跨越多个上下文窗口、持续稳定推进长期任务的一套 “工作制度”和工具链。其核心目标是解决Agent在长时间运行中的状态遗忘和目标漂移问题。
我认为 Harness 在广义上，能够区别且包含了以前我们设计 Agent 的一些工作，如 Context Engineering、Prompt Engineering、RAG、Memory，这些都只能代表整个 Agent 工程的一小部分。而 狭义的Harness 是在讨论 Agent、出现 Agent 架构以后，因为软件工程需求扩大才出现的。具体而言，是在出现工具调用、多 Agent 协同处理复杂多步长程任务之后才出现的工作。我在这里重新做一次分类和聚类，尽可能地把 Agent Harness 这个范围和定义说清楚。因为在我目前看来，做一个 Agent 产品就必须有 Harness。如果你没办法定义好这个 Harness，就做不出来一个好的 Agent 产品。无论你是 Agent 工程师，还是 AI 产品经理，也可以说是大模型策略产品——这里说的“策略”二字，正是指 Harness 本身。而落地一套 Agent，输入端、执行端、评测端都有非常多的工作量，望各位领导周知。
第一部分 基础认知
首先我们从最基础的 LLM 交互方式说起。大语言模型（LLM）触发的方式是输入任意的上下文，输出任意的 Token。所有使用这类 AI 的方式，就是围绕怎么输入这个上下文：每一个 AI 产品都在思考怎么限制、展示、使用 Agent 输出的 Token，或者怎么承接 Agent 输出的 Token。
最简单来说，使用大模型就是在与一个人对话——我对他说什么、他回复了什么，以及我怎么继续跟他对话，这三件事情。当然，这种说法只局限于大语言模型，而不是原生多模态模型。当原生多模态模型能够支持输入和输出皆为多模态时，这种交互方式就会变成：我与一个人进行面对面的对谈，他能见我所见，听我所言。
首先是围绕输入，我说了什么。之前的 Prompt Engineering、Context Engineering、Memory、RAG，都是在做这件事：帮用户输入的内容或用户的需求，更好地以某种格式整理起来，向 LLMs 去做请求。在这期间也限制、规定了 Agent 输出的 Token 的格式、内容等。因为大语言模型的注意力机制，使得输入就像调酒一样——你输入什么，在概率统计上就会获得什么。
再聊聊承接，LLM回复了什么，我们怎么继续对话。
Agent 输出了 Token，第一点是展示数据。我们如果从人类如何使用 Token 的角度对 Token 进行分类，可以得到几个类别，例如代码、对话、文章、表格、思维导图等，以及通过各类格式承载的数据，如 JSON 格式。但本质上，它们都是一类文字符号，最基本的要求就是展示这些数据，我们很多产品最基本的功能，就是获取 AI 返回的内容，并以人类阅读友好的格式来展现。
而如果是 JSON 格式的数据，一般意味着还需要承接并使用这部分数据，因为当要求输出 JSON 格式的时候，通常需要满足的需求场景便是更为复杂的任务。尤其是当输出的 JSON 是为了调用第三方的能力或服务时，例如搜索查询、操作浏览器、从高德地图服务中获取距离和地址相关信息等。当然，还有一种特殊的工具，就是大语言模型输出 Token 去调用另一个大语言模型，或者另一些大语言模型，以此套娃、组合实现任务的交付。
比如 Manus 的 Wide Research，使用一个 Agent 来理解用户需求、澄清用户需求，然后划分不同的研究方向，各自去调用新的 Agent 来批量搜索、总结；再调用一个 Agent 来编写内容大纲；再调用一个 Agent 来编写文章的主要内容，通过接收前面各个子 Agent 搜索和总结的结果来编写最终的研究报告。如果其中涉及数据、图文展示，可以调用 Coding 或生图的能力，将可视化的部分插入文章正文，那么这里面就有一个总体的可视化展示 Agent。
这中Agent涉及3个东西：第一个是 Agent 架构，第二个是工具，第三个是架构之外起润滑剂作用的逻辑代码——叫什么？叫 Context Engineering 合适吗？不合适。那叫什么？
这部分逻辑代码的作用简单概括就是，它不仅仅是把上下文进行传递、任务进行下发串联等内容，它还包含了例如搜索内容过长怎么控制、接口能力请求时怎么转发、当 Wide Search 多个任务并行时怎么支持，以及搜索过程中的长度、深度怎么控制。也不可能让 Agent 无数次地尝试搜索、总结、再返回结果。那我们怎么把控这整个的节奏，什么时候停止行动？
每个 Agent 都是有架构的，有架构就隐隐说明了 LLM 目前的能力受限于注意力机制，而不得不拆分出“职能范围”。推理过程是：注意力机制 → 上下文窗口有限 / 长文本效果下降 → 单次调用能力有限 → 复杂任务需要被拆解成多次调用 → 多次调用需要被组织和编排 → 因此出现了 Agent 架构（多节点、多 Agent、工具调用等）。而架构和前述的润滑剂工程是明显不一样的：前者是对 LLM 的能力划分，后者是在于怎么承接 Token 的流转，比如搜索结果过长怎么格式化、子 Agent 总结完内容如何传递给 main Agent等。有此可见，有一部分工程工作无法命名，有实无名则罔。
以上讲完了基础的 LLM 交互以及这个过程中涉及到的工程问题，接下来我想对 Harness 的范围进行一个分类和定义。
用Harness 是因为目前这个词很合适，而不是说它会一直用下去。这个词的意象，和我们想要借助 AI 来满足需求、更好地满足需求所要求的方式是一致的。这个意象是：我们怎么驾驭一匹马？我们怎么利用一匹马？借助工具 Harness。我们也可以把马改成牛马。所以打造Agent，就会在实施Harness Engineering。那么广义的Harness工程主要包含以下几个方面：
1.
输入端的上下文管理
包含提示词、上下文请求体、知识库/记忆存取、工具的暴露和调用等，涉及到我们曾经用到过的名词：Prompt Engineering、Context Engineering、RAG、Tool Call、MCP、Skill
2.
执行端
包含 Agent 架构、Agent Harness（狭义）和 Agent Tools
3.
评测工程
研究如何对 Agent 这种具有复杂性、不可预测性的大语言模型进行评测的工作
而为什么要借助工具 Harness？这里的前提是，使用工具的对象是有缺陷、有需求的。这个对象包含：一、大语言模型；二、人类或其他（如边牧）。
大语言模型的缺陷有：幻觉、因为注意力机制带来的注意力涣散问题、上下文窗口的限制、交互方式缺少 Agency 主动性（AI 没有意识也没有心）、无法自进化的缺陷（无法更新知识）。
而人的缺陷和需求有：追求效率，或者说懒——懒得输入更多内容，懒得表达更多内容，懒得去整理更多必要的信息输入给 AI；还有大脑容量的缺陷，无法记忆更多内容；以及大脑带宽的不足，无法处理并行任务，无法接收更多的变量信息；还有能力上的不足但需求很多，比如没办法人人都写代码来完成 PDF 文档的编写和格式转化，没办法通过爬虫接口 API 的方式获取数据。正因为模型和用户都有缺陷、有需求，而两者能力不匹配，所以需要有 Harness 工程来完成撮合。
第二部分 输入端
第一个方面是在输入端的工作。最基础的是 System Prompt 怎么写，接着是上下文中怎么编排——即内容怎么编排。这两点是作为一个 AI 产品经理必须清楚了解的工程问题。当然还有评测，后面我们再讲。System Prompt 我想大家应该很清楚，它的结构应该是什么？比如最经典的就是一开始得说明你的角色是什么、你的技能和职责范围是什么、你拥有的信息是什么、你输出的原则是什么、你输出的格式是什么。把这些问题一一回答，整理成一个文档，放进接口请求体中 Role 为 system 的 content 里，就完成了。
Context
接着是上下文。一个接口请求体里面包含有三种角色——System、Assistant、User，以及 Tool 参数，它们分别代表着四类信息。我们怎么往这四个角色的 Content 字段里塞内容，就意味着我们表达了想要向 AI（LLM）索取、召回的内容。这就像我们想调一杯长岛冰茶，就往里面添加固定的、比例的酒类、果汁类、糖浆等。
System、Assistant、User、Tool 这四类信息，是因为在指令微调中，要让大语言模型能够输出、能够理解。这是在对话过程中产生的训练数据集，最终模型就学会了如何读取这类结构化的信息。
比如 System，我们想给它的是一份整体的行为准则文本。Assistant 是 Agent 自己返回的内容。User 是用户的每一次请求的内容。Tool 是工具说明书，即给模型当前它能够使用的工具和这个工具的使用方式的文本描述，通常是 JSON 格式的文本，定义了函数名、用途、参数 Schema。模型并不会把它当成对话内容，而是当成一套“可调用的能力卡片”。
一个完整的上下文里面，就包含有多个 System、Assistant、User 这三类角色以及 Tool 说明。其中对话上下文拼接的方式普遍是：先接 User、Assistant 作为一个对话轮次，然后将多轮内容拼接在一起，形成一个对话的记忆内容。
下面是一个完整的、包含多轮对话和工具调用的 LLM 交互示例。我们使用 OpenAI Chat Completions API 格式，展示一次“查天气 → 工具调用 → 返回结果 → 再次查询股票 → 最终回答”的过程。
第一次请求：用户问天气，助手决定调用工具
代码块
{
"model": "gpt-4o",
"messages": [
{
"role": "system",
"content": "你是一个乐于助人的助手。你可以使用工具查询天气和股票信息。回复时请保持简洁。"
},
{
"role": "user",
"content": "今天北京天气怎么样？"
}
],
"tools": [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的实时天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，例如：北京"
}
},
"required": ["city"]
}
}
},
{
"type": "function",
"function": {
"name": "get_stock_price",
"description": "获取指定股票代码的实时价格",
"parameters": {
"type": "object",
"properties": {
"symbol": {
"type": "string",
"description": "股票代码，例如：AAPL"
}
},
"required": ["symbol"]
}
}
}
]
}