企业官网建设流程全解析

1. 为什么是 DeepSeek Harness 而不是“直接调 API”

这段时间一直在折腾一件事：把 DeepSeek Harness 接进公司的后台管理系统，让它以 Agent 形态辅助日常运营。先说结论：这套组合跑通以后，原来每天要花半个多小时手动做的数据汇总、异常订单筛选、周报素材整理，现在只要在后台里给 Agent 发一句话，它自己就能完成大半。如果你正打算给公司内部系统接入智能体，但又不确定该从哪一步下手，这篇文章应该能帮你省掉几个晚上的摸索时间。

1.1 后台管理系统里的智能体落地场景

先聊聊我为什么会盯上这个方向。公司后台管理系统是典型的 Vue3 管理端，订单、库存、用户、财务各种模块堆在一起，数据量不大但特别碎。运营同事每天干得最多的不是决策，而是把系统里的数据导来导去：从订单列表导出 Excel、把退款异常的单子筛出来、统计最近七天的转化趋势、再按模板填周报。这些事情有个共同点：操作路径固定、重复性高、又很费人工。

如果只是在后台里接一个“聊天机器人”，用户问一句它答一句，那顶多算个高级搜索框，价值有限。真正能提升效率的形态是 Agent：它不只回答问题，而是能自主调用系统里的工具，把“查数据—做统计—生成文件—给结论”这条链路完整跑下来。所以在动工之前，我给这次集成定了几个核心场景，都是可以直接量化收益的：

• 销售看板自动生成：Agent 读取订单接口数据，计算环比、同比，生成图表所需的 JSON 结构。
• 异常订单分析：按预设规则筛选超时未发货、退款申请、风控拦截的订单，输出摘要和处置建议。
• 库存补货提醒：结合近 30 天销量和当前库存，给出补货清单和预估售罄日期。
• 日志检索与初步定位：接入系统错误日志，线上出问题时，运营或开发可以直接让 Agent 查关键字并概括异常。

这些场景听起来都不复杂，但如果你直接用裸 API 调大模型，马上会遇到一堆工程问题：模型是无状态的，你得自己拼上下文；模型不能直接调系统接口，你要写一堆函数封装；任务执行到一半断了，你无法恢复；更别说权限控制、审批流、操作留痕这些后台系统必须有的东西了。

1.2 Harness 层到底解决了什么问题

我第一次看到 DeepSeek Harness 时也有同样的疑问：不就是个本地运行大模型智能体的壳子吗？真用起来才发现，我之前的理解太浅了。Harness 这层抽象，解决的核心问题是把“模型”和“工具”之间那堆脏活累活接住了。

打个比方：大模型像是发动机，本身只有动力，没有方向；Agent 像是整车，有了方向盘和轮子；而 Harness 就是驾驶舱里那套仪表盘和控制系统，让你能真正驾驶这辆车，而不是抱着发动机干瞪眼。具体到工程层面，Harness 至少帮我们解决了四件事：

第一是对话状态管理。后台管理系统里经常会遇到多轮交互，比如“帮我看下华东区的订单”“再按支付方式分一下”。如果没有状态管理，每次请求都要把前面所有上下文打包发给模型，又费 token 又容易崩。Harness 在本地维护了完整的会话上下文，后端只管发新的消息进去就行。

第二是工具调度协议。Agent 需要一个标准方式告诉系统“我要调用哪个工具、参数是什么、结果怎么处理”。Harness 内置了一套工具注册与调用机制，支持技能编排。我只需要按照插件规范写工具函数，Harness 会自动让模型学会在合适的时机调用它们，不需要我手写复杂的原因分析链路。

第三是长任务处理能力。后台管理里的任务有时需要跑几分钟，比如批量导出大量订单。直接用 API 请求会有超时风险，Harness 则以本地任务形式管理这种长时操作，执行到一半时系统重启了还能从事件日志里续跑。

