简介：一份聚焦大模型应用与AI智能体开发平台的PPT，适合AI开发者、产品经理及高校师生入门智能体开发。内容以女娲智能体平台为主线，系统讲解插件、工作流、触发器如何拓展智能体能力，文档/表格/照片三类知识库的应用场景，以及变量、数据库、长期记忆、文件盒子等记忆机制；并结合母婴助手智能体实例，展示角色定义、提示词编写、技能添加与工作流自动化的完整搭建思路。资源包共1个文件，为pptx演示文稿，整体大小10.4MB，排版清晰、图文结合，便于作为课程讲义或自学参考。已有535人学习，适合希望快速了解智能体开发平台全貌并上手实践的读者。
1. 别急着让模型跑分：这份PPT真正要你搭的是AI智能体开发平台
业务方丢来一份《大模型应用-AI智能体开发平台.pptx》，让我评估这个方向能不能落地，预算大概要多少。这类标题的方案我见过不少，它通常不是要你做一个聊天机器人，也不是让你从头训练大模型，而是要把大模型从“对话框”里放出来，给它装上任务拆解、工具调用和自主决策的能力，这就是AI智能体；再把一批这样的智能体配上开发、调试、发布、监控的流水线，才是开发平台要交付的东西。平台真正的难点不在模型选型，而在工程化：工具协议怎么定、权限边界在哪、上下文怎么管、并发怎么扛、出问题怎么追溯。这篇笔记适合三类人：做企业大模型私有化交付的乙方，搭AI应用平台的甲方技术团队，以及传统软件公司想给产品接大模型能力的人。
2. 平台选型三问：自研、开源还是商业底座
拿到这类PPT，第一步不是找代码仓库，而是先想清楚自己要哪一种“平台”。市面上叫“智能体开发平台”的东西，底层完全是三套玩法：自研编排框架、开源平台二次开发、商业SaaS直接订阅。选错了，后面每一个功能迭代都要还债。
2.1 先给平台画一张功能地图
我一般会让团队先画一张六层功能地图，再对着地图打勾，不管选哪条路线，这张地图都应该覆盖完整。核心模块大致如下：
| 层级 | 核心能力 | 典型问题 |
|---|---|---|
| 接入层 | Web UI、OpenAPI、企业微信/钉钉等渠道 | 用户从哪里发起对话或任务 |
| 模型路由层 | 多模型接入、负载均衡、成本统计、限流 | 用哪个大模型处理哪类任务 |
| Agent运行时 | 任务规划、工具调用循环、记忆读写 | 智能体怎么拆解一个复杂请求 |
| 工具层 | 工具注册、参数校验、权限控制、插件市场 | 智能体能调用哪些系统和接口 |
| 编排层 | 可视化工作流、分支、人工确认节点 | 复杂流程怎么编排而不是靠提示词硬凹 |
| 可观测层 | 全链路日志、Token统计、评测集、告警 | 线上翻车时能不能三分钟内定位 |
这张地图最大的价值是让所有人都知道“平台”不等于“模型接口封装”。很多团队拿着一个OpenAI兼容接口就说是平台，结果业务方接进来发现连工具调用、会话记忆、权限审计都没有，等于买了个壳。
2.2 三条路线：自研编排、开源平台、商业SaaS
对照功能地图做选型，常见路线是三条。自研路线用LangGraph、Semantic Kernel这类编排框架，适合已经有AI算法团队、工具协议非常特殊、需要深度定制的公司，代价是所有模块都要自己写，光可观测体系就够做一个季度。开源平台路线用Dify、FastGPT这类的开源版本做底座，保留私有化部署能力，适合数据不能出域、需要本地大模型支撑的企业，这也是目前企业大模型私有化部署最主流的一条路线，缺点是二次开发要跟上游版本保持同步。商业SaaS路线用Coze这类在线平台快速验证，绑定模型、插件即插即用，适合做Demo和低合规要求的内部工具，但数据主权和深度定制基本别想。
三条路线的取舍我总结成一张对比表：
| 维度 | 自研编排框架 | 开源平台二次开发 | 商业SaaS |
|---|---|---|---|
| 典型代表 | LangGraph、Semantic Kernel | Dify、FastGPT | Coze、云厂商智能体平台 |
| 上手速度 | 慢，需要自己拼全家桶 | 中等，一天能跑通Demo | 快，十分钟能出Demo |
| 私有化部署 | 完全可控 | 支持 | 基本不支持 |
| 深度定制 | 最灵活 | 依赖架构设计与插件机制 | 受限 |
| 长期维护成本 | 最高 | 中等，要跟版本 | 低，但订阅费随调用量涨 |
| 适用场景 | 工具复杂、流程苛刻的大厂 | 企业私有化、数据合规 | 验证想法、非核心链路 |
一个很现实的原则：如果业务方连“数据能不能出域”都答不上来，那默认走私有化路线，也就是自研或开源平台。
2.3 选型必问的五个问题
工具/方法层面的选型判据有三个，但这里更关键的是五个方向性问题：第一，数据能不能出域、能不能调用公有云API，这直接排除掉商业SaaS；第二，智能体要调用的系统多不多，如果超过五个异构系统，工具层设计比模型选型重要得多；第三，谁来开发智能体，是业务人员拖拽编排还是工程师写代码，这决定要不要可视化编排界面；第四，对可观测性有没有硬性要求，金融、政务类项目连审计日志都要保留，开源平台得提前看日志能力够不够；第五，业务是否需要多模态能力，比如看图片、听语音，选型时把多模态大模型的支持也一并加入评估。
这五个问题在PPT评审会上就能问，答不上来的地方就是项目风险点。选型不用纠结到完美，先定一个能跑通全链路的底座，后面再替换其中某一层，比一开始憋大招要稳妥得多。
3. Agent的内核：规划、工具调用与记忆管理
选型定了，接下来要把智能体本身讲透。很多方案写到“接入大模型”就停了，仿佛大模型会自动变成智能体。实际上，一个可靠的AI智能体需要四个组件拼在一起，缺一个都会露馅。
3.1 一个智能体的运行时由四个部件组成
我习惯把Agent运行时拆成四块：任务规划、工具调用、记忆读写、反思与自纠。任务规划负责把一个模糊需求拆成可执行的子任务，比如“帮我分析这个月订单异常”会拆成查数据、算指标、给结论三个步骤；工具调用负责在规划后选对工具并填对参数；记忆读写负责把历史对话、业务状态和外部知识组织起来；反思自纠负责在结果不合理或工具报错时换一条路重试。
这四块在一个循环里工作：模型接收用户请求，输出规划或工具调用指令，运行时执行工具，把结果回填给模型，模型再决定下一步。整个过程就是常说的“ReAct循环”，大模型是大脑，工具是手脚，运行时的代码是控制系统。理解这个循环就明白了一个反直觉的结论：平台的价值不在于模型多聪明，而在于运行时能不能稳定地把模型输出的调用意图转成真实系统动作。
3.2 先把工具协议定好：JSON Schema与函数调用
工具调用的第一步不是写代码，而是定协议。当前主流做法是用JSON Schema描述工具入参，让大模型根据描述决定调用哪个工具、填什么参数。下面是一个典型的工具定义：
{ "name": "查询订单状态", "description": "根据订单号查询订单当前状态，当用户询问物流、发货、订单进度时使用", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，形如 ORD20240101" } }, "required": ["order_id"] } }这段定义会被拼进发给大模型的系统上下文里，模型看完后如果判断需要查询，就输出一个结构化的调用意图。这里最关键的是description字段，它决定了模型在什么时候触发这个工具。写法上要包含两个要素：第一是触发条件（用户在问什么时用），第二是反例即什么时候不用，比如“仅当用户提供订单号时调用，若缺少订单号则先向用户索要”。parameters里的description同样重要，模型靠它来把用户话术里的信息映射到参数上，写得太泛模型就会填错。
模型返回的调用指令通常长这样：
{ "tool": "查询订单状态", "args": { "order_id": "ORD20240101" } }运行时收到这条指令后做三件事：校验参数是否符合Schema，不符合就回退或让模型补全；调用真实工具执行；把执行结果作为一条新消息回填给模型，让模型基于真实结果生成最终回复。很多AI智能体平台卡在第二步，因为工具调用是黑匣子，返回错误后模型看不到异常堆栈，只能猜。
3.3 记忆分三档：上下文、向量库与业务状态
记忆设计是Agent落地最容易欠债的地方。我按三层来分：短期记忆用上下文窗口承载，把最近几轮对话原样传给模型，这里就要关注大模型上下文长度，上下文越长越贵也越慢，不能无脑全塞；中期记忆用向量数据库存文档片段，用户问“我们之前那个异步任务后来怎么处理的”，系统先做语义检索再把相关片段拼进上下文；长期记忆存业务状态，比如用户搞定单查询频次、常用收货地址，这属于业务数据，得落在结构化存储里而不是模型上下文里。
最常翻车的做法是把所有历史对话都往上下文里堆，看起来是“让模型记住”，实际上上下文一长，模型对早期信息的注意力会衰减，而且Token成本直线上升。我的经验是上下文里只保留最近五轮对话和当前子任务的中间结果，和当前意图相关性不高的信息走向量库，需要精确计算的业务记录走数据库字段查询。这样既控制成本，也能让模型专注当前目标。
4. 把最小智能体跑通：Dify接入本地大模型加自定义工具
理论讲完，进入可复现的实操环节。这一章用一个常见组合：Dify做开发平台，Ollama跑本地模型，再加一个自己写的FastAPI工具后端。整套环境跑起来之后，你会看到“用户提问→模型规划→工具调用→结果回填→生成回答”的完整链路。
4.1 最小环境：Docker Compose装Dify，Ollama跑本地模型
先准备一台8核16G以上内存的Linux服务器，这是底线配置，低于这个跑7B模型都会卡。Dify的部署用Docker Compose进行，一条命令拉起包括API服务、Worker、PostgreSQL、Redis、向量数据库在内的全套组件：
git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d说明：这组命令会把Dify后端和中间件一起启动，.env里有密钥、数据库配置、存储方式等参数。我自己一般会改三个地方：一是SECRET_KEY，生产环境必须换成随机字符串；二是EXPOSE端口，避免和现有服务冲突；三是向量数据库的索引配置，如果要跑知识库检索，提前想好用哪种向量库。启动后用浏览器访问服务器IP的80端口，设置管理员账号就能登录控制台。
本地模型的启动用Ollama，一条命令拉模型，一条命令启动服务：
ollama pull qwen2.5:7b OLLAMA_HOST=0.0.0.0:11434 ollama serve说明：qwen2.5:7b是7B参数的中文模型，对工具调用的支持比较稳，是入门首选。OLLAMA_HOST设成0.0.0.0才能让Dify容器访问到，只监听127.0.0.1的话容器外访问不到。启动后用curl验证一下模型服务是否正常响应。
在Dify控制台的“设置→模型供应商”里添加Ollama，API Base URL填宿主机IP加11434端口。模型名填qwen2.5:7b，类型选LLM。这一步就把本地大模型接入了平台，后续创建应用时就能选到它。
4.2 写一个工具后端：FastAPI三分钟接口
平台接入模型只是第一步，要让Agent有手有脚，得给它一个真实可调的工具。这里用一个订单查询服务做示范，工具后端的代码用FastAPI写，核心逻辑如下：
from fastapi import FastAPI from pydantic import BaseModel import datetime, random app = FastAPI() class OrderResponse(BaseModel): order_id: str status: str eta: str @app.get("/order/{order_id}", response_model=OrderResponse) def query_order(order_id: str): # 模拟真实订单系统：根据订单号尾号返回不同状态 tail = int(order_id[-2:]) if tail % 3 == 0: status, eta = "已签收", "2025-06-20 14:30" elif tail % 3 == 1: status, eta = "运输中", "2025-06-22 18:00" else: status, eta = "待发货", "2025-06-25 前" return {"order_id": order_id, "status": status, "eta": eta} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8321)逻辑说明：这个接口接收订单号，返回三个字段，order_id是原样回传方便对账，status是状态枚举，eta是预计时效。参数里最关键的设计是order_id作为路径参数，路径式参数比查询参数更符合OpenAPI描述习惯，Dify识别更准确。actual响应结构必须保持稳定，字段不要随手改，因为大模型要根据字段名来组织回答话术。
4.3 在Dify里注册HTTP工具并创建Agent应用
工具后端跑起来后，把它的OpenAPI描述注册进Dify。当前版本Dify的入口一般是在“工具→自定义工具→创建自定义工具”里，选择导入OpenAPI Schema或者手工填写。Schema结构如下：
{ "openapi": "3.1.0", "info": { "title": "订单查询工具", "version": "1.0.0" }, "paths": { "/order/{order_id}": { "get": { "operationId": "查询订单状态", "summary": "根据订单号查询订单状态与预计送达时间", "parameters": [ { "name": "order_id", "in": "path", "required": true, "schema": { "type": "string" } } ], "responses": { "200": { "description": "订单状态响应", "content": { "application/json": { "schema": { "type": "object", "properties": { "order_id": { "type": "string" }, "status": { "type": "string" }, "eta": { "type": "string" } } } } } } } } } } }这段Schema的作用是让Dify知道工具叫什么、什么时候该调用、参数怎么传、返回长什么样。操作Id里的“查询订单状态”会挂在模型可调用的工具清单上，所以起名要直白。然后创建Agent应用，模型选刚才接入的Ollama，工具里启用“订单查询工具”，把温度调到0，关闭随机性，避免同一条问题每次回复不一样，这在工具调用场景下很重要。
4.4 编排一条带人工确认的工作流
单轮工具调用跑通后，再进一步：创建一个工作流应用，把“用户提问→意图识别→订单查询→人工确认→最终回复”串成一条可审计的链路。Dify里拖四个节点就可以：开始节点接收用户输入；LLM节点做意图识别，输出是否是订单查询类问题；工具节点调用查询订单API；结束节点返回结果。人工确认节点通常加在图中的关键动作之后，比如发货指令、退款操作，这类高影响动作绝不能全自动。
这里有个最容易踩的参数点：工具节点拿到结果后，后续模型节点的上下文里会自动带上工具的输出，不需要你再手动拼接。但如果工具返回的结果太长，必须在工具层做裁减，字段越多越容易把上下文塞满。工作流上线前我建议加一个分支节点，当订单状态为“已签收”时走一句固定话术，不经过模型生成，省Token之外还能保证话术一致。
5. AI智能体平台落地的五个真坑
平台跑通demo很容易，上线才会暴露问题。以下五条全是我在类似项目里见过或者自己踩过的坑，每条按现象、原因、解决三个层次说透。
5.1 提示词越写越长，Agent反而越笨
现象：业务方觉得Agent表现不好，就往系统提示词里加规则，加了三十条之后，模型开始频繁漏调用工具，明明该查订单却直接编一个状态回复。原因：提示词越长，模型对指令的注意力越分散，几十条优先级不明的规则相互干扰，工具描述被挤到上下文边缘，相当于把棋手的眼睛蒙上了。解决：把提示词压缩成三段结构，角色定位、决策树、输出约束，其余细节全部移到工具描述里。比如订单查询的触发条件写进工具description，不写在系统提示词里。规则超过十条就考虑把决策逻辑挪到工作流里用分支节点做，而不是靠模型自己判断。
5.2 工具返回一坨长文本，上下文直接撑爆
现象：接了一个文档查询工具后，平台Token消耗猛涨，响应越来越慢，甚至出现请求失败。原因：工具接口把整份文档塞进返回体，一次查询就吃掉十几万Token，而模型读这么多内容只为了找一小段结论。解决：工具层强制做结构化裁剪，返回字段严格控制在摘要、相关片段、状态码三部分；超过阈值的长文本返回文档ID，模型需要全文时再二次调用；同时给工具加“是否需要全文”的出参，把主动权交给模型。这个问题的本质是工具设计没考虑模型上下文约束，任何让Agent处理超长原始文本的工具接口都不合格。
5.3 本地模型不支持函数调用，Agent空转
现象：模型换成某些开源权重后，工具一个都没被调用，或者输出一堆对话文本替代工具指令。原因：函数调用是模型在训练阶段专门对齐过的能力，不是所有模型都有，尤其是一些小参数通用模型，只学会了聊天没学会输出结构化调用指令。解决：两种做法，一是换支持function calling的模型，实测Qwen2.5系、GLM系对工具调用的支持比较稳定；二是不依赖平台内置的函数调用机制，改为在提示词里约定一个纯文本协议，让模型输出“ACTION: 工具名”加“ARGS: JSON”两行，用代码解析这个格式再触达工具。第二种方案丑但通用，适合必须用某个固定模型的场景。
5.4 并发一上来，模型服务先排队
现象：Demo阶段一切正常，全公司接入后请求开始超时，模型服务CPU打满，Dify后台排队任务堆积。原因：没有做模型网关的限流和分级，所有应用共用同一个本地模型服务，同步生成请求占满连接池，一个慢请求拖垮整条链路。解决：搭建模型网关统一入口，给不同应用分配配额，高优先级的内部系统不排队；启动流式输出，首字延迟比整体耗时更重要；长任务改成异步提交加回调通知，避免HTTP长连接占资源。重试策略用指数退避，不要秒级重试，否则雪崩就是这么来的。
5.5 线上出问题全凭感觉，黑匣子没人说得清
现象：业务方质问“为什么这个订单被处理成已退款”，打开后台只有最终答案，中间调了哪个工具、模型怎么想的、工具返回了什么，全是黑匣子。原因：部署时没做全链路追踪，只保存了最终响应结果。原因背后还有一个更隐蔽的问题：Agent的推理过程不可解释，审计和追责根本无从下手。解决：在平台层把每个会话的完整轨迹落库，包括模型输入输出、工具调用参数、工具返回原始数据、每一步的Token消耗，并给关键节点打上trace_id。这个能力在选型阶段就该确认，开源平台可能需要自己扩展，商业平台要看日志保留时长。顺带提醒，工具返回内容对模型来说是事实来源，务必对工具输出做白名单和格式校验，避免外部注入内容污染上下文。
6. 从能跑到敢上线：评测集和影子模式两个进阶动作
平台跑通只是开始，真正让AI智能体敢接生产流量，我靠两个动作，一个是评测集，一个是影子模式。
先建评测集。做法是从真实对话里抽五十到一百条请求，人工标注每条的期望结果：应该调用哪个工具、参数怎么填、最终回答包含哪些要点。这五十条就是回归测试的金标准，每次改提示词、换模型、改工具协议之后跑一遍，分数掉下来就说明改坏了。评测集规模不用大，但样本要真实，我在项目里用过一个原则：每接一个新工具，先补三条该工具相关的评测用例，跑过再放量。这比让人肉点一百遍页面靠谱得多。
影子模式的逻辑更简单，先让Agent在后台模拟决策但不真正执行。我在代码层面通常这样描述：
# 影子模式：先记录决策轨迹，不真正执行工具动作 decision = agent.plan(user_request) if shadow_mode: save_log(request_id, decision.trace, decided_by="agent") human_result = business_handle(user_request) save_log(request_id, human_result, decided_by="human") else: agent.execute(decision)逻辑说明：影子模式下系统把Agent的规划轨迹记录下来的同时，真实业务还是走人工老流程，两边结果都存下来。跑两周之后对比Agent的决策和人工决策的重合率，重合率超过阈值再切真流量，切的时候先放百分之五的用户慢慢加。
这相当于给Agent上一个靠谱的观察期，比直接全量上线心态稳得多。
我后来做任何智能体项目都固定这套流程：先定工具协议，再建评测集，最后影子模式灰度。也是因为在第一个项目上吃过亏，当时demo演示很顺利，上线第一天就被一条“给我查去年的订单”打回原形，模型压根不知道去年这个时间概念映射不到数据库字段。后来补了三条类似用例在评测集里，回归时才敢点发布。这套流程不复杂，但很值得坚持，希望帮到你。
本文还有配套的精品资源，点击获取
