Auto-sync: 2026-04-25 04:02

wiki/sources/macos-spatial-metal-engineer.md

@@ -0,0 +1,62 @@
+---
+title: "macOS Spatial/Metal Engineer Agent Personality"
+type: source
+tags: [agent, apple, metal, spatial-computing, visionos, xr]
+date: 2026-04-25
+---
+
+## Source File
+- [[raw/Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：macOS Spatial/Metal Engineer Agent 的人格定义——一个专注于 Swift + Metal 渲染的空间计算专家 Agent，负责构建 macOS 和 Vision Pro 上的高性能 3D 可视化系统
+- 问题域：如何在 Apple 平台上实现大规模图数据的高性能 GPU 渲染，并将渲染流通过 Compositor Services 传输到 Vision Pro 进行沉浸式空间计算体验
+- 方法/机制：使用实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点；通过 RemoteImmersiveSpace 和 LayerRenderer 实现 Vision Pro 立体帧流；用 Metal Compute Shader 实现 GPU 物理力导向图布局
+- 结论/价值：定义了一个完整的 Apple 平台空间计算 Agent 技术栈，从渲染管线到手势交互到性能调优，覆盖了 visionOS/macOS 跨平台沉浸式开发的核心路径
+
+## Key Claims（用中文描述）
+- Agent 通过实例化 Metal 渲染，可在 90fps 立体渲染下驱动 25k 节点图数据
+- Agent 使用 RemoteImmersiveSpace 实现 macOS 与 Vision Pro 的全沉浸式代码可视化连接
+- Agent 通过 LayerRenderer 的 stereo 配置（RGBA16Float + Depth32Float）实现高质量立体帧流
+- Agent 利用 Metal Compute Shader 执行 GPU 并行力导向图布局，避免 CPU 瓶颈
+- Agent 将注视（Gaze）追踪 + 捏合（Pinch）手势识别作为主要空间交互方式
+
+## Key Quotes
+> "Never drop below 90fps in stereoscopic rendering" — Metal 渲染硬性性能要求
+> "Use instanced drawing for massive node counts" — 核心渲染优化策略
+> "Stream stereo frames to Vision Pro via Compositor Services" — 跨设备渲染架构目标
+> "Implement proper depth ordering for stereoscopic rendering" — Vision Pro 立体渲染规范
+
+## Key Concepts
+- [[Instanced Rendering]]：通过单次 draw call 批量渲染大量节点，每个节点含 position/color/scale/symbolId 属性
+- [[RemoteImmersiveSpace]]：macOS 与 Vision Pro 之间的全沉浸式空间连接协议
+- [[Compositor Services]]：提供 LayerRenderer 用于生成和提交立体帧到 Vision Pro
+- [[LayerRenderer]]：配置 stereo 模式、RGBA16Float 颜色格式和 Depth32Float 深度格式的渲染层
+- [[Force-Directed Graph Layout]]：在 Metal Compute Shader 中实现的力导向图物理模拟（排斥力 + 吸引力 + 阻尼）
+- [[Metal System Trace]]：Xcode Instruments 工具，用于分析 Metal 帧时间和 GPU 利用率
+- [[Stereoscopic Rendering]]：双眼立体渲染，需维护正确的深度顺序和 vergence-accommodation 限制
+- [[GPU-Driven Rendering]]：通过 Indirect Command Buffers 实现 GPU 自主驱动的渲染管线
+- [[Triple Buffering]]：三缓冲策略保证 CPU-GPU 数据传输与渲染流水线的平滑衔接
+- [[Frustum Culling & LOD]]：视锥裁剪和层级细节优化，用于大规模图数据的性能保障
+
+## Key Entities
+- [[Apple]]：平台生态——提供 Metal、visionOS、CompositorServices 等核心框架
+- [[Vision Pro]]：目标设备——通过 RemoteImmersiveSpace 接收来自 macOS 的立体渲染流
+- [[Metal]]：底层图形 API——支持 instanced rendering、compute shaders、geometry shaders
+- [[Xcode Instruments]]：性能分析工具——Metal System Trace 用于帧时间和 GPU 利用率分析
+- [[RealityKit]]：空间锚点支持——用于 Vision Pro 空间锚点的持久化管理
+- [[ARKit]]：环境映射——结合 ARKit 实现环境光照和空间理解
+
+## Connections
+- [[macos-spatial-metal-engineer]] ← builds ← [[MetalGraphRenderer]]（核心渲染组件）
+- [[macos-spatial-metal-engineer]] ← integrates_with ← [[VisionProCompositor]]（Vision Pro 流式连接）
+- [[macos-spatial-metal-engineer]] ← uses ← [[ForceDirectedGraphLayout]]（GPU 物理模拟）
+- [[xr-immersive-developer]] ← shares_architecture_with ← [[macos-spatial-metal-engineer]]（XR 开发领域重叠）
+- [[visionos-spatial-engineer]] ← extends ← [[macos-spatial-metal-engineer]]（visionOS 专用扩展）
+
+## Contradictions
+- 与 [[visionos-spatial-engineer]] 可能存在职责重叠：
+  - 冲突点：两者都涉及 Vision Pro 开发，但侧重点不同
+  - 当前观点：macOS Spatial/Metal Engineer 专注 macOS 侧渲染管线 + Vision Pro 流式输出
+  - 对方观点：visionOS Spatial Engineer 专注 visionOS 原生空间交互开发
+  - 协调：两者可协同——macOS 侧负责高性能渲染，visionOS 侧负责原生交互体验

wiki/sources/paid-media-creative-strategist.md

@@ -0,0 +1,63 @@
+---
+title: "Paid Media Ad Creative Strategist Agent"
+type: source
+tags: ["paid-media", "creative", "advertising", "google-ads", "meta-ads", "ppc", "agent-persona"]
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/paid-media/paid-media-creative-strategist.md]]
+
+## Summary（用中文描述）
+- 核心主题：付费媒体广告创意策略 Agent，专注于 Google、Meta、Microsoft 及程序化平台的全渠道广告文案创作、响应式搜索广告（RSA）架构设计和系统性创意测试框架。
+- 问题域：如何在算法控制竞价、预算和定向的自动化竞价环境中，通过创意这一唯一可控变量实现效果最大化；创意疲劳监测与快速迭代难题。
+- 方法/机制：15-headline RSA 策略设计（全品牌/利益/功能/CTA/社会证明分类）；Hook-Body-CTA 视频广告结构；资产组（Asset Group）组合策略；A/B 测试框架与统计显著性标准；广告强度评分优化。
+- 结论/价值：创意是自动化竞价环境中最大的可控杠杆，每一条标题、描述、图片和视频都是一个待验证的假设，必须通过系统性测试持续迭代。
+
+## Key Claims（用中文描述）
+- 在 tCPA/tROAS/Max Conversions 等自动化竞价环境中，创意是广告主唯一实际可控的变量，算法接管了出价、预算和定向。
+- RSA 的 15 条标题和 4 条描述的所有可能组合必须语法和逻辑上都能成立，这是架构设计的核心挑战。
+- 创意疲劳（Creative Fatigue）是效果下降的主因，必须通过 CTR 趋势监测和超优展示阈值识别及时刷新。
+- 广告强度（Ad Strength）90%+ 达到 "Good" 或 "Excellent" 是 RSA 质量基准；Meta 相关性诊断需高于平均或顶级表现。
+- 统计显著性（Statistical Significance）是判定创意胜负的唯一可靠标准，必须在 2-4 周内达到。
+
+## Key Quotes
+> "Creative is the largest remaining lever in automated bidding environments — when the algorithm controls bids, budget, and targeting, the creative is what you actually control." — 核心价值观阐述
+> "Every headline, description, image, and video is a hypothesis to be tested." — 创意即假设
+> "Always audit existing ad performance before writing new creative. If API access is available, pull list_ads and ad strength data as the starting point for any creative refresh." — 数据优先原则
+
+## Key Concepts
+- [[ResponsiveSearchAds]]: RSA（响应式搜索广告），Google Ads 核心广告格式，由最多 15 条标题和 4 条描述自由组合，系统自动测试最优搭配。
+- [[PerformanceMax]]: Performance Max 广告系列，Google 全渠道自动化广告，创意资产组（Asset Group）是核心输入，决定系统学习信号质量。
+- [[AssetGroup]]: 资产组，Performance Max 的创意容器，由文本资产、图片、视频、Logo 等组成，决定广告主题表达质量。
+- [[AdStrength]]: 广告强度评分，Google 衡量 RSA 或 PMax 创意质量的指标，90%+ "Good/Excellent" 是基准目标。
+- [[CreativeFatigue]]: 创意疲劳，广告在超优展示阈值后点击率自然下降的现象，需通过定期刷新和新鲜创意对抗。
+- [[HookBodyCTA]]: Hook-Body-CTA 结构，视频广告的叙事框架——钩子（0-3秒）吸引注意，主体传递价值，号召行动促进转化。
+- [[ABTesting]]: A/B 测试框架，创意验证的标准方法，通过统计显著性判定胜负，指导规模化应用。
+- [[MessageMatch]]: 消息匹配评分，衡量广告创意与落地页内容一致性的指标，直接影响质量得分和转化率。
+- [[StatisticalSignificance]]: 统计显著性，创意测试的判断标准，确保结果可推广而非随机波动。
+- [[AdExtensions]]: 广告附加信息（Sitelink/Callout/Structured Snippets/Image Extensions 等），扩展广告视觉空间和点击率。
+
+## Key Entities
+- [[GoogleAds]]: Google Ads 平台，核心投放渠道，提供 RSA、Performance Max、Ad Strength 数据和 Google Ads MCP 工具集成。
+- [[MetaAdsManager]]: Meta（Facebook/Instagram）广告管理平台，支持 Primary Text/Headline/Description 框架和 Relevance Diagnostics。
+- [[MicrosoftAdvertising]]: Microsoft Advertising（Bing/AOL/Yahoo）搜索广告平台，与 Google Ads 并行的 PPC 渠道。
+- [[PerformanceMax]]: Google Performance Max 广告系列，AI 驱动的全渠道投放，Asset Group 质量决定效果上限。
+- [[JohnWilliams]]: Agent 作者（@itallstartedwithaidea），资深付费媒体创意策略师。
+
+## Connections
+- [[PaidMediaPpcStrategist]] ← coordinates_with ← [[PaidMediaCreativeStrategist]]: PPC 策略师制定活动架构，创意策略师提供素材支撑，两者协同制定 Performance Max 和 Display 投放方案。
+- [[PaidMediaProgrammaticBuyer]] ← depends_on ← [[PaidMediaCreativeStrategist]]: 程序化购买依赖高质量创意资产填充展示和视频广告库存。
+- [[PaidMediaSearchQueryAnalyst]] ← informs ← [[PaidMediaCreativeStrategist]]: 搜索查询分析师提供关键词意图数据，创意策略师据此撰写关键词插入文案。
+- [[PaidMediaTrackingSpecialist]] ← depends_on ← [[PaidMediaCreativeStrategist]]: 追踪专家提供的 CTR/CVR 数据是判断创意胜负的基础。
+- [[PaidMediaAuditor]] ← depends_on ← [[PaidMediaCreativeStrategist]]: 审计师诊断广告效果，创意刷新是优化策略的核心输出之一。
+
+## Contradictions
+- 与 [[PaidMediaPpcStrategist]] 在"自动化程度"权衡上存在张力：
+  - 冲突点：PPC 策略师倾向于强调 Smart Bidding 和自动化优化；创意策略师认为创意质量是瓶颈，自动化不能弥补低质量素材。
+  - 当前观点：创意是决定性杠杆，即使在自动化竞价环境中也需要人工精心设计的 RSA 组合和 Asset Group 策略。
+  - 对方观点：Broad Match + Smart Bidding 组合可以弥补创意不足，系统会自动寻找最优受众-创意搭配。
+- 与 [[PaidMediaProgrammaticBuyer]] 在"创意新鲜度"上存在潜在冲突：
+  - 冲突点：程序化购买强调规模化和成本效率，倾向于复用已有创意；创意策略师强调创意疲劳必须通过高频迭代对抗。
+  - 当前观点：持续创意迭代（每 2 周一次测试）是效果保持的必要条件，低频迭代会导致 CPM 上升和 CTR 下降。
+  - 对方观点：程序化购买的受众覆盖足够广泛，可以抵消创意疲劳的影响。

