AI知识普及，一文深入了解Prompt、Context、Harness、Loop（上篇）

AI agent领域最近出了很多新词包括之前的词有prompt, context, harness, loop,codex, hermes, claude code等等; 于是有几个问题

1. 它们是什么,可以相互替代吗?
2. 我直接用loop engineering不就好了吗，真的是这样吗?
3. 基座llm模型能力越来越强，我只选择最强的模型，是不是就不用管其他？
4. AI发展越来越迅猛，我很焦虑，该怎么才能获取核心竞争力？ 首先我们来看整个时间线;

内容比较多，我决定分2篇文章来给大家详细介绍；本文主要讲prompt, context, harness这块的内容。希望可以对大家有所帮助~

目录

• Prompt Engineering
• 提示词工程的优势
• 提示词工程的劣势
• Context Engineering
• 核心痛点：上下文资源的天然约束
• 上下文工程核心设计原则
• Context engineering的优势
• Context engineering的劣势
• Harness Engineering
• 什么是harness?
• 生产级harness agent包含组件
• harness设计的要素
• harness和context的关系
• harness学习资料
• 参考链接

Prompt Engineering

Prompt engineering又称提示词工程，通过设计、调试、优化输入给大语言模型（LLM）的文本指令（称为提示词 / Prompt），引导LLM精准理解需求、输出稳定、合规、符合预期的结果; 在同等的信息内容，换不同的说法，让大模型回复的结果更好。通常指那种面向单次、静态、独立任务，核心是优化指令文本写法，仅聚焦系统提示词，属于一次性静态配置。提示词通常包含下面几个组成：

提示词工程的优势

1. 输出格式可控。
2. 推理质量提升。
3. 角色边界清晰。

提示词工程的劣势

1. 信息孤岛: 只擅长单轮通用知识和逻辑强的问题; 没法解答实时性和交互类的问题，无法解决”模型不知道你的业务数据”的问题；例如今天天气怎么样，最近热点实时新闻都
2. 无记忆： 每轮对话对应几乎是独立的。没法沉淀对话中的记忆也没法复用；
3. 依赖人触发和人判断: 需要人不断地调整验证提示词

Context Engineering

随着时间的发展来到了25年6月; 此时llm的基座能力得到巨大提升;越来越多的研究者发现，要想让llm理解需要给它提供对应业务场景的上下文，单纯的提示词工程是远远不够的。

karpathy在6月25号在X平台上

没过多久，25年9月29号，Anthropic 发布了《effective-context-engineering-for-ai-agents》这篇工程博客，给出了正式定义：

Context engineering 是筛选和维护最优 token 集（信息）的策略集，包括 prompt 之外落入 context 的所有其他信息。从这里可以看出

1. context engineering 是包含prompt engineering；
2. 提示词工程: 面向单次、静态、独立任务，核心是优化指令文本写法，仅聚焦系统提示词，属于一次性静态配置
3. 上下文工程：覆盖推理全流程所有送入模型的 Token，包含系统提示、工具定义、外部检索数据、对话历史、少量示例、运行时动态加载信息，是迭代式、动态持续管理全上下文状态的完整体系。
4. 同时整个agent设计范式已经转变：开发目标从 “写一段完美提示词” 变为“在有限注意力预算内，构建最优上下文信息组合，稳定驱动智能体输出预期行为”。

核心痛点：上下文资源的天然约束

从底层原理来看Transformer 架构存在天然注意力约束：n 个 Token 会产生 n² 注意力关联，上下文越长，模型对远端信息的召回、长距离推理精度持续下滑；模型训练数据以短序列为主，长文本依赖能力薄弱。 上下文是稀缺有限资源，冗余信息会消耗注意力预算，造成 AI 健忘、逻辑断裂，因此必须精细化筛选高价值 Token。里面包含各类关于harness资料，其中从最基础的技术博客、Context, Memory & Working State、Constraints, Guardrails & Safe Autonomy 涉及agent的都有对应的介绍;

1. 上下文窗口容量有限：所有 LLM 单次推理可读取 Token 存在上限(从原理的32k->128K->512k->1M)，任务越长、调用工具越多，信息越容易溢出。
2. 上下文衰减（注意力稀释) context rot：上下文 Token 总量越大，模型远距离检索、关联早期信息的精度持续下降，并非彻底失效，而是推理准确率逐步下滑。
3. 智能体场景信息爆炸：Agent 多轮交互、工具调用、跨天长期任务、多源数据融合，持续产生海量冗余信息，无法全部塞进上下文窗口。

