很多人谈到 AI Recursive Self-Improvement，第一反应可能是：

AI 是不是要自己训练自己？
模型参数是不是会自动更新？
是不是只要 LLM 越来越大，AI 就会越来越聪明？
是不是未来所有智能都来自更强的模型？

这些问题当然重要。

但从当前 AI Application 的实际落地来看，真正让系统变得更稳定、更可复用、更接近“自我改进”的，往往不是直接修改模型参数，而是模型外部的工程系统。

这个系统，可以称为 Harness Engineering。

简单来说，Harness Engineering 就是把 LLM、Tools、Context、Memory、Workflow、Evaluation 和 Feedback 组织起来，让 AI 不只是“回答问题”，而是能够持续完成任务、记录过程、复用经验、减少错误。

也就是说，AI 的进化不一定只发生在模型内部，也可能先发生在系统外部。

什么是 AI Recursive Self-Improvement？

AI Recursive Self-Improvement 可以理解为“AI 递归自我改进”。

听起来很复杂，但可以简单理解为：

一个 AI 系统在完成任务的过程中，能够总结经验、发现错误、优化流程，并把这些经验用于下一次任务。

这里的重点不是“AI 立刻修改自己的模型参数”，而是系统能不能形成持续改进的闭环。

比如：

第一次执行任务时，系统记录完整过程。
第二次遇到类似任务时，系统调用历史经验。
第三次执行时，系统复用更好的流程。
失败之后，系统能分析哪里出错。
成功之后，系统能把经验沉淀下来。

这就是一种更现实、更工程化的 Self-Improvement。

什么是 LLM？

LLM 是 Large Language Model 的缩写，也就是“大语言模型”。

ChatGPT、Claude、Gemini 这类模型都可以理解为 LLM。

LLM 的能力很强，可以写代码、总结文章、分析问题、生成方案，也可以完成很多复杂的语言任务。

但在真实应用中，只靠 LLM 本身还不够。

因为真实任务往往不是简单问答，而是需要持续处理信息、调用工具、保存经验、检查结果和调整流程。

为什么只靠 LLM 还不够？

一个 LLM 可以很聪明，但一个 AI System 不一定稳定。

这里的 AI System 指的是完整的 AI 应用系统，而不只是一个模型。

比如一个 AI Agent 要帮用户完成一份研究报告，它可能需要：

理解用户需求；
查找资料；
筛选可靠信息；
整理结构；
生成内容；
检查逻辑；
修正错误；
输出最终文档。

这不是一次简单对话就能完成的。

它需要 Context Management、Tool Calling、Memory System、Workflow Orchestration、Evaluation 和 Feedback Loop。

这些能力都属于 Harness Engineering 的范围。

所以，真正的问题不是“模型会不会回答”，而是：

系统能不能稳定完成任务？
系统能不能记住之前发生过什么？
系统能不能复用成功经验？
系统能不能避免重复犯错？
系统能不能知道什么时候该调用工具？
系统能不能让开发者看到完整执行过程？

这些问题本质上是 System Engineering 的问题。

Harness Engineering 到底是什么？

Harness 可以理解为“把大模型能力组织起来的工程外壳”。

如果说 LLM 是“大脑”，那么 Harness 就像是这个大脑的工作台、工具箱、记忆本、任务流程和反馈机制。

没有 Harness，LLM 每次调用都像是从零开始。

有了 Harness，AI System 才能记录过去的经验，复用有效流程，分析失败原因，并逐渐变得更稳定。

Harness Engineering 通常包括几个核心部分。

Context Management：管理模型看到的信息

Context 是“上下文”，也就是模型当前能看到的信息。

比如用户需求、历史对话、文件内容、任务目标、约束条件、工具返回结果，都属于 Context。

Context 不是越多越好。

如果信息太乱，模型可能抓不住重点；
如果信息太少，模型可能缺少判断依据；
如果信息顺序不合理，模型可能误解任务目标。

所以 Context Management 就是管理模型看到的信息。

它要决定：

哪些信息要保留；
哪些信息要压缩；
哪些信息要放在前面；
哪些历史内容需要重新调用；
哪些无关信息应该丢弃。

