> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# AI Agent Foundation 最终态与当前缺口

> **Superseded / Historical（2026-07-15）**：本文包含已漂移的 live-table 和 Objective-first 假设，不再作为当前/最终态 source of truth。Task runtime、read tools、bounded reasoning loop 与 authority 以 [Task System Design](/product-design/v3/tasks-feature/task-domain-lifecycle.md) 为准；其他 AI foundation 能力实施前必须重新 code-audit。

## 0. 一句话判断

retaintive 现在已经有一部分 AI foundation：`contacts-analyzer`、production prompt、Zod schema、Task Orchestrator、Policy Guard、tasks/progress/suggestions/playbooks 表都在。Task Accuracy Baseline v1 也已经有第一版 executable foundation：57 个 golden eval scenario、11 个 DB replay case、以及 Task Detail 里的 task progress timeline。

但它还不是完整的自动 AI employee foundation。现在缺的是：

- investor demo 用的稳定 demo pack 和 operator guide。
- voicemail / firm rejection 等 known gap hardening。
- `unable_to_reach` threshold 的 deterministic writer policy。
- task objective / issue 抽象层。
- approval queue。
- agent execution log。
- LLM Gateway / usage metering。
- Vapi / outbound execution 接入。
- feedback loop 真正回流到 prompt/context/playbook。

所以 demo 前的正确目标不是“把终态全做完”，而是先做 **Task Accuracy Foundation**：证明 AI 能稳定决定任务，并且写库安全。

## 1. 现在我们有什么

```text
当前态：我们已经有一条 task intelligence pipeline

┌────────────────────────────────────────────┐
│ 1. 业务事实 Facts                           │
│                                            │
│ contacts / calls / messages / leads        │
│ tasks / task_progress_events               │
│ task_suggestions / task_playbooks           │
│ contact_timeline                            │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 2. AI 判断入口                              │
│                                            │
│ contacts-analyzer                           │
│ production prompt                           │
│ ContactsAnalysisSchema                      │
│ taskDecisions[]                             │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 3. 写库安全层                               │
│                                            │
│ resolve taskRef T1/T2                       │
│ writeAnalysisWithTasks()                    │
│ applyTaskAction()                           │
│ Policy Guard                                │
│ DB constraints                              │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 4. 产品表面                                 │
│                                            │
│ Studio UI tasks                             │
│ suggestions                                 │
│ playbook tab                                │
│ timeline / audit pieces                     │
└────────────────────────────────────────────┘
```

当前已经不错的部分：

| Layer              | 当前状态                                                                                        | 评价                          |
| ------------------ | ------------------------------------------------------------------------------------------- | --------------------------- |
| Task SSoT          | `tasks` 已是行动项主表                                                                             | 可用                          |
| Task state machine | `open / closed` + `create_open / create_closed / close / update / record_progress / reopen` | 可用，但 eval 不够                |
| Policy Guard       | DNC、duplicate、store-match、type allowlist、confidence、stale proposal 等                        | 方向对                         |
| Progress events    | `task_progress_events` 拆出 process facts                                                     | 方向对                         |
| Suggestions        | `task_suggestions` append-only                                                              | 已为 feedback / provenance 留口 |
| Playbooks          | `task_playbooks` current/stale/superseded                                                   | 可作为未来 agent context         |
| Golden eval        | 已有真实模型 eval runner                                                                          | 需要扩容                        |

## 2. 现在还缺什么

| 缺口                   | 为什么重要                                                   | Demo 前 / Demo 后 |
| -------------------- | ------------------------------------------------------- | --------------- |
| Scenario registry    | 没有系统化 expected decision，无法判断 prompt 准不准                 | Demo 前          |
| Golden eval coverage | 现有 case 太少，不能证明稳定性                                      | Demo 前          |
| DB replay harness    | golden eval 不验证 writer / policy / constraints           | Demo 前选 8-12 个  |
| Known gap tracking   | 不稳定 case 不能混进 demo                                      | Demo 前          |
| Objective layer      | `typeCategory` 偏健身房语义，跨行业不够抽象                           | Demo 后          |
| Approval queue       | AI 外呼 / 发消息前必须有人审                                       | Demo 后          |
| Agent execution log  | Vapi agent 做了什么需要审计、回放、归因                               | Demo 后          |
| LLM Gateway          | 模型路由、降级、缓存、cost attribution 需要统一出口                      | Demo 后          |
| Usage metering       | 未来 package + usage 收费必须 per-client 计量                   | Demo 后          |
| Feedback loop        | 历史对话 / staff reaction / close outcome 还没系统喂回 AI context | Demo 后          |

