Auto-sync: 2026-04-26 00:02

openclaw/每日复盘/2026-04-25.md

@@ -0,0 +1,39 @@
+## 【yunce】云策 每日复盘 - 2026-04-25
+
+### 执行时间
+15:25 UTC (23:25 北京时间)
+
+### 活动概述
+- 通过 cron 触发执行每日复盘任务
+- 尝试通过 Django Admin 获取日报
+
+### 日报查询结果
+- **目标 URL**: http://192.168.3.45:8765/admin/daily-reports/yunce/2026-4-25/
+- **结果**: 404 Not Found - 当天数据尚未生成
+
+### 观察
+1. **yunce agent 状态**：
+   - 2026-04-25 仍无活动记录
+   - 已连续 6 天（4月20-25日）无会话
+   - 这是 Product Manager 角色的正常状态
+
+2. **Django Admin 列表确认**：
+   - 筛选 yunce agent 后共有 13 个报告
+   - 最新报告日期：2026-04-19
+   - 4月20日-25日无记录
+
+3. **技术操作**：
+   - 使用 select @e19 "yunce" 筛选 agent
+   - 使用 get attr @e34 "href" 获取报告链接
+   - 多条命令连续执行会导致进程被 SIGKILL
+
+### 系统状态
+- Gateway 正常运行
+- Telegram 消息接收正常
+- cron 任务正常触发
+
+### 元数据
+- **日期**: 2026-04-25
+- **Agent**: yunce
+- **来源**: cron-task daily-review
+- **数据延迟**: 是

wiki/concepts/Content-Matrix-Strategy.md

@@ -0,0 +1,41 @@
+---
+title: "Content Matrix Strategy（内容矩阵策略）"
+type: concept
+tags: [content-marketing, short-video, multi-platform]
+sources: [marketing-douyin-strategist]
+last_updated: 2026-04-25
+---
+
+## Definition
+内容矩阵策略是通过在单一平台或跨平台布局多种内容类型的账号组合，实现流量来源多元化、用户触点覆盖最大化的内容运营方法论。
+
+## Core Framework
+在抖音平台，典型内容矩阵包含四类内容：
+
+| 类型 | 目的 | 典型时长 | 完播率目标 |
+|------|------|----------|------------|
+| 教育类 | 建立专业权威 | 30-60s | > 40% |
+| 剧情类 | 情感共鸣 | 15-30s | > 35% |
+| 产品测评类 | 种草转化 | 30-45s | > 38% |
+| Vlog类 | 人设打造 | 60-120s | > 30% |
+
+## Key Principles
+- **主账号**负责品牌定位和高价值内容
+- **子账号**承担垂类渗透和长尾流量
+- **员工账号**提供真实背书和日常互动
+- 内容类型之间互相引流，形成闭环
+
+## Applications
+- 抖音/快手短视频矩阵
+- 微信公众号/视频号矩阵
+- 小红书多品类账号矩阵
+- TikTok 海外市场矩阵
+
+## Related Concepts
+- [[MarketingDouyinStrategist]]：抖音平台内容矩阵的具体执行 Agent
+- [[CompletionRateOptimization]]：内容矩阵中每条视频的优化目标
+
+## Aliases
+- 内容矩阵
+- Content Matrix
+- Multi-format Content Strategy

wiki/concepts/Context-Passing.md

@@ -0,0 +1,25 @@
+---
+title: "Context Passing"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Context Passing（上下文传递）是多 Agent 协作中的记忆共享机制：Agent 之间不存在共享记忆，下一个 Agent 必须显式接收上一个 Agent 的完整输出作为输入上下文。
+
+## Details
+- **实现方式**：手动 copy-paste 或由 Orchestrator Agent 自动传递
+- **关键原则**：不要摘要，要使用完整输出
+- **与 [[Sequential Handoff]] 的关系**：Context Passing 是 Sequential Handoff 的技术基础
+
+## Aliases
+- Context Passing
+- 上下文传递
+
+## Related Patterns
+- [[Sequential Handoff]]
+- [[Orchestrator Agent]]（未来可自动化此过程）
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Feedback-Loop.md

@@ -0,0 +1,39 @@
+---
+title: "Feedback Loop"
+type: concept
+tags: [multi-agent, workflow-pattern, iteration, quality-assurance]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+后续 Agent（通常是 Reviewer/QA 角色）对前序 Agent 的产出进行审查，生成具体改进建议，前序 Agent 根据反馈修改后再交付的迭代机制。
+
+## Core Principle
+
+反馈必须是**具体的、可执行的**，而非泛泛的评价。"CTA 按钮颜色对比度不够"比"设计不够好"有价值一万倍。
+
+## Usage in The Agency
+
+- [[workflow-landing-page]]：Growth Hacker 审查 HTML 后给出具体修改意见 → Frontend Developer 15:30 前应用反馈并交付最终版本
+- [[workflow-startup-mvp]]：QA Auditor 检查第一版 → Dev 根据 Bug 报告修复 → Re-audit 循环直到达标
+- [[support-analytics-reporter]]：Analytics Reporter 生成报告 → 用户反馈 → 调整分析维度
+
+## Structure
+
+```
+[Agent A 产出 v1] → [Reviewer Agent B 审查] → [具体改进建议]
+       ↑                                              ↓
+       └──────────── [Agent A 修改后交付 v2] ←───────┘
+```
+
+## Key Requirements
+
+1. **Reviewer 必须独立于 Creator**——自己评审自己的产出无效
+2. **反馈必须有具体量化指标**——"降低 50ms 加载时间"比"优化性能"有用
+3. **时间盒必须保护修改时间**——反馈没有时间完成修改等于无效
+
+## Aliases
+- Review-Iterate Cycle
+- Quality Assurance Loop
+- Iteration Cycle

wiki/concepts/Golden-3-Second-Hook.md

@@ -0,0 +1,55 @@
+---
+title: "Golden 3-Second Hook（黄金3秒钩子）"
+type: concept
+tags: [short-video, copywriting, attention-economy, douyin]
+sources: [marketing-douyin-strategist]
+last_updated: 2026-04-25
+---
+
+## Definition
+黄金3秒钩子是指短视频开头3秒内通过特定的创作技巧，在算法推荐之前就抓住观众注意力的开场设计策略。是抖音/短视频完播率优化的第一道关卡。
+
+## Four Hook Types
+
+### A. 冲突型（Conflict Hook）
+**公式**："除非你看完这个，否则不要做XXX"
+**原理**：制造认知冲突，触发好奇心
+**示例**："买二手房之前没看这个视频，你亏大了"
+
+### B. 价值型（Value Hook）
+**公式**："XX元解决了困扰我X年的问题"
+**原理**：具体数字锚定价值感
+**示例**："花200块解决了困扰我三年的失眠问题"
+
+### C. 悬念型（Suspense Hook）
+**公式**："XX行业有一个他们不想让你知道的秘密"
+**原理**：信息不对称引发窥探欲
+**示例**："服装店老板打死不会告诉你的砍价技巧"
+
+### D. 共鸣型（Relatability Hook）
+**公式**："有没有人和我一样，每次XXX就崩溃？"
+**原理**：情感共鸣触发评论互动
+**示例**："有没有人和我一样，一刷手机就停不下来"
+
+## Relationship to Completion Rate
+- 钩子决定前三秒留存
+- 前三秒留存影响算法初始流量池评级
+- 初始评级决定是否进入更大的流量池
+- **因此：钩子质量决定整条视频的天花板**
+
+## Key Metrics
+- 前3秒跳出率（< 20% 为优秀）
+- 5秒完播率（> 50% 为优秀）
+- 与整体完播率正相关
+
+## Related Concepts
+- [[CompletionRateOptimization]]：黄金钩子是完播率优化的核心组成部分
+- [[ContentMatrixStrategy]]：不同内容类型适用不同钩子策略
+- [[VideoPacing]]：钩子之后的内容节奏同样关键
+
+## Aliases
+- 黄金3秒
+- 开头钩子
+- Hook
+- Attention Hook
+- 短视频开场策略

wiki/concepts/Memory-Based-Handoff.md

@@ -0,0 +1,28 @@
+---
+title: "Memory-Based Handoff"
+type: concept
+tags: [multi-agent, memory, handoff, workflow]
+last_updated: 2026-04-26
+---
+
+## Definition
+
+一种多 Agent 协作中的交接模式，通过外部记忆服务器（而非人工复制粘贴）实现 Agent 间的上下文传递。当一个 Agent 完成工作时，将交付物存储到共享记忆服务器；下一个 Agent 通过 recall 操作自动检索所需上下文，无需人工干预。
+
+## Core Mechanism
+
+1. **存储（remember）**：Agent 完成任务后，将交付物快照存入记忆服务器，带上项目标签（如 `retroboard`）和接收方标签（如 `frontend-developer`）
+2. **召回（recall）**：下一个 Agent 激活时，通过 recall 操作按标签检索历史记忆，自动获取上一个 Agent 的交付物
+3. **无需人工粘贴**：人类不再充当"粘合剂"，记忆服务器接管上下文传递
+
+## Aliases
+- Memory-Based Handoff
+- MCP Memory Handoff
+
+## Related Patterns
+
+- [[Sequential Handoff]]：前身模式——必须人工复制粘贴完整输出，Memory-Based Handoff 将其升级为自动召回
+- [[Memory-Based Handoff]] ← enabled_by ← [[MCP Memory Server]]
+
+## Source
+- [[workflow-with-memory]]：完整工作流文档，包含 4 周 MVP 场景下的 Memory-Based Handoff 实践

wiki/concepts/Merge-Point.md

@@ -0,0 +1,32 @@
+---
+title: "Merge Point"
+type: concept
+tags: [multi-agent, workflow-pattern, dependency-management]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+工作流中的特定节点——多个并行分支的输出在此处合并，触发下一阶段的执行。所有上游分支必须在此点完成。
+
+## Core Principle
+
+下游 Agent 明确声明其所需的**上游输出集合**，只有当全部上游输出就绪后，才开始工作。这是 Multi-Agent 协作中的关键依赖管理机制。
+
+## Usage in The Agency
+
+- [[workflow-landing-page]]：**Frontend Developer** 的合并点是 `Content Creator 输出 + UI Designer 输出`。两者未完成之前，Frontend Developer 无法开始。
+- [[workflow-startup-mvp]]：**Build Phase** 是合并点，需要 API Spec（Backend Architect）+ UI Spec（UI Designer）+ 增长计划（Growth Hacker）全部就绪
+- [[scenario-enterprise-feature]]：**Integration Phase** 需要 Backend 输出 + Frontend 输出 + QA 测试计划全部合并
+
+## Anti-Pattern
+
+不要将合并点设计为"等待最慢的一个"——应该在设计阶段就估算各分支的执行时间，必要时：
+- 对快速分支添加有价值的额外任务（如性能基准测试）
+- 对慢速分支进行拆分加速
+- 将非关键输出从合并点移除
+
+## Aliases
+- Convergence Point
+- Synchronization Barrier
+- Handoff Point

wiki/concepts/Multi-Agent-Orchestration.md

@@ -0,0 +1,33 @@
+---
+title: "Multi-Agent Orchestration"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Multi-Agent Orchestration（多 Agent 编排）指通过预定义的 Agent 角色、交接顺序和质量门控，将多个专业 Agent 组织为流水线化协作体系的过程。
+
+## Details
+- **核心组件**：
+  1. 角色定义（Sprint Prioritizer、UX Researcher、Backend Architect 等）
+  2. 交接协议（[[Sequential Handoff]] + [[Context Passing]]）
+  3. 并行策略（[[Parallel Agent Work]]）
+  4. 质量保证（[[Quality Gate]]）
+- **自动化前景**：引入 [[Orchestrator Agent]] 可替代手动编排，实现全自动化流水线
+- **适用场景**：复杂多角色协作任务（SaaS 开发、内容生产、研究分析等）
+
+## Aliases
+- Multi-Agent Orchestration
+- 多 Agent 编排
+- Agent Orchestration
+- Agent 编排
+
+## Related Patterns
+- [[Sequential Handoff]]
+- [[Parallel Agent Work]]
+- [[Quality Gate]]
+- [[Context Passing]]
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Parallel-Agent-Work.md

@@ -0,0 +1,25 @@
+---
+title: "Parallel Agent Work"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Parallel Agent Work（并行 Agent 工作）指多个独立 Agent 在同一阶段同时激活，各自处理不相互依赖的任务，从而压缩项目时间线。
+
+## Details
+- **应用场景**：Week 1 中，Sprint Prioritizer 和 UX Researcher 可并行激活
+- **条件**：两个 Agent 的任务无相互依赖，可独立产出
+- **收益**：将 2 个串行步骤合并为 1 个时间单位，节省约 50% 时间
+
+## Aliases
+- Parallel Agent Work
+- 并行 Agent 工作
+
+## Related Patterns
+- [[Sequential Handoff]]
+- [[Context Passing]]
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Parallel-Kickoff.md