第四是插件化架构。官方提供了插件机制，我可以用 Python 或相关语言写独立技能包，注册进 Harness 后就能被 Agent 使用。这一点对后台系统集成特别关键，因为每个公司的后台接口都不一样，必须有可扩展的插件体系才能匹配业务。

当然，Harness 不是万能的，它不是拿来就能和后台管理系统打通的神器。实际集成时，还需要自己写一层“桥接服务”，把 Harness 的事件、任务状态转发到后台管理系统的数据库和前端界面里。这部分后面会详细讲。

1.3 先确定边界：Agent 能做和不能做的事

动手写代码之前，我花了不少时间定边界。很多团队做 Agent 集成翻车，不是因为技术不行，而是没有在立项阶段划清楚“Agent 到底能不能做这件事”。后台管理系统里全是业务数据和操作入口，一旦 Agent 误操作删了订单或者改了价格，损失可能非常大。

我最终定下来三条铁律：

• 只读操作可以直接执行：查询订单、查库存、读取日志这类不改数据的动作，Agent 可以自主完成，但结果必须展示给用户。
• 写操作必须先审批：创建补货单、批量修改订单状态、生成并发送报表等操作，Agent 只能生成“执行方案”，等人工在后台确认后才能真正落库。
• 危险操作默认禁止：删除数据、修改价格、导出敏感客户信息等，除非在技能配置里显式开启，否则 Agent 连请求入口都不应该有。

这三条边界直接影响后续架构设计。比如 Harness 工具注册时，每个工具都要带上一个权限级别字段；后台管理系统的 RBAC 模型也要同步扩展，确保“人不能操作的，Agent 也不能绕过”。说白了，Agent 不是新的管理员，它只是帮管理员更快地按下按钮，至于按钮能不能按，必须由后台系统的权限体系说了算。

现在回看，先花半天时间把边界定义清楚，是整个项目里最划算的一笔投入。后续开发、测试、上线，几乎所有需求冲突和安全隐患，都能用这三条铁律快速判断。

2. 环境准备与 Harness 的本地化接入

边界定完之后，第二步就是把 DeepSeek Harness 跑起来，然后打通和后台管理系统的通信链路。这一节的内容适用性比较强，不管你的后台管理系统是 Vue3 还是 React，后端是 Java、Go 还是 Python，思路都差不多。

2.1 安装 DeepSeek Harness 桌面端

我用的方式是下载 DeepSeek Harness 桌面端安装包，装在一台内网 Windows 服务器上。为什么不用个人电脑？因为后台管理系统跑在公司的内网环境，Harness 需要和系统接口互通，放在同一内网段可以减少很多网络策略上的麻烦，也方便做进程守护和日志集中采集。

安装本身没什么难度，一路下一步就行，但有三个细节值得注意：

• 安装路径不要带中文和空格，否则后续加载插件时容易出现编码问题。
• 首次启动后，它会在系统托盘运行，需要在设置里确认本地服务端口已经监听。默认情况下，Harness 会启动一个本地服务端口，后台管理系统后续要连的就是这个端口。
• 模型配置建议先用官方默认配置跑通，不要一上来就折腾自定义模型或外部模型网关，等核心链路稳定了再优化。

安装完以后，我做的第一件事不是急着写代码，而是先在 Harness 自带界面里建一个测试 Agent，让它执行一个最简单的技能，比如“总结一段文本”。确认 Harness 自身能正常工作后，才开始往外面接系统。很多人喜欢直接一步到位，但分层验证能让你在后面的排错中节约大量时间。

2.2 后台管理系统与 Harness 进程的桥接方案

接入之前要想清楚一个问题：后台管理系统和 Harness 之间，到底谁主动连谁？

最简单的方案是让后台管理系统直接调用 Harness 的本地 HTTP API，发送用户问题、轮询任务状态。但我在实测中发现，光是轮询还不够，因为 Harness 在执行任务过程中需要向后台系统请求“工具调用结果”，比如查询订单、读取库存，它不能只靠轮询感知这类回调事件。这个沟通模型用术语说就是“事件驱动”，两边都需要有主动推送能力。

