Harness驾驭工程实战：企业级多Agent智能体架构拆解

什么是Harness驾驭工程架构

随着大模型智能体从概念走向生产落地，如何在企业环境中构建可靠、可扩展的Agent系统成为工程界的核心命题。B站一位技术UP主分享了一个真实客户项目——基于已有ERP系统的智能采购助手，采用了被称为「Harness Engineering」（中文译作「驾驭工程」）的新型架构。这套架构强调把智能体作为工程系统的一部分来对待，而非孤立的AI能力模块。

驾驭工程的核心思想在于：智能体不是独立运行的黑盒，它需要与外部模型、已有业务系统、执行环境和用户界面深度协同。项目本身代码量较大，是一个典型的贴近企业需求的完整实战案例，涵盖了从模型接入到工程部署的全链路设计。

前后端分离的整体架构

项目采用前后端分离的经典结构。前端使用 Vue 框架，运行在 3000 端口，负责与用户交互；后端则基于 FastAPI，运行在 8090 端口。之所以需要独立后端，是因为开发完成的智能体最终必须部署到生产级服务中。

对于以 Python 为主开发的智能体，后端通常跑在 ASGI（Asynchronous Server Gateway Interface）服务上。项目中使用了 UV 相关工具链作为 ASGI 服务的载体。UP主强调，ASGI 之所以成为企业生产环境的标配，主要解决两个关键问题：

• 高并发异步处理：能够胜任高频率的异步请求，满足多用户同时访问的负载需求；
• 流式输出：真正实现智能体的流式响应，这是提升用户体验的关键能力。

换言之，个人开发可以随意运行智能体脚本，但企业生产必须把智能体部署到 ASGI 后端，再通过前端（无论 Vue、App 还是小程序）暴露给终端用户。

ASGI（Asynchronous Server Gateway Interface）是 Python Web 生态中用于处理异步请求的服务器接口规范，是早期 WSGI 的继任者。WSGI 基于同步模型，每个请求占用一个线程或进程，难以应对大量长连接或流式传输场景；ASGI 则基于 Python 的 asyncio 事件循环，单进程即可并发处理大量请求。对于智能体应用，ASGI 的流式支持尤为关键：大模型推理结果往往是逐 token 生成的，需要通过 Server-Sent Events（SSE）或 WebSocket 将 token 实时推送给前端，形成"打字机效果"。FastAPI 原生支持 ASGI，配合 Uvicorn 或 Hypercorn 等 ASGI Server 即可在生产环境中提供高并发、低延迟的流式响应能力。

外部模型与已有系统的对接

这个智能采购助手需要连接的外部资源相当丰富。在模型层面，推理模型使用了 DeepSeek，备用模型选择了智谱，同时还配置了专门的摘要模型。这种「主模型+备用模型+摘要模型」的多模型编排，体现了企业级应用对稳定性和成本的综合考量。

更值得关注的是与已有业务系统的对接逻辑。很多公司在大模型普及之前，早已运行着自己的 CRM、ERP 等业务平台。企业定制智能体的现实场景，往往不是从零构建独立系统，而是让智能体与存量系统交付协作。

本项目以 ERP 为例，智能采购助手需要读取 ERP 中的采购、供应商等业务数据。项目特意采用 MCP 协议与网关 的方式来读取已有 ERP 项目中的数据，而非直接侵入原系统。这种解耦式的数据接入设计，是企业级智能体落地的典型工程手法。

MCP（Model Context Protocol）是由 Anthropic 于2024年末提出的开放协议，旨在标准化大模型与外部数据源、工具之间的通信方式。其核心思想类似于 USB 接口的统一化：无论外部系统是数据库、API 还是文件系统，都通过同一套协议与智能体通信，避免每次集成都重新定制适配层。MCP 网关则充当协议的路由中枢，将智能体的数据请求转发至对应的后端服务，同时提供权限控制、请求审计等企业级能力。在对接存量 ERP 的场景中，这种方式的优势尤为明显：原有 ERP 系统无需改造，只需在其外层部署一个 MCP Server 暴露必要数据接口，智能体便可通过标准协议读取采购订单、供应商档案等业务数据，实现"非侵入式"集成。

沙箱：安全与用户隔离的双重保障

智能体在执行任务时会调用各类 skill，甚至从网络下载或由大模型自主生成脚本。这带来两个必须解决的工程问题。

第一是 skill 的安全问题。企业级开发中，无法保证每个执行脚本都绝对安全，需要一个受控的执行环境来隔离潜在风险。第二是 多用户之间的文件与数据隔离。由于前端会有多个用户（如张三、李四）同时使用智能体，各自生成的中间文件、分析报表必须彼此隔离，不能混淆或越权访问。

项目给出的解决方案是引入 沙箱（Sandbox） 服务。UP主特意用一台独立的 Linux 服务器运行沙箱，通过 open sandbox server 命令启动。沙箱本质上是多个容器的组合——这是一个已存在十几年的成熟概念。

隔离机制的巧妙之处在于：为每个用户分配独立沙箱。张三操作智能体时，系统为其分配专属沙箱，他生成的所有中间文件都留在自己的容器内；李四则拥有另一个独立沙箱。由于容器之间天然隔离，张三生成的 PPT 文件李四无法访问，反之亦然。这样既解决了安全执行问题，又实现了多租户数据的天然隔离。

沙箱（Sandbox）在工程实现上通常基于 Linux 容器技术，如 Docker 或更轻量的 gVisor、Firecracker 等方案。容器通过 Linux 内核的 namespace 和 cgroups 机制，为每个进程组提供独立的文件系统视图、网络栈和资源配额，使得容器内的代码无法感知或访问宿主机及其他容器的资源。在智能体场景中，大模型有时会生成并执行动态代码（即 Code Interpreter 能力），这类"模型自生成代码"的执行风险极高——一旦生成恶意或有缺陷的脚本，若不加隔离可能损坏生产数据甚至威胁服务器安全。将每次代码执行限制在独立容器内，即使脚本出现异常，影响范围也被严格控制在该容器边界之内，到期销毁容器即可彻底清理副作用。

镜像仓库与供应商数据抓取

既然沙箱由多个容器构成，就需要为容器指定镜像。项目配置了独立的 镜像仓库，原因在于不同用户的容器环境可能不同——某些用户需要特定功能或环境配置，可以提前准备多个差异化镜像供调度使用。

此外，作为采购助手，智能体必须与供应商信息关联。它会通过 skill 或网络爬虫的方式访问供应商官网，抓取报价页面等公开信息，为采购决策提供数据支撑。

从架构俯瞰企业级智能体落地

这个项目虽然只讲解了宏观框架，但已经清晰勾勒出企业级智能体工程的完整拼图：Vue 前端负责交互，FastAPI + ASGI 后端承载智能体运行，多模型编排提供推理能力，MCP 协议对接存量 ERP 系统，沙箱容器解决安全与隔离，镜像仓库支撑环境定制，网络爬虫补充外部数据。

驾驭工程的价值正在于此——它不再把智能体当作一个孤立的 AI 功能，而是将其纳入完整的软件工程体系中考量部署、并发、安全、隔离与系统集成等真实生产问题。对于希望将大模型能力落地到实际业务的团队，这套架构思路提供了颇具参考价值的工程范式。