AI工程范式之争：代码设计Harness与模型驱动Harnesses的架构选择

1. 项目概述：一场关于AI工程范式的思辨

最近在跟几个做AI应用落地的朋友聊天，大家不约而同地提到了一个核心困惑：当我们构建一个基于大语言模型（LLM）或智能体（Agent）的复杂系统时，到底应该是“代码设计Harness”，还是“模型驱动Harnesses”？这个看似拗口的标题，实际上触及了当前AI工程化实践中的一个根本性分歧。简单来说，Harness在这里可以理解为“约束框架”或“控制套件”，它定义了如何组织、调用、监控和评估AI模型（尤其是LLM/Agent）来完成特定任务。而“Code designs Harness”与“Model drives Harnesses”之争，本质上是两种截然不同的系统构建哲学。

前者，“代码设计Harness”，意味着开发者是绝对的中心。我们像传统软件工程一样，用严谨的代码逻辑来构建一个坚固的框架（Harness），模型（Model）或智能体（Agent）只是这个框架中一个可替换的、功能性的“零件”。框架规定了输入输出的格式、处理流程、错误处理机制、评估标准等一切。模型需要严格适配框架的接口和规范，它的能力被框架所“驯化”和“约束”。这种思路下，系统的确定性高，可控性强，但模型的“灵性”和涌现能力可能被抑制。

后者，“模型驱动Harnesses”，则将模型（特别是能力强大的LLM或规划能力强的Agent）置于驱动地位。我们承认模型自身具有复杂的认知、规划和执行能力，因此Harness的设计应该是灵活、动态甚至是由模型参与共同定义的。框架（Harnesses，注意复数）更像是一组工具、一组协议或一个协作环境，它根据模型在不同任务、不同上下文中的表现和需求，动态地调整自身结构、提供不同的工具集或改变交互流程。模型是“驾驶员”，Harness是“可重构的车辆和道路系统”。

这场辩论之所以重要，是因为它直接决定了我们开发AI应用时的技术选型、架构设计、团队分工乃至最终产品的天花板。是追求稳定可控的“软件2.0”，还是拥抱灵活强大的“智能体原生”？接下来，我将结合具体的实践场景，深入拆解这两种范式的核心逻辑、技术实现与取舍之道。

2. 范式之争：代码设计 vs. 模型驱动

要理解这场辩论，我们首先得抛开抽象概念，看看它们在实际项目中长什么样。

2.1 “代码设计Harness”：确定性框架下的模型仆从

在这种范式下，系统的核心是一个由开发者精心编写的、逻辑严密的程序。我们以一个“智能客服工单分类与路由系统”为例。

核心思路：系统的目标是自动分析用户提交的工单文本，将其分类（如“账号问题”、“支付故障”、“产品咨询”），并根据紧急程度和技能组路由给相应的客服人员。

Harness（框架）的设计：

1. 输入标准化模块：接收工单原始数据（可能来自网页表单、API、邮件），进行清洗、去除无关字符、统一编码。
2. 预处理流水线：调用固定的自然语言处理（NLP）步骤，如分词、去除停用词、词干提取。这里可能使用像jieba、spaCy这样的确定性库。
3. 特征工程与模型调用层：将预处理后的文本转化为特征向量。例如，使用一个预先训练好的TF-IDF模型（从joblib加载的tfidf_model.pkl）将文本转换为数值特征。然后，将这个特征向量输入到一个分类模型（可能是传统的机器学习模型如SVM、随机森林，也可能是一个轻量化的LLM嵌入模型）进行预测。
4. 规则后处理层：模型输出一个分类标签和置信度。Harness中会写入明确的业务规则：例如，如果置信度低于0.7，则标记为“待人工审核”；如果文本中包含“紧急”、“无法登录”等关键词，则自动提升优先级。
5. 路由与执行器：根据最终的分类和优先级标签，调用内部API，将工单分配到对应的客服队列。
6. 监控与回馈环：记录每一次分类的输入、输出、置信度和最终分配结果，用于后续的模型重训练和规则优化。

在这个Harness中，LLM或任何模型（上述的tfidf_model和分类模型）都只是第3步中的一个“函数调用”。它们的接口是固定的（输入特征向量，输出标签和分数），行为被严格限定。整个系统的智能上限，很大程度上取决于开发者设计的特征工程和规则逻辑是否完备。如果出现一种全新的投诉类型（例如，关于某个新功能的BUG），除非开发者更新特征词典或添加新规则，否则系统可能无法正确处理。

