Retaintive AI Operating System 长期蓝图

Historical / Superseded for Task domain（2026-07-15）：本文探索的独立 Objective → Task 产品模型未被采用，不能作为 schema、API、UI 或 AI runtime 的目标态。现行 Task contract 是 Task / Next Action / Activity / Outcome，见 Task System Design V3。registry、Decision Ledger、typed tools、approval 与 traceability 等通用平台思路仍可作为历史参考。

0. 这份文档解决什么

前面几份文档分别讲了：

系统世界观：Retaintive 这台机器信什么、谁说了算。
LLM 平台架构终态与 Traceability：Governance / Data / Cross-cutting 三平面、ID、traceability。
AI Objective / Evidence 数据模型目标态：objective、sources、decision ledger、tool execution 怎么落库。
AI 决策可追溯性：AI 提过什么、为什么 accepted / rejected / skipped、怎么查。

这份文档回答另一个问题：

如果 Retaintive 未来要从 task generator 进化成 objective-first AI operating system，我们到底要建设哪些能力、买哪些工具、自己管哪些 registry，最后客户会看到什么效果，以及从今天 prompt 工作怎么一步步落地。

一句话：

Retaintive 长期要做的是 Evidence-backed Revenue Objective Engine，不是一个泛用 AI chatbot，也不是一个单纯 agent framework demo。

1. 最终产品效果

客户最终不应该看到“AI 输出了一个 JSON”。客户应该看到的是一套可解释、可执行、可追踪 outcome 的业务系统。

Customer
  -> revenue / risk objectives
  -> evidence cards
  -> recommended next actions
  -> tasks / approvals / AI actions
  -> owner / SLA / escalation
  -> outcome

一个目标态页面应该长这样：

Customer: Max W.
VIP: yes

Open Objective:
  Renewal risk with upgrade potential

Why:
  1. Call: customer asked whether membership can be extended.
  2. SMS: customer asked for renewal options.
  3. CRM: current plan expires soon.
  4. Tenant policy: renewal outreach allowed before expiration.

Recommended next step:
  Manager should call today with renewal + upgrade option.

Related tasks:
  - Manager callback
  - Send renewal option summary

Status:
  open -> assigned -> completed -> outcome recorded

客户愿意付钱的点不是“AI 很聪明”，而是：

不漏 revenue opportunity。
不漏 churn / complaint / VIP risk。
每个建议都有 sources。
每个目标有 owner、SLA、next action。
管理者知道哪些事情逾期、谁没处理、最后有没有产生结果。
每个 tenant 可以有自己的 policy、VIP 规则、行业 vocabulary、approval threshold 和 automation limits。

2. 核心产品对象

长期系统里，task 不应该是最高层对象。

signal -> evidence -> objective -> task / approval / agent action -> outcome

对象	人话解释	客户是否直接看到
`signal`	外部发生的事：call、SMS、lead、CRM event、policy doc update	通常不直接看
`evidence`	被系统标准化后的证据，可引用、可展示、可权限控制	看一部分
`objective`	业务上要达成的目标：renewal、upgrade、churn save、complaint recovery	看
`task`	为了推进 objective 的具体动作	看
`approval`	高风险动作的人工裁决	管理者看
`agent action`	AI 在授权范围内执行的动作	看摘要和审计
`outcome`	最后有没有 booked、renewed、saved、lost、not interested	看

这套对象让系统能从“派活”升级成“经营目标管理”。

3. AI 在对话前、对话中、对话后的角色

AI 不一定一开始就知道 objective。它有三种模式。

3.1 对话前已有 objective

例子：VIP 客户已有 open cancellation risk objective。

AI 在对话前应该拿到一个受控的 objective envelope：

objective_id
target outcome
known evidence
customer status
VIP policy
allowed tools
forbidden actions
approval requirements
stop conditions
escalation rules

这时 AI 的任务不是自由发挥，而是：

在 policy envelope 内推进一个明确 objective。

3.2 对话中发现 objective

例子：客户本来只是问价格，但电话里表达了 cancellation、upgrade、complaint、referral 或 renewal intent。

这时 AI 的任务是：

识别 fresh intent。
补问必要信息。
不越过 DNC、compliance、store boundary。
把新发现的 objective hypothesis 记下来。
对 VIP 或高风险场景触发升级。

这时 AI 的目标是：

发现并澄清 objective，而不是强行完成一个预设任务。

3.3 对话后生成 proposal

对话结束后，系统把 transcript、tool results、CRM facts、policy docs 转成 evidence，然后生成：