对 AI Agent 来说，Context Management 非常关键。

因为模型的输出质量，很大程度上取决于它当前看到的 Context 是否清晰。

Tool Calling：让 AI 正确使用工具

Tool Calling 是“工具调用”。

它指的是让 AI 调用外部工具来完成任务。

比如：

使用 Search 查资料；
使用 Code Interpreter 运行代码；
使用 Database 查询数据；
使用 File System 读取文件；
使用 Browser 浏览网页；
使用 API 调用外部服务。

这里的 API 可以简单理解为“程序之间互相调用功能的接口”。

但 Tool Calling 的难点不是“有没有工具”，而是：

什么时候该用工具？
该用哪个工具？
工具返回的结果是否可靠？
工具失败了怎么办？
工具结果应该怎么放回 Context？

如果这些问题处理不好，AI Agent 就容易出现混乱。

比如该搜索的时候不搜索，该验证的时候不验证，工具返回错误结果时还继续往下做。

所以 Harness 需要管理 Tool Calling，而不是简单地把工具接口交给模型。

Memory System：让 AI 不再每次从零开始

Memory System 是“记忆系统”。

它的作用是让 AI System 保存对未来有价值的信息。

比如：

用户偏好；
项目背景；
历史任务；
失败案例；
成功经验；
常用模板；
执行轨迹。

如果没有 Memory System，AI 每次都像第一次见到用户。

用户需要重复解释背景，系统也无法复用之前的经验。

但如果有了 Memory System，系统就可以在后续任务中调用历史信息，提高连续性和效率。

当然，Memory System 不是简单地“什么都记住”。

真正重要的是记住有价值的信息，并且在合适的时候调用出来。

Workflow Orchestration：把复杂任务拆成稳定流程

Workflow 是“工作流”，也就是完成任务的步骤。

Orchestration 是“编排”，也就是把不同步骤、工具和模块组织起来。

很多复杂任务不是一步完成的。

比如写一篇技术文章，可能需要：

确定主题；
收集资料；
搭建结构；
解释概念；
补充例子；
检查逻辑；
优化表达；
生成最终版本。

如果没有 Workflow Orchestration，AI 可能会想到哪写到哪，缺少稳定流程。

而 Harness 可以把任务拆成多个阶段，让系统按更可靠的方式推进。

这也是 AI Agent 从 Demo 走向真实应用时必须解决的问题。

Evaluation：让系统知道结果好不好

Evaluation 是“评估”。

它的作用是判断 AI 的输出是否符合要求。

比如：

答案是否准确；
代码是否能运行；
文章逻辑是否清晰；
引用是否可靠；
格式是否符合要求；
结果是否满足用户目标。

如果没有 Evaluation，系统就不知道自己做得好不好。

很多 AI 应用的问题就在这里：它们能生成结果，但不会检查结果。

一个真正可靠的 AI System，不能只会输出，还要能评估输出。

Feedback Loop：让系统把经验用于下一次

Feedback Loop 是“反馈闭环”。

它指的是系统把评估结果、错误信息、用户反馈重新传回流程中，用来改进下一次执行。

比如：

如果某次工具调用失败，系统下次可以避免同样的调用方式；
如果某种写作结构效果好，系统下次可以复用；
如果用户指出某个结果不准确，系统可以把原因记录下来；
如果某个 Workflow 更稳定，系统可以优先采用。

这就是 Harness Engineering 中非常重要的一环。

没有 Feedback Loop，AI System 只是一次次重复执行。

有了 Feedback Loop，系统才可能持续积累经验。

Trajectory：为什么执行过程比最终答案更重要？

Trajectory 可以理解为“执行轨迹”。

它记录 AI 完成任务的全过程，而不只是最终答案。

比如：

模型看到了哪些 Context；
调用了哪些 Tools；
每一步做了什么判断；
中间出现了哪些错误；
错误是如何修正的；
最终结果是怎么得到的。

为什么 Trajectory 重要？

因为只看最终答案，很难知道 AI 到底是怎么成功或失败的。

如果一个 Agent 输出错了，我们需要知道它错在：

Context 没组织好？
Tool 选错了？
工具结果理解错了？
Workflow 顺序错了？
Evaluation 没做好？