上下文工程核心设计原则

总纲领：最小化高信号 Token 集合，只保留对当前步骤决策有决定性作用的信息，剔除噪声，最大化 Token 利用效率。

1. 结构化分层排布上下文：固定顺序->系统指令->长期记忆摘要->工具定义->本轮工具输出->近期对话历史；用 Markdown/XML 标签分区，降低模型信息检索成本。
2. 系统提示轻量化迭代：先极简基线提示，根据实际运行报错补充约束，不提前堆砌冗余规则；少量高质量示例远优于长篇边界规则罗列。
3. 信息分层存储：区分即时上下文（窗口内） 和外部长期记忆（窗口外），不把全部历史塞进上下文。
4. 优先结构化数据：任务状态、工具返回结果用 JSON 等紧凑格式存储，减少无意义自然语言占用 Token。

Context engineering的优势

• 实现通用 AI 向企业专属业务智能体转型 该方案可打通企业知识库、内部业务系统数据链路，让智能体不再输出泛化通用答案，所有回复、建议均依托企业自有业务数据生成、有据可依，是企业 AI 智能体落地、产生实际业务价值的核心基础。
• 提升Token使用效率，显著降低AI调用成本 LLM 服务商普遍按照 Token 消耗量计费，上下文工程遵循最小高信噪比 Token 集合核心原则，精简无效冗余信息。
• 保障单会话多轮对话逻辑连贯，解决长交互遗忘问题 通过标准化对话历史上下文管理机制，智能体可完整留存会话全流程信息，在十几轮长对话中持续记忆前期沟通内容、关键决策结论，避免出现前后信息割裂、遗忘历史共识的问题。

Context engineering的劣势

• 仅管控模型输入，无法约束模型输出行为 上下文工程仅负责筛选、送入模型所需信息，只能保证模型获取完整、准确的业务素材；即便输入信息无偏差，模型仍可能产生错误判断、执行偏离预期的动作，该环节缺陷无法通过上下文优化解决。
• 缺少 LLM 调用错误自检测、自修正机制 多轮交互过程中，智能体若在中间轮次产生逻辑、操作类错误，系统无法自动识别并修正；后续遇到同类业务场景时，相同失误会重复出现，容错能力较弱。
• 无法脱离人工独立完成全流程闭环 上下文优化仅提升单次任务的回答精准度，但任务发起、需求定义、输出结果合规性与可用性判定，均依赖人工操作与审核。智能体本质是高算力专业工具，全程需要人工主导、监督使用。

当你的 Agent 反复犯同样的错，而你只能通过改 prompt 或调 RAG 来”希望”它不再犯时——你就需要harness engineeing了;

Harness Engineering

在聊什么是harness engineeing前，先给大家看几篇真实的案例;

什么是harness?

26年1月初，langchain团队他们的 coding agent 在 TerminalBench 2.0 基准测试上，从 52.8% 跳到了 66.5%，排名从前 30 开外进入了全球前 5。

2026 年 2 月 5 日，Mitchell Hashimoto 发布了一篇博客，描述了一个他在使用 AI agent 时养成的习惯：每次 agent 犯错，他都会工程化一个解决方案，让 agent 再也不会犯同样的错。 他把这个实践叫做 “engineer the harness”。

2026年2月11号，OpenAI 发布了《Harness Engineering: Leveraging Codex in an Agent-First World》，描述了一个 3-7 人小团队如何在五个月内，用 Codex agent 构建了约一百万行代码——零行手写代码。核心发现是不是模型能力不行，是环境没配好。

2026年3月10号, LangChain 用一个公式做了最简洁的凝练harness和agent的关系：Agent = Model + Harness;

2026年3月28号，MIT研究院发现 在同一个 benchmark 上，仅仅改变 harness，性能差距可以达到 6 倍。

2026年7月1日，huggingface的研究员《Don’t Train the Model,Evolve the Harness》实验数据给出了极其震撼的答案。同一个 DeepSeek-V4-Pro、同一批任务、同一个评测器，仅仅因为换了五种不同的外层执行机制，pooled score（综合得分）竟然在 3.5% 到 80.1% 之间剧烈波动：