objective proposal。
task proposal。
source links。
decision attempt。
approval request。
outcome update。

这里仍然遵守世界观：AI 只提出 proposal，代码、Policy Guard、approval 和 DB constraints 决定什么真正发生。

4. 需要建设的技术能力

Retaintive 最终需要九类能力。

4.1 Prompt / Schema Management

要管理：

prompt version。
prompt hash。
prompt labels。
output schema version。
schema field semantics。
prompt / schema / taxonomy 的 compatibility。
per-tenant prompt override。

市面工具能帮忙做 prompt version、labels、playground、experiment。Langfuse 的 prompt management 支持 version 和 labels；labels 可以用于 environment、tenant 或 experiment。Helicone、Portkey、Braintrust、LangSmith 也都有不同程度的 prompt / experiment 能力。

Retaintive 仍然要自己拥有：

prompt 里的业务 contract。
Zod / output schema。
taxonomy stable keys。
prompt 改动对应的 eval scenarios。
production release policy。

4.2 Observability / Tracing

要管理：

trace_id / span_id。
ai_run_id。
model call。
tool call。
retrieval step。
guardrail decision。
token / cost / latency。
prompt version。
output validation error。

Langfuse、LangSmith、Phoenix、Braintrust 都可以承担 LLM observability。Langfuse 可以接 OpenTelemetry endpoint；Phoenix 也支持 OpenTelemetry / OpenInference 风格的 trace ingestion。OpenAI Agents SDK 自带 tracing，能记录 LLM generation、tool calls、handoffs、guardrails 和 custom events。

Retaintive 的原则：

Trace 平台负责 debug 和分析；Neon 里的 product tables / ledger 才是业务 system of record。

4.3 Evaluation / Scenario Registry

要管理：

golden scenarios。
DB replay cases。
expected objective / task decision。
known gaps。
prompt regression。
model regression。
source-grounding quality。
tool-use correctness。

平台可以跑 eval 和展示 scores，但 scenario 本身必须由 Retaintive 自己定义。因为只有 Retaintive 知道什么叫“正确的 renewal objective”、“什么时候不该创建 task”、“VIP cancellation 怎么升级”。

4.4 Business Registry

要管理：

objective_type。
source_type。
outcome_type。
priority。
risk_level。
source_strength。
source_visibility。
industry vocabulary。

这部分不能外包。Prompt 可以引用它，UI 可以展示它，writer 可以校验它，eval 可以断言它。

早期可以是 typed code + docs；后期可以升级为 DB-backed registry + admin UI。

4.5 Policy / Tenant Config Registry

要管理：

tenant 是否接 CRM / POS。
VIP definition。
SLA。
approval threshold。
DNC / compliance。
allowed objective types。
allowed tools。
model / cost limits。
data retention。
source visibility。

这是多租户 AI 系统的控制面。不能只写在 prompt 里，也不能只由 observability 平台管理。

4.6 Tool Catalog / Capability Envelope

要管理：

tool name。
tool version。
input schema。
output schema。
tenant scope。
read-only / side-effect。
authz policy。
rate limit。
cost limit。
approval requirement。
tool result 是否能变成 evidence。

Mastra、OpenAI Agents SDK、AI SDK、LangGraph 都能帮你运行 tool call；但 Retaintive 必须自己决定：

这个 tenant 能不能用这个 tool。
这个 customer 能不能被查。
这个 action 是否需要 approval。
tool output 是否允许给客户看。

4.7 Agent Runtime / Orchestration

可选技术：

AI SDK：适合 TypeScript 小型 tool loop，stopWhen / prepareStep 够轻。
Mastra：适合 TypeScript-first agents / workflows / tools / observability，业务代码集成感较好。
LangGraph：适合复杂 state graph、persistence、human-in-the-loop、pause/resume。
OpenAI Agents SDK：适合 OpenAI-native agent loop、tools、guardrails、tracing。
Temporal：适合跨天、跨周、审批、等待客户回复、失败恢复的 durable workflow。

判断标准：

场景	优先选择
单次 read-only assistant / lookup	AI SDK 或小型自研 loop
TypeScript agent app + tools + workflows	Mastra
复杂状态机 / pause-resume / HITL graph	LangGraph
OpenAI-native tools / tracing / guardrails	OpenAI Agents SDK
长周期、强可靠 workflow	Temporal

不要让 runtime 决定业务模型。Runtime 可以换，objective、evidence、decision ledger 不能换。

4.8 Approval / Human-in-the-loop

要管理：