所以我最终采用了一个轻量级桥接服务，架构大概是这样的：

后台管理系统前端(Vue3) ↓ WebSocket/HTTP 后台管理系统后端(REST API + WebSocket Server) ↓ HTTP/WebSocket Harness 本地服务(端口监听 + Agent 运行时) ↓ HTTP 工具调用 后台管理系统后端(REST API - 工具执行入口)

桥接服务就是后台管理系统后端本身。它一方面向 Harness 提供工具调用的 REST 接口，另一方面向前端提供任务状态查询和审批操作接口。Harness 产生的任务状态变更，通过 WebSocket 推送到前端页面，用户就能实时看到 Agent 在做什么。

这里面最关键的决策是：不要把 Harness 直接暴露给前端。也就是前端不直接连 Harness 端口，所有交互都走后台系统后端中转。这样权限校验、参数校验、操作日志都能在统一入口完成，不会出现绕过安全体系的情况。我见过一些人图省事，让前端直连本地的 AI 服务端口，结果权限校验完全失控，后面根本没法上线。

2.3 连接验证与最小可用链路

架构定了之后，先不要急着开发复杂技能，一定要先打通一条最小可用链路。我当时写了一个最简单的工具，功能是让 Agent 获取后台系统的“当前时间”。这个工具毫无业务价值，但能验证整条链路是否通畅：用户提问 → Harness 收到 → Agent 决定调用工具 → 后台系统接口被触发 → 结果返回 → Agent 生成回答 → 前端展示。

Harness 插件工具的核心代码简写如下：

from harness import Tool @Tool.register(name="system_current_time", description="获取后台服务器当前时间") def get_current_time(): from datetime import datetime return {"time": datetime.now().isoformat()}

启动后，我在 Harness 技能配置里把这个问题映射到这条工具链上，然后在后台管理系统的 Agent 面板发了一句“现在几点”。第一次看到前端页面弹出服务器时间时，心里一块石头落了地：从模型决策到系统调用这条路，通了。

最小链路跑通后，我才开始往里面加业务工具。这一步走得很慢，但非常值得，后面所有复杂功能的排错，都能回到这条链路上来复现和验证。

3. Agent 技能开发：从模型调用到可控执行

链路通了之后，真正的重头戏才刚开始：开发能被业务真正使用的 Agent 技能。这一节我会把技能模型、权限模型和审批机制讲透，这些都是后台管理系统集成 Harness 时最容易踩坑的地方。

3.1 技能与工具的权限模型

先引入两个概念：工具是原子能力，技能是业务场景。比如“查询订单列表”是一个工具，“生成销售日报”是一个技能，它内部会按顺序调用多个工具、处理中间结果、最终输出一份日报。

在 Harness 的技能配置里，我用 JSON 声明了一个技能文件，里面包含提示词模板、可用的工具列表、输入输出格式说明。这里有个设计要点：技能里的工具列表一定要写得很收敛，只声明它真正需要的那几个，不要图省事把全部工具都挂上去。因为技能一经发布，Agent 就可能在这个范围内自由组合工具调用，工具暴露面越大，误操作风险越高。

权限模型上，我给每个工具标了三个级别：

这个三级模型和前面的边界是一致的。实现上，Harness 工具注册时会将级别写入元数据；桥接服务的工具执行入口收到请求后，先校验技能声明的级别，再判断当前会话用户是否有对应权限。双重校验，避免只依赖某一层。

3.2 技能配置示例：数据汇总与 Excel 导出

拿“销售日报生成”这个技能举例。它的业务目标是：读取指定日期的订单数据，按商品分类汇总销售额，生成一份 Excel 文件，最后把文件存到后台系统的附件目录，并返回下载地址。

