获课：xingkeit.top/16284/

撕掉“套壳”标签：从审批与查询智能体看企业AI的落地真谛

在企业数字化转型的浪潮中，大模型落地的第一步往往是从“智能客服”或“知识库问答”开始的。但说实话，这类应用很容易陷入“懂很多废话，却办不了一件正事”的尴尬境地。真正的企业痛点，隐藏在那些枯燥、繁琐且高度结构化的内部流程中——比如请假审批、报销查询、库存核对。

最近，我完整地使用扣子平台，从零搭建了一套涵盖企业常用审批与查询的智能体。在这个过程中，我最大的感触是：如果只是简单地把大模型接进企业微信群，那叫“套壳”；只有当AI能够穿透自然语言的表象，准确触发底层的业务逻辑时，它才配叫“智能体”。

一、 查询类智能体：从“知识检索”到“数据编织”

很多人做查询智能体，第一反应就是扔一堆PDF或Excel进知识库，然后让大模型去“猜”。但在企业真实的查询场景（如“查一下上个月华东区的差旅报销进度”）中，这种做法准确率极低，且极易产生幻觉。

我的核心经验是：企业级查询，绝不能依赖大模型的记忆，必须依赖“结构化数据的精准投喂”。 在扣子搭建中，大模型的角色不是数据库，而是一个极其聪明的“SQL翻译官”和“语义路由器”。

当用户输入模糊的自然语言时，我们需要通过精心设计的Prompt，让大模型精准提取出关键实体（时间：上个月；部门：华东区；类型：差旅报销）。随后，利用扣子的插件能力或工作流，将这些实体拼接成标准的API请求参数，去调用企业后台真实的数据库。最后，大模型只需要把返回的冰冷JSON数据，用人类友好的语言包装一下输出即可。这种“自然语言理解 + 结构化接口调用 + 自然语言生成”的解耦模式，才是查询类智能体做到100%准确率的唯一途径。

二、 审批类智能体：最核心的价值是“防御性执行”

如果说查询智能体是“只读”的，那么审批智能体就是“写入”的，这也是风险最高的地方。让AI直接决定是否通过一笔10万元的报销，在任何企业都是不可接受的。

在搭建审批流时，我深刻体会到了扣子工作流中“人机协同”的精妙之处。审批类智能体的底线原则是：AI只做“预处理”，不做“最终决策”。

当用户说“帮我提交请假申请”时，智能体不应该直接调接口，而是要进入一个多节点的工作流：首先，反问用户核对关键信息（请假天数、事由）；其次，根据企业规则进行初步校验（比如判断年假余额是否足够）；最后，也是最关键的，生成一张结构化的审批卡片，推送给真正的审批人。在这个流程中，大模型的价值在于极大地降低了发起审批的摩擦力，代替了原来繁琐的表单填写，但它始终被严格地关在权限控制的笼子里。

三、 提示词工程的进阶：写代码的严谨，而非写散文的浪漫

在C端聊天场景里，Prompt往往写得越活泼、越有人情味越好。但在搭建企业审批和查询智能体时，我彻底抛弃了这种“散文式”的写法，转而采用极其枯燥的“契约式”Prompt。

因为你面对的是严格的API Schema和不容有失的业务规则。在扣子的系统提示词中，我需要像写接口文档一样，明确规定大模型输出的格式（如必须输出纯JSON）、枚举值的范围（如请假类型只能选事假、病假、年假），甚至要规定在无法识别用户意图时的标准拒绝话术。在企业级AI搭建中，对大模型的约束越死，它在业务流程中的表现就越稳。

四、 结语：AI不替代流程，而是润滑流程

回顾整个实战过程，我越来越觉得，用扣子搭建企业智能体，本质上是一种“业务流程的重构与润滑”。

我们并没有因为引入了AI，就废掉企业原有的OA系统或ERP系统。那些后台的数据库、权限校验、状态机流转依然稳如泰山。AI所做的事情，是掩盖了这些复杂系统冰冷、生硬的交互界面，用最符合人类直觉的对话方式，作为前端接入层。

这不仅降低了员工使用内部系统的学习成本，更让那些沉睡在复杂菜单深处的功能被轻易唤醒。当企业内部的审批与查询不再需要翻找表单、核对字段，而是变成一句轻描淡写的“帮我查一下”、“帮我走个流程”时，这才是大模型真正为企业创造的、看得见摸得着的生产力跃迁。