Agent 出了问题，大多数团队的第一反应是改 Prompt。
Fiddler 的生产数据直接打脸了这个直觉：Agent 失败时，人们本能去调提示词，但问题往往不在模型，而在 Harness。
Harness 是什么？就是模型外围的那一层运行时组件。可靠的 Agent，从来不是"更强的模型"单独撑起来的，是模型加 Harness 加环境，三者共同构成的系统行为。
开始正文之前插播一下，我在搭建一个关于Harness Engineering和各种AI相关话题的知识库，不定期更新，超多番外。大家感兴趣的话可以直接点击原文链接访问。
01
别把 Harness 当成一个模糊外壳
Harness 最常见的定义是"模型之外的一切"。
方向没错。但工程上等于什么都没说。
想想看：Agent 出了问题，你只知道"它不太对"，却不知道问题在工具层、状态层、控制循环、权限边界还是验证闭环。只能反复改 Prompt，改完还是不对。
组件化拆解解决的就是这个问题。一旦明确拆分，失败归因就从"模型不够聪明"变成可调试的工程对象：状态层丢了上下文、约束边界没被执行、反馈闭环没形成。
近一两年的工程综述已经收敛到这个方向。Databricks、LangChain、Fiddler、Sebastian Raschka、TiDB，从不同角度说了同一件事：Harness 不是模糊外壳，是围绕模型组织起来的一组运行时组件。
02
先看一张总装图
下面这张表，覆盖了近两年大多数公开资料反复出现的核心职责。不一定是唯一拆法，但足够稳定，足够做后续分析的导航。
| 组件 | 核心问题 | 典型对象 | 主要职责 |
|---|---|---|---|
| 工具与执行层 | Agent 如何真正行动 | shell、API、DB、MCP、代码执行器 | 把模型意图转成受控动作 |
| 内存与状态层 | Agent 如何跨步、跨会话持续推进 | task state、memory store、progress logs | 保存运行真相源与长期记忆 |
| 工作区与沙箱 | Agent 在哪里工作 | repo、filesystem、容器、浏览器、临时目录 | 提供受控工作现场与隔离边界 |
| 控制循环与编排 | 谁决定下一步做什么 | single loop、subagents、handoff、router | 组织 plan-act-observe-verify 流程 |
| 约束与权限边界 | 什么可以做、什么不能做 | rules files、permissions、policy gates | 限定行动空间与风险边界 |
| 反馈验证与可观测性 | 系统如何知道自己是否做对 | tests、lint、traces、metrics、evals | 构成闭环、自纠错与归因基础 |
这张表的意义不是宣布"只有这六个组件存在"，而是给你一个稳定的诊断框架。下次团队讨论时，别再说"把 Agent 再调一调"了。直接问：瓶颈更像是 tools 问题、state 问题、sandbox 问题、loop 问题、constraint 问题，还是 feedback 问题？
03
工具层：Agent 的手
模型不会真正执行现实世界的动作。它只生成下一步该做什么的表示。
真正让 Agent 动起来的，是工具与执行层。Databricks 把 tools 放在定义 Harness 的核心位置，理由很简单：没有工具调用、文件读写、代码执行或 API 访问，模型再强也只是纸面规划。
但工具层不只是"能调用"。更关键的是"受控调用"。
工程上至少要解决四个问题：调用描述够不够清晰、参数约束够不够严、错误返回能不能解析、超时重试幂等性有没有控制。
打个比方：好的工具层让模型像驾驶一台有仪表和踏板的机器，踩油门有反馈，踩刹车有制动。糟糕的工具层呢？像让它在黑暗中盲操真实系统，什么都看不见，什么都摸不准。
Tool schema、MCP 接口、函数调用描述，很多人以为是"接口美化"。不是。它们是决定 Agent 能否可靠行动的控制面。一旦工具调用模糊、返回结构不稳定、错误难解析，Loop 就没法形成闭环。
04
状态层：Agent 的记忆，不能只放在上下文窗口里
2026 年 Harness 文章的一个共识：把 memory/state 从"附属能力"提升为一等架构对象。
TiDB 说得很直白：决定 agent state 能否迁移、持久、恢复的，不是模型，是 Harness 如何设计独立的 state substrate（状态基底）。
为什么？因为上下文窗口是临时的、昂贵的、会丢的。
你让 Agent 跑一个长任务，跑了 40 步，突然窗口收缩、上下文压缩、进程重启。如果所有工作记忆都留在对话历史里，这时就全没了。断点恢复不了，跨 session handoff 做不了，审计追溯查不到。
有个团队踩了这个坑：Agent 改了半天代码，跑了 30 多步，每次都"记得"之前的决策。结果一次重启后，Agent 从头开始，把之前的修改全推翻了。原因很简单，状态全在上下文窗口里，没有外置。
[修改说明: 补充微型踩坑故事，增加具体性和情感触点]
State 和 Memory 不是同一件事
很多人混用这两个词。但从工程角度，最好分开。
State 是运行时真相源：当前任务在哪一步、哪些 artifacts 已生成、哪些 checks 已完成、loop 持有什么局部变量。
Memory 是可复用知识：用户偏好、任务教训、历史决策、成功 playbook。
Fountain City 把 agent memory 分为 semantic（语义）、episodic（情景）和 procedural（程序性）三类，强调双层架构：上下文窗口是 RAM，持久存储是长期层。
这个判断很重要：不是"把所有历史塞进上下文"就叫 memory 设计。你得分清什么是近期操作态、什么是可检索经验、什么是系统真相源。
一个实用的三层状态模型：（1）Loop 级：当前计划、工具返回、scratchpad、临时变量；（2）Task 级：任务列表、进度文件、关键决策、生成 artifacts、验证结果；（3）System 级：长期 memory、组织知识库、审计日志、跨任务偏好与经验。
三层分别影响控制循环、长任务推进、组织化学习。把"状态"从抽象概念拆成可分别设计的对象，后续每一层都能单独优化。
05
工作区与沙箱：Agent 的工作现场
LangChain 和 Databricks 都把 filesystem/sandbox 放在 Harness 核心位置。
Agent 不是在抽象的"问题空间"里工作。它在一个非常具体的现场里：代码仓库、目录树、配置文件、浏览器、临时工件目录。工作区设计本身就是 Harness 的一部分，不是底层基础设施的偶然细节。
Sandbox 的本质是什么？控制爆炸半径
如果 Agent 可以直接触达生产文件、共享知识库主干、高权限网络资源，那任何推理错误都会有过大的爆炸半径。
容器、Git worktree、只读主仓加可写分支、受限浏览器、临时文件系统，这些都属于同一个设计目标：让 Agent 在受控世界里行动，做完了再通过 review 或 approval 把结果带回主世界。
打个比方：Sandbox 不是给 Agent 一个临时目录玩玩，是在系统层面划出试验空间和真实空间的边界。试验空间里炸了没关系，真实空间必须干净。
Workspace 也不只是安全问题。它直接影响可维护性和可恢复性。
设计良好的工作区，让 artifacts、logs、patches、memory writes 都有明确落点。混乱的工作区？状态四处散落，后续 handoff 困难、审计查不到、复现做不了。
06
控制循环：Harness 的心脏
工具层是手，状态层是记忆，控制循环是心脏。
Code as Agent Harness 把 reasoning、action、state、feedback、verification 放进同一个闭环框架。它强调的核心判断是：真正的能力不来自单次回答，来自连续控制过程。
LangChain 也把 orchestration 视为核心。Harness 不只是静态配置，它负责让模型在多步任务中持续推进、分解工作、调用工具、检查结果、决定是否继续。
一个最小 Loop 的抽象：
接收目标 → 读状态与上下文 → 生成下一步计划 → 通过工具执行 → 获得外部反馈 → 写回状态 → 判断继续、切换还是停止
不管外面是单线程 CLI、Planner/Worker 组合还是 Supervisor 加 Subagents 编排，本质上都是对这个循环的不同扩展。
一旦有了任务拆分、角色分工、模型路由、handoff 和 continuation，Harness 就从"带工具的问答系统"变成真正的工作引擎。
Orchestration 干的事很具体：谁拥有状态、谁能分配任务、什么时候切换上下文、何时终止循环、何时升级给人类。这些决策不靠模型"聪明"，靠 Loop 设计。
07
约束与权限：车道线和门禁系统
在很多团队的口语里，约束、权限、guardrails、policy gates、approval workflows 像是分散的几个主题。
但从 Harness 的组件视角看，它们只定义一件事：Agent 的行动空间边界。说白了，就是"能做什么"和"不能做什么"的控制面。
Martin Fowler 把 Guides 解释为前馈控制（feedforward），打比方说：工厂的进料检验不是等产品出了次品再返工，而是在原料进厂前就筛掉不合格的。Guides 做的就是这件事，在 Agent 行动前就介入。
生产级多用户 Harness 的实践又补上了 permissions 这一层：共享 memory 的写保护、工具的访问边界、角色化权限、review queue。都属于同一个控制面。
这一组件至少三层边界：（1）文本规则：AGENTS.md、CLAUDE.md、specs、workflows；（2）机器规则：lint、schema validation、contract checks、policy files；（3）权限规则：身份、工具访问、目录访问、审批条件、写保护。
前两层定义"该怎么做"，第三层定义"谁有资格做"。
小团队里，约束层主要是规则文件和少量 wrapper。企业环境里，这一层自然升级成 identity、authentication、approval workflows、cost controls、intervention recording。
Fountain City 那篇"7 Components You Should Audit"把 identity/authentication 和 cost governance 也纳入审计对象。说明权限边界已经不只是安全附属，是生产系统的构成部分。
08
反馈与可观测性：雷达与仪表盘
Databricks 和 Fiddler 都把 feedback loops 放在定义 Harness 的中心位置。
一个只能行动、不能判断是否做对的 Agent 系统，永远在"凭感觉做事"。一旦任务涉及代码修改、外部调用或长期推进，没有外部反馈的系统几乎注定不可靠。
验证层回答一个问题：它做对了吗？
最典型的形式：tests、lint、typecheck、schema checks、contract validation、goal checks、evaluator passes。
AI Harness Engineering 论文把 verification、failure attribution、intervention recording 与 observability 并列列为 component responsibilities。验证不是"开发流程附属品"，是 agent run 能否被视为有效 episode 的前提。
对 Agent 来说，真正的终点不是 patch 生成。是 patch 被验证、归因、记录，纳入可追溯链路。改完代码就结束？那是人类开发者的简化直觉，不适合 Agent 系统。
可观测性回答另一个问题：昨晚到底发生了什么？
2026 年的 Harness 文章越来越多地把 traces、metrics、cost controls、failure patterns、audit evidence 单列出来。
Addy Osmani、Fountain City、AI Harness Engineering 论文都把这些纳入核心关注。
反馈层不应被缩减为"跑一下测试"。它要包含完整的运行记录能力：哪一步失败、用了多少 token、哪个工具报错、哪个 gate 被触发、谁 intervened、最后如何收敛或放弃。
这一组件最适合作为"雷达与仪表盘"来理解。它不只帮 Agent 自我修正，也帮团队第二天早上追问：系统为什么成功、为什么失败？失败归因给模型、规则、状态还是工具？
09
六个组件不是并列清单，是一条闭环
把六个组件当并列清单看，会失去系统感。更重要的，是理解它们在一次真实任务中怎么协同：
Goal → Loop/Orchestration → 读 State/Memory → 选 Tools → 在 Workspace/Sandbox 里执行 → 受 Constraints/Permissions 限制 → 经 Feedback/Verification 检验 → 写回 State + Trace → 继续/移交/停止
Loop 组织，State 记忆，Workspace 提供世界，Tools 行动，Constraints 划边界，Feedback 闭环。
缺一块，系统就不完整。
10
为什么这套拆法对你有用
三个理由。
第一，问题定位快了。Agent 总是忘记任务？大概率 state/memory 的问题。误触高风险操作？constraints/permissions 的边界没画好。在错误方向跑太久？loop 和 feedback 的闭环没形成。不一定在模型本身。
第二，分析有锚点了。执行循环、任务分解、State Store、Workspace 管理、约束即架构、Sensors、Eval、错误恢复，全部能挂在六块之下。不再是零散专题，是逐层展开的系统课程。
第三，焦点变了。从"怎么让模型更聪明"变成"怎么让模型所在的系统更可靠"。AI Harness Engineering 论文提了一个判断：关键问题不应只是模型能不能产出 patch，而是 model-harness-environment 系统能不能产出可验证、可归因、可维护的变更。
六组件框架就是这种转向的具体表达。
✦ Harness 不是"模型外的一切"这种模糊剩余项。它是一组围绕模型组织起来的关键运行时组件。
把它拆成六大组件，抽象概念变成了工程可讨论、可分工、可扩展的系统对象。
这套拆法重要的地方，不在于方便解释 Harness。在于它解释了后续所有分析为什么存在：每一章都不是孤立主题，是六个核心组件中某一块的深入展开。
接受了这一点之后，Harness Engineering 就不像时髦术语了。更像一门真正的系统工程学科。
所以下次 Agent 出问题，别再改 Prompt 了。先拆开 Harness 看看，瓶颈在哪一块。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
