🔶 Agent 不等于模型
英文标题：🔶 Agent Is Not the Model
文章厘清了 Agent、模型、推理服务与 Harness 之间常被混用的概念：完整的 Agent 系统由 Harness、推理服务和模型三层组成。模型负责将输入 token 转换为输出 token，推理服务负责托管运行与计费，而 Harness 则负责上下文组装、工具调用和与外部世界交互。Claude Desktop、Claude CLI、Cursor、ChatGPT 等产品的差异，很大程度上来自各自不同的 Harness，而非仅仅是底层模型。对开发者而言，准确定位问题所在层级，有助于更高效地优化回答质量、工具调用、延迟与成本。
中文
我经常听到人们把 agent 和 model 两个词混用，将 Claude 称作其中任意一种。因此，我认为有必要快速说明一下我们在这里使用的术语，以便进行更精确的讨论。
让我们先从一张展示未来方向的图开始。
Agent 系统
Harness 推理服务 模型
一个 Agent 系统由多个层级构成。其核心是一个模型，例如 Sonnet、Opus 或 Gemini。这些模型在海量文本和数据上训练而成；归根结底，它们本质上是一大组以特定方式连接起来的浮点数。
前沿模型的计算成本过高，以至于大多数人无法在本地以完整规模运行它们。它们需要的 RAM 远超大多数本地设备所具备的容量。因此，我们需要在别处运行它们。这个地方就是推理服务，例如 AWS Bedrock 或 Anthropic 的 API。推理服务接收你的 API 调用，将其输入模型，并在使用过程中追踪计费。
该服务会在推理引擎中运行模型，但它本身依然相当基础：文本输入，文本输出。可以想想 ChatGPT 刚推出时的工作方式。为你提供便捷 API 交互方式的那一层，即交互层，被称为 Harness。最简单的 Harness 只是一个轻量级封装。你可能熟悉的其他 Harness 包括 Claude Desktop 或 Claude CLI。
而这正是事情开始变得有趣的地方。MCP 和 Skills 之类的功能？它们主要属于 Harness 层。模型本身并不天然知道 MCP 服务器或 Skill 的存在；由 Harness 决定向模型暴露哪些上下文和工具。
因此，将这些组合起来看，一个Agent 系统就是：一个 Harness，配备一组用于处理输入的工具和逻辑；它调用一个推理服务；而推理服务运行一个模型。仅此而已，这就是完整技术栈。
现实世界中的示例
以下是一些你可能正在使用的常见工具，其技术栈的拆分方式。
| Agent 系统 | Harness | 推理服务 | 模型 |
|---|---|---|---|
| Claude Desktop | Claude Desktop（UI + MCP + 本地逻辑） | Anthropic 的推理服务 | Sonnet / Opus / Haiku |
| Claude CLI | Claude CLI（工具解析 + 文件 I/O） | Anthropic 的推理服务 | Sonnet / Opus / Haiku |
| Cursor | Cursor 编辑器（上下文组装 + 工具路由） | Cursor 的推理层（多种提供商） | Sonnet / GPT / Gemini / 等 |
| ChatGPT | ChatGPT UI（历史记录 + 编排） | OpenAI 的推理服务 | GPT 模型 |
| 使用 LangChain 构建的自定义 Agent | 你的 LangChain 代码（提示词模板 + 工具定义） | 你选择的提供商（Bedrock、OpenAI 等） | 你选择的模型 |
请注意其中的规律。Harness 是你的逻辑所在之处。推理服务是托管并运行模型的层。模型则是生成文本的数学实体。同一个模型，例如 Sonnet，可以被用于多个采用完全不同 Harness 的 Agent 系统中；由于 Harness 会塑造输入并解释输出，它们的行为也会不同。
假设我们正在建造一栋房子。工地上有一支施工队。他们拿着蓝图、订购材料、操作设备，并决定施工顺序。他们是唯一能够真正接触地面的人：浇筑混凝土、钉钉子，诸如此类。但如果遇到问题、需要更多智力支持，他们会联系一位建筑师。不过，他们无法直接与建筑师交流，必须通过雇用建筑师的事务所。事务所负责安排日程和计费。而建筑师非常有原则：你给它一份任务简报，它只会还给你纸面设计图，仅此而已。
施工队就是 Harness。它是能够真正接触外部世界、并把建筑师设计图转化为行动的部分。事务所是推理服务，是负责处理流程和成本的入口。建筑师则是模型：纯粹、受限，并在其狭窄职责上表现卓越。
因此，当你使用 Claude CLI 之类的工具时，CLI 就是 Harness。它使用 Anthropic 的推理服务，而该服务运行其 Sonnet 和 Opus 模型。一个有趣的推论是：随着模型变得更聪明，当今的一些 Harness 逻辑，例如 Skills 或 MCP，可能会变得不那么有用。我们现在构建 Harness 的方式，未必能经得起时间考验。
核心结论
让我们明确这些术语。
- 模型 - 将输入 token 转换为输出 token 的数学函数。
- 推理服务 - 运行模型并追踪用量的托管服务。
- Harness - 塑造输入、解释输出并与外部世界交互的逻辑层。
- Agent 系统 - 上述三者协同工作形成的整体。
当我们说“我的模型在做这件事或那件事”时，通常实际指的是 Harness 正在编排什么。模型本身只是这些难以理解的数学对象，供我们调用。
而这种区分很重要。因为当问题出现，或我们希望改进某些能力时，需要知道该去哪里寻找原因。模型是否给出了糟糕答案？也许它需要 Harness 提供更好的上下文。它是否太慢或太昂贵？问题可能出在推理服务或底层计算资源。它是否没有正确使用工具？Harness 很可能错误地格式化了工具，或没有正确解析响应。
当你能说出问题属于哪一层，你就能修复那一层。这正是精确表达的全部意义。它并不是为了吹毛求疵，而是为了能够更快、更有效地改进系统。
| 症状 | 可能所属层级 |
|---|---|
| 推理能力 / 知识表现差 | 模型，或由 Harness 提供的上下文 |
| 缺少上下文 | Harness |
| 工具不可用 | Harness / 工具集成 |
| 工具调用格式错误 | Harness 或模型 |
| 工具执行错误 | 工具 / Harness |
| 推理缓慢 | 推理基础设施 |
| 成本过高 | 模型选择 / 推理服务 |
| 同一模型表现不同 | Harness / 上下文 / 工具 |
English / 原文
I often hear people use the words agent and model interchangeably, referring to Claude as either one. So I thought it would be useful to write a quick reference on the terminology we use here, to help us have more precise conversations.
Let’s start with a graphic that shows where we are headed.
The Agent System
Harness Inference service Model
An agent system is made up of several layers. At its core is a model. Things like Sonnet, Opus, or Gemini. These are trained on vast amounts of text and data, and in the end, they are essentially big collections of floating point numbers wired together in a particular way.
Frontier models are far too computationally expensive for most of us to run locally at full scale. They need way more RAM than most of us have on our local machines. So we need somewhere else to run them. That somewhere is an inference service. Services like AWS Bedrock or Anthropic’s API. The inference service takes your API calls, feeds them into the model, and also tracks pricing as you go.
The service runs the model in an inference engine, but it is still pretty basic. Text in, text out. Think of how ChatGPT worked when it first launched. That interaction layer, the thing that gives you a nice way to talk to the API, is called a harness. In its simplest form, it is just a lightweight wrapper. Other harnesses you might know are Claude Desktop or Claude CLI.
And this is where things get interesting. Features like MCP and Skills? They are primarily part of the harness layer. The model doesn’t inherently know about an MCP server or a Skill; the harness decides what context and tools to expose to it.
So if you put all that together, an agent system is a harness, a set of tools and logic for processing inputs, that calls an inference service, which runs a model. That is it. That is the whole stack.
Real world examples
Here is how the stack breaks down for some common tools you might be using.
| Agent System | Harness | Inference Service | Model |
|---|---|---|---|
| Claude Desktop | Claude Desktop | ||
| (UI + MCP + local logic) | Anthropic’s inference service | Sonnet / Opus / Haiku | |
| Claude CLI | Claude CLI | ||
| (tool parsing + file I/O) | Anthropic’s inference service | Sonnet / Opus / Haiku | |
| Cursor | Cursor editor | ||
| (context assembly + tool routing) | Cursor’s inference layer (various providers) | Sonnet / GPT / Gemini / etc. | |
| ChatGPT | ChatGPT UI | ||
| (history + orchestration) | OpenAI’s inference service | GPT models | |
| Custom agent you build with LangChain | Your LangChain code | ||
| (prompt templates + tool definitions) | Your chosen provider (Bedrock, OpenAI, etc.) | Your chosen model |
Notice the pattern. The harness is where your logic lives. The inference service is the hosted layer that runs the model. The model is the mathematical thing that produces text. The same model, say Sonnet, can be used across multiple agent systems with completely different harnesses, and it will behave differently because the harness is shaping the inputs and interpreting the outputs.
Let’s imagine we are building a house. We have a building crew on site. They take a blueprint, order materials, handle equipment, and decide sequencing. They are the only ones who can actually touch the ground. Pour concrete, hammer nails, that kind of thing. But if something comes up and they need brainpower, they call an architect. They can’t talk to the architect directly, though. They have to go through the firm that employs them. The firm handles scheduling and billing. And the architect is very particular. You give it a brief, it gives you back paper plans. Nothing more.
The crew is the harness. They’re the part that can actually touch the outside world and turn the architect’s plans into actions. The firm is the inference service. The gateway that handles logistics and cost. And the architect is the model. Pure, constrained, and brilliant at its narrow job.
So when you use something like Claude CLI, the CLI is the harness. It uses Anthropic’s inference service, which runs their models, Sonnet and Opus. One interesting implication: as models get smarter, they might make some of today’s harness logic, like Skills or MCP, less useful. The way we build harnesses now might not age well.
The takeaway
Let’s be explicit with our terms.
- Model - the mathematical function that transforms input tokens into output tokens.
- Inference service - the hosted service that runs the model and tracks usage.
- Harness - the logic that shapes inputs, interprets outputs, and touches the outside world.
- Agent system - all three working together.
When we say “my model is doing this or that,” we are usually talking about what the harness is orchestrating. The models themselves are just these inscrutable mathematical objects that we get to call out to.
And that distinction matters. Because if something goes wrong, or if we want to make things better, we need to know where to look. Is the model giving bad answers? Maybe it needs better context from the harness. Is it too slow or too expensive? That is probably the inference service or the compute underneath. Is it not using tools correctly? The harness is probably formatting them wrong or not parsing the responses properly.
When you can name the layer, you can fix the layer. That is the whole point of being precise. It is not about being pedantic. It is about being able to improve things faster and more effectively.
| Symptom | Likely layer |
|---|---|
| Bad reasoning / knowledge | Model or context supplied by harness |
| Missing context | Harness |
| Tool isn’t available | Harness / tool integration |
| Tool call is malformed | Harness or model |
| Tool executes incorrectly | Tool / harness |
| Slow inference | Inference infrastructure |
| High cost | Model choice / inference service |
| Same model behaves differently | Harness / context / tooling |