wiki/sources/paid-media-paid-social-strategist.md

@@ -0,0 +1,54 @@
+---
+title: "Paid Social Strategist"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/paid-media/paid-media-paid-social-strategist.md]]
+
+## Summary（用中文描述）
+- 核心主题：跨平台付费社交广告专家 Agent，覆盖 Meta（Facebook/Instagram）、LinkedIn、TikTok、Pinterest、X 和 Snapchat，设计从引流到再营销的全漏斗社交广告项目。
+- 问题域：社交广告的本质是"打断"而非"回答"，如何在各平台原生体验与广告效果之间取得平衡；iOS 隐私政策对追踪归因的冲击；跨平台受众重叠与频次管理难题。
+- 方法/机制：全漏斗结构（引流 → 互动 → 再营销 → 留存）；平台差异化创意策略（UGC 风格适配 TikTok/Meta，专业内容适配 LinkedIn）；受众工程（像素自定义受众、CRM 上传、互动受众）；Conversions API / 服务端事件追踪；SKAdNetwork 应对 iOS 隐私变化。
+- 结论/价值：为每个社交平台构建原生广告体验，而非跨平台复用同一创意；通过跨渠道数据验证增量贡献，避免重复计算转化。
+
+## Key Claims（用中文描述）
+- 付费社交广告本质上是"打断"用户而非"回答"问题，因此创意和受众策略必须赢得用户注意力。
+- 各平台是独立生态系统（Meta Ads Manager、LinkedIn Campaign Manager、TikTok Ads 各有不同算法机制和用户行为），不应跨平台复用同一套创意。
+- iOS 隐私变化后，SKAdNetwork 和聚合事件测量成为移动归因的核心手段，Conversions API 实施至关重要。
+- 跨渠道预算分配必须基于跨渠道证据（搜索+展示+社交综合数据），避免基于单一渠道数据做预算决策。
+
+## Key Quotes
+> "Social advertising is fundamentally different from search — you're interrupting, not answering, so the creative and targeting have to earn attention." — 核心哲学阐述
+
+> "When cross-channel API data is available, always validate social performance against search and display results before recommending budget increases." — 跨渠道验证原则
+
+## Key Concepts
+- [[Full-Funnel Campaign Architecture]]：从引流（Prospecting）到留存（Retention）的完整漏斗结构，各阶段受众策略与预算分配各异。
+- [[Custom Audience Engineering]]：基于像素的自定义受众、CRM 名单上传、互动受众（视频观看者、主页互动者、表单开启者）的构建与排除策略。
+- [[Conversions API]]：服务端事件追踪，与平台像素配合绕过浏览器限制，是后 iOS 14 隐私政策的关键归因基础设施。
+- [[Advantage+ Campaigns]]：Meta 的自动化广告系列，利用机器学习优化受众定位和竞价，是 CBO/ABO 架构的重要演进。
+- [[Audience Overlap Analysis]]：跨平台受众重叠分析，防止频次过载，最大化独特触达。
+- [[Incrementality Testing]]：增量测试，验证社交广告是否带来净新增转化，而非蚕食自然搜索流量。
+- [[SKAdNetwork]]：Apple 的隐私化归因框架，替代 IDFA，用于衡量 iOS 应用广告效果。
+
+## Key Entities
+- [[Meta Ads Manager]]：Facebook/Instagram 广告管理平台，核心工具包括 Advantage+ 购物广告、应用广告、目录销售等。
+- [[LinkedIn Campaign Manager]]：LinkedIn 广告管理后台，支持赞助内容、消息广告、文档广告、ABM 名单上传等 B2B 定向功能。
+- [[TikTok Ads]]：TikTok 广告平台，支持 Spark Ads、TopView、信息流广告、品牌标签挑战等原生内容形式。
+- [[Google Ads MCP Tools]]：可选集成工具，用于跨渠道（搜索+社交）数据对比、增量验证和预算决策支持。
+- [[John Williams]]（@itallstartedwithaidea）：Agent 作者。
+
+## Connections
+- [[Paid Media Search Query Analyst]] ← parallel_specialization ← [[Paid Media Paid Social Strategist]]（两者同属付费媒体 Agent 体系，一个专注搜索查询，一个专注社交广告）
+- [[Paid Media Programmatic Buyer]] ← channel_extension ← [[Paid Media Paid Social Strategist]]（程序化购买与社交广告共享受众工程和数据归因方法论）
+- [[Paid Media Creative Strategist]] ← depends_on ← [[Paid Media Paid Social Strategist]]（创意策略依赖社交策略的受众洞察和平台选择）
+- [[Paid Media Auditor]] ← informs ← [[Paid Media Paid Social Strategist]]（审计结果指导社交广告的优化方向）
+
+## Contradictions
+- 与 [[Paid Media Programmatic Buyer]] 在"自动化 vs. 控制"的权衡上存在张力：
+  - 冲突点：程序化购买强调自动化竞价和实时优化；社交广告中的 Advantage+ 也强调自动化，但该 Agent 同时强调人工干预的受众排除和频次管理。
+  - 当前观点：社交广告需要人工把控受众排除策略和跨平台频次，防止自动化算法过度扩张。
+  - 对方观点：程序化购买可以高度依赖算法自动学习，人工干预应最小化。

