# Report 2 — AI Copilot:架构、数据盘点与开发提案(中文版)

**日期:** 2026-07-28 · **作者:** AI review (Claude) · **读者:** CEO,以及任何被邀请评审本提案的其他 AI model — **Part A 和 Part B 的写法,让没有 codebase 权限的外部评审者也能独立评估 Part C 的优劣。**

> 姊妹篇:[Report 1 — UX & Functionality Review](./2026-07-28-ux-functionality-review.md)(英文)· 独立扩展:[11 个 World-Class AI Ideas(中文)](./2026-07-28-ai-independent-ideas-zh.md) · 本文英文原版:[2026-07-28-ai-copilot-development.md](./2026-07-28-ai-copilot-development.md)。本文若干提案依赖 Report 1 列出的数据采集修复(booking 字段、closer 归属、activity logging)。

---

## Part A — 现状:AI 将要接入的系统

### A1. 技术栈与形态

- **Laravel 13 (PHP 8.4) + Inertia + Vue 3 + Tailwind v4**,MySQL,Redis + Horizon 队列(含专用 lane:长时 ASR 任务走 `redis-transcription`,AI 调用走带韧性的 `ai` lane),Reverb websockets,GCS 文件存储(统一经 `MediaService`),scheduler,以及一个 Node 的 `baileys-wa-bridge` sidecar(WhatsApp QR 通道)。
- **严格的架构约定**(GUIDELINES.md 强制):所有写操作走 Repository + transaction,校验走 Form Request,列表过滤走 QueryRequest,model 只放常量与关系,所有 admin 列表共用一套 DataTable/filter 基础组件。
- **两个 portal,一条 identity 主线:** Manage portal(管理员)+ Main portal(客户)。**一个 lead 就是一个 portal user** — 一个人 = 一条 `Lead` 记录,对应一个 `User` + `UserProfile`。所有身份解析统一经 **`LeadLinker`** service(phone-trust 策略、去重、merge 检测)。这是对 AI 工作最重要的架构事实:**下文所有信号都已经能用 `lead_id` join 起来。**

### A2. 软件所建模的业务流

六条销售产品线,每条在概念上都跑 **Pipeline → Sales → Referral & Repeat**(UI 上是 chevron stage rail)。Property Booking 已完整落地:买家 quiz 提交 → 按 (lead, project) 建 **engagement**(Caller → Closer → Follow-Up 生命周期)→ **booking**(单位、价格、SPA 流程、按 project rate × basis price 推导 commission)→ referral worklist(按 never-asked → 最近成交 → 消费额排序)。营销侧走 **funnels**(landing page → sessions → Zoom webinars,含出席追踪和 session 级 Meta 广告归因)+ **Meta ads**(Traffics 页的 campaign CPL)。沟通侧走**统一 inbox**(WhatsApp Cloud API + WhatsApp QR bridge + Messenger)。

### A3. 已在生产环境运行的 AI 基础设施(`Src\Ai`)

给评审者的关键信息:**这不是从零开始 — 平台已经有一层真实的 AI substrate。**

| 组件 | 作用 |
|---|---|
| `AiClient` | Provider-agnostic 的 chat/prompt service,横跨 **Anthropic、OpenAI、Gemini、DeepSeek、Moonshot** — 统一响应格式、fail-soft、支持 streaming。所有 AI 调用的唯一入口。 |
| `AiKeyService` / `AiCredential` | 加密的 key 存储,两种 scope:**公司全局 key** 与 **会员自带 key**(BYO-key)。入库前先向 provider 验证。 |
| Prompt registry | `AiPrompt` / `AiPromptVersion` + markdown prompt 文件,按 registry key 管理 — prompt 是有版本的数据,不是写死的代码字符串。 |
| `ai_requests` 日志 | 每次调用都记录:provider、model、tokens、成本、耗时,以及一个**多态 `subject`**(这次调用是关于哪条记录的)。至今 764 条。 |
| Credits | `lead_ai_credits`:面向会员的 AI 先用免费额度、用完切自己的 key;默认额度管理员可改。 |
| 队列 lane | 带 rate-limit + circuit-breaker 语义的 `ai` lane。 |

### A4. 已上线的 AI 功能(substrate 的现有消费者)