实操心得：采用“代码设计Harness”范式，项目管理的复杂度相对较低，因为流程是确定的。测试可以覆盖所有分支，SLA（服务等级协议）容易保证。但它的致命弱点在于“脆弱性”。面对开放域、长尾或定义模糊的任务时，需要维护一个极其庞大且不断增长的规则库和特征集，技术债务会迅速累积。我曾在一个早期项目中采用这种方式处理用户意图识别，最终规则文件变得比核心业务代码还长，维护成本惊人。

2.2 “模型驱动Harnesses”：将模型视为战略核心

现在，让我们用“模型驱动”的视角重构同一个客服系统，或者考虑一个更复杂的场景：一个帮助分析师进行市场研究的AI助手。

核心思路：我们不再试图用代码穷举所有可能的情况和规则，而是构建一个能够理解任务、自主规划、调用工具、并动态调整策略的智能体（Agent）。Harness在这里提供的是“能力支持”和“运行环境”，而非“指令流程”。

Harnesses（复数框架）的体现：

1. 工具集（Toolkit）：Harness提供一组定义良好的工具，如“搜索最新财经新闻”、“查询公司财报数据库”、“进行情感分析”、“生成图表摘要”、“撰写分析报告草稿”。每个工具都有清晰的API描述。
2. 规划与协调层：系统初始化时，会将任务（例如，“分析新能源汽车行业未来半年的竞争格局”）和可用工具的描述，一并提交给一个核心的“规划型”LLM（例如，Claude 3 Opus或GPT-4）。这个LLM（作为Agent的大脑）会自主生成一个执行计划：“第一步，搜索近期行业政策与头部公司动态；第二步，获取主要公司的季度财报数据；第三步，对比分析各公司的技术路线和市场份额；第四步，综合信息撰写报告。”
3. 动态执行引擎：Harness中的执行引擎负责解读LLM生成的计划，按顺序或根据条件调用相应的工具。关键在于，这个引擎需要处理不确定性：如果搜索工具返回的结果不理想，引擎需要将这一信息反馈给LLM，请求调整搜索策略或跳过此步。这要求Harness具备状态管理和与LLM的多轮对话能力。
4. 上下文管理与记忆：Harness需要维护一个不断增长的对话上下文，包含任务目标、已执行步骤、获取到的信息片段、以及LLM的中间思考过程。这直接应对了“maximum context length is 1048576 tokens”这类挑战。优秀的Harness需要具备智能的上下文压缩、摘要和优先级排序能力，确保最相关的信息保留在窗口内。
5. 评估与反思层：任务执行到某个阶段或完成后，Harness可以调用另一个“评估型”LLM，或者内置一些评估指标，对当前结果进行批判性审视。例如，“报告中的数据引用是否完整？”“分析维度是否全面？”根据评估结果，Harness可以决定是否让主Agent进行修正，或标记出需要人工复核的部分。

在这个范式下，Harness不再是“模具”，而是“舞台”和“工具箱”。模型（特别是作为规划核心的LLM）是舞台上的主角，它驱动着整个任务的推进流程。不同的任务，甚至同一任务的不同执行阶段，Harness被“驱动”出的形态（使用的工具组合、执行路径）都是不同的。

注意事项：“模型驱动”范式对模型能力的要求极高。你需要一个在规划、工具使用、长上下文理解方面都足够强大的LLM作为核心引擎。同时，Harness的设计复杂度也急剧上升，你需要处理LLM输出的非确定性（它可能生成无法解析的指令）、工具调用的错误处理、以及可能无限循环的规划-执行循环。一个常见的坑是，没有为Agent设置清晰的“停止条件”，导致它在一些细节上陷入死循环。

3. 核心技术栈与工具选型解析

选择不同的范式，意味着选择不同的技术栈和工具。下面我们来具体拆解。

3.1 “代码设计Harness”的典型技术栈

这种范式下的技术选型偏向于传统软件工程与机器学习Ops（MLOps）的结合，强调稳定、可控和高效。

1. 核心框架与运行时：

   • FastAPI / Flask：用于构建清晰、高效的API服务层，定义严格的输入/输出模式（Pydantic Models），这是Harness的“外壳”。
   • Celery / Dramatiq：对于耗时较长的模型推理或批处理任务，引入异步任务队列，保证主服务的响应性。
   • 工作流引擎：对于流程复杂的任务，可以使用Prefect或Airflow来编排固定的处理流水线。每个节点（任务）都是确定的函数。

