这是一份基于公开案例与项目实践的行业观察，不是市场预测。结论只代表我们在一线交付中看到的情况。
一、2023-2024：为什么大量项目停在了 POC
那两年企业做大模型，主流形态是「知识库问答」：把制度、手册、产品文档丢进去，做一个聊天窗口。
上线半年后的普遍结局是：
- 使用率低：员工试过两次就不用了，因为「去问同事更快」；
- 无法归因：答错了不知道错在哪，答对了也无法证明依据；
- 不进流程：它只是一个外部工具，和 OA、ERP、工单系统没有关系。
根因不是模型不够强，而是这些项目只做了「查」，没做「办」。业务真正的痛点往往不是「找不到规定」，而是「这条规定怎么落到这单业务上」。
二、2025 年的转折：从问答到执行
2025 年之后，项目形态明显变化，共同点是模型开始调用系统、承担步骤：
| 场景 | 过去 | 现在 |
|---|---|---|
| 合同审核 | 检索相似条款给人看 | 逐条比对 + 标注冲突 + 生成偏离申请单 |
| 采购对账 | 导出台账人工核 | 三单匹配 + 风险分级 + 自动路由审批 |
| 设备运维 | 查维修手册 | 读告警 + 调历史工单 + 给处置建议 + 派单 |
| 经营分析 | 拉报表 | 多源取数 + 归因 + 情景推演 |
评判标准也随之变化：不再问「回答准不准」，而是问「这件事原来几个人几天，现在几个人几小时，错误率降了多少」。
三、当前的四条技术主线
1. 推理能力下探
推理模型（o 系列、R1 类）把多步推理变成可训练的能力。企业开始把它用在规则复杂、需要权衡的场景：合规判断、报价策略、故障根因分析。
代价是延迟与成本，所以普遍做法是路由分层：简单问题走小模型，复杂问题才升级到推理模型。
2. 工具编排成为核心工程
真正决定效果的往往不是模型，而是工具的质量：
- 接口是否幂等、是否有明确错误码；
- 失败时能否降级到备用数据源；
- 每个节点是否可观测、可回放。
我们在项目里常见的情况是：工具层改造占整个工作量的 60% 以上，模型选型反而只花几天。
3. 多角色协同与仲裁
单模型「综合考虑」容易把分歧平均掉。更可靠的做法是让财务、法务、技术视角各自出结论，仲裁层显式列出冲突并阻断高风险输出。这在金融、医药、工程类决策中尤其必要。
4. 私有化与可控性
数据不出内网是硬门槛。2025 年之后开源模型（Qwen、DeepSeek、Llama 系列）在多数企业任务上已达到可用水平，私有化部署的性价比显著提升。与之配套的需求是：字段级权限、动态脱敏、审计日志、模型与知识库的版本管理。
四、采购还是自建
我们的判断标准是三个问题：
- 这件事是不是你的核心竞争力？ 是 → 自建；不是 → 采购成熟产品。
- 数据能不能出去？ 不能 → 必须私有化，选开源模型 + 本地部署。
- 流程改造的权限在你手里吗？ 不在 → 先解决组织问题，工具解决不了。
一个常见的错误是：用采购的通用 Agent 平台去套一个高度定制的流程，最后发现既改不动流程，也改不动产品。
五、2026 年的三个现实约束
- 数据质量仍是天花板。多数企业的文档没有结构、版本混乱、口径不一。切分与清洗的工作量被严重低估。
- 评估体系缺失。没有标注集、没有回归测试，模型一升级就不知道好坏。这比模型选型重要得多。
- 组织配套滞后。Agent 上线意味着审批链条变化，如果没人对「机器给的建议」负责，项目就走不到生产。
六、给决策者的清单
在立项前，建议先回答这六个问题：
- 这件事现在由谁做、花多少时间、错一次的代价多大？
- 判断标准能不能写成规则或标注集？
- 需要调用哪些系统，接口是否具备？
- 出错了谁来兜底，能否回滚？
- 数据能否出内网，若不能，本地算力是否够？
- 上线后由哪个部门负责运营与迭代？
六个问题里若有三个答不上来，说明还不具备上线条件，先把 POC 收窄到一个可验证的单点，比铺开做平台更实际。
参考
- 公开财报与厂商案例（2023-2026）中的企业 AI 投入结构
- McKinsey State of AI 系列报告（2024-2025）
- 我们在制造、零售、网吧连锁等行业的交付复盘（内部材料，未公开）