ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
weishen
2026-04-25 04:02:51 +08:00
parent ef8474f0d2
commit a26d62bb6d
55 changed files with 2535 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
wiki/overview.md
View File

@@ -49,6 +49,14 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
**[[multi-agent-system-reliability]]**（Alex Ewerlöf）：多智能体系统可靠性的架构模式理论——反对拟人化LLM，主张将LLM视为分布式系统中不可靠的组件。核心4模式：[[Hierarchy-Agent-Pattern]]（主管→工作→验证链）、[[Consensus-Voting-Pattern]]（N个LLM多数票消除幻觉）、[[Adversarial-Debate-Pattern]]（Generator→Critic→Judge对抗辩论）、[[Knock-out-Pattern]]（适者生存淘汰制）。核心洞察：不应要求模型"小心"，而应**强制**其正确——通过架构约束而非提示词约束。与 [[Designing for Agentic AI]] 互补（架构 vs 用户体验），与 [[Recursive Self-Optimization]] 共享自引用结构思想。与 [[Genetic-Algorithm]]（遗传算法）有关联——Knock-out/Tree of Thoughts 是 GA 的精简实现。
**[[xr-interface-architect]]**（XR Interface Architect）：XR 空间界面架构师 Agent——The Agency Spatial Computing 部门的 UX/UI 设计专家，专注于为 AR/VR/XR 沉浸式环境创建直觉化、舒适且可发现的界面。核心方法：HUD / 浮动菜单 / 交互区域设计，支持直接触摸、注视+捏合、控制器和手势四种输入模型；基于人体工程学约束进行 UI 放置，减少晕动症；构建座舱/仪表盘/可穿戴界面布局模板；运行可用性验证实验（舒适度和学习性）。人格特质：**Human-centered, layout-conscious, sensory-aware, research-driven**。与 [[xr-immersive-developer]] 和 [[xr-cockpit-interaction-specialist]] 同属 Spatial Computing 部门，三者共同构建完整的 XR 产品交互基础设施。
**[[xr-cockpit-interaction-specialist]]**（XR Cockpit Interaction Specialist）：XR 座舱交互专家 Agent——The Agency Spatial Computing 部门的沉浸式座舱式交互设计专家，专注于设计和实现固定视角、高存在感的座舱交互环境。核心设计原则：约束驱动控制机制（constraint-driven control mechanics）消除自由漂浮运动，通过 3D meshes 和输入约束将控制物理化；座舱人体工学对齐自然的眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用场景：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。核心工具：A-Frame / Three.js 原型开发。与 [[xr-interface-architect]] 存在层级关系（前者提供座舱交互基础能力，后者构建界面）；与 [[xr-immersive-developer]] 在运动自由度设计上存在张力——前者强调固定视角约束以降低眩晕，后者倾向开放空间沉浸体验。属 [[Spatial-Computing]] 概念在座舱场景的具体应用，为 The Agency 的 XR 产品矩阵提供交互基础设施。
**[[xr-immersive-developer]]**（XR Immersive Developer）：XR 沉浸式开发专家 Agent——The Agency Spatial Computing 部门的 WebXR 前端工程师，专注于在浏览器环境下构建跨平台高性能 AR/VR/XR 体验。核心栈：A-Frame / Three.js / Babylon.js；核心能力：WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller input）、raycasting / hit testing / 实时物理交互、LOD 系统 / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）、模块化组件驱动设计及优雅降级。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。核心工具：A-Frame / Three.js 原型开发。与 [[XR-Interface-Architect]]（界面架构）和 [[XR-Cockpit-Interaction-Specialist]]（座舱交互）同属 Spatial Computing 部门，共同构建 XR 产品矩阵。与 [[XR-Cockpit-Interaction-Specialist]] 在运动自由度设计上存在张力——后者强调固定视角约束以降低运动病，前者倾向开放空间沉浸体验。属 [[Spatial-Computing]] 概念在浏览器前端场景的具体实现。
**[[macos-spatial-metal-engineer]]**（macOS Spatial/Metal Engineer）：Apple 平台专用 Metal 渲染与空间计算 Agent——专注于 Swift + Metal 的高性能 3D 渲染系统和 visionOS 空间计算体验。核心能力：实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点图数据，目标 90fps 立体渲染；通过 RemoteImmersiveSpace 和 LayerRenderer（stereo 模式、RGBA16Float + Depth32Float）实现 macOS 到 Vision Pro 的帧流传输；Metal Compute Shader 执行 GPU 并行力导向图物理模拟（排斥力 + 吸引力 + 阻尼）；注视（Gaze）+ 捏合（Pinch）空间交互与 raycast hit testing。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。与 [[xr-immersive-developer]] 互补——前者专注浏览器端 WebXR，后者专注 Apple 原生 Metal 渲染管线；与 [[visionos-spatial-engineer]] 存在职责张力——后者倾向 visionOS 原生开发，前者侧重 macOS 渲染侧 + Vision Pro 流式输出，两者协同构成完整的 Apple 空间计算平台能力。属 [[Spatial-Computing]] 概念在 Apple 原生平台场景的具体实现。
### The Agency — Paid Media 部门
The Agency 的 Paid Media 部门专注于企业级付费媒体策略与运营，涵盖 Google Ads、Microsoft Advertising、Amazon Ads 三大核心平台。
@@ -645,26 +653,34 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
**[[sales-deal-strategist]]**（Deal Strategist Agent）：高级deal策略师与管线架构师，将严谨的资质方法论应用于复杂B2B销售周期——坚信每个deal都是战略问题而非关系练习，"如果资质缺口没有尽早识别，失败就已经锁定了，只是你还没发现"。核心能力：**MEDDPICC资质评估**（八维度评分，每维度5分，满分40；全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%）+ **竞争定位**（Winning/Battling/Losing三区分析 + 地雷问题布局）+ **Challenger商业教学法**（六步序列：Warmer → Reframe → Rational Drowning → Emotional Impact → A New Way → Your Solution）+ **交易检查方法论**（系统探测风险信号：单线程/无紧迫事件/Champion不开放EB通道/决策标准完美匹配竞争对手）。核心原则：预测准确率Commit deals关闭率85%+；Qualified Pipeline（28/40+）赢率35%+；永远不做单线程账户；每条资质缺口必须附带具体下一步、责任人、和截止日期。与 [[sales-discovery-coach]] 协同——后者提供买方情境输入（发现阶段），前者构建交易策略（评估+定位+计划）；与 [[sales-proposal-strategist]] 互补——Deal Strategist提供结构化deal分析和竞争定位，Proposal Strategist将其转化为说服性叙事，共同构成"发现→赢单策略→提案叙事"完整销售闭环。
**[[sales-pipeline-analyst]]**（Pipeline Analyst Agent）：Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent，将 CRM 数据转化为可执行的 Pipeline 洞察——坚信"每个 Pipeline 评估都应至少发现一个需要立即干预的 Deal"。核心框架：**Pipeline Velocity** =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，四个变量均为独立诊断杠杆；**质量调整覆盖度**（$5M 含 20 个陈旧 Deal 的 Pipeline 价值低于 $2M 含 8 个活跃 Deal 的 Pipeline）；**MEDDPICC Deal 健康评分**（资格深度 + 互动强度 + 进展速度三维度 0-36 分综合评分）；**多信号预测模型**（历史转化 + Velocity 加权 + 互动调整 + 季节性模式 + AI 模式匹配）。预测输出 Commit（>90%）/Best Case（>60%）/Upside（<60%）三档而非单一数字。关键原则：晚期阶段 MEDDPICC 字段<5/8 的 Deal 是预测失误的主要来源；单线程 + 无 EB 接触 + 20+ 天无会议 = 与上一季度 Closed-Lost 队列相同模式；30 天未更新的 Pipeline 应被标记审查；CRM 显示的 $12M Pipeline 调整后可能只有 $4.8M 有效。与 [[sales-deal-strategist]] 协同——后者关注单个 Deal 策略，前者提供全 Pipeline 层面的诊断和预测；与 [[sales-coach]] 共享 MEDDPICC 框架，但前者用于 Deal 质量评估，后者用于代表能力辅导。
**[[sales-engineer]]**（Sales Engineer Agent）：售前工程师 Agent，专注于在 B2B 技术评估中赢得技术决策——核心理念：技术决策先于商业合同，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能。核心能力：**Demo Engineering**（以影响力为导向的演示设计：先量化问题→展示结果→逆向讲解→证明收尾，以 [[AhaMoment]] 为核心成功标准）+ **POC Scoping**（严格限定的概念验证：成功标准明确写在开始前，2-3 周硬性时间线，中期检查点，防止范围蔓延）+ **FIA Framework**（Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性，永远不攻击竞品）+ **技术异议解码**（识别"是否支持 SSO？"背后的真实关切是"能否通过安全审查"，从根源回应而非表面处理）+ **评估笔记维护**（结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略）。成功指标：技术赢率 70%+，POC 转化率 80%+，演示到下一步行动率 90%+，中位数 18 天技术决策。与 [[sales-discovery-coach]] 在发现阶段技术深度参与度上存在张力——前者主张售前主导技术发现，后者主张销售发现以业务语言建立信任；与 [[sales-deal-strategist]] 共享竞争定位和 Winning/Battling/Losing 三区分析，但前者专注于技术评估层，后者覆盖全周期交易策略。属 The Agency Sales 团队完整销售闭环中的技术评估支柱。
## Conflict Areas
1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**（事件驱动看板替代方案）vs 传统 PM 工具。核心差异：手动拖拽 vs 自然语言输入；静态快照 vs 全历史保留；无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列，每次 progress/blocker/decision/pivot 均持久化，保留完整决策上下文。
2. **Kuaishou vs Douyin**: Kuaishou emphasizes authenticity and balanced algorithm; Douyin emphasizes polished content and central recommendation. Same country, opposite platform strategies.
2. **MEDDPICC 维度数量**：MEDDPICC 有 8 个维度（Metrics/Economic Buyer/Decision Criteria/Decision Process/Paper Process/Implicated Pain/Champion/Competition），但早期摄入的 [[sales-coach]] 描述为"六个维度"。已于本次摄入中修正为八维度，后续应避免再次引用旧的六维度描述。
3. **Micro-Enterprise vs Portage Salarial**: Micro-enterprise yields higher net income but lacks social protections; Portage Salarial costs more but includes unemployment insurance, pension, mutuelle. Financial trade-off vs social safety net.
3. **Kuaishou vs Douyin**: Kuaishou emphasizes authenticity and balanced algorithm; Douyin emphasizes polished content and central recommendation. Same country, opposite platform strategies.
4. **CI/CD Build Output**: SECURITY.md says build output is always closed; GitHub Actions best practice says certain generated files should be committed for reproducibility. Reproducibility vs cleanliness tension.
4. **Micro-Enterprise vs Portage Salarial**: Micro-enterprise yields higher net income but lacks social protections; Portage Salarial costs more but includes unemployment insurance, pension, mutuelle. Financial trade-off vs social safety net.
5. **路由器科学上网 vs VPS科学上网 vs NAS科学上网 vs Server终端代理**：四层方案各有适用场景。[[网件RAX50刷梅林固件与科学上网]] 路由网关方案（[[MerlinClash插件]]）→ 全屋透明代理，无需客户端配置；[[3X-UI Xray on BandwagonVPS]] VPS服务端方案（[[3X-UI]] + [[Xray]]）→ 集中式代理节点，可扩展；[[群晖NAS科学上网]] NAS 代理方案（V2RayA 透明代理）→ 覆盖 NAS 本身及容器；[[ubuntu-server科学上网]] Server 终端代理方案（[[ProxyChains]] + [[Git 全局代理]] + [[Docker Daemon Proxy]]）→ 仅覆盖该 Server 本身。最佳实践：路由器作为主网关（[[MerlinClash插件]]），VPS作为代理节点池（订阅机制），NAS 按需透明代理，Server 终端按工具单独配置。**额外洞察**：在群晖 DSM 7.x 和 Ubuntu Server 中，V2RayA/透明代理不一定对 Docker Daemon 生效，**显式配置 Docker Daemon Proxy 环境变量**（systemd drop-in 文件）比依赖透明代理更可靠。
5. **CI/CD Build Output**: SECURITY.md says build output is always closed; GitHub Actions best practice says certain generated files should be committed for reproducibility. Reproducibility vs cleanliness tension.
6. **Prometheus 监控 vs OpenTelemetry**：Prometheus 生态成熟、部署简单，适合家庭服务器和小型集群；OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），长期可考虑迁移路径但学习成本高。[[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] vs [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]。
6. **Sales Engineer vs Sales Discovery Coach（技术发现参与深度）**：Sales Engineer Agent 主张售前工程师应在技术发现阶段主导参与，结构化挖掘架构、集成、安全约束和真实技术决策标准；Sales Discovery Coach Agent 主张销售发现应以业务语言建立信任，深度技术探索由专门时机负责。协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式。详见 [[sales-engineer]] Contradictions 部分。
7. **Netdata vs Prometheus**：Netdata 开箱即用适合实时短期诊断（默认 19999 端口），Prometheus + Grafana 适合长期存储和趋势分析。两者可互补使用：Netdata 做快速排查，Prometheus 做 SLA 报表和历史分析。
7. **路由器科学上网 vs VPS科学上网 vs NAS科学上网 vs Server终端代理**：四层方案各有适用场景。[[网件RAX50刷梅林固件与科学上网]] 路由网关方案（[[MerlinClash插件]]）→ 全屋透明代理，无需客户端配置；[[3X-UI Xray on BandwagonVPS]] VPS服务端方案（[[3X-UI]] + [[Xray]]）→ 集中式代理节点，可扩展；[[群晖NAS科学上网]] NAS 代理方案（V2RayA 透明代理）→ 覆盖 NAS 本身及容器；[[ubuntu-server科学上网]] Server 终端代理方案（[[ProxyChains]] + [[Git 全局代理]] + [[Docker Daemon Proxy]]）→ 仅覆盖该 Server 本身。最佳实践：路由器作为主网关（[[MerlinClash插件]]），VPS作为代理节点池（订阅机制），NAS 按需透明代理，Server 终端按工具单独配置。**额外洞察**：在群晖 DSM 7.x 和 Ubuntu Server 中，V2RayA/透明代理不一定对 Docker Daemon 生效，**显式配置 Docker Daemon Proxy 环境变量**（systemd drop-in 文件）比依赖透明代理更可靠。
8. **macOS vs Linux 睡眠管理**：macOS 使用 `pmset` 命令配置电源管理（sleep/displaysleep/standby/hibernatemode），Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置。两者目标相同（防止服务器睡眠），但工具链完全不同，不可互换但互为参考。[[mac-mini-服务器配置-防止自动锁屏与睡眠]] vs [[ubuntu禁用合盖休眠]]。
8. **Prometheus 监控 vs OpenTelemetry**：Prometheus 生态成熟、部署简单，适合家庭服务器和小型集群；OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），长期可考虑迁移路径但学习成本高。[[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] vs [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]。
9. **数据库备份方案**：pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准（零停机、跨平台迁移能力强），但不能备份运行中数据库的物理文件目录；rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录，两者互补。
9. **Netdata vs Prometheus**：Netdata 开箱即用适合实时短期诊断（默认 19999 端口），Prometheus + Grafana 适合长期存储和趋势分析。两者可互补使用：Netdata 做快速排查，Prometheus 做 SLA 报表和历史分析。
10. **SuperCall 沙盒 Persona vs 通用语音 Agent**：[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line，无法访问外部系统；[[phone-based-personal-assistant]] 侧重通用个人助手场景，需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务（安全、无注入风险）；通用语音 Agent 适用于需要跨系统协调的复杂助手场景。
10. **macOS vs Linux 睡眠管理**：macOS 使用 `pmset` 命令配置电源管理（sleep/displaysleep/standby/hibernatemode），Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置。两者目标相同（防止服务器睡眠），但工具链完全不同，不可互换但互为参考。[[mac-mini-服务器配置-防止自动锁屏与睡眠]] vs [[ubuntu禁用合盖休眠]]。
11. **Agent 去电通知 vs Agent 来电接收**：[[phone-call-notifications]] 中 Agent 主动向用户拨打电话通知（Agent → User），通话由 Agent 触发，用户是被动接收方；[[phone-based-personal-assistant]] 中用户主动呼叫 Agent（User → Agent），Agent 接听并提供助理服务。两者方向相反但互补——前者用于紧急告警、定时简报、重要事件通知，后者用于随时咨询、查询、执行任务。共同构成完整语音双向通信能力。
11. **数据库备份方案**：pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准（零停机、跨平台迁移能力强），但不能备份运行中数据库的物理文件目录；rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录，两者互补。
12. **SuperCall 沙盒 Persona vs 通用语音 Agent**：[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line，无法访问外部系统；[[phone-based-personal-assistant]] 侧重通用个人助手场景，需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务（安全、无注入风险）；通用语音 Agent 适用于需要跨系统协调的复杂助手场景。
13. **Agent 去电通知 vs Agent 来电接收**：[[phone-call-notifications]] 中 Agent 主动向用户拨打电话通知（Agent → User），通话由 Agent 触发，用户是被动接收方；[[phone-based-personal-assistant]] 中用户主动呼叫 Agent（User → Agent），Agent 接听并提供助理服务。两者方向相反但互补——前者用于紧急告警、定时简报、重要事件通知，后者用于随时咨询、查询、执行任务。共同构成完整语音双向通信能力。