## 3. Task Accuracy Foundation 是什么

Task Accuracy Foundation 是“自动执行之前的地基”。它不是一个 UI，也不是一个 prompt 文件，而是一套可回归的验证系统：

```text
Task Accuracy Foundation 最终态

┌────────────────────────────────────────────┐
│ Scenario Registry                           │
│                                            │
│ 中文业务场景                                 │
│ structured input context                    │
│ structured expected decision                │
│ sourceOfRule / knownGap / priority          │
└───────────────┬────────────────────────────┘
                │
                ├───────────────────────────────────────┐
                │                                       │
                ▼                                       ▼
┌──────────────────────────────┐        ┌──────────────────────────────┐
│ Golden Eval                   │        │ DB Replay                     │
│                              │        │                              │
│ production prompt             │        │ seed processed rows            │
│ production Zod schema         │        │ run writer / Policy Guard      │
│ real model                    │        │ assert persisted rows          │
└───────────────┬──────────────┘        └───────────────┬──────────────┘
                │                                       │
                └───────────────────┬───────────────────┘
                                    ▼
┌────────────────────────────────────────────┐
│ Verdict                                    │
│                                            │
│ pass: demo candidate                        │
│ fail: fix prompt / policy / schema          │
│ xfail: known gap, record GitHub issue       │
└───────────────┬────────────────────────────┘
                │
                ▼
┌────────────────────────────────────────────┐
│ Demo Pack                                  │
│                                            │
│ 只展示连续稳定通过的 case                    │
│ 不现场赌模型随机性                           │
└────────────────────────────────────────────┘
```

做完以后，团队应该可以回答：

- 这个 scenario 为什么应该 `create_open`，不是 `no-op`？
- 这个 outbound call 为什么是 `record_progress`，不是 `close`？
- 这个 customer rejection 为什么是 `not_interested`，不是 DNC？
- AI 如果编 `taskId`，系统会不会真写库？
- 没有触发通话证据时，contacts-analyzer writer 会不会跳过 `create_closed`？
- duplicate open task 是否被 DB unique index 挡住？
- accepted mutation 是否产生 suggestion / playbook artifact？

### 它在 AI 基座里属于哪一层

Task Accuracy Foundation 不是第 7 层，也不是一个独立业务产品。它是一套横跨 **AI 判断层、控制层、执行层** 的质量保证系统。

```text
通用 AI 基座

1. Facts / 业务事实
   calls / SMS / leads / contacts / tasks

2. Objective + Context / 目标与上下文
   当前有哪些候选目标、open task、history、policy constraints

3. AI Decision / AI 判断层
   production prompt + model + structured output schema
          ▲
          │  Golden Eval 验证这里：AI 判断准不准
          │

4. Control Plane / 安全控制层
   Policy Guard / DNC / duplicate / store isolation / approval
          ▲
          │  DB Replay 验证这里：危险 mutation 是否被挡住
          │

5. Execution / 执行层
   create / close / update / record_progress / future Vapi / SMS
          ▲
          │  DB Replay 验证这里：writer 是否真的安全落库
          │

6. Feedback / 结果回流
   closeResult / progress events / staff feedback / business outcome
```

所以它的定位是：

- `AI Decision Assurance`：证明模型输出的 `taskDecisions[]` 对不对。
- `Control Plane Assurance`：证明 Policy Guard 没有漏掉 DNC、duplicate、forbidden create、store mismatch。
- `Execution Assurance`：证明 writer / DB constraints 真能保护 production data。

