AI 智能体和聊天机器人的区别在哪
这个词被用得太泛,先把边界划一下。
聊天机器人输出的是文字,智能体输出的是动作。前者接收问题、生成回答;后者接收一个目标,自己判断需要哪几个步骤、按什么顺序调用哪些工具,执行完再把结果交回来。
关键在「工具」这两个字。智能体本身不会查数据库、不会算模型、不会发邮件,这些事情由外部工具完成。它负责的是理解目标、选工具、按顺序调用、根据中间结果调整。工具做得好不好,决定了智能体靠不靠谱。
这正是 iModel 的切入点:你已经搭好的那些数据工作流,本身就可以作为工具被智能体调用。取数、清洗、模型预测、报表生成,每一条都是一个能力,不需要为了做智能体重新写一遍。
为什么多数智能体项目停在演示阶段
这四条来自客户沟通,和模型能力关系不大。
演示时调用境外模型 API 很顺,真要接入生产数据,合规这一关就过不去。尤其是金融、政务和涉密场景。
智能体接的是导出的样本文件而不是活的业务系统,回答基于过期数据。一旦要接实时数据源,工程量远超预期。
模型给了个结论,但中间调用了什么、用了哪些数据,没有记录。审计和内控环节通不过。
同样的问题问两次,答案不一样。在需要确定性的业务流程里,这个特性是致命的。
相关阅读:AI 试点为何止步于演示
工作流即工具:智能体怎么接到你的业务上
三层结构,每一层都在你自己的环境里。
把工作流变成工具
已有的取数、清洗、预测、报表工作流,加上说明和参数定义之后,就成了智能体可以调用的工具。工具做什么、需要什么输入,由你定义,不由模型猜。
模型只负责编排
大模型拿到目标后决定调用哪些工具、按什么顺序。它不直接碰数据库,也不直接执行动作,只在你给定的工具清单里做选择。
执行与记录在本地
工具的实际执行发生在 iModel 里,数据不经过模型。每次调用了哪个工具、传了什么参数、返回了什么,全都留在工作流的执行记录中。
接哪个模型由你决定
通过标准接口对接,不绑定单一厂商。
多数国产大模型提供 OpenAI 兼容接口,可通过相应节点配置接入;本地部署的模型(如通过 Ollama、vLLM 等方式运行)同样通过接口地址接入。具体接入方式与已验证的模型清单,建议在方案沟通阶段确认,我们不对未实测过的组合作承诺。
一个报销单据核查智能体长什么样
用一个常见场景说明工具怎么拆、智能体怎么编排。
说明:以下是用于说明方法的示例设计,不是客户案例。实际项目中每一步的难度取决于你的系统对接条件。
先把工具拆出来
单据信息提取、制度条款匹配、历史重复报销检查、超标金额计算、结果通知。五个工具,每一个都是一条独立的工作流,可以单独测试、单独修改,也可以被其他流程复用。
把判断规则写进工具,不交给模型
报销标准、金额上限、哪些票据类型需要额外审批,这些是确定性规则,写在规则节点里。模型不参与判断合规与否,只负责决定什么时候调用这个工具。这是结果能稳定的前提。
让智能体编排顺序
收到一张单据后,先提取信息还是先查重复,遇到信息缺失怎么处理,这一层交给模型判断。它的可选动作被限制在你给的五个工具之内,不会做出范围外的事。
保留人工确认环节
智能体给出的是初审结论和依据,金额超过阈值或判断存疑的单据转人工。不建议一开始就让它全自动放行,先跑一段时间比对人工结果,确认准确率之后再逐步放宽。
动手之前应该知道的四件事
选型阶段说清楚,比上线后返工便宜。
智能体不会把差的工具用出好结果。如果底层的取数逻辑有问题、口径不清楚,套一层智能体只会让错误传播得更快、更难查。数据工程这一步省不掉。
模型的编排决策带有不确定性。会计分录生成、资金划转这类必须每次结果完全一致的环节,应该用确定性的工作流,不要交给智能体编排。
出于合规要求选择本地部署的小参数模型时,编排复杂任务的能力明显弱于大参数的云端模型。工具数量多、步骤长的场景要提前做能力验证。
智能体能调用哪些工具、什么情况下必须转人工、哪些数据不能进入提示词,这些都要人来设定。这部分工作量不比搭工具少。
版本提示:智能体相关节点在较新的 iModel 版本中提供。如果贵司当前使用的是较早版本,需要先升级才能使用本页所述功能,升级方式可联系我们确认。
关于 AI 智能体的五个问题
方案沟通阶段问得最多的几个。
工具和编排逻辑都在可视化工作流里搭建,不需要写代码。但这不等于没有门槛:你需要理解自己的数据结构、能把业务规则表达清楚、知道怎么拆分工具的粒度。这些是分析能力而不是编程能力。
需要更复杂的处理时,可以用脚本节点接入 Python 或 R。
取决于你怎么设计。工具的实际执行发生在 iModel 本地,原始数据不需要经过模型。发给模型的是任务描述、工具说明和中间结果的摘要。
如果某些字段连摘要都不能外发,可以在工作流中先做脱敏或匿名化处理再进入提示词。使用本地部署的模型时,整个过程不出内网。
核心做法是把确定性的部分从模型手里拿走。业务规则、计算逻辑、判断阈值全部写在工具里,模型只负责选工具和定顺序,可选范围被严格限制。
即便如此,编排层仍然存在不确定性。建议上线前用一批历史数据做批量回放,统计结论与人工判断的一致率,达标之后再上生产,并保留人工复核环节。
iModel 在银河麒麟 V10 / V11 与统信 UOS 的 x86-64 版本上已验证可运行,海光 C86 架构已验证。鲲鹏、飞腾等 ARM 平台目前不支持,在规划中。
模型侧可以接本地私有化部署的国产大模型,整条链路不需要连接境外服务。具体组合建议在 POC 阶段实测。
建议从一个已经有成熟工作流的场景开始,先把那条工作流变成工具试一次,而不是一上来就设计多工具的复杂智能体。
如果目前还没有把数据流程搭起来,那么正确的第一步是数据工程而不是智能体。可以先看基础教程,或者了解 iModel 的平台能力。
先把一条工作流变成工具试一次
智能体不是从零开始的新项目,而是建在你已有的数据能力之上。如果你手上已经有跑得稳的工作流,那一步比想象中近。想先确认场景是否合适,可以直接联系我们。
