企业官网建设流程全解析

1. 银行为什么突然集体押注大模型与智能体

过去两年，我陆陆续续参与了几个银行侧的大模型落地项目，从最初的“POC 演示很惊艳、上线就翻车”，到后来慢慢摸出一套能跑通的路子。2026 年这个时间点回头看，超过一半的银行已经把大模型和智能体用在了真实业务里，这个比例不是拍脑袋来的——你去翻任何一家股份制银行的年报或者科技条线负责人的公开分享，几乎都能看到“智能体”“Agent”“大模型”这些词。

但真正值得聊的不是“用了没有”，而是“用在哪、怎么用、踩了哪些坑”。我见过太多团队一上来就想做一个“全能银行大脑”，结果三个月烧掉几百万算力，最后连一个能稳定回答理财问题的客服机器人都没做出来。问题出在哪？出在把大模型当成了万能钥匙，而忽略了银行这个行业最核心的两个字：合规和准确。

银行不是互联网公司，它不能容忍“大概对”。一个信贷审批的结论、一个理财产品的推荐、一笔反欺诈的判定，背后都是真金白银和监管红线。所以银行做大模型，走的是一条和通用聊天机器人完全不同的路——用智能体把大模型的能力框起来，让它在可控的边界内干活。

这篇文章我想做一件事：把 2026 年银行大模型加智能体的落地情况，拆成 19 个能看得懂、能参考、能复现的案例逻辑。不是罗列名词，而是讲清楚每个场景为什么需要智能体、智能体在里面扮演什么角色、技术选型怎么定、上线后哪些地方最容易出问题。如果你正在做银行侧的 AI 项目，或者想了解智能体在强监管行业怎么落地，这篇内容应该能帮你省下不少试错成本。

2. 先搞清楚：银行里的“大模型”和“智能体”到底分工是什么

2.1 大模型是“大脑”，但它一个人干不了活

很多人把大模型理解成一个超级员工，什么都能问、什么都能答。但在银行场景里，大模型更像是一个知识渊博但缺乏纪律的实习生——它知道很多，但它不知道什么该说、什么不该说，也不知道做完一步之后下一步该干什么。

举个例子，客户问“我这张信用卡能不能提额”。大模型可以直接生成一段听起来很专业的回答，但它不知道这个客户当前的额度是多少、最近有没有逾期、提额需要满足哪些内部规则。这些信息不在模型的训练数据里，而在银行的业务系统里。

所以大模型在银行里的定位很明确：负责语言理解和生成，不负责业务逻辑和决策。它把客户的自然语言问题翻译成结构化的意图，把结构化的结果翻译成客户能听懂的话。中间的业务判断，交给智能体。

2.2 智能体是“流程管家”，把大模型的能力串起来

智能体（Agent）这个词这两年被用得很泛，但在银行语境下，它的核心价值就一个：编排。它知道一个任务需要分几步、每步调用什么工具、什么条件下走什么分支、什么情况下必须停下来转人工。

我习惯把智能体理解成一个“有剧本的调度员”。大模型是演员，智能体是导演。导演不负责演戏，但导演决定这场戏怎么演、什么时候换场景、什么时候喊停。

在银行里，一个典型的智能体至少包含四个部分：

• 意图识别：用大模型判断客户到底想干什么
• 工具调用：连接行内的核心系统、数据库、知识库
• 流程控制：根据业务规则决定下一步走向
• 安全兜底：在不确定或高风险时触发人工介入

这四个部分缺一不可。我见过只做了意图识别和工具调用、没做安全兜底的智能体，上线第一周就因为给一个不符合条件的客户推荐了高风险产品被合规部门叫停。

2.3 为什么银行不用“一个大模型包打天下”

这里有一个很现实的工程问题：成本和延迟。银行的核心业务系统每天要处理海量请求，如果每一个请求都调用千亿参数的大模型，算力成本根本扛不住，响应时间也没法接受。

所以银行普遍采用的是大小模型配合的策略。简单意图识别用小模型或者微调后的中等模型，复杂语义理解和生成用大模型，业务规则判断用传统规则引擎。智能体负责在这几者之间做路由。

我参与过的一个项目里，智能体把 80% 的常见问题路由到了小模型和规则引擎，只有 20% 的复杂问题才调用大模型。这样整体成本降了一个数量级，响应时间也从平均 3 秒降到了 800 毫秒以内。

