正文
学习了某项技术以后，很容易希望尽快用起来。但应用最终要解决的是用户的问题。系统能否完成任务、结果怎样核实、等待多久、需要多少维护，都比它采用了多少新组件更值得关心。
这一篇继续用会议通知的任务来判断。假设一个团队希望减少整理会议资料、撰写通知和保存草稿的重复工作。需求听起来相似，实际需要的实现方式却可能不同。
先看最明确的一种情况。系统已经拿到会议名称、日期、时间和地点，只需要把这些字段填入固定格式，保存到指定目录。普通程序就能把字段放进模板，并检查必要信息有没有缺失。
这样的任务可以直接从软件逻辑入手。时间格式不对，就检查格式；缺少地点，就提示补充。让模型在每一步重新判断，可能增加等待和出错机会，却未必带来用户需要的改进。
再稍微改变要求。用户提供了一段比较零散的会议说明，希望把它整理成语气自然的通知。这里涉及语言理解和改写，使用语言模型就可能有帮助。
应用可以把原文与写作要求交给模型，得到正文，再由程序保存文件。模型主要负责内容处理，执行路径仍然清楚。只要这样的安排已经满足需求，就不必为了这个任务，另外设计一个能不断选择工具的循环。
接着，用户希望系统自己去查日历，但已经明确指定会议编号。程序能够读取对应记录，取出日期、时间和地点，再交给模型组织通知，最后保存。对于这条稳定路径，固定工作流仍然是一种自然选择。
在常见工程区分中，工作流的主要路径由程序预先安排，Agent 则允许模型根据任务和中间结果动态参与后续过程。二者可以使用同一个模型，也都可以调用工具。工作流与 Agent 的控制方式
真正让问题发生变化的，是下一步难以提前确定。
假设用户只说“把下一次客户项目例会整理成通知”。日历中有几场名称相近的会议，有的只有简称，有的发生过改期，还有一条记录缺少地点。为了完成任务，系统可能需要调整查询范围，读取不同记录，比较项目与参与人，必要时再询问用户。
这时，开发者很难预先写出适用于所有情况的唯一执行顺序。模型能够根据当前结果选择后续动作，就可能提供实际价值：先查什么、证据不够时补充什么、什么时候需要澄清，都可以随任务进展调整。
不过，“情况会变化”也不能单独证明必须使用 Agent。如果变化只有两三种明确情形，普通的条件分支就可能足够。需要看的是，动态判断能否显著改善这项任务，而不是输入里是否出现了不确定性。
一种稳妥的开发思路，是先实现能够满足要求的简单方案，再根据实际问题增加复杂度。相关工程经验也建议从简单、可组合的模式开始，并评估自主处理带来的时延与费用代价。选择适当的 Agent 复杂度
有些问题，则需要先补足基础条件。
如果应用根本无法访问项目日历，模型反复安排查询也拿不到资料；如果会议名称长期混乱，参与人信息也缺失，换成多个 Agent 并不会自动产生可靠依据。
此时，接入正确数据源、整理会议标识，或者请用户提供少量关键信息，可能比增加决策循环更有效。系统遇到的困难，需要先判断来自数据、工具、权限、模型能力，还是执行组织方式。
任务目标也应当足够明确。“帮我处理好所有会议”很难直接判断完成与否；“找到下一次指定项目例会，核实所需信息，并保存通知草稿”，就能够对应具体结果。
这个结果还能成为后续比较方案的依据。我们可以检查会议是否选对，通知中的日期与地点是否有来源，文件是否确实存在，以及系统有没有执行用户未要求的操作。
这些检查会影响 Agent 是否适合投入使用。一个系统即使能连续调用很多工具，如果最终结果难以核实，开发者也很难知道它是在有效推进任务，还是只是输出了完整的执行叙述。
评估资料中会区分执行记录与环境里的最终结果。对于会议通知，最后一句“草稿已保存”属于输出；指定位置是否真的出现正确文件，才属于需要核实的结果。任务执行记录与最终结果的区别
因此，判断方案时，可以准备一组有代表性的会议任务，其中既包括信息齐全的情况，也包括同名会议、记录缺失和查询失败等情况。这里是在说明一种比较方式，并没有声称某个应用已经完成这些测试。
让简单工作流与 Agent 处理相同的任务，再比较结果，才有机会看清动态决策解决了哪些问题。只展示一次顺利完成的演示，难以说明遇到不同输入后是否仍然可靠。
比较也不能只看成功与失败。系统用了多少时间、调用了哪些服务、消耗多少费用、需要人回答多少次、失败后能否继续，都影响实际价值。
例如，Agent 多查询几条记录，可能避免选错会议；如果它没有取得新信息，却不断重复相同查询，这些额外动作就增加了等待与开销。相反，一条很长的固定流程也可能浪费操作，所以“固定”本身不等于便宜，仍然需要实际测量。
人的时间也应当算进去。模型调用费用不高，但每次都把简单问题转交用户，可能让整个任务比手工处理更慢。自动完成比例看起来很高，却需要开发者频繁排查故障，也同样存在维护成本。
这就进一步涉及复杂度。
每加入一个组件，系统就多一项需要理解和维护的关系。外部工具可能改接口，模型版本可能改变输出方式，状态记录可能与真实文件不一致。组件越多，排查问题时需要检查的连接通常也越多。
假设原本一个 Agent 就能完成会议查询和草稿整理，再添加专门查询、撰写与审核的多个 Agent，并不会自动提高质量。开发者还需要处理任务交接、信息共享、意见冲突和结束条件。
只有当这些安排确实解决了单个系统的限制，并且收益能够通过评价体现出来，额外的协作才值得承担。学习目录列出了多 Agent、长期记忆和微调，是为了认识可选能力，并不要求每个应用都装上这些部分。
使用框架也是类似的选择。现成组件可能减少重复开发，也可能让问题被藏在多层接口后面。适合的做法，是了解当前方案实际需要哪些能力，再判断框架提供的部分是否合用，以及将来升级和迁移要付出什么代价。
Agent 与工作流也可以组合。在会议任务中，文件保存、路径检查和权限控制可以保持明确规则；会议记录存在歧义时，让模型参与查找与判断。用户确认以后，再进入受约束的后续执行。
这样的组合允许灵活性出现在确实需要的地方，同时让能够确定的环节保持清楚。自主程度也可以受到范围和预算限制，而不必把整项任务的所有选择都交给模型。
对初学者来说，可以先选择一个范围小、资料可获得、结果能检查的任务，把从输入到交付的过程做完整。模型可以通过托管接口使用，也可以按条件部署在本地；是否需要自己训练模型，是另外一个问题。
回到最初的会议通知任务，合适的方案可能是一段普通程序、一次模型调用、一条工作流，也可能包含 Agent。最终选择应当与问题相匹配，并能够用实际结果解释它带来了什么改进。
到这里，01 模块完成了对 Agent 全貌与边界的初步认识。接下来进入编程基础，从 Python 开始学习怎样表达数据、组织处理过程，并把模型与工具真正接起来。后面的各个分支，还会继续展开原理与实现细节。
当前学习编号：01.12 Agent 的适用条件与复杂度取舍。
下一学习编号：02.01 Python 编程。后续还有其他学习编号。
关联分支：选择实现方式对应 01.07 工作流与自主 Agent 的区别、12.01 模型能力与任务匹配、20.01 单 Agent 与多 Agent 的取舍、26.08 框架、平台与直接 API 的取舍。
比较实际效果对应 23.02 任务成功标准与评测集、23.09 工具选择、参数与执行正确性、23.13 重复试验、稳定性与置信区间、23.17 时延、吞吐、成本与质量权衡；维护对应 26.09 模型、数据、提示词和工具版本协同、26.13 供应商迁移、维护成本与退出方案。这些支系会在各自编号中单独展开。