用汽车系统来类比智能体的“Harness驾驭工程”

图 1：大模型是发动机，智能体是自动驾驶软件，Agent Harness 是真正的上路系统。

最近聊 AI 智能体，越来越绕不开一个词：Harness。这个词直译有点别扭，可以理解成“挽具”“缰绳”或“安全带”。它不是马本身，也不是骑手本身，但没有它，马的力量很难被稳定驾驭。放到AI里，Harness也不是大模型本身，而是包在大模型外面的一套工程系统。它让模型不只是会聊天，而是真的能读文件、调用工具、执行任务、接受约束、留下记录，最后把事情做完。

这个词听起来还比较抽象，我们先看几个熟悉的产品形态：Codex、Claude Code、OpenCode、OpenClaw。它们不是单纯的大模型，也不是普通聊天机器人，而是把模型、工具、文件系统、终端、权限、上下文、状态管理和执行循环打包在一起的智能体产品。更严格地说，它们不是“纯 Harness 组件”，而是带有完整Agent Harness的智能体产品或运行时。LangChain 在讨论 agent harness 时，也把 Claude Code、OpenCode、Codex、OpenClaw等列为典型例子。

用汽车来类比，大模型像发动机，提供马力、推理和生成能力；智能体像自动驾驶系统，会围绕目标不断判断下一步该做什么；而Agent Harness则是让这辆车真正能上路的一整套系统：车辆自身的安全限制、外界道路设施，以及交通安全规则。没有Harness，大模型就像一台摆在实验室里的发动机，轰鸣声很漂亮，但离真正上路还差很远。

Agent Harness 不是给模型加一个插件，而是在模型外面搭起“可控行动”的工程外壳：它让模型能看见环境、调用工具、获得反馈、接受约束，并和其他  Agent 安全协作。

这套系统真正解决的，是智能体落地时最根本的三个问题。

第一，智能体本身的能力可控性：大模型会幻觉、会误判、会被诱导，当它接入真实系统之后，怎样避免“说错一句话”变成“做错一件事”？

第二，外界环境提供条件，改善目标的可达性：很多任务不是模型不聪明，而是模型看不到环境、拿不到工具、得不到反馈，所以目标本身对它不可达。

第三，多智能体协作的可控性和安全性：当多个 Agent 同时工作时，怎样避免它们各自局部合理、整体互相撞车？

第一层：先有刹车，智能体才敢上路

图 2：车辆自身的安全限制，对应 Agent Harness 中的权限、沙箱、审批和审计。

一辆车有发动机，不代表它就能上路。发动机越强，越需要刹车；速度越快，越需要方向稳定；车越重，越需要更可靠的制动系统。车辆自身的最高时速、最大转向角、最小刹车距离、安全气囊、电子稳定系统，看起来是在限制车，实际上是在定义这辆车“能安全释放多少能力”。Agent 也是一样。裸的大模型，本质上是一个概率系统。它会根据上下文生成最可能的输出，但这个输出不一定是真的，也不一定经过验证。放在聊天场景里，这叫“幻觉”；放在智能体场景里，问题就严重得多。因为智能体不只是说话，它可能真的去删文件、改代码、发邮件、查数据库、调用 API、操作浏览器。

一旦LLM接上工具，幻觉就不再只是“说错一句话”，而可能变成“做错一件事”。这也是AI安全领域为什么会关注Excessive Agency，也就是“过度代理能力”：当LLM系统被赋予过多功能、过高权限或过度自主性时，意外、模糊或被操纵的模型输出，可能触发破坏性动作。Agent Harness的第一层价值，不是让模型永远不犯错，这不现实；它真正要做的是让模型即使犯错，错误也不会直接变成不可逆事故。

这就像自动驾驶汽车可以判断路线，但不能因为一次误判就允许它以 180公里时速冲进闹市区。Harness 会把模型的“想法”和系统的“动作”隔开：模型可以提出要执行某个命令，但 Harness 决定这个命令能不能跑；模型可以建议修改某个文件，但 Harness 决定是否需要用户确认；模型可以调用工具，但 Harness 决定它能调用哪些工具、用什么权限、在什么沙箱里调用。换句话说，模型负责生成意图，Harness 负责控制动作。

很多人容易把安全性寄托在系统提示词上，以为只要在提示词里写清楚“不要做危险操作”，模型就会乖乖遵守。真实世界不会这么简单。模型可能理解错规则，用户可能给出诱导性输入，网页、邮件或文档里可能藏着间接提示词注入，工具返回的内容也可能污染后续推理。只靠一句“请安全行事”，就像只提醒司机“小心开车”，却不给车装刹车。

