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 才不会只是看上去聪明。

到那时，它才会真正变得有用。