qinghuan
返回三条项目主线

机制参考 · 按需阅读 / 读后台任务与工具发现

JavaClaw

研究长任务如何排队、重试与追踪结果

一个个人助手型应用，适合补后台任务和工具发现。它使用 Java 25 与较新的 Spring 栈；如果你的环境只有 Java 17，先读指定文件，不必为了这一条机制参考升级整个项目。

进阶；环境门槛较高核对 2026-09-29

先固定版本和学习范围

Java 25 · Spring Boot 4.0.6 · Spring AI 2.0.0 · JobRunr 8.6.1

打开本轮固定源码 · 项目仓库

提交 4df0115ea2b417af123d501ed2ec2d79db036056

仓库许可证标识：LGPL-3.0（license.md）。本页介绍所读版本，未保证未来版本保持相同行为。

开始前要会

  • Gradle、后台任务和数据库幂等
  • 区分调度重试与业务完成
环境、模型费用和额外服务
  • 需 Java 25、Gradle 和可用模型服务；模型调用可能收费。
  • 浏览器、搜索、消息渠道与外部工具按启用功能另行配置。
  • 版本以 gradle/libs.versions.toml 为准，README 的旧版本表未同步。

已经在源码中读到

一次任务大致怎样走

  1. 保存任务
  2. 排队 / 定时
  3. 转为执行中
  4. Agent 调用工具
  5. 记录结果并通知

保存任务和入队分开

TaskManager 先写任务文件再入队，适合分析“写成功、入队失败”这一中间状态。

失败后会重试

TaskHandler 标有三次重试；模型返回任务结果后保存状态。自动重试并不保证外部工具只执行一次，结果也应独立核对。

工具可按需发现

ChatClient 组装了工具调用、工具发现和会话记忆；找到工具仍需单独做执行授权。

需要自己补齐或验证

这些能力不能直接写成“已实现”

  • 本轮未构建或启动，不能承诺任务崩溃恢复、并发文件写入和工具隔离已达生产要求。
  • 任务与会话使用文件存储；持久化介质存在不等于事务、并发控制和租户隔离都已解决。
  • 当前任务通知处仍有会话关联待办；完整消息渠道体验需要另外验证。

建议改造 · 不是原仓库成绩

把原项目变成自己的项目

按顺序完成最小闭环，再增加难度。只把真正实现并测过的部分写进简历；如果声明支持恢复或并发，就补对应的故障实验。

01

限定为一个模拟工单场景

从虚构故障日志提出建议，批准后创建模拟工单。

怎样验收

  • 结果以工单记录判断，不能只信模型说成功。
02

用故障注入检查重试

在写工单后、保存任务状态前故障；为工具调用添加幂等键和恢复对账。

怎样验收

  • 重试后不重复建单；保存成功但入队失败的任务可被补偿。
03

比较工具发现是否有收益

同一组任务比较全量工具与动态发现。

怎样验收

  • 同时报告漏找、选错、调用次数、延迟和任务成功率。

按这个顺序读源码

每读一步，画一条调用关系，写下输入、状态变化和失败出口。无需先把整个仓库读完。

  1. 第 1 步 · 核对依赖版本libs.versions.tomlgradle/libs.versions.toml
  2. 第 2 步 · 核对 Java 工具链build.gradlebuild.gradle
  3. 第 3 步 · 工具组装MainChatClientProvider.javabase/src/main/java/ai/javaclaw/MainChatClientProvider.java
  4. 第 4 步 · 创建任务TaskManager.javabase/src/main/java/ai/javaclaw/tasks/TaskManager.java
  5. 第 5 步 · 状态与重试TaskHandler.javabase/src/main/java/ai/javaclaw/tasks/TaskHandler.java

准备好回答这些追问

先用自己的实现和实验回答，再对照源码。只背术语，很难解释异常情况。

  1. 自动重试为什么可能重复创建工单？
  2. 保存任务与入队之间失败，如何补偿？
  3. 模型说任务完成，你用什么业务证据核对？
  4. 文件记忆怎样处理同一会话的并发更新？
  5. 动态工具发现漏找了必需工具，如何定位？
  6. 为什么长任务要离开 HTTP 请求线程？

本轮实际验证范围

  • 固定提交检查构建文件和核心源码；未构建、运行测试、启动应用或调用模型。

源码链接是阅读证据；改造建议是待完成任务。二者都不等于完整系统运行证明。