AI开发工程范式演进:Prompt->Context->Harness

Posted on In
AI开发工程从最开始的LLM训练，演化到Agent开发，到现在整个智能体架构的演进。

AI开发工程范式演进:Prompt->Context->Harness

一直以来，AI开发工程从最开始的LLM训练，演化到Agent开发，到现在整个智能体架构的演进。

先来解释下这三者的定义和演化时间

阶段 时间 核心问题 局限性
Prompt Engineering 2023-2024 如何写好指令 复杂任务崩溃、无状态、无法处理私有知识
Context Engineering 2025 给 AI 准备什么信息 上下文窗口扩大≠性能线性提升，Agent 仍会失控
Harness Engineering 2026-至今 在什么环境里做事 解决可靠性问题

1. Prompt Engineering

Prompt Engineering 是 LLM 训练的“术业有专攻”阶段，它主要解决如何写好指令的问题。也就是角色扮演和角色定位。这时候的大模型还只是可以扮演某个角色或角色组合，不能处理复杂任务。处理能力取决于大模型的训练数据集和模型本身。直到Langchain出现，CoT思维链和大模型的结合，才让大模型进入到了可以渐进式思考，可调用tools的状态。

2. Context Engineering

Context Engineering 是在 Prompt Engineering 的基础上，给 AI 添加了上下文信息，使得 AI 可以处理复杂任务。这时候的模型已经可以处理复杂任务，但是上下文窗口扩大≠性能线性提升，Agent 还是会失控。上下文窗口只是解决了大模型知道了多少，但是这始终是有上限的，而且对于非Kimi模型的思考偏差之前，注意力和思考会随着上下文的增大而某些之前的关键字被稀释。造成对话开头和对话结尾的一些事物无法进行关联，尽管后面用动态上下文和滑动窗口进行扩展部分解决了这部分问题，但是在大Context情况下，还是会出现无法停止某些任务，即进入任务调用循环的情况，导致消耗掉无限的token。

3. Harness Engineering

Harness Engineering更像是一种开发范式规范，限制agent应该怎么做，做到什么样为止。

1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────┐
│                    Harness Engineering                    │
├─────────────────────────────────────────────────────────┤
│  1. Context Engineering（上下文工程）                      │
│     └── 持续更新的知识库 + 动态上下文（监控数据、浏览器导航）  │
├─────────────────────────────────────────────────────────┤
│  2. Architectural Constraints（架构约束）                  │
│     └── 自定义 Linter + 结构测试（确定性强制执行）           │
├─────────────────────────────────────────────────────────┤
│  3. Garbage Collection（垃圾回收/熵管理）                  │
│     └── 定期运行的清理 Agent，对抗文档不一致和架构漂移         │
└─────────────────────────────────────────────────────────┘

详细技术组件

1. 上下文工程（Context Engineering）

不仅仅是给 AI 喂数据，而是设计信息的”策展系统”：

组件 功能 实现方式
渐进式披露 解决上下文窗口限制 5阶段压缩：名称→描述→全文→附加文件→执行时加载
动态上下文 实时获取必要信息 接入可观测性数据、浏览器导航、MCP 工具
记忆外部化 跨会话保持状态 进度文件（progress files）、策略记忆（playbook）
工具注册表 管理可用工具 MCP 工具延迟发现、专用处理器

实际案例：Claude Code 的 CLAUDE.md 或 OpenCode 的 AGENTS.md 文件，包含项目约定、目录结构、测试命令 。

2. 架构约束（Architectural Constraints）

用确定性规则约束 AI 行为，而非依赖模型自律：

1
2
3
4
5
6
约束类型：
├── 文件系统约束：限制访问目录（如禁止修改 node_modules）
├── 代码规范约束：ESLint、Prettier、类型检查强制执行
├── 变更范围约束：每个 PR 只能修改特定文件/模块
├── 安全约束：危险命令检测、生产数据访问审批
└── 结构测试：验证架构规则（如"不允许跨层调用"）

