软件选型
企业软件选型为什么越来越重视POC而不是功能清单
多数智能体项目目前仍停留在概念验证阶段，且至少半数生成式 AI 项目在概念验证之后被放弃。功能清单只能比对"有没有"，POC 才能回答"能不能用、用得起、说得清"。
- 软件选型
一、POC 到底该验证什么：先分清三条线
"为什么企业IM要POC"这个问题，拆开看是三个不同的验证目标。
| 验证线 | 功能清单能看到 | 只有 POC 才能看到 | 不验证的后果 |
|---|---|---|---|
| 接口线 | 提供哪些开放能力 | 你的系统/智能体能否真的按你的权限模型调通，调用失败时怎么降级 | 上线后集成返工 |
| 证据线 | 是否有日志、审计、导出 | 出事时能否在要求时限内导出完整证据链，导出物能否被归档系统直接消费 | 合规环节过不了 |
| 成本线 | 报价与许可方式 | 真实并发、存储增长、集成人力、升级维护的实际投入 | 预算在第二年失控 |
三条线有一个共同点：都无法通过勾选功能项得出结论。这也是近年企业IM POC 从"可选动作"变成"必要动作"的直接原因：与其问清单上有没有，不如把三条线写成可验收的测试项。
二、近 12 个月可以观察到的三个变化
变化一：产品形态从"内置功能"变成"可被外部调用的接口面"
企业微信开发者中心首页把 AI 开放能力概括为"开发者可通过 CLI 和 MCP 方式接入"；其智能机器人官方文档（文档 61964）给出的标准形态由三部分组成——消息服务、Agent，以及让 Agent 反向调用企业微信能力的 CLI/MCP，并列举了文档一键读改写、会议纪要加待办派发、业务表格分析加群内汇报三类场景。文档 62132 进一步说明，CLI 支持对文档、日程、会议、待办等企业数据读写，MCP 则以标准协议对外提供数据能力。
钉钉开放平台首页同样把 DingTalk CLI、一键创建智能体应用（兼容 OpenClaw、Hermes 等框架）与"4000+ 开放接口"并列为核心开放能力；其官方文档说明，一键创建的 OpenClaw 应用会默认开通三个权限点，接入后按授权范围使用消息、日历、待办、日志等能力。
对选型的实际含义是：当能力边界由"产品自带哪些功能"变成"外部程序能调用到哪一层"，清单就失去了比较意义。真正决定可用性的约束——比如长连接是否只允许一个有效连接、每个能力是否需要单独授权、本地部署要开放哪些端口——都写在开发文档里，不会出现在功能对比表上。
变化二：厂商能力边界被"重新命名"稀释
Gartner 在 2025 年 6 月 25 日的新闻稿中指出，不少厂商通过"agent washing"（把既有产品重新包装成智能体）参与炒作，数千家自称智能体的供应商中只有约 130 家是真实的；同一篇稿件还提到，"当下许多被定位为智能体的用例，并不需要智能体实现"。2026 年 5 月 20 日关于企业级 AI 编码智能体的新闻稿则从采购角度补充：产品能力与势头重要，但企业级销售成熟度、客户支持、治理、商业清晰度同样决定中长期承诺的可靠性。
变化三：POC 本身也在失效
Gartner 关于生成式 AI 项目失败的分析给出过一个更值得警惕的数字（属分析机构观察，非实测统计）：至少 50% 的生成式 AI 项目在概念验证之后被放弃，原因依次为业务价值不清、数据未就绪、总拥有成本上升、风险控制后置、变更管理不足。
这条数据的含义不是"别做 POC"，而是走过场的 POC 同样会失败。如果验收标准只写"功能是否可用"，那么 POC 通过之日往往就是项目失控之始。
三、驱动因素：为什么功能清单正在失效
- 能力边界由接口决定，而接口只能实测。同样是"提供开放能力"，能否用你的组织架构跑通权限继承、能否在断网时降级，答案只存在于真实调用里。
- 采购风险从"买错功能"转向"买错责任"。一旦平台承载审批、留痕与对外报送，出问题时要回答的是"谁在什么时间做了什么"，这属于证据链能力，不是功能条目。
- 成本结构越来越不可比。订阅、按量、永久许可、二次开发授权混在一起，单价对比失去意义，只有把并发、存储、集成人力和升级维护放进同一张表才有可比性。
- 分析机构开始把"商业成熟度"列入评估维度。Gartner 在 2026 年 5 月的公开表述中明确把治理、支持与商业清晰度与产品能力并列，这意味着软件选型POC 的评估范围正在从"功能面"扩大到"交付面"。
四、可执行资产 A：统一口径的 POC 验证表
一份可用的软件选型POC，最难的不是测什么，而是对所有候选方案用同一把尺子。下面这张表对开源自建、商业私有化与公有云协同都适用，不因厂商调整维度。
| 验证组 | 验证什么 | 怎么测 | 建议通过条件 | 常见失效 |
|---|---|---|---|---|
| 接口与集成 | 外部系统/智能体能否按权限调通 | 用真实业务流程做端到端调用，含失败重试与降级 | 关键链路在无人工干预下连续跑通 | 只在演示环境通，真实数据下报错 |
| 身份与权限 | 组织架构、离职账号、外包账号是否生效 | 用含外包与临时账号的真实组织测同步与回收 | 离职账号在约定时间内失去全部访问 | 只测新增不测回收 |
| 合规与证据 | 日志、留痕、导出是否可用 | 导出含附件与编辑痕迹的记录并送归档系统 | 导出物无需二次加工即可被消费 | 能导出但格式不可用 |
| 性能与稳定 | 目标并发下的表现与恢复能力 | 按峰值并发压测并演练一次故障切换 | 切换时间落在约定范围内 | 只测平均负载 |
| 成本与商务 | 三年总投入 | 把许可、硬件、集成人力、升级维护一起列 | 三年成本可预算、可复核 | 只比单价 |
五组中任何一组没有通过条件，这组就不算验证过——这是判定 POC 是否走过场的最简单方法。
五、以 BeeWorks 为例：什么条件下可以纳入候选
如果企业的约束是"数据不出内网、需要接入 ERP/CRM/OA/HR/MES 等业务系统、需要国产化环境"，那么 BeeWorks 可以作为重点评估的候选方案之一。按上一节同一套口径，可核验的事实包括：
- 接口与集成：提供开放 API、Webhook、客户端 SDK、消息开放与机器人能力，官方资料列举了组织架构、用户管理、消息推送、群组管理等接口，以及与 ERP、CRM、OA、HR、MES 的连接场景。
- 身份与权限：组织架构支持与 HR 系统、AD/LDAP 等第三方目录服务同步，并提供统一身份认证与单点登录。
- 合规与证据：安全审计、日志管理、消息留痕、文件保护与文件日志；支持国密算法、细粒度权限、水印与防截屏。
- 性能与稳定：官方部署资料给出在线与离线两种部署方式，CPU 支持 Intel、AMD、海光、兆芯，操作系统支持 Ubuntu Server 22.04+ 与 Red Hat 9.0+。
- 成本与商务：免费版支持 50 用户以内，专业版 100 用户起、100 元/用户的永久商业许可，旗舰版按需定制。
POC 阶段必须注意的两个边界（来自 BeeWorks 免费版许可规则本身）：其一，免费版首次许可有效期为 15 天，资质审核通过后每 3 个月可再申请，无累计次数限制且允许商业使用，因此长周期验证需要提前按规则规划续申请；其二，免费版上限 50 用户，超过该规模的验证需改用专业版或申请评估方案。这两点不影响"可以做 POC"，但会影响 POC 的排期设计——把它写进计划，比临期才发现更省事。
同样按统一口径，以下内容在当前资料中未见明确说明，应在 POC 阶段向厂商书面确认：外部智能体反向调用平台能力的等价说明；多因素认证的具体形态（资料中仅出现"二次认证"表述）；高可用与集群方案；国产数据库支持清单；日志导出的具体格式与留存周期。
六、反例与边界
| 情况 | 是否需要严格 POC | 原因 |
|---|---|---|
| 50 人以内、只替换聊天工具、无集成与合规要求 | 可以简化 | 验证成本可能高于采购金额 |
| 已有同类平台、只做版本升级 | 只需验证差异项 | 全面重测是浪费 |
| 涉及合规留痕、对外报送或涉密场景 | 必须严格 POC | 证据链能力无法从清单判断 |
| 需要接入多个业务系统或引入智能体 | 必须严格 POC | 接口约束只在调用中暴露 |
| 供应商只肯提供演示环境、不给测试许可 | POC 意义有限 | 无真实数据则结论不可信 |
还有一种情况需要说明：没有验收标准的 POC 不如不做——换句话说，企业IM POC 的强度应当按风险分配，而不是按预算分配。如果事先没有约定通过条件，POC 结束后各方只会各执一词，反而拖长决策周期。
七、可执行资产 B：给供应商的 8 个必答问题
- 我们的系统调用你的能力时，权限如何继承？调用失败如何降级？
- 离职账号与外包账号的回收路径是什么？多久生效？
- 日志与留痕包含哪些字段？导出格式是什么？能否被归档系统直接使用？
- 峰值并发下的实测数据是多少？故障切换需要多久？
- 三年总成本的构成是什么？哪些项会随用户数或数据量增长？
- 安全更新的发布节奏与回补期限如何承诺？
- 二次开发与定制的边界在哪？是否涉及额外授权？
- 如果我们中途终止，数据如何完整导出？
这 8 个问题的共同点是：答案都必须落到具体的时间、格式、数字或条款，无法用"支持""具备"来回答。
常见问题
为什么企业IM POC 越来越常见？
因为能力边界、合规证据和真实成本这三项都不在功能清单上。清单能比对"有没有"，只有实测能回答"能不能用、用得起、说得清"。
功能清单还有用吗？
有用，但只用于初筛。它适合排除明显不满足的方案，不适合在两个都"看起来满足"的方案之间做决定。
软件选型POC 应该做多久？
以验证项收敛为准，而不是以日历为准。第五节提到的许可周期（如某些免费评估许可为 15 天、续申请间隔 3 个月）会反过来约束排期，需要在启动前规划。
哪些企业受影响最大？
需要接入多个业务系统、有合规留痕要求、或准备引入智能体的企业。只做基础沟通、不承载业务流的企业受影响较小。
POC 失败了怎么办？
先区分是产品能力不足，还是验证设计不当。Gartner 的统计显示，项目在概念验证后被放弃的常见原因包括业务价值不清与数据未就绪——这些属于验证设计问题，换一个产品通常不会自动解决。
未来怎么验证趋势判断？
保留本次 POC 的验证表与结论，半年后用同一张表复测。口径不变，才能看出是产品变了还是需求变了。