wiki/sources/paid-media-tracking-specialist.md

@@ -0,0 +1,55 @@
+---
+title: "Paid Media Tracking & Measurement Specialist Agent"
+type: source
+tags: ["paid-media", "agent", "tracking", "measurement", "GTM", "GA4"]
+date: 2026-04-20
+last_updated: 2026-04-25
+sources: []
+---
+
+## Source File
+- [[Agent/agency-agents/paid-media/paid-media-tracking-specialist.md]]
+
+## Summary（用中文描述）
+- **核心主题**：付费媒体追踪与归因专家 Agent——负责构建跨平台（GTM、GA4、Google Ads、Meta CAPI、LinkedIn Insight Tag）的事件追踪架构，确保每一次转化都被正确计数，每一分广告投入都可衡量。
+- **问题域**：标签容器臃肿、跨平台重复计数、归因模型失准、隐私合规（GDPR/CCPA/Consent Mode v2）挑战、UA→GA4/客户端→服务端迁移。
+- **方法/机制**：GTM 容器架构设计、dataLayer 规范、事件去重（event_id 匹配）、增强转化（hashed PII）、服务端容器部署、数据驱动归因模型。
+- **结论/价值**：精准追踪是付费媒体优化的数据根基——错误的数据不仅浪费，更会误导出价算法往错误方向优化。
+
+## Key Claims（用中文描述）
+- 精准追踪工程师构建的数据基础，使所有付费媒体优化成为可能。
+- 错误追踪比无追踪更糟糕——一次错误计数的转化，不仅浪费数据，更会主动误导出价算法向错误结果优化。
+- 追踪 bug 会无声叠加——5% 的数据差异若不修复，明天就变成一个方向错误的出价算法。
+- 重大营销活动前，必须先建立测量计划（Measurement Plan）。
+
+## Key Quotes
+> "Bad tracking is worse than no tracking — a miscounted conversion doesn't just waste data, it actively misleads bidding algorithms into optimizing for the wrong outcomes." — 核心原则
+
+> "Always cross-reference platform-reported conversions against the actual API data. Tracking bugs compound silently — a 5% discrepancy today becomes a misdirected bidding algorithm tomorrow." — 调试方法论
+
+> "If it's not tracked correctly, it didn't happen." — Agent 风格标语
+
+## Key Concepts
+- [[GoogleTagManager]]：GTM 容器架构、工作区管理、触发器/变量设计、自定义 HTML 标签、Consent Mode 实现、标签序列与触发优先级。
+- [[GoogleAnalytics4]]：事件分类体系设计、自定义维度/指标、增强衡量配置、电商 dataLayer 实现（view_item/add_to_cart/begin_checkout/purchase）、跨域追踪。
+- [[MetaConversionsAPI]]：CAPI 服务端配置、事件去重（event_id 匹配）、域名验证、聚合事件测量配置——确保 Pixel 浏览器事件与 CAPI 服务端事件不重复计数。
+- [[ServerSideTagging]]：GTM 服务端容器部署、第一方数据收集、Cookie 管理、服务端富化。
+- [[ConversionTracking]]：Google Ads 转化操作（主转化/次转化）、增强转化（网页和线索）、离线转化 API 导入、转化价值规则、转化操作集。
+- [[AttributionModeling]]：数据驱动归因模型配置、跨渠道归因分析、增量测试设计、营销组合建模输入。
+- [[ConsentModeV2]]：Consent Mode v2 实现、GDPR/CCPA 合规、Cookie Banner 集成、数据保留设置。
+- [[DataLayerArchitecture]]：复杂电商和线索生成网站的 dataLayer 架构设计规范。
+
+## Key Entities
+- [[JohnWilliams]]：Agent 作者（@itallstartedwithaidea）
+- [[TheAgency]]：Agent 所属的多 Agent 协作框架
+
+## Connections
+- [[PaidMediaAdCreativeStrategist]] ← complementary ← [[PaidMediaTrackingSpecialist]]
+- [[PaidMediaPaidSocialStrategist]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（Social 广告依赖精准追踪）
+- [[PaidMediaPPCStrategist]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（PPC 依赖转化追踪数据）
+- [[PaidMediaProgrammaticBuyer]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（程序化投放依赖归因模型）
+- [[PaidMediaSearchQueryAnalyst]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（搜索词分析依赖转化数据）
+- [[PaidMediaAuditor]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（审计依赖追踪准确性验证）
+
+## Contradictions
+- （暂无发现与其他页面的内容冲突）

wiki/sources/sales-account-strategist.md

@@ -0,0 +1,63 @@
+---
+title: "Account Strategist Agent"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/sales/sales-account-strategist.md]]
+
+## Summary（用中文描述）
+- 核心主题：Account Strategist（账户策略师）Agent —— 售后收入扩张战略智能体，专门负责账户扩展、QBR设计、利益相关者映射和净收入留存
+- 问题域：SaaS/企业软件公司如何将一次性成交转化为长期平台关系，如何通过系统性扩张规划实现净收入留存（NRR）最大化
+- 方法/机制：Land-and-Expand 执行框架 → 季度业务回顾（QBR）设计 → 利益相关者多线程关系建设 → NRR 健康评分体系 → 流失预警干预机制
+- 结论/价值：最佳销售时机是客户成功时；账户健康优先于扩张；永远不做单线程账户；NRR 是终极指标
+
+## Key Claims（用中文描述）
+- 账户策略师将每个客户账户视为一片有待填充的空白领域（territory with whitespace），通过系统性扩张规划将单点解决方案转化为企业平台
+- 每个扩张机会必须配套来自客户视角的文档化商业案例，单纯有信号不足以触发扩张
+- 永远不在尚未成功使用现有产品的账户上推扩张——向不健康的账户销售更多会加速流失而非增长
+- 区分扩张就绪（客户可以买更多）与扩张意图（客户想买更多），只有后者才能可靠转化
+- 每个账户必须有至少三条独立的业务关系线——即使冠军明天离职，你仍然能与关心产品的其他人保持活跃对话
+- NRR（净收入留存）是终极指标，它用一个数字捕获了扩张、收缩和流失
+- QBR 应是前瞻性的战略规划会议，而非回顾性的状态报告
+
+## Key Quotes
+> "The best time to sell more is when the customer is winning." — Account Strategist Agent 核心理念
+> "A signal alone is not enough. Every expansion signal must be paired with context (why is this happening?), timing (why now?), and stakeholder alignment (who cares about this?)." — Expansion Signal Discipline
+> "Never pitch expansion to a customer who is not yet successful with what they already own." — Account Health First Rule
+> "NRR is the ultimate metric. It captures expansion, contraction, and churn in a single number. Optimize for NRR, not bookings." — Account Health First Rule
+> "Be strategically specific: 'Usage in the analytics team hit 92% capacity — their headcount is growing 30% next quarter, so expansion timing is ideal.'" — Communication Style
+
+## Key Concepts
+- [[Land-and-Expand]]：将初始成交（land deal）逐步扩展为七位数平台关系的系统性方法论，包括扩张就绪信号识别、冠军赋能套件、RACI 扩张剧本
+- [[Net Revenue Retention (NRR)]]：净收入留存率——捕获扩张、收缩和流失的综合指标，NRR > 100% 意味着即使没有新客户也能实现增长
+- [[QBR (Quarterly Business Review)]]：季度业务回顾——前瞻性战略规划会议，包含 ROI 数据量化回顾、业务目标对齐、共同行动计划
+- [[Stakeholder Mapping]]：利益相关者映射——维护账户内活的利益相关者地图：决策者、预算持有者、影响者、终端用户、反对者、冠军
+- [[Multi-Threading]]：多线程关系建设——每个账户至少三条独立关系线，防止单点失败（champion 离职导致的关系断层）
+- [[Account Health Score]]：账户健康评分——综合产品使用率、支持工单情感、利益相关者参与度、合同时间线、高管发起人活动
+- [[Churn Prevention Playbook]]：流失预防手册——早期预警信号 + 分级干预计划（立即/短期/中期）
+
+## Key Entities
+- **Account Strategist Agent**：售后扩张策略师角色，对应 [[sales-account-strategist]]
+- **Account Executive (AE)**：客户经理，与账户策略师在扩张剧本、RACI 中协作
+- **Customer Success (CS)**：客户成功团队，负责使用监控和健康评分维护
+- **Product Team**：产品团队，参与扩张对齐和里程碑触发
+- **Executive Sponsor**：高管发起人——高参与度（>60天未接触=风险信号）是账户健康的领先指标
+
+## Connections
+- [[sales-proposal-strategist]] ← post-sale extends pre-sale ← [[sales-proposal-strategist]]
+- [[sales-engineer]] ← overlaps (both post-sale) ← [[sales-engineer]]
+- [[sales-discovery-coach]] ← upstream feeds downstream ← [[sales-discovery-coach]]
+- [[sales-pipeline-analyst]] ← shares NRR metric ← [[sales-pipeline-analyst]]
+
+## Contradictions
+- 与 [[sales-proposal-strategist]] 的关注阶段不同：
+  - 冲突点：提案策略师关注赢单前的提案叙事；账户策略师关注赢单后的扩张执行
+  - 当前观点：两者互补——提案建立期望，账户策略师交付并超越期望
+  - 对方观点：[[sales-proposal-strategist]] 的"赢单叙事"需要考虑 post-sale 的可交付性
+- 与 [[sales-coach]] 的辅导焦点不同：
+  - 冲突点：销售教练辅导卖方（销售代表成长）；账户策略师辅导买方（帮助客户内部推广）
+  - 当前观点：互补关系——[[sales-coach]] 提升卖方能力，[[sales-account-strategist]] 建设买方冠军
+  - 对方观点：无直接冲突，角色边界清晰

wiki/sources/sales-coach.md

@@ -0,0 +1,54 @@
+---
+title: "Sales Coach Agent"
+type: source
+tags: ["sales", "coaching", "agent", "b2b"]
+date: 2026-04-24
+---
+
+## Source File
+- [[Agent/agency-agents/sales/sales-coach.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长，专注于管道审查、话术辅导、交易策略和预测准确性
+- 问题域：销售团队管理、销售代表能力发展、交易风险识别、预测纪律
+- 方法/机制：结构化辅导框架（ Richardson Sales Performance）、挑战者销售模型（Challenger）、MEDDPICC 资质诊断、行为反馈循环
+- 结论/价值：正式销售辅导项目使配额完成率达 91.2%（vs 非正式辅导 84.7%），每周接受2小时以上辅导的销售代表赢单率达56%（vs 少于30分钟仅43%）
+
+## Key Claims（用中文描述）
+- 正式销售辅导项目使团队配额完成率达 91.2%，显著优于非正式辅导的 84.7%
+- 每周接受 2 小时以上辅导的销售代表赢单率为 56%，远高于每周少于 30 分钟辅导的 43%
+- 辅导行为而非结果：过程完美的输单不需要纠正，幸运赢单需要立即辅导
+- 管道数量是虚荣指标，管道质量才是管理工具
+- 每次辅导互动必须产出一个具体、可行为、可执行的改进建议
+
+## Key Quotes
+> "Ask before telling. Your first instinct should always be a question, not an instruction." — 苏格拉底式辅导的核心原则
+> "A lost deal with disciplined process is more valuable than a lucky win, because process compounds and luck does not." — 过程优于结果
+> "Enthusiasm without commitment is not a buying signal." — 挑战"happy ears"，要求可验证的承诺
+
+## Key Concepts
+- [[MEDDPICC]]：交易资质诊断框架，包含八个维度（Metrics、Economic Buyer、Decision Criteria、Decision Process、Paper Process、Implicated Pain、Champion、Competition）；Deal 少于 5/8 字段填充即为资格不足，是预测失误的主要来源；资质缺口是交易风险的信号，而非 CRM 记录问题
+- [[Challenger Sales Model]]：挑战者辅导模型，教导销售代表以商业洞察引领对话，而非被动回应客户需求；在客户思考问题的方式上重新构建认知
+- [[Richardson Sales Performance Framework]]：四维能力框架：辅导卓越、激励领导、销售管理纪律、战略规划
+- [[Pipeline Review]]：将管道审查从审讯转变为辅导对话，用"我们对这个交易还有什么不知道的"替代"什么时候关单"
+- [[Forecast Accuracy]]：基于可验证证据而非乐观情绪的预测纪律，区分 upside/commit/closed 三个层级
+- [[Coaching Discipline]]：辅导纪律——行为辅导而非结果辅导；一次只做一件事；跟进反馈是否被应用
+
+## Key Entities
+- [[Discovery Coach Agent]]：同为 The Agency 销售类 Agent，专注发现阶段辅导，与 Sales Coach 形成互补关系
+- [[Sales Pipeline Analyst Agent]]：管道分析类 Agent，提供数据支撑，与 Sales Coach 协同工作
+- [[Sales Deal Strategist Agent]]：交易策略类 Agent，在重大交易前进行策略准备
+
+## Connections
+- [[Discovery Coach Agent]] ← complements ← [[Sales Coach Agent]]
+- [[Sales Pipeline Analyst Agent]] ← provides_data_for ← [[Sales Coach Agent]]
+- [[Sales Deal Strategist Agent]] ← prepares ← [[Sales Coach Agent]]
+- [[Sales Coach Agent]] ← uses ← [[MEDDPICC]]
+- [[Sales Coach Agent]] ← uses ← [[Challenger Sales Model]]
+
+## Contradictions
+- 与 [[Discovery Coach Agent]] 的潜在差异：
+  - 冲突点：辅导焦点的层次不同
+  - 当前观点（Sales Coach）：辅导范围覆盖全销售周期，包括发现、策略、预测
+  - 对方观点（Discovery Coach）：专注发现阶段的深度辅导
+  - 协调方案：Discovery Coach 负责发现阶段深度，Sales Coach 负责整体辅导规划，两者协同覆盖完整周期

wiki/sources/sales-deal-strategist.md

@@ -0,0 +1,61 @@
+---
+title: "Deal Strategist Agent"
+type: source
+tags: []
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/sales/sales-deal-strategist.md]]
+
+## Summary（用中文描述）
+- 核心主题：B2B 复杂销售周期的高级deal策略与管线架构
+- 问题域：销售管线中deal质量评估不严、预测失准、竞争定位模糊、赢率低下
+- 方法/机制：MEDDPICC八维资质评分 + Challenger商业教学法 + 三区竞争定位 + 六步商业教学序列 + 交易检查方法论
+- 结论/价值：全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%；预测准确率Commit deals关闭率85%+；Qualified Pipeline赢率35%+
+
+## Key Claims（用中文描述）
+- 全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%——但前提是将MEDDPICC作为思维工具而非打勾练习
+- 一个deal若没有回答全部八个要素，说明尚未真正理解该deal
+- 6周采购周期如果在第11周才发现，会直接扼杀季度
+- 决策在理性层面被论证，在感性层面被做出
+- 预测准确率Commit deals关闭率应达85%+
+- Qualified Pipeline（28/40分以上）赢率应达35%+
+- 竞争定位中的Losing Zone应对策略是缩小其重要性，而非撒谎或攻击竞争对手
+
+## Key Quotes
+> "A deal without all eight answered is a deal you don't understand." — MEDDPICC核心原则
+> "This deal is at risk. Here's why, and here's what to do about it." — 策略师沟通风格
+> "Decisions are justified rationally and made emotionally." — 商业教学情感层
+> "The winning move on losing zones is to shrink their importance, not to lie about your capabilities." — 竞争定位原则
+
+## Key Concepts
+- [[MEDDPICC]]：八维资质评分框架——Metrics/Economic Buyer/Decision Criteria/Decision Process/Paper Process/Identify Pain/Champion/Competition，每维度5分，满分40
+- [[Challenger Sales Model]]：挑战者销售法——通过商业教学重新定义买方对自身问题的理解，在定位解决方案之前先建立价值
+- [[Command of the Message]]：信息掌控框架——三层支柱（我们解决什么问题/我们如何不同/客户实现什么可衡量成果）
+- Deal Scoring：加权评分模型，分离真实管线与虚假管线，含预警指标
+- Competitive Positioning：竞争定位策略——Winning/Battling/Losing三区分类 + 地雷问题布局
+- Win Planning：分阶段行动计划，含明确责任人、里程碑和退出标准
+- Deal Inspection Methodology：交易检查方法论——系统性探测deal状态、风险和下一步
+- Challenger Messaging：六步商业教学序列——Warmer/Reframe/Rational Drowning/Emotional Impact/A New Way/Your Solution
+
+## Key Entities
+- [[Sales Coach Agent]]：同为The Agency销售体系的核心智能体，Sales Coach辅导卖方行为，Deal Strategist辅导deal策略
+- [[Discovery Coach Agent]]：发现阶段教练，提供买方情境输入给Deal Strategist
+- [[Sales Proposal Strategist]]：赢单叙事构建者，接收Deal Strategist的竞争定位和评分输出
+- Deal Strategist Agent：The Agency销售部门成员，专业于MEDDPICC deal策略、竞争定位和赢单规划
+
+## Connections
+- [[sales-coach]] ← shares MEDDPICC framework with ← [[sales-discovery-coach]]
+- [[sales-proposal-strategist]] ← receives win strategy input from ← [[sales-deal-strategist]]
+- [[sales-discovery-coach]] ← provides buyer context to ← [[sales-deal-strategist]]
+- [[sales-deal-strategist]] ← extends MEDDPICC with deal execution tactics ← [[sales-coach]]
+
+## Contradictions
+- 与 [[sales-proposal-strategist]] 的视角差异：
+  - 冲突点：Deal Strategist聚焦交易层面的策略和执行，Proposal Strategist聚焦提案层面的叙事和说服
+  - 当前观点：Deal Strategist认为"没有全面评估的deal在预测会上就输了"
+  - 对方观点：Proposal Strategist认为"赢单在提案开篇100词就已决定"
+  - 协调：两者互补——Deal Strategist提供结构化deal分析和竞争定位，Proposal Strategist将其转化为说服性叙事
+- 与 [[sales-discovery-coach]] 的互补关系：
+  - Discovery Coach发现买方情境，Deal Strategist基于此构建交易策略，两者构成"发现→策略"闭环

wiki/sources/sales-discovery-coach.md

@@ -0,0 +1,50 @@
+---
+title: "Discovery Coach Agent"
+type: source
+tags: [sales, discovery, methodology, coaching]
+last_updated: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/sales/sales-discovery-coach.md]]
+
+## Summary（用中文描述）
+- 核心主题：销售发现访谈（Discovery）方法论与教练框架，帮助销售代表成为更优秀的买家访谈者
+- 问题域：销售团队普遍存在发现访谈深度不足、问题设计粗糙、无法挖掘真正购买动机的问题
+- 方法/机制：三大发现框架（SPIN Selling / Gap Selling / Sandler Pain Funnel）+ 标准30分钟发现电话结构 + AECR异议处理框架
+- 结论/价值：发现是交易成败的关键战场——而非演示、提案或谈判阶段。顶级销售通过多问一个问题来击败竞争对手
+
+## Key Claims（用中文描述）
+- 发现阶段决定交易成败，而非演示、提案或谈判阶段
+- Implication问题（SPIN Selling第三层）是最有力的成交工具，因其激活买家的损失厌恶心理
+- Gap Selling中，根因问题是最重要也最常被跳过的问题；表面问题不产生紧迫感，根因才产生
+- Sandler Pain Funnel第三层（个人/情感层面）是大多数销售人员永远不会触及的区域，但购买决策本质上是情感决策
+- 预算异议几乎从不是真正的预算问题，而是买家对价值是否超过成本的判断
+
+## Key Quotes
+> "Implication questions are uncomfortable to ask. That discomfort is a feature. The buyer has not fully confronted the cost of the status quo until these questions are asked." — SPIN Selling中Implication问题的价值说明
+> "Level 3 is where most sellers never go. But buying decisions are emotional decisions with rational justifications." — Sandler Pain Funnel第三层的重要性
+> "Budget objections are almost never about budget. They are about whether the buyer believes the value exceeds the cost." — 预算异议的真相
+> "The 60/40 rule: the buyer should talk 60% of the time or more. If you are talking more than 40%, you are pitching, not discovering." — 发现访谈的核心比例原则
+
+## Key Concepts
+- [[SPIN Selling]]：Neil Rackham提出的企业销售四步提问法（Situation / Problem / Implication / Need-Payoff），核心洞察是Implication问题通过激活损失厌恶来推动成交
+- [[Gap Selling]]：Keenan提出的以当前状态与期望未来状态之间的差距为中心的销售方法论；差距越大，紧迫感越强
+- [[Sandler Pain Funnel]]：从表面症状到商业影响再到情感/个人层面的三层漏斗式发现技术
+- [[AECR Framework]]：处理销售异议的四步框架（Acknowledge / Empathize / Clarify / Reframe），将异议视为诊断信息
+- [[Upfront Contract]]：发现电话开场的最优技术，通过预设三种可能结果来建立信任和获取提问许可
+- [[Discovery Call Structure]]：标准30分钟发现电话的时间分配（开场2分钟 / 发现18分钟 / 定向pitch 6分钟 / 下一步4分钟）
+
+## Key Entities
+- [[Neil Rackham]]：SPIN Selling方法论的提出者，通过对35,000+次销售拜访的研究发展出该框架
+- [[Keenan]]：Gap Selling方法论的提出者，强调当前状态与未来状态之间精确差距的商业价值
+- [[Sandler]]：Sandler Pain Funnel的创始人，开发了从表面到个人层面的三层痛苦发现技术
+
+## Connections
+- [[Sales Coach]] ← extends ← [[Discovery Call Structure]]
+- [[SPIN Selling]] ← extends ← [[Sandler Pain Funnel]]（两者互补，SPIN强调问题序列，Sandler强调深度层次）
+- [[AECR Framework]] ← depends_on ← [[Discovery Call Structure]]
+- [[Gap Selling]] ← depends_on ← [[SPIN Selling]]（Gap Selling可视为SPIN框架的实践落地）
+
+## Contradictions
+- 暂无发现与现有Wiki内容的冲突

wiki/sources/sales-engineer.md

@@ -0,0 +1,59 @@
+---
+title: "Sales Engineer Agent"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/sales/sales-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：售前工程师（Sales Engineer）Agent 的角色定义、能力模型与操作框架，专注于在 B2B 技术评估中赢得技术决策
+- 问题域：B2B 软件销售中的技术售前环节——如何设计演示、执行 POC、应对竞争、处理异议、管理评估流程
+- 方法/机制：Demo Engineering（以影响力为导向的演示设计）、POC Scoping（严格限定的概念验证范围）、FIA Framework（事实-影响-行动竞争定位框架）、Evaluation Notes（交易级技术情报维护）
+- 结论/价值：技术决策先于商业决策，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能
+
+## Key Claims（用中文描述）
+- 售前工程师赢得技术决策，销售才能赢得商业合同——技术层是整个交易的关键门槛
+- 演示不是产品tour，而是叙事——买家在演示中看到自己的问题被实时解决
+- POC 不是免费试用，而是有二元结果的结构化评估：成功或失败，标准在开始前就已明确定义
+- 竞争定位应采用 FIA 框架（Fact-Impact-Act），保持事实基础和可操作性，而非情绪化和反应式
+- 永远不要攻击竞争对手——认可竞争对手的优势，同时清晰表达差异化
+
+## Key Quotes
+> "A demo is not a product tour. A demo is a narrative where the buyer sees their problem solved in real time." — 演示的本质是叙事，不是功能演示
+> "Every technical conversation must connect back to a business outcome or it's just a feature dump." — 技术对话必须连接到业务成果
+> "Ambiguous success criteria produce ambiguous outcomes, which produce 'we need more time to evaluate,' which means you lost." — 模糊的成功标准等于失败
+> "Never trash the competition. Buyers respect SEs who acknowledge competitor strengths while clearly articulating differentiation." — 永远不要攻击竞争对手
+
+## Key Concepts
+- [[Demo Engineering]]：以影响力为导向的演示设计，先量化问题，再展示产品，最后证明效果
+- [[POC Scoping]]：严格限定的概念验证范围设计，以成功标准、硬性时间线和检查点为支柱
+- [[FIA Framework]]：Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性
+- [[Evaluation Notes]]：交易级技术情报维护，结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略
+- [[Technical Objection Handling]]：技术异议处理，解码真实问题而非表面问题
+- [[Aha Moment]]：演示中让买家产生"这正是我们需要的"那一刻，是演示成功的核心标志
+
+## Key Entities
+- [[Sales Pipeline Analyst Agent]]：同属销售团队的数据分析 Agent，共同支撑销售闭环
+- [[Sales Outbound Strategist Agent]]：同属销售团队的对外策略 Agent，共同支撑销售闭环
+- [[Deal Strategist Agent]]：同属销售团队的交易策略 Agent，共同支撑销售闭环
+- [[Account Strategist Agent]]：同属销售团队的客户策略 Agent，共同支撑销售闭环
+- [[Sales Proposal Strategist]]：同属销售团队的建议书策略 Agent，共同支撑销售闭环
+
+## Connections
+- [[Sales Pipeline Analyst Agent]] ← team_member ← [[Sales Engineer Agent]]
+- [[Sales Outbound Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
+- [[Deal Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
+- [[Account Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
+- [[Sales Proposal Strategist]] ← team_member ← [[Sales Engineer Agent]]
+- [[Sales Discovery Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]]
+- [[Sales Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]]
+
+## Contradictions
+- 与 [[Sales Discovery Coach Agent]] 在"技术深度"维度存在互补张力：
+  - 冲突点：售前工程师在发现阶段应保持多深的技术参与度？
+  - 当前观点（Sales Engineer）：售前工程师应主导技术发现，结构化地挖掘架构、集成、安全约束和真实技术决策标准
+  - 对方观点（Sales Discovery Coach）：销售发现应聚焦于业务问题，深度技术探索由专门的角色或时机负责
+  - 协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式

wiki/sources/sales-pipeline-analyst.md

@@ -0,0 +1,46 @@
+---
+title: "Pipeline Analyst Agent"
+type: source
+tags: [sales, revenue-operations, pipeline, forecasting, CRM, MEDDPICC]
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/sales/sales-pipeline-analyst.md]]
+
+## Summary（用中文描述）
+- 核心主题：Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent，将 CRM 数据转化为可执行的 Pipeline 洞察，在问题演变为季度失误之前主动预警。
+- 问题域：销售 Pipeline 管理、收入预测准确性、Deal 质量评估、销售教练数据分析
+- 方法/机制：Pipeline Velocity 公式 + MEDDPICC 资格评分 + 多信号预测模型 + Deal 健康评分卡
+- 结论/价值：质量调整后的 Pipeline 覆盖度永远优于阶段加权覆盖度；每份 Pipeline 评估都应至少发现一个需要立即干预的 Deal；预测必须带置信区间而非单一数字。
+
+## Key Claims（用中文描述）
+- Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，四个变量均为诊断杠杆。
+- 目标覆盖比率：成熟可预测业务 3x，成长期或新市场 4-5x，新销售入职 5x+。
+- 晚期阶段 Deal 的 MEDDPICC 字段少于 5/8 即为资格不足，是预测失误的主要来源。
+- 多线程、利益相关者深度参与的 Deal 关闭率是同阶段单线程低活跃度 Deal 的 2-3 倍。
+- 预测必须输出 Commit（>90%置信）/Best Case（>60%）/Upside（<60%）三档，而非单一数字。
+- AI 驱动的预测评分消除两种最常见的人类偏见：销售乐观主义（永远"看起来很好"）和管理层锚定（从上一季度数字而非当前数据分析）。
+
+## Key Quotes
+> "Quality-adjusted coverage discounts pipeline by deal health score, stage age, and engagement signals. A $5M pipeline with 20 stale, poorly qualified deals is worth less than a $2M pipeline with 8 active, well-qualified opportunities." — 质量调整原则：高质量少量 Pipeline 优于大量低质量 Pipeline
+> "Deals with fewer than 5 of 8 MEDDPICC fields populated are underqualified. Underqualified deals at late stages are the primary source of forecast misses." — 晚期阶段资格不足 Deal 是预测失误的主因
+> "The CRM shows $12M in pipeline. After adjusting for stale deals, missing qualification data, and historical stage conversion, the realistic weighted pipeline is $4.8M." — 数据质量对预测的影响示例
+
+## Key Concepts
+- [[PipelineVelocity]]：Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，是 Revenue Operations 最核心的复合指标
+- [[MEDDPICC]]：8维度 Deal 资格评估框架（Metrics、Economic Buyer、Decision Criteria、Decision Process、Paper Process、Implicated Pain、Champion、Competition），用于诊断 Deal 质量和预测可行性
+- [[DealHealthScoring]]：通过资格深度、互动强度、进展速度三维度综合评估 Deal 健康状况的评分体系
+- [[QualityAdjustedCoverage]]：质量调整后的 Pipeline 覆盖度，结合 Deal 健康评分、阶段年龄和互动信号对 Pipeline 进行折减
+- [[RevenueOperations]]：Revenue Operations 的核心分析方法论，活动指标驱动 Pipeline 指标，Pipeline 指标驱动收入结果
+
+## Key Entities
+- [[SalesDealStrategist]]：Deal 策略制定 Agent，与 Pipeline Analyst 共同构成销售情报闭环（Pipeline Analyst 评估 Deal 质量，Deal Strategist 制定推进策略）
+- [[SalesAccountStrategist]]：客户策略 Agent，Pipeline Analyst 为其提供客户层级的 Pipeline 健康数据
+- [[SalesOutboundStrategist]]：外展策略 Agent，其创建的 Pipeline 机会进入 Pipeline Analyst 的监测体系
+
+## Connections
+- [[SalesDealStrategist]] ← depends_on ← [[SalesPipelineAnalyst]]
+- [[SalesAccountStrategist]] ← depends_on ← [[SalesPipelineAnalyst]]
+- [[SalesOutboundStrategist]] ← creates_pipeline_for ← [[SalesPipelineAnalyst]]
+- [[SalesCoach]] ← uses_forecast_data ← [[SalesPipelineAnalyst]]

wiki/sources/sales-proposal-strategist.md

@@ -0,0 +1,51 @@
+---
+title: "Sales Proposal Strategist"
+type: source
+tags: ["sales", "proposal", "RFP", "win-themes", "narrative", "persuasion"]
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/sales/sales-proposal-strategist.md]]
+
+## Summary（用中文描述）
+- 核心主题：销售提案策略师 Agent 的系统化提案撰写方法论——将 RFP 响应从合规检查清单转化为有说服力的赢单叙事
+- 问题域：企业级销售提案、RFP 响应、竞争性投标、赢标主题开发、执行摘要撰写
+- 方法/机制：三幕提案叙事结构（理解挑战→解决方案旅程→转变状态）、3-5 个赢标主题矩阵、执行摘要五步模板、说服架构（首因/近因效应、认知负荷管理、社会认同排序、损失厌恶框架）、内容运营体系
+- 结论/价值：提案的胜负在开篇 100 词内决定；叙事是差异化核心；在能力趋同的商品化市场中，说服力即竞争力
+
+## Key Claims（用中文描述）
+- 赢标主题必须贯穿执行摘要、解决方案叙事、案例研究和定价逻辑——孤立的主题等于隐形的主题
+- 提案在开篇 100 词内决定胜负：评估者通过前 100 词判断供应商是否真正理解他们的业务
+- 执行摘要不是提案的摘要，而是提案的终局论证，应放在最前面
+- 永远不要直接批评竞争对手——将自身优势框架为直接利益，让对比自然形成
+- 定价在价值之后：先建立 ROI 案例、量化问题成本，在买方看到数字之前锚定成果而非成本
+- 内容库应按赢标主题而非章节组织——加速未来提案并保持叙事一致性
+
+## Key Quotes
+> "Proposals are won on clarity and lost on generics." — 核心理念：泛泛而谈即失败
+> "The executive summary is the proposal's closing argument, placed first." — 执行摘要的本质定义
+> "Every proposal needs 3-5 win themes: compelling, client-centric statements that connect your solution directly to the buyer's most urgent needs." — 赢标主题的定义
+> "Micro-stories win sections. Teams that embed micro-stories within technical sections achieve measurably higher evaluation scores." — 微故事的力量
+
+## Key Concepts
+- [[WinThemes|赢标主题（Win Themes）]]：连接解决方案与买方最紧迫需求的核心叙事陈述，贯穿整个提案
+- [[ThreeActProposalNarrative|三幕提案叙事（Three-Act Proposal Narrative）]]：理解挑战→解决方案旅程→转变状态
+- [[ExecutiveSummary|执行摘要（Executive Summary）]]：提案的终局论证，非摘要
+- [[CaptureStrategy|捕获策略（Capture Strategy）]]：RFP 发布前的预定位和关系映射
+- [[PersuasionArchitecture|说服架构（Persuasion Architecture）]]：首因/近因效应、认知负荷管理、社会认同排序、损失厌恶框架
+- [[RFP|RFP（Request for Proposal）]]：招标书/需求建议书
+- [[WinThemeMatrix|赢标主题矩阵（Win Theme Matrix）]]：评估主题与买方需求、差异化因素、证明点映射关系的结构化工具
+
+## Key Entities
+- 无特定命名实体（人/公司/产品/项目）
+
+## Connections
+- [[SalesCoach]] ← related_to ← [[SalesProposalStrategist]]（同属销售 Agent 体系）
+- [[SalesDiscoveryCoach]] ← related_to ← [[SalesProposalStrategist]]（发现阶段为提案策略提供输入）
+- [[SalesEngineer]] ← related_to ← [[SalesProposalStrategist]]（技术销售工程师提供提案技术支撑）
+- [[SalesOutboundStrategist]] ← related_to ← [[SalesProposalStrategist]]（外展策略为提案创造机会）
+- [[SalesDealStrategist]] ← related_to ← [[SalesProposalStrategist]]（deal 策略与提案策略协同）
+
+## Contradictions
+- 暂无冲突

wiki/sources/terminal-integration-specialist.md

@@ -0,0 +1,54 @@
+---
+title: "Terminal Integration Specialist"
+type: source
+tags: []
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/spatial-computing/terminal-integration-specialist.md]]
+
+## Summary（用中文描述）
+- 核心主题：Terminal Integration Specialist 是一个专注于终端仿真、文本渲染优化和 SwiftTerm 集成的 Agent，服务于现代 Swift 应用程序开发。
+- 问题域：如何在 Apple 平台上（iOS/macOS/visionOS）构建高性能、符合无障碍标准的终端模拟器；如何将 SSH 连接到终端仿真器；如何在 SwiftUI 应用中嵌入 SwiftTerm。
+- 方法/机制：
+  - 完整支持 VT100/xterm ANSI 转义序列，实现光标控制与终端状态管理
+  - 使用 Core Graphics / Core Text 优化文本渲染，实现平滑滚动
+  - 通过 SwiftNIO SSH / NMSSH 实现 SSH I/O 桥接
+  - 嵌入式 SwiftUI 生命周期管理和后台 I/O 线程处理
+- 结论/价值：提供了一套完整的 Apple 平台终端集成解决方案，兼顾性能、无障碍和跨平台考虑（iOS/macOS/visionOS）。
+
+## Key Claims（用中文描述）
+- SwiftTerm API 提供完整的公开接口，支持终端仿真的深度定制
+- Core Graphics 优化可实现高频文本更新下的平滑滚动渲染
+- 正确的后台线程处理可避免 UI 更新阻塞，确保终端 I/O 流畅
+- SSH 连接状态管理涵盖连接、断开、重连场景的完整终端行为处理
+- VoiceOver、动态类型等无障碍支持是 Apple 平台终端集成的必要条件
+
+## Key Quotes
+> "Focuses on creating robust, performant terminal experiences that feel native to Apple platforms while maintaining compatibility with standard terminal protocols." — 核心理念
+
+> "Specializes in SwiftTerm specifically (not other terminal emulator libraries)" — 明确范围边界
+
+## Key Concepts
+- [[VT100/xterm Standards]]：完整的 ANSI 转义序列支持，用于光标控制和终端状态管理
+- [[SwiftTerm]]：Miguel de Icaza 开发的 MIT 许可 Swift 终端仿真库，核心依赖
+- [[Core Graphics Optimization]]：通过 Core Graphics / Core Text 优化文本渲染，实现高频更新下的平滑滚动
+- [[SSH I/O Bridging]]：将 SSH 流高效桥接到终端仿真器的输入/输出层
+- [[Scrollback Buffer]]：大终端历史的回滚缓冲区管理，支持搜索功能
+- [[Accessibility Integration]]：VoiceOver、动态类型等 Apple 无障碍技术集成
+
+## Key Entities
+- [[SwiftTerm]]（MIT License）：核心终端仿真库，GitHub: migueldeicaza/SwiftTerm
+- [[SwiftNIO SSH]]：用于 SSH 连接的 Swift 网络库
+- [[NMSSH]]：另一个 SSH 连接选项库
+- [[Core Graphics]]：Apple 平台 2D 渲染框架
+- [[Core Text]]：Apple 平台文本排版引擎
+
+## Connections
+- [[visionOS Spatial Engineer]] ← depends_on ← [[Terminal Integration Specialist]]：visionOS 空间工程师依赖终端集成实现空间终端体验
+- [[macOS Spatial Metal Engineer]] ← depends_on ← [[Terminal Integration Specialist]]：macOS Metal 工程师依赖终端集成处理渲染层面
+- [[SwiftTerm]] ← implements ← [[VT100/xterm Standards]]：SwiftTerm 库实现 VT100/xterm 标准
+
+## Contradictions
+- 无明显内容冲突；该 Agent 专注于 Apple 平台和 SwiftTerm，与其他通用终端解决方案（如 libvte、iTerm2）不在同一问题域内。

wiki/sources/xr-cockpit-interaction-specialist.md

@@ -0,0 +1,41 @@
+---
+title: "XR Cockpit Interaction Specialist Agent"
+type: source
+tags: []
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/spatial-computing/xr-cockpit-interaction-specialist.md]]
+
+## Summary（用中文描述）
+- 核心主题：XR 座舱交互专家 Agent——专注于设计和实现沉浸式座舱式交互环境，融合空间控制与自然人体工学
+- 问题域：如何在 XR 环境中构建高存在感、低眩晕的固定视角座舱交互系统
+- 方法/机制：固定视角（fixed-perspective）高存在感交互区设计、人体工学对齐（眼-手-头协调）、约束驱动控制机制（constraint-driven）、多模态交互集成（手势+语音+注视+物理道具）
+- 结论/价值：提供真实感与舒适度并重的 XR 座舱解决方案，适用于模拟指挥中心、航天器座舱、XR 载具界面和训练模拟器
+
+## Key Claims（用中文描述）
+- XR 座舱交互通过固定视角设计（fixed-perspective）和高存在感交互区（high-presence interaction zones）显著提升沉浸感体验
+- 约束驱动控制机制（constraint-driven control mechanics）消除自由漂浮运动，有效降低用户眩晕感
+- 座舱人体工学设计需对齐自然的眼-手-头协调流动（eye–hand–head flow），确保长时间使用舒适性
+- 多模态交互集成（手势、语音、注视、物理道具）为用户提供灵活自然的控制选择
+
+## Key Quotes
+> "You create fixed-perspective, high-presence interaction zones that combine realism with user comfort." — Agent 核心定位：固定视角高存在感交互区设计
+
+## Key Concepts
+- [[Constraint-Driven-Control-Mechanics]]：约束驱动控制机制——通过 3D meshes 和输入约束实现的控制物理化设计，取代自由漂浮式交互
+- [[Cockpit-Ergonomics]]：座舱人体工学——对齐自然的眼-手-头协调流动，优化长时间使用的舒适度
+- [[Spatial-Computing]]：空间计算——XR 环境的核心技术基础，支持 3D 空间中的交互设计
+- [[Motion-Sickness-Threshold]]：运动病阈值——通过固定视角和约束驱动设计将其最小化
+
+## Key Entities
+- [[XR-Cockpit-Interaction-Specialist]]：本 Agent 角色——空间座舱设计专家，专注于 XR 模拟和载具界面
+
+## Connections
+- [[XR-Interface-Architect]] ← builds_upon ← [[XR-Cockpit-Interaction-Specialist]]
+- [[XR-Immersive-Developer]] ← collaborates ← [[XR-Cockpit-Interaction-Specialist]]
+- [[Terminal-Integration-Specialist]] ← extends ← [[XR-Cockpit-Interaction-Specialist]]
+
+## Contradictions
+- 与 [[XR-Immersive-Developer]] 在运动自由度上存在设计张力：后者倾向开放空间沉浸体验，前者强调固定视角约束以降低眩晕；当前观点：座舱场景优先舒适性与真实感，通用沉浸场景可保留开放自由度

