AI Agent（智能体）指能围绕一个目标，自己规划步骤、调用工具、根据中间结果调整做法的 AI 系统，是否完成任务仍需检查。据 Anthropic 的说法，agent 有多种定义，业内用法并不统一。聊天界面可以是智能体的入口，判断时应看系统如何决定流程和使用工具，而不是看界面长什么样。
这篇文章讲清楚定义、和相近概念的区别、组成、MCP、搭建路径、适用场景和风险。读完你应该能判断：自己的业务需不需要智能体，需要的话从哪里起步。
一、AI Agent（智能体）到底是什么？
最简单的理解：大模型负责「想」，工具负责「做」，智能体就是把两者接在一起、并让模型自己决定什么时候用哪个工具的系统。比如你说「把这周的客户咨询整理成跟进清单」，智能体会自己去查聊天记录、按规则归类、写出清单，必要时再去补查缺失的信息，而不是只回你一段文字。
业内讨论智能体时，Anthropic 在《Building effective agents》一文里给过一个很实用的区分。据 Anthropic 的说法，workflow 是按预先定义好的代码路径来编排大模型和工具；agent 则是由大模型动态决定自己的流程和工具使用方式。前者路径固定、可预期，后者更灵活、也更难控制。
这个区分直接影响选型。同一篇文章还建议从最简单的方案开始，只在确实需要时才增加复杂度。落到企业场景就是：能用固定流程加一次大模型调用解决的，就别做成自主决策的 agent。
二、智能体和聊天机器人、自动化、RPA 有什么区别？
这几个概念经常被混着说。下面按几个关键维度对比，便于判断自己的需求属于哪一类。
| 对比项 | 聊天机器人 | 传统自动化 / RPA | AI 智能体 |
|---|---|---|---|
| 核心能力 | 对话问答 | 按固定规则重复操作界面或接口 | 理解目标、规划步骤、调用工具 |
| 遇到没见过的情况 | 尽力回答，不负责执行 | 通常直接报错或停下 | 可以根据情况调整做法，但需要护栏 |
| 输入形式 | 自然语言 | 结构化数据、固定界面 | 自然语言加各类资料 |
| 能否办完一件事 | 一般不能，只给答案 | 能，但只限预先写死的路径 | 能，范围取决于接入的工具与权限 |
| 可预期性 | 中 | 高 | 较低，需要日志与人工兜底 |
| 适合 | 客服答疑、内容问答 | 规则固定、格式统一的批量操作 | 多步骤、需要判断的任务 |
要点是：智能体并不取代自动化和 RPA。规则死板、格式统一的活，用传统自动化更稳、更便宜；智能体的价值在于处理那些「要先读懂内容才知道下一步」的环节，比如读一封客户邮件，判断是投诉还是询价，再决定转给谁。
三、一个能干活的智能体由哪几部分组成？
- 模型：负责理解指令、做判断、生成内容。选模型看任务难度，简单的分类和提取不必用最大的模型。
- 工具：智能体能「动手」的部分，比如查数据库、读文档、发消息、建工单、调用某个业务系统的接口。没有工具，系统就只能输出文字，很难称为能办事的智能体。
- 记忆与知识：包括当前任务的上下文（短期记忆），以及企业自己的资料、制度、产品手册（知识库）。常见做法是把资料切片后检索再交给模型，也就是 RAG（检索增强生成）。
- 流程：任务该先做什么后做什么、什么时候该停、什么时候该转人工。这部分在 workflow 里由代码写死，在 agent 里由模型决定，但边界依然要人来设。
- 权限：智能体能读哪些数据、能写哪些系统、能不能发对外消息。权限决定了出错时的最大损失。
流程与权限这后两项容易被低估：模型选得再合适、工具接得再顺，如果流程没有兜底、权限给得过宽，试运行阶段的风险就会暴露出来，需要在上线前逐条检查。
四、MCP 是什么，和智能体有什么关系？
MCP 全称 Model Context Protocol，由 Anthropic 于 2024 年 11 月发布，是连接 AI 应用与外部工具、数据源的开放标准，官方站点是 modelcontextprotocol.io。可以把它理解为 AI 世界的「统一接口规范」：工具方按规范提供一个 MCP 服务，支持 MCP 的 AI 应用就能用同一种方式去调用，可以减少部分重复对接工作，但具体能力的兼容、授权和适配仍要逐项处理。
对智能体来说，MCP 解决的是「工具怎么接」的问题。接入的工具越多，智能体能办的事越多，同时风险也越大，所以接每一个 MCP 服务之前，都要先想清楚它能读什么、能改什么。MCP 是接口规范，不是安全保证，权限控制仍然要自己做。
五、智能体怎么搭建？从零代码到写代码的路径
下面是一条循序渐进的路径，每一步都可以停在那里，用得够了就不必往下走。
- 写清任务：用一页纸写下目标、输入是什么、输出长什么样、什么情况算做完、什么情况必须转人工。写不清楚的任务，做成智能体只会更乱。
- 先手动跑通：用主流大模型的对话界面，拿十几条真实样本人工试一遍，看它在哪里出错。这一步能较早暴露需求问题，成本较低。
- 用零代码平台搭第一版：选一个支持工作流、知识库和常用工具的平台，把任务搭成固定流程，接上知识库。部分内部问答、资料整理类需求，到这一步可能就够用了。
- 补工具接口：需要查业务系统、发消息、建工单时，通过平台提供的插件、HTTP 接口或 MCP 服务接入，先接只读的，再接可写的。
- 加评测与日志：留一批标准问题和标准答案，每次改动后重跑；记录每一次工具调用，出了问题能回溯。
- 再考虑写代码：当平台的灵活度不够、需要深度集成老系统、或对数据与部署有特殊要求时，再用代码开发，这一步通常需要工程师参与。
六、哪些场景适合做智能体，哪些不适合？
常见的判断标准是三条：痛点清晰、规则明确、重复度高。满足的先试，不满足的先放一放。
- 适合：内部制度和产品资料问答、客户咨询的首轮应答、销售线索与聊天记录整理、工单分类和初审、会议纪要转待办、周报与数据摘要。
- 谨慎：涉及报价、合同条款、退款这类要承担责任的对外承诺，可以让智能体出初稿，但必须有人确认后再发出。
- 不适合：没有任何规则可循的决策、关键审批、需要法律或医疗专业判断的结论，以及资料本身混乱、没人维护的领域。资料不行，智能体只会把混乱放大。
「数字员工」是企业里对这类智能体的常见叫法，意思是给它一个明确的岗位、一套规则和一份权限，让它承担岗位里重复的那部分任务。用「员工」来想有个好处：新员工要培训、要考核、要有人带，智能体也一样。
七、用智能体有哪些风险，怎么防？
| 风险 | 表现 | 常见防法 |
|---|---|---|
| 幻觉 | 编造不存在的政策、数据或引用 | 回答限定在知识库范围内，要求给出处，无依据时回答「不知道」 |
| 权限越界 | 读到不该读的数据，或执行了不该执行的操作 | 最小权限原则，先只读后可写，敏感操作单独授权 |
| 成本失控 | 循环调用工具、上下文越来越长，调用量暴涨 | 设置单任务步数与调用上限，监控用量并设告警 |
| 没有兜底 | 出错后没人发现，错误扩散到客户 | 关键动作人工确认，保留完整日志，设置转人工的触发条件 |
| 资料过期 | 知识库里的制度已更新，智能体还在按旧的答 | 指定资料负责人，定期更新并抽检 |
一个实用原则：让智能体做的每一件事，都要能回答「它做错了，谁能发现、多快发现、损失多大」。回答不了，就先降低它的权限。
八、企业落地智能体，常见做法是什么？
试点可以先选择痛点清晰、规则明确、重复度高的场景，验证有效再推广；业务部门最好参与规则制定和验收，而不是把它当成纯 IT 项目；老旧系统缺少接口是常见阻碍，需要提前评估对接成本；上线后可以用业务指标持续复盘，比如首次响应时间、人工转接率、一次解决率。
试点阶段建议只定一个场景、一个负责人、一组指标，跑一两个月再看。团队内部如果没人会用，再好的智能体也可能被闲置，所以培训和系统搭建应当一起考虑，可以参考我们的另一篇《企业 AI 落地实操指南》。
九、莱客能提供什么？
莱客是深圳龙岗的企业 AI 落地与 AI 技能教育服务商，成立于 2016 年。与本文相关的业务主要有三类：智能体与 AI 助手开发，围绕业务流程构建 AI 数字员工，接入资料、流程和工单；企业知识库问答，把制度、手册、产品资料做成随问随答的系统；企业 AI 落地诊断，先把流程过一遍，筛出适合做智能体的环节。
莱客智能体（agent.laikr.com）是我们自己在运行的产品，可以直接打开看。如果想先判断自己的业务适不适合，可以先做在线 AI 落地诊断；课程方案与安排请联系顾问。