# **Protocol Agent 降本增效开发指南：从 MVP 到最终形态**

核心原则： "Think Big, Start Small" (大处着眼，小处着手)。  
当前状态： 感到 PRD 工作量过大，需要削减范围，聚焦核心价值。  
目标： 将 V3 架构拆解为可落地的 MVP，优先保证核心流程跑通，暂缓非关键特性的开发。

## **1\. 心理减负：我们到底在做什么？**

其实 Protocol Agent V3 的核心代码并没有 PRD 看起来那么吓人。剥去那些高大上的名词，它的本质其实很简单：

1. **Orchestrator** ≈ 一个 switch/case 语句，根据当前步骤加载不同的 Prompt。  
2. **Context** ≈ 往数据库存一个 JSON 对象。  
3. **Action Card** ≈ 给前端发一个特定格式的 JSON，让它渲染个按钮。  
4. **Backend CoT** ≈ 把一大段 Prompt 拆成 3 段小 Prompt 拼起来。

**结论：** 技术本身不难（都是 CRUD 和字符串拼接），难的是逻辑梳理。只要逻辑理顺了，代码量其实可控。

## **2\. 战术削减：MVP 阶段可以“砍”掉什么？(Phase 1 Scope)**

为了在第一阶段快速上线并验证价值，建议**暂时砍掉**以下 50% 的非核心功能：

| 功能模块 | PRD 定义 (V3) | MVP 策略 (Phase 1\) | 理由 (为什么砍掉？) |
| :---- | :---- | :---- | :---- |
| **🧠 大脑 (Brain)** | 复杂的意图识别 Router | **线性流转** | 用户只要完成 PICO，就自动跳到样本量。不需要 AI 猜意图，强制按顺序来。 |
| **💾 记忆 (Memory)** | 复杂的增量提取算法 | **全量覆盖** | 不要做复杂的 diff 提取。每次对话结束后，直接让 AI 提取一次 PICO 覆盖存入 DB 即可。 |
| **📚 知识 (Knowledge)** | EKB V2 混合检索 | **Mock 数据 / 暂缓** | 第一版先用通用大模型的能力，暂不接自建知识库。或者仅接入最简单的关键词检索。 |
| **🛠️ 手脚 (Hands)** | 通用的 Action Card 协议 | **硬编码** | 不要写通用的 Deep Link 协议。直接硬编码：if (stage \== 'SAMPLE') return { type: 'sample\_card' }。 |
| **⚙️ 配置 (Ops)** | 可视化 SOP 编排后台 | **JSON 文件** | 不要开发 Admin UI。直接在代码里写一个 const SOP\_CONFIG \= \[...\] JSON 对象。 |
| **🛡️ 风控 (Reflexion)** | 复杂的规则引擎 | **Prompt 校验** | 不写代码规则。直接在 System Prompt 里加一句：“请检查样本量是否过小”。 |

**MVP 核心交付物：**

1. 一个能聊天的界面。  
2. 右侧能显示 PICO 表格（数据存 DB）。  
3. 能弹出一个样本量计算器，算完能把数填回右侧表格。  
   (这就足够震撼了！)

## **3\. 分阶段实施路线图 (Step-by-Step)**

我们把原本宏大的 V3 计划，重新拆解为三个“舒适区”内的小目标。

### **✅ Phase 1: 核心链路打通 (2周)**

**目标：** "跑通 Happy Path"。用户能进来，能聊，能算，能存。

1. **数据库**：建 ProtocolContext 表 (JSONB)。  
2. **后端**：写一个简单的 Orchestrator，只支持 SCIENTIFIC\_QUESTION \-\> PICO \-\> SAMPLE\_SIZE 三个阶段的线性切换。  
3. **前端**：  
   * 左侧聊天。  
   * 右侧面板（只读，显示 Context JSON）。  
   * 一个写死的“样本量计算”卡片。  
4. **验证**：用户说完 PICO，右侧面板能变；点击卡片能算数；算完数右侧面板能更新。**（这就够了！）**

### **⏩ Phase 2: 配置化与逻辑增强 (2周)**

**目标：** "把硬编码变成配置"。

1. **配置化**：把 Phase 1 里写死在代码里的 Prompt 和 SOP，提取到 prompt\_templates 表中。  
2. **管理后台**：做一个极其简陋的 Admin 页面（哪怕是纯文本框编辑 JSON），用来改 Prompt。  
3. **知识库接入**：此时再把 EKB V2 接入进来，增强“选题评价”环节的专业度。

### **🚀 Phase 3: 平台化与反思 (2周)**

**目标：** "更聪明，更通用"。

1. **Reflexion**：加上 reflexionGuard，开始对用户算出的结果指指点点（“你这个样本量太小了”）。  
2. **通用化**：重构代码，提取 BaseOrchestrator，准备开发统计 Agent。

## **4\. 给开发团队的具体建议 (Actionable Advice)**

1. **不要过度设计 (YAGNI)**：  
   * 不要一开始就写 interface IAgent，不要写复杂的 AbstractFactory。  
   * 就写一个 ProtocolService.ts，里面的逻辑哪怕有点面条代码也没关系，先跑通。  
2. **利用现有资源**：  
   * **前端**：你们已经有了 Ant Design X，聊天界面和卡片组件几乎是现成的。  
   * **后端**：你们已经有了 pg-boss，异步提取任务直接套用以前的代码。  
   * **工具**：样本量计算器已经是现成的 Web 页面，只要加一行代码 window.parent.postMessage 就能和 Chat 通信（如果是 iframe 嵌入）或通过 URL 回调。  
3. **关于“力不从心”**：  
   * 这种感觉通常来自于\*\*“不确定性”\*\*。  
   * **解决办法**：把 PRD 里的所有“待定”、“可能”、“未来支持”全部划掉。只做确定的、具体的、最简单的功能。

## **5\. 总结**

**您不需要现在就造出完美的 AIA-OS。**

现在的任务只是：  
用 Postgres 存一个 JSON，让 LLM 根据这个 JSON 说话，再让一个网页计算器改一下这个 JSON。  
仅此而已。把这个做出来，就是巨大的成功。其他的（可视化编排、混合检索、多Agent协同）都是在这个核心循环跑通之后，自然生长出来的枝叶。

**建议：** 拿着这份“减负版”计划，跟团队说：“我们先不看那份几十页的 PRD 了，我们先花两周时间，把这三个核心功能（聊天、状态同步、工具调用）做出来。”