从 Prompt 到 Loop:2026 年生产级 Agent 的工程栈与产品决策
模型能力正在商品化,产品之间真正的差异,越来越多地来自模型之外的那一层。本文梳理 2026 年 Agent 工程的最新演进——Harness Engineering 与 Loop Engineering——并给出面向产品决策的解读:钱该投在哪、指标该盯什么、护城河在哪里。
一、为什么这件事值得产品团队关注
一个正在被反复验证的行业事实是:企业级 Agent 项目的失败率极高(有市场数据称高达 88% 的项目无法进入生产),而失败的原因很少是模型推理能力不足,更多是模型之外的基础设施——上下文管理、工具执行、安全控制、验证机制——不成熟。
由此形成了 2026 年最重要的一个架构共识:
Agent = Model + Harness
模型是一个无状态的、概率性的"推理计算器";Harness(挂具/执行框架)是围绕它的运行时基础设施,负责把概率性的推理翻译成可依赖的确定性行动。一句被广泛引用的工程信条是:
模型可以是概率性的,基础设施绝不能是。
对产品团队的直接含义:当所有竞品都能接入同样的前沿模型时,决定任务成功率、可靠性和用户信任的是你的 Harness,而不是你选了哪个模型。 这就是 2026 年的护城河所在。
二、技能栈的四阶段演进
理解当前的技术版图,先看这条演进线:
| 阶段 | 时期 | 核心问题 | 关键手段 |
|---|---|---|---|
| 1. Prompt Engineering | 2022–2023 | "我该怎么措辞?" | 指令优化、few-shot |
| 2. Context Engineering | 2024–2025 | "模型该看到什么信息?" | RAG、MCP、项目规则注入 |
| 3. Harness Engineering | 2026 | "如何让 Agent 自主、准确、可控?" | 运行时框架、护栏、验证循环 |
| 4. Loop Engineering | 2026 年中– | "如何设计一个不需要我在场的系统?" | 目标契约、状态层、自动验证、终止条件 |
每一层都不取代上一层,而是叠加:Loop Engineering 设计循环本身,Context Engineering 管理每一轮模型看到什么,Harness Engineering 是围绕模型的整个系统(包括循环)。构建可靠的 Agent,三者缺一不可。
三、Harness Engineering:生产 Agent 的"操作系统"
3.1 核心理念
Harness 工程把 LLM 视为"冻结的推理内核",把安全、执行准确性、多步编排、记忆管理的责任全部转移到宿主应用的基础设施上。Mitchell Hashimoto 在 2026 年初确立的原则最能概括这个思路:
每当发现 Agent 犯错,就花时间设计一个方案,让它在结构上不可能再犯同样的错。
注意这句话的产品含义:修复的对象是 系统,不是 prompt。反复手工修补 prompt 是没有复利的;沉淀进 Harness 的每一条规则、每一个护栏,都是可积累的资产。
3.2 生产级 Harness 的典型分层
一个生产级 Harness 通常包含五层:
- 工具编排(Tool Orchestration) —— 2026 年的主流做法是用 MCP 或标准化 JSON Schema 严格定义能力边界,每个工具携带详细元数据,并限制单次推理暴露的工具数量,避免模型的"认知过载"。
- 验证循环(Verification Loops) —— 强制"思考—行动—观察"闭环,Agent 每执行一个动作,Harness 强制它观察结果。
- 上下文与记忆(Context & Memory) —— 上下文压缩(compaction)、跨会话状态持久化、反馈写回:当人类审核者拒绝 Agent 的产出时,纠正信息与失败轨迹配对,作为主动规则约束写入记忆库。
- 护栏(Guardrails) —— 权限检查、审批门、沙箱隔离,绝不允许无限制执行。
- 可观测性(Observability) —— 所有状态转换必须可观测,每次运行留下完整轨迹(trace)。
3.3 Inner Harness vs Outer Harness
一个对产品定位很关键的区分:
- Inner Harness:前沿实验室内置于模型的部分——基础安全层、原生工具调用、原始上下文窗口。这部分你买模型就自带,不构成差异化。
- Outer Harness:企业自建的定制配置、环境路由、测试框架、情境化业务规则。这才是真正的工程护城河。
产品判断:预算和人力应压在 Outer Harness 上,不要重复造实验室已经内置的轮子。
3.4 主流工具版图(选型参考)
- 编排框架:按架构分为图式、角色式、对话式三类。LangGraph(图式)通过条件边、检查点、流式处理提供细粒度状态控制,在 2026 年对比基准中达到 87% 的任务成功率;其他常见选择包括 CrewAI、AutoGen、OpenAI Agents SDK 等。
- 开箱即用的 Harness:LangChain 的 DeepAgents(自带规划工具、文件系统访问、内置工作流)、Anthropic 的 Claude Agent SDK(源自 Claude Code 的内部机制)、面向编码场景的 Amp Code。
- 新一代融合框架:如 Mastra,已将 LLM-as-judge 的 eval 系统直接内置——运行时与评估能力正在同一产品中融合。
四、生产 Agent 中的两种 Harness:Runtime 与 Eval
这是生产实践中最容易被忽略、但对组织分工和排期影响最大的一个区分。
4.1 定位差异
| Runtime Harness | Eval / QA Harness | |
|---|---|---|
| 所在路径 | 线上实时请求路径 | 离线 / 开发时路径 |
| 职责 | 让 Agent 每一次都跑对 | 证明它跑对,且改动后不会跑坏 |
| 类比 | 生产环境的操作系统 | CI/CD + 回归测试 |
| 核心组件 | 模型调用、工具分发、输出解析、错误恢复、护栏、终止判断 | Golden 数据集、批量执行器、轨迹收集、评分指标 |
| 失败后果 | 用户直接受损 | 发布被阻断(这是好事) |
需要澄清的是:Eval Harness 不是与 Agent Harness 并列的东西,而是 Agent Harness 多层结构中的验证层——Agent Harness 横跨工具编排、状态持久化、错误恢复、验证循环、安全强制等多个层面,Runtime 和 Eval 是其中两个不同路径上的层。
4.2 Eval Harness 具体长什么样
它端到端地运行评估:遍历一个 golden 数据集,对每条调用 Agent,收集响应和完整执行轨迹,再用一套指标打分。学术界的 lm-evaluation-harness、HELM 是它的前身,但 MMLU 这类学术基准是为基础模型研究设计的;生产 Agent 需要基于自己业务任务的基准集。
一个典型实现(来自学术评测实践)的关键设计点,值得直接抄作业:
- 受控循环:LLM 生成 → 提取代码 → 沙箱执行 → 返回观察,步数上限(如 100 步);
- 双层超时:单命令超时 + 总时长超时;
- 无重试:每次复现都是单次尝试,保证可比性;
- 全轨迹记录:对话历史、工具调用、输出全部留存,支持事后分析。
4.3 Eval 与 Guardrail:同一个检查器,两个位置
一个精妙的洞察:评估(eval)和护栏(guardrail)的打分机制可以完全相同——比如同一个 LLM-as-a-judge——区别只在部署位置:
- 放在线上每个请求路径里,拦截坏输出并重试/降级 → 这是 Guardrail,属于 Runtime Harness 的错误处理部分,且正在快速商品化;
- 放在离线批量回归里,对发布质量把关 → 这是 Eval,是 QA Harness 的核心。
产品含义:检查器/评分器是可以在两条路径间复用的资产,设计时就应该按"一次构建、两处部署"来规划。
4.4 把两者连成飞轮
生产运营的正确模型不是把两者分开维护,而是形成闭环。OpenAI 在 Codex 的实践中把这个模式讲得很直白:harness 是围绕模型的完整契约,飞轮是——
线上轨迹(traces)→ 反馈(feedback)→ 沉淀为 evals → 据此演化 harness → 回到线上
即:追踪每一次运行,把失败转化为 evals,再用 evals 来演化 harness,而不是反复手工修补 prompt。每一个线上事故都应该变成一条永久的回归用例——这是 Agent 产品质量的复利来源。
五、Loop Engineering:2026 年中的新浪潮
5.1 起源与定义
爆发点非常明确:2026 年 6 月第二周,Peter Steinberger 提出真正的技能已从"提示 Agent"转向"设计 Agent 的循环";次日,Google Chrome 工程负责人 Addy Osmani 发表《Loop Engineering》一文将实践命名并结构化,相关讨论几天内传播超 650 万次浏览。另一个催化剂是 Claude Code 创造者 Boris Cherny 对自己工作流的描述:
我不再手动提示 Claude 了,是那些运行中的循环在提示 Claude、并决定该做什么。
定义上的对比:
- Prompt Engineering 问:"我该说什么,才能得到最好的输出?"
- Loop Engineering 问:"我该构建什么系统,让 Agent 自己找到工作、执行、验证、并记住做过什么——完全不需要我在循环中?"
5.2 核心技术模式
五层模型:Harness(环境)→ Loop Contract(定义"完成"意味着什么)→ State 层(能在重启后存活的文件与任务列表)→ Checker(自动化验证)→ Human Checkpoint(人类介入点)。
Ralph 技术:由 Geoffrey Huntley 在 2026 年初命名,在一个朴素的 while 循环里反复用同一个 prompt 驱动编码 Agent。"看起来蠢到不可能有效,但它有效"——不那么显然的关键洞察是上下文重置:长会话会因窗口被旧推理、死胡同、过期文件内容填满而退化,每轮重启反而保持了模型的清醒。
产品原生化:这些组件已从自维护脚本变成产品内置能力——Claude Code 在 2026 年 5 月的版本中加入原生 /goal 循环(跨轮次运行直到条件为真,由独立的快速模型在每轮后给工作打分);Codex CLI 也在 4 月底发布了同样的原语,外加 Automations 与分诊收件箱。
嵌套循环视角:Andrew Ng 补充的产品构建框架——分钟级的内层 agentic coding 循环,嵌套在小时级的开发者反馈循环、再嵌套在天级的外部用户反馈循环之中。这对排期和迭代节奏设计很有参考价值。
趋势:2026 年最强的编码 Agent 都在走向更长时间运行、自我验证的 "while-not-done" 循环,配合强终止逻辑,以及由子 Agent 处理的并行子循环。
5.3 最重要的洞察:验证器是瓶颈
几乎所有科普都跳过、但对资源分配影响最大的一点:
在任何循环中,瓶颈是验证器(verifier),不是模型。
模型现在自己写 prompt,稀缺技能变成了定义"好"和"完成"意味着什么。配套的最佳实践是:不要让 Agent 评估自己的输出,构建独立的 evaluator / verifier 组件在发布前捕获错误。
这与第四节的 Eval Harness 直接打通:离线评估中沉淀的评分器,会被复用为线上循环里的 checker。投资验证能力,是同时提升 Runtime 质量和 Loop 自主性的一份投入、两份回报。
5.4 必须正视的风险与冷静的声音
- 安全:循环观察到的一切内容(网页、文件)都是不可信输入,存在提示注入风险——执行真实动作的循环必须运行在隔离沙箱中。
- 成本:token 消耗是真实的批评点,已出现企业设置每人每月 1500 美元上限的案例;成本护栏必须是循环设计的一等公民。
- 自主性被高估:有媒体指出,实际运行仍需要比演示中多得多的人工引导;厂商遥测数据也存在采样偏差(数据来自已经在深度使用产品的人群)。
- 概念祛魅:"这不就是个 while 循环吗"的质疑并非全无道理——名词是新的,但价值取决于契约、状态、验证、终止这些工程细节做得多扎实。
产品判断:Loop Engineering 是真实的实践演进,但当前宣传热度超前于普遍落地程度。规划路线图时,把它当作"渐进扩大自主半径"的方向,而不是一步到位的全自动愿景。
六、落地清单:产品团队的行动项
架构与投入
- 明确区分并分别立项:Runtime Harness(线上)与 Eval Harness(离线)是两条路径、两种 SLA,但共享检查器资产。
- 预算压在 Outer Harness(业务定制层),不重复建设模型自带的 Inner Harness 能力。
- 验证器优先:在增加模型预算之前,先问评分器和 golden 数据集够不够好——瓶颈大概率在这里。
流程与飞轮
- 建立 "trace → 失败 → eval 用例 → harness 改进" 的强制闭环;每个线上事故必须产出一条回归用例。
- 拒绝手工修 prompt 作为长期方案;修复必须沉淀为结构化的 Harness 规则。
指标体系(衡量一个循环的方式)
- 目标达成率(goal success rate)、达成所需迭代次数、单位任务成本——这是 Loop 的三个基本面指标;辅以护栏拦截率、eval 回归通过率、人工介入频率。
风险控制
- 任何执行真实动作的循环:沙箱 + 权限白名单 + 成本上限 + 强终止条件,四件套缺一不可上线。
- 对"全自动"保持克制的对外承诺:当前阶段,Human Checkpoint 是设计的一部分,不是妥协。
结语
2026 年 Agent 产品竞争的重心已经清晰:模型决定能力下限,Harness 决定可靠性,Loop 决定自主性上限,而 Eval 决定你敢不敢发布。四者中,只有第一项是买来的,后三项都是建出来的——这正是产品团队的战场。