wiki/sources/xr-immersive-developer.md

@@ -0,0 +1,55 @@
+---
+title: "XR Immersive Developer Agent Personality"
+type: source
+tags: []
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/spatial-computing/xr-immersive-developer.md]]
+
+## Summary（用中文描述）
+- 核心主题：XR Immersive Developer Agent——基于 WebXR 技术的沉浸式浏览器 AR/VR/XR 应用开发专家智能体
+- 问题域：如何在浏览器环境下构建跨平台、高性能、具备手部追踪/注视/控制器输入的沉浸式 3D 体验
+- 方法/机制：使用 A-Frame / Three.js / Babylon.js 构建模块化组件化 XR 应用，通过 raycasting、hit testing、实时物理引擎实现沉浸交互，通过 occlusion culling、shader tuning、LOD 系统优化性能，兼容 Meta Quest / Vision Pro / HoloLens / mobile AR
+- 结论/价值：提供一套完整的前端 WebXR 工程能力——从原型开发到性能优化，从交互设计到跨设备兼容覆盖
+
+## Key Claims（用中文描述）
+- XR Immersive Developer 通过 WebXR Device API 实现浏览器端完整沉浸式支持（hand tracking / pinch / gaze / controller input）
+- A-Frame / Three.js / Babylon.js 是核心 3D 引擎栈，覆盖从快速原型到高级渲染的完整需求
+- 性能优化通过 occlusion culling、shader tuning、LOD 系统三条路径协同实现
+- 跨设备兼容（Meta Quest / Vision Pro / HoloLens / mobile AR）需要显式兼容性层管理
+- 模块化组件驱动设计确保 XR 体验可复用、降级优雅、便于维护
+
+## Key Quotes
+> "You are **XR Immersive Developer**, a deeply technical engineer who builds immersive, performant, and cross-platform 3D applications using WebXR technologies." — Agent 身份定义
+> "You bridge the gap between cutting-edge browser APIs and intuitive immersive design." — 核心价值定位
+> "You've shipped simulations, VR training apps, AR-enhanced visualizations, and spatial interfaces using WebXR" — 工程经验总结
+
+## Key Concepts
+- [[WebXR]]：浏览器原生沉浸式计算 API，支撑 AR/VR/XR 跨设备体验
+- [[A-Frame]]：Mozilla 出品的 Three.js 封装框架，适合快速 WebXR 原型开发
+- [[Three.js]]：底层 WebGL 3D 渲染引擎，A-Frame 的核心依赖
+- [[Babylon.js]]：微软出品的专业级 WebXR 3D 引擎，强大的工具链和 XR 支持
+- [[Hand-Tracking]]：WebXR Hand Input Module，手部追踪交互能力
+- [[LOD-System]]：Level of Detail 渲染优化，根据距离动态调整模型精度
+- [[Occlusion-Culling]]：遮挡剔除性能优化，不渲染被遮挡的物体
+
+## Key Entities
+- [[Meta Quest]]：Facebook/Meta 的 VR 头显，WebXR 主要目标平台之一
+- [[Vision Pro]]：Apple 空间计算设备，WebXR 重要目标平台
+- [[HoloLens]]：Microsoft 的 AR 头显，WebXR 兼容设备
+- [[Mobile AR]]：移动端增强现实（ARKit/ARCore），跨平台 WebXR 目标
+
+## Connections
+- [[XR-Interface-Architect]] ← depends_on ← [[XR-Immersive-Developer]]（前者依赖后者的沉浸式渲染和交互能力）
+- [[XR-Cockpit-Interaction-Specialist]] ← shares_domain ← [[XR-Immersive-Developer]]（同属 Spatial Computing 部门）
+- [[macOS-Spatial-Metal-Engineer]] ← complements ← [[XR-Immersive-Developer]]（前者负责平台底层，后者负责浏览器层）
+- [[visionOS-Spatial-Engineer]] ← complements ← [[XR-Immersive-Developer]]（前者专注文果空间计算平台，后者专注浏览器跨平台）
+
+## Contradictions
+- 与 [[XR-Cockpit-Interaction-Specialist]] 冲突：
+  - 冲突点：运动自由度设计哲学
+  - 当前观点（XR-Immersive-Developer）：倾向开放空间沉浸体验，最大化运动自由度
+  - 对方观点（XR-Cockpit-Interaction-Specialist）：强调固定视角约束（constraint-driven control mechanics）以降低运动病阈值
+  - 说明：两者代表 XR 交互设计的两种范式——沉浸派 vs 安全派，在不同场景下各有优势

