从 Prompt 到 Loop：AI 工程到底在卷什么
半年前的我还天天琢磨怎么写 prompt。现在更常问的问题是：怎么让这个 AI 自己跑起来、自己检查、自己接着跑？
这不是因为 prompt 不重要了，而是AI 应用的瓶颈已经从"模型听不懂"变成了"系统不可靠"。Loop Engineering 橙皮书把这个变化概括成四层工程栈。我觉得这个框架挺准的，分享给你。
| 层级 | 核心问题 | 解决什么 |
|---|---|---|
| Prompt Engineering | 我该怎么说？ | 单次调用质量 |
| Context Engineering | 给模型看什么？ | 信息供给质量 |
| Harness Engineering | Agent 能做什么、做得多可靠？ | 单次任务执行可靠性 |
| Loop Engineering | 怎么让 Agent 自己持续运行？ | 自动化循环系统 |
下面按顺序聊。
一、Prompt Engineering：让模型听懂这一次
Prompt Engineering 是最里面那层，也是最容易上手的一层。它干的事很简单：在一次调用里，把任务说清楚。
但"说清楚"本身就有讲究。我习惯把 prompt 拆成这么几块：
- Persona：你是什么角色。比如"你是这个项目的后端负责人"。
- Purpose：这次要干什么，别含糊。
- Process：按什么步骤来，特别是复杂任务。
- Policy：长度、风格、不能做什么。
- Presentation：输出格式，JSON / Markdown / 表格都行。
- Proof：输出前自己检查一遍。
工程上常见的手法包括 Zero-shot / Few-shot / Many-shot、Chain-of-Thought、ReAct，以及把 System Prompt 和 User Prompt 分开管理。还有一件越来越重要的事：把 prompt 当代码做版本控制，方便 A/B 测试和回滚。
Prompt Engineering 的上限就是单次调用质量。它能让模型这次回答得更好，但管不了模型不知道的东西，也管不了长期行为。
二、Context Engineering：别让模型靠猜
Context Engineering 解决的是一个很现实的问题：模型不是你公司的人，它不读你们的需求文档，也不记得上周的讨论。
所以得有人帮它挑信息。
真实应用里的上下文可能来自用户输入、历史对话、知识库、文档、数据库、API 返回、工具执行结果，还有各种短期和长期记忆。Context Engineering 就是把这些东西整理好，按正确的顺序、合适的长度塞进上下文窗口。
通常的流程是：
- 检索：从向量库、数据库、文件系统里召回相关内容。
- 过滤去重：去掉噪声和重复。
- 排序：按相关性、时效性、重要性排。
- 压缩：长内容做摘要或提取关键片段。
- 注入：把整理好的信息放进 prompt。
RAG 是最常见的实践。Anthropic 最近提的 Contextual Retrieval 也挺有意思，给每个 chunk 加点上下文说明，检索质量会好很多。另外长上下文模型越来越能装，但装得多不等于装得对，RAG 在成本和可解释性上仍有优势。
这件事的核心不是塞更多信息，而是给模型刚好需要的信息。太少，它编；太多，它抓不住重点；顺序乱了，它会被干扰。
三、Harness Engineering：把 AI 从 Demo 里捞出来
Harness Engineering 是我最近花时间最多的一层。它解决的是一个很朴素的问题：这东西能不能上线，能不能放心用。
Harness 就是模型外面的那层壳。它包括 Agent Loop、工具调用、权限控制、Guardrails、错误处理、日志、可观测性、评估系统、版本管理、成本控制这些。
一个典型的单次 Agent Loop 大概是：
- 收集上下文
- 采取行动
- 校验结果
如果结果不对，就反馈回去再试。
OpenAI 讲 Harness Engineering 时提到两个目标：一是提高 Agent 一次做对的概率；二是提供反馈闭环，让问题在到人眼之前尽量自我修复，好的 harness 能减少 review 负担，提升系统稳定性。
工程实践上，我觉得这几件事最关键：
- 可执行性：能验证 Agent 实际做了什么，而不是只听它说了什么。
- 可检查性：出问题能定位。
- 结构化日志：记录输入、输出、工具调用、耗时、成本。
- 自动化评估：离线 evals + 在线监控，持续看准确率、幻觉率、任务完成率。
- 沙箱和 worktree 隔离：别让 Agent 在主分支上乱来。
没有 Harness，AI 应用基本就是 Demo。有了 Harness，它才可能进生产环境。
四、Loop Engineering：设计一个会自己运转的系统
Loop Engineering 是最近我听得最多的概念。它的核心想法是：
别再做那个一句句 prompt AI 的人，去设计一个会自动 prompt AI 的系统。
传统模式是：
text
人 -> Prompt -> Agent -> 输出 -> 人Loop 模式是：
text
Loop -> Agent -> Evaluator -> Memory -> Next Loop一个 Loop 通常拆成五个动作：
- Discovery：自动发现该干什么。CI 挂了、新 issue 来了、用户反馈到了。
- Handoff：把任务丢给 Agent，最好每个任务独立 worktree，方便并行。
- Verification：生成和评审必须分开。
- Persistence：状态落盘，markdown、issue board、repo 都行。
- Scheduling：自动定时、自动重跑、自动接续。
橙皮书里强调了一个原则：Generator ≠ Evaluator。写代码的 AI 不能给自己打分，因为它天然偏向自己的输出。这和 GAN 有点像：一个负责生成，一个负责挑错。
现实案例也很有意思。Addy Osmani 做过一个自动 Triage Loop，每天读 CI、看 issue、开 worktree、修 bug、提 PR。Stripe 的 Minions 每周能自动合并上千个 AI PR。这些系统的可靠不靠模型变大，而靠约束和系统设计。
五、四层不是替换关系，是逐层加码
这四层的关系大概是这样：
- Prompt 决定模型要做什么。
- Context 决定模型知道什么。
- Harness 决定模型能不能可靠地做一次。
- Loop 决定模型能不能持续地做、自动地变好。
少了哪一层，都会出问题。
六、一些容易踩的坑
Prompt 层
- 目标不清楚，模型只能猜。
- 约束不明确，输出风格飘忽。
- 只写一句话就想完成复杂任务。
Context 层
- 不给背景，模型硬编。
- 检索噪声大，关键信息被淹没。
- 上下文太长不压缩，模型抓不住重点。
- 记忆机制缺失，长期知识不更新。
Harness 层
- 工具调了没闭环，模型说了没做。
- 没有评估，好坏靠感觉。
- 没有日志，出了问题两眼一抹黑。
- 没有成本权限控制，账单爆炸。
Loop 层
- 验证债：AI 生成越来越多，但没人验证，错误慢慢堆积。
- 理解腐烂：代码全是 AI 写的，人已经看不懂项目了。
- 认知投降：AI 给什么就接受什么，人停止思考。
- Token 失控：自动重试、自动并发，费用不可预测。
七、一点工程上的建议
如果要搭一个正经的 AI 应用，我会按这个顺序来：
- 先定义目标和约束，再写 prompt。
- 先检索相关信息，再放入上下文。
- 先压缩排序，再注入模型。
- 所有输出都要可校验、可追踪、可评估。
- 用数据驱动迭代，而不是靠感觉。
成熟度的判断指标也很实际：准确率、相关性、幻觉率、任务完成率、延迟、成本、失败恢复能力。
八、最后
Prompt 让模型听懂任务。Context 让模型掌握信息。Harness 让模型可靠执行。Loop 让模型自己持续运转。
AI 工程的下一阶段，已经不是怎么写一句好 prompt，而是怎么设计一个会自动运行、自动验证、自动迭代的系统。
系统能帮我们做越来越多的事，如果设计不好，我们可能会在一堆自动生成的代码里慢慢失去判断力。Loop Engineering 真正考验的，可能不是 prompt 功力，而是工程判断。