@@ -0,0 +1,38 @@
+---
+title: "Parallel Kickoff"
+type: concept
+tags: [multi-agent, workflow-pattern, parallelization]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+多个独立 Agent 任务在同一时间并行启动，彼此之间没有数据依赖，无需等待对方完成即可开始执行。
+
+## Core Principle
+
+只有当两个工作流**产出互相独立**时，才适合并行启动。如果一个任务的输出是另一个的输入，则必须串行。
+
+## Usage in The Agency
+
+- [[workflow-landing-page]]：Content Creator 与 UI Designer 在上午 9:00 同时启动，两者输出（文案 + 设计稿）互不依赖
+- [[workflow-startup-mvp]]：Backend Architect、Frontend Developer、Growth Hacker 在 Week 2 并行启动
+- [[scenario-marketing-campaign]]：文案、视觉、增长策略并行输出
+
+## Implementation
+
+```
+Agent A ──┐
+          ├──► [合并点]
+Agent B ──┘
+```
+
+并行启动的条件：
+1. 两者输出没有依赖关系
+2. 两者不写入同一个共享状态（除非有锁机制）
+3. 执行时间相近（避免一个等待另一个过长）
+
+## Aliases
+- Parallel Activation
+- Concurrent Kickoff
+- Independent Parallel Execution

wiki/concepts/Quality-Gate.md

@@ -0,0 +1,27 @@
+---
+title: "Quality Gate"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Quality Gate（质量门控）是在关键里程碑设置的质量评估检查点，由 [[Reality Checker]] 评估产出是否满足继续推进的条件，防止有缺陷的代码或计划进入下一阶段。
+
+## Details
+- **典型位置**：
+  1. Week 2 中点——评估是否能在剩余 2 周内完成
+  2. Week 4 发布前——评估生产就绪状态（GO/NO-GO）
+- **评估维度**：时间可行性、功能裁剪建议、技术债务风险
+- **决策结果**：GO（可继续）或 NO-GO（需回滚修复）
+
+## Aliases
+- Quality Gate
+- 质量门控
+
+## Related Patterns
+- [[Reality Checker]]（具体执行角色）
+- [[Sequential Handoff]]
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Sequential-Handoff.md

@@ -0,0 +1,27 @@
+---
+title: "Sequential Handoff"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Sequential Handoff（顺序交接）是 [[workflow-startup-mvp]] 中定义的多 Agent 协作核心模式：每个 Agent 的完整输出作为下一个 Agent 的输入，形成流水线。
+
+## Details
+- **原则**：不摘要、不压缩，完整粘贴上一 Agent 的输出
+- **原因**：Agent 之间无共享记忆，必须显式传递完整上下文
+- **与 [[Context Passing]] 的关系**：Context Passing 是实现 Sequential Handoff 的具体技术手段
+
+## Aliases
+- Sequential Handoff
+- 顺序交接
+- Sequential Hand-off
+
+## Related Patterns
+- [[Context Passing]]
+- [[Quality Gate]]
+- [[Parallel Agent Work]]
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Time-Boxing.md

@@ -0,0 +1,42 @@
+---
+title: "Time Boxing"
+type: concept
+tags: [project-management, workflow-pattern, scope-control]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+为每个工作阶段设定严格的时间上限（Time Box），无论该阶段是否"完成"，时间到达后必须停止并交付当前状态，进入下一阶段。
+
+## Core Principle
+
+Time Boxing 是对抗"完美主义"和"范围蔓延"的武器——在敏捷/Scrum 中广泛使用，在 Multi-Agent 工作流中同样有效。
+
+## Usage in The Agency
+
+- [[workflow-landing-page]]：每个 Agent 任务都有明确的时间盒
+  - 09:00–11:00：Content Creator + UI Designer（2小时并行）
+  - 11:00–14:00：Frontend Developer 构建（3小时）
+  - 14:00：完成第一版
+  - 14:00–14:30：Growth Hacker 审查（30分钟）
+  - 15:30：应用反馈完成
+  - 16:30：交付上线
+- [[workflow-startup-mvp]]：每周一个阶段有明确交付物截止日期
+- [[scenario-incident-response]]：P0 事件 15 分钟必须恢复，P1 1 小时内解决
+
+## Why Time Box Works
+
+1. **催促决策**：没有无限时间，团队必须优先处理最重要的部分
+2. **可预测节奏**：所有参与者知道何时会有产出
+3. **避免过度工程**：不追求完美的 100 分，而是在时间限制内交付 80 分的价值
+4. **促进迭代**：第一版快速上线 → 收集真实反馈 → 下一轮 Time Box 改进
+
+## Anti-Pattern
+
+不要将 Time Boxing 变成"赶工"的借口。每个 Time Box 内部应该有明确的**最小可用产出（MVP）定义**，确保即使提前完成也能交付有价值的东西。
+
+## Aliases
+- Fixed Time Window
+- Time Limit Discipline
+- Sprint

wiki/entities/Backend-Architect.md

@@ -0,0 +1,24 @@
+---
+title: "Backend Architect"
+type: entity
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Backend Architect 是 [[workflow-startup-mvp]] 中负责设计完整 API 和数据模型的 Agent 角色，是前后端交接的关键桥梁。
+
+## Details
+- **输入**：Sprint Prioritizer 输出的冲刺计划 + UX Researcher 输出的调研简报
+- **输出**：
+  1. 数据库 Schema（SQL）
+  2. REST API 端点列表
+  3. WebSocket 实时事件规范
+  4. 认证策略建议
+- **执行时机**：Week 1 第三步，接收前两个 Agent 的输出
+
+## Aliases
+- Backend Architect
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/entities/Content-Creator.md

@@ -0,0 +1,34 @@
+---
+title: "Content Creator"
+type: entity
+entity_type: Agent Role
+tags: [content, copywriting, landing-page, the-agency]
+last_updated: 2026-04-25
+---
+
+## Role
+
+The Agency Design/Marketing 部门的文案撰写专家 Agent，负责为 landing page、产品介绍、营销材料等场景创作高质量文案。
+
+## In [[workflow-landing-page]]
+
+Content Creator 在上午 9:00 与 UI Designer 并行启动（[[Parallel-Kickoff]]），负责为 FlowSync（API 集成平台）撰写完整 landing page 文案：
+
+- **目标受众**：开发者和技术 PM，中型公司
+- **语调**：自信、简洁、略带趣味
+- **交付物结构**：
+  1. Hero（标题 + 副标题 + CTA）
+  2. Problem Statement（3个痛点）
+  3. How It Works（3步流程）
+  4. Social Proof（推荐语占位格式）
+  5. Pricing（3档：Free/Pro/Enterprise）
+  6. Final CTA
+
+## Aliases
+- Copywriter
+- Landing Page Copywriter
+
+## Related Agents
+- [[UI-Designer]]：并行搭档（[[workflow-landing-page]]）
+- [[Frontend-Developer]]：下游合并点（[[workflow-landing-page]]）
+- [[Growth-Hacker]]：内容审查（[[workflow-landing-page]]）

wiki/entities/Douyin.md

@@ -33,6 +33,20 @@ last_updated: 2026-04-25
 - 医疗广告须经过行业资质审核
 - 创意内容须经平台人工审核
 
+## Marketing & Short-Video Strategy
+- **推荐算法优先级**：完播率 > 点赞率 > 评论率 > 分享率
+- **黄金3秒原则**：前三秒决定视频生死，必须用冲突/悬念/价值钩子开场
+- **内容矩阵类型**：教育类、剧情类、产品测评类、Vlog类
+- **热门BGM**：每周追踪平台趋势热点
+- **限流红线**：视频内禁止引流外部平台
+
+## Key Agents
+- [[MarketingDouyinStrategist]]：The Agency 抖音短视频营销与直播带货策略专家
+
+## Connections
+- [[MarketingDouyinStrategist]] ← 核心 Agent ← [[MarketingShortVideoEditingCoach]]（内容剪辑支撑）
+- [[OceanEngine]] ← 广告投放平台 ← Douyin
+
 ## Aliases
 - 抖音
 - Douyin

wiki/entities/Frontend-Developer.md

@@ -0,0 +1,22 @@
+---
+title: "Frontend Developer"
+type: entity
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Frontend Developer 是 [[workflow-startup-mvp]] 中负责基于 API 规范构建 React 应用前端的 Agent 角色，是产品核心体验的实现者。
+
+## Details
+- **输入**：Backend Architect 输出的完整 API 规范
+- **技术栈**：React + TypeScript + Tailwind + Socket.io-client
+- **交付页面**：Login、Dashboard、Board View
+- **交付组件**：RetroCard、VoteButton、ActionItem、BoardColumn
+- **执行时机**：Week 2，与 Rapid Prototyper 并行工作
+
+## Aliases
+- Frontend Developer
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/entities/Growth-Hacker.md

@@ -0,0 +1,24 @@
+---
+title: "Growth Hacker"
+type: entity
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Growth Hacker 是 [[workflow-startup-mvp]] 中负责制定发布策略和增长计划的 Agent 角色，在 Week 3 与前端开发并行启动。
+
+## Details
+- **输入**：产品介绍、目标用户、零预算限制
+- **输出**：
+  1. 着陆页文案（Hero、Features、CTA）
+  2. 发布渠道（Product Hunt、Reddit、Hacker News、Twitter）
+  3. Day-by-day 发布序列
+  4. Week 1 关键指标定义
+- **执行时机**：Week 3，与 Frontend Developer 继续开发并行
+
+## Aliases
+- Growth Hacker
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/entities/OceanEngine.md

@@ -0,0 +1,34 @@
+---
+title: "Ocean Engine（巨量引擎）"
+type: entity
+tags: [platform, advertising, china, douyin]
+sources: [marketing-douyin-strategist]
+last_updated: 2026-04-25
+---
+
+## Overview
+巨量引擎（Ocean Engine）是字节跳动旗下的一站式数字化营销服务平台，为抖音、今日头条、西瓜视频等字节系产品提供广告投放服务，是抖音电商和品牌营销的核心商业化基础设施。
+
+## Core Products
+- **千川（Qianchuan）**：抖音电商广告投放平台，专注于直播带货和短视频带货广告
+- **品牌广告**：开屏广告、信息流广告、搜索广告等品牌曝光产品
+- **DOU+**：抖音原生内容加热工具，支持精准人群定向
+
+## Key Metrics
+- **GPM**（GMV per thousand views）：直播每千次观看产生的销售额，核心效率指标
+- **CVR**（Conversion Rate）：转化率，从观看→下单的比例
+- **ROI**：广告投入产出比，DOU+ ROI 基准 > 1:3
+
+## Douyin Marketing Integration
+- 付费广告（千川）与自然流量运营协同
+- DOU+ 用于测试内容方向和人群包
+- 矩阵账号运营配合付费投放放大效果
+
+## Key Agents
+- [[MarketingDouyinStrategist]]：依赖 Ocean Engine 工具进行付费流量策略规划
+
+## Aliases
+- 巨量引擎
+- Ocean Engine
+- 字节跳动商业化
+- 千川

wiki/entities/OrchestratorAgent.md

@@ -0,0 +1,21 @@
+---
+title: "Orchestrator Agent"
+type: entity
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Orchestrator Agent 是未来用于自动化多 Agent 工作流的编排 Agent，可替代手动 copy-paste 实现自动化流水线协作。
+
+## Details
+- **用途**：自动化 [[workflow-startup-mvp]] 中描述的手动 7 步多 Agent 流程
+- **核心能力**：自动触发专业 Agent、自动传递上下文、自动评估质量门控
+- **相关模式**：[[Sequential Handoff]]、[[Quality Gate]]、[[Context Passing]]
+
+## Aliases
+- Orchestrator Agent
+- Orchestrator
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/entities/Rapid-Prototyper.md

@@ -0,0 +1,20 @@
+---
+title: "Rapid Prototyper"
+type: entity
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Rapid Prototyper 是 [[workflow-startup-mvp]] 中负责快速产出第一个可运行版本的 Agent 角色，目标是尽快验证核心功能。
+
+## Details
+- **目标**：让第一个版本快速跑起来
+- **执行时机**：Week 2，与 Frontend Developer 并行工作
+- **质量门控**：产出需经 [[Reality Checker]] 评估后方可继续
+
+## Aliases
+- Rapid Prototyper
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/entities/Reality-Checker.md

