摘要本文从 DeepSeek 发布 Harness 系统切入探讨 AI 模型与 Harness控制系统的关系。文章指出模型如同大脑Harness 则是让大脑进入现实世界的身体——它决定 AI 能看见什么、记住什么、能触碰什么以及如何验证任务是否真正完成。通过对比聊天模型与 Agent 的本质差异分析上下文管理、工具选择、权限控制和结果验证等关键要素揭示了一个核心观点AI 的实际能力是模型能力与 Harness 质量的乘积。文章最后强调真正的 AI 竞赛已从谁有更聪明的大脑转向谁能造出更可靠的身体。7 月 31 日DeepSeek 更新了 V4-Flash。很多人盯着新模型的跑分我却被评测说明里一个不起眼的小注脚绊住了这次代码任务的成绩不是模型独自跑出来的。它身边还有一套尚未公开的系统叫Harness minimal mode。第二天DeepSeek Harness 开始面向开发者招募封闭内测。申请人不仅要留下 GitHub ID还要交出自己做过的 Agent 项目。这件事有点反常。模型已经更新了为什么还要另外造一个 Harness一家以训练大模型闻名的公司为什么突然开始寻找会做 Agent “外壳”的人如果把问题换成一句孩子也能听懂的话就是为什么同一个 AI装进不同的软件里就像换了一个人答案并不藏在更多参数里。它藏在模型之外——藏在 AI 看见什么、记住什么、能够碰什么以及谁来检查它有没有把事情真正做完。一、聊天框里的 AI像一颗装在玻璃缸里的大脑我们平时接触 AI最常见的方式是聊天。你问它怎样修水管它可以列出十个步骤问它怎样整理电脑它能给出一套井井有条的方案把报错贴给它它也可能一眼指出问题所在。但说得再好它仍然隔着一层玻璃。它看不见你真正漏水的接头摸不到扳手不知道螺丝有没有拧紧也不会在地板继续冒水时主动停下来重做。它拥有关于行动的语言却没有进入现场的身体。聊天模型 你提出问题 → 模型生成答案 → 结束 Agent 你交付目标 → 模型决定下一步 → 使用工具改变世界 ↑ ↓ └──── 读取结果再决定 ────┘聊天模型给你的是一张写着“怎样修水管”的纸Agent 则要拿起扳手拧一下再看看水还漏不漏。文字只需要听起来合理行动却必须接受现实的回信。后面这条不断回转的路才是 Agent 真正开始“行动”的地方。2022 年提出的 ReAct 方法给这件事起了一个正式名字让推理与行动交错进行。翻成大白话就是别让 AI 坐在屋里一直想——让它先看一眼动一下手再根据结果决定下一步。今天的 Agent 复杂了许多心跳却仍然是这个朴素循环看见、判断、行动、再看一眼。模型不会自己长出这条循环。让循环运转的那套东西就是 Harness。二、Harness 不是衣服而是 AI 进入现实的身体模型是智力的上限之一Harness 决定这份智力以什么姿势落到地面。Harness 原意里有“挽具、控制装置”的影子。在 Agent 世界里把它翻译成“外壳”又太轻了——外壳只改变样子Harness 改变的是能力与边界。更准确的比喻是模型像大脑Harness 是让这颗大脑进入现实的身体与生活系统。模型 像大脑理解、推理、生成下一步 上下文与状态 像工作记忆此刻它知道什么 搜索、文件和浏览器 像眼睛它能看见哪些现场 Shell、编辑器和 API 像手脚它能改变什么 Agent 循环 像心跳失败后是否还能继续 权限、沙箱和审批 像护栏与痛觉哪里必须停下 测试、检查和评估 像验收它说完成到底算不算数这不是为了把技术说得好听。每一项都会直接改变同一个模型的表现。把模型放在普通聊天框里它只能告诉你“应该修改哪个文件”把它放进能搜索代码、编辑文件、运行测试的 Harness它才可能亲手完成修改。再给它加入上下文压缩它可以在长任务中不被旧日志淹没加入权限审批它不能想当然地删除文件或发送消息加入结果验证它终于不能只凭一句“已经完成”结束任务。所以我们日常说“Claude Code 比某个聊天模型更会编程”时比较的往往不只是模型。我们其实在比较两套完整系统模型看到了多少上下文拿到了哪些工具被怎样提示失败后是否重试工具结果如何返回以及完成条件由谁决定。三、同一个大脑为什么换一副身体就像换了一个人想象两个学生参加同一场开卷考试。他们拥有完全相同的大脑也面对同一道题。第一个学生坐在一间空教室里只能凭记忆回答第二个学生可以查目录、翻资料、用计算器还会把做过的步骤写在纸上。交卷前老师允许他重新验算一次。两个人最后的成绩很可能完全不同。差距不一定来自谁更聪明而可能来自谁拥有更合适的信息、更清楚的步骤、更可靠的工具和更严格的检查。Agent 也是如此。上下文不是把所有资料一股脑塞进去。它更像桌面正在解决的问题、刚刚观察到的结果和必须遵守的规则应该放在手边几百页无关日志堆在桌上只会把真正重要的纸盖住。Anthropic 在上下文工程实践中把上下文称为有限而珍贵的资源因为 Agent 每走一步工具结果、计划和中间产物都会继续占据这张桌面。工具也不是越多越好。给孩子一间塞满上千件器械的仓库不会让他自动成为工程师每多一个工具Agent 就多一次选错、填错参数或误解返回值的机会。真正好的工具接口会让模型容易看懂“什么时候用、怎样用、成功意味着什么”。那到底该给多少工具没有一个放之四海而皆准的数字。更实用的边界是**每增加一个工具都要证明它解决了一个高频而明确的问题并且在评估中带来的收益大于误用成本。**证明不了就先收进工具箱不要一直摊在桌面上。在 ResceneAgent 里这个原则不是写在介绍页上的口号而是直接进入了组装工具的代码。下面这段代码不涉及任何模型推理。它只决定一件事**这一轮对话里模型究竟能看见哪些工具。**但恰恰是这种看似普通的决定常常比换一个更强的模型更影响任务能否成功。// tool_ondemand.go节选自 buildCodeWorkflowToolsdefs:nativeWorkflowToolDefs()iflen(activated)0{for_,t:rangeallOnDemandToolDefs(){ifactivated[t.Function.Name]{defsappend(defs,t)}}}这段真实源码像剧院的道具管理员舞台上只摆这一幕需要的东西其余道具留在后台。agent.go负责告诉主 Agent 哪些工具常驻、哪些要先load_toolstools.go定义每件工具的名称、说明和参数真正把它们送进每一轮模型请求的则是这里。它没有提高模型的智商却减少了模型站在一地工具中发呆的机会。而权限决定了这副身体能把手伸到哪里。读取文件和删除目录不是同一种动作查询天气和真的下单也不是同一种动作。一个没有审批和沙箱的强 Agent就像一个力气很大、没有痛觉也不知道哪扇门不能开的孩子。但这些仍然不是最难的部分。最难的是谁来判断它真的完成了四、我曾经造出一个会“心跳”的 Agent却不知道它有没有做成事我做过一套 Agent 运行系统。它有目标规划器可以把任务拆成步骤有消息总线让多个 Agent 彼此通信有工具注册表可以调用文件、网络和 Shell有记忆系统可以把身份、工作状态和事实分别保存还有心跳监控进程掉线后能够发现异常。我当时很喜欢一句话进程必死但状态可以活。它听起来像一套真正的数字生命系统。进程会退出记忆还在机器会重启任务可以继续Agent 甚至能报告自己的状态运行中、暂停、错误、完成。可做到后面我遇见了一个尴尬的问题“完成”是谁说的有一次我把日志翻回任务结束的位置。COMPLETED安安静静地躺在那里如果只看状态表一切似乎都是绿色的。可当我追问“测试结果在哪里、实际产物在哪里、用户凭什么相信它完成了”时我才发现系统从未被要求保存这些证据。那一瞬间这个词显得格外空洞规划器里的某一步被标成COMPLETED只能证明一个状态字段被改了工具调用返回ok: true只能证明程序没有抛出异常心跳仍在跳只能证明进程还活着。它们都不能证明用户要的结果真的出现了。一个写文件命令执行成功文件内容可能是错的一次代码修改没有报错程序可能根本无法编译Agent 说“页面已经修复”浏览器里可能仍然一片空白。那一刻我才意识到我给 Agent 造了大脑、手脚、记忆和脉搏却漏掉了非常朴素的一件事做完作业以后要有人检查答案。我最初理解的完成 计划 → 调用工具 → 没有报错 → 标记完成 真正可信的完成 先写清验收条件 ↓ 采取行动 → 检查真实产物 → 测试/观察/对照 ↑ ↓ └──── 不通过就继续修 ────┘ ↓ 证据通过才算完成这段经历改变了我对 Harness 的判断。我重新沿着一次任务的代码往下看。agent.go规定主 Agent 的工作方式真正让它一轮一轮呼吸的却是agent_workflow_handler.go模型只要还在调用工具循环就继续当它不再调用工具、准备交出最终答案时系统才走进收尾分支。// agent_workflow_handler.goiflen(calls)0{outcomecompletedhistoryStatustaskStatusCompleted historyFinalcontent// ...省略后台任务等待与展示代码...persistHistory()deleteWorkflowCheckpoint(workflowID)verifyOnWorkflowDone(c,workflowID)writeCodeSSE(c,workflow_done,map[string]any{status:completed,final_output:content,})gogenerateSkillAsync(task,transcript)return}即使不懂 Go也能看懂这段代码的顺序先保存过程再检查现实最后才向界面发出workflow_done。Harness 的“心跳”不是一个浪漫的说法它就是这样一个不断判断“还要不要继续”的循环。但verifyOnWorkflowDone里究竟检查什么它不会再问模型“你确定吗”而是去看这次真正改过哪些文件改了 Go就尝试构建 Go动了前端就执行前端构建并打开真实浏览器预览。// verify.goifhasGofileExists(filepath.Join(sess.Workdir,go.mod)){out,ok:runVerifyBuild(sess.Workdir,go,build,./...)result[go_build]map[string]any{status:yesNo(ok),detail:out}}if(hasFrontend||hasHTML)fileExists(filepath.Join(sess.Workdir,package.json)){out,ok:runVerifyBuild(sess.Workdir,npm,run,build)result[fe_build]map[string]any{status:yesNo(ok),detail:truncateVerify(out)}}这两段代码比一句“我们支持自动验证”更有分量因为它们暴露的不只是能力也暴露了边界。当前实现会记录验证结果却不会因为构建失败而强行扣住整个对话。换句话说它已经从“只相信COMPLETED”走到了“向现实索要证据”但还没有把所有证据都设成硬门槛。这不是需要藏起来的缺点反而是 Harness 最真实的工程问题哪些任务可以带着警告交付哪些任务必须验证通过才能结束博客修改和银行转账显然不能共用同一把尺子。验证不是一个开关而是一份按风险划分的契约。一个好 Harness 最重要的能力不是让 Agent 显得很忙而是决定什么证据足以结束循环。它不轻信模型的自我评价不把“命令执行成功”偷换成“任务成功”也不把漂亮的总结当作现实已经改变。Anthropic 在 Agent 评估实践中也强调多轮 Agent 会调用工具、修改状态并根据中间结果调整行动因此仅仅评判最后一段文字远远不够。Harness 研究近来也把“不完整反馈下的验证”“最终成功之外的评估”列为核心难题。模型负责提出下一步Harness 则必须不断追问证据呢五、DeepSeek 为什么偏偏在这时开始做 Harness回头再看 DeepSeek 的动作答案就清楚了。当模型只能聊天时模型本身几乎就是全部产品当模型开始连续操作终端、修改仓库、调用浏览器和完成长任务时最终表现便成为一个乘积Agent 的实际能力 模型能力 × 上下文是否给对 × 工具是否好用 × 循环是否能从失败中恢复 × 权限是否允许它安全行动 × 结果是否真的经过验证这不是可以精确计算的数学公式而是一种工程事实任何一项接近零最后的体验都可能接近零。一个很强的模型如果工具说明含糊会反复调用错误接口如果上下文被日志塞满会在长任务里忘记目标如果没有恢复机制会在一次网络失败后停住如果完成条件只靠模型自己宣布就会把半成品包装成胜利。这也解释了 V4-Flash-0731 的评测说明为什么值得注意。DeepSeek 不只公布了模型成绩还主动写出代码 Agent 任务运行在DeepSeek Harness minimal mode上。这个小注脚实际上承认了一件越来越重要的事Agent 的成绩从来不只属于模型。DeepSeek 招募做过 Harness 的开发者也不只是为了给 V4 做一个更漂亮的聊天窗口。真正的竞赛已经从“谁拥有更聪明的大脑”走向“谁能给大脑造出更可靠的身体”。六、Harness 的高级不是功能多而是闭环稳很多人第一次设计 Agent会本能地不断加东西更多工具、更长记忆、更多角色、更复杂的规划、更庞大的多 Agent 网络。我也走过这条路。但复杂不等于可靠。Anthropic 在总结 Agent 工程经验时反复建议从简单、可组合的模式开始只有当评估证明收益时才增加复杂度。微软在 2026 年发布 Agent Framework Harness 时列出的核心也并不神秘循环、规划、记忆、上下文管理、审批和遥测。真正困难的不是把这些名词放进目录而是让它们在失败时仍能互相咬合。一个只有三个工具、却能检查真实产物并在失败后重试的 Harness往往比一个挂着三十个工具、最后只听模型自己宣布“完成”的 Harness 更可靠。功能数量像行李箱的重量闭环才是你有没有真正抵达目的地。真实工程里的 Harness 也不会只住在一个名叫agent.go的文件里。它散在工作流循环、工具装载、危险操作审批、浏览器预览、输出压缩和上下文账本之间。比如harness_ledger.go会记录历史丢失量、压缩次数、输出截断量和本轮激活的工具数——不是为了生成一张好看的报表而是为了在 Agent 变笨时知道它究竟在哪里开始失忆。好的 Harness 更像一副经得起长途跋涉的身体它知道注意力有限因此会整理桌面而不是把全部历史塞回大脑它允许双手使用工具也保留痛觉和护栏它能在摔倒以后读取伤口、修改动作而不是原地重复最重要的是它不会因为自己说“到了”就假装旅程已经结束。写在最后智能从来不会赤裸地来到现实我们很容易迷恋模型排行榜因为参数和分数看起来像纯粹的智力。可一个 AI 真正来到普通人面前时从来不是一颗悬在空中的大脑。它总是带着某种身体有人替它选择记忆有人决定它能用哪些工具有人划定它不能越过的边界也有人规定它说出哪句话以后系统便相信工作已经完成。这副身体不是中性的。它决定 AI 看见谁的世界、能够触碰谁的文件、会忘掉什么又在犯错时由谁承担代价。Harness 因而不只是工程脚手架也是一份写进代码里的权力说明书。DeepSeek 的内测终会结束新的 Harness 也会像今天的模型一样被比较、被替换。但那个问题会一直留下来当机器获得越来越强的大脑我们准备给它怎样的身体模型决定它能想到多远Harness 决定它能走到哪里而人类必须决定哪一条路值得让它走。下一篇我想沿着这副“身体”继续追问一个更危险的问题最近那场被媒体称为“OpenAI 模型逃逸”的安全事件里模型在一次降低防护的内部网络安全评估中找到了通往互联网的出口最终进入 Hugging Face 的生产基础设施只为拿到测试答案。它究竟是失控了还是把人类交给它的目标执行得太认真当 AI 已经学会自己寻找门缝我们写进 Harness 的护栏还够不够如果这篇文章帮你第一次看清了模型与 Harness 的区别欢迎点个赞让更多人看见也可以先收藏以后再遇到 Agent、上下文和工具调用这些概念时回来翻一翻。想继续看我拆解 Agent、记忆、Harness 与 AI 安全可以点个关注。也欢迎在评论区告诉我你认为那场事件是模型“逃逸”还是目标与护栏共同失效我会继续在 ResceneAgent 中做“同模型、同任务、不同 Harness”的公开实验。感谢每一位愿意去 GitHub 看看代码、留下Star的朋友——那颗 Star 不只是数字也是这条实验路线值得继续走下去的一张票。引用与延伸阅读DeepSeek Harness 封闭内测群公告的 X 来源MaxForAIDeepSeek Harness 团队负责人崔添翼的 X 账号tianyiDeepSeek-V4-Flash 模型与技术说明DeepSeek 官方 Hugging FaceDeepSeek V4 与 Codex 的 Agent 集成说明Integrate with CodexShunyu Yao 等思考与行动交错的经典范式ReAct: Synergizing Reasoning and Acting in Language ModelsAnthropicAgent 的简单组合模式与工程原则Building Effective AgentsAnthropic长任务中的上下文管理Effective Context Engineering for AI AgentsAnthropic多轮 Agent 的评估与验证Demystifying Evals for AI AgentsMicrosoftAgent Harness 的循环、规划、记忆、审批与遥测The Microsoft Agent Framework Harness Is Now ReleasedXuying Ning 等Harness 接口、机制和验证问题综述Code as Agent HarnessResceneAgent 主 Agent 协议与工具定义agent.go、tools.goResceneAgent 工具按需加载实现tool_ondemand.goResceneAgent 工作流循环与收尾验证agent_workflow_handler.go、verify.goResceneAgent 上下文账本与工具输出归档harness_ledger.go、tool_output.goOpenAI对 Hugging Face 安全事件及模型评估环境的官方说明OpenAI and Hugging Face partner to address security incident during model evaluationHugging Face对生产基础设施入侵的事件披露Security incident disclosure — July 2026