[Feature] 完善现有定时任务的执行历史、成果归因与统计查询

Ouverte
  • Quelque chose ne va pas ?
#460 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
8/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Active
Stack technique
github, go
Domaine
analytics, backend

Piste de recherche

This is a multi-part design proposal, so start by reading internal/httpapi/assistant_tasks.go (readScheduledTurn, deleteScheduledSessionsExcept), internal/httpapi/assistant_session_cleanup.go, and internal/domain/analytics.go (AnalyticsFilter) to see how scheduled sessions and filters work today. Done is not a single patch: a maintainer would first need to split the issue into smaller, separately verifiable tasks, such as durable execution records for scheduled runs, then usage deduplication. Treat this as a discussion to clarify scope before writing code.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Problem

定时 AI 任务和定时触发 SOP 已经可以持续运行，但用户目前主要能看到最近一轮状态、会话结果和已上报 Token，难以准确回答：某个 Loop 历史执行了多少次、创建/处理了哪些 Issue 和 PR、最终交付了什么、累计消耗多少，以及数据是否完整。

本 Issue 聚焦完善现有定时任务、运行记录和统计页面。不新增独立看板、一级菜单或另一套统计中心，不把项目总量当作某个 Loop 的成绩。旧提案 #455 已关闭，本 Issue 按上述边界重新整理。

已确认的现状
  • 定时任务执行已经给会话写入 scheduled 来源和 taskId，可复用现有身份关系。
  • 同文件的 readScheduledTurn 在成功后删除上一轮会话，并调用 deleteScheduledSessionsExcept；另外还有定时会话清理策略。因此，不只是展示问题：仅靠会话无法保证历史累计完整。
  • AnalyticsFilter已有项目、工作流、用户、时间等筛选，但缺少完整的定时任务和单次执行维度。
  • 会话与工作区 Run 可能包含同一份用量，直接相加会重复；costUsd=0 也可能代表未知，不能当作免费。
  • GitHub 上的 Issue、PR、review 和合入状态可以查询，但尚未形成跨会话、下游 SOP 和外部动作的完整任务归因。

Proposed behavior

1. 在现有入口补齐展示

现有定时任务列表/详情：保留当前配置和最近结果，补充历史执行列表。每轮可查看触发方式、时间、状态、结果摘要、关联工作项/Issue/PR、已知 Token 和采集情况，并跳到现有会话、运行详情及外部成果。可以复用现有详情、弹窗或抽屉组件，不另建独立看板。

现有统计页面：在当前项目、时间等筛选基础上增加“定时来源/任务”维度，复用已有图表、表格和下钻交互。选中单个任务后，所有卡片、趋势、明细、导出及 API/MCP 查询保持同一范围与口径。

默认先回答“做成了什么”，Token 和费用作为投入展示。任务类型不相关或未支持的指标不强行填零；原始工具调用量、扫描轮数和产物数量作为诊断信息，不充当交付效果。

用户要查看的信息 在现有入口中的展示
某个 Loop 执行情况 历史执行、成功/失败/取消/等待/跳过、无产出轮次、失败原因
Issue 成果 平台新建工作项、外部新建 Issue、实际处理/解决的独立 Issue，并可看明细
PR 成果 创建、审查、修改和合入的独立 PR，动作类型、状态及原始链接
投入 已知总 Token、输入/输出、缓存读写、估算/已上报费用、缺失来源
证据 对应执行、会话/Run/Trace、Issue、PR、review、验证记录；清理后说明可用范围
2. 优先保住历史：独立执行记录

复用现有任务 ID，每次触发建立持久化执行记录，不以聊天记录作为统计账本；已有可复用的运行/执行实体应优先扩展，避免重复存储和重复记账。

  • 两类入口均覆盖：AI 提示词任务、扫描并派发 SOP 的触发任务。即使扫描后没有派发，也保留本轮结果；“空扫描执行成功”不等于完成了需求。
  • 区分定时触发、立即运行、排队、实际开始、等待、成功、失败、取消和跳过；同轮节点重试不增加定时触发次数，手动重跑有独立执行及来源关系。
  • 稳定 taskId → executionId → session/workspace/run/子 SOP/attempt。传播到下游，异步 SOP 结束和外部合入不因主会话结束而失去归属。
  • 保存执行时的任务名称、配置版本/摘要、模型、起止时间、结果摘要和必要证据引用。任务改名/修改配置不覆盖历史，停用或删除任务配置不自动删除统计事实。
  • 执行事实、成果和用量与会话/Trace 分开留存；详细内容仍可按现有策略清理，页面明确哪些内容已过期。留存策略须明确、可配置；用户显式删除业务数据时遵守平台规则。
  • 执行开始尽早落库，缺凭据、启动失败、服务重启/中断等也留下可辨识记录，不能只保存成功轮次。采集异常可重试/补采，不重新执行已完成的外部写操作。
