从Prompt到Environment：AI Agent工程化的五次范式跃迁
从Prompt到Environment：AI Agent工程化的五次范式跃迁
当模型不再是瓶颈，真正的挑战在于如何让它在真实世界中不失控。
1. 起点：Prompt Engineering——学会“好好说话”
2023年，整个行业沉浸在一种近乎玄学的氛围中。那时候，我们相信一句措辞精妙的“咒语”能点石成金。这就是Prompt Engineering（提示工程）的时代。
它解决的核心问题：意图对齐。 模型像一个能力极强但理解力有限的高级实习生，你需要把模糊的人类意图，翻译成它听得懂的“模型语言”。
本质上看，Prompt Engineering处理的是单次输入-输出对的优化，是无状态的。一个好的Prompt长什么样？对比一下：
# 粗糙的Prompt
prompt = "帮我修一下代码里的bug"
# 经过Prompt Engineering优化的Prompt
prompt = """你是一位资深Python工程师，正在审查一个生产环境的bug。
背景信息：
- bug导致orders.py第47行抛出KeyError
- 仅发生在周末批量处理时
- 系统使用PostgreSQL和只读副本
任务：
1. 先定位根本原因，不要修改任何代码
2. 描述什么数据条件会触发此错误
3. 提出一个保持向后兼容的修复方案
4. 列出需要补充的测试用例
在我确认诊断之前，不要修改任何文件。"""
区别一目了然：后者给了角色、背景、步骤和边界。但Prompt Engineering有硬天花板——如果模型根本访问不到orders.py，没有工具运行测试，写得再好也是空中楼阁。
2. 进阶：Context Engineering——让模型“看得准”
当任务从单轮对话扩展到多轮、长周期，核心瓶颈从“怎么说”变成了“看什么”。Context Engineering（上下文工程）应运而生。
它解决的核心问题：信息供给。 模型不再只靠当前输入，而是要在一个动态的信息环境中做决策——把对的信息，在对的时候，喂给对的地方。
Context Engineering有三个关键支柱：
- 检索（RAG） ：当知识超出上下文窗口，就建立向量索引，在需要时把最相关的片段“拽”进来
- 工具（Tools） ：模型需要与现实世界交互——读文件、查API、跑命令。工具描述是否清晰（Function Calling的Schema设计），直接决定模型会不会“用错工具”
- 记忆（Memory） ：模型本身是无状态的。Context Engineering要决定：什么留在活跃窗口，什么做摘要压缩，什么存到长期存储供后续检索
一个关键洞察：Context Engineering解决的是“模型看到什么”，但没解决“模型做错了怎么办”。它让模型“看得准”，但还没让模型“做得对”。
3. 攻坚：Harness Engineering——给AI套上“缰绳”
“Harness”一词源自马术，本意是“马具”。如果说大语言模型是一匹动力强劲但可能失控的野马，Harness就是那副缰绳和传动系统。
它解决的核心问题：可控运行。 Harness Engineering被定义为“对系统的设计与实现，约束Agent能做什么，告知它应该做什么，验证它是否正确完成，并在出错时纠正它”。
LangChain的一个实验极具说服力：他们没换底层模型，只改了Harness，Terminal Bench 2.0得分就从52.8%飙升到66.5%，从前30跃入前5。改动包括：自我验证循环、目录结构映射、循环检测、推理预算策略——同一个模型，不同的“缰绳”，天壤之别。
一个真实的Harness配置示例（CLAUDE.md）：
## Project conventions
- All database access goes through /src/db/queries/, never raw SQL inline
- Use `pnpm run typecheck` after every change
- Never modify migration files after they've been committed
## Verification
Run `pnpm run typecheck && pnpm test --changed` before stopping.
Failures are required reading - do not ignore them.
再看一个Sub-agent隔离上下文的调度模式（Harness层面的任务拆分）：
def trace_request_flow(parent_agent, service_name):
sub_agent_prompt = f"""
Trace the request flow for {service_name}.
Return only:
1. Entry point file:line
2. Key middleware in order
3. DB queries triggered
Cite sources as filepath:line.
Do not include intermediate steps in your response.
"""
# Sub-agent在隔离的上下文窗口中运行
result = dispatch_sub_agent(sub_agent_prompt, tools=["read", "grep"])
# 父Agent只看到浓缩后的结果
return result
Hook机制是Harness的另一核心——在Agent生命周期的特定事件触发确定性反馈：
#!/bin/bash
# 每次Agent停止后运行类型检查
OUTPUT=$(bun run --parallel "biome check . --write --unsafe" "turbo run typecheck" 2>&1)
if [ $? -ne 0 ]; then
echo "$OUTPUT" >&2
exit 2 # 退出码2重新激活Agent来修复错误
fi
# 成功则静默，不污染上下文
Harness的本质：它不是“封装逻辑的中间件”，而是复杂系统的“控制平面”与“策略层”。API可以吞噬“机制”，但替代不了“策略”——什么时候触发降级、如何在Token预算下切分任务、多个Agent冲突时听谁的。
4. Loop Engineering——让AI“会纠错”
当Agent开始执行多步任务时，一个致命问题浮现：一次推理错了，整条链就崩了。传统的单次推理没有“后悔药”。Loop Engineering（循环工程）解决的正是“迭代修正”的问题。
它解决的核心问题：自我修正闭环。 一个健壮的Agent系统不应该只会“一次性生成”，而应该具备 “执行→验证→反馈→重试” 的循环能力。
Loop Engineering的经典范式是 ReAct（Reason + Act） 模式——推理后行动，行动后观察，观察后再次推理，形成一个闭环：
Thought（思考） → Action（行动） → Observation（观察结果） → Thought（再思考） → ...
为什么需要Loop？ 一个任务往往需要多步才能完成。比如“分析这个项目里所有未使用的导出函数”：
- Step 1：用
grep找所有export语句 - Step 2：用
grep找所有import语句 - Step 3：对比差异
- Step 4：如果结果太多，需要分页或筛选
每一步的输出都依赖上一步的观察结果，这就是Loop存在的根本原因。
一个极简的Loop实现：
class AgentLoop:
def __init__(self, max_iterations=10, max_stalls=3):
self.max_iterations = max_iterations
self.max_stalls = max_stalls
self.consecutive_stalls = 0 # 连续无进展次数
def run(self, initial_prompt):
context = initial_prompt
step = 0
while step < self.max_iterations:
# 1. 推理
thought, action = model.generate(context)
# 2. 行动（调用工具）
observation = execute_action(action)
context += f"\n[Observation] {observation}"
# 3. 自检——判断是否到达终止状态
if self._check_completion(context):
return model.generate_final_answer(context)
# 4. 防死循环：检测是否原地踏步
if self._detect_stall(context):
self.consecutive_stalls += 1
if self.consecutive_stalls >= self.max_stalls:
# 强制反思——"你一直在重复同样的话，换个思路"
context += "\n[Sys] You're repeating yourself. Try a different approach."
else:
self.consecutive_stalls = 0
step += 1
# 超时兜底：输出当前最佳结果
return model.generate_final_answer(context, fallback=True)
Loop Engineering的深层难点——“奖励信号”从哪里来？
Harness给出了“规则”，但Agent执行的每一步，谁告诉它对不对？这里需要引入过程级奖励模型（Process Reward Model, PRM）：
def verify_step(action, observation):
# 这是一个简化的PRM打分
score = 0
if action.tool in ["read", "grep", "ls"]:
score += 1 # 只读操作安全
if len(observation) > 0:
score += 1 # 有产出
if "error" in observation.lower() or "denied" in observation.lower():
score -= 2 # 执行失败
return score
真正的Loop工程远不止“for循环套个Agent调用”，它需要：
- Self-Correction：检查到错误后，Agent能否自己纠正
- Stall Detection：检测Agent是否在重复输出（死循环检测）
- Budget Management：每一步消耗多少Token，超预算后如何降级
- Search vs. Exploit：是继续深入当前路径（利用），还是换个新方向（探索）
Loop与Harness的分界线：Harness管“做几步、按什么顺序做”；Loop管“每步做完后，判断要不要重做、怎么修正”。Harness是流程编排，Loop是反馈修正。
5. Environment Engineering——构建“不会炸楼”的物理防线
如果说Harness是“规则”，Loop是“纠错机制”，那么Environment Engineering就是“物理边界”。这是最后的兜底防线。
它解决的核心问题：硬兜底。 Environment Engineering被定义为“构建能放大生产力行为、抑制有害行为的环境——资源、约束和接口”。
Harness和Environment的本质区别：
| 维度 | Harness / Loop | Environment Engineering |
|---|---|---|
| 本质 | 逻辑/流程约束 | 物理边界 |
| 类比 | 交通规则 + 驾考纠错 | 道路护栏 |
| 控制方式 | 软约束（Agent可能无视） | 硬约束（想违规都没门） |
| 失效后果 | 逻辑混乱、死循环、费资源 | 数据泄露、资产受损、事故 |
一个真实场景：你让Agent管理数据库。
- Harness/Loop做法：在Prompt里写“千万别删库”，或加个Retry逻辑，检测到危险操作后尝试纠正
- Environment做法：在数据库权限层直接Disable Drop权限，或丢进沙箱跑。Agent就算Loop爆炸产生幻觉发疯，也删不掉一行数据。
风控圈有句话叫“不要信任，要验证”。放到Agent工程里，就是：不要指望Prompt或Loop能拦住一个犯错的模型，要在物理层面让它犯不了错。
EurekAgent将Environment Engineering拆解为四个维度：
- 权限工程：限制Agent执行边界，隔离评估环境
- 产物工程：基于文件系统和Git的协作管理
- 预算工程：Token和成本的感知式探索
- 人机回环工程：便于人工监督和干预（“人在回路”）
6. 演进逻辑与未来格局
这五个层级并非替代关系，而是层层递进、相互叠加的能力升维。每一层都在为上一层“擦屁股”：
| 层级 | 核心问题 | 类比 | 失效时谁兜底 |
|---|---|---|---|
| 1. Prompt Engineering | 怎么说？（意图对齐） | 清晰的指令 | Context |
| 2. Context Engineering | 看什么？（信息供给） | 充足的材料 | Harness |
| 3. Harness Engineering | 怎么控？（流程编排） | 项目章程 | Loop |
| 4. Loop Engineering | 错了怎么改？（自我修正） | 复盘机制 | Environment |
| 5. Environment Engineering | 在哪做、兜不兜得住？（物理防线） | 护栏 | 物理世界 |
一个Agent运行的完整闭环：
用户输入
↓
【Prompt Engineering】→ 翻译成模型指令
↓
【Context Engineering】→ 检索相关信息、加载工具定义
↓
【Harness Engineering】→ 决定调用哪个Sub-agent、按什么顺序
↓
【Loop Engineering】→ ReAct循环：执行→验证→纠错→再执行
↓
【Environment Engineering】→ 沙箱隔离、权限拦截、成本监控
↓
安全输出（或Human-in-the-loop介入）
AI产业价值的三阶段推演：
- 第一阶段（2023-2025）模型为王：AI应用能力 ≈ 模型能力
- 第二阶段（2025-2028）Harness × Loop为王：AI应用能力 = 模型能力 × Harness效率 × Loop修正质量
- 第三阶段（2028+）数据与Environment为王：AI终极能力 = (模型能力 × Harness × Loop) ^ (数据 × 环境治理)
未来的壁垒不是“更酷的沙箱”，而是环境治理（Governance）与反馈学习（Feedback Learning）的闭环。Agent在Loop里踩了坑，系统能否自动从失败日志中提取教训，沉淀为Environment层面的新策略？从“踩坑”到“填坑”的过程能否自动化？
对开发者的启示：别再只盯着Prompt了。学Docker、K8s、权限管理——未来的核心竞争力不是“跟AI对话的能力”，而是“构建一个AI做了也不会出错的环境”的能力。
Prompt决定它说得好不好，Context决定它看得准不准，Harness决定它跑得稳不稳，Loop决定它错了会不会改，Environment决定它一旦摔倒，会不会炸毁整栋楼。