2023年，我们用大模型的方式很简单：问一个问题，得到一个回答。
比如你让程序员写个Python排序函数，模型几乎秒回，不需要“思考”。
那时候的模型就是光秃秃的LLM，没有今天这些花里胡哨的东西——工具、记忆、技能，等等。
但到了2026年，这些附加组件已经成了标配。正是它们，让一个简单的LLM变成了一个AI智能体。
一边是模型竞赛，一边是用户的野心
2023、2024年，大家比的是模型。OpenAI有最强的通用模型，Anthropic有最强的编程模型。各家拼命刷榜，MMLU、SWE-bench，谁分高谁牛。
后来模型竞赛饱和了，开始出现“推理”“上下文”这些词。你在聊天界面里问个问题，会看到“思考中……”的提示。人们开始好奇：它到底在底下干什么？
智能体的竞赛，开始了。
与此同时，用户的野心也大了。
以前我们问问题，后来我们直接派任务。任务需要智能体自己定目标、用浏览器等外部工具、从记忆里翻出过去的对话和事实，才能回答你。
我还记得，我截了一张亚马逊首页的图，扔给一个编程模型，让它“照着这个截图建一个网站”。它确实做出了一个类似的界面。但你想想，如果一个用户想要的是UI、后端、基础设施，全部一次性搞定呢？
这就是2026年的现状。
现在我会直接说：“解决GitHub上第122号issue里的bug。”就这么一句话，背后藏着一堆步骤。2023年的LLM只会说：“抱歉，我访问不了你的GitHub仓库。”
但一个装了好的Agent Harness的LLM，会进入“思考”模式。它会走这样的流程：
推理 → 规划 → 选择工具/动作 → 执行工具 → 观察结果 → 重复或停止。
所以，Agent Harness到底是什么？
既然我们给LLM包了这么多东西——上下文、工具、记忆——那就需要一种高效的方式来“工程化”它们和LLM之间的交互。这个就叫Agent Harness。
正式的定义是：
Agent Harness是包裹、控制、测试、监控和评估AI智能体的基础设施层。
说人话：它就是LLM外面的那层“操作系统”。
作为基础设施层，Harness包括：智能体架构、编排多个子智能体的编排框架、评估智能体输出的评估系统、运行时基础设施、安全、治理，以及最后但同样重要的——可观测性。
为什么需要Agent Harness？
因为我们给AI智能体定的目标越来越大，它执行任务的时间也越来越长。
Anthropic的数据显示，智能体的执行时间在指数级增长。2025年，一个任务大概跑一个小时。现在，已经逼近12小时。
这种长时任务会带来一堆问题：可能无限循环、幻觉出根本不存在的工具、破坏智能体状态、超出token预算、丢失上下文、反复重试错误动作、静默失败、滥用权限，甚至忘记目标。
这些都是很贵的问题。
想象一个AI智能体陷入无限循环12小时。token消耗和算力消耗会巨大。我们可以在Harness里给每个任务设预算——时间预算、token预算、算力预算，来解决这个问题。
更严重的是安全问题。想象LLM选了一个破坏性的工具，比如删掉文件系统里所有文件。通过Harness，我们可以精细控制LLM能访问什么。
一句话：Harness让你能控制智能体，从而让你相信它在做你想让它做的事。
Agent Harness的组件
不管你怎么叫它，Harness都逃不出下面这些组件。
智能体状态
回答“我现在在哪？”——跟踪当前任务、步骤、观察、决策等。比如计划有4步，状态记录哪些完成了、当前在哪、还剩什么。
工具
回答“我能做什么？”——给智能体代码执行、浏览器、API、数据库、shell等能力。工具是最明显的组件。对编程智能体来说，read_file可能就是基础工具之一。
规划
回答“我该做什么？”——决定下一步是什么，创建或修改计划。编程任务里，规划组件可能列出4-5步，按顺序完成。
记忆
回答“我知道/记得什么？”——跨步骤或跨会话存储和检索信息。从向量数据库里取信息放进上下文时，可能值得先摘要一下，优化上下文和工作记忆。这些都由记忆组件管理。
编排
回答“我怎么执行这个过程？”——控制执行循环、工具调用、重试、子智能体、并行、交接等。比如一个购买任务，可以调支付子智能体，同时让库存智能体并行更新库存；或者库存智能体必须等支付成功后才按顺序执行。
上下文管理
回答“LLM现在该看到什么？”——决定每一步把什么信息放进LLM的上下文窗口。
安全与治理
回答“我允许做什么？”——权限、沙箱、审批门、策略、限制、认证等。就算模型有杀手级工具，它能走多远？比如编程任务里，允许模型编辑文件，但不允许它删掉文件系统里的所有文件。
可观测性与评估
回答“它真的成功了吗？”——追踪发生了什么，衡量智能体成功、失败还是违规。比如模型完成任务用了10个工具里的3个，值得追踪这些工具怎么用的。如果失败了，是因为模型工具不够，还是上下文缺了数据？
Harness工程，就是设计、实现、执行这些组件，让智能体表现最佳的新学科。
一个实际的编程智能体例子
假设我们给一个编程智能体实现了Harness。用户发来提示：
解决GitHub上第122号issue里的bug。
注意，这不是“给我解释一下……”那种简单提示。这是一个真正的任务。要完成它，需要规划、工具使用、记忆等智能体能力。
下面是一种逻辑上的Harness实现方式：
- 用户输入进入上下文。模型开始推理，形成一个目标。目标留在上下文里直到完成。
- 它决定“规划”任务执行。计划是：检查相关bug、修正确的文件、编译和测试、跑测试用例、更新记忆。
- 执行第一步，Harness从向量数据库检索记忆——过去相关bug的细节。发现认证相关的信息最匹配，放进上下文。
- 模型用上下文信息，决定编辑auth.py文件来修复认证bug。这需要read_file和write_file工具。模型用这些工具编辑文件并保存。
- 模型决定通过终端测试代码变更。需要终端工具，它在模型可用的工具集里。（Harness确保模型对终端和文件有正确的访问级别。）
- 模型进入计划下一步，执行测试用例。需要更多工具。注意每一步都会更新上下文，确保模型知道自己在哪、还剩什么。
- 全程，可观测性组件记录一切：用了哪些工具、任务耗时、内存使用、中间失败等。
注意我们还没碰评估，那本身就是一个巨兽。它不只是准确率，还可以根据智能体的观察行为覆盖多个指标。
我们正在往哪走？
今天智能体AI最大的挑战之一，是长时可靠性。
跑几个小时的智能体正在变成现实，我们需要确保运行绝对可靠。如果智能体卡在无限循环或某种损坏状态，我们可能浪费资源，还危及安全。
其次，评估变得非常困难，因为我们在模型外面搭了越来越复杂的Harness。每个任务都会留下大量数据轨迹，比如内存使用。我是该换模型，还是该重新设计Harness？我该加更多工具，还是修现有的？
这些问题正在社区里冒出来，大家正在积极构建复杂的Harness。
我们等着看下一步往哪走吧。
本文话题 #AgentHarness #AI智能体 #LLM #人工智能 #智能体架构 #AI工程 #可观测性 #Anthropic #OpenAI #AI开发