OpenAI 实践：为 Codex 设置”不能随意修改不相关代码”的硬性边界，违反即报错 。

3. 反馈循环（Feedback Loops）

让 AI 知道自己做得对不对，并自动修正：

1
2
3
4
5
6
7
基础循环（写-测-修）：
AI 生成代码 → 自动运行测试/Linter → 失败则反馈错误信息 → AI 修正 → 重试 → 成功则提交

高级循环（PEV 模式）：
Planner（生成计划）→ Executor（执行）→ Verifier（验证轨迹是否符合预期状态转移）
                    ↑___________________________________________↓
                    （发现差异则注入 refined constraint 回 Planner）

关键数据：同样模型，无 Harness 成功率 42%，加上适当系统环境后跳到 78% 。

4. 熵管理/垃圾回收（Entropy Management）

对抗 AI 产生的技术债务：
定期清理 Agent：扫描文档不一致、架构违规、无用代码
影子模式评估：新配置与生产 Agent 并行测试，仅当超越基线才升级
版本控制：Harness 本身需要版本管理和 A/B 测试 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
┌─────────────────────────────────────────────────────────────┐
│                      Agent Harness 架构                        │
├─────────────────────────────────────────────────────────────┤
│  用户消息 → 消息注入队列                                         │
├─────────────────────────────────────────────────────────────┤
│  Prompt 组合引擎：按优先级组装模块化系统提示                      │
├─────────────────────────────────────────────────────────────┤
│  工具注册表：分发到专用处理器（MCP 工具延迟发现）                  │
├─────────────────────────────────────────────────────────────┤
│  安全系统：                                                     │
│  ├── 审批层（Approval）                                        │
│  ├── 危险命令检测                                               │
│  ├── 钩子（Hooks）                                              │
│  ├── 陈旧读取检测                                               │
│  ├── 计划模式限制                                               │
│  ├── 厄运循环检测（Doom Loop Detection）                         │
│  ├── 迭代上限                                                   │
│  └── 协作取消                                                   │
├─────────────────────────────────────────────────────────────┤
│  上下文工程：5阶段渐进式压缩（内存压力时触发）                     │
├─────────────────────────────────────────────────────────────┤
│  记忆与会话服务：                                                 │
│  ├── 持久策略记忆（Playbook）                                    │
│  ├── 会话存储                                                   │
│  └── 每步撤销（Git 快照）                                        │
├─────────────────────────────────────────────────────────────┤
│  子代理编排：生成隔离实例，过滤工具访问，并行探索                   │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────────────────────────────────────────────┐   │
│  │              ReAct 执行循环（6阶段）                    │   │
│  │  预检查与压缩 → 思考 → 自我批判 → 行动 → 工具执行 → 后处理 │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

Harness 设计哲学：

“当 Agent 挣扎时，我们将其视为信号：识别缺失的内容——工具、防护栏、文档——并通过让 Codex 自己编写修复来反馈到仓库中。”

对于开发者来说，我们应该学会的是：

1
设计环境 → 明确意图 → 构建反馈循环 → 审查输出
  1. 给AI一个项目，包含项目说明，新建中间执行md文件，要求AI在每一步修改都要追加写在中间执行md文件内，并要求说明为什么要这么改，原因是什么？这样才能让其他AI或中断后的AI重新读取执行md文件时能知道，项目进行到哪里了，为什么要这么改。
  2. 描述项目的意图，要做什么？完成什么功能？最后要达到什么样为止？中途遇到什么情况停止？
  3. 构建反馈循环，让AI自己修复代码，并给出修复后的代码。
  4. AI验收测试，确保代码符合要求。
  5. 人工验收，做边缘测试，确保代码没有问题。

这个概念最早应该是在claude和Cursor那个时期就出现的，只不过现在更倾向于做一个通用框架和逻辑开发范式的形式表达出来，这种在开发复杂项目和大型项目，多Agent开发中很适合。