Ryan Lopopolo —OpenAI

Humans steer. Agents execute.

The lack of hands-on human coding introduced a different kind of engineering work, focused on systems, scaffolding, and leverage.

马克的技术工作坊

        工程领域真正的进步，往往不在于发明了什么新技术，而在于有没有一套统一的框架把这些零散的能力组织起来，以变成可以系统设计、可持续优化的工程方法。在Agent开发中，随着模型能力持续增强，今天这些用来约束模型、纠正模型和给模型兜底的系统设计很可能会被模型自身逐步吸收。                                                                                          

一、 Prompt Engineering/Context Engineering/Harness Engineering/Loop Engineering在系统层级（Floor）的纵向演化关系

        Google 工程师 Addy Osmani 曾提出一个极为精妙的“楼层隐喻（The Multi-Story Framework）”。这四个工程范式绝非平行替代关系，而是逐层向上搭建、空间彼此依存的高维演化实体：

Floor 1：Prompt Engineering（基础地表：执行单元）

        解决的是大模型对单次原子任务的理解力。它为模型注入最初的角色（Role）、任务（Task）与输出格式（Schema）。它是最底层的执行引擎。

Floor 2：Context Engineering（第二层空间：环境感知）

        当单一 Prompt 无法承载海量知识，且受限于上下文窗口（Context Window）时，演化出了 Context 工程。它专注于渐进式信息检索与知识密度压缩，将企业的私有数据、代码库上下文，以最低的 Token 成本“喂”给底层的 Prompt 单元。

Floor 3：Harness Engineering（第三层空间：刚性沙箱与治理边界）

        有了 Prompt 和 Context，Agent 依然是个在裸机上乱跑的“概率性怪兽”。LangChain 在《The Anatomy of an Agent Harness》中指出，Harness 是环绕在模型周围除模型本身之外的所有代码、硬核约束和基础设施的总和。它向下接管持久化文件系统、隔离的 Bash 沙箱、安全护栏（Guardrails），以及严格的依赖拓扑结构，将大模型驯服为“确定性”的工业机器。

Floor 4：Loop Engineering（顶层空间：长时序自主进化闭环）

        “Loop engineering is the shift from prompting AI agents by hand to designing the systems that prompt them.” Loop 处于整个大厦的最高层，它将底层的 Harness 沙箱和 Agent 单元编排成一个无需人类介入的、自运行的、具备递归目标的闭环网络。它通过时间调度、多 Agent 协同、状态机流转与自省（Self-Correction），让 AI 奔跑在长达数天甚至数周的业务流中。

二、 横向机制区别：核心本质的四维深度剖析

        为了指导生产环境下的架构设计，必须划清这四者在解决同一核心痛点时的横向机制区别。

1. 应对“幻觉与代码崩溃”：从软性祈祷到硬核防御

这是最能展现四者技术分水岭的维度。当 Agent 遇到复杂的外部报错或知识盲区时：

• Prompt Engineering（软约束）：在系统提示词里写下强指令：“你必须绝对保证生成的代码能够运行，不要猜测，否则将受到惩罚。”（这是一种无能为力的情绪性祈祷，模型依然会Predict失败）。

• Context Engineering（事实对齐）：通过 GraphRAG 或实时语义检索，把当前组件的 API 契约和最新的开发文档动态组装进去。让大模型“照着现成的事实抄”，从源头阻断知识匮乏带来的原发性幻觉。

• Harness Engineering（物理硬阻断）：由 Harness 框架直接提供一个完全隔离的沙箱（如 Docker 容器或 Web-hosted Sandbox）。大模型生成的代码直接在这个安全的物理环境中编译并执行。如果报错，Harness 会利用内置的静态语法检查（Linter）、依赖方向校验器（Dependency Direction Verifier），在底层物理链路上强制熔断，绝对不允许异常向生产环境污染。

• Loop Engineering（自省自纠错）：Anthropic 在 Fable 5 的自纠错指南中指出，Loop 机制不依赖模型的“自我反思”（因为模型往往有认知偏见），而是设计一个评测子智能体（Verifier Sub-agent）或客观的反馈红线（Rubric）。当 Harness 报出 Runtime Error 时，Loop 机制捕获这个信号，自动将其包装成全新的输入，驱动 Agent 走入下一个 Fail ➔ Investigate ➔ Verify ➔ Distill 的迭代循环，直到满足目标（Goal）才跳出。

2. 优化目标与度量衡的区别

• Prompt E.：优化的是信息表达的清晰度。通过 CoT（思维链）、ToT（思维树）和 XML 标签结构化消除语义的二义性。

• Context E.：优化的是上下文的流动效率与经济学成本。通过 Prompt Caching（提示词缓存）、语义重排（Rerank）以及上下文压缩（Compaction），解决 Token 腐烂（Context Rot）问题。

• Harness E.：优化的是架构的确定性与对齐（Alignment）。OpenAI 的 Codex 实践中强调“强制执行代码不变性（Enforcing Invariants）”，通过刚性的架构层（如严格区分 Domain、Layer 并用自定义 linter 拦截），确保 Agent 生成的代码不会导致系统架构漂移（Architectural Drift）。

• Loop E.：优化的是长时序任务的终点成功率（Goal Completion Rate）。例如在复杂的自动驾驶信号调配或百步以上的代码重构中，通过状态持久化（State Checkpointing）确保系统挂掉后能原地拉起继续跑。

3. 工具链与技术栈的彻底分化

• Prompt E.： Playground、系统提示词模板。

• Context E.： 向量数据库、Model Context Protocol (MCP，模型上下文协议)、知识图谱。

• Harness E.： 隔离沙箱、Llama Guard 安全防御库、API 契约验证器、人机协同（Human-in-the-loop）拦截阻断件。

• Loop E.： LangGraph 状态机、Claude Code 内部的 /goal 及 /loop 动态调度器、多智能体团队（Agent Teams）的通信图计算。

网络参考资料：

• https://addyosmani.com/blog/loop-engineering/
• Loop Engineering Explained
• Harness Engineering到底是什么？概念、实战与争议 | 马克的技术工作坊
• The Anatomy of an Agent Harness
• Harness engineering:Leveraging Codex in an agent-first world | OpenAI
• Designing Loops with Claude Fable 5: Self-Correction & Memory Guide | explainx.ai Blog | explainx.ai