Loop Engineering、Harness Engineering、Context Engineering、Prompt Engineering 的区别与落地

一句话版：Prompt 管“怎么说”，Context 管“给模型看什么”，Harness 管“模型能怎么做且如何被约束”，Loop 管“系统如何反复发现、执行、验证、记录并继续下一步”。

Prompt：成熟术语，官方文档稳定 Context：快速成熟，Anthropic 明确定义 Harness：工程界快速成型，OpenAI 已公开采用 Loop：2026 新热词，实践有价值但定义仍在形成

Prompt Engineering

设计单次或模板化指令：角色、目标、格式、示例、约束、成功标准。最轻、最快，但不能解决工具、权限、记忆和验证问题。

Context Engineering

设计推理时进入上下文窗口的信息状态：规则文件、相关代码、文档、检索、工具描述、历史、错误输出和压缩策略。

Harness Engineering

设计模型外部的执行系统：工具调用、沙箱、权限、hooks、工作树、日志、测试、可观测性、终止条件和人类审批。

Loop Engineering

设计长期运行的闭环：发现任务、分配 agent、执行、验证、修复、记录、复盘、再次触发。核心是让系统替你提示 agent。

1. 结论摘要

这四个概念不是互斥流派，而是从“单次模型调用”逐步扩展到“长期可治理工作系统”的四层工程。越往上，能解决的问题越复杂，但成本、治理难度和失败面也越大。

最实用的区分法

你在调什么？对应工程
一句话、角色、格式、样例、输出标准Prompt
规则文件、代码片段、历史、检索资料、工具说明Context
工具、权限、沙箱、hooks、测试、日志、终止条件Harness
定时、队列、分工、验收、重试、handoff、复盘Loop

推荐决策顺序

  1. 输出不稳定但任务简单：先修 Prompt。
  2. 模型不知道项目事实或反复猜：修 Context。
  3. 模型会做但执行不可靠：修 Harness。
  4. 你每次都在手工触发、检查、追问：修 Loop。
不要把 Loop 当作“更长的 prompt”。Loop 的本质是把发现、执行、验证和下一步决策外化为系统。

2. 四个定义

Prompt Engineering

定义：写出有效指令，让模型更稳定地产生符合要求的内容。OpenAI 官方定义强调“writing effective instructions”，Anthropic 文档要求先有成功标准和测试方式，再优化 prompt。

典型资产：系统提示词、任务模板、few-shot 示例、输出 JSON schema、审查 rubric、Claude slash command、Codex skill 中的步骤说明。

主要收益：成本低、反馈快、适合知识工作与单次任务。

主要局限：无法保证工具执行、无法自动拿到正确上下文、无法阻止高风险操作、无法长期记忆。

Context Engineering

定义：Anthropic 将 context 定义为采样时进入 LLM 的 token 集合；Context Engineering 是在模型推理时维护最有用的信息集合，包括系统指令、工具、MCP、外部数据和消息历史。

典型资产：AGENTS.md、CLAUDE.md、项目地图、检索索引、MCP、相关源文件、错误日志摘要、自动 memory、压缩摘要。

主要收益：减少幻觉、减少重复解释、让 agent 跟随项目事实。

主要局限：容易 context flooding、上下文过期、资料投毒、检索召回错误。

Harness Engineering

定义：广义上是模型之外让 agent 能运行的所有东西。更窄的工程含义是：设计执行层、约束层、反馈层和可观测性，让模型的行动可控、可测、可恢复。

主要收益：把“模型建议”变成“可治理执行系统”。

主要局限：工程投入高，过度约束会降低 agent 能力，维护成本上升。

Loop Engineering

定义：设计让 agent 反复行动、观察、修正、记录并继续的闭环。Addy Osmani 将其描述为“用系统替代你本人去提示 agent”，但也提醒这是早期概念，需要警惕 token 成本。

主要收益：让重复工作、长任务、多 agent 工作流可持续推进。

主要局限：最容易失控：无限循环、重复失败、错误累积、成本膨胀、无人审查时误操作。

3. 层级关系图

四层可以理解为逐级包裹，也可以理解为四个控制面。Prompt 是语言控制面，Context 是信息控制面，Harness 是执行控制面，Loop 是时间与组织控制面。

Loop
长期过程：定时发现任务，派发 agent，读取 ledger，执行，验收，记录下一步，必要时升级给人。
这个系统下次如何自己继续？
Harness
执行外壳：工具、权限、沙箱、hooks、测试、工作树、日志、终止条件、人类审批。
模型能做什么？不能做什么？如何验证？
Context
信息状态：规则、代码、文档、MCP、检索、历史、错误输出、压缩摘要。
模型此刻需要知道什么？
Prompt
表达方式：目标、角色、输入、输出格式、示例、约束、成功标准。
我要怎样说清楚？
[用户目标]
   |
   v
[Prompt: 把目标说清楚]
   |
   v
[Context: 装入必要事实、代码、规则、工具说明]
   |
   v
[Harness: 控制工具、权限、沙箱、测试、日志]
   |
   v