技能配置文件大致长这样：

{ "name": "sales_daily_report", "description": "生成指定日期的销售日报，包含分类汇总和 Excel 文件", "tools": ["orders.query_by_date", "report.excel_export", "file.upload"], "permission": "write_approved", "input_schema": { "date": "string, 格式YYYY-MM-DD", "channel": "string, 可选值:all/online/store" }, "output_schema": { "summary": "object, 每个商品分类的销售额和订单量", "file_url": "string, Excel 文件下载地址", "tips": "string, 用于提醒运营关注的异常点" } }

配置里的三个工具，需要分别在 Harness 插件层实现。特别是report.excel_export这个工具，实际是后台管理系统里的一个文件生成服务，它接收汇总数据后生成 Excel，并存入文件存储模块。为什么不让 Harness 直接生成文件？因为后台管理系统的附件通常需要权限控制、过期清理和审计，放在统一文件服务里更安全。

关于 Excel 文件，还有一个高频需求是“在线预览”。Agent 生成 Excel 后，用户往往不想下载到本地再打开，而是希望后台页面直接点开看。我采用的方案是：文件生成时同时输出一份 HTML 预览版本，或者让前端用表格插件解析下载到的文件内容并渲染。也就是说，预览功能不是端到端自动的，需要后台管理系统在前端做一次表格式展示的适配。实践下来，用现成的前端表格插件渲染服务端吐出的 JSON 数据最稳定，本来就不建议让前端直接解析二进制 Excel 文件。

3.3 人工审批环节：让操作过程“可回滚”

所有写操作，前面提到必须走审批。但审批不能简单理解成“弹个窗确认”，它要设计成一套完整的事件流，否则很容易在网络抖动或任务中断时产生不一致。

我设计的审批流程是：

1. Agent 在执行带write_approved权限的技能时，先生成一份“执行方案”，包含要调用的工具、参数和预期影响范围。
2. 桥接服务把这个方案写入后台管理系统的agent_approval表，状态为pending，并通过 WebSocket 通知前端。
3. 用户在后台页面看到审批卡片，可以一键通过或拒绝，也可以修改参数后通过。
4. 用户通过后，桥接服务再回调 Harness 的接口，告诉它继续执行；如果拒绝，则 Harness 收到终止指令，标记任务为rejected。
5. 整个流程的每一步都写入审计日志，谁审批的、什么时候审批的、原始方案是什么，全部留痕。

这套流程最大的好处是“可回滚”。即使 Agent 生成的方案有误，只要用户不点通过，不会产生任何实际影响；即使审批通过后执行出错，审计日志里也有完整链路可以追溯。后台系统要的是可控，不是智能。再聪明的 Agent，如果没有人工兜底，在后台管理系统里就是定时炸弹。

4. 后台管理系统的改造点：菜单、权限、消息流

把 Agent 能力和后台管理系统真正融合，不只是多一个接口的事，而是要在前端界面、后端权限、消息通知这三个层面做一次系统性改造。下面按改造顺序展开讲。

4.1 前端菜单与操作面板设计

我在 Vue3 后台管理系统的侧边导航里加了一个“AI 助手”的入口，点开后是一个抽屉式操作面板。这个面板不是简单的聊天框，它分三个区域：

• 上方是任务输入区，用户可以直接输入自然语言指令，比如“生成本周华东区订单汇总”。
• 中间是任务流状态区，展示 Agent 当前执行到哪一步、调用了哪些工具、是否等待审批。数据来自后端 WebSocket 推送。
• 下方是历史任务列表，用户可以重新查看之前的任务结果、下载生成的文件，也能一键复跑相似任务。

前端和后端约定了一套统一的任务状态机：created → running → pending_approval → approved/rejected → completed/failed。前端每个状态都有对应的 UI 展示，避免用户面对一个黑盒干等。

