# 基于 PostgreSQL + xxxxxxx 的 xxxx 标量混合搜索索引：多 Agent 协同示例

## 一、目标形式化与验收标准

### 1.1 总目标

设计并实现一个xxxxxxxxxxxxxxxx。

### 1.2 成功标准（可验证）

| 编号 | 验收项 | 验证方式 |
|------|--------|----------|
| S1 | `CREATE INDEX ... USING xxxx` 成功创建索引 | `EXPLAIN` 确认索引被使用 |
| S2 | xxx+标量混合查询返回正确结果 | 与暴力扫描结果对比，Recall@10 ≥ 0.95 |
| S3 | 索引支持增量 INSERT 和 DELETE | 插入后查询命中，删除后 VACUUM 可回收 |
| S4 | VACUUM 后索引结构完整，查询质量不下降 | VACUUM 前后 Recall 对比 |
| S5 | 磁盘存储格式可持久化，重启后索引可用 | 重启 PostgreSQL，重新查询验证 |
| S6 | 混合查询性能优于“分别扫描再交集”基线 | 执行时间对比 |

### 1.3 约束条件

- PostgreSQL 14+，xxxxxxx 0.xx+
- 支持 xxxx 结构与标量过滤的联合下推
- VACUUM 需维护 xxxx 多层图连接性
- 不允许全表扫描作为默认执行路径

### 1.4 终止条件

全局验收通过 / 预算耗尽 / 超时 / 不可恢复冲突升级人类。

---

## 二、动态任务图设计

将目标分解为可独立执行、可验证的任务节点：

```text
T1  调研 xxxxxx现状
T2  调研 PostgreSQL 自定义索引 AM 接口规范
T3  设计xxxxx的磁盘页布局与元数据结构
T4  实现 ambuild（索引构建，含 in-memory + on-disk 两阶段）
T5  实现 aminsert（增量插入）
T6  实现混合查询执行器（Vxxxxxx+标量条件联合下推）
T7  实现 ambulkdelete / amvacuumcleanup（VACUUM 三阶段回收）
T8  实现 amcostestimate（代价估算，让 Planner 选择此索引）
T9  编写单元测试与集成测试
T10 性能基准测试与 Recall 验证
T11 文档与最终验收报告
```

依赖关系：

```text
T1 ──┐
     ├──→ T3 ──→ T4 ──→ T5 ──→ T7
T2 ──┘         │       │
               ▼       ▼
              T6 ──→ T8 ──→ T9 ──→ T10 ──→ T11
               │
               └──→ T7
```

---

## 三、Agent 设计

### 3.1 Agent 能力档案

| Agent | 技能 | 工具/权限 | 成本 | 置信度 |
|-------|------|-----------|------|--------|
| **Planner** | 任务分解、重规划、依赖管理 | 任务图读写 | 高 | 0.9 |
| **C-Researcher** | PostgreSQL C 源码、索引 AM 接口 | 源码仓库、文档 | 中 | 0.85 |
| **Vxxx-Expert** | xxxx 算法、xxxxxxx 源码 | xxxxxxx 源码、论文 | 中 | 0.9 |
| **Storage-Engineer** | 磁盘页布局、Buffer Manager、WAL | PostgreSQL 内核源码 | 高 | 0.8 |
| **Query-Engineer** | 查询执行器、Planner 接口、代价估算 | PostgreSQL 执行器源码 | 高 | 0.85 |
| **Vacuum-Engineer** | MVCC、VACUUM、图结构维护 | PostgreSQL VACUUM 源码 | 高 | 0.8 |
| **Test-Engineer** | 测试框架、Recall 计算、基准测试 | 测试工具、数据集 | 中 | 0.9 |
| **Verifier** | 独立验证、证据链检查 | 只读权限、验证脚本 | 低 | 0.95 |
| **Coordinator** | 冲突仲裁、超时处理 | 消息总线 | 低 | 0.9 |

### 3.2 共享黑板结构