它不是用户每打开页面才跑。它应该在这些时机触发：

| 触发时机                                       | 跑什么                        | 为什么                               |
| ------------------------------------------ | -------------------------- | --------------------------------- |
| 改 prompt / schema / task policy 前后         | Golden Eval                | 防止 AI decision 回归                 |
| 改 writer / Policy Guard / DB constraint 前后 | DB Replay                  | 防止危险 mutation 漏进 DB               |
| Demo 前                                     | Golden Eval + 关键 DB Replay | 只展示稳定 case，不现场赌模型随机性              |
| CI / nightly                               | Golden Eval 子集或全量          | 长期监控模型和 prompt 漂移                 |
| Production event 到来时                       | Runtime Policy Guard       | 不跑完整 eval，但每次 mutation 都必须过 guard |

### 未来会有一组 Accuracy Foundations

Task Accuracy 不是唯一的 accuracy foundation。长期我们会有 Call / Contact / Task / Agent Execution 多个 accuracy harness，但它们不应该各自长出一套孤立基座。正确方向是：**共享 AI Foundation，按不同输出面挂不同 accuracy harness**。

```text
共享 AI Foundation（厚底座）

┌────────────────────────────────────────────────────────┐
│ Facts / Source of Truth                                │
│ calls / messages / leads / contacts / tasks / outcomes │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ Context Builder                                         │
│ 把 DB facts 组装成模型可读、可追溯、可测试的 context      │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ Tenant / Vertical Taxonomy Registry                     │
│ 健身房、医疗、fraud、BPO 等行业各自有 category pack       │
│ 值来自 common schema / taxonomy，不在 prompt 手写第二份   │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ LLM Gateway + Structured Output                         │
│ model routing / prompt version / Zod schema / metering  │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ Deterministic Canonicalizer + Policy Guard              │
│ enum 校验、category 反推、store_id isolation、DNC、审批   │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ Eval / Replay / Observability                           │
│ golden eval、DB replay、prompt snapshot、runtime audit   │
└──────────────────────────┬─────────────────────────────┘
                           │
        ┌──────────────────┼──────────────────┬──────────────────┐
        ▼                  ▼                  ▼                  ▼
┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ Call Accuracy│   │Contact       │   │Task Accuracy │   │Agent Exec    │
│ Harness      │   │Accuracy      │   │Harness       │   │Accuracy      │
│              │   │Harness       │   │              │   │Harness       │
│ transcript   │   │contact state │   │task decision │   │approved run  │
│ -> call facts│   │/ context     │   │/ mutation    │   │/ outcome     │
└──────────────┘   └──────────────┘   └──────────────┘   └──────────────┘
```

所以这里有两个不同层面的关系：

```text
数据依赖关系（业务上游/下游）

Transcript
  -> Call Analysis
  -> Contact State / Intent
  -> Task Decision
  -> Policy Guard / Writer
  -> Agent Execution
  -> Business Outcome
```

```text
工程资产关系（底座复用）

Shared context / taxonomy / schema / canonicalizer / policy / eval
  -> Call Accuracy Harness
  -> Contact Accuracy Harness
  -> Task Accuracy Harness
  -> Agent Execution Accuracy Harness
```

如果 Call Analysis 把“我要取消”理解错，Contact 状态和 Task 决策都会跟着错。所以 demo 前后要补 Call Accuracy 和 Contact Accuracy。但这不是另外造两个“基座”，而是在同一个 AI Foundation 上加两个 upstream harness。demo 前先做 Task Accuracy，是因为它最接近现在要展示的价值：AI 能不能把已有业务 context 变成正确、可控、可写库的 task decision。

## 4. 最终态应该长什么样

借鉴另一份 AI Agent 架构方案，retaintive 的长期方向也是：**底座厚，Skill 薄**。

也就是说，不要每个功能都重新写一套 AI 流程。底座统一做 context、LLM、policy、approval、execution、metering、feedback；上层不同 skill 只定义业务目标。

先把现状和目标态分清楚：

