为何企业Agent难以替代人工？揭秘大模型应用的三大难题

先简单介绍一下背景。

我目前在多家企业担任智能体落地顾问，手头有多家企业智能体成功落地的实战经验，而且这些系统都已经真正投入生产环境使用。

从 GPT 刚问世那会儿起，我们都憧憬着：在大模型能力加持下，企业能够实现真正的智能化，让 AI 自动解决业务流程中的复杂问题。

但三年多过去了，我们很少听说哪家企业的自动化系统，真正替代了人工的正常工作流程。大部分所谓的“自动化”，依然停留在数字报表和传统 OA 办公层面， 并没有真正让大模型的决策能力渗透到业务核心链路。

Part.01

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

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

如果你的要求很简单，结果的准确性还能保证。但问题也来了： 如果要求简单，为什么还要用大模型？ 直接写几个 if-else 判断不就行了？

而如果场景复杂，涉及模糊概念、长流程、多条款、多步骤，这时候让大模型处理似乎也很自然。因为它懂那些隐晦的经验，能够“意会”。

但这往往正是问题开始的地方。

大模型有时候像艺术家一样发散思维，想得太深太远，给出你根本不想要的结果；有时候又畏缩不前，你明明让它做，它偏不敢做。 你只能通过提示词去命令它，但它不听话的时候，你并没有太多办法。更痛苦的是，模型版本一迭代，旧问题刚解决，新场景里又冒出更多问题。

现在 Vibe Coding 领域之所以能跑起来，是因为背后已经经历了极其工程化的优化：海量代码微调、Prompt 工程、后训练优化。你会发现 GPT 的表达里经常带有强烈的代码式结构感，这本质上就是因为它被灌入了大量代码训练，并且针对代码场景做了深度微调。 这也是目前少数已经被证明有巨大商业价值的落地场景。

但如果要把大模型落地到企业自己的特定业务场景里，需要烧掉多少 Token？多少资本投入？又要为单个场景做多少定制化？ 大模型并不是天然通用的。要在某个具体场景达到好效果，就必须高度定制。

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

Part.02

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

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

大模型的本质是什么？

它是一个 生成模型（Generative Model） 。它通过“预测下一个字”这个简单任务，学会了文本的概率分布。它的内核，本质上是一个不断吐字的生成器。它没有真正的逻辑性，没有真正的判断力，更像是一种把文字粘连起来的“胶水”，只是因为输出足够像人话，所以看起来像在思考。

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

因此，企业要落地大模型，就必须借助其他方式去保证流程的精准性。大模型适合发挥“灵活性”和“胶水”的作用：把流程串起来，或者在需要发散思维的创新环节使用它。

但在整个链路的 准确表达 上，必须放弃让大模型自由发挥。

Part.03

企业智能体落地的三大难题

企业落地智能体，至少要面对三个核心难题。

一、错误的范式：目标导向的命令式思路

很多人以为，既然大模型已经很智能，那我们就可以采用一种目标导向的方式：给定一个目标，让大模型自己推理出执行步骤。

这很像逻辑编程里的推理引擎：给定公理和目标，系统自动组合出证明过程。

这种使用方式，确实很符合今天大家对大模型的直觉。但它 不适合企业落地 。

我们总是容易高估模型的智能，想当“甩手掌柜”，给出一个目标，就期待它自己推出一套严谨、稳定、可靠的执行过程。问题在于， 大模型并不会自动给你严谨的推理结果 。

正确的方向：过程式编程，先给骨架，再让它生成

为什么不换个思路？

与其让大模型自己创造流程，不如直接采用 过程式编程（Procedural Programming） 的思路。就像 Python、C++ 那样，把算法流程一行一行写出来。

如果用过程式的方式来使用大模型，它会同时具备两种能力：

第一，它自然有了流程骨架。 流程是确定性的，执行边界是清晰的。

第二，它依然保留生成能力。 自然语言描述的灵活性、模糊表达的适配能力，仍然可以发挥出来。

这其实是一个非常好的折中： 既用了大模型的生成能力，又控制住了整个过程。

把大模型当作一种“过程语言”来使用，而不是把它当作一个会自动设计流程的大脑，这才是打开企业自动化场景的钥匙。

