哪些任务适合交给 Agent 自动完成，怎样设置人工介入边界？

核心回答

适合 Agent 自动完成的任务，通常具有目标明确、结果可验证、操作范围可控、出错后能恢复这些条件。人工介入要按具体业务动作设置，不能只按“用了 AI”或“有写操作”统一划线。

例如运维任务中，读取授权范围内的指标、整理日志、匹配已知故障和生成处理建议，可以自动推进；已经授权、范围有限且有成熟校验与回滚流程的修复，也可以自动执行。若要变更生产配置，却存在目标不清、证据冲突或恢复代价高的问题，应先由人判断。

边界可以分三层：

1. 开始前判断能否闭环：是否具备所需信息、工具、权限、验收方式和恢复手段。
2. 执行中按条件转交：缺少关键输入、遇到未授权动作、重复失败、没有进展或接近预算时，停止相关步骤并带着证据交接。
3. 人工处理后可恢复：保存当前状态、已执行动作和待决事项，接收补充、修改或拒绝结果，再校验现场后继续，避免重复操作。

人工可以负责澄清目标、判断例外、决定某个动作或直接接管，不必每一轮都确认，也不必把整个任务从头交回人。

用动作的后果与恢复成本判断自动化范围

先拆业务链路，区分“读信息、提出建议、改变外部状态”。同一个 Agent 可以负责前两类，第三类按条件开放。

以故障处理为例：告警归类和日志摘要即使出错，通常还可对照原始材料修正；重启实例会影响在线请求；清理数据一旦误删，恢复可能依赖备份，甚至无法完整恢复。因此，不能用同一套自动执行条件覆盖所有动作。

判断时具体看：

• 能否验收：有无明确状态、规则、测试或可对照的证据，还是只凭模型说“已经解决”。
• 错误影响：涉及单个测试资源，还是大量用户、资金、权限或不可替代的数据。
• 可逆性与补救成本：能否重试、撤销、回滚；恢复耗时是否超过业务容忍度。
• 环境稳定性：输入和工具是否可靠，是否存在长等待、并发变更或外部系统结果不明。

低风险写入也可能适合自动化，例如按既定规则创建内部工单、在隔离环境修改文件或重建可再生成的缓存。高影响动作若已具备明确授权、经过验证的操作规程、监测和可靠恢复，也可以受控自动执行；关键是这些条件真实成立。

哪些情况需要人，以及人需要做什么

任务含糊时澄清。 例如“把服务器恢复正常”没有说明可接受的中断和修改范围。先补足目标及限制，不让 Agent 自行替业务决定取舍。

证据不足或冲突时补充判断。 日志同时指向两个不同原因、资源归属不明，或数据与用户描述矛盾时，可以让人提供缺失信息或选择后续方向。模型自报的置信度只能作为线索，不能直接充当可执行依据。

动作超出已授权范围或影响发生变化时暂停。 比如原先只处理测试环境，却发现目标实际是生产实例；或者准备修改的配置已经被他人更新。需要重新明确当前动作的对象、参数和影响，而不是继续沿旧计划执行。

恢复不确定或反复无进展时接管。 外部接口超时后，不知道操作是否成功，应先查业务状态；仍无法确定就把记录交给人，不能盲目重试可能重复扣款、发送或重启的动作。相同失败反复出现、工具缺失或预算耗尽，也应提供部分结果和已尝试路径。

不同触发点对应不同处理：补充信息、确认一个具体动作、修改方案、拒绝动作或专家接管。单个动作被拒绝后，流程还可以继续处理不受影响的部分。

让人能快速判断，而不是只弹一个确认框

交接内容至少包含：当前目标、已经查到的证据、已完成与未完成步骤、准备执行的动作和参数、预期影响、备选方案，以及需要人决定的具体问题。能标出原始日志、配置差异或失败请求，处理者就不必重新排查。

例如不要只显示“是否修复”，而应说明“准备把哪个实例的哪个配置从什么值改成什么值，依据是什么，预计影响哪些请求，失败后怎样恢复”。如果只是缺少一项业务参数，就只请求这项信息，不必把整个流程转成审批。

人工反馈与实际执行要绑定同一任务及动作版本。人修改参数后，由执行层再次检查类型、业务状态和权限；人工点击同意不代表可以跳过这些校验。若等待期间目标已经变化，应重新评估该动作，而不是执行过期决定。

暂停与恢复要保存现场，也要防止重复副作用

把任务标为等待输入，并保存状态、动作标识、工具结果和交接信息；等待期间不需要持续让模型空转。根据业务设置超时、取消或转交安排，无人响应不能自动变成同意。

LangGraph 的中断机制就是一种实现：借助 checkpointer 保存图状态，使用同一线程标识和恢复输入继续执行。需要注意，恢复时中断所在节点可能从头运行，因此非幂等副作用不能随意放在中断之前。LangGraph Interrupts

实际业务仍需幂等键、执行记录或去重检查。把发送、转账等动作放到恢复后的独立步骤，可以减少中断重放造成的重复，但不能仅靠节点拆分保证跨系统“恰好一次”。若人已经手动完成修复，应记录结果并验证现场，让 Agent 接着做验收，而不是再修一次。

自动化范围怎样逐步扩大

可以先让 Agent 完成诊断或生成候选方案，用历史任务回放和有限范围运行验证，再按动作类型逐步增加执行能力。重点看任务成功率、错误动作的后果、恢复次数、人工介入是否及时，以及交接材料能否帮助人快速完成处理。

同时观察不必要介入：如果每次常规操作都需要人重新看完整日志，自动化收益会被等待和复核抵消。可以改进验证规则、缩小动作范围或补齐回滚能力，再放开满足条件的场景；不应只追求“人工介入率为零”。

追问：代码生成到上线能完全自动化吗？

可以把有清晰边界的部分自动化，例如局部格式修复、在隔离环境修改代码、运行相关测试和生成可审查 diff。涉及新业务取舍、数据迁移、权限变化或难以恢复的发布，应结合项目已有验证与发布机制判断需要何种人工参与。

预发测试通过只是其中一项证据，不能覆盖测试没有代表的真实流量、数据和依赖差异。对于已有充分覆盖、发布范围受控且能及时发现并回滚的问题，可以提高自动化程度；不能由“Agent 已完成”直接推出所有需求都能上线。

对应教程

参考资料