从跟AI聊天到让AI干活：Harness Engineering 与四种行为范式

如果你最近在AI技术圈晃悠，可能注意到一个新词冒出来了：Harness Engineering。2026年初，HashiCorp联合创始人Mitchell Hashimoto正式提了这个概念，OpenAI随后把它定义为一门学科：“如何设计脚手架，使Codex和类似的代理能够在以代理为先的世界中可靠地运行。”

这有一个视频 Harness Engineering 是什么？和提示词工程和上下文工程有什么关系？，Up 总结得非常棒。

Harness Engineering 就是让模型能稳定输出的一套工程化结构——通过编排、记忆、执行、反馈这些“马甲”，把大模型的能力兜住。模型越强，马甲就可以越轻薄。

但光有底盘还不够。如果说 Harness 搭的是“物理底盘”，决定系统会不会崩，那么行为范式就是装在底盘上的“认知引擎”，决定模型怎么想、怎么干。下面这四种范式，基本覆盖了目前Agent干活的主要套路。

ReAct：走一步看一步

ReAct的核心是把“想”和“做”绑在一起。模型不能闷头一次性输出答案，必须先显式说出自己的推理（Thought），再决定调什么工具（Action），然后等外部环境返回真实结果（Observation），根据反馈修正下一步。

这就像修车：你不能光靠脑补判断故障，得先拆开看看（Action），看到实际情况（Observation），再决定下一步拧哪颗螺丝。边思考、边动手、边纠偏，让模型摆脱了纯文本接龙的幻觉，真正能在物理世界里落地执行多步任务。

Plan-Execute-RePlan：谋定而后动

遇到复杂任务，ReAct那种“走一步看一步”容易迷路。Plan-Execute-RePlan的思路是：先统揽全局，把大目标拆成子任务队列，再逐个执行。

执行过程中如果撞墙——比如数据缺失、接口报错——系统会把真实反馈传回来，模型据此重新评估局势，动态调整甚至彻底重写剩下的计划。这就像自驾游：出发前规划好路线，路上遇到封路就重新导航，而不是硬着头皮往前开。

Reflection：交卷前先自己批改一遍

代码生成、架构设计这类任务，单次生成的质量往往不靠谱。Reflection的做法是把模型一分为二：既是生成者，也是评审员。

先出初稿（Generate），然后切换视角，以严苛评审员的身份挑毛病（Evaluate），再根据意见修改（Refine）。通常迭代3次左右，直到评审员觉得达标了才交卷。不借助外部工具，纯靠内部“左脚踩右脚”，就能在代码和数学推理上实现明显的质量跃升。

Multi-Agent：专业的人干专业的事

当系统复杂度极高时，单体Agent会扛不住——一个System Prompt既要懂前端又要懂底层并发，日志杂乱还会污染上下文。Multi-Agent的思路是拆分：每个SubAgent只带极度精简的上下文和专属工具，通过路由和状态交接来协同。

目前主要有三种形态：SubAgents各自独立干活，主控统一汇总；Agent Teams允许子节点互相通信、共享任务清单；Agent Swarm则更激进，任务重时能动态孵化新Agent投入并行队列，靠算力弹性裂变应对高并发。

小结

ReAct是走一步看一步，Plan-Execute-RePlan是谋定而后动，Reflection是交卷前先自查，Multi-Agent是术业有专攻。没有最好的范式，只有最适合当前任务的。

而Harness Engineering的价值，就在于把这些行为范式、工具系统、记忆管理、容错机制整合成一套可靠的运行环境。模型能力越来越同质化的今天，真正拉开差距的往往不是模型本身，而是驾驭模型的那套系统。就像赛车，引擎重要，但底盘、悬挂和空气动力学才决定圈速。