开发这个面板时有个容易忽略的点：页面刷新后，WebSocket 连接会断开，任务状态展示会丢失。我的做法是在前端增加一个“恢复现场”机制：进入 AI 助手动面板时，先调用后端接口拉取当前会话最近的未完成任务，再重新订阅事件。这样即使刷新了页面，用户依然知道刚才的任务跑到了哪一步。

4.2 服务端接口与 RBAC 权限收敛

后台管理系统原本就有 RBAC 权限体系，角色、菜单、按钮三级控制。接入 Harness 后，我没有另搞一套权限系统，而是把 Agent 的工具调用映射到原有的权限点上。具体做法是：

• 每个 Harness 工具对应后端一个服务方法，方法方法体一开始就做权限校验，判断当前调用是否来自已授权的角色或用户。
• 桥接服务收到 Harness 的工具调用请求时，会绑定一个“虚拟用户”，这个虚拟用户关联的权限集合由会话发起人的权限实时计算得出。也就是说，管理员发起的 Agent 任务和管理员本人操作系统具备相同的权限。普通运营发起的任务，就按运营的角色权限走。
• 工具执行方法内部不再信任外部传入的角色字段，而是重新从数据库加载会话用户的权限列表。

这套设计核心就一句话：Agent 只是操作发起方，权限校验必须回到服务端原有的 RBAC 体系里去。我见过一些团队在 Harness 技能配置里写死“管理员权限”，那等于给所有能访问 AI 面板的人发了一套超级权限，非常危险。

还有一个细节：后台管理系统后端早期在做接口时，很多写操作接口没有严格拆分，一个 update 接口可能既允许修改部分字段也允许修改敏感字段。Agent 工具一旦调用了这种宽接口，权限边界就很模糊。我把这些宽接口做了收敛，给 Agent 调用单独定制了细粒度接口，只允许传白名单里的字段。

4.3 审批、日志与 Excel 在线预览打通

前面审批机制讲了流程，这里补一下和现有后台功能的融合。我在原有的“操作日志”模块里增加了一个新分类，专门记录 Agent 触发的所有动作。日志内容包括：任务 ID、技能名称、调用的工具、输入参数、输出摘要、审批人、审批时间、执行耗时、错误信息。这个日志不仅是审计用途，也是 Agent 排错的第一手资料。

Excel 在线预览的打通，更多是在文件服务层做适配。Agent 生成 Excel 文件后，文件服务会同时生成一个预览用的 HTML 版本。后台管理系统的“报表中心”页面，原本就支持在详情页展示文件，我复用了这一套展示逻辑，让 Agent 生成的文件也走同一个预览入口。用户不需要下载文件，直接在页面上就能看到表格内容，还能按列排序、搜索。实测下来，运营同事对这个改动尤其满意，因为他们最烦的就是下载、打开、关掉这个循环。

审批流和文件预览还有一个联动场景：Agent 生成 Excel 后，如果技能标记为write_approved，文件本身不会直接对用户可见，而是等审批通过后才会出现在附件列表里。这样既保证了敏感信息不泄漏，又不影响审批人先预览内容做决策。

5. 上线前排错与性能调优记录

任何系统都是测出来的，不是设计出来的。Harness 集成这种跨进程、跨端点的项目，真实环境里会遇到很多文档里没写的坑。这一节记录三个我踩得最重的坑以及对应的排查过程。

5.1 连接不稳定：Harness 进程存活与自动重启

内网服务器跑了两天后，突然发现 Agent 面板上的任务全部卡在created状态，前端怎么刷新都不动。第一反应是网络问题，但后台管理系统本身一切正常。后来排查发现，Harness 的桌面端进程在前一天晚上被系统更新弹窗干扰后异常退出了，但窗口图标还在任务栏残留，看起来好像活着，实际上服务端口已经不再响应。

这个问题暴露了一个盲区：我一开始把 Harness 当成普通桌面软件，忘了它是一个需要长期稳定运行的服务进程。修复方案有两步。

