一句反共识观点，撕开了 AI 编程圈最深的分歧：当模型足够强时，我们还需要脚手架吗？实测数据给出了冷酷的答案。

一、争议的起点：一个反共识的抛出
2025 年的 AI 编程圈，正在经历一场比"该不该用 Rust 重写"更激烈的架构之争。
事情的起因是前 Kimi CLI 负责人、Raft 创始人 Richard Qian 在一次技术分享中抛出了一个反共识观点：
“Harness（脚手架）不会随模型变强而消失，复杂度只会从’能力层’转移到’协作层’。”
这句话直接戳中了当下 AI 编程圈最敏感的神经。要知道，在过去一年里，"模型变强了，所以不需要复杂框架"几乎成了一种政治正确——从 Cursor 的极简主义，到各种"一句话生成全栈应用"的 Demo，整个行业都在贩卖一种乐观叙事：只要模型够强，Prompt 写得好，一切问题都能解决。
Richard Qian 的观点像一盆冷水，浇在了这团火上。
而更耐人寻味的是，就在同一天，一份实测数据悄然佐证了他的判断。

二、两派对立：极简派 vs 重框架派
要理解这场争论的分量，得先看清 AI 编程圈当前的两条技术路线。

2.1 Prompt 极简派
这一派的信条是：模型是核心，框架是负债。
代表选手：
Cursor：以编辑器为中心，最小化 Agent 编排逻辑
v0 / bolt.new：单轮对话直出，追求"一句话到产物"的爽感
部分开源 Agent：仅做工具调用封装，不引入复杂状态机
他们的论据很直观：
GPT-4o、Claude 3.5 Sonnet 等模型在 SWE-bench 上的分数持续上涨
复杂的多 Agent 编排容易引入"电话传话"式的信息损耗
框架越厚，调试成本越高，迭代越慢
极简派喜欢用一个比喻：“模型是发动机，框架是车壳。发动机足够强时，你不需要给自行车装变速箱。”

2.2 重框架派
这一派的信条是：模型只是原材料，编排才是产品。
代表选手：
Devin / Factory：重状态机 + 长程规划
OpenHands（原 OpenDevin）：多 Agent 协作 + 沙箱化执行
Raft：Richard Qian 自己的项目，主打任务分解与协作层
MetaGPT / CrewAI：角色化多智能体分工
他们的论据同样扎实：

真实工程任务的上下文长度远超单轮能承载的范围
错误恢复、状态回滚、子任务并行都需要框架层兜底
模型在"长程任务"上的成功率依然不够看，必须靠编排补偿
重框架派也有一个比喻：“再强的发动机，也得有变速箱、差速器、ECU 才能跑完赛道。F1 赛车不是把发动机装在滑板上。”
两派各执一词，谁也说服不了谁。直到 Richard Qian 用一个新框架重新定义了战场。

三、反共识的核心：复杂度的"转移"而非"消失"
Richard Qian 观点的精妙之处，在于他没有简单地站队任何一边，而是提出了一个更高维的判断：
复杂度守恒。
它的完整推论是这样的：
code
当模型能力较弱时，复杂度集中在【能力层】
→ 需要复杂的 Prompt 工程、Few-shot 示例、思维链引导
→ 需要精细的工具描述、错误重试、输出格式约束

当模型能力变强时，能力层的复杂度确实下降
→ 但任务边界也随之扩张（从写函数 → 写模块 → 写系统）
→ 复杂度转移到【协作层】
→ 多智能体分工、状态同步、任务交接、上下文压缩
换句话说，模型变强不会消灭 Harness，只会改变 Harness 的形态。

这是一个比"极简 vs 重框架"更深刻的判断。因为它揭示了：
阶段 模型能力 Harness 主要负担 典型形态
2023 初 弱 能力层（Prompt 工程） 长 Prompt、Few-shot、CoT
2024 中 中 能力层 + 协作层过渡 工具调用、单 Agent 编排
2025 后 强 协作层 多 Agent 分工、状态机、上下文管理
Harness 不是在变薄，而是在变厚——只是厚的地方换了。

