Prompt、Context、Harness 工程全景图
最近跟不少朋友聊 Agent，发现一个特别有意思的现象。
大家一遇到效果不好，第一反应基本都是改 Prompt。改角色，改语气，改格式，再加一句你要认真思考，再加一句输出前自我检查。然后模型偶尔好了，偶尔又不行，搞到人开始怀疑人生，觉得是不是模型不够强，或者自己不会写 Prompt。
说真的，我非常理解这种感觉。因为我自己一开始也这样。愚钝如我，刚开始做 Agent 应用的时候，也经常把所有锅都甩给 Prompt，仿佛只要找到那句神奇咒语，系统就能稳定、可靠、可复现。
但后来越做越发现，不是这么回事。
Prompt 当然重要。但只盯着 Prompt 做 Agent，有点像你只训练一个人怎么说话，却不给他资料，不给他工具，不给他流程，也不告诉他做错了怎么办。
那他能稳定才怪。。。
我现在越来越觉得，一个真正能跑进业务里的 LLM Agent 应用，通常不是一层东西，而是三层东西叠在一起。
它们像三个同心圆。
最里面是 Prompt Engineering，决定模型这一次要做什么。
中间是 Context Engineering，决定模型此刻知道什么。
最外面是 Harness Engineering，决定模型怎么可靠地做，并且持续变好。
这块我觉得挺重要的，因为很多 AI 应用死掉，不是死在模型智商不够，而是死在工程层没搭起来。
1、Prompt Engineering 指令层
Prompt 是最直观的东西，也是大家最容易接触到的东西。它负责告诉模型，你是谁，你要干什么，你按什么步骤干，哪些事不能干，交付成什么样。
一个还不错的 Prompt，通常至少要讲清楚六件事，角色、目标、流程、约束、输出格式、自检方式。你让 Claude Code 改代码也好，让 Codex 写脚本也好，让 ChatGPT 帮你整理材料也好，如果这几件事没说清楚，它就很容易往自己最熟悉的方向跑。
比如你只说帮我分析一下这个项目。那它可能给你写一篇介绍，也可能给你列风险，也可能直接开始改文件。不是它故意皮，是你的任务边界本来就是虚的。
所以 Prompt Engineering 解决的，其实是单次调用的表达质量问题。它让模型更容易听懂任务。
但问题来了。
只听懂任务，够吗？
不够。
因为模型就算听懂了，也可能不知道你公司最新的接口改了，昨天用户刚反馈的 bug 是什么，仓库里某个函数为什么不能动，业务里哪个字段其实是历史包袱。
这时候就到第二层了。
2、Context Engineering 信息层
我觉得 Context Engineering 是这两年被严重低估的一层。很多人嘴上说 RAG，脑子里想的还是把资料塞给模型。
但上下文工程不是塞资料。
上下文工程是喂情报。
你想想看，一个人要做判断，最怕的不是信息少一点，而是拿到一堆乱七八糟、过期、重复、互相打架的信息。模型也一样。上下文太少，它会编。上下文太多，它会抓不住重点。上下文顺序乱，它会被噪声带偏。上下文过期，它会一本正经地基于错误事实做判断。
这尼玛就是很多 Agent 看起来很聪明，用起来很不可靠的原因之一。
所以 Context Engineering 真正要做的，不是把所有东西塞进窗口里，而是先检索，再筛选，再压缩，再排序，把刚好需要的信息放到模型面前。
比如一个代码 Agent 要修 bug，它需要的不是整个仓库。它需要相关报错、相关文件、相关调用链、最近改动、测试结果，以及那些人类知道但模型不知道的潜规则。
比如这个接口虽然看起来没人用，但其实被一个老系统凌晨三点的任务调用。
不是哥们，这种信息你不给它，它怎么可能知道。
所以 Context 解决的是信息质量问题。Prompt 让模型听懂任务，Context 让模型少猜。
说到这里，其实已经能解释很多问题了。
为什么同一个 Prompt，有时候效果很好，有时候效果很差？因为模型面对的上下文不一样。
为什么同一个知识库，换个检索策略，回答质量差别巨大？因为模型看到的信息顺序和密度不一样。
为什么很多 Agent Demo 看起来很炸，但一上线就崩？因为 Demo 场景里的上下文是干净的，真实业务里的上下文是脏的。
大时代啊，朋友们。
真实世界不是一份整理好的 Markdown。真实世界是一堆数据库字段、历史文档、聊天记录、网页、权限、报错日志和人类口头约定揉在一起的毛线球。
Context Engineering，就是把这个毛线球理到模型能处理的程度。
但这还不够。因为就算 Prompt 写好了，Context 也喂准了，模型还是会犯错。
它可能工具调用失败，可能拿到了错误结果，可能成本超预算，可能权限越界，可能把一个不该删的东西删了，也可能任务做到一半发现信息不够，但它不好意思说，继续硬编。
这时候就到了最外层。
3、Harness Engineering 系统层
这个词有点工程味，直译是线束、牵引、外部框架。我自己的理解很简单，Harness 就是模型外面的那套可靠运行系统。
如果 Prompt 是指令，Context 是信息，那 Harness 就是执行环境。它包括 Agent Loop、工具调用、权限控制、日志追踪、错误恢复、Guardrails、自动化测试、评估系统、版本管理、成本控制、部署发布、监控告警。
听起来很重，对吧。
但真实业务就是这么重。
一个典型的 Agent Loop，其实就三件事，收集上下文，采取行动，校验结果。结果不对，就把反馈放回去，让它修正。达到停止条件，就停。需要人判断，就把人叫进来。
听起来很朴素，但这里面全是工程细节。
比如工具调用失败了，要不要重试？重试几次？如果模型要调用删除类工具，要不要二次确认？如果输出是 JSON，怎么验证 schema？如果它改了代码，怎么跑测试？测试失败以后，是让它自己修，还是直接交给人？如果连续三次都修不好，要不要熔断？如果这次效果变差了，怎么知道是 Prompt 的锅，Context 的锅，还是模型版本变了？
这些问题都不性感。
但它们决定一个 Agent 是玩具，还是系统。
我有时候觉得，AI 应用从 Demo 到生产，最大的鸿沟不在「能不能生成答案」，而在「答案能不能被验证，行为能不能被追踪，错误能不能被恢复」。
这就是 Harness Engineering 的价值。
没有 Harness，模型像一个聪明但不可控的实习生。有了 Harness，它才慢慢变成一个能进流程、能留痕、能复盘、能迭代的工作单元。
4、很多 Agent 不稳定，不是模型不行，是三层缺了一层
当然，我不是说大家一上来就要搞一套巨复杂的平台。那也不现实。
尤其是很多个人项目、小团队项目，一开始连需求都还没跑明白，直接上全套观测、评估、权限系统，到头来很可能做成一个没人用的漂亮架子。
这话听着有点刺耳但，很多时候我们不是缺架构，我们是缺一个能真实跑起来的闭环。
所以更实用的做法，是按三层一点点补。
先把 Prompt 讲清楚，这次任务是什么，边界是什么，输出是什么，失败了怎么说。
然后把 Context 喂准，信息从哪里来，怎么筛，怎么去重，怎么压缩，怎么排序，哪些事实必须放在前面。
再把 Harness 接起来，动作怎么执行，权限怎么控，结果怎么验，错误怎么恢复，日志怎么留，评估怎么跑。
你会发现，很多问题并不需要更强的模型。
只要把这三层补齐，系统就会立刻稳很多。
举个特别简单的例子。你让 Agent 帮你处理一批客户反馈。
只写 Prompt，它可能会给你总结得挺漂亮。加上 Context，它能知道每个客户的历史订单、最近工单、产品版本、之前沟通过什么。再加上 Harness，它就可以把高置信度问题自动分类，把低置信度问题交给人工，把每次分类结果记录下来，定期评估准确率，发现某类问题总分错就回头改检索和 Prompt。
到这一步，它才开始像一个应用。
不是一个会聊天的窗口。
是一个有输入、有动作、有验证、有反馈的系统。
5、别迷信咒语，要搭系统
回到最开始那个问题，为什么很多人做 Agent 只盯着 Prompt？
因为 Prompt 最像魔法。你改一句话，模型立刻变了。这种反馈太爽了。
Context 和 Harness 就没那么爽，它们更像脏活累活，要处理文档、接口、日志、权限、评估、异常。
但偏偏这些脏活累活，才是 AI 应用真正能不能落地的地方。
Prompt 是咒语。
Context 是情报。
Harness 是作战系统。
只有咒语，没有情报和作战系统，最多打一个漂亮的演示。有了三层，才有机会把 Agent 放进真实世界里，让它面对真实世界那坨混乱的信息、权限、失败和反馈。
我自己的感受是，未来做 AI 产品的人，能力结构会越来越像半个产品经理、半个工程师、半个流程设计师。
要会写 Prompt，但不能迷信 Prompt。要懂上下文，但不能只会堆资料。要做 Harness，但不能为了工程而工程。
说到底，就是把模型当成一个强但不稳定的认知引擎，然后在它外面搭一套让它稳定工作的系统。
这件事儿我自己也还在摸索，可能有些想法还不成熟。
但我始终坚信一点。
真正的 AI 工程能力，不是写好一句 Prompt。
而是把 Prompt、Context、Harness 三层一起设计好。
Prompt 决定任务。
Context 决定知识。
Harness 决定可靠性。
这三个同心圆转起来，Agent 才不只是看起来聪明。
它才会开始变得真的有用。