@@ -0,0 +1,24 @@
+---
+title: "Reality Checker"
+type: entity
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Reality Checker 是 [[workflow-startup-mvp]] 中负责在关键里程碑评估生产就绪状态的质量门控 Agent，给出 GO/NO-GO 决策。
+
+## Details
+- **评估维度**：
+  1. 是否能在剩余时间内完成
+  2. 需要削减什么功能以满足截止日期
+  3. 哪些技术债务会在发布时反噬
+- **执行时机**：Week 2 中点和 Week 4 发布前
+- **决策输出**：GO（可继续）或 NO-GO（需回滚修复）
+- **触发回滚**：发现问题后回滚到对应专业 Agent 修复
+
+## Aliases
+- Reality Checker
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/entities/RetroBoard.md

@@ -0,0 +1,22 @@
+---
+title: "RetroBoard"
+type: entity
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+RetroBoard 是本文档中的示例 SaaS 产品——一个面向远程团队的实时团队回顾工具，4 周内从创意到 MVP 交付。
+
+## Details
+- **目标用户**：远程团队（5-20 人），包括工程经理和 Scrum Master
+- **核心功能**：用户注册、创建回顾板、添加卡片、投票、行动项
+- **技术栈**：React + TypeScript + Tailwind（前端），Node.js + Express + PostgreSQL + Socket.io（后端）
+- **部署**：Vercel（前端）+ Railway（后端）
+- **竞争对手**：EasyRetro、Retrium、Parabol
+
+## Aliases
+- RetroBoard
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/entities/Sprint-Prioritizer.md

@@ -0,0 +1,20 @@
+---
+title: "Sprint Prioritizer"
+type: entity
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Sprint Prioritizer 是 [[workflow-startup-mvp]] 中的第一个 Agent 角色，负责将项目拆解为可执行的周级冲刺计划。
+
+## Details
+- **输入**：项目名称、目标、时间线、核心功能、约束条件
+- **输出**：4 周每周一个有明确交付物和验收标准的冲刺计划
+- **执行时机**：Week 1 第一步，可与 UX Researcher 并行激活
+
+## Aliases
+- Sprint Prioritizer
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/entities/UI-Designer.md

@@ -0,0 +1,37 @@
+---
+title: "UI Designer"
+type: entity
+entity_type: Agent Role
+tags: [ui-design, visual-design, landing-page, the-agency]
+last_updated: 2026-04-25
+---
+
+## Role
+
+The Agency Design 部门的视觉界面设计专家 Agent，负责为 SaaS 产品 landing page 设计布局、配色、字体和组件规格。
+
+## In [[workflow-landing-page]]
+
+UI Designer 在上午 9:00 与 Content Creator 并行启动（[[Parallel-Kickoff]]），为 FlowSync（API 集成平台）设计完整的视觉规范：
+
+- **风格参考**：Linear / Vercel 美学，支持深色模式
+- **交付物结构**：
+  1. Layout Wireframe（版块顺序和间距）
+  2. Color Palette（主色/辅色/强调色/背景色）
+  3. Typography（字体配对、标题和正文尺寸）
+  4. Component Specs（Hero区/功能卡片/定价表/CTA按钮规格）
+  5. Responsive Breakpoints（Mobile/Tablet/Desktop）
+
+## Relationship with Other Agents
+
+- **并行搭档**：[[Content-Creator]]（两者在 [[workflow-landing-page]] 中并行启动，无依赖）
+- **下游合并点**：[[Frontend-Developer]] 等待 UI Designer 交付完整设计规范后开始构建（[[Merge-Point]]）
+
+## Aliases
+- Visual Designer
+- Landing Page Designer
+- UI Design Specialist
+
+## Related Agents
+- [[Content-Creator]]：并行搭档（[[workflow-landing-page]]）
+- [[Frontend-Developer]]：下游合并点（[[workflow-landing-page]]）

wiki/entities/UX-Researcher.md

@@ -0,0 +1,20 @@
+---
+title: "UX Researcher"
+type: entity
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+UX Researcher 是 [[workflow-startup-mvp]] 中负责快速用户调研和竞品分析的 Agent 角色，帮助识别产品的差异化方向。
+
+## Details
+- **输入**：目标用户画像、竞品列表
+- **输出**：1 页调研简报，包含：竞品标配功能、竞品短板、可差异化方向
+- **执行时机**：Week 1 第二步，与 Sprint Prioritizer 并行激活
+
+## Aliases
+- UX Researcher
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/index.md

@@ -4,6 +4,8 @@
 - [Overview](overview.md) — living synthesis
 
 ## Sources
+- [2026-04-25] [Marketing Douyin Strategist](sources/marketing-douyin-strategist.md)
+- [2026-04-25] [Nexus Spatial: Full Agency Discovery Exercise](sources/nexus-spatial-discovery.md)
 - [2026-04-25] [Multi-Agent Workflow: Startup MVP with Persistent Memory](sources/workflow-with-memory.md)
 - [2026-04-25] [Multi-Agent Workflow: Landing Page Sprint](sources/workflow-landing-page.md)
 - [2026-04-25] [Multi-Agent Workflow: Startup MVP](sources/workflow-startup-mvp.md)
@@ -416,9 +418,7 @@
 - [2026-04-21] [marketing-reddit-community-builder](sources/marketing-reddit-community-builder.md) — (expected: wiki/sources/marketing-reddit-community-builder.md — source missing)
 - [2026-04-21] [marketing-cross-border-ecommerce](sources/marketing-cross-border-ecommerce.md) — (expected: wiki/sources/marketing-cross-border-ecommerce.md — source missing)
 - [2026-04-21] [marketing-book-co-author](sources/marketing-book-co-author.md) — (expected: wiki/sources/marketing-book-co-author.md — source missing)
-- [2026-04-21] [marketing-zhihu-strategist](sources/marketing-zhihu-strategist.md) — (expected: wiki/sources/marketing-zhihu-strategist.md — source missing)
+- [2026-04-21] [Marketing Zhihu Strategist](sources/marketing-zhihu-strategist.md) — 知乎营销专家 Agent，通过专业知识分享建立思想领导力和精准获客
-- [2026-04-21] [marketing-douyin-strategist](sources/marketing-douyin-strategist.md) — (expected: wiki/sources/marketing-douyin-strategist.md — source missing)
-- [2026-04-26] [Nexus Spatial: Full Agency Discovery Exercise](sources/nexus-spatial-discovery.md) — 8个专业Agent并行协作，产出AI空间指挥中心产品完整规划（市场验证、技术架构、品牌策略、GTM、UX研究、项目执行方案）；验证SpatialAIOps新品类；确定2D先行、WebXR分发、调试为杀手级用例。
 - [2026-04-20] [security](sources/security.md) — (expected: wiki/sources/security.md — source missing)
 - [2026-04-20] [llm-wiki](sources/llm-wiki.md) — (expected: wiki/sources/llm-wiki.md — source missing)
 - [2026-04-20] [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing)
@@ -533,8 +533,6 @@
 - [engineering-ai-data-remediation-engineer](sources/engineering-ai-data-remediation-engineer.md) — (expected: wiki/sources/engineering-ai-data-remediation-engineer.md — source missing)
 
 ## Entities
-- [Nexus-Spatial](entities/Nexus-Spatial.md) — AI Agent 沉浸式 3D 命令中心；SpatialAIOps 新品类定义者
-- [CrewAI](entities/CrewAI.md) — 开源多 Agent 编排框架；100K+ 开发者；CLI-first，可视化能力有限
 - [Acemoglu](entities/Acemoglu.md)
 - [ACI-318](entities/ACI-318.md)
 - [Acronis](entities/Acronis.md)
@@ -611,6 +609,7 @@
 - [containerd](entities/containerd.md)
 - [Content-Creator](entities/Content-Creator.md)
 - [Coze](entities/Coze.md)
+- [CrewAI](entities/CrewAI.md)
 - [Cursor](entities/Cursor.md)
 - [Curve-Finance](entities/Curve-Finance.md)
 - [DanielStefanovic](entities/DanielStefanovic.md)
@@ -713,6 +712,7 @@
 - [Navidrome](entities/Navidrome.md)
 - [NetApp](entities/NetApp.md)
 - [Netdata](entities/Netdata.md)
+- [Nexus-Spatial](entities/Nexus-Spatial.md)
 - [NicholasCarlini](entities/NicholasCarlini.md)
 - [Niklas-Luhmann](entities/Niklas-Luhmann.md)
 - [NMPA](entities/NMPA.md)
@@ -723,6 +723,7 @@
 - [NotebookLlama](entities/NotebookLlama.md)
 - [NotebookLM](entities/NotebookLM.md)
 - [Obsidian](entities/Obsidian.md)
+- [OceanEngine](entities/OceanEngine.md)
 - [Octane-Hub](entities/Octane-Hub.md)
 - [Ollama](entities/Ollama.md)
 - [Open-Alliance-for-Cloud-Adoption](entities/Open-Alliance-for-Cloud-Adoption.md)
@@ -823,11 +824,6 @@
 - [苏东坡](entities/苏东坡.md)
 
 ## Concepts
-- [SpatialAIOps](concepts/SpatialAIOps.md) — 空间AI运营新品类；将空间计算引入 AI Agent 编排和监控
-- [Command Theater Interface](concepts/Command-Theater-Interface.md) — 命令剧院界面；以用户为中心的弧形空间布局范式
-- [Debugging Visualization](concepts/Debugging-Visualization.md) — 调试可视化；空间叠加运行时追踪于工作流结构之上；杀手级用例
-- [Semantic Zoom](concepts/Semantic-Zoom.md) — 语义缩放；4级导航范式，随缩放层级揭示不同粒度信息
-- [Growth Loop](concepts/Growth-Loop.md) — 增长飞轮；产品内生的自我强化增长机制
 - [14种UML图](concepts/14种UML图.md)
 - [7种视觉风格系统](concepts/7种视觉风格系统.md)
 - [ABTesting](concepts/ABTesting.md)
@@ -955,6 +951,7 @@
 - [Cognitive-Distortions](concepts/Cognitive-Distortions.md)
 - [Cognitive-Load-Reduction](concepts/Cognitive-Load-Reduction.md)
 - [Columnar-Storage](concepts/Columnar-Storage.md)
+- [Command-Theater-Interface](concepts/Command-Theater-Interface.md)
 - [Compaction](concepts/Compaction.md)
 - [Competition-Analysis](concepts/Competition-Analysis.md)
 - [Compliance-Automation](concepts/Compliance-Automation.md)
@@ -968,6 +965,7 @@
 - [Content-Creator](concepts/Content-Creator.md)
 - [Content-Hashing](concepts/Content-Hashing.md)
 - [Content-Ingestion](concepts/Content-Ingestion.md)
+- [Content-Matrix-Strategy](concepts/Content-Matrix-Strategy.md)
 - [Context-Passing](concepts/Context-Passing.md)
 - [Context-Substrate](concepts/Context-Substrate.md)
 - [Context-Window](concepts/Context-Window.md)
@@ -995,6 +993,7 @@
 - [Data-Sovereignty](concepts/Data-Sovereignty.md)
 - [DBA-Role-Evolution](concepts/DBA-Role-Evolution.md)
 - [DealHealthScoring](concepts/DealHealthScoring.md)
+- [Debugging-Visualization](concepts/Debugging-Visualization.md)
 - [DecisionFramework](concepts/DecisionFramework.md)
 - [Default-Bias](concepts/Default-Bias.md)
 - [Defense-in-Depth](concepts/Defense-in-Depth.md)
@@ -1087,9 +1086,11 @@
 - [Gitmoji-Commit](concepts/Gitmoji-Commit.md)
 - [GitOps](concepts/GitOps.md)
 - [Global-First-Architecture](concepts/Global-First-Architecture.md)
+- [Golden-3-Second-Hook](concepts/Golden-3-Second-Hook.md)
 - [GPG-密钥验证](concepts/GPG-密钥验证.md)
 - [Grandes-Ecoles](concepts/Grandes-Ecoles.md)
 - [Green-Computing](concepts/Green-Computing.md)
+- [Growth-Loop](concepts/Growth-Loop.md)
 - [Hand-Tracking](concepts/Hand-Tracking.md)
 - [Handoff-Contract](concepts/Handoff-Contract.md)
 - [HCX](concepts/HCX.md)
@@ -1339,6 +1340,7 @@
 - [Semantic-Index-Infrastructure](concepts/Semantic-Index-Infrastructure.md)
 - [Semantic-Search](concepts/Semantic-Search.md)
 - [Semantic-Versioning](concepts/Semantic-Versioning.md)
+- [Semantic-Zoom](concepts/Semantic-Zoom.md)
 - [Sequential-Handoff](concepts/Sequential-Handoff.md)
 - [Sequential-Thinking](concepts/Sequential-Thinking.md)
 - [Serverless-Computing](concepts/Serverless-Computing.md)
@@ -1366,6 +1368,7 @@
 - [Source-Grounding](concepts/Source-Grounding.md)
 - [Spatial-Computing](concepts/Spatial-Computing.md)
 - [Spatial-Widgets](concepts/Spatial-Widgets.md)
