智能体的三个阶段从提示词人设到目标驱动工程边界在哪摘要市面上大量智能体其实只是包了人设的提示词。本文用三个阶段模型划清能力边界——提示词人设、工作流编排、目标驱动自主体并给出 RAG 把回答准确率从 60% 拉到 90% 的具体工程路径与平台选型依据。一、先定义清楚什么才算智能体判断标准只有一条而且很干脆能不能调用工具。用户直接提问、大模型直接给答复——这是大模型应用。一旦模型具备了调用外部工具的能力联网搜索、查数据库、调 API它才变成智能体。智能体包含大模型但大模型本身不是智能体。这条线划清楚之后很多讨论才有意义。比如「我在官网开了联网开关是不是就在用智能体了」——严格讲不是你操作的是一个应用联网能力是应用层封装好喂给模型的你没有让模型自己决定调不调。历史上对智能体的理解分两代时间提出者核心要素视角1986明斯基《意识社会》分布式智能体集合、层级协作、无中央控制认知科学2023翁丽莲OpenAI大模型、记忆、工具、规划、行动功能化系统设计明斯基那套是从认知科学出发的哲学式定义和今天写代码完全是两回事。真正能落地的是 2023 年那套五要素框架逐条对应到工程大模型决策中枢负责推理和规划记忆短期是上下文窗口长期靠向量库 / 知识图谱 / 微调工具扩展能力边界突破纯文本限制规划任务拆解 反思自省行动实际调接口、执行操作成熟度可以类比自动驾驶 L4——人设定目标和给资源AI 完成绝大部分执行闭环。二、三阶段模型能力越强可控性越弱这是我见过最实用的一张判断表。分阶段的依据不是「用了什么技术」而是谁来决定执行路径。阶段一提示词立人设典型形态是 GPTs、各类客户端的「智能体」功能。你写一段提示词定义角色模型按这个人设回答。能力边界非常清楚没有自主工具调用没有流程控制依赖模型固有能力。所以业内管它叫「阉割版智能体」不算贬义只是准确。适用场景角色扮演、风格化写作、固定话术的客服问答。这类场景不需要工具也不需要多步流程提示词够用。阶段二工作流编排每一步的模型、插件、节点顺序由人显式指定系统按设定流程执行。从编程范式类比这是「面向过程」——你写的是流程图不是目标。所以它的特点恰好是确定性高、可控性强、异常可枚举。输入 → 节点1(插件A) → 节点2(代码) → 节点3(大模型B) → 输出 ↓异常 重试/兜底分支阶段二的工程价值被低估了。企业级落地时大多数场景其实应该停在这一层因为业务方要的是「结果稳定」不是「AI 自主」。让 AI 自由决定怎么查数据出了错没人能解释为什么。阶段三目标驱动自主体人只给目标智能体自主完成任务拆分、工具选择、进度控制达成后自主结束。这是「面向目标」的架构。差别有多大举个具体的让人去对面桌子拿苹果要拆成语音转文本、视觉识别定位、机械运动控制多个环节每一步选什么工具、什么顺序阶段二需要人提前编排好所有分支阶段三由智能体现场决定。从阶段二到阶段三是质变但代价是可控性下降。所以生产环境的策略通常是核心业务链路走阶段二探索型任务走阶段三。下面这张图是三个阶段的关系可控性高 ←──────────────────────────────→ 可控性低 能力窄 ←──────────────────────────────→ 能力宽 阶段一 阶段二 阶段三 提示词人设 工作流编排 目标驱动 │ │ │ 固定角色 固定流程 自主规划 无工具 显式选工具 自主选工具 ← 企业落地主战场 →一个反直觉的结论阶段二不是过渡形态它是终态之一。就像不是所有程序都需要用声明式编程不是所有 AI 应用都需要自主智能体。三、RAG把准确率从 60% 拉到 90%知识库是智能体「记忆」要素的工程载体。为什么必须有它三个具体痛点痛点具体表现解法训练数据滞后问 2025 年春节档电影模型不知道联网搜索领域语料缺失问私域健身方案模型没学过私有知识库私域数据不可见公众号高质量内容不在训练集里特定数据源接入实测下来引入 RAG 后回答准确率可以从 60% 提升到 90%。这个数字怎么理解——打个比方让大模型去考一个它完全陌生的领域闭卷正确率可能只有百分之几给了参考资料就相当于开卷能顺着资料找到方向正确率能到 90%。这里要说清 RAG 的完整链路两步走数据存储过程PDF / Word / Markdown → 文本切分chunking → 嵌入模型向量化 → 存入向量数据库用户查询过程用户提问 → 问题向量化同一个嵌入模型 → 向量库相似度检索 → 检索结果作为上下文拼进提示词 → 大模型生成答案 标注来源踩坑点这两个过程必须用同一个嵌入模型。不同产品用的嵌入模型不一样有的用 BGE有的用其他一旦写入和查询用了不同的模型向量空间不对齐检索结果会完全随机——而且不报错只是答得莫名其妙。这是最难排查的一类问题。四、平台选型按场景而非按名气主流的几条路各有明确适用条件路径代表优势代价本地化客户端 本地知识库数据完全本地、可离线需配 API Key 与嵌入模型在线便捷在线搜索类产品拖拽上传即用数据存第三方服务器生态融合依托社交生态的产品独家私域语料、稳定性好绑定单一生态开源可部署Dify 类平台可本地部署、工具链国际化插件多需境外网络选型时按这个顺序问自己数据能不能出域不能 → 只能本地化方案其他不用看了。知识库更新频率每天变 → 必须支持增量更新不能整库重跑。有没有生态独占数据有 → 优先用能接这个数据的平台。有个坑需要提醒跨平台迁移成本极高。一旦在某个平台搭了复杂工作流比如「视频链接 → 文案提取 → 竞品分析 → 报告生成」迁移到别的平台要重写 80% 以上的逻辑因为插件生态是绑定的。应对策略是「核心能力自建 平台只作分发」知识库和 RAG 模块保持平台无关用标准向量库 标准嵌入模型平台层只负责界面和分发渠道。五、工程细节三个容易被忽略的配置细节 1temperature 与 Top-p 的选择逻辑不是所有场景都要低温度。创意生成类文案、故事需要温度高一些保证多样性数据查询、事实问答必须贴近 0保证可复现——同一个问题问两次得到不同数字在业务场景里是灾难。细节 2记忆要分层不是一层短期记忆是上下文轮数长期记忆是知识库更新频率。这两个参数要分开调。常见错误是把上下文轮数开到很大来「记住更多」结果 Token 爆了而且相关性反而下降——因为塞进去的无关历史会干扰模型。细节 3工具权限要显式配置知识库成员权限分公开 / 成员可见 / 私有三级。做企业知识库时权限必须在前端可见地配不能靠「反正内部系统没人乱看」这种默认假设。这条在合规检查时一定会被问到。六、这套东西的边界最后说清楚解决不了什么不能解决数据本身错误。知识库里写错的文档RAG 会把它当权威答案输出而且因为「有引用来源」显得更可信。不能替代流程梳理。工作流编排的前提是你得先把业务流程说清楚。流程本身混乱编排出来只是把混乱自动化了。不降低领域知识门槛。低代码让开发门槛归零但设计门槛更高了——提示词怎么写、工具怎么组合、记忆怎么分层这些需要业务理解不是拖拽能解决的。所以团队里真正稀缺的角色不是「会搭智能体的人」而是能把用户目标拆解成能力映射的人。这个活目前还没被工具替代。结尾三阶段模型最大的价值不是给技术分层而是给人一个判断依据你现在要做的事到底该用哪个阶段实现。很多项目失败不是技术不到位是一上来就想做阶段三结果可控性崩了。你在项目里踩过哪个坑是明明该用工作流却硬上了自主智能体还是 RAG 检索总召回不到对的内容评论区聊聊。评论区互动话术「关于阶段二和阶段三的边界我们现在的做法是核心链路走工作流、异常兜底才放给智能体决策算是混合。想问问有没有更明确的判断标准比如节点数量超过多少就该考虑自主编排」「嵌入模型那个坑太真实了。我们之前写入用了一个模型、查询换成另一个检索结果完全随机排查了三天才定位。补充一个换模型之后必须整库重建不能只换查询侧。」「想问下知识库更新频率这块你们是全量重建还是增量我们现在文档量大概两万份全量重建一次要四十分钟业务方抱怨更新不及时。」