从上面的真实案例可以看出， 决定 Agent 整体能力上限的除了LLM本身能力外，适配llm的对应的工程是至关重要的; 可以看出，整个agent设计范式已经转变：从之前的 “模型看到什么” 变成了 “如何构建一个让错误结构性不可重犯的执行环境？”

生产级harness agent包含组件

这里介绍一下x平台akshay_pachaar博主分享《The Anatomy of an Agent Harness》关于harness拆解; 关于agent应用，有博主跟电脑操作系统进行类比,如下;

• 一个原始的 LLM 就像一个没有 RAM、没有磁盘和没有 I/O 的 CPU。
• 上下文窗口充当 RAM（快速但有限）。
• 外部数据库充当磁盘存储（容量大但速度慢）。
• 工具集成充当设备驱动程序。
• harness是操作系统。

通过综合 Anthropic、OpenAI、LangChain 以及更广泛的从业者社区，一个生产级的harness 应该十二个不同的组成部分。

• 协调循环:它实现了思维->行动->观察（TAO）循环，也称为 ReAct 循环。循环运行：组装提示->调用 LLM->解析输出->执行任何工具调用，将结果反馈，重复直到完成。 它通常只是一个 while 循环。复杂性存在于循环管理的一切事物中，而不是循环本身。
• tool: 工具是agent的手; 它们被定义为注入到 LLM 上下文中的模式（名称、描述、参数类型），以便模型知道有哪些可用。例如Claude Code 提供了跨越六个类别的工具：文件操作、搜索、执行、网络访问、代码智能和子代理生成。
• memory: agent的记忆需要有多个时间尺度; 短期记忆是单个会话内的对话历史;长期记忆会话持久存储：Anthropic 使用 CLAUDE.md 项目文件和自动生成的 MEMORY.md 文件；LangGraph 使用命名空间组织的 JSON 存储；OpenAI 支持由 SQLite 或 Redis 支持的会话。
• 上下文管理: 正如前面context engineering中提到，llm上下文窗口会有上下文衰减效应。 有当关键内容位于窗口中间位置时，模型性能会下降 30%以上（Chroma 研究的结果，斯坦福大学的“Lost in the Middle”研究也证实了这一点）。即使是在包含百万个令牌的窗口中，随着上下文的增多，模型的性能也会下降。常见对应如下:

• 提示词构建:提示词构建要进行分层组装;系统提示、工具定义、内存文件、对话历史和当前用户消息。 可以参考 claude code的提示词方式利用好prompt caching,提供agent应用的ttft指标和降低token消耗成本;

• 输出解析: 现代的 harness 依赖于本地工具调用，其中模型返回结构化的 tool_calls 对象，而不是自由文本;harness 需要检查：是否有工具调用？执行它们并循环。没有工具调用？那就是最终答案。
• 状态管理:LangGraph 模型将状态视为通过图节点流动的带类型的字典，使用 reducer 合并更新。检查点在超级步骤边界发生，支持中断后的恢复和时间旅行调试。OpenAI 提供四种互斥策略：应用内存、SDK 会话、服务器端 Conversations API 或轻量级 previous_response_id 链接。Claude Code 采取不同方法：git 提交作为检查点，进度文件作为结构化草稿板。

• 错误处理: 一个包含 10 个步骤且每步成功率高达 99%的流程，其端到端成功率仍然只有~90.4%。错误会迅速累积。 需要对agent各种错误进行处理;
• 安全防护和护栏:
• OpenAI 的 SDK 实现了三个级别：输入护栏（在第一个代理上运行）、输出护栏（在最终输出上运行）和工具护栏（在每次工具调用上运行）。一个“绊线”机制在触发时立即停止代理。
• Claude Code Gates ~40 提供了独立的工具功能，这些功能分为三个阶段：在项目加载时建立信任机制，在每次调用工具之前进行权限检查，以及对于高风险操作进行明确的用户确认。
• 验证循环:Claude Code 的创作者 Boris Cherny 指出，为该模型提供一种验证其工作成果的方法，可以使其质量提升 2 到 3 倍。Anthropic 推荐三种方法：基于规则的反馈机制（如测试、 lint 检查、类型检查器等）、视觉反馈（通过 Playwright 生成 UI 界面的截图），以及以LLM-as-judge(大语言模型作为裁判)的方式（由一个独立的子代理来评估输出结果）。
• 子代理编排:Claude 代码支持三种执行模型：Fork（与父上下文具有相同的字节码副本）、Teammate（独立的终端窗口，通过基于文件的邮箱进行通信）以及 Worktree（独立的 Git 工作树，每个代理都有一个独立的分支）。OpenAI 的 SDK 支持将代理作为工具使用（专家处理有限的子任务），以及任务移交功能（专家可以完全控制任务的执行）。LangGraph 则将子代理实现为嵌套的状态图结构。