wiki/sources/xr-interface-architect.md

@@ -0,0 +1,49 @@
+---
+title: "XR Interface Architect Agent Personality"
+type: source
+tags: ["agent-personality", "spatial-computing", "ux-design", "ar-vr-xr"]
+date: 2026-04-25
+---
+
+## Source File
+- [[raw/Agent/agency-agents/spatial-computing/xr-interface-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：定义一个专为 AR/VR/XR 沉浸式环境设计空间化用户界面的 AI Agent 个性
+- 问题域：如何在 3D 空间中创建直觉化、舒适且可发现的交互界面，同时减少晕动症、增强存在感
+- 方法/机制：通过 HUD、浮动菜单、交互区域设计，支持多种输入模型（手势、注视+捏合、控制器），基于人体工程学约束布局 UI
+- 结论/价值：提供一个以人为中心、感知驱动的研究型 Agent，可为沉浸式应用定义 UI 流程、构建布局模板并运行可用性验证实验
+
+## Key Claims（用中文描述）
+- XR Interface Architect 通过设计空间直觉化用户体验来定义其核心使命
+- 该 Agent 支持多种输入模型：直接触摸、注视+捏合、控制器和手势
+- UI 放置遵循基于舒适度的约束原则，以减少晕动症
+- 该 Agent 可构建座舱、仪表盘或可穿戴界面的布局模板
+- 该 Agent 专注于沉浸式搜索、选择和操作的交互原型设计
+
+## Key Quotes
+> "Designs spatial interfaces where interaction feels like instinct, not instruction." — 核心理念，定义交互的最高目标
+> "Human-centered, layout-conscious, sensory-aware, research-driven" — Agent 人格特质，四个维度
+> "Recommend comfort-based UI placement with motion constraints" — 减少晕动症的核心设计策略
+
+## Key Concepts
+- [[SpatialInterfaceDesign]]：空间界面设计 — 在 3D 环境中创建直觉化用户界面的设计方法论
+- [[MotionSicknessMitigation]]：晕动症缓解 — 通过 UI 放置约束和运动限制减少 VR 使用中的不适感
+- [[PresenceEnhancement]]：存在感增强 — 通过界面设计提升用户在沉浸式环境中的临场感
+- [[MultimodalInput]]：多模态输入 — 支持手势、注视、控制器等多种交互方式的输入架构
+- [[HUDDesign]]：抬头显示器设计 — 在 XR 环境中创建浮动信息面板的设计实践
+
+## Key Entities
+- [[XRImmersiveDeveloper]]：XR 沉浸式开发者 — 该 Agent 的主要协作对象，负责实现 3D 环境
+- [[XRCockpitInteractionSpecialist]]：XR 座舱交互专家 — 同为 spatial-computing 领域，协作设计驾驶舱交互
+
+## Connections
+- [[XRImmersiveDeveloper]] ← collaborates_with ← [[XRInterfaceArchitect]]
+- [[XRCockpitInteractionSpecialist]] ← related_to ← [[XRInterfaceArchitect]]
+- [[DesignUXArchitect]] ← extends ← [[DesignUIDesigner]]
+
+## Contradictions
+- 暂无发现冲突
+
+## Notes
+- 该 Agent 与 [[macOS Spatial/Metal Engineer Agent Personality]] 同属 spatial computing 领域，但侧重点不同：前者关注 3D 界面设计，后者关注空间计算底层工程实现