最近跟不少朋友聊 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 才不只是看起来聪明——它才会开始变得真的有用。
