Agent Engineering —— Prompt & Context & Harness & Loop

引言：为什么你的Agent在Demo里惊艳，在生产中拉胯？

2026年，几乎每家企业都在谈AI Agent。团队花了三周搭了一个Agent原型，接入了内部知识库，CEO看了Demo点头说“不错”——然后呢？上线两周后，Agent把客户的订单信息张冠李戴，把合同条款搞混，在凌晨三点自动发了一封莫名其妙的邮件。

这个故事正在无数企业里反复上演。问题不在模型不够聪明——问题在于：你在用Demo阶段的工程方法论，去解决生产阶段的系统问题。

过去四年，AI工程领域经历了一场静悄悄的范式迁移。从2022年的Prompt Engineering，到2025年的Context Engineering，到2026年的Harness Engineering。Andrej Karpathy在2025年说“prompt engineering应该让位给context engineering”；Mitchell Hashimoto（HashiCorp联合创始人）在2026年2月提出“engineer the harness”；Boris Cherny（Anthropic Claude Code负责人）在2026年6月说“我不再prompt Claude了，我设计Loop来prompt Claude”。

这不是大佬们在造词。他们各自独立地撞上了同一堵墙：单靠改善prompt无法让Agent在生产环境中可靠运行；单靠优化context无法防止Agent犯同样的错。

本文将系统拆解Agent工程的四个递进层级，给出每一层的数学原理与代码实现。

一、Prompt Engineering——“怎么问”

1.1 定义与核心问题

Prompt Engineering是最基础的工程层，关注的是如何用自然语言精确地表达任务，从而引导模型输出符合预期的结果。

在大模型刚兴起时，最直观的现象是：同一个模型，仅仅改变提问方式，输出结果就可能发生巨大变化。因此，当时的核心共识是：模型不是不会，而是你没有把问题表达清楚。

Prompt Engineering的核心手段包括：角色设定、思维链（CoT）引导、少样本示例、输出格式约束等。

1.2 数学本质：塑造概率分布

从数学上看，Prompt Engineering的本质是通过输入文本调整模型的条件概率分布。设词表为 $\mathcal{V}$ ，给定提示词 $p$ ，LLM生成输出 $y$ 的概率为：

$P(y \mid p) = \prod_{t=1}^{|y|} P(y_t \mid y_{<t}, p)$

Prompt Engineering的目标是找到一个最优的提示词 $p^*$ ，使得目标输出 $y^*$ 的概率最大化：

$p^* = \arg\max_{p \in \mathcal{P}} P(y^* \mid p)$

其中 $\mathcal{P}$ 是所有可能的提示词空间。

更精确地说，提示词通过塑造模型的局部概率分布来影响输出。一个精心设计的prompt将目标输出从“低概率事件”变为“高概率事件”。temperature参数控制着这个概率分布的平滑程度：

$p_i' = \text{softmax}\left(\frac{\log(p_i)}{\text{temperature}}\right)$

1.3 局限：天花板是硬性的

Prompt Engineering的局限性同样明显：

无状态：每次调用独立，没有记忆
无法注入外部知识：无法告知模型代码库里的最新变更
无法处理跨步骤协作：一旦任务需要调用工具或追踪状态，单靠Prompt撑不住整个系统

Prompt Engineering问的是“怎么表达任务”。

1.4 代码示例：从朴素到工程化

1
# ❌ 朴素Prompt：信息太少
2
prompt_naive = "Fix the bug in my code"
3

4
# ✅ 工程化Prompt：结构化、分步骤、带约束
5
prompt_engineered = """
6
你是一位资深Python工程师，正在审查一个生产环境Bug。
7

8
背景信息：
9
- Bug导致orders.py第47行抛出KeyError
10
- 仅在周末批处理时触发
11
- 系统使用PostgreSQL + 读副本
12

13
请按以下步骤执行：
14
1. 首先定位根本原因，不修改任何代码
15
2. 描述什么数据条件触发了该错误
16
3. 提出一个保持向后兼容的修复方案
17
4. 列出需要新增的测试用例
18

19
在确认诊断之前，不要修改任何文件。
20
"""