| 层                                      | 现在 production 里有什么                                                                                                         | 最终态想补什么                                                         |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| 2. Objective Catalog + Context Builder | 没有独立 `task_objectives` / `task_issues` 表；现在主要是 `tasks.typeCategory` + `prompt-builder` 里的 open task / recent event context | 独立 objective / issue 抽象，把“想达成什么、怎么算成功、什么时候停止”从健身房 category 里抽出来 |
| 3. AI Decision Layer                   | `contacts-analyzer` + production prompt + `ContactsAnalysisSchema`                                                         | LLM Gateway、model routing、usage metering、持续 eval / replay       |

所以第 2 层在下面的图里是 **target state**，不是说现在已经有一张 production objective catalog 表。

```text
通用 AI 基座最终态：任何行业都能复用

┌────────────────────────────────────────────┐
│ 1. 业务事实 Facts                           │
│                                            │
│ 客户、事件、订单、合同、对话、任务、结果       │
│ 只负责记录真实发生了什么                     │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 2. 目标目录 + 上下文构建（目标态）            │
│ Objective Catalog + Context Builder         │
│                                            │
│ 不是 AI 最终判断                             │
│ 而是把“可能要完成什么”和“证据是什么”整理好     │
│                                            │
│ 当前：typeCategory + prompt-builder context │
│ 未来：task_objectives / task_issues          │
│                                            │
│ objective candidates                        │
│ customer / account context                  │
│ policy context                              │
│ history / suggestions / playbooks           │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 3. AI 判断层 AI Decision Layer              │
│                                            │
│ LLM Gateway                                 │
│ prompt / model routing                      │
│ structured output schema                    │
│ eval / replay                               │
│ usage metering                              │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 4. 控制层 Control Plane                     │
│                                            │
│ Policy Guard                                │
│ approval queue                              │
│ DNC / operating hours / tenant policy       │
│ agent execution log                         │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 5. 执行层 Skills & Execution                │
│                                            │
│ voice call / SMS / email                    │
│ human handoff                               │
│ workflow automation                         │
│ 每个 skill 只做薄薄一层业务动作              │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 6. 结果回流 Feedback Loop                   │
│                                            │
│ conversion / retention / fraud result       │
│ staff feedback                              │
│ transcript / outcome / cost                 │
│ 下一轮 context 和 playbook 从这里改进         │
└────────────────────────────────────────────┘
```

### 六层各管一件事

| 层                                      | 职责                                    | retaintive 里的对应                                            |
| -------------------------------------- | ------------------------------------- | ---------------------------------------------------------- |
| 1. Facts                               | 事实从哪里来                                | calls、messages、leads、contacts、tasks、progress、timeline      |
| 2. Objective Catalog + Context Builder | AI 判断前先整理候选目标和证据                      | future `task_objectives` / `task_issues` + context pack    |
| 3. AI Decision Layer                   | 模型调用、prompt、structured output、eval、计量 | `contacts-analyzer`、LLM Gateway、golden eval                |
| 4. Control Plane                       | 什么动作被允许、谁审批、如何审计                      | Policy Guard、approval queue、agent logs                     |
| 5. Skills & Execution                  | 具体业务动作                                | follow-up、retention、Vapi call、SMS draft                    |
| 6. Feedback Loop                       | 结果如何反哺下一轮判断                           | close outcome、staff feedback、conversion / retention result |

两个枢纽必须做厚：

- `LLM Gateway`：所有模型调用统一出口，才能做 routing、fallback、cache、cost tracking、prompt versioning。
- `Approval + Policy`：所有外部触达前必须过 policy 和 human approval，尤其是电话 / SMS / Email。

### Interface Contract / 操作面放在哪里

API / CLI / MCP 不应该理解成第 7 层，也不应该理解成另一个业务逻辑层。它们是 **外部系统、人、agent 使用 AI 基座的受控入口**。

六层回答的是：

```text
内部能力怎么运转？

Facts
  -> Objective / Context
  -> AI Decision
  -> Control Plane
  -> Execution
  -> Feedback
```

Interface Contract 回答的是：

