夜雨聆风
摘要：本文从 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()if len(activated) > 0 {for _, t := range allOnDemandToolDefs() {if activated[t.Function.Name] {defs = append(defs, t)}}}
这段真实源码像剧院的道具管理员：舞台上只摆这一幕需要的东西，其余道具留在后台。agent.go 负责告诉主 Agent 哪些工具常驻、哪些要先 load_tools；tools.go 定义每件工具的名称、说明和参数；真正把它们送进每一轮模型请求的，则是这里。它没有提高模型的智商，却减少了模型站在一地工具中发呆的机会。
而权限决定了这副身体能把手伸到哪里。读取文件和删除目录不是同一种动作，查询天气和真的下单也不是同一种动作。一个没有审批和沙箱的强 Agent，就像一个力气很大、没有痛觉，也不知道哪扇门不能开的孩子。
但这些仍然不是最难的部分。
最难的是：谁来判断它真的完成了？
四、我曾经造出一个会“心跳”的 Agent，却不知道它有没有做成事
我做过一套 Agent 运行系统。
它有目标规划器，可以把任务拆成步骤；有消息总线，让多个 Agent 彼此通信；有工具注册表，可以调用文件、网络和 Shell；有记忆系统，可以把身份、工作状态和事实分别保存；还有心跳监控，进程掉线后能够发现异常。
我当时很喜欢一句话：
进程必死，但状态可以活。
它听起来像一套真正的数字生命系统。进程会退出，记忆还在；机器会重启，任务可以继续；Agent 甚至能报告自己的状态：运行中、暂停、错误、完成。
可做到后面，我遇见了一个尴尬的问题：
“完成”是谁说的？
有一次，我把日志翻回任务结束的位置。COMPLETED 安安静静地躺在那里；如果只看状态表，一切似乎都是绿色的。可当我追问“测试结果在哪里、实际产物在哪里、用户凭什么相信它完成了”时，我才发现：系统从未被要求保存这些证据。
那一瞬间，这个词显得格外空洞：规划器里的某一步被标成 COMPLETED，只能证明一个状态字段被改了；工具调用返回 ok: true，只能证明程序没有抛出异常；心跳仍在跳，只能证明进程还活着。
它们都不能证明用户要的结果真的出现了。
一个写文件命令执行成功，文件内容可能是错的；一次代码修改没有报错，程序可能根本无法编译；Agent 说“页面已经修复”，浏览器里可能仍然一片空白。
那一刻我才意识到，我给 Agent 造了大脑、手脚、记忆和脉搏，却漏掉了非常朴素的一件事：做完作业以后，要有人检查答案。
我最初理解的完成：计划 → 调用工具 → 没有报错 → 标记完成真正可信的完成：先写清验收条件↓采取行动 → 检查真实产物 → 测试/观察/对照↑ ↓└──── 不通过就继续修 ────┘↓证据通过，才算完成
这段经历改变了我对 Harness 的判断。
我重新沿着一次任务的代码往下看。agent.go 规定主 Agent 的工作方式，真正让它一轮一轮呼吸的，却是 agent_workflow_handler.go：模型只要还在调用工具，循环就继续；当它不再调用工具、准备交出最终答案时，系统才走进收尾分支。
// agent_workflow_handler.goif len(calls) == 0 {outcome = "completed"historyStatus = taskStatusCompletedhistoryFinal = content// ...省略后台任务等待与展示代码...persistHistory()deleteWorkflowCheckpoint(workflowID)verifyOnWorkflowDone(c, workflowID)writeCodeSSE(c, "workflow_done", map[string]any{"status": "completed", "final_output": content,})go generateSkillAsync(task, transcript)return}
即使不懂 Go，也能看懂这段代码的顺序：先保存过程，再检查现实，最后才向界面发出 workflow_done。Harness 的“心跳”不是一个浪漫的说法，它就是这样一个不断判断“还要不要继续”的循环。
但 verifyOnWorkflowDone 里究竟检查什么？它不会再问模型“你确定吗”，而是去看这次真正改过哪些文件：改了 Go，就尝试构建 Go；动了前端，就执行前端构建，并打开真实浏览器预览。
// verify.goif hasGo && fileExists(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 来源：@MaxForAI DeepSeek Harness 团队负责人崔添翼的 X 账号：@tianyi DeepSeek-V4-Flash 模型与技术说明：DeepSeek 官方 Hugging Face DeepSeek V4 与 Codex 的 Agent 集成说明：Integrate with Codex Shunyu Yao 等，思考与行动交错的经典范式：ReAct: Synergizing Reasoning and Acting in Language Models Anthropic，Agent 的简单组合模式与工程原则：Building Effective Agents Anthropic，长任务中的上下文管理：Effective Context Engineering for AI Agents Anthropic，多轮 Agent 的评估与验证：Demystifying Evals for AI Agents Microsoft，Agent Harness 的循环、规划、记忆、审批与遥测：The Microsoft Agent Framework Harness Is Now Released Xuying Ning 等，Harness 接口、机制和验证问题综述：Code as Agent Harness ResceneAgent 主 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 evaluation Hugging Face，对生产基础设施入侵的事件披露：Security incident disclosure — July 2026
