大模型不是 Agent：智能体究竟是如何运转的？

什么是 Agent

你在 ChatGPT 的网页里打一句话，它回一段话。问天气，它给你天气。让它写首诗，它给你一首诗。到这里为止，你手里的是一个大语言模型（Large Language Model，LLM），一个很会接话的问答机器。

可如果它自己握着键盘鼠标，自己翻仓库里的文件，自己往数据库里写数据，把一个"把项目做完"的任务从头做到尾，情况就变了。人们把这种形态叫做 Agent（智能体）。

2025年2月，一款Agent产品横空出世，它就是Claude Code。上图为它的CLI界面。这个就是一个Agent。

很多人在本地把 Agent 跑通了。模型能回答，能调用一两个工具，看起来挺像回事。可一旦放到真实环境里，让它稳定处理用户一个个请求，问题就全冒出来了。模型偶尔把格式写错，工具偶尔抛异常，流程偶尔卡在一个地方不动。每一样都得有人兜底。

这两个东西之间差了一层外壳。

LLM 只负责一件事，把输入变成输出。它没有手，没有脚，连执行一段代码都做不到，它只能生成文字。Agent 的玩法，是让 LLM 当大脑，外面套一个能真正动手的外围工程系统（Harness）。大模型提供推理能力，Harness 提供除模型权重之外的所有基础设施，把模型那些不可靠的自然语言输出，转成工程上可控的系统行为。分开说就是一句话，Agent 等于一个会想的大脑，加一个会干活的身体。

这篇文章会拆开这层壳，一路往下讲。先看 Harness 由什么组成，再看 Agent 接到任务后怎么运转，接着把工具调用和技能积累这两块讲透。

Harness 基座

Harness 通常分成三个核心层。

Runtime（运行时）。维持模型运转的核心循环，负责提示词的组装、结构化输出的解析，以及异常重试机制。可以把它想成发动机，让模型一圈一圈转下去。

Capabilities（能力层）。赋予 Agent 实际操作环境的能力，包括工具注册表、上下文管理、长期记忆读写。这一层决定 Agent 能摸到什么东西。

Assurance（保障层）。也叫 Eval Harness，它存在于离线开发路径里。批量遍历测试数据集（Goldens），调用 Agent 跑完整任务，收集执行轨迹（Traces），再用评估指标打分，比如准确率、幻觉率、LLM-as-a-judge。没有这一层，Agent 就没法稳定迭代。

想真正学会这套东西，最实在的办法是落到你自己熟悉的工程栈里。用 Python 做测验或复习系统，就抛开高级封装库，手写一个最简的 Runtime Loop，自己处理模型的 JSON 输出和本地业务逻辑的对接。等你亲手撞过一次 JSON 解析报错和无限重试循环，Harness 的价值就彻底清楚了。

运转的四大步骤

有了这层壳，Agent 是怎么从接到任务到交活的？我拿一个真实场景从头到尾走一遍。下面这个场景贯穿全篇。你把一段线性代数笔记丢给 Agent，说"帮我把这段笔记做成 5 道选择题，存进数据库"。

第一步，意图解析与环境隔离

大模型有个天生的毛病。你给它塞进几万字的工具说明书、规则手册和示例，它会看懵，回答开始前言不搭后语。做 Agent 的人管这个叫上下文污染。模型的上下文窗口（一次能同时"看见"的输入长度）是有限的，塞进来的东西越杂，真正要紧的信息就被稀释得越厉害。

所以第一步，Agent 要先弄清楚用户到底想干什么。

这一层判断由一个叫 Router（路由） 的组件完成。它拿到用户的原始请求，分析出意图。这段请求说要"生成测验"，Router 就判定这是"测验生成"任务，立刻去把对应的 技能包（Skill） 搬出来。

Skill 是一个写好的方案包，里面装着这个任务需要的提示词、规则和工具清单。它像一本任务专用的操作手册。Router 把用户请求、这本手册和相关的工具，一起打包。

接着进入环境隔离。Harness 会把模型关进一个"沙箱"里。这个词不是玄学，它指一个被限制住的工作环境。在这个环境里，模型只能看到自己需要的提示词，只能调用被允许的工具，比如数据库写入工具。其他不相关的文件、网络入口、敏感接口，全部被挡在外面。