提示：不要一上来就追求“全场景大模型”。先把高频、简单、规则明确的场景用智能体加小模型跑通，再逐步把大模型引入复杂场景。这是银行落地最稳妥的路径。

3. 19 个智能体案例里，哪几类场景真正跑出了价值

3.1 客户服务类：从“答得上”到“办得成”

客服是银行最早尝试大模型的场景，也是最容易看到效果的场景。但 2026 年的客服智能体和两年前的“智能问答”已经完全不是一回事了。

早期的智能客服本质上是检索加匹配——客户问一个问题，系统从知识库里找最相似的答案返回。它只能“答”，不能“办”。客户想查账单，它告诉你“请登录手机银行查询”；客户想挂失，它告诉你“请拨打客服热线”。这种体验客户根本不买账。

现在的客服智能体，核心变化是接入了业务系统。客户说“我上个月的信用卡账单怎么多了 200 块”，智能体不是返回一段解释，而是直接调用账单查询接口，拉出具体交易明细，然后用大模型生成一段人话解释：“您上个月有一笔 200 元的年费扣款，因为您的卡片消费次数未达到免年费标准。”

我复盘过的一个案例里，客服智能体上线后，简单业务的自助完成率从 35% 提升到了 68%，人工客服的转接率下降了一半以上。关键就在于智能体把“查询、解释、办理”三个环节串起来了，而不是只做中间的“解释”。

但这里有一个很容易被忽略的坑：权限控制。智能体调用业务系统时，必须严格继承客户的权限。我见过一个案例，智能体在测试环境里能查到所有客户的账单，上线时忘了改权限配置，差点造成数据泄露。后来他们的做法是，智能体调用任何接口都必须携带客户的会话令牌，由业务系统做二次鉴权。

3.2 信贷与风控类：智能体做“辅助”，不做“决策”

信贷审批是银行最核心的业务之一，也是监管最严的领域。大模型和智能体在这里的角色非常明确：辅助人工，不替代人工。

具体怎么做？我拆一个典型的对公信贷智能体流程：

1. 客户经理上传企业财报和征信报告
2. 智能体调用 OCR 能力提取关键财务数据
3. 大模型对非结构化信息（如企业经营范围、上下游描述）做语义分析
4. 智能体把结构化数据和非结构化分析结果汇总，生成一份初步的信贷评估报告
5. 报告提交给风控人员做最终审核

整个流程里，智能体做的是信息提取、初步分析和报告生成，最终决策权始终在人手里。这样做的好处是，既大幅提升了客户经理的效率（一份报告从半天缩短到 20 分钟），又完全符合监管对信贷决策的要求。

注意：信贷场景的智能体绝对不能直接输出“建议批准”或“建议拒绝”的结论。正确的做法是输出“关键风险点提示”和“需要人工重点关注的事项”。这个边界一旦模糊，合规风险极高。

我见过一个反面案例：某银行的智能体在测试时直接给出了“建议批准 500 万”的结论，虽然只是测试环境，但被监管检查时发现，整个项目被要求整改了三个月。后来他们的做法是，所有智能体的输出都加了一层“结论过滤”，任何涉及审批结论的表述都会被拦截并替换成中性提示。

3.3 营销与销售类：智能体解决“什么时候对谁说什么”

银行营销的痛点从来不是“没有产品”，而是“不知道在什么时间、对什么客户、说什么话”。传统做法是靠客户经理的经验和批量营销活动，转化率低、客户体验差。

销售智能体的逻辑是：实时监听客户行为，在合适的时机触发合适的营销动作。

我复盘过一个理财推荐智能体的案例。它的工作流程是这样的：

• 智能体实时接入客户的手机银行行为数据
• 当客户频繁查看某类理财产品但未购买时，触发营销时机
• 大模型根据客户的历史持仓、风险偏好、浏览记录，生成个性化的推荐话术
• 智能体把话术推送给客户经理，或者直接在 App 内以弹窗形式展示

这个案例上线三个月后，理财产品的点击转化率提升了 2.3 倍。但更值得说的是，他们做对了一件事：智能体只负责“推荐”，不负责“销售”。最终的购买决策还是由客户自己做，智能体不会替客户下单，也不会绕过风险测评。