+- [SpatialAIOps](concepts/SpatialAIOps.md)
 - [Split](concepts/Split.md)
 - [Spot-Instances](concepts/Spot-Instances.md)
 - [SprintPlanning](concepts/SprintPlanning.md)

wiki/log.md

@@ -3588,3 +3588,12 @@
 - Entities created: 无（所有参与 Agent 和 RetroBoard 均已在 wiki 中存在，均以 wikilink 形式记录于 Source Page Key Entities 节）
 - Source page: wiki/sources/workflow-with-memory.md
 - Notes: index.md 原占位条目（2026-04-21 source missing）已替换为完整摘要；overview.md 新增 workflow-with-memory 段落，位于 Backend Architect with Memory 之后、multi-channel-assistant 之前；冲突检测：与 workflow-startup-mvp 在"是否需要人工复制粘贴"上存在表面冲突（实质为增强关系），已记录于 Source Page Contradictions 节——Memory 模式是原始工作流的增强层，Memory Server 可用时自动召回，不可使用时沿用手工粘贴策略。
+
+## [2026-05-05] ingest | Marketing Douyin Strategist
+- Source file: Agent/agency-agents/marketing/marketing-douyin-strategist.md
+- Status: ✅ 成功摄入
+- Summary: The Agency Marketing 部门的抖音短视频营销与直播带货策略专家 Agent 个性文档。核心能力：推荐算法（完播率 > 点赞率 > 评论率 > 分享率）、爆款视频策划（黄金3秒钩子）、流量运营（DOU+/矩阵账号）、直播带货（引流款/利润款/形象款/秒杀款结构）。交付物模板：短视频脚本结构（1-3秒黄金钩子 + 4-20秒核心内容 + 21-30秒收尾钩子）、直播产品结构表、2小时直播节奏规划。
+- Concepts created: [[Content-Matrix-Strategy]]（内容矩阵策略）、[[Golden-3-Second-Hook]]（黄金3秒钩子）
+- Entities created: [[OceanEngine]]（巨量引擎/千川广告平台）；[[Douyin]]（抖音平台）已更新，新增 Marketing & Short-Video Strategy 节
+- Source page: wiki/sources/marketing-douyin-strategist.md
+- Notes: index.md 原占位条目（2026-04-21 expected）已替换；overview.md 新增 Douyin Short-Video & Livestream Commerce 段落（TikTok E-commerce Product Management 之后）；Douyin.md 实体已更新（增加 Marketing & Short-Video Strategy 节）；冲突检测：与 [[MarketingTiktokStrategist]] 在算法权重优先级上存在差异——抖音以完播率为首要指标，TikTok 需平衡分享率与互动率，已记录于 Source Page Contradictions 节。

wiki/overview.md

@@ -718,6 +718,11 @@ A comprehensive Django-based product data management system for TikTok Shop. Cov
 
 Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]], [[Docker 容器化部署]], [[Django-Q 异步任务]], [[Bright Data API]], [[MySQL / MariaDB 数据库]], [[Gunicorn]], [[Nginx]], [[自定义管理命令]]
 
+### Douyin Short-Video & Livestream Commerce
+**[[marketing-douyin-strategist]]**（Marketing Douyin Strategist）：The Agency Marketing 部门的抖音短视频营销与直播带货策略专家 Agent——深度掌握抖音推荐算法机制、爆款视频策划与直播带货全链路，是国内电商流量运营的核心角色。**核心理念：抖音的核心不是"拍好看的视频"，而是"前三秒钩住注意力，让算法替你分发"**。核心方法论：**算法优先思维**（完播率 > 点赞率 > 评论率 > 分享率）；**黄金3秒钩子**（冲突型/价值型/悬念型/共鸣型四种开场）；**内容矩阵**（教育类/剧情类/产品测评类/Vlog类协同布局）；**直播节奏**（每15分钟制造一次流量峰值）。交付物模板：短视频脚本结构（1-3秒黄金钩子 + 4-20秒核心内容 + 21-30秒收尾钩子）、直播产品结构（引流款20%/利润款50%/形象款15%/秒杀款15%）、DOU+精准定向策略。与 [[marketing-tiktok-strategist]] 同属短视频平台策略，但算法权重不同——抖音以完播率为首要指标，TikTok 需平衡分享率与互动率。与 [[做TK跨境思路不对努力白费]]（TikTok 跨境电商运营）和 [[电商如何选品]]（选品策略）共同构成中国短视频电商知识体系；与 [[固定镜头短视频制作的AI全流程解析]]（AI视频制作）互补，后者侧重内容生产，前者侧重流量运营。
+
+**[[marketing-zhihu-strategist]]**（Marketing Zhihu Strategist）：The Agency Marketing 部门的知乎营销专家 Agent——将品牌打造为中国最大知识分享平台知乎上的思想领袖，通过专业知识分享建立权威并获取精准线索。**核心理念：信誉优先——在知乎，权威和真实专业度比粉丝数或推广推送重要得多**。核心方法论：六阶段工作流（话题定位→问题识别→高质量内容创作→专栏开发→关系建设→性能分析与优化）；信誉驱动内容标准（仅回答真正有可辩护专业知识的问答，每条主张必须有数据/研究/案例支撑）；知识驱动参与策略。关键交付物：专题权威映射（识别 3-5 个品牌应建立权威的核心话题）、问题选择策略、高质量答案模板库（最少 300 词）、专栏开发计划（6 个月内容日历）、影响力者关系列表、线索生成漏斗。成功指标：答案平均 100+ 点赞、每月 50-200 条精准线索、专栏每月 500-2000 新订阅者。与 [[marketing-douyin-strategist]] 同属 The Agency Marketing 部门中国平台矩阵——知乎侧重信誉驱动的深度内容（综合性回答最少 300 词），抖音侧重娱乐驱动的视觉内容（3-60 秒爆款），两者互补构建品牌在中国主流平台的全方位影响力。
+
 ### New Linux/DevOps Concepts (recently added)
 - **[[efibootmgr]]** — Linux NVRAM 启动项管理工具，可强制重写 BootOrder 解决 HP BIOS 固执行为
 - **[[ISOHybrid镜像]]** — 同时支持 BIOS 和 UEFI 引导的混合 ISO 镜像，Rufus 提供 ISO/DD 两种写入模式

wiki/sources/marketing-douyin-strategist.md

@@ -0,0 +1,54 @@
+---
+title: "Marketing Douyin Strategist"
+type: source
+tags: ["douyin", "short-video", "livestream-commerce", "marketing", "agent-personality"]
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/marketing/marketing-douyin-strategist]]
+
+## Summary（用中文描述）
+- 核心主题：抖音短视频营销与直播带货策略专家 Agent 个性文档，深度掌握抖音推荐算法、爆款视频策划、直播带货全链路
+- 问题域：短视频完播率优化、流量运营、DOU+投放策略、直播选品与话术设计、账号矩阵布局
+- 方法/机制：算法优先思维（完播率 > 点赞率 > 评论率 > 分享率）；黄金3秒钩子 + 信息密度 + 结尾悬念；直播15分钟流量峰值节奏控制
+- 结论/价值：提供可执行的短视频脚本模板、直播产品结构规划、流量运营 SOP，帮助实现视频完播率 > 35%、月粉丝增长 > 15%
+
+## Key Claims（用中文描述）
+- 完播率优先于点赞率、评论率和分享率，是抖音算法的首要权重
+- 前3秒决定一切——必须用冲突、悬念或价值钩子开场，不能铺垫
+- DOU+ 精准定向比砸钱更重要
+- 直播节奏：每15分钟制造一次流量峰值
+- 出镜人物视频完播率比纯产品展示高30%以上
+- 视频内禁止引流外部平台，否则触发限流
+
+## Key Quotes
+> "抖音的核心不是'拍好看的视频'，而是'前三秒钩住注意力，让算法替你分发'" — 抖音营销的本质
+> "完播率 > 点赞率 > 评论率 > 分享率——这是算法优先级顺序" — 流量分发逻辑
+> "别纠结滤镜，先每天发一条，让算法学习你的账号" — 执行优先原则
+
+## Key Concepts
+- [[CompletionRateOptimization]]：完播率优化策略——通过黄金3秒钩子、信息密度和结尾悬念提升视频完播率
+- [[ContentMatrixStrategy]]：内容矩阵策略——教育类、剧情类、产品测评类、Vlog类内容协同布局
+- [[DOUPlus]]：抖音原生投放工具，精准定向比预算更重要
+- [[LivestreamCommerce]]：直播带货——引流款(20%)/利润款(50%)/形象款(15%)/秒杀款(15%)产品结构设计
+- [[Golden3SecondHook]]：黄金3秒钩子——冲突型、价值型、悬念型、共鸣型四种开场模式
+- [[TrafficOperations]]：流量运营——发布时间优化、评论区互动、合集优化
+- [[VideoPacing]]：视频节奏控制——节拍剪辑、转场节奏、字幕韵律同步
+
+## Key Entities
+- [[Douyin]]：抖音（中国版 TikTok）平台，本 Agent 的主战场
+- [[OceanEngine]]：巨量引擎，抖音商业化广告平台，包含千川(Qianchuan)广告
+- [[DouyinBGM]]：抖音热门BGM，跟踪趋势热点
+
+## Connections
+- [[MarketingShortVideoEditingCoach]] ← feeds_into ← [[MarketingDouyinStrategist]]：短视频拍摄剪辑为策略提供素材支撑
+- [[MarketingKuaishouStrategist]] ← related_to ← [[MarketingDouyinStrategist]]：快手与抖音同为短视频平台，策略有互通性
+- [[MarketingChinaEcommerceOperator]] ← depends_on ← [[MarketingDouyinStrategist]]：抖音营销是电商运营的重要流量来源
+- [[MarketingVideoOptimizationSpecialist]] ← extends ← [[MarketingDouyinStrategist]]：视频优化专员在完播率和算法层面提供更深入的技术支持
+
+## Contradictions
+- 与 [[MarketingTiktokStrategist]] 存在平台规则差异：
+  - 冲突点：TikTok 与抖音的推荐算法权重不完全相同（TikTok 更注重分享率，抖音更注完播率）
+  - 当前观点：抖音策略以完播率为首要优化指标
+  - 对方观点：TikTok 策略需平衡分享率与互动率

wiki/sources/marketing-zhihu-strategist.md

@@ -0,0 +1,53 @@
+---
+title: "Marketing Zhihu Strategist"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/agency-agents/marketing/marketing-zhihu-strategist]]
+
+## Summary（用中文描述）
+- 核心主题：知乎营销专家 Agent，将品牌打造为知乎思想领袖，通过专业知识分享建立权威并获取精准线索
+- 问题域：品牌在中国最大知识分享平台知乎上的思想领导力建设、社区公信力建立、精准获客
+- 方法/机制：六阶段工作流（话题定位→问题识别→高质量内容创作→专栏开发→关系建设→性能分析与优化）+ 信誉驱动内容标准 + 知识驱动参与策略
+- 结论/价值：知乎是信誉优先平台，权威和真实专业度比粉丝数或推广推送重要得多；成功来自真实有用的内容，权威建立后商业结果自然跟进
+
+## Key Claims（用中文描述）
+- 知乎是信誉优先平台，权威和真实专业度比粉丝数更重要，推广推送无效
+- 仅回答真正有可辩护专业知识的问答（信誉是知乎的一切）
+- 综合性、有价值的内容是基础（大多数主题最少 300 词）
+- 每条主张必须有数据、研究、案例支撑以获得最大信誉度
+- 专栏开发是建立持续思想领导力和订阅者基础的必备策略
+- CTA 必须含蓄且有价值，从不硬推销
+- 成功衡量标准：答案平均 100+ 点赞、每月 50-200 条精准线索、专栏每月 500-2000 新订阅者
+
+## Key Quotes
+> "On Zhihu, you're building authority through authentic expertise-sharing and community participation. Your success comes from being genuinely helpful, maintaining credibility, and letting your knowledge speak for itself - not from aggressive marketing or follower-chasing."
+> "Credibility is everything on Zhihu"
+> "Never use aggressive sales language; let expertise and value speak for itself"
+> "Build real authority and the business results follow naturally."
+
+## Key Concepts
+- [[Thought-Leadership]]：通过专业知识分享建立品牌在行业中的可信、有知识权威声音
+- [[Community-Credibility]]：通过真实专业知识分享和社区参与赢得信任和权威
+- [[Strategic-Question-Answer]]：识别和回答高影响力问题以驱动曝光和参与
+- [[Content-Pillar]]：开发专有内容系列（专栏）以建立订阅者基础和权威
+- [[Lead-Generation-Funnel]]：通过战略定位和含蓄 CTA 将参与读者转化为精准线索
+
+## Key Entities
+- [[知乎]]（Zhihu）：中国最大知识分享平台，信誉优先平台，权威比粉丝数重要
+
+## Connections
+- [[Marketing Douyin Strategist]] ← 同属 ← [[Marketing Channel Strategy]]
+- [[Marketing Weibo Strategist]] ← 同属 ← [[Marketing Channel Strategy]]
+- [[Marketing Xiaohongshu Specialist]] ← 同属 ← [[Marketing Channel Strategy]]
+- [[Marketing Kuaishou Strategist]] ← 同属 ← [[Marketing Channel Strategy]]
+
+## Contradictions
+- 与 [[Marketing Douyin Strategist]] 冲突：
+  - 冲突点：内容长度与格式策略
+  - 当前观点：知乎需要综合性深度内容（最少 300 词），以数据、案例、研究支撑主张
+  - 对方观点：抖音侧重短平快视觉内容，15-60 秒内抓住注意力
+  - 说明：平台特性不同，策略自然分化——知乎是信誉驱动深度平台，抖音是娱乐驱动视觉平台，两者互补而非矛盾

