一个正在发生的变化：AI 从对话框走进业务系统

2026 年 6 月，在 ISC.AI 2026 大会上，中国信息通信研究院人工智能研究所与 360 集团联合发布了《企业级智能体技术与应用研究报告（2026 年）》。据中国工信新闻网的公开报道，这份报告给出了几个值得注意的判断：

· 企业级智能体正从试点阶段进入

，开始真正接受以效率、质量和业务价值为标尺的"KPI 考核"；

：大模型把 AI 带进了对话框，企业级智能体则开始把 AI 带进客服、审批、生产和管理等真实业务系统；

· 下一阶段企业 AI 的竞争，不再只是比模型有多聪明，而是

比谁能把模型、企业知识、业务工具和管理流程组织成一套稳定运行的生产系统

· 报告同时提到，安全层面需要把权限管理、运行监测、过程审计融入智能体建设全程，确保执行过程

这几句话对准备做 AI 项目的老板来说，信息量很大。它意味着：讨论的焦点已经从"用哪家的大模型"转移到"怎么把它接进业务、怎么管住它、怎么衡量它"。

（以上为对公开发布的报告内容的转述，具体表述以报告原文为准。）

只会聊天的智能体，价值上限很低

很多 AI 项目的第一期是这样的：把企业文档喂进去，做一个问答机器人，员工或客户可以在里面问政策、问流程、问产品。上线之后，大家觉得"能用"，但也仅此而已——它替代的是"翻文档"这个动作，而不是"办成一件事"。

问"差旅住宿标准是多少"，这是检索；问"帮我订一张下周去上海的高铁票并提交审批"，这是执行。后者的价值是前者的数倍，因为它省掉的是一整段人工流程，而不只是一次查找。

但"能动手"也立刻带来风险：它可能订错日期、订错人、提交错误的审批流、触发一笔不该发生的退款。

所以智能体项目的核心决策，不是要不要让它动手，而是让它动手到哪一步、动错了怎么办。

把"执行能力"安全地放出来，通常需要四道闸门。它们不复杂，但每一道都决定了项目能不能上线。

智能体只能调用一份明确列出的动作清单：查询订单、创建工单、修改某个状态字段、发送通知……清单之外的动作一律不允许。这里的关键是

——不是"可以操作订单"，而是"可以将订单状态从 A 改为 B，且仅限在满足条件 C 时"。

很多事故不是因为模型越权，而是因为给它的接口太宽泛（例如给了一个"更新订单"的接口，参数不限），模型在合理意图下做出了超出预期的修改。

涉及金额、数量、不可逆操作的动作，要设置阈值：低于阈值自动执行，高于阈值转人工确认。阈值不是技术参数，是业务决策——它应该由业务负责人来定，而不是由开发团队默认设置。

同时，凡是"不可撤销"的动作（发起转账、删除数据、对外发送消息），都应该保留人工确认环节，哪怕它降低了一部分效率。

效率的提升如果以不可逆的错误为代价，是不划算的。

即使有了白名单和阈值，错误仍会发生。所以每一个可执行动作都要设计对应的撤销或补偿路径：改错了状态能不能回退？发错了通知能不能撤回或补发更正？创建的工单能不能合并或关闭？

这一条在需求阶段经常被忽略，因为大家都假设"AI 不会错"。但从工程经验看，错误不是会不会发生的问题，而是以什么频率发生的问题。

每一次智能体的动作都要留下一条记录：谁发起（用户或触发条件）、智能体基于什么信息做出了判断、调用了哪个动作、传了什么参数、结果是什么。

这不只是为了事后追责，它也是

。没有日志，你无法回答"为什么它在这类问题上总是做错"。

谈 AI 项目的预算时，很多老板的第一反应是 Token 费用。实际上，在多数企业级项目里，Token 成本通常不是最大的那一块。更大的通常在四处：

 智能体要动手，业务系统就必须把能力暴露成稳定、可调用、有权限控制的接口。很多企业的老系统根本没有接口，或者接口文档缺失、语义不清。把这些接口梳理、封装、加上鉴权与限流，往往是整个项目里工作量最大的部分。这也是前述报告里"系统改造期"这个说法的含义。

 让智能体回答得准，前提是喂给它的知识是干净的：去重、分版本、标权威层级、划适用范围。这一步是纯人力工作，且无法完全自动化。

 你需要一组有标准答案的问题，用来在每次改动后验证效果没有退化。构建这组问题需要业务专家参与，而且它不是一次性的——业务规则变了，评估集也要跟着更新。

 智能体处理不了的部分要转人工，而人工兜底的排班、培训、质检都属于持续成本。

