Harness engineering—AI时代的软件工程新范式#

AI时代给软件工程带来了一个最大的变量—大语言模型，它是AI native应用最核心的组件，它最核心特点是：输出是不确定的。

不确定就会难以预测，这不是它的缺点，这是智慧的必然——确定的东西没办法称作智慧。但是我们工作任务的目的地是明确的，想让AI生成一个minecraft，它生成一个terraria是不行的。所以要有Harness，马具，来驾驭LLM这匹烈马。Harness enginerring，驾驭工程，就是迄今为止AI native应用的总结，我们所有的那些框架，工程，所做的努力，就是为了驾驭LLM这个随机性组件。

误解#

我在看那些前沿开源项目之前，我以为厉害的agent要有多么多么复杂的工作流编排，同时并行几十个Agent，执行者，检察官…而后我了解到，事情没有那么复杂。

就拿商业化最成功Agent产品Claude Code，它的核心其实就是一个While True循环；没错，有时候我们还是太傲慢，觉得自己比模型聪明，可以教它做事，这反而弄巧成拙。随着模型能力的提高，真正优秀的harness应该是agentic的，充分发挥模型自己能力，一个简单的ReAct范式就可以充分把模型很好的调用起来。

这样来看，harness设计也是一个平衡的智慧。

关注点#

Harness核心关注点，在我看来是一下几项：

上下文工程#

上下文是最稀缺的资源，无论模型如何发展，它总赶不上消息历史膨胀的速度，即使真的做到了无限上下文，太长的上下文也会把真正重要的东西淹没。所以上下文工程不是简单的压缩上下文，而是合理的，在每轮对话，把模型真正关注需要的东西放进关注力最强的地方。

这也是一个平衡的艺术，考验的也是系统设计的能力。

围绕上下文工程也能衍生出很多东西，比如父agent和子agent的架构，一方面也是为了给某些任务一个干净的上下文；比如工具系统和skill系统的延迟发现，索引，也是为了解决上下文膨胀问题。

安全#

agent的安全看似非常简单，实则很难，因为极致的安全，往往是以牺牲大模型的能力为代价的。就比如一个最简单的bash tool，据说claude code里面写了1000多行，因为这个工具的能力强大，破坏力同时也很强大怎样，平衡agent的能力边界和安全是一个问题，否则会造成不可估量的后果

记忆#

大模型本质上是无状态的，本质上就是不断的在预测下一个字。持久化的记忆需要外部，目前记忆有很多解决方案，就比如过去的RAG，现在有llm wiki，claude code的纯文件系统，我觉得它最后应该也是轻量的，agentic的，能够充分利用LLM的能力。而不是笨重的，因为所有的笨重的系统都还是传统设计范式的延续，不适合与agent时代，不过现在这方面所有的技术都还在探索阶段。

总结#

Harness工程是一个全新的领域，每天都会有各种各样大大小小的开源项目冒出来，所以没有谁对谁错。大浪淘沙，最后能留下来的自然就是有价值的最佳实践。

其实我们不难发现，所谓Harness Engineering，背后考验的还是系统设计能力——设计一个稳定，可持续的系统并持续敏捷迭代，而这背后隐藏的还是那些经典的计算机系统思维——暴露合适的抽象，做出正确的取舍…

所以，打好计算机基础才能走得长远，会用AI是没有门槛的，而强大的工程师思维，解决问题的能力才是护城河。