Harness架构实战：企业级Agent项目全解析

为什么Harness架构成了大模型面试的新考点

AI大模型领域的求职门槛正在快速提升。据B站马士教育肖老师的分享，无论是算法研究还是大模型应用开发岗位，面试官对技术深度的要求都在提高。其中一个显著变化是：面试官开始重点考察候选人对多智能体（Multi-Agent）和Harness架构的掌握程度。

所谓Harness（驾驭工程），是Anthropic提出的一种面向复杂任务的智能体新架构。它不再是简单的"一个Prompt调一个模型"，而是围绕智能体构建了一整套涵盖模型调度、工具调用、安全隔离、数据对接的工程化体系。值得了解的是，Harness架构脱胎于Anthropic 2024年发布的智能体工程化实践框架，其核心理念是将单一大模型调用升级为可编排、可监控、可扩展的工程化体系。

从软件工程视角看，Harness本质上是将"可观测性（Observability）"和"韧性工程（Resilience Engineering）"引入AI系统。可观测性源自分布式系统领域，指通过日志（Logs）、指标（Metrics）和链路追踪（Traces）三个维度，实时掌握系统内部运行状态的能力——这套方法论由谷歌SRE团队在大规模服务治理中逐步完善，如今成为云原生工程的基础原则。值得一提的是，链路追踪（Distributed Tracing）最早由谷歌Dapper论文（2010年）系统化提出，其核心思想是为每个请求分配唯一的TraceID，并在跨服务调用中透传该ID，从而将分散在多个服务日志中的调用片段还原为完整的调用链视图——在智能体场景下，这意味着可以精确追踪"用户提问→工具调用→模型推理→结果返回"每个环节的耗时与异常，而非只能事后猜测故障发生在哪一步。韧性工程则强调系统在局部故障时的自我恢复能力，要求系统设计预先考虑各类失败场景并建立相应的降级与容错机制。这两个概念原本是分布式系统领域的核心原则，如今被迁移到智能体工程中，解决的是AI系统在生产环境中"不可控、不可测、不可维护"的根本问题。

与早期的ReAct（Reasoning + Acting）范式相比，Harness代表了一次重要的范式跃迁。ReAct自2022年由谷歌研究团队提出以来，成为早期智能体设计的主流框架，其核心思想是让语言模型在"思考（Thought）→行动（Action）→观察（Observation）"的循环中逐步解决问题，本质上是对单一模型推理能力的增强。ReAct的灵感来源于人类认知科学中的"认知行为循环"——在执行任务时，人类会不断地根据新观察更新行动计划，ReAct将这一过程形式化为可被语言模型执行的结构化范式。从心理学角度看，这一设计对应了"元认知"（Metacognition）理论：个体不仅执行任务，同时监控并调整自身的执行过程。ReAct正是通过强制语言模型在每次行动前显式输出"思考"步骤，模拟了这一自我监控机制，从而显著减少了模型的盲目行动和幻觉输出。然而ReAct的局限在于：它仍以模型本身为中心，缺乏对工具调用失败、模型幻觉、并发任务等工程级问题的系统性处理。单一模型的上下文窗口是有限的，当任务链条足够长时，早期的推理信息会被"遗忘"；而工具调用的失败率在生产环境中远高于实验室环境，ReAct并未内置重试、降级或错误分类机制。

Harness架构的出现，标志着智能体工程从"模型能力驱动"向"工程可靠性驱动"的范式转移——将整个智能体运行周期纳入统一的工程管控，强调的是生产环境下的可靠性与安全性，而非仅仅提升单轮任务的完成质量。本文将以一个真实的企业级项目为例，逐层拆解这套架构的核心设计。

大模型岗位的两大就业方向

在深入架构之前，有必要厘清当前大模型岗位的两个主要方向：

• 算法研究方向：专注于研发新版基座大模型，参与模型预训练。此类岗位对学历和论文背景要求较高，通常需要985硕士及以上学历。
• AI大模型工程化落地方向：基于已有基座模型结合企业业务进行定制化开发，涉及模型微调、Agent开发、推理优化等，一般不参与预训练阶段。

有意思的是，工程化落地方向的岗位名称并不统一——应用工程师、大模型应用算法工程师、智能体开发工程师，叫法各异。名称不重要，关键是理解岗位背后的实际工作内容。值得注意的是，工程化落地方向在2024年后需求量已超过纯算法研究岗位，这一趋势与整个行业从"模型研究竞赛"转向"规模化商业落地"的重心转移高度吻合。

企业级Agent项目全景：智能采购助手

