之前做过一些AI应用的项目。踩过一些坑。最近整理了一些想法。贴出来跟大家交流一下。
过去几年，AI 应用工程的关注重点发生了一次非常清晰的迁移。早期开发者最关心的是，怎样写 prompt，才能让模型更稳定地理解指令、输出正确格式、减少跑题和幻觉。随后，随着长上下文、检索增强、工具调用和多轮状态管理逐渐成熟，问题转向了另一个方向：怎样为模型提供它在当前任务中真正需要的信息。再往前一步，当模型开始具备跨步骤执行复杂任务的能力，一个更深层的挑战浮现出来：即使模型已经理解任务，也拿到了足够的信息，怎样才能让它持续、可靠、可验证地把工作做完。
如果把这三个阶段放在一起看，就会发现它们并不是零散技巧的更替，而是 AI 应用工程的三层递进问题。第一层是 Prompt Engineering，解决的是如何表达意图；第二层是 Context Engineering，解决的是如何供给信息；第三层是 Harness Engineering，解决的是如何约束行为、验证结果并维持系统可靠性。它们共同构成了 AI Agent 从“能回答”走向“能工作”的一条演化路径。
Prompt关心的是接口，Context关心的是认知环境，Harness关心的是系统约束。理解这三层之间的关系，不仅能帮助我们解释行业讨论为何会从“提示词”转向“上下文”，再进一步转向“agent harness”，也能帮助团队在实践中更准确地判断：一个问题究竟应该在 prompt 层解决，在 context 层解决，还是必须上升到 harness 层解决。
Prompt Engineering 是最早出现、也最容易被大家感知的一层。原因很简单：在大模型开放 API 的早期，开发者最直接、往往也是唯一能控制的变量，就是输入给模型的那段文本。无论是最初的文本补全接口，还是后来的对话式界面，开发者首先面对的问题都是“怎么说，模型才更容易照着做”。因此，Prompt Engineering 的兴起并不神秘，它几乎是由交互形态本身决定的。模型能力尚不稳定时，表达方式自然成为第一控制杠杆。
Prompt 的作用，就是在人类意图与模型生成行为之间建立一个尽可能清晰、低歧义、可重复的接口。角色设定、示例提供、格式约束、分步指令，这些常见技术本质上都在做同一件事：让模型更准确地映射人的意图。但 Prompt Engineering 的边界也始终存在。它擅长解决的是“怎么表达”带来的偏差，却无法凭空补齐模型没有看到的信息，更无法独立解决跨轮次记忆、多工具协作、长任务验证和系统级恢复这些问题。当任务复杂度提升到一定程度，仅靠 prompt 写得更好，往往已经不够。
这正是 Context Engineering 兴起的背景。随着模型的上下文窗口扩大、工具调用能力增强、RAG 和各类记忆机制逐渐成熟，开发者开始越来越明显地感受到：很多失败并不是因为 prompt 写得不够好，而是因为模型没有在当下看到正确的信息。它可能不知道最新政策，不了解企业内部知识，不记得前几轮对话已经确认的决定，也可能虽然拿到了信息，却因为注入方式混乱而无法有效使用。到了这个阶段，问题的重心就从“如何提问”转向了“模型该看到什么”。
Context Engineering 的核心，不是简单地往上下文里塞更多内容，而是系统性地设计模型的认知环境。检索哪些材料、保留哪些历史、怎样压缩长文档、如何组织工具描述、哪些状态需要长期持久化、哪些信息应该在当前轮动态注入，这些都属于 Context Engineering 的范畴。它解决的是信息供给问题：在上下文窗口有限的前提下，如何在正确的时刻把正确的信息放进模型可见范围内。
这一层之所以重要，是因为大模型的很多“不会”，本质上不是能力缺失，而是信息缺席。模型在很多任务中并非不具备推理能力，而是推理所依赖的事实、状态和材料没有被正确供给。随着 AI 应用从聊天问答走向文档助手、代码代理、企业知识系统和工具增强型 agent，Context Engineering 逐渐从辅助环节变成主导环节，也就不难理解了。
但即便如此，一个拿到了正确信息的agent，仍可能在长任务中偏离目标，可能在没有验证结果的情况下过早宣布完成，可能持续复制代码库中的坏模式，可能在多次操作中悄悄积累错误，最终把本来局部可控的问题放大成系统性风险。到了这里，问题已经不再是信息供给，而是行为约束和系统可靠性。
Harness Engineering 之所以成为新的焦点，正是因为 agent 的失败模式已经超出了 prompt 和 context 两层能够单独解决的范围。Harness 所指向的，不是更多提示词，也不是更大的上下文，而是一整套包裹模型工作的外部系统：项目规则、状态文件、架构约束、自动化测试、静态检查、任务分解、反馈回路、回滚机制、子智能体编排，以及让错误能被发现、被反馈、被修正的全部工程设施。
如果说 Prompt 是告诉模型你要什么，Context 是让模型看到完成任务所需的信息，那么 Harness 做的就是让模型在真实系统里以可接受的方式把事情做成。它不是替代前两者，而是在前两者之上增加了一层对行为的调控。这个变化之所以关键，是因为一旦模型开始长时间自主工作，“回答对一个问题”就不再是核心标准，“能否持续在边界内完成一项任务”才是。
这也是为什么越来越多关于 agent 的高价值讨论，不再把注意力集中在单次输出质量，而是开始关注智能体的工作环境。没有测试的 agent 会自信地交付未验证结果，没有状态管理的 agent 会在跨会话中失忆，没有结构约束的 agent 会在代码库里不断扩散局部最优，没有反馈回路的 agent 即使犯了同一种错也会反复重演。换句话说，agent 的问题越来越像软件工程问题，而不再只是模型调用问题。
1 个帖子 - 1 位参与者