最小单位：增强过的模型
先想一个具体任务：“找到预约系统最新的取消规则，并告诉我明早那一场还能不能取消。”一次检索（retrieval）就够，还是需要查看版本、补查例外、再问用户准确时间？区别不在于用了几个模型，而在于下一步由谁决定。
模型可以接检索、工具和记忆，但不是每个 agent 都必须把三样装齐。工作流（workflow）通常由代码规定路径；agent 则让模型根据执行反馈选择下一步。这个区分方便设计，不是给所有产品盖章的唯一定义。Building effective agents
五种 workflow 和一种 agent
| 结构 | 怎么做 | 什么时候用 |
|---|---|---|
| Prompt chaining | 把任务拆成固定的几步，上一步的输出就是下一步的输入，中间可以加检查 | 步骤清楚，愿意拿一点延迟换准确 |
| Routing | 先分类，再交给专门的处理路径 | 输入类型差别大，分开处理更好 |
| Parallelization | 拆成独立的子任务同时做（sectioning），或同一件事做几遍再投票（voting） | 子任务互不依赖，或想要更稳的结果 |
| Orchestrator-workers | 一个模型现场拆任务、分给 worker、再汇总 | 子任务事先列不出来，比如要动哪些文件得看需求 |
| Evaluator-optimizer | 一个模型生成，另一个评价并给反馈，循环改进 | 有清楚的评价标准，而且反馈确实能让结果变好 |
| Agent | 模型在循环里自己决定每一步，看着环境反馈判断进展，直到满足停止条件 | 开放式任务，走几步、怎么走事先都不知道 |
这些不是从低级到高级的排行榜，也可以组合。一个固定工作流可能并发调用很多模型，比一个只查一次资料的 agent 更贵；要看实际执行了什么。
表里的 voting 和 evaluator-optimizer，在推理模型那边叫测试时计算：同一题多采几份再投票，或让验证器挑一份。多花的计算什么时候值得，见采样、投票与验证器。
看一遍执行过程，比记结构名有用
继续用预约规则的例子。下面是给开发者看的行动记录，不要求模型公开一长串内部推理：
| 步骤 | 模型提出的动作 | 程序负责什么 | 得到的反馈 |
|---|---|---|---|
| 1 | 搜索取消规则 | 检查搜索参数和用户权限 | 返回两份不同版本的通知 |
| 2 | 打开生效时间（effective time）较新的通知 | 读取允许访问的原文，保留位置 | 发现“提前 24 小时”及场地关闭例外 |
| 3 | 询问准确预约时间 | 暂停执行，不编造缺失信息 | 等用户回答 |
| 4 | 引用适用规则作答 | 检查来源与时间计算 | 给出结论或仍需确认的事项 |
ReAct的关键是把推理、行动和环境观察交替起来，不要求一台“推理模型”配一台“生成模型”。工具超时是环境反馈，不是“规则不存在”；重试也要有限次，否则循环只是反复花钱。
Function calling 和 MCP 分别做什么？
模型的工具调用输出只是提出工具名和参数，生成了参数也不代表有执行权限；应用里的执行器负责校验、实际调用，并且不把工具返回的文字当成系统指令；MCP 是连接外部工具的协议层，不替你决定计划、权限或答案对不对。三者的分工在工具、MCP 与 Skills里用同一个例子列成了表。
只读搜索与取消预约也不是同一种风险。前者主要担心取错资料，后者会改变外部状态。真要提供取消工具，应在执行前确认，并用幂等键避免超时重试导致重复操作。记住某段历史不等于有权执行里面提到的动作。
要看完整的小例子，接着读工具、MCP 与 Skills：从“只检查，不修改”的请求出发，区分任务说明、工具协议和执行权限。
Deep Research 多做的不是“写长一点”
把问题换成“这几份预约政策怎么变过，哪些例外还有效”，一次检索可能不够。系统需要保留待查问题，补搜缺失证据，比较冲突，再写结论。可以用下面这张小表记录进展：
| 待核实的问题 | 现有证据 | 下一步 |
|---|---|---|
| 24 小时规则何时生效？ | 一份带日期的正式通知 | 核对是否有后续修订 |
| 关闭场地是否例外？ | 当前规则中的明确条款 | 保留条款位置，不只保存摘要 |
| 某个预约适用哪一版？ | 还缺预约日期 | 问用户，不继续猜 |
什么时候能并行、转载为什么不算独立证据、预算用尽时怎样说清没查到什么，以及问题队列、证据记录和可运行的引用检查，都在 Deep Research 专篇里；那里的局部测试只检查代码逻辑，不代表真实模型的效果。
怎么选
- 先试一次调用，配上好的 prompt 和检索，很多问题到这一步就解决了；
- 能写成 workflow 就写成 workflow：每一步可以单独测、单独改；
- 实在没法把路径定下来，再换成 agent，同时给它明确的停止条件和预算。
框架还是直接调 API
可以先用少量直接调用把任务跑通，理解状态和失败路径，再决定是否需要框架的持久化、恢复和追踪能力。框架能省掉不少工程工作，但也要能查看实际输入、工具参数和执行结果。
不要只测试“正常时能答出来”。至少模拟一次工具超时、无权限、冲突来源、达到步数上限，以及写操作执行成功却丢失响应。能在这些情况下停止或恢复，比多画几个 agent 方框更重要。
本页术语 2
- 检索 retrieval
- 从外部语料里找出相关内容
- 生效时间 effective time
- 某一版本的数据或属性从什么时候开始对外有效