正文
仍然用会议通知的任务来理解。用户说：
查询下一次项目例会，核实日期、时间和地点，再把通知保存到“会议草稿”文件夹。
如果系统每查一条记录、每读一次详情、每修改一句措辞，都要求用户点一次同意，用户很难把这项任务交出去。如果它查完日历就擅自改动会议，并把通知发给所有联系人，又超出了这次要求。
怎样让系统顺利完成已交给它的工作，同时让人保留必要的决定权，就是自主程度与人工参与边界的问题。
这里所说的自主程度，可以先理解为：在已经明确的目标和允许范围内，系统能够自行选择并执行多少事情，以及遇到哪些情况需要人的参与。
它涉及许多具体选择。模型能否自行调整查询关键词，是否可以决定采用哪条记录，能否修改已有文件，什么时候必须暂停，这些选择可以分别设计，不能只用一个“全自动”按钮概括。
在会议任务中，用户已经授权查询并保存草稿。应用可以允许系统自行查找记录、读取详情、生成通知和核对保存结果。在这些操作符合约定范围时，不必为了表示“有人监督”，反复要求用户批准同一件事。
但“可以查询日历”也不等于“可以处理日历里所有事情”。读取项目例会，与修改同事的私人安排，是不同的操作。一个工具账户在技术上拥有某项能力，也不等于用户在当前任务中已经授权使用它。
理解这一点，可以把三个问题分开：工具是否做得到，系统是否被允许做，以及这次是否还有关键信息需要人提供。
例如，文件工具能够写入很多目录，程序却只允许这项任务在指定文件夹创建草稿；模型知道怎样调用发送接口，但用户没有要求发送通知，任务就不应因此扩展。这些边界需要应用落实到工具与参数检查中。
实际开发设施可以支持自动允许、拒绝以及运行时询问等不同处理方式。具体采用哪一种，取决于工具、操作参数和应用规则，不需要把每一次工具调用都转成一次人工审批。工具使用的权限控制
自主程度也与信息是否足够有关。
假设日历里出现两场同名项目例会。一场属于用户正在讨论的项目，另一场属于其他团队。如果参与人和项目名称足以区分，系统可以继续核对，选择有依据的那场会议。不能仅因存在两条结果，就机械地把所有判断推回给用户。
如果现有信息无法区分，继续猜测就可能写错通知。这时系统可以问：“你指的是产品组例会，还是客户项目例会？”这个问题是在取得缺失信息，属于澄清，不是询问用户是否允许查询日历。
两类问题看起来都要等待用户回答，作用却不同。澄清帮助确定目标；审批则是在某个操作发生前，确认是否允许执行。文章里把二者分清，才能理解系统为什么停下来。
人工参与还可以发生在结果已经准备好的时候。
如果用户只是要求保存草稿，系统可以在核实保存成功后交付文件，让用户随后阅读和编辑。这里通常不需要为了一个尚未提出的发送动作，额外追问“现在是否发送”。做好当前任务，就已经满足要求。
假设用户后来补充：“通知写好后先让我看，确认后再发给项目组。”这就增加了一道明确的人工检查环节。系统可以先完成查询、改写和草稿准备，再把准备发送的内容与接收范围展示给用户，在获得对应授权后继续。
这样的审批应当有具体对象。用户需要看到将采取的操作、相关内容、接收人和必要依据，才能判断是否合适。只弹出一个没有上下文的“是否继续”，并没有充分支持人的判断。
如果用户先前已经明确授权某种条件下的操作，应用可以记录并执行这项约定。已有授权的范围也需要清楚：允许把这份草稿发给项目组，并不自动覆盖之后的另一份通知、另一组接收人或其他任务。
这里不要求模型独自记住所有授权细节。程序可以保存任务范围和审批状态，在执行操作时再次检查。模型负责在这些边界内选择下一步，权限检查则由相应执行设施落实。
要让人工参与真正起作用，系统还需要能够暂停并接着工作。
用户审核通知期间，程序应当保留已经查到的会议资料、草稿版本和等待事项。收到回复以后，再从相应位置继续。LangGraph 的中断机制就是一类具体实现：在需要外部输入的位置暂停，保存状态，再接收输入恢复执行。暂停、等待输入与恢复执行
暂停不意味着模型一直在后台“思考”，也不要求把一个计算过程持续占住。应用可以保存所需信息，在收到回复后发起后续处理。具体是否支持退出后恢复，则取决于实际存储与运行设计。
人给出确认以后，也可能出现新情况。比如，用户审核的是下午三点的通知，但恢复执行时发现日历已经把会议改到四点。系统就需要识别：原先审核的内容与现在准备执行的内容发生了变化。
这种情况下，要根据变化对原授权的影响处理。需要重新核实的，应当先核实；已经超出用户批准对象的，应当重新呈现具体变化。不能仅凭“这个任务之前同意过”，就把所有后续版本都视为已经认可。
人也应该能够主动打断任务。例如，用户说“先别继续，我要改会议范围”，系统需要停止安排新的相关动作，并说明已经执行了哪些事情。如果外部操作早已完成，取消后续执行也不能让那些结果自动消失。
因此，人工接管需要有可见的进展和可用的控制。用户要知道系统目前在做什么、哪些结果已有依据、哪些动作尚未发生，才能有效调整方向。把一大段原始工具日志丢给用户，往往不如清楚交代影响决定的几项事实。
另一方面，加入审批并不能代替系统自身的正确性检查。
用户可能没有时间逐项核对日期，也可能信任界面给出的摘要。如果模型读错了会议，审批页面又没有展示来源，人点了同意，错误仍然可能继续。因此，程序应当完成能够自动完成的格式、范围和结果核对，再把需要人判断的事项清楚呈现出来。
通知是否保存成功，可以查询文件结果；两场会议究竟哪一场符合用户意图，资料不足时才需要用户澄清。不同问题采用合适的处理方式，才能减少无效打扰，同时保留人的决定权。
自主范围也可以随着证据逐步调整。一个新应用可以先把较多结果交给人检查，收集任务中实际出现的错误；当某类操作表现稳定、边界明确时，再考虑允许它在相应范围内直接进行。
这种调整需要评价具体任务。一个系统在查询会议上表现可靠，不代表它已经适合独立修改所有人的安排。自主范围扩大到哪里，就需要检查相应的结果、失败方式和处理能力。人的加入也有时间成本，应当在系统评估中一并考虑。同时检查执行过程与最终结果
回到最初的任务，合理的安排可以很朴素：允许系统完成已有授权的查询与草稿保存；信息不足时说明具体疑问；操作超出范围时停止；结束后交付可检查的文件与依据。
自主程度的设计，最终落实在这些具体约定里。下一篇会继续往前问：了解了模型、工具、运行设施与人工参与以后，什么任务值得采用 Agent，又有哪些任务用更简单的方法就能完成？
当前学习编号：01.11 自主程度与人工参与边界。
下一学习编号：01.12 Agent 的适用条件与复杂度取舍。后续还有其他学习编号。
关联分支：目标与询问对应 26.01 用户任务与需求边界、26.04 澄清问题与不确定性表达；授权对应 22.05 身份认证与访问授权、22.06 最小权限与能力范围、22.07 用户意图、授权与操作审批。
人工参与的实现对应 18.13 暂停、恢复与取消、18.14 人机协同与人工接管、26.06 审批、编辑、撤销与人工接管体验；评价对应 23.18 安全、权限与失败场景评测。这些支系会在各自编号中单独展开。