wiki/sources/readme.md

@@ -1,40 +1,52 @@
 ---
-title: "OpenCode Integration"
+title: "Examples - Agency Multi-Agent Collaboration Showcase"
 type: source
 tags: []
-date: 2026-04-26
+date: 2026-04-25
 ---
 
 ## Source File
-- [[Agent/agency-agents/integrations/opencode/README.md]]
+- [[Agent/agency-agents/examples/README.md]]
 
 ## Summary（用中文描述）
-- 核心主题：OpenCode 的子 Agent 集成机制——如何将 .md 文件格式的 Agent 转换为 OpenCode 可调用的子代理
+- 核心主题：展示 agency-agents 中多个专业 Agent 如何协作完成真实任务的案例目录
-- 问题域：OpenCode IDE 中的多 Agent 协作与按需调用
+- 问题域：Agent 协作的实践价值证明——仅靠 Agent 定义无法展示多 Agent 联合部署的效果
-- 方法/机制：通过 YAML frontmatter 中的 `mode: subagent` 标记，将具名 Agent 从 Tab 循环列表中分离，改为按需 `@agent-name` 调用；颜色通过命名颜色到十六进制的自动映射实现
+- 方法/机制：通过具体案例回答"当全体 Agent 同时部署在同一任务上时会发生什么"这一问题
-- 结论/价值：提供了一种轻量级、无需修改主 Agent 系统的子 Agent 扩展方案，支持项目级和全局级两种安装范围
+- 结论/价值：8 个 Agent 并行运行，产出一致、相互引用的完整计划，无需协调开销
 
 ## Key Claims（用中文描述）
-- OpenCode Agent 通过在 `.opencode/agents/` 目录存储 .md 文件（带 YAML frontmatter）实现——文件格式与 The Agency 的 Agent 定义格式兼容
+- 8 个专业 Agent 并行运行，产出了连贯且相互引用的完整计划，无协调开销
-- `mode: subagent` 配置使 Agent 仅在 `@agent-name` 触发时出现，不会在 Tab 循环列表中占位——保持主 Agent 列表的简洁性
+- 多 Agent 协作可从"发现机会"到"完整蓝图"在单次会话中完成
-- 命名颜色（如 `cyan`）在安装脚本中被自动转换为十六进制颜色代码——无需手动查表
+- 好的案例应展示多个 Agent 协作、Agent 能力广度、真实世界适用性
-- Agent 支持两种安装范围：项目级（`.opencode/agents/`）和全局级（`~/.config/opencode/agents/`）——通过不同路径实现作用域隔离
-- 转换脚本 `./scripts/convert.sh --tool opencode` 负责将 The Agency 的标准 Agent 文件转换为 OpenCode 兼容格式
 
 ## Key Quotes
-> "mode: subagent — agent is available on-demand, not shown in the primary Tab-cycle list"
+> "What does it actually look like when the full agency collaborates?" — 核心问题
-> — Agent YAML frontmatter 的核心语义，说明 subagent 模式与普通 agent 的本质区别
+> "All 8 agents ran in parallel and produced coherent, cross-referencing plans without coordination overhead." — 核心成果
+> "Multiple agents collaborating on a shared objective" — 好案例的三要素之首
 
 ## Key Concepts
-- [[Subagent]]：按需调用的辅助 Agent，通过 `@agent-name` 语法触发，不参与 Tab 循环
+- [[Multi-Agent-Collaboration]]：多个专业 Agent 在同一任务上并行协作，通过共享上下文相互引用，无需显式协调
-- [[OpenCode]]：一个支持多 Agent 协作的 IDE/编辑器扩展平台
+- [[Agents-Orchestrator]]：多 Agent 开发流水线编排器，与本示例的"并行部署"同属 Agent 协作机制，后者强调编排层，前者强调执行层
 
 ## Key Entities
-- [[The Agency]]：OpenCode Agent 的来源框架，提供 147 个专业化 Agent 定义
+- [[Product-Trend-Researcher]]：产品趋势研究员——市场验证与竞争格局分析（示例中参与协作的 8 个 Agent 之一）
+- [[Backend-Architect]]：后端架构师——系统架构、数据模型、API 设计（示例中参与协作的 8 个 Agent 之一）
+- [[Design-Brand-Guardian]]：品牌守护者——定位、视觉身份、品牌命名（示例中参与协作的 8 个 Agent 之一）
+- [[Growth-Hacker]]：增长黑客——GTM 战略、定价、发布计划（示例中参与协作的 8 个 Agent 之一）
+- [[Support-Responder]]：支持响应员——支持层级、入职、社区建设（示例中参与协作的 8 个 Agent 之一）
+- [[UX-Researcher]]：用户体验研究员——用户画像、旅程地图、设计原则（示例中参与协作的 8 个 Agent 之一）
+- [[Project-Management-Project-Shepherd]]：项目看护者——阶段计划、Sprint、风险登记（示例中参与协作的 8 个 Agent 之一）
+- [[XR-Interface-Architect]]：XR 界面架构师——空间 UI 规范（示例中参与协作的 8 个 Agent 之一）
+- [[Nexus-Spatial-Discovery]]：具体的 8 Agent 并行协作案例——市场验证到技术架构到品牌策略到 GTM 计划的完整产出
 
 ## Connections
-- [[contributing]] ← 贡献来源 ← [[Agent/agency-agents/integrations/opencode/README.md]]
+- [[Nexus-Spatial-Discovery]] ← exemplifies ← [[Multi-Agent-Collaboration]]
-- [[The Agency]] ← Agent 定义来源 ← [[Agent/agency-agents/integrations/opencode/README.md]]
+- [[Multi-Agent-Collaboration]] ← extends ← [[Agents-Orchestrator]]
+- [[Multi-Agent-System-Reliability]] ← provides framework ← [[Multi-Agent-Collaboration]]
 
 ## Contradictions
-- （未检测到与其他页面的明显冲突）
+- 与 [[Multi-Agent-System-Reliability]] 中的"需显式协调机制确保一致性"：
+  - 冲突点：Multi-Agent-System-Reliability 强调需要结构化协调（主管→工作→验证链），但示例中 8 个 Agent 无需显式协调即产出连贯结果
+  - 当前观点：并行 Agent 通过共享上下文和独立产出实现自我协调
+  - 对方观点：幻觉和重复问题需通过架构约束（Consensus Voting / Adversarial Debate 等）强制解决
+  - 可能的调和：示例中"无需协调"可能是因为任务天然解耦；若 Agent 间存在依赖关系，仍需协调机制

wiki/sources/support-executive-summary-generator.md

@@ -0,0 +1,47 @@
+---
+title: "Executive Summary Generator Agent Personality"
+type: source
+tags: ["agent-personality", "consulting", "executive-communication", "business-analysis"]
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/support/support-executive-summary-generator.md]]
+
+## Summary（用中文描述）
+- 核心主题：咨询级 AI Agent，专为 C-suite 决策者生成高管执行摘要
+- 问题域：如何将复杂冗长的商业输入转化为简洁、可执行的高管级决策文档
+- 方法/机制：融合麦肯锡 SCQA、BCG 金字塔原理、贝恩行动导向建议三大咨询框架；采用严格的 325-475 词输出标准；所有发现必须量化
+- 结论/价值：让高管在 3 分钟内把握本质、评估影响、做出决策；辅助而非替代人类判断
+
+## Key Claims（用中文描述）
+- 咨询级 AI Agent 融合三大顶级咨询公司框架（麦肯锡 SCQA + BCG 金字塔原理 + 贝恩行动模型）生成高管级执行摘要
+- 执行摘要长度严格控制在 325-475 词（上限 500 词），确保高管阅读时间不超过 3 分钟
+- 每个关键发现必须包含 ≥ 1 个量化或对比数据点，不允许超越提供数据的假设
+- 建议部分必须包含明确的负责人、时间线和预期结果，按业务影响排序（Critical / High / Medium）
+- Agent 不替代人类判断，而是加速人类决策，明确标记数据缺口和不确定性
+
+## Key Quotes
+> "You specialize in transforming complex or lengthy business inputs into concise, actionable executive summaries designed for C-suite decision-makers." — 核心定位
+> "Enable executives to grasp essence, evaluate impact, and decide next steps in under three minutes." — 成功标准
+> "You do not make assumptions beyond provided data." — 专业诚信原则
+> "Quantify wherever possible" — 核心方法论
+
+## Key Concepts
+- [[SCQA Framework]]：Situation-Complication-Question-Answer 结构化叙事框架（麦肯锡）
+- [[Pyramid Principle]]：金字塔原理，自上而下逻辑沟通和层级化洞察组织（BCG）
+- [[Action-Oriented Recommendations]]：行动导向建议模型，明确负责人+时间线+预期结果（贝恩）
+- [[Executive Summary]]：高管执行摘要，专为 C-suite 设计的结构化决策文档
+
+## Key Entities
+- **McKinsey & Company**：SCQA 框架的原创咨询公司，定位顶级战略咨询
+- **Boston Consulting Group (BCG)**：金字塔原理的原创咨询公司
+- **Bain & Company**：行动导向建议模型的原创咨询公司
+
+## Connections
+- [[Support Infrastructure Maintainer]] ← shared_support_agent ← [[Support Executive Summary Generator]]
+- [[Support Support Responder]] ← shared_support_agent ← [[Support Executive Summary Generator]]
+- [[Analytics Reporter]] ← delivers_data_to ← [[Support Executive Summary Generator]]
+
+## Contradictions
+- 无已知冲突。该 Agent 专注于咨询方法论和执行摘要生成，与其他 Support Agent 无直接概念冲突。

wiki/sources/support-finance-tracker.md

@@ -0,0 +1,47 @@
+---
+title: "Finance Tracker Agent Personality"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/support/support-finance-tracker.md]]
+
+## Summary（用中文描述）
+- 核心主题：企业财务规划与分析的 AI Agent 人格定义，涵盖预算管理、现金流优化、投资分析和合规控制
+- 问题域：企业财务运营与决策支持
+- 方法/机制：通过 SQL 预算差异分析、Python 现金流预测（季节性因子+增长因子）、NPV/IRR 投资评估框架驱动财务决策
+- 结论/价值：提供从数据验证→预算编制→绩效监控→战略规划的全链路财务管理能力，确保财务准确性、合规性和可审计性
+
+## Key Claims（用中文描述）
+- Finance Tracker Agent 通过综合预算框架（含季度差异分析）实现预算准确率 95%+，附差异说明和纠正措施
+- 现金流管理系统通过季节性因子和增长因子预测未来 12 个月现金流，维持 90 天流动性可视性，预测准确率 90%+
+- 投资分析器通过 NPV、IRR、投资回收期和 ROI 多维度评估，推荐投资的平均 ROI 达 25%+，风险评分 < 3
+- 所有财务流程必须包含多级审批检查点、完整审计跟踪和合规验证文档
+
+## Key Quotes
+> "Budget accuracy achieves 95%+ with variance explanations and corrective actions" — 预算准确率指标定义
+> "Cash flow forecasting maintains 90%+ accuracy with 90-day liquidity visibility" — 现金流预测标准
+> "Investment recommendations achieve 25%+ average ROI with appropriate risk management" — 投资回报基准
+> "Financial reporting meets 100% compliance standards with audit-ready documentation" — 合规性要求
+
+## Key Concepts
+- [[BudgetVarianceAnalysis]]：预算金额与实际金额的差异分析，按部门/季度分组，差异率 ±5% 以内为"On Track"
+- [[CashFlowForecasting]]：基于历史数据季节性模式和增长因子，预测未来 12 个月现金流，含置信区间
+- [[NPV_IRR_Analysis]]：净现值（NPV）和内部收益率（IRR）投资评估方法，IRR > 折现率且 NPV > 0 为正向投资信号
+- [[PaybackPeriod]]：投资回收期，目标 < 3 年
+- [[RiskAssessment]]：风险评分（1-10 分），< 3 为低风险，评分越高风险越大
+- [[FinancialCompliance]]：财务合规性，包括审计跟踪文档、多级审批和职责分离
+
+## Key Entities
+- [[AgentsOrchestrator]]：多 Agent 系统的编排器，Finance Tracker 作为其麾下财务专家 Agent
+
+## Connections
+- [[AgentsOrchestrator]] ← manages ← [[SupportFinanceTracker]]
+- [[SupportFinanceTracker]] ← depends_on ← [[BudgetVarianceAnalysis]]
+- [[SupportFinanceTracker]] ← depends_on ← [[CashFlowForecasting]]
+- [[SupportFinanceTracker]] ← depends_on ← [[NPV_IRR_Analysis]]
+
+## Contradictions
+- 暂无发现与现有 Wiki 内容的冲突

