简介：《大模型应用-AI智能体开发平台》PPT课件聚焦大模型应用开发平台，面向希望掌握智能体设计与搭建的产品经理、开发者及高校师生。内容从平台定义与核心价值切入，明确可视化界面、预置模型、全流程工具集成如何降低开发门槛，并以女娲智能体平台为主线，详解插件、工作流、触发器对智能体能力的扩展方式，以及文档知识库、表格知识库、照片知识库各自适用的数据场景。课件拆解了变量、数据库、长期记忆、文件盒子所构成的记忆机制，并区分知识与记忆在数据来源、可见性和共享规则上的差异。在实践部分，通过母婴助手智能体实例完整演示了智能体创建、提示词编写、技能添加、调试优化，以及利用工作流自动总结测评视频的搭建流程，具有较强的可操作性。整包为单个演示文稿文件，大小10.4MB，现有535人学习，适合作为教学课件或入门自学资料，可按章节顺序阅读并结合平台操作快速上手。
1. AI智能体开发平台：为什么大模型落地卡在“接线”而不是“模型”
企业里做AI落地，最容易被低估的一项工作，是把大模型接进业务流程。单独调Prompt、微调模型，大家已经摸索出不少套路；可一旦要把“对话”变成“能干活”的智能体，你面对的就是模型怎么选、工具怎么接、记忆怎么存、流程怎么编排这一整串问题。所谓AI智能体开发平台，就是把这四件事封装成一套可复用的工程框架，让研发团队不用每次从头搭脚手架。这篇笔记会沿着“选型→搭建→调参→排错→上生产”的顺序，把做智能体平台的关键环节拆开讲，适合正在从Demo往生产推、想少踩坑的工程师。
2. 拆开智能体开发平台：模型层、记忆层、工具层与编排层的选型逻辑
2.1 模型层：底座选型不只看分数，要看调用成本与控制力
先聊模型层，因为这一层的选择会直接限制上面几层的设计空间。很多团队选底座模型时习惯看公开榜单的分数，这个思路在智能体场景里不够用。一份40分的模型在单轮问答上可能只比90分的差一点，但到了连续工具调度、多轮状态跟踪、输出格式强制约束这类任务上，差距会迅速放大。我做过的项目里，最典型的翻车案例是：某个轻量模型在生成JSON时偶尔会在结尾多一个换行符，导致下游解析失败，单看问答质量根本发现不了。
所以我的选型习惯是三步走。第一步，把业务里最复杂的5个Prompt场景抽出来，做成固定的评测集；第二步，在候选模型上跑一轮，重点看工具调用准确率和结构化输出成功率；第三步，估算单位token成本与每请求平均token消耗，算出单次智能体任务的模型成本上限。如果预算敏感，优先考虑用本地部署的开源大模型把高频简单任务扛住，把复杂任务路由给商用模型，整体成本能降一个量级。
这一层还有一个很多人忽略的点：如果要走本地部署，接口协议尽量选兼容OpenAI格式的服务封装。目前常见做法是用Ollama或vLLM这类工具起服务，它们能把本地模型包装成标准API，上层代码不用为每家模型单独写适配。如果业务领域性很强，比如法律条文问答、设备维修知识库，还可以考虑在开源底座上先做微调再部署，这样指令遵循能力会更贴合场景。我在踩坑那一章会专门讲接口不兼容的问题，这里先记住原则：统一接口是平台稳定性的地基。
2.2 记忆层：短期上下文与长期向量库的分工
记忆层是智能体区别于普通对话机器人最关键的部分，也是最容易被做成“黑匣子”的部分。很多人一上来就上向量数据库，把所有历史消息都塞进Embedding，结果召回的片段上下文混乱，模型反而变笨。
正确的分工应该是：会话窗口内的近期消息走短期记忆，直接放进上下文供模型读取；跨会话的用户偏好、历史事实、业务规则走长期记忆，向量检索只负责把相关片段找出来，再拼接到当前上下文里。要记住一个原则：模型能直接读到的永远是“拼接后的上下文”，而不是数据库里所有数据。
具体实现上，短期记忆要控制窗口大小。不要简单地把最后N轮对话全塞进去，那样很快会顶到上下文上限。更稳妥的做法是在窗口内保留“完整对话结构”，但把超过一定轮数的消息做摘要压缩。长期记忆的写入也有讲究：不能把原始聊天记录直接丢进向量库，而是先让模型把对话里的关键信息抽取出来，格式化成类似“用户ID、属性名、属性值”的结构再入库。这样检索时可以用结构化字段做过滤，大幅降低召回噪音。
向量检索的召回数量（top_k）和相似度阈值也不是越大越好。我一般会把top_k设在3到5之间，相似度阈值设在0.2到0.3之间（按余弦相似度），太高容易漏召回，太低全是噪音。这几个值要根据业务内容反复调，没有放之四海皆准的预设。
2.3 工具层：Function Calling 是智能体的“手脚”
没有工具调用能力的智能体只是一个高级聊天机器人。工具层要解决的核心问题，是让模型在需要时能主动调用你注册的外部函数，并把返回结果纳入推理链条。
实现上，现在主流的大模型都支持Function Calling，要点是把可调用的工具用JSON Schema描述清楚，随请求一起发给模型。模型不直接执行函数，而是返回一个结构化的调用意图，由平台侧负责真正执行并回传结果。描述工具时，函数名和参数的语义要足够精确，否则模型会凭字面意思乱猜。比如一个函数叫“query_order_status”，参数里只有“order_id”，模型很可能把用户说的“我上周买的东西”这种模糊表述直接映射进来，导致查询失败。正确的做法是为参数补充别名和示例值，让模型知道“上周买的东西”应该先通过用户ID查出订单列表，再调用查询状态。
工具注册表还需要做版本管理。业务系统接口在演进，但线上智能体可能还停留在旧版本的工具定义。如果工具Schema变了而平台侧没有同步，模型会按旧格式生成调用参数，下游接口必然报错。我见过不少团队在这里翻车，最后是靠给每个工具加版本号、在部署时做兼容性检查才稳住的。
2.4 编排层：ReAct、Plan-and-Execute 还是 Graph？
编排层决定智能体怎么“思考”。三种常见的编排范式分别是ReAct、Plan-and-Execute和图编排。
ReAct是最常见的思路：让模型在“思考→调用工具→观察结果→再思考”的循环中推进任务，适合工具不多、步骤相对线性的场景。Plan-and-Execute更进一步，模型先产出整份计划，再逐步执行，适合任务链路长、需要预判的场景。图编排则是用流程图显式定义状态转移，把智能体拆成节点和边，每个节点是一个具体的处理步骤，适合流程固定、需要强管控的场景，比如工单审批、订单异常处理。
我的建议是：优先从ReAct起步，因为实现成本最低、可解释性也够；当任务链路真的变长、模型开始频繁在计划之间跳来跳去时，再迁移到Plan-and-Execute或图编排。不要让编排层过早复杂化，这是很多团队把平台做成“大而全但没人用”的常见原因。
3. 从零搭一个最小可用的智能体平台：核心组件与落地步骤
3.1 最小框架：API网关 + 模型路由 + 工具注册表 + 记忆存储
抛开PPT里那些复杂的架构图，真正常用的最小可运行框架只有四个部件。
第一是API网关，负责接收外部请求、做鉴权和限流；第二是模型路由，根据请求类型、成本策略把请求分发到不同模型；第三是工具注册表，统一管理和校验所有可被智能体调用的外部函数；第四是记忆存储，用Redis管短期会话，用向量库管长期事实。四个部件之间通过一个编排核心串起来，这个核心就是我们在上一章说的ReAct循环。
这套框架里，网关和路由可以先用轻量方案代替。网关直接用FastAPI写一层中间件，路由则做成一个简单的配置表。不要一开始就上微服务和消息队列，等流量和数据量真正起来了再演进。这也是我反复跟团队强调的：平台的第一版应该是能用手推着走的自行车，而不是四轮汽车。如果不想从零造轮子，也可以直接在Dify这类开源平台上接入本地大模型，把上面四个部件交给平台托管，团队专注业务工具的接入。不想自己维护基础设施的团队，这条路最省人力。
3.2 用Python实现一个模型路由与工具调用循环
下面给出一个最小可运行的ReAct循环示例，代码只保留了核心逻辑。
# 拉取模型并启动 Ollama 服务（默认监听 11434，暴露 OpenAI 兼容接口） ollama pull qwen2.5:7b-instruct ollama serve# agent_core.py import json from openai import OpenAI # 统一使用 OpenAI 兼容的接口协议 client = OpenAI(base_url="http://localhost:11434/v1", api_key="EMPTY") TOOLS = [ { "type": "function", "function": { "name": "query_order_status", "description": "查询订单当前状态", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，例如 SO20240501" } }, "required": ["order_id"] } } } ] def run_agent(user_message: str, max_steps: int = 5): messages = [{"role": "user", "content": user_message}] for step in range(max_steps): resp = client.chat.completions.create( model="qwen2.5:7b-instruct", messages=messages, tools=TOOLS, tool_choice="auto", temperature=0.2, ) msg = resp.choices[0].message # 模型没有调用工具意图，直接返回回答 if not msg.tool_calls: return msg.content # 把模型回复追加进上下文 messages.append({ "role": "assistant", "tool_calls": [ {"id": tc.id, "type": "function", "function": {"name": tc.function.name, "arguments": tc.function.arguments}} for tc in msg.tool_calls ], }) for tc in msg.tool_calls: # 模拟执行工具，实际应调用注册表里的函数 args = json.loads(tc.function.arguments) result = {"order_status": "SHIPPED", "order_id": args["order_id"]} messages.append({ "role": "tool", "tool_call_id": tc.id, "content": json.dumps(result), }) raise TimeoutError("agent steps exceeded") if __name__ == "__main__": print(run_agent("帮我查一下 SO20240501 这个订单到哪了"))这段代码的核心逻辑是一个标准的ReAct循环：每次把用户消息和历史追加进messages，调用模型接口时带上tools定义，模型如果决定调用工具，就会返回tool_calls；平台解析参数、执行工具、把结果以role="tool"的消息回传，然后带着新上下文进入下一轮。循环终止条件是模型不再返回tool_calls，或者步骤数超过max_steps。
有几个参数值得注意。temperature设为0.2，是因为工具调度场景需要确定性，温度太高模型容易在工具选择上左右摇摆。max_steps限制在5，防止模型陷入死循环。tool_choice用auto，让模型自己判断是否需要调用工具；如果业务场景是“必须走某个工具”，可以显式指定为对应函数名。如果你在本地用Ollama启动模型，base_url指向本地的兼容接口即可，api_key用占位符EMPTY。
3.3 接入业务系统的三种方式：同步API、消息队列与事件回调
智能体不能只活在沙盒里，它必须能触达真实业务系统。常见的接入方式有三种。
第一种是同步API调用，最直接。模型调工具时平台同步请求外部服务，拿回结果再继续推理，适合查询类操作，比如查订单、查库存、查客户信息。缺点是慢，一旦外部接口超时，整个智能体响应时间就被拖长。第二种是消息队列异步调用，适合写操作，比如创建工单、发起审批。平台把工具调用包装成消息发到队列，业务系统消费后把结果写回结果表，智能体在后续轮次里通过查询主动获取结果。这种模式能避免长时间占用模型连接，但要自己处理结果对账。第三种是事件回调，适合外部系统主动通知智能体的场景，比如支付回调触发订单状态变更。实现上一般是暴露一个Webhook接口，接收事件后把事件内容写入智能体的短期记忆，再触发一次主动推理。
建议第一版尽量只用同步API，把能跑通的业务场景跑起来；异步和事件驱动等平台稳定了再补。同步调用能暴露最多的连接问题，也最容易调试。
4. 智能体开发平台中的关键参数：温度、上下文窗口、工具超时与重试策略
4.1 大模型参数：temperature、top_p、max_tokens 怎么配合
很多人在智能体场景里还是按聊天机器人习惯调参，这是第一个坑。聊天可以开高温度让回复多样，但智能体追求的是任务完成率，参数必须往确定性方向压。
temperature控制在0到0.3之间，优先从0.2起步。top_p可以保持默认或与temperature联动下调，一般不建议同时把两者都压到极低，会大幅降低输出质量。max_tokens要按工具返回体量预留余量：如果工具结果可能很长，而max_tokens设小了，模型回复会被截断，JSON解析失败。一个经验值是按“历史上下文加工具返回加模型回复”的三倍估算，宁可多预留。
还有frequency_penalty和presence_penalty，在智能体场景里建议设成0或接近0。这两个参数设计的初衷是减少重复、鼓励发散，放在工具调度里只会让模型输出不稳定。记住一个原则：智能体平台的模型参数，目标不是“有趣”，而是“可复现地完成任务”。
参数配置有个推荐做法：把不同场景的参数组合做成配置模板，每个智能体实例引用一个模板，而不是在代码里到处写死。这样调整参数不用动代码，灰度验证也方便。比如客服场景用一套模板，工单处理用另一套，每套模板独立调优，互不干扰。
注意：模型升级后，原来调好的参数很可能不再适用。每次更换模型版本，都要重新在评估集上跑一遍参数组合，不要沿用旧参数想当然。
4.2 工具调用的超时、重试与并发控制
工具调用是智能体生产事故的高发区。外部接口慢、超时、返回异常，都会让整个智能体卡住或答非所问。
超时设置上，不同工具要分开配置。查询类工具可以给3秒到5秒的超时；写操作或涉及人工审批的工具，可以放宽到15秒甚至30秒。不要给所有工具设同一个超时阈值，否则慢工具频繁超时、快工具白白等待。
重试策略要区分错误类型。网络抖动导致的连接错误可以重试2到3次，采用指数退避；业务逻辑错误（比如参数校验失败）重试多少次都没用，应该直接返回错误信息给模型，让模型调整参数或向用户澄清。这里很多团队会犯一个错误：把所有异常都交给重试，结果外部系统被反复打，形成雪崩。
并发控制同样关键。如果外部接口有QPS限制，平台侧要为每个工具配一个信号量或令牌桶。常见做法是给每个工具定义max_concurrent参数，超过后新的调用排队等待，而不是直接拒绝。这样既保护了外部服务，也保住了用户体验。
4.3 记忆上下文的裁剪策略：窗口不够时怎么办
上下文窗口是智能体平台最硬的资源约束。即使模型支持很长的上下文，每次请求携带的token数也直接决定成本和延迟。
裁剪策略按优先级有三层。第一层是丢弃最早的非关键消息，比如问候语、寒暄、无关的闲聊。第二层是摘要压缩，把超过一定轮数的对话用模型生成一段结构化摘要，替换掉原始消息。第三层是长期记忆外置，把已经沉淀为事实的内容写进向量库，上下文里只保留引用ID，需要时再检索回来。
实现时要注意，摘要压缩本身也要消耗token。一个经验做法是：只有当对话轮数超过阈值（比如10轮）且累计token接近窗口上限的60%时才触发压缩。压缩后的摘要要保留“用户目标、已执行动作、当前状态、待办事项”四个字段，否则下一轮模型会丢失关键任务状态。
还有一个容易忽略的细节：工具调用产生的中间结果也会占用上下文。在ReAct循环里，模型每次调用工具后，工具返回的结果都会被放回上下文。如果某个工具返回特别大的数据，建议在代码层做截断，只保留关键字段，而不是把完整响应塞给模型。这一步对控制上下文膨胀非常有效。
5. 智能体开发平台踩坑手记：常见问题与排查路径
5.1 现象：模型“乱叫工具”
现象：智能体在用户问一句“你好”时，就主动去调用查询订单的工具，返回一堆无意义数据。
原因：系统提示词里没有约束“何时使用工具”。模型把“自动调用工具”理解成了“每次都调用”，尤其是用tool_choice为auto时更容易这样。
解决：在系统提示词里明确写清工具的触发条件，同时在代码侧用业务规则做前置过滤。比如只有当用户消息里匹配到“订单”“发货”等关键词时，才把工具列表传给模型；否则只走普通对话路径。这条血泪经验告诉我们：给模型的边界约束，越具体越好。
5.2 现象：智能体答非所问
现象：用户问“我上次的退款处理到哪一步了”，智能体却开始介绍退款政策，答非所问。
原因：长期记忆的向量检索把“退款政策”和“退款进度”混为一谈，召回了政策文档片段，没有召回用户的退款工单记录。
解决：把用户事实按业务实体建模，不要只存对话文本。退款进度应该存成“用户张三，退款单号R20240001，状态复核中”这样的结构化记录，检索时先用结构化字段过滤用户，再做语义检索。另外把召回top_k从5降到3，并加上相似度阈值0.3，过滤掉边缘结果。
5.3 现象：工具调用超时
现象：某个查询服务依赖的数据库慢查询，单次查询从2秒涨到20秒，智能体所有请求都卡住，前端大量超时。
原因：平台侧工具调用没有超时熔断，服务变慢后请求全部堆积在等待队列里。
解决：为每个工具配置独立的超时时间和最大并发数，超时直接返回“工具执行超时”给模型，让模型给出降级回答（比如“系统繁忙，请稍后再试”）。排查链路要从外部服务监控入手，先看慢查询SQL和连接池，再回头调整平台侧熔断参数。没有熔断的平台，流量一大就是雪崩，这不是危言耸听。
5.4 现象：多轮对话上下文爆炸
现象：智能体在30轮对话后，单次请求的token数从3千涨到3万，响应延迟翻倍，成本飙升。
原因：短期记忆窗口只追加不裁剪，30轮对话的原始消息和每轮工具调用结果全部堆积在上下文里。
解决：按第4章的压缩策略，对话超过10轮且token占用超过窗口的60%时，触发摘要压缩。这里要特别提醒，工具调用的中间结果要单独归类，不能和用户消息混在一起裁剪。我见过一个项目把工具返回截断后，模型下一轮就找不到订单号了，就是因为压缩策略把“当前任务的参数”当成了历史消息裁掉了。
5.5 现象：本地大模型接口和云端模型不兼容
现象：同一套代码在云端模型上正常运行，切到本地部署模型后，工具调用频繁报错，或返回格式不符。
原因：本地模型对Function Calling的支持程度不一，有的模型工具格式是厂商私有协议，有的对JSON Schema校验不严格，系统提示词的格式要求也不一样。
解决：统一接口层的适配。常见做法是在平台内部做一个“模型适配器”，把云端模型的函数定义转成本地模型能识别的格式。切换到新的本地模型时，先在离线评测集上跑工具调用用例，确认返回格式稳定后再灰度放量。如果某个本地模型对工具调用的支持太差，别硬扛，换一个函数调用能力强的开源模型，省下来的时间足够你多做几轮业务迭代。
6. 把智能体平台推向生产：验证方法、可观测性与一个值得养成的习惯
6.1 用 Pytest 给智能体写“行为回归测试”
智能体不像普通函数那样输入输出一一对应，它的行为是多步推演的结果。因此测试不能只看最终回答，要看中间的工具调用序列。常见做法是把一组业务场景固化成测试用例，断言每一步的工具名称、参数和最终回答的关键字段。
# test_agent.py from agent_core import run_agent def test_order_query_flow(): result = run_agent("查一下单号 SO20240501 的物流状态") assert "query_order_status" in result.tool_trace assert result.tool_params["order_id"] == "SO20240501" assert "运输中" in result.final_answer这样的回归测试，能在模型升级或系统提示词调整时快速暴露行为漂移。我的经验是每新增一个业务场景，就先补一个这样的测试用例，把测试集当成智能体行为规范来维护。
6.2 可观测性：链路追踪与 token 成本核算
智能体平台比普通接口更需要可观测性。每一个请求会经历“模型推理→工具调用→再推理”多个阶段，任何一个环节出问题，用户感知到的都是“回答奇怪”。所以从第一版开始，就要为每个请求生成一个trace_id，记录模型调用耗时、token消耗、工具调用列表、每步延迟和错误信息。
成本核算也是容易被忽略的点。按模型单价乘以每次请求的总token数，按月汇总，你会发现智能体平台的成本大头往往集中在“多轮对话加频繁工具调用”的长任务上。有了成本数据，你才有依据去优化上下文压缩策略、调整模型路由规则。
6.3 一个值得养成的习惯：先定评估集，再动代码
我在智能体平台上最大的教训，是“没有评估集就改Prompt等于盲改”。你改了一次系统提示词，凭感觉觉得效果好了一点，但没有量化指标，两周后你根本说不清哪次改动真正有效。
所以现在的习惯是：每次业务改版，先把涉及的业务场景扩充进评估集，跑一遍基线，记录工具调用准确率和任务完成率；改完代码或Prompt后再跑同一套评估集，对比差异。这个过程可能只花半小时，但它能让你从“玄学调参”变成“有据可依”。
这套方法说起来简单，坚持下来不容易。但正是这个习惯，帮我避开了好几次“看起来在进步、实际在退步”的陷阱。如果你也要推智能体平台，建议从今天起就把评估集建起来，哪怕只有10个用例，也比没有强。希望帮到你。
本文还有配套的精品资源，点击获取
