裸模型有四大硬伤无记忆、不能执行代码、知识过时、无工作环境。Harness 六大组件逐一补救——文件系统管存储与版本沙箱赋予代码自验证AGENTS.md 无需训练即可注入知识Web SearchMCP 打破知识截止上下文工程对抗信息腐烂编排Hooks 保障多 Agent 协同质量。System Prompt 贯穿始终是整套系统的神经中枢。一句话摘要 模型提供智能Harness 让智能变得有用。如果你不是模型本身那你就是 Harness 的一部分。2025 年底一位创业者在社交媒体上发了一条动态迅速引爆了技术圈的讨论——“我花了三个月调 Prompt模型回答质量提升了 20%。然后我花了两周搭 Harness整体任务完成率从 35% 飙到了 82%。”这条动态下面点赞最高的评论只有四个字方向错了。过去两年几乎整个行业都在追逐更大的模型、更强的推理能力、更长的上下文窗口。从 GPT-4 到 Claude 3.5从 Gemini Ultra 到 DeepSeek-V3参数规模一路狂飙基准测试分数不断刷新。每一次新模型发布社交媒体上都会涌现一波AGI 要来了的狂欢。但一个令人尴尬的事实是绝大多数真实业务场景中用户并没有感受到与基准分数相匹配的能力提升。为什么因为大家盯错了地方。模型就像一颗强大的引擎但引擎本身不是汽车。一颗裸露的引擎放在地上它不能载人不能转向不能刹车甚至不能自己启动。你需要底盘、变速箱、方向盘、仪表盘、油路系统……这一整套让引擎变得有用的东西在 AI Agent 的世界里有一个越来越被重视的名字——Harness。Agent Model Harness。 模型提供智能Harness 让智能变得有用。这不是一个新概念但它正在成为 2026 年 AI 工程领域最核心的共识。本文将从裸模型的四个硬伤出发逐一拆解 Harness 的六大组件——文件系统、Bash 沙箱、记忆AGENTS.md、Web Search MCP、上下文工程、编排 Hooks——带你看清 AI Agent 真正的竞争壁垒不在模型层而在 Harness 层。读完这篇文章你将重新理解一件事你写的每一行 System Prompt、搭的每一个工具链、设计的每一套编排逻辑都是在构建 Harness。 如果你不是模型本身那你就是 Harness 的一部分。01Agent Model Harness一个被忽视太久的公式在正式拆解 Harness 之前我们需要先厘清一个最基础的认知框架。1.1 什么是 AgentAgent这个词在 2024 年被用滥了。每一个能调用 API 的聊天机器人都自称 Agent每一个加了 RAG 的问答系统都宣称自己是 Agent。但如果我们回到最朴素的定义——Agent 是一个能够自主感知环境、做出决策、执行行动并从结果中学习的智能体。注意这里的四个关键动词感知、决策、执行、学习。裸模型能做到哪个严格来说它只能做决策这一步——给定输入产出输出。它不能主动感知外部世界没有眼睛和耳朵不能真正执行行动没有手和脚更不能持久化地学习没有长期记忆。所以一个真正的 Agent 必须是这样的结构Agent Model HarnessModel 是大脑负责想。Harness 是大脑之外的一切——感官系统、运动系统、记忆系统、能量系统——负责让想变成做。1.2 Harness 到底是什么Harness 这个词的英文原意是挽具就是套在马身上、让马的力量转化为拉车动力的那套装备。类比非常精准模型是马Harness 是挽具Agent 是马挽具车的整体系统。更技术化地说Harness 是模型之外的一切工程基础设施。它包括但不限于模型如何接收输入上下文构建模型的输出如何被解析和执行工具调用、代码执行模型如何获取外部信息搜索、API模型如何记住之前发生的事记忆机制模型如何与其他模型或子系统协作编排以及贯穿所有环节的安全、格式、质量约束HooksHarness 不是一个单一的组件而是一个系统。这也是为什么搭建一个真正好用的 Agent 如此之难——你不是在调一个参数你是在设计一整套工程架构。下面这张架构图展示了 Model 与 Harness 的关系以及 Harness 内部六大组件的整体布局这张图传达了三个关键信息第一Model 处于中心但它被 Harness 包围和支撑第二六大组件各司其职但彼此协同第三System Prompt 贯穿所有组件它是 Harness 的神经系统。02裸模型的四个硬伤为什么光有聪明的大脑远远不够要理解 Harness 的价值我们必须先直面一个残酷的现实裸模型Raw Model有四个致命的硬伤。所谓裸模型就是没有任何外部工具、没有文件系统、没有搜索能力、没有持久化记忆的纯粹大语言模型。你可以把它想象成一个被关在密闭房间里的天才——智商极高但看不见外面的世界记不住昨天的对话说了话也没人去执行。2.1 硬伤一无法维持跨会话状态这是最容易被感知的痛点。你跟一个裸模型聊了两个小时讨论了一个复杂的系统架构画了流程图定了技术方案。然后你关掉窗口第二天回来——它什么都不记得了。这不是记忆力差的问题这是根本没有记忆机制的问题。裸模型的每一次对话都是一个全新的开始前一轮的所有上下文在会话结束的瞬间灰飞烟灭。对于简单的问答场景这无所谓。但对于任何需要持续推进的工作——写一本书、开发一个项目、管理一个流程——这个硬伤是致命的。你需要每次都从头解释背景每次都重新建立共识每次都把之前的结论手动灌进去。这不是在用 AI 协作这是在训练一个每天都失忆的实习生。2.2 硬伤二无法执行代码裸模型可以写代码但它不能跑代码。它可以生成一段 Python 脚本但它无法验证这段代码是否能正确运行。它可以告诉你算法的时间复杂度但它不能在真实数据集上跑一遍来证明自己的分析。这意味着什么意味着裸模型的代码输出没有自我验证能力。它可能写出语法正确但逻辑错误的代码可能忽略边界条件可能对库的版本做出错误假设。而这一切错误只有在人类手动复制粘贴到本地环境运行之后才会暴露。更深层的问题是没有代码执行能力模型就失去了写→跑→看→修→再来的自我验证循环。而这个循环恰恰是优秀程序员最核心的工作方式。一个不能运行自己代码的 AI 编程助手就像一个只能在纸上画图纸但从来不去工地的建筑师——理论上无懈可击实践中漏洞百出。2.3 硬伤三无法获取实时知识大语言模型的知识有一个截止日期。截止日期之后发生的一切——新发布的 API 文档、最新的安全漏洞、上周刚更新的框架版本、今天的新闻——它统统不知道。在技术领域这个问题尤其严重。前端框架半年一个大版本云服务商每季度更新一次产品线开源库的 Breaking Change 防不胜防。你问裸模型React 19 的 use() Hook 怎么用它可能给你一个基于 React 18 的回答甚至虚构一个根本不存在的 API。这就是所谓的幻觉Hallucination的一个重要来源不是模型故意胡说而是它的知识库里根本没有正确答案于是它基于过时信息或模式匹配推理出了一个看起来合理但实际上错误的答案。2.4 硬伤四无法搭建工作环境裸模型没有文件系统没有工作空间没有项目目录。它不能创建文件不能组织代码结构不能管理依赖不能运行构建工具。这意味着它无法完成任何工程级的任务。写一个单独的函数可以。搭建一个完整的项目脚手架、配置 CI/CD 流水线、管理多个微服务之间的依赖关系不可能。工程不是写代码工程是在正确的位置写正确的代码并确保它与其他代码正确协作。没有工作环境工程就无从谈起。2.5 四个硬伤的本质如果你仔细看这四个硬伤会发现它们恰好对应了一个完整智能体所需的四种基础能力硬伤缺失的能力Harness 的对应组件无法维持跨会话状态长期记忆文件系统 记忆AGENTS.md无法执行代码行动能力Bash 沙箱无法获取实时知识感知能力Web Search MCP无法搭建工作环境环境操控文件系统 上下文工程 编排每一个不能都是 Harness 里的一个组件。 Harness 不是锦上添花它是对裸模型致命缺陷的系统性补救。没有 Harness 的 Model就像没有身体的大脑——它可以思考但无法存在于这个世界。03组件一文件系统——最基础的原语在 Harness 的六大组件中文件系统排在第一位不是因为它最炫酷恰恰相反——它最朴素也最基础。基础到很多人压根没意识到它是一个组件。但正是这个最朴素的组件决定了 Agent 能力的上限。3.1 为什么文件系统是最基础原语想一想人类程序员是怎么工作的。打开电脑第一件事是什么打开 IDE加载项目目录。所有的代码文件、配置文件、文档、测试用例、构建脚本……都以文件的形式存在于一个结构化的目录树中。文件系统是一切工程活动的地基。没有文件系统代码无处存放中间结果无法持久化多步骤任务无法衔接多 Agent 之间无法协作对于 AI Agent 来说文件系统的意义甚至比对人类更大。因为人类有大脑记忆可以记住一些中间状态。但 Agent 的上下文窗口是有限的——即使是 200K token 的上下文对于一个真实项目来说也远远不够。文件系统就是 Agent 的外部大脑是它突破上下文窗口限制的唯一途径。3.2 文件系统的三大核心能力第一工作空间与中间结果存储。Agent 在执行复杂任务时会产生大量的中间产物——分析报告的草稿、代码的半成品、数据处理的中间结果、与用户确认的决策记录。这些中间产物需要一个地方存放以便后续步骤引用。没有文件系统Agent 必须把所有中间产物都塞进上下文窗口——这既浪费 token又容易超出上下文长度限制。有了文件系统Agent 可以把中间产物写入文件需要时再读取实现按需加载。第二Agent 协作的基础。当一个任务复杂到需要多个 Agent 协同工作时文件系统就成了它们之间的共享白板。Agent A 把分析结果写入文件Agent B 读取文件并在此基础上继续工作。这种基于文件的异步协作模式简单、可靠、可追溯。第三版本追踪与错误回滚。这一点经常被忽略但它可能是文件系统最有价值的能力之一。当文件系统与 Git 集成后Agent 的每一步操作都可以被记录、追溯、回滚。为什么这很重要因为 Agent 会犯错。它可能在重构代码时引入 Bug可能在修改配置时破坏了系统。如果没有版本追踪错误就像雪球一样越滚越大直到系统彻底崩溃。有了 GitAgent或者监督它的人类可以随时回到之前的安全状态甚至可以开分支做实验——失败了就丢弃分支成功了就合并。以下是文件系统在 Agent 工作流中的角色示意这里有一个关键洞察文件系统 Git 给了 Agent 试错的能力。 没有这个能力Agent 只能小心翼翼地一步步走不敢冒险。有了这个能力Agent 可以大胆尝试——反正随时可以回滚。这极大地释放了模型的创造力。3.3 文件系统的设计原则在实际工程中为 Agent 设计文件系统需要注意几个原则目录结构要清晰且约定俗成。 Agent 不擅长处理混乱的文件组织。使用标准化的目录结构如前端项目的 src/components、src/utils 约定能显著降低 Agent 的认知负担。文件粒度要适中。 太大的文件几千行代码会超出 Agent 的处理能力太小的文件每个函数一个文件会增加文件管理的复杂度。一般来说一个文件对应一个模块或职责单元是比较好的粒度。元数据要丰富。 文件名要有意义目录要有 README关键决策要有 ADRArchitecture Decision Records。这些元数据是 Agent 理解为什么这样组织的线索。04组件二Bash 沙箱——让 Agent 从说到做如果说文件系统给了 Agent 一个工作台那么 Bash 沙箱就给了它一双手。4.1 从生成代码到执行代码的质变裸模型只能生成代码文本。但文本不是程序——程序是被执行的文本。在生成和执行之间存在一条巨大的鸿沟。一个终端Bash环境意味着 Agent 可以运行它自己写的代码安装依赖包执行构建命令运行测试套件查看运行时错误并调试这从根本上改变了 Agent 的工作模式。没有 BashAgent 是一个提建议的顾问有了 BashAgent 是一个动手做的工程师。4.2 自我验证循环写→跑→看→修→再来这是 Bash 赋予 Agent 的最核心能力——自我验证循环。这个循环看起来简单但它的意义是革命性的。没有这个循环Agent 的输出质量完全依赖于模型的一次性生成能力——模型推理正确就对了推理错误就全错。有了这个循环Agent 拥有了自我纠错能力它可以从自己的错误中学习至少在单次会话内。实际测试数据表明在编程任务中具备自我验证循环的 Agent 的任务完成率比一次性生成的方式高出 40%–60%。这个差距不是来自更好的模型而完全来自 Harness 层的 Bash 能力。4.3 为什么必须是沙箱有了 Bash 就够了吗不还需要安全隔离。Agent 执行的代码不一定是安全的。它可能无意中执行了 rm -rf /可能下载了恶意包可能发起了未授权的网络请求。如果 Agent 的代码执行环境是宿主机本身后果不堪设想。沙箱Sandbox提供了一个隔离的执行环境资源限制 CPU、内存、磁盘空间都有上限防止死循环或内存泄漏拖垮系统。网络隔离 默认禁止外部网络访问或只允许白名单内的地址防止数据泄露或恶意攻击。文件系统隔离 Agent 只能访问自己的工作目录不能接触宿主机的敏感文件。超时机制 执行时间超过阈值自动终止防止资源被长期占用。沙箱不是一个可选的安全加固措施它是 Bash 能力的必要前提。没有沙箱你不敢让 Agent 执行代码不敢让 Agent 执行代码Agent 就失去了自我验证能力失去了自我验证能力Agent 的输出质量就会大打折扣。4.4 沙箱技术的选择在工程实践中常见的沙箱方案包括Docker 容器 最主流的方案隔离性好生态成熟镜像管理方便。大多数 Agent 框架如 Devin、OpenHands都采用 Docker 作为沙箱。gVisor / Firecracker 更轻量的虚拟化方案启动速度快毫秒级适合需要频繁创建/销毁沙箱的场景。WebAssemblyWASM 在浏览器端或边缘计算场景中有潜力但目前对系统调用的支持还不够完善。Nix / 纯函数式环境 通过声明式的环境定义确保每次执行的环境完全一致杜绝在我机器上能跑的问题。选择哪种方案取决于你的具体需求但核心原则只有一条在保证安全的前提下给 Agent 尽可能大的自由度。05组件三记忆AGENTS.md——不改权重也能给模型加知识这是 Harness 六大组件中最容易被低估但可能最具长期价值的一个。5.1 模型的失忆症我们在前文讨论过裸模型无法维持跨会话状态。每次对话结束所有的上下文都会消失。但在真实的工作场景中Agent 需要记住大量信息项目的技术栈和架构决策用户的偏好和工作习惯之前犯过的错误和学到的教训团队的编码规范和设计模式业务领域的专有知识传统的做法是把这些信息写进 System Prompt——但 System Prompt 的长度是有限的塞太多信息会稀释重要指令的权重甚至导致模型注意力分散。AGENTS.md 提供了一个优雅的解决方案把知识写入文件在需要时自动注入上下文。5.2 AGENTS.md 的工作机制AGENTS.md 的设计理念可以用一句话概括工作中写入知识存文件下次自动注入。具体来说写入阶段 当 Agent 在工作过程中产生了有价值的知识比如发现某个 API 有一个未文档化的限制或者确定了某种架构方案的优劣它会把这些知识以结构化的方式写入 AGENTS.md 文件。存储阶段 AGENTS.md 文件存放在项目的文件系统中通常是根目录或各子目录下。它本质上就是一个 Markdown 文件人类可以直接阅读和编辑。注入阶段 下一次 Agent 启动或切换到新的工作上下文时Harness 会自动读取相关的 AGENTS.md 文件并将其内容注入到 Agent 的上下文中。5.3 “上下文注入 不改权重给模型加知识”这个等式是 AGENTS.md 最深刻的洞察。传统上要给模型加知识你需要微调Fine-tuning——修改模型的权重参数。这个过程成本高、周期长、且存在灾难性遗忘的风险。AGENTS.md 提供了一条捷径不碰模型权重只通过上下文注入来添加知识。 模型仍然是原来的模型但它看到的信息变了因此它的行为也变了。这就像是一种即插即用的知识扩展机制——今天你发现了一个新的最佳实践写进 AGENTS.md明天 Agent 就自动具备了这个知识。不需要重新训练不需要等模型供应商更新不需要任何机器学习的专业知识。这也解释了为什么 AGENTS.md 被称为记忆组件——它让 Agent 拥有了跨会话的长期记忆而且这种记忆是透明的人类可以阅读和编辑、可控的可以随时增删改、可审计的配合 Git 可以追溯每一次知识变更。5.4 AGENTS.md 的最佳实践在实际项目中AGENTS.md 的组织方式通常遵循以下原则层次化存放。 根目录的 AGENTS.md 存放全局知识项目概述、核心架构决策、团队规范子目录的 AGENTS.md 存放局部知识该模块的特殊约定、已知问题、接口规范。Agent 在进入某个目录工作时会同时加载全局和局部的知识。结构化书写。 好的 AGENTS.md 不是随意的笔记而是有明确结构的知识库。常见的分类包括项目架构、技术约束、编码规范、已知陷阱Gotchas、决策记录ADR等。定期清理。 过时的知识比没有知识更危险。随着项目演进某些早期的约束可能已经不再适用某些技术决策可能已经被推翻。定期审查和清理 AGENTS.md 是保持其有效性的关键。双向可编辑。 AGENTS.md 不仅是 Agent 写给自己的备忘录也是人类与 Agent 之间的知识契约。人类可以直接编辑 AGENTS.md 来向 Agent 传达偏好“我不喜欢使用三元表达式”、约束“所有 API 必须使用 REST 风格”、甚至个人工作习惯“代码审查时请重点关注错误处理”。06组件四Web Search MCP——突破知识的时间牢笼裸模型的第三个硬伤是无法获取实时知识。Web Search MCP 就是针对这个硬伤的解药。6.1 AGENTS.md 的最佳实践每个大语言模型都有一个知识截止日期。这个日期之后的世界对模型来说是一片空白。这在日常闲聊中可能无伤大雅但在专业工作场景中这是一个严重的限制。想象一下这些场景你让 Agent 帮你调试一个 bug而这个 bug 的修复方案在模型训练之后才被社区发布你让 Agent 写一个集成方案而目标 API 在上个月做了 Breaking Change你让 Agent 分析竞品动态而竞品昨天刚发布了新产品在这些场景中裸模型不仅帮不了你还可能用过时的信息自信地给出错误的答案——这比不知道更危险。6.2 Web Search打开信息的大门Web Search 赋予 Agent 搜索互联网的能力让它能够访问训练数据之后的新信息。这从根本上解决了知识过时的问题。但 Web Search 不仅仅是接个搜索 API那么简单。一个好的 Web Search 组件需要解决以下问题查询构建 模型的自然语言表述不一定是好的搜索查询。Harness 需要帮助模型把模糊的意图转化为精准的搜索关键词。结果筛选 搜索引擎返回的结果质量参差不齐。Harness 需要帮助模型过滤低质量来源优先使用权威文档如官方文档、RFC、知名技术博客。内容提取 网页内容通常包含大量无关信息广告、导航栏、侧边栏。Harness 需要提取核心内容并以模型友好的格式呈现。信息整合 当 Agent 需要综合多个来源的信息时Harness 需要帮助它处理信息冲突、去重、排序。6.3 MCP从搜索到连接如果说 Web Search 让 Agent 能看互联网那么 MCPModel Context Protocol让 Agent 能触互联网。MCP 是 Anthropic 在 2024 年底推出的一个开放协议它定义了 AI 模型与外部工具、数据源之间的标准化交互方式。你可以把它理解为AI 世界的 USB 接口——只要工具遵循 MCP 规范就可以即插即用地接入任何支持 MCP 的 Agent。MCP 的意义在于它把 Agent 的感知范围从公开互联网扩展到了任何可编程的数据源和服务。数据库、内部 Wiki、项目管理工具Jira、Linear、代码仓库GitHub、监控系统Datadog、Grafana……只要有 MCP 接口Agent 就能直接访问。6.4 Web Search MCP 的协同效应Web Search 和 MCP 单独使用都有价值但它们的组合才是真正强大的。举个例子Agent 需要修复一个生产环境的 Bug。MCP 连接监控系统 → 获取错误日志和堆栈信息MCP 连接代码仓库 → 查看相关代码和最近的变更历史Web Search 搜索错误信息 → 查找社区中是否有类似问题的解决方案MCP 连接项目管理工具 → 检查是否有相关的已知问题Agent 综合所有信息 → 生成修复方案并提交 PR整个流程中Agent 像一个经验丰富的 SRESite Reliability Engineer在多个信息源之间穿梭快速定位和解决问题。这种能力不来自于更强的模型而来自于 Harness 层的 Web Search MCP。07组件五上下文工程——对抗 AI 系统的熵增如果说前四个组件是给 Agent 装上四肢和感官那么上下文工程就是在管理它的大脑如何高效运转。这是 Harness 中最软的一个组件——它不涉及具体的工具或协议而是关于如何构建和维护模型的输入上下文。但恰恰是这个软组件在实践中对 Agent 表现的影响最大。7.1 Context Rot上下文的腐烂在长时间运行的 Agent 会话中一个普遍但很少被讨论的问题是 Context Rot上下文腐烂。随着对话的进行上下文窗口中会积累越来越多的信息——早期的指令、中间的讨论、工具调用的输入输出、错误信息和修复过程……这些信息像沉积物一样不断堆积导致几个严重的问题信噪比下降。 真正重要的信息被大量冗余内容淹没。模型的注意力被分散关键指令的执行质量下降。矛盾信息累积。 早期做出的决定可能已经被推翻但旧信息仍然留在上下文中。模型可能在新旧信息之间摇摆不定产出不一致的结果。Token 浪费。 大量无用的历史信息占据了宝贵的上下文窗口空间留给真正有用信息的空间被压缩。推理质量退化。 研究表明当上下文中充斥大量无关信息时即使相关信息就在上下文中模型的提取和推理能力也会显著下降——这就是所谓的大海捞针Needle in a Haystack问题的实践版。Context Rot 不是一个理论问题它是每一个长时间运行的 Agent 都会遇到的实际挑战。如果你用过 Agent 做复杂任务你一定有过这样的体验一开始 Agent 的表现很好但随着对话变长它开始变笨——遗忘之前的约定重复之前犯过的错误甚至对同一个问题给出前后矛盾的回答。这就是 Context Rot 在起作用。7.2 上下文工程的核心策略对抗 Context Rot 的技术手段统称为上下文工程Context Engineering它包含以下几个关键策略压缩Compression。 定期对历史上下文进行摘要压缩。把冗长的工具调用记录替换为简洁的结果摘要把详细的讨论过程替换为最终结论。这就像是给上下文做垃圾回收。工具输出卸载Tool Output Offloading。 工具调用的输出特别是大段的代码、日志、搜索结果是上下文膨胀的主要来源。上下文工程会把这些输出存储到文件系统中在上下文中只保留摘要和文件引用。需要详细信息时Agent 可以随时重新读取文件。Skills 渐进加载。 不同的任务阶段需要不同的知识和能力。上下文工程会根据当前任务阶段动态加载和卸载相关的 Skill 定义。例如在需求分析阶段加载产品相关知识在编码阶段加载技术栈相关知识避免一次性把所有信息都塞进上下文。分层上下文结构。 把上下文分为核心层System Prompt、关键约束始终保留、“工作层”当前任务相关信息按需更新、“历史层”已完成任务的摘要逐渐压缩。不同层的信息有不同的生命周期和更新策略。7.3 上下文工程是 Harness 的元能力上下文工程有一个特殊的地位——它不是 Harness 的一个独立功能模块而是影响所有其他组件的元能力。文件系统的读写操作需要上下文工程来决定读什么和什么时候读。记忆的注入需要上下文工程来决定注入多少和注入哪些。Web Search 的结果需要上下文工程来决定保留什么和丢弃什么。编排中的子 Agent 通信也依赖上下文工程来构建高效的信息传递格式。可以说Harness 本质上就是好的上下文工程的交付机制。 Harness 的每一个组件归根结底都是在解决同一个问题如何在正确的时间、以正确的方式、把正确的信息送到模型面前。这也是为什么上下文工程这个概念在 2025 年底开始取代Prompt 工程成为 AI 工程领域的核心话题。Prompt 工程关注的是怎么写指令上下文工程关注的是怎么构建模型看到的全部信息——后者的范围大得多影响也深远得多。08组件六编排 Hooks——让单兵作战变成集团军最后一个组件是编排Orchestration Hooks。如果说前五个组件是在增强单个 Agent 的能力那么这个组件是在把多个 Agent 组织成一个协同作战的系统。8.1 为什么需要编排当任务复杂度超过单个 Agent 的处理能力时你需要把任务分解为多个子任务分配给不同的子 Agent处理然后把结果汇总。这就是编排。编排解决的核心问题包括子 Agent 调度。 哪个子任务应该分配给哪个 Agent它们之间的依赖关系是什么哪些可以并行哪些必须串行任务分发。 如何把一个模糊的大任务拆解为明确的小任务如何确保每个子 Agent 得到足够的上下文来完成它的子任务模型路由。 不是所有的子任务都需要最强也最贵的模型。简单的格式转换可以用小模型复杂的架构设计需要大模型。编排器需要根据任务复杂度选择合适的模型在成本和质量之间取得平衡。结果聚合。 当多个子 Agent 返回结果后如何检查一致性、解决冲突、合并为最终输出8.2 Hooks注入确定性编排解决了谁做什么的问题Hooks 则解决了做得对不对的问题。在软件工程中Hook 是一种在特定事件发生时自动触发的回调机制。在 Agent Harness 中Hooks 的作用类似——在 Agent 行为的关键节点插入确定性检查确保输出符合预期。Hooks 的典型应用场景包括Lint 检查。 Agent 生成代码后自动运行 linter 检查语法和风格是否符合项目规范。不符合的话自动要求 Agent 修复。续接Continuation。 当 Agent 的单次输出因为 token 限制被截断时Hook 自动检测截断并触发续接请求确保输出的完整性。格式约束。 确保 Agent 的输出符合特定的格式要求——JSON Schema 验证、Markdown 结构检查、API 响应格式校验等。安全过滤。 在 Agent 执行敏感操作如文件删除、数据库写入、外部 API 调用前Hook 进行权限检查和安全审计。成本控制。 监控 token 消耗和 API 调用频率在接近预算上限时发出警告或限制。Hooks 的核心价值在于它们用确定性的规则约束了概率性的模型输出。 模型的输出本质上是概率性的——它可能生成正确的代码也可能犯错。Hooks 在模型输出的出口设置了一道关卡用确定性的规则如 lint 规则、格式校验把不合格的输出拦截下来要求重新生成。这种概率性生成 确定性校验的组合模式是当前 Agent 工程中最有效的质量保障策略之一。它既充分利用了模型的创造力和灵活性又通过工程手段兜住了质量底线。8.3 编排模式的演进Agent 编排的方式在过去两年经历了快速演进线性管道Sequential Pipeline。 最简单的编排方式Agent A 的输出直接作为 Agent B 的输入依次传递。适用于步骤明确、依赖关系清晰的任务。DAG 编排Directed Acyclic Graph。 用有向无环图定义任务之间的依赖关系支持并行执行没有依赖关系的任务。比线性管道更灵活高效。动态编排Dynamic Orchestration。 不预定义完整的任务图而是由编排器 Agent 根据上一步的结果动态决定下一步做什么。最灵活但也最难控制质量和成本。层级编排Hierarchical Orchestration。 编排器本身也可以层级嵌套——一个高层编排器管理几个中层编排器每个中层编排器又管理几个执行 Agent。适用于超大规模的复杂任务。选择哪种编排模式取决于任务的复杂度、确定性程度和实时性要求。但无论选择哪种模式Hooks 都是不可或缺的质量保障机制。09System Prompt贯穿所有组件的神经系统在讨论完六大组件后还有一个贯穿始终的要素值得单独讨论——System Prompt。System Prompt 不是 Harness 的第七个组件但它是贯穿所有六个组件的神经系统。它在 Harness 架构中扮演着四个关键角色9.1 定义角色边界System Prompt 告诉模型你是谁和你不是谁。这不是简单的角色扮演而是在定义 Agent 的能力边界和行为约束。例如你是一个前端开发 Agent专注于 React 生态系统。当用户提出后端相关需求时建议他们使用专门的后端 Agent。这样的定义帮助 Agent 聚焦在自己擅长的领域避免在不擅长的领域产出低质量结果。注入领域知识System Prompt 是零成本知识注入的第一入口。项目背景、技术栈选型、核心业务逻辑——这些信息直接写在 System Prompt 中确保 Agent 从第一轮对话开始就具备必要的领域知识。当然正如前文讨论的System Prompt 的容量有限。当领域知识量超过 System Prompt 能承载的范围时AGENTS.md 就接管了这个职责。两者是互补关系System Prompt 装必须知道的AGENTS.md 装最好知道的。约束安全规则System Prompt 是 Agent 安全策略的第一道防线。哪些操作是允许的哪些是禁止的哪些数据可以读取哪些是敏感的遇到不确定的情况应该怎么处理——这些安全规则通过 System Prompt 直接刻进 Agent 的行为模式。贯穿所有组件System Prompt 的影响范围不限于模型本身它通过定义 Agent 的行为模式间接影响了所有 Harness 组件的工作方式影响文件系统定义文件的组织规范和命名约定影响 Bash 执行限制可执行的命令范围影响记忆写入规定知识记录的格式和标准影响搜索行为设置搜索的优先来源和可信度标准影响上下文管理定义信息的优先级和压缩策略影响编排逻辑规定任务分解的粒度和协作规范在这个意义上写 System Prompt 就是在设计 Harness 的行为规范。一个好的 System Prompt 就像一部好的公司章程——它不直接做任何事但它决定了所有事怎么做。10结语你就是 Harness 的一部分让我们回到文章开头的那个公式Agent Model Harness如果你是一名 AI 工程师、产品经理、技术负责人——如果你不是模型本身——那你就是 Harness 的一部分。你写的 System Prompt 是 Harness 的神经系统。你搭建的工具链是 Harness 的四肢。你设计的记忆机制是 Harness 的长期记忆。你优化的上下文策略是 Harness 的注意力管理。你编写的 Hook 规则是 Harness 的质量底线。过去两年行业的聚光灯一直打在模型身上——参数规模、基准分数、推理能力。但真正在生产环境中创造价值的往往不是那个最强的模型而是那个最好的 Harness。模型会继续进步但进步的速度在放缓。与此同时Harness 的工程空间还几乎没有被充分探索。文件系统怎么设计才能最大化 Agent 的效率上下文工程有没有最优的压缩算法编排模式怎样才能在成本和质量之间取得完美平衡记忆机制能否实现真正的终身学习这些问题的答案不在模型的论文里而在 Harness 的工程实践中。模型决定了 Agent 能力的下限Harness 决定了 Agent 能力的上限。下一次当你在调试 Agent 的表现时不要急着换一个更强的模型。先看看你的 Harness文件系统完善吗沙箱安全吗记忆机制在工作吗上下文腐烂了吗编排合理吗Hooks 在兜底吗也许答案就在那里。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】