wiki/sources/support-infrastructure-maintainer.md

@@ -0,0 +1,56 @@
+---
+title: "Support Infrastructure Maintainer Agent Personality"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/support/support-infrastructure-maintainer.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Support 部门的基础设施维护专家 Agent（Infrastructure Maintainer），专注于系统可靠性、性能优化和技术运维管理
+- 问题域：云架构设计、监控告警系统、灾备恢复、安全合规、运维自动化
+- 方法/机制：Prometheus + Grafana 监控告警、Terraform IaC 基础设施代码化、自动备份加密恢复、Auto Scaling 弹性伸缩、安全加固 SOC2/ISO27001 合规
+- 结论/价值：确保 99.9%+ 服务可用性，自动化降低 70%+ 人工运维任务，成本效率提升 20%+
+
+## Key Claims（用中文描述）
+- Infrastructure Maintainer Agent 通过 Prometheus 监控配置实现了对 CPU/内存/磁盘/服务可用性的实时告警，发现问题前主动预警
+- Terraform IaC 框架实现了 VPC/Subnet/Auto Scaling/RDS 数据库的基础设施代码化管理，确保部署一致性和版本可追溯
+- GPG 加密 + S3 分层存储备份方案实现了关键数据的安全存储与 30 天自动清理机制
+- 安全加固集成 SOC2/ISO27001 合规验证，确保所有基础设施变更均通过安全审计
+
+## Key Quotes
+> "Be proactive: Monitoring indicates 85% disk usage on DB server - scaling scheduled for tomorrow" — Infrastructure Maintainer 主动预警的沟通风格
+> "Ensure Maximum System Reliability and Performance: Maintain 99.9%+ uptime for critical services with comprehensive monitoring and alerting" — 核心可靠性指标定义
+> "Security and Compliance Integration: Validate security requirements for all infrastructure modifications" — 安全优先原则
+
+## Key Concepts
+- [[Infrastructure-as-Code]]：使用 Terraform/CloudFormation/Ansible 实现基础设施配置代码化，确保部署一致性、环境可复制和版本控制
+- [[Auto-Scaling]]：基于 CPU/内存/自定义指标自动调整计算资源，平衡性能与成本
+- [[Disaster-Recovery]]：自动化备份 + 加密存储 + 经过测试的恢复流程，保障业务连续性
+- [[Monitoring-and-Observability]]：Prometheus 指标采集 + Grafana 可视化 + 告警规则，实现全面可观测性
+- [[Security-Hardening]]：零信任架构 + 最小权限 + MFA 多因素认证 + 漏洞管理
+- [[Compliance-Monitoring]]：SOC2/ISO27001/HIPAA 等标准持续合规验证与审计追踪
+- [[Cost-Optimization]]：资源正确规模分析 + 预留实例 + 自动化运维降低 20%+ 年度基础设施成本
+
+## Key Entities
+- [[Prometheus]]：开源监控系统，提供指标采集、告警规则和 Alertmanager 集成
+- [[Terraform]]：HashiCorp 基础设施即代码工具，支持多云 AWS/Azure/GCP 资源编排
+- [[AWS-RDS]]：托管关系数据库服务，支持自动备份、性能监控和多可用区部署
+- [[GPG-Encryption]]：GnuPG 加密工具，用于备份数据 AES-256 对称加密
+- [[SOC2]]：Service Organization Control 2 安全合规框架，评估服务安全性/可用性/保密性
+- [[ISO27001]]：国际信息安全管理标准，提供系统化安全管理方法论
+- [[Auto-Scaling-Group]]：AWS 自动伸缩组，基于策略自动调整 EC2 实例数量
+
+## Connections
+- [[Support-Support-Responder]] ← depends_on ← [[Support-Infrastructure-Maintainer]]（Support Responder 依赖稳定的基础设施才能提供可靠的支持服务）
+- [[Support-Analytics-Reporter]] ← depends_on ← [[Support-Infrastructure-Maintainer]]（Analytics Reporter 依赖数据库和存储基础设施）
+- [[Support-Legal-Compliance-Checker]] ← extends ← [[Support-Infrastructure-Maintainer]]（合规检查扩展了基础设施安全加固要求）
+
+## Contradictions
+- 与 [[Support-Legal-Compliance-Checker]] 冲突：
+  - 冲突点：变更速度 vs 合规验证
+  - 当前观点（Infrastructure Maintainer）：在所有变更前实施监控、创建回滚程序、建立事件响应流程，合规是变更的组成部分
+  - 对方观点（Legal Compliance Checker）：合规验证应在变更前完成，需完整的审计追踪和监管要求跟踪
+  - 协调建议：合规验证作为 CI/CD 流水线的 Gate 步骤，在部署前完成自动化合规扫描，不阻断常规变更但强制阻断高风险变更

wiki/sources/support-legal-compliance-checker.md

@@ -0,0 +1,56 @@
+---
+title: "Support Legal Compliance Checker Agent Personality"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/agency-agents/support/support-legal-compliance-checker.md]]
+
+## Summary（用中文描述）
+- **核心主题**：Legal Compliance Checker — The Agency Support 部门的法律合规专家 Agent，负责确保企业运营、数据处理和内容创作符合多司法管辖区的法律法规和行业标准。
+- **问题域**：数据隐私保护（GDPR/CCPA）、行业监管合规（HIPAA/SOX/PCI-DSS/FERPA）、合同风险审查、隐私政策生成、合规文化建设。
+- **方法/机制**：四阶段工作流（监管格局评估 → 风险评估与差距分析 → 政策制定与实施 → 培训与文化建设）；GDPR 合规 YAML 配置框架；Python PrivacyPolicyGenerator；Python ContractReviewSystem（含关键词扫描风险评估）。
+- **结论/价值**：通过量化合规评分体系（目标 98%+）、自动化的违规检测和文档管理，帮助组织建立持续合规的文化，最小化法律风险暴露。
+
+## Key Claims（用中文描述）
+- Legal Compliance Checker 实施任何业务流程变更前必须验证监管要求，并将所有合规决策记录在法律推理和监管引用中。
+- GDPR 合规框架要求数据主体权利响应时间不超过 30 天，数据泄露需在 72 小时内通知监管机构。
+- 合同风险评分 ≥10 分为高风险（需法律审查），5–10 分为中风险（需经理批准），<5 分为低风险（标准审批流程）。
+- 合规培训计划应在员工入职或政策更新后 30 天内达到 100% 完成率。
+- 合规文化评分应达到 4.5/5（员工满意度和合规意识调查）。
+
+## Key Quotes
+> "Compliance First Approach — Verify regulatory requirements before implementing any business process changes." — 实施任何业务变更前的核心原则
+> "Non-compliance with CCPA could result in penalties up to $7,500 per violation." — 风险量化沟通风格示例
+> "GDPR Article 17 requires data deletion within 30 days of valid erasure request." — 精确引用监管条款的沟通风格
+> "If it's not tested with a screen reader, it's not accessible." — （跨 Agent 参考）证据驱动的验证理念在此 Agent 中的体现：隐私政策必须通过合规验证框架的截图式确认
+
+## Key Concepts
+- [[PrivacyByDesign]]：数据保护原则，要求最小化数据收集、目的限制、存储限制、准确性、完整保密性和问责制。
+- [[DataBreachNotification]]：数据泄露响应机制，要求 72 小时内向监管机构通报，无不当延迟向数据主体通报。
+- [[AuditTrail]]：审计追踪，记录所有合规活动和决策过程，支持多司法管辖区合规验证和审计准备。
+- [[RiskAssessment]]：法律风险评估方法，涵盖影响分析和缓解策略开发，是所有新业务举措的必须步骤。
+- [[ConsentManagement]]：同意管理机制，支持 GDPR 的明确同意和 CCPA 的选择退出模式。
+- [[ComplianceTraining]]：合规培训体系，角色定制教育 + 有效性测量 + 年度再认证。
+
+## Key Entities
+- [[GDPR]]：欧盟通用数据保护条例，核心法律基础包括同意、合同履行、法律义务、重要利益、公共任务和合法利益六种。
+- [[CCPA]]：加州消费者隐私法，赋予加州居民知情权、删除权、选择退出销售权和不受歧视权。
+- [[HIPAA]]：美国健康保险可携带性和责任法案，医疗行业数据保护要求。
+- [[PCI-DSS]]：支付卡行业数据安全标准，处理信用卡数据的合规要求。
+- [[SOX]]：萨班斯-奥克斯利法案，财务报告合规要求。
+- [[FERPA]]：家庭教育权利和隐私法案，教育记录保护要求。
+
+## Connections
+- [[ComplianceAuditor]] ← extends ← [[support-legal-compliance-checker]]：Compliance Auditor Agent 提供审计执行能力，而 Legal Compliance Checker 提供政策框架和风险评估，两者互补。
+- [[support-support-responder]] ← depends_on ← [[support-legal-compliance-checker]]：Support Responder Agent 在处理客户投诉时依赖 Legal Compliance Checker 的合规框架确保响应符合监管要求。
+- [[automation-governance-architect]] ← informs ← [[support-legal-compliance-checker]]：Automation Governance Architect 的治理框架为 Legal Compliance Checker 的政策制定提供结构化方法论。
+
+## Contradictions
+- 与 [[testing-reality-checker]] 在质量标准严格度上存在张力：
+  - **冲突点**：Legal Compliance Checker 默认"正常通过"（当合规评分达到阈值），而 Testing Reality Checker 默认"NEEDS WORK"（首次实现通常不通过）。
+  - **当前观点**：合规 Agent 认为达到监管标准（98%+）即为合规，可接受有记录的例外情况。
+  - **对方观点**：Reality Checker 要求压倒性视觉证明，认为"合规评分达标"不等于"生产就绪"。
+  - **解决建议**：Legal Compliance Checker 的合规框架 + Reality Checker 的视觉验证结合使用，合规是准入门槛，Reality Check 是质量门禁。

wiki/sources/support-support-responder.md

