Harness工程：AI智能体从Demo到生产的核心基础设施

在AI智能体（Agent）从Demo走向生产的过程中，很多开发者都遇到过同一个困境：本地跑得好好的Agent，一旦上线就状态百出——中断无法恢复、行为难以预测、缺乏权限控制。Netflix工程师Scott Moss在Front End Masters（现已更名为Master.Dev）的"Harness工程与智能体编排"工作坊中，系统阐述了一个被严重低估的概念：Harness（运行环境/线束）工程。

本文基于这场工作坊内容，梳理Harness工程的核心理念，以及为什么Scott断言"没有Harness，你根本无法把Agent送上生产环境"。

什么是Harness？它与Agent的本质区别

Scott给出了一个清晰的等式：Agent = LLM + Harness。

如果只有大语言模型，你拥有的不过是一个"一次性、事务型的推理调用"——你问它一句，它答你一句，仅此而已。这里需要理解一个关键的技术背景：大语言模型本质上是一个无状态的文本生成函数，接收输入token序列，输出下一个token的概率分布。每次API调用之间，模型本身不保留任何上下文或状态信息。这意味着如果没有外部系统来管理对话历史、维护任务状态、处理异常恢复，LLM就只能完成单轮问答。Agent的概念正是在此基础上演化而来——通过外部编排层赋予LLM感知环境、规划行动、使用工具和持续迭代的能力，使其从被动应答器变为主动执行者。

而Harness，正是让这个无状态的模型变得可对话、有记忆、可持续、能自愈、能根据不同问题切换不同架构的那一整套基础设施。

"在我看来，Agent本身就是基础设施，而Harness是构建这个基础设施的东西。没有基础设施，你造不出任何一个用户真正愿意用的Agent。"

Scott特别强调，Harness和Agent一样，都是被过度使用、含义模糊的词。但剥离表述差异后，本质都指向同一件事：让Agent变得健壮、准确、有记忆、可恢复的全部底层能力。

以Claude Code为例，如果把LLM选择剥离掉，剩下的终端UI、对skills的支持、@提及文件的交互、历史过长时的自动压缩（auto compact）、自动派生子Agent的能力——这些全都属于Harness的范畴。具体来说，Claude Code是Anthropic推出的命令行AI编码助手，它将Claude模型与终端环境深度集成，支持直接读写文件、执行shell命令、浏览代码库等操作。其内部实现了自动上下文压缩（当对话历史超出上下文窗口时自动摘要）、子Agent派生（将复杂任务拆分给专门的子进程处理）、以及通过CLAUDE.md文件和/compact命令等机制管理长期记忆。Skills机制允许用户通过Markdown文件定义项目特定的规则和工作流程，本质上是结构化的system prompt注入。

聊天室里有观众做了一个精辟总结，Scott当即认可："模型的能力，取决于Harness允许它做什么。" 这也解释了为什么模型本身已不再是竞争焦点——用较弱模型配好Harness，完全可能胜过强模型配差Harness的组合。

为什么产品级Agent不能只靠Claude Code

工作坊中有一个高频问题：企业场景下（比如自动分诊Jira工单），是自己构建Harness，还是直接用Claude Code这类现成的编码Agent？

Scott的回答相当务实：

编码相关任务：用现成编码Agent

如果任务涉及写代码、需要访问终端、bash、文件系统、代码仓库，那么使用Claude Code、Codex这类编码Agent几乎总是更好的选择。没必要从零造一个编码Agent。

产品级Agent：必须自建程序化Agent

Scott明确区分了"编码Agent"与"程序化Agent（programmatic agent）"。这两者的区别至关重要：编码Agent（如Claude Code、GitHub Copilot Agent、OpenAI Codex）专为软件开发场景设计，其Harness预置了代码理解、文件操作、终端执行等能力。程序化Agent则是开发者通过代码完全自定义编排逻辑的Agent——你控制每一步的决策流程、工具选择、状态管理和错误处理。两者的关键区别在于确定性：编码Agent的行为路径由模型自主决定，而程序化Agent允许开发者在关键节点注入确定性逻辑，例如强制执行特定的审批流程或数据验证步骤。

Claude Code的Harness已经写死，你唯一能影响它的方式就是给它更多上下文——prompt、skill、MCP server本质上都是prompt。这里补充一下MCP的背景：MCP（Model Context Protocol）是Anthropic提出的开放协议标准，旨在统一AI模型与外部工具和数据源的交互方式。MCP Server是实现该协议的服务端程序，它向AI Agent暴露一组标准化的工具接口（如数据库查询、API调用、文件操作等）。Agent通过MCP协议发现可用工具、理解工具参数格式、发起调用并接收结果。从Harness的视角看，MCP Server本质上是一种结构化的上下文注入机制——它告诉模型"你有哪些工具可用以及如何使用它们"，这些信息最终都会被转化为prompt的一部分。

Scott给出三条不适合生产环境的理由：

1. 过于通用——即便加上正确的skill，也难以精准匹配垂直业务需求；
2. 无法评估（eval）——你只能衡量给它的prompt，为Claude Code写evals几乎不可能；
3. 无法控制Harness——如果你需要确定性地执行某个固定工作流，Claude Code做不到。

关于第二点，Evals（评估）在Agent开发中的重要性值得展开说明。Evals是衡量AI系统输出质量的系统化测试框架。与传统软件的单元测试不同，Agent的评估需要处理输出的非确定性：同一输入可能产生多种合理输出。典型的Agent评估维度包括：任务完成率、工具调用准确性、幻觉检测、安全边界遵守情况、以及多轮交互中的一致性。业界常用的评估方法包括LLM-as-Judge（用另一个模型评判输出质量）、人工标注对比、以及基于规则的自动化检查。没有完善的Evals体系，开发者就无法量化Agent的改进或退化，也无法在模型升级时评估兼容性。

