Harness Engineering是什么？和提示词工程和上下文工程有什么关系？
AI AGENT#
1. LLM#
1.1 大模型的本质#
大模型本质上就是磁盘上的超大参数文件。
1.2 大模型服务是怎么来的#
把这个参数文件从磁盘加载到显卡内存里，再配上 API 接口，就形成了大模型 API 服务。
1.3 大模型的作用#
它的核心作用，是根据当前输入，预测下一个字词大概率是什么。
2. Harness Engineering（驾驭工程）#
Harness 的本质，就是为大模型写一个微型操作系统（OS）。 在这个 OS 里，大模型是 CPU，上下文窗口是极其珍贵的 RAM（内存），各种本地操作是外设（硬件）。Harness 不干涉 CPU 的计算，但它必须极其严苛地管理内存回收（上下文压缩）、调度硬件接口（极简工具集）、并随时准备触发系统中断（拦截高危操作与死循环）。
Harness Engineering 可以理解为：为了让 AI Agent 真正可用、可控、可执行，需要在 LLM 之外补齐的一整套工程能力。
2.1 四层能力#
（1）记忆层#
① 提示词工程
LLM 本质上是在根据你的输入预测下一个词。如果你的输入过于宽泛，它的输出就会很发散。
所以需要补充更多细节，让模型的预测更加精准。围绕“如何优化提示词，让结果更符合预期”所做的工作，就是提示词工程。
它主要解决的是：
大模型缺乏引导、容易乱说话的问题。
② 上下文工程
上下文，是发给大模型的提示词和相关资料的总和。
但大模型一次能处理的上下文数量是有限的，这就是上下文窗口。
因此，我们不得不压缩或丢弃部分信息。可一旦压缩或丢弃，就可能丢失关键信息，导致模型“忘掉”前面重要内容，这种现象就是上下文退化。
上下文工程，就是动态管理上下文的技术：
在合适的时候，把合适的内容送给大模型。
上下文工程的实现策略，可以概括为三个步骤：
一是召回。
先决定要找什么信息，这些信息可能来自外部新闻、聊天记录、当前代码环境、程序运行报错等。
这里通常会涉及 RAG、Memory 等技术。
二是压缩。
因为上下文窗口有限，所以需要对信息做压缩，让内容更短、更精炼。
例如，可以先把一部分信息发给大模型做总结，再把总结结果送入后续流程。
三是组装。
信息放置的位置和顺序，会直接影响模型的理解和输出。
所以需要按一定结构重新组织内容，让进入模型的上下文更精简、更相关。
不同 Agent 的上下文工程策略不同，所以即使接的是同一个大模型，不同 Agent 的执行效果也会不一样。
③ 规则文件
AI Agent 本质上是一个 for 循环：
执行层先执行任务，把执行结果通过上下文工程传给 LLM；
LLM 思考后，再驱动执行层继续执行；
执行结果又被送回 LLM；
如此循环往复。
但随着循环次数增多，上下文会不断膨胀，进而出现腐化问题。
随着喂给 LLM 的文件和信息越来越多，前面设定好的目标和约束会被逐渐冲淡，模型的理解就容易偏离。
为了解决这个问题，可以在每次给 LLM 的上下文中都加入一些可复用的核心信息，例如：
-
项目目标
-
技术栈
-
需求背景
-
代码风格
-
禁止事项
这样可以减少模型的理解偏差。
这些核心信息可以单独写成规则文件，例如 CLAUDE.md 之类的文件。
但规则文件写多了以后，本身也会变长。
所以还需要继续拆分，把大的规则文件拆成多个，再通过路由机制，在不同场景下调用不同的规则文件。
（2）执行层#
只有 LLM 加上下文工程，本质上还只是“会聊天”。
要让 AI Agent 真正执行任务，还需要补充执行能力，例如：
-
Bash 沙箱
-
文件系统
-
MCP
-
外部工具调用
-
代码文件读写
-
命令执行
这些能力共同构成了执行层。
（3）反馈层#
AI Agent 本质上还是一个 for 循环。
执行结果会被加入上下文，再反馈给 LLM；
LLM 会根据这些执行结果、报错信息、校验结果，继续修复问题。
这种“检查执行结果 → 回传错误 → 自动修复”的能力，就是反馈层。
（4）编排层#
如果 Agent 只是循环执行，而没有全局规划和清晰的结束目标，那它仍然很容易跑偏，甚至陷入死循环。
因此，需要把大任务拆解成多个目标明确的小任务，按照规划驱动 Agent 分步执行。
这种以全局规划为核心，对任务进行拆解和全过程管控的能力，就是编排层。
2.2 如何落地#
SDD（Spec-Driven Development）#
以 Claude Code 为例，这类软件本身已经原生支持 Harness Engineering 的四层能力。
一种比较轻量的做法，是在 CLAUDE.md 里写清楚：
-
项目背景
-
需要做什么
-
不能做什么
-
做完后要跑哪些 lint
-
要执行哪些单测
-
要使用哪些 skill
借助插件 spec-kit#
还可以借助 spec-kit 这样的插件，逐步推进开发流程：
-
生成约束
-
明确需求
-
定制计划
-
拆解任务
-
开始实现
3. 一句话总结#
AI Agent 不是单纯把 LLM 接出来就够了，而是要通过 Harness Engineering，把记忆、执行、反馈、编排这些工程能力补齐，最终让模型从“会聊天”变成“能做事”。
传统 framework 和 harness#
Harness 的三大转变：
- 控制反转（IoC）： 业务流程的控制权从“Go/Python 代码”完全转移到了“大模型的实时推理和规划”中。代码只提供物理定律（如文件读写和编辑、沙箱执行等），不干涉任务走向
- 防线前移： 既然大模型是自由的，它就可能犯错或搞破坏。因此 Harness 的核心代码全部集中在了 Middleware（防止搞破坏）和 Compactor（防止内存被撑爆）上
- 状态透明： 循环只依赖一个单一的数据结构——也就是不断累加的 Context 消息列表。没有任何隐式的树节点或图节点变量
采用何种类似 OS 的策略来避免 API 报错而彻底崩溃失忆的问题？#
在经典的计算机操作系统中，当内存（RAM）不足时，系统会触发 OOM（Out Of Memory）Killer 强杀进程，或者将不常用的内存页置换到磁盘上（Swap）。
结合 Harness 理念，如果大模型的上下文窗口（Context Window）逼近了极限限制（比如 128k Tokens），你认为在我们的 go-tiny-claw 引擎中，应该采取哪些类似 OS 的策略，来避免整个 Agent 因为 API 报错而彻底崩溃失忆？
和操作系统的共通之处是如何在资源有限的情况下持续运行——操作系统的 CPU、内存、IO 等都是稀缺资源，而且各种应用进程可能报错；
相应的，Agent Runtime 会面临 Context Window 有限、token 成本有限、工具集可能输出爆炸的问题——把有限资源分配给最重要的任务，尽可能保证核心稳定让系统具备恢复能力，于是可以：
1、类似程序计数器一样记录当前执行状态，结构化保存可追溯可恢复不受模型调用影响；
2、类似分级缓存一样设计 token 使用阶梯，提前约束资源使用量减少频繁超额请求；
3、类似分层存储一样设计数据索引，热数据放 prompt、原始日志放 memory、按需调用