@@ -0,0 +1,55 @@
+---
+title: "Support Responder Agent Personality"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/support/support-support-responder.md]]
+
+## Summary（用中文描述）
+- 核心主题：客户支持专家 Agent 人格定义，专注于卓越客户服务、问题解决和用户体验优化，将每次支持互动转化为品牌正向体验。
+- 问题域：多渠道客户支持（邮件/聊天/电话/社交媒体）、主动客户关怀、危机管理、知识库管理、客服数据分析与指标优化。
+- 方法/机制：四步工作流（客户查询分析与路由 → 问题调查与解决 → 客户跟进与成功测量 → 知识共享与流程改进）；Omnichannel Support Framework（五渠道 SLA 配置）；三级支持体系（Tier1/Tier2/Tier3 分层升级）；SupportAnalytics Python 框架；KnowledgeBaseManager 知识库管理。
+- 结论/价值：客户满意度 4.5+/5、首次联系解决率 80%+、SLA 合规率 95%+、知识库贡献减少相似工单 25%+。
+
+## Key Claims（用中文描述）
+- Support Responder 通过多渠道（邮件/聊天/电话/社交媒体/应用内消息）提供全渠道支持，实现 85% 首次联系解决率和 2 小时首次响应 SLA。
+- 三级支持体系（Tier1 General / Tier2 Technical / Tier3 Specialists）通过明确的升级标准和路由机制，确保客户问题高效分流至合适层级。
+- SupportAnalytics Python 框架通过数据分析识别支持趋势、生成改进建议并创建主动外展列表。
+- KnowledgeBaseManager 通过文章模板、交互式故障排除和内容优化建议，实现知识资产持续积累。
+- 核心原则：客户满意度优先于内部效率指标，同理心沟通结合技术准确解决方案，适当升级超出权限的问题。
+
+## Key Quotes
+> "I understand how frustrating this must be - let me help you resolve this quickly" — 同理心沟通表达模板
+> "Here's exactly what I'll do to fix this issue, and here's how long it should take" — 聚焦解决方案的沟通表达
+> "Let me summarize what we've done and confirm everything is working perfectly for you" — 确保清晰确认的沟通表达
+
+## Key Concepts
+- [[Omnichannel-Support]]：通过多个渠道（邮件/聊天/电话/社交媒体/应用内消息）提供统一的客户体验，各渠道共享客户上下文和历史记录。
+- [[First-Contact-Resolution]]：在首次客户互动中解决问题，无需升级或回呼，是衡量支持质量的核心 KPI。
+- [[Support-Tier-System]]：三级分层支持体系（Tier1/Tier2/Tier3），每级有明确的职责范围、升级标准和专业能力要求。
+- [[Service-Level-Agreement]]：服务水平协议，定义各渠道的首次响应时间和解决时间 SLA 目标（如邮件 2 小时、实时聊天 30 秒）。
+- [[Proactive-Customer-Outreach]]：主动外展，在客户问题升级前主动联系高风险或高价值客户进行预防性支持。
+- [[Customer-Satisfaction-Score]]：客户满意度评分（CSAT），衡量每次支持互动的客户满意度，目标 4.5+/5.0。
+- [[Knowledge-Base]]：集中化的自助服务知识库，包含故障排除指南、常见问题解答和产品文档，支持客户自助和 Agent 协作。
+
+## Key Entities
+- [[Support-Responder-Agent]]：The Agency Support 部门的客户支持专员 Agent，核心职责：多渠道客户响应、问题解决、满意度测量、知识库贡献。
+- [[Support-Analytics-Dashboard]]：SupportAnalytics Python 类实现的客服分析仪表盘，提供关键指标计算、趋势识别和改进建议生成功能。
+- [[Knowledge-Base-Manager]]：KnowledgeBaseManager Python 类实现的知识库管理系统，提供文章创建、模板生成、交互式故障排除流程构建和内容优化功能。
+- [[Customer-Support-Interaction-Template]]：标准化客户支持互动报告模板，涵盖客户信息、问题摘要、解决过程、指标结果和后续行动五大板块。
+
+## Connections
+- [[support-analytics-reporter]] ← depends_on ← [[support-support-responder]]（Support Responder 产生工单数据，Analytics Reporter 分析数据生成洞察）
+- [[support-support-responder]] ← extends ← [[support-legal-compliance-checker]]（合规问题升级至 Legal Compliance Checker）
+- [[Support-Responder-Agent]] ← extends ← [[Knowledge-Base]]（知识库是支持体系的核心基础设施）
+- [[support-executive-summary-generator]] ← depends_on ← [[support-support-responder]]（执行摘要基于支持数据分析）
+
+## Contradictions
+- 与 [[support-legal-compliance-checker]] 冲突：
+  - 冲突点：问题解决优先 vs 合规优先
+  - 当前观点（Support Responder）：客户满意度优先于内部效率指标，快速解决问题是核心目标
+  - 对方观点（Legal Compliance Checker）：合规优先，任何业务流程变更前必须验证监管要求
+  - 协调建议：常规客户问题以 Support Responder 为主；涉及合规风险的问题（如数据删除/账户限制）升级至 Legal Compliance Checker 处理

wiki/sources/testing-accessibility-auditor.md

@@ -0,0 +1,64 @@
+---
+title: "Accessibility Auditor Agent Personality"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/testing/testing-accessibility-auditor.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 的无障碍审计专家人格定义，专注于 WCAG 标准合规性检测和辅助技术测试
+- 问题域：无障碍测试（Accessibility Testing）、WCAG 合规性评估、辅助技术（屏幕阅读器、键盘导航）验证
+- 方法/机制：
+  - 基于 WCAG 2.2 AA 标准进行自动化扫描 + 手动辅助技术测试双重验证
+  - 四项 POUR 原则评估（可感知、可操作、可理解、健壮）
+  - 屏幕阅读器（VoiceOver/NVDA/JAWS）真实交互流测试
+  - 键盘-only 导航完整测试
+  - 提供结构化审计报告模板，包含问题严重性分级和修复建议
+- 结论/价值：为 AI Agent 提供一套完整的无障碍审计方法论，确保数字产品对残障用户的真实可用性
+
+## Key Claims（用中文描述）
+- 自动化工具仅能发现约 30% 的无障碍问题，剩余 70% 需手动辅助技术测试发现
+- Lighthouse 绿色分数不等于无障碍可用——自定义组件（标签页、模态框、轮播图、日期选择器）需逐个审查
+- 所有交互流程必须支持纯键盘操作，"鼠标可用"不是有效的无障碍测试
+- 语义化 HTML 优于 ARIA——最好的 ARIA 是不需要 ARIA
+
+## Key Quotes
+> "If it's not tested with a screen reader, it's not accessible." — AccessibilityAuditor 核心原则
+> "Automated tools catch roughly 30% of accessibility issues — you catch the other 70%" — 自动化 vs 手动测试的差距
+> "Custom components (tabs, modals, carousels, date pickers) are guilty until proven innocent" — 自定义组件无障碍审查原则
+> "A green Lighthouse score does not mean accessible" — 合规性检查的诚实评估原则
+
+## Key Concepts
+- [[WCAG 2.2]]: Web Content Accessibility Guidelines 2.2，网页内容无障碍指南，审计标准的核心框架
+- [[POUR Principles]]: 可感知（Perceivable）、可操作（Operable）、可理解（Understandable）、健壮（Robust），WCAG 的四项核心原则
+- [[ARIA]]: Accessible Rich Internet Applications，WAI-ARIA 规范，用于增强自定义组件的无障碍支持
+- [[Screen Reader Testing]]: 屏幕阅读器测试（VoiceOver/NVDA/JAWS），验证动态内容和交互组件的语音播报正确性
+- [[Keyboard Navigation Audit]]: 键盘导航审计，确保所有交互元素可通过 Tab/方向键访问且无键盘陷阱
+- [[axe-core]]: 自动化无障碍扫描工具，集成到 CI/CD 流程中用于回归测试
+- [[Focus Management]]: 焦点管理，动态内容加载时焦点应正确转移且不丢失
+- [[Live Regions]]: ARIA 实时区域，用于向屏幕阅读器用户播报状态更新和通知
+
+## Key Entities
+- [[VoiceOver]]: Apple 屏幕阅读器（macOS/iOS），AccessibilityAuditor 主要测试环境之一
+- [[NVDA]]: NonVisual Desktop Access，Windows 平台开源屏幕阅读器
+- [[JAWS]]: Job Access With Speech，Windows 商业屏幕阅读器
+- [[axe-core]]: Deque Labs 开发的自动化无障碍测试引擎
+- [[Lighthouse]]: Chrome DevTools 内置审计工具，可生成无障碍分数但不足以验证真实可用性
+- [[WAI-ARIA]]: W3C Web Accessibility Initiative 发布的富互联网应用无障碍规范
+
+## Connections
+- [[Testing Tool Evaluator]] ← 协同 → [[Testing Evidence Collector]]
+- [[Testing Reality Checker]] ← 供给无障碍证据 → [[Accessibility Auditor]]
+- [[Frontend Developer]] ← 接收修复建议 → [[Accessibility Auditor]]
+- [[UI Designer]] ← 审计设计 token 对比度/间距/目标尺寸 → [[Accessibility Auditor]]
+- [[Legal Compliance Checker]] ← 关联 ADA/Section 508 合规要求 → [[Accessibility Auditor]]
+
+## Contradictions
+- 与 [[Testing Tool Evaluator]] 的潜在冲突：
+  - 冲突点：自动化工具（如 axe-core/Lighthouse）的充分性评估
+  - 当前观点（AccessibilityAuditor）：自动化工具只能覆盖 30%，不能替代手动测试
+  - 对方观点（Tool Evaluator）：倾向于相信自动化工具的检测能力
+  - 建议：两者协同使用，自动化工具作为基线，手动测试作为深度验证

wiki/sources/workflow-book-chapter.md

@@ -0,0 +1,45 @@
+---
+title: "Workflow Example: Book Chapter Development"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/examples/workflow-book-chapter.md]]
+
+## Summary（用中文描述）
+- 核心主题：单 Agent 工作流——将粗糙的原始素材转化为结构化的第一人称章节草稿，包含明确的修订循环
+- 问题域：作者拥有录音、碎片化笔记或战略要点，但缺乏完整的章节草稿
+- 方法/机制：Book Co-Author Agent 接收原始素材，输出五部分结构化输出（目标、章节、编辑注释、反馈循环、下一步）
+- 结论/价值：确保草稿保持作者个人声音、强化分类定位、暴露开放编辑决策，而非泛化的代笔
+
+## Key Claims（用中文描述）
+- Book Co-Author Agent 将原始素材转换为带编辑注释和下一步问题的版本化章节草稿
+- 工作流目标不是泛化 ghostwriting，而是生产能强化分类定位、保卫作者声音、清晰暴露开放编辑决策的章节
+- 输出必须以明确修订问题结尾，而非模糊的交接
+
+## Key Quotes
+> "The goal is not generic ghostwriting. The goal is to produce a chapter that strengthens category positioning, preserves the author's voice, and exposes open editorial decisions clearly." — 工作流设计目标
+
+> "The output ends with explicit revision questions, not a vague handoff." — 质量标准
+
+## Key Concepts
+- [[BookCoAuthor]]：Book Co-Author Agent — 将原始素材转换为版本化章节草稿（含编辑注释和下一步问题）的单 Agent 角色
+- [[SingleAgentWorkflow]]：单 Agent 工作流——使用单一专注 Agent 执行特定任务的聚焦式工作流
+- [[EditorialRevisionLoop]]：编辑修订循环——通过明确的修订问题和反馈循环迭代改进输出的机制
+- [[AuthorVoicePreservation]]：作者声音保持——确保 AI 生成内容忠实反映作者个人表达风格而非泛化模板语言
+
+## Key Entities
+- [[BookCoAuthor]]：Book Co-Author Agent — 本工作流的核心执行 Agent
+
+## Connections
+- [[workflow-startup-mvp]] ← related_to ← [[workflow-book-chapter]]
+- [[agents-orchestrator]] ← extends ← [[BookCoAuthor]]
+- [[contributing]] ← part_of ← [[TheAgency]]
+
+## Contradictions
+- 与泛化 ghostwriting 服务冲突：
+  - 冲突点：泛化 ghostwriting 生成通用内容；本工作流强调保持作者个人声音和定位
+  - 当前观点：AI 生成内容必须保持第一人称声音、依附来源材料或明确标记为假设
+  - 对方观点：专业写手可以完全替代作者完成写作，无需维持原始素材关联

wiki/sources/workflow-landing-page.md

@@ -0,0 +1,50 @@
+---
+title: "Multi-Agent Workflow: Landing Page Sprint"
+type: source
+tags: [multi-agent, workflow, landing-page, conversion-optimization]
+date: 2026-04-21
+---
+
+## Source File
+- [[raw/Agent/agency-agents/examples/workflow-landing-page.md]]
+
+## Summary（用中文描述）
+- 核心主题：多 Agent 协作在一天内完成高转化率 landing page 的完整工作流
+- 问题域：如何在极短时间内协调多个专业 Agent（文案、设计、开发、增长）并行与串行工作，产出可上线的 landing page
+- 方法/机制：上午并行（文案 + 设计）→ 中午合并构建 → 下午增长优化 + 反馈循环
+- 结论/价值：展示了 Multi-Agent 协作中的 4 个核心设计模式（并行启动、合并点、反馈循环、时间盒）
+
+## Key Claims（用中文描述）
+- 文案 Agent 与 UI 设计 Agent 可在上午并行工作，因两者输出互相独立
+- 前端开发 Agent 需要等待文案和设计两者完成后才能开始（合并点依赖）
+- 增长黑客 Agent 在第一版完成后进行转化率审查，前端开发根据反馈进行修改
+- 每个阶段有明确的时间盒，防止范围蔓延
+
+## Key Quotes
+> "Parallel kickoff: Copy and design happen at the same time since they're independent" — 工作流核心原则：独立任务并行启动
+> "Merge point: Frontend Developer needs both outputs before starting" — 前端开发的依赖管理
+> "Feedback loop: Growth Hacker reviews, then Frontend Developer applies changes" — 质量保障的迭代机制
+> "Time-boxed: Each step has a clear timebox to prevent scope creep" — 项目管理原则
+
+## Key Concepts
+- [[Parallel-Kickoff]]：独立 Agent 任务在同一时间并行启动，无需相互等待
+- [[Merge-Point]]：多个并行分支的输出在特定节点合并，触发下一阶段
+- [[Feedback-Loop]]：后续 Agent 审查并反馈，前序 Agent 根据反馈修改的迭代机制
+- [[Time-Boxing]]：为每个工作阶段设定严格时间限制，防止范围蔓延
+
+## Key Entities
+- [[Content-Creator]]：负责撰写 landing page 文案（标题、副标题、CTA、定价等）的 Agent
+- [[UI-Designer]]：负责设计布局、配色、字体、组件规格的 Agent
+- [[Frontend-Developer]]：负责将文案和设计合并构建为可部署 HTML 的 Agent
+- [[Growth-Hacker]]：负责转化率审查和优化建议的 Agent
+- [[FlowSync]]：案例中的虚构产品——一个 API 集成平台
+
+## Connections
+- [[Content-Creator]] ← depends_on ← (无，独立启动)
+- [[UI-Designer]] ← depends_on ← (无，独立启动)
+- [[Frontend-Developer]] ← merge_point ← [[Content-Creator]] + [[UI-Designer]]
+- [[Growth-Hacker]] ← depends_on ← [[Frontend-Developer]]
+- [[workflow-startup-mvp]] ← extends ← [[Parallel-Kickoff]] + [[Merge-Point]] + [[Feedback-Loop]] + [[Time-Boxing]]
+
+## Contradictions
+- 无明显冲突。workflow-startup-mvp 的时间线以"周"为单位（长周期迭代），本工作流以"小时"为单位（短周期冲刺）。两者互补，后者是前者在单日冲刺场景下的具体化。