3. 明确 Issue / PR 归因与去重

从平台工具成功结果、现有交付关联、SOP 事件和外部系统确认中采集结构化成果，至少保留来源任务/执行、资源唯一键、动作、发生时间、执行者、结果与证据。

  • 平台建单与外部建 Issue 分开。导入已有 GitHub Issue 不算新建外部问题，同一个问题的多份平台关联不重复计算独立外部问题。
  • 扫描/读取与实际处理分开。分诊、回复、状态变更、修复等作为不同动作；新建、处理、解决分别统计，不把它们相加为交付总数。
  • 完成状态与修复效果分开。平台工作项 done、外部 Issue 关闭、验证通过各自保留口径；重复/不计划处理的关闭不算修复。已解决后重开保留变化历史。
  • 创建 PR、提交 review、审查评论、推送修复、合入分开。仅查看 diff 不算审查；独立 PR 数与 review/评论/更新次数分别统计。普通聊天评论不能无条件视为有效审查。
  • 合入以代码托管平台为准，保留真实 merged 时间、分支和合入者。Loop 创建或审查、由人合入的 PR 标记为协作成果，不表述为全自动合入；合入也不等同上线/验收。
  • 同一 PR 多轮处理、多个 Loop 参与时，分别保留创建/审查/修复等贡献；任务行可以都关联该 PR，平台独立资源总数取并集，不直接相加。主任务与子 SOP 的同一成果不重复累计。
  • 动作时间、合入时间、当前状态分开。默认按成果事件发生时间统计；查看某轮执行的最终成果时可看到后续异步变化，并注明观察截止时间。
  • 稳定资源键应包含托管平台/实例、仓库、资源类型及 ID；不能仅凭标题或机器人账号猜任务归属。无法确认的关联展示为未归因/待核实，不计入已核实成果。

外部状态采用已有 webhook 能力或增量轮询核实；重复通知和重试幂等处理，有最后同步时间、失败原因与补采状态。不要求为此先实现一整套新的 webhook 平台。

4. Token 和费用按任务累计，保留完整度
  • 包含主会话、下游 SOP、重试、失败/取消已产生的用量；同一模型用量来源只记一次，会话与工作区副本、父级汇总与子级明细不能重复相加。
  • 正确处理增量事件、累计快照、恢复执行及不同模型的缓存口径；缓存读写单列，不能不加区分地再加进总 Token。
  • 支持 taskId/executionId 和时间范围汇总，并下钻到来源。执行次数与模型调用/用量来源数分开，覆盖率明确分母。
  • 区分零用量、未知、不支持和部分已知。未知价格/缺失用量不能显示为完整的零成本；上报费用与估算费用标明来源、币种和价格版本，不混称实际账单。
  • 单位成果投入只在成果范围、时间范围和成本覆盖明确时显示；失败、返工和无产出轮次的投入不得隐藏，多成果共享消耗不能重复全额分摊。
5. 通用上报，不绑定某个 Loop 或项目

内置 Issue/PR/用量采集覆盖常用工具路径；同时提供有文档的成果上报 API/MCP/脚本契约，复用统一执行上下文、鉴权、幂等与证据字段。可上报文档发布、巡检发现等其他业务资源/动作，不为每个任务新增专属数据库列或写死标题前缀。

任意 shell/外部 MCP 中的动作不能保证自动识别：支持的适配器自动采集，其余通过显式上报补齐并说明覆盖边界。AI 自报“修复了十个问题”只作为待核实摘要，不能直接变成已核实成果。第一版不做自定义 BI/公式编辑器。

