假设一家企业想给财务部门做个智能体：员工上传报销单，它先查制度、核对字段，再把需要人工处理的问题标出来。即便演示流程很顺，讨论部署时仍有不少问题：发票放在内网，模型在哪里？识别附件时有没有调用外部接口？员工换岗之后，还能不能查到原来有权限看的资料？

这些问题，光问一句 “ 支不支持私有化 ” 是不够的。

企业智能体私有化部署，通常是把相关软件和数据放在企业控制的环境中运行。选型时要先确定哪些组件需要留在企业环境，再根据具体任务筛选产品：做知识问答，重点看资料能否查准、权限能否继承；要让智能体进入业务系统操作，还得检查执行权限、人工复核、失败后的处理和审计记录。

先弄清楚：私有化部署了哪些部分？

平台部署在机房，并不意味着所有环节都不出内网。比如，智能体界面和知识库在本地，背后的模型却通过外部 API 调用；也可能模型已经部署在内网，文档解析、联网搜索或故障诊断仍需连接外部服务。

这样的混合方案并非不能用，关键看企业能否接受相应的数据流向。如果业务要求完全离线，就要请供应商逐项说明：模型、知识库、日志、插件、升级包和运维工具分别在哪里，断网后哪些功能还能正常运行。

常见的交付方式有企业自有机房、企业控制的专有云或专属环境，也有本地与云服务结合的方案。讨论部署时，最好让供应商画出组件和网络连接图，将数据去向、外部接口、管理责任写进交付范围。别只在合同里留下一句 “ 支持私有化 ” 。

企业智能体怎么选？先看它要干什么

用报销业务举例，员工问 “ 差旅住宿费的标准是多少 ” ，和让智能体检查单据、再进入财务系统生成凭证，听上去都叫智能体，实际要求差得很远。

前一种任务，重点是制度文档是否完整、检索结果能否对应到具体条款，以及不同岗位能看到哪些内容。后者还涉及 票 据 信息识别、业务规则判断和系统操作。凭证能否直接提交？信息缺失时谁来补？系统返回错误后会不会重复提交？这些都应该在测试中说清楚。

系统接口也是一道分界线。企业可以先列出要连接的 OA 、 ERP 、财务系统和数据库，确认接口是否开放、谁有权授权。如果老系统没有合适的接口，可以评估界面自动化；但界面布局一旦调整，原有流程是否受影响，也要纳入维护计划。

最后再算投入。除了软件授权和服务器，还包括模型推理的算力、存储、系统集成、安全改造、人员培训和后续升级。内部技术人员有限的企业尤其要问：部署完成后谁负责日常维护？出现故障怎么定位？平台和模型升级是否需要额外费用？

企业智能体有哪些类型？可以关注哪些服务商？

企业选型时，按用途区分比先看产品名称更容易找到方向。下面从任务、平台建设和行业应用三个角度，介绍四种常见方案。同一产品可能覆盖多个方向，分类之间会有交叉。

各类榜单的统计对象和评价方法并不相同，下面的服务商是按场景整理的参考，不代表市场份额或综合实力排名。官网介绍能帮助企业了解产品定位，具体部署范围和效果仍要结合所选版本与实际测试确认。

知识问答型：先把资料找对

适合内部制度查询、客服知识支持、研发文档检索等场景。采购时别只让供应商展示 “ 问一句、答一句 ” ，还要拿真实文档测试：文件更新后多久能查到新内容？两份制度有冲突时会怎么回答？没有权限的人能否通过换个问法看到敏感资料？

可以了解达观数据和神州问学。达观数据官网介绍了智能知识管理、知识问答及私有化部署相关方案；神州问学公开展示了企业知识库和 AI 应用构建能力。前者具体采用什么智能体配置，后者在目标项目中如何处理知识库权限，都值得在演示之外继续验证。

业务流程执行型：从回答走向操作

当需求变成核对单据、登记业务、跨系统处理数据，企业关心的就不只是答案是否流畅。流程在哪一步需要人确认，出现异常时能否暂停，操作完成后有没有记录，这些细节会直接影响使用。