本文拆解的项目是一个基于已有ERP系统的智能采购助手，属于典型的Harness架构实战案例。强调"基于ERP系统"，是因为它反映了企业智能体开发的真实处境：大多数公司在大模型普及之前，早已运行着CRM、ERP等成熟业务系统。这些系统往往运行多年，积累了海量的历史数据和业务逻辑，且通常以Java、.NET等传统技术栈构建，与Python主导的AI生态存在天然的技术鸿沟。新的智能体不能独立存在，必须与这些既有系统深度对接，这也是Harness架构中"数据对接层"设计复杂度的根本来源。

前后端分离的整体架构

项目采用前后端分离设计：

• 前端：使用Vue开发，运行于3000端口，负责用户交互界面。
• 后端：使用FastAPI框架，运行于8090端口，智能体最终部署在ASGI服务中。

为什么企业生产环境必须将智能体部署到ASGI服务？要理解这一点，需要先了解ASGI的技术背景。ASGI（Asynchronous Server Gateway Interface）是Python Web生态中WSGI的异步继任者，由Django Channels项目于2018年率先推广。与传统的WSGI（同步阻塞模型）不同，ASGI基于Python的asyncio事件循环，单进程即可处理数千个并发连接——这对于大量用户同时与智能体交互的场景至关重要。

理解WSGI与ASGI的本质区别，有助于更深刻地认识这一技术选型的必要性。WSGI诞生于2003年（PEP 333），彼时互联网应用以请求-响应式的同步交互为主流；每个请求占用一个线程，请求处理完毕后线程释放。这一模型在低并发场景下工作良好，但在AI时代遭遇了结构性瓶颈：大模型的响应延迟通常在数秒乃至数十秒量级，若用WSGI同步阻塞处理，100个并发用户就需要维持100个线程持续等待，线程资源迅速耗尽。ASGI彻底转变了这一范式——基于asyncio的协程机制，单个线程可以在等待模型响应的间隙切换去处理其他请求，真正实现"等待不阻塞"。这一设计思想与JavaScript的事件循环（Event Loop）异曲同工：Node.js正是凭借类似的非阻塞I/O模型，在实时通信和API聚合场景中展现出远超传统同步服务器的并发能力，而Python的asyncio则将同样的思想带入了AI工程领域。

具体到本项目，选择ASGI的核心原因有两点：

1. 高并发异步处理能力：ASGI天然支持异步请求，可从容应对大量并发用户。当一个用户的请求正在等待大模型响应时，服务器无需阻塞，可以同时处理其他用户的请求。
2. 真正的流式输出：流式响应（Streaming Response）是智能体交互体验的关键——用户能看到模型逐字输出而非等待完整回答。ASGI的异步特性能够原生支持这一能力，而传统同步框架则需要额外的工程技巧才能勉强实现。流式输出在技术上依赖HTTP的Server-Sent Events（SSE）或WebSocket协议，这两者都需要长连接支持，恰好是ASGI的原生能力域。

项目中使用了UV作为ASGI服务的运行框架。"智能体 + ASGI后端 + 前端"的组合，正是企业生产环境的标准搭配，而非个人项目的简易实现。

MCP协议：智能体对接企业系统的标准方案

智能采购助手的核心能力之一，是读取企业ERP系统中的真实业务数据。项目采用MCP（Model Context Protocol）协议和网关，实现了对已有Java项目中ERP系统数据的标准化访问。

要理解MCP为何重要，需要了解它解决的历史问题。MCP是Anthropic于2024年11月开源的标准化协议，其诞生背景是大模型与外部系统集成的"碎片化困境"：在MCP出现之前，每个AI应用都需要为不同数据源单独编写适配代码——对接数据库一套逻辑，对接文件系统一套逻辑，对接REST API又是一套逻辑，维护成本极高且难以复用。

MCP的设计哲学借鉴了LSP（Language Server Protocol）的成功经验——LSP统一了代码编辑器与语言服务之间的通信标准，使VS Code、Neovim等不同编辑器能共享同一套语言分析后端。MCP将类似理念引入AI生态：定义了标准化的资源（Resources）、**工具（Tools）和提示（Prompts）**三层抽象，使任意遵循协议的客户端（AI应用）都能无缝对接任意遵循协议的服务端（数据源）。