四、冷酷的实测数据：同一模型，成功率差 20 个点
如果说理论推演还不够有说服力，那么同一天流出的实测数据则让这场争论从"哲学问题"变成了"工程问题"。

实验设置：
固定模型：DeepSeek V4 Flash（控制变量）
变化因素：仅更换不同的 Harness（脚手架/编排框架）
任务集：一组具有代表性的真实编程任务
结果：
Harness 类型 成功率 单任务成本 备注
最简 Harness 47% 低 单轮 + 基础工具调用
中等 Harness ~57% 中 单 Agent + 错误恢复
优化 Harness 67% 高 多 Agent + 状态同步
极重 Harness ~60% 极高 过度编排，反而下降
几个值得深挖的现象：

4.1 成功率从 47% 到 67%——20 个点的鸿沟
同一个模型，仅仅因为换了脚手架，成功率相差 20 个百分点。
这是什么概念？要知道，整个 AI 圈为了在 SWE-bench 上提升 5 个点，各家厂商投入了数以亿计的算力去训练模型。而在这里，不换模型、只换 Harness，就拿到了 4 倍于训练收益的提升。
这直接动摇了"模型榜单决定一切"的评估范式。

4.2 单任务成本相差近 7 倍
最简 Harness 和优化 Harness 的单任务成本相差近 7 倍。这意味着：
code
成本 = 模型调用次数 × 单次 token 成本 × 编排开销
Harness 越重 → 调用次数越多 → token 消耗越大 → 成本越高
但关键在于：成本高 7 倍，成功率只高 20 个点。 这说明 Harness 的收益存在边际递减，工程上需要在"成功率"和"成本"之间做权衡。

4.3 极重 Harness 反而下降——过度编排的诅咒
最值得注意的是最后一行：当 Harness 过度复杂时，成功率反而从 67% 下降到 60%。
这印证了 Richard Qian 观点的另一面：复杂度转移到协作层后，如果协作层本身设计得不好，反而会引入新的损耗。 多 Agent 之间的"电话传话"、状态同步的不一致、任务交接时的上下文丢失，都会吃掉模型能力提升带来的红利。
这也解释了为什么"极简派"的 Demo 看起来那么爽——在简单任务上，过度编排确实是负收益。但任务一旦复杂，极简派就会崩盘。

五、代码示例：三种 Harness 厚度的具体实现

为了更直观地理解不同 Harness 厚度的差异，我们通过一个具体任务来展示三种典型 Harness 的实现。假设任务是为一个电商系统实现"用户下单后自动发送邮件通知"功能。

5.1 最简 Harness：单轮对话 + 基础工具调用

# 最简 Harness 实现 - 单轮对话
import openai

def simplest_harness(task_description):
    """最简 Harness：单轮对话完成所有工作"""
    prompt = f"""
    请实现一个电商系统的邮件通知功能：
    1. 用户下单后触发邮件发送
    2. 邮件包含订单详情和预计送达时间
    3. 使用 Python 的 smtplib 库
    
    任务描述：{task_description}
    
    请直接给出完整代码。
    """
    
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}]
    )
    
    return response.choices[0].message.content

# 使用示例
task = "用户下单后发送邮件通知"
code = simplest_harness(task)
print(code)

特点分析：

• 单轮对话完成所有工作
• 无错误处理、无状态管理
• 适合简单、独立的任务
• 成功率约 47%（参考实测数据）

5.2 中等 Harness：单 Agent + 错误恢复

# 中等 Harness 实现 - 单 Agent 带错误恢复
import openai
import json
from typing import Dict, Any

