aboutHarness

Harness的定义

Harness（Agent Harness）可以理解为：

给定一个大语言模型，通过增加工具调用、上下文管理、任务循环、权限控制、记忆、状态管理、评估等基础设施，让LLM从“只能回答问题的模型”变成“能够持续完成任务的智能体”。

简单来说：

LLM负责思考，Harness负责让它真正做事。

传统LLM：

用户问题
   ↓
LLM
   ↓
文本回答

Agent：

用户任务
   ↓
LLM
   ↓
判断下一步做什么
   ↓
调用工具
   ↓
获得工具结果
   ↓
重新交给LLM
   ↓
继续判断
   ↓
……
   ↓
完成任务

而控制这个循环的基础设施，就是Agent Harness。

微软对 Agent Harness 的定义也强调了这一点：Harness负责驱动模型调用与工具调用、管理会话状态和上下文、执行审批策略，并让Agent能够持续推进多步骤任务。

Coding Agent|Browser Agent|Research Agent|Data Agent|DevOps Agent

---

Harness解决什么问题？

单独使用LLM时，模型主要负责：

• 理解用户问题
• 生成文本
• 根据上下文进行推理

但是一个真正的Agent还需要：

• 调用工具
• 读取文件
• 执行代码
• 查询数据库
• 访问网络
• 管理上下文
• 保存任务状态
• 控制权限
• 处理错误
• 继续执行任务
• 判断什么时候应该停止

因此：

Agent ≠ LLM

更加准确的关系是：

Agent
│
├── LLM
│   └── 思考 / 决策
│
├── Tools
│   └── 执行具体操作
│
├── Context
│   └── 保存任务所需的信息
│
├── Memory
│   └── 保存长期信息
│
├── Agent Loop
│   └── 控制“思考 → 行动 → 观察 → 再思考”
│
├── Permission
│   └── 控制Agent能够做什么
│
└── Evaluation
    └── 判断任务是否完成

所以Harness更像是：

Agent的运行时基础设施。

---

Harness的核心流程

一个最简单的Agent Harness可以抽象成：

用户输入
   ↓
Context组装
   ↓
LLM
   ↓
是否需要调用工具？
   ↓
 ┌──────────────┐
 │      是       │
 ↓              │
调用Tool         │
 ↓              │
得到Tool结果     │
 ↓              │
加入Context ─────┘
 ↓
LLM继续推理
 ↓
是否完成？
 ↓
最终Response

核心其实就是一个循环：

while not finished:

    response = llm(context)

    if response.tool_call:
        result = execute_tool(response.tool_call)
        context.append(result)

    else:
        finished = True

因此Agent Harness最核心的部分可以理解为：

Agent Loop

---

Harness的核心组成

1. LLM

LLM是Agent的“大脑”。

主要负责：

• 理解任务
• 分析上下文
• 选择工具
• 制定下一步行动
• 根据工具结果继续推理
• 最终生成结果

例如：

用户：

帮我检查项目中的登录问题，并修复它。

LLM可能决定：

1. 查看项目目录
2. 搜索login相关代码
3. 查看错误日志
4. 修改代码
5. 执行测试
6. 如果测试失败继续修改
7. 最终提交结果

但是LLM本身不能直接完成这些事情。

这就需要Harness。

---

2. Tool

Tool是Agent能够真正执行操作的接口。

例如：

文件系统
├── read_file
├── write_file
└── search_file

终端
├── shell
├── git
└── npm

网络
├── search
├── fetch
└── browser

数据库
├── query
└── update

LLM负责：

决定调用什么工具。

Harness负责：

真正执行工具，并把结果重新交给LLM。

例如：

LLM：

调用 read_file
参数：
path = src/login.ts

Harness：

执行 read_file
        ↓
读取文件
        ↓
返回文件内容
        ↓
加入Context

然后：

LLM
 ↓
分析代码
 ↓
调用write_file
 ↓
修改代码
 ↓
调用shell
 ↓
运行测试

---

3. Agent Loop

Agent Loop是Harness最核心的机制。

传统程序：

A → B → C → D

流程提前确定。

Agent：

A
 ↓
LLM判断
 ↓
B / C / D？
 ↓
执行
 ↓
观察结果
 ↓
LLM重新判断
 ↓
下一步

因此Agent的执行路径不是完全固定的。

一个典型循环可以表示为：

Observe
   ↓
Think
   ↓
Act
   ↓
Observe
   ↓
Think
   ↓
Act
   ↓
……

这也是Agent区别于普通LLM API调用的重要原因。

---

4. Context

Context负责保存Agent当前任务所需要的信息。

例如：

System Prompt
+
User Prompt
+
历史对话
+
工具调用结果
+
文件内容
+
任务状态

最终组成：

Context
   ↓
LLM

Context管理非常重要，因为Agent运行时间越长：

工具调用次数 ↑
对话历史 ↑
文件内容 ↑
Token ↑

如果无限制地保存所有内容，就会导致：

• Token消耗增加
• 推理速度下降
• 上下文窗口不足
• 无关信息干扰模型

因此Harness通常需要：

Context Management

---

5. Context Compaction

当上下文过长时，可以对历史信息进行压缩。

例如原始Context：

用户问题
+
10次工具调用
+
20个文件
+
大量日志
+
历史回答

压缩之后：

任务目标：
修复登录问题

已经完成：
1. 找到login.ts
2. 找到token校验问题
3. 修改了token处理

当前状态：
测试失败

下一步：
检查JWT过期逻辑

也就是：

大量历史信息
       ↓
总结 / 压缩
       ↓
重要状态

这样可以让Agent长时间运行。

