企业官网建设流程全解析

导语：模型能力持续升级，但企业级 Agent 最难的部分，往往不在模型本身。

从内网、权限、审计到稳定性，真正决定项目能否上线的，是一套可以按现场约束拆开、替换并重新组装的工程底座。

目录

最近半年，我大部分时间都在客户现场。

角色是前沿部署工程师，英文叫 Forward Deployed Engineer，简称 FDE。

这份工作一句话能说清：把 AI 真正用进客户的业务里，而不是停在演示上。

它和普通工程师不一样。KPI 不是代码有没有提交，是问题有没有解决、价值有没有显现。

问题，几乎全都堆在"最后一公里"。

配图：企业级 Agent 从模型能力到生产落地的最后一公里

一、模型已经不是最大的障碍

做这行之前，我以为最大的难点会是模型。

后来发现不是。

模型接口在变，能力在涨，但这部分反而不是最耗精力的。

真正难的是客户的环境。

客户的系统是老的，数据是脏的，权限是一层套一层的，网络还经常是隔离的。

一个在演示环境里跑得飞起的 Agent，扔进客户机房，往往第一步就卡住。

要么连不上内网，要么写不进文件。

要么每个动作都要弹确认，要么跑完之后，谁也说不清它到底做了什么。

我在不同客户之间，反复遇到同样的问题。

每次都要重新搭一遍：工具、权限、日志、审批、沙箱。

搭完 A 客户，B 客户的约束又变了。

一套东西，换一个现场，就废一半。

这让我开始重新想一个问题：企业落地，到底缺的是什么。

FDE 的三种工作方式

做久了，我把 FDE 的工作方式归纳成三条。

1. 需求逆向驱动

   不是从技术能做什么出发，而是从客户现场的真实痛点倒推，需要什么，才上什么。

2. 跨域能力迁移

   一个客户踩过的坑，抽象成可复用的组件，带到下一个客户，而不是每次都重写。

3. 透明化保障落地

   每一步都留痕、可解释，让客户敢把生产环境交给你。

这三条，写出来很朴素。

但真正在现场能同时做到的人，不多。

这大概也是这个岗位难做、又不可替代的原因。

二、一个真实的现场

说一段我印象很深的经历，你会更清楚 FDE 面对的是什么。

客户是一家传统企业，IT 系统跑了十多年。

他们要的不是"上个 AI"，是一条真实的业务：把分散在几个老系统里的单据，自动整理、核对、汇总。

听上去不难，落地时全是坑。

第一个坑，是内网。

客户的 Agent 环境不能直接出公网，模型只能走内部网关。

第二个坑，是权限。

不同角色的员工，能看的数据范围不一样，Agent 也必须遵守同一套边界。

第三个坑，是审计。

财务数据，每一笔都要能说清"谁、在什么时候、做了什么、结果是什么"。

第四个坑，是稳定。

跑批处理时，一个超时的调用，可能让整条流水线卡住。

这四个坑，没有一个是模型能力问题。

它们全是工程问题、边界问题、留痕问题。

我在现场花了大量时间，不是在调模型，是在搭这些"外围"。

而恰恰是这些外围，决定了项目能不能真的上线。

三、我接触到了 deepseek-harness

后来我接触到了 deepseek-harness。

它是一个基于插件的 Agent 底座，底层是裁剪过的 Cordis。

它最核心的一条原则，是"一切皆插件"。

模型适配器、工具、文件系统、会话存储、沙箱，甚至 Agent Loop，全都是插件。

跑起来的一整套系统，本质就是一棵由配置组装出来的插件树。

配图：deepseek-harness 由配置组装的插件树

第一次看清这一点的时候，我愣了一下。

因为我意识到，它和 FDE 的工作方式，其实是同一件事。

FDE 的工作，就是在每个客户现场，把通用能力重新组合成一套能落地的方案。

而"一切皆插件"，恰好把这种"重新组合"，变成了系统本身的能力。

这很激进。非常厉害。

四、能力接缝：定义、提供、消费

deepseek-harness 里有一个概念，叫"能力接缝"。

这个名字听起来抽象，拆开其实很简单。

一个能力接缝，由三个角色组成：定义、提供、消费。

• 定义，是说清楚这个能力是什么、长什么样。

• 提供，是真正实现它的那一层。

• 消费，是使用它的那一方。

三者各归其位，边界清晰。

拿文件系统举例。

文件系统是一个能力接缝，策略层负责定规则，本地实现负责真正读写，Agent 的工具负责调用。

要做边界控制，就在策略层写清楚，而不是在循环里埋一坨 if。