class MediumHarnessAgent:
    """中等 Harness：单 Agent 带错误恢复机制"""
    
    def __init__(self, model="gpt-4"):
        self.model = model
        self.max_retries = 3
        self.conversation_history = []
        
    def execute_task(self, task_description: str) -> Dict[str, Any]:
        """执行任务，带错误恢复"""
        for attempt in range(self.max_retries):
            try:
                # 步骤1：任务分解
                decomposition = self._decompose_task(task_description)
                
                # 步骤2：分步执行
                results = []
                for step in decomposition["steps"]:
                    result = self._execute_step(step)
                    results.append(result)
                    
                # 步骤3：结果整合
                final_result = self._integrate_results(results)
                
                return {
                    "success": True,
                    "result": final_result,
                    "attempts": attempt + 1
                }
                
            except Exception as e:
                print(f"第 {attempt + 1} 次尝试失败: {e}")
                self.conversation_history.append(f"错误: {str(e)}")
                
                if attempt < self.max_retries - 1:
                    # 反思错误并调整策略
                    reflection = self._reflect_on_error(str(e), task_description)
                    self.conversation_history.append(f"反思: {reflection}")
                else:
                    return {
                        "success": False,
                        "error": str(e),
                        "attempts": self.max_retries
                    }
    
    def _decompose_task(self, task: str) -> Dict:
        """任务分解"""
        prompt = f"""
        请将以下任务分解为可执行的步骤：
        任务：{task}
        
        要求：
        1. 每个步骤应该是独立的、可验证的
        2. 步骤之间要有明确的依赖关系
        3. 输出 JSON 格式
        
        当前对话历史：{json.dumps(self.conversation_history[-3:])}
        """
        
        response = self._call_model(prompt)
        return json.loads(response)
    
    def _execute_step(self, step: Dict) -> Any:
        """执行单个步骤"""
        prompt = f"""
        执行以下步骤：
        {json.dumps(step, ensure_ascii=False)}
        
        请给出具体实现代码。
        """
        
        return self._call_model(prompt)
    
    def _call_model(self, prompt: str) -> str:
        """调用模型"""
        messages = self.conversation_history + [{"role": "user", "content": prompt}]
        
        response = openai.ChatCompletion.create(
            model=self.model,
            messages=messages,
            temperature=0.2
        )
        
        result = response.choices[0].message.content
        self.conversation_history.append({"role": "assistant", "content": result})
        return result

# 使用示例
agent = MediumHarnessAgent()
result = agent.execute_task("实现用户下单后的邮件通知功能")
print(f"执行结果: {result}")

特点分析：

• 单 Agent 但具备任务分解能力
• 内置错误恢复和重试机制
• 有简单的对话历史管理
• 成功率约 57%（参考实测数据）

5.3 优化 Harness：多 Agent 协作 + 状态同步

# 优化 Harness 实现 - 多 Agent 协作
import openai
import json
from typing import Dict, List, Any
from dataclasses import dataclass
from enum import Enum

class TaskStatus(Enum):
    PENDING = "pending"
    RUNNING = "running"
    COMPLETED = "completed"
    FAILED = "failed"

@dataclass
class Task:
    id: str
    description: str
    status: TaskStatus
    dependencies: List[str]
    result: Any = None

