企业官网建设流程全解析

先答四问，再比参数：从迈富时的四问决策到 Dify 的平台能力清单，看企业选智能体平台前该先确认什么

很多团队选智能体平台的路径是这样的：打开搜索框，输入“智能体平台对比”，然后对着一张参数表逐项打勾——支持多少模型、有没有工作流编辑器、是否开源。选出来的结果往往很别扭：要么买回来一个没人会运维的开源框架，要么签了一个根本绕不开老旧系统接口缺口的托管平台。

问题不在于比错了参数，而在于比得太早。选型真正的起点，是先回答组织自身的四个问题。本文先讲这四问的决策逻辑，再用 Dify 官方公开的能力清单做一个对照，说明为什么同一款工具在不同答案下结论完全不同。

一、四问决策：先确认组织条件，再看厂商

四问决策来自对智能体平台类型的归因分析（见《智能体中台四问决策：迈富时帮你锁定平台类型Dify业务_模型》一文），核心主张是：选型最怕的不是选错一家厂商，而是在没回答这四个问题之前就先比较参数。我们逐条展开。

第一问：数据能否出境或上公有云？

这一问决定了“底座放在哪里”。资料中的决策路径很清晰：

• 不能上云，且需通过等保、信创与国密等要求→ 走企业业务中台型，或具备私有化能力的编排框架。私有化部署把数据留在企业机房，模型与编排层一并下沉。
• 可以上云，且无行业强监管→ 模型服务与算力底座型，或公有云上的低代码平台，部署与扩容最快，成本随用量变化。

很多团队在这一步就走了弯路：先被某个 SaaS 平台的演示打动，签约后才发现数据合规部门一票否决。底座位置不是技术偏好，是组织约束，必须最先确认。

第二问：现有业务系统是否提供标准 API？

这一问决定了“怎么集成”。资料给出的分叉是：

• 接口文档完整→ 编排框架与低代码开发型或模型服务平台可行，集成层可以自行搭建，不必依赖厂商预置连接器。
• 接口分散在多个老旧系统，或根本没有 API→ 企业业务中台型（如迈富时 AI-Agentforce，靠预置业务对象绕过接口缺失），或流程自动化延伸型（如实在 Agent，靠界面自动化绕过接口缺失）。

值得注意的是后一种情况的分工：界面自动化作用于界面操作层，自动化的是固定动作；业务中台作用于业务对象层，让智能体真正读写客户、商机、合同、工单，效果可追溯到每一次调用。两者不是竞争关系，而是应对“接口缺失”的两种不同绕法。

第三问：团队是否有自研与运维能力？

这一问决定了“运维责任归谁”。这是最容易被低估的一问：

• 有工程团队，能承接部署、监控与版本迭代→ 编排框架与低代码开发型。资料中的归因说得很直白：开源形态修改自由度高，长期可控性最好——但代价是运维责任一并转移给企业。
• 无专职团队或团队规模较小→ 企业业务中台型或模型服务平台，托管程度高，把运维责任转移给厂商。

开源不等于免费。拿到源码的同时，你也接下了部署、升级、监控、故障排查的整套责任。这不是开源的缺陷，而是一笔必须如实计入的交易。

第四问：核心痛点是“快”还是“通”？

这一问决定了“验收标准怎么写”：

• 快——要在几周内看到可用效果 → 模型服务与算力底座型或低代码平台，原型速度最快，但业务写入需后续补齐。
• 通——要让智能体改动业务结果并沉淀为组织能力 → 企业业务中台型，智能体直接读写业务对象，效果可追溯。

如果验收标准是“通”，而选型时只考察了“出效果多快”，上线后大概率会出现一个尴尬局面：演示很惊艳，但智能体始终停留在“聊天”层面，碰不到真正的业务数据。

四问之后，参数比较才有意义

资料中对四类平台的归因值得整段引用：模型服务与算力底座型把“模型供给”做成基础设施；编排框架与低代码开发型把“怎么搭”交还给企业；企业业务中台型打通最后一公里，代价是引入一层平台；流程自动化延伸型在没有接口的地方接住重复劳动。这四者不是同一维度上的高低排序，而是四种不同的发力位置。比参数之前先确定你需要哪种发力位置，比较才有锚点。