二、知识沉淀：这不是纯技术问题，更是人的问题

企业里当然有专家，而且很多专家已经积累了多年的工作经验。

但问题在于，企业的工作模式长期是“人治”的。很多隐性的管理方式、协作方式、人际关系，并不是一套文档就能说清楚，更不是上了大模型之后就能直接替代的。

落地智能体，70% 是人的事，是组织的事，是管理的事。

很多时候，只有一把手强势推动，项目才有可能创造出全局价值。可即使有这个推动力，仍然会遇到一个非常现实的问题： 怎样把专家手里的经验，明明白白写出来，并且写到大模型能理解、能执行的程度？

这件事极其困难。

张三和李四可能都在做同一件事，但两个人的表达方式完全不同，甚至互相都未必看得懂对方的经验。 这本质上不是技术发展的问题，而是认知统一、交流沟通、语言表达的问题。

技术人员能提供的，其实只是表达范式、交流模板和沉淀经验的标准模式。真正要把经验落下来，仍然需要在对人的管理和沟通中，把经验一点点提炼出来。 这往往是最难的部分，也不是单靠技术就能解决的。

为了让经验更准确、判断更标准、执行更稳定，我们需要做几件事：

限定专家讨论范围。 也就是限定状态空间（State Space），在这个限定域内完成决策与逻辑落地。

采用科学的沟通方法。 比如问卷、会议纪要、动作分析等方式，把隐性经验慢慢显性化。

这里就必须提到 Palantir 的本体（Ontology） 。

目前 Palantir 的本体模式，基本已经主导了企业智能体落地的一条重要方向。 本体落地，是专家经验落地的第一步，也是经验能够被编写、被表达、被系统接住的前提。

三、准确率：99.7% 是生死线

对技术人员来说，能够创造最大价值的环节，其实是 测试 。

我们必须要有一套测试方案，能够准确评价智能体在企业中的执行准确率。 上线标准至少是 95%，最好能到 99.7%。

为什么这个数字这么重要？

因为企业场景和个人使用场景完全不同。

在个人使用里，模型答错了，你可以重来一次；答偏了，你可以补一句提示词；效果不好，你还可以多试几轮。

但企业不是这样。

企业里的错误，会直接降低系统可信度； 企业流程本身又是确定性的，一处错误就可能引发连锁反应，尤其是在多人协作场景里； 它不像个人使用时那样，允许你无限重试。

现在市面上很多通用智能体，准确率往往只有 60% 到 70%。它们经常说出让人匪夷所思的话，一旦进入多步执行场景，问题会更加明显。 这种准确率的智能体，根本没有办法在企业里真正落地。

当我告诉企业，我能把准确率做到 99.7% 时，所有老板都会非常有兴趣。因为他们真正关心的，不是模型有多聪明，而是它能不能稳定替代工作流中的一部分真实工作。

所以，对技术人员来说， 保证准确率，是上线智能体的底线，也是最核心的能力。

我们需要建立的是一套 闭环的回归测试机制 。即使经验会随着场景和时间不断变化，我们也能通过测试环节把执行动态闭环起来，持续优化流程。

测试的价值有两层：

一层是对流程正确性的保障；

另一层是让智能体持续进化的基础设施。

Part.04

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

要在企业里真正把智能体落地，必须抓住三个方向。这也是我后续会持续拆解的方法论核心。

流程化表达：放弃目标导向的命令式幻想，采用过程式方法，让大模型在明确的流程骨架上发挥，而不是让它自己创造流程。

知识沉淀与本体构建：解决人的问题，通过本体构建等方法，把专家经验标准化、结构化，让经验真正能够被表达、被沉淀、被执行。

工程化测试体系：建立闭环测试机制，确保 95% 甚至 99.7% 的执行准确率。这不是锦上添花，这是上线的底线。

Part.05

未完待续

后面的内容里，我会逐步拆解这套方法论，并结合当前前沿的技术实践，一步一步展开。

如果你对企业智能体落地、流程工程化、知识沉淀和测试闭环这些问题感兴趣，欢迎持续关注。我们一起学习，也一起把这件事真正做成。