正如HumanLayer工程团队的观察：“这不是模型问题，是配置问题。” 更聪明的模型只是被分配更难的任务，同样的失败模式照样会出现。

二、Context Engineering——“给模型看什么”

2.1 定义与核心问题

当Prompt Engineering碰到天花板后，行业意识到：问题不在于“怎么说”，而在于“给模型看什么”。

Context Engineering（上下文工程）关注的是模型在执行任务时处于什么信息环境中。它不再只关注单次prompt，而是关注模型每次推理时看到的全部信息：系统提示、对话历史、检索到的文档（RAG）、工具调用结果、项目文件内容等。

Context Engineering的本质是治理信息环境——从“写一条好prompt”升级到“设计模型每次决策时的完整信息环境”。

2.2 数学建模：上下文装配方程

Context Engineering可以用一个上下文装配方程来形式化：

$C = A(c_1, c_2, c_3, c_4, c_5, c_6)$

其中 $C$ 是装配完成的上下文（最终输入给LLM的内容）， $A$ 是装配函数， $c_i$ 是各个上下文组件：

$c_1$ ：系统指令（System Prompt）
$c_2$ ：用户输入与对话历史
$c_3$ ：检索结果（RAG）
$c_4$ ：工具调用返回结果
$c_5$ ：当前任务状态与中间结果
$c_6$ ：系统规则与安全约束

Context Engineering的优化目标可以形式化为：

$F^* = \arg\max_{F} \mathbb{E}_{\tau \sim T} \left[ \text{Reward}\left(P_\theta(Y \mid C_F(\tau)), Y_\tau^*\right) \right]$

其中 $F$ 是一组上下文生成函数（如检索、选择、格式化、装配等）， $C_F(\tau)$ 是任务 $\tau$ 的上下文， $Y_\tau^*$ 是期望输出。

2.3 核心能力

Context Engineering需要解决三个核心问题：

① 检索（Retrieval） ：从知识库中动态注入相关文档。这是RAG的核心。选对文档而不是全量灌入，是Context Engineering的第一原则。

② 压缩（Compression） ：在长对话或长文档中保留关键信息、丢弃噪音。“正确的300个token胜过10万个嘈杂的token”。

③ 时序管理（Temporal Management） ：决定历史信息何时保留、何时摘要、何时丢弃。典型实践是“渐进式披露”——不是一次性提供全部信息，而是在需要时逐步注入。

2.4 Prompt vs Context：包含关系

需要特别强调的是：Prompt只是Context的一个子集。Context Engineering包含Prompt Engineering，并在其上增加了信息环境的治理维度。

Context Engineering问的是“模型工作时应该处于什么信息环境里”。

2.5 代码示例：上下文装配器

1
from typing import List, Dict, Any
2
from dataclasses import dataclass
3

4
@dataclass
5
class ContextComponent:
6
    """上下文组件"""
7
    name: str
8
    content: str
9
    priority: int  # 优先级，决定装配顺序
10
    max_tokens: int  # 该组件允许的最大token数
11

12
class ContextAssembler:
13
    """
14
    上下文装配器：将多个组件装配为最终上下文
15

16
    数学上，这实现了装配函数 C = A(c₁, c₂, ..., cₙ)
17
    """
18

19
    def __init__(self, max_total_tokens: int = 128000):
20
        self.max_total_tokens = max_total_tokens
21
        self.components: List[ContextComponent] = []
22

23
    def add_component(self, component: ContextComponent):
24
        """添加上下文组件"""
25
        self.components.append(component)
26

27
    def assemble(self, query: str) -> str:
28
        """
29
        装配最终上下文
30

31
        策略：按优先级排序，在token预算内渐进式注入
32
        """
33
        # 1. 按优先级排序
34
        sorted_components = sorted(self.components, key=lambda c: c.priority, reverse=True)