这里有一个实操心得：营销智能体的效果高度依赖时机判断的准确性。如果触发太频繁，客户会反感；如果触发太保守，又起不到效果。我的经验是，初期把触发阈值设得高一些，宁可少推几次，也不要让客户觉得被骚扰。等模型积累了一定数据之后，再逐步优化触发策略。

3.4 运营与内部效率类：智能体是“员工的助手”

银行内部有大量重复性、规则性的工作，比如报表生成、合规检查、工单处理。这些场景不需要大模型做复杂的语义理解，但需要智能体把多个系统串起来。

我印象最深的一个案例是合规检查智能体。银行的合规部门每天要处理大量的监管文件、内部制度、业务凭证，人工检查效率很低。智能体的做法是：

• 用大模型对监管文件做摘要和关键条款提取
• 把提取结果和行内制度做比对，找出差异点
• 生成合规检查报告，标注需要人工确认的事项

这个智能体上线后，合规检查的覆盖率从 60% 提升到了 95%，而且检查时间从平均 3 天缩短到了 4 小时。但他们的合规负责人跟我说了一句话，我觉得很到位：“智能体帮我们把‘找问题’的时间省下来了，但‘判断问题’还是得靠人。”

4. 技术选型：银行做智能体，为什么很少用“开箱即用”的平台

4.1 通用智能体平台的三个“不匹配”

市面上有很多智能体开发平台，拖拖拽拽就能搭一个流程出来。但银行在实际选型时，很少直接使用这些平台，原因有三个：

第一，数据不出域。银行的核心数据绝对不能离开行内的网络环境。通用平台大多是 SaaS 服务，数据要上传到云端，这在银行是红线。所以银行要么用私有化部署的平台，要么自研。

第二，权限体系不匹配。银行有非常复杂的权限体系，不同角色、不同部门、不同层级的人能访问的数据完全不同。通用平台的权限模型通常比较简单，没法直接对接银行的行内权限系统。

第三，审计要求不满足。银行的每一个操作都要留痕，智能体的每一次决策、每一次工具调用、每一次大模型生成，都必须可追溯、可审计。通用平台在这方面的能力通常比较弱。

所以银行做智能体，主流的技术路线是基于开源框架自研，或者在私有化部署的商业平台上做二次开发。

4.2 主流技术栈的取舍逻辑

我参与过的项目里，技术栈的选择基本围绕几个维度：可控性、成本、开发效率、运维复杂度。

从我的观察来看，大型银行倾向于自研或基于开源框架二次开发，因为它们的业务复杂度高、定制需求多，通用平台满足不了。中小银行更倾向于私有化商业平台，因为它们的科技团队规模有限，需要快速上线。

但不管选哪条路，有一个能力是必须自己建的：大模型的评测和监控体系。银行不能接受“模型今天表现好、明天表现差”这种不确定性。所以必须有一套机制，持续监控智能体的输出质量，及时发现和纠正问题。

4.3 大模型选型：不是越大越好

银行在选择底层大模型时，考虑的因素和互联网公司很不一样。互联网公司可能更看重模型的通用能力，银行更看重的是稳定性、可控性和成本。

我见过的一个选型评估表里，权重最高的是“输出稳定性”，其次是“私有化部署能力”，然后是“推理成本”，最后才是“通用能力得分”。这很银行——宁可模型笨一点，也不能让它胡说八道。

具体到模型规模，银行普遍采用分层策略：

• 小模型（1B-7B）：用于意图识别、实体抽取、简单分类等任务，可以微调后私有化部署
• 中模型（13B-30B）：用于中等复杂度的语义理解和生成，如客服话术生成、报告摘要
• 大模型（70B 以上）：用于最复杂的场景，如多轮对话、复杂推理，通常以 API 方式调用或私有化部署

提示：银行在评估大模型时，一定要用自己的业务数据做评测，不要只看公开榜单。我见过一个模型在公开评测里排名很高，但在银行客服场景里的准确率还不如一个微调过的小模型。原因很简单：公开评测的数据分布和银行真实业务数据差异太大。

5. 落地过程中最容易翻车的五个环节

5.1 数据准备：不是“有数据”就行

银行不缺数据，但缺高质量、标注好、能用于训练和评测的数据。我参与的第一个项目，光数据清洗和标注就花了两个月，占了整个项目周期的一半。

这里有几个实操经验：