这些都需要通过 Trajectory 来分析。

所以，对于 AI Agent 来说，Trajectory 不只是日志，而是系统改进的重要资产。

Prompt Engineering 重要，但不够

Prompt Engineering 是“提示词工程”。

它指的是通过设计更好的输入指令，让模型输出更好的结果。

Prompt 很重要，但它不是全部。

如果系统没有 Harness，只靠 Prompt 很难解决长期稳定性问题。

因为真实任务会遇到很多复杂情况：

Context 会越来越长；
Tools 会越来越多；
任务状态会不断变化；
失败案例需要被记录；
历史经验需要被复用；
执行过程需要被调试；
结果需要被评估。

这些问题不是单靠一个 Prompt 就能彻底解决的。

真正可用的 AI Agent，通常不是：

LLM + Prompt

而是：

LLM + Context + Tools + Memory + Workflow + Evaluation + Feedback Loop

这才是 Harness Engineering 的核心价值。

RAG、Agent 和 Harness 的关系

很多人可能听过 RAG 和 AI Agent。

RAG 是 Retrieval-Augmented Generation 的缩写，可以理解为“检索增强生成”。

简单来说，RAG 就是先从外部知识库里找相关资料，再让 LLM 基于这些资料生成答案。

比如让 AI 回答企业内部制度问题时，它不能只靠模型记忆，而是应该先检索公司文档，再基于文档回答。

AI Agent 可以理解为“能自主完成任务的 AI 系统”。

它不只是回答问题，还可以规划步骤、调用工具、执行操作、检查结果。

而 Harness Engineering 更像是把这些能力组织起来的系统工程。

RAG 可以是 Harness 的一部分。
Tool Calling 可以是 Harness 的一部分。
Memory System 可以是 Harness 的一部分。
Workflow Orchestration 也可以是 Harness 的一部分。

Harness 的重点不是某一个单独技术，而是如何把这些技术组合成一个稳定可用的 AI System。

为什么 Harness Engineering 会越来越重要？

随着 LLM 能力越来越强，AI 应用正在从简单问答走向复杂任务。

过去，我们更关注模型能不能回答一个问题。

现在，我们更关注系统能不能完成一个任务。

未来，我们可能更关注系统能不能长期稳定地完成一类任务，并不断积累经验。

这就需要 Harness Engineering。

因为真实世界的任务通常具有这些特点：

步骤多；
信息多；
工具多；
错误多；
约束多；
需要反复修改；
需要持续复用经验。

这些都不是单个模型调用能完全解决的。

模型能力是基础，但系统工程决定了它能不能真正落地。

AI 的进化，可能先发生在 System Layer

System Layer 可以理解为“系统层”。

它指的是模型外部的工程结构，包括 Context、Tools、Memory、Workflow、Evaluation 和 Feedback。

当前大多数 AI Application 并不会在每次运行后更新 Model Parameters。

Model Parameters 可以理解为模型内部学到的知识和能力。
如果要改变 Model Parameters，通常需要训练或微调，成本比较高，也不适合每次任务都做。

但 System Layer 可以更灵活地改进。

比如：

优化 Context 组织方式；
增加新的工具；
改进 Workflow；
加入 Evaluation；
保存成功经验；
记录失败原因；
调整 Feedback Loop。

这些改进虽然没有直接改变模型参数，但会显著提升 AI System 的表现。

所以，从应用角度看，AI Recursive Self-Improvement 的起点，可能不是 Model Parameter Update，而是 Harness Engineering。

最后想说

AI 的下一阶段，不只是模型越来越大。

更关键的是，我们能不能构建一个让 LLM 持续积累经验、复用 Workflow、管理 Context、调用 Tools、记录 Trajectory、接受 Evaluation 和 Feedback 的系统。

真正稳定的 AI Agent，不应该只是一个会回答问题的模型，而应该是一个可观察、可复用、可迭代的 AI System。

从这个角度看，未来 AI 的核心竞争力，可能不只是 LLM 本身，而是 LLM 背后的 Harness Engineering。

也就是说：

模型决定了 AI 的基础能力。
Harness 决定了 AI 能不能真正稳定工作。