Update nexus wiki content

wiki/overview.md

@@ -4,8 +4,15 @@ This wiki is a living synthesis of curated sources spanning AI agents, cloud inf
 
 ## Major Themes
 
+**[[sre-weekly-issue-513]]**（SRE Weekly Issue #513）：SRE Weekly 第 513 期精选文章汇总，涵盖 8 篇 SRE 领域重要文章。核心主题：① [[Organizational-Second-Hit-Syndrome]]（[[Richard-Cook]] 和 [[John-Allspaw]] 在 [[Adaptive-Capacity-Labs]] 提出）——重大故障后的组织脆弱期，二次故障会引发强烈破坏性组织反应；② Netflix 在现代 CPU 上运行容器时面临 [[NUMA]] 和 2 万次挂载挑战，SRE 需关注全栈；③ [[Cost-As-Distributed-Systems-Bug]]——成本突增是可靠性问题的信号，成本异常应触发故障调查而非仅财务审查；④ [[Autoscaling]] vs [[Elasticity]]——Autoscaling 是被动的反应式机制，缺乏策略和测试会加剧故障；⑤ [[AI-For-On-Call]]（[[RunLLM]] 产品实践）——AI 最大价值在于为值班工程师提供上下文辅助，而非自主修复；⑥ [[Resilience]] 的 5 个不可自动化要素：学习、决策、优先级排序、沟通、适应。为 [[engineering-sre]] 和 [[engineering-incident-response-commander]] Agent 提供行业最新实践参考。
 ### Engineering Agents
 
+**[[engineering-devops-automator]]**（DevOps Automator Agent）：The Agency 工程部门的基础设施自动化与云运营专家 Agent——专注于消除手动运维流程、实现可扩展部署策略，核心理念：**"Automates infrastructure so your team ships faster and sleeps better."** 核心方法：基础设施即代码（Terraform/CloudFormation/CDK）→ CI/CD 流水线自动化（GitHub Actions/Jenkins/GitLab CI）→ 容器编排（Docker/Kubernetes）→ 零停机部署（蓝绿/金丝雀/滚动）→ Prometheus + Grafana 可观测性体系。关键成功指标：每日多次部署频率、MTTR < 30分钟、99.9% 可用性、100% 安全扫描通过率。与 [[engineering-backend-architect]] 互补——后端架构负责系统设计，DevOps Automator 负责将设计转化为可自动化运行的云基础设施；与 [[engineering-sre]] 互补——DevOps Automator 负责构建自动化基础设施，SRE 负责监控、错误预算决策和人工 on-call，两者协同构建完整生产系统可靠性体系。
+
+**[[engineering-sre]]**（SRE Agent）：The Agency 工程部门的网站可靠性工程师 Agent——将可靠性视为可量化预算的专业生产系统专家 Agent。核心理念：**"Reliability is a feature. Error budgets fund velocity — spend them wisely."** 核心使命：① SLOs 与错误预算——定义"可靠"标准，测量实际表现，通过错误预算驱动发布决策（SLO 达标则发布功能，耗尽则修复可靠性）；② 可观测性体系——Metrics（趋势/告警/SLO追踪）、Logs（事件调试）、Traces（跨服务请求链路）三支柱；③ Golden Signals 监控——Latency（延迟）、Traffic（流量）、Errors（错误）、Saturation（饱和度）四个最小必要监控信号；④ Toil 消除——将重复运维工作系统化自动化（重复两次则自动化）；⑤ 混沌工程——在用户发现前主动注入故障发现系统弱点；⑥ 容量规划——基于数据而非猜测的资源右限。关键规则：SLO 驱动决策、先测量再优化、自动化 Toil 不靠英雄、零责备故障文化（系统故障非个人错误）、渐进式发布（Canary → Percentage → Full，禁止大爆炸发布）。SRE Agent 的独特价值在于将工程纪律引入运维——每个 9（99.9% → 99.99%）的成本是前一个的 10 倍，错误预算是衡量可靠性投资的量化工具。与 [[engineering-devops-automator]] 互补而非矛盾——后者构建自动化基础设施，前者负责监控、SLO 决策和 on-call；与 [[engineering-incident-response-commander]] 互补——SRE 定义 SLO 和错误预算，事故指挥官负责在事故发生时执行结构化响应和复盘；与 [[CTP-Topic-41-NFRs-and-Error-Budgets]] 和 [[CTP-Topic-59-Achieving-Reliability-with-Amazon-EKS]] 共享错误预算与可靠性概念。
+
+**[[engineering-incident-response-commander]]**（Incident Response Commander Agent）：The Agency 工程部门的事故响应指挥官 Agent——将生产事故混乱转化为结构化解决的专业事故管理专家 Agent。核心理念：**"Preparation beats heroics."** 核心使命：① 结构化事故响应——SEV1–SEV4 分类框架（定义响应时间、升级路径、沟通节奏）、固定角色分工（IC/Communications Lead/Technical Lead/Scribe）、15 分钟时间盒假设验证；② 无责复盘文化——归因于系统缺陷而非个人错误，通过 5 Whys 和故障树分析找到系统性根因，48 小时内生成时间线+影响评估+行动项；③ SLO/SLI 体系——定义可测量可靠性指标，错误预算低于 25% 时暂停功能开发全力修复可靠性；④ On-Call 健康管理——至少 4 人轮换、每周不超过 5 次告警、SEV1 后强制休息，防止告警疲劳和工程师倦怠。关键规则：Runbook 每季度必须测试一次、On-call 工程师必须有应急处置权无需多级审批、复盘若无跟进只是会议。成功指标：MTTD < 5 分钟（SEV1/2）、MTTR < 30 分钟（SEV1）、100% SEV1/2 复盘完成率。与 [[engineering-sre]] 互补——SRE Agent 定义可靠性和 SLO 框架，事故指挥官负责在事故发生时驱动结构化响应和持续改进；与 [[CTP-Topic-41-NFRs-and-Error-Budgets]] 共享错误预算决策机制。
+
 **[[engineering-database-optimizer]]**（Database Optimizer Agent）：The Agency 工程部门的数据库性能优化专家 Agent——核心专长：PostgreSQL 优化和高级特性（EXPLAIN ANALYZE、查询计划解读）、B-tree/GiST/GIN/部分索引策略、Schema 设计（规范化 vs 反规范化权衡）、N+1 查询检测与解决、连接池管理（PgBouncer、Supabase pooler）、零停机迁移策略。支持 PostgreSQL、MySQL、Supabase 和 PlanetScale。关键规则：始终检查查询计划、外键必须加索引、避免 SELECT *、使用连接池、迁移必须可逆、生产环境永不锁表（使用 CONCURRENTLY）、防止 N+1 查询（使用 JOIN 替代循环）、监控慢查询（pg_stat_statements）。核心价值：提供可直接用于生产的 SQL 模板和 TypeScript 代码示例。与 [[engineering-backend-architect]] 存在依赖关系——后端架构师的设计决策需遵循数据库优化专家的原则。
 
 **[[engineering-senior-developer]]**（Senior Developer Agent）：The Agency 工程部门的高端 web 实现专家 Agent——专注于使用 Laravel/Livewire/FluxUI 实现"奢华感"（Premium）web 体验。核心理念：**"Every pixel should feel intentional and refined"**，性能与美感必须共存。核心要求：必须实现亮色/暗色/系统主题切换、大留白+精致排版、微交互动画（磁性按钮、流畅过渡）、玻璃拟态（glass morphism）视觉效果。技术栈：Laravel/Livewire 全栈框架、FluxUI 专业组件库、高级 CSS（glass morphism、organic shapes、cubic-bezier 缓动曲线）、Three.js WebGL 集成（粒子背景、3D 产品展示）。质量标准：加载 < 1.5s、动画 60fps、WCAG 2.1 AA 无障碍。关键规则：FluxUI 组件参考官方文档、Alpine.js 已随 Livewire 捆绑无需单独安装。与 [[engineering-rapid-prototyper]] 互补——原型优先速度，高级开发者优先品质。
@@ -14,6 +21,14 @@ This wiki is a living synthesis of curated sources spanning AI agents, cloud inf
 
 **[[engineering-cms-developer]]**（CMS Developer Agent）：The Agency 工程部门的 CMS 开发专家 Agent——专注于 Drupal 和 WordPress 网站开发，可交付从内容建模到上线审计的完整 CMS 开发生命周期。核心理念：**"A CMS isn't a constraint — it's a contract with your content editors."** 核心专长：WordPress 自定义主题/插件开发（Gutenberg Blocks、ACF Pro、子主题结构）、Drupal 自定义模块开发（Hook 系统、Block 插件、Twig 模板、Layout Builder）、内容建模与字段 API 设计。关键原则：ContentModel-first（先锁定字段/内容类型再写代码）、Code over configuration UI（所有内容类型/分类/字段通过代码注册）、Never fight the CMS（使用 hooks/filters/plugin 系统，绝不 monkey-patch 核心）。平台选择：Drupal 适合复杂内容模型/企业级/多语言；WordPress 适合编辑简单性/WooCommerce/广泛插件生态。
 
+**[[engineering-codebase-onboarding-engineer]]**（Codebase Onboarding Engineer）：The Agency 工程部门的代码库 onboarding 专家 Agent——专注于帮助新开发者快速理解陌生代码库，通过读取源码、追踪执行路径、仅陈述有代码依据的事实来构建准确的心智模型。核心理念：**"Code first, explain second. State only what you can prove."** 核心原则：证据优先（永远只陈述代码中可验证的事实）、分层解释（一句话 → 五分钟高层 → 深度代码流三层递进）、诚实告知检查边界（明确说明哪些部分已检查/未检查）、严格保持只读模式绝不修改文件。核心使命：① 快速构建准确的心智模型（目录结构、入口点、系统边界）；② 追踪真实执行路径（数据如何进入、转换、持久化、退出）；③ 加速开发者 onboarding（回答"从哪里开始"和"什么拥有这个行为"）。关键规则：绝不推断意图或质量、在部分理解时只说明检查了哪些文件、只做说明不做建议。与 [[engineering-senior-developer]] 和 [[engineering-git-workflow-master]] 互补——后两者分别提供代码实现和版本控制专业视角，Codebase Onboarding Engineer 则提供独立于具体技术的代码库结构理解能力。与 [[engineering-minimal-change-engineer]] 互补——后者专注交付最小变更，前者专注理解代码库结构，两者配合可实现"先理解再最小改动"的工作流。与 [[ThreeTierExplanation]] 和 [[ExecutionTracing]] 方法论深度绑定。
+
+**[[engineering-voice-ai-integration-engineer]]**（Voice AI Integration Engineer）：The Agency 工程部门的语音 AI 集成工程师 Agent——专注于设计并构建生产级语音转文字（STT）管道，涵盖从原始音频摄入到结构化输出的完整流程。核心理念：**"Turn raw audio into structured, production-ready text that machines and humans can actually use."** 核心管道：音频验证（ffprobe 探测格式/codec/采样率）→ 预处理（ffmpeg 重采样至 16kHz 单声道 + EBU R128 响度归一化）→ VAD 过滤（跳过静音）→ 分块（>30 分钟重叠感知分块）→ 转录（Faster-Whisper CTranslate2 优化版）→ 说话人分离（pyannote.audio）→ 归一化（标点/大小写/文本清理）→ PII 脱敏（命名管道阶段）→ 结构化输出（JSON/SRT/VTT）。架构选型：本地 Whisper（隐私敏感）vs 云端 ASR（AssemblyAI/Deepgram，高精度批量）。关键原则：永远探测不信任扩展名、永远保留时间戳、永远不静默删除低置信度片段、永远在管道中嵌入 PII 脱敏而非事后补丁。与 [[engineering-frontend-developer]] 在音频格式验证上存在张力（前端信任 MIME type，Voice AI 永远 ffprobe 探测）；与 [[EngineeringSRE]] 在生产日志记录上存在张力（Voice AI 严禁记录原始音频/未脱敏文本）。为 [[FasterWhisper]]/[[VoiceActivityDetection]]/[[SpeakerDiarization]]/[[EBUR128LoudnessNormalization]]/[[OverlapAwareChunking]]/[[PIIRedaction]]/[[StructuredTranscriptJSON]]/[[LLMHandoff]] 等 8 个核心概念定义了 Wiki 中的标准定义。
+
+
+**[[n8n-调用openclaw-agents的工作流架构]]**：n8n 工作流自动化平台如何通过 OpenAI 兼容 API 调用 OpenClaw Agent。核心机制：OpenClaw Gateway 提供 OpenAI Chat Completions 兼容端点（默认关闭，需在  中手动开启），n8n 通过 HTTP Request 节点调用，Agent ID 通过  字段指定（如 ）。与 Hermes Agent 的关键区别：默认端口不同（Hermes 8642 vs OpenClaw 18789）、Agent 指定方式不同。n8n 可同时连接两个 Agent——共用同一局域网 IP，仅端口不同，建两个 HTTP Request 节点即可实现统一自动化编排。
+**[[engineering-frontend-developer]]**（Frontend Developer Agent）：The Agency 工程部门的前端开发专家 Agent——专注于现代 Web 技术（React/Vue/Angular/Svelte）、UI 框架和性能优化，核心理念：**"Performance-first, accessibility always, pixel-perfect by default."** 核心能力：四阶段工作流（项目架构 → 组件开发 → 性能优化 → 测试 QA）；Core Web Vitals 优化（LCP < 2.5s、FID < 100ms、CLS < 0.1）；WCAG 2.1 AA 无障碍合规（ARIA 标签、语义化 HTML、键盘导航、屏幕阅读器兼容）；现代 CSS 技术（响应式设计、玻璃拟态、微交互动画）；PWA 构建（离线能力、Service Worker 缓存）；Code Splitting + Lazy Loading 优化_bundle size。关键成功指标：3G 网络下页面加载 < 3s、Lighthouse 性能与无障碍评分 > 90、组件复用率 > 80%、生产环境零控制台错误。与 [[engineering-senior-developer]] 互补——后者专注"奢华感"高级 Web 体验，前者专注性能与无障碍基础规范；与 [[design-ui-designer]] 在工作流 landing-page 中协同（UI Designer 设计 → Frontend Developer 实现）。属 The Agency Engineering 部门。
+
 **[[engineering-backend-architect]]**（Backend Architect Agent）：The Agency 工程部门的后端架构师 Agent——
 
 ### 知识与资源
