把 Chat2DB 内置 AI 从「Chat 型」强化为「任务型 Agent Runtime」

[auenger]

提议：把 Chat2DB 内置 AI 从「Chat 型」强化为「任务型 Agent Runtime」

背景：当前 AI 能力是「Chat 型」

Chat2DB 内置的 AI 能力（Chat 对话、AI 写 SQL / NL2SQL、外部模型接入）目前是典型的 Chat 型 交互：

• 一次请求内同步流式返回（SSE），单轮问答，流结束即结束；
• 没有任务概念：无队列、无生命周期状态、无断线恢复；
• 工具调用即时执行，没有人工介入点（审批 / review / 澄清）；
• 执行过程只有展示型 trace，不可重放、不可追踪、不可恢复。

提议：升级为「任务型 Agent Runtime」

在 Chat2DB App 自身能力不变（数据库连接、SQL 客户端、数据管理、MCP 工具等原有能力全部保留）的前提下，把产品形态转型为类似 WorkBuddy / Codex App 的任务型 Agent 工作台：数据库能力仍是核心底座，交互升级为"任务驱动"，AI 从聊天助手升级为可调度、可审批、可留痕的一等公民。

参考任务驱动型 Agent 工作台（如 WorkBuddy）与 Coding Agent（如 Codex、Claude Code、Hermes）的通用模式，把 Chat2DB 的 AI 升级为以 Task 为一等公民 的 Agent 运行时：

1. UI：从 Chat 升级为 Task 工作台

• 任务列表入口 + 任务详情页（状态、执行时间线、产物、审批）；
• 现有 Chat 流时间线（reasoning / tool_call / tool_result / answer）直接复用为任务执行时间线；
• 轻量问答入口保留，不破坏现有聊天数据。

2. 执行体（runtime）可插拔

• 进程内 Java AgentExecutor（默认执行体，离线可用、无外部依赖）；
• 内置 Rust CLI（chat2db 二进制）强化为独立 agent 执行体；
• 外部 Coding Agent（Codex、Claude Code、Hermes 等）也可作为 runtime 接入；
• 统一执行体契约：run(task) → 流式事件（与 MCP 协议兼容），执行体可插拔切换。

3. 通用 Agent 能力

• 任务队列 + 状态机：queued → running → waiting_approval / in_review → completed / failed / cancelled；
• 定时轮询 / 定时触发任务（类似 autopilot 的定时巡检、定时报表）；
• 人工介入点：SQL 写操作（DML/DDL）审批、结果 review、澄清提问；
• 任务产物快照（结果集 + 图表 + 报告，可回看、可恢复）；
• 断线恢复：任务在后台执行，离开/重进后进度与结果仍在。

4. 核心定位：以数据库连接能力为底座，本地 Runtime + CLI 做任务强化

• Chat2DB 已有的数据库连接、元数据、SQL 执行、MCP 工具能力是整个体系的底座；
• 本地 Agent Runtime（进程内 Java / 内置 Rust CLI）配合 CLI 把这份底座能力编排为可调度的工具集，完成复杂任务调度 / 任务强化；
• 上层 Agent（内部 AgentExecutor 或外部 Codex、Claude Code、Hermes）在此之上获得更高能力：多步数据分析、定时巡检、写操作审批执行、跨库编排；
• 即：数据库连接能力 → CLI / 工具层 → Agent Runtime → 复杂任务强化，能力逐层放大，各层可独立演进。

架构落地三步

1. 显式编排循环（AgentExecutor）：从"模型内部工具循环"改为显式可控循环——最大迭代轮数、工具失败重试、提前终止、超时控制；
2. 任务 / 状态模型 + 事件协议：引入 AgentRun / AgentStep 状态机，SSE 事件升级为结构化、可重放的事件流；
3. 工具注册表 + 安全边界：工具带元数据（读写级别、是否需审批）；execute_sql 写操作挂起等用户批准；支持只读模式。

想听大家讨论

1. Chat 与 Task 的关系：整体升级为任务模型，还是任务入口与轻量问答双入口并存？
2. 多执行体的取舍：内置 Rust CLI 兜底（离线可用）vs 外部 Coding Agent 增强（依赖用户本机安装），价值曲线怎么排？
3. 本地桌面的调度模型：进程内定时器 + 任务队列（关应用即停）是否符合预期，还是需要常驻后台？
4. 与现有会话历史（本地 JSON）的数据兼容方案？
5. 第一波优先场景：数据分析任务 / SQL 写操作审批 / 定时巡检？

欢迎拍砖、补充场景，也欢迎指出这个方向在数据库工具里的坑。

关联

• 关联 Issue：#2566 把内置 AI 从「Chat 型」强化为「任务型 Agent Runtime」

[houyongsheng]

Chat 是发生在任意 Agent 或渠道中的意图入口，Task 才是 Chat2DB 承接数据库工作的可信执行单元；Chat2DB 不争夺谁来聊天，而将来自 Codex、Claude、IDE、CLI、IM 或自身的意图，统一转化为可调度、可审批、可恢复、可审计的 Task，并安全可靠地执行到底。

[auenger]