"Claude Code适合写代码、做数据分析、做原型。除此之外我几乎不会用它做任何事。"

Scott还提出一个实用的检验标准：使用Agent时你需要做多少次"你为什么这么做/别这么做"的追问？作为开发者你有容忍度，但如果这是面向客户的产品（比如个人邮件Agent），客户对反复追问的容忍度是零——他们根本不会付费。

Harness的核心组件：记忆、工具、持久化

面对"构建Harness时最该关注什么"的提问，Scott强调一切取决于你想交付的体验。

他举了一个自主运行的交易Agent的例子：因为它在你睡觉时也持续运行，所以Harness的重点是故障状态处理与自愈——确保它永不中断；因为涉及金钱，需要护栏（guardrails）与审批系统；因为接触敏感财务信息，需要围绕PII的安全机制。

关于护栏的工程实现，这是一个值得深入了解的领域。AI系统中的护栏是指防止模型产生有害、不合规或超出预期行为的安全机制。工程实现上通常分为三层：输入护栏（在用户输入到达模型前进行过滤和改写，如检测prompt注入攻击）、输出护栏（对模型生成内容进行合规性检查，如PII检测、有害内容过滤）、以及行为护栏（限制Agent可调用的工具范围、执行频率、资金阈值等）。在生产环境中，护栏通常结合规则引擎和专门训练的分类模型实现，确保在不显著增加延迟的前提下提供安全保障。

不过Scott也梳理了每个Agent都应具备的"基础配置（table stakes）"：

• 记忆（Memory）：短期记忆、长期记忆、scratch pad、facts等多层级记忆管理；
• 工具调用（Tool Calling）：几乎所有Agent都需要与外部系统交互的能力；
• 持久化执行（Durable Execution）：并非每个Agent都需要，但对长时间运行的任务至关重要。

关于持久化执行，这一概念源自分布式系统中的工作流引擎，代表性实现包括Temporal、Azure Durable Functions和Inngest。其核心思想是：将程序的执行状态（包括局部变量、调用栈位置、等待中的异步操作）持久化到外部存储中，使得即使进程崩溃或服务器重启，程序也能从最后一个检查点恢复执行，而不是从头开始。对于AI Agent而言，这意味着一个需要数小时运行、涉及多次LLM调用和外部API交互的复杂任务，不会因为单次网络超时或服务重启而丢失全部进度。

工作坊的示例Agent实现了一个关键能力：即使在推理中途停掉服务器，重启后也能从中断处立即续跑。这背后依赖分布式架构——工作坊选用WebSocket作为传输层而非常见的SSE，因为需要双向通信、"fire and forget"后再接收事件回传，从而支持向任意已连接客户端推送消息。

这一技术选型背后有清晰的工程考量：Server-Sent Events（SSE）是基于HTTP的单向推送协议，服务器可以持续向客户端发送事件流，但客户端无法通过同一连接向服务器发送数据。WebSocket则建立在TCP之上，提供全双工通信通道，客户端和服务器可以随时互发消息。对于Agent系统，WebSocket的优势在于：客户端可以在Agent运行过程中随时发送中断信号、审批决策或补充信息；服务器可以向任意已连接客户端推送状态更新；支持"fire and forget"模式——客户端发送请求后可以断开，后续通过重新连接接收结果。SSE虽然实现简单且对防火墙友好，但无法满足这些双向交互需求。

Scott还给出一句颇具分量的判断：

"Harness工程和evals，是当下AI领域最重要的两件事。如果我要去一家AI公司，我要么全力做Harness工程，要么全力做evals。"

从零构建生产级Harness的实战路径

工作坊的目标不是造Agent，而是造能在生产环境运行任意Agent的那层基础设施。示例项目是一个"客户任务处理Agent"，界面左侧是聊天面板，右侧则是Scott着重设计的"事件流检查器（Event Stream Inspector）"——每一个事件、每一次工具调用、每一次任务移交（handoff）都可被追溯审查。

课程逐步实现以下核心能力：

• 沙盒代码执行：Agent能自己写代码并在隔离环境中安全执行，用于处理算术等需要精确结果的场景，避免反复迭代消耗token；
• 任务移交（Handoff）：Agent判断某任务更适合另一个子Agent时主动转交；
• 子Agent与规划："supervised"模式下派生一批各具人格（persona）的子Agent协同制定计划；
• 审批与持久化：关键操作需人工审批，整个流程可中断恢复。

说个细节，整个Harness在技术选型上刻意保持了可迁移性。课程使用Vercel AI SDK仅仅是为了发起推理调用，并未依赖其独有机制。Scott指出，无论你用Azure AI、AWS Agent Core还是Cloudflare的对应能力，Harness的概念都是通用的——理解这些概念，才能知道"这里需要护栏、那里需要审批"，进而在任意平台上落地。

Harness才是AI Agent的真正护城河

Scott的核心观点值得每一位AI应用开发者深思：在模型能力日趋同质化（连开源模型都足够好）的今天，真正决定Agent产品成败的，不是你选了哪个模型，而是你能否构建出足够好的Harness。

从记忆管理到工具调用，从持久化执行到护栏审批，Harness工程是让AI从"演示很惊艳"跨越到"生产可依赖"的那道关键工程。对于希望把Agent真正推向用户的团队而言，与其纠结模型排行榜，不如把精力投向Harness工程和evals这两项被低估的核心能力建设。