这么做的道理很朴素。模型是概率机器，输入什么它就顺着什么往下走。给它看得越少，它跑偏的可能就越小。沙箱把"它可能碰到的"压缩到"它必须用到的"，出错的面积一下子小了很多。

到这一步，Agent 完成了感知。它知道了任务是什么，拿到了对应的方案，站在一块干净的工作台上。

第二步，意图识别与工具触发

很多人以为大模型自己会联网、自己会写 SQL。把这句话放回工程里看，就会发现问题。

模型确实会"写"一段 SQL 语句，但那是它生成的文字。它不会真的连上数据库去执行。模型会"提到"某个网页的内容，但那是它训练时见过的记忆，跟实时的互联网是两回事。

所以第二步的核心，是让模型把"想做什么"用机器能读懂的格式交出来。

模型读完 Skill 里的提示词，开始分析手头的任务。它发现要生成 5 道题，得先把笔记里的内容清洗成干净的文本，再套进题目模板，最后存进数据库。它评估出自己需要"写数据库"这个动作。

模型不会直接输出最终答案，也不会假装自己已经把数据存好了。它输出的是一段标准的 JSON 数据包。JSON 是一种结构化的文本格式，用键值对把信息组织起来，机器一眼就能读。这个数据包里写了工具名和参数，比如"调用 write_quiz 工具，参数是这 5 道题的内容"。工程上把这个请求叫 Tool Call Request，也就是一次工具调用请求。

可以把这段 JSON 想成一张填好的工单。模型把工单递给外面的系统，说，我需要有人帮我干这件事。它自己没有手，但它知道自己该要什么。

这一步的实质，是模型完成了决策，把决策翻译成机器可读的请求，交了出去。

第三步，物理拦截与代码执行

模型把工单递出来，接下来接活的是 Harness。

Harness 在模型和真实世界之间守着。它拦截下模型输出的这段 JSON，开始解析里面的工具名和参数。解析完，它要在真实的服务器环境里执行对应的代码。

比如这段 JSON 说"调用 write_quiz 工具"，Harness 就在服务器上真的跑一段 Python 代码，连上数据库，执行 db.execute()，把那 5 道题写进去。或者如果工具要求的是网络请求，它就真的发起一次 HTTP 调用。

这里有一层区分值得看清。模型本身不执行代码，它只生成文字。Harness 拦下它交出的请求，由 Harness 里的代码在服务器上连上数据库、执行写入。模型负责决定做什么，代码负责把它做掉。

代码跑完以后，会有两个可能的结果。要么成功了，数据库返回"写入完成"；要么失败了，抛出一个异常，比如 Exception（程序出错时抛出的错误信号），或者返回"数据格式不合法"。

不管是哪种结果，Harness 都会把它重新打包成一个叫 Observation（观察结果） 的数据，再一次喂回给模型。

这一步的实质，是请求变成了物理动作，真实世界给了回应，回应又被交回给了大脑。

第四步，异常重试与最终交付

到这里，你可能觉得流程已经走完了。其实 Agent 工程里，一半的功夫花在"出了错怎么办"上。

因为模型是概率机器，它第一次生成的 JSON 可能格式不对，少个括号，多个逗号。它要写的 SQL 可能语法有误。工具调用可能抛 Exception。这些事情都会发生，而且经常发生。

成熟的 Agent 不会一遇到错就罢工。Harness 内部装了一个状态机和一套重试机制。

状态机把 Agent 的运行过程拆成几个明确的阶段，比如"等待输入"、“生成请求”、“执行工具”、“处理结果”。每个阶段只允许跳到合法的下一个阶段，模型想乱跳，状态机会拦下来。

重试机制负责处理出错。当工具调用失败，Harness 把错误信息拼进一条消息，原样喂回给模型，相当于跟它说"你刚才给的格式不对，这里少了个括号，重新生成一份"。模型看到错误信息，通常会自己修正，再交一份新的请求。Harness 再次执行，直到成功，或者达到重试上限。

这个过程听起来简单，却是 Agent 能"显得聪明"的关键。它把模型的试错，圈在了一条有护栏的路上。错了可以改，改了重来，但不会撒手不管。

最后，当 5 道题成功写进数据库，Harness 把最终结果整理好，交付给你。

到这里，一次完整的 Agent 调用才算结束。

Tool Calling 到底怎么工作