class OptimizedHarness:
    """优化 Harness：多 Agent 协作 + 状态同步"""
    
    def __init__(self):
        self.agents = {
            "analyzer": AnalyzerAgent(),
            "designer": DesignerAgent(),
            "implementer": ImplementerAgent(),
            "tester": TesterAgent()
        }
        self.task_graph = {}
        self.shared_state = {}
        self.checkpoints = []
        
    def execute_complex_task(self, main_task: str) -> Dict:
        """执行复杂任务"""
        # 1. 创建检查点
        self._create_checkpoint("initial")
        
        try:
            # 2. 分析任务
            analysis = self.agents["analyzer"].analyze(main_task)
            self.shared_state["analysis"] = analysis
            
            # 3. 设计架构
            design = self.agents["designer"].design(analysis)
            self.shared_state["design"] = design
            
            # 4. 构建任务图
            self.task_graph = self._build_task_graph(design)
            
            # 5. 并行执行任务
            results = self._execute_tasks_parallel()
            
            # 6. 集成结果
            final_result = self._integrate_results(results)
            
            return {
                "success": True,
                "result": final_result,
                "tasks_executed": len(results),
                "shared_state_snapshots": len(self.checkpoints)
            }
            
        except Exception as e:
            # 回滚到最近检查点
            self._rollback_to_last_checkpoint()
            return {
                "success": False,
                "error": str(e),
                "rolled_back": True
            }
    
    def _create_checkpoint(self, name: str):
        """创建状态检查点"""
        checkpoint = {
            "name": name,
            "task_graph": self.task_graph.copy(),
            "shared_state": self.shared_state.copy(),
            "timestamp": time.time()
        }
        self.checkpoints.append(checkpoint)
    
    def _rollback_to_last_checkpoint(self):
        """回滚到最近检查点"""
        if self.checkpoints:
            last = self.checkpoints[-1]
            self.task_graph = last["task_graph"]
            self.shared_state = last["shared_state"]

class AnalyzerAgent:
    """分析 Agent：理解任务需求"""
    def analyze(self, task: str) -> Dict:
        prompt = f"""
        分析以下任务需求：
        {task}
        
        请输出：
        1. 核心功能点
        2. 技术难点
        3. 依赖的外部服务
        4. 预估工作量
        
        格式：JSON
        """
        return self._call_model(prompt)

class DesignerAgent:
    """设计 Agent：制定技术方案"""
    def design(self, analysis: Dict) -> Dict:
        prompt = f"""
        基于以下分析设计技术方案：
        {json.dumps(analysis, ensure_ascii=False)}
        
        请设计：
        1. 系统架构图
        2. 模块划分
        3. 接口定义
        4. 数据库设计
        
        格式：JSON
        """
        return self._call_model(prompt)

# 使用示例
harness = OptimizedHarness()
result = harness.execute_complex_task(
    "为电商系统实现完整的订单邮件通知系统，包括："
    "1. 订单创建时发送确认邮件"
    "2. 发货时发送物流邮件" 
    "3. 支持邮件模板管理"
    "4. 失败重试机制"
    "5. 邮件发送统计报表"
)
print(f"优化 Harness 执行结果: {result}")

特点分析：

• 多 Agent 分工协作（分析、设计、实现、测试）
• 共享状态管理，避免信息不一致
• 检查点机制，支持回滚
• 任务图管理，支持并行执行
• 成功率约 67%（参考实测数据）

5.4 三种 Harness 对比分析

维度	最简 Harness	中等 Harness	优化 Harness
架构复杂度	单轮对话	单 Agent + 状态机	多 Agent + 状态同步
错误处理	无	重试机制	检查点回滚
任务分解	无	简单分解	智能分解 + 依赖分析
并发能力	无	无	任务图并行执行
状态管理	无	对话历史	共享状态 + 检查点
适用场景	简单独立任务	中等复杂度任务	复杂系统工程
成功率	~47%	~57%	~67%
开发成本	低	中	高
维护成本	低	中	高

关键洞察：

1. 复杂度转移明显：从最简到优化，复杂度从"让模型理解任务"转移到"让多个 Agent 协作"
2. 边际收益递减：优化 Harness 比中等 Harness 复杂得多，但成功率提升有限（57% → 67%）
3. 适用场景决定选择：简单任务用最简 Harness 性价比最高，复杂任务才需要优化 Harness

这个代码示例清晰地展示了 Richard Qian 的观点：模型变强不会消灭 Harness，只会让 Harness 的复杂度从能力层转移到协作层。最简 Harness 关注"如何让模型理解任务"，而优化 Harness 关注"如何让多个智能体高效协作"。