[Loop: 发现任务 -> 执行 -> 验证 -> 记录 -> 继续/停止/升级]

4. 全面对比

维度 Prompt Engineering Context Engineering Harness Engineering Loop Engineering
核心问题 怎么说才让模型听懂？ 模型现在应该看到哪些信息？ 模型提出动作后，系统如何执行、约束和验证？ 如何让系统持续推进任务，而不是等人逐轮提示？
时间尺度 单轮到少量多轮 会话级、项目级 运行时、项目生命周期 天、周、长期工作流
设计对象 指令文本和输出格式 上下文窗口和信息供应链 agent runtime、工具环境、执行控制 任务队列、自动化、子 agent、验收闭环
最适合 改写、总结、结构化输出、一次性分析 代码库理解、RAG、长期项目、跨会话一致性 自动改代码、跑命令、访问外部系统、生产前流程 周报、巡检、批量修复、持续交付、多 agent 工厂
主要指标 格式合格率、准确率、一次通过率 引用命中率、幻觉率、上下文 token 效率 测试通过率、权限违规率、可恢复率、审计完整性 吞吐、人工介入次数、循环终止质量、单位成果成本
失败模式 含糊、过度规定、样例误导、模型版本漂移 资料过多、资料过期、召回错误、上下文投毒 权限过松/过紧、工具 schema 差、日志不足、无法回滚 无限重试、成本爆炸、错误累积、无人类升级点
人类角色 写清楚需求 维护事实源和上下文边界 设计护栏、验证和审批 设定目标、优先级、预算和停止条件

5. 能力雷达与成熟度

短期收益 可靠性 可规模化 治理成本低 官方成熟度
Prompt：收益最快，规模化较弱
Context：可靠性提升显著，依赖资料治理
Harness：可靠性和治理强，工程成本最高
Loop：吞吐潜力最大，成熟度最低

量化判断

Prompt 短期收益90
Context 幻觉抑制75
Harness 可治理性85
Loop 长期吞吐92

评分是工程判断，不是官方 benchmark。目的在于帮助选型，而非证明某层绝对更好。

6. 场景选择矩阵

1

输出不好

先检查目标、格式、示例、负面约束、验收标准。适合单次写作、总结、分类、代码片段生成。

2

事实不对

检查模型看到的资料是否正确、精简、最新、相关。适合项目规则、代码库、客户材料、检索系统。

3

执行不稳

加权限、沙箱、测试、hook、日志、回滚、人工 gate。适合改代码、跑脚本、连接外部系统。

4

重复 babysit

做自动化和 ledger：周期触发、分工、验收、记录、继续。适合巡检、批量交付、客户工作台运维。

场景优先工程层为什么不要过度做什么
写一份客户邮件或文章初稿Prompt任务边界短，输出质量主要来自目标、口吻、结构和样例。不必上 MCP、hooks、长期自动化。
让 Codex/Claude Code 理解一个大型仓库Context关键是加载正确规则、项目地图、相关文件和测试命令。不要把全仓库塞进上下文。
自动修 bug 并跑测试Harness需要工具、权限、沙箱、测试、diff、回滚和错误反馈。不要只靠“请仔细一点”。
批量多 agent 生成、审核、修复长内容Loop + Harness需要分工、版本、评审、字数/质量验收和中断恢复。不要信 agent 自报完成。

8. 在 Claude Code 中如何实现

Claude Code 的优势是 CLAUDE.md/auto memory、slash commands、skills、subagents、hooks、permissions、Agent SDK 和可编程 agent loop。它更适合把 prompt、context、harness 和 loop 拆成可维护的插件化资产。