• 不要试图标注所有数据。先标注一批高质量的种子数据，用于评测和微调，剩下的用模型自动标注加人工抽检。
• 负样本比正样本更重要。银行场景里，“不该说什么”比“该说什么”更关键。所以标注时要特别注意收集边界案例和反面案例。
• 数据要持续更新。银行业务变化快，今天有效的问答对，三个月后可能就过时了。所以要建立数据回流机制，把线上真实对话持续补充到训练集里。

5.2 提示词工程：银行场景需要“约束型提示词”

通用场景的提示词工程追求的是“让模型发挥创造力”，银行场景恰恰相反，追求的是“让模型别乱发挥”。

我总结的银行场景提示词原则是：能约束就约束，能举例就举例，能给格式就给格式。

举个例子，同样是让模型生成一段客服回复，通用场景的提示词可能是“请友好地回答客户的问题”，银行场景的提示词应该是：

你是一名银行客服助手。请根据以下信息回答客户问题： - 客户问题：{question} - 业务数据：{data} - 回答要求： 1. 只使用提供的业务数据，不要编造任何信息 2. 如果业务数据不足以回答问题，回复“抱歉，我需要为您转接人工客服” 3. 不要提供任何投资建议或收益承诺 4. 回答长度不超过 100 字 5. 语气专业、简洁、礼貌

这种“约束型提示词”看起来笨，但在银行场景里非常有效。它把模型的输出空间压缩到了一个可控的范围内，大幅降低了胡说八道的概率。

5.3 工具调用的可靠性：接口超时和异常处理

智能体要调用行内的各种接口，但行内接口的稳定性参差不齐。我遇到过最离谱的情况是，一个查询接口在高峰期响应时间超过 30 秒，智能体等不到结果就直接超时了，客户那边看到的就是“系统繁忙”。

后来我们的做法是：

• 给每个工具调用设置独立的超时时间，一般不超过 5 秒
• 超时后走降级逻辑，比如返回缓存数据，或者直接转人工
• 对接口做熔断和限流，防止某个接口挂了拖垮整个智能体
• 记录每一次工具调用的耗时和结果，用于后续优化

这些看起来是基础的工程问题，但在实际项目里，工具调用的稳定性往往比模型本身的能力更影响用户体验。

5.4 多轮对话的状态管理：别让智能体“失忆”

银行客服场景经常涉及多轮对话。客户先说“我要查账单”，智能体问“请问是哪张卡”，客户说“尾号 1234 那张”，智能体再问“请问查哪个月的”，客户说“上个月”。

这个过程中，智能体需要记住上下文：客户要查的是尾号 1234 的卡、上个月的账单。如果状态管理没做好，智能体就会“失忆”，反复问同样的问题，客户体验极差。

我的经验是，多轮对话的状态不要只存在大模型的上下文里，而是要显式地维护一个会话状态对象。这个对象里记录当前对话的意图、已收集的槽位、下一步要做什么。大模型只负责理解当前这句话，状态管理交给智能体框架。

这样做的好处是，即使大模型换了、提示词改了，会话状态依然稳定，不会因为模型的变化导致对话流程断裂。

5.5 人工兜底的触发时机：什么时候必须转人工

智能体再聪明，也有搞不定的情况。关键是要定义清楚什么情况下必须转人工，而不是等客户投诉了才转。

我总结的转人工触发条件包括：

• 客户明确要求转人工
• 智能体连续两轮无法理解客户意图
• 涉及高风险操作（如大额转账、挂失、投诉）
• 客户情绪激动（通过情感分析判断）
• 智能体输出的置信度低于阈值

这些条件要写在智能体的流程控制里，而不是靠模型自己判断。模型可能会“自信地犯错”，但规则不会。

6. 从 POC 到生产：银行智能体上线的完整路径

6.1 阶段一：场景选择与价值验证

不要一上来就做“全行智能体平台”。先选一个高频、规则明确、风险可控的场景做 POC。

我推荐的首选场景是内部员工助手，比如制度查询、报表生成、工单处理。原因很简单：内部用户对错误的容忍度比外部客户高，而且内部场景的数据更容易获取，合规风险也更低。

POC 的目标不是“做得多完美”，而是验证三件事：技术可行性、业务价值、合规可行性。这三件事里任何一件不成立，项目就不应该继续。

6.2 阶段二：小范围试点与数据积累

