#AI Objective / Evidence 数据模型目标态

Superseded for Task domain（2026-07-15）：本文的 Objective-first / Task-as-action 模型未被采用。Task 领域不新增 Objective/Case 层，现行 contract 是 Task / Next Action / Activity / Outcome；见 Task System Design。本文仅保留为历史 exploration。

Date: 2026-06-25 Status: Draft Scope: objective 数据模型、客户可见 sources、AI decision ledger、tool execution、registry、从 task-first 到 objective-first 的演进路线

#0. 一句话判断

retaintive 长期不应该只是“AI 生成 task”。它应该是一台 Evidence-backed Revenue Objective Engine：

call / SMS / voicemail / lead / CRM / policy / regulation / web signal
  -> evidence
  -> AI proposal
  -> policy decision
  -> objective
  -> task / approval / automation / outcome

task 是执行动作，objective 才是客户愿意付钱的业务对象。

客户真正要买的不是“有 AI”，而是：

• 哪些客户现在有 revenue opportunity 或 revenue risk。
• 为什么系统这么判断，有哪些 source。
• 谁应该处理，什么时候处理，逾期了没有。
• 处理以后是否真的产生 outcome。
• 对 VIP、高价值客户、合规敏感场景，系统有没有更高等级的保护和升级机制。

所以数据库不要设计成“存一个 AI 返回的大 JSON”。应该设计成：

Typed core schema
  + versioned registry
  + JSONB details
  + append-only ledger
  + external trace/artifact pointer

固定 schema 负责产品、权限、查询、计费、审计；开放式 JSONB 负责模型细节和未来扩展。两者缺一不可。

#1. 先定边界：AI 输出不是一种数据

AI 输出看起来千奇百怪，但落库时要先分成三类。

最重要的原则：

客户页面永远读 normalized product state，不要直接读 raw AI output。

raw output 可以保留，但它不是产品契约。产品契约必须是稳定的 typed schema。

#2. Fixed schema 和 flexible schema 怎么取舍

不要在 “全 fixed schema” 和 “全 JSONB” 之间二选一。正确答案是 hybrid。

#2.1 必须 fixed 的东西

这些字段会被权限、列表、筛选、排序、报表、计费、SLA、通知和审计依赖，所以必须是 typed columns 或 typed enum：

• tenant_id / store_id
• customer_ref / contact_phone
• objective_id
• objective_type
• status
• priority
• confidence_band
• risk_level
• estimated_value_band
• owner_type / owner_id
• due_at
• created_at / updated_at
• source_visibility
• decision_status
• approval_status
• execution_status
• idempotency_key
• trace_id / ai_run_id

这些字段不能只藏在 JSONB 里。否则以后会出现三个问题：

1. 列表页查不快。
2. 权限和隔离容易漏。
3. 数据分析和计费会变成解析半结构化垃圾。

#2.2 可以 flexible 的东西

这些内容变化快、行业差异大、还在探索期，适合放 jsonb：

• objective 的行业专属 detail。
• AI reasoning 的结构化片段。
• tool result 摘要。
• policy evaluation 的 extra context。
• source-specific metadata。
• 实验性字段。
• 模型输出的原始 normalized proposal。

但 JSONB 也要有规矩：

• 必须有 schema_version。
• 必须有 producer。
• 必须有 visibility。
• 高频查询字段要提升成 typed column 或 expression index。
• 不把 secret、完整 prompt、完整客户隐私文本随便塞进去。

PostgreSQL 的 jsonb 支持 GIN index 和 containment 查询，适合半结构化扩展；但它不是替代 relational schema 的理由。官方文档也把 jsonb indexing 描述为对 key / key-value / jsonpath 查询的加速能力，而不是“所有字段都进 JSONB”的建议。

#3. 目标数据模型

最终态可以分成八组表。名字可以调整，但职责边界不要混。

#3.1 Signal / Evidence 层

这一层记录“系统看到了什么”。

evidence_items
knowledge_sources
knowledge_chunks

evidence_items 是统一证据表。它可以指向 call、SMS、voicemail、lead、CRM event、policy doc chunk、regulation doc chunk、web result、manual note。

核心字段：

