AI 产品的复杂体验，往往来自几种基础机制的组合。围绕“你需要知道的 AI 三种机制”这个主题，可以从工程视角把它们理解为：模型负责生成内容，系统负责检索事实，代理负责采取行动。理解这三层，有助于判断一个功能究竟应该依赖模型能力，还是应该补上数据与工具链。
生成：模型如何给出答案
生成机制的核心，是根据已有上下文预测接下来最可能出现的内容。对大语言模型来说，输入的问题、历史对话、系统指令和外部资料都会被转换成上下文，模型再逐步生成文本。
这解释了几个常见现象：
- 模型擅长总结、改写、分类和生成草稿，因为这些任务主要依赖语言模式。
- 同一个问题换一种问法，结果可能不同，因为上下文改变了概率分布。
- 语言流畅不等于事实正确。模型的首要目标是生成合理的后续内容，而不是自动验证每个事实。
因此，适合让模型直接完成的任务通常是低风险、可人工检查或有明确格式约束的工作，例如生成会议纪要初稿、把日志转换成摘要、根据模板起草邮件。
检索：把答案连接到真实资料
当问题涉及公司内部文档、最新产品信息或需要精确引用的知识时，单靠生成机制不够。检索增强生成（RAG）的基本做法，是先从文档库中找到相关片段，再把这些片段交给模型生成答案。
一个可落地的流程可以拆成四步：
- 将文档切分成大小适中的片段。
- 为片段建立关键词索引或向量索引。
- 根据用户问题召回相关片段。
- 要求模型只基于召回内容回答，并在找不到依据时明确说明。
检索并不会自动消除错误。召回内容可能过时，片段可能被截断，问题也可能本身就没有对应资料。生产系统需要记录召回结果、文档版本和答案引用，方便排查“模型错了”还是“检索错了”。
行动：让模型调用工具完成任务
生成和检索主要解决“说什么”，行动机制则解决“做什么”。当模型能够调用搜索、数据库、计算服务或业务 API 时，它就从问答界面变成了一个任务执行器。
一个典型流程如下：
用户请求
-> 模型判断意图
-> 选择工具并生成结构化参数
-> 服务端校验权限和参数
-> 调用业务 API
-> 把结果返回给模型
-> 模型生成最终回复
这里最重要的边界是：模型可以提出行动建议，但不应天然拥有无限权限。删除数据、转账、发送外部邮件等操作应该经过服务端鉴权、参数校验和必要的人工确认。工具调用也应该限制在明确的接口集合内，避免把任意 SQL、任意 Shell 或任意网络请求直接暴露给模型。
一个可运行的最小示例
下面的 Python 示例不依赖第三方库，用三个函数模拟三种机制：生成一个草稿、从本地资料中检索依据、调用一个受控工具。它不是完整的 LLM 实现，但可以帮助你设计应用边界。
将代码保存为 ai_mechanisms_demo.py 后运行 python ai_mechanisms_demo.py：
from dataclasses import dataclass
from typing import Callable, Dict, List
@dataclass
class Document:
title: str
content: str
DOCUMENTS = [
Document("退款政策", "普通订单在发货前可以申请退款，到账时间取决于支付渠道。"),
Document("服务时间", "客服工作时间为周一至周五 09:00-18:00。"),
]
def generate_draft(question: str) -> str:
"""模拟生成机制：根据问题产生一个待核验的草稿。"""
return f"关于“{question}”，建议先确认相关政策，再给出明确答复。"
def retrieve(question: str, documents: List[Document]) -> List[Document]:
"""模拟检索机制：用关键词匹配召回本地资料。"""
keywords = set(question.replace("？", "").replace("?", ""))
return [doc for doc in documents if keywords & set(doc.title + doc.content)]
def check_order(order_id: str) -> str:
"""模拟行动机制：只允许调用预先注册的业务工具。"""
if not order_id.startswith("ORD-"):
raise ValueError("订单号格式必须为 ORD-xxxx")
return f"订单 {order_id} 当前状态：待发货"
def run(question: str, order_id: str = "") -> None:
draft = generate_draft(question)
sources = retrieve(question, DOCUMENTS)
print("[生成]", draft)
print("[检索]", [doc.title for doc in sources] or "没有找到可靠资料")
if order_id:
print("[行动]", check_order(order_id))
if __name__ == "__main__":
run("订单可以退款吗？", "ORD-1001")
真实项目中，可以把 retrieve 替换为全文搜索或向量数据库，把 check_order 替换为内部 API，再由模型输出符合 JSON Schema 的工具参数。权限校验仍然应该放在服务端，而不是放在提示词里。
如何选择机制
可以用下面的判断方式快速拆解需求：
- 目标是改写、总结或创作：优先使用生成机制，并加上格式约束。
- 目标是回答内部知识或实时信息：加入检索机制，并保留来源。
- 目标是查询或修改业务状态：引入行动机制，同时增加鉴权、审计和确认步骤。
- 目标同时包含三类任务：把它们拆成独立阶段，分别观察生成质量、召回质量和工具执行质量。
这三种机制的成本和风险并不相同。生成通常最容易接入，但事实边界较弱；检索需要维护文档、索引和版本；行动最有价值，也最需要权限控制和失败恢复。AI 系统做得可靠，关键不是让模型“什么都能做”，而是让每一步都知道自己的依据、权限和退出条件。