```text
外部入口怎么安全使用这些能力？

Dashboard / Lark / Codex / Botmux / Vapi / external AI client
  -> API / OpenAPI contract
  -> generated internal client
  -> thin CLI / MCP tool schema / product UI action
  -> Control Plane
  -> Domain service / Task Orchestrator
  -> Facts write or approved Execution
  -> Feedback Loop
```

不要这样理解：

```text
CLI / MCP / Vapi
  -> directly update DB
  -> directly call customer
  -> directly bypass policy
```

应该这样理解：

```text
任何入口都只能提交受控请求
  -> auth / store_id isolation / scope
  -> DNC / operating hours / duplicate / stale proposal guard
  -> approval when outbound action affects customer
  -> audit log / usage event
  -> then execute
```

所以 API / CLI / MCP 的位置是：

```text
┌────────────────────────────────────────────┐
│ AI Foundation 六层                          │
│                                            │
│ Facts / Context / AI Decision               │
│ Control Plane / Execution / Feedback        │
└──────────────────────┬─────────────────────┘
                       │ capabilities are exposed through
                       ▼
┌────────────────────────────────────────────┐
│ Interface Contract / 操作面                 │
│                                            │
│ API: 受控业务能力入口                        │
│ OpenAPI: 机器可读合同                        │
│ Internal client: CLI / test / agent 复用     │
│ Thin CLI: Codex / Botmux / CI 可操作         │
│ MCP / Tool schema: 外部 AI client 可调用     │
│ Skill: 告诉 agent 应该怎么用这些能力          │
└────────────────────────────────────────────┘
```

Demo 前不需要把所有 endpoint 设计完。现在只需要把原则写清楚：**业务规则收口在 service / Orchestrator / Control Plane；API / CLI / MCP 只是受控入口，不能复制业务规则，也不能绕过安全层。** 具体 API spec 应该单独开后续设计文档或 GitHub issue。

### 套到 retaintive：我们最终应该这样搭

```text
retaintive AI 基座最终态：以 task 为中心

┌────────────────────────────────────────────┐
│ 1. 业务事实                                 │
│                                            │
│ calls / messages / leads / contacts / tasks│
│ task_progress_events / task_suggestions    │
│ task_playbooks / contact_timeline          │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 2. 任务目标上下文（目标态）                  │
│ Objective Catalog + Context Builder         │
│                                            │
│ 当前 production：                            │
│ tasks.typeCategory + prompt-builder          │
│                                            │
│ 未来目标：                                  │
│ 例子：lead_follow_up                        │
│ objective: 让客户预约 intro class           │
│ desiredOutcome: 客户确认具体时间            │
│ success: closeResult = booked              │
│ failure: not_interested / unable_to_reach   │
│ evidence: 最近 call/SMS/voicemail/task      │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 3. AI 判断层                                │
│                                            │
│ contacts-analyzer                           │
│ production prompt                           │
│ ContactsAnalysisSchema                      │
│ taskDecisions[]                             │
│ golden eval / DB replay                     │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 4. 安全控制层                               │
│                                            │
│ resolve taskRef T1/T2                       │
│ applyTaskAction()                           │
│ Policy Guard                                │
│ DNC guard                                   │
│ duplicate guard                             │
│ store_id isolation                          │
│ approval before outbound                    │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 5. 执行动作                                 │
│                                            │
│ 现在：create / close / update / progress task│
│ 未来：AI agent 根据 approved playbook 打电话   │
│      Vapi call / SMS draft / manager handoff │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 6. 结果回流                                 │
│                                            │
│ task_progress_events                        │
│ closeResult                                 │
│ call transcript                             │
│ staff feedback                              │
│ conversion / retention result               │
│ 这些再进入下一轮 AI context                  │
└────────────────────────────────────────────┘
```

这里最容易混的是第 2 层和第 3 层：