四大步骤里，第二步到第三步之间的工具调用，是整套机制里最值得拆开看的一块。它能不能工作，直接决定 Agent 能不能碰到真实世界。以联网搜索为例，把它拆开。

Tool Calling（工具调用）是打破大模型"信息孤岛"的机制。它运作的本质只有一句话，大模型负责意图推理，Harness 负责物理执行。整个流程走五步。

第一步，Schema 注入（定义工具）。在 Harness 层，开发者用 JSON Schema 定义 web_search 工具的名字、参数类型和描述。Harness 发起请求时，把这些工具定义发给模型，相当于先告诉模型"你手边有 web_search 这个工具可用"。

第二步，意图识别与参数生成（触发调用）。在大模型层，模型收到用户提问，推理后发现自己权重里没有实时数据，于是停止生成普通文本，转而输出一段符合预先定义的 JSON，请求调用 web_search，参数是 {“query”: “Harness 架构解析”}。

第三步，拦截与物理执行（运行工具）。Harness 拦截这个工具调用请求，暂停对话流程，解析 JSON 参数，真的向搜索引擎 API 发起 HTTP 请求，拿到网页片段。

第四步，上下文回传（观察结果）。Harness 把搜索结果格式化，封装成一条特殊消息（标记为 tool 或 observation），追加进对话历史，再提交给模型。

第五步，最终合成（响应用户）。模型读着包含最新搜索结果的上下文，综合外部信息二次推理，用自然语言生成完整答案返回给你。

下面用动画把五步走一遍。

再用一张时序图，看消息怎样在用户、模型、Harness 和外部工具之间流动。

Skill 技能如何积累

Tool 能让 Agent 碰到外部世界，但 Agent 怎么积累"该怎么干活"的经验？答案在 Skill 里。

如果说 Tool 是原子的，Prompt 表达意图，那么 Skill 是介于两者之间的"可复用过程知识"。大模型知道怎么调用各种 API，但它不知道遇到特定业务错误该怎么修，也不知道你的团队习惯怎样的排查流程。Skill 封装的就是这类经验。

在学术定义上，Skill 常被形式化为一个四元组 (C, π, T, R)，分别对应触发条件（Condition）、执行策略（Policy）、终止条件（Termination）和可调用接口（Interface）。

先分清四个容易混的概念。

Skill 的创作路径通常有三条。

人工编写（Human-authored）。开发者把已知的最佳实践硬编码成一份 Skill 配置文件。里面明确写了触发条件（遇到环境依赖报错时）、按什么顺序调用哪些工具、遇到常见错误代码时怎么排查。

会话提取（Session Extraction）。开发过程中，你观察到 Agent 在某次运行里反复尝试，成功解决了一个以前没见过的问题。把这次成功的执行轨迹（Trace）提炼出来，泛化成一个标准 Skill，供以后使用。

失败演进（Refinement）。当 Agent 在生产环境里反复陷入某种逻辑死循环或失败时，开发者介入修改现有 Skill，添加新的决策分支或防御性边界（Boundaries），让它随着使用越来越稳。

最后说两句

把整条线串起来看，Agent 的工作方式很清晰。

模型做判断，Router 分拣意图，Skill 提供方案，Harness 执行动作，状态机管流程，重试机制兜底。Harness 是 Agent 能稳定跑起来的基座，Tool Calling 是它和外部世界对话的方式，Skill 是它把经验沉淀下来的手段。每个组件各干一件小事，拼起来就是一台能自己干活的机器。

大模型决定了 Agent 的智商上限，它有多会想，Agent 就能多聪明。而外围的 Harness 工程系统决定了 Agent 的落地底线，它有多稳，Agent 才能多可靠地交付结果。聪明的模型配上不靠谱的外壳，一样会翻车。

想深挖的话，有几篇文章值得阅读。工程思想上，Martin Fowler 的《Harness engineering for coding agent users》讲了怎么用前馈（Guides）和反馈（Sensors）机制搭基座，减少模型的错误输出。评测架构上，DeepEval 团队的《Eval harness: What it is, how to use it》和 Braintrust 的《AI agent evaluation framework》说明了怎么对多步骤的 Agent 决策树做系统性验证。前沿方向，arXiv 上的《Rethinking the Evaluation of Harness Evolution for Agents》探讨怎么自动演进和评估 Harness 的结构配置。这些文章在各自的官网和 arXiv 上都能搜到。