这张表是 Perplexity-style sources 的地基。但它不是 trace table。它存的是业务证据，不是 prompt 和 token。

#3.2 Objective 层

这一层记录“系统认为应该达成什么”。

objectives
objective_sources
objective_events

objectives 是未来最重要的主表。它比 tasks 更接近客户价值。

核心字段：

objective_sources 是 objective 到 evidence 的引用关系：

objective_events 是 append-only lifecycle stream：

created
accepted
assigned
task_created
progress_recorded
escalated
approved
rejected
closed
reopened
outcome_recorded

它回答“这个 objective 怎么一路走到现在”。

#3.3 Task 层

tasks 继续存在，但定位改变：

task 是实现 objective 的一个具体 action。

一个 objective 可以有多个 task：

• 给客户回电话。
• 发 pricing options。
• manager review。
• 等待 CRM sync。
• 安排 VIP follow-up。
• 让 AI 草拟短信但先等人工批准。

目标态关系：

objectives 1 -> N tasks
tasks N -> N evidence_items through task_sources

现有 task_sources 继续保留。短期内不要把它删掉或替换，因为它已经承担 accepted task provenance。未来可以让它引用 evidence_items，而不是只引用原始 call/message/lead id。

#3.4 Decision Ledger 层

这一层记录“AI 想做什么，系统最后怎么裁决”。

decision_attempts

它应该覆盖 task proposal 和 objective proposal，而不是只覆盖 task：

这层补的是当前最危险的黑洞：AI 提了，但最后没出现在页面上。

客户一般不直接看 decision_attempts。但客户可见解释可以从这里派生：

• “这个建议被创建，因为它引用了这些 sources。”
• “这个建议没有自动执行，因为需要 manager approval。”
• “这个建议被系统拒绝，因为客户是 DNC。”

#3.5 Tool Execution 层

未来 read-only tools / write tools 都要进这一层。

tool_executions

核心字段：

关键点：tool result 不应该只作为一段 transient prompt text 存在。只要它影响了 objective / task，就要变成 evidence 或 decision ledger 的引用。

#3.6 AI Run / Trace Pointer 层

产品数据库里只保轻量 join key：

ai_runs
ai_observation_refs

大 payload 交给 Langfuse / Traceplane / object storage。

ai_runs 负责：

• ai_run_id
• store_id / tenant_id
• trace_id
• external_trace_url
• stage
• model
• provider
• prompt_version
• prompt_hash
• schema_version
• execution_bundle_id
• token / cost / latency summary
• status

Langfuse 的核心数据模型是 traces、observations、sessions。OpenTelemetry 和 OpenAI Agents SDK 也把 LLM generation、tool call、guardrail、handoff 这些看成 trace/span/observation。Retaintive 应该顺着这个行业方向：内部调试看 trace，产品状态看 Neon。

#3.7 Approval / Automation 层

未来 AI 能执行更多动作时，必须有：

approval_requests
agent_executions
automation_runs

第一版可以只做 approval_requests：

这和 LangChain Human-in-the-Loop / LangGraph persistence / Temporal durable workflow 的方向一致：高风险动作不能只靠模型自觉，要能暂停、等人、恢复、审计。

#3.8 Registry 层

现在很多东西不规范，本质是 registry 不清楚。

目标态要有四类 registry：

registry 不一定第一天全做成 DB 表。早期可以是 typed code + versioned config。关键是：

• 每个 registry entry 有 stable key。
• 每次 AI run 记录使用的 registry version。
• prompt 里的 label 可以变，但 stable key 不能随便变。
• tenant override 不能污染 global default。
• deprecated value 不能马上删除，要有迁移期。

#4. 客户到底看到什么

客户不应该看到 AI 的内部链路。客户应该看到一个稳定、可解释、能行动的 product surface。

#4.1 Customer profile 页面

展示：

Open Objectives
  - Renewal discussion likely needed
  - Cancellation risk needs manager review
  - VIP follow-up overdue

For each objective:
  - status
  - priority
  - owner
  - due date
  - confidence band
  - estimated value / risk
  - evidence cards
  - related tasks
  - outcome

#4.2 Objective detail 页面

展示：

Objective
Why it matters
Recommended next step
Sources
Related tasks
Timeline
Outcome