这三层抽象有其明确的职责分工：Resources对应静态或动态的数据读取（如数据库查询、文件读取），Tools对应有副作用的操作执行（如提交订单、发送邮件），Prompts则提供可复用的任务模板。从通信层看，MCP基于JSON-RPC 2.0协议传输消息，支持stdio（本地进程通信）和HTTP+SSE（远程服务通信）两种传输方式——前者适用于在同一机器上运行的本地工具，后者则支持跨网络访问企业内部系统，两种模式的灵活切换使MCP既能服务于开发者的本地调试场景，也能适配企业生产环境的分布式部署需求。这一分层设计不仅降低了集成复杂度，更重要的是为安全审计提供了清晰的权限边界——企业安全团队可以精确控制某个AI应用能访问哪些Resources、调用哪些Tools，而无需分析大量碎片化的自定义代码。这一设计在企业环境中尤为重要，因为企业往往同时运行数十个异构系统，MCP的标准化降低了集成成本，并提高了安全审计的可行性——类似于USB接口统一了硬件连接标准，从根本上解决了"智能体如何安全、规范地访问企业内部数据"这一普遍难题。

在模型层，项目接入了多个外部模型，分工明确：

• 推理模型：使用DeepSeek作为主力推理引擎
• 备用模型：使用智谱，在主力模型不可用时接管任务
• 摘要模型：单独配置，专项处理文本摘要任务

这种多模型协同设计，正是Harness架构的典型特征。这一理念在工程上被称为"模型路由"（Model Routing），其背后逻辑是：不同的请求根据其特征被动态分发到最合适的处理节点，需要解决三个关键工程问题——如何准确判断任务类型（分类器或规则引擎）、如何处理主力模型不可用时的降级逻辑（Circuit Breaker熔断模式）、以及如何在多模型间保持上下文一致性（共享Memory层）。

Circuit Breaker模式源自Martin Fowler提出的微服务容错设计：当下游服务（如DeepSeek API）连续失败达到阈值时，熔断器自动"断开"，将请求切换到备用模型（如智谱），避免级联失败拖垮整个系统。Circuit Breaker通常具有三种状态——闭合（Closed）：正常转发请求；断开（Open）：拒绝请求并直接返回降级响应；半断开（Half-Open）：周期性尝试恢复，若成功则回到闭合状态。这套状态机机制确保了系统在模型API不稳定时仍能保持对用户的响应，是生产级AI系统不可缺少的容错设计。在实践中，Netflix开源的Hystrix库（现已进入维护模式，由Resilience4j继承）将Circuit Breaker模式带入了工业界主流，其设计思想在云原生领域广泛沿用；如今在AI工程中，LangChain、LlamaIndex等主流框架也开始内置类似的熔断与重试机制，这一模式正从分布式系统领域全面渗透到智能体工程中。

推理任务需要强大的逻辑链条，摘要任务更需要语言凝练能力，强行用同一模型处理既浪费算力，也未必能取得最佳效果。DeepSeek作为推理主力的选择，还体现了"性价比优先"的工程决策——其在数学推理和代码生成上的benchmark表现与顶级模型相近，但API调用成本显著更低，这在企业生产环境中是不可忽视的运营因素。

外部数据的抓取：对接供应商信息

作为采购助手，智能体还需获取供应商的实时报价。项目通过Skill调用或网络爬虫的方式访问供应商官网，抓取报价页面和商品信息，为采购决策提供外部数据支撑。这一能力在技术上涉及对动态渲染页面的处理（通常需要Playwright或Selenium等无头浏览器工具），以及对非结构化HTML数据的结构化提取——大模型在这一环节承担了传统正则表达式难以完成的语义解析工作，能够从格式各异的供应商页面中准确抽取价格、库存、交货期等关键字段。值得一提的是，Playwright相比Selenium具有原生的异步API支持，能与ASGI后端的asyncio生态无缝集成，避免了在异步服务中调用同步阻塞爬虫带来的性能瓶颈——这一细节体现了技术选型中"整体架构一致性"的重要性，各组件的异步特性需要在整个技术栈层面保持对齐。

沙箱机制：企业级Agent的安全底座

MCP解决了数据对接问题，而沙箱（Sandbox） 则负责解决企业级Agent中最容易被忽视、却极其关键的两个安全问题。

Skill执行的安全隔离

智能体支持Skill（技能扩展），这些Skill可能来自网络下载，也可能由智能体自主生成。无论哪种来源，直接在宿主环境中执行都存在安全隐患——尤其是自动生成的代码，可能包含危险操作或恶意逻辑。当大模型具备代码生成与自主执行能力时，这一风险尤为突出：模型可能被诱导生成删除文件、访问敏感目录甚至发起网络攻击的代码，若不加隔离，后果不可控。

