一个只能聊天的 Agent，对企业来说价值有限。真正有用的 Agent，必须能够读取企业数据、调用业务系统、执行具体操作。实现这一点，需要两大核心技术：RAG（让 Agent 有知识）和工具调用（让 Agent 能行动）。
RAG：让 Agent 拥有企业知识
RAG（Retrieval-Augmented Generation）解决的是「大模型不知道企业私有信息」的问题。它的流程是：用户提问 → 从企业知识库检索相关片段 → 把问题和片段一起交给大模型 → 生成有依据的回答。
没有 RAG，大模型只能回答通用问题；有了 RAG，它就能回答「我们公司的退款政策是什么」「这款产品支持哪些接口」等企业专属问题。RAG 也是降低大模型幻觉的关键手段。
工具调用：让 Agent 具备行动能力
工具调用（Tool Use / Function Calling）让大模型能够调用外部 API、数据库、业务系统。例如，当用户说「帮我查一下订单 12345 的状态」，Agent 可以调用订单查询接口，获取真实数据后再回复。
工具调用的设计要点包括：工具描述要清晰、参数校验要严格、错误处理要完善、权限控制要到位。一个常见错误是给 Agent 开放的工具太多，导致它选错工具或参数填错。
| 能力 | 解决的问题 | 典型工具 |
|---|---|---|
| 知识检索 | 回答企业专属问题 | 向量数据库、企业知识库、文档系统 |
| 数据查询 | 获取实时业务数据 | 订单系统、CRM、ERP、数据库 |
| 操作执行 | 完成具体业务动作 | 退款、发券、创建工单、发送通知 |
| 信息计算 | 进行复杂计算或分析 | 代码执行、数据分析工具 |
合理地为 Agent 配备工具，是 Agent 工程的核心能力之一。
RAG 与工具调用的协同
在一个完整的 Agent 流程中，RAG 和工具调用往往是协同工作的。例如用户问「我上周买的耳机还能退换吗？」：
- Agent 先用 RAG 检索公司的退换货政策。
- 然后调用订单查询工具，找到用户上周的耳机订单。
- 结合政策和订单状态，生成准确回复。
- 如果符合退换条件，再调用退换货申请工具。
这种协同让 Agent 既有知识依据，又能采取实际行动，而不是纸上谈兵。
常见问题
RAG 和工具调用有什么区别？
RAG 让 Agent 能获取企业知识，回答事实性问题；工具调用让 Agent 能调用业务系统，执行具体操作。
为什么 Agent 需要工具调用？
因为企业很多价值来自业务系统，Agent 只有能操作系统，才能真正替代人工完成流程。
工具调用过多会有什么问题？
会增加 Agent 选错工具、填错参数的概率。建议按场景给 Agent 配备最小必要的工具集。
