Agent Harness 正在成为 AI Agent 的新基础设施：从 Pi、Codex 到 DeepSeek Harness

发布于 · 3,368 字 · 约 8 分钟#AI Agent#Agent Harness#Coding Agent
Agent Harness 正在成为 AI Agent 的新基础设施：从 Pi、Codex 到 DeepSeek Harness 封面图
  • 探索 Agent Harness 作为 AI Agent 新基础设施
  • Agent Harness 连接 LLM 与真实计算环境
  • Agent Harness 与 Agent Framework、Coding Agent 区别
  • Agent Harness 核心架构与模块组成
  • Agent Harness 在 2026 年成为竞争焦点

大家好，我是若风。

最近一段时间，我越来越频繁地看到一个词：Agent Harness。

OpenAI 有 Codex，Anthropic 有 Claude Code，Google 有 Gemini CLI，DeepSeek 直接发布了 DeepSeek Harness，MiniMax 也开源了 MiniMax Code。除此之外，还有 Pi、Goose、OpenCode、Qwen Code、Mistral Vibe 等一批项目。

如果只从产品表面看，它们似乎都是“能在终端里帮你写代码的 AI”。

但如果继续往下拆，就会发现真正重要的并不是那个 CLI，而是 CLI 下面这一层：

模型如何获得上下文、调用工具、执行任务、管理状态、控制权限，并持续运行。

这层基础设施，就是 Agent Harness。

这篇文章想系统回答几个问题：

  1. Agent Harness 到底是什么？
  2. 它和普通 Agent Framework、Coding Agent 有什么区别？
  3. 一个现代 Agent Harness 通常由哪些模块组成？
  4. Pi、Codex、Claude Code、DeepSeek Harness 等项目分别在做什么？
  5. 为什么到了 2026 年，Agent 的竞争开始从“谁的模型更强”转向“谁的 Harness 更强”？
  6. 如果今天自己做一个 Agent Runtime，哪些设计已经逐渐成为行业共识？

一、先定义：什么是 Agent Harness？

“Harness” 原本就有“把某个能力接入到一个可控制运行环境中”的意思。

放到 AI Agent 领域，可以把 Agent Harness 理解成：

连接 LLM 与真实计算环境的一层 Agent Runtime。

它负责把一个只能“生成文本”的模型，变成一个可以：

  • 读取文件
  • 修改代码
  • 执行 Shell
  • 调用 API
  • 使用浏览器
  • 调用 MCP
  • 管理上下文
  • 保存 Session
  • 使用 Skills
  • 创建 Subagent
  • 申请权限
  • 运行长任务

的真正 Agent。

可以先看一个最简单的分层：

User
  │
  ▼
Agent UI
CLI / IDE / Web / Desktop
  │
  ▼
Agent Harness
  ├── Agent Loop
  ├── Context
  ├── State
  ├── Tools
  ├── Skills
  ├── Subagents
  ├── Permission
  ├── Sandbox
  └── Telemetry
  │
  ▼
Model Provider
OpenAI / Anthropic / Gemini / DeepSeek / Qwen / Local Model

LLM 本身只负责推理和生成。

真正让它能够“做事”的，是 Harness。

如果你只想先抓主线，可以先看下面这张图。

从模型能力到可运行 Agent 的关系：Harness 负责把工具、状态、上下文与执行环境组织起来。
从模型能力到可运行 Agent 的关系：Harness 负责把工具、状态、上下文与执行环境组织起来。

图里的意思其实很简单：模型提供思考能力，Framework 提供搭建方法，而 Harness 将它们组织为可持续运行、能调用真实工具的 Agent Runtime。

二、Agent、Agent Framework、Agent Harness 有什么区别？

这几个词现在经常混在一起使用。

我的理解是，它们关注的层次不同。

1. Agent

Agent 是最终运行出来的“智能体”。

比如：

  • Claude Code
  • Codex CLI
  • Gemini CLI
  • OpenCode
  • Pi Coding Agent

它们都是最终用户可以直接交互的 Agent 产品。

2. Agent Framework

Agent Framework 更关注“开发 Agent”。

例如早期常见的：

  • LangChain
  • LangGraph
  • AutoGen
  • CrewAI

你会在自己的业务代码中引入它们：

npm install xxx
pip install xxx

然后自己编排 Agent。

Framework 更像：

SDK / Library。

3. Agent Harness

Harness 更接近：

Runtime + Execution Environment。

它不仅定义“怎么调用模型”，还会管理：

Agent Loop
Context
Tool Execution
Filesystem
Shell
Session
Permission
Sandbox
Plugin
Skill
Subagent
Telemetry
Provider

