Harness工程：LLM是大脑，Harness是身体

当我们在谈论LLM时，我们在忽略什么

HN上出现了一个只有39个点、17条评论的帖子，标题却精准得让人停下来：Harness Engineering 101: The LLM is the brain, the harness is the body。没有大厂的PR稿，没有融资新闻，但这恰恰是当下AI应用层最需要被系统讨论的一个概念。

大模型本身不解决任何端到端问题。它不会记住你上一轮对话的上下文（除非框架替它记住），不会调用API，不会在没有工具的情况下读取数据库，更不会主动重试失败的操作。所有这些「让模型真正干活」的工程层，就是harness——或者按中文语境更准确的说法，「脚手架」「执行框架」。文章用了一个极简的比喻：LLM是大脑，harness是身体。大脑再聪明，没有身体去感知和行动，就只是悬空的推理机器。

Harness到底包含哪些东西

如果把LLM当作一个无状态的函数，harness就是包在它外面的那层状态管理与工具执行系统。拆开来看，至少包含四层：

第一层是上下文编排。 模型每次调用只能看到当前的token窗口。谁来决定塞什么进去、按什么顺序塞、何时做摘要压缩、何时丢弃旧信息，全是harness的工作。同一个模型，在两个不同的上下文管理策略下，表现可以差出几个档次。

第二层是工具接口。 函数调用、MCP、代码解释器、浏览器控制——模型本身只会输出结构化的调用意图，真正执行、处理异常、把结果格式化回模型可读的形式，都是harness在做。工具描述怎么写、返回结果要不要截断、错误信息以什么格式回传，这些细节直接决定模型能否正确使用工具。

第三层是控制流。 一个任务需要多少步、什么时候该继续循环、什么时候该停下来问人、失败了重试几次、并行还是串行——这些不属于模型推理的范畴，而是harness的决策逻辑。ReAct、Plan-and-Execute、Reflexion这些模式，本质上都是harness层面的架构选择。

第四层是状态与记忆。 对话历史、任务进度、中间产物、跨会话的长期记忆。模型没有持久化能力，所有「记住」都是harness在外部存储里读写。

这四层加起来，构成了一套运行时系统。模型可以随时替换——从GPT换到Claude换到开源模型——但harness往往需要重写或者大幅调整。

MCP（Model Context Protocol） 是Anthropic于2024年底提出的一套开放协议，用于标准化LLM应用与外部工具、数据源之间的连接方式。传统做法是每个应用自己定义函数调用格式、自己实现工具适配，导致工具生态碎片化。MCP试图充当这一层的「USB接口」：工具提供方按协议暴露能力，harness按协议发现和调用，双方解耦。对harness工程而言，MCP的价值在于把工具接口层标准化，使得同一个工具可以被不同框架复用，也降低了替换模型或框架时的迁移成本。不过MCP主要解决的是「怎么连」的问题，工具描述怎么写、返回结果怎么裁剪、错误怎么归一化，仍属于harness自身的工程决策。

ReAct、Plan-and-Execute、Reflexion 是三种常见的agent控制流模式，区别在于「谁来决定下一步」。ReAct让模型在每一步交替输出推理和动作，由harness执行动作并把观察结果回灌，循环直到模型给出终止信号，灵活但步数不可预测。Plan-and-Execute先让模型一次性产出完整计划，再由harness逐步执行，可控性强但计划质量差时整体失败。Reflexion在执行失败后引入自我反思环节，把失败原因写成文字反馈给下一轮尝试，本质是在harness层维护一份「经验记忆」。三者都不是模型能力，而是harness对循环结构、终止条件和反馈回路的编排选择，实际产品中常混合使用。

为什么它值得被当作一门工程学科

HN评论区里有一条被反复回应的观点：大多数人把90%的精力花在选模型和写prompt上，但真正决定产品体验的是harness。这个判断值得认真对待。

同一个模型，在聊天的场景里表现不错，但放到一个需要调用5个工具、处理3种失败模式、保持多轮状态的任务里，立刻暴露问题。问题出在哪？往往不是模型「变笨了」，而是harness没有给模型足够的支撑：工具描述写得模糊、错误信息直接抛原文、上下文超过窗口后暴力截断、没有终止条件导致无限循环。

从工程角度看，harness的设计有自己的一套权衡：

• 控制粒度：是让模型自由决定每一步，还是由harness编排固定流程？前者灵活但不可控，后者稳定但僵硬。
• 错误恢复：把异常原样抛给模型，还是由harness先做一层归一化处理？
• 可观测性：每次调用的输入输出、每次工具调用的耗时和结果，有没有完整的trace？没有trace的harness几乎无法调试。
• 成本与延迟：并行调用、缓存、模型分级路由，都是在harness层做决策。

这些问题的答案不写在任何模型的system card里，但它们决定了最终用户感受到的是「智能助手」还是「人工智障」。

可观测性（observability） 在LLM应用中比传统后端更关键，因为失败往往不是抛异常，而是模型「安静地做错事」。一套完整的trace至少需要记录：每次模型调用的完整输入token与输出、每次工具调用的参数与返回、每一步的耗时与token消耗、以及控制流的跳转路径。没有这些，调试只能靠猜——同一个bug在温度参数和上下文变化下未必复现。工程上通常把trace按「会话-轮次-步骤」三级组织，并支持按失败步骤回放。可观测性同时也是成本优化的前提：只有看清每次调用的token分布，才能判断该压缩哪段上下文、该缓存哪个工具结果。

一个被低估的结论

原文标题里那个身体隐喻，拆到底是一句话：模型的智能上限由模型决定，产品的体验上限由harness决定。当前模型能力已经足够支撑大量实际任务，瓶颈往往卡在执行框架的工程质量上。

对于正在构建AI应用的团队，这意味着投入方向需要重新分配——与其反复比较benchmark分数，不如把时间花在上下文策略、工具接口设计、错误处理和可观测性上。这些东西不性感，不容易写成发布公告，但它们是让模型从「演示可用」走到「生产可用」的那道门槛。

HN帖子热度不高，但这个框架本身值得被更多做AI工程的人看到。