```json
{
  "goal": { "id": "hybrid-xxxxxxx-index", "success_criteria": ["S1","S2","S3","S4","S5","S6"] },
  "task_graph": {
    "T4": { "status": "in_progress", "owner": "Storage-Engineer",
            "inputs": ["T3.design_doc"], "outputs": ["ambuild实现"],
            "deadline": "2026-09-15", "budget": 500, "commitment": "signed" }
  },
  "artifacts": {
    "T1.research": { "path": "docs/xxxx_architecture.md", "evidence": ["src/xxxx.h:L14-L34"] },
    "T3.design_doc": { "path": "docs/page_layout.md", "reviewed_by": "Verifier" }
  },
  "messages": [],
  "conflicts": [],
  "budget": { "total": 5000, "used": 1200 }
}
```

---

## 四、自主协调机制

### 4.1 合同网投标与承诺

每个就绪任务发布后，有能力的 Agent 自主投标：

```text
T4 (ambuild 实现) 公告:
  所需能力: PostgreSQL C, Buffer Manager, xxxx 构建
  预算: 500, 截止: 2026-09-15

投标:
  Storage-Engineer: 得分 = 0.9×0.8×0.9 - 0.3 - 0.2 = 0.148
  Vxxxxxx-Expert:    得分 = 0.85×0.9×0.9 - 0.2 - 0.1 = 0.388  ← 中标

承诺: Vxxxxxx-Expert 签署合约，每 2 小时报告状态
```

### 4.2 关键协调场景

**场景 1：T4 实现中遇到 xxxx in-memory 与 on-disk 阶段切换问题**

Vxxxxxx-Expert 发现 xxxx构建分两阶段：第一阶段图完全在内存中构建，第二阶段逐条插入磁盘。但自定义索引 AM 的 `ambuild` 需要在磁盘上直接构建。

→ Vxxxxxx-Expert 在黑板发布 `request_help`，C-Researcher 响应，提供 PostgreSQL `IndexBuildHeapScan()` 的用法示例。两者协商后决定：复用 xxxxxxx 的两阶段策略，`ambuild` 中先内存构建再批量写入。

**场景 2：T7 VACUUM 实现与 T4 的存储格式冲突**

Vacuum-Engineer 发现 xxxx 三阶段 VACUUM 需要访问 `xxxxx` 的 `heaptids` 和 `neighbors` 字段，但 Storage-Engineer 在 T3 中设计的磁盘页布局没有预留这些字段的持久化位置。

→ Coordinator 发起冲突解决会议。三方协商后决定：T3 增加一个辅助页类型存储图连接信息，Vacuum-Engineer 修改 T7 实现以适配新布局。T3 重新验证，T4 的 `ambuild` 同步更新。

**场景 3：T6 混合查询执行器需要与 T8 代价估算协同**

Query-Engineer 实现查询执行器时，需要让 Planner 知道混合条件下推的代价。但 T8 的 `amcostestimate` 还未实现。

→ Query-Engineer 与 Planner 自动组成临时协作组：先定义接口契约（代价估算输入输出格式），然后并行实现，最后集成测试。

### 4.3 验证协议

每个任务完成后，Verifier 独立验证：

- T4 验证：编译通过 + `CREATE INDEX` 成功 + `EXPLAIN` 显示索引被使用
- T6 验证：混合查询结果与暴力扫描对比 Recall ≥ 0.95
- T7 验证：VACUUM 前后查询质量不下降 + 磁盘空间回收

---

## 五、运行闭环