1. **Conversation analysis**(`Src\Conversation\ConversationAnalyzer`)— 三种录音(电话、门店 badge、Zoom)共用**一个 analyzer、一个 schema**:summary、对话类型、sentiment、**客户画像(interest level、buying stage、budget、needs、concerns)**、**销售表现(0–10 score、strengths、improvements)**、meeting report(含 next steps + follow-up date),中英双语。输出经 `normalize()` 钳制 — 每个 key 保底、enum 强制收敛 — **防幻觉的 guardrail 模式已经制度化。**
2. **Transcription**(`Src\Transcription`)— 共享服务,Gemini 为主 → Deepgram 兜底,跑在专用队列 lane 上;三条录音 pipeline 共用。
3. **WhatsApp AI** — 按 channel 分配的 **AI Profiles**:分层知识文档 + instruction(全局 base profile 可被具名 profile 继承),两种模式(**draft-suggest** 在输入框上方给草稿 / **auto-reply** 自动回复,超出 active hours 自动降级为草稿),debounce 窗口,objective 完成标记(`[[OBJECTIVE_MET]]`)。这实际上就是**跑在最高流量渠道上的、生产级的 RAG-lite + agent loop。**
4. **WhatsApp Flows** — 20 条 flow:定时 drip 与规则型 menu bot,支持并行 run slot、campaign/keyword/Google-Sheet 触发、四道 template 校验、human handoff 时终止所有自动化。
5. **AI Conversations**(会员 portal)— 流式 ChatGPT 式聊天,可选注入会员自己的 wealth plans + property analyses 做 grounding,credits-then-own-key 计费。
6. **Lead enrichment** — 每个 lead 的低成本身份信号:GeoIP、设备指纹、电话有效性/运营商、WhatsApp 在网检测(有限速)、Gravatar、Google Places 商户反查(已 enrich 1,213 个 lead)。
7. **AI Video**(feature-flagged)与 portal 里的 **AI Debate** 实验。

### A5. 集成轨道(agent 可以*通过什么*去行动)

WhatsApp Cloud API + Bridge(发送、templates、flows)、Meta Messenger、Zoom S2S(建会议/webinar、拉录音 + transcript)、Meta Ads API(campaigns、spend、lead-gen)、Stripe(products/purchases)、SMS360(`SmsSender`)、Telegram 员工告警(`Notifier` — 按事件注册,管理员自行订阅)、带 magic sign-in link 的 email、dowayai 通话录音轮询、yhy smart-badge webhook 摄入。

---

## Part B — 数据盘点(实测,2026-07-27)

| 领域 | 表 | 行数 | 对 AI 的意义 |
|---|---|---|---|
| **人** | `leads` / `users` + profiles | **9,846 / 10,063** | 主轴。其余所有数据都 join 到它。 |
| 归因 | `lead_funnels` | 9,841 | 每次注册的 first-touch 来源/UTM/广告 — 广告 ROI 的训练标签。 |
| Enrichment | `lead_enrichments` | 1,213 | 身份/假号识别特征,可入 scoring。 |
| **对话** | `whatsapp_messages`(+1,048 threads) | **19,070** | 最丰富的行为语料,意图/情绪价值尚未开采。 |
| | `messenger_messages` | 18 | 边缘。 |
| **录音** | `zoom_recordings` | **1,694** | 最大的 transcript 语料,已挂 analyzer schema。 |
| | `call_recordings` | 214 | 已分析(interest、stage、objections、score)。 |
| | `f2f_recordings` | 4 | Pipeline 已验证,硬件佩戴率待提升。 |
| **销售** | `engagements` / `bookings` / `projects` | 195 / 182 / 39 | 成交结果(Converted/Lost)= 监督标签。⚠️ 过程态数据稀疏;SPA/bank/closer 字段全空(Report 1 §4)。 |
| 会员 | `member_subscriptions` | 452 | 第二收入流。 |
| **活动** | `event_registrations`(9 场) | **1,004** | 出席 + 时长 + session 级广告快照 — 高意向信号,目前是死胡同。 |
| **Portal 行为** | wealth plans / analyses / concierge / AI convos / lesson progress | 1 / 2 / 1 / 3+6 msgs / 8 | 量极小,但出现即是*极高*意向。已统一进 Activity timeline(UNION feed)。 |
| **楼盘知识** | `catalog_projects` / floor plans | **15,528** / 24 | 现成的房地产 RAG 知识库 — 价格、地段、事实。 |
| 获客表单 | property match / rental estimate 提交 | 0 / 0 | 功能已上线,但没有流量。 |
| AI 运维 | `ai_requests` | 764 | 成本/延迟遥测已在积累。 |