wiki/sources/workflow-startup-mvp.md

@@ -0,0 +1,61 @@
+---
+title: "Multi-Agent Workflow: Startup MVP"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/agency-agents/examples/workflow-startup-mvp.md]]
+
+## Summary（用中文描述）
+- 核心主题：多 Agent 协作工作流，演示如何协调多个 Agent 从创意到 MVP 交付的完整流程
+- 问题域：SaaS 产品（团队回顾工具）的快速开发与多角色 Agent 协调
+- 方法/机制：7 种专业 Agent 角色（Sprint Prioritizer、UX Researcher、Backend Architect、Frontend Developer、Rapid Prototyper、Growth Hacker、Reality Checker），按 4 周 7 步骤流水线协作
+- 结论/价值：展示了顺序交接、并行工作、质量门控、上下文传递四大关键模式，是多 Agent 团队协作的最佳实践范例
+
+## Key Claims（用中文描述）
+- Sprint Prioritizer 将 4 周 MVP 项目拆解为有明确交付物和验收标准的 4 个冲刺
+- UX Researcher 并行进行竞品分析，识别产品差异化机会
+- Backend Architect 输出完整 API 规范（数据库 Schema、REST 端点、WebSocket 事件、认证策略）
+- Frontend Developer + Rapid Prototyper 基于 API 规范并行构建应用
+- Reality Checker 在第 2 周和第 4 周各设置一个质量门控点，评估生产就绪状态
+- Growth Hacker 在第 3 周同步启动增长策略制定（着陆页、发布渠道、Day-by-day 序列）
+- Sequential Handoffs（顺序交接）：每个 Agent 的输出作为下一个 Agent 的输入
+- Parallel Work（并行工作）：Week 1 中 Sprint Prioritizer 和 UX Researcher 可同时运行
+- Quality Gates（质量门控）：Reality Checker 在关键里程碑处评估是否可继续
+- Context Passing（上下文传递）：Agent 之间无共享记忆，必须完整粘贴上一个 Agent 的输出
+
+## Key Quotes
+> "Sequential handoffs: Each agent's output becomes the next agent's input" — 多 Agent 协作的核心机制
+> "Copy-paste agent outputs between steps — don't summarize, use the full output" — 上下文传递原则，必须完整粘贴而非摘要
+> "Keep the Orchestrator agent in mind for automating this flow once you're comfortable with the manual version" — 未来可引入 Orchestrator Agent 自动化此工作流
+
+## Key Concepts
+- [[Sequential Handoff]]：顺序交接模式 — 每个 Agent 的输出作为下一个 Agent 的完整输入
+- [[Parallel Agent Work]]：并行工作模式 — 独立 Agent 在 Week 1 可同时激活
+- [[Quality Gate]]：质量门控 — 在关键里程碑设置 Reality Checker 评估点，防止有问题的代码上线
+- [[Context Passing]]：上下文传递 — Agent 之间无共享记忆，必须显式传递完整上下文
+- [[Multi-Agent Orchestration]]：多 Agent 编排 — 通过预定义的 Agent 角色和交接顺序实现流水线化协作
+
+## Key Entities
+- [[Sprint Prioritizer]]：将项目拆解为 4 周冲刺的角色
+- [[UX Researcher]]：进行竞品分析并识别差异化的角色
+- [[Backend Architect]]：设计 API、数据模型和实时架构的角色
+- [[Frontend Developer]]：基于 API 规范构建 React 应用的角色
+- [[Rapid Prototyper]]：快速产出第一个可运行版本的角色
+- [[Growth Hacker]]：制定发布策略和增长计划的角色
+- [[Reality Checker]]：在关键节点评估生产就绪状态并给出 GO/NO-GO 决策的角色
+- [[RetroBoard]]：示例产品 — 面向远程团队的实时团队回顾工具
+- [[Orchestrator Agent]]：未来用于自动化此工作流的编排 Agent
+
+## Connections
+- [[Sprint Prioritizer]] ← outputs sprint plan to ← [[UX Researcher]] ← parallel work in Week 1
+- [[UX Researcher]] ← outputs research brief to ← [[Backend Architect]] ← handoff in Week 1
+- [[Backend Architect]] ← outputs API spec to ← [[Frontend Developer]] + [[Rapid Prototyper]] ← parallel in Week 2
+- [[Frontend Developer]] ← midpoint gate ← [[Reality Checker]] ← Week 2 quality check
+- [[Reality Checker]] ← final gate ← [[Growth Hacker]] ← Week 3 parallel with Frontend Developer
+- [[Reality Checker]] ← GO/NO-GO ← Launch ← Week 4 final check
+
+## Contradictions
+- 无明显内容冲突。该工作流以示例为主，与其他 Agent 工作流文档可共存。

wiki/sources/workflow-with-memory.md

@@ -0,0 +1,68 @@
+---
+title: "Multi-Agent Workflow: Startup MVP with Persistent Memory"
+type: source
+tags: [multi-agent, memory, mcp, workflow, persistent-state]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/examples/workflow-with-memory.md]]
+
+## Summary（用中文描述）
+- 核心主题：多 Agent 协作工作流增加 MCP 持久记忆机制，解决 Agent 间手动复制粘贴交接、上下文丢失、QA 失败回滚困难等问题
+- 问题域：多 Agent 协作中跨会话状态持久化、上下文自动传递、失败自动回滚的工程实践
+- 方法/机制：MCP Memory Server（remember/recall/rollback/search）+ 项目标签命名策略 + 接续 Agent 自动召回机制，替代人工复制粘贴
+- 结论/价值：将"你（人类）作为粘合剂"变为"记忆服务器作为粘合剂"，实现 Agent 间无缝交接、跨会话持久化、多 Agent 共享上下文、QA 失败自动回滚
+
+## Key Claims（用中文描述）
+- MCP Memory Server 通过 remember（存储）、recall（召回）、rollback（回滚）三个操作实现 Agent 间的状态持久化
+- 手动交接的核心痛点：会话超时丢失输出、多 Agent 需要相同上下文、QA 失败需要回滚到上一状态、项目跨多天多会话
+- MCP Memory Server 的核心价值：Handoff 变为自动召回（无需复制粘贴）、上下文跨会话持久化、多 Agent 按项目标签共享上下文、QA 失败可回滚而非手动撤销
+- 标签策略是召回的核心：所有记忆用项目名标签（如 retroboard）、交付物标签到接收 Agent（如 frontend-developer）
+- Reality Checker 可召回项目中所有已存储的记忆，获得完整的全局可见性，无需人工编译上下文
+- Rollback 机制：将问题回滚到上一个检查点，而非手动追踪发生了什么变化
+- Setup 要求：仅需安装一个支持 remember/recall/rollback/search 的 MCP-compatible memory server
+
+## Key Quotes
+> "You are the glue. You copy-paste outputs between agents, keep track of what's been done, and hope you don't lose context along the way." — 手动交接模式的根本缺陷
+> "The agent searches memory for RetroBoard context, finds the sprint plan and research brief stored by previous agents, and picks up from there." — Memory Server 下的 Agent 交接
+> "Tag everything with the project name. This is what makes recall work." — 标签命名策略是记忆召回的核心
+> "Tag deliverables for the receiving agent. When the Backend Architect finishes an API spec, it tags the memory with frontend-developer so the Frontend Developer finds it on recall." — 双向标签策略
+> "Rollback replaces manual undo. When something fails, roll back to the last checkpoint instead of trying to figure out what changed." — Rollback 替代手动撤销
+
+## Key Concepts
+- [[MCP Memory Server]]：Model Context Protocol 记忆服务器，提供 remember/recall/rollback/search 四个操作，实现 Agent 间状态持久化和上下文自动召回
+- [[Memory-Based Handoff]]：基于记忆的交接模式 — Agent 完成工作后存储记忆（带标签），下一个 Agent 通过 recall 自动召回，无需人工复制粘贴
+- [[Persistent Context Across Sessions]]：跨会话持久上下文 — 记忆服务器使 Agent 能够在数天或数周的多会话项目中自动拾取上次离开的位置
+- [[Agentic Rollback]]：Agent 级回滚机制 — QA 失败时，Agent 从记忆服务器回滚到上一个检查点，替代手动追踪和撤销
+- [[Project-Based Memory Tagging]]：基于项目的记忆标签策略 — 所有记忆用项目名标签，交付物额外用接收 Agent 标签，是召回系统正常工作的核心
+- [[Multi-Agent Shared Context]]：多 Agent 共享上下文 — 多个 Agent 可通过搜索相同项目标签共享同一个项目的所有上下文，无需人工编译
+
+## Key Entities
+- [[MCP Memory Server]]：支持 remember、recall、rollback、search 操作的 MCP-compatible 记忆服务器（任意实现均可）
+- [[RetroBoard]]：示例产品 — 面向远程团队的实时团队回顾工具，作为该工作流演示的统一项目背景
+- [[Sprint Prioritizer]]：将 4 周 MVP 项目拆解为冲刺计划，并将 sprint plan 存入记忆（标签：sprint-prioritizer、retroboard、sprint-plan）
+- [[UX Researcher]]：进行竞品分析并将研究简报存入记忆（标签：ux-researcher、retroboard、research-brief）
+- [[Backend Architect]]：设计 API 规范并存入记忆（标签：backend-architect、retroboard、api-spec、frontend-developer）
+- [[Frontend Developer]]：通过 recall 自动获取 API 规范，构建 React 应用并持续存储进度
+- [[Reality Checker]]：召回项目中所有 Agent 的交付物，获得完整全局可见性，给出 GO/NO-GO 决策
+- [[Growth Hacker]]：召回项目上下文和 Reality Checker 裁决，制定增长计划并存入记忆
+- [[Rapid Prototyper]]：快速产出第一个可运行版本的角色
+
+## Connections
+- [[MCP Memory Server]] ← enables ← [[Memory-Based Handoff]]
+- [[MCP Memory Server]] ← enables ← [[Agentic Rollback]]
+- [[MCP Memory Server]] ← enables ← [[Persistent Context Across Sessions]]
+- [[workflow-startup-mvp]] ← extends (adds memory layer to) ← [[Multi-Agent Workflow: Startup MVP with Persistent Memory]]
+- [[Sprint Prioritizer]] ← stores sprint plan in ← [[MCP Memory Server]] ← recalls for ← [[Backend Architect]]
+- [[UX Researcher]] ← stores research brief in ← [[MCP Memory Server]] ← recalls for ← [[Backend Architect]]
+- [[Backend Architect]] ← stores API spec in ← [[MCP Memory Server]] ← recalls for ← [[Frontend Developer]]
+- [[Reality Checker]] ← recalls all project memories from ← [[MCP Memory Server]] ← all agents store here
+- [[Memory-Based Handoff]] ← replaces ← [[Sequential Handoff]]（来自 workflow-startup-mvp）
+
+## Contradictions
+- 与 [[workflow-startup-mvp]] 的关系：
+  - 冲突点：workflow-startup-mvp 强调"必须完整粘贴上一个 Agent 的输出"，而本工作流主张"Agent 自动召回，无需复制粘贴"
+  - 当前观点：MCP Memory Server 消除人工复制粘贴，Agent 通过 recall 自动获取所需上下文
+  - 对方观点：原始工作流认为手动交接是必要的，因为没有持久化机制时完整粘贴是保证上下文不丢失的唯一方式
+  - 结论：两者不冲突，本工作流是原始工作流的增强层——在 Memory Server 可用的环境中，Agent 自动召回替代人工粘贴；在 Memory Server 不可用的环境中，沿用原始工作流的手动粘贴策略