这个拆法，对个人工具来说，有点过度设计。

对企业的多现场交付来说，它刚好是需要的。

因为 FDE 最怕的，就是能力搅在一起，改一处牵动全身。

五、注册即副作用，卸载即撤销

还有一点，我特别想讲。

在 deepseek-harness 里，插件往共享上下文里注册的每一样东西——服务、事件、界面——都是一次"副作用"。

这个说法听起来吓人，其实是好事。

因为每次注册，都会返回一个"撤销器"。

插件卸载的时候，对应的注册跟着撤销。

想换掉某部分能力，通常只需要在配置树里替换一项，或者插入一个新插件。

对 FDE 来说，这解决了一个很实际的痛点。

客户现场的需求会变，今天要这个工具，明天可能就要撤掉，换成另一个。

能力如果不能干净地拆下来，替换就是一场灾难。

能挂上去，也能卸下来，这不是锦上添花，是现场交付的基本功。

六、五个企业级关卡

我把企业落地里最磨人的事，归纳成五个关卡。

下面一个一个说，deepseek-harness 分别怎么解。

关卡一：文件系统与边界

企业环境里，Agent 能碰哪些目录、不能碰哪些目录，是一件必须说死的事。

不能让它读到不该读的，也不能让它写到不该写的。

deepseek-harness 把文件系统做成独立的能力，带策略。

目录边界、符号链接检查，都能在策略层写清楚。

工作区根目录不能被越过去，符号链接也要额外检查。

这比我过去在每个项目里手写一坨权限判断，要可靠得多。

关卡二：权限与审批

企业客户最怕的，是 Agent 自作主张。

它的交互层，把审批、权限、命令、问询都做成了可插拔的能力。

哪些操作要人确认、哪些可以放行，在配置里定，而不是硬编码进循环里。

要拒绝就拒绝，要允许一次就允许一次，要永久放行就永久放行。

配图：企业 Agent 的权限审批流程

这个灵活性，在现场几乎是必需的。

因为不同客户对"哪些动作可以自动做"的容忍度，差得非常远。

有的客户连读文件都要确认，有的客户只关心写操作。

一套能配的审批，比一套写死的默认，更能适配这种差异。

关卡三：沙箱与护栏

现场跑 Agent，最怕它越界，也怕它卡死。

deepseek-harness 有独立的沙箱能力，还有专门的护栏插件，管循环卫生和工具超时。

出错了能停，超时了能断。

这两点在个人工具上无所谓，在客户生产环境里，是刚需。

因为一个跑飞的 Agent，在客户那里留下的，不是"一次失败"，而是"一次事故"。

一次事故，可能毁掉客户对整个 AI 项目的信任。

关卡四：留痕与审计

这是我最看重的一个。

我在客户现场，最常被问的一句话是：它刚才到底干了什么？

deepseek-harness 有一条很硬的约束：凡是被模型看到的东西，都必须能从会话日志里重建。

每一轮 Agent 收到的上下文、调用的工具、每一步的输入输出，事后都能查出来。

会话日志还带版本机制，格式变了会显式升级，而不是悄悄不兼容。

配图：会话日志与工具调用审计轨迹

对个人工具来说，这条约束有点较真。

对企业的合规审计来说，它是底线。

财务、法务、数据安全，这些部门不会问"它聪不聪明"，只会问"它可不可查"。

关卡五：模型与凭据

企业的模型来源五花八门。

有的是公有云，有的是私有化，有的是集团统一采购的网关。

API Key 怎么放，也牵扯安全。

deepseek-harness 把凭据做成独立能力，支持环境变量和 .env 文件，不把密钥写死在代码里。

模型路由、服务商配置、凭据存储，各是各的插件，边界保留得很清楚。

这一点，恰恰是企业采购时会被反复盘问的地方。

七、显式，大于隐式

deepseek-harness 还有一个原则，叫"显式大于隐式"。

意思是，在包的边界上，任何默认值，都要显式地做一次解析，而不是藏在实现里偷偷用默认。

我第一次看到这个原则时，觉得它很较真。

后来在客户现场，我慢慢理解了。

企业环境里，最怕的就是"我以为它默认这样"。

网络走没走代理，超时是多少，权限开到哪一档，这些一旦靠隐式默认，就会在某个深夜突然炸出来。

显式地写清楚，代价是多写几行配置。

换来的，是现场不会出现"说不清它为什么这么干"的悬案。

这条原则，和 FDE 的信条是一致的：把话说在前面，比事后解释强。

八、它没有让落地变轻松

我要说清楚，这条路并不省事。