哪些动作需要人批。
谁能批。
能否 edit。
reject 后怎么回到 AI。
approval 是否过期。
审批结果如何写入 ledger。

LangGraph / LangChain 有 human-in-the-loop 机制，可以暂停 tool call 等人类决定；Temporal 也适合长时间等待。Retaintive 仍要自己定义业务 approval policy。

4.9 Usage Metering / Billing

要管理：

tenant 级 token / cost。
model usage。
trace count。
tool execution count。
objective / task automation count。
VIP automation package。
overage。

这部分将来会影响收费。不能只依赖 provider dashboard。

5. Build vs Buy：不要什么都自己造，也不要把内核交出去

推荐策略：

Buy / integrate:
  Langfuse-style observability / prompt management / eval UI
  AI SDK / Mastra / LangGraph-style runtime
  OpenRouter / gateway-style provider routing
  Temporal-style durable workflow when needed

Own:
  objective lifecycle
  evidence model
  decision ledger
  tenant policy
  business registry
  tool authorization
  approval semantics
  customer-visible product state

更具体地说：

能力	推荐方向	原因
LLM observability	先选 Langfuse	覆盖 traces、prompt management、evals，和 OpenTelemetry 方向一致。
Prompt registry	Git/source code + Langfuse hybrid	代码保证 review/eval；Langfuse 提供 UI、version、labels、playground。
Eval platform	Langfuse 起步；需要更强 eval workflow 时评估 Braintrust / LangSmith / Phoenix	先别同时接多个 eval 平台。
Agent runtime	近期小 loop / AI SDK；TS-first workflow 增长后看 Mastra	先把 read-only assistant 做稳，不要一开始重 agent framework。
Stateful / HITL graph	真需要 pause/resume 再看 LangGraph	不要为简单流程引入复杂 graph。
Durable workflow	跨天/跨周任务、审批和外呼后再考虑 Temporal	Temporal 很强，但不是 prompt v1 阶段的第一优先级。
AI Gateway	当前可以继续 OpenRouter + 自有 wrapper；后期评估 Portkey / Helicone / LiteLLM	Gateway 可以买，但 execution bundle 和 tenant usage 要自己记。

6. Retaintive 自己必须管理的 registries

长期至少有八类 registry。

6.1 Prompt Registry

管：

prompt name。
prompt version。
prompt hash。
labels：dev / staging / production / tenant-specific。
owner。
changelog。
eval status。

第一阶段可以继续 code-first。后期接 Langfuse 做 UI / labels / playground，但 production prompt 仍要能追到 Git commit 和 eval result。

6.2 Output Contract Registry

管：

Zod schema。
schema version。
field semantics。
allowed enum stable keys。
deprecated fields。
migration notes。

这是 prompt 和 writer 的契约。模型可以输出结构化 proposal，但 writer 只能接受符合 schema 的 proposal。

6.3 Objective Registry

管：

objective_type。
success criteria。
close criteria。
allowed task types。
priority default。
source requirements。
approval requirement。

例如 churn_risk 必须有 fresh customer intent 或 high-confidence complaint evidence；renewal 可能需要 membership expiration evidence；compliance_review 可能必须 manager approval。

6.4 Evidence / Source Registry

管：

source_type。
source strength。
visibility。
freshness policy。
display rules。
retention。

同样一句客户说的话和 CRM fact 的权威性不一样。registry 要让代码知道“谁更硬”，而不是让 prompt 自己猜。

6.5 Policy Registry

管：

DNC。
store isolation。
CRM / POS authority。
duplicate suppression。
VIP escalation。
approval threshold。
side-effect limits。

这部分是 code authority，不是 prompt authority。

6.6 Tenant Config Registry

管：

tenant enabled features。
tenant-specific prompt label。
tenant policy override。
model tier。
usage cap。
integrations。
data retention。

未来多租户复杂后，不能靠环境变量硬写所有差异。

6.7 Tool Registry

管：

tool name / version。
input / output schema。
permission。
tenant scope。
side-effect level。
approval rules。
result-to-evidence mapping。

这会成为 agent autonomy 的核心。

6.8 Evaluation Registry

管：

scenario id。
source of rule。
expected decision。
expected sources。
priority。
known gap。
last pass/fail。

没有 eval registry，prompt management 会变成“凭感觉改 prompt”。

7. Planes：这些 registry 落在哪一层

可以把系统分成四个面。

Governance / Release Plane
  prompt registry
  schema registry
  objective registry
  policy registry
  tenant config
  model routing

