Agent落地三阶段详解（Prompt / Context / Harness Engineering）
一、第一阶段：Prompt Engineering——解决「话说不清楚」的问题
1. 行业最初的共识
大模型刚普及时，大家都有一个直观感受：同一个模型，问法不同，输出质量差距非常大。随便问一句，得到的回答往往泛泛而谈；但如果换个说法、把逻辑理顺，效果就会好很多。当时行业普遍的认知是：模型能力本身够用，问题出在人没把需求说清楚。
于是大家开始研究怎么写好提示词：给模型设定角色、约束文风、提供参考示例、用思维链分步引导、规定输出格式……这些技巧构成了早期提示词工程的主要内容。
2. 提示词为什么有效
大模型本质上是一个对上下文高度敏感的概率生成系统——它没有自主判断力，只会根据前面的输入往下续写。提示词之所以有效，原理很直接：
- 身份锚定：给它一个职业身份，它就会用对应的视角和口吻来回答，不容易跑偏；
- 示例引导：给它参考样例，它会模仿同样的行文结构和逻辑；
- 约束聚焦：告诉它什么该做、什么不该做，它会在生成时自动向这些约束靠拢。
3. 提示词工程的本质
不是靠硬性指令控制模型，而是通过精心设计的语言铺垫，人为构造一个有利于高质量输出的概率空间，让模型顺势生成我们想要的内容。这个阶段，做AI落地拼的不是系统架构能力，而是语言设计能力。
4. 提示词工程的天花板
它只能优化表达方式、规范输出形式，没办法弥补信息上的缺口。一旦对接真实业务，短板马上暴露——下面这些场景，提示词再好也搞不定：
- 解析企业内部的私有文档；
- 回答产品更新后的最新参数配置；
- 参照一份超长的开发规范来写代码；
- 协调多个工具、跨步骤完成一个完整任务。
5. 小结
✅ 擅长：单轮简单任务、约束输出格式和风格、激活模型自身能力。
❌ 不擅长：补齐模型不知道的私有知识、处理动态变化的信息、管控多步骤复杂任务。
一句话：提示词解决的是「怎么说」的问题，解决不了「信息不够」的问题。行业于是进入第二阶段。
二、第二阶段：Context Engineering——解决「信息给得不到位」的问题
1. 为什么需要这个阶段
如果只是做聊天机器人，单轮对话、不需要记状态，好的提示词就够了。但随着Agent概念的兴起，模型开始要干更复杂的活：多轮对话、联网检索、写代码、查数据库、在多个工具之间传递结果、根据反馈调整方案……
评价标准也变了——不是看单轮回答好不好，而是看一整条任务链能不能跑通。到了这个复杂度，一句提示词根本撑不住。
2. 上下文工程的思路
模型不需要记住所有业务知识，而是工程系统在合适的时机，把合适的信息推送给它。
从工程视角看，上下文远不只是"给模型补充几段背景资料"。所有影响模型当前决策的信息都算上下文：用户输入、历史对话、检索结果、工具返回的数据、任务进度、中间结论、系统规则、安全限制、多Agent之间传递的数据……
一个关键认知：Prompt只是Context的一小部分。怎么动态、精准地组织和供给上下文，才是这个阶段真正要解决的问题。
3. 不只是做检索
基础的RAG只是把资料查出来塞进上下文，但成熟的上下文工程要处理的事情多得多：文档怎么切分、检索结果怎么排序、长文本怎么压缩、历史对话什么时候该保留什么时候该摘要、工具返回的数据怎么筛选脱敏、多Agent之间传什么数据（传结构化的关键字段，而不是把原始内容全堆上去）。
4. 一个典型实践：渐进式能力披露
一个常见的坑：把十几个工具的完整说明一股脑全塞进上下文，理论上信息最全，实际效果很差。因为上下文窗口是有限资源，塞太多无关信息会分散模型注意力，关键指令反而被淹没。
更好的做法是按需披露：一开始只给模型看工具的简要列表；等任务推进到需要用某个工具的时候，再把对应的详细文档、操作规范加载进来。
结论：上下文工程的重点不是信息越多越好，而是在对的时间给对的信息。
5. 上下文工程的局限
即使输入侧的信息已经做到位了——准确、完整、该有的都有——在长链路任务中，模型仍然可能跑偏：计划制定得没问题，执行的时候走歪了；工具调用正常，但误解了返回结果的含义；长时间分步作业中慢慢偏离目标，系统全程没有察觉。
问题浮出水面：输入侧已经优化到位，但模型在连续自主执行的过程中，缺少监督和纠偏机制。第三阶段应运而生。
三、第三阶段：Harness Engineering——解决「执行过程跑偏、稳不住」的问题
1. 什么是Harness Engineering
Harness的本义是马具、缰绳，用来控制方向。放到AI工程领域，意思是：模型从被动回答变成自主干活之后，光做好前期的信息准备和提示词设计还不够，还需要在执行全程进行监控、约束和纠偏，确保复杂任务能稳定完成。
前两个阶段的目标是让模型"更聪明、回答更准"；Harness Engineering的目标是让模型"不跑偏、稳得住、出了错能拉回来、全程可追溯"。
2. 用一个类比说清三者的区别
场景：让一个新人独立去拜访重要客户。
- Prompt Engineering：提前告诉他流程和话术——先破冰、再讲方案、挖需求、定下一步。重点是把任务交代清楚。
- Context Engineering：给他配齐资料——客户背景、历史沟通记录、报价单、竞品分析、这次拜访的目标。重点是把信息准备齐全。
- Harness Engineering：给他带上检查清单，要求关键节点实时汇报，回来后拿录音逐条对照会议纪要，全程监控偏差，发现问题随时远程纠正，最后按量化标准验收。重点不是靠事前准备，而是靠过程监控和结果验收。
3. 三者的关系：不是替代，是逐层递进
- Prompt Engineering：聚焦指令表达；
- Context Engineering：在Prompt的基础上，加上信息供给；
- Harness Engineering：在前两者的基础上，加上执行过程的管控。
覆盖范围逐层扩大，从简单的单轮问答，一直到生产级的Agent复杂任务。
四、Harness Engineering 六层架构
第一层：上下文边界管控（基础层）
模型执行得稳不稳，很大程度上取决于它当前看到的信息是否准确、是否跟任务相关。这一层做的是：
- 明确角色职责、任务目标、验收标准，避免模糊执行；
- 裁剪掉无关信息，只保留高相关内容，节省上下文空间；
- 把不同类型的信息分区存放——系统规则、当前任务、运行状态、外部证据各归各位，避免混在一起导致遗漏。
第二层：可控的工具系统（执行抓手）
没有工具的大模型只是个文本生成器，接不上真实业务。但挂工具不是越多越好，关键要管好三件事：
- 数量控制：太少能力不够，太多容易乱用，要按场景适配；
- 调用时机：不该调的别调（浪费资源），该调的不能漏（避免瞎猜）；
- 结果处理：工具返回的原始数据往往很杂，需要筛选和提炼后再喂给模型，不要把原始数据一股脑堆上去。
第三层：任务执行编排（流程轨道）
Agent的一个常见问题是：单个能力都有（会检索、会写代码、会总结），但串不起来，最后输出一堆半成品。这一层要做的是铺设标准化流程：
拆解目标 → 检查信息是否完整 → 缺什么补什么 → 分步分析 → 生成初步输出 → 自检 → 不合格就重试修正 → 合格则交付
相当于把一个专业人士的工作逻辑固化成流程，用流程来约束模型，而不是让它自由发挥。
第四层：记忆与状态管理（防失忆）
防止Agent在长时间工作中"失忆"。要把三类数据分开管理：
- 当前任务的实时进度；
- 多轮对话中产生的阶段性结论；
- 用户的长期偏好、历史记录等持久化信息。
分开管理后，Agent在长周期任务中才不会越跑越乱、反复返工。
第五层：观测与评估（质检层）
这一层经常被忽视。大多数Agent可以正常生成内容，但没有自检能力——不知道自己做得好不好、错在哪。这一层要补齐的能力包括：输出合规性校验、真实环境实测、自动化批量测试、全流程日志记录、异常告警、故障归因。
要求很明确：系统不仅要能做事，还要知道自己做得对不对。
第六层：约束、校验、自愈与回滚（兜底层）
在真实生产环境中，接口超时、文档格式错乱、检索结果不准、模型理解偏差——这些不是偶发情况，而是日常。系统能不能稳定上线，就看这一层：
- 前置约束：划定红线，明确什么可以做、什么不可以做；
- 前后校验：输出前和交付后都做检查，拦住有问题的结果；
- 故障自愈：出错自动重试，异常节点可回滚，不需要人工介入重启。
五、大厂实践参考
1. Anthropic：两个方案解决自主编码的难题
问题一：上下文越来越长，质量越来越差。 长时间工作后上下文不断膨胀，模型会逐渐丢失关键细节、草率收尾。单纯做压缩效果有限。
解法：Context Reset。 不去压缩旧的上下文，而是直接启动一个新Agent，把已完成的工作状态交接过去，让它在干净的上下文中继续。就像处理内存泄漏——与其反复清缓存，不如直接重启进程、恢复状态。
问题二：模型自己评估自己，容易盲目乐观。 自己干活自己打分，没有标准答案的情况下偏差很大，容易放过隐性bug。
解法：执行和验收分离。
- Planner：把模糊的自然语言需求拆解成可执行的规格；
- Generator：按规格逐步实现；
- Evaluator：独立验收——实际运行页面、检查交互效果、查看日志，在真实环境中验证，不做纸上审查。
形成「生成→验收→修复→再验收」的循环，从结构上避免自评盲区。
2. OpenAI：重新定义工程师在Agent时代的角色
他们的观点是：工程师的工作重心不再是手写业务代码，而是做好三件事：
- 把产品目标拆解成Agent能处理的子任务；
- Agent做不好的时候，不是去调模型参数，而是排查它缺了什么环境支持，把短板补上；
- 搭建反馈通路，让Agent能看到自己的执行结果和问题所在。
实践一：文档分层索引。 不再用一个巨大的规则文档，改成一个精简的目录索引页，具体规范拆成独立子文档，Agent按需查阅，不占用宝贵的上下文窗口。
实践二：打通观测环境。 让Agent能操作浏览器、截屏验证页面、接入日志和监控系统自主排查bug。每个任务独立隔离运行。Agent写完代码可以自己部署、测试、发现问题、修复、复测——整个闭环不需要人参与。
实践三：把经验固化成规则。 把资深工程师关于代码分层、依赖管理、风险拦截的经验，变成系统自动执行的规则。发现问题的同时推送修复建议给Agent，形成自动化治理，不再依赖人工逐行Review。
六、总结
- Prompt Engineering：解决「怎么把任务说清楚」，适用于简单的单轮交互。
- Context Engineering：解决「怎么把信息给到位」，适用于需要外部知识和实时数据的场景。
- Harness Engineering：解决「长链路任务怎么稳定做对」，适用于生产级Agent落地。
三者互不替代，逐层递进。模型能力决定了产品的上限，但缰绳工程决定了产品能不能真正上线、能不能稳定运行。
行业趋势已经很清楚：AI落地的重心，正在从"让模型更聪明"转向"让模型在真实场景中稳定干活"。做Agent落地，Harness Engineering是绕不开的一关。