POC 跑通后，选一个分行或一个部门做小范围试点。这个阶段的核心任务是积累真实数据、发现边界问题、打磨提示词和流程。

我建议试点期至少持续一个月，覆盖足够多的真实用户和真实场景。试点期间要建立每日复盘机制，把智能体回答错误、转人工、客户投诉的案例都收集起来，逐条分析原因。

这个阶段最容易犯的错误是“急于扩大范围”。我见过一个项目，POC 刚跑通就全行推广，结果各种边界问题集中爆发，最后不得不回滚。试点期的耐心，决定了推广期的顺利程度。

6.3 阶段三：全面推广与持续运营

试点验证通过后，可以逐步扩大范围。但这个阶段的工作重心要从“建设”转向“运营”。

智能体不是上线就完事了，它需要持续的运营和优化：

• 每日监控：关键指标包括自助完成率、转人工率、用户满意度、平均响应时间
• 每周复盘：分析 bad case，更新提示词、补充知识库、优化流程
• 每月迭代：根据业务变化和用户反馈，调整智能体的能力和边界

我见过做得最好的团队，把智能体运营做成了一个闭环：线上发现问题 → 标注数据 → 优化模型或提示词 → 回归测试 → 上线验证。这个闭环转得越快，智能体的能力提升就越快。

7. 几个真实踩坑案例的完整复盘

7.1 案例一：智能体“自作主张”推荐了高风险产品

问题现象：某银行的理财推荐智能体上线后，给一批风险承受能力为“保守型”的客户推荐了中高风险理财产品。客户点击后进入购买页面，虽然最终购买前有风险测评拦截，但客户体验很差，有客户投诉“银行诱导我买高风险产品”。

排查过程：

1. 先查智能体的推荐逻辑，发现推荐规则里确实有“根据客户历史浏览记录推荐”这一条
2. 再查客户的历史浏览记录，发现这些客户最近确实浏览过中高风险产品页面
3. 但问题是，客户浏览不代表客户有相应的风险承受能力
4. 进一步排查发现，智能体在生成推荐时，只用了浏览记录，没有校验客户的风险等级

根因：智能体的推荐流程里缺少了风险等级校验这一步。开发团队默认“浏览记录代表兴趣”，但忽略了银行场景里“兴趣”和“适当性”是两回事。

修复方案：

• 在推荐流程里增加强制校验：客户风险等级必须匹配产品风险等级
• 推荐话术里增加风险提示
• 建立推荐结果的抽样审计机制

经验教训：银行场景的智能体，任何涉及产品推荐的流程，都必须把适当性校验作为强制步骤，不能依赖模型的判断，要用规则硬控。

7.2 案例二：智能体在高峰期“集体失智”

问题现象：某银行的客服智能体在业务高峰期（每月账单日前后）出现大量错误回答，平时准确率 90% 以上，高峰期掉到了 60% 以下。

排查过程：

1. 先查模型本身，发现模型没有变化
2. 再查提示词，也没有变化
3. 查系统监控，发现高峰期接口响应时间大幅上升
4. 进一步排查发现，智能体调用的账单查询接口在高峰期响应时间从 200 毫秒飙升到 5 秒以上
5. 智能体等待超时后，走了降级逻辑，但降级逻辑返回的是通用话术，导致回答质量下降

根因：智能体的超时设置不合理，而且降级逻辑过于简单。高峰期接口变慢是正常现象，但智能体没有做好应对。

修复方案：

• 调整超时策略：根据接口的历史响应时间动态设置超时阈值
• 优化降级逻辑：超时后不是返回通用话术，而是返回“正在查询，请稍候”并异步获取结果
• 增加接口缓存：对高频查询结果做缓存，减少对后端接口的压力

经验教训：智能体的稳定性不仅取决于模型，还取决于它依赖的所有外部系统的稳定性。上线前一定要做压力测试，模拟高峰期场景。

7.3 案例三：提示词里一个词导致合规风险

问题现象：某银行的智能体在回答客户关于理财产品的问题时，使用了“稳赚不赔”“保证收益”等表述，被合规部门在巡检中发现。

排查过程：

1. 查提示词，发现提示词里写了“请用积极、正面的语言回答客户关于收益的问题”
2. 模型把“积极、正面”理解成了“强调收益、淡化风险”
3. 进一步排查发现，提示词里没有明确禁止使用“保证”“稳赚”等词汇