对的没错，我想要让 Chat2db 成为一个安全可信的针对数据库层面可以自主完成任务的一个独立 Agent， 做到一个完整的生态中，实现 数据库相关 Task 的可调度、可审批、可恢复、可审计。然后做到整个 agent 运行生态中去。

类似图中这个意思，专门的一个负责 DB的 独立 Agent

[auenger]

补充：这不是给 Chat 增加几个能力，而是两种软件形态

当前 Chat2DB 的 AI 仍然主要由人驱动：用户发起对话、描述问题，AI 生成 SQL 或返回查询结果，之后还需要人继续判断、复制、整理和交付。它更像一个增强型数据库工具，工作的闭环仍由人完成。

我们希望升级后的 Chat2DB 能拥有自己的 Agent Runtime：接到一个 Task 后，Agent 可以自主读取任务上下文，规划和拆解步骤，定位合适的数据源，调用现有数据库连接、元数据和 SQL 能力获取数据，完成分析，并把最终产物交付出去。人不再负责逐轮驱动执行，只在澄清、审批和 review 等必要节点介入。

可以把完整闭环抽象为：

Task 输入 → 上下文理解 → 规划与拆解 → 数据源发现 → SQL / 工具执行 → 分析与校验 → 产物生成 → 渠道交付

这里最核心的抽象是 Task，而不是 Chat，也不是 A2A：

• 任务不关心由谁发起，可以来自 Chat2DB 自身、其他 Agent、IDE、CLI、IM、定时器或外部系统；
• A2A、MCP、API 等都只是接收任务、传递上下文和返回产物的媒介；
• 只要请求符合统一的 Task 契约，Chat2DB Agent 就能够承接并执行；
• Task 应标注目标、上下文、约束、数据源范围、审批策略、期望产物和交付渠道。

产物和交付也不应局限于聊天文本：

• 产物可以是结果集、分析报告、图表、CSV / Excel / PDF 等文件，或其他结构化数据；
• 交付可以回到 Chat2DB，也可以发送给发起 Agent、IM、Webhook、邮件或指定系统；
• Agent 根据 Task 定义自主调度工具、生成产物并选择交付方式。

同时，产品中需要完整保留每个 Task 的来源、上下文、规划过程、执行步骤、状态变化、审批记录、数据访问记录和最终产物，使任务可以追溯、恢复和审计。

因此真正的产品变化是：

从“人使用 Chat2DB 完成数据库工作”，升级为“人或其他 Agent 把数据库任务交给 Chat2DB，由 Chat2DB 自主完成并交付结果”。

这才是 Chat2DB 作为 AI Native Database Agent 的核心形态：数据库能力是底座，Task 是统一入口，Agent Runtime 负责自主执行，Artifact 是最终交付。

[bobleer]

这个方向挺对。我觉得第一波别铺太大，先把「SQL 写操作审批」这一条竖着跑通：创建 Task → 跑到 DML/DDL 前挂起 → 杀掉 App → 重开 → 审批 → 继续执行 → 留下可审计的结果。这个链路一旦通了，队列、恢复、审批、产物几个最难的底层问题基本都碰到了；定时巡检反而可以后放。

我们做 BitFun 的 Rust Agent Runtime 和 Mini Apps 时，有个坑很明显：别让 Task 状态寄生在聊天记录里。Chat 可以是入口和观察窗，但 Run、approval、tool result、artifact 得各自有稳定 ID，事件最好只追加，工具执行还要有幂等键。否则很容易出现“聊天还在，但这个写操作到底执行过没有”的尴尬场面。

另外数据库任务真的很适合单独的界面，不必把结果都塞回 Markdown。结果集、图表、写入前后的 diff、审批按钮可以直接作为任务自己的 UI，Chat 只负责追问和改目标。这个也是我们做 Agentic Mini Apps 后感觉比纯聊天顺手很多的地方。

[haizhi03]

我比较认同从 Chat 往 Task 这个方向走，不过这段看下来还有几个地方没太想明白。

首先是这句：

只要请求符合统一的 Task 契约，Chat2DB Agent 就能够承接并执行。

我感觉这里说得有点满。Task 契约更多解决的是“任务怎么描述”，但一个任务能不能真正执行，还要看当前 Agent 有没有对应能力、调用方有没有数据源权限、这个任务允不允许执行写操作、产物能不能往外发等等。

比如一个任务要求查生产库，然后生成 CSV 发到某个 Webhook。Task 格式本身完全合法，但调用方可能没有生产库权限，Webhook 也可能不允许外发数据。这种情况下，光靠统一 Task Contract 应该还不够。

所以这里是不是还需要有一层 capability / permission / policy 的判断？尤其 Chat2DB 本身管理的是数据库连接，我觉得数据源的“可见”“可用”“当前任务允许使用”最好不要混在一起。

另外，A2A、MCP、API 全部归成“接收任务、传上下文、返回产物的媒介”，我觉得也有点粗。MCP 更偏工具和资源暴露，A2A 本身其实已经有 Task、状态、Artifact 这些概念了。既然后面希望其他 Agent 也可以把任务交给 Chat2DB，那是不是可以先看看内部 Task Model 和这些协议怎么映射，而不是一开始就把 Chat2DB 的 Task Contract 定死？