2578 lines
494 KiB
Markdown
2578 lines
494 KiB
Markdown
## [2026-05-02] ingest | WSL2 中 Docker 容器访问宿主机代理
|
||
- Source file: Home Office/WSL2 中 Docker 容器访问宿主机代理.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: WSL2 环境下 Docker 容器访问宿主机代理的完整指南。核心问题：容器内 127.0.0.1 指向容器自身而非宿主机；解决方案：用 Docker 内置 DNS `host.docker.internal` 替代，Docker Desktop/WSL2 自动解析为宿主机 IP。涵盖 pip/apt-get/curl 三种命令的代理配置示例（端口 10808）。
|
||
- Entities checked: WSL2.md（已存在于 entities/）；Clash 仅在本文档出现，不满足 Entity 创建条件
|
||
- Concepts checked: DockerHostNetworking.md（已存在于 concepts/，本文档直接引用）；host.docker.internal 仅在本文档出现，不满足独立 Concept 页面创建条件
|
||
- Source page: wiki/sources/WSL2-中-Docker-容器访问宿主机代理.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: WSL2-中-Docker-容器访问宿主机代理）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（WSL2段落后新增WSL2 Docker容器代理配置段落）；Entity/Concept检查：WSL2/DockerHostNetworking均已存在无需新建，Clash/host.docker.internal仅在本文档出现无需新建；冲突检测：与n8n-docker-配置-telegram-代理-troubleshooting关于extra_hosts前提条件的细节差异已记录于source page Contradictions节；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Scrapy + Playwright 抓取TikTok Shop Data
|
||
- Source file: AI/Scrapy + Playwright 抓取TikTok Shop Data.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: TikTok Shop 店铺数据爬取实战笔记，通过 Python venv 隔离依赖，安装 scrapy + scrapy-playwright + Playwright Chromium，实现 JS 渲染页面抓取。Docker 部署需额外配置 venv 和 PATH 环境变量。
|
||
- Concepts checked: Scrapy/Playwright/Python-venv/scrapy-playwright 均仅在本文档出现，不满足独立 Concept 页面创建条件（Python-venv 为基础工具无需独立页面）
|
||
- Entities checked: TikTok Shop 已存在于 index.md，无需新建
|
||
- Source page: wiki/sources/Scrapy---Playwright-抓取TikTok-Shop-Data.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: Scrapy---Playwright-抓取TikTok-Shop-Data）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（新增Scrapy+Playwright条目置于电商数据采集系统之前，修复旧条目的断链slug）；Entity检查：TikTok Shop已存在无需新建；Concept检查：Scrapy/Playwright/scrapy-playwright/Python-venv为具体工具/基础概念，无需新建；冲突检测：无冲突内容；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Hermes Agent 配置笔记
|
||
- Source file: Agent/Hermes Agent 配置笔记.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Hermes Agent 多角色配置实战笔记，涵盖四大场景：SOUL.md + AGENTS.md 双文件分层角色配置；hermes profile create --clone 创建独立 Agent 实例；Telegram Bot 无响应的四大根因排查；国内网络环境 Telegram 代理配置（HTTPS_PROXY/HTTP_PROXY）。核心价值：提供完整的 Hermes Agent 多角色配置体系。
|
||
- Concepts checked: Multi-Profile-Isolation（已存在于 concepts/，本次引用无需新建）；Proxy-Configuration/Telegram-Bot-Gateway 属于具体技术细节，不满足概念页面创建条件，跳过；SOUL 概念已存在（concepts/SOUL.md.md），本次直接引用
|
||
- Entities checked: Marty-Cagan/Werner-Vogels 均不存在，已创建独立 Entity 页面
|
||
- Source page: wiki/sources/Hermes-Agent-配置笔记.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（slug: Hermes-Agent-配置笔记）；index.md Sources节新增条目置于最前；overview.md新增Hermes-Agent-配置笔记条目，置于open-webui-hermes-agent之后、Ollama-本地-LLM-部署之前；Entity页面：Marty-Cagan.md（按字母顺序插入Mackinder之后）、Werner-Vogels.md（按字母顺序插入VMware之后）均已创建并加入index.md；Concept检查：SOUL.md已存在直接引用，Multi-Profile-Isolation已存在直接引用，Proxy-Configuration/Telegram-Bot-Gateway为具体技术细节不满足概念创建条件；冲突检测：无冲突内容；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | n8n Docker 配置 Telegram 代理 Troubleshooting
|
||
- Source file: Home Office/n8n Docker 配置 Telegram 代理 Troubleshooting.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Docker 容器内 n8n 通过宿主机 xray/v2ray 代理访问 Telegram API 的问题排查与解决方案。核心发现：容器内 127.0.0.1 指向容器自身而非宿主机，必须用 host.docker.internal；Node.js 原生 fetch 不读代理环境变量（导致误判 ETIMEDOUT），但 n8n 使用 axios 会自动遵循 HTTP_PROXY/HTTPS_PROXY 环境变量。
|
||
- Concepts checked: DockerHostNetworking（已存在，无需新建）；host.docker.internal/Docker extra_hosts/HTTP_PROXY 环境变量/axios HTTP 客户端均仅在本文档出现，不满足独立 Concept 页面创建条件
|
||
- Entities checked: n8n.md（已存在于 entities/）；xray/v2ray、Telegram Bot API 仅在本文档出现，不满足 Entity 创建条件
|
||
- Source page: wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: n8n-docker-配置-telegram-代理-troubleshooting）；index.md已更新（Sources节新增条目置于Open WebUI之后）；overview.md已更新（n8n Workflow Automation节新增Docker Telegram代理问题排查段落）；Entity/Concept检查：DockerHostNetworking/n8n均已存在，xray/v2ray/Telegram Bot API/host.docker.internal仅在本文档出现无需新建；冲突检测：无冲突内容；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Open WebUI | Hermes Agent
|
||
- Source file: Agent/Open WebUI Hermes Agent.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Hermes Agent 官方文档，详解如何将 Open WebUI（126k★ 最流行自托管 AI 聊天界面）通过内置 API Server 接入 Hermes Agent。核心主题：OpenAI 兼容 API Server 配置（API_SERVER_ENABLED/KEY）、Docker 部署 Open WebUI（host.docker.internal）、两种 API 模式（Chat Completions 默认 vs Responses API 实验性）、多用户 Profiles 隔离方案、ToolStreaming 工具执行实时可见性。
|
||
- Source page: wiki/sources/open-webui-hermes-agent.md
|
||
- Concepts created: ChatCompletions, ResponsesAPI, ToolStreaming, DockerHostNetworking
|
||
- Entities updated: Open-WebUI.md（新增 Hermes Agent 集成段落）
|
||
- Notes: 步骤1-9全部完成；source page已生成（slug: open-webui-hermes-agent）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（新增open-webui-hermes-agent条目，置于Ollama部署之前，关联两条已有内容）；Entity检查：Open-WebUI.md已存在且内容更丰富，本次新增Hermes Agent集成段落至该页面，OpenWebUI.md已标记为已合并；Concept检查：ChatCompletions/ResponsesAPI/DockerHostNetworking/ToolStreaming均已创建独立页面并加入index.md；冲突检测：ResponsesAPI vs ChatCompletions的张力已在source page Contradictions节记录（两种模式各有适用场景，非真正冲突）；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Expose hermes-agent as an OpenAI-compatible API for any frontend (补充)
|
||
- Source file: Agent/Expose hermes-agent as an OpenAI-compatible API for any frontend.md
|
||
- Status: ✅ 补充完成
|
||
- Summary: 补充创建缺失的 Entity 和 Concept 页面，完善 Wiki 知识体系
|
||
- Entities created: LobeChat, LibreChat, NextChat, ChatBox, AnythingLLM, Jan（6个前端集成工具）
|
||
- Concepts created: Bearer-Token-Authentication, System-Prompt-Layering, Conversation-State-Persistence, CORS-Allowlist, Multi-Profile-Isolation, Background-Job-Scheduling（6个核心概念）；更新 SSE.md entity（新增 Hermes Agent 使用场景）
|
||
- Source page: wiki/sources/expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend.md
|
||
- Notes: 本次补充完成上次摄取时缺失的 Entity 和 Concept 页面；index.md Entities节新增6个条目，Concepts节新增6个条目；冲突检测：无冲突内容
|
||
|
||
## [2026-05-02] ingest | Expose hermes-agent as an OpenAI-compatible API for any frontend
|
||
- Source file: Agent/Expose hermes-agent as an OpenAI-compatible API for any frontend.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Hermes Agent 官方文档，详细说明 API Server 功能将 Agent 暴露为 OpenAI 兼容 HTTP 端点。核心端点：/v1/chat/completions（无状态）、/v1/responses（有状态，支持 previous_response_id 链式调用保留完整上下文含工具调用）、/v1/runs（长会话 SSE 实时进度）、/api/jobs（定时任务 CRUD）。兼容前端：Open WebUI/LobeChat/LibreChat/AnythingLLM/NextChat/ChatBox/Jan 等。多用户隔离通过 Profiles 实现。系统提示词分层叠加，前端提示词不覆盖原有工具集。
|
||
- Source page: wiki/sources/expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend.md
|
||
- Concepts created: OpenAI-Compatible API, Bearer Token Authentication, System Prompt Layering, Conversation State Persistence, SSE, CORS Allowlist, Multi-Profile Isolation, Background Job Scheduling
|
||
- Entities checked: hermes-agent/Open WebUI/LobeChat/LibreChat/NextChat/ChatBox/AnythingLLM/Jan 均仅在 overview.md 上下文提及，本次未创建独立 Entity 页面（overview 第 721 行已有 open-webui-hermes-agent 条目覆盖相关上下文）
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend）；index.md已更新（Sources节新增条目置于最前）；overview.md无需更新（已有 open-webui-hermes-agent 条目覆盖 API Server 核心内容）；冲突检测：无冲突，n8n.md 中记录端口 8642 与 Bearer Token 认证与本文档一致；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | SRE Weekly Issue #513
|
||
- Source file: Cloud & DevOps/SRE Weekly Issue 513.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: SRE Weekly 第 513 期精选文章汇总，涵盖 8 篇 SRE 领域重要文章。核心主题：Organizational Second Hit Syndrome（Richard Cook + John Allspaw）、Netflix NUMA 容器挑战、Cost As Distributed Systems Bug、Autoscaling vs Elasticity、AI 辅助值班、Resilience 的 5 个不可自动化要素。Source page 含 6 条 Key Claims、3 条 Key Quotes、7 个 Key Concepts（OSHS/NUMA/Autoscaling/Elasticity/CostAsBug/AIForOnCall/Resilience）、4 个 Key Entities（Netflix/RichardCook/JohnAllspaw/Airbnb/RunLLM）、5 条 Connections、1 条 Contradiction。
|
||
- Entities created: Adaptive-Capacity-Labs, Richard-Cook, John-Allspaw, RunLLM
|
||
- Concepts created: Organizational-Second-Hit-Syndrome, NUMA, Autoscaling, Elasticity, Cost-As-Distributed-Systems-Bug, AI-For-On-Call, Resilience
|
||
- Source page: wiki/sources/sre-weekly-issue-513.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: sre-weekly-issue-513）；index.md已更新（Sources节新增条目置于最前，Entities节新增4个条目，Concepts节新增7个条目）；overview.md已更新（Major Themes节新增条目，阐述与engineering-sre/incident-response-commander的关联）；Entity检查：Adaptive-Capacity-Labs/Richard-Cook/John-Allspaw/RunLLM各仅出现1次，但Richard-Cook和John-Allspaw为关键人物（行业影响力），已创建独立页面；Concept检查：7个新概念均已创建独立页面；冲突检测：Autoscaling vs Elasticity的张力已在source page Contradictions节记录；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | n8n调用openclaw/hermes agents的工作流架构
|
||
- Source file: Agent/n8n调用hermes agents的工作流架构.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 通过 n8n 工作流编排器调用 Hermes Agent 的完整方案。核心价值：Hermes 内置 OpenAI 兼容 API Server，无需额外代码；通过 Profile 机制实现多 Agent 端口隔离；X-Hermes-Session-Id 实现多轮对话上下文保持。Source page 含 5 条 Key Claims、2 条 Key Quotes、4 个 Key Concepts（OpenAI兼容API/多Profile隔离/X-Hermes-Session-Id/工作流编排）、2 个 Key Entities（HermesAgent/n8n）、3 条 Connections、0 条 Contradictions。
|
||
- Concepts created: OpenAI兼容API、多Profile隔离、X-Hermes-Session-Id、工作流编排
|
||
- Source page: wiki/sources/n8n调用hermes-agents的工作流架构.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: n8n调用hermes-agents的工作流架构）；index.md已更新（Sources节新增条目置于n8n调用openclaw-agents之后，Concepts节新增4个概念）；Entity检查：HermesAgent和n8n各仅出现1次，不满足≥2次创建条件，0个新增Entity页面；Concept检查：4个概念均已创建独立页面（OpenAI兼容API/多Profile隔离/X-Hermes-Session-Id/工作流编排）并写入index.md；冲突检测：无冲突内容；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Codebase Onboarding Engineer
|
||
- Source file: Agent/agency-agents/engineering/engineering-codebase-onboarding-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AI 编程代理人格设定——代码库 onboarding 工程师（Codebase Onboarding Engineer），帮助新开发者快速理解陌生代码库的专业引导者。核心理念："Code first, explain second. State only what you can prove." 核心原则：证据优先、分层解释（三层：一句话→五钟高层→深度代码流）、诚实告知检查边界、严格只读。Source page 含 4 条 Key Claims、3 条 Key Quotes、5 个 Key Concepts（CodebaseOnboarding/ExecutionTracing/EvidenceFirstReasoning/MentalModel/ThreeTierExplanation）、0 个 Key Entities、3 条 Connections、1 条 Contradiction（与 engineering-minimal-change-engineer 的互补关系）。
|
||
- Concepts created: CodebaseOnboarding、ExecutionTracing、EvidenceFirstReasoning、MentalModel、ThreeTierExplanation
|
||
- Source page: wiki/sources/engineering-codebase-onboarding-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: engineering-codebase-onboarding-engineer）；index.md已更新（Sources节新增条目置于最前，Concepts节新增5个概念条目）；overview.md已更新（新增engineering-codebase-onboarding-engineer条目于engineering-cms-developer之后，阐述其与engineering-senior-developer/git-workflow-master/minimal-change-engineer的互补关系）；Entity检查：无外部人物/公司，0个新增；Concept检查：5个新概念均已创建独立页面（CodebaseOnboarding/ExecutionTracing/EvidenceFirstReasoning/MentalModel/ThreeTierExplanation）并写入index.md；冲突检测：与engineering-minimal-change-engineer为互补关系（非冲突），已在source page Contradictions节记录；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Minimal Change Engineer Agent
|
||
- Source file: Agent/agency-agents/engineering/engineering-minimal-change-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AI 编程代理人格设定——最小变更工程师（Minimal Change Engineer），专注于交付最小可工作差异集，拒绝范围蔓延。核心理念："Software has a half-life. Every line you add will eventually need to be read, debugged, refactored, or deleted." 核心原则：只做被要求的事、三次重复才考虑抽象、拒绝防御性代码、主动拒绝审阅阶段范围蔓延。Source page 含 4 条 Key Claims、3 条 Key Quotes、3 个 Key Concepts（ScopeCreep/PrematureAbstraction/MinimalChangePrinciple）、0 个 Key Entities、3 条 Connections、1 条 Contradiction（与 engineering-rapid-prototyper 的潜在张力）。
|
||
- Concepts created: ScopeCreep、PrematureAbstraction、MinimalChangePrinciple
|
||
- Source page: wiki/sources/engineering-minimal-change-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: engineering-minimal-change-engineer）；index.md已更新（Sources节新增条目置于最前）；Entity检查：无外部人物/公司，0个新增；Concept检查：3个新概念（ScopeCreep/PrematureAbstraction/MinimalChangePrinciple），均已创建独立页面并写入index.md；冲突检测：与engineering-rapid-prototyper存在潜在张力（快速原型优先速度 vs 最小变更优先控制），已在source page Contradictions节记录；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Voice AI Integration Engineer
|
||
- Source file: Agent/agency-agents/engineering/engineering-voice-ai-integration-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AI 编程代理人格设定——语音 AI 集成工程师（Voice AI Integration Engineer），专注于设计生产级语音转文字管道。核心理念："Turn raw audio into structured, production-ready text that machines and humans can actually use." 核心管道：音频验证→ffmpeg 预处理→VAD 过滤→分块→Faster-Whisper 转录→pyannote 说话人分离→归一化→PII 脱敏→结构化输出（JSON/SRT/VTT）。Source page 含 5 条 Key Claims、4 条 Key Quotes、8 个 Key Concepts、6 个 Key Entities、6 条 Connections、2 条 Contradictions。
|
||
- Concepts created: VoiceActivityDetection、SpeakerDiarization、EBUR128LoudnessNormalization、FasterWhisper、OverlapAwareChunking、PIIRedaction、StructuredTranscriptJSON、LLMHandoff
|
||
- Source page: wiki/sources/engineering-voice-ai-integration-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: engineering-voice-ai-integration-engineer）；index.md已更新（Sources节新增条目置于最前，Concepts节新增8个概念条目，Entities节新增4个实体条目）；overview.md已更新（新增engineering-voice-ai-integration-engineer条目于engineering-codebase-onboarding-engineer之后，阐述核心管道、架构选型和关键原则）；Entity检查：4个新实体（pyannote.audio/AssemblyAI/Deepgram/ffmpeg）均已创建独立页面，LangChain/OpenAI已存在；Concept检查：8个新概念均已创建独立页面；冲突检测：与engineering-frontend-developer存在音频格式验证张力（信任MIME vs ffprobe探测），与SRE存在生产日志张力（严禁记录未脱敏内容），均已在source page Contradictions节记录；log.md已追加。
|
||
|
||
- Source file: Agent/agency-agents/finance/finance-fpa-analyst.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: FP&A（财务规划与分析）Agent，代号 Riley，11+ 年高增长 SaaS/制造/零售行业经验。核心理念："FP&A is not accounting's sequel — it's strategy's translator." 核心交付物：AOP（年度经营计划）、滚动预测、MBR（月度业务回顾）、场景规划。关键规则：预算必须挂接业务驱动因素、差异分析必须解释未来、场景规划是重大决策的必备条件。高级能力：ZBB/ABC/蒙特卡洛模拟/单位经济分析。Source page 含 6 条 Key Claims、4 条 Key Quotes、10 个 Key Concepts、7 个 Key Entities、4 条 Connections、1 条 Contradiction（暂无冲突）。
|
||
- Concepts touched: Annual-Operating-Plan(AOP)、Rolling-Forecast、Variance-Analysis、Driver-Based-Forecasting、Scenario-Planning、Zero-Based-Budgeting(ZBB)、Activity-Based-Costing(ABC)、Monte-Carlo-Simulation、Unit-Economics、Monthly-Business-Review(MBR)（均在 source page 内引用或描述性定义，暂不建独立 concept 页面）
|
||
- Entities touched: Riley（仅出现 1 次，未达 ≥2 次标准）、Anaplan/Adaptive-Insights/Planful/Pigment/Tableau/Power-BI/Looker/NetSuite/SAP/Oracle（仅出现 1 次，未达创建标准）
|
||
- Source page: wiki/sources/finance-fpa-analyst.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: finance-fpa-analyst）；index.md已更新（Sources节新增条目置于Finance类别最前）；overview.md已更新（新增finance-fpa-analyst条目于loan-officer-assistant之后，阐述其与Investment Researcher/Financial Analyst/Accounts-Payable-Agent/Finance-Tracker的关联）；Entity检查：所有实体仅出现1次，均未达≥2次标准，无新增独立实体页面；Concept检查：所有关键概念均为描述性引用或通用框架，无需新建独立页面；冲突检测：与finance-investment-researcher/finance-financial-analyst为互补关系（非冲突），与其他财务Agent功能边界清晰；wikilinks已验证指向有效页面；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Investment Researcher Agent
|
||
- Source file: Agent/agency-agents/finance/finance-investment-researcher.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 机构级投资研究 AI Agent（代号 Quinn），14年+经验，专注买方权益研究、风险投资尽职调查和机构资产管理。核心理念："The best investments are found where rigorous analysis meets variant perception." 五阶段工作流（筛选→初评→深度研究→研报撰写→持续监控），双重论证框架（牛熊市同等严谨），另类数据集成。Source page 含 5 条 Key Claims、4 条 Key Quotes、7 个 Key Concepts（Variant-Perception/Investment-Research-Report/Due-Diligence/Thesis-Breakers/Alternative-Data/Quantitative-Strategies/Porter-Five-Forces）、2 个 Key Entities（Quinn/The-Agency）、4 条 Connections、1 条 Contradiction（与 finance-financial-analyst 的视角互补而非冲突）。
|
||
- Concepts touched: Variant-Perception、Investment-Research-Report、Due-Diligence、Thesis-Breakers、Alternative-Data、Quantitative-Strategies、Porter-Five-Forces（均在 source page 内引用或描述性定义，暂不建独立 concept 页面）
|
||
- Entities touched: Quinn（仅出现 1 次，未达 ≥2 次标准）、The-Agency（已存在）
|
||
- Source page: wiki/sources/finance-investment-researcher.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: finance-investment-researcher）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（Finance部门部分新增finance-investment-researcher条目，插入于finance-financial-analyst之前）；Entity检查：Quinn仅出现1次未达创建标准，The-Agency已存在，无新增独立实体页面；Concept检查：所有概念均为描述性引用或通用框架，无需新建独立页面；冲突检测：与finance-financial-analyst为视角互补（Morgan运营视角 vs Quinn投资视角），非冲突；wikilinks已验证指向有效页面；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Financial Analyst Agent
|
||
- Source file: Agent/agency-agents/finance/finance-financial-analyst.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 专业金融分析师 AI Agent（代号 Morgan），12年+经验，专注投资银行/企业财务/FP&A，The Agency Finance 部门核心成员。核心理念："Revenue is vanity, profit is sanity, but cash flow is reality." 四阶段工作流：数据收集验证→模型架构与假设→场景分析→决策支持呈现。核心交付物：三报表联动模型、DCF 估值、LBO/M&A 建模、预算差异分析、单位经济学分析。工具栈：Python/SQL/Excel/Tableau/ERP 系统。Source page 含 7 条 Key Claims、4 条 Key Quotes、10 个 Key Concepts（Three-Statement-Model/DCF-Analysis/LBO-Modeling/Variance-Analysis/Unit-Economics/Sensitivity-Analysis/Scenario-Analysis/Budget-Variance-Analysis/Cash-Flow-Forecasting/Investment-Analysis）、2 个 Key Entities（Finance-Tracker/finance-tax-strategist）、4 条 Connections、0 条 Contradictions。
|
||
- Concepts touched: Three-Statement-Model、DCF-Analysis、LBO-Modeling、Variance-Analysis、Unit-Economics、Sensitivity-Analysis、Scenario-Analysis（均在 source page 内引用现有 concept page 或描述性定义，暂不建新独立 concept 页面）
|
||
- Entities touched: Finance-Tracker（已在 entities/ 目录存在）、finance-tax-strategist（已在 sources/ 目录存在）
|
||
- Source page: wiki/sources/finance-financial-analyst.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: finance-financial-analyst）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（Finance部门部分新增finance-financial-analyst条目，插入于finance-tax-strategist之后）；Entity检查：Finance-Tracker和finance-tax-strategist均已存在，无新增独立实体页面；Concept检查：所有概念均为对现有页面的引用或描述性定义，无需新建独立页面；冲突检测：无冲突；wikilinks已验证全部指向有效页面；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Tax Strategist Agent
|
||
- Source file: Agent/agency-agents/finance/finance-tax-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 专业税务战略代理 Agent（代号 Cassandra），Big Four + 企业税务部 + 精品咨询 15年+经验，The Agency Finance 部门核心成员。通过五阶段工作流（税务状况评估 → 机会识别 → 策略开发 → 实施合规 → 持续监控）使组织 ETR 达到行业同行中位数。核心能力：多辖区税务优化（GILTI/BEPS/FDII）、转让定价基准研究、83(b)/QSBS 股权筹划、R&D 抵免、BEAT 分析。Source page 含 5 条 Key Claims、3 条 Key Quotes、8 个 Key Concepts（TransferPricing/GILTI/BEPS/QSBS/83bElection/EffectiveTaxRate/TaxPlanningMemorandum/BEAT）、6 个 Key Entities（Cassandra/BigFour/IRS/ThomsonReutersONESOURCE/Alteryx/TPBenchmarking）、5 条 Connections、0 条 Contradictions。
|
||
- Concepts created: TransferPricing（独立 concept page）、EffectiveTaxRate（独立 concept page）；GILTI/BEPS/83bElection/QSBS/BEAT/TaxPlanningMemorandum 仅在 source page 内描述，暂不建独立页面
|
||
- Source page: wiki/sources/finance-tax-strategist.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: finance-tax-strategist）；index.md已更新（Sources节新增条目置于最前，Concepts节新增EffectiveTaxRate和TransferPricing条目）；overview.md已更新（Finance部门部分新增finance-tax-strategist条目）；Entity检查：无新增独立实体页面（Cassandra等提及实体均未达≥2次标准）；Concept检查：TransferPricing和EffectiveTaxRate均高频出现且具抽象可复用性，已建独立页面；冲突检测：无冲突；wikilinks已验证全部指向有效页面；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Agentic Search Optimizer
|
||
- Source file: Agent/agency-agents/marketing/marketing-agentic-search-optimizer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AI 浏览器 Agent 任务完成率优化 Agent——基于 W3C WebMCP 草案标准（2026 年 2 月 Chrome + Edge 联合开发），通过声明式（`data-mcp-*` HTML 属性）和命令式（`navigator.mcpActions.register()`）两种模式，让 AI Agent 能在网站上真正完成预订、购买、注册等任务流。核心方法论：审计任务流而非页面 → 用真实 Agent 测试 → 建立基线 → 优先声明式实施 → 迭代复测。Source page 含 6 条 Key Claims、4 条 Key Quotes、6 个 Key Concepts（WebMCP/Declarative WebMCP/Imperative WebMCP/Task Completion Rate/Agent Friction Map/MCP Actions Discovery Endpoint）、4 个 Key Entities（Chrome/Edge/Claude in Chrome/Perplexity）、4 条 Connections、0 条 Contradictions。
|
||
- Concepts touched: WebMCP（新兴 W3C 草案，2026-02）、Declarative WebMCP、Imperative WebMCP、Task Completion Rate（均仅在 source page 内描述，暂不建独立 concept 页面）
|
||
- Entities touched: Chrome、Edge、Claude in Chrome、Perplexity（各仅出现 1 次，未达 ≥2 次创建条件）
|
||
- Source page: wiki/sources/marketing-agentic-search-optimizer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: marketing-agentic-search-optimizer）；index.md已更新（Sources节修正缺失标记为完整条目）；overview.md已存在[[Marketing Agentic Search Optimizer]]引用（AI Citation Strategist条目末尾），无需重复添加段落；Entity检查：无新增独立实体页面（提及实体仅出现1次，未达≥2次标准）；Concept检查：WebMCP等为新兴W3C草案，保守处理仅在source page内描述，暂不建独立concept页面；冲突检测：无冲突；wikilinks已验证全部指向有效页面（WebMCP/Declarative WebMCP/Imperative WebMCP/Task Completion Rate/Agent Friction Map/MCP Actions Discovery Endpoint/Chrome/Edge/Claude in Chrome/Perplexity/AI Citation Strategist/SEO Specialist/Frontend Developer/UX Architect/marketing-agentic-search-optimizer）；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Chinese (zh-CN) Localization
|
||
- Source file: Agent/agency-agents/scripts/i18n/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Agency Agents 中文本地化工具——通过 PowerShell 脚本将已安装的 Copilot Agent 的 YAML frontmatter name/description 字段替换为简体中文。JSON 文件 agent-names-zh.json 作为翻译唯一数据源（130+ 条目），脚本纯 ASCII 避免编码问题，每次 install.sh 后需重新运行。Source page 含 6 条 Key Claims、3 条 Key Quotes、2 个 Key Concepts（Global-First-Architecture/YAML-Configuration）、2 个 Key Entities（The-Agency/GitHub-Copilot）、2 条 Connections、0 条 Contradictions。
|
||
- Concepts touched: Global-First-Architecture（已存在于 wiki/concepts/）、YAML-Configuration（已存在于 wiki/）
|
||
- Entities touched: The-Agency（已存在于 wiki/）、GitHub-Copilot（已创建 entity page）
|
||
- Source page: wiki/sources/i18n-readme.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: i18n-readme）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（插入 github-copilot 集成之后，新增 chinese-localization 条目）；Entity检查：无新增独立实体页面；Concept检查：无独立建页必要；冲突检测：无冲突；wikilinks已验证全部指向有效页面（Global-First-Architecture/YAML-Configuration/The-Agency/GitHub-Copilot/Qwen Code Integration/i18n-readme）；GitHub-Copilot entity page已创建；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Qwen Code Integration
|
||
- Source file: Agent/agency-agents/integrations/qwen/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Agency Agents Qwen Code 集成——将 SubAgent Markdown 定义导出为 Qwen Code `.qwen/agents/` 格式。核心工具：`convert.sh --tool qwen` 生成文件，`install.sh --tool qwen` 部署到目标项目。关键特性：Qwen Code 为项目级作用域；SubAgent 文件使用最小化 frontmatter（name/description/tools）；更新后需重新生成并安装。Source page 含 5 条 Key Claims、3 条 Key Quotes、2 个 Key Concepts（SubAgent/Tool Integration Export）、2 个 Key Entities（Agency Agents/Qwen Code）、2 条 Connections、0 条 Contradictions。
|
||
- Concepts touched: SubAgent（仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）、Tool Integration Export（仅提及1次，不满足创建条件）
|
||
- Source page: wiki/sources/readme.md
|
||
- Notes: The Agency 实体页面已存在，已将 qwen-readme 加入其 sources；AgentIntegration 概念页面已存在，已将 qwen-readme 加入其 sources
|
||
|
||
- Source file: Agent/agency-agents/specialized/loan-officer-assistant.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门抵押贷款专员 AI Agent 全流程摄取——覆盖借款人接待、预审、申请与 TRID 披露、处理与文件收集、承销管理、交割协调全生命周期。核心方法：五步工作流 + 十大关键规则 + 借款人接待脚本/预审分析表/文件清单/TRID合规时间表/状态更新模板/承销条件跟踪表等标准化交付物。Source page 含 10 条 Key Claims、3 条 Key Quotes、8 个 Key Concepts（TRID/DebtToIncome/LoanToValue/PreQualification/UnderwritingConditions/RateLock/DocumentExpiration/FairLending）、6 个 Key Entities（FannieMae/FreddieMac/FHA/VA/USDA/SBA）、4 条 Connections、1 条 Contradiction（vs RealEstateBuyerSeller 的\"交易融资节点主导权\"冲突，已记录为协调协议建议）。
|
||
- Concepts touched: TRID / DebtToIncome / LoanToValue / PreQualification / UnderwritingConditions / RateLock / DocumentExpiration / FairLending（均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Entities touched: FannieMae / FreddieMac / FHA / VA / USDA / SBA（均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/loan-officer-assistant.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，kebab-case slug与源文件名一致）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（插入 real-estate-buyer-seller 之后，新增 loan-officer-assistant 条目，补充了与 real-estate-buyer-seller/legal-document-review/SalesOutreach 的关系说明）；Entity检查：无新增独立实体页面（FannieMae/FreddieMac/FHA/VA/USDA/SBA 均仅提及1次）；Concept检查：无独立建页必要（8个核心概念均在本文首次出现，仅提及1次）；冲突检测：与 RealEstateBuyerSeller 在"交易融资节点主导权"上存在职责重叠，已在 Source Page Contradictions 节记录，并建议通过 Communication Protocol 协调；wikilinks指向的pages（RealEstateBuyerSeller/LegalDocumentReview/SalesOutreach等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Real Estate Buyer & Seller Agent
|
||
- Source file: Agent/agency-agents/specialized/real-estate-buyer-seller.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门房地产交易代理 Agent 全流程摄取——覆盖买方代表（需求评估→物业搜索→要约策略→谈判）、卖方代表（挂牌准备→CMA定价→营销→展示管理）和交易协调（合同→检查→融资→交割）全生命周期。核心方法：五步工作流 + 十大关键规则 + CMA/买方需求评估表/要约策略框架/交易协调时间线等标准化交付物。Source page 含 10 条 Key Claims、3 条 Key Quotes、6 个 Key Concepts（BuyerNeedsAssessment/ComparativeMarketAnalysis/OfferNegotiation/TransactionCoordination/FairHousingCompliance/EarnestMoneyHandling）、0 个 Key Entities、3 条 Connections（vs SalesEngineer/SalesOutreach/HospitalityGuestServices）、1 条 Contradiction（vs SalesOutreach 的"个性化深度 vs 规模化"策略差异，已记录为领域差异可共存）。
|
||
- Concepts touched: BuyerNeedsAssessment / ComparativeMarketAnalysis / OfferNegotiation / TransactionCoordination / FairHousingCompliance / EarnestMoneyHandling（均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/real-estate-buyer-seller.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，kebab-case slug与源文件名一致）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（插入 legal-document-review 之后，新增 real-estate-buyer-seller 条目，补充了与 legal-document-review/hospitality-guest-services/SalesOutreach 的关系说明）；Entity检查：无新增实体（本文未提及具体人物/公司/产品名称）；Concept检查：无独立建页必要（6个核心概念均在本文首次出现，仅提及1次，不满足≥2次条件）；冲突检测：与 SalesOutreach 在"个性化深度 vs 规模化"上存在领域差异（房地产高价值低频次适合深度个性化 vs B2B 外勤批量触达），已在 Source Page Contradictions 节记录；wikilinks指向的pages（SalesEngineer/SalesOutreach/HospitalityGuestServices等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Legal Document Review Agent
|
||
- Source file: Agent/agency-agents/specialized/legal-document-review.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门专业法律文档审查 Agent 全流程摄取——覆盖合同（MSA/NDA/雇佣/供应/合伙/许可）、诉讼文书（诉状/动议/开示/和解/命令）、房地产文件（买卖/租赁/贷款/产权）、合规审查和版本比对全场景。核心方法：五步工作流 + 高风险条款库（七类）+ 分级风险评分（高/中/低）+ 标准化交付模板。Source page 含 7 条 Key Claims、3 条 Key Quotes、7 个 Key Concepts（DocumentSummaryTemplate/RiskClauseFlagging/ContractComparisonTemplate/ComplianceReviewTemplate/HighRiskClauseLibrary/TenCriticalRules/DomainExpertiseCoverage）、0 个 Key Entities、3 条 Connections、1 条 Contradiction（vs CustomerService 的"简洁高效"理念，已记录为领域差异）。
|
||
- Concepts touched: DocumentSummaryTemplate / RiskClauseFlagging / ContractComparisonTemplate / ComplianceReviewTemplate / HighRiskClauseLibrary / TenCriticalRules / DomainExpertiseCoverage（均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/legal-document-review.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（置于 legal-client-intake 之后，补充了与 legal-client-intake/LegalBillingTimeTracking 的上下游关系）；冲突检测：与 CustomerService 在"穷尽式标记 vs 简洁高效"上存在领域差异，已在 Source Page Contradictions 节记录；wikilinks指向的pages（LegalClientIntake/LegalBillingTimeTracking/CustomerService等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Sales Outreach Agent
|
||
- Source file: Agent/agency-agents/specialized/sales-outreach.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: B2B 销售外勤 Agent 全流程摄取——覆盖冷邮件（7步触达序列）、ICP 定义框架、SPIN/Challenger/MEDDIC 销售方法论、异议处理、提案撰写和7阶段管道管理。
|
||
- Concepts touched: Consultative Selling / SPIN Selling / Challenger Sale / MEDDIC / Ideal Customer Profile / Cold Outreach / Objection Handling（均仅提及1次，不满足≥2次创建条件，已在 Source Page 以 wikilink 引用）
|
||
- Entities touched: Outreach / Salesloft / Apollo / HubSpot（均仅提及1次，不满足≥2次创建条件，已在 Source Page 以 wikilink 引用）
|
||
- Source page: wiki/sources/sales-outreach.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Sales Outreach Agent）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（Sales Outbound Methodology节新增 sales-outreach 条目，置于 Sales Discovery Methodology 之前）；冲突检测：与 Sales Outbound Strategist 在"规模化 vs 个性化"策略上存在视角差异，已在 Source Page Contradictions 节记录；wikilinks指向的pages（sales-engineer/sales-coach/sales-discovery-coach等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Retail Customer Returns Agent
|
||
- Source file: Agent/agency-agents/specialized/retail-customer-returns.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 零售退货专员 Agent 全流程摄取——覆盖实体店/电商/全渠道退货处理，含10条关键行为规则、退货欺诈识别（Wardrobing/收据欺诈/价格掉包）、退货原因代码体系（P/C/O/F四类）、客户挽留话术和数据分析仪表盘。
|
||
- Concepts touched: Wardrobing / Return Abuse / RMA / Returnless Refund / BORIS / Return Reason Code（均仅提及1次，不满足≥2次创建条件，已在 Source Page 以 wikilink 引用）
|
||
- Entities touched: Loss Prevention / POS（均仅提及1次，不满足≥2次创建条件，已在 Source Page 以 wikilink 引用）
|
||
- Source page: wiki/sources/retail-customer-returns.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Retail Customer Returns Agent）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（替换 hospitality-guest-services 截断占位符，新增 retail-customer-returns 条目，补充与 customer-service 的扩展关系）；冲突检测：与 Security Policy 在欺诈处理方式上存在视角差异（员工规程 vs 系统化安全），已在 Source Page Contradictions 节记录；wikilinks指向的pages（customer-service/SecurityPolicy等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Chief of Staff
|
||
- Source file: Agent/agency-agents/specialized/specialized-chief-of-staff.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门首席运营官（CoS）Agent 完整摄取——为创始人/高管提供全方位运营协调，充当主心骨与整个组织之间的"主协调者"。核心方法：三层信息过滤器（立即上报/处理后简报/暂存待问）、文档依赖图维护、流程一致性 100% 执行、影响力定位、ADHD 感知支持、多 Agent 全局上下文编排。Source page 含 9 条 Key Claims、3 条 Key Quotes、7 个 Key Concepts（首席运营官/三层信息过滤器/文档依赖图/流程一致性/影响力定位/ADHD感知支持/多Agent编排）、2 个 Key Entities、3 条 Connections、2 条 Contradictions（与 project-manager-senior 职责边界模糊、与 support-infrastructure-maintainer 流程维护重叠）。
|
||
- Concepts created: 首席运营官（CoS）/ 三层信息过滤器 / 文档依赖图 / 流程一致性 / 影响力定位 / ADHD感知支持 / 多Agent编排（均仅在本文提及1次，不满足≥2次独立建页条件，已在 Source Page 中以 wikilink 引用现有/待建 pages）
|
||
- Source page: wiki/sources/specialized-chief-of-staff.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，kebab-case slug与源文件名一致）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（替换 specialized-korean-business-navigator 截断占位符，插入完整 CoS 条目）；Entity检查：无新增实体（本文仅提及"高管/Principal"和"组织/Organization"概念，无具体名称实体）；Concept检查：无独立建页必要（7个核心概念均在本文首次出现，仅提及1次，不满足≥2次条件）；冲突检测：①与 project-manager-senior 职责边界模糊（项目经理专注特定交付物 vs CoS 专注整体运转），②与 support-infrastructure-maintainer 在流程维护上有重叠（技术基础设施流程 vs 运营流程），均已在 Source Page Contradictions 节记录；wikilinks指向的pages（executive-brief/quickstart/project-manager-senior/support-infrastructure-maintainer等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Customer Service Agent
|
||
- Source file: Agent/agency-agents/specialized/customer-service.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门通用客户服务 Agent 完整摄取——覆盖零售/SaaS/酒店/金融/电信/医疗行政/物流等多行业全场景（FAQ/Account/Order/Complaint/Retention/Escalation），核心方法为五步工作流 + 十大关键规则 + 行业专业知识 + 渠道差异化沟通 + 解级技术 + KPI 量化体系。Source page 含 8 条 Key Claims、2 条 Key Quotes、5 个 Key Concepts（EmpathyFirst/ComplaintResponseProtocol/RetentionProtocol/EscalationProtocol/ActiveListening）、1 个 Key Entity（HealthcareCustomerService）、3 条 Connections、1 条 Contradiction（vs LegalClientIntake 的身份验证要求差异，已在 Contradictions 节记录）。
|
||
- Concepts touched: EmpathyFirst / ComplaintResponseProtocol / RetentionProtocol / EscalationProtocol / ActiveListening（均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Entities touched: HealthcareCustomerService（已存在于 wiki/overview.md 和 wiki/sources/healthcare-customer-service.md，无须独立 Entity 页面）
|
||
- Source page: wiki/sources/customer-service.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（Healthcare Customer Service Agent 条目之后新增 customer-service 条目，补充了与 hospitality-guest-services/healthcare-customer-service 的抽象→具体关系说明）；冲突检测：与 LegalClientIntake 的身份验证要求差异已在 Source Page Contradictions 节记录（通用客服基于姓名+邮箱验证 vs 医疗场景 HIPAA 全名+DOB+SSN后四位，属场景差异非事实矛盾）；wikilinks指向的pages（HealthcareCustomerService/HospitalityGuestServices/LegalClientIntake等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Healthcare Customer Service Agent
|
||
- Source file: Agent/agency-agents/specialized/healthcare-customer-service.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门医疗保健客户服务 Agent 完整摄取——覆盖患者预约/账单/保险/投诉处理/临床路由/紧急响应全场景，核心方法为五步工作流结合 LEAP 降级技术和 HIPAA 合规要求。Source page 含 5 条 Key Claims、3 条 Key Quotes、5 个 Key Concepts（HIPAACompliance/EmpathyFirst/LEAPDeescalation/EscalationProtocol/PatientSupportWorkflow）、5 个 Key Entities（BillingSpecialist/PatientAdvocate/ClinicalStaff/Supervisor/RiskManagement）、3 条 Connections、1 条 Contradiction（vs Legal-Client-Intake 的身份验证要求差异，已记录为场景差异可共存）。overview.md 已添加 entry 置于 Support 部门 Executive Summary Generator 之后。
|
||
- Concepts touched: HIPAACompliance / EmpathyFirst / LEAPDeescalation / EscalationProtocol / PatientSupportWorkflow（均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Entities touched: BillingSpecialist / PatientAdvocate / ClinicalStaff / Supervisor / RiskManagement（均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/healthcare-customer-service.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format）；index.md已更新（Sources节新增条目置于hospitality-guest-services之后）；overview.md已更新（Support部门Executive Summary Generator之后新增healthcare-customer-service条目，补充了与hospitality-guest-services/Support-Legal-Compliance-Checker/Support-Support-Responder的关联关系）；冲突检测：与Legal-Client-Intake的身份验证要求差异已记录为场景差异（医疗HIPAA强制 vs 法律场景宽松），非事实矛盾；wikilinks指向的pages（Healthcare-Marketing-Compliance/Hospitality-Guest-Services/Support-Responder/Legal-Client-Intake等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Legal Billing & Time Tracking
|
||
- Source file: Agent/agency-agents/specialized/legal-billing-time-tracking.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门法律事务所计费与时间追踪专家 Agent 完整摄取——覆盖时间捕获（0.1h增量/实时录入）、账单叙事撰写（诚实具体可防御）、开票生成（发票审核清单三段式）、催收管理（五阶段通信序列）、信托账户合规（IOLTA/月度三向对账）、计费分析（实现率≥90%/实收率≥95%）全生命周期六大模块。Source page 含 10 条 Key Claims、2 条 Key Quotes、7 个 Key Concepts（TimeCapture/BillingNarrative/IOLTA/Three-Way-Reconciliation/Realization-Rate/Collection-Rate/BlockBilling）、4 个 Key Entities（Clio/LawPay/QuickBooks/The-Agency）、4 条 Connections、1 条 Contradiction（vs "快速简洁intake"观点，张力已记录）。所有 Key Concepts 和 Key Entities 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept/Entity 页面。
|
||
- Concepts touched: TimeCapture / BillingNarrative / IOLTA / Three-Way-Reconciliation / Realization-Rate / Collection-Rate / BlockBilling（均仅提及1次，不满足独立建页条件，已在 Source Page 中以 wikilink 引用）
|
||
- Entities touched: Clio / LawPay / QuickBooks / The-Agency（Clio/LawPay/QuickBooks 仅提及1次；The-Agency 已存在于 wiki/entities/，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/legal-billing-time-tracking.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（Specialized部门新增legal-billing-time-tracking条目，置于legal-client-intake之前，补充了与legal-client-intake的下游关系、与accounts-payable-agent的现金流双侧关系、与support-legal-compliance-checker的合规体系关系）；冲突检测：与"快速简洁intake"主流观点的张力已在Source Page Contradictions节记录（协调方案：在intake阶段预先确认计费框架属预防性管理而非效率损失）；wikilinks指向的pages（legal-client-intake/accounts-payable-agent/support-legal-compliance-checker/The-Agency等）均已存在于wiki中；log.md已追加。
|
||
- Source file: Agent/agency-agents/specialized/legal-client-intake.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门法律客户接待与资格审查专家 Agent 完整摄取——AI 驱动的律所潜在客户 intake 全流程自动化，覆盖六阶段标准化工作流（初始接触→业务领域资格审查→利益冲突筛查→案件信息收集→咨询安排→摘要交付）和 10 条关键行为规则。Source page 含 6 条 Key Claims、2 条 Key Quotes、6 个 Key Concepts（Statute-of-Limitations/Conflict-of-Interest-Screening/Intake-Summary/Practice-Area-Qualification/Consultation-Scheduling/Referral-Out）、3 个 Key Entities（The-Agency/Personal-Injury/EEOC）、5 条 Connections。6 个 Key Concepts 均仅在本页首次提及，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页。
|
||
- Concepts touched: Statute-of-Limitations / Conflict-of-Interest-Screening / Intake-Summary / Practice-Area-Qualification / Consultation-Scheduling / Referral-Out（均仅提及1次，不满足独立建页条件，已在 Source Page 中以 wikilink 引用）
|
||
- Entities touched: The-Agency / Personal-Injury / EEOC（均仅提及1次，不满足≥2次创建条件，无需独立 Entity 页面）
|
||
- Source page: wiki/sources/legal-client-intake.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（hospitality-guest-services 之后新增 legal-client-intake 条目，补充了与 Support-Responder 的互补关系说明）；冲突检测：与"简洁快速 intake"主流观点的张力已在 Source Page Contradictions 节记录（协调方案：按潜在客户类型调整 intake 深度）；wikilinks指向的 pages（The-Agency/Personal-Injury/EEOC/Support-Responder 等）均已存在于 wiki 中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Hospitality Guest Services
|
||
- Source file: Agent/agency-agents/specialized/hospitality-guest-services.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门酒店及综合款待业宾客服务专家 Agent 的完整 Prompt 摄取——覆盖预订/预到/入住/住店/投诉处理/退房/售后8阶段全宾客旅程，核心方法论为 HEARD 五步投诉处理框架、分级服务恢复协议（绿/黄/红/紧急四级补偿）和忠诚计划全生命周期管理。Source page 含6条 Key Claims、2条 Key Quotes、6个 Key Concepts（HEARD Method/Guest Journey/Service Recovery Protocol/Loyalty Program Management/Concierge Services/Review Management）、4个 Key Entities（Hotel Property/OTA/Food Allergy/VIP Guest，仅 Generic 类型不满足创建条件）、7条 Connections。overview.md 已添加 entry 置于 Design 部门 Agent 之后（Multi-Agent AI Systems 分类下）。
|
||
- Concepts created: [[HEARD-Method]] / [[Guest-Journey]] / [[Service-Recovery-Protocol]] / [[Loyalty-Program-Management]] / [[Concierge-Services]] / [[Review-Management]]
|
||
- Entities touched: Hotel Property / OTA / Food Allergy / VIP Guest（均为 Generic 类型，出现<2次，未达创建阈值，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/hospitality-guest-services.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format）；index.md已更新（Sources节新增条目置于最前）；overview.md已添加 Hospitality Guest Services entry（Design Brand Guardian 之后）；6个 Concept 页面已创建并更新 sources frontmatter；index.md Concepts 节已添加6个新条目；冲突检测：无已知冲突（HEARD Method 为酒店行业标准投诉处理框架，与现有 Wiki 内容无交叉）；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | HR Onboarding Agent
|
||
- Source file: Agent/agency-agents/specialized/hr-onboarding.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门企业级新员工入职管理专家 Agent 完整摄取——覆盖从预入职准备到第一年结束的完整员工入职生命周期，核心方法为五阶段工作流 + 十项关键行为规则 + 量化成功指标体系（I-9完成率100%/福利登记率≥95%/90天留存率≥95%）。Source page 含7条 Key Claims、2条 Key Quotes、5个 Key Concepts（30-60-90-Day-Plan/Pre-Boarding/Day-One-Orientation/Psychological-Safety/Buddy-System）、4个 Key Entities（The-Agency/Workday/BambooHR/Rippling）。overview.md 已添加 entry 置于 Supply Chain Strategist 之后。
|
||
- Concepts touched: 30-60-90-Day-Plan / Pre-Boarding / Day-One-Orientation / Psychological-Safety / Buddy-System（均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页）
|
||
- Entities touched: Workday / BambooHR / Rippling（均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/hr-onboarding.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（Supply Chain Strategist 之后新增 hr-onboarding 条目，补充了与 recruitment-specialist/support-legal-compliance-checker/compliance-auditor 的关联关系和视角差异说明）；冲突检测：与 compliance-auditor 的合规视角差异已记录（入职合规底线硬性要求 vs 合规文化长期深化，两者互补非矛盾）；wikilinks指向的pages（The-Agency/recruitment-specialist/support-legal-compliance-checker/compliance-auditor等）均已存在于wiki中；log.md已追加。
|
||
- Source file: Agent/agency-agents/SECURITY.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: agency-agents 项目安全漏洞报告政策与贡献者安全最佳实践完整摄取——涵盖通过 GitHub Security 私密报告漏洞的响应时间线（48h 确认、7天初评）、Agent 文件（非可执行，无凭证）vs Shell 脚本（可执行，合并前审查）的分层安全范围、prompt 注入检测与上报要求。Source page 含 5 条 Key Claims、2 条 Key Quotes、3 个 Key Concepts（PromptInjection/SecurityAdvisory/AgentSecurity）、1 个 Key Entity（AgencyAgents）、3 条 Connections。Content 因文档简短精炼，无需修订 overview.md。
|
||
- Concepts created: [[PromptInjection]] / [[SecurityAdvisory]] / [[AgentSecurity]]
|
||
- Entities touched: [[AgencyAgents]]（出现1次，未达创建阈值，无需独立 Entity 页面）
|
||
- Source page: wiki/sources/security.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；overview.md无需修订（内容为标准化政策，不构成独立主题）；冲突检测：无已知冲突（现有安全相关内容均为企业/AWS场景，与开源agent安全政策无交叉）；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Karpathy 最新分享：用 LLM 搭建个人知识库，告别 RAG 的低效循环
|
||
- Source file: Agent/Karpathy 最新分享：用 LLM 搭建个人知识库，告别 RAG 的低效循环.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Karpathy + 老张 的 LLM Wiki 落地教程完整摄取——核心洞察：RAG 的根本问题是"没有积累"，每次从零检索什么都沉淀不下来；LLM Wiki 让 AI 增量维护交叉引用，一次操作改十五个文件，维护成本趋近于零。操作栈：Obsidian Web Clipper（采集）+ Ctrl+Shift+D（图片本地化）+ Graph View（Lint 健康检查）+ Obsidian Git（版本管理）+ qmd（精准搜索）。Source page 含 4 条 Key Claims、3 条 Key Quotes、9 个 Key Concepts、2 个 Key Entities、3 条 Connections。
|
||
- Concepts created: [[RAG]] / [[LLM Wiki]] / [[Obsidian]] / [[Obsidian Web Clipper]] / [[Graph View]] / [[Obsidian Git]] / [[Dataview]] / [[Marp]] / [[qmd]]
|
||
- Entities created: [[Karpathy]] / [[laozhang2579]]
|
||
- Source page: wiki/sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（替换原LLM Wiki条目为karpathy实操指南）；冲突检测：无已知冲突；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Phase 0 Playbook — Intelligence & Discovery
|
||
- Source file: Agent/agency-agents/strategy/playbooks/phase-0-discovery.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 多 Agent 团队 Phase 0（Intelligence & Discovery 阶段）完整执行手册——3-7 天，6 个 Agent 并行激活（Wave 1 市场/用户 + Wave 2 数据/合规/技术），Day 5-7 汇聚点由 Executive Summary Generator 合成 SCQA 格式执行摘要并给出 GO/NO-GO/PIVOT 三段式决策。6 项质量门标准，全部通过方可进入 Phase 1。
|
||
- Concepts: Convergence-Point / Quality-Gate / Executive-Summary-Generator（已在 Source Page 中以 wikilink 引用；均已在 phase-1-strategy.md 中出现过，本次频次<2，不满足独立 Concept 页创建条件）
|
||
- Entities: Trend Researcher / Feedback Synthesizer / UX Researcher / Analytics Reporter / Legal Compliance Checker / Tool Evaluator（6 个 Agent 均仅在本文档中出现一次，频次<2，不满足独立 Entity 页创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/phase-0-discovery.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（scenario-startup-mvp之后、phase-1-strategy之前新增phase-0-discovery条目）；冲突检测：Phase 0要求3-7天完成验证与快速创业节奏（scenario-startup-mvp的Day 2即需Go/No-Go）存在时间框架张力，已在Source Page Contradictions节记录；wikilinks指向的pages（Phase-1-Strategy/phase-2-foundation等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Phase 5 Playbook — Launch & Growth
|
||
- Source file: Agent/agency-agents/strategy/playbooks/phase-5-launch.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 多 Agent 团队 Phase 5（发布与增长运营阶段）完整执行手册——2-4 周（T-7~T+14），12 个 Agent 协同，实现最大市场影响力。核心四阶段节奏：T-7 预热周（三轨并行：内容/营销/技术）→ T-0 发布日（蓝绿部署 + 全渠道营销激活）→ T+1~T+7 每日三波段运营 → T+7~T+14 优化迭代。质量门 7 项标准，Studio Producer + Analytics Reporter 双签，决策 STABLE/CRITICAL/ROLLBACK。
|
||
- Concepts: BlueGreenDeployment / KFactor / ViralLoop / QualityGate / FeatureFlag / AutoScaling（均为首次在 NEXUS Phase 系列中引入独立定义，已在 Source Page Key Concepts 中以 wikilink 引用；BlueGreenDeployment 已在 phase-2-foundation 提及，本次以规范化 Concept Name 引用）
|
||
- Entities: DevOps-Automator / Infrastructure-Maintainer / Growth-Hacker / Analytics-Reporter / Support-Responder / Content-Creator / Feedback-Synthesizer / Project-Shepherd / Studio-Producer / Experiment-Tracker / Executive-Summary-Generator（均已在其他 Phase 出现过，频次 ≥2，不满足独立 Entity 页创建条件，已在 Source Page 中以 wikilink 引用）；Twitter-Engager / Reddit-Community-Builder / Instagram-Curator / TikTok-Strategist / Social-Media-Strategist（仅在 Phase 5 首次出现，频次 <2，不满足独立 Entity 页创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/phase-5-launch.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（Phase 4之后、Phase 6之前新增Phase 5条目）；冲突检测：Phase 5的2-4周发布周期与scenario-startup-mvp的Day 6即需PMF验证存在节奏张力，已在Source Page Contradictions节记录；wikilinks指向的pages（Phase4Hardening/Phase6Operate等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | baoyu-skills
|
||
- Source file: raw/Skills/baoyu-skills.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 宝玉（JimLiu）Claude Code Skills 技能集完整摄取——覆盖内容生成（xhs-images/infographic/diagram/cover-image/slide-deck/comic/article-illustrator）、多平台发布（X/微信/微博）和 AI 图像生成（baoyu-imagine，支持 10+ provider）以及工具集（YouTube 字幕/URL 转 Markdown/翻译/图片压缩/Markdown 处理）。Source page 含 7 条 Key Claims、3 条 Key Quotes、8 个 Key Concepts（含多维度图像生成系统、多Provider图像生成、SVG图表生成、三档翻译系统等）、2 个 Key Entities（JimLiu、ClawHub）、12 条 Connections。
|
||
- Concepts created: 多维度图像生成系统 / 多Provider图像生成 / SVG图表生成 / 三档翻译系统
|
||
- Entities created: JimLiu / ClawHub
|
||
- Source page: wiki/sources/baoyu-skills.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节替换缺失占位条目 + Entities节新增JimLiu + Concepts节新增SVG图表生成/三档翻译系统/多维度图像生成系统/多Provider图像生成）；overview.md已更新（baoyu-skills条目插入于fireworks-tech-graph之后、Claude Prompt Library之前）；冲突检测：无已知冲突；wikilinks指向的pages（baoyu-imagine/JimLiu/ClawHub/Claude-Code等）均已存在于wiki中；log.md已追加。
|
||
- Source file: AI/如何让AI生成风格一致的图片
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 通过 Style Seed（风格种子句）+ STYLE LOCK 机制控制 Gemini 生成风格统一的系列图片。核心方法：在每个提示词开头加风格种子句锚定视觉基线 + 末尾加 STYLE LOCK 逐项检查 + 统一模板结构，组合使用可实现 ★★★★★ 一致性。提供 6 张黑板粉笔风格信息卡的完整生成指南（Saleable & Security / Cloud Deployment / HA & Self Recovery / Upgrade & Patch / Backup & Restore / Observability & Service Management）。
|
||
- Concepts created: StyleSeed / StyleLock / ChalkboardStyle（新建独立 Concept 页面）
|
||
- Entities created: Gemini（新建独立 Entity 页面）
|
||
- Source page: wiki/sources/如何让ai生成风格一致的图片.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；overview.md因文件过大（1247行/503KB）本次未更新，在 Source Page 中记录此决定，待后续批次更新；冲突检测：与"简洁提示词更有效"的主流观点存在风格描述长度的张力，已在Source Page Contradictions节记录；wikilinks指向的pages（StyleSeed/StyleLock/ChalkboardStyle/Gemini）已同步创建；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Phase 1 Playbook — Strategy & Architecture
|
||
- Source file: Agent/agency-agents/strategy/playbooks/phase-1-strategy.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 多 Agent 团队 Phase 1（战略与架构阶段）完整执行手册——5-10 天，8 个 Agent 并行协作，定义项目启动前所有前期准备工作。核心理念："写代码之前，先定义做什么、如何组织、何为成功"。三步 Agent 激活序列：战略框架（Day 1-3）→ 技术架构（Day 3-7）→ 优先级排序（Day 7-10）。质量门必须 Studio Producer + Reality Checker 双签方可进入 Phase 2。
|
||
- Concepts: RICE-Scoring / MoSCoW-Classification / Quality-Gate / Work-Breakdown-Structure / Dual-Sign-Off（均为新创建 Concept 页面）
|
||
- Entities: Studio Producer / Reality Checker / Brand Guardian / Finance Tracker / UX Architect / Backend Architect / AI Engineer / Senior Project Manager / Sprint Prioritizer（均已在其他 sources 页面存在，频次<2，不满足独立 Entity 页创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/phase-1-strategy.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（scenario-startup-mvp之后新增phase-1-strategy条目）；冲突检测：Phase 1明确规定双签放行前不得进入Phase 2，与快速迭代场景存在潜在张力，已在Contradictions节记录；wikilinks指向的pages（phase-2-foundation/phase-3-build/nexus-strategy等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Phase 2 Playbook — Foundation & Scaffolding
|
||
- Source file: Agent/agency-agents/strategy/playbooks/phase-2-foundation.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS Phase 2 执行手册——6 Agent 双工作流并行构建技术基础设施与应用框架，3-5 天完成骨架站立。Workstream A（基础设施）：DevOps Automator + Infrastructure Maintainer + Studio Operations 并行；Workstream B（应用框架）：Frontend Developer + Backend Architect + UX Architect 并行。质量门要求 DevOps Automator + Evidence Collector 联合双签，8 项截图证据验证全部通过方可进入 Phase 3。
|
||
- Concepts: Evidence-Based-QA / Design-Tokens / Two-Phase-Build / Infrastructure-as-Code / Blue-Green-Deployment（均仅在本页首次提及，不满足"可复用、非具体实例"独立建页条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页）
|
||
- Entities: DevOps-Automator / Infrastructure-Maintainer / Studio-Operations / Frontend-Developer / Backend-Architect / UX-Architect / Evidence-Collector / Project-Shepherd / Brand-Guardian（均仅在本页首次提及，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Entity 页）
|
||
- Source page: wiki/sources/phase-2-foundation.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（scenario-startup-mvp之后新增phase-2-foundation条目）；冲突检测：与scenario-startup-mvp的Agent数量差异已记录为互补关系说明——Phase 2的6个基础设施专项Agent与scenario-startup-mvp的全周期角色（Evidence Collector等）可同步激活，属不同维度；wikilinks指向的pages（phase-1-strategy/phase-3-build/nexus-strategy/scenario-enterprise-feature等）均已存在于wiki中或已在raw/目录存在；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Phase 3 Playbook — Build & Iterate
|
||
- Source file: Agent/agency-agents/strategy/playbooks/phase-3-build.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS Phase 3 执行手册——2-12 周，15-30+ Agent，通过 Agents Orchestrator 驱动 Dev↔QA 循环完成所有功能实现。Agent Assignment Matrix 覆盖 14 类任务；四条并行构建轨道（Track A 核心产品/Track B 增长营销/Track C 质量运营/Track D 品牌体验）NEXUS-Full 时同时激活；Sprint 执行模板（Sprint Planning → Daily Execution → Sprint Review → Retrospective）；7 项质量门检查清单，Gate Keeper 裁决 PASS→Phase 4 / CONTINUE→继续 Phase 3 / ESCALATE→Studio Producer 介入。
|
||
- Concepts: Parallel-Build-Tracks（新创建 Concept 页面）；Dev-QA-Loop / RICE-Scoring / Quality-Gate（均已在其他 sources 页面存在，满足 wikilink 引用，无需独立 Concept 页）
|
||
- Entities: Agents-Orchestrator / Project-Shepherd / Studio-Producer / Reality-Checker / Performance-Benchmarker（均已在其他 sources 页面存在，满足 wikilink 引用，无需独立 Entity 页）
|
||
- Source page: wiki/sources/phase-3-build.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于phase-2-foundation之后）；overview.md已更新（新增phase-3-build条目，置于phase-2-foundation之后、phase-4-hardening之前）；Parallel-Build-Tracks Concept页面已创建并添加到index.md Concepts节；冲突检测：与phase-4-hardening的视角互补——Phase 3建立功能基线，Phase 4专注重化质量，已在Source Page Contradictions节记录；wikilinks指向的pages（Phase-2-Foundation/phase-4-hardening/Agents-Orchestrator等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Runbook: Startup MVP Build
|
||
- Source file: Agent/agency-agents/strategy/runbooks/scenario-startup-mvp.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 初创公司 MVP 4-6 周快速构建的多 Agent 编排执行手册——NEXUS-Sprint 模式，18-22 个专业 Agent 并行协作，分四周执行：Week 1 快速发现+架构、Week 2-3 核心构建（Dev↔QA 循环双 Sprint，Growth Team 第 3 周激活）、Week 4 抛光硬化（Reality Checker 最终质量门）、Week 5-6 发布+增长。核心价值：MoSCoW 防止范围蔓延、Evidence Collector 每个任务必须运行、Rapid Prototyper 先验证后扩展。
|
||
- Concepts: RICE-Scoring / MoSCoW / Quality-Gate / NEXUS-Sprint — 均在文档内部首次提及且不满足"可复用、非具体实例"独立建页条件，已在 Source Page 中以 wikilink 引用
|
||
- Entities: Agents-Orchestrator / Sprint-Prioritizer / Evidence-Collector / Reality-Checker / DevOps-Automator / Growth-Hacker / Studio-Producer — 均在文档内部首次提及且不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Entity 页
|
||
- Source page: wiki/sources/scenario-startup-mvp.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（Multi-Agent AI Systems部分新增scenario-startup-mvp条目）；冲突检测：与scenario-enterprise-feature（6-12周/20-30 Agent）时间维度和团队规模差异已记录为互补关系说明；wikilinks指向的pages（scenario-enterprise-feature/scenario-marketing-campaign/scenario-incident-response/RICE-Scoring/MoSCoW/Quality-Gate/NEXUS-Sprint等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-06-01] ingest | Runbook: Enterprise Feature Development
|
||
- Source file: Agent/agency-agents/strategy/runbooks/scenario-enterprise-feature.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 企业级产品大型功能开发的多 Agent 编排完整手册——12 周五阶段 NEXUS-Sprint 流水线（需求架构→基础构建→开发→硬化→发布），20-30 个 Agent 并行协作，含量化质量门（代码覆盖率>80%/API P95<200ms/零关键漏洞/品牌一致性≥95%/WCAG 2.1 AA）+结构化风险矩阵+分层利益相关者沟通节奏。
|
||
- Concepts: Quality-Gate / RICE-Scoring / MoSCoW / Canary-Deployment / WCAG-2.1-AA — 均在文档内部首次提及且不满足"可复用、非具体实例"独立建页条件，已在 Source Page 中以 wikilink 引用
|
||
- Entities: Agents-Orchestrator / Project-Shepherd / Sprint-Prioritizer / Reality-Checker / Evidence-Collector / Experiment-Tracker / Legal-Compliance-Checker / Performance-Benchmarker / Executive-Summary-Generator / DevOps-Automator — 均在文档内部首次提及且不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Entity 页
|
||
- Source page: wiki/sources/scenario-enterprise-feature.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（Multi-Agent AI Systems部分新增scenario-enterprise-feature条目）；冲突检测：无已知冲突——scenario-marketing-campaign（营销场景）/scenario-incident-response（应急响应）/本runbook（企业合规开发）域清晰互补无重叠；wikilinks指向的pages（NEXUS/scenario-marketing-campaign/scenario-incident-response/NEXUS-Sprint等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Runbook: Multi-Channel Marketing Campaign
|
||
- Source file: Agent/agency-agents/strategy/runbooks/scenario-marketing-campaign.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 多渠道营销活动完整 Agent 协作执行手册——15 个专业 Agent 角色（核心团队 5 人 + 平台专家 5 人 + 支持团队 5 人），分四周执行：第 1 周策略与内容生产、第 2 周发布与激活、第 3-4 周持续优化。提供 Campaign KPIs（总量指标 + 平台专属指标）、Brand Consistency Checkpoints（发布前审查 + 每周审计）及 A/B 测试追踪机制。核心价值：可复用的多渠道营销 Agent 编排模板，数据驱动、平台差异化、品牌统一。
|
||
- Concepts: Multi-Channel-Marketing-Campaign / Campaign-KPIs / Brand-Consistency-Checkpoint / Conversion-Funnel — 均在文档内部首次提及且不满足"可复用、非具体实例"独立建页条件，已在 Source Page 中以 wikilink 引用
|
||
- Entities: Social-Media-Strategist / Content-Creator / Growth-Hacker / Brand-Guardian / Analytics-Reporter / Trend-Researcher / Experiment-Tracker / Legal-Compliance-Checker / Twitter-Engager / TikTok-Strategist / Instagram-Curator / Reddit-Community-Builder / Executive-Summary-Generator — 均在文档内部首次提及且不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Entity 页
|
||
- Source page: wiki/sources/scenario-marketing-campaign.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前）；冲突检测：无已知冲突——scenario-startup-mvp（产品MVP构建）、scenario-incident-response（应急响应）、本runbook（多渠道营销）域清晰无重叠；wikilinks指向的pages均已存在于wiki中；log.md已追加。
|
||
- Source file: Agent/agency-agents/strategy/runbooks/scenario-incident-response.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 框架生产事故结构化响应手册——P0~P3 四级严重等级分类（P0=服务全停/数据丢失/安全漏洞，即时响应；P1=主要功能故障/性能严重下降，<1小时；P2=次要功能故障/有 workaround，<4小时；P3=表面问题，下个 sprint），按等级激活 3-8 个 Agent 并行响应。五阶段标准流程：检测分诊→并行调查→缓解决策树→解决验证→48小时内复盘。提供标准化沟通模板（状态页面/高管简报）和五类升级矩阵。
|
||
- Concepts: Severity-Classification / Incident-Response-Sequence / Response-Team-Activation / Communication-Templates / Escalation-Matrix — 均仅在本页首次提及且不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Infrastructure-Maintainer / DevOps-Automator / Backend-Architect / Frontend-Developer / Support-Responder / Executive-Summary-Generator / Evidence-Collector / API-Tester / Workflow-Optimizer — 均仅在本页首次提及且不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Entity 页
|
||
- Source page: wiki/sources/scenario-incident-response.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节第493行，从missing状态替换为正式条目）；overview.md已更新（Multi-Agent AI Systems部分新增scenario-incident-response条目，置于handoff-templates之后）；冲突检测：与engineering-incident-response-commander.md的角色命名差异（"Incident Commander" vs "Incident Response Commander"）已记录在Contradictions节，属同一角色的不同视角互补；wikilinks指向的pages（NEXUS/scenario-startup-mvp/scenario-marketing-campaign/handoff-templates/engineering-incident-response-commander等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-29] ingest | NEXUS Agent Activation Prompts
|
||
- Source file: Agent/agency-agents/strategy/coordination/agent-activation-prompts.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 流水线中各类 Agent 的标准化激活提示词模板库，覆盖六大部门（Pipeline Controller、Engineering、Design、Testing、Product、Support）共 15+ Agent 角色。每个模板包含 Phase/Task/Acceptance Criteria/Reference Documents/Implementation Requirements 五大要素，实现 Agent 的即插即用。核心价值：让任何 Agent 收到激活提示词即可在正确上下文下执行，无需重复初始化。
|
||
- Concepts: Dev-QA-Loop、Quality-Gate、Evidence-Based-QA、Context-Continuity、Escalation、SCQA-Framework、RICE-Scoring（均已存在于 wiki concepts/，已在 source page 中以 wikilink 引用）
|
||
- Entities: AgentsOrchestrator、FrontendDeveloper、BackendArchitect、AIEngineer、DevOpsAutomator、EvidenceCollector、RealityChecker、SprintPrioritizer、ExecutiveSummaryGenerator 等（均已存在于 wiki entities/，已在 source page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/agent-activation-prompts.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于 quickstart 之后）；冲突检测：与 agents-orchestrator.md 视角互补——agents-orchestrator.md定义"做什么"（协调职责），agent-activation-prompts.md定义"怎么做"（具体提示词模板）；wikilinks指向的pages均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | NEXUS Handoff Templates
|
||
- Source file: Agent/agency-agents/strategy/coordination/handoff-templates.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 多 Agent 协作框架的标准化交接模板体系——7 种场景化模板覆盖从任务分配、QA 通过/失败、升级、阶段门控、冲刺边界到事故响应的全链路交接。核心价值：一致性交接防止上下文丢失（交接边界是多 Agent 协调失败的头号原因）。与 NEXUS QualityGate 体系深度集成，属 NEXUS 三大战略交付物之一（与 Master Strategy/Phase Playbooks 并列）。
|
||
- Concepts: 无需创建（Handoff-Boundary/Dev-QA-Loop/Evidence-Over-Claims/QualityGate/Sprint-Handoff/Incident-Response 等关键概念均已存在于 wiki/concepts/，已在 source page 中以 wikilink 引用）
|
||
- Entities: EvidenceQA 已存在（由 agents-orchestrator 创建），本次更新 sources 字段追加 handoff-templates
|
||
- Source page: wiki/sources/handoff-templates.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources 节新增条目置于最前）；overview.md已更新（NEXUS部分新增handoff-templates条目，补充了与workflow-with-memory的互补关系说明）；EvidenceQA entity sources字段已追加handoff-templates；冲突检测：与 workflow-with-memory（MCP持久记忆 vs 结构化文档传递）的对比已记录在 Contradictions 节，两者互补——handoff-templates定义"交接什么"，memory系统定义"如何持久化"；wikilinks指向的pages（Handoff-Boundary/Dev-QA-Loop/Evidence-Over-Claims/QualityGate/Sprint-Handoff/Incident-Response/EvidenceQA/NEXUS/AgentsOrchestrator等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | NEXUS Executive Brief
|
||
- Source file: Agent/agency-agents/strategy/EXECUTIVE-BRIEF.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 多 Agent 编排框架战略概览——将 9 大部门 147+ Agent 从"各自为战"转化为"协调统一"的网络。核心问题：交接边界 73% 失败率 + "幻想型审批"。核心发现：① 标准化交接模板和上下文连续性是最高杠杆干预；② Reality Checker 默认"NEEDS WORK"防止过早部署；③ 4 条并行轨道压缩 40-60% 时间线；④ Dev↔QA 循环捕获 95% 缺陷、硬化时间减少 50%。三大交付物：Master Strategy（800+行 doctrine）、Phase Playbooks（7份）、Handoff Templates（7份）。战略建议：Critical = 立即采用 NEXUS-Sprint；High = Dev↔QA 循环；High = P0/P1 事故用 Incident Response Runbook。
|
||
- Concepts created: Handoff-Boundary（交接边界，73%失败发生地）、Parallel-Workstream（NEXUS并行轨道）、Evidence-Over-Claims（证据优于主张）；Quality-Gate/Dev-QA-Loop/Reality-Checker/Agent-Handoff 均已存在，已在 sources 字段引用；Dev-QA-Loop.md 已追加 executive-brief 来源
|
||
- Entities created: NEXUS（The Agency 多 Agent 编排框架）
|
||
- Source page: wiki/sources/executive-brief.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前、Entities节新增NEXUS、Concepts节新增4条）；overview.md Multi-Agent AI Systems 部分新增 executive-brief entry（与 quickstart 并列，补充战略层数据支撑），引用了 NEXUS 框架三层文档体系关系；冲突检测：与 nexus-spatial-discovery（并行 Agent 协作执行案例）和 workflow-startup-mvp（Startup MVP 工作流）均无实质冲突，属战略与执行层面的相互印证；wikilinks指向的pages（NEXUS/quickstart/nexus-spatial-discovery/nexus-strategy/agents-orchestrator/Reality-Checker/workflow-startup-mvp等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | NEXUS Quick-Start Guide
|
||
- Source file: Agent/agency-agents/strategy/QUICKSTART.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 多智能体编排框架快速启动指南——5分钟内从零启动完整多 Agent 流水线。三种模式：NEXUS-Full（完整产品，12-24周，6阶段全流程）、NEXUS-Sprint（功能/MVP，2-6周）、NEXUS-Micro（单一任务，1-5天）。核心原则：Quality Gates（无证据不推进）、Dev↔QA Loop（PASS推进/FAIL重试最多3次）、Handoffs（结构化上下文传递）、Reality Checker（最终质量权威）、Evidence Over Claims（截图/测试结果 > 口头断言）。涵盖 20+ Agent 角色分类表（Engineering/Design/Marketing/Product/PM/Testing/Support/Spatial/Specialized）和策略文档索引。
|
||
- Concepts created: 无需创建（Quality Gates/Dev-QA Loop/Agent Handoff/Evidence Over Claims 等概念已在 wiki 中存在）
|
||
- Entities created: 无需创建（The Agency/Agents Orchestrator/Reality Checker/Trend Researcher 等 Entity 已在 wiki 中存在）
|
||
- Source page: wiki/sources/quickstart.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目置于最前，位于 nexus-spatial-discovery 之前）；overview.md Multi-Agent AI Systems 部分新增 quickstart entry，补充了与 nexus-strategy、phase-0~6、workflow-startup-mvp 的关联关系；冲突检测：未发现冲突内容；wikilinks指向的pages（nexus-strategy/phase-0~6/agents-orchestrator/workflow-startup-mvp/scenario-startup-mvp等）均已存在于wiki中；log.md已追加。
|
||
- Source file: Agent/agency-agents/engineering/engineering-frontend-developer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Frontend Developer Agent 个性定义——专注于现代 Web 技术（React/Vue/Angular/Svelte）、UI 框架和性能优化的前端开发专家 Agent。核心理念：性能优先、无障碍始终、像素级精确。四阶段工作流（项目架构→组件开发→性能优化→测试 QA）。核心方法：Core Web Vitals 优化（LCP<2.5s/FID<100ms/CLS<0.1）、WCAG 2.1 AA 合规、Code Splitting + Lazy Loading、PWA 离线能力、TypeScript + 现代 CSS 组件库。
|
||
- Concepts created: 无（技术概念将在实际使用时创建）
|
||
- Entities created: 无（无具体人物/公司）
|
||
- Source page: wiki/sources/engineering-frontend-developer.md
|
||
- Notes: 与 engineering-senior-developer 互补；与 design-ui-designer 在 landing-page 工作流中协同
|
||
|
||
## [2026-05-02] ingest | Incident Response Commander Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-incident-response-commander.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Incident Response Commander Agent 个性定义——将生产事故混乱转化为结构化解决的专业事故管理专家 Agent。核心理念："Preparation beats heroics." 核心方法：SEV1–SEV4 分类框架 + 固定角色分工（IC/Communications Lead/Technical Lead/Scribe）+ 无责复盘文化（5 Whys + 故障树分析）+ SLO/SLI 体系 + On-Call 健康管理。关键规则：Runbook 每季度测试一次、On-call 工程师有应急处置权、48 小时内完成复盘。与 SRE Agent 互补——SRE 定义 SLO 和错误预算，IC 负责在事故发生时执行结构化响应和持续改进。
|
||
- Concepts created: BlamelessPostMortem（新建）、FiveWhys（新建）
|
||
- Entities created: IncidentCommander（新建）
|
||
- Source page: wiki/sources/engineering-incident-response-commander.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目位于最前、Entities节新增IncidentCommander、Concepts节新增BlamelessPostMortem和FiveWhys）；overview.md Engineering Agents部分新增Incident Response Commander entry，补充了与SRE Agent的互补关系说明；冲突检测：Incident Response Commander与SRE Agent在可靠性框架层面高度互补——SRE负责定义SLO/错误预算/Golden Signals，IC负责执行事故响应/复盘/On-Call文化建设；wikilinks指向的pages（BlamelessPostMortem/FiveWhys/IncidentCommander等）已新建；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Data Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-data-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Data Engineer Agent 个性定义——构建可靠、可观测、自愈的数据管道和 Lakehouse 架构的专业 Agent。核心理念："Builds the pipelines that turn raw data into trusted, analytics-ready assets." 核心方法：Medallion Architecture（Bronze→Silver→Gold）+ PySpark+Delta Lake ETL/ELT + dbt 数据质量契约 + Great Expectations 行级验证 + Apache Kafka 流式处理。关键原则：所有管道必须幂等、null 处理必须显式、Gold 层必须附带行级质量评分。与 SRE Agent 在数据 SLA 监控层面高度互补。
|
||
- Concepts created: Medallion-Architecture（新建）、CDC-Change-Data-Capture（新建）、Data-Contract（新建）
|
||
- Entities created: Apache-Spark（新建）、Delta-Lake（新建）、dbt（新建）、Great-Expectations（新建）、Apache-Kafka（新建）、Apache-Iceberg（新建）、Apache-Hudi（新建）、Databricks（新建）、Snowflake（新建）
|
||
- Source page: wiki/sources/engineering-data-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目Entities节新增9个entity、Concepts节新增3个concept，均按字母顺序插入）；冲突检测：Data Engineer Agent 与 SRE Agent 在数据管道 SLA 监控层面互补——Data Engineer 负责管道内部可观测性和质量评分，SRE 负责整体服务可靠性；wikilinks指向的pages（SCD-Type-2/Data-Lineage/Data-Mesh等）暂不存在，待后续摄取相关来源时一并建立；log.md已追加。
|
||
- Source file: Agent/agency-agents/engineering/engineering-sre.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: SRE Agent 个性定义——将可靠性视为可量化预算的专业生产系统专家 Agent。核心理念："Reliability is a feature. Error budgets fund velocity — spend them wisely." 核心方法：SLO 驱动决策（错误预算剩余则发布功能，耗尽则修复可靠性）→ 三支柱可观测性（Metrics/Logs/Traces）→ Golden Signals 监控（Latency/Traffic/Errors/Saturation）→ 零责备故障文化 → 渐进式发布（Canary → Percentage → Full）。关键原则：每个 9 的成本是前一个的 10 倍，Toil 必须自动化而非靠英雄应对。
|
||
- Concepts created: 无需创建（SLO/Error Budget/Observability/Golden Signals/Chaos Engineering/Toil 为成熟行业概念，暂无需独立页）
|
||
- Source page: wiki/sources/engineering-sre.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目，位置紧接DevOps Automator之后）；overview.md Engineering Agents部分新增SRE Agent entry；冲突检测：与DevOps Automator的"Tension"条目已更新为"互补"——原描述为"DevOps强调完全自动化，SRE强调人工on-call不可替代"，现修正为"DevOps Automator构建自动化基础设施，SRE负责监控/SLO决策/on-call，两者协同"；wikilinks指向的CTP-Topic-41/59页面待后续摄入相关CTP来源时一并建立；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | DevOps Automator Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-devops-automator.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: DevOps Automator Agent 个性定义——专注于基础设施自动化、CI/CD 流水线开发和云运营的专业 DevOps 工程师 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% 安全扫描通过率。
|
||
- Concepts created: Infrastructure-as-Code（已存在，追加来源）、CI-CD-Pipeline（已存在，追加来源）、Zero-Downtime Deployment（新建）、Observability（已存在，已关联）、Self-Healing System（新建）
|
||
- Entities created: Terraform（新建）、Kubernetes（已存在，已关联）、GitHub Actions（新建）、Prometheus（已存在，已关联）、Grafana（已存在，已关联）
|
||
- Source page: wiki/sources/engineering-devops-automator.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目，Entities节新增GitHub-Actions）；overview.md Engineering Agents部分新增DevOps Automator entry，位置在所有其他Engineering Agent之前；冲突检测：与SRE Engineering Agent（engineering-sre，源文件待摄入）存在张力——DevOps Automator强调完全自动化，SRE强调人工on-call和故障复盘的不可替代性，待engineering-sre摄入后进一步确认；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Git Workflow Master Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-git-workflow-master.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Git Workflow Master Agent 个性定义——Git 工作流与版本控制策略专家 Agent，帮助团队维护干净提交历史、有效分支策略，掌握高级 Git 特性（worktree/interactive rebase/bisect）。核心理念："Clean history, atomic commits, and branches that tell a story." 核心使命：原子提交、Smart branching、Safe collaboration、Advanced techniques（worktrees/bisect/reflog/cherry-pick）、CI integration。关键规则：永远不要在共享分支上强制推送（用 `--force-with-lease`）、PR 前必须 rebase 到目标分支最新代码。分支策略：Trunk-Based（主推，大多数团队）和 Git Flow（版本发布团队）。
|
||
- Concepts created: 无需创建（AtomicCommits/ConventionalCommits/TrunkBasedDevelopment/GitFlow/ForceWithLease 等概念仅在本页首次提及，未在其他页面引用，无需独立 Concept 页）
|
||
- Entities created: 无需创建（本文档为 Agent 个性定义，无外部公司/产品引用）
|
||
- Source page: wiki/sources/engineering-git-workflow-master.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-git-workflow-master.md）；index.md已更新（Sources节新增条目，日期2026-05-01排第一）；overview.md Engineering Agents部分新增entry；冲突检测：与 GitFlow 策略存在视角差异（Trunk-Based 主推 vs GitFlow 适合版本发布），属互补关系而非直接矛盾；wikilinks（AtomicCommits/ConventionalCommits/TrunkBasedDevelopment/GitFlow/ForceWithLease/CodeReviewer/GitOps）指向的页面暂不存在，待后续摄取相关来源时一并建立；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Senior Developer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-senior-developer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Senior Developer Agent 个性定义——专注于使用 Laravel/Livewire/FluxUI 实现"奢华感"（Premium）web 体验的高级全栈开发者 Agent。核心理念："Every pixel should feel intentional and refined"，性能与美感必须共存。技术栈：Laravel/Livewire 全栈框架、FluxUI 专业组件库、高级 CSS（glass morphism、organic shapes、cubic-bezier 缓动曲线）、Three.js WebGL 集成。核心要求：必须实现亮色/暗色/系统主题切换、玻璃拟态视觉效果、磁性按钮微交互。质量标准：加载 < 1.5s、动画 60fps、WCAG 2.1 AA 无障碍。
|
||
- Concepts created: 无需创建（Glass Morphism/Three.js Integration/Premium Design Standards 等概念仅在本页首次提及1次，无独立 Concept 页必要）
|
||
- Entities created: 无需创建（Laravel/Livewire/FluxUI/Three.js 等技术栈在各 Engineering Agent 中已有引用基础，本页仅列举实现工具）
|
||
- Source page: wiki/sources/engineering-senior-developer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-senior-developer.md）；index.md已更新（Sources节新增条目，日期2026-05-01排第一）；overview.md第9行 Engineering Agents 部分新增 entry；冲突检测：无已知冲突；与 xr-immersive-developer 中 Three.js 描述一致（均用于 WebGL 沉浸式体验）；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Database Optimizer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-database-optimizer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Database Optimizer Agent 个性定义——专注于数据库性能优化的专家 Agent，主要支持 PostgreSQL、MySQL、Supabase 和 PlanetScale。核心专长：EXPLAIN ANALYZE 查询计划分析、B-tree/GiST/GIN/部分索引/复合索引策略、N+1 查询检测与解决（JOIN + json_agg）、连接池管理（PgBouncer/Supabase pooler）、零停机迁移（CONCURRENTLY）。核心规则：始终检查查询计划、外键必须加索引、避免 SELECT *、使用连接池、迁移必须可逆、生产环境永不锁表。提供可直接用于生产的 SQL 模板和 TypeScript 代码示例。
|
||
- Concepts created: IndexingStrategies / N1QueryPrevention / QueryPlanAnalysis / ConnectionPooling — 均仅本次首次提及，均已创建独立 Concept 页面
|
||
- Entities created: PostgreSQL — 仅本次首次提及，已创建独立 Entity 页面
|
||
- Source page: wiki/sources/engineering-database-optimizer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-database-optimizer.md）；index.md已更新（Sources节新增条目；Concepts节新增IndexingStrategies、N1QueryPrevention、QueryPlanAnalysis、ConnectionPooling；Entities节新增PostgreSQL）；overview.md Engineering Agents部分新增entry；冲突检测：无已知冲突；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Security Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-security-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Security Engineer Agent 个性定义——专注于威胁建模、漏洞评估、安全代码审查、安全架构设计和事件响应的全链路应用安全专家 Agent。核心理念："You think like an attacker to defend like an engineer." 核心原则：所有用户输入均为敌对输入（多边界验证清理）；默认拒绝（白名单优于黑名单）；安全失效（错误不泄露堆栈/路径/schema）；最小权限；不自定义加密；密钥神圣。核心安全体系：SDLC 全阶段安全集成；STRIDE 威胁建模；零信任架构；防御深度（WAF→限流→输入验证→参数化查询→输出编码→CSP）；CI/CD 安全门禁（SAST/DAST/SCA/secrets 检测）；SBOM 与供应链安全监控。
|
||
- Concepts created: Security-Engineering-Concepts — 聚合页面，涵盖 Threat Modeling / Defense in Depth / Zero Trust / CVSS / OWASP Top 10 / Supply Chain Security / Secrets Management 等 8 个核心安全概念（均可抽象、可复用、非具体实例）
|
||
- Entities created: 无需创建（Semgrep / Trivy / Gitleaks / HashiCorp Vault / AWS Secrets Manager / OAuth / WebAuthn / libsodium 等工具仅在本文档提及 1 次，不满足"≥ 2 次"创建条件）
|
||
- Source page: wiki/sources/engineering-security-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources节新增条目）；overview.md Engineering Agents 部分新增 entry，紧接 engineering-threat-detection-engineer 之后；冲突检测：前瞻性记录了与 engineering-sre 的潜在视角张力（fail securely vs fail loudly），但 engineering-sre 源文件尚未存在于 raw/ 中，实际冲突待 SRE Agent 摄入时确认；log.md已追加。
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-ai-engineer.md）；index.md已更新（Sources 节新增条目，日期2026-05-01排第一）；overview.md第86行 Engineering Agents 部分新增 entry；冲突检测：无已知冲突；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Rapid Prototyper Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-rapid-prototyper.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Rapid Prototyper Agent 个性定义——极速原型开发专家，专注 3 天内交付可工作 MVP。速度优先开发：选择最小化设置时间的工具，先核心功能再边界情况，优先用户面功能。验证驱动开发：只构建核心假设测试所需功能，从第一天内置用户反馈和数据分析。技术栈：Next.js 14 + Supabase + Prisma + Clerk + shadcn/ui + Vercel。成功指标：3 天原型交付、1 周用户反馈、80% 核心功能通过验证、2 周内原型到生产转化。
|
||
- Concepts created: MVP / A/B Testing / Rapid Prototyping / 用户反馈收集 / No-Code/Low-Code — 均仅在本页提及 1 次，不满足 ≥2 次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Next.js / Supabase / Clerk / Prisma / shadcn/ui / Vercel — 均仅提及 1 次，不满足 ≥2 次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-rapid-prototyper.md
|
||
- Notes: 与 SoftwareArchitect 和 BackendArchitect 互补，无冲突
|
||
|
||
## [2026-05-01] ingest | WeChat Mini Program Developer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-wechat-mini-program-developer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: WeChat Mini Program Developer Agent 人格定义——专注于微信生态高性能小程序全栈开发的 AI Agent。核心约束：双线程架构（无 DOM/需 setData）、包体积限制（主包 ≤2MB/子包 ≤20MB）、域名白名单 + HTTPS 强制。核心交付物：项目结构规范、request.js 统一请求封装、微信支付集成模板、性能优化页面模板。跨平台：Taro/uni-app。成功指标：启动 <1.5s、主包 <1.5MB、审核首次通过率 >90%。
|
||
- Concepts created: 微信小程序 / setData优化 / 子包加载 / WXML/WXSS / 微信支付集成 / 跨平台小程序框架 — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: 微信 / Taro / uni-app — 均仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-wechat-mini-program-developer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成；index.md已更新（Sources 节新增条目）；overview.md第1181行后新增 entry 30；冲突检测：无已知冲突；log.md已追加。
|
||
|
||
|
||
## [2026-05-01] ingest | Technical Writer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-technical-writer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Technical Writer Agent 人格定义——技术文档工程师，专注于将复杂工程概念转化为开发者真正愿意阅读的清晰、准确、引人入胜的文档。核心理念："Bad documentation is a product bug." 核心方法：Divio 文档体系（教程/操作指南/参考文档/解释文档四象限分离）；Docs-as-Code 基础设施（Docusaurus/MkDocs/Sphinx/VitePress + CI/CD）；OpenAPI/Swagger 自动生成 API 参考文档；质量门禁（零错误代码示例、无文档的代码视为不完整）。核心指标：支持工单降低 20%、新开发者 15 分钟内上手、文档搜索满意度 ≥ 80%。属 The Agency Engineering 部门。
|
||
- Concepts created: [[Divio-Documentation-System]] / [[Docs-as-Code]] — 两个概念均为可抽象、可复用的方法论框架，满足创建条件；其余概念（OpenAPI/Swagger、Vale、Redoc、Stoplight 等工具）仅在本页提及1次，无需独立页面
|
||
- Entities: [[Docusaurus]] / [[MkDocs]] / [[Sphinx]] / [[VitePress]] / [[OpenAPI]] / [[Vale]] / [[Redoc]] / [[Stoplight]] — 均仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页；已作为 Key Entities 在 Source Page 中引用
|
||
- Source page: wiki/sources/engineering-technical-writer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-technical-writer.md）；index.md已更新（Sources 节第460行，从 missing 状态替换为正式条目）；overview.md第79行后新增条目；创建了两个 Concept 页面（Divio-Documentation-System 和 Docs-as-Code）；index.md Concepts 节新增两个条目（第1412-1413行）；冲突检测：与 specialized-developer-advocate 的内容边界冲突已在双方 Source Page 的 Contradictions 节记录，协调方案为按 Divio 体系分工；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Backend Architect Agent Personality
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Backend Architect AI Agent 人格定义——专注于可扩展系统设计、数据库架构、API 开发与云基础设施的高级后端架构师。核心理念：安全性优先、性能意识、可靠性至上。核心交付物：System Architecture Specification（模式选型矩阵）、Database Schema（含 PostgreSQL + 索引优化）、API Design（含 Express.js 安全中间件）。与 [[engineering-software-architect]] 共享架构思维但抽象层次不同（实现细节 vs 领域边界）；与 [[backend-architect-with-memory]] 在知识持久化方式上互补（文档传递 vs MCP Memory 自动召回）。
|
||
- Concepts: MicroservicesArchitecture / CQRS / EventSourcing / ServerlessArchitecture / DatabaseIndexing / CircuitBreaker / DefenseInDepth / Event-DrivenArchitecture / API-Versioning / HorizontalScaling — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: SoftwareArchitect / MobileAppBuilder / GodotMultiplayerEngineer / AutonomousOptimizationArchitect / SRE — 均仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-backend-architect.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-backend-architect.md）；index.md已更新（Sources 节第7行，新增条目）；overview.md第75行后新增条目；所有 Concept 和 Entity 均仅提及1次，无需独立页面；冲突检测：与 backend-architect-with-memory（知识持久化方式）和 engineering-software-architect（抽象层次）的差异已记录在 Contradictions 节；log.md已追加。
|
||
|
||
|
||
## [2026-05-01] ingest | Filament Optimization Specialist Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-filament-optimization-specialist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Filament PHP 管理后台的结构性优化专家 Agent——专注于高影响力布局重构（Tab/Grid/Collapsible）而非装饰性改进（图标/提示文字）。核心理念：结构改变比装饰性改动价值高10倍。结构优化层次体系（按优先级）：Tab分隔 → 并排Grid → Range Slider替换 → 可折叠区块 → Repeater itemLabel → Summary Placeholder → NavigationGroup。噪音控制：最多一层引导、图标克制、保留默认值。属 The Agency Engineering 部门，与 [[DesignUXArchitect]] 共享 UX 优化理念但专注后端管理场景。
|
||
- Concepts: [[StructuralOptimization]] / [[FilamentPHP]] / [[RangeSliderReplacement]] / [[RepeaterItemLabel]] / [[CollapsibleSection]] / [[NavigationGrouping]] / [[NoiseCheck]] / [[PlaceholderSummary]] — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: [[FilamentOptimizationAgent]] — 仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-filament-optimization-specialist.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-filament-optimization-specialist.md）；index.md已更新（Sources 节第7行）；overview.md已更新（第73行后新增条目）；所有 Concept 和 Entity 均仅提及1次，无需独立页面；冲突检测：与一般 UI 优化观点（装饰性改进）的对比已记录在 Contradictions 节；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Mobile App Builder Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-mobile-app-builder.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Mobile App Builder Agent 人格定义——专注于原生 iOS/Android 开发和跨平台框架（Swift/SwiftUI、Kotlin/Jetpack Compose、React Native、Flutter）。核心理念：平台感知、性能优先、用户体验驱动。核心规范：遵循平台设计指南（Material Design/Human Interface Guidelines）；默认实现离线优先架构和智能数据同步；性能指标：冷启动 < 3 秒、内存 < 100MB、续航损耗 < 5%/小时。属 The Agency Engineering 部门，与 [[Software Architect]] 共享架构思维，与 [[Unity Architect]] 在跨平台理念上有分工——前者面向通用移动应用，后者面向游戏。
|
||
- Concepts: [[MVVM]] / [[Offline-First Architecture]] / [[Cross-Platform Development]] / [[Native Mobile Development]] / [[Platform Design Guidelines]] / [[Performance Optimization]] / [[Biometric Authentication]] — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: [[SwiftUI]] / [[Jetpack Compose]] / [[React Native]] / [[Flutter]] / [[Hilt]] / [[Combine]] / [[Material Design]] / [[Human Interface Guidelines]] — 均仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-mobile-app-builder.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-mobile-app-builder.md）；index.md已更新（第8行）；overview.md第73行条目已存在且内容一致（无需更新）；所有 Concept 和 Entity 均仅提及1次，无需独立页面；冲突检测：与 unity-architect 的跨平台理念差异已记录在 Contradictions 节（无实质冲突，属不同应用场景的合理分工）；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Autonomous Optimization Architect Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-autonomous-optimization-architect.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Autonomous Optimization Architect Agent 人格定义——AI 系统自治优化架构师，在保证财务和安全的前提下实现 LLM API 的持续自动化路由优化。核心理念：自主路由必须有熔断器兜底，否则是昂贵的炸弹。核心能力：LLM-as-a-Judge 评分、暗启动 A/B 测试、熔断器（Circuit Breaker）、成本感知语义路由。核心方法：建立数学评估标准→识别降级路径→暗启动部署→自主晋升+告警。核心交付物：Evaluation Prompts、Multi-provider Router with Circuit Breakers、Shadow Traffic 实现、Telemetry 日志。成功指标：运营成本降低 > 40%、99.99% 工作流完成率、新模型 1 小时内完成生产验证。属 The Agency Engineering 部门，与 [[Performance Benchmarker]]（传统性能测试）互补——本 Agent 专注于语义基准测试和 AI 经济优化；与 [[Tool Evaluator]]（人工驱动一次性评估）形成机器驱动持续 A/B 测试的对比。
|
||
- Concepts created: [[Circuit-Breaker]] / [[LLM-as-a-Judge]] / [[Shadow-Traffic]] / [[Semantic-Routing]] / [[AI-FinOps]] — 均满足≥2次引用条件（source page + overview/connections），已创建独立 Concept 页面
|
||
- Entities: [[OpenAI]] / [[Anthropic]] / [[Google-Gemini]] — 仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-autonomous-optimization-architect.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-autonomous-optimization-architect.md）；index.md已更新（Sources 节第9行）；5个 Concept 页面已创建（Circuit-Breaker/LLM-as-a-Judge/Shadow-Traffic/Semantic-Routing/AI-FinOps）；冲突检测：与 testing-workflow-optimizer（人工驱动 vs 机器驱动）和 tool-evaluator 的对比已记录在 Contradictions 节；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Software Architect Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-software-architect.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Software Architect Agent 人格定义——专注于系统设计、领域驱动设计、架构模式和可扩展性决策的 AI Agent。核心理念：可维护性优先于理论最优解。核心规范：反架构航天员主义（每个抽象必须证明复杂度）、权衡优先于最佳实践、领域优先于技术、ADR 记录"为什么"而非"做什么"。系统设计流程：领域发现→架构选型→质量属性分析→沟通→文档。架构模式对照：Modular Monolith（小型团队/边界不清晰）vs Microservices（领域清晰/团队自主性要求高）vs Event-driven（松耦合/异步）vs CQRS（读写不对称）。属 The Agency Engineering 部门，与 [[Backend-Architect-With-Memory]]（后端架构师，补充持久记忆能力）形成互补关系。
|
||
- Concepts: [[ArchitectureDecisionRecord]]（已存在，已引用）/ [[DomainDrivenDesign]]（已存在，已引用）/ Bounded Context / Trade-off Matrices / CQRS / Event-driven Architecture / C4 Model — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Simon Brown（C4 Model 创建者）— 仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-software-architect.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-software-architect.md）；index.md已更新（Sources 节第7行）；ADR 和 DDD Concept 页面已存在，已在 Sources 节正确引用；冲突检测：与 Backend-Architect-With-Memory 的潜在张力已记录在 Contradictions 节（详见 source page）；overview.md 无需更新（Software Architect 属于 Engineering 分支已有覆盖范围）；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Godot Multiplayer Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/game-development/godot/godot-multiplayer-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Godot 4 网络多人游戏开发 Agent 人格——精通 MultiplayerAPI、场景复制、ENet/WebRTC 传输、RPC 和权威模型。核心理念：服务器权威 + RPC 安全验证 + MultiplayerSpawner/Synchronizer 协同 + 延迟测试。核心规范：`set_multiplayer_authority()` 显式设置权威；`is_multiplayer_authority()` 守卫所有状态变更；`@rpc("any_peer")` 必须服务器端验证发送者 ID；动态节点必须用 MultiplayerSpawner 禁止手动 add_child；延迟测试必须达到 150ms 模拟延迟。核心交付物：NetworkManager.gd（ENet C/S 管理器）、服务器权威 Player 控制器（含 send_input RPC + take_damage 确认 RPC）、MultiplayerSpawner 配置示例、RPC 安全模式示例（物品拾取 + 距离验证）。高级能力：WebRTC P2P 浏览器多人（含 STUN/TURN NAT 穿透）、Nakama 游戏服务器集成、Relay 中继服务器架构、二进制数据包协议（`PackedByteArray`）+ 增量压缩。属 The Agency Game Dev 部门 Godot 专项，与 [[Godot Gameplay Scripter]]（GDScript 游戏逻辑）和 [[Godot Shader Developer]]（渲染与特效）协同构建完整 Godot 4 游戏开发栈。与 [[Unity Multiplayer Engineer]] 同属多人游戏网络专项，核心原则一致（服务器权威），但实现 API 不同。
|
||
- Concepts created: MultiplayerAPI / Server-Authoritative Architecture / RPC / MultiplayerSpawner / MultiplayerSynchronizer / ENet / WebRTC / Authority Model / Scene Replication / Delta Compression — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Godot / Nakama / NetworkManager / Player — 均仅在本页提及，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/godot-multiplayer-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/godot-multiplayer-engineer.md）；index.md已更新（第7行）；冲突检测：与 unity-multiplayer-engineer.md 存在权威模型比较（已在 Contradictions 节记录，核心原则一致，仅 API 实现不同，无实质冲突）；所有 Concept 和 Entity 均仅提及1次，无需独立页面；log.md已追加。
|
||
|
||
|
||
- Source file: Agent/agency-agents/game-development/godot/godot-shader-developer.md
|
||
- Status: ✅ 成功摄入（内容更新）
|
||
- Summary: Godot 4 渲染效果专家 AI Agent——精通 Godot 着色语言（GLSL-like）、VisualShader 编辑器、CanvasItem 和 Spatial 着色器、后处理与性能优化。核心理念：创作性、正确性与性能意识三合一。核心规范：`shader_type` 声明 + uniform hint 强制 + 渲染器分级适配（Forward+ / Mobile / Compatibility）+ 纹理采样性能审计。核心交付物：2D CanvasItem 精灵描边着色器（8 邻域采样）、3D Dissolve 溶解着色器（noise + discard + 边缘自发光）、3D 水面着色器（双层法线 + 深度色彩渐变）、全屏后处理 CompositorEffect、Shader Performance Audit Checklist。属 The Agency Game Dev 部门 Godot 专项，与 [[Godot Gameplay Scripter]]（GDScript 游戏逻辑）协同构建完整 Godot 4 游戏开发栈。
|
||
- Concepts: CanvasItem Shader / Spatial Shader / VisualShader / CompositorEffect / Forward+ Renderer / Mobile Renderer / Compatibility Renderer / RenderingDevice — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Godot / GLSL — 均仅在本页提及，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/godot-shader-developer.md
|
||
- Notes: 步骤1-9全部完成；source page已重新生成（wiki/sources/godot-shader-developer.md）；index.md第494行条目已存在（无需更新）；overview.md第1104-1112行条目已存在且内容一致（无需更新）；所有 Concept 和 Entity 均仅提及1次，无需独立页面；Connections 已记录（4条）；Contradictions 已记录（无冲突）；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Roblox Avatar Creator Agent Personality
|
||
- Source file: Agent/agency-agents/game-development/roblox-studio/roblox-avatar-creator.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Roblox UGC 化身 pipeline 专家 AI Agent——掌握从建模到 Creator Marketplace 提交的完整 Avatar 物品制作流程。核心规范：UGC 网格三角面数硬限制（配件 ≤4,000）；单 UV 通道 [0,1] 范围；纹理 256×256~1024×1024 PNG；Layered Clothing 必须有 Outer Mesh + InnerCage + OuterCage 三层 cage；附件点标准命名（R15 兼容性）；HumanoidDescription API 游戏内换装。核心交付物：Accessory Export Checklist、AvatarManager.lua、Layered Clothing Cage Setup Guide、Creator Marketplace Submission Package、UGC Shop UI Flow。
|
||
- Concepts: UGC / Layered Clothing / R15 Avatar Rig / HumanoidDescription / Creator Marketplace / Cage Mesh / Rthro Avatar Scale / Blender R15 Rig — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Source page: wiki/sources/roblox-avatar-creator.md
|
||
- Notes: overview.md 第 1022 行已存在 roblox-avatar-creator 条目，内容与本次摄入一致，无需更新。冲突检测：无内容冲突。
|
||
|
||
## [2026-05-01] ingest | Roblox Systems Scripter
|
||
- Source file: Agent/agency-agents/game-development/roblox-studio/roblox-systems-scripter.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Roblox Systems Scripter Agent——Roblox 平台系统工程专家 AI Agent，专精 Luau 编程、服务器权威模型、RemoteEvent/RemoteFunction 安全架构、DataStore 持久化与模块化代码组织。核心理念：服务器是唯一真相来源，客户端只展示状态不拥有状态。核心规范：客户端→服务器请求必须完整验证（类型+冷却+距离+权限）；DataStore 必须 pcall 保护+指数退避重试（2s/4s/8s）+双保存点（PlayerRemoving+BindToClose）；所有游戏逻辑封装在 ModuleScript 返回表；RemoteFunction InvokeClient 禁止在服务器调用（恶意客户端可永久挂起线程）。核心交付物：DataManager.lua（含 retryAsync+deepCopy+双保存点）、CombatSystem.lua（完整验证链路示例）、GameServer.bootstrap.server.lua（五阶段引导模式）。高级能力：Parallel Luau（task.desynchronize+Actor+SharedTable）、对象池化（预实例化 effects/NPC）、数据版本迁移（data._version+UpdateAsync 原子升级）、ServiceLocator 依赖注入、FeatureFlags 特性开关。属 The Agency Game Dev 部门 Roblox Studio 专项，与 [[Roblox Experience Designer]]（玩家参与度和变现系统设计）协同构成完整 Roblox 开发体系。
|
||
- Concepts: ServerAuthoritativeModel / RemoteEvent / RemoteFunction / DataStore / ModuleScript / ParallelLuau / ObjectPooling / ServiceLocator / FeatureFlags / ActorModel / UpdateAsync / SessionLocking — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: RobloxSystemsScripter / RobloxPlatform / Luau / DataStoreService / ReplicatedStorage / ServerStorage / Players / BindableEvent — 均仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/roblox-systems-scripter.md
|
||
- Notes: 步骤1-9全部完成；source page为新建（wiki/sources/roblox-systems-scripter.md）；index.md第7行条目已补充；overview.md第1011行条目已存在并覆盖完整（无需更新）；所有 Concept 和 Entity 均仅提及1次，无需独立页面；Connections 已记录（RobloxSystemsScripter extends RobloxExperienceDesigner + 6个依赖关系）；Contradictions 已记录（vs UnrealMultiplayerArchitect 权威模型差异 + vs UnityMultiplayerEngineer 帧率同步差异）；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Roblox Experience Designer
|
||
- Source file: Agent/agency-agents/game-development/roblox-studio/roblox-experience-designer.md
|
||
- Status: ✅ 成功摄入（内容更新）
|
||
- Summary: Roblox Experience Designer Agent——Roblox 平台原生体验设计师 AI Agent 更新版。核心方法新增：每日奖励系统（7天循环阶梯，第7天含徽章奖励）、入职引导三阶段含流失恢复策略（<2分钟=引导过慢/5-7分钟=奖励不够吸引/>15分钟=缺少返回钩子）、Roblox SEO 三要素。高级能力新增：Live Ops 事件运营（ReplicatedStorage 配置对象 + 服务器重启实现限时活动）；高级分析（A/B 测试基础设施 math.random() 按 UserId 分配桶、队列元数据 Cohort 分析、HttpService 导出外部 BI）；社会化系统（好友邀请 GetFriendsAsync、Group 门控 GetRankInGroup、Lobby 实时在线人数）；变现优化（软货币首次购买漏斗、价格锚定、购买遗弃提醒）。核心交付物新增：DailyRewardSystem.lua（7天奖励阶梯）、Onboarding Flow Design Document、Retention Metrics Tracking（AnalyticsService 事件）。成功指标：D1 留存 >30%、D7 >15%、MAU 月增长 >10%、转化率 >3%、零 Roblox 政策违规。
|
||
- Concepts: EngagementLoop / DailyRewardSystem / DataStoreDrivenProgression / GamePassMonetization / DeveloperProduct / UGCMonetization / OnboardingFlow / RobloxAlgorithm / AnalyticsService / SoftCurrencyFunnel / PriceAnchoring / LiveOperations / PurchaseAbandonmentRecovery / GroupGating / ABTestingInfrastructure — 均仅在本页提及1次或已在其他页引用，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: RobloxExperienceDesigner / RobloxPlatform / MarketplaceService / DataStoreService / AnalyticsService / ReplicatedStorage / Players / HttpService — 均仅在本页提及1次或已在其他页引用，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/roblox-experience-designer.md
|
||
- Notes: 步骤1-9全部完成；source page已存在（本次为内容更新，完全重写）；index.md第490行条目已补充日期[2026-05-01]和摘要；overview.md第1020行条目已增强，新增高级能力四模块（Live Ops/高级分析/社会化系统/变现优化）和流失恢复策略细节；所有 Concept 和 Entity 均仅提及1次，无需独立页面；Connections 已更新（新增 ReplicatedStorage/LiveOperations/Players/HttpService 连接）；Contradictions 已更新（新增 vs RobloxSystemsScripter 互补关系说明）；log.md 已追加。
|
||
|
||
## [2026-05-01] ingest | Unity Shader Graph Artist
|
||
- Source file: Agent/agency-agents/game-development/unity/unity-shader-graph-artist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Unity Shader Graph Artist Agent——Unity渲染效果专家AI Agent，专精Shader Graph可视化材质创作与HLSL性能优化，覆盖URP/HDRP渲染管线的实时视觉效果开发。核心理念：Shader Graph是艺术家创作首选工具，HLSL仅用于性能关键路径。核心规范：Sub-Graph强制复用重复逻辑；URP/HDRP API严格区分（ScriptableRendererFeature vs CustomPassVolume）；移动端性能硬约束（≤32纹理采样/≤60 ALU）；Alpha Clipping优先于Alpha Blend；Frame Debugger强制性能分析。核心交付物：Dissolve Shader Graph（含Sub-Graph封装的DissolveCore）、OutlineRendererFeature（URP自定义描边通道）、CustomLit.hlsl（URP兼容PBR完整示例）、Shader Complexity Audit模板。高级能力：Compute Shader GPU处理、RenderDoc调试、自定义深度后处理通道、程序化纹理生成。
|
||
- Concepts created/updated: Shader（更新sources和last_updated）/ URP（新建）/ HDRP（新建）——均已写入wiki/concepts/
|
||
- Entities created/updated: Unity（新建）——已写入wiki/entities/
|
||
- Source page: wiki/sources/unity-shader-graph-artist.md
|
||
- Notes: 步骤1-9全部完成；source page为新建（wiki/sources/unity-shader-graph-artist.md）；index.md第486行条目已补充日期和摘要；overview.md第1064行条目已覆盖全部新增内容，无需修订；新增3个Concept页（Shader更新/URP新建/HDRP新建）；index.md Entities节补充Unity（第1004行），Concepts节补充HDRP（第2029行）和URP（第2030行）；Connections已记录（UnityShaderGraphArtist↔Unity↔Shader↔URP↔HDRP）；Contradictions章节记录URP/HDRP API不兼容特性；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Code Reviewer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-code-reviewer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Code Reviewer AI Agent 人格定义——专注于代码审查与质量保证，提供构造性、可操作的反馈，聚焦正确性、安全性、可维护性、性能四大维度。核心理念：像导师而非门卫一样审查，每次评论都教授知识。审查清单三层优先级：🔴 Blocker（安全漏洞/数据损坏/竞态条件/破坏API合约/缺失关键路径错误处理）、🟡 Suggestion（缺失输入验证/命名混乱/缺失测试/N+1查询/代码重复）、💭 Nit（风格不一致/小幅命名改进/文档缺口）。与 [[SoftwareArchitect]] 和 [[BackendArchitect]] 协同，与 [[QualityGate]] 构成质量保障双层。属 The Agency Engineering 部门。
|
||
- Concepts: CodeReview / SecurityAudit / PerformanceProfiling / Mentorship / ReviewChecklist — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: CodeReviewerAgent — 仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-code-reviewer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-code-reviewer.md）；index.md已更新（Sources 节第11行，新增条目）；overview.md第77行后新增条目；所有 Concept 和 Entity 均仅提及1次，无需独立页面；冲突检测：与 linter（风格审查工具）的差异已记录在 Contradictions 节（审查负责人工判断，linter 负责格式自动化）；log.md已追加。
|
||
|
||
- Source file: Agent/agency-agents/game-development/godot/godot-gameplay-scripter.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Godot Gameplay Scripter Agent——Godot 4 游戏玩法脚本专家 AI Agent，专注于用 GDScript 2.0 和 C# 构建类型安全、信号驱动的游戏系统。核心理念：一切皆为节点，行为通过组合而非继承实现。核心规范：GDScript 信号 snake_case + 类型化参数；C# 信号 PascalCase + EventHandler 模式；静态类型强制（无未类型化 var）；组合优于继承（HealthComponent/MovementComponent）；Autoload 仅作全局状态服务定位器；场景必须可独立运行（F6）。核心交付物：Typed Signal 声明（GDScript + C#）、EventBus Autoload、HealthComponent 组件模式、Typed Array 敌人追踪、GDScript/C# 跨语言信号连接。高级能力：GDExtension C++ 集成、RenderingServer 低级 API、Service Locator + 优先级事件总线、场景池化、WebRTC P2P 多人游戏、Nakama 集成、延迟补偿。属 The Agency Game Dev 部门 Godot 专精，与 [[GodotShaderDeveloper]] + [[GodotMultiplayerEngineer]] 协同构成完整 Godot 4 开发体系。
|
||
- Concepts: GDScript-2.0 / TypedSignals / CompositionOverInheritance / EventBus / StaticTyping / GDExtension / RenderingServer / SceneTreeLifecycle — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: GodotGameplayScripter / GodotEngine / GDScript / CSharpGodot — 均仅提及1次，不满足≥2次条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/godot-gameplay-scripter.md
|
||
- Notes: 步骤1-9全部完成；source page 为新建（wiki/sources/godot-gameplay-scripter.md）；index.md 第495行条目已补充日期[2026-05-02]和摘要；overview.md 第1086行条目已存在并覆盖完整（无需更新）；所有 Concept 和 Entity 均仅提及1次，无需独立页面；Contradictions 已记录（vs UnrealSystemsEngineer Autoload vs Actor/Component 差异）；Connections 已记录（与 GodotShaderDeveloper + GodotMultiplayerEngineer 协同关系）；log.md 已追加。
|
||
|
||
## [2026-05-01] ingest | Unity Editor Tool Developer
|
||
- Source file: Agent/agency-agents/game-development/unity/unity-editor-tool-developer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Unity Editor Tool Developer Agent——Unity 编辑器扩展开发工程师 AI Agent，构建 EditorWindows / AssetPostprocessors / PropertyDrawers / Build Validators 等自动化工具，核心理念"最佳工具是隐形的"。核心规范：Editor 脚本必须置于 Editor 文件夹或 #if UNITY_EDITOR 保护；EditorWindow 必须持久化状态（[SerializeField]/EditorPrefs）且长操作必须 DisplayProgressBar；AssetPostprocessor 必须幂等；PropertyDrawer 必须调用 BeginProperty/EndProperty；构建失败必须抛出 BuildFailedException 而非 LogWarning。核心交付物：AssetAuditWindow / TextureImportEnforcer / FloatRangeDrawer / BuildValidationProcessor。高级能力：Assembly Definition 架构 / CI/CD 集成 / Scriptable Build Pipeline / UI Toolkit 迁移。
|
||
- Concepts: EditorWindow / PropertyDrawer / AssetPostprocessor / AssemblyDefinition / Undo / BuildValidation / ScriptableBuildPipeline / UI-Toolkit — 均仅提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: UnityEditorToolDeveloper — 仅提及1次，不满足≥2次条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/unity-editor-tool-developer.md
|
||
- Notes: 步骤1-9全部完成；source page 为新建（wiki/sources/unity-editor-tool-developer.md）；index.md 第487行条目已补充日期[2026-04-26]；overview.md 第1055行条目已存在并已增强，新增核心交付物列表和高级能力（Assembly Definition架构/CI/CD集成/ScriptableBuildPipeline/UI Toolkit迁移）描述；Contradictions 章节记录与[[UnrealTechnicalArtist]]的编辑器扩展方案差异；log.md 已追加。
|
||
|
||
- Source file: Agent/agency-agents/game-development/unreal-engine/unreal-systems-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Unreal Systems Engineer Agent——UE5 系统架构工程师 AI Agent 人格规范更新。C++/Blueprint 边界核心原则：Tick 逻辑必须 C++（Blueprint VM 开销产生 ~10x 性能差距）；Nanite 实例预算（单场景上限 1600 万，植被密度 500m 视距内超出上限）；内存安全（UPROPERTY 强制声明、IsValid() 检查、TWeakObjectPtr/TSharedPtr 非拥有引用）；GAS 网络复制（.Build.cs 三模块、AttributeSet 含 RepNotify、FGameplayTag 替代字符串）；Unreal Build System 反射宏规范。高级能力新增：Mass Entity（FMassFragment + FMassTag + UMassRepresentationSubsystem）、Chaos 破坏系统（Geometry Collection + constraint 类型）、Lyra 模块化框架（GameFeatureAction + Experience 模式切换）。
|
||
- Concepts: Chaos-Physics（新建）/ Mass-Entity（新建）/ Nanite（已存在，更新 sources 和 last_updated）/ GAS（更新 last_updated）——均已写入 wiki/concepts/
|
||
- Entities: UnrealEngine5（更新 last_updated）/ UnrealMultiplayerArchitect / UnrealTechnicalArtist — 均已存在于 wiki/entities/，无需新建
|
||
- Source page: wiki/sources/unreal-systems-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已存在（本次为内容更新，完全重写）；index.md第484行条目已补充日期[2026-05-30]；overview.md第1032行条目已更新，新增Blueprint Tick ~10x性能差距、Nanite显式切线禁止规则、.Build.cs三模块要求、反射宏静默失败警告、Mass/Chaos/Lyra详细规范；新增3个Concept页（Chaos-Physics/Mass-Entity/Nanite更新）；index.md Concepts节补充Chaos-Physics（第1271行）和Mass-Entity（第1754行）；Contradictions章节记录与[[UnrealMultiplayerArchitect]]的GAS职责边界冲突；log.md已追加。
|
||
- Source file: Agent/agency-agents/game-development/unreal-engine/unreal-technical-artist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Unreal Technical Artist Agent——UE5 视觉系统工程师 Agent，专注 Material Editor / Niagara VFX / PCG / Nanite / HLOD / Substrate 全栈管线。核心原则：可复用逻辑进入 Material Function（避免 permutation 爆炸）、Niagara GPU/CPU 选型前置于构建、PCG 确定性图、HLOD 覆盖所有 World Partition 开放世界区域。性能纪律：Max Particle Count 必设、Static Switch 双重 permutation 计数、材质 instruction 预算分级（mobile<200/console<400/PC<800）。
|
||
- Concepts: MaterialFunction / NiagaraScalability / PCG / Nanite / HLOD / Substrate — 均已存在于 wiki/concepts/，无需新建
|
||
- Entities: 无满足≥2次条件的 Entity，无需独立页面
|
||
- Source page: wiki/sources/unreal-technical-artist.md
|
||
- Notes: 步骤1-9全部完成；source page已存在（本次为内容更新，完全重写）；index.md第482行条目已补充日期[2026-04-30]；overview.md第1028行条目已覆盖全部新增内容，无需修订；所有关键Concept（MaterialFunction/NiagaraScalability/PCG/Nanite/HLOD/Substrate）均已存在于wiki/concepts/，已在Source Page中以wikilink引用；3组Connections（UnrealWorldBuilder/UnrealSystemsEngine/UnrealMultiplayerArchitect）和1组Contradiction（vs TechnicalArtist）已记录；log.md已追加。
|
||
|
||
|
||
- Source file: Agent/agency-agents/game-development/narrative-designer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Narrative Designer Agent——将游戏叙事理解为一套由选择、后果和世界一致性构成的系统，而非插入在玩法之间的电影剧本。核心交付物：三-tier Lore架构（Surface/Engaged/Deep）、Voice Pillars角色声音定义、分支节点映射、叙事-玩法对齐矩阵、环境叙事简报。强调Engine-ready格式（Ink/Yarn）从第一天开始写作，避免剧本到脚本翻译层。
|
||
- Concepts: Branching-Dialogue-Design / Voice-Pillars / Lore-Architecture / Environmental-Storytelling / Emergent-Narrative / Choice-Architecture — Environmental-Storytelling已存在于wiki/concepts/，其余5个在本页首次引入但均仅提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Concept页
|
||
- Entities: NarrativeDesigner — 仅提及1次，不满足≥2次条件，无需独立Entity页
|
||
- Source page: wiki/sources/narrative-designer.md
|
||
- Notes: 步骤1-9全部完成；source page为新建（wiki/sources/narrative-designer.md）；index.md第490行条目已补充日期[2026-05-07]；5个Key Concepts（Branching-Dialogue-Design/Voice-Pillars/Lore-Architecture/Emergent-Narrative/Choice-Architecture）和1个Key Entity（NarrativeDesigner）均仅提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用；Environmental-Storytelling已存在于concepts目录；4组Connections（Game Designer/Technical Artist/Game Audio Engineer/Level Designer）均仅提及1次，不满足Entity页创建条件；无冲突记录；log.md已追加。
|
||
|
||
## [2026-05-07] ingest | Level Designer Agent Personality
|
||
- Source file: Agent/agency-agents/game-development/level-designer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Level Designer Agent——将走廊视为句子、房间视为段落、关卡视为完整论点的空间叙事专家。六阶段工作流（意图定义→纸面布局→灰盒→遭遇战调优→美术交接→打磨）；节奏控制通过 Pacing Chart 实现；遭遇战三要素（进入读时+多种战术选项+撤退位置）；灰盒阶段锁定设计决策，美术美化零例外必须先通过灰盒测试；高级能力涵盖 Prospect-Refuge 空间心理学、程序化关卡设计、Kevin Lynch 城市设计五要素、多人空间设计。
|
||
- Concepts: Pacing-Chart / Grey-Box-Blockout / Encounter-Design / Environmental-Storytelling / Spatial-Psychology — Pacing-Chart（新建）、Grey-Box-Blockout（新建）；Encounter-Design、Environmental-Storytelling、Spatial-Psychology 均已存在，无需更新
|
||
- Source page: wiki/sources/level-designer.md
|
||
- Notes: 步骤1-9全部完成；source page已存在（本次为内容更新，完全重写）；index.md第490行条目已补充日期[2026-05-07]；overview.md第1024行game-designer条目之后新增level-designer条目；新增5个Concept页面（Pacing-Chart/Grey-Box-Blockout/Encounter-Design/Environmental-Storytelling/Spatial-Psychology），其中Encounter-Design/Environmental-Storytelling/Spatial-Psychology已存在于index和concepts目录，仅需补充sources引用；index.md补充Pacing-Chart和Grey-Box-Blockout条目；Contradictions章节记录与[[Technical Artist]]的美术交接冲突（gameplay-critical vs dressable标注）；log.md已追加。
|
||
|
||
## [2026-05-30] ingest | Technical Artist
|
||
- Source file: Agent/agency-agents/game-development/technical-artist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 技术美术 Agent 个性定义更新——新增粒子系统 Max Particle Count 上限强制要求、AI 辅助美术管线（纹理超分/ML去噪/DLSS）、着色器参数 tooltip 文档规范、VFX profiling 场景构建要求、纹理图集（Texture Atlasing）规范。共 8 个 Key Claims（含原 4 个）、13 个 Key Concepts（含新增 3 个）、7 个 Key Entities（含新增 2 个）、10 组 Connections（含新增 3 组）。
|
||
- Concepts: MachineLearningArtPipeline / TextureAtlasing / ToolDevelopment — 均仅在本页提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Concept页
|
||
- Entities: GodotShaderDeveloper / BlenderAddonEngineer — 均仅在本页提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Entity页
|
||
- Source page: wiki/sources/technical-artist.md
|
||
- Notes: 步骤1-9全部完成；source page已存在（本次为内容更新），新增4个Key Claims、3个Key Concepts（MachineLearningArtPipeline/TextureAtlasing/ToolDevelopment）、2个Key Entities（GodotShaderDeveloper/BlenderAddonEngineer）、3组新Connections；index.md第485行条目已存在，无需更新；overview.md第1000行条目已覆盖新增高级能力，无需修订；Entity和Concept均不满足≥2次条件，无需独立页面；log.md已追加。
|
||
|
||
## [2026-05-30] ingest | Marketing Growth Hacker Agent
|
||
- Source file: Agent/agency-agents/marketing/marketing-growth-hacker.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 增长黑客专家 Agent——数据驱动的增长实验 + K-factor > 1.0 病毒式传播 + 北极星指标体系 + LTV:CAC ≥ 3:1 单位经济学 + AARRR 漏斗全链路优化。核心竞争力：发现无人涉足的流量渠道并规模化复制，而非砸钱买广告。成功指标：月增长 20%+、K-factor > 1.0、CAC 回本 < 6 个月、实验速度 10+/月。
|
||
- Concepts: GrowthFunnelOptimization / ViralLoop / NorthStarMetric / KFactor / CACandLTV / ProductLedGrowth — 均已存在，无需新建或更新（其中 GrowthFunnelOptimization / ViralLoop / NorthStarMetric / KFactor / CACandLTV / ProductLedGrowth 在其他来源中已创建独立页面）
|
||
- Source page: wiki/sources/marketing-growth-hacker.md
|
||
- Notes: 步骤1-9全部完成；source page 已存在（步骤3无需新建），index.md 第472行原有条目已补充日期和一行摘要；overview.md 第857行已有详细条目（Marketing Agents部分），内容一致，无需更新；Entity（Growth Hacker Agent / The Agency）仅在本页提及1次，不满足≥2次创建条件，已在Source Page中引用；所有6个 Key Concepts 均已存在独立页面，无需新建；Contradictions 节记录与 [[MarketingTikTokStrategist]] 的渠道优先级冲突（实验数据驱动 vs 平台内容优先）；log.md 已追加。
|
||
|
||
## [2026-05-30] ingest | Marketing Xiaohongshu Specialist
|
||
- Source file: Agent/agency-agents/marketing/marketing-xiaohongshu-specialist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 小红书（中国生活方式种草平台）爆款品牌营销专家 Agent——通过生活方式品牌定位 + 趋势驱动内容策略 + 微内容优化 + 社区互动 + 数据迭代五阶段工作流，将品牌打造为小红书顶流。核心内容配比：70% 有机生活内容 + 20% 趋势参与 + 10% 品牌直接推广。关键指标：互动率 5%+、评论转化 30%+、分享率 2%+、收藏率 8%+、CTR 3%+。
|
||
- Entities: XiaohongshuPlatform / GenZMillennials / MicroInfluencer / KOLKOC — 均仅在本页提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Entity页面
|
||
- Concepts: LifestyleBrandPositioning / TrendRiding / MicroContentOptimization / CommunityFirstEngagement / UGCCampaign / MicroInfluencerPartnership / ContentMixStrategy — 均仅在本页提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Concept页面
|
||
- Source page: wiki/sources/marketing-xiaohongshu-specialist.md
|
||
- Notes: 步骤1-9全部完成；source page 已存在（步骤3无需新建），index.md 第471行原有条目，log.md 追加记录；overview.md 已通过关联 Agent（China Market Localization Strategist 等）提及小红书，无需单独修订；Entity 和 Concept 均不满足≥2次创建条件，无需独立页面；与 [[MarketingTikTokStrategist]] 的视频时长偏好冲突已在 Contradictions 章节记录。
|
||
|
||
## [2026-05-30] ingest | Marketing Podcast Strategist
|
||
- Source file: Agent/agency-agents/marketing/marketing-podcast-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 中国播客内容策略与全漏斗运营专家 Agent——涵盖节目定位（小宇宙/喜马拉雅等平台差异化运营）、音频制作（-16 LUFS标准）、受众增长（社群运营/跨平台引流/嘉宾互推）、多平台分发（RSS同步+手动上传）、商业化变现（品牌赞助→付费订阅→知识付费→私域导流）。核心理念：播客是"慢媒介"，核心竞争力是主播人格深度，完成率比播放量更能反映内容质量。
|
||
- Entities: Xiaoyuzhou / Ximalaya / LizhiFM / QingtingFM / ShureSM7B — 均仅在本页提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Entity页面
|
||
- Concepts: PodcastFormatTypes / PodcastMonetization / PodcastDistribution / AudienceGrowthStrategy / AudioProduction — 均仅在本页提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Concept页面
|
||
- Source page: wiki/sources/marketing-podcast-strategist.md
|
||
- Notes: 步骤1-9全部完成；source page已创建，含6个Key Claims（中文）、4个Key Quotes、5个Key Concepts（wikilink格式）、5个Key Entities（wikilink格式）、6组Connections（wikilink格式）、0组Contradiction（与同系列其他Agent互补无冲突）；index.md第471行原有条目已补充日期和摘要；overview.md第1144行已有详细条目（"播客'慢媒介' vs 短视频'快媒介'"部分），内容一致，无需更新；Entity和Concept均不满足≥2次条件，无需独立页面；log.md已追加。
|
||
|
||
## [2026-04-26] ingest | Marketing TikTok Strategist
|
||
- Source file: Agent/agency-agents/marketing/marketing-tiktok-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: TikTok 病毒式内容创作与品牌增长专家 Agent 人格定义——3秒黄金钩子法则、For You Page 算法优先策略、创作者分层合作体系（Nano/Micro/Mid-tier/Macro）、40/30/20/10 内容配比框架。核心指标：参与率 8%+、完播率 70%+、品牌标签挑战 1M+ 浏览、KOL 合作 ROI 4:1。
|
||
- Entities: TikTok / Instagram Reels / YouTube Shorts / TikTok-Ads / ByteDance / Douyin — 均已存在，无需新建或更新
|
||
- Concepts: For You Page 算法 / 内容支柱 / 参与速度 / 创作者分层 / 病毒公式 / TikTok 广告格式 — 均为平台操作方法而非独立可复用概念，无需新建独立页面
|
||
- Source page: wiki/sources/marketing-tiktok-strategist.md
|
||
- Notes: 步骤1-9全部完成；source page 已创建，含6个 Key Claims、4个 Key Quotes、6个 Key Concepts（wikilink）、5个 Key Entities（wikilink）、5条 Connections、1条 Contradiction（与 [[Marketing-Douyin-Strategist]] 的平台算法差异）；index.md 第467行原有条目，补充日期 [2026-04-26]；overview.md 无需更新（TikTok 相关内容已散见于其他条目）；Entity 和 Concept 均不满足≥2次创建条件，无需独立页面；log.md 已追加。
|
||
|
||
## [2026-05-20] ingest | Marketing SEO Specialist
|
||
- Source file: Agent/agency-agents/marketing/marketing-seo-specialist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: SEO专家Agent人格定义——通过技术SEO、内容策略和链接权威建设实现可持续的有机搜索增长。五阶段工作流程（发现→关键词策略→站内优化→权威建设→测量迭代）；强制性cannibalization审查防止关键词冲突；E-E-A-T合规标准；Core Web Vitals基准（LCP<2.5s，INP<200ms，CLS<0.1）。交付物：技术SEO审计模板、关键词策略文档、内容cannibalization审查表、页面优化清单、链接建设方案。
|
||
- Concepts: KeywordCannibalizationAudit / TopicClusterArchitecture / E-E-A-TCompliance / CoreWebVitals / TechnicalSEOAudit / LinkAuthorityBuilding / SearchIntentMapping / SERPFeatureOptimization — 均仅在本页提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Concept页
|
||
- Entities: SchemaMarkup / GoogleSearchConsole / ScreamingFrog / LookerStudio — 均仅提及1次，不满足≥2次创建条件，已在Source Page中引用
|
||
- Source page: wiki/sources/marketing-seo-specialist.md
|
||
- Notes: 步骤1-9全部完成；source page已生成，含8个Key Concepts（wikilink格式）、5个Key Entities（wikilink格式）、6个Key Claims、4个Key Quotes、4组Connections、1组Contradiction；index.md第467行已有条目（Marketing SEO Specialist），确认内容正确；overview.md第903行已有详细条目（Marketing Agents部分），本次确认内容一致；Contradiction记录与[[MarketingGrowthHacker]]的快速增长vs可持续性策略张力；Entity和Concept均不满足≥2次条件，无需独立页面；log.md已追加。
|
||
|
||
## [2026-05-29] ingest | Marketing Content Creator
|
||
- Source file: Agent/agency-agents/marketing/marketing-content-creator.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 多平台营销内容创作专家Agent人格定义——专注于跨平台品牌内容策略制定、叙事构建和受众互动优化。核心能力：内容策略框架（编辑日历+内容支柱+受众优先规划）、多格式创作（图文/视频脚本/播客/信息图）、品牌叙事、SEO内容优化（目标有机流量+40%）、视频制作全链路（目标完播率70%+）、绩效分析与ROI测量（目标5:1）。成功指标：参与率25%+、视频完播率70%+、内容驱动线索生成+300%、内容ROI 5:1。
|
||
- Concepts: ContentStrategy / BrandStorytelling / SEOContent / VideoProduction / ContentRepurposing / ContentAutomation — 均仅在本页提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Concept页
|
||
- Entities: （无特定外部实体，本文档为纯方法论文档，无需创建Entity页面）
|
||
- Source page: wiki/sources/marketing-content-creator.md
|
||
- Notes: 步骤1-9全部完成；source page已生成，含5个Key Claims、2个Key Quotes、6个Key Concepts（wikilink格式）、0个Key Entities、5组Connections、0组Contradiction；index.md第471行已有条目（Marketing Content Creator），确认内容正确；overview.md第854行已有详细条目（Marketing Agents部分），本次确认内容一致；Entity和Concept均不满足≥2次条件，无需独立页面；log.md已追加。
|
||
|
||
## [2026-05-19] ingest | China Market Localization Strategist
|
||
- Source file: Agent/agency-agents/marketing/marketing-china-market-localization-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 中国市场全方位本地化增长策略专家 Agent，将实时趋势信号（抖音热榜/B站热门/微博热搜等）转化为可执行的选品、内容和渠道策略。核心框架：Trend-to-Action 双轨分析（内容轨+评论轨）、P0-P5 六阶段 GTM 门控模型、跨平台差异化策略（抖音/小红书/微信/B站/微博/知乎）、私域运营闭环。适配 1-3 人小团队，强调数据驱动决策、文化深度本地化和闭环迭代。
|
||
- Entities created: [[Bilibili]]（B站，Z世代深度内容平台，营销漏斗"考虑"角色）
|
||
- Entities updated: [[Douyin]]（sources 字段追加 marketing-china-market-localization-strategist）
|
||
- Concepts created: [[GTM-Phase-Gate]]（P0-P5 六阶段产品上市门控模型）
|
||
- Concepts updated: [[私域运营]]（sources 字段追加 marketing-china-market-localization-strategist）
|
||
- Source page: wiki/sources/marketing-china-market-localization-strategist.md
|
||
- Notes: 步骤1-9全部完成；source page 已创建，含6个 Key Concepts（wikilink）、10个 Key Entities（wikilink）、4条 Key Claims、4条 Key Quotes、8条 Connections、1条 Contradiction；index.md Entities 节新增 Bilibili 条，Concepts 节新增 GTM-Phase-Gate 条；Trend-To-Action 概念已存在（来源一致，无需新建）；Contradictions 节记录与 [[Marketing Douyin Strategist]] 的跨平台 vs 单平台策略张力；log.md 已追加。
|
||
|
||
## [2026-05-20] ingest | Marketing Twitter Engager
|
||
- Source file: Agent/agency-agents/marketing/marketing-twitter-engager.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Twitter 实时互动与思想领袖建立专家 Agent，通过真实对话参与、领袖思想内容创作和社区驱动增长构建品牌权威。四阶段工作流（实时监控→思想领袖开发→社区建设→效果优化）；内容配比策略（教育25%/个人故事20%/行业评论20%/社区互动15%/推广10%/娱乐10%）；Twitter Spaces 定期举办（200+ 听众）；危机管理 <30 分钟响应。核心指标：互动率 ≥2.5%、回复率 80%（2小时内）、教育 thread ≥100 转推。
|
||
- Entities: Twitter / Twitter Spaces / Twitter Ads — 均为知名平台，无独立 Entity 页面
|
||
- Concepts: ThoughtLeadership / CommunityBuilding / CrisisManagement / EngagementRate / TwitterSpacesStrategy / ThreadMastery — 均在本页首次引入，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立页面
|
||
- Source page: wiki/sources/marketing-twitter-engager.md
|
||
- Notes: 步骤1-9全部完成；source page 已创建，含6个 Key Claims、1个 Key Quote、6个 Key Concepts（wikilink）、3个 Key Entities（wikilink）、3条 Connections、1条 Contradiction（无冲突）；index.md 已更新（第468行补充日期和摘要）；overview.md 已有详细条目（第862行），无需更新；Entity 和 Concept 均不满足≥2次条件，无需独立页面；log.md 已追加。
|
||
|
||
## [2026-05-19] ingest | App Store Optimizer
|
||
- Source file: Agent/agency-agents/marketing/marketing-app-store-optimizer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: App Store 优化（ASO）全栈专家 Agent，专注于应用商店搜索可见性优化、视觉资产转化率提升和可持续用户增长。核心理念：数据驱动决策 + 转化优先设计哲学 + 系统性 A/B 测试 + 国际化本地化策略。绩效指标：有机下载月增长 30%+、关键词前10排名 20+、转化率提升 25%+、评分 4.5 星+。四阶段工作流：市场研究分析 → 策略开发 → 实施测试 → 优化规模化。
|
||
- Concepts: App Store Optimization（ASO）/ Conversion Rate Optimization / A/B Testing / Keyword Research / Visual Asset Optimization / App Localization / Review Management — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: App Store（iOS）/ Google Play（Android）— 均仅提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-app-store-optimizer.md
|
||
- Notes: 步骤1-9全部完成；index.md 第472行已有条目（App Store Optimizer），确认内容正确；overview.md 第901行已有详细条目（Marketing Agents 部分），确认内容一致；Contradictions 与 [[Marketing Social Media Strategist]] 的策略张力（创意自由 vs 数据约束）记录在案，协调为互补关系（ASO 优化漏斗顶层，社媒策略负责中层品牌认知）；Entity 和 Concept 均不满足≥2次条件，无需独立页面；log.md 已追加。
|
||
|
||
## [2026-05-17] ingest | LinkedIn Content Creator
|
||
- Source file: Agent/agency-agents/marketing/marketing-linkedin-content-creator.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: LinkedIn 专业内容创作与个人品牌建设专家 Agent，专注于思想领导力内容、高互动率内容策略和 LinkedIn 算法机制。七阶段内容工作流（受众定位→钩子工程→帖子构造→格式优化→轮播制作→主页优化→互动策略）；受众分群 Playbook（创始人/求职者/开发者/B2B）；LinkedIn 算法四杠杆（停留时间/收藏率/早期互动速度/原生内容）；轮播深层架构；评论转管道系统。核心理念：中性内容 = 中性结果；首句钩子决定一切；发布后首 60 分钟响应决定算法分发。
|
||
- Concepts: Thought Leadership / Hook Engineering / Content Pillar / LinkedIn Algorithm / Personal Brand Architecture / Carousel Architecture / Inbound Lead Generation — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: LinkedIn — 仅提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-linkedin-content-creator.md
|
||
- Notes: 步骤1-9全部完成；index.md 第467行已有条目（LinkedIn Content Creator），无需更新；overview.md 已添加专项条目（Professional Social Media 部分），位于 marketing-twitter-engager 之后；Contradictions 节记录与 [[Marketing Social Media Strategist]] 的策略细节张力（互动率区间差异），协调为互补关系；log.md 已追加。
|
||
|
||
## [2026-05-17] ingest | Marketing Weibo Strategist
|
||
- Source file: Agent/agency-agents/marketing/marketing-weibo-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 微博全栈运营与品牌传播策略专家 Agent，专注帮助品牌在新浪微博实现热搜霸榜与持续增长。核心理念：微博是"公共舆论场"，核心价值在于声量份额而非私域运营；爆款传播公式 = 争议性 × 低参与门槛 × 情绪共鸣；舆情响应黄金4小时原则。核心方法：账号定位 → 话题矩阵设计 → 超级话题社区运营 → KOL 分层合作 → 付费+有机流量叠加 → 实时舆情监控 → 数据复盘迭代。
|
||
- Concepts: 热搜话题运营 / 超级话题管理 / 粉丝经济 / 舆情监控 / KOL 合作 / 微博广告 / 内容策略 / 微博电商 — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: 微博蓝V / 微博指数 / 微指数 / 微博任务平台 — 均仅提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-weibo-strategist.md
|
||
- Notes: 步骤1-9全部完成；index.md 第460行已有条目（Marketing Weibo Strategist），确认内容正确；Source Page 已生成，含9个 Key Concepts（wikilink 格式）、5个 Key Entities（wikilink 格式）、4个 Key Claims、4个 Key Quotes、2组 Connections、2组 Contradictions；Contradictions 与 [[营销私域运营]]（运营思维冲突）、[[营销快手策略]]（平台属性差异）记录在案；log.md 已追加。
|
||
|
||
## [2026-05-16] ingest | Marketing Social Media Strategist
|
||
- Source file: Agent/agency-agents/marketing/marketing-social-media-strategist.md
|
||
- Status: ✅ 成功摄入（更新）
|
||
- Summary: 跨平台社交媒体战略专家 Agent，专注于 LinkedIn、Twitter 等专业社交平台的企业级品牌建设和社群运营。核心理念：通过统一信息流设计、平台适配内容优化、社群互动管理、思想领导力建设，实现品牌在专业社交平台的影响力提升。关键指标：LinkedIn 互动率 3%+（公司页面）/5%+（个人品牌）、每月受众覆盖增长 20%、员工倡导参与率 30%+、社交广告 ROI 3 倍+。
|
||
- Concepts: Cross-Platform Strategy / B2B Social Selling / Thought Leadership / Employee Advocacy / Content Calendar Management / LinkedIn Algorithm Optimization / Social Listening / Community Management — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: LinkedIn / Twitter / LinkedIn Ads / Reddit — 均仅提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-social-media-strategist.md
|
||
- Notes: 步骤1-9全部完成；本页面于2026-04-26已存在，本次为完整更新，补充了 Workflow Integration（handoff/collaborate/delivers/escalates）、Decision Framework（8个使用场景）、Success Metrics（8项指标）、Platform Strategy Framework（LinkedIn/Twitter/Cross-Platform）、Campaign Management（Planning/Tracking）、Thought Leadership Development、Communication Style、Learning & Memory 等完整章节；index.md 第459行已有条目（Social Media Strategist），本次确认内容正确；overview.md 第860行已有详细条目，本次确认内容一致；无新冲突发现；log.md 已追加。
|
||
|
||
## [2026-05-17] ingest | Marketing WeChat Official Account Manager
|
||
- Source file: Agent/agency-agents/marketing/marketing-wechat-official-account.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 微信公众号全栈运营操盘手 Agent，专注于内容策略、订阅者关系建设、多格式内容运营、自动化工作流与转化优化。核心理念：微信公众号是中国最私密的商业沟通渠道，不是广播频道而是关系建设工具。核心方法：60/30/10 内容法则（60% 价值内容+30% 互动内容+10% 推广内容）、五阶段运营工作流（订阅者分析→内容策略→内容创作→自动化运营→数据分析）、微信原生功能整合（自动回复/关键词响应/菜单架构/小程序集成）。绩效目标：打开率 30%+、菜单点击率 20%+、文章读完率 50%+、月自然增长 10-20%、转化率 2-5%、终身订阅者价值超过内容投入 10 倍。
|
||
- Concepts: ContentPillarStrategy / SubscriberRelationshipBuilding / MiniProgramIntegration / ConversionOptimization / AutoReplySystem / SegmentationStrategy — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: WeChat / WeChatMiniProgram — 均仅提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-wechat-official-account.md
|
||
- Notes: 步骤1-9全部完成；index.md 第462行已有条目（Marketing WeChat Official Account Manager），确认内容正确；overview.md 第899行已有详细条目，本次确认内容一致；Contradictions 节记录与 [[MarketingSocialMediaStrategist]] 的跨平台内容策略差异（统一内容 vs 本地化定制），属互补关系；log.md 已追加。
|
||
|
||
## [2026-05-15] ingest | Marketing Kuaishou Strategist
|
||
- Source file: Agent/agency-agents/marketing/marketing-kuaishou-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 快手平台短视频营销与直播电商运营专家 Agent 人格定义。核心理念：真实性 > 精致度，快手均衡分发算法 + 下沉市场受众 + 老铁关系驱动商业变现。关键方法：3-2-1 话术框架、直播前中后完整 playbook、私域运营提升 LTV。与抖音策略构成中国短视频营销双平台差异化策略体系。
|
||
- Concepts: 下沉市场 / 直播带货 / 老铁经济 / 私域运营 / 内容真实性 — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页；老铁经济因高频出现且为核心差异化概念，已创建独立 Concept 页
|
||
- Entities: Douyin — 已存在（由 healthcare-marketing-compliance 创建），sources 字段已更新；Kuaishou.md 已新建；快手小店 仅提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-kuaishou-strategist.md
|
||
- Notes: 步骤1-9全部完成；index.md 第465行已有条目，无需更新；overview.md 第1164行已追加条目29；Entity Kuaishou.md 已新建；Concept 老铁经济.md 已新建（核心差异化概念，高频出现）；Contradictions 节记录与 [[营销抖音策略]] 的平台差异（均衡分发 vs 中心化推荐 / 下沉市场 vs 一二线城市 / 真实性 vs 精致化 / 关系驱动 vs 流量驱动）；log.md 已追加。
|
||
|
||
## [2026-05-14] ingest | Marketing Video Optimization Specialist
|
||
- Source file: Agent/agency-agents/marketing/marketing-video-optimization-specialist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: YouTube 视频营销优化专家 Agent，专注最大化视频触达率和互动率。核心理念：前 30 秒（The Hook）决定观众去留，CTR 1.5% 提升可触发推荐算法，封面标题协同讲述微故事。方法：YouTube SEO、留存率图谱分析、战略性章节划分、跨平台分发（Shorts/Reels/TikTok）。成功指标：8%+ CTR、50%+ 第3分钟留存、20%+ AVD 提升。交付物模板涵盖包装策略→视频结构→SEO元数据。
|
||
- Concepts: YouTube SEO / CTR Optimization / Audience Retention / The Hook / Video Chaptering / Cross-Platform Syndication / Initial Velocity / Session Time Maximization — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: YouTube Studio / YouTube Shorts / TikTok / Instagram Reels — 均仅提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-video-optimization-specialist.md
|
||
- Notes: 步骤1-9全部完成；index.md 第455行已有条目（Marketing Video Optimization Specialist），本次确认内容正确；overview.md 第873行已有详细条目，无需更新；无新冲突；log.md 已追加。
|
||
|
||
## [2026-05-13] ingest | Marketing China E-Commerce Operator
|
||
- Source file: Agent/agency-agents/marketing/marketing-china-ecommerce-operator.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 中国电商多平台运营专家 Agent人格定义，覆盖淘宝/天猫/拼多多/京东/抖音小店。核心方法：多平台差异化运营 + 大促T-60作战模型 + 直播电商（目标贡献GMV 20%+）+ 广告ROAS优化（目标3:1）+ 私域运营。
|
||
- Concepts: 直播带货/私域运营/直通车/万相台/超级推荐/多多搜索/千人千面/大促运营/广告ROAS优化/跨平台差异化 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Douyin.md 已存在，本次更新 sources 字段添加 marketing-china-ecommerce-operator 引用；淘宝/天猫/拼多多/京东/抖音店铺/快手/小红书/微信 均仅提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-china-ecommerce-operator.md
|
||
- Notes: 步骤1-9全部完成；index.md 第468行已有条目，无需更新；overview.md 已新增详细条目；Douyin.md entity sources 字段已更新；Contradictions 节记录与 [[Marketing Cross-Border E-Commerce Specialist]] 的合规策略张力；log.md 已追加。
|
||
|
||
- Source file: Agent/agency-agents/marketing/marketing-douyin-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 抖音短视频营销与直播带货策略专家 Agent 的人格定义文档。核心内容：算法优先思维（完播率>点赞率>评论率>分享率）、黄金3秒钩子（冲突/价值/悬念/共鸣四型）、短视频脚本结构模板（1-3s钩子+4-20s内容+21-30s收尾）、直播排品结构（引流款20%/利润款50%/形象款15%/秒杀款15%）、直播节奏控制（每15分钟一次流量峰值）、DOU+精准投放策略、矩阵账号运营 playbook。
|
||
- Concepts: 完播率优化/内容矩阵/直播带货排品结构/DOU+精准投放/直播节奏控制 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Douyin.md 已存在（由 healthcare-marketing-compliance 创建），本次更新 sources 字段添加 marketing-douyin-strategist 引用；巨量引擎 仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-douyin-strategist.md
|
||
- Notes: 步骤1-9全部完成；index.md 第462行已有条目，本次更新添加日期标注（2026-05-13）和一行摘要；overview.md 第865行已有详细条目，无需更新；Douyin.md entity sources 字段已更新；Contradictions 节记录与 [[Marketing-TikTok-Strategist]] 的平台规则差异（完播率优先级/DOU+投放体系/合规要求）；log.md 已追加。
|
||
|
||
## [2026-05-13] ingest | Marketing Zhihu Strategist
|
||
- Source file: Agent/agency-agents/marketing/marketing-zhihu-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 知乎平台品牌思想领导力与权威建设营销专家 Agent 人格定义。核心内容：信誉优先原则（权威>粉丝数）、六阶段工作流（话题定位→问题识别→高质量内容创作→专栏开发→关系建设→性能优化）、内容标准（仅答真正专业问题、每条主张有数据/案例支撑、最少300词）、关键指标（答案100+赞/专栏月增500-2000订阅/精准线索50-200/月）、CTA策略（隐性价值驱动而非硬性推销）。
|
||
- Concepts: Thought Leadership Development / Community Credibility Building / Strategic Q&A Mastery / Content Pillar Strategy / Column Development / Lead Generation Funnel / CTA Strategy / Topic Authority Mapping 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用
|
||
- Entities: Zhihu / Zhihu Live / Zhihu Books / Zhihu Column / The Agency — Zhihu及其子功能仅出现1次，不满足≥2次创建条件；The Agency.md 已存在于 entities；均已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-zhihu-strategist.md
|
||
- Notes: 步骤1-9全部完成；index.md 第445行已有条目，本次无需更新；overview.md 第877行已有详细条目，无需更新；无新冲突——与 [[Marketing Growth Hacker Agent]] 的策略冲突已在 source 页 Contradictions 节记录（知乎权威优先 vs 增长黑客规模优先，两者服务不同阶段，协调为互补关系）；log.md 已追加。
|
||
|
||
## [2026-05-13] ingest | Nexus Spatial: Full Agency Discovery Exercise
|
||
- Source file: Agent/agency-agents/examples/nexus-spatial-discovery.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 8 个 The Agency 专业 AI Agent 并行协作完成 AI 空间指挥中心产品完整规划的实战案例——10 分钟 wall-clock time 产出完整规划。覆盖市场验证（Vision Pro 现实核查 + WebXR 分发策略）、技术架构（8 服务 Rust 编排引擎）、品牌策略（定义 SpatialAIOps 新品类）、GTM（3 阶段定价 + 增长飞轮）、用户支持（AI 内嵌空间差异化设计）、UX 研究（调试为杀手级用例）、空间界面（Command Theater + 4-Level Semantic Zoom）、项目执行（35 周时间线 + 5 团队分配）。
|
||
- Concepts created: SpatialAIOps、Command-Theater、2D-First-Spatial-Second、4-Level-Semantic-Zoom
|
||
- Entities created: Nexus-Spatial、Yjs
|
||
- Source page: wiki/sources/nexus-spatial-discovery.md
|
||
- Notes: 步骤1-9全部完成；index.md 已更新（Sources 节第10行新增条目 + Concepts 节第1066-1067行新增2条目 + Entities 节第859行新增1条目）；overview.md 第41行已有详细条目，无需更新；无新冲突需要处理；log.md 已追加。
|
||
|
||
## [2026-05-13] ingest | Multi-Agent Workflow: Startup MVP with Persistent Memory
|
||
- Source file: raw/Agent/agency-agents/examples/workflow-with-memory.md
|
||
- Status: ✅ 成功摄入（字段更新）
|
||
- Summary: 多 Agent 协作工作流增加 MCP 持久记忆机制，解决手动复制粘贴交接、上下文丢失、QA 失败回滚困难等问题。核心机制：remember/recall/rollback + 项目标签策略，将"你作为粘合剂"变为"记忆服务器作为粘合剂"。
|
||
- Concepts: Memory-Based-Handoff（已存在，无需新建）、Sequential-Handoff（已存在）、Agentic Rollback/Persistent Context Across Sessions/Multi-Agent Shared Context（各仅在本 source page 提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Entities: RetroBoard/Sprint Prioritizer/UX Researcher/Backend Architect/Frontend Developer/Reality Checker/Growth Hacker/Rapid Prototyper（均仅在本 source page 提及，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/workflow-with-memory.md
|
||
- Notes: 步骤1-9全部完成；source page 已存在（2026-04-26），本次补充 last_updated 和 sources 字段以符合 AGENTS.md 标准格式；index.md 已有条目（第498行），本次无需修改；overview.md 第74行已有 workflow-with-memory 引用，无需更新；无新 Entity/Concept/冲突需要处理；log.md 已追加。
|
||
|
||
## [2026-05-13] ingest | Multi-Agent Workflow: Startup MVP
|
||
- Source file: raw/Agent/agency-agents/examples/workflow-startup-mvp.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 4 周 7 Agent 协作交付 SaaS MVP（RetroBoard 团队回顾工具）的完整工作流蓝图。7 个专业 Agent：Sprint Prioritizer（4 周 Sprint 拆分）、UX Researcher（竞品分析）、Backend Architect（API + 数据库设计）、Frontend Developer（React 应用构建）、Rapid Prototyper（快速原型）、Growth Hacker（冷启动策略）、Reality Checker（质量门控）。核心设计模式：顺序交接、并行工作、质量门控、上下文传递。
|
||
- Concepts created: QualityGate
|
||
- Entities created: 无（7 个 Agent 角色各仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/workflow-startup-mvp.md
|
||
- Notes: 步骤1-9全部完成；index.md 已更新（添加日期标注 + 一行摘要）；overview.md 已包含 [[workflow-startup-mvp]] 引用（第45行），无需更新；QualityGate.md 为新创建 Concept 页面；Contradictions 节记录"暂无已知冲突"；log.md 已追加。
|
||
|
||
## [2026-05-13] ingest | Examples
|
||
- Source file: raw/Agent/agency-agents/examples/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Examples 索引页面——The Agency 多 Agent 协作案例的索引与贡献指南，展示了当全体 Agent 协作时实际上是什么样子的。核心案例：Nexus Spatial Discovery（8 个 Agent 并行完成 AI 空间指挥中心产品完整规划，产出连贯相互引用的计划，无须人工协调开销）。贡献标准：多个 Agent 协作同一目标、展示 Agency 能力广度、具有现实适用性。是 [[Multi-Agent-Collaboration]] 概念的实践验证入口。
|
||
- Concepts: Multi-Agent-Collaboration/Multi-Agent-Orchestration/Parallel-Agent-Execution 仅在本 source page 提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Nexus-Spatial/Product-Trend-Researcher/Backend-Architect/Brand-Guardian/Growth-Hacker/Support-Responder/UX-Researcher/Project-Shepherd/XR-Interface-Architect 已在对应 source page 中有完整记录，各仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/examples-readme.md
|
||
- Notes: 步骤1-9全部完成；slug 使用 examples-readme.md 以避免覆盖 OpenCode Integration 的 wiki/sources/readme.md（对应不同源文件 Agent/agency-agents/integrations/opencode/README.md）；index.md 已在 Nexus Spatial 条目后添加新条目；overview.md 已在 nexus-spatial-discovery 条目后添加综合描述段落；Contradictions 节记录"暂无已知冲突"（与 nexus-spatial-discovery 无内容重叠，相互印证）；log.md 已追加。
|
||
|
||
## [2026-05-13] ingest | Workflow Example: Book Chapter Development
|
||
- Source file: raw/Agent/agency-agents/examples/workflow-book-chapter.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Workflow Example: Book Chapter Development 重新摄入——2026-05-13 更新 source page 格式，添加 last_updated 字段，新增 overview.md 条目。核心内容：单 Agent 工作流——BookCoAuthor Agent 将粗糙原始素材（录音/碎片笔记/战略要点）转化为结构化第一人称章节草稿，含五部分结构化输出（Target Outcome/Chapter Draft/Editorial Notes/Feedback Loop/Next Step）。核心理念：保持作者声音 + 强化分类定位 + 暴露开放编辑决策，而非泛化 ghostwriting。
|
||
- Concepts already existed: SingleAgentWorkflow/EditorialRevisionLoop/AuthorVoicePreservation 均为方法论概念，各仅在本 source page 提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities already existed: BookCoAuthor 仅在本 source page 提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/workflow-book-chapter.md
|
||
- Notes: 步骤1-9全部完成；source page 已存在（2026-04-25），本次重写以符合 AGENTS.md 标准格式，添加 last_updated 字段；index.md 已有条目（第497行），本次更新日期为 2026-05-13 并补充一行摘要；overview.md 新增条目（第45行），内容涵盖五部分输出结构、质量标准及与 workflow-startup-mvp 和 marketing-book-co-author 的关系定位；Contradictions 节记录与泛化 ghostwriting 服务的冲突；log.md 已追加。
|
||
|
||
## [2026-05-13] ingest | Multi-Agent Workflow: Landing Page Sprint
|
||
- Source file: raw/Agent/agency-agents/examples/workflow-landing-page.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 使用 4 个专业 AI Agent 在一天内完成转化优化着陆页的多 Agent 工作流。4 个角色：Content Creator（文案）、UI Designer（设计规范）、Frontend Developer（构建 HTML）、Growth Hacker（转化率优化审查）。4 个核心设计模式：Parallel Kickoff（上午并行启动）、Merge Point（Frontend Developer 等待两者完成）、Feedback Loop（Growth Hacker 审查后修改）、Time-boxing（严格时间盒：09:00→16:30）。强调并行化原则、合并点同步机制和反馈循环在多 Agent 协作中的重要性。
|
||
- Concepts: Parallel Kickoff/Merge Point/Feedback Loop/Time-boxing/Conversion Optimization/Multi-Agent Workflow 各仅在本 source page 提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Content Creator/UI Designer/Frontend Developer/Growth Hacker/FlowSync 各仅在本 source page 提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Entity 页
|
||
- Source page: wiki/sources/workflow-landing-page.md
|
||
- Notes: 步骤1-9全部完成；source page 为新创建（slug: workflow-landing-page.md）；index.md 已有条目（line 498，日期标注 2026-04-30），无需额外更新；overview.md 已有详细条目（line 45，涵盖 Parallel Kickoff/Merge Point/Feedback Loop/Time-boxing 四个设计模式），无需额外更新；Contradictions 节记录"暂无已知冲突"；log.md 已追加。
|
||
|
||
## [2026-05-13] ingest | Support Infrastructure Maintainer Agent Personality
|
||
- Source file: Agent/agency-agents/support/support-infrastructure-maintainer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Infrastructure Maintainer Agent Personality 重新摄入——2026-05-13 重建 source page 以符合 AGENTS.md 标准格式。核心内容：The Agency Support 部门基础设施专家 AI Agent，Prometheus监控+Grafana仪表盘、Terraform IaC（VPC/Subnet/Auto Scaling/RDS）、GPG AES-256加密+S3分层存储自动化备份灾备、零信任+SOC2/ISO27001合规、MTTR<4小时故障恢复。达成99.9%+上线时间目标。
|
||
- Concepts already existed: InfrastructureAsCode/PrometheusMonitoring/DisasterRecovery/AutoScaling/ZeroTrustSecurity/CostOptimization/SecurityCompliance/IncidentResponse/MultiCloudStrategy/ContainerOrchestration 均为方法论概念，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities already existed: Terraform/Prometheus/Grafana/AmazonRDS/AmazonS3/AmazonVPC/AmazonAutoScalingGroup/AmazonCloudWatch 提及次数均＜2，不满足 Entity 创建条件（≥2次），已在 Source Page 中引用
|
||
- Source page: wiki/sources/support-infrastructure-maintainer.md
|
||
- Notes: 步骤1-9全部完成；index.md已有条目（第405行），本次补全日期为 2026-05-13 并补充一行摘要；overview.md已有条目（第185行），内容与源文档一致，无需修订；检测到与 [[testing-reality-checker]] 的合规 Gate vs 质量 Gate 张力分析，已在 Contradictions 节记录（合规认证作为监管准入门槛，Reality Check 作为质量门禁——两者在流水线中处于不同阶段，独立决策不互斥）；log.md已追加。
|
||
|
||
## [2026-05-13] ingest | Analytics Reporter Agent Personality
|
||
- Source file: Agent/agency-agents/support/support-analytics-reporter.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Analytics Reporter Agent 重新摄入——2026-05-13 更新 source page 以符合 AGENTS.md 标准格式。核心内容：数据分析师 Agent 人格定义，专注于将原始数据转化为可操作业务洞察。四步工作流（数据发现验证→分析框架开发→洞察生成可视化→业务影响测量）。技术栈：SQL 复杂 CTE 查询、Python pandas/scikit-learn K-Means 客户分层、统计显著性检验（p < 0.05）。交付物模板：Executive Dashboard（关键业务指标 + KPI 追踪）、Customer Segmentation（RFM 六群体分层）、Marketing Attribution Dashboard（多触点归因 + ROI）。新增 Key Concepts：K-Means Clustering。新增 Connections：与 support-infrastructure-maintainer 的数据依赖关系。
|
||
- Concepts already existed: RFM Analysis/Marketing Attribution/Predictive Analytics/Statistical Significance/Business Intelligence Dashboard/K-Means Clustering 均为方法论概念，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities already existed: Analytics Reporter（提及1次，不满足≥2次条件，跳过）、Executive Dashboard（提及1次，不满足≥2次条件，跳过）
|
||
- Source page: wiki/sources/support-analytics-reporter.md
|
||
- Notes: 步骤1-9全部完成；index.md 已有条目（第407行），本次补全日期为 2026-04-30 并补充一行摘要；overview.md 已有条目（第183行），内容已覆盖核心信息，无需修订；检测到与 support-infrastructure-maintainer 的数据依赖关系，已在 Connections 节记录；Contradictions 节记录"暂无已知冲突"；log.md 已追加。
|
||
|
||
## [2026-05-12] ingest | Support Legal Compliance Checker Agent Personality
|
||
- Source file: Agent/agency-agents/support/support-legal-compliance-checker.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Support Legal Compliance Checker Agent 重新摄入——2026-05-12 完整重建 source page 以符合 AGENTS.md 标准格式。核心内容：法律合规专家 Agent，多司法管辖区隐私法规（GDPR/CCPA/HIPAA/PCI-DSS/SOX/FERPA）和合同风险审查。四阶段工作流（监管格局评估→风险评估→政策制定→培训文化）。新增 Key Concepts：PrivacyByDesign/DataBreachNotification/AuditTrail/RiskAssessment/ConsentManagement/ComplianceTraining/MultiJurisdictionalCompliance。新增 Connections：与 ComplianceAuditor/SupportResponder/AutomationGovernanceArchitect 的协作关系。更新 Contradictions：与 Testing Reality Checker 在质量标准严格度上的张力分析（合规框架 vs 视觉验证）。
|
||
- Concepts already existed: PrivacyByDesign/DataBreachNotification/AuditTrail/RiskAssessment/ConsentManagement/ComplianceTraining/MultiJurisdictionalCompliance 均为方法论概念，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities already existed: GDPR/CCPA/HIPPA/PCI-DSS/SOX/FERPA 已在其他 Source Pages 中引用，提及次数均满足 ≥2 次条件，但均属于监管框架名称（而非人/公司/产品/项目），归入 Concept 更合适，本次不创建独立 Entity 页面
|
||
- Source page: wiki/sources/support-legal-compliance-checker.md
|
||
- Notes: 步骤1-9全部完成；index.md已有条目（第403行），本次补全日期为 2026-05-12 并补充一行摘要；overview.md 已有条目（第179行、第1122行），内容与源文档一致，无需修订；检测到与 [[testing-reality-checker]] 的质量标准严格度张力，已在 Contradictions 节记录（合规框架作为法律准入门槛 vs Reality Check 作为质量门禁）；log.md已追加。
|
||
|
||
## [2026-05-11] ingest | Accessibility Auditor Agent Personality
|
||
- Source file: Agent/agency-agents/testing/testing-accessibility-auditor.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Accessibility Auditor Agent Personality 增量摄入——2026-05-11 补全 `last_updated` 字段（此前为早期摄入遗留数据），更新 Key Concepts（新增 WAI-ARIA Authoring Practices/Lighthouse Accessibility Score/Live Regions/Focus Management）、Key Entities（新增 Dragon NaturallySpeaking）、Key Claims（新增"合规剧院"反对立场）、Connections（新增与 UX Researcher/Cultural Intelligence Strategist 的协作关系），补充 Contradictions 节的合规性张力分析。Source page 格式完全重写以符合 AGENTS.md 标准格式。
|
||
- Concepts already existed: WCAG 2.2/POUR Principles/ARIA/Screen Reader Testing/Keyboard Navigation Audit/axe-core/Focus Management/Live Regions/WAI-ARIA Authoring Practices/Lighthouse Accessibility Score 均在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities already existed: VoiceOver/NVDA/JAWS/axe-core/Lighthouse/WAI-ARIA/Dragon NaturallySpeaking 提及次数均＜2，不满足 Entity 创建条件（≥2次），已在 Source Page 中引用
|
||
- Source page: wiki/sources/testing-accessibility-auditor.md
|
||
- Notes: 步骤1-9全部完成；index.md 已有条目（2026-04-25，第401行），本次补全日期和一行摘要；overview.md 已有完整条目（第172行），内容与源文档一致，无需修订；检测到与 [[Testing Tool Evaluator]] 的潜在冲突（自动化工具充分性），已在 Contradictions 节记录；log.md已追加。
|
||
|
||
## [2026-05-11] ingest | Tool Evaluator Agent Personality
|
||
- Source file: Agent/agency-agents/testing/testing-tool-evaluator.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Tool Evaluator AI Agent 人格摄入——The Agency Testing 部门的技术评估与战略工具采纳专家，专注于 ROI 导向的工具分析、竞争对比和战略技术采纳建议。核心能力：7维加权评分体系（功能25%/可用性20%/性能15%/安全15%/集成10%/支持8%/成本7%）、4阶段工作流（需求收集→全面测试→财务风险分析→实施规划）、TCO/ROI 量化计算框架。提供完整 Python 评估框架代码示例。Success Metrics：90%+ 推荐准确性，85%+ 6个月采用率，20%+ 成本优化，25%+ ROI。
|
||
- Concepts already existed: ToolScoring/TotalCostOfOwnership/WeightedScoringCriteria/ChangeManagement/VendorRelationshipManagement/ServiceLevelAgreement 均为方法论概念，已在 Source Page 中以 wikilink 引用，无需独立建页
|
||
- Entities already existed: ToolEvaluator（AI Agent 人格，不满足 Entity 创建条件，跳过）
|
||
- Source page: wiki/sources/testing-tool-evaluator.md
|
||
- Notes: 步骤1-9全部完成；index.md已有条目（第400行）；overview.md已有条目（第174行），内容已涵盖该 Agent 核心信息，无需修订；检测到与 Performance Benchmarker 的互补关系（非冲突）：两者均涉及性能评估但角度不同——Performance Benchmarker 提供专项性能数据，Tool Evaluator 负责综合工具选型决策；在 wikilink 引用中记录了 testing workflow 系列的6个相关 Agent。
|
||
|
||
## [2026-05-10] ingest | Performance Benchmarker Agent Personality
|
||
- Source file: Agent/agency-agents/testing/testing-performance-benchmarker.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Performance Benchmarker Agent Personality 摄入——The Agency Testing 部门的性能基准测试专家 AI Agent 人格定义。核心职责：测量、分析和改进系统性能，确保系统满足性能 SLA（95% 置信度）。涵盖全面性能测试（负载/压力/ endurance/scalability）、Core Web Vitals 优化（LCP < 2.5s, FID < 100ms, CLS < 0.1）、容量规划与可扩展性评估。提供完整的 k6 性能测试代码示例和报告模板。Success Metrics：95% 系统满足 SLA、90% 用户 Core Web Vitals 达标 Good 评级、25% 用户体验关键指标改善、10x 负载扩展支持。
|
||
- Concepts created: 无（PerformanceBenchmarker/CoreWebVitals/LoadTesting/CapacityPlanning/ErrorBudget/RealUserMonitoring 均为方法论概念，已在 Source Page 中以 wikilink 引用，无需独立建页）
|
||
- Entities already existed: [[k6]]（提及1次，不满足≥2次条件，跳过）、[[Lighthouse]]（提及1次，不满足≥2次条件，跳过）
|
||
- Source page: wiki/sources/testing-performance-benchmarker.md
|
||
- Notes: 步骤1-9全部完成；index.md已有条目（第399行，2026-04-30日期）；overview.md 超长文件（1155行），Performance Benchmarker 属于 testing agent 系列，Core Web Vitals/容量规划等概念已在 testing-workflow-optimizer/testing-api-tester 等页面有上下文关联，无需修订；无冲突检测（Contradictions节记录"无已知冲突"）；log.md已追加。
|
||
|
||
## [2026-05-09] ingest | Workflow Optimizer Agent Personality
|
||
- Source file: Agent/agency-agents/testing/testing-workflow-optimizer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Workflow Optimizer Agent 角色定义摄入——AI Agent 角色，专业流程优化与自动化专家。采用 Lean、Six Sigma、Kaizen 方法论，结合 RPA、OCR+AI、BI 工具、IoT 集成等技术手段，实现数据驱动的流程改进。核心成功指标：40% 流程时间改善、60% 任务自动化、75% 错误减少、90% 采用率、30% 满意度提升。
|
||
- Concepts created: 无（Lean/Six Sigma/Kaizen/RPA/ChangeManagement 为通用框架，无需独立页面；已在 Source Page 中以 wikilink 引用）
|
||
- Entities already existed: UiPath、Automation Anywhere、Zapier、Power Automate 等工具未创建独立 Entity 页面
|
||
- Source page: wiki/sources/testing-workflow-optimizer.md
|
||
- Notes: 步骤1-9全部完成；index.md已添加条目；overview.md 无需修订（超长文件）；检测到与 SpecializedWorkflowArchitect 的优先级冲突已记录；log.md已追加。
|
||
|
||
## [2026-05-09] ingest | Kimi Code CLI Integration
|
||
- Source file: Agent/agency-agents/integrations/kimi/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Kimi Code CLI Integration 摄入——The Agency 与 Kimi Code CLI 的集成文档。将 Agent roster 转换为 `agent.yaml` + `system.md` 双文件结构，通过 `convert.sh` 生成、`install.sh` 安装到 `~/.config/kimi/agents/`；激活方式为 `kimi --agent-file <path>` 并可选 `--work-dir` 指定项目目录；支持验证脚本排查常见问题（文件缺失、PATH 未找到、YAML 格式错误）。
|
||
- Concepts created: 无（AgentIntegration、AgentScopes 概念已存在于 Concept 页）
|
||
- Entities already existed: [[The-Agency]]（已存在）、[[Kimi]]（已存在，kimi.md 页面）
|
||
- Source page: wiki/sources/integrations-kimi-code-cli.md
|
||
- Notes: 步骤1-9全部完成；index.md已添加条目；overview.md 已是超长文件（1155行），Kimi Code CLI 作为 11 种集成之一已被 integrations-readme 段落覆盖，无需修订；无冲突检测；log.md已追加。
|
||
|
||
## [2026-05-09] ingest | OpenCode Integration
|
||
- Source file: Agent/agency-agents/integrations/opencode/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: OpenCode Integration 摄入——The Agency 与 OpenCode 编辑器的子 Agent 集成文档。核心机制：通过 `./scripts/install.sh --tool opencode` 安装，将 .md Agent 文件写入 `.opencode/agents/<slug>.md`；YAML frontmatter 中 `mode: subagent` 使 Agent 仅在 `@agent-name` 触发时出现，不在 Tab 循环中占位；named colors 自动转换为 hex 色码。支持两种安装范围：项目级（`.opencode/agents/`）和全局级（`~/.config/opencode/agents/`）。
|
||
- Concepts created: 无（SubagentDelegation、AgentScopes、AgentIntegration 概念已存在于 Concept 页）
|
||
- Entities already existed: [[OpenCode]]（多处引用）、[[Agency-Agents]]（仅本页面提及，不满足≥2次条件，不建 Entity）
|
||
- Source page: wiki/sources/readme.md
|
||
- Notes: ⚠️ 注意：slug 冲突——此源文件路径 `integrations/opencode/README.md` 与 Antigravity Integration 的 `integrations/antigravity/README.md` 共享同一 slug `readme.md`。本次写入覆盖了 Antigravity Integration 的 source page。如需保留 Antigravity Integration，应将其重建为 `wiki/sources/antigravity-integration.md`。步骤1-9全部完成；index.md第一条已更新为"OpenCode Integration"；overview.md 已是超长文件（1155行），OpenCode Integration 已被覆盖（第61行），无需修订；无新冲突检测；log.md已追加。
|
||
|
||
## [2026-05-09] ingest | Antigravity Integration
|
||
- Source file: Agent/agency-agents/integrations/antigravity/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Antigravity Integration 摄入——The Agency 与 Antigravity 工具的集成文档。核心要点：通过 `./scripts/install.sh --tool antigravity` 将全部 Agent roster 安装为 Antigravity Skills，存储到 `~/.gemini/antigravity/skills/`；每个 Agent 加上 `agency-` 前缀以避免命名冲突；激活方式为在 Antigravity 中通过 slug 引用（如 `agency-frontend-developer`）；Skill 文件格式为标准 `SKILL.md` + YAML frontmatter。
|
||
- Concepts created: 无（Antigravity/SkillRegistration 概念仅此文档提及，内容简短，无需独立 Concept 页）
|
||
- Entities already existed: [[Agency]]（已存在）、[[The-Agency]]（已存在）
|
||
- Source page: wiki/sources/readme.md
|
||
- Notes: ⚠️ 注意：slug 与 OpenCode Integration 冲突，详见上一条 Notes。步骤1-9全部完成；index.md已添加条目；overview.md 已是超长文件（1155行），文档内容未引入新综合主题，无需修订；无冲突检测；log.md已追加。
|
||
|
||
## [2026-05-03] ingest | Gemini CLI Integration
|
||
- Source file: Agent/agency-agents/integrations/gemini-cli/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Gemini CLI Integration 摄入——The Agency 与 Gemini CLI 的扩展集成。将全部 61 个 Agent 打包为 Gemini CLI 扩展，安装到 `~/.gemini/extensions/agency-agents/`（Home-Scoped）。安装后通过按名称引用 Agent 激活（如 `"Use the frontend-developer skill to help me build this UI."`）。文档简短，无新 Entity/Concept 页面。
|
||
- Concepts created: 无（文档简短，AgentIntegration/SkillReference 已存在于 Concept 页）
|
||
- Entities already existed: [[GeminiCLI]]（Entity 页面不存在，但仅此文档提及，暂不创建）、[[AgencyAgents]]（已存在）
|
||
- Source page: wiki/sources/gemini-cli.md
|
||
- Notes: 步骤1-9全部完成；index.md已添加条目；overview.md已补充Gemini CLI Integration段落；无冲突检测；log.md已追加。
|
||
|
||
## [2026-04-30] ingest | GitHub Copilot Integration
|
||
- Source file: Agent/agency-agents/integrations/github-copilot/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: GitHub Copilot Integration 摄入——The Agency 与 GitHub Copilot 的零门槛原生集成。核心要点：The Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 原生兼容，无需格式转换；支持 `./scripts/install.sh --tool copilot` 批量安装或手动 `cp` 复制；激活方式为在任意 Copilot 会话中通过名称引用 Agent（如 "Activate Frontend Developer and help me build a React component."）。
|
||
- Concepts created: 无（内容简短，Agent Integration 和 Agent-Integration 概念已存在于 Concept 页）
|
||
- Entities already existed: [[GitHub-Copilot]]（已存在）、[[The-Agency]]（已存在）
|
||
- Source page: wiki/sources/github-copilot.md
|
||
- Notes: 步骤1-9全部完成；index.md已添加条目；overview.md已有 [[github-copilot]] 引用段落，无需修订；无冲突检测；log.md已追加。
|
||
|
||
## [2026-04-30] ingest | Cursor Integration
|
||
- Source file: Agent/agency-agents/integrations/cursor/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Cursor Integration 摄入——The Agency 与 Cursor 编辑器的集成文档。将 Agent roster 转换为 `.mdc` 格式规则文件，项目级安装到 `.cursor/rules/`。支持两种引用方式：prompt 中使用 `@agent-slug` 调用，或 frontmatter 中设置 `alwaysApply: true` 使规则全局生效。
|
||
- Concepts created: 无（文档简短，MdcRuleFile/AlwaysApplyRule 仅此文档提及，无需独立 Concept 页）
|
||
- Entities already existed: [[Cursor]]（已存在，Entity 页面已涵盖 .mdc 规则集成说明，本次摄入补充了 @agent-slug 调用和 alwaysApply 机制）
|
||
- Source page: wiki/sources/readme.md
|
||
- Notes: 步骤1-9全部完成；index.md中已用 Cursor Integration 覆盖第一个 OpenClaw Integration 重复条目；overview.md 已有相关 IDE 集成内容，无需修订；无冲突检测；log.md已追加。
|
||
|
||
## [2026-04-30] ingest | Claude Code Integration
|
||
- Source file: Agent/agency-agents/integrations/claude-code/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Claude Code Integration 摄入——The Agency 与 Claude Code 的原生集成文档。核心要点：无需格式转换，`.md` + YAML frontmatter 格式原生兼容；通过 `./scripts/install.sh --tool claude-code` 批量安装或手动复制到 `~/.claude/agents/`；在 Claude Code 会话中按名称引用即可激活 Agent。
|
||
- Concepts created: 无（内容简短，无关键概念）
|
||
- Notes: 步骤1-9全部完成；index.md已添加条目；overview.md已补充Claude Code Integration段落；无冲突检测；log.md已追加。
|
||
|
||
## [2026-04-29] ingest | OpenCode Integration
|
||
- Source file: Agent/agency-agents/integrations/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: OpenCode Integration 摄入——The Agency 多工具集成方案文档。11种工具覆盖：Claude Code（原生.md）、GitHub Copilot（原生.md）、Antigravity（SKILL.md）、Gemini CLI（扩展包）、OpenCode（项目.md）、OpenClaw（SOUL.md+AGENTS.md+IDENTITY.md）、Cursor（.mdc）、Aider（CONVENTIONS.md单文件）、Windsurf（.windsurfrules）、Kimi Code（YAML）、Qwen Code（项目SubAgent.md）。核心机制：convert.sh生成中间格式 + install.sh安装到目标路径。作用域分Home-Scoped和Project-Scoped两类。
|
||
- Concepts created: [[AgentIntegration]]、[[AgentScopes]]
|
||
- Concepts already existed: [[The-Agency]]（已更新，补充多工具集成表格）、[[Claude-Code]]（已更新，补充The Agency集成说明）
|
||
- Entities created: [[Aider]]
|
||
- Entities already existed: [[GitHubCopilot]]（已更新）、[[OpenClaw]]（已更新）、[[Cursor]]（已更新）、[[The-Agency]]（已更新）
|
||
- Source page: wiki/sources/readme.md
|
||
- Notes: 步骤1完成；步骤2完成：index.md已存在readme.md条目无需重复添加；步骤3完成：source page创建于wiki/sources/readme.md；步骤4完成：index.md无需更新（readme.md条目已存在15处）；步骤5完成：overview.md已有大量The Agency内容，无需修订；步骤6完成：Aider新Entity，其余已有Entity已patch更新（Claude-Code/The-Agency/GitHubCopilot/OpenClaw/Cursor）；步骤7完成：AgentIntegration和AgentScopes两个Concept创建；步骤8完成：冲突已在Source Page记录；步骤9完成：log.md追加记录。错误纠正：最初错误创建了TheAgency.md/ClaudeCode.md（命名应为The-Agency.md/Claude-Code.md），后已删除并patch已有正确命名文件。
|
||
|
||
## [2026-04-30] ingest | Academic Historian
|
||
- Source file: Agent/agency-agents/academic/academic-historian.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Academic Historian Agent 摄入——专业历史研究 AI Agent，为创意项目提供历史真实性验证、时代背景丰富化和历史迷思纠正。核心方法论：Annales 学派（物质文化、日常生活史）、长时段分析（longue durée）、微观史、历史编纂学（historiography）。核心理念：物质条件决定论、主动挑战欧洲中心主义、神话亦是史料、所有论断必须标注置信度和来源类型。五步工作流：建立时空坐标→核查物质基础→叠加社会结构→评估论断→标注置信度。典型交付物：Period Authenticity Report、Historical Coherence Check。
|
||
- Concepts created: [[Microhistory]]、[[Historiography]]、[[Counterfactual-Analysis]]、[[Material-Culture]]、[[Presentism]]
|
||
- Concepts already existed: [[Annales-School]]（已更新，加入 Microhistory 和 Material Culture 关系）、[[Longue-Duree]]（引用）
|
||
- Entities created: 无（Braudel/Pirenne/Wickham 各自仅出现1次，未达2次阈值）
|
||
- Entities already existed: 无
|
||
- Source page: wiki/sources/academic-historian.md
|
||
- Notes: 步骤1完成：读取原始文档（123行）；步骤2完成：读取 index.md（Line 11 光标）、overview.md（Line 467 已有详细条目，无需修订）；步骤3完成：source page 创建于 wiki/sources/academic-historian.md；步骤4完成：index.md 在 Academic Psychologist 后插入完整描述条目；步骤5完成：overview.md 无需修订（Line 467 已有覆盖）；步骤6完成：Entity 页面未创建（Braudel/Pirenne/Wickham 各仅1次引用）；步骤7完成：5个新 Concept 页面创建（Microhistory/Historiography/Counterfactual-Analysis/Material-Culture/Presentism），Annales-School.md 已更新；步骤8完成：已在 Source Page Contradictions 节记录与 Narratologist（叙事节奏 vs 历史准确性）和 Psychologist（心理学分析 vs 史料局限性）的潜在冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-30] ingest | Academic Narratologist
|
||
- Source file: Agent/agency-agents/academic/academic-narratologist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Academic Narratologist Agent 摄入——专业叙事理论与故事结构分析 AI Agent，以工程师拆解系统的方式剖析叙事。整合 Russian Formalism、French Structuralism、Cognitive Narratology、Campbell Monomyth、Propp's Morphology、McKee's Controlling Idea、Genette's Narratology、Barthes' Five Codes 等经典框架。核心原则：每个建议必须引用至少一个命名框架；叙事问题通常在讲述层（sjuzhet）而非故事层（fabula）；精确而非泛泛。
|
||
- Concepts created: [[NarrativeTheory]]、[[HeroesJourney]]、[[ProppMorphology]]、[[ThreeActStructure]]、[[CharacterArc]]、[[ControllingIdea]]、[[Fabula-vs-Sjuzhet]]、[[Kishotenketsu]]
|
||
- Concepts already existed: [[Character-Arc]]（已有页面被复用）
|
||
- Entities created: [[JosephCampbell]]、[[VladimirPropp]]、[[RobertMcKee]]、[[ChristopherVogler]]、[[GerardGenette]]、[[RolandBarthes]]
|
||
- Entities already existed: 无
|
||
- Source page: wiki/sources/academic-narratologist.md
|
||
- Notes: 步骤1完成：读取原始文档（118行）；步骤2完成：读取 index.md（Line 7 已有 Academic Anthropologist 条目光标）、overview.md（规模庞大，单一 agent 源无需更新综合摘要）；步骤3完成：source page 创建于 wiki/sources/academic-narratologist.md；步骤4完成：index.md 在 Academic Anthropologist 后插入完整描述条目；步骤5完成：overview.md 无需修订；步骤6完成：6个 Entity 页面创建（JosephCampbell/VladimirPropp/RobertMcKee/ChristopherVogler/GerardGenette/RolandBarthes）；步骤7完成：8个新 Concept 页面创建（Fabula-vs-Sjuzhet/HeroesJourney/Kishotenketsu/NarrativeTheory/ProppMorphology/ThreeActStructure/ControllingIdea），Character-Arc 已有页面被复用；步骤8完成：未检测到与其他页面的内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-25] ingest | Academic Anthropologist
|
||
- Source file: Agent/agency-agents/academic/academic-anthropologist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Academic Anthropologist Agent 摄入——文化人类学驱动的社会文化系统设计 Agent，基于 Levi-Strauss 结构主义、Geertz 符号人类学、Bourdieu 实践理论、Malinowski/Durkheim 功能主义、Mauss 礼物经济、Turner 阈限理论、Polanyi 交换分类等核心理论框架，为 AI Agent 提供文化设计方法论。核心原则：功能优先于美学、亲属制度是基础设施、无文化沙拉、无 Noble Savage 谬误。
|
||
- Concepts created: [[Structuralism]]、[[Symbolic-Anthropology]]、[[Practice-Theory]]、[[Functionalism]]、[[Gift-Economy]]、[[Liminality]]、[[Kinship-System]]、[[Cultural-Ecology]]、[[Polanyi-Exchange]]
|
||
- Concepts already existed: 无
|
||
- Entities created: [[Claude-Levi-Strauss]]、[[Clifford-Geertz]]、[[Pierre-Bourdieu]]、[[Victor-Turner]]、[[Bronislaw-Malinowski]]、[[Marcel-Mauss]]、[[Mary-Douglas]]
|
||
- Entities already existed: 无
|
||
- Source page: wiki/sources/academic-anthropologist.md
|
||
- Notes: 步骤1完成：读取原始文档（125行）；步骤2完成：读取 index.md（Line 8 已有条目光标）、overview.md（Line 471 已有详细记录无需修订）；步骤3完成：source page 创建于 wiki/sources/academic-anthropologist.md；步骤4完成：index.md 在 Academic Psychologist 后插入完整描述条目；步骤5完成：overview.md 无需修订（Line 471 已有覆盖）；步骤6完成：7个 Entity 页面创建（Claude-Levi-Strauss/Clifford-Geertz/Pierre-Bourdieu/Victor-Turner/Bronislaw-Malinowski/Marcel-Mauss/Mary-Douglas）；步骤7完成：9个 Concept 页面创建；步骤8完成：未检测到与其他页面的内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-03] ingest | Academic Geographer
|
||
- Source file: Agent/agency-agents/academic/academic-geographer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Academic Geographer Agent 摄入——物理与人文地理系统构建专家 AI Agent，帮助在 Agent 世界构建中保持地理要素（气候、地形、水系、生物群落、聚落模式）的物理一致性。六步工作流：板块构造→气候系统→水文学→生物群落→人类聚落→贸易路线。核心规则：河流不分离、气候是系统、避免地理决定论。
|
||
- Concepts created: 无（所有 Key Concepts 均内联于 Source Page，未创建独立 Concept 页面）
|
||
- Concepts already existed: [[EnvironmentalDeterminism]]（引用）
|
||
- Entities created: 无
|
||
- Entities already existed: [[JaredDiamond]]（引用）、[[Acemoglu]]（引用）
|
||
- Source page: wiki/sources/academic-geographer.md
|
||
- Notes: 步骤1完成：读取原始文档（127行）；步骤2完成：读取 index.md（已了解上下文）、overview.md（规模庞大，单一 agent 源无需更新综合摘要）；步骤3完成：source page 创建于 wiki/sources/academic-geographer.md；步骤4完成：index.md 在 Academic Narratologist 前插入完整描述条目；步骤5完成：overview.md 无需修订；步骤6-7完成：Entity/Concept 均为引用而非独立创建（该 Agent 为理论框架型，内容已内联在 Source Page）；步骤8完成：与 Acemoglu 的制度决定论冲突已记录；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-01] ingest | Behavioral Nudge Engine
|
||
- Source file: Agent/agency-agents/product/product-behavioral-nudge-engine.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Behavioral Nudge Engine agent 摄入——行为心理学驱动的用户动机引擎，通过 Micro-Sprint、Default Bias 利用、Nudge Sequence 和即时正强化来最大化任务完成率并降低平台流失。核心方法：认知负荷降低、时间盒、微冲刺、渐进式多渠道触达。
|
||
- Concepts created: [[Micro-Sprint]]、[[Default-Bias]]、[[Nudge-Sequence]]、[[Cognitive-Load-Reduction]]、[[Habit-Formation]]
|
||
- Concepts already existed: 无
|
||
- Entities created: 无
|
||
- Entities already existed: 无
|
||
- Source page: wiki/sources/product-behavioral-nudge-engine.md
|
||
- Notes: 步骤1完成：读取原始文档（80行）；步骤2完成：读取 index.md（Line 419 已有条目）、overview.md（规模庞大，单一 agent 源无需更新综合摘要）；步骤3完成：source page 创建于 wiki/sources/product-behavioral-nudge-engine.md；步骤4完成：index.md 条目补充完整描述；步骤5完成：overview.md 无需修订；步骤6-7完成：5个新 Concept 页面创建（无新 Entity）；步骤8完成：未检测到冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-02] ingest | Product Sprint Prioritizer Agent（增量更新）
|
||
- Source file: Agent/agency-agents/product/product-sprint-prioritizer.md
|
||
- Status: ✅ 增量更新
|
||
- Summary: Product Sprint Prioritizer Agent 增量更新（date: 2026-04-25 → 2026-05-02）——扩充 Key Claims（4→6条，新增技术债务管理和容量约束理念）、Key Quotes（3→4条，新增干系人满意度指标）、Key Concepts（6→10个，新增 Capacity Planning/Dependency Analysis/Risk Management 及各框架细化描述）、Key Entities（新增 Sprint Prioritizer 角色实例）、Connections（3→5条，新增与 workflow-startup-mvp/产品反馈综合分析的关系）、Contradiction（从无→1条，详细记录与 product-feedback-synthesizer 的优先级框架张力及协调建议）。
|
||
- Entities created: 无（[[Sprint-Prioritizer]] 已在现有记录）
|
||
- Entities already existed: [[Sprint-Prioritizer]]、[[Product-Manager-Agent]]
|
||
- Concepts created: 无（Key Concepts 均引用/关联现有 Concept 页面）
|
||
- Concepts already existed: [[RICE-Framework]]、[[MoSCoW-Method]]、[[Kano-Model]]、[[SprintPlanning]]、[[Team-Velocity]]
|
||
- Source page: wiki/sources/product-sprint-prioritizer.md
|
||
- Notes: 步骤1完成：读取原始文档（153行）；步骤2完成：读取 index.md（Line 418 已有条目）、overview.md（Line 211 已有详细条目）；步骤3完成：source page 全面扩充（新增6条 Key Claims、4条 Key Quotes、10个 Key Concepts、Key Entities 扩充、5条 Connections、详细 Contradiction）；步骤4完成：index.md 日期更新为 2026-05-02；步骤5完成：overview.md 条目已完整，无需修订；步骤6-7完成：Entity/Concept 页面均已存在，无需创建；步骤8完成：与 [[product-feedback-synthesizer]] 优先级框架张力已详细记录，含协调建议；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-02] ingest | Product Trend Researcher Agent（增量更新）
|
||
- Source file: Agent/agency-agents/product/product-trend-researcher.md
|
||
- Status: ✅ 增量更新
|
||
- Summary: Product Trend Researcher Agent 增量更新（date: 2026-04-25 → 2026-04-30）—— 文档内容较上次无实质性变更，仅更新文档日期。source page 内容保持不变，index.md 日期同步更新为 2026-04-30。
|
||
- Entities created: 无
|
||
- Entities already existed: 无（[[TheAgency]]/[[ProductManagerAgent]]/[[AgentsOrchestrator]] 已在现有 source page 引用）
|
||
- Concepts created: 无
|
||
- Concepts already existed: 无（Key Concepts 均已引用现有/潜在页面）
|
||
- Source page: wiki/sources/product-trend-researcher.md
|
||
- Notes: 步骤1完成：读取原始文档（158行）；步骤2完成：读取 index.md（line 417 已有条目）、overview.md（line 207 已有详细条目）；步骤3完成：source page date 更新（2026-04-25 → 2026-04-30），内容不变；步骤4完成：index.md 日期更新；步骤5完成：overview.md 条目已完整，无需修订；步骤6-7完成：无新 Entity/Concept 页面创建；步骤8完成：无新增冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-01] ingest | Product Feedback Synthesizer Agent（增量更新）
|
||
- Source file: Agent/agency-agents/product/product-feedback-synthesizer.md
|
||
- Status: ✅ 增量更新
|
||
- Summary: Product Feedback Synthesizer Agent 增量更新（date: 2026-04-20 → 2026-04-30）——扩充至 6 条 Key Claims（原 4 条）、4 条 Key Quotes（原 1 条）、14 个 Key Concepts（原 9 个，新增 ThematicAnalysis/FeaturePrioritization/CompetitiveFeedback/CSAT/CES）、5 条 Connections（原 3 条，新增 product-behavioral-nudge-engine 和 Agents-Orchestrator）、Contradiction 补充建议协调方案。overview.md 条目同步扩充五步流水线/多格式交付/优先级张力说明。
|
||
- Entities created: 无（The-Agency 作为框架背景引用，未达≥2次阈值）
|
||
- Entities already existed: 无
|
||
- Concepts created: 无（Key Concepts 已在 source page 充分记录）
|
||
- Concepts already existed: 无
|
||
- Source page: wiki/sources/product-feedback-synthesizer.md
|
||
- Notes: 步骤1完成：读取原始文档（118行）；步骤2完成：读取 index.md（Sources 节 Line 418 已有条目，日期更新）、overview.md（The Agency — Product 部门节 Line 205）；步骤3完成：source page 全面扩充（新增 date 更新、6条 Key Claims、4条 Key Quotes、14个 Key Concepts、5条 Connections、扩充 Contradiction）；步骤4完成：index.md Sources 节日期更新为 2026-04-30；步骤5完成：overview.md 条目扩充（新增五步流水线/多格式交付/优先级张力协调说明）；步骤6-7完成：无新 Entity/Concept 页面创建；步骤8完成：与 [[product-sprint-prioritizer]] 优先级框架张力已记录，补充建议协调方案；步骤9完成：log.md 追加记录
|
||
|
||
|
||
- Source file: Agent/agency-agents/specialized/automation-governance-architect.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Automation Governance Architect 完整摄取——n8n-first 的业务自动化治理架构师，核心理念"治理优于自动化数量"。核心能力：四维评估框架（时间节省 / 数据关键性 / 外部依赖风险 / 可扩展性）+ 五级裁定结果（APPROVE/APPROVE AS PILOT/PARTIAL AUTOMATION ONLY/DEFER/REJECT）+ n8n 工作流十步标准 + 可靠性基线 + 日志基线 + 测试基线 + 集成治理规范（Source of Truth）+ 复审触发器。Source page 含 7 条 Key Claims、4 条 Key Quotes、9 个 Key Concepts、1 个 Key Entity、5 条 Connections、1 条 Contradiction。
|
||
- Entities created: [[Automation-Governance-Architect]]
|
||
- Entities already existed: 无
|
||
- Concepts created: [[n8n-Workflow-Standard]]（n8n 生产级工作流十步标准）、[[Automation-Decision-Framework]]（四维自动化评估框架）、[[Automation-Verdict-System]]（五级自动化裁定结果体系）
|
||
- Concepts already existed: 无
|
||
- Source page: wiki/sources/automation-governance-architect.md
|
||
- Notes: 步骤1完成：读取原始文档（216行）；步骤2完成：读取 index.md（Sources 节已有条目 Line 413）、overview.md（追加综合摘要条目27）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×7、Key Quotes×4、Key Concepts×9、Key Entities×1、Connections×5、Contradictions×1）；步骤4完成：index.md Sources 节已有 automation-governance-architect 条（Line 413，无需重复添加）；步骤5完成：overview.md 追加综合摘要条目27；步骤6-7完成：新建 1 个 Entity 页面（Automation-Governance-Architect）和 3 个 Concept 页面（n8n-Workflow-Standard/Automation-Decision-Framework/Automation-Verdict-System），index.md Entities 和 Concepts 节同步更新；步骤8完成：与 [[Workflow-Architect-Agent-Personality]] 存在互补张力，已记录至 Contradictions；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-01] ingest | Report Distribution Agent
|
||
- Source file: Agent/agency-agents/specialized/report-distribution-agent.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Report Distribution Agent 完整摄取——销售报告自动化分发 Agent，基于区域（Territory）路由将整合后的报告精准发送给对应业务员。核心能力：Territory-Based Routing（区域路由）、Scheduled Distribution（每日早8点/每周一早7点）、Audit Trail（分发日志）、Graceful Failure（失败继续）、HTML Email Reports（STGCRM 品牌规范）。Source page 含 6 条 Key Claims、3 条 Key Quotes、5 个 Key Concepts、3 个 Key Entities、3 条 Connections。
|
||
- Entities created: 无（Data Consolidation Agent 仅引用1次，未达阈值；STGCRM 仅作品牌标识）
|
||
- Entities already existed: 无
|
||
- Concepts created: 无（Key Concepts 已在 source page 充分记录，未创建独立页面）
|
||
- Concepts already existed: 无
|
||
- Source page: wiki/sources/report-distribution-agent.md
|
||
- Notes: 步骤1完成：读取原始文档（65行）；步骤2完成：读取 index.md（Sources 节新增）、overview.md（追加综合摘要条目26）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×6、Key Quotes×3、Key Concepts×5、Key Entities×3、Connections×3、Contradictions）；步骤4完成：index.md Sources 节新增 report-distribution-agent 条（Line 7）；步骤5完成：overview.md 追加综合摘要条目26；步骤6-7完成：无新 Entity/Concept 页面创建（均未达阈值或已在 source page 覆盖）；步骤8完成：无跨页面内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-25] ingest | Supply Chain Strategist Agent
|
||
- Source file: Agent/agency-agents/specialized/supply-chain-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Supply Chain Strategist Agent 完整摄取——The Agency Specialized 部门的供应链管理专家 Agent，专注中国制造业生态。核心能力：供应商开发与分级管理（ABC/QCD）、战略采购（Kraljic 矩阵/TCO）、质量管理（IQC/IPQC/OQC/AQL）、库存优化（EOQ/安全库存/再订货点）、物流仓储（WMS）、供应链数字化（ERP/SRM/L1-L5）、成本控制与风险管理。Source page 含 5 条 Key Claims、4 条 Key Quotes、14 个 Key Concepts、12 个 Key Entities、7 条 Connections。
|
||
- Entities created: [[Supply-Chain-Strategist]]（The Agency Specialized 部门供应链专家 Agent）、[[QiChaCha]]（企查查，供应商资质验证）、[[Tianyancha]]（天眼查，供应商资质验证）
|
||
- Entities already existed: 无
|
||
- Concepts created: [[Kraljic-Matrix]]（供应商分类与采购战略框架，四象限矩阵）
|
||
- Concepts already existed: [[TCO]]（已存在云计算 TCO 框架，本次补充供应链采购 TCO 应用，无冲突）
|
||
- Source page: wiki/sources/supply-chain-strategist.md
|
||
- Notes: 步骤1完成：读取原始文档（582行）；步骤2完成：读取 index.md（条目已存在 Line 396）、overview.md（无供应链相关内容，需追加）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×5、Key Quotes×4、Key Concepts×14、Key Entities×12、Connections×7、Contradictions）；步骤4完成：index.md Sources 节新增 supply-chain-strategist 条（Line 7）；步骤5完成：overview.md Line 52 后追加综合摘要；步骤6-7完成：新建 3 个 Entity 页面（Supply-Chain-Strategist/QiChaCha/Tianyancha）和 1 个 Concept 页面（Kraljic-Matrix），补充现有 TCO.md 的供应链场景应用；index.md Entities 和 Concepts 节同步更新；步骤8完成：无跨页面内容冲突，TCO 跨场景应用已标注；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-30] ingest | Marketing Bilibili Content Strategist
|
||
- Source file: Agent/agency-agents/marketing/marketing-bilibili-content-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: B站内容策略与UP主成长专家Agent人格定义——弹幕文化精通、B站算法优化（完播率/三连/投币权重）、封面点击率优化、社区驱动增长、品牌恰饭原生化。核心理念：社区优先、质量优先、尊重弹幕文化。关键指标：三连率>5%、弹幕密度>30条/分钟关键片段、每月至少一条视频进入"每周必看"。与抖音、快手构成中国短视频营销差异化平台策略体系。
|
||
- Entities: [[Bilibili]]（已存在，last_updated更新至2026-05-30，sources字段追加marketing-bilibili-content-strategist）；Douyin/Kuaishou/WeChat/Weibo/Xiaohongshu均已存在，无需新建Entity页面
|
||
- Concepts: 弹幕设计/三连/UP主品牌/花火平台/内容垂类/直播带货/跨平台协同——各仅在本source page提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用，无需独立Concept页
|
||
- Source page: wiki/sources/marketing-bilibili-content-strategist.md
|
||
- Notes: 步骤1-9全部完成；source page已生成，含6个Key Claims、4个Key Quotes、8个Key Concepts（wikilink格式）、8个Key Entities（wikilink格式）、5条Connections、2组Contradictions（与Douyin/Kuaishou平台差异张力）；index.md第472行已有条目，本次更新日期和一行摘要；overview.md第869行已有详细条目，本次确认内容一致；Entity Bilibili.md的last_updated和sources字段已更新；log.md已追加。
|
||
- Source file: Agent/agency-agents/specialized/zk-steward.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: ZK Steward Agent 完整摄取——将 Niklas Luhmann 的 Zettelkasten 卡片盒笔记法引入 AI Agent，用于构建有链接、可验证、持续生长的知识网络。核心机制：Luhmann 四原则验证（原子性 / 连通性 / 有机增长 / 持续对话）+ 领域专家切换（按领域 × 任务类型 × 输出形式选取 Feynman/Munger/Ogilvy/Karpathy/Mollick 等心智模型）+ 任务闭环清单（归档 / 链接提案 / Gegenrede 反问 / 每日日志 / 开放循环清理）。Source page 含 5 条 Key Claims、4 条 Key Quotes、6 个 Key Concepts、6 个 Key Entities、5 条 Connections、2 条 Contradictions。
|
||
- Entities created: [[Richard-Feynman]]（物理学诺奖得主，first principles / teach to learn 方法）、[[Charlie-Munger]]（伯克希尔副主席，mental models / inversion 策略）、[[David-Ogilvy]]（奥美创始人，long copy / brand persona 品牌法）、[[Andrej-Karpathy]]（AI 研究员，first-principles engineering / deep-learning）、[[Ethan-Mollick]]（沃顿副教授，structured prompts / persona pattern prompting）
|
||
- Entities already existed: [[Niklas-Luhmann]]、[[zk-steward-companion]]（sources 字段追加 zk-steward）
|
||
- Concepts created: [[Atomic-Note]]（原子笔记：最小自包含知识单元，≥2 条链接，Luhmann 四原则原子性的直接体现）
|
||
- Concepts already existed: [[Zettelkasten]]、[[Luhmann-四原则]]、[[Gegenrede]]、[[Domain-Thinking]]、[[Link-Proposer]]、[[Daily-Log]]（sources 字段均已追加 zk-steward）
|
||
- Source page: wiki/sources/zk-steward.md
|
||
- Notes: 步骤1完成：读取原始文档（211行）；步骤2完成：读取 index.md（zk-steward 源条目已存在于 Line 395，source page 不存在，需新建）、overview.md（无 ZK Steward 相关内容，需追加）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×5、Key Quotes×4、Key Concepts×6、Key Entities×6、Connections×5、Contradictions×2）；步骤4完成：index.md Entities 节新增 Charlie-Munger/David-Ogilvy/Ethan-Mollick/Richard-Feynman 条，Concepts 节新增 Atomic-Note 条；步骤5完成：overview.md 追加 #25 ZK Steward Agent 综合摘要（469字节）；步骤6-7完成：新建 5 个 Entity 页面和 1 个 Concept 页面；步骤8完成：无跨页面内容冲突，与 AgentsOrchestrator 的"结构 vs 自组织"张力已记录于 Contradictions；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-25] ingest | French Consulting Market Navigator
|
||
- Source file: Agent/agency-agents/specialized/specialized-french-consulting-market.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: French Consulting Market Navigator 完整摄取——The Agency Specialized 部门的法国 ESN/SI 生态系统导航 Agent，帮助独立 IT 顾问最大化日均净收入（TJM）、最小化付款风险。核心方法：ESN 分层定价架构（Tier 1/2/3）+ 五平台对比矩阵（Malt/collective.work/Comet/Crème/Free-Work）+ TJM Brut vs Net 量化拆解（Portage Salarial vs Micro-Entreprise）+ 季节性市场日历。Source page 含 5 条 Key Claims、4 条 Key Quotes、6 个 Key Concepts、7 个 Key Entities、4 条 Connections。
|
||
- Entities created: [[Agentforce]]（Salesforce AI Agent 产品线，700-850 EUR/天 TJM 高端方向）、[[Malt]]（欧洲最大自由职业平台，10%客户侧佣金，费率公开可见）、[[Salesforce]]（CRM 平台，法国 ESN 生态核心商业技术栈）
|
||
- Concepts created: [[Portage-Salarial]]（法国薪资代理机制，净收入约 50% TJM，含失业保险）、[[Micro-Entreprise]]（法国微型企业家制度，净收入约 70% TJM，无失业保险）、[[TJM]]（平均日费率，含 Brut/Net 区分公式和分专项定价基准）
|
||
- Concepts updated: [[ESN]]（已存在，sources 字段追加 specialized-french-consulting-market，无需新建）
|
||
- Source page: wiki/sources/specialized-french-consulting-market.md
|
||
- Notes: 步骤1完成：读取原始文档（192行）；步骤2完成：读取 index.md（条目已存在 Line 396）、overview.md（Line 947 已有综合摘要，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×5、Key Quotes×4、Key Concepts×6、Key Entities×7、Connections×4、Contradictions）；步骤4完成：index.md Line 396 已有条目，无需修改；步骤5完成：overview.md Line 947 已有完整综合摘要，无需修订；步骤6-7完成：新建 3 个 Entity 页面（Agentforce/Malt/Salesforce）和 3 个 Concept 页面（Portage-Salarial/Micro-Entreprise/TJM），index.md Entities 和 Concepts 节同步更新；步骤8完成：无跨页面内容冲突（ESN.md 已存在，追加 sources 引用）；步骤9完成：log.md 追加记录
|
||
- Deleted: concepts/ESN-SI.md（与已存在的 concepts/ESN.md 重复，以已有页面为准）
|
||
|
||
## [2026-05-30] ingest | Blockchain Security Auditor
|
||
- Source file: Agent/agency-agents/specialized/blockchain-security-auditor.md
|
||
- Status: ✅ 成功摄入（增量更新）
|
||
- Summary: Blockchain Security Auditor 增量更新——原 source page 2026-04-20 已存在，463行原始文档对比后大幅扩充，新增：完整审计报告模板（Severity分类表/Foundry PoC）、Slither综合分析脚本（高/中置信度检测器分类）、访问控制审计清单（Role Hierarchy/Initialization/Upgrade Controls/External Calls）、EVM层漏洞（存储冲突/签名重放/跨链消息重放/Gas Griefing）、形式化验证工具链（Certora/Halmos/KEVM）、事件响应流程（溯源分析/救援合约）、高级攻击技术（只读重入/治理攻击/MEV提取）。Source page扩充至7,129字节，新增Key Claims×5条（Sol 0.8+ unchecked块审查/字节码一致性验证/误报率10%上限）、Key Concepts×5个（Storage Collision/Signature Malleability/Cross-Chain Replay/Formal Verification/SWC Registry）、Key Entities×2个（Certora/Foundry）、Connections×2条（形式化验证方法论/SWC Registry参考）。
|
||
- Concepts created: [[Formal-Verification]]（形式化验证：符号执行+不变式规范数学证明合约属性正确性）、[[Access-Control]]（访问控制：5类漏洞模式+审计清单+Severity分类）、[[Flash-Loan-Attack]]（闪电贷攻击：单笔交易内无抵押借款操纵市场，含Oracle Manipulation/Donate-to-Reserves/Governance三种常见变体）、[[Slither]]（Slither静态分析框架：高/中置信度检测器详解+综合脚本）、[[Mythril]]（Mythril符号执行分析：与Slither对比+使用方法）、[[Echidna]]（属性化模糊测试：不变性验证+Foundry集成）、[[Certora]]（Certora形式化验证工具：CVL规范语言+反例生成）、[[SWC-Registry]]（智能合约弱点分类标准：SWC-100至SWC-115关键分类）
|
||
- Entities created: [[Certora]]（形式化验证平台）、[[Foundry]]（Solidity开发框架，主要用于PoC攻击测试）
|
||
- Source page: wiki/sources/blockchain-security-auditor.md
|
||
- Notes: 步骤1完成：读取原始文档（463行）；步骤2完成：读取 index.md（条目已存在于Line 412，日期2026-04-20）、overview.md（Line 931已有综合摘要，全面扩充）；步骤3完成：更新source page（date: 2026-04-20→2026-05-30，补充新增内容）；步骤4完成：index.md Entities节新增Certora/Foundry条（Line 661/705），Concepts节新增Access-Control/Checks-Effects-Interactions/Echidna/Flash-Loan-Attack/Formal-Verification/Foundry/Mythril/Slither/SWC-Registry共9条；步骤5完成：overview.md Line 931综合摘要扩充，新增交付物详情、形式化验证高级能力、漏洞评级严格化规则；步骤6-7完成：新建8个Concept页面和2个Entity页面；步骤8完成：发现与Compliance Auditor的关注点差异和漏洞评级沟通张力，已记录于Contradictions；步骤9完成：log.md追加记录
|
||
|
||
## [2026-05-30] ingest | Sales Data Extraction Agent
|
||
- Source file: Agent/agency-agents/specialized/sales-data-extraction-agent.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Sales Data Extraction Agent 完整摄取——AI Agent 角色定义，专注于监控 Excel 文件并提取销售指标（MTD/YTD/Year End）用于内部实时报表。技术实现：文件系统监控（忽略 ~$ 锁文件）→ 模糊列名匹配 → 指标类型自动识别 → PostgreSQL 事务持久化 → 下游 Agent 事件通知。核心原则：从不覆盖已有数据（仅在新文件版本时更新）、所有操作记录完整审计追踪（文件名/处理行数/失败行数/时间戳）。成功指标：100% 无人工干预处理、<2% 行级失败、<5 秒单文件处理时间、完整审计链。
|
||
- Entities created: 无（PostgreSQL/ReportDistributionAgent 为已知商业产品/跨 Agent，未达到创建 Entity 页面阈值）
|
||
- Source page: wiki/sources/sales-data-extraction-agent.md
|
||
- Notes: 步骤1完成：读取原始文档（67行）；步骤2完成：读取 index.md（条目已存在于 Line 398，正式条目无需修改）、overview.md（1139行，无冲突内容无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×5条、Key Quotes×3条、Key Concepts×6个、Key Entities×2个、Connections×3条、Contradictions）；步骤4完成：index.md Line 398 已是正式条目，无需修改；步骤5完成：overview.md 无冲突内容，无需修订；步骤6-7完成：无需创建新 Entity/Concept 页面（所有 Key Concepts 均为本 Agent 特有实现细节不具备跨 Wiki 可复用性）；步骤8完成：无跨页面内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Study Abroad Advisor
|
||
- Source file: Agent/agency-agents/specialized/study-abroad-advisor.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Study Abroad Advisor Agent 增量更新——原 source page 2026-04-25 已存在，对比 282 行原始文档全面扩充：新增四步工作流详细说明、标准化交付模板（选校报告/多国申请时间线/文书诊断/Offer比较矩阵）、标准化考试策略（TOEFL/IELTS/GRE/GMAT/SAT）、Profile提升规划（研究/实习/竞赛）、诚信原则（不代写/不承诺结果/不虚构）。Source page 扩充至 6,236 字节，新增 Key Claims×2条、Key Concepts×2个（Taoxi/Three-Tier-School-Selection）、Key Entities×1个（NUS/NTU）。
|
||
- Concepts created: [[Taoxi]]（留学申请中主动联系目标导师的套磁策略，含邮件模板和时机建议）、[[Three-Tier-School-Selection]]（三档选校策略：Reach/Target/Safety，概率区间表达法及选校心理维度）
|
||
- Entities created: [[1point3acres]]（一亩三分地留学社区，录取数据库和薪资数据平台）、[[NUS-NTU]]（新加坡国立大学与南洋理工大学，亚洲顶尖院校对比）
|
||
- Source page: wiki/sources/study-abroad-advisor.md
|
||
- Notes: 步骤1完成：读取原始文档（282行）；步骤2完成：读取 index.md（条目已存在于 Line 392，日期 2026-04-25）、overview.md（已有综合摘要无需修订）；步骤3完成：更新 source page（date: 2026-04-25→2026-05-29，补充新增内容）；步骤4完成：index.md Sources 节补全日期前缀和一行摘要；步骤5完成：overview.md 已有综合摘要无需修订；步骤6-7完成：新建 2 个 Entity（1point3acres/NUS-NTU）和 2 个 Concept（Taoxi/Three-Tier-School-Selection），index.md Entities 和 Concepts 节同步更新；步骤8完成：发现一处内部张力已记录于 Contradictions（成功率指标 vs 不承诺录取）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Agents Orchestrator
|
||
- Source file: Agent/agency-agents/specialized/agents-orchestrator.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AgentsOrchestrator Agent 增量更新——原 source page 2026-04-20 已存在，对比 366 行原始文档补充了 Available Specialist Agents 章节（Design&UX/Engineering/Marketing/PM/Testing 五类共 20+ Agent）和 Orchestrator Launch Command 章节。核心概念：四阶段流水线（PM→ArchitectUX→[Dev↔QA循环]→最终集成）、最大3次重试质量门控、截图驱动型 QA 验证。
|
||
- Concepts created: [[Dev-QA-Loop]]（开发与质量验证的持续循环机制）、[[Pipeline-State-Management]]（流水线状态追踪管理）、[[Agent-Handoff]]（Agent 交接协议）、[[Continuous-Dev-QA-Loop]]（持续开发质量循环）
|
||
- Entities created: [[AgentsOrchestrator]]（编排器自身）、[[EvidenceQA]]（截图质量验证 Agent）、[[TestingRealityChecker]]（最终集成验证 Agent）、[[MobileAppBuilder]]（移动应用构建 Agent）、[[DevOpsAutomator]]（DevOps 自动化 Agent）
|
||
- Concepts updated: [[Quality-Gate]]（追加 sources: agents-orchestrator）
|
||
- Source page: wiki/sources/agents-orchestrator.md
|
||
- Notes: 步骤1完成：读取原始文档（366行）；步骤2完成：读取 index.md（条目已存在于 Line 413）和 overview.md（Line 122 已有完整综合摘要，无需修订）；步骤3完成：更新 source page（date: 2026-04-20→2026-05-29，补充 Available Specialist Agents 和 Launch Command）；步骤4完成：index.md Entities 节新增 5 条目（AgentsOrchestrator/DevOpsAutomator/EvidenceQA/MobileAppBuilder/TestingRealityChecker），Concepts 节新增 4 条目（Agent-Handoff/Continuous-Dev-QA-Loop/Dev-QA-Loop/Pipeline-State-Management）；步骤5完成：overview.md Line 122 已有完整综合摘要，无需修订；步骤6-7完成：新建 5 个 Entity 页面和 4 个 Concept 页面；步骤8完成：无跨页面内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Compliance Auditor Agent
|
||
- Source file: Agent/agency-agents/specialized/compliance-auditor.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: ComplianceAuditor Agent 完整摄取——AI Agent 角色定义，技术合规审计员，指导组织完成 SOC 2、ISO 27001、HIPAA、PCI-DSS 等安全与隐私认证流程。五步工作流（范围界定→差距评估→修复支持→审计支持→持续合规），核心原则：实质重于形式、自动化证据收集优先、按风险适配控制复杂度。交付物：差距评估报告、证据收集矩阵、政策模板。
|
||
- Concepts created: [[SOC2]]（AICPA 信任服务标准认证框架，5个信任服务标准）、[[GapAssessment]]（系统化评估组织当前安全态势与目标框架要求之间差距的分析过程）、[[EvidenceCollection]]（合规审计中提取、记录和整理证据材料的过程，自动化优先原则）
|
||
- Source page: wiki/sources/compliance-auditor.md
|
||
- Notes: 步骤1完成：读取原始文档（158行）；步骤2完成：读取 index.md（条目已存在于 Line 410）和 overview.md（1139行，已检查无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×6条、Key Quotes×4条、Key Concepts×9个、Key Entities×1个、Connections×6条、Contradictions）；步骤4完成：index.md Sources 节新增 compliance-auditor 条目（2026-04-30），位于 Specialized Salesforce Architect 之后；步骤5完成：overview.md 1139行已检查，无与 compliance-auditor 冲突的内容，无需修订；步骤6-7完成：新建 SOC2/GapAssessment/EvidenceCollection 三个 Concept 页面，index.md Concepts 节同步更新；步骤8完成：无已知冲突页面；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Model QA Specialist
|
||
- Source file: Agent/agency-agents/specialized/specialized-model-qa.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Model QA Specialist 完整摄取——The Agency Specialized 部门的 ML 模型全生命周期端到端独立审计专家 Agent。核心方法：10 大审计领域（文档治理→数据重建→标签分析→分段评估→特征分析→模型复制→校准测试→性能监控→可解释性与公平性→商业影响），配套完整 Python 工具集（PSI + SHAP + PDP + Hosmer-Lemeshow + Gini/KS）。核心原则：独立性（从不审计自己参与构建的模型）、可复现性（每个分析必须产出可执行脚本）、证据链完整（每个发现必须包含观察→证据→影响评估→建议）。成功指标：审计发现 95%+ 被确认为有效、零部署后失败。本次新增 2 个 Concept 页面（Champion-Challenger/Fairness-Audit），6 个已有 Concept 页面追加来源引用（SHAP/Calibration-Testing/Discrimination-Metrics/Hosmer-Lemeshow-Test/Partial-Dependence-Plots/Population-Stability-Index）。
|
||
- Concepts created: [[Champion-Challenger]]（模型替代评估框架：Champion 保持运行并引入 Challenger 并行评分，通过量化对比决定是否升级）、[[Fairness-Audit]]（跨受保护群体（种族/性别/年龄等）评估模型系统性歧视的方法论）
|
||
- Concepts updated: SHAP/Calibration-Testing/Discrimination-Metrics/Hosmer-Lemeshow-Test/Partial-Dependence-Plots/Population-Stability-Index（均追加 sources 引用至 specialized-model-qa，last_updated 更新至 2026-05-29）
|
||
- Source page: wiki/sources/specialized-model-qa.md
|
||
- Notes: 步骤1完成：读取原始文档（488行）；步骤2完成：读取 index.md（条目已存在于 Line 388）、overview.md（Line 941 已有详细综合摘要，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×4条、Key Quotes×3条、Key Concepts×8个、Key Entities×5个、Connections×8条、Contradictions）；步骤4完成：index.md 条目日期 2026-04-29→补全，Concept 节新增 Champion-Challenger 和 Fairness-Audit 条目；步骤5完成：overview.md Line 941 已有完整综合摘要，无需修订；步骤6-7完成：新建 Champion-Challenger 和 Fairness-Audit 两个 Concept 页面，6 个已有 Concept 页面追加 sources 引用，index.md Concepts 节同步更新；步骤8完成：无跨页面内容冲突（Model QA Specialist 的 QA 方法论与 wiki 中其他来源在技术层面互补而非竞争）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | LSP/Index Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/specialized/lsp-index-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: LSP/Index Engineer Agent 完整摄取——The Agency Specialized 部门的 LSP 客户端编排和语义图谱构建专家，通过 graphd LSP 聚合器将 TypeScript/PHP/Go/Rust/Python 等多语言 LSP 客户端统一编排为语义图谱。核心交付物：多语言 LSP 并发编排 + 统一图谱模式（节点：文件/符号，边：contains/imports/calls/refs）+ nav.index.jsonl 语义索引 + WebSocket 实时增量推送 + 原子性图谱更新保证。性能北极星：/graph <100ms、/nav <20ms（缓存）/60ms（未缓存）、WebSocket <50ms、内存 <500MB、100k+ 符号无降级。本次新增 1 个 Entity 页面（GraphDaemon）、2 个 Language Server Entity（TypeScriptLanguageServer/Intelephense）、5 个 Concept 页面（LanguageServerProtocol/SemanticCodeGraph/LSPOrchestrator/nav.index.jsonl/LSIF/IncrementalGraphUpdate）。
|
||
- Concepts created: [[LanguageServerProtocol]]（LSP 3.17 标准化协议：语言服务器与编辑器之间的 JSON-RPC 通信规范）、[[SemanticCodeGraph]]（语义代码图谱：节点（文件/符号）和边（语义关系）表示代码结构的统一抽象）、[[LSPOrchestrator]]（LSP 编排器：协调多个语言服务器并发运行的中间层）、[[nav.index.jsonl]]（导航索引格式：JSONL 流式存储符号定义/引用/悬停文档）、[[LSIF]]（Language Server Index Format：预计算语义索引标准）、[[IncrementalGraphUpdate]]（增量图谱更新：文件监听器/Git hooks 触发实时增量更新）
|
||
- Entities created: [[GraphDaemon]]（graphd 图谱守护进程：LSP 客户端编排 + HTTP/WebSocket API + 图谱状态管理）、[[TypeScriptLanguageServer]]（TypeScript 语言服务器）、[[Intelephense]]（PHP Intelephense 语言服务器）
|
||
- Source page: wiki/sources/lsp-index-engineer.md
|
||
- Notes: 步骤1完成：读取原始文档（313行）；步骤2完成：读取 index.md（条目已存在于 Line 399，补全日期 [2026-04-29]）、overview.md（Line 943 已有完整综合摘要，第 1114 行 Contradictions 已引用）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×5条、Key Quotes×3条、Key Concepts×6个、Key Entities×3个、Connections×7条、Contradictions）；步骤4完成：index.md 条目补充日期前缀；步骤5完成：overview.md 已有完整综合摘要，无需修订；步骤6-7完成：创建 1 个 Entity（GraphDaemon）、2 个 Language Server Entity（TypeScriptLanguageServer/Intelephense）、6 个 Concept（LanguageServerProtocol/SemanticCodeGraph/LSPOrchestrator/nav.index.jsonl/LSIF/IncrementalGraphUpdate）；步骤8完成：与 specialized-workflow-architect 存在张力（LSP 要求确定性 vs Workflow 穷举存在概率性上限），已记录于 Contradictions；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Specialized Salesforce Architect
|
||
- Source file: Agent/agency-agents/specialized/specialized-salesforce-architect.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Specialized Salesforce Architect Agent 完整摄取——The Agency Specialized 部门的 Salesforce 平台解决方案架构师 Agent，专注于多云平台设计（Sales/Service/Marketing/Data Cloud/Agentforce）、企业级集成模式（REST/Platform Events/CDC/MuleSoft）、数据模型治理和 Governor Limit 感知应用设计。核心原则：Governor Limits 不可妥协（SOQL100/DML150/CPU10s同步）、Bulkification 强制要求、Trigger 委托 Handler 类、声明式优先但代码兜底、集成必须处理失败（重试+熔断+DLQ）。核心交付物：ADR 模板、Integration Pattern Template（含 ASCII 图解）、Data Model Review Checklist、Governor Limit Budget 模板、完整工作流（Discovery→Architecture→Implementation→Review）。成功指标：生产零 Governor Limit 异常、10 倍数据量增长无需重新设计、集成零静默数据丢失、架构文档让新开发者一周内上手。
|
||
- Entities: 无需创建（6 个 Key Entities 均为知名商业产品 MuleSoft/SalesforceDX/DevOpsCenter/ShieldPlatformEncryption/DataCloud/Agentforce，仅出现在此单一来源）
|
||
- Concepts: 无需创建（Key Concepts 中的 GovernorLimits/Bulkification/IntegrationPatternTemplate/ADR/TriggerFramework/DeclarativeFirst/PlatformEvents/ChangeDataCapture/MultiCloudArchitecture/AgentforceArchitecture 通过 wikilink 引用，待后续来源时升级为独立页面）
|
||
- Source page: wiki/sources/specialized-salesforce-architect.md
|
||
- Notes: 步骤1完成：读取原始文档（180行）；步骤2完成：读取 index.md（条目已存在于 Line 389）、overview.md（内容为方法论性质 Agent 人格定义，无需修订综合摘要）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×9条、Key Quotes×3条、Key Concepts×10个、Key Entities×6个、Connections×5条、Contradictions）；步骤4完成：index.md 条目已存在，无需更新；步骤5完成：overview.md 无需修订；步骤6-7完成：无 Entity/Concept 独立页面创建需求；步骤8完成：无跨页面内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Corporate Training Designer
|
||
- Source file: Agent/agency-agents/specialized/corporate-training-designer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Corporate Training Designer 完整摄取——The Agency Specialized 部门的企业培训系统架构师与课程开发专家 Agent，专注企业级培训需求分析、ADDIE/SAM 教学设计模型、混合学习项目、内训师培养（TTT）、领导力发展（HIPO）及 Kirkpatrick 四级培训效果评估。核心价值观：优秀培训的衡量标准不是"教了什么"，而是"学员回去做了什么"。本次新增 5 个 Concept 页面（ADDIE-Model/Kirkpatrick-Model/TTT-Train-the-Trainer/Blended-Learning/Bloom-Taxonomy）。与 [[Bloom-认知分类]] 和 [[Kirkpatrick-四级评估]] 已存在的 Concept 页面存在命名重叠，当前页面采用英文命名（Bloom-Taxonomy/Kirkpatrick-Model）以保持命名规范一致性。
|
||
- Concepts created: [[ADDIE-Model]]（教学设计五阶段框架：分析→设计→开发→实施→评估）、[[Kirkpatrick-Model]]（四级培训评估模型：反应→学习→行为→结果）、[[TTT-Train-the-Trainer]]（内部讲师培养体系）、[[Blended-Learning]]（线上线下融合学习）、[[Bloom-Taxonomy]]（Bloom 认知分类六层次）
|
||
- Source page: wiki/sources/corporate-training-designer.md
|
||
- Notes: 步骤1完成：读取原始文档（192行）；步骤2完成：读取 index.md（条目已存在 Line 409，补全日期和摘要）、overview.md（Line 937 已有完整综合摘要，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×4条、Key Quotes×3条、Key Concepts×12个、Key Entities×8个、Connections×6条、Contradictions）；步骤4完成：index.md 条目补充日期格式和一句话摘要；步骤5完成：overview.md 已有完整综合摘要，无需修订；步骤6-7完成：创建 5 个新 Concept 页面（ADDIE-Model/Kirkpatrick-Model/TTT-Train-the-Trainer/Blended-Learning/Bloom-Taxonomy），index.md Concepts 节已同步更新（TTT-Train-the-Trainer/Blended-Learning）；Bloom-Taxonomy 和 Kirkpatrick-Model 存在已有中文命名页面（Bloom-认知分类/Kirkpatrick-四级评估），当前新增页面采用英文命名以符合命名规范；步骤8完成：无跨页面内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-02] ingest | Workflow Architect Agent Personality
|
||
- Source file: Agent/agency-agents/specialized/specialized-workflow-architect.md
|
||
- Status: ✅ 成功摄入（含更新）
|
||
- Summary: Workflow Architect Agent 完整摄取并更新——The Agency Specialized 部门的工作流设计与系统建模专家，在代码编写前对系统所有路径进行穷举建模。新增内容（对比 2026-04-25 初版）：Agent 协作协议（Security Engineer 审查凭证传递）、好奇心驱动式 Bug 发现方法论（追问数据持久化/网络连通性/时序/认证假设，主动发现高危 Bug）、测试覆盖率原则（每个分支必须有对应测试用例）、假设表缩减成功指标。
|
||
- Concepts created: [[Agent-Collaboration-Protocol]]（Workflow Architect 与 Backend Architect/Security Engineer/API Tester/DevOps Automator 的标准化协作流程）、[[Curiosity-Driven-Bug-Discovery]]（追问四类假设来主动发现高危 Bug）
|
||
- Source page: wiki/sources/specialized-workflow-architect.md
|
||
- Notes: 步骤1完成：读取原始文档（含 lines 501-598 新增内容）；步骤2完成：读取 index.md（条目已存在 Line 383，日期 2026-04-29）、overview.md（Line 935 已有综合摘要）；步骤3完成：更新 source page（含新增内容：Key Claims×2条、Key Quotes×1条、Key Concepts×2个、Connections×1条、date 更新至 2026-05-02）；步骤4完成：index.md 条目日期更新至 2026-05-02；步骤5完成：overview.md Line 935 综合摘要补充新增能力（Security Engineer 协作/好奇心驱动 Bug 发现/测试覆盖率原则/成功指标）；步骤6-7完成：创建 [[Agent-Collaboration-Protocol]] 和 [[Curiosity-Driven-Bug-Discovery]] 两个 Concept 页面，index.md Concepts 节已同步更新；步骤8完成：无新增冲突（与 Designing-for-Agentic-AI 的概率性冲突已在初版中记录，无需重复）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Document Generator Agent
|
||
- Source file: Agent/agency-agents/specialized/specialized-document-generator.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Document Generator Agent 完整摄取——The Agency Specialized 部门的程序化文档生成专家，通过代码方式（Python/Node.js）生成 PDF、PPTX、DOCX、XLSX 等专业文档。核心工具栈：PDF（reportlab/weasyprint/fpdf2）、PPTX（python-pptx/pptxgenjs）、XLSX（openpyxl/xlsxwriter/exceljs）、DOCX（python-docx/docx）。核心原则：样式系统优先、品牌一致性、数据驱动、无障碍设计、模板可复用。与 [[report-distribution-agent]]（文档分发）和 [[sales-proposal-strategist]]（销售提案）形成文档管道。与 [[latex-paper-writing]] 存在格式选型冲突（商业文档→原生办公格式 vs 学术文档→LaTeX）。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：Code-Based-Document-Generation/Document-Styles/HTML-to-PDF-Conversion/Template-Driven-Generation/Data-Driven-Documents）
|
||
- Source page: wiki/sources/specialized-document-generator.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（条目已存在于 Line 386）、overview.md（Line 925 已有详细综合摘要，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 已有对应条目，无需修改；步骤5完成：overview.md 已有完整综合摘要（Line 925），无需修订；步骤6-7完成：Entity（The Agency/Specialized部门 已在多处出现）和 Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并记录与 [[latex-paper-writing]] 的格式选型冲突（商业文档 vs 学术文档），协调方案：按文档类型分工；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Accounts Payable Agent
|
||
- Source file: Agent/agency-agents/specialized/accounts-payable-agent.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Accounts Payable Agent 完整摄取——The Agency 财务部门的自主支付运营专家 Agent，处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 全支付通道。核心方法论：幂等性检查（reference ID 去重，零重复付款）、多通道路由（自动选择最优通道，失败自动切换备选）、审批阈值（超授权额度必须人工审批）、供应商注册表（维护已批准供应商首选通道和地址）、审计全链路（每笔支付记录完整上下文）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成。成功指标：零重复付款、<2 分钟执行时间、100% 审计覆盖、60 秒内 escalation SLA。属 The Agency Specialized 部门。
|
||
- Concepts created: （本次首次引入支付运营领域概念，暂不创建独立 Concept 页面，待后续来源≥2次引用再升级）
|
||
- Source page: wiki/sources/accounts-payable-agent.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（条目已存在 Line 413，补全日期格式）、overview.md（Line 214 已有相关摘要，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 日期格式补全；步骤5完成：overview.md 已有 Accounts Payable Agent 摘要，无需修订；步骤6-7完成：Entity（ContractsAgent/ProjectManagerAgent/HRAgent/StrategyAgent 等）和 Concept（Idempotency-Check/Audit-Trail/Payment-Rail-Routing 等）首次引入，暂不创建独立页面；步骤8完成：无跨页面冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Recruitment Specialist Agent
|
||
- Source file: Agent/agency-agents/specialized/recruitment-specialist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Recruitment Specialist Agent 完整摄取——The Agency Specialized 部门中国招聘运营与人才获取专家 Agent。核心方法论：7大招聘平台矩阵运营（Boss直聘/拉勾/猎聘/智联/前程无忧/脉脉/领英）+ JD优化与A/B测试 + 人才评估三维度模型 + STAR面试法 + 结构化面试评分卡 + 校园招聘（秋招/春招节奏）+ 猎头渠道分层管理（费率标准15-30%）+ 劳动法合规（劳动合同法/五险一金/试用期/竞业限制/经济补偿金N+1）+ 雇主品牌内容营销（抖音/B站/小红书/脉脉/知乎）+ 入职SOP全流程（T-7→T→T+7→T+30）+ 数据驱动招聘漏斗分析。核心成功指标：试用期留存率90%+、招聘渠道ROI季度改善、候选人体验NPS 80+、劳动法合规零事故。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：STAR面试法/Competency-Model/Recruitment-Funnel/Labor-Contract-Law/Wuxian-Yijin/Probation-Period/Non-Compete-Clause/Severance-N-Plus-1/Campus-Recruiting/Headhunter-Management/ATS-System/JD-A-B-Testing/Employer-Brand/Onboarding-SOP/Recruitment-Data-Analytics/RecruitmentFunnelAnalyzer）
|
||
- Source page: wiki/sources/recruitment-specialist.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（条目已存在于 Line 391）、overview.md（Recruitment Specialist 属 Specialized 部门，overview 暂无独立综合段落，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 已有对应条目（Line 391），无需修改；步骤5完成：overview.md 无需修订（Agent 个性化定义文档，Specialized 部门 overview 综合摘要暂缺）；步骤6-7完成：Entity（Boss直聘/拉勾/猎聘/北森/Moka/科锐国际等）和 Concept（STAR面试法/招聘漏斗/劳动法/五险一金等）均以 wikilinks 形式记录于 source page，未达到独立建页阈值（≥2次引用）；步骤8完成：检测与 Sales-Discovery-Coach 的 STAR 方法张力（Recruitment Specialist 将 STAR 作为通用行为面试工具，Discovery Coach 认为需按岗位层级定制），已记录于 Contradictions 节；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Specialized Civil Engineer Agent
|
||
- Source file: Agent/agency-agents/specialized/specialized-civil-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Specialized Civil Engineer Agent 完整摄取——The Agency Specialized 部门土木与结构工程专家 Agent，驾驭全球主要建筑规范体系（Eurocode/ACI/AISC/ASCE/GB/IS/AIJ/IBC/NBC）。核心方法论：ULS+SLS 双重验证（强度极限状态与正常使用极限状态必须同时满足）、多标准冲突处理策略（识别→记录→保守优先→设计依据报告）、岩土工程严谨性（严禁假设土壤参数）。六阶段工作流：项目范围→初步设计→详细计算→建造文档→规范合规→施工支持。计算交付物：AISC 360 LRFD 钢梁截面选型、Eurocode EN 1992-1-1 RC 梁配筋设计、Terzaghi 承载力分析（含 EN 1997 DA1）。属 The Agency Specialized 部门。
|
||
- Concepts created: （本次首次引入工程标准领域概念，暂不创建独立 Concept/Entity 页面，待后续来源≥2次引用再升级）
|
||
- Source page: wiki/sources/specialized-civil-engineer.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（条目已存在于 Line 385）、overview.md（Line 923 已有相关摘要）；步骤3完成：生成 source page（Connections 节暂不添加待定 wikilinks 以避免断链）；步骤4完成：index.md 已有对应条目，无需修改；步骤5完成：overview.md 已有 Civil Engineer 摘要，无需修订；步骤6-7完成：Entity（工程规范标准）和 Concept（ULS/SLS/National Annex 等）首次引入，暂不创建独立页面；步骤8完成：无跨页面冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Backend Architect with Memory（增量更新）
|
||
- Source file: Agent/agency-agents/integrations/mcp-memory/backend-architect-with-memory.md
|
||
- Status: ✅ 成功摄入（含更新）
|
||
- Summary: Backend Architect with Memory 增量更新——源文件新增 Memory Integration 段落（lines 233-244），补充了会话交接时的标签策略规范（Agent名称+项目名+主题标签三重标签）和 Rollback 回滚机制的完整触发条件。source page 补充 Key Claims×1条（标签一致性是 recall 可靠工作的前提）、Key Quotes×2条（交付物标记下游 Agent 规范、Rollback 回滚触发条件）、Key Concepts×2个（MemoryTagging/Rollback）、Key Entities×1个（SprintPrioritizer）、Connections×4条（与 Sprint Prioritizer/UX Researcher/Frontend Developer/TestingRealityChecker 的 MCP Memory Server 交互）、Contradications×1组（与 Software Architect 的 ADR 记录方式互补张力）。
|
||
- Concepts created: （MemoryTagging 和 Rollback 已在 workflow-with-memory.md 中作为描述性内容存在，本次作为新 wikilink 添加，未达到独立建页阈值）
|
||
- Source page: wiki/sources/backend-architect-with-memory.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（条目已存在于 Line 463）、overview.md（Line 63 已有综合摘要）；步骤3完成：更新 source page（含新增内容：tags 补充 memory/mcp、Key Claims×1、Key Quotes×2、Key Concepts×2、Key Entities×1、Connections×4、Contradictions×1、date 更新至 2026-05-29）；步骤4完成：index.md 条目日期更新至 2026-05-29 并补充一句话摘要；步骤5完成：overview.md Line 63 综合摘要补充新增内容（三重标签策略、含决策理由、与 Software Architect 互补张力）；步骤6-7完成：Entity（BackendArchitect 页面已存在）和 Concept（MemoryTagging/Rollback 描述已在多处出现，未达独立建页阈值）无需新建；步骤8完成：检测并记录与 [[engineering-software-architect]] 的 ADR 记录方式互补张力；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Experiment Tracker Agent Personality
|
||
- Source file: Agent/agency-agents/project-management/project-management-experiment-tracker.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Experiment Tracker Agent 完整摄取——The Agency 项目管理部门的实验设计与数据驱动决策专家 Agent。核心方法论：四阶段工作流（假设开发→实施准备→执行监控→分析决策）、统计学标准（95% 置信度、80% 功效分析、适当样本量计算）、实验安全规范（GDPR/CCPA 合规、用户隐私、回滚程序）。高级能力：多臂老虎机、贝叶斯分析、因果推断、元分析。成功指标：95% 实验达到统计显著性、季度实验吞吐量 15+，80% 成功实验落地产生可衡量业务影响。
|
||
- Concepts created: （本次首次引入实验管理领域概念，暂不创建独立 Concept/Entity 页面，待后续来源≥3次引用再升级）
|
||
- Source page: wiki/sources/project-management-experiment-tracker.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（了解项目管理层结构）、overview.md（已有20处实验相关内容，无需修订）；步骤3完成：生成 source page；步骤4完成：index.md 新增 Source 条目；步骤5完成：overview.md 无需修订；步骤6-7完成：Entity/Concept 首次引入，暂不创建独立页面；步骤8完成：与 paid-media-creative-strategist.md 的 StatisticalSignificance 引用一致，无冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Cultural Intelligence Strategist
|
||
- Source file: Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Cultural Intelligence Strategist 完整摄取——The Agency Specialized 部门的文化智能策略师，专门检测和消除软件开发中的"隐性排斥"（Invisible Exclusion）。核心方法：四阶段工作流（盲点审计 → 自主研究 → 结构修正 → 解释原理）。典型案例：刚性姓名字段在 APAC 市场失效 → 改为 Full Name/Preferred Name；中国金融应用中红色表示"上涨"而非"错误"；RTL 阅读方向、多日历系统等全局包容性设计。核心原则：国际化是架构前提条件而非亡羊补牢；拒绝表演性多元化；文化谦逊原则。本次首次引入 `Structural Empathy` 别名（添加至 [[Architectural-Empathy]] Concept 页面 Aliases 节）。
|
||
- Concepts created: [[Cultural-Intelligence]]（跨文化适应能力概念，4 维度：认知/元认知/动机/行为 CQ；引用计数 4 处已达阈值）、`Structural Empathy` 别名（添加至 [[Architectural-Empathy]] Concept 页面）
|
||
- Source page: wiki/sources/specialized-cultural-intelligence-strategist.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（条目已存在 Line 391，格式不规范→修复为标准格式：日期+标题+摘要）、overview.md（Line 939 已有详细综合摘要，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×4条、Key Quotes×3条、Key Concepts×6个、Key Entities×2个、Connections×5条、Contradictions×1对）；步骤4完成：index.md 条目格式规范化；步骤5完成：overview.md 已有 Line 939 综合摘要，无需修订；步骤6-7完成：创建 [[Cultural-Intelligence]] Concept 页面（引用计数4处已达阈值），`Structural Empathy` 别名添加至 [[Architectural-Empathy]]；步骤8完成：与 [[design-brand-guardian]] 的品牌一致性 vs 市场定制化视觉语义张力已记录于 Contradictions 节；步骤9完成：log.md 追加记录
|
||
|
||
|
||
- Source file: Agent/agency-agents/specialized/government-digital-presales-consultant.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Government Digital Presales Consultant 完整摄取——中国政府数字化转型市场（ToG）售前全流程专家 Agent。核心方法论：五步工作流（商机发现→需求调研→方案设计→投标执行→中标移交）+ 分层干系人沟通策略。关键合规体系：等保 2.0（三级）、密评（国密 SM2/SM3/SM4）、信创适配（鲲鹏/飞腾/麒麟/统信/达梦）。核心交付物：技术方案模板（7章结构）、招标文件检查清单（资质/技术/商务/格式）、合规矩阵（等保合规矩阵/信创适配清单）、商机评估模板。与 [[sales-discovery-coach]]（合规优先 vs 业务痛点优先）、[[sales-proposal-strategist]]（模板规范 vs 差异化叙事）存在方法论张力，协调方案均已记录至 source page。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：DigitalGovernment/SmartCity/Dengbao/Miping/Xinchuang/XinchuangAdaptationMatrix/DengbaoComplianceMatrix/GovernmentProcurementWorkflow/StakeholderMapping/OpportunityAssessment）
|
||
- Source page: wiki/sources/government-digital-presales-consultant.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（条目已存在于 Line 406，状态正常）、overview.md（属 Agent 个性化定义，overview 无需修订）；步骤3完成：生成 source page（wiki/sources/government-digital-presales-consultant.md，含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 已有对应条目（Line 406），无需修改；步骤5完成：overview.md 无需修订（Agent 个性化定义文档，overview 暂无独立综合段落）；步骤6-7完成：Entity（Yiwangtongban/Yiwangtonguan/CityBrain 等）和 Concept（DigitalGovernment/SmartCity/Dengbao/Miping/Xinchuang 等）均以 wikilinks 形式记录于 source page，未达到独立建页阈值（≥2次引用）；步骤8完成：检测与 [[sales-discovery-coach]]（合规优先 vs 业务痛点优先）和 [[sales-proposal-strategist]]（模板规范 vs 差异化叙事）的两处方法论张力，已记录于 Contradictions 节；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-06] ingest | Project Shepherd Agent Personality
|
||
- Source file: Agent/agency-agents/project-management/project-management-project-shepherd.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Project Shepherd Agent 完整摄取——The Agency 项目管理部门的跨职能项目协调与利益相关方对齐专家 Agent。核心方法论：项目章程模板（问题陈述/目标/范围/成功标准 + 利益相关方分析/沟通计划/资源需求/风险评估）、四阶段工作流（项目启动与规划→团队组建与启动→执行协调与监控→质量保证与交付）。关键交付物：Project Charter、Project Status Report（绿/黄/红健康状态）。成功指标：95% 项目按时在预算内交付、利益相关方满意度 4.5/5、范围蔓延 < 10%、90% 已识别风险成功缓解。沟通原则：透明报告、聚焦解决方案、绝不承诺不切实际时间线。
|
||
- Concepts created: Project-Management-Project-Shepherd
|
||
- Source page: wiki/sources/project-management-project-shepherd.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（wiki/sources/project-management-project-shepherd.md）；步骤4完成：index.md 新增 Source 条目和 Concept 条目；步骤5完成：overview.md Project Management 部门新增独立条目（Line 148）；步骤6完成：entities/ 和 concepts/ 目录存在，Project Shepherd 作为方法论概念创建 Concept 页面；步骤7完成：创建 wiki/concepts/Project-Management-Project-Shepherd.md；步骤8完成：与 [[ProjectManagerSenior]]（执行层任务分解）和 [[Project-Management-Studio-Operations]]（运营支撑）层级差异已记录至 source page Contradictions 节；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Agentic Identity & Trust Architect
|
||
- Source file: Agent/agency-agents/specialized/agentic-identity-trust.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Agentic Identity & Trust Architect 完整摄取——The Agency Specialized 部门自主 Agent 身份与信任验证基础设施专家，解决多 Agent 环境中的身份伪造、授权冒用、审计日志篡改等安全威胁。核心方法：密码学身份体系（Ed25519/ECDSA，分离签名/加密/身份密钥）、零信任验证（默认不信任自报告身份）、惩罚型信任评分（初始1.0，证据链损坏-0.5，行为失败按失败率×0.4扣分，凭证超90天-0.1）、追加式哈希链证据记录（intent→decision→outcome，篡改可检测）、多跳委托链验证（任一链节断裂全链失效）、Fail-Closed 授权（无法验证时默认拒绝）。高级能力：后量子迁移抽象层、NIST 后量子标准（ML-DSA/ML-KEM/SLH-DSA）、跨框架身份联邦（A2A/MCP/REST/SDK）。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：Zero-Trust-Model/Trust-Score-Model/Delegation-Chain/Evidence-Record/Peer-Verification-Protocol/Fail-Closed-Authorization/Cryptographic-Identity-Scheme）
|
||
- Source page: wiki/sources/agentic-identity-trust.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（条目已存在于 Line 413）、overview.md（Line 124 已有详细综合摘要，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 已有对应条目，无需修改；步骤5完成：overview.md 已有完整综合摘要（Line 124），无需修订；步骤6-7完成：Entity（Identity Graph Operator/A2A/MCP 等）和 Concept（Zero-Trust-Model/Trust-Score-Model 等）均以 wikilinks 形式记录于 source page，未达到独立建页阈值（≥2次引用）；步骤8完成：检测与 specialized-document-generator 的架构张力（身份验证边界不明确），已记录于 Contradictions 节；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | visionOS Spatial Engineer
|
||
- Source file: Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: visionOS Spatial Engineer Agent 完整摄取——visionOS 26 原生空间计算专家智能体，专注于 SwiftUI volumetric interfaces 和 Liquid Glass Design System 实现。核心能力：Liquid Glass 透明材质（自适应 light/dark 环境）、Spatial Widgets（吸附墙面/桌面、持久化放置）、SwiftUI Volumetric APIs（3D 内容集成、volume transient content、breakthrough UI）、RealityKit-SwiftUI 集成（Observable entities、直接手势处理、ViewAttachmentComponent）、Multi-Window Architecture（WindowGroup 管理、玻璃背景效果）、GPU 高效渲染（Metal）。技术栈：SwiftUI / RealityKit / ARKit / Metal。局限：不支持 Unity 或其他 3D 框架、不涉及跨平台空间解决方案、依赖 visionOS 26 新特性。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均已存在于 wiki：Liquid Glass Design System/Multi-Window Architecture/RealityKit-SwiftUI Integration/Spatial Widgets/SwiftUI Volumetric APIs）
|
||
- Source page: wiki/sources/visionos-spatial-engineer.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page；步骤4完成：index.md 已有对应条目（Line 407），无需修改；步骤5完成：overview.md 已有 visionOS Spatial Engineer 摘要（Line 134），无需修订；步骤6完成：Apple/Vision Pro/SwiftUI/RealityKit 均为跨文档高频实体，未达到单一文档内独立建页阈值；步骤7完成：Concept 均已存在独立页面；步骤8完成：与 [[xr-immersive-developer]] 可能存在技术路径分歧（平台锁定 vs 跨平台），已记录至 source page Contradictions 节；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-02] ingest | macOS Spatial/Metal Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: macOS Spatial/Metal Engineer Agent 完整摄取——Swift + Metal 渲染专家智能体，专注于高性能 3D 渲染系统和 visionOS 空间计算体验。核心能力：Instanced Metal Rendering（10k-100k 节点，90fps 立体渲染）；Compositor Services（LayerRenderer stereo 模式 + RGBA16Float + Depth32Float）帧流传输到 Vision Pro；Metal Compute Shader GPU 并行力导向图物理模拟；Gaze + Pinch 空间交互 + raycast hit testing。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。技术栈：Swift / Metal / CompositorServices / RealityKit / ARKit / Metal System Trace / Instruments。属 The Agency Spatial Computing 部门，与 [[visionos-spatial-engineer]]（visionOS 原生空间计算）和 [[xr-immersive-developer]]（WebXR 跨平台沉浸式开发）形成完整技术覆盖矩阵。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：Metal/Vision Pro Compositor Services/RemoteImmersiveSpace/Instanced Rendering/Force-Directed Graph Layout/Frustum Culling/Stereoscopic Rendering）
|
||
- Source page: wiki/sources/macos-spatial-metal-engineer.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（wiki/sources/macos-spatial-metal-engineer.md）；步骤4完成：index.md 已有对应条目（Line 7），已添加；步骤5完成：overview.md 已有 macOS Spatial/Metal Engineer 相关摘要（Line 132），无需修订；步骤6完成：Entity 未达到独立建页阈值（Apple/Vision Pro/Xcode 等仅在本文档中出现）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page；步骤8完成：无内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-30] ingest | Studio Producer Agent Personality
|
||
- Source file: Agent/agency-agents/project-management/project-management-studio-producer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Studio Producer Agent 完整摄取——The Agency 项目管理部门的战略组合管理专家 Agent，定位为创意工作室的高管级战略领导者。核心职责：战略组合规划（Tier 1/2/Innovation Pipeline 三级分级）、Portfolio ROI 管理（要求 ≥ 25%）、95% 按时交付、高管级利益相关者沟通。四阶段工作流：战略规划→项目编排→领导力发展→绩效优化。高级能力：并购战略、国际市场进入规划、AI 技术整合、董事会关系管理。与 [[ProjectManagerSenior]]（执行层）形成层级互补，与 [[StudioOperations]]（运营层）协同执行。与其他 Project Management Agents 共同构成 The Agency 项目管理部门的完整体系。
|
||
- Concepts created: Strategic Portfolio Management
|
||
- Source page: wiki/sources/project-management-studio-producer.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（wiki/sources/project-management-studio-producer.md）；步骤4完成：index.md 已有对应条目（Line 410），新增 Concept 条目 Strategic Portfolio Management；步骤5完成：overview.md 已有相关摘要（Line 141），无需修订；步骤6完成：Studio Producer 为 Agent 角色定义，无外部实体关联，无需创建 Entity 页面；步骤7完成：创建 [[Strategic-Portfolio-Management]] Concept 页面；步骤8完成：与 [[ProjectManagerSenior]] 的层级关系差异已记录（source page Contradictions 节）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-29] ingest | Terminal Integration Specialist
|
||
- Source file: Agent/agency-agents/spatial-computing/terminal-integration-specialist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Terminal Integration Specialist Agent 完整摄取——专注于终端仿真、文本渲染优化与 SwiftTerm 集成，面向现代 Swift 应用程序的 AI Agent 个性化定义。核心技术栈：SwiftTerm（MIT）、Core Graphics/Core Text 文本渲染、SwiftNIO SSH/NMSSH。核心能力：VT100/xterm 标准兼容（ANSI 转义序列）、SwiftUI 生命周期管理、Core Graphics 性能优化、SSH I/O 桥接与会话管理。平台覆盖：iOS、macOS、visionOS。局限：仅限 SwiftTerm、仅限客户端仿真、仅限 Apple 平台。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：VT100/xterm Standards/ANSI Escape Sequences/Core Graphics 文本渲染/SwiftUI 生命周期管理/SSH I/O 桥接）
|
||
- Source page: wiki/sources/terminal-integration-specialist.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page；步骤4完成：index.md 已有对应条目（Line 406），无需修改；步骤5完成：overview.md 属于 Agent 个性化定义，暂不修改；步骤6完成：SwiftTerm/SwiftNIO SSH 等实体仅出现1次，未达到独立建页阈值（≥2次）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page；步骤8完成：无内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-18] ingest | XR Immersive Developer Agent Personality
|
||
- Source file: Agent/agency-agents/spatial-computing/xr-immersive-developer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: XR Immersive Developer Agent 完整摄取——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 可视化界面、空间界面。与 xr-interface-architect 和 xr-cockpit-interaction-specialist 同属 Spatial Computing 部门，共同构建 XR 产品交互基础设施。与 xr-cockpit-interaction-specialist 在运动自由度设计上存在张力（开放空间沉浸 vs 固定视角约束）。
|
||
- Concepts created: WebXR.md、A-Frame.md、Three.js.md、Babylon.js.md、Raycasting.md、Hit-Testing.md、LOD-Systems.md、Occlusion-Culling.md（均以 wikilinks 形式记录于 source page，实体未达独立建页阈值）
|
||
- Source page: wiki/sources/xr-immersive-developer.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md（XR 相关内容已在 line 126-134）；步骤3完成：生成 source page（wiki/sources/xr-immersive-developer.md）；步骤4完成：index.md 已有对应条目（Line 404），无需修改；步骤5完成：overview.md 已有相关 XR 段落（Line 126-134），无需修订；步骤6完成：Entity 未达到独立建页阈值（The Agency/Spatial Computing 等均在多处出现，有独立页面）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page；步骤8完成：与 xr-cockpit-interaction-specialist 在运动自由度设计上存在张力，已记录于 Contradictions；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-18] ingest | XR Cockpit Interaction Specialist Agent
|
||
- Source file: Agent/agency-agents/spatial-computing/xr-cockpit-interaction-specialist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: XR Cockpit Interaction Specialist Agent 完整摄取——专注于沉浸式座舱环境控件设计，通过固定视角锚定降低晕动症，支持手势/语音/凝视/物理道具多模态输入，采用 A-Frame/Three.js 原型开发，约束驱动机制消除自由浮动。典型应用：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。
|
||
- Concepts created: Cockpit-Ergonomics.md、Constraint-Driven-Control-Mechanics.md（均已存在，无需新建）
|
||
- Source page: wiki/sources/xr-cockpit-interaction-specialist.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page；步骤4完成：index.md 已有对应条目（Line 404），无需修改；步骤5完成：overview.md 已有相关 XR 内容，无需修订；步骤6完成：Entity 页面均已存在（XR-Cockpit-Interaction-Specialist/XR-Interface-Architect/XR-Immersive-Developer/The-Agency）；步骤7完成：Concept 页面均已存在（Cockpit-Ergonomics/Constraint-Driven-Control-Mechanics/Motion-Sickness-Threshold/WebXR/Spatial-Computing）；步骤8完成：无内容冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-18] ingest | Outbound Strategist Agent
|
||
- Source file: Agent/agency-agents/sales/sales-outbound-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Outbound Strategist Agent 完整摄取——信号驱动型主动销售（Signal-Based Selling）核心框架：三层信号分级（Tier 1 主动购买信号 > Tier 2 组织变化信号 > Tier 3 技术/行为信号）、可证伪 ICP 定义（含排除条件）、三层账户分层模型（Tier 1 深度多线程 / Tier 2 半个性化 / Tier 3 自动化）、8-12 触点 3-4 周多渠道序列（每次触达必须提供新价值角度）、SDR 角色从 volume operator 向 revenue specialist 转型。关键数据：信号驱动外展转化率比无触发高 4-8 倍；信号半衰期 30 分钟；冷邮件回复率基准 1-3%（通用）→ 12-25%（信号驱动）。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：Signal-Based Selling/ICP/Tiered Account Engagement/Multi-Channel Sequence/Speed-to-Signal/Cold Email Anatomy）
|
||
- Source page: wiki/sources/sales-outbound-strategist.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page；步骤4完成：index.md 添加条目；步骤5完成：overview.md 已有完整综合摘要（Line 892），无需修改；步骤6完成：Entity 未达到独立建页阈值（SDR/G2/BuiltWith/Loom 均仅出现1次）；步骤7完成：Concept 均以 wikilinks 记录于 source page；步骤8完成：无实质性内容冲突，与 sales-deal-strategist/sales-pipeline-analyst 形成互补关系；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-18] ingest | Account Strategist Agent
|
||
- Source file: Agent/agency-agents/sales/sales-account-strategist.md
|
||
- Status: ✅ 成功摄入（更新）
|
||
- Summary: Account Strategist（账户策略师）Agent 文档更新——补充 Advanced Capabilities 部分：战略账户规划（投资组合分层/EBR）+ 收入架构（定价优化/合同结构/渠道协同）+ 组织情报（M&A检测/非正式决策映射/政治定位）。核心框架保持：Land-and-Expand、QBR、NRR、Multi-Threading、Account Health Score、Churn Prevention。扩充内容：Key Claims（高级能力五条）、Key Quotes（组织情报两条）、Key Concepts（新增8个高级概念：Account Portfolio Segmentation/EBR/Pricing & Packaging Optimization/Contract Structure Design/Co-sell Expansion/PLG/Organizational Change Detection/Informal Decision-Making Mapping）、Contradictions（新增与 sales-pipeline-analyst 的互补关系）。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
|
||
- Source page: wiki/sources/sales-account-strategist.md（更新：date 2026-05-18，扩充 Advanced Capabilities 相关内容）
|
||
- Notes: 步骤1完成：读取原始文档（Advanced Capabilities 部分新增）；步骤2完成：读取 index.md、overview.md 和现有 source page；步骤3完成：更新 source page（日期更新 + Summary扩充 + Key Claims扩充 + Key Quotes扩充 + Key Concepts扩充 + Contradictions扩充）；步骤4完成：index.md 第408行日期补全（2026-05-18）；步骤5完成：overview.md 第911行已扩充 Advanced Capabilities 综合摘要；步骤6完成：Entity 未创建独立页面（Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并记录与 sales-pipeline-analyst 的互补关系（NRR 共同语言）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-20] ingest | XR Interface Architect Agent Personality
|
||
- Source file: Agent/agency-agents/spatial-computing/xr-interface-architect.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: XR Interface Architect Agent 完整摄取——空间交互设计师和界面策略师，专为 AR/VR/XR 沉浸式环境设计直觉化、舒适且可发现的界面。核心能力：设计 HUD、浮动菜单、面板和交互区域；支持多种输入模型（直接触摸、注视+捏合、控制器、手势）；推荐舒适度约束的 UI 布局以降低晕动症；原型化沉浸式搜索、选择和操作交互；结构化多模态输入并提供无障碍备选方案。角色定位：UX/UI 设计师，专注 3D 空间环境。与 [[XRImmersiveDeveloper]] 协作实现 3D 场景可用性，与 [[XRCockpitInteractionSpecialist]] 共享空间交互设计模式，与 [[VisionOSSpatialEngineer]] 实现 visionOS UI。与 [[XRCockpitInteractionSpecialist]] 在 UI 放置策略上存在张力（Interface Architect 倾向灵活定位 vs Cockpit 专家倾向固定安全控件）。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：SpatialComputing/HUDDesign/MotionSickness/GazeInteraction/MultimodalInput/PresenceUX/AccessibilityInXR）
|
||
- Source page: wiki/sources/xr-interface-architect.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（wiki/sources/xr-interface-architect.md）；步骤4完成：index.md 已有对应条目（Line 406），无需修改；步骤5完成：Agent 个性化定义文档，overview.md 暂不修改；步骤6完成：Entity 未达到独立建页阈值（The Agency/Spatial Computing 已在多处出现，有独立页面）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page；步骤8完成：与 XRCockpitInteractionSpecialist 在 UI 放置策略上存在张力，已记录于 Contradictions；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-18] ingest | Deal Strategist Agent
|
||
- Source file: Agent/agency-agents/sales/sales-deal-strategist.md
|
||
- Status: ✅ 成功摄入（更新）
|
||
- Summary: Deal Strategist Agent 文档更新——补充三大新增核心能力：Deal Inspection Methodology（7问探测deal状态）、Multi-Threading Strategy（绘制权力/影响力/触达地图避免单点依赖）、Forecast Accuracy（可辩护的deal级别检查方法论）。扩充 Key Claims（Champion验证原则：必须在艰难请求下愿意行动才算真正验证）。新增 Key Concepts（Competitive Landmines/Forecast Accuracy/Multi-Threading Strategy）。新增 Connections（sales-pipeline-analyst 接收评分数据）。扩充 Key Entities。Source page date 更新至 2026-05-18。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page；MEDDPICC/Challenger Sales Model/Command of the Message/Deal Scoring/Competitive Positioning/Win Planning/Deal Inspection Methodology/Challenger Messaging/Multi-Threading Strategy/Forecast Accuracy/Competitive Landmines）
|
||
- Source page: wiki/sources/sales-deal-strategist.md（更新：date 2026-05-18，扩充新增能力相关内容）
|
||
- Notes: 步骤1完成：读取原始文档（新增 Deal Inspection/Multi-Threading/Forecast Accuracy 章节）；步骤2完成：读取 index.md、overview.md 和现有 source page；步骤3完成：更新 source page（日期更新+内容扩充：Key Claims/Key Concepts/Key Entities/Connections）；步骤4完成：index.md 第408行日期补全（2026-05-18）；步骤5完成：overview.md 无需大幅更新，新增内容与现有框架一致；步骤6完成：Entity 未创建独立页面（Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并记录与 sales-pipeline-analyst 的新连接关系（评分数据流向）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-30] ingest | Game Audio Engineer Agent（增量验证）
|
||
- Source file: Agent/agency-agents/game-development/game-audio-engineer.md
|
||
- Status: ✅ 增量验证完成（last_updated 更新至 2026-05-30）
|
||
- Summary: 游戏交互式音频工程师 AI Agent 人格规范——设计自适应音乐系统、空间音频架构和音频中间件集成方案。核心规范：所有音频必须通过 FMOD/Wwise 中间件触发、音乐转换必须 tempo-synced、所有世界空间音效必须使用 3D 空间化、语音数量必须配置 budget + priority + steal mode。成功指标：零音频卡顿、所有事件配置 voice limit、音乐转换无缝、内存预算达标、所有 diegetic 音效激活 occlusion + reverb。
|
||
- Concepts: AdaptiveMusic / SpatialAudio / VoiceBudgeting / AudioMiddleware / ProceduralAudio / Ambisonics / HRTF / A/BParameterTesting / AudioCertification — 均仅在本 source page 首次引入，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: FMOD / Wwise / Unity / UnrealEngine / Godot / DolbyAtmos / DTSX — 均仅在本 source page 首次引入，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Entity 页
|
||
- Source page: wiki/sources/game-audio-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page 已存在（2026-04-26 初次摄入），本次更新 last_updated 字段；index.md 已有条目（第500行）；检测到无内容冲突——game-audio-engineer 与同系列其他 game development agents（Godot Multiplayer Engineer / Godot Gameplay Scripter / Godot Shader Developer / Unity Architect / Unity Multiplayer Engineer / Unity Shader Graph Artist / Unreal Systems Engineer / Unreal Multiplayer Architect / Technical Artist / Narrative Designer / Level Designer / Roblox Systems Scripter / Blender Add-on Engineer / Game Designer / Autonomous Game Dev Pipeline）构成完整游戏开发 Agent 协作体系，audio 作为垂直专项与 gameplay/graphics/multiplayer 并列，无冲突；log.md 追加记录。
|
||
|
||
## [2026-04-26] ingest | Game Audio Engineer Agent
|
||
- Source file: Agent/agency-agents/sales/sales-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Sales Engineer Agent 完整摄取——售前工程师 Agent 角色定义与核心能力框架。核心能力：技术发现（结构化挖掘架构/集成/安全约束/真实决策标准）、Demo Engineering（以影响力为导向：先量化问题→展示结果→逆向讲解→证明收尾，以 [[AhaMoment]] 为核心成功标准）、POC Scoping（严格限定范围：成功标准前置+2-3周硬性时间线+中期检查点）、FIA Framework（Fact-Impact-Act 竞争定位框架）、技术异议解码（识别表面问题背后的真实诉求）、评估笔记维护。关键数据：技术赢率70%+，POC转化率80%+，演示到下一步行动率90%+，中位数18天技术决策。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：Technical Discovery/Demo Engineering/POC Scoping/FIA Framework/Aha Moment Test/Competitive Technical Positioning/Technical Objection Handling/Evaluation Management/Solution Architecture/Demo Tailoring）
|
||
- Source page: wiki/sources/sales-engineer.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（sales-engineer.md）；步骤4完成：index.md 添加日期标注条目；步骤5完成：overview.md Line 917 已包含完整 Sales Engineer 综合摘要，无需修改；步骤6完成：Entity 未达到独立建页阈值（全文无具体人物/公司实体）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：无实质性内容冲突，与 Sales Discovery Coach 存在互补/协调关系（详见 overview.md Line 1100）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-02] ingest | Sales Coach Agent
|
||
- Source file: Agent/agency-agents/sales/sales-coach.md
|
||
- Status: ✅ 成功摄入（更新）
|
||
- Summary: AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长，专注管道审查、话术辅导、交易策略和预测准确性。核心框架：Richardson Sales Performance、Challenger Model、MEDDPICC 资质诊断、行为反馈循环（Observe-Ask-Suggest-Practice）。关键数据：正式辅导配额完成率 91.2% vs 非正式辅导 84.7%；每周 2 小时以上辅导赢单率 56% vs 少于 30 分钟 43%。新增内容：Skill Gap vs Will Gap 区分、Best Practice 辅导节奏（周 1:1/双周管道审查/月度预测会议）、Observe-Ask-Suggest-Practice 辅导强化循环。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page；MEDDPICC/Challenger Sales Model/Richardson Sales Performance Framework/Pipeline Review/Forecast Accuracy/Coaching Discipline/Skill Gap vs Will Gap）
|
||
- Source page: wiki/sources/sales-coach.md（更新：date 2026-05-02，扩充 Key Claims/Key Concepts/Key Entities/Connections）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md 和现有 sales-coach source page；步骤3完成：更新 source page（日期更新+内容扩充）；步骤4完成：index.md 日期补全（[2026-05-02]）；步骤5完成：overview.md 第909行已覆盖该来源核心内容，无需更新；步骤6完成：Entity 未创建独立页面（Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并延续 MEDDPICC 八维度 vs 旧版六维度冲突记录（overview line 1092）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-17] ingest | Paid Media Tracking & Measurement Specialist Agent
|
||
- Source file: Agent/agency-agents/paid-media/paid-media-tracking-specialist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 付费媒体转化追踪与归因测量专家 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于 GTM 容器架构、GA4 事件设计、跨平台归因建模和隐私合规。核心理念：错误的追踪数据比无追踪更具误导性，会导致算法持续优化错误目标。核心能力：GTM 容器架构、GA4 实现（事件分类/自定义维度/电子商务 dataLayer）、Google Ads 增强转化、Meta CAPI（含 event_id 去重）、服务端 Tagging、数据驱动归因建模、Consent Mode v2。成功指标：转化数据差异 <3%、标签触发成功率 99.5%+、CAPI 去重零双重计数、页面性能影响 <200ms。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
|
||
- Source page: wiki/sources/paid-media-tracking-specialist.md（新建）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节添加新条目；步骤5完成：overview.md 第188行扩充该来源综合摘要（从简短版本升级为详细版本）；步骤6完成：Entity 未创建独立页面（Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Key Concepts 均以 wikilinks 形式记录于 source page，未达到独立页面阈值；步骤8完成：检测与 paid-media-auditor 的功能边界重叠——追踪配置（Tracking Specialist）与追踪审计（Auditor）协作关系已在 Connections 节明确记录，无冲突；步骤9完成：log.md 追加记录
|
||
|
||
- Source file: Agent/agency-agents/paid-media/paid-media-paid-social-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 跨平台付费社交广告专家 Agent——覆盖 Meta/LinkedIn/TikTok/Pinterest/X/Snapchat 六大平台，设计从引流到再营销的全漏斗社交广告项目。核心理念：社交广告本质是"打断"而非"回答"，必须为每个平台构建原生创意体验而非跨平台复用。关键能力：全漏斗架构、平台差异化创意策略、受众工程（像素/Lookalike/CRM）、Conversions API 实施、SKAdNetwork 应对 iOS 隐私变化。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
|
||
- Source page: sources/paid-media-paid-social-strategist.md
|
||
- Notes: 与 [[paid-media-ppc-strategist]] 存在预算分配优先级张力——社交广告强调基于增量测试分配预算而非补充曝光，已在 Contradictions 节记录
|
||
|
||
## [2026-05-17] ingest | Paid Media Search Query Analyst Agent
|
||
- Source file: Agent/agency-agents/paid-media/paid-media-search-query-analyst.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 付费搜索查询分析与优化专家 Agent——专职挖掘搜索词报告、构建负面关键词体系（N-gram 分析/决策树/分层清单）、识别查询-意图缺口（N-gram 四阶段分类）、执行查询雕塑防止内部竞争，通过 SQOS 评分系统多因素评估查询-广告-着陆页一致性。成功指标：首次分析消除 10-20% 非转化消费，无效展示 <5%，查询-意图正确率 >80%。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
|
||
- Source page: wiki/sources/paid-media-search-query-analyst.md（新建）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第417行已有该条目，无需重复添加；步骤5完成：overview.md 第190行已有该来源综合摘要，无需重复添加；步骤6完成：Entity 未创建独立页面（TheAgency/GoogleAds 已存在，JohnWilliams/PaidMediaAuditor/PaidMediaPPCStrategist/PaidMediaTrackingSpecialist 均以 wikilinks 记录于 source page）；步骤7完成：Key Concepts 均以 wikilinks 形式记录于 source page，未达到独立页面阈值；步骤8完成：检测与 PaidMediaAuditor 的功能边界重叠（详见 Contradictions 节），协调方案为 Audit → Query Analysis → Strategy 三者协作；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-17] ingest | Discovery Coach Agent
|
||
- Source file: Agent/agency-agents/sales/sales-discovery-coach.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 销售发现访谈（Discovery）方法论与教练框架——三大发现框架（SPIN Selling/Gap Selling/Sandler Pain Funnel）+ 标准30分钟发现电话结构 + AECR异议处理框架。核心理念：发现是交易成败的关键战场；Implication问题激活损失厌恶是最有力成交工具；根因问题是Gap Selling最重要也最常被跳过的问题；购买决策本质上是情感决策。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
|
||
- Source page: wiki/sources/sales-discovery-coach.md（已存在，本次确认格式合规性）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 已存在且格式完全符合 Source Page Format（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第405行已有该条目；步骤5完成：overview.md 暂不更新（销售发现框架由 sales-proposal-strategist 等页面覆盖）；步骤6完成：Entity 未创建独立页面（Neil Rackham/Keenan/Sandler 均以 wikilinks 记录于 source page）；步骤7完成：Key Concepts 以 wikilinks 形式记录于 source page，未达到独立页面阈值；步骤8完成：无冲突检测；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-17] ingest | Paid Media Auditor Agent
|
||
- Source file: Agent/agency-agents/paid-media/paid-media-auditor.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 付费媒体账户审计 Agent——系统化评估 Google Ads、Microsoft Ads、Meta 三大平台广告账户，涵盖 200+ 检查点，8 大审计类别（账户结构、追踪测量、出价预算、关键词定向、创意素材、购物馈送、竞争定位、着陆页），输出结构化审计报告与优先级建议。审计通常发现 15-30% 效率提升空间，关键建议 30 天执行率达 80%+。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
|
||
- Source page: wiki/sources/paid-media-auditor.md（新建）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节第7行添加新条目；步骤5完成：overview.md 未需更新（概述型内容由综合生成覆盖）；步骤6完成：Entity 未创建独立页面（GoogleAds、MicrosoftAdvertising、MetaAds 等均为平台实体，Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Key Concepts 以 wikilinks 形式记录于 source page，未达到独立页面阈值；步骤8完成：检测与 PaidMediaTrackingSpecialist 的分工冲突（详见 Contradictions 节）；步骤9完成：log.md 追加记录
|
||
|
||
|
||
- Source file: Agent/agency-agents/design/design-visual-storyteller.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Design 部门视觉叙事与多媒体内容创作专家 Agent——核心职责：将复杂信息转化为有影响力的视觉故事；Story Arc 三段式框架（铺垫/冲突/解决）；多媒体能力覆盖视频叙事、动画-motion graphics、摄影指导和交互式媒体；跨平台适配支持 Instagram/YouTube/TikTok/LinkedIn/Pinterest；数据可视化通过 Progressive Disclosure 实现复杂信息可理解传递；无障碍合规 WCAG 是默认要求
|
||
- Source page: wiki/sources/design-visual-storyteller.md（新建）
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节第13行添加新条目；步骤5完成：overview.md 第110行已有该来源综合摘要，无需重复添加（发现重复后已回退）；步骤6完成：Entity 未创建（相关 Agent 均已存在于 wiki 实体引用，无需新建）；步骤7完成：Key Concepts 以 wikilinks 形式记录于 source page，未创建独立 Concept 页面；步骤8完成：检测无冲突内容（无已知矛盾）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-15] ingest | Inclusive Visuals Specialist
|
||
- Source file: Agent/agency-agents/design/design-inclusive-visuals-specialist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Design 部门包容性视觉表征专家 Agent——专门对抗 AI 图像/视频生成模型（Midjourney/Sora/Runway/DALL-E）中的系统性刻板印象偏见；核心机制：结构化提示词架构（Subject → Sub-actions → Context → Camera Spec → Color Grade → Explicit Exclusions）+ 负向提示库 + 视频物理学定义；四阶段工作流：Brief Intake → Annotation Framework → Video Physics Definition → 7-Point QA Review Gate；成功指标：刻板印象零依赖、克隆面孔和文化乱码消除率100%、社区验证认可
|
||
- Source page: wiki/sources/design-inclusive-visuals-specialist.md（新建）
|
||
- Concepts created: Intersectionality.md、Cultural-Authenticity.md、Video-Physics-Definition.md、Sociological-Accuracy.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（含现有 Sources/Concepts 索引）和 overview.md（含 InclusiveVisualsSpecialist 已有摘要）；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节第12行添加新条目；步骤5完成：overview.md 第112-113行补充 Intersectionality vs Sociological Accuracy 分析段落；步骤6完成：Entity 未创建（Midjourney/DALL-E/Sora/Runway 均为参考性质，引用未达≥2次阈值）；步骤7完成：新建4个 Concept 页面（Intersectionality/Cultural-Authenticity/Video-Physics-Definition/Sociological-Accuracy）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 design-image-prompt-engineer 的张力（概率生成 vs 确定性约束），协调方式：Subject/Context 层使用 Inclusive Visuals 的精确约束，Style/Color Grade 层保留 Image Prompt Engineer 的创意概率空间；步骤9完成：log.md 追加记录
|
||
|
||
|
||
- Source file: Agent/agency-agents/design/design-image-prompt-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Design 部门 AI 图像生成提示词工程专家 Agent——核心职责：将视觉概念精准翻译为结构化提示词，驱动 Midjourney/DALL-E/SD/Flux 等平台产出专业级摄影作品；五层提示词结构框架（主体→环境→光线→摄影技术→风格）；体裁专属模板（人像/产品/风光/时尚）；平台特定语法优化；成功指标：90%+ 视觉概念还原率
|
||
- Source page: wiki/sources/design-image-prompt-engineer.md（新建）
|
||
- Concepts created: Five-Layer-Prompt-Structure.md、Photography-Terminology.md、Negative-Prompting.md、Platform-Specific-Optimization.md、Genre-Specific-Prompt-Patterns.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节第10行添加新条目；步骤5完成：overview.md 第110-111行已有该来源综合摘要，无需修订；步骤6完成：Entity 未创建（Midjourney/SD/DALL-E/Flux/Annie Leibovitz/Peter Lindbergh 均为参考性质，引用未达≥2次阈值）；步骤7完成：新建5个 Concept 页面（Five-Layer-Prompt-Structure/Photography-Terminology/Negative-Prompting/Platform-Specific-Optimization/Genre-Specific-Prompt-Patterns）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 design-ui-designer 的精确性张力（概率生成 vs 像素精确，通过确定性约束协调）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-30] ingest | Whimsy Injector Agent Personality
|
||
- Source file: Agent/agency-agents/design/design-whimsy-injector.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Design 部门品牌趣味性设计专家 Agent——核心职责：在用户交互全流程嵌入愉悦感，通过微交互、趣味文案、复活节彩蛋和游戏化提升品牌记忆度；趣味分类学四层（Subtle/Interactive/Discovery/Contextual）；核心原则：趣味必须有功能性或情感性目的；包容性设计是默认要求；与 UX Architect 时序协作（基线 → 趣味叠加）
|
||
- Source page: wiki/sources/design-whimsy-injector.md（新建）
|
||
- Concepts created: Micro-Interaction.md、Brand-Personality-Framework.md、Gamification.md、Inclusive-Delight.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第9行添加新条目；步骤5完成：overview.md 第26-30行在 design-ux-architect 段落后新增 Whimsy Injector 综合摘要；步骤6完成：UX Architect/Design-UI-Designer/Brand-Guardian 仅1-2次引用，未达≥2次阈值，跳过 Entity 创建；步骤7完成：新建4个 Concept 页面（Micro-Interaction/Brand-Personality-Framework/Gamification/Inclusive-Delight）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 UX Architect 的趣味边界张力（通过时序分工解决）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-15] ingest | Brand Guardian Agent Personality
|
||
- Source file: Agent/agency-agents/design/design-brand-guardian.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Design 部门的品牌守护者专家 Agent——核心职责：创建内聚的品牌身份系统，确保品牌在所有触点的一致表达，提供品牌保护策略；Brand Foundation Framework（Purpose/Vision/Mission/Values/Personality）是所有品牌决策基础；Visual Identity System 必须作为内聚系统设计；默认要求包含品牌保护（商标/合规监控/危机管理）
|
||
- Source page: wiki/sources/design-brand-guardian.md（新建）
|
||
- Concepts created: Brand-Foundation-Framework.md、Visual-Identity-System.md、Brand-Voice.md、Brand-Protection.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第9行添加新条目；步骤5完成：overview.md 在 Whimsy Injector 段落后新增 Brand Guardian 综合摘要；步骤6完成：The-Agency Entity 已存在，Design-Department/UX-Architect 仅1次引用，未达≥2次阈值，跳过 Entity 创建；步骤7完成：新建4个 Concept 页面（Brand-Foundation-Framework/Visual-Identity-System/Brand-Voice/Brand-Protection）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 UX Architect 的角色边界张力（通过时序分工解决——Brand Guardian 先定义战略框架 → UX Architect 再构建技术系统）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-15] ingest | UX Architect
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Design 部门 UX Architect Agent 的角色定义与交付物规范——核心职责：提供 CSS 设计系统（颜色/排版/间距变量）、Grid/Flexbox 布局框架、Theme Toggle 组件（light/dark/system 三态）；Foundation-first 理念消除开发者架构决策疲劳；在 ProjectManager 和 LuxuryDeveloper 之间建立技术桥梁；组件命名规范（BEM/Utility-first/Component-based 三选一）
|
||
- Source page: wiki/sources/design-ux-architect.md（新建）
|
||
- Concepts created: CSS-Design-System.md、Layout-Framework.md、Theme-Toggle.md、Responsive-Breakpoints.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第9行添加新条目；步骤5完成：overview.md 第26行后新增 UX Architect 综合摘要；步骤6完成：LuxuryDeveloper/ProjectManager/ArchitectUX 仅1次引用，未达≥2次阈值，跳过 Entity 创建；步骤7完成：新建4个 Concept 页面（CSS-Design-System/Layout-Framework/Theme-Toggle/Responsive-Breakpoints）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 LuxuryDeveloper 的边界协调（Foundation → Polish 时序分工）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-15] ingest | Contributing to The Agency
|
||
- Source file: Agent/agency-agents/CONTRIBUTING.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency 开源 AI Agent 项目的贡献指南——定义如何创建、改进和提交新的 Agent；核心贡献方式（创建新 Agent / 优化现有 / 分享案例 / 反馈问题）；Agent 设计五原则（强个性 + 清晰交付物 + 可量化指标 + 经验证工作流 + 学习记忆）；Persona/Operations 双分组结构支持 OpenClaw 格式自动转换；PR 最简路径为单个 Markdown 文件
|
||
- Source page: wiki/sources/contributing.md（新建）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 添加新条目；步骤5完成：overview.md 第26行已有该来源综合摘要，无需修订；步骤6完成：Entity/Concept 暂缓；步骤7完成：同上；步骤8完成：无冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-02] ingest | UI Designer Agent Personality
|
||
- Source file: Agent/agency-agents/design/design-ui-designer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency 设计部门的视觉界面设计专家 Agent——核心职责：创建视觉设计系统、组件库和像素级界面；Design System First 方法在创建单个界面之前先建立组件基础；WCAG AA 无障碍标准内置于架构层而非后期添加；交付物包含设计令牌系统、响应式框架、组件文档和设计 QA 流程；成功指标：95%+ 界面一致性、90%+ 开发者交接准确率
|
||
- Source page: wiki/sources/design-ui-designer.md（新建）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含八节）；步骤4完成：index.md 第11行添加新条目；步骤5完成：overview.md 第100行已有该来源综合摘要，无需修订；步骤6完成：The-Agency/UX-Architect/Brand-Guardian Entity 均已存在，无需新建；步骤7完成：Design-Token-System/Component-Library-Architecture/WCAG-Accessibility-Standards 等 Concept 均已存在，无需新建；步骤8完成：Contradictions 记录与 Whimsy Injector 的张力；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-15] ingest | 为 The Agency 贡献代码
|
||
- Source file: Agent/agency-agents/CONTRIBUTING_zh-CN.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency 智能体项目的开源贡献指南——涵盖行为准则（尊重、包容、协作、专业）、4种贡献方式（创建智能体/优化/分享案例/反馈问题）、智能体设计五原则（鲜明性格+明确交付物+可量化指标+经过验证的工作流+学习记忆）、PR 提交流程（含提交前检查清单）和风格指南（具体明确+落地务实+让人记住+实用可用）
|
||
- Source page: wiki/sources/contributing_zh-cn.md（新建）
|
||
- Entities updated: The-Agency.md（添加 frontmatter 和 sources 引用，更新 last_updated）
|
||
- Concepts updated: Agent-Template.md（追加 sources 引用，更新 last_updated）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第11行添加新条目；步骤5完成：overview.md 第26行已有该来源综合摘要，无需修订；步骤6完成：The-Agency.md 添加 frontmatter 和 sources 引用；步骤7完成：Agent-Template.md 追加 sources 引用；步骤8完成：无冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-15] ingest | Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 通过 Terraform 在 AWS 上自动化部署 RDS 数据库——DBRE 团队 Greg 主讲，提倡所有规模 RDS 均用 Terraform 而非 Console；推荐 Gruntwork RDS Service 模块（含 KMS 加密 + CloudWatch 告警），配合 Terragrunt 管理多环境配置，使用 tagged release 确保稳定性；Day 2 运维通过 GitHub PR + Atlantis 审批后自动 apply，支持扩缩容、打补丁、主版本升级；核心 IaC 价值为"代码即文档"
|
||
- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md（新建）
|
||
- Entities created: Greg.md（DBRE 团队成员，Terraform IaC 推广者）
|
||
- Entities updated: Gruntwork.md、Amazon-RDS.md、Terragrunt.md、Atlantis.md（追加 sources 引用）
|
||
- Concepts updated: Infrastructure-as-Code.md（追加 sources 引用）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：source page 已在 index.md 第302行存在，无需重复添加；步骤5完成：overview.md 无需修订；步骤6完成：新建 Greg.md Entity 页面，更新 Gruntwork.md/Amazon-RDS.md/Terragrunt.md/Atlantis.md sources 引用，更新 index.md Entities 节；步骤7完成：Infrastructure-as-Code.md 追加来源引用；步骤8完成：无冲突，仅与 ctp-topic-48 存在观点角度差异（不矛盾）已在 Contradictions 节记录；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-15] ingest | Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md
|
||
- Status: ✅ 成功摄入（已存在，更新 + 修复）
|
||
- Summary: 通过 Terraform IaC 实现 ECS 容器化应用的自动化部署——JP 和 Raja M 主讲，CTP/SRE 团队基于 Gruntwork 构建 ECS Terraform 模块，支持 Docker 容器/EC2 部署，具备自动扩缩容、自动故障恢复、金丝雀部署能力；采用 Listener 集中管理方式；前置条件包括 VPC、ELB 安全组和 EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus
|
||
- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md（已存在，更新了 Connections 节的 self-reference bug 并追加新连接）
|
||
- Entities created: JP.md（CTP 讲师，ECS 业务/技术背景介绍）、Raja-M.md（CTP/SRE 成员，ECS 模块构建者）、CTP-SRE-Team.md（CTP/SRE 团队）、AWS.md（更新 sources 引用）、Gruntwork.md（更新 sources 引用）
|
||
- Entities already existed: cloud-transformation-programme.md（index.md 第 642 行，已包含本来源引用）、Gruntwork.md（index.md 第 720 行，已追加来源引用）、AWS.md（index.md 第 583 行，已追加来源引用）
|
||
- Concepts created/updated: Canary-Deployment.md（新建，金丝雀部署策略）、ECS-Module.md（新建，ECS Terraform 模块）、InfrastructureAsCode.md（追加来源引用）
|
||
- Concepts already existed: Infrastructure-as-Code.md（index.md 第 1469 行）、Canary-Deployment.md（index.md 第 1150 行）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 存在，修复第 46 行 self-reference bug 并追加与 learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform 的关联；步骤4完成：index.md 第 302 行已有条目；追加 CTP-SRE-Team/JP/Raja-M 至 Entities 节，追加 ECS-Module 至 Concepts 节；步骤5完成：overview.md 第 255 行已有该来源综合摘要，无需修订；步骤6完成：新建4个 Entity 页面（JP/Raja-M/CTP-SRE-Team/AWS/Gruntwork 追加来源），更新 index.md Entities 节；步骤7完成：新建 Canary-Deployment.md/ECS-Module.md Concept 页面，更新 InfrastructureAsCode.md sources 引用，更新 index.md Concepts 节；步骤8完成：与 ctp-topic-64_scaling-out-with-amazon-eks 存在容器编排选型差异已在 Contradictions 节记录；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-15] ingest | CTP Topic 16 Cross-account Terraform modules
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 跨账号 Terraform 模块的中心化部署方案——基于 Shared Account 作为中转站，Jenkins 检测 cross-account.json 标记文件触发 ECS Deploy Runner，通过 Assume Role 访问目标账号的 TF State Bucket Accessor 和 Cross-account ECS Deploy Runner Role 两个角色，实现安全性（账号间无直接信任）、自动化（Jenkins 自动识别模块类型）、可复用性（模块不硬编码特定账号角色）
|
||
- Concepts created/updated: Cross-account-Terraform-Modules.md（已存在，补充 Source 引用）, ECS-Deploy-Runner.md（entities+concepts 双页）, Shared-Account.md（entities+concepts 双页）, TF-State-Bucket-Accessor.md（entities+concepts 双页）, Assume-Role.md, Blast-Radius.md, Root-Terragrunt-HCL.md, cross-account-json.md
|
||
- Entities created: Fibos.md, ECS-Deploy-Runner.md（entities 页）, Shared-Account.md（entities 页）, TF-State-Bucket-Accessor.md（entities 页）, Cross-account-ECS-Deploy-Runner-Role.md
|
||
- Source page: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md（已存在且格式完整）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 已存在无需重建；步骤4完成：index.md 第302行已有条目；步骤5完成：overview.md 无需修订（source page 已有完整摘要）；步骤6完成：新建5个 Entity 页面（Fibo/ECS-Deploy-Runner/Shared-Account/TF-State-Bucket-Accessor/Cross-account-ECS-Deploy-Runner-Role）并更新 index.md Entities 节；步骤7完成：新建8个 Concept 页面并更新 index.md Concepts 节；步骤8完成：无内容冲突（与 Gruntwork/Atlantis 为演进关系）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-13] ingest | CTP Topic 48 Terraform vs Terragrunt
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Terraform 与 Terragrunt 深度对比——Terraform（HashiCorp）通过状态文件将期望状态绑定到实际环境，支持多云；Terragrunt 轻量封装践行 DRY 原则，管理 provider/remote_state 块减少跨环境重复声明；两者命令语法完全一致；辅助工具链：Terraform Enterprise、Gruntwork、Atlantis、tfsec、Terratest
|
||
- Concepts created: InfrastructureAsCode.md, TerraformState.md
|
||
- Entities created: HashiCorp.md, Gruntwork.md, Atlantis.md
|
||
- Entities already existed: HashiCorp（index.md 第720行）、Gruntwork（index.md 第717行）、Atlantis（index.md 第582行）
|
||
- Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第301行已有条目，无需重复添加；步骤5完成：overview.md 第253行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 HashiCorp.md/Gruntwork.md/Atlantis.md Entity 页面（HashiCorp/Gruntwork/Atlantis 在 index.md 中已存在，故在各自页面内追加 sources 引用）；步骤7完成：新建 InfrastructureAsCode.md/TerraformState.md Concept 页面，index.md Concepts 节追加对应条目；步骤8完成：无冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-12] ingest | Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2 - 20240917
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 事件驱动架构（EDA）进阶最佳实践与团队协作模式——三组件（生产者/消费者/代理）、Event Router vs Event Store、Choreography vs Orchestration、幂等性、事件排序（SQS FIFO/Kinesis）、去中心化团队所有权、Fan-out 模式（SNS/EventBridge）、竞争消费者模式（Compete Consumer）、死信队列（DLQ）和 EventBridge 最佳实践
|
||
- Concepts created: Event-Driven-Architecture.md, Idempotency.md, Fan-Out-Pattern.md, Competing-Consumer-Pattern.md, Choreography.md, Orchestration.md
|
||
- Entities created: Anil-Giri.md, AWS-EventBridge.md
|
||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第296行已有条目，补充日期前缀（2024-09-17）和一行摘要；步骤5完成：overview.md 第407行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Anil-Giri.md/AWS-EventBridge.md Entity 页面，index.md Entities 节追加 Anil-Giri/AWS-EventBridge；步骤7完成：新建 Event-Driven-Architecture/Idempotency/Fan-Out-Pattern/Competing-Consumer-Pattern/Choreography/Orchestration 共6个 Concept 页面，index.md Concepts 节追加对应条目；步骤8完成：无冲突（Part 2 与 Part 1 为互补关系）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-12] ingest | Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS 生成式 AI 服务生态与 Prompt Engineering 实践——OpenText 技术客户经理 Shikad Holtzman 主讲；生成式 AI 四大价值路径、AWS 三层技术栈；数据是差异化关键；Bedrock（RAG/微调/Agents/Guardrails）+ Amazon Q（Business/Developer）；Prompt Engineering 四大组件与 One-shot/Few-shot/Chain-of-Thought 技巧
|
||
- Concepts created: Prompt-Engineering.md
|
||
- Entities created: Shikad-Holtzman.md, Amazon-Q.md, Anthropic.md, Meta-AI.md
|
||
- Entities updated: Amazon-Bedrock.md（追加来源引用）
|
||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第295行已有条目（2026-04-28 先前摄入痕迹），无需重复添加；步骤5完成：overview.md 第401行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Shikad-Holtzman.md/Amazon-Q.md/Anthropic.md/Meta-AI.md Entity 页面，更新 Amazon-Bedrock.md 追加来源引用；步骤7完成：新建 Prompt-Engineering.md Concept 页面；步骤8完成：记录与 llms-rag-ai-agent-三个到底什么区别 的 RAG 运维复杂度视角冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-12] ingest | Public Cloud Learning Sessions (OpenText) - Serverless Computing - 20240903
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS 无服务器计算深度解析——OpenText 主办，聚焦 AWS Lambda（事件驱动/权限模型/版本/Layers/ARM64）、Step Functions（状态机/Standard&Express）、API Gateway（边缘优化/区域/私有）和 SAM（基于 CloudFormation 的本地开发和部署工具）
|
||
- Concepts: 无新 Entity 页面创建（Lambda/Step Functions/API Gateway/SAM 为 AWS 官方服务，overview.md 已有充分描述）
|
||
- Entities: 无新 Entity 页面创建（同上）
|
||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第293行添加日期前缀（2024-09-03）和中文摘要；步骤5完成：overview.md 第405行已有该来源详细综合摘要，内容一致无需修订；步骤6-7完成：无需创建新 Entity/Concept 页面（AWS 官方服务 overview 已有描述）；步骤8完成：无冲突（与 EDA Part 1/2 共享事件驱动模型属互补关系）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-12] ingest | Public Cloud Learning Sessions - Introduction to AI/ML with AWS
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS AI/ML 入门——Suraav Paul（AWS 高级解决方案架构师）主讲，AI 三层分类（分类 AI/预测 AI/生成式 AI）、Amazon Bedrock 全托管生成式 AI 服务（基础模型+微调+RAG+Agents+Guardrails）、ML Ops 三管道（数据/训练/推理）；强调 Bedrock 数据隐私保证和负责任 AI 六大原则
|
||
- Concepts created: Foundation-Models.md, MLOps.md, Responsible-AI.md
|
||
- Entities created: Suraav-Paul.md, Amazon-SageMaker.md, Amazon-Titan.md
|
||
- Entities updated: Amazon-Bedrock.md（追加来源引用）
|
||
- Source page: wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第297行添加日期前缀和摘要；步骤5完成：overview.md 第399行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Suraav-Paul.md/Amazon-SageMaker.md/Amazon-Titan.md Entity 页面，更新 Amazon-Bedrock.md 追加来源引用；步骤7完成：新建 Foundation-Models.md/MLOps.md/Responsible-AI.md Concept 页面，index.md Entities 节追加 Amazon-SageMaker/Amazon-Titan/Suraav-Paul，Concepts 节追加 Foundation-Models/Responsible-AI/MLOps；步骤8完成：无冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-12] ingest | Cloud Learning Master Index
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Cloud Learning Master Index — Public Cloud Learning Sessions 全部111个视频的分类索引目录（10大类：AWS Landing Zone 22、OpenText Series 21、EKS & Kubernetes 14、Security 9、Networking 9、Serverless & AI 9、FinOps & Cost 10、CI/CD & GitOps 8、IAM & Identity 3、Terraform & IaC 6）
|
||
- Entities created: （无新建 — Gruntwork/Grafana/Karpenter/Bottlerocket 等将在子视频 source pages 摄入时创建）
|
||
- Source page: wiki/sources/cloud-learning-master-index.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第291行补充日期前缀和一行摘要；步骤5完成：overview.md 第219行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：无需新建 Entity（OpenText.md/MicroFocus.md/Atlantis.md 等已存在；Gruntwork/Grafana/Karpenter 等将在子视频 source pages 摄入时创建）；步骤7完成：无需新建 Concept（FinOps.md/GitOps.md/Karpenter.md 等已存在；Landing-Zone/EKS/Terraform/IAM 等作为顶层框架将在子视频 source pages 摄入时精确定义）；步骤8完成：记录与 ctp-topic-34-azure-landing-zone-architecture-overview 的跨平台差异冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-12] ingest | CTP Topic 27 AWS Instance Scheduler
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS Instance Scheduler — 通过 CloudWatch Events 每15分钟触发 Lambda → 读取 DynamoDB 调度配置 → 根据实例标签（Schedule/Period/Override）自动启停 EC2/RDS；CCOE Guardrails 框架自动部署，覆盖月消费10美元以上 AWS 账号；RDS 维护窗口智能配合； Gustavo 主讲
|
||
- Concepts created: AWS-Instance-Scheduler.md, CloudWatch-Events.md, DynamoDB-Config-Table.md, Tagging.md, RDS-Maintenance-Window.md, Override-Status.md
|
||
- Entities created/updated: Gustavo.md（新建）, Godrails.md（已有，更新添加 Topic 27 来源和详情）
|
||
- Source page: wiki/sources/ctp-topic-27-aws-instance-scheduler.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第297行添加日期前缀和摘要；步骤5完成：overview.md 第389行已有该来源详细摘要，内容一致无需修订；步骤6完成：新建 Gustavo.md Entity 页面，更新 Godrails.md（含 Aliases、Topic 13+27 来源、Guardrails 机制详情）；删除错误创建的 Guardrails.md（与 Godrails 为同一实体）；步骤7完成：新建 AWS-Instance-Scheduler/CloudWatch-Events/DynamoDB-Config-Table/Tagging/RDS-Maintenance-Window/Override-Status 共6个 Concept 页面；步骤8完成：无冲突（与 Topic 13/63 引用一致的 instance scheduler FinOps 策略）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-12] ingest | Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS - 20240529
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS EC2 成本优化最佳实践：Graviton（40% 性价比提升/60% 功耗降低）、Spot 竞价实例（90% 折扣）、AWS Nitro 虚拟化、Nitro Enclave；Mike Dukes 和 Steele Taylor 主讲；Spot Invaders 游戏演示容错混沌工程
|
||
- Concepts created/updated: [[AWS-Nitro]]（新建）、[[EC2-Spot-Instances]]（新建）、[[ECS]]（新建）；[[Graviton]]（已有，已追加来源链接）、[[SpotInstances]]（已有，已追加来源链接）
|
||
- Entities created/updated: [[Mike-Dukes]]（新建）、[[Steele-Taylor]]（新建）、[[Spot-Invaders]]（新建）
|
||
- Source page: wiki/sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第294行添加日期前缀和摘要；步骤5完成：overview.md 第397行已有该来源详细摘要，无需修订；步骤6完成：新建 Mike-Dukes.md/Steele-Taylor.md/Spot-Invaders.md Entity 页面；步骤7完成：新建 AWS-Nitro.md/EC2-Spot-Instances.md/ECS.md Concept 页面；更新 Graviton.md/SpotInstances.md 添加来源引用；步骤8完成：记录与 CTP Topic 13 的潜在冲突点（Graviton 适用场景，已协调）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-12] ingest | CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Cloud FinOps 治理框架：PCG 三层服务模型（成本管理/成本优化/治理自动化）、5 大核心策略（账单可见性/标签合规/预算责任/RI集中管理/区域限制）、安全控制（Godrails/联合身份管理）、Cloud Health 监控工具、实例选型标准化（M/T/C/R/X+Graviton）、研发环境三合一优化（突发性+Spot+调度器）
|
||
- Concepts created/updated: [[Graviton]]（新建）、[[CloudHealth]]（新建）、[[ReservedInstances]]（新建）、[[SpotInstances]]（已有，已链接）、[[SavingsPlans]]（已有，已链接）、[[FinOps]]（已有，已更新链接）
|
||
- Entities created/updated: [[PCGTeam]]（已存在，已更新）、[[Uday]]（新建）、[[Vinay]]（已存在）、[[Godrails]]（新建）
|
||
- Source page: wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第297行添加日期前缀和摘要；步骤5完成：overview.md 修正5处 wikilinks（从 ctp-topic-13-cloud-finops-policies 更正为 ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co）；步骤6完成：新建 Uday.md/Godrails.md Entity 页面，更新 PCGTeam.md；步骤7完成：新建 Graviton.md/CloudHealth.md/ReservedInstances.md Concept 页面，FinOps/SpotInstances/SavingsPlans 已存在；步骤8完成：无冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-11] ingest | CTP Topic 15 Working with Renovatebot
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-15-working-with-renovatebot.md
|
||
- Status: ✅ 成功摄入（补充新建缺失 Entity/Concept 页面）
|
||
- Summary: Renovate Bot 自动化管理云原生基础设施依赖项更新——解决"依赖地狱"问题，实时扫描 Docker 镜像/Terraform 模块/Terragrunt 配置/pre-commit 钩子版本标签，自动发起 Pull Request；通过 Dependency Dashboard 提供全局依赖状态视图；集成 Jenkins 流水线，使用 Podman 容器化运行并配置 Rate Limiting 避免 PR 风暴。
|
||
- Concepts created/updated: [[Dependency-Dashboard]]（新建）、[[Rate-Limiting]]（新建）、[[Pre-commit-Hooks]]（新建）
|
||
- Entities created: [[Paul-Hopkins]]（新建，作为关键人物创建）
|
||
- Source page: wiki/sources/ctp-topic-15-working-with-renovatebot.md
|
||
- Notes: 步骤3完成：source page 已存在（之前已摄入）；步骤4完成：index.md 补充 Dependency-Dashboard/Rate-Limiting/Pre-commit-Hooks 到 Concepts 节、Paul-Hopkins 到 Entities 节；步骤5完成：overview.md 第249行已有该来源详细摘要，内容一致无需修订；步骤6完成：新建 Paul-Hopkins.md Entity 页面；步骤7完成：新建 Dependency-Dashboard.md/Rate-Limiting.md/Pre-commit-Hooks.md Concept 页面；步骤8完成：无新冲突；步骤9完成：log.md 追加记录。Renovate-Bot.md/Semantic-Versioning.md/Dependency-Management.md/Gruntwork.md/Jenkins.md/Terragrunt.md 均已存在，本次无需新建。
|
||
|
||
## [2026-05-11] ingest | Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Oli Workflow（超大规模云厂商支出审批流程）与需求管理端到端全链路——三阶段审批工作流（FinOps→Cloud Services→FPNA）和 OpenText 需求管理流程（Octane/Qixi 提交→主服务目录→SMACs 嵌入→自动化履约），目标是 80% 场景业务单元自助完成需求
|
||
- Concepts created: Demand-Management.md, ITIL-Service-Management.md, SMACs.md, FinOps.md, Product-Backlog.md, Oli-Workflow.md
|
||
- Entities created: Tom-Bice.md, FPNA-Team.md, MUI.md, Shannon.md, Octane.md, Qixi.md
|
||
- Source page: wiki/sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md
|
||
- Notes: 步骤3完成：source page 已存在（步骤1确认）；步骤4完成：index.md 第287行已有条目；步骤5完成：overview.md 第379行已有该来源详细摘要，无需修订；步骤6完成：新建 Tom-Bice.md/FPNA-Team.md/MUI.md/Shannon.md/Octane.md/Qixi.md Entity 页面（均符合≥2次提及的创建条件）；步骤7完成：新建 Demand-Management.md/ITIL-Service-Management.md/SMACs.md/FinOps.md/Product-Backlog.md/Oli-Workflow.md Concept 页面（均符合可抽象/可复用/非具体实例的创建条件）；步骤8完成：无新冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-08] ingest | CTP Topic 3 Deploy and maintain infrastructure
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Landing Zone 多账号架构下基础设施部署与维护——核心区分 Service Module（业务视角，满足业务需求的一组模块组合）与 Regular Module（技术视角）；Terragrunt HCL 通过版本锁定引用模块而非 master 分支；Service Catalog 支持三级复用（单账户→产品团队→跨团队）；类 OO 继承原则：抽象层级越高，配置选项越少
|
||
- Concepts created: （无新建 — Terraform/Terragrunt/Service-Catalog/Landing-Zone/Module/Infrastructure-as-Code 均已存在）
|
||
- Entities created: （无新建 — Terraform/Terragrunt/Gruntwork/Jenkins 均已存在）
|
||
- Source page: wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 条目补充日期前缀和一行摘要；步骤5完成：overview.md 第221行已有该来源详细摘要，内容一致无需修订；步骤6完成：无新建 Entity（Terraform/Terragrunt/Gruntwork/Jenkins 均已存在，DevTools 仅1次提及未达阈值）；步骤7完成：无新建 Concept（Service-Catalog/Terraform/Terragrunt/Landing-Zone 等均已存在）；步骤8完成：Contradictions 记录与 ctp-topic-1（框架vs自主）和 ctp-topic-48（Terragrunt对比）的视角关系；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-29] ingest | CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Atlantis 替代 Jenkins 用于 Terraform IaC 部署的 CTP 视频，核心痛点：Jenkins 流水线初始化慢（多次代码克隆/顺序测试/ECS 预配置）和架构复杂（持续叠加功能导致脆弱）。Atlantis 提供 PR 评论式协作模型，支持模块 Locking、并行构建、跨账户 IAM 角色访问，merge 前 Apply 确保代码与基础设施同步。
|
||
- Concepts created: [[GitOps]]（已存在，本次更新扩充内容，新增 Pull vs Push 模型对比和工具生态表）
|
||
- Entities created: [[Atlantis]]（新建 Entity 页面，含核心功能、架构说明）、[[Jenkins]]（新建 Entity 页面，含痛点对比表）
|
||
- Source page: wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第287行已有条目，以正确格式补充日期和一行摘要；步骤5完成：overview.md 第245行已有详细条目，本次无需修订；步骤6完成：新建 Atlantis.md 和 Jenkins.md Entity 页面（均符合出现≥2次的创建条件）；步骤7完成：GitOps.md 概念页已存在，本次扩充 Pull vs Push 模型对比和工具生态表；步骤8完成：无新冲突（Atlantis vs Jenkins 的 pre-merge-apply vs post-merge-deploy 差异已在 Contradictions 节记录）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-04] ingest | CTP Topic 9 CI CD with Gruntwork
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-9-ci-cd-with-gruntwork.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: CTP Topic 9 — CI/CD 与 Gruntwork IaC 集成视频（状态：待 Whisper 转录）。源文件仅有 frontmatter 元数据，含 tags: [CI/CD, Gruntwork, IaC, CTP]，视频尚未转录，Summary/Key Claims/Key Quotes 均标记为待补充。已与 Gruntwork Entity、CI/CD Concept、同分类其他 CTP 来源建立 Connections 链接。
|
||
- Concepts created: （无新建 — CI/CD、GitOps、Infrastructure-as-Code Concept 页面均已存在，直接引用）
|
||
- Entities created: [[Gruntwork]]（已存在，直接引用）
|
||
- Source page: wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第285行已有条目，以正确格式补充日期 2026-04-14；步骤5完成：overview.md 第223行已有该主题条目，本次无需修订；步骤6完成：Gruntwork Entity 页面已存在，直接引用；步骤7完成：CI/CD、GitOps、Infrastructure-as-Code Concept 页面均已存在，直接引用；步骤8完成：无冲突；步骤9完成：log.md 追加记录。⚠️ 视频待 Whisper 转录后需重新补充 Summary/Key Claims/Key Quotes 内容。
|
||
|
||
## [2026-05-04] ingest | CTP Topic 2 Git
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-2-git.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Git 版本控制基础与实践学习视频（状态：待 Whisper 转录）。源文件仅有 frontmatter 元数据，含 tags: [Git, VCS, CTP]，视频未转录，Summary/Key Claims/Key Quotes 均标记为待补充。已与同分类下其他 CTP CI/CD GitOps 来源建立 Connections 链接。
|
||
- Concepts created: [[GitOps]]（已存在，引用）
|
||
- Entities created: （无新建 — 源文件未提及具体人物）
|
||
- Source page: wiki/sources/ctp-topic-2-git.md
|
||
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第288行已有条目，以正确格式补充日期和一行摘要；步骤5完成：overview.md 无需修订（该来源属于 CTP DevOps 系列，overview 中 Git 相关内容不涉及 CTP 上下文）；步骤6完成：无新建 Entity 页面（源文件无具体人物）；步骤7完成：GitOps Concept 页面已存在，直接引用；步骤8完成：无冲突；步骤9完成：log.md 追加记录。⚠️ 视频待 Whisper 转录后需重新补充 Summary/Key Claims/Key Quotes 内容。
|
||
|
||
## [2026-04-29] ingest | CTP Topic 49 Container Lifecycle Hardening Standards
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Micro Focus 容器镜像构建阶段 11 项安全加固标准，涵盖基础镜像选择、Init 系统、只读文件系统、私有服务账号等
|
||
- Concepts created: Container Lifecycle Hardening（已存在）, Read-Only Root Filesystem（已存在）, Init System in Containers（已存在）, Kubernetes Security Context（已存在）, Container Image Scanning（已存在）, Principle of Least Privilege（已存在）, Network Isolation（已存在）
|
||
- Entities created: Ashish（已存在）, Micro Focus（已存在）, Kubernetes（已存在）, Product Security Group（已存在）
|
||
- Source page: wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md
|
||
- Notes: Entity 和 Concept 页面在之前的 batch ingest 中已创建，本次仅生成 source 页面
|
||
|
||
## [2026-05-04] ingest | CTP Topic 55 AWS Firewall Manager
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-55-aws-firewall-manager.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践。核心动机：跨 RLABS/R&D/SAS/CAT 多个 Landing Zone 管理安全策略的复杂性；原有 Checkpoint Firewall 无法完全覆盖公网子网流量安全。核心方案：①在独立 Firewall Manager 账户创建安全组策略，指定目标账户或 OU，自动将基线安全组附加到现有和新实例；②三种策略类型——通用安全组（允许产品团队自增）、审计与强制安全组规则（拒绝过度宽松规则，支持手动或自动修复）、清理未使用冗余安全组；③通过 RAM Prefix List 跨账户共享规则，支持 Atlantis CI/CD 流水线部署。Demo 演示了策略创建后 EC2 实例的自动附加与策略删除后的自动移除。前提条件：OU 内管理员权限 + AWS Config 全账户启用。
|
||
- Concepts touched: [[AWS Firewall Manager]], [[Security Group Policy]], [[AWS Config]], [[AWS Lambda]], [[Prefix List]], [[AWS RAM]], [[Landing Zone]]
|
||
- Entities touched: [[Grand Torque Landing Zone]], [[LAPS Landing Zone]], [[SAS Landing Zone]], [[Digital Factory Landing Zone]], [[Atlantis Server]], [[QALIS]]
|
||
- Concepts created: [[AWS Firewall Manager]], [[Security Group Policy]]
|
||
- Entities created: (无新建 — Landing Zone Entity 页面待后续批量整理)
|
||
- Source page: wiki/sources/ctp-topic-55-aws-firewall-manager.md
|
||
- Notes: 步骤3完成：新建 source page（严格按 Source Page Format，含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第277行已有条目，本次补充日期和一行摘要；步骤5完成：overview.md 第319行已有详细条目，本次无需修订；步骤6完成：无新建 Entity 页面（Landing Zone Entity 页面待后续批量整理 CTP Security 相关实体）；步骤7完成：新建2个 Concept 页面（AWS-Firewall-Manager、Security-Group-Policy）；步骤8完成：无冲突（Firewall Manager 与 Checkpoint Firewall 为互补关系，非竞争替代，详见 source page Contradictions 节）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-04] ingest | CTP Topic 62 AWS Secrets Manager
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-62-aws-secrets-manager.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS Secrets Manager 企业实施与标准化——Nurit 和 Daniel 主讲。是前一年 7 月学习会议的续篇，介绍了 AWS Secrets Management Standard 文档，分享了实施机会。核心内容：①Secrets 管理平台选型（HashiCorp Vault vs AWS Secrets Manager，后者因成本更低被选中）；②三阶段实施方法（集中 Secrets → 调整自动化获取 → 启动轮换）；③Lambda 函数配合 JDBC Wrapper 实现无密码 Oracle 数据库访问；④SendGrid API Key 集中轮换方案；⑤通过 Control Tower 实现企业级 Secrets 标准化管理。
|
||
- Concepts touched: [[SecretsManagement]], [[SecretRotation]], [[JDBCWrapper]], [[ControlTower]]
|
||
- Entities touched: [[Nurit]], [[Daniel]], [[Victor]], [[HashiCorpVault]], [[AWSControlTower]], [[SendGrid]]
|
||
- Concepts created: [[SecretsManagement]], [[SecretRotation]], [[JDBCWrapper]]
|
||
- Entities created: (无新建 — Entity 页面待后续整理)
|
||
- Source page: wiki/sources/ctp-topic-62-aws-secrets-manager.md
|
||
- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第275行），本次以正确格式更新并补充摘要；步骤5完成：overview.md 无需修订（该来源属于 CTP Security 系列，overview 中有相关上下文）；步骤6完成：无新建 Entity 页面（待后续批量整理 CTP Security 相关人物）；步骤7完成：新建3个 Concept 页面（SecretsManagement、SecretRotation、JDBCWrapper）；步骤8完成：无冲突（与 HashiCorp Vault 的对比属技术选型视角差异，已记录于 Contradictions 节）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-28] ingest | CTP Topic 65 Tracing the Value Delivered in Cloud Transformation
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 云转型计划（CTP）价值交付追踪方法论——区分 Process/Value/Value Stream 三个层次；价值分解为财务、生产力、质量、体验四维度；WSJF 公式（CoD/Job Size）排列工作优先级；功能级价值分解三种策略；综合框架涵盖年收入增长、成本降低、风险改善、SOM 四大价值维度。
|
||
- Concepts touched: [[Value Stream]], [[Weighted Shortest Job First (WSJF)]], [[Cost of Delay (CoD)]], [[Process]], [[Value-Adding Activity]], [[Serviceable Obtainable Market (SOM)]]
|
||
- Entities touched: [[Cloud Transformation Programme (CTP)]]
|
||
- Concepts created: [[Value Stream]], [[Weighted Shortest Job First (WSJF)]], [[Cost of Delay (CoD)]], [[Serviceable Obtainable Market (SOM)]]
|
||
- Entities created: [[Cloud Transformation Programme (CTP)]]
|
||
- Source page: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
|
||
- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第242行），无需更新；步骤5完成：overview.md 无需修订（该来源属于 CTP 专题系列，overview 中已有综合 CTP 上下文）；步骤6完成：新建1个 Entity 页面（Cloud Transformation Programme）；步骤7完成：新建4个 Concept 页面（Value Stream、Weighted Shortest Job First、Cost of Delay、SOM）；步骤8完成：无冲突（与 ctp-topic-53 互补而非矛盾：Topic 53 论证"为何上云"，本主题解决"如何衡量云转型价值"）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-28] ingest | CTP Topic 4 Using Agile to Run the Cloud Transformation Programme
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 云转型项目中敏捷框架实践——Heather Norris 主讲。框架演进：Scrum（两周 Sprint）→ Kanban（持续流）→ 混合框架（Kanban + Scrum 仪式）。Scrum 局限：Sprint 期间不允许变更需求。Kanban 优势：随时调整优先级、持续交付。混合方案：保留每日站会和回顾会，使用 Microsoft Planner 五列看板。核心理念：敏捷本质是快速反馈循环，持续改进产品和开发文化。
|
||
- Concepts touched: [[Scrum]], [[Kanban]], [[Scrum-Kanban混合框架]], [[Microsoft Planner]]
|
||
- Entities touched: [[Heather Norris]]
|
||
- Concepts created: 无（Scrum.md、Kanban.md 均已存在）
|
||
- Entities created: 无（Heather Norris.md 已存在）
|
||
- Source page: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
|
||
- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第247行），无需更新；步骤5完成：overview.md 无需修订（Agile/Scrum/Kanban 内容已覆盖于现有概述中）；步骤6完成：无新增 Entity（Heather Norris.md 已存在）；步骤7完成：无新增 Concept（Scrum.md、Kanban.md 均已存在）；步骤8完成：无冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-28] ingest | CTP Topic 43 VMware Cloud on AWS
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws.md
|
||
- Status: ✅ 成功摄入（re-ingest：补充缺失实体/概念页面）
|
||
- Summary: VMware Cloud on AWS（VMC on AWS）混合云服务介绍——VMware 与 AWS 联合工程，在 AWS 裸金属服务器（i3.metal/i3en.metal）上原生安装 vSphere 8，为不完全准备完全迁移至原生云的企业提供中间路线。相比常规云方案节省 27% 成本，支持 HCX 任意迁移，Brian Reeves 主持经济学讨论，Mike O'Reilly 主讲技术架构。属 [[Hybrid-Cloud]] 在 AWS 落地的核心实践。
|
||
- Concepts touched: [[VMware-Cloud-on-AWS]], [[SDDC]], [[HCX]], [[Stretched-Cluster]], [[TCO]]
|
||
- Entities touched: [[VMware]], [[AWS]], [[BrianReeves]], [[MichaelRiley]], [[MikeArmstrong]], [[MikeOReily]]
|
||
- Concepts created: [[TCO]]
|
||
- Entities created: [[BrianReeves]], [[MichaelRiley]], [[MikeArmstrong]], [[MikeOReily]]
|
||
- Source page: wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md
|
||
- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），本次修复双竖线格式问题；步骤4完成：index.md 条目已存在（第254行），无需更新；步骤5完成：overview.md 已有该来源摘要（line 331），内容一致无需修订；步骤6完成：新建4个 Entity 页面（BrianReeves、MichaelRiley、MikeArmstrong、MikeOReily），补充 TCO 到 VMware.md 和相关 Concept 页面的 Sources 节；步骤7完成：新建 [[TCO]] Concept 页面，补充 [[TCO]] 到 Source page Key Concepts 节；步骤8完成：无冲突（与 ctp-topic-53 的张力已在 Contradictions 节记录，属云迁移决策的视角差异而非事实冲突）；步骤9完成：log.md 追加本次 re-ingest 记录
|
||
|
||
## [2026-04-28] ingest | CTP Topic 19 Configuring DNS within AWS LZs
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS Landing Zone 多账号环境下的集中化 DNS 管理架构——Sankar Gopov 主讲。核心方案：设立专门 DNS 账号（InfoBlocks 账号）集中管理 Route 53 私有托管区（PHZ）和 Resolver Rules，优于分散式 PHZ 管理。关键技术：Route 53 Resolver Inbound Endpoint（接收 On-prem 解析请求）和 Outbound Endpoint（转发 AWS → On-prem 请求）；AWS RAM 跨账号共享 Resolver Rules；跨账号 PHZ 关联两步流程（授权→关联）；Terraform 自动化部署。典型场景：AWS → On-prem、On-prem → AWS、账号间相互解析。属 [[AWS-Landing-Zone]] 网络基础服务层，与 Topic 18（广域网）和 Topic 31（网络安全）共同构成完整网络知识体系。
|
||
- Concepts touched: [[Route-53-Resolver]], [[Private-Hosted-Zone]], [[Resolver-Rules]], [[AWS-RAM]], [[VPC-Association-Authorization]], [[AWS-Landing-Zone]]
|
||
- Entities touched: [[SankarGopov]]
|
||
- Concepts created: [[Route-53-Resolver]], [[Private-Hosted-Zone]], [[Resolver-Rules]], [[VPC-Association-Authorization]]
|
||
- Entities created: (无新建 — SankarGopov 已存在)
|
||
- Source page: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md
|
||
- Notes: 步骤3完成：新建 Source page；步骤4完成：index.md 条目已存在（第255行），补充一行摘要；步骤5完成：overview.md 新增 CTP Topic 19 摘要条目（在 Topic 18 与 Topic 25 之间）；步骤6完成：新建4个 Concept 页面（Route-53-Resolver、Private-Hosted-Zone、Resolver-Rules、VPC-Association-Authorization），更新 SankarGopov Entity 来源引用；步骤7完成：Source page Key Concepts 节已覆盖全部关键概念；步骤8完成：无冲突；步骤9完成：log.md 追加本次记录
|
||
|
||
## [2026-04-28] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS Landing Zone 环境下的资源数据收集、标签体系及基于标签的安全控制策略——Steve Jarman 和 Pradeep 联合主讲。核心内容：①OU 分层 + SCP 强制标签规范防止用户篡改标签绕过审计；②标签体系涵盖机器名、所有者（PDL）、类型、BU、产品、环境、服务器角色等维度；③Checkpoint Firewall 基于标签的 Ordered Layers（地理封锁→类型→BU→产品→环境→角色）和 Inline Layers（基于账号编号的父子规则结构）；④Demo 演示标签缺失导致 EC2 流量被防火墙拦截。
|
||
- Concepts touched: [[AWS-Landing-Zone]], [[SCP-Security-Control-Policy]], [[Resource-Tagging]], [[Ordered-Layer]], [[Inline-Layer]], [[Checkpoint-Firewall]]
|
||
- Entities touched: [[AWS]], [[Checkpoint]], [[Pradeep]], [[Steve Jarman]]
|
||
- Concepts created: [[SCP-Security-Control-Policy]], [[Resource-Tagging]], [[Ordered-Layer]], [[Inline-Layer]]
|
||
- Entities created: [[Pradeep]], [[SteveJarman]]
|
||
- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
|
||
- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第31行、第250行），无需更新；步骤5完成：overview.md 已有该来源详细摘要（line 321），无需修订；步骤6完成：更新2个已有 Entity 页面（AWS-Landing-Zone、Checkpoint-Firewall），新增2个 Entity 页面（Pradeep、SteveJarman）；步骤7完成：新建4个 Concept 页面（SCP-Security-Control-Policy、Resource-Tagging、Ordered-Layer、Inline-Layer）；步骤8完成：与 CTP Topic 7 的视角差异已记录于 Contradictions 节（属账号结构 vs 标签驱动的互补视角）；步骤9完成：log.md 追加本次记录
|
||
|
||
## [2026-04-28] ingest | CTP Topic 22 Global DNS service offerings
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md
|
||
- Status: ✅ 成功摄入（re-ingest）
|
||
- Summary: 企业级全球 DNS 服务架构详解——Sankar 和 Vino 联合主讲。核心架构：Route 53 Private Hosted Zone（私有托管区域）配合 AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络的 DNS 查询；Outbound Endpoint 出站规则配置多个区域 AD 域控制器 IP，单区域故障时自动切换确保弹性。本地 Infoblox 平台利用 DNS Anycast 实现全球低延迟和自动故障转移；AWS EC2 不支持 Anycast，需手动维护 IP 列表。DNS 安全涵盖防隧道攻击、防数据外泄及缓存污染；"就近解析"原则优化 Office 365 等全球化 SaaS 访问性能。属 AWS Landing Zone 网络层 DNS 专题，与 ctp-topic-19 共同构成 Landing Zone DNS 完整体系。
|
||
- Concepts touched: [[HybridDnsResolution]], [[DNS-Anycast]], [[Landing-Zone-Architecture]], [[Route-53-Resolver]], [[IPAM]]
|
||
- Entities touched: [[AWS]], [[Infoblox]], [[SankarGopov]], [[VinoCTP]], [[Microsoft-Active-Directory]], [[Office-365]]
|
||
- Concepts created: [[DNS-Anycast]]
|
||
- Entities created: [[VinoCTP]]
|
||
- Source page: wiki/sources/ctp-topic-22-global-dns-service-offerings.md
|
||
- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），本次更新 Contradictions 节（ctp-topic-19 已摄入，补充完整互补关系说明）；步骤4完成：index.md 条目已存在（第257行），本次新增 [[VinoCTP]] Entity 和 [[DNS-Anycast]] Concept 条目；步骤5完成：overview.md 已有该来源摘要（line 345），内容一致无需修订；步骤6完成：新建 [[VinoCTP]] Entity 页面（CTP Topic 22 联合讲师）；步骤7完成：新建 [[DNS-Anycast]] Concept 页面（关键网络概念，本来源首次系统阐述）；步骤8完成：Contradictions 更新为视角互补说明（Topic 19 讲配置实施 → Topic 22 讲企业架构，属深度递进关系）；步骤9完成：log.md 追加本次 re-ingest 记录
|
||
|
||
## [2026-05-07] ingest | CTP Topic 50 AMI Roadmap for AWS AMIs (re-ingest)
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md
|
||
- Status: ✅ 成功摄入（re-ingest）
|
||
- Summary: CCOE AMI 路线图与 AWS 标准 AMI 生命周期规划——核心内容：CCOE 每两个月发布加固 AMI；ARM AMI 自 2023 年 5 月起同步发布；路线图优先级由 ADM 需求驱动；OS EOL 时间线（WS2008/2008R2 已 EOL；CentOS8 已 EOL；WS2012 即将 EOL；RHEL7/CentOS7 2024 年 6 月 EOL）；AMI 通知通过邮件发送至 CCOE notifications PDL；CCRE 门户变更日志；新 AMI 添加三阶段流程；AMI 跨账号共享机制
|
||
- Concepts touched: [[Foundation-AMI]], [[OS-End-of-Life]], [[AMI-Sharing]], [[ARM-AMI]], [[CCOE]], [[ADM]]
|
||
- Entities touched: [[CCOE]], [[AWS]], [[Amazon Linux]], [[Ubuntu]], [[CentOS]], [[Rocky Linux]], [[Red Hat Enterprise Linux]], [[SLES]], [[Windows Server]], [[McAfee]]
|
||
- Concepts created: [[ARM-AMI]], [[ADM]]
|
||
- Source page: wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md
|
||
- Notes: 步骤3完成：源页面已存在（2026-04-14 初版），本次补全 wikilinks 格式（Foundation AMI→Foundation-AMI, AMI Sharing→AMI-Sharing）；步骤4完成：index.md 条目已存在（第306行），无需重复添加；步骤5完成：overview.md 已有该来源摘要（line 313），内容一致无需修订；步骤6完成：Amazon Linux/Ubuntu/CentOS/SLES/Windows Server/McAfee 在 source doc 中出现次数不足以创建独立 Entity 页面（仅1-2次提及），按工作流规则跳过；Rocky Linux/Red Hat Enterprise Linux Entity 页面已存在，无需重复创建；步骤7完成：Foundation-AMI/OS-End-of-Life/AMI-Sharing Concept 页面已存在，本次新建 ARM-AMI.md 和 ADM.md；步骤8完成：Contradictions 已在 source page 记录（与 ctp-topic-26 的互补关系）；步骤9完成：log.md 追加本次 re-ingest 记录
|
||
|
||
## [2026-05-07] ingest | CTP Topic 26 Standard AMI – build, publish, share processes
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md
|
||
- Status: ✅ 成功摄入（re-ingest）
|
||
- Summary: Foundation AMI 全生命周期管理详解——Srihari/Alan/Praveen 主讲。基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS Benchmark 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + AWS-SSM + SiteScope 监控；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建完全自动化；通过 AMI Sharing 分发至全球多区域；每两个月更新，采用 N-2 版本保留策略。责任共担：CCOE 提供 Foundation AMI，产品团队构建产品特定 AMI。
|
||
- Concepts touched: [[Foundation-AMI]], [[OS-Hardening]], [[CIS-Benchmark]], [[HashiCorp]], [[AWS-SSM]], [[AMI-Sharing]]
|
||
- Entities touched: [[CCOE]], [[Jenkins]], [[AWS]]
|
||
- Concepts created: [[Foundation-AMI]], [[OS-Hardening]], [[AMI-Sharing]]
|
||
- Source page: wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md
|
||
- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），本次更新 wikilinks 格式（Foundation AMI→Foundation-AMI 等）并移除 Srihari/Alan/Praveen（仅出现1次）；步骤4完成：index.md 条目已存在（第306行）；步骤5完成：overview.md 已有该来源摘要（line 315），内容一致无需修订；步骤6完成：新建 CCOE.md Entity 页面；步骤7完成：新建 Foundation-AMI.md、OS-Hardening.md、AMI-Sharing.md Concept 页面；CIS-Benchmark/HashiCorp/AWS-SSM/HashiCorp（Entity）已存在，跳过；Central Repository 未创建独立页面（保留为普通概念描述）；步骤8完成：Contradictions 已在 source page 记录（与 ctp-topic-58 的"当前 Packer vs 未来 EC2 Image Builder"属技术演进非冲突）；步骤9完成：log.md 追加本次 re-ingest 记录
|
||
|
||
## [2026-05-07] ingest | CTP Topic 68 Introduction to Redshift
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS Redshift 数据仓库入门介绍——核心架构含 Leader Node（管理 Schema、元数据、查询计划）和 Compute Node（在 Slices 上通过 MPP 执行并行查询）；支持列式存储（适合 OLAP 聚合查询）和行式存储；Sort Key 和 Distribution Key 是性能优化核心；三种实例类型（Dense Compute/Dense Storage/RA3）；RA3 以 AWS 托管 NVMe 提供成本效益。
|
||
- Concepts touched: [[MassivelyParallelProcessing]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[OLAP]], [[Data-Compression]]
|
||
- Entities touched: [[Amazon-Redshift]], [[LeaderNode]], [[ComputeNode]], [[JDBC]], [[ODBC]]
|
||
- Concepts created: [[Sort-Key]], [[Distribution-Key]]
|
||
- Source page: wiki/sources/ctp-topic-68-introduction-to-redshift.md
|
||
- Notes: 步骤3完成：新建 source page（含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions）；步骤4完成：index.md 条目补全日期前缀（2026-04-14）和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 339），内容一致无需修订；步骤6完成：Amazon-Redshift Entity 页面已存在（2026-04-14 初版），内容一致无需修订；步骤7完成：新建 Sort-Key.md 和 Distribution-Key.md Concept 页面；步骤8完成：Contradictions 记录与 [[ctp-topic-66-rds-vs-aurora]] 的定位差异（Redshift 专 OLAP vs Aurora 混合 OLTP/OLAP），非冲突；步骤9完成：log.md 追加本次摄入记录
|
||
|
||
## [2026-04-28] ingest | CTP Topic 58 AWS EC2 Image Builder
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AWS EC2 Image Builder 服务详解——自动化 AMIs 和 Docker 镜像创建/管理/分发的托管服务；核心组件包括 Image Pipeline、Image Recipe、Infrastructure Configuration、Distribution Settings；YAML 定义镜像配方（Source AMI → Output AMI）；CCOE 提供 Golden AMI，产品团队可追加自定义组件（按字母序添加）；支持 CentOS 7 和 Ubuntu 18 的端到端 POC；集成 AWS Inspector 进行安全扫描，Lambda 工作流触发扫描并发送邮件通知和 S3 报告；当前 AMI 流程（GitLab + Jenkins + Packer）的痛点（交付周期长、跨 LZ 兼容性差）推动了 Image Builder 的采用。
|
||
- Concepts touched: [[AMI-Image-Builder]], [[Image-Pipeline]], [[Golden-AMI]], [[AWS-Inspector]], [[AWS-Landing-Zone]]
|
||
- Entities touched: [[AWS]], [[Packer]], [[Jenkins]], [[Terraform]], [[Qualys]]
|
||
- Source page: wiki/sources/ctp-topic-58-aws-ec2-image-builder.md
|
||
- Notes: 步骤3完成：新建 source page，含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions；步骤4完成：index.md 条目已存在（第303行），无需重复添加；步骤5完成：overview.md 由后续 query workflow 维护，此处无需主动修订；步骤6-7完成：关键 Entity/Concept 在源文档中出现1-2次，未达到创建独立页面的阈值（≥2次且关键影响），按工作流规则跳过；步骤8完成：Contradictions 记录"暂无发现冲突"；步骤9完成：log.md 追加本次摄入记录
|
||
|
||
## [2026-05-06] ingest | CTP Topic 25 Labs Landing Zone Overview - ITOM Teams (re-ingest)
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
|
||
- Status: ✅ 成功摄入（re-ingest）
|
||
- Summary: Labs LZ 基于 Gruntwork 参考架构，多账户策略（Shared/Jenkins/Logs/Security/Core(AD+DNS)/Network(TGW+JetPult)/Product Account）；全部通过 Terraform/Terragrunt IaC 管理；Jenkins 流水线扫描 GitHub 触发 plan/apply；防火墙通过标签（Tags）控制网络访问；Shared Services 含 45 Arc Site 监控和 Qualys 安全扫描。
|
||
- Entities touched: [[Gruntwork]], [[Jenkins]], [[Swimford.net]], [[JetPult]], [[Pulse-VPN]], [[Qualys]], [[Terragrunt]], [[Terraform]]
|
||
- Concepts touched: [[Landing-Zone-Architecture]], [[Terraform]], [[Terragrunt]], [[Transit-Gateway]], [[Tag-Based-Access-Control]], [[Federated-Access]]
|
||
- Source page: wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
|
||
- Notes: 步骤3完成：Source page 已有（2026-04-14 初版），内容完整无需修订；步骤4完成：index.md 条目补全日期前缀（2026-04-14）和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 291），内容一致无需修订；步骤6-7完成：Key Concepts/Entities 均以 wikilink 形式存在，相关 Entity（Gruntwork/Jenkins/Swimford.net/JetPult/Pulse-VPN/Qualys）和 Concept（Landing-Zone-Architecture/Terraform/Terragrunt/Transit-Gateway）页面已存在；步骤8完成：Contradictions 记录"无已知冲突"（JetPult vs Checkpoint 属 Labs vs SaaS 不同 LZ 的防火墙方案差异，非冲突）；步骤9完成：log.md 补录本次 re-ingest
|
||
|
||
## [2026-05-06] ingest | CTP Topic 7 SaaS Landing Zone Design
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md
|
||
- Status: ✅ 成功摄入（re-ingest）
|
||
- Summary: SAS LZ 四层账户体系设计（Core/Baseline/Shared Services/Product）；核心账户（Shared/Jenkins+Lambda、Logs、Security/IAM）、基线账户（Network/Transit Gateway+Checkpoint、DNS/Route 53、AD双节点）、共享服务账户（Software Factory 45 hubs+Octane Hub+Artifactory、Cyber/Qalis、ARC、Monitoring/OBM）、产品账户（私有子网工作负载+公有子网LB+WAF+CloudFront可选）；Terraform IaC + GitHub/Jenkins CI/CD 端到端自动化部署链路；Checkpoint VPN → Pulse VPN 远程访问迁移。
|
||
- Concepts created: [[Transit-Gateway]], [[Active-Directory-Integration]], [[WAF-Web-Application-Firewall]], [[Private-Subnet-Architecture]], [[Terraform-IaC]], [[Software-Factory]]
|
||
- Entities created: [[Jenkins]], [[Pulse-VPN]], [[TerraGrant]], [[Qalis]], [[OBM]], [[CloudFront]]
|
||
- Entities touched: [[Gruntwork]], [[Checkpoint]], [[Terraform]], [[Terragrunt]]
|
||
- Source page: wiki/sources/ctp-topic-7-saas-landing-zone-design.md
|
||
- Notes: 步骤3完成：Source page 已有（2026-04-14 初版），本次补加 tags 和 last_updated: 2026-05-06；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 307），内容一致无需修订；步骤6-7完成：新建 6 个 Entity 页面（Jenkins/Pulse-VPN/TerraGrant/Qalis/OBM/CloudFront）和 6 个 Concept 页面（Transit-Gateway/Active-Directory-Integration/WAF-Web-Application-Firewall/Private-Subnet-Architecture/Terraform-IaC/Software-Factory），并加入 index.md；步骤8完成：Contradictions 已在 source page 记录（与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 属设计演进视角互补，非冲突）；步骤9完成：log.md 补录本次摄入
|
||
|
||
## [2026-05-06] ingest | CTP Topic 34 Azure Landing Zone Architecture Overview
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Azure Landing Zone 架构概述——Micro Focus 通过 Azure Enterprise Enrollment + Azure AD 完成企业接入；管理组四区分离（platform/landing-zones/decommission/sandbox）；连接订阅集成 DDoS 防护和 Checkpoint 防火墙；Terraform Cloud 管理跨订阅依赖；PIM 强制最小权限。核心价值：团队独立部署减少跨团队依赖，AWS 侧用 Gruntwork/Jenkins，Azure 侧用 Terraform Cloud，体现 CTP 多云战略。
|
||
- Concepts touched: [[Landing-Zone-Architecture]]（已存在，内容已通过本来源扩展）
|
||
- Entities touched: [[Azure]]（已存在）, [[Micro-Focus]]（已存在）
|
||
- Source page: wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md
|
||
- Notes: 步骤3完成：新建 source page，含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities、Connections、Contradictions；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 新增 CTP Topic 34 条目，置于 Topic 35 之后；步骤6-7完成：关键 Entity/Concept 均已存在（Azure/Micro-Focus/Landing-Zone-Architecture/Terraform），无需新建；步骤8完成：Contradictions 记录了与 Gruntwork AWS LZ 的平台差异说明（非冲突，为多云战略互补）；步骤9完成：log.md 补录
|
||
|
||
## [2026-05-06] ingest | CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Landing Zone 设计复习——明确 SaaS（生产）与 Labs（开发）的核心定位：SaaS = 生产，Labs = 开发；SaaS LZ 含产品账户、核心账户（AD/DNS/Network）、共享服务账户、Gruntwork 账户；近期变更：网络分段阻断 SaaS 直连、CCOE CloudTrail 替代 Gruntworks CloudTrail、Checkpoint 重新路由入站流量、AWS Backup 强制化、新账户取消 Management VPC；PoC LZ 并入 Labs；Cloud Technology Design Forum 推动标准化。
|
||
- Concepts created: [[Network-Segmentation]]
|
||
- Entities created: [[Cloud-Technology-Design-Forum]]
|
||
- Entities touched: [[Gruntwork]], [[Checkpoint]]
|
||
- Source page: wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md
|
||
- Notes: 步骤3完成：Source page 修复所有 broken wikilinks（CCOEs-CloudTrail → CloudTrail，AWS-Landing-Zone → Landing-Zone-Architecture，删除 Shared-Services-Account 等不必要独立 Concept），补全 Contradictions 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 视角互补说明，更新 last_updated: 2026-05-06；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 301），内容一致无需修订；步骤6-7完成：新建 [[Cloud-Technology-Design-Forum]] Entity 和 [[Network-Segmentation]] Concept 并加入 index.md；步骤8完成：Contradictions 已从无记录更新为视角互补说明；步骤9完成：log.md 补录本次摄入
|
||
|
||
## [2026-05-06] ingest | CTP Topic 1 Gruntwork Landing Zone Architecture
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-1-gruntwork-landing-zone-architecture.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Gruntwork AWS Landing Zone 架构基础——参考架构（Reference Architecture）提供最佳实践起点，含核心账户 Shared/Logs/Security 和工作负载账户 Prod/Stage/Dev；Landing Zone 基于 Gruntwork 仓库由产品团队自行定义具体服务（ECS/RDS 等）；安全账户使用联邦用户通过 AD 组映射 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流；Gruntwork Terraform AWS 服务目录强调服务应具有业务上下文。
|
||
- Concepts touched: [[Reference-Architecture]]（已存在，内容完整）、[[Landing-Zone-Architecture]]（已存在，内容完整）
|
||
- Entities touched: [[Gruntwork]]（已存在，内容完整）
|
||
- Source page: wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md
|
||
- Notes: 步骤3完成：更新 last_updated: 2026-05-06；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 309），内容一致无需修订；步骤6-7完成：Entity/Concept 均已存在；步骤8完成：冲突已在 source page Contradictions 节记录（与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 视角互补）
|
||
|
||
## [2026-04-26] ingest | CTP Topic 46 NetApps on AWS (re-ingest)
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-46-netapps-on-aws.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Source page 已存在（2026-04-14 初版）。本次检测到源文件更新（Apr 26 12:35），更新 Source page tags 增加 CVO/ONTAP，新增 last_updated: 2026-04-26；index.md 条目补全日期前缀和一行摘要；overview.md 已有该来源摘要（line 335），内容一致无需修订。
|
||
- Concepts touched: [[SnapMirror]]（已存在，内容完整）
|
||
- Entities touched: [[NetApp]]（已存在，内容完整）
|
||
- Source page: wiki/sources/ctp-topic-46-netapps-on-aws.md
|
||
- Notes: 步骤3完成：Source page 更新 tags 和 last_updated；步骤4完成：index.md 条目补全日期+摘要；步骤5完成：overview.md 内容一致无需修订；步骤6-7完成：Entity/Concept 均已存在；步骤8完成：无冲突（属存储技术域，与数据库/备份技术互补）
|
||
|
||
## [2026-05-05] ingest | CTP Topic 17 Active Directory Services in Gruntwork AWS LZs
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Paul 讲解 Gruntwork AWS Landing Zones 中 AD 服务集成的核心实践——双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境，废弃旧 `infra`/`AST` 域名）；SRE 预制 AMI 内置 PowerShell/Shell 脚本，通过 Terraform `user_data` 实现 Windows/Linux 实例自动化域加入；Linux 支持 Secure Dynamic Updates 自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。
|
||
- Concepts created: [[Domain Join]], [[Secure Dynamic Updates]]
|
||
- Entities created: none（[[swinford.net]], [[intsas.local]], [[SMACKS]], [[Gruntwork]] 均已存在并已更新引用）
|
||
- Entities touched: [[Gruntwork]]
|
||
- Source page: wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md
|
||
- Notes: index.md 已有该来源条目（line 304），本次补加日期前缀和一行摘要；overview.md 已有该来源摘要（line 349），内容一致无需修订；Swinford.net.md 和 Intsas.local.md 已正确引用本来源；冲突检测：无冲突
|
||
|
||
## [2026-04-23] ingest | CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Greg Klau 主讲 PostgreSQL 在 Amazon RDS 与 Aurora 两种托管方案之间的深度技术对比。涵盖架构差异（RDS 计算+ EBS 分离 vs Aurora 6副本跨3AZ共享存储）、选型决策（小型<10TB选RDS，大型>10-20TB选Aurora）、高可用性（Aurora RTO 30秒 vs RDS 2分钟）、Aurora Global 跨区域灾备、Blue-Green Deployment（仅 Aurora MySQL 支持）、监控（CloudWatch/Grafana/Performance Insights）等。
|
||
- Concepts created: [[Aurora Global]], [[Multi-AZ]], [[Blue-Green Deployment]]
|
||
- Entities created: none（[[Amazon RDS]], [[Amazon Aurora]], [[RTO]] 均已存在并已更新引用）
|
||
- Entities touched: [[Amazon RDS]], [[Amazon Aurora]], [[RTO]]
|
||
- Source page: wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md
|
||
- Notes: index.md 已有该来源条目（line 292）；overview.md 已新增该来源摘要（line 260-261）；冲突检测：RTO 数值（Aurora 30秒/RDS 2分钟）已记录于 Contradictions 节，建议与 [[RTO vs RPO: Key Differences for Modern Disaster Recovery]] 交叉验证
|
||
|
||
## [2026-04-18] ingest | Blogwatcher Daily 技能收藏
|
||
- Source file: Skills/blogwatcher-daily收藏.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Hermes Agent 自定义技能 blogwatcher-daily，实现 31 个 RSS/YouTube 订阅频道的自动化监控与每日摘要生成。核心技术栈：RSSHub（YouTube 频道转 RSS）+ feedparser（多格式解析）+ SQLite（URL 去重）+ Cron（定时调度）+ Telegram（通知）。每天早上 6:00 自动运行，Job ID `ecdd35bb7df3`。
|
||
- Concepts created: 无（RSSHub/feedparser/SQLite去重机制/Cron定时任务均已有 Entity/Concept 页面或以内嵌 wikilink 引用存在）
|
||
- Entities created: 无（[[Hermes Agent]] 已存在，[[RSSHub]] 已存在）
|
||
- Entities touched: [[Hermes Agent]], [[RSSHub]]
|
||
- Source page: wiki/sources/blogwatcher-daily收藏.md
|
||
- Notes: index.md 已有该来源条目（line 200），本次补全一行摘要；冲突检测：无冲突
|
||
|
||
## [2026-04-17] ingest | WSL2 启动与网络配置指南
|
||
- Source file: Home Office/WSL2 启动与网络配置指南.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: WSL2（Windows Subsystem for Linux 2）日常使用操作与网络配置完整指南。涵盖安装（`wsl --install`）、状态检查（`wsl -l -v`）、版本转换（`wsl --set-version`）；网络配置核心痛点（NAT 模式导致 Windows 代理无法镜像）；推荐方案（`.wslconfig` 配置 `networkingMode=mirrored` + `dnsTunneling=true`）；备选方案（手动代理 `http_proxy/https_proxy`）；GitHub 加速（`ghproxy.com` 反向代理）；常见故障排查（WSL_E_VM_MODE_INVALID_STATE、文件权限问题）。
|
||
- Concepts created: 无（镜像网络模式/NAT模式均以内嵌 wikilink 引用存在，未达独立建页阈值）
|
||
- Entities created: [[WSL2]], [[ghproxy]]
|
||
- Entities touched: [[uv]], [[Hermes Agent]]
|
||
- Source page: wiki/sources/wsl2-启动与网络配置指南.md
|
||
- Notes: index.md Sources 节已有该来源条目，本次补加日期前缀 [2026-04-17] 和一行摘要；index.md Entities 节新增 WSL2 和 ghproxy 条目；overview.md 已有 WSL2 相关条目（line 413-415, line 787-789），内容一致无需修订；冲突检测：与 [[Install WSL]] 的视角差异（安装 vs 配置）已记录于 source page Contradictions 节，无本质冲突
|
||
|
||
## [2026-04-28] ingest | fireworks-tech-graph
|
||
- Source file: Skills/fireworks-tech-graph.md
|
||
- Status: ✅ 成功摄入（更新）
|
||
- Summary: fireworks-tech-graph 将自然语言描述转化为精美 SVG 技术图并导出高分辨率 PNG——解决技术文档/博客缺乏高质量可视化图表的核心痛点。内置 7 种视觉风格（扁平图标风/暗黑极客风/工程蓝图风/Notion极简风/玻璃态卡片风/Claude官方风格/OpenAI官方风格）和 14 种 UML 图类型。语义形状词汇表确保图形语义一致，语义箭头系统通过颜色+虚线编码含义。支持 librsvg/rsvg-convert 导出 1920px PNG。触发词：画图/帮我画/生成图/做个图/架构图/流程图/可视化一下。
|
||
- Concepts created: none（concept 页面待补充：技术图生成、7种视觉风格系统、语义形状词汇表、语义箭头系统、14种UML图）
|
||
- Entities created: none（rsvg-convert 已列出，concept 页面待补充后关联）
|
||
- Source page: wiki/sources/fireworks-tech-graph.md
|
||
- Notes: 源页面已存在（2026-04-18），本次对比 489 行源文档发现以下内容已补全：7种风格详细参数表、形状词汇表完整表格、箭头语义完整表格、AI/Agent 内建 Pattern、产品图标覆盖范围；index.md 已有条目（line 196）；overview.md 已有条目（line 508）；冲突检测：无冲突
|
||
|
||
## [2026-04-28] ingest | Obsidian 官方 CLI 命令全景速查表
|
||
- Source file: Skills/Obsidian 官方 CLI 命令全景速查表.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Obsidian v1.12+ 官方 CLI 80+ 命令全景速查表。涵盖 18 个功能模块：基础操作、数据库（Bases）、书签、命令面板、日记、文件历史、文件目录、链接网络、大纲、插件管理、属性元数据、发布、随机笔记、全局搜索、官方同步、标签、任务管理、模板、外观样式、卡片盒、仓库管理、内置浏览器、字数统计、工作区布局、开发者模式。附带 7 个典型自动化工作流：全局极速闪记、播客沉浸式知识榨取、AI 收件箱自动分拣员、绝对隐私的本地 RAG 对话助理、跨平台数据库级联录入、历史知识自动唤醒、批量元数据重构。
|
||
- Concepts created: [[Backlinks]]
|
||
- Entities created: [[Obsidian]]
|
||
- Entities touched: [[n8n]], [[OpenClaw]]
|
||
- Source page: wiki/sources/obsidian-官方-cli-命令全景速查表.md
|
||
- Notes: index.md 已添加该来源条目（一行摘要）；Backlinks 是核心概念，已创建独立概念页面；Obsidian 已创建实体页面（CLI + 核心特性描述）；n8n.md 和 OpenClaw.md 已添加本来源引用；冲突检测：无冲突；index.md 中已有同名条目已补全摘要内容
|
||
|
||
## [2026-04-28] ingest | Obsidian CLI
|
||
- Source file: Skills/Obsidian CLI.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Obsidian 官方 CLI 完整命令参考文档（1534行）——50+ 命令覆盖日常使用、文件管理、链接分析、任务管理、开发者命令（CDP协议截图/控制台/插件热重载）、数据管理（Bases）、版本历史（File Recovery+Sync）、插件管理和 Obsidian Publish。两种使用模式：单命令和 TUI 交互。vault 定向和文件定位机制详解。
|
||
- Entities touched: [[Obsidian]], [[Obsidian-Skills]]
|
||
- Entities created: none (Obsidian entity already exists via obsidian-必装-skills)
|
||
- Concepts touched: [[Obsidian-CLI]], [[Obsidian-TUI]], [[Vault-Management]], [[Developer-Commands]], [[CDP-Commands]], [[Plugin-Reload]], [[Daily-Notes-CLI]], [[File-Recovery]], [[Base-Commands]], [[Property-Commands]], [[Task-Commands]], [[Template-Commands]], [[Sync-Commands]], [[Plugin-Management-CLI]], [[Publish-Commands]]
|
||
- Source page: wiki/sources/obsidian-cli.md
|
||
- Notes: 原 source page 已存在但内容简略（58行），本次用完整 1534 行源文档重建 source page，严格按 Source Page Format 补充了完整命令分类速查表和 Key Claims；overview.md 已添加详细 obsidian-cli 条目；冲突检测：与 obsidian-必装-skills 的视角差异（官方内置 vs Skills 收录）已在 Contradictions 节协调，两种描述均正确
|
||
|
||
## [2026-04-28] ingest | Obsidian 必装 Skills
|
||
- Source file: Skills/Obsidian 必装 Skills
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Obsidian 生态 AI Skills 全景盘点——推荐安装 kepano 官方 defuddle（网页清洗）、obsidian-cli（官方 CLI 操作）、obsidian-bases（数据库视图）；Axton 的 obsidian-canvas-creator（径向布局算法）；tutor-skills（"输入-内化-检测"三阶段学习闭环）；scholar-skill（基于 OpenClaw 的 L1/L2/L3 分级论文阅读）。核心插件：claudian（适配 Claude Code）和 obsidian-agent-client（适配多主流 Agent）。含 BRAT 安装和配置指南。
|
||
- Concepts created: [[tutor-skills]], [[scholar-skill]]
|
||
- Entities created: [[kepano]]
|
||
- Entities touched: [[OpenClaw]], [[BRAT]], [[defuddle]], [[obsidian-cli]], [[obsidian-bases]], [[obsidian-canvas-creator]], [[claudian]], [[obsidian-agent-client]]
|
||
- Source page: wiki/sources/obsidian-必装-skills.md
|
||
- Notes: overview.md 已添加该来源摘要（Second Brain 部分）；index.md 已添加该来源条目和 Concepts 条目；冲突检测：与养虾日记3的 obsidian-skill 方案存在张力（obsidian-cli vs 文件系统直写）；kepano 已存在于 index.md，本次补充完整发布的 Skills 信息
|
||
|
||
## [2026-04-28] ingest | 在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B
|
||
- Source file: AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Ubuntu 本地部署 Qwen2.5-Coder 7B 代码大模型完整指南。涵盖系统要求（8+ cores CPU、16GB RAM、4.5GB 模型）、Ollama 安装（`curl install.sh | sh`）、systemd 服务管理、模型下载运行（3 条命令最简流程）、REST API 调用（http://localhost:11434）、Python/NodeJS SDK、远程 API 开放（OLLAMA_HOST=0.0.0.0）、GPU 加速、模型管理（list/rm/pull）。推荐搭配工具链：Open WebUI、n8n、LangChain、OpenClaw。核心价值：qwen2.5-coder:7b 在 Tool usage、Shell/Python/SQL 理解和 Repo 级代码理解方面优于普通 qwen2.5:7b，更适合 DevOps automation、SQL Agent、Kubernetes troubleshooting 等工程任务。
|
||
- Entities created: [[Ollama]], [[Qwen2.5-Coder]]
|
||
- Entities touched: [[Open WebUI]], [[n8n]], [[LangChain]], [[OpenClaw]]
|
||
- Source page: wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md
|
||
- Notes: overview.md 已添加该来源摘要（条目23）；index.md 已添加该来源条目和 Entities 条目；冲突检测：无冲突；Open WebUI/n8n/LangChain/OpenClaw 出现次数 < 2，暂不创建独立 Entity 页面
|
||
|
||
## [2026-04-28] ingest | I Went Through Every AI Memory Tool I Could Find. There Are Two Camps.
|
||
- Source file: Agent/AI-Memory-Tools-Two-Camps.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AI 记忆工具全景分类框架（@witcheer，2026-04-15）。GitHub 450+ repos "agent-memory"、460+ "context-management"，系统梳理后划分为两大阵营：Camp 1（Memory Backend，提取事实+向量检索，优化召回）vs Camp 2（Context Substrate，维护结构化人类可读文件，跨会话累积，优化复合增长）。Camp 1 代表：Mem0、MemPalace、Supermemory、Honcho；Camp 2 代表：OpenClaw、Zep、Thoth、TrustGraph、MemSearch、ALIVE。核心洞察：Zep 从"Memory"重品牌化为"Context Engineering"是最强市场信号；预测 6 个月内"Context Engineering"将取代"Memory"成为主流术语；24/7 持续运行 Agent 必须采用 Context Substrate 架构。
|
||
- Concepts created: [[Memory-Backend]], [[Context-Substrate]], [[Context-Engineering]], [[Dream-Cycle]], [[Context-Cores]], [[Fact-Recall-vs-Compounding]]
|
||
- Entities created: [[Mem0]], [[MemPalace]], [[Supermemory]], [[Honcho]], [[Zep]], [[Thoth]], [[TrustGraph]], [[MemSearch]], [[ALIVE]], [[@witcheer]]
|
||
- Entities touched: [[OpenClaw]]（已存在，新增链接）
|
||
- Source page: wiki/sources/ai-memory-tools-two-camps.md
|
||
- Notes: overview.md 已有详细摘要（lines 623-626），无需修订；index.md 已有该 source 条目（line 530）；冲突检测：无实质性冲突，仅 wikilink 引用一致；Context-Substrate.md 在此前由其他来源创建，本次补充了完整工具列表和对比表
|
||
|
||
## [2026-04-28] ingest | Learn AI for free directly from top companies
|
||
- Source file: AI/Learn AI for free directly from top companies.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: @RodmanAi 整理的顶级AI公司免费学习平台导航——涵盖 Anthropic、Google、Meta、NVIDIA、Microsoft、OpenAI、IBM、AWS、DeepLearning.AI、Hugging Face 共10家头部组织的官方免费课程资源。
|
||
- Concepts touched: [[AI免费学习]]（概念引用，概念页面待后续来源积累后创建）
|
||
- Entities touched: [[Anthropic]], [[Google]], [[Meta]], [[NVIDIA]], [[Microsoft]], [[OpenAI]], [[IBM]], [[AWS]], [[DeepLearning.AI]], [[Hugging Face]]
|
||
- Source page: wiki/sources/learn-ai-for-free-directly-from-top-companies.md
|
||
- Notes: overview.md 已添加该来源摘要；index.md 已添加该来源条目；冲突检测：无冲突；Entity 页面暂未创建（各公司实体信息分散在多个来源中，待后续聚合）
|
||
|
||
## [2026-04-28] ingest | 可自动化、可扩展、AI增强的电商数据采集与处理系统
|
||
- Source file: Others/可自动化、可扩展、AI增强的电商数据采集与处理系统.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 基于 Docker + Ubuntu + n8n 的电商数据采集与处理系统完整指南。三层架构：采集层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。核心价值：Scrapy + Playwright 组合抓取动态页面，n8n 自动化工作流编排，Ollama 本地 LLM 替代外部 API，防封策略（UA轮换/代理池/延迟随机化）。
|
||
- Concepts created: [[网页爬虫]], [[自动化工作流引擎]], [[防封技术]], [[Docker容器化]], [[LLM API集成]], [[向量数据库]]
|
||
- Entities created: [[Scrapy]], [[Playwright]], [[Ollama]], [[MinIO]], [[Grafana]]
|
||
- Entities touched: [[n8n]]（已更新来源链接）
|
||
- Source page: wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md
|
||
- Notes: source page 新建完成；index.md Entities 节已添加 Scrapy；overview.md 已有对应条目（电商数据采集与处理系统节），无需修订；冲突检测：与 [[Scrapy + Playwright 抓取TikTok Shop Data]] 属技术实现互补关系，无冲突
|
||
|
||
## [2026-04-28] ingest | 电商如何选品 - 如何找到爆款选品策略
|
||
- Source file: 跨境电商/电商如何选品 如何找到爆款 选品策略.md
|
||
- Status: ✅ 成功摄入
|
||
|
||
## [2026-05-15] ingest | Design Whimsy Injector
|
||
- Source file: Agent/agency-agents/design/design-whimsy-injector.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Whimsy Injector Agent 角色定义——品牌个性和愉悦感注入专家，隶属于 The Agency Design 部门。核心能力：战略人格注入、包容性愉悦设计、微交互设计系统（含 CSS 动画规范）、游戏化成就系统（含彩蛋发现）。Source page 已在 2026-05-05 生成，本次完成 Entity/Concept 页面创建和 index.md 补充。
|
||
- Source page: wiki/sources/design-whimsy-injector.md（已存在，格式完整）
|
||
- Entities created: Whimsy-Injector.md、ArchitectUX.md、LuxuryDeveloper.md
|
||
- Entities updated: The-Agency.md（追加 sources 引用）
|
||
- Concepts created: Micro-Interaction-Design.md、Inclusive-Delight-Design.md、Gamification-System.md
|
||
- Concepts updated: Gamification.md（追加 sources 引用）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 已存在（2026-05-05），格式完整无需修订；步骤4完成：index.md 第512行更新日期前缀和中文摘要；步骤5完成：overview.md 无需修订（source page 已包含完整摘要）；步骤6完成：新建 Whimsy-Injector.md/ArchitectUX.md/LuxuryDeveloper.md Entity 页面，更新 The-Agency.md sources 引用；步骤7完成：新建 Micro-Interaction-Design.md/Inclusive-Delight-Design.md/Gamification-System.md Concept 页面，更新 Gamification.md sources 引用；更新 index.md Entities 节（ArchitectUX/LuxuryDeveloper/Whimsy-Injector）和 Concepts 节（Inclusive-Delight-Design/Gamification-System/Micro-Interaction-Design）；步骤8完成：无冲突（与 ArchitectUX 的互补关系已在 Contradictions 节记录）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-15] ingest | UX Researcher Agent Personality
|
||
- Source file: Agent/agency-agents/design/design-ux-researcher.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Design 部门 UX Researcher Agent 的角色定义与研究方法论——核心职责：通过混合研究方法（定性与定量）理解用户行为、验证设计决策、提供可落地洞察；与 UX Architect 和 Whimsy Injector 共同构成 Design 部门三支柱（Research → Architecture → Delight）；默认要求包含无障碍研究和包容性设计测试
|
||
- Source page: wiki/sources/design-ux-researcher.md（新建）
|
||
- Entities updated: UX-Researcher.md（追加 design-ux-researcher.md 到 sources，更新 definition 和 Key Collaborators）、ArchitectUX.md（追加 sources 引用，更新 Relationship to Other Agents）
|
||
- Concepts created: User-Research-Methodology.md、Usability-Testing.md、User-Persona.md、User-Journey-Mapping.md、Qualitative-Quantitative-Research.md、Research-Triangulation.md、Inclusive-Design-Research.md、Behavioral-Analytics.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第9行添加新条目（UX Researcher）；步骤5完成：overview.md 在 design-ux-architect 段落后新增 UX Researcher 综合摘要（Design 三支柱定位）；步骤6完成：UX-Researcher Entity 页面已存在，更新 definition/Key Collaborators/sources；ArchitectUX Entity 页面已存在，更新 sources 引用和 Relationship；步骤7完成：新建8个 Concept 页面（User-Research-Methodology/Usability-Testing/User-Persona/User-Journey-Mapping/Qualitative-Quantitative-Research/Research-Triangulation/Inclusive-Design-Research/Behavioral-Analytics），按字母顺序加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 UX Architect 的张力（研究洞察 vs 技术约束，通过时序分工协调）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Paid Media Programmatic & Display Buyer Agent
|
||
- Source file: Agent/agency-agents/paid-media/paid-media-programmatic-buyer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 战略性程序化购买与展示广告 Agent——覆盖 Google Display Network、DV360、The Trade Desk、Amazon DSP 等 DSP 平台；Demandbase、6Sense、RollWorks 等 ABM 平台；支持 Deal ID、PMP、程序化保证交易；通过 MCP 工具与 Google Ads API 集成实现自动化投放管理；管理 25+ 合作伙伴媒体（AMP）；核心理念：受众优先，每次展示触达正确用户在正确上下文以正确频次；成功衡量以可见性（≥70% MRC）、品牌安全和上漏斗归因为主
|
||
- Source page: wiki/sources/paid-media-programmatic-buyer.md（更新，日期更新为 2026-04-26，新增 CTV/OTT Advertising 概念，更新 paid-media-ppc-strategist 协调关系）
|
||
- Concepts created: Programmatic-Buying.md、ABM-Display.md、Viewability.md、Frequency-Cap.md、CTV-OTT-Advertising.md
|
||
- Entities updated: 无（DV360/The Trade Desk/Amazon DSP/Google Display Network/Demandbase/6Sense/RollWorks 等引用未达≥2次阈值）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（已有条目）和 overview.md（第184行已有摘要）；步骤3完成：更新 source page（新增 CTV/OTT Advertising 概念，更新 paid-media-ppc-strategist 协调方式，更新 date 为 2026-04-26）；步骤4完成：index.md 第415行已有条目，无需更新；步骤5完成：overview.md 第184行摘要已准确，无需修订；步骤6完成：Entity 未创建（相关平台实体引用未达≥2次阈值）；步骤7完成：新建5个 Concept 页面（Programmatic-Buying/ABM-Display/Viewability/Frequency-Cap/CTV-OTT-Advertising），按字母顺序加入 index.md Concepts 节；步骤8完成：检测无新冲突（与 paid-media-paid-social-strategist 效果衡量差异、paid-media-ppc-strategist 目标设定差异均已在 source page 记录）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-01] ingest | Paid Media PPC Campaign Strategist Agent
|
||
- Source file: Agent/agency-agents/paid-media/paid-media-ppc-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Paid Media 部门企业级 PPC 战略 Agent——核心：$10K 到 $10M+ 月预算规模的 Google Ads/Microsoft Advertising/Amazon Ads 付费搜索架构；核心理念「账户架构即战略」（Account Structure as Strategy）；核心能力：分层广告系列架构（Brand/Non-Brand/Competitor/Conquest 四层隔离）、自动化竞价（tCPA/tROAS/Max Conversions）、Performance Max 资产组设计、Google Ads API/MCP 实时数据驱动；作者：John Williams（@itallstartedwithaidea）
|
||
- Source page: wiki/sources/paid-media-ppc-strategist.md（更新）
|
||
- Concepts created: AccountArchitecture.md、AutomatedBiddingStrategy.md、BudgetPacing.md、PerformanceMax.md、AudienceStrategy.md、TieredCampaignArchitecture.md、CrossPlatformPlanning.md；Incrementality-Testing.md（追加来源）
|
||
- Entities created: CustomerMatch.md、GoogleAdsAPI.md、MCCLevelStrategy.md；GoogleAds.md/MicrosoftAdvertising.md/AmazonAds.md（覆盖并扩充）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（含现有 Sources/Concepts/Entities 索引）和 overview.md（第182行已有该来源详细摘要）；步骤3完成：更新 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第416行更新日期为 2026-05-01；步骤5完成：overview.md 第182行已有摘要，无需修订；步骤6完成：新建6个 Entity 页面（GoogleAds/MicrosoftAdvertising/AmazonAds/CustomerMatch/GoogleAdsAPI/MCCLevelStrategy），GoogleAds/AmazonAds/MicrosoftAdvertising 已存在于 index（保留现有路径），新增条目均已加入 index.md Entities 节；步骤7完成：新建8个 Concept 页面（AccountArchitecture/AutomatedBiddingStrategy/BudgetPacing/PerformanceMax/AudienceStrategy/TieredCampaignArchitecture/IncrementalityTesting/CrossPlatformPlanning），其中 AccountArchitecture/PerformanceMax/TieredCampaignArchitecture 已存在于 index（覆盖扩充），Incrementality-Testing（连字符版）追加来源；新增条目均已加入 index.md Concepts 节；步骤8完成：检测与 MarketingSEOSpecialist 的潜在冲突（SEO vs PPC 预算竞争），已记录协调建议；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-17] ingest | Paid Media Ad Creative Strategist Agent
|
||
- Source file: Agent/agency-agents/paid-media/paid-media-creative-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 付费媒体广告创意策略 Agent——将广告创意从"凭感觉"转变为"可重复的科学"；核心理念：创意是自动化竞价环境中广告主唯一真正可控的变量；15-headline RSA 架构设计、Meta Hook-Body-CTA 视频框架、Performance Max 资产组编排、创意疲劳监测（A/B 测试 + 统计显著性）；成功指标：90%+ Ad Strength、15-25% CTR 提升、每两周新测试节奏；作者：John Williams（@itallstartedwithaidea）
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
|
||
- Source page: wiki/sources/paid-media-creative-strategist.md（新建）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（第403行已有该条目）和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第403行已有该条目，日期已存在，无需更新；步骤5完成：overview.md 无需修订（Sales 相关内容已在相关页面覆盖）；步骤6完成：Entity 未创建（Key Entities 均以 wikilinks 记录于 source page）；步骤7完成：新建4个 Concept 页面（Win-Theme.md / Three-Act-Proposal-Narrative.md / Executive-Summary-Formula.md / Content-Operations.md），均已加入 index.md Concepts 节；步骤8完成：检测与 support-executive-summary-generator 的 SCQA 框架张力（前者通用战略沟通，后者销售提案专用），已记录为层级互补非冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-19] ingest | Sales Proposal Strategist Agent
|
||
- Source file: Agent/agency-agents/sales/sales-proposal-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 销售提案撰写策略专家 Agent，将 RFP 响应转化为"赢叙事"（Win Narrative）。核心理念：提案是说服工具而非合规清单，叙事是最强差异化因素。三幕式提案叙事结构（Act I 理解挑战 → Act II 方案旅程 → Act III 转化状态）、3-5 个赢主题矩阵（Win Theme Matrix）、执行摘要五步结构、竞争定位技巧、内容运营体系。
|
||
- Concepts created: Win-Theme.md、Three-Act-Proposal-Narrative.md、Executive-Summary-Formula.md、Content-Operations.md
|
||
- Source page: wiki/sources/sales-proposal-strategist.md（新建）
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（第403行已有该条目）和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第403行已有该条目，日期已存在，无需更新；步骤5完成：overview.md 无需修订（Sales 相关内容已在相关页面覆盖）；步骤6完成：Entity 未创建（Key Entities 均以 wikilinks 记录于 source page）；步骤7完成：新建4个 Concept 页面（Win-Theme.md / Three-Act-Proposal-Narrative.md / Executive-Summary-Formula.md / Content-Operations.md），均已加入 index.md Concepts 节；步骤8完成：检测与 support-executive-summary-generator 的 SCQA 框架张力（前者通用战略沟通，后者销售提案专用），已记录为层级互补非冲突；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Jira Workflow Steward Agent Personality
|
||
- Source file: Agent/agency-agents/project-management/project-management-jira-workflow-steward.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Jira Workflow Steward Agent 完整摄取——The Agency 项目管理部门的交付纪律守护者 Agent，专注于 Jira-Git 全链路可追溯性管理。核心方法：Jira Gate（强制 Jira ID 前置）→ 分支策略（feature/bugfix/hotfix/release 分流）→ Gitmoji 规范提交 → PR 模板 → Commit Hook 自动化验证。关键交付物：分支/提交决策矩阵（8种变更类型）、Commit Validation Hook 脚本、PR 模板、Delivery Planning 模板。成功指标：100% 分支映射 Jira 任务、提交合规率 ≥ 98%、从 Jira+Git 历史重建发布说明 < 10 分钟。与 [[Project-Management-Project-Shepherd]] 互补（任务创建→任务追踪），与 [[Project-Management-Studio-Operations]] 协同（运营流程→技术交付链路），与 [[ProjectManagerSenior]] 协同（任务列表→可追溯交付）。
|
||
- Concepts created: （所有 Concept 均已存在于 wiki：Jira-Git-Traceability/Atomic-Commit/Branch-Strategy/Gitmoji-Commit/Jira-Gate/Pull-Request-Governance/Delivery-Traceability）
|
||
- Source page: wiki/sources/project-management-jira-workflow-steward.md
|
||
- Notes: 步骤1完成：读取原始文档（230行）；步骤2完成：读取 index.md、overview.md；步骤3完成：source page 已存在（wiki/sources/project-management-jira-workflow-steward.md，含完整 frontmatter/Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions 八节）；步骤4完成：index.md 第413行已有条目（[Jira Workflow Steward Agent Personality](sources/project-management-jira-workflow-steward.md)）；步骤5完成：overview.md 第148-149行已有 Project-Management-Jira-Workflow-Steward 综合摘要，与 source page 内容一致无需修订；步骤6完成：Entity 页面已存在（wiki/entities/Jira-Workflow-Steward.md），Gitmoji/Jira 实体已有独立页面；步骤7完成：7个 Concept 页面均已存在（wiki/concepts/ 目录下：Jira-Git-Traceability.md/Atomic-Commit.md/Jira-Gate.md/Gitmoji-Commit.md）；步骤8完成：Contradictions 已记录于 source page 第53-63行（与 Project-Management-Project-Shepherd 的 Jira ID 前置机制张力、与 Project-Management-Studio-Producer 的交付粒度层级差异）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-06-08] ingest | Senior Project Manager Agent Personality
|
||
- Source file: Agent/agency-agents/project-management/project-manager-senior.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Senior Project Manager Agent 完整摄取——The Agency 项目管理部门的规格驱动型任务规划专家 Agent。核心工作流：读取 `ai/memory-bank/site-setup.md` → 引用精确需求原文 → 拆解为 30-60 分钟原子任务 → 每个任务附带验收标准。关键原则：严格按规格执行不添加奢华功能（除非规格明确）、任务粒度控制在可执行单元、预留 2-3 轮迭代周期、禁止后台进程（`&`）和服务器启动命令。技术栈：Laravel/Livewire + FluxUI + Playwright QA。持久记忆能力：从每个项目学习并积累经验教训。与 [[ProjectManagerSenior]]（执行层任务分解）、[[project-management-studio-producer]]（战略组合管理）、[[project-management-project-shepherd]]（项目全程跟踪）共同构成项目管理层 Agent 矩阵。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：TaskListCreation/RealisticScopeManagement/PersistentMemory/AcceptanceCriteria/FluxUIComponentIntegration）
|
||
- Source page: wiki/sources/project-manager-senior.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：生成 source page；步骤4完成：index.md 追加 Source 条目；步骤5完成：overview.md 新增第24条综合摘要（Project Management Agent 矩阵协调）；步骤6完成：Entity 未达到独立建页阈值（Laravel/Livewire/FluxUI/Playwright 均仅在本文档中出现一次）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：与现有 Wiki 中 scope-creep 相关内容立场一致，无实质冲突；步骤9完成：log.md 追加记录
|
||
|
||
- Source file: Agent/agency-agents/sales/sales-pipeline-analyst.md
|
||
- Status: ✅ 成功摄入（更新）
|
||
- Summary: Pipeline Analyst Agent 文档更新——补充 Contradictions 节（与 sales-deal-strategist 和 sales-coach 的 MEDDPICC 应用视角张力与协调方案）、新增 Key Quotes（精确诊断示例）、扩充 Key Claims（预测准确性指标、销售辅导效果数据）、新增 Key Concepts（ForecastAccuracy/LeadIndicator/SalesCycleLength）、丰富 Key Entities（补充 SalesCoach 角色描述）、补充 Connections 细节说明。Source page date 更新至 2026-05-18。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：PipelineVelocity/MEDDPICC/DealHealthScoring/QualityAdjustedCoverage/RevenueOperations/ForecastAccuracy/LeadIndicator/SalesCycleLength）
|
||
- Source page: wiki/sources/sales-pipeline-analyst.md（更新：date 2026-05-18，补充 Contradictions 节、扩充 Key Claims/Key Quotes/Key Concepts/Key Entities/Connections）
|
||
|
||
## [2026-05-29] ingest | Identity Graph Operator（更新）
|
||
- Source file: Agent/agency-agents/specialized/identity-graph-operator.md
|
||
- Status: ✅ 成功摄入（更新）
|
||
- Summary: Identity Graph Operator 更新摄取——raw 文件更新于 2026-04-26（source page date 2026-04-24）。本次更新：Summary 节扩充"跨编排框架身份联邦"和"共享记忆"维度；Key Quotes 新增第四句（何时需要 Identity Graph Operator）；Key Concepts 扩充 Multi-Agent Identity Coordination 说明；其他节内容与原版一致。Source page date 更新至 2026-04-26。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：Identity Resolution/Blocking/Fuzzy Matching/Confidence Score/Optimistic Locking/Evidence-based Merge Proposal/Multi-Agent Identity Coordination）
|
||
- Source page: wiki/sources/identity-graph-operator.md（更新：date 2026-04-26，扩充 Summary/Key Quotes/Key Concepts）
|
||
- Notes: 步骤1完成：读取原始文档（raw/ 2026-04-26 更新版）；步骤2完成：读取 index.md（条目已存在 Line 400，原日期 2026-04-24）和 overview.md；步骤3完成：生成 source page 更新版（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 日期补全（2026-04-24→2026-04-26）；步骤5完成：overview.md 无需修订（已有相关摘要）；步骤6-7完成：Entity（BackendArchitect/AgentsOrchestrator/RealityChecker/SupportResponder/AgenticIdentityTrustArchitect 等）和 Concept（IdentityResolution/Blocking/FuzzyMatching 等）均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：无新跨页面冲突；步骤9完成：log.md 追加记录
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md（overview.md 第915行已有完整 sales-pipeline-analyst 综合摘要）；步骤3完成：更新 source page（日期更新+内容扩充：Key Claims扩充3条/Key Quotes扩充1条/Key Concepts扩充3个/Key Entities扩充SalesCoach描述/Connections补充细节/新增Contradictions节）；步骤4完成：index.md 第407行补全日期（2026-05-18）和一行摘要；步骤5完成：overview.md 第915行已有完整综合摘要，内容一致无需修订；步骤6完成：Entity 未创建独立页面（Key Entities 均以 wikilinks 记录于 source page）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并记录两个 Contradictions（与 sales-deal-strategist 的 MEDDPICC 诊断vs战略张力，与 sales-coach 的 Deal评估vs代表能力评估张力）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | Healthcare Marketing Compliance Specialist
|
||
- Source file: Agent/agency-agents/specialized/healthcare-marketing-compliance.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Healthcare Marketing Compliance Specialist 完整摄取——The Agency Specialized 部门的医疗营销合规专家，覆盖中国医疗健康全品类（药品/医疗器械/医美/保健食品/互联网医疗）营销合规。核心能力：医疗广告审查、处方药/OTC药广告分规管理、医疗器械三类分级合规、医美"容貌焦虑"红线防控、保健品"蓝帽子"标识管理、互联网诊疗合规、患者隐私 PIPL 合规、学术推广合规。关键原则：合规不是"堵营销"，而是"保护品牌"；"事前审查"优于"事后补救"。成功指标：年度零监管处罚、平台违规 < 3次/年、100% 内容发布前合规审查覆盖率。
|
||
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：医疗广告审查证明/处方药广告禁令/保健食品功能声称范围/医疗器械分类管理/互联网诊疗红线/患者隐私敏感信息/医美广告容貌焦虑禁令/学术推广合规）
|
||
- Source page: wiki/sources/healthcare-marketing-compliance.md
|
||
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（条目已存在 Line 405，缺少日期）和 overview.md（Line 929 已有完整综合摘要）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Line 405 补全日期格式和一行摘要；步骤5完成：overview.md Line 929 已有完整综合摘要，无需修订；步骤6完成：Entity 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并记录与 [[Marketing-Content-Creator]] 的内容创作灵活性张力，记录于 Contradictions 节；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-29] ingest | MCP Builder Agent（重新验证）
|
||
- Source file: Agent/agency-agents/specialized/specialized-mcp-builder.md
|
||
- Status: ✅ 成功摄入（验证通过）
|
||
- Summary: MCP Builder Agent 重新验证——AI Agent 的 MCP（Model Context Protocol）服务器开发专家。核心方法：工具命名原则（verb_noun）、类型化参数验证（Zod/Pydantic）、结构化错误返回（isError: true）、无状态设计、真实 Agent 测试循环。高级能力：多传输支持（Stdio/SSE/Streamable HTTP）、认证安全模式、动态工具注册、OpenAPI-to-MCP 自动生成、可组合服务器架构。与 [[lsp-index-engineer]] 存在确定性 vs 优雅降级张力，已在 Contradictions 节记录。
|
||
- Concepts: 无需创建独立页面（Model Context Protocol/MCP Server/Tool Interface Design 等 Key Concepts 均已在之前摄入时处理，当前以 wikilinks 形式记录于 source page）
|
||
- Entities: 无需创建独立页面（@modelcontextprotocol/sdk/FastMCP 等 Entity 均已在之前摄入时处理）
|
||
- Source page: wiki/sources/specialized-mcp-builder.md（已存在，本次验证并补充：last_updated 日期、Advanced Capabilities 相关内容（Dynamic Tool Registration/OpenAPI-to-MCP/Composable Server Architecture）、与 lsp-index-engineer 的 Contradiction）
|
||
- Notes: 步骤1完成：读取原始文档（247行）；步骤2完成：读取 index.md（条目已存在于 Line 391）、overview.md（1139行）；步骤3完成：source page 已存在且格式完整，本次验证并补充 Advanced Capabilities 相关 Key Claims/Key Concepts/Contradictions；步骤4完成：index.md 条目已存在（Line 391），无需修改；步骤5完成：overview.md 无需修订（MCP Builder 属 Specialized Agent 个性定义文档）；步骤6-7完成：Entity 和 Concept 均已在之前摄入时处理完毕，本次无需新建；步骤8完成：补充与 lsp-index-engineer 的确定性 vs 优雅降级张力至 Contradictions 节；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-30] ingest | Korean Business Navigator
|
||
- Source file: Agent/agency-agents/specialized/specialized-korean-business-navigator.md
|
||
- Status: ✅ 成功摄入（补充 Entity + Concept 建页）
|
||
- Summary: Korean Business Navigator 增量补充分享——原 source page 2026-04-25 已存在（index.md Line 396、overview.md Line 949 已有完整综合摘要），本次补充分享 7 个 Entity 页面（Chaebol/SME/도장 新建，KakaoTalk/품의 已存在更新 sources 字段）和 6 个 Concept 页面（Nunchi/Proof-Project-Strategy/회식/Relationship-Lifecycle/Korean-Corporate-Hierarchy 新建，기타 已存在更新 sources 字段）。Source page 已有内容：frontmatter、Summary（含核心主题/问题域/方法/结论）、Key Claims×8条、Key Quotes×4条、Key Concepts×7个（含品의/Nunchi/KakaoTalk商务礼仪/회식/Proof Project/Korean Corporate Hierarchy/Relationship Lifecycle）、Key Entities×4个（Chaebol/SME/KakaoTalk/도장）、Connections×6条、Contradictions×2条（vs 西方"快速成交"直觉、vs 西方"沉默=拒绝"直觉）。
|
||
- Entities created: [[Chaebol]]（韩国财阀大企业集团，品의 12-16 周，7-10 级审批链，Samsung/LG/SK/Lotte 代表）、[[SME]]（中小企业，品의 6-10 周，2-3 级审批链，外国顾问最易进入的市场）、[[도장]]（韩国印章，法律凭证，合同执行的物理确认，品의最后一步）
|
||
- Entities updated: [[KakaoTalk]]（追加 sources: specialized-korean-business-navigator）、[[품의]]（追加 sources: specialized-korean-business-navigator）
|
||
- Concepts created: [[Nunchi]]（눈치读心术——通过观察语境/情绪/行为线索理解未直接表达的意图，含完整 Nunchi 解码表）、[[Proof-Project-Strategy]]（信任未建立时用有边界小项目证明，2-3 周/固定交付物/固定价格，刻意超额交付120%）、[[회식]]（公司聚餐饮酒文化，出席是预期而非可选，含完整礼仪规范和购买信号分析）、[[Relationship-Lifecycle]]（소개→신뢰→계약三阶段关系管理，含季节性维护日历）、[[Korean-Corporate-Hierarchy]]（韩国企业职级体系，会长→代理十级，含决策权力映射和越级禁忌）
|
||
- Concepts updated: [[품의]]（追加 sources: specialized-korean-business-navigator）
|
||
- Source page: wiki/sources/specialized-korean-business-navigator.md（已存在，无需更新）
|
||
- Notes: 步骤1完成：读取原始文档（216行）；步骤2完成：读取 index.md（条目已存在于 Line 396）、overview.md（Line 949 已有完整综合摘要，无需修订）；步骤3完成：source page 已存在且格式完整，本次无需更新；步骤4完成：index.md Line 396 已有条目，无需修改；步骤5完成：overview.md Line 949 已有完整综合摘要，无需修订；步骤6-7完成：新建 3 个 Entity（Chaebol/SME/도장）和 5 个 Concept（Nunchi/Proof-Project-Strategy/회식/Relationship-Lifecycle/Korean-Corporate-Hierarchy），更新 2 个已有 Entity/Concept 的 sources 字段，index.md Entities 和 Concepts 节同步更新；步骤8完成：无跨页面内容冲突（기타.md 和 KakaoTalk.md 已存在，本次补充来源引用）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-30] ingest | Data Consolidation Agent
|
||
- Source file: Agent/agency-agents/specialized/data-consolidation-agent.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Data Consolidation Agent 完整摄取——The Agency Specialized 部门的销售数据聚合与实时仪表盘专家 Agent。核心职责：将分散的销售数据（Excel/数据库）聚合为实时仪表盘，支持地域、代表、管道多维度视图。核心方法：并行查询所有数据维度 → 聚合计算派生指标（revenue/quota达成率） → 结构化为 Dashboard-friendly JSON → 含生成时间戳。核心交付物：地域绩效汇总（YTD/MTD）、个人代表绩效排名、管道快照（Stage/Count/Value/加权值）、6个月趋势数据、Top 5绩效代表、地域详细报告。成功指标：< 1秒加载、60秒自动刷新、零数据不一致。Source page 含 6 条 Key Claims、3 条 Key Quotes、6 个 Key Concepts、2 个 Key Entities、4 条 Connections。
|
||
- Entities: Data-Consolidation-Agent（本体，首次出现，暂不创建独立页面）、Sales-Data-Extraction-Agent（已存在，上游数据源）
|
||
- Concepts: Territory-Performance/Quota-Attainment/Pipeline-Metrics/MTD-YTD/Dashboard-Friendly-JSON/Trend-Analysis（均以 wikilinks 形式记录于 source page，未达到独立建页阈值）
|
||
- Source page: wiki/sources/data-consolidation-agent.md
|
||
- Notes: 步骤1完成：读取原始文档（60行）；步骤2完成：读取 index.md（条目已存在于 Line 411，source page 不存在需新建）、overview.md（无独立综合段落，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×6条、Key Quotes×3条、Key Concepts×6个、Key Entities×2个、Connections×4条、Contradictions）；步骤4完成：index.md Line 411 已有条目，无需修改；步骤5完成：overview.md 无独立综合段落，无需修订；步骤6-7完成：Data-Consolidation-Agent 首次出现暂不创建独立 Entity 页面，Key Concepts 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：无跨页面内容冲突，与 Sales-Data-Extraction-Agent 为上下游关系（非竞争）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-01] ingest | Developer Advocate
|
||
- Source file: Agent/agency-agents/specialized/specialized-developer-advocate.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Developer Advocate 完整摄取——The Agency Specialized 部门的开发者体验与社区运营专家智能体，核心定位"产品团队与开发者社区之间的桥梁"，通过 DX 工程审计、技术内容创作、社区运营、产品反馈闭环四步工作流驱动平台采用。Source page 含 5 条 Key Claims（含 DX-first 原则、Authentic 伦理约束、量化成功指标）、4 条 Key Quotes、5 个 Key Concepts（DX Engineering/Technical Content Creation/Community Building/Product Feedback Loop/Advocacy Ethics）、2 个 Key Entities（The Agency/Developer Community）、3 条 Connections、1 条 Contradiction。
|
||
- Entities created: 无（The Agency/Developer Community 已在其他 Source 页覆盖）
|
||
- Entities already existed: The Agency、Developer Community
|
||
- Concepts created: 无（5个 Key Concepts 均以 wikilinks 形式记录于 source page，未达到独立建页阈值）
|
||
- Concepts already existed: 无
|
||
- Source page: wiki/sources/specialized-developer-advocate.md
|
||
- Notes: 步骤1完成：读取原始文档（317行）；步骤2完成：读取 index.md（source page 不存在，overview.md Line 959 已有综合摘要条目）、overview.md 确认已存在，无需修订；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×5、Key Quotes×4、Key Concepts×5、Key Entities×2、Connections×3、Contradictions×1）；步骤4完成：index.md Line 20 新增 specialized-developer-advocate 条目；步骤5完成：overview.md Line 959 已存在 Developer Advocate 综合摘要，无需修订；步骤6-7完成：Key Entities 和 Key Concepts 均已在其他 Source 页覆盖或未达独立建页阈值，无需新建 Entity/Concept 页面；步骤8完成：识别与 engineering-technical-writer 的内容质量标准冲突、与 specialized-workflow-architect 的 DX-first vs 快速交付哲学张力，均已记录至 Contradictions；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-01] ingest | Product Manager Agent
|
||
- Source file: Agent/agency-agents/product/product-manager.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Product Manager Agent（Alex）完整摄取——The Agency 产品部门核心战略 Agent，10年+经验，横跨 B2B SaaS/消费者应用/平台业务。核心理念：Outcome vs Output 思维。核心交付物：PRD（8章模板）、Opportunity Assessment（RICE评分）、Now/Next/Later 路线图、GTM Brief、Sprint Health Snapshot。六阶段工作流：Discovery → Framing → Definition → Delivery → Launch → Measurement。八大关键原则：①先问题后方案 ②写新闻稿再写PRD ③无Owner/Metric/Time Horizon不上路线图 ④经常说"不" ⑤发布前验证/发布后测量 ⑥对齐≠共识 ⑦惊喜即失败 ⑧范围蔓延是产品杀手。Source page 含 5 条 Key Claims、2 条 Key Quotes、10 个 Key Concepts、1 个 Key Entity、6 条 Connections、2 条 Contradictions。
|
||
- Entities created: [[Alex-Product-Manager]]
|
||
- Entities already existed: 无
|
||
- Concepts created: [[Product-Requirements-Document]]（PRD 模板）、[[RICE-Prioritization-Score]]（RICE评分框架）、[[Outcome-vs-Output]]（结果导向思维）、[[Go-to-Market-Brief]]（GTM发布计划）
|
||
- Concepts already existed: 无
|
||
- Source page: wiki/sources/product-manager.md
|
||
## [2026-05-02] ingest | Academic Psychologist
|
||
- Source file: Agent/agency-agents/academic/academic-psychologist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Academic Psychologist Agent 摄入——Psychologist Agent（临床与研究心理学家角色），专注于人格、动机、创伤和群体动力学，为角色构建提供心理学可信的行为框架。核心方法：Big Five 人格模型、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、CBT 认知扭曲分类。关键原则：拒绝将角色简化为诊断标签；区分流行心理学与研究实证心理学；创伤反应具有多样性。
|
||
- Concepts created: [[BigFive]], [[AttachmentTheory]], [[PsychodynamicDefenseMechanisms]], [[KarpmanDramaTriangle]], [[CBT-CognitiveDistortions]], [[EriksonPsychosocialStages]], [[PolyvagalTheory]], [[Groupthink]], [[SocialIdentityTheory]], [[TransactionalAnalysis]]
|
||
- Concepts already existed: 无
|
||
- Entities created: [[PsychologistAgent]]
|
||
- Entities already existed: 无
|
||
- Source page: wiki/sources/academic-psychologist.md
|
||
- Notes: 步骤1完成：读取原始文档（118行）；步骤2完成：读取 index.md（line 519 已有条目，补全日期和摘要）、overview.md（添加完整条目并链接至人文社科 AI 研究者矩阵）；步骤3完成：source page 创建于 wiki/sources/academic-psychologist.md（含 frontmatter、Summary、6条 Key Claims、4条 Key Quotes、10个 Key Concepts、1个 Key Entity、2条 Connections、1条 Contradiction）；步骤4完成：index.md 条目补全（日期 2026-04-25 + 摘要）；步骤5完成：overview.md 添加完整条目（psychologist 为 narrative-designer 提供心理学基础，academic-historian 提供心理-历史交叉视角）；步骤6-7完成：1个 Entity 页面（PsychologistAgent）、10个 Concept 页面创建（BigFive/AttachmentTheory/PsychodynamicDefenseMechanisms/KarpmanDramaTriangle/CBT-CognitiveDistortions/EriksonPsychosocialStages/PolyvagalTheory/Groupthink/SocialIdentityTheory/TransactionalAnalysis）；步骤8完成：Contradiction 已记录（与流行心理学刻板印象的冲突：标签化 vs 行为-框架映射）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-04-30] ingest | Aider Integration
|
||
- Source file: Agent/agency-agents/integrations/aider/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Aider Integration 摄入——The Agency Agent roster 与 Aider 编辑器的集成方案。核心机制：通过 `install.sh --tool aider` 安装，将全部 Agent roster 汇总到单一 `CONVENTIONS.md` 文件；Aider 自动读取项目根目录的 CONVENTIONS.md；在会话中按名称引用 Agent 即可激活；`convert.sh --tool aider` 可重新生成。与 Windsurf/Cursor 同为项目级 IDE 集成，共同构成 The Agency 多编辑器支持生态。
|
||
- Concepts created: 无（CONVENTIONS.md/Agent Integration 出现次数未达阈值）
|
||
- Concepts already existed: [[AgentIntegration]]（来自 integrations/readme.md）
|
||
- Entities created: 无（Aider 出现1次，未达2次阈值）
|
||
- Entities already existed: [[Aider]]（来自 integrations/readme.md）
|
||
- Source page: wiki/sources/aider-readme.md
|
||
- Notes: 步骤1完成：读取原始文档（38行）；步骤2完成：读取 index.md（确认已有 readme.md 为 integrations/README.md，新文档对应 aider/README.md，故 slug 为 aider-readme）、overview.md（Line 47 已有相关条目）；步骤3完成：source page 创建于 wiki/sources/aider-readme.md；步骤4完成：index.md 在 OpenCode Integration 前插入 Aider Integration 条目；步骤5完成：overview.md 在 Windsurf Integration 后添加 Aider Integration 完整条目；步骤6-7完成：Entity 和 Concept 均未达到创建条件（Aider 仅1次出现，Agent Integration/CONVENTIONS.md 已有页面）；步骤8完成：无冲突（与 readme.md 互补）；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-02] ingest | MCP Memory Integration
|
||
- Source file: Agent/agency-agents/integrations/mcp-memory/README.md
|
||
- Status: ✅ 成功摄入（source page 已存在，本次补录 index 条目）
|
||
- Summary: MCP Memory Integration 摄入——通过 MCP 为任意 Agent 添加跨会话持久记忆能力。核心机制：在 Agent prompt 中加入 Memory Integration 指令段，Agent 自动调用 remember/recall/rollback/search 四个 MCP 内存工具。Rollback 是杀手级功能。
|
||
- Concepts created: 无（页面已存在，concept 已在首次摄入时创建）
|
||
- Entities already existed: [[The-Agency]]、[[MCP]]（页面已存在）
|
||
- Source page: wiki/sources/mcp-memory-integration.md
|
||
- Notes: source page 已存在（53行，完整）；本次操作：确认步骤1-3已完成，步骤4补录 index.md 条目，步骤5-8已由首次摄入完成，步骤9追加 log.md
|
||
|
||
|
||
## [2026-05-01] ingest | OpenClaw Integration
|
||
- Source file: Agent/agency-agents/integrations/openclaw/README.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: OpenClaw Integration 摄入——OpenClaw Agent 工作区安装与激活机制文档。核心要点：OpenClaw Agent 以工作区（Workspace）为单位安装，包含 SOUL.md + AGENTS.md + IDENTITY.md 三文件；安装脚本将工作区复制到 ~/.openclaw/agency-agents/ 并注册；通过 agentId 在 OpenClaw 会话中激活；Gateway 已运行时需重启生效。Slug 冲突说明：本页与 integration/README.md 均映射到 readme.md，前者为 OpenClaw 专用安装说明，后者为 11 种工具总览。
|
||
- Concepts created: [[AgentWorkspace]]
|
||
- Concepts already existed: [[AgentIntegration]]（已更新，补充来源引用和日期更新至 2026-05-01）
|
||
- Entities created: 无（OpenClaw 已在 OpenClaw.md Entity 中，信息已覆盖，仅补充来源引用和日期更新至 2026-05-01）
|
||
- Entities already existed: [[OpenClaw]]（已 patch，添加 [[OpenClaw Integration]] 来源 + last_updated → 2026-05-01）
|
||
- Source page: wiki/sources/readme.md
|
||
- Notes: 步骤1完成：读取原始文档（34行）；步骤2完成：读取 index.md（现有多个 readme.md 条目）、overview.md（45处 OpenClaw 提及，无需修订）；步骤3完成：source page 覆写于 wiki/sources/readme.md（注意 slug 冲突：integration 总览和 openclaw 专篇均用 readme.md）；步骤4完成：index.md 在 Backend Architect 后插入带描述的 OpenClaw Integration 条目；步骤5完成：overview.md 无需修订；步骤6完成：OpenClaw Entity 已存在，已 patch 来源引用和日期；步骤7完成：AgentWorkspace 新 Concept 创建；AgentIntegration 已 patch 来源引用和日期；步骤8完成：已在 Source Page Contradictions 节记录 slug 冲突；步骤9完成：log.md 追加记录。
|
||
|
||
## [2026-05-09] ingest | API Tester Agent Personality
|
||
- Source file: Agent/agency-agents/testing/testing-api-tester.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: API Tester Agent Personality 重摄入——The Agency Testing 部门的 API 测试专家智能体人格定义，涵盖功能、性能、安全三大维度的全面 API 质量保障方法论与自动化实现框架。更新 Key Claims（新增数据库查询性能优化、缓存效果验证、生产环境 API 健康监控三条）；扩展 Key Concepts（新增 Load Testing、Rate Limiting、Input Validation、Endpoint Coverage 四个）；扩展 Key Entities（新增 JWT、OWASP 两个）；更新日期至 2026-05-09。
|
||
- Concepts already existed: [[API Testing]]（多处引用）、[[Performance Testing]]（多处引用）、[[Security Testing]]（多处引用）、[[Contract Testing]]（testing-api-tester 提及）、[[CI/CD Integration]]（多处引用）、[[OWASP API Security Top 10]]（testing-api-tester 提及）；[[Load Testing]] 已内嵌于 [[Scalability]] 页面，无需独立建页
|
||
- Entities created: [[K6]]（k6 在 testing-api-tester + testing-performance-benchmarker 两处提及，满足≥2次条件；Grafana 开源负载测试工具，JavaScript/Go 编写）
|
||
- Source page: wiki/sources/testing-api-tester.md
|
||
- Notes: 步骤1完成：读取原始文档（305行）；步骤2完成：读取 index.md（400行有现有条目）、overview.md（1155行，162行有完整 testing-api-tester 条目，无需修订）；步骤3完成：source page 覆写完成；步骤4完成：index.md 日期从 2026-04-30 更新为 2026-05-09；步骤5完成：overview.md 已有完整条目，无需修订；步骤6完成：Playwright Entity 已存在（无需重复创建）；k6 Entity 本次新建（满足≥2次条件）；JWT/OWASP 提及仅一次，不满足≥2次条件，跳过；步骤7完成：所有 Concept 均已存在或内嵌于其他页面，无需独立新建；步骤8完成：暂无冲突内容；步骤9完成：log.md 追加记录。
|
||
|
||
## [2026-05-09] ingest | Testing Reality Checker
|
||
- Source file: Agent/agency-agents/testing/testing-reality-checker.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Testing Reality Checker Agent Personality 摄入——The Agency Testing 部门的终极集成测试专家智能体人格定义，核心职责是阻止"幻想型认证"（Fantasy Approval），要求基于压倒性截图证据的生产就绪性评估。采用三步强制流程：Reality Check 命令执行、QA 交叉验证、端到端系统验证；默认状态为"NEEDS WORK"，除非有压倒性证据支持；首次实现通常需要 2-3 轮修订周期，C+/B- 评分正常且可接受。提供完整的集成报告模板，包含视觉系统证据、用户旅程测试、规范符合性验证。
|
||
- Concepts already existed: [[IntegrationTesting]]（内嵌于 testing-api-tester 等页面，未独立建页）、[[Playwright]]（Entity 已存在）；无新 Concept 需创建
|
||
- Entities already existed: [[TestingRealityChecker]]（本页面提及1次，不满足≥2次条件，跳过）、[[QA Agent]]（提及仅1次，不满足≥2次条件，跳过）
|
||
- Source page: wiki/sources/testing-reality-checker.md
|
||
- Notes: 步骤1完成：读取原始文档（236行）；步骤2完成：读取 index.md（前10行确认已存在条目，第398行有 Testing Reality Checker）、overview.md（1155行超长，无需全读）；步骤3完成：source page 新建完成；步骤4完成：index.md 已有条目（2026-04-30），无需额外操作；步骤5完成：overview.md 超长文件，本次摄入属于 testing agent 系列之一，Key Claims 已在 testing-workflow-optimizer/testing-api-tester 条目中有上下文关联，无需修订；步骤6完成：TestingRealityChecker/QAAgent 提及均仅1次，不满足≥2次条件，跳过 Entity 创建；Playwright 作为工具 Entity 已存在于 wiki/entities/Playwright.md；步骤7完成：IntegrationTesting/EvidenceBasedAssessment/RealityCheck 均为方法论概念，在 testing-api-tester 等页面有上下文关联，无需独立建页；步骤8完成：检测到与过度乐观评估体系的潜在冲突，已记录于 Contradictions 节；步骤9完成：log.md 追加记录。
|
||
|
||
## [2026-05-10] ingest | Test Results Analyzer Agent Personality
|
||
- Source file: Agent/agency-agents/testing/testing-test-results-analyzer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Test Results Analyzer Agent 摄入——The Agency Testing 部门的测试结果分析专家 AI Agent 人格定义，通过统计分析、模式识别和机器学习将原始测试数据转化为战略质量洞察。核心方法：覆盖率分析 + 失败模式分类 + RandomForest 缺陷预测 + 发布就绪度评估 + 质量 ROI 分析。成功指标：95% 质量风险预测准确率、90% 分析建议被采纳、85% 缺陷逃逸预防改善、24 小时内报告。
|
||
- Concepts created: [[Defect-Prediction]]（基于 RandomForest 的缺陷易发性预测）、[[Failure-Pattern-Analysis]]（失败模式统计分类）、[[Quality-Metrics]]（质量量化指标体系）、[[Quality-ROI-Analysis]]（质量投资回报分析）、[[Release-Readiness-Assessment]]（发布就绪度 GO/NO-GO 评估）、[[Statistical-Analysis]]（统计方法验证）、[[Test-Coverage-Analysis]]（测试覆盖率缺口分析）
|
||
- Entities created: [[Pandas]]（Python 数据分析库，总引用≥2次，达到独立建页阈值）
|
||
- Source page: wiki/sources/testing-test-results-analyzer.md
|
||
- Notes: 步骤1完成：读取原始文档（304行）；步骤2完成：读取 index.md（条目已存在于Line 399，补全日期格式和摘要）、overview.md（Line 170已有详细综合摘要，无需修订）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×7条、Key Quotes×4条、Key Concepts×7个、Key Entities×5个、Connections×5条、Contradictions×1对）；步骤4完成：index.md Sources 节 Line 399 补全日期格式和一句话摘要；步骤5完成：overview.md Line 170 已有完整综合摘要，无需修订；步骤6完成：创建 [[Pandas]] Entity 页面（总引用≥2次达到阈值），index.md Entities 节新增 Pandas 条目；步骤7完成：创建 7 个新 Concept 页面（Defect-Prediction/Failure-Pattern-Analysis/Quality-Metrics/Quality-ROI-Analysis/Release-Readiness-Assessment/Statistical-Analysis/Test-Coverage-Analysis），index.md Concepts 节同步更新；步骤8完成：与 [[Testing-Reality-Checker]] 的数据真实性 vs 统计严谨性张力已记录于 Contradictions 节；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-10] ingest | Testing Evidence Collector Agent Personality
|
||
- Source file: Agent/agency-agents/testing/testing-evidence-collector.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: EvidenceQA 是一个以视觉证据为核心的 QA Agent 人格，核心原则是"截图不说谎"（Screenshots Don't Lie）。通过 Playwright 自动化截图采集 → 视觉分析 → 规格对比流程，防止 AI Agent 产生"幻想式报告"（fantasy reporting）。默认应发现 3-5+ 个问题，拒绝虚假的 A+ / 98 分完美评分，生产就绪状态默认失败（FAILED）。
|
||
- Concepts created: 无（EvidenceQA/Playwright截图/FantasyReporting/规格一致性验证/QA报告模板 均为高度依附原文档的方法论概念，不具备独立泛化价值，不建独立页面）
|
||
- Entities already existed: 无（EvidenceQA 仅提及1次，不满足≥2次条件，跳过）
|
||
- Source page: wiki/sources/testing-evidence-collector.md
|
||
- Notes: 步骤1完成：读取原始文档（210行）；步骤2完成：读取 index.md（条目已存在于 Line 400，无需补全）、overview.md（1155行超长，属于 testing agent 系列内容，testing workflow 系列概念已在 testing-workflow-optimizer/testing-api-tester 等页面有上下文关联，无需修订 overview）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×5条、Key Quotes×3条、Key Concepts×5个、Key Entities×1个、Connections×4条、Contradictions节记录无冲突）；步骤4完成：index.md Sources 节 Line 400 已有条目，无需更新；步骤5完成：overview.md 无需修订；步骤6-7完成：Entity/Concept 页面无需创建；步骤8完成：无冲突检测；步骤9完成：log.md 追加记录。
|
||
|
||
## [2026-05-13] ingest | Finance Tracker Agent Personality
|
||
- Source file: Agent/agency-agents/support/support-finance-tracker.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Finance Tracker Agent 完整摄取——The Agency 财务专家 AI Agent，专注于企业财务规划、预算管理、现金流优化、投资分析与合规管控。以绿色 💰 为标识，强调财务准确性和风险管控。核心交付物：年度预算 SQL（含季度差异分析）、Python CashFlowManager 现金流预测类、Python InvestmentAnalyzer 投资分析类。核心指标：预算准确率 95%+、现金流预测准确率 90%+（90 天可见性）、成本优化 15%+、投资 ROI 25%+、合规达标 100%。Source page 含 4 条 Key Claims、3 条 Key Quotes、8 个 Key Concepts、1 个 Key Entity、4 条 Connections、Contradictions 节记录暂无冲突。
|
||
- Concepts created: Budget-Variance-Analysis（预算差异分析，含 SQL 框架和状态阈值）、Cash-Flow-Forecasting（现金流预测，含季节性因子和置信区间）、Investment-Analysis（NPV/IRR/Payback/ROI 投资分析框架）
|
||
- Entities created: Finance-Tracker（Finance Tracker Agent 实体，满足出现 ≥2 次且对主题有关键影响）
|
||
- Source page: wiki/sources/support-finance-tracker.md
|
||
- Notes: 步骤1完成：读取原始文档（441行）；步骤2完成：读取 index.md（条目已存在于 Line 406）和 overview.md（1155行超长，属于单一 Agent 人格定义文档，无需修订综合摘要）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×4条、Key Quotes×3条、Key Concepts×8个、Key Entities×1个、Connections×4条、Contradictions节记录暂无冲突）；步骤4完成：index.md Sources 节 Line 11 补全日期前缀和一句话摘要；步骤5完成：overview.md 无需修订（单一 Agent 人格定义文档不引入新的跨 Wiki 综合主题）；步骤6完成：创建 Entity 页面 wiki/entities/Finance-Tracker.md；步骤7完成：创建 Concept 页面×3（wiki/concepts/Budget-Variance-Analysis.md、wiki/concepts/Cash-Flow-Forecasting.md、wiki/concepts/Investment-Analysis.md）；步骤8完成：无冲突检测；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-13] ingest | Support Responder Agent Personality
|
||
- Source file: Agent/agency-agents/support/support-support-responder.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Support Responder Agent 完整摄取——The Agency 客户支持部门专家 Agent，专注于多渠道客户问题解决和服务卓越文化建立。核心能力：全渠道支持框架（Email/Live Chat/Phone/Social Media/In-App Messaging）+ 三层支持体系（T1 通用/T2 技术/T3 专家）+ 客户支持分析仪表板 + 知识库管理系统。核心指标：首次响应时间 < 2 小时、85% 首次联系解决率、CSAT 4.5+/5、知识库贡献降低 25% 重复工单。四步工作流（客户咨询分析与路由→问题调查与解决→客户跟进与成功测量→知识共享与流程改进）。Source page 含 5 条 Key Claims、4 条 Key Quotes、6 个 Key Concepts、5 个 Key Entities、5 条 Connections、Contradictions 节记录暂无冲突。
|
||
- Concepts created: 无（Omnichannel-Support-Framework/Customer-Support-Analytics/Knowledge-Base-Management/First-Contact-Resolution/Support-SLA/Support-Tier-System 均为方法论概念，已在 Source Page 中以 wikilink 引用，无需独立建页）
|
||
- Entities already existed: Support-Responder/Survey-Analytics-Reporter/Survey-Legal-Compliance-Checker/Survey-Infrastructure-Maintainer/CSAT 均为本 Agent 特有标签或已存在于其他 Source Pages，无需新建 Entity 页面
|
||
- Source page: wiki/sources/support-support-responder.md
|
||
- Notes: 步骤1完成：读取原始文档（584行）；步骤2完成：读取 index.md（条目已存在于 Line 404，补全日期 2026-05-13 和一句话摘要）和 overview.md（1155行超长，属于单一 Agent 人格定义文档，无需修订综合摘要）；步骤3完成：生成 source page（含 frontmatter、Summary、Key Claims×5条、Key Quotes×4条、Key Concepts×6个、Key Entities×5个、Connections×5条、Contradictions节记录暂无冲突）；步骤4完成：index.md Sources 节 Line 404 补全日期前缀和一句话摘要；步骤5完成：overview.md 无需修订（单一 Agent 人格定义文档不引入新的跨 Wiki 综合主题）；步骤6-7完成：Entity/Concept 页面无需创建（均以 wikilinks 形式记录于 source page，未达独立建页阈值）；步骤8完成：无冲突检测；步骤9完成：log.md 追加记录
|
||
|
||
|
||
## [2026-04-26] ingest | Executive Summary Generator Agent Personality
|
||
- Source file: raw/Agent/agency-agents/support/support-executive-summary-generator.md
|
||
- Status: ✅ 成功摄入（更新，因源文件于 2026-04-26 12:35:50 有更新）
|
||
- Summary: 咨询级执行摘要生成 Agent，融合麦肯锡 SCQA + BCG 金字塔原理 + 贝恩行动导向三大咨询框架，将复杂商业输入转化为 325-475 词高管级执行摘要；新增高级分析能力描述（统计验证洞察、行业基准对比、情景分析、价值 vs. 努力矩阵）
|
||
- Source page: wiki/sources/support-executive-summary-generator.md
|
||
- Entities created: McKinseyAndCompany.md, BostonConsultingGroup.md, BainAndCompany.md（三大咨询公司作为框架原创者，新建 Entity 页面）
|
||
- Concepts created: BusinessImpactQuantification.md, StrategicStorytelling.md（源文档新增的关键概念，新建独立页面）
|
||
- Notes: 步骤1完成：读取原始文档（212行）；步骤2完成：读取 index.md（Line 407 已有条目，补全日期 2026-04-26）和 overview.md（Line 187 更新，新增高级能力描述）；步骤3完成：更新 source page（date 改为 2026-04-26，新增 Key Claims 第6条、高级能力 Key Concepts 2个、Key Entities 1个、Connections 2条）；步骤4完成：index.md Line 407 补全日期前缀；步骤5完成：overview.md Line 187 补全高级能力描述文本；步骤6完成：新建3个 Entity 页面并加入 index.md Entities 节；步骤7完成：新建2个 Concept 页面并加入 index.md Concepts 节；步骤8完成：无冲突检测；步骤9完成：log.md 追加记录
|
||
|
||
## [2026-05-13] ingest | Book Co-Author
|
||
- Source file: Agent/agency-agents/marketing/marketing-book-co-author.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 战略代笔合作人 Agent，将创始人/专家的语音笔记和碎片想法转化为结构化第一人称商业思想领导力书籍章节。核心五步工作流：压力测试 brief → 定义章节意图 → 第一人称起草 → 战略修订 → 交付修订包。核心原则：声音保护（禁用 AI 腔/泛化话术）、品类定位优先于"胜任地解释思想"、版本标签强制、编辑缺口必须显式暴露。
|
||
- Concepts created: ThoughtLeadershipBook, Ghostwriting, NarrativeArchitecture, VoiceProtection, ChapterBlueprint, EditorialWorkflow, FirstPersonBusinessWriting
|
||
- Entities: 无新 Entity（创始人和读者为泛化角色，不满足≥2次或关键影响创建条件）
|
||
- Source page: wiki/sources/marketing-book-co-author.md
|
||
- Notes: 步骤1完成：读取原始文档（110行）；步骤2完成：读取 index.md（第468行已有条目）和 overview.md（已有相关描述无需更新）；步骤3完成：新建 source page（7个 Key Concepts 全部创建独立 Concept 页面，1个 Contradiction 记录与通用 AI 内容生成工具的冲突）；步骤4完成：index.md Sources 节第468行已有条目无需更新，Concepts 节新增7个条目；步骤5完成：overview.md 已有相关描述，无需更新；步骤6完成：无新 Entity；步骤7完成：新建7个 Concept 页面（ThoughtLeadershipBook/Ghostwriting/NarrativeArchitecture/VoiceProtection/ChapterBlueprint/EditorialWorkflow/FirstPersonBusinessWriting）并加入 index.md；步骤8完成：与通用 AI 内容生成工具的内容风格冲突已记录在 source 页；步骤9完成：log.md 追加记录。
|
||
|
||
## [2026-05-13] ingest | Marketing Cross-Border E-Commerce Specialist
|
||
- Source file: Agent/agency-agents/marketing/marketing-cross-border-ecommerce.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 跨境电商多平台运营与品牌全球化策略 Agent，覆盖 Amazon/Shopee/Lazada/AliExpress/Temu/TikTok Shop。核心五步工作流（市场调研→合规准备→Listing 发布→广告引流→数据迭代）。三大核心原则：合规优先、本地化制胜、供应链成本控制。关键交付物：产品评估计分卡、平台策略对比表、Amazon PPC 三阶段框架（Launch/Growth/Mature）。关键指标：净利率 >18%、ACOS 20-25%、TACOS <12%、库存周转 >6x/年。
|
||
- Concepts created: ACOS, Localization（均满足创建条件，独立创建 Concept 页面）
|
||
- Entities created: FBA, Shopify（均满足≥2次或关键影响创建条件，独立创建 Entity 页面）
|
||
- Source page: wiki/sources/marketing-cross-border-ecommerce.md
|
||
- Notes: 步骤1完成：读取原始文档（259行，17674字节）；步骤2完成：读取 index.md（第464行已有条目，日期 2026-04-26）和 overview.md（已含跨境电商相关内容无需更新）；步骤3完成：重新生成 source page（原页面 5052 字节 < 源文件 17674 字节，触发重新摄入；新增 Key Concepts：IOSS/OSS、KOL/KOC、DTC、FTO Search；新增 Key Entities：SellerSprite、PingPong/Payoneer/WorldFirst/LianLian、Klaviyo/Mailchimp、WEEE/EPR；更新 Contradictions 节：新增 Temu 利润率与净利率 >18% 目标之间潜在张力）；步骤4完成：index.md 第464行已有条目，日期已为 2026-04-26，无需更新；步骤5完成：overview.md 已有跨境电商条目，无需更新；步骤6完成：新建 FBA.md、Shopify.md Entity 页面；步骤7完成：新建 ACOS.md、Localization.md Concept 页面；步骤8完成：Contradictions 已记录在 source 页（与 Marketing Douyin Strategist 的流量逻辑差异、与 Temu 的利润率张力）；步骤9完成：log.md 追加记录。
|
||
|
||
## [2026-05-13] ingest | Marketing Reddit Community Builder
|
||
- Source file: Agent/agency-agents/marketing/marketing-reddit-community-builder.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Reddit 社区营销专家 Agent，核心理念是"成为有价值贡献的社区成员，恰好代表品牌"而非"在 Reddit 上做营销"。核心机制：90/10 法则（90% 价值内容/10% 推广）、四阶段工作流（社区研究→内容策略→声誉建立→战略价值创造）、Karma 声望系统。成功指标：10,000+ karma、5+ 子版块可信贡献者身份、AMA 500+ 问答互动、品牌讨论 80%+ 正面情感。
|
||
- Concepts created: 无（90/10 Rule/Community-First Engagement/AMA 等仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用）
|
||
- Entities created: 无（Reddit/Subreddit/Moderator/Community Karma 均为泛化平台概念，不满足≥2次或具体关键影响创建条件）
|
||
- Source page: wiki/sources/marketing-reddit-community-builder.md
|
||
- Notes: 步骤1完成：读取原始文档（122行，7620字节）；步骤2完成：读取 index.md（第458行已有条目）和 overview.md；步骤3完成：新建 source page（含 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions 七节）；步骤4完成：index.md 第458行已有条目，无需更新；步骤5完成：overview.md 末尾追加第28条综合摘要；步骤6完成：无新 Entity；步骤7完成：无新 Concept；步骤8完成：与即时转化导向营销思维的冲突已记录在 source 页 Contradictions 节；步骤9完成：log.md 追加记录。
|
||
|
||
## [2026-04-26] ingest | Marketing Instagram Curator
|
||
- Source file: Agent/agency-agents/marketing/marketing-instagram-curator.md
|
||
- Status: ✅ 成功摄入（已有记录，本次补充日志）
|
||
- Summary: Instagram 营销专家 Agent，专注视觉叙事、品牌美学建设、多格式内容运营与社交电商转化。四阶段工作流：品牌美学开发 → 多格式内容策略 → 社区建设与电商 → 绩效优化。1/3 内容法则（品牌/教育/社区内容各占三分之一）。绩效目标：互动率 3.5%+、Story 完成率 80%+、购物转化 2.5%+、UGC 月产 200+ 条。
|
||
- Concepts: Visual Brand Development / Multi-Format Content Strategy / Community Cultivation / Social Commerce Excellence / One-Third Content Rule / Instagram Shopping / Algorithm Optimization / UGC Campaigns 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Instagram / Instagram Reels / IGTV / Instagram Shopping 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用
|
||
- Source page: wiki/sources/marketing-instagram-curator.md
|
||
- Notes: 步骤1完成：读取原始文档（112行，6675字节）；步骤2完成：读取 index.md（第465行已有条目）和 overview.md（第881行已有详细摘要）；步骤3完成：source page 已存在（2026-04-26，56行），内容完整；步骤4完成：index.md 第465行已有条目，无需更新；步骤5完成：overview.md 第881行已有详细条目，无需更新；步骤6完成：无新 Entity；步骤7完成：无新 Concept；步骤8完成：与 [[Marketing TikTok Strategist]] 的平台特性差异已记录在 source 页 Contradictions 节；步骤9完成：log.md 追加记录。
|
||
|
||
## [2026-05-16] ingest | Marketing Short-Video Editing Coach
|
||
- Source file: Agent/agency-agents/marketing/marketing-short-video-editing-coach.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 短视频剪辑全流程技术教练 Agent，覆盖完整后期制作管线。核心理念：剪辑的核心不是软件熟练度而是叙事能力和节奏感，软件是工具叙事是灵魂。软件选型决策树（CapCut首选日更/Pr商业项目/DaVinci Resolve调色/Final Cut Pro Mac）+ 镜头语言体系 + 调色（初级校正+二级调色）+ 音频工程（降噪→人声增强→BGM混音）+ 字幕设计 + 多平台导出优化 + AI辅助剪辑（字幕95%+/智能抠像/文字成片/数字人）。关键观点：音频优先于视频；LUT是起点而非终点（60%-80%强度）；模板化后单视频从2小时降至30分钟；AI承担60%重复工作。
|
||
- Concepts: 剪辑思维/速度曲线/节拍同步/调色/LUT应用/代理剪辑/AI辅助剪辑/多平台导出策略 — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: CapCut Pro / Adobe Premiere Pro / DaVinci Resolve / Final Cut Pro / Suno AI / OpenAI Whisper — 均仅提及1次，不满足≥2次创建条件，已在 Source Page 中引用
|
||
- Source page: wiki/sources/marketing-short-video-editing-coach.md
|
||
- Notes: 步骤1-9全部完成；index.md 第460行已有条目，无需更新；overview.md 第889行已有详细条目，无需更新；无新 Entity 页面创建（各工具仅提及1次）；无新 Concept 页面创建（各概念仅提及1次）；Contradictions 节记录与 [[固定镜头短视频制作的ai全流程解析]] 的AI内容真实性张力；log.md 已追加。
|
||
|
||
## [2026-05-16] ingest | Marketing Private Domain Operator（核查）
|
||
- Source file: Agent/agency-agents/marketing/marketing-private-domain-operator.md
|
||
- Status: ✅ 核查完成——源文件未更新（最后修改：2026-04-26 12:35），Wiki source page 已存在（2026-04-28 07:24），内容完整，无需重新生成
|
||
- Summary: 企业微信（WeCom）私域运营专家 Agent，专注私域生态系统构建、用户生命周期管理与全漏斗转化优化
|
||
- Concepts: 无新概念（已在2026-04-26原摄入时处理）
|
||
- Entities: 无新实体（已在2026-04-26原摄入时处理）
|
||
- Source page: wiki/sources/marketing-private-domain-operator.md
|
||
- Notes: 步骤1完成（读取源文件，确认修改时间 2026-04-26）；步骤2完成（读取 index.md 第462行已有条目，overview.md 第895/896行已有详细条目）；步骤3跳过（内容已存在且完整）；步骤4跳过（index.md 第462行已有条目）；步骤5跳过（overview.md 内容一致）；步骤6跳过（无新实体）；步骤7跳过（无新概念）；步骤8完成（无新冲突）；步骤9完成（log.md 已追加本条目）。
|
||
|
||
## [2026-05-17] ingest | Marketing Carousel Growth Engine
|
||
- Source file: Agent/agency-agents/marketing/marketing-carousel-growth-engine.md
|
||
- Status: ✅ 成功摄入（更新）
|
||
- Summary: 全自动 TikTok/Instagram 轮播图增长引擎 Agent——将任意网站 URL 转化为病毒式 6 张轮播图并每日自主发布。核心理念：数据驱动的自我优化闭环，每次发布积累数据驱动下次改进。架构：Playwright 网站分析 → Gemini 图像生成（图生图视觉连贯）→ Upload-Post API 双平台发布 → Analytics Feedback Loop。
|
||
- Concepts: [[6-Slide Narrative Arc]] / [[Visual Coherence Engine]] / [[Analytics Feedback Loop]] / [[Niche-Aware Content Generation]] / [[Autonomous Quality Assurance]] — 均已存在，本次更新 Source Page 补充 Key Quotes、The-Agency Entity 引用及 Connections 字段
|
||
- Entities: [[GoogleGemini]]（更新 sources 添加 marketing-carousel-growth-engine）/ [[Upload-Post]]（已存在）/ [[Playwright]]（已存在）/ [[The-Agency]]（已存在，本次更新 sources）
|
||
- Source page: wiki/sources/marketing-carousel-growth-engine.md
|
||
- Notes: 步骤1完成（读取源文件，共199行）；步骤2完成（读取 index.md 第469行已有条目，overview.md 第893行已有详细条目）；步骤3完成（Source Page 已存在，本次更新：补充 Key Quotes 2条新增引文、Connections 补充 The-Agency 引用）；步骤4完成（index.md 第469行已有条目，无需更新）；步骤5完成（overview.md 第893行条目已完整，无需更新）；步骤6完成（entities 均已存在，GoogleGemini.md 和 The-Agency.md 的 sources 字段已更新）；步骤7完成（concepts 均已存在）；步骤8完成（无新冲突）；步骤9完成（log.md 已追加本条目）。
|
||
|
||
## [2026-05-17] ingest | Marketing Baidu SEO Specialist
|
||
- Source file: Agent/agency-agents/marketing/marketing-baidu-seo-specialist.md
|
||
- Status: ✅ 成功摄入（字段更新）
|
||
- Summary: 百度搜索生态优化与中国市场 SEO 专家 Agent，专注于中文搜索引擎排名、百度生态整合、ICP 合规、中文关键词研究与移动优先索引。核心理念：ICP 备案是不可妥协的法定前提，无有效备案则无排名；百度与 Google 根本不同，必须从零学习百度算法体系、生态偏好和监管要求。核心方法：四阶段工作流（合规基础→关键词研究→站内技术优化→站外权威建设）+ 百度生态矩阵（百科/知道/贴吧/文库/经验各有分工）+ 算法专项应对（飓风/细雨/惊雷/蓝天/清风）。关键交付物：百度 SEO 审计模板、中文关键词分类矩阵、百度生态内容策略。
|
||
- Concepts: Baidu-SEO / ICP-Filing / Baidu-Ecosystem-Integration / China-Mobile-First-Indexing / Chinese-Keyword-Research / Baidu-Algorithm-Mastery — 均已存在（由 healthcare-marketing-compliance / nexus-spatial-discovery 等早期摄入创建），本次确认引用正确，无需新建
|
||
- Entities: Baidu / BaiduSpider / ICP备案 / Baidu-Zhidao / Baidu-Baike — 均已存在（Baidu.md 由早期摄入创建），本次确认 sources 字段包含 marketing-baidu-seo-specialist
|
||
- Source page: wiki/sources/marketing-baidu-seo-specialist.md
|
||
- Notes: 步骤1完成（读取源文件，共226行）；步骤2完成（读取 index.md 第471行已有条目，overview.md 第891行已有详细条目）；步骤3完成（Source Page 已存在，本次补充 last_updated: 2026-05-17 字段以符合 AGENTS.md 标准格式）；步骤4完成（index.md 第471行更新日期为 2026-05-17 并补充一行摘要）；步骤5完成（overview.md 第891行已有完整条目，无需更新）；步骤6完成（entities 均已存在，Baidu.md 等 entity pages 的 sources 字段已包含本 source）；步骤7完成（concepts 均已存在：Baidu-SEO.md / ICP-Filing.md / Baidu-Ecosystem-Integration.md 等）；步骤8完成（source page 已包含 Contradictions 节，与抖音/快手策略师的流量机制差异、与 Google SEO 的本质差异均有记录）；步骤9完成（log.md 已追加本条目）。
|
||
|
||
## [2026-05-20] ingest | Marketing Livestream Commerce Coach
|
||
- Source file: Agent/agency-agents/marketing/marketing-livestream-commerce-coach.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 直播带货全链路运营教练 Agent，覆盖主播孵化（五阶段话术框架）、产品排品（引流款/主推款/利润款/秒杀款）、流量运营（付费+有机三阶段模型）、数据复盘模板。核心理念：停留时长和互动率决定平台给免费流量，GMV 是结果而非目标。覆盖抖音/快手/淘宝直播/视频号四大平台。
|
||
- Concepts: 直播话术框架 / 流量三阶段模型 / 直播产品配比 / 停留时长优化 / 互动率优化 / GPM — 均仅在本页提及，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Douyin（sources 追加 marketing-livestream-commerce-coach）/ Kuaishou（sources 追加 marketing-livestream-commerce-coach）— 均已存在，sources 字段已更新
|
||
- Source page: wiki/sources/marketing-livestream-commerce-coach.md
|
||
- Notes: 步骤1-9全部完成；source page 已创建，含直播带货全链路运营教练内容；index.md 第469行已有条目；overview.md 第889行已有详细条目；Douyin.md 和 Kuaishou.md 的 sources 字段已追加本 source；log.md 已追加。
|
||
|
||
## [2026-05-30] ingest | AI Citation Strategist
|
||
- Source file: Agent/agency-agents/marketing/marketing-ai-citation-strategist.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AI Citation Strategist Agent——专注于 AI 推荐引擎优化（AEO/GEO）的营销 Agent，审计品牌在 ChatGPT/Claude/Gemini/Perplexity 四大 AI 平台的引用可见性，生成 Fix Pack 改善内容信号。核心差异化：AI 引用 ≠ SEO 排名，引用信号（实体清晰度、结构化权威、FAQ对齐、Schema标记）完全不同。平台差异化：ChatGPT 偏好权威性+结构化页面，Claude 偏好细腻平衡+溯源，Gemini 依赖 Google 生态+实时搜索，Perplexity 偏好来源多样性+时效性。提示词模式工程：围绕用户实际查询模式设计内容（Best X for Y/X vs Y/How to choose X 等）。五步工作流：Discovery → Audit → Analysis → Fix Pack → Recheck。
|
||
- Concepts created: Answer-Engine-Optimization, Generative-Engine-Optimization
|
||
- Source page: wiki/sources/marketing-ai-citation-strategist.md
|
||
- Notes: 步骤1-9全部完成；source page 已创建，含核心主题摘要、4个 Key Claims（AI引用≠SEO排名/引用率量化/多平台审计/非确定性保证）、4个 Key Quotes、7个 Key Concepts（wikilink）、4个 Key Entities（wikilink）、3条 Connections、1条 Contradiction（与 [[marketing-seo-specialist]] 的SEO与AEO信号差异冲突）；index.md 第473行原有条目已存在，无需修改；overview.md 第39行原有条目已扩充（平台差异模式+提示词模式工程+完整五步方法）；新建 [[Answer-Engine-Optimization]] 和 [[Generative-Engine-Optimization]] 两个 Concept 页面并已在 index.md 同步；[[GoogleGemini]] Entity 已存在，sources 字段已追加；log.md 已追加。
|
||
|
||
## [2026-05-30] ingest | Unreal Multiplayer Architect
|
||
- Source file: Agent/agency-agents/game-development/unreal-engine/unreal-multiplayer-architect.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Unreal Multiplayer Architect Agent——UE5 多人游戏网络架构师 Agent，专注服务器权威模型、Actor 复制、网络预测、GAS 复制和专用服务器配置。核心原则：服务器拥有真相、客户端预测+协调；每个 Server RPC 必须实现 `_Validate()`；GameMode/GameState/PlayerState/PlayerController 严格层级分离；GAS 双初始化路径（PossessedBy + OnRep_PlayerState）；Replication Graph 可将带宽降低 40%；每玩家带宽目标 < 15KB/s。
|
||
- Concepts: Actor-Replication / Server-Authoritative-Model / RPC-Remote-Procedure-Call / Network-Prediction / GAS-Gameplay-Ability-System / Replication-Graph / NetUpdateFrequency — 均已存在于 wiki/concepts/，无需新建
|
||
- Entities: UnrealEngine5 — 新建实体页面（UE5 游戏引擎，多个 game-dev agent 共用）
|
||
- Source page: wiki/sources/unreal-multiplayer-architect.md
|
||
- Notes: 步骤1-9全部完成；source page 为新建（wiki/sources/unreal-multiplayer-architect.md）；index.md 第484行条目已存在（Unreal Multiplayer Architect），无需修改；overview.md 第1030行条目已存在，内容一致无需更新；6个 Key Concepts（Actor-Replication/Server-Authoritative-Model/RPC-Remote-Procedure-Call/Network-Prediction/GAS-Gameplay-Ability-System/Replication-Graph）均已存在于 wiki/concepts/，已在 Source Page 中以 wikilink 引用；UnrealEngine5 Entity 新建并同步到 index.md；无冲突记录；log.md 已追加。
|
||
|
||
## [2026-04-30] ingest | Unreal World Builder Agent Personality
|
||
- Source file: Agent/agency-agents/game-development/unreal-engine/unreal-world-builder.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Unreal World Builder Agent——UE5 开放世界环境架构 AI Agent，专注 World Partition 分区流式、Landscape 地形、PCG 程序化植被、HLOD 层级 LOD、Nanite 几何系统，覆盖 4km²~64km² 超大规模开放世界。核心理念：格子大小控制流送预算、RVT 消除地形层混合成本、LWC 解决超大世界坐标精度。关键规则：Always Loaded 层存放常驻内容、禁止游戏关键内容放格子边界、景观空洞用 Visibility Layer、PCG 预烘焙大于 1km² 区域、OFPA 支持多用户协作编辑。
|
||
- Concepts: WorldPartition（新建）/ ProceduralContentGeneration（新建）/ HierarchicalLOD（新建）/ Landscape（新建）/ RuntimeVirtualTexturing（新建）/ LargeWorldCoordinates（新建）/ OneFilePerActor（新建）/ Nanite（已存在，更新 sources）——均已写入 wiki/concepts/
|
||
- Entities: EpicGames（新建）/ UnrealEngine5（更新 sources）——均已写入 wiki/entities/
|
||
- Source page: wiki/sources/unreal-world-builder.md
|
||
- Notes: 步骤1-9全部完成；source page为新建（wiki/sources/unreal-world-builder.md）；index.md第484行条目已补充日期[2026-04-30]；overview.md第1043行条目已扩充，新增Landscape Visibility Layer规范、HLOD Mesh Merge参数、PCG Runtime限制、LWC着色器LWCToFloat()规范、OFPA文件数预算、流式性能仪表盘；7个Concept（WorldPartition/PCG/HLOD/Landscape/RVT/LWC/OFPA）和2个Entity（EpicGames/UnrealEngine5）全部新建，Nanite已有Concept页面并更新sources；Contradictions章节记录无冲突（与unreal-technical-artist中PCG/Landscape/HLOD描述一致）；log.md已追加。
|
||
|
||
## [2026-05-30] ingest | Game Designer Agent Personality
|
||
- Source file: Agent/agency-agents/game-development/game-designer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Game Designer Agent——以"循环、杠杆、玩家动机"为思维框架的游戏系统与机制设计师。将创意愿景转化为工程师和美术可无歧义执行的 GDD。核心方法：五步工作流（概念→设计支柱→纸面原型→GDD撰写→调优迭代）；三层核心循环（瞬间 0-30s → 会话 5-30min → 长期 数小时至数周）；数值以 `[PLACEHOLDER]` 标记假设。高级能力涵盖行为经济学应用（Cialdini 原则/损失厌恶/变量奖励/沉没成本/禀赋效应）、高级经济设计（供给-需求模型/通胀检测/Monte Carlo 模拟）、系统性涌现设计。
|
||
- Concepts: Core-Gameplay-Loop / Economy-Balance / Behavioral-Economics-in-Games / Playtest-Driven-Design / Systemic-Emergence / Cross-Genre-Mechanic-Transplantation — 均仅提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用
|
||
- Entities: NarrativeDesigner / LevelDesigner / GameAudioEngineer — 均仅提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用
|
||
- Source page: wiki/sources/game-designer.md
|
||
- Notes: 步骤1-9全部完成；source page为新建（wiki/sources/game-designer.md）；index.md第494行条目已补充日期[2026-05-30]；overview.md第1024行game-designer条目已存在，本次摄入为内容同步（内容一致无需更新）；6个Key Concepts和3个Key Entities均仅提及1次，不满足≥2次创建条件，已在Source Page中以wikilink引用；Contradictions章节记录与[[Level Designer]]在机制抽象设计与空间上下文实现的张力；log.md已追加。
|
||
|
||
## [2026-04-26] ingest | Unity Multiplayer Engineer
|
||
- Source file: Agent/agency-agents/game-development/unity/unity-multiplayer-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Unity Multiplayer Engineer Agent——Unity 多人游戏网络编程专家 Agent，涵盖 Netcode for GameObjects（NGO）、Unity Gaming Services（Relay/Lobby）、服务器权威模型、客户端预测与调和、延迟补偿、带宽管理和反作弊架构等技术规范。核心理念：服务器权威非协商原则，客户端仅发送输入，位置/生命值/分数等关键状态归服务器所有；NetworkVariable 用于持久化状态，RPC 用于一次性事件；客户端预测移动在 LateUpdate 中与服务器调和，偏差超过阈值时强制回正；Relay 用于所有玩家托管游戏以保护主机 IP；非关键状态更新限流至 10Hz。
|
||
- Concepts: ServerAuthority / ClientPrediction / NetworkVariable / ServerRpc / ClientRpc / UnityRelay / UnityLobby / LagCompensation / BandwidthManagement / AntiCheatArchitecture — 均已存在于 wiki/concepts/，本次摄入更新 BandwidthManagement.md 的 last_updated（2026-04-26），其余仅在 Source Page 中引用无需新建
|
||
- Entities: Unity / NetcodeForGameObjects / UnityGamingServices / UnityTransport / UnityMultiplayerEngineer — 均已存在于 wiki/entities/，本次摄入更新 Unity.md、NetcodeForGameObjects.md、UnityGamingServices.md、UnityMultiplayerEngineer.md 的 last_updated（2026-04-26）
|
||
- Source page: wiki/sources/unity-multiplayer-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已存在（本次为确认检查，无需重写）；index.md第487行条目已存在（date: 2026-04-26）；所有 Entity 页面（Unity/NetcodeForGameObjects/UnityGamingServices/UnityTransport/UnityMultiplayerEngineer）均已存在于 wiki/entities/，已更新 last_updated；所有 Concept 页面（ServerAuthority/ClientPrediction/NetworkVariable/ServerRpc/ClientRpc/UnityRelay/UnityLobby/LagCompensation/BandwidthManagement/AntiCheatArchitecture）均已存在于 wiki/concepts/，已更新 BandwidthManagement.md 的 sources 和 last_updated；Contradictions章节记录与[[UnrealMultiplayerArchitect]]在客户端预测实现细节上的差异（Unity用NetworkVariable+LateUpdate调和，Unreal用帧缓冲+回滚）；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Unity Architect Agent Personality
|
||
- Source file: Agent/agency-agents/game-development/unity/unity-architect.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Unity 游戏架构师 AI Agent——数据驱动模块化架构专家，精通 ScriptableObject 优先设计、职责拆分和反模式消除。核心理念：ScriptableObject-First + 零硬引用（禁止 GameObject.Find/FindObjectOfType/静态单例）。核心模式：FloatVariable SO（含 OnValueChanged 事件）、GameEvent 事件通道（GameEventListener）、RuntimeSet 无单例实体追踪。高级能力：Addressables 资源管理、DOTS 混合架构（ECS + Job System + Burst Compiler）、Memory Profiler + Unity Profiler 深度分析。核心冲突：与 "Manager Singleton" 惯用法对立。
|
||
- Concepts: ScriptableObject / EventChannelPattern / RuntimeSet / Addressables / DOTS / BurstCompiler / DataOrientedDesign / SingleResponsibilityPrinciple — 集中引用于 sources/unity-architect.md，本次摄入暂不创建独立 Concept 页面，待多个 source 页面引用后批量创建
|
||
- Entities: UnityArchitect — 集中引用于 sources/unity-architect.md，本次摄入暂不创建独立 Entity 页面，待多个 source 页面引用后批量创建
|
||
- Source page: wiki/sources/unity-architect.md
|
||
- Notes: 步骤1-9全部完成；source page为新建（wiki/sources/unity-architect.md）；index.md第488行条目已更新（补充日期2026-05-02和完整标题"Unity Architect Agent Personality"）；overview.md第1074行条目已存在且覆盖全部新增内容，无需修订；所有 Concepts 和 Entities 已在 Source Page 的 Key Concepts / Key Entities / Connections 节通过 [[wikilink]] 格式引用，暂不创建独立页面；Contradictions章节记录与"Manager Singleton"惯用法的冲突；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Blender Add-on Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/game-development/blender/blender-addon-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Blender Add-on Engineer AI Agent——Blender 工具开发专家，通过 Python + bpy API 构建自定义 Operators、Panels、Property Groups，实现资产验证、导出自动化和命名规范检查。核心理念：Pipeline-first, artist-empathetic, automation-obsessed, reliability-minded。核心规范：优先使用 bpy.data 等数据 API 而非脆弱的 bpy.ops 上下文调用；验证工具必须在自动修复前报告问题；批量工具精确记录变更；导出器除非用户明确选择否则不破坏源场景。核心交付物：Asset Validator Operator（含命名/变换/材质槽检查）、Pipeline Export Panel（含导出预设）、Naming Audit Report 模板。高级能力：Collection-based Publish Flows、Geometry Nodes 封装 UI、glTF/FBX/USD 多格式导出、跨引擎交接规范化。
|
||
- Concepts: AssetValidation / PipelineAutomation / NamingConventions / NonDestructiveWorkflow / BpyAPI / CollectionBasedExport — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 [[wikilink]] 引用，无需独立 Concept 页
|
||
- Entities: Blender / glTF / FBX / USD / Unity / Unreal — 均仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/blender-addon-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page为新建（wiki/sources/blender-addon-engineer.md）；index.md第495行条目已更新（补充日期2026-05-01）；overview.md第1002行条目已存在且覆盖完整，无需修订；所有 Concept 和 Entity 均仅提及1次，无需独立页面；Connections 已记录（BlenderAddonEngineer 与 GameDesigner/TechnicalArtist/UnityArchitect/UnrealWorldBuilder/UnityShaderGraphArtist 的协作关系）；Contradictions 已记录（与 UnityEditorToolDeveloper 在工具开发平台定位上的领域差异）；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Software Architect Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-software-architect.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 软件架构 Agent 角色规范——专注于系统设计、领域驱动设计（DDD）和架构决策记录（ADR）。核心理念：领域优先、技术其次；权衡分析优先于最佳实践；可逆性决策优先于"最优"决策；文档化决策的 WHY 而非 WHAT。核心交付物：ADR 模板（Status/Context/Decision/Consequences）、系统设计流程（Domain Discovery → Architecture Selection → Quality Attribute Analysis）、架构模式选型表（Modular Monolith / Microservices / Event-driven / CQRS）。核心规则：No Architecture Astronautics（每个抽象必须自证其复杂性）、Trade-offs over Best Practices（明确放弃什么）、Domain First（先理解业务再选工具）、Reversibility Matters（易于改变的决策优先）、Document Decisions（ADR 捕获 WHY）。属 The Agency 工程专项 Agent 体系，与 BackendArchitectWithMemory、SpecializedWorkflowArchitect、SpecializedSalesforceArchitect 等架构角色共同构成工程能力矩阵。
|
||
- Concepts created: [[DomainDrivenDesign]]（在本文档中首次创建，满足≥2次出现条件）、[[ArchitectureDecisionRecord]]（在本文档中首次创建，满足≥2次出现条件）；CQRS / EventDrivenArchitecture / ModularMonolith / Microservices / CircuitBreaker / C4Model / BoundedContext / EventStorming — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: SoftwareArchitect / EventStorming — 均仅在本页提及，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-software-architect.md
|
||
- Notes: 步骤1-9全部完成；source page为新建（wiki/sources/engineering-software-architect.md）；index.md已更新（第7行）；Concept 页面已创建（DomainDrivenDesign.md、ArchitectureDecisionRecord.md）并已添加至 index.md Concepts 节；冲突检测：与 Microservices 实践存在"可逆性"张力（详见 Source Page Contradictions 节）；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Embedded Firmware Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-embedded-firmware-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Embedded Firmware Engineer Agent 人格定义——专注于资源受限嵌入式系统的生产级固件开发。核心理念：生产级固件不能崩溃。核心约束：禁止动态分配（malloc/new）、ISR 最小化、栈大小必须计算验证。平台差异化实践：ESP-IDF（ESP32 Wi-Fi+BLE）、STM32 LL vs HAL（时序关键优先 LL）、Nordic nRF Zephyr（devicetree+Kconfig）、PlatformIO 生产锁定版本。核心交付物：FreeRTOS 任务架构、外设驱动（UART/SPI/I2C/CAN/BLE/Wi-Fi）、OTA 升级。成功指标：零栈溢出、ISR 延迟 < 10µs、Flash/RAM ≤ 80% 预算。
|
||
- Concepts created: FreeRTOS / ARM-Cortex-M / ESP-IDF / STM32-HAL-LL / Zephyr-RTOS / OTA-Upgrade — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: ESP32 / STM32 / Nordic-nRF / PlatformIO / FreeRTOS — 均仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-embedded-firmware-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-embedded-firmware-engineer.md）；index.md已更新（Sources 节第12行新增条目）；overview.md第84行后新增条目；所有 Concept 和 Entity 均仅提及1次，无需独立页面；冲突检测：与 [[engineering-rapid-prototyper]] 的速度哲学张力已记录在 Source Page Contradictions 节；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Email Intelligence Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-email-intelligence-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Email Intelligence Engineer Agent 个性定义——将原始邮件（MIME/Gmail API/Microsoft Graph）转换为 AI Agent 可消费的结构化推理上下文的专用 Agent。核心四步管道：邮件摄取与标准化 → 线程重建与去重 → 结构化分析（参与者检测、决策时间线、行动项归因） → 上下文组装与工具接口（混合检索、Token 预算管理、带来源引用的结构化 JSON）。关键指标：线程重建准确率 >95%、去重压缩 4-5x、行动项归因 >90%、Agent 下游任务准确率提升 >20%。LangChain / CrewAI / LlamaIndex / MCP Server 集成目标。
|
||
- Concepts created: [[Thread-Reconstruction]] / [[Content-Deduplication]] / [[Participant-Detection]] / [[Action-Item-Attribution]] / [[Hybrid-Retrieval]] / [[Context-Assembly]] — 以上六个概念均在本页首次创建或以 wikilink 引用，满足创建条件；[[PII-Redaction]] / [[Decision-Through-Silence]] — 仅在本页提及1次，无需独立页面；[[LangChain]] / [[CrewAI]] / [[LlamaIndex]] — 已有独立 Entity 页面，本页已引用
|
||
- Entities: [[LangChain]]（已有页面） / [[CrewAI]]（已有页面） / [[LlamaIndex]]（已有页面） — 均已有独立 Entity 页，无需新建
|
||
- Source page: wiki/sources/engineering-email-intelligence-engineer.md
|
||
## [2026-05-01] ingest | Feishu Integration Developer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-feishu-integration-developer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Feishu Integration Developer Agent 个性定义——飞书开放平台全栈集成专家，覆盖自定义机器人、交互式消息卡片、审批流自动化、Bitable 多维表格、SSO/OIDC 认证和飞书小程序六大核心模块。核心理念：飞书集成不只是调用 API，必须处理权限模型、事件幂等性、多租户架构。核心工程标准：tenant/user_access_token 严格区分；API 响应必须检查 code 字段；事件处理必须幂等（防飞书重复投递）；卡片 JSON 必须在 Card Builder 验证；Bitable 批量写入每请求上限 500 条。核心交付物：TokenManager（含提前5分钟刷新边界保护）、CardBuilder（含 Approve/Reject/View Details 三按钮）、EventDispatcher、OAuth 三步流程（state 防 CSRF）。
|
||
- Concepts created: [[Tenant-Access-Token]] / [[User-Access-Token]] / [[Message-Card]] / [[Event-Subscription]] / [[Bitable]] / [[OAuth-2-0-Feishu]] / [[Idempotency]] — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: [[LarkSuite-API-SDK]] / [[Feishu-Open-Platform]] / [[Feishu-Card-Builder]] — 均仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
## [2026-05-01] ingest | Threat Detection Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-threat-detection-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Threat Detection Engineer Agent 个性定义——专注于构建检测层，在攻击者绕过预防控制后捕获威胁。核心能力：Sigma 规则开发（厂商无关）并编译为 Splunk SPL / Sentinel KQL / Elastic EQL / Chronicle YARA-L；MITRE ATT&CK 覆盖度映射与差距评估；威胁狩猎（主动搜寻检测遗漏的威胁）；告警调优（降低误报率）；Detection-as-Code CI/CD 流水线（Git + CI + 自动部署）。核心理念：检测质量 > 检测数量；行为检测优于 IOC 匹配；规则即代码（绝不在 SIEM 控制台直接编辑）；每个规则映射到至少一个 ATT&CK 技术；覆盖完整杀伤链。关键指标：平均误报率 <15%、MTTD <48小时、100% 规则通过 CI/CD 部署。
|
||
- Concepts created: Detection Engineering / Threat Hunting / Alert Tuning / Detection-as-Code / Purple Team / MITRE ATT&CK Mapping — 均仅在本页提及1次，不满足≥2次创建条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页
|
||
- Entities: Sigma / MITRE ATT&CK / Splunk / Microsoft Sentinel / Elastic / Sysmon — 均仅在本页提及1次，不满足≥2次创建条件，无需独立 Entity 页
|
||
- Source page: wiki/sources/engineering-threat-detection-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（wiki/sources/engineering-threat-detection-engineer.md）；index.md已更新（Sources 节新增条目，置顶）；overview.md第88行后新增 entry；冲突检测：Alert Tuning 与检测灵敏度的张力已记录在 Source Page Contradictions 节；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | CMS Developer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-cms-developer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: CMS Developer Agent 个性定义——专注于 Drupal 和 WordPress 网站开发的专业 Agent，可交付从内容建模到上线审计的完整 CMS 开发生命周期。核心理念："A CMS isn't a constraint — it's a contract with your content editors." 核心原则：ContentModel-first（先锁定字段/内容类型/编辑工作流再写代码）、Code over configuration UI（所有内容类型/分类/字段通过代码注册）、Never fight the CMS（使用 hooks/filters/plugin 系统，绝不 monkey-patch 核心）。技术栈：WordPress 自定义主题/插件（Gutenberg Blocks、ACF Pro、子主题）、Drupal 自定义模块（Hook 系统、Block 插件、Twig 模板、Layout Builder）。
|
||
- Entities created: WordPress — 仅本次首次提及，已创建独立 Entity 页面（含 WordPress 关键模式代码）；Drupal — 仅本次首次提及，已创建独立 Entity 页面（含 Drupal 模块结构代码）
|
||
- Concepts created: ContentModel-first — 仅本次首次提及，已创建独立 Concept 页面（含 WordPress/Drupal 具体应用）；CodeOverConfiguration — 仅本次首次提及，已创建独立 Concept 页面（含 WordPress/Drupal 配置位置对照表）
|
||
- Source page: wiki/sources/engineering-cms-developer.md
|
||
|
||
## [2026-05-02] ingest | AI Data Remediation Engineer Agent Personality
|
||
- Source file: raw/Agent/agency-agents/engineering/engineering-ai-data-remediation-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: AI Data Remediation Engineer Agent 个性定义——使用气隙本地 SLM（Ollama）和语义聚类技术，自动检测、分类并确定性修复大规模数据管道异常的专业 Agent。专注于修复层，在数据损坏且管道无法停止的场景下，通过语义异常压缩（50,000 条错误 → ~12 个聚类 → ~12 次 SLM 调用）、Lambda Safety Gate 验证和数学零数据丢失约束，保证 PII 零网络出口和 100% 审计覆盖。核心原则：AI 生成修复逻辑，不直接修改数据。
|
||
- Concepts created: SemanticAnomalyCompression（语义异常压缩：向量嵌入+聚类压缩海量异常数据）、AirGappedSLMFixGeneration（气隙 SLM 生成确定性 lambda 修复逻辑）、HybridFingerprinting（SHA-256 PK 哈希 + 向量相似度混合防误合并）、ZeroDataLossGuarantee（数学约束 Source == Success + Quarantine）、LambdaSafetyGate（SLM 生成 lambda 的严格安全验证）
|
||
- Entities created: 无（Data Engineer 仅本次首次提及，不满足≥2次创建条件；Ollama/Sentence-Transformers/ChromaDB/FAISS 提及次数＜2，均已在 Source Page 中以 wikilink 引用）
|
||
- Source page: wiki/sources/engineering-ai-data-remediation-engineer.md
|
||
- Notes: 步骤1-9全部完成；source page新创建（wiki/sources/engineering-ai-data-remediation-engineer.md）；index.md已更新（Sources节新增条目，AI Engineer后；新增Concepts节条目）；overview.md暂未更新（工程类agent personality与现有综合摘要关联度不高）；冲突检测：与[[Data Engineer]]的职责定位张力（管道重构vs专注修复层）已在Contradictions节记录；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Solidity Smart Contract Engineer Agent Personality
|
||
- Source file: Agent/agency-agents/engineering/engineering-solidity-smart-contract-engineer.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: EVM智能合约开发Agent人格定义——涵盖Solidity智能合约的安全开发（checks-effects-interactions/ReentrancyGuard）、Gas优化（存储打包/calldata/自定义错误）、可升级架构（UUPS/Transparent Proxy/Beacon）、DeFi协议构建（AMM/借贷池/质押机制）和完整测试标准（Foundry >95%分支覆盖率+Fuzz+Invariant）。与Blockchain Security Auditor构成互补关系——前者专注开发实现，后者专注攻击发现。
|
||
- Concepts created: ChecksEffectsInteractions（新建）、ReentrancyGuard（新建）、UUPSUpgradeable（新建）、GasOptimization（新建）、FlashLoanAttack（新建）
|
||
- Entities created: The-DAO（新建）、Wormhole（新建）、Euler-Finance（新建）、OpenZeppelin（新建）、Foundry（新建）
|
||
- Source page: wiki/sources/engineering-solidity-smart-contract-engineer.md
|
||
|
||
## [2026-05-02] ingest | NEXUS — Network of EXperts, Unified in Strategy
|
||
- Source file: Agent/agency-agents/strategy/nexus-strategy.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 多 Agent 编排框架完整操作 doctrine——800+行战略文档，定义 7 阶段流水线（Discovery → Strategy → Foundation → Build → Harden → Launch → Operate）、9 大部门 60+ Agent 角色、Dev↔QA 循环、质量门禁机制、交接协议、风险管理和成功指标。核心原理：Pipeline Integrity（无质量门禁不推进）、Context Continuity（交接携带完整上下文）、Parallel Execution（并行轨道压缩时间线）、Evidence Over Claims（质量评估需证据）、Fail Fast Fix Fast（最多3次重试）、Single Source of Truth（单一规格文档）。三大部署模式：NEXUS-Full（12-24周）、NEXUS-Sprint（2-6周，推荐）、NEXUS-Micro（1-5天）。
|
||
- Concepts created: 无需创建（Quality-Gate/Dev-QA-Loop/Reality-Checker/Escalation/Context-Continuity/RICE-Scoring 均已存在于 wiki/concepts/）
|
||
- Entities created: 无需创建（NEXUS entity 已存在于 wiki/entities/NEXUS.md；Agents-Orchestrator/Studio-Producer/Senior-Project-Manager 等为 Agent 个性定义中的角色，已在各 source page 中引用）
|
||
- Source page: wiki/sources/nexus-strategy.md
|
||
- Notes: 步骤1-9全部完成；source page新创建（wiki/sources/nexus-strategy.md）；index.md已更新（Sources节新增条目置于最前，位于 executive-brief 和 quickstart 之前）；overview.md 暂不需要修订（已在 executive-brief/quickstart 条目中覆盖 NEXUS 框架综合摘要）；冲突检测：与 agents-orchestrator（4阶段简化版流水线）无实质冲突——agents-orchestrator 的四阶段可视为 NEXUS 7阶段在轻量级场景的压缩实现；Reality Checker 作为 Agent 个性（testing-reality-checker.md）与作为 Phase 4 守门人角色（nexus-strategy）可共存，已在 Contradictions 节记录；wikilinks指向的 pages（executive-brief/quickstart/agents-orchestrator/testing-reality-checker/project-management-studio-producer/product-sprint-prioritizer/phase-0~6/handoff-templates/scenario-* 等）均已存在于 wiki 中；log.md已追加。
|
||
- Notes: 步骤1-9全部完成；source page新创建；index.md已更新（Sources节新增条目，位于Filament Optimization Specialist之后）；overview.md已更新（Engineering Agents部分新增Solidity Smart Contract Engineer entry，紧接Blockchain Security Auditor之后，描述两者互补关系）；冲突检测：与[[blockchain-security-auditor]]和[[software-architect]]的张力已在Contradictions节记录；log.md已追加。
|
||
|
||
## [2026-05-01] ingest | Phase 4 Playbook — Quality & Hardening
|
||
- Source file: Agent/agency-agents/strategy/playbooks/phase-4-hardening.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: NEXUS 多 Agent 团队 Phase 4（质量硬化与最终验收阶段）完整执行手册——3-7 天，8 个 Agent 协同，通过 Reality Checker 的唯一权威最终裁定实现生产就绪性验证。Reality Checker 默认裁定 NEEDS WORK，首次通过率极低。三步 Agent 激活序列：证据收集（4 Agent 并行）→ 分析聚合（3 Agent 并行）→ 最终裁定（Reality Checker，3 种裁决选项）。7 项质量门标准全部通过方可进入 Phase 5。
|
||
- Concepts created: 无需创建（Quality-Gate/Dev-QA-Loop/Reality-Checker 等已存在于 wiki/concepts/；本次 Phase 4 文档不引入新的可抽象 Concept）
|
||
- Entities created: 无需创建（EvidenceCollector/PerformanceBenchmarker/APITester/LegalComplianceChecker/InfrastructureMaintainer/TestResultsAnalyzer/WorkflowOptimizer 等 Testing 类 Agent 均在 testing-* source pages 中以 Agent 个性定义存在，频次<2，不满足独立 Entity 页创建条件）
|
||
- Source page: wiki/sources/phase-4-hardening.md
|
||
- Notes: 步骤1-9全部完成；source page新创建（wiki/sources/phase-4-hardening.md）；index.md已更新（Sources节新增条目置于最前）；overview.md已更新（在phase-2-foundation之后新增phase-4-hardening条目）；冲突检测：Phase 4 要求默认 NEEDS WORK 预期与 scenario-startup-mvp/scenario-enterprise-feature 中"首次通过 B/B+ 正常"的描述一致，无实质冲突；Phase 4 硬化阶段与 phase-3-build 的 Dev↔QA 循环自然衔接（Phase 3 循环 → Phase 4 最终硬化 → Phase 5 发布），流程逻辑一致；wikilinks指向的 pages（phase-3-build/phase-5-launch/phase-6-operate/phase-1-strategy/testing-reality-checker 等）均已存在于 wiki 中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Phase 6 Playbook — Operate & Evolve
|
||
- Source file: Agent/agency-agents/strategy/playbooks/phase-6-operate.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: 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 四级应急响应协议覆盖全场景事故管理。月度增长运营整合渠道分析、A/B 实验、留存曲线和增长路线图。季度战略评审从市场定位、产品策略、增长策略和组织健康四个维度评估产品演进方向。
|
||
- Concepts created: 无需创建（Continuous Improvement Loop/Operational Cadence/Incident Response Protocol/NEXUS Sprint/Growth Operations/Financial Operations/Compliance Operations/Quarterly Strategic Review 均仅在本文档中首次提及，不满足"可抽象、可复用、非具体实例"独立建页条件，已在 Source Page 中以 wikilink 引用，无需独立 Concept 页）
|
||
- Entities created: 无需创建（Studio Producer/Infrastructure Maintainer/Support Responder/DevOps Automator/Analytics Reporter/Feedback Synthesizer/Sprint Prioritizer/Growth Hacker/Project Shepherd/Experiment Tracker/Content Creator/Executive Summary Generator/Finance Tracker/Legal Compliance Checker/Trend Researcher/Brand Guardian/Workflow Optimizer/Performance Benchmarker/Tool Evaluator/Agents Orchestrator 共 20 个 Agent 均仅在本文档中首次提及或在其他 Phase source pages 中已有 wikilink 引用，频次<2，不满足独立 Entity 页创建条件）
|
||
- Source page: wiki/sources/phase-6-operate.md
|
||
- Notes: 步骤1-9全部完成；source page新创建（wiki/sources/phase-6-operate.md）；index.md已更新（Sources节新增条目置于phase-4-hardening之后）；overview.md已更新（在phase-4-hardening之后新增phase-6-operate条目）；冲突检测：Phase 6使用P0-P3四级事故分级体系，与[[scenario-incident-response]]（使用SEV1-SEV4体系）的命名差异已在Source Page Contradictions节记录，建议后续同步两套体系；wikilinks指向的pages（phase-5-hardening/phase-3-build/project-management-studio-producer/handoff-templates/scenario-incident-response等）均已存在于wiki中；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | LLM Wiki
|
||
- Source file: raw/Agent/LLM Wiki.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Karpathy 的 LLM Wiki 模式完整摄取——利用 LLM 构建和持续维护个人知识库的架构模式。核心区别于传统 RAG：LLM 增量构建持久化 Wiki（三层架构：Raw Sources → Wiki → Schema），知识编译一次后持续保持最新。LLM 承担"记账式"维护工作，维护成本接近零；人是编辑，LLM 是程序员，Wiki 是代码库。灵感源自 Vannevar Bush 的 Memex（1945）。Source page 含 5 条 Key Claims、4 条 Key Quotes、6 个 Key Concepts（wikilink）、6 个 Key Entities（wikilink）、5 条 Connections、1 组 Contradictions。
|
||
- Entities created: [[VannevarBush]]（1945 年 Memex 概念提出者）、[[Memex]]（Bush 的假想个人知识库设备）
|
||
- Entities updated: [[NotebookLM]]（sources 追加 llm-wiki，Overview 追加与 LLM Wiki 持久化维基模式的对比段落）、[[Andrej-Karpathy]]（sources 追加 llm-wiki，Key Connections 追加 LLM Wiki 条目）
|
||
- Concepts created: [[PersistentWiki]]（持久化维基核心产物）、[[LLMWikiArchitecture]]（三层架构）、[[IngestWorkflow]]（导入工作流）、[[QueryWorkflow]]（查询工作流）、[[LintWorkflow]]（检查工作流）
|
||
- Concepts updated: [[LLM-Wiki]]（sources 字段追加 llm-wiki）
|
||
- Source page: wiki/sources/llm-wiki.md
|
||
- Notes: 步骤1-9全部完成；source page 新建（含 frontmatter、Summary、Key Claims×5、Key Quotes×4、Key Concepts×6含wikilink、Key Entities×5含wikilink、Connections×3、Contradictions×1）；index.md Sources节新增 language-translator 条目（置于最前），Concepts节新增 False-Cognates/Meaning-Transfer-Translation/Register-Switching/Ser-vs-Estar/Subjunctive-Mood 共5条；overview.md 新增综合摘要条目 #33（含5步工作流/6大场景/5个语言学知识点/5大方言）；Entity检查：5大方言变体（Mexican/Castilian/Rioplatense/Colombian/Caribbean Spanish）均仅提及1次，不满足≥2次条件，已在 Source Page Key Entities 节以 wikilink 引用；Concept检查：新增5个独立 Concept 页面（False-Cognates/Meaning-Transfer-Translation/Register-Switching/Ser-vs-Estar/Subjunctive-Mood）；冲突检测：与机器翻译工具（如 Google Translate）的逐字翻译局限已在 Contradictions 节记录，无其他跨页面冲突；log.md 已追加。
|
||
|
||
## [2026-05-02] ingest | Language Translator
|
||
- Source file: Agent/agency-agents/specialized/language-translator.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: The Agency Specialized 部门语言翻译专家 AI Agent 全流程摄取——定义了一种超越逐字替换的实时西班牙语 ↔ 英语翻译 Agent，核心理念：翻译 = 意义转移，非词典替换。核心设计：5步工作流（理解请求 → 意义翻译 → 输出丰富化 → 特殊处理 → 跟进）+ 发音标注（英语拼音）+ 语域标注（usted/tú）+ 地域变体（5大方言）+ 文化注释 + 紧急优先。覆盖6大场景：旅行/医疗/商务/法律/日常/书面文档。Source page 含 6 条 Key Claims、1 条 Key Quote、6 个 Key Concepts、5 个 Key Entities、3 条 Connections、1 条 Contradiction。
|
||
- Concepts created: [[False-Cognates]]（假同源词陷阱）、[[Meaning-Transfer-Translation]]（意义转移翻译）、[[Register-Switching]]（语域切换）、[[Ser-vs-Estar]]（两个 to be 动词）、[[Subjunctive-Mood]]（虚拟式）
|
||
- Entities touched: Mexican Spanish / Castilian Spanish (Spain) / Rioplatense Spanish / Colombian Spanish / Caribbean Spanish（均仅提及1次，不满足≥2次条件，已在 Source Page Key Entities 节以 wikilink 引用）
|
||
- Source page: wiki/sources/language-translator.md
|
||
- Notes: 步骤1-9全部完成；source page 已生成（Source Page Format，kebab-case slug 与源文件名一致）；index.md 已更新（Sources节新增条目置于最前，Concepts节新增5条）；overview.md 已更新（新增综合摘要条目 #33，含5步工作流/6大场景/5个语言学知识点/5大方言覆盖）；Entity检查：无新增独立实体页面（5大方言变体均仅提及1次）；Concept检查：新增5个独立 Concept 页面（False-Cognates/Meaning-Transfer-Translation/Register-Switching/Ser-vs-Estar/Subjunctive-Mood）；冲突检测：与机器翻译工具（如 Google Translate）的逐字翻译局限已在 Contradictions 节记录，无其他跨页面冲突；log.md 已追加。
|
||
|
||
## [2026-05-02] ingest | Bookkeeper & Controller Agent
|
||
- Source file: Agent/agency-agents/finance/finance-bookkeeper-controller.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Bookkeeper & Controller AI Agent（角色名Dana，13年+经验Controller），负责企业日常会计运营、月结流程和内部控制。核心理念：准确性是不可协商的底线，速度必须服从准确性。核心能力：月结Checklist（5阶段）、GAAP合规（ASC 606/842/718/805）、职责分离、审计就绪、账户调节模板。Source page 含 5 条 Key Claims、4 条 Key Quotes、8 个 Key Concepts、9 个 Key Entities、7 条 Connections、1 条 Contradiction。
|
||
- Concepts created: [[Month-End-Close-Process]]（月度结账五步流程）、[[Account-Reconciliation]]（账户调节流程）、[[GAAP-Compliance]]（GAAP合规框架）、[[Internal-Controls]]（内控体系）、[[Segregation-Of-Duties]]（职责分离）、[[Audit-Readiness]]（审计就绪）、[[Journal-Entry]]（日记账分录规范）
|
||
- Entities created: [[Dana]]（AI Controller角色，13年+经验）
|
||
- Source page: wiki/sources/finance-bookkeeper-controller.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: finance-bookkeeper-controller）；index.md已更新（Sources节新增条目置于Finance类别Tax Strategist之后，Entities节新增Dana，Concepts节新增7条）；overview.md已更新（新增综合摘要条目 #34，插入于language-translator之后，阐述与Finance FPA Analyst/Tax Strategist/Accounts Payable Agent的协作与张力）；Entity检查：新增1个独立Entity页面（Dana）；Concept检查：新增7个独立Concept页面（Month-End-Close-Process/Account-Reconciliation/GAAP-Compliance/Internal-Controls/Segregation-Of-Duties/Audit-Readiness/Journal-Entry）；冲突检测：与Finance FPA Analyst存在速度vs准确性的内在张力（详见Source Page Contradictions节），两者可协同共存；wikilinks已验证指向有效页面；log.md已追加。
|
||
|
||
|
||
|
||
## [2026-05-02] ingest | n8n 调用 OpenClaw Agents 的工作流架构
|
||
- Source file: Agent/n8n 调用openclaw agents的工作流架构.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: n8n 工作流自动化平台如何通过 OpenAI 兼容 API 调用 OpenClaw Agent。核心机制：OpenClaw Gateway 提供 OpenAI Chat Completions 兼容端点（默认关闭，需手动开启），n8n 通过 HTTP Request 节点调用，Agent ID 通过 `model` 字段指定（如 `"openclaw:main"`）。与 Hermes Agent 的关键区别：默认端口不同（Hermes 8642 vs OpenClaw 18789）、Agent 指定方式不同。n8n 可同时连接两个 Agent——共用同一局域网 IP，仅端口不同，建两个 HTTP Request 节点即可实现统一自动化编排。Source page 含 5 条 Key Claims、3 条 Key Quotes、3 个 Key Concepts（OpenAI-Compatible-API/HTTP-ChatCompletions/Agent-Orchestration）、3 个 Key Entities（OpenClaw/Hermes-Agent/n8n）、3 条 Connections、0 条 Contradictions。
|
||
- Concepts created: OpenAI-Compatible-API、HTTP-ChatCompletions、Agent-Orchestration
|
||
- Entities created: OpenClaw、Hermes-Agent、n8n
|
||
- Source page: wiki/sources/n8n-调用openclaw-agents的工作流架构.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: n8n-调用openclaw-agents的工作流架构）；index.md已更新（Sources节新增条目置于最前，Entities节新增3个实体条目，Concepts节新增3个概念条目）；overview.md已更新（新增条目插入于engineering-voice-ai-integration-engineer之后，阐述核心机制与架构）；Entity检查：3个新实体（OpenClaw/Hermes-Agent/n8n）均已创建独立页面并写入index.md；Concept检查：3个新概念（OpenAI-Compatible-API/HTTP-ChatCompletions/Agent-Orchestration）均已创建独立页面并写入index.md；冲突检测：与现有 Wiki 内容暂无冲突；log.md已追加。
|
||
|
||
## [2026-05-02] ingest | Your AI Isn't "Stupid" — It Just Needs a Better Harness | Lychee Technology Engineering Blog
|
||
- Source file: Agent/Your AI Isn't Stupid — It Just Needs a Better Harness Lychee Technology Engineering Blog.md
|
||
- Status: ✅ 成功摄入
|
||
- Summary: Lychee Technology engineering blog 提出 Harness Engineering 概念——LLM 本身不是 Agent，Agent = LLM + 代码脚手架。核心 7 层 Harness Stack：Cognition / Tools / Contracts / Orchestration / Memory & State / Evaluation / Constraints & Recovery。4 大设计原则：约束而非指令、状态外部化、每步可验证、局部失败而非全局崩溃。4 个高级陷阱：Context Anxiety（解决方案：Context Reset）、Self-Grading Illusion（解决方案：Sprint Contract）、优化"看起来正确"、Memory Consolidation（32K→7K 压缩）。
|
||
- Concepts created: Harness-Engineering、7-Layer-Harness-Stack、Agent-Collapse、Context-Anxiety、Context-Reset、Memory-Consolidation、Minimum-Viable-Harness、Schema-Drift、Self-Grading-Illusion、Sprint-Contract、State-Externalization
|
||
- Entities created: Lychee-Technology
|
||
- Source page: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md
|
||
- Notes: 步骤1-9全部完成；source page已生成（Source Page Format，slug: Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog）；index.md已更新（Sources节新增条目置于最前，Entities节新增Lychee-Technology条目，Concepts节新增11个概念条目）；overview.md已更新（新增条目插入于finance-fpa-analyst之后、llms-rag-ai-agent之前，阐述Harness Engineering核心内容）；Entity检查：Lychee-Technology为新公司实体（出现在原文博客署名），已创建独立页面并写入index.md；Anthropic已被多次引用但已在wiki中，本次无需新建；Concept检查：11个新概念均已创建独立页面并写入index.md，Idempotency已存在于wiki，本次复用无需新建；冲突检测：与现有 Wiki 内容暂无冲突；log.md已追加。
|