真正可靠的 Harness，会用工程机制兜底。权限系统会把工具分成可读、可写、可执行、需审批、禁止调用等不同等级；沙箱会限制 Agent 的文件访问范围、网络访问范围和命令执行范围；审批机制会在发邮件、删文件、改数据库、提交代码、调用支付接口之前暂停，让人类确认；日志和回放系统会记录每一步模型调用、工具调用和结果反馈；checkpoint 或版本控制机制则让错误操作可以回滚。

第二层：修好路，目标才真正可达

图 3：道路、地图和服务区，对应上下文、工具、文件系统、数据库、日志和反馈。

自动驾驶系统再聪明，也不能被扔进荒野里，然后期待它自己开到机场。它需要道路，需要地图，需要车道线，需要路况信息，需要停车场，需要服务区。道路不是发动机的一部分，但没有道路，发动机的马力没有意义。Agent 也是这样。很多时候，一个Agent做不好任务，并不是模型不够聪明，而是任务本身对它来说“不可达”。

让它修 Bug，但不给代码仓库、报错日志、依赖关系和测试命令，它只能猜。让它分析业务，但不给数据表、指标口径、用户画像和历史记录，它只能编。让它处理客户问题，但不给订单系统、退款规则、客服记录和权限边界，它就不可能真正完成任务。Agent Harness的第二层价值，就是给模型修路。

这里的“路”，不是简单地把更多资料塞进 prompt。真正的路，是一整套让 Agent 可以从当前状态走向目标状态的环境条件：它能看到什么上下文，能调用哪些工具，能得到什么反馈，能不能验证自己的动作，失败后能不能继续迭代。大模型本身像一个压缩过的世界知识库，但真实任务往往不在它的训练数据里，而在用户当下的环境里：这个项目的代码结构、这个公司的业务规则、这个客户的历史订单、这个系统刚刚报出的错误日志、这个 PR 改了哪些文件。

如果 Agent 看不到这些，它就只能凭“常识”工作。可是越到真实业务场景，常识越不够用。一个代码 Agent 想修复问题，需要知道项目目录、依赖关系、函数调用链、测试结果、最近提交记录。一个销售 Agent 想跟进客户，需要知道 CRM 记录、历史沟通、报价规则、合同状态。一个财务 Agent 想处理报销，需要知道公司制度、票据材料、审批流、预算科目。一个个人助理Agent 想管理日程，需要知道用户偏好、日历冲突、邮件上下文和出行规则。

这些东西不是模型天生知道的，它们必须由 Harness 提供。于是，Agent Harness 不只是工具列表，而是一个任务环境的设计系统。它要决定当前任务需要哪些上下文，哪些上下文一开始就给模型，哪些让 Agent 运行时自己去查；它要决定工具返回什么格式，模型最容易理解；它要决定文件系统怎样暴露，既不让模型看不到关键线索，也不让模型被无关信息淹没；它还要决定长任务中哪些信息要保留，哪些要压缩，哪些要丢掉。

这也解释了一个常见误区：很多人以为解决 Agent 问题的办法，就是给模型更长的上下文。但更长的上下文不等于更好的理解。给自动驾驶车一张全世界地图，并不等于它更容易找到你家门口那条小路。真正有用的是在正确的时间，把正确的信息，以正确的形式，交给 Agent。

OpenAI在分享Codex的Harness Engineering经验时提到，工程团队的工作重点会从“亲自写代码”转向“让Agent能写代码”：搭建代码仓库结构、CI配置、格式化规则、测试流程、日志系统、指标系统、文档索引、技能文件和审查机制。这样一来，用户不再只是对Agent说“帮我优化性能”，而是可以让它启动服务、跑用户路径、读取日志和trace、找出超过阈值的环节、修改代码、重新验证。目标从一个模糊愿望，变成了一条可观察、可执行、可反馈的路径。

第三层：车越多，越需要交通规则

图 4：多 Agent 协作不是多放几辆车，而是先建好车道、红绿灯、交接和调度。

单车上路已经复杂，多车同行更复杂。一辆车需要刹车，一座城市需要红绿灯。如果每辆车都只按照自己的局部最优行动，整个交通系统很快就会崩溃。每个司机都觉得自己有理由抢道，每辆车都觉得自己的路线最短，但结果一定是拥堵、冲突和事故。多 Agent 系统也是一样。

现在越来越多的智能体产品，不再只是一个 Agent 从头干到尾，而是多个 Agent 协作：一个负责规划，一个负责查资料，一个负责写代码，一个负责测试，一个负责审查，一个负责和用户沟通。表面上看，这是把一个大任务拆给多个 AI 员工；但只要进入真实任务，就会出现新的系统问题。谁先做，谁后做？谁有最终决策权？哪个 Agent 可以调用高风险工具？哪个 Agent 只能读，不能写？一个 Agent 修改了文件，另一个 Agent 是否知道？两个 Agent 结论冲突时，听谁的？一个 Agent 拿到的上下文，能不能完整传给下一个 Agent？某个 Agent 被提示词注入污染，会不会污染整个系统？