所以一个非常粗略的区别可以写成：

层级关注点
ModelThinking
Agent FrameworkBuild Agent
Agent HarnessRun Agent
Agent ProductUse Agent

这也是为什么今天越来越多项目开始从“Agent Framework”转向“Agent Runtime / Harness”。

三、一个现代 Agent Harness 的核心架构

虽然各家公司实现差异很大，但看过几套项目之后，会发现架构正在快速收敛。

可以抽象成下面这个结构：

                    Agent Harness
                         │
        ┌────────────────┼────────────────┐
        │                │                │
   Agent Loop         Context          Session
        │
   ┌────┼────┐
   │    │    │
 Tools Skills Agents
   │
   ├── Shell
   ├── Filesystem
   ├── Git
   ├── Browser
   ├── Search
   ├── MCP
   └── Custom Tools
        │
        ▼
 Permission / Sandbox
        │
        ▼
 Provider Abstraction
        │
 ┌──────┼──────┬────────┬────────┐
OpenAI Claude Gemini DeepSeek Qwen

先记住这个结构，再看后面的细节。

现代 Agent Harness 的分层：上层界面和运行时核心，经权限与沙箱边界连接到底层模型提供商。
现代 Agent Harness 的分层：上层界面和运行时核心，经权限与沙箱边界连接到底层模型提供商。

这张图对应后文最重要的一个判断：Agent Loop、Context、Tools 与 Subagent 组成运行时核心，而权限与 Sandbox 不是附属功能，是连接真实环境前必须经过的安全层。

其中几个模块尤其关键。

四、Agent Loop：Harness 的心脏

最核心的其实不是 Tool Calling，而是 Agent Loop。

一个最简单的 Agent Loop 可以写成：

while task_not_finished:

    context = build_context()

    response = model(context)

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

    else:
        return response

表面看很简单。

但真正工程化之后，会迅速出现大量问题：

  • 一个任务最多运行几轮？
  • Tool Call 失败怎么办？
  • 是否 retry？
  • 模型重复调用同一个工具怎么办？
  • 上下文超过 Token Limit 怎么办？
  • 工具执行是否需要用户确认？
  • 子任务是否创建 Subagent？
  • 中途 crash 如何恢复？
  • 长任务怎样 checkpoint？
  • 用户插入新指令怎么办？

所以真正成熟的 Agent Loop 更像：

Observe
  ↓
Plan
  ↓
Reason
  ↓
Act
  ↓
Tool Execution
  ↓
Observe Result
  ↓
Update State
  ↓
Continue / Stop / Delegate

这也是 Harness 与一个简单的 “LLM + Tool Calling Demo” 最大的区别。

五、Tool System：模型连接真实世界的接口

Agent 本质上并不能直接操作你的电脑。

模型只能输出：

{
  "tool": "shell",
  "arguments": {
    "command": "npm test"
  }
}

真正执行命令的是 Harness。

因此 Harness 必须提供 Tool Runtime。

典型工具包括：

FileSystem
├── read
├── write
├── edit
└── search

Shell
├── exec
├── process
└── terminal

Git
├── diff
├── status
├── commit
└── branch

Network
├── HTTP
├── Search
└── Browser

External
├── MCP
├── API
└── Plugin

这里会直接引出另一个非常重要的问题：权限。

六、Permission 与 Sandbox：Agent 真正进入生产环境的门槛

Agent 一旦拥有 Shell，就意味着它理论上可以：