**给评审者的诚实判断:** 对话语料(1.9 万条消息 + ~1,900 份 transcript)和 lead 池(9.8 千、带归因)是真金白银;但**成交标签很薄**(182 张 booking,状态几乎只有终态)。这决定了路线:**先做「创造并采集数据」的 agent**(speed-to-lead、follow-up、referral ask),**后做「从数据学习」的 model**(预测式 scoring)— 这个顺序塑造了下面的 roadmap。

---

## Part C — 提案

### C0. 定位(一段话)

不要做「摆在 CRM 旁边的 chatbot」。要做:一个**以 tool-use 方式驾驭 CRM 的 copilot**、一层**与所有现有 AI 界面共享的知识层**、一小组**延伸既有自动化的 channel agents**(WhatsApp profiles/flows 已经等于 SDR agent 的 80%)。编排上**先 deterministic workflow,AI 放在边缘** — 当前行业共识(也是 Anthropic 公开的工程指南)是:可靠的生产系统由 workflow 编排、LLM 做其中的步骤,只有任务真正需要开放式规划时才升级到自主 multi-agent。2026 年是企业[从 pilot 走向 operational AI](https://www.cflowapps.com/ai-workflow-automation-trends/) 的一年,赢家的配方是 [RAG 负责「知」+ tool-calling(MCP 式)负责「行」](https://portkey.ai/blog/mcp-vs-rag/),再加上[有纪律的人机任务编排](https://www.blueprism.com/resources/blog/future-ai-agents-trends/)。

### C1. 地基 — Lead Timeline API(前置条件,~1 周)

下面每个提案都需要同一样东西:**一个能回答「关于 lead X 我们知道的一切」和「自 T 时刻以来发生了什么」的 service。** Portal Activity tab(2026-07-27 上线)已经 UNION 了五张行为表 — 把这个模式泛化成 `Src\Lead\Services\LeadTimeline`:

- 合并:funnel 注册、双渠道消息、录音分析、活动出席、portal 行为、engagement/booking 状态变迁、enrichment 事实。
- 两个 day-one 消费者:**Copilot 的 context builder**,和一条 **webhook 式事件流**(`lead.registered`、`lead.attended`、`lead.high_intent_signal`、`lead.went_quiet`)供编排器(C5)订阅。
- 顺带解决 Report 1 的「信号不流动」主题 — lead 详情页渲染同一条 timeline。

### C2. Copilot v1 — 管理员的 tool-using chat(`/manage/ai-copilot` 页面 + context drawer)

**架构:对内部 read API 做 agentic tool-use,而不是 embeddings 优先。** 对结构化的 CRM 问题(「今天该打给谁、为什么」「本月各 funnel 的 CPL 对比上月」「3 点见客前把 lead X 的一切总结给我」),tool call 打在现有查询层上,比向量检索更准、更新鲜、且天然带权限。暴露 ~10–15 个 read tool(leads.search、lead.timeline、engagements.list、bookings.stats、campaigns.cpl、events.attendance、recordings.analysis…),每个都是现有代码的薄封装,并且**强制执行调用者本人的 `LeadVisibility`/权限** — agent 永远不能看到比登录管理员更多的东西。

- Model 调用走现有 `AiClient`(需补一个 tool-use/function-calling 透传 — 现在的 transports 只做纯 chat;这是 v1 唯一的 substrate 升级)。所有 run 照旧记入 `ai_requests`。
- **两个挂载点:** AI Copilot 页(开放式提问),以及 lead/inbox 页面上的 context drawer(预置当前记录 —「帮我起草 follow-up」「这单为什么卡住」)。
- v1 的写操作**只做提议**:copilot 起草(一条 WhatsApp、一个 appointment、一次状态变更),管理员确认 — 复用 WhatsApp draft-suggest 已经训练过团队的同一套 UX。
- 若未来要把 tool 暴露给外部 runner,再把同一批 tool 包成 **MCP server** — 那是打包问题,不是架构问题;先把 tool 做出来。

### C3. 知识层 — closing playbook RAG(您的「上传世界级销售知识库」构想)

方向正确,而且一半管线已经存在:WhatsApp AI Profiles 已经支持全局 + 按 profile 分层的**知识文档 + instruction**。做法是泛化而不是另起炉灶:

- **一个 `KnowledgeBase` service**(文档带 scope:全局 / 产品线 / 渠道 / 阶段),供*四个*界面消费:copilot、WhatsApp draft/auto 回复、coaching agent(C6)、以及适用场景下的会员 portal chat。
- **先 prompt-stuffing,后 embeddings。** playbook 规模(几十份文档)下,把 scope 内相关文档直接塞进 context,质量和复杂度都优于向量库。等语料超出 context 预算再上 embeddings(独立向量库或 provider 托管的 file search)— 届时遵循当前检索最佳实践:先宽后窄、agentic 重查询,而不是一次性 top-k([RAG 管规则 + tools 管行动](https://www.projectpro.io/article/mcp-with-rag/1144))。
- **15,528 个楼盘的 catalog 是第二个知识库:**「X 附近 600k 以下的可比项目」是一个打在 `catalog_projects` 上的 copilot tool,不是文档 RAG。

### C4. Channel 与阶段 agents(按此顺序延伸已上线的东西)

1. **Speed-to-lead SDR(WhatsApp)。** ROI 最高、新代码最少。新 lead → 编排器等一个短暂的人工认领窗口 → 无人认领则由 AI-profile 以正确的 template 开启对话,objective = qualify + 约时段;`[[OBJECTIVE_MET]]`/handoff 语义都已存在。直接攻击 Report 1 的第一发现(9,651 个从未被跟进的 lead)。
2. **Pre-call/pre-meeting brief。** 任何 appointment 前(calendar + Zoom 已挂 lead),从 timeline 生成一页 brief:上次分析的 objections、portal 信号、funnel 来源、来自 playbook KB 的话术建议。App 内 + `Notifier` 双投递。
3. **Post-conversation actions。** analyzer 已输出 `next_steps` + `follow_up_date` — agent 把它变成*提议的* appointment + 已起草的 follow-up 消息,销售一键批准。堵上「洞察死在抽屉里」的缺口。
4. **Attendance follow-up agent。** Webinar 结束 → 出席但不在任何 pipeline 的人收到个性化 follow-up 序列(webinar summary 就绪后可 transcript-aware);no-show 走重邀 flow。全部机件(出席、flows、campaign 触发)都已存在。
5. **Referral 与 renewal agents。** Stage 3 的 ripeness 排序 worklist 变成一个在正确时机(交楼后窗口)起草 referral ask、一键发送的 agent;membership 续费(452 个 subscription)同法炮制。

### C5. 「Master Brain」— 编排层(您的构想,加一条纪律警告)

把它建成**事件驱动的 next-best-action 引擎,而不是放养的 multi-agent 社会。**

- **骨架:** timeline 事件(C1)→ 规则优先的 policy 表(在 Manage 里可编辑,就像今天的 flows)→ 由 channel agents(C4)执行动作,每类动作分三档自主权:*suggest*(进人工队列)→ *draft*(已备好,一键发)→ *auto*(在 guardrail 内自动,例如营业时间、消息上限)。每个动作连同触发原因入日志 — 可审计的决策链。
- **LLM 在边缘**(分类意图、打分、起草、总结),**代码在中间**(路由、时机、限额)。只有当规则被证明表达不了某个决策点时,才把那个点升级给 LLM planner。这是真正能上线的系统与 [orchestration-theater 演示](https://blog.on-demand.io/the-future-of-ai-agents-2/)的分野;连 Anthropic 自家的 [multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system) 也只把 multi-agent 展开留给真正开放式的任务,并报告其成本约为单次 chat 的 15 倍 tokens。
- **Lead scoring 内置其中:** 先启发式(出席 + portal 行为 + 消息新近度 + enrichment 有效性 + analyzer interest level → 分层),从第一天起记录 score-vs-outcome,等 booking 标签积累够了再考虑学习型模型(见 Part B 的诚实判断)。

### C6. Coaching agent(被低估的赢面)

把 analyzer 的 `sales_performance` 分数 + strengths/improvements 按 agent 聚合到其全部录音上,对照 closing playbook(C3),每周经 Telegram 投递:2–3 个具体训练点 + 本周最佳/最差通话。数据今天就齐,新增采集≈零。

### C7. 建设顺序与粗略工作量

| Phase | 周数 | 交付物 | 依赖 |
|---|---|---|---|
| 0 | 1–2 | Lead Timeline service + 事件流;`AiClient` tool-use 支持;booking 数据采集修复(Report 1 #2) | — |
| 1 | 3–4 | Copilot v1(页面 + lead/inbox drawer、read tools、draft-only 写);KnowledgeBase service + playbook 上传 UI | 0 |
| 2 | 3–4 | Speed-to-lead SDR agent;pre-call briefs;post-conversation 提议动作;coaching 周报 | 0–1 |
| 3 | 4–6 | 编排器(policy 表 + 自主权分档 + 审计日志);启发式 lead scoring;attendance 与 referral agents | 1–2 |
| 4 | 之后 | 学习型 scoring;voice/realtime agents;语料到量后的 embeddings 检索;tool 层的 MCP 打包 | 3 + 数据积累 |

### C8. 风险与 guardrails

- **WhatsApp 号码信誉**是渠道级的生存风险:保留现有限速/debounce,编排器加每 lead 出站上限 + 全局 kill-switch;auto-reply 恪守 active hours、超时降级为人工。
- **PDPA(马来西亚个资法):** 录音 + transcript 属个人数据 — 保留策略、badge/通话录音的同意姿态、以及现有「删音频留 tombstone」语义,在 agent 向客户引用 transcript 之前应过一次法务。
- **幻觉:** 把 `normalize()` 钳制模式推广到每个新的 structured output;draft 档以上的客户触达内容必须 template 锚定或 KB grounded。
- **成本:** `ai_requests` 已记成本 — 加按功能的每日预算 + 熔断(队列 lane 已有 breaker 原语),并在 Setting → AI Requests 页可视化。
- **评估:** 在提升自主权档位之前,用真实 threads/transcripts(语料现成)建一个小型 eval set,suggest→draft→auto 的晋级用测得的质量说话,不靠感觉。

---

## Part D — 给评审 AI model 的话

你在评审一个 Laravel/Inertia 房地产销售平台的提案。可索取/查验的 ground truth:`GUIDELINES.md`(架构规则)、`docs/modules_handbook/`(逐模块事实,尤其 `shared/ai`、`shared/conversation-analysis`、`manage/messages/whatsapp/*`、`manage/engagement`、`manage/leads`)、`src/Ai/Services/AiClient.php`、`LeadLinker` handbook,以及 Part B 的数据(实测,非估算)。值得挑战的关键主张:(1) Copilot v1 用 tool-use-over-APIs 而非 embeddings 优先;(2) workflows-first 编排 vs 自主 multi-agent;(3) 在成交标签稀薄的前提下「先造数据的 agent、后学数据的 model」这一顺序之赌;(4) 以 WhatsApp 为中心的渠道策略是否把风险过度集中在一个号码的信誉上;(5) 下方 Part E 的独立建议 — 其排序,以及是否应顶替 C7 建设顺序中的某些项。

---

## Part E — 独立建议(brief 之外)

C2–C5 回应的是 CEO 的 brief;这一部分是作者自己的押注 — brief 没有要求、但每一条都锚定在 Part B 的某个实测事实上。**完整版(每个 idea 的理由、依赖与风险):[独立提案 — 11 个 World-Class AI Ideas(中文)](./2026-07-28-ai-independent-ideas-zh.md)。** 评审用摘要:

| # | Idea | 一句话 | 数据依据 |
|---|------|--------|----------|
| 1 | **Self-Writing Playbook** | 从自己的 transcripts 按 Converted vs Lost 挖掘 objection→rebuttal 模式 — KB 自己写自己;上传的书本只是种子 | ~1,900 份已分析 transcript + 98/79 成交标签 |
| 2 | **Self-Filling CRM** | Extraction agent 读对话、*提议* CRM 字段更新(suggest 档)— 不靠人的纪律也能采集数据 | 182 张 booking 0 张有 SPA price/bank/closer,而事实就在对话里 |
| 3 | **AI-as-the-Funnel** | 面向公众的 WhatsApp 楼盘顾问,盖在 catalog 上:webinar 机器旁边一条 24/7 的对话式获客渠道 | 15,528 楼盘 catalog;两个表单型 magnet 提交数为 0 |
| 4 | **Creative Loop** | CPL 衰减自动触发有据可查的广告变体生成 → Meta API → 度量 | 广告级归因 + AI Video 模块已存在 |
| 5 | **Campaign Factory** | 一句 brief → 横跨五个自家模块起草 landing + flows + ads,人工批准上线 | 五个模块都有内部 API |
| 6 | **Market Intelligence Radar** | 每周双语市场简报,挂钩 catalog 在售库存,经 Telegram 推送 | Notifier + catalog 已存在 |
| 7 | **Buyer Simulator** | 用真实挖掘的 objections 构建 AI 买家训练新人,由与真实通话同一个 analyzer 打分 | 语料 + 打分器已存在 |
| 8 | **AI Loan Companion** | 基于现有 WhoPay/CCRIS 解析 + bank-rules simulator 的 WhatsApp 贷款陪跑 agent — 打在马来西亚成交的头号杀手上 | Wealth 模块已具备原语 |
| 9 | **Membership Success Agent** | 以 LMS 参与度驱动的 churn 预防与续费触达 | 452 个 subscription、8 条 lesson progress(这本身就是信号) |
| 10 | **Lost-Deal Marketplace** | 把 Lost engagements(带预算+偏好的需求数据)匹配到 Concierge 卖/租委托 — 需求循环成为系统属性 | 79 个 Lost + concierge 供给在同一条 `lead_id` 主线上 |
| 11 | **Project-Launch War Room** | 新盘上架 → AI 反向扫描全部 lead 的历史信号 → 按匹配度排序的 call list,每人附理由 | 9,846 个 lead 的信号;Copilot v1 之后近乎免费 |

作者排序:#2 → #1 → #11 → #8 → #3(试点)→ #7 → #10 → 增长层(#4/#5/#6/#9)。Brief 的提案让 AI *帮团队干活*;这批让公司*拥有竞争对手抄不走的资产* — 自我更新的 playbook、自我维护的 CRM、不休息的 funnel、不浪费 lead 的需求池。两条线共享 Phase 0–1 的地基。

---

## Part F — 两份上传的战略文件(2026-07-28 增补)

本报告首发后,CEO 提供了两份内部文件。此处摘要,供评审者看到完整拼图。

### F1.《petaV3 Cloud GPU Internal AI Deployment and Private AI Rollout Plan》(v1.0,2026-07-07,.docx)

一份工程级的**自建 AI 基础设施**推进计划,分三个阶段:

- **Test / Phase 0(2–4 周):** 租用 cloud GPU(RunPod L40S 48GB / GCP L4 新加坡 / AWS G6),用 **vLLM** 以 OpenAI-compatible API 部署开源模型(先 **Qwen 14B**,必要时 32B quantized),前置 gateway;在 petaV3 现有 AI provider 层新增 **`internal_ai` provider**;试点 1–3 个文本功能(AI Conversations、用 20–50 份 transcript 对比 ConversationAnalyzer、WhatsApp draft 模式);明确 Go/No-Go 标准(API 成功率 ≥95%、简单请求 3–10 秒、JSON 失败率 <5–10%、质量评分 ≥3.5/5)。
- **Phase 1(1–3 个月):「PropertyLab Internal AI Brain」** — 私有数据 RAG(**Qdrant** 向量库;按数据源分 chunking 策略;PII 脱敏;检索时**服务端权限过滤**),五个内部功能(Lead Summary Copilot、Sales Next Action、WhatsApp Draft Assistant、Marketing/Video Brief Assistant、Management Dashboard Chat),50–100 题 eval 套件,成本报告,以及是否购买 on-prem GPU 的决策。
- **Phase 2:产品化为「面向房地产公司的 Private AI」** — 按客户完全隔离的部署(private cloud / on-prem / hybrid),pilot SOP,打包(「PropertyLab Private AI Suite」),**NVIDIA certification** 增信。

难得的纪律性 non-goals:验证前不买硬件、不做模型预训练、WhatsApp 不经人审不自动发送、内部 POC 未证实前不做外部部署。

### F2.《PETA Global Architecture — 一套代码 · 两个外壳 · 一个大脑 · 一个飞轮》(.md)

一份把 **PETA 定位为房地产经纪的 AI coaching layer** 的战略叙事,横跨两个市场:

- **两个区域节点:** 中国(经纪在 **WeCom/企业微信**里工作;聊天经会话存档/Finance SDK 采集;备案的境内模型 DeepSeek/Qwen;按 **PIPL** 数据不出境)与国际(PropertyLab 自有 CRM;Claude/GPT 落在新加坡节点)。同一个 repo、同一套 event schema;跨境流动的只有**方法论与匿名聚合基准**。
- **五触点**(chat / 电话 / 视频会议 / 智能工牌 / 官网-App)由**适配层**归一为一套 event schema。
- **飞轮 — 真正的产品论点:** CAPTURE(指标:覆盖率 ≥80%)→ **LABEL(结果回填 join:对话 × 成交结果 — 文中称「所有人都跳过的接触点」,即护城河)** → LEARN(月度规则更新 + 区域 **LoRA**)→ GUIDE(动作状态机 `pushed → read → executed`;一键 Send 按钮就是采纳率传感器)→ **MEASURE(采纳组 vs 未采纳组的 uplift A/B,North-Star 指标,也是 performance-based billing 的基础)**。建设顺序 **v0 手动 → v1 自动化 → v2 训练** —「别先造训练管线,那是没接油路的引擎」。
- 文件自己也诚实划界:今天真实上线的是 portal 事件分析(30,156 events / 7 个已识别用户);双节点飞轮是 roadmap。

**给评审者的一个重要观察:** F2 的实际页面(`/admin/analytics/overview`、`ih_user_events`、`InvestHink\AnalyticsController`、Blade 视图)属于**另一个 codebase**(propertylabglobal.com),不是 petav3 —「一套代码」的理想目前是*两套代码*,谁并入谁,两份文件都还没有决定、也没有排期。

## Part G — 评估:可行性、方向对不对、算不算 deep tech

### G1. 方向对吗?对 — 而且三份计划的共识比它们自己知道的还多

我能给 F2 飞轮论点的最强背书是:本报告在**读到它之前**就独立得出了相同结论 — F2 的 **LABEL** 阶段*就是* Part E 的 **Self-Filling CRM**(#2);它的「no labels → no flywheel」*就是* Part B 的诚实判断(成交标签太薄)和「先造数据、后学数据」的押注;它的 GUIDE 采纳状态机*就是* C5 的 suggest→draft→auto 分档 + 审计;它的 MEASURE uplift *就是* C8 的评估 guardrail 升格为 North Star。三份独立写成的文件都收敛到「outcome-labeled closed loop 才是护城河」— 这是信号,不是巧合。

### G2. 可行性,说实话

- **飞轮(F2):可行且正确,但有一个警告。** v0 手动先行的纪律完全正确。风险是*组织性的*,不是技术性的:飞轮第一阶段是覆盖率,而今天的覆盖是真实但偏科的(1.9 万条 WhatsApp、1,694 条 Zoom 录音 — 但工牌只有 4 条、click-event 为 0、booking 字段全空)。飞轮从 LABEL join 被填上的那天才真正转起来 — 这就是下面 6 个月计划把 Self-Filling CRM 排第一的原因。
- **自建模型(F1):技术上成立,但要想清楚*为什么做*。** 以当前用量(`ai_requests` 总共 764 条)自建**省不了钱** — 这个规模的 API 调用费是零头,一台 24/7 的 L40S 比现在全部 AI 账单还贵。质量也是真实风险:Qwen 14B/32B 在中英夹杂的销售分析上大概率落后 Claude/Gemini(计划自己的 eval 关卡也承认这点)。*正确*的理由是计划里点到为止的那几个:(a) **Phase 2 本身是产品** — 卖给不愿把 WhatsApp 记录交给公共 API 的中介公司,数据主权就是卖点;(b) **中国**,备案境内模型是硬性要求;(c) 议价筹码与可迁移性。把 Phase 0 当作低成本的产品研发来跑(约一个工程师·月 + GPU 租金),不要当作基础设施迁移 — 并且永久保留 fallback 链。
- **中国节点(F2):战略上自洽,操作上为时过早。** WeCom Finance SDK、境内 GPU、模型备案、本地主体/伙伴、PIPL 合规 — 这是一次市场进入,不是一个 feature。现在就*为它设计*(适配层的 event schema *就是* C1 的 LeadTimeline;`AiClient` 本来就 provider-agnostic),但只有拿到有承诺的中国锚定客户或伙伴才*动手建*。
- **Performance-based billing(F2):有差异化,但很难。** Uplift 归因天然招争议(季节性、盘源结构、谁算「已采纳」)。建议混合定价 — 基础订阅 + 按*双方共同认可的* uplift 度量算成功费 — 且先在内部把 MEASURE 跑满 ≥2 个季度。

### G3. 算不算 deep tech?直接回答

**按当前范围:不算,而且这没关系。** vLLM + 开源模型 + Qdrant + RAG + LoRA 是对现有开放技术的世界级*系统集成* — vertical applied AI,不是原创研究。对投资人讲 deep tech 会招来错误的审视。真正可防守、而且比多数 deep-tech 故事更稀有的是:(1) **专有的 outcome-labeled 对话数据集**及其上的 uplift 度量闭环 — 会复利、买不到的 data moat;(2) **在专有数据上做的区域 LoRA fine-tune** — 随语料增长逐渐向 deep tech 靠拢的 applied ML;(3) **跨境分区部署方法论** — 少有对手愿意复刻的合规工程。就马来西亚生态而言(Cradle / MDEC / MRANTI 等项目),一个带专有微调模型、可测量 uplift 的 vertical AI 平台,申报 deep-tech 相邻类别是站得住的;但对外的*故事*要立在 closed loop 上,不要立在标签上。

## Part H — 未来 6 个月:一份合并后的优先计划(2026-08 → 2027-01)

把本报告的 C7、F1 的阶段、F2 的飞轮阶段合并成一条时间线。总原则:**飞轮现在就用手动流程 + API 模型转起来;自建模型是并行的研发线,必须靠 eval 成绩挣到上场资格。**

| 月份 | 飞轮阶段 | 交付物 | 出处 |
|---|---|---|---|
| **1 · 8月** | CAPTURE + v0 手动闭环 | LeadTimeline service + 事件流;`AiClient` tool-use;booking 采集修复 + speed-to-lead SLA 队列;**每周手动复盘仪式**(已评分通话 → 手工更新规则)立即开始 — 不需要 GPU。并行:**F1 Phase 0 POC**(cloud GPU、vLLM、`internal_ai` provider、20–50 份 transcript 评测)。 | C1 / R1#1–3 / F1 §6 / F2 v0 |
| **2 · 9月** | LABEL | **Self-Filling CRM** extraction agent(suggest 档)— *结果回填率成为被追踪的 KPI*;Copilot v1(tool-use chat + lead/inbox drawer、只做草稿的写操作);KnowledgeBase service + playbook 上传。POC 按 F1 自己的关卡做 **Go/No-Go**。 | E#2 / C2–C3 / F1 §6.5 |
| **3 · 10月** | GUIDE | Channel agents 第一波:speed-to-lead SDR、pre-call briefs、post-conversation 提议动作;coaching 周报;每条 AI 建议接上**采纳状态机**(`pushed → read → executed` — F2 的传感器)。 | C4 / C6 / F2 第4阶段 |
| **4 · 11月** | LEARN(规则) | 编排器 v1(policy 表 + 自主权分档 + 审计日志);启发式 lead scoring 并记录 score-vs-outcome;Self-Writing Playbook v1(每月挖掘赢/输模式回灌 KB);POC 若通过,把 draft 档功能在 eval 达标处迁移到 `internal_ai`;内部 case study 起草。 | C5 / E#1 / F1 §7 |
| **5 · 12月** | MEASURE | **Uplift A/B 上线**(采纳组 vs 未采纳组)— North-Star 指标开始出报表;attendance + referral agents;多租户隔离设计(F1 Phase 2 预备);1–2 名工程师考 NVIDIA certification;transcript 使用的 PDPA/法务审查。 | F2 第5阶段 / C4 / F1 §8–9 |
| **6 · 1月** | 产品化 | 选定并圈定一家外部 **pilot 中介**(F1 Phase 2 pilot SOP);混合定价草案;用内部 case study + 实测 uplift 搭 demo。**用数据做决策的两道闸:** on-prem GPU(仅当 POC + 用量撑得起)· 中国节点(仅当有承诺的伙伴/锚定客户)。 | F1 §8 / F2 §5 |

**这 6 个月的明确 non-goals**(延伸 F1 的清单):不建中国节点、不买 on-prem GPU、不做本地视频生成模型、不整体替换现有 provider、draft 档以上不向客户自动发送(除非草稿质量已被测量满 2 个月)、不被 codebase 合并分心 — petav3 ⇄ propertylabglobal 的归并在第 3 个月前要的是一个*决定*(哪个 repo 是产品主干),不是一次迁移。

**Sources:** [Salesmate — AI agent trends 2026](https://www.salesmate.io/blog/future-of-ai-agents/) · [Cflow — AI workflow automation trends 2026](https://www.cflowapps.com/ai-workflow-automation-trends/) · [SS&C Blue Prism — AI agent trends](https://www.blueprism.com/resources/blog/future-ai-agents-trends/) · [On-Demand — agentic AI automation](https://blog.on-demand.io/the-future-of-ai-agents-2/) · [Portkey — MCP vs RAG in production](https://portkey.ai/blog/mcp-vs-rag/) · [ProjectPro — MCP + RAG implementation](https://www.projectpro.io/article/mcp-with-rag/1144) · [Anthropic — multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)