这些问题靠“模型更聪明”解决不了。它们是系统组织问题，不是单体智力问题。这就是Agent Harness第三层的意义：它要给多个Agent建立交通秩序。在汽车类比里，红绿灯、限速牌、车道线、交规和交警，并不负责提升某一辆车的发动机性能。它们负责的是系统层面的安全：什么时候该停，什么时候能走，谁有优先权，出了事故怎么处理，哪些道路不能进入。

对应到多 Agent 系统里，Harness 要解决的是任务编排、上下文隔离、权限分配、交接规则、冲突处理、审计追踪和回滚机制。多 Agent 的重点不是“多几个Agent 就更厉害”，而是每个 Agent 必须有自己的车道。有的 Agent 只能探索，不能修改；有的 Agent 负责实现，不能自行发布；有的 Agent 只做文档核验，不碰代码；有的 Agent 负责安全审查，必须保持只读；有的 Agent 可以并行跑任务，但最后必须把结果汇总给主 Agent。

多 Agent 也不是免费的。每多一个 Agent，就多一份上下文、多一组工具调用、多一条执行路径、多一次潜在冲突。看起来像是多线程加速，但如果没有良好的编排和边界，很快就会变成多线程内耗：一个 Agent 查一遍资料，另一个 Agent 又查一遍；一个 Agent 写了方案，另一个 Agent 没读到；一个 Agent 修改了文件，另一个 Agent 基于旧状态继续工作；一个 Agent 想省时间跳过验证，另一个 Agent 又把错误结果当成事实继续往下推。

这不是智能不够，而是交通系统没建好。多Agent的可控性，本质上是在避免“局部聪明导致整体失控”。一个Agent看起来很合理的动作，放到系统里可能会和另一个Agent冲突；一个Agent节省上下文的做法，可能导致下游Agent丢失关键信息；一个Agent被污染，可能通过任务交接污染整个链路。没有这套制度，多个Agent不会自然形成团队，只会变成一群同时踩油门的自动驾驶汽车。

Harness 如何提升 LLM 的能力？它提升的是“可用能力”

图 5：Harness 没有改模型参数，却让模型从“只能回答”变成“能理解、能行动、能验证、能协作”。

说到这里，可能有人会问：Harness 是模型外面的工程系统，又没有训练模型，也没有改模型参数，怎么能说它提升了 LLM 的能力？这里要区分两种能力。一种叫模型能力，也就是模型权重里蕴含的语言、推理、代码、数学、知识能力。另一种叫可用能力，也就是模型在真实任务中能够稳定发挥出来的能力。很多时候，真正决定产品体验的不是前者，而是后者。

一个模型理论上能写代码，但如果看不到仓库结构，它写不好；一个模型理论上会分析业务，但如果拿不到数据，它只能泛泛而谈；一个模型理论上能规划任务，但如果不能调用工具，它只能停留在建议；一个模型理论上能自我修正，但如果没有测试和反馈，它不知道自己错了；一个模型理论上能协作，但如果没有任务编排，多个 Agent 只会互相干扰。

Agent Harness提升的，正是这种可用能力。它让模型看见环境，所以提升理解力；它让模型调用工具，所以提升行动力；它让模型获得反馈，所以提升自我修正能力；它让模型受到约束，所以提升安全性；它让多个Agent被编排，所以提升协作能力；它让过程被记录，所以提升可观察性；它让结果能回滚，所以提升可恢复性；它让任务能复用，所以提升组织效率。

这也是为什么 Codex、Claude Code、OpenCode、OpenClaw 这类产品值得关注。它们的价值不只是用了哪个模型，而是把模型放进了一个真实工作环境里。Codex 把模型接进代码仓库、终端、隔离环境、日志指标和开发流程；Claude Code 把模型接进代码库、命令行、hooks、权限、sessions 和 subagents；OpenCode 把模型接进终端、IDE、LSP、多会话和可回滚的工作流；OpenClaw 则更像个人 AI 助手，把模型接进邮件、日历、聊天应用、浏览器、自动化和个人工作流。

这些产品共同做了一件事：把LLM从“回答系统”变成“行动系统”。普通聊天框里的LLM，像一个会说话的大脑；Agent Harness里的LLM，开始有眼睛、有手、有脚、有路线、有规矩、有记录。它能看见上下文，能调用工具，能试错迭代，能被权限约束，能和其他Agent分工，也能在失败后回滚。这才是智能体从“像人一样说话”，走向“像助手一样做事”的关键一步。

从“烧 Token”到“设计 Harness”：AI 工程的重心正在变化