这类攻击在安全领域被称为"Prompt Injection"（提示词注入）——攻击者通过精心构造的输入诱使模型执行恶意指令，是当前AI安全领域最活跃的研究方向之一。Prompt Injection与传统的SQL注入攻击有异曲同工之处：两者都利用了"指令与数据未能有效分离"的设计缺陷。区别在于，SQL注入针对的是数据库解析器，而Prompt Injection针对的是语言模型本身——由于大模型的"执行逻辑"天然嵌入在自然语言中，边界更难界定，防御难度也更高。Prompt Injection还可进一步分为直接注入（攻击者直接向模型发送恶意指令）和间接注入（恶意指令嵌入在模型需要处理的外部内容中，如网页、文档或数据库返回值）——后者在智能体场景下危害尤为隐蔽，因为智能体在访问供应商网页、读取ERP数据时，都可能无意间"读入"攻击者预先埋伏的恶意指令。沙箱隔离正是阻断此类攻击链条的关键防线：即使模型被成功诱导执行了恶意代码，沙箱的容器边界也能将破坏范围限制在隔离环境内，宿主系统毫发无损。

多用户的数据隔离

前端面向多个用户开放，智能体在处理复杂任务时会产生大量中间文件、分析报表等临时数据。

若不做用户隔离，不同用户的文件极易混乱甚至泄露。解决方案是为每个用户分配独立的沙箱：张三的沙箱只属于张三，李四的沙箱只属于李四，从架构层面天然实现数据隔离。

项目使用OpenSandbox-Server部署在独立的Linux服务器上，提供沙箱服务。从技术本质看，沙箱是基于容器（Container）技术实现的——这是一项以Docker为代表、自2013年问世以来已成为云原生基础设施核心组件的成熟能力。

容器通过Linux内核的**namespace（命名空间）和cgroup（控制组）**两大机制实现隔离。namespace为进程提供独立的系统视图：PID namespace使每个容器拥有独立的进程树（容器内的进程1不是宿主机的init）；network namespace为容器分配独立的网卡、IP和路由表；mount namespace隔离文件系统挂载点，使容器无法访问宿主机的任意目录。cgroup则从资源维度施加约束：限制容器最多使用多少CPU时间、多少内存、多少磁盘I/O带宽，防止某个恶意或失控的容器耗尽宿主机资源、影响其他用户的沙箱。值得注意的是，相比完整虚拟机（VM），容器的隔离边界本质上仍共享同一个Linux内核——这意味着容器隔离依赖于内核本身的安全性，若内核存在提权漏洞（如历史上的Dirty COW漏洞），容器内的恶意代码理论上仍可突破边界。因此在高安全要求的场景下，部分企业会选择gVisor（谷歌开源的用户态内核沙箱）或Firecracker（AWS开源的轻量级微虚拟机）等更强隔离方案，在容器便利性与VM级别安全性之间取得平衡。

在智能体场景中，这意味着即使模型被诱导生成了危险指令，其破坏范围也被严格限制在容器内部，宿主系统完全不受影响——这是"最小权限原则"（Principle of Least Privilege）在AI工程中的具体落地，是企业将AI能力引入生产系统时不可绕过的安全工程基础。为支持不同用户所需的差异化运行环境，项目还配置了镜像仓库，预先准备多个容器镜像，按需动态分配——这与Kubernetes生产集群的管理理念一脉相承：将基础设施的供给抽象为声明式的资源申请，由调度系统负责实际的分配与回收。

Harness架构的能力全景与求职启示

综合来看，这个智能采购助手项目完整串联了企业级Agent开发的多项核心技术：

技术模块	核心作用
Harness架构	统筹复杂任务的工程化调度框架
多模型调度	推理、备用、摘要模型各司其职
MCP协议	标准化对接企业既有业务系统
ASGI部署	支撑高并发请求与流式输出
沙箱隔离	保障代码安全与多用户数据隔离

对于正在准备大模型岗位的求职者而言，这套架构恰恰对应了面试官关注的新方向。单纯会调API、写Prompt已经不够用了——能够理解并落地一套完整的、贴近企业生产环境的Agent工程体系，才是当下求职的核心竞争力所在。

这意味着求职者需要同时具备"AI视角"（理解模型能力边界与多模型协作逻辑）和"工程视角"（掌握异步服务、容器隔离、协议标准化等基础设施知识），两者缺一不可。前者让你知道该让模型做什么，后者让你知道如何让系统安全可靠地运行在真实生产环境中。从更宏观的视角来看，Harness架构所代表的工程化思维，本质上是将大模型从"实验室工具"转变为"可信赖的生产级系统"的必经之路——这一转变不仅需要算法能力，更需要对整个软件工程体系的融会贯通。事实上，这一趋势与整个计算机行业的历史规律高度一致：从早期的学术编程语言到工业级编译器，从实验室网络协议到互联网基础设施，每一项技术从"能用"到"好用、可靠、安全"的跨越，都经历了类似的工程化深化过程——大模型正在走过同样的路。

本文梳理的是项目的宏观架构框架，具体的代码结构与功能实现细节，将在后续内容中进一步拆解。

核心要点

核心要点