@@ -32,6 +47,8 @@ This wiki is a living synthesis of curated sources spanning AI agents, cloud inf
 
 **[[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]**（大模型术语扫盲）：通俗解读大模型生态关键术语——LLM（≥1B参数的语言模型）、MCP（连接外部工具的标准化协议）、Agent（LLM+MCP实现自动化执行）、RAG（通过外部检索消除幻觉，正确率60%→90%）、Embedding（词向量语义距离）、vLLM（PagedAttention+连续批处理优化GPU显存）、Token（英文≈0.3/字、中文≈0.6/字的计量单位）、数据蒸馏（大模型生成精简数据训练小模型）。核心观点：大模型本身只给步骤方法不会真正执行工具调用，需配合MCP才能实现自动化；RAG通过"给提示"解决大模型在陌生领域的幻觉问题。属 [[Multi-Agent-AI-Systems]] 的基础概念层，与 [[llms-rag-ai-agent-三个到底什么区别]] 互补——后者从系统架构层面区分三者关系，本文档则提供术语的通俗定义与机制解释。
 
+**[[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]]**（LLM Wiki 实操指南）：Karpathy + 老张 的 LLM Wiki 落地教程——核心操作栈：Obsidian Web Clipper（网页文章一键转 Markdown）、Ctrl+Shift+D 快捷键批量图片本地化、Graph View 做 Lint 健康检查和发现幽灵节点（被多处引用但无专页的概念）、Git 插件自动 commit+push 版本管理、qmd 本地 Markdown 搜索引擎。核心洞察：**RAG 的根本问题是"没有积累"——每次提问 AI 都从零检索，什么都没沉淀；LLM Wiki 让 AI 增量维护交叉引用，一次操作改十五个文件，维护成本趋近于零**。思想精髓：**"你负责读和想，AI 负责整理和维护"**。属 [[LLM Wiki]] 的实操落地层——[[LLM Wiki]] 提供架构理念，本页提供 Obsidian 完整操作流程；与 [[Second Brain]] 互补——后者是更广泛的个人知识管理框架，本页聚焦 LLM Wiki 的具体实现。
+
 ### Multi-Agent AI Systems
 The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents) and **OpenClaw**. The Agency provides 147 specialized agents across 12 business divisions (Engineering, Design, Finance, Game Dev, Marketing, Paid Media, Product, Project Management, Testing, Support, Spatial Computing, Specialized). OpenClaw focuses on autonomous agents with persistent memory and workflow orchestration via n8n. A beginner-focused **n8n AI Agent 教程**（[[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]）：通过 N8N 平台构建 AI Agent 的入门指南——核心区分 Workflow（预定义自动化，输出恒定）与 Agent（由 LLM 驱动，动态选择工具）；系统讲解五类 N8N 节点（触发节点、动作节点、工具节点、代码节点、AI Agent 节点）；集成 Memory 模块保留对话上下文提升连贯性；演示 Airtable 库存管理工具集成案例。是 [[n8n-workflow-orchestration|OpenClaw+n8n 工作流编排]] 的入门前置知识。
 
@@ -45,22 +62,68 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
 
 **[[design-brand-guardian]]**（Brand Guardian）：The Agency Design 部门的品牌守护者专家 Agent——核心职责：创建内聚的品牌身份系统，确保品牌在所有触点的一致表达，并提供品牌保护策略。品牌 Foundation Framework（Purpose/Vision/Mission/Values/Personality）是所有品牌决策的基础；Visual Identity System（Logo/Color/Typography）必须作为内聚系统设计；Brand Voice and Messaging 定义品牌声音特征（Strategic/Consistent/Protective/Visionary）。默认要求包含品牌保护（商标/合规监控/危机管理）。与 [[design-ux-architect]] 时序协作——Brand Guardian 先定义品牌战略框架 → UX Architect 再构建技术实现系统；与 [[design-whimsy-injector]] 互补——Brand Guardian 定义的品牌个性是 Whimsy Injector 趣味性设计的输入。属 [[Multi-Agent-System-Reliability]] 的 Design 部门 Agent 设计层。
 
-**[[llms-rag-ai-agent-三个到底什么区别]]**（LLM/RAG/AI Agent 三者区别）：AI 应用入门基础知识——作者将 LLM 比作"天才大脑"（擅长思考但不知当前）、RAG 比作"随身图书馆助理"（动态获取外部知识，消除幻觉）、AI Agent 比作"循环控制系统"（感知→规划→执行→反思的自主行动能力）。核心观点：三者并非竞争技术，而是在三个不同层面互补协同——**LLM 用于思考，RAG 用于认知，Agent 用于执行**。生产系统应叠加三者：纯语言任务用 LLM、需准确性时加 RAG、需真正自主性时部署 Agent。属 [[Multi-Agent-AI-Systems]] 的基础概念层。
+**[[hospitality-guest-services]]**（Hospitality Guest Services Agent）：The Agency Specialized 部门的酒店及综合款待业宾客服务专家 Agent——覆盖酒店/度假村/餐厅/活动场地的全流程宾客体验：预订（booking/modification/cancellation）、预到沟通（48小时入住前个性化触达）、入住（30秒内问候 + 忠诚身份识别）、住店（礼宾服务、餐饮预订、活动安排）、投诉处理（**HEARD** 五步法：Hear/Empathize/Apologize/Resolve/Delight）、退房（账单审核 + 积分确认）、售后（24小时口碑请求 + 差评48小时响应）。核心方法论：**HEARD 投诉处理框架**（立即倾听→真诚共情→诚挚道歉→即时解决→超越补偿）、**分级服务恢复**（绿/黄/红/紧急四级补偿梯度）、**宾客隐私神圣不可侵犯**、**食物过敏零容忍**。核心理念：**"Every complaint is a gift"**（愿意投诉的宾客说明仍相信你能补救，不投诉直接离开则说明放弃）。
+
+**[[retail-customer-returns]]**（Retail Customer Returns Agent）：The Agency Specialized 部门的零售退货专员 Agent——处理退货、退款、换货的全流程客户服务 Agent，覆盖实体店、电商和全渠道零售环境。核心全渠道退货流程：退货授权 → 商品检查 → 退款处理 → 商品处置（退回库存/二手/供应商/RMA/报废）。10条关键行为规则：共情优先于政策执行/一致性政策防止歧视投诉/绝不指控客户欺诈/所有例外必须记录/退款优先退回原支付方式/未经检查不处理退货/退货欺诈每年造成数十亿损失/不得扣押客户商品/礼品退货特殊处理/健康安全品类严格限制。退货欺诈识别：Wardrobing（穿后退货）、收据欺诈、价格掉包、偷窃商品退货；发现可疑立即上报 Loss Prevention。退货原因代码体系：P类（产品缺陷/损坏/缺失配件/与描述不符）、C类（客户偏好/改主意/重复购买）、O类（运营错误）、F类（欺诈标记，仅内部使用）。客户挽留策略：在退款前主动推荐替代品、将退款转为无过期日期店内积分、提供替代方案而非直接拒绝。属 [[customer-service]] 的零售退货垂直专精扩展——两者均处理客户交互，后者专注文档中记录的场景。
+
+**[[legal-billing-time-tracking]]**（Legal Billing & Time Tracking Agent）：The Agency Specialized 部门的法律事务所计费与时间追踪专家 Agent——覆盖时间捕获（0.1小时增量、实时录入）、账单叙事撰写（诚实具体可防御）、开票生成（发票审核清单三段式）、催收管理（五阶段通信序列：发票→友好提醒→逾期→最终通知→律师升级）、信托账户合规（IOLTA、月度三向对账：银行对账单=客户台账=信托日记账）、计费分析（实现率≥90%、实收率≥95%、90天以上AR<5%）。**10条关键行为规则**：时间实时捕获/禁止计费非billable时间/信托账户神圣/叙事诚实具体/永不超过实际时间/遵守客户计费指南/核销需律师批准/催收沟通专业/应急费协议必须书面/争议立即升级。核心理念：**"计费不是行政职能，而是事务所的财务引擎"**——以$300/小时计算，每位律师每天因时间捕获习惯不佳平均损失$600-$900，年均$180,000-$270,000。属 [[legal-client-intake]] 的下游——intake 完成案件信息收集后，计费 Agent 接手财务引擎管理；与 [[accounts-payable-agent]] 形成事务所现金流的收/支双侧；与 [[support-legal-compliance-checker]] 共同构成法律合规体系（计费合规/信托账户合规）。
+
+**[[legal-client-intake]]**（Legal Client Intake Agent）：The Agency Specialized 部门的法律客户接待与资格审查专家 Agent——AI 驱动的律所潜在客户 intake 全流程自动化，覆盖初始接触（温暖问候+紧迫性筛查）、业务领域资格审查（人身伤害/家庭法/刑事/商业/房地产/遗产/雇佣）、利益冲突筛查（对方当事人全名 + 事先代表查询）、案件信息收集（六阶段问卷）、咨询安排和 attorney-ready 摘要交付。**10 条关键行为规则**：不提供法律建议、时效期限识别（人身伤害 2-3 年/EEOC 180-300 天）、冲突筛查先于安排咨询、同理心优先、不承诺结果、保密从第一次接触开始、资格审查先于时间投入、紧迫信号立即升级、无歧视对待、每次接触以明确下一步结束。属 [[Support-Responder]] 的法律行业版本——两者都是 first contact 接待专家，但后者面向通用客户支持，前者专精法律执业合规与 malpractice 风控。
+
+**[[legal-document-review]]**（Legal Document Review Agent）：The Agency Specialized 部门的专业法律文档审查 Agent——为律师提供第一轮文件审查，覆盖合同（MSA/NDA/雇佣/供应/合伙/许可）、诉讼文书（诉状/动议/开示/和解/命令）、房地产文件（买卖/租赁/贷款/产权）、合规审查和版本比对全场景。核心方法：**五步工作流**（文档接收与分类 → 结构分析 → 实质审查 → 风险评估与标记 → 交付物准备），结合高风险条款库（七类：赔偿/责任限制/终止/IP/自动续期/竞业限制/适用法律）、分级风险评分（高/中/低）和标准化交付模板。**10 条关键行为规则**：不提供法律意见（始终标记为"供律师审查"）、先识别上下文（文件类型/当事人/代理客户/管辖权）、全面标记（误报秒级消除，漏报代价数百万）、不省略经济重大条款、尊重管辖权差异、标记缺失条款而非沉默、保密绝对、版本比对穷尽化、以明确行动建议结尾。属 [[legal-client-intake]] 的下游依赖——intake 收集案件信息后，文档审查负责核心文件的风险识别；与 [[LegalBillingTimeTracking]] 共享法律事务所上下文（文档审查完成后记录工时和计费叙事）。
+
+**[[real-estate-buyer-seller]]**（Real Estate Buyer & Seller Agent）：The Agency Specialized 部门的房地产交易代理专家 Agent——专注于住宅和投资物业全流程交易支持，覆盖买方代表（需求评估→物业搜索→要约策略→谈判）、卖方代表（挂牌准备→定价策略→营销→展示管理）和交易协调（合同管理→房屋检查→融资跟踪→交割支持）。核心方法：**五步工作流**（咨询→搜索/挂牌→要约谈判→交易管理→交割）结合 **十大关键规则**（独家代表客户利益/书面协议强制/公平住房合规/重大缺陷必披露/截止日期不可错过/定金条款严格遵守/不从事法律实践/持续更新市场状况/响应速度2小时基准/推荐增长为成功指标）。**三大核心交付物**：Comparative Market Analysis（CMA 市场比较分析）、Buyer Needs Assessment（买方需求评估表）和 Transaction Coordination Timeline（交易协调时间线）。与 [[legal-document-review]] 共享房地产交易法律上下文——两者均涉及房地产交易文档，但前者专注买卖代理，后者专注法律文件审查；与 [[hospitality-guest-services]] 共享"卓越客户体验"核心理念——两者均以响应速度、沟通能力和专业服务为成功基石；与 [[SalesOutreach]] 在"个性化深度 vs 规模化"上存在策略差异（房地产高价值低频次适合深度个性化 vs B2B 外勤规模化触达）。
+
+**[[loan-officer-assistant]]**（Loan Officer Assistant Agent）：The Agency Specialized 部门的抵押贷款专员 AI Agent——面向抵押贷款、消费信贷和商业贷款全生命周期，支持贷款专员管理借款人沟通、文件收集、管道进度、合规截止日期和交割协调。核心方法：**五步工作流**（借款人接待→申请与披露→处理与文件收集→承销管理→交割协调）结合 **十大关键规则**（TRID 时间线/DTI 比率/公平贷款合规/文件有效期管理/资质决策权/州级执照要求等）。**核心交付物**：借款人接待脚本（5 分钟首次响应）、预审分析表（DTI/LTV/CLTV 计算）、文件清单（按贷款类型）、TRID 合规时间表、贷款状态更新模板（7种场景）、承销条件跟踪表。**关键合规要求**：LE 必须在申请后 3 个工作日内交付、CD 必须在成交前至少 3 个工作日交付；错过任一截止日期均为联邦监管违规。与 [[real-estate-buyer-seller]] 在交易融资节点存在协调关系——贷款合规截止日期具有法律强制性，Agent 必须主动追踪而非被动等待对方协调；与 [[legal-document-review]] 共享抵押贷款法律文件上下文——后者提供法律审查，Loan Officer Agent 负责贷款文件全生命周期管理；与 [[SalesOutreach]] 在"销售漏斗转化"上形成上游关系——Outreach 触达潜在借款人，Loan Officer Agent 接手完成预审和申请。
+
+**[[finance-fpa-analyst]]**（FP&A Analyst Agent）：The Agency Finance 部门的高增长 SaaS 财务规划与分析专家 Agent——人格化身份为"Riley"，11+ 年经验，专注于将战略计划转化为具体财务框架，驱动问责制和明智的资源分配。核心理念：**"FP&A is not accounting's sequel — it's strategy's translator"**。核心交付物：**年度经营计划（AOP）**——自上而下目标与自下而上构建的差距协调、董事会演示；**滚动预测**——至少每季度重新预测，结合业务所有者输入；**月度业务回顾（MBR）**——执行仪表板、收入/费用差异分析、前瞻性预测更新；**场景规划**——base/upside/downside，含明确假设和触发点。关键规则：每个预算必须有负责人（"预算无人认领=无人遵循"）、差异分析必须解释未来而非仅解释过去、场景规划是重大决策的必备条件。高级技术能力：零基预算（ZBB）、作业成本法（ABC）、蒙特卡洛概率预测、单位经济分析（CAC/LTV/回本周期）。属 [[finance-investment-researcher]] 和 [[finance-financial-analyst]] 的下游——投资研究提供市场洞察，财务分析提供历史报告，FP&A 负责前瞻性规划和决策支持；与 [[accounts-payable-agent]] 形成财务规划与财务执行的双向财务闭环；与 [[Support-Finance-Tracker]]（财务追踪）形成规划→执行→追踪的财务全周期。
+
+**[[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]**（Harness Engineering：LLM Agent 的 7 层工程脚手架）：Lychee Technology 的 engineering blog 提出**Harness Engineering**概念——LLM 本身不是 Agent，Agent = LLM + 代码脚手架（状态管理 + 恢复工作流）。核心演进路径：**Prompt Engineering**（如何问）→ **Context Engineering**（如何知道，RAG）→ **Harness Engineering**（如何约束和运行）——后者吸收前两者并增加执行控制层。**4大设计原则**：约束而非指令（Schema 验证器 > 提示词保证）、状态外部化（context window 易失，磁盘文件持久）、每步可验证（规则/工具/LLM-as-judge 三层异构验证）、局部失败而非全局崩溃（单步重试不重启管道）。**7层 Harness Stack**：① Cognition（受限操作边界，role file/job description）→ ② Tools（工具输出排序/去重/token预算截断）→ ③ Contracts & Interfaces（JSON Schema 边界验证，防 Schema Drift）→ ④ Orchestration（DAG/状态机约束允许动作）→ ⑤ Memory & State（Working Memory + Persistent State 分层）→ ⑥ Evaluation & Observation（异构验证层）→ ⑦ Constraints & Recovery（幂等重试，Context Reset 机制）。**4个高级陷阱**：Context Anxiety（70% token 时模型仓促行为，解决方案：Context Reset）、Self-Grading Illusion（LLM 无法可靠评估自身，解决方案：Sprint Contract 分离 Generator/Evaluator）、优化"看起来正确"而非"真正正确"（解决方案：客观反馈而非情绪化错误消息）、Memory Consolidation（32K 噪声日志压缩至 7K）。**最小可行 Harness**（Day 1 可构建）：state.json + retry wrapper + schema validator + tool output truncation。属 [[Multi-Agent-System-Reliability]] 的 Agent 可靠性工程基础层，与 [[llms-rag-ai-agent-三个到底什么区别]] 互补——后者从概念层面区分 LLM/Agent/RAG，本文从工程层面提供 Agent 可靠运行的系统性解决方案；与 [[engineering-ai-engineer]] 共享 AI 系统生产化思维；与 [[designing-for-agentic-ai]]（Designing for Agentic AI）互补——前者侧重工程实现，后者侧重设计原则。
+
+**[[llms-rag-ai-agent-三个到底什么区别]]**（LLM/RAG/AI Agent 三者区别）：
 
 **[[multi-agent-team]]**（Multi-Agent Specialized Team — Solo Founder Setup）：Solo Founder 通过多 Agent 专业化团队实现"一人公司"运作的实战方案——4个专业 Agent（Milo 战略lead / Josh 商业分析 / Marketing 内容营销 / Dev 开发）+ 共享记忆 + Telegram 单入口 + 定时任务自动推送。核心洞察：**Agent 个性化**使"和团队对话"比"使用工具"更自然（Milo 自信有魅力、Josh 务实数据驱动）；**共享记忆 + 私有上下文**组合是核心——共同 ground（目标/决策）+ 各积累领域专长；按任务复杂度匹配模型（Claude Opus 做战略、Gemini 做长文本研究、Codex 做实现）；定时主动推送洞察而非被动响应形成价值飞轮。建议从小团队开始（lead + 1 specialist），按瓶颈逐步扩展。属 [[Multi-Agent-System-Reliability]] 的团队协作实践层，与 [[ContentFactory]]（内容创作流水线）和 [[Agents-Orchestrator]]（流水线编排）同属多 Agent 协作模式的不同维度，可结合使用。
 **[[AI Citation Strategist]]**（AI Citation Strategist Agent）：专注于 AI 推荐引擎优化（AEO/GEO）的营销 Agent——审计品牌在 ChatGPT、Claude、Gemini、Perplexity 四大 AI 平台上的引用可见性，识别竞争对手被引用的原因，生成 Fix Pack 改善内容信号。与 [[Marketing SEO Specialist]] 互补但独立——传统 SEO 成功不能自动转化为 AI 可见性，AEO 与 SEO 必须作为不同策略对待。核心差异化：**AI 引用 ≠ SEO 排名**，引用的信号（实体清晰度、结构化权威、FAQ 对齐、Schema 标记）完全不同。**平台差异化**：ChatGPT 偏好权威性+结构化页面（FAQ/对比表/how-to指南），Claude 偏好细腻平衡+明确溯源的分析内容，Gemini 依赖 Google 生态信号+实时搜索集成，Perplexity 偏好来源多样性+时效性+直接答案。**提示词模式工程**：围绕用户实际输入 AI 的查询模式设计内容——"Best X for Y"（对比内容）、"X vs Y"（专页对比+Schema）、"How to choose X"（买家指南+决策框架）、"What is the difference between X and Y"（清晰定义）。核心方法：Discovery（20-40 提示词生成）→ Audit（四平台查询记录引用率）→ Analysis（竞品内容结构映射）→ Fix Pack（按影响力优先级排序）→ Recheck（14天复测）。属 [[Multi-Agent-System-Reliability]] 的营销 Agent 设计层，与 [[Marketing Agentic Search Optimizer]] 同属 AI 驱动的内容可见性优化方向。
 
 **[[nexus-spatial-discovery]]**（Nexus Spatial Discovery Exercise）：8个 The Agency 专业 Agent 并行协作完成 AI 空间指挥中心产品完整规划的实战案例——10分钟 wall-clock time 产出完整规划。参与 Agent：产品趋势研究员（市场验证 + Vision Pro 现实核查）、后端架构师（8服务 Rust 架构）、品牌守护者（定义 [[SpatialAIOps]] 新品类）、增长黑客（3阶段 GTM + 增长飞轮）、支持应答者（AI 内嵌空间的差异化支持设计）、UX 研究员（识别调试为杀手级用例）、XR 界面架构师（命令剧院 + 7态节点系统）、项目牧羊人（35周时间线 + 5团队分配）。跨 Agent 独立共识：2D先行（WebXR分发） > VisionOS、品牌 > 调试 > 战情室协作 > 渐进披露。核心张力：Growth Hacker（$29-59）与 Trend Researcher（$99-249）定价分歧待 A/B 测试。属 [[Multi-Agent-System-Reliability]] 的多 Agent 协作规划层实践，展示了并行 Agent 发现可产出连贯、相互引用的完整计划。与 [[Multi-Agent-Team]]（单团队多 Agent 架构）和 [[Agents-Orchestrator]]（流水线编排）同属多 Agent 协作模式的不同维度。
 
+**[[executive-brief]]**（NEXUS Executive Brief）：The Agency 多 Agent 编排框架 NEXUS 的战略概览文档——从商业价值层面论证多 Agent 协调统一的必要性与量化收益。**核心问题**：缺乏协调时 Agent 在交接边界 73% 失败率，且无证据要求的质量评估导致"幻想型审批"（Agent 给无证明的基础实现评 A+）。**核心发现**（4条）：① 标准化交接模板和上下文连续性是最高杠杆干预；② Reality Checker 默认"NEEDS WORK"姿态防止过早生产部署；③ 4 条并行轨道同时执行压缩 40-60% 时间线，是主要上市加速器；④ Dev↔QA 循环可在集成前捕获 95% 缺陷，硬化时间减少 50%。**三大部署模式**：NEXUS-Full（12-24周，All agents）、NEXUS-Sprint（2-6周，15-25 agents）、NEXUS-Micro（1-5天，5-10 agents）。**三大交付物类别**：Master Strategy（800+行操作 doctrine）、Phase Playbooks（7份阶段手册）、Handoff Templates（7份交接模板）。**战略建议**：Critical = 立即采用 NEXUS-Sprint；High = 实现 Dev↔QA 循环；High = 所有 P0/P1 事故使用 Incident Response Runbook；Medium = 每季度 NEXUS-Full 战略复审。属 [[Multi-Agent-System-Reliability]] 的战略层，与 [[quickstart]]（操作层 Quick-Start Guide）和 [[nexus-strategy]]（完整 doctrine）共同构成 NEXUS 框架的三层文档体系，与 [[nexus-spatial-discovery]]（并行 Agent 协作执行案例）相互印证并行工作流价值。
+
+**[[quickstart]]**（NEXUS Quick-Start Guide）：The Agency 多 Agent 编排框架 NEXUS 的快速启动指南——核心价值：**5 分钟内从零启动完整的多 Agent 流水线**。三种启动模式覆盖全场景：NEXUS-Full（完整产品，12-24周，6阶段全流程）→ NEXUS-Sprint（功能/MVP，2-6周，跳过市场发现）→ NEXUS-Micro（单一任务，1-5天，精准激活特定 Agent）。核心原则：Quality Gates（每阶段质量门控，无证据不推进）、Dev↔QA Loop（构建→测试循环，PASS推进/FAIL重试，最多3次）、Handoffs（结构化上下文传递，避免冷启动）、Reality Checker（最终质量权威，默认"NEEDS WORK"）、Evidence Over Claims（截图/测试结果/数据 > 口头断言）。[[agents-orchestrator]] 是管道的核心控制器。与 [[nexus-strategy]]（完整 doctrine）、[[executive-brief]]（战略层）、[[handoff-templates]]（交接模板）共同构成 NEXUS 三大战略交付物体系。
+
+**[[handoff-templates]]**（NEXUS Handoff Templates）：NEXUS 框架的标准化交接模板体系——7 种场景化 Markdown 模板覆盖多 Agent 协作全链路交接：**Standard Handoff**（通用任务分配，含 metadata/context/deliverable/quality-expectations 四段结构）、**QA PASS/FAIL**（Dev↔QA 循环结果反馈，含证据清单和多分辨率截图要求）、**Escalation Report**（3 次重试耗尽后的升级报告，含失败历史/根因分析/决策建议）、**Phase Gate Handoff**（阶段门控交接，含门控标准结果表和风险携带记录）、**Sprint Handoff**（冲刺边界交接，含完成状态/质量指标/待办项/回顾洞察）、**Incident Handoff**（事故响应交接，含 P0-P3 分类和状态追踪）。Usage Guide 表格将每种场景映射到对应模板，确保 Agent 始终使用正确格式。与 [[workflow-with-memory]] 的 MCP 持久记忆机制互补——handoff-templates 定义"交接什么"，memory 系统定义"如何持久化"。属 [[Multi-Agent-System-Reliability]] 的交接机制层。
+
+**[[scenario-marketing-campaign]]**（Multi-Channel Marketing Campaign Runbook）：NEXUS 多渠道营销活动完整 Agent 协作执行手册——Mode: NEXUS-Micro to NEXUS-Sprint | Duration: 2-4 weeks | Agents: 10-15。15 个专业 Agent 角色分三类：**Campaign Core**（Social Media Strategist 活动总负责 + Content Creator 全格式内容生产 + Growth Hacker 获客漏斗 + Brand Guardian 品牌一致性 + Analytics Reporter 数据分析）、**Platform Specialists**（Twitter Engager + TikTok Strategist + Instagram Curator + Reddit Community Builder + App Store Optimizer 各平台专项运营）、**Support**（Trend Researcher + Experiment Tracker + Executive Summary Generator + Legal Compliance Checker 支持团队）。四周执行计划：**Week 1** 策略制定与内容生产（Day 1-2 策略规划含 KPI/受众/预算/内容日历；Day 3-5 多格式内容创作含博客/邮件/落地页/视频脚本/社媒文案）；**Week 2** 发布与激活（含 Launch Day 全渠道同步启动 + Day 4-5 数据驱动优化）；**Week 3-4** 持续优化（每日仪表盘监控 + 每周复盘 + 活动结束 ROI 分析）。核心指标体系：总量指标（总触达/互动率>3%/CTR>2%/CVR>5%/CPA/品牌情感） + 平台专属 KPI（Twitter 触达+互动率、TikTok 完播率+粉丝增长、Reddit  upvotes+评论质量等）。品牌一致性检查点：发布前审查（Brand Guardian）+ 每周视觉一致性审计 + 合规审查。属 [[Multi-Agent-System-Reliability]] 的营销活动执行层，与 [[workflow-landing-page]]（单日冲刺）互补——本 runbook 是 2-4 周多渠道营销的全景模板，后者是单渠道单任务的快速实现。
+
+**[[scenario-incident-response]]**（Incident Response Runbook）：NEXUS 框架生产事故结构化响应手册——定义 P0~P3 四级严重等级分类（P0=服务全停/数据丢失/安全漏洞，即时响应；P1=主要功能故障/性能严重下降，<1小时；P2=次要功能故障/有 workaround，<4小时；P3=表面问题，下个 sprint），按等级激活 3-8 个 Agent 并行响应。五阶段标准流程：检测分诊→并行调查→缓解决策树→解决验证→48小时内复盘。提供标准化沟通模板和五类升级矩阵。属 [[Multi-Agent-System-Reliability]] 的事故响应层。
+
+**[[scenario-enterprise-feature]]**（Enterprise Feature Development Runbook）：企业级产品大型功能开发的多 Agent 编排完整手册——Mode: NEXUS-Sprint | Duration: 6-12 weeks | Agents: 20-30。五阶段流水线：**Phase 1** 需求与架构（Week 1-2，利益相关者对齐+合规扫描+技术架构评审）→ **Phase 2** 基础构建（Week 3，CI/CD 流水线+组件脚手架+数据库迁移）→ **Phase 3** 开发（Week 4-9，Dev↔QA 循环，双周汇报，3 个 Sprint）→ **Phase 4** 硬化（Week 10-11，全量截图+API 回归+10 倍流量压测，Reality Checker 默认 NEEDS WORK）→ **Phase 5** 发布（Week 12，灰度发布 5%→25%→100%+实时监控）。核心价值：量化质量门（代码覆盖率>80%、API P95<200ms、零关键漏洞、品牌一致性≥95%、WCAG 2.1 AA）+结构化风险矩阵（5 类风险+缓解策略）+分层利益相关者沟通节奏（执行层每日/产品周报/主管双周 SCQA 简报≤500词/合规财务月度报告）。属 [[Multi-Agent-System-Reliability]] 的企业级功能开发层，与 [[scenario-marketing-campaign]]（多渠道营销）互补——两者均采用 NEXUS-Sprint 框架，营销场景侧重内容传播，本 runbook 侧重企业合规开发；与 [[scenario-incident-response]]（应急响应）形成首尾衔接——企业功能发布上线后由应急响应机制保驾护航。
+
+**[[scenario-startup-mvp]]**（Startup MVP Build Runbook）：初创公司 MVP 4-6 周快速构建的多 Agent 编排执行手册——Mode: NEXUS-Sprint | Duration: 4-6 weeks | Agents: 18-22。分周执行：**Week 1** 快速发现+架构（竞品扫描+线框图+RICE 评分 backlog+CI/CD 初始化）→ **Week 2-3** 核心构建（Dev↔QA 循环双 Sprint，Growth Team 第 3 周激活）→ **Week 4** 抛光硬化（全量截图+负载测试+Reality Checker 最终质量门）→ **Week 5-6** 发布+增长（Growth Hacker 激活获客渠道+实时监控+早期用户反馈）。关键决策点：Day 2 概念 Go/No-Go、Day 4 架构审批、Week 4 Day 5 生产就绪判定。核心价值：强调 Sprint Prioritizer 执行 MoSCoW 防止范围蔓延（"Won't" means won't）、Evidence Collector 每个任务必须运行（no exceptions）、Rapid Prototyper 先验证后扩展的心态。与 [[scenario-enterprise-feature]]（企业级功能，6-12 周）和 [[scenario-marketing-campaign]]（多渠道营销，2-4 周）共同构成 NEXUS-Sprint 三档时长模板。
+
+**[[phase-0-discovery]]**（Phase 0 Playbook — Intelligence & Discovery）：NEXUS 多 Agent 团队 Phase 0（Intelligence & Discovery 阶段）完整执行手册——3-7 天，6 个 Agent 并行激活，在投入资源前全面验证机会。核心原则：**"在问题、市场和监管环境被充分理解之前，不进行任何建设"**。采用 Wave 1 + Wave 2 双波并行结构：Wave 1（外部探索）包含 Trend Researcher（市场情报，TAM/SAM/SOM、竞争格局、趋势预测，3天）、Feedback Synthesizer（用户需求，多渠道反馈收集、RICE 评分痛点、流失指标，3天）、UX Researcher（用户体验，5-10用户访谈计划、3-5 Persona、用户旅程地图，5天）；Wave 2（内部评估）包含 Analytics Reporter（数据审计，数据源盘点、信号识别、质量评分，2天）、Legal Compliance Checker（法律合规，GDPR/CCPA/HIPANA 框架映射、风险评级，3天）、Tool Evaluator（技术评估，Build vs. Buy、开源 vs. 商业评估，2天）。Day 5-7 为汇聚点（Convergence Point），6 份报告交由 Executive Summary Generator 合成不超过 500 词的 SCQA 格式执行摘要，并给出 **GO/NO-GO/PIVOT** 三段式决策。6 项质量门标准：市场机会验证、TAM 阈值、≥3 个有数据支撑的用户痛点、无阻断性合规问题、关键指标与数据源确认、技术栈可行性。Phase 0 完成标准：Executive Summary Generator 交付 GO 决策且附全部 6 个 Agent 的支撑证据。属 [[Multi-Agent-System-Reliability]] 的 Phase Playbook 体系层，是 [[phase-1-strategy]] 的前置阶段——Phase 0 验证通过后才进入 Phase 1 战略与架构。
+
+**[[phase-1-strategy]]**（Phase 1 Playbook — Strategy & Architecture）：NEXUS 多 Agent 团队 Phase 1（战略与架构阶段）完整执行手册——5-10 天，8 个 Agent 并行协作，定义项目启动前所有前期准备工作。核心理念：**"写代码之前，先定义做什么、如何组织、何为成功"**。三步 Agent 激活序列：① **战略框架**（Day 1-3，并行）— Studio Producer 战略组合对齐（3天）+ Brand Guardian 品牌标识系统（3天）+ Finance Tracker 财务规划（2天）；② **技术架构**（Day 3-7，并行，需①输出就绪）— UX Architect 前端设计系统（4天）+ Backend Architect 后端系统架构（4天）+ AI Engineer ML 架构（条件激活，3天）+ Senior Project Manager 规范转任务（3天）；③ **优先级排序**（Day 7-10，顺序，需②输出）— Sprint Prioritizer RICE 评分 + MoSCoW 分类（2天）。质量门：7 项检查清单，**必须 Studio Producer（战略）+ Reality Checker（技术）双签**方可进入 Phase 2。Phase 1→Phase 2 Handoff Package 包含 8 份交付物（战略计划/品牌系统/财务计划/CSS 设计系统/系统架构规范/ML 设计/任务列表/Sprint 计划）。属 [[Multi-Agent-System-Reliability]] 的 Phase Playbook 体系层，与 [[phase-2-foundation]] 前后衔接（Phase 1 定义架构 → Phase 2 搭建脚手架），与 [[nexus-strategy]] 共同构成 NEXUS 框架的阶段执行层。
+
+**[[phase-2-foundation]]**（Phase 2 Playbook — Foundation & Scaffolding）：NEXUS 框架 Phase 2 执行手册——6 Agent 双工作流并行构建技术基础设施与应用框架，3-5 天完成骨架站立。**Workstream A（基础设施）**：DevOps Automator（CI/CD 流水线+IaC，3 天）+ Infrastructure Maintainer（云资源+监控栈，3 天）+ Studio Operations（Git 工作流+协作工具，2 天）并行；**Workstream B（应用框架）**：Frontend Developer（React/Vue+组件库，3 天）+ Backend Architect（数据库+API 脚手架，4 天）+ UX Architect（CSS 设计令牌+主题系统，2 天）并行。质量门：DevOps Automator + Evidence Collector 联合双签，8 项截图证据验证（CI 日志/桌面端/移动端/主题切换/API 健康检查/数据库/监控面板/组件库），通过后方可进入 [[phase-3-build]]。属 [[Multi-Agent-System-Reliability]] 的基础设施构建层，与 [[scenario-enterprise-feature]] 中的 Phase 2 阶段（Week 3，CI/CD+脚手架+数据库迁移）相互印证——前者是 Phase Playbook 本身，后者是 NEXUS-Sprint 场景中的具体应用。
+
+**[[phase-3-build]]**（Phase 3 Playbook — Build & Iterate）：NEXUS 多 Agent 协作下功能迭代构建的完整流程手册——2-12 周（视范围而定），15-30+ Agent，通过 [[Agents-Orchestrator]] 驱动 Dev↔QA 循环完成所有功能实现。核心机制：任务按 RICE 评分排序分配 → Developer Agent 实现 → Evidence Collector 多维度测试（截图+功能+品牌）→ 通过则完成，失败则修复，最多 3 次，超过则升级。Agent Assignment Matrix 覆盖 14 类任务（React UI/REST API/数据库/移动端/ML/CI-CD 等），Specialist 专家按需激活（UI Designer/Brand Guardian/Whimsy Injector 等）。四条并行构建轨道：Track A 核心产品（Dev↔QA 循环，2 周 Sprint）、Track B 增长营销（Growth Hacker+Content Creator+Social Media Strategist）、Track C 质量运营（Evidence Collector+API Tester+Performance Benchmarker 持续验证）、Track D 品牌体验（UI Designer+Brand Guardian+Visual Storyteller 持续抛光）。Sprint 执行模板：Sprint Planning → Daily Execution（含状态报告）→ Sprint Review → Retrospective。质量门：7 项检查清单（100% 任务 QA 通过/API 端点验证/P95<200ms/品牌一致性≥95%/零 P0/P1 bug/验收标准满足/代码审查完成），Gate Keeper（Agents Orchestrator）裁决 PASS→Phase 4 / CONTINUE→继续 Phase 3 / ESCALATE→Studio Producer 介入。属 [[Multi-Agent-System-Reliability]] 的开发执行层，与 [[phase-2-foundation]]（Phase 2 基础就绪是 Phase 3 前置条件）和 [[phase-4-hardening]]（Phase 3 Dev↔QA 循环的产出进入 Phase 4 最终硬化）前后衔接，共同构成 NEXUS 框架最核心的价值交付阶段。
+
+**[[phase-4-hardening]]**（Phase 4 Playbook — Quality & Hardening）：NEXUS 多 Agent 团队 Phase 4（质量硬化与最终验收阶段）完整执行手册——3-7 天，8 个 Agent 协同，通过 Reality Checker 的唯一权威最终裁定实现生产就绪性验证。核心理念：**Reality Checker 默认裁定 NEEDS WORK，首次通过率极低，2-3 轮迭代属于正常预期**。三步 Agent 激活序列：① **证据收集**（Day 1-2，4 个 Agent 并行）— Evidence Collector（全维度截图套件：桌面/平板/手机×亮色/暗色/主题检测）× API Tester（全部端点回归+集成+边界情况）× Performance Benchmarker（10 倍流量负载测试+Core Web Vitals P95<200ms/LCP<2.5s/CLS<0.1）× Legal Compliance Checker（隐私合规+OWASP Top10+GDPR/CCPA+WCAG 2.1 AA）；② **分析聚合**（Day 3-4，3 个 Agent 并行）— Test Results Analyzer（聚合质量仪表板+问题优先级划分）/ Workflow Optimizer（Dev↔QA 循环效率分析）/ Infrastructure Maintainer（生产环境验证+灾难恢复）；③ **最终裁定**（Day 5-7，顺序）— Reality Checker 执行端到端用户路径验证+跨设备一致性检查+规格对照审查，裁决选项：READY（极少首次通过）/ NEEDS WORK（预期结果，返回 Phase 3 修复循环）/ NOT READY（架构级问题，返回 Phase 1/2）。7 项质量门标准：用户路径完整、跨设备一致性、P95<200ms & LCP<2.5s、零关键漏洞、所有监管要求满足、规格 100% 合规、生产环境验证通过。属 [[Multi-Agent-System-Reliability]] 的质量保障层，与 [[phase-3-build]]（开发迭代）前后衔接（Phase 3 Dev↔QA 循环 → Phase 4 最终硬化），与 [[phase-5-launch]]（发布就绪）共同构成 NEXUS 的最终验收闭环。
+
+**[[phase-5-launch]]**（Phase 5 Playbook — Launch & Growth）：NEXUS 多 Agent 团队 Phase 5（发布与增长运营阶段）完整执行手册——2-4 周（T-7~T+14），12 个 Agent 协同，实现最大市场影响力。核心理念：**全渠道同步激活，最大化发布冲击力，工程侧确保零宕机**。四阶段递进节奏：① **T-7 预热周**（Content Creator × Social Media Strategist × Growth Hacker × App Store Optimizer 并行准备内容/营销资源 × DevOps Automator × Infrastructure Maintainer × Project Shepherd 并行准备部署/监控/清单）；② **T-1 发布前夕**（三维度完整检查清单：Technical × Content × Marketing × Support）；③ **T-0 发布日**（Hour 0 蓝绿部署 → Hour 1-2 全渠道营销激活：Twitter/Reddit/Instagram/TikTok → Hour 2-8 监控与响应）；④ **T+1~T+14**（每日三波段运营节奏 T+1~T+7 → Growth Hacker + Experiment Tracker + Analytics Reporter 优化周 T+7~T+14）。7 项质量门：零宕机部署、48h 无 P0/P1、监控就绪、用户获取渠道激活、反馈循环运转、干系人通报、支持团队就绪。质量门由 [[StudioProducer]]（战略）+ [[AnalyticsReporter]]（数据）双签，决策：STABLE → Phase 6 / CRITICAL → 热修复循环 / ROLLBACK → 返回 Phase 4。属 [[Multi-Agent-System-Reliability]] 的发布执行层，以 [[phase-4-hardening]] READY 裁决为前提，向 [[Phase6Operate]]（STABLE 裁决）移交运营。
+
+**[[Phase6Operate]]**（Phase 6 Playbook — Operate & Evolve）：NEXUS 多 Agent 团队 Phase 6（持续运营与演进阶段）完整执行手册——无结束日期，12+ Agent 轮换协调，只要产品在市场就持续运行。核心机制：**分层运营节拍**（Continuous / Daily / Weekly / Bi-Weekly / Monthly / Quarterly）将 Agent 职责与活动频率对齐，由 [[Studio Producer]] 统筹治理。**持续改进闭环**（Measure → Analyze → Plan → Build → Validate → Deploy）每季度驱动流程效率提升 20%。**P0–P3 四级应急响应协议**覆盖从即时响应（P0 服务全停）到纳入 Sprint 处理（P3 表面问题）的全场景事故管理。**月度增长运营**整合渠道分析、A/B 实验、留存曲线和增长路线图；**季度战略评审**从市场定位、产品策略、增长策略和组织健康四个维度评估产品演进方向。新功能通过 **NEXUS Sprint**（压缩的 7 步循环：Backlog→实现→验证→部署→监控→测量→反馈）实现持续交付。属 [[Multi-Agent-System-Reliability]] 的运营保障层，以 [[phase-4-hardening]] 通过质量门为前提，与 [[scenario-incident-response]] 共享 P0–P3 事故分级体系（细节粒度需对齐）。
+
 **[[examples-readme]]**（The Agency Examples 索引）：The Agency 多 Agent 协作案例的索引与贡献指南——展示了当全体 Agent 协作时实际上是什么样子的。Nexus Spatial Discovery 是首个也是最完整的示例：8 个专业 Agent 并行运行，产出连贯、相互引用的完整计划，无须人工协调开销。贡献标准：多个 Agent 协作同一目标、展示 Agency 能力广度、具有现实适用性。是 [[Multi-Agent-Collaboration]] 概念的实践验证入口。
 
 **[[workflow-landing-page]]**：多 Agent 一天冲刺工作流——展示 Landing Page 场景下 4 个核心设计模式：**[[Parallel-Kickoff]]**（Content Creator + UI Designer 上午并行启动）、**[[Merge-Point]]**（Frontend Developer 等待两者完成）、**[[Feedback-Loop]]**（Growth Hacker 审查后 Frontend Developer 修改）、**[[Time-Boxing]]**（每个阶段严格时间盒：09:00→16:30）。与 [[workflow-startup-mvp]] 互补——后者以周为单位的长周期迭代，本工作流是单日冲刺的具体化实现。与 [[design-ui-designer]] 和 [[design-brand-guardian]] 共享 UI Designer 角色。
 
 **[[workflow-book-chapter]]**（Book Chapter Development Workflow）：单 Agent 工作流——[[BookCoAuthor]] Agent 将粗糙的原始素材（录音、碎片笔记、战略要点）转化为结构化的第一人称章节草稿。核心理念：**不是泛化 ghostwriting，而是保持作者声音 + 强化分类定位 + 暴露开放编辑决策**。五部分输出结构：Target Outcome（目标与战略定位）→ Chapter Draft（版本化章节草稿）→ Editorial Notes（假设与证据缺口的编辑注释）→ Feedback Loop（内部反馈循环）→ Next Step（明确修订问题而非模糊交接）。质量标准：草稿保持第一人称声音、claim 必须依附来源或标记为假设、删除泛化激励语言、以明确修订问题结尾。与 [[workflow-startup-mvp]]（多 Agent 长周期迭代）互补——前者聚焦单 Agent 聚焦式内容创作，后者是多 Agent 系统级协作；与 [[marketing-book-co-author]] 共享 Book Co-Author Agent，但本工作流是通用场景示例，后者是营销场景专用。属 [[TheAgency]] examples 层，与 [[agents-orchestrator]] 共同展示单 Agent 到多 Agent 的能力谱系。
 
-**GitHub Copilot Integration**（[[github-copilot]]）：The Agency 与 GitHub Copilot 的开箱即用集成——无需转换，Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 原生兼容。通过 `./scripts/install.sh --tool copilot` 一键安装，或手动复制到 `~/.github/agents/` 或 `~/.copilot/agents/` 目录。用户可在任意 Copilot 会话中通过名称激活特定 agent，如 `"Activate Frontend Developer and help me build a React component."`。与 [[readme|Cursor Integration]] 互补——后者项目级别生效，Copilot Integration 用户级别全局生效，共同构成 [[The Agency]] 的多 IDE 集成生态。
+**GitHub Copilot Integration**（[[GitHub-Copilot]]）：The Agency 与 GitHub Copilot 的开箱即用集成——无需转换，Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 原生兼容。通过 `./scripts/install.sh --tool copilot` 一键安装，或手动复制到 `~/.github/agents/` 或 `~/.copilot/agents/` 目录。用户可在任意 Copilot 会话中通过名称激活特定 agent，如 `"Activate Frontend Developer and help me build a React component."`。与 [[readme|Cursor Integration]] 互补——后者项目级别生效，Copilot Integration 用户级别全局生效，共同构成 [[The Agency]] 的多 IDE 集成生态。
 
-**Windsurf Integration**（[[windsurf-integration]]）：The Agency Agent roster 与 Windsurf 编辑器的集成方案——通过 `.windsurfrules` 文件将全部 Agent roster 聚合为单一规则文件，install.sh 脚本从项目根目录安装，项目级生效。Windsurf 中在 prompt 里按名称引用 Agent 即可激活（如 "Use the Frontend Developer agent to build this component."）。与 [[Cursor Integration]]（.mdc 规则）和 [[Aider Integration]]（CONVENTIONS.md）同为项目级 IDE 集成，机制相似，共同构成 The Agency 的多 IDE 覆盖体系。[[integrations-readme]] 已覆盖所有 11 种集成工具的概览。
+**Chinese Localization**（[[i18n-readme]]）：The Agency 的 Copilot Agent 中文本地化工具——通过 `scripts/i18n/localize-agents-zh.ps1` PowerShell 脚本将已安装的 Agent 的 YAML frontmatter `name` 和 `description` 字段替换为简体中文，提升中文用户在使用 Copilot Chat Agent 选择器时的体验。JSON 文件 `agent-names-zh.json` 作为翻译的唯一数据源（130+ 条目），脚本纯 ASCII 编码避免 PowerShell 编码问题，每次运行 `install.sh --tool copilot` 后需重新执行本地化。属 [[The Agency]] 多工具生态中的用户体验增强工具，与 [[readme|Qwen Code Integration]] 同属 Agency Agents 的集成功能，共同支持多语言/多工具环境。
 
 **Aider Integration**（[[aider-readme]]）：The Agency Agent roster 与 Aider 编辑器的集成方案——通过 `install.sh --tool aider` 安装，将全部 Agent roster 汇总到单一 `CONVENTIONS.md` 文件，Aider 会自动读取项目根目录的该文件。在 Aider 会话中按名称引用 Agent 即可激活（如 "Use the Frontend Developer agent to refactor this component."），或通过 `aider --read CONVENTIONS.md` 手动指定。`convert.sh --tool aider` 可重新生成最新的 CONVENTIONS.md。与 [[Windsurf Integration]]（.windsurfrules）、[[Cursor Integration]]（.mdc 规则）同为项目级 IDE 集成，共同构成 The Agency 的多编辑器支持生态。
 
@@ -74,7 +137,11 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
 
 **[[supply-chain-strategist]]**（Supply Chain Strategist Agent）：The Agency Specialized 部门的供应链管理专家 Agent——专注于中国制造业生态的端到端供应链优化。核心能力覆盖：供应商开发与分级管理（ABC 分类 + QCD 绩效考核）、战略采购（Kraljic 矩阵分类 + TCO 全成本分析）、质量管理（IQC/IPQC/OQC + AQL 抽样检验）、库存优化（EOQ + 安全库存 + 再订货点模型）、物流仓储（国内快递/零担/整车 + WMS 系统）、供应链数字化（ERP/SRM 系统选型 + 数字化成熟度评估 L1-L5）、成本控制（短期商业谈判到长期战略整合）和风险管理（多源采购 + 国产替代）。强调数据驱动决策（TCO 而非单价）+ 供应链安全优先（关键物料不得单一来源）。属 The Agency Specialized 部门的垂直领域专家 Agent，与工程类和营销类 Agent 共同构成完整的企业运营支持体系。
 
-**OpenCode Integration**（[[readme|OpenCode Integration]]）：The Agency Agent roster 与 OpenCode 编辑器的子 Agent 集成方案——通过 `./scripts/install.sh --tool opencode` 安装，将 The Agency 的 .md 文件格式 Agent 转换为 OpenCode 的 `.opencode/agents/` 目录格式。核心机制：在 YAML frontmatter 中添加 `mode: subagent` 使 Agent 仅在 `@agent-name` 触发时出现，不会在 Tab 循环列表中占位；颜色通过命名颜色到十六进制的自动映射实现。支持两种安装范围：项目级（`.opencode/agents/`）和全局级（`~/.config/opencode/agents/`）。与 [[readme|Cursor Integration]]（.mdc 规则）、[[github-copilot]]（用户级 Copilot）、[[windsurf-integration]]（.windsurfrules）同属 The Agency 的多 IDE 集成生态，[[integrations-readme]] 已覆盖所有集成工具概览。
+**[[hr-onboarding]]**（HR Onboarding Agent）：The Agency Specialized 部门的企业级新员工入职管理专家 Agent——覆盖从预入职准备到第一年结束的完整员工入职生命周期。核心理念：**"入职不是行政文书工作，而是员工职业故事的第一章"**。核心方法：五阶段工作流（预入职→入职第一天→第一周整合→30-60-90天里程碑→转入稳态）+ 十项关键行为规则 + 量化成功指标体系（I-9完成率100%/福利登记率≥95%/90天留存率≥95%）。与 [[recruitment-specialist]] 互补——招聘流程完成后进入入职流程，招聘专员负责提供入职日期和角色详情；与 [[support-legal-compliance-checker]] 共享合规框架——入职合规培训（文书+培训）依赖法律合规专家定义的多司法管辖区合规标准；与 [[compliance-auditor]] 存在视角差异（入职合规为底线硬性要求 vs 合规文化为长期深化过程，两者互补）。属 The Agency Specialized 部门的垂直领域专家 Agent，与招聘专员和法律合规专家共同构成完整的人力资源运营支撑体系。
+
+**[[specialized-chief-of-staff]]**（Chief of Staff）：The Agency Specialized 部门的高管主协调者专家 Agent——为创始人/高管提供全方位运营协调，充当主心骨与整个组织之间的"主协调者"。核心理念：**"我不在任何职能部门，但我拥有所有职能部门之间的空间"**；**"CoS 负责运转，高管负责领导，我让高管有空间做只有他能做的事"**。核心方法论：①**三层信息过滤器**——立即上报（影响公司目标/组织/避免偷袭）/ 处理后简报（小型修复）/ 暂存待问（优化建议），阈值随信任积累动态调整；②**文档依赖图维护**——当决策 X 变化时，主动识别所有受影响文档并级联更新，不遗漏任何一份；③**流程一致性保障**——格式、标准、SOP 必须 100% 执行，CoS 是最后一道防线防止忙碌工作冒充进步；④**影响力定位**——交付物不仅要创建，更要放在正确位置、在正确时机面向正确受众，位置错误等同于交付物不存在；⑤**ADHD 感知支持**——一次只呈现一件事，使用强视觉锚点，提供"离线标签"，温和引导偏离话题；⑥**多 Agent 编排**——维护任何单个 Agent 都不持有的全局上下文，防止矛盾输出和交接遗漏。与 [[project-manager-senior]] 互补但职责不同——项目经理专注特定交付物，CoS 专注组织整体运转和缝隙填补；与 [[support-infrastructure-maintainer]] 在流程维护上有协作关系。属 The Agency Specialized 部门的战略运营专家 Agent，与 NEXUS 框架中的 [[executive-brief]] 和 [[quickstart]] 共同构成战略→执行→协调的完整高层支撑体系。成功指标：高管零偷袭 / 零决策延迟（<48小时）/ 流程合规 100% / 文档同步 100%。
+
+**[[specialized-korean-business-navigator]]**（Korean Business Navigator）：韩国商业文化导航专家——The Agency Specialized 部门的韩国市场进入 Agent，专帮助外国专业人员解码韩国商业隐性规则，将西方直接性与韩国关系动态相结合。核心理念：**韩国"yes"不一定是同意，沉默是信息，成交发生在会议室外的走廊**。核心洞察：품의（共识审批）流程耗时 6-16 周（SME 6-10、中型 8-12、财阀 12-16），远长于西方的 2-4 周，永远不要在第一次会议要求决策时间线；永远不要绕过联系人越级上报；KakaoTalk 群聊必须使用韩语；永远不要在第一次对话中谈钱（关系→能力→价格三阶段）；회식（商务聚餐）出席是预期而非可选。关键方法：六阶段 품의时间线（소개→미팅→내부검토→품의서→결재→계약）、Nunchi 解码表（"검토해보겠습니다"实际意为"婉拒"）、分阶段 KakaoTalk 消息模板、韩国企业职级体系（회장→대리十级）、Proof Project 策略（有边界小项目降低感知风险）。属 The Agency Specialized 部门的垂直领域专家 Agent，与供应链、销售、市场营销 Agent 共同构成跨境业务运营支撑体系。
 
 **MCP Memory Integration**（[[mcp-memory-integration]]）：The Agency 的 MCP Memory 集成方案——通过在 Agent 提示词中加入标准化的 Memory Integration 段落，为任意 Agent 赋予跨会话持久记忆能力，无需修改 Agent 代码。MCP Memory Server 提供四个核心工具：`remember`（存储决策/交付物快照）、`recall`（跨会话检索）、`rollback`（失败时回滚到上一个检查点）、`search`（跨 Agent 搜索记忆）。**Rollback 是杀手级功能**——当 QA 检查失败或架构决策出错时，直接恢复到已知良好状态而非从头重建。标签一致性是关键：每个记忆使用 Agent 名称和项目名称作为标签，确保 recall 可靠。与 [[specialized-mcp-builder]]（构建 MCP Server）和 [[ai-memory-tools-two-camps]]（AI 记忆工具全景分类）同属 The Agency MCP 生态的核心组成部分。
 
@@ -100,6 +167,8 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
 
 **[[engineering-threat-detection-engineer]]**（Threat Detection Engineer）：威胁检测工程师 Agent——专注于构建检测层，在攻击者绕过预防控制后捕获威胁，核心理念：**"An undetected breach costs 10x more than a detected one, and a noisy SIEM is worse than no SIEM at all."** 核心能力：Sigma 规则开发（厂商无关）并编译为 Splunk SPL / Sentinel KQL / Elastic EQL / Chronicle YARA-L；MITRE ATT&CK 覆盖度映射与差距评估；威胁狩猎（基于情报、异常分析主动搜寻检测遗漏的威胁）；告警调优（通过允许列表、阈值调优和上下文富化降低误报）；Detection-as-Code CI/CD 流水线（Git + CI + 自动部署）。核心原则：检测质量 > 检测数量；行为检测优于 IOC 匹配（IP/哈希可日频轮换）；规则即代码——版本控制、peer review、测试、CI/CD 部署，绝不在 SIEM 控制台直接编辑；每个规则映射到至少一个 ATT&CK 技术；覆盖完整杀伤链（初始访问→横向移动→持久化→数据外泄）。关键量化指标：平均误报率 <15%、MTTD <48小时（关键 ATT&CK 技术情报→部署检测规则）、100% 规则通过 CI/CD 部署。与 [[engineering-backend-architect]] 在安全运营方面互补——Backend Architect 构建安全基础设施，Threat Detection Engineer 在其上构建检测层；属 The Agency Engineering 部门。
 
+**[[engineering-security-engineer]]**（Security Engineer）：应用安全工程师 Agent——专注于威胁建模、漏洞评估、安全代码审查、安全架构设计和事件响应的全链路应用安全专家，核心理念：**"You think like an attacker to defend like an engineer."** 核心原则：所有用户输入均为敌对输入（必须多边界验证清理）；默认拒绝（白名单优于黑名单）；安全失效（错误不泄露堆栈/路径/schema）；最小权限（IAM/DB/API/文件权限层层收紧）；不自定义加密（使用 libsodium/OpenSSL/Web Crypto API）；密钥神圣（禁止硬编码/日志/客户端代码/未加密环境变量）。核心安全体系：SDLC 全阶段安全集成（设计→实现→测试→部署→运营）；STRIDE 威胁建模（Spoofing/Tampering/Repudiation/Info Disclosure/DoS/Elevation of Privilege）；零信任架构（最小权限+微隔离）；防御深度（WAF→限流→输入验证→参数化查询→输出编码→CSP）；CI/CD 安全门禁（SAST/DAST/SCA/secrets 检测）；SBOM 与供应链安全监控。与 [[engineering-threat-detection-engineer]] 互补——Security Engineer 负责预防层（构建安全架构+代码门禁），Threat Detection Engineer 负责检测层（攻击后捕获）；与 [[engineering-backend-architect]] 共享"安全优先"原则，但 Security Engineer 专注于安全专业视角而非系统架构整体。属 The Agency Engineering 部门。
+
 **[[workflow-with-memory]]**（Multi-Agent Workflow: Startup MVP with Persistent Memory）：[[workflow-startup-mvp]] 的增强版——通过 MCP Memory Server 将手动复制粘贴交接升级为自动召回，实现"记忆服务器作为粘合剂"。核心机制：`remember` 存储 Agent 交付物（带项目名 + 接收方标签）、`recall` 自动召回上下文（无需人工粘贴）、`rollback` 回滚到上一个检查点（替代手动撤销）。Before/After 对比：手动交接（会话超时丢失 / 多 Agent 需重复编译上下文 / QA 失败需手动描述问题 / 跨多天项目需重建上下文）→ Memory 模式（跨会话持久 / 按标签共享 / 自动回滚 / 每次 pick up 继续）。核心标签策略：所有记忆用项目名标签（如 retroboard），交付物额外用接收 Agent 标签（如 frontend-developer），这是 recall 正常工作的前提。Rollback 是 QA 失败恢复的核心：回滚到检查点而非手动追踪变化。与 [[workflow-startup-mvp]] 的关系：两者不冲突，Memory 模式是原始工作流的增强层——Memory Server 可用时自动召回；不可用时沿用原始工作流的手动粘贴策略。
 
 **[[multi-channel-assistant]]**：基于 [[OpenClaw]] 的多渠道个人助理方案——以 Telegram Topic 路由为统一入口，整合 Google Workspace（gog）、Slack、Todoist、Asana，实现"说一句话完成全套工作"。核心价值：消除应用切换疲劳，AI 主动推送定时提醒（如每周垃圾清理、公司周报）。
@@ -219,6 +288,10 @@ The Agency 的 Support 部门涵盖数据分析、基础设施维护、法律合
 
 **[[support-executive-summary-generator]]**（Executive Summary Generator）：咨询级执行摘要生成 Agent——The Agency Support 部门的战略沟通专家，融合麦肯锡 SCQA、BCG 金字塔原理、贝恩行动导向三大顶级咨询框架，将复杂冗长的商业输入转化为 325-475 词的高管级执行摘要，确保 C-suite 决策者在 3 分钟内把握本质、评估影响、做出决策。核心理念：**洞察优先于信息，行动优先于描述**——每个关键发现必须包含量化数据点（≥1 个），不允许超越提供数据的假设，明确标记数据缺口。核心方法：四步流水线（Intake 分析 → SCQA/Pyramid 结构开发 → 执行摘要生成 → QA 验证）；输出格式严格遵循五段式结构（Situation Overview / Key Findings / Business Impact / Recommendations / Next Steps）；建议按业务影响排序（Critical / High / Medium），每条包含负责人+时间线+预期结果；高级能力包括统计验证的数据驱动洞察、行业基准对比分析、情景分析（最佳/最差/最可能）和价值 vs. 努力矩阵。成功指标：摘要阅读时间 <3 分钟、100% 发现含量化数据、325-475 词合规率 100%。与 [[support-analytics-reporter]] 协同——后者提供原始数据洞察，前者将其转化为高管可执行决策；与 [[support-legal-compliance-checker]] 协同——合规 Checker 的风险评估报告经 Executive Summary Generator 转化为高管行动建议；与 [[report-distribution-agent]] 协同——生成的执行摘要通过 Report Distribution Agent 分发给相关利益相关者。属 [[Multi-Agent-System-Reliability]] 的战略沟通层，为 C-suite 提供可执行的决策支撑文档。
 
+**[[healthcare-customer-service]]**（Healthcare Customer Service Agent）：医疗保健客户服务 Agent——The Agency Specialized 部门的患者支持专员 Agent，专注于患者预约管理、医疗账单、保险理赔、投诉处理和紧急响应场景。核心理念：**同理心优先**——在解决方案、流程、政策之前必须先承认患者的人性需求，"A patient isn't a ticket number"。核心方法：五步工作流（患者识别与情感评估 → 理解需求 → 解决或转接 → 确认解决 → 记录与跟进），结合 LEAP 降级技术（Listen/Empathize/Apologize/Partner）和 HIPAA 合规强制要求。十大黄金规则：绝不提供临床建议（所有临床问题立即路由给持牌临床人员）、身份验证前置（HINAME+DOB+SSN后四位）、紧急情况识别100%准确（胸痛/呼吸困难/中风症状立即指导911）、账单冻结（在审核期间）、承诺必须文档化、绝不将情绪困扰患者强制等待、有疑问立即升级、永不最小化患者顾虑、永不透露诊断或预后信息。
+
+**[[customer-service]]**（Customer Service Agent）：通用行业客户服务 Agent——The Agency Specialized 部门的全能客服专家 Agent，面向零售/SaaS/酒店/金融/电信/医疗行政/物流等多行业，提供全场景客户支持。核心理念：**"Customer service isn't a department — it's a philosophy"**——每个联系进来的客户都值得感到被重视、被理解，客服是将问题转化为忠诚的机会。五步工作流（Greet & Assess → Understand → Understand Inquiry → Resolve or Route → Confirm & Close → Document），**十大关键规则**（Empathy First / No "not possible" without alternative / Never blame customer / Own the problem / Proactive escalation before frustration peaks / No unfulfilled promises / Personalized every interaction / No hold without asking / Document everything / Warm close）。覆盖 FAQ/Account/Order/Complaint/Retention/Escalation 全类型，沟通渠道支持 Phone/Live Chat/Email/Social/SMS。属 [[hospitality-guest-services]] 和 [[healthcare-customer-service]] 的抽象基础——两者分别是客服 Agent 在款待业和医疗场景的具体化，共享投诉处理框架和升级协议，但各自增加行业专属合规要求（HEARD 框架/HIPAA）。
+
 ### The Agency — Paid Media 部门
 The Agency 的 Paid Media 部门专注于企业级付费媒体策略与运营，涵盖 Google Ads、Microsoft Advertising、Amazon Ads 三大核心平台。
 
@@ -254,7 +327,12 @@ Key concepts: [[PerformanceMax]], [[SmartBidding]], [[AccountArchitecture]], [[T
 
 **[[accounts-payable-agent]]**（Accounts Payable Agent）：The Agency 财务部门的自主支付运营专员 Agent——处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 等全支付通道。核心原则：**幂等性优先**（reference ID 去重，零重复付款）、**审计全链路**（每笔支付记录发票引用、金额、通道、时间戳和状态）、**安全路由**（自动选择最优通道路由，失败自动切换备选通道）、**严格额度管控**（超授权额度必须人工审批）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成，接收来自其他 Agent 的支付请求并生成支出报告供 Strategy Agent 分析。成功指标：零重复付款、< 2 分钟执行时间（快捷通道）、100% 审计覆盖、60 秒内 escalation SLA。属 [[Multi-Agent-System-Reliability]] 的财务合规执行层，[[Accounts-Payable-Agent]] 为 The Agency 提供可信赖的支付执行基础。
 
+**[[finance-tax-strategist]]**（Tax Strategist Agent）：The Agency Finance 部门的专业税务战略代理（代号 Cassandra）——在 Big Four 会计事务所、企业税务部门和精品税务咨询机构拥有 15 年+经验。核心理念：**"Tax isn't an afterthought; it's a strategic lever."** 核心使命：通过五阶段工作流（税务状况评估 → 机会识别 → 策略开发 → 实施合规 → 持续监控），使组织有效税率（ETR）达到行业同行中位数或以下。核心能力：多辖区税务优化（联邦/州/国际 GILTI/BEPS/FDII）、转让定价基准研究与 APA 申请、83(b) Election / QSBS 等股权激励税务筹划、R&D 税收抵免与加速折旧、BEAT 分析与税基侵蚀防控。标准化交付物：Tax Planning Memorandum（含立场强度评估 + 风险量化矩阵）和 ETR Analysis（含年度纵向对比 + 优化机会排序）。成功指标：ETR ≤ 行业中位数、零罚款利息、100% 按时申报、所有立场有同期文档支持、审计调整 < 2% 总税负。与 [[accounts-payable-agent]] 同属 Finance 部门——后者处理支付执行，前者专注税务筹划与合规，构成财务合规的双侧防护。与 [[accounts-payable-agent]] 和 [[support-finance-tracker]] 共同构成 The Agency Finance 部门完整的财务合规体系（支付合规/税务筹划/财务分析）。
+
+**[[finance-investment-researcher]]**（Investment Researcher Agent）：The Agency Finance 部门的专业投资研究代理（代号 Quinn）——14年+经验，覆盖买方权益研究、风险投资尽职调查和机构资产管理，已完成 200+ 家公司尽职调查并识别出多只 5 倍回报投资。核心理念：**"The best investments are found where rigorous analysis meets variant perception."**（当研究与共识一致时，不存在优势）。核心使命：生产机构级投资研究，发现 alpha、量化风险、支持数据驱动的投资组合决策。**五阶段工作流**：筛选与创意生成 → 初步评估 → 深度研究 → 论点构建与建议 → 持续监控。**双重论证框架**：牛市和熊市论点同等严谨，倡导胜于平衡即为营销而非研究。核心能力：基本面分析（财务、护城河、管理层评估、行业、ESG）、量化分析（DCF/可比公司法/残余收益/DDM、因子模型、风险指标）、尽职调查（私募/M&A/运营/市场）、另类数据集成（网页/App/专利/职位/卫星图像）。标准化交付物：Investment Research Report（含执行摘要、三情景 DCF、可比分析、竞争格局）和 Due Diligence Checklist（含 Red Flags 识别）。成功指标：风险调整回报高于基准、80%+ 论点终结触发器提前识别、DD 流程在投资决策前捕获 90%+ 实质性风险。与 [[finance-financial-analyst]]（Morgan）和 [[finance-tax-strategist]]（Cassandra）同属 Finance 部门——三方构成投资决策完整能力链：Morgan 负责财务建模与预算分析，Quinn 负责投资研究与估值，Cassandra 负责税务筹划，共同支撑 The Agency 的投资组合管理能力。
+
 ### Home Lab Infrastructure
+
 **[[家庭网络环境概览]]**（2026-04-03）：个人家庭网络的完整基础设施架构文档，记录了从公网 VPS（RackNerd）到内网各服务器的完整拓扑、应用部署和域名映射。核心架构：FRP（Fast Reverse Proxy）内网穿透 + Caddy 反向代理实现内网设备公网访问；Cloudflare DNS 托管提供免费 CDN 与 SSL 证书。
 
 **节点组成**：① **公网 VPS（RackNerd）** — 位于公网，运行 Caddy 和 FRP Server，是内网穿透的核心节点；② **Mac Mini M4 主控节点**（192.168.3.189）— 运行 OpenClaw AI 助手框架、vaultwarden 密码管理器、STQ 项目管理系统；③ **Synology NAS DS718 媒体中心**（192.168.3.17）— 运行 Jellyfin 媒体服务器、Navidrome 音乐流媒体、Calibre 电子书库、MinIO 对象存储、Prometheus 监控栈；④ **Ubuntu1 监控服务器**（192.168.3.47）— 运行 Grafana + Prometheus 监控栈、Apache Superset BI 平台、Homarr 导航面板、Transmission 下载客户端；⑤ **Ubuntu2 自动化服务器**（192.168.3.45）— 运行 n8n 工作流自动化平台、Gitea 自建 Git 服务、Draw.io 图表编辑器。
@@ -477,6 +555,8 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast
 
 **[[WSL2]]** 是 Windows 内置的 Linux 运行环境，WSL2 默认使用 NAT 网络模式导致 Windows 代理无法被 WSL2 内部访问。通过 `.wslconfig` 启用 `networkingMode=mirrored` + `dnsTunneling=true` 可实现 WSL2 与 Windows 共享网络堆栈；国内环境下可使用 `ghproxy.com` 反向代理加速 GitHub 下载。[[WSL2]] 与 [[Ubuntu Server]] 同属 Linux 环境，[[WSL2]] 侧重 Windows 桌面开发场景，[[Ubuntu Server]] 侧重无头服务器场景。
 
+**WSL2 Docker 容器代理配置**：[[WSL2-中-Docker-容器访问宿主机代理]] 补充了 WSL2 下 Docker 容器访问宿主机代理的具体方法——核心问题是容器内 `127.0.0.1` 指向容器自身而非宿主机，解决方法是用 `host.docker.internal`（Docker 内置 DNS，自动解析为宿主机 IP）替代。适用场景包括 pip/apt-get/curl 等各种命令的代理配置（示例端口 `10808`），代理软件（如 Clash）必须开启「允许局域网连接」。
+
 **[[ubuntu服务器通过rsync实现日常增量备份]]**：在已完成 Clonezilla 全盘镜像备份的基础上，通过 rsync 实现不关机的日常增量同步。核心架构：备份脚本（`/usr/local/bin/rsync_backup.sh`）+ Crontab 凌晨 3:00 自动执行 + NAS 作为备份目标。关键配置：①锁文件机制（`/tmp/rsync_backup.lock`）防止并发运行；②挂载点检查（`mountpoint -q`）防止 NAS 掉线时写入本地磁盘；③rsync 参数 `-azR --delete`（归档/压缩/保持相对路径/删除目标端多余文件）+ 排除规则（venv/__pycache__/.git）；④Docker 卷路径 `/var/lib/docker/volumes`；⑤数据库一致性建议（MySQL 先 `mysqldump` 再 rsync）。NFS 永久挂载通过 `/etc/fstab` 配置（`192.168.3.17:/volume2/backup /mnt/nas_backup nfs defaults,timeo=900,retrans=5,_netdev 0 0`），`_netdev` 参数确保网络就绪后再挂载。灾难恢复路径：单文件丢失→从 NAS 直接拷贝；系统崩溃但能 SSH→反向 rsync；硬盘彻底损坏→Clonezilla 镜像恢复 + rsync 同步最新增量（"时间点恢复"）。与 [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]] 共同构成完整 NAS 备份基础设施；与 [[Clonezilla对Ubuntu Server进行全盘镜像备份]] 形成"全量+增量"双层保护体系。
 
 **[[clonezilla对ubuntu-server进行全盘镜像备份]]**：使用 Clonezilla（再生龙）对 HP ZBook Ubuntu Server 进行全盘镜像备份的完整操作指南——①制作启动盘（Rufus + Clonezilla ISO，GPT+UEFI 新机器/DD 镜像模式备用）；②从旧笔记本 U 盘启动 Clonezilla live；③选择 `device-image` → `nfs_server` 模式，通过 NFS 将 NAS（192.168.3.17:/volume2/backups）挂载为镜像存储目标；④配置备份参数（Beginner 模式 → `savedisk` → 选择 `-z1p` 高压缩 → 跳过文件系统检查 `-sfsck`）；⑤确认后开始全盘克隆，生成日期格式镜像文件（如 `Ubuntu_Server_Ghost_20251220`）。灾难恢复时选择 `restoredisk` 选中镜像即可完整还原系统。与 [[Ubuntu服务器通过rsync实现日常增量备份]] 互补——Clonezilla 提供全量磁盘快照（低频），rsync 提供文件级增量同步（高频），构成"全量+增量"双层备份策略；恢复时先 Clonezilla 还原镜像，再用 rsync 同步最新增量（时间点恢复）。
@@ -530,6 +610,8 @@ Key concepts: [[Channel ID]], [[RSS Feed]], [[X/Twitter-API-Automation]], [[Soci
 
 **Docker 容器化部署**：[[n8n-docker-install-update]] 提供了完整的 n8n Docker 部署指南——通过自定义 Dockerfile 扩展官方镜像（安装 curl/wget）；配置 `ALL_PROXY=socks5://宿主机Docker网桥IP:10808` 实现容器内科学上网；配合 Caddy 反向代理提供 HTTPS 访问。版本更新方法：`docker compose pull` → `docker compose down` → `docker compose up -d`。
 
+**Docker Telegram 代理问题排查**：[[n8n-docker-配置-telegram-代理-troubleshooting]] 记录了 n8n 在 Docker 容器内通过 `host.docker.internal` 访问宿主机 xray/v2ray 代理的完整排查过程。核心要点：①容器内 `127.0.0.1:10808` 指向容器自身而非宿主机，必须用 `host.docker.internal`；②需在 `docker-compose.yml` 中配置 `extra_hosts: - "host.docker.internal:host-gateway"`；③Node.js 原生 `fetch` 不读代理环境变量（导致误判 ETIMEDOUT），但 n8n 使用 axios 会自动遵循 `HTTP_PROXY`/`HTTPS_PROXY` 环境变量。正确验证方法是用 n8n HTTP Request 节点直接测试 `api.telegram.org`。
+
 **入门教程**：[[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]] 提供了使用 N8N 构建 AI Agent 的完整指南，涵盖五类节点系统（Trigger/Action/Utility/Code/Advanced AI）、Agent 记忆机制、以及与 Airtable 等外部工具的集成方法。教程强调了 Agentic System 的核心概念：Agent 利用 LLM 动态选择工具，结合 Memory 实现上下文保持，使 AI 应用能够根据用户输入自适应响应。
 
 **Claude + N8N MCP 自动化工作流**：通过安装 [[n8n-mcp]]（Model Context Protocol 多功能控制面板），Claude 可理解并调用 543 个 N8N 节点，自动生成工作流。使用 OpenSea 模型 + Extended Thinking 模式可提升生成质量，Claude 生成的 N8N 工作流完成度约 80%-90%，仍需人工二次修正，但显著降低了新手的入门门槛。两种接入路径：**Claude Desktop** 端侧方案（适合桌面用户，通过本地 MCP 连接 n8n）与 **Claude API** 云端方案（适合程序化集成），核心均依赖 [[Node.js]] 运行环境。
@@ -572,6 +654,8 @@ Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP vi
 
 **[[fireworks-tech-graph]]**：Claude Code Skill，将自然语言描述转化为精美 SVG 技术图并导出 PNG——解决技术文档/博客缺乏高质量可视化图表、手动绘图耗时且风格不统一的核心痛点。内置 **7 种视觉风格**（扁平图标风/暗黑极客风/工程蓝图风/Notion极简风/玻璃态卡片风/Claude官方风格/OpenAI官方风格）和 **14 种 UML 图类型**，深度覆盖 AI/Agent 领域常见 Pattern（RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等）。语义形状词汇表确保图形语义一致（LLM=双边框圆角矩形、Agent=六边形、Vector Store=带内环圆柱），语义箭头系统通过颜色+虚线编码含义（主数据流/控制触发/记忆读取/写入/异步/反馈循环）。通过 `rsvg-convert` 导出 1920px PNG，可直接嵌入文章发布。安装：`npx skills add yizhiyanhua-ai/fireworks-tech-graph`，依赖 `librsvg`（macOS: `brew install librsvg`，Ubuntu: `sudo apt install librsvg2-bin`）。核心价值：**AI Agent 可快速生成专业级技术图，无需手动绘制**，支持 SVG 可编辑 + PNG 无损发布。
 
+**[[baoyu-skills]]**（宝玉 Claude Code 技能集）：[[JimLiu]]（宝玉）维护的 Claude Code Skills 仓库（github.com/JimLiu/baoyu-skills）——覆盖内容生成（xhs-images/infographic/diagram/cover-image/slide-deck/comic/article-illustrator）、多平台发布（X/微信/微博）和 AI 图像生成（baoyu-imagine，支持 OpenAI/Google/DashScope/MiniMax/即梦/豆包等 10+ provider）以及工具集（YouTube 字幕/URL 转 Markdown/翻译/图片压缩/Markdown 处理）。核心方法论：**多维度图像生成系统**——通过类型×风格×配色×渲染×氛围等正交维度组合控制 AI 生成输出，覆盖信息图（20 种布局×17 种风格）、小红书卡片（12 种风格×6 种布局）、封面图（6 种类型×11 种配色×7 种渲染）等多个场景；**三档翻译系统**（快速/标准/精翻）提供渐进式翻译质量；**baoyu-diagram** 不调用图像生成模型，由 LLM 直接手写 SVG 代码生成图表并内嵌深色模式。Claude Skills 范式（[[3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1]]）将 baoyu-skills 的方法论提升为 AI 应用从「提示词工程」向「流程工程」转变的典型案例，属 [[AI Tools & Prompt Engineering]] 的 Claude Skills 生态层。
+
 **Claude Prompt Library**（[[useful-prompt-lib]]）：Anthropic 官方提示词库，收录 64+ 款专业化提示词，覆盖开发工具（Python Bug Buster、Code Consultant、Git Gud）、效率工具（Data Organizer、Review Classifier、CSV Converter）、创意工具（Storytelling Sidekick、Culinary Creator）、营销工具（Babel's Broadcasts 多语言推文、Polyglot Superpowers 互译）、教育工具（Meeting Scribe、Lesson Planner、Socratic Sage）等 10+ 领域。TikTok 跨境电商推荐三剑客：Babel's Broadcasts（10 种语言产品发布）、Review Classifier（评论自动化分类）、Data Organizer（非结构化文本→JSON，对接 n8n 工作流）。
 
 **LLM / RAG / AI Agent 三层架构**：基于 [[llms-rag-ai-agent-三个到底什么区别]] 的系统梳理，AI 应用的三层架构：
@@ -638,6 +722,8 @@ Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP vi
 
 **[[Nano Banana Pro 提示词指南]]**：谷歌发布的 Nano Banana Pro 官方提示词指南（《The Complete Guide to Nano Banana Pro: 10 Tips for Professional Asset Production》，含上下两篇），凌晨无预警发布，核心主题是"将 AI 从趣味性图像生成升级为功能性专业资产生产"。核心理念：**停止标签堆砌，像创意总监一样思考**。核心突破：意图理解引擎实现物理规则推演、构图美学理解和语义上下文推理（而非传统关键词匹配）。关键能力：支持 14 张参考图像（6 张高保真）实现"身份锁定"；默认生成思考图像（不收费）后再输出最终结果；支持 1K-4K 原生高分辨率；[[Google Search]] 信息锚定减少实时内容幻觉。10 大黄金法则包括：编辑而非重新生成、使用自然语言完整句子、具体且具描述性、提供上下文（"为什么"或"为谁"）。上篇（[[nano-banana-pro-prompting-guide-strategies-1]]）覆盖前 9 个能力域（文本渲染/信息图、角色一致性/病毒缩略图、Google 搜索信息锚定、高级编辑/修复/着色、2D/3D 维度转换、高分辨率/纹理、思考推理、故事板/概念艺术、结构控制/布局引导），附大量可直接复制的实战提示词模板。与 [[清华出的DeepSeek使用手册]] 同属 AI 工具方法论指南——前者聚焦 DeepSeek 文本推理，后者聚焦 Nano Banana Pro 图像生成；与 [[nano-banana-提示词框架]]（Nano Banana 基础框架）和 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]（Nano Banana 2 综合指南）同属 Nano Banana 提示词体系的不同层次。
 
+**[[open-webui-hermes-agent]]**（Open WebUI + Hermes Agent 集成）：Hermes Agent 官方文档，详细说明如何将 [[OpenWebUI]]（126k★ 最流行自托管 AI 聊天界面）作为 Hermes Agent 的 Web 前端接入。核心机制：Hermes Agent 内置 OpenAI 兼容 API Server（`API_SERVER_ENABLED=true`），Open WebUI 通过 Docker 部署后配置 API URL 和 Key 接入，双方 server-to-server 直连无需 CORS 配置。关键配置：API Server 端口默认 8642，Docker 容器内必须用 `host.docker.internal` 访问宿主机。支持两种 API 模式——Chat Completions（默认，推荐）和 Responses API（实验性，支持结构化事件流）。多用户场景通过 Profiles 实现隔离，每个 Profile 运行独立 API Server（不同端口）。工具执行时实时流式输出工具 emoji 到 UI（ToolStreaming），提升可见性。是 [[Ollama 本地 LLM 部署]] 中 Open WebUI 使用场景的扩展——后者侧重 Ollama 后端，本页侧重 Hermes Agent 后端。
+**[[Hermes-Agent-配置笔记]]**（Hermes Agent 多角色配置实战）：记录 Vibe Coding 多角色 Agent 配置的核心方法，涵盖四个关键场景。**角色分层配置**：SOUL.md（`~/.hermes/SOUL.md`）定义全局角色人设（身份定位、思维方式、沟通风格），AGENTS.md（项目根目录）定义项目级技术栈和开发约定，两者职责分明，避免每次对话重复配置。**多 Profile 隔离**：`hermes profile create --clone` 创建独立 Agent 实例，每个 Profile 拥有独立的 SOUL.md、配置、记忆、会话历史和技能，实现多角色完全隔离。**Telegram Bot 接入**：Telegram Bot 无响应的四大根因——Gateway 未启动（最常见）、Token 配错 Profile、用户 ID 未加入白名单（`TELEGRAM_ALLOWED_USERS`）、同一 Token 被两个 Gateway 共享导致冲突。**国内网络代理**：Telegram 在国内被封，通过 Profile 的 .env 配置 `HTTPS_PROXY`/`HTTP_PROXY` 环境变量解决，同一 Token 被两个 Gateway 共享导致冲突；重启 Gateway 后验证连接状态。是 [[open-webui-hermes-agent]] 的配置前置知识——后者侧重前端接入，前者侧重角色配置与网络层。
 **[[Ollama 本地 LLM 部署]]**：基于 [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]] 的完整实操指南，展示如何使用 Ollama + DeepSeek-R1 + Open WebUI 在本地离线部署大模型。核心价值：**免费、无需 API Key、数据完全私有**。Ollama 跨平台支持（macOS/Windows/Linux/Docker），通过 `ollama run deepseek-r1:8b` 一键运行；国内网络环境下可通过魔塔社区（modelscope.cn）或 HuggingFace Mirror（hf-mirror.com）加速下载；云服务器部署必须通过 nginx + Bearer Token 保护 API 防止恶意调用；Open WebUI 提供浏览器端 Web 界面，支持 RAG 本地知识库（bge-m3 嵌入模型）和联网搜索。硬件要求：1.5B 模型需 4GB RAM，7B 需 16GB RAM，32B 需 64GB RAM+48GB 显存（Apple M2 Max 可流畅运行 32b 及以下）。
 
 **[[Qwen2.5-Coder]] 部署实战**（[[在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b]]）：Ubuntu 上通过 Ollama 本地部署 Qwen2.5-Coder 7B 代码生成模型，3条命令完成安装（`curl -fsSL https://ollama.com/install.sh | sh && ollama pull qwen2.5-coder:7b && ollama run qwen2.5-coder:7b`）。推荐配置：8+ CPU cores + 16GB RAM + NVIDIA GPU（CUDA 自动加速）。**qwen2.5-coder:7b 因 Tool usage 能力强、Shell/Python/SQL 理解强、Repo 级代码理解强，比普通 qwen2.5:7b 更适合工程任务**。支持 REST API（默认 localhost:11434）和 Python/Node.js SDK，可与 [[Open WebUI]]、[[n8n]]、[[OpenClaw]] 等工具集成构建本地 AI 应用栈。与 [[Ollama 本地 LLM 部署]]（DeepSeek-R1）同属 Ollama 本地部署场景，本方案侧重 Qwen2.5-Coder 的代码生成能力优势。
@@ -714,7 +800,7 @@ Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Suff
 
 | Category | Count | Key Sources |
 |----------|-------|-------------|
-| The Agency Agents | 147+ agents | README, CONTRIBUTING, 12 divisions |
+| The Agency Agents | 147+ agents | README, CONTRIBUTING, 12 divisions, integrations/qwen |
 | CTP Topics | 73 topics | AWS, Azure, FinOps, Security |
 | Learning Sessions | 30+ sessions | OpenText, AWS, EKS, Cloud FinOps |
 | Home Office | 60+ docs | Docker, NAS, Network, Monitoring |
@@ -872,7 +958,9 @@ Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Suff
 
 **[[做TK跨境思路不对努力白费]]**：TikTok 跨境电商全流程实战指南——从市场选择（优先美区/日本，避开东南亚）→ 账号准备（选区看直播了解流程）→ 选品策略（数据软件分析+单一垂直类目）→ 店铺运营（流量监控+商品优化）→ 流量获取（短视频营销+达人合作）→ 仓储物流（海外仓+海运补货）→ 团队建设（招聘分工），提供完整的执行框架。核心观点：思路正确是成功的前提，市场定位和选品是核心竞争力。与 [[电商如何选品]] 同属选品策略范畴，与 [[TikTok E-commerce Product Management]]（Django 产品管理系统）互补——前者侧重运营策略，后者侧重技术实现。
 
-**电商数据采集与处理系统**：基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统。三层架构：爬虫层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。推荐 Scrapy + Playwright 组合抓取动态页面，Docker Compose 容器化部署，输出 JSON/CSV 供 n8n 消费；n8n 工作流实现定时启动爬虫→读取数据→LLM提取属性→写入数据库→报表通知的全链路自动化；AI 处理任务包括摘要分类、多语言翻译、特征提取、异常检测；本地可使用 Ollama（Mistral/Llama3）通过 HTTP Request 调用，无需外部 API Key；防封策略包括 User-Agent 轮换、代理池（Bright Data/ScraperAPI）和下载延迟随机化。与 [[做TK跨境思路不对努力白费]]（运营策略）互补，后者侧重电商运营全流程，前者侧重技术架构搭建。与 [[scrapy-playwright-抓取tiktok-shop-data]] 同属电商数据采集技术栈。
+**Scrapy + Playwright 抓取 TikTok Shop Data**：基于 [[Scrapy---Playwright-抓取TikTok-Shop-Data]] 的 TikTok Shop 店铺数据爬取实战笔记。核心方法：通过 Python venv 隔离项目依赖，安装 `scrapy` + `scrapy-playwright`，配置 Playwright Chromium 浏览器，实现 JS 渲染页面抓取。Docker 部署需在 Dockerfile 中添加 venv 创建和 PATH 配置命令。验证安装成功的命令：`python -c "from playwright.sync_api import sync_playwright; print('Playwright OK')"`。与 [[电商数据采集与处理系统]]（三层架构中的爬虫层）和 [[TikTok Shop - Apache Superset Dashboard设计思路]]（数据可视化层）共同构成 TikTok Shop 数据采集→处理→展示完整链路。
+
+**电商数据采集与处理系统**：基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统。三层架构：爬虫层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。推荐 Scrapy + Playwright 组合抓取动态页面，Docker Compose 容器化部署，输出 JSON/CSV 供 n8n 消费；n8n 工作流实现定时启动爬虫→读取数据→LLM提取属性→写入数据库→报表通知的全链路自动化；AI 处理任务包括摘要分类、多语言翻译、特征提取、异常检测；本地可使用 Ollama（Mistral/Llama3）通过 HTTP Request 调用，无需外部 API Key；防封策略包括 User-Agent 轮换、代理池（Bright Data/ScraperAPI）和下载延迟随机化。与 [[做TK跨境思路不对努力白费]]（运营策略）互补，后者侧重电商运营全流程，前者侧重技术架构搭建。与 [[Scrapy---Playwright-抓取TikTok-Shop-Data]] 同属电商数据采集技术栈。
 
 ### TikTok E-commerce Product Management
 A comprehensive Django-based product data management system for TikTok Shop. Covers Django ORM models (Product, ProductImage, ProductVideo, ProductVariation, ProductReview), Django Admin customization (TinyMCE rich text, inline models, image preview modals), REST API via Django REST Framework with django-filter for search and filtering, Docker + Gunicorn + Nginx production deployment, Django-Q async task queue for Bright Data API scraping, and custom Management Commands for JSON data import. Key components: Product list with thumbnail display, multi-condition filtering by store_name, bulk product fetch via Bright Data asynchronous API, description detail HTML generation, and Apache Superset BI dashboard integration.
@@ -940,6 +1028,8 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
 ### Sales Outbound Methodology
 **[[sales-outbound-strategist]]**（Outbound Strategist Agent）：信号型出站销售策略师，将出站销售从"批量轰炸"转变为"精准触发"——核心信念：出站应由证据驱动，而非配额驱动。核心理念：**信号驱动出站转化率比无触发出站高 4-8 倍**；信号的半衰期极短（30 分钟内必须路由到正确销售），24 小时后信号失效，72 小时后竞争对手已成交。核心框架：三层信号分级体系（Tier 1 主动购买信号如 G2 访问/竞品对比 → Tier 2 组织变化信号如融资/招聘/领导层变动 → Tier 3 技术/行为信号如技术栈变化/内容互动）+ 可证伪 ICP 定义（含排除条件，否则是 TAM 幻灯片）+ 三层账户分级（Tier 1 深度多线程个性化 / Tier 2 半个性化序列 / Tier 3 自动化轻定制）+ 8-12 触点 3-4 周多渠道序列（每次触达必须提供新的价值角度）。冷邮件回复率基准：泛化型 1-3%、角色定制 5-8%、信号驱动 12-25%、推荐引入型 30-50%。SDR 角色演变：从每天 100 次活动的批量操作员 → 拥有 50-80 个深度账户的信号监控管线专家。与 [[sales-discovery-coach]] 协同——发现阶段收集的 ICP 信号直接驱动出站序列启动；与 [[sales-deal-strategist]] 形成漏斗互补——出站负责漏斗顶部（Signal → Contact），Deal Strategist 负责漏斗中部（Qualified → Commit）；与 [[sales-account-strategist]] 形成客户生命周期互补——出站获取新客户，Account Strategist 负责 Land-and-Expand 扩张。
 
+**[[sales-outreach]]**（Sales Outreach Agent）：B2B 销售外勤 Agent 的完整角色定义与可执行框架——核心信念：最佳销售人员不推销，而是帮助客户购买。覆盖从潜客挖掘（ICP 定义、触发事件识别）到冷开拓（7 步触达序列：冷邮件→LinkedIn→跟进→电话→内容→断联邮件）、异议处理（以好奇心探索而非反驳）、提案撰写（口头对齐后才发送，24 小时内完成）到管道管理（7 阶段：Prospecting→Engaged→Discovery→Solution→Proposal→Negotiation→Closed）的完整生命周期。核心销售方法论：[[Consultative Selling]]（咨询式销售）、[[SPIN Selling]]（Neil Rackham 四步提问法）、[[Challenger Sale]]（商业洞察引领对话）、MEDDIC/MEDDPICC（复杂销售八维度资质框架）。关键原则：100% 个性化（不满足 ≥2 次条件的实体在 Source Page 内 wikilink 引用）；每条消息单一 CTA；永远先提供价值再提产品；断联邮件往往回复率最高。与 [[sales-outbound-strategist]] 互补——后者聚焦信号驱动规模化出站策略，前者提供一对一个性化执行细节；与 [[sales-engineer]] 协同——外勤 Agent 负责建立初次接触并完成 Discovery，Sales Engineer 在此基础上进行技术评估。
+
 ### Sales Discovery Methodology
 **[[sales-discovery-coach]]**（Discovery Coach Agent）：销售发现访谈（Discovery）方法论与教练框架，帮助销售代表和SDR成为更优秀的买家访谈者——坚信发现阶段才是交易成败的真正战场，而非演示、提案或谈判阶段。
 
@@ -977,6 +1067,8 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
 
 **[[blockchain-security-auditor]]**（Blockchain Security Auditor）：The Agency Specialized 部门的智能合约安全审计 Agent——专职发现 DeFi 协议与区块链应用中的漏洞，在攻击者之前找到 bug。核心理念：**"Your job is not to make developers feel good — it is to find the bug before the attacker does."** 核心理念：自动化工具只能捕获约 30% 的真实漏洞；每个发现必须包含可复现 PoC；使用 OpenZeppelin 不等于安全（误用安全库本身是漏洞类型）；必须验证代码与部署字节码一致（供应链攻击真实存在）；Solidity 0.8+ 的 `unchecked` 块仍需审查；漏洞发现误报率必须控制在 10% 以下。核心方法：自动化静态分析（[[Slither]]/[[Mythril]]/[[Echidna]]）+ 人工逐行审查 + 属性化模糊测试 + 经济博弈建模；五步工作流（范围→自动化分析→人工审查→经济分析→报告）。交付物包含完整审计报告模板（Severity 分类表 + 详细 Finding 结构 + Foundry PoC）、Slither 综合分析脚本（高/中置信度分类）、访问控制审计清单（Role Hierarchy/Initialization/Upgrade Controls/External Calls）。高级能力涵盖形式化验证（[[Certora]]/[[Halmos]]/KEVM）、EVM 层漏洞（存储冲突/签名重放/跨链消息重放）、事件响应（攻击溯源 + 救援合约）。漏洞评级严格化：能导致用户资金损失的发现不得降级为 Informational；C-01/H-01 必须在部署前修复；Medium 可随监控计划上线。与 [[Agents-Orchestrator]] 构成审计质量门控——流水线交付前须通过安全审计；与 [[Compliance-Auditor]] 同属审计类 Agent，但前者聚焦代码层智能合约安全，后者聚焦企业合规认证框架。
 
+**[[engineering-solidity-smart-contract-engineer]]**（Solidity Smart Contract Engineer）：The Agency Engineering 部门的 EVM 智能合约开发专家 Agent——专注于 EVM 兼容链（以太坊主网及 L2）的安全合约架构、Gas 优化和 DeFi 协议开发。核心理念：**"Treat every wei of gas as precious, every external call as a potential attack vector, and every storage slot as prime real estate."** 与 [[blockchain-security-auditor]] 构成互补关系——前者专注于开发实现（安全开发+Gas优化+可升级架构），后者专注于攻击发现（渗透测试+漏洞挖掘）。核心交付物：安全合约模板（ERC-20/721/1155 含 AccessControl/Pausable）、UUPS/Staking Vault 可升级合约模式、Foundry 测试套件（>95% 分支覆盖率）、Gas 优化参考模式（存储打包/calldata/自定义错误）。关键原则：checks-effects-interactions 模式（非重入根本保障）、never use `tx.origin`（始终使用 `msg.sender`）、pull-over-push 优先（避免 DoS）、OpenZeppelin 优先（不重新发明密码学轮子）。五步工作流：需求与威胁建模→架构与接口设计→实现与 Gas 性能分析→测试与形式化验证→审计准备与部署。Gas 优化核心要点：存储打包节省约 5000 gas/写入；calldata 替代 memory 节省约 60 gas/参数；custom errors 较 require 字符串节省约 50 gas/ revert；immutable/constant 避免 SLOAD 消耗。|
+
 **[[compliance-auditor]]**（Compliance Auditor）：The Agency Specialized 部门的专业技术合规审计 Agent——专注于 SOC 2、ISO 27001、HIPAA、PCI-DSS 等安全隐私认证的全流程指导，从准备评估到证据收集直至认证通过。与 Healthcare Marketing Compliance 侧重营销内容合规不同，Compliance Auditor 关注**技术控制体系**的审计准备。核心方法：五步工作流（Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance）；核心原则：**不跟随的政策比没政策更危险**（Checkbox-Compliance 是反面教材）、**证据必须证明整个审计周期内持续有效**（而非仅当下存在）、**自动化证据收集从第一天建立**（手动流程无法扩展）、**技术控制优于管理控制**（代码比培训更可靠）。核心交付物：Gap Assessment Report（差距评估报告）、Evidence Collection Matrix（证据收集矩阵）、Policy Template（策略模板）。成功指标：零不合格发现（zero adverse findings）、审计周期缩短 30%、年度合规状态持续可查。与 [[specialized-model-qa]] 互补——后者审计 AI/ML 模型质量，前者审计组织整体安全控制，两者共同构成完整的技术合规审计体系；与 [[automation-governance-architect]] 协同——自动化证据收集需依托 Governance Architect 设计的 AI 系统治理框架。
 
 |**[[specialized-workflow-architect]]**（Workflow Architect）：工作流设计专家 Agent——The Agency Specialized 部门的工作流设计与系统建模专家，在代码编写前对系统所有路径进行穷举建模。核心职责：**工作流发现**（扫描 route/worker/migration/IaC/cron/event-listener/webhook 文件找出隐式工作流）+ **工作流注册表维护**（四视角：按工作流/按组件/按用户旅程/按状态）。核心交付物：**工作流树规范格式**（含 Actor/Prerequisites/Trigger/Step 树/ABORT_CLEANUP/State Transitions/Cleanup Inventory/Test Cases/Assumptions），覆盖快乐路径+七类失败分支（输入验证/超时/瞬态/永久/部分失败/并发冲突）。关键原则：**不只为快乐路径设计**、**每个系统边界定义显式 Handoff Contract**（payload schema + 成功/失败响应 + 超时值 + 恢复动作）、**Reality Checker 验证是 Draft 升为 Approved 的前置条件**、**每个分支必须有对应测试用例**（无测试覆盖的分支在生产中断言）。Agent 协作协议：Reality Checker 验证规范→Backend Architect 实现代码→API Tester 生成测试用例→DevOps Automator 验证清理顺序→Security Engineer 审查凭证传递。高级能力：**好奇心驱动式 Bug 发现**（追问数据持久化假设/网络连通性假设/时序假设/认证假设，主动发现高危 Bug）。成功指标：假设表随时间持续缩减、注册表中无 Missing 状态工作流残留超过一个 Sprint、零孤岛资源。属 The Agency Specialized 部门的质量保障基础设施，与 [[specialized-civil-engineer]]（基础设施工程）同属 Specialized 专业 Agent 系列。
@@ -1205,3 +1297,7 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
 
 32. **Feishu Integration Developer Agent：飞书开放平台全栈集成专家 Agent**：[[engineering-feishu-integration-developer]] 定义了一种专注于飞书（Feishu/Lark）开放平台企业级集成的 AI Agent，覆盖自定义机器人、交互式消息卡片、审批流自动化、Bitable 多维表格、SSO/OIDC 认证和飞书小程序六大核心模块。核心理念：**飞书集成不只是调用 API**，必须处理权限模型、事件幂等性、多租户架构和与内部系统的深度集成。核心工程标准：`tenant_access_token`（应用级）与 `user_access_token`（用户级 OAuth）必须严格区分使用场景；所有 API 响应必须检查 `code` 字段；事件处理必须实现幂等性（飞书可能重复投递同一事件）；卡片 JSON 必须在 Card Builder 工具验证后才发送；Bitable 批量写入每请求上限 500 条需分批并建议批次间 200ms 延迟。核心交付物：完整项目结构（config/auth/bot/approval/bitable/sso/webhook 目录）、TokenManager 缓存实现（含提前5分钟刷新边界保护）、CardBuilder 审批通知卡片（含 Approve/Reject/View Details 三按钮）、EventDispatcher 事件分发（含 Bot 消息接收和审批状态变更监听）、BitableClient CRUD（含 500 条分批写入）、OAuth 授权登录三步流程（authorize 重定向 → code 交换 → user_info 获取，state 参数防 CSRF）。成功指标：API 调用成功率 >99.5%、事件处理延迟 <2 秒、卡片渲染成功率 100%、Token 缓存命中率 >95%、审批流端到端时间缩短 50%+。属 The Agency Engineering 部门的集成专精层，与 [[engineering-backend-architect]] 在 API 集成架构上有协同空间；与 [[engineering-rapid-prototyper]] 在速度哲学上存在张力：原型阶段可简化幂等性和错误处理，生产化阶段必须补充完整错误恢复机制。
 
+33. **Language Translator Agent：意义转移型西英翻译专家 Agent**：[[language-translator]] 定义了一种超越逐字替换的实时西班牙语 ↔ 英语翻译 AI Agent，核心理念：**翻译 = 意义转移，非词典替换**——目标不是字典输出，而是对方能实际理解的信息。核心设计：①**5 步工作流**（理解请求 → 意义翻译 → 输出丰富化 → 特殊处理 → 跟进），②**发音标注**（为口语短语提供英语拼音而非 IPA），③**语域标注**（明确正式/非正式，usted/tú 选择），④**地域变体**（标注同一词汇在不同西语国家的差异），⑤**文化注释**（主动标注跨国家/地区的文化敏感性差异），⑥**紧急优先**（医疗/安全/法律短语立即呈现，解释后补）。覆盖六大场景：旅行（方向/餐厅/酒店/交通）、医疗（症状/药物/急诊）、商务（会议/邮件/合同）、法律（证件/权利/官员对话）、日常（问候/闲聊/社交）、书面文档。语言学知识点：Ser vs Estar（两个"to be"不可互换）、虚拟式（subjunctive 在愿望/怀疑/情感场景的强制使用）、假同源词陷阱（embarazada=怀孕、sensible=敏感、éxito=成功）。方言覆盖：墨西哥西语（纳瓦特尔语借词）、卡斯蒂利亚西语（c/z 发 th 音，vosotros）、阿根廷/乌拉圭 Rioplatense（vos 替代 tú）、哥伦比亚（正式 usted 习惯）、加勒比（语速快、辅音弱化）。与 [[Customer Service Agent]] 和 [[Healthcare Customer Service Agent]] 共享紧急响应和语气适配原则，属 The Agency Specialized 部门的语言服务支柱。
+
+34. **Bookkeeper & Controller Agent：财务主管 AI Agent**：[[finance-bookkeeper-controller]] 定义了一种名为"Dana"的专业会计主管 AI Agent，拥有13年+经验，专精日常会计运营、月结流程和内部控制。核心理念：**准确性是不可协商的底线**——快速结账很好，但准确结账是必须达成的目标，速度必须服从准确性。核心能力：①**月结Checklist**（Pre-Close → Core Close → Reconciliations → Financial Statements → Review），将月末结账周期从10天压缩至7天，AP自动化后可达5天；②**GAAP合规框架**（ASC 606/842/718/805），确保所有交易符合会计准则；③**职责分离**（Segregation of Duties），交易发起人与审批/记录人不得为同一人；④**审计就绪**，日常维持审计就绪状态，审计师可随时进场，24小时内提供任何余额支持文件；⑤**账户调节模板**，每个资产负债表科目每月必须调节，未调节余额视为"定时炸弹"。关键工具栈：QuickBooks/Xero/NetSuite（ERP）、FloQast/BlackLine（结账管理）、Bill.com/Tipalti（AP自动化）、Expensify/Ramp（费用管理）。与 [[Finance FPA Analyst]] 协同工作——Dana提供高质量财务数据供 FP&A 做预算差异分析，两者共享"准确数据驱动决策"理念，但存在速度 vs 准确性的内在张力；与 [[Finance Tax Strategist]] 共享季度税项计算和年度税表协调。与 [[Accounts Payable Agent]] 存在协作关系，前者负责AP处理流程，后者（Dana）负责AP数据审核和账务记录。
+