过去一段时间，很多 AI 应用的做法很粗放：上下文不够，就塞更多上下文；结果不稳定，就让模型多想几轮；一次回答不准，就多开几个 Agent；任务做不好，就换一个更贵、更强的模型。这条路短期有效，但代价很高。智能体任务天然比普通聊天更烧 Token，因为它不只是一次输入、一次输出，而是多轮观察、多次推理、多次工具调用、多次反馈修正。

一个没有 Harness 的 Agent，很容易陷入低效循环：不知道该查什么，就全查；不知道哪个文件重要，就全读；不知道工具怎么用，就反复试；不知道结果对不对，就继续生成；不知道什么时候停止，就一直跑。这不是智能，而是迷路。真正好的Harness，不是让Agent无限消耗Token，而是帮它更少走弯路。

工具说明写得更清楚，Agent 就少试错；上下文组织得更合理，Agent 就少读无关信息；文件结构更可导航，Agent 就少乱翻；反馈信号更明确，Agent 就少自我脑补；权限边界更清晰，Agent 就少做危险动作；多 Agent 分工更合理，系统就少重复劳动。这些都不是单纯“换更强模型”能解决的，而是 Harness Engineering 要解决的问题。

换句话说，未来AI产品的竞争，不会只停留在“谁的模型更强”。还会比谁的上下文工程更好，谁的工具设计更适合Agent，谁的沙箱更安全，谁的权限系统更细，谁的多Agent编排更稳，谁的记忆系统更可迁移，谁的反馈回路更短，谁能用更少Token完成更可靠的任务。模型决定上限的一部分，Harness决定这个上限能不能被稳定抵达。

为什么说 Harness 决定了 AI 的下限与上限？

图 6：Harness 同时决定 AI 的下限、上限和成本边界。

过去几年，行业里大家拼命卷模型参数，默认“只要发动机马力够大，什么问题都能解决”。这很容易理解。因为模型能力的提升最直观：回答更流畅了，代码更像样了，推理更强了，长文本能读了，多模态能看图了。每一次模型升级，都像换了一台更大马力的发动机。

但现实证明，光有聪明的模型，难以保障任务在复杂环境里安全落地。一辆车不能只看发动机，一架飞机不能只看引擎，一个城市交通系统不能只看汽车性能。自动驾驶再先进，也离不开车身稳定系统、刹车系统、道路设施、信号灯、交通规则和调度中心。民航飞机再智能，也离不开飞控系统、空中交通管制、航线规划、维护流程和黑匣子。

AI智能体也是这样。Agent Harness不是某个简单插件，而是一整套让AI真正安全、稳定、高效落地的系统性工程。它负责组装提示词，管理工具权限，提供文件系统和运行环境，追踪任务状态，暴露日志和指标，拦截危险操作，安排多Agent协作，并在必要时把控制权交还给人类。

它决定AI的下限，因为它决定Agent出错时会坏到什么程度。有没有权限限制，有没有沙箱，有没有人工审批，有没有回滚机制，有没有日志审计，有没有防止多Agent互相污染的隔离机制？没有这些，AI越能干，越危险。它可能不是帮你提升效率，而是把错误放大到真实系统里。

它也决定AI的上限，因为它决定模型的能力能不能被充分释放。模型能不能看到正确上下文，能不能调用合适工具，能不能得到高质量反馈，能不能在长任务中保持目标一致，能不能和其他Agent分工合作，能不能把一次成功经验沉淀成可复用的技能和流程？没有这些，模型再强，也只能在聊天框里表演能力；有了这些，模型才有机会进入代码仓库、业务系统、企业流程和个人工作流，真正把任务做完。

这就是为什么AI工程正在进入Harness Engineering，驾驭工程时代。这个时代的核心，不再只是问“哪个模型最强”，而是问怎样设计环境，让Agent能做事；怎样设计工具，让Agent少走弯路；怎样设计权限，让Agent不会失控；怎样设计反馈，让Agent能自我修正；怎样设计协作，让多个Agent不会撞车；怎样设计成本结构，让系统不靠无脑烧Token也能完成任务。

正如行业里越来越常见的说法：Agent = Model + Harness。大模型提供强大的引擎，而Harness 打造方向盘、刹车、道路、地图、红绿灯和交规。只有当这匹马被配上精良的缰绳与马鞍，它才能从一匹横冲直撞的野马，变成能在职场和生活中稳定输出价值的战马。也只有当这台发动机被装进一辆真正能上路的车里，AI 才不只是会说，而是开始会做；不只是聪明，而是变得可靠；不只是一次次烧 Token，而是持续交付结果。

未来的 AI 竞争，当然还会继续比拼模型。但真正能把 AI 带进现实世界的，可能不是更大的发动机，而是更好的 Harness。