source cards 可以长这样：

Source 1: Call on 2026-06-24
"Customer asked whether membership can be extended."

Source 2: SMS on 2026-06-23
"Send me the renewal options."

Source 3: Policy
Renewal outreach is allowed within 30 days of expiration.

注意：source excerpt 要短、脱敏、可点击回原始上下文。不要把完整 transcript 大段塞进 objective 页面。

#4.3 Manager / owner dashboard

展示：

• New revenue objectives detected.
• VIP objectives needing review.
• Objectives overdue.
• Objectives by type and store.
• AI-created vs human-created objective outcome.
• Top sources driving objectives.
• Rejected / needs-review proposals for admin audit.

这才是客户愿意付钱的地方：不是“AI 很聪明”，而是“我知道哪里在漏钱、谁该处理、证据是什么、最后有没有处理成”。

#5. VIP 应该怎么进系统

VIP 不应该只是 contact 上的一个 badge。VIP 应该影响 workflow。

VIP signal
  -> objective priority
  -> SLA
  -> routing
  -> approval threshold
  -> automation permissions
  -> manager visibility

VIP 目标态：

VIP 不是“把任务布置给 VIP”。任务仍然分配给 staff、manager、AI agent 或 system。VIP 的作用是让系统更谨慎、更快升级、更重视 outcome。

#6. Tool calling 和 orchestrator 怎么接

数据模型不要绑定某个 agent framework。Mastra、LangGraph、AI SDK、自研 loop 都只是 runtime 选择。

最小 loop 可以是：

initialize run
load execution bundle
load current evidence window
call model
if model asks for read-only tool:
  authorize tool
  execute tool
  store tool_execution
  convert useful result into evidence_items
  call model again
if model proposes objective/task:
  write decision_attempt
  pass Policy Guard
  write objective/task if allowed
  attach sources

框架可以换，但这几个写入点不能换：

• ai_runs
• tool_executions
• evidence_items
• decision_attempts
• objectives
• objective_sources
• tasks
• task_sources

AI SDK 的 ToolLoopAgent 提供 stopWhen / prepareStep 这类 loop control。LangGraph 有 checkpointer 和 store，可以支持 pause/resume、human-in-the-loop、fault tolerance。Temporal 适合更长周期、跨天、需要 crash-proof execution 的 workflow。它们都不替代产品数据库里的 objective / evidence / ledger。

#7. 分阶段演进路线

#Phase 0：现在已经有的地基

现状已经有：

• tasks
• task_sources
• contact_timeline
• contactAnalysisRunId
• promptVersion / promptHash
• Traceplane
• Policy Guard
• task accuracy harness

这说明方向已经对了。不要推倒重来。

#Phase 1：先把 task 解释清楚

目标：

• accepted task 一定能展示 sources。
• rejected / skipped / zero-row proposal 不再消失。
• AI run 能 join 到 prompt/model/schema/version。

要做：

• 补 decision_attempts。
• 扩 task_sources 读取 API。
• Task detail 展示 evidence cards。
• Langfuse / Traceplane 接 trace id。

做到后效果：

员工能回答“这个 task 为什么存在”；工程能回答“为什么该有的 task 没出现”。

#Phase 2：Objective shadow mode

目标：

• AI 同时输出 taskDecisions[] 和 objectiveProposals[]。
• objective 先 shadow write，不改变现有 task 行为。
• PM / engineer 用 dashboard 对比 objective 是否比 task 更稳定。

要做：

• 新增 objectives / objective_sources / objective_events。
• 让现有 task 可以 optional 关联 objective_id。
• 对一通 call 产生多个 task 的场景，验证一个 objective 下挂多个 task 是否更清晰。

做到后效果：

系统开始从“派活”升级为“识别业务目标”。

#Phase 3：Objective-first write path

目标：

• 新 signal 先生成 objective proposal。
• task 由 objective 派生。
• task 不再承担所有业务语义。

要做：

• writer 支持 objective accepted/rejected ledger。
• task dedupe 改为 objective-aware。
• close task 不等于 close objective；objective 关闭需要 outcome。

做到后效果：

一个客户的业务机会不会被拆散在多个孤立 task 里。

#Phase 4：Read-only tools + tenant knowledge