在项目预算里，这一项最容易被漏掉

，结果就是上线后一线团队被动承担额外工作量，产生抵触。

怎么判断它到底有没有产生价值

接下来说评估，因为这是 AI 项目最容易自欺的地方。

建议先定四个基线指标，再上系统：

：同样一件事，人工平均花多久？智能体接入后降到多少？

：用户的问题在一次交互内被解决的比例。

：智能体的输出需要人工修正的比例。

：多少比例的问题最终还是交给了人。

转人工率下降，但人工处理时长上升。

这种情况很典型：智能体把简单问题都处理了，剩下转给人的全是被它搞复杂的问题——用户已经和机器人纠缠了三轮，情绪更差，情况更难理清。结果是机器"解决"了 60% 的问题，但剩下 40% 的人工成本翻了倍，总账并不划算。

看整条链路的总成本与总时长，而不是看智能体单独处理了多少。

另一个建议是分阶段灰度：先在低风险场景（内部知识问答、标准化查询）验证稳定性，再逐步扩展到复杂场景。这样即使出问题，影响范围可控，也更容易获得组织内部的信任。

最后给一个"不做清单"。以下三类需求，建议在立项阶段就否掉或大幅缩减范围：

第一类：需要绝对精确且错误不可逆的场景。

 例如直接根据 AI 判断执行大额资金划转、自动生成对外法律文件并直接发出。这类场景里，AI 作为"辅助生成 + 人工复核"是合适的，作为"自动执行"是不合适的。

第二类：知识本身还在剧烈变化的场景。

 如果业务规则每个月都在改、政策还没定稿、流程尚未标准化，那么先做的是流程梳理，而不是上 AI。把混乱的流程交给 AI，只会得到自动化执行的混乱。

第三类：没有可衡量目标的场景。

 "我们也想做个 AI"不是需求。如果无法说清楚"上线后哪个指标会变好、变好多少算成功"，那么项目结束时必然无法验收，也无法判断该继续投入还是止损。

如果只能记住几件事，建议是这五条：

1. 这个智能体要做的是"检索"还是"执行"？如果要执行，动作白名单是什么？

2. 涉及金额与不可逆操作的阈值由谁定？超过阈值怎么办？

3. 每一个可执行的动作，撤销或补偿路径是什么？

4. 业务系统需要暴露哪些接口？这些接口现在存在吗？改造工作量有多大？

5. 上线后用什么指标验收？基线数据现在有没有采集？

第 5 条最容易被跳过，也最致命——

没有基线，就没有办法证明 AI 带来了价值，也没有办法说服组织继续投入。

把前面的内容串起来看，会发现一个不太技术化的结论：智能体项目的难度，大部分不在算法上，而在组织上。

它需要你把业务规则说清楚（否则智能体无从判断），把系统接口理顺（否则智能体无从动手），把责任边界划定（否则没人敢上线），把指标定好（否则无法验收）。

这几件事，其实都是企业管理的基本功。AI 只是用一种非常直接的方式，把它们的重要性放大了——

流程不清楚的企业，会在引入 AI 时第一次真切地感受到这件事的代价。

智能体项目的成本大头不在 Token，在接口改造和人工兜底

人工智能

企业级智能体正从对话走向实际业务系统，核心挑战在接口改造、知识整理、评估与人工兜底四大成本。通过动作白名单、阈值确认、撤销补偿、审计日志四道闸门管控风险，建立处理时长、一次解决率、错误率、转人工率四指标，立项前需验证检索还是执行、明确撤销路径和验收基线。

智能体

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

智能体项目的成本大头不在 Token，在接口改造和人工兜底

智能体项目的成本大头不在 Token，在接口改造和人工兜底

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