五、核心公式：Agent 真实性能 = 模型 × 脚手架
把上面的讨论收敛成一个公式：
code
Agent 真实性能 = f(模型能力) × g(Harness 设计) × h(任务复杂度)
简化版：
code
P_agent = M × H
其中：
M：模型本身的能力（由参数量、训练数据、对齐方式决定）
H：Harness 的适配系数（由编排策略、状态管理、协作机制决定）
这个公式有几个重要推论：
推论 1：模型榜单不等于 Agent 榜单
code
M_a > M_b ≠> P_agent_a > P_agent_b
模型 A 比模型 B 强，不代表用 A 做出来的 Agent 比 B 强。因为 Harness 的适配系数 H 是乘性的，一个弱模型配强 Harness，可能反超强模型配弱 Harness。
这解释了为什么 Devin 在很长一段时间里，用相对普通的模型却跑出了惊艳的效果——它的 H 值极高。

推论 2：Harness 的边际收益取决于任务复杂度
code
∂P/∂H 是关于任务复杂度的递增函数
任务越复杂，Harness 的边际收益越高。简单任务上，H 的提升对 P 贡献有限（甚至为负）；复杂任务上，H 的提升是决定性的。
这就是为什么"极简派"和"重框架派"都能找到支持自己的证据——他们在不同的任务复杂度区间里测试。

推论 3：存在最优 Harness 厚度
code
∂P/∂H = 0 时，H 达到最优
过度加厚 Harness（如第 4.3 节所示）会让 H 反而下降。最优 Harness 厚度是任务复杂度的函数，不是越厚越好。

六、复杂度转移的具象化：能力层 → 协作层
让我们用一个具体例子看看复杂度是如何"转移"的。
任务：重构一个 10 万行的单体仓库为微服务架构。

6.1 弱模型时代（能力层复杂度）
code
[Harness 的工作]
├── 极长的 Prompt（描述重构规则、代码风格、架构约束）
├── Few-shot 示例（给出 5-10 个重构前后对比）
├── 思维链引导（强制模型 step-by-step）
├── 输出格式约束（JSON Schema 严格校验）
└── 错误重试（格式错误时重新生成）
复杂度集中在"让模型能做对一件事"。

6.2 强模型时代（协作层复杂度）
code
[Harness 的工作]
├── 任务分解（把 10 万行拆成 N 个子任务）
├── 多 Agent 分工
│ ├── Agent-1: 分析依赖图
│ ├── Agent-2: 识别服务边界
│ ├── Agent-3: 生成迁移脚本
│ └── Agent-4: 编写适配层
├── 状态同步（共享依赖图、边界决策）
├── 任务交接（Agent 间传递上下文，避免重复分析）
├── 冲突解决（多个 Agent 改同一文件时合并）
├── 上下文压缩（长程任务中压缩历史）
└── 检查点与回滚（某步失败时回退到稳定状态）
复杂度转移到了"让多个模型能协作完成一件事"。
注意：总复杂度并没有减少，反而增加了——因为任务边界本身扩张了。 弱模型时代，我们不敢让 Agent 做 10 万行的重构；强模型时代，我们敢了，于是协作层的复杂度暴涨。
这就是 Richard Qian 说的"Harness 越厚"——厚在协作层。

七、对评估范式的冲击：不能只看模型榜单
这场争论对整个 AI 编程圈的评估方法提出了严肃挑战。
当前主流的评估方式有两种，都有问题：

7.1 模型榜单评估（如 SWE-bench）
问题：只评估 M，不评估 H。
SWE-bench 上模型 A 比 B 高 5 个点，但配上不同的 Harness，结论可能完全反转。榜单上的"最强模型"，放到一个糟糕的 Harness 里，可能跑出比"弱模型 + 好 Harness"更差的效果。

7.2 产品 Demo 评估
问题：H 是隐式的，无法归因。
当我们看到 Devin 的 Demo 很惊艳时，分不清是模型强还是 Harness 强。当 Cursor 的 Demo 很流畅时，也分不清是模型强还是编辑器集成做得好。H 被藏在了"产品体验"的黑盒里。