目标：

• AI 可以主动查 customer、task、call、SMS、lead、tenant policy、reg docs。
• 所有 tool result 都有 tool_execution 和 evidence。

要做：

• Tool Registry。
• Tenant Knowledge Registry。
• Read-only tool authz。
• Prompt injection 防护。
• Cost / rate limits。

做到后效果：

AI 不再只能吃预先塞好的 context，而是能在受控范围内自己补上下文。

#Phase 5：Approval-gated automation

目标：

• AI 可以提出 outbound message、manager escalation、CRM write、VIP handling。
• 高风险动作必须 approval。

要做：

• approval_requests。
• agent_executions。
• side-effect tool policy。
• human edit / approve / reject flow。
• outcome 回流。

做到后效果：

AI 从“建议员工做事”升级为“在授权范围内推进工作”，但仍然不绕过人和代码。

#Phase 6：Durable workflows for long-running objectives

目标：

• 对跨天、跨周、需要等待客户回复或审批的 objective，支持 durable workflow。

候选：

• 继续自研 state machine。
• LangGraph persistence。
• Temporal workflow。

选择标准：

• 是否需要跨进程 crash recovery。
• 是否需要长时间 sleep / resume。
• 是否有复杂 approval。
• 是否需要多步骤 side effects。

做到后效果：

objective 不只是数据库里的一行，而是能长期推进、暂停、恢复、审计的 workflow。

#8. Final State 图

Signals
  calls / SMS / voicemail / leads / CRM / docs / web
    |
    v
Evidence Layer
  evidence_items / knowledge_chunks
    |
    v
AI Runtime
  model calls / read-only tools / RAG / tool loop
    |
    v
Decision Layer
  decision_attempts
  policy guard
  approval gate
    |
    v
Business State
  objectives
  objective_sources
  objective_events
  tasks
  task_sources
    |
    v
Product Surface
  objective detail
  task detail
  customer timeline
  manager dashboard
  VIP escalation
    |
    v
Feedback
  outcomes
  staff edits
  customer replies
  eval scores
  prompt / policy improvement

横切全链路：

tenant isolation
idempotency
trace_id / span_id
ai_run_id
execution_bundle_id
Langfuse / Traceplane
cost / usage
retention / privacy

#9. 不要做的事

• 不要把 AI 原始 JSON 当产品主表。
• 不要把所有 flexible 字段都藏进 JSONB。
• 不要为每个行业一开始就建一套独立 schema。
• 不要让 prompt 里的中文 label 成为数据库里的永久 key。
• 不要把 Langfuse / Traceplane 当业务 system of record。
• 不要让 tool result 只存在 prompt 历史里。
• 不要让 rejected proposal 静默消失。
• 不要让 VIP 绕过 approval；VIP 应该更谨慎，不是更随意。

#10. 推荐的近期开工顺序

第一优先级：

1. decision_attempts：先补“AI 提过但没落库”的黑洞。
2. Task sources UI/API：把现有 task_sources 变成客户可见信任能力。
3. ai_runs lightweight ledger：把 prompt/model/schema/cost/trace join key 固化。

第二优先级：

1. objectives shadow mode。
2. objective_sources。
3. objective detail 的 internal prototype。

第三优先级：

1. Tool Registry。
2. read-only customer/task/call/message/knowledge tools。
3. Langfuse traces 和 DB ai_run_id / trace_id 对齐。

第四优先级：

1. VIP policy。
2. approval queue。
3. outbound / CRM write side-effect tools。

这条路线的核心是：先把“为什么”存清楚，再让 AI 更自主。否则 AI 越自主，系统越不可解释。

#11. 参考资料

本设计基于以下已有文档和官方资料：

• 系统世界观
• AI 决策可追溯性：把 AI 做事过程变成可查的账
• AI Agent Foundation 最终态与当前缺口
• retaintive LLM 平台架构终态与 Traceability
• Langfuse Observability data model
• Langfuse Scores data model
• OpenTelemetry trace semantic conventions
• W3C Trace Context
• PostgreSQL JSON Types
• AI SDK Loop Control
• LangGraph Persistence
• LangChain Human-in-the-loop
• OpenAI Agents SDK tracing
• Temporal Durable Execution