无人值守智能体任务闭环设计实践

一、问题的本质：从“对话式智能体”到“值班式智能体”

在很多开发场景中，真正需要智能体来处理的并不是一个简单问答，而是一段需要持续推进的工作流。例如，一批测试用例需要补齐，若干文档需要生成，数据迁移脚本需要按顺序执行，或是一组小型缺陷需要逐个修复。此时开发者可能正在睡觉、通勤、开会或外出，无法守在终端前逐步确认。

常规的对话式智能体在这种场景下会暴露明显短板。每一次推进都依赖开发者输入，一旦上下文中断，任务状态就容易丢失。更常见的做法是让模型“连续完成所有任务”，但这种方法存在三个风险：其一，进程可能因网络波动或异常退出而中断，无人拉起；其二，任务清单写在对话里，随着轮次增加不断重复消耗上下文；其三，智能体可能在没有真实验证的情况下自行判断“已经完成”，最终交付物质量不可控。

因此，真正的需求并不是一个“更强的模型”，而是一套面向无人值守场景的流程规范。它必须能让智能体自己读取任务、自己执行、自己验收、自己决策，并在异常后自行恢复，最终向开发者交付一份可读的晨间简报。

二、任务清单必须文件化：让状态可持久、可变更

无人值守流程的第一个设计原则，是任务清单必须写入文件，而不是停留在对话上下文中。对话中的清单会随着轮次反复带入历史消息，造成上下文浪费；同时，开发者在夜间如果想临时增删任务，也无法便捷修改对话内容。

更合理的做法是将任务清单放在项目内固定文件中，例如 TASK-BOARD.md 或 TODO.md，由智能体按需读取。这样至少带来三个好处：

1. 状态持久化：任务状态不依赖当前会话，进程重启或会话中断后仍可恢复。
2. 上下文节约：智能体仅在需要时读取文件片段，不必每轮重复携带完整清单。
3. 人机协同修改：开发者可以随时增删、调整优先级，而不必打断正在运行的智能体。

为了清晰表达任务进展，建议采用四级状态标记：

• [ ]：待办，尚未开始处理；
• [x]：已完成，且已通过验证；
• [~]：部分完成，存在残留问题；
• [!]：受阻，等待条件满足或人工介入。

例如：

## 任务清单
- [x] 修复登录模块异常处理，补充单元测试
- [~] 生成数据迁移文档，缺少回滚策略说明
- [ ] 重跑夜间数据对账任务
- [!] 更新接口文档，测试环境暂不可用

这种标记方式简单直观，适合机器解析，也方便开发者晨间快速浏览。

三、验收门禁：只有证据才算完成

无人值守最核心的风险在于，智能体可能“觉得自己做完了”。模型生成代码或文档后，有可能跳过验证步骤，直接标记为完成。如果没有人复核，这类虚假完成会被带入最终交付物。

为了避免这种情况，必须设置明确的验收门禁：只有可复现的验证证据通过，任务才能被标记为完成。所谓验证证据，可以是测试命令及其输出、静态检查结果、构建成功记录，或数据校验结果。

例如，一个修复任务不能只写“已经修复”，而应给出：

pytest tests/test_order_service.py -q

并附上通过结果：

12 passed, 0 failed, 0 skipped

如果修复内容涉及多模块，还需要补充影响范围说明与回归验证命令。这样开发者在晨间复核时，不必重新推导全过程，只需扫一眼验证输出即可判断任务是否可信。

这一原则可以进一步细化为：

• 每个完成项必须至少关联一条验证证据；
• 证据必须是命令加结果的形式，不能只写“已验证”；
• 验证失败不得标记为完成，应转入修复或受阻状态。

四、默认决策：不等待人工也能持续推进

无人值守场景下，智能体经常遇到需要判断的模糊情况。例如：某个依赖暂时不可用；两个任务存在先后关系但前序未完成；某个生成结果介于可接受与不可接受之间。如果此时智能体停下来等待人工确认，整个夜间流程就会中断，失去无人值守的意义。