```text
=== 第 1 轮：调研与设计 ===
Planner 生成 T1-T3
C-Researcher 中标 T1 → 产出 docs/xxx_architecture.md
Vxxxxxx-Expert 中标 T2 → 产出 docs/pg_index_am.md
Storage-Engineer 中标 T3 → 产出 docs/page_layout.md
Verifier 验证 T1-T3 → 通过

=== 第 2 轮：核心实现 ===
黑板发布 T4, T5, T6, T7
Vxxxxxx-Expert 中标 T4 → ambuild 实现
Query-Engineer 中标 T6 → 混合查询执行器
Vacuum-Engineer 中标 T7 → VACUUM 三阶段实现
Storage-Engineer 中标 T5 → aminsert 实现
→ 检测到 T3/T7 冲突 → Coordinator 仲裁 → T3 修订 → T4 重编
Verifier 验证 T4-T7 → T7 首次失败（图连接断裂）
→ Vacuum-Engineer 修复，Verifier 复验通过

=== 第 3 轮：集成与验收 ===
Query-Engineer 中标 T8 → amcostestimate
Test-Engineer 中标 T9-T10 → 测试 + 基准
→ Recall 0.93 < 0.95 阈值 → Planner 重规划
→ Vxxxxxx-Expert 调整 ef_search 参数 → Recall 0.97
Verifier 验证 S1-S6 → 全部通过
Planner 宣布目标达成，产出 T11 最终报告
```

---

## 六、技术实现要点

### 6.1 自定义索引 AM 必须实现的回调

根据 PostgreSQL 索引 AM 接口规范，核心回调包括：

| 回调 | 职责 |
|------|------|
| `ambuild` | 扫描堆表，构建索引 |
| `aminsert` | 增量插入新元组 |
| `ambulkdelete` | 批量删除（VACUUM 调用） |
| `amvacuumcleanup` | VACUUM 后清理，回收空页 |
| `amcostestimate` | 代价估算，供 Planner 使用 |
| `ambeginscan` / `amrescan` / `amgettuple` | 查询扫描接口 |

### 6.2 xxxx 构建的两阶段策略

xxxxxxx 的 xxxx 构建分两阶段：第一阶段图完全在内存中构建，支持快速邻居更新；第二阶段逐条插入磁盘。如果图能完全放入内存，磁盘阶段可跳过。自定义 AM 的 `ambuild` 应复用此策略。

### 6.3 VACUUM 三阶段回收

xxxx 索引的 VACUUM 需要三阶段：

1. **RemoveHeapTids**：扫描所有页，标记删除的堆 TID
2. **RepairGraph**：修复图连接性，重新连接邻居
3. **MarkDeleted**：标记删除元素，更新版本号

### 6.4 混合搜索的联合下推

xxxxxxx 0.8+ 支持迭代索引扫描（iterative index scan），当 WHERE 条件过滤掉太多 top-k 结果时，继续遍历图直到满足条件。自定义索引应在 `amgettuple` 中实现类似机制：xxxxxx + 标量谓词联合评估，避免“先返回 top-k 再过滤”导致的召回损失。

---


## 七、总结

整个协同过程的核心闭环是：

**目标形式化 → 动态任务图 → 能力市场投标 → 承诺执行 → 独立验证 → 冲突仲裁与重规划 → 全局验收**

Agent 在完成目标前持续自主协调，Planner 只负责生成和更新任务图，不直接分配任务；Agent 通过合同网自主认领；Coordinator 仅在冲突时介入仲裁。

## 八、各 Agent 任务进度与状态查询显示

### 8.1 状态模型

#### Agent 状态

| 状态 | 含义 |
|------|------|
| `idle` | 空闲，可投标 |
| `bidding` | 正在评估/投标 |
| `committed` | 已承诺任务，尚未开始 |
| `working` | 正在执行任务 |
| `waiting` | 等待依赖或资源 |
| `blocked` | 被阻塞，需要协调 |
| `verifying` | 正在验证他人产物 |
| `retrying` | 失败后重试 |
| `done` | 当前任务完成 |
| `offline` | 心跳超时，视为不可用 |

#### 任务状态

| 状态 | 含义 |
|------|------|
| `pending` | 尚未就绪 |
| `ready` | 依赖满足，可发布 |
| `bidding` | 招标中 |
| `assigned` | 已分配，等待承诺 |
| `in_progress` | 执行中 |
| `blocked` | 阻塞 |
| `review` | 等待验证 |
| `verifying` | 验证中 |
| `done` | 验收通过 |
| `failed` | 失败，待重分配 |
| `cancelled` | 取消 |