根因：提示词的约束不够具体。“积极正面”这种模糊的表述，在银行场景里是危险的。

修复方案：

• 在提示词里增加明确的禁止词列表
• 增加输出过滤层，对生成内容做合规检查
• 建立提示词评审机制，所有提示词上线前必须经过合规审核

经验教训：银行场景的提示词，每一条模糊的指令都可能被模型放大成合规风险。能用规则约束的，不要用自然语言描述。

8. 2026 年银行智能体的几个趋势判断

8.1 从“单智能体”走向“多智能体协作”

早期的银行智能体大多是单点应用，一个场景一个智能体。但现在越来越多的银行开始尝试多智能体协作——比如一个客服智能体在处理复杂问题时，可以调用一个“信贷专家智能体”和一个“理财专家智能体”来协同完成。

这种架构的好处是，每个智能体可以专注于自己的领域，能力更深、维护更简单。但挑战也很明显：智能体之间的通信和协调需要一套机制，否则容易出现“三个和尚没水喝”的情况。

我观察到的一个做法是，用一个“调度智能体”来做路由和协调，它不直接处理业务，只负责把任务分发给合适的专家智能体，并汇总结果。

8.2 从“通用大模型”走向“领域微调模型”

2024 年的时候，大家还在争论“用通用大模型还是微调模型”。到了 2026 年，这个问题的答案已经很清楚了：银行的核心场景必须用领域微调模型。

原因很简单：通用大模型在银行专业场景里的准确率不够，而且推理成本太高。通过微调，可以用更小的模型达到更好的效果，同时降低推理成本。

但微调也有代价：需要高质量的训练数据、需要持续的迭代维护、需要防止灾难性遗忘。所以银行的做法通常是通用能力用大模型，专业能力用微调小模型，智能体负责在两者之间做路由。

8.3 从“辅助工具”走向“业务伙伴”

早期银行对智能体的定位是“辅助工具”，帮员工省点时间。但现在越来越多的银行开始把智能体当成“业务伙伴”——它不仅执行任务，还能主动发现问题、提出建议。

比如，信贷智能体不仅生成评估报告，还能主动提示“这家企业的上下游集中度较高，建议关注供应链风险”。这种主动性的能力，是智能体从“工具”走向“伙伴”的关键。

但这也带来了新的挑战：智能体的建议如果错了，谁来负责？目前行业的共识是，智能体可以提供建议，但决策责任始终在人。这个边界在 2026 年依然是银行智能体落地的核心原则。

9. 给正在做银行智能体的团队几条实操建议

如果你正在或者准备做银行侧的智能体项目，下面这几条是我踩过坑之后总结出来的，不一定对，但应该能帮你少走点弯路。

第一条：先想清楚“不做什么”，再想“做什么”。银行场景里，边界比能力更重要。一个知道什么不能做的智能体，比一个什么都能做的智能体更有价值。

第二条：把合规和风控的人拉进项目组，从第一天就拉进来。不要等产品做完了再让合规审核，那时候改造成本极高。让合规同事参与需求评审、提示词设计、测试验收的全过程，项目会顺利很多。

第三条：不要追求“零人工”。银行智能体的目标不是替代人，而是让人做人更擅长的事。把重复性、规则性的工作交给智能体，把判断性、情感性的工作留给人。这个定位想清楚了，很多技术选型和流程设计的问题都会迎刃而解。

第四条：监控体系比模型能力更重要。一个能力一般但监控完善的智能体，比一个能力很强但监控缺失的智能体更让人放心。因为前者的问题能被及时发现和修复，后者的问题可能直到客户投诉才暴露。

第五条：做好长期运营的准备。智能体不是一次性项目，而是持续运营的产品。上线只是开始，后面的数据回流、提示词优化、模型迭代、场景扩展，才是真正考验团队的地方。

我在实际项目里最大的体会是，银行智能体的成功，技术只占三成，业务理解和合规意识占七成。一个对银行业务理解深刻的团队，用一般的模型也能做出好用的智能体；一个对银行业务理解肤浅的团队，用最好的模型也做不出能上线的产品。

最后分享一个我常用的判断标准：如果你做的智能体，业务部门的同事愿意主动推荐给其他部门用，那说明你做对了。如果业务部门是被动配合、上线后没人用，那不管技术指标多好看，这个项目都是失败的。