因此需要引入“默认决策树”，让智能体在拿不准时按照预定义规则继续推进。通常可以设计为三档：

1. 低风险事项：直接按最常见处理方式执行，并将决策写入决策日志；
2. 中风险事项：执行默认策略但标记为“待人工晨检”；
3. 高风险事项：跳过当前任务，标记为受阻，并在简报中突出提示。

例如，当发现依赖服务不可用时，默认策略可以是连续重试三次，间隔一分钟；若仍不可用，则将任务标记为 [!]，继续处理其他不依赖该服务的任务。所有默认决策都应记录在 DECISIONS.md 中，供开发者事后追溯。

这样做的关键在于：流程永不因等待而悬停，但也不隐瞒任何自行做出的决定。晨间简报中会集中列出所有自动决策，开发者可快速判断是否需要纠正。

五、心跳保活与看门狗：让流程扛得住崩溃

工程化实践中最棘手的问题，是执行过程中的进程中断。无人值守任务通常运行数小时，期间可能遇到网络闪断、机器休眠、服务重启或代码异常。如果没有恢复机制，任务会停在中间，既无人知晓，也无法续跑。

解决方案可以抽象为两部分：心跳保活与看门狗监控。

心跳保活的核心思路是，在执行过程中定期产生一个可以被外部捕获的“生命信号”。例如，通过周期调度机制创建一个间隔提醒，每 30 秒发出一次信号，表示当前流程仍在运行。如果外部系统连续多次未收到信号，则判定任务中断。

示例伪代码：

schedule_create(
    name="night_shift_heartbeat",
    interval="every_seconds=30",
    action="send_heartbeat"
)

看门狗则承担恢复职责。它作为主机级脚本独立运行，监控目标进程或心跳文件。一旦发现消失，就执行恢复动作：读取任务清单、找到最后一个完成项、重新启动执行流程。

将看门狗与任务清单状态结合后，可以实现近似“断点续跑”的能力。每个任务完成时都更新状态文件，看门狗重启执行器后会读取文件，跳过已完成项，从最近未完成任务继续。这样即便整个节点重启，只要状态文件还在，工作就不会白做。

六、最终交付：晨间简报与决策可追溯

无人值守流程必须闭环到“开发者能够快速理解昨晚发生了什么”。智能体应在全部任务处理完毕后，生成一份简报，内容至少包括：

• 任务总量、完成数、部分完成数、受阻数；
• 每个完成项对应的验证命令与结果摘要；
• 所有默认决策及其理由；
• 仍存在的风险与建议人工处理事项；
• 看门狗触发次数与恢复记录。

例如：

# 夜间任务简报
- 总任务：7
- 已完成：5
- 有残留：1
- 受阻：1
## 验证摘要
- 订单模块：pytest 12 passed
- 数据迁移：校验脚本通过，2 条记录待人工确认
## 自动决策
- 缓存服务不可用，重试 3 次后标记受阻，继续处理其他任务
## 风险提示
- 接口文档因测试环境异常未更新

这份简报让开发者从“检查有没有跑完”变为“只看关键异常”，真正实现“放一晚上，第二天收割成果”。

七、工程落地建议

在实际工程中，这套流程可以逐步引入。优先从任务清单文件化开始，让所有待办任务具备持久化基础；随后加入验收门禁，强制要求验证证据；再引入默认决策树，减少中途等待；最后部署看门狗与心跳保活，形成完整闭环。

需要强调的是，这些机制并不依赖某个特定模型或平台，而是通用的工程规范。无论使用哪种智能编程工具，都可以通过类似方式提升无人值守执行的稳定性与可信度。如果结合云上的容器平台、日志服务与监控告警能力，还能进一步实现跨机器恢复与集中审计。

无人值守智能体的目标，并非替代开发者的全部判断，而是让开发者把精力从“盯着执行”转移到“审阅结果”。只有验收有证据、决策有记录、崩溃能恢复，才可能让人真正放心地离开终端。