Data Plane
  evidence acquisition
  context builder
  model call
  tool execution
  policy guard
  writer

Cross-cutting Plane
  trace
  audit
  idempotency
  authz
  cost
  eval

Product State Plane
  objectives
  tasks
  sources
  approvals
  outcomes

一个重要结论：

Observability 平台可以覆盖 Cross-cutting Plane 的一部分；agent framework 可以覆盖 Data Plane 的一部分；但 Governance Plane 和 Product State Plane 的业务语义必须由 Retaintive 自己拥有。

8. 从现在开始怎么一步步做

Phase 0：先把当前 prompt v1 做稳

当前第一要务仍然是 prompt / schema / task decision。

完成标准：

prompt 分层清楚。
output schema 清楚。
enum stable keys 清楚。
prompt version / hash 正常。
task decision 行为通过核心 eval。
stale profile 不压制 fresh intent。
DNC / store isolation / duplicate / task visibility 仍由 code guard。

这个阶段不要急着上 tool calling。

Phase 1：把 prompt 改动变成可管理 release

要做：

prompt registry 文档化。
output contract registry 文档化。
eval scenario registry 扩充。
每次 prompt 改动都带 eval。
trace 里记录 prompt version、hash、model、schema version。

可接：

Langfuse prompt management / traces / evals。

做到后的效果：

prompt 不再是“改一段文字看看”，而是有版本、有评估、有回放、有发布边界。

Phase 2：补 Decision Ledger 和 sources 产品化

要做：

decision_attempts。
rejected / skipped / zero-row proposal 落账。
task_sources read API。
Task Detail 展示 source cards。
内部 audit 页面能查 AI 提过但没写入的 proposal。

做到后的效果：

员工知道 task 为什么存在；工程知道 task 为什么没出现。

Phase 3：Objective shadow mode

要做：

objectiveProposals[] shadow output。
objectives / objective_sources / objective_events shadow write。
不影响现有 task 行为。
用 internal dashboard 看 objective 是否比 task 更能表达业务目标。

做到后的效果：

系统开始从 task-first 过渡到 objective-first，但不冒险破坏现有产品。

Phase 4：Objective-first product surface

要做：

Customer profile 显示 open objectives。
Objective detail 显示 sources、tasks、timeline、outcome。
task optional 关联 objective。
close task 不等于 close objective。
objective 关闭必须有 outcome。

做到后的效果：

客户看到的是 revenue / risk objectives，而不是一堆散 task。

Phase 5：Read-only tools

要做：

Tool Registry。
customer lookup。
task lookup。
call / SMS / lead lookup。
tenant knowledge search。
read-only authz。
tool executions 落账。
tool results 转 evidence。

可选 runtime：

小型自研 loop / AI SDK。
TS-first 复杂后评估 Mastra。
需要复杂 state graph 再评估 LangGraph。

做到后的效果：

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

Phase 6：VIP / approval-gated automation

要做：

VIP policy registry。
approval requests。
manager escalation。
AI draft outbound message。
approval 后执行。
outcome 回流。

做到后的效果：

VIP 不只是 badge，而是影响 SLA、routing、approval 和 automation 的业务规则。

Phase 7：Agent execution / durable workflows

要做：

agent execution log。
side-effect tool policy。
outbound call / SMS / CRM write。
long-running objective workflow。
pause / resume / retry。
human-in-the-loop。

候选：

LangGraph for stateful HITL graph。
Temporal for durable workflow。
Mastra workflows for TypeScript app workflows。

做到后的效果：

Retaintive 从“建议员工做事”升级为“在授权范围内推进目标”，但仍然由 code / policy / approval 掌权。

9. AI 和人类开发者以后应该读哪些文档

为了让未来的 AI coding agent 不乱写，必须把文档变成开发入口。

动 task / contact / prompt / agent 前，至少读：

每次改 prompt / schema / task writer / policy guard，必须问：

这个改动改变了哪个 registry？
是否需要 bump prompt / schema / taxonomy version？
是否需要新增 eval scenario？
是否影响 traceability？
是否影响 customer-visible sources？
是否可能让 rejected proposal 静默消失？
是否绕过 tenant / store isolation？

10. 现在的务实建议

现在不要急着把所有未来能力都做出来。

当前最合理的顺序是：