#### 任务状态机

```mermaid
stateDiagram-v2
  [*] --> pending
  pending --> ready
  ready --> bidding
  bidding --> assigned
  assigned --> in_progress
  in_progress --> blocked
  blocked --> in_progress
  in_progress --> review
  review --> verifying
  verifying --> done
  verifying --> failed
  failed --> ready
  done --> [*]
```

---

### 8.2 黑板状态结构扩展

在原有黑板中增加 `agents`、`task_events`、`metrics`：

```json
{
  "goal": {
    "id": "hybrid-xxxx-index",
    "success_criteria": ["S1", "S2", "S3", "S4", "S5", "S6"],
    "overall_progress": 62,
    "risk": "medium",
    "budget": { "total": 5000, "used": 1200 }
  },
  "agents": {
    "Vxxxxxx-Expert": {
      "status": "working",
      "current_task": "T4",
      "progress": 70,
      "last_heartbeat": "2026-09-10T12:01:03+08:00",
      "eta": "2026-09-10T14:00:00+08:00",
      "load": 0.7,
      "confidence": 0.9,
      "reputation": 0.92,
      "message": "ambuild 内存阶段完成，正在刷盘"
    },
    "Storage-Engineer": {
      "status": "blocked",
      "current_task": "T5",
      "progress": 35,
      "last_heartbeat": "2026-09-10T12:00:58+08:00",
      "blocked_reason": "等待 T3 页布局修订"
    }
  },
  "tasks": {
    "T4": {
      "description": "实现 ambuild",
      "status": "in_progress",
      "owner": "Vxxxxxx-Expert",
      "progress": 70,
      "dependencies": ["T3"],
      "acceptance": ["编译通过", "CREATE INDEX 成功", "EXPLAIN 使用索引"],
      "deadline": "2026-09-15",
      "budget": 500,
      "updated_at": "2026-09-10T12:01:03+08:00"
    },
    "T5": {
      "description": "实现 aminsert",
      "status": "blocked",
      "owner": "Storage-Engineer",
      "progress": 35,
      "dependencies": ["T4"],
      "blocked_reason": "等待 T3 页布局修订"
    }
  },
  "task_events": [
    {
      "time": "2026-09-10T12:01:03+08:00",
      "task_id": "T4",
      "agent_id": "Vxxxxxx-Expert",
      "event_type": "progress",
      "message": "in-memory graph built, flushing pages",
      "progress": 70
    },
    {
      "time": "2026-09-10T12:01:05+08:00",
      "task_id": "T6",
      "agent_id": "Verifier",
      "event_type": "verify_warning",
      "message": "Recall@10=0.93 < 0.95"
    }
  ],
  "metrics": {
    "task_done_rate": 0.27,
    "avg_blocked_minutes": 12,
    "agent_utilization": 0.71,
    "verify_pass_rate": 0.83,
    "recall_at_10": 0.93,
    "build_time_sec": 184,
    "vacuum_reclaimed_mb": 0
  }
}
```

---

### 8.3 查询接口

#### CLI 查询

```bash
# 总览
agentctl status --goal hybrid-xxxx-index

# 所有 Agent 状态
agentctl agents --goal hybrid-xxxx-index

# 单个 Agent 详情
agentctl agent Vxxxxxx-Expert

# 任务列表
agentctl tasks --goal hybrid-xxxx-index
agentctl tasks --status blocked
agentctl tasks --owner Vacuum-Engineer

# 单个任务详情
agentctl task T4

# 实时监听
agentctl watch --goal hybrid-xxxx-index

# 查看任务事件流
agentctl events --task T7 --tail 50
```

#### REST / HTTP 查询

