Harness架构实战：企业级智能体从部署到落地全解析

大模型岗位面试的要求正在变高。一位常年做就业辅导的讲师在视频里提到，现在面试官对大模型应用开发者的考察，已经明显偏向两个具体问题：你做的智能体是不是多智能体架构？里面有没有用上 Harness（驾驭工程）架构？这两个问题背后，其实指向同一件事——企业要的不是能跑 demo 的智能体，而是能接进现有业务系统、能隔离用户数据、能安全运行的生产级智能体。

大模型就业的两个方向，决定了你要学什么

讲师把大模型相关岗位主观地分成两类。一类是算法研究方向，负责预训练、版本迭代，对学历和论文要求高，通常需要 985 硕士及以上。另一类是工程化落地方向，拿着已有基座模型结合企业业务做定制开发、微调、推理优化，岗位名称五花八门，应用工程师、智能体工程师、大模型应用算法工程师都可能指向同一类工作。

这个分类不是行业标准，但解释了一个现实：同样叫「大模型算法工程师」，A 公司可能是招微调的人，B 公司可能真的在招预训练的人。对求职者来说，搞清楚自己投的岗位落在哪个方向，比死记岗位名称有用得多。而 Harness 架构的智能体项目，正是工程化落地方向里最能拿得出手的作品。

Harness 架构是什么，为什么面试官在意

按照视频里的说法，Harness 是 2026 年 1 月之后提出的一种新架构，中文叫驾驭工程。它处理的是复杂任务的编排问题——一个智能体要调用多个外部模型、要读写企业已有系统、要生成和操作文件，这些能力如何被组织起来、如何被约束，就是 Harness 要解决的事。

讲师演示的项目把推理模型接的是 DeepSeek^广告，备用模型用智谱，另外还配置了摘要模型。多个模型各司其职，由智能体统一调度，这是 Harness 架构在多模型协同上的一个直观体现。面试官关心它，是因为它对应的是真实的企业开发场景，而不是教学 demo。

Harness（驾驭工程）这个提法在业内尚未形成统一标准，它更接近对一类工程实践的概括：当智能体不再只是单轮问答，而是要调度多个模型、调用外部工具、读写文件和业务系统时，需要一层专门负责编排与约束的机制。这层机制通常包含任务分解、工具路由、上下文管理、失败重试与权限边界等职责，使推理模型只专注于「想」，而「怎么安全地做」交给外层框架。因此它和单纯写 Prompt、接一个模型 API 有本质区别，考察点落在候选人是否理解智能体在生产环境中的控制流与异常处理。

项目全貌：基于 ERP 的智能采购助手

这个实战项目是一个基于已有 ERP 系统的智能采购助手。现实里很多公司在用上大模型之前就已经有 CRM、ERP 这类系统在跑，新做的智能体不可能独立存在，必须和这些老系统对接、读数据、做交付。项目选择以 ERP 为例，模拟的正是这种「智能体嵌进存量系统」的场景。

整体框架是前端加后端。前端用 Vue，端口 3000；后端是 FastAPI，端口 8090。智能体通过 MCP 协议和网关去读取 ERP 里的数据，这个设计把「智能体如何安全访问企业数据」这个问题摆到了台面上，也是项目里值得一提的工程细节。

MCP（Model Context Protocol）是一套让模型或智能体以标准化方式访问外部数据源和工具的协议。它的价值在于把「智能体能调什么、怎么调」抽象成统一的接口描述，智能体无需为每个企业内部系统单独写适配代码，而是通过 MCP Server 暴露能力、由网关统一管理调用。网关在此承担了鉴权、审计和流量收敛的作用，企业可以据此控制智能体只能读取被授权的 ERP 字段，避免模型直接持有数据库凭证。这也是文中强调「智能体如何安全访问企业数据」的技术落点。

为什么智能体要跑在 ASGI 服务里

智能体开发完之后要部署到后端服务，这个后端在项目里是 ASGI 服务，用 UV 框架来承载。

讲师给出的理由有两个：一是高并发请求处理，二是真正意义上的流式输出。这两点对企业生产环境很关键——用户通过前端界面使用智能体，响应不能等整个任务跑完才吐出来，流式输出是体验的基础。所以他强调，个人玩智能体随便跑跑没关系，企业环境里把智能体部署进 ASGI 服务是常规做法。

ASGI（Asynchronous Server Gateway Interface）是 Python 生态中面向异步的 Web 服务接口标准，Flask 时代常用的 WSGI 是同步的，一个请求占一个工作线程，遇到智能体这种耗时较长的任务容易把线程池占满。ASGI 基于 async/await，单个进程可以并发处理大量等待型请求，并原生支持 Server-Sent Events 等流式响应方式。文中提到的 UV 框架即基于 ASGI 的 Python 运行时与包管理工具，用它承载服务可以同时获得异步并发和较快的依赖安装体验。

沙箱：解决 Skill 安全和用户隔离两个问题

项目里另一个重点设计是沙箱服务。视频演示中讲师在一台 Linux 服务器上启动了 OpenSandbox-Server，并进入对应的 Python 虚拟环境。

沙箱要解决两个问题。第一是 Skill 的安全隐患——Skill 可能来自网络下载，也可能是大模型自己生成的，项目本身就能帮用户生成 Skill，来源不可控就意味着风险。第二是用户之间的隔离：前端接入后张三李四都能用这个智能体，他们操作和生成的文件必须彼此不可见。

做法是给每个用户分配独立的沙箱容器。张三的沙箱只属于张三，他生成的中间文件、分析报表别人访问不到，隔离是天然的。讲师顺带解释，沙箱本质上就是多个容器，这个概念在编程领域已经存在十几年，不必神秘化。容器环境可能因用户而异，所以项目还准备了镜像仓库，提前备好多个不同镜像供分配。

Skill 指智能体可调用的封装能力单元，通常以一段可执行代码或工具描述的形式存在，智能体按需加载并执行。由于 Skill 可能由模型动态生成或从外部获取，其代码内容不可信，直接在主服务进程内执行等同于让不受控代码拥有服务器权限。容器沙箱通过命名空间、cgroups 等机制限制文件系统、网络和资源占用，即使 Skill 存在恶意行为，影响也被约束在单个容器内，销毁重建的成本很低，这正是它成为企业级智能体默认安全底座的原因。

外部对接：供应商与存量系统

作为采购助手，智能体需要和供应商关联。项目设计里它会通过爬虫或 API 的方式访问供应商官网，比如抓取报价页面的信息。加上前面提到的 ERP 数据读取，整条链路是：智能体在沙箱内运行 → 通过 MCP 网关读取 ERP → 通过爬虫取供应商报价 → 多模型协同完成推理与摘要 → 经 ASGI 服务以流式方式返回前端。这套链路把企业级智能体常见的外部依赖基本覆盖了。

需要说明的是，视频这期只讲了整体框架，智能体的具体功能细节留到了下一期。但即便只看框架，也能看出这个项目的定位：它不是为了展示某个花哨的智能体能力，而是把企业落地时绕不开的部署、安全、隔离、系统对接这些脏活累活都摆出来，逐个给出工程解。对准备面试的人来说，能讲清楚这些设计取舍，比背概念有说服力得多。

（本文基于 B 站 UP 主的项目讲解视频整理，观点与项目设计均来自该单一来源。）