资源介绍
视频数量：35个
总时长：1小时41分
课程介绍：
智能体架构设计：让智能体可控、可测、可信赖
客户发来一句：“包裹还没到，我要退款。”几秒后，智能体可能查错订单，甚至把订单备注里的恶意文字当成命令。界面看上去很聪明，业务却已经失控。很多智能体演示停在这一幕，而真正决定系统能否投入使用的，恰恰是演示之后：它如何调用工具，出了错怎样恢复，谁来批准敏感操作，又如何证明每次回答都可靠。
这节课不只讲提示词。你会从零搭建一家在线书店的客服系统，让它读取工单、查询订单、核对退款政策并生成回复。全部代码都用 Python 写成，三十五段视频共约一百零一分钟。每种架构都有可运行程序、测试和运行记录。课堂结果实时执行：能看到每次模型调用、工具调用、耗时与费用，也能看到订单号写错、服务超时或政策冲突时，系统怎样继续工作。
一、先分清工作流与智能体：
如果步骤固定，交给可预测的工作流；如果现场情况决定下一步，才让智能体参与。课程从“谁决定下一步”讲起，再把大模型放在工具、知识与记忆之间，解释它为何既是推理核心，又不是整个系统。这个视角能破除一个常见误区：给模型接上几个函数，并不等于完成了智能体设计。
二、从手工循环看清智能体如何运转：
先不用框架隐藏细节，自己实现模型、工具与结果之间的循环，完成一次真实客服任务；再用软件开发工具包的内置循环重写同一逻辑，观察两者差别。最大轮数、费用预算和最终答案生成会分别讲透。理解这些边界后，模型陷入重复调用、持续烧钱或迟迟不给结论时，你才知道该在哪里刹车。
三、把工具设计成模型真正能用的接口：
工具不是零散函数，而是一份可验证的契约。先看参数模式怎样限制输入，再把异常改造成可读的错误结果。订单号格式不对时，工具应告诉模型正确格式和下一步该查什么，而不是抛出含糊异常。工具拆得太细会制造多次往返和选择错误，合成一个大工具又会失去可检查性，课程会寻找两者之间的平衡。最后区分读工具与写工具，让查询和退款这类状态变更走不同路径，为审批留下边界。
四、用工作流模式换取稳定性：
提示链通过关卡逐步检查中间结果，路由模式依据结构化输出把工单分给合适路径，并实际处理十二张不同工单。并行模式把任务拆成可独立执行的片段，再汇总或投票。这里不会把模式当成固定答案，而会说明何时该链式调用，何时该路由，何时并行才有价值。业务步骤越确定，越应该让普通代码承担更多控制权。
五、多智能体不是越多越好：
编排者与工作器适合把复杂任务拆开，子智能体能在隔离上下文中专门研究政策，避免大量材料挤占主对话。评估者与优化者形成“生成、批评、修改”的闭环，用来提高答案质量。课程也会把多智能体的真实代价摊开计算，包括更多调用、延迟、费用和协调复杂度。学完这部分，你会根据任务边界决定是否需要多个角色，而不是看到复杂问题就拆出一串代理。
六、让状态与记忆各归其位：
上下文窗口只是当前会话的工作记忆，不该被当成永久数据库。课程会实现会话恢复与分叉，让对话能够延续，也能从某个节点尝试另一条路径；外部记忆保存跨会话仍需保留的信息和笔记。检索工具与预先装入上下文也会放在一起比较：什么时候按需查资料，什么时候预先准备背景，可以依据任务时效性、信息量和上下文成本来决定。
七、为智能体加上护栏与人工判断：
最小权限原则先限制智能体能接触的工具和数据范围，高风险写操作进入人工审批。钩子机制负责执行政策并留下审计记录，出了问题可以还原动作链。课程还会模拟一种隐蔽攻击：恶意指令藏在工具返回结果中，诱导智能体跳过流程。面对提示注入，真正的防线不是一句提醒，而是权限隔离、结果校验、审批关卡和可追溯操作。
八、用评估和运行数据支撑迭代：
评估不是看几个示例觉得回答顺眼，而是建立固定测试集，用确定性评分器检查查单、政策判断、工具选择和拒绝行为。运行整套评估后，再通过追踪记录分析每个任务的调用次数与成本。重复循环、错误恢复、上下文污染、无限递归和策略越权等故障模式会逐个拆解。最后得到一张架构检查清单，设计新智能体时可以逐项核对，而不是凭感觉拼装组件。
这套内容适合已经掌握基础 Python、调用过大模型接口，并准备把原型做成实际系统的开发者。后端工程师、机器学习工程师、自动化产品开发者，以及需要判断智能体方案是否可靠的技术负责人，都能在其中找到依据。配套项目包含智能体循环、编排、路由、并行、子代理、会话、记忆、检索、审批、护栏、评估和追踪，适合边看边改，也能作为团队讨论架构的参照。
学完后，你能解释智能体为什么这样行动：工具失败时如何恢复，任务该不该拆分，状态存在哪里，谁有权执行敏感操作，以及如何用测试和成本数据证明系统确实变好了。更实际的变化是，你会在动手之前先问清业务边界，把那些看似聪明的自由度，转换成可观察、可控制、可追责的工程设计。