为什么我能讲这个话题

先简单介绍一下背景。我目前在多家企业担任智能体落地的顾问，手头有多家企业智能体成功落地的实战经验，且这些系统都真正投入到了生产环境使用。

从 GPT 刚问世那会儿起，我们都憧憬着在大模型能力加持下，企业能够实现真正的智能化——让 AI 自动解决业务流程中的复杂问题。但三年多过去了，我们很少听说哪家企业的自动化系统真正替代了人工的正常工作流程。大部分所谓的"自动化"，依然停留在数字报表和传统的 OA 办公层面，并没有真正用大模型的决策能力渗透到业务核心链路。

我开发的企业本体流程落地网站：http://sicbot.cn

企业不敢用大模型的根本原因：随机性

答案很简单：大模型生成的内容是随机的，每次结果都不一样。

如果你的要求很简单，结果的准确性还能保证。但问题是——如果要求简单，为什么还要用大模型？直接写几个 if-else 判断不就行了？而如果场景复杂，涉及模糊概念、长流程、多条款、多步骤，这时候让大模型处理似乎天经地义——它懂那些隐晦的经验，能够"意会"。

但这正是你跌入大坑的开始。大模型时而像艺术家一样发散思维，想得太深太远，给出你根本不想要的结果；时而又畏缩不前，你明明让它这么做，它偏不敢做。 你只能通过提示词命令它，但它不听话，你也没什么办法。更痛苦的是，模型版本迭代后，旧问题解决了，新场景又冒出更多问题。

现在的 Vibe Coding（氛围变成）领域之所以能用，是因为经过了极其工程化的优化：海量代码微调、Prompt 工程、后训练优化。你看 GPT 说话是不是经常 "If...else...If...else"（不是，而是，不是，而是）？这是因为它被灌入了大量代码训练，专门为代码场景做了微调——这是目前唯一被证明有大商业价值的落地场景。

但如果要把大模型落地到你的特定业务场景，需要烧掉多少 Token？多少资本投入？要为单个场景做大量定制化。大模型不是通用的，要在某个场景达到好效果，必须定制。

现在技术发展的趋势，包括代码生成范式的演进、模型能力的"畸变"，其实都在把大模型变成一种"定制化"的文本生成。而企业不具备训练专用大模型的数据基础，指望通过"生成"的方式让大模型自动解决企业问题，这条路是走不通的。

重新认识大模型：它是胶水，不是大脑

从 GPT 诞生之初，我也曾陷入上述悖论，但很快意识到：我们不能跟着资本的方向走，要有自己独立的认知。

大模型的本质是什么？它是一个生成模型（Generative Model）。它通过"预测下一个字"这个简单任务，学会了文本的概率分布。它的内核是不断吐字的生成器，没有逻辑性，没有判断力，只是像胶水一样把字粘在一起，看起来像人话。

它表现出"像人一样思考"的特征，仅仅是因为训练语料中存在这样的模式，它学到了这些模式的高概率组合。我们不能把企业中必须精确执行的精严判断，直接交给大模型做等价表达——这本身就是个伪命题。

所以，企业落地大模型必须借助其他方式保证流程精准，大模型只能发挥"灵活性"和"胶水"的作用——把流程串起来，或在需要发散思维的创新环节使用。但在整个链路的准确表达上，必须放弃让大模型自由发挥。

落地的三大难题

企业落地智能体还面临三个核心难题：

1. 错误的范式：命令式编程（目标导向）

很多人以为，既然大模型很智能，那我们可以采用命令式编程（Goal-oriented Programming）：给定一个目标，让大模型自己推理出执行步骤。这就像逻辑编程（Logic Programming）中的推理引擎，给定公理和目标，系统自动组合出证明过程。

这正好契合大模型现在的使用方式，但这不适合企业落地。我们总是夸大模型的智能，想当"甩手掌柜"，下达命令就期待严谨的推理结果。大模型不会给你严谨的推理结果。

正确的范式：过程式编程（流程骨架）

为什么不放弃命令式，改用过程式编程（Procedural Programming）呢？就像 Python、C++ 那样，一行一行代码把算法流程写出来。

如果用过程式的方式来使用大模型：

• 它自然就有了流程的骨架

  （确定性执行）

• 它又发挥了生成能力

  （自然语言描述的灵活性）

这是最好的折中：我们既用了大模型的生成能力，又能控制住整个过程。把大模型当作一种"过程语言"来使用，这才是打开企业自动化场景的钥匙。

2. 知识沉淀：这不是技术问题，是人的问题

企业有专家，多年积累的工作模式是"人治"的。那些隐性的管理形式、人际关系很难直接打破。你不能说上了大模型，就把原来的管理链条砍断。落地智能体，70% 是人的事、组织的事、管理的事。

一般需要一把手强势推动，才能创造全局价值。但即使有权力，如何把手下专家的经验明明白白写出来，让大模型理解？ 这极其困难。

张三和李四都做同一件事，但表达方式不同，互相可能都看不懂对方的经验。这不是技术发展问题，是认知统一、交流沟通、语言表达的问题。

技术人员能提供的，只是表达的范式、交流的模板、沉淀经验的标准模式。真正的落地，需要在对人的管理和沟通中获取经验——这是最难的，不是技术能解决的。

为了让经验更确切、判断执行更标准化，我们需要：

• 限定专家的讨论范围（限定状态空间/State Space）

• 在这个域内进行决策和逻辑落地

• 采用科学的沟通方法：问卷、会议纪要、动作分析等

这里就必须提到 Palantir 的本体（Ontology） 了。目前 Palantir 的本体模式基本主导了企业智能体落地的方向。本体落地是专家经验落地的第一步，是经验能够编写的前提。

3. 准确率：99.7% 是生死线

对技术人员来说，我们能创造的最大价值就是测试环节。我们需要一套测试方案，能准确评价智能体在企业中的执行准确率。

上线标准至少是 95%，最好能到 99.7%。

为什么？因为企业场景和个人使用完全不同：

• 企业中错误会大大降低可信度

• 企业流程是确定性的，错误会引发连锁反应（多人协作场景）

• 不像个人使用时可以随意重试

现在市面上通用的智能体，准确率往往只有 60-70%，经常说出匪夷所思的话，在多步执行场景下更是如此。这种准确率的智能体根本无法在企业落地。

当我告诉企业能达到 99.7% 准确率时，所有老板都是"垂涎欲滴"的。所以作为技术人员，保证准确率是我们上线智能体的底线，也是我们的看家本领。

我们需要闭环的回归测试：即使经验随场景和时间变化，也能通过测试环节动态闭环执行，持续优化流程。测试一方面是流程保证，另一方面是让智能体持续进化的基础。

总结：企业智能体落地的三个支柱

要在企业成功落地智能体，必须把握住三个方向（这也是我后续会详细拆解的内容）：

1. 流程化表达

   ：放弃命令式，采用过程式，让大模型在明确的流程骨架上发挥，而不是让它创造流程。

2. 知识沉淀与本体构建

   ：解决人的问题，通过 Palantir 本体论等方法论，将专家经验标准化、结构化。

3. 工程化测试体系

   ：建立闭环测试，确保 95% 甚至 99.7% 的准确率，这是上线的底线。

后面我会逐步拆解这套方法论，融合目前前沿的技术实践，供大家探索。

---

如果你对这套方法论感兴趣，欢迎持续关注，我们一起学习进步。

---