2. 模型部署与集成：

   • 模型格式：倾向于使用标准化格式，如ONNX、TensorFlow SavedModel或PyTorch TorchScript，以实现跨平台部署和性能优化。
   • 推理服务器：使用Triton Inference Server、TensorFlow Serving或TorchServe。这些服务器提供版本管理、动态批处理、并发监控等功能，让模型像一个稳定的微服务一样被Harness调用。
   • 轻量级LLM集成：如果需要LLM能力，通常会选择参数量较小、推理速度快的模型，如Sentence-Transformers用于嵌入，或量化后的Llama 2/3-7B、Gemma用于简单的文本生成。通过vLLM或Hugging Face TGI(Text Generation Inference) 进行高性能部署。

3. 状态与配置管理：

   • 系统的状态（如工单处理到哪一步）通常保存在外部数据库（PostgreSQL,Redis）中，由Harness的逻辑代码完全掌控。
   • 配置（如分类阈值、路由规则）使用YAML文件或配置管理服务（如Consul），更改配置需要重新部署或热加载。

4. 监控与评估：

   • 使用Prometheus+Grafana监控API延迟、模型调用次数、错误率等指标。
   • 评估依赖于人工标注的测试集和预定义的业务指标（准确率、召回率、F1值、平均处理时间）。

工具选型理由：这套栈的核心思想是“控制”。每一个环节都有成熟的、可预测的工业级工具。系统的行为不依赖于某个黑盒模型的一次随机输出，而是由代码逻辑和配置完全定义。这非常适合对可靠性要求极高、任务边界清晰的场景，如金融风控、内容安全过滤、标准化文档处理。

3.2 “模型驱动Harnesses”的典型技术栈

这种范式则深度拥抱AI原生理念，技术栈围绕LLM和Agent的能力构建。

1. Agent框架与编排：

   • LangChain / LangGraph：这是目前最流行的选择。LangChain提供了大量的工具集成、模板和记忆组件，能快速搭建Agent原型。LangGraph在此基础上引入了基于图的状态机概念，非常适合描述Agent复杂的、有分支循环的决策流程。它允许你定义“节点”（工具调用或LLM调用）和“边”（条件流转），Harness的形态由此图定义，但具体的执行路径由LLM在运行时决定。
   • AutoGen：由微软推出，擅长构建多智能体协作系统。你可以定义不同的Agent角色（程序员、测试员、产品经理），它们通过对话协同完成任务。Harness在这里体现为定义角色、设定交互协议和提供共享状态。
   • Semantic Kernel/Dify：前者是微软的另一个框架，强调将传统代码技能与LLM语义技能“插件化”结合；后者更像一个低代码平台，通过可视化工作流（Workflow）来编排LLM和工具，其“workflow将LLM输出的内容保存到一个word文档”正是这种思想的体现。

2. 核心模型服务：

   • 高性能LLM API/端点：强烈依赖强大的LLM作为“大脑”。通常通过API调用云端大模型（如OpenAI GPT-4/4o,Anthropic Claude 3,DeepSeek-V4），或部署开源大模型（如Qwen2.5-72B,Llama 3 70B）。需要特别处理上下文长度（context length）和速率限制问题。
   • 嵌入模型与向量数据库：为Agent提供长期记忆和知识检索能力。使用text-embedding-3-small或BGE等模型生成嵌入，存入Pinecone、Weaviate或Qdrant等向量数据库。Harness需要管理检索策略（如MMR最大边际相关性）。

3. 工具与技能抽象：

   • 工具被抽象为具有标准描述（名称、描述、参数schema）的函数。框架如LangChain提供了@tool装饰器来简化创建。
   • 需要为工具调用设计鲁棒的错误处理与重试机制。例如，一个搜索工具可能因网络问题失败，Harness应能捕获异常，并决定是重试、换用备用工具，还是将问题反馈给LLM重新规划。

4. 状态、记忆与持久化：

   • Agent的状态（对话历史、中间结果、工具执行记录）管理至关重要。简单的可以使用内存存储，复杂的需要持久化到数据库。LangChain提供了多种Memory后端。
   • 需要考虑上下文窗口限制。当对话或任务历史超过模型限制时，需要智能的摘要策略（如通过另一个LLM总结关键信息）或分层记忆系统。

5. 评估与调试：

   • 评估变得异常困难。无法再用简单的准确率衡量。需要结合过程评估（Agent的决策步骤是否合理？）和结果评估（最终产出质量如何？）。TruLens、Phoenix等工具开始提供针对LLM应用的可观测性。
   • 调试更像是在“教书”或“调教”一个智能体，需要分析它的思考链（Chain-of-Thought），修正工具描述，或提供更好的示例（Few-shot Examples）。

