Agent Harness Engineering综述：一篇读懂 AI Agent 真正的工程瓶颈

写在前面欢迎大家关注Rocky的公众号WeThinkIn欢迎大家关注Rocky的知乎Rocky DingAIGC算法工程师/开发工程师面试面经秘籍分享WeThinkIn/Interview-for-Algorithm-Engineer欢迎大家StarAIGC时代的《三年面试五年模拟》AI算法工程师求职面试秘籍独家资源【三年面试五年模拟】AI算法工程师面试秘籍Rocky最新撰写AI AgentAI智能体的深入浅出全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识AIGC算法岗/开发岗面试面经交流社群涵盖AI Agent、AIGC图像创作、AI视频、LLM大模型、AI多模态、数字人、传统深度学习、具身智能等AIGC面试干货资源欢迎大家加入https://t.zsxq.com/33pJ0大家好我是Rocky。核心导读这篇《Agent Harness Engineering: A Survey》真正重要的地方不是它又整理了一批 Agent 框架、工具协议和沙箱项目而是它把一个正在发生的行业事实讲清楚了当大模型能力进入长任务、工具调用、代码执行、多步协作之后Agent 的可靠性瓶颈越来越不只是模型本身而是模型外面的执行 harness。换句话说过去我们总以为 Agent 做不好是因为模型不够强、prompt 不够好、工具调用不够准。但这篇综述提出的 binding-constraint thesis 更尖锐在很多长时任务里同一个模型换一套上下文构造、工具接口、执行环境、验证机制、权限控制和观测反馈最终表现会发生远大于一次模型小版本升级的变化。论文引用的例子包括只改 edit-tool format 和工具 harness就在 15 个模型的 coding benchmark 上带来最高 10 倍提升固定 GPT-5.2-Codex只通过 system prompt 重构、中间件上下文注入和自验证 hook就把 Terminal-Bench 2.0 从 52.8% 提到 66.5%Meta-Harness 则通过自动 harness optimization 在 Terminal-Bench-2 上达到 76.4%。Rocky认为这篇综述的本质价值在于它把 AI Agent 从“模型能力问题”重新定义成“系统控制问题”。一个可用的 Agent不是一个会思考的模型加一个工具列表而是一个有边界、有状态、有执行环境、有观测、有验证、有治理的闭环系统。模型是大脑但 harness 是身体、工作台、显微镜、保险丝和审计账本。这件事对 AI 行业很关键。因为 2026 年以后Agent 的竞争不会只发生在谁的模型 benchmark 更高也会发生在谁能把模型放进更好的执行系统里谁能更稳定地管理上下文谁能更安全地执行工具谁能追踪失败根因谁能把成本、质量、速度、安全约束做成可运营的闭环。工具红利会被更强模型逐步吸收但 harness 工程会变成 Agent 产品真正的基础设施壁垒。问题背景作者到底想解决什么学术界过去研究 LLM Agent主要研究“模型能做什么”能不能规划、能不能调用工具、能不能检索记忆、能不能协调多个 Agent。这个视角默认 Agent 能力主要来自模型能力只要模型足够强再配上好 promptAgent 行为就会足够可靠。这篇综述认为这个假设正在失效。真实部署里Agent 的失败常常不是因为模型完全不懂任务而是因为外层系统没有把任务执行变成可控、可观测、可恢复的过程。工具描述太多会让模型选错上下文压缩会丢掉关键约束沙箱没有 reset 会污染评测权限边界不清会放大风险没有 trace 就无法知道失败来自模型、工具、环境还是评估器没有 governanceAgent 的自主性越强出错半径越大。论文把这个外层系统称为 agent execution harness它是围绕语言模型的一层基础设施负责上下文构造、工具交互、编排控制、反馈验证和执行约束。它的核心作用是把一次次模型调用变成“有边界、带状态、可执行、可追踪、可恢复”的长时任务过程。Figure 1 用三阶段演化解释了这个转变。Prompt engineering 优化的是单次模型输入Context engineering 优化的是模型在多步任务中看到什么Harness engineering 优化的是模型如何运行包括工具、环境、编排、验证、治理和安全。它不是替代 prompt 或 context而是把它们吸收到一个更大的系统层里。这张图背后有一个行业判断Agent 不是聊天机器人多接几个 API而是模型开始进入“执行世界”之后产生的新系统形态。只要模型能够写文件、跑命令、调用浏览器、操作数据库、委托子 Agent、影响外部环境工程焦点就会从“怎么问模型”转向“怎么约束和验证模型的行动”。核心思路用 ETCLOVG 把 Agent Harness 拆成七层论文的核心贡献是 ETCLOVG 七层 taxonomyExecution environment, Tool interface, Context management, Lifecycle/Orchestration, Observability, Verification, Governance。它不是把 Agent 系统随便分成几个模块而是试图回答一个工程问题一个长时运行的 Agent要可靠地完成任务外层 harness 到底有哪些不可省略的系统面Figure 2 展示了七层之间的关系。E、T、C、L 四层构成结构性支柱执行环境决定 Agent 在哪里行动工具接口决定 Agent 能调用什么上下文管理决定模型看到什么生命周期和编排决定任务如何推进。O、V、G 三层构成控制平面Observability 记录发生了什么Verification 判断结果和过程是否正确Governance 决定什么能做、什么不能做、出了事如何审计。Rocky认为这个七层 taxonomy 的关键不是“分类完整”而是把 Agent 的可靠性从单点能力转成了系统耦合问题。一个 Agent benchmark 分数不能只归因于模型它同时受到 sandbox、tool schema、context policy、orchestration loop、trace capture、grader、permission model 的影响。你改一个工具描述可能改变模型行为你改一个沙箱 reset 逻辑可能改变评测分数你增加一个 guardrail可能提升安全但降低速度和成本效率。这就是 harness engineering 的复杂性。Figure 3 把 2022 到 2026 的系统演化放在时间线上早期是 ReAct、AutoGPT、BabyAGI 这样的单循环 Agent随后是工具调用、多 Agent 协作、Web/OS/软件工程 benchmark再到 2025-2026 年MCP、A2A、Codex、Claude Code、OpenHands、Terminal-Bench、Meta-Harness、sandboxing、observability、governance 开始成为主线。它说明 harness 不是一个新名词而是过去几年 Agent 生态堆积出的真实工程表面。Figure 4 是 ETCLOVG 的展开图。它把每一层进一步细分Execution 下有 managed sandboxes、computer-use infrastructure、code sandboxes、browser evaluation environments、OS-level permission sandboxesTool 下有 protocol standards、tool discovery、tool-augmented training、session managementContext 下有 active context、session state、long-term memory、long-horizon techniques、context driftLifecycle 下有 single-agent loop、multi-agent orchestration、full task pipelineO/V/G 则分别对应观测、评估和治理控制。这张图适合工程团队用来做架构自查你的 Agent 产品到底只是在 LLM 外面包了一个 framework还是已经具备完整 harness有没有可复现执行环境有没有工具协议和工具选择策略有没有长期状态管理有没有 trace有没有 failure attribution有没有权限和审计如果没有模型越强系统风险反而越大。方法展开沿着论文原始逻辑拆解语料构造这不是凭经验写的生态评论这篇综述不是只靠作者主观经验整理工具列表而是构造了一个公开可见的 agent-harness 生态语料。候选项目来自 prior surveys、benchmark papers、GitHub 搜索、curated lists、package registries、公司工程博客和 release notes。作者记录项目名、URL、artifact type、source type、availability status、release year、GitHub metadata 和后续 ETCLOVG coding 所需的公开证据快照时间为 2026 年 5 月 8 日。Figure 5 展示 corpus construction protocol先从 GitHub、论文、curated lists、公司博客、package registries 收集候选再 deduplicate、检查 inclusion criteria最后映射到 ETCLOVG 层。论文强调 included project 必须公开可查、实现或指定具体 harness-level mechanism并且有足够证据分配至少一个 ETCLOVG layer。这一步很重要因为 Agent 生态现在太容易陷入“项目名很像 Agent实际只是 demo”的噪声。论文采用 mechanism-based inclusion而不是 label-based inclusion一个仓库叫 agent 不够一个 sandbox/evaluation/memory/governance 项目如果提供可复用 harness machinery就可以进入语料。作者也承认语料有偏差偏英语、GitHub-visible、开源项目、公开实现细节充分的系统商业生产系统低估coding-agent 生态高估因为它有大量公开仓库、benchmark、sandbox、issue-to-PR workflow 和 release notes。这个限制反而增强了文章的可信度它不是宣称覆盖了所有生产 Agent而是给出了“可见生态”的系统地图。EExecution Environment and SandboxAgent 行动的物理边界Execution layer 解决的是 Agent 的动作在哪里执行、以什么边界执行。对 LLM Agent 来说execution environment 和 sandbox 高度耦合因为 Agent 可以运行代码、读写文件、调用网络、操作浏览器或桌面。如果不限制执行环境Agent 的错误不仅是文本错误而可能变成真实副作用。Figure 6 归纳了 execution/sandbox 生态general-purpose managed sandboxes、computer-use infrastructure、code/repository execution sandboxes、framework-integrated runtimes、browser evaluation environments、OS-level permission/runtime security、sandbox abstraction/training/evaluation。论文的一个关键判断是Agent sandboxing 比传统多租户代码执行更难。LLM 生成代码不可静态审计Agent 会多步自主执行人类不可能每一步都 interveneprompt injection 还可能把原本 benign 的 Agent 变成攻击 sandbox 的载体。Sandbox-EscapeBench 这类工作显示frontier LLM 在 Docker-based containers 上有 15% 到 35% 的 escape success rates说明这不是理论风险。Rocky认为Execution layer 是 Agent 产品从 demo 走向生产的第一道硬门槛。没有可测量、可 reset、可隔离、可审计的执行环境Agent 的成功率和安全性都没有意义。尤其是 coding agent、browser agent、computer-use agent它们本质上是在把模型输出接到真实操作系统上沙箱不是可选项而是产品的安全地基。TTool Interface and Protocol工具越多越需要协议和选择机制Tool layer 定义 Agent 如何发现能力、描述工具、选择工具、执行调用。论文把工具接口放在能力覆盖和决策质量之间的矛盾中暴露更多工具可以提高任务覆盖但也会增大 action space、token overhead、prompt injection surface 和选择错误概率。Figure 7 展示工具接口和协议相关工作包括 Toolformer、Gorilla、ToolLLM、MCP、A2A、OpenAPI、function calling、BFCL、StableToolBench 等。论文认为工具标准应该按“跨越的集成边界”分类而不是按厂商或发布时间分类。Table 1 进一步把标准放到四类边界里。Table 1: Tool/interface standards arranged by integration boundary.BoundaryStandardWireTypedRuntime discoveryLong-runningModel ↔ FunctionFunction callingJSONfirst-classout of scopeout of scopeAgent ↔ CapabilityMCPJSON-RPCfirst-classfirst-classout of scopeAgent ↔ CapabilityOpenAPIHTTPfirst-classout of scopeout of scopeAgent ↔ AgentA2AJSON-RPCfirst-classfirst-classfirst-classAgent ↔ AgentACP / ANPHTTPfirst-classfirst-classfirst-classAgent ↔ Repo / envAGENTS.md / AGENT.mdMarkdownout of scopeout of scopeout of scope这张表非常有启发。很多人会问 MCP 和 A2A 谁会赢但论文提醒我们它们其实跨越的是不同边界。MCP 更像 Agent 访问工具和上下文资源的协议A2A 更像 Agent 应用之间的协作协议AGENTS.md 则是把 repo/env 里的工作约束版本化。真正的 harness 往往需要它们组合而不是在一个协议里解决所有问题。CContext and Memory长任务的核心不是塞更多 token而是保持任务状态Context layer 解决模型在每一步看到什么以及哪些状态应该保留、压缩、恢复或遗忘。论文强调从 prompt engineering 到 context engineering 的转变是因为 Agent 变成长任务后问题不再是“单次输入怎么写”而是“多步执行中哪些信息应该进入窗口”。Figure 8 展示 context/memory 相关工作active context window、session state、long-term memory、long-horizon context techniques、context drift 等。论文把 context 分成短期 active context、中期 session state、长期 persistent memory。Rocky认为这一节的本质是Agent 的 context 不应该被理解成“模型输入材料”而应该被理解成“任务状态估计”。长时任务里每一次总结、检索、压缩、清理 tool result都可能删除关键约束或保存错误假设。所谓 context rot不只是 token 太多而是 Agent 内部状态和真实任务状态逐渐偏离。这也是为什么很多 Agent 产品看起来能跑 100 步但结果不稳定。它不是不会推理而是执行过程中丢了上下文、误用了旧记忆、把 hallucinated output 写进 persistent memory又在后续 session 中继续引用。未来真正有价值的 context engineering不是无限扩大窗口而是给记忆加 provenance、staleness、contradiction handling 和 recovery procedure。LLifecycle and OrchestrationAgent 从单循环走向任务流水线Lifecycle layer 组织 Agent 的执行流程单 Agent 内循环、多 Agent 编排、从 issue 到 PR 的完整任务流水线。论文把 state management 放在 Lifecycle 内部因为状态总是被执行流读取和写入。Figure 9 展示 orchestration 相关工作。Table 2 列出代表性系统包括 OpenCode、Claude Code、Gemini CLI、Codex CLI、Aider、SWE-agent 等 single-agent inner loopDeerFlow、AutoGen、LangGraph、OpenAI Agents SDK、DeepAgents 等 multi-agent orchestrationVibe Kanban、Symphony、GitHub Agentic Workflows 等 full lifecycle pipeline。Table 2: Representative orchestration systems.LevelRepresentative systemsPrimary patternExecution modelSingle-agent inner loopOpenCode, Claude Code, Gemini CLI, Codex CLI, Aider, SWE-agentobserve-act-continue loophybrid or stateless replayMulti-agent orchestrationDeerFlow, AutoGen, LangGraph, OpenAI Agents SDK, DeepAgents, Hivehierarchical / graph / team orchestrationmostly statefulFull lifecycle pipelineVibe Kanban, Symphony, GitHub Agentic Workflowsissue-to-execution-to-review pipelinestateful or hybrid论文的关键观察是Agent 正在从 framework 走向 platform。Framework 包装 agents、tools、memory、execution loopsplatform 则要提供 durable workspaces、managed sandboxes、identity、billing、observability、evaluation、governance 和 human handoff。对于长时 Agent问题不再只是“怎么构建一个 Agent”而是“怎么运营一组 Agent让它们的行动跨多轮、多任务、多用户仍然可检查、可恢复、可回滚”。OObservability and Operations看见发生了什么才可能改进Observability layer 捕获 trace、cost、failure、latency、retries、intermediate messages 和 reliability signals。论文把 Observability 提升为独立层而不是 Lifecycle hook 的副产物因为生产系统里 observability 已经有独立工具栈和工程实践。Figure 10 总结 observability 和 operations 生态包括 Langfuse、OpenTelemetry/OpenLLMetry、Arize Phoenix、AgentOps、TensorZero 等。论文指出一个结构性断裂很多团队有 trace collection但没有把 trace 接入 evaluation 和 regression feedback。LangChain 2026 survey 中89% 团队使用 observability但只有 52.4% 做 offline evaluation。这个断裂很现实。你看得见 Agent 做了什么不代表你知道它做得对不对你知道 final score不代表你知道失败根因。真正有价值的 observability应该能把 production failure traces 转成 regression cases把 cost/latency/anomaly 变成 alert把模型、工具、上下文、沙箱和治理事件关联起来。论文提出一个很好的原则harness-as-assumption。每一个 harness 组件都编码了一个假设模型现在不能自己做某件事所以我们加了 context reset、evaluator feedback loop、tool restriction、permission gate 或 recovery loop。随着模型变强这些组件可能从必要控制变成冗余成本。Observability 不仅要发现 Agent 失败还要发现哪些 harness intervention 已经不再 load-bearing。VVerification and Evaluation不只是打分而是任务到反馈的质量控制循环Verification layer 解决如何评价一个 Agent run。论文强调harness-aware evaluation 应该把分数看作 model-harness pair 的属性而不是模型单体属性。因为同一模型换 harness行为可能大幅变化。Figure 11 展示 verification/evaluation 相关工作包括 SWE-bench、Terminal-Bench、WebArena、OSWorld、AgentBench、GAIA、Promptfoo、DeepEval、R2E-Gym、Meta-Harness 等。Figure 12 是论文对 harness evaluation 的核心抽象task-to-feedback lifecycle。它分成五阶段task and benchmark grounding、pre-execution readiness validation、controlled execution and trace capture、multi-level judgement and failure attribution、continuous regression and deployment feedback。这张图讲清楚了 Agent evaluation 和传统 LLM evaluation 的差别。传统 LLM evaluation 多是固定输入、评分输出Agent evaluation 评估的是一个 execution episode任务嵌入环境Agent 调用工具和状态trace 被捕获评估器判断最终结果和执行路径。Rocky认为未来 Agent benchmark 最大的问题不是“有没有更难任务”而是“能不能减少 evaluation infrastructure noise”。失败可能来自模型推理也可能来自 broken tools、stale context、non-reset sandboxes、flaky tests、benchmark ambiguity、unstable judges。如果评估不能做 failure attributionleaderboard 数字就很容易误导工程判断。GGovernance and Security自主性越强越需要治理栈Governance layer 处理 permission、identity、policy enforcement、component hardening、audit、human oversight。论文把 Governance 提升为独立层因为 Agent 的风险不是只靠内容安全过滤能解决的。Agent 会行动会调用工具会访问文件和网络会跨 session 保留状态会把外部内容带回上下文。Figure 13 展示 governance/security 相关工作包括 permission model、lifecycle hooks、component hardening、declarative constitution、audit infrastructure、agent security landscape 等。Figure 14 把一个 tool-use cycle 拆成四个治理 hookH1 在输入进入 LLM 前做 input guardrailH2 在工具执行前验证 proposed actionH3 在工具输出进入上下文前做 information flow controlH4 对 consequential actions 加 human approval。这张图很实用因为它把 Agent 安全从抽象原则变成了插点。输入要防 prompt injection动作要防越权工具调用工具输出要防不可信数据污染上下文关键动作要人类确认。治理不是模型最后说一句“我会安全行动”而是贯穿 tool-use cycle 的控制结构。Table 3 把治理机制映射到风险类型。Table 3: Mapping governance mechanisms to agent risks.Governance mechanismRisks mitigated or detectedPermission models and identity managementuntrusted interfaces, data leakage, unauthorized actionsInput guardrailsuntrusted input, wrong instruction followingOutput guardrailswrong instruction following, hallucination, data leakage, unauthorized actionsInformation flow controlunconstrained data flow, data leakage, unauthorized actionsComponent hardeninguntrusted input, wrong instruction following, hallucinationMonitoring and auditdata leakage, unauthorized actions, resource drainHuman-in-the-loopwrong instruction following, unauthorized actionsDeclarative constitutioncross-cutting governance configurationTable 4 则显示当前系统治理覆盖仍然稀疏。Codex、Gemini CLI、OpenHands、AutoHarness、Progent、CaMeL、SAGA、IsolateGPT、AgentSpec、SAFEFLOW 等系统在 permission、hooks、hardening、constitution、audit、multi-agent governance 上各有覆盖但没有哪个系统真正完整。Table 4: Governance feature coverage.SystemPermissionHooksHardeningConstitutionAuditMulti-AgentCodexfullpartialpartialpartialpartialpartialGemini CLIfullpartialpartialpartialpartialpartialOpenHandspartialfullpartialpartialpartialpartialAutoHarnessfullfullpartialfullfullpartialProgentfullfullpartialpartialpartialpartialCaMeLpartialfullpartialpartialpartialpartialSAGAfullpartialpartialpartialfullfullIsolateGPTfullpartialpartialpartialpartialfullAgentSpecpartialfullpartialfullpartialpartialSAFEFLOWpartialfullpartialpartialfullfull这里最值得关注的是 information flow control、identity management、formal verification 等能力在很多真实系统里并不完整。Agent 安全现在仍然处在“单点防御很多组合治理不足”的阶段。实验与证据结果能支撑到什么程度这篇论文不是实验型模型论文而是一篇 practice-grounded survey。它的证据主要有三类。第一类是 harness-only gain 的案例证据。论文开头引用三项结果只改工具 harness 带来最高 10 倍 coding benchmark 提升固定 GPT-5.2-Codex 通过 harness 层改造提升 13.7 个百分点Meta-Harness 自动优化 harness 达到 76.4%。这些结果支持 binding-constraint thesis在 long-horizon agent tasks 中harness 变化可以产生超过常规模型小幅升级的表现差异。第二类是生态 mapping 证据。论文把 148 或 170 公开项目映射到 ETCLOVG taxonomy显示 Execution、Tooling、Lifecycle、Verification 覆盖最密Context/Memory 多嵌在大型框架里Observability 和 Governance 在开源可见生态中更薄更多存在于商业平台、SDK feature 或工程博客中。这个发现解释了为什么很多 Agent demo 看起来能跑但生产落地卡在监控、评估和权限治理。第三类是 layer-by-layer 文献综合。论文不是单独讨论 sandbox、memory、tool-use、eval、安全而是把它们放进一个统一控制系统。比如 sandbox escape 属于 Execution 但会影响 Governancetool schema 属于 Tooling 但会占用 Context budget 并影响 Evaluationtrace 属于 Observability 但只有捕捉 identity/permission 才能变成 audit evidence。证据边界也要明确。这篇综述的 corpus 偏向 GitHub-visible 和 coding-agent 生态对闭源生产系统和非 coding Agent 覆盖不足layer assignment 基于公开文档而不是私有架构部分类别的星标和项目状态会随时间变化。它提供的是可见生态的系统画像不是所有 Agent 基础设施的完整普查。Rocky认为这样的证据已经足以支撑一个方向性判断Agent 的下一轮竞争会从模型能力扩展到 harness 质量。但它还不足以回答某个具体 harness 设计在所有场景下是否最优。真正的下一步是把 ETCLOVG 从 descriptive taxonomy 变成 normative design framework给定任务风险、成本约束、模型能力和部署环境应该如何选择每一层的配置。跨层综合这篇论文真正想让我们记住的三个系统效应成本-质量-速度三难强 sandbox、更细 trace、更严格 governance、更深 evaluation 都能提高质量和安全但也会增加延迟、token、存储、人工审计和基础设施成本。生产系统不可能把所有检查都同步做满必须区分哪些检查必须 inline哪些可以 async哪些只进入 regression suite。这对创业团队尤其重要。Agent 产品如果只追求质量可能成本高到无法商业化如果只追求速度可能牺牲可诊断性和安全边界如果只追求低成本可能在复杂任务上出现不可控失败。Harness engineering 本质上是在做 cost-quality-speed 的工程取舍。能力-控制权衡更大的工具菜单、更持久的记忆、更开放的沙箱、更少的人类审批都会提高 Agent 能力上限同时扩大控制问题。工具越多选择错误和 prompt injection 面越大记忆越持久staleness、privacy 和 provenance 风险越大权限越开放错误行动的 blast radius 越大。这说明安全不是后加的 guardrail而是 Agent 能力设计的一部分。一个真正成熟的 Agent不是无限开放工具而是知道什么时候暴露能力、什么时候隐藏能力、什么时候要求确认、什么时候回滚、什么时候停止。Harness Coupling Problem论文最本质的系统洞察是 harness layers 彼此耦合局部优化很容易误导。执行环境会改变评测结果工具描述会改变模型行为上下文策略会影响记忆和评估可复现性observability trace 只有和 identity/permission 绑定才具备治理价值evaluation reward 会反过来塑造 orchestration loop。这解释了为什么 Agent benchmark 很难把分数干净归因给模型。模型M MM加 harness controllerC H C_HCH​才构成实际行为系统。只要你改了 prompt、tool schema、memory、sandbox、verifier、monitor 或 recovery loop你就改了 controller也就改了同一个模型的 measured behavior。Rocky认为这一点对行业判断很关键。未来所谓“某模型 Agent 能力更强”如果不说明 harness 配置其实信息量很低。更严谨的评测应该报告 model-harness pair甚至把 harness intervention 作为实验因子。这篇工作的边界与可复现性第一这篇综述的 taxonomy 是描述性框架不是自动设计指南。ETCLOVG 告诉我们有哪些层但还没有告诉我们不同业务风险、成本预算和模型能力下该怎么取舍。它更像一张地图不是导航系统。第二公开项目 mapping 会随时间变化。论文的 metadata snapshot 是 2026 年 5 月的公开生态GitHub star、项目活跃度、协议成熟度、商业平台能力都会变化。文章结论中的“生态密度”和“覆盖缺口”需要定期更新。第三harness-only gain 的例子很有说服力但并不意味着模型能力不重要。更准确的说法是模型和 harness 是耦合系统。模型越强某些 harness 组件可能变得不必要模型越弱harness 可能需要更强 scaffolding。两者不是替代关系而是共同决定系统表现。第四Governance 和 Observability 的很多问题还停留在早期工程阶段。权限 UI 会不会让用户疲劳多层 guardrail 会不会互相干扰audit log 如何兼顾隐私和可追责policy DSL 如何标准化这些都不是综述能直接解决的问题。第五Agent harness 的生态过于偏 coding-agent。软件工程任务天然有 repo、shell、tests、PR、benchmark因此更容易公开和量化但企业办公、数据分析、科研、客服、运营、供应链等 Agent 的 harness 形态可能不同。ETCLOVG 很可能仍适用但具体层内机制需要扩展。如果继续研究/落地应该关注什么第一把 harness 当成产品基础设施而不是 demo glue code。Agent 产品不能只看模型 API 和前端交互必须设计执行环境、工具协议、上下文状态、任务编排、观测、评估和治理。否则 demo 越强生产风险越大。第二建立 trace-native evaluation。不要只看 final score要把每次 agent run 的 tool call、state change、error、retry、cost、latency、permission decision 都记录下来并转成 failure attribution 和 regression tests。没有 trace 的 Agent无法持续改进。第三做预算感知的 harness。不是所有任务都需要最强沙箱、最深评估、最多 human-in-the-loop。应该按风险分层低风险任务快速执行高风险任务加强权限、审计和验证。真正的工程能力是在质量、成本、速度和风险之间动态调度。第四重视 state handoff。未来 Agent 会从一个模型、一轮对话走向多 Agent、多工具、多 session、多人工交接。每次 handoff 不能只是文本总结还应该传递 intent、constraints、permissions、artifacts、provenance、budget state、risk level、trace history 和 unresolved decisions。第五定期简化 harness。随着模型变强某些 reset、planner、verifier、restriction 可能从必要控制变成成本负担。优秀的 harness 不是越复杂越好而是知道哪些控制仍然 load-bearing哪些应该被移除。术语与概念速查术语解释Agent Harness围绕 LLM Agent 的执行基础设施用于管理上下文、工具、状态、编排、观测、验证和治理。Binding-Constraint Thesis在长时 Agent 任务中实际表现的瓶颈可能更多来自 harness而不只是模型。Prompt Engineering优化单次模型输入的指令、示例和格式。Context Engineering管理多步任务中模型能看到的信息、记忆、检索和压缩。Harness Engineering系统层面优化模型如何运行包括执行环境、工具、编排、验证、安全和反馈。ETCLOVGExecution, Tooling, Context, Lifecycle, Observability, Verification, Governance 七层 taxonomy。Execution EnvironmentAgent 行动发生的环境如沙箱、容器、浏览器、桌面、终端、VM。Tool Interface工具描述、发现、选择和调用的协议层。Lifecycle/OrchestrationAgent 执行循环、多 Agent 协作和完整任务流水线。Observability捕获 trace、成本、延迟、错误、重试和运行状态的能力。Verification对任务结果、执行轨迹、评估器稳定性和失败根因进行判断。Governance权限、身份、策略、guardrail、审计、人类审批和安全控制。Harness Couplingharness 各层彼此影响局部优化可能改变整体行为。Trace-native Evaluation以执行轨迹为核心对象进行评分、诊断和回归测试。拓展思考值得继续扩展研究与思考的创新点这篇综述给我的最大启发是AI Agent 的技术路线正在从“模型中心主义”走向“系统中心主义”。模型当然重要但当模型开始写代码、跑命令、调工具、管理项目、访问企业系统时决定产品可用性的往往是模型外面的工程控制面。Rocky认为未来 Agent 领域会形成三类壁垒。第一类是模型壁垒。更强的推理、更稳的工具调用、更好的长上下文、更低成本的多模态能力仍然会持续提高 Agent 上限。第二类是 harness 壁垒。谁能把执行环境、工具协议、上下文状态、trace、verification、governance 做成稳定平台谁就能把相同模型用出更高可靠性。这类壁垒不像模型参数那样显眼但更接近产品和商业闭环。第三类是组织壁垒。Agent 真正进入企业不只是部署一个助手而是改变任务分配、权限审批、审计责任、知识沉淀和人机协作方式。Harness 本质上也是组织控制系统它决定 Agent 能代表谁行动、能看到什么、能改什么、失败后谁负责。如果说 prompt engineering 是 AI 应用的早期红利context engineering 是长任务红利那么 harness engineering 可能是 Agent 产品化的中场红利。未来大量单点 Agent 工具会被更强模型和通用平台吸收但能把模型、工具、数据、权限、评估和业务流程接成稳定闭环的团队会继续拥有跨周期价值。这也是这篇综述最值得记住的一句话**Agent 的可靠性不是模型单点能力的自然外溢而是模型与 harness 共同构成的闭环系统能力。**模型越强harness 越不能草率因为越能行动的系统越需要边界、证据和治理。推荐阅读Rocky一直在运营技术交流群WeThinkIn-技术交流群这个群的初心主要聚焦于技术话题的讨论与学习包括但不限于算法开发竞赛科研以及工作求职等。群里有很多人工智能行业的大牛欢迎大家入群一起学习交流请添加小助手微信Jarvis8866拉你进群1. 深入浅出完整解析AI AgentAI智能体的核心基础知识2025年可以说是AI Agent全面落地应用的元年因此Rocky在持续撰写对AI Agent的全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识2. 深入浅出完整解析扩散模型DDPM、DDIM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识和Rocky一起学习探究扩散模型的本质原理与和核心基础知识同时不断跟进扩散模型的最新发展。Rocky在本文中对扩散模型的本质做了全面系统的梳理与讲解深入浅出完整解析扩散模型DDPM、DDIM、SDE、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识3. 深入浅出完整解析FLUX.2、Seedream即梦、Z-image、GLM-Image核心基础知识https://zhuanlan.zhihu.com/p/19751746910491895624. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识5. 深入浅出完整解析DeepSeek系列核心基础知识深入浅出完整解析DeepSeek系列核心基础知识6、Sora等AI视频大模型的核心原理核心基础知识网络结构经典应用场景从0到1搭建使用AI视频大模型从0到1训练自己的AI视频大模型AI视频大模型性能测评AI视频领域未来发展等全维度解析文章正式发布码字不易欢迎大家多多点赞Sora等AI视频大模型文章地址深入浅出完整解析Sora、Wan2.1、AnimateDiff、CogVideoX等AI视频大模型核心基础知识7、Stable Diffusion 3和FLUX.1核心原理核心基础知识网络结构从0到1搭建使用Stable Diffusion 3和FLUX.1进行AI绘画从0到1上手使用Stable Diffusion 3和FLUX.1训练自己的AI绘画模型Stable Diffusion 3和FLUX.1性能优化等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion 3和FLUX.1文章地址深入浅出完整解析Stable Diffusion 3SD 3和FLUX.1系列核心基础知识8、Stable Diffusion XL核心基础知识网络结构从0到1搭建使用Stable Diffusion XL进行AI绘画从0到1上手使用Stable Diffusion XL训练自己的AI绘画模型AI绘画领域的未来发展等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion XL文章地址深入浅出完整解析Stable Diffusion XLSDXL核心基础知识9、Stable Diffusion 1.x-2.x核心原理核心基础知识网络结构经典应用场景从0到1搭建使用Stable Diffusion进行AI绘画从0到1上手使用Stable Diffusion训练自己的AI绘画模型Stable Diffusion性能优化等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion文章地址深入浅出完整解析Stable DiffusionSD核心基础知识10、ControlNet核心基础知识核心网络结构从0到1使用ControlNet进行AI绘画从0到1训练自己的ControlNet模型从0到1上手构建ControlNet商业变现应用等全维度解析文章正式发布码字不易欢迎大家多多点赞ControlNet文章地址深入浅出完整解析ControlNet核心基础知识11、LoRA系列模型核心原理核心基础知识从0到1使用LoRA模型进行AI绘画从0到1上手训练自己的LoRA模型LoRA变体模型介绍优质LoRA推荐等全维度解析文章正式发布码字不易欢迎大家多多点赞LoRA文章地址深入浅出完整解析LoRALow-Rank Adaptation模型核心基础知识12、深入浅出完整解析AIGC时代Transformer核心基础知识在AIGC时代中Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向成为AI技术架构大一统与多模态整合的关键核心基座大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析Transformer文章地址深入浅出完整解析AIGC时代Transformer核心基础知识13、最全面的AIGC面经《手把手教你成为AIGC算法工程师斩获AIGC算法offer2024年版》文章正式发布码字不易欢迎大家多多点赞AIGC面经文章地址手把手教你成为AIGC算法工程师斩获AIGC算法offer14、50万字大汇总《“三年面试五年模拟”之算法工程师的求职面试“独孤九剑”秘籍》文章正式发布码字不易欢迎大家多多点赞算法工程师三年面试五年模拟文章地址https://zhuanlan.zhihu.com/p/545374303《三年面试五年模拟》github项目地址希望大家能多多starhttps://github.com/WeThinkIn/Interview-for-Algorithm-Engineer15、Stable Diffusion WebUI、ComfyUI、Fooocus三大主流AI绘画框架核心知识从0到1搭建AI绘画框架从0到1使用AI绘画框架的保姆级教程深入浅出介绍AI绘画框架的各模块功能深入浅出介绍AI绘画框架的高阶用法等全维度解析文章正式发布码字不易欢迎大家多多点赞AI绘画框架文章地址深入浅出完整解析主流AI绘画框架ComfyUI、Stable Diffusion WebUI、Fooocus核心基础知识16、GAN网络核心基础知识网络架构GAN经典变体模型经典应用场景GAN在AIGC时代的商业应用等全维度解析文章正式发布码字不易欢迎大家多多点赞GAN网络文章地址https://zhuanlan.zhihu.com/p/66315730617. AI算法工程师的《三年面试五年模拟》求职秘籍AIGC时代的算法工程师的求职面试秘籍持续更新中18. AIGC产业的深度思考与分析2023年3月21日微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示自从1980年首次看到图形用户界面graphical user interface以来以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。Rocky也认为AIGC及其生态会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期未来随着AIGC的全面落地和深度商用会深刻改变我们的工作、生活、学习以及交流方式各行各业都将被重新定义过程会非常有趣。那么在此基础上我们该如何更好的审视AIGC的未来我们该如何更好地拥抱AIGC引领的革新Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点希望能帮助各位读者对AIGC有一个全面的了解深入浅出全面解析AIGC时代核心价值与发展趋势2025年版