你有没有想过一个问题：Claude Code、Devin、Codex 这些 Agent 产品，底层模型都是 GPT-4 或者 Claude，为什么有些跑得稳、有些跑着跑着就崩了？
答案不在模型里，在"套子"里。
这个"套子"叫 Harness——包裹在 LLM 外面的那层基础设施，决定了一个 Agent 能不能真正在 production 环境里干活。2026 年 5 月，一篇发表在 OpenReview 上的论文 Agent Harness Engineering: A Survey 把这个概念拆成了七层，取了个不太好记的名字：ETCLOVG。
名字拗口，但拆开看，每一层都是你搭 Agent 系统时绕不开的问题。
论文提出了一个三阶段演进模型：
Phase 1：Prompt Engineering。 核心问题是"怎么写 prompt 让模型输出更好"。这个阶段大家的注意力都在模型身上，调 temperature、加 few-shot、写 system prompt。
Phase 2：Context Engineering。 随着 context window 变大，问题变成了"往 context 里塞什么"。RAG、长期记忆、会话压缩、working state 管理——这些都不是 prompt 能解决的。
Phase 3：Harness Engineering。 当 Agent 要在真实环境里跑长任务（几十分钟甚至几小时），你需要的不只是好的 prompt 和 context，还需要一整套基础设施：安全沙箱、工具权限、状态恢复、错误重试、成本追踪、审计日志。这就是 Harness。
论文的核心论点：Agent 执行的可靠性，更多取决于 Harness 的工程质量，而不是底层模型的强弱。
Anthropic 的工程博客也印证了这一点。他们在 Scaling Managed Agents 一文中描述了如何将 session log、harness loop 和 sandbox 三者解耦，来支持长时间运行的 Agent。OpenAI 也在 Harness Engineering 一文中分享了通过 Harness 约束和验证来构建可靠 Agent 的经验。
先看全貌。论文提出的七层模型，从底层到顶层依次是：
MERMAID_BLOCK_0
每一层解决一个维度的问题。下面逐层拆解，并附带对应的开源项目。
Agent 在哪里跑？
这是最底层的问题，但也是最容易被忽视的。一个 Agent 的执行环境决定了它的能力边界和安全边界。
本地进程：最简单，Agent 直接在你机器上跑。Claude Code 就是这个模式——它读取你的文件系统、执行 shell 命令、调用 Git。优点是开发体验好，缺点是 Agent 能做你的一切。
容器沙箱：Agent 在 Docker 或 MicroVM 中运行。Daytona（72k stars）、E2B（12k stars）、Alibaba OpenSandbox（10k stars）都是这个方向。沙箱可以限制文件访问、网络请求和进程权限，适合跑不可信代码。
浏览器环境：Agent 通过 CDP 协议控制浏览器。Browser Harness（13k stars）做的是这件事——让 LLM 直接操作真实浏览器，还能在运行时扩展 helper。
桌面环境：Computer Use Agent 的执行环境。E2B Desktop Sandbox 提供虚拟桌面，CUA（17k stars）提供完整的 computer-use 基础设施。
远程沙箱：Cloudflare Workers、Kubernetes pod、云函数。Cloudflare Agents 和 Kubernetes Agent Sandbox 分别代表了 serverless 和 K8s-native 两种思路。
核心权衡：能力越大，风险越大。 你给 Agent 多大的执行权限，就要配套多大的隔离措施。
工具是 Agent 的手。但手好不好使，不在于有多少只，而在于指挥系统怎么调度。
这一层要解决四个问题：
工具描述：模型怎么知道某个工具是干什么的？MCP（Model Context Protocol）是当前最主流的答案。它定义了一套标准化的工具描述格式，让不同 Agent 框架都能理解和调用同一组工具。GitHub Spec Kit（105k stars）则走 spec-driven 路线，用声明式规范引导 Agent 执行。
工具发现：Agent 怎么知道有哪些工具可用？MCP Servers（86k stars）维护了官方工具目录，leerob/directories 整理了 Agent 规则和 MCP Server 索引。工具发现做得不好，Agent 要么错过关键工具，要么在大量工具里迷失。
工具调用：怎么防止模型乱选工具？Anthropic 在 Writing effective tools for AI agents 中给出了实用建议：工具名称要清晰、参数要少、描述要精确到让模型不会搞混。PydanticAI（17k stars）则通过类型系统强制约束工具 schema。
工具互操作：不同框架的工具能不能混用？MCP 就是干这个的。它让 LangChain 的工具、OpenAI 的 function call、Anthropic 的 tool use 都能用同一套接口通信。
这一层解决的是 Agent 的"短期记忆"和"长期记忆"问题。
短期上下文：当前会话里的信息。怎么在有限的 context window 里塞进最有用的信息？Context Mode（15k stars）做的是"上下文优化"——沙箱化工具输出、索引会话事件、在 Agent 压缩上下文时恢复连续性。
会话状态：Agent 执行到一半断了怎么办？Anthropic 的 Effective harnesses for long-running agents 专门讲了这个问题。checkpoint、resume、state serialization——这些机制让长任务不怕中断。
长期记忆：跨会话的知识积累。claude-mem（78k stars）是最典型的项目——它捕获每次会话的历史，在未来的运行中自动注入相关上下文。agentmemory（17k stars）更进一步，用 MCP/REST 接口提供混合搜索（向量+关键词）。
工作状态：Agent 当前任务的结构化状态。planning-with-files（22k stars）把任务计划持久化到文件里，CCPM（8k stars）把 PRD 和 GitHub Issue 转成持久化的执行上下文。
论文把这一层叫 "Context Management"，它和 Phase 2 的 Context Engineering 一脉相承，但多了持久化和状态恢复的维度。
一个 Agent 是单轮执行还是多轮循环？是一个 Agent 干到底，还是多个角色分工？
这是编排层要回答的问题。论文给出了几种典型模式：
单 Agent 循环：Plan → Execute → Observe → Reflect → 重复。这是最基础的 Agent Loop。LangGraph（32k stars）用图结构来编排这个循环，每个节点是一个步骤，边是条件转移。
多 Agent 分工：Planner 负责规划、Executor 负责执行、Reviewer 负责审查。AutoGen（58k stars）是微软的多 Agent 框架，OpenAI Agents SDK（26k stars）支持 agent handoff——一个 Agent 干不完可以交给另一个。
工作流引擎：把复杂任务拆成阶段，每个阶段有明确的输入、输出和验证门。Archon（21k stars）用 YAML 定义阶段、在独立 worktree 里执行、每步有验证门控。OpenAI 的 Symphony（24k stars）则走 ticket-driven 路线，把项目工作拆成独立的自动化执行单元。
长周期编排：字节跳动的 DeerFlow（69k stars）是论文重点提到的项目——集成了记忆、工具、子 Agent 和沙箱的长周期 super-agent harness。
关键问题：怎么判断该继续循环还是该停下来？这个判断逻辑本身就是 Harness 工程的重头戏。论文称之为 capability-control tradeoff——给 Agent 更多自主能力，就需要更强的控制机制来兜底。
每次模型调用、工具调用、检索、报错、重试、token 成本、延迟，都要能追踪。
这层之所以被论文从之前的六层框架中独立出来，是因为生产环境的 Agent 系统太复杂了——一个长任务可能涉及几十次 LLM 调用、上百次工具调用，如果哪步出了问题你根本找不到原因，那整个系统就是黑盒。
Trace 追踪：LangWatch（3.2k stars）做的是端到端的 Agent simulation 和 evaluation。Microsoft Agent Framework 内建了图工作流级别的 tracing。
成本监控：每次 API 调用花了多少 token？花了多少钱？如果是多模型架构（Planner 用 GPT-4、Executor 用 GPT-4o-mini），成本追踪就更复杂。
错误诊断：失败发生在哪一层？是模型推理错了、工具执行错了、上下文信息错了，还是执行环境有问题？没有好的 observability，debug Agent 就像盲人摸象。
实时监控：Agent 正在干什么？卡在哪一步？需要人工干预吗？LangChain 在 Improving Deep Agents with harness engineering 中展示了纯靠 Harness 改进就能提升 benchmark 成绩的案例——而 observability 是发现问题的基础。
结果对不对？失败到底是谁的锅？
这一层和 Observability 的区别在于：Observability 关注"发生了什么"，Verification 关注"结果对不对"。
输出验证：Agent 的最终输出符合预期吗？Promptfoo（21k stars）做的是 config-driven 的 prompt/agent 测试。DeepEval（15k stars）提供 LLM 级别的评估指标。
轨迹验证：Agent 是怎么走到这个结果的？中间有没有走弯路、有没有幻觉？SWE-bench（5k stars）是代码修复领域的标准 benchmark，Terminal-Bench 则面向长周期的终端任务。
分层归因：这是论文最有价值的观点之一——失败到底是模型错了、工具错了、上下文错了，还是测试环境错了？ 如果不区分这四层，你可能花了一周优化 prompt，结果发现是沙箱配置有问题。
自动优化：auto-harness 做的是 benchmark-gated 的优化循环——自动挖掘失败案例、修改 Agent 代码、防止回归。Meta-Harness（Stanford）更进一步，在任务空间里搜索最优的 Harness 配置。
持续评估：不是上线前测一次就完了。Agent 的行为会随着模型更新、工具变化、数据漂移而退化。LangChain 在 Evaluating Deep Agents 中分享了持续评估有状态长周期 Agent 的实战经验。
Agent 有什么权限？能不能发邮件、改代码、调 API、读私有数据？谁来审批？谁来审计？
这是论文区别于之前六层框架的关键——把 Governance 提升为独立架构关注点，而不是安全团队的事后补丁。
权限控制：Agent 能做什么、不能做什么？Claude Code 的 auto mode 用分类器来决定哪些操作可以自动执行、哪些需要人工审批。NVIDIA OpenShell 用声明式策略控制文件系统、网络、进程和推理权限。
审批机制：敏感操作需要人类确认。Water 框架内建了 approval gates，sd0x-dev-flow 实现了 hook 强制的双审查机制。
审计日志：谁在什么时间让 Agent 做了什么？结果是什么？对于金融、医疗等监管行业，这是合规底线。
数据边界：Agent 能访问哪些数据？能不能把私有数据发到外部 API？Microsandbox（6.2k stars）用 rootless VM 提供硬件级隔离，阿里 CubeSandbox 用 MicroVM 实现 sub-60ms 启动的隔离环境。
Anthropic 的观点很明确：Your Agent Needs a Harness, Not a Framework。Framework 解决的是开发效率问题，Harness 解决的是生产可靠性问题。Governance 是可靠性拼图的最后一块。
论文把 170+ 个开源项目映射到了 ETCLOVG 七层上，发现了一个有趣的规律：
这七层之间不是简单的堆叠关系，而是一个耦合系统——论文称之为 harness coupling problem。你改了执行环境（从本地改成容器），工具接口、上下文管理、编排逻辑都要跟着变。你加了新的验证规则，Governance 的权限模型也要更新。
论文还提出了三个贯穿所有层的张力：
成本-质量-速度三难（Cost-Quality-Speed Trilemma）：快、好、省最多占两个。用便宜模型省成本但质量差，用强模型质量好但慢且贵。
能力-控制权衡（Capability-Control Tradeoff）：给 Agent 越多能力，就需要越强的控制机制。但你加的每一条限制都可能阻碍 Agent 完成任务。
Harness 耦合（Harness Coupling）：七层之间相互依赖，改一层影响其他层。怎么设计松耦合的 Harness 架构，是论文留出的最大 open problem。
论文配套的 GitHub 项目 awesome-agent-harness 收录了 220 个相关项目，按 ETCLOVG 分类整理，是目前最全面的 Agent Harness 生态目录。数据集发布在 HuggingFace 上。
如果你正在搭建 Agent 系统，建议对照这七层检查一遍：缺了哪层？哪层是你的薄弱点？大多数 Agent 系统失败的原因，不是模型不够强，而是 Harness 不够完整。
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。