---

6. Memory

Context和Memory不是完全相同的东西。

Context

主要保存：

当前任务需要的信息

例如：

当前正在修改：
login.ts

Memory

主要保存：

跨任务、长期需要的信息

例如：

项目使用：
React + TypeScript

测试命令：
bun test

部署环境：
Docker

可以简单理解：

Context
= 当前工作记忆

Memory
= 长期记忆

---

7. Permission

Agent拥有工具以后，就产生了一个非常重要的问题：

Agent到底可以做什么？

例如：

读取文件       ✓
修改代码       ✓
执行测试       ✓
删除文件       ?
执行rm -rf      ✗
生产环境部署   ?

因此Harness通常需要权限控制。

例如：

Read
Write
Execute
Network
Database
Deploy

可以进一步设置：

允许
拒绝
需要人工确认

例如：

Agent：

我要执行：
git push origin main

Harness：

⚠️ 该操作需要人工确认

[允许] [拒绝]

这也是生产环境Agent非常重要的一层。

---

8. Sub-Agent

复杂任务可以拆分给多个Agent。

例如：

主Agent
│
├── Research Agent
│   └── 搜索资料
│
├── Coding Agent
│   └── 修改代码
│
├── Testing Agent
│   └── 执行测试
│
└── Review Agent
    └── 检查代码

最终：

主Agent
   ↓
协调多个Sub-Agent
   ↓
汇总结果
   ↓
完成任务

因此Harness还可以负责：

Agent之间的任务调度与生命周期管理。

---

9. Hooks

Hooks可以理解为：

在Agent执行某些关键动作之前或之后自动执行额外逻辑。

例如：

Agent开始执行
      ↓
Before Hook
      ↓
调用LLM
      ↓
Tool执行
      ↓
After Hook

可以用于：

• 日志记录
• 权限检查
• Token统计
• 安全检查
• 自动测试
• 审计
• 结果评估

---

10. MCP

MCP（Model Context Protocol）可以作为Agent连接外部工具和数据源的一种标准化方式。

例如：

Agent
  ↓
Harness
  ↓
MCP
  ├── GitHub
  ├── Notion
  ├── Database
  ├── Browser
  └── 文件系统

这样Agent不需要针对每个工具重新设计一套调用方式。

---

Harness与Agent、LLM的关系

可以这样理解：

概念	主要职责
LLM	思考、推理、决策
Tool	执行具体操作
Agent	利用LLM和Tool完成任务
Harness	管理Agent运行所需的整个运行环境
MCP	标准化Agent与外部工具/数据源之间的连接
Memory	保存长期信息
Context	保存当前任务信息

因此：

            Agent
              │
    ┌─────────┴─────────┐
    │                   │
   LLM                Tools
    │                   │
    └─────────┬─────────┘
              │
           Harness
              │
   ┌──────────┼──────────┐
   │          │          │
Context     Memory    Permission
   │          │          │
   └──────────┼──────────┘
              │
             MCP
              │
   ┌──────────┼──────────┐
 GitHub     Notion     Database

---

Harness的典型应用

1. Coding Agent

例如：

用户：

帮我修复这个Bug。

Harness负责：

读取代码
 ↓
搜索相关文件
 ↓
修改代码
 ↓
运行测试
 ↓
分析错误
 ↓
再次修改
 ↓
再次测试
 ↓
完成

---

2. Research Agent

用户：

研究RAG的最新技术。

Agent可以：

搜索论文
 ↓
读取论文
 ↓
提取信息
 ↓
比较不同方法
 ↓
整理结果
 ↓
生成报告

---

3. DevOps Agent

例如：

检查生产环境服务状态

Agent：

查询监控
 ↓
查看日志
 ↓
分析异常
 ↓
检查部署
 ↓
执行修复
 ↓
重新检查

企业平台也已经开始把AI Agent直接作为软件交付Pipeline中的步骤，使Agent能够参与构建、测试、部署、故障处理等流程，并通过Pipeline和平台治理进行控制。

---

Harness的核心价值

传统：

LLM
 ↓
回答问题

Agent：

LLM
 ↓
Tool
 ↓
结果
 ↓
LLM
 ↓
Tool
 ↓
结果
 ↓
……

Harness：

┌──────────────────────────────┐
│          Agent Harness       │
│                              │
│  Context                     │
│  Memory                      │
│  Agent Loop                  │
│  Tool Management             │
│  Permission                  │
│  Sub-Agent                   │
│  Hooks                       │
│  Evaluation                  │
│  MCP                         │
│                              │
└──────────────┬───────────────┘
               ↓
              LLM

因此可以把Harness理解成：

让LLM能够稳定、持续、安全地执行复杂任务的一套运行时基础设施。

---

Harness与普通工作流的区别

传统Workflow：

A → B → C → D

流程由开发者提前确定。

Agent Harness：

A
 ↓
LLM判断
 ↓
选择B/C/D
 ↓
执行
 ↓
根据结果重新判断
 ↓
下一步

因此：

Workflow强调预定义流程。

Agent Harness强调动态决策 + 工具执行 + 状态循环。

两者也可以结合：

Workflow
   ↓
Agent
   ↓
Harness
   ↓
Tools

---

Harness的本质

如果只记住一句话：

LLM负责“想”，Tool负责“做”，Harness负责“让整个Agent持续运行起来”。

进一步可以理解为：

LLM
= 大脑

Tools
= 手脚

Memory
= 记忆

Context
= 工作记忆

Harness
= 神经系统 + 执行环境

所以在Agent系统中，Harness并不是一个单独的模型，而是一层运行时基础设施（Runtime Infrastructure）。