harness设计的要素

1. 单一智能体 vs. 多智能体。无论是 Anthropic 还是 OpenAI 都表示：首先应最大化单一智能体的性能。多智能体系统会增加额外的开销（例如需要多次调用大型语言模型来处理路由问题，以及在智能体切换时产生上下文丢失的情况）。
2. ReAct vs. plan-and-execute:ReAct在每一步都实现了推理与行动的结合（虽然灵活性较高，但每步的成本却更高）;据 LLMCompiler 的测试结果显示，使用  plan-and-execute 模式的速度比采用顺序ReAct快 3.6 倍。 3.** 上下文窗口管理策略**：五种生产方法：基于时间的清理机制、对话摘要生成、观察数据掩蔽、结构化笔记记录，以及子代理委托。ACON 研究表明，通过优先处理推理结果而非原始工具输出，可以在保持 95%以上的准确性的同时，减少 26%到 54%的令牌消耗。
3. 验证循环的设计：计算验证（测试、 lint 检查）能够提供确定的真实结果。推理验证（使用 LLM-as-judge 作为判断依据）可以捕捉语义上的问题，但会引入一定的延迟。Martin Fowler 的 Thoughtworks 团队将这种验证方式分为两类：引导式验证（在前端进行预判断）和传感器式验证（在行动后进行反馈）。
4. 权限与安全性架构:一种是允许性模式（操作快速但存在风险，大多数操作均可自动批准）；另一种是限制性模式（安全性较高但操作速度较慢，每个操作都需要获得批准）。
5. 工具选择策略: 使用更多的工具往往会导致性能下降。Vercel 在版本 0 中删除了 80%的工具，从而获得了更好的性能。Claude Code 通过延迟加载技术实现了 95%的上下文简化。其原理是：只提供当前步骤所需的最少数量工具即可。

Harness thickness: harness封装的厚度，harness装置中包含了多少逻辑内容，而模型本身又包含了多少逻辑呢？人们倾向于使用较薄的控制装置，并期望模型能够有所改进,同时也好方便迁移。基于图的结构框架则强调对控制的精确控制。

harness和context的关系

1. 可以看harness engineering是包含context engineering; context engineering 是包含提示词工程;
2.  Context Engineering：给模型看正确的信息，期望它做出正确的行为。 这是一种基于信任的策略——你信任模型在看到正确信息后会做正确的事。
3. Harness Engineering：不管模型看到了什么，在它的输出被应用到真实环境之前，必须通过外部检查。 这是一种基于验证的策略——你不信任模型的任何单次输出，你信任的是验证流程。

来自x平台akshay_pachaar: https://x.com/akshay_pachaar/status/2044763357300027842/photo/1

harness学习资料

给大家安利github上面一个开源项目awesome-harness-engineering, 目前stars已有3.6k;

这里面收藏的技术博客都是openai、Anthropic、langchain等等的顶尖机构在对对应技术的详细介绍,非常值得深入阅读，而且还是一手资料， 读完这些技术博客文章，你就知道agent的来时路，知其然知其所以然，有想深入了解的朋友，可以仔细去阅读;

• https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering
• https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• https://mitchellh.com/writing/my-ai-adoption-journey
• https://openai.com/zh-Hans-CN/index/harness-engineering/
• https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
• https://arxiv.org/html/2603.28052v1
• https://huggingface.co/spaces/joelniklaus/harness-optimization#introduction
• https://x.com/sairahul1/article/2063544956158185927
• https://github.com/walkinglabs/awesome-harness-engineering
• https://x.com/sairahul1/article/2063544956158185927
• The Anatomy of an Agent Harness: https://x.com/akshay_pachaar/status/2041146899319971922