Agent Harness的六层架构模型深度解读

最近，Agent Harness Engineering这个词突然就火了起来。其实，只要是做过生产级智能体的人，这种工程化思维肯定一直都在潜移默化中设计并使用着，只是一直没有权威机构或个人站出来正式提出“Harness”这个说法而已。

关于Harness这个词的翻译，有人叫它外骨骼，也有人叫它马具，还有人称之为驾驭——大家的叫法各不相同，现阶段也没有统一标准。说到底，Harness只是一种智能体的实现方式、一种设计思想、一种架构模式，或者说一种设计模式。所以这里我们采用市面上比较认可的一种叫法：驾驭工程。

Harness这个概念的出现，其实唤起了大家一个共同的问题：为什么大家用的是同一个GPT或Claude大模型，别人做出来的Agent活就干得好、运行就稳定，而我的智能体却那么拉垮？说实话，这问题听起来有点像是“同样的工具，为什么有人用得妙、有人用得糟”——使用者对工具的理解深度和运用技巧的差异，才是根因。

如果用一句话来总结Harness：Harness = Agent - Model。模型决定Agent的智商上限，Harness决定Agent的交付下限。

下面，我们把一个成熟的Agent Harness拆解为六层架构（目前业界还没有统一标准，这套拆法仅供参考）。

第一层：上下文管理层

核心问题：如何让模型在有限的窗口里，看到此刻应该看到的东西。

现在大模型厂商已经把上下文窗口卷到200K甚至1M token了，但我们依然不能把所有context一股脑全扔进去，原因有三个：

• 长上下文衰减：模型在中间段的注意力明显下降，这就是经典的“Lost in the middle”效应。
• 成本爆炸：每次调用都带着几十万token，烧钱速度可想而知。
• 噪声干扰：无关信息太多，模型会抓不住重点。

解决方案：

• 动态组装上下文：每轮对话前，根据当前任务动态检索相关文件、历史决策、工具输出。
• 上下文压缩：当上下文接近上限时，自动摘要早期对话，释放空间。
• 分层加载：核心指令常驻，工作记忆按需加载，长期记忆按查询拉取。
• 结构化切片：把大文件切成语义块，用embedding或关键词检索按需注入。

第二层：工具与执行层

核心问题：如何让模型能精准地调用工具。

模型输出的本质是文本，要让文本真正“动起来”，必须依赖工具调用。这一层决定了Agent的物理能力边界。

工程实践：

• 工具描述的精确性：工具名、参数schema、描述文案——每一个字都会影响模型的调用准确率。
• 执行沙箱：代码执行、Shell命令、浏览器等操作都需要隔离环境。
• 工具执行结果的结构化反馈：执行成功/失败、错误信息、输出摘要，都要以模型能理解的方式回传。
• MCP协议：正在成为业界默认的标准协议。

第三层：编排与规划层

核心问题：面对一个复杂目标，如何把任务拆解成模型能一步步执行的动作序列。

这一层是Agent从“单轮问答”升级为“多步任务执行”的关键，也是搞定复杂任务的诀窍所在。

工程实践：

• ReAct循环：Reason（思考）→ Act（行动）→ Observe（观察）→ 再思考，最经典的单Agent循环。
• Plan-and-Execute：先生成完整计划，再逐步执行，中途可重规划。Claude Code的Plan Mode就是这个思路。
• 多Agent协作：主Agent负责统筹，子Agent负责专项任务——一个负责搜索、一个负责写代码、一个负责审查。
• 任务图（Task Graph）调度：把任务拆成DAG，有并行、有依赖，像CI/CD流水线一样执行。

第四层：状态与记忆层

核心问题：如何让Agent记得自己是谁、做过什么、还要做什么。

这是Agent和Chatbot最本质的区别之一——Agent有状态。通常可以将状态层按时间维度分为三类：

• 工作记忆（Working Memory）：记录当前任务的状态、当前执行到哪一步、中间变量等。
• 会话记忆（Session Memory）：本次会话的完整历史、用户偏好、已做的决策等。
• 长期记忆（Long-term Memory）：跨会话的知识积累、用户画像、历史经验。

在具体工程实践上：

• 向量记忆库：用embedding存储历史经验，检索相似场景。
• 结构化记忆文件：例如CLAUDE.md、AGENTS.md，把稳定知识固化成文件，每次会话自动加载。
• 状态快照与恢复：长任务中断后能断点续传。
• 设计TODO系统：规划TODO任务清单，把计划物化成可追踪的状态。

第五层：评估与观测层

核心问题：如何知道Agent到底在干什么，干得好不好。

这一层往往不受重视，但却特别重要。你需要知道Agent卡在哪一步了，哪个工具调用失败了，为什么选了这条错误的路径；上线之后换了新模型，效果是提升了还是下降了——这些全都依赖观测。

工程实践：

• 全链路Tracing：每一次模型调用、工具调用、上下文变化都要可追溯。
• 结构化日志：打印带有trace_id、span、token消耗、延迟、成本的结构化事件。
• 自动化Eval：用测试集定期回归，监控准确率、完成率、幻觉率的变化。
• LLM-as-a-Judge：用更强的模型去评估Agent输出的质量，实现规模化自动评估。
• 在线A/B测试：不同prompt、不同模型、不同工具组合的真实对比。

第六层：安全、约束与失败恢复层

核心问题：当Agent做错事、卡死、或被诱导时，谁来踩刹车。

这一层是Harness的安全带和气囊——越是能力强、权限大的Agent，这一层就越不能省。

工程实践：

• 权限控制：哪些命令可以自动执行，哪些必须人工确认。
• 资源约束：最大token数、最大轮数、最大工具调用次数、最大执行时长，防止Agent陷入无限循环。
• 输入输出审查：Prompt注入防御、敏感信息脱敏、输出内容合规。
• 失败重试与降级：工具调用失败时的重试策略、降级策略、兜底策略。
• 断点恢复：长任务被打断后，能不能从上一个checkpoint继续，而不是从头开始。
• 人机协同（Human-in-the-Loop）：关键决策节点强制人工介入。

---

为什么同样的模型、同样的业务，做出来的Agent差异那么大？本质上就是：模型平等，但Harness不平等。

虽然模型在快速迭代，能力在不断刷新，但Harness是可以积累的工程资产。在上下文管理、工具集成、状态持久化、观测体系、安全约束上的每一分投入，都会在下一代模型上持续受益。