```http
GET /api/goals/{goal_id}/status
GET /api/goals/{goal_id}/graph
GET /api/agents?goal_id=hybrid-xxxx-index
GET /api/agents/{agent_id}
GET /api/tasks?goal_id=hybrid-xxxx-index
GET /api/tasks/{task_id}
GET /api/tasks/{task_id}/events
GET /api/metrics?goal_id=hybrid-xxxx-index

# 实时推送
GET /api/stream?goal_id=hybrid-xxxx-index   # SSE
WS  /ws/status                              # WebSocket
```

#### SQL 查询

```sql
-- 所有 Agent 当前状态
SELECT * FROM v_agent_status;

-- 阻塞任务
SELECT * FROM v_blocked_tasks;

-- 目标整体进度
SELECT * FROM v_goal_progress WHERE goal_id = 'hybrid-xxxx-index';

-- 某任务最近事件
SELECT * FROM task_events
WHERE task_id = 'T7'
ORDER BY created_at DESC
LIMIT 20;
```

---

### 8.4 显示面板设计

#### 总览面板

```text
目标: hybrid-xxxx-index
验收: S1-S6
全局进度: 62%  |  预算: 1200/5000  |  风险: 中
关键路径: T3 -> T4 -> T6 -> T7 -> T9 -> T10 -> T11
当前阻塞: T5 (等待 T3 修订)
最近告警: T6 Recall@10=0.93 < 0.95
```

#### Agent 状态面板

| Agent | 状态 | 当前任务 | 进度 | 心跳 | ETA | 备注 |
|-------|------|----------|------|------|-----|------|
| Planner | idle | - | - | 2s | - | 等待重规划 |
| C-Researcher | done | T1,T2 | 100% | 10s | - | 已交付文档 |
| Vxxxxxx-Expert | working | T4 | 70% | 1s | 2h | ambuild 内存阶段完成 |
| Storage-Engineer | blocked | T5 | 35% | 3s | - | 等待 T3 页布局修订 |
| Query-Engineer | working | T6 | 55% | 1s | 3h | 联合下推实现中 |
| Vacuum-Engineer | retrying | T7 | 40% | 1s | 4h | 图连接修复 |
| Test-Engineer | pending | T9 | 0% | 5s | - | 等待 T6/T7 |
| Verifier | verifying | T4,T6 | 30% | 1s | - | Recall 初测 0.93 |
| Coordinator | idle | - | - | 2s | - | 无未决冲突 |

#### 任务看板

```text
待发布: T8, T9, T10, T11
投标中: -
执行中: T4(70%), T6(55%)
阻塞:   T5(35%, 等待 T3)
验证中: T3(90%), T7(40%, 重试)
已完成: T1, T2
失败:   T7(第一次图连接断裂)
```

#### 任务明细

| 任务 | 状态 | 负责人 | 进度 | 依赖 | 验收 | 阻塞 |
|------|------|--------|------|------|------|------|
| T1 | done | C-Researcher | 100% | - | 文档/证据 | - |
| T2 | done | Vxxxxxx-Expert | 100% | - | 文档/证据 | - |
| T3 | review | Storage-Engineer | 90% | T1,T2 | 页布局评审 | 等待 Verifier |
| T4 | in_progress | Vxxxxxx-Expert | 70% | T3 | CREATE INDEX | 等待 T3 最终版 |
| T5 | blocked | Storage-Engineer | 35% | T4 | 插入测试 | 等待 T3 修订 |
| T6 | in_progress | Query-Engineer | 55% | T3,T4 | 混合查询 | - |
| T7 | retrying | Vacuum-Engineer | 40% | T4,T5 | VACUUM 测试 | 图连接修复 |
| T8 | pending | Query-Engineer | 0% | T6 | 代价估算 | - |
| T9 | pending | Test-Engineer | 0% | T6,T7 | 测试通过 | - |
| T10 | pending | Test-Engineer | 0% | T9 | Recall≥0.95 | - |
| T11 | pending | Planner | 0% | T10 | 最终报告 | - |

#### 事件流

```text
[12:01:03] Vxxxxxx-Expert -> T4 progress 70%: in-memory graph built, flushing pages
[12:01:05] Verifier -> T6 verify warning: Recall@10=0.93 < 0.95
[12:01:06] Planner -> replan: adjust ef_search, rerun T10
[12:01:07] Coordinator -> no conflict; budget ok
```

