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框架的设计输入标准化模块接收工单原始数据可能来自网页表单、API、邮件进行清洗、去除无关字符、统一编码。预处理流水线调用固定的自然语言处理NLP步骤如分词、去除停用词、词干提取。这里可能使用像jieba、spaCy这样的确定性库。特征工程与模型调用层将预处理后的文本转化为特征向量。例如使用一个预先训练好的TF-IDF模型从joblib加载的tfidf_model.pkl将文本转换为数值特征。然后将这个特征向量输入到一个分类模型可能是传统的机器学习模型如SVM、随机森林也可能是一个轻量化的LLM嵌入模型进行预测。规则后处理层模型输出一个分类标签和置信度。Harness中会写入明确的业务规则例如如果置信度低于0.7则标记为“待人工审核”如果文本中包含“紧急”、“无法登录”等关键词则自动提升优先级。路由与执行器根据最终的分类和优先级标签调用内部API将工单分配到对应的客服队列。监控与回馈环记录每一次分类的输入、输出、置信度和最终分配结果用于后续的模型重训练和规则优化。在这个Harness中LLM或任何模型上述的tfidf_model和分类模型都只是第3步中的一个“函数调用”。它们的接口是固定的输入特征向量输出标签和分数行为被严格限定。整个系统的智能上限很大程度上取决于开发者设计的特征工程和规则逻辑是否完备。如果出现一种全新的投诉类型例如关于某个新功能的BUG除非开发者更新特征词典或添加新规则否则系统可能无法正确处理。实操心得采用“代码设计Harness”范式项目管理的复杂度相对较低因为流程是确定的。测试可以覆盖所有分支SLA服务等级协议容易保证。但它的致命弱点在于“脆弱性”。面对开放域、长尾或定义模糊的任务时需要维护一个极其庞大且不断增长的规则库和特征集技术债务会迅速累积。我曾在一个早期项目中采用这种方式处理用户意图识别最终规则文件变得比核心业务代码还长维护成本惊人。2.2 “模型驱动Harnesses”将模型视为战略核心现在让我们用“模型驱动”的视角重构同一个客服系统或者考虑一个更复杂的场景一个帮助分析师进行市场研究的AI助手。核心思路我们不再试图用代码穷举所有可能的情况和规则而是构建一个能够理解任务、自主规划、调用工具、并动态调整策略的智能体Agent。Harness在这里提供的是“能力支持”和“运行环境”而非“指令流程”。Harnesses复数框架的体现工具集ToolkitHarness提供一组定义良好的工具如“搜索最新财经新闻”、“查询公司财报数据库”、“进行情感分析”、“生成图表摘要”、“撰写分析报告草稿”。每个工具都有清晰的API描述。规划与协调层系统初始化时会将任务例如“分析新能源汽车行业未来半年的竞争格局”和可用工具的描述一并提交给一个核心的“规划型”LLM例如Claude 3 Opus或GPT-4。这个LLM作为Agent的大脑会自主生成一个执行计划“第一步搜索近期行业政策与头部公司动态第二步获取主要公司的季度财报数据第三步对比分析各公司的技术路线和市场份额第四步综合信息撰写报告。”动态执行引擎Harness中的执行引擎负责解读LLM生成的计划按顺序或根据条件调用相应的工具。关键在于这个引擎需要处理不确定性如果搜索工具返回的结果不理想引擎需要将这一信息反馈给LLM请求调整搜索策略或跳过此步。这要求Harness具备状态管理和与LLM的多轮对话能力。上下文管理与记忆Harness需要维护一个不断增长的对话上下文包含任务目标、已执行步骤、获取到的信息片段、以及LLM的中间思考过程。这直接应对了“maximum context length is 1048576 tokens”这类挑战。优秀的Harness需要具备智能的上下文压缩、摘要和优先级排序能力确保最相关的信息保留在窗口内。评估与反思层任务执行到某个阶段或完成后Harness可以调用另一个“评估型”LLM或者内置一些评估指标对当前结果进行批判性审视。例如“报告中的数据引用是否完整”“分析维度是否全面”根据评估结果Harness可以决定是否让主Agent进行修正或标记出需要人工复核的部分。在这个范式下Harness不再是“模具”而是“舞台”和“工具箱”。模型特别是作为规划核心的LLM是舞台上的主角它驱动着整个任务的推进流程。不同的任务甚至同一任务的不同执行阶段Harness被“驱动”出的形态使用的工具组合、执行路径都是不同的。注意事项“模型驱动”范式对模型能力的要求极高。你需要一个在规划、工具使用、长上下文理解方面都足够强大的LLM作为核心引擎。同时Harness的设计复杂度也急剧上升你需要处理LLM输出的非确定性它可能生成无法解析的指令、工具调用的错误处理、以及可能无限循环的规划-执行循环。一个常见的坑是没有为Agent设置清晰的“停止条件”导致它在一些细节上陷入死循环。3. 核心技术栈与工具选型解析选择不同的范式意味着选择不同的技术栈和工具。下面我们来具体拆解。3.1 “代码设计Harness”的典型技术栈这种范式下的技术选型偏向于传统软件工程与机器学习OpsMLOps的结合强调稳定、可控和高效。核心框架与运行时FastAPI / Flask用于构建清晰、高效的API服务层定义严格的输入/输出模式Pydantic Models这是Harness的“外壳”。Celery / Dramatiq对于耗时较长的模型推理或批处理任务引入异步任务队列保证主服务的响应性。工作流引擎对于流程复杂的任务可以使用Prefect或Airflow来编排固定的处理流水线。每个节点任务都是确定的函数。模型部署与集成模型格式倾向于使用标准化格式如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) 进行高性能部署。状态与配置管理系统的状态如工单处理到哪一步通常保存在外部数据库PostgreSQL,Redis中由Harness的逻辑代码完全掌控。配置如分类阈值、路由规则使用YAML文件或配置管理服务如Consul更改配置需要重新部署或热加载。监控与评估使用PrometheusGrafana监控API延迟、模型调用次数、错误率等指标。评估依赖于人工标注的测试集和预定义的业务指标准确率、召回率、F1值、平均处理时间。工具选型理由这套栈的核心思想是“控制”。每一个环节都有成熟的、可预测的工业级工具。系统的行为不依赖于某个黑盒模型的一次随机输出而是由代码逻辑和配置完全定义。这非常适合对可靠性要求极高、任务边界清晰的场景如金融风控、内容安全过滤、标准化文档处理。3.2 “模型驱动Harnesses”的典型技术栈这种范式则深度拥抱AI原生理念技术栈围绕LLM和Agent的能力构建。Agent框架与编排LangChain / LangGraph这是目前最流行的选择。LangChain提供了大量的工具集成、模板和记忆组件能快速搭建Agent原型。LangGraph在此基础上引入了基于图的状态机概念非常适合描述Agent复杂的、有分支循环的决策流程。它允许你定义“节点”工具调用或LLM调用和“边”条件流转Harness的形态由此图定义但具体的执行路径由LLM在运行时决定。AutoGen由微软推出擅长构建多智能体协作系统。你可以定义不同的Agent角色程序员、测试员、产品经理它们通过对话协同完成任务。Harness在这里体现为定义角色、设定交互协议和提供共享状态。Semantic Kernel/Dify前者是微软的另一个框架强调将传统代码技能与LLM语义技能“插件化”结合后者更像一个低代码平台通过可视化工作流Workflow来编排LLM和工具其“workflow将LLM输出的内容保存到一个word文档”正是这种思想的体现。核心模型服务高性能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最大边际相关性。工具与技能抽象工具被抽象为具有标准描述名称、描述、参数schema的函数。框架如LangChain提供了tool装饰器来简化创建。需要为工具调用设计鲁棒的错误处理与重试机制。例如一个搜索工具可能因网络问题失败Harness应能捕获异常并决定是重试、换用备用工具还是将问题反馈给LLM重新规划。状态、记忆与持久化Agent的状态对话历史、中间结果、工具执行记录管理至关重要。简单的可以使用内存存储复杂的需要持久化到数据库。LangChain提供了多种Memory后端。需要考虑上下文窗口限制。当对话或任务历史超过模型限制时需要智能的摘要策略如通过另一个LLM总结关键信息或分层记忆系统。评估与调试评估变得异常困难。无法再用简单的准确率衡量。需要结合过程评估Agent的决策步骤是否合理和结果评估最终产出质量如何。TruLens、Phoenix等工具开始提供针对LLM应用的可观测性。调试更像是在“教书”或“调教”一个智能体需要分析它的思考链Chain-of-Thought修正工具描述或提供更好的示例Few-shot Examples。工具选型理由这套栈的核心思想是“赋能”和“协作”。框架的目标是最大化释放LLM的潜力让它能灵活运用各种工具解决问题。技术选型的重点是那些能良好支持动态性、交互性和长上下文管理的组件。它适合探索性、创造性或流程无法预先完全定义的任务如智能编程助手、复杂研究分析、开放域对话机器人。4. 实战场景对比与架构设计让我们通过两个更具体的并行案例来感受两种范式在架构设计上的根本差异。4.1 场景一智能代码审查助手目标开发一个能自动审查Pull RequestPR中代码质量、安全性和规范符合性的助手。方案A代码设计Harness架构事件触发器通过GitHub Webhook监听PR创建/更新事件。静态分析管道Harness启动一个固定流水线。调用SonarQube或CodeQL进行静态代码安全扫描。调用Pylint/ESLint进行代码风格和语法检查。调用自定义脚本检查提交信息规范、文件命名约定等。结果聚合器收集所有静态分析工具的报告按照预定义的规则如存在高危漏洞则阻塞风格问题超过10个则警告进行汇总。评论生成器使用一个模板引擎将汇总结果填充到固定的Markdown模板中生成评论并提交到PR。特点审查项完全固定规则明确。新增一种检查如检查是否使用了某个废弃的API需要开发新的脚本并集成到管道中。系统行为完全可预测。方案B模型驱动Harnesses架构事件与上下文构建收到PR事件后Harness不仅获取代码Diff还会自动获取相关的需求文档、过往类似PR的讨论、项目编码规范文档构建一个丰富的上下文包。智能体激活将上下文包和任务指令“请全面审查此PR”发送给一个具备代码理解能力的LLM Agent如基于Claude 3或GPT-4 Code Interpreter构建。自主审查循环Agent首先理解变更意图阅读Diff和关联文档。然后规划审查重点它可能决定先检查核心逻辑再查看边界条件最后审查错误处理。在审查过程中它可以动态调用工具比如对某段复杂的算法调用一个代码解释工具来验证逻辑对某个数据库操作调用SQL分析工具检查潜在的性能问题对某个外部API调用检查项目中是否有对应的Mock或测试。它还可以进行知识检索从向量数据库中查询类似的代码片段及其审查意见作为参考。报告生成与交互Agent生成一份结构化的审查报告不仅列出问题还会解释问题的严重性、给出修改建议甚至能生成示例代码。它可以将报告以评论形式发布并能响应后续的开发者追问进行多轮交互式讨论。特点审查范围动态、深入能结合项目上下文和开发者意图。能处理规则未覆盖的复杂逻辑问题。但审查耗时可能更长且结果有一定不可预测性取决于LLM的发挥。4.2 场景二客户服务对话系统目标构建一个能处理多轮对话、解决复杂问题的在线客服系统。方案A代码设计Harness架构经典的“意图识别 - 槽位填充 - 对话状态管理 - 执行/回复”流水线。NLU模块使用训练好的意图分类模型和命名实体识别NER模型处理用户语句。对话状态跟踪器DST一个维护着当前对话状态如用户在办理什么业务、已收集哪些信息的代码模块。对话策略模块Policy基于当前状态和NLU结果根据预编写的策略树if-else或有限状态机决定下一步动作如询问更多信息、调用API、回复固定话术。自然语言生成NLG根据策略模块的指令从模板库中选择或生成回复文本。特点对于封闭域、流程固定的业务如查话费、改套餐效率高且稳定。但扩展性差增加一个新业务需要重新标注数据、训练模型、编写策略成本高昂。方案B模型驱动Harnesses架构以LLM为核心的多技能智能体。中央对话引擎一个强大的LLM作为对话主脑维护整个对话历史和上下文。技能工具库Harness提供一系列技能如“查询订单状态API”、“计算费用折扣API”、“生成服务满意度问卷”、“转接人工坐席协议”。动态规划与执行每轮用户输入后LLM分析当前对话状态和用户需求自主决定是否需要调用某个技能、需要询问什么信息来补全技能参数、或是直接生成回复。例如用户说“我想退掉昨天买的手机”LLM可能规划先调用“查询最新订单”技能确认订单详情和退货政策再调用“发起退货流程”技能最后生成回复告知用户下一步操作。记忆与个性化利用向量数据库存储历史对话摘要实现跨会话的记忆提供个性化服务如“您上次反映的XX问题解决了吗”。特点能处理开放域、多跳的复杂查询对话自然灵活。添加新技能只需定义好API接口和描述无需修改核心对话逻辑。但对LLM的推理能力、工具调用的可靠性要求极高且单次交互成本更高。5. 决策指南如何为你的项目选择范式面对两种范式如何做出选择这并非非此即彼而是一个光谱。你可以根据项目的核心维度进行定位。评估维度更适合“代码设计Harness”更适合“模型驱动Harnesses”任务确定性高。输入输出格式固定处理逻辑可被完整描述。低。任务边界模糊需要推理、规划或创造性解决。变更频率低。业务规则和流程相对稳定。高。需要快速适应新需求、新工具或新知识。可解释性要求高。每一步决策都必须有明确的规则或数据依据用于审计和合规。中/低。更关注最终结果允许一定程度的“黑箱”推理过程。性能与成本要求高吞吐、低延迟、低成本。确定性模型和规则引擎效率极高。可接受较高的延迟和单次调用成本以换取更强的能力。错误容忍度低。错误可能导致严重业务后果如金融交易错误。相对较高。错误通常可被后续交互纠正或影响范围有限。团队技能强于传统软件工程、数据管道和MLOps。强于提示工程、Agent设计、大模型应用开发和评估。启动速度初期搭建框架较快但覆盖长尾案例的后期成本高。初期搭建和调优较慢需要设计工具、调教Agent但扩展新能力相对快。混合模式Hybrid Approach在实际项目中纯粹的两种范式往往并存形成混合架构。外层模型驱动内层代码设计一个用于复杂任务拆解的Agent模型驱动在拆解出的子任务中调用一个高度优化的、规则化的数据处理服务代码设计。例如研究Agent规划出“获取A公司股价”的任务然后调用一个稳定的金融数据API客户端。代码设计框架中嵌入模型能力在一个以规则为主的客服系统中引入一个LLM模块专门处理“其他”类别或进行情感分析作为现有流程的补充和增强。个人经验与建议不要盲目追求“模型驱动”的时髦。我见过很多团队在业务逻辑本身非常清晰的情况下强行上马Agent框架结果引入了巨大的复杂性和不稳定性得不偿失。一个实用的切入点是从“代码设计Harness”开始识别其中最僵化、最易变、最需要智能的环节将其剥离出来用“模型驱动”的思路进行改造将其变成一个由模型驱动的“智能子模块”。例如先构建一个规则化的工单分类器然后发现“紧急程度判断”这个子任务规则很难写全再用一个微调的小模型或Prompt精巧的LLM来负责这部分。这样既能享受AI带来的灵活性提升又能将风险和控制力掌握在核心框架手中。6. 实施挑战与避坑指南无论选择哪种范式在实施过程中都会遇到一系列挑战。以下是一些常见的“坑”及应对策略。6.1 “代码设计Harness”的典型挑战规则爆炸与维护地狱问题随着业务复杂if-else规则或特征工程代码指数级增长难以理解和维护。对策引入决策表或规则引擎如Drools来外部化管理业务规则。定期进行规则审计和简化。积极探索将部分稳定、可标注的规则转化为轻量级机器学习模型实现从“硬规则”到“软模型”的渐进过渡。面对未知输入的脆弱性问题系统对训练数据分布外的输入OOD处理能力差容易产生荒谬输出或直接崩溃。对策必须在Harness中设计强大的输入验证和异常处理层。对于无法处理的输入必须有清晰的降级策略如返回“我需要更多信息”或转交人工。建立监控持续收集这些“未知输入”用于迭代改进系统。模型更新与迭代成本高问题每次更新模型即使是替换为同架构的更优版本都需要重新测试整个流水线确保接口兼容性和性能表现。对策采用严格的模型版本化和契约测试。使用模型注册表如MLflow管理版本。Harness通过模型别名如production-model引用模型而非具体版本号便于滚动更新和快速回滚。6.2 “模型驱动Harnesses”的典型挑战LLM输出的非确定性与可靠性问题LLM可能生成格式错误、无法解析的JSON可能“幻觉”出不存在的工具或参数可能陷入循环思考。对策结构化输出强制要求LLM使用JSON、XML或YAML等格式输出并使用Pydantic等库进行严格验证。像LangChain的StructuredOutputParser就很好用。重试与降级设计自动重试机制如尝试重新Prompt、让模型修正输出。设定最大重试次数失败后转入降级流程如执行一个默认操作或请求人工干预。思维链CoT与自我验证鼓励LLM展示其推理步骤“Let‘s think step by step”并在关键决策点加入自我验证提示“请检查你刚才的规划是否符合工具A的输入要求”。上下文管理与成本控制问题长对话或多步骤任务极易耗尽模型的上下文窗口遇到maximum context length错误。同时长上下文调用API成本高昂。对策选择性上下文不要无脑地将所有历史对话都塞进上下文。实现一个记忆管理系统区分核心记忆任务目标、关键决策、近期记忆最近几轮对话和长期记忆存入向量数据库的可检索知识。智能摘要当对话轮次增多时用一个较小的、便宜的模型或让主模型自己对之前的对话历史进行摘要用摘要替换掉原始长文本再继续对话。分层上下文策略为不同的子任务或工具调用使用独立的、较短的上下文而不是一个贯穿始终的巨型上下文。工具调用的错误处理与安全性问题Agent调用的外部工具可能失败网络超时、API限流、返回意外结果甚至可能被诱导执行危险操作如删除文件、发送邮件。对策工具层面的防护每个工具函数内部必须有完备的异常捕获和日志记录。对敏感操作写数据库、发网络请求实施参数白名单验证和权限控制。Agent层面的约束在给LLM的工具描述中明确说明工具的风险和限制。可以使用“沙箱”环境来运行不确定的工具代码。人工审核环节对于高风险操作如发布生产配置、支付操作设计“人工确认”环节必须由用户明确批准后才能执行。评估与调试困难问题传统的自动化测试方法对Agent不适用。如何评估一个自主规划、执行的Agent的好坏对策过程日志与可视化详尽记录Agent的每一步思考Chain-of-Thought、工具调用请求和结果。使用LangSmith、Weights Biases等平台进行可视化追踪这是调试的基石。基于场景的端到端测试构建一批覆盖核心和边缘用例的测试场景“用户想订一张明天北京飞上海的机票预算2000元以内”运行整个Agent评估其最终结果是否满足要求。这比单元测试更有效。模糊测试与对抗性Prompt主动输入一些模糊、矛盾或带有误导性的用户指令观察Agent的鲁棒性。这能暴露出很多逻辑漏洞。7. 未来展望融合与进化“Code designs Harness”和“Model drives Harnesses”的界限正在变得模糊。未来的趋势不是二选一而是两者的深度融合。Harness的智能化未来的框架Harness本身会集成更多AI能力。例如框架可以自动分析任务描述推荐或自动组装合适的工具链可以根据历史执行日志自动优化提示词Prompt或调整规划策略甚至能动态监测模型性能在多个LLM提供商之间进行智能路由和降级。模型的工程化另一方面模型特别是Agent的设计将更加工程化、模块化。会出现更多“开箱即用”的、针对特定领域如代码、运维、设计预训练和调优的Agent基础模型。构建一个应用可能像搭积木一样组合不同的预制Agent模块而Harness则提供标准的通信协议和协作环境。新编程范式的出现我们可能正在见证一种新编程范式的萌芽——“提示词编程”或“自然语言编程”。在这种范式下开发者用自然语言描述高层意图和约束这类似于在定义Harness的“目标”而AI负责生成或协调底层的执行代码和流程这相当于“模型驱动”了Harness的具体实现。像Claude Code、GPT Engineer这样的项目已经展现了这种潜力。回到最初的问题“Code designs Harness 还是 Model drives Harnesses” 我的答案是这取决于你的“第一性原理”。如果你的首要原则是确定性、可控性和可靠性那么你应该让Code去设计Harness让模型成为可靠的工具。如果你的首要原则是适应性、创造性和解决未知问题的能力那么你应该致力于构建一个能充分赋能和包容模型的、灵活的Harnesses生态让模型来驱动探索的进程。在实际项目中最明智的做法往往是用“代码设计”的严谨搭建系统的主干和护栏用“模型驱动”的灵活点亮那些最难编码的智能角落。两者结合方能构建出既强大又可靠的下一代AI应用。 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框架的设计输入标准化模块接收工单原始数据可能来自网页表单、API、邮件进行清洗、去除无关字符、统一编码。预处理流水线调用固定的自然语言处理NLP步骤如分词、去除停用词、词干提取。这里可能使用像jieba、spaCy这样的确定性库。特征工程与模型调用层将预处理后的文本转化为特征向量。例如使用一个预先训练好的TF-IDF模型从joblib加载的tfidf_model.pkl将文本转换为数值特征。然后将这个特征向量输入到一个分类模型可能是传统的机器学习模型如SVM、随机森林也可能是一个轻量化的LLM嵌入模型进行预测。规则后处理层模型输出一个分类标签和置信度。Harness中会写入明确的业务规则例如如果置信度低于0.7则标记为“待人工审核”如果文本中包含“紧急”、“无法登录”等关键词则自动提升优先级。路由与执行器根据最终的分类和优先级标签调用内部API将工单分配到对应的客服队列。监控与回馈环记录每一次分类的输入、输出、置信度和最终分配结果用于后续的模型重训练和规则优化。在这个Harness中LLM或任何模型上述的tfidf_model和分类模型都只是第3步中的一个“函数调用”。它们的接口是固定的输入特征向量输出标签和分数行为被严格限定。整个系统的智能上限很大程度上取决于开发者设计的特征工程和规则逻辑是否完备。如果出现一种全新的投诉类型例如关于某个新功能的BUG除非开发者更新特征词典或添加新规则否则系统可能无法正确处理。实操心得采用“代码设计Harness”范式项目管理的复杂度相对较低因为流程是确定的。测试可以覆盖所有分支SLA服务等级协议容易保证。但它的致命弱点在于“脆弱性”。面对开放域、长尾或定义模糊的任务时需要维护一个极其庞大且不断增长的规则库和特征集技术债务会迅速累积。我曾在一个早期项目中采用这种方式处理用户意图识别最终规则文件变得比核心业务代码还长维护成本惊人。2.2 “模型驱动Harnesses”将模型视为战略核心现在让我们用“模型驱动”的视角重构同一个客服系统或者考虑一个更复杂的场景一个帮助分析师进行市场研究的AI助手。核心思路我们不再试图用代码穷举所有可能的情况和规则而是构建一个能够理解任务、自主规划、调用工具、并动态调整策略的智能体Agent。Harness在这里提供的是“能力支持”和“运行环境”而非“指令流程”。Harnesses复数框架的体现工具集ToolkitHarness提供一组定义良好的工具如“搜索最新财经新闻”、“查询公司财报数据库”、“进行情感分析”、“生成图表摘要”、“撰写分析报告草稿”。每个工具都有清晰的API描述。规划与协调层系统初始化时会将任务例如“分析新能源汽车行业未来半年的竞争格局”和可用工具的描述一并提交给一个核心的“规划型”LLM例如Claude 3 Opus或GPT-4。这个LLM作为Agent的大脑会自主生成一个执行计划“第一步搜索近期行业政策与头部公司动态第二步获取主要公司的季度财报数据第三步对比分析各公司的技术路线和市场份额第四步综合信息撰写报告。”动态执行引擎Harness中的执行引擎负责解读LLM生成的计划按顺序或根据条件调用相应的工具。关键在于这个引擎需要处理不确定性如果搜索工具返回的结果不理想引擎需要将这一信息反馈给LLM请求调整搜索策略或跳过此步。这要求Harness具备状态管理和与LLM的多轮对话能力。上下文管理与记忆Harness需要维护一个不断增长的对话上下文包含任务目标、已执行步骤、获取到的信息片段、以及LLM的中间思考过程。这直接应对了“maximum context length is 1048576 tokens”这类挑战。优秀的Harness需要具备智能的上下文压缩、摘要和优先级排序能力确保最相关的信息保留在窗口内。评估与反思层任务执行到某个阶段或完成后Harness可以调用另一个“评估型”LLM或者内置一些评估指标对当前结果进行批判性审视。例如“报告中的数据引用是否完整”“分析维度是否全面”根据评估结果Harness可以决定是否让主Agent进行修正或标记出需要人工复核的部分。在这个范式下Harness不再是“模具”而是“舞台”和“工具箱”。模型特别是作为规划核心的LLM是舞台上的主角它驱动着整个任务的推进流程。不同的任务甚至同一任务的不同执行阶段Harness被“驱动”出的形态使用的工具组合、执行路径都是不同的。注意事项“模型驱动”范式对模型能力的要求极高。你需要一个在规划、工具使用、长上下文理解方面都足够强大的LLM作为核心引擎。同时Harness的设计复杂度也急剧上升你需要处理LLM输出的非确定性它可能生成无法解析的指令、工具调用的错误处理、以及可能无限循环的规划-执行循环。一个常见的坑是没有为Agent设置清晰的“停止条件”导致它在一些细节上陷入死循环。3. 核心技术栈与工具选型解析选择不同的范式意味着选择不同的技术栈和工具。下面我们来具体拆解。3.1 “代码设计Harness”的典型技术栈这种范式下的技术选型偏向于传统软件工程与机器学习OpsMLOps的结合强调稳定、可控和高效。核心框架与运行时FastAPI / Flask用于构建清晰、高效的API服务层定义严格的输入/输出模式Pydantic Models这是Harness的“外壳”。Celery / Dramatiq对于耗时较长的模型推理或批处理任务引入异步任务队列保证主服务的响应性。工作流引擎对于流程复杂的任务可以使用Prefect或Airflow来编排固定的处理流水线。每个节点任务都是确定的函数。模型部署与集成模型格式倾向于使用标准化格式如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) 进行高性能部署。状态与配置管理系统的状态如工单处理到哪一步通常保存在外部数据库PostgreSQL,Redis中由Harness的逻辑代码完全掌控。配置如分类阈值、路由规则使用YAML文件或配置管理服务如Consul更改配置需要重新部署或热加载。监控与评估使用PrometheusGrafana监控API延迟、模型调用次数、错误率等指标。评估依赖于人工标注的测试集和预定义的业务指标准确率、召回率、F1值、平均处理时间。工具选型理由这套栈的核心思想是“控制”。每一个环节都有成熟的、可预测的工业级工具。系统的行为不依赖于某个黑盒模型的一次随机输出而是由代码逻辑和配置完全定义。这非常适合对可靠性要求极高、任务边界清晰的场景如金融风控、内容安全过滤、标准化文档处理。3.2 “模型驱动Harnesses”的典型技术栈这种范式则深度拥抱AI原生理念技术栈围绕LLM和Agent的能力构建。Agent框架与编排LangChain / LangGraph这是目前最流行的选择。LangChain提供了大量的工具集成、模板和记忆组件能快速搭建Agent原型。LangGraph在此基础上引入了基于图的状态机概念非常适合描述Agent复杂的、有分支循环的决策流程。它允许你定义“节点”工具调用或LLM调用和“边”条件流转Harness的形态由此图定义但具体的执行路径由LLM在运行时决定。AutoGen由微软推出擅长构建多智能体协作系统。你可以定义不同的Agent角色程序员、测试员、产品经理它们通过对话协同完成任务。Harness在这里体现为定义角色、设定交互协议和提供共享状态。Semantic Kernel/Dify前者是微软的另一个框架强调将传统代码技能与LLM语义技能“插件化”结合后者更像一个低代码平台通过可视化工作流Workflow来编排LLM和工具其“workflow将LLM输出的内容保存到一个word文档”正是这种思想的体现。核心模型服务高性能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最大边际相关性。工具与技能抽象工具被抽象为具有标准描述名称、描述、参数schema的函数。框架如LangChain提供了tool装饰器来简化创建。需要为工具调用设计鲁棒的错误处理与重试机制。例如一个搜索工具可能因网络问题失败Harness应能捕获异常并决定是重试、换用备用工具还是将问题反馈给LLM重新规划。状态、记忆与持久化Agent的状态对话历史、中间结果、工具执行记录管理至关重要。简单的可以使用内存存储复杂的需要持久化到数据库。LangChain提供了多种Memory后端。需要考虑上下文窗口限制。当对话或任务历史超过模型限制时需要智能的摘要策略如通过另一个LLM总结关键信息或分层记忆系统。评估与调试评估变得异常困难。无法再用简单的准确率衡量。需要结合过程评估Agent的决策步骤是否合理和结果评估最终产出质量如何。TruLens、Phoenix等工具开始提供针对LLM应用的可观测性。调试更像是在“教书”或“调教”一个智能体需要分析它的思考链Chain-of-Thought修正工具描述或提供更好的示例Few-shot Examples。工具选型理由这套栈的核心思想是“赋能”和“协作”。框架的目标是最大化释放LLM的潜力让它能灵活运用各种工具解决问题。技术选型的重点是那些能良好支持动态性、交互性和长上下文管理的组件。它适合探索性、创造性或流程无法预先完全定义的任务如智能编程助手、复杂研究分析、开放域对话机器人。4. 实战场景对比与架构设计让我们通过两个更具体的并行案例来感受两种范式在架构设计上的根本差异。4.1 场景一智能代码审查助手目标开发一个能自动审查Pull RequestPR中代码质量、安全性和规范符合性的助手。方案A代码设计Harness架构事件触发器通过GitHub Webhook监听PR创建/更新事件。静态分析管道Harness启动一个固定流水线。调用SonarQube或CodeQL进行静态代码安全扫描。调用Pylint/ESLint进行代码风格和语法检查。调用自定义脚本检查提交信息规范、文件命名约定等。结果聚合器收集所有静态分析工具的报告按照预定义的规则如存在高危漏洞则阻塞风格问题超过10个则警告进行汇总。评论生成器使用一个模板引擎将汇总结果填充到固定的Markdown模板中生成评论并提交到PR。特点审查项完全固定规则明确。新增一种检查如检查是否使用了某个废弃的API需要开发新的脚本并集成到管道中。系统行为完全可预测。方案B模型驱动Harnesses架构事件与上下文构建收到PR事件后Harness不仅获取代码Diff还会自动获取相关的需求文档、过往类似PR的讨论、项目编码规范文档构建一个丰富的上下文包。智能体激活将上下文包和任务指令“请全面审查此PR”发送给一个具备代码理解能力的LLM Agent如基于Claude 3或GPT-4 Code Interpreter构建。自主审查循环Agent首先理解变更意图阅读Diff和关联文档。然后规划审查重点它可能决定先检查核心逻辑再查看边界条件最后审查错误处理。在审查过程中它可以动态调用工具比如对某段复杂的算法调用一个代码解释工具来验证逻辑对某个数据库操作调用SQL分析工具检查潜在的性能问题对某个外部API调用检查项目中是否有对应的Mock或测试。它还可以进行知识检索从向量数据库中查询类似的代码片段及其审查意见作为参考。报告生成与交互Agent生成一份结构化的审查报告不仅列出问题还会解释问题的严重性、给出修改建议甚至能生成示例代码。它可以将报告以评论形式发布并能响应后续的开发者追问进行多轮交互式讨论。特点审查范围动态、深入能结合项目上下文和开发者意图。能处理规则未覆盖的复杂逻辑问题。但审查耗时可能更长且结果有一定不可预测性取决于LLM的发挥。4.2 场景二客户服务对话系统目标构建一个能处理多轮对话、解决复杂问题的在线客服系统。方案A代码设计Harness架构经典的“意图识别 - 槽位填充 - 对话状态管理 - 执行/回复”流水线。NLU模块使用训练好的意图分类模型和命名实体识别NER模型处理用户语句。对话状态跟踪器DST一个维护着当前对话状态如用户在办理什么业务、已收集哪些信息的代码模块。对话策略模块Policy基于当前状态和NLU结果根据预编写的策略树if-else或有限状态机决定下一步动作如询问更多信息、调用API、回复固定话术。自然语言生成NLG根据策略模块的指令从模板库中选择或生成回复文本。特点对于封闭域、流程固定的业务如查话费、改套餐效率高且稳定。但扩展性差增加一个新业务需要重新标注数据、训练模型、编写策略成本高昂。方案B模型驱动Harnesses架构以LLM为核心的多技能智能体。中央对话引擎一个强大的LLM作为对话主脑维护整个对话历史和上下文。技能工具库Harness提供一系列技能如“查询订单状态API”、“计算费用折扣API”、“生成服务满意度问卷”、“转接人工坐席协议”。动态规划与执行每轮用户输入后LLM分析当前对话状态和用户需求自主决定是否需要调用某个技能、需要询问什么信息来补全技能参数、或是直接生成回复。例如用户说“我想退掉昨天买的手机”LLM可能规划先调用“查询最新订单”技能确认订单详情和退货政策再调用“发起退货流程”技能最后生成回复告知用户下一步操作。记忆与个性化利用向量数据库存储历史对话摘要实现跨会话的记忆提供个性化服务如“您上次反映的XX问题解决了吗”。特点能处理开放域、多跳的复杂查询对话自然灵活。添加新技能只需定义好API接口和描述无需修改核心对话逻辑。但对LLM的推理能力、工具调用的可靠性要求极高且单次交互成本更高。5. 决策指南如何为你的项目选择范式面对两种范式如何做出选择这并非非此即彼而是一个光谱。你可以根据项目的核心维度进行定位。评估维度更适合“代码设计Harness”更适合“模型驱动Harnesses”任务确定性高。输入输出格式固定处理逻辑可被完整描述。低。任务边界模糊需要推理、规划或创造性解决。变更频率低。业务规则和流程相对稳定。高。需要快速适应新需求、新工具或新知识。可解释性要求高。每一步决策都必须有明确的规则或数据依据用于审计和合规。中/低。更关注最终结果允许一定程度的“黑箱”推理过程。性能与成本要求高吞吐、低延迟、低成本。确定性模型和规则引擎效率极高。可接受较高的延迟和单次调用成本以换取更强的能力。错误容忍度低。错误可能导致严重业务后果如金融交易错误。相对较高。错误通常可被后续交互纠正或影响范围有限。团队技能强于传统软件工程、数据管道和MLOps。强于提示工程、Agent设计、大模型应用开发和评估。启动速度初期搭建框架较快但覆盖长尾案例的后期成本高。初期搭建和调优较慢需要设计工具、调教Agent但扩展新能力相对快。混合模式Hybrid Approach在实际项目中纯粹的两种范式往往并存形成混合架构。外层模型驱动内层代码设计一个用于复杂任务拆解的Agent模型驱动在拆解出的子任务中调用一个高度优化的、规则化的数据处理服务代码设计。例如研究Agent规划出“获取A公司股价”的任务然后调用一个稳定的金融数据API客户端。代码设计框架中嵌入模型能力在一个以规则为主的客服系统中引入一个LLM模块专门处理“其他”类别或进行情感分析作为现有流程的补充和增强。个人经验与建议不要盲目追求“模型驱动”的时髦。我见过很多团队在业务逻辑本身非常清晰的情况下强行上马Agent框架结果引入了巨大的复杂性和不稳定性得不偿失。一个实用的切入点是从“代码设计Harness”开始识别其中最僵化、最易变、最需要智能的环节将其剥离出来用“模型驱动”的思路进行改造将其变成一个由模型驱动的“智能子模块”。例如先构建一个规则化的工单分类器然后发现“紧急程度判断”这个子任务规则很难写全再用一个微调的小模型或Prompt精巧的LLM来负责这部分。这样既能享受AI带来的灵活性提升又能将风险和控制力掌握在核心框架手中。6. 实施挑战与避坑指南无论选择哪种范式在实施过程中都会遇到一系列挑战。以下是一些常见的“坑”及应对策略。6.1 “代码设计Harness”的典型挑战规则爆炸与维护地狱问题随着业务复杂if-else规则或特征工程代码指数级增长难以理解和维护。对策引入决策表或规则引擎如Drools来外部化管理业务规则。定期进行规则审计和简化。积极探索将部分稳定、可标注的规则转化为轻量级机器学习模型实现从“硬规则”到“软模型”的渐进过渡。面对未知输入的脆弱性问题系统对训练数据分布外的输入OOD处理能力差容易产生荒谬输出或直接崩溃。对策必须在Harness中设计强大的输入验证和异常处理层。对于无法处理的输入必须有清晰的降级策略如返回“我需要更多信息”或转交人工。建立监控持续收集这些“未知输入”用于迭代改进系统。模型更新与迭代成本高问题每次更新模型即使是替换为同架构的更优版本都需要重新测试整个流水线确保接口兼容性和性能表现。对策采用严格的模型版本化和契约测试。使用模型注册表如MLflow管理版本。Harness通过模型别名如production-model引用模型而非具体版本号便于滚动更新和快速回滚。6.2 “模型驱动Harnesses”的典型挑战LLM输出的非确定性与可靠性问题LLM可能生成格式错误、无法解析的JSON可能“幻觉”出不存在的工具或参数可能陷入循环思考。对策结构化输出强制要求LLM使用JSON、XML或YAML等格式输出并使用Pydantic等库进行严格验证。像LangChain的StructuredOutputParser就很好用。重试与降级设计自动重试机制如尝试重新Prompt、让模型修正输出。设定最大重试次数失败后转入降级流程如执行一个默认操作或请求人工干预。思维链CoT与自我验证鼓励LLM展示其推理步骤“Let‘s think step by step”并在关键决策点加入自我验证提示“请检查你刚才的规划是否符合工具A的输入要求”。上下文管理与成本控制问题长对话或多步骤任务极易耗尽模型的上下文窗口遇到maximum context length错误。同时长上下文调用API成本高昂。对策选择性上下文不要无脑地将所有历史对话都塞进上下文。实现一个记忆管理系统区分核心记忆任务目标、关键决策、近期记忆最近几轮对话和长期记忆存入向量数据库的可检索知识。智能摘要当对话轮次增多时用一个较小的、便宜的模型或让主模型自己对之前的对话历史进行摘要用摘要替换掉原始长文本再继续对话。分层上下文策略为不同的子任务或工具调用使用独立的、较短的上下文而不是一个贯穿始终的巨型上下文。工具调用的错误处理与安全性问题Agent调用的外部工具可能失败网络超时、API限流、返回意外结果甚至可能被诱导执行危险操作如删除文件、发送邮件。对策工具层面的防护每个工具函数内部必须有完备的异常捕获和日志记录。对敏感操作写数据库、发网络请求实施参数白名单验证和权限控制。Agent层面的约束在给LLM的工具描述中明确说明工具的风险和限制。可以使用“沙箱”环境来运行不确定的工具代码。人工审核环节对于高风险操作如发布生产配置、支付操作设计“人工确认”环节必须由用户明确批准后才能执行。评估与调试困难问题传统的自动化测试方法对Agent不适用。如何评估一个自主规划、执行的Agent的好坏对策过程日志与可视化详尽记录Agent的每一步思考Chain-of-Thought、工具调用请求和结果。使用LangSmith、Weights Biases等平台进行可视化追踪这是调试的基石。基于场景的端到端测试构建一批覆盖核心和边缘用例的测试场景“用户想订一张明天北京飞上海的机票预算2000元以内”运行整个Agent评估其最终结果是否满足要求。这比单元测试更有效。模糊测试与对抗性Prompt主动输入一些模糊、矛盾或带有误导性的用户指令观察Agent的鲁棒性。这能暴露出很多逻辑漏洞。7. 未来展望融合与进化“Code designs Harness”和“Model drives Harnesses”的界限正在变得模糊。未来的趋势不是二选一而是两者的深度融合。Harness的智能化未来的框架Harness本身会集成更多AI能力。例如框架可以自动分析任务描述推荐或自动组装合适的工具链可以根据历史执行日志自动优化提示词Prompt或调整规划策略甚至能动态监测模型性能在多个LLM提供商之间进行智能路由和降级。模型的工程化另一方面模型特别是Agent的设计将更加工程化、模块化。会出现更多“开箱即用”的、针对特定领域如代码、运维、设计预训练和调优的Agent基础模型。构建一个应用可能像搭积木一样组合不同的预制Agent模块而Harness则提供标准的通信协议和协作环境。新编程范式的出现我们可能正在见证一种新编程范式的萌芽——“提示词编程”或“自然语言编程”。在这种范式下开发者用自然语言描述高层意图和约束这类似于在定义Harness的“目标”而AI负责生成或协调底层的执行代码和流程这相当于“模型驱动”了Harness的具体实现。像Claude Code、GPT Engineer这样的项目已经展现了这种潜力。回到最初的问题“Code designs Harness 还是 Model drives Harnesses” 我的答案是这取决于你的“第一性原理”。如果你的首要原则是确定性、可控性和可靠性那么你应该让Code去设计Harness让模型成为可靠的工具。如果你的首要原则是适应性、创造性和解决未知问题的能力那么你应该致力于构建一个能充分赋能和包容模型的、灵活的Harnesses生态让模型来驱动探索的进程。在实际项目中最明智的做法往往是用“代码设计”的严谨搭建系统的主干和护栏用“模型驱动”的灵活点亮那些最难编码的智能角落。两者结合方能构建出既强大又可靠的下一代AI应用。