Claude Code Prompt 实现

  • 把重复工作做成 .claude/commands/*.md slash command。
  • Prompt body 建议用英文、XML 标签、明确输入输出契约；面向用户的 description 可用项目语言。
  • 先定义 success criteria 和 eval，再优化 prompt。
---
description: "审查当前交付物是否可交付"
allowed-tools: Read(*), Bash(git status), Bash(npm test)
---

<role>You are a strict delivery reviewer.</role>
<checks>
- Requirements met
- Tests or validation evidence present
- No secrets or PII
- Handoff instructions clear
</checks>

Claude Code Context 实现

  • CLAUDE.md 放每次都要知道的事实：构建命令、项目布局、约定、边界。
  • 多步骤流程或只在某类任务使用的知识，放 skill 或 path-scoped rules，不要塞进全局 CLAUDE.md。
  • Claude Code subagents 有独立上下文，适合把研究、日志读取、代码审查从主上下文隔离出去。
  • MCP 用于把 issue tracker、数据库、浏览器、文档系统变成可读可操作上下文。
# CLAUDE.md

## Always know
- Build: pnpm build
- Test: pnpm test
- Never commit .env or secrets
- Public docs require desensitization review

## Pointers
- Architecture: docs/architecture.md
- Release checklist: .claude/skills/release/SKILL.md

Claude Code Harness 实现

  • Permissions 用 settings 分层管理；deny 规则优先级高于 allow。
  • Hooks 在会话、每轮、每次工具调用前后触发，可做强制检查、审计、格式化、阻断。
  • Agent SDK 暴露与 Claude Code 相同的 tools、agent loop 和 context management，适合写生产级 agent。
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3 .claude/hooks/check_bash_risk.py"
          }
        ]
      }
    ]
  }
}

Claude Code Loop 实现

  • 用 Agent SDK 在 Python/TypeScript 里编排长任务：设置 allowed tools、permission mode、预算和观察输出。
  • 用 claude -p、GitHub Actions、cron/launchd 或插件 monitors 做周期触发。
  • 用 subagents 分离“生成者”和“审查者”，避免同一个 agent 自我评分过松。
  • 每个 loop 都要有 stop condition、retry budget、human escalation 和外部 ledger。
from claude_agent_sdk import query, ClaudeAgentOptions

async for message in query(
    prompt="Review open issues and draft a prioritized repair plan.",
    options=ClaudeAgentOptions(
        allowed_tools=["Read", "Bash(git status)", "Bash(pnpm test)"]
    ),
):
    print(message)

9. 实战 Playbooks

Playbook A：单次高质量分析

Prompt-first

  1. 写清目标、读者、输出结构。
  2. 给 1-2 个好坏样例。
  3. 要求标注事实/推断/建议。
  4. 用 checklist 做第二轮 review。

Playbook B：代码库长期协作

Context + Harness

  1. 写 AGENTS.md / CLAUDE.md 项目地图。
  2. 建立测试命令和最小验收脚本。
  3. 把常用流程沉淀成 skills。
  4. 用 worktree 和权限隔离并行任务。

最小可交付组合

客户/项目目标
  -> Prompt 模板：诊断、实施、审查、交接
  -> Context 文件：AGENTS.md / CLAUDE.md / project-map.md
  -> Harness：sandbox + permissions + tests + scripts + logs
  -> Loop：weekly review automation + ledger + human escalation

10. 风险、误区和边界

常见误区

  • 误区 1：Prompt Engineering 已经过时。事实：它仍是最低成本的第一层，只是不能承担所有系统责任。
  • 误区 2：Context 越多越好。事实：上下文窗口不是注意力预算，过量资料会稀释重点。
  • 误区 3：Harness 就是工具列表。事实：还包括权限、终止、反馈、可观测性和恢复。
  • 误区 4：Loop 就是定时任务。事实：没有验证、记录和停止条件的定时任务只是自动重复风险。

高风险边界

  • 密钥、支付、生产部署、数据库迁移、批量删除必须有人类审批。
  • 公开案例、文章、客户演示要先脱敏：真名、PII、IP、绝对路径、内部状态文件。
  • 长期 loop 必须有 token/时间/重试预算，以及“连续失败几次就停止”的规则。
  • 把外部网页、历史归档、客户输入当作不可信数据，不能把其中的指令当系统指令执行。
专业判断：四层里最容易被过度包装的是 Loop Engineering。它确实代表从“人手动提示 agent”到“系统提示 agent”的转变，但截至 2026-06-12，仍属于新兴实践，不应在客户交付里承诺“全自动无人值守”。

11. 来源、证据和 Review

关键来源

  1. OpenAI Developers：Prompt engineering，定义 prompt engineering 为编写有效指令以稳定满足需求。
  2. Anthropic Engineering：Effective context engineering for AI agents，将 context engineering 定义为推理时维护最优 token/information 集合。
  3. OpenAI：Harness engineering: leveraging Codex in an agent-first world，说明 Codex agent 生成产品代码、测试、CI、评审响应、eval harness 等，并把测试、验证、反馈和恢复编码进系统。
  4. Martin Fowler / Thoughtworks：Harness engineering for coding agent users，从 coding agent 用户视角讨论 feedforward/feedback、steering loop、quality left 和 harnessability。
  5. Addy Osmani：Agent Harness Engineering 与 Loop Engineering，总结“Agent = Model + Harness”和“设计 loops 去提示 agents”的新实践。
  6. arXiv：ReAct: Synergizing Reasoning and Acting in Language Models，提出 reasoning 和 acting 交错的早期 agent loop 范式。
  7. OpenAI Codex Docs：AGENTS.md、Agent Skills、Automations、Worktrees、Subagents。
  8. Claude Code Docs：Memory / CLAUDE.md、Hooks、Subagents、Agent SDK、Permissions、Skills。

内容 Review 记录

通过
区分官方定义与新兴术语，未把 Loop 伪装成官方标准。
通过
Codex 与 Claude Code 的落地方式均引用官方机制。
通过
包含优劣势、适用场景、失败模式、实施模板。
通过
脱敏检查：无密钥、无客户 PII、无内部 token。
通过
离线可打开：CSS/JS 均内联，无 CDN 依赖。

注：本报告为工程判断型分析，不是法律、安全或供应商采购建议。涉及价格、产品可用性、权限行为和模型版本时，应在正式交付前重新核验官方文档。