deepseek-harness 目前的使用门槛，仍然偏高。

它是给工程师用的底座，不是开箱即用的产品。

FDE 还是要写配置、要懂插件边界、要在客户现场反复调。

插件化没有让落地变轻松，它只是让"这次踩过的坑"，下次能少踩一遍。

而且，插件拆得越细，第一次把它们拼对，就越费劲。

能力接缝、注册即副作用、会话格式版本……这些概念，得花时间才能真正吃进去。

配置写错了，它会显式报错，而不是静默跳过。

这很好，但对赶工期的人来说，意味着更高的上手成本。

还有一点要承认：它现在更像一个"准备接口"的阶段，离成熟的 C 端产品还很远。

没有那种开箱即用的顺滑，没有一键部署的承诺。

如果你想要的是一台买回来就能开的车，它不是。

它给你的，是一套能拆能装的零件，和一张还算清楚的装配图。

九、为什么不做成 no-code 平台

有人可能会问：企业落地这么难，为什么不做成拖拽式的 no-code 平台？

这个问题我想过。

我的答案是：现场太杂，no-code 反而更快触顶。

no-code 平台擅长的是标准场景——流程固定、边界清晰、输入输出可预期。

但 FDE 面对的现场，恰恰是反过来的：遗留系统、脏数据、复杂权限、隔离网络。

这些场景里，真正难的从来不是"把流程画出来"，而是"把边界和异常处理对"。

no-code 的封装，在这些地方往往会变成墙。

你被它挡在通用能力之外，够不到真正需要定制的那一层。

deepseek-harness 选择的方向，是往下拆，而不是往上封。

拆开之后，FDE 才能把手伸进去，按现场的需要重新拼。

这不一定是对的，但它至少回答了那个问题：为什么现场工程师，更需要的是零件，而不是模板。

十、把它当成一套"零件库"

所以我现在更愿意把它看成 FDE 的一套"零件库"。

每个客户现场，都是一次重新组装。

工具可以换，权限可以配，留痕一直在。

客户要私有化，就把底座塞进内网。

客户要合规，就把审计能力挂上。

客户要跑在 Windows 上，就换对应的 shell 提供者。

客户要接自己的内部系统，就补一个自定义的工具插件。

这种可替换的结构，恰恰是前沿部署最需要的东西。

它没有承诺"一次部署，处处可用"。

它承诺的是另一件事：拆开的零件，可以按现场重新拼。

这句话不性感，但真实。

一句话总结：对于 FDE，deepseek-harness 的价值不在于替你消灭复杂度，而在于把复杂度拆到可识别、可配置、可替换的位置。

十一、我不确定它能走多远

最后说点实在的。

现在做 AI 产品，变化速度太快了。

模型接口会变，Agent 的工作方式也在变，今天觉得稳定的交互，过几个月可能就要重新设计。

能力全都绑在一起，每次调整都会带出一串迁移工作。

deepseek-harness 选择先把系统拆开，允许使用者重新组合。

这条路对不对，我说不准。

但我能看到它的好处：需要维护的范围比较清楚，不会把整套东西拖进长期分叉。

以后如果 Agent 要参与调整自己的配置，至少已经有一套可以识别和替换的组件结构。

这离 Agent 自己进化产品还很远，目前更多是在准备接口。

可我愿意看这种尝试。

前沿部署最缺的，从来不是更强的模型，而是一个能经得起反复拆装的底座。

deepseek-harness 给了我这个选项：不必每次从零开始。

我愿意继续在这条路上试下去。

也愿意把试出来的坑，继续记下来，讲给下一个还在客户现场的同行听。

附：FDE 用 deepseek-harness 落地的四个动作

如果你也是做前沿部署的，下面是我自己梳理的四个动作，仅供参考。

第一步：先别急着写代码，先把现场约束列出来

能访问哪些目录，哪些操作要审批，日志要留到多细，模型从哪来，跑在什么系统上。

这些约束，才是后面所有配置的输入。

第二步：把约束映射到能力接缝

文件边界对应 fs 能力，审批对应交互能力，留痕对应会话能力，模型对应 llm 能力。

先分清哪些是定义、哪些是提供、哪些是消费。

第三步：用配置组装，而不是改源码

能通过 cordis.yml 解决的，就不要去动实现。

插件树一旦立起来，换现场就是换配置，不是重写。

第四步：留痕永远开着

不管客户有没有要求，会话日志都保留完整。

它不只在审计时救你，也在排障时救你自己。

本文基于 deepseek-harness 的公开架构与 FDE 的现场实践经验写成，仅代表个人观察，不代表任何官方立场。