#### 指标面板

```text
任务完成率:        27%
平均阻塞时长:      12 min
Agent 利用率:      71%
投标命中率:        63%
验证通过率:        83%
Recall@10:         0.93 -> 目标 0.95
构建耗时:          184 s
VACUUM 回收空间:   0 MB
预算消耗:          1200 / 5000
```

---

### 8.5 SQL 实现

#### 表结构

```sql
CREATE TABLE agents (
  id text PRIMARY KEY,
  role text,
  status text,
  current_task text,
  progress numeric DEFAULT 0,
  last_heartbeat timestamptz,
  eta timestamptz,
  load numeric DEFAULT 0,
  confidence numeric DEFAULT 0,
  reputation numeric DEFAULT 0,
  blocked_reason text,
  metadata jsonb
);

CREATE TABLE tasks (
  id text PRIMARY KEY,
  goal_id text,
  description text,
  status text,
  owner text,
  progress numeric DEFAULT 0,
  dependencies text[],
  inputs jsonb,
  outputs jsonb,
  acceptance jsonb,
  deadline timestamptz,
  budget numeric,
  blocked_reason text,
  updated_at timestamptz DEFAULT now()
);

CREATE TABLE task_events (
  id bigserial PRIMARY KEY,
  task_id text,
  agent_id text,
  event_type text,
  message text,
  payload jsonb,
  created_at timestamptz DEFAULT now()
);
```

#### 视图

```sql
CREATE VIEW v_agent_status AS
SELECT
  a.id,
  a.role,
  a.status,
  a.current_task,
  t.description AS current_task_desc,
  a.progress,
  a.last_heartbeat,
  now() - a.last_heartbeat AS heartbeat_age,
  a.eta,
  a.load,
  a.confidence,
  a.reputation,
  a.blocked_reason
FROM agents a
LEFT JOIN tasks t ON t.id = a.current_task;

CREATE VIEW v_task_status AS
SELECT
  t.id,
  t.goal_id,
  t.description,
  t.status,
  t.owner,
  t.progress,
  t.dependencies,
  t.deadline,
  t.budget,
  t.blocked_reason,
  t.updated_at
FROM tasks t;

CREATE VIEW v_blocked_tasks AS
SELECT *
FROM v_task_status
WHERE status IN ('blocked', 'failed')
   OR blocked_reason IS NOT NULL;

CREATE VIEW v_goal_progress AS
SELECT
  goal_id,
  avg(progress) FILTER (WHERE status <> 'cancelled') AS avg_progress,
  count(*) FILTER (WHERE status = 'done') AS done_tasks,
  count(*) AS total_tasks,
  count(*) FILTER (WHERE status = 'blocked') AS blocked_tasks,
  count(*) FILTER (WHERE status = 'failed') AS failed_tasks
FROM tasks
GROUP BY goal_id;
```

---

### 8.6 进度计算与状态更新

#### 任务进度

```text
任务进度 = Σ(子步骤权重 × 子步骤完成度) / Σ(子步骤权重) × 100%
```

例如 T4：

| 子步骤 | 权重 | 完成度 |
|--------|------|--------|
| 内存图构建 | 0.4 | 100% |
| 页刷盘 | 0.3 | 60% |
| 元数据写入 | 0.2 | 30% |
| 自测 | 0.1 | 0% |

```text
T4 进度 = 0.4×1 + 0.3×0.6 + 0.2×0.3 + 0.1×0 = 0.64 = 64%
```

#### Agent 进度

```text
Agent 进度 = 当前任务进度
```

#### 全局进度

推荐按关键路径加权：

```text
全局进度 = Σ(关键路径任务权重 × 任务进度) / Σ(关键路径任务权重)
```

非关键路径任务只影响风险，不影响主进度。

#### 心跳与超时