7.3 应该怎么做？
Richard Qian 的观点隐含了一个评估范式的建议：
code
评估一个 AI 编程 Agent，必须同时报告：

1. 使用的模型（M）
2. 使用的 Harness（H）
3. 在不同任务复杂度下的 (M, H) 组合表现
   只有控制变量——如那份实测数据所做的"固定模型，换 Harness"——才能看清 H 的真实贡献。否则，所有"我的 Agent 比你的强"的争论都是 M 和 H 混淆的伪命题。

八、工程实践：如何选择 Harness 厚度
收敛一下，给工程实践一些可操作的建议。
8.1 按任务复杂度选 Harness
python
def choose_harness(task):
complexity = estimate_complexity(task) # 上下文长度 × 依赖深度 × 步骤数
if complexity < LOW:
return “极简 Harness” # 单轮 + 工具调用
elif complexity < MID:
return “单 Agent + 错误恢复” # 加 retry、reflection
elif complexity < HIGH:
return “多 Agent + 状态同步” # 协作层登场
else:
return “多 Agent + 检查点 + 上下文压缩” # 全套协作机制
不要一刀切。 极简派和重框架派的错误都在于试图用一种 Harness 厚度应对所有任务。

8.2 协作层设计的三个关键
当复杂度转移到协作层后，Harness 的设计重点变成：
任务交接的上下文压缩：Agent A 把结果传给 Agent B 时，不能传全部上下文（太贵），也不能只传结论（信息丢失）。需要设计"足够 B 继续工作的最小上下文"。
状态同步的一致性：多 Agent 并行修改时，需要一个单一事实来源（single source of truth），避免各自基于过时状态决策。
检查点与回滚：长程任务必须能回退到上一个稳定状态，否则一步错步步错。这是协作层最容易忽视、也最值钱的能力。

8.3 警惕"过度编排"
实测数据中极重 Harness 反而下降的现象，提醒我们：
多 Agent 不是越多越好，每多一个 Agent 就多一份交接损耗
状态机不是越复杂越好，每多一个状态就多一份同步成本
协作层的复杂度应该恰好覆盖任务复杂度，不要过度设计
九、延伸思考：这个争论的更深层含义
Richard Qian 的观点，其实触及了一个比 AI 编程更深的命题：
工具的复杂度，是否会随底层能力提升而消失？
历史给出的答案是一致的：
编译器变强了，程序员没有变得更轻松，而是开始写更复杂的系统软件
数据库变强了，DBA 没有消失，而是开始处理更大规模的分布式事务
云原生变强了，运维没有消失，而是开始管理更复杂的微服务拓扑
能力的提升总是伴随着任务边界的扩张，复杂度永远守恒，只是换了栖息地。
AI 编程也不会例外。模型变强，Harness 不会消失，只会从"伺候模型"变成"指挥模型"。从能力层到协作层，从单兵作战到多兵种协同。
所以，下次再看到"模型这么强了，还要什么框架"的言论时，不妨想想 Richard Qian 的那句话，再看看那份 47% → 67% 的数据。发动机再强，也跑不完没有变速箱的赛道。

参考资料
Richard Qian 技术分享关于 Harness 复杂度转移的论述
DeepSeek V4 Flash 在不同 Harness 下的实测对比数据
SWE-bench 模型评估榜单
OpenHands / Raft / MetaGPT 等多 Agent 框架设计文档
Cursor / v0 / bolt.new 等极简派产品实践
我的观点：这场争论的真正价值，不在于分出极简派和重框架派的胜负，而在于让我们意识到——评估 AI 编程 Agent，必须把模型和脚手架拆开看。 任何只谈模型不谈 Harness 的对比，都是耍流氓。未来的 AI 编程竞争，主战场正在从"谁的模型强"转移到"谁的 Harness 设计得更懂任务"。这才是这场架构之争留给行业最值得深思的遗产。