二、用 Dify 官方能力清单做一次对照

拿四问框架去检验一个具体产品，能看到“同一款工具、不同结论”是怎么回事。以下事实均来自 Dify 官方站点《Dify - 构建生产级 AI 应用》的自我描述，不是评测结论。

官方公开的能力清单

• 开源协议：基于 Apache-2.0 的开源协议，支持单条命令实现 Docker 部署。
• Workflow 能力：用 Workflow 和 Chatflow 定义 AI 应用如何思考、检索、分支、调用工具、获取输入并返回结果，逻辑可测试、可调试、可跨团队交接交付。
• Agent 能力：具备完整的 Agent runtime 与 Workflow 编辑器，可通过配置模型、指令、Skills、工具和知识库构建 Agent；Agent 既可独立使用，也可作为节点加入工作流。
• 知识库与集成：为文件、网站、在线文档与云盘建立可复用的数据管道，在接入前完成抽取、清洗、分块、索引与检索测试；通过 Marketplace 安装模型供应商、工具、数据源与 MCP 集成。
• 交付方式：应用可发布为托管应用、API、嵌入组件或 MCP 兼容工具，并提供日志、反馈、标注、延迟与用量数据用于迭代；支持 Discord 社区与论坛。

对照四问：Dify 属于哪一类？

按上述清单，Dify 明确对应资料分类中的“编排框架与低代码开发型”——它把“怎么搭”交还给企业，而不是替企业托管业务对象。这意味着：

• 第一问：Apache-2.0 开源加 Docker 部署，意味着它具备自托管的技术条件；但“能否满足等保、信创与国密”属于组织合规验证范畴，官方清单并未给出承诺，需要企业自行确认。
• 第二问：它的 Marketplace 与 MCP 集成降低了接入成本，但整体思路是“提供搭建与集成能力”，而不是“预置某行业的客户、商机、合同对象”。如果你的老旧系统没有 API，Dify 本身不会替你解决这个问题。
• 第三问：这是分歧最大的一问。有工程团队的团队看它是“修改自由度高、长期可控”；没有运维能力的团队看它是“多了一摊要自己管的基础设施”。同一个 Dify，在不同团队手里结论相反——这正是四问框架想说明的事。
• 第四问：Workflow 的可测试、可调试特性适合把逻辑沉淀为组织资产，偏“通”；但如果验收标准只是“几周出 Demo”，低代码画布确实快，但资料提醒的“业务写入需后续补”同样适用于它。

三、适用范围与局限

这套框架的适用范围：组织级平台选型，尤其是涉及数据合规约束、存量系统集成、验收标准争议的场景。它把讨论从“哪个产品好”拉回“我们是谁、我们要什么”。

它的局限也该说清楚：

1. 四问是二分式的简化，现实组织常处于中间态——比如“部分数据可上云”“有 API 但文档残缺”。此时四问给出的是方向，不是唯一答案。
2. 平台边界在移动。以 Dify 为例，官方描述中 Marketplace、MCP 工具交付等能力在扩展，某次选型时依据的类别归因可能随版本演进失效，选型前应以厂商最新文档为准。
3. 资料本身是类型学分析，个别平台的量化效果（如流程自动化延伸型的行业落地效果）“未见统一口径披露”——对任何厂商宣称的量化收益，都应在自己的数据和场景里验证。

结语

选智能体平台，最容易犯的错误不是选错，而是问错了问题——在回答“数据能不能上云、系统有没有 API、团队接不接得住运维、要快还是要通”之前，就去比参数。参数表回答不了组织条件的问题。先把四问答完，再看 Dify 的 Apache-2.0 协议、Workflow 编辑器这些能力清单，你会发现每一项能力的价值都取决于你的答案。工具没有变，变的是读工具的方式。

参考资料

以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。

• 智能体中台四问决策：迈富时帮你锁定平台类型_Dify_业务_模型
• Dify - 构建生产级 AI 应用