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

2026-04-26 00:02:55 +08:00
parent 8cceccf489
commit f1de106298
42 changed files with 1482 additions and 30 deletions
--- a/wiki/sources/marketing-douyin-strategist.md
+++ b/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 策略需平衡分享率与互动率
--- a/wiki/sources/marketing-zhihu-strategist.md
+++ b/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 秒内抓住注意力
+  - 说明：平台特性不同，策略自然分化——知乎是信誉驱动深度平台，抖音是娱乐驱动视觉平台，两者互补而非矛盾
--- a/wiki/sources/readme.md
+++ b/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 可调用的子代理
- 问题域：OpenCode IDE 中的多 Agent 协作与按需调用
- 方法/机制：通过 YAML frontmatter 中的 `mode: subagent` 标记，将具名 Agent 从 Tab 循环列表中分离，改为按需 `@agent-name` 调用；颜色通过命名颜色到十六进制的自动映射实现
- 结论/价值：提供了一种轻量级、无需修改主 Agent 系统的子 Agent 扩展方案，支持项目级和全局级两种安装范围
+- 核心主题：展示 agency-agents 中多个专业 Agent 如何协作完成真实任务的案例目录
+- 问题域：Agent 协作的实践价值证明——仅靠 Agent 定义无法展示多 Agent 联合部署的效果
+- 方法/机制：通过具体案例回答"当全体 Agent 同时部署在同一任务上时会发生什么"这一问题
+- 结论/价值：8 个 Agent 并行运行，产出一致、相互引用的完整计划，无需协调开销

 ## Key Claims（用中文描述）
- OpenCode Agent 通过在 `.opencode/agents/` 目录存储 .md 文件（带 YAML frontmatter）实现——文件格式与 The Agency 的 Agent 定义格式兼容
- `mode: subagent` 配置使 Agent 仅在 `@agent-name` 触发时出现，不会在 Tab 循环列表中占位——保持主 Agent 列表的简洁性
- 命名颜色（如 `cyan`）在安装脚本中被自动转换为十六进制颜色代码——无需手动查表
- Agent 支持两种安装范围：项目级（`.opencode/agents/`）和全局级（`~/.config/opencode/agents/`）——通过不同路径实现作用域隔离
- 转换脚本 `./scripts/convert.sh --tool opencode` 负责将 The Agency 的标准 Agent 文件转换为 OpenCode 兼容格式
+- 8 个专业 Agent 并行运行，产出了连贯且相互引用的完整计划，无协调开销
+- 多 Agent 协作可从"发现机会"到"完整蓝图"在单次会话中完成
+- 好的案例应展示多个 Agent 协作、Agent 能力广度、真实世界适用性

 ## Key Quotes
-> "mode: subagent — agent is available on-demand, not shown in the primary Tab-cycle list"
-> — Agent YAML frontmatter 的核心语义，说明 subagent 模式与普通 agent 的本质区别
+> "What does it actually look like when the full agency collaborates?" — 核心问题
+> "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 循环
- [[OpenCode]]：一个支持多 Agent 协作的 IDE/编辑器扩展平台
+- [[Multi-Agent-Collaboration]]：多个专业 Agent 在同一任务上并行协作，通过共享上下文相互引用，无需显式协调
+- [[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]]
- [[The Agency]] ← Agent 定义来源 ← [[Agent/agency-agents/integrations/opencode/README.md]]
+- [[Nexus-Spatial-Discovery]] ← exemplifies ← [[Multi-Agent-Collaboration]]
+- [[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 间存在依赖关系，仍需协调机制
--- a/wiki/sources/support-executive-summary-generator.md
+++ b/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 无直接概念冲突。
--- a/wiki/sources/support-finance-tracker.md
+++ b/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 内容的冲突
--- a/wiki/sources/support-infrastructure-maintainer.md
+++ b/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 步骤，在部署前完成自动化合规扫描，不阻断常规变更但强制阻断高风险变更
--- a/wiki/sources/support-legal-compliance-checker.md
+++ b/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 是质量门禁。
--- a/wiki/sources/support-support-responder.md
+++ b/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 处理
--- a/wiki/sources/testing-accessibility-auditor.md
+++ b/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）：倾向于相信自动化工具的检测能力
+  - 建议：两者协同使用，自动化工具作为基线，手动测试作为深度验证
--- a/wiki/sources/workflow-book-chapter.md
+++ b/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 生成内容必须保持第一人称声音、依附来源材料或明确标记为假设
+  - 对方观点：专业写手可以完全替代作者完成写作，无需维持原始素材关联
--- a/wiki/sources/workflow-landing-page.md
+++ b/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 的时间线以"周"为单位（长周期迭代），本工作流以"小时"为单位（短周期冲刺）。两者互补，后者是前者在单日冲刺场景下的具体化。
--- a/wiki/sources/workflow-startup-mvp.md
+++ b/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 工作流文档可共存。
--- a/wiki/sources/workflow-with-memory.md
+++ b/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 不可用的环境中，沿用原始工作流的手动粘贴策略