第一步是做进程守护。我在服务器上给 Harness 进程注册了一个系统服务，设置失败后自动重启。如果服务器环境允许，还可以用 Docker 把 Harness 服务化，但我这边的内网环境有限制，所以用了轻量级的方式。

第二步是让桥接服务具备心跳感知。桥接服务每隔 15 秒轮询一次 Harness 的健康检查接口，连续两次没有响应就标记为“Agent 服务不可用”，同时在前端面板顶部显示告警横幅，避免用户提交任务后像之前一样石沉大海。任务提交时如果检测到 Harness 不可用，直接返回“AI 服务正在维护中，请稍后再试”。这个优化虽然不起眼，但省掉了大量“任务到底跑没跑”的困惑。

5.2 长任务超时与任务取消机制

第二个坑是长任务超时。销售日报生成这个技能，在处理单日订单时只花了几秒，但一旦用户指定“生成本季度日报”，工具链里要查询的订单数据量剧增，整个任务跑了两三分钟还没结束。而桥接服务当初给 Harness 回调超时时间设的是 60 秒，结果前端直接报错，用户以为功能坏了。

我把超时策略改成了分层设计：

• 工具调用级别的超时仍然保留，单次查询超过 60 秒就会中断，并给 Agent 返回“查询超时，请缩小数据范围”的提示。
• 任务级别的超时放宽到 30 分钟，Harness 侧支持任务持续执行，桥接服务只负责状态转发，不再强制中断整个任务。
• 前端增加了一个“取消任务”按钮，用户发现 Agent 跑偏了可以主动终止。取消动作会同步发给 Harness，Harness 的运行时负责停止正在执行的工具链。

这个改动背后有个思考：后台管理系统里的任务，既有毫秒级的查询，也有分钟级的报表任务，不能一刀切。超时策略要围绕任务类型来定，而不是所有任务共用一套配置。

5.3 权限绕过的排查与修复

最让我紧张的一个坑发生在权限校验上。测试同事发现，在 AI 面板里用普通运营账号发起一个“导出客户信息”的任务，按道理技能配置里没有这个功能，会被系统拒绝，但实际跑出来的结果里居然包含了一条客户记录的导出链接。

排查链路是这样的：

1. 先看审计日志，发现任务确实触发了customers.query_detail工具，但会话用户权限里并没有这个工具的对应权限。
2. 再看技能配置，发现这个工具是通过“汇总报表”技能的report.excel_export工具间接被调用的，因为该技能的工具列表里漏掉了对内部依赖的声明，Harness 运行时生成了新的工具组合。
3. 最后定位到根因：我在工具实现里默认信任了技能声明的权限级别，而没有在服务端执行前重新做会话级权限越权校验。

修复方案是双管齐下：一是补全技能工具依赖声明，不让模型在技能声明之外自由引入额外工具；二是在服务端工具执行方法的最前面，增加一个“权限预检”逻辑：无论 Harness 认为这个请求属于什么技能，服务端都会加载会话用户的真实权限，再判断该工具是否可以执行。权限预检通过，才真正调用业务方法。

这个坑让我强烈意识到：外部系统传来的任何元信息，包括技能权限级别，都不能当作安全边界。真正的边界必须收敛在自己这边的服务端代码里。后来我在代码评审里定了一条规则：所有需要对外的工具接口，禁止在方法内部使用调用方传入的权限判断结果，必须重新取数、重新判断。

整个项目上线后，回过头看最有价值的其实不是某个具体的技能写得多聪明，而是这套“Harness + 后台管理系统”的组合，终于把大模型的能力装进了可控的企业应用框架内。现在同事们每天在系统里自然语言发任务，权限不会越界，审批有迹可循，文件统一沉淀在后台附件库。后续如果有精力，我还想把更多日常重复操作拆成更细粒度的工具，让 Agent 能覆盖更多工作流。但前提永远不变：先守住边界，再谈智能。