工具选型理由：这套栈的核心思想是“赋能”和“协作”。框架的目标是最大化释放LLM的潜力，让它能灵活运用各种工具解决问题。技术选型的重点是那些能良好支持动态性、交互性和长上下文管理的组件。它适合探索性、创造性或流程无法预先完全定义的任务，如智能编程助手、复杂研究分析、开放域对话机器人。

4. 实战场景对比与架构设计

让我们通过两个更具体的并行案例，来感受两种范式在架构设计上的根本差异。

4.1 场景一：智能代码审查助手

目标：开发一个能自动审查Pull Request（PR）中代码质量、安全性和规范符合性的助手。

方案A：代码设计Harness

• 架构：
  1. 事件触发器：通过GitHub Webhook监听PR创建/更新事件。
  2. 静态分析管道：Harness启动一个固定流水线。
     • 调用SonarQube或CodeQL进行静态代码安全扫描。
     • 调用Pylint/ESLint进行代码风格和语法检查。
     • 调用自定义脚本检查提交信息规范、文件命名约定等。
  3. 结果聚合器：收集所有静态分析工具的报告，按照预定义的规则（如：存在高危漏洞则阻塞；风格问题超过10个则警告）进行汇总。
  4. 评论生成器：使用一个模板引擎，将汇总结果填充到固定的Markdown模板中，生成评论并提交到PR。
• 特点：审查项完全固定，规则明确。新增一种检查（如检查是否使用了某个废弃的API）需要开发新的脚本并集成到管道中。系统行为完全可预测。

方案B：模型驱动Harnesses

• 架构：
  1. 事件与上下文构建：收到PR事件后，Harness不仅获取代码Diff，还会自动获取相关的需求文档、过往类似PR的讨论、项目编码规范文档，构建一个丰富的上下文包。
  2. 智能体激活：将上下文包和任务指令（“请全面审查此PR”）发送给一个具备代码理解能力的LLM Agent（如基于Claude 3或GPT-4 Code Interpreter构建）。
  3. 自主审查循环：
     • Agent首先理解变更意图，阅读Diff和关联文档。
     • 然后规划审查重点：它可能决定先检查核心逻辑，再查看边界条件，最后审查错误处理。
     • 在审查过程中，它可以动态调用工具：比如，对某段复杂的算法，调用一个代码解释工具来验证逻辑；对某个数据库操作，调用SQL分析工具检查潜在的性能问题；对某个外部API调用，检查项目中是否有对应的Mock或测试。
     • 它还可以进行知识检索：从向量数据库中查询类似的代码片段及其审查意见作为参考。
  4. 报告生成与交互：Agent生成一份结构化的审查报告，不仅列出问题，还会解释问题的严重性、给出修改建议，甚至能生成示例代码。它可以将报告以评论形式发布，并能响应后续的开发者追问，进行多轮交互式讨论。
• 特点：审查范围动态、深入，能结合项目上下文和开发者意图。能处理规则未覆盖的复杂逻辑问题。但审查耗时可能更长，且结果有一定不可预测性（取决于LLM的发挥）。

4.2 场景二：客户服务对话系统

目标：构建一个能处理多轮对话、解决复杂问题的在线客服系统。

方案A：代码设计Harness

• 架构：经典的“意图识别 -> 槽位填充 -> 对话状态管理 -> 执行/回复”流水线。
  1. NLU模块：使用训练好的意图分类模型和命名实体识别（NER）模型处理用户语句。
  2. 对话状态跟踪器（DST）：一个维护着当前对话状态（如：用户在办理什么业务、已收集哪些信息）的代码模块。
  3. 对话策略模块（Policy）：基于当前状态和NLU结果，根据预编写的策略树（if-else或有限状态机）决定下一步动作（如：询问更多信息、调用API、回复固定话术）。
  4. 自然语言生成（NLG）：根据策略模块的指令，从模板库中选择或生成回复文本。
• 特点：对于封闭域、流程固定的业务（如查话费、改套餐），效率高且稳定。但扩展性差，增加一个新业务需要重新标注数据、训练模型、编写策略，成本高昂。

方案B：模型驱动Harnesses