| 问题                 | 第 2 层：Objective Catalog + Context Builder | 第 3 层：AI Decision Layer                           |
| ------------------ | ----------------------------------------- | ------------------------------------------------- |
| 它是不是 AI 最终判断？      | 不是                                        | 是                                                 |
| 它做什么？              | 整理候选目标、现有任务、证据、限制条件                       | 判断这次应该 create / close / update / progress / no-op |
| 没有 open task 时怎么办？ | 给 AI 候选目标和证据，比如 lead 可能想预约                | AI 判断是否真的要 `create_open`                          |
| 有 open task 时怎么办？  | open task 已经提供 objective                  | AI 判断最新证据是否推进或结束这个 objective                      |
| 为什么不能合并？           | 合并后 context 不稳定，难复用、难评估                   | 分层后 prompt/eval/policy 可以独立改                      |

## 5. 现在 vs 最终态

| 能力                   | 现在                                 | 最终态                                                   | 还差什么                                |
| -------------------- | ---------------------------------- | ----------------------------------------------------- | ----------------------------------- |
| Task decision        | AI 输出 `taskDecisions[]`            | 有 scenario registry + eval + replay 持续验证              | Task Accuracy Baseline v1           |
| Task mutation safety | `applyTaskAction()` + Policy Guard | 所有 human/system/AI/agent 都走同一入口                       | DB replay +更多 guard tests           |
| Task category        | `typeCategory` 健身房语义               | `objectiveType` 或 `task_objectives/task_issues` 支撑跨行业 | schema design                       |
| Suggestions          | append-only `task_suggestions`     | staff feedback / close outcome 反哺建议质量                 | feedback analytics                  |
| Playbooks            | `task_playbooks` 可生成执行建议           | agent / staff 共用 execution playbook                   | quality eval + tenant playbook pack |
| Approval             | 还不是统一产品层                           | draft/edit/approve/reject/expire state machine        | approval queue                      |
| Agent execution      | 还没有 Vapi agent run SSoT            | 每次 call attempt 有 run log、transcript、outcome、cost     | `agent_runs` / `agent_actions`      |
| Usage metering       | 分散或未成体系                            | per-client package + usage + quota + cost attribution | LLM Gateway + usage events          |
| Context improvement  | 有 history 和 artifacts，但未闭环         | 历史对话、feedback、close outcome 自动改进 context pack         | feedback loop                       |
| Lark surface         | 可以用 Lark doc/card 做 review         | Lark approval / daily report / eval report 成为运营入口     | Lark integration polish             |

## 6. `objective / desiredOutcome / businessGoal` 是什么意思

当前 `tasks.typeCategory` 回答的是：

> 这个 task 属于哪个业务桶？

例如：

- `lead_follow_up`
- `cancellation_risk`
- `retention`
- `renewal`

但未来 AI agent 真正需要知道的是：

> 这次联系客户到底想达成什么结果？什么算成功？什么算失败？什么时候应该停止？

这就是 `objective / desiredOutcome / businessGoal` 的意义。

| 当前 category            | Objective            | Desired outcome               | Success criteria       |
| ---------------------- | -------------------- | ----------------------------- | ---------------------- |
| `lead_follow_up`       | 预约 first intro class | 客户确认具体时间                      | `close booked`         |
| `booked_not_converted` | 转成 paying member     | 客户购买 membership               | `close converted`      |
| `cancellation_risk`    | 挽留取消客户               | 客户同意留下 / freeze / downgrade   | `close cancel_saved`   |
| `retention`            | 解决投诉                 | 客户确认问题解决                      | `close issue_resolved` |
| `renewal`              | 恢复连续付费               | card fixed / renewal restored | `close renewed`        |

长期看，`typeCategory` 仍然可以保留为 UI / reporting taxonomy，但 agent context 最好再有 objective 层。

## 7. 现在要不要改 DB schema

建议：demo 前不要改。

原因：

- Task Accuracy Baseline v1 不依赖 schema migration。
- `tasks`、`task_progress_events`、`task_suggestions`、`task_playbooks` 已经够支撑 demo。
- 现在改 schema 会牵动 writer / API / UI / migration / tests，风险高。
- 我们还没有通过 scenario registry 验证哪些 objective pattern 是真的高频。

Demo 后再做一个正式设计 issue，比较：