35

36
        # 2. 渐进式装配
37
        assembled = []
38
        current_tokens = 0
39

40
        # 先注入系统指令（最高优先级）
41
        for comp in sorted_components:
42
            # 估算token数（简化版）
43
            estimated_tokens = len(comp.content) // 4
44

45
            if current_tokens + estimated_tokens <= self.max_total_tokens:
46
                assembled.append(f"--- {comp.name} ---\n{comp.content}")
47
                current_tokens += estimated_tokens
48
            else:
49
                # token预算不足，尝试压缩
50
                compressed = self._compress(comp.content, self.max_total_tokens - current_tokens)
51
                if compressed:
52
                    assembled.append(f"--- {comp.name} (压缩) ---\n{comp}")
53
                    break
54

55
        # 3. 添加当前查询
56
        assembled.append(f"--- 用户查询 ---\n{query}")
57

58
        return "\n\n".join(assembled)
59

60
    def _compress(self, content: str, budget: int) -> str:
61
        """压缩内容以适应token预算"""
62
        # 实际实现可使用LLM生成摘要
63
        # 或用滑动窗口截取
64
        if len(content) // 4 <= budget:
65
            return content
66
        # 简化：取前budget个token
67
        return content[:budget * 4]

三、Harness Engineering——“在哪里安全运行”

3.1 定义与核心问题

即便模型理解正确、信息充分，也未必能够稳定完成任务。常见问题包括：执行过程中逐渐偏离目标、错误使用工具、长链路任务中状态混乱、无法发现自身错误。

这类问题本质上已经超出了输入侧优化的范畴。Prompt和Context解决的是“输入问题”，而这里需要解决的是 “执行过程问题” 。

Harness Engineering（驾驭工程）应运而生。Harness的原意是“马具”——套在马身上的缰绳、嚼子和鞍具。马提供动力，但马具控制方向、速度和安全。在AI语境中：模型是马，Harness是缰绳。模型提供智能，Harness提供控制。

行业的核心公式是：

$\text{Agent} = \text{Model} + \text{Harness}$

Harness是AI Agent中除模型本身之外的所有代码、配置和执行逻辑。原始模型不是Agent——只有当Harness赋予它状态、工具执行、反馈循环和可强制执行的约束时，它才成为Agent。

3.2 Harness的七层架构

卡内基梅隆大学等研究团队提出了Harness工程的ETCLOVG七层分类：

层级	名称	职责
E	执行环境与沙箱	Agent代码在哪里运行、受到什么约束
T	工具接口与协议	外部能力如何被描述、发现和调用
C	上下文管理	模型在短期、会话级和持久化层面能看到什么
L	生命周期与编排	组织状态读写控制流，覆盖单Agent循环到多Agent协作
O	可观测性	捕获轨迹、成本、失败和可靠性信号
V	验证	将任务和轨迹转化为评估、失败归因和回归反馈
G	治理	权限、身份、策略、安全加固、审计和人工监督

前四层构成Harness的结构核心，后三层对应围绕核心的控制平面。

3.3 Harness的量化效果

Harness Engineering的价值可以通过数据量化：

仅仅是给同一个大语言模型换上一套更精巧的Harness架构，它在Terminal Bench 2.0（衡量AI编程能力的权威榜单）上的通过率，直接从52.8%拉升到了66.5%。底层模型的权重一个字节都没改。
在不改模型权重的情况下，仅调整harness层本身，就可能显著改变Agent在coding和terminal benchmark上的表现。
研究显示，围绕固定语言模型的wrapper——每一步存储、检索和呈现什么——可以改变端到端性能高达可观的程度。

3.4 Harness的核心构件

一个完整的Harness包含以下核心构件：

1
from typing import List, Dict, Any, Optional
2
from dataclasses import dataclass, field
3
import logging
4
import time
5

6
@dataclass
7
class ToolSpec:
8
    """工具规范"""
9
    name: str
10
    description: str
11
    parameters: Dict[str, Any]