6. 接口、权限与历史数据
  • 扩展现有查询能力支持任务、执行、时间、来源和成果类型；后端聚合、分页明细、趋势和 CSV/JSON 导出同口径，MCP 能读取相同数据。不得静默忽略 taskId 导致返回项目总量。
  • 服务端校验当前项目权限与执行归属；跨项目汇总只包含授权数据，不能通过伪造 taskId/executionId 写入其他任务。避免在指标中存储凭据或完整敏感工具参数。
  • 历史回填仅使用仍存在且可验证的会话、Run 和外部关联，不猜测恢复已经删除的历史；标明采集起点、回填范围、缺失与统计更新时间。
  • 持久化按现有领域仓库和手工 SQL 迁移约定实现。优先增量采集、可重算聚合和分页，前端不靠拉取全部会话解析文本计数。

建议实现顺序

  1. 先上线独立执行记录和用量持久化，防止后续历史继续丢失；保留现有会话清理能力。
  2. 串联下游 SOP，补齐 Issue/PR 结构化成果、外部核实与去重，以及通用上报契约。
  3. 将上述数据接入现有任务历史/运行详情和统计筛选、明细及导出，完成浏览器验收。最终交付需覆盖以上完整路径，不以“只有埋点没有可见数据”结束。

本次不要求实现人工工时节省、意见自动采纳判定或 RSI 效果归因等缺乏可靠证据的高级指标。后续若接入 Verification/评测，沿用成果和证据关联，不另建统计体系。

Acceptance criteria

  • 无新增独立看板、一级导航或并行统计中心；用户从现有定时任务入口看历史，从现有统计入口按任务筛选并下钻，同一筛选下卡片、趋势、明细、导出和 API/MCP 一致。
  • 同一任务连续成功执行三轮后，即使旧会话被清理，三轮状态、结果摘要、成果、已知用量仍在；修改名称、停用和删除配置不覆盖统计。历史页面能区分证据已清理与执行不存在。
  • AI 提示词、扫描派发两种任务均有记录，覆盖空扫描、启动失败、等待、取消、立即运行、节点重试和重启中断；次数口径明确，失败不从分母和投入中消失。
  • A 在外部创建 I1 并关联平台、导入已有外部 I2、创建 P1、对 P2 提交两次真实审查：外部新建 Issue=1、创建 PR=1、审查独立 PR=1、审查次数=2，I2 不计外部新建。
  • B 也审查 P1：A 的处理 PR 并集=2、B=1，平台独立处理 PR=2；每条贡献可查动作和原始证据，重复上报/回调不变更计数。
  • P1 次日由人合入：按真实合入时间计数，仍可追到 A 的创建和 B 的审查贡献，标明人工合入；关闭未合入、Issue 重开及无法核实均不伪装成已交付。
  • 主会话100 Token、独立下游 SOP200 Token、另一失败执行300 Token：任务已知累计600；重复会话/工作区记录和父级累计快照不双计。另有缺失用量时标明部分已知，而非完整零成本。
  • 文档发布任务可通过同一上报契约记录资源、动作与证据，出现在现有任务历史/成果明细；不新增专属统计页面或专属数据库列，自报与已核实信息有区分。
  • API 测试覆盖幂等、并发、累计/增量用量、任务归因、异步成果、补采、版本兼容和越权；浏览器测试覆盖历史→执行→成果/会话/运行详情的路径及零/缺失/不支持/空状态。
  • 提供数据采集范围、留存/迁移、旧数据回填及统计口径说明；外部动作成功但采集失败可补采，不为了补采重做外部业务写入。

Scope

Platform — workflows / collaboration; UI / integrations.

Alternatives considered

  • 新建独立看板：增加重复入口和维护成本，不采用。
  • 无限制保留聊天，再解析自然语言：存储成本高且口径不可靠，不采用；保留结构化事实，详细记录按策略留存。
  • 只按项目总量、标题前缀或统一机器人账号统计：缺少可靠任务归因，可辅助历史核对但不能作为唯一依据。

Checks

  • 不依赖组织专属基础设施、内部数据或凭据。
  • 已检索相关 Issue；#455 保持关闭，本 Issue 明确改为完善现有入口及数据能力。
Langage dominant
Go
Étoiles
141
Forks
28
Merge moyen
1 j 15 h
PR mergées (30 j)
113

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Tencent/LoopForge

Toutes les issues de Tencent/LoopForge

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.