| 方案                                                               | 优点                                  | 风险                               |
| ---------------------------------------------------------------- | ----------------------------------- | -------------------------------- |
| 在 `tasks` 加 nullable `objective / desiredOutcome / businessGoal` | 简单、查询方便                             | 一 task 多 issue 会 messy；跨行业抽象有限   |
| 新增 `task_objectives`                                             | 更通用，适合 AI agent                     | schema / UI / writer 复杂          |
| 新增 `task_issues`                                                 | 和 `task_suggestions.issueId` 预留方向一致 | 偏问题/阻塞，不一定覆盖所有 revenue objective |

我的倾向：先设计 `task_objectives` + `task_issues` 的组合，等 Task Accuracy Baseline v1 跑出真实 scenario 后再决定，不要现在硬拍。

## 8. Demo 前路线图

```text
Demo 前两天优先级

Day 1
  -> Scenario registry 初版
  -> P0 / P1 expected decision review
  -> DB replay 选 8-12 个关键 case
  -> knownGap 标记规则确定

Day 2
  -> Golden eval expansion
  -> 修最影响 demo 的 prompt / policy gap
  -> 关键 DB replay 跑通
  -> Demo pack 只保留稳定通过 case

不能混进 demo：
  -> 需要赌模型随机性的 case
  -> 还没有 writer / policy 证明的高风险 mutation
  -> Vapi 自动外呼
  -> 自动发 SMS
```

Demo 前必须完成：

- Scenario registry 初版。
- P0 / P1 expected decision review。
- Golden eval case expansion。
- 已知不稳定 case 标 `knownGap`。
- DB replay 选 8-12 个关键 case。
- Demo pack 只展示稳定通过的 case。

Demo 前不建议做：

- Vapi 接入。
- 自动发 SMS。
- 完整 approval queue。
- LLM Gateway 重构。
- task objective schema migration。

## 9. Demo 后路线图

```text
Demo 后演进顺序

Baseline v1 stable
  -> Objective / issue schema design
  -> Approval queue
  -> Agent execution log
  -> Vapi voice pilot
  -> Usage metering + LLM Gateway
  -> Feedback loop

为什么这个顺序：
  先证明 AI 判断准
  再定义 objective / issue 的长期 schema
  再加 approval 和 agent run audit
  最后接真正自动外呼和计费闭环
```

第二批建议：

| Milestone           | 产出                                                                    |
| ------------------- | --------------------------------------------------------------------- |
| Objective design    | `task_objectives` / `task_issues` proposal，覆盖健身房 + 非健身房例子             |
| Approval queue      | draft / edit / approve / reject / expire 状态机                          |
| Agent execution log | `agent_runs`、`agent_actions`、call attempt、transcript、cost、outcome     |
| Vapi pilot          | 只对低风险 task + approved script 做 outbound                               |
| LLM Gateway         | prompt version、model routing、usage event、per-client quota             |
| Feedback loop       | close outcome + staff reaction + conversation history 改进 context pack |

## 10. 你现在还差多少

粗略判断：

| Area                            | 完成度判断 | 说明                                                     |
| ------------------------------- | ----- | ------------------------------------------------------ |
| Task data model                 | 中高    | tasks/progress/suggestions/playbooks 已有，但 objective 层缺 |
| Safe mutation architecture      | 中高    | Orchestrator + Policy Guard 方向对，需要 DB replay 证明        |
| AI decision accuracy            | 中     | prompt/schema 有了，scenario/eval 覆盖还不够                   |
| Demo readiness                  | 中     | 只要聚焦稳定 case，两天内可做出可信 demo                              |
| Voice agent readiness           | 低     | 缺 approval、agent log、execution policy、Vapi integration |
| AI foundation commercialization | 中低    | 缺 LLM Gateway、usage metering、quota、billing attribution |

最重要的补充判断：

> 你现在不是“从 0 开始做 AI foundation”。你已经有一条 task intelligence pipeline。接下来要做的是把它从“能跑”升级成“可证明准确、可安全执行、可持续学习、可计费”。

这就是为什么 Task Accuracy Baseline v1 是当前最好的切入点。