rm -rf
git push
curl xxx
cat ~/.ssh/*
读取环境变量
访问生产数据库

所以今天成熟 Agent Harness 几乎都绕不开：

Permission
Sandbox
Approval
Policy
Isolation

一种常见模型是：

Model
  │
  ▼
Tool Call
  │
  ▼
Policy Engine
  │
  ├── Allow
  │
  ├── Ask User
  │
  └── Deny
  │
  ▼
Sandbox
  │
  ▼
Operating System

Codex 在这方面就非常有代表性。

而 Pi 则走了另一条路线。

Pi 自己明确说明：

默认情况下，它使用启动 Pi 的用户和进程权限。

也就是说 Pi 不试图把所有安全策略都内置。

如果需要更强隔离，可以使用：

  • Docker
  • OpenShell
  • Gondolin micro-VM

这其实体现了两种不同设计哲学。

一种是：

Harness 自己负责安全边界。

另一种是：

Harness 保持轻量，把安全隔离交给基础设施层。

两种方案没有绝对对错，取决于使用场景。

七、Context Management：现在 Agent 的真正瓶颈之一

Agent 的能力并不只取决于模型聪不聪明。

很多时候决定结果的是：

Harness 给模型看了什么。

例如一个 Coding Agent 要完成任务，可能需要：

System Prompt
User Prompt
AGENTS.md
Project Files
Git Diff
Tool Results
Terminal Output
Previous Messages
Memory
Skills
Subagent Result

问题是上下文不是无限的。

所以 Harness 需要做：

  • Context Selection
  • Context Compression
  • Summarization
  • Truncation
  • Retrieval
  • Cache
  • Working Memory

这其实正在成为 Agent Harness 最有技术含量的部分之一。

一个简单策略是：

Recent Messages
      +
Relevant Files
      +
Current Task
      +
Tool Results
      +
Summary of Old Context

真正做得好的 Harness，并不是“把整个 repo 塞进模型”。

而是：

每一轮只给模型最有价值的信息。

八、Skills 正在成为 Agent 的新扩展层

2025 年之后，一个明显趋势是 Skills。

Skill 和 Tool 不完全一样。

Tool 更偏：

原子能力。

例如：

read_file
write_file
shell
browser

Skill 更像：

一套完成复杂任务的方法、规则和工作流。

例如：

Deploy Application Skill
Code Review Skill
Create PPT Skill
Analyze Logs Skill
Release iOS Skill

一个 Skill 可能同时包含：

Instructions
+
Tools
+
Scripts
+
Templates
+
Domain Knowledge

所以 Agent 的扩展模型正在从：

Agent + Tools

变成：

Agent
  ├── Tools
  ├── Skills
  ├── MCP
  └── Subagents

这也是未来 Harness 很重要的一层。

九、Subagent：从单 Agent 转向动态任务分解

现在越来越多 Coding Agent 开始支持 Subagent。

它解决的是一个非常现实的问题：

一个 Context 不适合处理所有任务。

例如：

Main Agent
    │
    ├── Research Agent
    │
    ├── Code Agent
    │
    ├── Test Agent
    │
    └── Review Agent

主 Agent 负责：

Plan
Delegate
Merge
Decide

子 Agent 则拥有独立：

Context
Prompt
Tools
Token Budget

这样可以显著降低 Context 污染。

我认为未来 Harness 的重要能力之一，就是：

Dynamic Agent Runtime。

也就是 Agent 不是预先写死，而是运行时动态创建。

十、当前值得关注的开源 Agent Harness / Coding Agent

下面这张表是我截至 2026 年 9 月 20 日整理的一个快照。

Star 会持续变化，所以这里只用于观察当前生态规模，不代表项目质量排序。

公司 / 团队项目GitHub Star（2026-09-20）定位
DeepSeekDeepSeek Harness230k+插件化 Agent Harness
AnomalyOpenCode208k+开源 Coding Agent
AnthropicClaude Code146k+Terminal Coding Agent
OpenAICodex125k+Coding Agent Runtime
Earendil WorksPi107k+Agent Harness + Coding Agent
GoogleGemini CLI107k+Terminal AI Agent
Goose / AAIFGoose54k+Extensible Agent
Alibaba / QwenQwen Code27k+Terminal Coding Agent
GitHubCopilot CLI11k+Terminal Coding Agent
Mistral AIMistral Vibe4.9k+Minimal Coding Agent
MiniMaxMiniMax Code1.2k+Terminal Coding Agent

这里面我认为最值得单独研究 Harness 架构的是：

DeepSeek Harness
Pi
Codex
OpenCode
Goose

十一、Pi：非常“纯”的 Agent Harness 设计

最近我比较关注的一个项目是 Pi。

GitHub：

https://github.com/earendil-works/pi

Pi 的 README 直接写的是：

Pi Agent Harness

它不是单纯提供一个 Coding CLI，而是把整个系统拆成多个独立 Package。

目前核心结构包括：

Pi
│
├── pi-ai
│   └── Unified Multi-provider LLM API
│
├── pi-agent-core
│   ├── Agent Runtime
│   ├── Tool Calling
│   └── State Management
│
├── pi-durable
│   ├── Conversation Runtime
│   ├── Task Runtime
│   └── Document Runtime
│
├── pi-coding-agent
│   └── Interactive Coding Agent CLI
│
├── pi-tui
│   └── Terminal UI
│
├── pi-telemetry
│   └── Vendor-neutral Telemetry
│
└── chord
    ├── Services
    ├── RPC
    ├── Replicated State
    └── Plugins

这个设计很有意思。

因为它没有把“Agent”做成一个巨大的 CLI 应用，而是在明确分离：

Model Layer
Runtime Layer
Durable Layer
UI Layer
Application Layer

从架构研究角度，我认为 Pi 很值得看。

它更像：

Agent Runtime Toolkit + Reference Coding Agent。

而不是单纯 Claude Code 的开源替代品。

十二、DeepSeek Harness：Everything is a Plugin

DeepSeek Harness 是另一个非常值得观察的方向。

它最核心的理念就是：

Everything is a Plugin.

这意味着很多 Harness 能力不再写死在 Core 中。

可以想象成：

Harness Core
    │
    ├── Plugin: Tool
    ├── Plugin: Model
    ├── Plugin: Context
    ├── Plugin: Skill
    ├── Plugin: Runtime
    └── Plugin: Integration

这样做的好处非常明显：

  • Core 很小
  • 能力可以替换
  • Provider 可以替换
  • Tool 可以动态扩展
  • Runtime 可以组合

从软件工程角度，这其实是在解决 Agent 系统快速膨胀的问题。

因为 Agent 一旦发展起来，模块数量会非常快地增加。

如果所有能力都直接进入 Core：

AgentCore
  + Browser
  + Git
  + Search
  + Memory
  + MCP
  + Slack
  + GitHub
  + Jira
  + Docker
  + ...

最终一定会变成巨石。

Plugin Architecture 是很自然的下一步。

十三、Codex：Harness 与操作系统之间的边界

Codex 则更强调：

Agent
+
Execution
+
Sandbox
+
Approval

这使得它非常接近一个：

AI Native Process Runtime。

传统程序：

User
  ↓
Application
  ↓
OS

Agent 时代：

User
  ↓
Agent
  ↓
Agent Runtime
  ↓
Sandbox / Policy
  ↓
OS

Harness 开始成为模型和操作系统之间的一层。

这也是我认为 Agent Harness 长期最有意思的地方。

它可能不只是“AI Coding 的一个组件”。

未来它很可能变成：

AI Agent 的操作系统层。

十四、OpenCode：Multi-provider 是非常重要的方向

OpenCode 另一个值得关注的点是：

Provider Neutral。

如果 Harness 强绑定某一个模型：

Agent
  ↓
Claude

那么 Agent 的能力上限、成本、可用性全部受到一个 Provider 约束。

更通用的设计应该是：

Agent Harness
      │
      ▼
Provider Interface
      │
 ┌────┼────┬─────┬──────┐
 GPT Claude Gemini Qwen DeepSeek

这样 Harness 才真正成为独立基础设施。

Pi 的 pi-ai 本质上也在做同样的事情。

我非常看好这个方向。

十五、为什么说 Harness 正在变得和模型一样重要？

假设有两个产品都使用同一个模型。

比如：

Model: GPT-X

Agent A：

简单 Prompt
+
Shell

Agent B：

Context Engine
+
Code Search
+
Memory
+
Skills
+
MCP
+
Subagents
+
Sandbox
+
Checkpoint
+
Retry
+
Tool Policy

最后表现可能完全不像同一个模型。

也就是说：

Agent Capability
≈
Model Capability
×
Harness Capability
×
Context Quality
×
Tool Quality

甚至在很多真实任务中：

Harness 的影响可能比换一个模型还大。

因为模型本身并不知道：

  • 项目结构是什么
  • 哪些文件重要
  • 上一步执行结果是什么
  • 什么命令允许运行
  • 哪个工具最适合
  • 什么信息应该保留

这些都是 Harness 决定的。

十六、Agent Harness 正在出现架构收敛

目前观察几个主流项目后，我觉得已经能看到非常明显的收敛趋势。

未来主流 Harness 基本都会包含：

Agent Runtime
├── Agent Loop
├── State
├── Session
└── Event

Context Engine
├── Retrieval
├── Compression
├── Memory
└── Cache

Tool Runtime
├── FS
├── Shell
├── Browser
├── Git
└── MCP

Extension
├── Skills
├── Plugins
├── Hooks
└── Subagents

Security
├── Permission
├── Approval
├── Sandbox
└── Policy

Provider
├── OpenAI
├── Anthropic
├── Gemini
├── DeepSeek
└── Local

Observability
├── Log
├── Trace
├── Metrics
└── Replay

如果今天重新设计一个 Agent 平台，我会直接从这个结构开始。

十七、未来我更关注的五个方向

1. Harness 会不会替代 Agent Framework？

我认为不会完全替代。

但 Framework 的地位可能会下降。

未来更可能是：

Agent Application
      ↓
Agent SDK
      ↓
Agent Harness
      ↓
Model + OS

Framework 从 Runtime 逐渐变成 SDK。

2. Agent Harness 会不会成为新的“浏览器内核”？

我觉得这个类比很有意思。

现在 AI Agent 产品很多：

Coding Agent
Research Agent
Browser Agent
Office Agent
Data Agent
DevOps Agent

但底层其实大量能力重复：

Tool
Context
Memory
Sandbox
MCP
Permission
Session

未来完全可能出现：

Chrome / Safari
        ↓
Browser Engine

各种 Agent
        ↓
Agent Harness

产品不同，底层 Runtime 相同。

3. Skills 会成为 Agent 时代的 Package 吗？

我非常看好这个方向。

传统软件：

npm package
pip package

Agent：

Skill
Plugin
MCP

未来可能出现非常成熟的：

Agent Capability Marketplace。

4. Sandbox 会成为 Harness 的标准能力

当 Agent 从“写代码”进入：

  • 运维
  • 财务
  • 企业系统
  • 浏览器
  • 云资源

之后，安全问题会快速放大。

未来成熟 Harness 大概率都会提供：

Capability-based Permission
+
Sandbox
+
Audit Log
+
Approval

5. Durable Agent 会越来越重要

现在很多 Agent 仍然是：

Run
→
Finish
→
Exit

未来会越来越多：

Run
→
Sleep
→
Wake
→
Continue
→
Observe
→
Act

这需要：

  • Durable State
  • Scheduler
  • Event
  • Trigger
  • Checkpoint

也就是说 Agent 会逐渐从：

Chatbot

变成：

Long-running Process。

Pi 中的 pi-durable 就是一个很值得关注的信号。

十八、如果今天自己设计一个 Agent Harness

如果让我现在从零设计，我会先做六层。

┌─────────────────────────────┐
│        Application          │
│ Coding / Research / DevOps  │
├─────────────────────────────┤
│        Agent Layer          │
│ Loop / Subagent / Skill     │
├─────────────────────────────┤
│        Context Layer        │
│ Memory / Retrieval / Cache  │
├─────────────────────────────┤
│         Tool Layer          │
│ Shell / FS / MCP / Browser  │
├─────────────────────────────┤
│       Runtime Layer         │
│ State / Session / Durable   │
├─────────────────────────────┤
│       Security Layer        │
│ Sandbox / Policy / Approval │
├─────────────────────────────┤
│       Provider Layer        │
│ GPT / Claude / Gemini ...   │
└─────────────────────────────┘

并且坚持几个原则：

Core 尽可能小

不要把所有能力写进核心。

Everything Pluggable

Model、Tool、Skill、Storage、Sandbox 都应该可以替换。

Event Driven

Agent 每一步最好都变成事件。

例如：

agent.started
model.called
tool.requested
tool.completed
agent.delegated
context.compacted
agent.finished

这样才能做：

  • Telemetry
  • Replay
  • Debug
  • Audit

Provider Neutral

Harness 不应该依赖单一模型厂商。

Security First

权限系统不能最后补。

如果你更习惯按场景做判断，这张图会更直观。

Agent Harness 的设计取舍：从轻量个人编码到企业安全、多模型平台与长任务运行，对应不同的架构侧重点。
Agent Harness 的设计取舍：从轻量个人编码到企业安全、多模型平台与长任务运行，对应不同的架构侧重点。

图中的四条路线对应的并不是互斥产品类型，而是不同场景的优先级：个人工具偏向小核心，企业工作流先划安全边界，多模型平台强调 Provider Abstraction，长任务则必须把 State 和 Durable 能力放到前面。

十九、最后

过去两年，我们讨论 AI Agent 时，焦点经常是：

哪个模型更聪明？

但我越来越觉得，下一阶段更值得关注的问题是：

谁能把模型真正可靠地运行起来？

模型负责 Intelligence。

Harness 负责：

Execution
Context
Tools
State
Security
Extensions
Reliability

如果把模型比作 CPU，那么 Agent Harness 越来越像：

Operating System + Runtime。

这也是为什么最近 DeepSeek、OpenAI、Anthropic、Google、MiniMax，以及 Pi、Goose、OpenCode 这些项目都在不同程度上走向同一个方向。

未来真正成熟的 Agent 产品，很可能并不会从零重新实现这些基础设施。

它们会建立在某一种成熟 Harness 之上。

所以如果你现在正在研究 AI Agent，我认为除了关注模型、Prompt、MCP 之外，还应该开始认真研究：

Agent Harness。

因为这里很可能就是下一轮 Agent 基础设施竞争的核心战场。

相关项目

评论互动

© 2026 王若风的技术博客 · Powered by Astro