文章目录先说结论为什么大家突然不再只聊 Prompt 了Prompt Engineering 到底在做什么Context Engineering 为什么越来越重要Harness Engineering 为什么很多人没讲明白最近为什么大家开始聊 Loop Engineering这四种 engineering 到底是什么关系用一个例子看懂从“回答问题”到“完成任务”做 Loop Engineering 最怕什么如果你现在做 Agent应该先补哪一层面试里怎么把这几个词讲清楚结尾先说结论如果你现在还把大模型应用理解成“写一段 prompt然后等它回答”那大概率已经落后半代了。前几年大家讨论最多的是Prompt Engineering核心是“怎么把话说清楚”后来越来越多人开始讲Context Engineering核心是“怎么把该给模型的信息喂对”再往后又冒出来Harness Engineering关注的是“怎么把模型、工具、评测、执行环境真正接起来”而最近被反复提到的Loop Engineering本质上是在讨论一件更工程化的事怎么让模型不是只回答一次而是能围绕目标不断观察、决策、执行、纠错直到把事情做完。一句话概括Prompt Engineering 解决的是“怎么问”Context Engineering 解决的是“给它什么信息问”Harness Engineering 解决的是“让它在什么系统里工作”Loop Engineering 解决的是“让它怎么持续干活直到完成”所以它们不是替代关系而是一层一层往上加的工程能力。为什么大家突然不再只聊 Prompt 了Prompt 当然重要但问题是真实业务很快就会把“只会写 prompt”这件事打回原形。比如你让模型帮你分析一个线上故障根据公司知识库生成发布说明自动查订单、查日志、汇总结论写完代码后自己跑测试、看报错、继续修这时候你会发现问题根本不只是“提示词怎么写更优雅”而是该给模型哪些上下文上下文太多了怎么裁剪工具怎么调失败了怎么重试中间结果怎么保存什么时候继续循环什么时候停下来也就是说一旦任务不再是单轮问答而是多步执行prompt 就从主角变成了一个零件。Prompt Engineering 到底在做什么Prompt Engineering 最容易理解因为它就是大家最早接触 LLM 时做的那件事设计输入让模型更容易输出你想要的结果。常见手段包括设定角色约束输出格式给 few-shot 示例拆解步骤明确成功标准比如同样是让模型“写个接口文档”普通问法可能只会得到一段泛泛而谈的说明但如果你补上输入参数、返回结构、异常码风格、输出模板它的结果往往会稳定很多。所以 Prompt Engineering 的价值一直都在。它解决的是表达问题。但它也有边界。它默认了一个前提你需要的信息已经都在这一轮输入里了。一旦这个前提不成立光靠 prompt 就不够了。Context Engineering 为什么越来越重要Context Engineering 说白了就是围绕一次调用决定“什么信息该进上下文什么不该进”。很多人一开始会把它理解成“往 prompt 里塞更多内容”其实正好相反。真正好的 Context Engineering不是把东西塞满而是把东西喂准。它通常关心这些问题当前任务真正需要哪些背景信息历史对话哪些还相关哪些该丢工具返回的数据怎么裁剪和结构化RAG 召回哪些片段最值得放进去用户偏好、系统规则、运行状态怎么一起组织你会发现这已经不是语言技巧了而是信息编排能力。举个很常见的例子用户问“帮我总结这次线上事故原因”。如果你一股脑把所有日志、群聊、工单、监控数据都扔给模型它大概率会被噪声淹没。真正有效的做法往往是先筛出和事故时间段相关的数据再抽取关键事件和异常字段最后把业务背景、影响范围、时间线拼成一个可理解上下文这时候你做的就已经不是 Prompt Engineering而是 Context Engineering 了。Harness Engineering 为什么很多人没讲明白Harness 这个词本来就容易让人有点懵。你可以先把它理解成把模型“套进”一个能工作的系统框架里。它关心的不是单条 prompt也不是单次上下文而是整套运行支架模型怎么接入工具怎么注册和调用输出怎么校验评测怎么做失败怎么兜底日志、监控、回放怎么保留如果说 Prompt Engineering 是“写得好”Context Engineering 是“喂得准”那 Harness Engineering 就是“搭出一个能稳定跑的工作台”。很多 Agent 项目一开始 demo 很惊艳后来一上线就不稳根本原因通常不是模型突然变笨了而是 harness 太薄没有统一的工具协议没有结构化输出校验没有超时和重试策略没有轨迹记录没有回放和评估闭环所以 Harness Engineering 更像传统后端工程。它不性感但很关键。没有它很多所谓“智能体”都只是一次性演示。最近为什么大家开始聊 Loop EngineeringLoop Engineering 最近火起来不是因为它是个特别玄的新概念而是因为大家慢慢意识到真正有用的 Agent不是会答一道题而是会围绕目标连续做很多步动作。这就需要 loop。所谓 Loop Engineering本质上是在设计这样一条循环读当前状态判断下一步做什么调模型或工具执行观察结果更新状态再决定继续、回退、重试还是结束它关注的是“循环怎么设计才不失控”。比如下面这类问题都是典型的 Loop Engineering 问题模型什么时候应该继续调用工具什么时候该停一次失败后是重试、换方案还是直接降级多轮执行里状态怎么积累如果任务跑偏了怎么把它拉回来如何避免死循环和无意义反复调用换句话说Loop Engineering 不是在优化一句提示词而是在优化一个会反复运行的任务闭环。这四种 engineering 到底是什么关系它们最容易被误解的地方是总有人把它们讲成“新词替代旧词”。其实不是。更准确的理解应该是它们对应的是大模型应用从单轮问答走向可执行系统的四层升级。LLM engineering evolutionThis diagram shows how LLM application design evolves from prompt writing to context design, system harness, and task loops.Prompt Engineering怎么问Context Engineering给什么信息Harness Engineering放进什么系统里Loop Engineering怎么持续执行直到完成这个演进顺序可以这样理解你先得会把需求说清楚所以有 Prompt Engineering你很快发现说清楚还不够得喂对信息所以有 Context Engineering然后你发现信息和模型也还不够系统得稳定可控所以有 Harness Engineering最后你发现单次调用解决不了任务得把规划、执行、观察、修正串成闭环所以有 Loop Engineering越往后越接近真正的工程落地。用一个例子看懂从“回答问题”到“完成任务”我们用一个简单场景来感受一下差别。需求是“帮我修一个单元测试失败的问题。”如果你只有 Prompt Engineering做法通常是把报错贴给模型让它猜原因让它给修改建议这适合问答但不适合真实执行。如果你加入 Context Engineering系统会进一步做这些事拉取失败测试日志补充相关代码片段附带最近一次改动 diff把无关文件和噪声裁掉这时模型回答会靠谱很多。如果再加上 Harness Engineering系统就不只是“问”而是能调 git / 测试 / 搜索工具要求模型按结构化格式输出自动校验改动有没有语法问题记录每一步的输入输出这已经是一个可运行的 agent 框架了。而到了 Loop Engineering事情会再往前一步先读失败日志定位怀疑文件修改代码重新跑测试如果还失败重新分析新的报错必要时切换方案直到测试通过或达到停止条件这时候它不再只是“给建议”而是在围绕目标持续迭代。所以你会发现Loop Engineering 真正让 Agent 从“像助手”变成了“像执行器”。做 Loop Engineering 最怕什么最怕两件事。第一件事是循环失控。比如一直重复同样的工具调用遇到错误只会机械重试明明没有新信息还是继续生成下一步任务已经跑偏却没人纠正第二件事是循环看起来很忙其实没有有效进展。这类系统往往日志很多、步骤很多、token 也花得很多但最后没把问题真正解决。原因通常是缺少明确的目标状态可观测的中间状态每一步的评估标准停止条件回退和降级机制所以 Loop Engineering 的关键不是“多循环几轮”而是让每一轮都带来可验证的推进。如果你现在做 Agent应该先补哪一层很多人看完这些概念第一反应是想直接追最新的 Loop Engineering。其实不一定。更现实的顺序通常是先把 Prompt 写明白别让模型连任务都没理解再把 Context 管起来别让它吃一堆噪声再把 Harness 做扎实别让工具调用、输出校验、重试策略全靠运气最后再去优化 Loop让系统真正能连续完成任务因为没有前面三层loop 往往只会把错误放大得更快。你可以用一句很实用的话判断自己现在在哪一层如果你还在琢磨“这句提示词怎么写更好”你大概率还在 Prompt Engineering。如果你已经在认真处理检索、记忆、历史、裁剪、状态注入你在做 Context Engineering。如果你开始关心工具协议、输出约束、评测、回放、监控你已经进入 Harness Engineering。如果你的系统会根据结果不断继续做下一步直到目标完成或满足停止条件你就在做 Loop Engineering。面试里怎么把这几个词讲清楚如果面试官问你这几个 engineering 有什么区别可以直接按下面这个逻辑答Prompt Engineering 解决的是如何表达任务让模型更容易按预期输出Context Engineering 解决的是如何为当前任务组织最相关的信息Harness Engineering 解决的是如何把模型接进一个稳定、可观测、可评测的执行系统Loop Engineering 解决的是如何让模型围绕目标持续规划、执行、观察和修正而不是只做单轮回答。这段话的好处是它不是在背定义而是在讲工程边界。结尾这波概念演进表面上看是在给 Agent 领域发明越来越多的新词实际上是在逼大家承认一个现实大模型应用真正难的部分早就不是“会不会写 prompt”了而是怎么把提示、上下文、工具系统和执行循环拼成一个能长期工作的工程闭环。所以别再把 Prompt Engineering 当成全部。它当然重要但它更像起点不是终点。当你开始关心上下文组织、工具支架、运行轨迹和任务闭环时你才算真正走进了 Agent 工程。