• 架构：以LLM为核心的多技能智能体。
  1. 中央对话引擎：一个强大的LLM作为对话主脑，维护整个对话历史和上下文。
  2. 技能（工具）库：Harness提供一系列技能，如“查询订单状态API”、“计算费用折扣API”、“生成服务满意度问卷”、“转接人工坐席协议”。
  3. 动态规划与执行：每轮用户输入后，LLM分析当前对话状态和用户需求，自主决定是否需要调用某个技能、需要询问什么信息来补全技能参数、或是直接生成回复。例如，用户说“我想退掉昨天买的手机”，LLM可能规划：先调用“查询最新订单”技能，确认订单详情和退货政策，再调用“发起退货流程”技能，最后生成回复告知用户下一步操作。
  4. 记忆与个性化：利用向量数据库存储历史对话摘要，实现跨会话的记忆，提供个性化服务（如“您上次反映的XX问题解决了吗？”）。
• 特点：能处理开放域、多跳的复杂查询，对话自然灵活。添加新技能只需定义好API接口和描述，无需修改核心对话逻辑。但对LLM的推理能力、工具调用的可靠性要求极高，且单次交互成本更高。

5. 决策指南：如何为你的项目选择范式？

面对两种范式，如何做出选择？这并非非此即彼，而是一个光谱。你可以根据项目的核心维度进行定位。

混合模式（Hybrid Approach）：在实际项目中，纯粹的两种范式往往并存，形成混合架构。

• 外层模型驱动，内层代码设计：一个用于复杂任务拆解的Agent（模型驱动），在拆解出的子任务中，调用一个高度优化的、规则化的数据处理服务（代码设计）。例如，研究Agent规划出“获取A公司股价”的任务，然后调用一个稳定的金融数据API客户端。
• 代码设计框架中嵌入模型能力：在一个以规则为主的客服系统中，引入一个LLM模块专门处理“其他”类别或进行情感分析，作为现有流程的补充和增强。

个人经验与建议：不要盲目追求“模型驱动”的时髦。我见过很多团队在业务逻辑本身非常清晰的情况下，强行上马Agent框架，结果引入了巨大的复杂性和不稳定性，得不偿失。一个实用的切入点是：从“代码设计Harness”开始，识别其中最僵化、最易变、最需要智能的环节，将其剥离出来，用“模型驱动”的思路进行改造，将其变成一个由模型驱动的“智能子模块”。例如，先构建一个规则化的工单分类器，然后发现“紧急程度判断”这个子任务规则很难写全，再用一个微调的小模型或Prompt精巧的LLM来负责这部分。这样既能享受AI带来的灵活性提升，又能将风险和控制力掌握在核心框架手中。

6. 实施挑战与避坑指南

无论选择哪种范式，在实施过程中都会遇到一系列挑战。以下是一些常见的“坑”及应对策略。

6.1 “代码设计Harness”的典型挑战

1. 规则爆炸与维护地狱：

   • 问题：随着业务复杂，if-else规则或特征工程代码指数级增长，难以理解和维护。
   • 对策：引入决策表或规则引擎（如Drools）来外部化管理业务规则。定期进行规则审计和简化。积极探索将部分稳定、可标注的规则转化为轻量级机器学习模型，实现从“硬规则”到“软模型”的渐进过渡。

2. 面对未知输入的脆弱性：

   • 问题：系统对训练数据分布外的输入（OOD）处理能力差，容易产生荒谬输出或直接崩溃。
   • 对策：必须在Harness中设计强大的输入验证和异常处理层。对于无法处理的输入，必须有清晰的降级策略（如返回“我需要更多信息”或转交人工）。建立监控，持续收集这些“未知输入”，用于迭代改进系统。

3. 模型更新与迭代成本高：

   • 问题：每次更新模型（即使是替换为同架构的更优版本），都需要重新测试整个流水线，确保接口兼容性和性能表现。
   • 对策：采用严格的模型版本化和契约测试。使用模型注册表（如MLflow）管理版本。Harness通过模型别名（如production-model）引用模型，而非具体版本号，便于滚动更新和快速回滚。

6.2 “模型驱动Harnesses”的典型挑战

1. LLM输出的非确定性与可靠性：

   • 问题：LLM可能生成格式错误、无法解析的JSON；可能“幻觉”出不存在的工具或参数；可能陷入循环思考。
   • 对策：
     • 结构化输出：强制要求LLM使用JSON、XML或YAML等格式输出，并使用Pydantic等库进行严格验证。像LangChain的StructuredOutputParser就很好用。
     • 重试与降级：设计自动重试机制（如尝试重新Prompt、让模型修正输出）。设定最大重试次数，失败后转入降级流程（如执行一个默认操作或请求人工干预）。
     • 思维链（CoT）与自我验证：鼓励LLM展示其推理步骤（“Let‘s think step by step”），并在关键决策点加入自我验证提示（“请检查你刚才的规划是否符合工具A的输入要求？”）。

