Prompt → Context → Harness → Loop → Graph：AI 应用的工程重心，正在从“怎么问模型”逐渐转向“怎么构建让模型稳定工作的系统”。
Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering
一、开篇
今天我想分享一个今年在 AI Agent 领域比较有意思的话题。
这几个词大家可能都听过：
- Prompt Engineering
- Context Engineering
- Harness Engineering
- Loop Engineering
- Graph Engineering
如果单独看，每一个词似乎都不难理解。
Prompt Engineering：提示词工程。
Context Engineering：上下文工程。
Harness Engineering：Harness 工程。
Loop Engineering：循环工程。
Graph Engineering：图工程。
但是把这五个词放在一起，就会发现它们其实描述的是一个非常有意思的变化：
AI 应用开发的工程重心，正在不断向更高层次移动。
最开始，我们研究的是：
怎么把 Prompt 写好？
后来发现：
Prompt 写得再好，如果模型没有足够的信息，也没有用。
于是开始研究：
模型这一轮到底应该看到什么？
再后来，模型已经不只是回答问题，而是开始调用工具、修改文件、执行代码、访问数据库。
这时候问题又变成：
怎么给模型提供一个可靠的运行环境？
再往后，如果 Agent 要自己运行几十轮、几百轮：
什么时候运行？什么时候继续？什么时候重试？什么时候停止？
最后，当一个 Agent 已经不够，我们需要多个 Agent、工具、验证器、人工节点协同：
这些节点应该怎么连接？
于是就形成了今天这五个关键词：
Prompt
↓
Context
↓
Harness
↓
Loop
↓
Graph
今天我们就按照这个顺序来理解。
二、Prompt Engineering：我应该怎么告诉模型？
先从最熟悉的 Prompt Engineering 开始。
Prompt Engineering，本质上是在研究：
如何设计给模型的指令，让模型产生更加符合预期的输出。
比如我们直接告诉模型：
帮我写一个登录接口。
模型当然可以写。
但是如果我们把要求写得更加明确：
你是一名 Java 后端工程师。
请使用 Spring Boot 3 + MyBatis Plus 实现用户登录接口。
要求：
1. 使用 RESTful API
2. 密码使用 BCrypt 加密
3. 登录成功返回 JWT
4. 参数使用 Bean Validation 校验
5. 统一使用 Result<T> 返回
6. 给出 Controller、Service、Mapper 和 DTO
通常得到的结果会更加稳定。
这就是 Prompt Engineering。
它关注的是：
Instruction
Role
Constraint
Example
Output Format
也就是：
我要怎么说，模型才能更好地理解我的意图？
Prompt Engineering 的局限
但是问题很快就出现了。
假设我告诉 AI：
帮我修复这个项目中的登录 Bug。
Prompt 写得再漂亮，如果 AI 根本不知道：
- 项目的目录结构
- 数据库表结构
- 登录流程
- Redis 配置
- JWT 生成方式
- 项目的编码规范
- 之前已经尝试过什么
- 测试怎么运行
它还是很难真正解决问题。
所以我们发现：
模型的问题，有时候不是“不知道怎么做”，而是“根本不知道相关信息”。
这时候，工程重心就开始从 Prompt 转向 Context。
三、Context Engineering：这一轮到底应该让模型看到什么？
Anthropic 对 Context Engineering 的一个核心描述是：
Prompt Engineering 关注如何编写指令，而 Context Engineering 更关注如何在模型推理时，动态组织和维护它所需要的信息。([Anthropic][1])
简单来说：
Prompt 是“我告诉你什么”，Context 是“你现在知道什么”。
例如我们开发一个 AI 客服。
用户说：
我上次买的那双鞋什么时候发货？
如果只看 Prompt：
你是一个电商客服，请帮助用户解决问题。
模型根本不知道：
用户是谁？
买了什么？
订单号是什么？
物流状态是什么？
所以系统需要动态构建 Context：
System Prompt
+
用户信息
+
历史对话
+
订单信息
+
物流信息
+
商品信息
+
相关知识库
↓
最终 Context
↓
LLM
这就是 Context Engineering。
Context Engineering 到底在工程什么？
可以把它拆成几个问题。
1. Retrieve：拿什么？
从数据库、RAG、API、搜索引擎中找到相关信息。
2. Select：选什么？
不是所有信息都应该塞进去。
3. Compress：压缩什么？
历史对话越来越长，需要摘要、压缩。
4. Structure：怎么组织？
同样的信息，不同的结构可能产生不同的效果。
例如：
用户：
张三
订单：
订单号：10086
商品：Nike Air Max
状态：运输中
比把所有信息直接拼成一大段文本更加容易被模型正确使用。
5. Isolate：隔离什么？
不同 Agent、不同任务，不应该看到全部上下文。
所以 Context Engineering 本质上是在解决：
有限 Context Window 下，如何让模型在当前时刻获得最有价值的信息。
四、Harness Engineering：不仅给模型信息，还要给它一个“工作环境”
当 AI 从 Chatbot 变成 Agent，问题又发生变化。
以前：
User
↓
Prompt
↓
LLM
↓
Answer
现在：
User
↓
Agent
↓
LLM
↓
Tool
↓
Environment
↓
Observation
↓
LLM
↓
Tool
↓
...
比如 Coding Agent。
它可能需要：
读取文件
修改代码
执行 Shell
运行测试
查看 Git Diff
搜索代码
访问数据库
这时候单纯 Prompt 和 Context 已经不够。
我们需要一个：
Harness
可以把 Harness 理解成：
围绕模型构建的一整套运行环境和控制机制。
它决定：
模型能看到什么
模型能调用什么
模型能修改什么
模型不能做什么
怎么验证结果
失败之后怎么办
什么时候认为任务完成
Anthropic 对 Agent 的 Context 管理强调了工具、MCP、历史、外部数据等动态状态；而 Harness Engineering 则进一步进入运行环境、权限、工具、验证和反馈等系统层面。([Anthropic][1])
一个 Coding Agent 的 Harness
例如：
┌───────────────┐
│ LLM │
└───────┬───────┘
│
┌───────────────┼───────────────┐
↓ ↓ ↓
文件系统 Terminal Git
↓ ↓ ↓
Read/Write Execute Diff
│ │ │
└───────────────┼───────────────┘
↓
Tests
↓
Verification
这里：
- File System 是工具
- Terminal 是工具
- Git 是工具
- Test 是验证机制
- Permission 是约束
- Sandbox 是运行环境
- Context Manager 是上下文管理
这些东西共同构成了 Agent 的 Harness。
所以可以记住一句话：
Model 提供智能，Harness 提供可执行、可控制、可验证的工作环境。
五、Loop Engineering：如果 Agent 不只运行一次呢？
现在我们已经有：
Prompt
+
Context
+
Harness
Agent 可以开始干活了。
但真实任务往往不是：
执行一次 → 完成
而是：
执行
↓
观察结果
↓
发现错误
↓
修改
↓
再次执行
↓
测试
↓
继续修改
↓
再次测试
↓
完成
这就是 Loop。
Loop Engineering 关注的是：
如何设计 Agent 的持续运行循环。
IBM 在 2026 年对 Loop Engineering 的定义，就是设计能够反复引导 Agent 朝目标前进、减少人工干预的 Agentic Workflow。([IBM][2])
一个最简单的 Agent Loop
┌──────────────┐
│ Goal │
└──────┬───────┘
↓
┌──────────────┐
│ Think │
└──────┬───────┘
↓
┌──────────────┐
│ Act │
└──────┬───────┘
↓
┌──────────────┐
│ Observe │
└──────┬───────┘
↓
┌──────────────┐
│ Verify │
└──────┬───────┘
↓
Done?
/ \
No Yes
↓ ↓
Retry Stop
│
└──────────→
这里最重要的其实不是“循环”。
而是三个东西：
1. Goal
到底什么叫完成？
比如：
让所有测试通过
比：
把代码优化得更好
更加适合作为 Agent Goal。
2. Verification
不能让 Agent 自己说：
我觉得已经完成了。
而应该：
mvn test
npm test
pytest
typecheck
lint
用确定性的工具验证。
3. Stop Condition
必须告诉 Agent：
什么时候停止？
例如：
测试全部通过
或者：
连续 3 次失败
或者：
达到 Token / Cost Budget
或者：
需要人工审批
Loop Engineering 的核心，就是把：
“我再给 AI 发一句 Prompt”
变成：
“我设计一个可以自己运行、验证、重试、停止的系统。”
这也是 2026 年 Loop Engineering 这个术语快速出现的核心背景。([Loop Engineering][3])
六、Graph Engineering：一个 Loop 不够了怎么办？
到这里，我们有一个 Agent Loop。
但是复杂任务可能是：
需求分析
↓
代码实现
↓
测试
↓
Code Review
↓
安全检查
↓
部署
而且其中还可能出现：
测试失败
↓
返回开发 Agent
安全检查失败
↓
返回安全 Agent
高风险操作
↓
人工审批
这已经不是简单的 Loop。
它更像一个：
Graph。
Graph Engineering 就是在关注：
如何把多个 Agent、工具、任务、验证器、人工节点组织成一个可观察、可控制、可恢复的任务图。
不过这里必须强调：
Graph Engineering 目前仍然是一个正在形成中的架构标签，并不是像 HTTP、TCP 这样的标准化技术名词。 不同资料对它的边界也存在差异。([GitHub][4])
所以分享的时候不要把它说成“行业已经统一定义的标准”。
一个 Agent Graph
例如一个 AI 软件开发系统：
┌──────────────┐
│ Requirement │
└──────┬───────┘
↓
┌──────────────┐
│ Planner │
└──────┬───────┘
↓
┌──────────────┐
│ Developer │
└──────┬───────┘
↓
┌──────────────┐
│ Test │
└──────┬───────┘
Pass│Fail
┌────┴────┐
↓ ↓
Review Developer
↓
Security
↓
Human Approval
↓
Deploy
这时候每一个节点都可能拥有自己的：
Prompt
Context
Tools
Harness
Loop
而 Graph 负责：
节点之间怎么连接
什么时候进入下一个节点
什么时候回退
什么时候分支
什么时候并行
什么时候需要人工介入
所以可以把它理解成：
Loop 解决“一个 Agent 怎么持续工作”，Graph 解决“多个工作节点怎么协同”。
七、五个概念到底是什么关系？
现在把五个概念放在一起。
| Engineering | 核心问题 | 关注对象 |
|---|---|---|
| Prompt Engineering | 我应该怎么告诉模型？ | 指令 |
| Context Engineering | 模型这一刻应该知道什么？ | 信息 |
| Harness Engineering | 模型应该在什么环境里工作？ | 工具、权限、验证、运行环境 |
| Loop Engineering | 模型应该如何持续工作？ | 循环、状态、重试、停止 |
| Graph Engineering | 多个 Agent / 工具如何协同？ | 工作流、节点、边、分支 |
可以用一句话记忆：
Prompt
= 怎么说
Context
= 给什么信息
Harness
= 给什么工作环境
Loop
= 怎么持续干
Graph
= 多个角色怎么协同
八、为什么会出现这种演进？
我认为核心原因只有一个：
模型能力越来越强之后，瓶颈开始从“模型本身”转移到“模型周围的工程系统”。
以前模型能力不够。
所以大家最关心：
换哪个模型？
模型参数多少？
Prompt 怎么写？
但是当模型已经能够：
写代码
调用工具
搜索信息
修改文件
运行测试
自主规划
问题就变成：
它看到了什么？
它能做什么？
它做错了怎么办？
它怎么知道自己做错了？
它什么时候应该停止？
多个 Agent 怎么协同？
所以工程关注点开始向外扩展。
九、用一个“AI 程序员”把五个概念串起来
假设我要做一个 AI Coding Agent。
用户输入：
帮我给项目增加一个 Redis 缓存。
第一步：Prompt Engineering
告诉模型：
你是一名 Java 后端工程师。
请为项目增加 Redis Cache。
遵循现有项目代码规范。
解决：
怎么说？
第二步：Context Engineering
系统自动给模型：
项目目录
Spring Boot 版本
pom.xml
相关 Service
现有 Redis 配置
数据库结构
代码规范
历史修改记录
解决：
模型需要知道什么？
第三步：Harness Engineering
给模型：
Read File
Write File
Search
Terminal
Git
Maven
Test
同时限制：
不能访问生产数据库
不能直接 push main
不能删除项目
解决：
模型在哪里工作？能做什么？不能做什么？
第四步：Loop Engineering
Agent 开始：
分析
↓
修改代码
↓
mvn test
↓
失败
↓
读取错误
↓
修改
↓
mvn test
↓
通过
↓
停止
解决：
模型怎么持续完成任务？
第五步：Graph Engineering
进一步拆成：
Planner
↓
Developer
↓
Tester
↓
Reviewer
↓
Security
↓
Human
↓
Deploy
解决：
复杂任务如何组织多个 Agent 和工具？
十、最后总结
所以今天的五个关键词，我认为可以浓缩成一个非常简单的模型：
AI Engineering
│
┌──────────────┴──────────────┐
↓ ↓
单次交互 Agent System
│ │
Prompt Context
│
Harness
│
Loop
│
Graph
或者更简单：
Prompt → Context → Harness → Loop → Graph
怎么说 知道什么 怎么工作 怎么持续 怎么协同
这五个词真正有价值的地方，并不是让我们多记五个 AI 黑话。
而是它们帮助我们理解一个变化：
AI 应用开发正在从“Prompt 开发”，逐渐走向“Agent 系统工程”。
当我们还在研究：
“这个 Prompt 怎么改得更好？”
的时候，也许下一步真正应该问的是：
“模型现在缺什么 Context？”
“它有哪些 Tool？”
“它的 Harness 怎么设计？”
“它怎么验证？”
“什么时候停止？”
“多个 Agent 怎么协同？”
这可能才是未来 AI 应用工程真正有技术含量的地方。
谢谢大家。
2. 博客.md
从 Prompt Engineering 到 Graph Engineering：AI Agent 工程范式的五次跃迁
Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering
最近 AI Agent 领域出现了一组越来越频繁的工程术语：
- Prompt Engineering
- Context Engineering
- Harness Engineering
- Loop Engineering
- Graph Engineering
乍一看，它们像是一堆新的 AI 黑话。
但如果把它们放在一起观察，会发现这五个概念其实描述了一条非常清晰的演进路径：
AI 应用开发的工程重心，正在从“如何告诉模型”逐渐转向“如何构建一个让模型稳定完成任务的系统”。
需要提前说明的是：Prompt Engineering、Context Engineering、Harness Engineering 已经形成了较清晰的工程语义；Loop Engineering 和 Graph Engineering 则是 2026 年快速兴起的术语，目前不同实践者对边界仍有不同理解。因此，本文把后两者作为一种理解 Agent 系统架构的工程视角，而不是严格的行业标准。([Anthropic][1])
一、五个概念先看懂
如果只想记住最核心的东西，可以直接记下面这张表。
| 概念 | 核心问题 | 关注对象 |
|---|---|---|
| Prompt Engineering | 我应该怎么告诉模型？ | Instruction |
| Context Engineering | 模型这一刻应该知道什么？ | Context |
| Harness Engineering | 模型应该在什么环境里工作？ | Runtime / Tools / Guardrails |
| Loop Engineering | 模型应该如何持续完成任务？ | Loop / State / Verification |
| Graph Engineering | 多个 Agent 如何协同？ | Graph / Workflow |
一句话概括：
Prompt
= 怎么说
Context
= 给什么信息
Harness
= 给什么工作环境
Loop
= 怎么持续干
Graph
= 怎么组织多个角色协同
接下来逐层展开。
二、Prompt Engineering：怎么告诉模型？
2.1 什么是 Prompt Engineering？
Prompt Engineering，也就是提示词工程。
它研究的是：
如何设计给 LLM 的指令，使模型更稳定地产生预期结果。
例如：
帮我写一个 Spring Boot 登录接口。
这属于非常简单的 Prompt。
进一步增加约束：
你是一名 Java 后端工程师。
使用 Spring Boot 3 + MyBatis Plus 实现用户登录。
要求：
1. 使用 RESTful API
2. 使用 Bean Validation 校验参数
3. 密码使用 BCrypt
4. 登录成功返回 JWT
5. 使用统一 Result<T> 返回
6. 给出 Controller、Service、Mapper、DTO
模型得到的任务边界明显更加清晰。
Prompt Engineering 主要关注：
Role
Instruction
Constraint
Example
Output Format
也就是：
如何把人的意图转换成模型更容易执行的指令。
三、Prompt Engineering 为什么不够？
假设现在任务变成：
帮我修复这个项目的登录 Bug。
即使 Prompt 写得非常漂亮，模型还是可能不知道：
项目使用什么框架？
登录代码在哪里？
数据库表是什么？
Redis 怎么配置？
JWT 怎么生成？
之前修改过什么？
项目应该如何测试？
这就出现了一个非常关键的问题：
模型不是不知道怎么做，而是不知道足够的信息。
因此工程问题从：
怎么写 Prompt？
逐渐转变为：
这一轮到底应该把什么信息给模型？
这就是 Context Engineering。
四、Context Engineering：模型应该知道什么？
Anthropic 将 Context Engineering 描述为：不仅设计 Prompt，而是管理模型推理时所获得的完整上下文，包括系统指令、工具、MCP、外部数据、消息历史等。([Anthropic][1])
因此可以简单理解：
Prompt 是你对模型说的话，Context 是模型在当前时刻所拥有的工作信息。
4.1 一个 AI 客服的例子
用户：
我上次买的鞋什么时候发货？
System Prompt：
你是一名电商客服。
显然不够。
系统可能需要动态获取：
用户信息
+
订单信息
+
商品信息
+
物流信息
+
历史对话
+
售后政策
最终：
┌──────────────┐
│ System Prompt│
└──────┬───────┘
│
用户 ───────→ Context Builder
│
┌────────────┼────────────┐
↓ ↓ ↓
Order DB RAG History
│ │ │
└────────────┼────────────┘
↓
Final Context
↓
LLM
这就是 Context Engineering。
4.2 Context Engineering 的几个核心动作
Retrieve
从数据库、RAG、API、搜索引擎中找到相关信息。
Select
不是检索出来的所有内容都需要给模型。
Compress
历史越来越长，需要摘要、压缩。
Structure
把信息组织成模型容易理解的结构。
Isolate
不同任务、不同 Agent 不一定需要看到全部信息。
因此 Context Engineering 真正解决的是：
有限 Context Window 下，如何让模型在当前时刻获得最有价值的信息。
Google Cloud 也将 Context Engineering 描述为从简单 Prompt 转向构建结构化数据和信息环境的过程。([Google Cloud][5])
五、Harness Engineering：模型开始“干活”了
如果说：
Prompt = 告诉模型做什么
Context = 告诉模型它需要知道什么
那么 Harness Engineering 关注的是：
给模型什么样的运行环境，让它真正能够完成任务。
这是从 Chatbot 走向 Agent 的关键一步。
六、从 Chatbot 到 Agent
传统 Chatbot：
User
↓
Prompt
↓
LLM
↓
Answer
Agent：
User
↓
Agent
↓
LLM
↓
Tool
↓
Environment
↓
Observation
↓
LLM
↓
Tool
↓
...
比如一个 Coding Agent 可能需要：
File System
Terminal
Git
Search
Database
Browser
Test Runner
模型本身并不会天然拥有这些能力。
我们需要在模型周围搭建一层系统。
这就是 Harness。
七、Harness 到底包含什么？
可以粗略理解成：
┌─────────────┐
│ LLM │
└──────┬──────┘
│
┌────────────────┼────────────────┐
↓ ↓ ↓
Tools Context State
↓ ↓ ↓
File / Git Memory / RAG Task State
│
↓
Environment
│
↓
Verification
│
↓
Guardrails
典型组件包括：
- Tool Calling
- File System
- Terminal
- Sandbox
- Permissions
- Memory
- Context Management
- Verification
- Observability
- Guardrails
2026 年关于 AI Harness Engineering 的研究也开始把任务规格、上下文选择、工具访问、状态、可观测性、验证、权限等视为 Harness 的重要职责。([arXiv][6])
因此：
Model 提供智能，Harness 提供运行环境。
八、Loop Engineering：让 Agent 自己不断推进
有了 Harness，Agent 可以执行任务。
但是一个复杂任务通常不是：
执行一次
↓
完成
而是：
Plan
↓
Act
↓
Observe
↓
Verify
↓
Retry
↓
Observe
↓
Verify
↓
Done
这就是 Loop。
IBM 对 Loop Engineering 的定义，就是设计能够反复引导 Agent 朝目标推进、减少人工逐步干预的 Agentic Workflow。([IBM][2])
九、一个最基本的 Agent Loop
┌───────────┐
│ Goal │
└─────┬─────┘
↓
┌───────────┐
│ Think │
└─────┬─────┘
↓
┌───────────┐
│ Act │
└─────┬─────┘
↓
┌───────────┐
│ Observe │
└─────┬─────┘
↓
┌───────────┐
│ Verify │
└─────┬─────┘
↓
Done?
/ \
No Yes
↓ ↓
Retry Stop
│
└───────────→
这里真正重要的不是“循环”两个字，而是：
Goal
必须明确什么叫完成。
例如：
让全部测试通过
比：
优化代码
更适合作为 Agent 的目标。
Verification
不要让 Agent 自己判断：
应该已经好了。
而应该：
mvn test
pytest
npm test
npm run typecheck
用确定性工具验证。
Stop Condition
必须明确：
什么时候停止？
例如：
测试全部通过
连续 3 次失败
超过 Token Budget
超过时间限制
触发高风险操作
需要人工审批
因此 Loop Engineering 的核心思想可以概括成：
不要不断手动给 Agent 发下一条 Prompt，而是设计一个能够自己推进、验证、重试和停止的循环。
十、Harness 和 Loop 有什么区别？
这是非常容易混淆的地方。
可以这样理解：
Harness
=
一个 Agent 怎么工作
Loop
=
这个 Agent 怎么持续工作
例如：
Harness：
LLM
+
Tools
+
Context
+
Permissions
+
Sandbox
+
Verification
而 Loop：
while (!done) {
context = buildContext();
result = agent.run(context);
verify(result);
if (success) {
break;
}
retry();
}
所以：
Harness 是运行环境，Loop 是控制循环。
十一、Graph Engineering：一个 Agent 不够了
再往上走。
假设我们要让 AI 自动完成一个软件开发任务：
需求分析
↓
代码实现
↓
测试
↓
Code Review
↓
安全检查
↓
部署
显然一个 Agent 全包并不是唯一方案。
我们可以把任务拆成多个节点：
Requirement
↓
Planner
↓
Developer
↓
Test
/ \
Pass Fail
↓ ↓
Review Developer
↓
Security
↓
Human Approval
↓
Deploy
这就是 Graph。
十二、什么是 Graph Engineering？
Graph Engineering 可以理解为：
设计多个 Agent、工具、验证节点、人工节点之间的关系，以及它们之间的信息和控制流。
它解决的问题已经从：
一个 Agent 怎么工作？
升级到了：
多个 Agent 怎么协同工作？
需要设计：
- Node
- Edge
- Branch
- Parallel
- State
- Checkpoint
- Human Gate
- Retry
- Failure Route
例如：
Planner
│
├────→ Developer
│ │
│ ↓
│ Tester
│ / \
│ Pass Fail
│ │ │
│ ↓ └──→ Developer
│ Reviewer
│ │
│ ↓
│ Security
│ │
│ ↓
└──→ Human
需要强调的是：
Graph Engineering 目前仍是一个正在形成中的工程术语，不同资料对它的定义并不完全一致。
一些实践将它理解为多 Agent / 工具 / 检查点的显式工作图，也有实践将它进一步扩展到任务图、信息流和状态拓扑。([GitHub][4])
因此，更适合把它理解成一种：
Agent 系统的架构设计视角。
而不是一个已经标准化的技术规范。
十三、五个 Engineering 到底是什么关系？
现在重新看这五个概念：
Prompt Engineering
↓
Context Engineering
↓
Harness Engineering
↓
Loop Engineering
↓
Graph Engineering
它们实际上是在不断扩大“工程对象”。
第一层：Prompt
工程对象：
一句 Prompt
问题：
怎么说？
第二层：Context
工程对象：
模型当前看到的信息
问题：
模型应该知道什么？
第三层：Harness
工程对象：
模型周围的运行环境
问题：
模型能做什么？
在哪里做？
怎么约束？
怎么验证？
第四层：Loop
工程对象：
Agent 的持续执行过程
问题：
怎么继续？
怎么重试？
怎么验证？
什么时候停止？
第五层：Graph
工程对象：
多个 Agent / Tool / Human Node 的协作关系
问题：
复杂任务怎么拆？
节点怎么连接？
什么时候分支？
什么时候回退？
什么时候人工介入？
十四、用 AI Coding Agent 串起来
假设我要做一个 AI 程序员。
用户输入：
帮我给这个 Spring Boot 项目增加 Redis 缓存。
Prompt Engineering
设计：
你是一名 Java 后端工程师。
请给当前项目增加 Redis Cache。
遵循现有代码规范。
解决：
怎么告诉模型？
Context Engineering
自动提供：
项目结构
pom.xml
Spring Boot Version
Service
Controller
Redis Config
数据库结构
相关代码
历史修改记录
解决：
模型应该知道什么？
Harness Engineering
给模型：
Read
Write
Search
Terminal
Git
Maven
Test
同时限制：
禁止访问生产数据库
禁止删除项目
禁止直接 push main
解决：
模型在哪里工作？能够做什么？
Loop Engineering
Agent：
分析代码
↓
修改代码
↓
mvn test
↓
失败
↓
读取错误
↓
修复
↓
mvn test
↓
通过
↓
结束
解决：
模型如何持续完成任务？
Graph Engineering
进一步拆分：
Planner
↓
Developer
↓
Tester
↓
Reviewer
↓
Security
↓
Human
↓
Deploy
解决：
多个 Agent 和工具如何协同？
十五、为什么这些概念现在突然流行？
本质上是因为：
LLM 的能力越来越强，系统的瓶颈开始从模型本身向模型周围的工程基础设施转移。
早期我们经常讨论：
哪个模型更强？
GPT 还是 Claude？
Prompt 怎么写？
但当模型已经可以：
写代码
搜索资料
调用 API
操作文件
运行程序
修改代码
运行测试
真正的问题开始变成：
它应该看到什么？
它能调用哪些工具？
它拥有哪些权限？
它怎么知道自己错了？
失败以后怎么恢复？
怎么防止无限循环？
怎么控制成本？
多个 Agent 怎么协作？
什么时候必须人工介入？
这也是为什么 Context Engineering 被 Anthropic 描述为 Prompt Engineering 在 Agent 时代的自然延伸，而 Harness Engineering、Loop Engineering 等概念进一步把问题扩大到运行环境和持续执行机制。([Anthropic][1])
十六、最终总结
可以用一张图记住这五个概念：
┌─────────────────────────────────────────────┐
│ Graph Engineering │
│ 多 Agent / Tool / Human 如何协同 │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ Loop Engineering │ │
│ │ Agent 如何持续执行与验证 │ │
│ │ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Harness Engineering │ │ │
│ │ │ Agent 在什么环境工作 │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────────┐ │ │ │
│ │ │ │ Context Engineering │ │ │ │
│ │ │ │ 模型应该知道什么 │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ Prompt Engineering │ │ │ │
│ │ │ │ 我应该怎么告诉模型 │ │ │ │
│ │ │ └─────────────────────┘ │ │ │
│ │ └─────────────────────────────┘ │ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
也可以直接记成：
Prompt
↓
怎么说？
Context
↓
知道什么？
Harness
↓
怎么工作？
Loop
↓
怎么持续？
Graph
↓
怎么协同？
这五个概念真正值得关注的地方，并不是多了五个 AI 名词。
而是它们体现了一个非常明显的趋势：
AI Engineering 正在从 Prompt Engineering 逐渐走向 Agent System Engineering。
过去我们把模型当成一个“回答问题的函数”。
现在越来越多的系统开始把模型当成一个：
Reasoning Engine
+
Tools
+
Context
+
Memory
+
Runtime
+
Verification
+
Loop
+
Workflow
最终形成真正能够完成工作的 Agent System。
所以，当你下一次开发 AI 应用时，与其只问：
“我的 Prompt 写得够好吗？”
不如继续问：
模型现在缺什么 Context？
它拥有哪些 Tools？
Harness 怎么设计？
结果如何 Verification？
Loop 如何 Retry？
什么时候 Stop？
多个 Agent 如何 Graph 化？
这可能才是从“会调用大模型”走向“真正做 AI 应用工程”的关键一步。
扫一扫
1038
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