```text
last_heartbeat < now() - 30s   -> suspect
last_heartbeat < now() - 120s  -> offline，任务重分配
blocked 状态超过 15min         -> Coordinator 介入
验证连续失败 2 次              -> Planner 重规划
预算消耗 > 80% 且进度 < 60%    -> 升级人类
```

---

### 8.7 告警与人类干预

| 规则 | 动作 |
|------|------|
| Agent 心跳超时 | 标记 suspect/offline，任务重新招标 |
| 任务阻塞超时 | Coordinator 仲裁或重分配 |
| Recall 低于阈值 | Planner 重规划，调整 ef_search 或索引参数 |
| VACUUM 后查询质量下降 | 回滚策略，重新修复图连接 |
| 预算超限 | 暂停低优先级任务，升级人类 |
| 冲突未决 | 投票、辩论或人类仲裁 |

人类干预接口：

```http
POST /api/tasks/{task_id}/intervene
POST /api/agents/{agent_id}/pause
POST /api/goals/{goal_id}/cancel
POST /api/goals/{goal_id}/approve
```

---

### 8.8 与多 Agent 协议集成

状态查询依赖以下结构化消息：

```text
heartbeat       Agent 心跳
status          Agent 总体状态
progress        任务进度更新
blocked         任务阻塞
request_help    请求协助
bid             投标
award           中标
commit          承诺
verify          验证结果
fail            失败
replan          重规划
escalate        升级人类
```

每次消息写入 `task_events` 和黑板，Dashboard 通过 SSE/WebSocket 实时刷新。

---

### 8.9 技术选型建议

| 能力 | 可选方案 |
|------|----------|
| 终端显示 | Rich、Textual、blessed |
| Web 面板 | React + WebSocket、Grafana |
| 实时推送 | SSE、WebSocket |
| 状态存储 | PostgreSQL JSONB、Redis Stream |
| 指标 | Prometheus + Grafana |
| 追踪 | OpenTelemetry |
| 日志 | 结构化 JSON |
| 图可视化 | Mermaid、Cytoscape、D3 |

---

### 8.10 示例：查询 T7 VACUUM 任务状态

```bash
$ agentctl task T7

任务: T7
描述: 实现 ambulkdelete / amvacuumcleanup
状态: retrying
负责人: Vacuum-Engineer
进度: 40%
依赖: T4, T5
验收: VACUUM 前后查询质量不下降；磁盘空间回收
阻塞: 图连接修复中
最近事件:
  [11:42:10] fail: 图连接断裂，Recall 下降至 0.71
  [11:45:22] replan: 增加辅助页存储 neighbors
  [11:58:03] progress 40%: RepairGraph 阶段实现中
  [12:01:07] Coordinator: 无冲突，预算正常
```

```bash
$ agentctl agent Vacuum-Engineer

Agent: Vacuum-Engineer
状态: retrying
当前任务: T7
进度: 40%
心跳: 1s 前
ETA: 4h
负载: 0.8
置信度: 0.78
信誉: 0.81
备注: 图连接修复中，等待 T5 插入路径稳定
```

---

## 九、更新后的协同闭环

```text
目标形式化
  -> 动态任务图
  -> 能力市场投标
  -> 承诺执行
  -> 状态/进度实时写入黑板
  -> 查询与显示 Dashboard
  -> 独立验证
  -> 冲突仲裁与重规划
  -> 全局验收
```

其中，**状态查询与显示**不是附属功能，而是自主协调的反馈回路：  
Agent 通过查询黑板决定是否投标、是否等待、是否请求帮助；  
Planner 通过全局进度决定是否重规划；  
Coordinator 通过阻塞和冲突视图决定是否仲裁；  
人类通过 Dashboard 决定是否干预。

 让ai自动化开发的流程：

（1）生成需求文档并进行评审

（2）生成设计文档并进行评审、调整

（3）生成开发规约文档和验证脚本

（4）登记任务到共享任务看板并记录进度.任务必须有形式化目标和可验收标准  

（5）创建持续任务目标，自动挑选下一个 ready 任务推进