切换深色模式
视频导读：从工具调用到 Agent 协作
参考视频：今天不coding · 大模型应用开发知识概述，发布于 2026-07-31，时长 32:38。作者账号与用户提供的 UID 443011857 一致。
本篇依据该视频完整的自动中文字幕整理，聚焦 Agent 相关部分，不代表已观看该账号全部视频。自动字幕有术语误识别，本文统一使用 Function Call、MCP、Skills、ReAct 等常用拼写；未逐帧核对演示代码，不提供其代码可运行性的保证。只保留概要和原视频定位，不转载完整字幕、课件或付费 PDF。核对日期：2026-09-06。
一、先建立整体认识
视频从大模型能力局限讲起，再依次介绍外部工具、任务规程、知识检索和智能体。对学习者最有用的主线是：模型负责生成决策，应用负责把决策接到真实环境，并处理反馈。
下面的分工表是本站结合现有专题所作的工程归纳，不是视频原图：
| 组成 | 解决的问题 | 研究助手中的例子 |
|---|---|---|
| 模型 | 当前应该回答、查询还是澄清 | 判断是否缺少故障恢复资料 |
| Function Call | 如何表达工具名与参数 | 请求 search_notes |
| MCP | 应用如何以统一协议连接能力 | 对接笔记检索服务 |
| Skills | 某类任务应该按什么规程做 | 查来源、区分事实与建议、检查引用 |
| RAG | 如何把外部知识带入生成过程 | 检索并读取指定版本的笔记 |
| 状态与记忆 | 哪些进展需要跨轮次保留 | 已读证据、待解决问题、用户约束 |
| Agent 循环 | 如何根据反馈持续推进 | 查询失败后换策略，证据不足时停止 |
这些组件不是必须全部安装的清单。只总结用户已经提供的一段文字，通常不需要检索；单次任务也不一定需要跨会话长期记忆。选型先看任务需要，再决定组件。工程模式参考。
二、视频时间导航
时间按字幕中话题开始处取整，可作为回看定位，播放器实际跳转可能略有偏差。
| 开始时间 | 视频讨论内容 | 对应本站章节 |
|---|---|---|
| 05:26 | 工具定义、应用执行、结果回传 | 工具契约 |
| 07:30 | MCP 连接、工具发现与调用、传输方式 | 工具与 MCP |
| 12:22 | Skills 目录与渐进式加载 | Skills |
| 15:21 | RAG 入库、检索与生成 | 上下文与 RAG |
| 21:33 | 检索材料、答案与问题之间的评估 | 评估 |
| 25:57 | Agent 的记忆、工具、规划与行动 | 基础与循环 |
| 26:51 | ReAct 与 Plan-and-Execute | 编排 |
| 28:16 | Reflection 与人工介入 | 编排与可靠性 |
| 29:15 | 主子、交接、群聊及 A2A | 多 Agent |
三、Agent 部分的核心要点
以下为视频相关段落的压缩概括；后文的实施规则是本站补充。
1. 工具让回答连接到行动
视频强调：模型返回工具请求，真正执行的是调用端；执行结果交回模型后，还可能触发下一次调用。因此，工具调用不是“模型直接运行函数”，也不必止于一轮。05:26 起。
2. 规划、反馈与检查可以组合
视频用 ReAct 解释下一步决策、行动和观察的循环；用 Plan-and-Execute 解释先形成总体计划再执行；随后引入 Reflection 检查结果，以及人工审批后的恢复。26:51 起。
3. 多 Agent 需要明确控制关系
视频列举了把子 Agent 当作工具调用、把处理责任交给另一 Agent，以及由管理器选择发言者的群聊模式，并介绍 A2A 的任务与产物概念。29:15 起。
四、落到研究助手：怎样选择架构
下面是本站原创方案推演，不是对视频代码的复现。
ReAct：先探索，再根据结果调整
用户问“哪种延时任务方案适合我们”，但没有指出资料位置。助手先搜索，再根据返回的文档决定读什么。读到概念介绍后，发现没有故障恢复信息，于是补查。每一步都以真实工具结果更新状态。
适合路径尚不清楚的探索任务。需要限制重复查询、轮数和总时限；否则“继续思考”可能退化成循环搜索。验收的对象是证据是否增加，而不是思考文字是否变长。
Plan-and-Execute：先统一比较维度
面对“三类方案的完整比较”，先列出触发机制、允许延迟、恢复方式和重复执行风险，再为每个维度收集证据。执行者内部仍然可以采用 ReAct；发现某类资料不存在时，规划器应更新计划，而不是把原计划强行做完。
计划条目建议包含 目标、依赖、证据要求、状态、修订号。是否更快取决于总调用量、执行结构和重试，不能仅凭“有规划步骤”断言一定更慢，也不能保证规划一定正确。
Reflection：检查要有外部标准
让检查器逐项核对“结论是否由原文支持、是否混用了版本、是否遗漏限定条件”。如果答案声称某方案具备指定吞吐能力，而证据只介绍原理，应删除该数值判断或补充可核验资料。
设置明确退出条件：通过验收、达到修订上限、没有新增证据或需要用户输入。单纯让生成模型再说一次“我检查过了”不能独立证明正确。带反馈的改进循环应以清晰标准和可测收益为前提。官方工程讨论。
Human-in-the-loop：把审批绑定到具体操作
假设将来允许助手发布文章，审批不应只问“是否继续”，而要展示发布目标、内容版本和影响范围。批准的是这一次确定的操作；内容改了或目标变了，就不能沿用旧批准。
text
生成候选操作 → 保存待审批状态 → 展示目标与内容
├─ 拒绝 → 结束或修改
└─ 批准 → 核对操作版本与权限 → 执行 → 记录结果恢复时还要考虑重放。例如 LangGraph 中断所在节点可能从头重新运行，中断前的副作用应设计成幂等或拆分处理。中断恢复规则。当前本站示例只有暂停返回值，没有实现持久化审批与恢复。
多 Agent：先保证交接可检查
将三类方案分别交给研究者，统一返回“结论、来源、适用条件、未解决项”；最终报告由一个汇总者写入。群聊模式同样要限制回合、确定主持者和停止标准，不能用讨论热烈代替证据完整。
如果各任务高度依赖彼此的中间状态，拆分可能增加传递与合并成本。先保留单 Agent 基线，再用相同问题、资料快照和预算比较。实现细节继续阅读工作流与多 Agent。
五、听课时需要校正的 MCP 边界
视频的口语化类比有助于入门，但以下几处不能直接作为实现规范。这里按本站明确采用的 MCP 2025-11-25 版本核对，不声称它是最新版本。
| 容易形成的理解 | 更准确的表述 |
|---|---|
| Function Call 在本地，MCP 在远程 | 前者描述模型请求工具的机制，后者描述应用连接能力的协议；本地或远程不是本质区别 |
| stdio 是同一进程内调用 | 标准 stdio 方式通常由客户端启动服务端子进程，通过标准输入输出通信 |
| JSON-RPC 意味着 MCP 必须无状态 | 该版本的 Streamable HTTP 可建立有状态会话，使用会话 ID；会话状态也不等于 Agent 长期记忆 |
| 新旧 HTTP 传输的区别是一个端口和两个端口 | 关键是端点及消息交互方式，不是 TCP 端口数量；Streamable HTTP 使用统一 MCP 端点，也可以使用 SSE |
这些区别依据传输规范。
视频约 12 分钟处关于鉴权的讲解，也应区分“演示未配置”和“协议没有规范”：MCP 有针对 HTTP 场景的授权规范，是否采用及业务资源权限仍需应用正确实现。单加一个 Token 拦截器不等于完成了协议授权与逐资源访问控制。授权规范。
六、把视频变成自己的学习成果
建议完成三个小练习，而不是只记住模式名称：
- 用一条实际执行轨迹，标出模型请求、参数检查、权限检查、工具结果和最终验收。
- 为同一个研究问题分别写出 ReAct 与先规划再执行的方案，列出各自可能浪费调用的位置。
- 设计一个“引用合法但结论无依据”的反例，以及一次审批后内容发生变化的反例，说明运行时如何阻止错误完成。
可从离线实践开始：它能验证部分执行边界，但没有真实模型、完整 RAG、多 Agent 或审批服务。以上扩展是学习设计，不是本站新增的在线能力。
返回 Agent 专题目录。