12
    permissions: List[str]  # 所需权限
13
    is_dangerous: bool = False
14

15
@dataclass
16
class ExecutionContext:
17
    """执行上下文"""
18
    task_id: str
19
    user_id: str
20
    session_id: str
21
    permissions: List[str]
22
    start_time: float = field(default_factory=time.time)
23
    state: Dict[str, Any] = field(default_factory=dict)
24

25
class Harness:
26
    """
27
    Agent Harness：模型的"缰绳、马鞍与路"
28

29
    Harness = 执行环境 + 工具接口 + 上下文管理 + 编排 + 可观测性 + 验证 + 治理
30
    """
31

32
    def __init__(self, model, tools: List[ToolSpec], max_steps: int = 20):
33
        self.model = model
34
        self.tools = {t.name: t for t in tools}
35
        self.max_steps = max_steps
36
        self.logger = logging.getLogger("harness")
37
        self.audit_trail: List[Dict] = []  # 审计日志
38

39
    def run(self, task: str, context: ExecutionContext) -> str:
40
        """
41
        在Harness约束下执行任务
42

43
        Harness的四个核心控制机制：
44
        1. 权限校验（治理层）
45
        2. 工具调用边界（工具接口层）
46
        3. 可观测性（观测层）
47
        4. 审计就绪（治理层）
48
        """
49
        self.logger.info(f"开始执行任务: {task}, 用户: {context.user_id}")
50

51
        # 1. 权限校验（Governance）
52
        if not self._check_permissions(context, task):
53
            self._audit("permission_denied", context, {"task": task})
54
            raise PermissionError(f"用户 {context.user_id} 无权执行此任务")
55

56
        state = {"task": task, "step": 0, "history": []}
57

58
        while state["step"] < self.max_steps:
59
            # 2. 构建上下文（Context Management）
60
            prompt = self._build_prompt(state, context)
61

62
            # 3. 模型推理
63
            response = self.model.generate(prompt)
64

65
            # 4. 解析行动
66
            action = self._parse_action(response)
67

68
            # 5. 工具调用边界检查（Tool Interface）
69
            if action["type"] == "tool_call":
70
                tool_name = action["tool"]
71
                if tool_name not in self.tools:
72
                    self._audit("unknown_tool", context, {"tool": tool_name})
73
                    return f"错误：未知工具 {tool_name}"
74

75
                tool = self.tools[tool_name]
76

77
                # 6. 工具级权限校验
78
                if not self._check_tool_permissions(context, tool):
79
                    self._audit("tool_permission_denied", context, {"tool": tool_name})
80
                    return f"错误：无权调用工具 {tool_name}"
81

82
                # 7. 执行工具（在沙箱中）
83
                try:
84
                    result = self._execute_in_sandbox(tool, action["args"])
85
                    observation = f"Observation: {result}"
86
                except Exception as e:
87
                    observation = f"Observation: 错误 - {str(e)}"
88
                    self.logger.error(f"工具执行失败: {e}")
89

90
                # 8. 审计记录（Observability + Governance）
91
                self._audit("tool_call", context, {
92
                    "tool": tool_name,
93
                    "args": action["args"],
94
                    "result": result if "result" in locals() else None,
95
                    "error": str(e) if "e" in locals() else None
96
                })
97

98
                state["history"].append({"action": action, "observation": observation})
99

100
            elif action["type"] == "finish":
101
                # 9. 验证输出（Verification）
102
                if self._verify_output(action["answer"]):
103
                    self._audit("task_completed", context, {"answer": action["answer"]})
104
                    return action["answer"]
105
                else:
106
                    self._audit("verification_failed", context, {"answer": action["answer"]})
107
                    # 继续循环，让模型修正
108

109
            state["step"] += 1
110

111
        self._audit("max_steps_reached", context, {"steps": state["step"]})
112
        return "达到最大步数，任务未完成"
113

114
    def _check_permissions(self, context: ExecutionContext, task: str) -> bool:
115
        """治理层：权限校验"""
116
        # 实现权限检查逻辑
117
        return True
118

119
    def _check_tool_permissions(self, context: ExecutionContext, tool: ToolSpec) -> bool:
120
        """治理层：工具权限校验"""
121
        return all(p in context.permissions for p in tool.permissions)
122

123
    def _execute_in_sandbox(self, tool: ToolSpec, args: Dict) -> Any:
124
        """执行环境与沙箱：工具在受控环境中执行"""
125
        # 实际实现中，这里会使用容器化或隔离执行环境
126
        pass
127

128
    def _verify_output(self, output: str) -> bool:
129
        """验证层：输出验证"""
130
        # 实现输出验证逻辑
131
        return True
132

133
    def _audit(self, event_type: str, context: ExecutionContext, data: Dict):
134
        """治理+观测层：审计日志"""
135
        self.audit_trail.append({
136
            "timestamp": time.time(),
137
            "event_type": event_type,
138
            "user_id": context.user_id,
139
            "task_id": context.task_id,
140
            "data": data
141
        })
142
        self.logger.info(f"审计: {event_type} - {data}")

3.5 Harness vs Context vs Prompt：三层包含关系

三者不是竞争关系，而是逐层扩展的包含关系：

Context Engineering包含Prompt Engineering；Harness Engineering包含Context Engineering。

用一句话概括：

Prompt Engineering解决表达问题
Context Engineering解决信息问题
Harness Engineering解决执行问题

外层不取消内层，而是在内层的基础上增加新的工程维度。如果你的prompt写得模糊、context配置混乱，再好的harness也救不了你——因为模型每次推理时收到的指令和信息本身就是低质量的。

四、Loop Engineering——第四维度的延伸

4.1 从三层到四层

2026年中，行业开始讨论Loop Engineering（循环工程）作为第四层。其核心思想是：设计一个让Agent自主循环的系统，而不是手动逐轮prompt模型。

“你不应该继续给编码Agent写提示词了，你应该设计循环，让循环去提示你的Agent。”

Loop Engineering的五个组成部分是：自动化、工作树、skill、插件和连接器、子Agent，外加一个跨会话的记忆层。

4.2 四层的嵌套关系

四层工程是嵌套关系，不是替代关系：

1
Loop Engineering（循环工程）
2
    └── Harness Engineering（执行工程）
3
            └── Context Engineering（信息工程）
4
                    └── Prompt Engineering（表达工程）

Loop Engineering包含以上所有层。

4.3 各层级落地侧重点

层级	核心问题	落地侧重点	典型技术
Prompt	怎么问	指令表达、输出格式、角色设定	思维链、少样本、结构化输出
Context	给模型看什么	RAG检索、记忆召回、上下文压缩	向量数据库、语义分块、渐进式披露
Harness	在哪里安全运行	工具接入边界、权限校验、审计就绪	沙箱、权限系统、可观测性、治理
Loop	怎么让Agent自己跑	自动化心跳、工作树隔离、子Agent制衡	循环编排、状态持久化、自主决策

五、总结：从控制模型到控制智能体

AI工程的演进从来不是替代，而是层层叠加的抽象升级。

Prompt Engineering（2022-2024）：把模型当作一个文本框，优化输入
Context Engineering（2025）：把模型当作一个信息处理器，优化信息环境
Harness Engineering（2026）：把模型当作一个执行者，构建控制框架
Loop Engineering（2026-）：把模型当作一个自主工作者，设计让它自己跑的循环

每一次演进，都是工程关注点的实质性跃迁。正如研究团队所总结的：“Harness——提示词、工具选择、内存管理、编排逻辑、安全检查——让智能变得可操作”。而Loop Engineering则更进一步：把人从“循环里的操作员”挪到“循环外的设计者”。

模型是马，Harness是缰绳，Loop是让它自己跑起来的自动驾驶系统。三者的组合，才是Agent从Demo走向生产的完整路径。

Clear Eyes, Full Heart