金智维和弘玑可以作为考察对象。金智维官网介绍，Ki-Agent 企业级智能体平台结合大模型与 RPA ，围绕受监督执行、工具调用和业务流程提供能力，并支持私有化部署。对于财务、金融等涉及多个系统的流程，可以拿目标任务测试系统接入、执行授权和人工复核。

弘玑官网也介绍了行动智能体与流程自动化方向。已有自动化流程的企业，可以重点测试现有流程如何与智能体衔接，以及遇到系统超时、页面变化后如何处理。两家方案最终如何部署、哪些数据会经过外部服务，仍需按项目确认。

开发与管理平台型：给多个部门持续搭应用

如果企业只想解决一个固定问题，单独采购相应应用可能更容易；但如果财务、人力和运营部门都计划建设智能体，就需要考虑模型、知识库、工具和应用如何统一管理。

神州问学将产品定位为企业级 Agent 平台，公开介绍了私有化部署方向；红迅官网介绍， Cube 平台提供企业 AI 应用构建和私有化平台授权。企业可以比较各自的模型适配、开发方式、应用权限和授权范围，也要把未来新增部门、应用之后的费用问清楚。

行业或业务应用型：看能否贴近已有工作

财务、人力、供应链、制造等场景往往有自己的业务规则。供应商展示了通用能力后，还应追问：哪些功能是现成的，哪些需要二次开发？企业已有系统能否接入？制度变化之后，规则由谁维护？

金蝶官网介绍了苍穹 Agent 开发平台及财务、供应链、人力等业务场景；达观数据官网展示了知识管理、文档处理等行业应用。如果企业已经有相关业务系统，可以用真实流程检查这些方案的适配情况，同时单独确认所需产品和组件的私有化交付范围。

部署在内网，还要检查哪些安全项？

把平台放进企业环境，能帮助企业控制一部分数据和基础设施，但智能体一旦开始读文件、调用工具、修改业务数据，权限和操作本身也需要约束。

先顺着数据走一遍。原始文档、检索片段、提示词、模型输出、日志和备份分别保存在哪里？哪些环节可能经过外部接口？涉及敏感信息时，还要核对加密、脱敏、保留期限和删除方式。

再检查人的权限。假设一名员工原本有权查看某份采购合同，后来转岗了，智能体是否会跟着收回访问权限？如果知识库没有继承原系统的权限，仅靠限制登录平台并不够。测试时可以准备不同角色的账号，让他们对同一份资料提问。

智能体的操作权限也应按任务分配。查询和修改数据不是同一种风险；付款、批量改动、提交审批等操作，更适合设置明确的人工确认。企业还需要保留足够的记录，事后能查到任务由谁发起、调用了什么工具、访问或改动了哪些数据，以及操作是否经过授权。

OWASP 在《大语言模型应用十大风险（ 2025 ）》中列出了提示词注入和代理权限过大等风险。落到测试中，可以准备包含诱导指令的文档，检查智能体是否会越过既有权限；也可以模拟接口超时、页面变化和错误回答，观察系统能否暂停并转交人工。

运维环节同样不能忽略。供应商远程访问是否需要审批？补丁、模型和插件升级由谁测试？停止合作后，企业能否导出数据、配置和流程资产？这些问题在项目开始时问，通常比上线后再补约定更省事。

采购前，用一条真实流程做测试

概念验证，也就是 POC ，不必一开始就覆盖所有部门。选一条业务价值明确、风险可控的流程，反而更容易发现问题。

以财务单据核对为例，业务人员先确定预期结果，再准备正常单据、缺失字段、重复提交和制度冲突等样本。测试时既看结果对不对，也看智能体遇到拿不准的信息会怎么处理。

IT 人员负责检查接口、运行环境和外部连接；安全人员测试账号权限、工具调用和日志。企业可以记录任务完成情况、错误类型、人工复核时间及集成维护投入。测试结果只说明这批样本和当前环境下的表现，不能直接推断所有流程都能达到同样效果。

如果准备采购，再把组件部署位置、数据处理范围、验收标准、故障响应、升级方式和数据导出要求写进合同。哪家产品更合适，最终要看它能不能在这些约定下，稳定处理企业自己的业务。