先完成 prompt v1。 把当前 contacts-analyzer prompt / schema / task decision 做稳。
把 prompt 改动纳入 eval。 没有 eval 的 prompt change 不算真正安全。
接 Langfuse 或同类平台做 trace / prompt / eval 起点。 先选一个，不要多平台并行。
补 Decision Ledger。 这是比 tool calling 更早的地基。
把 task sources 展示出来。 先让客户看到“为什么有这个 task”。
做 objective shadow mode。 不急着替换 task，但先收集 objective 是否更好。
再做 read-only tools。 从 customer/task/call/message/knowledge lookup 开始。
最后做 approval-gated automation。 尤其是 VIP、outbound、CRM write。

这条路线的核心是：

先让 AI 判断可评估、可解释、可追责，再逐步增加 AI 自主性。

11. 不要做的事

不要先上复杂 agent framework，再回头补 ledger / sources。
不要把 prompt management 完全交给外部平台，repo 里没有 source of truth。
不要让 model 自己决定 tenant policy。
不要让 tool catalog 只是函数列表，没有 authz / approval / visibility。
不要把 Langfuse / LangSmith / Phoenix 当业务数据库。
不要让 VIP 绕过审批。VIP 应该更谨慎、更快升级，不是更放任。
不要把 objective 做成另一个 task type。Objective 是目标，task 是动作。
不要在 prompt v1 还不稳定时引入 write tools。

#Retaintive AI Operating System 长期蓝图

#0. 这份文档解决什么

#1. 最终产品效果

#2. 核心产品对象

#3. AI 在对话前、对话中、对话后的角色

#3.1 对话前已有 objective

#3.2 对话中发现 objective

#3.3 对话后生成 proposal

#4. 需要建设的技术能力

#4.1 Prompt / Schema Management

#4.2 Observability / Tracing

#4.3 Evaluation / Scenario Registry

#4.4 Business Registry

#4.5 Policy / Tenant Config Registry

#4.6 Tool Catalog / Capability Envelope

#4.7 Agent Runtime / Orchestration

#4.8 Approval / Human-in-the-loop

#4.9 Usage Metering / Billing

#5. Build vs Buy：不要什么都自己造，也不要把内核交出去

#6. Retaintive 自己必须管理的 registries

#6.1 Prompt Registry

#6.2 Output Contract Registry

#6.3 Objective Registry

#6.4 Evidence / Source Registry

#6.5 Policy Registry

#6.6 Tenant Config Registry

#6.7 Tool Registry

#6.8 Evaluation Registry

#7. Planes：这些 registry 落在哪一层

#8. 从现在开始怎么一步步做

#Phase 0：先把当前 prompt v1 做稳

#Phase 1：把 prompt 改动变成可管理 release

#Phase 2：补 Decision Ledger 和 sources 产品化

#Phase 3：Objective shadow mode

#Phase 4：Objective-first product surface

#Phase 5：Read-only tools

#Phase 6：VIP / approval-gated automation

#Phase 7：Agent execution / durable workflows

#9. AI 和人类开发者以后应该读哪些文档

#10. 现在的务实建议

#11. 不要做的事

#12. 参考资料

Retaintive AI Operating System 长期蓝图

0. 这份文档解决什么

1. 最终产品效果

2. 核心产品对象

3. AI 在对话前、对话中、对话后的角色

3.1 对话前已有 objective

3.2 对话中发现 objective

3.3 对话后生成 proposal

4. 需要建设的技术能力

4.1 Prompt / Schema Management

4.2 Observability / Tracing

4.3 Evaluation / Scenario Registry

4.4 Business Registry

4.5 Policy / Tenant Config Registry

4.6 Tool Catalog / Capability Envelope

4.7 Agent Runtime / Orchestration

4.8 Approval / Human-in-the-loop

4.9 Usage Metering / Billing

5. Build vs Buy：不要什么都自己造，也不要把内核交出去

6. Retaintive 自己必须管理的 registries

6.1 Prompt Registry

6.2 Output Contract Registry

6.3 Objective Registry

6.4 Evidence / Source Registry

6.5 Policy Registry

6.6 Tenant Config Registry

6.7 Tool Registry

6.8 Evaluation Registry

7. Planes：这些 registry 落在哪一层

8. 从现在开始怎么一步步做

Phase 0：先把当前 prompt v1 做稳

Phase 1：把 prompt 改动变成可管理 release

Phase 2：补 Decision Ledger 和 sources 产品化

Phase 3：Objective shadow mode

Phase 4：Objective-first product surface

Phase 5：Read-only tools

Phase 6：VIP / approval-gated automation

Phase 7：Agent execution / durable workflows

9. AI 和人类开发者以后应该读哪些文档

10. 现在的务实建议

11. 不要做的事

12. 参考资料