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

写在前面

欢迎大家关注Rocky的公众号：WeThinkIn
欢迎大家关注Rocky的知乎：Rocky Ding
AIGC算法工程师/开发工程师面试面经秘籍分享：WeThinkIn/Interview-for-Algorithm-Engineer欢迎大家Star～

AIGC时代的《三年面试五年模拟》AI算法工程师求职面试秘籍独家资源：【三年面试五年模拟】AI算法工程师面试秘籍

Rocky最新撰写AI Agent（AI智能体）的深入浅出全维度解析文章：深入浅出完整解析AI Agent（AI智能体）的核心基础知识

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 能力主要来自模型能力：只要模型足够强，再配上好 prompt，Agent 行为就会足够可靠。

这篇综述认为这个假设正在失效。真实部署里，Agent 的失败常常不是因为模型完全不懂任务，而是因为外层系统没有把任务执行变成可控、可观测、可恢复的过程。工具描述太多会让模型选错；上下文压缩会丢掉关键约束；沙箱没有 reset 会污染评测；权限边界不清会放大风险；没有 trace 就无法知道失败来自模型、工具、环境还是评估器；没有 governance，Agent 的自主性越强，出错半径越大。

论文把这个外层系统称为 agent execution harness：它是围绕语言模型的一层基础设施，负责上下文构造、工具交互、编排控制、反馈验证和执行约束。它的核心作用，是把一次次模型调用变成“有边界、带状态、可执行、可追踪、可恢复”的长时任务过程。

Figure 1 用三阶段演化解释了这个转变。Prompt engineering 优化的是单次模型输入；Context engineering 优化的是模型在多步任务中看到什么；Harness engineering 优化的是模型如何运行，包括工具、环境、编排、验证、治理和安全。它不是替代 prompt 或 context，而是把它们吸收到一个更大的系统层里。

这张图背后有一个行业判断：Agent 不是聊天机器人多接几个 API，而是模型开始进入“执行世界”之后产生的新系统形态。只要模型能够写文件、跑命令、调用浏览器、操作数据库、委托子 Agent、影响外部环境，工程焦点就会从“怎么问模型”转向“怎么约束和验证模型的行动”。

核心思路：用 ETCLOVG 把 Agent Harness 拆成七层

论文的核心贡献是 ETCLOVG 七层 taxonomy：Execution 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 sandboxes；Tool 下有 protocol standards、tool discovery、tool-augmented training、session management；Context 下有 active context、session state、long-term memory、long-horizon techniques、context drift；Lifecycle 下有 single-agent loop、multi-agent orchestration、full task pipeline；O/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，而是给出了“可见生态”的系统地图。

E：Execution Environment and Sandbox，Agent 行动的物理边界

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 会多步自主执行，人类不可能每一步都 intervene；prompt 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，它们本质上是在把模型输出接到真实操作系统上，沙箱不是可选项，而是产品的安全地基。

T：Tool 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.

这张表非常有启发。很多人会问 MCP 和 A2A 谁会赢，但论文提醒我们：它们其实跨越的是不同边界。MCP 更像 Agent 访问工具和上下文资源的协议；A2A 更像 Agent 应用之间的协作协议；AGENTS.md 则是把 repo/env 里的工作约束版本化。真正的 harness 往往需要它们组合，而不是在一个协议里解决所有问题。

C：Context 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。

L：Lifecycle and Orchestration，Agent 从单循环走向任务流水线

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 loop；DeerFlow、AutoGen、LangGraph、OpenAI Agents SDK、DeepAgents 等 multi-agent orchestration；Vibe Kanban、Symphony、GitHub Agentic Workflows 等 full lifecycle pipeline。

Table 2: Representative orchestration systems.

论文的关键观察是：Agent 正在从 framework 走向 platform。Framework 包装 agents、tools、memory、execution loops；platform 则要提供 durable workspaces、managed sandboxes、identity、billing、observability、evaluation、governance 和 human handoff。对于长时 Agent，问题不再只是“怎么构建一个 Agent”，而是“怎么运营一组 Agent，让它们的行动跨多轮、多任务、多用户仍然可检查、可恢复、可回滚”。

O：Observability 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。

V：Verification 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 attribution，leaderboard 数字就很容易误导工程判断。

G：Governance 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 拆成四个治理 hook：H1 在输入进入 LLM 前做 input guardrail；H2 在工具执行前验证 proposed action；H3 在工具输出进入上下文前做 information flow control；H4 对 consequential actions 加 human approval。

这张图很实用，因为它把 Agent 安全从抽象原则变成了插点。输入要防 prompt injection，动作要防越权工具调用，工具输出要防不可信数据污染上下文，关键动作要人类确认。治理不是模型最后说一句“我会安全行动”，而是贯穿 tool-use cycle 的控制结构。

Table 3 把治理机制映射到风险类型。

Table 3: Mapping governance mechanisms to agent risks.

Table 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.

这里最值得关注的是 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 但会影响 Governance；tool schema 属于 Tooling 但会占用 Context budget 并影响 Evaluation；trace 属于 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，哪些应该被移除。

术语与概念速查

拓展思考：值得继续扩展研究与思考的创新点

这篇综述给我的最大启发是：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 Agent（AI智能体）的核心基础知识

2025年可以说是AI Agent全面落地应用的元年，因此Rocky在持续撰写对AI Agent的全维度解析文章：深入浅出完整解析AI Agent（AI智能体）的核心基础知识

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/1975174691049189562

4. 深入浅出完整解析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 3（SD 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 XL（SDXL）核心基础知识

9、Stable Diffusion 1.x-2.x核心原理，核心基础知识，网络结构，经典应用场景，从0到1搭建使用Stable Diffusion进行AI绘画，从0到1上手使用Stable Diffusion训练自己的AI绘画模型，Stable Diffusion性能优化等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

Stable Diffusion文章地址：深入浅出完整解析Stable Diffusion（SD）核心基础知识

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文章地址：深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

12、深入浅出完整解析AIGC时代Transformer核心基础知识

在AIGC时代中，Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向，成为AI技术架构大一统与多模态整合的关键核心基座，大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析：

Transformer文章地址：深入浅出完整解析AIGC时代Transformer核心基础知识

13、最全面的AIGC面经《手把手教你成为AIGC算法工程师，斩获AIGC算法offer！（2024年版）》文章正式发布！

码字不易，欢迎大家多多点赞：

AIGC面经文章地址：手把手教你成为AIGC算法工程师，斩获AIGC算法offer！

14、50万字大汇总《“三年面试五年模拟”之算法工程师的求职面试“独孤九剑”秘籍》文章正式发布！

码字不易，欢迎大家多多点赞：

算法工程师三年面试五年模拟文章地址：https://zhuanlan.zhihu.com/p/545374303

《三年面试五年模拟》github项目地址（希望大家能多多star）：https://github.com/WeThinkIn/Interview-for-Algorithm-Engineer

15、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/663157306

17. 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年版）