2. 上下文管理与成本控制：

   • 问题：长对话或多步骤任务极易耗尽模型的上下文窗口（遇到maximum context length错误）。同时，长上下文调用API成本高昂。
   • 对策：
     • 选择性上下文：不要无脑地将所有历史对话都塞进上下文。实现一个记忆管理系统，区分核心记忆（任务目标、关键决策）、近期记忆（最近几轮对话）和长期记忆（存入向量数据库的可检索知识）。
     • 智能摘要：当对话轮次增多时，用一个较小的、便宜的模型（或让主模型自己）对之前的对话历史进行摘要，用摘要替换掉原始长文本，再继续对话。
     • 分层上下文策略：为不同的子任务或工具调用使用独立的、较短的上下文，而不是一个贯穿始终的巨型上下文。

3. 工具调用的错误处理与安全性：

   • 问题：Agent调用的外部工具可能失败（网络超时、API限流）、返回意外结果，甚至可能被诱导执行危险操作（如删除文件、发送邮件）。
   • 对策：
     • 工具层面的防护：每个工具函数内部必须有完备的异常捕获和日志记录。对敏感操作（写数据库、发网络请求）实施参数白名单验证和权限控制。
     • Agent层面的约束：在给LLM的工具描述中，明确说明工具的风险和限制。可以使用“沙箱”环境来运行不确定的工具代码。
     • 人工审核环节：对于高风险操作（如发布生产配置、支付操作），设计“人工确认”环节，必须由用户明确批准后才能执行。

4. 评估与调试困难：

   • 问题：传统的自动化测试方法对Agent不适用。如何评估一个自主规划、执行的Agent的好坏？
   • 对策：
     • 过程日志与可视化：详尽记录Agent的每一步思考（Chain-of-Thought）、工具调用请求和结果。使用LangSmith、Weights & Biases等平台进行可视化追踪，这是调试的基石。
     • 基于场景的端到端测试：构建一批覆盖核心和边缘用例的测试场景（“用户想订一张明天北京飞上海的机票，预算2000元以内”），运行整个Agent，评估其最终结果是否满足要求。这比单元测试更有效。
     • 模糊测试与对抗性Prompt：主动输入一些模糊、矛盾或带有误导性的用户指令，观察Agent的鲁棒性。这能暴露出很多逻辑漏洞。

7. 未来展望：融合与进化

“Code designs Harness”和“Model drives Harnesses”的界限正在变得模糊。未来的趋势不是二选一，而是两者的深度融合。

1. Harness的智能化：未来的框架（Harness）本身会集成更多AI能力。例如，框架可以自动分析任务描述，推荐或自动组装合适的工具链；可以根据历史执行日志，自动优化提示词（Prompt）或调整规划策略；甚至能动态监测模型性能，在多个LLM提供商之间进行智能路由和降级。

2. 模型的工程化：另一方面，模型（特别是Agent）的设计将更加工程化、模块化。会出现更多“开箱即用”的、针对特定领域（如代码、运维、设计）预训练和调优的Agent基础模型。构建一个应用可能像搭积木一样，组合不同的预制Agent模块，而Harness则提供标准的通信协议和协作环境。

3. 新编程范式的出现：我们可能正在见证一种新编程范式的萌芽——“提示词编程”或“自然语言编程”。在这种范式下，开发者用自然语言描述高层意图和约束（这类似于在定义Harness的“目标”），而AI负责生成或协调底层的执行代码和流程（这相当于“模型驱动”了Harness的具体实现）。像Claude Code、GPT Engineer这样的项目已经展现了这种潜力。

回到最初的问题：“Code designs Harness 还是 Model drives Harnesses？” 我的答案是：这取决于你的“第一性原理”。如果你的首要原则是确定性、可控性和可靠性，那么你应该让Code去设计Harness，让模型成为可靠的工具。如果你的首要原则是适应性、创造性和解决未知问题的能力，那么你应该致力于构建一个能充分赋能和包容模型的、灵活的Harnesses生态，让模型来驱动探索的进程。

在实际项目中，最明智的做法往往是：用“代码设计”的严谨，搭建系统的主干和护栏；用“模型驱动”的灵活，点亮那些最难编码的智能角落。两者结合，方能构建出既强大又可靠的下一代AI应用。