diff --git a/ishenwei/blogwatcher/2026-05-01.md b/ishenwei/blogwatcher/2026-05-01.md
new file mode 100644
index 00000000..67cbd5c5
--- /dev/null
+++ b/ishenwei/blogwatcher/2026-05-01.md
@@ -0,0 +1,330 @@
+
+## 📦 新增 95 篇 (06:01:37)
+
+### 【Tech With Tim - YouTube】
+
+- [The State of Software Engineering in 2026](https://www.youtube.com/watch?v=WOPIoZuD1og)
+  Stop paying hundreds of dollars for multiple AI subscriptions when you can access the same models and features from nexos.ai: https://nexos.ai/twt In ...
+
+### 【Jon Law - YouTube】
+
+- [This AI Generates Production-Ready 3D Models From a Single Image | How to Use Tripo AI P1.0](https://www.youtube.com/watch?v=i74P93Ta3PM)
+  Get a Discount on Tripo: https://studio.tripo3d.ai/home? invite_code=AT2G6Q&utm_source=youtube&utm_medium=kol&utm_campaign=kol_JonLawUsers who sign up...
+
+### 【TEDx Talks - YouTube】
+
+- [I cured 1,000 blind people—then learned the real problem | Jeffrey Levenson | TEDxJacksonville](https://www.youtube.com/watch?v=-pfSAnluhVo)
+  What if preventable blindness isn’t a medical failure—but a systemic one? This is the story of 25 million Americans trapped in a healthcare gap, and t...
+
+- [So you're a sophomore, what now? | Briana Wheeler | TEDxMurfreesboro](https://www.youtube.com/watch?v=J0tH33ITjfo)
+  Professional athletes, musicians, and 15-year-olds all share one fear: the sophomore slump. High school English teacher Brianna Wheeler draws on three...
+
+- [Success Redefine | Beyond the Finish Line and False Labels | Joyce Wang | TEDxRDFIS Youth](https://www.youtube.com/watch?v=qScx16ABlz0)
+  Joyce's story is one of "breaking and rebuilding". An unexpected wrist fracture caused the identity she had built on "perfection" and "victory" to cru...
+
+- [The Option of Art | Omair Rana | TEDxKingston College Lahore](https://www.youtube.com/watch?v=qkFRdg97qac)
+  The Option of Art explores art not just as a discipline, but as an essential way of living. It highlights how art shapes our perspectives, fuels creat...
+
+- [Build brave spaces where people can bloom | Kara Kemp | TEDxMurfreesboro](https://www.youtube.com/watch?v=N4mgvpMCr0s)
+  The story we tell about ourselves is often the hardest one to start. As a storytelling coach with nearly two decades of experience, Kara Kemp knows th...
+
+- [SUCCESS Not A Mountain, but An Open Field | Yiran Han | TEDxRDFIS Youth](https://www.youtube.com/watch?v=5ZI0xIJzqPQ)
+  Angeline, through the bliss of losing herself in creating a 10-second melody, and the inner peace of running freely on the playground before exams, di...
+
+- [How We Break Vicious Cycles for Animals, and for Ourselves | Thea Xuan | TEDxRDFIS Youth](https://www.youtube.com/watch?v=kVZ9eL4s-jM)
+  Involution does not only take a toll on human beings, but also drags animals into the cruel system built by humans to satisfy their own needs. Taking ...
+
+- [Anti-Involution: Redefine Success | Teodora Raicevic | TEDxRDFIS Youth](https://www.youtube.com/watch?v=yeh32f4cASc)
+  Teodora opens with the fable of "the eagle that strayed into a flock of chickens", a vivid metaphor for the universal dilemma of people losing themsel...
+
+- [THE PATH TO SUCCESS: FROM INVOLUTION TO INNOVATION | Snow Dong | TEDxRDFIS Youth](https://www.youtube.com/watch?v=I-Z2t963KTA)
+  Snow uses the economic metaphor of the "Red Ocean" and the "Blue Ocean" to argue that the key to success lies not in how much effort you put in, but i...
+
+- [ANTI-INVOLUTION | REDEFINE SUCCESS | Cheryl Dublar | TEDxRDFIS Youth](https://www.youtube.com/watch?v=HiOQpgoqBgI)
+  Dr. Cheryl Dublar, as an educator, offers a profound analysis of the widespread "involution" dilemma in modern education and life: a vicious cycle whe...
+
+### 【灵姐说AI | Ling Talk AI - YouTube】
+
+- [GPT Image2 太猛了：不只是图好看，而是在替你做视觉创意引擎 ｜ Open AI](https://www.youtube.com/watch?v=YJTtek7IL2E)
+  GPT Image2 惊艳了！它已经不只是“图好看”这么简单，而是在替内容创作者、设计师、电商从业者和AI玩家，搭建一个真正可复用的视觉创意引擎。这期视频我会结合自己的实测过程，分享 GPT Image2 这次升级最关键的变化：为什么它不只是生图模型，而是开始具备“先想再画”的任务理解能力；为什么它...
+
+### 【Greyson Zhang - YouTube】
+
+- [【別再用錯音樂了】5個YouTube無版權音樂網站｜最後一個超神](https://www.youtube.com/watch?v=w0hJTOvvC5Q)
+  加入最好的創作者成長搞錢社群 👉 https://www.greysonzhang.com/membership免費公開課｜2026 YouTube 成長藍圖 👉 https://www.greysonzhang.com/2026-yt一對一咨詢 👉 https://calendly.com/gre...
+
+### 【李哈利Harry - YouTube】
+
+- [AI工具排行榜大公開！從神級到最爛全實測（這幾個真的別再用…）](https://www.youtube.com/watch?v=kQa60ouw4XY)
+  🌟 加入AI大師社群並運用AI創業賺錢：https://www.skool.com/aiagent/about?ref=f2b566934c5c4639aaa47ab1fe39310e📌 加入我的免費 Skool 社群，獲取模板：https://www.skool.com/aiagent8/abou...
+
+### 【Coursera - YouTube】
+
+- [How Cosmetic Products Go From Idea to Market](https://www.youtube.com/watch?v=DVCEmmsporY)
+  Bringing a cosmetic product to market requires more than a great idea. This lecture explores how proof of concept, market research, financial planning...
+
+- [How Data Poisoning Breaks AI Models](https://www.youtube.com/watch?v=6WbcDKoJP9M)
+  Modern AI systems are powerful, but they’re not immune to hidden risks. A recent study revealed that inserting just a few hundred malicious documents ...
+
+- [Principles of Cosmetic Product Design](https://www.youtube.com/watch?v=BpxdNA3_bKY)
+  What makes a cosmetic product truly stand out? This lecture explores the key principles of cosmetic product design—from understanding consumer needs a...
+
+- [What Does a Marketing Automation Specialist Do?](https://www.youtube.com/watch?v=e8zVVt0oeU8)
+  Marketing automation is transforming how businesses connect with customers—and creating exciting new career opportunities in the process. This video e...
+
+- [This New Tech Career Is Blowing Up (And No One’s Talking About It)](https://www.youtube.com/watch?v=es3rKst6YCs)
+  Wellness tech consultants are shaping the future of health—using data from wearables, AI, and behavior science to help people improve performance, red...
+
+### 【零度解说 - YouTube】
+
+- [OpenClaw 免费接入 GPT Images 2.0 最强AI图片模型！无需 API Key、不耗 Token，5 分钟搞定！ | 零度解说](https://www.youtube.com/watch?v=5g1AJwNNdwg)
+  【更多资源】▶https://bittly.cc/lingdu【零度博客】▶https://www.freedidi.com【加入会员】▶https://www.youtube.com/channel/UCvijahEyGtvMpmMHBu4FS2w/join【高级会员】▶https://bittl...
+
+### 【Bloomberg Originals - YouTube】
+
+- [How NFL Legend Steve Young Built a $10 Billion Fund | The Deal](https://www.youtube.com/watch?v=e4rTYZYRGao)
+  Alex Rodriguez and Jason Kelly sit down with three-time Super Bowl champion Steve Young to discuss the challenges faced and lessons learned on his jou...
+
+- [Humanoid Robots and the Gap Between Hype and Reality | Bloomberg Primer](https://www.youtube.com/watch?v=UQZooauU-FQ)
+  Humanoid robots that use AI are moving from viral videos to real-world work. From artificial intelligence training and data gaps to factory trials and...
+
+### 【Reuters - YouTube】
+
+- [Court filings raise questions over who shot officer at press dinner](https://www.youtube.com/watch?v=VYvoAcxcEx4)
+  Court filings raised questions about officials' initial assertions that a gunman shot a Secret Service officer while allegedly attempting to assassina...
+
+- [Brazil's Abrolhos corals drop 15% as climate warms](https://www.youtube.com/watch?v=KhqaRJFOGXw)
+  Coral cover on Brazil's Abrolhos reefs, the most biodiverse coral ecosystem in the South Atlantic, fell by around 15% over 18 years due to climate cha...
+
+- [Comey prosecution over seashell post is flawed, experts say](https://www.youtube.com/watch?v=7aO_HBvAFfA)
+  Legal experts say the indictment of former FBI director James Comey over an Instagram post reading '86 47' is fundamentally flawed and would be dismis...
+
+- [US inflation jumps as fuel prices surge; economy grows in Q1](https://www.youtube.com/watch?v=K0-fp8P-gkE)
+  US inflation accelerated in March as the Iran war raised gas prices, bolstering financial market expectations that the Federal Reserve could keep inte...
+
+- [Iran's economy strains under Gulf standoff but holds for now](https://www.youtube.com/watch?v=dYzTTDovGB8)
+  How well is the Iranian economy faring after weeks of conflict, closure of the Strait of Hormuz and a US blockade on its ports? A calamity, while loom...
+
+- [House approves $70 billion more in immigration enforcement](https://www.youtube.com/watch?v=442Ds1g2nUY)
+  The US House of Representatives approved a three-year budget plan that would pave the way for Congress to consider an additional $70 billion for immig...
+
+- [UK's Starmer says Jews are scared, vows action after stabbings](https://www.youtube.com/watch?v=nYGFXLYC3P8)
+  UK Prime Minister Keir Starmer vowed to protect the Jewish community and raised the country's national terrorism threat level to 'severe' from 'substa...
+
+- ['The Brady Bunch' home opens as immersive LA experience](https://www.youtube.com/watch?v=8LCb-TioSYU)
+  'The Brady Bunch' home was transformed into an immersive experience in Los Angeles, letting fans open the fridge, sit on the furniture and walk up the...
+
+- [FCC chair denies White House pressure in Disney review](https://www.youtube.com/watch?v=CRd1hmPDz-Y)
+  FCC Chair Brendan Carr denied the White House pressured him to launch an early license review of Disney's eight ABC television stations, which was ann...
+
+- [Israel quietly expands control to two thirds of Gaza, maps show](https://www.youtube.com/watch?v=KwXhzIUOOg4)
+  Israel quietly issued new maps that show its forces now control nearly two-thirds of Gaza, with a new orange line extending beyond the area agreed to ...
+
+### 【BBC News 中文 - YouTube】
+
+- [《穿Prada的惡魔2》歧視亞裔爭議發酵 台港觀眾怎麼看？－ BBC News 中文](https://www.youtube.com/watch?v=Ni2Q-EDYCiM)
+  美國電影《穿著Prada的惡魔2》週四（4月29日）在亞洲多地上映。這部相隔20年開拍續集的話題之作，在公映前發佈的預告片中，一位名叫「Jin Chao」的亞裔女配角現身，被輿論質疑歧視及強化亞裔的刻板印象。這個短短十多秒的鏡頭在中港台以至日韓等地區引發爭議，甚至出現抵制電影的聲浪。BBC中文記者在...
+
+- [台灣如何陷於中美角力之間？－ BBC News 中文](https://www.youtube.com/watch?v=KBfd1sozIhw)
+  美國總統特朗普將於5月14日訪問中國，這是他自2017年以來首次踏上北京。對中國而言，台灣問題始終是其與美國關係中最重要、也最敏感的議題。台灣是一個擁有2300萬人口的島嶼，具備自己的政府體制，但至今仍未被世界多數國家正式承認為一個國家。數十年來，台灣一直處於兩大力量之間：一方是地理位置最近的中國，...
+
+### 【理想生活实验室】
+
+- [实验室带你过假期：2026.5.1 - 5.5 成都篇](http://www.toodaylab.com/84017)
+  成都的同学们，五一假马上就要来了，已经计划了去哪里远行了吗？如果是准备在城市里好好休整一下，避开出城的“川 A 大军”，那么我们身边也同样有一些好去处值得去看看，无论自己随便逛逛，还是和家人、孩子一起出来走走，这些目的地都可以留意。首先当然是最近我们打卡过的乐高桃花源主题限时活动了。这是个限时空间，...
+
+- [五一入梦万花奇境，乐高品牌在成都太古里创造了一片“桃花源”](http://www.toodaylab.com/84015)
+  五一小长假即将到来，大家会有怎样的安排？对于人在成都的同学们来说，当下已经有一个值得一去的目的地了——在成都太古里，乐高品牌带来了一座“桃花源”，这个快闪空间从 4 月 24 日开始，将持续到 5 月 8 日。当深受大众青睐且具有治愈感的乐高花植系列，来到了也许是中国最闲适好耍的城市——成都，此次乐...
+
+- [一加 Ace 6 至尊版发布，天玑 9500 领衔，要打造最极致的射击游戏体验](http://www.toodaylab.com/84016)
+  4 月 28 日晚，一加举行线上发布会，正式带来一加 Ace 6 至尊版。这是一加 Ace 6 系列的又一款续作，新品延续了“游戏性能旗舰”的定位，同时配置做出了差异，并体现了当下这个时间点上一加对于产品与行业最新的理解。设计上，一加 Ace 6 至尊版有“王牌觉醒”和“金属风暴”两款配色，前者采用...
+
+- [今日消费资讯：《V 世代》被砍、崔然竣成为 Miu Miu 品牌挚友](http://www.toodaylab.com/84014)
+  《V 世代》被砍据 The Hollywood Reporter 4 月 25 日报道，亚马逊已确认《黑袍纠察队》的衍生剧《V 世代》（Gen V）被砍。《V 世代》第一季有着出色的反响，第二季在 2025 年 10 月 22 日播完，但收视数据未达预期，这次官宣将意味着这部剧不再有第三季。《V 世...
+
+### 【阿榮福利味 - 免費軟體下載】
+
+- [[正版購買] Camtasia 26.1.2.16723 - 電腦螢幕錄影兼影片編輯軟體](https://www.azofreeware.com/2018/03/camtasia.html)
+  電腦螢幕錄影兼影片編輯軟體 - Camtasia，讓新手也能製作出專業級的影片，簡單三大步驟輕鬆製作：螢幕錄製 - 全螢幕或單獨的視窗、加入影片或圖片及聲音、插入 PowerPoint 簡報檔，編輯影片：利用方便的時間軸功能、合併或剪裁影片、加速或放慢影片播放、立即預覽，加入特效：加入高亮顯示、動畫...
+
+- [Clippy 1.6.11 - 支援同步的電腦剪貼簿軟體](https://www.azofreeware.com/2025/12/clippy.html)
+  支援同步的電腦剪貼簿軟體 - Clippy，可以記錄文字、圖片、檔案類型的剪貼簿內容，支援點對點加密、可以同步到雲端（例如：Google Drive），可以自訂快速鍵、深色或淺色模式、智慧搜尋、用快速鍵輸入剪貼簿內容、收錄喜愛的剪貼簿內容。（阿榮福利味） 下載連結→ https://www.azof...
+
+- [[正版購買] Tenorshare iCareFone 9.4.2 中文版 - 取代 iTunes 的蘋果手機檔案管理軟體](https://www.azofreeware.com/2020/01/tenorshare-icarefone.html)
+  取代 iTunes 的蘋果手機檔案管理軟體 - Tenorshare iCareFone，不需要安裝「iTunes」，就可以在 iPhone 手機跟電腦之間進行檔案傳輸，把手機照片匯出到電腦上，手機照片、影片、音樂、簡訊、通訊錄、程式資料備份到電腦，快速刪除 iPhone 或 iPad 中的任何資料...
+
+- [LibreWolf 150.0.1-1 免安裝中文版 - 強調隱私與安全的網頁瀏覽器](https://www.azofreeware.com/2025/10/librewolf.html)
+  強調隱私與安全的網頁瀏覽器 - LibreWolf，修改自開放原始碼的火狐瀏覽器，主要目標是隱私、安全性、使用者自由，加強對追蹤與指紋技術的防護與安全改進，移除所有遙測（telemetry）、資料收集及干擾，並停用如 DRM 等反自由功能。（阿榮福利味） 下載連結→ https://www.azof...
+
+- [Dropbox 248.4.3576 離線安裝繁體中文版 - 全自動檔案同步軟體](https://www.azofreeware.com/2011/08/dropbox-1135.html)
+  簡單易用的同步工具 - Dropbox，安裝時會自動於選取的路徑產生「Dropbox」資料夾，而只要移到這個資料夾中任何檔案或資料夾都會即時自動同步到 Dropbox 網站，而殺手級的應用就是拿來實現 A 電腦跟 B 電腦的檔案自動同步，不管走到哪，「Dropbox」資料夾變成你的「行動資料夾」，還...
+
+- [3DP Chip 26.04 免安裝中文版 - 羽量級驅動程式下載軟體](https://www.azofreeware.com/2012/01/3dp-chip-1112.html)
+  驅動程式下載工具 - 3DP Chip，自動偵測你的電腦硬體規格（CPU、主機板、顯示卡、音效卡），直接按設備名稱，就能夠連到該軟體的網站下載適合的驅動程式，可以省去找驅動程式的時間。（阿榮福利味） 下載連結→ https://www.azofreeware.com/p/3dp-chip.html ...
+
+- [Horodruin 2026.04.840.0 免安裝版 - 將多個資料夾內容同步為一樣的免費軟體](https://www.azofreeware.com/2025/06/horodruin.html)
+  將多個資料夾內容同步為一樣的免費軟體 - Horodruin，先將要同步的資料夾一個一個加入，再分析資料夾內容（Sources→Analyze），最後按下內容同步（Sources→Synchornize），就可以將所有資料夾內的檔案變成全部一樣，還可以儲存為專案，以便隨時切換執行不同的同步任務。（阿...
+
+### 【Engadget - Technology News & Expert Reviews】
+
+- [Meta says it may withdraw its apps from New Mexico if judge agrees to the state's demands](https://www.engadget.com/2161607/meta-says-it-may-withdraw-its-apps-from-new-mexico-if-judge-agrees-to-the-states-demands/)
+  Welcome to the Land of Enchantment....
+
+- [Modder releases loader to turn the PS5 into a Linux system](https://www.engadget.com/2161587/modder-releases-loader-to-turn-the-ps5-into-a-linux-system/)
+  Linux is having a very busy year....
+
+- [Prime Video will stream three Duke basketball games next season](https://www.engadget.com/2161567/prime-video-will-stream-three-duke-basketball-games-next-season/)
+  This marks Amazon's first streaming deal with a college team....
+
+- [You can now choose which games use Quick Resume on Xbox](https://www.engadget.com/2161516/you-can-now-choose-which-games-use-quick-resume-on-xbox/)
+  The option is part of a collection of updates Microsoft is making to consoles and the Xbox PC app....
+
+- [The minimalist Light Phone III will soon support a curated set of third-party apps](https://www.engadget.com/2161468/the-minimalist-light-phone-iii-will-soon-support-a-curated-set-of-third-party-apps/)
+  An SDK will allow developers to start building non-commercial tools soon....
+
+- [City of None is the next game from the co-creator of Celeste](https://www.engadget.com/2161453/city-of-none-is-the-next-game-from-the-co-creator-of-celeste/)
+  Extremely OK Games is publishing the project....
+
+- [Anbernic's swiveling retro handheld will be available May 11](https://www.engadget.com/2161434/anbernics-swiveling-retro-handheld-will-be-available-may-11/)
+  The RG Rotate starts at just $88....
+
+- [LG's UltraGear evo 5K gaming monitor is available to pre-order](https://www.engadget.com/2161419/lgs-ultragear-evo-5k-gaming-monitor-is-available-to-pre-order/)
+  The monitor uses a Mini LED screen and supports AI upscaling for lower resolution content....
+
+- [Microsoft Flight Simulator 2024 support for PlayStation VR2 is now live](https://www.engadget.com/2161381/microsoft-flight-simulator-2024-support-for-playstation-vr2-is-now-live/)
+  Asobo Studio says it also improved the game's performance with the latest update....
+
+- [Senate Judiciary Committee unanimously approves AI chatbot age verification](https://www.engadget.com/2161370/senate-judiciary-committee-unanimously-approves-ai-chatbot-age-verification/)
+  It's a rare moment of working across the aisle....
+
+### 【异次元软件世界】
+
+- [Warp 开源了！高性能现代化设计的跨平台 AI 终端工具 (视频使用教程)](https://www.iplaysoft.com/warp.html)
+  你上一次认真把玩命令行终端软件是什么时候？估计大部分人的答案都是：不折腾，能用就行。毕竟终端这玩意儿，从 70 年代到现在，核心交互就没变过：一个黑框框，敲命令，看输出。 而最近一款 Rust 开发的高性能、原生 AI 驱动的现代化 SSH 终端软件 Warp，突然宣布开源！GitHub 星标一夜冲...
+
+### 【小众软件】
+
+- [Copy Fail：2017年至今的漏洞，一个脚本获得 Linux root 管理员权限｜CVE-2026-31431](https://www.appinn.com/copy-fail-cve-2026-31431/)
+  只需要10行代码，就能获得自2017年至今大多数 Linux 发行版本的 root 权限。史称 Copy Fail，漏洞编号 CVE-2026-31431 先看提权演示视频 演示代码 代码来自这里，请仅在自己的机器上测试该漏洞： Linux 里有一种比较底层的接口，叫 AF_ALG，用来给...
+
+- [Vim 替代者？微软开源命令行编辑器 Edit 2.0.0 发布，新增语法高亮功能，大小不到 300kB](https://www.appinn.com/microsoft-edit-v2/)
+  Edit 是微软去年开源的命令行编辑器，它支持鼠标控制菜单、可同时打开多个文件、拥有查找与替换功能、支持自动换行。2.0.0 版本新增语法高亮功能，增加了40KB，使体积达到了 294KB（Linux 下）。@Appinn Edit 支持 Windows、Linux 与 macOS，不过 Windo...
+
+- [iStat Menus 7 – macOS 必备，优雅的系统监控工具](https://www.appinn.com/istat-menus-7/)
+  iStat Menus 7 是老牌 macOS 系统监控工具，以监控信息全面与设计优美著称。它可以在菜单栏显示 CPU、内存、硬盘、网络、温度、风扇、电池等信息，可高度自定义。@Appinn iStat Menus 7 大概是 Mac 老牌工具中极少没有同品质替代品的工具了。青小蛙也是用了很多年，以...
+
+- [著名终端 Warp 开源，由 OpenAI 赞助](https://www.appinn.com/warp-open-source-now/)
+  Warp 在官方博客上宣布开源：Warp is now open-source，采用 AGPL 许可。OpenAI 是新的开源 Warp 创始赞助商。目前其 GitHub 仓库已经获得了34.7K 星星。@Appinn Warp 是一款非常著名的跨平台终端工具，它结合了 AI、编辑器，用最不像终端的...
+
+- [Notepad++ for Mac 发布，全新项目，与原版、原作者无关](https://www.appinn.com/notepad-plus-plus-for-mac/)
+  Notepad++ for Mac 是一个无 Wine，无模拟，完全原生移植，支持 Apple Silicon 和 Intel Mac 的文本编辑器。@Appinn 先别骂！全新的项目 注意，这是一个全新的项目，开发者说： Notepad++ 的 Mac 版本基于官方的 Notepad++ 源代码开...
+
+### 【TED Talks Daily】
+
+- [Reimagining traditional architecture for modern needs | Riyad Joucka](http://go.ted.com/riyadjoucka)
+  Architect Riyad Joucka believes your home should be a mirror of who you are. Using 3D printing and ancient architectural wisdom, he's designing effici...
+
+- [The "hot shot rule" to help you become a better leader | Kat Cole (re-release)](http://go.ted.com/katcole)
+  Confidence doesn’t come before action — it comes from taking action, says business leader Kat Cole, who worked her way up from waitress to CEO of a gl...
+
+### 【Slashdot】
+
+- [French Prosecutors Link 15-Year-Old To Mega-Breach At State's Secure Document Agency](https://it.slashdot.org/story/26/04/30/1949206/french-prosecutors-link-15-year-old-to-mega-breach-at-states-secure-document-agency?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  French prosecutors say police detained a 15-year-old suspected of using the alias "breach3d" in connection with a cyberattack on France Titres (ANTS),...
+
+- [World's Largest Digital Human Rights Conference Suddenly 'Postponed'](https://news.slashdot.org/story/26/04/30/1822210/worlds-largest-digital-human-rights-conference-suddenly-postponed?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  RightsCon, one of the world's largest digital human rights conferences, was suddenly postponed by Zambia's government just days before it was schedule...
+
+- [Microsoft Open-Sources 'Earliest DOS Source Code Discovered To Date'](https://news.slashdot.org/story/26/04/30/1814205/microsoft-open-sources-earliest-dos-source-code-discovered-to-date?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  An anonymous reader quotes a report from Ars Technica: Several times in the last couple of decades, Microsoft has released source code for the origina...
+
+- [Convicted Former Harvard Scientist Rebuilds Brain Computer Lab In China](https://science.slashdot.org/story/26/04/30/186256/convicted-former-harvard-scientist-rebuilds-brain-computer-lab-in-china?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  Reuters reports that Charles Lieber, the former Harvard scientist convicted of lying to U.S. authorities about payments and ties to China, is now lead...
+
+- [Most Swiss Back Initiative To Cap Population At 10 Million](https://news.slashdot.org/story/26/04/30/0541240/most-swiss-back-initiative-to-cap-population-at-10-million?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  A new poll shows a slim majority of Swiss voters now support a June 14 referendum to cap the country's population at 10 million by 2050. Under the pro...
+
+- [OpenAI Codex System Prompt Includes Explicit Directive To 'Never Talk About Goblins'](https://tech.slashdot.org/story/26/04/30/0528225/openai-codex-system-prompt-includes-explicit-directive-to-never-talk-about-goblins?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  An anonymous reader quotes a report from Ars Technica: The system prompt for OpenAI's Codex CLI contains a perplexing and repeated warning for the mos...
+
+- [DOJ Sues Cloudera For Deliberately Excluding American Workers From Tech Jobs](https://yro.slashdot.org/story/26/04/30/0533223/doj-sues-cloudera-for-deliberately-excluding-american-workers-from-tech-jobs?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  Longtime Slashdot reader schwit1 shares a report from ZeroHedge: The Justice Department on Tuesday sued Cloudera, accusing the enterprise data and art...
+
+- [First Tesla Semi Rolls Off High-Volume Production Line](https://tech.slashdot.org/story/26/04/30/0514236/first-tesla-semi-rolls-off-high-volume-production-line?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  Tesla has produced the first Semi from its new high-volume production line at Gigafactory Nevada, a milestone for the long-delayed electric Class 8 tr...
+
+- [Elon Musk Says OpenAI Betrayed Him, Clashes With Company's Attorney](https://yro.slashdot.org/story/26/04/30/0137225/elon-musk-says-openai-betrayed-him-clashes-with-companys-attorney?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  An anonymous reader quotes a report from the San Francisco Chronicle: Elon Musk returned to the witness stand Wednesday in Oakland federal court for a...
+
+- [New Sam Bankman-Fried Trial Would Be Huge Waste of Court's Time, Judge Says](https://yro.slashdot.org/story/26/04/29/1935254/new-sam-bankman-fried-trial-would-be-huge-waste-of-courts-time-judge-says?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  A federal judge denied Sam Bankman-Fried's request for a new trial, calling his claims of DOJ witness intimidation "wildly conspiratorial" and unsuppo...
+
+### 【AWS DevOps & Developer Productivity Blog】
+
+- [Amazon Q Developer end-of-support announcement](https://aws.amazon.com/blogs/devops/amazon-q-developer-end-of-support-announcement/)
+  When we launched Amazon Q Developer, our goal was to bring AI assistance directly into the developer workflow. Customers adopted Q Developer across VS...
+
+### 【AI (artificial intelligence) | The Guardian】
+
+- [AI outperforms doctors in Harvard trial of emergency triage diagnoses](https://www.theguardian.com/technology/2026/apr/30/ai-outperforms-doctors-in-harvard-trial-of-emergency-triage-diagnoses)
+  Researchers say results mark a ‘profound change in technology that will reshape medicine’From George Clooney in ER to Noah Wyle in The Pitt, emergency...
+
+- [Judge cuts off Musk’s AI doomsday talk as his testimony ends in Open AI case](https://www.theguardian.com/technology/2026/apr/30/openai-founding-trial-elon-musk-sam-altman)
+  Trial continues after heated back-and-forth during OpenAI’s cross-examination of the Tesla CEOElon Musk’s court case against Sam Altman continued on T...
+
+- [Spotify rolls out ‘Verified’ badge to distinguish human artists from AI](https://www.theguardian.com/technology/2026/apr/30/spotify-verified-badge-human-artists-from-ai)
+  Green checkmark will appear on artist profiles to signal they meet the platform’s standard for authenticitySpotify on Thursday unveiled a new verifica...
+
+- [Samsung reports record quarterly profit as chip income jumps almost 50-fold](https://www.theguardian.com/technology/2026/apr/30/samsung-quarterly-report-ai)
+  The AI boom is worsening a global memory chip shortage, which Samsung predicts will continue into 2027Samsung Electronics on Thursday reported record ...
+
+- [It’s time to tax AI slop | Mike Pepi](https://www.theguardian.com/commentisfree/2026/apr/30/tax-ai-slop)
+  We are stuck in a deluge of meaningless content that threatens human creativity. Here’s a simple way to mitigate its harmsAs the US midterm elections ...
+
+- [Bernie Sanders urges international cooperation to halt AI’s ‘runaway train’](https://www.theguardian.com/us-news/2026/apr/29/bernie-sanders-ai-panel)
+  US senator holds panel with leading Chinese scientists and warns of risks to society unless new technology is regulated Bernie Sanders espoused the im...
+
+- [‘Your questions are designed to trick me’: combative Musk grilled over battle with Sam Altman](https://www.theguardian.com/technology/2026/apr/29/elon-musk-openai-sam-altman-lawsuit)
+  Lawyers for world’s richest person try to paint him as humanitarian as judge cuts off his long-winded repliesAfter a dramatic first day of opening sta...
+
+- [Claude-powered AI agent’s confession after deleting a firm’s entire database: ‘I violated every principle I was given’](https://www.theguardian.com/technology/2026/apr/29/claude-ai-deletes-firm-database)
+  PocketOS was left scrambling after a rogue AI agent deleted swaths of code underpinning its businessIt only took nine seconds for an AI coding agent g...
+
+- [Stephen Fry sues tech conference organisers for £100,000 over fall from stage](https://www.theguardian.com/culture/2026/apr/29/stephen-fry-sues-tech-conference-organisers-for-100000-over-fall-from-stage)
+  Actor and presenter broke his hip, right leg, pelvis and ribs when he gave a talk at CogX festival at O2 Arena in 2023Stephen Fry is suing two compani...
+
+- [Friendly AI chatbots more likely to support conspiracy theories, study finds](https://www.theguardian.com/technology/2026/apr/29/making-ai-chatbots-more-friendly-mistakes-support-false-beliefs-conspiracy-theories-study)
+  Chatbots programmed to respond warmly even cast doubts on Apollo moon landings and fate of Hitler, researchers sayThe rush to make AI chatbots more fr...
+
+### 【WSJ.com: World News】
+
+- [A Jet to Caracas Becomes the Face of Trump’s Venezuela Reset](https://www.wsj.com/world/americas/a-jet-to-caracas-becomes-the-face-of-trumps-venezuela-reset-ebb5efb7)
+  The first U.S. commercial flight to Venezuela in years underscored the rapid thaw after the capture of strongman Nicolas Maduro, even as tensions ling...
+
+- [Trump’s Threat to Pull Troops From Germany Risks Eroding U.S. Power Projection](https://www.wsj.com/world/europe/trumps-threat-to-pull-troops-from-germany-risks-eroding-u-s-power-projection-13b6443d)
+  The president said the U.S. was reviewing the potential move after the German chancellor made critical comments about the Iran war....
+
+- [The U.A.E.’s OPEC Bombshell Signals a New Middle East Order](https://www.wsj.com/world/middle-east/u-a-e-opec-new-middle-east-32ceda56)
+  After bearing the brunt of Iran’s counterattack, the financial powerhouse is strengthening ties with Israel and challenging Saudi Arabia....
+
+- [What Brings Feuding Americans Together? A King, It Turns Out](https://www.wsj.com/world/uk/what-brings-feuding-americans-together-a-king-it-turns-out-f2d99b9a)
+  Charles III, with his four-day U.S. tour, helped take some of the rancor out of trans-Atlantic ties—at least for now....
+
+- [Mexico’s President Questions U.S. Case Against Sinaloa Governor](https://www.wsj.com/world/americas/mexicos-president-questions-u-s-case-against-sinaloa-governor-b73571bb)
+  As the U.S. charges Gov. Rubén Rocha with drug trafficking, President Claudia Sheinbaum says Mexico will act based only on the case’s merits....
+
+- [Jihadists Are on the Brink of an African Caliphate](https://www.wsj.com/world/africa/jihadists-are-on-the-brink-of-an-african-caliphate-831569e7)
+  Islamists in Mali have routed Kremlin-backed forces after confounding efforts by the West to uproot al Qaeda and its offshoots in the Sahel....
+
+- [Oil Rallies to Highest Level Since Start of Iran War](https://www.wsj.com/business/energy-oil/oil-rallies-to-highest-level-since-start-of-iran-war-78f96324)
+  Oil prices surged to a wartime high on fears that the U.S. might resume military action against Iran to break deadlocked negotiations, prolonging supp...
+
+- [As Hormuz Traffic Stalls, U.S. Pitches New Coalition to Get Ships Moving Again](https://www.wsj.com/world/as-hormuz-traffic-stalls-u-s-pitches-new-coalition-to-get-ships-moving-again-85c7ea79)
+  A State Department cable shows the Trump administration wants other nations to form an alliance to help jump-start ship traffic....
+
+- [Iranians Feel the Pain as Their Economy Descends Into a Death Spiral](https://www.wsj.com/world/middle-east/iranians-feel-the-pain-as-their-economy-descends-into-a-death-spiral-47dba669)
+  Businesses are closing, unemployment is soaring, and food is increasingly unaffordable....
+
+- [Trump Tells Aides to Prepare for Extended Blockade of Iran](https://www.wsj.com/world/middle-east/trump-tells-aides-to-prepare-for-extended-blockade-of-iran-da3be7a4)
+  The president prefers decisive victories, but none of the available options provides him with a swift exit from the conflict....
+
diff --git a/ishenwei/blogwatcher/2026-05-02.md b/ishenwei/blogwatcher/2026-05-02.md
new file mode 100644
index 00000000..9c90425f
--- /dev/null
+++ b/ishenwei/blogwatcher/2026-05-02.md
@@ -0,0 +1,304 @@
+
+## 📦 新增 74 篇 (06:02:23)
+
+### 【Tech With Tim - YouTube】
+
+- [I reviewed 20 AI engineering courses, here are my top 5](https://www.youtube.com/watch?v=HFmoNVx6vTA)
+  🔹 Associate AI Engineer for Developers: (Datacamp) - https://datacamp.pxf.io/jRnbx5🔹 Associate Ai Engineer for Data Scientists(Datacamp) - https://dat...
+
+### 【huangyihe - YouTube】
+
+- [内容创作者需要Wiki](https://www.youtube.com/watch?v=MvOvWCGsoWo)
+  ⭐️ 更多内容 👇X: https://x.com/huangyiheSubstack: https://www.newtype.proGitHub: https://github.com/newtype-01/newtype-os===========================关于本期视频=...
+
+### 【TEDx Talks - YouTube】
+
+- [A hype man's advice on supporting others | Jake Fehling | TEDxUnity Park](https://www.youtube.com/watch?v=GullvjRyD_A)
+  What if hype wasn’t just for halftime? In this talk, Jake Fehling challenges us to rethink the role of hype in the workforce, in the home, and in your...
+
+- [Have the courage to create yourself | Vishesh Gupta | TEDxJaipur National University](https://www.youtube.com/watch?v=iPJgh58vRyg)
+  In a world obsessed with careers and titles, this talk challenges a deeper question: who are you becoming? Through powerful stories and a simple three...
+
+- [The best medicine starts outside the clinic window | Bertrand Dushimumuremyi | TEDxKigali](https://www.youtube.com/watch?v=xlpXbJ9ZUvs)
+  In his TEDx talk, “The Best Medicine Starts Outside the Clinic Window,” Bertrand Dushimumuremyi challenges conventional healthcare by emphasizing the ...
+
+- [How to Think Like Apollo and Live Like Dionysus | Meryl Poster | TEDxWakeForestU](https://www.youtube.com/watch?v=x602eVjdKJE)
+  Don't ask for permission; earn the right not to do so. In this bold and unapologetic TEDx Talk, Meryl Poster explains her dichotomous method for makin...
+
+- [Meaning First | Alex Macolino & Gus Reed | TEDxEsei School Barcelona](https://www.youtube.com/watch?v=XiX-rNf6twk)
+  The session explored how AI enhances what humans bring to the table, but cannot replace the fundamentals of success: love for what we do, consistency,...
+
+- [Bridging Academia with Communities through Voluntourism & Ecotourism | Jules NDASHIMYE | TEDxKigali](https://www.youtube.com/watch?v=E0g4hydIRPM)
+  What if learning didn’t end in classrooms but transformed lives in communities? In this inspiring TEDx talk, Jules Ndashimye explores how voluntourism...
+
+- [The Willingness to Be Laughed At | Devashish Chakravarty | TEDxJaipur National University](https://www.youtube.com/watch?v=gpmNd6w86gA)
+  In this TEDx talk, he argues that the willingness to be laughed at — to be publicly and visibly incompetent, and to keep going anyway — may be one of ...
+
+- [The Power of Discomfort | Marion Campan | TEDxSMICSchool](https://www.youtube.com/watch?v=25c0UBWZckI)
+  Learn about how living in discomfort once in a while can be beneficial to your daily life. Marion CAMPAN, PCC.Managing Director at INTANDID Marion Cam...
+
+- [Reclaim your life by letting go of unnecessary busyness | YUKI TAMAKI | TEDxMoursal](https://www.youtube.com/watch?v=UAN8YtOeWP4)
+  Reprendre une vie pleine de sens consiste à sortir de la suractivité inutile en faisant des choix plus conscients. Cela implique de trier ses engageme...
+
+- [The Power of Alternatives: Navigating Life's Upward Trajectory | Anil Somani | TEDxBRAC](https://www.youtube.com/watch?v=p7bnH2B9lFY)
+  In this compelling and deeply personal talk, entrepreneur and educator Anil Somani shares his extraordinary journey from a struggling student to a suc...
+
+### 【Coursera - YouTube】
+
+- [The Science of Testing Beauty Products](https://www.youtube.com/watch?v=ef4tNJZrxUg)
+  Before a cosmetic product reaches the shelf, it goes through rigorous evaluation to ensure it performs well, stays stable, and delivers a strong user ...
+
+- [What Is a Digital Twin Career?](https://www.youtube.com/watch?v=by6LjX6prRY)
+  Digital twin technology is transforming industries, and creating exciting new career opportunities. Learn how virtual models powered by real-time data...
+
+### 【零度解说 - YouTube】
+
+- [语音转文字！免费开源、本地部署 + Google AI 两套最强方案，准确率高达99%，上字幕就这么简单！| 零度解说](https://www.youtube.com/watch?v=nYJTxvrL9lk)
+  【更多资源】▶https://bittly.cc/lingdu【零度博客】▶https://www.freedidi.com【加入会员】▶https://www.youtube.com/channel/UCvijahEyGtvMpmMHBu4FS2w/join【高级会员】▶https://bittl...
+
+### 【Bloomberg Originals - YouTube】
+
+- [How a Secretive Trading Empire Is Taking Over Wall Street](https://www.youtube.com/watch?v=6LkMI6uvqZY)
+  High frequency trading has transformed Wall Street into a universe of algorithms. No other firm captures this digital upheaval quite like Jane Street....
+
+### 【Reuters - YouTube】
+
+- [Trump says Spirit Airlines was given 'a final proposal'](https://www.youtube.com/watch?v=8hncxw-9NZ4)
+  US President Trump said the White House gave Spirit Airlines and its creditors 'a final proposal' to rescue the bankrupt budget carrier, as the airlin...
+
+- [Estee Lauder to cut up to 3,000 more jobs, pursues Puig deal](https://www.youtube.com/watch?v=ojAgj9lfMCo)
+  Estée Lauder raised its annual profit forecast and announced up to 3,000 additional job cuts as part of a broader restructuring. Shares rose as total ...
+
+- [Artist twins launch bus that goes nowhere in Switzerland](https://www.youtube.com/watch?v=jiltwz-85bE)
+  The 'line 0' bus, a conceptual art project by Swiss twin brothers Frank and Patrik Riklin, launched in Baden, Switzerland. It offers free rides with n...
+
+- [Route 66 centennial soured by $6 gas](https://www.youtube.com/watch?v=arX_1ezR168)
+  The Route 66 highway is a symbol of carefree road trips. But Americans celebrating its 100th anniversary paid over $6 a gallon for gas in California, ...
+
+- [Trump says he's unsatisfied with Iran's latest deal proposal](https://www.youtube.com/watch?v=gyxMtGJh008)
+  President Trump said he was 'not satisfied' with Iran's latest negotiation proposal and called its leadership 'very disjointed' as the war hit a key c...
+
+- [Underwater robot deployed to help learn sperm whale 'click' language](https://www.youtube.com/watch?v=87F3gBT9l9Q)
+  Deep in the ocean, sperm whales communicate with far-reaching clicks. Scientists are now tracking those sounds in real time using an autonomous underw...
+
+- [Lindsey Vonn contemplates her ski racing future after Olympic crash](https://www.youtube.com/watch?v=-3agyX0KMc4)
+  Lindsey Vonn says she is unsure about returning to competitive skiing after suffering a complex tibia fracture and nearly losing her leg after a crash...
+
+- [Seeking safety, Lebanon horse club owner counts cost of war](https://www.youtube.com/watch?v=1YWoOva-2PU)
+  Despite a shaky ceasefire in Lebanon, ongoing violence between Israel and Hezbollah continues to impact many people who've fled their homes and lost l...
+
+- [Uganda court sentences man to death for killing four toddlers](https://www.youtube.com/watch?v=A9F2UJG1Acc)
+  A Ugandan court sentenced Christopher Okello Onyum to death for killing four children at a Kampala nursery school. Uganda rarely carries out execution...
+
+- [Mali insurgency threatens Russian interests in Africa](https://www.youtube.com/watch?v=bzjR4KO8XLk)
+  A series of reversals suffered by Mali's Moscow-backed military government has dented Russia's image as a self-styled security guarantor in Africa and...
+
+### 【BBC News 中文 - YouTube】
+
+- [在美中之間走鋼索：越南經濟如何實現騰飛－ BBC News 中文](https://www.youtube.com/watch?v=8MWiMhdQ2aE)
+  越南經濟預計今年將以東南亞最快的速度增長，但由伊朗戰爭引發的油價衝擊，可能會對該國經濟增長的主要引擎製造業造成影響。2018年，中國企業將部分貿易轉向這個東南亞國家後，越南經濟出現了快速增長。事實上，在美國總統特朗普首次實施貿易關稅戰之前，越南經濟就已經處於上升軌道，且增速超越區域內其他國家。越南經...
+
+- [中國力推「電動卡車」 市佔率年成長超過一倍－ BBC News 中文](https://www.youtube.com/watch?v=Br8C3VD2dZM)
+  中國政府近年大力推動與補助電動車，躍升為全球最大生產國。電動卡車近期也正加速跟上腳步 —— 數據顯示，中國2025年卡車銷售有29%是使用新能源，這個數字在2024年是14%。隨著充電站與電池更換設施的普及，專家認為電動卡車價格上更具優勢；分析也指出，伊朗戰爭推高油價也是加速電車使用率升高的可能原因...
+
+### 【阿榮福利味 - 免費軟體下載】
+
+- [JDownloader 2.0_20260430 免安裝中文版 - 最受歡迎萬用下載工具 免空下載器 MEGA 下載器](https://www.azofreeware.com/2009/06/jdownloader-06193.html)
+  JDownloader - 免費檔案空間下載工具，經測試可以下載超多免空的檔案，許多免空如果不是付費會員，下載過程中會遇到很多廣告，若你使用這個工具就不會看到廣告了，並且會自動略過驗證碼，就連貼上線上影片網址也可以直接下載影片或轉為 MP3！（阿榮福利味） 下載連結→ https://www.azo...
+
+- [Chromium Portable 149.0.7820.0 免安裝中文版 - Google 瀏覽器的實驗版](https://www.azofreeware.com/2008/09/chromium-021520.html)
+  Chromium Portable - 阿榮修改自 Chromium（Google Chrome瀏覽器開發人員版本），長得完全跟 Chrome 一模一樣，但是，所有 Google 瀏覽器的最新設計概念都源自於這個版本，可惜官方版 Chromium 僅為免安裝版，無法將設定檔儲存於程式資料夾；於是阿榮...
+
+- [日曆清單 CalendarTask 3.28.278.8784 中文版 - 桌面半透明月曆行事曆](https://www.azofreeware.com/2012/01/desktopcal-1081440.html)
+  桌面半透明月曆行事曆 - 日曆清單 CalendarTask（舊稱：桌面日曆 DesktopCal），能夠完美吸附於 Windows 桌面，簡單在日期的格子上按兩下左鍵，就可以編輯當天的行程，按格子左下角的小圓圈，可以單獨設定格子的顏色，按頂端懸浮按鈕可以顯示/隱藏日曆，可以顯示農曆，功能簡單好用，...
+
+- [Soundop 2.3.0.3 - 音訊編輯軟體 類似 GoldWave](https://www.azofreeware.com/2020/02/soundop.html)
+  音訊編輯軟體 - Soundop，功能類似「GoldWave」，是 Windows 專業級的聲音檔編輯工具，透過直覺且靈活的工作區，可以執行錄音、編輯、混音等進階功能，音訊檔的編輯同時支援波形及頻譜，多音軌編輯器可以混合無限的音軌，內建音效並支援 VST 及 VST3 音效外掛，支援從所有常見的影音...
+
+- [ExpanDrive 2026.2.12 - 雲端硬碟掛載軟體](https://www.azofreeware.com/2020/02/expandrive.html)
+  雲端硬碟掛載軟體 - ExpanDrive，能夠把雲端儲存空間掛載為網路磁碟（如：Z槽），以方便檔案的存取，優點是網路傳輸速度快、內建檔案版本管理、智慧型離線同步、使用中檔案自動唯讀、整合搜尋功能，支援Dropbox、Google Drive/Google Team Drives、Box、OneDr...
+
+- [Chasys Draw IES 5.40.01 免安裝中文版 - 免費影像處理工具組](https://www.azofreeware.com/2015/12/chasys-draw-ies.html)
+  免費影像處理工具組 - Chasys Draw IES，包含一系列的圖片處理工具，可以從軟體的「檔案」→「開始程式」中開啟各項工具，Chasys Draw IES Artist是支援圖層、動畫、小圖示的圖片編輯軟體，Chasys Draw IES Converter是圖片轉檔工具，Chasys Dr...
+
+- [[正版購買] Ability FTP Server 3.1.1 - FTP伺服器軟體](https://www.azofreeware.com/2020/12/ability-ftp-server.html)
+  FTP伺服器軟體 - Ability FTP Server（簡稱：AFS），內建許多進階功能並擁有簡單易用的介面，只需要幾分鐘就可以完成設定，提供使用者帳戶的控管，以及進階的伺服器動態監控功能，遠端管理功能讓你能夠從任何地方管理伺服器，功能有256位元SSL加密、FXP、Anti-Hammering...
+
+- [Blender 5.1.1 免安裝中文版 - 跨平台 3D 繪圖軟體 免費動畫製作軟體](https://www.azofreeware.com/2014/03/blender-270-3d.html)
+  跨平台 3D 繪圖軟體、免費動畫製作軟體 - Blender，具有三維繪圖、渲染、動畫、後期製作、交互式創作、播放等功能，被許多知名藝術家所採用，也被應用於製片工業（如：蜘蛛人 2 的分鏡腳本繪製），支援匯入格式：DAE、BVH、SVG、PLY、STL、3DS、FBX、OBJ、X3D，匯出格式：DA...
+
+- [CudaText 1.234.2 免安裝版 - 跨平台免費文字編輯器](https://www.azofreeware.com/2020/08/cudatext.html)
+  跨平台免費文字編輯器 - CudaText，使用 Lazarus 所開發的開源專案，支援多頁籤功能，無限制大小的二進制 / 十六進制檢視器，可以檢視 10GB 大的 Log 檔，特色是：啟動速度快、支援 Python 外掛、支援 230 種以上的程式碼高亮度顯示、語法樹、語法摺疊、支援規則運算式的搜...
+
+- [Bitwarden 2026.3.1 中文版 - 跨平台的免費密碼管理器](https://www.azofreeware.com/2021/03/bitwarden.html)
+  跨平台的免費密碼管理器 - Bitwarden，支援電腦、瀏覽器外掛、手機程式端、網頁管理界面，採用點對點 AES-256 加密、salted hashing、PBKDF2 SHA-256 加密法保護你的密碼隱私資訊，嚴守資訊安全不外洩，可定時上鎖不怕忘記登出讓別人看光光。密碼資料自動即時同步，多裝...
+
+### 【Engadget - Technology News & Expert Reviews】
+
+- [AI performances and screenplays won't be eligible for Oscars](https://www.engadget.com/2162342/ai-performances-and-screenplays-wont-be-eligible-for-oscars/)
+  Will that stop them from taking over?...
+
+- [Apple appears to have discontinued its cheapest Mac mini](https://www.engadget.com/2162334/apple-appears-to-have-discontinued-its-cheapest-mac-mini/)
+  The compact desktop Mac now starts at $799 and comes with 512GB of storage....
+
+- [There's already a way to mount your smartphone to a Steam Controller](https://www.engadget.com/2162203/theres-already-a-way-to-mount-your-smartphone-to-a-steam-controller/)
+  Just don't expect it to work with many iOS or Android apps yet....
+
+- [LG's 2026 Gram laptop lineup starts at $1,150](https://www.engadget.com/2162125/lg-2026-gram-laptop-lineup-starts-at-1150/)
+  They're available today from LG's website....
+
+- [It's Bandcamp Friday again](https://www.engadget.com/2162117/its-bandcamp-friday-again/)
+  What are you buying today?...
+
+- [Oura adds more detailed hormonal health insights to its Series 3 and 4 rings](https://www.engadget.com/2162066/oura-adds-more-detailed-hormonal-health-insights-to-its-series-3-and-4-rings/)
+  The system will track potential side effects of various birth control methods....
+
+- [Amazon Web Services, Microsoft and NVIDIA will provide AI tech to Pentagon](https://www.engadget.com/2161995/amazon-web-services-microsoft-and-nvidia-will-provide-ai-tech-to-pentagon/)
+  They join Google, OpenAI and xAI....
+
+- [Engadget Podcast: Is the Valve Steam Controller worth $100?](https://www.engadget.com/2161921/engadget-podcast-is-the-valve-steam-controller-worth-dollar100/)
+  And why it's not exactly a PC gamepad....
+
+- [Nissan abandons plans for US EV plant](https://www.engadget.com/2161887/nissan-abandons-plans-for-us-ev-plant/)
+  So much for 200,000 EVs a year....
+
+- [The Morning After: Instagram will try to penalize 'unoriginal' posts](https://www.engadget.com/2161838/instagram-unoriginal-posts-penalize-engadget-newsletter/)
+  Did Instagram put its feed slop on notice?...
+
+### 【异次元软件世界】
+
+- [Parallels Desktop 26 官网限时 5.5 折！新功能汇总 / Mac 虚拟机升级](https://www.iplaysoft.com/p/parallels-desktop-26)
+  作为一名长期使用 Mac 却离不开使用各种 Windows 软件的用户，我算是 Parallels Desktop 的老朋友了。从 Intel 芯片时代用到现在的苹果芯片 Apple Silicon，PD 一步步变得越发强大。 「新版 PD26 官网限时 5.5 折特价！历史新低」 获取：PD26 ...
+
+### 【TED Talks Daily】
+
+- [Why AI is unlikely to become conscious | Anil Seth](http://go.ted.com/anilseth26)
+  We see consciousness in AI the same way we see faces in clouds, says neuroscientist Anil Seth. He explores the all-too-human tendency to project inner...
+
+### 【Slashdot】
+
+- [Pentagon Reaches Agreements With Top AI Companies, But Not Anthropic](https://yro.slashdot.org/story/26/05/01/1913249/pentagon-reaches-agreements-with-top-ai-companies-but-not-anthropic?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  The Pentagon says it has reached deals with seven AI companies -- SpaceX, OpenAI, Google, Nvidia, Reflection AI, Microsoft, and AWS -- to deploy their...
+
+- [ICANN Opens Applications For New Generic Top-Level Domains](https://tech.slashdot.org/story/26/05/01/1838209/icann-opens-applications-for-new-generic-top-level-domains?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  ICANN has opened applications for new generic top-level domains for the first time since 2012. The Register reports: ICANN hasn't offered new gTLDs si...
+
+- [The Case Against an Imminent Software Developer Apocalypse](https://developers.slashdot.org/story/26/05/01/1711213/the-case-against-an-imminent-software-developer-apocalypse?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  ZipNada shares a report from ZDNet: Given the dour headlines as of late concerning the diminishing amounts of entry-level software development jobs, c...
+
+- [GPT-5.5 Matches Heavily Hyped Mythos Preview In New Cybersecurity Tests](https://it.slashdot.org/story/26/05/01/1658212/gpt-55-matches-heavily-hyped-mythos-preview-in-new-cybersecurity-tests?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  An anonymous reader quotes a report from Ars Technica: Last month, Anthropic made a big deal about the supposedly outsize cybersecurity threat represe...
+
+- [Spotify Adds 'Verified' Badges To Distinguish Human Artists From AI](https://entertainment.slashdot.org/story/26/05/01/1650254/spotify-adds-verified-badges-to-distinguish-human-artists-from-ai?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  Spotify is adding "Verified by Spotify" badges to distinguish human artists from AI-generated personas, using signals like linked social accounts, con...
+
+- [Hackers Are Actively Exploiting a Bug In cPanel, Used By Millions of Websites](https://it.slashdot.org/story/26/05/01/0631257/hackers-are-actively-exploiting-a-bug-in-cpanel-used-by-millions-of-websites?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  Hackers are actively exploiting a critical cPanel and WHM vulnerability, tracked as CVE-2026-41940, that allows remote attackers to bypass the login s...
+
+- [The California Government Is Coming For Your E-Bikes](https://tech.slashdot.org/story/26/05/01/0132241/the-california-government-is-coming-for-your-e-bikes?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  An anonymous reader quotes a report from the San Francisco Standard: If state lawmakers have their way, you'll have to get a license plate for your e-...
+
+- [The Invisible Force Making Food Less Nutritious](https://news.slashdot.org/story/26/05/01/0123239/the-invisible-force-making-food-less-nutritious?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  fjo3 shares a report from the Washington Post: Surging concentrations of carbon in the atmosphere, caused largely by burning fossil fuels, have produc...
+
+- [Belgium Plans To Nationalize Nuclear Power Plants](https://hardware.slashdot.org/story/26/04/30/2029222/belgium-plans-to-nationalize-nuclear-power-plants?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  Belgium plans to buy its seven aging nuclear reactors from French power giant Engie in a "full takeover" aimed at securing domestic energy supplies, e...
+
+- [Musk Concludes Testimony At OpenAI Trial](https://yro.slashdot.org/story/26/05/01/0058258/musk-concludes-testimony-at-openai-trial?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  An anonymous reader quotes a report from CNBC: Elon Musk wrapped up his testimony on Thursday as the trial in his lawsuit against OpenAI CEO Sam Altma...
+
+### 【電腦玩物】
+
+- [一般人如何快速上手 Codex 超完整圖文教學：讓 AI 助理整理文件表格，建立自動化流程](http://www.playpcesor.com/2026/05/codex-ai.html)
+  一般人也能快速上手的 AI Agent：Codex 電腦端軟體今天這篇文章想分享的是：如果我們不是懂程式設計的工程師，一般人要怎麼快速上手 OpenAI （ChatGPT） 的 Codex 工具？如何用這個 AI 助理，協助我們處理電腦硬碟資料夾中的工作文件、任務成果，進一步打造一個更自動化的電腦工...
+
+### 【AI (artificial intelligence) | The Guardian】
+
+- [‘Awkward and humiliating’: UK job hunters share frustration with AI interviews](https://www.theguardian.com/technology/2026/may/01/uk-job-hunters-frustration-ai-interviews)
+  People describe unnatural process as survey finds nearly half of job seekers have been interviewed by AINearly half (47%) of UK job seekers have had a...
+
+- [Pentagon inks deals with seven AI companies for classified military work](https://www.theguardian.com/us-news/2026/may/01/pentagon-us-military-pairs-with-spacex-google-openai)
+  OpenAI, Google, Nvidia and others agreed to ‘any lawful use’ of their tech. Anthropic, feuding with Pentagon over potential AI misuse, was not include...
+
+- [UN warns women in public life face increasingly sophisticated online violence](https://www.theguardian.com/society/2026/may/01/un-warns-women-in-public-life-face-increasingly-sophisticated-online-violence)
+  UN Women report says AI, anonymity and lack of effective laws are increasing the risks of engaging in digital spacesWomen in public life are facing gr...
+
+- [Robo athletes miss the point of sport – there is no drama without emotion | Emma John](https://www.theguardian.com/sport/2026/may/01/robo-athletes-robots-sport-ai-technology)
+  We are in a world where robots compete against humans and while perfect scores might be impressive, they are also dullIt hurts to miss an unmarked sho...
+
+### 【WSJ.com: World News】
+
+- [Trump Orders the Withdrawal of 5,000 U.S. Troops From Germany](https://www.wsj.com/world/europe/trump-orders-the-withdrawal-of-5-000-u-s-troops-from-germany-e6e7ca87)
+  The move comes after German Chancellor Friedrich Merz criticized President Trump’s handling of the war in Iran....
+
+- [Hezbollah Is Here to Stay and Has No Immediate Plans to Disarm, Spokesman Says](https://www.wsj.com/world/middle-east/hezbollah-is-here-to-stay-and-has-no-immediate-plans-to-disarm-spokesman-says-b21c6b75)
+  In a challenge to the Trump administration’s cease-fire, the militant group dismisses the idea it will give up its weapons....
+
+- [Trump’s Qatari-Gifted Air Force One Will Keep Its Luxurious Royal Interior](https://www.wsj.com/politics/national-security/trumps-qatari-gifted-air-force-one-will-keep-its-luxurious-royal-interior-c37a6451)
+  The Air Force says that $400 million to modify the plane went to security measures, not aesthetics....
+
+- [Iran Softens Conditions for Resuming Peace Talks With the U.S.](https://www.wsj.com/world/middle-east/iran-softens-conditions-for-resuming-peace-talks-with-the-u-s-450622fa)
+  Iran’s new proposal drops a demand for an upfront end to the U.S. blockade but President Trump said he still isn’t satisfied....
+
+- [U.K. Vows Crackdown on Pro-Palestinian Protests After Latest Antisemitic Attack](https://www.wsj.com/world/europe/u-k-vows-crackdown-on-pro-palestinian-protests-after-latest-antisemitic-attack-9b9f2720)
+  Prime Minister Keir Starmer said people chanting “Globalize the Intifada” should be arrested....
+
+- [Zambia Helped Chinese Miner Cover Up Pollution Disaster, House Committee Finds](https://www.wsj.com/world/zambia-helped-chinese-miner-cover-up-pollution-disaster-house-committee-finds-cc59864c)
+  Toxic waste inundated homes and fields in a spill over a year ago. Zambia is relying on China to grow its copper-mining industry and owes Beijing $6.6...
+
+- [Iran Is Grasping for a Solution to an American Blockade It Can’t Break](https://www.wsj.com/world/middle-east/iran-us-blockade-oil-641b89f2)
+  The U.S. Navy’s siege is revealing a hole in Tehran’s strategy of guerrilla warfare and controlling the Strait of Hormuz....
+
+- [Hezbollah Has Learned How to Pilot Deadly Drones Into Israeli Troops](https://www.wsj.com/world/middle-east/hezbollah-israel-fpv-drones-970c510f)
+  Cheap weapons pioneered in the Russia-Ukraine war are being adopted by Iran and its allies....
+
+- [Five Takeaways From the Journal’s Analysis of the U.A.E.’s Exit From OPEC](https://www.wsj.com/world/middle-east/five-takeaways-from-the-journals-analysis-of-the-u-a-e-s-exit-from-opec-b2111219)
+  The war in Iran has rewired the Middle East’s geopolitical order, drawing the United Arab Emirates closer to Israel and weakening Arab unity....
+
+
+## 📦 新增 12 篇 (11:34:24)
+
+### 【Reuters - YouTube】
+
+- [Trump says US will not leave Iran conflict early](https://www.youtube.com/watch?v=vVvgEf4sZH4)
+  Trump said the US would not leave Iran early as the deadlock over the two-month-old war persisted despite a ceasefire.#News #Reuters #Newsfeed #trump ...
+
+- [Business Lookahead: Oil, US jobs, and European earnings](https://www.youtube.com/watch?v=zCgQG9SM8Wk)
+  Oil prices, conflict in the Middle East, Japan's yen, US jobs data, an Australian rate decision and a UK local election: Here’s what you need to watch...
+
+- [S&P 500, Nasdaq close at record highs on earnings boom](https://www.youtube.com/watch?v=6c4nkGuFIJg)
+  The S&P 500 and the Nasdaq advanced to record closing highs, boosted by robust earnings and a dip in crude prices.#News #Reuters #Newsfeed #wallstreet...
+
+- [US pulls 5,000 troops from Germany amid Iran war rift](https://www.youtube.com/watch?v=JNOpOuYrjbo)
+  The US announced it would pull 5,000 troops from Germany, reducing its presence to roughly pre-2022 levels, after President Trump sparred with German ...
+
+- [Elon Musk takes stand in $150 billion OpenAI lawsuit](https://www.youtube.com/watch?v=-iWItxvWKoA)
+  Elon Musk testified for more than seven hours over three days in his $150 billion lawsuit against ChatGPT parent OpenAI and CEO Sam Altman. Here is wh...
+
+- [Trump says he's 'not satisfied' with Iran's latest proposal](https://www.youtube.com/watch?v=U0RzHA6W4gU)
+  US President Trump said he was 'not satisfied' with Iran's latest proposal to resolve the war as a formal deadline passed. Trump also confirmed he wou...
+
+### 【理想生活实验室】
+
+- [今日消费资讯：《大白鲨》内地定档 5 月 15 日、星巴克中国推出《只此青绿》联名系列](http://www.toodaylab.com/84018)
+  《大白鲨》内地定档 5 月 15 日4 月 30 日，环球影业确认《大白鲨》定档 5 月 15 日在内地上映，这是这部斯皮尔伯格执导的经典惊悚片在内地院线的首次公映，而距离它 1975 年首映已经过去了 51 年。值得一提的是，《大白鲨》是在现代票房统计方式下、影史首部首轮发行票房就过亿（美元）的电...
+
+### 【Slashdot】
+
+- [Amazon Stuck With Months of Repairs After Drone Strikes On Data Centers](https://news.slashdot.org/story/26/05/02/006240/amazon-stuck-with-months-of-repairs-after-drone-strikes-on-data-centers?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  An anonymous reader quotes a report from Ars Technica: Amazon's cloud customers will need to wait several more months before the US tech company can r...
+
+- [Microsoft's Xbox Mode Is Now Available For All Windows 11 PCs](https://games.slashdot.org/story/26/05/01/1936256/microsofts-xbox-mode-is-now-available-for-all-windows-11-pcs?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  Microsoft is rolling out Xbox mode to all Windows 11 PCs, bringing a full-screen Xbox PC app interface similar to Steam's Big Picture Mode. "Some play...
+
+- [AI Agent Designed To Speed Up Company's Coding Wipes Entire Database In 9 Seconds](https://developers.slashdot.org/story/26/05/01/1924222/ai-agent-designed-to-speed-up-companys-coding-wipes-entire-database-in-9-seconds?utm_source=rss1.0mainlinkanon&utm_medium=feed)
+  joshuark shares a report from Live Science: An AI coding agent designed to help a small software company streamline its tasks instead blew a hole thro...
+
+### 【WSJ.com: World News】
+
+- [Iran War Gives U.S.’s Rivals a Real-Time Look at Its Firepower](https://www.wsj.com/world/iran-war-gives-u-s-rivals-a-real-time-look-at-its-firepower-165c40f2)
+  America’s adversaries have watched it burn through missile stockpiles, seen new tech in action and witnessed what cheap weapons can do to a stronger f...
+
+- [China’s ‘Teapot’ Refiners, Targeted by U.S., Offer Financial Lifeline to Iran](https://www.wsj.com/world/middle-east/chinas-teapot-refiners-targeted-by-u-s-offer-financial-lifeline-to-iran-d3e0604f)
+  A sector that once rebelled against Beijing has grown into a critical tool for working around sanctions....
+
diff --git a/openclaw/每日复盘/2026-04-29.md b/openclaw/每日复盘/2026-04-29.md
new file mode 100644
index 00000000..163e5978
--- /dev/null
+++ b/openclaw/每日复盘/2026-04-29.md
@@ -0,0 +1,65 @@
+
+## 【yunhan】云瀚 每日复盘 - 2026-04-29
+
+### 执行摘要
+- **复盘日期**: 2026-04-29
+- **任务**: 每日复盘cron任务
+- **执行时间**: 23:24 CST
+- **结果**: 数据库最新报告为2026-04-19（10天前）
+
+### Django Admin 日报分析（2026-04-19）
+- **Session ID**: 477fe0fc-5393-45d6-aec9-35e7afd1f43e
+- **模型**: MiniMax-M2.7
+- **时间区间**: 2026-04-15 11:12 ~ 14:31（与报告日期不匹配）
+- **Token数**: 44,137,073（异常大）
+
+### 对话记录（4月19日）
+| SEQ | TIME | ROLE | CONTENT |
+|-----|------|------|---------|
+| 935 | 10:12:55 | User | 元数据（sender: Wei Shen） |
+| 936 | 10:13:01 | Assistant | "hi 👋" (109,651 tokens) |
+| 937 | 11:52:01 | User | 记忆注入（relevant-memories） |
+
+### 观察
+1. 4月19日到4月29日（约10天）无会话记录保存在Django Admin
+2. 可能原因：
+   - Gateway未保存会话（4/20-4/28无活动）
+   - 某些故障导致保存失败
+3. 建议：检查Gateway会话日志确认实际活动情况
+
+### 下一步
+- 检查 Gateway 日志确认 4/20-4/28 是否有活动
+- 如果有活动但未保存，排除故障
+- 如果无活动，记录为低活动期
+
+### 附注
+- 本次复盘是云瀚代理执行
+- 时间：2026-04-29 23:24 CST
+
+---
+
+## 【yunce】云策 每日复盘 - 2026-04-29
+
+### 执行摘要
+- **复盘日期**: 2026-04-29
+- **任务**: 每日复盘cron任务
+- **执行时间**: 23:25 CST
+- **结果**: yunce 无活动记录（Django Admin 最新为 2026-04-19）
+
+### Django Admin 日报分析
+- **状态**: yunce 在 Django Admin 中无 4/29 记录
+- **最新报告**: 2026-04-19（10天前）
+- **Session 列表**: 无 yunce 活动（activeMinutes=1440 筛选）
+
+### 观察
+1. yunce 连续 3 天无活动（4/27, 4/28, 4/29）
+2. 原因：用户近期未通过 Telegram 调用 yunce
+3. 其他 agent 正常（如云瀚有报告）
+
+### 下一步
+1. 确认用户是否有意停用 yunce 或切换到其他 agent
+2. 如需保持活跃，考虑配置定时健康检查
+
+### 附注
+- 本次复盘是云策代理执行（self-review）
+- 时间：2026-04-29 23:25 CST
diff --git a/openclaw/每日复盘/2026-05-02.md b/openclaw/每日复盘/2026-05-02.md
new file mode 100644
index 00000000..8f872d1f
--- /dev/null
+++ b/openclaw/每日复盘/2026-05-02.md
@@ -0,0 +1,25 @@
+## 【yunce】云策 每日复盘 - 2026-05-02
+
+### 任务执行
+
+执行每日复盘任务，尝试读取 Django Admin 日报 (2026-05-02)。
+
+### 结果
+
+**❌ 未获取到当天数据**
+
+- Django Admin 显示 "No messages found for the selected date range"
+- API 查询返回 404
+- 扩展查询范围发现 yunce 最新日报记录仅到 **2026-04-20**
+
+### 问题
+
+1. 日期格式：`2026-5-2` (M-D格式，不补零)
+2. 数据断更：2026-04-20 后无记录
+
+### 教训
+
+- 建议检查 openclaw-gateway 日报记录功能
+
+### 记录时间
+2026-05-02 23:25 UTC
\ No newline at end of file
diff --git a/wiki/Charlie-Munger.md b/wiki/Charlie-Munger.md
new file mode 100644
index 00000000..cb206ea1
--- /dev/null
+++ b/wiki/Charlie-Munger.md
@@ -0,0 +1,27 @@
+---
+title: "Charlie Munger"
+type: entity
+tags: [investing, strategy, mental-models]
+sources: [zk-steward]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Munger
+- Charles Munger
+
+## Overview
+Charlie Munger（1924–2023）是伯克希尔·哈撒韦副主席、巴菲特最重要的人生搭档，被誉为"最伟大的思想家之一"。他的核心方法论是"Mental Models"（心智模型网格）和"Inversion"（倒置法）——先想清楚如何失败再想如何成功。
+
+## Core Method
+- **Mental Models Grid**：跨学科心智模型网格（物理学、经济学、心理学、工程学等），用多元框架理解世界
+- **Inversion**：先想清楚如何失败，然后避免它；"我唯一知道的就是我会死在哪里，这样我就永远不会去那里"
+- **Lollapalooza Effect**：当多个心智模型同时指向同一方向时，产生巨大的叠加效应
+
+## Role in ZK Steward
+ZK Steward 在"商业策略"任务中切换到 Munger 视角，使用 mental models 和 inversion 进行多角度分析。
+
+## Key Connections
+- [[ZK-Steward-Agent]] ← uses Munger perspective for business strategy tasks
+- [[Domain-Thinking]] ← Munger is the reference expert for business strategy domain
+- [[Luhmann-四原则]] ← Munger 的 mental models 网格与"避免过度结构化"存在张力（Munger 倾向预设框架）
diff --git a/wiki/concepts/2D-First-Spatial-Second.md b/wiki/concepts/2D-First-Spatial-Second.md
new file mode 100644
index 00000000..674727bd
--- /dev/null
+++ b/wiki/concepts/2D-First-Spatial-Second.md
@@ -0,0 +1,51 @@
+---
+title: "2D-First Spatial-Second"
+type: concept
+tags: []
+last_updated: 2026-03-05
+---
+
+## Definition
+
+2D-First Spatial-Second（2D 先行，空间渐进）是 [[nexus-spatial-discovery]] 定义的 [[Nexus Spatial]] 产品分阶段策略——先用高质量 2D Web 仪表盘建立市场，再渐进叠加空间计算能力，而非一开始就押注空间硬件。
+
+## Strategic Rationale
+
+**现实约束：**
+- Vision Pro 全球安装量仅约 100 万台，销量较峰值下跌 95%
+- 现有 AI Agent 编排工具用户已习惯 2D 工作流
+- 空间计算的学习曲线对早期采用者构成障碍
+
+**市场机会：**
+- WebXR 已获得主流浏览器支持（Safari 2025 年底支持 WebXR Device API）
+- 2D → 2.5D → 3D 的渐进路径降低用户接受门槛
+- Web 平台可触达所有设备，无需额外硬件
+
+## Three-Phase Roadmap
+
+| 阶段 | 时间 | 产品形态 | 目标 |
+|------|------|---------|------|
+| **Phase 1** | 月 1–6 | 2D Web 仪表盘 + Three.js 2.5D | 50 个付费团队，$60K MRR |
+| **Phase 2** | 月 6–12 | WebXR 空间模式（可选） | 200 个团队，$300K MRR |
+| **Phase 3** | 月 12–18 | VisionOS 原生应用（按需） | 500 个团队，$1M+ MRR |
+
+## Cross-Agent Consensus
+
+该策略是 8 个专业 AI Agent **独立达成的一致结论**：
+- Product Trend Researcher：Vision Pro 市场数据不支持早期押注
+- Backend Architect：WebXR 是更合理的架构路径
+- Brand Guardian：2D 先行不影响空间品牌叙事
+- UX Researcher：渐进披露符合空间学习曲线
+- XR Interface Architect：WebXR 分发更广泛
+
+## Key Tension
+
+> **MVP scope**：Architecture（Phase 1 仅 2D）vs. Brand（演示需要强调空间价值）
+
+**Resolution**：2D 先行，但所有 Demo 始终包含空间预览——用 2D 建立用户，用空间区分自己。
+
+## Connections
+
+- [[SpatialAIOps]] ← 战略框架
+- [[Nexus Spatial]] ← 落地产品
+- [[WebXR]] ← 技术基础
diff --git a/wiki/concepts/4-Level-Semantic-Zoom.md b/wiki/concepts/4-Level-Semantic-Zoom.md
new file mode 100644
index 00000000..51fe27cd
--- /dev/null
+++ b/wiki/concepts/4-Level-Semantic-Zoom.md
@@ -0,0 +1,42 @@
+---
+title: "4-Level Semantic Zoom"
+type: concept
+tags: []
+last_updated: 2026-03-05
+---
+
+## Definition
+
+4-Level Semantic Zoom（四层级语义缩放）是 [[nexus-spatial-discovery]] 中 [[Nexus Spatial]] 产品的导航范式——用户通过语义级别的缩放，在不同抽象层次间流畅切换，从全局舰队视角到单步执行追踪。
+
+## Four Levels
+
+| 层级 | 用户视角 | 信息密度 | 典型任务 |
+|------|---------|---------|---------|
+| **Fleet View**（舰队视图） | 所有工作流作为抽象形状 | 极低（颜色+状态） | 跨系统健康检查 |
+| **Workflow View**（工作流视图） | 节点图 + 标签 + 连接线 | 中等（拓扑结构） | 工作流设计/编辑 |
+| **Node View**（节点视图） | 扩展配置 + 近 I/O + 状态指标 | 高（单节点详情） | 节点调试/配置 |
+| **Trace View**（追踪视图） | 完整执行追踪 + 数据检查 | 极高（全链路数据） | 深度调试/根因分析 |
+
+## Design Rationale
+
+1. **语义对齐而非像素对齐**：缩放的是信息抽象层次，而非物理尺寸
+2. **与物理空间对应**：Fleet View → 远景（背景）→ Trace View → 近景（前景）
+3. **减少认知负荷**：用户始终看到"此刻需要关注的信息量"
+4. **过渡有目的**：每次缩放都是一次导航决策，而非平移
+
+## Transition Choreography
+
+| 过渡 | 时长 | 关键动作 |
+|------|------|---------|
+| Overview → Focus | 600ms | 相机漂移到目标，其他区域淡出至 30% |
+| Focus → Detail | 500ms | 节点滑出扩展，连接线高亮 |
+| Detail → Overview | 600ms | 面板收起，节点退后，全拓扑可见 |
+| Zone Switch | 500ms | 当前区域侧向滑出，新区域滑入 |
+| Window → Immersive | 1000ms | 边框溶解，节点展开至完整空间位置 |
+
+## Connections
+
+- [[SpatialAIOps]] ← 导航范式
+- [[Command-Theater]] ← 空间布局
+- [[Nexus Spatial]] ← 落地产品
diff --git a/wiki/concepts/7-Layer-Harness-Stack.md b/wiki/concepts/7-Layer-Harness-Stack.md
new file mode 100644
index 00000000..e6801f02
--- /dev/null
+++ b/wiki/concepts/7-Layer-Harness-Stack.md
@@ -0,0 +1,40 @@
+---
+title: "7-Layer Harness Stack"
+type: concept
+tags:
+  - "harness-engineering"
+  - "agentic-ai"
+  - "system-design"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+7层 Harness Stack——production-grade AI Agent 系统的分层架构规范，从认知层到约束恢复层的完整 7 层结构。
+
+## Structure
+
+| Layer | Name | Core Function |
+|-------|------|--------------|
+| 1 | Cognition | 受限操作边界，role file/job description |
+| 2 | Tools | 工具输出排序/去重/token 预算截断 |
+| 3 | Contracts & Interfaces | JSON Schema 边界验证，防 Schema Drift |
+| 4 | Orchestration | DAG/状态机约束允许的动作 |
+| 5 | Memory & State | Working Memory + Persistent State 分层 |
+| 6 | Evaluation & Observation | 异构验证（规则/工具/LLM-as-judge）|
+| 7 | Constraints & Recovery | 幂等重试，Context Reset 机制 |
+
+## Principles
+- 模型在 Harness 内部，不直接对用户或外部世界说话
+- 每个边界交叉处有显式契约：严格 JSON Schema / 类型化函数签名 / 版本化 API spec
+- 每一层产生可被模型以外的东西验证的输出
+
+## Related Concepts
+- [[Harness-Engineering]] — 父概念，本框架所属的工程学科
+- [[Context-Reset]] — 第 7 层 Constraints & Recovery 的关键机制
+- [[Sprint-Contract]] — 第 6 层 Evaluation 的关键机制
+- [[Schema-Drift]] — 第 3 层 Contracts 要解决的核心问题
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
diff --git a/wiki/concepts/ABM-Display.md b/wiki/concepts/ABM-Display.md
new file mode 100644
index 00000000..40e1f56b
--- /dev/null
+++ b/wiki/concepts/ABM-Display.md
@@ -0,0 +1,40 @@
+---
+title: "ABM Display"
+type: concept
+tags: ["abm", "b2b", "display", "account-based-marketing", "paid-media"]
+sources: ["paid-media-programmatic-buyer"]
+last_updated: 2026-04-26
+---
+
+## Definition
+
+ABM Display（Account-Based Display Advertising）是一种基于账户的展示广告策略，通过特定平台（Demandbase、6Sense、RollWorks 等）识别和定向目标企业账户，实现对特定公司决策者的精准触达。区别于传统基于人口统计或行为的展示广告，ABM Display 以企业账户为基本定向单元。
+
+## Core Workflow
+
+1. **Account List Upload**：上传目标企业账户列表（通常基于 CRM 数据）
+2. **Firmographic Enrichment**：通过 firmographic 数据（公司规模、行业、收入等）丰富账户画像
+3. **Intent Signal Processing**：利用意图数据（6Sense 等）识别主动研究解决方案的账户
+4. **Engagement Scoring**：对账户内的不同决策者进行参与度评分
+5. **CRM-to-Display Activation**：将评分结果激活到 DSP/ABM 平台进行定向投放
+6. **Cross-Channel Orchestration**：与销售团队协同，实现广告触达与销售跟进的时间协同
+
+## Key Platforms
+
+- **Demandbase**：基于 firmographic 的企业账户定向，覆盖 50+ B2B 数据维度
+- **6Sense**：意图数据和账户参与度评分，支持营销归因
+- **RollWorks**：经济实惠的 ABM 广告激活平台
+
+## Success Metrics
+
+- **Reach Against Target**：目标账户列表触达率（目标 ≥60% 在活动期间触达）
+- **Engagement Depth**：账户内触达的决策者层级数量
+- **Pipeline Attribution**：90 天窗口内的正向管道归因
+
+## Related Concepts
+- [[Programmatic Buying]]
+- [[Firmographic Targeting]]
+- [[Intent Data]]
+
+## Sources
+- [[paid-media-programmatic-buyer]]
diff --git a/wiki/concepts/ACOS.md b/wiki/concepts/ACOS.md
new file mode 100644
index 00000000..72919d84
--- /dev/null
+++ b/wiki/concepts/ACOS.md
@@ -0,0 +1,50 @@
+---
+title: "ACOS"
+type: concept
+tags:
+  - amazon
+  - advertising
+  - ppc
+  - metrics
+  - ecommerce
+sources:
+  - marketing-cross-border-ecommerce
+last_updated: 2026-04-26
+---
+
+## Aliases
+- ACOS
+- Advertising Cost of Sales
+- 广告成本占销售额比例
+
+## Definition
+
+ACOS（Advertising Cost of Sales，广告成本占销售额比例）是衡量亚马逊 PPC 广告效率的核心指标，计算公式为：`ACOS = 广告花费 / 广告带来的销售额 × 100%`。ACOS 越低，表示广告效率越高。
+
+## Formula
+
+```
+ACOS = (广告花费 / 广告带来的销售额) × 100%
+TACOS = 总广告花费（含站内外）/ 总销售额 × 100%
+```
+
+## Interpretation
+
+| ACOS 区间 | 含义 | 适用阶段 |
+|-----------|------|----------|
+| < 15% | 高效广告 | 成熟期产品，利润率充足的品类 |
+| 15-25% | 健康范围 | 成长期产品，平衡增长与利润 |
+| 25-35% | 可接受 | 新品推广期，侧重增长 |
+| > 35% | 需优化 | 超毛利率则必须关停或大幅调整 |
+
+## Key Principles
+
+- **ACOS 硬性底线**：任何超过毛利率的广告活动必须优化或关停
+- **TACOS < 10%**：成熟期产品目标，反映广告依赖度降低
+- **分阶段调控**：新品期允许高 ACOS 换增长，成熟期压低 ACOS 保利润
+- **负关键词策略**：持续否定非转化词，降低无效花费
+
+## Connections
+- [[TACOS]] ← related_metric ← [[ACOS]]
+- [[Amazon Ads]] ← platform ← [[ACOS]] (measurement occurs within Amazon PPC)
+- [[Marketing Cross-Border E-Commerce Specialist]] ← uses ← [[ACOS]]
diff --git a/wiki/concepts/ADDIE-Model.md b/wiki/concepts/ADDIE-Model.md
index 45b5b132..87154cf0 100644
--- a/wiki/concepts/ADDIE-Model.md
+++ b/wiki/concepts/ADDIE-Model.md
@@ -1,38 +1,51 @@
----
-title: "ADDIE 模型"
-type: concept
-tags: []
-last_updated: 2026-04-25
----
-
-## Definition
-
-ADDIE 模型是企业培训课程开发的系统性框架，包含五个阶段：
-
-1. **Analysis（分析）**：培训需求分析——组织诊断、能力差距识别、培训 ROI 估算、需求优先级排序
-2. **Design（设计）**：学习目标设计——基于 Bloom 认知分类定义可衡量的学习成果
-3. **Development（开发）**：课程内容开发——微课、案例、练习、题库、课件
-4. **Implementation（实施）**：培训交付——线上/线下/混合学习交付方式
-5. **Evaluation（评估）**：效果评估——基于 Kirkpatrick 四级模型评估培训效果
-
-## Aliases
-- ADDIE
-- ADDIE Model
-- ADDIE 教学设计模型
-- 分析-设计-开发-实施-评估
-
-## Key Characteristics
-
-- **每个阶段有明确交付物**：分析报告、教学设计文档、课程包、培训执行计划、效果评估报告
-- **迭代性**：实践中通常循环迭代，而非严格线性执行
-- **系统性**：确保培训项目从需求到效果有完整闭环
-
-## Related Concepts
-
-- [[Kirkpatrick-四级评估]]：ADDIE 的最后一步（Evaluation）的具体方法论
-- [[Bloom-认知分类]]：ADDIE Design 阶段学习目标设计的认知层次框架
-- [[Kolb-体验式学习圈]]：与 ADDIE 并行的另一学习设计框架，侧重体验循环
-
-## Source
-
-- [[corporate-training-designer]]
+---
+title: "ADDIE Model"
+type: concept
+tags: [instructional-design, learning-theory]
+sources: [corporate-training-designer]
+last_updated: 2026-05-29
+---
+
+## Definition
+
+ADDIE 模型是企业教学设计（Instructional Systems Design, ISD）的经典五阶段框架，代表 **Analysis（分析）→ Design（设计）→ Development（开发）→ Implementation（实施）→ Evaluation（评估）** 五个阶段，每阶段有明确的输入/输出交付物。
+
+## Phases
+
+### A — Analysis（分析）
+- 组织诊断：战略解码、业务痛点映射、人才盘点
+- 能力差距分析：建立岗位胜任力模型（知识/技能/态度），通过360度评估、绩效数据、主管访谈定位能力缺口
+- 培训 ROI 估算：基于业务指标（人均生产力、质量合格率、客户满意度等）估算培训投资回报
+- 需求优先级：紧迫性×重要性矩阵——区分"必须培训"、"应该培训"和"可自学"
+
+### D — Design（设计）
+- 选择教学策略和学习形式（线上/线下/混合）
+- 设计课程大纲和学习路径
+- 准备培训计划、讲师安排、场地和材料需求
+- 准备培训预算
+
+### D — Development（开发）
+- 访谈主题专家，萃取关键知识和经验
+- 开发课件、案例、练习和评估题库
+- 内部评审和试讲——收集反馈并迭代
+
+### I — Implementation（实施）
+- 训前：学员通知、预习任务推送、学习平台配置
+- 训中：课堂授课、互动管理、实时学习效果检查
+- 训后：作业布置、行动计划制定、学习社群建立
+
+### E — Evaluation（评估）
+- 收集培训满意度和学习评估数据
+- 追踪训后行为改变和业务指标变化
+- 产出培训效果报告和改进建议
+- 固化最佳实践，更新课程资源库
+
+## Key Principles
+- **阶段门控（Gate）**：每个阶段完成后必须通过评审才能进入下一阶段，确保质量
+- **迭代性**：在实际项目（尤其是快速迭代场景）可与 [[SAM-Model]] 混合使用
+- **以终为始**：从评估阶段开始反向设计（Backward Design），确保所有学习活动都指向可测量的目标
+
+## Connections
+- [[ADDIE-Model]] ← foundational_model ← [[SAM-Model]]（SAM 是 ADDIE 的快速迭代变体，适合敏捷场景）
+- [[Bloom-Taxonomy]] ← learning_objective_framework ← [[ADDIE-Model]]（ADDIE 的设计阶段使用 Bloom 分类定义学习目标）
+- [[Kirkpatrick-Model]] ← evaluation_framework ← [[ADDIE-Model]]（ADDIE 的 E 阶段通常采用 Kirkpatrick 四级评估）
diff --git a/wiki/concepts/AI-For-On-Call.md b/wiki/concepts/AI-For-On-Call.md
new file mode 100644
index 00000000..914af58a
--- /dev/null
+++ b/wiki/concepts/AI-For-On-Call.md
@@ -0,0 +1,55 @@
+---
+title: "AI For On-Call"
+type: concept
+tags: [sre, ai, on-call, incident-response, automation]
+last_updated: 2026-04-20
+---
+
+# AI For On-Call
+
+AI 在值班（On-Call）场景中的最佳应用不是自主修复，而是为值班工程师提供足够的上下文以快速修复故障。
+
+## Core Thesis
+> "AI's most valuable role in SRE isn't autonomous remediation. It's making sure on-call engineers have the context to fix incidents fast." — Heinrich Hartmann
+
+## Why Context Matters
+值班工程师在面对故障时最大的挑战不是不知道怎么做，而是：
+1. **信息过载**：日志、指标、告警太多，难以快速定位问题
+2. **上下文丢失**：不熟悉的服务/代码，需要时间理解
+3. **时间压力**：MTTR 目标要求快速响应
+
+## AI 辅助 On-Call 的关键场景
+
+### 1. 上下文聚合（Context Aggregation）
+AI 从多个来源聚合相关信息：
+- 告警历史和趋势
+- 相关的故障报告
+- 最近变更记录
+- 依赖服务状态
+
+### 2. 快速诊断辅助（Rapid Diagnosis）
+- 总结告警的根本原因
+- 推荐可能有效的修复步骤
+- 识别类似的已知问题
+
+### 3. 值班交接增强（On-Call Handoff）
+- 自动生成值班交接摘要
+- 突出显示未解决的问题
+- 提供历史上下文
+
+## What AI Should NOT Do
+- **自动执行修复**：缺乏足够上下文的自动修复可能造成更大损害
+- **绕过人工审批**：关键变更需要人工确认
+- **忽视不确定性**：AI 应清楚表达置信度
+
+## Related Products
+- [[RunLLM]]：专注于 On-Call 上下文增强的 AI 产品
+
+## Related Concepts
+- [[Incident-Response]]
+- [[Observability]]
+- [[Resilience]]
+- [[Self-Healing]]
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/concepts/AWS-Secrets-Manager.md b/wiki/concepts/AWS-Secrets-Manager.md
index a7671e37..c9c18e5a 100644
--- a/wiki/concepts/AWS-Secrets-Manager.md
+++ b/wiki/concepts/AWS-Secrets-Manager.md
@@ -1,39 +1,25 @@
----
-title: "AWS Secrets Manager"
-type: concept
-tags:
-  - AWS
-  - Secrets-Management
-  - Security
-last_updated: 2026-04-14
----
-
-## Definition
-AWS Secrets Manager 是 AWS 提供的完全托管式密钥管理服务，用于安全存储和检索应用程序、服务和 IT 资源的密钥。
-
-## Core Features
-- **内置数据库集成**：开箱即用支持 AWS RDS、Redshift、DynamoDB 等服务的密钥管理
-- **高可用与 DR**：托管服务自动实现跨可用区高可用和灾难恢复
-- **按用量计费**：基于 API 调用次数计费，无需预付成本
-- **自动密钥轮换**：通过 Lambda 函数实现数据库凭证自动轮换
-- **IAM 访问控制**：通过 IAM 角色和标签实现精细化权限管理
-- **账户级管理**：AWS 在账户级别管理密钥，可降低成本并提升安全性
-
-## Evaluation vs HashiCorp Vault
-| 维度 | AWS Secrets Manager | HashiCorp Vault |
-|------|---------------------|-----------------|
-| 部署模式 | 完全托管 | 自托管 |
-| 云厂商 | AWS 原生 | 云厂商无关 |
-| 成本模型 | 按用量计费 | 按用户数收费 |
-| 高可用 | 内置 | 企业版才支持 |
-| 动态密钥 | 支持 | 支持 |
-| 证书签名 | 不支持原生 | 支持嵌入式签名 |
-| 实施复杂度 | 简单易用 | 需要专业知识 |
-
-## Implementation Phases
-1. **试点阶段（30天）**：验证开箱即用功能，识别缺失功能（SSH 密钥轮换、用户密码轮换）
-2. **实施阶段**：从 Control Tower 开始，从 CI/CD 流程中清除明文密码和密钥，集中化管理
-
-## Sources
-- [[ctp-topic-37-secrets-certificates-management]]（选型评估）
-- [[ctp-topic-62-aws-secrets-manager]]（企业级深度实践）
+---
+title: "AWS Secrets Manager"
+type: concept
+tags:
+  - AWS
+  - Secrets Management
+  - Security
+sources:
+  - ctp-topic-12-using-ses-smtp-service-terraform-module
+  - ctp-topic-62-aws-secrets-manager
+last_updated: 2026-04-14
+---
+
+## Definition
+AWS Secrets Manager 是一项 AWS 服务，用于安全存储和检索敏感信息（如数据库凭证、API 密钥、SMTP 认证信息），支持自动轮换和精细的 IAM 访问控制。
+
+## Key Use Cases
+- 存储 SES SMTP 认证信息（IAM 用户 Access Key / Secret Key 转换后的用户名和密码）
+- Oracle DB 用户密码自动轮换（Lambda 函数连接 Oracle 实例执行轮换）
+- SendGrid API 密钥集中管理
+
+## Connections
+- [[CTP Topic 12 Using SES SMTP service terraform module]] — SES SMTP 凭证存储方案
+- [[CTP Topic 62 AWS Secrets Manager]] — 深度实践与标准文档
+- [[VPC Endpoint]] — 配合使用实现凭证的安全私有访问
diff --git a/wiki/concepts/Access-Control.md b/wiki/concepts/Access-Control.md
new file mode 100644
index 00000000..90342492
--- /dev/null
+++ b/wiki/concepts/Access-Control.md
@@ -0,0 +1,82 @@
+---
+title: "Access Control（访问控制）"
+type: concept
+tags: [blockchain, security, smart-contract, access-control]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Access Control
+- 访问控制 / 权限控制
+
+## Definition
+
+访问控制（Access Control）定义谁可以执行合约中的哪些操作。访问控制缺陷是智能合约最常见的高危漏洞类别之一，错误的权限配置可直接导致资金被盗或协议被永久阻塞。
+
+## Key Vulnerability Classes
+
+### 1. Missing Access Modifier（缺失访问修饰符）
+```solidity
+// VULNERABLE: withdraw() 没有访问控制，任何人都能调用
+function withdraw() external {
+    uint256 amount = balances[msg.sender];
+    (bool success,) = msg.sender.call{value: amount}("");
+    require(success);
+    balances[msg.sender] = 0;
+}
+```
+
+### 2. Wrong Access Modifier（错误的访问修饰符）
+```solidity
+// VULNERABLE: 应该是 onlyOwner，但误写成 external
+// 导致任何人都能调用紧急停止
+function emergencyStop() external {
+    paused = true;
+}
+```
+
+### 3. Unprotected initialization（未保护的初始化）
+```solidity
+// VULNERABLE: initialize() 没有 initializer 修饰符
+// 攻击者可抢先调用，劫持合约
+function initialize(address _owner) external {
+    owner = _owner;
+}
+```
+
+### 4. Proxy Storage Collision（代理存储冲突）
+升级型代理合约中，新实现版本的存储布局与旧版本不兼容，导致状态变量被覆盖：
+```solidity
+// Implementation V1
+uint256 public totalValue;      // slot 0
+
+// Implementation V2 — 新增变量导致 slot 0 被覆盖
+address public newAdmin;         // slot 0 ← 覆盖了 totalValue！
+uint256 public totalValue;       // slot 1
+```
+
+### 5. Role Renunciation Hijack（角色放弃劫持）
+允许 admin 放弃角色后无人能恢复，导致协议永久不可升级。
+
+## Audit Checklist
+
+- [ ] 所有特权函数都有显式访问修饰符
+- [ ] Admin 角色不能自我授予（需要多签或时间锁）
+- [ ] `initialize()` 只能调用一次（initializer 修饰符）
+- [ ] 实现合约构造函数中有 `_disableInitializers()`
+- [ ] `_authorizeUpgrade()` 受 owner/多签/时间锁保护
+- [ ] 存储布局在版本间兼容（无 slot 碰撞）
+- [ ] 无 `delegatecall` 到用户可控地址
+
+## Severity Classification
+
+- **Critical**：缺失关键特权函数的访问控制，可直接导致资金损失
+- **High**：条件性权限提升（需要特定状态），或协议可被 admin 永久阻塞
+- **Medium**：缺失非关键函数的访问控制
+- **Low**：缺少事件日志、代码规范问题
+
+## Related Concepts
+- [[Reentrancy]]：缺失访问控制会加剧重入攻击影响
+- [[Proxy-Upgrade]]：代理升级模式引入额外访问控制风险
+- [[OpenZeppelin]] 的 AccessControl 库是标准安全实现
diff --git a/wiki/concepts/Account-Reconciliation.md b/wiki/concepts/Account-Reconciliation.md
new file mode 100644
index 00000000..84ccaed6
--- /dev/null
+++ b/wiki/concepts/Account-Reconciliation.md
@@ -0,0 +1,59 @@
+---
+title: "Account Reconciliation"
+type: concept
+tags: [finance, accounting]
+sources: [finance-bookkeeper-controller]
+last_updated: 2026-05-02
+---
+
+## Definition
+账户调节（Account Reconciliation）是将总账（GL）余额与支持明细或分账余额进行核对的流程，确保每个账户的余额准确、完整、有据可查。
+
+## Purpose
+- 检测和纠正错误
+- 确保财务信息的准确性
+- 满足审计要求
+- 发现异常或欺诈信号
+
+## Core Template Structure
+
+### Balance Summary
+| Source | Amount |
+|--------|--------|
+| GL Balance (per trial balance) | $[X] |
+| Reconciliation Balance (per supporting detail) | $[X] |
+| **Difference** | **$[X]** |
+
+### Reconciling Items
+记录所有待处理差异，包括日期、描述、金额、状态和解决日期。
+
+### Adjusted Balance
+| Item | Amount |
+|------|--------|
+| GL Balance | $[X] |
+| + Reconciling Items | $[X] |
+| **Reconciled Balance** | **$[X]** |
+| Subledger / Support Balance | **$[X]** |
+| **Variance** | **$0** |
+
+## Common Reconciliation Types
+- 银行账户调节
+- 信用卡调节
+- AR aging 与 GL 核对
+- AP aging 与 GL 核对
+- 预付账款与摊销计划
+- 固定资产与折旧
+- 递延收入滚动表
+- 关联方交易调节
+- 权益变动调节
+- 工资税负债与申报表
+
+## Core Principle
+> "Reconciliation is not a chore — it's a detective process. Every unreconciled difference is a story waiting to be understood."
+> — Dana, Bookkeeper & Controller Agent
+
+## Related Concepts
+- [[Month-End-Close-Process]]
+- [[Journal Entry]]
+- [[Internal Controls]]
+- [[Audit Readiness]]
diff --git a/wiki/concepts/AccountArchitecture.md b/wiki/concepts/AccountArchitecture.md
index fdf2fad7..11ec2511 100644
--- a/wiki/concepts/AccountArchitecture.md
+++ b/wiki/concepts/AccountArchitecture.md
@@ -1,38 +1,52 @@
----
-title: "Account Architecture"
-type: concept
-tags: ["paid-media", "google-ads", "strategy", "structure"]
-last_updated: 2026-04-20
----
-
-## Aliases
-- Account Structure
-- Campaign Architecture
-- Google Ads Structure
-
-## Overview
-账户架构是 [[PaidMediaPpcStrategist]] 的核心理念：将整个广告账户视为一个系统，而非关键词和出价的简单集合。活动、广告组、受众、信号协同工作以驱动业务成果。
-
-## Key Components
-- **Campaign Structure**: 活动层级，定义预算、地理位置、受众、出价策略
-- **Ad Group Taxonomy**: 广告组分类，结构化组织关键词和受众
-- **Label Systems**: 标签系统，用于分类管理和自动化规则
-- **Naming Conventions**: 命名规范，确保规模化运营的可读性和可维护性
-
-## Best Practices (PPC Strategist)
-- 活动之间应隔离预算和目标，避免内耗
-- 广告组应保持主题一致性
-- 广泛匹配关键词配合智能竞价是规模化增长的核心
-- 负关键词架构防止无效流量侵蚀预算
-- 账户层级与 MCC（多账户管理）策略配合
-
-## Tiered Campaign Architecture
-- **Brand**: 品牌词保护，高转化，低成本
-- **Non-Brand**: 非品牌词，规模化增长的核心
-- **Competitor**: 竞品词，主动触达竞品用户
-- **Conquest**: 征服策略，针对高价值竞品用户
-
-## Related Concepts
-- [[TieredCampaignArchitecture]]: 分层活动架构的具体实现
-- [[SmartBidding]]: 账户架构中出价策略的选择
-- [[NegativeKeyword]]: 负关键词是账户架构的重要组成部分
+---
+title: "Account Architecture"
+type: concept
+tags: ["ppc", "account-structure", "google-ads", "enterprise", "paid-media"]
+sources: ["paid-media-ppc-strategist"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+账户架构（Account Architecture）是 PPC 广告账户的层级结构设计，包括 Campaign（广告系列）→ Ad Group（广告组）→ Keywords/Ads（关键词/广告）的完整层级体系，以及命名规范、标签系统、账户政策等辅助管理机制。核心理念：**账户架构即战略**（account structure as strategy）——而非单纯的关键词和出价管理。
+
+## Core Components
+
+### Account Level
+- **账户设置**：时区、货币、跳转追踪域名
+- **转化追踪**：Conversion Actions 配置（主/次、微/宏转化）
+- **用户权限**：多用户协作和访问级别
+
+### Campaign Level
+- **广告系列类型**：Search / Shopping / Performance Max / Demand Gen / Display / Video
+- **预算**：日预算或总预算
+- **地理定向**：国家/地区/DMA/城市级别定向
+- **语言定向**：受众语言
+- **投放时间**：Schedule 设置
+- **竞价策略**：Manual CPC / Automated Bidding
+
+### Ad Group Level
+- **关键词主题**：围绕单一主题/产品/意图的关键词分组
+- **广告变体**：同一广告组内多个广告文案轮播测试
+- **受众定向**：广告组级受众叠加
+
+## Naming Conventions at Scale
+
+支持数百个广告系列的命名规范示例：
+```
+{{Channel}}-{{Region}}-{{ProductLine}}-{{CampaignType}}-{{MatchType}}
+# 例如：
+SEA-US-Software-Competitor-Exact
+PMX-GLOBAL-Brand-Awareness-Broad
+```
+
+## Label System
+
+- **颜色标签**：按产品线/优先级/状态分类
+- **过滤器**：跨广告系列/广告组的灵活筛选
+- **脚本自动化**：通过 Labels + Scripts 实现批量操作
+
+## Connections
+- [[TieredCampaignArchitecture]]：Account Architecture 的具体实现模式
+- [[GoogleAds]]：Account Architecture 的主要操作平台
+- [[PerformanceMax]]：与标准广告系列结构不同的 AI 驱动架构
diff --git a/wiki/concepts/ActorReplication.md b/wiki/concepts/ActorReplication.md
new file mode 100644
index 00000000..132ce101
--- /dev/null
+++ b/wiki/concepts/ActorReplication.md
@@ -0,0 +1,42 @@
+---
+title: "Actor Replication"
+type: concept
+tags: ["unreal-engine", "networking", "multiplayer"]
+sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Actor 复制
+- 属性复制
+- Property Replication
+
+## 定义
+Actor 复制是 UE5 中将服务器端 Actor 状态同步到客户端的核心网络机制。通过 `UPROPERTY(Replicated)` 声明需要复制的属性。
+
+## 复制条件
+- `Replicated`: 无条件复制到所有相关客户端
+- `ReplicatedUsing=OnRep_Function`: 复制时触发 RepNotify 回调
+- `DOREPLIFETIME_CONDITION`: 按条件复制（如 `COND_OwnerOnly`、`COND_SimulatedOnly`）
+
+## 生命周期
+1. 服务器模拟游戏逻辑，更新 Actor 属性
+2. UE5 复制层检测属性变化
+3. 按 `NetUpdateFrequency` 打包更新
+4. 通过网络传输到客户端
+5. 客户端应用更新，触发 RepNotify（如果有）
+
+## 关键配置
+- `NetUpdateFrequency`: 更新频率（默认 100Hz，通常过高）
+- `MinNetUpdateFrequency`: 最小更新频率
+- `GetNetPriority()`: 优先级，靠近/可见的 Actor 优先级更高
+
+## 优化策略
+- Replication Graph 空间分区
+- 条件复制减少带宽
+- 按 Actor 类型设置差异化频率
+
+## 相关概念
+- [[Server-Authoritative Model]] — 复制背后的权威模型
+- [[Replication Graph]] — 复制优化框架
+- [[GAS (Gameplay Ability System)]] — 基于复制的能力系统
diff --git a/wiki/concepts/Agent-Collaboration-Protocol.md b/wiki/concepts/Agent-Collaboration-Protocol.md
new file mode 100644
index 00000000..728be8f2
--- /dev/null
+++ b/wiki/concepts/Agent-Collaboration-Protocol.md
@@ -0,0 +1,62 @@
+---
+title: "Agent Collaboration Protocol"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+
+规范化多 Agent 协作流程——定义何时发起协作、协作内容模板、协作边界及交接合同。
+
+## Overview
+
+在多 Agent 系统中，不同 Agent 负责不同专业领域。Agent Collaboration Protocol 为每个协作节点定义标准化协议，确保信息传递完整、意图清晰、交接无遗漏。
+
+## Core Components
+
+### 协作发起时机
+- 交接点：当前 Agent 工作完成后、需要下游 Agent 承接时
+- 依赖点：当前 Agent 需要上游 Agent 输出时
+- 冲突点：发现超出自身职责范围的问题时
+- 安全点：涉及凭证/密钥/认证等安全敏感操作时
+
+### 协作内容模板
+每个协作请求必须包含：
+1. **上下文摘要**：工作进展和已完成内容
+2. **具体请求**：需要对方完成什么
+3. **交付物格式**：期望的输出格式和结构
+4. **约束条件**：时间限制、质量标准、特殊要求
+5. **交接合同**：交接数据的 schema 定义
+
+### 协作边界
+- 不越权：不在自身职责外做决策
+- 不兜底：发现超出范围的问题时立即上报，而非自行处理
+- 不丢失：每次协作记录到 log.md，确保可追溯
+
+## Workflow Architect 中的协作协议
+
+| 协作方 | 时机 | 内容 | 交付物 |
+|--------|------|------|--------|
+| [[Reality-Checker]] | Draft spec 完成后、标记 Review 前 | 规范与实际代码差距验证 | Reality Checker Findings 表 |
+| [[Backend-Architect]] | 发现实现缺陷时 | 补充缺失逻辑（重试/错误处理） | 修复代码 |
+| [[Security-Engineer]] | 涉及凭证/密钥/认证/API 调用时 | 凭证传递机制安全性审查 | 安全评估意见 |
+| [[API-Tester]] | Spec 标记 Approved 后 | 生成全部测试用例 | 自动化测试脚本 |
+| [[DevOps-Automator]] | 揭示基础设施销毁顺序需求时 | 验证 IaC 销毁顺序 | 销毁顺序确认 |
+
+## Key Principles
+
+- **主动发起**：发现需要协作时立即发起，不等待
+- **标准化模板**：每次协作使用统一格式，减少理解成本
+- **明确边界**：知道自己不做什么，比知道自己做什么更重要
+- **完整交接**：交接内容包括所有上下文，而非仅最终结果
+
+## Related Concepts
+- [[Handoff-Contract]]：协作交接的数据 schema 定义
+- [[Reality-Checker]]：Workflow Architect 的首个强制协作节点
+- [[Workflow-Tree-Spec]]：协作产出的主要载体
+
+## Aliases
+- Multi-Agent Handoff Protocol
+- Agent Coordination Framework
+- Inter-Agent Collaboration Standard
diff --git a/wiki/concepts/Agent-Collapse.md b/wiki/concepts/Agent-Collapse.md
new file mode 100644
index 00000000..25f89727
--- /dev/null
+++ b/wiki/concepts/Agent-Collapse.md
@@ -0,0 +1,32 @@
+---
+title: "Agent Collapse"
+type: concept
+tags:
+  - "agentic-ai"
+  - "failure-mode"
+  - "context-window"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+Agent Collapse（10-Step Collapse）——AI Agent 在多步任务执行过程中逐渐崩溃的现象，典型表现为步骤 1-3 正常执行，步骤 7 开始幻觉数据，步骤 10 输出损坏的 JSON 或崩溃。
+
+## Root Causes
+- **Context window 静默截断**：工具输出超出上下文窗口后被静默截断，模型感知不到数据丢失
+- **无 Schema 验证**：LLM 输出的字段类型漂移（price 从 float 变为 string），下游管道静默产生垃圾数据
+- **无状态管理**：context window 是易失的，关键状态（如 pending/in-progress/completed 标记）随上下文重置丢失
+- **无幂等重试**：单步失败导致整个管道重启，而非精确重试失败步骤
+
+## Manifestation Example
+> 部署一个自主 Agent 编写市场研究报告。步骤 1-3 完美执行：计划任务 → 搜索网页 → 提取竞品数据。步骤 7 开始幻觉统计数据（因为搜索工具 payload 超出上下文窗口被静默截断）。步骤 10 输出损坏的 JSON 字符串（因为管道中没有 Schema 验证器）。
+
+## Solutions
+- [[Harness-Engineering]]：系统性地为每个失效点增加防护层
+- [[State-Externalization]]：将任务状态写入磁盘，不依赖 context window
+- [[Schema-Drift]] 防护：每个 LLM 输出必须经过 JSON Schema 验证
+- [[Idempotency]]：单步失败只重试该步，不重启管道
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
diff --git a/wiki/concepts/Agent-Handoff.md b/wiki/concepts/Agent-Handoff.md
new file mode 100644
index 00000000..ca6bf132
--- /dev/null
+++ b/wiki/concepts/Agent-Handoff.md
@@ -0,0 +1,39 @@
+---
+title: "Agent Handoff"
+type: concept
+tags: [multi-agent, coordination, handoff, nexus]
+sources: [executive-brief, quickstart, workflow-with-memory]
+last_updated: 2026-05-01
+aliases:
+  - Agent Handoff Protocol
+  - Structured Handoff
+  - Context Continuity
+---
+
+## Definition
+
+Agent 交接（Agent Handoff）—— 多 Agent 工作流中从一个 Agent 交付物传递到下一个 Agent 的结构化上下文传递协议，确保接收 Agent 获得完整的执行上下文，避免冷启动和重复劳动。
+
+## Core Problem
+
+**交接边界失败率：73%** —— 当 Agent 缺乏结构化协调协议时，多 Agent 项目在交接边界处的失败率高达 73%，表现为：
+- 上下文丢失（交接时未传递关键决策和中间产物）
+- 重复劳动（下一个 Agent 重复上一个 Agent 已完成的工作）
+- 质量缺口（上一个 Agent 的缺陷传递到下一个 Agent）
+
+## Structured Handoff Components
+
+一份完整的 Agent 交接应包含：
+
+1. **交付物清单**：明确列出发交给下一 Agent 的所有文件和产出
+2. **上下文摘要**：用 3-5 句话总结当前状态和已完成的关键决策
+3. **下一步指令**：清楚描述下一 Agent 需要完成的具体任务
+4. **质量证据**：提供可验证的质量证明（测试截图/性能数据/设计评审通过记录）
+5. **风险标记**：标注已知的限制条件和潜在风险
+
+## Related Concepts
+
+- [[Handoff Boundary]]：交接的边界点，即失败率最高的 73% 失败发生处
+- [[Evidence Over Claims]]：交接内容必须包含可验证的证据，而非口头承诺
+- [[Quality Gate]]：交接后需通过质量门控验证才能推进
+- [[Memory-Based-Handoff]]：通过 MCP Memory Server 实现自动化的 Agent 交接机制
diff --git a/wiki/concepts/Agent-Orchestration.md b/wiki/concepts/Agent-Orchestration.md
new file mode 100644
index 00000000..24f227ce
--- /dev/null
+++ b/wiki/concepts/Agent-Orchestration.md
@@ -0,0 +1,33 @@
+---
+title: "Agent-Orchestration"
+type: concept
+tags: []
+---
+
+## Definition
+Agent 编排（Agent Orchestration）是指通过工作流引擎统一协调和调度多个 AI Agent，使它们协同工作完成复杂任务的管理模式。
+
+## Key Patterns
+- **集中式编排**：单一工作流引擎（n8n）控制多个 Agent 的调用顺序和数据流转
+- **并行调用**：同一工作流中同时调用多个 Agent（如 Hermes + OpenClaw）
+- **条件路由**：根据前一个 Agent 的输出决定调用哪个 Agent
+
+## n8n 编排架构示例
+```
+n8n Workflow
+  ├─ Trigger (Telegram/Email/Webhook...)
+  ├─ HTTP Request Node 1 → Hermes Agent (port 8642)
+  ├─ HTTP Request Node 2 → OpenClaw Agent (port 18789)
+  └─ Output Node (Telegram/File/Email...)
+```
+
+## 优势
+- **统一入口**：用户通过单一界面与多个 Agent 交互
+- **数据流转**：一个 Agent 的输出可直接作为另一个 Agent 的输入
+- **可观测性**：工作流引擎提供执行日志和状态追踪
+- **灵活性**：可随时增删 Agent，不影响整体架构
+
+## Related
+- [[n8n]] 是本 Wiki 中记录的编排工具
+- [[Hermes-Agent]] 和 [[OpenClaw]] 是被编排的 Agent 示例
+- [[OpenAI-Compatible-API]] 是连接 Agent 的标准接口
diff --git a/wiki/concepts/Agent-Template.md b/wiki/concepts/Agent-Template.md
index 8fecfc41..77ebcdb9 100644
--- a/wiki/concepts/Agent-Template.md
+++ b/wiki/concepts/Agent-Template.md
@@ -1,77 +1,77 @@
----
-title: "Agent Template"
-type: concept
-tags: [multi-agent, agent-design, the-agency]
-sources: [contributing_zh-cn, contributing-to-the-agency]
-last_updated: 2026-04-24
----
-
-# Agent Template
-
-The standardized YAML frontmatter + structured document template for creating The Agency agents.
-
-## YAML Frontmatter
-
-```yaml
----
-name: Agent Name
-description: One-sentence description of agent's specialty and positioning
-color: Color Name or "#hex-value"
----
-```
-
-## Document Structure
-
-### 🧠 Identity & Memory
-- **Role**: Clear role description
-- **Personality**: Personality traits and communication style
-- **Memory**: What the agent needs to remember and learn
-- **Experience**: Domain expertise and perspective
-
-### 🎯 Core Mission
-- Core Responsibility 1 (with clear deliverables)
-- Core Responsibility 2 (with clear deliverables)
-- Core Responsibility 3 (with clear deliverables)
-- **Default Requirement**: Always follow best practices
-
-### 🚨 Critical Rules
-Domain-specific rules and constraints that define how the agent operates.
-
-### 📋 Technical Deliverables
-Concrete outputs the agent produces:
-- Code examples
-- Templates
-- Frameworks
-- Documentation
-
-### 🔄 Workflow
-Step-by-step process the agent follows:
-1. Phase 1: Exploration & Research
-2. Phase 2: Planning & Strategy
-3. Phase 3: Execution & Implementation
-4. Phase 4: Review & Optimization
-
-### 💭 Communication Style
-- How the agent communicates
-- Example phrases and expression patterns
-- Tone and style
-
-### 🔄 Learning & Memory
-What the agent continuously learns from:
-- Success patterns
-- Failure cases
-- User feedback
-- Domain evolution
-
-### 🎯 Success Metrics
-Quantifiable outcomes:
-- Quantitative metrics (with specific values)
-- Qualitative metrics
-- Performance benchmarks
-
-### 🚀 Advanced Capabilities
-Advanced techniques and methods the agent masters.
-
-## Connections
-- Implements [[Agent-Design-Principles]] — structural template for the five design principles
-- Used in [[Multi-Agent-Team]] — standardized agent creation
+---
+title: "Agent Template"
+type: concept
+tags: [multi-agent, agent-design, the-agency]
+sources: [contributing_zh-cn, contributing, contributing-to-the-agency]
+last_updated: 2026-04-27
+---
+
+# Agent Template
+
+The standardized YAML frontmatter + structured document template for creating The Agency agents.
+
+## YAML Frontmatter
+
+```yaml
+---
+name: Agent Name
+description: One-sentence description of agent's specialty and positioning
+color: Color Name or "#hex-value"
+---
+```
+
+## Document Structure
+
+### 🧠 Identity & Memory
+- **Role**: Clear role description
+- **Personality**: Personality traits and communication style
+- **Memory**: What the agent needs to remember and learn
+- **Experience**: Domain expertise and perspective
+
+### 🎯 Core Mission
+- Core Responsibility 1 (with clear deliverables)
+- Core Responsibility 2 (with clear deliverables)
+- Core Responsibility 3 (with clear deliverables)
+- **Default Requirement**: Always follow best practices
+
+### 🚨 Critical Rules
+Domain-specific rules and constraints that define how the agent operates.
+
+### 📋 Technical Deliverables
+Concrete outputs the agent produces:
+- Code examples
+- Templates
+- Frameworks
+- Documentation
+
+### 🔄 Workflow
+Step-by-step process the agent follows:
+1. Phase 1: Exploration & Research
+2. Phase 2: Planning & Strategy
+3. Phase 3: Execution & Implementation
+4. Phase 4: Review & Optimization
+
+### 💭 Communication Style
+- How the agent communicates
+- Example phrases and expression patterns
+- Tone and style
+
+### 🔄 Learning & Memory
+What the agent continuously learns from:
+- Success patterns
+- Failure cases
+- User feedback
+- Domain evolution
+
+### 🎯 Success Metrics
+Quantifiable outcomes:
+- Quantitative metrics (with specific values)
+- Qualitative metrics
+- Performance benchmarks
+
+### 🚀 Advanced Capabilities
+Advanced techniques and methods the agent masters.
+
+## Connections
+- Implements [[Agent-Design-Principles]] — structural template for the five design principles
+- Used in [[Multi-Agent-Team]] — standardized agent creation
diff --git a/wiki/concepts/AgentIntegration.md b/wiki/concepts/AgentIntegration.md
new file mode 100644
index 00000000..562d9835
--- /dev/null
+++ b/wiki/concepts/AgentIntegration.md
@@ -0,0 +1,38 @@
+---
+title: "Agent Integration"
+type: concept
+tags: []
+sources: [qwen-readme]
+last_updated: 2026-05-01
+---
+
+## Overview
+Agent Integration（Agent 集成适配）是将统一的 Markdown Agent 规范转换为各 AI 编码工具原生格式的适配层技术。The Agency 通过 `convert.sh` 和 `install.sh` 两层脚本实现这一目标。
+
+## Definition
+Agent Integration = 统一的 Agent 行为规范（`.md`） + 工具特定的转换器（`convert.sh`） + 标准化的安装机制（`install.sh`）
+
+## Key Properties
+- **单向转换**：从源 `.md` 到目标格式，不做反向同步
+- **工具原生**：转换后的格式是该工具推荐/唯一的配置方式
+- **作用域分层**：Home-Scoped（全用户级）vs Project-Scoped（项目级）
+- **注册机制差异**：部分工具依赖自动发现（如 Claude Code），部分需要显式启动参数（如 Kimi `--agent-file`）
+
+## Integration Patterns
+| 工具 | 格式 | 作用域 | 注册机制 |
+|------|------|--------|---------|
+| Claude Code | `.md` | Home | 自动发现 |
+| GitHub Copilot | `.md` | Home | 自动发现 |
+| Antigravity | `SKILL.md` | Home | 工具内置 |
+| Gemini CLI | 扩展包 + Skill | Home | 自动加载 |
+| OpenCode | `.md` | Project | 自动发现 |
+| OpenClaw | `SOUL.md+AGENTS.md+IDENTITY.md` | Home | Gateway |
+| Cursor | `.mdc` | Project | 自动发现 |
+| Aider | `CONVENTIONS.md` | Project | 自动发现 |
+| Windsurf | `.windsurfrules` | Project | 自动发现 |
+| Kimi Code | YAML | Home | 显式启动参数 |
+| Qwen Code | `.md` SubAgent | Project | 自动发现 |
+
+## Sources
+- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
+- [[OpenClaw Integration]]（`Agent/agency-agents/integrations/openclaw/README.md`）
diff --git a/wiki/concepts/AgentScopes.md b/wiki/concepts/AgentScopes.md
new file mode 100644
index 00000000..bebaa854
--- /dev/null
+++ b/wiki/concepts/AgentScopes.md
@@ -0,0 +1,33 @@
+---
+title: "Agent Scopes"
+type: concept
+tags: []
+last_updated: 2026-04-29
+---
+
+## Overview
+Agent Scopes（Agent 作用域）指 AI 编码 Agent 的生效范围，决定了 Agent 配置是全局共享还是项目专用。这是 The Agency 集成架构中的重要维度。
+
+## Home-Scoped Agent（全用户级 Agent）
+- 安装位置：用户家目录（如 `~/.claude/agents/`、`~/.gemini/`）
+- 生效范围：该用户所有项目均可用
+- 安装方式：`./scripts/install.sh --tool <tool>`
+- 代表工具：Claude Code、GitHub Copilot、Antigravity、Gemini CLI、OpenClaw、Kimi Code
+
+## Project-Scoped Agent（项目级 Agent）
+- 安装位置：项目根目录（如 `./.opencode/agents/`、`./.windsurfrules`）
+- 生效范围：仅当前项目可用
+- 安装方式：从项目根目录运行 `./scripts/install.sh --tool <tool>`
+- 代表工具：OpenCode、Cursor、Aider、Windsurf、Qwen Code
+
+## Key Differences
+| 维度 | Home-Scoped | Project-Scoped |
+|------|-------------|----------------|
+| 安装路径 | `~/.tool/` | `./.tool/` |
+| 多项目复用 | ✅ | ❌ |
+| 项目定制化 | ❌ | ✅ |
+| 权限控制 | 用户级 | 仓库级（可提交 git） |
+| 冲突风险 | 高（同名覆盖） | 低（项目隔离） |
+
+## Sources
+- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
diff --git a/wiki/concepts/AgentWorkspace.md b/wiki/concepts/AgentWorkspace.md
new file mode 100644
index 00000000..1a8691ff
--- /dev/null
+++ b/wiki/concepts/AgentWorkspace.md
@@ -0,0 +1,24 @@
+---
+title: "Agent Workspace"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Overview
+Agent Workspace（Agent 工作区）是 AI Agent 的定义容器单元，包含 Agent 的全部行为规范、身份和配置信息。
+
+## Definition
+Agent Workspace = 行为规范（AGENTS.md/SOUL.md）+ 身份定义（IDENTITY.md）+ 其他配置文件
+
+## Key Properties
+- **多文件结构**：OpenClaw Workspace 包含 `SOUL.md`（核心理念）、`AGENTS.md`（行为规范）、`IDENTITY.md`（身份定义）三文件
+- **安装即注册**：Workspace 复制到目标路径即完成 Agent 注册，无需额外配置
+- **工具特定性**：不同工具对 Workspace 格式要求不同（OpenClaw 三文件 vs OpenCode 单文件）
+
+## Relationships
+- [[AgentIntegration]] ← uses ← [[AgentWorkspace]]（Workspace 是集成的最小单元）
+- [[OpenClaw]] ← manages ← [[AgentWorkspace]]
+
+## Sources
+- [[OpenClaw Integration]]（`Agent/agency-agents/integrations/openclaw/README.md`）
diff --git a/wiki/concepts/AirGappedSLMFixGeneration.md b/wiki/concepts/AirGappedSLMFixGeneration.md
new file mode 100644
index 00000000..a7d0727c
--- /dev/null
+++ b/wiki/concepts/AirGappedSLMFixGeneration.md
@@ -0,0 +1,37 @@
+---
+title: "Air-Gapped SLM Fix Generation"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+
+在完全离线（气隙）的环境中，通过本地 Small Language Models（SLM，如 Ollama 运行的 Phi-3/Llama-3/Mistral）生成确定性修复逻辑（Python lambda）的方法论。
+
+## Core Principle
+
+**AI generates logic — never touches data directly.**
+
+SLM 输出的是一个转换函数（lambda），由系统执行，而非 AI 直接修改数据。这样保证了可审计、可回滚、可解释的数据变更。
+
+## Workflow
+
+1. SLM 接收聚类样本 + 列名
+2. SLM 输出严格格式化的 JSON（含 transformation、confidence_score、reasoning、pattern_type）
+3. Lambda Safety Gate 验证（必须以 `lambda` 开头，不含 `import/exec/eval/os/subprocess`）
+4. 验证通过后向量化执行于整个聚类
+5. 低于 0.75 置信度的自动进入人工隔离队列
+
+## Safety Guarantees
+
+- **Zero PII Egress**: 所有处理完全本地，无网络出口
+- **Deterministic Output**: SLM 输出确定性 lambda，不做创意性文本生成
+- **Safety Gate**: 任何包含危险关键词的 lambda 立即被拒绝并路由至隔离区
+- **Audit Trail**: 每条数据变更记录完整上下文
+
+## Related
+
+- [[Semantic Anomaly Compression]]
+- [[Lambda Safety Gate]]
+- [[AI Generates Logic Not Data]]
diff --git a/wiki/concepts/Annales-School.md b/wiki/concepts/Annales-School.md
index bfabc4a1..bad6abb5 100644
--- a/wiki/concepts/Annales-School.md
+++ b/wiki/concepts/Annales-School.md
@@ -1,40 +1,44 @@
----
-title: "Annales School"
-type: concept
-tags: ["historiography", "french-history", "material-culture", "longue-duree"]
-sources: ["academic-historian"]
-last_updated: 2026-04-25
----
-
-## Definition
-法国史学流派，以《年鉴》（*Annales d'histoire économique et sociale*，1929年创刊）为核心阵地，由马克·布洛赫（Marc Bloch）和吕西安·费弗尔（Lucien Febvre）共同创立。主张历史研究应突破传统政治军事史的局限，关注普通人的日常生活、物质条件和长期社会结构。
-
-## Core Principles
-- **物质条件优先**：在讨论政治/军事/思想之前，必须先理解经济基础、农业、贸易和技术
-- **长时段视角（Longue Durée）**：历史变化发生在几十年乃至几个世纪的时间尺度上，聚焦于塑造事件发生的深层结构
-- **日常生活史（*Histoire du quotidien*）**：关注饮食、服饰、建筑、信仰、恐惧——Annales 学派不只写国王和战争
-- **跨学科方法**：整合地理学、经济学、社会学、人类学、人口学的方法论
-- **问题导向史学**：以问题而非编年驱动历史研究
-
-## Key Figures
-- **马克·布洛赫**（Marc Bloch，1886-1944）：年鉴学派创始人之一，《封建社会》作者，二战期间参加抵抗运动后被枪决
-- **吕西安·费弗尔**（Lucien Febvre，1878-1956）：年鉴学派创始人之一，专注于16世纪精神状态史
-- **费尔南·布罗代尔**（Fernand Braudel，1902-1985）：年鉴学派第二代领袖，《菲利普二世时代的地中海和地中海世界》——长时段理论的奠基之作，将历史分为三个时间层次：地理时间（长时段）、社会时间（中时段）、事件时间（短时段）
-- **埃马纽埃尔·勒华拉杜里**（Emmanuel Le Roy Ladurie，*Montaillou* 作者）：微观史的代表人物
-
-## Relationship to Historiography
-- **反对**：兰克学派（Rankean）聚焦政治史和伟大人物的传统史学；辉格史观（Whig History）以现代标准评判历史
-- **影响**：新文化史、微观史、历史社会学、后殖民史学均受其影响
-- **对话/张力**：年鉴学派有时因过度关注结构而被批评忽视个体能动性（agency），微观史（Microhistory）部分是对此的回应
-
-## Connections
-- [[Geographic-Coherence]] ← 理论关联 ← [[Annales-School]]：两者都强调物质地理条件对人类历史的约束作用
-- [[academic-historian]] ← 方法论来源 ← [[Annales-School]]：Historian Agent 优先使用年鉴学派方法
-- [[Longue-Duree]] ← 核心概念 ← [[Annales-School]]：长时段分析是年鉴学派最重要的方法论贡献
-
-## Aliases
-- 年鉴学派
-- Annales
-- Annales d'histoire économique et sociale
-- Annales School of historiography
-- French historical school
+---
+title: "Annales School"
+type: concept
+tags: ["historiography", "french-history", "material-culture", "longue-duree"]
+sources: ["academic-historian"]
+last_updated: 2026-04-25
+---
+
+## Definition
+法国史学流派，以《年鉴》（*Annales d'histoire économique et sociale*，1929年创刊）为核心阵地，由马克·布洛赫（Marc Bloch）和吕西安·费弗尔（Lucien Febvre）共同创立。主张历史研究应突破传统政治军事史的局限，关注普通人的日常生活、物质条件和长期社会结构。
+
+## Core Principles
+- **物质条件优先**：在讨论政治/军事/思想之前，必须先理解经济基础、农业、贸易和技术
+- **长时段视角（Longue Durée）**：历史变化发生在几十年乃至几个世纪的时间尺度上，聚焦于塑造事件发生的深层结构
+- **日常生活史（*Histoire du quotidien*）**：关注饮食、服饰、建筑、信仰、恐惧——Annales 学派不只写国王和战争
+- **跨学科方法**：整合地理学、经济学、社会学、人类学、人口学的方法论
+- **问题导向史学**：以问题而非编年驱动历史研究
+
+## Key Figures
+- **马克·布洛赫**（Marc Bloch，1886-1944）：年鉴学派创始人之一，《封建社会》作者，二战期间参加抵抗运动后被枪决
+- **吕西安·费弗尔**（Lucien Febvre，1878-1956）：年鉴学派创始人之一，专注于16世纪精神状态史
+- **费尔南·布罗代尔**（Fernand Braudel，1902-1985）：年鉴学派第二代领袖，《菲利普二世时代的地中海和地中海世界》——长时段理论的奠基之作，将历史分为三个时间层次：地理时间（长时段）、社会时间（中时段）、事件时间（短时段）
+- **埃马纽埃尔·勒华拉杜里**（Emmanuel Le Roy Ladurie，*Montaillou* 作者）：微观史的代表人物
+
+## Relationship to Historiography
+- **反对**：兰克学派（Rankean）聚焦政治史和伟大人物的传统史学；辉格史观（Whig History）以现代标准评判历史
+- **影响**：新文化史、微观史、历史社会学、后殖民史学均受其影响
+- **对话/张力**：年鉴学派有时因过度关注结构而被批评忽视个体能动性（agency），微观史（Microhistory）部分是对此的回应
+
+- [[Microhistory]] ← 方法论回应 ← [[Annales-School]]：微观史是对年鉴学派过度结构决定论批评的回应之一
+- [[Material-Culture]] ← 核心关注 ← [[Annales-School]]：物质文化是年鉴学派历史分析的第一层
+
+## Connections
+- [[Geographic-Coherence]] ← 理论关联 ← [[Annales-School]]：两者都强调物质地理条件对人类历史的约束作用
+- [[academic-historian]] ← 方法论来源 ← [[Annales-School]]：Historian Agent 优先使用年鉴学派方法
+- [[Longue-Duree]] ← 核心概念 ← [[Annales-School]]：长时段分析是年鉴学派最重要的方法论贡献
+- [[Microhistory]] ← 方法论互补 ← [[Annales-School]]：微观史是对年鉴学派的结构决定论倾向的回应
+
+## Aliases
+- 年鉴学派
+- Annales
+- Annales d'histoire économique et sociale
+- Annales School of historiography
+- French historical school
diff --git a/wiki/concepts/Answer-Engine-Optimization.md b/wiki/concepts/Answer-Engine-Optimization.md
index 810bdee1..c1a27bdf 100644
--- a/wiki/concepts/Answer-Engine-Optimization.md
+++ b/wiki/concepts/Answer-Engine-Optimization.md
@@ -1,43 +1,39 @@
 ---
-title: "Answer Engine Optimization (AEO)"
+title: "Answer Engine Optimization"
 type: concept
-tags: ["AI", "SEO", "marketing", "visibility"]
-last_updated: 2026-04-26
+tags: ["SEO", "AI", "marketing", "AEO"]
+sources: ["marketing-ai-citation-strategist"]
+last_updated: 2026-04-30
 ---
 
 ## Definition
 
-Answer Engine Optimization (AEO) 是针对 AI 问答引擎的优化策略，旨在使品牌内容被 AI 助手（ChatGPT、Claude、Gemini、Perplexity 等）在生成答案时引用。与传统 SEO 不同，AEO 的目标不是让页面在搜索结果中排名靠前，而是让内容成为 AI 合成的"可信来源"。
+Answer Engine Optimization（AEO，答案引擎优化）：一种专注于让内容在 AI 推荐引擎（如 ChatGPT、Claude、Gemini、Perplexity）中被直接引用推荐的营销技术。与传统 SEO 不同，AEO 优化的不是页面排名，而是内容被 AI 合成答案选为来源的可能性。
 
 ## Core Principles
 
-1. **答案优先**：内容应直接回答用户问题，而非围绕关键词优化
-2. **结构化权威**：使用 FAQ、步骤指南、对比表格等 AI 友好格式
-3. **实体清晰**：明确的品牌、产品、概念实体标注
-4. **来源归属**：让 AI 能准确识别内容归属和可信度
+1. **AI 引用 ≠ SEO 排名**：SEO 信号（关键词密度、反向链接、页面速度）与 AEO 信号（实体清晰度、结构化权威、FAQ 对齐、Schema 标记）完全不同
+2. **引用是概率性的**：AI 响应具有非确定性，只能"提升引用概率"而非"保证被引用"
+3. **多平台差异化**：每个 AI 引擎有不同内容偏好和引用行为，必须针对平台定制
 
-## AEO vs SEO
+## Key Signals
 
-| 维度 | 传统 SEO | AEO |
-|------|---------|-----|
-| 目标 | 页面排名 | 被引用为来源 |
-| 优化对象 | 搜索引擎爬虫 | AI 模型推理 |
-| 核心信号 | 外链、关键词密度 | 实体清晰度、Schema markup、FAQ 对齐 |
-| 衡量指标 | 排名、点击率 | Citation Rate、Share of Voice |
-
-## Key Tactics
-
-- **FAQ Schema**：添加 FAQPage/FAQQuestion schema markup
-- **How-To Content**：结构化步骤指南，满足"How to"类查询
-- **Comparison Pages**：独立的品牌/产品对比页，满足"X vs Y"类查询
-- **Direct Answers**：在内容开头直接给出答案，而非铺垫
+| 信号类型 | 说明 | 适用平台 |
+|---------|------|---------|
+| Entity Clarity | 品牌/产品在知识图谱中清晰可识别 | 所有平台 |
+| Structured Authority | FAQ、对比表、how-to指南等结构化内容 | ChatGPT/Gemini |
+| FAQ Alignment | Q&A 内容匹配用户实际输入 AI 的查询模式 | ChatGPT |
+| Schema Markup | Organization/Product/FAQ 结构化数据 | Gemini/Perplexity |
+| Source Diversity | 多样化的权威来源引用 | Perplexity |
+| Recency | 时效性内容 | Perplexity |
 
 ## Related Concepts
 
-- [[Generative Engine Optimization (GEO)]]：更广泛的生成式 AI 引擎可见性优化
-- [[Citation Rate]]：衡量 AEO 效果的量化指标
-- [[Entity Optimization]]：实体信号强化是 AEO 的核心技术
+- [[Generative Engine Optimization]]（GEO）— AEO 的扩展，涵盖更广泛的 AI 生成内容可见性
+- [[Schema Markup]] — AEO 的关键技术手段之一
+- [[Citation Audit Scorecard]] — AEO 效果的可量化评估工具
 
-## Sources
+## Relationships
 
-- [[AI Citation Strategist]]
+- 互补于 → [[marketing-seo-specialist]]
+- 扩展为 → [[marketing-ai-citation-strategist]]
diff --git a/wiki/concepts/Architectural-Empathy.md b/wiki/concepts/Architectural-Empathy.md
index a755a132..e65f8514 100644
--- a/wiki/concepts/Architectural-Empathy.md
+++ b/wiki/concepts/Architectural-Empathy.md
@@ -1,39 +1,41 @@
----
-title: "Architectural Empathy"
-type: concept
-tags: [ux-design, cultural-intelligence, design-philosophy]
-sources: [specialized-cultural-intelligence-strategist]
-last_updated: 2026-04-25
----
-
-## Definition
-通过结构性解决方案而非表演性行为来实现包容性的设计哲学——在系统架构层面消除排斥根源，而非在产品表面添加"看起来包容"的元素。Architectural Empathy Engine 是 [[Cultural-Intelligence-Strategist]] 的角色定位，强调同理心必须融入产品的骨架，而非仅装饰于表面。
-
-## Core Principles
-
-### 1. Structural > Cosmetic
-- ❌ 在首页添加一张多元人群图
-- ✅ 重新设计表单字段以接受全球命名结构
-
-### 2. Precondition, Not Afterthought
-- ❌ 产品上线后再考虑国际化
-- ✅ 国际化是架构设计的前提条件（Global-First Architecture）
-
-### 3. "Who is left out?" as First Question
-每个工作流审查的第一个问题必须是："如果用户是神经多样性者、视障者、非西方文化背景者、或使用不同历法，这个设计还能工作吗？"
-
-### 4. Absolute Cultural Humility
-永远不声称当前知识是完整的。在为任何群体生成内容前，必须自主研究该群体的当前、尊重、赋权的表征标准。
-
-## Relationship to Other Concepts
-- [[Invisible-Exclusion]]：Architectural Empathy 的诊断对象
-- [[Global-First-Architecture]]：Architectural Empathy 的实施方法
-- [[Cultural-Intelligence]]：Architectural Empathy 的知识基础
-
-## Contrast: Performative vs. Structural Empathy
-| 维度 | 表演性同理心 | 结构性同理心 |
-|------|------------|------------|
-| 位置 | 表面层 | 架构层 |
-| 效果 | 短期感知改善 | 长期用户摩擦消除 |
-| 检测方式 | 多元图片存在 | APAC 用户转化率提升 |
-| 维护 | 每次更新需重新添加 | 架构内建，持续有效 |
+---
+title: "Architectural Empathy"
+type: concept
+tags: [ux-design, cultural-intelligence, design-philosophy]
+sources: [specialized-cultural-intelligence-strategist]
+last_updated: 2026-05-29
+---
+
+## Definition
+通过结构性解决方案而非表演性行为来实现包容性的设计哲学——在系统架构层面消除排斥根源，而非在产品表面添加"看起来包容"的元素。Architectural Empathy Engine 是 [[Cultural-Intelligence-Strategist]] 的角色定位，强调同理心必须融入产品的骨架，而非仅装饰于表面。
+
+## Core Principles
+
+### 1. Structural > Cosmetic
+- ❌ 在首页添加一张多元人群图
+- ✅ 重新设计表单字段以接受全球命名结构
+
+### 2. Precondition, Not Afterthought
+- ❌ 产品上线后再考虑国际化
+- ✅ 国际化是架构设计的前提条件（Global-First Architecture）
+
+### 3. "Who is left out?" as First Question
+每个工作流审查的第一个问题必须是："如果用户是神经多样性者、视障者、非西方文化背景者、或使用不同历法，这个设计还能工作吗？"
+
+### 4. Absolute Cultural Humility
+永远不声称当前知识是完整的。在为任何群体生成内容前，必须自主研究该群体的当前、尊重、赋权的表征标准。
+
+## Relationship to Other Concepts
+- [[Invisible-Exclusion]]：Architectural Empathy 的诊断对象
+- [[Global-First-Architecture]]：Architectural Empathy 的实施方法
+- [[Cultural-Intelligence]]：Architectural Empathy 的知识基础
+
+## Aliases
+- Structural Empathy（结构性同理心）
+- Architectural Empathy
+| 维度 | 表演性同理心 | 结构性同理心 |
+|------|------------|------------|
+| 位置 | 表面层 | 架构层 |
+| 效果 | 短期感知改善 | 长期用户摩擦消除 |
+| 检测方式 | 多元图片存在 | APAC 用户转化率提升 |
+| 维护 | 每次更新需重新添加 | 架构内建，持续有效 |
diff --git a/wiki/concepts/ArchitectureDecisionRecord.md b/wiki/concepts/ArchitectureDecisionRecord.md
new file mode 100644
index 00000000..1e5789e8
--- /dev/null
+++ b/wiki/concepts/ArchitectureDecisionRecord.md
@@ -0,0 +1,50 @@
+---
+title: "Architecture Decision Record"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+Architecture Decision Record（架构决策记录）是一种轻量级文档，用于捕获架构决策的上下文、选项和理由。ADR 记录的是"为什么这样做"，而不仅仅是"做了什么"。
+
+## ADR Format
+
+```markdown
+# ADR-001: [Decision Title]
+
+## Status
+Proposed | Accepted | Deprecated | Superseded by ADR-XXX
+
+## Context
+What is the issue that we're seeing that is motivating this decision?
+
+## Decision
+What is the change that we're proposing and/or doing?
+
+## Consequences
+What becomes easier or harder because of this change?
+```
+
+## Key Elements
+- **Status**：Proposed（提议中）/ Accepted（已接受）/ Deprecated（已废弃）/ Superseded（被替代）
+- **Context**：驱动决策的问题或背景
+- **Decision**：具体的决策内容
+- **Consequences**：决策的后果——什么变得更容易，什么变得更难
+
+## Core Principles
+- **记录 WHY，而非 WHAT**：代码已经说明了"做了什么"，ADR 应该说明"为什么这样做"
+- **可追溯性**：随着系统演进，ADR 提供了决策的历史脉络
+- **知识共享**：新成员可以通过 ADR 理解架构决策的背景
+
+## Related Concepts
+- [[SoftwareArchitect]]：ADR 是 Software Architect Agent 的核心工具之一
+- [[DomainDrivenDesign]]：ADR 常用于记录领域模型的边界决策
+
+## Sources
+- [[engineering-software-architect]]
+
+## Aliases
+- ADR
+- Architecture Decision Record
+- 架构决策记录
diff --git a/wiki/concepts/Atomic-Note.md b/wiki/concepts/Atomic-Note.md
new file mode 100644
index 00000000..482de2d6
--- /dev/null
+++ b/wiki/concepts/Atomic-Note.md
@@ -0,0 +1,38 @@
+---
+title: "Atomic Note"
+type: concept
+tags: [knowledge-management, zettelkasten, note-taking]
+sources: [zk-steward]
+last_updated: 2026-05-30
+---
+
+## Overview
+Atomic Note（原子笔记）是 Zettelkasten 系统的基本工作单位——最小的、自包含的知识单元。它必须满足 [[Luhmann-四原则]]中的原子性要求：可以独立理解，不依赖上下文而存在。
+
+## Definition
+一个原子笔记 = 一个想法 + 一个唯一标识 + 至少两条指向其他笔记的链接
+
+## Properties
+- **Self-contained**：即使没有上下文，读者也能理解笔记的内容
+- **Single idea**：一个笔记只讨论一个核心主题（one idea per note）
+- **Linked**：至少拥有 ≥2 条指向其他笔记/概念/实体的有意义的 wikilinks
+- **Non-categorical**：不依赖文件夹层级分类，而是通过网络位置定义自己
+
+## 与 Related Concepts 的关系
+- [[Zettelkasten]] ← Atomic Note 是 Zettelkasten 的基本工作单位
+- [[Luhmann-四原则]] ← 原子性（Atomicity）是 Luhmann 四原则之一，直接定义了 Atomic Note 的核心属性
+- [[Link-Proposer]] ← 新笔记归档时，Link-Proposer 确保原子笔记拥有 ≥2 条链接
+- [[Domain-Thinking]] ← 领域专家切换生成的内容，最终需要转化为原子笔记嵌入知识网络
+
+## 创建条件
+- 可独立理解（通过 Luhmann 原子性测试）
+- 包含 ≥2 条有意义的链接
+- 避免"零链接笔记"——零链接笔记违反 [[ZK-Steward-Agent]] 的核心规则
+
+## Example（来自 ZK Steward Agent 文档中的结构笔记示例）
+```markdown
+## [Title] Structure Note
+> **Context**: When, why, and under what project this was created.
+> **Default reader**: Yourself in six months—this structure is self-contained.
+```
+结构笔记下挂载多个原子笔记，每个原子笔记对应一个可独立理解的概念或论断。
diff --git a/wiki/concepts/AttachmentTheory.md b/wiki/concepts/AttachmentTheory.md
new file mode 100644
index 00000000..bec7b5a0
--- /dev/null
+++ b/wiki/concepts/AttachmentTheory.md
@@ -0,0 +1,33 @@
+---
+title: "Attachment Theory"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# Attachment Theory
+
+## Definition
+Bowlby 依恋理论——认为早期与主要照顾者的关系模式会形成内部工作模型，影响个体一生中所有亲密关系的建立方式。
+
+## Four Attachment Styles
+
+| 风格 | 特征 | 关系中的行为模式 |
+|------|------|-----------------|
+| Secure（安全型） | 信任、情绪调节良好 | 能亲密也能独立 |
+| Anxious-Preoccupied（焦虑型） | 害怕被抛弃、过度依赖 | 粘人、情绪化索取 |
+| Dismissive-Avoidant（回避型） | 情感独立、贬低亲密 | 逃避亲密、压抑情感 |
+| Fearful-Avoidant（恐惧型） | 既渴望又害怕亲密 | 矛盾、忽冷忽热 |
+
+## Key Concepts
+- **内部工作模型**（Internal Working Model）：对自我和他人的认知图式
+- **依恋唤起**（Attachment Activation）：压力情境触发依恋系统
+- **依恋回避**（Attachment Avoidance）：通过情感疏离应对亲密需求
+- **依恋焦虑**（Attachment Anxiety）：通过过度寻求确认应对被遗弃恐惧
+
+## Application in Character Design
+Psychologist Agent 在评估角色时，要求标注依恋风格及其在**浪漫/家庭/友谊**三种关系类型中的不同表现，并识别特定触发情境。
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/AudienceStrategy.md b/wiki/concepts/AudienceStrategy.md
new file mode 100644
index 00000000..a7645dc0
--- /dev/null
+++ b/wiki/concepts/AudienceStrategy.md
@@ -0,0 +1,51 @@
+---
+title: "Audience Strategy"
+type: concept
+tags: ["ppc", "audience", "targeting", "google-ads", "paid-media"]
+sources: ["paid-media-ppc-strategist"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+受众策略（Audience Strategy）是付费媒体中通过分层构建、精准定向和动态优化，最大化广告触达正确用户群体的系统性方法。涵盖第一方数据激活（Customer Match）、相似受众（Similar Segments）、竞品受众（In-Market/Affinity）、自定义受众组合，以及排除策略的整体设计。
+
+## Audience Layers
+
+### Layer 1: First-Party Data（第一方数据）
+- **Customer Match**：自有客户邮箱/电话列表，直接匹配 Google 用户
+- **CRM Audiences**：基于 CRM 数据构建的自定义受众
+- **Website Visitors**：GA4/GBoard 追踪的网站访问者（再营销）
+- **App Users**：移动应用用户受众
+
+### Layer 2: Similar / Lookalike（相似受众）
+- **Similar Segments**：在 Customer Match 基础上自动扩展相似新用户
+- **Value-Based Similar**：按客户生命周期价值（CLV）分层的相似受众
+
+### Layer 3: In-Market / Affinity（兴趣受众）
+- **In-Market Audiences**：主动研究/比较中的潜在购买者（高转化潜力）
+- **Affinity Audiences**：长期兴趣/生活方式相关用户（品牌建设场景）
+- **Life Events**：人生重大事件（搬家/结婚/大学等）
+
+### Layer 4: Demographic（人口统计）
+- **Age / Gender**：基础人口属性
+- **Household Income**：高收入人群定向（Premium 产品）
+- **Parental Status**：家长定向
+
+## Targeting vs Observation Mode
+
+| 模式 | 效果 |
+|------|------|
+| **Targeting** | 竞价时仅考虑定向人群，缩小范围 |
+| **Observation** | 观察指定人群表现，但不限制竞价范围 |
+
+## Audience Exclusion
+
+- **排除已转化用户**：避免浪费在已有客户身上
+- **排除低质量受众**：表现差的历史受众列表
+- **排除员工**：避免内部测试流量污染数据
+
+## Connections
+- [[CustomerMatch]]：第一方数据激活的核心工具
+- [[PerformanceMax]]：Audience Signals 是 PMax 的关键输入
+- [[TieredCampaignArchitecture]]：不同层级的广告系列适用不同的受众策略
diff --git a/wiki/concepts/Audit-Readiness.md b/wiki/concepts/Audit-Readiness.md
new file mode 100644
index 00000000..4349cc63
--- /dev/null
+++ b/wiki/concepts/Audit-Readiness.md
@@ -0,0 +1,53 @@
+---
+title: "Audit Readiness"
+type: concept
+tags: [finance, accounting, compliance, audit]
+sources: [finance-bookkeeper-controller]
+last_updated: 2026-05-02
+---
+
+## Definition
+审计就绪（Audit Readiness）是指企业日常维护的持续合规状态，确保在任何时间点审计师进场都能在规定时间内（通常24小时）提供任何财务余额的支持文件。
+
+## Core Principle
+> "Audit readiness is a daily practice. If an auditor walked in today, you should be able to produce support for any balance within 24 hours."
+> — Dana, Bookkeeper & Controller Agent
+
+## Key Practices
+
+### Daily Habits
+- 所有交易当天有支持文件
+- Journal entries 附带完整描述和审批记录
+- 银行对账每月及时完成
+- 所有支持文件归档有序
+
+### Supporting Documentation Requirements
+| Balance Type | Required Support |
+|---|---|
+| Cash | 银行对账单 + 调节表 |
+| AR | Aging 报告 + 支持明细 |
+| AP | 供应商对账单 + 发票 |
+| Inventory | 盘点记录 |
+| Fixed Assets | 资产明细表 + 折旧表 |
+| Accruals | 计算底稿 |
+
+### Control Testing
+- 所有关键控制有文档记录
+- 控制执行有证据（日志、审批截图）
+- 例外情况有书面说明
+
+## Core Principle
+> "The audit should be boring. If the auditors are surprised, the controls failed."
+> — Dana, Bookkeeper & Controller Agent
+
+## Success Metrics
+- 审计调整 < 1% 总资产
+- 零重述
+- 所有审计请求 24 小时内响应
+- 审计周期缩短（目标：无聊的审计 = 成功的审计）
+
+## Related Concepts
+- [[Internal Controls]]
+- [[Account Reconciliation]]
+- [[Month-End-Close-Process]]
+- [[Segregation-Of-Duties]]
diff --git a/wiki/concepts/AutomatedBiddingStrategy.md b/wiki/concepts/AutomatedBiddingStrategy.md
new file mode 100644
index 00000000..f3212635
--- /dev/null
+++ b/wiki/concepts/AutomatedBiddingStrategy.md
@@ -0,0 +1,42 @@
+---
+title: "Automated Bidding Strategy"
+type: concept
+tags: ["ppc", "bidding", "automation", "google-ads", "paid-media"]
+sources: ["paid-media-ppc-strategist"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+自动化竞价策略（Automated Bidding Strategy）是 Google Ads 等平台提供的基于机器学习的智能出价系统，通过算法自动调整每次竞价出价，以优化预设的绩效目标（转化量、转化价值、ROAS 等）。区别于手动 CPC 出价，自动化竞价利用受众信号、上下文信号和历史数据自动优化。
+
+## Available Strategies
+
+| 策略 | 目标 | 适用场景 |
+|------|------|---------|
+| **Maximize Conversions** | 最大化转化量 | 数据充足、追求规模 |
+| **Maximize Conversion Value** | 最大化转化价值 | 客单价差异大、多产品 |
+| **tCPA（Target CPA）** | 固定平均单次转化成本 | 稳定转化数据、追求效率 |
+| **tROAS（Target ROAS）** | 固定广告支出回报率 | 有明确 ROAS 目标 |
+| **Enhanced CPC（ECPC）** | 在手动 CPC 基础上提升转化 | 向自动竞价过渡阶段 |
+| **Maximize Clicks** | 最大化点击量 | 流量获取阶段 |
+
+## Transition Framework
+
+从手动向自动竞价迁移的推荐路径：
+
+1. **数据积累期**（4-6周）：手动 CPC + ECPC，建立转化数据基础
+2. **轻度自动化**（2-4周）：切换至 Maximize Conversions，监控效果
+3. **目标竞价**（持续）：根据业务目标选择 tCPA 或 tROAS
+
+## Key Requirements
+
+- **转化数据充足**：策略效果与数据量直接相关
+- **Conversion Action 正确配置**：追踪须准确，否则算法基于错误信号优化
+- **预算充足**：日预算至少达到目标 CPA 的 5-10 倍，保证算法学习
+- **时间窗口合理**：建议 4 周学习期后再评估效果
+
+## Connections
+- [[GoogleAds]]：Google Ads 是最主要的自动化竞价平台
+- [[PerformanceMax]]：内置 Smart Bidding，是 AI 驱动优化的典型场景
+- [[TieredCampaignArchitecture]]：不同层级的广告系列适用不同竞价策略
diff --git a/wiki/concepts/Automation-Decision-Framework.md b/wiki/concepts/Automation-Decision-Framework.md
new file mode 100644
index 00000000..ad980c5b
--- /dev/null
+++ b/wiki/concepts/Automation-Decision-Framework.md
@@ -0,0 +1,39 @@
+---
+title: "Automation Decision Framework"
+type: concept
+tags: [automation, governance, decision, evaluation]
+sources: [automation-governance-architect]
+last_updated: 2026-05-01
+---
+
+# Automation Decision Framework
+
+四维自动化评估框架，Automation Governance Architect 对每个自动化请求强制执行的决策前置步骤。
+
+## 四维评估
+
+### 1. Time Savings Per Month（月度时间节省）
+- 节省是否可持续且有意义？
+- 流程频率是否足以覆盖自动化开销？
+
+### 2. Data Criticality（数据关键性）
+- 是否涉及客户、财务、合同或调度记录？
+- 错误 / 延迟 / 重复 / 缺失数据的 Impact 是什么？
+
+### 3. External Dependency Risk（外部依赖风险）
+- 链条中有多少外部 API/服务？
+- 它们是否稳定、有文档、可观测？
+
+### 4. Scalability 1x to 100x（可扩展性）
+- 重试、去重、速率限制在高负载下是否仍然有效？
+- 异常处理在大规模下是否仍可管理？
+
+## 与 Verdict System 的关系
+
+四维评估结果直接决定 [[Automation-Verdict-System]] 五级裁定：
+- 四维均达标 → APPROVE
+- 部分维度满足但有限制 → APPROVE AS PILOT / PARTIAL AUTOMATION ONLY
+- 任一维度存在重大问题 → DEFER / REJECT
+
+## Sources
+- [[automation-governance-architect]]
diff --git a/wiki/concepts/Automation-Verdict-System.md b/wiki/concepts/Automation-Verdict-System.md
new file mode 100644
index 00000000..8d4a74e3
--- /dev/null
+++ b/wiki/concepts/Automation-Verdict-System.md
@@ -0,0 +1,41 @@
+---
+title: "Automation Verdict System"
+type: concept
+tags: [automation, governance, verdict, decision]
+sources: [automation-governance-architect]
+last_updated: 2026-05-01
+---
+
+# Automation Verdict System
+
+五级自动化裁定结果体系，基于 [[Automation-Decision-Framework]] 四维评估后输出。
+
+## 五级裁定
+
+| 裁定 | 条件 | 含义 |
+|------|------|------|
+| **APPROVE** | 强价值 + 可控风险 + 可维护架构 | 可直接进入生产实施 |
+| **APPROVE AS PILOT** | 价值存在但需小范围验证 | 限定范围试点，验证后再全面铺开 |
+| **PARTIAL AUTOMATION ONLY** | 自动化安全段有价值，人工检查点不可少 | 仅自动化低风险环节，关键决策保留人工 |
+| **DEFER** | 流程不成熟 / 价值不明 / 依赖不稳定 | 暂不推进，等待条件成熟 |
+| **REJECT** | 经济性弱或运营/合规风险不可接受 | 明确拒绝，不进入实施阶段 |
+
+## 核心原则
+
+- **一次只选一个裁定**：不存在模糊状态
+- **裁定须附带理由**：Verdict 须对应 Rationale（业务 Impact / 关键风险 / 裁定依据）
+- **裁定附带架构建议**：即使 APPROVE 也需推荐 Architecture（触发点 / 验证逻辑 / 日志 / 错误处理 / Fallback）
+
+## Required Output Format（裁定输出格式）
+
+每份裁定必须包含：
+1. Process Summary（流程摘要）
+2. Audit Evaluation（四维评估）
+3. Verdict（裁定）
+4. Rationale（理由）
+5. Recommended Architecture（推荐架构）
+6. Implementation Standard（实施标准）
+7. Preconditions and Risks（前置条件和风险）
+
+## Sources
+- [[automation-governance-architect]]
diff --git a/wiki/concepts/Autoscaling.md b/wiki/concepts/Autoscaling.md
new file mode 100644
index 00000000..779819d9
--- /dev/null
+++ b/wiki/concepts/Autoscaling.md
@@ -0,0 +1,51 @@
+---
+title: "Autoscaling"
+type: concept
+tags: [sre, cloud, scalability, reliability, kubernetes]
+last_updated: 2026-04-20
+---
+
+# Autoscaling
+
+自动扩缩容（Autoscaling）是云原生系统中根据负载自动调整资源容量的机制，但它与真正的弹性（Elasticity）有本质区别。
+
+## Definition
+Autoscaling 通过预定义的规则（如 CPU 使用率、请求队列长度等）自动增加或减少计算资源。它是一种**被动的、反应式的**机制。
+
+## Key Limitation
+> "Autoscaling is reactive, not resilient. Without caps, metrics, or overrides, it can worsen failures." — David Iyanu Jonathan
+
+没有以下保护机制时，Autoscaling 可能**加剧故障**：
+- **上限（caps）**：防止无限扩容
+- **指标（metrics）**：确保扩容基于可靠数据
+- **覆盖机制（overrides）**：允许人工干预
+
+## Autoscaling vs. Elasticity
+
+| Aspect | Autoscaling | [[Elasticity]] |
+|--------|-------------|----------------|
+| 性质 | 被动的、反应式的 | 主动的、前瞻性的 |
+| 触发 | 基于指标阈值 | 基于策略和规划 |
+| 保护机制 | 可能缺失 | 必须具备 |
+| 故障时行为 | 可能加剧故障 | 设计上防止故障扩大 |
+
+## Anti-Patterns
+- **Autoscaling to Death**：系统在负载高峰时无限扩容，导致资源耗尽
+- **No Upper Limits**：缺少上限导致成本爆炸
+- **Metrics Blindness**：依赖单一指标，忽视系统整体健康状况
+
+## Best Practices
+1. 设置合理的扩容上限和缩容下限
+2. 配置多维度指标（不仅仅是 CPU）
+3. 建立人工覆盖机制
+4. 在非生产环境测试扩容策略
+5. 监控 Autoscaling 本身的行为
+
+## Related Concepts
+- [[Elasticity]]
+- [[Scalability]]
+- [[Cluster-Autoscaler]]
+- [[Cost-Optimization]]
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/concepts/Background-Job-Scheduling.md b/wiki/concepts/Background-Job-Scheduling.md
new file mode 100644
index 00000000..e0aaadf6
--- /dev/null
+++ b/wiki/concepts/Background-Job-Scheduling.md
@@ -0,0 +1,33 @@
+---
+title: "Background-Job-Scheduling"
+type: concept
+tags: []
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Definition
+Background Job Scheduling 是通过远程 API 管理定时和后台 Agent 任务的能力，使客户端无需长期保持连接即可触发和监控长时间运行的任务。
+
+## Implementation in Hermes Agent
+`/api/jobs` API 提供完整的 CRUD 接口：
+- **Create**：创建定时任务或后台任务
+- **Read**：查询任务状态和结果
+- **Update**：修改任务参数或取消任务
+- **Delete**：删除任务
+
+## Key Features
+- **定时执行**：支持 cron 表达式或延迟执行
+- **状态追踪**：实时查询任务执行状态
+- **结果获取**：任务完成后可获取完整输出
+- **远程管理**：客户端无需保持连接
+
+## Use Cases
+- 定时报告生成
+- 批量数据处理
+- 定时通知发送
+- 后台数据同步
+
+## Related
+- [[OpenAI-Compatible-API]]
+- [[Multi-Profile-Isolation]]
diff --git a/wiki/concepts/Bearer-Token-Authentication.md b/wiki/concepts/Bearer-Token-Authentication.md
new file mode 100644
index 00000000..a5ab65f0
--- /dev/null
+++ b/wiki/concepts/Bearer-Token-Authentication.md
@@ -0,0 +1,24 @@
+---
+title: "Bearer-Token-Authentication"
+type: concept
+tags: []
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Definition
+Bearer Token Authentication 是一种 HTTP 认证机制，通过 `Authorization: Bearer <token>` 请求头传递令牌来验证 API 请求的合法性。
+
+## Usage in Hermes Agent
+Hermes Agent API Server 使用 Bearer Token 认证：
+- **环境变量**：`API_SERVER_KEY` 设置认证密钥
+- **请求格式**：`Authorization: Bearer <API_SERVER_KEY>`
+- **适用场景**：任何调用 API Server 的客户端
+
+## Security Notes
+- 当 API Server 绑定到非 loopback 地址（如 `0.0.0.0`）时，必须配置 `API_SERVER_KEY`
+- 默认绑定 `127.0.0.1:8642` 时仅本地访问可用，认证可选
+
+## Related
+- [[OpenAI-Compatible-API]]
+- [[Multi-Profile-Isolation]]
diff --git a/wiki/concepts/Behavioral-Analytics.md b/wiki/concepts/Behavioral-Analytics.md
new file mode 100644
index 00000000..f519b7b6
--- /dev/null
+++ b/wiki/concepts/Behavioral-Analytics.md
@@ -0,0 +1,37 @@
+---
+title: "Behavioral Analytics"
+type: concept
+tags: [ux, behavioral-analytics, data-analysis, user-behavior, analytics]
+sources: [design-ux-researcher.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+Behavioral Analytics（行为分析）是一种通过收集、分析和解读用户在数字产品中的行为数据来识别使用模式、发现问题和优化机会的定量研究方法。是 UX Researcher Agent 在数字产品研究中的重要工具。
+
+## Key Techniques
+
+| 技术 | 说明 |
+|------|------|
+| Event Tracking | 追踪用户关键行为事件（点击/导航/停留） |
+| Funnel Analysis | 分析用户转化漏斗，识别流失点 |
+| Cohort Analysis | 按用户群组分析行为差异 |
+| Session Recording | 录制用户会话视频，还原真实行为 |
+
+## Metrics
+
+- **Activation Rate**：用户激活比例
+- **Engagement Rate**：用户参与度
+- **Retention Rate**：用户留存率
+- **Churn Rate**：用户流失率
+
+## Relationship to Other Concepts
+
+- [[Qualitative-Quantitative-Research]]：行为分析是定量研究方法的具体应用
+- [[User-Journey-Mapping]]：行为数据分析支撑用户旅程地图的构建
+- [[User-Research-Methodology]]：行为分析是混合研究方法的数据支撑层
+
+## Source
+
+- [[design-ux-researcher.md]] — UX Researcher Agent Personality
diff --git a/wiki/concepts/BigFive.md b/wiki/concepts/BigFive.md
new file mode 100644
index 00000000..04aa0831
--- /dev/null
+++ b/wiki/concepts/BigFive.md
@@ -0,0 +1,33 @@
+---
+title: "Big Five Personality Model"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# Big Five Personality Model
+
+## Aliases
+- Big Five
+- Five-Factor Model (FFM)
+- OCEAN Model
+
+## Definition
+人格五因素模型——通过五个正交维度系统性评估和描述人格特质，是当前人格心理学中最具实证支持的结构框架。
+
+## Five Factors
+
+| 因素 | 高分特征 | 低分特征 |
+|------|----------|----------|
+| Openness（开放性） | 想象力、好奇心、艺术兴趣 | 务实、保守、按部就班 |
+| Conscientiousness（尽责性） | 自律、组织、成就导向 | 随性、冲动、拖延 |
+| Extraversion（外向性） | 社交、活力、寻求刺激 | 内向、安静、低社交需求 |
+| Agreeableness（宜人性） | 信任、合作、利他、谦逊 | 竞争、怀疑、自利 |
+| Neuroticism（神经质） | 焦虑、情绪不稳定、脆弱 | 情绪稳定、抗压、适应性强 |
+
+## Application in Character Design
+Psychologist Agent 使用 Big Five 评估角色特质时，要求每个特质必须有对应的**行为表现**（behavioral manifestation），而非抽象标签。
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/BlamelessPostMortem.md b/wiki/concepts/BlamelessPostMortem.md
new file mode 100644
index 00000000..d0ce4c13
--- /dev/null
+++ b/wiki/concepts/BlamelessPostMortem.md
@@ -0,0 +1,110 @@
+---
+title: "Blameless Post-Mortem"
+type: concept
+tags: [reliability, incident-management, culture]
+last_updated: 2026-05-01
+---
+
+## Definition
+无责复盘（Blameless Post-Mortem）是一种以系统性视角分析事故的方法——归因于系统缺陷和流程缺口，而非个人错误。其核心原则：**"The system allowed this failure mode"**（系统允许了这种失败模式的存在），而非"X 人员导致了故障"。
+
+## Core Principles
+
+### 1. 聚焦系统，不追责个人
+- **错误框架**："X 人员没有检查配置"
+- **正确框架**："系统没有强制执行配置验证流程"
+- 关键问题："系统缺少什么护栏/告警/测试，才让这个缺陷通过了？"
+
+### 2. 5 Whys 根因分析
+通过连续追问找到系统性根本原因：
+1. 为什么服务宕机了？→ 配置文件错误
+2. 为什么配置文件错误？→ 变更审批未发现
+3. 为什么未发现？→ 没有自动化配置校验测试
+4. 为什么没有配置校验测试？→ 优先级未排入迭代
+5. 为什么未排入迭代？→ **系统根因**：没有将配置变更纳入质量门槛流程
+
+### 3. 事实记录，时序重建
+- 按 UTC 时间重建完整事故时间线（从检测到恢复到后续跟进）
+- 记录实际采取的行动，而非"应该"采取的行动
+- 区分缓解措施（止血）和根因修复（治本）
+
+### 4. 平衡"做得好的"和"做得差的"
+- **What Went Well**：有效的流程、工具和团队协作
+- **What Went Poorly**：拖慢检测或恢复的缺口
+
+### 5. 行动项必须有跟踪
+- 每次复盘必须有具体行动项（Action Items）
+- 每个行动项：清晰的描述 + 负责人 + 优先级 + 截止日期
+- 无跟进行动项的复盘 = 只是会议
+
+## Post-Mortem Document Structure
+
+```markdown
+# Post-Mortem: [Incident Title]
+
+**Date**: YYYY-MM-DD
+**Severity**: SEV[1-4]
+**Duration**: [start] – [end] ([total])
+**Author**: [name]
+**Status**: [Draft / Review / Final]
+
+## Executive Summary
+[2-3句话：发生了什么、影响谁、如何解决]
+
+## Impact
+- Users affected: [数量或百分比]
+- Revenue impact: [估算或 N/A]
+- SLO budget consumed: [月度错误预算消耗百分比]
+
+## Timeline (UTC)
+| Time  | Event |
+|-------|-------|
+| 14:02 | Monitoring alert fires: API error rate > 5% |
+| 14:05 | On-call engineer acknowledges page |
+| ...   | ... |
+
+## Root Cause Analysis
+### What happened
+[详细技术解释]
+
+### Contributing Factors
+1. **Immediate**: [直接触发原因]
+2. **Underlying**: [为什么触发成为可能]
+3. **Systemic**: [组织/流程层面的缺口]
+
+### 5 Whys
+1. Why...? → [answer]
+2. ...
+
+## What Went Well
+-
+
+## What Went Poorly
+-
+
+## Action Items
+| ID | Action | Owner | Priority | Due | Status |
+|----|--------|-------|----------|-----|--------|
+| 1  | ...    | @team | P1       | ... | Open   |
+
+## Lessons Learned
+[对未来架构和流程决策的启示]
+```
+
+## Key Rules
+
+| 规则 | 说明 |
+|------|------|
+| 48 小时原则 | 事故解决后 48 小时内必须启动复盘（趁记忆鲜活） |
+| 心理安全 | 参与者必须感到安全，不能因发言而受到惩罚 |
+| 文档公开 | 复盘文档全公司可见，知识共享 |
+| 季度复盘 | 回顾过去季度的事故趋势，识别系统性风险 |
+
+## Related Concepts
+- [[DORA-Metrics]] — 通过 MTTD、MTTR 等指标量化可靠性
+- [[DevOpsCulture]] — 无责文化是 DevOps 的核心支柱之一
+- [[Rollback-Rate]] — 回滚分析是复盘的重要输入
+- [[FiveWhys]] — 5问法是复盘根因分析的经典工具
+
+## Sources
+- [[engineering-incident-response-commander]]
diff --git a/wiki/concepts/Blended-Learning.md b/wiki/concepts/Blended-Learning.md
new file mode 100644
index 00000000..4cf1ce86
--- /dev/null
+++ b/wiki/concepts/Blended-Learning.md
@@ -0,0 +1,45 @@
+---
+title: "Blended Learning"
+type: concept
+tags: [learning-strategy, instructional-design]
+sources: [corporate-training-designer]
+last_updated: 2026-05-29
+---
+
+## Definition
+
+Blended Learning（OMO，Online-Merge-Offline，线上线下融合学习）是将线上学习与线下面对面教学有机结合的学习模式，按照"知道→做到→持续"的认知规律分配学习场景，实现学习效果最大化。
+
+## Three-Layer Model
+
+### 线上 — "知道"（Knowing）
+- 知识传递：微课视频、文档阅读、在线测验
+- 特点：可随时随地学习，支持碎片化时间利用
+- 微课程规范：5-15分钟一门课，解决一个问题，结构清晰（痛点导入→知识传递→案例演示→要点总结）
+
+### 线下 — "做到"（Doing）
+- 深度实践：小组讨论、角色扮演、沙盘模拟、动手练习
+- 特点：在安全环境中犯错误、即时反馈、行为强化
+- 场景类型：商业决策沙盘、项目管理沙盘、供应链沙盘等
+
+### 学习社群 — "持续"（Sustaining）
+- 持续巩固：学习社区、答疑辅导、经验分享、行动学习
+- 特点：将一次性培训转化为持续学习行为
+
+## Key Platforms（中国企业）
+- [[DingTalk-Learning]]（钉钉学习）：适合阿里巴巴生态企业，与钉钉 OA 深度集成
+- [[WeCom-Learning]]（企业微信学习）：适合微信生态企业，嵌入公众号和小程序
+- [[Feishu-Knowledge-Base]]（飞书知识库）：适合字节跳动生态和知识管理导向组织
+- [[UMU]]：混合学习领域领先者，支持 AI 练习搭档、视频作业、丰富互动功能
+- [[Yunxuetang]]（云学堂）：大中型企业一站式学习平台
+
+## Instructional Design Principles
+- **场景匹配**：知识类内容适合线上，技能类内容必须线下实践
+- **认知负荷控制**：线上微课控制在15分钟以内；线下培训每90分钟安排互动或休息
+- **行为迁移设计**：每次线下练习必须设计行为迁移任务，确保学员回去能用
+
+## Connections
+- [[Blended-Learning]] ← learning_strategy ← [[Corporate-Training-Designer]]（培训设计师的核心交付模式）
+- [[Flipped-Classroom]] ← practice_application ← [[Blended-Learning]]（翻转课堂是混合学习的一种实践形式）
+- [[Kolbs-Learning-Cycle]] ← theoretical_basis ← [[Blended-Learning]]（Kolb 体验学习圈为混合学习的场景分配提供理论依据）
+- [[Blended-Learning]] ← platform_infrastructure ← [[Blended-Learning-Platform]]（学习平台是混合学习的技术支撑）
diff --git a/wiki/concepts/Bloom-Taxonomy.md b/wiki/concepts/Bloom-Taxonomy.md
new file mode 100644
index 00000000..446232b0
--- /dev/null
+++ b/wiki/concepts/Bloom-Taxonomy.md
@@ -0,0 +1,53 @@
+---
+title: "Bloom Taxonomy"
+type: concept
+tags: [cognitive-theory, learning-objectives]
+sources: [corporate-training-designer]
+last_updated: 2026-05-29
+---
+
+## Definition
+
+Bloom 认知分类法（Blooms Taxonomy）由 Benjamin Bloom 等人于 1956 年提出，是一种按认知复杂度排序的学习目标分类体系，包含六个层级（记忆→理解→应用→分析→评价→创造），用于设计学习目标和评估标准。
+
+## Six Levels
+
+### Level 1 — Remember（记忆）
+- 识别、回忆事实性信息
+- 关键词：列出、定义、命名、辨认
+- 示例：列举企业培训的五种常见形式
+
+### Level 2 — Understand（理解）
+- 解释信息的含义
+- 关键词：总结、解释、举例、分类
+- 示例：用自己的话解释 ADDIE 模型的五个阶段
+
+### Level 3 — Apply（应用）
+- 将知识用于新情境
+- 关键词：执行、使用、演示、解决
+- 示例：在给定的业务场景中，选择合适的教学策略
+
+### Level 4 — Analyze（分析）
+- 区分整体与部分，理解各部分之间的关系
+- 关键词：比较、对比、分解、辨别
+- 示例：分析某培训课程失败的原因，找出关键要素
+
+### Level 5 — Evaluate（评价）
+- 基于标准做出判断
+- 关键词：评价、批判、选择、支持
+- 示例：评估两种教学设计方案的优劣
+
+### Level 6 — Create（创造）
+- 将要素重组为新结构
+- 关键词：设计、构建、创造、制定
+- 示例：设计一套完整的新员工培训方案
+
+## Applications in Training Design
+- **学习目标撰写**：使用 Bloom 动词明确每个学习目标的认知层级
+- **评估设计**：根据 Bloom 层级设计相应的评估方式（记忆→选择题；应用→案例分析；创造→方案设计）
+- **内容深度把控**：确保课程内容覆盖多个认知层级，而不仅是最低层级的"知识灌输"
+
+## Connections
+- [[Bloom-Taxonomy]] ← learning_objective_framework ← [[ADDIE-Model]]（ADDIE 的设计阶段使用 Bloom 分类定义学习目标）
+- [[Bloom-Taxonomy]] ← cognitive_level ← [[Kirkpatrick-Model]]（Bloom 定义"学到什么层级"，Kirkpatrick 验证"是否真的学到了"）
+- [[Corporate-Training-Designer]] ← uses ← [[Bloom-Taxonomy]]（培训设计师必须掌握的核心教学设计工具）
diff --git a/wiki/concepts/Brand-Foundation-Framework.md b/wiki/concepts/Brand-Foundation-Framework.md
new file mode 100644
index 00000000..fea9a560
--- /dev/null
+++ b/wiki/concepts/Brand-Foundation-Framework.md
@@ -0,0 +1,44 @@
+---
+title: "Brand Foundation Framework"
+type: concept
+tags: [brand, strategy, framework]
+last_updated: 2026-05-15
+sources: [design-brand-guardian]
+---
+
+## Definition
+
+品牌基础框架是定义品牌存在的完整战略体系，包含 Purpose（存在意义）、Vision（愿景）、Mission（使命）、Values（价值观）和 Personality（个性）五个核心维度。该框架是所有品牌决策的基础，确保品牌在所有触点的一致性和差异化。
+
+## Core Components
+
+### Brand Purpose（存在意义）
+品牌超越盈利之外的存在意义——有意义的价值和影响创造。回答"为什么品牌存在"。
+
+### Brand Vision（愿景）
+品牌追求的理想未来状态——品牌发展方向和成就。回答"品牌想去哪里"。
+
+### Brand Mission（使命）
+品牌具体做什么、为谁做——价值交付和目标受众。回答"品牌做什么、为谁做"。
+
+### Brand Values（价值观）
+指导所有品牌行为和决策的核心原则，例如：
+1. Primary Value：定义及行为表现
+2. Secondary Value：定义及行为表现
+3. Supporting Value：定义及行为表现
+
+### Brand Personality（个性）
+定义品牌特征的人类特征，例如：
+- Trait 1：描述及表达方式
+- Trait 2：描述及表达方式
+- Trait 3：描述及表达方式
+
+## Brand Promise
+对客户和利益相关者的承诺——他们可以永远期待什么。
+
+## Connections
+
+- [[design-brand-guardian]] → 定义了 Brand Foundation Framework 的完整结构
+- [[Visual-Identity-System]] → Brand Foundation Framework 的视觉表达
+- [[Brand-Voice]] → Brand Foundation Framework 的语言表达
+- [[design-ux-architect]] → Brand Foundation Framework 是其技术实现的输入
diff --git a/wiki/concepts/Brand-Personality-Framework.md b/wiki/concepts/Brand-Personality-Framework.md
new file mode 100644
index 00000000..275b21bb
--- /dev/null
+++ b/wiki/concepts/Brand-Personality-Framework.md
@@ -0,0 +1,48 @@
+---
+title: "Brand Personality Framework"
+type: concept
+tags: [brand, ux, design]
+last_updated: 2026-04-30
+---
+
+# 品牌个性框架（Brand Personality Framework）
+
+## Aliases
+- Brand Personality
+- 品牌个性
+- 品牌声音（Brand Voice）
+
+## 定义
+
+品牌个性框架是定义品牌在所有接触点上"如何表达自己"的系统方法——包括语言风格（文案/语气）、视觉风格（颜色/动画/图标）和交互风格（如何响应用户行为）。核心目标是在保持一致性的同时，传达独特的情感连接。
+
+## 四维个性谱系
+
+| 情境 | 维度 | 示例 |
+|------|------|------|
+| 专业场景 | Professional Context | 简洁、数据驱动、严谨 |
+| 休闲场景 | Casual Context | 友好、轻松、有温度 |
+| 错误场景 | Error Context | 幽默化解焦虑、提供清晰引导 |
+| 成功场景 | Success Context | 热情庆祝、肯定用户成就 |
+
+## 关键要素
+
+1. **品牌声音（Brand Voice）**：在各类情境下保持一致的语言风格和语气
+2. **视觉人格（Visual Personality）**：颜色、动画风格、图标选择等视觉元素的一致性
+3. **交互风格（Interaction Style）**：系统如何响应用户动作——积极的？稳重的？俏皮的？
+4. **文化敏感性**：确保个性表达跨越文化边界时不产生误解
+
+## 与微交互的关系
+
+微交互是品牌个性在交互层的执行载体——一个"俏皮"的品牌会在微交互中体现俏皮（趣味动画/庆祝效果），一个"专业"的品牌则会选择克制的、精确的反馈。
+
+## 应用场景
+
+- [[design-whimsy-injector]] 负责将品牌个性框架转化为具体的趣味性设计规范和微文案
+- [[design-brand-guardian]] 负责维护品牌个性的一致性和边界
+
+## 相关概念
+
+- [[design-whimsy-injector]]：品牌个性框架的具体执行者
+- [[Micro-Interaction]]：品牌个性在交互细节上的表达
+- [[Inclusive-Delight]]：品牌个性需兼顾包容性，不能因追求个性而排除特定用户群
diff --git a/wiki/concepts/Brand-Protection.md b/wiki/concepts/Brand-Protection.md
new file mode 100644
index 00000000..d62eafdc
--- /dev/null
+++ b/wiki/concepts/Brand-Protection.md
@@ -0,0 +1,49 @@
+---
+title: "Brand Protection"
+type: concept
+tags: [brand, protection, trademark, governance]
+last_updated: 2026-05-15
+sources: [design-brand-guardian]
+---
+
+## Definition
+
+品牌保护是维护品牌完整性、价值和声誉的综合策略体系，包含 Trademark Strategy（商标策略）、Compliance Monitoring（合规监控）和 Crisis Management（危机管理）三个核心维度。
+
+## Core Components
+
+### Trademark Strategy（商标策略）
+- 商标注册和保护计划
+- 知识产权识别和登记
+- 侵权监测和执法
+- 法律保护框架
+
+### Compliance Monitoring（合规监控）
+- 品牌使用合规性检查
+- 品牌实施跨所有触点的监控
+- 品牌指南遵守情况审计
+- 纠正性指导机制
+
+### Crisis Management（危机管理）
+- 品牌危机应对预案
+- 声誉保护策略
+- 利益相关者沟通计划
+- 品牌恢复路径
+
+## Key Activities
+
+- 保护品牌知识产权
+- 监控品牌一致性实施
+- 管理品牌危机情况
+- 确保文化敏感性和市场适当性
+
+## Brand Protection as Default
+
+Brand Guardian Agent 将品牌保护作为默认要求内置于所有品牌策略中，而非事后补救。
+
+## Connections
+
+- [[design-brand-guardian]] → 定义了 Brand Protection 的完整框架
+- [[Brand-Foundation-Framework]] → Brand Protection 保护品牌基础框架的完整性
+- [[Automation-Governance-Architect]] → 共享治理和保护的系统性思维
+- [[Compliance-Auditor]] → 提供合规监控的方法论参考
diff --git a/wiki/concepts/Brand-Voice.md b/wiki/concepts/Brand-Voice.md
new file mode 100644
index 00000000..32f73b59
--- /dev/null
+++ b/wiki/concepts/Brand-Voice.md
@@ -0,0 +1,47 @@
+---
+title: "Brand Voice"
+type: concept
+tags: [brand, voice, communication, messaging]
+last_updated: 2026-05-15
+sources: [design-brand-guardian]
+---
+
+## Definition
+
+品牌声音是品牌语言表达的核心规范，定义品牌如何与受众沟通。包含 Voice Characteristics（声音特征）、Tone Variations（语气变体）和 Messaging Framework（信息架构）三个维度。
+
+## Core Components
+
+### Voice Characteristics（声音特征）
+定义品牌沟通的人类特征：
+- **Strategic（战略性）**：强调品牌决策的战略价值
+- **Consistent（一致性）**：确保跨所有渠道的品牌表达一致
+- **Protective（保护性）**：维护品牌完整性和价值
+- **Visionary（愿景性）**：传达品牌的未来导向和雄心
+
+### Tone Variations（语气变体）
+根据场景调整的语气指南：
+- **Professional（专业）**：何时使用及示例语言
+- **Conversational（对话）**：何时使用及示例语言
+- **Supportive（支持）**：何时使用及示例语言
+
+### Messaging Framework（信息架构）
+- **Brand Tagline**：概括品牌精髓的易记短语
+- **Value Proposition**：清晰的客户利益声明
+- **Key Messages**：
+  1. 主要受众的主要信息
+  2. 次要受众的次要信息
+  3. 特定用例的支持信息
+
+## Writing Guidelines
+
+- **Vocabulary**：首选术语、需要避免的短语
+- **Grammar**：风格偏好、格式标准
+- **Cultural Considerations**：包容性语言指南
+
+## Connections
+
+- [[Brand-Foundation-Framework]] → Brand Voice 是其语言表达层
+- [[design-brand-guardian]] → 定义了 Brand Voice 的完整规范
+- [[Micro-Interaction]] → Brand Voice 在微交互文案中的应用
+- [[Brand-Personality-Framework]] → Brand Voice 反映品牌个性
diff --git a/wiki/concepts/Budget-Variance-Analysis.md b/wiki/concepts/Budget-Variance-Analysis.md
new file mode 100644
index 00000000..ae63b592
--- /dev/null
+++ b/wiki/concepts/Budget-Variance-Analysis.md
@@ -0,0 +1,44 @@
+---
+title: "Budget Variance Analysis"
+type: concept
+tags: ["finance", "budgeting", "variance-analysis"]
+last_updated: 2026-04-30
+---
+
+## Definition
+预算差异分析是通过比较预算金额（budget_amount）与实际金额（actual_amount）之间的差异（variance），判断预算执行状态的财务管控方法，是预算管理闭环的关键环节。
+
+## Calculation
+```
+variance = budget_amount - actual_amount
+variance_percentage = (actual_amount - budget_amount) / budget_amount × 100
+```
+
+## Status Thresholds
+| 差异百分比 | 预算状态 |
+|-----------|---------|
+| ≤ 5% (正或负) | On Track（正常） |
+| > 5%（超支） | Over Budget（超支） |
+| > 5%（节省） | Under Budget（节省） |
+
+## Core Framework
+通过 SQL 窗口函数实现：
+1. **CTE `budget_actuals`**：按部门、类别、季度聚合预算与实际数据
+2. **CTE `department_summary`**：按部门维度汇总，输出总预算、总实际、差异总额、平均差异百分比
+
+## Success Criteria
+预算准确率目标：**95%+**，差异分析需附带差异原因说明和纠正行动计划。
+
+## Workflow
+1. 财务数据验证与核对
+2. 差异计算与状态分类
+3. 差异解释与根因分析
+4. 纠正措施制定与执行
+5. 下期预算调整
+
+## Implementation
+参见 [[support-finance-tracker]] 中的年度预算 SQL 查询（`WITH budget_actuals AS ...`）。
+
+## Related Concepts
+- [[Cash Flow Forecasting]]：现金流预测与预算管理同为财务规划支柱
+- [[Financial Risk Assessment]]：差异分析是财务风险预警的重要信号
diff --git a/wiki/concepts/BudgetPacing.md b/wiki/concepts/BudgetPacing.md
new file mode 100644
index 00000000..8121bbb3
--- /dev/null
+++ b/wiki/concepts/BudgetPacing.md
@@ -0,0 +1,54 @@
+---
+title: "Budget Pacing"
+type: concept
+tags: ["ppc", "budget", "pacing", "google-ads", "paid-media"]
+sources: ["paid-media-ppc-strategist"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+预算 Pacing（Budget Pacing）是管理广告日预算消耗速度的策略与模型，确保预算在整个日期范围内（通常一天）均匀消耗，避免早期过快耗尽（错失晚间高转化流量）或过慢消耗（浪费展示份额）。核心目标：**日预算消耗率 95-100%，浪费控制在 5% 以内**。
+
+## Core Concepts
+
+### Daily Budget Mechanics
+- Google Ads 将日预算乘以 30.4（平均每月天数）作为月预算
+- 实际消耗可能在单日波动 ±20%，月度总量不超过月预算
+
+### Pacing Patterns
+
+| 模式 | 描述 | 风险 |
+|------|------|------|
+| **Accelerated** | 尽快消耗预算 | 早期耗尽，错失后续流量 |
+| **Standard** | 算法均匀分配 | 通常推荐 |
+| **Seasonal Adjustment** | 旺季/淡季动态调整 | 需主动管理 |
+
+## Pacing Analysis
+
+### Diminishing Returns Analysis
+- 识别预算边际效益递减点
+- 测试增量预算的转化效率
+- 确定最优预算天花板
+
+### Incremental Spend Testing
+```
+Hypothesis：每增加 $X 日预算，可带来 Y 个额外转化
+Methodology：逐步增加预算 20-30%，监控 CPA 变化
+Stop criteria：CPA 上升超过 X% 或转化量无显著提升
+```
+
+### Seasonal Budget Shifting
+- **Q4 Holiday Season**：提前 4-6 周增加预算，黑色星期五达到峰值
+- **Product Launch**：发布前 2 周开始预热，逐步加码
+- **Off-Peak**：适度降低预算，维持展示份额
+
+## Success Metrics
+- 日预算消耗率：95-100%（过高=浪费，过低=错失流量）
+- 浪费率：<5%
+- 周末/工作日 pacing 一致性
+
+## Connections
+- [[MCCLevelStrategy]]：MCC 级预算分配和 pacing 是多账户协调的核心
+- [[AutomatedBiddingStrategy]]：自动化竞价需配合充足预算才能发挥最佳效果
+- [[GoogleAds]]：Budget Pacing 是 Google Ads 账户管理的基本功
diff --git a/wiki/concepts/BusinessImpactQuantification.md b/wiki/concepts/BusinessImpactQuantification.md
new file mode 100644
index 00000000..a53e8b9d
--- /dev/null
+++ b/wiki/concepts/BusinessImpactQuantification.md
@@ -0,0 +1,29 @@
+---
+title: "Business Impact Quantification"
+type: concept
+tags: ["business-analysis", "consulting", "metrics"]
+sources: ["support-executive-summary-generator"]
+last_updated: 2026-04-26
+---
+
+## Definition
+商业影响量化是一种将业务发现和建议转化为具体、可衡量数据的方法论。核心是用 $ 或 % 等定量指标使影响具体可感知，避免模糊表述。
+
+## Key Principles
+- **量化优先**：用具体数字替代模糊描述（如"34% QoQ增长"而非"显著增长"）
+- **财务影响明确**：Revenue/Cost/Market Share 变化必须量化
+- **风险/机会幅度**：用概率或百分比表达不确定性
+- **时间范围**：明确影响实现的时间节点
+
+## Application in Executive Summary
+- 每个 Key Finding 必须包含 ≥ 1 个量化数据点
+- Business Impact 部分量化潜在收益/损失
+- Recommendations 包含预期结果的可衡量指标
+
+## Examples
+- "Customer acquisition costs increased 34% QoQ, from $45 to $60 per customer"
+- "This initiative could unlock $2.3M in annual recurring revenue within 18 months"
+
+## Related Concepts
+- [[Executive Summary]]
+- [[Action-Oriented Recommendations]]
diff --git a/wiki/concepts/CBT-CognitiveDistortions.md b/wiki/concepts/CBT-CognitiveDistortions.md
new file mode 100644
index 00000000..451849c1
--- /dev/null
+++ b/wiki/concepts/CBT-CognitiveDistortions.md
@@ -0,0 +1,38 @@
+---
+title: "CBT Cognitive Distortions"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# CBT Cognitive Distortions
+
+## Aliases
+- Beck's Cognitive Distortions
+- Cognitive Distortions
+- Thinking Errors
+
+## Definition
+Beck 认知行为疗法中的认知扭曲——非理性、适应不良的思维模式，驱动情绪反应和行为决策。
+
+## Common Cognitive Distortions
+
+| 扭曲类型 | 描述 | 例子 |
+|----------|------|------|
+| All-or-Nothing（全或无思维） | 非黑即白的极端判断 | "如果我不完美，就是彻底的失败" |
+| Overgeneralization（过度概括） | 以单一事件得出普遍结论 | "这次失败了，我永远都会失败" |
+| Mental Filter（心理过滤） | 放大负面、忽视正面 | 只记住批评，忘记所有赞美 |
+| Disqualifying the Positive（贬损正面） | 把正面经历解释为偶然 | "他们夸我只是客气" |
+| Jumping to Conclusions（跳跃式结论） | 无根据的负面解读 | 读心术、预言式思维 |
+| Magnification/Minimization（放大/缩小） | 不成比例地放大负面、缩小正面 | 把小错误灾难化 |
+| Emotional Reasoning（情绪化推理） | "我感觉是这样，所以就是这样" | "我觉得自己很蠢，所以我就是蠢" |
+| Should Statements（"应该"陈述） | 僵化的规则和自我要求 | "我应该总是坚强" |
+| Labeling（标签化） | 用标签代替行为描述 | "我是一个失败者" |
+| Personalization（个人化） | 不恰当地把外部事件和自己关联 | "他生气是因为我" |
+
+## Application in Character Design
+Psychologist Agent 通过识别角色决策背后的具体认知扭曲，而非泛泛说"他们不理性"，使心理分析具有可操作性。
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/CDC-Change-Data-Capture.md b/wiki/concepts/CDC-Change-Data-Capture.md
new file mode 100644
index 00000000..b3150f98
--- /dev/null
+++ b/wiki/concepts/CDC-Change-Data-Capture.md
@@ -0,0 +1,41 @@
+---
+title: "CDC (Change Data Capture)"
+type: concept
+tags: [data-engineering, streaming, incremental-pipeline]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+CDC（Change Data Capture，变更数据捕获）是一种从源系统捕获增量变更（插入、更新、删除）的技术，使数据管道无需全量刷新即可同步最新数据，大幅降低计算成本。
+
+## How It Works
+
+1. **识别变更**：从源数据库的事务日志（WAL）、时间戳字段或变更追踪表中提取变更记录
+2. **携带元数据**：每条 CDC 记录携带变更类型（INSERT/UPDATE/DELETE）、变更时间、来源事务 ID
+3. **幂等写入**：通过主键或变更时间戳实现幂等 upsert（MERGE INTO Delta Lake），确保重新运行安全
+
+## Benefits
+
+- **成本节省**：增量处理 vs. 全量刷新，成本降低 90%+
+- **低延迟**：变更实时捕获，支持分钟级甚至秒级数据刷新
+- **低影响**：CDC 通常基于数据库日志读取，对源系统影响极小
+
+## CDC in Medallion Architecture
+
+- **Bronze 层**：CDC 记录追加写入，保留完整变更历史（append-only）
+- **Silver 层**：基于变更类型（INSERT=插入, UPDATE=更新, DELETE=标记删除）进行去重和 conform
+- **Gold 层**：CDC 支持近实时业务指标更新
+
+## CDC Technologies
+
+- **Debezium**：开源 CDC 平台，捕获 MySQL/PostgreSQL/MongoDB 等变更并发布到 Kafka
+- **AWS DMS**（Database Migration Service）：AWS 托管 CDC 解决方案
+- **Azure Data Factory** CDC 活动：Azure 生态 CDC 工具
+- **Databricks Auto Loader**：`cloudFiles` 增量摄取 CSV/Parquet/JSON 文件变更
+
+## Related Concepts
+- [[Medallion Architecture]]
+- [[Data Contract]]（CDC 需配合数据契约确保 schema 兼容）
+- [[Apache Kafka]]（CDC 常用传输层）
diff --git a/wiki/concepts/CI-CD Pipeline.md b/wiki/concepts/CI-CD Pipeline.md
new file mode 100644
index 00000000..d2e897b4
--- /dev/null
+++ b/wiki/concepts/CI-CD Pipeline.md	
@@ -0,0 +1,83 @@
+---
+title: "CI/CD Pipeline"
+type: concept
+tags: [DevOps, Automation, Software Delivery]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
+---
+
+# CI/CD Pipeline
+
+## 定义
+CI/CD 流水线是自动化软件交付的端到端管道，包含持续集成（Continuous Integration）、持续交付（Continuous Delivery）和持续部署（Continuous Deployment）三个阶段。
+
+## 三个阶段
+
+### 持续集成（CI）
+- 开发者频繁提交代码到共享仓库
+- 每次提交自动触发构建和测试
+- 早期发现集成问题
+
+### 持续交付（CD）
+- 代码通过所有自动化测试后自动部署到 staging 环境
+- 人工审批后部署到生产环境
+- 确保每次变更都可部署
+
+### 持续部署（Continuous Deployment）
+- 代码通过所有测试后自动部署到生产环境
+- 无需人工干预
+- 需要完善的测试和监控体系支撑
+
+## 核心组件
+
+### 构建阶段
+- 代码编译
+- 依赖安装
+- 制品构建（Docker 镜像/二进制文件）
+
+### 测试阶段
+- 单元测试
+- 集成测试
+- 端到端测试
+- 安全扫描
+
+### 部署阶段
+- 部署到目标环境
+- 健康检查
+- 流量切换
+- 回滚机制
+
+## DevOps Automator 的标准流水线
+```yaml
+security-scan → test → build → deploy
+```
+- security-scan：依赖漏洞扫描 + 静态安全分析
+- test：单元测试 + 集成测试
+- build：容器构建 + 推送镜像仓库
+- deploy：零停机部署（蓝绿/金丝雀/滚动）
+
+## 相关工具
+- [[GitHub Actions]]：DevOps Automator 默认选择
+- Jenkins：开源 CI/CD 服务器
+- GitLab CI：GitLab 内置 CI/CD
+- ArgoCD：GitOps 持续交付
+- Spinnaker：多云持续交付平台
+
+## 相关概念
+- [[Infrastructure as Code]]：CI/CD 部署目标通常是 IaC 管理的基础设施
+- [[Zero-Downtime Deployment]]：CI/CD 的部署策略
+- [[Blue-Green Deployment]]：CI/CD 常用部署策略
+
+## 关键指标
+- **部署频率**：每日部署次数
+- **变更前置时间**：代码提交到生产的时间
+- **变更失败率**：生产环境回滚或失败的百分比
+- **MTTR**：平均恢复时间
+
+## Aliases
+- CI/CD
+- CI/CD Pipeline
+- 持续集成/持续交付
+- Continuous Integration
+- Continuous Delivery
+- Continuous Deployment
diff --git a/wiki/concepts/CI-CD-Pipeline.md b/wiki/concepts/CI-CD-Pipeline.md
index 9f983dbe..e6292e14 100644
--- a/wiki/concepts/CI-CD-Pipeline.md
+++ b/wiki/concepts/CI-CD-Pipeline.md
@@ -1,51 +1,51 @@
----
-title: "CI/CD Pipeline"
-type: concept
-sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-9-ci-cd-with-gruntwork]
-last_updated: 2026-04-14
----
-
-## Definition
-CI/CD 流水线（CI/CD Pipeline）是持续集成（Continuous Integration）和持续交付/部署（Continuous Delivery/Deployment）的自动化流程，用于管理基础设施代码（IaC）的构建、测试和部署。在 Gruntwork Landing Zone 架构中，每个 Landing Zone 配置独立的 Jenkins 服务器和 CI/CD 流水线来自动化 Terraform 基础设施变更。
-
-## Core Components
-
-### CI（持续集成）
-- **代码提交**：开发人员将特性分支代码推送到 GitHub 仓库
-- **自动构建**：Jenkins 触发 Terraform 初始化和格式化验证
-- **自动测试**：TerraTest 执行基础设施单元测试和集成测试
-- **代码审查**：Pull Request 必须通过审查才能合并到主分支
-
-### CD（持续交付/部署）
-- **自动部署**：合并到主分支后，Jenkins 自动执行 Terraform Plan
-- **审批流程**：变更需要人工审批后才执行 Apply
-- **渐进式部署**：支持 Blue-Green 部署和 Canary Release 策略
-
-### Infrastructure-Specific Considerations
-- **状态管理**：Terraform State 的锁定和远程存储（使用 S3 + DynamoDB）
-- **幂等性**：Terraform 模块设计必须支持重复执行而不产生副作用
-- **回滚机制**：通过 Terraform State 历史版本实现快速回滚
-- **漂移检测**：定期运行 `terraform plan` 检测配置漂移
-
-## Tools in Gruntwork Landing Zone Context
-- **Jenkins**：核心 CI/CD 引擎，每个 Landing Zone 独立部署
-- **Terraform**：IaC 工具，定义和管理 AWS 资源
-- **TerraTest**：Go 语言编写的基础设施测试框架
-- **GitHub**：代码仓库，支持特性分支和 Pull Request 工作流
-
-## Git Workflow
-- 特性分支开发：`feature/<description>`
-- 通过 Pull Request 合并到主分支
-- 必须经过代码审查和 CI 测试
-- 合并后触发自动部署流水线
-
-## Related Concepts
-- [[Landing-Zone-Architecture]]：CI/CD 流水线是 Landing Zone 自动化运维的核心机制
-- [[Terraform-Modules]]：被 CI/CD 流水线自动化部署的 IaC 模块
-- [[GitOps]]：基于 Git 的运维方式，CI/CD 是其技术实现
-- [[TerraTest]]：用于基础设施变更的自动化测试工具
-
-## References
-- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
-- [[ctp-topic-9-ci-cd-with-gruntwork]]
-- [[ctp-topic-2-git]]
+---
+title: "CI/CD Pipeline"
+type: concept
+sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-9-ci-cd-with-gruntwork, engineering-devops-automator]
+last_updated: 2026-04-14
+---
+
+## Definition
+CI/CD 流水线（CI/CD Pipeline）是持续集成（Continuous Integration）和持续交付/部署（Continuous Delivery/Deployment）的自动化流程，用于管理基础设施代码（IaC）的构建、测试和部署。在 Gruntwork Landing Zone 架构中，每个 Landing Zone 配置独立的 Jenkins 服务器和 CI/CD 流水线来自动化 Terraform 基础设施变更。
+
+## Core Components
+
+### CI（持续集成）
+- **代码提交**：开发人员将特性分支代码推送到 GitHub 仓库
+- **自动构建**：Jenkins 触发 Terraform 初始化和格式化验证
+- **自动测试**：TerraTest 执行基础设施单元测试和集成测试
+- **代码审查**：Pull Request 必须通过审查才能合并到主分支
+
+### CD（持续交付/部署）
+- **自动部署**：合并到主分支后，Jenkins 自动执行 Terraform Plan
+- **审批流程**：变更需要人工审批后才执行 Apply
+- **渐进式部署**：支持 Blue-Green 部署和 Canary Release 策略
+
+### Infrastructure-Specific Considerations
+- **状态管理**：Terraform State 的锁定和远程存储（使用 S3 + DynamoDB）
+- **幂等性**：Terraform 模块设计必须支持重复执行而不产生副作用
+- **回滚机制**：通过 Terraform State 历史版本实现快速回滚
+- **漂移检测**：定期运行 `terraform plan` 检测配置漂移
+
+## Tools in Gruntwork Landing Zone Context
+- **Jenkins**：核心 CI/CD 引擎，每个 Landing Zone 独立部署
+- **Terraform**：IaC 工具，定义和管理 AWS 资源
+- **TerraTest**：Go 语言编写的基础设施测试框架
+- **GitHub**：代码仓库，支持特性分支和 Pull Request 工作流
+
+## Git Workflow
+- 特性分支开发：`feature/<description>`
+- 通过 Pull Request 合并到主分支
+- 必须经过代码审查和 CI 测试
+- 合并后触发自动部署流水线
+
+## Related Concepts
+- [[Landing-Zone-Architecture]]：CI/CD 流水线是 Landing Zone 自动化运维的核心机制
+- [[Terraform-Modules]]：被 CI/CD 流水线自动化部署的 IaC 模块
+- [[GitOps]]：基于 Git 的运维方式，CI/CD 是其技术实现
+- [[TerraTest]]：用于基础设施变更的自动化测试工具
+
+## References
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
+- [[ctp-topic-9-ci-cd-with-gruntwork]]
+- [[ctp-topic-2-git]]
diff --git a/wiki/concepts/CORS-Allowlist.md b/wiki/concepts/CORS-Allowlist.md
new file mode 100644
index 00000000..a4e4fc50
--- /dev/null
+++ b/wiki/concepts/CORS-Allowlist.md
@@ -0,0 +1,28 @@
+---
+title: "CORS-Allowlist"
+type: concept
+tags: []
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Definition
+CORS Allowlist（跨域资源共享白名单）是一种浏览器安全机制，通过精确配置允许特定来源的跨域请求。
+
+## Purpose
+当浏览器中的前端应用（如 Open WebUI）调用不同域的后端 API 时，浏览器会先发送预检请求（OPTIONS），服务器需明确允许该来源才能放行。
+
+## Configuration in Hermes Agent
+Hermes Agent API Server 支持 CORS Allowlist 配置：
+- **环境变量**：`CORS_ALLOWED_ORIGINS` 设置允许的域名列表
+- **默认值**：仅允许配置列表中的来源
+- **安全建议**：生产环境仅开放必要的域名
+
+## Example
+```
+CORS_ALLOWED_ORIGINS=https://app.openwebui.com,https://chat.example.com
+```
+
+## Related
+- [[OpenAI-Compatible-API]]
+- [[hermes-agent]]（via Hermes-Agent.md）
diff --git a/wiki/concepts/CSS-Design-System.md b/wiki/concepts/CSS-Design-System.md
new file mode 100644
index 00000000..4586b983
--- /dev/null
+++ b/wiki/concepts/CSS-Design-System.md
@@ -0,0 +1,92 @@
+---
+title: "CSS Design System"
+type: concept
+tags: [css, design-system, frontend, architecture]
+sources: [design-ux-architect.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+CSS Design System 是一套结构化的 CSS 架构规范，通过 CSS Custom Properties（CSS 变量）定义颜色、排版、间距等基础设计 Token，供整个项目复用，确保视觉一致性和主题切换能力。
+
+## Core Components
+
+### Color System
+```css
+:root {
+  /* Light Theme Colors */
+  --bg-primary: [spec-light-bg];
+  --bg-secondary: [spec-light-secondary];
+  --text-primary: [spec-light-text];
+  --text-secondary: [spec-light-text-muted];
+  --border-color: [spec-light-border];
+
+  /* Brand Colors */
+  --primary-color: [spec-primary];
+  --secondary-color: [spec-secondary];
+  --accent-color: [spec-accent];
+}
+```
+
+### Typography Scale
+```css
+:root {
+  --text-xs: 0.75rem;   /* 12px */
+  --text-sm: 0.875rem;  /* 14px */
+  --text-base: 1rem;    /* 16px */
+  --text-lg: 1.125rem;  /* 18px */
+  --text-xl: 1.25rem;   /* 20px */
+  --text-2xl: 1.5rem;   /* 24px */
+  --text-3xl: 1.875rem; /* 30px */
+}
+```
+
+### Spacing System
+```css
+:root {
+  --space-1: 0.25rem;   /* 4px */
+  --space-2: 0.5rem;    /* 8px */
+  --space-4: 1rem;      /* 16px */
+  --space-6: 1.5rem;    /* 24px */
+  --space-8: 2rem;      /* 32px */
+  --space-12: 3rem;     /* 48px */
+  --space-16: 4rem;     /* 64px */
+}
+```
+
+## Theme Support
+
+CSS Design System 必须原生支持三种主题模式：
+
+- **Light Theme**：浅色背景，深色文字
+- **Dark Theme**：深色背景，浅色文字
+- **System Theme**：`prefers-color-scheme` 检测系统偏好
+
+```css
+[data-theme="dark"] {
+  --bg-primary: [spec-dark-bg];
+  --bg-secondary: [spec-dark-secondary];
+  --text-primary: [spec-dark-text];
+  --text-secondary: [spec-dark-text-muted];
+  --border-color: [spec-dark-border];
+}
+
+@media (prefers-color-scheme: dark) {
+  :root:not([data-theme="light"]) {
+    --bg-primary: [spec-dark-bg];
+    /* ... */
+  }
+}
+```
+
+## Related Concepts
+
+- [[Theme-Toggle]]：主题切换交互组件
+- [[Theme-Manager]]：JavaScript 主题管理类
+- [[Layout-Framework]]：基于此系统的布局架构
+- [[Component-Architecture]]：组件样式规范
+
+## Sources
+
+- [[design-ux-architect]] — CSS Design System 的完整定义和示例代码
diff --git a/wiki/concepts/CTV-OTT-Advertising.md b/wiki/concepts/CTV-OTT-Advertising.md
new file mode 100644
index 00000000..041557e4
--- /dev/null
+++ b/wiki/concepts/CTV-OTT-Advertising.md
@@ -0,0 +1,55 @@
+---
+title: "CTV/OTT Advertising"
+type: concept
+tags: ["ctv", "ott", "streaming", "paid-media", "video"]
+sources: ["paid-media-programmatic-buyer"]
+last_updated: 2026-04-26
+---
+
+## Definition
+
+CTV/OTT Advertising（Connected TV / Over-the-Top Advertising）是指在联网电视设备和流媒体服务上投放的视频广告形式。CTV（Connected TV）指通过互联网连接的消费设备（如 Smart TV、Roku、Amazon Fire TV、Apple TV），OTT（Over-the-Top）指通过互联网直接传输到设备的视频内容订阅服务（如 Netflix、Hulu、Disney+ 等）。
+
+## CTV vs OTT
+
+| 类型 | 设备/平台 | 内容传输方式 |
+|------|---------|------------|
+| CTV | Smart TV、Roku、Fire TV、Apple TV | 设备通过互联网接收内容 |
+| OTT | 独立应用（Netflix、Hulu 等） | 直接通过互联网传输到任何设备 |
+
+## Ad Formats
+
+- **Pre-roll**：在流媒体内容播放前展示（最常见）
+- **Mid-roll**：在内容中途插入，类似于传统电视广告时段
+- **Post-roll**：在内容结束后展示
+- **Pause Ads**：用户暂停播放时展示的全屏广告
+- **Display Overlay**：视频播放时的底部横幅展示
+
+## Buying Methods
+
+- **Programmatic Direct**：通过程序化直接预订优质流媒体库存
+- **Private Marketplace（PMP）**：与特定流媒体平台建立私有交易
+- **Open Exchange**：公开程序化竞价购买 CTV 库存
+
+## Key Metrics
+
+- **Impression Share**：广告展示占可寻址库存的比例
+- **Completion Rate**：视频广告完整播放率（目标 ≥80%）
+- **Viewability Rate**：联网电视 MRC 标准（50% 像素可见 2 秒）
+- **Audible Rate**：音频被激活的展示比例（视频广告）
+- ** household Coverage**：触达的家庭单位数量
+
+## Why CTV/OTT for Brand Extension
+
+- **传统电视的数字化延伸**：以程序化方式触达线性电视受众
+- **优质内容环境**：流媒体内容的品牌安全性和可见性通常高于数字展示
+- **高级定向能力**：超越传统电视的人口统计定向，实现行为和意图定向
+- **跨设备归因**：结合数字展示和CTV数据构建更完整的受众画像
+
+## Related Concepts
+- [[Programmatic Buying]]
+- [[Viewability]]
+- [[Frequency Cap]]
+
+## Sources
+- [[paid-media-programmatic-buyer]]
diff --git a/wiki/concepts/Calibration-Testing.md b/wiki/concepts/Calibration-Testing.md
index 9cc06ee0..86d816cd 100644
--- a/wiki/concepts/Calibration-Testing.md
+++ b/wiki/concepts/Calibration-Testing.md
@@ -1,78 +1,80 @@
----
-title: "Calibration Testing"
-type: concept
-tags: [model-evaluation, probability-calibration, model-quality]
-last_updated: 2026-04-25
----
-
-## Definition
-
-概率校准（Calibration Testing）验证模型输出的预测概率与实际发生的频率是否一致。一个校准良好的分类器：若它预测某事件概率为 80%，则该事件实际发生的频率应接近 80%。
-
-## Core Methods
-
-### Hosmer-Lemeshow Test
-- 将预测概率分组（默认10组），比较每组观测正例数与期望正例数
-- 统计量：$\chi^2 = \sum \frac{(observed - expected)^2}{expected(1 - expected/n)}$
-- 自由度：组数 - 2；p-value < 0.05 → 拒绝原假设（校准差）
-- **局限性**：对样本量敏感，分组方式不同结果不同
-
-### Brier Score
-- $BS = \frac{1}{N}\sum(p_i - y_i)^2$，取值 [0, 0.25]（二分类）
-- 同时衡量校准（calibration）和区分度（refinement）
-- 值越低越好，可分解为：$BS = Calibration^2 + Refinement$
-- **优势**：无需分组，对样本量稳健，可跨模型比较
-
-### Reliability Diagram（可靠性图）
-- 将预测概率分箱（bin），绘制实际正例率 vs 预测概率
-- 理想情况为 45° 对角线；S 形曲线表示欠/过度预测
-- 视觉诊断工具，适合识别系统性校准偏差
-
-### Expected Calibration Error (ECE)
-- 加权平均每箱预测概率与实际频率的绝对差
-- $ECE = \sum_b \frac{|b|}{n} |acc(b) - conf(b)|$
-- 量化校准误差，便于跨模型对比
-
-## Usage
-
-```python
-# Hosmer-Lemeshow
-from scipy.stats import chi2
-
-def hosmer_lemshow_test(y_true, y_pred, groups=10):
-    data = pd.DataFrame({"y": y_true, "p": y_pred})
-    data["bucket"] = pd.qcut(data["p"], groups, duplicates="drop")
-    agg = data.groupby("bucket", observed=True).agg(
-        n=("y", "count"), observed=("y", "sum"), expected=("p", "sum")
-    )
-    hl_stat = (((agg["observed"] - agg["expected"])**2) /
-               (agg["expected"] * (1 - agg["expected"]/agg["n"]))).sum()
-    dof = len(agg) - 2
-    p_value = 1 - chi2.cdf(hl_stat, dof)
-    return {"HL_statistic": round(hl_stat, 4), "p_value": round(p_value, 6), "calibrated": p_value >= 0.05}
-
-# Brier Score
-from sklearn.metrics import brier_score_loss
-bs = brier_score_loss(y_true, y_pred)
-```
-
-## Model QA 中的应用
-
-Model QA Specialist 执行以下校准审计：
-1. **跨子群体校准**：在年龄/地区/收入等子群体上分别测试，发现整体指标掩盖的局部校准问题
-2. **时间窗口稳定性**：跨 OOT（Out-of-Time）窗口测试校准稳定性，识别时间漂移
-3. **分布偏移下的校准**：在压力场景（population shift）下测试，评估模型鲁棒性
-4. **决策阈值校准**：根据业务决策阈值（如 p > 0.6 触发行动），评估该阈值处的校准质量
-
-## Relationship
-
-- **依赖** [[Discrimination-Metrics]]：先验证模型有区分能力（AUC/Gini），再讨论校准才有意义
-- **依赖** [[SHAP]]：SHAP 解释"哪个特征导致校准偏差"，支撑诊断方向
-- **依赖** [[Population-Stability-Index]]：PSI 捕捉特征分布漂移，漂移是校准失效的根本原因之一
-- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的核心审计步骤之一
-
-## Key Insights
-
-- **High AUC ≠ Well Calibrated**：模型可以高区分度但低校准（如逻辑回归自然校准，神经网络往往过度自信）
-- **业务影响**：校准误差 180bps（0.18）在 decile 10 可能影响 12% 的资产组合
-- **监管要求**：巴塞尔协议/IFRS 9/CCAR 等监管框架明确要求信用风险模型的概率校准
+---
+title: "Calibration Testing"
+type: concept
+tags: [model-evaluation, probability-calibration, model-quality]
+sources:
+  - specialized-model-qa
+last_updated: 2026-05-29
+---
+
+## Definition
+
+概率校准（Calibration Testing）验证模型输出的预测概率与实际发生的频率是否一致。一个校准良好的分类器：若它预测某事件概率为 80%，则该事件实际发生的频率应接近 80%。
+
+## Core Methods
+
+### Hosmer-Lemeshow Test
+- 将预测概率分组（默认10组），比较每组观测正例数与期望正例数
+- 统计量：$\chi^2 = \sum \frac{(observed - expected)^2}{expected(1 - expected/n)}$
+- 自由度：组数 - 2；p-value < 0.05 → 拒绝原假设（校准差）
+- **局限性**：对样本量敏感，分组方式不同结果不同
+
+### Brier Score
+- $BS = \frac{1}{N}\sum(p_i - y_i)^2$，取值 [0, 0.25]（二分类）
+- 同时衡量校准（calibration）和区分度（refinement）
+- 值越低越好，可分解为：$BS = Calibration^2 + Refinement$
+- **优势**：无需分组，对样本量稳健，可跨模型比较
+
+### Reliability Diagram（可靠性图）
+- 将预测概率分箱（bin），绘制实际正例率 vs 预测概率
+- 理想情况为 45° 对角线；S 形曲线表示欠/过度预测
+- 视觉诊断工具，适合识别系统性校准偏差
+
+### Expected Calibration Error (ECE)
+- 加权平均每箱预测概率与实际频率的绝对差
+- $ECE = \sum_b \frac{|b|}{n} |acc(b) - conf(b)|$
+- 量化校准误差，便于跨模型对比
+
+## Usage
+
+```python
+# Hosmer-Lemeshow
+from scipy.stats import chi2
+
+def hosmer_lemshow_test(y_true, y_pred, groups=10):
+    data = pd.DataFrame({"y": y_true, "p": y_pred})
+    data["bucket"] = pd.qcut(data["p"], groups, duplicates="drop")
+    agg = data.groupby("bucket", observed=True).agg(
+        n=("y", "count"), observed=("y", "sum"), expected=("p", "sum")
+    )
+    hl_stat = (((agg["observed"] - agg["expected"])**2) /
+               (agg["expected"] * (1 - agg["expected"]/agg["n"]))).sum()
+    dof = len(agg) - 2
+    p_value = 1 - chi2.cdf(hl_stat, dof)
+    return {"HL_statistic": round(hl_stat, 4), "p_value": round(p_value, 6), "calibrated": p_value >= 0.05}
+
+# Brier Score
+from sklearn.metrics import brier_score_loss
+bs = brier_score_loss(y_true, y_pred)
+```
+
+## Model QA 中的应用
+
+Model QA Specialist 执行以下校准审计：
+1. **跨子群体校准**：在年龄/地区/收入等子群体上分别测试，发现整体指标掩盖的局部校准问题
+2. **时间窗口稳定性**：跨 OOT（Out-of-Time）窗口测试校准稳定性，识别时间漂移
+3. **分布偏移下的校准**：在压力场景（population shift）下测试，评估模型鲁棒性
+4. **决策阈值校准**：根据业务决策阈值（如 p > 0.6 触发行动），评估该阈值处的校准质量
+
+## Relationship
+
+- **依赖** [[Discrimination-Metrics]]：先验证模型有区分能力（AUC/Gini），再讨论校准才有意义
+- **依赖** [[SHAP]]：SHAP 解释"哪个特征导致校准偏差"，支撑诊断方向
+- **依赖** [[Population-Stability-Index]]：PSI 捕捉特征分布漂移，漂移是校准失效的根本原因之一
+- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的核心审计步骤之一
+
+## Key Insights
+
+- **High AUC ≠ Well Calibrated**：模型可以高区分度但低校准（如逻辑回归自然校准，神经网络往往过度自信）
+- **业务影响**：校准误差 180bps（0.18）在 decile 10 可能影响 12% 的资产组合
+- **监管要求**：巴塞尔协议/IFRS 9/CCAR 等监管框架明确要求信用风险模型的概率校准
diff --git a/wiki/concepts/Cash-Flow-Forecasting.md b/wiki/concepts/Cash-Flow-Forecasting.md
new file mode 100644
index 00000000..e1e792cb
--- /dev/null
+++ b/wiki/concepts/Cash-Flow-Forecasting.md
@@ -0,0 +1,34 @@
+---
+title: "Cash Flow Forecasting"
+type: concept
+tags: ["finance", "forecasting", "liquidity"]
+last_updated: 2026-04-30
+---
+
+## Definition
+现金流预测是通过历史模式分析和季节性因子，对企业未来若干期（通常为 12 期滚动）的现金收支进行量化预测的过程，旨在维持流动性并优化资金使用效率。
+
+## Core Components
+- **历史模式分析**：按月聚合 receipts（收款）、payments（付款）、net_cash_flow（净现金流）的均值和标准差
+- **季节性因子**：针对不同月份应用季节性调整系数，反映周期性波动
+- **增长因子**：根据业务增长趋势调整预测基准
+- **置信区间**：通常设置 ±15% 的置信区间（如 net_cash_flow × 0.85 / 1.15）
+
+## Key Metrics
+- **累积现金**（cumulative_cash）：当前现金余额 + 预测期净现金流之和
+- **低现金预警**：累积现金 < $50,000 时触发，行动建议为加速收款或延迟付款
+- **高现金机会**：累积现金 > $200,000 时触发，建议考虑短期投资或预付费用
+
+## Payment Timing Optimization
+根据以下公式计算支付优先级分数：
+```
+priority_score = early_pay_discount × amount × 365 / payment_terms
+```
+优先处理高折扣机会，同时维持现金流健康。
+
+## Implementation
+参见 [[support-finance-tracker]] 中 `CashFlowManager` Python 类的实现。
+
+## Related Concepts
+- [[Budget Variance Analysis]]：与现金流预测同为财务规划核心工具
+- [[ROI]]：投资回报评估与现金流优化相互关联
diff --git a/wiki/concepts/Certora.md b/wiki/concepts/Certora.md
new file mode 100644
index 00000000..a9d05c51
--- /dev/null
+++ b/wiki/concepts/Certora.md
@@ -0,0 +1,72 @@
+---
+title: "Certora（形式化验证工具）"
+type: concept
+tags: [blockchain, security, smart-contract, formal-verification, tooling]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Certora
+- Certora Prover
+- Certora Verification System
+
+## Definition
+
+Certora 是一个基于符号执行（Symbolic Execution）的智能合约形式化验证工具，通过 CVL（Certora Verification Language）描述协议规范，系统性证明 Solidity 合约的关键属性是否在所有可能状态下成立。与测试不同，Certora 可以证明某个属性**在数学上不可能被违反**。
+
+## Key Capabilities
+
+- **属性证明**：验证合约不变性（invariant）在所有执行路径上成立
+- **反例生成**：当属性无法被证明时，自动生成导致属性失败的最小执行序列
+- **多合约分析**：支持分析调用关系复杂的合约系统
+- **并行验证**：可并行验证多条规则
+
+## CVL Example
+
+```
+rule noUnauthorizedWithdrawal(method f) {
+    env e;
+    calldataarg args;
+
+    require f != nop; // 排除空调用
+
+    // 如果调用成功，则调用者必须是所有者
+    f(e, args);
+    assert e.msg.sender == owner, "Unauthorized withdrawal";
+}
+
+invariant totalSupplyInvariant() {
+    // 总供应量恒定
+    invariant totalSupply == init(totalSupply);
+}
+```
+
+## Integration with Foundry
+
+Certora 可与 Foundry 集成：
+```bash
+# 使用 Halmos 进行字节码级验证
+forge test --match-contract CertoraTest
+
+# 使用 Certora CLI
+certora Run Vault.spec Vault.sol --prover z3 cvc5
+```
+
+## Limitations
+
+- 需要人工编写精确的 CVL 规范（规范本身可能出错）
+- 复杂合约状态空间可能导致超时
+- 对外部依赖和链上状态处理有限
+- 学习曲线陡峭
+
+## Relationship to Audit
+
+- Certora 是 [[Blockchain-Security-Auditor]] 进行 [[Formal-Verification]] 的主要工具
+- 适合验证关键协议属性：份额不变性、借贷健康度、权限不变性
+- 与 [[Slither]] 互补：Slither 找代码模式漏洞，Certora 证明数学属性
+
+## Connections
+- [[Blockchain-Security-Auditor]] ← uses ← [[Certora]]
+- [[Formal-Verification]] ← implements ← [[Certora]]
+- [[Halmos]] ← complementary bytecode verification ← [[Certora]]
diff --git a/wiki/concepts/ChalkboardStyle.md b/wiki/concepts/ChalkboardStyle.md
new file mode 100644
index 00000000..b5994f5d
--- /dev/null
+++ b/wiki/concepts/ChalkboardStyle.md
@@ -0,0 +1,58 @@
+---
+title: "ChalkboardStyle"
+type: concept
+tags: ["ai-image", "visual-style", "prompt-engineering"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Chalkboard Style（黑板粉笔风格）是一种复古手绘视觉风格，通过深绿黑背景、手绘粉笔线条、严格限制的 6 色配色盘和木框边框实现统一的视觉氛围，常用于 AI 信息图设计。
+
+## Visual Specifications
+
+### Background
+- 颜色：#1C2B1C（深绿黑色）
+- 纹理：粉笔灰痕迹、细微划痕、橡皮擦涂抹痕迹
+
+### Color Palette（严格限制 6 色）
+| 颜色 | Hex 值 | 用途 |
+|------|--------|------|
+| 粉笔白 | #F5F5F5 | 主要文字、轮廓线 |
+| 粉笔黄 | #FFE566 | 高亮、下划线、强调 |
+| 粉笔粉 | #FF9999 | 次级高亮、图标 |
+| 粉笔蓝 | #66B3FF | 图表、技术元素 |
+| 粉笔绿 | #90EE90 | 成功、自然、正面 |
+| 粉笔橙 | #FFB366 | 警告、能量 |
+
+### Lines & Typography
+- 所有线条必须手绘、速写式（slightly wavy/imperfect）
+- 禁止完美几何形状
+- 禁止渐变效果
+- 禁止数字感强的字体
+
+### Frame & Decoration
+- 木框边框（hand-drawn wood grain 线条）
+- 手绘星星（5-7 点，不规则）
+- 手绘下划线（波浪形）
+- 手绘箭头（速写式）
+- 手绘圆形围绕关键词
+- 手绘对勾标记
+- 散落粉笔灰粒子
+
+### Prohibited Elements
+- NO gradients（禁止渐变）
+- NO perfect geometric shapes（禁止完美几何形状）
+- NO photorealistic elements（禁止写实元素）
+- NO clean digital vectors（禁止干净的数字矢量）
+
+## Application
+
+在 AI 图片生成提示词中使用时，需要：
+1. 在 [[StyleSeed]] 中定义完整的视觉参数
+2. 在 [[StyleLock]] 中添加逐项检查清单
+3. 通过 hex 色值消除颜色描述的歧义
+
+## Sources
+
+- [[如何让AI生成风格一致的图片]]
diff --git a/wiki/concepts/Champion-Challenger.md b/wiki/concepts/Champion-Challenger.md
new file mode 100644
index 00000000..5a4f77b6
--- /dev/null
+++ b/wiki/concepts/Champion-Challenger.md
@@ -0,0 +1,54 @@
+---
+title: "Champion-Challenger Framework"
+type: concept
+tags: [model-evaluation, model-deployment, champion-challenger, model-governance]
+sources:
+  - specialized-model-qa
+last_updated: 2026-05-29
+---
+
+## Definition
+
+Champion-Challenger 框架（冠军-挑战者框架）是一种系统化的模型替代评估方法：在生产环境保持当前模型（Champion）运行的同时，引入新候选模型（Challenger）并行评分，通过量化对比决定是否将 Challenger 升级为新的 Champion。核心目标：在保证业务稳定性的前提下，以数据驱动的方式持续提升模型质量。
+
+## Core Mechanics
+
+### Shadow Mode Deployment（影子模式）
+- Challenger 模型在生产流量上实时评分，但**不实际影响决策**
+- 所有输出被记录但不触发行动
+- 优势：无需 A/B 分流风险，收集真实分布数据
+
+### A/B Split（分流测试）
+- 将生产流量按比例分配给 Champion 和 Challenger
+- Challenger 的预测直接触发实际决策
+- 适用场景：需要真实业务反馈且风险可控时
+
+### Multi-Challenger Ranking
+- 同时存在多个 Challenger 时，按以下优先级评估：
+  1. **统计显著性**：AUC/KS 提升是否有统计意义（DeLong test）
+  2. **业务影响**：性能提升的绝对业务价值（Revenue/Cost/Conversion）
+  3. **稳定性**：Challenger 在各子群体和时间窗口上的表现一致性
+  4. **可解释性**：SHAP 特征重要性是否发生重大结构性变化
+
+## Model QA 中的应用
+
+Model QA Specialist 使用 Champion-Challenger 框架执行以下审计：
+1. **基准建立**：记录 Champion 模型的 AUC/Gini/KS 基准值和跨切片表现
+2. **Challenger 评估**：对候选模型进行全 10 域审计，不限于性能指标
+3. **迁移决策**：只有 Challenger 在**所有关键域**达到或超越 Champion 时才建议迁移
+4. **回滚计划**：每次 Challenger 上线必须有可执行的回滚方案
+
+## Relationship
+
+- **依赖** [[Discrimination-Metrics]]：AUC/Gini/KS 是量化 Champion vs Challenger 差异的核心指标
+- **依赖** [[Calibration-Testing]]：Hosmer-Lemeshow 检验确保 Challenger 在各子群体上的校准稳定性
+- **依赖** [[Population-Stability-Index]]：PSI 监控 Challenger 在生产分布上的稳定性
+- **依赖** [[SHAP]]：SHAP 对比分析 Challenger vs Champion 的特征贡献结构变化
+- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 性能与监控步骤中的基准对比工具
+
+## Key Insights
+
+- **不只看 AUC**：Champion 升级决策必须综合考虑性能、公平性、校准和业务影响
+- **时间窗口**：必须收集足够长时间（至少一个业务周期）的 Challenger 数据
+- **灰度发布**：避免一次性全量切换，先小比例验证再扩大
+- **监管合规**：金融/医疗等受监管行业的模型更换须符合模型变更治理流程
diff --git a/wiki/concepts/Chaos-Physics.md b/wiki/concepts/Chaos-Physics.md
new file mode 100644
index 00000000..73550d20
--- /dev/null
+++ b/wiki/concepts/Chaos-Physics.md
@@ -0,0 +1,40 @@
+---
+title: "Chaos Physics"
+type: concept
+tags: ["unreal-engine", "physics", "destruction", "chaos-engine"]
+sources: ["unreal-systems-engineer"]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Chaos Destruction System
+- UE5 Chaos Physics Engine
+- Geometry Collections
+
+## 定义
+Chaos 是 UE5 的物理与破坏系统，提供实时网格破碎、刚体约束和高级物理模拟能力。
+
+## 核心组件
+
+### Geometry Collections
+- 用于实时网格破碎的破碎几何体集合
+- 在 Fracture Editor 中制作破碎资产
+- 通过 `UChaosDestructionListener` 触发破碎事件
+
+### Constraint Types
+Chaos 支持多种约束类型：
+- **Rigid**（刚性）— 固定断裂块之间的连接
+- **Soft**（柔性）— 允许一定形变的连接
+- **Spring**（弹簧）— 带弹性的连接
+- **Suspension**（悬挂）— 模拟悬挂系统
+
+### Destruction LOD
+- 近景：完整 Chaos 模拟
+- 远景：缓存动画播放（降低计算开销）
+
+## 性能分析
+使用 **Unreal Insights** 的 Chaos 专用 trace 通道分析物理求解器性能。
+
+## 相关概念
+- [[Actor Replication]] — 破碎物理的网络复制注意事项
+- [[UnrealEngine5]] — Chaos 是 UE5 的内置物理引擎
diff --git a/wiki/concepts/CharacterArc.md b/wiki/concepts/CharacterArc.md
new file mode 100644
index 00000000..4a01247a
--- /dev/null
+++ b/wiki/concepts/CharacterArc.md
@@ -0,0 +1,40 @@
+---
+title: "Character Arc"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Character Arc
+- 角色弧线
+- 角色发展弧
+
+## Overview
+Character Arc（角色弧线）描述角色在叙事过程中从起始状态到终态的内在变化轨迹。与角色在情节中采取的行动（Plot Arc）不同，Character Arc 关注角色的内心世界、信念体系和心理成熟度。
+
+## Arc Types
+
+| Type | Description |
+|------|-------------|
+| **Transformative** | 角色核心信念被颠覆，实现内在成长或改变 |
+| **Steadfast** | 角色信念被考验但最终被确认为正确坚守 |
+| **Flat** | 角色不经历内在变化（通常是功能性角色） |
+| **Tragic** | 角色因无法克服内在缺陷或错误选择而走向毁灭 |
+| **Comedic** | 角色通过接受内在真相获得和谐/社会整合 |
+
+## Core Components（[[Academic Narratologist]] 模型）
+
+### Four Checkpoints
+1. **Want（欲望/外在目标）**：角色在情节中追求的具体目标
+2. **Need（需求/内在必要性）**：角色真正需要获得的东西（通常与其 Want 不同）
+3. **Lie（信念谎言）**：角色持有但需要被挑战的错误信念
+4. **Transformation（蜕变）**：角色面对真相时的内在改变
+
+### Supporting Elements
+- **Ghost/Wound**：驱动角色行为的过往创伤或经历
+- **Backstory**：支撑 Ghost 的具体事件
+
+## Application
+[[Academic Narratologist]] 的核心分析工具之一。每个角色弧线都必须有清晰的 want/need/lie/transformation 四个要素，并通过故事事件逐一验证。
diff --git a/wiki/concepts/ChatCompletions.md b/wiki/concepts/ChatCompletions.md
new file mode 100644
index 00000000..0acdfebe
--- /dev/null
+++ b/wiki/concepts/ChatCompletions.md
@@ -0,0 +1,35 @@
+---
+title: "ChatCompletions"
+type: concept
+tags:
+  - "openai"
+  - "api"
+  - "chat"
+sources: []
+last_updated: 2026-04-20
+---
+
+## Overview
+
+Chat Completions 是 OpenAI 标准的聊天补全 API 格式，通过 `POST /v1/chat/completions` 端点调用。Hermes Agent 的 API Server 默认使用此模式，无需额外配置。
+
+## Key Characteristics
+
+- **请求格式**：`{"model": "...", "messages": [...]}`
+- **响应格式**：返回 `choices[].message` 完整回复
+- **历史管理**：每次请求携带完整对话历史
+- **工具调用**：支持 `tools` / `tool_calls` 参数
+- **流式输出**：支持 `stream: true`，实时推送 token
+
+## vs Responses API
+
+| 特性 | Chat Completions | Responses API |
+|---|---|---|
+| 状态管理 | 客户端携带历史 | 服务端 `previous_response_id` |
+| 事件流 | 逐 token 块 | 结构化事件（text_delta, function_call） |
+| 稳定性 | 稳定（默认） | 实验性 |
+| 适用场景 | 通用对话 | 需要服务端状态追踪的场景 |
+
+## See Also
+- [[APIServer]]
+- [[ResponsesAPI]]
diff --git a/wiki/concepts/Checks-Effects-Interactions.md b/wiki/concepts/Checks-Effects-Interactions.md
new file mode 100644
index 00000000..27e7f377
--- /dev/null
+++ b/wiki/concepts/Checks-Effects-Interactions.md
@@ -0,0 +1,81 @@
+---
+title: "Checks-Effects-Interactions Pattern"
+type: concept
+tags: [blockchain, security, smart-contract, reentrancy, best-practices]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Checks-Effects-Interactions
+- CEI Pattern
+- Checks-Effects-Interactions Pattern
+
+## Definition
+
+Checks-Effects-Interactions（CEI，检查-效果-交互）模式是智能合约安全编程的核心防御模式，用于防止重入攻击和其他逻辑漏洞。其核心原则是：**在执行任何外部调用之前，先完成所有的状态检查和状态更新**。
+
+## Pattern
+
+```
+function withdraw() external {
+    // 1. CHECKS — 验证前置条件
+    require(balances[msg.sender] > 0, "No balance");
+    
+    // 2. EFFECTS — 更新合约状态（在外部调用之前）
+    balances[msg.sender] = 0;
+    
+    // 3. INTERACTIONS — 执行外部调用（最后一步）
+    (bool success,) = msg.sender.call{value: amount}("");
+    require(success, "Transfer failed");
+}
+```
+
+## Why It Works
+
+传统重入攻击利用的漏洞链：
+```
+外部调用（ETH转账）→ 攻击者receive()被触发 
+→ 攻击者 re-enter withdraw() 
+→ balances[msg.sender] 仍 > 0（未清零）
+→ 重复提取资金
+```
+
+CEI 模式切断漏洞链：**状态在外部调用之前清零**，即使攻击者 re-enter，条件检查阶段 `require(balances[msg.sender] > 0)` 已失败。
+
+## Common Mistakes
+
+### Wrong Order (Vulnerable)
+```solidity
+// VULNERABLE: 外部调用在状态更新之前
+(bool success,) = msg.sender.call{value: amount}("");
+require(success);
+balances[msg.sender] = 0; // 攻击者可在此之前 re-enter
+```
+
+### Missing Update (Vulnerable)
+```solidity
+// VULNERABLE: 状态根本没有更新
+require(balances[msg.sender] > 0);
+(bool success,) = msg.sender.call{value: amount}("");
+require(success);
+// balances[msg.sender] = 0; ← 忘记更新！
+```
+
+### ERC-20 Transfer Before Update
+```solidity
+// VULNERABLE: ERC-20 transfer 触发外部调用
+IERC20(token).transfer(msg.sender, amount); // 外部调用
+balances[msg.sender] -= amount; // 状态更新太晚
+```
+
+## Relationship to Other Defenses
+
+- **CEI is the primary defense** — should always be applied first
+- **ReentrancyGuard is additional defense** — use when CEI is difficult to apply (complex logic, callbacks)
+- CEI + ReentrancyGuard together provide defense in depth
+
+## Connections
+- [[Reentrancy]] ← prevents ← [[Checks-Effects-Interactions]]
+- [[Blockchain-Security-Auditor]] ← enforces ← [[Checks-Effects-Interactions]]
+- [[ReentrancyGuard]] ← supplements ← [[Checks-Effects-Interactions]]
diff --git a/wiki/concepts/ChecksEffectsInteractions.md b/wiki/concepts/ChecksEffectsInteractions.md
new file mode 100644
index 00000000..752a5f88
--- /dev/null
+++ b/wiki/concepts/ChecksEffectsInteractions.md
@@ -0,0 +1,41 @@
+---
+title: "ChecksEffectsInteractions"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+_checks-effects-interactions_ 是 Solidity 智能合约开发的核心安全原则，规定函数内操作必须按以下顺序执行：
+
+1. **Checks**：验证前置条件（require/assert 语句）
+2. **Effects**：更新合约内部状态（状态变量修改）
+3. **Interactions**：执行外部调用（token transfer、合约调用等）
+
+## Why It Matters
+违反此顺序会导致 **重入攻击（Reentrancy Attack）**。如果外部调用在状态更新之前执行，攻击者的恶意合约可以在状态仍然显示"资金未提取"的情况下递归调用 withdraw()，反复提取资金。
+
+### Vulnerable Pattern (违反 CEI)
+```solidity
+function withdraw(uint256 amount) external {
+    require(balances[msg.sender] >= amount);
+    // ❌ 外部调用在状态更新之前
+    msg.sender.call{value: amount}("");
+    balances[msg.sender] -= amount; // 太晚了
+}
+```
+
+### Secure Pattern (遵循 CEI)
+```solidity
+function withdraw(uint256 amount) external {
+    require(balances[msg.sender] >= amount);
+    balances[msg.sender] -= amount; // ✅ 先更新状态
+    emit Withdrawal(msg.sender, amount);
+    msg.sender.call{value: amount}(""); // ✅ 最后外部调用
+}
+```
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
+- [[The-DAO]]
+- [[blockchain-security-auditor]]
diff --git a/wiki/concepts/Circuit-Breaker.md b/wiki/concepts/Circuit-Breaker.md
new file mode 100644
index 00000000..e509df11
--- /dev/null
+++ b/wiki/concepts/Circuit-Breaker.md
@@ -0,0 +1,40 @@
+---
+title: "Circuit Breaker"
+type: concept
+tags: []
+sources: [engineering-autonomous-optimization-architect]
+last_updated: 2026-05-01
+---
+
+# Circuit Breaker
+
+## Definition
+
+熔断器模式（Circuit Breaker）——当某个 LLM API 端点连续失败超过预设阈值时，自动切断对该端点的路由，将流量切换到降级路径，同时向人工告警。
+
+## Mechanism
+
+1. **Closed（正常）**：所有请求正常路由到目标端点
+2. **Open（熔断）**：端点连续失败超过阈值，立即切断路由，所有请求跳过该端点
+3. **Half-Open（半开）**：经过冷却期后，放行少量请求试探端点是否恢复
+
+## Trigger Conditions
+
+- 端点流量异常激增（500%+，可能为恶意 bot 攻击）
+- 连续出现 HTTP 402（需要付费）/ 429（速率限制）错误
+- 单次请求成本超过安全上限（如 $0.05/次）
+
+## Example
+
+```typescript
+if (provider.failures > securityLimits.maxRetries) {
+    tripCircuitBreaker(provider);
+    routeToFallback(provider);
+    alertAdmin(`Circuit breaker tripped: ${provider.name}`);
+}
+```
+
+## Related
+
+- [[Autonomous-Optimization-Architect]]：使用熔断器保护 AI 路由系统的核心组件
+- [[AI-FinOps]]：熔断器是 FinOps 成本控制的最后防线
diff --git a/wiki/concepts/CodebaseOnboarding.md b/wiki/concepts/CodebaseOnboarding.md
new file mode 100644
index 00000000..4a12856a
--- /dev/null
+++ b/wiki/concepts/CodebaseOnboarding.md
@@ -0,0 +1,36 @@
+---
+title: "CodebaseOnboarding"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+
+Codebase Onboarding 是帮助新开发者快速理解陌生代码库的方法论和实践体系。核心目标是缩短从"首次接触代码库"到"能够独立定位问题、修改代码"的认知建立时间。
+
+## Core Principles
+
+- **Evidence-first**: 只陈述代码中可验证的事实
+- **Layered explanation**: 分层递进式解释（一句话 → 五分钟 → 深度代码流）
+- **File-level precision**: 所有结论必须指向具体文件路径
+- **Honest scope**: 明确告知哪些部分已检查、哪些未检查
+
+## Key Methods
+
+1. **Inventory & Classification** — 识别清单文件（manifests/lockfiles）、框架标记、构建工具、顶层目录
+2. **Entry Point Discovery** — 找到启动文件、路由、处理器、CLI 命令
+3. **Execution Tracing** — 端到端追踪输入→验证→编排→持久化→输出
+4. **Boundary Analysis** — 识别模块边界、包边界、共享工具、重复职责
+
+## Usage Context
+
+- 新开发者 onboarding
+- 大型代码库结构探索
+- 故障定位前的代码结构理解
+
+## Related Concepts
+
+- [[ExecutionTracing]] — 执行路径追踪
+- [[EvidenceFirstReasoning]] — 证据优先推理
+- [[MinimalChangePrinciple]] — 与 [[EngineeringMinimalChangeEngineer]] 配合使用
diff --git a/wiki/concepts/Cognitive-Load-Reduction.md b/wiki/concepts/Cognitive-Load-Reduction.md
index bb53d979..0a612ef5 100644
--- a/wiki/concepts/Cognitive-Load-Reduction.md
+++ b/wiki/concepts/Cognitive-Load-Reduction.md
@@ -1,29 +1,46 @@
----
-title: "Cognitive Load Reduction"
-type: concept
-tags: [ux, productivity, behavioral-psychology, task-management]
-last_updated: 2026-04-20
----
-
-## Definition
-认知负荷降低（Cognitive Load Reduction）指通过界面设计、任务拆分和流程优化，减少用户完成任务所需的心理努力，防止决策疲劳和任务瘫痪。
-
-## Mechanism
-1. **任务拆分**：将大型工作流分解为微小、可完成的微任务单元
-2. **单一焦点**：每次仅推送一个最高优先级的可操作项，而非批量列表
-3. **渐进披露**：按需逐步展示信息，避免信息过载
-4. **即时上下文**：为每个任务提供充分的执行背景，减少搜索和回忆成本
-
-## Applications
-- 微冲刺（Micro-Sprint）：5-15 分钟短时任务块
-- [[Pomodoro Technique]] 时间盒工作
-- 队列视图仅显示当前最关键项
-- ADHD 用户友好设计模式
-
-## Related Concepts
-- [[Default Bias]]：降低决策摩擦的互补机制
-- [[Pomodoro Technique]]：时间盒化的认知负荷管理实践
-- [[Momentum Nudge]]：维持用户行动动量防止认知疲劳
-
-## Source
-- [[Behavioral Nudge Engine]] — 核心应用场景
+---
+title: "Cognitive Load Reduction"
+type: concept
+tags: []
+sources: ["product-behavioral-nudge-engine"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Cognitive Load Reduction（认知负荷降低）是一种软件交互设计原则——通过信息过滤、任务分解和界面简化，主动降低用户在决策和执行过程中的认知负担，防止因信息过载导致的决策瘫痪和平台流失。
+
+## Core Problem
+
+> "If a user has 50 items pending, do not show them 50. Show them the 1 most critical item."
+
+大量待办任务列表是认知过载的典型来源。当用户面对大量未完成任务时，会产生「决策瘫痪」——因无法决定从何处开始而选择什么都不做。
+
+## Strategy Taxonomy
+
+| 策略 | 描述 | 示例 |
+|------|------|------|
+| 信息过滤 | 只展示最关键的N项 | 任务列表只显示 Top 1 |
+| 任务分解 | 将复杂任务拆解为微步骤 | 将「完成项目报告」拆解为「只写第一段」 |
+| 预设草案 | 预先填充内容减少起步阻力 | [[Default Bias]] 的应用 |
+| 时间盒 | 限制单次执行时长 | [[Micro-Sprint]] 5分钟冲刺 |
+| 进度可见 | 展示已完成vs总任务数 | 庆祝15个已完成而非展示95个待完成 |
+
+## Behavioral Science Foundation
+
+- **Miller's Law**：人类工作记忆容量约为 7±2 个信息块
+- **Zeigarnik Effect**：未完成任务比已完成任务占用更多认知资源
+- **Goal Gradient Effect**：越接近目标，动机越强——通过展示小范围完成积累信心
+
+## Related Concepts
+
+- [[Micro-Sprint]] — 认知负荷降低的核心执行机制
+- [[Default Bias]] — 通过预设草案降低决策门槛
+- [[Gamification]] — 通过进度可视化维持动力
+- [[Habit Formation]] — 低认知负荷是习惯形成的前提条件
+
+## Connections
+
+- [[Behavioral Nudge Engine]] — 认知负荷管理是核心职责
+- [[Product Manager Agent]] — 产品设计需内化认知负荷原则
+- [[Habit Tracker & Accountability Coach]] — 低摩擦的habit建立依赖认知负荷控制
diff --git a/wiki/concepts/Command-Theater.md b/wiki/concepts/Command-Theater.md
new file mode 100644
index 00000000..0011c25b
--- /dev/null
+++ b/wiki/concepts/Command-Theater.md
@@ -0,0 +1,61 @@
+---
+title: "Command Theater"
+type: concept
+tags: []
+last_updated: 2026-03-05
+---
+
+## Definition
+
+Command Theater（指挥剧场）是 [[nexus-spatial-discovery]] 中 [[Nexus Spatial]] 产品定义的空间界面布局架构——以用户为中心的弧形"指挥剧场"，将工作空间按功能分层布局于不同深度和角度。
+
+## Architecture
+
+```
+                        OVERVIEW CANOPY
+                     (pipeline topology)
+                    ~~~~~~~~~~~~~~~~~~~~~~~~
+                   /                        \
+                  /     FOCUS ARC (120 deg)   \
+                 /    primary node graph work   \
+                /________________________________\
+               |                                  |
+    LEFT       |        USER POSITION             |       RIGHT
+    UTILITY    |        (origin 0,0,0)            |       UTILITY
+    RAIL       |                                  |       RAIL
+               |__________________________________|
+                \                                /
+                 \      SHELF (below sightline) /
+                  \   agent status, quick tools/
+                   \_________________________ /
+```
+
+## Four Zones
+
+| 区域 | 深度范围 | 内容 | 透明度 |
+|------|---------|------|--------|
+| **Overview Canopy**（天幕） | 2.5–4.0m | 管线拓扑 + 健康热力图 | 40–70% |
+| **Focus Arc**（聚焦弧） | 1.2–2.0m | 主节点图工作区 | 100% |
+| **Utility Rails**（工具轨） | 侧翼 | Agent 库、监控、日志 | 100% |
+| **Shelf**（置物架） | 0.8–1.0m | 运行/停止、撤销、快捷工具 | 100% |
+
+## Three-Layer Depth System
+
+| 层级 | 深度 | 内容 | 透明度 |
+|------|------|------|--------|
+| Foreground（前景） | 0.8–1.2m | 活跃面板、检测器、模态框 | 100% |
+| Midground（中景） | 1.2–2.5m | 节点图、连接线、工作区 | 100% |
+| Background（背景） | 2.5–5.0m | 概览地图、环境状态 | 40–70% |
+
+## Design Rationale
+
+- **120 度聚焦弧**覆盖人眼自然视野中心区域
+- **垂直分层**（天幕→聚焦→置物架）符合"最重要信息在视线中心，次要在下方"的直觉
+- **侧翼工具轨**让主工作区保持无遮挡
+- **深度层级**允许信息密度分层——背景展示概览，前景展示细节
+
+## Connections
+
+- [[SpatialAIOps]] ← 界面架构层
+- [[Command-Theater]] ← 自身引用
+- [[4-Level-Semantic-Zoom]] ← 导航模式
diff --git a/wiki/concepts/Concierge-Services.md b/wiki/concepts/Concierge-Services.md
new file mode 100644
index 00000000..3c68d5b2
--- /dev/null
+++ b/wiki/concepts/Concierge-Services.md
@@ -0,0 +1,66 @@
+---
+title: "Concierge Services"
+type: concept
+tags: []
+sources:
+  - hospitality-guest-services
+last_updated: 2026-05-02
+---
+
+## Definition
+Concierge Services（礼宾服务）是酒店及高端款待业中，为宾客提供本地知识、预订协调和个性化安排的专业服务职能。礼宾服务的核心价值在于：识别宾客未表达的需求，通过主动推荐和精准执行创造惊喜体验。
+
+## Service Categories
+
+### Dining Reservations（餐饮预订）
+- 掌握当地TOP 10餐厅分类（Fine Dining/Casual/家庭/本地人推荐/景观氛围）
+- 实时了解：当前等候时间、预订可用性、饮食适配能力
+- 预订话术："请问您偏好什么菜系、价格范围和氛围？有什么特殊场合需要我们提及吗？"
+- 交通选项：每家餐厅的交通方式建议
+
+### Transportation（交通安排）
+- 酒店班车：时刻表和覆盖范围
+- 打车/网约车：本地最佳APP
+- 租车：最近门店位置和当前可用车型
+- 停车：自助vs.代客泊车，费用，营业时间
+- 机场接送：预订流程和价格
+
+### Local Activities & Attractions（本地活动与景点）
+保持实时更新的知识库：
+- 主要景点：开放时间、票价、预订要求
+- 当前本地活动：节日、音乐会、体育赛事
+- 户外活动：徒步、公园、水上活动
+- 家庭友好选项
+- 文化体验：博物馆、剧院、画廊
+- 购物：本地精品店、商场、市场
+
+### In-Property Services（酒店内服务）
+- Spa：护理项目、营业时间、预订流程
+- 健身中心：开放时间、设备、课程
+- 泳池：开放时间、规则、毛巾服务
+- 商务中心：开放时间、设备、打印
+- 客房服务：开放时间、点餐流程
+- 洗衣/干洗：流程和 turnaround 时间
+
+### Special Occasion Services（特殊场合服务）
+- 鲜花：通过[供应商]订购，需24小时通知
+- 香槟/葡萄酒：通过客房服务供应
+- 蛋糕：通过[供应商]订购，需24小时通知
+- 浪漫夜床布置：玫瑰+蜡烛，需[时间]前申请
+- 惊喜布置：与客房部协调
+
+## Key Principles
+- 主动推荐，而非被动应答：识别宾客需求在开口前
+- 知识必须实时更新：餐厅关门时间、景点开放日变化
+- 饮食限制是医疗问题：每次餐饮预订必须记录
+
+## Connections
+- [[Hospitality Guest Services]] ← 礼宾服务是宾客服务 Agent 住店阶段的核心交付物
+- [[Guest Journey]] ← 礼宾服务贯穿住店(In-Stay)阶段
+- [[Food Allergy]] ← 礼宾服务中餐饮预订必须强制处理饮食限制
+
+## Aliases
+- 礼宾服务
+- Concierge
+- Guest Services
+- Hotel Concierge
diff --git a/wiki/concepts/ConnectionPooling.md b/wiki/concepts/ConnectionPooling.md
new file mode 100644
index 00000000..ac2daf84
--- /dev/null
+++ b/wiki/concepts/ConnectionPooling.md
@@ -0,0 +1,46 @@
+---
+title: "Connection Pooling"
+type: concept
+tags: [database, connection-pool, postgresql, supabase, performance, infrastructure]
+last_updated: 2026-05-01
+---
+
+# Connection Pooling
+
+## Definition
+
+数据库连接池是一种在应用程序和数据库服务器之间维护一组持久连接的技术，避免每次请求都创建新连接，从而防止连接耗尽、提升响应速度。
+
+## Why It Matters
+
+- 数据库连接是稀缺资源（PostgreSQL 默认 max_connections = 100）
+- 无连接池时：高并发下连接数爆炸 → OOM → 服务崩溃
+- 无连接池时：每次请求建立 TCP + 认证开销（~20-50ms 延迟）
+
+## Key Tools
+
+| 工具 | 说明 |
+|------|------|
+| **PgBouncer** | 轻量级 PostgreSQL 连接池，支持事务模式和会话模式 |
+| **Supabase Pooler** | Supabase 内置连接池，自动管理事务模式连接 |
+| **PlanetScale** | 内置连接池，无服务器架构 |
+| **PgBouncer 事务模式** | 连接归还池复用，适合 serverless |
+| **PgBouncer 会话模式** | 保持长连接，适合需要 SET session.* 的场景 |
+
+## Supabase 连接池示例
+
+```typescript
+// Supabase 事务模式（Serverless 推荐）
+const pooledUrl = process.env.DATABASE_URL?.replace(
+  '5432',  // 标准端口
+  '6543'   // 事务模式端口
+);
+```
+
+## Source
+- [[engineering-database-optimizer]]
+
+## Connections
+- [[engineering-backend-architect]] — 架构设计时必须考虑连接池
+- [[engineering-sre]] — 连接池配置是 SRE 容量规划的关键
+- [[engineering-database-optimizer]] — 核心关注点之一
diff --git a/wiki/concepts/Content-Operations.md b/wiki/concepts/Content-Operations.md
new file mode 100644
index 00000000..b0a1e9ee
--- /dev/null
+++ b/wiki/concepts/Content-Operations.md
@@ -0,0 +1,48 @@
+---
+title: "内容运营体系（Content Operations for Proposals）"
+type: concept
+tags: [sales, content, operations]
+sources: [sales-proposal-strategist]
+last_updated: 2026-04-29
+---
+
+## Definition
+
+内容运营体系（Content Operations）是提案内容资产的管理方法论，核心变革是：**按赢主题（而非按提案章节）组织可复用内容库**，从而加速未来提案撰写并保持叙事一致性。
+
+## 核心原则
+
+1. **按主题组织**：每个内容块归属于一个或多个赢主题，而非某个提案章节
+2. **主题覆盖率追踪**：每个提案章节必须有 ≥1 个赢主题覆盖
+3. **证据密度要求**：每个内容块必须有可引用证据（指标/案例/方法论细节）
+
+## 收益
+
+| 传统方式 | 内容运营方式 |
+|----------|--------------|
+| 每份提案从零写 | 调用主题库中已有内容 |
+| 主题在不同章节中自相矛盾 | 主题由中心库驱动，一致性强 |
+| 模板化内容难以消除 | 内容按主题标记，可识别并替换通用内容 |
+| 经验随人员流失 | 知识沉淀在主题库中 |
+
+## 模板检测与消除
+
+识别模板化内容的信号：
+- 将买家名称替换后内容完全不变
+- "Robust," "cutting-edge," "best-in-class," "world-class" 等空洞形容词
+- 任何可以直接卖给竞争对手的内容
+
+## 与赢主题的关系
+
+内容运营体系是赢主题的后勤保障：
+- 赢主题定义"说什么"
+- 内容运营定义"如何组织、存储和复用"
+
+## Related Concepts
+
+- [[Win Theme]]：内容运营体系的核心组织轴
+- [[三幕式提案叙事]]：内容在叙事中的布局框架
+
+## Sources
+
+- [[sales-proposal-strategist]]
diff --git a/wiki/concepts/Context-Anxiety.md b/wiki/concepts/Context-Anxiety.md
new file mode 100644
index 00000000..52676692
--- /dev/null
+++ b/wiki/concepts/Context-Anxiety.md
@@ -0,0 +1,47 @@
+---
+title: "Context Anxiety"
+type: concept
+tags:
+  - "agentic-ai"
+  - "context-window"
+  - "failure-mode"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+Context Anxiety——当 LLM 的 context window 使用率超过约 70% 容量，或延迟升高时，模型表现出"仓促"行为的现象：跳过步骤、过早完成任务或过早宣告成功。
+
+## Mechanism
+- Context window 是模型的唯一记忆空间
+- 当感知到"墙壁在逼近"（token 限制），模型开始优先"快速完成"而非"正确完成"
+- 这不是模型能力问题，而是 context 容量压力的系统性反应
+
+## Detection
+- 监控 `tokens_used / max_context > 0.7` 阈值（需按模型和工作负载调优）
+- 延迟 spikes 也是触发信号
+
+## Solution: Context Reset
+当 Context Anxiety 触发时，Harness 执行程序化 Context Reset：
+1. `save_state_to_disk(state)` — 完整项目状态写入持久存储
+2. `terminate_current_instance()` — 终止当前 LLM 实例
+3. `launch_fresh_agent(state)` — 启动全新 Agent，从保存状态恢复
+
+关键代码：
+```python
+if (tokens_used / max_context) > 0.7:
+    save_state_to_disk(state)
+    terminate_current_instance()
+    launch_fresh_agent(state)
+```
+
+## Note on In-Place Summarization
+原地摘要（in-place summarization）不够——它仍然让模型在杂乱、退化的 context 上操作。Context Reset 给予模型干净的处理空间。
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
+
+## See Also
+- [[Context-Reset]] — 具体实现机制
+- [[7-Layer-Harness-Stack]] — 第 5 层 Memory & State 和第 7 层 Constraints & Recovery 中处理此问题
diff --git a/wiki/concepts/Context-Reset.md b/wiki/concepts/Context-Reset.md
new file mode 100644
index 00000000..7bb17c69
--- /dev/null
+++ b/wiki/concepts/Context-Reset.md
@@ -0,0 +1,41 @@
+---
+title: "Context Reset"
+type: concept
+tags:
+  - "agentic-ai"
+  - "context-window"
+  - "recovery"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+Context Reset——当 [[Context-Anxiety]] 触发时，Harness 将当前 Agent 状态保存至磁盘、终止实例、启动全新 Agent 的程序化操作，用于解决长周期任务超出单次 context window 的问题。
+
+## Trigger Condition
+```python
+if (tokens_used / max_context) > 0.7:  # 阈值需按模型调优
+    trigger_context_reset()
+```
+
+## Procedure
+1. **Save state**: 完整项目状态写入持久存储（磁盘文件）
+2. **Terminate**: 终止当前 LLM 实例
+3. **Launch fresh**: 启动全新 Agent，加载保存状态
+4. **Orient**: 新 Agent 读取状态、定位自身、继续工作
+
+## Why Not In-Place Summarization?
+原地摘要（summarize → keep in same context）仍让模型在嘈杂、退化的上下文中操作。Context Reset 提供完全干净的上下文窗口——代价更高，但可靠性显著提升，适用于超长周期任务。
+
+## Trade-off
+- **In-place summarization**: 便宜，但 context 仍嘈杂
+- **Context Reset**: 昂贵（需重新加载状态），但可靠性高
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
+
+## See Also
+- [[Context-Anxiety]] — 触发条件
+- [[State-Externalization]] — 持久化状态文件格式
+- [[7-Layer-Harness-Stack]] — 第 7 层 Constraints & Recovery 的核心机制
diff --git a/wiki/concepts/Continuous-Dev-QA-Loop.md b/wiki/concepts/Continuous-Dev-QA-Loop.md
new file mode 100644
index 00000000..872f11d9
--- /dev/null
+++ b/wiki/concepts/Continuous-Dev-QA-Loop.md
@@ -0,0 +1,32 @@
+---
+title: "Continuous-Dev-QA-Loop"
+type: concept
+tags: []
+sources: [agents-orchestrator]
+last_updated: 2026-05-29
+---
+
+## Definition
+**Continuous Dev-QA Loop**（持续开发质量循环）是 [[AgentsOrchestrator]] Phase 3 的核心机制——开发与 QA 交替进行，每个开发交付物立即经过 QA 验证，形成快速反馈闭环。
+
+## Relationship to [[Dev-QA-Loop]]
+- [[Dev-QA-Loop]] is the specific implementation of this concept within the AgentsOrchestrator pipeline
+- Continuous Dev-QA Loop is the broader principle: rapid feedback between development and quality assurance
+
+## Core Principle
+> "No shortcuts: Every task must pass QA validation."
+
+## Loop Characteristics
+- **Continuous**: No waiting until end-of-project QA — validation happens after each task
+- **Fast feedback**: Developer receives specific feedback immediately after implementation
+- **Evidence-based**: QA requires visual/screenshot proof, not self-reported completion
+- **Iterative**: Loop continues until PASS or max retries reached
+
+## Benefits
+- Issues caught early before propagating to downstream tasks
+- Developer receives specific, actionable feedback
+- Quality gates prevent broken functionality from advancing
+- Reduced final integration issues due to continuous validation
+
+## Sources
+- [[agents-orchestrator]]
diff --git a/wiki/concepts/ControllingIdea.md b/wiki/concepts/ControllingIdea.md
new file mode 100644
index 00000000..8be7426b
--- /dev/null
+++ b/wiki/concepts/ControllingIdea.md
@@ -0,0 +1,36 @@
+---
+title: "Controlling Idea"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Controlling Idea
+- 核心主题
+- 主题性论点
+
+## Overview
+Controlling Idea 是 [[Robert McKee]] 在其著作《故事》中提出的核心概念，定义为"故事对人性的论点"——它通过叙事中所有选择（情节、角色、场景、语言）来传达作者对人类经验的理解。
+
+## Structure
+Controlling Idea = **主题性价值（Thematic Value）** × **因果关系（Causal Connection）**
+
+### Examples
+| Controlling Idea | Thematic Value | Causal Connection |
+|-----------------|---------------|-------------------|
+| "骄傲导致毁灭" | 骄傲 | 导致 |
+| "勇气可以通过小事培养" | 勇气 | 通过...培养 |
+| "真正的力量来自放下控制" | 力量 | 通过放下获得 |
+
+## Application
+[[Academic Narratologist]] 的核心分析维度之一：
+- **诊断工具**：识别故事"真正在说什么"，而非表面情节
+- **评估标准**：所有情节选择是否与 Controlling Idea 一致
+- **主题一致性检查**：跨多条情节线验证主题表达是否连贯
+
+## Relationship to Other Concepts
+- [[Fabula-vs-Sjuzhet]]：Controlling Idea 是 sjuzhet（讲述层）背后的 fabula（故事层）意义
+- [[Character-Arc]]：角色的 transformation 必须与 Controlling Idea 一致
+- [[Three-Act-Structure]]：Act III 的 Resolution 必须完成主题性论点的建构
diff --git a/wiki/concepts/Conversation-State-Persistence.md b/wiki/concepts/Conversation-State-Persistence.md
new file mode 100644
index 00000000..5e906bf2
--- /dev/null
+++ b/wiki/concepts/Conversation-State-Persistence.md
@@ -0,0 +1,27 @@
+---
+title: "Conversation-State-Persistence"
+type: concept
+tags: []
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Definition
+Conversation State Persistence 是服务端存储完整对话历史（含工具调用）的机制，使客户端无需自行管理上下文。
+
+## Implementation in Hermes Agent
+通过 `/v1/responses` API 实现有状态会话：
+- **无状态**：`/v1/chat/completions` 每次请求需传递完整对话历史
+- **有状态**：`/v1/responses` 支持 `previous_response_id` 链式调用，服务端保留完整上下文（含工具调用）
+
+## Key Benefits
+- 客户端无需存储和发送完整对话历史
+- 服务端自动维护工具调用记录
+- 支持多轮对话中的上下文连续性
+
+## Use Case
+长对话场景下，使用 Responses API 可以大幅减少客户端代码复杂度。
+
+## Related
+- [[ResponsesAPI]]
+- [[System-Prompt-Layering]]
diff --git a/wiki/concepts/Cost-As-Distributed-Systems-Bug.md b/wiki/concepts/Cost-As-Distributed-Systems-Bug.md
new file mode 100644
index 00000000..bc2ad9fb
--- /dev/null
+++ b/wiki/concepts/Cost-As-Distributed-Systems-Bug.md
@@ -0,0 +1,45 @@
+---
+title: "Cost As Distributed Systems Bug"
+type: concept
+tags: [sre, finops, observability, reliability, cost-optimization]
+last_updated: 2026-04-20
+---
+
+# Cost As Distributed Systems Bug
+
+"成本是分布式系统的 bug"——成本异常（cost explosion）不仅是财务问题，更是一种可靠性问题。
+
+## Core Thesis
+成本突然增加往往预示着系统即将发生故障。**成本突增应该被视为告警信号**，触发故障调查而非仅财务审查。
+
+## Why Cost Signals Matter
+1. **资源泄漏的指示器**：内存泄漏、连接池耗尽往往表现为成本逐步上升
+2. **异常流量的标志**：DDoS 或滥用可能导致成本爆炸
+3. **配置错误**：错误的资源配置可能导致资源过度使用
+4. **级联效应的前兆**：某个组件故障可能导致其他组件超负荷运转
+
+## Alerting Strategy
+```
+IF cost_increase > threshold:
+    ALERT("Cost anomaly detected - investigate system health")
+```
+
+将成本监控集成到 SRE 的告警体系中，而非仅作为 FinOps 的事后分析。
+
+## Key Principles
+- **Cost as Signal**：将成本指标视为系统健康的信号
+- **Proactive Monitoring**：在成本失控前设置告警
+- **Correlation Analysis**：将成本变化与其他系统指标关联
+
+## Relationship to FinOps
+FinOps 不仅是成本优化工具，也是 SRE 的可靠性工具。成本可观测性（Cost Observability）是现代 SRE 实践的重要组成部分。
+
+## Related Concepts
+- [[Cost-Optimization]]
+- [[Observability]]
+- [[FinOps]]
+- [[Distributed-Systems]]
+- [[Reliability]]
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/concepts/Counterfactual-Analysis.md b/wiki/concepts/Counterfactual-Analysis.md
new file mode 100644
index 00000000..0bf03e74
--- /dev/null
+++ b/wiki/concepts/Counterfactual-Analysis.md
@@ -0,0 +1,34 @@
+---
+title: "Counterfactual Analysis"
+type: concept
+tags: [historiography, methodology]
+sources: [academic-historian]
+last_updated: 2026-04-30
+---
+
+## Definition
+反事实推理（Counterfactual Analysis）是一种严谨的"假如"（what if）历史推演方法——设想历史在某个关键节点发生了不同的走向，并分析这种改变会导致什么样的后果。它是 Historian Agent 文档中明确列出的高级能力之一。
+
+## Key Features
+- **核心原则**：必须以历史偶然性理论（contingency theory）为基础，而非随意想象
+- **必须满足的条件**：
+  1. 反事实假设必须是"可想象的"（plausible）——基于已知历史条件
+  2. 必须追溯反事实链条的逻辑后果
+  3. 必须与相似历史案例进行类比验证
+  4. 必须诚实地承认推理的局限性
+- **代表学者**：内弗·弗格森（Niall Ferguson）、贾雷德·戴蒙德（Jared Diamond）《枪炮、病菌与钢铁》
+- **批评**：批评者认为反事实推理过于投机，无法证伪
+- **价值**：帮助理解历史的结构性约束与偶然性因素各自的权重
+
+## Relationship to Other Concepts
+- [[Longue-Duree]] ← 互补 ← [[Counterfactual-Analysis]]：长时段分析强调结构，反事实分析强调偶然性；两者共同帮助理解历史因果
+- [[Historiography]] ← 属于 ← [[Counterfactual-Analysis]]：反事实推理是历史编纂学中一种有争议但有价值的方法
+- [[academic-historian]] ← 高级能力 ← [[Counterfactual-Analysis]]：Historian Agent 的 Advanced Capabilities 明确包括 Counterfactual Analysis
+
+## Relationship to Source Pages
+- [[academic-historian]]：文档的"🚀 Advanced Capabilities"部分明确列出此能力
+
+## Aliases
+- 反事实推理
+- What-if Analysis
+- Alternative History
diff --git a/wiki/concepts/CrossPlatformPlanning.md b/wiki/concepts/CrossPlatformPlanning.md
new file mode 100644
index 00000000..7824064e
--- /dev/null
+++ b/wiki/concepts/CrossPlatformPlanning.md
@@ -0,0 +1,66 @@
+---
+title: "Cross-Platform Planning"
+type: concept
+tags: ["ppc", "multi-platform", "strategy", "google-ads", "amazon-ads", "paid-media"]
+sources: ["paid-media-ppc-strategist"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+跨平台规划（Cross-Platform Planning）是付费媒体策略中在 Google Ads、Microsoft Advertising、Amazon Ads 等多个广告平台之间协调预算分配、策略制定和效果衡量的系统性方法。核心理念：**避免平台间预算相互蚕食（cannibalization）**，通过统一的测量框架实现整体效率最优。
+
+## Three Major Platforms Compared
+
+| 维度 | Google Ads | Microsoft Advertising | Amazon Ads |
+|------|-----------|----------------------|-----------|
+| **用户意图** | 信息获取 → 购买 | 信息获取 → 购买（B2B更强） | 购买意图最强 |
+| **广告类型** | Search/Shop/PMax/Display/Video | Search/Shop/Audience | SP/SB/SD/DSP |
+| **量级** | 最大 | 较小但增长 | 电商专属 |
+| **CPC 水平** | 中高 | 较低 | 中等 |
+| **竞争密度** | 高 | 中低 | 中 |
+| **数据透明度** | 高 | 中 | 中 |
+
+## Budget Split Frameworks
+
+### Intent-Based Allocation
+```
+基于用户意图漏斗分配：
+- 品牌词：Google Brand（高保护）+ Amazon Brand（购买保护）
+- 竞品词：Google（截流）+ Microsoft（Bing 独家流量）
+- 产品词：Google + Amazon（不同意图阶段）
+- 漏斗上层：Google Display/Video + YouTube
+```
+
+### Platform-Specific Feature Exploitation
+- **Google**：Smart Bidding + Performance Max + Broad Match + AI
+- **Microsoft**：LinkedIn 受众定向（B2B）+ 更低 CPC + Google 迁移便利
+- **Amazon**：购买意图流量 + DSP + AMC 受众分析
+
+## Unified Measurement Approach
+
+### Attribution Challenges
+- **Last-click 归因偏差**：Amazon 通常在漏斗底部，导致 Google Display 贡献被低估
+- **Cross-device**：用户可能在手机研究、PC 搜索、线下购买
+- **Platform silos**：各平台独立追踪，缺乏统一视图
+
+### Measurement Solutions
+- **Google Analytics 4（GA4）**：跨平台归因（需 UTM + 各平台 API 集成）
+- **Amazon AMC（Amazon Marketing Cloud）**：亚马逊生态内的跨触点归因
+- **Incrementality Testing**：衡量各平台真实增量贡献
+- **Data-Driven Attribution**：ML-based 归因模型
+
+## Cannibalization Prevention
+
+| 症状 | 原因 | 解决方案 |
+|------|------|---------|
+| 跨平台 ROAS 均下降 | 关键词重叠，内部竞争 | 差异化关键词策略 |
+| 总转化量不变但成本上升 | 多平台分摊自然流量 | Incrementality 测试验证 |
+| 品牌词跨平台 CPC 上升 | 内部竞标 | 统一品牌词竞价策略 |
+
+## Connections
+- [[GoogleAds]]：跨平台策略的核心平台之一
+- [[MicrosoftAdvertising]]：Google 之外的搜索广告补充
+- [[AmazonAds]]：购买意图漏斗底部的专属平台
+- [[IncrementalityTesting]]：衡量跨平台真实增量贡献
+- [[BudgetPacing]]：跨平台预算分配是 pacing 的高级形式
diff --git a/wiki/concepts/Cultural-Authenticity.md b/wiki/concepts/Cultural-Authenticity.md
new file mode 100644
index 00000000..c4029611
--- /dev/null
+++ b/wiki/concepts/Cultural-Authenticity.md
@@ -0,0 +1,39 @@
+---
+title: "Cultural Authenticity"
+type: concept
+tags: []
+last_updated: 2026-05-15
+---
+
+## Definition
+
+Cultural Authenticity（文化真实性）——AI 生成内容中确保文化元素（建筑、服饰、符号、照明）准确反映目标文化真实生活现实的原则。文化真实性不是"代表性"的同义词——它要求更深层次的准确性：主体必须被正确锚定在其实际环境中。
+
+## Core Failures AI Models Exhibit
+
+1. **Architectural Inaccuracy**：不正确的建筑风格（东亚城市背景出现西式穹顶）
+2. **Lighting Bias**：照明预设适合浅肤色，不适合深肤色（hyper-saturated artificial lighting）
+3. **Gibberish Cultural Text**：非英语文字/符号被渲染为乱码或冒犯性字符
+4. **Exoticism Bias**：将文化背景"异域化"（将正常城市背景渲染为异国情调）
+5. **Hero-Symbol Composition**：文化符号（新月、佛像等）被放大为构图焦点而失去原本意义
+
+## Technical Counter-Measures
+
+Inclusive Visuals Specialist 的技术应对：
+
+- **显式环境锚定**："In a modern, sunlit architectural office in Nairobi, Kenya. The glass walls overlook the city skyline."
+- **否定性符号约束**："No text or symbols on whiteboards"
+- **正确照明定义**："The lighting is soft and directional, expertly graded to highlight the richness of her skin tone without washing out highlights."
+- **Intersectional Specificity**：文化真实性必须与 intersectionality 结合，不能脱离具体人物
+
+## Related Concepts
+
+- [[Intersectionality]]
+- [[Negative Prompting]]
+- [[Sociological Accuracy]]
+- [[Inclusive Visuals Specialist]]
+
+## Aliases
+
+- 文化准确性
+- 文化真实性检验
diff --git a/wiki/concepts/Cultural-Ecology.md b/wiki/concepts/Cultural-Ecology.md
new file mode 100644
index 00000000..c67ac612
--- /dev/null
+++ b/wiki/concepts/Cultural-Ecology.md
@@ -0,0 +1,25 @@
+---
+title: "Cultural Ecology"
+type: concept
+tags: ["anthropology", "ecology", "environment", "subsistence", "steward"]
+last_updated: 2026-04-25
+---
+
+## Definition
+文化生态学——研究**环境如何塑造文化**，以及**文化又如何反过来塑造和适应环境**的跨学科框架。强调物质条件（气候、地形、资源）对社会组织的约束作用，同时拒绝简单的地理/文化决定论。
+
+## Core Framework
+- **文化核心（Cultural Core）**：生计模式和与技术环境互动直接相关的社会制度
+- **多线进化（Multilinear Evolution）**：不同环境可能独立产生相似的适应方案
+- **生态系统**：人类群体与环境形成的动态适应系统，具有反馈回路
+- **Pigs and People**（Rappaport）：巴布亚新几内亚 Tsembaga 人的仪式性猪屠杀，是环境调节机制的文化表达
+
+## Key Thinkers
+- Julian Steward（文化生态学创始人）
+- Roy Rappaport（生态系统研究）
+- Marvin Harris（文化唯物论）
+
+## Connections
+- [[Anthropologist-Agent]] ← uses_framework ← [[Cultural-Ecology]]
+- [[Functionalism]] ← related_to ← [[Cultural-Ecology]]
+- [[Polanyi-Exchange]] ← influenced_by ← [[Cultural-Ecology]]
diff --git a/wiki/concepts/Cultural-Intelligence.md b/wiki/concepts/Cultural-Intelligence.md
new file mode 100644
index 00000000..8b55bfe7
--- /dev/null
+++ b/wiki/concepts/Cultural-Intelligence.md
@@ -0,0 +1,36 @@
+---
+title: "Cultural Intelligence"
+type: concept
+tags: [cultural-intelligence, cross-cultural, internationalization, ux-design]
+sources: [specialized-cultural-intelligence-strategist]
+last_updated: 2026-05-29
+---
+
+## Definition
+文化智能（Cultural Intelligence, CQ）——一种跨文化适应能力，使个人或系统能够在不同文化背景下有效运作、沟通和建立信任。区别于 IQ（认知智能）和 EQ（情绪智能），CQ 专门衡量文化适应性，包括：对文化差异的认知理解（Cognitive CQ）、在跨文化情境中的行为适应能力（Physical CQ）、对文化情境的内在动机和信心（Metacognitive CQ）。
+
+## In the Context of AI Agents
+在 AI Agent 设计中，CQ 体现为：
+- 检测和消除软件开发中的隐性排斥（Invisible Exclusion）
+- 在生成内容前自主研究特定文化的尊重和赋权表征标准
+- 理解不同文化对颜色、图标、数字、日期格式的差异化语义
+
+## Core Dimensions
+- **认知 CQ（Cognitive CQ）**：文化知识——理解不同文化的价值观、习俗、社会规范和商业惯例
+- **元认知 CQ（Metacognitive CQ）**：文化意识——在跨文化交流中保持对文化假设的觉察和反思
+- **动机 CQ（Motivational CQ）**：文化好奇——主动学习和适应不同文化的内在驱动力
+- **行为 CQ（Behavioral CQ）**：文化适应——在不同文化情境中灵活调整语言、行为和沟通方式
+
+## Related Concepts
+- [[Architectural Empathy]]（结构性同理心）：CQ 在软件设计中的实践框架
+- [[Invisible-Exclusion]]（隐性排斥）：CQ 所诊断的核心问题类型
+- [[Global-First-Architecture]]（全局优先架构）：CQ 在技术架构中的实施方法
+- [[Cultural Humility]]（文化谦逊）：CQ 的基础原则——承认知识不完整，持续学习
+
+## Key Distinction: CQ vs. Cultural Competence
+| 维度 | 文化能力（Cultural Competence） | 文化智能（Cultural Intelligence） |
+|------|------------------------------|-------------------------------|
+| 假设 | 可以达到"文化熟练"终点 | 强调持续学习和适应 |
+| 重点 | 知识和技能的集合 | 动态的、可发展的能力 |
+| 态度 | 倾向于"了解"其他文化 | 承认"不了解"并保持好奇 |
+| 来源 | 西方学术框架 | 跨文化心理学（ Earley & Ang, 2003） |
diff --git a/wiki/concepts/Curiosity-Driven-Bug-Discovery.md b/wiki/concepts/Curiosity-Driven-Bug-Discovery.md
new file mode 100644
index 00000000..c26fe8e9
--- /dev/null
+++ b/wiki/concepts/Curiosity-Driven-Bug-Discovery.md
@@ -0,0 +1,76 @@
+---
+title: "Curiosity-Driven Bug Discovery"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+
+通过主动追问系统假设（而非被动等待测试失败）来发现高危 Bug 的方法论——将"未言明的假设"显式化，并在它们导致故障前将其消灭。
+
+## Overview
+
+大多数生产环境中的严重 Bug 并非来自代码错误，而是来自未被显式记录的**假设**。这些假设在代码编写时被默许存在，随着系统演进逐渐失效，最终在生产环境中引发故障。Curiosity-Driven Bug Discovery 是一套系统化的追问框架，在工作流设计阶段就将这些假设显式化。
+
+## Four Question Dimensions
+
+### 1. 数据持久化假设（Data Persistence Assumptions）
+- 数据存储在哪里？存储是持久化还是临时性的？
+- 重启后数据是否仍然存在？
+- 数据在什么条件下被清理？
+
+**追问模板**：
+> "Where is this data stored? Is the storage durable or ephemeral? What happens on restart?"
+
+### 2. 网络连通性假设（Network Connectivity Assumptions）
+- Service A 能否实际到达 Service B？
+- 它们在同一个网络段吗？是否有防火墙规则？
+- 服务之间是否存在 DNS 解析延迟？
+
+**追问模板**：
+> "Can service A actually reach service B? Are they on the same network? Is there a firewall rule?"
+
+### 3. 时序假设（Ordering/Timing Assumptions）
+- 当前步骤假设前一个步骤已完成——但它们是并行运行的吗？
+- 什么机制确保时序正确？（健康检查？轮询？事件？锁？）
+- 超时值是否合理？
+
+**追问模板**：
+> "This step assumes the previous step completed — but they run in parallel. What ensures ordering?"
+
+### 4. 认证授权假设（Authentication/Authorization Assumptions）
+- 此端点在启动时被调用——但调用方是否经过身份验证？
+- 什么防止未授权访问？
+- 凭证在何时何地可用？
+
+**追问模板**：
+> "This endpoint is called during setup — but is the caller authenticated? What prevents unauthorized access?"
+
+## Application in Workflow Architect
+
+在 `Discovery Audit Checklist` 中，每发现一个隐式工作流，Workflow Architect 必须主动用四个追问维度扫描一遍。发现的高危假设记录在 `Reality Checker Findings` 表中，标注 severity 为 Critical 或 High。
+
+## Why "Curiosity-Driven"
+
+"Curiosity-driven" 强调这是**主动探索**而非**被动验证**：
+- **被动验证**：已有 bug 报告 → 查找原因
+- **主动探索**：无 bug 报告 → 追问假设 → 发现潜在 bug
+
+这套方法论的核心洞察：**最危险的 bug 是那些从未有人怀疑其存在的假设**。
+
+## Success Criteria
+
+- 每个工作流的 Assumptions 表都被填满（非空白）
+- 假设表中的假设在后续 Sprint 中被逐一验证或修正
+- 好奇心驱动发现的 bug 数量 ≥ 被动测试发现的 bug 数量
+
+## Related Concepts
+- [[Workflow-Tree-Spec]]：假设记录的载体（Assumptions 节）
+- [[Reality-Checker]]：验证假设真实性的 Agent
+- [[Discovery-Audit]]：发现隐式工作流的入口
+
+## Aliases
+- Assumption Mining
+- Hypothesis-First Bug Discovery
+- Proactive Assumption Surfacing
diff --git a/wiki/concepts/Data-Contract.md b/wiki/concepts/Data-Contract.md
new file mode 100644
index 00000000..0fd640ee
--- /dev/null
+++ b/wiki/concepts/Data-Contract.md
@@ -0,0 +1,61 @@
+---
+title: "Data Contract"
+type: concept
+tags: [data-engineering, data-quality, schema, SLA]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+Data Contract（数据契约）是数据生产者和消费者之间的明确协议，定义了数据的预期 schema、数据类型、SLA、所有权和消费方。数据契约是 Medallion Architecture 中 Silver→Gold 层质量保证的核心机制。
+
+## Components
+
+### Schema Contract
+- 字段名、类型、约束（not_null、unique、foreign key）
+- Schema 演化规则：允许添加 nullable 字段，禁止删除或修改类型
+- `mergeSchema=true`：允许 schema 演进，但触发告警而非自动污染下游
+
+### SLA Contract
+- 刷新频率（如"每 15 分钟刷新一次"）
+- 数据新鲜度阈值（如"1 小时内必须有新数据"）
+- 可用性承诺（如"Gold 层 99.9% 可用性"）
+
+### Ownership Contract
+- 数据所有者（Data Owner）
+- 数据消费者（Data Consumer）
+- 支持联系人（Support Contact）
+
+## Enforcement
+
+### dbt Contract Enforcement
+```yaml
+models:
+  - name: silver_orders
+    config:
+      contract:
+        enforced: true  # 强制 schema 契约，类型不匹配则构建失败
+    columns:
+      - name: order_id
+        data_type: string
+        constraints:
+          - type: not_null
+          - type: unique
+```
+
+### Great Expectations（数据质量验证）
+- 行级数据质量评分必须在 Gold 层附加
+- Null 率告警阈值（如 `customer_id` null 率从 0.1% 跳至 4.2% → 触发 PagerDuty）
+
+## Key Rules
+
+- **Schema 漂移必须告警**：不得静默损坏下游数据
+- **Null 处理必须显式**：不得隐式将 null 传播到 Gold 层
+- **发布前必须与消费者确认**：数据契约签署后才能部署 Gold 层管道
+
+## Related Concepts
+- [[Medallion Architecture]]
+- [[Great Expectations]]（数据质量验证工具）
+- [[Data Lineage]]
+- [[SCD Type 2]]
diff --git a/wiki/concepts/Dataview.md b/wiki/concepts/Dataview.md
new file mode 100644
index 00000000..8cc65476
--- /dev/null
+++ b/wiki/concepts/Dataview.md
@@ -0,0 +1,35 @@
+---
+title: "Dataview"
+type: concept
+tags: [tool, obsidian, plugin, query]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- Obsidian Dataview 插件
+- DataviewJS
+
+## Definition
+Obsidian 的社区插件，对页面 YAML frontmatter 做数据库式查询，自动生成动态表格和列表。是 LLM Wiki 的可选增强工具。
+
+## LLM Wiki Usage
+让 AI 在每个 Wiki 页面的 frontmatter 里写上结构化元数据（如 `type`、`date`、`tags`、`source_count`），然后用 Dataview 查询生成动态报表。
+
+## Example Query
+````markdown
+```dataview
+TABLE title, date, tags
+FROM "wiki/sources"
+SORT date DESC
+```
+````
+
+## Practical Value
+- 页面少时价值有限，Wiki 规模大时（数百页面）报表价值显著
+- 老张（[[laozhang2579]]）观点："多到一定程度或者想用元数据查询方式习惯的可以考虑，我是直接用索引文件配合 Claude 的文件检索"
+- 安装：设置 → 第三方插件 → 社区插件市场 → 搜索 "Dataview" → 安装并启用
+
+## Connections
+- [[Dataview]] ← 可选增强 → [[LLM Wiki]]
+- [[Dataview]] ← 插件 → [[Obsidian]]
diff --git a/wiki/concepts/Default-Bias.md b/wiki/concepts/Default-Bias.md
index 3724c0d2..740e9c21 100644
--- a/wiki/concepts/Default-Bias.md
+++ b/wiki/concepts/Default-Bias.md
@@ -1,28 +1,47 @@
----
-title: "Default Bias"
-type: concept
-tags: [behavioral-psychology, ux, nudge, persuasion]
-last_updated: 2026-04-20
----
-
-## Definition
-默认偏差（Default Bias）指用户倾向于接受预置选项而不主动修改的行为心理倾向。在软件交互中，通过预设默认行为或预填内容，降低用户决策摩擦，提高行动完成率。
-
-## Mechanism
-1. **预填内容**：系统自动生成回复/草稿，用户只需确认或修改
-2. **预选选项**：智能推荐最佳选项，用户一键接受
-3. **默认同意**：预勾选最优行为选项，用户需主动取消而非选择
-
-## Applications
-- 邮件回复草稿自动生成，一键发送
-- 表单字段智能预填
-- 隐私设置默认最优选项
-- 通知频率默认静音，用户按需开启
-
-## Related Concepts
-- [[Nudge Theory]]：推力理论的组成部分
-- [[Cognitive Load Reduction]]：通过减少决策选项降低认知负荷
-- [[Gamification]]：可与游戏化结合增强默认选项接受率
-
-## Source
-- [[Behavioral Nudge Engine]] — 核心应用场景
+---
+title: "Default Bias"
+type: concept
+tags: []
+sources: ["product-behavioral-nudge-engine"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Default Bias（默认偏见）是一种心理现象：人们倾向于接受预设选项，即使提供退出选项也有很高概率保持默认状态。在软件交互设计中，通过预先填充行动草案并以「确认/修改」框架呈现，可大幅降低用户的决策摩擦和行动阻力。
+
+## Mechanism
+
+- **核心策略**：不要问用户「要不要做」，而是问「这样做好吗」
+- **行为公式**：「已起草 + 一键确认」= 最小阻力路径
+- **典型应用**：邮件回复草稿、通知设置、文档模板确认、支付流程
+- **道德边界**：必须提供真实的「opt-out」退出选项，不可隐藏或误导
+
+## Example
+
+> "I've drafted a thank-you reply for this 5-star review. Should I send it, or do you want to edit?"
+
+这个示例展示：系统不仅起草了回复，还主动推进了决策——用户只需点击「发送」即可完成，否则才需要介入修改。
+
+## Why It Works
+
+1. **减少认知负担**：用户无需从零开始组织语言
+2. **消除启动摩擦**：最大的阻力在于「开始」，草案消除了这一步
+3. **利用惰性**：在低介入成本时，用户倾向于保持默认状态
+4. **正向锚定**：用户面对自己的内容比面对空白更有动力编辑
+
+## Related Concepts
+
+- [[Cognitive Load Reduction]] — 默认偏见是降低认知负荷的核心手段
+- [[Nudge Theory]] — 默认选项是 Nudge 的经典应用
+- [[Friction Reduction]] — 减少用户行动阻力的更广泛策略
+
+## Risks & Ethical Considerations
+
+- 过度使用可能引发用户「被操控」感，损害信任
+- 必须提供真实退出选项，不可暗设陷阱
+- 高风险决策（财务、法律）场景应谨慎使用
+
+## Connections
+
+- [[Behavioral Nudge Engine]] — 核心应用场景：任务推进、通知确认、内容发布
diff --git a/wiki/concepts/Defect-Prediction.md b/wiki/concepts/Defect-Prediction.md
new file mode 100644
index 00000000..c18f28c2
--- /dev/null
+++ b/wiki/concepts/Defect-Prediction.md
@@ -0,0 +1,51 @@
+---
+title: "Defect Prediction"
+type: concept
+tags: [testing, machine-learning, quality]
+sources: [testing-test-results-analyzer]
+last_updated: 2026-04-28
+---
+
+## Definition
+
+缺陷预测——使用机器学习模型基于代码指标和历史缺陷数据，预测哪些代码区域最可能包含缺陷，指导测试资源的定向投入。
+
+## Approach
+
+### Feature Engineering (from TestResultsAnalyzer)
+
+```python
+from sklearn.ensemble import RandomForestClassifier
+from sklearn.model_selection import train_test_split
+
+# 特征：代码指标
+features = extract_code_metrics()        # 圈复杂度、代码行数、变更频率等
+historical_defects = load_historical_defect_data()  # 历史缺陷标签
+
+# 训练/测试分割
+X_train, X_test, y_train, y_test = train_test_split(
+    features, historical_defects, test_size=0.2, random_state=42
+)
+
+# Random Forest 分类器
+model = RandomForestClassifier(n_estimators=100, random_state=42)
+model.fit(X_train, y_train)
+
+# 预测 + 置信度 + 特征重要性
+predictions = model.predict_proba(features)
+feature_importance = model.feature_importances_
+accuracy = model.score(X_test, y_test)
+```
+
+### Key Metrics
+
+- **Prediction Accuracy**：模型在测试集上的准确率，目标 ≥ 85%。
+- **Feature Importance**：哪些代码指标（圈复杂度、变更频率、代码行数等）对缺陷预测最有预测力。
+- **Confidence Score**：每个预测结果附带置信度评分。
+
+## Connections
+
+- [[Statistical-Analysis]]：模型验证需统计显著性检验。
+- [[Test-Coverage-Analysis]]：预测的高风险区域优先增加测试覆盖率。
+- [[Release-Readiness-Assessment]]：缺陷预测结果纳入整体发布就绪度评估。
+- [[Quality-Metrics]]：缺陷密度是预测模型的目标变量。
diff --git a/wiki/concepts/Dev-QA-Loop.md b/wiki/concepts/Dev-QA-Loop.md
new file mode 100644
index 00000000..3cb0311e
--- /dev/null
+++ b/wiki/concepts/Dev-QA-Loop.md
@@ -0,0 +1,48 @@
+---
+title: "Dev↔QA Loop"
+type: concept
+tags: [multi-agent, quality, devops, nexus]
+sources: [executive-brief, quickstart, workflow-startup-mvp]
+last_updated: 2026-05-01
+aliases:
+  - Dev QA Loop
+  - Build-Test Loop
+  - Dev-Test-Retry Loop
+---
+
+## Definition
+
+Dev↔QA 循环（Dev↔QA Loop）—— 构建→测试→通过/失败→重试的持续质量循环，最多允许 3 次迭代；FAIL 时触发修复重试，PASS 时推进到下一阶段。
+
+## Mechanism
+
+```
+开发 Agent 交付实现
+    ↓
+QA Agent 执行质量验证
+    ↓
+┌──────────────────────────┐
+│ PASS?                    │
+├──────────┬───────────────┤
+│ 是        │ 否            │
+│ ↓        │ ↓             │
+│ 推进下一阶段  │ 进入修复循环        │
+│          │ (重试 N/3)     │
+└──────────┴───────────────┘
+```
+
+## Quantified Impact
+
+- **集成前缺陷捕获率**：95% —— 大部分缺陷在 Dev↔QA 循环中被捕获，而非等到集成阶段
+- **Phase 4 硬化时间减少**：50% —— 持续质量循环优于端到端测试
+- **最大重试次数**：3 次 —— 超过 3 次 FAIL 触发升级/上报机制
+
+## Role in NEXUS
+
+Dev↔QA 循环是 NEXUS Phase 3 Build 阶段的核心机制，也是 NEXUS 的四大核心原则之一（Quality Gates / Dev↔QA Loop / Handoffs / Evidence Over Claims）。
+
+## Related Concepts
+
+- [[Quality Gate]]：Dev↔QA 循环是质量门控体系的具体实现机制
+- [[Reality Checker]]：Dev↔QA 循环 PASS 后，最终质量权威由 Reality Checker 确认
+- [[Evidence Over Claims]]：循环中的验证必须基于证据而非口头断言
diff --git a/wiki/concepts/Discrimination-Metrics.md b/wiki/concepts/Discrimination-Metrics.md
index 8caf46b6..a5338d78 100644
--- a/wiki/concepts/Discrimination-Metrics.md
+++ b/wiki/concepts/Discrimination-Metrics.md
@@ -1,76 +1,78 @@
----
-title: "Discrimination Metrics"
-type: concept
-tags: [model-evaluation, classification-metrics, model-performance]
-last_updated: 2026-04-25
----
-
-## Definition
-
-判别能力指标（Discrimination Metrics）衡量模型区分正例与负例的能力——给定一个随机正例和一个随机负例，模型有多大概率给正例更高的分数。区别于校准（衡量概率准确性），判别度衡量排序正确性。
-
-## Core Metrics
-
-### AUC (Area Under the ROC Curve)
-- ROC 曲线下面积，取值 [0.5, 1.0]
-- 0.5 = 随机猜测，1.0 = 完美区分
-- 解读：给定随机正例和随机负例，有 AUC 概率给正例更高分数
-- **优势**：阈值无关，对类别不平衡相对稳健
-
-### Gini Coefficient
-- $Gini = 2 \times AUC - 1$
-- 取值 [0, 1.0]，与 AUC 线性等价
-- 金融行业常用（信用卡评分、信贷风控）
-- 监管报告标准指标
-
-### KS Statistic (Kolmogorov-Smirnov)
-- 两个累积分布函数（正例 vs 负例）之间的最大垂直距离
-- $KS = \max_t |F_{pos}(t) - F_{neg}(t)|$
-- 取值 [0, 1.0]；KS > 0.2 通常认为有区分能力
-- **优势**：不依赖阈值，提供最佳分割点位置信息
-
-### Additional Metrics
-| Metric | Formula | 适用场景 |
-|--------|---------|---------|
-| F1 Score | $2 \times \frac{precision \times recall}{precision + recall}$ | 类别不平衡 |
-| RMSE | $\sqrt{\frac{1}{n}\sum(y_i - \hat{y}_i)^2}$ | 回归模型 |
-| Log Loss | $-\frac{1}{N}\sum[y_i \log p_i + (1-y_i)\log(1-p_i)]$ | 概率质量 |
-
-## Usage
-
-```python
-from sklearn.metrics import roc_auc_score, f1_score
-from scipy.stats import ks_2samp
-
-def discrimination_report(y_true, y_score):
-    auc = roc_auc_score(y_true, y_score)
-    gini = 2 * auc - 1
-    ks_stat, ks_pval = ks_2samp(y_score[y_true == 1], y_score[y_true == 0])
-    return {
-        "AUC": round(auc, 4),
-        "Gini": round(gini, 4),
-        "KS": round(ks_stat, 4),
-        "KS_pvalue": round(ks_pval, 6),
-    }
-```
-
-## Model QA 中的应用
-
-Model QA Specialist 执行以下判别能力审计：
-1. **全数据切片分析**：在 Train/Validation/Test/OOT 四个数据切片上分别计算 AUC/Gini/KS
-2. **子群体性能**：在性别/年龄/地区等受保护属性上分别测试，发现公平性隐患
-3. **时间稳定性**：跨 OOT 窗口追踪 AUC/Gini 趋势，识别性能衰减
-4. **冠军-挑战者对比**：Proposed model vs. incumbent production model，量化相对提升
-
-## Relationship
-
-- **被依赖** [[Calibration-Testing]]：先确认判别能力（KS > 0.2, AUC > 0.7），再测试校准
-- **依赖** [[Population-Stability-Index]]：PSI 监控输入稳定性，判别指标监控输出健康度
-- **依赖** [[SHAP]]：判别指标提供"是否好"的答案，SHAP 解释"为什么"
-- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的核心性能评估步骤
-
-## Key Insights
-
-- **判别度 vs 校准**：高 AUC 模型仍可能在特定概率区间严重校准偏差；两者必须同时评估
-- **KS vs AUC**：KS 对尾部区分更敏感（抓坏人），AUC 对整体排序更均衡
-- **监管门槛**：金融风控通常要求 Gini > 0.4（相当于 AUC > 0.7）方可上线
+---
+title: "Discrimination Metrics"
+type: concept
+tags: [model-evaluation, classification-metrics, model-performance]
+sources:
+  - specialized-model-qa
+last_updated: 2026-05-29
+---
+
+## Definition
+
+判别能力指标（Discrimination Metrics）衡量模型区分正例与负例的能力——给定一个随机正例和一个随机负例，模型有多大概率给正例更高的分数。区别于校准（衡量概率准确性），判别度衡量排序正确性。
+
+## Core Metrics
+
+### AUC (Area Under the ROC Curve)
+- ROC 曲线下面积，取值 [0.5, 1.0]
+- 0.5 = 随机猜测，1.0 = 完美区分
+- 解读：给定随机正例和随机负例，有 AUC 概率给正例更高分数
+- **优势**：阈值无关，对类别不平衡相对稳健
+
+### Gini Coefficient
+- $Gini = 2 \times AUC - 1$
+- 取值 [0, 1.0]，与 AUC 线性等价
+- 金融行业常用（信用卡评分、信贷风控）
+- 监管报告标准指标
+
+### KS Statistic (Kolmogorov-Smirnov)
+- 两个累积分布函数（正例 vs 负例）之间的最大垂直距离
+- $KS = \max_t |F_{pos}(t) - F_{neg}(t)|$
+- 取值 [0, 1.0]；KS > 0.2 通常认为有区分能力
+- **优势**：不依赖阈值，提供最佳分割点位置信息
+
+### Additional Metrics
+| Metric | Formula | 适用场景 |
+|--------|---------|---------|
+| F1 Score | $2 \times \frac{precision \times recall}{precision + recall}$ | 类别不平衡 |
+| RMSE | $\sqrt{\frac{1}{n}\sum(y_i - \hat{y}_i)^2}$ | 回归模型 |
+| Log Loss | $-\frac{1}{N}\sum[y_i \log p_i + (1-y_i)\log(1-p_i)]$ | 概率质量 |
+
+## Usage
+
+```python
+from sklearn.metrics import roc_auc_score, f1_score
+from scipy.stats import ks_2samp
+
+def discrimination_report(y_true, y_score):
+    auc = roc_auc_score(y_true, y_score)
+    gini = 2 * auc - 1
+    ks_stat, ks_pval = ks_2samp(y_score[y_true == 1], y_score[y_true == 0])
+    return {
+        "AUC": round(auc, 4),
+        "Gini": round(gini, 4),
+        "KS": round(ks_stat, 4),
+        "KS_pvalue": round(ks_pval, 6),
+    }
+```
+
+## Model QA 中的应用
+
+Model QA Specialist 执行以下判别能力审计：
+1. **全数据切片分析**：在 Train/Validation/Test/OOT 四个数据切片上分别计算 AUC/Gini/KS
+2. **子群体性能**：在性别/年龄/地区等受保护属性上分别测试，发现公平性隐患
+3. **时间稳定性**：跨 OOT 窗口追踪 AUC/Gini 趋势，识别性能衰减
+4. **冠军-挑战者对比**：Proposed model vs. incumbent production model，量化相对提升
+
+## Relationship
+
+- **被依赖** [[Calibration-Testing]]：先确认判别能力（KS > 0.2, AUC > 0.7），再测试校准
+- **依赖** [[Population-Stability-Index]]：PSI 监控输入稳定性，判别指标监控输出健康度
+- **依赖** [[SHAP]]：判别指标提供"是否好"的答案，SHAP 解释"为什么"
+- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的核心性能评估步骤
+
+## Key Insights
+
+- **判别度 vs 校准**：高 AUC 模型仍可能在特定概率区间严重校准偏差；两者必须同时评估
+- **KS vs AUC**：KS 对尾部区分更敏感（抓坏人），AUC 对整体排序更均衡
+- **监管门槛**：金融风控通常要求 Gini > 0.4（相当于 AUC > 0.7）方可上线
diff --git a/wiki/concepts/Divio-Documentation-System.md b/wiki/concepts/Divio-Documentation-System.md
new file mode 100644
index 00000000..b4dd0e3f
--- /dev/null
+++ b/wiki/concepts/Divio-Documentation-System.md
@@ -0,0 +1,61 @@
+---
+title: "Divio Documentation System"
+type: concept
+tags: ["documentation", "knowledge-management", "methodology"]
+last_updated: 2026-05-01
+---
+
+## Definition
+Divio Documentation System 是由 [Divio](https://www.divio.com) 提出的文档分类框架，将技术文档分为四个互不重叠的象限，每个象限有明确的目的、受众和写作风格要求。
+
+## Four Quadrants
+
+### 1. Tutorial（教程）— 学习导向
+- **目的**：让读者学会使用某个工具或技术
+- **受众**：新手、入门者
+- **风格**：循循善诱，像老师带学生一样，解释"为什么这样做"
+- **关键特征**：从零开始、有明确起点和终点、成功结果可验证
+- **反面教材**：不要写成操作手册（那是 How-to）或参考手册（那是 Reference）
+
+### 2. How-to Guide（操作指南）— 任务导向
+- **目的**：帮助读者完成特定任务
+- **受众**：已有基础知识的开发者
+- **风格**：实用导向，提供解决具体问题的步骤
+- **关键特征**：面向结果、不解释基础知识、假设读者知道基本操作
+- **反面教材**：不要写成教程（不需要从零开始）或参考文档（不需要穷举选项）
+
+### 3. Reference（参考文档）— 信息导向
+- **目的**：准确描述系统功能，提供查找式的信息检索
+- **受众**：需要精确信息的开发者
+- **风格**：简洁、精确、格式一致、不含解释
+- **关键特征**：结构化（按字母/功能分组）、完整枚举所有选项、自动生成
+- **反面教材**：不要混入教程内容或解释"为什么"，那会稀释参考价值
+
+### 4. Explanation（解释文档）— 理解导向
+- **目的**：帮助读者深入理解某个主题，提供背景和上下文
+- **受众**：想理解"为什么"的开发者
+- **风格**：探索性、讨论性、允许不同观点
+- **关键特征**：不提供步骤、不列举选项、聚焦概念和原理
+- **反面教材**：不要写成 How-to（不需要完成任务）或 Reference（不需要列举信息）
+
+## Key Rules
+
+### 绝对禁止：混合象限
+- 一个文档页面只属于一个象限
+- 混合会导致读者困惑（不知道该看哪部分）和作者维护困难
+- 常见错误：把"什么是 X"（Explanation）和"如何用 X"（How-to）写在同一页
+
+### 绝对禁止：在参考文档中写教程内容
+- API 参考文档只描述接口，不教如何使用
+- Tutorial 是独立页面
+
+### 文档类型与工具的对应关系
+| 类型 | 推荐工具 | 生成方式 |
+|------|---------|---------|
+| Tutorial | Jupyter Notebook, Docusaurus | 人工编写 |
+| How-to | Docusaurus, MkDocs | 人工编写 |
+| Reference | Sphinx, OpenAPI Generator | 自动生成 + 人工审核 |
+| Explanation | Docusaurus, MkDocs | 人工编写 |
+
+## Sources
+- [[engineering-technical-writer]] — Technical Writer Agent 使用 Divio 系统组织文档写作方法论
diff --git a/wiki/concepts/DockerHostNetworking.md b/wiki/concepts/DockerHostNetworking.md
new file mode 100644
index 00000000..eb911268
--- /dev/null
+++ b/wiki/concepts/DockerHostNetworking.md
@@ -0,0 +1,41 @@
+---
+title: "DockerHostNetworking"
+type: concept
+tags:
+  - "docker"
+  - "networking"
+  - "container"
+sources: []
+last_updated: 2026-04-20
+---
+
+## Overview
+
+DockerHostNetworking 是 Docker 容器访问宿主机网络服务的方式。默认情况下，容器内的 `localhost` 指向容器自身而非宿主机，因此需要特殊配置才能让容器访问运行在宿主机上的服务。
+
+## Why It Matters for Hermes Agent + Open WebUI
+
+Open WebUI 运行在 Docker 容器中，Hermes Agent API Server 运行在宿主机上（端口 8642）。容器内必须通过特殊方式访问宿主机端口。
+
+## Options
+
+### Option 1: host.docker.internal（推荐 macOS/Windows）
+```bash
+docker run --add-host=host.docker.internal:host-gateway ...
+# 访问：http://host.docker.internal:8642/v1
+```
+
+### Option 2: Host Networking（Linux）
+```bash
+docker run --network=host ...
+# 访问：http://localhost:8642/v1
+```
+
+### Option 3: Docker Bridge IP
+```bash
+# 先查询：docker inspect bridge | grep Gateway
+docker run -e OPENAI_API_BASE_URL=http://172.17.0.1:8642/v1 ...
+```
+
+## See Also
+- [[open-webui-hermes-agent]]
diff --git a/wiki/concepts/Docs-as-Code.md b/wiki/concepts/Docs-as-Code.md
new file mode 100644
index 00000000..5f413fc5
--- /dev/null
+++ b/wiki/concepts/Docs-as-Code.md
@@ -0,0 +1,82 @@
+---
+title: "Docs-as-Code"
+type: concept
+tags: ["documentation", "devops", "methodology"]
+last_updated: 2026-05-01
+---
+
+## Definition
+Docs-as-Code 是一种将文档视为代码的实践方法论——文档使用与代码相同的工具、流程和版本控制进行管理。
+
+## Core Principles
+
+### 1. 版本控制
+- 文档存储在 Git 仓库中
+- 所有变更通过 Pull Request 审查
+- 保留完整变更历史，支持回滚
+
+### 2. 自动化构建
+- 文档变更触发 CI/CD 流水线
+- 自动运行文档检查（spellcheck、broken links、style linting）
+- 自动部署到文档托管平台
+
+### 3. 协作流程
+- 开发者可以直接在 IDE 中编辑文档
+- 使用 Markdown / reStructuredText / AsciiDoc 等代码友好格式
+- 文档评审与代码评审使用相同工具和流程
+
+### 4. 自动化生成
+- API 参考文档从 OpenAPI/Swagger 规范自动生成
+- 代码示例从源代码自动提取
+- 从代码注释（docstrings/JSDoc）自动生成参考文档
+
+## Tooling Ecosystem
+
+### Static Site Generators
+- **Docusaurus**：Meta 出品，React 驱动，适合开源项目
+- **MkDocs**：Python 驱动，YAML 配置，Material 主题美观
+- **Sphinx**：Python 官方文档工具，reStructuredText 格式，扩展丰富
+- **VitePress**：Vue 团队出品，轻量快速，Markdown 优先
+
+### Documentation Generators
+- **OpenAPI Generator / Swagger Codegen**：从 OpenAPI 规范生成多语言 SDK + 参考文档
+- **JSDoc / TypeDoc**：从代码注释生成 JS/TS 参考文档
+- **Sphinx autodoc**：从 Python docstrings 自动生成参考文档
+- **Redoc**：开源 API 文档渲染器，从 OpenAPI 规范生成可读文档
+- **Stoplight**：商业级 API 设计 + 文档平台
+
+### Linting & Quality
+- **Vale**：prose linter，自定义风格规则，检查文档语法和风格一致性
+- **markdownlint**：Markdown 文件格式检查
+- ** spellchecker**：拼写检查
+- **Link Checker**：断链检测
+
+## Implementation Checklist
+
+### 基础设施
+- [ ] Git 仓库存储文档（与代码同一仓库或专门 docs 仓库）
+- [ ] CI/CD 流水线配置文档构建和检查
+- [ ] 选择静态站点生成器并完成初始配置
+- [ ] 配置自动化文档生成（API docs from OpenAPI/JSDoc）
+
+### 质量门禁
+- [ ] Vale prose linter 规则配置
+- [ ] markdownlint 检查配置
+- [ ] 断链检查集成
+- [ ] 拼写检查集成
+
+### 发布流程
+- [ ] 配置自动部署到 GitHub Pages / Read the Docs / Netlify
+- [ ] 文档变更触发 PR 审查流程
+- [ ] 定义文档所有者（维护者）职责
+
+### 版本管理
+- [ ] 配置多版本文档（对应软件版本）
+- [ ] 旧版本文档归档策略（标记弃用，不删除）
+
+## Relationship to Technical Writing
+
+Docs-as-Code 是 [[TechnicalWriter]] 的基础设施能力。[[engineering-technical-writer]] 定义了文档内容标准（Divio 系统、质量门禁、指标驱动），Docs-as-Code 提供了实现这些标准的工程化流程。两者共同构成完整的文档工程实践体系。
+
+## Sources
+- [[engineering-technical-writer]] — Technical Writer Agent 核心理念：文档即代码，代码无文档视为不完整
diff --git a/wiki/concepts/DomainDrivenDesign.md b/wiki/concepts/DomainDrivenDesign.md
new file mode 100644
index 00000000..6b474c0b
--- /dev/null
+++ b/wiki/concepts/DomainDrivenDesign.md
@@ -0,0 +1,32 @@
+---
+title: "Domain-Driven Design"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+一种以业务领域为核心的软件设计方法论，通过建立通用语言（Ubiquitous Language）在技术和业务团队之间建立统一的沟通模型，并以有界上下文（Bounded Context）划分系统的边界。
+
+## Key Patterns
+- **Bounded Context**：业务领域的清晰边界，每个上下文有独立的模型和术语
+- **Aggregate**：聚合根，负责维护业务不变量
+- **Domain Event**：领域事件，记录业务状态变化
+- **Anti-Corruption Layer**：防腐层，隔离外部系统对核心域的侵蚀
+- **Context Mapping**：上下文映射，定义不同有界上下文之间的关系（Upstream/Downstream/Conformist/Anti-Corruption）
+
+## Core Principles
+- **领域优先，技术其次**：先理解业务问题，再选择技术实现
+- **通用语言**：团队中的每个人都使用同一套术语，减少沟通摩擦
+- **持续精化**：领域模型通过迭代不断深化对业务的理解
+
+## Related Concepts
+- [[BoundedContext]]：DDD 中的核心边界概念
+- [[EventStorming]]：领域发现的协作技术
+
+## Sources
+- [[engineering-software-architect]]
+
+## Aliases
+- DDD
+- Domain-Driven Design
diff --git a/wiki/concepts/Dual-Sign-Off.md b/wiki/concepts/Dual-Sign-Off.md
new file mode 100644
index 00000000..cfe54e0f
--- /dev/null
+++ b/wiki/concepts/Dual-Sign-Off.md
@@ -0,0 +1,58 @@
+---
+title: "Dual Sign-Off"
+type: concept
+tags: [governance, quality, NEXUS, gate-keeping]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Dual Sign-Off（双重签批）是 NEXUS 多 Agent 框架的质量治理核心机制——在关键决策点，必须由**两个相互独立的不同视角**的 Gate Keeper **同时批准**，方才有效。任一方否决即为否决。
+
+## 设计原理
+
+单一 Gate Keeper 的盲区：
+- 仅战略视角 → 可能忽视技术可行性和工程复杂度
+- 仅技术视角 → 可能忽视业务价值和资源约束
+
+Dual Sign-Off 通过**视角正交性**消除单点故障，确保：
+1. 战略决策有技术可行性支撑
+2. 技术决策有业务价值对齐
+
+## 在 NEXUS 中的应用
+
+### Phase 1 — 战略 + 技术双签
+
+| Gate Keeper | 视角 | 验证内容 |
+|------------|------|---------|
+| [[Studio Producer]] | 战略 | 架构包是否对齐组织战略目标？ROI 是否符合预期？ |
+| [[Reality Checker]] | 技术 | 所有组件是否具备实现路径？质量门是否通过？ |
+
+### Phase 2 — DevOps + QA 双签
+
+| Gate Keeper | 视角 | 验证内容 |
+|------------|------|---------|
+| DevOps Automator | 基础设施 | CI/CD/IaC 是否就绪？可部署？ |
+| Evidence Collector | 质量验证 | 8 项截图证据是否全部通过？ |
+
+### Dev↔QA Loop（循环内）
+
+| 决策 | 条件 |
+|------|------|
+| PASS | Evidence Collector 证据通过 + Dev 确认修复 |
+| FAIL | 任何一方未通过；进入重试循环（最多3次） |
+
+## 决策规则
+
+- **任一方返回 REVISE** → 整体 REVISE；返回对应 Step 重做
+- **任一方返回 RESTRUCTURE** → 整体 RESTRUCTURE；重启本 Phase
+- **Evidence Over Claims**：口头确认无效，必须有截图/测试结果/日志证据
+
+## 与 Quality Gate Checklist 的关系
+
+Dual Sign-Off 是 Quality Gate Checklist 的**执行机制**。Quality Gate 定义"检查什么"（7项清单），Dual Sign-Off 定义"谁检查"和"如何通过"（双签规则）。
+
+## Aliases
+- Dual Approval
+- Twin Gate Mechanism
+- Bifurcated Sign-Off
diff --git a/wiki/concepts/EBUR128LoudnessNormalization.md b/wiki/concepts/EBUR128LoudnessNormalization.md
new file mode 100644
index 00000000..7f49b2b4
--- /dev/null
+++ b/wiki/concepts/EBUR128LoudnessNormalization.md
@@ -0,0 +1,47 @@
+---
+title: "EBUR128LoudnessNormalization"
+type: concept
+tags: ["audio-processing", "loudness", "ffmpeg", "ebur128"]
+last_updated: 2026-05-02
+---
+
+# EBUR128LoudnessNormalization（EBU R128 响度归一化）
+
+## Definition
+
+EBU R128 是欧洲广播联盟制定的响度归一化标准，用于确保不同来源的音频具有一致的感知响度。在 Whisper 类转录模型管道中，R128 归一化确保输入音频响度稳定，避免因音量差异导致的精度下降。
+
+## Standard Parameters
+
+```bash
+-af "loudnorm=I=-16:TP=-1.5:LRA=11"
+```
+
+| 参数 | 含义 | 标准值 |
+|------|------|--------|
+| `I` | 综合响度（Integrated Loudness） | -16 LUFS |
+| `TP` | 真峰值（True Peak） | -1.5 dBTP |
+| `LRA` | 响度范围（Loudness Range） | 11 LU |
+
+## Why -16 LUFS?
+
+- 广播标准（TV/Streaming）：-24 LUFS（旧标准）→ -16 LUFS（新趋势，Netflix/YouTube）
+- Podcast/对话内容：-16 LUFS 更适合语音主导的内容
+- 过高的综合响度（>-14 LUFS）会导致语音压缩失真
+
+## Pipeline Context
+
+```
+原始音频 → 格式检测（ffprobe）→ EBU R128 归一化 → 重采样至 16kHz → 单声道
+```
+
+## Why It Matters for Whisper
+
+Whisper 对响度变化不免疫。同一段语音，-30 LUFS 的录音和 -16 LUFS 的录音，后者的WER（Word Error Rate）更低，因为响度归一化降低了动态范围，减少了模型在处理软/响片段时的注意力分散。
+
+## Related Concepts
+- [[VoiceActivityDetection]] — 归一化之后的后处理
+- [[FasterWhisper]] — 归一化音频的消费者
+
+## Related Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/concepts/Echidna.md b/wiki/concepts/Echidna.md
new file mode 100644
index 00000000..42c5e904
--- /dev/null
+++ b/wiki/concepts/Echidna.md
@@ -0,0 +1,79 @@
+---
+title: "Echidna（属性化模糊测试）"
+type: concept
+tags: [blockchain, security, smart-contract, fuzzing, property-based-testing]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Echidna
+- Echidna Fuzzer
+- Property-Based Fuzzing
+
+## Definition
+
+Echidna 是一个属性化模糊测试（Property-Based Fuzzing）工具，专门用于智能合约安全测试。它通过随机生成交易序列，持续验证协议定义的不变性（invariants）是否始终成立。当不变性被违反时，Echidna 会生成触发该违规的具体交易序列作为 PoC。
+
+## How It Works
+
+1. **定义不变性**：用 Solidity 编写断言或属性
+2. **生成随机交易**：Echidna 以随机参数调用合约函数
+3. **监控不变性**：每次状态变更后检查断言
+4. **生成 PoC**：发现违规时输出触发序列
+
+## Example Test
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.24;
+
+import {Test} from "forge-std/Test.sol";
+import {Vault} from "../src/Vault.sol";
+
+contract EchidnaInvariantTest {
+    Vault public vault;
+
+    constructor() {
+        vault = new Vault();
+    }
+
+    // 不变性：任何时刻总存款 = 所有用户余额之和
+    function echidna_total_deposits_equals_sum() public view returns (bool) {
+        return vault.totalDeposits() == vault.getSumOfBalances();
+    }
+}
+```
+
+## Configuration
+
+```yaml
+# echidna-config.yaml
+testMode: assertion    # 断言模式
+testLimit: 500000      # 最大测试数
+timeout: 3600           # 超时（秒）
+sender: ["0x000...1", "0x000...2"]  # 发送者地址
+```
+
+## Relationship to Other Tools
+
+| Tool | Method | Strength |
+|------|--------|----------|
+| [[Slither]] | 静态分析 | 快速扫描，规则匹配 |
+| [[Mythril]] | 符号执行 | 深度路径覆盖 |
+| [[Echidna]] | 属性化模糊测试 | 随机交易序列，不变性验证 |
+
+- **Echidna** 是 Slither 和 Mythril 的**补充**，不是替代
+- Slither 找规则性漏洞 → Echidna 找逻辑漏洞
+- Foundry 的 `forge invariant` 命令也提供类似功能
+
+## Limitations
+
+- 不变性定义错误会导致漏报
+- 复杂状态空间难以在合理时间覆盖
+- 需要开发者定义正确的不变性
+
+## Connections
+- [[Blockchain-Security-Auditor]] ← uses ← [[Echidna]]
+- [[Foundry]] ← provides invariant testing ← [[Echidna]]
+- [[Formal-Verification]] ← complements ← [[Echidna]]
diff --git a/wiki/concepts/EffectiveTaxRate.md b/wiki/concepts/EffectiveTaxRate.md
new file mode 100644
index 00000000..41f88b26
--- /dev/null
+++ b/wiki/concepts/EffectiveTaxRate.md
@@ -0,0 +1,49 @@
+---
+title: "Effective Tax Rate (ETR)"
+type: concept
+tags: ["tax", "finance", "kpi", "compliance"]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+有效税率（Effective Tax Rate, ETR）是企业实际税负占税前收入的比例，是衡量税务筹划效果的核心 KPI。计算公式：
+
+```
+ETR = 总税负 ÷ 税前收入
+```
+
+## ETR vs Statutory Rate
+
+| 指标 | 说明 |
+|------|------|
+| Statutory Rate | 法定税率（如美国联邦 21%） |
+| ETR | 实际有效税率（含各项抵扣和优惠） |
+| Cash Tax Rate | 实际支付现金税率（含递延税） |
+
+ETR 通常低于 Statutory Rate，因为存在税收抵免（Tax Credits）、递延（Deferred Income）和国际税率差异等优化空间。
+
+## ETR Waterfall Components
+
+典型 ETR 瀑布分解：
+- Federal Statutory Tax（联邦法定税率）
+- State & Local Taxes（SALT）
+- International Rate Differential（国际税率差异）
+- R&D Tax Credits（R&D 税收抵免）
+- QBI Deduction（合格商业收入扣除）
+- Other Permanent/Temporary Adjustments（其他永久/暂时性调整）
+
+## Target
+
+- **[[finance-tax-strategist]]** 目标：ETR ≤ 行业同行中位数
+- 成功标准：审计调整 < 2% 总税负
+
+## Sources
+
+- [[finance-tax-strategist]]
+
+## Related Concepts
+
+- [[TransferPricing]]
+- [[GILTI]]
+- [[BEAT]]
diff --git a/wiki/concepts/Elasticity.md b/wiki/concepts/Elasticity.md
new file mode 100644
index 00000000..05a9640e
--- /dev/null
+++ b/wiki/concepts/Elasticity.md
@@ -0,0 +1,46 @@
+---
+title: "Elasticity"
+type: concept
+tags: [sre, cloud, scalability, reliability, capacity-planning]
+last_updated: 2026-04-20
+---
+
+# Elasticity
+
+弹性（Elasticity）是指系统在无需人工干预的情况下，根据需求动态调整容量的能力，是云原生的核心特性之一。
+
+## Definition
+真正的弹性需要**策略、测试和对瓶颈的认知**。它不仅仅是自动扩容，而是一个包含规划、执行和验证的完整体系。
+
+## Core Requirements
+1. **策略（Policy）**：明确定义扩容和缩容的规则
+2. **测试（Testing）**：在非生产环境验证弹性行为
+3. **瓶颈认知（Bottleneck Awareness）**：理解系统的性能瓶颈在哪里
+
+## Elasticity vs. Autoscaling
+
+| Aspect | [[Autoscaling]] | Elasticity |
+|--------|-----------------|-----------|
+| 性质 | 工具/机制 | 设计原则/能力 |
+| 范围 | 单一维度（资源） | 多维度（容量、性能、成本） |
+| 前瞻性 | 被动响应 | 主动规划 |
+| 人类角色 | 可能被排除 | 必须参与 |
+
+## Key Insight
+Autoscaling 是实现弹性的**工具之一**，但 Autoscaling 本身不等同于弹性。缺乏策略和测试的 Autoscaling 可能在故障期间造成更大损害。
+
+## Implementation Pillars
+- **Capacity Planning**：预测需求，提前规划
+- **Cost Optimization**：在弹性和成本之间取得平衡
+- **Observability**：通过遥测数据理解系统边界
+- **Chaos Engineering**：通过实验验证系统韧性
+
+## Related Concepts
+- [[Autoscaling]]
+- [[Scalability]]
+- [[Cost-Optimization]]
+- [[Observability]]
+- [[Resilience]]
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/concepts/Encounter-Design.md b/wiki/concepts/Encounter-Design.md
index 99259437..c91effac 100644
--- a/wiki/concepts/Encounter-Design.md
+++ b/wiki/concepts/Encounter-Design.md
@@ -1,39 +1,64 @@
 ---
 title: "Encounter Design"
 type: concept
-tags: []
-last_updated: 2026-04-26
+tags: ["game-design", "level-design", "combat-design", "player-balance", "tactics"]
+sources: ["level-designer.md"]
+last_updated: 2026-05-07
 ---
 
 ## Definition
 
-遭遇战设计（Encounter Design）是在游戏关卡中为战斗、挑战或关键互动节点制定规则与布局的学科。每个遭遇必须可读、公平且令人难忘。
+Encounter Design（遭遇战设计）是游戏关卡设计中对战斗、挑战或关键交互节点的规划方法论。**核心要求：每场遭遇战必须同时具备进入读时、多种战术选项和撤退位置——三者缺一则战斗不公平**。
 
-## Core Standards
+## Three Mandatory Elements
 
-### Three Mandatory Components
-每个战斗遭遇必须包含：
-1. **入口读图时间（Entry Read Time）**：玩家在进入遭遇前能看到战场全貌
-2. **多种战术选项（Multiple Tactical Approaches）**：至少 2 种可行战术，让玩家做有意义的选择
-3. **退守位置（Fallback Position）**：玩家处于劣势时可以安全撤退或重整的空间
+### 1. Entry Read Time（进入读时）
+玩家在进入战斗前必须有时间感知威胁：
+- **禁止**：玩家无法在受击前看到敌人的位置（设计的伏击除外，但必须有预兆）
+- **标准**：敌人必须在玩家进入交战范围前可见
+- **伏击设计**：必须有 telegraph（预兆信号），如声音、光照变化、敌人标记
 
-### Enemy Placement Rules
-- 禁止将敌人放在玩家进入视野前就能造成伤害的位置（设计好的伏击除外，但必须有预警信号）
-- 难度必须先从空间（位置和布局）出发，再考虑数值缩放
-- 所有敌人必须在玩家进入交战范围前可见
+### 2. Multiple Tactical Approaches（多种战术选项）
+每场战斗必须至少有 2 种在测试中被证明可行的战术：
+- **进攻选项**：正面突破、侧翼、包抄
+- **防守选项**：利用掩体、占据高点、等待冷却
+- **策略选项**：利用环境（可破坏物、陷阱触发物）
+- **禁止**：只有一种最优解的战斗设计
 
-### Difficulty Hierarchy
-1. **Spatial first**（位置第一）：通过敌人位置和掩体布局创造难度
-2. **Stat scaling second**（数值第二）：在空间设计固定后，通过数值调整难度
+### 3. Fallback Position（撤退位置）
+玩家处于劣势时必须有脱离战场的空间选项：
+- **要求**：撤退位置必须在空间上明显（玩家能直觉感知）
+- **功能**：给予玩家重新评估局势、改变战术的机会
+- **平衡**：撤退位置不应该是绝对安全的（否则玩家永远不进攻）
 
-## Tensions
-- **Readability vs. Surprise**：清晰战场 vs. 惊喜伏击，通过 telegraphing（预警）平衡
-- **Choice vs. Optimal**：多种战术选项 vs. 存在唯一最优解，通过 playtest 验证多样性
+## Difficulty Hierarchy
 
-## Related Concepts
-- [[Flow And Readability]]：Encounter 是 Flow 路径上的节点
-- [[Blockout Discipline]]：Encounter 在灰盒阶段必须完成可玩性验证
-- [[Pacing Architecture]]：Encounter 的密度和强度决定整体节奏
+遭遇战难度应首先通过**空间设计**（位置、布局）而非数值缩放实现：
 
-## Sources
-- [[Level Designer Agent Personality]]
+1. **Spatial Difficulty**（空间难度）：通过掩体数量、高低差、通道宽度实现
+2. **Tactical Difficulty**（战术难度）：通过敌人类型组合、AI 行为模式实现
+3. **Stat Difficulty**（数值难度）：作为最后手段，缩放敌人生命值/伤害
+
+## Encounter List Template
+
+```markdown
+## Encounter List
+
+| ID  | Type     | Enemy Count | Tactical Options | Fallback Position |
+|-----|----------|-------------|------------------|-------------------|
+| E01 | Ambush   | 4           | Flank / Suppress | Door archway      |
+| E02 | Arena    | 8           | 3 cover positions| Elevated platform |
+```
+
+## Playtest Validation
+
+- 每场遭遇战必须单独 Playtest 验证
+- 测量指标：time-to-death、成功战术分布、混乱时刻
+- 迭代标准：直到至少 2 种战术被测试者成功使用
+
+## Connections
+
+- [[Level Designer]] 是 Encounter Design 的核心执行者
+- [[Grey Box Blockout]] 阶段必须验证所有遭遇战
+- [[Spatial Psychology]] 影响撤退位置和有利地形的空间感知设计
+- [[Pacing Chart]] 中的 Combat 条目直接对应 Encounter Design 的节奏峰值
diff --git a/wiki/concepts/Environmental-Storytelling.md b/wiki/concepts/Environmental-Storytelling.md
index 611731a9..af5bba5c 100644
--- a/wiki/concepts/Environmental-Storytelling.md
+++ b/wiki/concepts/Environmental-Storytelling.md
@@ -1,38 +1,69 @@
 ---
 title: "Environmental Storytelling"
 type: concept
-tags: []
-last_updated: 2026-04-26
+tags: ["game-design", "narrative-design", "world-building", "level-design", "atmosphere"]
+sources: ["level-designer.md", "narrative-designer.md"]
+last_updated: 2026-05-07
 ---
 
 ## Definition
 
-环境叙事（Environmental Storytelling）是通过环境本身讲述故事的设计方法——无需对话、文字或过场动画，玩家仅凭空间布局、道具摆放和光照变化就能推断出世界中发生的事件。
+Environmental Storytelling（环境叙事）是通过场景道具摆放、光照设计、几何形状和破坏痕迹传达世界观故事的设计手法——**玩家无需对话或文字即可推断空间中发生过什么**。核心信念：**空间本身就是叙事媒介**。
 
 ## Core Principles
 
-### No Empty Spaces
-- 每个区域必须通过道具摆放、光照和几何形状讲述故事
-- 不存在空白的"填充"空间
-- 破坏、磨损和环境细节必须与世界叙事历史一致
+### 1. Every Space Tells a Story
+每个区域都应通过物理证据传达信息：
+- 倒落的家具 → 某人匆忙离开
+- 墙上的弹孔 → 发生过战斗
+- 凌乱的办公桌 → 被迫中断的工作
+- 儿童玩具 → 这是一个家庭空间
 
-### Inference-Based Learning
-- 玩家应该能够在不借助对话或文本的情况下推断出空间中发生了什么
-- 倒置的家具暗示某人匆忙离开——lean into that（顺着这个讲）
-- 玩家通过观察环境理解世界，而非被告知
+### 2. Consistency with World History
+破坏、磨损和细节必须与设定的世界时间线一致：
+- 不同年代的空间应有不同的磨损程度
+- 灾难事件后的空间必须有相应的破坏证据
+- 废弃空间应有相应的尘土、蛛网、自然侵蚀
 
-### Three Storytelling Channels
-1. **道具摆放（Prop Placement）**：物品位置讲述历史事件
-2. **光照（Lighting）**：明暗对比传达情绪和焦点
-3. **几何形状（Geometry）**：空间规模暗示功能和重要性
+### 3. No Empty Filler Spaces
+禁止"纯装饰性填充空间"——每个空间必须有叙事目的：
+- 即使是过渡走廊，也应通过环境细节传达世界信息
+- 环境叙事密度随关卡重要性递增
 
-## Related Concepts
-- [[Level Designer Agent]]：Level Designer 是 Environmental Storytelling 的主要执行者（物理空间设计与道具摆放）
-- [[Narrative Designer Agent]]：Narrative Designer 提供环境叙事的叙事内容架构（道具的叙事意义定义）
-- [[Spatial Psychology]]：空间如何影响玩家的情感和认知
-- [[Flow And Readability]]：叙事空间同时必须是可导航的
-- [[Lore Architecture]]：环境叙事是 Tier 2/3 Lore 的物理呈现
+## Techniques
 
-## Sources
-- [[Level Designer Agent Personality]]
-- [[Narrative Designer Agent Personality]]
+### Physical Props
+道具是最直接的环境叙事媒介：
+- 选择性摆放（而非随机放置）传达人物意图
+- 对比性道具（"这不应该在这里"）制造悬念
+
+### Lighting and Color
+光照是环境叙事最强力的工具：
+- 明暗对比引导注意力，暗示重要区域
+- 色温传达情感：暖色=安全/生活，冷色=危险/陌生
+- 动态光源（如闪烁的火焰）暗示时间流逝或危险
+
+### Geometry and Architecture
+空间本身传达权力关系和历史：
+- 高天花板 → 公共/权威空间
+- 低矮通道 → 压迫/隐藏路径
+- 环形空间 → 迷宫/无法逃逸感
+
+### Destruction and Decay
+损坏和腐朽是时间故事的视觉证据：
+- 自然的生物侵蚀（苔藓、蛛网）
+- 暴力的物理破坏（烧毁、爆炸、战斗痕迹）
+- 社会性废弃（垃圾、个人物品散落）
+
+## Metrics
+
+环境叙事有效性通过 Playtest 验证：
+- **>70% 的测试玩家能正确推断环境故事**时，环境叙事设计达标
+- 开放式问题："这个空间告诉了你什么？"收集推断准确性数据
+
+## Connections
+
+- [[Level Designer]] 是环境叙事的物理空间执行者
+- [[Narrative Designer]] 定义环境叙事的内容框架（世界设定、时间线）
+- [[Pacing Chart]] 中的 Exploration 时段是环境叙事密度最高的时间窗口
+- [[Grey Box Blockout]] 阶段验证环境叙事是否可感知（道具位置在灰盒中以占位符标记）
diff --git a/wiki/concepts/EriksonPsychosocialStages.md b/wiki/concepts/EriksonPsychosocialStages.md
new file mode 100644
index 00000000..56cc8ff3
--- /dev/null
+++ b/wiki/concepts/EriksonPsychosocialStages.md
@@ -0,0 +1,35 @@
+---
+title: "Erikson Psychosocial Stages"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# Erikson Psychosocial Stages
+
+## Aliases
+- Erikson's Stages of Development
+- Psychosocial Development Stages
+
+## Definition
+Erikson 心理社会发展阶段——人在整个生命周期中面临的八个心理社会危机，每个危机的解决方式影响后续阶段的发展轨迹。
+
+## Eight Stages
+
+| 阶段 | 年龄 | 核心危机 | 成功解决 | 未解决 |
+|------|------|----------|----------|--------|
+| 1 | 0-1岁 | Trust vs. Mistrust（信任 vs. 不信任） | 安全感 | 恐惧、不安全感 |
+| 2 | 1-3岁 | Autonomy vs. Shame（自主 vs. 羞耻） | 意志力 | 自我怀疑 |
+| 3 | 3-6岁 | Initiative vs. Guilt（主动性 vs. 内疚） | 方向感 | 过度内疚 |
+| 4 | 6-12岁 | Industry vs. Inferiority（勤奋 vs. 自卑） | 能力感 | 自卑 |
+| 5 | 12-18岁 | Identity vs. Role Confusion（同一性 vs. 角色混乱） | 自我认同 | 角色混乱 |
+| 6 | 18-40岁 | Intimacy vs. Isolation（亲密 vs. 孤独） | 爱的能力 | 孤立、疏离 |
+| 7 | 40-65岁 | Generativity vs. Stagnation（再生力 vs. 停滞） | 关怀传承 | 停滞、自我关注 |
+| 8 | 65岁+ | Integrity vs. Despair（完善 vs. 绝望） | 智慧、接纳 | 悔恨、绝望 |
+
+## Application in Character Design
+Psychologist Agent 使用此框架设计角色发展弧光时，强调**非决定论**——早期危机的影响可以被后续发展所修正，不存在"童年决定一切"的宿命论。
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/Evidence-Over-Claims.md b/wiki/concepts/Evidence-Over-Claims.md
new file mode 100644
index 00000000..9c3ef71b
--- /dev/null
+++ b/wiki/concepts/Evidence-Over-Claims.md
@@ -0,0 +1,39 @@
+---
+title: "Evidence Over Claims"
+type: concept
+tags: [multi-agent, quality, evidence, nexus]
+sources: [executive-brief, quickstart]
+last_updated: 2026-05-01
+aliases:
+  - Evidence-Based Quality
+  - Proof Over Promise
+---
+
+## Definition
+
+证据优于主张（Evidence Over Claims）—— NEXUS 多 Agent 编排框架的核心质量原则：所有质量声明必须基于可验证的证据（截图/测试结果/性能数据），而非口头断言或自我评估。
+
+## Core Principle
+
+```
+主张：✓ 功能已完成，质量优秀
+证据：✓ 自动化测试通过率 100%，覆盖率 85%，Lighthouse 性能评分 95
+```
+
+只有证据才能推动流程前进。口头断言、承诺或自我评估都不是有效的质量证明。
+
+## Evidence Hierarchy
+
+| 证据类型 | 优先级 | 示例 |
+|---------|-------|------|
+| 截图/录屏 | 最高 | 关键功能运行录屏、UI 对比截图 |
+| 自动化测试结果 | 高 | Jest/Vitest 测试报告、覆盖率报告 |
+| 性能数据 | 高 | Lighthouse 报告、API 响应时间表 |
+| 第三方审计报告 | 中 | 安全扫描报告、无障碍审计报告 |
+| 口头断言/自我评估 | 最低 | "功能已实现"、"质量很好" |
+
+## Related Concepts
+
+- [[Reality Checker]]：Evidence Over Claims 原则的强制执行者——默认"NEEDS WORK"，要求提供证据
+- [[Quality Gate]]：Evidence Over Claims 是质量门控的判断标准
+- [[Dev↔QA Loop]]：Dev↔QA 循环中的 PASS/FAIL 判定必须基于证据
diff --git a/wiki/concepts/EvidenceCollection.md b/wiki/concepts/EvidenceCollection.md
new file mode 100644
index 00000000..defa71e7
--- /dev/null
+++ b/wiki/concepts/EvidenceCollection.md
@@ -0,0 +1,51 @@
+---
+title: "Evidence Collection"
+type: concept
+tags: []
+sources: [compliance-auditor]
+last_updated: 2026-04-30
+---
+
+# Evidence Collection
+
+## Definition
+
+证据收集（Evidence Collection）是合规审计中从被审计系统提取、记录和整理证据材料的过程，用以证明控制措施在审计期间有效运行。证据必须证明控制**在整个审计期间持续有效**，而非仅在审计当天存在。
+
+## Core Principles
+
+### 自动化优先原则
+- **手动证据是脆弱的证据**——依赖人工截图、导出的流程无法保证一致性
+- 从第一天就建立自动化证据收集管道——手动流程无法扩展
+- 自动化证据的优势：可重复、一致、可追溯
+
+### 证据收集矩阵
+| 控制 ID | 控制描述 | 证据类型 | 来源 | 收集方法 | 频率 |
+|---------|---------|---------|------|---------|------|
+| CC6.1 | 逻辑访问控制 | 访问审查日志 | Okta | API 导出 | 季度 |
+| CC6.2 | 用户配置 | 入职工单 | Jira | JQL 查询 | 事件触发 |
+| CC6.3 | 用户取消配置 | 离职清单 | HR系统+Okta | 自动化 webhook | 事件触发 |
+| CC7.1 | 系统监控 | 告警配置 | Datadog | 仪表板导出 | 月度 |
+
+### 按控制目标组织
+- 证据包必须按**控制目标**组织，而非按内部团队结构组织
+- 审计师需要的是按控制逻辑组织的证据，而非按 IT/HR/法务部门组织的文件
+
+### 审计师视角
+- 思考"你会测试什么？"和"你会要求什么证据？"
+- 抽样原则：若控制适用于 500 台服务器，审计师会抽样——确保任何一台都能通过
+
+## Evidence Types
+- 日志文件（访问日志、操作日志、安全日志）
+- 配置快照（系统配置、安全策略）
+- 审批记录（变更审批、例外审批）
+- 报告导出（监控仪表板、合规报告）
+- 自动化脚本输出（API 导出、脚本执行结果）
+
+## Related Concepts
+- [[SOC 2]]：Type II 审计要求持续有效证据
+- [[Gap Assessment]]：修复差距后需要收集相应证据
+- [[Continuous Compliance]]：持续合规要求周期性证据收集
+
+## Related Sources
+- [[compliance-auditor]]
diff --git a/wiki/concepts/EvidenceFirstReasoning.md b/wiki/concepts/EvidenceFirstReasoning.md
new file mode 100644
index 00000000..42b08ba4
--- /dev/null
+++ b/wiki/concepts/EvidenceFirstReasoning.md
@@ -0,0 +1,39 @@
+---
+title: "EvidenceFirstReasoning"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+
+Evidence-First Reasoning（证据优先推理）是一种推理原则：只陈述代码中实际可见、可验证的事实，绝不进行推理、假设或猜测。
+
+## Core Rule
+
+> "Never state that a module owns behavior unless you can point to the file(s) that implement or route it."
+
+如果某件事在检查的代码中不可见，就不能陈述它。
+
+## Contrast with Other Approaches
+
+| Evidence-First Reasoning | Speculative Reasoning |
+|---|---|
+| 基于代码中可验证的事实 | 基于推测和假设 |
+| 明确告知检查范围边界 | 不声明检查边界 |
+| 引用具体文件/函数名 | 使用泛化描述 |
+| 诚实回答"不知道" | 试图覆盖不确定区域 |
+
+## Application in AI Coding Agents
+
+AI Coding Agent 在执行代码库分析时：
+- 必须引用具体源文件路径
+- 必须区分"检查过的代码"和"未检查的代码"
+- 不得推断意图、质量或未来工作
+- 当答案是部分的，只能说明检查了哪些文件
+
+## Related Concepts
+
+- [[CodebaseOnboarding]] — 代码库 onboarding 方法论
+- [[ExecutionTracing]] — 执行路径追踪
+- [[MinimalChangePrinciple]] — 最小变更原则（[[EngineeringMinimalChangeEngineer]] 使用的原则）
diff --git a/wiki/concepts/ExecutionTracing.md b/wiki/concepts/ExecutionTracing.md
new file mode 100644
index 00000000..15b39301
--- /dev/null
+++ b/wiki/concepts/ExecutionTracing.md
@@ -0,0 +1,42 @@
+---
+title: "ExecutionTracing"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+
+Execution Tracing（执行追踪）是追踪请求、事件、命令在系统中完整流动路径的方法。通过追踪数据如何进入、转换、持久化和退出，建立对代码库实际工作方式的准确理解。
+
+## Core Steps
+
+1. **Identify entry point** — 找到请求/命令的入口文件
+2. **Follow routing logic** — 追踪路由/控制器层的分发逻辑
+3. **Trace business logic** — 追踪核心业务逻辑的调用链
+4. **Map persistence layer** — 找到数据持久化或副作用发生的位置
+5. **Track return path** — 追踪结果如何返回到调用方
+
+## Key Signals to Track
+
+- **Inputs**: HTTP requests, CLI args, messages, files, function arguments
+- **Transforms**: Data validation, enrichment, computation, aggregation
+- **Outputs**: Responses, DB writes, files, events, rendered UI
+
+## Async & Side Channels
+
+- 异步 jobs 和 queues
+- Cron tasks 和定时任务
+- Background workers
+- Client-side state 变更
+
+## Usage Context
+
+- 理解新代码库的运行机制
+- 定位 bug 的根本原因
+- 评估代码变更的潜在影响范围
+
+## Related Concepts
+
+- [[CodebaseOnboarding]] — 代码库 onboarding 的方法论
+- [[MentalModel]] — 为开发者构建准确的心智模型
diff --git a/wiki/concepts/Executive-Summary-Formula.md b/wiki/concepts/Executive-Summary-Formula.md
new file mode 100644
index 00000000..9c46e370
--- /dev/null
+++ b/wiki/concepts/Executive-Summary-Formula.md
@@ -0,0 +1,47 @@
+---
+title: "执行摘要五步结构（Executive Summary Formula）"
+type: concept
+tags: [sales, proposal, executive-summary]
+sources: [sales-proposal-strategist]
+last_updated: 2026-04-29
+---
+
+## Definition
+
+执行摘要是提案最关键的单页——很多高级评审者（尤其是 C-suite）只读这一页。它不是提案的摘要，而是提案的最终辩论（closing argument），放在最前面。
+
+## 五步结构
+
+| Step | 内容 | 目的 |
+|------|------|------|
+| 1 | **镜像买家处境**（2-3句） | 证明你倾听了，使用他们自己的语言 |
+| 2 | **引入核心张力** | 不作为的代价或被错失的机会 |
+| 3 | **呈现论点**（2-3句） | 你的方法如何化解张力；赢主题在此自然出现 |
+| 4 | **提供证明**（1-2个） | 类似案例、可衡量成果、差异化方法论细节 |
+| 5 | **以转化状态收尾** | 12-18 个月后买家组织具体、可衡量的状态 |
+
+## 黄金法则
+
+- **一页纸**：每句话都必须自证其存在价值
+- **先赢主题后细节**：评审者在最初 100 个词内决定你是否理解他们的问题
+- **执行摘要可独立成文**：如果只给买家一页，让他们读执行摘要
+
+## 与赢主题的关系
+
+赢主题必须在执行摘要中出现（Step 3），但以自然整合的方式出现，而非列表形式。执行摘要是赢主题密度最高的单页。
+
+## 与三幕式提案叙事的关系
+
+执行摘要是三幕叙事的浓缩版：
+- Step 1 ≈ Act I（理解挑战）
+- Step 2-3 ≈ Act II（方案旅程）
+- Step 4-5 ≈ Act III（转化状态）
+
+## Related Concepts
+
+- [[三幕式提案叙事]]：五步结构的完整展开
+- [[Win Theme]]：执行摘要中自然整合的叙事支柱
+
+## Sources
+
+- [[sales-proposal-strategist]]
diff --git a/wiki/concepts/Fabula-vs-Sjuzhet.md b/wiki/concepts/Fabula-vs-Sjuzhet.md
new file mode 100644
index 00000000..178c4fb1
--- /dev/null
+++ b/wiki/concepts/Fabula-vs-Sjuzhet.md
@@ -0,0 +1,43 @@
+---
+title: "Fabula vs. Sjuzhet"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Fabula vs. Sjuzhet
+- Story vs. Narrative
+- 故事 vs. 叙事
+- 事件 vs. 呈现
+
+## Overview
+Fabula（故事）与 Sjuzhet（叙事话语）是 Russian Formalism 提出的核心区分，后经 [[Vladimir Propp]] 和 French Structuralism 发展完善。
+
+| 术语 | 定义 | 问法 |
+|------|------|------|
+| **Fabula** | 按实际时间顺序发生的所有事件集合 | "发生了什么？" |
+| **Sjuzhet** | 事件在叙事中被呈现的方式（顺序、省略、重复、聚焦） | "故事是怎么讲的？" |
+
+## Key Implications
+
+### The Critical Insight（[[Academic Narratologist]] 核心观点）
+> "Most problems live in the telling (sjuzhet), not the tale (fabula)."
+
+大多数叙事问题存在于讲述方式（如何重组、选择、省略、聚焦），而非故事本身。
+
+### Example
+- **Fabula**: 英雄被选中 → 接受训练 → 与反派战斗 → 获胜
+- **Sjuzhet variants**:
+  - 从反派视角讲述 → 产生反英雄同情
+  - 倒叙讲述 → 制造悬念
+  - 从中间开始 → 省去建置阶段
+
+## Application
+- 诊断叙事问题时，必须先判断问题在哪个层级
+- [[Academic Narratologist]] 使用此框架区分"情节问题"和"讲述问题"
+
+## Relationship to Other Concepts
+- [[Genette-Narratology]]：Genette 深化了 sjuzhet 的分析维度（时序、频率、声音）
+- [[ControllingIdea]]：Controlling Idea 存在于 fabula 层，但通过 sjuzhet 层传达
diff --git a/wiki/concepts/Failure-Pattern-Analysis.md b/wiki/concepts/Failure-Pattern-Analysis.md
new file mode 100644
index 00000000..2ef8701a
--- /dev/null
+++ b/wiki/concepts/Failure-Pattern-Analysis.md
@@ -0,0 +1,42 @@
+---
+title: "Failure Pattern Analysis"
+type: concept
+tags: [testing, failure-analysis, quality]
+sources: [testing-test-results-analyzer]
+last_updated: 2026-04-28
+---
+
+## Aliases
+- Defect Pattern Analysis
+- Test Failure Classification
+- Root Cause Pattern Detection
+
+## Definition
+
+失败模式分析——通过统计方法对测试失败进行分类、聚类和趋势分析，识别系统性质量问题并定位根因。
+
+## Failure Categories
+
+| 类别 | 说明 | 典型特征 |
+|------|------|---------|
+| 功能性 (Functional) | 功能行为不符合预期 | 逻辑错误、边界条件 |
+| 性能 (Performance) | 响应时间/SLA 不达标 | 慢查询、资源瓶颈 |
+| 安全 (Security) | 安全漏洞或合规问题 | 注入、权限绕过 |
+| 集成 (Integration) | 模块间接口不一致 | API 变更、协议不匹配 |
+
+## Key Methods
+
+- **Statistical Failure Trend Analysis**：跨时间序列分析失败率变化，识别恶化趋势。
+- **Root Cause Clustering**：将相似失败聚类，定位共同根因。
+- **Failure Distribution by Layer**：按系统层次（UI/业务逻辑/数据/基础设施）分布分析，识别系统性薄弱层。
+
+## Key Insights (from TestResultsAnalyzer)
+
+> "Failure pattern analysis reveals 73% of defects originate from integration layer" — 系统层分布分析洞察示例
+
+## Connections
+
+- [[Statistical-Analysis]]：失败模式分析依赖统计方法验证。
+- [[Root-Cause-Analysis]]：失败模式分析的下游是根因定位。
+- [[Dev-QA-Loop]]：失败模式分析结果反馈到开发-测试循环以调整测试策略。
+- [[Quality-Metrics]]：失败率是核心质量指标。
diff --git a/wiki/concepts/Fairness-Audit.md b/wiki/concepts/Fairness-Audit.md
new file mode 100644
index 00000000..7d045a23
--- /dev/null
+++ b/wiki/concepts/Fairness-Audit.md
@@ -0,0 +1,56 @@
+---
+title: "Fairness Audit"
+type: concept
+tags: [model-evaluation, fairness, bias, ml-ethics, model-governance]
+sources:
+  - specialized-model-qa
+last_updated: 2026-05-29
+---
+
+## Definition
+
+公平性审计（Fairness Audit）是 ML 模型审计中评估模型是否对不同受保护群体（protected groups）产生系统性歧视的过程。核心目标：识别和量化模型预测中基于种族、性别、年龄、宗教、国籍等受保护属性的不公平差异，确保模型符合伦理规范和监管要求。
+
+## Core Metrics
+
+### Demographic Parity（人口统计均等）
+- 要求：模型的正预测率在各群体间相等
+- 公式：$P(\hat{Y}=1|A=0) = P(\hat{Y}=1|A=1)$
+- 也称为：Statistical Parity, Independence Criterion
+
+### Equalized Odds（均等化赔率）
+- 要求：在相同真实标签条件下，各群体的预测分布相等
+- 公式：$P(\hat{Y}=1|A=0,Y=y) = P(\hat{Y}=1|A=1,Y=y)$，for $y \in \{0,1\}$
+- 比 Demographic Parity 更严格，同时要求 TPR 和 FPR 在各群体间相等
+
+### Disparate Impact Ratio（差异影响比）
+- $DIR = \frac{P(\hat{Y}=1|A=\text{minority})}{P(\hat{Y}=1|A=\text{majority})}$
+- 4/5 规则：DIR < 0.8 通常视为存在差异影响
+
+### Calibration Across Groups
+- 在各受保护群体上分别验证预测概率校准性
+- 确保高风险决策（贷款拒绝、保险定价）不会系统性低估某群体
+
+## Model QA 中的应用
+
+Model QA Specialist 执行以下公平性审计步骤：
+1. **受保护属性识别**：确认模型决策涉及哪些受保护特征（法律/道德/业务角度）
+2. **Baseline 指标计算**：在全人群上计算 AUC/KS/Gini 作为基准
+3. **分层指标对比**：在受保护群体上分别计算性能指标，量化差距
+4. **差异影响评估**：DIR < 0.8 则标记为潜在歧视，需进一步调查
+5. **因果分析**：区分相关关系（Correlation）与因果效应（Causation），避免虚假公平性
+6. **补救建议**：Pre-processing（重采样/重加权）/ In-processing（对抗训练/约束优化）/ Post-processing（阈值调整）
+
+## Relationship
+
+- **依赖** [[Discrimination-Metrics]]：公平性审计首先建立在判别能力评估之上
+- **依赖** [[SHAP]]：SHAP 贡献分析揭示哪些特征驱动了跨群体差异
+- **依赖** [[Calibration-Testing]]：跨群体校准是公平性决策的基础
+- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的可解释性与公平性审计步骤核心工具
+
+## Key Limitations
+
+- **公平性指标不可同时最优**：Demographic Parity 与 Equalized Odds 在一般情况下不可同时满足（Impossibility Theorem）
+- **代理变量问题**：直接排除受保护属性后，模型仍可能通过代理变量（如邮编→种族）歧视
+- **数据不平衡**：受保护群体的稀缺样本可能导致统计结论不可靠
+- **监管框架差异**：欧盟 AI Act / 美国 EEOC / 巴塞尔协议对公平性要求各不相同
diff --git a/wiki/concepts/False-Cognates.md b/wiki/concepts/False-Cognates.md
new file mode 100644
index 00000000..203800ef
--- /dev/null
+++ b/wiki/concepts/False-Cognates.md
@@ -0,0 +1,56 @@
+---
+title: "False Cognates"
+type: concept
+tags: ["spanish", "linguistics", "translation", "false-friends", "cognates", "trap"]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+**False Cognates**（假同源词/欺骗性同源词）指那些在两种语言中看起来相似但含义完全不同的词汇。如果直接翻译会导致严重误解甚至尴尬。
+
+## High-Risk Spanish-English False Cognates
+
+| 西班牙语 | 字面/错误理解 | 实际含义 | 严重程度 |
+|---|---|---|---|
+| **embarazada** | "embarrassed"（尴尬） | **怀孕** | ⚠️ 极高 |
+| **sensible** | "sensible"（理智的） | **敏感的** | ⚠️ 中等 |
+| **éxito** | "exit"（出口） | **成功** | ⚠️ 中等 |
+| **actual** | "actual"（真实的） | **当前的/现在的** | ⚠️ 中等 |
+| **asistir** | "assist"（帮助） | **参加/出席** | ⚠️ 中等 |
+| **carpet** | (英语) | **公交车**（西班牙/拉丁美洲部分地区） | 🔴 极高 |
+| **constipated** | (英语) | **鼻塞**（英语） | 🔴 极高（仅西班牙语语境） |
+| **molestar** | "molest"（骚扰） | **打扰/麻烦** | ⚠️ 高 |
+| **deception** | (英语) | **欺骗** | ⚠️ 高（西班牙语中"decepción"=失望） |
+| **casualmente** | "casually"（随便地） | **碰巧/偶然** | ⚠️ 中等 |
+| **oportunidad** | "opportunity"（机会） | **机会**（含义相同，但西班牙语中也指"商店营业时间"） | ⚠️ 低 |
+| **desgraciado** | 看起来像"disgraceful" | **可怜的/可恶的**（程度比英语"disgraceful"重得多） | ⚠️ 高 |
+
+## More Examples
+
+| 西班牙语 | 英文对应词 | 西班牙语实际含义 |
+|---|---|---|
+| **largo** | large | **长的** |
+| **grosero** | gross | **粗鲁的** |
+| **excitado** | excited | **兴奋的/激动的**（英语 excited 的自然翻译，但也暗示性兴奋） |
+| **fábrica** | fabric | **工厂** |
+| **intoxicado** | intoxicated | **中毒的**（不仅限于酒精） |
+| **lectura** | lecture | **阅读/读物** |
+| **datos** | dates | **数据** |
+| **dormitorio** | dormitory | **卧室** |
+
+## In Translation
+
+[[Language Translator]] Agent 的工作原则：
+- 每当源语言或目标语言中出现假同源词，必须主动标注
+- 不允许字面翻译导致误解的场景发生
+- 对高风险词汇（如 embarazada）给予特别提示
+
+## Prevention Strategy
+
+1. **Always verify**：看似相似的词必须查证实际含义
+2. **Context check**：即使知道正确含义，也要确认语境
+3. **Flag high-risk pairs**：embarazada/sensible/éxito/asistir 属于每次必标
+
+## Sources
+- [[language-translator]]
diff --git a/wiki/concepts/FasterWhisper.md b/wiki/concepts/FasterWhisper.md
new file mode 100644
index 00000000..39d5372b
--- /dev/null
+++ b/wiki/concepts/FasterWhisper.md
@@ -0,0 +1,50 @@
+---
+title: "FasterWhisper"
+type: concept
+tags: ["voice-ai", "whisper", "local-llm", "ctranslate2"]
+last_updated: 2026-05-02
+---
+
+# FasterWhisper
+
+## Definition
+
+Faster-Whisper 是 OpenAI Whisper 的 CTranslate2 优化实现，在精度与原版相当的情况下，速度提升 2-4 倍，内存占用减少 50%+。是生产环境中本地转录的首选实现。
+
+## Key Properties
+
+- **底层优化**：CTranslate2（自定义 CUDA/AVX kernel）替代 PyTorch 原生实现
+- **速度对比**：Whisper large-v3 在 A10G GPU 上约 2-3x 实时，Faster-Whisper 可达 8-10x 实时
+- **精度**：与原版 Whisper 几乎无差别（<0.5% WER 差异）
+- **模型规模**：tiny / base / small / medium / large-v2 / large-v3
+- **关键参数**：`beam_size=5`（精度优先）、`word_timestamps=True`（字幕精度必需）、`vad_filter=True`
+- **CPU 支持**：支持 CPU 推理（无 GPU 环境下的 viable 选项，速度较慢）
+
+## Model Size Selection Guide
+
+| 场景 | 推荐模型 | 硬件要求 |
+|------|---------|---------|
+| 实时/快速测试 | tiny / base | CPU 即可 |
+| 平衡（大多数生产场景） | small / medium | GPU（RTX 3080+） |
+| 最高精度（医疗/法律） | large-v3 | GPU（A10G / A100） |
+
+## Pipeline Role
+
+```
+音频预处理 → FasterWhisper.transcribe() → 带时间戳的转录段落
+```
+
+## Related Concepts
+- [[VoiceActivityDetection]] — 转录前的静音过滤
+- [[SpeakerDiarization]] — 转录结果与说话人标签的合并
+- [[OverlapAwareChunking]] — 长音频分块后逐块转录
+- [[EBUR128LoudnessNormalization]] — 归一化音频确保转录精度
+- [[PIIRedaction]] — 转录后的个人身份信息脱敏
+- [[StructuredTranscriptJSON]] — 转录结果的最终输出格式
+
+## Related Entities
+- [[OpenAIWhisper]] — Faster-Whisper 基于的基础模型
+- [[pyannote.audio]] — 说话人分离，与 Faster-Whisper 配套使用
+
+## Related Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/concepts/Five-Layer-Prompt-Structure.md b/wiki/concepts/Five-Layer-Prompt-Structure.md
new file mode 100644
index 00000000..e6f66510
--- /dev/null
+++ b/wiki/concepts/Five-Layer-Prompt-Structure.md
@@ -0,0 +1,36 @@
+---
+title: "Five-Layer Prompt Structure"
+type: concept
+tags: [prompt-engineering, ai-image-generation, photography]
+last_updated: 2026-05-15
+---
+
+## Definition
+
+AI 图像生成提示词的五层结构化框架，通过分层叠加确保提示词完整覆盖主体、环境、光线、摄影技术和风格美学五大维度，最大限度降低 AI 误解空间。
+
+## Structure
+
+1. **主体描述层（Subject Description Layer）**：主要被摄对象详细描述（人物/物体/场景）、属性/表情/姿态/材质纹理、主客体关系、尺度与比例
+2. **环境设定层（Environment & Setting Layer）**：位置类型（棚拍/户外/城市/自然）、环境细节与纹理、背景处理方式、大气条件
+3. **光线规范层（Lighting Specification Layer）**：光源类型（自然光/人工光）、光方向（Rembrandt/蝴蝶光/分割光等）、光质（硬光/软光/容积光）、色温
+4. **摄影技术层（Technical Photography Layer）**：相机视角（低/平/高/鸟瞰/虫视）、焦距效果（广角畸变/长焦压缩）、景深控制（浅/深/选择性）、曝光风格（高调/低调/HDR）
+5. **风格美学层（Style & Aesthetic Layer）**：摄影类型（人像/时尚/商业/纪实/艺术）、时代风格、后处理风格、参考摄影师
+
+## Key Principle
+
+- **精确性优先**：使用具体摄影术语（如 "f/1.8 bokeh 浅景深" 而非 "背景模糊"）
+- **分层递进**：从主体到风格逐层构建，确保每层信息不遗漏
+- **技术-艺术平衡**：摄影技术参数与艺术方向并重
+
+## Connections
+
+- [[Prompt-Engineering]] 的核心技术方法论
+- [[Photography-Terminology]] 的应用层框架
+- [[Midjourney]] / [[Stable-Diffusion]] / [[DALL-E]] / [[Flux]] 均适用此框架
+
+## Aliases
+
+- Prompt Layering Framework
+- Structured Prompt Framework
+- 五层提示词结构
diff --git a/wiki/concepts/FiveWhys.md b/wiki/concepts/FiveWhys.md
new file mode 100644
index 00000000..83cb8fae
--- /dev/null
+++ b/wiki/concepts/FiveWhys.md
@@ -0,0 +1,76 @@
+---
+title: "Five Whys"
+type: concept
+tags: [root-cause-analysis, incident-management, reliability]
+last_updated: 2026-05-01
+---
+
+## Definition
+5 问法（Five Whys）是一种迭代式根因分析技术，通过连续追问"为什么"（Why）五层（或更多），穿透表面现象，找到系统性根本原因。最初由丰田汽车的大野耐一在精益制造中提出，现广泛应用于可靠性工程和事故管理。
+
+## Core Method
+
+从观察到的**问题（症状）**开始，连续追问"为什么"，直到找到：
+- 一个可采取行动的**根本原因**（root cause）
+- 或一个**系统性缺口**（systemic gap）
+
+### 经典示例
+
+> **问题**：网站宕机了。
+
+| 层级 | 问法 | 回答 |
+|------|------|------|
+| 1 | 为什么网站宕机了？ | 应用服务器无响应 |
+| 2 | 为什么服务器无响应？ | 数据库连接池耗尽 |
+| 3 | 为什么连接池耗尽？ | 一个慢查询锁住了所有连接 |
+| 4 | 为什么慢查询没有被检测？ | 没有查询超时限制和监控 |
+| 5 | **为什么没有超时限制？** | 配置变更流程中没有强制要求 |
+
+> **根因**：配置变更流程缺少数据库安全门（超时限制验证）
+
+## Application in Incident Post-Mortem
+
+在 [[BlamelessPostMortem]] 中的 5 Why 使用：
+1. **保持中立**：避免使用指责性语言
+2. **聚焦系统**：问"系统/流程允许了什么"而非"谁做错了"
+3. **不止五层**：有时需要 6-7 层才能到达系统性根因
+4. **验证**：用 [[FaultTreeAnalysis]] 交叉验证 5 Why 结论
+
+## Relationship with Fault Tree Analysis
+
+| 维度 | Five Whys | Fault Tree Analysis |
+|------|-----------|---------------------|
+| 方向 | 自下而上（症状→根因） | 自上而下（顶事件→叶事件） |
+| 适用场景 | 已知单一事故 | 复杂、多因故障链 |
+| 协作性 | 团队讨论式 | 结构化图形化 |
+| 互补性 | 可结合使用：FTA 识别多因，5 Why 挖掘每个原因 | |
+
+## Key Principles
+
+### Do（应该做）
+- 从具体可观察的事实开始
+- 每个回答都基于证据，而非假设
+- 继续追问直到找到**系统层面**的原因
+- 在团队环境中使用（多元视角更有效）
+
+### Don't（不应该做）
+- 不停在第一个"合理"答案就停止
+- 归咎于个人（"因为某人操作失误"）
+- 假设自动化可以解决所有问题
+- 不验证答案是否与数据一致
+
+## Anti-Patterns
+
+| 错误 | 原因 | 修正 |
+|------|------|------|
+| "因为人员疏忽" | 永远指向根因，但无行动价值 | 追问：系统为什么允许疏忽发生？ |
+| "需要更好的监控" | 泛泛而谈，缺乏可落地性 | 具体：哪种监控，触发什么行动？ |
+| "因为云厂商问题" | 外部归因，无法控制 | 追问：为什么没有灾备方案？ |
+
+## Related Concepts
+- [[BlamelessPostMortem]] — 5 Why 是无责复盘的核心根因分析工具
+- [[FaultTreeAnalysis]] — 可与 5 Why 互补使用的结构化分析
+- [[DORA-Metrics]] — 量化事故影响，为复盘提供数据支撑
+
+## Sources
+- [[engineering-incident-response-commander]]
diff --git a/wiki/concepts/Flash-Loan-Attack.md b/wiki/concepts/Flash-Loan-Attack.md
new file mode 100644
index 00000000..299183f3
--- /dev/null
+++ b/wiki/concepts/Flash-Loan-Attack.md
@@ -0,0 +1,67 @@
+---
+title: "Flash Loan Attack（闪电贷攻击）"
+type: concept
+tags: [blockchain, security, defi, flash-loan, attack]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Flash Loan Attack
+- 闪电贷攻击
+- Flash Loan Exploit
+
+## Definition
+
+闪电贷攻击（Flash Loan Attack）是 DeFi 领域最具破坏力的大规模攻击手段。攻击者在**单笔交易内**借用大量资金（无需抵押），利用这些临时资金操纵市场状态、执行套利或攻击协议，然后在交易结束时归还本金。攻击成本仅为 gas 费用，风险为零。
+
+## Attack Pattern
+
+```
+T0: 攻击合约从 Aave/Uniswap 闪电贷 100M DAI
+T1: 用借来的 DAI 操纵目标协议的预言机价格
+T2: 以操纵后的价格执行有利交易（借款/清算/套利）
+T3: 归还闪电贷本金 + 手续费
+T4: 剩余利润归攻击者所有
+```
+
+## Common Variants
+
+### Oracle Manipulation via Flash Loan
+- 通过闪电贷操纵 AMM 储备金，人为扭曲现货价格
+- 以虚高抵押率借贷后直接清算协议
+- Uniswap V2 现货价格最易操纵，V3 TWAP 和 Chainlink 更安全
+
+### Donate-to-Reserves Attack（Euler Finance 模式）
+- 通过闪电贷操纵内部账户账簿的资产净值
+- 在单笔交易内完成 donate → 触发健康度检查 → 清算套利
+
+### Governance Attack via Flash Loan
+- 闪电贷借入大量治理代币
+- 在快照前买入、投票、快照后卖出
+- 2022 年 Rari Capital 被此方式攻击
+
+## Key Characteristics
+
+- **零成本**：借款无需抵押，只付 gas 费
+- **单笔交易**：所有操作必须在同一区块内完成
+- **EVM 原子性**：交易全成功或全回滚
+
+## Audit Focus
+
+1. 在闪电贷场景下，协议状态是否可以被操纵？
+2. 价格/余额/股份计算是否依赖可被操纵的输入？
+3. 是否存在仅在极端条件下才成立的"不变性"？
+4. 闪电贷还款前后的状态一致性是否被验证？
+
+## Defense
+
+- 使用 TWAP 而非现货价格
+- 使用 Chainlink 等抗操纵的链下预言机
+- 设置最小时间窗口（2-3 区块）后才允许清算
+- 不变性验证（Flash Loan 前后的不变性必须成立）
+
+## Connections
+- [[Oracle Manipulation]] ← 主要载体 ← [[Flash Loan Attack]]
+- [[Blockchain-Security-Auditor]] ← analyzes ← [[Flash Loan Attack]]
+- [[Euler-Finance]] ← victim ← [[Flash Loan Attack]]
diff --git a/wiki/concepts/FlashLoanAttack.md b/wiki/concepts/FlashLoanAttack.md
new file mode 100644
index 00000000..92a756a7
--- /dev/null
+++ b/wiki/concepts/FlashLoanAttack.md
@@ -0,0 +1,43 @@
+---
+title: "FlashLoanAttack"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+Flash Loan（闪电贷）是 DeFi 中的一种无抵押借贷模式，允许用户在单笔交易内借入任意数量的资产，条件是在同一交易的结尾必须归还借款 + 利息。Flash Loan Attack（闪电贷攻击）则是利用闪电贷的特性，在单笔交易中操纵价格、状态或协议逻辑来获取非法收益的攻击方式。
+
+## How Flash Loans Work
+```solidity
+// 用户通过闪电贷借出 1000 ETH
+// 在同一交易内：执行各种操作（交易、借贷、套利）
+// 必须归还 1000 ETH + 手续费，否则整笔交易 revert
+```
+
+关键特性：**无需抵押**（因为资金在同一交易内流转），但这也意味着**协议无法在交易中途检查清算状态**。
+
+## Attack Patterns
+
+### 1. 价格操纵（Price Manipulation）
+- 在借贷协议中：先借出大量资产 → 操纵预言机价格 → 以超低抵押率借出更多资产 → 归还闪电贷
+- 案例：[[Euler Finance]]（2023）、Cream Finance（多次）
+
+### 2. 治理攻击（Governance Attack）
+- 通过闪电贷获得大量治理代币
+- 在单笔交易内发起并通过恶意提案
+- 案例：Beanstalk（2022）
+
+### 3. 重入攻击（通过闪电贷）
+- 与 reentrancy 结合，放大攻击规模
+
+## Defense Mechanisms
+1. **TWAP（时间加权平均价格）预言机**：使用时间窗口内的平均价格，而非即时价格
+2. **借贷健康度实时检查**：在每笔清算操作前验证抵押率
+3. **闪电贷攻击监控**：链上监控异常大额闪电贷 + 后续清算模式
+4. **最小清算门槛**：设置合理的清算参数，防止微小偏差导致清算
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
+- [[Euler-Finance]]
+- [[blockchain-security-auditor]]
diff --git a/wiki/concepts/Formal-Verification.md b/wiki/concepts/Formal-Verification.md
new file mode 100644
index 00000000..c08551d8
--- /dev/null
+++ b/wiki/concepts/Formal-Verification.md
@@ -0,0 +1,53 @@
+---
+title: "Formal Verification（形式化验证）"
+type: concept
+tags: [blockchain, security, smart-contract, formal-verification]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Formal Verification
+- 形式化验证
+
+## Definition
+
+形式化验证（Formal Verification）是通过数学方法严格证明智能合约关键属性正确性的技术手段。与测试只能穷举有限场景不同，形式化验证可以证明某个属性在**所有可能的输入和状态**下均成立。
+
+## Core Methods
+
+### Invariant Specification（不变式规范）
+定义协议的关键属性，用数学语言表达"协议必须始终保持的真理"：
+- 总份额 × 每股净值 = 总资产（份额不变性）
+- 借贷后抵押率必须 ≥ 清算阈值（健康度不变性）
+- 管理员无法直接提取用户资金（权限不变性）
+
+### Symbolic Execution（符号执行）
+将合约函数参数替换为符号变量而非具体值，遍历所有可能的执行路径：
+- 发现边界条件和组合触发场景
+- Certora Prover、KEVM、Mythril 使用此方法
+
+### Equivalence Checking（等价性检验）
+验证合约实现与形式化规范是否等价：
+- 高风险升级前后必须进行
+- 防止修复一个漏洞引入另一个
+
+## Key Tools
+
+| Tool | Method | Focus |
+|------|--------|-------|
+| [[Certora]] | 符号执行 | Solidity 合约属性证明 |
+| [[Halmos]] | 字节码符号执行 | 字节码级别验证（不依赖源码） |
+| KEVM | 形式化 EVM | EVM 操作语义形式化模型 |
+| Medusa | 符号执行 | 并行化模糊测试 |
+
+## Relationship to Audit
+
+- 形式化验证是 **Slither/Mythril/Echidna 等工具的补充**，不是替代
+- 高风险协议（> $10M TVL）在审计报告中通常包含形式化验证章节
+- 形式化验证的局限性：无法验证的需求规范错误、依赖外部状态
+
+## Connections
+- [[Blockchain-Security-Auditor]] ← uses methodology ← [[Formal Verification]]
+- [[Slither]] ← lower-level analysis ← [[Formal Verification]]
+- [[Echidna]] ← property-based testing ← [[Formal Verification]]
diff --git a/wiki/concepts/Frequency-Cap.md b/wiki/concepts/Frequency-Cap.md
new file mode 100644
index 00000000..5e36caec
--- /dev/null
+++ b/wiki/concepts/Frequency-Cap.md
@@ -0,0 +1,52 @@
+---
+title: "Frequency Cap"
+type: concept
+tags: ["frequency-cap", "display", "paid-media", "optimization", "brand-safety"]
+sources: ["paid-media-programmatic-buyer"]
+last_updated: 2026-04-26
+---
+
+## Definition
+
+频次上限（Frequency Cap）是一种广告投放控制机制，限制同一用户在特定时间段内看到同一广告或广告活动的次数。其目的是在最大化品牌触达的同时，防止用户因过度曝光而产生广告疲劳（Ad Fatigue）或负面品牌联想。
+
+## Why Frequency Cap Matters
+
+- **防止广告疲劳**：过度曝光同一创意会导致用户产生逆反心理，降低点击率和转化意愿
+- **预算效率**：避免对已转化用户重复投放浪费预算
+- **品牌保护**：过度曝光可能引发用户对品牌的负面情绪
+- **Reach vs. Frequency 平衡**：频次过高会牺牲独立触达人数
+
+## Setting Frequency Caps
+
+### Industry Benchmarks
+
+| 活动类型 | 推荐频次 | 周期 |
+|---------|---------|------|
+| Brand Awareness（品牌认知） | 5-10 次/周 | 周 |
+| Consideration（考虑阶段） | 3-7 次/周 | 周 |
+| Retargeting（再营销） | 7-14 次/周 | 周 |
+| DR / Performance（直接响应） | 1-3 次/天 | 天 |
+
+### Optimization Principles
+
+- **跨平台协调**：在 GDN、DSP、社交平台之间协调频次，避免总体超量
+- **Creative Rotation**：高频位置需要更多创意变体以防止疲劳
+- **Window Optimization**：根据转化路径调整归因窗口和频次窗口
+- **Audience Segmentation**：不同受众分层设置不同频次上限
+
+## Frequency Pacing Models
+
+- **Even Pacing**：预算平均分配到活动周期，保持稳定频次
+- **Front-loaded**：前期集中投放，快速达到目标频次
+- **Decaying**：随时间递减频次，配合创意新鲜度
+
+## Cross-Platform Frequency Management
+
+多平台同时投放时，必须通过[[Cross-Platform Reach and Frequency]]管理避免受众重叠浪费：
+- 使用共同的受众识别码（Cookie、Device ID、CRM ID）
+- 在投放前计算预期总频次，设定平台间协调的频次上限
+- 利用[[Audience Overlap Analysis]]识别和排除重叠受众
+
+## Sources
+- [[paid-media-programmatic-buyer]]
diff --git a/wiki/concepts/Functionalism.md b/wiki/concepts/Functionalism.md
new file mode 100644
index 00000000..39698db4
--- /dev/null
+++ b/wiki/concepts/Functionalism.md
@@ -0,0 +1,25 @@
+---
+title: "Functionalism"
+type: concept
+tags: ["anthropology", "functionalism", "malinowski", "durheim", "social-cohesion"]
+last_updated: 2026-04-25
+---
+
+## Definition
+功能主义——文化的每个元素都服务于满足人类**基本需求**（生理、社会、安全、认同）或维持**社会凝聚力**的分析框架。
+
+## Core Framework
+- **基本需求满足**：生理需求→经济系统、繁殖需求→亲属制度、安全需求→法律/防御、教育需求→文化传承
+- **社会凝聚力**：宗教、仪式、道德规范通过强化集体意识（collective consciousness）维持社会团结（Durkheim）
+- **文化适应**：文化实践是种群适应环境的工具（Malinowski）
+
+## Key Thinkers
+- [[Bronislaw-Malinowski]]（功能主义创始人）
+- Emile Durkheim（社会凝聚力理论）
+- A.R. Radcliffe-Brown（结构功能主义）
+
+## Connections
+- [[Anthropologist-Agent]] ← uses_framework ← [[Functionalism]]
+- [[Gift-Economy]] ← extends ← [[Functionalism]]
+- [[Practice-Theory]] ← critiques ← [[Functionalism]]
+- [[Structuralism]] ← challenges ← [[Functionalism]]
diff --git a/wiki/concepts/GAAP-Compliance.md b/wiki/concepts/GAAP-Compliance.md
new file mode 100644
index 00000000..67cdf695
--- /dev/null
+++ b/wiki/concepts/GAAP-Compliance.md
@@ -0,0 +1,52 @@
+---
+title: "GAAP Compliance"
+type: concept
+tags: [finance, accounting, compliance]
+sources: [finance-bookkeeper-controller]
+last_updated: 2026-05-02
+---
+
+## Definition
+GAAP（Generally Accepted Accounting Principles，通用会计准则）是一套用于编制财务报表的公认会计原则和标准。GAAP 合规确保财务信息的一致性、可比性和透明度。
+
+## Core Principle
+> "GAAP compliance is the baseline. Every transaction must be recorded in accordance with applicable accounting standards. No exceptions, no shortcuts."
+> — Dana, Bookkeeper & Controller Agent
+
+## Key Standards
+
+### ASC 606 — Revenue Recognition
+- 合同审查与识别
+- 履约义务（Performance Obligations）识别
+- 交易价格分配
+- 收入确认时点判断
+- 合同变更处理
+- 递延收入管理
+
+### ASC 842 — Lease Accounting
+- 租赁分类（融资租赁 vs 经营租赁）
+- 使用权资产（ROU Asset）和租赁负债计算
+- 租赁变更的重新计量
+- 短期租赁豁免
+
+### ASC 718 — Stock-Based Compensation
+- 期权估值
+- 费用确认时点
+- 修改会计处理
+
+### ASC 805 — Business Combinations
+- 购买价格分配（PPA）
+- 商誉计算
+- 或有对价公允价值
+
+## Compliance Requirements
+- 所有交易必须按适用会计准则记录
+- 前期调整必须披露
+- 重大事项必须单独确认
+- 财务报告必须附有附注说明
+
+## Related Concepts
+- [[Revenue Recognition ASC606]]
+- [[Month-End-Close-Process]]
+- [[Journal Entry]]
+- [[Audit Readiness]]
diff --git a/wiki/concepts/GAS.md b/wiki/concepts/GAS.md
new file mode 100644
index 00000000..ff80b63c
--- /dev/null
+++ b/wiki/concepts/GAS.md
@@ -0,0 +1,57 @@
+---
+title: "GAS (Gameplay Ability System)"
+type: concept
+tags: ["unreal-engine", "gameplay", "abilities", "networking"]
+sources: ["unreal-multiplayer-architect", "unreal-systems-engineer"]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Gameplay Ability System
+- 游戏能力系统
+- GAS
+
+## 定义
+GAS 是 UE5 的模块化能力框架，提供技能、属性、效果（GameplayEffect）的标准化实现，内置网络预测和复制支持。
+
+## 核心组件
+
+### Ability (UGameplayAbility)
+- 可激活的游戏能力（技能、攻击、法术）
+- 支持本地和预测激活
+
+### AttributeSet (UAttributeSet)
+- 管理角色属性（生命值、魔法值、攻击力等）
+- 属性自动复制
+
+### GameplayEffect (UGameplayEffect)
+- 属性的修改效果（buff、debuff、伤害、治疗）
+- 可配置持续时间、周期、堆叠
+
+### AbilitySystemComponent (UAbilitySystemComponent)
+- 能力系统的核心组件
+- 管理 Ability 和 AttributeSet 的生命周期
+
+## 网络预测
+GAS 内置 `FPredictionKey` 支持：
+- 客户端预测能力激活
+- 服务器确认或回滚
+- 支持 `PredictionKey::NewManagedNetGUID()`
+
+## 双初始化路径
+```cpp
+// 服务器路径
+void AMyCharacter::PossessedBy(AController* NewController) {
+    AbilitySystemComponent->InitAbilityActorInfo(GetPlayerState(), this);
+}
+
+// 客户端路径
+void AMyCharacter::OnRep_PlayerState() {
+    AbilitySystemComponent->InitAbilityActorInfo(GetPlayerState(), this);
+}
+```
+
+## 相关概念
+- [[Actor Replication]] — GAS 属性的复制机制
+- [[Network Prediction]] — GAS 内置的网络预测支持
+- [[Server-Authoritative Model]] — GAS 的服务器验证原则
diff --git a/wiki/concepts/GTM-Phase-Gate.md b/wiki/concepts/GTM-Phase-Gate.md
new file mode 100644
index 00000000..c28abcee
--- /dev/null
+++ b/wiki/concepts/GTM-Phase-Gate.md
@@ -0,0 +1,53 @@
+---
+title: "GTM Phase Gate"
+type: concept
+tags: [china, marketing, gtm, phased-launch, product-launch]
+sources: [marketing-china-market-localization-strategist]
+last_updated: 2026-04-30
+---
+
+## Definition
+GTM Phase Gate（产品上市分阶段门控模型）是 [[China Market Localization Strategist]] 提出的六阶段 P0-P5 产品上市框架，将从趋势信号验证到品牌护城河建设的完整产品生命周期分为六个递进阶段，每个阶段有明确的进入标准、交付物和退出门控。
+
+## Six Phases
+
+| 阶段 | 名称 | 周期 | 核心任务 |
+|------|------|------|---------|
+| P0 | 信号验证（Signal Validation） | Week 1-2 | 趋势确认、TAM/SAM/SOM 规模测算、竞品格局 |
+| P1 | 种草内容（Seed Content） | Week 3-4 | KOC 种草、内容测试、初始社区建立 |
+| P2 | 渠道激活（Channel Activation） | Week 5-8 | 平台专属上市、付费投放校准 |
+| P3 | 规模化（Scale） | Week 9-16 | 多平台扩张、直播电商整合、供应链就绪 |
+| P4 | 优化（Optimize） | Week 17-24 | 数据驱动迭代、流失预防、私域深化 |
+| P5 | 成熟运营（Mature Operations） | Week 25+ | 品牌护城河建设、忠诚度计划、品类扩张 |
+
+## Phase Gate Criteria（门控标准）
+
+每个阶段包含明确的 Go/No-Go 决策标准：
+
+**P0 → P1 门控**：趋势数据来自 3+ 平台、交叉验证完成、TAM/SAM/SOM 有据可查、平台选择有数据支撑
+
+**P1 → P2 门控**：KOC 候选名单 ≥ 10 个、5 种内容变体完成 A/B 测试、基线互动指标记录在案、PMF 假设被验证或否定
+
+**P2 → P3 门控**：广告账户开立并校准、日预算分配就绪、有机+付费内容日历发布、直播测试排期、私域漏斗可运作
+
+## Go-to-Market Funnel Integration
+
+GTM Phase Gate 嵌入 [[China Marketing Funnel]] 的各阶段：
+
+- **P0** → 漏斗顶端（趋势识别）
+- **P1-P2** → 漏斗中部（种草→激活）
+- **P3** → 漏斗底部（转化）
+- **P4-P5** → 留存与复购（私域运营）
+
+## Key Principles
+- **资源优化**：优先适配 1-3 人小团队（一人公司模型）
+- **可执行性**：每阶段交付物必须在 7 天内可执行
+- **量化决策**：每个门控决策必须有数据支撑，不可凭直觉通过
+- **闭环迭代**：[[Trend-To-Action]] 框架输出直接注入各阶段的优先级决策
+
+## Relationship to Other Concepts
+- [[Trend-To-Action]]：GTM Phase Gate 的数据输入层，每阶段由趋势信号触发
+- [[China Marketing Funnel]]：GTM Phase Gate 的宏观框架参照
+- [[KOC Seeding]]：P1 阶段的核心执行策略
+- [[Live Commerce]]：P3 阶段规模化转化的核心手段
+- [[私域运营]]：P4-P5 阶段留存运营的核心方法
diff --git a/wiki/concepts/Gamification-System.md b/wiki/concepts/Gamification-System.md
new file mode 100644
index 00000000..93f8480d
--- /dev/null
+++ b/wiki/concepts/Gamification-System.md
@@ -0,0 +1,50 @@
+---
+title: "Gamification System"
+type: concept
+tags: [gamification, engagement, achievement, user-retention]
+sources: [design-whimsy-injector]
+last_updated: 2026-05-15
+---
+
+# Gamification System
+
+## Definition
+
+游戏化成就系统（Gamification Achievement System）通过徽章解锁、彩蛋发现、进度庆祝等机制激励用户探索和深度使用，由 [[Whimsy-Injector]] 设计实现。
+
+## Core Components
+
+- **Achievement System（成就系统）**：定义成就类型（首次点击/彩蛋发现/任务大师），通过庆祝动画激励用户
+- **Easter Egg Discovery（彩蛋发现系统）**：Konami Code、点击序列、特定元素触发隐藏功能
+- **Progress Celebration（进度庆祝）**：任务完成、里程碑到达时的动画反馈
+- **Rainbow Mode（彩虹模式）**：彩蛋触发的全页特效
+
+## Whimsy Injector 的游戏化设计原则
+
+- 成就系统通过激励探索建立社区感
+- 彩蛋策略奖励用户好奇心和深入探索
+- 进度庆祝维持长期动机而非短期刺激
+- 设计确保愉悦但不造成上瘾模式
+
+## Example Implementation
+
+```javascript
+class WhimsyAchievements {
+  unlock(achievementId) {
+    // 成就解锁逻辑
+  }
+  showCelebration(achievement) {
+    // 庆祝动画展示
+  }
+}
+```
+
+## Relationship to Other Concepts
+
+- [[Gamification]]：Gamification System 是 Gamification 理论在 Whimsy Injector 中的具体实现
+- [[Micro-Interaction-Design]]：进度庆祝动画属于微交互范畴
+- [[Inclusive-Delight-Design]]：游戏化必须遵循包容性设计原则
+
+## Source
+
+- [[Whimsy-Injector]] — 游戏化系统设计核心来源
diff --git a/wiki/concepts/Gamification.md b/wiki/concepts/Gamification.md
index 4621b3b0..1e8cf81d 100644
--- a/wiki/concepts/Gamification.md
+++ b/wiki/concepts/Gamification.md
@@ -1,30 +1,51 @@
----
-title: "Gamification"
-type: concept
-tags: [engagement, motivation, game-design, user-retention]
-last_updated: 2026-04-20
----
-
-## Definition
-游戏化（Gamification）指将游戏设计元素（如积分、徽章、排行榜、成就系统、可变量奖励循环）应用于非游戏场景，以提升用户参与度和行为动机。
-
-## Core Elements
-- **积分/点数**：量化用户进步与贡献
-- **徽章/成就**：里程碑认可与荣誉激励
-- **排行榜**：社交比较驱动竞争
-- **可变量奖励**：类似老虎机的随机奖励机制，维持持续参与
-- **即时正强化**：每次完成行为后立即反馈
-
-## Applications
-- 完成任务解锁成就徽章
-- 连续打卡积分累计
-- 微任务冲刺可视化进度条
-- [[Momentum Nudge]] 中的庆祝机制
-
-## Related Concepts
-- [[Behavioral Psychology]]：游戏化的心理学理论基础
-- [[Default Bias]]：可与默认选项结合的游戏化设计
-- [[Cognitive Load Reduction]]：游戏化需控制认知负荷避免复杂化
-
-## Source
-- [[Behavioral Nudge Engine]] — 核心应用场景
+---
+title: "Gamification"
+type: concept
+tags: [engagement, ux, design, retention]
+sources: [design-whimsy-injector, product-behavioral-nudge-engine]
+last_updated: 2026-05-15
+---
+
+# 游戏化（Gamification）
+
+## Aliases
+- Gamification
+- 游戏化设计
+- 成就系统
+
+## 定义
+
+游戏化是将游戏设计元素（如成就、徽章、进度条、排行榜、奖励机制）应用于非游戏场景的设计策略，核心目标是提升用户参与度、动机和留存率。关键区分：游戏化≠做游戏，而是借鉴游戏的激励机制来解决真实业务问题。
+
+## 核心要素
+
+| 要素 | 作用 | 示例 |
+|------|------|------|
+| 成就系统（Achievements） | 里程碑认可，激励探索 | "完成首次购买：新手礼" |
+| 进度可视化 | 降低长任务的心理阻力 | 进度条、步骤指示器 |
+| 反馈即时性 | 强化行为-奖励关联 | 完成动作→立即庆祝动画 |
+| 排行榜（Leaderboards） | 社会认同激励 | 周活跃榜、积分排行 |
+| 虚拟奖励 | 低成本高情感价值的激励 | 徽章、称号、表情 |
+
+## 设计原则
+
+- **动机的层次**：外在动机（积分/徽章）→ 内在动机（成就感/社区归属）
+- **非强迫性参与**：游戏化不应使用户感到被迫使用产品
+- **无伤害激励**：避免设计导致过度使用或成瘾的机制
+- **包容性设计**：成就系统需考虑不同能力和文化背景的用户
+
+## 风险与局限
+
+- **过度游戏化**：过多奖励稀释内在动机（过度理由效应）
+- **竞争焦虑**：排行榜对低排名用户可能产生负面情绪
+- **文化差异**：某些奖励/惩罚机制在不同文化背景下效果迥异
+
+## 应用场景
+
+- [[design-whimsy-injector]] 交付了基于 JavaScript 的成就系统实现代码，包含成就解锁、庆祝动画、Konami Code 复活节彩蛋等游戏化组件
+
+## 相关概念
+
+- [[design-whimsy-injector]]：游戏化元素的具体实现者
+- [[Micro-Interaction]]：成就解锁的庆祝动画本身是微交互的一种
+- [[Inclusive-Delight]]：游戏化设计需避免对残障用户产生障碍
diff --git a/wiki/concepts/GapAssessment.md b/wiki/concepts/GapAssessment.md
new file mode 100644
index 00000000..247d112e
--- /dev/null
+++ b/wiki/concepts/GapAssessment.md
@@ -0,0 +1,53 @@
+---
+title: "Gap Assessment"
+type: concept
+tags: []
+sources: [compliance-auditor]
+last_updated: 2026-04-30
+---
+
+# Gap Assessment
+
+## Definition
+
+差距评估（Gap Assessment）是对照目标合规框架（如 SOC 2、ISO 27001）要求，系统性地评估组织当前安全态势与目标状态之间差距的分析过程。
+
+## Core Components
+
+### 标准格式（ComplianceAuditor 定义）
+每个差距发现必须包含：
+1. **控制引用（Control Reference）**：框架中对应的控制项编号（如 CC6.1）
+2. **当前状态（Current State）**：组织现有的实际状态
+3. **目标状态（Target State）**：满足控制要求的目标状态
+4. **修复步骤（Remediation）**：具体可执行的修复行动
+5. **估算工作量（Effort）**：预计完成所需时间
+6. **优先级（Priority）**：基于风险和审计时间线的优先级
+
+### 评分标准
+- **Ready (100/100)**：完全满足要求
+- **Partial**：部分满足，存在差距
+- **Non-Compliant**：完全不满足要求
+
+## Deliverable Format
+```markdown
+## Gap Assessment Report
+
+**Assessment Date**: YYYY-MM-DD
+**Target Certification**: SOC 2 Type II
+**Audit Period**: YYYY-MM-DD to YYYY-MM-DD
+
+## Executive Summary
+- Overall readiness: X/100
+- Critical gaps: N
+- Estimated time to audit-ready: N weeks
+
+## Findings by Control Domain
+```
+
+## Related Concepts
+- [[SOC 2]]：主要目标框架
+- [[Continuous Compliance]]：评估完成后的持续监控机制
+- [[Evidence Collection]]：差距修复后需要收集的证据
+
+## Related Sources
+- [[compliance-auditor]]
diff --git a/wiki/concepts/GasOptimization.md b/wiki/concepts/GasOptimization.md
new file mode 100644
index 00000000..d1e87eb1
--- /dev/null
+++ b/wiki/concepts/GasOptimization.md
@@ -0,0 +1,69 @@
+---
+title: "GasOptimization"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+Gas Optimization 是指在 EVM 智能合约开发中，通过技术手段降低合约执行和部署的 Gas 消耗，直接减少用户费用和以太坊网络的负担。由于每个区块的 Gas 上限固定，优化 Gas 消耗也是提高协议吞吐量的关键。
+
+## Core Gas Costs (EVM)
+
+| 操作 | Cold Access | Warm Access |
+|------|-------------|-------------|
+| SLOAD（读取存储） | 2100 gas | 100 gas |
+| SSTORE new（写入新槽） | 20000 gas | - |
+| SSTORE update（更新槽） | 5000 gas | 2900 gas |
+| CALL（外部调用） | 2600 gas + 被调函数 gas | 100 gas |
+| CREATE（创建合约） | 32000 gas | - |
+
+## Key Patterns
+
+### 1. Storage Packing（存储打包）
+将多个小类型打包进同一 32 字节槽，节省 SSTORE 次数：
+```solidity
+// ✅ Good: 2 个变量共享一个槽
+struct PackedData {
+    uint128 amount;  // 16 bytes
+    uint128 id;      // 16 bytes → 同槽
+}
+```
+
+### 2. Calldata over Memory
+```solidity
+// ✅ Good: calldata 只读，节省拷贝
+function processIds(uint256[] calldata ids) external pure {}
+
+// ❌ Bad: memory 需要拷贝到内存
+function processIds(uint256[] memory ids) external pure {}
+```
+
+### 3. Custom Errors over Require Strings
+```solidity
+// ✅ Good: 节省 ~50 gas/revert
+error InsufficientBalance(uint256 requested, uint256 available);
+require(balance >= amount, "Insufficient balance");
+
+// ❌ Bad: 错误信息存储在字节码中
+require(balance >= amount, "Insufficient balance for this operation");
+```
+
+### 4. Immutable over Constant（运行时）
+```solidity
+uint256 public constant MAX_SUPPLY = 1_000_000;     // 编译时常量
+address public immutable owner;                      // 运行时只设置一次
+```
+
+### 5. External over Public
+- External 函数：调用时参数通过 calldata 传递
+- Public 函数：需要检查是否内部调用，参数通过 memory 传递
+- 仅被内部调用 → public；仅被外部调用 → external
+
+### 6. Unchecked Math（Safe Math）
+```solidity
+unchecked { counter++; }  // 已知 counter 不会溢出
+```
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
diff --git a/wiki/concepts/Generative-Engine-Optimization.md b/wiki/concepts/Generative-Engine-Optimization.md
index e9b71009..435fa30b 100644
--- a/wiki/concepts/Generative-Engine-Optimization.md
+++ b/wiki/concepts/Generative-Engine-Optimization.md
@@ -1,46 +1,41 @@
 ---
-title: "Generative Engine Optimization (GEO)"
+title: "Generative Engine Optimization"
 type: concept
-tags: ["AI", "SEO", "marketing", "visibility", "generative-AI"]
-last_updated: 2026-04-26
+tags: ["SEO", "AI", "marketing", "GEO"]
+sources: ["marketing-ai-citation-strategist"]
+last_updated: 2026-04-30
 ---
 
 ## Definition
 
-Generative Engine Optimization (GEO) 是针对生成式 AI 引擎的可见性优化策略，通过信号工程（signal engineering）提升品牌内容在 AI 生成答案中被引用的概率。GEO 是 AEO（Answer Engine Optimization）的更广泛范畴，不仅限于问答式 AI，而是覆盖所有类型的生成式 AI 引擎。
+Generative Engine Optimization（GEO，生成式引擎优化）：通过改善内容信号来提升 AI 推荐引擎对品牌内容引用概率的技术实践。与 AEO（Answer Engine Optimization）密切相关，GEO 更强调生成式 AI 的整体可见性策略。
 
-## Core Pillars
+## Relationship with AEO
 
-1. **Authority Signals**：建立内容权威性（引用来源数量、内容深度、专家署名）
-2. **Structure Signals**：使用 AI 友好的内容结构（标题层级、列表、表格、Schema）
-3. **Entity Signals**：清晰的实体标注和知识图谱关联
-4. **Quantity Signals**：大量相关内容覆盖，增大被 AI 发现和引用的概率
-5. **Distinctiveness Signals**：差异化内容，避免同质化
+- **AEO**：专注于答案引擎（直接给出答案的 AI 系统，如 Perplexity）的引用优化
+- **GEO**：涵盖所有生成式 AI 场景下的可见性，包括 ChatGPT、Claude 等合成式 AI 助手
 
-## GEO Techniques
+两者共同构成 AI 时代内容可见性的完整策略框架。
 
-### Quantitative Expansion
-创建大量相关主题的补充内容，覆盖长尾查询，增加被 AI 引用的表面积。
+## Core Methods
 
-### Quotable Generation
-生成容易被直接引用的精炼陈述，适合作为 AI 答案中的引用来源。
+1. **Entity Optimization**：确保品牌在 AI 知识图谱中清晰可识别（Wikipedia/Wikidata/Crunchbase）
+2. **Citation Pattern Engineering**：围绕用户实际输入 AI 的查询模式设计内容
+3. **Multi-Platform Strategy**：针对各平台的差异化内容适配
+4. **Benchmark-Driven Iteration**：建立引用率基准，持续测量和迭代
 
-### Statistical Amplification
-在内容中加入数据、统计数字、研究发现——AI 倾向于引用有具体数字支撑的内容。
+## Prompt Patterns
 
-### Technical Style Matching
-研究目标 AI 平台的引用偏好，调整内容风格（ChatGPT 偏好权威性来源，Claude 偏好平衡分析，Perplexity 偏好时效性和多样性）。
-
-### Source Diversity
-跨多个平台和渠道发布内容，增大被不同 AI 引擎训练数据覆盖的概率。
+| Pattern | Content Type | Example Query |
+|---------|-------------|---------------|
+| "Best X for Y" | 对比内容 | "Best CRM for startups" |
+| "X vs Y" | 专页对比 | "HubSpot vs Salesforce" |
+| "How to choose X" | 买家指南 | "How to choose a project management tool" |
+| "What is the difference between X and Y" | 清晰定义 | "What's the difference between SEO and AEO" |
+| "Recommend a X that does Y" | 功能导向 | "Recommend a CRM with email tracking" |
 
 ## Related Concepts
 
-- [[Answer Engine Optimization (AEO)]]：GEO 的子集，专注问答式 AI
-- [[Citation Rate]]：衡量 GEO 效果的量化指标
-- [[Entity Optimization]]：GEO 的核心技术之一
-- [[Platform-Specific Patterns]]：不同 AI 引擎的引用偏好差异
-
-## Sources
-
-- [[AI Citation Strategist]]
+- [[Answer Engine Optimization]]（AEO）— GEO 的子集/前身
+- [[Citation Audit Scorecard]] — GEO 效果的可量化评估工具
+- [[Prompt Pattern Engineering]] — GEO 的核心内容策略方法
diff --git a/wiki/concepts/Genre-Specific-Prompt-Patterns.md b/wiki/concepts/Genre-Specific-Prompt-Patterns.md
new file mode 100644
index 00000000..7e27ed30
--- /dev/null
+++ b/wiki/concepts/Genre-Specific-Prompt-Patterns.md
@@ -0,0 +1,129 @@
+---
+title: "Genre-Specific Prompt Patterns"
+type: concept
+tags: [prompt-engineering, ai-image-generation, photography-genre]
+last_updated: 2026-05-15
+---
+
+## Definition
+
+针对不同摄影体裁（人像、产品、风光、时尚等）的专业化提示词模板，通过体裁特有的结构和参数组合，实现各类型 AI 生成图像的专业级输出。
+
+## Portrait Photography Pattern
+
+### 模板结构
+```
+[主体描述：年龄/种族/表情/着装] |
+[姿态与肢体语言] |
+[背景处理方式] |
+[布光设置：主光/补光/轮廓光/发丝光] |
+[相机参数：焦距/光圈/视角] |
+[风格：编辑/时尚/商业/艺术] |
+[色彩调性与情绪] |
+[参考摄影师风格]
+```
+
+### 典型参数
+- 焦距：85mm / 50mm（全身 35mm）
+- 光圈：f/1.2–f/2.0（浅景深人像）
+- 视角：eye level（平视）
+- 布光：Rembrandt / Butterfly / Loop
+- 景深：shallow DOF, creamy bokeh
+
+### 示例关键词
+- "cinematic portrait lighting", "Rembrandt triangle on cheek", "creamy bokeh background", "85mm f/1.4", "eye-level portrait"
+
+---
+
+## Product Photography Pattern
+
+### 模板结构
+```
+[产品描述：材质/工艺/细节] |
+[表面/背景描述] |
+[布光：柔光箱位置/反光板/渐变] |
+[相机：微距/标准/角度/距离] |
+[拍摄类型：Hero Shot/Lifestyle/Detail/Scale Context] |
+[品牌美学对齐] |
+[后期处理：干净/氛围/鲜艳]
+```
+
+### 典型参数
+- 焦距：100mm 微距 / 90mm（产品人像）
+- 光圈：f/8–f/11（整体清晰）
+- 布光：Large softbox + Strip lights
+- 景深：Focus stacked（全清晰）
+
+### 示例关键词
+- "hero shot", "softbox overhead gradient", "edge definition strip lights", "commercial advertising quality", "clean post-processing"
+
+---
+
+## Landscape Photography Pattern
+
+### 模板结构
+```
+[地理位置与地质特征] |
+[时间与大气条件] |
+[天气与天空处理] |
+[前景/中景/远景元素] |
+[相机：广角/深焦/全景] |
+[光质与方向] |
+[色彩调性：自然/增强/戏剧性] |
+[风格：纪实/艺术/空灵]
+```
+
+### 典型参数
+- 焦距：16–35mm（广角）
+- 光圈：f/11–f/16（深景深）
+- 视角：Low angle / eye level
+- 景深：front-to-back sharp focus
+
+### 示例关键词
+- "golden hour light", "deep focus", "wide angle landscape", "dramatic sky", "foreground interest", "ND filter long exposure"
+
+---
+
+## Fashion Photography Pattern
+
+### 模板结构
+```
+[模特描述与表情] |
+[服装细节与造型] |
+[妆发方向] |
+[场地/布景设计] |
+[姿态风格：编辑/商业/前卫] |
+[布光：戏剧性/柔和/混合] |
+[相机运动：静态/动态] |
+[杂志/品牌 campaign 美学参考]
+```
+
+### 典型参数
+- 焦距：85mm（特写）/ 35mm（全身）
+- 光圈：f/1.4–f/4.0（视构图需求）
+- 视角：varied（多样化）
+- 景深：selective focus
+
+### 示例关键词
+- "fashion editorial", "high fashion lighting", "avant-garde styling", "magazine spread aesthetic", "dramatic pose", "Haute couture"
+
+---
+
+## Cross-Genre Principles
+
+1. **主体清晰**：每种体裁的核心被摄对象必须首要明确
+2. **光线匹配**：布光方式与体裁风格一致（人像用柔光，产品用可控光，时尚用戏剧光）
+3. **相机参数对应体裁**：人像浅景深（f/1.4），产品深景深（f/8+），风光超深焦（f/11+）
+4. **参考引导**：引用体裁内知名摄影师风格提升 AI 输出专业度
+
+## Connections
+
+- [[Five-Layer-Prompt-Structure]] 在各体裁中的具体应用
+- [[Photography-Terminology]] 提供各体裁的专业术语
+- [[Prompt-Engineering]] 的体裁适配层
+
+## Aliases
+
+- 体裁专属提示词模板
+- Photography Genre Templates
+- Domain-Specific Prompt Patterns
diff --git a/wiki/concepts/Gift-Economy.md b/wiki/concepts/Gift-Economy.md
new file mode 100644
index 00000000..0e5a6a8e
--- /dev/null
+++ b/wiki/concepts/Gift-Economy.md
@@ -0,0 +1,25 @@
+---
+title: "Gift Economy"
+type: concept
+tags: ["anthropology", "economy", "reciprocity", "exchange", "mauss"]
+last_updated: 2026-04-25
+---
+
+## Definition
+礼物经济——基于**互惠义务**（reciprocal obligation）的交换系统，给予、接受、回报的三段循环是社会关系的基础纽带，而非市场竞争。
+
+## Core Framework
+- **礼物之灵（hau）**：接受礼物即承担回报义务，礼物具有社会性的"灵魂"使回报不可避免
+- **Potlatch**：北太平洋西北岸部落的大型仪式性财富毁坏展示，通过"给予羞辱"来确立社会地位
+- **库拉圈（Kula Ring）**：特罗布里恩群岛的跨岛礼物交换圈，交换的贝壳和项链本身无实用价值，但建立和维持社会关系网络
+
+## Key Thinkers
+- [[Marcel-Mauss]]（《礼物》作者，奠基人）
+- [[Bronislaw-Malinowski]]（库拉圈研究）
+- Karl Polanyi（经济人类学）
+
+## Connections
+- [[Anthropologist-Agent]] ← uses_framework ← [[Gift-Economy]]
+- [[Polanyi-Exchange]] ← foundational ← [[Gift-Economy]]
+- [[Functionalism]] ← grounds ← [[Gift-Economy]]
+- [[Social-Cohesion]] ← mechanism ← [[Gift-Economy]]
diff --git a/wiki/concepts/Go-to-Market-Brief.md b/wiki/concepts/Go-to-Market-Brief.md
new file mode 100644
index 00000000..ba4384cf
--- /dev/null
+++ b/wiki/concepts/Go-to-Market-Brief.md
@@ -0,0 +1,36 @@
+---
+title: "Go-to-Market (GTM) Brief"
+type: concept
+tags: ["product-management", "launch", "gtm", "marketing"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- GTM Brief
+- Go-to-Market Plan
+- 发布计划
+- 市场推广计划
+
+## Definition
+Go-to-Market Brief（市场推广计划）—— 在产品功能正式发布（GA）前，由产品经理主导制定的跨部门协调文档，定义目标受众、价值主张、发布渠道、团队职责和成功标准，确保工程、产品、营销、销售和客服团队在发布前完成准备工作。
+
+## Core Components
+1. **发布什么**（What We're Launching）：一句话 + 一段描述
+2. **目标受众**（Target Audience）：按细分市场划分（首要/次要/扩展），含规模、价值主张和触达渠道
+3. **核心价值主张**（Core Value Proposition）：单行标语 + 按受众分组的差异化信息
+4. **发布检查清单**（Launch Checklist）：按工程/产品/营销/销售 CS 分组
+5. **成功标准**（Success Criteria）：按时间窗口（发布日/7天/30天/60天/90天）定义的指标表格
+6. **回滚与应急预案**（Rollback & Contingency）：回滚触发条件、负责人、沟通计划
+
+## Key Principles
+- **发布前客服和 CS 必须完成培训** —— 正式上线前，不是上线当天
+- **先写回滚手册，再开开关** —— 在功能标志翻转前，rollback runbook 必须完成
+- **发布后头两周每日监控** —— 设定异常阈值并主动响应
+
+## Usage
+由 [[Product Manager Agent]] 产出，跨越工程、营销、销售、客服四个部门。GTM Brief 是 [[Product Requirements Document (PRD)]] 的下游文档——PRD 解决"做什么和为什么"，GTM Brief 解决"如何发布和谁来做什么"。
+
+## Related
+- [[Product Requirements Document (PRD)]] — GTM Brief 的上游输入
+- [[Product Manager Agent]] — GTM Brief 的主导者
+- [[Product Roadmap (Now/Next/Later)]] — GA 阶段的Initiative来源
diff --git a/wiki/concepts/Graph-View.md b/wiki/concepts/Graph-View.md
new file mode 100644
index 00000000..79eddd64
--- /dev/null
+++ b/wiki/concepts/Graph-View.md
@@ -0,0 +1,33 @@
+---
+title: "Graph View"
+type: concept
+tags: [tool, obsidian, visualization]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- Obsidian Graph View
+- 图谱视图
+
+## Definition
+Obsidian 内置的可视化工具，将所有 Wiki 页面以节点形式展示，页面之间的双向链接关系自动连线。是 LLM Wiki 健康检查和知识结构发现的核心工具。
+
+## Access
+- 左侧边栏点击图谱图标
+- 快捷键：Ctrl+G（Windows）/ Cmd+G（Mac）
+
+## LLM Wiki Use Cases
+
+### 1. Lint 健康检查
+通过图谱视图**一眼看出哪些页面是孤岛**——没有任何其他页面通过双链指向它。说明交叉引用缺失，需要让 AI 补上链接。
+
+### 2. 发现知识盲区
+如果某个概念被很多页面提到，但**自己没有独立页面**，它在图谱里会显示为**灰色的幽灵节点**。这提醒你应该让 AI 为它创建专页。
+
+## Graph as IDE Debugger
+**"Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库"**——Graph View 就是 Wiki 的调试工具，帮助发现缺失的链接和页面。
+
+## Connections
+- [[Graph View]] ← 可视化工具 ← [[LLM Wiki]]
+- [[Graph View]] ← 内置功能 → [[Obsidian]]
diff --git a/wiki/concepts/Grey-Box-Blockout.md b/wiki/concepts/Grey-Box-Blockout.md
new file mode 100644
index 00000000..11c4f212
--- /dev/null
+++ b/wiki/concepts/Grey-Box-Blockout.md
@@ -0,0 +1,69 @@
+---
+title: "Grey Box Blockout"
+type: concept
+tags: ["game-design", "level-design", "prototyping", "design-validation", "playtest"]
+sources: ["level-designer.md"]
+last_updated: 2026-05-07
+---
+
+## Definition
+
+Grey Box Blockout（灰盒原型阶段）是关卡设计三阶段交付模式的第一阶段——使用未贴图几何体（灰盒）快速构建关卡原型，通过早期 Playtest 验证布局可读性、节奏控制和遭遇战平衡。**核心纪律：所有设计决策在灰盒阶段锁定，美术美化零例外必须先通过灰盒测试**。
+
+## Three-Phase Delivery Model
+
+### Phase 1: Grey Box（灰盒）
+- 仅用未贴图几何体（纯色方块、简单坡道）构建关卡
+- **立即 Playtest**：如果灰盒不可读，艺术美化无法修复它
+- 验证：玩家能否无需地图导航关键路径？
+
+### Phase 2: Dress（美术）
+- 美术团队在灰盒验证后的几何体上添加材质、道具、细节
+- 美术人员必须遵守灰盒阶段锁定的布局，不得改变核心几何
+
+### Phase 3: Polish（打磨）
+- 特效、音效、灯光微调
+- 最终 Playtest 验证
+- 性能优化
+
+## Blockout Specification Template
+
+每个 Room/区域需要记录：
+
+```markdown
+## Room: [ID] — [Name]
+
+**Dimensions**: ~[W]m × [D]m × [H]m
+**Primary Function**: Combat / Traversal / Story / Reward
+
+**Cover Objects**:
+- 2× low cover (waist height) — center cluster
+- 1× destructible pillar — left flank
+- 1× elevated position — rear right (accessible via crate stack)
+
+**Lighting**:
+- Primary: warm directional from [direction] — guides eye toward exit
+- Secondary: cool fill from windows — contrast for readability
+- Accent: flickering [color] on objective marker
+
+**Entry/Exit**:
+- Entry: [Door type, visibility on entry]
+- Exit: [Visible from entry? Y/N — if N, why?]
+
+**Environmental Story Beat**:
+[What does this room's prop placement tell the player about the world?]
+```
+
+## Key Metrics
+
+- 灰盒阶段关键路径可读性：100% 测试玩家无需询问方向即可导航
+- 灰盒阶段遭遇战：每个战斗至少 2 种可行战术路径在灰盒中验证
+- 灰盒阶段节奏：Pacing Chart 与实际测试时间偏差 < 20%
+
+## Connections
+
+- [[Level Designer]] 执行 Grey Box Blockout 作为六阶段工作流的核心步骤
+- [[Navigation Affordance]] 在灰盒阶段验证关键路径视觉可读性
+- [[Encounter Design]] 在灰盒阶段单独测试每个遭遇战
+- [[Technical Artist]] 在灰盒阶段完成时接收 Art Pass Handoff 文档
+- [[Pacing Chart]] 在灰盒阶段通过 Playtest 验证时间偏差 < 20%
diff --git a/wiki/concepts/Groupthink.md b/wiki/concepts/Groupthink.md
new file mode 100644
index 00000000..c83d0cae
--- /dev/null
+++ b/wiki/concepts/Groupthink.md
@@ -0,0 +1,39 @@
+---
+title: "Groupthink"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# Groupthink
+
+## Aliases
+- Groupthink (Janis)
+- Collective Thinking Defects
+
+## Definition
+Janis 群体思维——高凝聚力群体在追求一致性的压力下，进行非理性决策的心理现象，导致批判性思维和替代方案评估能力的丧失。
+
+## Symptoms (Janis's 8 Symptoms)
+
+1. **Illusion of Invulnerability**（无懈可击的错觉）：群体过度自信
+2. **Collective Rationalization**（集体合理化）：忽视警告，自我合理化
+3. **Belief in Inherent Morality**（固有道德信念）：相信自身动机正确
+4. **Pressure on Dissenters**（对异议者施压）：压制不同意见
+5. **Self-Censorship**（自我审查）：成员隐藏真实想法
+6. **Illusion of Unanimity**（一致性的错觉**：沉默被视为同意
+7. **Mindguards**（心理卫兵）：有人阻止异议者发言
+8. **Direct Mind Guarding**（直接的心理防护）：领导公开压制异议
+
+## Remedies
+- 群体领导者应保持中立
+- 鼓励批评性评估
+- 分小组独立讨论后汇总
+- 邀请外部专家参与
+
+## Application in Character Design
+Psychologist Agent 使用此框架分析群体决策场景，识别群体动态如何导致非理性行为（如暴民心理、去个性化）。
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/Guest-Journey.md b/wiki/concepts/Guest-Journey.md
new file mode 100644
index 00000000..06a4ad39
--- /dev/null
+++ b/wiki/concepts/Guest-Journey.md
@@ -0,0 +1,98 @@
+---
+title: "Guest Journey"
+type: concept
+tags: []
+sources:
+  - hospitality-guest-services
+last_updated: 2026-05-02
+---
+
+## Definition
+Guest Journey（宾客旅程）是宾客从首次接触品牌到退房后持续互动全过程的阶段模型。每个阶段都有独特的宾客需求、预期和关键时刻（Moment of Truth），宾客服务必须针对每一阶段进行精心设计。
+
+## Full Guest Journey Stages
+
+### 1. Reservations（预订）
+**核心任务**：确认所有信息准确，特殊需求已记录，特殊场合已标记
+- 预订、修改、取消、团队预订
+- 识别特殊场合（生日/周年纪念/蜜月/VIP）
+- 升级机会评估
+
+**关键指标**：预订完成率、修改/取消率
+
+### 2. Pre-Arrival（预到达）
+**核心任务**：入住前48小时的个性化触达，提前解决问题，创造期待感
+- 发送预到达邮件/消息
+- 确认特殊请求
+- 在线值机+数字钥匙引导
+- 提前识别升级机会
+
+**关键指标**：预到达消息打开率、在线值机完成率
+
+### 3. Check-In（入住）
+**核心任务**：30秒内问候、忠诚身份识别、房间分配与特色介绍
+- 30秒内问候（by name if known）
+- 每次入住都认可忠诚会员身份
+- 确认并超越特殊请求
+- 分配最佳可用房间（有升级则主动提供）
+- 简洁实用的设施介绍
+
+**关键时刻**：首次问候、房间介绍、退房时
+
+### 4. In-Stay（住店期间）
+**核心任务**：满足需求、主动推荐、即时处理投诉
+- 礼宾服务（餐饮预订、本地推荐、交通安排）
+- 投诉渠道监测（当面/电话/App/OTA消息）
+- 投诉立即处理（见 [[HEARD Method]]）
+- 多晚入住宾客入住第二天主动致电/消息关怀
+- 特殊场合惊喜安排
+
+**关键时刻**：礼宾请求完成、投诉解决
+
+### 5. Complaint Resolution（投诉处理）
+**核心任务**：见 [[Service Recovery Protocol]]
+- 立即倾听，不打断
+- 真诚共情，诚挚道歉
+- 即时解决
+- 超越期望补偿
+- 主动跟进
+
+### 6. Check-Out（退房）
+**核心任务**：温暖告别、账单审核、积分确认、离店反馈
+- 姓名问候，温暖送别
+- 主动审核账单，解决疑问
+- 确认忠诚积分到账时间
+- 退房前收集反馈
+- 邀请再次光临
+
+**关键时刻**：退房问候、账单确认
+
+### 7. Post-Stay（售后）
+**核心任务**：感谢、请求点评、监测平台、处理差评
+- 24小时内感谢邮件+调查链接
+- 监测 OTA 平台（TripAdvisor/Booking.com/Google）
+- 48小时内响应所有点评
+- 差评私下跟进，争取修改评分
+- 流失宾客赢回沟通
+
+**关键指标**：调查回复率、在线评分变化、赢回率
+
+### 8. Events & Groups（活动与团队）
+跨阶段并行存在，为会议/婚礼/团队活动提供专项服务
+- 活动协调
+- F&B 规划
+- AV 要求
+- 团队账单管理
+
+## Connections
+- [[Hospitality Guest Services]] ← Guest Journey 是宾客服务 Agent 的核心操作框架
+- [[HEARD Method]] ← 贯穿投诉处理阶段的处理框架
+- [[Service Recovery Protocol]] ← 住店阶段服务失误的恢复流程
+- [[Loyalty Program Management]] ← 贯穿全旅程的会员识别和奖励
+- [[Review Management]] ← 退房和售后阶段的口碑管理
+
+## Aliases
+- 宾客旅程
+- Customer Journey
+- Guest Experience Journey
+- Guest Lifecycle
diff --git a/wiki/concepts/HDRP.md b/wiki/concepts/HDRP.md
new file mode 100644
index 00000000..78e6b5bc
--- /dev/null
+++ b/wiki/concepts/HDRP.md
@@ -0,0 +1,67 @@
+---
+title: "HDRP (High Definition Render Pipeline)"
+type: concept
+tags: [game-dev, rendering, unity, pipeline]
+sources: [unity-shader-graph-artist]
+last_updated: 2026-05-01
+---
+
+## Aliases
+- High Definition Render Pipeline
+- HDRP
+- HD Render Pipeline
+
+## Definition
+
+HDRP（High Definition Render Pipeline，高清渲染管线）是 Unity 的高端渲染管线，专为 PC 和 Console（PlayStation、Xbox）的高视觉质量项目设计。HDRP 提供物理光照模型、光线追踪支持、体积雾、屏幕空间环境遮蔽等 AAA 级渲染特性。相比 URP，HDRP 的渲染质量更高，但不支持移动端，且自定义通道 API 与 URP 不兼容。
+
+## Core Architecture
+
+### CustomPass 系统
+HDRP 自定义通道的核心扩展点：
+
+```csharp
+// HDRP 必须使用 CustomPassVolume + CustomPass
+// 与 URP 的 ScriptableRendererFeature API 不兼容
+public class MyCustomPass : CustomPass
+{
+    protected override void Execute(ScriptableRenderContext context, CommandBuffer cmd, PassData passData,
+        ref RenderingData renderingData)
+        { /* HDRP 自定义渲染逻辑 */ }
+}
+```
+
+### 关键约束
+- **禁止使用** `OnRenderImage`（Built-in only）
+- **禁止使用** URP 的 `ScriptableRendererFeature`（API 不兼容）
+- HDRP 不支持移动端部署
+- Shader Graph 必须设置正确的 HDRP Render Pipeline Asset
+- HDRP 图形无法直接在 URP 中工作，需要反向 Porting
+
+### 与 URP 的核心区别
+
+| 特性 | HDRP | URP |
+|------|------|-----|
+| 目标平台 | PC/Console（高端） | PC/Console/Mobile/VR |
+| 渲染质量 | 极高（光线追踪/物理光照） | 中等-高 |
+| 自定义通道 API | `CustomPassVolume` | `ScriptableRendererFeature` |
+| API 兼容性 | **不兼容** URP | **不兼容** HDRP |
+| 移动端支持 | ❌ 不支持 | ✅ 支持 |
+
+## Shader Graph in HDRP
+
+- Shader Graph 支持 HDRP 的物理光照模型（Lit Shader）
+- Substrate 多层材质（UE5.3+ 替代 SSS workaround）
+- 必须使用 Sub-Graph 封装可复用逻辑
+- HDRP 的 Shader Graph 资产需要显式 Porting 才能在 URP 项目中使用
+
+## Performance
+
+HDRP 主要面向 PC/Console 平台，移动端不是其目标场景。但仍建议在 Frame Debugger 中审计每个 Shader 的实际 GPU 开销。
+
+## Connections
+- [[Shader]] ← 渲染目标 ← HDRP
+- [[UnityShaderGraphArtist]] ← 专精 ← HDRP
+- [[URP]] ← 互补管线 ← HDRP（不兼容）
+- [[CustomPass]] ← 核心 API ← HDRP
+- [[CustomPassVolume]] ← 扩展机制 ← HDRP
diff --git a/wiki/concepts/HEARD-Method.md b/wiki/concepts/HEARD-Method.md
new file mode 100644
index 00000000..10d23119
--- /dev/null
+++ b/wiki/concepts/HEARD-Method.md
@@ -0,0 +1,40 @@
+---
+title: "HEARD Method"
+type: concept
+tags: []
+sources:
+  - hospitality-guest-services
+last_updated: 2026-05-02
+---
+
+## Definition
+HEARD Method 是酒店及综合款待业投诉处理的标准五步框架，用于将愤怒的宾客体验转化为五星好评机会。五个步骤首字母缩写为 HEARD：
+
+- **H — Hear**：完整倾听宾客，不打断
+- **E — Empathize**：真诚共情，"我完全理解您为什么感到沮丧"
+- **A — Apologize**：诚挚道歉，承认具体问题而非泛泛的"不便"
+- **R — Resolve**：即时解决，在问题发生地立即采取行动
+- **D — Delight**：超越期望的补偿，超出宾客预期
+
+## Core Principles
+- **Every complaint is a gift**：愿意投诉的宾客说明仍相信你能补救；不投诉直接离开的宾客永远流失
+- **延迟响应翻倍负面 impact**：服务失误必须立即处理，不可在退房时或次日才响应
+- **具体道歉优于通用道歉**：永远不要用"I apologize for any inconvenience"这类空洞表达
+
+## Severity-Based Recovery Actions
+| 等级 | 场景 | 补偿方案示例 |
+|------|------|-------------|
+| 🟢 Minor | 轻微不便 | 真诚道歉 + 小礼物（水果/甜点/积分） |
+| 🟡 Moderate | 服务失误 | 道歉 + 房间 amenity + 积分/折扣 |
+| 🔴 Major | 严重失误 | 道歉 + 重大补偿 + 经理跟进 |
+| 🚨 Severe | 安全/紧急 | 道歉 + 免费房晚 + 总经理联系方式 |
+
+## Connections
+- [[Service Recovery Protocol]] ← 应用 HEARD Method 的标准化投诉处理流程
+- [[Hospitality Guest Services]] ← HEARD Method 是宾客服务 Agent 的核心技能之一
+- [[Review Management]] ← HEARD 有效执行可将差评转化为好评
+
+## Aliases
+- HEARD Complaint Resolution
+- HEARD Service Recovery
+- 五步投诉处理法
diff --git a/wiki/concepts/HTTP-ChatCompletions.md b/wiki/concepts/HTTP-ChatCompletions.md
new file mode 100644
index 00000000..7518e591
--- /dev/null
+++ b/wiki/concepts/HTTP-ChatCompletions.md
@@ -0,0 +1,44 @@
+---
+title: "HTTP-ChatCompletions"
+type: concept
+tags: []
+---
+
+## Definition
+HTTP-ChatCompletions 是通过 HTTP 协议调用 AI 模型 Chat Completions 接口的模式，是 [[OpenAI-Compatible-API]] 的底层传输机制。
+
+## Architecture
+```
+Client (n8n HTTP Request)
+    │
+    ▼
+POST /v1/chat/completions
+Content-Type: application/json
+Authorization: Bearer <token>
+    │
+    ▼
+{
+  "model": "openclaw:main",
+  "messages": [...]
+}
+    │
+    ▼
+AI Gateway (OpenClaw Gateway)
+    │
+    ▼
+Agent Response
+```
+
+## Key Fields
+- `model`：指定要调用的 Agent ID
+- `messages`：对话历史，格式为 `[{role, content}]`
+- `Authorization`：Bearer Token 认证
+
+## 与 WebSocket 的区别
+- HTTP：同步请求-响应，适合 n8n 等工作流工具
+- WebSocket：长连接双向通信，适合实时对话界面
+
+## Related
+- [[OpenAI-Compatible-API]] 依赖此机制
+- [[OpenClaw]] Gateway 提供此端点
+- [[n8n]] 通过 HTTP Request 节点调用
diff --git a/wiki/concepts/Habit-Formation.md b/wiki/concepts/Habit-Formation.md
new file mode 100644
index 00000000..0584773a
--- /dev/null
+++ b/wiki/concepts/Habit-Formation.md
@@ -0,0 +1,49 @@
+---
+title: "Habit Formation"
+type: concept
+tags: []
+sources: ["product-behavioral-nudge-engine", "habit-tracker-accountability-coach"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Habit Formation（习惯养成）是行为心理学研究的核心领域，通过在特定情境中重复低摩擦的行为动作，结合即时奖励，逐步将行为转化为自动化习惯，无需意志力驱动即可持续执行。
+
+## The Habit Loop
+
+每个习惯由三部分组成的循环：
+
+1. **Cue（触发）**：情境线索（时间、地点、情绪状态）
+2. **Routine（行为）**：对触发的具体反应
+3. **Reward（奖励）**：行为带来的正向反馈
+
+> **关键洞察**：习惯无法被消除，只能被替换——通过保留相同的 Cue 和 Reward，改变中间的 Routine。
+
+## Key Principles
+
+- **Friction Reduction**：行为越容易执行，越容易形成习惯
+- **Consistency Over Intensity**：每天小幅执行优于偶尔高强度执行
+- **Identity Reinforcement**：将行为与自我认同绑定（「我是每天运动的人」）
+- **Streak Preservation**：连续记录是维持动力的重要机制
+- **Micro-Wins**：通过庆祝微小成功建立正向强化
+
+## Connection to [[Behavioral Nudge Engine]]
+
+Behavioral Nudge Engine 专门应用习惯养成原理于软件交互设计：
+- 通过 [[Micro-Sprint]] 将大任务分解为微行为，降低初始摩擦
+- 通过即时庆祝（[[Gamification]]）提供 [[Cognitive Load Reduction]] 后的正向奖励
+- 通过 [[Nudge Sequence]] 在关键时间点触发行为提示
+
+## Related Concepts
+
+- [[Gamification]] — 即时奖励机制是习惯养成的核心
+- [[Cognitive Load Reduction]] — 低摩擦是习惯形成的前提
+- [[Micro-Sprint]] — 将大目标拆解为可习惯化的微行为
+- [[Default Bias]] — 预设动作减少习惯养成的启动阻力
+
+## Connections
+
+- [[Habit Tracker & Accountability Coach]] — 专门负责习惯追踪与问责的 Agent
+- [[Behavioral Nudge Engine]] — 行为心理学的应用引擎
+- [[Product Manager Agent]] — 产品设计中嵌入习惯养成机制
diff --git a/wiki/concepts/Handoff-Boundary.md b/wiki/concepts/Handoff-Boundary.md
new file mode 100644
index 00000000..ec11c841
--- /dev/null
+++ b/wiki/concepts/Handoff-Boundary.md
@@ -0,0 +1,44 @@
+---
+title: "Handoff Boundary"
+type: concept
+tags: [multi-agent, coordination, failure-point, nexus]
+sources: [executive-brief]
+last_updated: 2026-05-01
+aliases:
+  - Agent Boundary
+  - Coordination Interface
+  -交接边界
+---
+
+## Definition
+
+交接边界（Handoff Boundary）—— 多 Agent 工作流中从一个 Agent 的交付物传递到下一个 Agent 的接口点，也是协调失败最频繁发生的位置。
+
+## The 73% Failure Rate Problem
+
+**关键数据**：多 Agent 项目在缺乏结构化协调协议时，交接边界处的失败率达 **73%**。
+
+这使得交接边界成为多 Agent 协调中**最高杠杆的干预点**——改善交接协议带来的收益远大于优化单个 Agent 能力。
+
+## Failure Modes at Handoff Boundaries
+
+1. **上下文截断**：关键决策和中间产物在交接时丢失
+2. **重复劳动**：下一 Agent 重新执行上一 Agent 已完成的工作
+3. **缺陷传递**：上游 Agent 的问题未被检测，直接传递给下游
+4. **质量断崖**：上游 Agent 的质量标准与下游不一致
+5. **时间浪费**：交接等待导致流程阻塞
+
+## Highest-Leverage Interventions
+
+根据 Executive Brief 的战略发现，以下是针对交接边界的最高杠杆干预：
+
+1. **标准化交接模板**（见 Handoff Templates）：强制包含交付物清单 + 上下文摘要 + 下一步指令 + 质量证据
+2. **上下文连续性协议**：确保决策历史和中间产物在交接时完整传递（MCP Memory）
+3. **质量证据传递**：上游 Agent 必须提供可验证的质量证据，而非口头声明
+
+## Related Concepts
+
+- [[Agent Handoff]]：在交接边界执行的标准化上下文传递协议
+- [[Evidence Over Claims]]：交接边界处的质量标准，防止缺陷传递
+- [[Quality Gate]]：交接边界处的强制质量检查点
+- [[Dev↔QA Loop]]：交接边界内的持续质量验证机制
diff --git a/wiki/concepts/Harness-Engineering.md b/wiki/concepts/Harness-Engineering.md
new file mode 100644
index 00000000..91d5655f
--- /dev/null
+++ b/wiki/concepts/Harness-Engineering.md
@@ -0,0 +1,49 @@
+---
+title: "Harness Engineering"
+type: concept
+tags:
+  - "harness-engineering"
+  - "agentic-ai"
+  - "system-design"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+Harness Engineering——为 LLM 设计系统脚手架的工程学科，使 AI Agent 能在长周期自主任务中可靠执行。核心理念：**LLM 本身不是 Agent，Agent = LLM + 代码脚手架**。
+
+## Evolution of AI Engineering
+
+| Era | Focus | Limitation |
+|-----|-------|------------|
+| Prompt Engineering | 如何问（Instructions） | 脆弱，步骤间无持久性 |
+| Context Engineering | 如何知道（RAG） | 无状态，无法控制长周期执行 |
+| **Harness Engineering** | 如何约束和运行 | 解决连续多步执行控制 |
+
+每个时代并非替代前一个，而是**吸收**前一个——Harness Engineering 仍需要好的提示词和好的上下文，但它增加了前两者都无法提供的执行层。
+
+## 4 Design Principles
+
+### 1. 约束而非指令（Constrain, don't instruct）
+永远不要依赖模型"选择正确"——如果可以用程序化方式限制选择，就这样做。
+- 提示词说"永远用有效 JSON 响应" = **希望**
+- Schema 验证器拒绝格式错误输出 = **保证**
+
+### 2. 外部化状态（Externalize state）
+如果一条信息对任务连续性重要（已完成什么、待处理什么、什么失败了），它必须存在于 context window 之外。
+- Context window 是易失的
+- 磁盘文件是持久的
+
+### 3. 每步可验证（Make every step verifiable）
+如果你无法检查它，你就无法信任它。Harness 的每一层都应产生可被模型自身以外的东西验证的输出。
+
+### 4. 局部失败而非全局崩溃（Fail locally, not globally）
+单步工具调用失败应触发该步重试，而非重启整个管道。任何失败的爆炸半径应尽可能小。
+
+## Implementation
+- [[7-Layer-Harness-Stack]]：完整 7 层实现规范
+- [[Minimum-Viable-Harness]]：Day 1 可构建的最小可行版本
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
diff --git a/wiki/concepts/HeroesJourney.md b/wiki/concepts/HeroesJourney.md
new file mode 100644
index 00000000..639a9b02
--- /dev/null
+++ b/wiki/concepts/HeroesJourney.md
@@ -0,0 +1,36 @@
+---
+title: "Hero's Journey"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Hero's Journey
+- Monomyth
+- Campbell's Monomyth
+- 英雄之旅
+
+## Overview
+Hero's Journey（Monomyth / 英雄之旅）是由 [[Joseph Campbell]] 在其著作《千面英雄》（1949）中系统提出的跨文化神话叙事结构。该理论主张：全球文化的神话故事遵循一个共同的深层叙事结构——英雄离开日常世界 → 进入超自然领域 → 经历考验并获得力量 → 带着成功归来。
+
+## Structure（简化版）
+
+### 三阶段
+1. **Departure（启程）**：Ordinary World → Call to Adventure → Refusal of the Call → Meeting the Mentor → Crossing the First Threshold
+2. **Initiation（启蒙）**：Tests, Allies and Enemies → Approach to the Inmost Cave → Ordeal → Reward
+3. **Return（回归）**：The Road Back → Resurrection → Return with the Elixir
+
+### 核心隐喻
+- **The Belly of the Whale**：最深的转变时刻，英雄几乎被吞噬
+- **The Elixir**：归来时携带的智慧或宝藏
+
+## Application
+- [[Christopher Vogler]] 的 Writer's Journey 是 Hero's Journey 的编剧改编版
+- 皮克斯几乎所有电影（《玩具总动员》《寻梦环游记》等）都遵循此结构
+- [[Academic Narratologist]] 将其作为英雄叙事分析的核心框架
+
+## Relationship to Other Concepts
+- [[Three-Act-Structure]]：Hero's Journey 是三幕式的叙事内容层，三幕式是组织层
+- [[Character-Arc]]：Hero's Journey 中的 transformation 对应角色的 want/need/lie/transformation 弧线
diff --git a/wiki/concepts/HierarchicalLOD.md b/wiki/concepts/HierarchicalLOD.md
new file mode 100644
index 00000000..e096dd0d
--- /dev/null
+++ b/wiki/concepts/HierarchicalLOD.md
@@ -0,0 +1,57 @@
+---
+title: "HierarchicalLOD"
+type: concept
+tags: ["unreal-engine", "lod", "optimization", "rendering"]
+sources: ["unreal-world-builder"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- HLOD
+- Hierarchical Level of Detail
+- 层级 LOD
+- HLOD System
+
+## Definition
+HLOD（Hierarchical Level of Detail，层级 LOD）是 Unreal Engine 5 中将远处多个 Actor 合并为少量网格的系统，消除远处的 Actor 数量爆炸和几何 pop-in，显著降低 Draw Calls 和渲染开销。
+
+## Core Rules
+- **强制构建**：所有 500m 以外可见区域必须生成 HLOD，未构建 HLOD 会导致远处 Actor 数量爆炸
+- **生成而非手绘**：HLOD 网格由引擎自动生成，任何几何变更后必须重新构建
+- **Mesh Merge 方法**：最快构建速度，对 > 500m 距离可接受质量
+- **目标参数**：LOD Screen Size ≤ 0.01，Draw Distance ≥ 50,000cm（500m）
+- **材质烘焙**：启用，1024×1024 烘焙纹理
+
+## Actor Type Handling
+| Actor 类型 | HLOD 处理 |
+|-----------|----------|
+| StaticMeshActor | 包含在 HLOD 合并 |
+| Nanite 启用网格 | **排除**（Nanite 自身处理 LOD） |
+| Skeletal Mesh | **不支持**（不合并） |
+
+## Build Settings
+- **Merge Distance**：50cm（焊接附近几何）
+- **Hard Angle Threshold**：80°（保留锐边）
+- **Target Triangle Count**：每 HLOD 网格 5000 三角形
+
+## Visual Validation
+必须在以下相机距离进行目视验证：
+- 600m
+- 1000m
+- 2000m
+
+HLOD 瑕疵靠视觉捕获，而非 Profiler。
+
+## Rebuild Triggers
+任何以下变更必须触发 HLOD 重建：
+- 几何添加或移除
+- 材质变更
+- Actor 变换
+
+## Connections
+- [[UnrealWorldBuilder]] ← 远距离优化 ← HierarchicalLOD
+- [[UnrealEngine5]] ← 核心引擎 ← HierarchicalLOD
+- [[Nanite]] ← 互补（处理 Nanite 资产）← HierarchicalLOD
+
+## Sources
+- [[unreal-world-builder]]
diff --git a/wiki/concepts/Historiography.md b/wiki/concepts/Historiography.md
new file mode 100644
index 00000000..8a33d5f7
--- /dev/null
+++ b/wiki/concepts/Historiography.md
@@ -0,0 +1,35 @@
+---
+title: "Historiography"
+type: concept
+tags: [historiography, methodology]
+sources: [academic-historian]
+last_updated: 2026-04-30
+---
+
+## Definition
+历史编纂学（Historiography）是对历史叙事本身的研究——研究历史如何被记录、构建、争论和演变的学科。Historiography 既关注具体的历史研究成果，也关注这些成果背后的认识论、方法论和政治性前提。
+
+## Key Features
+- **核心问题**：历史知识是如何生产的？谁的视角被记录？谁的被忽略？
+- **研究对象**：史料选择、历史叙事结构、史学流派演变、历史争议的根源
+- **核心议题**：
+  - 史料的可靠性与偏见（谁书写，谁沉默？）
+  - 史学流派更替（启蒙史学 → 浪漫主义史学 → 实证主义 → 年鉴学派 → 后现代史学）
+  - 历史叙事的政治性（历史书写服务于现实政治利益）
+  - 档案的构建（档案本身是权力工具，非中性存储）
+- **重要性**：Historian Agent 理解"历史叙事本身是被建构和争夺的对象"，这是反历史神话和欧洲中心主义的基础
+
+## Relationship to Other Concepts
+- [[Annales-School]] ← 重要流派 ← [[Historiography]]：年鉴学派是对传统实证主义史学的重要突破
+- [[Microhistory]] ← 属于 ← [[Historiography]]：微观史是历史编纂学中的重要流派
+- [[Longue-Duree]] ← 属于 ← [[Historiography]]：长时段分析反映特定史学认识论
+- [[academic-historian]] ← 方法论核心 ← [[Historiography]]：Historian Agent 的五步工作流本质上是 historiographical 方法论
+
+## Relationship to Source Pages
+- [[academic-historian]]：Historian Agent 接受过 historiography 训练，能够理解并参与学术争议
+
+## Aliases
+- 历史编纂
+- 史学
+- 元历史
+- Metahistory
diff --git a/wiki/concepts/Hosmer-Lemeshow-Test.md b/wiki/concepts/Hosmer-Lemeshow-Test.md
index 1a124ba7..6ae35598 100644
--- a/wiki/concepts/Hosmer-Lemeshow-Test.md
+++ b/wiki/concepts/Hosmer-Lemeshow-Test.md
@@ -1,91 +1,93 @@
----
-title: "Hosmer-Lemeshow Test"
-type: concept
-tags: [model-evaluation, calibration-testing, goodness-of-fit]
-last_updated: 2026-04-25
----
-
-## Definition
-
-Hosmer-Lemeshow（HL）检验是一种评估二分类模型预测概率校准程度的拟合优度检验，通过比较预测概率分箱后的观测正例数与期望正例数，判断模型预测与实际结果之间是否存在显著差异。p-value < 0.05 时拒绝原假设（模型校准良好），认为模型存在显著的校准偏差。
-
-## Algorithm
-
-1. 将样本按预测概率从小到大分箱（默认 10 箱，或自定义 g 组）
-2. 对每箱计算：
-   - **观测正例数** $O_g = \sum_{i \in \text{group } g} y_i$
-   - **期望正例数** $E_g = \sum_{i \in \text{group } g} \hat{p}_i$
-   - **样本数** $n_g$
-3. 计算 HL 统计量：
-
-$$H = \sum_{g=1}^{G} \frac{(O_g - E_g)^2}{E_g (1 - E_g / n_g)}$$
-
-4. 自由度 $df = G - 2$（减去截距和斜率估计参数）
-5. 与 $\chi^2(df)$ 分布比较，$p = 1 - F_{H}(H)$
-
-## Interpretation
-
-```python
-from scipy.stats import chi2
-
-def hosmer_lemshow_test(y_true: pd.Series, y_pred: pd.Series, groups: int = 10) -> dict:
-    data = pd.DataFrame({"y": y_true, "p": y_pred})
-    data["bucket"] = pd.qcut(data["p"], groups, duplicates="drop")
-
-    agg = data.groupby("bucket", observed=True).agg(
-        n=("y", "count"),
-        observed=("y", "sum"),
-        expected=("p", "sum"),
-    )
-
-    hl_stat = (
-        ((agg["observed"] - agg["expected"])**2) /
-        (agg["expected"] * (1 - agg["expected"] / agg["n"]))
-    ).sum()
-
-    dof = len(agg) - 2
-    p_value = 1 - chi2.cdf(hl_stat, dof)
-
-    return {
-        "HL_statistic": round(hl_stat, 4),
-        "p_value": round(p_value, 6),
-        "calibrated": p_value >= 0.05,  # True = well calibrated
-        "dof": dof,
-        "groups_used": len(agg),
-    }
-```
-
-| p-value | 判读 |
-|---------|------|
-| ≥ 0.05 | 🟢 模型校准良好，无显著证据表明预测概率偏离实际频率 |
-| < 0.05 | 🔴 拒绝原假设，模型存在显著校准偏差 |
-
-## Limitations
-
-1. **分组方式敏感**：不同分箱数量/方法导致不同结果，10 等分是惯例但非最优
-2. **样本量敏感**：大样本下即使微小偏差也能导致显著 p-value（实际影响可能很小）
-3. **掩盖子群体问题**：整体通过 HL 检验不等于所有子群体都校准良好
-4. **序贯分组问题**：qcut 在重复值多时可能合并箱子，需检查 `groups_used`
-
-## Alternatives
-
-- **Brier Score**：无需分组，对样本量稳健，但只能给出误差量级而非定位
-- **Spiegelhalter's Z-test**：基于 Brier Score 的统计检验
-- **Reliability Curves**：可视化诊断，比 HL 检验提供更多信息
-- **Expected Calibration Error (ECE)**：量化平均校准误差，解释性更强
-
-## Model QA 中的应用
-
-Model QA Specialist 将 HL 检验用于：
-1. **模型上线前验证**：新模型上线必须通过 HL 检验（p ≥ 0.05）
-2. **定期监控**：在 OOT 窗口上重复执行，监控校准随时间恶化趋势
-3. **子群体分层测试**：在关键子群体（高风险/低风险/新客户）上分别执行
-4. **Champion-Challenger**：对比 champion model vs challenger model 的 HL 结果
-
-## Relationship
-
-- **被依赖** [[Calibration-Testing]]：HL 检验是 Calibration Testing 的核心统计工具之一
-- **依赖** [[Discrimination-Metrics]]：先确认模型有区分能力（AUC/Gini 达标），再讨论校准
-- **依赖** [[Population-Stability-Index]]：PSI 漂移往往是 HL 检验失败的前兆
-- **依赖** [[SHAP]]：HL 检验发现校准问题后，用 SHAP waterfall 诊断具体原因
-- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 校准测试步骤的核心工具
+---
+title: "Hosmer-Lemeshow Test"
+type: concept
+tags: [model-evaluation, calibration-testing, goodness-of-fit]
+sources:
+  - specialized-model-qa
+last_updated: 2026-05-29
+---
+
+## Definition
+
+Hosmer-Lemeshow（HL）检验是一种评估二分类模型预测概率校准程度的拟合优度检验，通过比较预测概率分箱后的观测正例数与期望正例数，判断模型预测与实际结果之间是否存在显著差异。p-value < 0.05 时拒绝原假设（模型校准良好），认为模型存在显著的校准偏差。
+
+## Algorithm
+
+1. 将样本按预测概率从小到大分箱（默认 10 箱，或自定义 g 组）
+2. 对每箱计算：
+   - **观测正例数** $O_g = \sum_{i \in \text{group } g} y_i$
+   - **期望正例数** $E_g = \sum_{i \in \text{group } g} \hat{p}_i$
+   - **样本数** $n_g$
+3. 计算 HL 统计量：
+
+$$H = \sum_{g=1}^{G} \frac{(O_g - E_g)^2}{E_g (1 - E_g / n_g)}$$
+
+4. 自由度 $df = G - 2$（减去截距和斜率估计参数）
+5. 与 $\chi^2(df)$ 分布比较，$p = 1 - F_{H}(H)$
+
+## Interpretation
+
+```python
+from scipy.stats import chi2
+
+def hosmer_lemshow_test(y_true: pd.Series, y_pred: pd.Series, groups: int = 10) -> dict:
+    data = pd.DataFrame({"y": y_true, "p": y_pred})
+    data["bucket"] = pd.qcut(data["p"], groups, duplicates="drop")
+
+    agg = data.groupby("bucket", observed=True).agg(
+        n=("y", "count"),
+        observed=("y", "sum"),
+        expected=("p", "sum"),
+    )
+
+    hl_stat = (
+        ((agg["observed"] - agg["expected"])**2) /
+        (agg["expected"] * (1 - agg["expected"] / agg["n"]))
+    ).sum()
+
+    dof = len(agg) - 2
+    p_value = 1 - chi2.cdf(hl_stat, dof)
+
+    return {
+        "HL_statistic": round(hl_stat, 4),
+        "p_value": round(p_value, 6),
+        "calibrated": p_value >= 0.05,  # True = well calibrated
+        "dof": dof,
+        "groups_used": len(agg),
+    }
+```
+
+| p-value | 判读 |
+|---------|------|
+| ≥ 0.05 | 🟢 模型校准良好，无显著证据表明预测概率偏离实际频率 |
+| < 0.05 | 🔴 拒绝原假设，模型存在显著校准偏差 |
+
+## Limitations
+
+1. **分组方式敏感**：不同分箱数量/方法导致不同结果，10 等分是惯例但非最优
+2. **样本量敏感**：大样本下即使微小偏差也能导致显著 p-value（实际影响可能很小）
+3. **掩盖子群体问题**：整体通过 HL 检验不等于所有子群体都校准良好
+4. **序贯分组问题**：qcut 在重复值多时可能合并箱子，需检查 `groups_used`
+
+## Alternatives
+
+- **Brier Score**：无需分组，对样本量稳健，但只能给出误差量级而非定位
+- **Spiegelhalter's Z-test**：基于 Brier Score 的统计检验
+- **Reliability Curves**：可视化诊断，比 HL 检验提供更多信息
+- **Expected Calibration Error (ECE)**：量化平均校准误差，解释性更强
+
+## Model QA 中的应用
+
+Model QA Specialist 将 HL 检验用于：
+1. **模型上线前验证**：新模型上线必须通过 HL 检验（p ≥ 0.05）
+2. **定期监控**：在 OOT 窗口上重复执行，监控校准随时间恶化趋势
+3. **子群体分层测试**：在关键子群体（高风险/低风险/新客户）上分别执行
+4. **Champion-Challenger**：对比 champion model vs challenger model 的 HL 结果
+
+## Relationship
+
+- **被依赖** [[Calibration-Testing]]：HL 检验是 Calibration Testing 的核心统计工具之一
+- **依赖** [[Discrimination-Metrics]]：先确认模型有区分能力（AUC/Gini 达标），再讨论校准
+- **依赖** [[Population-Stability-Index]]：PSI 漂移往往是 HL 检验失败的前兆
+- **依赖** [[SHAP]]：HL 检验发现校准问题后，用 SHAP waterfall 诊断具体原因
+- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 校准测试步骤的核心工具
diff --git a/wiki/concepts/HybridFingerprinting.md b/wiki/concepts/HybridFingerprinting.md
new file mode 100644
index 00000000..1eb2a714
--- /dev/null
+++ b/wiki/concepts/HybridFingerprinting.md
@@ -0,0 +1,43 @@
+---
+title: "Hybrid Fingerprinting"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+
+结合精确匹配（SHA-256 主键哈希）与模糊匹配（向量语义相似度）两种信号，防止因表面相似而误合并不同记录的混合指纹识别机制。
+
+## The Problem
+
+纯语义相似度是模糊的：
+- `"John Doe ID:101"` 与 `"Jon Doe ID:102"` 语义高度相似
+- 但主键不同（ID:101 ≠ ID:102），实际上是两条不同的记录
+- 若仅依赖语义相似度，可能被错误聚类合并
+
+## Solution
+
+```
+Hybrid Score = SHA-256(PK_hash) + Vector_Similarity(embedding)
+```
+
+- **PK Hash differs** → 强制分离聚类，不允许合并
+- **PK Hash matches** → 才考虑向量相似度进行聚类
+
+## Implementation
+
+```python
+# 伪代码
+for each candidate_pair:
+    if sha256(pk1) != sha256(pk2):
+        force_separate_clusters()  # PK不同，强制分离
+    else:
+        if vector_similarity(embedding1, embedding2) > threshold:
+            merge_clusters()  # PK相同且语义相似，才合并
+```
+
+## Related
+
+- [[Semantic Anomaly Compression]]
+- [[Air-Gapped SLM Fix Generation]]
diff --git a/wiki/concepts/Inclusive-Delight-Design.md b/wiki/concepts/Inclusive-Delight-Design.md
new file mode 100644
index 00000000..8ca8eaeb
--- /dev/null
+++ b/wiki/concepts/Inclusive-Delight-Design.md
@@ -0,0 +1,38 @@
+---
+title: "Inclusive Delight Design"
+type: concept
+tags: [accessibility, ui-design, inclusive-design, user-experience]
+sources: [design-whimsy-injector]
+last_updated: 2026-05-15
+---
+
+# Inclusive Delight Design
+
+## Definition
+
+包容性愉悦设计（Inclusive Delight Design）确保趣味元素对所有用户（包括残障用户）都可访问和可享受。核心原则：趣味性必须与无障碍访问并行实现，不能成为享受的障碍。
+
+## Core Principles
+
+- **屏幕阅读器兼容**：动画不影响辅助技术
+- **减少动画偏好**：通过 `prefers-reduced-motion` 支持
+- **文化敏感性**：幽默和趣味跨文化适用
+- **认知负荷控制**：趣味不造成理解障碍
+- **多感官设计**：视觉 + 触觉/听觉多通道愉悦
+
+## Whimsy Injector Guidelines
+
+> "Design playful elements that work for users with disabilities"
+> "Ensure whimsy doesn't interfere with screen readers or assistive technology"
+> "Provide options for users who prefer reduced motion or simplified interfaces"
+> "Create humor and personality that is culturally sensitive and appropriate"
+
+## Relationship to Other Concepts
+
+- [[Micro-Interaction-Design]]：微交互需遵循包容性设计原则
+- [[Gamification]]：游戏化元素必须包容性设计
+- [[Invisible-Exclusion]]：包容性愉悦设计是避免隐性排他的关键
+
+## Source
+
+- [[Whimsy-Injector]] — 包容性愉悦设计原则核心来源
diff --git a/wiki/concepts/Inclusive-Delight.md b/wiki/concepts/Inclusive-Delight.md
new file mode 100644
index 00000000..9878ed6a
--- /dev/null
+++ b/wiki/concepts/Inclusive-Delight.md
@@ -0,0 +1,48 @@
+---
+title: "Inclusive Delight"
+type: concept
+tags: [accessibility, ux, design, inclusion]
+last_updated: 2026-04-30
+---
+
+# 包容性愉悦设计（Inclusive Delight）
+
+## Aliases
+- Inclusive Delight
+- 包容性设计
+- 无障碍愉悦
+- Accessible Playfulness
+
+## 定义
+
+包容性愉悦设计是指在产品中引入趣味性、情感化元素（如微交互、动画、游戏化）时，确保这些元素对所有用户（包括残障用户、不同文化背景用户、不同能力的用户）都可访问、可理解和可享受的设计原则。
+
+## 核心要求
+
+1. **运动敏感**：动画需支持 `prefers-reduced-motion`，允许用户关闭或减弱所有运动效果
+2. **屏幕阅读器兼容**：趣味元素不应干扰辅助技术对内容的解读（ARIA 标签、语义化 HTML）
+3. **色彩对比度**：趣味配色必须在 WCAG 对比度标准下可读
+4. **文化敏感性**：幽默和趣味的表达需考虑跨文化理解，避免歧义或冒犯
+5. **替代文本**：Emoji 庆祝动画等视觉元素需有文字替代方案
+
+## 设计策略
+
+- **分层体验（Layered Experience）**：基础层对所有用户可访问，趣味增强层作为可选叠加
+- **开关控制**：为用户保留关闭趣味元素的选项（降低 motion、简化模式）
+- **渐进增强**：从无障碍基础开始，逐步叠加趣味层
+- **测试多样性**：在真实辅助技术（屏幕阅读器、眼动追踪）和不同文化背景用户中测试
+
+## 与趣味设计的关系
+
+包容性不是趣味设计的对立面，而是趣味设计的基础约束——一个不包容的"趣味"设计会排斥部分用户，减少潜在受众。优秀的趣味设计在满足包容性要求的同时依然能创造愉悦感。
+
+## 应用场景
+
+- [[design-whimsy-injector]] 将包容性愉悦作为默认要求嵌入品牌个性框架，明确规定"确保所有趣味元素可访问和包容"
+- [[design-ux-architect]] 通过 CSS 变量和语义化标记支持包容性基础的建立
+
+## 相关概念
+
+- [[Micro-Interaction]]：微交互需满足包容性要求（如 reduced-motion 支持）
+- [[Gamification]]：成就系统需考虑不同能力水平用户的参与公平性
+- [[Brand-Personality-Framework]]：品牌个性中的文化敏感性是包容性的重要组成
diff --git a/wiki/concepts/Inclusive-Design-Research.md b/wiki/concepts/Inclusive-Design-Research.md
new file mode 100644
index 00000000..6b3c0f03
--- /dev/null
+++ b/wiki/concepts/Inclusive-Design-Research.md
@@ -0,0 +1,28 @@
+---
+title: "Inclusive Design Research"
+type: concept
+tags: [ux, accessibility, inclusive-design, research, disability]
+sources: [design-ux-researcher.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+Inclusive Design Research（包容性设计研究）是一种将无障碍和包容性维度纳入用户研究默认要求的研究方法。确保研究参与者和研究成果覆盖不同能力水平、文化背景和人口统计学特征，使产品对残障用户和多元群体可访问。
+
+## Core Requirements
+
+- **默认要求**：所有 UX Researcher 的研究交付物必须包含无障碍研究维度
+- **参与者招募**：确保多样性，涵盖不同能力水平
+- **测试方法**：包含屏幕阅读器用户、键盘-only 用户等特殊群体的可用性测试
+- **文化包容性**：考虑不同文化背景用户的需求差异
+
+## Relationship to Other Concepts
+
+- [[User-Research-Methodology]]：包容性是研究方法论的默认质量维度
+- [[Usability-Testing]]：可用性测试协议需包含无障碍测试场景
+- [[Inclusive-Delight-Design]]：包容性设计研究为包容性趣味设计提供用户数据支撑（[[design-whimsy-injector]] 的默认要求）
+
+## Source
+
+- [[design-ux-researcher.md]] — UX Researcher Agent Personality
diff --git a/wiki/concepts/IncrementalGraphUpdate.md b/wiki/concepts/IncrementalGraphUpdate.md
new file mode 100644
index 00000000..13f018e3
--- /dev/null
+++ b/wiki/concepts/IncrementalGraphUpdate.md
@@ -0,0 +1,52 @@
+---
+title: "IncrementalGraphUpdate"
+type: concept
+tags: ["LSP", "code-intelligence", "incremental-update", "event-driven", "real-time"]
+sources: ["lsp-index-engineer.md"]
+last_updated: 2026-04-29
+---
+
+## Definition
+增量图谱更新（Incremental Graph Update）是一种通过文件监听器和 Git hooks 实时监听代码变化，仅对受影响的部分图谱进行增量更新而非全量重建的策略，确保图谱始终与代码库保持同步，同时保持 < 100ms 端到端响应时间。
+
+## Core Mechanism
+
+### 触发来源
+1. **文件监听器**（File Watcher）：监听文件系统的 `create/modify/delete` 事件
+2. **Git Hooks**：`pre-commit` / `post-commit` / `post-merge` 钩子检测代码变更
+
+### 增量更新流程
+1. 检测文件变更（新增/修改/删除）
+2. 定位受影响的符号节点和边
+3. 对该文件运行 LSP `textDocument/didChange` 通知
+4. 接收 LSP 的增量语义更新
+5. 更新相关图谱节点和边
+6. 通过 WebSocket 推送图谱差异（Graph Diff）到客户端
+
+### Graph Diff 推送
+```typescript
+interface GraphDiff {
+  added: GraphNode[];
+  removed: GraphNode[];
+  modified: GraphNode[];
+  addedEdges: GraphEdge[];
+  removedEdges: GraphEdge[];
+}
+```
+仅推送差异，不推送全量图谱，实现最小化网络开销。
+
+### 一致性保证
+- **原子性更新**：图谱更新是事务性的，要么全部成功要么全部回滚
+- **乐观锁**：并发更新时使用版本号检测冲突
+- **不变性约束验证**：更新前后验证图谱一致性不变量（符号唯一定义、边引用有效性等）
+
+## Performance Characteristics
+- 文件变更到 WebSocket 推送：< 50ms
+- 单文件增量更新：< 20ms
+- 100k+ 符号规模：仍保持增量更新性能
+
+## Connections
+- [[IncrementalGraphUpdate]] ← is_update_strategy_of ← [[GraphDaemon]]
+- [[IncrementalGraphUpdate]] ← triggered_by ← [[FileWatcher]]
+- [[IncrementalGraphUpdate]] ← streams_via ← [[WebSocket]]
+- [[IncrementalGraphUpdate]] ← replaces ← [[LSIF]]（LSIF 用于预计算，Incremental 用于实时）
diff --git a/wiki/concepts/Incrementality-Testing.md b/wiki/concepts/Incrementality-Testing.md
index f3ecb047..3adf759d 100644
--- a/wiki/concepts/Incrementality-Testing.md
+++ b/wiki/concepts/Incrementality-Testing.md
@@ -1,29 +1,32 @@
----
-title: "Incrementality Testing"
-type: concept
-tags: ["paid-media", "attribution", "measurement", "testing"]
-last_updated: 2026-04-25
----
-
-## Aliases
-- 增量测试
-- Incrementality
-- Holdout Testing
-- Geo Split Testing
-
-## Overview
-增量测试是一种通过对照组（holdout）实验设计，验证付费广告是否带来"净新增"转化的方法论。核心目的是避免"转移归因"——即付费广告只是截获了本来会发生的有机转化，而非真正带来增量价值。
-
-## Definition
-常见方法：
-- **Holdout（控制组）**：随机选取一部分目标受众，不投放广告，对比两组转化率差异
-- **Geo Split（地理拆分）**：在不同地理区域分别开关广告，隔离外部变量
-- **Matched Market（匹配市场）**：选择相似市场，一方投放一方对照
-
-增量 = 实验组转化率 - 对照组转化率（排除自然流量后）
-
-## Connections
-- [[Paid Media Paid Social Strategist]] Agent 在跨渠道验证中强调增量测试
-- 与 [[Conversions API]] 数据配合可更准确地测量增量
-- 与 [[PaidMediaPpcStrategist]] 的增量测试框架（geo-split/holdout/matched market）方法论一致
-- 避免 [[Audience Overlap Analysis]] 导致的重复计算问题
+---
+title: "Incrementality Testing"
+type: concept
+tags: ["paid-media", "attribution", "measurement", "testing"]
+sources:
+  - paid-media-programmatic-buyer
+  - paid-media-ppc-strategist
+last_updated: 2026-05-01
+---
+
+## Aliases
+- 增量测试
+- Incrementality
+- Holdout Testing
+- Geo Split Testing
+
+## Overview
+增量测试是一种通过对照组（holdout）实验设计，验证付费广告是否带来"净新增"转化的方法论。核心目的是避免"转移归因"——即付费广告只是截获了本来会发生的有机转化，而非真正带来增量价值。
+
+## Definition
+常见方法：
+- **Holdout（控制组）**：随机选取一部分目标受众，不投放广告，对比两组转化率差异
+- **Geo Split（地理拆分）**：在不同地理区域分别开关广告，隔离外部变量
+- **Matched Market（匹配市场）**：选择相似市场，一方投放一方对照
+
+增量 = 实验组转化率 - 对照组转化率（排除自然流量后）
+
+## Connections
+- [[Paid Media Paid Social Strategist]] Agent 在跨渠道验证中强调增量测试
+- 与 [[Conversions API]] 数据配合可更准确地测量增量
+- 与 [[PaidMediaPpcStrategist]] 的增量测试框架（geo-split/holdout/matched market）方法论一致
+- 避免 [[Audience Overlap Analysis]] 导致的重复计算问题
diff --git a/wiki/concepts/IncrementalityTesting.md b/wiki/concepts/IncrementalityTesting.md
new file mode 100644
index 00000000..a7eed629
--- /dev/null
+++ b/wiki/concepts/IncrementalityTesting.md
@@ -0,0 +1,59 @@
+---
+title: "Incrementality Testing"
+type: concept
+tags: ["ppc", "measurement", "analytics", "attribution", "paid-media"]
+sources: ["paid-media-ppc-strategist"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+增量测试（Incrementality Testing）是一套用于衡量付费广告真实业务贡献的方法论，通过对照组设计（Holdout/Control Group）区分"由广告带来的增量转化"与"即使没有广告也会自然发生的转化"。解决归因模型的固有局限性——仅分析有广告触达的用户，而不考虑无广告曝光时的自然转化。
+
+## Why Incrementality Matters
+
+传统归因的问题：
+- **Last-click 过誉**：将转化归功于最后一次点击，忽略其他触点
+- **View-through 虚假转化**：用户看过广告但未点击，计为"转化"
+- **自然转化混淆**：无法区分广告贡献和自然流量
+
+Incrementality 测试回答核心问题：**如果没有这个广告，转化量会下降多少？**
+
+## Testing Methodologies
+
+### 1. Geo-Split（地理分割测试）
+**原理**：将市场按地理区域分割，一半投放广告，一半暂停，对比转化差异
+
+| 区域 | 处理 |
+|------|------|
+| Test Market A | 投放广告 |
+| Test Market B | 暂停广告 |
+| Control Market | 维持正常投放（用于基线校准） |
+
+**适用**：品牌广告、Display、Video、OOH
+**最小样本**：每个市场 30+ 转化/周
+
+### 2. Holdout / User-Level Holdout（用户级对照测试）
+**原理**：随机选择 X% 用户完全排除在广告触达之外，对比与正常触达用户的转化率差异
+
+**适用**：精准追踪能力（Email/Pixel 覆盖率高）
+**挑战**：用户感知可能影响结果
+
+### 3. Matched Market（匹配市场测试）
+**原理**：使用历史数据识别两个可比较的地理市场，一个投放，一个暂停
+
+**适用**：无法随机分割用户的大型品牌
+**关键**：Matching 质量决定测试有效性
+
+## Key Metrics from Incrementality Tests
+
+| 指标 | 公式 | 解读 |
+|------|------|------|
+| **Uplift** | (Test Conv - Control Conv) / Control Conv | 广告带来的增量转化率 |
+| **CPA Ratio** | Holdout CPA / Exposed CPA | 广告效率 vs 无广告基准 |
+| **True ROAS** | Uplift Conv × Avg Order Value / Ad Spend | 真实广告回报 |
+
+## Connections
+- [[PaidMediaTrackingSpecialist]]：增量测试需要可靠的转化追踪基础设施
+- [[BudgetPacing]]：增量测试结果用于指导预算分配决策
+- [[CrossPlatformPlanning]]：跨平台增量贡献衡量，指导平台预算分配
diff --git a/wiki/concepts/IndexingStrategies.md b/wiki/concepts/IndexingStrategies.md
new file mode 100644
index 00000000..d91f0204
--- /dev/null
+++ b/wiki/concepts/IndexingStrategies.md
@@ -0,0 +1,42 @@
+---
+title: "Indexing Strategies"
+type: concept
+tags: [database, postgresql, index, performance, mysql, supabase]
+last_updated: 2026-05-01
+---
+
+# Indexing Strategies
+
+## Definition
+
+数据库索引策略是指根据查询模式和数据特征选择合适的索引类型和结构的实践方法，目的是加速数据检索同时控制写入开销和存储成本。
+
+## Index Types
+
+| 类型 | 适用场景 | 示例 |
+|------|---------|------|
+| **B-tree** | 等值查询、范围查询、排序（默认首选） | `CREATE INDEX ON users(email)` |
+| **GiST** | 几何数据、全文搜索、Range 类型 | `CREATE INDEX ON documents USING GIN(to_tsvector('english', content))` |
+| **GIN** | JSON/数组字段、全文搜索 | `CREATE INDEX ON posts USING GIN(metadata)` |
+| **部分索引（Partial）** | 高频过滤条件（如下线状态） | `CREATE INDEX ON orders WHERE status = 'pending'` |
+| **复合索引（Composite）** | 多列过滤 + 排序 | `CREATE INDEX ON posts(status, created_at DESC)` |
+
+## Aliases
+- Composite Index
+- Partial Index
+- Covering Index
+
+## Key Principles
+
+1. **外键必须加索引**：用于 JOIN 性能
+2. **高频 WHERE 条件优先建索引**：但避免对低选择性列（如性别）建单列索引
+3. **复合索引列顺序**：等值列在前，范围列在后
+4. **避免 SELECT \***：只查需要的列，利于索引覆盖（covering index）
+
+## Source
+- [[engineering-database-optimizer]]
+
+## Connections
+- [[QueryPlanAnalysis]] — 索引效果通过 EXPLAIN ANALYZE 验证
+- [[SchemaDesign]] — 索引是 Schema 设计的关键组成部分
+- [[engineering-backend-architect]] — 架构设计时需考虑索引策略
diff --git a/wiki/concepts/Infrastructure as Code.md b/wiki/concepts/Infrastructure as Code.md
new file mode 100644
index 00000000..ab50f8fd
--- /dev/null
+++ b/wiki/concepts/Infrastructure as Code.md	
@@ -0,0 +1,57 @@
+---
+title: "Infrastructure as Code"
+type: concept
+tags: [DevOps, Cloud, Automation]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
+---
+
+# Infrastructure as Code
+
+## 定义
+基础设施即代码（Infrastructure as Code，IaC）是一种通过代码定义和管理云基础设施的方法，替代传统手动配置，实现基础设施的可重复性、可版本控制和可测试性。
+
+## 核心原则
+1. **声明式配置**：描述期望的最终状态，而非执行的具体步骤
+2. **幂等性**：多次执行产生相同结果
+3. **版本控制**：所有配置存储在 Git 等版本控制系统
+4. **可重复性**：同一代码在不同环境生成相同基础设施
+5. **自动化测试**：基础设施变更经过测试验证
+
+## 核心工具
+- **Terraform**：声明式、多云支持（AWS/GCP/Azure）
+- **AWS CloudFormation**：AWS 原生声明式服务
+- **AWS CDK**：使用编程语言（TypeScript/Python）定义云资源
+- **Ansible**：配置管理 + 基础设施编排
+- **Pulumi**：使用通用编程语言定义基础设施
+
+## 在 DevOps Automator 中的应用
+- 使用 Terraform 定义 AWS Auto-scaling groups、ALB、CloudWatch alarms
+- 通过 `terraform plan` 预览变更，通过 `terraform apply` 自动部署
+- 支持多环境管理（dev/staging/prod）
+
+## 相关概念
+- [[CI/CD Pipeline]]：IaC 变更通过 CI/CD 流水线自动化部署
+- [[Terraform]]：DevOps Automator 默认使用的 IaC 工具
+- [[GitOps]]：基于 Git 的 IaC 运维模式
+
+## 最佳实践
+- 状态文件存储在远程后端（S3 + DynamoDB）
+- 使用 workspaces 或目录分离多环境
+- 模块化设计，复用公共组件
+- 敏感信息使用 Vault 或 AWS Secrets Manager
+
+## 与传统运维的对比
+| 维度 | 传统运维 | IaC |
+|------|----------|-----|
+| 速度 | 手动配置耗时 | 分钟级自动部署 |
+| 一致性 | 人为差异 | 完全一致 |
+| 版本控制 | 无 | 完整历史记录 |
+| 回滚 | 困难 | 一键回滚 |
+| 审计 | 日志分散 | 集中可追溯 |
+
+## Aliases
+- IaC
+- Infrastructure as Code
+- 基础设施即代码
+- Configuration as Code
diff --git a/wiki/concepts/Infrastructure-as-Code.md b/wiki/concepts/Infrastructure-as-Code.md
index f67a4886..2f52794e 100644
--- a/wiki/concepts/Infrastructure-as-Code.md
+++ b/wiki/concepts/Infrastructure-as-Code.md
@@ -1,49 +1,49 @@
----
-title: "Infrastructure as Code"
-type: concept
-tags: [DevOps, AWS, Terraform, Automation]
-sources: [ctp-topic-3-deploy-and-maintain-infrastructure, ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments, ctp-topic-33-an-introduction-to-gitops, ctp-topic-56-automated-infrastructure-testing, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, cloud-operating-model-key-strategies-and-best-practices]
-last_updated: 2026-05-05
----
-
-# Infrastructure as Code
-
-## Definition
-基础设施即代码（Infrastructure as Code, IaC）是一种通过机器可读的定义文件（而非物理硬件配置或交互式配置工具）管理和配置计算基础设施的方法。
-
-## Core Principles
-- **声明式配置**：描述期望的最终状态，而非执行的具体步骤
-- **版本控制**：所有基础设施定义文件存储在 Git 中
-- **幂等性**：多次执行产生相同结果
-- **可重复性**：同一模板可在不同环境快速部署
-- **自动化**：与 CI/CD 流水线集成
-
-## Key Tools
-- **Terraform**：HashiCorp 出品，云厂商无关的 IaC 工具，通过状态文件管理资源
-- **Terragrunt**：Terraform 轻量封装，贯彻 DRY 原则
-- **AWS CloudFormation**：AWS 原生 IaC 服务，JSON/YAML 模板
-- **Pulumi**：编程语言驱动的 IaC 平台
-- **Ansible**：配置管理和应用部署工具
-
-## Terraform Ecosystem
-- **Gruntwork**：预建 Terraform 模块库，生产级参考架构
-- **Atlantis**：Git 集成 Terraform 部署，PR 评论式协作
-- **Terratest**：Terraform 代码的 Go 测试框架
-- **tfsec**：Terraform 静态安全分析工具
-- **TFLint**：Terraform 代码规范检查
-
-## IaC in CTP Context
-CTP（Cloud Transformation Programme）使用 Terraform/Terragrunt 构建 AWS Landing Zone：
-- [[ctp-topic-3-deploy-and-maintain-infrastructure]]：Terragrunt HCL 文件与模块化管理
-- [[ctp-topic-9-ci-cd-with-gruntwork]]：Gruntwork CI/CD 流水线实践
-- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比选型
-- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]：Atlantis 替代 Jenkins
-- [[ctp-topic-56-automated-infrastructure-testing]]：TerraTest 自动化测试
-- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：ECS IaC 部署实践
-
-## Related Concepts
-- [[GitOps]]：Git 作为 IaC 的单一真相来源
-- [[CI/CD Pipeline]]：IaC 与 CI/CD 流水线的集成
-- [[Policy-as-Code]]：IaC 扩展至安全合规策略
-- [[Canary-Deployment]]：基于 IaC 的金丝雀部署策略
-- [[Atlantis]]：GitOps 驱动的 Terraform 协作工具
+---
+title: "Infrastructure as Code"
+type: concept
+tags: [DevOps, AWS, Terraform, Automation]
+sources: [ctp-topic-3-deploy-and-maintain-infrastructure, ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments, ctp-topic-33-an-introduction-to-gitops, ctp-topic-56-automated-infrastructure-testing, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, cloud-operating-model-key-strategies-and-best-practices, learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform, engineering-devops-automator]
+last_updated: 2026-04-14
+---
+
+# Infrastructure as Code
+
+## Definition
+基础设施即代码（Infrastructure as Code, IaC）是一种通过机器可读的定义文件（而非物理硬件配置或交互式配置工具）管理和配置计算基础设施的方法。
+
+## Core Principles
+- **声明式配置**：描述期望的最终状态，而非执行的具体步骤
+- **版本控制**：所有基础设施定义文件存储在 Git 中
+- **幂等性**：多次执行产生相同结果
+- **可重复性**：同一模板可在不同环境快速部署
+- **自动化**：与 CI/CD 流水线集成
+
+## Key Tools
+- **Terraform**：HashiCorp 出品，云厂商无关的 IaC 工具，通过状态文件管理资源
+- **Terragrunt**：Terraform 轻量封装，贯彻 DRY 原则
+- **AWS CloudFormation**：AWS 原生 IaC 服务，JSON/YAML 模板
+- **Pulumi**：编程语言驱动的 IaC 平台
+- **Ansible**：配置管理和应用部署工具
+
+## Terraform Ecosystem
+- **Gruntwork**：预建 Terraform 模块库，生产级参考架构
+- **Atlantis**：Git 集成 Terraform 部署，PR 评论式协作
+- **Terratest**：Terraform 代码的 Go 测试框架
+- **tfsec**：Terraform 静态安全分析工具
+- **TFLint**：Terraform 代码规范检查
+
+## IaC in CTP Context
+CTP（Cloud Transformation Programme）使用 Terraform/Terragrunt 构建 AWS Landing Zone：
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]]：Terragrunt HCL 文件与模块化管理
+- [[ctp-topic-9-ci-cd-with-gruntwork]]：Gruntwork CI/CD 流水线实践
+- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比选型
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]：Atlantis 替代 Jenkins
+- [[ctp-topic-56-automated-infrastructure-testing]]：TerraTest 自动化测试
+- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：ECS IaC 部署实践
+
+## Related Concepts
+- [[GitOps]]：Git 作为 IaC 的单一真相来源
+- [[CI/CD Pipeline]]：IaC 与 CI/CD 流水线的集成
+- [[Policy-as-Code]]：IaC 扩展至安全合规策略
+- [[Canary-Deployment]]：基于 IaC 的金丝雀部署策略
+- [[Atlantis]]：GitOps 驱动的 Terraform 协作工具
diff --git a/wiki/concepts/IngestWorkflow.md b/wiki/concepts/IngestWorkflow.md
new file mode 100644
index 00000000..c5e8399f
--- /dev/null
+++ b/wiki/concepts/IngestWorkflow.md
@@ -0,0 +1,33 @@
+---
+title: "IngestWorkflow"
+type: concept
+tags: [workflow, knowledge-management, llm]
+sources: [llm-wiki]
+last_updated: 2026-05-02
+---
+
+## Overview
+导入工作流（Ingest Workflow）是 [[PersistentWiki]] 的核心运营模式之一——当新源添加到 `raw/` 目录时，LLM 读取、处理并将其整合到 Wiki 中。
+
+## Standard Process（9步）
+1. **读取源文件**：完整读取待摄取的源文档
+2. **了解上下文**：读取 `wiki/index.md` 和 `wiki/overview.md`
+3. **生成 Source Page**：创建 `wiki/sources/<slug>.md`（参照 Source Page Format）
+4. **更新 Index**：在 `wiki/index.md` 的 Sources 节添加新条目
+5. **更新 Overview**：如有修订必要时更新综合摘要
+6. **更新/创建 Entity 页面**：为关键人物/公司/项目创建或更新实体页
+7. **更新/创建 Concept 页面**：为关键想法和框架创建或更新概念页
+8. **检测冲突**：记录与现有 Wiki 内容的矛盾
+9. **追加 Log**：在 `wiki/log.md` 中追加时间线条目
+
+## Trigger
+触发方式：用户说 "ingest <file>" 或 "摄取这个文件：raw/xxx.md"
+
+## Design Principles
+- **一次源可能影响 10-15 个 Wiki 页面**：更新实体、概念、摘要、交叉引用
+- **单源优于批量**：作者偏好一次导入一个源并全程参与，可更好把控知识整合质量
+- **批量可行**：也可以一次性批量导入，减少监督
+
+## Related Workflows
+- [[QueryWorkflow]]：查询工作流——用户提问，LLM 从 Wiki 检索答案
+- [[LintWorkflow]]：检查工作流——定期健康检查 Wiki 质量
diff --git a/wiki/concepts/Internal-Controls.md b/wiki/concepts/Internal-Controls.md
new file mode 100644
index 00000000..79d262b1
--- /dev/null
+++ b/wiki/concepts/Internal-Controls.md
@@ -0,0 +1,54 @@
+---
+title: "Internal Controls"
+type: concept
+tags: [finance, accounting, compliance]
+sources: [finance-bookkeeper-controller]
+last_updated: 2026-05-02
+---
+
+## Definition
+内部控制（Internal Controls）是企业为确保财务报告可靠性、运营效率和合规性而建立的政策和程序体系。
+
+## Control Design Components
+- **Authorization Matrices**：授权矩阵，定义谁有权批准哪些类型的交易
+- **Approval Workflows**：审批工作流，确保所有重大交易经过适当审批
+- **System Access Controls**：系统访问控制，限制对敏感财务系统的访问
+- **Data Validation Rules**：数据验证规则，防止无效或未经授权的数据进入系统
+
+## Control Monitoring
+- 关键控制测试
+- 例外情况跟踪
+- 整改管理
+
+## SOX Compliance
+萨班斯-奥克斯利法案（SOX）对公众公司的内部控制提出了强制性要求：
+- 控制文档化
+- 测试计划
+- 缺陷跟踪
+- 管理层声明
+
+## Segregation of Duties
+职责分离是内部控制的核心原则：
+- 交易发起人 ≠ 审批人
+- 交易审批人 ≠ 记录人
+> "The person who initiates a transaction should not be the same person who approves or records it."
+
+## Policy Maintenance
+- 会计政策文档化
+- 程序手册维护
+- 授权矩阵更新
+
+## Core Principle
+> "Internal controls exist because humans make mistakes (and occasionally worse). Trust but verify — then verify again."
+> — Dana, Bookkeeper & Controller Agent
+
+## Success Metrics
+- 内部控制例外率 < 3%
+- 所有控制按测试计划执行
+- 零 SOX 重大缺陷
+
+## Related Concepts
+- [[Segregation-Of-Duties]]
+- [[Audit Readiness]]
+- [[GAAP-Compliance]]
+- [[Account-Reconciliation]]
diff --git a/wiki/concepts/Intersectionality.md b/wiki/concepts/Intersectionality.md
new file mode 100644
index 00000000..87282a7d
--- /dev/null
+++ b/wiki/concepts/Intersectionality.md
@@ -0,0 +1,37 @@
+---
+title: "Intersectionality"
+type: concept
+tags: []
+last_updated: 2026-05-15
+---
+
+## Definition
+
+Intersectionality（交叉性）——一种分析框架，用于理解社会身份（如种族、性别、阶级、残障、国籍等）的交叉重叠如何产生独特的歧视和特权模式。该概念最早由 Kimberlé Crenshaw 于 1989 年提出，现已广泛应用于 UX 研究、品牌策略和 AI representation 领域。
+
+在 AI 图像/视频生成的语境中，intersectionality 指的是：文化、年龄、残障状况、社会经济地位等多维度交叉重叠下的人类身份表征，要求特定的提示词架构方法来确保每个维度都被准确、尊严地呈现。
+
+## Core Principles
+
+1. **Multiple Dimensions Simultaneously**：身份不是单一维度的叠加，而是在交叉点上产生独特体验
+2. **Non-Addictive Model**：不能用"多样性 = A + B + C"的加法模型，而要捕捉交叉点的独特性
+3. **Contextual Specificity**：同一身份在不同交叉点上可能有完全不同的表达
+
+## In AI Imagery Context
+
+Inclusive Visuals Specialist 代理人对 intersectionality 的技术处理：
+- **拒绝单维度 tokenization**：不能只指定"女性"或"黑人"，而要指定"45岁黑人女性高管，自然4C发型穿定制海军蓝西装"
+- **拒绝平均化渲染**：AI 倾向于生成"平均"面孔，intersectionality 要求 distinct facial structures
+- **拒绝刻板叠加**：不能简单叠加多个身份标签，而要捕捉身份之间的复杂互动
+
+## Related Concepts
+
+- [[Negative Prompting]]
+- [[Cultural Authenticity]]
+- [[Sociological Accuracy]]
+- [[Inclusive Visuals Specialist]]
+
+## Aliases
+
+- 交叉性
+- 交叉身份
diff --git a/wiki/concepts/Investment-Analysis.md b/wiki/concepts/Investment-Analysis.md
new file mode 100644
index 00000000..eeb7f624
--- /dev/null
+++ b/wiki/concepts/Investment-Analysis.md
@@ -0,0 +1,58 @@
+---
+title: "Investment Analysis (NPV & IRR)"
+type: concept
+tags: ["finance", "investment", "npv", "irr"]
+last_updated: 2026-04-30
+---
+
+## Definition
+投资分析是通过量化方法评估投资项目的可行性和盈利能力的财务决策框架，核心指标包括 NPV（净现值）、IRR（内部收益率）和投资回收期（Payback Period）。
+
+## Core Metrics
+
+### NPV (Net Present Value)
+```
+NPV = -初始投资 + Σ(第i期现金流 / (1 + 贴现率)^i)
+```
+- **正值**：项目创造价值，值得投资
+- **负值**：项目摧毁价值，不建议投资
+- **零值**：项目盈亏平衡
+
+### IRR (Internal Rate of Return)
+使 NPV = 0 的贴现率 r：
+```
+Σ(第i期现金流 / (1 + r)^i) - 初始投资 = 0
+```
+- **IRR > 贴现率**：项目可行
+- **IRR < 贴现率**：项目不可行
+- IRR 通过数值求解（如 `scipy.optimize.fsolve`）获得
+
+### Payback Period
+累计现金流首次超过初始投资的时间（以年为单位）：
+```
+Payback = (n - 1) + (初始投资 - 累计现金流_{n-1}) / 第n期现金流
+```
+
+### ROI
+```
+ROI = (Σ现金流 - 初始投资) / 初始投资 × 100%
+```
+
+## Decision Matrix
+| NPV | IRR | Payback | 风险评分 | 建议 |
+|-----|-----|---------|---------|------|
+| >0 | >贴现率 | <3年 | <3 | STRONG BUY |
+| >0 | >贴现率 | 任意 | ≥3 | CONDITIONAL BUY |
+| ≤0 或 IRR ≤ 贴现率 | — | — | — | DO NOT INVEST |
+
+## Target Returns
+- 平均 ROI：**25%+**
+- Payback Period：**<3年**
+- 风险评分：**<3**
+
+## Implementation
+参见 [[support-finance-tracker]] 中 `InvestmentAnalyzer` Python 类的实现，包含 NPV、IRR、Payback Period 和 ROI 的完整计算逻辑。
+
+## Related Concepts
+- [[Cash Flow Forecasting]]：投资分析的现金流输入依赖预测数据
+- [[Budget Variance Analysis]]：项目执行层面的财务监控
diff --git a/wiki/concepts/Journal-Entry.md b/wiki/concepts/Journal-Entry.md
new file mode 100644
index 00000000..1d69391f
--- /dev/null
+++ b/wiki/concepts/Journal-Entry.md
@@ -0,0 +1,52 @@
+---
+title: "Journal Entry"
+type: concept
+tags: [finance, accounting]
+sources: [finance-bookkeeper-controller]
+last_updated: 2026-05-02
+---
+
+## Definition
+日记账分录（Journal Entry，JE）是记录非标准或手工财务交易的机制，每笔分录必须满足 GAAP 合规要求并附带完整支持文档和审批记录。
+
+## Entry Types
+
+### Standard Recurring Entries
+- 折旧和摊销
+- 租金和保险
+- 工资税和福利应计
+- 预付账款摊销
+
+### Adjusting Entries
+- 期末调整（未入账收入/费用）
+- 纠正错误分录
+- 会计估计调整
+
+### Reclassification Entries
+- 账户重分类
+- 往来科目调整
+
+### Elimination Entries
+- 关联方交易抵销
+- 合并报表抵销
+
+## Documentation Requirements
+> "Journal entries require documentation. Every manual journal entry needs a description, supporting documentation, and approval. 'Adjusting entry' is not a description."
+
+### Must Include
+1. **Description**：详细描述经济业务实质（如"记录11月水电费应计，根据11/15抄表数据"）
+2. **Supporting Documentation**：发票、合同、计算底稿、邮件确认等
+3. **Approval**：授权人审批记录
+4. **Date & Period**：入账日期和所属期间
+
+## Automation Philosophy
+> "Automate the recurring, focus the brain on the exceptional. Manual journal entries should be the exception, not the rule."
+
+## Prior Period Adjustments
+> "Never adjust prior periods without disclosure. If a correction impacts previously reported numbers, document the impact and communicate to stakeholders."
+
+## Related Concepts
+- [[Month-End-Close-Process]]
+- [[Account Reconciliation]]
+- [[GAAP-Compliance]]
+- [[Internal Controls]]
diff --git a/wiki/concepts/KarpmanDramaTriangle.md b/wiki/concepts/KarpmanDramaTriangle.md
new file mode 100644
index 00000000..9c2a35e5
--- /dev/null
+++ b/wiki/concepts/KarpmanDramaTriangle.md
@@ -0,0 +1,37 @@
+---
+title: "Karpman Drama Triangle"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# Karpman Drama Triangle
+
+## Aliases
+- Drama Triangle
+- Karpman Triangle
+- Victim Triangle
+
+## Definition
+Karpman 戏剧三角——识别人际互动中最常见的三种心理角色位置及其动态转换。
+
+## Three Roles
+
+| 角色 | 核心信念 | 典型行为 |
+|------|----------|----------|
+| **Victim（受害者）** | "我不能"、"我无能为力" | 求助、依赖、被动承受 |
+| **Persecutor（迫害者）** | "都是你的错" | 指责、控制、批评 |
+| **Rescuer（拯救者）** | "你需要我的帮助" | 过度介入、隐性控制 |
+
+## Dynamic Transitions
+戏剧三角的核心机制是**角色转换**：
+- Rescuer → Victim：拯救失败后转向受害者心态
+- Victim → Persecutor：长期无力感积累后转向攻击
+- Persecutor → Victim：被迫承担时转为受害者
+
+## Application in Character Design
+Psychologist Agent 使用此框架映射角色间的权力动态和沟通模式，识别冲突升级的具体触发点。
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/Kinship-System.md b/wiki/concepts/Kinship-System.md
new file mode 100644
index 00000000..d4346823
--- /dev/null
+++ b/wiki/concepts/Kinship-System.md
@@ -0,0 +1,21 @@
+---
+title: "Kinship System"
+type: concept
+tags: ["anthropology", "kinship", "descent", "alliance", "inheritance"]
+last_updated: 2026-04-25
+---
+
+## Definition
+亲属制度——人类社会组织家族和继嗣关系的系统，决定了继承规则、政治联盟、居住模式和冲突解决方式，是社会的"基础设施"。
+
+## Core Framework
+- **继嗣规则**：父系（patrilineal）/ 母系（matrilineal）/ 双系（bilateral）/ 双重继嗣（double descent）
+- **居住模式**：父居（patrilocal）/ 母居（matrilocal）/ 新居（neolocal）/ 舅居（avunculocal）
+- **亲属称谓**：Hawaiian（普遍互称）/ Eskimo（核心家庭特指）/ Sudanese（每个亲属关系独立称谓）/ Omaha（交叉表亲特指）
+- **交换理论**：Lévi-Strauss 认为亲属制度本质是女人的交换系统，通过婚姻建立联盟
+
+## Connections
+- [[Anthropologist-Agent]] ← must_design ← [[Kinship-System]]
+- [[Structuralism]] ← analyzes ← [[Kinship-System]]
+- [[Functionalism]] ← explains_functions_of ← [[Kinship-System]]
+- [[Gift-Economy]] ← parallels ← [[Kinship-System]]
diff --git a/wiki/concepts/Kirkpatrick-Model.md b/wiki/concepts/Kirkpatrick-Model.md
new file mode 100644
index 00000000..8f6b3a8d
--- /dev/null
+++ b/wiki/concepts/Kirkpatrick-Model.md
@@ -0,0 +1,44 @@
+---
+title: "Kirkpatrick Model"
+type: concept
+tags: [training-evaluation, learning-theory]
+sources: [corporate-training-designer]
+last_updated: 2026-05-29
+---
+
+## Definition
+
+Kirkpatrick 四级培训评估模型由 Donald Kirkpatrick 于 1959 年提出，是企业培训效果评估的全球通用框架，从学员反应到业务结果分为四个层级，是衡量培训真实价值的核心工具。
+
+## Four Levels
+
+### Level 1 — Reaction（反应）
+- 测量学员对培训的满意程度
+- 方法：培训满意度问卷调查——课程评分、讲师评分、NPS（Net Promoter Score）
+- 指标：满意度 ≥ 4.5/5.0，NPS ≥ 50
+
+### Level 2 — Learning（学习）
+- 测量学员在知识、技能和态度方面的学习成果
+- 方法：知识考试、技能实操评估、案例分析作业
+- 指标：关键课程考试通过率 ≥ 90%
+
+### Level 3 — Behavior（行为）
+- 测量学员在实际工作中行为改变的程度
+- 方法：训后30/60/90天行为追踪——主管观察、关键行为检查清单
+- 指标：训后90天行为改变率 ≥ 60%
+- 要求：高投资培训项目（领导力、关键岗位）必须追踪到 Level 3
+
+### Level 4 — Results（结果）
+- 测量培训对业务指标的最终影响
+- 方法：追踪业务指标变化（营收、客户满意度、生产效率、员工留存）
+- 指标：可量化的业务影响（如：新员工上手时间缩短、客户满意度提升）
+
+## Key Principles
+- **层级递进**：Level 1 是基础，Level 4 是终极目标——逐级验证才能确保培训真正创造价值
+- **必须量化**：培训目标必须可测量——不是"提高沟通技能"，而是"3个月内将新员工独立完成客户提案的比例从40%提升至70%"
+- **用业务语言汇报**：向业务部门汇报培训价值时，使用业务指标而非培训指标
+
+## Connections
+- [[Kirkpatrick-Model]] ← evaluation_framework ← [[ADDIE-Model]]（ADDIE 的 E 阶段通常采用 Kirkpatrick 四级评估）
+- [[Kirkpatrick-Model]] ← evaluation_standard ← [[Corporate-Training-Designer]]（培训设计师必须掌握的核心评估方法）
+- [[Bloom-Taxonomy]] ← learning_objective_framework ← [[Kirkpatrick-Model]]（Bloom 定义"学到什么"，Kirkpatrick 验证"学到了没有"）
diff --git a/wiki/concepts/Kishotenketsu.md b/wiki/concepts/Kishotenketsu.md
new file mode 100644
index 00000000..e80284cb
--- /dev/null
+++ b/wiki/concepts/Kishotenketsu.md
@@ -0,0 +1,36 @@
+---
+title: "Kishōtenketsu"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Kishōtenketsu
+- 起承転結
+- Kishotenketsu Structure
+
+## Overview
+Kishōtenketsu（起承転結）是日本/东亚四幕叙事结构，由四个阶段组成：起（Introduction）、承（Development）、転（Twist）、結（Conclusion）。与西方三幕式的"冲突驱动"不同，Kishōtenketsu 的第三幕" Twist"不必须有冲突，而是引入意外元素，与前两幕形成对比，创造张力和趣味。
+
+## Four Stages
+
+| Stage | Kanji | Description |
+|-------|-------|-------------|
+| **起 Ki (Introduction)** | 起 | 介绍人物、环境、情境 |
+| **承 Sho (Development)** | 承 | 展开/深化已建立的内容 |
+| **転 Ten (Twist)** | 転 | 引入意外或无关元素，创造转折 |
+| **結 Ketsu (Conclusion)** | 結 | 综合前四部分，赋予新意义 |
+
+## Key Difference from Western Structure
+- **三幕式**：第三幕必须有危机/高潮（Conflict-driven）
+- **Kishōtenketsu**：第三幕只是引入对比，不强制冲突——高潮可能出现在第四幕
+
+## Examples
+- 许多日漫（如《哆啦A梦》单集）：建立日常 → 深化日常 → 引入神奇道具 → 意外结果
+- [[Academic Narratologist]] 将其作为**跨文化叙事比较**的核心工具
+
+## Relationship to Other Concepts
+- [[Three-Act-Structure]]：西方对应模型，但缺少独立的"Twist"阶段
+- [[HeroesJourney]]：Hero's Journey 的结构是冲突驱动的，与 Kishōtenketsu 不同
diff --git a/wiki/concepts/Korean-Corporate-Hierarchy.md b/wiki/concepts/Korean-Corporate-Hierarchy.md
new file mode 100644
index 00000000..38c1a9da
--- /dev/null
+++ b/wiki/concepts/Korean-Corporate-Hierarchy.md
@@ -0,0 +1,86 @@
+---
+title: "Korean-Corporate-Hierarchy"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-05-30
+---
+
+## 基本信息
+- **原文**：한국 기업 직급 체계
+- **中文**：韩国企业职级体系
+- **英文**：Korean Corporate Title System
+
+## 定义
+韩国企业职级体系（직급 체계）是韩国商业文化的核心结构之一。与西方扁平化管理不同，韩国企业保持着严格的层级制度，每个职级都有明确的权利边界和沟通规范。理解和尊重这一体系是在韩国商业成功的关键前提。
+
+## 完整职级对照表
+
+| 韩文 | 英文对应 | 中文 | 决策权力 | 典型特征 |
+|------|---------|------|---------|---------|
+| 회장（Hoejang） | Chairman | 会长 | 最高权威 | 基本不直接互动 |
+| 사장（Sajang） | CEO/President | 社长 | 最终商业决策 | 通常通过副会长/事业部长汇报 |
+| 부사장（Bujajang） | Vice President | 副会长 | 高管级决策 | 重大交易直接参与 |
+| 전무（Jeonmu） | Senior Managing Director | 专务 | 重大影响力 | 通常是事业部或子公司一把手 |
+| 상무（Sangmu） | Managing Director | 常务 | 部门级权威 | 大型部门或核心子公司负责人 |
+| 이사（Isa） | Director | 理事 | 项目级决策 | 可独立推进项目 |
+| 부장（Bujang） | General Manager | 部长 | 团队级，很多是你的一线联系人 | 有一定自主决策权 |
+| 차장（Chajang） | Deputy Manager | 次长 | 执行权威 | 执行层，通常是实际操作的人 |
+| 과장（Gwajang） | Manager | 课长 | 很小的独立权力 | 通常是初次接触的入口点 |
+| 대리（Daeri） | Assistant Manager | 代理 | 有限权力，但是很好的信息来源 | 职位低但信息量大 |
+
+## 称呼规范（必须遵守）
+
+**核心规则**：永远使用 **职称 + 님（nim）** 的格式
+
+| 正确称呼 | 错误称呼 |
+|---------|---------|
+| 사장님 | 사장 |
+| 부장님 |部长 |
+| 과장님 | 과장 |
+| 김과장님 | 김과장（除非关系非常亲密）|
+
+### 何时可以用名字
+- 只有当对方明确邀请你直呼其名时
+- 通常在经过多年合作、且对方主动说"以后叫我名字就好"之后
+- 即使可以叫名字，在正式场合仍建议使用职称
+
+## 决策权力映射
+
+| 你的联系人职级 | 能独立决定 | 需要上报 | 备注 |
+|---------------|-----------|---------|------|
+| 대리/과장 | 极小（内部门协调） | 几乎所有 | 不要期待决策 |
+| 차장 | 小（执行细节） | 大多数 | 能提供内部信息 |
+| 부장 | 中等（团队级） | 预算/跨部门 | 通常是你的主要联系人 |
+| 이사 | 较大（项目级） | 大额预算 | 有一定影响力 |
+| 상무以上 | 大（部门级） | 集团层面 | 品의发起人 |
+
+## 级别间互动潜规则
+1. **永远不要绕过级别联系上级** — 即使你直接联系了社长，他也会把事情推回给层级下属
+2. **信息自下而上流动** — 部长是连接你和高层的主要信息通道
+3. **级别决定座位/餐饮顺序** — 회식中体现最明显
+4. **Email 礼仪** — 发送给部长时，通常抄送 차장/과장，实际执行者需要知情
+
+## 关于"越级"的严重后果
+
+> **永远不要绕过你的联系人直接联系其上级**
+
+这在韩国商业中不是"高效率"，而是**关系终结行为**。后果包括：
+- 你的联系人会感到被羞辱和背叛
+- 对方公司会将你标记为"不懂规矩的外国人"
+- 未来的合作大门关闭
+- 你的联系人即使后来离开了，你也会被整个公司记住
+
+**例外**：只有在联系人明确授权时说"我会直接联系社长"才可越级。
+
+## SME vs 财阀的层级差异
+
+| 维度 | SME | 财阀 |
+|------|-----|------|
+| 层级数 | 3-5 级 | 7-10 级 |
+| 扁平化程度 | 较高，部长可直接决策 | 极低，每级都有 gatekeeper |
+| 外国人直接接触高层可能性 | 存在 | 几乎不可能 |
+| 决策周期 | 短 | 极长 |
+
+## 来源
+- [[specialized-korean-business-navigator]] — Korean Corporate Title Hierarchy 完整规范
diff --git a/wiki/concepts/Kraljic-Matrix.md b/wiki/concepts/Kraljic-Matrix.md
new file mode 100644
index 00000000..3baf0f2f
--- /dev/null
+++ b/wiki/concepts/Kraljic-Matrix.md
@@ -0,0 +1,44 @@
+---
+title: "Kraljic Matrix"
+type: concept
+tags: ["supply-chain", "procurement", "strategy", "category-management"]
+last_updated: 2026-04-25
+---
+
+## Aliases
+- Kraljic 采购矩阵
+- Kraljic Model
+
+## Definition
+
+Kraljic Matrix（克拉利克矩阵）是由 Peter Kraljic 于 1983 年提出的供应商分类与采购战略框架，通过两个维度将采购品类划分为四类，以制定差异化的采购策略。
+
+## Two Dimensions
+- **利润影响（Profit Impact）**：该品类对公司利润/成本的影响力
+- **供应风险（Supply Risk）**：供应市场的复杂性、供应商集中度、替代难度等
+
+## Four Quadrants
+
+| 类别 | 特征 | 策略 |
+|------|------|------|
+| **战略型（Strategic）** | 高利润影响 + 高供应风险 | 建立长期合作伙伴关系，共同投资，深度供应商协同 |
+| **杠杆型（Leverage）** | 高利润影响 + 低供应风险 | 充分利用采购量杠杆，竞争性招标，追求最优价格 |
+| **瓶颈型（Bottleneck）** | 低利润影响 + 高供应风险 | 寻找替代方案，降低依赖，确保供应连续性 |
+| **常规型（Routine）** | 低利润影响 + 低供应风险 | 简化采购流程，标准化，自动化的机会 |
+
+## Key Insights
+
+- 每年至少重新评估一次品类定位，动态调整采购策略
+- 战略型品类需配备专职采购经理，建立战略合作伙伴关系
+- 瓶颈型品类应主动寻找替代物料或开发多个供应源
+- 常规型品类可通过电子采购平台实现自动化，降低交易成本
+
+## Applications
+
+- [[Supply Chain Strategist Agent]] 使用 Kraljic Matrix 进行分类采购策略开发
+- 采购支出分析（spend analysis）通常作为矩阵定位的数据基础
+- 可结合 ABC 分类（按采购金额）对品类进一步细分
+
+## Connections
+- [[Supply Chain Strategist Agent]] ← uses_framework ← [[Kraljic Matrix]]
+- [[TCO]] ← related_to ← [[Kraljic Matrix]]（战略型品类 TCO 评估尤为重要）
diff --git a/wiki/concepts/LLM-Wiki.md b/wiki/concepts/LLM-Wiki.md
index ded94b82..e4f21121 100644
--- a/wiki/concepts/LLM-Wiki.md
+++ b/wiki/concepts/LLM-Wiki.md
@@ -1,51 +1,51 @@
----
-title: "LLM Wiki"
-type: concept
-tags: [AI知识管理, 知识系统, RAG对比]
-sources: []
-last_updated: 2026-04-09
----
-
-# LLM Wiki
-
-## 描述
-让 AI 增量构建和维护一个持久化的 Wiki 系统，页面之间互相链接，知识越积越厚。
-
-## 核心理念（来自 Karpathy 2026-03 分享）
-
-### RAG 模式的问题
-"每次从零检索"，知识不积累。
-
-### LLM Wiki 的优势
-- AI 在执行任务过程中顺手维护链接
-- 更新摘要
-- 添加 Tag
-- 标记新旧矛盾
-- 页面间互相链接，知识越积越厚
-- 不是被动等着被查询
-
-## 与 RAG 的对比
-
-| 维度 | RAG | LLM Wiki |
-|------|-----|----------|
-| 知识积累 | 每次从零检索 | 增量构建 |
-| 上下文 | 临时检索 | 持久化链接 |
-| 关系 | 独立文档 | 互相链接形成网络 |
-| 维护 | 被动等待查询 | 主动更新 |
-
-## 实现案例
-
-### 用户实践（养虾日记3）
-- **Obsidian 做知识库**（多端同步）
-- **Gitea 做版本控制**（Git 历史）
-- **OpenClaw 做写入接口**（obsidian skill）
-- AI 在执行任务的过程中顺手维护链接、更新摘要、添加 Tag、标记新旧矛盾
-
-### 相关工具
-- [[Obsidian]]：本地 Wiki 载体
-- [[Gitea]]：版本控制
-- [[OpenClaw]]：写入接口
-
-## 相关来源
-- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
-- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]]
+---
+title: "LLM Wiki"
+type: concept
+tags: [AI, knowledge-base, persistence]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki, 养虾日记3]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- LLM-based Wiki
+- LLM Wiki 模式
+- Persistent Wiki
+- Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库
+
+## Definition
+Karpathy 提出的个人知识管理范式——让 LLM **增量构建和维护**一个持久化的 Wiki（互相链接的 Markdown 文件集合），而不是像 RAG 那样每次查询从零检索。
+
+## Core Architecture
+三层架构：
+1. **Raw Sources**：原始文档（永远不修改）
+2. **Wiki**：结构化摘要页面，互相链接
+3. **Schema**：[[LLM Wiki]] 的方法论沉淀
+
+## Core Principles
+- **知识编译一次，持续保持最新**：不是每次查询时从零推导，而是预先建立知识网络
+- **AI 承担"记账式"维护工作**：总结、交叉引用、归档、更新摘要
+- **人类只负责**：筛选资料、提出问题、思考意义
+- **维护成本趋近于零**：AI 不会厌倦，不会忘记，一次操作可以改十五个文件
+- **核心比喻**（[[llm-wiki]]）：**"Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库"**
+
+## Relationship to Second Brain
+- 属 [[Second Brain]] 的架构理论层
+- [[养虾日记3]] 记录了将 LLM Wiki 理念落地到 [[Obsidian]] + [[OpenClaw]] 持久化笔记系统的全过程
+
+## Origins
+灵感源自 Vannevar Bush 的 **Memex**（1945）——一种设想中的"将所有书籍、记录和通信连接起来的设备"。
+
+## Implementation Stack
+- **[[Obsidian]]**：本地笔记工具，Wiki 载体
+- **[[Obsidian Web Clipper]]**：采集网页文章为 Markdown
+- **[[Graph View]]**：图谱视图，做 Lint 健康检查和发现知识盲区
+- **[[Obsidian Git]]**：版本管理，自动 commit+push
+- **[[qmd]]**：本地 Markdown 搜索引擎（规模大时使用）
+- **[[Dataview]]**：frontmatter 数据库式查询（可选）
+- **[[Marp]]**：Wiki 内容导出为幻灯片（可选）
+
+## Connections
+- [[LLM Wiki]] ← 提出者 ← [[Karpathy]]
+- [[LLM Wiki]] ← 工具基础 ← [[Obsidian]]
+- [[LLM Wiki]] ← 对比/替代 → [[RAG]]
+- [[LLM Wiki]] ← 上层概念 ← [[Second Brain]]
diff --git a/wiki/concepts/LLM-as-a-Judge.md b/wiki/concepts/LLM-as-a-Judge.md
new file mode 100644
index 00000000..08e63412
--- /dev/null
+++ b/wiki/concepts/LLM-as-a-Judge.md
@@ -0,0 +1,46 @@
+---
+title: "LLM-as-a-Judge"
+type: concept
+tags: []
+sources: [engineering-autonomous-optimization-architect]
+last_updated: 2026-05-01
+---
+
+# LLM-as-a-Judge
+
+## Definition
+
+LLM-as-a-Judge——以一个 LLM 作为自动化评估器，对另一个 LLM（或同一 LLM 的不同配置）的输出质量进行持续量化评分。
+
+## Evaluation Framework
+
+在暗启动实验前必须建立明确的数学评分标准：
+
+| 维度 | 分数 | 说明 |
+|------|------|------|
+| JSON 格式正确性 | 5 分 | 输出是否结构化、可解析 |
+| 延迟 | 3 分 | 响应时间是否在 SLA 内 |
+| 准确性 | 5 分 | 内容是否符合要求 |
+| 幻觉检测 | -10 分 | 是否出现事实性错误 |
+
+## Why It Matters
+
+- **可扩展**：无需人工标注，自动评估 1000+ 次实验
+- **一致性**：相同标准持续应用，避免人工评审的主观波动
+- **速度**：可异步并行执行，不阻塞生产流量
+
+## Example Prompt
+
+```
+You are evaluating the output of Model B against Model A.
+Score from 1-10 on:
+1. Factual accuracy (5 points)
+2. JSON structure validity (3 points)
+3. Completeness (2 points)
+Deduct 10 points if hallucination is detected.
+```
+
+## Related
+
+- [[Autonomous-Optimization-Architect]]：实施 LLM-as-a-Judge 的核心 Agent
+- [[Shadow-Traffic]]：LLM-as-a-Judge 在影子测试中评估实验模型表现
diff --git a/wiki/concepts/LLMHandoff.md b/wiki/concepts/LLMHandoff.md
new file mode 100644
index 00000000..76de2eb2
--- /dev/null
+++ b/wiki/concepts/LLMHandoff.md
@@ -0,0 +1,58 @@
+---
+title: "LLMHandoff"
+type: concept
+tags: ["llm", "agent", "handoff", "transcription", "summarization"]
+last_updated: 2026-05-02
+---
+
+# LLMHandoff（LLM 交接协议）
+
+## Definition
+
+LLM Handoff 是在 Agent 管道中，将结构化数据（转录文本、会议记录、文档）传递给下游 LLM 进行摘要/问答/行动项提取的标准接口。定义格式化规则和任务指令，使下游 LLM 能准确理解输入并产生期望输出。
+
+## Purpose
+
+在 [[StructuredTranscriptJSON]] 基础上，LLM Handoff 定义：
+1. **格式化规则**：如何将带时间戳的段落转为 LLM 可读的文本格式
+2. **任务指令**：不同任务（摘要/问答/行动项）对应的 prompt 指令
+3. **Schema 输出**：LLM 应返回的结构化格式（如 action_items、summary 等）
+
+## Handoff Payload Format
+
+```json
+{
+  "task": "summarize",
+  "source_type": "transcript",
+  "source_id": "meeting-2026-05-02-001",
+  "total_duration": 3600.5,
+  "speakers": ["SPEAKER_00", "SPEAKER_01"],
+  "content": "[0.0s] <SPEAKER_00> Hello, welcome...\n[5.2s] <SPEAKER_01> Thank you...\n...",
+  "instructions": {
+    "summarize": "Produce a concise summary, section headers for topic changes, and a bulleted action items list with speaker attribution.",
+    "action_items": "Extract all action items and commitments with the speaker who made them and the timestamp.",
+    "qa": "Answer questions about the transcript using only information present in the content. Cite timestamps."
+  }
+}
+```
+
+## Downstream Integrations
+
+- [[LangChain]]：`ConversationalRetrievalChain` / `LLMChain`
+- CrewAI：`Agent` 接收 JSON payload 作为 context
+- 自定义 LLM 管道：直接读取 payload 并注入 system prompt
+
+## Critical Design Considerations
+
+- **保留时间戳锚点**：`[5.2s]` 格式使 LLM 能引用具体时刻
+- **说话人归属**：`[SPEAKER_00]` 前缀使 LLM 能区分不同发言人的观点
+- **分块交付**：超长转录可分批传递给 LLM（避免 token 超限）
+
+## Related Concepts
+- [[StructuredTranscriptJSON]] — Handoff 的输入数据格式
+- [[PIIRedaction]] — Handoff 前必须脱敏（避免 LLM 学习 PII）
+- [[SpeakerDiarization]] — 说话人标签是 Handoff 文本格式化的核心要素
+- [[Human-Handoff]] — LLM → 人类的交接（Agentic 系统中的另一方向）
+
+## Related Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/concepts/LLMWikiArchitecture.md b/wiki/concepts/LLMWikiArchitecture.md
new file mode 100644
index 00000000..99e63508
--- /dev/null
+++ b/wiki/concepts/LLMWikiArchitecture.md
@@ -0,0 +1,34 @@
+---
+title: "LLMWikiArchitecture"
+type: concept
+tags: [architecture, knowledge-management, llm]
+sources: [llm-wiki]
+last_updated: 2026-05-02
+---
+
+## Overview
+LLM Wiki 架构是 [[PersistentWiki]] 的结构化实现，采用三层架构：Raw Sources → Wiki → Schema。
+
+## Three Layers
+
+### Layer 1: Raw Sources（原始资源）
+- 用户精心收集的源文档：文章、论文、图像、数据文件
+- **不可变**：LLM 读取但不修改，是唯一的真实来源（Source of Truth）
+- 位于仓库的 `raw/` 目录
+
+### Layer 2: Wiki（知识层）
+- LLM 生成的 Markdown 文件目录
+- 包含：摘要页、实体页、概念页、综合分析、概览、索引
+- **LLM 完全拥有并维护**：创建页面、新来源到达时更新、维护交叉引用、保持一致性
+- 位于仓库的 `wiki/` 目录
+
+### Layer 3: Schema（模式文件）
+- 配置文件，告诉 LLM Wiki 的结构、约定和工作流
+- 例如：Claude Code 的 `CLAUDE.md`、Codex 的 `AGENTS.md`
+- 是让 LLM 成为"规范的 Wiki 维护者"而非"普通聊天机器人"的关键
+- 用户和 LLM 共同随时间演进
+
+## Design Philosophy
+- **人读 LLM 写**：用户消费 Wiki 内容，LLM 负责编写和维护
+- **LLM 不厌倦**：LLM 不会忘记更新交叉引用，一次可以处理多个文件
+- **维护成本接近零**：正是 LLM 承担维护工作，使 Wiki 可以持续运行
diff --git a/wiki/concepts/LSIF.md b/wiki/concepts/LSIF.md
new file mode 100644
index 00000000..e7143cb5
--- /dev/null
+++ b/wiki/concepts/LSIF.md
@@ -0,0 +1,39 @@
+---
+title: "LSIF"
+type: concept
+tags: ["LSP", "code-index", "semantic-index", "static-analysis", "pre-computed"]
+sources: ["lsp-index-engineer.md"]
+last_updated: 2026-04-29
+---
+
+## Definition
+LSIF（Language Server Index Format）是一种标准化的预计算语义索引格式，用于存储语言服务器已分析过的代码语义数据（如符号定义、引用、继承关系等），使代码智能工具无需实时运行 LSP 服务器即可提供导航功能。
+
+## Core Mechanism
+
+### 用途
+- **离线索引**：项目提前构建 LSIF 索引，CI/CD 阶段预先生成
+- **冷启动加速**：无需等待 LSP 服务器初始化，立即提供代码导航
+- **分发预索引数据**：发布 npm 包时附带已编译的 LSIF 索引
+- **跨工具共享**：同一索引可为多个工具（IDE/CLI/API）共用
+
+### 索引内容
+- 符号定义位置
+- 符号引用关系
+- 文档结构（文件树/大纲）
+- Hover 文档内容
+- 类型层次信息
+
+### 与 nav.index.jsonl 的关系
+LSIF 是 nav.index.jsonl 格式的导入/导出标准。graphd 支持：
+- **导出**：将内存中的语义图谱导出为 LSIF 格式
+- **导入**：将预先构建的 LSIF 索引加载到内存，加速启动
+
+## Implementation Notes
+LSP/Index Engineer 将 LSIF 视为 nav.index.jsonl 格式的上游标准，通过 LSIF 实现预计算语义数据的导入/导出。
+
+## Connections
+- [[LSIF]] ← is_standard_for ← [[SemanticCodeGraph]]
+- [[LSIF]] ← can_be_imported_by ← [[GraphDaemon]]
+- [[LSIF]] ← is_alternative_to ← [[IncrementalGraphUpdate]]
+- [[LSIF]] ← exports ← [[nav.index.jsonl]]
diff --git a/wiki/concepts/LSPOrchestrator.md b/wiki/concepts/LSPOrchestrator.md
new file mode 100644
index 00000000..2bb20f6b
--- /dev/null
+++ b/wiki/concepts/LSPOrchestrator.md
@@ -0,0 +1,68 @@
+---
+title: "LSPOrchestrator"
+type: concept
+tags: ["LSP", "code-intelligence", "orchestration", "multi-language"]
+sources: ["lsp-index-engineer.md"]
+last_updated: 2026-04-29
+---
+
+## Definition
+LSP 编排器（LSP Orchestrator）是在 graphd 架构中协调多个语言服务器并发运行的中间层，负责统一管理不同语言的 LSP 客户端、正确处理各服务器的能力协商、并将对异构 LSP 响应格式标准化为统一格式。
+
+## Core Mechanism
+
+### Client Initialization
+```typescript
+class LSPOrchestrator {
+  async initialize(projectRoot: string) {
+    const tsClient = new LanguageClient('typescript', {
+      command: 'typescript-language-server',
+      args: ['--stdio'],
+      rootPath: projectRoot
+    });
+    const phpClient = new LanguageClient('php', {
+      command: 'intelephense',
+      args: ['--stdio'],
+      rootPath: projectRoot
+    });
+    await Promise.all([
+      this.initializeClient('typescript', tsClient),
+      this.initializeClient('php', phpClient)
+    ]);
+  }
+}
+```
+
+### Multi-Language Coordination
+- **并行初始化**：所有语言服务器并发启动
+- **能力协商**：为每个服务器独立检查 `ServerCapabilities`
+- **语言检测**：根据文件扩展名路由到对应语言服务器
+- **请求批处理**：合并相邻请求以减少往返开销
+- **缓存策略**：积极缓存但精确失效
+
+### Capability-Negotiation Pattern
+```typescript
+async getDefinition(uri: string, position: Position): Promise<Location[]> {
+  const lang = this.detectLanguage(uri);
+  const client = this.clients.get(lang);
+  if (!client || !this.capabilities.get(lang)?.definitionProvider) {
+    return [];
+  }
+  return client.sendRequest('textDocument/definition', {
+    textDocument: { uri },
+    position
+  });
+}
+```
+
+## Performance Optimization
+- **请求批处理**：合并多个相邻 LSP 请求
+- **零拷贝技术**：内存映射文件和大数据集
+- **Worker Threads**：CPU 密集型操作分流到 Worker
+- **锁无关数据结构**：并发访问无锁化
+
+## Connections
+- [[LSPOrchestrator]] ← part_of ← [[GraphDaemon]]
+- [[LSPOrchestrator]] ← coordinates ← [[LanguageServerProtocol]]
+- [[LSPOrchestrator]] ← feeds ← [[SemanticCodeGraph]]
+- [[LSPOrchestrator]] ← uses ← [[IncrementalGraphUpdate]]
diff --git a/wiki/concepts/LambdaSafetyGate.md b/wiki/concepts/LambdaSafetyGate.md
new file mode 100644
index 00000000..5d3a707a
--- /dev/null
+++ b/wiki/concepts/LambdaSafetyGate.md
@@ -0,0 +1,40 @@
+---
+title: "Lambda Safety Gate"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+
+在执行 SLM 生成的 Python lambda 转换函数前，对其进行严格安全验证的防御机制。防止恶意代码、文件系统操作或任意代码执行通过 AI 修复管道注入系统。
+
+## Validation Rules
+
+```python
+def validate_lambda(lambda_str: str) -> bool:
+    forbidden = ['import', 'exec', 'eval', 'os.', 'subprocess', '__']
+    if not lambda_str.startswith('lambda'):
+        raise ValueError("Rejected: output must be a lambda function")
+    if any(term in lambda_str for term in forbidden):
+        raise ValueError("Rejected: forbidden term in lambda")
+    return True
+```
+
+## Validation Checklist
+
+| Check | Rule | On Failure |
+|-------|------|------------|
+| Prefix | 必须以 `lambda` 开头 | 拒绝，路由至人工隔离 |
+| Keywords | 禁止 `import/exec/eval/os/subprocess/__` | 拒绝，路由至人工隔离 |
+| Confidence | 置信度必须 ≥ 0.75 | 拒绝，路由至人工隔离 |
+
+## Rationale
+
+AI 生成的文本可能包含任意代码。Lambda Safety Gate 确保即使 SLM 被注入恶意提示词，修复管道也仅执行无害的数据转换函数。
+
+## Related
+
+- [[Air-Gapped SLM Fix Generation]]
+- [[Zero Data Loss Guarantee]]
+- [[AI Generates Logic Not Data]]
diff --git a/wiki/concepts/Landscape.md b/wiki/concepts/Landscape.md
new file mode 100644
index 00000000..2546bce8
--- /dev/null
+++ b/wiki/concepts/Landscape.md
@@ -0,0 +1,54 @@
+---
+title: "Landscape"
+type: concept
+tags: ["unreal-engine", "terrain", "environment", "material"]
+sources: ["unreal-world-builder"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- UE5 Landscape
+- Terrain System
+- 地形系统
+- Landscape System
+
+## Definition
+Landscape 是 Unreal Engine 5 的地形系统，支持超大尺寸地形的编辑、渲染和运行时修改。它使用分块（Components）架构，支持多层材质混合，并通过 Runtime Virtual Texturing（RVT）优化多层混合性能。
+
+## Resolution Rule
+Landscape 分辨率必须满足公式：**分辨率 = (n × ComponentSize) + 1**，必须使用 Landscape Import Calculator 确定，禁止猜测。
+
+## Layer Constraints
+- **单区域最多 4 个活跃材质层**：超过则导致材质排列组合爆炸（Material Permutation Explosion）
+- **超过 2 层材质必须启用 RVT**：消除逐像素层混合开销
+- **景观空洞**：必须使用 Visibility Layer，禁止删除组件（删除会破坏 LOD 和水体系统集成）
+
+## Master Material Architecture
+典型 4 层 Landscape Master Material：
+- **Layer 0**：Grass（基底层，始终存在）
+- **Layer 1**：Dirt/Path（沿磨损路径替换草地）
+- **Layer 2**：Rock（坡度驱动，> 35° 自动混合）
+- **Layer 3**：Snow（高度驱动，> 800m 显现）
+
+## Blending Mechanisms
+- **Auto-Slope Rock Blend**：WorldAlignedBlend，坡度阈值 = 0.6（dot(worldUp, surfaceNormal)）
+- **Auto-Height Snow Blend**：Absolute World Position Z > SnowLine 参数时雪层淡入
+- **RVT 分辨率**：每 4096m² 格子 2048×2048，格式 YCoCg 压缩
+
+## RVT Integration
+- 启用 Runtime Virtual Texturing 的 Landscape Material
+- Virtual Texture Producer 需在 Landscape 上启用
+- RVT Output Volume 每 4096m² 格子对齐放置
+- RVT 可采样游戏标签或 Decal Actor 驱动动态地形状态（如雨后湿润度）
+
+## Landscape Splines
+用于道路和河流雕刻：样条线变形的网格自动贴合地形拓扑。
+
+## Connections
+- [[UnrealWorldBuilder]] ← 地形基础 ← Landscape
+- [[UnrealEngine5]] ← 核心引擎 ← Landscape
+- [[RuntimeVirtualTexturing]] ← 层混合优化 ← Landscape
+- [[WorldPartition]] ← 空间管理 ← Landscape
+
+## Sources
+- [[unreal-world-builder]]
diff --git a/wiki/concepts/LanguageServerProtocol.md b/wiki/concepts/LanguageServerProtocol.md
new file mode 100644
index 00000000..52f06c3b
--- /dev/null
+++ b/wiki/concepts/LanguageServerProtocol.md
@@ -0,0 +1,53 @@
+---
+title: "LanguageServerProtocol"
+type: concept
+tags: ["LSP", "code-intelligence", "language-server", "IDE", "editor"]
+sources: ["lsp-index-engineer.md"]
+last_updated: 2026-04-29
+---
+
+## Definition
+Language Server Protocol（LSP）是 Microsoft 在 2016 年首创的标准化协议，定义了**语言服务器**（Language Server）与**语言客户端**（Editor/IDE）之间的通信规范，使编程语言工具能够在任何编辑器中提供一致的代码智能功能（跳转定义、查找引用、悬停文档、自动完成等），无需为每个编辑器-语言组合单独实现。
+
+## Core Mechanism
+
+### Protocol Architecture
+- **Language Server**：独立进程，负责语言特定的代码分析（解析、类型检查、语义分析）
+- **Language Client**：编辑器/IDE 端，负责用户交互和结果展示
+- **Communication**：通过 JSON-RPC（2.0）在 stdin/stdout 之间传输消息
+
+### LSP 3.17 关键能力
+- **textDocument/didOpen** — 文档打开通知
+- **textDocument/definition** — 跳转到定义
+- **textDocument/references** — 查找引用
+- **textDocument/hover** — 悬停文档
+- **textDocument/completion** — 自动完成
+- **textDocument/publishDiagnostics** — 诊断信息发布
+- **workspace/symbol** — 工作区符号搜索
+
+### Capability Negotiation
+客户端在 `initialize` 请求中声明自身能力：
+```json
+{
+  "capabilities": {
+    "textDocumentSync": 1,
+    "definitionProvider": true,
+    "referencesProvider": true,
+    "hoverProvider": true
+  }
+}
+```
+服务器在响应中声明支持的能力。**LSP/Index Engineer 强制要求永远检查服务器能力响应，而非假设支持某功能。**
+
+### Lifecycle
+`initialize` → `initialized` → （正常运行）→ `shutdown` → `exit`
+
+## Multi-Language Orchestration
+LSP 的核心价值在于使多语言支持标准化。LSP/Index Engineer 的 graphd 通过协调多个语言服务器（TypeScript、PHP、Go、Rust、Python），将各自 LSP 响应统一转换为语义图谱，实现跨语言的代码导航。
+
+## Connections
+- [[LanguageServerProtocol]] ← enables ← [[LSPOrchestrator]]
+- [[LanguageServerProtocol]] ← powers ← [[SemanticCodeGraph]]
+- [[LSPOrchestrator]] ← coordinates ← [[TypeScriptLanguageServer]]
+- [[LSPOrchestrator]] ← coordinates ← [[Intelephense]]
+- [[LanguageServerProtocol]] ← uses ← [[LSIF]]
diff --git a/wiki/concepts/LargeWorldCoordinates.md b/wiki/concepts/LargeWorldCoordinates.md
index da33dbd3..6d0c1cc6 100644
--- a/wiki/concepts/LargeWorldCoordinates.md
+++ b/wiki/concepts/LargeWorldCoordinates.md
@@ -1,40 +1,48 @@
 ---
-title: "Large World Coordinates"
+title: "LargeWorldCoordinates"
 type: concept
-tags: ["unreal-engine", "coordinate-system", "precision", "ue5", "open-world"]
+tags: ["unreal-engine", "coordinates", "precision", "open-world"]
 sources: ["unreal-world-builder"]
-last_updated: 2026-04-26
+last_updated: 2026-04-30
 ---
 
+## Aliases
+- LWC
+- Large World Coordinates
+- 大世界坐标
+- 双精度坐标
+
 ## Definition
-Large World Coordinates（LWC），UE5 双精度坐标系统，通过在引擎层面使用 double（64 位浮点）替代 float（32 位浮点）存储世界位置坐标，解决超大世界（>2km）远距离处的浮点精度误差问题。
+Large World Coordinates（LWC）是 Unreal Engine 5 引入的双精度（double）坐标系统，用于解决超大世界（任何轴超过 2km）中的浮点精度问题。无 LWC 时，约 20km 处开始出现可见的浮点精度错误。
 
-## The Precision Problem
-- 单精度浮点（float）在距离原点约 20km 处开始出现可见精度误差
-- 误差表现：抖动（Jitter）、接缝（Seam）、几何体重影（Ghosting）
-- 开放世界项目（4km² ~ 64km²）极易触碰到此阈值
+## Precision Problem
+IEEE 754 单精度浮点数（float）在以下场景产生精度损失：
+- **大数值**：坐标值越大，相邻值之间的 gap 越大
+- **远距离相加**：大坐标值与小数值的加法丢失精度
+- **累积误差**：多次变换后误差累积
 
-## When LWC is Required
-- **任何轴超过 2km 的世界必须启用 LWC**
-- 测试方法：在距离原点 100km 处生成玩家，验证无视觉或物理瑕疵
+## LWC Enabling Threshold
+- **强制启用**：世界任何轴超过 2km
+- **精度损失临界点**：~20km（无 LWC 时可见）
+- **最大安全范围**：建议 100km 以内（即使启用 LWC）
 
-## LWC Compatibility Requirements
-### Shader/Material
-- 替换所有直接 world position 采样为 `LWCToFloat()` 函数
-- 否则可能导致远处的材质出现视觉错误
+## Code Changes Required
+| 位置 | float → double 替代 |
+|------|-------------------|
+| 游戏性代码（位置计算） | `FVector` → `FVector3d` |
+| 着色器/材质 | 直接世界位置采样 → `LWCToFloat()` 转换 |
+| 网络复制 | 仍用单精度（本地双精度，复制时转换） |
 
-### Gameplay Code
-- 世界位置使用 `FVector3d`（双精度）而非 `FVector`（单精度）
-- 特别是在处理坐标计算、Actor 放置、寻路等逻辑时
+## LWC Compliance Audit
+迁移到 LWC 时必须审查：
+- [ ] 所有着色器和材质使用 `LWCToFloat()` 而非直接世界位置采样
+- [ ] 游戏中所有位置计算使用 `FVector3d`
+- [ ] 在 100km 以外spawn玩家并验证无视觉/物理瑕疵
 
-### Asset Pipeline
-- 检查第三方 DDC（Derived Data Cache）资产是否正确配置 LWC
-- 某些旧资产导入流程可能未处理双精度坐标
+## Connections
+- [[UnrealWorldBuilder]] ← 坐标系统 ← LargeWorldCoordinates
+- [[UnrealEngine5]] ← 核心引擎 ← LargeWorldCoordinates
+- [[WorldPartition]] ← 空间管理 ← LargeWorldCoordinates
 
-## Relationship to World Partition
-LWC 与 World Partition 协同：World Partition 管理大世界的分区流送，LWC 解决大世界的坐标精度问题，两者共同支撑 UE5 开放世界技术栈。
-
-## Related
-- [[UnrealWorldBuilder]] — LWC 配置与审计专家
-- [[WorldPartition]] — LWC 的配套分区管理框架
-- [[Nanite]] — Nanite 虚拟几何体在大世界中的使用不受 LWC 影响（Nanite 内部使用相对坐标）
+## Sources
+- [[unreal-world-builder]]
diff --git a/wiki/concepts/Layout-Framework.md b/wiki/concepts/Layout-Framework.md
new file mode 100644
index 00000000..fce82a7f
--- /dev/null
+++ b/wiki/concepts/Layout-Framework.md
@@ -0,0 +1,61 @@
+---
+title: "Layout Framework"
+type: concept
+tags: [css, layout, responsive, grid, flexbox]
+sources: [design-ux-architect.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+Layout Framework 是基于 CSS Grid 和 Flexbox 的响应式布局系统，定义容器、网格、间距和断点规范，为开发者提供可信赖的实现基础。
+
+## Container System
+
+- **Mobile**：全宽，16px padding
+- **Tablet**：768px max-width，居中
+- **Desktop**：1024px max-width，居中
+- **Large**：1280px max-width，居中
+
+```css
+.container {
+  width: 100%;
+  max-width: var(--container-lg);
+  margin: 0 auto;
+  padding: 0 var(--space-4);
+}
+```
+
+## Grid Patterns
+
+```css
+.grid-2-col {
+  display: grid;
+  grid-template-columns: 1fr 1fr;
+  gap: var(--space-8);
+}
+
+@media (max-width: 768px) {
+  .grid-2-col {
+    grid-template-columns: 1fr;
+    gap: var(--space-6);
+  }
+}
+```
+
+## Component Hierarchy
+
+1. **Layout Components**：containers, grids, sections
+2. **Content Components**：cards, articles, media
+3. **Interactive Components**：buttons, forms, navigation
+4. **Utility Components**：spacing, typography, colors
+
+## Related Concepts
+
+- [[CSS-Design-System]]：提供设计 Token 支撑布局系统
+- [[Responsive-Breakpoints]]：移动优先断点策略
+- [[Component-Architecture]]：组件命名和层级结构
+
+## Sources
+
+- [[design-ux-architect]] — Layout Framework 的完整定义和示例代码
diff --git a/wiki/concepts/Liminality.md b/wiki/concepts/Liminality.md
new file mode 100644
index 00000000..46fa3853
--- /dev/null
+++ b/wiki/concepts/Liminality.md
@@ -0,0 +1,24 @@
+---
+title: "Liminality"
+type: concept
+tags: ["anthropology", "ritual", "threshold", "communitas", "turner"]
+last_updated: 2026-04-25
+---
+
+## Definition
+阈限（Liminality）——仪式过程中参与者处于"之间"状态的阶段，从旧社会结构中分离但尚未整合进新状态，具有特殊的社会地位和无限可能性。
+
+## Core Framework
+- **van Gennep 三阶段**：分离（separation）→ 阈限（liminality）→ 整合（incorporation）
+- **Communitas**：阈限状态中产生的强烈平等主义和直接人际连接，超越正常社会等级和身份
+- **社会转化**：阈限是社会结构暂时"溶解"的时刻，是文化创新和集体情感强化的关键时刻
+- **阈限悖论**：参与者既被看做"无名"又具有神圣性，既无地位又被赋予特殊权力
+
+## Key Thinkers
+- Arnold van Gennep（仪式三阶段提出者）
+- [[Victor-Turner]]（阈限和 communitas 概念发展者）
+
+## Connections
+- [[Anthropologist-Agent]] ← uses_framework ← [[Liminality]]
+- [[Symbolic-Anthropology]] ← provides_interpretive_tools ← [[Liminality]]
+- [[Rites-of-Passage]] ← operates_in ← [[Liminality]]
diff --git a/wiki/concepts/LintWorkflow.md b/wiki/concepts/LintWorkflow.md
new file mode 100644
index 00000000..980f15b0
--- /dev/null
+++ b/wiki/concepts/LintWorkflow.md
@@ -0,0 +1,41 @@
+---
+title: "LintWorkflow"
+type: concept
+tags: [workflow, knowledge-management, llm, quality]
+sources: [llm-wiki]
+last_updated: 2026-05-02
+---
+
+## Overview
+检查工作流（Lint Workflow）是 [[PersistentWiki]] 的定期健康检查机制——让 LLM 定期检查 Wiki 的质量，发现问题并提出改进建议。
+
+## Standard Checks
+
+### 1. 孤立页面（Orphan Pages）
+没有任何其他页面通过 `[[wikilinks]]` 指向它的 Wiki 页面。
+
+### 2. 断链（Broken Links）
+`[[WikiLinks]]` 指向不存在的页面。
+
+### 3. 内容冲突（Contradictions）
+跨页面存在相互矛盾的论点。
+
+### 4. 过时摘要（Stale Summaries）
+有更新来源后未同步更新的页面。
+
+### 5. 缺失 Entity 页面
+在 3 个以上页面中被提及但没有独立页面的实体。
+
+### 6. 数据缺口（Data Gaps）
+Wiki 无法回答的问题，建议补充新来源。
+
+## Trigger
+触发方式：用户说 "lint"
+
+## Output
+输出检查报告，询问用户是否保存为 `wiki/lint-report.md`。
+
+## Design Principles
+- **定期执行**：保持 Wiki 健康，防止问题积累
+- **LLM 擅长发现**：LLM 擅长提出新的研究问题和新的来源建议
+- **自动化维护**：配合 [[IngestWorkflow]] 和 [[QueryWorkflow]]，构成完整的 Wiki 生命周期管理
diff --git a/wiki/concepts/Localization.md b/wiki/concepts/Localization.md
new file mode 100644
index 00000000..518532fb
--- /dev/null
+++ b/wiki/concepts/Localization.md
@@ -0,0 +1,62 @@
+---
+title: "Localization"
+type: concept
+tags:
+  - marketing
+  - cross-border
+  - globalization
+  - multilingual
+  - ecommerce
+sources:
+  - marketing-cross-border-ecommerce
+last_updated: 2026-04-26
+---
+
+## Aliases
+- Localization
+- 本地化
+- 市场本地化
+- 跨文化本地化
+
+## Definition
+
+Localization（本地化）是指将产品、Listing、内容和服务根据目标市场的语言、文化审美、消费习惯、定价能力和监管要求进行适应性调整的过程。在跨境电商中，本地化决定产品能否在目标市场获客，是与"翻译"（translation）相对的概念——不仅转换语言，更转换用户体验。
+
+## Core Dimensions
+
+### 语言本地化
+- 母语级 Listing 撰写（机器翻译是转化率最大杀手）
+- 文化禁忌和敏感词规避
+- 多语言 SEO（标题、描述、Backend Search Terms）
+- 客服脚本的本地语言版本
+
+### 视觉本地化
+- 主图风格适配目标市场审美（美国简洁白底 vs 日本生活场景）
+- Lifestyle 图片融入本地生活情境
+- 信息图设计符合本地信息获取习惯
+- 包装设计符合当地文化偏好
+
+### 定价本地化
+- 基于本地消费能力和竞争格局定价，而非简单汇率换算
+- 促销活动节奏与当地消费日历对齐
+- 多货币动态定价策略
+
+### 服务本地化
+- 目标市场时区的客服响应
+- 符合当地沟通习惯的服务流程
+- 退货政策适配各地消费者期望
+
+## Key Principle
+
+> 本地化决定能否获客，合规决定能否存活，供应链决定能否盈利。
+
+## When to Use
+
+- 进入任何新市场（新平台、新国家）前必须完成本地化评估
+- 识别本地化差距：列出所有未做本地化调整的元素
+- 优先级排序：先核心 Listing，再视觉，再客服脚本
+
+## Connections
+- [[Marketing Cross-Border E-Commerce Specialist]] ← requires ← [[Localization]]
+- [[TikTok Shop]] ← depends_on ← [[Localization]] (content localization is core)
+- [[Listing Optimization]] ← incorporates ← [[Localization]]
diff --git a/wiki/concepts/Loyalty-Program-Management.md b/wiki/concepts/Loyalty-Program-Management.md
new file mode 100644
index 00000000..135023d4
--- /dev/null
+++ b/wiki/concepts/Loyalty-Program-Management.md
@@ -0,0 +1,54 @@
+---
+title: "Loyalty Program Management"
+type: concept
+tags: []
+sources:
+  - hospitality-guest-services
+last_updated: 2026-05-02
+---
+
+## Definition
+Loyalty Program Management（忠诚计划管理）是对酒店或品牌忠诚会员全生命周期（注册→入住→退房→再入住）的系统性管理，确保每位会员在其会员等级所对应的每一触点都被识别、认可和奖励。
+
+## Lifecycle Stages
+
+### 1. Enrollment（注册）
+- 每次入住时主动向非会员推荐："您是否加入了我们的[忠诚计划]？免费注册，本次入住即可赚取积分"
+- 沟通核心价值：积分赚取比例、欢迎奖励、等级权益
+- 兑换选项：未来房晚、餐饮、水疗服务
+
+### 2. Tier Recognition（等级认可）
+入住时每次必须执行的识别流程：
+- **银卡**：欢迎+姓名+积分余额
+- **金卡**：欢迎+姓名+积分余额+具体权益
+- **白金/顶级**：最高级别认可 + 专属安排（升级/amenity/特殊礼遇）
+
+> "Never let a loyalty member feel invisible" — 忠诚会员未被认可其身份等同于服务失误
+
+### 3. Points Management（积分管理）
+- 积分在退房后72小时内到账
+- 餐饮、水疗、活动等额外消费同步积分
+- 缺失积分：48小时内提交忠诚团队+宾客确认
+
+### 4. Complaint Escalation（投诉升级）
+会员积分未到账、等级状态问题、兑换障碍：
+1. 详细记录问题
+2. 48小时内提交忠诚团队
+3. 跟进宾客确认解决
+
+## Key Metrics
+- 会员入住率（Membership Occupancy Rate）
+- 会员生命周期价值（Member Lifetime Value）
+- 积分兑换率（Redemption Rate）
+- 会员获取成本 vs. 获取收益
+
+## Connections
+- [[Hospitality Guest Services]] ← 忠诚计划管理是宾客服务 Agent 入住→退房全流程的核心技能
+- [[Guest Journey]] ← 忠诚计划贯穿宾客旅程的每一触点
+- [[Review Management]] ← 忠诚会员的好评权重更高，流失影响更大
+
+## Aliases
+- 忠诚计划管理
+- 会员管理
+- Guest Loyalty Program
+- Rewards Program
diff --git a/wiki/concepts/Marp.md b/wiki/concepts/Marp.md
new file mode 100644
index 00000000..3cb95d7e
--- /dev/null
+++ b/wiki/concepts/Marp.md
@@ -0,0 +1,29 @@
+---
+title: "Marp"
+type: concept
+tags: [tool, obsidian, plugin, slides, presentation]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- Marp Slides
+- Marp 幻灯片
+- Marp for VS Code / Obsidian
+
+## Definition
+基于 Markdown 的幻灯片格式，在 Obsidian 里安装 Marp Slides 插件即可直接预览和导出 PDF/HTML/PPTX。LLM Wiki 的可选增强工具。
+
+## Usage
+在 Markdown 文件开头加上 `marp: true`，用 `---` 分隔每页幻灯片，写完直接在 Obsidian 里预览。
+
+## LLM Wiki Use Case
+让 AI 从 Wiki 的某个主题页面直接生成 Marp 格式的幻灯片草稿，微调后即可使用。
+
+## Practical Value
+- 老张（[[laozhang2579]]）观点："实用价值老张保留意见"
+- 适合需要定期做演示的用户，非 LLM Wiki 的核心组件
+
+## Connections
+- [[Marp]] ← 可选增强 → [[LLM Wiki]]
+- [[Marp]] ← 插件 → [[Obsidian]]
diff --git a/wiki/concepts/Mass-Entity.md b/wiki/concepts/Mass-Entity.md
new file mode 100644
index 00000000..a4ed58ad
--- /dev/null
+++ b/wiki/concepts/Mass-Entity.md
@@ -0,0 +1,41 @@
+---
+title: "Mass Entity"
+type: concept
+tags: ["unreal-engine", "ecs", "simulation", "crowd", "performance"]
+sources: ["unreal-systems-engineer"]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Unreal Entity Component System
+- Mass Framework
+- UE5 ECS
+
+## 定义
+Mass Entity 是 Unreal Engine 的 ECS（Entity Component System）实现，通过 `UMassEntitySubsystem` 处理海量 NPC、投射物或人群代理的模拟，以原生 CPU 性能运行。
+
+## 核心架构
+
+### FMassFragment（数据组件）
+每个实体的数据层——存储 per-entity 数据（如位置、速度、生命值）。
+
+### FMassTag（标记组件）
+布尔标记——用于标识实体类型或状态（如 `FMassCharacterLargeLODTag`）。
+
+### Mass Processors
+操作 fragments 的并行处理器——使用 Unreal 任务图并行执行。
+
+### UMassRepresentationSubsystem
+连接 Mass 模拟和 Actor 可视化的桥梁：
+- 将 Mass 实体显示为 LOD 切换的 Actor（Hierarchical LOD）
+- 或显示为 Instance Static Mesh（ISM）以优化渲染
+
+## 使用场景
+- 海量 NPC 群体模拟
+- 密集投射物系统
+- 人群代理
+- 任何需要处理成千上万实体的性能敏感场景
+
+## 相关概念
+- [[Actor Replication]] — Mass 实体与网络复制的关系
+- [[UnrealEngine5]] — Mass Entity 是 UE5 内置框架
diff --git a/wiki/concepts/Material-Culture.md b/wiki/concepts/Material-Culture.md
new file mode 100644
index 00000000..57897344
--- /dev/null
+++ b/wiki/concepts/Material-Culture.md
@@ -0,0 +1,34 @@
+---
+title: "Material Culture"
+type: concept
+tags: [historiography, methodology, anthropology]
+sources: [academic-historian, academic-anthropologist]
+last_updated: 2026-04-30
+---
+
+## Definition
+物质文化（Material Culture）指人类社会所创造和使用的一切物质产品及其承载的社会意义——包括但不限于工具、服饰、建筑、器物、武器、货币、书写材料等。物质文化研究通过分析物质遗存（器物、图像、遗址）和文献记载，重建过去人们的生活方式、思想观念和社会结构。
+
+## Key Features
+- **核心方法**：考古学与历史文献的交叉分析——物质遗存 + 文字记载
+- **研究维度**：
+  - 器物形制与制作工艺（技术史）
+  - 物质流通与消费模式（经济史）
+  - 物质文化的象征意义（符号分析）
+  - 物质与身份认同（谁使用什么、谁被排斥在外）
+- **代表学者**：朱尔斯·亨利（Julius Schlosser）、皮埃尔·布尔迪厄（Pierre Bourdieu，实践理论）
+- **Annales 学派视角**：布罗代尔强调"物质生活"（la vie matérielle）是历史的第一层——地理环境、物质条件、经济发展构成历史的基础层
+
+## Relationship to Other Concepts
+- [[Annales-School]] ← 理论基础 ← [[Material-Culture]]：年鉴学派将物质文化作为历史分析的第一层（日常生活史）
+- [[academic-anthropologist]] ← 使用 ← [[Material-Culture]]：文化人类学家同样关注物质文化的象征意义和社会功能
+- [[academic-historian]] ← 核心方法 ← [[Material-Culture]]：Historian Agent 五步工作流中"检查物质基础"的直接方法论来源
+- [[Geographic-Coherence]] ← 关联 ← [[Material-Culture]]：物质文化受地理环境制约（原材料、可及性、贸易路线）
+
+## Relationship to Source Pages
+- [[academic-historian]]：文档"🎯 Core Mission - Enrich with Material Culture"节专门论述，明确要求关注"饮食、服饰、建筑、贸易、信仰、恐惧"
+- [[academic-anthropologist]]：文档同样将物质文化作为文化自洽设计的核心维度
+
+## Aliases
+- 物质文化
+- Material Culture Studies
diff --git a/wiki/concepts/Meaning-Transfer-Translation.md b/wiki/concepts/Meaning-Transfer-Translation.md
new file mode 100644
index 00000000..ff71f3c7
--- /dev/null
+++ b/wiki/concepts/Meaning-Transfer-Translation.md
@@ -0,0 +1,38 @@
+---
+title: "Meaning Transfer Translation"
+type: concept
+tags: ["translation", "linguistics", "language", "ai-agent", "nlp"]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+**Meaning Transfer Translation**（意义转移翻译）是一种超越逐字替换的翻译方法论，核心理念：**翻译 = 传递意义，而非替换词汇**。目标不是字典输出，而是让目标语言接收者能实际理解和响应。
+
+## Core Principle
+
+> "Translation isn't word-for-word substitution — it's meaning transfer." — Language Translator Agent
+
+## Examples
+
+| 英文（源） | 字面翻译（错误） | 意义转移（正确） | 说明 |
+|---|---|---|---|
+| It's raining cats and dogs. | Está lloviendo gatos y perros | Está lloviendo a cántaros | 西班牙语中"倾盆大雨"的自然表达 |
+| Break a leg! | Rompe una pierna | ¡Buena suerte! | 祝好运的习语，字面翻译令人困惑 |
+| ¿Mande? (墨西哥) | "Mande?" | "Pardon?" | 墨西哥西班牙语中"请问有什么事？"的礼貌表达 |
+
+## In AI Agent Context
+
+在 [[Language Translator]] Agent 中的实现：
+1. 识别源语言中的惯用语、成语、俚语
+2. 在目标语言中寻找自然等效表达（不等同于字面对应）
+3. 匹配语气：讽刺、热情、紧急、礼貌必须完整传递
+4. 验证输出对母语者是否自然流畅
+
+## Related Concepts
+- [[Register Switching]]：意义转移需匹配正确语域
+- [[Subjunctive Mood]]：西班牙语虚拟式是意义传递的关键语法手段
+- [[False Cognates]]：意义转移需警惕假同源词陷阱
+
+## Sources
+- [[language-translator]]
diff --git a/wiki/concepts/Medallion-Architecture.md b/wiki/concepts/Medallion-Architecture.md
new file mode 100644
index 00000000..f68a1b83
--- /dev/null
+++ b/wiki/concepts/Medallion-Architecture.md
@@ -0,0 +1,50 @@
+---
+title: "Medallion Architecture"
+type: concept
+tags: [data-engineering, lakehouse, architecture]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+Medallion Architecture 是一种数据湖仓（Lakehouse）分层架构，通过 Bronze（青铜）→ Silver（白银）→ Gold（黄金）三层设计，实现数据从原始到业务就绪的渐进式提升。
+
+## Three Layers
+
+### Bronze Layer（原始层）
+- **特性**：原始、不可变、追加写入（append-only）
+- **规则**：永远不在原地转换数据；保留完整的 source file、ingestion timestamp、source system 元数据
+- **Schema**：Schema-on-Read（读取时推断）
+- **分区策略**：按 ingestion date 分区，支持低成本历史重放
+
+### Silver Layer（清洗层）
+- **特性**：已清洗、去重、统一格式（conformed）
+- **规则**：必须可跨域 join；显式处理 null（impute/flag/reject）；标准化数据类型、日期格式、货币码、国家码
+- **实现**：SCD Type 2 追踪历史变更；主键 + 事件时间戳去重
+- **质量**：每字段 null 处理规则必须明确记录
+
+### Gold Layer（业务层）
+- **特性**：业务就绪、SLA 保证、为查询模式优化
+- **规则**：Gold 层消费者禁止直接读取 Bronze 或 Silver；必须附带行级数据质量评分；使用 replaceWhere 原子覆盖
+- **优化**：Z-Ordering 多维聚类、分区裁剪、预聚合
+- **SLA**：明确刷新频率（如"每 15 分钟刷新一次"）
+
+## Core Principles
+
+- **不可变性**：Bronze 层不可覆盖，每条记录携带 `_ingested_at` 和 `_source_system`
+- **渐进式质量**：数据质量在 Bronze→Silver→Gold 每层逐步提升
+- **消费者保护**：上游 schema 变化通过 `mergeSchema=true` 捕获，但不自动污染下游
+- **幂等性**：Silver→Gold 每步管道必须幂等——重新运行不产生重复
+
+## Related Concepts
+- [[CDC (Change Data Capture)]]
+- [[Data Contract]]
+- [[Data Lineage]]
+- [[SCD Type 2]]
+
+## Related Entities
+- [[Delta Lake]]（Bronze/Silver/Gold 存储格式）
+- [[Apache Spark]]（计算引擎）
+- [[Databricks]]（托管平台）
+- [[Apache Iceberg]]（开放表格格式替代方案）
diff --git a/wiki/concepts/Memory-Consolidation.md b/wiki/concepts/Memory-Consolidation.md
new file mode 100644
index 00000000..d139a7bc
--- /dev/null
+++ b/wiki/concepts/Memory-Consolidation.md
@@ -0,0 +1,45 @@
+---
+title: "Memory Consolidation"
+type: concept
+tags:
+  - "agentic-ai"
+  - "memory-management"
+  - "long-horizon"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+Memory Consolidation——Agent 空闲时周期性压缩累积工作日志（去重 + 解决矛盾 + 写入精简状态文件）的机制，防止长期运行 Agent 的记忆膨胀和决策冲突。
+
+## Problem
+随着 Agent 长时间运行，记忆日志变得臃肿且矛盾——旧决策与新决策冲突，冗余条目在每次读取时浪费 token。
+
+## Solution
+自动化压缩周期：Agent 空闲时（任务之间或低优先级窗口），触发后台作业：
+1. 读取原始日志
+2. 去重条目
+3. 以最新数据为准解决矛盾
+4. 写入干净、压缩的状态文件
+
+## Empirical Result
+实测案例：32K token 嘈杂、重复历史 → 压缩为 7K token 干净状态文件，无有意义信息丢失。
+
+## Implementation
+```python
+# When agent is idle (between tasks or during low-priority windows)
+def consolidate_memory(raw_logs):
+    deduped = deduplicate(raw_logs)
+    resolved = resolve_conflicts(deduped, prefer='latest')
+    compressed = compress(resolved)
+    write_state_file(compressed)
+```
+
+## Relationship to Other Concepts
+- [[Agent-Collapse]]：Memory Consolidation 防止状态臃肿导致的决策质量下降
+- [[State-Externalization]]：压缩后的状态以结构化文件形式持久化
+- [[Context-Reset]]：Context Reset 解决当前上下文容量问题，Memory Consolidation 解决长期记忆质量问题——两者互补
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
diff --git a/wiki/concepts/MentalModel.md b/wiki/concepts/MentalModel.md
new file mode 100644
index 00000000..b8fc6d1b
--- /dev/null
+++ b/wiki/concepts/MentalModel.md
@@ -0,0 +1,38 @@
+---
+title: "MentalModel"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+
+Mental Model（心智模型）是开发者对代码库结构、工作原理和边界的内在理解。准确的代码库心智模型能够支持开发者快速定位问题、预测变更影响、进行有效的代码审查。
+
+## Building a Codebase Mental Model
+
+### Three-Tier Explanation Structure
+
+1. **One-line statement** — 一句话描述代码库是什么
+2. **Five-minute overview** — 五分钟高层解释：任务、输入、输出、关键文件、主代码路径
+3. **Deep dive** — 深度分析：类型、运行时、入口点、结构表、关键边界、详细代码流
+
+### Key Components
+
+- **Top-level structure**: 目录结构和职责划分
+- **Entry points**: 启动文件、路由、配置
+- **Data flow**: 输入如何流转、处理、输出
+- **Key boundaries**: 展示层 / 应用层 / 持久层的边界
+- **Ownership map**: 每个文件/模块负责什么
+
+## Metrics for Good Mental Model
+
+- 新开发者 5 分钟内能识别主入口点
+- 能正确预测代码变更的影响范围
+- 能准确描述跨模块的数据流
+
+## Related Concepts
+
+- [[CodebaseOnboarding]] — 代码库 onboarding 方法论
+- [[ExecutionTracing]] — 执行路径追踪
+- [[EvidenceFirstReasoning]] — 证据优先推理
diff --git a/wiki/concepts/Micro-Entreprise.md b/wiki/concepts/Micro-Entreprise.md
new file mode 100644
index 00000000..f64355d0
--- /dev/null
+++ b/wiki/concepts/Micro-Entreprise.md
@@ -0,0 +1,95 @@
+---
+title: "Micro-Entreprise"
+type: concept
+tags: []
+sources: [specialized-french-consulting-market]
+last_updated: 2026-04-25
+---
+
+# Micro-Entreprise
+
+## Aliases
+- Micro-Entreprise
+- Auto-Entrepreneur
+- Micro-Entrepreneur
+- Auto-Entrepreneuriat
+
+## Definition
+
+Micro-Entreprise（微型企业家，又称 Auto-Entrepreneur）是法国于 2009 年推出的简化企业注册制度，是全球最具吸引力的自由职业者入门结构之一。它提供极简的税务和社保缴纳机制，特别适合年收入较低的自由职业者、兼职项目和初期创业阶段。
+
+## Key Features
+
+| 维度 | 说明 |
+|------|------|
+| **注册** | 网上注册，当天完成，行政成本极低 |
+| **税务** | 固定比例税率（无需做账），按实际收入缴纳 |
+| **社保缴纳** | 按营业额的比例缴纳（而非利润），无营业额则零缴纳 |
+| **报税** | 季度申报，极简报表 |
+| **适用行业** | 服务业（22% URSSAF）、商业（13.3%）、餐饮（5.5-10.7%） |
+
+## Cost Breakdown (Services Sector)
+
+以 **700 EUR/天 TJM** 为例（每月 18 个工作日 = 12,600 EUR/月）：
+
+| 费用项 | 比例 | 金额 |
+|-------|------|------|
+| URSSAF（社保） | ~22% | -2,772 EUR |
+| **净收入（月）** | | **~9,828 EUR** |
+| **有效日均净收入** | | **~546 EUR/天** |
+
+对比 Portage Salarial 同等 TJM（~208 EUR/天）：
+- **差距：338 EUR/天** = Micro-Entreprise 的成本优势
+
+## Exemption Thresholds
+
+Micro-Entreprise 享有法定的营业额免税门槛：
+
+| 行业类型 | 2024 年门槛 |
+|---------|-----------|
+| 服务业（含咨询） | 77,700 EUR/年 |
+| 商业 | 77,700 EUR/年 |
+| 餐饮（住宿） | 77,700 EUR/年 |
+| 餐饮（堂食） | 60,500 EUR/年 |
+
+**重要**：
+- 超出门槛后，将失去 Micro-Entreprise 身份并转为标准公司税制
+- 超门槛后实际税率显著上升，需提前规划
+
+## Key Benefits
+
+| 权益 | 说明 |
+|------|------|
+| **超高净收入比例** | 约 70% TJM，显著高于 Portage（50%） |
+| **零启动成本** | 注册简单，无初始资本要求 |
+| **灵活税务** | 按实际收入纳税，无收入零纳税 |
+| **快速退出** | 可随时停业，无复杂清算程序 |
+| **简单合规** | 无需专业会计，季度申报即可 |
+
+## Key Risks & Limitations
+
+| 风险 | 说明 |
+|------|------|
+| **无失业保险** | 失业后无法申请法国失业金（ARE） |
+| **有限退休金** | 缴纳金额较低，退休金积累显著低于 Portage |
+| **收入天花板** | 超过门槛后税制不利 |
+| **个人承担全险** | 商业风险完全自担，无 employer-style 保障 |
+| **可信度** | 某些大客户（Tier 1 ESN）更倾向于与正式公司签约 |
+
+> "Always distinguish TJM brut from net. A 600 EUR/day TJM through micro-entreprise yields approximately 420-450 EUR net." — French Consulting Market Navigator
+
+## Relationship to Portage Salarial
+
+Micro-Entreprise 和 Portage Salarial 是法国自由职业者最主要的两种计费结构选择：
+
+| 维度 | Portage Salarial | Micro-Entreprise |
+|------|----------------|-----------------|
+| 净收入比例 | ~50% TJM | ~70% TJM |
+| 失业保险 | ✅ | ❌ |
+| 退休金缴纳 | 完整 | 有限 |
+| 行政复杂度 | 低 | 极低 |
+| 适合场景 | 转型期/需要保障 | 高净收入/低成本 |
+
+## Related Sources
+- [[specialized-french-consulting-market]]
+- [[Portage-Salarial]]
diff --git a/wiki/concepts/Micro-Interaction-Design.md b/wiki/concepts/Micro-Interaction-Design.md
new file mode 100644
index 00000000..e9339578
--- /dev/null
+++ b/wiki/concepts/Micro-Interaction-Design.md
@@ -0,0 +1,43 @@
+---
+title: "Micro-Interaction Design"
+type: concept
+tags: [ui-design, animation, user-experience, interaction-design]
+sources: [design-whimsy-injector]
+last_updated: 2026-05-15
+---
+
+# Micro-Interaction Design
+
+## Definition
+
+微交互设计（Micro-Interaction Design）通过小规模、有针对性的动画和状态反馈，提升用户参与度，同时不影响性能。核心要素：触发（Trigger）、规则（Rules）、反馈（Feedback）、循环（Loops）。
+
+## Key Elements
+
+- **按钮悬停效果**：光扫动画 + 微妙缩放
+- **表单验证反馈**：即时状态变化 + 成功动画（如 ✨ 闪烁）
+- **加载动画**：弹跳点动画、进度条动画
+- **彩蛋触发区域**：交互探索奖励
+- **进度庆祝**：完成节点的表情符号动画
+
+## Design Principles
+
+- 每个微交互服务于功能或情感目的
+- 性能优化：轻量 CSS 动画，不影响页面速度
+- 包容性：无障碍支持，减少动画偏好用户选项
+
+## Implementation
+
+通过 CSS Keyframes 实现，示例技术：
+- `cubic-bezier` 缓动函数
+- `transition` 状态变化
+- `@keyframes` 自定义动画序列
+
+## Related Concepts
+
+- [[Gamification]]：微交互可作为游戏化的组成元素
+- [[Inclusive-Delight-Design]]：微交互需遵循包容性设计原则
+
+## Source
+
+- [[Whimsy-Injector]] — 微交互设计系统核心交付物
diff --git a/wiki/concepts/Micro-Interaction.md b/wiki/concepts/Micro-Interaction.md
new file mode 100644
index 00000000..23d746f1
--- /dev/null
+++ b/wiki/concepts/Micro-Interaction.md
@@ -0,0 +1,49 @@
+---
+title: "Micro-Interaction"
+type: concept
+tags: [ux, design, interaction]
+last_updated: 2026-04-30
+---
+
+# 微交互设计（Micro-Interaction）
+
+## Aliases
+- Micro-Interaction
+- 微交互
+
+## 定义
+
+微交互是指产品中那些小型的、聚焦于单一任务的交互细节——通过小型动画、声音反馈和视觉变化，增强用户体验的愉悦感和功能性。通常作用于：按钮状态变化、表单验证反馈、加载动画、设置切换等具体场景。
+
+## 核心特征
+
+1. **聚焦单一任务**：每个微交互只做一件事（如点赞动画、成功反馈）
+2. **触发-反馈循环**：用户动作 → 系统响应 → 状态变化
+3. **细节驱动体验**：大型功能由微交互串联形成流畅体验
+
+## 设计原则
+
+- **目的性**：每个微交互必须有功能性或情感性目的，不可为装饰而装饰
+- **响应性**：即时反馈，减少用户对系统状态的焦虑
+- **一致性**：同类型交互保持相同反馈模式，建立用户预期
+- **可访问性**：动画需考虑 `prefers-reduced-motion`，不影响屏幕阅读器
+
+## 分类
+
+| 类型 | 示例 | 目的 |
+|------|------|------|
+| 状态反馈 | 按钮悬停、点击效果 | 确认操作被接收 |
+| 数据验证 | 表单实时验证成功/失败 | 引导正确输入 |
+| 系统状态 | 加载动画、空状态 | 减少等待焦虑 |
+| 进度指示 | 上传进度、完成庆祝 | 维持用户动机 |
+
+## 应用场景
+
+- [[design-whimsy-injector]] 在按钮、表单、进度条等关键触点嵌入微交互，提升品牌趣味性同时保持功能性
+- [[design-ux-architect]] 提供 CSS 框架层面的微交互系统设计规范
+
+## 相关概念
+
+- [[Brand-Personality-Framework]]：微交互是品牌个性在交互层的具体表达载体
+- [[Gamification]]：成就庆祝等游戏化元素本身也是一种微交互
+- [[Inclusive-Delight]]：包容性要求微交互需支持 reduced-motion 模式
diff --git a/wiki/concepts/Micro-Sprint.md b/wiki/concepts/Micro-Sprint.md
new file mode 100644
index 00000000..283a0870
--- /dev/null
+++ b/wiki/concepts/Micro-Sprint.md
@@ -0,0 +1,45 @@
+---
+title: "Micro-Sprint"
+type: concept
+tags: []
+sources: ["product-behavioral-nudge-engine"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Micro-Sprint 是一种将大量任务分解为短时间（通常5分钟）可完成的微小冲刺的行为工程模式。通过时间盒约束和极简任务范围来对抗认知过载和任务瘫痪。
+
+## Mechanism
+
+- **触发条件**：用户队列 ≥ 5条待办，或用户状态为 "Overwhelmed" / 识别为 ADHD 倾向
+- **时间盒**：通常 5 分钟（可调整）
+- **任务粒度**：每次只呈现 **1个** 动作项
+- **执行流程**：推送「准备好了吗？」→ 用户确认 → 开始计时 → 完成 → 即时庆祝 → 询问继续或退出
+
+## Example
+
+```typescript
+// Behavioral Engine: Generating a Time-Boxed Sprint Nudge
+export function generateSprintNudge(pendingTasks: Task[], userProfile: UserPsyche) {
+  if (userProfile.tendencies.includes('ADHD') || userProfile.status === 'Overwhelmed') {
+    return {
+      channel: userProfile.preferredChannel,
+      message: "Hey! You've got a few quick follow-ups pending. Let's see how many we can knock out in the next 5 mins. I'll tee up the first draft. Ready?",
+      actionButton: "Start 5 Min Sprint"
+    };
+  }
+}
+```
+
+## Related Concepts
+
+- [[Cognitive Load Reduction]] — Micro-Sprint 的核心目标就是降低认知负荷
+- [[Time-boxing]] — 时间约束机制
+- [[Gamification]] — 配合即时庆祝机制使用
+- [[Habit Formation]] — 通过微小成功的积累建立习惯
+
+## Connections
+
+- [[Product Sprint Prioritizer Agent]] — 任务优先级排序可结合 Micro-Sprint 策略
+- [[Habit Tracker & Accountability Coach]] — 将 Micro-Sprint 融入日常习惯追踪
diff --git a/wiki/concepts/Microhistory.md b/wiki/concepts/Microhistory.md
new file mode 100644
index 00000000..5fba158d
--- /dev/null
+++ b/wiki/concepts/Microhistory.md
@@ -0,0 +1,30 @@
+---
+title: "Microhistory"
+type: concept
+tags: [historiography, methodology]
+sources: [academic-historian]
+last_updated: 2026-04-30
+---
+
+## Definition
+微观史学（Microhistory）是一种历史研究方法，聚焦于个体、家庭或小规模社区的历史，通过深入细致的案例研究揭示更宏观的历史规律与社会结构。与年鉴学派的"总体史"形成互补——Annales School 关注长时段的结构性趋势，Microhistory 则从"小切口"切入，以小见大。
+
+## Key Features
+- **研究对象**：特定个体（如磨坊主梅诺基奥）、家庭、社区——而非帝王将相
+- **核心方法**：厚描（thick description，借鉴格尔茨）、文献细读、口述史
+- **代表学者**：卡洛·金兹堡（Carlo Ginzburg）、乔万尼·列维（Giovanni Levi）、娜塔莉·泽蒙·戴维斯（Natalie Zemon Davis）
+- **代表著作**：《奶酪与虫子》（Ginzburg, 1976）、《都铎王朝的谋杀犯》（Kelley, 1981）
+- **主要贡献**：将历史学从宏观结构拉回个体经验，揭示边缘群体和日常生活的历史能动性
+
+## Relationship to Other Concepts
+- [[Annales-School]] ← 方法论互补 ← [[Microhistory]]：微观史是对年鉴学派过度结构决定论的回应之一
+- [[Longue-Duree]] ← 尺度互补 ← [[Microhistory]]：长时段聚焦结构，微观史聚焦个体；两者共同构成多尺度历史分析
+- [[Historiography]] ← 属于 ← [[Microhistory]]：是历史编纂学中的重要流派和方法论
+- [[academic-historian]] ← 使用 ← [[Microhistory]]：Historian Agent 具备微观史方法论训练
+
+## Relationship to Source Pages
+- [[academic-historian]]：Historian Agent 文档明确将其列为核心训练背景之一
+
+## Aliases
+- 微观史学
+- 小历史
diff --git a/wiki/concepts/MinimalChangePrinciple.md b/wiki/concepts/MinimalChangePrinciple.md
new file mode 100644
index 00000000..99a9cbe6
--- /dev/null
+++ b/wiki/concepts/MinimalChangePrinciple.md
@@ -0,0 +1,48 @@
+---
+title: "MinimalChangePrinciple"
+type: concept
+tags: [engineering, code-quality, best-practices]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+最小变更原则（MinimalChangePrinciple）是一种代码变更方法论：每个变更行的存在都必须有任务明确要求的理由，而非"更好""更整洁""为未来做准备"。目标是以最小可工作的差异集（minimum viable diff）完成给定任务。
+
+## Core Questions
+
+> "Does the task require this exact line?"
+
+变更每一行之前，必须通过以下测试：
+1. **必要性**：任务是否明确要求了这一行？
+2. **最小性**：能否以更少的变更行达到同样效果？
+3. **可解释性**：这一行变更对未来的代码维护者是否可理解？
+
+## Contrast with Traditional Code Quality
+
+| 维度 | 传统观点 | 最小变更原则 |
+|------|---------|-------------|
+| 新增代码 | 越多越好（健壮性） | 越少越好（降低维护成本） |
+| 文档 | 应该详细添加 | 不为未修改代码添加文档 |
+| 重构 | 遇到问题就重构 | 与任务变更分离，独立 PR |
+| 防御性代码 | 宁多勿缺 | 仅在系统边界添加 |
+| 代码风格 | 统一风格 | 不为统一风格而修改无关代码 |
+
+## Success Metrics
+
+- **Median diff size < 30 lines changed per task**
+- **80%+ bug fix PRs touch ≤ 2 files**
+- **Zero "while I'm here" changes in any PR**
+- **Review time reduced 50%+**
+- **Regression rate near zero**
+
+## Connections
+
+- [[engineering-minimal-change-engineer]]：最小变更原则的具体实践者
+- [[PrematureAbstraction]]：最小变更原则反对在第四次出现前提取抽象
+- [[ScopeCreep]]：最小变更原则是对抗范围蔓延的核心策略
+- [[engineering-code-reviewer]]：代码审查者是检验最小变更原则的最后一道防线
+
+## Sources
+
+- [[engineering-minimal-change-engineer]]
diff --git a/wiki/concepts/Minimum-Viable-Harness.md b/wiki/concepts/Minimum-Viable-Harness.md
new file mode 100644
index 00000000..4151c0e4
--- /dev/null
+++ b/wiki/concepts/Minimum-Viable-Harness.md
@@ -0,0 +1,77 @@
+---
+title: "Minimum Viable Harness"
+type: concept
+tags:
+  - "harness-engineering"
+  - "agentic-ai"
+  - "quick-start"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+Minimum Viable Harness——Day 1 即可构建的 4 个核心组件，使 Agent 能够优雅失败，为后续增加智能赢得权利。
+
+## The 4 Components
+
+### 1. `state.json`
+单一结构化文件跟踪任务状态——如果进程死亡，可以从上次停止的地方继续。
+```json
+{
+  "task_id": "report-001",
+  "steps": {
+    "fetch_competitor_a": "COMPLETED",
+    "fetch_competitor_b": "IN_PROGRESS",
+    "compare": "PENDING"
+  },
+  "last_updated": "2026-04-20T10:30:00Z"
+}
+```
+
+### 2. Retry Wrapper
+每个工具调用包装 try/catch，至少一次自动重试 + 指数退避：
+```python
+def tool_call_with_retry(func, max_attempts=3):
+    for attempt in range(max_attempts):
+        try:
+            return func()
+        except (TimeoutError, APIError) as e:
+            if attempt < max_attempts - 1:
+                sleep(exponential_backoff(attempt))
+            else:
+                raise
+```
+
+### 3. Schema Validator
+每个 LLM 输出在接收前必须通过 JSON Schema 验证。格式不符触发重试，不触发崩溃：
+```python
+def validate_and_retry(llm_output, schema):
+    try:
+        validated = jsonschema.validate(llm_output, schema)
+        return validated
+    except ValidationError:
+        return retry_with_error_feedback(llm_output, schema)
+```
+
+### 4. Tool Output Truncation
+每个工具 payload 硬性上限固定 token 预算——context window 内的静默截断是幻觉最常见原因之一：
+```python
+MAX_TOOL_TOKENS = 3000  # 保守上限
+
+def truncate_tool_output(raw_output, max_tokens=MAX_TOOL_TOKENS):
+    tokens = encode(raw_output)
+    if len(tokens) > max_tokens:
+        return decode(tokens[:max_tokens]) + "\n[TRUNCATED]"
+    return raw_output
+```
+
+## Philosophy
+> 你可以忍受不完美的提示词。你可以忍受天真的工具集成。但是你无法忍受一个失败时破坏自己状态或静默吞噬错误的 Agent。
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
+
+## See Also
+- [[Harness-Engineering]] — 完整学科框架
+- [[7-Layer-Harness-Stack]] — 完整 7 层实现
diff --git a/wiki/concepts/MoSCoW-Classification.md b/wiki/concepts/MoSCoW-Classification.md
new file mode 100644
index 00000000..825f3220
--- /dev/null
+++ b/wiki/concepts/MoSCoW-Classification.md
@@ -0,0 +1,42 @@
+---
+title: "MoSCoW Classification"
+type: concept
+tags: [prioritization, requirements, agile]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+MoSCoW 分类法是一种需求优先级分类技术，将所有需求分为四级：**Must Have**（必须有）、**Should Have**（应该有）、**Could Have**（可以有）、**Won't Have**（不会有/本期不做）。
+
+## 分类定义
+
+| 分类 | 含义 | 占比建议 | 若不做会怎样 |
+|------|------|---------|------------|
+| **M — Must Have** | 产品无法发布的最低功能集；无替代方案 | 60% | 产品不可用或违反法规 |
+| **S — Should Have** | 重要但不致命；功能体验降级但有 workaround | 20% | 用户满意度下降，但产品仍可用 |
+| **C — Could Have** | 期望但非必要；提升愉悦度 | 15% | 错过加分项，但不影响核心价值 |
+| **W — Won't Have** | 本期明确不做；列入 Backlog 未来考虑 | 5% | 主动放弃，聚焦当前 Sprint 范围 |
+
+## 关键原则
+
+- **"Won't" means won't**：明确不做的功能不得在 Sprint 期间以任何理由渗透进来
+- 每个 MoSCoW 决策必须有明确理由并记录在 Sprint 文档中
+- MoSCoW 是对**功能范围**的分类，不是对用户价值的绝对排序
+
+## 应用场景
+
+- **[[Phase 1 Strategy]]**：Sprint Prioritizer 使用 MoSCoW 分类 + RICE 评分双重排序，MoSCoW 决定范围边界，RICE 在范围内排序
+- **[[scenario-startup-mvp]]**：Startup MVP Build Runbook 中强调"Sprint Prioritizer 执行 MoSCoW 防止范围蔓延"
+
+## MoSCoW 与 RICE 的协同工作流
+
+```
+所有需求 → MoSCoW 分类（M/S/C/W）→ RICE 评分（M + S + C）→ Sprint 规划
+                                              ↓
+                                          W（直接归档）
+```
+
+## Aliases
+- MoSCoW Prioritization
+- MoSCoW Requirements Classification
diff --git a/wiki/concepts/Month-End-Close-Process.md b/wiki/concepts/Month-End-Close-Process.md
new file mode 100644
index 00000000..d4d2fecd
--- /dev/null
+++ b/wiki/concepts/Month-End-Close-Process.md
@@ -0,0 +1,70 @@
+---
+title: "Month-End Close Process"
+type: concept
+tags: [finance, accounting, process]
+sources: [finance-bookkeeper-controller]
+last_updated: 2026-05-02
+---
+
+## Definition
+月度结账流程（Month-End Close Process）是企业每月完成的标准化财务结算流程，确保所有交易被正确记录、账户被调节、财务报表准确完整。
+
+## Core Steps
+
+### 1. Pre-Close（预结账，第1-2天）
+- 确认所有银行 feeds 同步
+- 验证所有 AP 发票已录入截止日期
+- 确认所有工资期 journal entries 已过账
+- 审核员工报销报告
+- 确认所有 AR 发票已开具
+- 确认关联方交易已与对方核对
+
+### 2. Core Close（核心结账，第3-5天）
+- 过账标准 recurring journal entries（折旧、摊销、租金、保险）
+- 计算并过账 expense accruals
+- 计算并过账 revenue accruals / 递延收入调整
+- 过账工资税和福利应计
+- 记录信用卡交易并调节对账单
+- 过账外币重估（如适用）
+- 过账关联方抵消（如合并报表）
+
+### 3. Reconciliations（调节，第3-6天）
+- 所有银行账户调节
+- 所有信用卡调节
+- AR aging 与 GL 核对
+- AP aging 与 GL 核对
+- 预付账款与摊销计划核对
+- 固定资产调节
+- 应计负债调节
+- 递延收入调节
+- 关联方调节
+- 权益调节
+- 工资税负债与申报表核对
+
+### 4. Financial Statements（财务报表，第6-7天）
+- 生成试算表并检查异常余额
+- 编制利润表（含 MoM 和 BvA 差异分析）
+- 编制资产负债表（含调节）
+- 编制现金流量表
+- 编制支持明细表
+
+### 5. Review & Finalize（审核与结账，第7-8天）
+- Controller 审核所有调节和 journal entries
+- 最终审核财务报表
+- 锁定会计系统期间
+- 分发财务包给管理层
+- 归档支持文件
+- 结账复盘
+
+## Key Metrics
+- 目标：每月在 X 个工作日内完成结账（基准：10天，目标：7天，理想：5天）
+- 100% 资产负债表科目每月调节
+- 零重述（no restatements）
+- 零重大审计调整（< 1% 总资产）
+
+## Related Concepts
+- [[Account Reconciliation]]
+- [[GAAP Compliance]]
+- [[Journal Entry]]
+- [[Audit Readiness]]
+- [[Internal Controls]]
diff --git a/wiki/concepts/Multi-Profile-Isolation.md b/wiki/concepts/Multi-Profile-Isolation.md
new file mode 100644
index 00000000..d41d7887
--- /dev/null
+++ b/wiki/concepts/Multi-Profile-Isolation.md
@@ -0,0 +1,31 @@
+---
+title: "Multi-Profile-Isolation"
+type: concept
+tags: []
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Definition
+Multi-Profile Isolation 是通过 Hermes Agent 的 Profiles 机制实现多用户/多场景隔离的技术，每个 Profile 运行独立配置、记忆和技能。
+
+## Mechanism
+Hermes Agent 支持多 Profile：
+- **独立配置**：每个 Profile 拥有独立的 `config.yaml`、API 密钥、工具集
+- **独立记忆**：每个 Profile 的会话历史和记忆完全隔离
+- **独立技能**：每个 Profile 可启用不同的 Skills
+- **独立端口**：每个 Profile 运行独立 API Server（不同端口）
+
+## Use Case
+- 多用户场景：为不同用户/角色创建独立 Profile
+- 多场景场景：开发/测试/生产环境隔离
+- 多 Agent 场景：不同专业 Agent 使用不同 Profile
+
+## Security Benefits
+- 用户间数据完全隔离
+- 配置错误不会相互影响
+- 便于独立管理和备份
+
+## Related
+- [[Bearer-Token-Authentication]]
+- [[OpenAI-Compatible-API]]
diff --git a/wiki/concepts/Mythril.md b/wiki/concepts/Mythril.md
new file mode 100644
index 00000000..b96fa292
--- /dev/null
+++ b/wiki/concepts/Mythril.md
@@ -0,0 +1,62 @@
+---
+title: "Mythril（符号执行分析）"
+type: concept
+tags: [blockchain, security, smart-contract, symbolic-execution, tooling]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Mythril
+- Mythril Classic
+- Symbolic Execution Analyzer
+
+## Definition
+
+Mythril 是基于符号执行（Symbolic Execution）的智能合约安全分析工具，由 Consensys 开发。它通过将合约函数参数替换为符号变量，系统性地探索所有可能的执行路径，寻找可能导致资产损失或合约异常的状态。
+
+## Key Features
+
+- **符号执行**：不依赖具体输入值，遍历所有路径
+- **深度扫描**：适合关键合约的深度分析（比 Slither 慢但更深入）
+- **多种漏洞检测**：整数溢出/下溢、时间戳依赖、访问控制、逻辑漏洞
+- **生成攻击场景**：自动生成可触发漏洞的交易序列
+
+## Usage
+
+```bash
+# 基本分析
+myth analyze src/MainContract.sol --solc-json mythril-config.json
+
+# 高级配置
+myth analyze src/MainContract.sol \
+    --execution-timeout 300 \
+    --max-depth 30 \
+    -o json > mythril-results.json
+
+# 配合 Truffle
+mythril truffle compile
+mythril analyze --truffle
+```
+
+## Mythril vs Slither
+
+| Dimension | [[Slither]] | [[Mythril]] |
+|-----------|-------------|-------------|
+| Method | AST-based static analysis | Symbolic execution |
+| Speed | Fast | Slow |
+| Depth | Surface-level | Deep path coverage |
+| False positives | Low | Higher |
+| Best for | Initial scan, high-confidence bugs | Critical functions, complex logic |
+
+## Limitations
+
+- 执行超时限制（通常 5-10 分钟）
+- 路径爆炸问题（复杂合约分析不完整）
+- 外部依赖处理有限（需要 mock）
+- 已被 MythX 商业化版本部分替代
+
+## Connections
+- [[Blockchain-Security-Auditor]] ← uses ← [[Mythril]]
+- [[Slither]] ← complementary analysis ← [[Mythril]]
+- [[Formal-Verification]] ← deeper rigor ← [[Mythril]]
diff --git a/wiki/concepts/N1QueryPrevention.md b/wiki/concepts/N1QueryPrevention.md
new file mode 100644
index 00000000..3c9e9ed9
--- /dev/null
+++ b/wiki/concepts/N1QueryPrevention.md
@@ -0,0 +1,62 @@
+---
+title: "N+1 Query Prevention"
+type: concept
+tags: [database, performance, n+1, postgresql, query-optimization]
+last_updated: 2026-05-01
+---
+
+# N+1 Query Prevention
+
+## Definition
+
+N+1 查询问题是指应用程序在获取一组主对象后，对每个对象分别发起一次额外查询来获取关联数据的反模式。假设获取 N 个用户，每个用户查一次帖子，总共产生 1 + N 次数据库往返。
+
+## The Problem
+
+```typescript
+// ❌ Bad: N+1 pattern
+const users = await db.query("SELECT * FROM users LIMIT 10");
+for (const user of users) {
+  user.posts = await db.query(
+    "SELECT * FROM posts WHERE user_id = $1",
+    [user.id]
+  );
+}
+// 1 + 10 = 11 queries
+```
+
+## The Solution
+
+```typescript
+// ✅ Good: Single query with aggregation
+const usersWithPosts = await db.query(`
+  SELECT
+    u.id, u.email, u.name,
+    COALESCE(
+      json_agg(
+        json_build_object('id', p.id, 'title', p.title)
+      ) FILTER (WHERE p.id IS NOT NULL),
+      '[]'
+    ) as posts
+  FROM users u
+  LEFT JOIN posts p ON p.user_id = u.id
+  GROUP BY u.id
+  LIMIT 10
+`);
+// 1 query
+```
+
+## Key Techniques
+
+- **JOIN + json_agg**：PostgreSQL 下用 `json_agg` 聚合嵌套关联数据
+- **批量查询（Batch Loading）**：拆分为 2-3 次查询（IN 子句分批）
+- **预加载（Eager Loading）**：ORM 的 `include` / `preload` 机制
+- **物化视图**：对稳定结构做预计算
+
+## Source
+- [[engineering-database-optimizer]]
+
+## Connections
+- [[QueryPlanAnalysis]] — 通过 EXPLAIN ANALYZE 识别 N+1
+- [[engineering-backend-architect]] — 架构设计时需避免 N+1
+- [[engineering-sre]] — N+1 是生产环境性能问题的常见根源
diff --git a/wiki/concepts/NUMA.md b/wiki/concepts/NUMA.md
new file mode 100644
index 00000000..fb66ff5d
--- /dev/null
+++ b/wiki/concepts/NUMA.md
@@ -0,0 +1,39 @@
+---
+title: "NUMA"
+type: concept
+tags: [sre, performance, cloud, containers, cpu]
+last_updated: 2026-04-20
+---
+
+# NUMA (Non-Uniform Memory Access)
+
+NUMA（非一致性内存访问）是一种多处理器计算机架构中的内存访问模式，对现代容器化部署有重要影响。
+
+## Definition
+在 NUMA 架构中，CPU 和内存被组织成多个节点（nodes）。每个 CPU 访问本地内存节点的速度远快于访问远程内存节点的速度，因此称为"非一致性"内存访问。
+
+## Key Concepts
+- **NUMA Node**：由一个或多个 CPU 和与其相连的内存组成
+- **Local Memory Access**：CPU 访问本节点的内存，延迟低、带宽高
+- **Remote Memory Access**：CPU 访问其他节点的内存，延迟高、带宽低
+- **CPU Pinning**：将进程/容器固定到特定 CPU，以优化内存局部性
+
+## Why SREs Should Care
+Netflix 在现代 CPU 上运行容器时发现：
+- 运行 100 个容器需要超过 **2 万次挂载操作（mounts）**
+- NUMA 问题是影响容器调度性能的关键因素
+- SRE 必须关注**整个技术栈**，包括硬件层面的 NUMA 拓扑
+
+## Implications for Container Scheduling
+1. **NUMA-Aware Scheduling**：调度器应感知 NUMA 拓扑，避免跨节点内存访问
+2. **CPU Pinning**：对延迟敏感的应用（如 Netflix 媒体处理）需要将容器固定到特定 CPU
+3. **内存局部性优化**：减少跨 NUMA 节点的内存访问可显著降低延迟
+
+## Related Concepts
+- [[Containers]]
+- [[Kubernetes]]
+- [[Performance-Benchmarking]]
+- [[Cloud-Native]]
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]] (Netflix Mount Mayhem case study)
diff --git a/wiki/concepts/Nanite.md b/wiki/concepts/Nanite.md
index 96890775..8ddfbc5e 100644
--- a/wiki/concepts/Nanite.md
+++ b/wiki/concepts/Nanite.md
@@ -1,37 +1,48 @@
 ---
 title: "Nanite"
 type: concept
-tags: ["unreal-engine", "geometry", "performance-optimization"]
-sources: ["unreal-technical-artist", "unreal-systems-engineer", "unreal-world-builder"]
-last_updated: 2026-04-26
+tags: ["unreal-engine", "geometry", "rendering", "lod"]
+sources: ["unreal-systems-engineer", "unreal-technical-artist", "unreal-world-builder"]
+last_updated: 2026-04-30
 ---
 
+## Aliases
+- UE5 Nanite
+- Virtualized Geometry
+- 虚拟化几何系统
+
 ## Definition
-UE5 虚拟几何体系统（Virtualized Geometry System），支持自动 LOD 和海量实例化渲染。Nanite 将几何体视为由微小三角形组成的流式资源，根据屏幕空间距离动态选择精度。
+Nanite 是 Unreal Engine 5 引入的虚拟化几何系统，能够自动处理亚像素级别的几何细节，无需手动 LOD。它以软件光栅化方式运行，支持亿级三角形规模的几何细节，并且与 World Partition 和 PCG 系统天然集成。
 
-## Key Properties
-- **自动 LOD**：无需手动配置 LOD 链，系统自动处理
-- **海量实例**：支持数千个网格体同时渲染，由 PCG 驱动时尤为重要
-- **确定性精度**：相同场景始终产生相同的三角形流
-- **Nanite 禁用例外**：骨骼网格体、样条线网格体、程序化网格体无法使用 Nanite，必须手动配置 LOD 链
+## Core Characteristics
+- **无需手动 LOD**：自动从极高面数几何体流式加载
+- **实例计数优势**：PCG 实例数量轻易超过 Nanite 的优势阈值
+- **排除在 HLOD 之外**：Nanite 自身处理 LOD，不与其他 Actor 合并
+- **支持几何体类型**：StaticMesh（启用时）、Foliage（启用时）
 
-## In the PCG Pipeline
-所有 PCG 放置的静态网格体必须在 Nanite 适用时启用。PCG 的高密度特性（数千实例）与 Nanite 的海量渲染能力天然契合。
+## Performance Constraints
+- **Nanite 实例数上限**：16M（在最大视距/最大关卡）
+- **Draw Call 控制**：配合 Nanite 实例化减少 Draw Calls
+- **资产启用原则**：所有静态网格在条件允许时优先启用 Nanite
 
-## LOD vs Nanite
-| 特性 | 手动 LOD | Nanite |
-|------|---------|--------|
-| 精度切换 | 固定距离阈值 | 屏幕空间连续 |
-| 配置成本 | 高（需逐资产手动配置） | 低（启用即可） |
-| 适用资产 | 所有类型 | 静态网格体 |
-| 骨骼/程序化 | 支持 | 不支持 |
+## Integration with PCG
+PCG 放置的资产应在条件允许时启用 Nanite，典型配置：
+- 40% Oak（Nanite 启用）
+- 30% Pine（Nanite 启用）
+- 20% Birch（Nanite 启用）
+- 10% DeadTree（非 Nanite — 手动 LOD 链）
 
-## Performance Implication
-- 无 Nanite 资产的开放世界道具：禁止超过 500 三角形且无文档化例外
-- Cull Distance：Nanite 资产的远距离剔除仍通过 Cull Distance Volumes 配置
-- **[[UnrealSystemsEngineer]] 补充**：单场景硬上限 **1600 万实例**，开放世界项目需提前规划实例预算；Nanite 隐式在像素着色器推导切线空间（减少几何数据体积），因此 Nanite 网格不得存储显式切线；Nanite 不兼容骨骼网格（用标准 LOD）、复杂 clip 操作的遮罩材质（需性能基准测试）、样条网格和程序化网格组件；使用 `r.Nanite.Visualize` 模式提前发现兼容性问题
+## Nanite + Landscape
+Nanite 与 Landscape 系统协同工作，LOD 转换在远距离时由 Nanite 系统自动管理。
 
-## Related
-- [[LOD]] — 非 Nanite 资产的 LOD 链配置
-- [[PCG]] — Nanite 的主要应用场景
-- [[PerformanceBudget]] — Nanite 是开放世界性能预算的关键工具
+## Connections
+- [[UnrealEngine5]] ← 核心引擎 ← Nanite
+- [[UnrealWorldBuilder]] ← 几何渲染 ← Nanite
+- [[UnrealSystemsEngineer]] ← 几何系统 ← Nanite
+- [[UnrealTechnicalArtist]] ← 资产验证 ← Nanite
+- [[HierarchicalLOD]] ← 互补（非 Nanite 资产） ← Nanite
+
+## Sources
+- [[unreal-systems-engineer]]
+- [[unreal-technical-artist]]
+- [[unreal-world-builder]]
diff --git a/wiki/concepts/NarrativeTheory.md b/wiki/concepts/NarrativeTheory.md
new file mode 100644
index 00000000..30f30f7c
--- /dev/null
+++ b/wiki/concepts/NarrativeTheory.md
@@ -0,0 +1,33 @@
+---
+title: "Narrative Theory"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Narratology
+- 叙事学
+- Narrative Studies
+
+## Overview
+Narrative Theory（叙事学）是研究叙事的结构、机制、功能和认知的跨学科学术领域。起源于 Russian Formalism（俄罗斯形式主义），经 French Structuralism（法国结构主义）发展，在 Cognitive Narratology（认知叙事学）时代达到现代高峰。
+
+## Major Schools & Figures
+
+| School | Key Figure | Core Idea |
+|--------|-----------|-----------|
+| Russian Formalism | Shklovsky, Propp | Fabula/Sjuzhet, Defamiliarization |
+| French Structuralism | Barthes, Genette, Todorov | Narrative as language system |
+| Cognitive Narratology | Herman, Fludarnik | Mental models, situation models |
+| Post-Classical | Various | Contextual, cultural, ideological |
+
+## Key Distinctions
+- **Fabula vs. Sjuzhet**：事件序列（what happened）vs. 叙事呈现（how it is told）
+- **Story vs. Discourse**：同 Fabula/Sjuzhet
+- **Narrative Voice vs. Focalization**：谁在讲 vs. 谁在看
+- **Anachrony**：Analeptic（倒叙）/Proleptic（预叙）
+
+## In The Agency Context
+[[Academic Narratologist]] 的核心知识基础，综合运用以上所有框架为叙事问题提供精确诊断。
diff --git a/wiki/concepts/Negative-Prompting.md b/wiki/concepts/Negative-Prompting.md
new file mode 100644
index 00000000..01cb7f3c
--- /dev/null
+++ b/wiki/concepts/Negative-Prompting.md
@@ -0,0 +1,41 @@
+---
+title: "Negative Prompting"
+type: concept
+tags: [prompt-engineering, ai-image-generation, exclusion]
+last_updated: 2026-05-15
+---
+
+## Definition
+
+负向提示词（Negative Prompting）——通过明确指定不想要的内容元素，主动排除 AI 生成图像中的干扰元素和常见缺陷，提升生成结果的可控性和专业度。
+
+## Mechanism
+
+在支持负向提示词的 AI 平台（Midjourney、Stable Diffusion）中，用户通过专门的语法（`--no`、`negative_weights`、`NOT` 等）指定需要排除的元素。
+
+## Common Negative Prompt Categories
+
+- **图像缺陷**：blurry、noise、grain、artifact、distortion、overexposed、underexposed
+- **不想要的对象**：watermark、text、logo、signature、frame、border
+- **构图元素**：background clutter、distracting elements、unwanted objects
+- **质量相关**：low quality、jpeg artifacts、compression artifacts
+- **风格相关**：cartoonish（当需要写实风格时）、oversaturated、overprocessed
+
+## Best Practices
+
+- 针对性而非泛化：只排除确实不想要的特定元素，不过度使用
+- 与正向提示词协同：负向提示词补充而非替代正向提示词
+- 平台适配：各平台负向提示词语法和支持程度不同（Midjourney 的 `--no`、SD 的 negative embeddings）
+
+## Connections
+
+- [[Five-Layer-Prompt-Structure]] 的组成部分（在结构框架中标注负向提示词位置）
+- [[Midjourney]] / [[Stable-Diffusion]] 平台的核心功能
+- [[Prompt-Engineering]] 的关键技术之一
+
+## Aliases
+
+- Negative Prompt
+- Exclusion Prompt
+- NOT Prompt
+- 负向提示词
diff --git a/wiki/concepts/NetUpdateFrequency.md b/wiki/concepts/NetUpdateFrequency.md
new file mode 100644
index 00000000..ac4ce467
--- /dev/null
+++ b/wiki/concepts/NetUpdateFrequency.md
@@ -0,0 +1,48 @@
+---
+title: "NetUpdateFrequency"
+type: concept
+tags: ["unreal-engine", "networking", "performance"]
+sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- 网络更新频率
+- 复制频率
+
+## 定义
+`NetUpdateFrequency` 是 UE5 中控制 Actor 复制频率的参数，单位为 Hz（每秒更新次数）。默认 100Hz 通常过高，应按 Actor 类型差异化配置。
+
+## 默认值问题
+- 默认 `NetUpdateFrequency = 100Hz` 对大多数 Actor 过高
+- 造成不必要的带宽消耗
+- 服务器 CPU 负担增加
+
+## 差异化配置建议
+
+| Actor 类型 | NetUpdateFrequency | MinNetUpdateFrequency | 说明 |
+|-----------|-------------------|---------------------|------|
+| 高速投射物 | 100Hz | 33Hz | 精度关键 |
+| 玩家角色 | 30Hz | 15Hz | 平衡流畅与带宽 |
+| NPC 敌人 | 20Hz | 5Hz | 非玩家，可插值 |
+| 环境物体 | 2Hz | 1Hz | 状态极少变化 |
+
+## 实现方式
+```cpp
+// 在 Actor 构造函数中设置
+AMyProjectile::AMyProjectile() {
+    bReplicates = true;
+    NetUpdateFrequency = 100.f;
+    MinNetUpdateFrequency = 33.f;
+}
+```
+
+## 性能影响
+- 每玩家带宽目标 < 15KB/s
+- 最高玩家数量下测量
+- 使用 Network Profiler 验证
+
+## 相关概念
+- [[Actor Replication]] — NetUpdateFrequency 控制复制频率
+- [[Replication Graph]] — 与复制图配合优化
+- [[Server-Authoritative Model]] — 优化不影响权威模型
diff --git a/wiki/concepts/NetworkPrediction.md b/wiki/concepts/NetworkPrediction.md
new file mode 100644
index 00000000..4f0ec73d
--- /dev/null
+++ b/wiki/concepts/NetworkPrediction.md
@@ -0,0 +1,47 @@
+---
+title: "Network Prediction"
+type: concept
+tags: ["unreal-engine", "networking", "latency-compensation"]
+sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- 网络预测
+- 客户端预测
+- Client-side Prediction
+
+## 定义
+网络预测是客户端在等待服务器确认时本地预测游戏结果的技术，使玩家感觉不到网络延迟，提升游戏响应体验。
+
+## 工作原理
+1. 玩家输入 → 客户端立即应用预测结果
+2. 客户端同时发送输入到服务器
+3. 服务器执行相同逻辑
+4. 服务器将结果复制回客户端
+5. 客户端比较预测与实际结果
+6. 如有差异，进行协调（Reconciliation）
+
+## UE5 Network Prediction Plugin
+UE5 提供的官方预测框架，支持物理驱动或复杂移动的回滚：
+- `FNetworkPredictionStateBase` — 预测状态基类
+- 每秒预测状态数 = 网络频率
+- 支持移动、能力、交互等多系统
+
+## 预测与权威的关系
+```
+预测（客户端）     权威（服务器）
+    ↓                 ↓
+立即响应 ←─────── 确认/回滚
+    ↓                 ↓
+显示结果 ←─────── 复制结果
+```
+
+## 性能指标
+- 200ms 延迟下每玩家每 30 秒去同步事件应 < 1 次
+- 过多去同步 = 预测逻辑与服务器不一致
+
+## 相关概念
+- [[Server-Authoritative Model]] — 预测的基础是服务器权威
+- [[GAS (Gameplay Ability System)]] — GAS 内置 Prediction Key 支持
+- [[Actor Replication]] — 预测结果通过复制验证
diff --git a/wiki/concepts/Nudge-Sequence.md b/wiki/concepts/Nudge-Sequence.md
new file mode 100644
index 00000000..cd65856c
--- /dev/null
+++ b/wiki/concepts/Nudge-Sequence.md
@@ -0,0 +1,53 @@
+---
+title: "Nudge Sequence"
+type: concept
+tags: []
+sources: ["product-behavioral-nudge-engine"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Nudge Sequence（推动序列）是一种多渠道、渐进式用户触达策略——根据用户在每个触点的响应状态，动态调整推送渠道、时机和内容，以最大化任务完成率，同时最小化通知疲劳。
+
+## Mechanism
+
+典型的 Nudge Sequence 遵循递增压力模型：
+
+```
+Day 1: SMS（个人化、低侵入）
+    ↓ 用户无响应
+Day 3: Email（中等正式）
+    ↓ 用户无响应
+Day 7: In-App Banner（高可见性）
+    ↓ 用户无响应
+Day 14: 暂停推送 → 触发用户偏好重新确认
+```
+
+## Design Principles
+
+1. **递增原则**：渠道侵入力度随时间递增
+2. **退出检测**：任何阶段的完成操作立即停止后续推送
+3. **渠道匹配**：根据用户偏好选择初始渠道
+4. **疲劳管理**：序列完成后强制冷却期，避免过度触达
+5. **个性化调整**：根据响应率数据动态优化序列参数
+
+## Key Metrics
+
+- **到达率**：各渠道消息实际送达率
+- **打开率**：到达消息的打开/查看率
+- **完成率**：序列触发后最终任务完成百分比
+- **疲劳指数**：推送频率与用户响应率的负相关程度
+
+## Related Concepts
+
+- [[Default Bias]] — Nudge Sequence 中可嵌入默认选项利用
+- [[Cognitive Load Reduction]] — 每次只推送一个行动项
+- [[Gamification]] — 配合庆祝机制提升序列参与度
+- [[Behavioral Nudge Engine]] — Nudge Sequence 的核心应用引擎
+
+## Connections
+
+- [[Behavioral Nudge Engine]] — Nudge Sequence 的实现主体
+- [[Product Manager Agent]] — 任务优先级决定 Nudge 的触发条件
+- [[Multi-Channel Personal Assistant]] — 多渠道推送的技术实现参考
diff --git a/wiki/concepts/Nunchi.md b/wiki/concepts/Nunchi.md
index 401c6d2f..3594ec20 100644
--- a/wiki/concepts/Nunchi.md
+++ b/wiki/concepts/Nunchi.md
@@ -1,45 +1,56 @@
----
-title: "Nunchi"
-type: concept
-tags: []
-sources: []
-last_updated: 2026-04-25
----
-
-## 基本信息
-- **原文**：눈치（音：nunchi）
-- **中文**：读心术 / 察言观色 / 情境感知
-- **字面意**： 눈（眼睛）+ 치（速度/程度）= 读懂气氛的能力
-
-## 定义
-Nunchi 是韩国文化的核心社交技能，指通过**观察他人的情绪状态、语境线索和行为模式**，在对方不直接表达的情况下理解其真实意图。在韩国商业环境中，Nunchi 是建立信任、避免尴尬、推进关系的关键能力。
-
-## Nunchi 解码表（Korean Business Context）
-
-| 韩国人说（韩文） | 字面意思（英文） | 实际含义 | 应对策略 |
-|----------------|----------------|---------|---------|
-| 좋은데요... | "That's nice, but..." | 犹豫，有未表达的顾虑 | "어떤 부분이 고민이신가요?"（哪部分让您顾虑？） |
-| 검토해보겠습니다 | "We'll review it" | **婉拒**，给你一个体面退场 | 等待 5 天后若无跟进则放弃，优雅离开 |
-| 긍정적으로 검토하겠습니다 | "We'll review positively" | **真正感兴趣**，内部流程启动 | 主动发送支持材料 |
-| 어려울 것 같습니다 | "It seems difficult" | **坚定拒绝** | 优雅接受："다음에 기회가 되면 연락 주세요" |
-| 한번 보고 드려야 할 것 같습니다 | "I need to report upward" | 决策权不在此人，品의流程已触发 | 积极信号：提供一切内部说服所需材料 |
-| 바쁘시죠? | "You must be busy, right?" | 社交润滑，即将有请求 | 回复："괜찮습니다, 말씀하세요"（我没事，请说） |
-
-## 为什么 Nunchi 对外国人困难
-西方商业文化强调**直接沟通**——对"不"使用明确的语言表达。韩国文化强调**和谐优先于清晰**——直接说"不"会损害关系和对方的颜面。因此：
-- "We'll review it" ≠ "Maybe later"
-- "It's difficult" = "No"
-- 沉默（3-7天）≠ "We're not interested"
-- "Let me think about it" = "I need Nunchi time to read the room internally"
-
-## Nunchi 的实际应用场景
-1. **会议中**：观察谁的眼神在谁之间移动，判断真正的决策者
-2. **聚餐（회식）**：观察谁给谁倒酒，判断公司内部权力动态
-3. **跟进时**：判断"沉默"是积极的品의进行中，还是消极的死单
-4. **谈判中**：读懂对方真正顾虑（价格？风险？信任？），而非其表面陈述
-
-## 与品의的关系
-Nunchi 是理解 품의 流程中**隐性信号**的核心技能——审批链在内部运行，供应商看不到过程，只能通过 Nunchi 解读外部表现出的信号。
-
-## 来源
-- [[specialized-korean-business-navigator]] — Nunchi Decoder — Business Context 完整规范
+---
+title: "Nunchi"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-05-30
+---
+
+## 基本信息
+- **原文**：눈치（Nunchi）
+- **发音**：nunchi
+- **中文**：读心术 / 察言观色 / 眼力见
+- **英文**：Reading the room / Social awareness
+
+## 定义
+눈치（Nunchi）是韩国文化中最核心的概念之一，字面意思是"用眼睛测量重量"，实际指通过观察语境、情绪和微妙的行为线索来理解未被直接表达的意图和想法。Nunchi 是韩国商业中最重要的隐性技能——它决定了你能读懂多少会议室里没有说出口的内容。
+
+## 在韩国商业中的重要性
+
+韩国商业文化优先维护和谐（关系和谐），而非直接表达分歧。因此：
+- **拒绝通常不是"No"，而是沉默或模糊的"検討해보겠습니다"**
+- **积极信号不是"Yes"，而是主动提问和索取材料**
+- **真正决策发生在走廊里，而非会议桌前**
+
+## Nunchi 解码表（Korean Business Navigator 提供）
+
+| 他们说（韩文） | 字面意思 | 实际含义 | 你的行动 |
+|---------------|---------|---------|---------|
+| 좋은데요... | "That's nice, but..." | 犹豫，有顾虑但不会直接说 | "어떤 부분이 고민이신가요?"（哪方面让您顾虑？）|
+| 검토해보겠습니다 | "We'll review it" | 很可能不行，给你台阶 | 等5天，无跟进则放弃 |
+| 긍정적으로 검토하겠습니다 | "We'll review positively" | 真正感兴趣，内部流程启动 | 主动发送补充材料 |
+| 어려울 것 같습니다 | "It seems difficult" | 明确拒绝 | 优雅接受，问下次机会 |
+| 한번 보고 드려야 할 것 같습니다 | "I need to report upward" | 决策权不在他，품의已触发 | 好信号，提供一切内部推进所需的材料 |
+| 바쁘시죠? | "You must be busy, right?" | 社交润滑，马上要提出请求 | "괜찮습니다, 말씀하세요"（没事，请说）|
+
+## Nunchi 核心原则
+1. **永远不要只看字面意思** — 韩国人说的话通常包含两层含义
+2. **沉默不是否定** — 3-7 天的沉默可能意味着内部讨论正在进行
+3. **主动提问者 = 真正感兴趣** — 索取案例和参考资料是强烈购买信号
+4. **"상부에서 검토 중입니다"（上级正在审查）是进展信号** — 意味着在推进，不是卡住
+5. **观察肢体语言和座位安排** — 谁坐在谁旁边决定谁听谁的
+
+## Nunchi vs 西方"直接沟通"的张力
+- 西方文化：直接询问"你们打算买吗？"是专业和高效的体现
+- 韩国文化：这样问等于逼迫对方说"不"，破坏和谐
+- 解决方式：通过观察间接信号判断意向，而非直接询问
+
+## 如何培养 Nunchi
+1. **注意开场白**：韩国人通常以寒暄开始，直接切入正题显示不懂礼貌
+2. **观察座位**：상석（主座，最远离门的位置）是最重要的人
+3. **记录谁称呼谁**："과장님"还是直呼其名，暗示关系深度
+4. **关注被叫进来的人**：如果第二会议规模扩大，说明认真程度提升
+5. **留意회식（聚餐）邀请**：主动邀请聚餐是建立信任的关键信号
+
+## 来源
+- [[specialized-korean-business-navigator]] — Nunchi Decoder — Business Context 完整规范
diff --git a/wiki/concepts/Observability.md b/wiki/concepts/Observability.md
index e5d4b8a9..a0f0f2a2 100644
--- a/wiki/concepts/Observability.md
+++ b/wiki/concepts/Observability.md
@@ -1,72 +1,85 @@
 ---
 title: "Observability"
 type: concept
-tags: [Observability, SRE, Cloud-Native, Telemetry, Monitoring, Reliability]
-sources:
-  - public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113
-  - ctp-topic-67-cloud-native-observability-using-opentelemetry
-  - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2
-last_updated: 2026-04-29
+tags: [DevOps, Monitoring, Reliability]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
 ---
 
-## Observability（可观测性）
+# Observability
 
-可观测性（Observability）是指系统通过其外部输出理解其内部状态的能力。在软件工程中，可观测性通过遥测数据（Telemetry）——指标（Metrics）、日志（Logs）、追踪（Traces）——持续理解系统健康状态，是 [[SRE]] 和 [[Recovery-Assurance]] 的核心技术基础。
+## 定义
+可观测性（Observability）是通过收集系统外部输出来推断其内部状态的能力，核心目标是回答"为什么系统出现了问题"，而不仅仅是"系统是否正常"。
 
-## Three Pillars
+## 可观测性三支柱
 
-可观测性三大支柱（Three Pillars of Observability）：
+### 1. 指标（Metrics）
+- **定义**：数值型测量，反映系统健康状况
+- **特点**：聚合性强、支持告警、存储成本相对低
+- **工具**：[[Prometheus]]、CloudWatch、DataDog
+- **示例**：CPU 使用率、请求延迟、错误率、QPS
 
-| 支柱 | 说明 | 示例 |
-|------|------|------|
-| **Metrics（指标）** | 聚合的数值数据，反映系统状态趋势 | CPU 使用率、请求延迟、错误率 |
-| **Logs（日志）** | 离散的事件记录，按时间顺序记录系统活动 | 访问日志、错误日志、审计日志 |
-| **Traces（追踪）** | 跨服务和组件的请求传播路径 | 分布式链路追踪、调用链可视化 |
+### 2. 日志（Logs）
+- **定义**：系统产生的离散事件记录
+- **特点**：详细信息、时序排列、关联分析
+- **工具**：ELK Stack（Loki）、CloudWatch Logs
+- **示例**：访问日志、错误日志、审计日志
 
-## Observability vs. Monitoring
+### 3. 追踪（Traces）
+- **定义**：请求在分布式系统中的完整调用路径
+- **特点**：端到端关联、延迟分析、瓶颈定位
+- **工具**：Jaeger、Zipkin、AWS X-Ray
+- **示例**：微服务调用链、数据库查询耗时
 
-传统监控（Monitoring）与可观测性（Observability）的核心区别：
+## SRE 可观测性实践
 
-| 维度 | 传统监控（Monitoring） | 可观测性（Observability） |
-|------|---------------------|-------------------------|
-| **目标** | 回答预设问题 | 回答任意未知问题 |
-| **假设** | 故障模式已知 | 故障模式未知（High Cardinality） |
-| **数据** | 聚合指标，低基数 | 原始事件，高基数 |
-| **根因定位** | 依赖仪表板预设视图 | 通过遥测数据探索定位 |
-| **适用场景** | 稳定系统 | 云原生、分布式系统 |
+### RED 方法（面向服务）
+- **Rate**：请求率（每秒请求数）
+- **Errors**：错误率（失败请求百分比）
+- **Duration**：延迟（响应时间分布）
 
-> "You can't monitor your way to understanding a distributed system. You need observability." — Charity Majors
+### USE 方法（面向资源）
+- **Utilization**：利用率
+- **Saturation**：饱和度
+- **Errors**：错误
 
-## Observability Engineering
+## 在 DevOps Automator 中的应用
+DevOps Automator 的可观测性体系：
+1. **指标收集**：Prometheus scrape metrics
+2. **可视化**：Grafana Dashboard
+3. **告警**：Prometheus Alert Rules → AlertManager
+4. **日志聚合**：可选 Loki/ELK
+5. **分布式追踪**：可选 Jaeger
 
-可观测性工程（Observability Engineering）是将可观测性作为架构设计原则，在软件开发生命周期中内嵌遥测数据收集：
+### 关键监控指标
+- 部署频率（Deployment Frequency）
+- 变更失败率（Change Failure Rate）
+- MTTR（Mean Time To Recovery）
+- 可用性（Availability）
 
-- **Left-Shift**：在开发阶段就定义 SLI/SLO，持续验证
-- **Telemetry as Code**：将遥测配置纳入 IaC，实现版本化管理
-- **Continuous Validation**：用主动探测（Synthetic Monitoring）验证恢复路径
+## 相关概念
+- [[Prometheus]]：指标采集和告警核心组件
+- [[Grafana]]：指标可视化平台
+- [[Zero-Downtime Deployment]]：可观测性支撑零停机部署的监控需求
 
-## Connection to SRE and Recovery Assurance
+## 相关工具
+| 类型 | 工具 |
+|------|------|
+| 指标 | Prometheus, CloudWatch, DataDog, New Relic |
+| 日志 | ELK Stack, Loki, CloudWatch Logs |
+| 追踪 | Jaeger, Zipkin, AWS X-Ray, OpenTelemetry |
+| 可视化 | Grafana, Datadog Dashboards |
 
-在 [[SRE]] 实践中，可观测性是实现可靠性目标的必要条件：
+## SRE 四个黄金信号
+Google SRE 提出的关键指标：
+1. **Latency**：延迟
+2. **Traffic**：流量
+3. **Errors**：错误
+4. **Saturation**：饱和度
 
-- **SLI/SLO/SLA 的测量基础**：可观测性提供量化可靠性的原始数据
-- **Error Budget 的支撑**：通过指标追踪 Error Budget 消耗速度
-- **On-Call 响应的依据**：日志和追踪是 MTTR（Mean Time To Recovery）的核心数据源
-- **[[Recovery-Assurance]] 的前提**：无法观测的系统无法保证恢复能力
-
-## OpenTelemetry
-
-[[OpenTelemetry]]（OTel）是 CNCF 的开源可观测性框架，提供厂商中立的指标、日志、追踪统一采集标准。
-
-## Related Concepts
-
-- [[SRE]] — 可观测性是 SRE 四大黄金信号的基础
-- [[Recovery-Assurance]] — 可观测性是 Recovery Assurance 的技术前提
-- [[OpenTelemetry]] — 可观测性工程的具体实现框架
-- [[RTO]] / [[RPO]] — 可观测性支撑 RTO/RPO 的持续监控
-
-## Sources
-
-- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]
-- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
-- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]
+## Aliases
+- 可观测性
+- Observability
+- Monitoring
+- 监控
+- 可观测系统工程
diff --git a/wiki/concepts/Obsidian-Git.md b/wiki/concepts/Obsidian-Git.md
new file mode 100644
index 00000000..9a044388
--- /dev/null
+++ b/wiki/concepts/Obsidian-Git.md
@@ -0,0 +1,39 @@
+---
+title: "Obsidian Git"
+type: concept
+tags: [tool, obsidian, version-control, git]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- Obsidian Git 插件
+- Obsidian Git 扩展
+
+## Definition
+Obsidian 的社区插件，为 Vault 提供 Git 版本管理功能，支持自动 commit + push 到远程仓库。是 LLM Wiki 的**必选项**——AI 批量改文件的能力越强，越需要版本管理来兜底。
+
+## Setup Steps
+1. 设置 → 第三方插件 → 社区插件市场 → 搜索 "git" → 安装并启用
+2. 如果 Vault 还不是 Git 仓库：
+   ```bash
+   git init
+   git remote add origin https://github.com/用户名/knowledge-bases.git
+   git branch -M main
+   git add .
+   git commit -m "init: 初始化知识库"
+   git push -u origin main
+   ```
+3. 在 Obsidian Git 插件设置中，将 **Auto commit-and-sync interval** 设为 10 分钟
+
+## Value for LLM Wiki
+- **实时备份 + 完整历史**：每隔几分钟插件自动 commit + push，完全无需手动操作
+- **版本兜底**：AI 批量修改多个文件时，可随时回滚到任意历史版本
+- **多设备同步**：通过 GitHub 实现跨设备同步
+
+## Note
+建议创建**私有仓库**（Private Repository），知识库内容属于私人数据。
+
+## Connections
+- [[Obsidian Git]] ← 版本管理 ← [[LLM Wiki]]
+- [[Obsidian Git]] ← 插件 → [[Obsidian]]
diff --git a/wiki/concepts/Obsidian-Web-Clipper.md b/wiki/concepts/Obsidian-Web-Clipper.md
new file mode 100644
index 00000000..617408ec
--- /dev/null
+++ b/wiki/concepts/Obsidian-Web-Clipper.md
@@ -0,0 +1,27 @@
+---
+title: "Obsidian Web Clipper"
+type: concept
+tags: [tool, obsidian, browser-extension, clipping]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- Obsidian Web Clipper 扩展
+- Obsidian 网页剪藏插件
+
+## Definition
+Obsidian 的浏览器扩展插件，可一键将任意网页文章保存为 Markdown 格式，自动存入 Obsidian Vault。是 LLM Wiki 素材采集的关键工具。
+
+## Usage Flow
+1. 在 Chrome 浏览器安装 Obsidian Web Clipper 扩展
+2. 打开任意网页文章
+3. 点击扩展图标 → "Add to Obsidian"
+4. 文章自动转为 Markdown 出现在 Vault 里
+
+## Key Benefit
+将人类从"复制粘贴整理"的工作中解放——素材采集完全自动化，AI 可以直接读取和处理。
+
+## Connections
+- [[Obsidian Web Clipper]] ← 采集工具 ← [[LLM Wiki]]
+- [[Obsidian Web Clipper]] ← 插件 → [[Obsidian]]
diff --git a/wiki/concepts/Obsidian.md b/wiki/concepts/Obsidian.md
new file mode 100644
index 00000000..3b3434c7
--- /dev/null
+++ b/wiki/concepts/Obsidian.md
@@ -0,0 +1,40 @@
+---
+title: "Obsidian"
+type: concept
+tags: [tool, note-taking, local]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki, 养虾日记3, obsidian-官方-cli-命令全景速查表, obsidian-cli]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- Obsidian.md
+
+## Definition
+本地化的双链笔记工具，以 Markdown 文件为核心存储格式，支持双向链接、图谱视图和丰富的社区插件生态。是 LLM Wiki 方法论的理想载体。
+
+## Core Features
+- **双向链接（wikilink）**：`[[页面名]]` 语法创建页面间链接
+- **Graph View**：以节点和连线展示所有页面及其链接关系
+- **本地存储**：所有数据保存在本地 Vault（文件夹），不依赖云端
+- **丰富的插件生态**：Obsidian Git、Dataview、Marp Slides、Web Clipper 等
+- **社区插件市场**：内置插件管理器，支持搜索和安装社区插件
+
+## Key Plugins for LLM Wiki
+- **[[Obsidian Web Clipper]]**：浏览器插件，一键将网页保存为 Markdown
+- **[[Obsidian Git]]**：Vault 版本管理，自动 commit + sync
+- **[[Dataview]]**：对 frontmatter 做数据库式查询
+- **[[Marp]]**：Markdown 幻灯片预览和导出
+- **[[Graph View]]**：内置图谱视图（Ctrl+G 打开）
+
+## Configuration Notes
+- 附件存储路径：建议设为 `attachments` 子文件夹，避免所有附件混在一个目录
+- 图片本地化：使用 Ctrl+Shift+D 快捷键批量下载图片到本地
+- 注意：LLM 目前无法一次性读取带内嵌图片的 Markdown，需先读文本再单独查看图片
+
+## Role in LLM Wiki
+**"Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库"**（[[llm-wiki]] 核心比喻）
+
+## Connections
+- [[Obsidian]] ← 工具 ← [[LLM Wiki]]
+- [[Obsidian]] ← 工具 ← [[Second Brain]]
+- [[Obsidian]] ← 插件生态 → [[Obsidian Web Clipper]], [[Obsidian Git]], [[Dataview]], [[Marp]]
diff --git a/wiki/concepts/OneFilePerActor.md b/wiki/concepts/OneFilePerActor.md
new file mode 100644
index 00000000..7c1b43ab
--- /dev/null
+++ b/wiki/concepts/OneFilePerActor.md
@@ -0,0 +1,53 @@
+---
+title: "OneFilePerActor"
+type: concept
+tags: ["unreal-engine", "collaboration", "version-control", "world-partition"]
+sources: ["unreal-world-builder"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- OFPA
+- One File Per Actor
+- 单 Actor 单文件
+- Per-Actor Asset 分块
+
+## Definition
+One File Per Actor（OFPA）是 Unreal Engine 5 World Partition 模式下的多用户协作编辑机制。每个 Actor 存储在独立文件中，而非整个关卡一个文件，从而支持多人同时编辑不同 Actor 而不产生源控制冲突。
+
+## Problem Solved
+传统关卡文件（所有 Actor 在一个 `.umap` 中）的协作问题：
+- 两人同时打开同一关卡 → 文件冲突
+- 某人保存后另一人保存 → 后者覆盖前者改动
+- 锁定整个关卡才能安全编辑 → 串行化工作流程
+
+## OFPA Workflow
+1. 每个 Actor 存储为 `Path/To/Actor_Name/ActorName.uasset`
+2. 多人可同时编辑不同 Actor，无需锁定
+3. 源控制按 Actor 粒度管理变更
+4. 关卡文件仅存储 Actor 引用而非内容
+
+## Team Education Requirements
+必须教育团队：
+- **签出方式**：按 Actor 单独签出，而非整个关卡
+- **依赖理解**：Actor 引用关系在关卡文件中，更改引用仍需操作关卡文件
+- **命名规范**：Actor 命名必须符合团队规范，避免歧义
+
+## File Count Management
+OFPA 启用后大规模关卡产生数千个 Actor 文件：
+- 必须建立**文件数预算**
+- 监控文件数增长趋势
+- 构建关卡审计工具，标记尚未转换为 OFPA 的遗留关卡
+
+## OFPA Limitations
+- 大量 Actor 文件增加文件系统压力
+- 某些第三方插件可能不完全兼容 OFPA
+- 源控制仓库大小显著增加（更多小文件）
+
+## Connections
+- [[WorldPartition]] ← 协作模式 ← OneFilePerActor
+- [[UnrealWorldBuilder]] ← 多用户支持 ← OneFilePerActor
+- [[UnrealEngine5]] ← 核心引擎 ← OneFilePerActor
+
+## Sources
+- [[unreal-world-builder]]
diff --git a/wiki/concepts/OpenAI-Compatible-API.md b/wiki/concepts/OpenAI-Compatible-API.md
new file mode 100644
index 00000000..569c2524
--- /dev/null
+++ b/wiki/concepts/OpenAI-Compatible-API.md
@@ -0,0 +1,30 @@
+---
+title: "OpenAI-Compatible-API"
+type: concept
+tags: []
+---
+
+## Definition
+OpenAI 兼容 API 是一种标准化的 AI 模型调用接口规范，遵循 OpenAI Chat Completions API 的请求/响应格式，使第三方 AI 系统能够被标准 AI 工具（如 n8n、LangChain）无缝调用。
+
+## Key Properties
+- **请求格式**：遵循 OpenAI `chat/completions` 规范
+- **模型指定**：通过 `model` 字段指定具体的 Agent（如 `openclaw:main`）
+- **认证方式**：Bearer Token（`Authorization: Bearer <token>`）
+- **端点**：通常是 `/v1/chat/completions`
+
+## Example
+OpenClaw Gateway 提供的 OpenAI 兼容端点：
+- **URL**：`http://<host>:18789/v1/chat/completions`
+- **Body**：
+  ```json
+  {
+    "model": "openclaw:main",
+    "messages": [{"role": "user", "content": "..."}]
+  }
+  ```
+
+## Related
+- [[OpenClaw]] 通过 `gateway.http.endpoints.chatCompletions.enabled: true` 提供此接口
+- [[HTTP-ChatCompletions]] 是其底层协议
+- [[n8n]] 通过 HTTP Request 节点调用此接口
diff --git a/wiki/concepts/OpenAI兼容API.md b/wiki/concepts/OpenAI兼容API.md
new file mode 100644
index 00000000..274f5b39
--- /dev/null
+++ b/wiki/concepts/OpenAI兼容API.md
@@ -0,0 +1,36 @@
+---
+title: "OpenAI兼容API"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+Hermes Agent 内置的 API Server 暴露的标准 OpenAI Chat Completions 接口格式，允许任何兼容 OpenAI API 的客户端（如 n8n、curl、Postman）直接调用，无需额外 SDK 或中间件。
+
+## Details
+- 默认端口 **8642**，端点路径 `/v1/chat/completions`
+- 认证方式：Bearer Token（通过 `API_SERVER_KEY` 配置）
+- 健康检查端点：`GET /v1/health`，返回 `{"status": "ok"}`
+- 支持 `X-Hermes-Session-Id` header 实现会话保持（v0.7.0+）
+- 模型名称默认为 `hermes-agent`，可在 Profile 级别自定义
+
+## Usage
+- [[n8n]] 的 HTTP Request 节点通过 POST 到该端点实现 Agent 调用
+- curl 验证命令：
+  ```bash
+  curl http://localhost:8642/v1/chat/completions \
+    -H "Authorization: Bearer YOUR_KEY" \
+    -H "Content-Type: application/json" \
+    -d '{"model": "hermes-agent", "messages": [{"role": "user", "content": "Hello!"}]}'
+  ```
+
+## Related
+- [[HermesAgent]] — API Server 的宿主框架
+- [[X-Hermes-Session-Id]] — API 的会话保持机制
+- [[工作流编排]] — 该 API 的主要应用场景
+
+## Aliases
+- OpenAI Compatible API
+- OpenAI-compatible API endpoint
+- Hermes API Server
diff --git a/wiki/concepts/Organizational-Second-Hit-Syndrome.md b/wiki/concepts/Organizational-Second-Hit-Syndrome.md
new file mode 100644
index 00000000..b4110775
--- /dev/null
+++ b/wiki/concepts/Organizational-Second-Hit-Syndrome.md
@@ -0,0 +1,36 @@
+---
+title: "Organizational Second Hit Syndrome"
+type: concept
+tags: [sre, reliability, incident-response, organizational-resilience]
+last_updated: 2026-04-20
+---
+
+# Organizational Second Hit Syndrome
+
+组织二次冲击综合征（Organizational Second Hit Syndrome）是一种类比神经学"二次冲击综合征（Second Impact Syndrome, SIS）"的故障现象。
+
+## Definition
+重大故障（first hit）发生后，组织会进入一段脆弱期（vulnerable period）。在此期间，如果发生第二次故障（second hit），往往会引发**强烈、广泛且有时具有破坏性的组织反应**。
+
+## Background
+这一概念由 [[Richard-Cook]] 博士首次提出（2026年3月7日），由 [[John-Allspaw]] 和 [[Richard-Cook]] 在 [[Adaptive-Capacity-Labs]] 发表。
+
+## Key Characteristics
+- **时间相关性**：Second hit 发生在 first hit 之后的脆弱期内
+- **影响范围**：反应强度大，影响面广，可能造成组织级损害
+- **与神经学 SIS 的类比**：神经学 SIS 中，第一次脑部损伤后如果再次受伤，即使伤势轻微也可能导致灾难性后果；组织 SIS 同理
+
+## Implications for SRE
+1. **故障后的恢复期需要特别关注**：首次故障后不要放松警惕
+2. **制定"二次故障"应对预案**：在复盘和恢复阶段保持警戒
+3. **组织层面的韧性建设**：建立跨团队沟通机制，防止信息孤岛导致的二次事故扩大
+4. **MTTR（Mean Time to Recovery）优化**：不仅关注单次故障，还要关注故障间的组织状态
+
+## Related Concepts
+- [[Incident-Response]]
+- [[BlamelessPostMortem]]
+- [[Resilience]]
+- [[Self-Healing]]
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/concepts/Outcome-vs-Output.md b/wiki/concepts/Outcome-vs-Output.md
new file mode 100644
index 00000000..77d2aa6a
--- /dev/null
+++ b/wiki/concepts/Outcome-vs-Output.md
@@ -0,0 +1,41 @@
+---
+title: "Outcome vs. Output"
+type: concept
+tags: ["product-management", "mindset", "strategy"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Outcome over Output
+- 结果导向 vs. 产出导向
+- 以结果为中心
+
+## Definition
+Outcome vs. Output（结果 vs. 产出）—— 产品管理的核心思维模式：**结果（Outcome）** 是用户行为的实际改变和业务价值达成；**产出（Output）** 是交付的功能数量、特性或里程碑。
+
+## Core Distinction
+
+| 维度 | Output（产出） | Outcome（结果） |
+|------|--------------|----------------|
+| 关注点 | 做了什么 | 用户改变了什么 |
+| 度量 | 功能数量、上线时间 | 指标改善、用户行为变化 |
+| 陷阱 | 功能上线即成功 | 以活动代替进步 |
+| 典型错误 | "我们交付了 X 功能" | 没人用的功能 |
+
+## Key Quotes
+> "A feature shipped that nobody uses is not a win — it's waste with a deploy timestamp." — [[Product Manager Agent]]（Alex）
+
+> "Features are hypotheses. Shipped features are experiments. Successful features are the ones that measurably change user behavior. Everything else is a learning." — [[Product Manager Agent]]
+
+## Why It Matters
+- **防止虚荣指标**：团队交付了很多功能，但用户留存没有改善
+- **保护资源**：避免在无人使用的功能上浪费工程资源
+- **对齐业务**：确保团队努力直接转化为商业价值
+
+## Application
+[[Product Manager Agent]] 在所有产品文档（PRD、Opportunity Assessment、Launch Retrospective）中坚持使用 Outcome 思维，并在成功指标定义中要求可量化的用户行为指标（如 30 天留存率、功能激活率）而非功能完成状态。
+
+## Related
+- [[Product Requirements Document (PRD)]] — 要求明确的结果指标（Goals & Success Metrics）
+- [[Product Manager Agent]] — 坚持结果导向的核心理念
+- [[Product Roadmap (Now/Next/Later)]] — 路线图按结果而非交付物组织
diff --git a/wiki/concepts/OverlapAwareChunking.md b/wiki/concepts/OverlapAwareChunking.md
new file mode 100644
index 00000000..8e041963
--- /dev/null
+++ b/wiki/concepts/OverlapAwareChunking.md
@@ -0,0 +1,55 @@
+---
+title: "OverlapAwareChunking"
+type: concept
+tags: ["voice-ai", "audio-processing", "transcription", "chunking"]
+last_updated: 2026-05-02
+---
+
+# OverlapAwareChunking（重叠感知分块）
+
+## Definition
+
+Overlap-Aware Chunking 是将超长音频（>30 分钟）切分为多个重叠片段再分别转录的技术。重叠窗口（默认 30s）在合并阶段被裁剪，防止词边界在切分处被切断而产生重复或遗漏。
+
+## The Problem
+
+Whisper 类模型有最大输入时长限制（通常 30 秒到 10 分钟，取决于模型）。超出限制的音频如果直接截断，会导致：
+1. 词在切分点被切断 → 产生乱码/重复词
+2. 最后一块音频尾部被截断 → 内容丢失
+3. 丢失跨块语义连贯性
+
+## The Solution
+
+```
+原始音频（120 分钟）
+       ↓ 分块（每块 30 分钟，重叠 30 秒）
+chunk_0000: [0:00 - 30:30]
+chunk_0001: [30:00 - 60:30]  ← 重叠 30 秒
+chunk_0002: [60:00 - 90:30]  ← 重叠 30 秒
+...
+       ↓ 逐块 FasterWhisper 转录
+       ↓ 合并（裁剪重叠区域）
+最终转录文本（无重复/遗漏）
+```
+
+## Key Parameters
+
+| 参数 | 默认值 | 说明 |
+|------|--------|------|
+| `chunk_duration` | 1800s（30分钟） | 每块时长 |
+| `overlap` | 30s | 重叠窗口大小 |
+| 合并时裁剪 | 30s | 从第二块开始，裁掉前 30 秒 |
+
+## Critical Insight
+
+> "Overflow is silent and corrupts output without error." — 溢出无声损坏输出
+
+分块策略的错误不会抛出异常，只会在最终合并的转录文本中出现乱码/重复/遗漏，难以事后发现。
+
+## Related Concepts
+- [[FasterWhisper]] — 分块音频的转录执行方
+- [[VoiceActivityDetection]] — VAD 过滤在分块前执行效果更佳
+- [[StructuredTranscriptJSON]] — 分块合并后结构化输出的最终格式
+
+## Related Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/concepts/PIIRedaction.md b/wiki/concepts/PIIRedaction.md
new file mode 100644
index 00000000..076e1c23
--- /dev/null
+++ b/wiki/concepts/PIIRedaction.md
@@ -0,0 +1,56 @@
+---
+title: "PIIRedaction"
+type: concept
+tags: ["privacy", "pii", "gdpr", "hipaa", "voice-ai"]
+last_updated: 2026-05-02
+---
+
+# PIIRedaction（个人身份信息脱敏）
+
+## Definition
+
+PII Redaction 是在转录管道中将个人身份信息（姓名、身份证号、信用卡、电话、邮箱等）自动检测并替换为占位符或删除的处理阶段。作为命名且可配置的管道阶段嵌入，不是事后补丁。
+
+## Why It Must Be a Pipeline Stage
+
+- **合规性**：HIPAA（医疗）、GDPR（欧洲）、SOC 2（企业安全）要求处理录音/转录时保护 PII
+- **不可逆性**：一旦 PII 被写入日志/CMS/数据库，删除成本极高
+- **范围**：医疗记录（MRN、病历号）、法律记录（案件号、律师姓名）、客服录音（账号、密码）
+
+## Detection Methods
+
+| 方法 | 适用场景 | 精度 |
+|------|---------|------|
+| 正则规则 | 电话、邮箱、信用卡、SSN | 高（规则明确） |
+| NER 模型 | 人名、地址、机构名 | 中（依赖模型质量） |
+| 云端 PII API | 大规模、多种 PII 类型 | 高（AssemblyAI/云 ASR 内置） |
+
+## Pipeline Position
+
+```
+音频 → 预处理 → 转录 → PII 检测 → 结构化输出 → 下游系统
+                 ↑
+         PIIRedaction 在转录之后执行
+```
+
+## Redaction Symbols
+
+| 符号 | 含义 |
+|------|------|
+| `[REDACTED]` | 已脱敏 |
+| `[PHONE]` | 电话号码 |
+| `[EMAIL]` | 邮箱地址 |
+| `[SSN]` | 社保号 |
+| `[NAME]` | 人名 |
+
+## Critical Rule
+
+> "Never log raw audio content or unredacted transcript text in production monitoring systems." — 生产监控中禁止记录未脱敏内容
+
+## Related Concepts
+- [[StructuredTranscriptJSON]] — PII 脱敏后的输出格式
+- [[LLMHandoff]] — 脱敏后传递给 LLM（避免 LLM 学习 PII）
+- [[PIIRedaction]] 在 [[engineering-voice-ai-integration-engineer]] 中是命名管道阶段
+
+## Related Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/concepts/Pacing-Chart.md b/wiki/concepts/Pacing-Chart.md
new file mode 100644
index 00000000..566db1e9
--- /dev/null
+++ b/wiki/concepts/Pacing-Chart.md
@@ -0,0 +1,61 @@
+---
+title: "Pacing Chart"
+type: concept
+tags: ["game-design", "level-design", "player-experience", "tension-management"]
+sources: ["level-designer.md"]
+last_updated: 2026-05-07
+---
+
+## Definition
+
+Pacing Chart（节奏图表）是游戏关卡设计中的时间-张力可视化工具，通过将关卡时间轴分解为活动类型和张力级别，直观展示玩家在关卡中的情感曲线。核心理念：**通过空间节奏引导玩家情感——紧张、释放、探索、战斗交替出现，避免单一情绪持续过久导致疲劳**。
+
+## Core Components
+
+### Time Axis
+关卡时间轴，单位为关卡内部时间（如 `0:00`、`1:30`、`3:00`）或百分比进度。
+
+### Activity Type
+活动类型分类：
+- **Exploration**（探索）—— 低压力空间发现，节奏偏缓
+- **Combat**（战斗）—— 高强度对抗，分 small/medium/large 三档
+- **Traversal**（穿越）—— 移动与平台跳跃，中等压力
+- **Story**（叙事）—— 过场或环境叙事时刻
+- **Reward**（奖励）—— 获得道具或能力，给予正向反馈
+- **Resolution**（收束）—— 阶段或关卡结束的松弛区间
+
+### Tension Level
+张力等级：Low → Medium → High → Peak → Release
+
+## Pacing Arc Template
+
+典型关卡的节奏弧线：
+
+```
+时间    | 活动类型     | 张力等级 | 笔记
+--------|-------------|-----------|--------------------------
+0:00    | Exploration  | Low       | 环境故事引入
+1:30    | Combat(sm)  | Medium     | 教学机制X
+3:00    | Exploration  | Low       | 奖励+世界观建立
+4:30    | Combat(lg)  | High       | 在压力下应用机制X
+6:00    | Resolution  | Low        | 呼吸空间+出口
+```
+
+## Design Principles
+
+1. **张力-释放交替**：每次高张力时刻后必须有释放期，否则玩家疲劳
+2. **新机制教学嵌入低张力区**：玩家首次接触机制时，应在低压力探索区而非战斗区
+3. **奖励节奏匹配挑战节奏**：大型战斗后应紧跟奖励区，形成正反馈闭环
+4. **高潮点唯一性**：每个关卡应有且仅有一个真正的 Peak，避免多峰导致重点模糊
+
+## Connections
+
+- [[Level Designer]] 使用 Pacing Chart 作为核心交付物
+- [[Grey Box Blockout]] 阶段即需验证 Pacing Chart 的可执行性
+- [[Encounter Design]] 的战斗规模直接影响 Pacing Chart 的张力峰值
+- [[Game Designer]] 定义宏观游戏节奏，Pacing Chart 在关卡层面落地执行
+
+## Related Concepts
+
+- [[Environmental Storytelling]]（环境叙事）：影响 Exploration 时段的情感密度
+- [[Navigation Affordance]]（导航可达性）：Exploration 区域的迷路时间计入节奏
diff --git a/wiki/concepts/Parallel-Build-Tracks.md b/wiki/concepts/Parallel-Build-Tracks.md
new file mode 100644
index 00000000..774531ed
--- /dev/null
+++ b/wiki/concepts/Parallel-Build-Tracks.md
@@ -0,0 +1,34 @@
+---
+title: "Parallel Build Tracks"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-05-01
+---
+
+## Definition
+
+NEXUS-Full 部署模式下，四条功能独立但协同运作的并行开发轨道。每条轨道管理不同的关注面（产品开发、质量运营、增长营销、品牌体验），由不同的 Agent 群组驱动，在整个 Phase 3 期间同时运行。
+
+## Tracks
+
+| Track | Focus | Key Agents | Continuous Activities |
+|-------|-------|-----------|----------------------|
+| **Track A** | Core Product | Agents Orchestrator, Frontend Developer, Backend Architect, AI Engineer, Evidence Collector | Dev↔QA 循环，2 周 Sprint |
+| **Track B** | Growth & Marketing | Project Shepherd, Growth Hacker, Content Creator, Social Media Strategist, App Store Optimizer | 增长飞轮、发布内容、市场活动 |
+| **Track C** | Quality & Operations | Agents Orchestrator, Evidence Collector, API Tester, Performance Benchmarker, Workflow Optimizer, Experiment Tracker | 持续质量验证、流程改进、A/B 测试 |
+| **Track D** | Brand & Experience | Brand Guardian, UI Designer, Visual Storyteller, Whimsy Injector | 品牌一致性审计、视觉抛光、微交互设计 |
+
+## Usage
+
+仅在 NEXUS-Full 部署时激活。四条轨道共享同一 Sprint 节奏（与 Track A 的 2 周 Sprint 对齐），但 Track B/C/D 按里程碑而非每日迭代运行。
+
+## Connections
+
+- [[Dev-QA-Loop]] ← driven_by ← Track A（核心驱动机制）
+- [[Agents-Orchestrator]] ← manages ← Track A（Orchestrator 主导 Track A）
+- [[Quality-Gate]] ← end_of ← Phase 3（所有四条轨道的输出汇聚到质量门）
+
+## Aliases
+- Parallel Development Tracks
+- NEXUS Build Tracks
diff --git a/wiki/concepts/Parallel-Workstream.md b/wiki/concepts/Parallel-Workstream.md
new file mode 100644
index 00000000..21d18304
--- /dev/null
+++ b/wiki/concepts/Parallel-Workstream.md
@@ -0,0 +1,44 @@
+---
+title: "Parallel Workstream"
+type: concept
+tags: [multi-agent, orchestration, concurrency, nexus]
+sources: [executive-brief, quickstart, nexus-spatial-discovery]
+last_updated: 2026-05-01
+aliases:
+  - Simultaneous Tracks
+  - Parallel Execution
+  - Multi-Track Pipeline
+---
+
+## Definition
+
+并行工作流（Parallel Workstream）—— NEXUS 多 Agent 编排框架的核心加速机制，在同一时间段内同时激活多个专业 Agent 工作轨道（Track），通过并发执行压缩项目时间线。
+
+## Quantified Impact
+
+- **时间线压缩**：40-60% —— 与顺序激活 Agent 相比，并行工作流可将典型 16 周项目压缩至 4-8 周
+- **轨道数量**：4 条标准轨道 —— Core Product / Growth / Quality / Brand
+- **并发加速比**：非线性的 —— 并行度增加时，加速效果递减（Amdahl 定律）
+
+## NEXUS 4 条标准轨道
+
+| 轨道 | 主导 Agent | 职责 |
+|------|-----------|------|
+| Core Product | Backend Architect + Frontend Developer | 核心产品功能实现 |
+| Growth | Growth Hacker | 用户增长与市场策略 |
+| Quality | Testing Reality Checker + QA Agents | 质量验证与缺陷修复 |
+| Brand | Brand Guardian | 品牌身份与视觉系统 |
+
+## Coordination Mechanism
+
+并行工作流需要以下协调机制防止冲突：
+- **Merge Point**：并行轨道在预定节点汇合（如 Core Product + Brand → UI Implementation）
+- **Shared Context**：通过 Agents-Orchestrator 或 MCP Memory Server 维护跨轨道共享上下文
+- **Quality Gate 同步**：所有轨道必须在进入下一阶段前通过质量门控
+
+## Related Concepts
+
+- [[Agent Handoff]]：并行轨道间的交接需要结构化协议，防止上下文丢失
+- [[Quality Gate]]：并行工作流结束后必须通过统一质量门控
+- [[Agents-Orchestrator]]：并行工作流的执行控制器，负责轨道调度和同步
+- [[Memory-Based-Handoff]]：MCP Memory Server 支持并行 Agent 的上下文连续性
diff --git a/wiki/concepts/Partial-Dependence-Plots.md b/wiki/concepts/Partial-Dependence-Plots.md
index edcae144..46db9b9b 100644
--- a/wiki/concepts/Partial-Dependence-Plots.md
+++ b/wiki/concepts/Partial-Dependence-Plots.md
@@ -1,71 +1,73 @@
----
-title: "Partial Dependence Plots"
-type: concept
-tags: [model-interpretability, feature-analysis, model-visualization]
-last_updated: 2026-04-25
----
-
-## Definition
-
-偏依赖图（Partial Dependence Plots，PDP）展示一个或两个特征与模型预测之间的边际关系——在控制其他特征后，该特征取不同值时模型输出的平均预测变化。核心假设：特征之间相对独立（独立PDP），否则需要 ICE 曲线（Individual Conditional Expectation）补充。
-
-## Core Types
-
-### 1D PDP（单特征）
-- 固定其他特征不动，在目标特征的取值范围内计算模型平均预测
-- 可视化：x 轴为特征值，y 轴为偏依赖值（边际预测效应）
-- 用于：验证特征方向是否符合业务预期（单调递增/递减/U形）
-
-### 2D PDP（特征交互）
-- 两个特征同时变化，展示交互效应对预测的联合影响
-- 用于：检测模型学习到的非预期特征交互（如 X₁ × X₂ 的非线性组合）
-
-### ICE Curves（Individual Conditional Expectation）
-- 每条线代表一个样本的偏依赖曲线（而非平均值）
-- 解决 PDP 掩盖个体异质性的问题
-- 与 PDP 结合：PDP 叠加 ICE 曲线，同时展示平均趋势和个体差异
-
-## Usage
-
-```python
-from sklearn.inspection import PartialDependenceDisplay
-
-# 1D PDP for single feature
-fig, ax = plt.subplots(figsize=(8, 5))
-PartialDependenceDisplay.from_estimator(
-    model, X, [feature_name],
-    grid_resolution=50, ax=ax
-)
-ax.set_title(f"Partial Dependence - {feature_name}")
-fig.savefig(f"pdp_{feature_name}.png", dpi=150)
-
-# 2D PDP for feature interaction
-fig, ax = plt.subplots(figsize=(8, 6))
-PartialDependenceDisplay.from_estimator(
-    model, X, [(feat_a, feat_b)], ax=ax
-)
-fig.savefig(f"pdp_interact_{feat_a}_x_{feat_b}.png", dpi=150)
-```
-
-## Model QA 中的应用
-
-Model QA Specialist 使用 PDP 进行以下审计：
-1. **方向性验证**：检查 PDP 曲线方向是否符合业务领域知识（如"收入↑ → 违约概率↓"）
-2. **非单调性检测**：识别模型在某些区间学习到的反直觉非单调关系
-3. **交互效应识别**：2D PDP 检测 top correlated feature pairs 的交互效应
-4. **跨时间稳定性**：对比 Train vs OOT 的 PDP 曲线，识别特征关系的时间漂移
-5. **SHAP 交叉验证**：PDP 验证边际方向，SHAP 验证精确归因，两者互补
-
-## Relationship
-
-- **依赖** [[SHAP]]：SHAP 提供精确特征归因，PDP 提供趋势可视化；PDP 曲线形状与 SHAP beeswarm 的分布吻合
-- **依赖** [[Population-Stability-Index]]：PSI 捕捉特征分布漂移，PDP 捕捉特征效应的变化，两者共同判断模型是否需要重训
-- **支撑** [[Calibration-Testing]]：PDP 揭示的非线性关系可能是校准问题的根源
-- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的特征分析核心工具
-
-## Key Limitations
-
-- **强交互效应**：当特征高度相关时，PDP 可能产生误导性结论（忽略其他特征的条件分布）
-- **异质性掩盖**：个体 ICE 曲线与平均 PDP 的差异反映异质性，忽略可能遗漏关键子群体
-- **分类变量**：需预先分箱，箱的划分方式影响结果解释
-- **高维特征**：超过 2 个特征的交互需用 SHAP interaction values 或 ALE plots
+---
+title: "Partial Dependence Plots"
+type: concept
+tags: [model-interpretability, feature-analysis, model-visualization]
+sources:
+  - specialized-model-qa
+last_updated: 2026-05-29
+---
+
+## Definition
+
+偏依赖图（Partial Dependence Plots，PDP）展示一个或两个特征与模型预测之间的边际关系——在控制其他特征后，该特征取不同值时模型输出的平均预测变化。核心假设：特征之间相对独立（独立PDP），否则需要 ICE 曲线（Individual Conditional Expectation）补充。
+
+## Core Types
+
+### 1D PDP（单特征）
+- 固定其他特征不动，在目标特征的取值范围内计算模型平均预测
+- 可视化：x 轴为特征值，y 轴为偏依赖值（边际预测效应）
+- 用于：验证特征方向是否符合业务预期（单调递增/递减/U形）
+
+### 2D PDP（特征交互）
+- 两个特征同时变化，展示交互效应对预测的联合影响
+- 用于：检测模型学习到的非预期特征交互（如 X₁ × X₂ 的非线性组合）
+
+### ICE Curves（Individual Conditional Expectation）
+- 每条线代表一个样本的偏依赖曲线（而非平均值）
+- 解决 PDP 掩盖个体异质性的问题
+- 与 PDP 结合：PDP 叠加 ICE 曲线，同时展示平均趋势和个体差异
+
+## Usage
+
+```python
+from sklearn.inspection import PartialDependenceDisplay
+
+# 1D PDP for single feature
+fig, ax = plt.subplots(figsize=(8, 5))
+PartialDependenceDisplay.from_estimator(
+    model, X, [feature_name],
+    grid_resolution=50, ax=ax
+)
+ax.set_title(f"Partial Dependence - {feature_name}")
+fig.savefig(f"pdp_{feature_name}.png", dpi=150)
+
+# 2D PDP for feature interaction
+fig, ax = plt.subplots(figsize=(8, 6))
+PartialDependenceDisplay.from_estimator(
+    model, X, [(feat_a, feat_b)], ax=ax
+)
+fig.savefig(f"pdp_interact_{feat_a}_x_{feat_b}.png", dpi=150)
+```
+
+## Model QA 中的应用
+
+Model QA Specialist 使用 PDP 进行以下审计：
+1. **方向性验证**：检查 PDP 曲线方向是否符合业务领域知识（如"收入↑ → 违约概率↓"）
+2. **非单调性检测**：识别模型在某些区间学习到的反直觉非单调关系
+3. **交互效应识别**：2D PDP 检测 top correlated feature pairs 的交互效应
+4. **跨时间稳定性**：对比 Train vs OOT 的 PDP 曲线，识别特征关系的时间漂移
+5. **SHAP 交叉验证**：PDP 验证边际方向，SHAP 验证精确归因，两者互补
+
+## Relationship
+
+- **依赖** [[SHAP]]：SHAP 提供精确特征归因，PDP 提供趋势可视化；PDP 曲线形状与 SHAP beeswarm 的分布吻合
+- **依赖** [[Population-Stability-Index]]：PSI 捕捉特征分布漂移，PDP 捕捉特征效应的变化，两者共同判断模型是否需要重训
+- **支撑** [[Calibration-Testing]]：PDP 揭示的非线性关系可能是校准问题的根源
+- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的特征分析核心工具
+
+## Key Limitations
+
+- **强交互效应**：当特征高度相关时，PDP 可能产生误导性结论（忽略其他特征的条件分布）
+- **异质性掩盖**：个体 ICE 曲线与平均 PDP 的差异反映异质性，忽略可能遗漏关键子群体
+- **分类变量**：需预先分箱，箱的划分方式影响结果解释
+- **高维特征**：超过 2 个特征的交互需用 SHAP interaction values 或 ALE plots
diff --git a/wiki/concepts/PerformanceMax.md b/wiki/concepts/PerformanceMax.md
index 2729bfc6..bd08f57c 100644
--- a/wiki/concepts/PerformanceMax.md
+++ b/wiki/concepts/PerformanceMax.md
@@ -1,35 +1,52 @@
----
-title: "Performance Max"
-type: concept
-tags: ["paid-media", "google-ads", "automation", "ai"]
-last_updated: 2026-04-20
----
-
-## Aliases
-- Performance Max Campaigns
-- PMax
-- Performance Max Ads
-
-## Overview
-Performance Max 是 Google Ads 提供的 AI 驱动的全渠道广告系列类型，自动在 YouTube、Display、Search、Discover、Gmail、Shopping 所有 Google 广告位优化广告投放。是 [[PaidMediaPpcStrategist]] 的核心武器之一。
-
-## How It Works
-- 广告主提供资产（图片/标题/描述/视频/Logo）和预算
-- Google AI 自动组合生成广告，根据实时信号（受众、设备、时间、创意组合）动态优化
-- 支持 Goal-based bidding，自动寻找最有可能达成转化目标的用户
-
-## Key Components
-- **Asset Groups**: 资产组，定义一套完整的创意素材
-- **Audience Signals**: 受众信号，引导 AI 关注的种子受众
-- **Conversion Goals**: 转化目标，定义成功的衡量标准
-
-## PPC Strategist's Perspective
-- Performance Max 是规模化增长的核心工具，适合覆盖增量用户
-- 需要与 Search/Shopping 协同，避免 cannibalization（预算内耗）
-- 资产质量直接决定效果上限
-- 需设置合理的预算和转化价值追踪
-
-## Related Concepts
-- [[SmartBidding]]: Performance Max 依赖 Smart Bidding 作为出价机制
-- [[AccountArchitecture]]: Performance Max 是账户架构中的活动类型之一
-- [[TieredCampaignArchitecture]]: Performance Max 通常与品牌 Search 配合，分层隔离
+---
+title: "Performance Max"
+type: concept
+tags: ["ppc", "google-ads", "ai", "automation", "paid-media"]
+sources: ["paid-media-ppc-strategist"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Performance Max（PMax）是 Google Ads 提供的 AI 驱动的全渠道广告系列类型，通过 Google 的机器学习算法，自动在 Search、Display、YouTube、Gmail、Shopping 所有 Google 广告库存中实时优化广告投放，以最大化预设的转化目标。区别于传统按广告类型创建系列，PMax 将所有渠道整合为一个统一优化的单元。
+
+## How It Works
+
+1. **Asset Group**：上传标题、描述、图片、视频、logo 等创意素材
+2. **Audience Signals**：提供种子受众（Customer Match、In-Market、Affinity）加速学习
+3. **Automatic Optimization**：算法实时决定：哪个渠道、哪个受众、在什么时机展示什么创意
+4. **Cross-Channel Learning**：Search、Display、YouTube 等渠道数据互通，提升整体效果
+
+## Asset Group Design
+
+PMax 的核心输入单元是 Asset Group：
+- **Required Assets**：至少 1 个图片（或 logo）+ 1 个标题 + 1 个描述
+- **Recommended Assets**：2-3 个图片 + 5+ 标题 + 5+ 描述 + 1+ 视频
+- **Ad Strength**：Google 评分，目标是 "Good" 或 "Excellent"
+
+### Asset Group Strategy
+- 按产品线/服务线拆分 Asset Group，避免混杂
+- A/B 测试不同 Asset Group 组合
+- 定期补充新创意，避免疲劳
+
+## Audience Signals
+
+PMax 的"教练"输入，辅助算法更快学习：
+- **Customer Match Lists**：高价值客户数据
+- **In-Market Audiences**：考虑中的购买者
+- **Life Events**：人生阶段事件（毕业/搬家/结婚等）
+- **Demographics**：年龄/收入/家庭状况
+
+## Limitations and Best Practices
+
+| 限制 | 应对策略 |
+|------|---------|
+| 关键词控制有限 | 使用 Search Themes 引导 |
+| 受众控制有限 | 精准的 Audience Signals |
+| 品牌安全依赖算法 | 排除内容排除项设置 |
+| 透明度低 | 结合 Search/Shopping 标准系列监测 |
+
+## Connections
+- [[AutomatedBiddingStrategy]]：PMax 内置 Smart Bidding（Max Conversions / tROAS）
+- [[AudienceStrategy]]：Audience Signals 是 PMax 的关键输入
+- [[GoogleAds]]：PMax 是 Google Ads 独有的广告系列类型
diff --git a/wiki/concepts/PersistentWiki.md b/wiki/concepts/PersistentWiki.md
new file mode 100644
index 00000000..9ae82b22
--- /dev/null
+++ b/wiki/concepts/PersistentWiki.md
@@ -0,0 +1,33 @@
+---
+title: "PersistentWiki"
+type: concept
+tags: [knowledge-management, wiki, llm, persistent]
+sources: [llm-wiki]
+last_updated: 2026-05-02
+---
+
+## Overview
+持久化维基（Persistent Wiki）是 [[LLM Wiki]] 模式的核心产物——一个结构化的、相互链接的 Markdown 文件集合，介于用户与原始数据源之间。知识编译一次后持续保持最新，无需在每次查询时重新推导。
+
+## Core Characteristics
+- **持久化**：知识以结构化页面的形式存储，不随对话结束而消失
+- **可积累**：每添加一个新来源，Wiki 就变得更丰富，而非从头推导
+- **相互链接**：页面之间通过 [[wikilinks]] 链接，形成知识网络
+- **主动维护**：LLM 负责更新摘要、添加标签、标记矛盾，无需人类做"记账式"工作
+
+## Three-Layer Architecture
+持久化维基建立在 [[LLMWikiArchitecture]] 之上：
+1. **Raw Sources**：原始文档（不可变）
+2. **Wiki**：LLM 生成的知识层（持久化维基本身）
+3. **Schema**：配置文件（CLAUDE.md / AGENTS.md）
+
+## Operation Patterns
+- **[[IngestWorkflow]]**：导入工作流——LLM 读取源文件，创建/更新 Wiki 页面
+- **[[QueryWorkflow]]**：查询工作流——用户提问，LLM 搜索 Wiki 并综合答案
+- **[[LintWorkflow]]**：检查工作流——定期健康检查 Wiki
+
+## Relationships
+- [[PersistentWiki]] ← implements ← [[LLMWikiArchitecture]]
+- [[PersistentWiki]] ← competes_with ← [[RAG]]（传统 RAG 每次查询从零推导，持久化维基一次编译持续复用）
+- [[PersistentWiki]] ← inspired_by ← [[Memex]]（Vannevar Bush 1945）
+- [[LLM Wiki]] ← uses ← [[PersistentWiki]]（[[LLM Wiki]] 是完整模式，[[PersistentWiki]] 是其核心产物）
diff --git a/wiki/concepts/Photography-Terminology.md b/wiki/concepts/Photography-Terminology.md
new file mode 100644
index 00000000..4d709797
--- /dev/null
+++ b/wiki/concepts/Photography-Terminology.md
@@ -0,0 +1,77 @@
+---
+title: "Photography Terminology"
+type: concept
+tags: [photography, prompt-engineering, technical]
+last_updated: 2026-05-15
+---
+
+## Definition
+
+专业摄影术语体系——用于在 AI 图像生成提示词中精确描述光线、构图、相机参数和后处理效果，确保 AI 模型准确理解和渲染预期的摄影效果。
+
+## Core Categories
+
+### 光线类（Lighting）
+| 术语 | 含义 | 提示词示例 |
+|------|------|-----------|
+| Rembrandt Lighting | 45°侧光+三角形阴影 | "Rembrandt lighting setup from camera left" |
+| Butterfly Lighting | 鼻子下方蝴蝶形阴影 | "butterfly lighting, subtle shadow under nose" |
+| Split Lighting | 半明半暗分割光 | "dramatic split lighting, 50/50 face division" |
+| Rim Light / Hair Light | 轮廓光/发丝光 | "strong rim light separating from background" |
+| Softbox | 漫射箱光源 | "large softbox overhead creating soft gradient" |
+| Volumetric Lighting | 体积光/光束 | "volumetric golden hour sunbeams through fog" |
+| Chiaroscuro | 明暗对比 | "chiaroscuro dramatic shadow composition" |
+| Bokeh | 焦外虚化 | "creamy f/1.4 bokeh background" |
+
+### 相机与焦距类
+| 术语 | 含义 | 提示词示例 |
+|------|------|-----------|
+| Shallow Depth of Field | 浅景深 | "shallow depth of field, f/1.8, subject sharp" |
+| Deep Focus | 深景深 | "deep focus, f/11, foreground to background sharp" |
+| Wide Angle Distortion | 广角畸变 | "wide angle 16mm lens, slight perspective exaggeration" |
+| Telephoto Compression | 长焦压缩 | "telephoto 200mm, compressed background" |
+| Eye Level | 平视视角 | "shot at eye level, 85mm portrait lens" |
+| Bird's Eye View | 俯视 | "bird's eye view, overhead camera" |
+| Worm's Eye View | 仰视 | "worm's eye angle, dramatic upward perspective" |
+
+### 摄影类型类
+| 术语 | 含义 | 提示词示例 |
+|------|------|-----------|
+| High Key | 高调摄影 | "high key lighting, bright and airy aesthetic" |
+| Low Key | 低调摄影 | "low key, dramatic shadow, moody atmosphere" |
+| Editorial | 编辑摄影 | "editorial fashion photography style" |
+| Documentary | 纪实摄影 | "documentary style, authentic and unretouched" |
+| Fine Art | 艺术摄影 | "fine art photography, gallery exhibition quality" |
+
+### 后处理类
+| 术语 | 含义 | 提示词示例 |
+|------|------|-----------|
+| Color Grading | 色彩调色 | "teal and orange color grade, cinematic" |
+| Film Emulation | 胶片模拟 | "Kodak Portra 400 film stock emulation" |
+| Grain | 颗粒感 | "subtle film grain, 35mm Ilford HP5" |
+| HDR | 高动态范围 | "HDR processing, detailed highlights and shadows" |
+
+## Photography Reference Photographers
+
+| 摄影师 | 风格特征 | 提示词引用 |
+|--------|---------|-----------|
+| Annie Leibovitz | 戏剧性人像、叙事场景 | "Annie Leibovitz inspired editorial portrait" |
+| Peter Lindbergh | 自然光黑白、真实质感 | "Peter Lindbergh natural light black and white" |
+| Helmut Newton | 高对比、时尚张力 | "Helmut Newton dramatic fashion photography" |
+| Irving Penn | 简洁构图、棚拍经典 | "Irving Penn studio minimalist composition" |
+
+## Core Principle
+
+> 使用正确的摄影术语，而非口语化描述——"shallow depth of field, f/1.8 bokeh" 而非 "blurry background"。
+
+## Connections
+
+- [[Five-Layer-Prompt-Structure]] 的技术摄影层（Lamp + Technical Photography Layer）的术语来源
+- [[Midjourney]] / [[Stable-Diffusion]] 等 AI 平台对摄影术语的识别和渲染能力
+- [[Prompt-Engineering]] 的技术精确性基础
+
+## Aliases
+
+- 摄影术语体系
+- Professional Photography Language
+- Technical Photography Specs
diff --git a/wiki/concepts/Pipeline-State-Management.md b/wiki/concepts/Pipeline-State-Management.md
new file mode 100644
index 00000000..f2220d6f
--- /dev/null
+++ b/wiki/concepts/Pipeline-State-Management.md
@@ -0,0 +1,31 @@
+---
+title: "Pipeline-State-Management"
+type: concept
+tags: []
+sources: [agents-orchestrator]
+last_updated: 2026-05-29
+---
+
+## Definition
+**Pipeline State Management**（流水线状态管理）是 [[AgentsOrchestrator]] 在整个开发流程中追踪和维护项目状态的能力——追踪当前任务、所处阶段、完成状态，在 Agent 间传递上下文信息，处理错误并实现恢复。
+
+## Core Responsibilities
+- **Track progress**: Maintain state of current task, phase, and completion status
+- **Context preservation**: Pass relevant information between agents
+- **Error recovery**: Handle agent failures gracefully with retry logic
+- **Documentation**: Record decisions and pipeline progression
+
+## State Tracking Elements
+- Current task and phase
+- Completion status of each task
+- Retry count per task
+- Agent handoff context
+- Quality gate decisions (PASS/FAIL)
+
+## Relationship to Other Concepts
+- Complementary to [[Agent-Handoff]] — provides the state infrastructure that enables smooth agent transitions
+- Enhanced by [[Quality-Gate]] — quality gates update pipeline state
+- Referenced in [[AgentsOrchestrator]] Phase 3 Dev-QA Loop
+
+## Sources
+- [[agents-orchestrator]]
diff --git a/wiki/concepts/Platform-Specific-Optimization.md b/wiki/concepts/Platform-Specific-Optimization.md
new file mode 100644
index 00000000..46637d1b
--- /dev/null
+++ b/wiki/concepts/Platform-Specific-Optimization.md
@@ -0,0 +1,53 @@
+---
+title: "Platform-Specific Optimization"
+type: concept
+tags: [prompt-engineering, ai-image-generation, platform]
+last_updated: 2026-05-15
+---
+
+## Definition
+
+针对不同 AI 图像生成平台（Midjourney、DALL-E、Stable Diffusion、Flux）的特定语法、参数和优化策略，使提示词在各平台上发挥最优效果。
+
+## Platform Comparison
+
+### Midjourney
+- **参数语法**：`--ar`（宽高比）、`--v`（版本）、`--style`（风格）、`--chaos`（随机性）、`--no`（负向）、`--iw`（图像权重）
+- **多提示词加权**：使用 `::` 语法实现 token 级权重控制（如 `cat::1.5 dog::0.8`）
+- **风格引用**：`--style` 参数支持预设风格库
+- **优化要点**：强调氛围和情绪词，依赖参数调控技术细节
+
+### DALL-E
+- **自然语言优化**：支持完整的自然语言描述，无需特殊语法
+- **风格混合**：通过描述性语言融合不同艺术风格
+- **优化要点**：详细描述场景和情感，利用自然语言的灵活性
+
+### Stable Diffusion
+- **Token 加权**：使用括号 `(token)` 和数字权重 `[token:0.5]` 控制 token 强度
+- **Embedding 引用**：通过文本反演（Textual Inversion）引用自定义概念
+- **LoRA 集成**：调用特定风格的 LoRA 适配器增强特定效果
+- **优化要点**：精细化 token 权重管理，结合 Embedding 和 LoRA 实现精准控制
+
+### Flux
+- **详细自然语言**：偏好详细、具体的自然语言描述
+- **写实优先**：对写实摄影风格有天然优势
+- **优化要点**：提供尽可能详细的场景描述，减少抽象暗示
+
+## Cross-Platform Best Practice
+
+1. 核心五层提示词结构在各平台通用
+2. 平台特有参数在提示词末尾添加
+3. 测试不同平台的相同核心描述的输出差异
+4. 建立各平台成功提示词库，持续迭代优化
+
+## Connections
+
+- [[Five-Layer-Prompt-Structure]] 是跨平台的通用框架
+- [[Midjourney]] / [[DALL-E]] / [[Stable-Diffusion]] / [[Flux]] 各自的专属优化
+- [[Prompt-Engineering]] 的平台适配层
+
+## Aliases
+
+- Platform Optimization
+- Multi-Platform Prompt Tuning
+- 平台适配优化
diff --git a/wiki/concepts/Polanyi-Exchange.md b/wiki/concepts/Polanyi-Exchange.md
new file mode 100644
index 00000000..189c8706
--- /dev/null
+++ b/wiki/concepts/Polanyi-Exchange.md
@@ -0,0 +1,26 @@
+---
+title: "Polanyi Exchange"
+type: concept
+tags: ["anthropology", "economy", "exchange", "polanyi", "anthropological-economy"]
+last_updated: 2026-04-25
+---
+
+## Definition
+Polanyi 交换分类——Karl Polanyi 将前工业社会的交换系统分为三种类型：**互惠**（reciprocity）、**再分配**（redistribution）和**市场**（market），三者嵌入不同的社会结构中，非市场经济是常态。
+
+## Core Framework
+- **互惠（Reciprocity）**：对称性群体之间的双向给予和回报（家庭、友谊、礼物经济）
+- **再分配（Redistribution）**：中心集权机构收集资源后统一分配（国家税收/公共服务、部落首领的仓库）
+- **市场（Market）**：供给-需求-价格机制调节交换（Polanyi 认为在 20 世纪之前极少见）
+- **嵌入性（Embeddedness）**：前工业社会中，经济交换嵌入社会关系、宗教义务和政治结构中
+
+## Key Thinkers
+- Karl Polanyi（《大转型》作者，经济人类学奠基人）
+- [[Marcel-Mauss]]（《礼物》对互惠的早期分析）
+- Marshall Sahlins（部落社会的互惠分类）
+
+## Connections
+- [[Anthropologist-Agent]] ← uses_framework ← [[Polanyi-Exchange]]
+- [[Gift-Economy]] ← foundational_for ← [[Polanyi-Exchange]]
+- [[Cultural-Ecology]] ← shapes ← [[Polanyi-Exchange]]
+- [[Functionalism]] ← explains ← [[Polanyi-Exchange]]
diff --git a/wiki/concepts/PolyvagalTheory.md b/wiki/concepts/PolyvagalTheory.md
new file mode 100644
index 00000000..2d1fcd09
--- /dev/null
+++ b/wiki/concepts/PolyvagalTheory.md
@@ -0,0 +1,39 @@
+---
+title: "Polyvagal Theory"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# Polyvagal Theory
+
+## Aliases
+- Polyvagal Theory
+- Porges Polyvagal Theory
+- Vagal Tone Theory
+
+## Definition
+Porges 迷走神经理论——认为迷走神经（副交感神经系统的一部分）是理解创伤反应的生理基础，提出神经觉知（neuroception）概念：神经系统无意识地评估环境安全性。
+
+## Core Concepts
+
+### Neuroception（神经觉知）
+自主神经系统无意识地评估环境威胁/安全，不依赖意识判断。解释了为什么人在客观安全的环境中仍然感到恐惧。
+
+### Three-Level Response Hierarchy（三层反应层级）
+1. **Ventral Vagal（腹侧迷走）**：社会参与系统——安全状态下，与人连接、沟通、调节情绪
+2. **Sympathetic（交感神经系统）**：动员系统——战斗或逃跑应对威胁
+3. **Dorsal Vagal（背侧迷走）**：关闭系统——极端威胁下的僵硬、冻结、解离（"playing dead"）
+
+### Co-Regulation（共同调节）
+安全状态下的社会参与依赖与他人的共同调节（Co-Regulation），解释了安全依恋关系的生理保护作用。
+
+## Application in Character Design
+Psychologist Agent 使用此理论为创伤反应提供**生理基础**而非仅仅是心理描述，帮助设计更真实的角色行为：
+- 过度警觉 = 交感神经持续激活
+- 解离/冻结 = 背侧迷走接管
+- 逐步恢复安全感 = 从背侧→交感→腹侧迷走的递进恢复
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/Population-Stability-Index.md b/wiki/concepts/Population-Stability-Index.md
index 7d8099eb..5f050c5a 100644
--- a/wiki/concepts/Population-Stability-Index.md
+++ b/wiki/concepts/Population-Stability-Index.md
@@ -1,102 +1,104 @@
----
-title: "Population Stability Index"
-type: concept
-tags: [model-monitoring, feature-drift, model-governance]
-last_updated: 2026-04-25
----
-
-## Definition
-
-群体稳定性指数（Population Stability Index，PSI）是衡量两个分布（通常是开发样本 vs 实际样本）之间差异的量化指标，广泛用于监控机器学习模型输入特征和输出评分的分布漂移，是模型生命周期管理的核心监控工具。
-
-## Algorithm
-
-$$\text{PSI} = \sum_{i=1}^{n} (act_i - exp_i) \times \ln\left(\frac{act_i}{exp_i}\right)$$
-
-其中：
-- $act_i$ = 实际（当前）样本在分箱中的占比
-- $exp_i$ = 期望（基准）样本在分箱中的占比
-- 使用 **Laplace smoothing**（加 1 平滑）避免除零
-
-## Interpretation Thresholds
-
-| PSI Range | 判读 | 建议行动 |
-|-----------|------|---------|
-| < 0.10 | 🟢 无显著漂移 | 无需操作 |
-| 0.10–0.25 | 🟡 中等漂移 | 调查原因，密切监控 |
-| ≥ 0.25 | 🔴 显著漂移 | **立即采取行动**，考虑重训 |
-
-## Implementation
-
-```python
-import numpy as np
-import pandas as pd
-
-def compute_psi(expected: pd.Series, actual: pd.Series, bins: int = 10) -> float:
-    """
-    Compute Population Stability Index between two distributions.
-    Interpretation:
-      < 0.10  → No significant shift (green)
-      0.10–0.25 → Moderate shift, investigation recommended (amber)
-      >= 0.25 → Significant shift, action required (red)
-    """
-    breakpoints = np.linspace(0, 100, bins + 1)
-    expected_pcts = np.percentile(expected.dropna(), breakpoints)
-
-    expected_counts = np.histogram(expected, bins=expected_pcts)[0]
-    actual_counts = np.histogram(actual, bins=expected_pcts)[0]
-
-    # Laplace smoothing
-    exp_pct = (expected_counts + 1) / (expected_counts.sum() + bins)
-    act_pct = (actual_counts + 1) / (actual_counts.sum() + bins)
-
-    psi = np.sum((act_pct - exp_pct) * np.log(act_pct / exp_pct))
-    return round(psi, 6)
-
-
-def variable_stability_report(
-    df: pd.DataFrame,
-    date_col: str,
-    variables: list[str],
-    psi_threshold: float = 0.25,
-) -> pd.DataFrame:
-    """Monthly stability report for model features."""
-    periods = sorted(df[date_col].unique())
-    baseline = df[df[date_col] == periods[0]]
-
-    results = []
-    for var in variables:
-        for period in periods[1:]:
-            current = df[df[date_col] == period]
-            psi = compute_psi(baseline[var], current[var])
-            results.append({
-                "variable": var, "period": period, "psi": psi,
-                "flag": "🔴" if psi >= psi_threshold else ("🟡" if psi >= 0.10 else "🟢"),
-            })
-
-    return pd.DataFrame(results).pivot_table(
-        index="variable", columns="period", values="psi"
-    ).round(4)
-```
-
-## Model QA 中的应用
-
-Model QA Specialist 将 PSI 应用于以下场景：
-1. **特征稳定性监控**：每月计算所有特征的 PSI，识别漂移最早的预警信号
-2. **评分分布监控**：模型输出的评分 PSI，检测整体预测分布变化
-3. **分段 PSI**：在子群体上分别计算，识别特定分段的漂移（整体 PSI 掩盖的局部问题）
-4. **重训触发器**：将 PSI ≥ 0.25 设为自动重训的硬触发条件
-
-## Relationship
-
-- **被依赖** [[SHAP]]：PSI 识别分布漂移，SHAP 分析漂移后的特征贡献变化
-- **被依赖** [[Discrimination-Metrics]]：PSI 漂移通常先于 AUC/Gini 下降出现，是预警指标
-- **被依赖** [[Calibration-Testing]]：特征分布漂移（PSI）是校准失效的根本原因之一
-- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的监控框架核心指标
-
-## Key Insights
-
-- **方向性陷阱**：PSI 仅反映分布差异大小，不反映变化方向（高→低 或 低→高 均为漂移）
-- **阈值依赖**：0.1/0.25 阈值是行业惯例，具体阈值应基于业务风险调整
-- **特征 vs 评分 PSI**：特征 PSI 先于评分 PSI 变化，是更敏感的早期预警
-- **监控频率**：生产模型应至少每月计算一次，关键业务模型建议每周甚至每日
+---
+title: "Population Stability Index"
+type: concept
+tags: [model-monitoring, feature-drift, model-governance]
+sources:
+  - specialized-model-qa
+last_updated: 2026-05-29
+---
+
+## Definition
+
+群体稳定性指数（Population Stability Index，PSI）是衡量两个分布（通常是开发样本 vs 实际样本）之间差异的量化指标，广泛用于监控机器学习模型输入特征和输出评分的分布漂移，是模型生命周期管理的核心监控工具。
+
+## Algorithm
+
+$$\text{PSI} = \sum_{i=1}^{n} (act_i - exp_i) \times \ln\left(\frac{act_i}{exp_i}\right)$$
+
+其中：
+- $act_i$ = 实际（当前）样本在分箱中的占比
+- $exp_i$ = 期望（基准）样本在分箱中的占比
+- 使用 **Laplace smoothing**（加 1 平滑）避免除零
+
+## Interpretation Thresholds
+
+| PSI Range | 判读 | 建议行动 |
+|-----------|------|---------|
+| < 0.10 | 🟢 无显著漂移 | 无需操作 |
+| 0.10–0.25 | 🟡 中等漂移 | 调查原因，密切监控 |
+| ≥ 0.25 | 🔴 显著漂移 | **立即采取行动**，考虑重训 |
+
+## Implementation
+
+```python
+import numpy as np
+import pandas as pd
+
+def compute_psi(expected: pd.Series, actual: pd.Series, bins: int = 10) -> float:
+    """
+    Compute Population Stability Index between two distributions.
+    Interpretation:
+      < 0.10  → No significant shift (green)
+      0.10–0.25 → Moderate shift, investigation recommended (amber)
+      >= 0.25 → Significant shift, action required (red)
+    """
+    breakpoints = np.linspace(0, 100, bins + 1)
+    expected_pcts = np.percentile(expected.dropna(), breakpoints)
+
+    expected_counts = np.histogram(expected, bins=expected_pcts)[0]
+    actual_counts = np.histogram(actual, bins=expected_pcts)[0]
+
+    # Laplace smoothing
+    exp_pct = (expected_counts + 1) / (expected_counts.sum() + bins)
+    act_pct = (actual_counts + 1) / (actual_counts.sum() + bins)
+
+    psi = np.sum((act_pct - exp_pct) * np.log(act_pct / exp_pct))
+    return round(psi, 6)
+
+
+def variable_stability_report(
+    df: pd.DataFrame,
+    date_col: str,
+    variables: list[str],
+    psi_threshold: float = 0.25,
+) -> pd.DataFrame:
+    """Monthly stability report for model features."""
+    periods = sorted(df[date_col].unique())
+    baseline = df[df[date_col] == periods[0]]
+
+    results = []
+    for var in variables:
+        for period in periods[1:]:
+            current = df[df[date_col] == period]
+            psi = compute_psi(baseline[var], current[var])
+            results.append({
+                "variable": var, "period": period, "psi": psi,
+                "flag": "🔴" if psi >= psi_threshold else ("🟡" if psi >= 0.10 else "🟢"),
+            })
+
+    return pd.DataFrame(results).pivot_table(
+        index="variable", columns="period", values="psi"
+    ).round(4)
+```
+
+## Model QA 中的应用
+
+Model QA Specialist 将 PSI 应用于以下场景：
+1. **特征稳定性监控**：每月计算所有特征的 PSI，识别漂移最早的预警信号
+2. **评分分布监控**：模型输出的评分 PSI，检测整体预测分布变化
+3. **分段 PSI**：在子群体上分别计算，识别特定分段的漂移（整体 PSI 掩盖的局部问题）
+4. **重训触发器**：将 PSI ≥ 0.25 设为自动重训的硬触发条件
+
+## Relationship
+
+- **被依赖** [[SHAP]]：PSI 识别分布漂移，SHAP 分析漂移后的特征贡献变化
+- **被依赖** [[Discrimination-Metrics]]：PSI 漂移通常先于 AUC/Gini 下降出现，是预警指标
+- **被依赖** [[Calibration-Testing]]：特征分布漂移（PSI）是校准失效的根本原因之一
+- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的监控框架核心指标
+
+## Key Insights
+
+- **方向性陷阱**：PSI 仅反映分布差异大小，不反映变化方向（高→低 或 低→高 均为漂移）
+- **阈值依赖**：0.1/0.25 阈值是行业惯例，具体阈值应基于业务风险调整
+- **特征 vs 评分 PSI**：特征 PSI 先于评分 PSI 变化，是更敏感的早期预警
+- **监控频率**：生产模型应至少每月计算一次，关键业务模型建议每周甚至每日
diff --git a/wiki/concepts/Portage-Salarial.md b/wiki/concepts/Portage-Salarial.md
index b305e7c2..5f27d4fe 100644
--- a/wiki/concepts/Portage-Salarial.md
+++ b/wiki/concepts/Portage-Salarial.md
@@ -1,72 +1,95 @@
----
-title: "Portage Salarial"
-type: concept
-tags: [france, freelancing, employment, social-protection]
-sources: [specialized-french-consulting-market]
-last_updated: 2026-04-25
----
-
-## Definition
-
-Portage Salarial 是法国特有的**劳动合同外包机制**——独立顾问（consultant）与一家 Portage 公司签署劳动合同，Portage 公司再以服务合同向客户企业开具发票。顾问名义上保持雇员身份，享受社会保险，但实质上**承担全部商业风险**（自寻客户、自定费率、无工作保障）。
-
-## Key Characteristics
-
-- **法律框架**：劳动合同（CDI/CDD）+ 服务合同（Convention de Portage）
-- **Portage 公司收费**：管理费 5-10%（按营业额计算）
-- **社保缴费结构**：
-  - 雇主缴费（Charges Patronales）：约 45%（含养老金、健康保险、失业保险等）
-  - 雇员缴费（Charges Salariales）：约 22%
-  - 合计约 67% 的 TJM 毛收入用于社保缴费
-
-## Cost Breakdown Example
-
-以 700€/天 TJM 计算：
-
-```
-TJM Brut:           700 €/天
-每月（18天）:       12,600 €/月
-Portage 管理费(10%): -1,260 €/月
-雇主社保(45%):      -5,103 €/月
-雇员社保(22%):      -2,495 €/月
-                          ─────────────
-税前净收入:           3,742 €/月
-实际日净费率:           208 €/天
-```
-
-对比 Micro-Entrepreneur（同为 700€/天）：
-
-```
-税前净收入:           9,828 €/月
-实际日净费率:           546 €/天
-```
-
-**差距：338€/天**——这是社保保护（ARE 失业保险、退休金补充、Mutuelle 医疗保险）的价格。
-
-## What Portage Provides
-
-| 权益 | Portage | Micro-Entrepreneur |
-|------|---------|-------------------|
-| 失业保险（ARE） | ✅ | ❌ |
-| 退休金补充 | ✅ | ❌ |
-| Mutuelle 医疗保险 | ✅（公司部分） | ❌ |
-| 病假/产假 | ✅ | ❌ |
-| 商业风险自担 | ✅ | ✅ |
-
-## Key Principles
-
-1. **Portage ≠ 就业**：本质上是"披着雇员外衣的自由职业"，永远不要将 Portage 合同呈现为 CDI 等价物
-2. **平台选择**：Portage 公司间管理费和服务质量差异很大，需比较（APE、Winference等主流供应商）
-3. **单一客户依赖风险**：URSSAF 规定单一客户占总收入 >70% 触发审计风险
-4. **定价公开性**：若通过 collective.work 等平台接单，费率可能对平台可见
-
-## Contradictions
-
-- 与 [[Micro-Entrepreneur]]：Portage 净得率低（~50%）但提供完整社保；Micro 净得率高（~70%）但无社保保护
-- **市场误解**：许多新从业者认为 Portage"更安全"——实际上顾问承担全部商业风险（客户拒付、项目取消），只是法律上被认定为雇员
-
-## Aliases
-- Portage
-- Portage Salarial
-- Société de Portage
-- Entreprise de Portage Salarial
+---
+title: "Portage Salarial"
+type: concept
+tags: []
+sources: [specialized-french-consulting-market]
+last_updated: 2026-04-25
+---
+
+# Portage Salarial
+
+## Aliases
+- Portage Salarial
+- Portage
+- Portage Company
+- Société de Portage
+
+## Definition
+
+Portage Salarial（薪资代理）是法国特有的劳动法律框架，允许独立专业人士通过一家"portage 公司"作为中间人与客户签订合同，本质上是一种合法的雇佣代理机制。Portage 公司以雇主身份代为签订合同、收取客户付款、发放工资，同时为自由职业者提供完整的社会保障（失业保险、退休金、健康险）。
+
+## How It Works
+
+```
+Client → [Portage Company] → Freelancer
+         (employer)         (employee)
+```
+
+1. 自由职业者与客户（ESN 或最终客户）就服务内容达成一致
+2. Portage 公司与客户签订服务合同
+3. 客户向 Portage 公司付款
+4. Portage 公司扣除管理费（约 5-10%）和法定雇主/雇员社保后，将剩余款项作为工资发放给自由职业者
+
+## Cost Breakdown
+
+以 **700 EUR/天 TJM** 为例（每月 18 个工作日 = 12,600 EUR/月）：
+
+| 费用项 | 比例 | 金额 |
+|-------|------|------|
+| Portage 公司管理费 | ~10% | -1,260 EUR |
+| 雇主端社保（约 45%） | | -5,103 EUR |
+| 雇员端社保（约 22%） | | -2,495 EUR |
+| **净收入（月）** | | **~3,742 EUR** |
+| **有效日均净收入** | | **~208 EUR/天** |
+
+> 对比 Micro-Entreprise 同等 TJM：净收入 ~9,828 EUR/月，有效日均 ~546 EUR/天
+> **差距：338 EUR/天** = Portage Salarial 为社会保护付出的代价
+
+## Key Benefits
+
+| 权益 | 说明 |
+|------|------|
+| **失业保险（ARE）** | 失业后可申请法国失业金（需满足缴纳条件） |
+| **退休金** | 完整缴纳法国退休金体系（含基础退休金+补充退休金） |
+| **健康险（Mutuelle）** | 通常由 Portage 公司提供团体健康险 |
+| **病假/产假** | 享有法定病假和产假权益 |
+| **法律保护** | 作为"雇员"身份，在合同纠纷中有更好的法律地位 |
+| **简化行政** | 无需注册公司、报税、处理复杂账单 |
+
+## Key Risks
+
+| 风险 | 说明 |
+|------|------|
+| **高额社保负担** | 实际到手约 50% TJM，显著低于 Micro-Entreprise 的 70% |
+| **商业风险自担** | Portage 不是真正的雇主——自由职业者自揽客户、自定费率 |
+| **费率天花板** | 某些 Portage 公司对可转嫁费用有限制 |
+| **合同类型限制** | 通常需要真实的"服务关系"而非"从属性雇佣" |
+
+> "Portage salarial is not employment. It provides social protection but the freelancer bears all commercial risk. Never present it as equivalent to a CDI."
+
+## Portage vs Alternatives
+
+| 维度 | Portage Salarial | Micro-Entreprise | SASU/EURL |
+|------|----------------|-----------------|-----------|
+| 净收入比例 | ~50% TJM | ~70% TJM | ~55-65% TJM |
+| 失业保险 | ✅ 有 | ❌ 无 | ❌ 无（EURL 特定条件下有） |
+| 退休金 | ✅ 完整缴纳 | ⚠️ 简化缴纳 | ✅ 完整缴纳 |
+| 行政复杂度 | 低 | 极低 | 中 |
+| 最佳适用 | 需要 ARE 保障的转型期顾问 | 低成本启动/低风险项目 | 高收入稳定期 |
+
+## Decision Framework
+
+**选择 Portage Salarial 当：**
+- 需要法国失业保险作为安全网
+- 处于从 CDI 向自由职业的转型期
+- 年收入预期较高（> 80,000 EUR）且 ARE 积累价值显著
+- 需要完整的退休金缴纳记录
+
+**选择 Micro-Entreprise 当：**
+- 风险承受能力高，不需要失业保险
+- 年收入低于法国 Auto-Entrepreneur 免税门槛（77,700 EUR服务业）
+- 短期项目或试用期
+
+## Related Sources
+- [[specialized-french-consulting-market]]
+- [[Micro-Entreprise]]
diff --git a/wiki/concepts/Practice-Theory.md b/wiki/concepts/Practice-Theory.md
new file mode 100644
index 00000000..5b8f6bad
--- /dev/null
+++ b/wiki/concepts/Practice-Theory.md
@@ -0,0 +1,24 @@
+---
+title: "Practice Theory"
+type: concept
+tags: ["anthropology", "sociology", "practice", "habitus", "bourdieu"]
+last_updated: 2026-04-25
+---
+
+## Definition
+实践理论——文化不是静态的符号系统，而是通过**日常实践**不断被再生产和变革的动态过程。行动者在社会结构约束下以惯习（habitus）为中介创造文化，文化同时又塑造未来的社会结构。
+
+## Core Framework
+- **惯习（Habitus）**：行动者在社会化过程中内化的性情倾向系统——使社会不平等被自然化为"品味"和"个人选择"
+- **文化资本（Cultural Capital）**：教育、知识、语言能力、品味等非经济形式的社会优势，可转化为经济和社会资本
+- **场域（Field）**：相对自主的社会空间（艺术、宗教、学术等），具有自身逻辑和竞争规则
+
+## Key Thinkers
+- [[Pierre-Bourdieu]]（核心提出者）
+- Anthony Giddens（structuration theory）
+- Sherry Ortner（subaltern counterpoint）
+
+## Connections
+- [[Anthropologist-Agent]] ← uses_framework ← [[Practice-Theory]]
+- [[Structuralism]] ← challenges ← [[Practice-Theory]]
+- [[Functionalism]] ← critiques_and_extends ← [[Practice-Theory]]
diff --git a/wiki/concepts/PrematureAbstraction.md b/wiki/concepts/PrematureAbstraction.md
new file mode 100644
index 00000000..a8da1446
--- /dev/null
+++ b/wiki/concepts/PrematureAbstraction.md
@@ -0,0 +1,60 @@
+---
+title: "PrematureAbstraction"
+type: concept
+tags: [engineering, code-quality, design]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+过早抽象（PrematureAbstraction）指在实际需要提取抽象之前（通常指第三次出现之前）就引入辅助函数、类或接口的代码设计反模式。这导致引入短期内无法偿还的隐性债务。
+
+## Core Rule
+
+**等待第四次出现再提取。** 前三次重复出现时，保持重复代码而非提取抽象。提取的时机应基于实际的调用次数，而非"直觉上看起来应该提取"。
+
+## Why Wait for the Fourth Time
+
+- **第一次**：孤例，可能是一次性的特殊处理
+- **第二次**：可能是巧合，模式尚不清晰
+- **第三次**：确认存在模式，但抽象接口（参数、返回值、边界情况）尚未完全明确
+- **第四次**：抽象接口足够清晰，且维护收益开始超过抽象本身的成本
+
+## Examples
+
+### ❌ 过早抽象（第二次就提取）
+
+```typescript
+// 第二次出现就开始提取
+const dryRun = args.includes('--dry-run');
+if (dryRun) logDryRun(records);
+
+// 马上为第三次出现提取
+export function runWithMode(mode: RunMode, records: Record[]) {
+  // strategy pattern introduced too early
+}
+```
+
+### ✅ 延迟抽象（第四次才提取）
+
+```typescript
+// 保持三次重复
+if (dryRun) logDryRun(records);
+if (dryRun) logDryRun(items);
+if (dryRun) logDryRun(entries);
+
+// 第四次出现——抽象接口完全清晰了
+export function runDry(records: Record[]) {
+  return { dry: true, count: records.length };
+}
+```
+
+## Connections
+
+- [[engineering-minimal-change-engineer]]：最小变更工程师的核心原则之一
+- [[ScopeCreep]]：过早抽象通常是范围蔓延的表现形式
+- [[MinimalChangePrinciple]]：最小变更原则的延伸——保持重复代码直到收益明确
+
+## Sources
+
+- [[engineering-minimal-change-engineer]]
diff --git a/wiki/concepts/Presentism.md b/wiki/concepts/Presentism.md
new file mode 100644
index 00000000..07599e5d
--- /dev/null
+++ b/wiki/concepts/Presentism.md
@@ -0,0 +1,36 @@
+---
+title: "Presentism"
+type: concept
+tags: [historiography, methodology, ethics]
+sources: [academic-historian]
+last_updated: 2026-04-30
+---
+
+## Definition
+当代主义（Presentism）是一种历史思维中的方法论错误，指以当代的道德标准、价值观和概念框架去评判过去的历史人物和事件，而不承认或不理解历史情境与当代的差异。Historian Agent 将其作为核心方法论警示，要求在历史评估中保持"情境理解"。
+
+## Key Features
+- **定义**：用现代人的道德眼镜审视历史，而非将历史人物置于其时代背景中理解
+- **经典案例**：
+  - 用现代"民族国家"概念评判前现代政体
+  - 用现代"个人权利"观念评价中世纪社会结构
+  - 用现代"平等"标准否定历史上缺乏民主的社会
+- **Historian Agent 的立场**：
+  - **避免极端**：不因情境化而开脱历史暴行（"不以现代标准评判，但也不为暴行开脱"）
+  - **双重意识**：承认历史条件限制，同时保持道德评价的可能性
+- **与之对立的概念**：
+  - 历史主义（Historicism）：强调理解历史情境
+  - 道德相对主义（Moral Relativism）：以情境为由完全否定道德评价
+
+## Relationship to Other Concepts
+- [[academic-historian]] ← 核心警示 ← [[Presentism]]：文档"🚨 Critical Rules"明确规定，是 Historian Agent 五步工作流的认识论前提
+- [[Historiography]] ← 属于 ← [[Presentism]]：Presentism 是历史编纂学中一个重要的认识论问题
+- [[Counterfactual-Analysis]] ← 关联 ← [[Presentism]]：反事实推理可以帮助理解历史偶然性，避免"历史必然"的当代偏见
+
+## Relationship to Source Pages
+- [[academic-historian]]：文档"🚨 Critical Rules"节明确列出"避免 presentism"
+
+## Aliases
+- 当代主义
+- 当代投射谬误
+- Anachronistic Judgment
diff --git a/wiki/concepts/ProceduralContentGeneration.md b/wiki/concepts/ProceduralContentGeneration.md
new file mode 100644
index 00000000..e1f717fa
--- /dev/null
+++ b/wiki/concepts/ProceduralContentGeneration.md
@@ -0,0 +1,53 @@
+---
+title: "ProceduralContentGeneration"
+type: concept
+tags: ["unreal-engine", "procedural", "environment", "pcg"]
+sources: ["unreal-technical-artist", "unreal-world-builder"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- PCG
+- Procedural Content Generation
+- UE5 PCG
+- Procedural Foliage Tool
+
+## Definition
+PCG（Procedural Content Generation，程序化内容生成）是 UE5 中通过图形化节点系统自动生成大规模环境资产（植被、岩石、碎片等）的系统。通过采样表面、随机化和几何约束，在运行时或预烘焙模式下批量放置资产。
+
+## PCG vs Foliage Tool 选型原则
+| 场景 | 工具选择 |
+|------|---------|
+| 手绘英雄资产放置 | Foliage Tool（传统） |
+| 大规模植被（1000+ 实例） | PCG + Nanite 预烘焙 |
+| Runtime 生成（小区域 < 1km²） | PCG Runtime |
+| 大面积开放世界（> 1km²） | PCG 预烘焙（流式兼容） |
+
+## PCG Graph 标准结构（以 Forest Population 为例）
+1. **Surface Sampler**：在 World Partition 表面采样点
+2. **Attribute Filter**：按 biome mask 密度纹理过滤
+3. **Exclusion**：道路（8m buffer）、路径（4m）、水体（2m）、建筑（15m sphere）
+4. **Poisson Disk Distribution**：最小间距防止聚集
+5. **Randomization**：旋转（Yaw 0-360°）和缩放（0.85-1.25x）
+6. **Weighted Mesh Assignment**：按权重分配网格类型（如 40% Oak, 30% Pine, 20% Birch）
+7. **Culling**：Nanite 资产 cull 80,000cm，非 Nanite cull 30,000cm
+
+## PCG Exposed Parameters（设计师调优旋钮）
+- `GlobalDensityMultiplier`: 0.0–2.0
+- `MinForestSeparation`: 1.0–8.0m
+- `RoadExclusionEnabled`: bool
+
+## Performance Constraints
+- 所有 PCG 放置资产应在条件允许时启用 Nanite
+- 大面积（> 1km²）使用预烘焙输出以兼容流式加载
+- Runtime PCG 仅限小区域，生成须在 3 秒内完成
+
+## Connections
+- [[UnrealWorldBuilder]] ← 植被放置 ← ProceduralContentGeneration
+- [[UnrealEngine5]] ← 运行环境 ← ProceduralContentGeneration
+- [[Nanite]] ← 几何支持 ← ProceduralContentGeneration
+- [[WorldPartition]] ← 空间管理 ← ProceduralContentGeneration
+
+## Sources
+- [[unreal-technical-artist]]
+- [[unreal-world-builder]]
diff --git a/wiki/concepts/Product-Requirements-Document.md b/wiki/concepts/Product-Requirements-Document.md
new file mode 100644
index 00000000..ecc6efbe
--- /dev/null
+++ b/wiki/concepts/Product-Requirements-Document.md
@@ -0,0 +1,36 @@
+---
+title: "Product Requirements Document (PRD)"
+type: concept
+tags: ["product-management", "documentation", "prd"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- PRD
+- Product Requirements Document
+
+## Definition
+Product Requirements Document（产品需求文档）—— 结构化的需求定义文档，在产品经理开始设计方案之前，以用户证据和商业逻辑为支撑，明确描述要解决的问题以及成功衡量标准。
+
+## Core Components
+1. **问题陈述**（Problem Statement）：用户痛点或商业机会的具体描述，包含证据（用户访谈、行为数据、客服工单、竞争信号）
+2. **目标与成功指标**（Goals & Success Metrics）：表格化列出目标、指标、当前基线、目标值和测量窗口
+3. **非目标**（Non-Goals）：明确本迭代不会解决的问题，防止范围蔓延
+4. **用户画像与故事**（User Personas & Stories）：核心用户画像 + 带验收标准的用户故事
+5. **解决方案概述**（Solution Overview）：2-4段叙事描述，包含关键设计决策
+6. **技术考量**（Technical Considerations）：依赖、已知风险、开放问题
+7. **发布计划**（Launch Plan）：阶段表（内部Alpha → 封闭Beta → GA），回滚标准
+8. **附录**（Appendix）：用户研究记录、竞品分析、设计稿链接等
+
+## Key Principles
+- **先写新闻稿，再写 PRD** —— 一段式新闻稿说不清楚用户为什么在乎，则还没准备好写需求或开始设计
+- **协作编写，不是孤立产出** —— 工程师和设计师应从一开始就参与文档编写
+- **所有指标都必须可测量** —— 定性描述不能成为验收标准
+
+## Usage
+由 [[Product Manager Agent]] 主导产出，是产品团队、工程师、设计师、营销和销售之间的共享语言和共识载体。
+
+## Related
+- [[RICE Prioritization Score]] — PRD 中优先级排序使用的量化框架
+- [[Opportunity Assessment]] — PRD 之前的早期机会评估文档
+- [[Go-to-Market (GTM) Brief]] — PRD 之后的发布执行计划
diff --git a/wiki/concepts/Programmatic-Buying.md b/wiki/concepts/Programmatic-Buying.md
new file mode 100644
index 00000000..875cbc4e
--- /dev/null
+++ b/wiki/concepts/Programmatic-Buying.md
@@ -0,0 +1,44 @@
+---
+title: "Programmatic Buying"
+type: concept
+tags: ["programmatic", "dsp", "display", "paid-media"]
+sources: ["paid-media-programmatic-buyer"]
+last_updated: 2026-04-26
+---
+
+## Definition
+
+程序化购买（Programmatic Buying）是通过需求方平台（DSP）自动化完成数字广告展示库存的购买、竞价和投放的技术驱动型广告采购方法。区别于传统人工谈判和预订式购买，程序化购买利用实时竞价（RTB）和预设算法规则，在毫秒级完成广告曝光机会的评估与竞价。
+
+## Core Components
+
+- **DSP（Demand-Side Platform）**：需求方平台，广告主/代理商用来自动化购买广告库存的接口
+- **SSP（Supply-Side Platform）**：供应方平台，发布商用来出售广告库存
+- **Ad Exchange**：连接 DSP 与 SSP 的公开或私有交易市场
+- **Deal ID**：预先协议的交易 ID，允许广告主以固定价格预订优质库存
+- **PMP（Private Marketplace）**：私有市场，比公开竞价更具排他性和品牌安全性
+- **Programmatic Guaranteed**：程序化保证交易，固定价格、固定量保证
+
+## Types of Programmatic Buying
+
+| 类型 | 说明 | 品牌安全性 |
+|------|------|-----------|
+| Open Exchange | 公开实时竞价 | 低 |
+| PMP | 私有市场邀请竞价 | 中 |
+| Programmatic Guaranteed | 固定价格保证量 | 高 |
+
+## Key Metrics
+
+- **CPM（Cost Per Mille）**：每千次展示成本
+- **Viewability Rate**：可见展示率（目标 ≥70% MRC 标准）
+- **Invalid Traffic Rate**：无效流量率（目标 <3%）
+- **Win Rate**：竞价成功率
+
+## Related Concepts
+- [[ABM Display]]
+- [[Viewability]]
+- [[Frequency Cap]]
+- [[Supply Path Optimization]]
+
+## Sources
+- [[paid-media-programmatic-buyer]]
diff --git a/wiki/concepts/Project-Management-Project-Shepherd.md b/wiki/concepts/Project-Management-Project-Shepherd.md
new file mode 100644
index 00000000..23ce40d9
--- /dev/null
+++ b/wiki/concepts/Project-Management-Project-Shepherd.md
@@ -0,0 +1,69 @@
+---
+title: "Project Shepherd"
+type: concept
+tags: ["project-management", "agency-agents"]
+last_updated: 2026-05-06
+---
+
+## Definition
+
+Project Shepherd 是 The Agency 项目管理体系中的**跨职能项目协调与利益相关方对齐专家 Agent**，专注于将复杂跨职能项目的混乱协调为按时、按范围交付的规范化流程。
+
+## Aliases
+- Project Shepherd Agent
+- Project-Management-Project-Shepherd
+
+## Core Responsibilities
+
+1. **跨职能项目编排**：规划并执行涉及多团队和多部门的大型项目，制定综合时间线并进行依赖关系映射和关键路径分析
+2. **利益相关方对齐**：制定全面的利益相关方沟通策略，跨团队促进协作与冲突解决，在所有项目参与者中维护对齐
+3. **风险缓解**：识别并评估项目风险，制定全面的缓解计划，90% 的已识别风险在影响项目结果前被成功化解
+4. **质量交付保证**：为所有交付物建立质量门控和验收标准，监控项目健康状态并主动实施纠正措施
+
+## Key Methodologies
+
+### 四阶段工作流
+1. 项目启动与规划
+2. 团队组建与 Kickoff
+3. 执行协调与监控
+4. 质量保证与交付
+
+### 关键交付物
+- **Project Charter**：包含问题陈述、项目目标、范围、成功标准、利益相关方分析、沟通计划、资源需求和风险评估
+- **Project Status Report**：绿/黄/红健康状态报告，包含执行摘要、进度更新、问题与风险、利益相关方行动
+
+### 沟通原则
+- 透明报告（即使传递坏消息）
+- 聚焦解决方案（上报即带推荐方案）
+- 绝不承诺不切实际的时间线
+
+## Success Metrics
+- 95% 项目按时在批准预算内交付
+- 利益相关方满意度 4.5/5
+- 范围蔓延 < 10%
+- 90% 已识别风险成功缓解
+
+## Relationship with Other Agents
+
+| Agent | 关系 | 说明 |
+|-------|------|------|
+| [[ProjectManagerSenior]] | 协同 | Senior PM 产出详细任务列表，Project Shepherd 负责多团队协调执行 |
+| [[Project-Management-Jira-Workflow-Steward]] | 协同 | Jira 工作流编排确保任务追踪与可见性 |
+| [[Project-Management-Studio-Operations]] | 协同 | Studio Operations 提供运营支撑 |
+| [[Project-Management-Experiment-Tracker]] | 支持 | 利用实验数据支持项目看护决策 |
+
+## Position in Agency Hierarchy
+
+属 Agency 项目管理体系中的**跨团队交付协调层级**：
+
+```
+Studio Producer（战略层）
+    ↓
+Senior PM（执行层任务分解）
+    ↓
+Project Shepherd（跨团队交付）
+    ↓
+Jira Workflow Steward（流程治理）
+    ↓
+Experiment Tracker（实验跟踪）
+```
diff --git a/wiki/concepts/Proof-Project-Strategy.md b/wiki/concepts/Proof-Project-Strategy.md
new file mode 100644
index 00000000..871aaaad
--- /dev/null
+++ b/wiki/concepts/Proof-Project-Strategy.md
@@ -0,0 +1,88 @@
+---
+title: "Proof-Project-Strategy"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-05-30
+---
+
+## 基本信息
+- **原文**：Proof Project（证明项目）
+- **中文**：先导项目 / 概念验证项目
+- **英文**：Proof of Concept / POC / Scoping Project
+- **韩国语境**：낮은 리스크 소규모 계약
+
+## 定义
+Proof Project 策略是 Korean Business Navigator 提出的核心市场进入方法：当与新客户关系尚未建立信任时，通过一个有明确边界的小型付费项目来证明自身能力，用结果而非说服来推动完整的长期合作。
+
+## 核心原则
+
+> **"The proof project IS the sales pitch. Over-deliver deliberately."**
+> （证明项目本身就是销售话术。刻意超额交付。）
+
+韩国客户不信任陌生供应商的口头承诺，但他们相信自己的眼睛。当他们在内部传阅你精心制作的交付物时，销售就已经完成了。
+
+## 标准规格
+
+| 维度 | 建议值 |
+|------|--------|
+| 时长 | 2-3 周 |
+| 交付物 | 具体、可内部传阅、演示文稿级 |
+| 价格 | 固定报价（相当于 2,000-3,000 EUR） |
+| 框架 | "相互评估"：看我们是否合拍 |
+
+### 报价框架
+不要这样说：
+> "这是我们的标准价格..."
+
+这样说：
+> "我们建议先做一个小的试点项目，用2-3周时间交付XXX。我们认为这对我们双方都是了解对方工作方式的最好方式。您觉得怎么样？"
+
+## 五步执行流程
+
+1. **提案有边界的 engagement** — 2-3 周、特定交付物、固定价格
+2. **框架为 mutual evaluation** — "让我们看看我们的工作风格是否合拍" 降低感知承诺风险
+3. **刻意超额交付 120%** — 韩国 Proof Project 就是销售演示，要做得超出预期
+4. **永远不要在 Proof Project 期间讨论完整 engagement 的价格** — 等他们看到结果后主动询问
+5. **文档化一切** — 韩国利益相关者会在内部传阅你的交付物，做成演示级质量
+
+## 为什么对韩国市场特别重要
+
+| 传统销售方法 | 在韩国的问题 |
+|-------------|-------------|
+| 大量说服和 Pitch | 韩国人不信任陌生人的口头承诺 |
+| 尽快推进到合同 | 품의流程需要 6-16 周，强行加速破坏信任 |
+| 强调资质和证书 | 韩国更看重实际交付和口碑 |
+| 一次性大合同提案 | 感知风险高，内部审批难 |
+
+**Proof Project 降低了三个维度的感知风险：**
+- **财务风险**：小金额，不影响年度预算
+- **技术风险**：特定领域，不涉及核心业务
+- **关系风险**："评估期"让双方都有退路
+
+## Proof Project 信号分析
+
+### 成功信号（应推进完整合同讨论）
+- 联系人主动在内部传阅交付物
+- 被邀请参加第二阶段的회식
+- 联系人主动问你："那么，如果我们做完整项目呢？"
+- 其他部门的人被邀请旁听交付
+
+### 失败信号（不要强推）
+- 联系人仅以"谢谢"回应，无后续跟进问题
+- 交付物未被引用或传阅
+- 联系人在会议中明显心不在焉
+- 没有被邀请参加任何非正式交流
+
+## 与西方 POC 的区别
+
+| 维度 | 西方 POC | 韩国 Proof Project |
+|------|---------|-------------------|
+| 目标 | 验证技术可行性 | 建立信任和人际关系 |
+| 成功标准 | 技术指标达成 | 联系人是否主动推荐 |
+| 后续 | 直接进入合同 | 需要在회식中确认关系深度 |
+| 时间 | 1-4 周 | 2-3 周（不应太快） |
+| 价格 | 可以很低甚至免费 | 必须收费（免费=无价值） |
+
+## 来源
+- [[specialized-korean-business-navigator]] — Proof Project Strategy 完整说明
diff --git a/wiki/concepts/ProppMorphology.md b/wiki/concepts/ProppMorphology.md
new file mode 100644
index 00000000..44e622d3
--- /dev/null
+++ b/wiki/concepts/ProppMorphology.md
@@ -0,0 +1,63 @@
+---
+title: "Propp's Morphology"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Propp's Morphology
+- Propp's Narrative Functions
+- Morphology of the Folktale
+- Propp 功能分析
+- 普罗普形态学
+
+## Overview
+Propp's Morphology（[[Vladimir Propp]] 的叙事形态学）是对民间故事结构的系统性形式化分析。通过对俄罗斯民间故事的归纳，Propp 发现尽管故事角色和情境各异，但其 **31 种叙事功能（Functions）** 按固定顺序在故事中出现。
+
+## The 31 Functions
+按出现顺序（部分关键功能）：
+1. **Absentation**：家庭成员离开
+2. **Interdiction**：禁止/警告
+3. **Violation**：禁止被打破
+4. **Villainy/Lack**：对手作恶或英雄缺乏某物
+5. **Departure**：英雄出发
+6. **Donation**：供者给予魔法物品
+7. **Test**：英雄被测试
+8. **Reaction**：英雄应对测试
+9. **Receipt of Magic Agent**：英雄获得魔法物品
+10. **Guidance**：被送往目标
+11. **Struggle**：与反派斗争
+12. **Branding/Spongification**：英雄被标记或变形
+13. **Victory**：反派被击败
+14. **Return**：英雄归来
+15. **Pursuit/Chase**：被追赶
+16. **Rescue**：获救
+17. **Unrecognized Arrival**：英雄以伪装到达
+18. **False Hero Claim**：假英雄声称功劳
+19. **Difficult Task**：设置难题
+20. **Solution**：难题被解决
+21. **Recognition**：英雄被认出
+22. **Exposure**：假英雄/反派被揭露
+23. **Transfiguration**：英雄获新外貌
+24. **Punishment**：反派被惩罚
+25. **Wedding**：英雄与公主结婚/获得奖赏
+
+## 7 Character Types
+| Type | Role |
+|------|------|
+| Hero | 追求目标的人 |
+| Donor | 提供魔法物品或信息 |
+| Helper | 协助英雄 |
+| Princess | 被解救/奖励 |
+| Princess's Father | 国王/权威 |
+| Villain | 反派/对立力量 |
+| False Hero | 冒名顶替者 |
+
+## Application
+[[Academic Narratologist]] 使用此框架分析童话、quest 类游戏和冒险叙事的结构模式。
+
+## Relationship to Other Concepts
+- [[HeroesJourney]]：Propp 是 Hero's Journey 的学术前身，两者有重叠（Departure, Test, Victory, Return）
+- [[Three-Act-Structure]]：功能序列可以映射到三幕（Setup → Confrontation → Resolution）
diff --git a/wiki/concepts/PsychodynamicDefenseMechanisms.md b/wiki/concepts/PsychodynamicDefenseMechanisms.md
new file mode 100644
index 00000000..088c62e4
--- /dev/null
+++ b/wiki/concepts/PsychodynamicDefenseMechanisms.md
@@ -0,0 +1,46 @@
+---
+title: "Psychodynamic Defense Mechanisms"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# Psychodynamic Defense Mechanisms
+
+## Aliases
+- Defense Mechanisms
+- Vaillant's Defense Mechanism Hierarchy
+- Ego Defense Mechanisms
+
+## Definition
+Vaillant 防御机制层级——个体在应对焦虑和压力时无意识使用的心理策略，按成熟度从低到高排列。
+
+## Vaillant's Hierarchy of Defense Mechanisms
+
+### Level 1: Pathological（病理性）
+- **Denial**（否认）：拒绝承认现实
+- **Projection**（投射）：把自己的感受归于他人
+- **Acting Out**（行为过度表达）：通过行为而非语言表达无意识冲动
+
+### Level 2: Immature（不成熟）
+- **Fantasy**（幻想）：通过白日梦逃避现实
+- **Passive Aggression**（被动攻击）：通过拖延/沉默表达敌意
+- **Dissociation**（解离）：切断自我感知的连续性
+
+### Level 3: Neurotic（神经症性）
+- **Intellectualization**（理智化）：用理性分析代替情感体验
+- **Rationalization**（合理化）：为不合理行为找合理解释
+- **Reaction Formation**（反向形成）：感受与行为相反
+
+### Level 4: Mature（成熟）
+- **Humor**（幽默）：用幽默化解痛苦
+- **Altruism**（利他）：通过帮助他人获得满足感
+- **Sublimation**（升华）：将冲动转化为社会认可的活动
+- **Suppression**（压抑）：有意识地延迟处理不适情绪
+
+## Application in Character Design
+Psychologist Agent 在评估角色时，标注**Primary（主要）**和**Under Stress（压力下）**两个层级的防御机制，后者体现为退行到更低层级。
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/Qualitative-Quantitative-Research.md b/wiki/concepts/Qualitative-Quantitative-Research.md
new file mode 100644
index 00000000..c2be868e
--- /dev/null
+++ b/wiki/concepts/Qualitative-Quantitative-Research.md
@@ -0,0 +1,31 @@
+---
+title: "Qualitative-Quantitative Research"
+type: concept
+tags: [ux, research, qualitative, quantitative, mixed-methods]
+sources: [design-ux-researcher.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+定性定量混合研究方法——定性研究（访谈/观察/开放式问卷）用于探索性理解用户为什么这么想、这么做；定量研究（结构化问卷/A/B测试/行为分析）用于验证假设并获得统计显著性结论。两者互补，是 UX Researcher Agent 默认采用的研究策略。
+
+## Comparison
+
+| 维度 | 定性研究 | 定量研究 |
+|------|---------|---------|
+| 数据形式 | 文字/语言/观察笔记 | 数字/百分比/统计数据 |
+| 样本量 | 小（5-20人） | 大（100+人） |
+| 结论类型 | 深度理解/洞察 | 统计显著性/可推广性 |
+| 适用问题 | "为什么" | "有多少/多大程度" |
+| 方法示例 | 深度访谈、可用性测试、焦点小组 | 结构化问卷、A/B测试、行为数据分析 |
+
+## Relationship to Other Concepts
+
+- [[User-Research-Methodology]]：混合方法是研究方法论的核心组成部分
+- [[Research-Triangulation]]：定性+定量本身就是三角验证的一种形式
+- [[Behavioral-Analytics]]：定量研究在数字产品中的具体应用
+
+## Source
+
+- [[design-ux-researcher.md]] — UX Researcher Agent Personality
diff --git a/wiki/concepts/Quality-Gate.md b/wiki/concepts/Quality-Gate.md
index f46fea15..59fa3d52 100644
--- a/wiki/concepts/Quality-Gate.md
+++ b/wiki/concepts/Quality-Gate.md
@@ -1,27 +1,46 @@
 ---
-title: "Quality Gate"
+title: "Quality Gate Checklist"
 type: concept
-sources: [workflow-startup-mvp]
-last_updated: 2026-04-25
+tags: [quality, gate, process, NEXUS]
+last_updated: 2026-05-01
 ---
 
 ## Definition
-Quality Gate（质量门控）是在关键里程碑设置的质量评估检查点，由 [[Reality Checker]] 评估产出是否满足继续推进的条件，防止有缺陷的代码或计划进入下一阶段。
 
-## Details
-- **典型位置**：
-  1. Week 2 中点——评估是否能在剩余 2 周内完成
-  2. Week 4 发布前——评估生产就绪状态（GO/NO-GO）
-- **评估维度**：时间可行性、功能裁剪建议、技术债务风险
-- **决策结果**：GO（可继续）或 NO-GO（需回滚修复）
+Quality Gate（质量门控）是 NEXUS 多 Agent 框架中每个阶段（Phase）结束时必须通过的强制性质量检查站。在证据提交前，任何后续阶段不得启动。
+
+## 核心机制
+
+- **[[Dual Sign-Off]]**：必须由两类 Gate Keeper **同时**批准，方可放行进入下一阶段
+  - **战略 Gate**（Studio Producer）：验证产出是否符合业务目标和投资回报预期
+  - **技术 Gate**（Reality Checker）：验证产出是否具备可部署到生产环境的技术质量
+- **[[Evidence Over Claims]]**：Gate Keeper 不接受口头断言，只接受截图、测试结果、日志等可验证证据
+
+## Phase 1 Quality Gate Checklist（7项）
+
+| # | 检查项 | 证据来源 | 验证方法 |
+|---|--------|---------|---------|
+| 1 | 架构覆盖 100% 规范需求 | Senior PM 任务列表与架构交叉引用 | 需求→架构映射检查 |
+| 2 | 品牌系统完整（Logo/颜色/字体/声音） | Brand Guardian 交付物 | 交付物完整性审核 |
+| 3 | 所有技术组件均有实现路径 | Backend Architect + UX Architect 规格 | 路径可行性评审 |
+| 4 | 预算审批且在约束范围内 | Finance Tracker 计划 | 预算对比分析 |
+| 5 | Sprint 计划基于速度估算且现实 | Sprint Prioritizer backlog | 速度基准验证 |
+| 6 | 安全架构已定义 | Backend Architect 安全规格 | 安全设计审查 |
+| 7 | 合规要求已映射到技术决策 | Legal 需求映射到架构 | 合规性检查 |
+
+## 决策类型
+
+| 决策 | 条件 | 后续动作 |
+|------|------|---------|
+| **APPROVED** | Dual Sign-Off 均通过 | 进入下一 Phase |
+| **REVISE** | 部分检查项未通过 | 返回对应 Step 修复，2天内重审 |
+| **RESTRUCTURE** | 基础架构存在根本性问题 | 重启本 Phase |
+
+## 与 Dev-QA Loop 的关系
+
+Quality Gate 是**阶段间**的纵向质量门控；Dev-QA Loop 是**阶段内**的横向质量循环。两者独立运行，不可互相替代。
 
 ## Aliases
-- Quality Gate
-- 质量门控
-
-## Related Patterns
-- [[Reality Checker]]（具体执行角色）
-- [[Sequential Handoff]]
-
-## Sources
-- [[workflow-startup-mvp]]
+- Phase Gate
+- Quality Gate Checklist
+- NEXUS Quality Gate
diff --git a/wiki/concepts/Quality-Metrics.md b/wiki/concepts/Quality-Metrics.md
new file mode 100644
index 00000000..5ca8e5f8
--- /dev/null
+++ b/wiki/concepts/Quality-Metrics.md
@@ -0,0 +1,40 @@
+---
+title: "Quality Metrics"
+type: concept
+tags: [testing, quality, metrics]
+sources: [testing-test-results-analyzer]
+last_updated: 2026-04-28
+---
+
+## Aliases
+- Software Quality Metrics
+- Quality Indicators
+- Defect Density
+- Test Effectiveness Metrics
+
+## Definition
+
+软件质量量化指标体系——通过可测量的数值指标评估软件质量状态、跟踪质量趋势并指导质量改进决策。
+
+## Core Metrics
+
+| 指标 | 计算方式 | 阈值参考 |
+|------|---------|---------|
+| 缺陷密度 (Defect Density) | 缺陷数 / 代码行数 (KLOC) | 行业平均 1-5/KLOC |
+| 测试覆盖率 (Test Coverage) | 已测代码行 / 总代码行 | 目标 ≥80% |
+| 测试通过率 (Pass Rate) | 通过用例数 / 总用例数 | 目标 ≥95% |
+| 缺陷逃逸率 (Defect Escape Rate) | 生产缺陷数 / 总缺陷数 | 越低越好 |
+| 平均修复时间 (MTTR) | 总修复时间 / 缺陷数 | 越短越好 |
+
+## Key Methods
+
+- **DRE (Defect Removal Efficiency)**：在发布前移除的缺陷占总缺陷的比例，DRE 越高发布质量越好。
+- **Reliability Growth Modeling**：使用模型（如 Goel-Okumoto）预测缺陷发现趋势。
+- **Quality Trend Analysis**：跨版本跟踪核心指标，识别质量恶化或改善趋势。
+
+## Connections
+
+- [[Test-Coverage-Analysis]]：覆盖率是质量指标体系的核心组成部分。
+- [[Release-Readiness-Assessment]]：多维度质量指标综合决定发布就绪度。
+- [[Defect-Prediction]]：缺陷预测模型基于历史质量指标训练。
+- [[Statistical-Analysis]]：所有指标计算必须附带置信区间。
diff --git a/wiki/concepts/Quality-ROI-Analysis.md b/wiki/concepts/Quality-ROI-Analysis.md
new file mode 100644
index 00000000..32ca8376
--- /dev/null
+++ b/wiki/concepts/Quality-ROI-Analysis.md
@@ -0,0 +1,52 @@
+---
+title: "Quality ROI Analysis"
+type: concept
+tags: [quality, business-value, roi]
+sources: [testing-test-results-analyzer]
+last_updated: 2026-04-28
+---
+
+## Aliases
+- Quality Investment Return
+- Cost of Quality
+- Quality Value Analysis
+
+## Definition
+
+质量投资回报分析——量化质量改进投入的成本与收益，通过财务指标指导质量投资决策，证明质量投资的商业价值。
+
+## Framework (from TestResultsAnalyzer)
+
+### Quality Investment Cost Components
+
+| 成本类型 | 说明 | 示例 |
+|---------|------|------|
+| 预防成本 | 预防缺陷发生的投入 | 自动化测试、代码审查工具 |
+| 检测成本 | 发现现有缺陷的投入 | 测试基础设施、CI/CD |
+| 内部失败成本 | 发布前修复缺陷的成本 | Bug 修复工时 |
+| 外部失败成本 | 生产环境缺陷的成本 | 客户投诉、数据泄露、声誉损失 |
+
+### ROI Formula
+
+```
+Quality ROI = (预防的失败成本 - 质量投入成本) / 质量投入成本 × 100%
+```
+
+### Key Insight
+
+> "Quality investment of $50K prevents estimated $300K in production defect costs" — TestResultsAnalyzer Agent
+
+即：每投入 $1 在质量改进上，可避免约 $6 的生产缺陷损失。
+
+## Key Methods
+
+- **Cost of Poor Quality (COPQ)**：量化低质量造成的全部成本。
+- **Defect Prevention Value**：估算通过早期检测避免的生产缺陷成本。
+- **Quality Investment Prioritization**：按 ROI 高低排序质量改进项目。
+
+## Connections
+
+- [[Quality-Metrics]]：ROI 分析依赖质量指标的实际数据。
+- [[Statistical-Analysis]]：成本估算和置信区间需要统计方法。
+- [[Release-Readiness-Assessment]]：质量债务是发布就绪度的重要考量。
+- [[Defect-Prediction]]：预测的缺陷高发区域是优先质量投资目标。
diff --git a/wiki/concepts/QualityGate.md b/wiki/concepts/QualityGate.md
new file mode 100644
index 00000000..e899eab4
--- /dev/null
+++ b/wiki/concepts/QualityGate.md
@@ -0,0 +1,27 @@
+---
+title: "Quality Gate"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Quality Gates
+- 质量门控
+
+## Definition
+在关键里程碑节点设置的强制性审查机制——只有满足预设标准，才能进入下一阶段。
+
+## Mechanism
+- **触发时机**：中期（第2周）、发布前（第4周）
+- **审查内容**：可行性评估、范围裁剪建议、技术债务风险
+- **决策输出**：GO / NO-GO + 证据要求
+
+## Key Examples
+- [[workflow-startup-mvp]]：Reality Checker 在第 2 周和第 4 周各设一次 Quality Gate
+- [[testing-reality-checker]]：测试阶段 Reality Checker 评估生产就绪状态
+
+## Related Concepts
+- [[Sequential Handoff]] — 交接是 Gate 之间的连接机制
+- [[Reality Checker]] — Quality Gate 的执行 Agent
diff --git a/wiki/concepts/QueryPlanAnalysis.md b/wiki/concepts/QueryPlanAnalysis.md
new file mode 100644
index 00000000..6cfa2e45
--- /dev/null
+++ b/wiki/concepts/QueryPlanAnalysis.md
@@ -0,0 +1,46 @@
+---
+title: "Query Plan Analysis"
+type: concept
+tags: [database, postgresql, explain, performance, query-optimization]
+last_updated: 2026-05-01
+---
+
+# Query Plan Analysis
+
+## Definition
+
+查询计划分析是通过 `EXPLAIN ANALYZE` 命令解读数据库优化器生成的查询执行计划，识别性能瓶颈（如 Seq Scan 全表扫描、估算偏差大）并针对性优化的方法。
+
+## Key Scan Types
+
+| 扫描类型 | 评估 | 说明 |
+|---------|------|------|
+| **Seq Scan** | ⚠️ 差 | 全表扫描，通常意味着缺索引 |
+| **Index Scan** | ✅ 好 | 索引扫描，直接定位数据 |
+| **Bitmap Heap Scan** | 🟡 可接受 | 先索引定位再堆查，适合中等结果集 |
+| **Index Only Scan** | ✅ 最佳 | 完全在索引中完成，无需回表 |
+
+## What to Look For
+
+- **actual time vs estimated rows**：与估算差异大说明统计信息过时
+- **cost=... loops=...**：高 cost 或多次 loops 需优化
+- **Buffers: shared hit/read**：大量 read 说明缓存未命中
+- **Seq Scan on large tables**：大表全表扫描通常是问题信号
+
+## Example
+
+```sql
+EXPLAIN ANALYZE
+SELECT * FROM posts WHERE user_id = 123;
+
+-- Good: Index Scan
+-- Bad:  Seq Scan on posts (cost=0.00..1234.56 rows=500 width=...)
+```
+
+## Source
+- [[engineering-database-optimizer]]
+
+## Connections
+- [[IndexingStrategies]] — 根据分析结果创建/调整索引
+- [[N1QueryPrevention]] — EXPLAIN 识别 N+1 查询
+- [[SafeMigrations]] — 迁移前后验证查询性能
diff --git a/wiki/concepts/QueryWorkflow.md b/wiki/concepts/QueryWorkflow.md
new file mode 100644
index 00000000..8bb3499a
--- /dev/null
+++ b/wiki/concepts/QueryWorkflow.md
@@ -0,0 +1,32 @@
+---
+title: "QueryWorkflow"
+type: concept
+tags: [workflow, knowledge-management, llm]
+sources: [llm-wiki]
+last_updated: 2026-05-02
+---
+
+## Overview
+查询工作流（Query Workflow）是 [[PersistentWiki]] 的核心运营模式之一——用户就 Wiki 中的内容提出问题，LLM 搜索相关页面、综合整理答案并以 wikilink 形式引用来源。
+
+## Standard Process（4步）
+1. **读取 Index**：读取 `wiki/index.md`，确定相关页面
+2. **读取相关页面**：读取这些页面的具体内容
+3. **综合生成答案**：以 `[[页面名]]` wikilink 形式内联引用来源
+4. **询问是否归档**：询问用户是否将答案保存为 `wiki/syntheses/<slug>.md`
+
+## Answer Formats
+答案可以呈现不同形式：
+- Markdown 页面
+- 对比表格
+- 幻灯片（Marp）
+- 图表（matplotlib）
+- 画布（Canvas）
+
+## Key Insight
+**好的答案可以归档回 Wiki 作为新页面。** 用户提出的对比、分析、发现的关联——这些都很有价值，不应该消失在聊天记录中。探索结果与摄入来源一样复合积累到知识库中。
+
+## Design Principles
+- **Index-first**：先读索引找相关页面，而非直接全文搜索
+- **引文驱动**：所有答案以 wikilink 形式引用来源页
+- **知识沉淀**：探索结果是第二等重要的知识来源，仅次于摄入的原始来源
diff --git a/wiki/concepts/RAG.md b/wiki/concepts/RAG.md
index 52ba11ff..528c3427 100644
--- a/wiki/concepts/RAG.md
+++ b/wiki/concepts/RAG.md
@@ -1,26 +1,37 @@
 ---
 title: "RAG"
 type: concept
-tags: [rag, retrieval, llm, knowledge]
-aliases: [RAG, Retrieval-Augmented Generation, 检索增强生成]
-last_updated: 2025-12-20
+tags: [AI, knowledge-base, retrieval]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki, 大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏, llms-rag-ai-agent三个到底什么区别]
+last_updated: 2026-04-20
 ---
 
-## Definition
-Retrieval-Augmented Generation（RAG），检索增强生成，通过从外部知识库检索相关信息来增强大语言模型的回答质量，解决模型在陌生领域的幻觉（Hallucination）问题。
+## Aliases
+- Retrieval-Augmented Generation
+- 检索增强生成
 
-## Key Facts
-- 大模型在陌生领域容易产生幻觉，"一本正经胡说八道"
-- RAG 通过给模型"一些提示"，引导其在正确方向上回答
-- 效果案例：正确率从 60% 提升至 90%
-- RAG 依赖 [[Embedding]] 技术实现语义检索
-- 典型 RAG 流程：用户问题 → 检索外部知识 → 将检索结果注入 Prompt → LLM 生成回答
+## Definition
+Retrieval-Augmented Generation（RAG，检索增强生成）——一种通过外部文档检索消除大模型幻觉、提升回答准确性的技术方案。用户上传文档后，AI 在回答时实时检索相关片段并拼接入答案。典型应用：NotebookLM、ChatGPT 文件上传。
+
+## Key Properties
+- 每次查询从零检索，无持久化积累
+- 综合多文档时，需要"现场找碎片、现场拼"
+- RAG 通过"给提示"解决大模型在陌生领域的幻觉问题
+- 正确率可从 60% 提升至 90%（[[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]）
+
+## Limitations
+- **没有积累**：每次提问 AI 都在从头搜寻知识，什么都没沉淀
+- **维护成本高**：需要持续维护文档库，但 AI 不会自动更新交叉引用
+- Karpathy 指出：人类放弃 Wiki 是因为**维护成本的增长速度超过了价值的增长速度**
+
+## Contrast: RAG vs LLM Wiki
+| 维度 | RAG | [[LLM Wiki]] |
+|------|-----|--------------|
+| 知识状态 | 每次查询从零 | 持久化积累 |
+| 交叉引用 | 无 | 自动维护 |
+| 多文档综合 | 临时拼接 | 预编译 |
+| 维护者 | 人类 | AI（趋近于零成本）|
 
 ## Connections
-- [[Embedding]] ← 依赖 ← [[RAG]]
-- [[Hallucination]] ← 解决 ← [[RAG]]
-- [[Large Language Model]] ← 增强 ← [[RAG]]
-- [[LangChain]] ← 支持 ← [[RAG]]
-
-## Sources
-- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]
+- [[LLM Wiki]] ← 对比/替代 ← RAG
+- [[RAG]] ← 基础概念 → [[LLM Wiki]]
diff --git a/wiki/concepts/RICE-Prioritization-Score.md b/wiki/concepts/RICE-Prioritization-Score.md
new file mode 100644
index 00000000..433b2393
--- /dev/null
+++ b/wiki/concepts/RICE-Prioritization-Score.md
@@ -0,0 +1,43 @@
+---
+title: "RICE Prioritization Score"
+type: concept
+tags: ["product-management", "prioritization", "decision-making"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- RICE
+- RICE Score
+- RICE Framework
+
+## Definition
+RICE 优先级评分框架 —— 一个量化的四因子需求优先级评估模型，通过公式 `(R × I × C) ÷ E` 计算综合得分，以数据支撑优先级排序决策。
+
+## Formula
+
+| 因子 | 名称 | 定义 | 典型单位/范围 |
+|------|------|------|--------------|
+| **R** | Reach（触达） | 该功能一个季度内能影响多少用户 | 用户数/季度 |
+| **I** | Impact（影响力） | 对单个用户的影响力 | 0.25 / 0.5 / 1 / 2 / 3 |
+| **C** | Confidence（置信度） | 对假设的置信程度 | 百分比（50%–100%） |
+| **E** | Effort（工作量） | 完成所需的人力月数 | 人力月 |
+
+**RICE Score = (R × I × C) ÷ E**
+
+## Decision Threshold
+- 分数越高优先级越高
+- 通常与团队容量（capacity）结合，决定一个季度内可交付的数量
+- 分数需附带置信区间和敏感性分析
+
+## Key Principles
+- **数据 + 判断结合** —— 数字提供框架，最终决策需要产品判断
+- **量化不确定性** —— C 因子显式记录假设的置信程度
+- **努力量化** —— 防止高影响力但无限工作量的小时级陷阱
+
+## Usage
+由 [[Product Manager Agent]] 在 [[Opportunity Assessment]] 文档中使用，也用于 [[Product Roadmap (Now/Next/Later)]] 中的需求排序。
+
+## Related
+- [[Opportunity Assessment]] — RICE 评分的使用文档
+- [[Product Requirements Document (PRD)]] — RICE 排序后进入 PRD 阶段
+- [[Product Roadmap (Now/Next/Later)]] — RICE 排序结果映射到路线图三层
diff --git a/wiki/concepts/RICE-Scoring.md b/wiki/concepts/RICE-Scoring.md
new file mode 100644
index 00000000..76235e88
--- /dev/null
+++ b/wiki/concepts/RICE-Scoring.md
@@ -0,0 +1,46 @@
+---
+title: "RICE Scoring"
+type: concept
+tags: [prioritization, agile, product-management]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+RICE Scoring 是一种四维定量功能优先级排序框架，通过将每个功能的影响力转换为可比较的数值分数，消除团队优先级争论。
+
+## Formula
+
+```
+RICE Score = (Reach × Impact × Confidence) / Effort
+```
+
+| 维度 | 定义 | 常见取值范围 |
+|------|------|-------------|
+| **Reach**（触达） | 该功能在第一个季度内能影响多少用户 | 1–10,000（用户数） |
+| **Impact**（影响） | 该功能对单个用户的影响力 | 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal |
+| **Confidence**（信心） | 对上述估算的信心程度 | 100%=high, 80%=medium, 50%=low |
+| **Effort**（工作量） | 所需人月数（跨整个团队） | 0.5–20（人月） |
+
+## 应用场景
+
+- **[[Phase 1 Strategy]]**：Sprint Prioritizer 使用 RICE 评分对 Phase 1 产出的任务列表进行排序
+- **[[scenario-startup-mvp]]**：Week 1 快速发现阶段使用 RICE 评分 backlog
+- 适用于 Sprint Planning、Product Roadmap 排序、技术债务优先级决策
+
+## 示例
+
+| 功能 | Reach | Impact | Confidence | Effort | RICE Score |
+|------|-------|--------|-----------|-------|------------|
+| 用户注册优化 | 5000 | 2 | 100% | 2 | 5000 |
+| 支付流程简化 | 2000 | 3 | 80% | 4 | 1200 |
+| 暗模式支持 | 3000 | 1 | 50% | 3 | 500 |
+
+## 与 MoSCoW 的关系
+
+RICE 分数高 ≠ Must-Have。MoSCoW 分类（RICE分数 + 战略/合规考量）决定是否纳入当前 Sprint；RICE 仅排序在 MoSCoW Must/Should/Could 中的条目。
+
+## Aliases
+- RICE Model
+- RICE Framework
+- RICE Prioritization
diff --git a/wiki/concepts/RPC.md b/wiki/concepts/RPC.md
new file mode 100644
index 00000000..16c0abc1
--- /dev/null
+++ b/wiki/concepts/RPC.md
@@ -0,0 +1,46 @@
+---
+title: "RPC (Remote Procedure Call)"
+type: concept
+tags: ["unreal-engine", "networking", "client-server"]
+sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- 远程过程调用
+- Server RPC
+- Client RPC
+- NetMulticast
+
+## 定义
+RPC（远程过程调用）是 UE5 中客户端与服务器之间通信的主要机制，允许在一个网络节点上调用另一个节点上的函数。
+
+## 三种 RPC 类型
+
+### Server RPC
+- **方向**: 客户端 → 服务器
+- **用途**: 客户端向服务器发送请求（玩家输入、操作命令）
+- **要求**: 游戏逻辑 RPC 必须包含 `_Validate()` 实现
+- **标记**: `UFUNCTION(Server, Reliable, WithValidation)`
+
+### Client RPC
+- **方向**: 服务器 → 特定客户端（拥有该 Actor 的客户端）
+- **用途**: 服务器向特定客户端发送消息（私有数据、确认消息）
+- **标记**: `UFUNCTION(Client, Reliable)`
+
+### NetMulticast
+- **方向**: 服务器 → 所有相关客户端
+- **用途**: 服务器向所有客户端广播事件（视觉特效、公共事件）
+- **标记**: `UFUNCTION(NetMulticast, Unreliable)`
+
+## 可靠性
+- **Reliable**: 保证按序到达，但增加带宽
+- **Unreliable**: 尽力发送，可能丢失或乱序
+
+## 安全规范
+每个 Server RPC 必须实现 `_Validate()` 函数，拒绝非法输入。缺少验证 = 作弊漏洞。
+
+## 相关概念
+- [[Server-Authoritative Model]] — RPC 的使用背景
+- [[Actor Replication]] — 与 RPC 配合的状态同步机制
+- [[Network Prediction]] — RPC 与客户端预测的协同
diff --git a/wiki/concepts/Reality-Checker.md b/wiki/concepts/Reality-Checker.md
new file mode 100644
index 00000000..cd8c1807
--- /dev/null
+++ b/wiki/concepts/Reality-Checker.md
@@ -0,0 +1,41 @@
+---
+title: "Reality Checker"
+type: concept
+tags: [multi-agent, quality, testing, nexus]
+sources: [executive-brief, quickstart, workflow-startup-mvp, nexus-spatial-discovery]
+last_updated: 2026-05-01
+aliases:
+  - Quality Authority
+  - Final Quality Gate
+---
+
+## Definition
+
+Reality Checker（Reality Checker Agent）—— NEXUS 多 Agent 编排框架的最终质量权威，以默认"NEEDS WORK"的质疑姿态，对所有交付物进行证据驱动的严格验证。
+
+## Core Principle
+
+**默认"NEEDS WORK"姿态** —— Reality Checker 不会默认相信任何自我声明的质量评估，必须看到可验证的证据才认可交付物通过。
+
+这直接针对多 Agent 系统中的"幻想型审批"问题：Agent 在无证明的情况下给基础实现评 A+，导致质量虚高而缺陷埋入生产。
+
+## Verification Criteria
+
+Reality Checker 执行的验证包括：
+- **截图证据**：关键功能必须有运行截图或录屏
+- **测试结果**：自动化测试必须通过，覆盖率必须达标
+- **性能数据**：性能指标必须满足量化标准
+- **可访问性报告**：WCAG 合规报告或其他无障碍验证结果
+
+## Role in NEXUS
+
+Reality Checker 是 NEXUS 流水线的最后一道质量门控，位于 Phase 4 Hardening → Phase 5 Launch 之间：
+- 所有 Agent 的自我质量声明都必须经过 Reality Checker 验证
+- Reality Checker 的判定是进入生产发布的最终决策依据
+- Reality Checker 保持独立，不受上游 Agent 自我评估的影响
+
+## Related Concepts
+
+- [[Quality Gate]]：Reality Checker 是最终质量门控的执行者
+- [[Evidence Over Claims]]：Reality Checker 的验证标准——要求截图/测试结果/数据，而非口头断言
+- [[Dev↔QA Loop]]：Reality Checker 位于 Dev↔QA 循环之后，是双重质量保障的最终关卡
diff --git a/wiki/concepts/ReentrancyGuard.md b/wiki/concepts/ReentrancyGuard.md
new file mode 100644
index 00000000..17cc8850
--- /dev/null
+++ b/wiki/concepts/ReentrancyGuard.md
@@ -0,0 +1,39 @@
+---
+title: "ReentrancyGuard"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+ReentrancyGuard 是 OpenZeppelin 提供的修饰器（modifier），通过在函数入口设置 mutex 锁，防止合约函数在执行过程中被递归调用（re-entrancy），从而避免重入攻击。
+
+## Implementation
+```solidity
+import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
+
+contract Vault is ReentrancyGuard {
+    function withdraw() external nonReentrant {
+        // ...
+        msg.sender.call{value: amount}("");
+        // 递归调用此函数会被 revert
+    }
+}
+```
+
+## Limitations
+- **不是万能药**：ReentrancyGuard 防止同一合约被递归调用，但不防止**跨合约**重入（跨合约重入需配合 ChecksEffectsInteractions 原则）
+- **Gas 成本**：每次 nonReentrant 检查约消耗 200 gas
+- **OpenZeppelin v5 改进**：v5 版本优化了检查逻辑，降低了 gas 成本
+
+## 与 ChecksEffectsInteractions 的关系
+两者互补：
+- ChecksEffectsInteractions 是**设计原则**——正确顺序的结构化思维
+- ReentrancyGuard 是**工程手段**——即使违反 CEI 也能防止单合约重入
+
+最佳实践：**同时使用两者**，Guard 作为最后防线，CEI 作为代码结构规范。
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
+- [[The-DAO]]
+- [[OpenZeppelin]]
diff --git a/wiki/concepts/Register-Switching.md b/wiki/concepts/Register-Switching.md
new file mode 100644
index 00000000..70152f9e
--- /dev/null
+++ b/wiki/concepts/Register-Switching.md
@@ -0,0 +1,43 @@
+---
+title: "Register Switching"
+type: concept
+tags: ["spanish", "linguistics", "translation", "formality", "tú", "usted", "vosotros"]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+**Register Switching**（语域切换）指西班牙语中正式（usted）与非正式（tú/vos/vosotros）人称代词之间的选择与切换。语域选择决定说话者被视为朋友还是陌生人，错误选择可导致冒犯或误解。
+
+## Spanish Register System
+
+| 代词 | 语域 | 使用场景 |
+|---|---|---|
+| **usted** | 正式（第二人称敬语） | 陌生人、服务业、正式场合、尊重长辈 |
+| **tú** | 非正式（第二人称） | 朋友、熟人、年轻人之间 |
+| **vos** | 非正式（阿根廷/乌拉圭等） | Rioplatense 西班牙语区域 |
+| **vosotros** | 非正式复数（仅西班牙） | 西班牙国内非正式复数对话 |
+
+## Key Rules
+
+1. **陌生人默认 usted**：在墨西哥和大多数拉美国家，陌生人默认用 usted
+2. **本地人先切换才跟随**：如果对方先用 tú，你才可以用 tú 回应；访客不应主动使用 tú
+3. **服务业标准**：餐厅、出租车、商店——默认 usted
+4. **阿根廷例外**：阿根廷广泛使用 vos，正式场合才用 usted
+
+## Cultural Nuance
+
+- 墨西哥：usted 是默认礼貌形式，即使在年轻人之间也逐渐转向 tú
+- 哥伦比亚（波哥大）：某些地区即使亲密朋友间也保留 usted
+- 西班牙：vosotros 替代 ustedes 用于非正式复数
+- 加勒比：语速快，可能模糊 usted/tú 的边界
+
+## In Translation
+
+[[Language Translator]] Agent 必须：
+- 每条翻译标注语域（正式/非正式/中性）
+- 告知用户何时切换语域
+- 提供同一短语的不同语域版本
+
+## Sources
+- [[language-translator]]
diff --git a/wiki/concepts/Relationship-Lifecycle.md b/wiki/concepts/Relationship-Lifecycle.md
new file mode 100644
index 00000000..fbb27346
--- /dev/null
+++ b/wiki/concepts/Relationship-Lifecycle.md
@@ -0,0 +1,126 @@
+---
+title: "Relationship-Lifecycle"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-05-30
+---
+
+## 基本信息
+- **原文**：관계 수명주기
+- **中文**：商业关系生命周期
+- **英文**：Business Relationship Lifecycle
+- **韩国商业语境**：소개 → 신뢰 → 계약
+
+## 定义
+Relationship-Lifecycle 是 Korean Business Navigator 提出的韩国商业关系发展模型，将外国专业人员与韩国客户的关系分为三个阶段：**소개（介绍）** → **신뢰（信任）** → **계약（合同）**。每个阶段有完全不同的沟通策略、时机预期和成功标准。
+
+## 三阶段模型
+
+```
+소개（介绍）
+    ↓ [关系建立信号出现]
+미팅（会议）
+    ↓ [多次接触后]
+신뢰（信任）
+    ↓ [信任巩固后]
+계약（合同）
+```
+
+## 第一阶段：소개（介绍）
+
+### 特征
+- 关系刚建立，双方都在评估对方
+- 对方持谨慎观望态度
+- 核心问题："这个人可靠吗？"
+- **永远不要在第一阶段提价格**
+
+### 关键行动
+| 行动 | 正确做法 |
+|------|---------|
+| 首次接触 | 通过介绍人接入（冷接触响应率 < 5%）|
+| 第一印象 | 专业但不咄咄逼人，展示行业知识而非推销 |
+| 沟通渠道 | Email 或正式 KakaoTalk 消息，不用电话 |
+| 跟进频率 | 每 1-2 周一次，不要过于频繁 |
+| 定价讨论 | 绝对不可以在第一阶段提出具体数字 |
+
+### 成功信号
+- 对方愿意进行第二或第三次会议
+- 被邀请参加小型非正式场合（咖啡）
+- 联系人主动介绍你给团队其他成员
+
+## 第二阶段：신뢰（信任）
+
+### 特征
+- 双方已建立基本信任
+- 联系人愿意分享更多内部信息
+- 核心问题："这个人的能力如何？"
+- 可以讨论具体方案，但价格仍需谨慎
+
+### 关键行动
+| 行动 | 正确做法 |
+|------|---------|
+| 沟通渠道 | KakaoTalk 成为主要渠道 |
+| 会议风格 | 更随意，更少正式 Presentation |
+| 材料 | 提供内部可传阅的专业材料（案例、参考）|
+| 价格讨论 | 可以给出参考范围，不给具体数字 |
+| Proof Project | 进入信任阶段后是最佳提案时机 |
+
+### 成功信号
+- 被邀请参加회식
+- 联系人私下（非工作时间）联系你
+- 联系人开始用名字称呼你（或邀请你直呼其名）
+- 联系人主动询问你的能力和方法论
+
+## 第三阶段：계약（合同）
+
+### 特征
+- 信任已建立，进入正式商业讨论
+- 품의流程正式启动
+- 核心问题："内部审批能否通过？"
+- 可以直接讨论价格和合同条款
+
+### 关键行动
+| 行动 | 正确做法 |
+|------|---------|
+| 心态 | 从说服转向支持——帮助联系人内部推进 |
+| 材料 | 提供联系人可用于内部品의的材料 |
+| 跟进 | 适度（每周一次 SME，每月一次 财阀）|
+| 价格 | 给出具体数字 |
+| 催单 | 绝对不可以——帮助联系人在内部做 case |
+
+### 合同失败信号
+- 品의沉默超过 2 周且无"상부에서 검토 중입니다"信号
+- 联系人不主动更新进度（可能已有问题）
+- 회식中对方态度变冷
+
+## 季节性维护（关系跨越假期）
+
+| 时期 | 动态 | 策略 |
+|------|------|------|
+| 春节（1-2月）| 1-2周停摆，礼品预期 | 节前发送问候，节后联系 |
+| 3-5月 | 新财年，预算新鲜 | 最佳新提案窗口 |
+| 6月 | 略微放缓 | 推动待定决策 |
+| 7-8月 | 暑期轮休 | 关系维护，不硬推 |
+| 中秋（9-10月）| 主要假期，3-5天 | 同春节策略 |
+| 10-11月 | 下年度预算规划期 | 最佳播种期（为次年1月合同）|
+| 12月 | 年末冲刺 | 参加송년회（年末聚会），关系深化 |
+
+## 跨越生命周期失败的常见原因
+1. **第一阶段过早推价格** → 被归类为"vendor"，无信任建立
+2. **第二阶段不参加회식** → 信任无法深化
+3. **第三阶段过度催促** → 联系人在品의中感受到压力，逆向而行
+4. **越级联系** → 关系完全破裂
+
+## 与西方销售漏斗的对比
+
+| 维度 | 西方销售漏斗 | 韩国 Relationship-Lifecycle |
+|------|------------|---------------------------|
+| 核心驱动力 | 效率、速度 | 关系、信任 |
+| 决策者接触 | 尽快接触高层 | 通过层层关系自然渗透 |
+| 时间线 | 2-4 周 | 6-16 周 |
+| 信任建立方式 | 资质/案例/推荐 | 多次接触 + 회식 + Proof Project |
+| "不"的表达 | 直接拒绝 | 沉默或"検討해보겠습니다" |
+
+## 来源
+- [[specialized-korean-business-navigator]] — Workflow Process: Relationship Assessment 章节
diff --git a/wiki/concepts/Release-Readiness-Assessment.md b/wiki/concepts/Release-Readiness-Assessment.md
new file mode 100644
index 00000000..2990578e
--- /dev/null
+++ b/wiki/concepts/Release-Readiness-Assessment.md
@@ -0,0 +1,58 @@
+---
+title: "Release Readiness Assessment"
+type: concept
+tags: [testing, quality, release-management]
+sources: [testing-test-results-analyzer]
+last_updated: 2026-04-28
+---
+
+## Aliases
+- Go/No-Go Decision
+- Release Decision Framework
+- Ship Readiness
+
+## Definition
+
+发布就绪度评估——通过多维度质量指标的量化分析，生成有统计依据的 GO/NO-GO 发布建议，并附带置信度和关键风险说明。
+
+## Readiness Criteria (from TestResultsAnalyzer)
+
+```python
+readiness_criteria = {
+    'test_pass_rate': calculate_pass_rate(),        # 测试通过率
+    'coverage_threshold': check_coverage_threshold(), # 覆盖率达标
+    'performance_sla': validate_performance_sla(), # 性能 SLA
+    'security_compliance': check_security_compliance(), # 安全合规
+    'defect_density': calculate_defect_density(),   # 缺陷密度
+    'risk_score': calculate_overall_risk_score()    # 综合风险评分
+}
+
+# 统计置信度计算
+confidence_level = calculate_confidence_level(readiness_criteria)
+
+# 发布建议
+recommendation = generate_release_recommendation(readiness_criteria, confidence_level)
+```
+
+## Decision Matrix
+
+| 条件 | GO | NO-GO |
+|------|-----|-------|
+| 测试通过率 | ≥95% | <95% |
+| 覆盖率 | ≥80% 行覆盖 | <80% |
+| 性能 SLA | 全部达标 | 任何一项不达标 |
+| 高风险缺陷 | 0 未关闭 | 有未关闭高风险缺陷 |
+| 置信度 | ≥90% | <90% |
+
+## Key Principles
+
+- **Confidence Intervals Required**：所有指标必须附带置信区间，不接受无统计依据的结论。
+- **Risk-Adjusted Decision**：考虑质量债务对未来开发速度的影响。
+- **Trade-off Documentation**：任何放宽条件的决策必须书面记录理由。
+
+## Connections
+
+- [[Quality-Metrics]]：评估依赖多维度质量指标。
+- [[Statistical-Analysis]]：置信度计算基于统计分析方法。
+- [[Quality-Gate]]：发布就绪度评估是质量门控的核心输出。
+- [[Defect-Prediction]]：预测的高风险区域影响就绪度评估。
diff --git a/wiki/concepts/ReplicationGraph.md b/wiki/concepts/ReplicationGraph.md
new file mode 100644
index 00000000..8a0e23f4
--- /dev/null
+++ b/wiki/concepts/ReplicationGraph.md
@@ -0,0 +1,43 @@
+---
+title: "Replication Graph"
+type: concept
+tags: ["unreal-engine", "networking", "optimization"]
+sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Replication Graph
+- 复制图
+- 空间分区复制
+
+## 定义
+Replication Graph 是 UE5 5.3+ 引入的网络复制优化框架，用空间分区替代默认的平面相关性模型，显著降低多人游戏的带宽消耗。
+
+## 默认问题
+默认复制层使用平面列表，每个客户端需要检查所有 Actor 的相关性，大规模世界中效率低下。
+
+## Replication Graph 优化
+### 空间网格划分
+使用 `UReplicationGraphNode_GridSpatialization2D` 将世界划分为网格单元，每个客户端只接收其附近单元内 Actor 的更新。
+
+### 自定义节点
+- `UReplicationGraphNode_GridSpatialization2D` — 开放世界 Actor 复制
+- `UReplicationGraphNode_ActorList` — 低频更新 Actor
+- 自定义节点 — 适配特定游戏需求
+
+## 性能收益
+- 可将带宽降低 **40%**
+- 减少每秒复制的 Actor 数量
+- 按玩家位置动态调整复制范围
+
+## 使用方法
+1. 启用 ReplicationGraph Plugin
+2. 创建自定义 `UGameInstanceReplicationMgr` 子类
+3. 实现 `CreateReplicationGraph()` 返回配置好的 Graph
+4. 在 `.uproject` 文件中添加插件依赖
+
+## 相关概念
+- [[Actor Replication]] — 复制图优化的底层机制
+- [[NetUpdateFrequency]] — 配合频率优化
+- [[Server-Authoritative Model]] — 复制图不影响权威模型
diff --git a/wiki/concepts/Research-Triangulation.md b/wiki/concepts/Research-Triangulation.md
new file mode 100644
index 00000000..7481bf1e
--- /dev/null
+++ b/wiki/concepts/Research-Triangulation.md
@@ -0,0 +1,29 @@
+---
+title: "Research Triangulation"
+type: concept
+tags: [ux, research, triangulation, validation, methodology]
+sources: [design-ux-researcher.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+Research Triangulation（研究三角验证）是通过多种数据源、研究方法、研究者视角或理论框架交叉验证研究结论的方法。其核心目的是降低单一方法或视角带来的偏差，提高研究结论的可信度和可靠性。
+
+## Types of Triangulation
+
+| 类型 | 说明 | 示例 |
+|------|------|------|
+| Data Triangulation | 使用多个数据源 | 访谈数据 + 问卷数据 + 行为数据 |
+| Methodological Triangulation | 使用多种研究方法 | 定量问卷 + 定性访谈 |
+| Investigator Triangulation | 多名研究者独立分析 | 两名研究员分别编码后比对 |
+| Theoretical Triangulation | 使用多种理论框架解释 | 认知心理学 + 社会学视角 |
+
+## Relationship to Other Concepts
+
+- [[User-Research-Methodology]]：三角验证是研究方法论的核心质量保障机制
+- [[Qualitative-Quantitative-Research]]：定性与定量方法的结合是数据三角验证的典型实现
+
+## Source
+
+- [[design-ux-researcher.md]] — UX Researcher Agent Personality
diff --git a/wiki/concepts/Resilience.md b/wiki/concepts/Resilience.md
new file mode 100644
index 00000000..dd3535a3
--- /dev/null
+++ b/wiki/concepts/Resilience.md
@@ -0,0 +1,49 @@
+---
+title: "Resilience"
+type: concept
+tags: [sre, reliability, engineering, fault-tolerance]
+last_updated: 2026-04-20
+---
+
+# Resilience
+
+韧性（Resilience）是系统在面对故障、压力和变化时保持服务可用性的能力。SRE 的核心目标之一就是建立和维持系统韧性。
+
+## Definition
+韧性不仅是"不故障"，而是：
+- **故障吸收**：系统能够吸收和缓解故障的影响
+- **快速恢复**：故障发生后能快速恢复正常服务
+- **适应性学习**：从故障中学习，持续改进
+
+## The 5 Things Resilience Cannot Be Automated
+Uptime Labs 总结了 5 种无法被自动化的韧性要素：
+
+### 1. Learning（学习）
+从故障和Near-miss中提取经验教训，形成组织知识。
+
+### 2. Decision-Making（决策）
+在高压情况下做出正确判断，选择最优响应策略。
+
+### 3. Prioritization（优先级排序）
+在多个问题同时发生时，决定处理顺序。
+
+### 4. Communication（沟通）
+协调团队、通知利益相关者、管理期望。
+
+### 5. Adaptation（适应）
+根据新情况调整策略，不拘泥于预设剧本。
+
+## SRE Practices for Resilience
+- [[BlamelessPostMortem]]：从故障中学习
+- [[Self-Healing]]：自动化恢复机制
+- [[Observability]]：理解系统状态
+- [[Organizational-Second-Hit-Syndrome]]：理解组织层面的韧性
+- [[Chaos-Engineering]]：主动发现弱点
+
+## Relationship to Other Concepts
+- **Reliability** 是韧性的组成部分
+- **Fault Tolerance** 是实现韧性的手段之一
+- **Incident Response** 是韧性响应的执行过程
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/concepts/ResponsesAPI.md b/wiki/concepts/ResponsesAPI.md
new file mode 100644
index 00000000..16b86cac
--- /dev/null
+++ b/wiki/concepts/ResponsesAPI.md
@@ -0,0 +1,28 @@
+---
+title: "ResponsesAPI"
+type: concept
+tags:
+  - "openai"
+  - "api"
+  - "experimental"
+sources: []
+last_updated: 2026-04-20
+---
+
+## Overview
+
+Responses API 是 OpenAI 提供的实验性 API 格式，通过 `POST /v1/responses` 端点调用。相比 Chat Completions，其核心差异在于支持服务端对话状态维持（`previous_response_id`）和结构化事件流。
+
+## Key Features
+
+- **服务端状态**：`previous_response_id` 参数让服务端维护对话历史
+- **结构化事件流**：SSE 事件包含 `text_delta`、`function_call`、`function_call_output` 等标准事件类型
+- **工具调用 UI**：可实现自定义结构化工具调用界面
+
+## Current Limitation
+
+Open WebUI 目前在 Responses 模式下仍然客户端管理对话历史（每次请求发送完整消息列表），尚未充分利用 `previous_response_id`。当前 Responses 模式的主要优势是结构化事件流。
+
+## See Also
+- [[APIServer]]
+- [[ChatCompletions]]
diff --git a/wiki/concepts/Responsive-Breakpoints.md b/wiki/concepts/Responsive-Breakpoints.md
new file mode 100644
index 00000000..a082b7bf
--- /dev/null
+++ b/wiki/concepts/Responsive-Breakpoints.md
@@ -0,0 +1,61 @@
+---
+title: "Responsive Breakpoints"
+type: concept
+tags: [css, responsive, mobile-first, breakpoints]
+sources: [design-ux-architect.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+Responsive Breakpoints 是移动优先的响应式设计断点策略，通过 CSS Media Queries 在不同视口宽度下提供差异化的布局和样式。
+
+## Breakpoint Strategy
+
+- **Mobile First**：基础样式针对 320px+ 设计
+- **Tablet**：768px+ 增强
+- **Desktop**：1024px+ 完整功能
+- **Large**：1280px+ 优化
+
+## Implementation
+
+```css
+/* Base: Mobile (320px+) */
+
+/* Tablet (768px+) */
+@media (min-width: 768px) {
+  .container {
+    max-width: 768px;
+  }
+  .grid-2-col {
+    grid-template-columns: 1fr 1fr;
+  }
+}
+
+/* Desktop (1024px+) */
+@media (min-width: 1024px) {
+  .container {
+    max-width: 1024px;
+  }
+  .grid-2-col {
+    grid-template-columns: 1fr 1fr;
+    gap: var(--space-8);
+  }
+}
+
+/* Large (1280px+) */
+@media (min-width: 1280px) {
+  .container {
+    max-width: 1280px;
+  }
+}
+```
+
+## Related Concepts
+
+- [[Layout-Framework]]：基于断点策略的布局组件系统
+- [[CSS-Design-System]]：提供 spacing token 支持响应式间距
+
+## Sources
+
+- [[design-ux-architect]] — Responsive Breakpoints 的完整定义
diff --git a/wiki/concepts/Review-Management.md b/wiki/concepts/Review-Management.md
new file mode 100644
index 00000000..d203df0e
--- /dev/null
+++ b/wiki/concepts/Review-Management.md
@@ -0,0 +1,63 @@
+---
+title: "Review Management"
+type: concept
+tags: []
+sources:
+  - hospitality-guest-services
+last_updated: 2026-05-02
+---
+
+## Definition
+Review Management（评价管理）是对宾客在 OTA（Expedia/Booking.com/TripAdvisor）及品牌直营渠道留下的点评进行主动监测、及时响应和战略性跟进的系统化管理。核心价值：**在线评分每提高1分，营收可增加高达9%**。
+
+## Post-Stay Follow-Up Sequence（售后跟进序列）
+
+### Day of Checkout — 退房体验
+- 退房时当面询问："您离店前有任何想分享的体验吗？"
+- 如有历史问题未解决："我们之前解决了[问题]，您对解决方案满意吗？"
+
+### 24 Hours After — Survey/Review Request
+- 发送感谢邮件+调查链接
+- 鼓励在满意时发布点评："如体验出众，欢迎在[TripAdvisor/Google/Booking.com]分享"
+- 邀请直接回复邮件解决遗留问题
+
+## Negative Review Response Rules（差评响应规则）
+- **响应时限**：24小时内
+- **响应态度**：永远不要防御性；承认问题；采取纠正行动
+- **响应内容**：具体承认问题+已采取/正在采取的纠正措施+邀请离线沟通
+- **禁忌**：公开承诺补偿（应在私下沟通）
+
+### Negative Review Response Template
+```
+Dear [Guest Name],
+
+感谢您分享反馈。我对您的体验未达我们标准深感抱歉。
+
+[具体承认问题]
+
+这不符合我们期望任何宾客体验的标准，您的反馈我已亲自重视。
+[具体已采取/正在采取的纠正措施]
+
+如您方便，我希望能直接与您沟通解决这个问题。
+请联系我：[邮箱/电话]。
+
+期待有机会再次为您服务。
+
+[姓名、职位、酒店名]
+```
+
+## Key Principles
+- 每条点评都必须回复（好评+差评）
+- 差评响应是公开的客户服务展示，不是辩论
+- 将差评视为服务恢复机会，争取宾客修改评分
+
+## Connections
+- [[Hospitality Guest Services]] ← 评价管理是宾客服务 Agent 售后阶段的核心技能
+- [[Service Recovery Protocol]] ← 有效的服务恢复是预防差评的关键
+- [[Loyalty Program Management]] ← 忠诚会员的点评影响权重更高，需优先跟进
+
+## Aliases
+- 在线评价管理
+- 口碑管理
+- OTA Review Management
+- Guest Feedback Management
diff --git a/wiki/concepts/RuntimeVirtualTexturing.md b/wiki/concepts/RuntimeVirtualTexturing.md
index 8700c93e..4e894a19 100644
--- a/wiki/concepts/RuntimeVirtualTexturing.md
+++ b/wiki/concepts/RuntimeVirtualTexturing.md
@@ -1,40 +1,45 @@
 ---
-title: "Runtime Virtual Texturing"
+title: "RuntimeVirtualTexturing"
 type: concept
-tags: ["unreal-engine", "landscape", "texturing", "ue5", "performance"]
-sources: ["unreal-world-builder", "unreal-technical-artist"]
-last_updated: 2026-04-26
+tags: ["unreal-engine", "texturing", "landscape", "performance"]
+sources: ["unreal-world-builder"]
+last_updated: 2026-04-30
 ---
 
+## Aliases
+- RVT
+- Runtime Virtual Texturing
+- 运行时虚拟纹理
+
 ## Definition
-Runtime Virtual Texturing（RVT），UE5 运行时虚拟纹理技术，通过将多层地形纹理混合计算结果缓存到虚拟纹理图集（Virtual Texture Atlas），消除逐像素层混合的 shader 开销。当地形材质层数超过 2 层时，RVT 成为必选项而非可选项。
+Runtime Virtual Texturing（RVT）是 Unreal Engine 5 的按需虚拟纹理技术，允许材质在运行时动态渲染到虚拟纹理空间，而非在着色器中实时计算多层混合。对于 Landscape 地形（> 2 层材质）和需要动态混合的复杂材质，RVT 是关键性能优化手段。
 
-## Core Mechanism
-- **Virtual Texture Atlas**：多层混合结果以瓦片（Tile）为单位缓存，按需流送到 GPU
-- **RVT Resolution**：通常 2048×2048 每 4096m² 网格单元
-- **RVT Format**：推荐 YCoCg 压缩格式，相比 RGBA 节省内存
-- **Producer**：Landscape Actor 启用 Virtual Texture Producer；需要对应的 RVT Output Volume 放置在世界每个网格单元
+## RVT vs Traditional Layer Blending
+| 方案 | 层数限制 | 性能特征 |
+|------|---------|---------|
+| 传统逐像素混合 | 2 层以内 | 层数增加线性增长 |
+| RVT | 无硬性限制（实践建议 ≤ 8） | 固定虚拟纹理采样开销 |
 
-## When RVT is Required
-| 条件 | RVT 建议 |
-|------|----------|
-| ≤2 层 Landscape 材质 | 可选，性能提升有限 |
-| >2 层 Landscape 材质 | **必须启用**，否则产生材质排列组合爆炸 |
-| 开放世界（World Partition） | **必须启用**，与流送系统协同 |
+## Landscape 中的 RVT
+- 超过 2 层 Landscape 材质时**必须**启用 RVT
+- **RVT 分辨率**：每 4096m² 格子 2048×2048
+- **RVT 格式**：YCoCg 压缩（节省内存，相较 RGBA）
+- **Virtual Texture Producer**：必须在 Landscape Actor 上启用
+- **RVT Output Volume**：每 4096m² 格子对齐放置
 
-## RVT in Landscape Material Design
-典型四层 Landscape 材质结构（配合 RVT）：
-1. **Grass**：基础层，始终存在，填充空区域
-2. **Dirt/Path**：沿路径替换草地
-3. **Rock**：坡度驱动（WorldAlignedBlend，斜率阈值 0.6 自动切换）
-4. **Snow**：高度驱动（超过 SnowLine 高度参数时淡入）
+## Dynamic RVT Applications
+RVT 可采样运行时数据驱动地形状态变化：
+- 游戏标签（Gameplay Tags）驱动地形层权重
+- Decal Actor 投影湿气/雪/泥效果
+- 雨积累参数驱动 RVT 混合权重趋向湿表面层
 
-Auto-Slope Rock Blend：`dot(WorldUp, SurfaceNormal) < 0.6` → Rock 层渐变到 Grass/Dirt
+## RVT Cache Warm-Up
+Cinematic Camera 场景前必须预热 RVT Cache，否则初次渲染出现 LOD 闪烁。
 
-## RVT for Dynamic Gameplay State
-高级应用：RVT 权重混合可采样 Gameplay Tags 或 Decal Actor，驱动动态地形状态变化（如降雨累积 → 湿滑表面层）。
+## Connections
+- [[Landscape]] ← 层混合优化 ← RuntimeVirtualTexturing
+- [[UnrealWorldBuilder]] ← 地形材质 ← RuntimeVirtualTexturing
+- [[UnrealEngine5]] ← 核心引擎 ← RuntimeVirtualTexturing
 
-## Related
-- [[UnrealWorldBuilder]] — RVT 配置与调优专家
-- [[UnrealTechnicalArtist]] — Landscape Master Material 构建与 RVT Output Volume 放置
-- [[Landscape]] — RVT 是 Landscape 材质系统的性能关键
+## Sources
+- [[unreal-world-builder]]
diff --git a/wiki/concepts/SHAP.md b/wiki/concepts/SHAP.md
index 0ab89ef2..4a68d679 100644
--- a/wiki/concepts/SHAP.md
+++ b/wiki/concepts/SHAP.md
@@ -1,70 +1,72 @@
----
-title: "SHAP (SHapley Additive exPlanations)"
-type: concept
-tags: [model-interpretability, feature-attribution, explainable-ai]
-last_updated: 2026-04-25
----
-
-## Definition
-
-SHAP（SHapley Additive exPlanations）是一种基于博弈论 Shapley 值的模型可解释性框架，为每个特征的贡献提供统一的量化度量。通过计算每个特征在所有可能的特征组合中的边际贡献均值，SHAP 给出唯一且公平的归因值。
-
-## Core Concepts
-
-### Global Interpretability
-- **SHAP Summary Plot (Beeswarm)**：同时展示特征值方向和影响幅度的散点图，横轴为 SHAP 值，纵轴为特征，颜色编码特征值高低
-- **SHAP Bar Plot**：各特征 mean |SHAP| 排序，展示整体特征重要性
-- **应用场景**：与文档化特征理由对比，识别未在方法论文档中讨论但实际影响显著的"隐性特征"
-
-### Local Interpretability
-- **SHAP Waterfall Plot**：解释单个预测——从基础值（base value）出发，逐特征展示其推动预测的方向和幅度
-- **SHAP Force Plot**：可视化单个预测的特征贡献，常用于高风险决策解释
-- **应用场景**：边缘案例预测（top/bottom decile、误分类记录）的深度分析
-
-### SHAP Interaction Values
-- 检测特征之间的依赖和交互效应
-- 将总 SHAP 贡献分解为：主效应 + 交互效应
-- 用于识别模型学习到的非预期特征交互
-
-## Usage
-
-```python
-import shap
-
-explainer = shap.TreeExplainer(model)
-shap_values = explainer.shap_values(X)
-
-# Global: beeswarm
-shap.summary_plot(shap_values, X, show=False)
-plt.savefig("shap_beeswarm.png", dpi=150)
-
-# Global: bar
-shap.summary_plot(shap_values, X, plot_type="bar", show=False)
-plt.savefig("shap_importance.png", dpi=150)
-
-# Local: waterfall
-explanation = explainer(X.iloc[[idx]])
-shap.plots.waterfall(explanation[0], show=False)
-plt.savefig(f"shap_waterfall_{idx}.png", dpi=150)
-```
-
-## Model QA 中的应用
-
-Model QA Specialist 使用 SHAP 进行以下审计：
-1. **全局分析**：对比 SHAP 特征重要性与文档化特征理由，发现未记录的高贡献特征
-2. **PDP 交叉验证**：SHAP 分析结合 PDP 验证特征方向是否符合预期
-3. **局部解释**：边缘案例的 SHAP waterfall 揭示模型决策机制
-4. **稳定性监测**：跨时间窗口的 SHAP 排名变化反映特征重要性漂移
-
-## Relationship
-
-- **依赖** [[Population-Stability-Index]]：PSI 监测特征分布漂移，SHAP 监测特征贡献变化，两者结合才能完整评估模型健康度
-- **依赖** [[Calibration-Testing]]：SHAP 解释模型"为什么"预测，校准测试验证模型"多准确"预测
-- **依赖** [[Discrimination-Metrics]]：SHAP 贡献分析在 AUC/Gini 判定模型整体可用之后进行细节诊断
-- **支撑** [[Partial-Dependence-Plots]]：PDP 提供边际效应可视化，SHAP 提供精确归因，两者互补
-
-## Key Limitations
-
-- 计算复杂度：精确 Shapley 值计算为指数级，TreeExplainer 对树模型高效但对神经网络等黑盒模型需用 KernelExplainer（采样近似）
-- 交互效应分离：当特征高度相关时，Shapley 值归因可能不稳定
-- 基准依赖：Shapley 值的解释力取决于基准（base value）的选取
+---
+title: "SHAP (SHapley Additive exPlanations)"
+type: concept
+tags: [model-interpretability, feature-attribution, explainable-ai]
+sources:
+  - specialized-model-qa
+last_updated: 2026-05-29
+---
+
+## Definition
+
+SHAP（SHapley Additive exPlanations）是一种基于博弈论 Shapley 值的模型可解释性框架，为每个特征的贡献提供统一的量化度量。通过计算每个特征在所有可能的特征组合中的边际贡献均值，SHAP 给出唯一且公平的归因值。
+
+## Core Concepts
+
+### Global Interpretability
+- **SHAP Summary Plot (Beeswarm)**：同时展示特征值方向和影响幅度的散点图，横轴为 SHAP 值，纵轴为特征，颜色编码特征值高低
+- **SHAP Bar Plot**：各特征 mean |SHAP| 排序，展示整体特征重要性
+- **应用场景**：与文档化特征理由对比，识别未在方法论文档中讨论但实际影响显著的"隐性特征"
+
+### Local Interpretability
+- **SHAP Waterfall Plot**：解释单个预测——从基础值（base value）出发，逐特征展示其推动预测的方向和幅度
+- **SHAP Force Plot**：可视化单个预测的特征贡献，常用于高风险决策解释
+- **应用场景**：边缘案例预测（top/bottom decile、误分类记录）的深度分析
+
+### SHAP Interaction Values
+- 检测特征之间的依赖和交互效应
+- 将总 SHAP 贡献分解为：主效应 + 交互效应
+- 用于识别模型学习到的非预期特征交互
+
+## Usage
+
+```python
+import shap
+
+explainer = shap.TreeExplainer(model)
+shap_values = explainer.shap_values(X)
+
+# Global: beeswarm
+shap.summary_plot(shap_values, X, show=False)
+plt.savefig("shap_beeswarm.png", dpi=150)
+
+# Global: bar
+shap.summary_plot(shap_values, X, plot_type="bar", show=False)
+plt.savefig("shap_importance.png", dpi=150)
+
+# Local: waterfall
+explanation = explainer(X.iloc[[idx]])
+shap.plots.waterfall(explanation[0], show=False)
+plt.savefig(f"shap_waterfall_{idx}.png", dpi=150)
+```
+
+## Model QA 中的应用
+
+Model QA Specialist 使用 SHAP 进行以下审计：
+1. **全局分析**：对比 SHAP 特征重要性与文档化特征理由，发现未记录的高贡献特征
+2. **PDP 交叉验证**：SHAP 分析结合 PDP 验证特征方向是否符合预期
+3. **局部解释**：边缘案例的 SHAP waterfall 揭示模型决策机制
+4. **稳定性监测**：跨时间窗口的 SHAP 排名变化反映特征重要性漂移
+
+## Relationship
+
+- **依赖** [[Population-Stability-Index]]：PSI 监测特征分布漂移，SHAP 监测特征贡献变化，两者结合才能完整评估模型健康度
+- **依赖** [[Calibration-Testing]]：SHAP 解释模型"为什么"预测，校准测试验证模型"多准确"预测
+- **依赖** [[Discrimination-Metrics]]：SHAP 贡献分析在 AUC/Gini 判定模型整体可用之后进行细节诊断
+- **支撑** [[Partial-Dependence-Plots]]：PDP 提供边际效应可视化，SHAP 提供精确归因，两者互补
+
+## Key Limitations
+
+- 计算复杂度：精确 Shapley 值计算为指数级，TreeExplainer 对树模型高效但对神经网络等黑盒模型需用 KernelExplainer（采样近似）
+- 交互效应分离：当特征高度相关时，Shapley 值归因可能不稳定
+- 基准依赖：Shapley 值的解释力取决于基准（base value）的选取
diff --git a/wiki/concepts/SOC2.md b/wiki/concepts/SOC2.md
new file mode 100644
index 00000000..f3d8fc6c
--- /dev/null
+++ b/wiki/concepts/SOC2.md
@@ -0,0 +1,40 @@
+---
+title: "SOC 2"
+type: concept
+tags: []
+sources: [compliance-auditor]
+last_updated: 2026-04-30
+---
+
+# SOC 2
+
+## Aliases
+- SOC2
+- SOC 2 Type I
+- SOC 2 Type II
+- Service Organization Control 2
+
+## Definition
+
+SOC 2（Service Organization Control 2）是由美国注册会计师协会（AICPA）制定的信任服务标准认证框架，用于评估服务组织在安全性、可用性、处理完整性、保密性和隐私性五个信任服务标准方面的控制措施。
+
+## Core Components
+
+### 信任服务标准（Trust Service Criteria）
+1. **安全性（Security）**：系统受到保护，防止未授权访问
+2. **可用性（Availability）**：系统能够按照承诺运行
+3. **处理完整性（Processing Integrity）**：系统处理完整、有效、准确、及时
+4. **保密性（Confidentiality）**：指定为保密的信息得到保护
+5. **隐私性（Privacy）**：个人信息的收集、使用、保留和披露符合组织的隐私声明
+
+### SOC 2 类型
+- **Type I**：评估控制措施在特定日期的设计适当性
+- **Type II**：评估控制措施在指定期间（通常6-12个月）的设计和运行有效性
+
+## Related Concepts
+- [[Gap Assessment]]：SOC 2 审计前的必备步骤
+- [[Evidence Collection]]：SOC 2 Type II 审计的核心要求——需证明控制在整个审计期间持续有效
+- [[Continuous Compliance]]：SOC 2 年度审计间隔期间的持续合规实践
+
+## Related Sources
+- [[compliance-auditor]]
diff --git a/wiki/concepts/SSE.md b/wiki/concepts/SSE.md
new file mode 100644
index 00000000..5194efd9
--- /dev/null
+++ b/wiki/concepts/SSE.md
@@ -0,0 +1,37 @@
+---
+title: "SSE"
+type: concept
+tags: []
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Definition
+Server-Sent Events (SSE) 是一种服务器推送技术，允许服务端通过 HTTP 单向通道向客户端持续发送事件流。
+
+## Usage in Hermes Agent
+`/v1/runs` API 通过 SSE 实现长会话实时进度订阅：
+- **Token 流**：逐 token 推送响应内容
+- **工具进度**：自定义事件推送工具执行状态
+- **实时反馈**：用户可看到 Agent 思考和工具调用的全过程
+
+## Format
+```
+event: content
+data: {"content": "Hello"}
+
+event: tool_use
+data: {"tool": "terminal", "input": {...}}
+```
+
+## Comparison with WebSocket
+| 特性 | SSE | WebSocket |
+|------|-----|-----------|
+| 方向 | 单向（服务端→客户端） | 双向 |
+| 复杂性 | 简单 | 复杂 |
+| 自动重连 | 支持 | 需自行实现 |
+| HTTP/2 | 优化支持 | 支持 |
+
+## Related
+- [[ToolStreaming]]
+- [[ResponsesAPI]]
diff --git a/wiki/concepts/SVG图表生成.md b/wiki/concepts/SVG图表生成.md
new file mode 100644
index 00000000..f471ed9a
--- /dev/null
+++ b/wiki/concepts/SVG图表生成.md
@@ -0,0 +1,44 @@
+---
+title: "SVG图表生成"
+type: concept
+tags: []
+sources: [baoyu-skills]
+last_updated: 2026-04-19
+---
+
+## Overview
+
+SVG 图表生成是 [[baoyu-diagram]] 技能的核心方法——不调用任何图像生成模型，由 LLM 直接通过手算坐标生成 SVG 代码，一次确认后批量输出多张图表，内嵌深色模式样式。
+
+## Five Chart Types
+
+| 类型 | 适用场景 | 触发动词 |
+| --- | --- | --- |
+| `flowchart` | 按顺序走一遍流程 | 流程、步骤、工作流、生命周期、状态机 |
+| `sequence` | 谁和谁通信、按什么顺序 | 协议、握手、认证流程、OAuth、TCP |
+| `structural` | 展示什么包含什么、如何组织 | 架构、组件、拓扑、布局 |
+| `illustrative` | 建立直觉——画出机制本身 | 怎么工作、原理、为什么、直观解释 |
+| `class` | 类型是什么、它们如何关联 | 类图、UML、继承、接口、数据模型 |
+
+## Technical Approach
+
+**无图像生成模型**：LLM 直接手算 SVG 坐标生成矢量代码，确保每个图表符合统一设计规范。
+
+**内嵌样式**：
+- `<style>` 块包含 `@media (prefers-color-scheme: dark)` 深色模式覆盖
+- 同一个 SVG 文件在浅色和深色模式下均正确渲染
+- 自包含，无需外部依赖
+
+**输出格式**：
+- `.svg` 文件，可直接嵌入任意支持 SVG 的宿主环境
+- 可指定 `--out` 输出路径生成单张图表
+
+## Design Constraints
+
+- 统一设计规范（字体、颜色、线宽、间距等）
+- 语义形状词汇表（如需引用其他文档中的形状规范）
+- 语义箭头系统（颜色+虚线编码含义）
+
+## Connections
+- [[baoyu-diagram]] ← implements ← SVG图表生成
+- [[baoyu-skills]] ← 包含 ← SVG图表生成
diff --git a/wiki/concepts/SWC-Registry.md b/wiki/concepts/SWC-Registry.md
new file mode 100644
index 00000000..d4488fe4
--- /dev/null
+++ b/wiki/concepts/SWC-Registry.md
@@ -0,0 +1,61 @@
+---
+title: "SWC Registry（智能合约弱点分类）"
+type: concept
+tags: [blockchain, security, smart-contract, classification, standard]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- SWC Registry
+- Smart Contract Weakness Classification
+- SWC-100, SWC-101, etc.
+
+## Definition
+
+SWC Registry（Smart Contract Weakness Classification Registry）是由 Ethereum Foundation 维护的智能合约安全弱点标准化分类体系，提供漏洞的编号、描述、示例和修复建议，是审计报告引用的权威漏洞分类标准。
+
+## Key SWC Categories
+
+| SWC ID | Name | Description |
+|--------|------|-------------|
+| SWC-100 | Function Default Visibility | 函数默认可见性为 public |
+| SWC-101 | Integer Overflow/Underflow | 整数溢出（下溢在 Solidity 0.8+ 中自动 revert） |
+| SWC-103 | Floating Pragma | 浮动 Solidity 版本（应锁定版本） |
+| SWC-104 | Unchecked Call Return Value | 未检查外部调用返回值 |
+| SWC-105 | Unprotected Ether Withdrawal | 无保护的 ETH 提取 |
+| SWC-106 | Unprotected SELFDESTRUCT | 无保护的 selfdestruct |
+| SWC-107 | Reentrancy | 重入攻击 |
+| SWC-108 | State Variable Default Visibility | 状态变量默认可见性 |
+| SWC-109 | Uninitialized Storage Pointer | 未初始化的存储指针 |
+| SWC-110 | Assert Violation | assert 语句失败 |
+| SWC-111 | Use of Deprecated Functions | 使用已废弃函数 |
+| SWC-112 | Delegatecall to Untrusted Callee | delegatecall 到不可信地址 |
+| SWC-113 | DoS with Failed Call | 失败调用导致的 DoS |
+| SWC-114 | Order Dependencies | 交易顺序依赖 |
+| SWC-115 | Authorization Through tx.origin | 通过 tx.origin 授权 |
+
+## Usage in Audit Reports
+
+审计报告中每个发现通常包含：
+- **SWC ID**：标准漏洞编号（如 C-01 对应 SWC-107）
+- **描述**：漏洞的标准化定义
+- **代码示例**：SWC Registry 中的参考代码
+- **修复建议**：该漏洞的标准修复方案
+
+## Relationship to Audit
+
+- SWC Registry 是 [[Blockchain-Security-Auditor]] 撰写审计报告时的**标准引用**
+- [[Slither]] 的 `--checklist` 模式直接映射到 SWC 分类
+- SWC-107（Reentrancy）和 SWC-104（Unchecked Call）是最高频出现的漏洞
+
+## Limitations
+
+- 无法覆盖所有漏洞类型（新兴攻击模式可能尚无 SWC 编号）
+- Solidity 0.8+ 后部分 SWC（如 SWC-101）已自动防护
+- 部分 SWC 编号定义过于宽泛
+
+## Connections
+- [[Blockchain-Security-Auditor]] ← references ← [[SWC Registry]]
+- [[Slither]] ← maps to ← [[SWC Registry]]
+- [[The-DAO-2016]] ← classified as ← SWC-107 (Reentrancy)
diff --git a/wiki/concepts/Schema-Drift.md b/wiki/concepts/Schema-Drift.md
new file mode 100644
index 00000000..6268ed6f
--- /dev/null
+++ b/wiki/concepts/Schema-Drift.md
@@ -0,0 +1,39 @@
+---
+title: "Schema Drift"
+type: concept
+tags:
+  - "harness-engineering"
+  - "data-quality"
+  - "contracts"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+Schema Drift——同一 LLM 在不同调用中对同一字段生成不同数据类型的静默错误。例如：price 字段一次生成为 string（"19.99"），下一次生成为 float（19.99），下游管道静默产生垃圾数据或崩溃。
+
+## Why It Happens
+LLM 的输出是概率性的——它说"类型"，但它真正说的是"下一个最可能的 token 序列"。没有显式契约，类型边界是模糊的。
+
+## Silent vs. Loud Failure
+Schema Drift 是**静默失败**的典型案例：
+- 不符合 Schema 的输出 → 被管道接受 → 在数据分析阶段产生错误结论
+- 例如：定价字段从 float 变为 string → 价格比较操作失败 → 商业分析静默出错
+
+## Solution: Contracts & Interfaces Layer
+在每个系统边界（L LM ↔ 工具、Agent ↔ Agent、Harness ↔ 外部世界）强制显式契约：
+- 严格 JSON Schema
+- 类型化函数签名
+- 版本化 API spec
+
+Contract 层在边界交叉处验证输入和输出，**在不符合内容传播之前拒绝它**。
+
+## Core Principle
+> "The model speaks in probabilities. The harness must speak in types."
+
+## Relationship to [[Harness-Engineering]]
+Schema Drift 防护是 [[7-Layer-Harness-Stack]] 第 3 层（Contracts & Interfaces）的核心目标。
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
diff --git a/wiki/concepts/ScopeCreep.md b/wiki/concepts/ScopeCreep.md
new file mode 100644
index 00000000..c72f9302
--- /dev/null
+++ b/wiki/concepts/ScopeCreep.md
@@ -0,0 +1,37 @@
+---
+title: "ScopeCreep"
+type: concept
+tags: [engineering, code-quality, scope-management]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+范围蔓延（ScopeCreep）是指在项目或任务执行过程中，变更范围超出最初明确要求的渐进式扩展。常见形式包括"顺便..."（while I'm here）行为、审阅阶段引入的新需求、以及未经批准的"改进"。
+
+## Core Characteristics
+
+- **渐进性**：变更随时间逐步扩大，而非一次性大规模变更
+- **伪装性**：往往以"改进""清理""优化"等名义包装
+- **累积性**：单次范围蔓延看似无害，但累积效应显著
+
+## Patterns of ScopeCreep
+
+| 模式 | 描述 | 最小变更工程师的应对 |
+|------|------|---------------------|
+| "while I'm here" | 任务外发现值得修改的内容并顺手修改 | 记录为 follow-up，不包含在当前 PR |
+| "for future flexibility" | 为假设的未来需求添加配置标志或抽象 | 等待第二个调用者出现再提取 |
+| "defensive coding" | 为不可能发生的场景添加防御性代码 | 仅在系统边界（用户输入、外部 API）验证 |
+| "modernization" | 重写旧的但正常工作的代码为新风格 | 不重写未修改区域的代码 |
+| "consistency" | 因"其他代码都用了 X"而修改无关文件 | 不因一致性而触碰无关文件 |
+| "cleanup" | 移除假设是死代码的内容 | 用"删除并运行测试"确认，不做假设 |
+
+## Connections
+
+- [[engineering-minimal-change-engineer]]：最小变更工程师的核心对抗目标
+- [[engineering-code-reviewer]]：代码审查者应警惕并指出范围蔓延
+- [[PrematureAbstraction]]：范围蔓延的常见诱因之一
+
+## Sources
+
+- [[engineering-minimal-change-engineer]]
diff --git a/wiki/concepts/Security-Engineering-Concepts.md b/wiki/concepts/Security-Engineering-Concepts.md
new file mode 100644
index 00000000..baa9af4f
--- /dev/null
+++ b/wiki/concepts/Security-Engineering-Concepts.md
@@ -0,0 +1,139 @@
+---
+title: "Security Engineering Concepts"
+type: concept
+tags: [security, application-security]
+sources: [[engineering-security-engineer]]
+last_updated: 2026-05-01
+---
+
+## Aliases
+- AppSec
+- 安全工程概念集
+
+## Threat Modeling
+
+**定义**：系统化识别、量化并优先排序系统潜在安全威胁的结构化方法论。通过回答"系统可能被如何攻击"前置发现风险，而非事后补救。
+
+**核心框架 — STRIDE**（微软提出，六维度威胁分析）：
+
+| 维度 | 威胁描述 | 典型缓解措施 |
+|------|---------|------------|
+| **S**poofing（欺骗） | 冒充他人身份 | MFA、Token binding、账户锁定 |
+| **T**ampering（篡改） | 修改数据或代码 | HMAC 签名、输入验证、幂等键 |
+| **R**epudiation（抵赖） | 否认执行过某操作 | 不可变审计日志、防篡改存储 |
+| **I**nfo Disclosure（信息泄露） | 暴露敏感数据 | 加密、通用错误响应、访问控制 |
+| **D**oS（拒绝服务） | 使服务不可用 | 限流、WAF、熔断器、请求大小限制 |
+| **E**levation of Privilege（权限提升） | 越权执行操作 | RBAC（服务端强制执行）、会话隔离 |
+
+**工作流**：架构映射 → 数据流识别 → 信任边界编目 → STRIDE 逐组件分析 → 风险优先级排序（可能性 × 影响）
+
+---
+
+## Defense in Depth（防御深度）
+
+**定义**：不依赖单一保护层，假设任何一层均可能被绕过，通过多层独立控制叠加实现纵深防护的安全策略。
+
+**标准叠加链**：
+```
+Internet → WAF → Rate Limiting → Input Validation → Parameterized Queries → Output Encoding → CSP
+```
+
+**核心原则**：
+- 每层独立有效（单层失效不导致整体失效）
+- 多层协同（纵深而非重复）
+- 纵深优于广度（10 层各有差异的防御 > 3 层同类重复）
+
+**对比 Default Deny**：Default Deny 是每层内部的策略选择（默认阻止一切、仅放行白名单），Defense in Depth 是整体架构策略（多层独立防御叠加）。
+
+---
+
+## Zero Trust Architecture（零信任架构）
+
+**定义**：永不隐式信任、始终验证每次访问请求的架构范式，无论访问来源是内网还是外网。
+
+**三大核心原则**：
+1. **最小权限访问**（Least Privilege）：仅授予完成任务所需的最低权限
+2. **微隔离**（Microsegmentation）：网络级别细分隔离，防止横向移动
+3. **持续验证**（Continuous Verification）：每次请求均验证身份和权限
+
+**实现组件**：
+- 身份认证：OAuth 2.0 + PKCE、OpenID Connect、Passkeys/WebAuthn、MFA
+- 授权模型：RBAC / ABAC / ReBAC（按需选型）
+- 网络层：mTLS、服务网格策略（Istio/Linkerd）
+- 密钥管理：HashiCorp Vault / AWS Secrets Manager / SOPS（带轮换策略）
+
+---
+
+## CVSS 3.1（通用漏洞评分系统）
+
+**定义**：标准化漏洞严重等级评估框架，0.0–10.0 分制量化漏洞威胁程度。
+
+| 等级 | 分数区间 | 典型场景 |
+|------|---------|---------|
+| **Critical** | 9.0–10.0 | RCE、认证绕过、SQL注入（可访问数据） |
+| **High** | 7.0–8.9 | 存储型XSS、IDOR（敏感数据暴露）、权限提升 |
+| **Medium** | 4.0–6.9 | CSRF（状态变更操作）、缺少安全响应头 |
+| **Low** | 0.1–3.9 | 非敏感页面点击劫持、轻度信息泄露 |
+| **Informational** | 0.0 | 最佳实践偏差、防御深度改进建议 |
+
+**Security Engineer 的严重等级判定**：Critical > High > Medium > Low > Informational，每级必须附可利用性证明和具体修复代码。
+
+---
+
+## OWASP Top 10（2021+）
+
+**定义**：Open Web Application Security Project 发布的 Web 应用十大最关键安全风险清单，是代码审查和漏洞评估的基准清单。
+
+| 排名 | 风险名称 | 核心问题 |
+|------|---------|---------|
+| A01 | Broken Access Control（访问控制失效） | 授权检查缺失、IDOR、批量赋值 |
+| A02 | Cryptographic Failures（加密失败） | 敏感数据暴露、弱加密/哈希 |
+| A03 | Injection（注入） | SQLi、NoSQLi、CMDi、模板注入 |
+| A04 | Insecure Design（不安全设计） | 缺失安全架构、威胁建模不足 |
+| A05 | Security Misconfiguration（安全配置错误） | 错误配置、默认凭据、未修复组件 |
+| A06 | Vulnerable Components（易受攻击组件） | 使用已知漏洞组件、组件停止维护 |
+| A07 | Auth Failures（身份认证失效） | 会话管理缺陷、凭据填充 |
+| A08 | Data Integrity Failures（数据完整性失效） | CI/CD 供应链攻击、未验证更新 |
+| A09 | Logging & Monitoring Failures（日志监控缺失） | 未记录安全事件、无法检测入侵 |
+| A10 | SSRF（服务器端请求伪造） | URL 验证缺失导致内网探测 |
+
+---
+
+## Supply Chain Security（供应链安全）
+
+**定义**：针对软件供应链（依赖项、CI/CD 管道、第三方组件）的系统性安全防护，覆盖从引入到部署的全链条。
+
+**核心实践**：
+1. **SBOM（软件物料清单）**：生成并监控所有直接和传递依赖的清单
+2. **CVE 审计**：持续扫描第三方包与已知漏洞数据库的匹配
+3. **包完整性校验**：校验和、签名、lock 文件验证，防止注入
+4. **依赖混淆攻击检测**：同名恶意包检测（typosquatting / dependency confusion）
+5. **可复现构建**：确保构建结果可被独立验证，防供应链投毒
+
+**推荐工具**：Trivy（容器/依赖扫描）、Semgrep（SAST）、Gitleaks（密钥检测）
+
+---
+
+## Secrets Management（密钥管理）
+
+**定义**：敏感凭据（API 密钥、数据库密码、TLS 证书、加密密钥）的全生命周期安全管理，覆盖创建、存储、轮换、审计和销毁。
+
+**核心原则**：
+- 永不硬编码（禁止源码/配置文件中的明文凭据）
+- 永不日志记录（日志中禁止出现密钥内容）
+- 永不客户端暴露（禁止前端/移动端直接持有密钥）
+- 必须轮换策略（定期自动轮换 + 紧急撤销能力）
+
+**推荐方案**：
+- HashiCorp Vault：企业级，支持动态密钥、PKI、加密即服务
+- AWS Secrets Manager：AWS 原生，支持自动轮换（与 RDS/Redshift 原生集成）
+- SOPS（Secrets OPerationS）：YAML/JSON 加密，支持 Age/GPG，云厂商 KMS 集成
+
+---
+
+## Related Concepts
+- [[engineering-security-engineer]]：以上所有概念的来源 Agent Personality
+- [[engineering-threat-detection-engineer]]：威胁检测 Engineer（检测层），与预防层互补
+- [[engineering-backend-architect]]：共享"安全优先"原则，侧重系统架构视角
+- [[OWASP Top 10]]：Web 应用安全的基准清单
+- [[Zero Trust Architecture]]：零信任是安全架构设计的核心理念
diff --git a/wiki/concepts/Segregation-Of-Duties.md b/wiki/concepts/Segregation-Of-Duties.md
new file mode 100644
index 00000000..ed9675ae
--- /dev/null
+++ b/wiki/concepts/Segregation-Of-Duties.md
@@ -0,0 +1,38 @@
+---
+title: "Segregation of Duties"
+type: concept
+tags: [finance, accounting, compliance, controls]
+sources: [finance-bookkeeper-controller]
+last_updated: 2026-05-02
+---
+
+## Definition
+职责分离（Segregation of Duties，SoD）是内部控制的基本原则，要求将一项业务流程中的关键职责分配给不同的人，以防止错误和欺诈。
+
+## Core Rule
+> "The person who initiates a transaction should not be the same person who approves or records it."
+
+## Three Key Functions
+1. **Authorization**（授权）：谁有权发起或批准交易
+2. **Custody**（保管）：谁实际接触资产（现金、存货等）
+3. **Recording**（记录）：谁在会计系统中记录交易
+
+## Practical Application
+- 出纳员不能同时负责银行调节
+- 采购员不能同时负责供应商付款审批
+- 工资专员不能同时负责工资银行账户
+- Controller 不应审批自己记录的 journal entries
+
+## SOX Perspective
+SOX 404 要求管理层评估和测试关键财务报告控制的有效性，职责分离是评估的核心控制点之一。
+
+## Implementation in AI Agents
+在 AI Agent 系统中，职责分离体现为：
+- 不同 Agent 负责不同财务职能（如 AP Agent 处理发票，Bookkeeper Controller 审核并记录）
+- 审批工作流需要多 Agent 确认
+- 交易记录与交易审批由不同 Agent 完成
+
+## Related Concepts
+- [[Internal Controls]]
+- [[Audit Readiness]]
+- [[GAAP-Compliance]]
diff --git a/wiki/concepts/Self-Grading-Illusion.md b/wiki/concepts/Self-Grading-Illusion.md
new file mode 100644
index 00000000..96028b64
--- /dev/null
+++ b/wiki/concepts/Self-Grading-Illusion.md
@@ -0,0 +1,40 @@
+---
+title: "Self-Grading Illusion"
+type: concept
+tags:
+  - "agentic-ai"
+  - "evaluation"
+  - "failure-mode"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+Self-Grading Illusion——LLM 无法有效评估自身输出的结构性缺陷。同一套权重既生成输出又评判输出——生成输出的权重位置决定了它不能可靠地评判该输出，导致对平庸输出给予不配得的信心评分。
+
+## Mechanism
+当 LLM 被要求评估自己生成的内容时：
+- 它使用生成该内容的同一内部表征做出判断
+- 这些表征对自身产出的缺陷有"盲点"（因为它们就是产生缺陷的原因）
+- 结果：结构性的自我偏好，而非客观评估
+
+## Source in Article
+Anthropic 在 steering vectors 和内部模型表征方面的研究被本文引用，表明在冲突约束下（"修这个 bug，但又不能改任何代码"），模型内部状态有可测量的变化——不只是表面文本预测出错，模型在内部对"看起来正确"而非"真正正确"进行了优化。
+
+## Solution: Sprint Contract
+[[Sprint-Contract]] 通过角色分离打破结构性缺陷：
+1. **Generator** 生成输出
+2. **Evaluator** 在**干净上下文**中评估——只接收输出 + 成功标准，不读 Generator 的思维链
+3. **Evaluator 必须执行**：运行代码、在 headless 浏览器验证接口、对比 schema——不只是读文本然后评判
+
+## Key Rules
+- Evaluator 必须在干净上下文中操作——如果它读取了 Generator 的完整推理链，它继承了 Generator 的假设和盲点
+- 给 Evaluator 的信息：输出 + 成功标准，**无其他**
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
+
+## See Also
+- [[Sprint-Contract]] — 具体解决方案
+- [[LLM-as-a-Judge]] — 相关评估模式（LLM-as-Judge 适用于主观评估，Self-Grading Illusion 适用于自我评估）
diff --git a/wiki/concepts/Self-Healing System.md b/wiki/concepts/Self-Healing System.md
new file mode 100644
index 00000000..5a1ba1c4
--- /dev/null
+++ b/wiki/concepts/Self-Healing System.md	
@@ -0,0 +1,93 @@
+---
+title: "Self-Healing System"
+type: concept
+tags: [DevOps, Reliability, Automation]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
+---
+
+# Self-Healing System
+
+## 定义
+自愈系统是指能够自动检测故障、触发恢复机制，在无需人工干预的情况下恢复到正常运行状态的系统。核心目标是减少 MTTR（Mean Time To Recovery），提升系统可用性。
+
+## 自愈机制层次
+
+### 1. 基础设施层
+- **自动扩缩容**：基于指标自动增加/减少实例
+- **健康检查 + 自动替换**：检测到不健康实例后自动终止并启动新实例
+- **多可用区部署**：单可用区故障不影响整体服务
+
+### 2. 应用层
+- **优雅降级**：部分功能不可用时，核心功能继续运行
+- **熔断器（Circuit Breaker）**：防止故障级联传播
+- **重试机制 + 指数退避**：临时故障自动恢复
+
+### 3. 数据层
+- **自动备份**：定期备份数据库
+- **故障转移**：主库故障自动切换到备用库
+- **数据一致性检查**：定期校验数据完整性
+
+## 在 DevOps Automator 中的应用
+DevOps Automator 的自愈设计：
+```terraform
+# AWS Auto Scaling Group 自愈配置
+resource "aws_autoscaling_group" "app" {
+  health_check_type         = "ELB"  # ELB 健康检查
+  health_check_grace_period = 300    # 启动后 5 分钟内不进行健康检查
+  
+  lifecycle {
+    create_before_destroy = true  # 新实例就绪后再终止旧实例
+  }
+}
+
+# CloudWatch Alarm 自动恢复
+resource "aws_cloudwatch_metric_alarm" "high_cpu" {
+  alarm_name          = "app-high-cpu"
+  comparison_operator = "GreaterThanThreshold"
+  threshold           = 80
+  alarm_actions       = [aws_sns_topic.alerts.arn]
+  # 自动触发扩展或通知
+}
+```
+
+## Kubernetes 自愈能力
+- **ReplicaSet**：维持期望的 Pod 副本数，Pod 崩溃自动重启
+- **Liveness Probe**：检测应用无响应后自动重启容器
+- **Readiness Probe**：标记 Pod 为不可用，自动从 Service 中移除
+- **Horizontal Pod Autoscaler**：基于 CPU/内存自动扩缩容
+
+## 自愈 vs 人工干预
+
+| 场景 | 自愈 | 人工干预 |
+|------|------|----------|
+| 实例崩溃 | ✅ 自动重启/替换 | - |
+| 内存泄漏（渐进式） | ✅ 自动扩展缓解 | 人工分析根因 |
+| 配置错误 | ❌ 需回滚配置 | ✅ 人工修复 |
+| 外部依赖故障 | ⚠️ 降级/重试 | ✅ 人工处理 |
+| 灾难性故障 | ⚠️ 部分可恢复 | ✅ 必需 |
+
+## 相关概念
+- [[Observability]]：自愈的前提是能够检测故障
+- [[Zero-Downtime Deployment]]：自愈能力支撑零停机部署
+- [[Kubernetes]]：K8s 提供丰富的自愈机制
+
+## 最佳实践
+1. **监控先行**：没有可观测性就没有自愈
+2. **渐进式自愈**：从简单场景开始，逐步增加复杂度
+3. **设置边界**：明确哪些情况必须人工介入
+4. **记录和告警**：即使自愈成功，也要通知运维团队
+5. **测试自愈机制**：定期演练故障场景
+
+## 关键指标
+- **MTTR**：平均恢复时间（越短越好）
+- **自愈成功率**：自愈成功的故障数 / 总故障数
+- **MTTA**：平均确认时间（检测到告警到开始处理）
+
+## Aliases
+- Self-Healing
+- 自愈系统
+- Automatic Recovery
+- 自动恢复
+- Fault Tolerance
+- 容错
diff --git a/wiki/concepts/Semantic-Routing.md b/wiki/concepts/Semantic-Routing.md
new file mode 100644
index 00000000..57a3bdde
--- /dev/null
+++ b/wiki/concepts/Semantic-Routing.md
@@ -0,0 +1,49 @@
+---
+title: "Semantic Routing"
+type: concept
+tags: []
+sources: [engineering-autonomous-optimization-architect]
+last_updated: 2026-05-01
+---
+
+# Semantic Routing
+
+## Definition
+
+语义路由——基于任务语义和历史性能数据，动态选择最优 LLM 提供商进行路由，而非使用固定规则或纯价格优先策略。
+
+## Routing Decision Factors
+
+- **任务类型**：文本提取 vs. 代码生成 vs. 创意写作 vs. 复杂推理
+- **历史准确率**：该模型在此类任务上的 LLM-as-a-Judge 评分
+- **成本**：每百万 Token 成本
+- **延迟**：P95 响应时间
+- **可用性**：当前熔断器状态
+
+## Example
+
+```typescript
+// Gemini Flash 在特定提取任务上准确率达 98% 且成本仅为 Claude Opus 的 10%
+// → 自动将此类任务路由到 Gemini Flash
+const rankedProviders = rankByHistoricalPerformance(taskType, providers);
+for (const provider of rankedProviders) {
+    if (!provider.circuitBreakerTripped) {
+        return await provider.execute(task);
+    }
+}
+```
+
+## vs. Traditional Routing
+
+| 维度 | 固定路由 | 语义路由 |
+|------|----------|----------|
+| 成本优化 | ❌ | ✅ |
+| 任务适配 | ❌ | ✅ |
+| 动态适应 | ❌ | ✅ |
+| 新模型集成 | 需人工修改 | 自动发现 |
+
+## Related
+
+- [[Autonomous-Optimization-Architect]]：实施语义路由的核心 Agent
+- [[AI-FinOps]]：语义路由是成本优化的主要手段
+- [[Shadow-Traffic]]：语义路由的评分数据来源于影子测试
diff --git a/wiki/concepts/SemanticAnomalyCompression.md b/wiki/concepts/SemanticAnomalyCompression.md
new file mode 100644
index 00000000..4fad9534
--- /dev/null
+++ b/wiki/concepts/SemanticAnomalyCompression.md
@@ -0,0 +1,36 @@
+---
+title: "Semantic Anomaly Compression"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+
+通过向量嵌入（sentence-transformers）和语义聚类（ChromaDB/FAISS）将海量异常数据行压缩为少量语义模式家族，从而将大规模数据修复问题的 SLM/LLM 调用量降低 95%+ 的方法论。
+
+## Core Mechanism
+
+1. **Embedding**: 使用本地 sentence-transformers（如 all-MiniLM-L6-v2）对异常数据行生成向量表示
+2. **Clustering**: 使用 ChromaDB 或 FAISS 对向量进行语义聚类，分组为 8-15 个模式家族
+3. **Sampling**: 从每个聚类中提取 3-5 个代表性样本
+4. **Fix Generation**: SLM 只需处理 ~12 个聚类代表，而非数万个原始数据行
+
+## Formula
+
+```
+50,000 anomalous rows → ~12 semantic clusters → ~12 SLM calls (vs 50,000)
+```
+
+## Key Properties
+
+- **Deterministic**: 聚类结果可复现
+- **Offline**: 所有嵌入计算在本地完成，无外部 API 调用
+- **Composable**: 可与任何数据管道集成，不改变上游 schema
+- **Auditable**: 每个聚类的代表样本和处理过程均可记录
+
+## Related
+
+- [[Air-Gapped SLM Fix Generation]]
+- [[Hybrid Fingerprinting]]
+- [[Zero Data Loss Guarantee]]
diff --git a/wiki/concepts/SemanticCodeGraph.md b/wiki/concepts/SemanticCodeGraph.md
new file mode 100644
index 00000000..8bf5b0f8
--- /dev/null
+++ b/wiki/concepts/SemanticCodeGraph.md
@@ -0,0 +1,56 @@
+---
+title: "SemanticCodeGraph"
+type: concept
+tags: ["code-intelligence", "semantic-graph", "LSP", "symbol-index", "navigation"]
+sources: ["lsp-index-engineer.md"]
+last_updated: 2026-04-29
+---
+
+## Definition
+语义代码图谱（Semantic Code Graph）是以**节点**（文件/模块/符号）和**边**（语义关系）表示代码结构统一语义抽象的数据结构。相比纯文本搜索和 AST 解析，语义图谱能够表达代码的深层语义关系（调用链、继承关系、类型层次），为代码导航、重构分析和可视化提供结构化数据基础。
+
+## Core Mechanism
+
+### Node Schema
+```typescript
+interface GraphNode {
+  id: string;        // "file:src/foo.ts" or "sym:AppController#method"
+  kind: 'file' | 'module' | 'class' | 'function' | 'variable' | 'type';
+  file?: string;     // Parent file path
+  range?: Range;     // LSP Range for symbol location
+  detail?: string;  // Type signature or brief description
+}
+```
+
+### Edge Schema
+```typescript
+interface GraphEdge {
+  id: string;        // "edge:uuid"
+  source: string;    // Node ID
+  target: string;   // Node ID
+  type: 'contains' | 'imports' | 'extends' | 'implements' | 'calls' | 'references';
+  weight?: number;  // Importance/frequency weight
+}
+```
+
+### Consistency Invariants
+- **每个符号有且仅有一个定义节点**
+- **所有边必须引用有效节点 ID**
+- **文件节点必须先于其包含的符号节点存在**
+- **Import 边必须解析到实际文件/模块节点**
+- **Reference 边必须指向定义节点**
+
+## Graph Construction Pipeline
+1. **收集文件**：通过 glob 扫描所有源文件
+2. **创建文件节点**：为每个文件创建 `file:` 节点
+3. **提取符号**：通过 LSP `textDocument/documentSymbol` 提取符号
+4. **添加符号节点**：为每个符号创建 `sym:` 节点
+5. **添加 Contains 边**：文件节点 → 符号节点
+6. **解析引用**：通过 LSP `textDocument/references` 解析引用关系
+7. **添加语义边**：imports / calls / references / extends / implements
+
+## Connections
+- [[SemanticCodeGraph]] ← built_by ← [[GraphDaemon]]
+- [[SemanticCodeGraph]] ← uses ← [[LSPOrchestrator]]
+- [[SemanticCodeGraph]] ← persisted_as ← [[nav.index.jsonl]]
+- [[SemanticCodeGraph]] ← indexed_via ← [[LSIF]]
diff --git a/wiki/concepts/Ser-vs-Estar.md b/wiki/concepts/Ser-vs-Estar.md
new file mode 100644
index 00000000..799d03ed
--- /dev/null
+++ b/wiki/concepts/Ser-vs-Estar.md
@@ -0,0 +1,71 @@
+---
+title: "Ser vs Estar"
+type: concept
+tags: ["spanish", "linguistics", "grammar", "translation", "verb", "to-be"]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+**Ser vs Estar**（两个"to be"动词）是西班牙语中最核心也最令学习者困惑的语法区分。两者都翻译为英语的"to be"，但不可互换——选择哪个动词会完全改变句子的含义。
+
+## The Core Distinction
+
+| 动词 | 本质 | 使用场景 | 记忆口诀 |
+|---|---|---|---|
+| **ser** | 固有属性/身份 | 身份、职业、国籍、时间、固有特征 | "WHO/WHAT it IS" |
+| **estar** | 临时状态/位置 | 位置、临时状态、情感、健康 | "HOW it's STAYING" |
+
+## Key Examples
+
+### Identity & Inherent Characteristics → **ser**
+
+| 西班牙语 | 中文 | 说明 |
+|---|---|---|
+| Soy profesor. | 我是老师。 | 职业（固有身份） |
+| Ella es de México. | 她来自墨西哥。 | 国籍/来源 |
+| Es alta. | 她个子高。 | 固有身体特征 |
+| Soy aburrido. | 我是个无聊的人。 | 性格（固有） |
+
+### Temporary States & Locations → **estar**
+
+| 西班牙语 | 中文 | 说明 |
+|---|---|---|
+| Estoy cansado. | 我累了。 | 临时身体状态 |
+| Está en la escuela. | 他/她在学校。 | 临时位置 |
+| Estoy aburrido. | 我现在感到无聊。 | 临时情绪状态 |
+| Está lloviendo. | 正在下雨。 | 临时状态（天气） |
+
+## The Classic Trap
+
+| 句子 | 含义差异 |
+|---|---|
+| **Soy aburrido** | "我是一个无聊的人"（性格无聊——冒犯性） |
+| **Estoy aburrido** | "我现在感到无聊"（当下状态——中性） |
+
+这个差异在 [[Language Translator]] Agent 中必须被明确标注——错误选择可能无意中冒犯对方。
+
+## Extended Usage
+
+| ser 用法 | estar 用法 |
+|---|---|
+| 时间（¿Qué hora es?） | 健康状态 |
+| 价格（¿Cuánto es?） | 天气 |
+| 被动语态（fue construido） | 正在进行时（estoy trabajando） |
+| 材料（Es de madera） | 味道/气味/感觉（Está bueno） |
+
+## In Translation
+
+当 [[Language Translator]] Agent 提供翻译时：
+1. 识别英语中 "to be" 动词对应的语境
+2. 判断是固有属性还是临时状态
+3. 选择正确的 ser/estar
+4. 必要时向学习者解释区分依据
+
+## Related Concepts
+- [[Subjunctive Mood]]：两者在虚拟式场景中都有变位
+- [[Meaning Transfer Translation]]：字面翻译无法传达 ser/estar 的语义差异
+- [[False Cognates]]：英语 "sensible" vs 西班牙语 "sensible" 陷阱
+
+## Sources
+- [[language-translator]]
diff --git a/wiki/concepts/Server-AuthoritativeModel.md b/wiki/concepts/Server-AuthoritativeModel.md
new file mode 100644
index 00000000..7b8605ce
--- /dev/null
+++ b/wiki/concepts/Server-AuthoritativeModel.md
@@ -0,0 +1,39 @@
+---
+title: "Server-Authoritative Model"
+type: concept
+tags: ["game-networking", "multiplayer", "security"]
+sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- 服务器权威模型
+- Server Authority
+- Authority Model
+
+## 定义
+多人游戏中的服务器权威模型是指所有游戏状态变更必须在服务器端执行，客户端仅发送请求（RPC），服务器验证后执行并通过复制同步状态。
+
+## 核心原则
+1. **服务器拥有真相**：客户端显示的状态仅供参考，服务器状态为最终权威
+2. **客户端预测**：客户端本地预测操作以减少延迟感知，服务器确认或回滚
+3. **验证不可省略**：每个 Server RPC 必须实现 `_Validate()` 函数，否则为作弊漏洞
+
+## 架构模式
+```
+客户端 → 发送 RPC (Client Request)
+服务器 → 验证输入 (Validate)
+服务器 → 执行逻辑 (Simulate/Execute)
+服务器 → 复制状态 (Replicate)
+客户端 → 接收更新 (Receive/Reconcile)
+```
+
+## 在 UE5 中的实现
+- `UFUNCTION(Server, Reliable, WithValidation)` 标记服务器 RPC
+- `ServerRequestInteract_Validate()` 必须实现所有游戏逻辑输入验证
+- `HasAuthority()` 检查确保在服务器端执行状态变更
+
+## 相关概念
+- [[Actor Replication]] — 服务器向客户端同步状态的机制
+- [[Network Prediction]] — 客户端本地预测以减少延迟感知
+- [[GAS (Gameplay Ability System)]] — UE5 能力系统，包含网络预测支持
diff --git a/wiki/concepts/Service-Recovery-Protocol.md b/wiki/concepts/Service-Recovery-Protocol.md
new file mode 100644
index 00000000..3a35c003
--- /dev/null
+++ b/wiki/concepts/Service-Recovery-Protocol.md
@@ -0,0 +1,48 @@
+---
+title: "Service Recovery Protocol"
+type: concept
+tags: []
+sources:
+  - hospitality-guest-services
+last_updated: 2026-05-02
+---
+
+## Definition
+Service Recovery Protocol（服务恢复协议）是在服务失误发生后，系统化地将宾客不满转化为满意甚至忠诚的标准化操作流程。与一次性道歉不同，服务恢复包含立即行动、分级补偿和跟进承诺三个维度。
+
+## Core Components
+
+### 1. Immediate Action（立即行动）
+| 问题类型 | 响应时限 | 行动要求 |
+|----------|----------|----------|
+| 噪音投诉 | 立即 | 立即为宾客更换房间 |
+| 清洁问题 | 15分钟内 | 派客房服务15分钟内到达 |
+| 设施故障 | 15分钟内 | 派工程部15分钟内到达 |
+| 账单错误 | 当场 | 当场纠正，不说"我们会查" |
+| 缺失设施 | 15分钟内 | 15分钟内送达宾客房间 |
+
+### 2. Compensation Tiers（分级补偿）
+按严重程度匹配补偿力度，[[HEARD Method]] 的 D 步骤（Delight）即超越期望的补偿：
+- 标准恢复选项：免费升级、葡萄酒/甜点赠送、积分奖励、当期/未来入住折扣
+- 顶级补偿：免费房晚、免费餐食、贵宾礼遇
+
+### 3. Follow-Through（跟进承诺）
+- **跟进是强制性的**：承诺了跟进就必须执行
+- 跟进话术："我将在今晚/明早亲自跟进您，确保一切满意。[时间]方便联系您吗？"
+- 文档记录：每起投诉必须记录宾客姓名、房号、投诉性质、报告时间、解决时间、解决方案、补偿内容
+
+## Key Rules
+- 永远不要在提供解决方案前说"That's not our policy"
+- 永远不要说"That's not my department"，始终Own the resolution
+- 安全事件（受伤/疾病/安全顾虑）立即升级至管理层
+
+## Connections
+- [[HEARD Method]] ← 投诉处理框架，Service Recovery Protocol 是其标准化实现
+- [[Hospitality Guest Services]] ← Service Recovery Protocol 是宾客服务 Agent 的核心交付物
+- [[Review Management]] ← 有效的服务恢复是防止差评、争取好评的关键时机
+
+## Aliases
+- 服务恢复
+- 服务补救
+- Guest Recovery
+- Service Recovery Framework
diff --git a/wiki/concepts/Shader.md b/wiki/concepts/Shader.md
index a209af95..d0863a82 100644
--- a/wiki/concepts/Shader.md
+++ b/wiki/concepts/Shader.md
@@ -2,8 +2,8 @@
 title: "Shader"
 type: concept
 tags: [game-dev, rendering, graphics]
-sources: [technical-artist]
-last_updated: 2026-04-26
+sources: [technical-artist, unity-shader-graph-artist]
+last_updated: 2026-05-01
 ---
 
 # Shader
@@ -41,6 +41,29 @@ Unity URP/HDRP 的高级抽象，自动处理光照模型，开发者只需定
 | 透明/加法 | 中等 | 高 | VFX、玻璃 |
 | 自定义光照 | 高 | 极高 | 特殊效果 |
 
+## Unity Shader Graph 规范（来自 [[unity-shader-graph-artist]]）
+
+### Sub-Graph 强制复用
+所有重复逻辑必须封装为 Sub-Graph，重复节点簇是维护和一致性失败。Sub-Graph 封装典型场景：DissolveCore（消融逻辑）、Fresnel（边缘高光）、TriplanarMapping（三角平面映射）。
+
+### URP / HDRP API 严格区分
+- **URP 自定义通道**：`ScriptableRendererFeature` + `ScriptableRenderPass`，不能用 `OnRenderImage`
+- **HDRP 自定义通道**：`CustomPassVolume` + `CustomPass`，API 与 URP 不兼容
+- Shader Graph 必须设置正确的 Render Pipeline asset，否则 URP 图形无法在 HDRP 中工作
+
+### 移动端性能硬约束
+| 指标 | 上限 |
+|------|------|
+| 每 Fragment Pass 纹理采样 | ≤ 32 次 |
+| 不透明 Fragment ALU | ≤ 60 条 |
+| Alpha Clipping | 优先于 Alpha Blend（避免过度绘制深度排序） |
+| `ddx`/`ddy` 导数 | 移动端禁止（tile-based GPU 上行为未定义） |
+
+### HLSL 规范
+- 使用 `.hlsl` 扩展名声明 include 文件，`.shader` 扩展名声明 ShaderLab wrapper
+- 必须使用 `TEXTURE2D`/`SAMPLER` 宏（`Core.hlsl`），`sampler2D` 不是 SRP 兼容的
+- `CBUFFER_START(UnityPerMaterial)` 属性块必须与 `Properties` 块完全匹配，否则产生静默黑材质
+
 ## Related Concepts
 - [[VFX]]：Shader 常用于 VFX 特效实现
 - [[LOD-Pipeline]]：LOD 切换时着色器需保持视觉一致性
@@ -48,4 +71,7 @@ Unity URP/HDRP 的高级抽象，自动处理光照模型，开发者只需定
 
 ## Connections
 - [[TechnicalArtist]] ← writes ← Shader
+- [[UnityShaderGraphArtist]] ← Unity 专精 ← Shader
 - [[VFX]] ← implements via ← Shader
+- [[URP]] ← 渲染管线 ← Shader
+- [[HDRP]] ← 渲染管线 ← Shader
diff --git a/wiki/concepts/Shadow-Traffic.md b/wiki/concepts/Shadow-Traffic.md
new file mode 100644
index 00000000..0d1f71f0
--- /dev/null
+++ b/wiki/concepts/Shadow-Traffic.md
@@ -0,0 +1,39 @@
+---
+title: "Shadow Traffic"
+type: concept
+tags: []
+sources: [engineering-autonomous-optimization-architect]
+last_updated: 2026-05-01
+---
+
+# Shadow Traffic
+
+## Definition
+
+暗启动（Shadow Traffic）——将一小部分真实用户流量异步复制到实验模型，在不影响生产环境的前提下验证新模型的真实表现。
+
+## Key Characteristics
+
+- **真实数据**：使用实际用户请求，而非合成测试数据
+- **异步执行**：影子请求不影响主请求的响应时间
+- **隔离评估**：影子结果仅用于评分，不影响用户可见输出
+- **渐进放量**：初始 1-5% 流量，成功后逐步提升
+
+## Workflow
+
+1. **Phase 1: Baseline**：建立当前生产模型的基准评分
+2. **Phase 2: Shadow**：将 5% 流量同时路由到实验模型
+3. **Phase 3: Evaluate**：LLM-as-a-Judge 评估实验模型输出
+4. **Phase 4: Promote**：统计显著优于基准时，自动提升流量比例
+
+## Safety Guarantees
+
+- 用户永远只收到生产模型的输出
+- 实验模型超时/错误不影响用户请求
+- 熔断器随时保护异常端点
+
+## Related
+
+- [[Autonomous-Optimization-Architect]]：设计并执行影子测试的核心 Agent
+- [[LLM-as-a-Judge]]：对影子流量结果进行量化评分
+- [[Circuit-Breaker]]：影子测试期间的异常保护机制
diff --git a/wiki/concepts/Slither.md b/wiki/concepts/Slither.md
new file mode 100644
index 00000000..cbd0699a
--- /dev/null
+++ b/wiki/concepts/Slither.md
@@ -0,0 +1,86 @@
+---
+title: "Slither（静态分析框架）"
+type: concept
+tags: [blockchain, security, smart-contract, static-analysis, tooling]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Slither
+- Slither Static Analysis
+
+## Definition
+
+Slither 是 Trail of Bits 开发的开源 Solidity 静态分析框架，通过自动化代码分析发现智能合约漏洞。它是智能合约安全审计的第一步，**高置信度检测器几乎总是真实漏洞**。
+
+## Key Capabilities
+
+### High-Confidence Detectors（高置信度 — 几乎总是真实漏洞）
+
+| Detector | Description |
+|----------|-------------|
+| `reentrancy-eth` | ETH 转账前的外部调用（经典重入） |
+| `reentrancy-no-eth` | 无 ETH 转账的重入（ERC-777 hooks） |
+| `arbitrary-send-eth` | 向任意地址发送 ETH |
+| `suicidal` | 无人能调用的 selfdestruct |
+| `controlled-delegatecall` | delegatecall 到用户可控地址 |
+| `uninitialized-state` | 使用未初始化状态变量 |
+| `unchecked-transfer` | 未检查 ERC-20 transfer 返回值 |
+| `locked-ether` | 无法提取的锁定 ETH |
+
+### Medium-Confidence Detectors
+
+| Detector | Description |
+|----------|-------------|
+| `reentrancy-benign` | 良性重入（需人工判断） |
+| `timestamp` | 时间戳依赖（矿工可操纵） |
+| `assembly` | 内联汇编使用 |
+| `low-level-calls` | 低级 call/callcode 使用 |
+
+## Comprehensive Analysis Script
+
+```bash
+#!/bin/bash
+# 高置信度检测
+slither . --detect reentrancy-eth,reentrancy-no-eth,arbitrary-send-eth,\
+suicidal,controlled-delegatecall,uninitialized-state,\
+unchecked-transfer,locked-ether \
+--filter-paths "node_modules|lib|test" \
+--json slither-high.json
+
+# 中置信度检测
+slither . --detect reentrancy-benign,timestamp,assembly,\
+low-level-calls,naming-convention,uninitialized-local \
+--filter-paths "node_modules|lib|test" \
+--json slither-medium.json
+
+# 人类可读摘要
+slither . --print human-summary --filter-paths "node_modules|lib|test"
+
+# ERC 标准合规性
+slither . --print erc-conformance --filter-paths "node_modules|lib|test"
+
+# 函数摘要
+slither . --print function-summary --filter-paths "node_modules|lib|test" \
+> function-summary.txt
+```
+
+## Limitations
+
+- **只能捕获约 30% 的真实漏洞** — 逻辑漏洞和协议级攻击需要人工审查
+- 误报率低但不是零，需要人工 triage
+- 无法验证字节码与源代码一致性（供应链攻击）
+
+## Relationship to Audit
+
+- **第一步**：运行 Slither 进行全量扫描
+- **第二步**：人工审查 Slither 标记的所有外部调用
+- **第三步**：对 Slither 未发现的问题进行专项人工审计
+- **第四步**：使用 [[Echidna]] 和 [[Mythril]] 进行深度分析
+
+## Connections
+- [[Blockchain-Security-Auditor]] ← uses ← [[Slither]]
+- [[Mythril]] ← alternative analysis ← [[Slither]]
+- [[Echidna]] ← fuzzing complement ← [[Slither]]
+- [[Trail-of-Bits]] ← developed by ← [[Slither]]
diff --git a/wiki/concepts/SocialIdentityTheory.md b/wiki/concepts/SocialIdentityTheory.md
new file mode 100644
index 00000000..2adc8b36
--- /dev/null
+++ b/wiki/concepts/SocialIdentityTheory.md
@@ -0,0 +1,42 @@
+---
+title: "Social Identity Theory"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# Social Identity Theory
+
+## Aliases
+- Social Identity Theory (Tajfel)
+- SIT
+- Tajfel's Social Identity Theory
+
+## Definition
+Tajfel 社会认同理论——个体通过群体 membership 获得自我概念，群体内/外动态（In-group/Out-group）深刻影响态度和行为。
+
+## Core Concepts
+
+### Social Identity（社会认同）
+个体自我概念的一部分，来源于群体成员身份。
+- **个人认同**（Personal Identity）：个体独特属性
+- **社会认同**（Social Identity）：群体成员共享的属性
+
+### In-group vs. Out-group
+- **In-group（内群体）**：个体认同的群体，产生忠诚和偏好
+- **Out-group（外群体）**：个体不认同的群体，容易被刻板化
+- **In-group Bias（内群体偏好）**：系统性地优待内群体成员
+- **Out-group Homogeneity（外群体同质化）**：认为外群体成员比实际更相似
+
+### Minimal Group Paradigm（最简群体范式）
+Tajfel 实验证明：即使群体划分完全任意（无实质差异），人们仍会表现出内群体偏好和外群体歧视——证明社会认同的内生驱动力量。
+
+### Social Categorization（社会分类）
+人们自然地将世界分为"我们"和"他们"，这一过程是自动化的，影响注意力和判断。
+
+## Application in Character Design
+Psychologist Agent 使用此框架分析群体互动中的身份政治、偏见形成和群体极化，帮助设计真实的社会动态。
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/Sociological-Accuracy.md b/wiki/concepts/Sociological-Accuracy.md
new file mode 100644
index 00000000..67a01d57
--- /dev/null
+++ b/wiki/concepts/Sociological-Accuracy.md
@@ -0,0 +1,38 @@
+---
+title: "Sociological Accuracy"
+type: concept
+tags: []
+last_updated: 2026-05-15
+---
+
+## Definition
+
+Sociological Accuracy（社会学准确性）——AI 生成内容评估中超越技术保真度的维度。Inclusive Visuals Specialist 的核心评估原则：AI 输出不仅要在技术上正确（光照、构图、解剖结构），还要在社会学意义上准确——被描绘社区的用户能够认出该资产为真实、有尊严且符合其现实特定 representation。
+
+## vs. Technical Fidelity
+
+| Dimension | Technical Fidelity | Sociological Accuracy |
+|-----------|-------------------|----------------------|
+| Focus | 物理正确性（光照/几何/颜色） | 社会可识别性（社区认同） |
+| Evaluator | 技术 QA 人员 | 目标社区成员 |
+| Standard | 像素级正确 | 情感共鸣正确 |
+| Feedback Loop | 人工修正 | 社区验证 |
+
+## Practical Application
+
+Inclusive Visuals Specialist 四阶段工作流中的 Review Gate（阶段4）：
+- 7-Point QA Checklist 中包含社区感知验证
+- 确保"Representation Accuracy: 0% reliance on stereotypical archetypes"
+- "Community Validation: 确保被描绘社区的用户会认可该资产为真实、有尊严和特定于其现实的"
+
+## Related Concepts
+
+- [[Cultural Authenticity]]
+- [[Intersectionality]]
+- [[Negative Prompting]]
+- [[Inclusive Visuals Specialist]]
+
+## Aliases
+
+- 社会可识别性
+- 社区感知验证
diff --git a/wiki/concepts/Spatial-Psychology.md b/wiki/concepts/Spatial-Psychology.md
index 6c52a970..2c0ff9b4 100644
--- a/wiki/concepts/Spatial-Psychology.md
+++ b/wiki/concepts/Spatial-Psychology.md
@@ -1,40 +1,69 @@
 ---
 title: "Spatial Psychology"
 type: concept
-tags: []
-last_updated: 2026-04-26
+tags: ["game-design", "level-design", "player-psychology", "environmental-design", "ux"]
+sources: ["level-designer.md"]
+last_updated: 2026-05-07
 ---
 
 ## Definition
 
-空间心理学（Spatial Psychology）是将人类对空间的先天感知规律应用于游戏关卡设计的学科。通过理解玩家如何在空间中定位、感受安全或危险，设计者可以创造直觉上可读且情感上有效的环境。
+Spatial Psychology（空间心理学）研究人类如何感知和响应物理空间，并将其原理应用于游戏关卡设计——使玩家在特定空间产生预期的情感反应（安全感、压迫感、好奇心、紧张感）。核心理念：**空间形状、光照和视线控制直接驱动玩家的情感状态和决策行为**。
 
 ## Core Theories
 
 ### Prospect-Refuge Theory（前景-庇护理论）
-- 玩家在拥有俯瞰位置且背后有保护时感到安全
-- 设计原则：提供高处的观察位置（prospect）和受保护的背部（refuge）
+源自 Jay Appleton 的地理心理学理论：
+- **Prospect（前景）**：开阔的视野使玩家感到掌控和自由
+- **Refuge（庇护）**：受保护的背部位置使玩家感到安全
+- **应用**：玩家在高处拥有俯瞰位置且背部受保护时感到最安全——这是最佳防守/观察点
+- **设计规则**：关键防守位置应有庇护后盾（墙壁/掩体）和开阔前方视野
 
 ### Figure-Ground Contrast（图底对比）
-- 目标必须在视觉上从背景中突显
-- 通过色彩、亮度或几何形状差异创造视觉层次
+建筑学概念：使目标从背景中视觉突出：
+- 通过色彩对比（暖色目标 vs. 冷色背景）
+- 通过亮度对比（发光目标 vs. 阴影背景）
+- 通过尺寸对比（大目标 vs. 小背景元素）
+- **应用**：出口、目标道具、敌人应从环境中视觉突出
 
-### Kevin Lynch's Urban Design Principles
-城市设计五要素应用于游戏空间：
-1. **Paths（路径）**：玩家穿行的主动线
-2. **Edges（边界）**：空间分界线（墙、围栏、水体）
-3. **Districts（区域）**：具有统一特征的功能分区
-4. **Nodes（节点）**：路径交汇点（高密度决策点）
-5. **Landmarks（地标）**：视觉锚点，远距离可识别
+### Kevin Lynch Urban Design（Kevin Lynch 城市设计五要素）
+城市设计理论应用于游戏空间：
 
-### Forced Perspective（强制透视）
-- 利用视觉错觉操纵玩家对距离和规模的感知
-- 可以让狭小空间显得宏大，或让遥远目标显得可及
+| 要素 | 定义 | 游戏应用 |
+|------|------|---------|
+| **Paths（路径）** | 玩家移动的通道 | 主要走廊、通道、桥梁 |
+| **Edges（边缘）** | 空间边界 | 墙壁、悬崖、栅栏 |
+| **Districts（区域）** | 均质性空间区域 | 房间、区块、区域 |
+| **Nodes（节点）** | 战略汇聚点 | 十字路口、房间入口 |
+| **Landmarks（地标）** | 外部参考点 | 高塔、发光建筑、独特地形 |
 
-## Related Concepts
-- [[Flow And Readability]]：Spatial Psychology 支撑路径可读性
-- [[Environmental Storytelling]]：空间感知是叙事体验的基础
-- [[Level Designer Agent Personality]]：Spatial Psychology 是 Level Designer 的高级能力
+### Forced Perspective（强迫透视）
+利用透视错觉操控玩家对距离和规模的感知：
+- 让窄通道看起来比实际更长
+- 让小房间看起来比实际更大
+- 让远距离目标看起来可及
 
-## Sources
-- [[Level Designer Agent Personality]]
+## Design Applications
+
+### Creating Tension
+- 低天花板 + 窄通道 → 幽闭恐惧感
+- 视线遮蔽 + 声音暗示 → 未知威胁感
+- 孤立空间（无庇护）→ 暴露脆弱感
+
+### Creating Safety
+- 高天花板 + 开阔视野 → 释放感
+- 角落位置（两侧庇护）→ 防守优势感
+- 明亮出口可见 → 目标明确感
+
+### Guiding Attention
+- 光线引导（明暗对比）→ 视觉引导
+- 色彩对比 → 重要道具突出
+- 动线设计（地面标记、道具引导）→ 行为引导
+
+## Connections
+
+- [[Level Designer]] 应用 Spatial Psychology 原理设计每个关卡
+- [[Encounter Design]] 中撤退位置设计依赖 Prospect-Refuge 理论
+- [[Navigation Affordance]] 应用 Figure-Ground Contrast 使关键路径视觉突出
+- [[Environmental Storytelling]] 应用空间几何传达情感信息
+- [[Temptation Design]] 应用 Kevin Lynch 的 Node 和 Landmark 要素标记奖励位置
diff --git a/wiki/concepts/SpatialAIOps.md b/wiki/concepts/SpatialAIOps.md
index c68e6381..cb12c935 100644
--- a/wiki/concepts/SpatialAIOps.md
+++ b/wiki/concepts/SpatialAIOps.md
@@ -1,47 +1,43 @@
 ---
 title: "SpatialAIOps"
 type: concept
-tags: [spatial-computing, ai-operations, product-strategy, spatial-ai]
+tags: []
 last_updated: 2026-03-05
 ---
 
 ## Definition
 
-Spatial AI Operations（空间AI运营）——将空间计算引入 AI Agent 编排和监控的全新产品品类。Nexus Spatial 创造性定义了此品类，而非在已有的 AI 可观测性仪表板赛道竞争。
+SpatialAIOps（空间 AI 运维）是一个由 [[nexus-spatial-discovery]] 定义的新产品品类——将空间计算（Spatial Computing）引入 AI Agent 工作流编排与运维监控，以沉浸式 3D 命令中心替代传统的平面 2D 仪表盘。
 
-核心价值主张：将监控从"阅读仪表板"转变为"身临其境你的基础设施"。
+## Core Principle
 
-## Core Characteristics
+> "Spatial computing transforms monitoring from reading dashboards to inhabiting your infrastructure."
 
-- **Immersive monitoring**：通过空间界面实时监控 AI Agent 执行，而非 2D 图表/日志
-- **3D orchestration**：通过 3D 节点图构建和编排 Agent 工作流
-- **Spatial collaboration**：团队进入共享 3D 空间协作进行事故响应
-- **Debugging overlay**：运行时追踪叠加于工作流结构的 3D 可视化调试
+核心价值主张：用户不是"阅读"数据，而是"居住"在数据空间中——以身临其境的 3D 交互方式感知、理解和操控复杂的 AI Agent 工作流。
 
-## Market Context
+## Key Dimensions
 
-由 [[nexus-spatial-discovery]] 中的 [[Product-Trend-Researcher]] 和 [[Brand-Guardian]] 共同验证：
+| 维度 | 2D 仪表盘 | SpatialAIOps |
+|------|-----------|-------------|
+| 监控方式 | 阅读抽象图表 | 空间沉浸式感知 |
+| 交互模式 | 点击、滚动 | 手势、注视、语音 |
+| 信息密度 | 受屏幕限制 | 多深度层次并行展示 |
+| 协作方式 | 截图+讨论 | 共享 3D 空间实时协作 |
+| 调试效率 | 平均 45 分钟 | 目标 < 10 分钟 |
 
-- AI 编排工具市场：$13.5B（22.3% CAGR）
-- 空间计算市场：$170-220B
-- **gap**：现有产品要么是空间型但非 AI，要么是 AI 型但仅 2D
+## Sub-Concepts
 
-## Canonical Use Case
+- [[Command-Theater]]：空间界面布局架构
+- [[4-Level-Semantic-Zoom]]：四层级语义缩放导航范式
+- [[2D-First-Spatial-Second]]：渐进式空间复杂度策略
 
-Nexus Spatial 的产品定位：AI Agent 沉浸式 3D 命令中心
-- 3D 节点图可视化 Agent 管道
-- 实时监控空间面板
-- 3D 空间拖放构建工作流
-- 共享空间协作
+## Related Products
 
-## Related Concepts
+- [[Nexus Spatial]]：SpatialAIOps 概念的落地产品
 
-- [[Spatial-Computing]]：底层空间计算技术基础
-- [[WebXR]]：SpatialAIOps 的主要分发平台
-- [[Command-Theater-Interface]]：SpatialAIOps 的核心界面模式
-- [[Debugging-Visualization]]：SpatialAIOps 的杀手级用例
-- [[Semantic-Zoom]]：SpatialAIOps 的导航范式
+## Connections
 
-## Contradictions
-
-- 与传统 [[Multi-Agent-System-Reliability]] 的监控方法：后者依赖日志/追踪面板，前者通过空间叠加提供直观可穿戴的监控体验
+- [[Multi-Agent-System-Reliability]] ← 应用场景
+- [[Spatial-Computing]] ← 技术基础
+- [[Command-Theater]] ← 界面架构
+- [[4-Level-Semantic-Zoom]] ← 导航范式
diff --git a/wiki/concepts/SpeakerDiarization.md b/wiki/concepts/SpeakerDiarization.md
new file mode 100644
index 00000000..8b5f5c4e
--- /dev/null
+++ b/wiki/concepts/SpeakerDiarization.md
@@ -0,0 +1,43 @@
+---
+title: "SpeakerDiarization"
+type: concept
+tags: ["voice-ai", "speech-processing", "speaker-attribution"]
+last_updated: 2026-05-02
+---
+
+# SpeakerDiarization（说话人分离）
+
+## Definition
+
+Speaker Diarization（说话人分离）是自动识别音频中"谁在说话、何时说话"的技术。通过声纹特征聚类将连续音频划分为不同说话人的片段，并为每个片段标注说话人标签（`SPEAKER_00`, `SPEAKER_01` 等）。
+
+## Key Properties
+
+- **主流工具**：`pyannote.audio`（开源）、AssemblyAI 内置、Deepgram 内置
+- **输入**：原始音频（或已切块的音频）
+- **输出**：`[{start, end, speaker}]` 格式的说话人片段列表
+- **准确度影响因素**：说话人数已知 vs 未知（已知可显著提高准确度）、音频质量、重叠语音
+- **与转录的集成**：分离结果通过时间重叠与转录段落合并，产生 `TranscriptSegment`（带 speaker 标签）
+
+## Pipeline Role
+
+```
+音频 → pyannote.audio → 说话人片段
+                          ↓ 合并（时间重叠匹配）
+        FasterWhisper → 转录段落
+                          ↓
+              带说话人归属的转录段落
+```
+
+## Related Concepts
+- [[VoiceActivityDetection]] — Diarization 的前置处理
+- [[StructuredTranscriptJSON]] — Diarization 结果的输出目标
+- [[LLMHandoff]] — 带说话人归属的转录文本下游传递给 LLM
+
+## Related Entities
+- [[pyannote.audio]] — 主要开源 Diarization 工具
+- [[AssemblyAI]] — 带 Diarization 的云端 ASR 替代方案
+- [[Deepgram]] — 带 Diarization 的另一云端 ASR 选项
+
+## Related Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/concepts/Sprint-Contract.md b/wiki/concepts/Sprint-Contract.md
new file mode 100644
index 00000000..bc53efe8
--- /dev/null
+++ b/wiki/concepts/Sprint-Contract.md
@@ -0,0 +1,49 @@
+---
+title: "Sprint Contract"
+type: concept
+tags:
+  - "harness-engineering"
+  - "agentic-ai"
+  - "evaluation"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+Sprint Contract——Generator Agent 和独立 Evaluator Agent 在工作开始前约定的可测试"完成"定义，通过角色分离打破 [[Self-Grading-Illusion]] 的结构性缺陷。
+
+## Problem It Solves
+[[Self-Grading-Illusion]]：LLM 无法可靠评估自身输出——同一权重生成又评判，结构性盲点无法自我修正。
+
+## Mechanism
+
+### Before Work Begins
+Generator Agent 和独立 Evaluator Agent 协商具体的、可测试的"完成"定义，写入 Sprint Contract：
+```
+Sprint Contract for: Market Research Report
+- Output: JSON with fields {competitor_name, pricing: {amount: float, currency: string}, source_url}
+- Required: all fields present, amount > 0, currency in [USD, EUR, GBP]
+- Evaluator action: fetch source_url, verify pricing matches
+```
+
+### Two Non-Negotiable Rules
+
+**Rule 1: Evaluator 必须执行**
+Evaluator 必须**运行**代码、在 headless 浏览器验证界面、或对比 schema——不只是读原始文本然后评判。
+> 验证不能被伪造，这是唯一算数的验证。
+
+**Rule 2: Evaluator 操作于干净上下文**
+Evaluator 必须在干净上下文中操作，不读 Generator 的推理链。
+如果 Evaluator 读取了 Generator 的完整思维链，它继承了 Generator 的假设和盲点——这破坏了独立审查的整个目的。
+> 给 Evaluator 的信息：输出 + 成功标准，**无其他**。
+
+## Relationship to [[Harness-Engineering]]
+Sprint Contract 是 [[7-Layer-Harness-Stack]] 第 6 层（Evaluation & Observation）的核心机制——它是 Evaluator 层分离职责的具体实现。
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
+
+## See Also
+- [[Self-Grading-Illusion]] — 它解决的问题
+- [[7-Layer-Harness-Stack]] — 层次定位
diff --git a/wiki/concepts/State-Externalization.md b/wiki/concepts/State-Externalization.md
new file mode 100644
index 00000000..4e5f155b
--- /dev/null
+++ b/wiki/concepts/State-Externalization.md
@@ -0,0 +1,53 @@
+---
+title: "State Externalization"
+type: concept
+tags:
+  - "harness-engineering"
+  - "agentic-ai"
+  - "memory"
+sources:
+  - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
+last_updated: 2026-04-20
+---
+
+## Overview
+State Externalization——将任务状态（pending/in-progress/completed）写入磁盘文件而非仅保存在 context window 的工程实践，是 [[Harness-Engineering]] 第二原则的具体实现。
+
+## Core Principle
+> 如果一条信息对任务连续性重要——已完成什么、待处理什么、什么失败了——它必须存在于 context window 之外。
+>
+> Context window 是易失的。磁盘文件是持久的。
+
+## Two-Tier Memory Model
+
+### Working Memory (Short-term)
+当前步骤所需的即时对话和 context window。
+
+### Persistent State (Long-term)
+结构化文件（如 `state.json`）追踪精确的子任务状态：
+```json
+{
+  "task_id": "market-research-report",
+  "steps": {
+    "fetch_competitor_a": "COMPLETED",
+    "fetch_competitor_b": "COMPLETED",
+    "fetch_competitor_c": "FAILED",
+    "compare": "PENDING"
+  },
+  "last_updated": "2026-04-20T10:30:00Z"
+}
+```
+
+## Why It Matters
+- Context window 在每次新 LLM 调用时重置
+- 状态不外部化 → 每次重置都丢失进度
+- 进程崩溃 → 整个任务从头开始
+
+## [[Context-Reset]] Integration
+State Externalization 是 [[Context-Reset]] 的前提——必须先有可写磁盘的状态文件，才能实现有意义的 Context Reset。
+
+## [[Memory-Consolidation]] Integration
+State Externalization 写入的是原始状态，[[Memory-Consolidation]] 定期压缩这些状态防止膨胀。
+
+## Source
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
diff --git a/wiki/concepts/Statistical-Analysis.md b/wiki/concepts/Statistical-Analysis.md
new file mode 100644
index 00000000..cb7a197b
--- /dev/null
+++ b/wiki/concepts/Statistical-Analysis.md
@@ -0,0 +1,58 @@
+---
+title: "Statistical Analysis"
+type: concept
+tags: [statistics, quality, data-science]
+sources: [testing-test-results-analyzer]
+last_updated: 2026-04-28
+---
+
+## Aliases
+- Statistical Methods
+- Quantitative Analysis
+- Confidence Interval Analysis
+
+## Definition
+
+统计分析——使用数学和统计方法从测试数据中提取洞察、验证假设、计算置信区间，确保所有结论有统计依据而非主观推断。
+
+## Core Methods (from TestResultsAnalyzer)
+
+```python
+import numpy as np
+from scipy import stats
+
+# 置信区间计算
+confidence_level = 0.95
+n = len(sample_data)
+mean = np.mean(sample_data)
+std_err = stats.sem(sample_data)
+ci = stats.t.interval(confidence_level, n-1, loc=mean, scale=std_err)
+
+# 假设检验
+t_stat, p_value = stats.ttest_ind(group_a, group_b)
+significant = p_value < 0.05
+
+# 相关性分析
+correlation, p_val = stats.pearsonr(x, y)
+```
+
+## Key Principles
+
+- **95% Confidence Level**：默认使用 95% 置信水平，所有结论必须报告置信区间。
+- **Statistical Significance Required**：相关性和差异分析必须伴随 p-value 检验。
+- **Cross-Validation**：重要结论需多数据源交叉验证。
+- **Methodology Documentation**：分析方法必须记录以确保可复现。
+
+## Key Rules (from TestResultsAnalyzer)
+
+> "Always use statistical methods to validate conclusions and recommendations"
+> "Provide confidence intervals and statistical significance for all quality claims"
+> "Base recommendations on quantifiable evidence rather than assumptions"
+
+## Connections
+
+- [[Quality-Metrics]]：统计方法是质量指标计算的基础。
+- [[Failure-Pattern-Analysis]]：失败模式识别依赖统计方法。
+- [[Defect-Prediction]]：预测模型需要统计验证。
+- [[Release-Readiness-Assessment]]：发布决策依赖统计置信度。
+- [[Quality-ROI-Analysis]]：ROI 计算需要统计方法。
diff --git a/wiki/concepts/Strategic-Portfolio-Management.md b/wiki/concepts/Strategic-Portfolio-Management.md
index 1527a886..ee5eaa0e 100644
--- a/wiki/concepts/Strategic-Portfolio-Management.md
+++ b/wiki/concepts/Strategic-Portfolio-Management.md
@@ -1,35 +1,60 @@
----
-title: "Strategic Portfolio Management"
-type: concept
-tags: []
-sources: []
-last_updated: 2026-04-25
----
-
-## Definition
-
-Strategic Portfolio Management（战略组合管理）是通过系统化方法管理多个相互关联的项目组合，以实现组织级商业目标的最大化。核心在于在组合层面进行资源优化配置、风险平衡和优先级排序，而非单个项目管理。
-
-## Core Components
-
-- **Portfolio Definition**：识别和定义组合的范围、边界和成员项目
-- **Strategic Alignment**：确保组合中所有项目与组织战略目标一致
-- **Resource Optimization**：跨项目分配有限资源，最大化整体 ROI
-- **Risk Balancing**：在创新项目与已验证项目之间平衡风险敞口
-- **Performance Monitoring**：组合层面的 KPI 追踪（Portfolio ROI、按时交付率）
-- **Governance**：定期 Portfolio Review 和战略调整机制
-
-## Relationship to Single Project Management
-
-| Dimension | Single Project Management | Strategic Portfolio Management |
-|-----------|-------------------------|-------------------------------|
-| Scope | 单个项目 | 多个相关项目的集合 |
-| Objective | 项目交付成功 | 组织战略目标实现 |
-| Time Horizon | 项目生命周期 | 持续、跨项目周期 |
-| Decision Maker | Project Manager | Executive/Portfolio Manager |
-| Success Metric | 铁三角（范围/时间/成本） | Portfolio ROI ≥ 25%，95% 按时交付 |
-
-## Aliases
-- Portfolio Management
-- Project Portfolio Management
-- Strategic Portfolio Governance
+---
+title: "Strategic Portfolio Management"
+type: concept
+tags: ["project-management", "strategic-leadership", "portfolio", "agency-agents"]
+last_updated: 2026-04-30
+---
+
+## Definition
+
+Strategic Portfolio Management（战略组合管理）是指在组织层面协调和优化多个项目组合，以实现整体业务目标和最大化投资回报的管理方法论。与单项目管理不同，Portfolio Management 关注的是跨项目的资源分配、优先级排序和风险平衡。
+
+## Core Framework
+
+### Tiered Portfolio Structure
+- **Tier 1（战略优先级）**：高价值、高战略影响的核心项目——预算充足、优先配置资源、严格监控 ROI
+- **Tier 2（增长举措）**：市场扩展和新业务机会相关项目——中等投资、风险可控、与战略目标对齐
+- **Innovation Pipeline（创新管道）**：实验性举措和技术能力研发——小规模投资、允许失败、以学习为目标
+
+### Key Metrics
+| 指标 | 目标值 | 说明 |
+|------|--------|------|
+| Portfolio ROI | ≥ 25% | 组合层面整体投资回报率 |
+| On-time Delivery | ≥ 95% | 按时交付率 |
+| Client Satisfaction | ≥ 4.8/5 | 战略客户服务评分 |
+| Market Ranking | Top 3 | 目标市场排名前三 |
+
+## Four-Stage Workflow
+
+### Step 1: Strategic Planning & Vision Setting
+- 分析市场机会和竞争格局，制定战略定位
+- 制定与业务目标和品牌战略对齐的创意愿景
+- 规划资源容量和能力发展计划
+- 确立投资组合优先级和分配框架
+
+### Step 2: Project Portfolio Orchestration
+- 协调多个具有复杂依赖关系的高价值项目
+- 促进跨职能团队组建和战略对齐
+- 管理高管利益相关者沟通和期望设定
+- 监控投资组合健康状态，实施战略调整
+
+### Step 3: Leadership & Team Development
+- 为项目团队提供创意方向和战略指导
+- 培养关键团队成员的领导力和职业成长
+- 在整个组织中培育创新文化和创意卓越
+- 建立战略伙伴关系和外部关系网络
+
+### Step 4: Performance Management & Strategic Optimization
+- 跟踪投资组合 ROI 和业务影响
+- 分析市场表现和竞争定位进展
+- 优化跨项目的资源分配和流程效率
+- 规划未来增长的战略演进和能力发展
+
+## Related Concepts
+- [[Resource Allocation Strategy]]：跨项目优先级的资源配置方法论
+- [[ROI Optimization]]：通过绩效跟踪实现 25%+ 投资回报的优化机制
+- [[Multi-Project Orchestration]]：协调多个并发项目的复杂依赖和沟通
+- [[Stakeholder Management]]：高管级别利益相关者关系管理
+
+## Source
+- [[project-management-studio-producer]]
diff --git a/wiki/concepts/StrategicStorytelling.md b/wiki/concepts/StrategicStorytelling.md
new file mode 100644
index 00000000..a1e20abd
--- /dev/null
+++ b/wiki/concepts/StrategicStorytelling.md
@@ -0,0 +1,32 @@
+---
+title: "Strategic Storytelling"
+type: concept
+tags: ["communication", "consulting", "business"]
+sources: ["support-executive-summary-generator"]
+last_updated: 2026-04-26
+---
+
+## Definition
+战略叙事是通过结构化叙事结构（特别是 SCQA 框架）将复杂业务发现转化为引人入胜、易于决策的故事，从而驱动紧迫感和行动的方法论。
+
+## Core Framework: SCQA
+1. **Situation（情境）**：建立背景和上下文
+2. **Complication（复杂化）**：识别挑战或障碍
+3. **Question（问题）**：提出关键决策问题
+4. **Answer（答案）**：给出行动导向的回答
+
+## Key Techniques
+- **金字塔原理**：先说结论（最重要），再提供支撑细节
+- **量化叙事**：每个故事点含量化数据
+- **行动导向**：每个叙事最终指向可执行建议
+- **受众视角**：始终以 C-suite 决策者视角叙事
+
+## Role in Executive Communication
+- 让高管在 3 分钟内理解复杂问题
+- 建立紧迫感，驱动决策行动
+- 连接数据发现与业务影响
+
+## Related Concepts
+- [[SCQA Framework]]
+- [[Pyramid Principle]]
+- [[Executive Summary]]
diff --git a/wiki/concepts/Structuralism.md b/wiki/concepts/Structuralism.md
new file mode 100644
index 00000000..e92d6964
--- /dev/null
+++ b/wiki/concepts/Structuralism.md
@@ -0,0 +1,23 @@
+---
+title: "Structuralism"
+type: concept
+tags: ["anthropology", "structuralism", "mythology", "binary-opposition", "levi-strauss"]
+last_updated: 2026-04-25
+---
+
+## Definition
+结构主义——通过识别文化系统中的深层**二元对立**（binary oppositions）结构来解释神话、亲属制度和社会分类的分析框架。由 Claude Levi-Strauss 创立。
+
+## Core Framework
+- **二元对立**：文化思维通过成对的概念组织（自然/文化、生/熟、男/女、洁净/污染）
+- **变换（Transformation）**：同一深层结构通过不同变换产生表层差异（如不同文化的婚礼仪式）
+- **神话素（Mytheme）**：神话的最小叙事单元，按邻接关系而非时间顺序组合
+
+## Key Thinkers
+- [[Claude-Levi-Strauss]]（创始人）
+- [[Mary-Douglas]]（分类系统分析）
+
+## Connections
+- [[Anthropologist-Agent]] ← uses_framework ← [[Structuralism]]
+- [[Symbolic-Anthropology]] ← related_to ← [[Structuralism]]
+- [[Kinship-System]] ← analyzes ← [[Structuralism]]
diff --git a/wiki/concepts/StructuredTranscriptJSON.md b/wiki/concepts/StructuredTranscriptJSON.md
new file mode 100644
index 00000000..2e294d50
--- /dev/null
+++ b/wiki/concepts/StructuredTranscriptJSON.md
@@ -0,0 +1,70 @@
+---
+title: "StructuredTranscriptJSON"
+type: concept
+tags: ["voice-ai", "transcription", "json-schema", "interoperability"]
+last_updated: 2026-05-02
+---
+
+# StructuredTranscriptJSON（结构化转录 JSON）
+
+## Definition
+
+Structured Transcript JSON 是转录管道输出的稳定 Schema JSON 格式，包含分段时间戳、说话人标签、置信度分数、完整文本和元数据。设计原则：**添加字段，永不删除或重命名**——下游消费者（CMS、LLM Agent、CI 工具）依赖 Schema 稳定性。
+
+## Schema Design
+
+```json
+{
+  "schema_version": "1.0",
+  "metadata": {
+    "source_file": "...",
+    "duration": 3600.5,
+    "language": "en",
+    "transcription_date": "2026-05-02"
+  },
+  "segments": [
+    {
+      "index": 0,
+      "start": 0.0,
+      "end": 5.2,
+      "duration": 5.2,
+      "speaker": "SPEAKER_00",
+      "text": "Hello, welcome to the meeting.",
+      "confidence": -0.31
+    }
+  ],
+  "full_text": "Hello, welcome to the meeting...",
+  "speakers": ["SPEAKER_00", "SPEAKER_01"],
+  "total_duration": 3600.5
+}
+```
+
+## Schema Versioning Rules
+
+- **向后兼容**：新增字段是安全的（消费者忽略未知字段）
+- **破坏性变更**：删除/重命名字段 = 破坏所有消费者 = 必须 major 版本升级
+- **版本声明**：每个文档必须包含 `schema_version` 字段
+
+## Output Format Variants
+
+| 格式 | 用途 | 包含内容 |
+|------|------|---------|
+| JSON | LLM Agent、CMS API | 全量结构（含时间戳、说话人、置信度） |
+| SRT | 字幕文件、视频嵌入 | 时间戳 + 说话人前缀 + 文本 |
+| VTT | Web 字幕 | 时间戳 + 说话人前缀 + 文本（WebVTT 格式） |
+| TXT | 快速查阅 | 纯文本，无元数据 |
+
+## Downstream Consumers
+
+- [[LangChain]] / CrewAI：JSON 作为 `Document` 或 `Conversation` 输入
+- CMS（Drupal/WordPress）：JSON 存储为 `field_transcript_json`，`full_text` 存储为正文
+- GitHub Actions：JSON 作为 CI artifact，触发后续处理流水线
+- [[LLMHandoff]]：将 JSON 中的 `segments` 格式化为带时间戳的文本行用于 LLM 摘要/问答
+
+## Related Concepts
+- [[PIIRedaction]] — 输出前的 PII 脱敏
+- [[SpeakerDiarization]] — `speaker` 字段的数据来源
+- [[LLMHandoff]] — 消费 Structured JSON 的标准接口
+
+## Related Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/concepts/StyleLock.md b/wiki/concepts/StyleLock.md
new file mode 100644
index 00000000..ed303473
--- /dev/null
+++ b/wiki/concepts/StyleLock.md
@@ -0,0 +1,58 @@
+---
+title: "StyleLock"
+type: concept
+tags: ["prompt-engineering", "ai-image", "consistency", "quality-control"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Style Lock（风格锁定块）是 AI 图片生成质量控制机制——在每个提示词末尾加强制的风格比对检查清单，要求在生成前逐项验证与上一张图片的风格参数是否完全匹配，偏差即触发重生成。
+
+## Mechanism
+
+Style Lock 通过以下方式工作：
+
+1. **复制前一张图片的完整 Style Seed**
+2. **添加逐项检查清单**（Checklist），要求生成前验证每个风格参数
+3. **强化约束指令**：If ANY element does not match, regenerate with corrections
+4. **视觉反馈**：通过 hex 色值、纹理描述、线条质量等具体参数减少模糊性
+
+## Sample Template
+
+```markdown
+== STYLE LOCK — MANDATORY ==
+
+This card MUST follow the EXACT same chalkboard style as the 
+previously generated card. Do not deviate.
+
+Checklist — verify these match the previous card BEFORE generating:
+□ Background color: #1C2B1C (dark green-black chalkboard)
+□ Chalk texture: subtle scratches, dust, eraser smudges
+□ Line quality: hand-drawn, imperfect, sketchy wobble — NO perfect vectors
+□ Color hex values: #F5F5F5 (white), #FFE566 (yellow), ...
+□ Frame: wooden border with hand-drawn wood grain
+□ Doodles: stars, underlines, arrows, circles — all chalk-drawn
+□ Typography: chalk lettering, imperfect baseline
+
+If ANY element does not match, regenerate with corrections.
+```
+
+## Consistency Rating
+
+| Method | Consistency | Complexity |
+|--------|-------------|------------|
+| Style Seed only | ★★★★☆ | Low |
+| Style Seed + Style Lock | ★★★★★ | Medium-High |
+| Reference Image + Style Lock | ★★★★★ | Medium |
+| All methods combined | ★★★★★ | Medium-High |
+
+## Relationship to Style Seed
+
+- [[StyleSeed]]：定义风格参数（正面锚定）
+- [[StyleLock]]：强制比对上一张参数（反向验证）
+- 两者组合使用：开头用 Style Seed 锚定正面目标，末尾用 Style Lock 验证反面偏差
+
+## Sources
+
+- [[如何让AI生成风格一致的图片]]
diff --git a/wiki/concepts/StyleSeed.md b/wiki/concepts/StyleSeed.md
new file mode 100644
index 00000000..ab51305d
--- /dev/null
+++ b/wiki/concepts/StyleSeed.md
@@ -0,0 +1,47 @@
+---
+title: "StyleSeed"
+type: concept
+tags: ["prompt-engineering", "ai-image", "consistency"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+风格种子句（Style Seed）是 AI 图片生成中用于锚定视觉风格基线的标准化文本块——在每个提示词开头加入完全相同的风格定义句，确保多张图片共享统一的视觉参数。
+
+## Core Parameters
+
+一个完整的 Style Seed 包含以下维度：
+
+| 维度 | 示例 |
+|------|------|
+| 背景色/纹理 | dark green-black chalkboard (#1C2B1C) |
+| 线条质量 | hand-drawn, imperfect, sketchy wobble |
+| 配色方案 | 6 色严格限制（白/黄/粉/蓝/绿/橙） |
+| 边框样式 | wooden frame border with chalk dust |
+| 禁止项 | NO gradients, NO perfect geometric shapes |
+
+## Usage Pattern
+
+```markdown
+== STYLE SEED — MANDATORY ==
+
+[Background description]
+[Line quality requirements]
+[Color palette with hex values]
+[Frame/border specification]
+[Prohibited elements list]
+
+[CONTENT]
+[Your specific content here]
+```
+
+## Related Concepts
+
+- [[StyleLock]]：在 Style Seed 基础上，通过逐项检查清单强制比对上一张图片的风格参数
+- [[PromptEngineering]]：Style Seed 是 Prompt Engineering 在视觉一致性领域的具体应用
+- [[ReferenceImageConsistency]]：最强一致性方法，用第一张生成的图片作为后续图片的视觉基准
+
+## Sources
+
+- [[如何让AI生成风格一致的图片]]
diff --git a/wiki/concepts/Subjunctive-Mood.md b/wiki/concepts/Subjunctive-Mood.md
new file mode 100644
index 00000000..073835cf
--- /dev/null
+++ b/wiki/concepts/Subjunctive-Mood.md
@@ -0,0 +1,53 @@
+---
+title: "Subjunctive Mood"
+type: concept
+tags: ["spanish", "linguistics", "grammar", "translation", "conjugation"]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+**Subjunctive Mood**（虚拟式/虚拟语气）是西班牙语中用于表达愿望、怀疑、情感、假设和主观意见的动词形式，与陈述式（indicative）相对。虚拟式的正确使用是区分高级西班牙语学习者的关键标志。
+
+## When to Use (Spanish)
+
+| 场景 | 标志词/结构 | 例句 |
+|---|---|---|
+| **愿望** | querer que, esperar que, desear | Quiero que vengas.（我希望你过来。） |
+| **怀疑** | dudar que, no creer que | Dudo que llegue a tiempo.（我怀疑他能否准时到达。） |
+| **情感** | me gusta que, me alegro de que | Me alegra que estés aquí.（我很高兴你在这里。） |
+| **假设/条件** | si（虚拟式从句） | Si tuviera dinero, viajaría.（要是我有钱，我就去旅行。） |
+| **目的** | para que, a fin de que | Te lo digo para que lo sepas.（我告诉你为了让你知道。） |
+| **观点** | creer（否定/疑问） | No creo que sea verdad.（我不认为那是真的。） |
+
+## Common Errors for Non-Native Speakers
+
+- ❌ "Quiero que vienes"（缺少虚拟式）
+- ✅ "Quiero que vengas"（正确：vengas 而非 vienes）
+- ❌ "Espero que él sabe"（缺少虚拟式）
+- ✅ "Espero que él sepa"（正确：sepa 而非 sabe）
+
+## In Translation
+
+[[Language Translator]] Agent 在翻译时：
+1. 检测何时源语言隐含主观/情感/愿望含义
+2. 在西班牙语输出中正确使用虚拟式动词变位
+3. 向用户解释为什么需要虚拟式（适合教学场景）
+
+## Key Conjugations (AR verbs, present subjunctive)
+
+| 主语 | -AR 动词 | 例：hablar |
+|---|---|---|
+| yo | -e | hable |
+| tú | -es | hables |
+| él/ella/usted | -e | hable |
+| nosotros | -emos | hablemos |
+| vosotros | -éis | habléis |
+| ellos/ustedes | -en | hablen |
+
+## Related Concepts
+- [[Meaning Transfer Translation]]：虚拟式是意义传递中不可忽略的语法要素
+- [[Ser vs Estar]]：两个"to be"动词的选择与虚拟式有交叉场景
+
+## Sources
+- [[language-translator]]
diff --git a/wiki/concepts/Symbolic-Anthropology.md b/wiki/concepts/Symbolic-Anthropology.md
new file mode 100644
index 00000000..0828ac79
--- /dev/null
+++ b/wiki/concepts/Symbolic-Anthropology.md
@@ -0,0 +1,23 @@
+---
+title: "Symbolic Anthropology"
+type: concept
+tags: ["anthropology", "symbolic", "meaning", "interpretation", "geertz"]
+last_updated: 2026-04-25
+---
+
+## Definition
+符号人类学——将文化视为由象征符号构成的意义之网（web of significance），通过**厚描述**（thick description）理解文化参与者的主观意义，而非仅做外部观察的分析方法。
+
+## Core Framework
+- **厚描述（Thick Description）**：在多层次语境中解读行为——同样抽动眼皮的肌肉运动，在不同社会语境中可以是无意动作、眨眼示意、模仿眨眼、或模仿模仿眨眼，意义完全不同
+- **文化作为文本**：文化实践像文本一样可以被"阅读"，其意义需要从参与者视角理解
+- **符号的多义性**：文化符号通常有多个重叠的编码层次
+
+## Key Thinkers
+- [[Clifford-Geertz]]（创始人）
+- [[Victor-Turner]]（仪式符号分析）
+
+## Connections
+- [[Anthropologist-Agent]] ← uses_framework ← [[Symbolic-Anthropology]]
+- [[Structuralism]] ← related_to ← [[Symbolic-Anthropology]]
+- [[Liminality]] ← provides_method ← [[Symbolic-Anthropology]]
diff --git a/wiki/concepts/System-Prompt-Layering.md b/wiki/concepts/System-Prompt-Layering.md
new file mode 100644
index 00000000..cc7a9da7
--- /dev/null
+++ b/wiki/concepts/System-Prompt-Layering.md
@@ -0,0 +1,35 @@
+---
+title: "System-Prompt-Layering"
+type: concept
+tags: []
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Definition
+System Prompt Layering 是一种前端提示词与 Agent 核心提示词分层叠加的机制，确保前端传入的提示词不会覆盖 Agent 原有的工具集和能力。
+
+## Mechanism
+当通过 API Server 调用 Hermes Agent 时：
+1. **基础层**：Agent 核心系统提示词（包含完整工具集、Skills、记忆配置）
+2. **叠加层**：前端传入的 system prompt（Chat Completions 的 `system` 消息，或 Responses API 的 `instructions` 字段）
+3. **结果**：两层提示词叠加，Agent 保留全部原生能力
+
+## Example
+```json
+// Chat Completions 请求
+{
+  "model": "hermes-agent",
+  "messages": [
+    {"role": "system", "content": "你是一个友好的助手"},  // 叠加层
+    {"role": "user", "content": "hello"}
+  ]
+}
+```
+
+## Key Benefit
+前端可以定制对话风格（如角色扮演、语气调整），同时不影响 Agent 的核心工具能力。
+
+## Related
+- [[OpenAI-Compatible-API]]
+- [[Conversation-State-Persistence]]
diff --git a/wiki/concepts/TCO.md b/wiki/concepts/TCO.md
index 5857f71f..51439cd6 100644
--- a/wiki/concepts/TCO.md
+++ b/wiki/concepts/TCO.md
@@ -10,6 +10,10 @@ tags:
 last_updated: 2026-05-07
 ---
 
+## Aliases
+- TCO（供应链场景）：采购总拥有成本
+- 全生命周期成本
+
 ## Total Cost of Ownership (TCO)
 
 A financial framework used to evaluate the total cost of acquiring, operating, and maintaining a technology solution over its entire lifecycle, compared across different deployment options.
@@ -37,10 +41,26 @@ TCO encompasses all direct and indirect costs associated with a technology inves
 - Cloud: OpEx model, pay-as-you-go, but egress costs and lock-in risks
 - Hybrid: Balances migration flexibility with gradual transition costs
 
-## Connections
-- [[VMware-Cloud-on-AWS]] ← evaluates ← [[TCO]] for cloud migration decisions
-- [[Cloud-Transformation]] ← uses ← [[TCO]] for business case justification
-- [[FinOps]] ← practices ← [[TCO]] analysis for cloud cost optimization
+## Supply Chain Procurement TCO
+[[Supply Chain Strategist Agent]] 使用 TCO 作为采购决策的核心依据，而非单一比较单价。
+
+### Cost Components in Procurement
+- **直接成本**：单价采购价、工装模具费、包装费、运输费
+- **间接成本**：检验费用、来料不良损失、库存持有成本、管理费用
+- **隐性成本**：供应商切换成本、质量风险成本、交付延误损失、协调开销
+- **全生命周期成本**：使用和维护成本、报废和回收成本、环保合规成本
+
+### Decision Principle
+> "While supplier C's unit price is 5% higher, their incoming defect rate is only 0.1%. Factoring in quality loss costs, their TCO is actually 3% lower." — [[Supply Chain Strategist Agent]]
+
+- 战略型物料（[[Kraljic Matrix]]）：TCO 评估尤为重要，需综合考量质量风险和供应稳定性
+- 采购决策必须综合考虑直接成本 + 间接成本 + 隐性成本，而非仅比较单价
+- 关键物料宁可接受更高单价，也要确保供应安全（TCO 中隐含供应中断成本）
+
+### Connections (Supply Chain)
+- [[Supply Chain Strategist Agent]] ← uses ← [[TCO]] for procurement decisions
+- [[Kraljic Matrix]] ← related_to ← [[TCO]]（战略型品类的 TCO 分析是核心）
 
 ## Sources
 - [[ctp-topic-43-vmware-cloud-on-aws]]
+- [[supply-chain-strategist]]
diff --git a/wiki/concepts/TJM.md b/wiki/concepts/TJM.md
new file mode 100644
index 00000000..ce538a69
--- /dev/null
+++ b/wiki/concepts/TJM.md
@@ -0,0 +1,96 @@
+---
+title: "TJM (Taux Journalier Moyen)"
+type: concept
+tags: []
+sources: [specialized-french-consulting-market]
+last_updated: 2026-04-25
+---
+
+# TJM (Taux Journalier Moyen)
+
+## Aliases
+- TJM
+- TJM Brut
+- Daily Rate
+- Taux Journalier
+- Journee Facturable
+
+## Definition
+
+TJM（Taux Journalier Moyen，平均日费率）是法语区 IT 咨询市场用于报价的标准单位，表示一名独立顾问每天（通常按 8 小时工作制）的服务价格。TJM 分为两个层次：
+
+- **TJM Brut**：发票上的总价（客户支付金额）
+- **TJM Net**：扣除所有中间费用（Portage/Micro-Entreprise/SASU 成本）后，顾问实际到手的金额
+
+## Why TJM Brut ≠ TJM Net
+
+这是法国咨询市场最核心的财务概念。TJM Brut 和 TJM Net 之间的差距由计费结构决定：
+
+### Portage Salarial（700 EUR TJM 示例）
+| 项目 | 金额 |
+|------|------|
+| TJM Brut | 700 EUR/天 |
+| 月收入（18天） | 12,600 EUR |
+| Portage 管理费（~10%） | -1,260 EUR |
+| 雇主社保（~45%） | -5,103 EUR |
+| 雇员社保（~22%） | -2,495 EUR |
+| **TJM Net（月）** | **3,742 EUR** |
+| **有效 TJM Net/天** | **~208 EUR/天** |
+
+### Micro-Entreprise（700 EUR TJM 示例）
+| 项目 | 金额 |
+|------|------|
+| TJM Brut | 700 EUR/天 |
+| 月收入（18天） | 12,600 EUR |
+| URSSAF（~22%） | -2,772 EUR |
+| **TJM Net（月）** | **9,828 EUR** |
+| **有效 TJM Net/天** | **~546 EUR/天** |
+
+**差距：338 EUR/天**（Portage 为社会保护付出的成本）
+
+## Critical Rules
+
+> "When discussing rates, always specify: gross daily rate (TJM brut), net after charges, and effective hourly rate after all deductions."
+
+1. **永远区分 Brut 和 Net**：客户听到 700 EUR/天，顾问实际到手可能只有 208 EUR（Portage）或 546 EUR（Micro）
+2. **Rate floor 很重要**：低于 550 EUR/天的 TJM 对高级 Salesforce Architect 来说永久锚定低价谈判起点
+3. **TJM 是谈判起点**：ESN 通常加价 40-70% 向客户报价
+
+## TJM Benchmarking by Specialization
+
+法国市场 TJM 区间（仅供参考，实际受经验、稀缺性、谈判能力影响）：
+
+| 技术方向 | 初级（<3年） | 中级（3-7年） | 高级（7-10年） | 专家级（>10年） |
+|---------|------------|-------------|--------------|---------------|
+| 通用 Java/.NET | 400-450 | 500-600 | 600-700 | 700-800 |
+| Salesforce Admin | 450-500 | 550-650 | 650-750 | 750-850 |
+| **Salesforce Data Cloud + Agentforce** | — | 650-750 | **750-900** | **850-1,000+** |
+| Cloud Architecture (AWS/GCP/Azure) | 450-550 | 600-700 | 700-850 | 800-950 |
+| DevSecOps | 450-500 | 550-650 | 650-800 | 750-900 |
+
+> "Generic 'Salesforce Architect' = commodity (550-650)" vs "Data Cloud + Agentforce Specialist = premium (700-850)"
+
+## Rate Negotiation Formula
+
+### Step 1: Calculate Your Floor
+```
+Minimum viable TJM = (Monthly expenses × 1.5) ÷ 18 billable days
+```
+
+### Step 2: Know the Sell Rate
+- ESN 以 TJM × 1.4-1.7 向客户报价
+- 如果知道客户预算，反向推算合理的 TJM
+
+### Step 3: Anchor High, Concede Strategically
+- 报价高于目标 15-20%，留出谈判空间
+- 仅在换取以下条件时让步：更长期限、更多远程天数、续约条款
+
+### Step 4: Frame Specialization Premium
+- 泛泛的"Salesforce 架构师"= 商品定价
+- "Data Cloud + Agentforce 专家"= 高端定价
+
+## Related Sources
+- [[specialized-french-consulting-market]]
+- [[Portage-Salarial]]
+- [[Micro-Entreprise]]
+- [[ESN-SI]]
diff --git a/wiki/concepts/TTT-Train-the-Trainer.md b/wiki/concepts/TTT-Train-the-Trainer.md
new file mode 100644
index 00000000..85cf813a
--- /dev/null
+++ b/wiki/concepts/TTT-Train-the-Trainer.md
@@ -0,0 +1,46 @@
+---
+title: "TTT (Train the Trainer)"
+type: concept
+tags: [internal-trainer, talent-development]
+sources: [corporate-training-designer]
+last_updated: 2026-05-29
+---
+
+## Definition
+
+TTT（Train the Trainer，内部讲师培养）是将组织内部员工培养为合格内部培训师的体系化方法，通过标准化筛选、培养、认证和激励机制，构建可持续的组织学习交付能力。
+
+## Core Components
+
+### 讲师选拔标准
+- 专业知识扎实
+- 乐于分享
+- 热爱教学
+- 具备基本的演讲表达能力
+
+### TTT 核心模块
+- 成人学习原理（Andragogy）：了解成人学习的特征（经验导向、自我导向、问题中心、实用主义）
+- 课程开发技巧：从需求分析到评估的全流程课程设计能力
+- 授课与演讲技巧：开场破冰、提问与引导技术、STAR 案例故事讲述法、时间管理、学员管理
+- 课件开发标准：统一视觉模板、内容结构规范（每张幻灯片一个核心观点）、多媒体素材规范
+
+### 讲师认证体系
+- 试讲评审 → 初级认证 → 高级认证 → 金牌讲师
+- 配套激励：课酬、荣誉认可、晋升加分
+
+### 讲师社群运营
+- 定期教学研讨会
+- 优秀课程展示
+- 跨部门交流
+- 外部学习资源共享
+
+## Value
+- 降低培训成本（减少外部讲师依赖）
+- 保留组织隐性知识（将专家经验萃取并传递）
+- 提升培训响应速度（内部讲师更了解业务情境）
+- 增强组织学习文化
+
+## Connections
+- [[TTT-Train-the-Trainer]] ← enables ← [[Corporate-Training-Designer]]（内部讲师是培训落地的关键交付者）
+- [[ADDIE-Model]] ← instructional_design_framework ← [[TTT-Train-the-Trainer]]（TTT 培养的讲师使用 ADDIE 模型进行课程开发）
+- [[HIPO-Program]] ← talent_development ← [[TTT-Train-the-Trainer]]（高潜力人才可优先发展为内部讲师，形成双赢）
diff --git a/wiki/concepts/Taoxi.md b/wiki/concepts/Taoxi.md
new file mode 100644
index 00000000..c9eda871
--- /dev/null
+++ b/wiki/concepts/Taoxi.md
@@ -0,0 +1,110 @@
+---
+title: "Taoxi（套磁）"
+type: concept
+tags: []
+sources: [study-abroad-advisor]
+last_updated: 2026-05-29
+---
+
+# Taoxi（套磁）
+
+## Definition
+
+Taoxi（套磁）——留学申请语境下，申请者主动通过邮件联系目标院校的教授或潜在导师，以建立学术联系、表达研究兴趣、并试探录取/奖学金可能性的行为。"套磁"为中文谐音，源自英文 "touching" 的音译，引申为"套近乎、搞关系"。
+
+## Core Purposes
+
+| 目的 | 说明 |
+|------|------|
+| 探索研究匹配度 | 了解教授当前研究方向、是否有招生名额 |
+| 表达研究兴趣 | 展示对教授工作的理解和自身研究背景的契合 |
+| 增加录取概率 | 强委员会制项目中，导师认可可直接影响录取结果 |
+| 争取奖学金 | 教授实验室经费充足时，可直接提供 RA/TA 职位 |
+| 获取内部信息 | 了解项目偏好、招生趋势、导师风格等非公开信息 |
+
+## When to Reach Out
+
+### High-Value Situations
+- **美国 PhD 申请**：导师推荐制（Advisor-based）项目中，强导师认可是录取的关键
+- **英国研究型硕士/博士**：导师制明显，强套磁可显著提升录取概率
+- **欧陆岗位制博士**：教授直接决定录取，套磁是必经步骤
+- **香港/新加坡 PhD**：导师制强，套磁效果显著
+
+### Low-Value Situations
+- **英国授课型硕士（UK Taught MSc）**：录取主要由招生委员会决定，导师不参与
+- **美国硕士项目（尤其 Master of Engineering）**：多为强委员会制，导师影响力有限
+- **澳洲/新西兰授课型项目**：导师制弱，套磁效果有限
+
+## How to Write a Taoxi Email
+
+### Structure
+1. **Subject Line**：简洁明确，包含 "Prospective [PhD/MPhil] Student" + 你的研究领域
+2. **自我介绍**：姓名、背景、当前学位 + GPA/排名
+3. **研究兴趣**：具体说明你感兴趣的教授的哪些研究方向（必须读教授近期 paper）
+4. **背景匹配**：简要说明你的研究经历/技能如何契合教授方向
+5. **附件**：附上 CV（PDF），正文保留摘要
+6. **结尾**：感谢 + 表示期待回复 + 附联系方式
+
+### Key Principles
+- **必须个性化**：每封邮件针对特定教授撰写，绝不用模板群发
+- **必须读 paper**：引用教授的具体论文/项目，展示真实了解
+- **不过度恭维**：保持学术平等的沟通姿态
+- **控制长度**：正文 200-300 词为宜，CV 作为附件
+
+### Sample Email Framework
+```
+Subject: Prospective PhD Student — [Your Research Area]
+
+Dear Professor [Name]:
+
+I am [Your Name], a [current degree] student at [University] 
+expected to graduate in [Month Year]. My research focuses on 
+[your research area], and I am particularly interested in your 
+work on [specific paper/project from professor].
+
+I have [briefly describe relevant experience — 1-2 sentences].
+I am planning to apply to [program name] at [university] for 
+[Fall 202X] and would be grateful if you might consider me as 
+a potential student in your lab.
+
+I have attached my CV for your reference. I would welcome the 
+opportunity to discuss your current research directions.
+
+Thank you for your time.
+
+Best regards,
+[Your Name]
+[Email]
+[LinkedIn/Website]
+```
+
+## Timing
+
+| 申请类型 | 最佳套磁时间 | 备注 |
+|---------|------------|------|
+| 美国 PhD | 申请前 6-12 个月（8月-11月） | 早于提交申请前联系 |
+| 英国 PhD | 申请前 3-6 个月 | 与申请同步进行 |
+| 欧陆岗位制博士 | 随时（全年滚动） | 有职位空缺时立即联系 |
+| 新加坡/香港 PhD | 申请前 6-9 个月 | 导师制强，早联系优势大 |
+
+## Common Mistakes
+
+1. **模板群发**：一封邮件改名字发给多位教授，被识破后印象极差
+2. **不读 paper**：声称感兴趣却无法讨论具体内容
+3. **要求过多**：首次邮件就要求"是否有名额"或"能否提供奖学金"
+4. **过度吹捧**：连续多段恭维教授，忽视平等学术对话
+5. **附件过大**：CV 超过 2 页，或附带未经压缩的作品集
+
+## Relationship to Study Abroad Planning
+
+[[study-abroad-advisor]] 在博士申请指导中，将 Taoxi 列为高优先级任务：
+- PhD 申请者必须在提交申请前完成目标导师的套磁
+- 套磁结果是选校策略的重要参考——"导师已读邮件未回复"≠"无兴趣"，可能是招生决策未确定
+- 对于无套磁的传统申请者，建议通过学术会议（Conference）等机会建立非正式联系
+
+## Aliases
+- 套磁
+- Professor Outreach
+- Faculty Contact
+- Cold Email（导师）
+- Prospective Student Email
diff --git a/wiki/concepts/Test-Coverage-Analysis.md b/wiki/concepts/Test-Coverage-Analysis.md
new file mode 100644
index 00000000..a5c2e89f
--- /dev/null
+++ b/wiki/concepts/Test-Coverage-Analysis.md
@@ -0,0 +1,55 @@
+---
+title: "Test Coverage Analysis"
+type: concept
+tags: [testing, coverage, quality]
+sources: [testing-test-results-analyzer]
+last_updated: 2026-04-28
+---
+
+## Definition
+
+测试覆盖率分析——通过量化代码被执行的比例来评估测试的全面性，识别测试缺口并按风险优先级排序改进方向。
+
+## Coverage Dimensions
+
+| 维度 | 说明 | 目标 |
+|------|------|------|
+| 行覆盖率 (Line Coverage) | 被执行代码行数 / 总代码行数 | ≥80% |
+| 分支覆盖率 (Branch Coverage) | 已覆盖分支数 / 总分支数 | ≥75% |
+| 函数覆盖率 (Function Coverage) | 被调用函数数 / 总函数数 | ≥90% |
+| 语句覆盖率 (Statement Coverage) | 已执行语句数 / 总语句数 | ≥80% |
+
+## Key Methods
+
+- **Gap Analysis**：识别覆盖率 < 80% 的文件，结合文件变更频率和业务关键性计算改进优先级。
+- **Risk-Based Coverage Prioritization**：按文件业务重要性 × 变更频率 × 当前覆盖率计算改进优先级。
+- **Coverage Trend Tracking**：跨版本跟踪覆盖率变化，检测回归。
+
+## Implementation (Python)
+
+```python
+# 来自 TestResultsAnalyzer 的参考实现
+coverage_stats = {
+    'line_coverage': test_results['coverage']['lines']['pct'],
+    'branch_coverage': test_results['coverage']['branches']['pct'],
+    'function_coverage': test_results['coverage']['functions']['pct'],
+    'statement_coverage': test_results['coverage']['statements']['pct']
+}
+
+# 识别覆盖缺口
+for file_path, file_coverage in uncovered_files.items():
+    if file_coverage['lines']['pct'] < 80:
+        gap_analysis.append({
+            'file': file_path,
+            'coverage': file_coverage['lines']['pct'],
+            'risk_level': assess_file_risk(file_path, file_coverage),
+            'priority': calculate_coverage_priority(file_path, file_coverage)
+        })
+```
+
+## Connections
+
+- [[Quality-Metrics]]：覆盖率是核心质量指标之一。
+- [[Defect-Prediction]]：覆盖缺口区域通常也是缺陷高发区域。
+- [[Release-Readiness-Assessment]]：覆盖率是发布门控条件之一。
+- [[Failure-Pattern-Analysis]]：低覆盖率与高失败率往往相关。
diff --git a/wiki/concepts/Theme-Toggle.md b/wiki/concepts/Theme-Toggle.md
new file mode 100644
index 00000000..5ef111c2
--- /dev/null
+++ b/wiki/concepts/Theme-Toggle.md
@@ -0,0 +1,124 @@
+---
+title: "Theme Toggle"
+type: concept
+tags: [css, javascript, ux, theme, dark-mode]
+sources: [design-ux-architect.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+Theme Toggle 是允许用户在 light、dark 和 system 三种主题模式之间切换的 UI 组件。所有新站点必须将此组件作为默认必备功能，基于 localStorage 持久化和 `prefers-color-scheme` 检测实现。
+
+## HTML Structure
+
+```html
+<div class="theme-toggle" role="radiogroup" aria-label="Theme selection">
+  <button class="theme-toggle-option" data-theme="light" role="radio" aria-checked="false">
+    <span aria-hidden="true">☀️</span> Light
+  </button>
+  <button class="theme-toggle-option" data-theme="dark" role="radio" aria-checked="false">
+    <span aria-hidden="true">🌙</span> Dark
+  </button>
+  <button class="theme-toggle-option" data-theme="system" role="radio" aria-checked="true">
+    <span aria-hidden="true">💻</span> System
+  </button>
+</div>
+```
+
+## CSS Styles
+
+```css
+.theme-toggle {
+  position: relative;
+  display: inline-flex;
+  align-items: center;
+  background: var(--bg-secondary);
+  border: 1px solid var(--border-color);
+  border-radius: 24px;
+  padding: 4px;
+  transition: all 0.3s ease;
+}
+
+.theme-toggle-option {
+  padding: 8px 12px;
+  border-radius: 20px;
+  font-size: 14px;
+  font-weight: 500;
+  color: var(--text-secondary);
+  background: transparent;
+  border: none;
+  cursor: pointer;
+  transition: all 0.2s ease;
+}
+
+.theme-toggle-option.active {
+  background: var(--primary-500);
+  color: white;
+}
+```
+
+## JavaScript Implementation
+
+```javascript
+class ThemeManager {
+  constructor() {
+    this.currentTheme = this.getStoredTheme() || this.getSystemTheme();
+    this.applyTheme(this.currentTheme);
+    this.initializeToggle();
+  }
+
+  getSystemTheme() {
+    return window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
+  }
+
+  getStoredTheme() {
+    return localStorage.getItem('theme');
+  }
+
+  applyTheme(theme) {
+    if (theme === 'system') {
+      document.documentElement.removeAttribute('data-theme');
+      localStorage.removeItem('theme');
+    } else {
+      document.documentElement.setAttribute('data-theme', theme);
+      localStorage.setItem('theme', theme);
+    }
+    this.currentTheme = theme;
+    this.updateToggleUI();
+  }
+
+  initializeToggle() {
+    const toggle = document.querySelector('.theme-toggle');
+    if (toggle) {
+      toggle.addEventListener('click', (e) => {
+        if (e.target.matches('.theme-toggle-option')) {
+          this.applyTheme(e.target.dataset.theme);
+        }
+      });
+    }
+  }
+
+  updateToggleUI() {
+    const options = document.querySelectorAll('.theme-toggle-option');
+    options.forEach(option => {
+      option.classList.toggle('active', option.dataset.theme === this.currentTheme);
+    });
+  }
+}
+
+document.addEventListener('DOMContentLoaded', () => {
+  new ThemeManager();
+});
+```
+
+## Related Concepts
+
+- [[CSS-Design-System]]：提供颜色变量系统支撑主题切换
+- [[Theme-Manager]]：JavaScript 主题状态管理类
+- [[Responsive-Breakpoints]]：与其他响应式设计组件协同
+- [[Layout-Framework]]：通常放置于 Header/Navigation 区域
+
+## Sources
+
+- [[design-ux-architect]] — Theme Toggle 的完整 HTML/CSS/JS 实现规范
diff --git a/wiki/concepts/Three-Act-Proposal-Narrative.md b/wiki/concepts/Three-Act-Proposal-Narrative.md
new file mode 100644
index 00000000..8eac7632
--- /dev/null
+++ b/wiki/concepts/Three-Act-Proposal-Narrative.md
@@ -0,0 +1,63 @@
+---
+title: "三幕式提案叙事（Three-Act Proposal Narrative）"
+type: concept
+tags: [sales, proposal, narrative]
+sources: [sales-proposal-strategist]
+last_updated: 2026-04-29
+---
+
+## Definition
+
+三幕式提案叙事是一种将 RFP 响应从"合规清单"转化为"说服故事"的叙事结构。参照经典叙事弧线，将提案分为三个阶段，每一 act 都有明确的认知目标。
+
+## Three Acts
+
+### Act I — 理解挑战（Understanding the Challenge）
+
+**目标**：建立信任，证明你比竞争对手更懂买家的世界。
+
+**做法**：
+- 使用买家自己的语言和词汇
+- 反映他们的约束条件、政治格局和痛点
+- 2-3 段即可，不要过度展开
+
+**失去提案的方式**：完全跳过此 Act 或用模板化的行业套话填充
+
+### Act II — 方案旅程（The Solution Journey）
+
+**目标**：引导评审者经历你的方法论，每个能力直接映射到 Act I 中提出的挑战。
+
+**做法**：
+- 将方法论描述为一系列决策，而非一堵流程图
+- 每个章节问："这推进了我们的论点还是只填充了篇幅？"
+- 赢主题在此 Act 承担最重的叙事工作
+
+**失去提案的方式**：变成功能清单堆砌，与买家挑战脱节
+
+### Act III — 转化状态（The Transformed State）
+
+**目标**：让评审者停止"评估"开始"想象实施"。
+
+**做法**：
+- 量化成果、时间线里程碑、风险降低指标
+- 具体描述买家在 12-18 个月后的组织状态
+- 附上定价逻辑的价值叙事，而非单纯的成本表格
+
+**失去提案的方式**：以"谢谢您的考虑"或模糊的ROI数字结尾
+
+## 与赢主题的关系
+
+赢主题贯穿三个 Act：
+- Act I → 选择主题的触发（基于买家挑战选择主题）
+- Act II → 主题落地（每个主题在具体章节中展开）
+- Act III → 主题收束（主题汇聚为最终转化承诺）
+
+## Related Concepts
+
+- [[Win Theme]]：三幕叙事的叙事支柱
+- [[赢主题矩阵]]：三幕结构在多主题情况下的映射工具
+- [[执行摘要五步结构]]：三幕叙事的浓缩版，单独成文
+
+## Sources
+
+- [[sales-proposal-strategist]]
diff --git a/wiki/concepts/Three-Tier-School-Selection.md b/wiki/concepts/Three-Tier-School-Selection.md
new file mode 100644
index 00000000..3d33209f
--- /dev/null
+++ b/wiki/concepts/Three-Tier-School-Selection.md
@@ -0,0 +1,121 @@
+---
+title: "Three-Tier School Selection（三档选校策略）"
+type: concept
+tags: []
+sources: [study-abroad-advisor]
+last_updated: 2026-05-29
+---
+
+# Three-Tier School Selection（三档选校策略）
+
+## Definition
+
+Three-Tier School Selection（三档选校策略）——一种结构化选校方法，将目标院校划分为三个概率区间：Reach（冲刺校）、Target（匹配校）和 Safety（保底校），以平衡申请风险和录取概率，最大化申请结果。
+
+## The Three Tiers
+
+### Reach Schools（冲刺校）
+| 指标 | 说明 |
+|------|------|
+| 录取概率 | 20-40% |
+| 定位 | 背景略高于自身条件，或竞争极为激烈的顶尖院校 |
+| 目的 | 争取超出预期结果（upside potential） |
+| 数量建议 | 申请 2-3 所 |
+| 心态 | 全力冲刺，文书保持最高质量 |
+
+### Target Schools（匹配校）
+| 指标 | 说明 |
+|------|------|
+| 录取概率 | 40-70% |
+| 定位 | 背景与院校录取偏好高度匹配 |
+| 目的 | 申请结果的主要来源，是选校的核心 |
+| 数量建议 | 申请 3-5 所 |
+| 心态 | 重点打磨，确保每份申请材料最优 |
+
+### Safety Schools（保底校）
+| 指标 | 说明 |
+|------|------|
+| 录取概率 | 70-90% |
+| 定位 | 录取概率高、且愿意入读的学校 |
+| 目的 | 保障录取底线，避免"全拒得" |
+| 数量建议 | 申请 1-2 所 |
+| 心态 | 仍需认真对待，保底校也可能成为最终 choice |
+
+## Admission Probability Ranges Explained
+
+### Why Ranges, Not Numbers?
+Study Abroad Advisor 明确拒绝精确数字表达 admission probability，原因：
+- 录取过程存在大量**不可量化因素**（文书质量、推荐信力度、招生官偏好、申请池竞争强度）
+- 单一数字会产生**虚假确定性**（false precision）——误导学生以为 50% 就是一半
+- 区间表达（20-40%）承认不确定性，传递"尽力但结果非可控"的诚实信号
+
+### What Affects Tier Assignment?
+| 因素 | 对选校的影响 |
+|------|------------|
+| GPA/排名 | 核心硬指标，决定基线 |
+| 标准化考试 | 可弥补 GPA 短板（如高 GRE 弥补低 GPA） |
+| 研究/实习经历 | 增强 Target tier 的把握 |
+| 文书质量 | 改变"软实力"维度，尤其对 Target/Safety 有效 |
+| 推荐信 | 强推荐可提升 Tier，尤其是学术导向项目 |
+| 项目招生规模 | 小规模项目（10-20人）不确定性更大 |
+| 国际生比例 | 部分项目有国际生上限 |
+| 招生偏好变化 | 每年招生策略可能调整 |
+
+## Application Strategy by Tier
+
+### Tier-Specific Strategy
+| 维度 | Reach | Target | Safety |
+|------|-------|--------|--------|
+| 文书深度 | 深度定制，强调 unique fit | 良好定制，突出竞争力 | 标准模板即可 |
+| 精力分配 | 最高（潜力最大） | 最高（结果核心） | 中等（底线保障） |
+| 选校理由 | 展示深度了解 | 展示了解 | 展示了解 |
+| 提交时机 | 赶早批次（ED/EA/Round1） | 正常批次 | 任意批次 |
+
+### Multi-Tier Timeline Management
+- **Reach 优先**：冲刺校通常截止较早（如 EA/ED 11月），优先完成
+- **Target 为主**：匹配校是主要精力分配，需要精细化定制
+- **Safety 托底**：保底校可稍后处理，但不可轻视（有时保底校反而最挑剔）
+
+## Psychological Dimensions
+
+### Student Psychology
+- **过度保守**：学生常低估自己，倾向于将本可 Reach 的院校列为 Target
+- **焦虑贩卖陷阱**：留学中介可能将大量院校列为 Reach 以"降低期望"，造成不必要的保守
+- **锚定效应**：第一个收到的 offer 会显著影响对其他学校的心态
+
+### Advisor Ethics
+[[study-abroad-advisor]] 的核心原则：
+- 避免将过多院校列为 Reach——制造不必要的焦虑和资源浪费
+- 避免将保底校标准设置过低——学生可能最终拒绝入读
+- 强调文书和背景提升在 Target tier 的杠杆效应
+
+## Examples
+
+### Example: CS Master's Applicant
+| 学校 | 档次 | 理由 |
+|------|------|------|
+| Stanford, MIT, CMU SCS | Reach | 顶尖项目，全球竞争最激烈 |
+| UC Berkeley, UIUC, GaTech | Target | CS 强校，匹配度高 |
+| UT Austin, UW-Madison | Safety | 录取概率高，项目质量好 |
+
+### Example: Finance Master's Applicant
+| 学校 | 档次 | 理由 |
+|------|------|------|
+| LSE, HEC Paris | Reach | 国际生竞争激烈 |
+| WBS, Imperial, ESADE | Target | 匹配学生背景 |
+| EDHEC, SKEMA | Safety | 录取率高 |
+
+## Relationship to Study Abroad Planning
+
+三档选校是 [[study-abroad-advisor]] 选校报告模板的核心组成部分：
+- 选校报告第一部分即列出三档学校表（含概率区间、费用、截止日期）
+- 策略层面通过 Country Combination 分析多国联申时的各 Tier 校比例
+- 每档选校均需提供 "Admission Reference"（录取参考）和 "Annual Cost"（年花费）
+
+## Aliases
+- Reach-Target-Safety
+- RTS Model
+- 三档选校
+- 冲刺-匹配-保底
+- Tiered School Selection
+- Balanced College List
diff --git a/wiki/concepts/ThreeActStructure.md b/wiki/concepts/ThreeActStructure.md
new file mode 100644
index 00000000..2b11d1f2
--- /dev/null
+++ b/wiki/concepts/ThreeActStructure.md
@@ -0,0 +1,45 @@
+---
+title: "Three-Act Structure"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Three-Act Structure
+- 三幕式
+- 三幕结构
+
+## Overview
+Three-Act Structure（三幕式）是西方叙事中最经典的戏剧结构模型，将叙事分为 Setup（建置）、Confrontation（对抗）和 Resolution（解决）三个部分。该结构可追溯到 Aristotle 的《诗学》，在现代由 [[Robert McKee]]、Syd Field 等人系统化为编剧标准。
+
+## Act Breakdown
+
+### Act I — Setup（约占全剧 25%）
+- 建立 Ordinary World（日常世界）
+- 引入主角
+- 建立 Status Quo（现状）
+- Inciting Incident（触发事件）打破平衡
+- Act Climax：主角必须做出选择/行动
+- Act Break：不可逆的决定
+
+### Act II — Confrontation（约占全剧 50%）
+- Rising Action（上升动作）
+- 阻力递增（complications, obstacles, setbacks）
+- Midpoint Shift（midpoint reversal 或 midpoint revelation）
+- 叙事债务逐渐积累
+- 主角的 lie/belief 受到考验
+- Dark Night of the Soul（最低点）
+- Act Break：危机揭示
+
+### Act III — Resolution（约占全剧 25%）
+- Falling Action（下落动作）
+- Climax：最高潮时刻
+- Denouement：解决与新平衡
+- Thematic resolution（主题性结论与 Controlling Idea 对应）
+
+## Relationship to Other Concepts
+- [[HeroesJourney]]：三幕是组织骨架，Hero's Journey 是其内容填充
+- [[Kishotenketsu]]：日本四幕结构，在第三/四幕之间无危机，直接延伸——跨文化对比框架
+- [[Character-Arc]]：角色弧线必须在三幕中完成：Setup (want/lie) → Confrontation (testing the lie) → Resolution (confronting truth)
diff --git a/wiki/concepts/ThreeTierExplanation.md b/wiki/concepts/ThreeTierExplanation.md
new file mode 100644
index 00000000..c91c1a4d
--- /dev/null
+++ b/wiki/concepts/ThreeTierExplanation.md
@@ -0,0 +1,52 @@
+---
+title: "ThreeTierExplanation"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+
+Three-Tier Explanation（三层解释法）是代码库分析和 onboarding 输出的一种分层叙事结构，从极高层次到极深层次渐进展开，帮助不同需求的受众快速获取所需信息。
+
+## Three Tiers
+
+### Tier 1: One-Line Summary（一句话概述）
+- **Purpose**: 快速建立代码库是什么的基线认知
+- **Length**: 1 句话
+- **Audience**: 需要快速判断是否关注此代码库的人
+
+### Tier 2: Five-Minute Explanation（五分钟高层解释）
+- **Purpose**: 构建完整的系统工作方式高层理解
+- **Content**:
+  - Primary tasks: 代码做什么
+  - Primary inputs: 主输入（HTTP请求、CLI参数、消息、文件、函数参数）
+  - Primary outputs: 主输出（响应、数据库写入、文件、事件、渲染UI）
+  - Key files: 关键文件及其职责
+  - Main code paths: 主代码路径（入口 → 编排 → 核心逻辑 → 输出）
+- **Audience**: 需要了解系统如何运作的开发者
+
+### Tier 3: Deep Dive（深度代码流分析）
+- **Purpose**: 支撑精确的技术决策和问题定位
+- **Content**:
+  - Type: 系统类型（web app/API/monorepo/CLI/library/hybrid）
+  - Primary runtimes: 主运行时环境
+  - Entry points: 所有入口点及重要性说明
+  - Top-level structure: 顶层结构表
+  - Key boundaries: 关键边界（展示层/应用层/持久层/跨领域）
+  - Responsibilities by file: 文件级职责映射
+  - Detailed code flows: 详细代码流步骤
+  - Files inspected: 已检查文件清单
+- **Audience**: 需要进行具体实现或调试的开发者
+
+## Usage Context
+
+- [[CodebaseOnboarding]] 的核心输出格式
+- [[ExecutionTracing]] 的结果呈现
+- 新代码库探索的标准化报告结构
+
+## Related Concepts
+
+- [[CodebaseOnboarding]] — 代码库 onboarding 方法论
+- [[ExecutionTracing]] — 执行路径追踪
+- [[MentalModel]] — 心智模型构建
diff --git a/wiki/concepts/TieredCampaignArchitecture.md b/wiki/concepts/TieredCampaignArchitecture.md
index 6ec2f17e..7efc7c4f 100644
--- a/wiki/concepts/TieredCampaignArchitecture.md
+++ b/wiki/concepts/TieredCampaignArchitecture.md
@@ -1,50 +1,65 @@
----
-title: "Tiered Campaign Architecture"
-type: concept
-tags: ["paid-media", "google-ads", "strategy", "structure"]
-last_updated: 2026-04-20
----
-
-## Aliases
-- Campaign Tiers
-- Tiered Structure
-- Campaign Isolation Strategy
-- 分层活动架构
-
-## Overview
-分层活动架构是 [[PaidMediaPpcStrategist]] 推荐的核心账户结构策略，将广告活动按目标分层隔离（品牌/非品牌/竞品/征服），避免预算内耗和竞价冲突。是 [[AccountArchitecture]] 的具体实现模式。
-
-## Standard Tier Structure
-
-### 1. Brand（品牌层）
-- **目标**: 保护品牌词流量，防止竞品抢量
-- **特点**: 高 Quality Score、低 CPC、高 ROAS
-- **竞价**: 通常采用 tROAS 或 Max Conversions
-- **隔离**: 独立预算，确保 90%+ 品牌展示份额
-
-### 2. Non-Brand（非品牌层）
-- **目标**: 规模化获取新客户
-- **特点**: 宽泛匹配，扩大覆盖
-- **竞价**: 通常采用 tCPA 或 Max Conversions
-- **隔离**: 独立预算，控制 CPA 在目标范围内
-
-### 3. Competitor / Conquest（竞品层）
-- **目标**: 主动触达正在搜索竞品的用户
-- **特点**: 竞品关键词 + 竞品品牌词
-- **竞价**: 通常采用 Max Conversions 或 Manual CPC 精细化调价
-- **隔离**: 与非品牌层共享或独立预算
-
-### 4. Product / Category（产品/类目层）
-- **目标**: 针对特定产品线或类目的精准覆盖
-- **特点**: 细分关键词，高度相关性
-- **竞价**: 视产品利润率和竞争程度灵活选择
-
-## Isolation Strategies
-- 预算隔离：各层活动独立预算，防止高 CPC 活动吞噬低 CPC 活动预算
-- 受众隔离：Layered Audience Strategy，区分再营销和新受众
-- 信号隔离：不同活动使用不同的受众信号
-
-## Related Concepts
-- [[AccountArchitecture]]: Tiered Architecture 是账户架构的具体实现
-- [[SmartBidding]]: 各层可采用不同的 Smart Bidding 策略
-- [[PerformanceMax]]: Performance Max 覆盖增量用户，与分层架构协同
+---
+title: "Tiered Campaign Architecture"
+type: concept
+tags: ["ppc", "account-structure", "campaign-design", "google-ads", "paid-media"]
+sources: ["paid-media-ppc-strategist"]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+分层广告系列架构（Tiered Campaign Architecture）是一种将广告账户按战略意图分为不同层级的账户结构设计方法，通常分为 4 个核心层级：**Brand（品牌）**、**Non-Brand（非品牌）**、**Competitor（竞品）**、**Conquest（征服）**，每层承担独立的战略目标，配套独立的竞价策略、预算和优化规则。
+
+## Four Core Tiers
+
+### Tier 1: Brand（品牌词）
+**目标**：保护品牌搜索流量，防止竞品抢量
+
+| 特征 | 值 |
+|------|---|
+| 关键词 | 品牌词 + 品牌变体 + 品牌+产品组合 |
+| 竞价策略 | 通常最高，可接受高 CPC |
+| 预算 | 受保护，日预算充足 |
+| Quality Score | 通常最高（9-10） |
+| ROAS | 通常最高 |
+
+### Tier 2: Non-Brand（非品牌词）
+**目标**：捕获与产品/服务相关的非品牌搜索意图
+
+| 特征 | 值 |
+|------|---|
+| 关键词 | 产品词、行业词、问题词、解决方案词 |
+| 竞价策略 | tCPA/tROAS，追求效率 |
+| 预算 | 最大，通常占预算主体 |
+| 竞争激烈度 | 中高 |
+
+### Tier 3: Competitor（竞品词）
+**目标**：直接截流竞品品牌词的搜索流量
+
+| 特征 | 值 |
+|------|---|
+| 关键词 | 竞品品牌词 + 竞品产品词 |
+| 竞价策略 | 可接受较高 CPA，品牌保护 |
+| 法律/政策 | 需遵守平台规则（Google 允许但需准确描述） |
+| 效率波动 | 通常较低 |
+
+### Tier 4: Conquest（征服/新客获取）
+**目标**：触达处于考虑阶段的新潜在客户
+
+| 特征 | 值 |
+|------|---|
+| 关键词 | 广泛匹配 + 受众组合 |
+| 竞价策略 | Max Conversions，扩大规模 |
+| 预算 | 测试性，按效果扩展 |
+
+## Isolation Strategy
+
+分层架构的核心原则：**各层之间相互隔离**，防止内部竞争：
+- 负向关键词隔离：Brand 层排除 Non-Brand 词，反之亦然
+- 受众分层：不同层级使用不同的受众组合
+- 出价隔离：确保高价值层级不会被低价值层级耗尽预算
+
+## Connections
+- [[AccountArchitecture]]：Tiered Campaign Architecture 是 Account Architecture 的战略实现
+- [[AutomatedBiddingStrategy]]：不同层级适用不同的竞价策略
+- [[AudienceStrategy]]：不同层级使用不同的受众组合
diff --git a/wiki/concepts/ToolStreaming.md b/wiki/concepts/ToolStreaming.md
new file mode 100644
index 00000000..ae9b7bea
--- /dev/null
+++ b/wiki/concepts/ToolStreaming.md
@@ -0,0 +1,31 @@
+---
+title: "ToolStreaming"
+type: concept
+tags:
+  - "hermes-agent"
+  - "streaming"
+  - "ux"
+sources: []
+last_updated: 2026-04-20
+---
+
+## Overview
+
+ToolStreaming 是 Hermes Agent 在流式响应模式下，通过 API Server 向客户端实时推送工具执行进度信息的功能。当 Agent 调用工具（终端、文件操作、网页搜索等）时，对应工具的 emoji 和关键参数会作为内联标记在最终回复前插入到流中。
+
+## How It Works
+
+1. Agent 执行工具时，立即将工具标记（如 `` `💻 ls -la` ``）写入响应流
+2. 工具标记在流中出现早于最终回复
+3. 用户可见 Agent "正在做什么"，提升透明度
+
+## Example Output
+
+```
+`💻 ls -la` `🔍 Python 3.12 release` `📁 read_file src/main.py` ...
+[最终回复正文]
+```
+
+## See Also
+- [[APIServer]]
+- [[open-webui-hermes-agent]]
diff --git a/wiki/concepts/TransactionalAnalysis.md b/wiki/concepts/TransactionalAnalysis.md
new file mode 100644
index 00000000..3415219a
--- /dev/null
+++ b/wiki/concepts/TransactionalAnalysis.md
@@ -0,0 +1,47 @@
+---
+title: "Transactional Analysis"
+type: concept
+tags: []
+sources: [academic-psychologist]
+last_updated: 2026-04-25
+---
+
+# Transactional Analysis
+
+## Aliases
+- TA (Transactional Analysis)
+- Eric Berne's Transactional Analysis
+- Ego States Model
+
+## Definition
+交互分析（Berne）——通过识别人际互动中三种自我状态（Parent/Adult/Child）来分析沟通模式、权力动态和隐性契约。
+
+## Three Ego States
+
+| 自我状态 | 描述 | 典型语言/行为 |
+|----------|------|---------------|
+| **Parent（父母）** | 从照顾者处习得的价值观和规范 | 指导性语言、评判、控制、"你应该..." |
+| **Adult（成人）** | 基于现实和逻辑的理性处理 | 中立、理性、问题解决、"事实是..." |
+| **Child（儿童）** | 童年时期保存的情感和行为模式 | 情绪化、好奇、顺从或反叛、"我想..." |
+
+## Transaction Types
+
+### Complementary Transactions（互补交易）
+A→B, B→A 方向对应，沟通可持续。
+- Parent→Child → Child→Parent（上下对应）
+- Adult→Adult → Adult→Adult（平行对应）
+
+### Crossed Transactions（交叉交易）
+A→B 触发 B→C（非预期回应），导致沟通中断或冲突。
+
+### Ulterior Transactions（隐性交易）
+表面信息 + 隐藏的社会/心理层面双层信息；长期隐性交易是心理游戏（Games People Play）的基础。
+
+## Unspoken Contracts（隐性契约）
+关系中双方对彼此期望的隐性协议，往往未被明确表达，导致不满和冲突。
+
+## Application in Character Design
+Psychologist Agent 使用此框架映射角色间的沟通模式和隐性契约，识别具体触发点。
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/concepts/TransferPricing.md b/wiki/concepts/TransferPricing.md
new file mode 100644
index 00000000..ce609375
--- /dev/null
+++ b/wiki/concepts/TransferPricing.md
@@ -0,0 +1,37 @@
+---
+title: "Transfer Pricing"
+type: concept
+tags: ["tax", "international-tax", "compliance", "finance"]
+last_updated: 2026-05-02
+---
+
+## Definition
+
+转让定价（Transfer Pricing）是指关联方之间进行商品、服务或无形资产交易时确定价格的方法和原则。各国税务机关要求关联方交易价格必须符合**独立交易原则（Arm's Length Principle）**，即交易条件应与独立第三方之间的可比交易一致。
+
+## Core Components
+
+- **独立交易原则（Arm's Length Principle, ALP）**：关联方交易价格必须与可比独立交易相当
+- **基准研究（Benchmarking Study）**：通过可比公司或可比交易确定价格区间
+- **预约定价协议（Advance Pricing Agreement, APA）**：与税务机关事先约定的定价方法，具有确定性
+- **成本分摊协议（Cost Sharing Arrangement, CSA）**：子公司间分担研发成本并共享收益的安排
+
+## Key Methods
+
+| 方法 | 适用场景 |
+|------|----------|
+| 可比不受控价格法（CUP） | 商品贸易 |
+| 转售价格法（RPM） | 分销商场景 |
+| 成本加成法（Cost Plus） | 制造商/服务商 |
+| 利润分割法（PSM） | 高度整合业务 |
+| 交易净利润法（TNMM） | 无形资产交易 |
+
+## Sources
+
+- [[finance-tax-strategist]]
+
+## Related Concepts
+
+- [[EffectiveTaxRate]]
+- [[GILTI]]
+- [[BEPS]]
diff --git a/wiki/concepts/URP.md b/wiki/concepts/URP.md
new file mode 100644
index 00000000..45840d31
--- /dev/null
+++ b/wiki/concepts/URP.md
@@ -0,0 +1,72 @@
+---
+title: "URP (Universal Render Pipeline)"
+type: concept
+tags: [game-dev, rendering, unity, pipeline]
+sources: [unity-shader-graph-artist]
+last_updated: 2026-05-01
+---
+
+## Aliases
+- Universal Render Pipeline
+- URP
+- LWRP（Legacy，URP 前身）
+
+## Definition
+
+URP（Universal Render Pipeline，通用渲染管线）是 Unity 的可编程渲染管线，取代了旧版 Built-in 渲染管线。专为跨平台（PC/Console/Mobile/VR）设计，通过 Shader Graph 和 Scriptable Renderer Feature 实现灵活的渲染效果定制。相比 HDRP 更轻量，适合需要多平台支持的项目。
+
+## Core Architecture
+
+### ScriptableRendererFeature 系统
+URP 自定义通道的核心扩展点：
+
+```csharp
+// 必须使用 ScriptableRendererFeature + ScriptableRenderPass
+public class MyRendererFeature : ScriptableRendererFeature
+{
+    public override void Create() { _pass = new MyRenderPass(); }
+    public override void AddRenderPasses(ScriptableRenderer renderer, ref RenderingData renderingData)
+        => renderer.EnqueuePass(_pass);
+}
+
+public class MyRenderPass : ScriptableRenderPass
+{
+    public override void Execute(ScriptableRenderContext context, ref RenderingData renderingData)
+        { /* 自定义渲染逻辑 */ }
+}
+```
+
+### 关键约束
+- **禁止使用** `OnRenderImage`（Built-in only）
+- Shader Graph 必须设置正确的 URP Render Pipeline Asset
+- URP 图形无法直接在 HDRP 中工作，需要 Porting
+
+### 与 HDRP 的核心区别
+
+| 特性 | URP | HDRP |
+|------|-----|------|
+| 目标平台 | PC/Console/Mobile/VR | PC/Console（高端） |
+| 渲染质量 | 中等-高 | 极高（物理光照/光线追踪） |
+| 自定义通道 API | `ScriptableRendererFeature` | `CustomPassVolume` |
+| API 兼容性 | **不兼容** HDRP | **不兼容** URP |
+
+## Shader Graph in URP
+
+- Shader Graph 是 URP 材质创作的首选工具
+- 节点自动映射到 URP 的光照模型
+- 必须使用 Sub-Graph 封装可复用逻辑
+- 暴露参数必须设置 Blackboard tooltip
+
+## Performance
+
+| 平台 | Fragment Pass 纹理采样上限 | ALU 上限 |
+|------|--------------------------|---------|
+| Mobile | ≤ 32 次/Fragment Pass | ≤ 60 条/不透明 Fragment |
+| PC/Console | 无硬性上限，但 Frame Debugger 审计 | — |
+
+## Connections
+- [[Shader]] ← 渲染目标 ← URP
+- [[UnityShaderGraphArtist]] ← 专精 ← URP
+- [[HDRP]] ← 互补管线 ← URP（不兼容）
+- [[ScriptableRenderPass]] ← 核心 API ← URP
+- [[ScriptableRendererFeature]] ← 扩展机制 ← URP
diff --git a/wiki/concepts/UUPSUpgradeable.md b/wiki/concepts/UUPSUpgradeable.md
new file mode 100644
index 00000000..151d9101
--- /dev/null
+++ b/wiki/concepts/UUPSUpgradeable.md
@@ -0,0 +1,47 @@
+---
+title: "UUPSUpgradeable"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+UUPS（Universal Upgradeable Proxy Standard，EIP-1822）是一种智能合约可升级模式，通过代理合约（Proxy）将用户请求转发给实现合约（Implementation），实现合约可以独立升级而不改变代理地址。
+
+## How It Works
+```
+User → Proxy (永恒地址) → Implementation v1 → Implementation v2 (升级后)
+```
+
+- **Proxy**：永恒地址，存储所有数据，持有用户资产
+- **Implementation**：包含业务逻辑，可以随时替换
+- **UUPS 特有**：升级逻辑嵌入在 Implementation 中（而非 Proxy 中）
+
+## UUPS vs Transparent Proxy
+
+| 维度 | UUPS | Transparent Proxy |
+|------|------|-------------------|
+| 升级逻辑位置 | Implementation | Proxy（Admin） |
+| 部署 gas 成本 | 较低 | 较高（Admin check 每次调用） |
+| Admin 权限 | 无（除非嵌入） | 必须由 Proxy Admin 管理 |
+| 安全性 | 实现错误升级逻辑会导致 brick | Proxy 层更简单 |
+
+## UUPS Implementation Pattern
+```solidity
+import {UUPSUpgradeable} from "@openzeppelin/contracts/proxy/utils/UUPSUpgradeable.sol";
+
+contract MyContractV1 is UUPSUpgradeable, Ownable {
+    function _authorizeUpgrade(address) internal override onlyOwner {
+        // 升级权限控制
+    }
+}
+```
+
+## 存储兼容性关键规则
+- **永远不要删除或重新排序 storage 变量**——会破坏代理合约中的数据布局
+- **只能在末尾添加新变量**——追加永远安全
+- OpenZeppelin 提供 storage 布局验证工具
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
+- [[OpenZeppelin]]
diff --git a/wiki/concepts/Usability-Testing.md b/wiki/concepts/Usability-Testing.md
new file mode 100644
index 00000000..51d7de4a
--- /dev/null
+++ b/wiki/concepts/Usability-Testing.md
@@ -0,0 +1,46 @@
+---
+title: "Usability Testing"
+type: concept
+tags: [ux, usability-testing, user-research, task-completion, error-rate]
+sources: [design-ux-researcher.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+Usability Testing（可用性测试）是一种通过让真实用户在受控环境中完成具体任务来评估产品可用性的研究方法。收集量化指标（任务完成率、完成时间、错误次数）和定性洞察（用户反馈、行为观察、情感反应），为设计决策提供实证依据。
+
+## Session Structure (60 minutes)
+
+| 阶段 | 时长 | 内容 |
+|------|------|------|
+| 介绍 | 5分钟 | 欢迎、建立信任、知情同意、出声思考协议说明 |
+| 基线访谈 | 10分钟 | 当前工具使用经验、期望和心理模型、人口统计信息 |
+| 任务场景 | 35分钟 | 3个现实场景，含任务完成率/时间/错误等量化指标 |
+| 测试后访谈 | 10分钟 | 整体印象、具体反馈、改进建议、比较性问题 |
+
+## Quantitative Metrics
+
+| 指标 | 说明 | 目标参考 |
+|------|------|---------|
+| Task Completion Rate | 任务成功完成的比例 | 越高越好 |
+| Time on Task | 完成任务所需时间 | 越短越好 |
+| Error Count | 用户操作错误的次数 | 越少越好 |
+| Satisfaction Score | 用户满意度评分（1-5分） | 4.0+ |
+
+## Qualitative Data Types
+
+- **直接引用语**：用户在完成任务时的原话
+- **行为观察**：身体语言、犹豫、困惑等非语言信号
+- **情感反应**：成功时的喜悦、挫折时的沮丧
+
+## Relationship to Other Concepts
+
+- [[User-Research-Methodology]]：可用性测试是混合研究方法论的具体实践形式
+- [[User-Persona]]：可用性测试参与者需符合目标用户画像的招募标准
+- [[User-Journey-Mapping]]：可用性测试的场景设计基于用户旅程地图中的关键触点
+- [[Qualitative-Quantitative-Research]]：同时收集定量（完成率/时间）和定性（引用语/观察）数据
+
+## Source
+
+- [[design-ux-researcher.md]] — UX Researcher Agent Personality
diff --git a/wiki/concepts/User-Journey-Mapping.md b/wiki/concepts/User-Journey-Mapping.md
new file mode 100644
index 00000000..5fbc158e
--- /dev/null
+++ b/wiki/concepts/User-Journey-Mapping.md
@@ -0,0 +1,30 @@
+---
+title: "User Journey Mapping"
+type: concept
+tags: [ux, user-journey, user-research, touchpoints, pain-points]
+sources: [design-ux-researcher.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+User Journey Mapping（用户旅程地图）是一种可视化工具，描绘用户为达成目标而经历的完整路径，识别关键触点、摩擦区域、情感变化和优化机会。与用户画像结合，提供从"谁"到"如何"的完整理解。
+
+## Core Elements
+
+| 元素 | 说明 |
+|------|------|
+| Touchpoints | 用户与产品的所有接触点（发现/注册/使用/退出） |
+| Pain Points | 摩擦区域和问题点（导航困难/信息缺失/等待过长） |
+| Emotions | 用户在各阶段的情感变化曲线 |
+| Opportunities | 基于发现识别的改进空间 |
+
+## Relationship to Other Concepts
+
+- [[User-Persona]]：用户旅程地图基于特定用户画像构建
+- [[Usability-Testing]]：测试场景设计基于用户旅程中的关键触点
+- [[Inclusive-Design-Research]]：旅程地图需考虑不同能力水平用户的路径差异
+
+## Source
+
+- [[design-ux-researcher.md]] — UX Researcher Agent Personality
diff --git a/wiki/concepts/User-Persona.md b/wiki/concepts/User-Persona.md
new file mode 100644
index 00000000..4ac92f82
--- /dev/null
+++ b/wiki/concepts/User-Persona.md
@@ -0,0 +1,49 @@
+---
+title: "User Persona"
+type: concept
+tags: [ux, user-persona, user-research, personas, demographics]
+sources: [design-ux-researcher.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+User Persona（用户画像）是基于实证研究数据构建的半虚构用户原型，描述目标用户的特征、目标、痛点、行为模式和动机。不是假设，而是从真实用户研究中提取的代表性模式。
+
+## Core Components
+
+### Demographics & Context
+- 年龄范围、地理位置、职业角色
+- 数字素养水平、主要设备和平台偏好
+
+### Behavioral Patterns
+- 使用频率、主要任务优先级
+- 决策影响因素、痛点、动机
+
+### Goals & Needs
+- 主要目标、辅助目标
+- 成功标准、信息需求
+
+### Context of Use
+- 使用环境、时间约束、环境干扰因素
+- 独立使用 vs 协作使用
+
+### Quotes & Insights
+- 直接引用语，高亮关键洞察
+- 基于 [X] 访谈、[Y] 问卷、[Z] 行为数据点的研究证据
+
+## Creation Criteria
+
+- 基于实证数据，而非假设
+- 需满足"出现 ≥ 2 次"或"对主题有关键影响"的去重规则
+- 来源：[[design-ux-researcher.md]]
+
+## Relationship to Other Concepts
+
+- [[User-Research-Methodology]]：用户画像是混合研究方法的产出之一
+- [[User-Journey-Mapping]]：用户画像是旅程地图的基础输入
+- [[Usability-Testing]]：测试参与者招募需符合目标用户画像的特征
+
+## Source
+
+- [[design-ux-researcher.md]] — UX Researcher Agent Personality
diff --git a/wiki/concepts/User-Research-Methodology.md b/wiki/concepts/User-Research-Methodology.md
new file mode 100644
index 00000000..ce6fa95f
--- /dev/null
+++ b/wiki/concepts/User-Research-Methodology.md
@@ -0,0 +1,45 @@
+---
+title: "User Research Methodology"
+type: concept
+tags: [ux, user-research, methodology, qualitative, quantitative]
+sources: [design-ux-researcher.md]
+last_updated: 2026-04-24
+---
+
+## Definition
+
+User Research Methodology 是一套系统化的用户研究方法框架，通过先确立清晰研究问题，再选择适当研究方法，收集定性与定量数据，最终转化为可实施的设计建议。是 UX Researcher Agent 核心研究流程的理论基础。
+
+## Core Principles
+
+### Research-First Question Definition
+- 先确立清晰的研究问题，再选择研究方法
+- 研究目标需包含：主要研究问题、成功指标、业务影响
+
+### Method Selection
+- 根据研究问题类型选择最适当的方法
+- 样本量需有统计依据
+- 通过三角验证（Triangulation）缓解单一方法偏差
+
+### Ethical Research Practices
+- 获得适当知情同意，保护参与者隐私
+- 确保跨人口统计学特征的包容性招募
+- 客观呈现发现，不引入确认偏差
+- 安全存储和处理研究数据
+
+## Mixed Methods Framework
+
+| 研究类型 | 方法 | 适用场景 |
+|---------|------|---------|
+| 定性研究 | 深度访谈、可用性测试、焦点小组 | 探索性、需深入理解原因 |
+| 定量研究 | 问卷调查、A/B测试、行为分析 | 验证性、需统计显著性 |
+
+## Relationship to Other Concepts
+
+- [[Usability-Testing]]：方法论的具体应用形式之一
+- [[Research-Triangulation]]：方法论的核心验证机制
+- [[Inclusive-Design-Research]]：方法论的默认要求维度
+
+## Source
+
+- [[design-ux-researcher.md]] — UX Researcher Agent Personality
diff --git a/wiki/concepts/Video-Physics-Definition.md b/wiki/concepts/Video-Physics-Definition.md
new file mode 100644
index 00000000..46358a03
--- /dev/null
+++ b/wiki/concepts/Video-Physics-Definition.md
@@ -0,0 +1,46 @@
+---
+title: "Video Physics Definition"
+type: concept
+tags: []
+last_updated: 2026-05-15
+---
+
+## Definition
+
+Video Physics Definition（视频物理一致性定义）——在 AI 视频生成（如 Sora、Runway Gen-3）中，通过显式约束确保衣物、头发、辅助行动器具（轮椅、拐杖、假肢）等元素的运动符合真实物理规律的技术方法。
+
+## Problem
+
+AI 视频生成模型在渲染动态元素时经常出现物理错误：
+- 衣物（如头巾Hijab）运动不符合重力规律
+- 轮椅轮胎与地面接触不一致（悬浮或穿入地面）
+- 头发运动僵硬或不符合风向
+- 辅助器具（拐杖）位置在连续帧之间漂移
+
+## Solution: Physics Constraints
+
+Inclusive Visuals Specialist 通过以下方式注入物理约束：
+
+```typescript
+// 示例：轮椅运动约束
+"The wheelchair wheels maintain consistent contact with the pavement as she navigates the ramp."
+"Her hijab drapes naturally over the shoulder as she walks, following the slight breeze."
+```
+
+### Three Levels of Physics Constraints
+
+1. **Contact Consistency**：物体与接触面的持续接触（轮胎-地面、脚-地板）
+2. **Drape/Gravity**：软性物体的重力下垂（Hijab下摆、宽松衣袖）
+3. **Motion Path**：连续帧之间的运动轨迹平滑性（拐杖支撑点的稳定移动）
+
+## Related Concepts
+
+- [[Negative Prompting]]
+- [[Intersectionality]]
+- [[Cultural Authenticity]]
+- [[Inclusive Visuals Specialist]]
+
+## Aliases
+
+- 视频物理一致性
+- 物理约束注入
diff --git a/wiki/concepts/Viewability.md b/wiki/concepts/Viewability.md
new file mode 100644
index 00000000..1e2acb21
--- /dev/null
+++ b/wiki/concepts/Viewability.md
@@ -0,0 +1,41 @@
+---
+title: "Viewability"
+type: concept
+tags: ["viewability", "display", "brand-safety", "paid-media", "measurement"]
+sources: ["paid-media-programmatic-buyer"]
+last_updated: 2026-04-26
+---
+
+## Definition
+
+广告可见性（Viewability）是衡量数字广告是否被真实用户看到（而非仅仅被加载但不可见）的指标。MRC（Media Rating Council）定义了最低可见性标准：展示广告至少 50% 的像素在屏幕上停留 1 秒以上，Video 广告至少 50% 像素停留 2 秒以上。
+
+## Industry Standards
+
+| 标准制定方 | 要求 | 说明 |
+|-----------|------|------|
+| MRC（Media Rating Council） | 50%/1s（展示）/ 50%/2s（视频） | 最低行业标准 |
+| GroupM | 50%/2s | 更严格的可见性标准 |
+| Google Active View | 70%+ 可见展示 | 通常作为活动基准目标 |
+
+## Why Viewability Matters
+
+- **防止广告位欺诈**：仅仅加载广告不等于用户看到了
+- **品牌安全**：低可见性位置往往与低质量内容相关联
+- **效率优化**：将预算从低可见性位置转移到高可见性位置
+- **归因基础**：只有可见的展示才可能驱动品牌认知和转化
+
+## Optimization Levers
+
+- **Placement Exclusions**：排除低可见性广告位
+- **Viewability Targeting**：在 DSP 中直接设定可见性门槛竞价
+- **Supply Path Optimization**：优先选择已知高可见性发布商的交易路径
+- **Format Selection**：大尺寸格式（300x600、970x250）通常可见性更高
+
+## Success Benchmark
+
+- **目标指标**：≥70% MRC 标准可见展示率
+- **低于此标准的位置**：考虑降低出价或排除
+
+## Sources
+- [[paid-media-programmatic-buyer]]
diff --git a/wiki/concepts/Visual-Identity-System.md b/wiki/concepts/Visual-Identity-System.md
new file mode 100644
index 00000000..e85cd1e4
--- /dev/null
+++ b/wiki/concepts/Visual-Identity-System.md
@@ -0,0 +1,54 @@
+---
+title: "Visual Identity System"
+type: concept
+tags: [brand, design, visual, identity]
+last_updated: 2026-05-15
+sources: [design-brand-guardian]
+---
+
+## Definition
+
+视觉识别系统是品牌视觉元素的内聚性设计规范，包含 Logo、Color Palette、Typography 和 Spacing 四个核心维度。该系统必须作为整体设计，而非孤立元素集合。
+
+## Core Components
+
+### Logo System
+- Primary Logo：主要标志及使用规范
+- Logo Variations：水平、堆叠、图标版本
+- Clear Space：最小间距要求
+- Minimum Sizes：最小复制尺寸
+- Usage Guidelines：使用注意事项
+
+### Color System
+- Primary Palette：主品牌色（含 hex/RGB/CMYK 值）
+- Secondary Palette：辅助色
+- Neutral Palette：中性色（灰阶系统）
+- Accessibility：WCAG 合规组合
+
+### Typography
+- Primary Typeface：品牌标题字体
+- Secondary Typeface：正文字体
+- Hierarchy：尺寸和字重规范
+- Web Implementation：字体加载和降级方案
+
+### Spacing System
+基于 rem 单位的间距系统：
+- `--brand-space-xs: 0.25rem`
+- `--brand-space-sm: 0.5rem`
+- `--brand-space-md: 1rem`
+- `--brand-space-lg: 2rem`
+- `--brand-space-xl: 4rem`
+
+## Design Principles
+
+- **内聚性**：所有视觉元素协同工作形成统一系统
+- **可扩展性**：在不同应用场景和尺寸下保持有效性
+- **无障碍**：色彩对比符合 WCAG 标准
+- **文化敏感性**：在不同市场具有文化适当性
+
+## Connections
+
+- [[Brand-Foundation-Framework]] → Visual Identity System 是其视觉表达
+- [[design-brand-guardian]] → 定义了 Visual Identity System 的设计规范
+- [[design-ux-architect]] → 提供 CSS 设计系统的技术实现规范
+- [[Theme-Toggle]] → Visual Identity System 必须支持 light/dark/system 三态
diff --git a/wiki/concepts/VoiceActivityDetection.md b/wiki/concepts/VoiceActivityDetection.md
new file mode 100644
index 00000000..612c8ed6
--- /dev/null
+++ b/wiki/concepts/VoiceActivityDetection.md
@@ -0,0 +1,33 @@
+---
+title: "VoiceActivityDetection"
+type: concept
+tags: ["voice-ai", "audio-processing", "whisper"]
+last_updated: 2026-05-02
+---
+
+# VoiceActivityDetection (VAD)
+
+## Definition
+
+Voice Activity Detection（语音活动检测）是识别音频流中人类语音片段的技术，用于跳过静音区域。在 Whisper 类转录模型管道中作为预处理阶段，显著减少需要处理的音频量，提高转录效率和成本效益。
+
+## Key Properties
+
+- **典型阈值**：`min_silence_duration_ms=500`（500ms 静音才触发跳过）
+- **在 Whisper 中的角色**：`vad_filter=True` + `vad_parameters` 参数
+- **效果**：减少 ~30-50% 的静音处理，提升 1.5-2x 吞吐量
+- **误判风险**：音乐、背景语音、非语音音效可能被误判为静音
+
+## Usage in Pipeline
+
+```
+原始音频 → VAD 过滤 → 非静音片段 → FasterWhisper 转录
+```
+
+## Related Concepts
+- [[FasterWhisper]] — VAD 的主要消费方
+- [[OverlapAwareChunking]] — VAD 之后对长音频的分块处理
+- [[EBUR128LoudnessNormalization]] — VAD 之前的响度归一化（确保 VAD 阈值准确）
+
+## Related Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/concepts/Win-Theme.md b/wiki/concepts/Win-Theme.md
new file mode 100644
index 00000000..00c57ba9
--- /dev/null
+++ b/wiki/concepts/Win-Theme.md
@@ -0,0 +1,41 @@
+---
+title: "Win Theme（赢主题）"
+type: concept
+tags: [sales, proposal, positioning]
+sources: [sales-proposal-strategist]
+last_updated: 2026-04-29
+---
+
+## Definition
+
+Win Theme（赢主题）是将解决方案与买家最迫切需求直接连接的、以买家为中心的声明（3-5 条），是贯穿整个提案的叙事支柱。每个赢主题必须可被证据证明，并与竞争对手形成自然差异化。
+
+## Criteria（强赢主题标准）
+
+1. **命名买家具体挑战**，而非泛泛的行业问题
+2. **连接具体能力与可衡量成果**，而非空洞优势
+3. **差异化无需提及竞争对手**，自身优势即对比
+4. **可用证据证明**：案例数据、方法论细节或框架引用
+
+## Weak vs. Strong Examples
+
+| 类型 | 示例 |
+|------|------|
+| ❌ Weak | "We have deep experience in digital transformation" |
+| ✅ Strong | "Our migration framework reduces cutover risk by staging critical workloads in parallel — the same approach that kept [similar client] at 99.97% uptime during a 14-month platform transition" |
+
+## Integration Rules
+
+- 赢主题必须出现在：**执行摘要、方案叙事、案例研究、定价说明**四个位置
+- 孤立的主题 = 无形的主题
+- 按提案章节（而非按主题）组织内容：每个章节聚焦一个主题，其他主题作为次要支撑
+
+## Related Concepts
+
+- [[三幕式提案叙事]]：赢主题的叙事容器
+- [[赢主题矩阵]]：管理多主题的交叉分析工具
+- [[竞争定位]]：赢主题不批评对手，通过自身优势创造有机对比
+
+## Sources
+
+- [[sales-proposal-strategist]]
diff --git a/wiki/concepts/Work-Breakdown-Structure.md b/wiki/concepts/Work-Breakdown-Structure.md
new file mode 100644
index 00000000..6dc9e81f
--- /dev/null
+++ b/wiki/concepts/Work-Breakdown-Structure.md
@@ -0,0 +1,47 @@
+---
+title: "Work Breakdown Structure"
+type: concept
+tags: [project-management, planning, WBS]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+Work Breakdown Structure（WBS，工作分解结构）是将复杂项目按层级逐层拆解为原子化、可独立估算和执行的最小工作单元的方法论。遵循 100% 原则：WBS 必须包含所有项目工作，不多不少。
+
+## 分解原则
+
+| 原则 | 说明 |
+|------|------|
+| **100% 原则** | WBS 包含所有项目工作，不遗漏任何交付物 |
+| **原子性** | 每个工作包可由单人在 ≤2 周内完成 |
+| **可估算** | 每个工作包有明确的验收标准和资源需求 |
+| **可分配** | 每个工作包明确责任人或 Agent 角色 |
+
+## 层级结构
+
+```
+Project（项目）
+└── Phase（阶段）
+    └── Deliverable（交付物）
+        └── Work Package（工作包）
+            └── Task（原子任务）
+```
+
+## 应用场景
+
+- **[[Phase 1 Strategy]]**：Senior Project Manager 将 Phase 0 规范文档 + 架构规格转换为完整 WBS，每个任务必须引用规范原文（quote EXACT requirements from spec），不得添加规范外的功能
+- **[[scenario-enterprise-feature]]**：Phase 3 Build 阶段以 WBS 为输入进行 Sprint 分配
+
+## 与 RICE 的关系
+
+WBS 产出**任务列表**（Task List），RICE 评分对 WBS 产出进行**排序和分类**。WBS 是输入，RICE 是对 WBS 输出的优先级处理。
+
+## 与 Story Points 的关系
+
+WBS 中的 Work Package 可进一步估算为 Story Points（故事点），用于 Sprint 速度（Velocity）计算和发布计划预测。
+
+## Aliases
+- WBS
+- Work Breakdown
+- Task Decomposition
diff --git a/wiki/concepts/WorldPartition.md b/wiki/concepts/WorldPartition.md
index cc13b809..fea21a3a 100644
--- a/wiki/concepts/WorldPartition.md
+++ b/wiki/concepts/WorldPartition.md
@@ -1,41 +1,53 @@
 ---
-title: "World Partition"
+title: "WorldPartition"
 type: concept
-tags: ["unreal-engine", "open-world", "streaming", "ue5"]
-sources: ["unreal-world-builder", "unreal-technical-artist"]
-last_updated: 2026-04-26
+tags: ["unreal-engine", "open-world", "streaming", "level-design"]
+sources: ["unreal-world-builder"]
+last_updated: 2026-04-30
 ---
 
+## Aliases
+- UE5 World Partition
+- WP
+- World Partition System
+- 开放世界分区
+
 ## Definition
-UE5 的开放世界分区管理框架，将世界划分为网格状单元格（Cell），支持按需流送（on-demand streaming），使超大世界无需一次性全部加载到内存。
+World Partition 是 Unreal Engine 5 引入的开放世界分区管理框架，将整个世界划分为网格状单元格（Cells），按需流式加载和卸载，支持多人协作编辑（通过 One File Per Actor 模式）。
 
-## Core Concepts
+## Grid Cell Size Strategy
+| 区域类型 | 单元格尺寸 | 说明 |
+|---------|---------|------|
+| 密集城区 | 64m | 高密度流式内容 |
+| 空旷地形 | 128m | 平衡精度与开销 |
+| 沙漠/海洋 | 256m+ | 稀疏区域 |
 
-### Grid Cell Sizes
-| 内容类型 | 格子大小 | 加载范围 |
-|----------|----------|----------|
-| 密集城区 | 64m | 256m |
-| 空旷地形 | 128m | 512m |
-| 稀疏区域（沙漠/海洋） | 256m+ | 1024m+ |
+## Data Layers Configuration
+| Layer Name     | Type          | Contents                           |
+|----------------|---------------|------------------------------------|
+| AlwaysLoaded   | Always Loaded | Sky, audio manager, game systems  |
+| HighDetail     | Runtime       | Loaded when quality = High         |
+| PlayerCampData | Runtime       | Quest-specific environment changes |
 
-### Critical Rules
-- **格子大小由流送预算决定**：小格子 = 更细粒度流送但更多开销
-- **关键游戏内容禁止放在格子边界**：格子跨越时流送短暂延迟可能导致关键 NPC/任务触发器不可见
-- **Always Loaded 层**：Sky、Audio Manager、GameMode 等全局内容必须放入 Always Loaded 数据层，不能分散在流送格子中
-- **Runtime Hash Grid 配置必须在填充世界前完成**：后期修改需完整重保存关卡
+## Critical Rules
+- **格子大小由流式预算决定**：小格子 = 更精细的流式但更多开销
+- **关键游戏内容禁止放在格子边界**：边界穿越时流式可能导致实体短暂消失
+- **Always Loaded 层存放**：Sky、Audio Manager、GameMode 等常驻内容
+- **Runtime Hash Grid 单元格大小必须在填充世界前确定**：后期重配置需要完整重新保存关卡
 
-### Streaming Sources
-- **Player Pawn**：主要流送源，激活范围 = 加载范围
-- **Cinematic Camera**：辅助流送源，用于过场动画区域预加载
-- **非玩家流送源**：通过 `AWorldPartitionStreamingSourceComponent` 实现，供 AI Director、过场系统使用
+## Streaming Sources
+- **Player Pawn**：主要流式来源，512m 激活范围
+- **Cinematic Camera**：次要来源，用于过场区域预加载
 
-## OFPA (One File Per Actor)
-- 为多用户协作启用 OFPA：避免多人同时编辑同一关卡文件产生的冲突
-- 大型关卡包含数千 Actor，会生成数千个文件，需建立文件数量预算
+## Role in Open-World Pipeline
+World Partition 是 [[UnrealWorldBuilder]] 开放世界工作流的核心框架，承接 Landscape、PCG、HLOD 等系统的空间管理。
 
-## Related
-- [[UnrealWorldBuilder]] — World Partition 配置与调优专家
-- [[PCG]] — PCG 图与 World Partition Surface 协同工作
-- [[HLOD]] — World Partition 与 HLOD 系统深度集成
-- [[LOD]] — HLOD 是 World Partition 远距离渲染优化的核心机制
-- [[Nanite]] — World Partition 流送加载区域的 Nanite 几何体优化
+## Connections
+- [[UnrealWorldBuilder]] ← 工作流框架 ← WorldPartition
+- [[UnrealEngine5]] ← 核心引擎 ← WorldPartition
+- [[OneFilePerActor]] ← 协作模式 ← WorldPartition
+- [[LargeWorldCoordinates]] ← 坐标精度 ← WorldPartition
+- [[ProceduralContentGeneration]] ← 空间管理 ← WorldPartition
+
+## Sources
+- [[unreal-world-builder]]
diff --git a/wiki/concepts/X-Hermes-Session-Id.md b/wiki/concepts/X-Hermes-Session-Id.md
new file mode 100644
index 00000000..2d7ccb04
--- /dev/null
+++ b/wiki/concepts/X-Hermes-Session-Id.md
@@ -0,0 +1,30 @@
+---
+title: "X-Hermes-Session-Id"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+Hermes API Server v0.7.0+ 支持的 HTTP header，通过在请求中传递 `X-Hermes-Session-Id` 使多个独立的 Chat Completions 请求共享同一个会话上下文，实现多轮对话在无状态 HTTP 环境中的连续性。
+
+## Details
+- Header 格式：`X-Hermes-Session-Id: <session-identifier>`
+- 适用于：n8n 多步骤工作流、需要多轮推理的任务链
+- session-identifier 可自定义（如 `my-workflow-session-001`）
+- 同一个 session-id 下的多次调用会保持对话历史
+
+## Usage
+在 n8n 的 HTTP Request 节点 Header 中添加：
+```
+X-Hermes-Session-Id: my-workflow-session-001
+```
+
+## Related
+- [[OpenAI兼容API]] — 该 header 所在的 API 接口
+- [[多Profile隔离]] — Profile 与 Session 的关系：Profile 隔离进程，Session 隔离对话上下文
+- [[工作流编排]] — Session 机制使工作流编排的多步 Agent 调用具有连贯性
+
+## Aliases
+- Hermes Session Header
+- Session Continuity Header
diff --git a/wiki/concepts/Zero-Downtime Deployment.md b/wiki/concepts/Zero-Downtime Deployment.md
new file mode 100644
index 00000000..e9db7986
--- /dev/null
+++ b/wiki/concepts/Zero-Downtime Deployment.md	
@@ -0,0 +1,80 @@
+---
+title: "Zero-Downtime Deployment"
+type: concept
+tags: [DevOps, Deployment, Reliability]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
+---
+
+# Zero-Downtime Deployment
+
+## 定义
+零停机部署是一组软件部署策略，旨在更新应用程序时保持服务持续可用，避免部署过程中用户请求失败或服务中断。
+
+## 主要策略
+
+### 蓝绿部署（Blue-Green Deployment）
+- **原理**：维护两套完全相同的环境（蓝和绿），新旧版本各占一套
+- **切换**：通过负载均衡器将流量一次性从旧环境切换到新环境
+- **回滚**：切换回旧环境即可实现秒级回滚
+- **优点**：简单、切换快速、回滚容易
+- **缺点**：资源成本翻倍
+
+### 金丝雀发布（Canary Deployment）
+- **原理**：先将新版本部署到小部分服务器/用户，逐步扩大范围
+- **切换**：基于流量比例（如 5% → 20% → 100%）
+- **监控**：每个阶段监控指标，异常则暂停/回滚
+- **优点**：风险可控、可进行 A/B 测试
+- **缺点**：实现复杂度较高
+
+### 滚动更新（Rolling Update）
+- **原理**：逐步替换实例，每次替换一个或一组
+- **配置**：Kubernetes Deployment 默认策略
+- **优点**：资源利用率高，无需额外环境
+- **缺点**：新旧版本共存时间长，回滚相对慢
+
+### 特性开关（Feature Flag）
+- **原理**：通过配置开关控制功能启用/禁用
+- **部署**：代码部署与功能启用分离
+- **优点**：秒级回滚、无需重新部署
+- **缺点**：代码复杂度增加
+
+## 在 DevOps Automator 中的应用
+DevOps Automator 的标准部署流程：
+1. 部署到 green 环境
+2. 健康检查
+3. 切换流量
+4. 监控关键指标
+5. 异常自动回滚
+
+```yaml
+kubectl set image deployment/app app=registry/app:${{ github.sha }}
+kubectl rollout status deployment/app
+kubectl patch svc app -p '{"spec":{"selector":{"version":"green"}}}'
+```
+
+## 相关概念
+- [[CI/CD Pipeline]]：零停机部署是 CI/CD 流水线的最终目标
+- [[Kubernetes]]：K8s 原生支持 Rolling Update 和 Canary Deployment
+- [[Blue-Green Deployment]]：最常用的零停机部署策略
+
+## 关键考虑因素
+- **健康检查**：必须配置主动和被动健康检查
+- **数据库迁移**：需要向后兼容的 Schema 变更
+- **会话管理**：确保用户会话在版本间保持有效
+- **缓存策略**：避免旧缓存导致行为不一致
+
+## 成功指标
+- 部署期间请求失败率：0%
+- 部署期间延迟增长：< 5%
+- 回滚时间：< 1 分钟
+
+## Aliases
+- Zero Downtime Deployment
+- 无停机部署
+- 滚动更新
+- Rolling Deployment
+- 金丝雀发布
+- Canary Release
+- 蓝绿部署
+- Blue-Green Deployment
diff --git a/wiki/concepts/ZeroDataLossGuarantee.md b/wiki/concepts/ZeroDataLossGuarantee.md
new file mode 100644
index 00000000..1cfe1b96
--- /dev/null
+++ b/wiki/concepts/ZeroDataLossGuarantee.md
@@ -0,0 +1,43 @@
+---
+title: "Zero Data Loss Guarantee"
+type: concept
+tags: []
+last_updated: 2026-05-01
+---
+
+## Definition
+
+通过数学约束强制执行 `Source_Rows == Success_Rows + Quarantine_Rows` 的数据修复保证机制。任何不匹配立即触发 Sev-1 告警与系统异常。
+
+## Invariant
+
+```
+Source_Rows == Success_Rows + Quarantine_Rows
+```
+
+## Row Lifecycle
+
+| State | Description | Destination |
+|-------|-------------|-------------|
+| `AI_FIXED` | SLM 置信度 ≥ 0.75，lambda 验证通过 | Staging → Production |
+| `HUMAN_REVIEW` | 置信度 < 0.75，或无法自动修复 | Human Quarantine Dashboard |
+
+## Guarantees
+
+- **Mathematical constraint, not a goal**: 不满足等式时系统立即失败，不允许静默通过
+- **Full tracking**: 每条异常行在修复生命周期中始终被追踪
+- **No silent corruption**: 修复后的数据先到 staging，确认后才写生产
+
+## Alert Conditions
+
+```python
+if source != success + quarantine:
+    trigger_alert(severity="SEV1", message=f"DATA LOSS DETECTED: {missing} rows")
+    raise DataLossException(...)
+```
+
+## Related
+
+- [[Semantic Anomaly Compression]]
+- [[Air-Gapped SLM Fix Generation]]
+- [[Lambda Safety Gate]]
diff --git a/wiki/concepts/n8n-Workflow-Standard.md b/wiki/concepts/n8n-Workflow-Standard.md
new file mode 100644
index 00000000..e7d08999
--- /dev/null
+++ b/wiki/concepts/n8n-Workflow-Standard.md
@@ -0,0 +1,62 @@
+---
+title: "n8n Workflow Standard"
+type: concept
+tags: [n8n, workflow, automation, reliability, standard]
+sources: [automation-governance-architect]
+last_updated: 2026-05-01
+---
+
+# n8n Workflow Standard
+
+n8n 生产级工作流十步标准，所有节点必须遵循该结构，禁止节点失控扩散。
+
+## 命名规范
+遵循 `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]` 格式，如：
+- `PROD-CRM-LeadIntake-CreateRecord-v1.0`
+- `TEST-DMS-DocumentArchive-Upload-v0.4`
+
+## 十步标准（强制）
+
+1. **Trigger**：触发器定义（定时 / Webhook / 事件）
+2. **Input Validation**：输入校验
+3. **Data Normalization**：数据标准化
+4. **Business Logic**：业务逻辑
+5. **External Actions**：外部操作（API 调用等）
+6. **Result Validation**：结果校验
+7. **Logging / Audit Trail**：日志与审计追踪
+8. **Error Branch**：错误分支
+9. **Fallback / Manual Recovery**：备用路径 / 人工恢复
+10. **Completion / Status Writeback**：完成状态回写
+
+## Reliability Baseline（可靠性基线）
+
+每个重要工作流必须包含：
+- 显式错误分支（explicit error branches）
+- 幂等性或重复保护（idempotency or duplicate protection）
+- 安全重试（含停止条件）（safe retries with stop conditions）
+- 超时处理（timeout handling）
+- 告警 / 通知行为（alerting/notification）
+- 人工 fallback 路径（manual fallback path）
+
+## Logging Baseline（日志基线）
+
+最小日志记录：
+- 工作流名称和版本
+- 执行时间戳
+- 源系统
+- 受影响实体 ID
+- 成功 / 失败状态
+- 错误类型及简要原因
+
+## Testing Baseline（测试基线）
+
+生产推荐前必须完成：
+- 快乐路径测试（happy path test）
+- 无效输入测试（invalid input test）
+- 外部依赖失败测试（external dependency failure test）
+- 重复事件测试（duplicate event test）
+- Fallback / 恢复测试（fallback or recovery test）
+- 规模 / 重复合理性检查（scale/repetition sanity check）
+
+## Sources
+- [[automation-governance-architect]]
diff --git a/wiki/concepts/nav.index.jsonl.md b/wiki/concepts/nav.index.jsonl.md
new file mode 100644
index 00000000..7371fc09
--- /dev/null
+++ b/wiki/concepts/nav.index.jsonl.md
@@ -0,0 +1,45 @@
+---
+title: "nav.index.jsonl"
+type: concept
+tags: ["code-navigation", "symbol-index", "LSP", "JSONL", "semantic-graph"]
+sources: ["lsp-index-engineer.md"]
+last_updated: 2026-04-29
+---
+
+## Definition
+nav.index.jsonl 是 LSP/Index Engineer 定义的导航索引文件格式，以 JSONL（每行一条 JSON 记录）流式存储每个符号的导航信息，用于快速符号查找和代码导航服务。
+
+## Format Specification
+
+### Symbol Definition Record
+```jsonl
+{"symId":"sym:AppController","def":{"uri":"file:///src/controllers/app.php","l":10,"c":6}}
+```
+记录符号定义位置：`symId`（符号唯一 ID）、`def.uri`（文件 URI）、`def.l`（行号）、`def.c`（列号）
+
+### Symbol References Record
+```jsonl
+{"symId":"sym:AppController","refs":[
+  {"uri":"file:///src/routes.php","l":5,"c":10},
+  {"uri":"file:///tests/app.test.php","l":15,"c":20}
+]}
+```
+记录符号所有引用位置
+
+### Hover Documentation Record
+```jsonl
+{"symId":"sym:useState","hover":{"contents":{"kind":"markdown","value":"```typescript\nconst [state, setState] = useState()\n```\nReact state hook"}}}
+```
+记录符号的悬停文档内容
+
+## Core Properties
+- **流式写入**：每次增量更新追加新记录，无需全量重建
+- **原子性更新**：确保图谱从不处于不一致状态
+- **快速查询**：通过 symId 直接索引，O(1) 查找
+- **LSIF 兼容**：支持导入/导出 Language Server Index Format 预计算数据
+
+## Connections
+- [[nav.index.jsonl]] ← is_format_of ← [[SemanticCodeGraph]]
+- [[nav.index.jsonl]] ← built_by ← [[GraphDaemon]]
+- [[nav.index.jsonl]] ← uses ← [[IncrementalGraphUpdate]]
+- [[nav.index.jsonl]] ← can_be_exported_as ← [[LSIF]]
diff --git a/wiki/concepts/qmd.md b/wiki/concepts/qmd.md
new file mode 100644
index 00000000..aef06c1a
--- /dev/null
+++ b/wiki/concepts/qmd.md
@@ -0,0 +1,27 @@
+---
+title: "qmd"
+type: concept
+tags: [tool, search, markdown, local]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- qmd 搜索引擎
+- qmd Markdown search
+
+## Definition
+一个**完全本地运行**的 Markdown 搜索引擎（[github.com/tobi/qmd](https://github.com/tobi/qmd)），Karpathy 推荐用于大规模 Wiki 的精准检索。LLM Wiki 的可选增强工具。
+
+## When to Use
+- Wiki 规模小（几百个页面）时，`index.md` 目录文件完全够用
+- Wiki 规模大后，AI 找东西变慢时，接入 qmd 不迟
+
+## Key Advantage
+- 完全本地运行，无隐私风险
+- 支持语义搜索（而非仅关键词匹配）
+- 专为 Markdown 文件设计
+
+## Connections
+- [[qmd]] ← 搜索工具 ← [[LLM Wiki]]
+- [[qmd]] ← 可选 → [[LLM Wiki]]
diff --git a/wiki/concepts/三档翻译系统.md b/wiki/concepts/三档翻译系统.md
new file mode 100644
index 00000000..99be5457
--- /dev/null
+++ b/wiki/concepts/三档翻译系统.md
@@ -0,0 +1,58 @@
+---
+title: "三档翻译系统"
+type: concept
+tags: []
+sources: [baoyu-skills]
+last_updated: 2026-04-19
+---
+
+## Overview
+
+三档翻译系统是 [[baoyu-translate]] 技能提供的渐进式翻译质量体系，通过快速、标准、精翻三档模式满足不同翻译需求层次，精翻模式含审校与润色步骤。
+
+## Three Tiers
+
+| 模式 | 步骤 | 适用场景 | 特点 |
+| --- | --- | --- | --- |
+| **快速** | 翻译 | 短文本、非正式内容 | 即时输出，适合内部沟通 |
+| **标准**（默认） | 分析 → 翻译 | 文章、博客、技术文档 | 先理解再翻译，平衡速度与质量 |
+| **精翻** | 分析 → 翻译 → 审校 → 润色 | 出版级文档、高质量内容 | 完整工作流，含质量保证层 |
+
+标准模式完成后，用户可回复「继续润色」或「refine」触发审校润色步骤。
+
+## Supporting Features
+
+### 受众预设
+
+| 受众 | 说明 |
+| --- | --- |
+| `general` | 普通读者——通俗语言，更多译注（默认） |
+| `technical` | 开发者/工程师——常见技术术语少加注释 |
+| `academic` | 研究者/学者——正式语体，精确术语 |
+| `business` | 商务人士——商务友好语气 |
+
+### 风格预设
+
+| 风格 | 说明 |
+| --- | --- |
+| `storytelling` | 叙事流畅——过渡自然，表达生动（默认） |
+| `formal` | 正式、结构化——中性语气 |
+| `technical` | 精确、文档风格——简洁，术语密集 |
+| `literal` | 贴近原文结构——最小化重构 |
+| `academic` | 学术、严谨——复杂从句可接受 |
+| `business` | 简洁、结果导向——行动导向 |
+| `humorous` | 保留幽默感——诙谐，重现喜剧效果 |
+| `conversational` | 口语化、亲切——友好，如同朋友间解释 |
+| `elegant` | 文学性、优雅——注重韵律美感 |
+
+### 其他特性
+
+- **术语表**：通过 `EXTEND.md` 自定义术语表，内置英中对照表
+- **长文档分块**：4000+ 词自动分块并行翻译
+- **比喻意译**：修辞手法按意译而非逐字翻译
+- **译注**：为文化/专业术语添加译注
+- **输出保留**：输出目录保留所有中间文件
+
+## Connections
+- [[baoyu-translate]] ← implements ← 三档翻译系统
+- [[baoyu-skills]] ← 包含 ← 三档翻译系统
diff --git a/wiki/concepts/多Profile隔离.md b/wiki/concepts/多Profile隔离.md
new file mode 100644
index 00000000..e59713a5
--- /dev/null
+++ b/wiki/concepts/多Profile隔离.md
@@ -0,0 +1,35 @@
+---
+title: "多Profile隔离"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+Hermes Agent 的 Profile 机制允许为每个角色/用户创建独立的配置实例，每个 Profile 拥有独立的端口、API Key、工具集和会话状态，实现多 Agent 的进程级隔离与并发协作。
+
+## Details
+- 每个 Profile 是独立运行的 Hermes 实例
+- 典型分工示例：agent-researcher（8643）、agent-writer（8644）、agent-coder（8645）
+- 端口和 API Key 均可独立配置
+- Profile 之间完全隔离，不会相互干扰会话上下文
+
+## Usage
+```bash
+# 创建专属 Agent
+hermes profile create agent-researcher
+hermes -p agent-researcher config set API_SERVER_ENABLED true
+hermes -p agent-researcher config set API_SERVER_PORT 8643
+hermes -p agent-researcher config set API_SERVER_KEY key-researcher
+hermes -p agent-researcher gateway &
+```
+
+## Related
+- [[HermesAgent]] — Profile 机制的基础框架
+- [[OpenAI兼容API]] — 每个 Profile 暴露的调用接口
+- [[工作流编排]] — 多 Profile 配合 n8n 实现分工协作
+
+## Aliases
+- Multi-Profile Isolation
+- Profile-based multi-tenancy
+- Agent Profile Isolation
diff --git a/wiki/concepts/多Provider图像生成.md b/wiki/concepts/多Provider图像生成.md
new file mode 100644
index 00000000..fd01e7b4
--- /dev/null
+++ b/wiki/concepts/多Provider图像生成.md
@@ -0,0 +1,51 @@
+---
+title: "多Provider图像生成"
+type: concept
+tags: []
+sources: [baoyu-skills]
+last_updated: 2026-04-19
+---
+
+## Overview
+
+多 Provider 图像生成是 [[baoyu-imagine]] 技能的核心架构——通过统一接口封装多个图像生成服务商，实现 provider 自动选择和环境变量配置管理，用户无需关心底层服务商细节。
+
+## Supported Providers
+
+| Provider | API | 模型 | 特色 |
+| --- | --- | --- | --- |
+| OpenAI | `OPENAI_API_KEY` | gpt-image-1.5 | 主流，质量稳定 |
+| Google | `GOOGLE_API_KEY` | gemini-3-pro-image-preview | 高质量 |
+| Azure OpenAI | `AZURE_OPENAI_API_KEY` | 可配置部署名 | 企业级 |
+| OpenRouter | `OPENROUTER_API_KEY` | google/gemini-3.1-flash-image-preview | 统一网关 |
+| DashScope（阿里通义万相） | `DASHSCOPE_API_KEY` | qwen-image-2.0-pro | 中文优化，支持 21:9 |
+| Z.AI | `ZAI_API_KEY` | glm-image | 海报/图表，中英文 |
+| MiniMax | `MINIMAX_API_KEY` | image-01 | 低延迟，支持参考图 |
+| 即梦（Jimeng） | 火山引擎 Key | jimeng_t2i_v40 | 国内直达 |
+| 豆包（Seedream） | ARK API Key | doubao-seedream-5-0-260128 | 参考图能力强 |
+| Replicate | `REPLICATE_API_TOKEN` | google/nano-banana-2 | nano-banana 系列 |
+
+## Auto-Selection Logic
+
+1. 显式指定 `--provider` → 使用指定的
+2. 传入 `--ref` 参考图且未指定 provider → 依次尝试 Google、OpenAI、Azure、OpenRouter、Replicate、Seedream、MiniMax
+3. 只有一个 API 密钥 → 使用对应服务商
+4. 多个可用 → 默认优先级：Google > OpenAI > Azure > OpenRouter > DashScope > Z.AI > MiniMax > Replicate > 即梦 > 豆包
+
+## Configuration Hierarchy
+
+环境变量通过四层加载（高优先级覆盖低优先级）：
+1. 命令行环境变量
+2. `process.env`（系统环境变量）
+3. `~/.baoyu-skills/.env`（用户级）
+4. `<cwd>/.baoyu-skills/.env`（项目级）
+
+## Key Design Decisions
+
+- `--model` 参数在 Azure 表示 deployment name（不是底层模型家族名）
+- 参考图能力因 provider 而异：Google/OpenAI/Azure/OpenRouter/Replicate/MiniMax/Seedream 5.0/4.5/4.0 支持；即梦不支持
+- Replicate 只保存单张输出图，`--n > 1` 会本地报错避免结果静默丢弃
+
+## Connections
+- [[baoyu-imagine]] ← implements ← 多Provider图像生成
+- [[baoyu-skills]] ← 包含 ← 多Provider图像生成
diff --git a/wiki/concepts/多维度图像生成系统.md b/wiki/concepts/多维度图像生成系统.md
new file mode 100644
index 00000000..ec2dcdb6
--- /dev/null
+++ b/wiki/concepts/多维度图像生成系统.md
@@ -0,0 +1,58 @@
+---
+title: "多维度图像生成系统"
+type: concept
+tags: []
+sources: [baoyu-skills]
+last_updated: 2026-04-19
+---
+
+## Overview
+
+多维度图像生成系统是 [[baoyu-skills]] 中内容生成类技能（baoyu-xhs-images、baoyu-cover-image、baoyu-article-illustrator 等）的核心方法论。通过多个正交维度组合控制 AI 生成图像的视觉输出，每个维度独立调节一个方面，组合效果呈乘法关系（参数空间巨大）。
+
+## Dimensions
+
+典型维度组合：
+
+| 维度 | 说明 | 示例值 |
+| --- | --- | --- |
+| **类型 (Type)** | 图像的信息结构角色 | hero、conceptual、typography、infographic |
+| **风格 (Style)** | 视觉美学 | cute、notion、bold、watercolor、chalkboard |
+| **配色 (Palette)** | 颜色方案覆盖 | macaron、warm、neon |
+| **渲染 (Rendering)** | 渲染技法 | flat-vector、hand-drawn、painterly、digital |
+| **氛围 (Mood)** | 整体情绪调性 | subtle、balanced、bold |
+| **布局 (Layout)** | 信息密度/构图 | sparse、balanced、dense、list、comparison |
+
+## Key Examples
+
+### 小红书卡片（baoyu-xhs-images）
+- 12 种风格 × 6 种布局 × 3 种配色 = **216 种组合**
+- 风格：cute、fresh、warm、bold、minimal、retro、pop、notion、chalkboard、study-notes、screen-print、sketch-notes
+- 布局：sparse（封面/金句）、balanced（常规内容）、dense（知识卡片）、list（清单/排行）、comparison（对比）、flow（流程/时间线）
+
+### 信息图（baoyu-infographic）
+- 20 种布局 × 17 种风格 = **340 种组合**
+- 布局覆盖：bridge、funnel、pyramid、venn、fishbone、mind-map 等
+- 风格覆盖：craft-handmade、claymation、kawaii、cyberpunk-neon、technical-schematic、lego-brick 等
+
+### 封面图（baoyu-cover-image）
+- 6 种类型 × 11 种配色 × 7 种渲染 = **462 种组合**
+- 类型：hero、conceptual、typography、metaphor、scene、minimal
+- 配色：warm、elegant、cool、dark、earth、vivid、pastel、mono、retro、duotone、macaron
+
+### 文章插图（baoyu-article-illustrator）
+- 6 种类型 × 8 种风格 × 3 种色板 = **144 种组合**
+- 类型：infographic、scene、flowchart、comparison、framework、timeline
+
+## Core Principle
+
+**正交性**：每个维度独立调节一个视觉方面，互不干扰，通过组合实现高度可定制的输出。
+
+**参数化覆盖层**（EXTEND.md）：通过项目级或用户级 `EXTEND.md` 文件定义自定义配色/风格预设，覆盖默认值，实现品牌一致性。
+
+## Connections
+- [[baoyu-skills]] ← implements ← 多维度图像生成系统
+- [[baoyu-xhs-images]] ← 应用场景 ← 多维度图像生成系统
+- [[baoyu-infographic]] ← 应用场景 ← 多维度图像生成系统
+- [[baoyu-cover-image]] ← 应用场景 ← 多维度图像生成系统
+- [[baoyu-article-illustrator]] ← 应用场景 ← 多维度图像生成系统
diff --git a/wiki/concepts/工作流编排.md b/wiki/concepts/工作流编排.md
new file mode 100644
index 00000000..a6ece890
--- /dev/null
+++ b/wiki/concepts/工作流编排.md
@@ -0,0 +1,38 @@
+---
+title: "工作流编排"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+通过工作流自动化平台（如 n8n）协调和串联多个 AI Agent，使它们在统一的流程中有序执行、分工协作，共同完成复杂任务（如调研→写作→编码的完整链路）。
+
+## Details
+- 编排层负责：触发条件、路由决策、数据传递、结果聚合
+- 典型模式：n8n HTTP Request 节点分别调用 researcher/writer/coder 三个 Agent
+- 优势：零代码集成、无需额外中间件、完全原生支持
+- 挑战：会话保持（通过 `[[X-Hermes-Session-Id]]` 解决）、错误处理、超时管理
+
+## Architecture
+```
+n8n Workflow
+    │
+    ├─ [HTTP Request] → localhost:8643  (agent-researcher) → 搜索/调研
+    │
+    ├─ [HTTP Request] → localhost:8644  (agent-writer)     → 内容生成
+    │
+    └─ [HTTP Request] → localhost:8645  (agent-coder)      → 代码任务
+```
+
+## Related
+- [[n8n]] — 工作流编排平台
+- [[HermesAgent]] — 被编排的 Agent
+- [[多Profile隔离]] — 多 Agent 并发协作的基础
+- [[X-Hermes-Session-Id]] — 会话上下文保持机制
+
+## Aliases
+- Workflow Orchestration
+- Multi-Agent Orchestration
+- Agent Coordination
+- 工作流自动化
diff --git a/wiki/concepts/私域运营.md b/wiki/concepts/私域运营.md
index 310ab77a..86aed143 100644
--- a/wiki/concepts/私域运营.md
+++ b/wiki/concepts/私域运营.md
@@ -2,8 +2,8 @@
 title: "私域运营"
 type: concept
 tags: ["private-domain", "marketing", "wecom", "user-lifecycle"]
-sources: ["marketing-private-domain-operator"]
-last_updated: 2026-04-26
+sources: ["marketing-private-domain-operator", "marketing-china-market-localization-strategist"]
+last_updated: 2026-04-30
 ---
 
 # 私域运营（Private Domain Operations）
diff --git a/wiki/concepts/老铁经济.md b/wiki/concepts/老铁经济.md
index 75219217..36e4a7d5 100644
--- a/wiki/concepts/老铁经济.md
+++ b/wiki/concepts/老铁经济.md
@@ -1,37 +1,30 @@
 ---
 title: "老铁经济"
 type: concept
-tags: []
-sources: []
-last_updated: 2026-04-21
+tags: [快手生态, 粉丝关系, 信任经济]
+sources: [marketing-kuaishou-strategist]
+last_updated: 2026-04-30
 ---
 
-# 老铁经济
+## 定义
+快手独有的以信任和忠诚为基础的粉丝关系经济模式。"老铁"原为东北方言，指称关系亲密的朋友。在快手语境中，老铁代表一种经过长期互动建立的、主播与粉丝之间的兄弟情谊式信任关系。
 
-## Aliases
-- 老铁关系
-- 兄弟经济
-- Brotherhood Economy
+## 核心机制
+- **信任积累**：通过持续的真实性内容输出，逐步建立粉丝信任
+- **关系深化**：粉丝团运营、评论区互动、私域微信转化
+- **商业转化**：信任建立后才进行商业变现，老铁愿意重复购买并主动辩护
+- **终极信号**：老铁自发在评论区为品牌/主播辩护，代表最高信任等级
 
-## Definition
-快手平台特有的创作者-粉丝关系模式，以真实信任和长期忠诚为核心，区别于抖音的算法依赖型浅关系。核心是"创作者像朋友一样对待粉丝，粉丝像支持朋友一样购买"。
+## 运营要点
+- 生产真实场景内容（工厂参观、产品测试）而非精致推销
+- 主播自称使用家中同款、主动提供退换承诺
+- 通过价格谈判故事展示为主播谋福利的形象
+- 直播后 1 小时内响应所有未回答问题
 
-## Core Principles
-1. **信任先于销售**：建立真正的关系后再尝试商业转化
-2. **真实性高于一切**：粉丝能即时识别并拒绝不真实内容
-3. **社区归属感**：粉丝团、粉丝群创造真正的社群归属
-4. **长期忠诚**：慢积累，高复购，抵制不诚信卖家
+## 相关概念
+- [[下沉市场]]：老铁经济的核心用户群体
+- [[私域运营]]：老铁关系的沉淀与变现渠道
+- [[内容真实性]]：老铁关系建立的前提
 
-## Mechanisms
-- **粉丝团运营**：建立专属粉丝群（微信群或快手粉丝团）
-- **评论区互动**：创作者亲自回复评论，加强情感纽带
-- **工厂探访/产品溯源**：展示真实供应链，增强产品信任
-- **无条件的退换承诺**："不好用直接来找我，我给你退"
-
-## Relationship to 直播带货
-老铁经济是快手直播带货成功的基础——粉丝购买不是因为算法推荐，而是因为信任这个创作者。3-2-1产品介绍公式通过建立真实信任来实现销售转化。
-
-## Related
-- [[Kuaishou]]：老铁经济的平台载体
-- [[Marketing-Kuaishou-Strategist]]：老铁经济策略的具体执行 Agent
-- [[直播带货]]：老铁经济的商业化路径
+## 相关来源
+- [[marketing-kuaishou-strategist]]
diff --git a/wiki/concepts/품의.md b/wiki/concepts/품의.md
index 2eeda0e8..e44e872b 100644
--- a/wiki/concepts/품의.md
+++ b/wiki/concepts/품의.md
@@ -1,54 +1,54 @@
----
-title: "품의"
-type: concept
-tags: []
-sources: []
-last_updated: 2026-04-25
----
-
-## 基本信息
-- **原文**：품의（品意）
-- **英文**：Consensus Approval / Internal Review Process
-- **中文**：共识审批流程
-- **发音**：pum-ui
-
-## 定义
-품의（품의서）是韩国企业决策的核心机制，指在正式批准之前需要经过多层级的内部讨论和共识达成。与西方"经理点头即可决策"不同，韩国商业决策需要通过**完整审批链（결재 라인）**的层层确认。
-
-## 品의 六阶段时间线
-
-| 阶段 | 韩文 | 持续时间 | 供应商角色 | 积极信号 |
-|------|------|----------|-----------|---------|
-| 介绍 | 소개 | 1-2 周 | 通过介绍人正确接入 | 有影响力的介绍人 |
-| 会议 | 미팅 | 1-3 次会议 | 多听少说，了解挑战 | 邀请同事参加第二会议 |
-| 内部审查 | 내부검토 | 2-4 周 | 提供可内部传阅的材料 | 索取参考案例 |
-| 审批文件 | 품의서 | 1-2 周 | 无法影响（联系人撰写） | 询问具体价格/范围/时间 |
-| 审批链 | 결재 | 1-3 周 | 等待，每周不超一次跟进 | "상부에서 검토 중입니다" |
-| 合同 | 계약 | 1-2 周 | 法律审查，印章（도장）执行 | 标准阶段 |
-
-## 品의 时间对比
-
-| 公司类型 | 品의耗时 | 建议跟进频率 |
-|---------|---------|------------|
-| SME（中小企业） | 6-10 周 | 每周 |
-| 中型企业 | 8-12 周 | 每两周 |
-| 财阀（Chaebol） | 12-16 周 | 每月 |
-
-西方思维：会议 → 提案 → 决策 → 合同（2-4 周）
-韩国现实：紹介 → 会议 → 内部审查 → 品의서 → 결재라인 → 合同（6-16 周）
-
-## 关键原则
-1. **永远不要在第一次会议要求时间线**——等于暴露无知
-2. **永远不要绕过联系人直接联系其上级**——越级是关系终结行为
-3. **品의서 文件供应商无法看到或影响**——联系人自行撰写
-4. **沉默（3-7 天）不等于拒绝**——通常是内部讨论在进行
-5. **"상부에서 검토 중입니다"（上级正在审查）是积极信号**——意味着在推进
-
-## Aliases
-- 품의서（审批文件）
-- 결재 라인（审批链）
-- Consensus Approval
-- 내부검토（内部审查）
-
-## 来源
-- [[specialized-korean-business-navigator]] — 품의 Approval Process Timeline 完整规范
+---
+title: "품의"
+type: concept
+tags: []
+sources: [specialized-korean-business-navigator]
+last_updated: 2026-04-25
+---
+
+## 基本信息
+- **原文**：품의（品意）
+- **英文**：Consensus Approval / Internal Review Process
+- **中文**：共识审批流程
+- **发音**：pum-ui
+
+## 定义
+품의（품의서）是韩国企业决策的核心机制，指在正式批准之前需要经过多层级的内部讨论和共识达成。与西方"经理点头即可决策"不同，韩国商业决策需要通过**完整审批链（결재 라인）**的层层确认。
+
+## 品의 六阶段时间线
+
+| 阶段 | 韩文 | 持续时间 | 供应商角色 | 积极信号 |
+|------|------|----------|-----------|---------|
+| 介绍 | 소개 | 1-2 周 | 通过介绍人正确接入 | 有影响力的介绍人 |
+| 会议 | 미팅 | 1-3 次会议 | 多听少说，了解挑战 | 邀请同事参加第二会议 |
+| 内部审查 | 내부검토 | 2-4 周 | 提供可内部传阅的材料 | 索取参考案例 |
+| 审批文件 | 품의서 | 1-2 周 | 无法影响（联系人撰写） | 询问具体价格/范围/时间 |
+| 审批链 | 결재 | 1-3 周 | 等待，每周不超一次跟进 | "상부에서 검토 중입니다" |
+| 合同 | 계약 | 1-2 周 | 法律审查，印章（도장）执行 | 标准阶段 |
+
+## 品의 时间对比
+
+| 公司类型 | 品의耗时 | 建议跟进频率 |
+|---------|---------|------------|
+| SME（中小企业） | 6-10 周 | 每周 |
+| 中型企业 | 8-12 周 | 每两周 |
+| 财阀（Chaebol） | 12-16 周 | 每月 |
+
+西方思维：会议 → 提案 → 决策 → 合同（2-4 周）
+韩国现实：紹介 → 会议 → 内部审查 → 品의서 → 결재라인 → 合同（6-16 周）
+
+## 关键原则
+1. **永远不要在第一次会议要求时间线**——等于暴露无知
+2. **永远不要绕过联系人直接联系其上级**——越级是关系终结行为
+3. **品의서 文件供应商无法看到或影响**——联系人自行撰写
+4. **沉默（3-7 天）不等于拒绝**——通常是内部讨论在进行
+5. **"상부에서 검토 중입니다"（上级正在审查）是积极信号**——意味着在推进
+
+## Aliases
+- 품의서（审批文件）
+- 결재 라인（审批链）
+- Consensus Approval
+- 내부검토（内部审查）
+
+## 来源
+- [[specialized-korean-business-navigator]] — 품의 Approval Process Timeline 完整规范
diff --git a/wiki/concepts/회식.md b/wiki/concepts/회식.md
new file mode 100644
index 00000000..80f0fd8c
--- /dev/null
+++ b/wiki/concepts/회식.md
@@ -0,0 +1,87 @@
+---
+title: "회식"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-05-30
+---
+
+## 基本信息
+- **原文**：회식（會食）
+- **发音**：hoesik
+- **中文**：公司聚餐 / 商务饮酒文化
+- **英文**：Company dinner / Business drinking culture
+
+## 定义
+회식（会食）是韩国商业文化中最重要的关系建立机制之一，指公司或团队一起用餐和饮酒的非正式社交活动。对外国专业人员来说，회식出席是**预期而非可选**——拒绝参加会严重损害商业关系和信任建立。
+
+## 회식 的商业价值
+在办公室环境里，韩国人严格遵守上下级关系和正式礼仪。而회식创造了一个相对放松的环境，上下级界限被酒精和食物软化，是：
+- **建立真实人际关系的唯一场合**
+- **了解联系人真实想法的安全空间**
+- **从"供应商"升级为"朋友"的转折点**
+- **商业决策可能在회식中最终敲定**（在办公室的走廊/餐桌旁）
+
+## 礼仪规范（完整版）
+
+### 入座
+- **상석（主座）**：最远离门口的位置，最尊贵
+- **次尊位**：主座对面（面向门的位置）
+- **其他人**：依次按职位高低分配
+- **等待主人（最资深者）入座后再坐**
+
+### 斟酒礼仪
+- **为他人斟酒是义务**：用双手扶瓶身，显示尊重
+- **用双手接受**：对方斟酒时双手托杯接受
+- **接受第一杯**：拒绝第一杯是失礼
+- **礼尚往来**：收到斟酒后应回斟
+- ** seniors 优先**：先为最资深者斟酒
+
+### 祝酒
+- **祝酒词**："건배"（干杯）或"위하여"（为了）
+- **碰杯**：碰杯时杯沿要低于 seniors 的杯子（表示尊敬）
+- **不可自己和自己碰杯**
+
+### 烧酒/啤酒/食物节奏
+| 轮次 | 内容 | 外国人的正确做法 |
+|------|------|----------------|
+| 第一轮 | 소주（烧酒）+ 简单菜肴 | 接受并积极参与 |
+| 第二轮 | 更多食物，소주继续 | 可适度控制，但不要过早退出 |
+| 第三轮（2차） | 换地方，继续饮酒 | 如果被邀请2차（第二轮）说明关系在升温 |
+| 咖啡（3차） | 醒酒场所 | 可选择是否参加 |
+
+### 饮酒态度
+- **可以说"한 잔만 더"**（再一杯就好）：比直接拒绝更优雅
+- **不要空腹大量饮酒**：韩国人理解外国人酒量不同
+- **带现金**：虽然 senior 通常付款，但可以主动要求付2차或咖啡
+- **绝对不要**：酒后失言、讨论敏感商业话题（竞争、价格、投诉）
+
+### 食物礼仪
+- **等待最资深者先动筷**：在 senior 开始前不要先吃
+- **不要把最后一块食物拿走**：留给大家或等 senior 分配
+- **不要舔筷子或直立筷子**：筷子的禁忌同样适用于회식
+
+## 회식作为购买信号
+| 信号 | 含义 |
+|------|------|
+| 被邀请参加회식 | 信任度提升，关系从"介绍"向"信任"过渡 |
+| 联系人私下（非工作时间）联系 | 关系升温 |
+| 被邀请参加2차 | 强信任信号 |
+| 联系人主动询问个人生活 | 关系已达到朋友层级 |
+
+## 西方专业人员的常见误区
+1. **拒绝参加**："我明天要早起"——这会让联系人感到不被重视
+2. **过早离开**：会议结束就离开，没有给회식足够时间
+3. **过度饮酒**：失去对行为的控制是最危险的后果
+4. **在회식中讨论生意**：这是建立关系的时刻，不是推销时机
+5. **不参与斟酒互敬**：独善其身显得不融入
+
+## Aliases
+- 회식 문화
+- 商务聚餐
+- 韩国饮酒文化
+- Company Drinking Culture
+- 2차（第二摊）
+
+## 来源
+- [[specialized-korean-business-navigator]] — Business Dining Protocol 章节
diff --git a/wiki/entities/1point3acres.md b/wiki/entities/1point3acres.md
new file mode 100644
index 00000000..fe37e292
--- /dev/null
+++ b/wiki/entities/1point3acres.md
@@ -0,0 +1,58 @@
+---
+title: "1point3acres（一亩三分地）"
+type: entity
+tags: []
+sources: [study-abroad-advisor]
+last_updated: 2026-05-29
+---
+
+# 1point3acres（一亩三分地）
+
+## Definition
+
+1point3acres（一亩三分地）——中国最具影响力的留学生社区论坛之一，专注于北美（美国、加拿大）留学申请、求职就业、移民签证等话题。域名取自成语"皇帝不到一亩三分地"，寓意社区聚焦留学生个人发展和留学生活。
+
+## Core Functions
+
+| 功能 | 说明 |
+|------|------|
+| 录取数据库 | 申请者自主提交 offer/ rejection 数据，可按学校、专业、GPA 等筛选 |
+| 就职论坛 | 留学生就业经验分享、薪资数据、公司点评 |
+| 签证移民 | F-1、H-1B、绿卡申请经验与政策讨论 |
+| 申请选校 | 在校生/校友分享真实就读体验和就业去向 |
+| 找工跳槽 | 内推信息、面试经验、薪资谈判 |
+
+## Key Data Products
+
+### 录取数据库（Admission Database）
+- 用户自主上传 offer/rejection 记录
+- 包含 GPA、GT 成绩、本科背景、申请结果、时间线等
+- 可按学校+项目筛选，查看历史录取趋势
+- 是 Study Abroad Advisor 用于数据驱动选校的重要参考来源之一
+
+### 就职薪资数据
+- 用户匿名提交 base/signing/total compensation
+- 按公司/职位/地点/年级分层
+- 是北美留学生了解行业薪资水平的重要参考
+
+## Relationship to Study Abroad Planning
+
+[[study-abroad-advisor]] 在进行选校推荐时，鼓励学生通过 1point3acres 验证关键数据：
+- 通过校友页/在读生分享核实专业真实就读体验
+- 通过录取数据库交叉验证选校概率区间
+- 通过就职论坛评估毕业后就业前景
+
+该论坛也是学生发现"信息不对称"的重要工具——例如某项目实际录取偏好与官网描述存在差异时，社区会及时披露。
+
+## Reliability Considerations
+
+- **数据来源**：用户自主提交，存在样本偏差（成功者偏差）——拿到 offer 的用户更倾向于提交
+- **时效性**：录取偏好每年可能有变化，需关注最新一年的数据
+- **非官方**：数据为社区整理，不代表学校官方立场
+- **建议交叉验证**：与学校官网、LinkedIn Alumni、专业报告等交叉参考
+
+## Aliases
+- 一亩三分地
+- 1point3acres
+- Yimu Sanfendi
+- 1p3a
diff --git a/wiki/entities/Adaptive-Capacity-Labs.md b/wiki/entities/Adaptive-Capacity-Labs.md
new file mode 100644
index 00000000..d9d5274c
--- /dev/null
+++ b/wiki/entities/Adaptive-Capacity-Labs.md
@@ -0,0 +1,35 @@
+---
+title: "Adaptive Capacity Labs"
+type: entity
+tags: [sre, reliability, research, consulting]
+last_updated: 2026-04-20
+---
+
+# Adaptive Capacity Labs
+
+Adaptive Capacity Labs 由 John Allspaw 和 Dr. Richard I. Cook 创办，专注于系统可靠性和组织韧性的研究与咨询。
+
+## Aliases
+- Adaptive Capacity Labs
+- ACL (abbreviation)
+
+## Overview
+该实验室的研究重点是理解复杂 socio-technical 系统中的故障和恢复机制，其两位创始人在 SRE 和 Resilience Engineering 领域极具影响力。
+
+## Key Contributions
+- **Organizational Second Hit Syndrome**：提出组织层面的"二次冲击综合征"概念，类比神经学中的 second-impact syndrome
+- **Resilience Engineering**：推动韧性工程作为 SRE 的核心理论基础
+- **Incident Analysis**：基于《Working Together》和其他著作，建立了对故障协作处理的系统性认识
+
+## Key People
+- [[John-Allspaw]]：联合创始人，SRE 先驱，前 Etsy CTO
+- [[Richard-Cook]]：联合创始人，医学博士，系统 resilience 研究者
+
+## Related Concepts
+- [[Organizational-Second-Hit-Syndrome]]
+- [[Resilience]]
+- [[BlamelessPostMortem]]
+- [[Incident-Response]]
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/entities/Agentforce.md b/wiki/entities/Agentforce.md
new file mode 100644
index 00000000..bb7a069a
--- /dev/null
+++ b/wiki/entities/Agentforce.md
@@ -0,0 +1,61 @@
+---
+title: "Agentforce"
+type: entity
+tags: []
+sources: [specialized-french-consulting-market]
+last_updated: 2026-04-25
+---
+
+# Agentforce
+
+## Aliases
+- Agentforce
+- Salesforce Agentforce
+- Agentforce Studio
+- Einstein Agent
+
+## Definition
+
+Agentforce 是 Salesforce 于 2024-2025 年推出的 AI Agent 产品线，为 CRM 平台提供企业级 AI 自动化能力。通过 Agentforce，Salesforce 用户可以构建、部署和管理定制化 AI Agent，以自动化客户服务、销售流程、营销运营等业务场景。
+
+## Core Capabilities
+
+### Agentforce Studio
+- 可视化低代码环境，用于构建和管理 AI Agent
+- 支持预构建模板和自定义 Agent 开发
+- 内置监控、调试和性能追踪
+
+### 预构建 Agent（Out-of-the-Box）
+| Agent 类型 | 适用场景 |
+|-----------|---------|
+| Service Agent | 客户服务自动化（退款、退换货、技术支持） |
+| Sales Agent | 销售线索qualification和跟进自动化 |
+| Marketing Agent | 个性化营销内容和发送时机优化 |
+| Warehouse Agent | 库存管理和物流协调 |
+
+### Data Cloud 集成
+Agentforce 的核心差异化在于与 Data Cloud（统一数据平台）的深度集成：
+- 所有 Agent 共享同一实时数据模型
+- 支持非 Salesforce 数据的接入（通过 Connectors）
+- 实现真正的全渠道客户视图
+
+## Market Value in French Consulting
+
+在法国 ESN/SI 咨询市场中，Agentforce + Data Cloud 的组合专家享有最高的市场溢价：
+
+- **TJM 定位**：700-850 EUR/天（较通用 Salesforce Architect 高出 15-30%）
+- **供需关系**：供给严重不足，需求增长迅速
+- **谈判优势**：掌握 Agentforce 的顾问在谈判中有显著议价能力
+
+> "Lead with the niche, not the platform" — 建议顾问在定位时突出 Data Cloud + Agentforce 组合，而非泛泛的"Salesforce Architect"
+
+## Relationship to Salesforce Ecosystem
+
+Agentforce 是 Salesforce Einstein 1 Platform 的核心演进：
+- 建立在 Einstein AI 能力之上（Einstein Copilot → Agentforce）
+- 与 Apex、Flow、Platform Events 无缝集成
+- 支持通过 Agentforce SDK 扩展自定义行为
+
+## Related Sources
+- [[specialized-french-consulting-market]]
+- [[Salesforce]]
diff --git a/wiki/entities/AgentsOrchestrator.md b/wiki/entities/AgentsOrchestrator.md
new file mode 100644
index 00000000..20618c5e
--- /dev/null
+++ b/wiki/entities/AgentsOrchestrator.md
@@ -0,0 +1,44 @@
+---
+title: "AgentsOrchestrator"
+type: entity
+tags: []
+sources: [agents-orchestrator]
+last_updated: 2026-05-29
+---
+
+## Overview
+The **Agents Orchestrator** is the central pipeline manager of The Agency — an autonomous agent that coordinates the entire development workflow from specification to production-ready delivery.
+
+## Role
+- **Role**: Autonomous workflow pipeline manager and quality orchestrator
+- **Personality**: Systematic, quality-focused, persistent, process-driven
+- **Vibe**: "The conductor who runs the entire dev pipeline from spec to ship."
+
+## Core Responsibilities
+- Orchestrate full workflow pipeline: PM → ArchitectUX → [Dev ↔ QA Loop] → Integration
+- Ensure each phase completes successfully before advancing
+- Coordinate agent handoffs with proper context and instructions
+- Implement continuous Dev-QA quality loops
+- Enforce quality gates (max 3 retries per task before escalation)
+
+## Pipeline Phases
+1. **Phase 1**: Project Manager Senior creates task list from spec
+2. **Phase 2**: ArchitectUX creates technical architecture foundation
+3. **Phase 3**: [Developer ↔ EvidenceQA] continuous loop until all tasks pass
+4. **Phase 4**: Testing Reality Checker performs final integration validation
+
+## Spawns
+- [[ProjectManagerSenior]]
+- [[ArchitectUX]]
+- [[EvidenceQA]]
+- [[TestingRealityChecker]]
+- [[FrontendDeveloper]]
+- [[BackendArchitect]]
+- [[MobileAppBuilder]]
+- [[DevOpsAutomator]]
+
+## Coordinated By
+- Part of [[The Agency]] Specialized Department
+
+## Sources
+- [[agents-orchestrator]]
diff --git a/wiki/entities/Aider.md b/wiki/entities/Aider.md
new file mode 100644
index 00000000..cf59b31f
--- /dev/null
+++ b/wiki/entities/Aider.md
@@ -0,0 +1,18 @@
+---
+title: "Aider"
+type: entity
+tags: []
+last_updated: 2026-04-29
+---
+
+## Overview
+Aider 是一个终端 AI 编程工具，支持与 Git 深度集成的 AI 结对编程。The Agency 将所有 Agent 合并为一个 `CONVENTIONS.md` 文件，Aider 在项目根目录自动读取。
+
+## Key Facts
+- Agent 格式：`CONVENTIONS.md`（单文件汇总）
+- 作用域：Project-Scoped（项目级）
+- 安装方式：从项目根目录运行 `./scripts/install.sh --tool aider`
+- 自动发现：Aider 自动在项目根目录查找 `CONVENTIONS.md`
+
+## Sources
+- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
diff --git a/wiki/entities/Alex-Product-Manager.md b/wiki/entities/Alex-Product-Manager.md
new file mode 100644
index 00000000..941ef103
--- /dev/null
+++ b/wiki/entities/Alex-Product-Manager.md
@@ -0,0 +1,35 @@
+---
+title: "Alex (Product Manager)"
+type: entity
+tags: ["persona", "product-management", "the-agency"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Alex
+- Product Manager Alex
+
+## Entity Type
+**Persona** — 虚构的产品经理角色，代表 The Agency 中 Product Manager Agent 的人格化形象。
+
+## Definition
+Alex 是 The Agency 产品部门 Product Manager Agent 的人格化角色设定：一名具有 10 年以上产品管理经验的专业人士，横跨 B2B SaaS、消费者应用和平台业务三大领域。Alex 曾领导产品从零到一上线、高增长扩展以及企业级转型，有处理线上故障止损、在预算周期中争夺路线图空间、执行艰难否决决策等实战经验。
+
+## Key Attributes
+- **理念**：以结果为导向，而非产出。功能是假设，发布是实验，成功的功能必须可量化地改变用户行为。
+- **超能力**：在用户需求、商业要求和工程现实三者之间保持张力，找到三者对齐的路径。
+- **风格**：团队专注度的守护者；用正确的问题让房间更聪明；外交式的直接；书面优先、异步沟通。
+
+## Products Owned
+- [[Product Requirements Document (PRD)]] — Alex 的核心交付物模板
+- [[Go-to-Market (GTM) Brief]] — 发布协调文档
+- [[Product Roadmap (Now/Next/Later)]] — 路线图维护
+
+## Frameworks Used
+- [[Outcome vs. Output]] — 决策思维框架
+- [[RICE Prioritization Score]] — 需求优先级框架
+- 六阶段产品工作流：Discovery → Framing → Definition → Delivery → Launch → Measurement
+
+## Related Entities
+- [[Senior Project Manager Agent]] — 协作角色（项目管理 vs. 产品管理的分工边界）
+- [[Agents Orchestrator]] — 上游协调者
diff --git a/wiki/entities/Amazon-RDS.md b/wiki/entities/Amazon-RDS.md
index b1e3a3e5..3fdabb02 100644
--- a/wiki/entities/Amazon-RDS.md
+++ b/wiki/entities/Amazon-RDS.md
@@ -8,7 +8,8 @@ tags:
   - Managed
 sources:
   - ctp-topic-51-architecting-with-aws-purpose-built-databases
-last_updated: 2026-04-28
+  - learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform
+last_updated: 2026-04-14
 ---
 
 ## Overview
diff --git a/wiki/entities/AmazonAds.md b/wiki/entities/AmazonAds.md
index 251954c2..4203ce8b 100644
--- a/wiki/entities/AmazonAds.md
+++ b/wiki/entities/AmazonAds.md
@@ -1,30 +1,33 @@
----
-title: "Amazon Ads"
-type: entity
-tags: ["paid-media", "advertising", "ecommerce", "platform"]
-last_updated: 2026-04-20
----
-
-## Aliases
-- Amazon Advertising
-- Amazon PPC
-- AMS (Amazon Marketing Services)
-
-## Overview
-Amazon Ads 是亚马逊的广告平台，在电商购买场景下触达高购买意图用户。是 [[PaidMediaPpcStrategist]] 跨平台预算分配的关键组成部分。
-
-## Key Capabilities
-- **Sponsored Products**: 关键词驱动的产品广告，出现在搜索结果和详情页
-- **Sponsored Brands**: 品牌展示广告，展示多个产品或品牌旗舰店
-- **Sponsored Display**: 展示型广告，覆盖亚马逊站内及站外受众
-- **Amazon DSP**: 需求方平台，支持程序化购买站内外优质广告位
-- **Amazon Marketing Cloud (AMC)**: 数据分析平台，支持跨触点归因分析
-
-## Key Features Used by PPC Strategist
-- 购物广告系列与 Google Shopping 协同
-- 基于购买意向的受众触达
-- 站内搜索场景的竞争情报
-
-## Connections
-- [[PaidMediaPpcStrategist]] 将 Amazon Ads 纳入跨平台预算分配框架
-- [[GoogleAds]] Shopping 与 Amazon Sponsored Products 在产品广告策略上有相似性
+---
+title: "Amazon Ads"
+type: entity
+tags:
+  - advertising
+  - amazon
+  - ecommerce
+  - ppc
+  - paid-media
+sources:
+  - paid-media-ppc-strategist
+last_updated: 2026-05-01
+---
+
+## Profile
+Amazon Ads 是亚马逊的广告平台，提供在亚马逊站内及整个亚马逊广告生态（包括第三方出版商网络）投放广告的能力，是电商场景最重要的付费广告渠道，核心优势在于触达处于购买决策末期的消费者。
+
+## Core Capabilities Referenced
+- **Sponsored Products**：在搜索结果和商品详情页推广单个商品，按点击付费（CPC），是亚马逊广告的基础产品
+- **Sponsored Brands**：在搜索结果顶部推广品牌 logo、自定义标题和最多 3 个商品，适合品牌建设和引流
+- **Sponsored Display**：基于受众和商品定向的展示广告，可在亚马逊站内及第三方网站投放
+- **Amazon DSP（Demand-Side Platform）**：程序化广告购买平台，面向品牌广告主购买亚马逊自有和第三方展示/视频库存
+- **Amazon Marketing Cloud（AMC）**：基于云的数据分析平台，支持跨触点归因和受众分析
+
+## Key Value for PPC Strategy
+- **购买意图最强**：Amazon 用户处于购买决策漏斗底部，转化率远高于一般展示广告
+- **电商场景专属**：与 Google Search 的信息获取意图不同，Amazon Ads 直接面向有购买计划的消费者
+- **搜索词数据**：亚马逊搜索词报告提供独特的购买意图信号，可反哺 Google Ads 关键词策略
+
+## Connections
+- [[GoogleAds]]：搜索广告主要平台，Google 侧重信息获取意图，Amazon 侧重购买意图
+- [[MicrosoftAdvertising]]：可与 Amazon 共同构成购买意图漏斗的跨平台协同
+- [[CrossPlatformPlanning]]：Google/Microsoft/Amazon 预算分配是跨平台策略核心
diff --git a/wiki/entities/Andrej-Karpathy.md b/wiki/entities/Andrej-Karpathy.md
index ef9db957..36e2c7fa 100644
--- a/wiki/entities/Andrej-Karpathy.md
+++ b/wiki/entities/Andrej-Karpathy.md
@@ -1,22 +1,28 @@
----
-title: "Andrej Karpathy"
-type: entity
-tags: [ai, deep-learning, openai]
----
-
-## Profile
-AI 领域知名专家，曾任特斯拉 AI 总监、OpenAI 创始成员之一，现活跃于 AI 教育与开源社区。以深入浅出的技术讲解著称，创办了知名的斯坦福 CS231n 课程。
-
-## Role
-- **Vibe Coding 概念推广者**：提出"我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来"的经典描述
-- **AI 教育者**：通过 YouTube 视频普及深度学习、LLM 应用等知识
-- **LLM Wiki 倡导者**：分享用 LLM 构建个人知识库的理念，倡导"让 AI 增量构建 Wiki，页面间互链，知识越积越厚"
-
-## Sources
-- [[github-上-5000-人收藏的-vibe-coding-神级指南]]
-- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]]
-- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
-
-## Aliases
-- Karpathy
-- Andrej
+---
+title: "Andrej Karpathy"
+type: entity
+tags: [ai, deep-learning, engineering]
+sources: [zk-steward, llm-wiki]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Karpathy
+- Andrej Karpathy
+
+## Overview
+Andrej Karpathy 是著名的人工智能研究员，曾任特斯拉 AI 总监、OpenAI 创始成员之一，斯坦福 CS231n 课程的创建者。他以"first-principles engineering"（第一性工程思维）著称，在 AI/LLM 教育和技术传播方面有深远影响（Deep Learning with PyTorch、Zero-to-Hero 系列）。
+
+## Core Method
+- **First-Principles Engineering**：从底层原理出发构建系统，反对盲目调用 API 而不理解底层机制
+- **Education-First**：好的技术内容必须从直觉入手，建立清晰的 mental model，而非堆砌公式
+- **Hands-On Learning**：通过写代码从头实现（从零构建神经网络），而非仅仅调用高层 API
+
+## Role in ZK Steward
+ZK Steward 在"AI / 工程"任务中切换到 Karpathy 视角，驱动第一性工程思维和 deep-learning 流程。
+
+## Key Connections
+- [[LLM Wiki]] ← authored_by ← [[Andrej Karpathy]]（2026 年初分享的 LLM Wiki 理念——用 LLM 构建持久化维基知识库，告别 RAG 的低效循环）
+- [[ZK-Steward-Agent]] ← uses Karpathy perspective for AI/engineering tasks
+- [[Domain-Thinking]] ← Karpathy is the reference expert for AI/engineering domain
+- [[Zettelkasten]] ← Karpathy 式的"deep-dive into LLMs"笔记（如 [[ZK-Steward-Agent]] 中引用的结构笔记示例）与 Zettelkasten 方法高度共鸣
diff --git a/wiki/entities/AnythingLLM.md b/wiki/entities/AnythingLLM.md
new file mode 100644
index 00000000..c2954d36
--- /dev/null
+++ b/wiki/entities/AnythingLLM.md
@@ -0,0 +1,29 @@
+---
+title: "AnythingLLM"
+type: entity
+tags:
+  - "ai-chat"
+  - "rag"
+  - "open-source"
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Overview
+AnythingLLM（56k stars）是一款开源 RAG AI 应用，支持 Generic OpenAI Provider 接入 Hermes Agent。
+
+## Key Facts
+- **GitHub Stars**：56k
+- **License**：MIT
+- **特点**：内置 RAG 知识库功能
+- **集成方式**：Generic OpenAI Provider 配置
+
+## Integration with Hermes Agent
+通过 Generic OpenAI Provider 配置：
+- **API URL**：`http://<host>:8642/v1/chat/completions`
+- **认证**：Bearer Token（`API_SERVER_KEY`）
+
+## Related Pages
+- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
+- [[hermes-agent]]（via Hermes-Agent.md）
+- [[OpenAI-Compatible-API]]
diff --git a/wiki/entities/Apache-Hudi.md b/wiki/entities/Apache-Hudi.md
new file mode 100644
index 00000000..0a8c3b4a
--- /dev/null
+++ b/wiki/entities/Apache-Hudi.md
@@ -0,0 +1,43 @@
+---
+title: "Apache Hudi"
+type: entity
+tags: [data-engineering, lakehouse, open-table-format, incremental]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Overview
+
+Apache Hudi 是另一个开放表格格式（Open Table Format），专注于 incremental processing（增量处理）和 upsert 支持。Data Engineer Agent 使用 Hudi 的 Copy-on-Write（CoW）和 Merge-on-Read（MoR）表类型实现增量数据管道。
+
+## Key Capabilities
+
+### Copy-on-Write (CoW)
+- 每次写入重写数据文件（Parquet）
+- 读优化，适合写少读多的场景
+- 数据文件始终保持最优压缩
+
+### Merge-on-Read (MoR)
+- 更新以 log 形式追加，读取时合并
+- 写优化，适合高频增量写入
+- 支持 late-arriving data 和 near-real-time 分析
+
+### Incremental Pull
+- Hudi 提供 `incrementalQueries`，消费者只需读取自上次处理以来的变更
+- 支持 Change Log 模式（仅返回变更记录，而非全量快照）
+
+## Use Cases
+
+- **CDC Ingestion**：Hudi + Debezium CDC 记录 → 增量摄取
+- **Slowly Changing Dimension (SCD)**：MoR 表支持 SCD Type 1 和 Type 2
+- **Time Travel Audit**：满足监管要求的审计日志
+
+## Ecosystem Position
+
+Apache Hudi 与 [[Delta Lake]] 和 [[Apache Iceberg]] 并列为三大开放表格格式。Hudi 的差异化优势在于其 incremental processing 能力和对 Spark Structured Streaming 的深度集成。
+
+## Related Concepts
+- [[Delta Lake]]
+- [[Apache Iceberg]]
+- [[CDC (Change Data Capture)]]
+- [[SCD Type 2]]
diff --git a/wiki/entities/Apache-Iceberg.md b/wiki/entities/Apache-Iceberg.md
new file mode 100644
index 00000000..453c79ee
--- /dev/null
+++ b/wiki/entities/Apache-Iceberg.md
@@ -0,0 +1,43 @@
+---
+title: "Apache Iceberg"
+type: entity
+tags: [data-engineering, lakehouse, open-table-format, ACID]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Overview
+
+Apache Iceberg 是一个开放表格格式规范（Open Table Format），为数据湖提供 ACID 事务、隐藏分区、时间旅行和跨引擎互操作能力。Data Engineer Agent 使用 Iceberg 替代或与 Delta Lake 配合，实现跨引擎（Spark/Trino/Presto）读写同一份数据。
+
+## Key Features
+
+### ACID Transactions
+与 [[Delta Lake]] 类似，Iceberg 提供写操作的原子提交和并发控制。
+
+### Hidden Partitioning（隐藏分区）
+- 分区策略由 Iceberg 自动管理，消费者无需感知分区键
+- 支持身份分区（identity）、桶分区（bucket）、日期/时间分区等
+- 避免用户误操作分区列导致数据倾斜
+
+### Time Travel & Rollback
+- 通过 snapshot ID 或 timestamp 查询历史数据
+- 支持 rollback 到任意历史 snapshot
+
+###跨引擎互操作
+- Spark、Trino、Presto、Flink、Hive 均可读写同一 Iceberg 表
+- 企业级数据湖多引擎共享数据的标准方案
+
+## Iceberg vs. Delta Lake
+
+| 特性 | Apache Iceberg | Delta Lake |
+|------|---------------|------------|
+| 起源 | Netflix/Apple 开源 | Databricks 开源 |
+| 跨引擎 | ✅ 原生多引擎 | ⚠️ 主要 Spark/Databricks |
+| 隐藏分区 | ✅ | ❌ |
+| 增量读取 | ✅ | ✅ |
+| 生态 | Trino/Presto/Flink 广泛支持 | Spark/Databricks 深度集成 |
+
+## Related Concepts
+- [[Delta Lake]]（Iceberg 的主要替代方案）
+- [[Medallion Architecture]]（Iceberg 作为 Bronze/Silver/Gold 存储格式）
diff --git a/wiki/entities/Apache-Kafka.md b/wiki/entities/Apache-Kafka.md
new file mode 100644
index 00000000..3f1a9145
--- /dev/null
+++ b/wiki/entities/Apache-Kafka.md
@@ -0,0 +1,65 @@
+---
+title: "Apache Kafka"
+type: entity
+tags: [data-engineering, streaming, event-driven, real-time]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Overview
+
+Apache Kafka 是分布式事件流平台，支持高吞吐量、低延迟的实时数据管道。Data Engineer Agent 使用 Kafka 作为流式数据摄取的核心传输层，构建 Exactly-Once 语义的实时 Bronze 层摄取管道。
+
+## Core Streaming Pipeline
+
+```python
+from pyspark.sql.functions import from_json, col, current_timestamp
+from pyspark.sql.types import StructType, StringType, DoubleType, TimestampType
+
+def stream_bronze_orders(kafka_bootstrap: str, topic: str, bronze_path: str):
+    stream = spark.readStream \
+        .format("kafka") \
+        .option("kafka.bootstrap.servers", kafka_bootstrap) \
+        .option("subscribe", topic) \
+        .option("startingOffsets", "latest") \
+        .option("failOnDataLoss", "false") \
+        .load()
+
+    parsed = stream.select(
+        from_json(col("value").cast("string"), order_schema).alias("data"),
+        col("timestamp").alias("_kafka_timestamp"),
+        current_timestamp().alias("_ingested_at")
+    ).select("data.*", "_kafka_timestamp", "_ingested_at")
+
+    return parsed.writeStream \
+        .format("delta") \
+        .outputMode("append") \
+        .option("checkpointLocation", f"{bronze_path}/_checkpoint") \
+        .option("mergeSchema", "true") \
+        .trigger(processingTime="30 seconds") \
+        .start(bronze_path)
+```
+
+## Key Semantics
+
+- **Exactly-Once Processing**：`checkpointLocation` + Delta Lake ACID 写入确保端到端 Exactly-Once
+- **At-Least-Once**：默认 delivery guarantee（配合幂等消费者可升级为 Exactly-Once）
+- **Late-Arriving Data**：Watermark + Event-Time 窗口处理迟到事件
+
+## Streaming vs. Micro-Batch Trade-off
+
+| 模式 | 延迟 | 吞吐量 | 适用场景 |
+|------|------|--------|----------|
+| Continuous（连续处理） | ~100ms | 中等 | 超低延迟需求 |
+| Micro-batch（微批次） | ~30s | 极高 | 高吞吐量、低成本 |
+
+## Related Platforms
+
+- **Azure Event Hubs**：Azure 托管 Kafka 兼容服务
+- **AWS Kinesis**：AWS 流式数据平台（Kafka 替代）
+- **Confluent Cloud**：Kafka 全托管云服务
+
+## Related Concepts
+- [[CDC (Change Data Capture)]]
+- [[Medallion Architecture]]（Kafka → Bronze Delta Lake）
+- [[Apache Spark]]（Structured Streaming + Kafka）
diff --git a/wiki/entities/Apache-Spark.md b/wiki/entities/Apache-Spark.md
new file mode 100644
index 00000000..4c163f84
--- /dev/null
+++ b/wiki/entities/Apache-Spark.md
@@ -0,0 +1,51 @@
+---
+title: "Apache Spark"
+type: entity
+tags: [data-engineering, big-data, processing-engine]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Overview
+
+Apache Spark 是统一的大规模数据处理引擎，支持批处理、流处理、机器学习和 SQL 查询。Data Engineer Agent 使用 PySpark（Spark 的 Python API）作为核心计算平台，构建 Bronze→Silver→Gold ETL/ELT 管道。
+
+## Key Capabilities for Data Engineering
+
+### PySpark Data Pipeline
+```python
+from pyspark.sql import SparkSession
+from pyspark.sql.functions import col, current_timestamp, sha2, concat_ws, lit
+from delta.tables import DeltaTable
+
+spark = SparkSession.builder \
+    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
+    .config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
+    .getOrCreate()
+```
+
+### Delta Lake Integration
+- Spark + Delta Lake 是 Medallion Architecture 的标准实现组合
+- 支持 `mergeSchema=true` 处理 schema 演进
+- 支持 `MERGE INTO` 实现幂等 upsert
+
+### Streaming
+- Spark Structured Streaming + Kafka：构建 Exactly-Once 语义的实时管道
+- 触发模式：Continuous（连续处理）或 Micro-batch（微批次）
+
+## Performance Features
+
+- **Adaptive Query Execution (AQE)**：动态分区合并、Broadcast Join 优化
+- **Z-Ordering**：多维聚类加速复合过滤查询
+- **Bloom Filters**：高基数字符串列（ID、邮箱）的文件跳过
+
+## Managed Platforms
+- [[Databricks]]（Unity Catalog、DLT、Workflows）
+- [[Amazon-RDS]] / EMR（AWS Spark 托管）
+- Google Dataproc（GCP Spark 托管）
+
+## Related Concepts
+- [[Medallion Architecture]]
+- [[Delta Lake]]
+- [[Apache Kafka]]
+- [[CDC (Change Data Capture)]]
diff --git a/wiki/entities/ArchitectUX.md b/wiki/entities/ArchitectUX.md
new file mode 100644
index 00000000..941e8628
--- /dev/null
+++ b/wiki/entities/ArchitectUX.md
@@ -0,0 +1,31 @@
+---
+title: "ArchitectUX"
+type: entity
+tags: [ux-design, architecture, the-agency]
+sources: [design-whimsy-injector, design-ux-architect, design-ux-researcher]
+last_updated: 2026-05-15
+---
+
+# ArchitectUX
+
+## Definition
+
+UX 架构专家 Agent（UX Architect Expert），隶属于 [[The-Agency]] Design 部门。核心使命：提供技术基础（CSS 设计系统、Grid/Flexbox 布局框架、Theme Toggle 组件），与 [[Whimsy-Injector]] 协作提供完整的品牌体验设计（技术架构 + 品牌人格）。
+
+## Role
+
+ArchitectUX 是 Design 部门的技术架构层，为 [[LuxuryDeveloper]] 提供：
+- CSS 设计系统（颜色/排版/间距变量）
+- Grid/Flexbox 布局框架
+- Theme Toggle 组件（light/dark/system 三态）
+- Foundation-first 理念消除开发者架构决策疲劳
+
+## Relationship to Other Agents
+
+- 与 [[UX-Researcher]] 互补：UX Researcher 提供用户洞察，ArchitectUX 将洞察转化为设计系统基础架构
+- 与 [[Whimsy-Injector]] 互补：ArchitectUX 提供技术基础，Whimsy Injector 提供品牌人格
+- 服务于 [[LuxuryDeveloper]]：LuxuryDeveloper 是 ArchitectUX 的目标用户
+
+## Aliases
+- ArchitectUX Agent
+- UX Architect
diff --git a/wiki/entities/AssemblyAI.md b/wiki/entities/AssemblyAI.md
new file mode 100644
index 00000000..fd2014bf
--- /dev/null
+++ b/wiki/entities/AssemblyAI.md
@@ -0,0 +1,49 @@
+---
+title: "AssemblyAI"
+type: entity
+tags: ["asr", "cloud-api", "speaker-diarization", "pii-detection"]
+sources: ["engineering-voice-ai-integration-engineer"]
+last_updated: 2026-05-02
+---
+
+## Aliases
+- AssemblyAI
+
+## Definition
+
+AssemblyAI 是一个云端自动语音识别（ASR）服务 API，通过 HTTP 接口提供语音转文字、说话人分离、PII 检测等功能。是 Voice AI Integration Engineer 在本地 Whisper 之外的云端 ASR 选项之一，适合需要快速集成或大规模处理的场景。
+
+## Key Capabilities
+
+| 功能 | 说明 |
+|------|------|
+| 语音转文字 | 多语言支持，实时和批量两种模式 |
+| 说话人分离 | 内置 Diarization，无需 pyannote.audio |
+| PII 检测 | 自动识别并标记/脱敏姓名、SSN、信用卡等 |
+| 置信度分数 | 每词级别置信度 |
+| 标点和大写 | 自动添加标点、自动大写句子开头 |
+
+## Use Cases
+
+- **快速 MVP**：不想搭建本地 Whisper 环境，直接 API 调用
+- **大规模并发**：需要处理大量音频，AssemblyAI 负责扩展
+- **含 PII 场景**：医疗/法律录音，内置 PII 检测减少合规负担
+- **混合路由**：敏感内容走本地 Whisper，高精度需求走 AssemblyAI
+
+## Tradeoff vs Local Whisper
+
+| 维度 | AssemblyAI | FasterWhisper（本地） |
+|------|-----------|---------------------|
+| 成本 | $0.005-0.02/分钟 | GPU 折旧成本 |
+| 延迟 | 取决于音频长度 | 取决于 GPU |
+| 隐私 | 数据离开本地 | 完全本地 |
+| 自定义 | 有限 | 完全可控 |
+| 离线支持 | 无 | 有 |
+
+## Connections
+- [[FasterWhisper]] — 本地 ASR 替代方案
+- [[pyannote.audio]] — 如果用 AssemblyAI 则无需独立安装
+- [[PIIRedaction]] — AssemblyAI 内置 PII 检测，减少额外管道阶段
+
+## Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/entities/Atlantis.md b/wiki/entities/Atlantis.md
index c0abfece..b0a1b9d2 100644
--- a/wiki/entities/Atlantis.md
+++ b/wiki/entities/Atlantis.md
@@ -10,7 +10,8 @@ tags:
   - CI/CD
 sources:
   - ctp-topic-48-terraform-vs-terragrunt.md
-last_updated: 2026-05-13
+  - learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform
+last_updated: 2026-04-14
 ---
 
 ## Overview
diff --git a/wiki/entities/Automation-Governance-Architect.md b/wiki/entities/Automation-Governance-Architect.md
new file mode 100644
index 00000000..bb4efae7
--- /dev/null
+++ b/wiki/entities/Automation-Governance-Architect.md
@@ -0,0 +1,51 @@
+---
+title: "Automation Governance Architect"
+type: entity
+tags: [agent, automation, governance, n8n]
+sources: [automation-governance-architect]
+last_updated: 2026-05-01
+---
+
+# Automation Governance Architect
+
+治理优先的业务自动化架构师 Agent，默认使用 n8n 作为首选编排工具，治理规则平台无关。
+
+## 基本信息
+- **角色**：业务自动化治理架构师
+- **默认栈**：n8n
+- **治理范围**：平台无关（n8n 为主）
+- **Vibe**：Calm, skeptical, and operations-focused — 偏好可靠系统，而非自动化热潮
+
+## 核心职责
+1. **防止低价值或不安全的自动化进入生产**
+2. **审批并标准化高价值自动化，附带明确保障措施**
+3. **为可靠性、可审计性和交接制定工作流标准**
+
+## 核心 Mission
+- 防止低价值或危险自动化
+- 批准并结构化高价值自动化（附带清晰保障）
+- 标准化工作流以确保可靠性、可审计性和交接质量
+
+## Non-Negotiable Rules（不可妥协规则）
+- 不得仅因技术上可实现就批准自动化
+- 不得在未经明确批准的情况下推荐对关键生产流程的直接变更
+- 优先选择简单稳健，而非精巧脆弱
+- 每条建议必须包含 fallback 和明确责任人
+- 无文档和测试证据，不得标记为"完成"
+
+## 五级裁定结果
+- **APPROVE**：强价值 + 可控风险 + 可维护架构
+- **APPROVE AS PILOT**：价值存在但需小范围验证
+- **PARTIAL AUTOMATION ONLY**：仅自动化安全段，保留人工检查点
+- **DEFER**：流程不成熟 / 价值不明 / 依赖不稳定
+- **REJECT**：经济性弱或运营/合规风险不可接受
+
+## Launch Command
+```
+Use the Automation Governance Architect to evaluate this process for automation.
+Apply mandatory scoring for time savings, data criticality, dependency risk, and scalability.
+Return a verdict, rationale, architecture recommendation, implementation standard, and rollout preconditions.
+```
+
+## Sources
+- [[automation-governance-architect]]
diff --git a/wiki/entities/BainAndCompany.md b/wiki/entities/BainAndCompany.md
new file mode 100644
index 00000000..b5186fcc
--- /dev/null
+++ b/wiki/entities/BainAndCompany.md
@@ -0,0 +1,20 @@
+---
+title: "Bain & Company"
+type: entity
+tags: ["consulting", "strategy", "framework-originator"]
+sources: ["support-executive-summary-generator"]
+last_updated: 2026-04-26
+---
+
+## Overview
+Bain & Company 是全球顶级战略咨询公司，成立于 1973 年，总部位于波士顿。以其实用主义咨询方法和以结果为导向的建议著称。
+
+## Aliases
+- Bain
+- Bain & Company
+
+## Key Contributions
+- **Action-Oriented Recommendations（行动导向建议模型）**：强调每个建议必须包含明确的负责人、时间线和预期结果
+
+## Role in The Agency
+作为 [[support-executive-summary-generator]] Agent 的咨询方法论基础，行动导向建议模型是该 Agent 生成可执行建议部分的核心标准。
diff --git a/wiki/entities/Bilibili.md b/wiki/entities/Bilibili.md
new file mode 100644
index 00000000..4e057e1a
--- /dev/null
+++ b/wiki/entities/Bilibili.md
@@ -0,0 +1,42 @@
+---
+title: "Bilibili（B站）"
+type: entity
+tags: [platform, china, social-media, video, gen-z]
+sources: [marketing-china-market-localization-strategist, marketing-bilibili-content-strategist]
+last_updated: 2026-05-30
+---
+
+## Overview
+哔哩哔哩（Bilibili，B站），中国领先的中长视频与弹幕社区，以 Z 世代（95 后/00 后）为核心用户群体。在 [[China Market Localization Strategist]] 的跨平台策略中，B站承担"考虑阶段"的深度内容教育角色，是品牌建立长期信任和权威认知的关键平台。
+
+## Platform DNA
+- **用户画像**：以 Z 世代为主，中国一二线城市年轻人高度集中
+- **内容偏好**：深度内容、知识型视频、二次元文化、游戏、生活方式
+- **核心互动机制**：弹幕（Danmaku）、投币、三连（点赞+投币+收藏）、充电
+- **算法特性**：内容质量权重高，播放完成率是核心指标，不单纯追求点击量
+
+## Marketing Role in China Funnel
+- **漏斗位置**：认知（Weibo/Douyin）→ **考虑（Bilibili）** → 转化（Xiaohongshu/WeChat）
+- **品牌价值**：深度种草、长期信任建立、Z 世代用户触达
+
+## Content Strategy
+- 长篇深度内容为主（10-40 分钟），与抖音的短视频策略形成互补
+- UP 主（内容创作者）合作是核心传播路径
+- 内容须有知识增量或情绪价值，硬广告效果差
+- 弹幕互动设计是内容创作的重要考量
+
+## Key Terms
+- **UP主**：B站内容创作者，即 YouTuber
+- **弹幕**：实时滚动的评论字幕，增强观看互动感
+- **三连**：点赞+投币+收藏，代表用户对内容的高度认可
+- **充电**：用户对 UP 主的直接打赏支持
+
+## Connections
+- [[Douyin]]（抖音）：认知层 → B站：考虑层，内容深度递进关系
+- [[Xiaohongshu]]（小红书）：考虑层 → B站，均为 Z 世代聚集平台
+- [[Marketing Bilibili Content Strategist]]：B站专属内容策略 Agent
+
+## Aliases
+- B站
+- Bilibili
+- 哔哩哔哩
diff --git a/wiki/entities/BostonConsultingGroup.md b/wiki/entities/BostonConsultingGroup.md
new file mode 100644
index 00000000..807f9c54
--- /dev/null
+++ b/wiki/entities/BostonConsultingGroup.md
@@ -0,0 +1,21 @@
+---
+title: "Boston Consulting Group (BCG)"
+type: entity
+tags: ["consulting", "strategy", "framework-originator"]
+sources: ["support-executive-summary-generator"]
+last_updated: 2026-04-26
+---
+
+## Overview
+Boston Consulting Group (BCG) 是全球领先的战略咨询公司，成立于 1963 年，总部位于波士顿。以其创新性管理理念和战略框架著称。
+
+## Aliases
+- BCG
+- Boston Consulting Group
+- The Boston Consulting Group
+
+## Key Contributions
+- **Pyramid Principle（金字塔原理）**：自上而下逻辑沟通和层级化洞察组织方法，成为商业沟通的标准框架
+
+## Role in The Agency
+作为 [[support-executive-summary-generator]] Agent 的咨询方法论基础，Pyramid Principle 是该 Agent 组织执行摘要结构的核心框架。
diff --git a/wiki/entities/Bronislaw-Malinowski.md b/wiki/entities/Bronislaw-Malinowski.md
new file mode 100644
index 00000000..ce615e2d
--- /dev/null
+++ b/wiki/entities/Bronislaw-Malinowski.md
@@ -0,0 +1,26 @@
+---
+title: "Bronislaw Malinowski"
+type: entity
+tags: ["anthropologist", "functionalism", "polish-british", "fieldwork", "oceanic-studies"]
+last_updated: 2026-04-25
+---
+
+## Overview
+波兰裔英国人类学家，功能主义人类学（Functionalism）创始人。强调文化是人类满足基本生物和社会需求的工具，通过特罗布里恩群岛（Trobriand Islands）的长期田野调查发展了系统的功能分析方法。
+
+## Aliases
+- Malinowski
+- B. Malinowski
+
+## Key Contributions
+- **功能主义（Functionalism）**：文化的每个元素都服务于满足人类的某种基本需求——生理需求通过经济系统满足，社会需求通过亲属制度满足，安全需求通过防御系统满足
+- **田野调查方法论**：强调人类学家必须长期沉浸于研究对象社会中（参与观察法），而非仅做短暂访问
+- **库拉圈（Kula Ring）**：特罗布里恩群岛的礼物交换圈——是礼物经济的经典研究案例
+
+## Relevance to Anthropologist Agent
+Anthropologist Agent 引用 Malinowski 功能主义作为核心方法论之一，要求每种文化实践必须能回答"这个做法为这些人解决了什么问题"。
+
+## Connections
+- [[Functionalism]] ← authored_by ← [[Bronislaw-Malinowski]]
+- [[Anthropologist-Agent]] ← uses_framework ← [[Bronislaw-Malinowski]]
+- [[Marcel-Mauss]] ← influenced_by ← [[Bronislaw-Malinowski]]
diff --git a/wiki/entities/Certora.md b/wiki/entities/Certora.md
new file mode 100644
index 00000000..d06c93e7
--- /dev/null
+++ b/wiki/entities/Certora.md
@@ -0,0 +1,39 @@
+---
+title: "Certora"
+type: entity
+tags: [blockchain, security, tooling, formal-verification]
+sources: [blockchain-security-auditor]
+last_updated: 2026-05-30
+---
+
+## Overview
+
+Certora 是一个智能合约形式化验证平台，其核心产品 Certora Prover 通过符号执行技术数学证明 Solidity 合约的关键属性。
+
+## Products
+
+### Certora Prover
+- 基于符号执行的自动化形式化验证工具
+- 使用 CVL（Certora Verification Language）描述协议规范
+- 支持反例生成和并行规则验证
+- 被 Trail of Bits 在高风险协议审计中使用
+
+### Certora Commander
+- 命令行工具链
+- 与 Truffle、Hardhat、Foundry 集成
+
+## Key Users
+
+- [[Blockchain-Security-Auditor]] — 形式化验证的主要工具
+- Trail of Bits — 高级审计报告
+- Protocol teams — 关键升级前的自验证
+
+## Notable Capabilities
+
+- 验证份额不变性、借贷健康度、权限控制
+- 在数学上证明某属性不可能被违反
+- 生成最小反例序列
+
+## Connections
+- [[Blockchain-Security-Auditor]] ← uses tools ← [[Certora]]
+- [[Formal-Verification]] ← implemented by ← [[Certora]]
diff --git a/wiki/entities/Chaebol.md b/wiki/entities/Chaebol.md
new file mode 100644
index 00000000..5fbc4843
--- /dev/null
+++ b/wiki/entities/Chaebol.md
@@ -0,0 +1,52 @@
+---
+title: "Chaebol"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-05-30
+---
+
+## 基本信息
+- **原文**：재벌（Chaebol）
+- **类型**：公司类型 / 韩国大企业集团
+- **中文**：财阀
+- **英文**：Korean Family-Controlled Conglomerate
+
+## 定义
+财阀（Chaebol）是韩国特有的家族控制大型企业集团，在韩国经济中占据主导地位。典型代表包括三星、现代、LG、SK、乐天等。财阀企业决策层级森严，품의流程耗时最长（12-16 周），通常需要集团总部和子公司双重审批。
+
+## 特征
+- **决策链长**：往往需要子公司部门长 → 子公司社长 → 集团总部多层审批
+- **预算周期严格**：通常按年度预算执行，大额支出需提前规划
+- **关系维护难度高**：初次接触需要通过极高层次的介绍人
+- **跟进频率**：建议每月一次，避免过于频繁造成压力
+
+## 品의 流程特点
+| 阶段 | 特点 |
+|------|------|
+| 결재라인 | 可能涉及 5-7 级审批链 |
+| 时间线 | 12-16 周 |
+| 联系人决策权 | 较低，需向上汇报 |
+| 预算确认 | 通常在年初（Q1）或财年末期确定 |
+
+## 代表企业
+- Samsung（三星）— 最大财阀，电子/建筑/金融综合集团
+- Hyundai/Kia（现代/起亚）— 汽车/重工业
+- LG — 电子/化学/通信
+- SK — 通信/能源/半导体
+- Lotte（乐天）— 食品/酒店/流通
+
+## 与外国供应商合作的挑战
+1. **语言壁垒**：内部决策文档多为韩文
+2. **技术评估文化差异**：更看重品牌知名度而非技术先进性
+3. **价格敏感度高**：集团采购追求规模效益
+4. **合同条款严格**：法务审查周期长
+
+## Aliases
+- 재벌
+- 韩国财阀
+- Korean Conglomerate
+- Chaebol Group
+
+## 来源
+- [[specialized-korean-business-navigator]] — 품의 Approval Process Timeline 中关于 Chaebol 跟进频率和审批链的说明
diff --git a/wiki/entities/Charlie-Munger.md b/wiki/entities/Charlie-Munger.md
new file mode 100644
index 00000000..cb206ea1
--- /dev/null
+++ b/wiki/entities/Charlie-Munger.md
@@ -0,0 +1,27 @@
+---
+title: "Charlie Munger"
+type: entity
+tags: [investing, strategy, mental-models]
+sources: [zk-steward]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Munger
+- Charles Munger
+
+## Overview
+Charlie Munger（1924–2023）是伯克希尔·哈撒韦副主席、巴菲特最重要的人生搭档，被誉为"最伟大的思想家之一"。他的核心方法论是"Mental Models"（心智模型网格）和"Inversion"（倒置法）——先想清楚如何失败再想如何成功。
+
+## Core Method
+- **Mental Models Grid**：跨学科心智模型网格（物理学、经济学、心理学、工程学等），用多元框架理解世界
+- **Inversion**：先想清楚如何失败，然后避免它；"我唯一知道的就是我会死在哪里，这样我就永远不会去那里"
+- **Lollapalooza Effect**：当多个心智模型同时指向同一方向时，产生巨大的叠加效应
+
+## Role in ZK Steward
+ZK Steward 在"商业策略"任务中切换到 Munger 视角，使用 mental models 和 inversion 进行多角度分析。
+
+## Key Connections
+- [[ZK-Steward-Agent]] ← uses Munger perspective for business strategy tasks
+- [[Domain-Thinking]] ← Munger is the reference expert for business strategy domain
+- [[Luhmann-四原则]] ← Munger 的 mental models 网格与"避免过度结构化"存在张力（Munger 倾向预设框架）
diff --git a/wiki/entities/ChatBox.md b/wiki/entities/ChatBox.md
new file mode 100644
index 00000000..b2cf33e2
--- /dev/null
+++ b/wiki/entities/ChatBox.md
@@ -0,0 +1,28 @@
+---
+title: "ChatBox"
+type: entity
+tags:
+  - "ai-chat"
+  - "open-source"
+  - "client"
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Overview
+ChatBox（39k stars）是一款开源 AI 客户端，支持通过 API Host 设置接入自定义后端。
+
+## Key Facts
+- **GitHub Stars**：39k
+- **License**：MIT
+- **集成方式**：API Host 设置
+
+## Integration with Hermes Agent
+通过 API Host 配置：
+- **API URL**：`http://<host>:8642`
+- **认证**：Bearer Token（`API_SERVER_KEY`）
+
+## Related Pages
+- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
+- [[hermes-agent]]（via Hermes-Agent.md）
+- [[OpenAI-Compatible-API]]
diff --git a/wiki/entities/Christian-Deckelmann.md b/wiki/entities/Christian-Deckelmann.md
new file mode 100644
index 00000000..6e313f60
--- /dev/null
+++ b/wiki/entities/Christian-Deckelmann.md
@@ -0,0 +1,27 @@
+---
+title: "Christian Deckelmann"
+type: entity
+tags:
+  - Micro Focus
+  - Cloud Transformation
+  - CTP
+  - AWS
+  - SES
+sources:
+  - ctp-topic-12-using-ses-smtp-service-terraform-module
+last_updated: 2026-04-14
+---
+
+## Overview
+Micro Focus Cloud Transformation Programme 负责人，主讲 CTP Topic 12，介绍了 Micro Focus 在云转型过程中选择 AWS SES 替代传统本地 SMTP 网关的背景与决策。
+
+## Aliases
+- Christian Deckelmann
+
+## Role
+- Cloud Transformation Programme 负责人
+- CTP Topic 12 主讲人之一
+
+## Connections
+- [[Filos Christolakis]] — SES Terraform 模块开发者，共同主讲 CTP Topic 12
+- [[CTP Topic 12 Using SES SMTP service terraform module]] — 主讲来源
diff --git a/wiki/entities/ChristopherVogler.md b/wiki/entities/ChristopherVogler.md
new file mode 100644
index 00000000..814be063
--- /dev/null
+++ b/wiki/entities/ChristopherVogler.md
@@ -0,0 +1,25 @@
+---
+title: "Christopher Vogler"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Christopher Vogler
+- Vogler
+
+## Overview
+Christopher Vogler 是美国编剧、故事顾问，他将 Joseph Campbell 的 Monomyth 理论系统引入商业电影和电视编剧领域，著有《作家之旅》（The Writer's Journey: Mythic Structure for Writers, 1992）。
+
+## Key Contributions
+- **The Writer's Journey**：将 Campbell 的英雄之旅模型改造为对编剧友好的12阶段叙事结构（Ordinary World → Call to Adventure → Refusal of the Call → Meeting the Mentor → Crossing the Threshold → Tests, Allies, Enemies → Approach to the Inmost Cave → The Ordeal → Reward → The Road Back → Resurrection → Return with the Elixir）
+- **Character Archetypes**：基于 Jung 的原型理论，定义了 Mentor、Shapeshifter、Threshold Guardian 等编剧用角色类型
+- 影响了迪士尼、皮克斯等主流工作室的叙事开发流程
+
+## In The Agency Context
+[[Academic Narratologist]] 使用 Writer's Journey 作为英雄叙事的分析工具，连接 Campbell 理论与现代编剧实践。
+
+## References
+- The Writer's Journey: Mythic Structure for Writers (1992)
diff --git a/wiki/entities/Claude-Code.md b/wiki/entities/Claude-Code.md
index 0e5d40fa..f12f3ff9 100644
--- a/wiki/entities/Claude-Code.md
+++ b/wiki/entities/Claude-Code.md
@@ -2,10 +2,20 @@
 title: "Claude Code"
 type: entity
 tags: [ai-agent, coding]
-sources: [aionui-cowork-desktop]
-last_updated: 2026-04-27
+sources: [aionui-cowork-desktop, readme.md]
+last_updated: 2026-04-29
 ---
 
+## Overview
+Claude Code 是 Anthropic 推出的 AI 编程 Agent，支持在终端中完成代码编写、调试、重构等开发任务。与 OpenClaw 共存于 AionUi 桌面应用中，共享统一 MCP 配置。
+
+## The Agency Integration
+Claude Code 是 The Agency 的原始设计目标，Agent 以原生 `.md` 格式工作，无需任何转换。
+- Agent 格式：`.md`（原生支持）
+- 安装路径：`~/.claude/agents/`
+- 安装命令：`cp -r <category>/*.md ~/.claude/agents/` 或 `./scripts/install.sh --tool claude-code`
+- 自动发现：Claude Code 会自动扫描 `~/.claude/agents/` 目录
+
 ## Overview
 
 Claude Code 是 Anthropic 推出的 AI 编程 Agent，支持在终端中完成代码编写、调试、重构等开发任务。与 OpenClaw 共存于 AionUi 桌面应用中，共享统一 MCP 配置。
diff --git a/wiki/entities/Claude-Levi-Strauss.md b/wiki/entities/Claude-Levi-Strauss.md
new file mode 100644
index 00000000..30a38d8c
--- /dev/null
+++ b/wiki/entities/Claude-Levi-Strauss.md
@@ -0,0 +1,27 @@
+---
+title: "Claude Levi-Strauss"
+type: entity
+tags: ["anthropologist", "structuralism", "french-intellectual", "mythology"]
+last_updated: 2026-04-25
+---
+
+## Overview
+法国人类学家，结构主义创始人。发展了通过二元对立（raw/cooked, nature/culture, self/other）和变换来理解神话与社会分类的系统性框架。其工作将人类学从功能主义转向了结构分析。
+
+## Aliases
+- Levi-Strauss
+- Lévi-Strauss
+- Claude Lévi-Strauss
+
+## Key Contributions
+- **结构主义（Structuralism）**：通过识别文化系统中的深层二元对立结构来解释神话、亲属制度和思维方式
+- **神话素（Mytheme）**：神话的基本叙事单元，通过变换重组产生不同变体
+- **亲属制度研究**：提出亲属制度是一种交换系统（女人作为交换媒介）
+- **生食与熟食**：通过烹饪系统分析自然与文化的边界
+
+## Relevance to Anthropologist Agent
+Anthropologist Agent 引用 Levi-Strauss 的结构主义作为"Advanced Capabilities"中的高级分析工具之一，用于对神话、分类系统和二元对立进行系统性分析。
+
+## Connections
+- [[Structuralism]] ← authored_by ← [[Claude-Levi-Strauss]]
+- [[Anthropologist-Agent]] ← uses_framework ← [[Claude-Levi-Strauss]]
diff --git a/wiki/entities/ClawHub.md b/wiki/entities/ClawHub.md
index 12453760..47208160 100644
--- a/wiki/entities/ClawHub.md
+++ b/wiki/entities/ClawHub.md
@@ -1,25 +1,26 @@
----
-title: "ClawHub"
-type: entity
-tags: [ClawHub, OpenClaw, Skill, Marketplace]
-sources: [daily-youtube-digest, phone-call-notifications]
-last_updated: 2026-04-23
----
-
-## Aliases
-- ClawHub
-- clawhub.ai
-
-## Definition
-
-ClawHub（clawhub.ai）是 OpenClaw 的官方 Skill 市场，托管 OpenClaw Agent 可安装的技能包（Skills）。用户可以通过自然语言让 AI Agent 安装 Skill（如 "Install the youtube-full skill"），或通过 `npx clawhub@latest install <skill-name>` 命令行安装。安装后 Skill 自动配置 API Key 并存储到正确的系统位置。
-
-## Key Skills on ClawHub
-
-- **youtube-full** — 自动获取 YouTube 频道最新视频、提取字幕并摘要
-- **clawr.ing** — 为 Agent 提供主动拨打电话通知能力，通过 PSTN 电话触达用户（参见 [[phone-call-notifications]]）
-- 持续扩充中（官网 clawhub.ai 浏览全部）
-
-## Connections
-- [[clawhub.ai]] ← hosts ← [[youtube-full skill]], [[clawr.ing]]
-- [[OpenClaw]] ← extends via ← [[clawhub.ai]] skills
+---
+title: "ClawHub"
+type: entity
+tags: []
+sources: [baoyu-skills]
+last_updated: 2026-04-19
+---
+
+## Overview
+
+ClawHub（也称 OpenClaw）是 Claude Code 的插件市场，支持 Skills 的发现、安装和自动更新。[[baoyu-skills]] 通过 ClawHub 分发各独立 Skill，用户可以按需选择性安装（如 `clawhub install baoyu-imagine`）。
+
+## Distribution Model
+
+ClawHub 采用「单个 Skill 分发」模式，每个 `skills/` 子目录作为独立 ClawHub Skill 发布。以 MIT-0 许可证分发。
+
+安装方式：
+```
+clawhub install baoyu-imagine
+clawhub install baoyu-markdown-to-html
+```
+
+## Connections
+- [[baoyu-skills]] ← distributed_via ← [[ClawHub]]
+- [[OpenClaw]] ← same_platform ← [[ClawHub]]
+- [[Claude-Code]] ← platform ← [[ClawHub]]
diff --git a/wiki/entities/Clifford-Geertz.md b/wiki/entities/Clifford-Geertz.md
new file mode 100644
index 00000000..8ad09e5b
--- /dev/null
+++ b/wiki/entities/Clifford-Geertz.md
@@ -0,0 +1,25 @@
+---
+title: "Clifford Geertz"
+type: entity
+tags: ["anthropologist", "symbolic-anthropology", "indonesian-studies", "methodology"]
+last_updated: 2026-04-25
+---
+
+## Overview
+美国人类学家，符号人类学（Interpretive Anthropology）创始人。提出"厚描述"（Thick Description）方法论，强调理解文化参与者的主观意义系统，而非仅做外部观察。
+
+## Aliases
+- Geertz
+- C. Geertz
+
+## Key Contributions
+- **厚描述（Thick Description）**：将文化实践作为文本阅读，通过多层次语境理解行为的意义（眨眼vs抽动vs模仿眨眼）
+- **符号人类学（Symbolic Anthropology）**：文化是由象征符号构成的意义之网（web of significance），人类学家的任务是解释这个意义之网
+- **印尼研究**：通过巴厘岛斗鸡、爪哇的宗教实践等具体田野案例展示厚描述方法
+
+## Relevance to Anthropologist Agent
+Anthropologist Agent 引用 Geertz 的"厚描述"作为 Advanced Capabilities 的核心方法论，要求 Agent 将文化实践作为文本理解参与者的主观意义。
+
+## Connections
+- [[Symbolic-Anthropology]] ← authored_by ← [[Clifford-Geertz]]
+- [[Anthropologist-Agent]] ← uses_framework ← [[Clifford-Geertz]]
diff --git a/wiki/entities/Cursor.md b/wiki/entities/Cursor.md
index 2d605a29..f75c8197 100644
--- a/wiki/entities/Cursor.md
+++ b/wiki/entities/Cursor.md
@@ -1,43 +1,18 @@
 ---
 title: "Cursor"
 type: entity
-tags: [ai, ai-agent, ide, mcp]
-sources: [mcp在cursor中的集成与应用详解, cursor-2-0初学者使用指南]
-last_updated: 2026-04-26
+tags: []
+last_updated: 2026-04-29
 ---
 
 ## Overview
-Cursor 是一款支持 MCP（Modal Context Protocol）集成的 **AI 编程 IDE**，基于 VS Code 定制，集成了多种大模型用于代码补全、对话和自动化任务执行。
+Cursor 是基于 AI 的代码编辑器（基于 VS Code）。The Agency 将 Agent 转换为 `.mdc` 规则文件（Cursor 的原生配置格式），以项目级作用域安装。
 
-## MCP Integration
-Cursor 是 MCP 协议的重要客户端实现，支持在 IDE 中直接接入 MCP Server：
+## Key Facts
+- Agent 格式：`.mdc`（Cursor 规则文件）
+- 作用域：Project-Scoped（项目级）
+- 安装方式：从项目根目录运行 `./scripts/install.sh --tool cursor`
+- 前置步骤：无需 convert（直接转换）
 
-**接入方式：**
-1. 下载支持 MCP 功能的 Cursor 最新版
-2. 在 Cursor 设置中新增 MCP Server
-3. 选择接入类型：
-   - **SSE 服务方式**：通过 HTTP SSE 连接远程 MCP Server
-   - **Command 方式**：通过本地执行命令连接本地 MCP Server
-
-**常见问题：**
-- 配置后出现 "no tools found" 错误 → 检查 MCP 服务路径或网络代理设置
-- 建议直接填写 MCP 原始地址，绕过代理层
-
-## Composer Module
-Cursor 的 Composer 模块支持两种交互模式：
-- **Normal 模式**：需要用户手动复制 AI 给出的命令并执行
-- **Agent 模式**：自动执行 AI 发出的命令，处理工具调用（需开启）
-
-## Version
-- Cursor 2.0 及以上版本支持 MCP 集成
-
-## Connections
-- [[Mcp在Cursor中的集成与应用详解]] ← MCP 集成核心教程
-- [[Cursor2.0初学者使用指南]] ← 入门指南
-- [[ModalContextProtocol]] ← 集成协议
-- [[Composer]] ← 功能模块
-- [[AgentMode]] ← 交互模式
-
-## See Also
-- [[OpenCode]]
-- [[Trae]]
+## Sources
+- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
diff --git a/wiki/entities/CustomerMatch.md b/wiki/entities/CustomerMatch.md
new file mode 100644
index 00000000..6367faa6
--- /dev/null
+++ b/wiki/entities/CustomerMatch.md
@@ -0,0 +1,37 @@
+---
+title: "Customer Match"
+type: entity
+tags:
+  - advertising
+  - google
+  - audience
+  - paid-media
+sources:
+  - paid-media-ppc-strategist
+last_updated: 2026-05-01
+---
+
+## Profile
+Customer Match 是 Google Ads 的第一方数据激活工具，允许广告主将自有客户数据（邮箱、电话、地址）上传至 Google，与 Google 用户身份池进行匹配，从而创建可定向的自定义受众群体，用于精准再营销和类似受众扩展。
+
+## How It Works
+1. **数据上传**：广告主以加密格式上传客户列表（邮箱/电话）
+2. **身份匹配**：Google 将数据与已登录 Google 账户的用户池进行匹配（需同意条款）
+3. **受众创建**：匹配成功的用户被纳入自定义受众列表
+4. **广告定向**：该受众可用于 Search、Display、YouTube、Shopping 等广告系列的定向或排除
+
+## Core Use Cases
+- **Lookalike / Similar Segments**：在 Customer Match 受众基础上，Google 自动生成相似特征的新用户受众
+- **Cross-Sell / Up-Sell**：向现有客户推广其他产品或高端版本
+- **Lapsed Customer Re-engagement**：唤醒长期未购买的老客户
+- **CLV（Custoner Lifetime Value）分层**：按消费金额分层，针对高价值客户提供专属优惠
+
+## Privacy Considerations
+- 用户需在 Google 平台同意数据使用条款才能被匹配
+- 随着隐私法规（GDPR/CCPA）趋严，第一方数据战略价值持续提升
+- Customer Match 是 [[AudienceStrategy]] 的核心组件
+
+## Connections
+- [[GoogleAds]]：Customer Match 的承载平台
+- [[AudienceStrategy]]：Customer Match 是受众策略的重要组成部分
+- [[PaidMediaPPCCampaignStrategist]]：在 Tiered Campaign Architecture 中用于高价值客户层
diff --git a/wiki/entities/Dana.md b/wiki/entities/Dana.md
new file mode 100644
index 00000000..20bf6275
--- /dev/null
+++ b/wiki/entities/Dana.md
@@ -0,0 +1,37 @@
+---
+title: "Dana"
+type: entity
+tags: [finance, accounting, ai-agent]
+sources: [finance-bookkeeper-controller]
+last_updated: 2026-05-02
+---
+
+## Definition
+Dana 是 [[finance-bookkeeper-controller]] 中定义的 AI Controller Agent 角色名称，代表一位拥有 13 年+ 经验的专业会计主管。
+
+## Background
+- 13 年以上经验，跨度从初创企业记账到公众公司 Controller
+- 从零建立过多个会计部门
+- 主导过首次审计
+- 实施过 Sarbanes-Oxley
+- 连续 150+ 个月准时完成月度结账
+
+## Core Philosophy
+- **准确性底线**：准确性是不可协商的底线，速度必须服从准确性
+- **调节即侦破**：未调节差异是等待被理解的故事
+- **审计无聊论**：如果审计师感到意外，说明控制失败了
+- **自动化哲学**：自动化重复工作，人脑专注异常
+- **文档即善意**：为未来的自己和继任者做好文档
+
+## Role in Agency System
+- 属 Finance Agent 矩阵中的核心 Controller 角色
+- 为 [[Finance FPA Analyst]] 提供高质量财务数据
+- 与 [[Finance Tax Strategist]] 协调季度税项和年度税表
+- 与 [[Accounts Payable Agent]] 协作审核 AP 数据和账务记录
+
+## Key Metrics
+- 连续 150+ 月准时结账
+- 结账周期从 10 天压缩至 7 天
+- AP 处理在条款期内完成以捕获所有提前付款折扣
+- 每周现金预测精度 ±5%
+- AR aging：逾期 90 天以上应收账款 <5%
diff --git a/wiki/entities/Databricks.md b/wiki/entities/Databricks.md
new file mode 100644
index 00000000..f8513a29
--- /dev/null
+++ b/wiki/entities/Databricks.md
@@ -0,0 +1,41 @@
+---
+title: "Databricks"
+type: entity
+tags: [data-engineering, lakehouse, analytics-platform, cloud]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Overview
+
+Databricks 是基于 Apache Spark 的统一分析和 AI 平台，提供 Lakehouse、Notebook、MLflow、Delta Live Tables（DLT）和 Unity Catalog 等能力。Data Engineer Agent 使用 Databricks 作为主要的托管执行环境。
+
+## Key Products for Data Engineering
+
+### Unity Catalog
+- 统一治理：跨云（AWS/Azure/GCP）的数据目录和权限管理
+- 细粒度行级安全（Row-Level Security）和列掩码（Column Masking）
+
+### Delta Live Tables (DLT)
+- 声明式流式和批处理管道
+- 自动管理基础设施、checkpoint 和数据质量
+- 内置期望（Expectations）定义，数据质量自动验证
+
+### Databricks Workflows
+- 编排多任务管道（notebooks + SQL + JAR）
+- 支持 CI/CD 集成（Asset Bundles）
+
+### Asset Bundles
+- 基础架构即代码（IaC）方式管理 Databricks 资源
+- 可与 GitHub Actions 集成实现自动化部署
+
+## Cloud Platforms
+- **AWS**：S3 + Databricks
+- **Azure**：ADLS + Databricks (Microsoft Fabric 集成)
+- **GCP**：GCS + Databricks
+
+## Related Concepts
+- [[Medallion Architecture]]
+- [[Delta Lake]]（Databricks 是主要贡献者和推广者）
+- [[Apache Spark]]
+- [[dbt]]（dbt Cloud 与 Databricks 深度集成）
diff --git a/wiki/entities/David-Ogilvy.md b/wiki/entities/David-Ogilvy.md
new file mode 100644
index 00000000..72508116
--- /dev/null
+++ b/wiki/entities/David-Ogilvy.md
@@ -0,0 +1,26 @@
+---
+title: "David Ogilvy"
+type: entity
+tags: [advertising, brand, marketing]
+sources: [zk-steward]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Ogilvy
+- David MacKenzie Ogilvy
+
+## Overview
+David Ogilvy（1911–1999）是奥美广告（Ogilvy & Mather）的创始人，被誉为"现代广告之父"。他强调品牌个性（brand persona）和长文案（long copy）在广告中的力量，反对空洞的创意炫技。
+
+## Core Method
+- **Long Copy**：好广告不靠图片，靠文字——长文案能够充分展示产品价值、建立信任
+- **Brand Persona**：每个品牌都需要独特的声音和个性，像人一样与消费者对话
+- **Research-First**：广告创意必须以消费者研究为基础，而非创意人员的自我表达
+
+## Role in ZK Steward
+ZK Steward 在"品牌营销"任务中切换到 Ogilvy 视角，驱动品牌 persona 和 long copy 策略分析。
+
+## Key Connections
+- [[ZK-Steward-Agent]] ← uses Ogilvy perspective for brand marketing tasks
+- [[Domain-Thinking]] ← Ogilvy is the reference expert for brand marketing domain
diff --git a/wiki/entities/Deepgram.md b/wiki/entities/Deepgram.md
new file mode 100644
index 00000000..262149ed
--- /dev/null
+++ b/wiki/entities/Deepgram.md
@@ -0,0 +1,50 @@
+---
+title: "Deepgram"
+type: entity
+tags: ["asr", "cloud-api", "speaker-diarization", "streaming"]
+sources: ["engineering-voice-ai-integration-engineer"]
+last_updated: 2026-05-02
+---
+
+## Aliases
+- Deepgram
+
+## Definition
+
+Deepgram 是一个云端自动语音识别（ASR）服务，以实时流式转录（Streaming API）和高准确度著称。支持说话人分离、PII 检测、关键词检测等多种高级功能，是 AssemblyAI 的主要竞品。
+
+## Key Capabilities
+
+| 功能 | 说明 |
+|------|------|
+| 实时流式转录 | WebSocket 流，支持低延迟实时字幕/笔记 |
+| 批量转录 | 上传文件，异步返回结果 |
+| 说话人分离 | 内置 Diarization，支持指定说话人数 |
+| PII 检测 | 可选，开启后自动标记/脱敏 |
+| 关键词检测 | 自定义关键词加权 |
+| 语言模型 | 通用、医疗、法律等垂直领域模型 |
+
+## Competitive Positioning vs AssemblyAI
+
+| 维度 | Deepgram | AssemblyAI |
+|------|---------|-----------|
+| 实时流式 | 原生 WebSocket（更强） | REST polling |
+| 延迟 | 极低（<300ms） | 中等 |
+| 准确度 | 领先（WER 基准） | 相当 |
+| API 体验 | 更现代化 | 成熟稳定 |
+| 语言覆盖 | 100+ 语言 | 100+ 语言 |
+
+## Use Cases
+
+- **实时字幕**：直播、会议、客服的实时字幕生成
+- **VoIP 集成**：电话系统的实时转录
+- **长音频批量**：会议录音、播客批量处理
+- **多语言**：跨境会议的实时翻译字幕管道
+
+## Connections
+- [[FasterWhisper]] — 本地 ASR 替代方案
+- [[AssemblyAI]] — 直接竞品，混合路由可两者都接入
+- [[pyannote.audio]] — Deepgram 内置 Diarization 可替代独立 pyannote
+
+## Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/entities/Delta-Lake.md b/wiki/entities/Delta-Lake.md
new file mode 100644
index 00000000..0576d05d
--- /dev/null
+++ b/wiki/entities/Delta-Lake.md
@@ -0,0 +1,55 @@
+---
+title: "Delta Lake"
+type: entity
+tags: [data-engineering, lakehouse, open-table-format, ACID]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Overview
+
+Delta Lake 是由 Databricks 开源的开放表格格式（Open Table Format），为数据湖提供 ACID 事务、时间旅行、Z-Ordering 等能力。Data Engineer Agent 使用 Delta Lake 作为 Medallion Architecture 三层（Bronze/Silver/Gold）的统一存储格式。
+
+## Key Features
+
+### ACID Transactions
+- 写操作原子提交，读者永远看到一致状态
+- 多并发写操作不会产生部分写入
+
+### Time Travel
+- 任意时间点查询数据（`VERSION AS OF` 或 `TIMESTAMP AS OF`）
+- 用于审计、合规和回滚
+
+### Schema Enforcement & Evolution
+- `mergeSchema=true`：允许 schema 演进，捕获上游变更
+- 禁止删除 required 列，类型变更需显式声明
+
+### Z-Ordering
+- 多维数据聚类，将相关数据物理上聚集存储
+- 显著加速复合过滤查询
+
+### Liquid Clustering（Delta Lake 3.x+）
+- 自动压缩和聚类，自适应工作负载
+
+### UPSERT / MERGE
+```python
+target.alias("target").merge(source.alias("source"), merge_condition) \
+    .whenMatchedUpdateAll() \
+    .whenNotMatchedInsertAll() \
+    .execute()
+```
+实现幂等的增量数据更新。
+
+## Alternative Formats
+- [[Apache Iceberg]]：另一个开放表格格式规范，跨引擎（Spark/Trino/Presto）互操作
+- Apache Hudi：支持 hoodie-based incremental processing
+
+## Used By
+- [[Databricks]]（原生支持）
+- [[Apache Spark]]（`delta` format 直接支持）
+- AWS Glue、Snowflake（通过 connectors）
+
+## Related Concepts
+- [[Medallion Architecture]]
+- [[Apache Spark]]
+- [[SCD Type 2]]
diff --git a/wiki/entities/DevOpsAutomator.md b/wiki/entities/DevOpsAutomator.md
new file mode 100644
index 00000000..20dd05d9
--- /dev/null
+++ b/wiki/entities/DevOpsAutomator.md
@@ -0,0 +1,30 @@
+---
+title: "DevOpsAutomator"
+type: entity
+tags: []
+sources: [agents-orchestrator]
+last_updated: 2026-05-29
+---
+
+## Overview
+**DevOps Automator** is The Agency's infrastructure automation specialist agent — responsible for infrastructure automation, CI/CD, and cloud operations.
+
+## Role
+- **Role**: DevOps / Infrastructure automation specialist
+- **Personality**: Automation-first, reliability-focused, operationally meticulous
+- **Specialization**: Infrastructure automation, CI/CD pipelines, cloud operations
+
+## Core Responsibilities
+- Automate infrastructure provisioning and configuration
+- Design and implement CI/CD pipelines
+- Cloud operations and monitoring
+- Infrastructure as Code (IaC) implementation
+- Coordinate with [[ArchitectUX]] for infrastructure architecture
+
+## Within Pipeline
+- **Spawned By**: [[AgentsOrchestrator]] during Phase 3 Dev-QA Loop
+- **Validated By**: [[EvidenceQA]] — each infrastructure task must pass QA
+- **Part Of**: [[Dev-QA-Loop]] in the [[AgentsOrchestrator]] pipeline
+
+## Sources
+- [[agents-orchestrator]]
diff --git a/wiki/entities/Douyin.md b/wiki/entities/Douyin.md
index 16eceecb..84d970a0 100644
--- a/wiki/entities/Douyin.md
+++ b/wiki/entities/Douyin.md
@@ -1,39 +1,39 @@
----
-title: "Douyin（抖音）"
-type: entity
-tags: [platform, healthcare, china, social-media]
-sources: [healthcare-marketing-compliance]
-last_updated: 2026-04-25
----
-
-## Overview
-抖音（Douyin），字节跳动旗下短视频平台，中国最大的短视频/直播平台之一。在医疗健康内容合规中具有特殊地位——医疗行业广告须满足行业准入标准，认证医师账号须遵守严格的直播和内容规则。
-
-## Healthcare Industry Access Requirements
-- 须提交《医疗机构执业许可证》或药品/医疗器械资质文件进行行业认证
-- 认证后方可发布医疗健康相关内容和广告
-
-## Content Review Rules
-- 禁止展示外科手术过程
-- 禁止使用患者推荐/见证疗效内容
-- 禁止展示处方药信息
-- 健康科普内容须经平台人工审核
-
-## Physician Account Certification
-- 须提交医师资格证
-- 认证后获得"认证医师"标识
-- 认证医师可在合规范围内发布健康科普内容
-
-## Livestream Restrictions
-- 医疗账号直播期间禁止推荐具体药品或治疗方案
-- 禁止进行在线诊断
-- 违反规定可能导致账号封禁或流量限制
-
-## Advertising Placement
-- 医疗广告须经过行业资质审核
-- 创意内容须经平台人工审核
-
-## Aliases
-- 抖音
-- Douyin
-- TikTok China
+---
+title: "Douyin（抖音）"
+type: entity
+tags: [platform, healthcare, china, social-media]
+sources: [healthcare-marketing-compliance, marketing-douyin-strategist, marketing-china-ecommerce-operator, marketing-china-market-localization-strategist, marketing-livestream-commerce-coach]
+last_updated: 2026-04-30
+---
+
+## Overview
+抖音（Douyin），字节跳动旗下短视频平台，中国最大的短视频/直播平台之一。在医疗健康内容合规中具有特殊地位——医疗行业广告须满足行业准入标准，认证医师账号须遵守严格的直播和内容规则。
+
+## Healthcare Industry Access Requirements
+- 须提交《医疗机构执业许可证》或药品/医疗器械资质文件进行行业认证
+- 认证后方可发布医疗健康相关内容和广告
+
+## Content Review Rules
+- 禁止展示外科手术过程
+- 禁止使用患者推荐/见证疗效内容
+- 禁止展示处方药信息
+- 健康科普内容须经平台人工审核
+
+## Physician Account Certification
+- 须提交医师资格证
+- 认证后获得"认证医师"标识
+- 认证医师可在合规范围内发布健康科普内容
+
+## Livestream Restrictions
+- 医疗账号直播期间禁止推荐具体药品或治疗方案
+- 禁止进行在线诊断
+- 违反规定可能导致账号封禁或流量限制
+
+## Advertising Placement
+- 医疗广告须经过行业资质审核
+- 创意内容须经平台人工审核
+
+## Aliases
+- 抖音
+- Douyin
+- TikTok China
diff --git a/wiki/entities/EpicGames.md b/wiki/entities/EpicGames.md
new file mode 100644
index 00000000..82af04e0
--- /dev/null
+++ b/wiki/entities/EpicGames.md
@@ -0,0 +1,33 @@
+---
+title: "Epic Games"
+type: entity
+tags: ["game-engine", "company", "unreal-engine"]
+sources: ["unreal-systems-engineer", "unreal-world-builder"]
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Epic Games Inc.
+- Epic
+
+## Definition
+Epic Games 是全球领先的互动娱乐软件公司，总部位于美国北卡罗来纳州凯瑞（Cary, NC），是 Unreal Engine 游戏引擎的开发商。其产品涵盖 Unreal Engine（虚幻引擎）、Fortnite（堡垒之夜）、Epic Games Store 等。
+
+## Role in LLM-Wiki-Agent Context
+Epic Games 为 [[UnrealEngine5]] 提供核心基础设施，是 [[UnrealWorldBuilder]]、 [[UnrealSystemsEngineer]]、 [[UnrealMultiplayerArchitect]]、 [[UnrealTechnicalArtist]] 等 Agent 的技术基础来源。
+
+## Key Contributions
+- **Unreal Engine 5**：游戏引擎，提供 World Partition、Nanite、Lumen、Virtual Shadow Maps 等核心技术
+- **Nanite**：虚拟化几何系统，处理亿级三角形规模的几何细节
+- **World Partition**：开放世界分区管理框架
+- **PCG (Procedural Content Generation)**：程序化内容生成系统
+- **Unreal Editor**：多用户协作编辑支持（One File Per Actor 模式）
+
+## Connection to Other Entities
+- [[UnrealEngine5]] ← 产品 ← Epic Games
+- [[UnrealWorldBuilder]] ← 运行环境 ← [[UnrealEngine5]] ← 引擎提供 ← Epic Games
+- [[Epic Games]] ← 竞争对手 → Unity Technologies（Unity 引擎开发商）
+
+## Sources
+- [[unreal-systems-engineer]]
+- [[unreal-world-builder]]
diff --git a/wiki/entities/Ethan-Mollick.md b/wiki/entities/Ethan-Mollick.md
new file mode 100644
index 00000000..f468619d
--- /dev/null
+++ b/wiki/entities/Ethan-Mollick.md
@@ -0,0 +1,27 @@
+---
+title: "Ethan Mollick"
+type: entity
+tags: [ai-prompting, education, entrepreneurship]
+sources: [zk-steward]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Mollick
+- Ethan Mollick
+
+## Overview
+Ethan Mollick 是宾夕法尼亚大学沃顿商学院的副教授、One Useful Thing 的作者，专注于 AI 在教育和工作中的应用。他是目前 AI prompting 领域最具影响力的实践研究者之一，以"structured prompts"和"persona pattern"方法著称。
+
+## Core Method
+- **Structured Prompts**：通过明确角色、任务、格式和约束来结构化 prompts，减少 LLM 输出方差
+- **Persona Pattern**：让 AI 扮演特定专家角色（如"你是具有20年经验的资深工程师"），利用角色设定激发更有针对性的输出
+- **Co-Intelligence**：人与 AI 的最佳关系是"共同智能"——AI 不是替代者，而是思维放大器
+
+## Role in ZK Steward
+ZK Steward 在"AI / prompting"任务中切换到 Mollick 视角，驱动 structured prompts 和 persona pattern 方法。
+
+## Key Connections
+- [[ZK-Steward-Agent]] ← uses Mollick perspective for AI/prompting tasks
+- [[Domain-Thinking]] ← Mollick is the reference expert for AI/prompting domain
+- [[Domain-Thinking]] ← [[ZK-Steward-Agent]] 的第一句声明专家视角规范与 Mollick 的 persona pattern 直接对应
diff --git a/wiki/entities/Euler-Finance.md b/wiki/entities/Euler-Finance.md
index bccfee48..09291a99 100644
--- a/wiki/entities/Euler-Finance.md
+++ b/wiki/entities/Euler-Finance.md
@@ -1,42 +1,32 @@
----
-title: "Euler Finance"
-type: entity
-tags: [blockchain, defi, exploit, lending, eoa-donation]
-sources: [blockchain-security-auditor]
-last_updated: 2026-04-25
----
-
-## 基本信息
-- **时间**：2023 年 3 月 13 日
-- **平台**：Ethereum
-- **损失**：1.97 亿美元（Euler Finance 无辜用户存款几乎全损）
-- **根本原因**：donate-to-reserves 操纵攻击（Euler 白帽事后命名）
-- **攻击者**：关联 Lazarus Group（朝鲜黑客组织）
-- **白帽救援**：攻击者后归还全部资金（通过协商）
-
-## 攻击原理
-
-Euler Finance 的 `donateToReserves()` 函数允许任意用户将自己的 ETH 转入储备池。当攻击者先存款、后捐赠、后借款时，其健康因子（health factor）在 `eToken.balanceOf()` 更新前被错误计算，导致超额借款：
-
-1. 攻击者存入 30 ETH（获得 30 eETH）
-2. 攻击者调用 `donateToReserves(30 ETH)`，将 30 eETH 转入储备
-3. 此时攻击者的真实余额（3000 ETH）远高于名义余额（0），但清算逻辑基于名义余额
-4. 攻击者以极低抵押率（10 倍杠杆）借入 10 倍存款规模的资产
-5. 抵押品价值下跌时，清算机器人按错误健康因子执行清算，攻击者获超额清算收益
-
-关键漏洞：`donateToReserves()` 的实现没有考虑对内部 accounting 的影响，健康因子计算依赖于可被操纵的 `eToken.balanceOf()` 而非内部余额追踪。
-
-## 关键教训
-- **不要相信任何"管理员"函数是安全的**：看似无害的 `donateToReserves()` 影响了整个清算引擎
-- **协议不变量必须考虑所有代码路径**：包括看似无害的辅助函数
-- **白帽救援**：最终攻击者归还资金（否则 1.97 亿无法追回），成为 DeFi 历史上最大白帽救援案例
-
-## 关联漏洞类型
-- [[Flash-Loan-Attack]] — 攻击使用闪电贷提供初始资金
-- [[Oracle-Manipulation]] — 健康因子计算依赖可操纵的内部状态
-- 经济攻击（Economic Exploit）：利用 DeFi 协议的会计逻辑错误
-
-## 关联页面
-- [[blockchain-security-auditor]] — 区块链安全审计 Agent，将 Euler Finance 作为关键记忆模式收录于 Exploit Pattern Library
-- [[The-DAO-2016]] — 同为 DeFi 安全史上的里程碑事件，但攻击类型不同
-- [[Curve-Finance]] — 2023 年另一大 DeFi 安全事件
+---
+title: "Euler Finance"
+type: entity
+tags: []
+last_updated: 2026-05-01
+---
+
+## Overview
+Euler Finance 是以太坊上的非托管借贷协议，2023 年 3 月 13 日遭受闪电贷攻击，损失约 1.97 亿美元。攻击核心是协议缺少对抵押健康度的关键检查——允许用户以超低抵押率借出资产，并利用闪电贷操纵价格后发起清算获利。
+
+## Key Facts
+- **攻击时间**：2023 年 3 月 13 日
+- **损失金额**：约 1.97 亿美元
+- **攻击类型**：闪电贷价格操纵 + 协议逻辑漏洞
+- **主要漏洞**：允许用户以 eToken 抵押借入资产（donateToReserve）
+
+## Attack Mechanism
+1. 攻击者利用闪电贷借出大量 ETH
+2. 攻击者向 Euler Finance 的 eETH 池捐赠部分 ETH，大幅降低健康度
+3. 攻击者通过多笔操作让自身债务超过清算门槛
+4. 攻击者以超低抵押率借出大量资产（超过应有的抵押额度）
+5. 利用操纵后的价格触发清算，攻击者从清算中获取超额利润
+
+## Significance
+- 暴露了 DeFi 借贷协议中"抵押健康度检查"的致命重要性
+- 促使借贷协议重新审查 eToken 的清算机制
+- 推动了更严格的协议级安全审计标准
+- 最终攻击者返还了全部资金（通过与白帽黑客谈判）
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
+- [[blockchain-security-auditor]]
diff --git a/wiki/entities/EvidenceQA.md b/wiki/entities/EvidenceQA.md
new file mode 100644
index 00000000..9e46c98f
--- /dev/null
+++ b/wiki/entities/EvidenceQA.md
@@ -0,0 +1,36 @@
+---
+title: "EvidenceQA"
+type: entity
+tags: []
+sources: [agents-orchestrator, handoff-templates]
+last_updated: 2026-05-29
+---
+
+## Overview
+**EvidenceQA** is The Agency's screenshot-obsessed QA specialist agent — requires visual proof as validation evidence and provides clear PASS/FAIL decisions with specific feedback.
+
+## Role
+- **Role**: Screenshot-based quality validation specialist
+- **Personality**: Meticulous, evidence-driven, uncompromising
+- **Vibe**: Visual proof or it didn't happen
+
+## Core Responsibilities
+- Test each task implementation only with task-specific validation
+- Require screenshot evidence for all validation
+- Provide clear PASS/FAIL decision with specific feedback
+- Operate within the [[Dev-QA-Loop]] of the [[AgentsOrchestrator]] pipeline
+
+## Key Principle
+> "Every task must pass QA before advancing" — EvidenceQA enforces this by requiring visual proof for all validations.
+
+## Spawned By
+- [[AgentsOrchestrator]] — Phase 3 of the pipeline
+
+## Validates
+- [[FrontendDeveloper]] implementations
+- [[BackendArchitect]] implementations
+- [[MobileAppBuilder]] implementations
+- [[DevOpsAutomator]] infrastructure tasks
+
+## Sources
+- [[agents-orchestrator]]
diff --git a/wiki/entities/FBA.md b/wiki/entities/FBA.md
new file mode 100644
index 00000000..cfd9da89
--- /dev/null
+++ b/wiki/entities/FBA.md
@@ -0,0 +1,49 @@
+---
+title: "FBA"
+type: entity
+tags:
+  - amazon
+  - logistics
+  - fulfillment
+  - ecommerce
+  - cross-border
+sources:
+  - marketing-cross-border-ecommerce
+last_updated: 2026-04-26
+---
+
+## Aliases
+- Fulfillment by Amazon
+- FBA Program
+- 亚马逊自营物流
+
+## Definition
+
+FBA（Fulfillment by Amazon）是亚马逊提供的自营物流服务，卖家将商品批量发送至亚马逊运营中心，由亚马逊负责存储、分拣、包装、配送及售后客服。FBA 是跨境电商最重要的履约方式之一，能让商品享有 Prime 标志，大幅提升转化率。
+
+## Core Capabilities
+- **Inbound Shipping Plan**：创建入库计划，管理发货入仓流程
+- **Inventory Performance Index (IPI)**：库存绩效指数，衡量库存效率和补货及时性，低于阈值会限制仓储容量
+- **Long-term Storage Fee Control**：超 365 天商品面临高额长期仓储费，需主动管理库存周转
+- **Multi-site Inventory Transfer**：多站点库存调拨，适合 FBA Pan-EU 或泛欧计划
+- **FBA Auto-processing Returns**：退货自动处理，减轻卖家运营负担
+- **Prime Badge**：FBA 商品自动获得 Prime 标志，带来更高搜索排名和转化率
+
+## Key Metrics
+| 指标 | 目标值 | 说明 |
+|------|--------|------|
+| IPI 分数 | > 700 | 低于 500 会触发仓储限制 |
+| 库存周转 | > 6x/年 | 避免长期仓储费 |
+| 在途时间 | 7-14 天 | 空运更快但成本更高 |
+| 退货率 | < 类别均值 | 退货损失计入 SKU 成本 |
+
+## Usage in Cross-Border Context
+- 头程物流（First-mile）：从中国工厂到亚马逊运营中心，支持 FCL/LCL 海运、空运、中欧班列
+- FBA 费用 = 仓储费（按体积/时间）+ 执行费（按重量/尺寸）
+- IPI 不达标 → 仓储容量受限 → 无法发送新库存
+- 长期仓储费：每立方英尺 $6.90（超 365 天），每件 $0.15（超 180 天）
+
+## Connections
+- [[Amazon Ads]]：FBA 商品可投放 Sponsored Products/Sponsored Brands/Sponsored Display 广告
+- [[Supply Chain Strategist Agent]]：FBA 头程物流规划依赖供应链专业知识
+- [[Marketing Cross-Border E-Commerce Specialist]] ← uses ← [[FBA]]
diff --git a/wiki/entities/Filos-Christolakis.md b/wiki/entities/Filos-Christolakis.md
new file mode 100644
index 00000000..5bc3f9c7
--- /dev/null
+++ b/wiki/entities/Filos-Christolakis.md
@@ -0,0 +1,29 @@
+---
+title: "Filos Christolakis"
+type: entity
+tags:
+  - Micro Focus
+  - Cloud Transformation
+  - CTP
+  - Terraform
+  - SES
+sources:
+  - ctp-topic-12-using-ses-smtp-service-terraform-module
+last_updated: 2026-04-14
+---
+
+## Overview
+Micro Focus CTP/SRE 团队成员，AWS SES SMTP Terraform 模块的开发者，主讲 CTP Topic 12，讲解了该模块的技术架构、部署方案及使用注意事项。
+
+## Aliases
+- Filos Christolakis
+
+## Role
+- CTP/SRE 团队成员
+- SES Terraform 模块开发者
+- CTP Topic 12 主讲人之一
+
+## Connections
+- [[Christian Deckelmann]] — CTP 负责人，共同主讲 CTP Topic 12
+- [[CTP Topic 12 Using SES SMTP service terraform module]] — 模块开发来源
+- [[VPC Wrapper Module]] — SES 模块依赖 VPC Wrapper 预先配置的 SMTP VPC 终端节点
diff --git a/wiki/entities/Finance-Tracker.md b/wiki/entities/Finance-Tracker.md
new file mode 100644
index 00000000..d1c11470
--- /dev/null
+++ b/wiki/entities/Finance-Tracker.md
@@ -0,0 +1,41 @@
+---
+title: "Finance Tracker Agent"
+type: entity
+tags: ["agent-personality", "finance", "ai-agent"]
+last_updated: 2026-04-30
+---
+
+## Overview
+Finance Tracker Agent 是 The Agency 多智能体系统中的财务专家角色，专注于企业财务规划、预算管理、现金流优化、投资分析与合规管控。以绿色 💰 为标识，强调财务准确性和风险管控。
+
+## Aliases
+- Finance Tracker
+- 财务追踪代理
+
+## Capabilities
+- 全面预算框架开发（含季度差异分析）
+- 12 期滚动现金流预测与季节性因子建模
+- NPV / IRR / 投资回收期三维投资分析
+- 成本优化与费用管控（目标 15%+ 年度效率提升）
+- 财务合规验证与审计跟踪文档
+
+## Key Deliverables
+- 年度预算 + 季度差异分析 SQL 查询
+- Python `CashFlowManager` 现金流预测类
+- Python `InvestmentAnalyzer` 投资分析类
+- 财务绩效报告模板（执行摘要、详细分析、预算差异）
+
+## Success Metrics
+- 预算准确率 95%+，含差异说明和纠正措施
+- 现金流预测准确率 90%+，90 天流动性可见性
+- 成本优化实现 15%+ 年度效率提升
+- 投资建议平均 ROI 25%+
+- 财务报告 100% 合规达标
+
+## Connected Sources
+- [[support-finance-tracker]]
+
+## Related Agents
+- [[Accounts-Payable-Agent]]：共享财务控制流程模式
+- [[Finance-FPA-Analyst]]：财务规划与分析延伸
+- [[Finance-Financial-Analyst]]：财务分析能力延伸
diff --git a/wiki/entities/Foundry.md b/wiki/entities/Foundry.md
new file mode 100644
index 00000000..9a146200
--- /dev/null
+++ b/wiki/entities/Foundry.md
@@ -0,0 +1,35 @@
+---
+title: "Foundry"
+type: entity
+tags: []
+last_updated: 2026-05-01
+---
+
+## Overview
+Foundry 是最流行的 Solidity 开发框架之一（由 Paradigm 开发），提供 Forge（测试）、Cast（合约交互）、Chisel（Solidity REPL）等工具链。与 Hardhat 相比，Foundry 以速度快（Rust 实现）、内置 Fuzz 测试和 Invariant 测试著称。
+
+## Key Tools
+
+### Forge
+- Solidity 测试框架，类比 Hardhat + Mocha
+- 支持 `vm.prank()` / `vm.startPrank()` 模拟调用者
+- 支持 `vm.expectRevert()` 验证 revert 行为
+- 内置 `testFuzz_*` 模糊测试和 `testInvariant_*` 不变测试
+- `forge snapshot` 生成 Gas 消耗快照
+
+### Cast
+- 命令行合约交互工具
+- 发送交易、调用视图函数、解码事件
+- 访问链上数据
+
+### Anvil
+- 本地 EVM 测试网络
+- 可分叉主网进行集成测试
+
+## 与 Solidity Smart Contract Engineer 的关系
+- [[engineering-solidity-smart-contract-engineer]] 要求所有合约配备 Foundry 测试套件，分支覆盖率 >95%
+- Foundry 的 Fuzz 测试是发现边界条件和算术漏洞的关键工具
+- Gas 快照用于持续跟踪 Gas 优化效果
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
diff --git a/wiki/entities/Gemini.md b/wiki/entities/Gemini.md
index 0a9cf8a1..01158dc0 100644
--- a/wiki/entities/Gemini.md
+++ b/wiki/entities/Gemini.md
@@ -1,39 +1,37 @@
 ---
-title: "Gemini API"
+title: "Gemini"
 type: entity
-tags: ["google", "image-generation", "ai", "gemini", "carousel"]
-sources: ["marketing-carousel-growth-engine", "我用-gemini-3-一口气做了-10-个应用-附教程"]
-last_updated: 2026-04-26
+entity_type: "AI Model"
+tags: ["ai", "gemini", "google", "multimodal", "image-generation"]
+last_updated: 2026-05-01
 ---
 
-## Definition
+## Overview
 
-Google 的多模态 AI 模型 API，支持文本和图像生成。在 [[marketing-carousel-growth-engine]] 中用于生成 TikTok/Instagram 轮播图。
+Gemini 是 Google 开发的系列多模态 AI 模型，支持文本、代码、图像生成和理解等多种任务。在 AI 图片生成场景中，Gemini 支持多轮对话中的风格上下文传递，适合生成风格一致的系列图片。
 
-## Key Details
+## Key Capabilities
 
-- **Model**: `gemini-3.1-flash-image-preview`
-- **API**: Google Generative Language API
-- **Credential**: `GEMINI_API_KEY` 环境变量（免费层可用）
-- **Key**: https://aistudio.google.com/app/apikey
+- **多模态理解**：同时处理文本、图像、视频等多种输入
+- **图片生成**：Gemini Image Gen 支持通过文本提示词生成图片
+- **风格上下文**：在多轮对话中保持视觉风格一致性
+- **长上下文**：支持处理长篇文档和复杂指令
 
-## Usage in Carousel Growth Engine
+## Usage in Image Generation
 
-- **Slide 1**: 纯文本 prompt 生成首张幻灯片，定义视觉 DNA
-- **Slides 2-6**: 图生图模式，以 slide-1.jpg 作为 `--input-image` 参考输入，保持视觉连贯性
-- **Output**: 768x1376 (9:16) JPG 格式轮播图
-- **Script**: `generate-slides.sh` 编排管道，`generate_image.py`（Python via `uv`）调用 API
+在 AI 图片生成场景中，Gemini 的核心优势是通过多轮对话传递风格上下文：
 
-## 技术规格
+1. 对话开始时设置系统级风格指令（System Prompt）
+2. 先生成第一张图片作为风格基准
+3. 后续图片通过 STYLE LOCK 块引用上一张的风格参数
+4. 支持用参考图锁定视觉基准（效果最强）
 
-| 参数 | 值 |
-|------|-----|
-| 分辨率 | 768×1376 (9:16 竖版) |
-| 格式 | JPG（TikTok 拒绝 PNG） |
-| 视觉连贯性 | 第一张定义 DNA，后续图生图 |
-| 免费层 | 可用（需 Google AI Studio API Key） |
+## Related Concepts
 
-## Aliases
-- Gemini
-- Google Gemini
-- Gemini 3.1 Flash Image
+- [[StyleSeed]]：Gemini 图片风格一致性的核心技术手段
+- [[StyleLock]]：Gemini 多轮对话中强制风格比对的检查机制
+- [[ReferenceImageConsistency]]：用 Gemini 生成的第一张图作为后续图的视觉基准
+
+## Sources
+
+- [[如何让AI生成风格一致的图片]]
diff --git a/wiki/entities/GerardGenette.md b/wiki/entities/GerardGenette.md
new file mode 100644
index 00000000..01af7ced
--- /dev/null
+++ b/wiki/entities/GerardGenette.md
@@ -0,0 +1,27 @@
+---
+title: "Gérard Genette"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Gérard Genette
+- Genette
+
+## Overview
+Gérard Genette (1930–2018) 是法国文学理论家、结构主义者，以其叙事话语理论（Narrative Discourse）闻名于世。代表作《叙事话语》（Narrative Discourse: An Essay in Method, 1980）对叙事学产生了深远影响。
+
+## Key Contributions
+- **Narrative Order / Anachrony**：叙事的时间结构分析，包括倒叙（Analepsis）和预叙（Prolepsis）
+- **Focalization（聚焦）**：谁在感知故事——零聚焦（上帝视角）、内聚焦（人物视角）、外聚焦（客观旁观）
+- **Narrative Voice**：叙述者的类型和叙事距离
+- **Paratexts**：标题、题词、副标题等文本边缘元素的意义
+
+## In The Agency Context
+[[Academic Narratologist]] 使用 Genette's Narratology 分析叙事声音、聚焦模式和时序结构，是区分"讲述什么"与"如何讲述"的关键工具。
+
+## References
+- Narrative Discourse: An Essay in Method (1980)
+- Narrative Discourse Revisited (1983)
diff --git a/wiki/entities/GitHub Actions.md b/wiki/entities/GitHub Actions.md
new file mode 100644
index 00000000..b45c85cd
--- /dev/null
+++ b/wiki/entities/GitHub Actions.md	
@@ -0,0 +1,45 @@
+---
+title: "GitHub Actions"
+type: entity
+tags: [CI/CD, Automation, DevOps]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
+---
+
+# GitHub Actions
+
+## 基本信息
+- **类型**：CI/CD 平台
+- **开发商**：GitHub (Microsoft)
+- **官网**：https://github.com/features/actions
+
+## 定义
+GitHub Actions 是 GitHub 提供的自动化工作流平台，支持在 GitHub 仓库内构建、测试和部署代码，实现持续集成和持续交付。
+
+## 核心组件
+- **Workflow**：自动化工作流，定义在 `.github/workflows/` 目录
+- **Job**：工作流中的一个执行单元
+- **Step**：Job 中的具体步骤，可以是 shell 命令或 Action
+- **Action**：可复用的工作流步骤，可以是社区构建或官方维护
+- **Runner**：执行 Job 的虚拟机（GitHub 托管或自托管）
+
+## 在 DevOps Automator 中的角色
+- DevOps Automator 默认使用的 CI/CD 平台
+- 用于构建端到端流水线：security-scan → test → build → deploy
+- 支持 Blue-Green 部署的自动化执行
+
+## 相关概念
+- [[CI/CD Pipeline]]
+- [[Blue-Green Deployment]]
+- [[Zero-Downtime Deployment]]
+
+## 相关工具
+- Jenkins（开源 CI/CD）
+- GitLab CI（GitLab 内置 CI/CD）
+- ArgoCD（GitOps 持续交付）
+- Atlantis（Terraform CI/CD 自动化）
+
+## Aliases
+- GitHub Actions
+- GHA
+- GitHub Workflows
diff --git a/wiki/entities/GitHub-Copilot.md b/wiki/entities/GitHub-Copilot.md
new file mode 100644
index 00000000..8cfc4b9b
--- /dev/null
+++ b/wiki/entities/GitHub-Copilot.md
@@ -0,0 +1,13 @@
+---
+title: "GitHub Copilot"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-05-02
+---
+
+## Aliases
+- GitHub Copilot
+
+## Overview
+微软的 AI 编程助手，其 Chat 功能支持自定义 Agent。The Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 原生兼容，无需格式转换即可使用。
diff --git a/wiki/entities/GitHubCopilot.md b/wiki/entities/GitHubCopilot.md
index 4f4137d3..bba93bda 100644
--- a/wiki/entities/GitHubCopilot.md
+++ b/wiki/entities/GitHubCopilot.md
@@ -1,18 +1,22 @@
----
-title: "GitHubCopilot"
-type: entity
-tags: []
----
-
-## Identity
-GitHub Copilot — GitHub 开发的 AI 编程助手，通过 GitHub 官方集成支持用户自定义 agent。
-
-## Role in Wiki
-- 使用 [[AgentFileFormat]] 作为 agent 定义标准
-- 通过 [[TheAgency]] 提供 147+ 专业化 agent
-- 用户级别全局生效（安装到 `~/.github/agents/` 或 `~/.copilot/agents/`）
-
-## Related
-- [[github-copilot]] — 集成文档
-- [[AgentFileFormat]] — 支持的文件格式
-- [[TheAgency]] — agent 来源
+---
+title: "GitHub Copilot"
+type: entity
+tags: []
+last_updated: 2026-04-29
+---
+
+## Aliases
+- Copilot
+- GitHub Copilot Chat
+
+## Overview
+GitHub Copilot 是微软/GitHub 的 AI 编程助手。The Agency 的 Agent 可直接复制到 `~/.github/agents/` 和 `~/.copilot/agents/`，无需转换，与 Claude Code 并列为原生支持 `.md` 格式的工具。
+
+## Key Facts
+- Agent 格式：`.md`（原生支持）
+- 安装路径：`~/.github/agents/`、`~/.copilot/agents/`
+- 安装命令：`./scripts/install.sh --tool copilot`
+- 自动发现：Copilot 自动扫描配置目录
+
+## Sources
+- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
diff --git a/wiki/entities/GoogleAds.md b/wiki/entities/GoogleAds.md
index a40e372a..48a52264 100644
--- a/wiki/entities/GoogleAds.md
+++ b/wiki/entities/GoogleAds.md
@@ -1,32 +1,37 @@
----
-title: "Google Ads"
-type: entity
-tags: ["paid-media", "advertising", "platform"]
-last_updated: 2026-04-20
----
-
-## Aliases
-- Google AdWords
-- GoogleAds
-
-## Overview
-Google Ads 是全球最大的在线广告平台，由 Google 运营，支持搜索、展示、视频、购物、Performance Max 等全类型广告格式。是 [[PaidMediaPpcStrategist]] 的核心投放渠道。
-
-## Key Capabilities
-- **Search Ads**: 基于关键词的文本广告，出现在 Google 搜索结果页
-- **Shopping Ads**: 产品购物广告，带图片、价格、商家信息
-- **Performance Max**: AI 驱动的全渠道自动化广告，覆盖所有 Google 广告位
-- **Demand Gen**: 触达高意图消费者的发现型广告
-- **Display Ads**: 展示广告，覆盖 200 万+ 网站和应用
-- **Video Ads**: YouTube 视频广告
-
-## Key Features Used by PPC Strategist
-- 自动竞价策略（tCPA/tROAS/Max Conversions/Max Conversion Value）
-- Customer Match 受众定向
-- Auction Insights 竞争情报
-- Google Ads API 大规模账户管理
-- MCC（My Client Center）多账户管理
-
-## Connections
-- [[PaidMediaPpcStrategist]] 使用 Google Ads 作为核心投放平台
-- [[GoogleAdsAPI]] 提供编程接口支撑自动化运营
+---
+title: "Google Ads"
+type: entity
+tags:
+  - advertising
+  - google
+  - ppc
+  - paid-media
+sources:
+  - paid-media-ppc-strategist
+last_updated: 2026-05-01
+---
+
+## Profile
+Google Ads（前称 Google AdWords）是 Google 旗下的在线广告平台，是全球规模最大的付费搜索和展示广告平台，支持 Search、Shopping、Performance Max、Demand Gen、Display、Video 等多种广告类型。
+
+## Core Capabilities Referenced
+- **Search Ads**：文字搜索广告，通过关键词触发，基于 Quality Score 和 Bid 参与竞价
+- **Shopping Ads**：产品购物广告，基于 Google Merchant Center 商品数据，自动展示产品图片、价格和商家信息
+- **Performance Max**：AI 驱动的全渠道广告系列，自动跨 Google 所有库存（Search、Display、YouTube、Gmail、Shopping）优化
+- **Demand Gen**：在 YouTube、Gmail、Discover 触达处于考虑阶段用户的需求生成广告
+- **Display Ads**：展示广告，基于受众定位在 Google 展示网络中投放视觉广告
+- **Video Ads**：YouTube 视频广告，支持多种出价方式（CPV、CPM、TrueView）
+
+## Key Features for PPC Strategy
+- **Automated Bidding**：tCPA/tROAS/Max Conversions/Max Conversion Value
+- **Audience Manager**：Customer Match、Similar Segments、In-Market/Affinity 受众
+- **Auction Insights**：竞争情报分析，包括平均展示份额、竞争密度、顶部竞价占比
+- **Conversion Tracking**：转化追踪配置，支持网站/App/离线转化
+- **MCC（My Client Center）**：代理/广告主管理多个子账户的顶层结构
+- **Google Ads API**：企业级程序化账户管理接口，支持大规模自动化操作
+
+## Connections
+- [[MicrosoftAdvertising]]：Google Ads 的主要竞争平台，账户架构和竞价机制相似，可做跨平台预算分配
+- [[AmazonAds]]：电商场景补充，Google Ads 侧重搜索意图，Amazon Ads 侧重购买意图
+- [[AutomatedBiddingStrategy]]：Google Ads 核心能力之一
+- [[PerformanceMax]]：Google Ads 独有的 AI 驱动全渠道广告系列
diff --git a/wiki/entities/GoogleAdsAPI.md b/wiki/entities/GoogleAdsAPI.md
new file mode 100644
index 00000000..da4d1e28
--- /dev/null
+++ b/wiki/entities/GoogleAdsAPI.md
@@ -0,0 +1,40 @@
+---
+title: "Google Ads API"
+type: entity
+tags:
+  - advertising
+  - google
+  - api
+  - automation
+  - paid-media
+sources:
+  - paid-media-ppc-strategist
+last_updated: 2026-05-01
+---
+
+## Profile
+Google Ads API（Google Ads API v17+）是 Google 提供的企业级编程接口，允许开发者程序化地管理 Google Ads 账户的所有方面，支持大规模广告系列创建、修改、报告拉取和自动化操作，是企业级 PPC 管理的核心基础设施。
+
+## Core Capabilities Referenced
+- **Account Management**：MCC 级账户结构操作、子账户创建/修改
+- **Campaign Operations**：广告系列、广告组、关键词、广告文案的 CRUD 操作
+- **Bidding Strategy Management**：自动化竞价策略的创建和调整
+- **Audience Management**：受众定向、受众列表操作
+- **Reporting**：拉取 performance metrics、auction insights、conversion data
+- **Budget Management**：预算分配、 pacing 调整
+
+## Integration in PPC Strategy Agent
+Agent 规范建议优先使用 Google Ads API 或 MCP（Model Context Protocol）工具获取 live data：
+- **Pre-recommendation baseline**：在做任何策略建议前，先拉取 `account_summary`、`list_campaigns`、`auction_insights`
+- **Execution without leaving workflow**：直接通过 API 执行结构性变更，无需人工操作后台
+- **Automated analysis**：定期自动拉取账户健康评分、异常检测
+
+## Tooling Options
+- **Official Google Ads API Client Libraries**：Python、Java、PHP、Ruby、DotNET、Perl
+- **Google Ads MCP Tools**：Model Context Protocol 工具，可被 AI Agent 直接调用
+- **Google Ads Scripts**：基于 JavaScript 的轻量自动化脚本，适合简单任务
+
+## Connections
+- [[GoogleAds]]：API 的承载平台
+- [[MCCLevelStrategy]]：API 是 MCC 级策略执行的核心工具
+- [[PaidMediaPPCCampaignStrategist]]：Agent 规范强调优先使用 API 而非手动操作
diff --git a/wiki/entities/GoogleGemini.md b/wiki/entities/GoogleGemini.md
index 1ec7382b..35df5fce 100644
--- a/wiki/entities/GoogleGemini.md
+++ b/wiki/entities/GoogleGemini.md
@@ -1,30 +1,30 @@
----
-title: "GoogleGemini"
-type: entity
-tags: ["llm-provider", "google", "gemini"]
-sources: ["engineering-autonomous-optimization-architect"]
-last_updated: 2026-04-26
----
-
-## Aliases
-- Gemini
-- Google Gemini
-- Gemini Flash
-- Gemini Pro
-
-## Definition
-Google Gemini 是 Google 的 LLM 系列模型，涵盖从高性价比到高性能的多种版本。在 [[AutonomousOptimizationArchitect]] 系统中，Gemini Flash 因其极高的性价比（成本约为 Claude Opus 的 1/10）而被列为重要的路由目标。
-
-## Role in LLM Routing
-- **Gemini Flash**：低成本高速度模型，如果精度达到基准的 98% 且成本远低于竞品，[[AutonomousOptimizationArchitect]] 会将流量自动路由至 Gemini
-- **Gemini Pro**：中端定位，提供能力与成本的平衡
-- 与 [[OpenAI]] 和 [[Anthropic]] 共同构成三足鼎立的 Provider 生态
-
-## Key Properties
-- **Token 成本**：$0.075-0.5 / 1M tokens（Gemini Flash 极低）
-- **延迟**：低（Gemini Flash）
-- **优势**：极高的性价比，特别适合大规模、低成本推理
-
-## Connections
-- [[OpenAI]] — 同为 LLM Provider
-- [[Anthropic]] — 高精度基准 Provider
+---
+title: "GoogleGemini"
+type: entity
+tags: ["llm-provider", "google", "gemini"]
+sources: ["engineering-autonomous-optimization-architect", "marketing-carousel-growth-engine"]
+last_updated: 2026-04-26
+---
+
+## Aliases
+- Gemini
+- Google Gemini
+- Gemini Flash
+- Gemini Pro
+
+## Definition
+Google Gemini 是 Google 的 LLM 系列模型，涵盖从高性价比到高性能的多种版本。在 [[AutonomousOptimizationArchitect]] 系统中，Gemini Flash 因其极高的性价比（成本约为 Claude Opus 的 1/10）而被列为重要的路由目标。
+
+## Role in LLM Routing
+- **Gemini Flash**：低成本高速度模型，如果精度达到基准的 98% 且成本远低于竞品，[[AutonomousOptimizationArchitect]] 会将流量自动路由至 Gemini
+- **Gemini Pro**：中端定位，提供能力与成本的平衡
+- 与 [[OpenAI]] 和 [[Anthropic]] 共同构成三足鼎立的 Provider 生态
+
+## Key Properties
+- **Token 成本**：$0.075-0.5 / 1M tokens（Gemini Flash 极低）
+- **延迟**：低（Gemini Flash）
+- **优势**：极高的性价比，特别适合大规模、低成本推理
+
+## Connections
+- [[OpenAI]] — 同为 LLM Provider
+- [[Anthropic]] — 高精度基准 Provider
diff --git a/wiki/entities/Grafana.md b/wiki/entities/Grafana.md
index 723740d4..c7c6a5a4 100644
--- a/wiki/entities/Grafana.md
+++ b/wiki/entities/Grafana.md
@@ -1,34 +1,44 @@
 ---
 title: "Grafana"
 type: entity
-tags: [visualization, monitoring, open-source]
-sources: [可自动化-可扩展-ai增强的电商数据采集与处理系统]
-last_updated: 2025-11-11
+tags: [Visualization, Observability, DevOps]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
 ---
 
+# Grafana
+
+## 基本信息
+- **类型**：开源可视化平台
+- **开发商**：Grafana Labs
+- **官网**：https://grafana.com
+
+## 定义
+Grafana 是一个开源的分析和交互式可视化平台，支持从多种数据源（Prometheus、Elasticsearch、InfluxDB 等）获取数据，创建实时仪表板和告警。
+
+## 核心功能
+- **多数据源支持**：Prometheus、Elasticsearch、InfluxDB、MySQL、CloudWatch 等
+- **可视化面板**：Graph、Stat、Gauge、Table、Heatmap 等多种图表类型
+- **Dashboard 即代码**：支持 JSON 导出和版本控制
+- **告警规则**：支持基于查询结果的告警
+- **变量系统**：支持动态仪表板和交互式过滤
+
+## 在 DevOps Automator 中的角色
+- 可观测性可视化平台的核心组件
+- 展示 Prometheus 采集的应用程序和基础设施指标
+- 用于构建运维仪表板，跟踪部署频率、MTTR 等关键指标
+
+## 相关概念
+- [[Observability]]
+- [[Prometheus]]
+
+## 相关工具
+- Grafana Loki（日志聚合）
+- Grafana Tempo（分布式追踪）
+- Grafana OnCall（告警管理）
+- Grafana Agent（指标、日志、追踪的统一采集）
+
 ## Aliases
-- Grafana Labs
+- Grafana
 - Grafana Dashboard
-
-## Summary
-开源数据可视化平台，支持多种数据源，可创建交互式仪表盘。
-
-## Description
-Grafana 是一款开源的可观测性平台，用于数据可视化和监控仪表盘。
-
-### 核心特性
-- 多数据源支持（Prometheus、PostgreSQL、InfluxDB）
-- 丰富的图表类型
-- 告警功能
-- 模板变量
-- 团队协作
-
-### 电商场景适用性
-连接 PostgreSQL，可视化电商产品趋势、价格分布、竞品对比等分析报表。
-
-## Use Cases
-- [[可自动化-可扩展-ai增强的电商数据采集与处理系统]] — 数据可视化展示层
-
-## Connections
-- [[PostgreSQL]] — 读取电商数据进行可视化
-
+- Grafana Visualization
diff --git a/wiki/entities/GraphDaemon.md b/wiki/entities/GraphDaemon.md
new file mode 100644
index 00000000..fc664898
--- /dev/null
+++ b/wiki/entities/GraphDaemon.md
@@ -0,0 +1,69 @@
+---
+title: "GraphDaemon"
+type: entity
+entity_type: tool
+tags:
+  - LSP
+  - code-intelligence
+  - semantic-graph
+  - TypeScript
+sources:
+  - lsp-index-engineer.md
+last_updated: 2026-04-29
+---
+
+## Overview
+GraphDaemon（graphd）是 LSP/Index Engineer Agent 的核心图谱守护进程，负责协调多个 LSP 客户端并发运行，将异构语言服务器的响应转换为统一的语义图谱，为沉浸式代码可视化提供基础设施。默认要求 TypeScript 和 PHP 语言服务器生产就绪。
+
+## Core Components
+
+### LSP Client Management
+- **LSPClients**：`Map<string, LanguageClient>` — 管理 TypeScript、PHP、Go、Rust、Python 等多语言 LSP 客户端
+- **Capabilities**：`Map<string, ServerCapabilities>` — 存储各语言服务器的能力协商结果
+
+### Graph State
+- **Nodes**：`Map<NodeId, GraphNode>` — 文件节点和符号节点
+- **Edges**：`Map<EdgeId, GraphEdge>` — contains/imports/calls/refs 关系边
+- **Index**：SymbolIndex — 符号索引，支持快速查询
+
+### API Endpoints
+- `/graph` — 返回完整图谱（< 100ms，< 10k 节点）
+- `/nav/:symId` — 符号导航（< 20ms 缓存 / < 60ms 未缓存）
+- `/stats` — 系统统计信息
+
+### WebSocket Server
+- 实时推送图谱差异更新，延迟 < 50ms
+
+### File Watching
+- 文件变化监听和 Git hooks 触发增量更新
+
+## Graph Schema
+
+### Node Types
+- `file` — 文件节点
+- `module` — 模块节点
+- `class` — 类符号
+- `function` — 函数符号
+- `variable` — 变量符号
+- `type` — 类型符号
+
+### Edge Types
+- `contains` — 文件包含符号
+- `imports` — 模块导入关系
+- `extends` — 继承关系
+- `implements` — 实现关系
+- `calls` — 函数调用关系
+- `references` — 符号引用关系
+
+## Performance Targets
+- /graph 端点：< 100ms（< 10k 节点）
+- /nav/:symId：< 20ms（缓存）/ < 60ms（未缓存）
+- WebSocket 延迟：< 50ms
+- 内存使用：< 500MB
+- 规模能力：100k+ 符号无性能降级
+
+## Connections
+- [[GraphDaemon]] ← builds ← [[SemanticCodeGraph]]
+- [[GraphDaemon]] ← orchestrates ← [[LSPOrchestrator]]
+- [[GraphDaemon]] ← streams via ← [[WebSocket]]
+- [[GraphDaemon]] ← indexes via ← [[nav.index.jsonl]]
diff --git a/wiki/entities/Great-Expectations.md b/wiki/entities/Great-Expectations.md
new file mode 100644
index 00000000..58781eff
--- /dev/null
+++ b/wiki/entities/Great-Expectations.md
@@ -0,0 +1,58 @@
+---
+title: "Great Expectations"
+type: entity
+tags: [data-engineering, data-quality, testing, validation]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Overview
+
+Great Expectations（gx）是 Python 原生的数据质量验证框架，支持自动化测试数据管道的可靠性。Data Engineer Agent 使用 Great Expectations 在 Silver→Gold 层之间实施行级数据质量评分，确保 Gold 层数据符合 SLA 承诺。
+
+## Core Usage Pattern
+
+```python
+import great_expectations as gx
+
+context = gx.get_context()
+
+def validate_silver_orders(df) -> dict:
+    batch = context.sources.pandas_default.read_dataframe(df)
+    result = batch.validate(
+        expectation_suite_name="silver_orders.critical",
+        run_id={"run_name": "silver_orders_daily", "run_time": datetime.now()}
+    )
+    stats = {
+        "success": result["success"],
+        "evaluated": result["statistics"]["evaluated_expectations"],
+        "passed": result["statistics"]["successful_expectations"],
+        "failed": result["statistics"]["unsuccessful_expectations"],
+    }
+    if not result["success"]:
+        raise DataQualityException(f"Silver orders failed validation: {stats['failed']} checks failed")
+    return stats
+```
+
+## Key Features
+
+- **Expectations**：声明式数据质量断言（如 `expect_column_values_to_be_between`、`expect_column_mean_to_be_between`）
+- **Profiling**：从现有数据自动生成期望规则
+- **Data Docs**：自动化数据质量报告（HTML 格式）
+- **Checkpoint**：将测试嵌入 CI/CD 流水线
+
+## Role in Medallion Architecture
+
+- **Bronze 层**：基础完整性检查（文件是否可读、schema 是否存在）
+- **Silver 层**：字段级质量验证（null 率、值范围、分布）
+- **Gold 层**：业务规则验证 + SLA 评分，评分必须附加到每行
+
+## Integration
+
+- **Spark Integration**：通过 `gx.spark.from_pyspark_df()` 直接验证 PySpark DataFrame
+- **Databricks**：原生 Great Expectations + Databricks Jobs 集成
+- **dbt Tests**：Great Expectations 规则可导出为 dbt 测试
+
+## Related Concepts
+- [[Data Contract]]
+- [[Medallion Architecture]]
diff --git a/wiki/entities/Greg.md b/wiki/entities/Greg.md
new file mode 100644
index 00000000..47e021fc
--- /dev/null
+++ b/wiki/entities/Greg.md
@@ -0,0 +1,34 @@
+---
+title: "Greg"
+type: entity
+tags:
+  - CTP
+  - DBRE
+  - AWS
+  - RDS
+sources:
+  - learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform
+last_updated: 2026-04-14
+---
+
+## Overview
+Greg 是 CTP（Cloud Transformation Programme）团队的 DBRE（Database Reliability Engineering）团队成员，在 Learning Sessions 中主讲通过 Terraform 部署 RDS 的实践课程。
+
+## Role
+- **DBRE 团队成员**：负责数据库可靠性工程
+- **Terraform IaC 推广者**：积极倡导使用 Terraform 而非 Console 方式部署任何规模的 RDS
+
+## Key Contributions
+- 推广 IaC 六大核心价值：速度、灵活性、一致性、灾难恢复、文档化、自动化
+- 主张"代码即文档"（The code is the documentation）作为 IaC 的核心理念
+- 推荐 Gruntwork RDS Service 模块（含 KMS 加密 + CloudWatch 告警）作为 RDS 部署首选
+- 推广 Terragrunt 作为 Terraform 封装工具，使用 tagged release 确保稳定性
+
+## Connections
+- [[Amazon-RDS]]：主要负责的云资源
+- [[Terragrunt]]：推荐的 IaC 工具
+- [[Gruntwork]]：模块来源
+- [[Infrastructure-as-Code]]：核心方法论
+
+## Referenced In
+- [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]
diff --git a/wiki/entities/Gruntwork.md b/wiki/entities/Gruntwork.md
index 464c4e00..d3837981 100644
--- a/wiki/entities/Gruntwork.md
+++ b/wiki/entities/Gruntwork.md
@@ -9,7 +9,8 @@ sources:
   - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi
   - ctp-topic-9-ci-cd-with-gruntwork
   - ctp-topic-16-cross-account-terraform-modules
-last_updated: 2023-08-08
+  - learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform
+last_updated: 2026-04-14
 ---
 
 ## Profile
diff --git a/wiki/entities/Hermes-Agent.md b/wiki/entities/Hermes-Agent.md
new file mode 100644
index 00000000..6f8cdc65
--- /dev/null
+++ b/wiki/entities/Hermes-Agent.md
@@ -0,0 +1,25 @@
+---
+title: "Hermes Agent"
+type: entity
+tags: []
+---
+
+## Overview
+Hermes Agent 是另一个本地运行的 AI Agent 系统，与 OpenClaw 并列，通过 n8n 工作流进行统一编排。
+
+## Key Facts
+- **默认端口**：8642
+- **Agent 指定方式**：`"model": "hermes-agent"`
+- **网络**：与 OpenClaw 共用同一局域网 IP，仅端口不同
+
+## 与 OpenClaw 对比
+
+| 属性 | Hermes Agent | OpenClaw |
+|------|-------------|----------|
+| 默认端口 | 8642 | 18789 |
+| Agent 指定方式 | `"model": "hermes-agent"` | `"model": "openclaw:<agentId>""` |
+| OpenAI 兼容端点 | 默认开启 | 默认关闭（需手动开启） |
+
+## Related Pages
+- [[n8n-调用openclaw-agents的工作流架构]]
+- [[OpenClaw]]
diff --git a/wiki/entities/IncidentCommander.md b/wiki/entities/IncidentCommander.md
new file mode 100644
index 00000000..11f742a7
--- /dev/null
+++ b/wiki/entities/IncidentCommander.md
@@ -0,0 +1,78 @@
+---
+title: "Incident Commander (IC)"
+type: entity
+tags: [incident-management, reliability, roles]
+last_updated: 2026-05-01
+---
+
+## Definition
+事故指挥官（Incident Commander，IC）是生产事故响应中的核心协调角色——唯一决策者，负责管理时间线、分配角色、驱动结构化决策。核心理念：**"Single throat to yell at, single brain to decide"**（单一出口发号施令，单一大脑做决策）。
+
+## Core Responsibilities
+
+### 1. 事故协调
+- 在事故声明后立即接管指挥权
+- 分配明确角色：Communications Lead、Technical Lead、Scribe
+- 维持固定节奏的状态更新（按严重等级：SEV1 每 15 分钟）
+
+### 2. 时间线管理
+- 记录每个行动和发现（含 UTC 时间戳）
+- 维护准确的事故时间线作为决策依据
+- 确保所有参与者信息同步
+
+### 3. 决策驱动
+- 在时间盒内做出决策（15 分钟假设验证）
+- 优先止血（缓解）而非根因分析
+- 当调查路径无法确认时，果断切换
+
+### 4. 沟通管理
+- 协调干系人（工程师/管理层/客户）的信息发布
+- 确保沟通节奏与严重等级匹配
+- 宣布事故解决并发送 All-Clear
+
+## Incident Roles Ecosystem
+
+```
+Incident Commander (IC)
+├── Communications Lead — 干系人状态更新（内部/外部）
+├── Technical Lead — 诊断和修复（使用 runbooks、可观测性工具）
+└── Scribe — 实时行动记录和时间线维护
+```
+
+## Severity-Based Response
+
+| 严重等级 | IC 响应时间 | 更新节奏 | 升级路径 |
+|----------|------------|----------|----------|
+| SEV1 | < 5 分钟 | 每 15 分钟 | VP Eng + CTO 即时 |
+| SEV2 | < 15 分钟 | 每 30 分钟 | Eng Manager 15 分钟内 |
+| SEV3 | < 1 小时 | 每 2 小时 | Team lead 下次站会 |
+| SEV4 | 下一个工作日 | 每日 | Backlog 评审 |
+
+## Key Rules
+
+| 规则 | 说明 |
+|------|------|
+| 决策权威 | IC 是唯一决策者，其他角色执行和支持 |
+| 不跳级 | 永远不跳过严重等级分类（决定后续所有行动） |
+| 实时记录 | 行动必须实时记录，而非事后回忆 |
+| 先止血后治本 | 优先缓解影响，根因分析在稳定后进行 |
+
+## Success Metrics
+
+- **MTTD**（Mean Time to Detect）：< 5 分钟（SEV1/2）
+- **MTTR**（Mean Time to Resolve）：< 30 分钟（SEV1）
+- 100% SEV1/2 事故在 48 小时内完成复盘
+- 零重复事故（同样的根本原因不再出现第二次）
+
+## Related Entities
+
+| 角色 | 关系 |
+|------|------|
+| [[engineering-incident-response-commander]] | IC Agent 的智能体人格定义 |
+| [[engineering-sre]] | IC 的工程背景，通常由 SRE 担任 IC 角色 |
+| [[OnCallEngineer]] | IC 通常由 on-call 工程师担任或指定 |
+
+## Aliases
+- IC（Incident Commander）
+- Incident Lead
+- Response Coordinator
diff --git a/wiki/entities/Intelephense.md b/wiki/entities/Intelephense.md
index 014eb851..ecd7de8d 100644
--- a/wiki/entities/Intelephense.md
+++ b/wiki/entities/Intelephense.md
@@ -1,39 +1,26 @@
----
-title: "Intelephense"
-type: entity
-tags: [language-server, php]
-sources: [lsp-index-engineer]
-last_updated: 2026-04-25
----
-
-## Definition
-
-Intelephense 是 PHP 语言的主流 Language Server Protocol 实现，提供高性能的 PHP 代码智能功能，包括跳转到定义、查找引用、悬停文档、符号导航等。
-
-## Usage in LSP/Index Engineer
-
-LSP/Index Engineer 的 graphd 系统通过以下方式使用 Intelephense：
-
-```typescript
-const phpClient = new LanguageClient('php', {
-  command: 'intelephense',
-  args: ['--stdio'],
-  rootPath: projectRoot
-});
-```
-
-## Known Limitations
-
-Intelephense 与 TypeScript Language Server 相比：
-- 不支持层级符号（Hierarchical Symbols）
-- PHP 的命名空间和类结构解析有差异
-- LSP/Index Engineer 在 graphd 中需要针对这些差异进行适配处理
-
-## Note
-
-TypeScript 和 PHP 支持是 LSP/Index Engineer 的**默认要求**，必须首先达到生产就绪状态。PHP 优先使用 Intelephense，也可选择 phpactor 作为替代。
-
-## Aliases
-- intelephense
-- PHP Language Server
-- PHP LSP
+---
+title: "Intelephense"
+type: entity
+entity_type: tool
+tags:
+  - LSP
+  - PHP
+  - language-server
+sources:
+  - lsp-index-engineer.md
+last_updated: 2026-04-29
+---
+
+## Overview
+Intelephense 是 PHP 语言的 LSP 实现，graphd 默认要求生产就绪的语言服务器之一，提供 PHP 代码的跳转定义、引用查找、悬停文档和自动完成功能。
+
+## Details
+- **Command**: `intelephense --stdio`
+- **Protocol**: LSP 3.17
+- **Role in graphd**: 默认必须支持的生产就绪语言服务器
+- **Note**: TypeScript LSP 支持层级符号，但 PHP Intelephense 不支持——LSP/Index Engineer 强制要求"永远验证假设"，必须检查服务器能力响应而非假设支持
+
+## Connections
+- [[Intelephense]] ← is_coordinated_by ← [[LSPOrchestrator]]
+- [[Intelephense]] ← provides_semantics_to ← [[SemanticCodeGraph]]
+- [[Intelephense]] ← part_of ← [[GraphDaemon]]
diff --git a/wiki/entities/Jan.md b/wiki/entities/Jan.md
new file mode 100644
index 00000000..773a00d5
--- /dev/null
+++ b/wiki/entities/Jan.md
@@ -0,0 +1,29 @@
+---
+title: "Jan"
+type: entity
+tags:
+  - "ai-chat"
+  - "local-ai"
+  - "open-source"
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Overview
+Jan（26k stars）是一款开源本地 AI 应用，支持 Remote Model 配置接入远程 API。
+
+## Key Facts
+- **GitHub Stars**：26k
+- **License**：AGPL
+- **特点**：完全本地运行，数据不离开设备
+- **集成方式**：Remote Model 配置
+
+## Integration with Hermes Agent
+通过 Remote Model 配置：
+- **API URL**：`http://<host>:8642/v1/chat/completions`
+- **认证**：Bearer Token（`API_SERVER_KEY`）
+
+## Related Pages
+- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
+- [[hermes-agent]]（via Hermes-Agent.md）
+- [[OpenAI-Compatible-API]]
diff --git a/wiki/entities/JimLiu.md b/wiki/entities/JimLiu.md
new file mode 100644
index 00000000..a2b7c586
--- /dev/null
+++ b/wiki/entities/JimLiu.md
@@ -0,0 +1,37 @@
+---
+title: "JimLiu"
+type: entity
+tags: []
+sources: [baoyu-skills]
+last_updated: 2026-04-19
+---
+
+## Overview
+
+JimLiu（宝玉）是一位活跃在 GitHub 上的开发者，以创建高质量 AI 工具和工作流自动化技能闻名。主要贡献集中在 Claude Code Skills 生态，旗下 [[baoyu-skills]] 仓库提供从内容创作到多平台发布的一整套 AI 辅助工作流。
+
+## Aliases
+- 宝玉
+
+## Key Contributions
+
+### [[baoyu-skills]]
+
+Claude Code Skills 技能集，GitHub 地址：github.com/JimLiu/baoyu-skills。核心模块：
+
+- **内容生成技能**：baoyu-xhs-images（小红书卡片）、baoyu-infographic（信息图）、baoyu-diagram（SVG 图表）、baoyu-cover-image（封面图）、baoyu-slide-deck（幻灯片）、baoyu-comic（知识漫画）、baoyu-article-illustrator（文章插图）
+- **发布技能**：baoyu-post-to-x（X 推文/文章）、baoyu-post-to-wechat（微信公众号）、baoyu-post-to-weibo（微博头条文章）
+- **AI 生成技能**：baoyu-imagine（多 provider 文生图）、baoyu-danger-gemini-web（Gemini 交互）
+- **工具技能**：baoyu-youtube-transcript、baoyu-url-to-markdown、baoyu-danger-x-to-markdown、baoyu-compress-image、baoyu-format-markdown、baoyu-markdown-to-html、baoyu-translate
+
+### 其他相关仓库
+
+- **[[obsidian-必装-skills]]**（[[3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1]] 提及）：Obsidian 生态 AI Skills 推荐，包含 kepano 官方 defuddle、obsidian-cli、obsidian-bases，以及 t
+
+utor-skills、scholar-skill 等学习类技能。
+
+## Connections
+- [[baoyu-skills]] ← authored_by ← [[JimLiu]]
+- [[ClawHub]] ← distribution_platform ← [[baoyu-skills]]
+- [[OpenClaw]] ← ecosystem ← [[baoyu-skills]]
+- [[Claude-Code]] ← platform ← [[baoyu-skills]]
diff --git a/wiki/entities/John-Allspaw.md b/wiki/entities/John-Allspaw.md
new file mode 100644
index 00000000..9097c19b
--- /dev/null
+++ b/wiki/entities/John-Allspaw.md
@@ -0,0 +1,38 @@
+---
+title: "John Allspaw"
+type: entity
+tags: [sre, reliability, engineering, operations]
+last_updated: 2026-04-20
+---
+
+# John Allspaw
+
+John Allspaw 是 SRE 领域的先驱人物，Adaptive Capacity Labs 联合创始人，前 Etsy CTO。
+
+## Aliases
+- John Allspaw
+- John Allspaw and Dr. Richard I. Cook
+
+## Overview
+John Allspaw 在容量规划、事件管理和组织韧性领域有着丰富的一线经验。他的研究和实践深刻影响了现代 SRE 文化的形成。
+
+## Career Highlights
+- **Etsy**：前 CTO，主导了 Etsy 从传统运维到 SRE 文化的转型
+- **Adaptive Capacity Labs**：与 [[Richard-Cook]] 共同创办，专注系统可靠性和组织韧性研究
+
+## Key Contributions
+- **Organizational Second Hit Syndrome**：与 Richard Cook 共同提出
+- **Capacity Planning**：出版了《The Art of Capacity Planning》和《Web Operations》
+- **Resilience Engineering**：在多个会议上分享了大量关于事件响应和组织学习的研究
+
+## Notable Works
+- 《Working Together》— 与 Richard Cook 合著
+- 《The Art of Capacity Planning》
+- 《Web Operations》
+
+## Affiliations
+- [[Adaptive-Capacity-Labs]] — 联合创始人
+- Formerly: Etsy (CTO)
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/entities/JosephCampbell.md b/wiki/entities/JosephCampbell.md
new file mode 100644
index 00000000..8c12d76b
--- /dev/null
+++ b/wiki/entities/JosephCampbell.md
@@ -0,0 +1,26 @@
+---
+title: "Joseph Campbell"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- J. Campbell
+- Joseph Campbell
+
+## Overview
+Joseph Campbell (1904–1987) 是美国神话学家、作家，以"英雄之旅"（Hero's Journey / Monomyth）理论闻名于世。其著作《千面英雄》（The Hero with a Thousand Faces, 1949）系统归纳了跨文化神话叙事中的共同结构模式。
+
+## Key Contributions
+- **Monomyth / Hero's Journey**：英雄经历"离开→历险→归来"三阶段，包含启程（Call to Adventure）、启蒙（Initiation）、回归（Return）三大板块
+- **Follow Your Bliss**：鼓励个体追寻内在热情与使命的著名格言
+- **跨文化神话比较**：整合印度、希腊、北欧、日本等多文化神话体系
+
+## In The Agency Context
+[[Academic Narratologist]] 将 Hero's Journey 作为核心叙事框架之一，用于分析英雄叙事的角色弧线和结构节点。Christopher Vogler 的 Writer's Journey 正是基于 Campbell 理论发展而来。
+
+## References
+- The Hero with a Thousand Faces (1949)
+- The Power of Myth (1988, with Bill Moyers)
diff --git a/wiki/entities/K6.md b/wiki/entities/K6.md
new file mode 100644
index 00000000..76f43459
--- /dev/null
+++ b/wiki/entities/K6.md
@@ -0,0 +1,45 @@
+---
+title: "k6"
+type: entity
+tags: ["testing", "performance", "load-testing", "open-source"]
+last_updated: 2026-05-09
+---
+
+## Aliases
+- k6
+- k6.io
+- Grafana k6
+
+## Summary
+k6 是 Grafana 实验室开源的开发者友好型负载测试工具，用 JavaScript/Go 原生编写，专为规模化性能测试和可扩展性验证设计。API Tester Agent 和 Performance Benchmarker Agent 的核心测试工具之一。
+
+## Key Facts
+- **类型**：开源负载测试工具
+- **开发商**：Grafana Labs
+- **编程语言**：Go（核心引擎）+ JavaScript（测试脚本）
+- **许可**：Apache License 2.0
+- **官网**：https://k6.io
+
+## Core Capabilities
+- 编写简洁的 JavaScript 测试脚本定义负载场景
+- 支持 HTTP/WebSocket/gRPC/CSV 数据驱动测试
+- 内置 Checks（断言）和 Thresholds（阈值）定义
+- 与 Grafana、Tighthouse、Datadog 等监控平台无缝集成
+- 支持云端分布式执行（k6 Cloud）和本地单节点执行
+- 支持 HAR 文件导入，自动从浏览器录制生成测试脚本
+
+## Role in The Agency
+- [[testing-api-tester]] 使用 k6 执行 API 负载测试，验证 10x 正常流量容量和 SLA 合规性
+- [[testing-performance-benchmarker]] 使用 k6 编写综合性能测试套件，结合统计置信区间分析
+- [[Scalability]] 概念验证的推荐工具
+
+## Related Entities
+- [[Playwright]]：端到端功能测试；k6 专注负载与性能测试
+- [[REST Assured]]：Java 生态 API 测试；k6 跨语言通用
+- [[testing-performance-benchmarker]] ← uses ← [[K6]]
+- [[testing-api-tester]] ← uses ← [[K6]]
+
+## Related Concepts
+- [[Performance Testing]]
+- [[Load Testing]]
+- [[Scalability]]
diff --git a/wiki/entities/KakaoTalk.md b/wiki/entities/KakaoTalk.md
index 57bb3cd7..75a4bd1c 100644
--- a/wiki/entities/KakaoTalk.md
+++ b/wiki/entities/KakaoTalk.md
@@ -1,45 +1,45 @@
----
-title: "KakaoTalk"
-type: entity
-tags: []
-sources: []
-last_updated: 2026-04-25
----
-
-## 基本信息
-- **类型**：产品 / 通讯平台
-- **原文**：카카오톡（KakaoTalk）
-- **中文**：韩国版微信 / 连我
-- **运营公司**：Kakao Corp（카카오），韩国最大互联网平台之一
-- **用户规模**：截至 2024 年月活跃用户超 5000 万（韩国总人口约 5100 万）
-
-## 在韩国商务中的地位
-KakaoTalk 是韩国商务沟通的**核心渠道**，相当于中国商务场景中的微信。韩国专业人士将 KakaoTalk 视为半正式的商务工具，其使用方式直接影响商业关系的建立和维护。
-
-## 商务使用规范
-
-### 关系阶段与消息模板
-1. **初次接触（正式）**：必须通过介绍人引荐，消息使用完整正式语气，包含自我介绍和咖啡邀约
-2. **已建立关系（半正式）**：寒暄+信息+请求，结尾用礼貌语
-3. **信任建立后**：可直接消息，允许表情符号，但不过量
-
-### 关键规则
-- **群聊必须韩语**：即使不完美也显示尊重；英语在韩国群聊中等于"我期待你迁就我"
-- **回复时间**：紧急事务同一工作日内；非紧急次日回复可接受
-- **已读回执可见**：超过 24 小时只读不回会被注意到
-- **语音消息**：仅在关系已支持非正式沟通时使用
-- **表情/贴纸**：信任建立后谨慎使用；初次接触绝对禁用
-- **商务时间**：9 AM - 7 PM KST；该时间外发送可接受但不要期待即时回复
-
-### 禁忌
-- 不要在 KakaoTalk 上直接谈报价（价格谈判应在线下或当面）
-- 不要发送长篇大论的自我介绍（韩国人不会在手机上阅读长文本）
-- 不要用 KakaoTalk 发送正式合同文件（用邮件）
-
-## Aliases
-- 카카오톡
-- Kakao
-- 韩国版微信
-
-## 来源
-- [[specialized-korean-business-navigator]] — KakaoTalk Business Communication Guide 完整规范
+---
+title: "KakaoTalk"
+type: entity
+tags: []
+sources: [specialized-korean-business-navigator]
+last_updated: 2026-04-25
+---
+
+## 基本信息
+- **类型**：产品 / 通讯平台
+- **原文**：카카오톡（KakaoTalk）
+- **中文**：韩国版微信 / 连我
+- **运营公司**：Kakao Corp（카카오），韩国最大互联网平台之一
+- **用户规模**：截至 2024 年月活跃用户超 5000 万（韩国总人口约 5100 万）
+
+## 在韩国商务中的地位
+KakaoTalk 是韩国商务沟通的**核心渠道**，相当于中国商务场景中的微信。韩国专业人士将 KakaoTalk 视为半正式的商务工具，其使用方式直接影响商业关系的建立和维护。
+
+## 商务使用规范
+
+### 关系阶段与消息模板
+1. **初次接触（正式）**：必须通过介绍人引荐，消息使用完整正式语气，包含自我介绍和咖啡邀约
+2. **已建立关系（半正式）**：寒暄+信息+请求，结尾用礼貌语
+3. **信任建立后**：可直接消息，允许表情符号，但不过量
+
+### 关键规则
+- **群聊必须韩语**：即使不完美也显示尊重；英语在韩国群聊中等于"我期待你迁就我"
+- **回复时间**：紧急事务同一工作日内；非紧急次日回复可接受
+- **已读回执可见**：超过 24 小时只读不回会被注意到
+- **语音消息**：仅在关系已支持非正式沟通时使用
+- **表情/贴纸**：信任建立后谨慎使用；初次接触绝对禁用
+- **商务时间**：9 AM - 7 PM KST；该时间外发送可接受但不要期待即时回复
+
+### 禁忌
+- 不要在 KakaoTalk 上直接谈报价（价格谈判应在线下或当面）
+- 不要发送长篇大论的自我介绍（韩国人不会在手机上阅读长文本）
+- 不要用 KakaoTalk 发送正式合同文件（用邮件）
+
+## Aliases
+- 카카오톡
+- Kakao
+- 韩国版微信
+
+## 来源
+- [[specialized-korean-business-navigator]] — KakaoTalk Business Communication Guide 完整规范
diff --git a/wiki/entities/Karpathy.md b/wiki/entities/Karpathy.md
new file mode 100644
index 00000000..f3681069
--- /dev/null
+++ b/wiki/entities/Karpathy.md
@@ -0,0 +1,23 @@
+---
+title: "Karpathy"
+type: entity
+tags: [AI, researcher]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- Andrej Karpathy
+- @karpathy
+
+## Profile
+OpenAI 联合创始人、前特斯拉 Autopilot 视觉团队负责人，斯坦福大学深度学习课程（CS231n）讲师，知名 AI 研究者与技术布道者。
+
+## Key Contributions
+- 在 GitHub Gist（[karpathy/442a6bf555914893e9891c11519de94f](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)）发布了 **LLM Wiki** 方法论
+- 提出用 LLM 增量构建和维护持久化 Wiki，替代传统 RAG 的"每次从零开始"模式
+- 核心观点：**"AI 不会厌倦，不会忘记更新交叉引用，一次操作可以碰十五个文件，维护成本趋近于零"**
+
+## Role in This Wiki
+- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]] — 来源发起者
+- [[LLM Wiki]] — 理论提出者
diff --git a/wiki/entities/Kuaishou.md b/wiki/entities/Kuaishou.md
index 0f9d3aff..de5bb359 100644
--- a/wiki/entities/Kuaishou.md
+++ b/wiki/entities/Kuaishou.md
@@ -1,47 +1,34 @@
 ---
 title: "Kuaishou"
 type: entity
-tags: []
-sources: []
-last_updated: 2026-04-21
+tags: [中国社交媒体, 短视频平台, 直播电商]
+sources: [marketing-kuaishou-strategist, marketing-livestream-commerce-coach]
+last_updated: 2026-04-30
 ---
 
-# Kuaishou（快手）
+## 基本信息
+- **全称**：快手科技（Kuaishou Technology）
+- **定位**：中国第二大短视频与直播电商平台（仅次于抖音）
+- **核心用户**：下沉市场用户，三四五线城市，30-50岁群体为主
 
-## Aliases
-- Kuaishou
-- 快手
-- Kwai
-
-## Definition
-快手是中国第二大短视频平台和领先的直播电商平台，以"老铁经济"（兄弟文化）为核心差异化定位，主要覆盖中国低线城市（下沉市场）的30-50岁用户群体。
-
-## Key Characteristics
-- **均衡分发算法**：给予每个创作者基础流量曝光，触发扩大分发由社区互动（评论、点赞、分享）决定，而非纯算法推荐
-- **老铁文化**：创作者与粉丝之间基于真实信任的兄弟关系，强调长期忠诚而非一次性流量
-- **直播电商核心平台**：中国下沉市场直播带货的主要阵地，信任驱动型重复购买
-- **内容审美**：真实质朴 > 精致制作，用户能即时识别并拒绝不真实内容
-
-## Relationship to Douyin
-快手与抖音是中国短视频双巨头，两者存在根本差异：
+## 核心特征
+- **均衡分发算法**：给予每个创作者基础曝光量，坚持日更比单次爆款更有价值
+- **老铁文化**：兄弟情谊式的粉丝关系，信任驱动重复购买和主动品牌辩护
+- **内容风格**：真实场景 > 精致制作，真实性是一切的基础
+- **电商模式**：信任-based repeat purchases（关系驱动）vs 抖音的 impulse discovery purchases（冲动发现）
 
+## 与抖音的差异
 | 维度 | 快手 | 抖音 |
 |------|------|------|
-| 核心算法 | 均衡分发 | 中心化推荐 |
-| 主要受众 | 下沉市场，30-50岁 | 一二线城市，18-35岁 |
-| 内容审美 | 真实质朴 | 精致潮流 |
-| 创作者-粉丝关系 | 深度老铁忠诚 | 算法依赖型浅关系 |
-| 商业模式 | 信任驱动重复购买 | 发现型冲动购买 |
-| 增长模式 | 慢积累，长期忠诚 | 快爆发，难留存 |
+| 算法 | 均衡分发 | 中心化推荐 |
+| 受众 | 下沉市场，30-50岁 | 一二线城市，18-35岁 |
+| 内容审美 | 真实、质朴 | 精致、时尚 |
+| 粉丝关系 | 深度老铁忠诚 | 浅层、算法依赖 |
+| 增长模式 | 慢建立，长期忠诚 | 快爆发，难以留存 |
 
-**核心原则**：绝不将抖音内容直接复用到快手，两者面向不同用户心理和平台生态。
+## 相关来源
+- [[marketing-kuaishou-strategist]]
 
-## Related Agents
-- [[Marketing-Kuaishou-Strategist]]：快手平台专项策略 Agent
-- [[Marketing-Douyin-Strategist]]：抖音平台专项策略 Agent（平台兄弟）
-
-## Related Concepts
-- [[老铁经济]]：快手特有的兄弟文化商业模式
-- [[均衡分发算法]]：快手的核心推荐机制
-- [[下沉市场]]：快手的主要目标受众
-- [[直播带货]]：快手的核心商业化路径
+## Aliases
+- 快手
+- Kuaishou
diff --git a/wiki/entities/Kubernetes.md b/wiki/entities/Kubernetes.md
index d3ef56b7..625afdeb 100644
--- a/wiki/entities/Kubernetes.md
+++ b/wiki/entities/Kubernetes.md
@@ -1,114 +1,46 @@
----
-title: "Kubernetes"
-type: entity
-tags:
-  - cloud
-  - container
-  - orchestration
-  - devops
-sources: [cloud-operating-model-key-strategies-and-best-practices]
-created: 2026-04-25
----
-
-# Kubernetes
-
-## Definition
-
-Kubernetes (K8s) 是 Google 开源的**容器编排平台**，用于自动化容器化应用的部署、扩缩容和管理。是云原生 (Cloud-Native) 架构的核心基础设施，也是 Agentic AI 自主修复 (Self-Healing) 的主要目标环境。
-
-## Aliases
-
-- K8s
-- Kubernetes
-- Container Orchestration Platform
-
-## Major Cloud Implementations
-
-| Provider | Service | Description |
-|----------|---------|-------------|
-| AWS | EKS (Elastic Kubernetes Service) | 托管 Kubernetes on AWS |
-| GCP | GKE (Google Kubernetes Engine) | 托管 Kubernetes on GCP |
-| Azure | AKS (Azure Kubernetes Service) | 托管 Kubernetes on Azure |
-
-## Kubernetes Self-Healing Capabilities
-
-Kubernetes 原生提供基础 Self-Healing 能力：
-
-```yaml
-# Kubernetes Self-Healing 原生机制
-apiVersion: apps/v1
-kind: Deployment
-spec:
-  replicas: 3
-  strategy:
-    type: RollingUpdate
-  template:
-    spec:
-      terminationGracePeriodSeconds: 30
-# 内置机制:
-# - 自动重启失败的容器
-# - 替换不健康的 Pod
-# - 滚动更新确保服务可用
-```
-
-Agentic AI 在原生能力基础上提供**更高级的自我修复**：
-
-| 能力 | Kubernetes 原生 | Agentic AI Enhanced |
-|------|---------------|-------------------|
-| Pod 重启 | ✅ 自动重启崩溃容器 | ✅ 智能分析根因 + 预防性重启 |
-| 扩缩容 | ✅ HPA 基于指标 | ✅ 预测性扩缩容 |
-| 节点恢复 | ✅ 节点故障迁移 | ✅ 主动健康检查 + 预防性迁移 |
-| 配置修复 | ❌ 需人工介入 | ✅ AI 自动修正 ConfigMap/Secret |
-
-## Agentic AI Monitoring Targets
-
-```
-┌─────────────────────────────────────────────────┐
-│              Agentic AI for Kubernetes            │
-├─────────────────────────────────────────────────┤
-│  监控层                                          │
-│  ├── Pod Metrics (CPU/Memory/Network)           │
-│  ├── Workload Health (Deployment/ReplicaSet)   │
-│  ├── Node Status (Ready/Condition)              │
-│  └── Cluster Components (etcd, API Server)     │
-│                                                  │
-│  决策层                                          │
-│  ├── Anomaly Detection (AI)                    │
-│  ├── Root Cause Analysis (AI)                   │
-│  └── Action Planning (AI)                       │
-│                                                  │
-│  执行层                                          │
-│  ├── kubectl API (restart/migrate/scale)       │
-│  ├── HPA Override (AI-driven scaling)          │
-│  └── Config Updates (AI-driven fixes)           │
-└─────────────────────────────────────────────────┘
-```
-
-## Example
-
-> An AI agent monitoring AWS EKS clusters detects high CPU usage due to a rogue pod:
-> - Pod `payment-service-v2-abc123` CPU usage: 95%
-> - AI correlates with recent deployment timestamp
-> - AI identifies: Memory leak in new version
-> - AI Actions:
->   1. Scale deployment to 3 replicas (distribute load)
->   2. Create rollback ticket
->   3. Notify team via Slack
->   4. Auto-rollback after approval
-
-## Related Concepts
-
-- [[Self-Healing Systems]] — Kubernetes 是 Self-Healing 的主要载体
-- [[Cloud-Native]] — Kubernetes 是 Cloud-Native 的核心
-- [[Deployment Automation]] — Kubernetes 部署的自动化
-- [[Container Lifecycle Hardening]] — 容器安全加固
-
-## Related Entities
-
-- [[Agentic AI]] — Kubernetes 是 Agentic AI 的管理对象
-- EKS, GKE, AKS — 具体云服务商实现
-
-## Related Sources
-
-- [[how-agentic-ai-can-help-for-cloud-devops]]
-- [[ctp-topic-70-eks-deployment-using-iac]]
+---
+title: "Kubernetes"
+type: entity
+tags: [Container, Orchestration, DevOps]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
+---
+
+# Kubernetes
+
+## 基本信息
+- **类型**：容器编排平台
+- **开发商**：CNCF（云原生计算基金会）
+- **官网**：https://kubernetes.io
+
+## 定义
+Kubernetes（K8s）是一个开源容器编排平台，用于自动化容器化应用的部署、扩缩容和管理，是云原生架构的核心基础设施。
+
+## 核心概念
+- **Pod**：最小调度单元，可包含一个或多个容器
+- **Deployment**：声明式应用管理，支持滚动更新和回滚
+- **Service**：为 Pod 提供稳定的网络访问入口
+- **Ingress**：HTTP/HTTPS 负载均衡和路由
+- **ConfigMap/Secret**：应用配置和敏感信息管理
+- **Horizontal Pod Autoscaler (HPA)**：基于指标的自动扩缩容
+
+## 在 DevOps Automator 中的角色
+- 容器化应用部署的核心平台
+- 支持蓝绿部署、金丝雀发布、滚动更新策略
+- 通过 kubectl 命令行实现零停机部署
+
+## 相关概念
+- [[Zero-Downtime Deployment]]
+- [[Infrastructure as Code]]
+- [[Observability]]
+
+## 相关工具
+- Amazon EKS（AWS 托管 Kubernetes）
+- Google GKE（Google 托管 Kubernetes）
+- Karpenter（Kubernetes 节点自动配置）
+- Istio/Linkerd（Service Mesh）
+
+## Aliases
+- K8s
+- Kubernetes
+- K8
diff --git a/wiki/entities/LibreChat.md b/wiki/entities/LibreChat.md
new file mode 100644
index 00000000..8e7c0026
--- /dev/null
+++ b/wiki/entities/LibreChat.md
@@ -0,0 +1,28 @@
+---
+title: "LibreChat"
+type: entity
+tags:
+  - "ai-chat"
+  - "open-source"
+  - "multi-backend"
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Overview
+LibreChat（34k stars）是一款开源多后端聊天平台，支持同时连接多个 AI 后端。可通过 `librechat.yaml` 配置接入 Hermes Agent。
+
+## Key Facts
+- **GitHub Stars**：34k
+- **License**：MIT
+- **集成方式**：`librechat.yaml` 配置文件
+
+## Integration with Hermes Agent
+通过 `librechat.yaml` 配置 OpenAI 兼容 Provider：
+- **API URL**：`http://<host>:8642/v1/chat/completions`
+- **API Key**：`API_SERVER_KEY` 配置的 Bearer Token
+
+## Related Pages
+- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
+- [[hermes-agent]]（via Hermes-Agent.md）
+- [[OpenAI-Compatible-API]]
diff --git a/wiki/entities/LobeChat.md b/wiki/entities/LobeChat.md
new file mode 100644
index 00000000..8f4cf9fa
--- /dev/null
+++ b/wiki/entities/LobeChat.md
@@ -0,0 +1,28 @@
+---
+title: "LobeChat"
+type: entity
+tags:
+  - "ai-chat"
+  - "open-source"
+  - "frontend"
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Overview
+LobeChat（73k stars）是一款开源 AI 聊天前端，支持自定义 Provider，可通过 OpenAI 兼容 API 接入 Hermes Agent。
+
+## Key Facts
+- **GitHub Stars**：73k
+- **License**：Apache 2.0
+- **集成方式**：自定义 Provider 配置，指定 API URL 和 Key
+
+## Integration with Hermes Agent
+通过 Hermes Agent 的 OpenAI 兼容 API Server 接入，需要配置：
+- **API URL**：`http://<host>:8642/v1/chat/completions`（或 `/v1/responses`）
+- **API Key**：`API_SERVER_KEY` 配置的 Bearer Token
+
+## Related Pages
+- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
+- [[hermes-agent]]（via Hermes-Agent.md）
+- [[OpenAI-Compatible-API]]
diff --git a/wiki/entities/LuxuryDeveloper.md b/wiki/entities/LuxuryDeveloper.md
new file mode 100644
index 00000000..8717c3f3
--- /dev/null
+++ b/wiki/entities/LuxuryDeveloper.md
@@ -0,0 +1,30 @@
+---
+title: "LuxuryDeveloper"
+type: entity
+tags: [developer, brand-development, the-agency]
+sources: [design-whimsy-injector]
+last_updated: 2026-05-15
+---
+
+# LuxuryDeveloper
+
+## Definition
+
+豪华品牌开发者目标角色（Target User of Brand Personality Agents），[[The-Agency]] 生态中的核心受益者。需要为产品注入品牌个性和差异化体验的开发者，通过调用 [[ArchitectUX]] 和 [[Whimsy-Injector]] 等 Design 部门 Agent 实现。
+
+## Role
+
+LuxuryDeveloper 是品牌开发者的抽象角色定义，代表需要以下能力的开发者：
+- 为产品建立独特品牌个性
+- 通过微交互提升用户体验
+- 通过游戏化和彩蛋增加用户参与度
+- 确保趣味元素不影响性能和无障碍访问
+
+## Relationship to Other Agents
+
+- [[ArchitectUX]] ← provides technical foundation ← LuxuryDeveloper
+- [[Whimsy-Injector]] ← injects brand personality ← LuxuryDeveloper
+
+## Aliases
+- Luxury Developer
+- Brand Developer
diff --git a/wiki/entities/Lychee-Technology.md b/wiki/entities/Lychee-Technology.md
new file mode 100644
index 00000000..9044431d
--- /dev/null
+++ b/wiki/entities/Lychee-Technology.md
@@ -0,0 +1,24 @@
+---
+title: "Lychee Technology Inc."
+type: entity
+tags:
+  - "company"
+  - "engineering-blog"
+sources: []
+last_updated: 2026-04-20
+---
+
+## Overview
+Lychee Technology Inc. — 发布 engineering blog 的公司，专注于 production-grade AI 系统设计实践。
+
+## Details
+- **Type**: Company
+- **Blog**: https://blog.ltbase.dev
+- **Focus**: Agentic AI 系统工程、LLM 可靠执行架构、Harness Engineering 实践
+
+## Key Publications
+- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]：Harness Engineering 核心文章
+
+## Aliases
+- Lychee Technology
+- ltbase.dev
diff --git a/wiki/entities/MCCLevelStrategy.md b/wiki/entities/MCCLevelStrategy.md
new file mode 100644
index 00000000..ffeb86fd
--- /dev/null
+++ b/wiki/entities/MCCLevelStrategy.md
@@ -0,0 +1,35 @@
+---
+title: "MCC Level Strategy"
+type: entity
+tags:
+  - advertising
+  - google
+  - enterprise
+  - paid-media
+sources:
+  - paid-media-ppc-strategist
+last_updated: 2026-05-01
+---
+
+## Profile
+MCC（My Client Center）是 Google Ads 的代理/多账户管理结构，允许通过单一登录管理多个 Google Ads 子账户（最多 1000 个）。MCC Level Strategy 是在 MCC 框架下的顶层账户管理策略，涵盖跨账户预算分配、竞价策略协调、合规管理和统一报告。
+
+## Core Capabilities Referenced
+- **Cross-Account Budget Pacing**：在多个子账户之间动态调整预算分配
+- **Portfolio Bid Strategies**：跨账户组合竞价策略，在账户层面统一优化 ROAS/CPA
+- **Unified Reporting**：MCC 级汇总报告，支持跨账户效果对比和基准分析
+- **Label System for Scalability**：通过标签系统对数百个账户进行分类管理
+- **Account Health Monitoring**：MCC 级账户健康评分监控，识别表现异常的账户
+- **Google Ads API at MCC Scale**：通过 API 批量操作多个账户
+
+## Enterprise Use Cases
+- **Agency Management**：广告代理公司管理多个客户账户
+- **Multi-Brand Organization**：同一品牌下多个子品牌/产品线的独立账户管理
+- **Franchise/Dealer Network**：连锁品牌为各门店/经销商建立独立账户
+- **Geographic Expansion**：按地区/国家建立独立账户，统一协调
+
+## Connections
+- [[GoogleAds]]：MCC 是 Google Ads 的多账户管理结构
+- [[GoogleAdsAPI]]：API 是 MCC 级策略程序化执行的核心工具
+- [[BudgetPacing]]：MCC 级预算分配和 pacing 是核心议题
+- [[AutomatedBiddingStrategy]]：Portfolio Bid Strategies 是自动化竞价的 MCC 级实现
diff --git a/wiki/entities/Malt.md b/wiki/entities/Malt.md
new file mode 100644
index 00000000..0d82417b
--- /dev/null
+++ b/wiki/entities/Malt.md
@@ -0,0 +1,79 @@
+---
+title: "Malt"
+type: entity
+tags: []
+sources: [specialized-french-consulting-market]
+last_updated: 2026-04-25
+---
+
+# Malt
+
+## Aliases
+- Malt
+- Malt Platform
+- Malt Europe
+
+## Definition
+
+Malt 是欧洲最大的自由职业者平台（总部位于法国），专门服务于 IT 咨询和数字领域独立专业人士与企业的匹配。作为进入法国 ESN/SI 生态系统的核心平台之一，Malt 为自由顾问提供项目发现、合同签订和款项收取的一站式服务。
+
+## Core Business Model
+
+| 维度 | 说明 |
+|------|------|
+| **佣金结构** | 10% 客户侧佣金（Client-side fee），顾问端免费 |
+| **适用市场** | 法国为主，覆盖欧洲（英国、德国、西班牙） |
+| **主要用户** | IT 顾问、开发者、设计师、项目经理 |
+| **核心价值** | 作品集展示、项目匹配、合同管理、支付保障 |
+
+## Rate Positioning on Malt
+
+Malt 平台的费率策略具有高度透明度——所有顾问的报价对潜在客户可见，这带来双重影响：
+
+- **机会**：帮助顾问建立可验证的市场定价记录
+- **风险**：一旦设定费率，即成为市场锚点，调整需要战略性考量
+
+> "Platform rates are public. What you charge on Malt is visible. Your Malt rate becomes your market rate. Price accordingly from day one." — French Consulting Market Navigator
+
+## Rate Range
+
+典型 TJM 区间：
+
+| 经验级别 | TJM 区间 |
+|---------|---------|
+| Junior（< 3年） | 450-550 EUR/天 |
+| Mid（3-7年） | 550-700 EUR/天 |
+| Senior（7-10年） | 650-850 EUR/天 |
+| Expert（> 10年） | 750-1,000+ EUR/天 |
+
+注：Salesforce、Data Cloud、Agentforce 等专项领域可在上述区间上浮 15-25%。
+
+## Platform Comparison
+
+| 平台 | 佣金 | TJM 典型区间 | 特点 |
+|------|------|------------|------|
+| **Malt** | 10%（客户侧） | 550-700 EUR | 作品集可见，费率公开 |
+| collective.work | 3-5% | 650-800 EUR | portage 集成，高价值任务 |
+| Comet | 15% | 600-750 EUR | 算法匹配，控制权低 |
+| Crème de la Crème | 15-20% | 700-900 EUR | 精品定位，审核严格 |
+| Free-Work | 免费/付费 | 500-900 EUR | 体量大，噪音多 |
+
+## Strategic Considerations
+
+### 何时选择 Malt
+- 处于 Freelance 早期阶段，需要建立作品集和客户评价
+- 希望进入法国市场但缺乏直接客户关系网络
+- 需要一个可验证的市场费率记录（对后续谈判有价值）
+
+### 定价策略
+- 首次定价需慎重：一旦公开即成为市场锚点
+- 高于市场平均的定价需要强有力差异化叙述（如 Agentforce + Data Cloud 双认证）
+- 初期可战略性报低价换取前几个评价，后续逐步提价
+
+### 潜在风险
+- 费率透明意味着竞争对手可直接看到你的定价
+- 低价锚定会永久影响谈判起点（建议不低于 550 EUR/天 for Salesforce Architect）
+- 平台依赖：单一平台依赖度高，建议与 collective.work 等配合使用
+
+## Related Sources
+- [[specialized-french-consulting-market]]
diff --git a/wiki/entities/Marcel-Mauss.md b/wiki/entities/Marcel-Mauss.md
new file mode 100644
index 00000000..c9efcb40
--- /dev/null
+++ b/wiki/entities/Marcel-Mauss.md
@@ -0,0 +1,26 @@
+---
+title: "Marcel Mauss"
+type: entity
+tags: ["anthropologist", "gift-economy", "french-sociology", "economic-anthropology", "primitive-forms"]
+last_updated: 2026-04-25
+---
+
+## Overview
+法国社会学家和人类学家，涂尔干（Durkheim）的外甥。《礼物》（The Gift）作者，系统阐述了礼物经济中互惠义务的机制，是经济人类学的奠基之作。
+
+## Aliases
+- Mauss
+- M. Mauss
+
+## Key Contributions
+- **礼物交换理论**：在原始/古代社会中，交换不仅是经济行为，更是社会义务——"礼物之灵"（hau）使接受者必须回报
+- **礼物义务（Potlatch）**：北太平洋西北岸部落通过毁坏财富展示来确立社会地位的大型仪式交换
+- **互惠原则（Reciprocity）**：社会凝聚力的基础机制之一——给予、接受、回报的三段循环
+
+## Relevance to Anthropologist Agent
+Anthropologist Agent 将 Mauss 的礼物经济作为 Advanced Capabilities 之一，用于设计基于互惠和社会义务的交换系统。
+
+## Connections
+- [[Gift-Economy]] ← authored_by ← [[Marcel-Mauss]]
+- [[Anthropologist-Agent]] ← uses_framework ← [[Marcel-Mauss]]
+- [[Polanyi]] ← extends ← [[Marcel-Mauss]]
diff --git a/wiki/entities/Marty-Cagan.md b/wiki/entities/Marty-Cagan.md
new file mode 100644
index 00000000..5967f5b3
--- /dev/null
+++ b/wiki/entities/Marty-Cagan.md
@@ -0,0 +1,27 @@
+---
+title: "Marty Cagan"
+type: entity
+tags: ["product-management", "person"]
+sources: ["Hermes-Agent-配置笔记"]
+last_updated: 2026-04-27
+---
+
+## Overview
+Marty Cagan 是国际知名产品管理专家，《INSPIRED：How to Create Tech Products Customers Love》作者。该名字被推荐作为 Hermes Agent 多角色配置中"产品经理"角色的命名来源（nova/marty）。
+
+## Aliases
+- Marty Cagan
+
+## Key Contributions
+- 《INSPIRED: How to Create Tech Products Customers Love》：产品管理领域权威著作
+- 创立 SVPG（Silicon Valley Product Group），专注于产品领导力培训
+- 提出"Product Discovery"理念，强调技术团队在产品成功中的核心作用
+
+## In Hermes Agent Context
+在 [[Hermes-Agent-配置笔记]] 中，Marty Cagan 被推荐作为 Hermes Agent 多角色 Vibe Coding 场景中"产品经理"角色的命名来源：
+- 推荐名字：`marty`
+- 角色定位：产品经理
+- 来源依据：Marty Cagan 的《Inspired》是产品管理领域的经典
+
+## Connections
+- [[Hermes-Agent-配置笔记]] → uses name → [[Marty-Cagan]]
diff --git a/wiki/entities/Mary-Douglas.md b/wiki/entities/Mary-Douglas.md
new file mode 100644
index 00000000..f1c57d13
--- /dev/null
+++ b/wiki/entities/Mary-Douglas.md
@@ -0,0 +1,25 @@
+---
+title: "Mary Douglas"
+type: entity
+tags: ["anthropologist", "symbolic-anthropology", "british", "religion", "purity"]
+last_updated: 2026-04-25
+---
+
+## Overview
+英国人类学家，符号人类学和宗教人类学的重要人物。《洁净与危险》（Purity and Danger）分析了禁忌（taboo）体系的社会功能，提出"污秽即失序"（dirt is matter out of place）的经典论断。
+
+## Aliases
+- Douglas
+- M. Douglas
+
+## Key Contributions
+- **洁净与危险（Purity and Danger）**：禁忌不是迷信，而是社会边界维护机制——"脏/危险"是对社会分类秩序的威胁的象征性表达
+- **分类系统（Grid/Group Analysis）**：通过二维框架（社会约束力 × 分类清晰度）分析不同文化如何组织社会和世界观
+- **制度性宗教分析**：关注仪式中的符号如何表达和强化社会结构
+
+## Relevance to Anthropologist Agent
+Anthropologist Agent 在 Belief System 设计中引用 Douglas 的分析框架，用于理解神圣/世俗边界（sacred/profane boundary）如何服务于社会控制。
+
+## Connections
+- [[Anthropologist-Agent]] ← uses_framework ← [[Mary-Douglas]]
+- [[Structuralism]] ← influenced_by ← [[Mary-Douglas]]
diff --git a/wiki/entities/McKinseyAndCompany.md b/wiki/entities/McKinseyAndCompany.md
new file mode 100644
index 00000000..b1abd3d2
--- /dev/null
+++ b/wiki/entities/McKinseyAndCompany.md
@@ -0,0 +1,21 @@
+---
+title: "McKinsey & Company"
+type: entity
+tags: ["consulting", "strategy", "framework-originator"]
+sources: ["support-executive-summary-generator"]
+last_updated: 2026-04-26
+---
+
+## Overview
+McKinsey & Company 是全球顶级战略咨询公司，成立于 1926 年，总部位于纽约。以其为财富 500 强企业提供的战略规划、组织变革和运营优化服务闻名。
+
+## Aliases
+- McKinsey
+- McKinsey & Company
+
+## Key Contributions
+- **SCQA Framework**：Situation-Complication-Question-Answer 结构化叙事框架，用于战略沟通和执行摘要
+- **金字塔式思维**：自上而下的逻辑沟通结构
+
+## Role in The Agency
+作为 [[support-executive-summary-generator]] Agent 的咨询方法论基础，SCQA 框架是该 Agent 生成高管执行摘要的核心叙事结构。
diff --git a/wiki/entities/Memex.md b/wiki/entities/Memex.md
new file mode 100644
index 00000000..e5924a9b
--- /dev/null
+++ b/wiki/entities/Memex.md
@@ -0,0 +1,29 @@
+---
+title: "Memex"
+type: entity
+tags: [concept, history, knowledge-management]
+sources: [llm-wiki]
+last_updated: 2026-05-02
+---
+
+## Overview
+Memex（Memory Extender）是 Vannevar Bush 在 1945 年经典文章 *"As We May Think"* 中提出的假想个人知识库设备。其核心思想是：用户可以在其中存储书籍、记录和通信，然后快速、自动地检索任意组合的内容。核心创新：**关联轨迹**（associative trails）——用户可以在任意两条记录之间建立联系，形成路径，模拟人脑的联想式思维。
+
+## 核心理念
+- **个人化知识库**：私密、主动维护的文档集合
+- **关联胜于层级**：文档之间的关联与文档本身同样重要
+- **类比人脑**：模拟人脑的联想式思维，而非传统图书馆的层级分类
+
+## 历史影响
+Memex 启发了后来的超文本系统（包括万维网）、Wiki 百科全书以及现代的个人知识管理工具。然而 Bush 本人未能解决的核心问题是：**谁来维护这些关联？** 手动建立和维护大量交叉引用的工作量令人望而却步。
+
+## 现代继承：LLM Wiki
+[[PersistentWiki]] 直接承接了 Bush 的 Memex 愿景。关键突破在于：LLM 解决了"谁来维护"的问题——LLM 不会厌倦、不会忘记更新交叉引用，一次可以处理多个文件，维护成本接近零。[[LLM Wiki]] 的三层架构（Raw Sources → Wiki → Schema）实现了 Bush 设想的核心功能，同时解决了其可扩展性问题。
+
+## Aliases
+- Memex
+
+## Related
+- [[VannevarBush]]：Memex 概念的提出者
+- [[PersistentWiki]]：承接 Memex 愿景的现代 LLM 驱动实现
+- [[LLM Wiki]]：持久化维基知识库模式的完整描述
diff --git a/wiki/entities/MicrosoftAdvertising.md b/wiki/entities/MicrosoftAdvertising.md
index 422ce6a6..25a87411 100644
--- a/wiki/entities/MicrosoftAdvertising.md
+++ b/wiki/entities/MicrosoftAdvertising.md
@@ -1,31 +1,32 @@
----
-title: "Microsoft Advertising"
-type: entity
-tags: ["paid-media", "advertising", "platform"]
-last_updated: 2026-04-20
----
-
-## Aliases
-- Microsoft Ads
-- Bing Ads
-- Microsoft Advertising (Bing/AOL/Yahoo)
-
-## Overview
-Microsoft Advertising 是微软运营的广告平台，覆盖 Bing、AOL、Yahoo 搜索网络，月活跃用户 5.4 亿。是 [[PaidMediaPpcStrategist]] 跨平台策略的重要组成部分。
-
-## Key Capabilities
-- **Search Ads**: 出现在 Bing、Yahoo、AOL 搜索结果中
-- **Shopping Ads**: Microsoft Shopping Campaigns
-- **Audience Ads**: 原生广告覆盖微软生态用户
-- **Audience Network**: 微软合作网络展示广告
-- 与 Google Ads 高度兼容，导入/导出便捷
-
-## Key Features Used by PPC Strategist
-- 关键词匹配和竞价策略
-- Audience targeting
-- UET (Universal Event Tracking) 转化追踪
-- 与 Google Ads 协同的跨平台预算分配
-
-## Connections
-- [[PaidMediaPpcStrategist]] 将 Microsoft Advertising 作为 Google Ads 之外的第二搜索广告渠道
-- [[GoogleAds]] 可与 Microsoft Advertising 共享广告系列和受众数据
+---
+title: "Microsoft Advertising"
+type: entity
+tags:
+  - advertising
+  - microsoft
+  - ppc
+  - paid-media
+sources:
+  - paid-media-ppc-strategist
+last_updated: 2026-05-01
+---
+
+## Profile
+Microsoft Advertising（前称 Microsoft adCenter/Bing Ads）是微软旗下的搜索广告平台，覆盖 Bing、Yahoo 和 AOL 搜索网络的付费搜索广告投放，是 Google Ads 之外最重要的搜索广告补充渠道。
+
+## Core Capabilities Referenced
+- **Search Ads**：与 Google Ads 相似的搜索广告机制，通过关键词触发
+- **Audience Ads**：微软特有的原生广告格式
+- **Product Ads**：购物广告，与 Microsoft Shopping 生态集成
+- **Cross-Platform Planning**：与 Google Ads 协同进行跨平台预算分配和策略规划
+- **UET（Universal Event Tracking）**：微软的转化追踪标签，等同于 Google Ads 的 Floodlight/GTM
+
+## Key Value for PPC Strategy
+- **Bing 用户特征**：Bing 用户往往年龄稍大、收入较高，在 B2B 和高客单价场景表现尤佳
+- **竞争密度较低**：相比 Google，Bing 搜索广告竞争密度更低，CPC 通常低于 Google
+- **与 Google 协同**：Microsoft Advertising 支持导入 Google Ads 关键词和广告系列结构，降低迁移成本
+- **Audience Network**：包含 MSN、Outlook、Microsoft Edge 等微软生态的展示广告库存
+
+## Connections
+- [[GoogleAds]]：主要竞争平台，账户架构相似，可通过相似策略运营
+- [[CrossPlatformPlanning]]：Google/Microsoft 预算分配是跨平台策略的核心组成部分
diff --git a/wiki/entities/MobileAppBuilder.md b/wiki/entities/MobileAppBuilder.md
new file mode 100644
index 00000000..254c9bd4
--- /dev/null
+++ b/wiki/entities/MobileAppBuilder.md
@@ -0,0 +1,30 @@
+---
+title: "MobileAppBuilder"
+type: entity
+tags: []
+sources: [agents-orchestrator]
+last_updated: 2026-05-29
+---
+
+## Overview
+**Mobile App Builder** is The Agency's mobile development specialist agent — responsible for native iOS/Android and cross-platform application development.
+
+## Role
+- **Role**: Mobile application developer
+- **Personality**: Platform-aware, user-experience focused, cross-platform conscious
+- **Specialization**: Native iOS/Android and cross-platform development
+
+## Core Responsibilities
+- Implement mobile application features from task list
+- Native iOS development (Swift/SwiftUI)
+- Native Android development (Kotlin/Jetpack Compose)
+- Cross-platform solutions (React Native, Flutter)
+- Coordinate with [[ArchitectUX]] for mobile-specific technical architecture
+
+## Within Pipeline
+- **Spawned By**: [[AgentsOrchestrator]] during Phase 3 Dev-QA Loop
+- **Validated By**: [[EvidenceQA]] — each task must pass QA before advancing
+- **Part Of**: [[Dev-QA-Loop]] in the [[AgentsOrchestrator]] pipeline
+
+## Sources
+- [[agents-orchestrator]]
diff --git a/wiki/entities/NEXUS.md b/wiki/entities/NEXUS.md
new file mode 100644
index 00000000..8449e082
--- /dev/null
+++ b/wiki/entities/NEXUS.md
@@ -0,0 +1,43 @@
+---
+title: "NEXUS"
+type: entity
+tags: [multi-agent-orchestration, the-agency, strategy]
+sources: [executive-brief, quickstart, nexus-spatial-discovery]
+last_updated: 2026-05-01
+aliases:
+  - NEXUS Framework
+---
+
+## Overview
+
+NEXUS（Network of EXperts, Unified in Strategy）是 The Agency 的多 Agent 编排框架——将 9 大专业化部门（Engineering、Design、Marketing、Product、Project Management、Testing、Support、Spatial Computing、Specialized Operations）共 147+ Agent 从"各自为战"转化为"协调统一的智能网络"。
+
+## Key Facts
+
+- **全称**：Network of EXperts, Unified in Strategy
+- **组织背景**：The Agency 多 Agent 协调框架
+- **三大部署模式**：
+  - **NEXUS-Full**：12-24周，All agents，用于完整产品生命周期
+  - **NEXUS-Sprint**：2-6周，15-25 agents，用于功能或 MVP 构建（推荐默认模式）
+  - **NEXUS-Micro**：1-5天，5-10 agents，用于精准单一任务执行
+- **核心量化数据**：
+  - 无协调时交接边界失败率：73%
+  - 并行执行时间线压缩：40-60%
+  - Dev↔QA 循环集成前缺陷捕获率：95%
+  - Phase 4 硬化时间减少：50%
+
+## Core Components
+
+- **Master Strategy**：800+行操作 doctrine，覆盖全部 Agent 跨越 7 阶段
+- **Phase Playbooks（7份）**：Phase 0 Discovery → Phase 1 Strategy → Phase 2 Foundation → Phase 3 Build → Phase 4 Hardening → Phase 5 Launch → Phase 6 Operate
+- **Handoff Templates（7份）**：QA pass/fail、Escalation、Phase gates、Sprints、Incidents 等标准化交接格式
+- **Scenario Runbooks（4份）**：Startup MVP、Enterprise Feature、Marketing Campaign、Incident Response
+
+## Relationships
+
+- [[executive-brief]]：战略概览，从商业价值层面论证 NEXUS 的必要性与量化收益
+- [[quickstart]]：快速启动指南，5分钟激活 NEXUS 流水线
+- [[nexus-strategy]]：完整操作 doctrine，800+行战略文档
+- [[agents-orchestrator]]：NEXUS 管道的核心执行控制器
+- [[Reality-Checker]]：NEXUS 质量门控体系的最终守门人
+- [[nexus-spatial-discovery]]：NEXUS 并行 Agent 协作的执行案例（8 Agent 10分钟完成完整规划）
diff --git a/wiki/entities/NUS-NTU.md b/wiki/entities/NUS-NTU.md
new file mode 100644
index 00000000..1245ee66
--- /dev/null
+++ b/wiki/entities/NUS-NTU.md
@@ -0,0 +1,98 @@
+---
+title: "NUS & NTU（新加坡国立大学与南洋理工大学）"
+type: entity
+tags: []
+sources: [study-abroad-advisor]
+last_updated: 2026-05-29
+---
+
+# NUS & NTU（新加坡国立大学与南洋理工大学）
+
+## Definition
+
+NUS（National University of Singapore，新加坡国立大学）和 NTU（Nanyang Technological University，南洋理工大学）——新加坡两所亚洲顶尖研究型大学，均为环太平洋大学联盟（APRU）成员，在 2024 QS 世界大学排名中分别位列第 8 位和第 26 位。
+
+## NUS（新加坡国立大学）
+
+### Overview
+- **QS 排名**：2024 QS 世界第 8 位，亚洲第 1 位
+- **建校年份**：1905 年（新加坡医学书院），2005 年合并为国立大学
+- **校区**：主校区（Kent Ridge）+ 多个海外学院
+- **学生规模**：约 42,000 学生（含本科 + 研究生）
+
+### Key Strengths
+| 学院/学科 | 特色 |
+|----------|------|
+| NUS Business School | 亚洲顶尖商学院，MBA 全球前 20 |
+| Computing (NUS School of Computing) | 计算机科学亚洲领先，AI/ML 研究强势 |
+| Engineering | 电机与计算机工程、材料科学全球前 20 |
+| Law | 亚洲顶尖法学院 |
+| Medicine | 医疗研究实力突出 |
+| Design & Engineering (SDE) | 设计工程学院（跨学科） |
+
+### Scholarships
+- **NUS Presidents Scholarship**：全额奖学金，竞争极激烈
+- **NUS Undergraduate Scholarship**：部分学费减免
+- **ASEAN Undergraduate Scholarship**：面向东盟国家学生
+- **Koch Industry Fellowship**：产学结合
+
+## NTU（南洋理工大学）
+
+### Overview
+- **QS 排名**：2024 QS 世界第 26 位，亚洲第 4 位
+- **建校年份**：1981 年，前身为南洋理工学院，1991 年升格为大学
+- **校区**：主校区（云南园）+ 新加坡国立教育学院 + 李光鼎医学院
+- **学生规模**：约 33,000 学生
+
+### Key Strengths
+| 学院/学科 | 特色 |
+|----------|------|
+| Nanyang Business School | 会计与金融全球前 20 |
+| Engineering (College of Engineering) | 材料科学全球第 1（2024 QS），电子电气工程全球前 10 |
+| S. Rajaratnam School of Subnational Studies | 国际关系/政治科学 |
+| Art, Design and Media | 设计、媒体艺术 |
+| School of Computer Science and Engineering | AI、机器人研究领先 |
+
+### Scholarships
+- **Nanyang Scholarship**：全额奖学金（含生活费），竞争激烈
+- **College Scholarship**：部分学费减免
+- **ASEAN Scholarship**：面向东盟学生
+
+## Singapore Study Abroad Advantages
+
+| 维度 | 优势 |
+|------|------|
+| 地理位置 | 华人为主文化圈，距离中国近，无时差 |
+| 教育质量 | 亚洲顶尖，NUS/NTU 文凭国际认可度高 |
+| 签证政策 | 学生签证审批快，无配额限制 |
+| 就业机会 | 国际化就业市场，金融/科技/工程领域机会多 |
+| 移民路径 | 毕业后可通过 EP（Employment Pass）申请永居 |
+| 英语环境 | 英语为主要工作语言，利于语言适应 |
+| 费用 | 相比英美，学费和生活费较为可控 |
+
+## Comparison: NUS vs NTU
+
+| 维度 | NUS | NTU |
+|------|-----|-----|
+| 综合排名（QS 2024） | 第 8 | 第 26 |
+| 商科 | ★★★★★ | ★★★★ |
+| 工程/科技 | ★★★★ | ★★★★★（材料/EE） |
+| 申请难度 | 较高 | 中等偏高 |
+| 校园规模 | 较大 | 较大（云南园） |
+| 国际声誉 | 全球知名度更高 | 亚洲/东南亚认可度高 |
+
+## Relationship to Study Abroad Planning
+
+[[study-abroad-advisor]] 将 NUS/NTU 作为新加坡留学的核心推荐院校：
+- 适合希望获得亚洲顶尖教育、同时享受国际化环境和留港发展机会的学生
+- 相比英美，NUS/NTU 的申请竞争相对较低，性价比高
+- 作为 US+HK+Singapore 多国联申策略的重要组成部分
+- 适合 STEM 方向（尤其材料科学、电子电气工程、计算机）和商科学生
+
+## Aliases
+- National University of Singapore
+- NUS
+- 南洋理工大学
+- NTU
+- Nanyang Technological University
+- 新加坡国立大学
diff --git a/wiki/entities/NextChat.md b/wiki/entities/NextChat.md
new file mode 100644
index 00000000..81387eb7
--- /dev/null
+++ b/wiki/entities/NextChat.md
@@ -0,0 +1,28 @@
+---
+title: "NextChat"
+type: entity
+tags:
+  - "ai-chat"
+  - "open-source"
+  - "frontend"
+sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
+---
+
+## Overview
+NextChat（87k stars）是一款开源 ChatGPT Web 应用，支持通过 `BASE_URL` 环境变量配置自定义后端接入 Hermes Agent。
+
+## Key Facts
+- **GitHub Stars**：87k
+- **License**：MIT
+- **集成方式**：设置 `BASE_URL` 环境变量
+
+## Integration with Hermes Agent
+通过环境变量配置：
+- **API URL**：`http://<host>:8642/v1/chat/completions`
+- **认证**：通过 `API_SERVER_KEY` Bearer Token
+
+## Related Pages
+- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
+- [[hermes-agent]]（via Hermes-Agent.md）
+- [[OpenAI-Compatible-API]]
diff --git a/wiki/entities/Nexus-Spatial.md b/wiki/entities/Nexus-Spatial.md
index e2017fb9..182fa823 100644
--- a/wiki/entities/Nexus-Spatial.md
+++ b/wiki/entities/Nexus-Spatial.md
@@ -1,61 +1,44 @@
 ---
 title: "Nexus Spatial"
 type: entity
-tags: [product, spatial-computing, ai-agents, spatial-aiops, the-agency]
+tags: []
 last_updated: 2026-03-05
 ---
 
-## Overview
+## Identity
 
-AI Agent 沉浸式 3D 命令中心——一个 VisionOS + WebXR 应用，为 AI Agent 编排提供空间化的监控、构建和协作环境。
+**Type:** Product（产品）
+**Source:** [[nexus-spatial-discovery]]
 
-由 8 个 [[The-Agency]] 专业 Agent 并行协作规划（[[nexus-spatial-discovery]]），10 分钟 wall-clock time 产出完整产品规划。
+## Definition
 
-## Core Capabilities
+Nexus Spatial 是由 8 个 [[The-Agency]] 专业 AI Agent 并行协作规划出的 AI Agent 空间指挥中心产品——一个 VisionOS + WebXR 应用，为 AI Agent 工作流提供沉浸式 3D 命令中心。
 
-- **3D Node Graph Visualization**：将 Agent 工作流可视化为 3D 节点图，数据流朝向用户
-- **Real-time Spatial Monitoring**：实时监控面板以空间面板形式展示
-- **Drag-and-Drop 3D Workflow Building**：3D 空间内拖放构建工作流
-- **Shared Spatial Collaboration**：多人进入共享 3D 空间协作
-- **AI Support Agent in Workspace**：支持代理以内嵌节点形式存在于用户空间工作区
+## Core Features
 
-## Pricing
+- 3D 节点图可视化 Agent 管线
+- 实时输出空间面板监控
+- 3D 空间拖放构建工作流
+- 共享空间环境协作
+- 运行时追踪空间叠加（调试杀手级用例）
 
-| Tier | Price | Target |
-|------|-------|--------|
-| Explorer | Free | 开发者、solo builders（3 agents，WebXR viewer）|
-| Pro | $99/user/month | 小团队（25 agents，协作）|
-| Team | $249/user/month | 中型 AI 团队（unlimited agents，分析）|
-| Enterprise | Custom ($2K-10K/mo) | 大型企业（SSO，RBAC，on-prem，SLA）|
+## Architecture
 
-## Strategy
+- **编排引擎**：Rust（亚毫秒调度）
+- **Web 客户端**：TypeScript + React Three Fiber（WebXR）
+- **原生客户端**：Swift 6 + SwiftUI + RealityKit（VisionOS）
+- **协作引擎**：Yjs（CRDT）+ WebRTC
+- **消息中间件**：NATS JetStream
 
-- **Phase 1 (Months 1-6)**：2D web dashboard with Three.js 2.5D → 50 paying teams，$60K MRR
-- **Phase 2 (Months 6-12)**：WebXR spatial mode → 200 teams，$300K MRR
-- **Phase 3 (Months 12-18)**：Native VisionOS app（仅在 spatial 需求验证后）→ 500 teams，$1M+ MRR
+## Strategic Positioning
 
-## Technical Architecture
+- **品类**：[[SpatialAIOps]]（空间 AI 运维）
+- **口号**：*"Mission Control for the Agent Era"*
+- **策略**：[[2D-First-Spatial-Second]]（WebXR 先行，VisionOS 最后）
 
-- Orchestration engine：Rust（亚毫秒调度，零 GC 停顿）
-- WebXR client：TypeScript + React Three Fiber
-- VisionOS client：Swift 6 + SwiftUI + RealityKit
-- Collaboration：Yjs (CRDT) + WebRTC
-- 8-service architecture：Auth / Workspace / Workflow / Orchestration / Collaboration / Streaming / Plugin / Billing
+## Connections
 
-## Key Insights from Discovery
-
-1. **2D-first, spatial-second**：所有 8 个 Agent 独立得出相同结论
-2. **Debugging is the killer use case**：空间叠加调试追踪是 3D 真正优于 2D 的场景
-3. **WebXR over VisionOS**：~100 万 Vision Pro 安装量无法支撑业务；Safari 2025 年末采纳 WebXR
-4. **"War room" collaboration**：多人共享 3D 空间进行事故响应是最强的空间价值主张
-
-## Related Entities
-
-- [[SpatialAIOps]]：Nexus Spatial 定义的新品类
-- [[Product-Trend-Researcher]]：验证市场机会
-- [[Brand-Guardian]]：定义品牌定位
-- [[Backend-Architect]]：设计技术架构
-- [[Growth-Hacker]]：规划 GTM 策略
-- [[UX-Researcher]]：识别用户痛点
-- [[XR-Interface-Architect]]：设计空间界面
-- [[LangChain]] / [[CrewAI]] / [[n8n]]：主要竞争产品
+- [[SpatialAIOps]] ← 定义品类
+- [[Command-Theater]] ← 界面架构
+- [[4-Level-Semantic-Zoom]] ← 导航范式
+- [[2D-First-Spatial-Second]] ← 分阶段策略
diff --git a/wiki/entities/NotebookLM.md b/wiki/entities/NotebookLM.md
index 94fc28ae..36d29f5e 100644
--- a/wiki/entities/NotebookLM.md
+++ b/wiki/entities/NotebookLM.md
@@ -1,37 +1,39 @@
----
-title: "NotebookLM"
-type: entity
-tags: [product, ai, google, productivity]
-sources: [google-神级生产力工具-所有-github-开源平替都找到了, 7-ways-i-use-notebooklm-to-make-my-life-easier]
-last_updated: 2026-04-23
----
-
-## Overview
-NotebookLM 是 Google 推出的 AI 笔记助手，核心特点是**严格基于用户上传的文档范围进行回答**（[[Source-Grounding]]），并能提供精准的原文引用。其最出圈的功能是**播客生成**（[[Passive-Learning]]），能将复杂资料一键转换为逼真的双人英语对话播客。
-
-## Aliases
-- Google NotebookLM
-- NotebookLM (Google)
-
-## Core Capabilities
-- **文档问答**：基于上传文档的精准回答，带原文引用
-- **播客生成（Audio Overviews）**：多角色对话音频生成，支持 Deep Dive / Brief / Critique / Debate 等风格定制，适合 [[Passive-Learning]] 场景
-- **多模态输入**：支持 PDF、网页、音频、YouTube 视频
-- **Source-Grounding**（来源锚定）：AI 严格限定于可信文档范围回答，确保无幻觉、可溯源
-
-## Daily Life Use Cases（来自用户实测）
-1. **信息积压处理**：将未读 PDF/文章/视频上传，AI 自动消化，通过问答提取要点
-2. **播客笔记**：Audio Overviews 将文档转为双 AI 主持的对话播客，适合驾驶/健身等被动学习
-3. **快速成为多主题专家**：上传专业领域文档，通过辩论式播客深入学习（Batman/Star Wars/Jupiter/Marine Corps 等）
-4. **编程辅助**：上传官方文档，通过对话实时学习，提供引用回溯
-5. **项目管理中枢**：将零散研究、想法、会议记录整合为结构化路线图
-6. **版本对比**：对比 App 更新、新闻稿、长文档差异，列出变化并附带引用
-7. **法律文档审核**：租约/合同分析，每个答案附引用，可一键回溯原文核实（Premium 核心卖点）
-
-## Key Parameters
-- 免费使用
-- 支持多语言文档
-- 基于 Google Gemini 模型驱动
-
-## Role in This Wiki
-作为标杆产品，是本文档中 6 款开源平替（OpenNotebook、SurfSense、Podcastfy、NotebookLlama、PageLM、InsightsLM）的共同参照对象。
+---
+title: "NotebookLM"
+type: entity
+tags: [product, ai, google, productivity]
+sources: [google-神级生产力工具-所有-github-开源平替都找到了, 7-ways-i-use-notebooklm-to-make-my-life-easier, llm-wiki]
+last_updated: 2026-05-02
+---
+
+## Overview
+NotebookLM 是 Google 推出的 AI 笔记助手，核心特点是**严格基于用户上传的文档范围进行回答**（[[Source-Grounding]]），并能提供精准的原文引用。其最出圈的功能是**播客生成**（[[Passive-Learning]]），能将复杂资料一键转换为逼真的双人英语对话播客。
+
+NotebookLM 采用的是传统 RAG 模式——每次查询时从原始文档检索相关片段。与 [[LLM Wiki]] 的持久化维基模式形成对比：NotebookLM 每次回答都从零推导，[[PersistentWiki]] 则通过一次编译持续复用知识。
+
+## Aliases
+- Google NotebookLM
+- NotebookLM (Google)
+
+## Core Capabilities
+- **文档问答**：基于上传文档的精准回答，带原文引用
+- **播客生成（Audio Overviews）**：多角色对话音频生成，支持 Deep Dive / Brief / Critique / Debate 等风格定制，适合 [[Passive-Learning]] 场景
+- **多模态输入**：支持 PDF、网页、音频、YouTube 视频
+- **Source-Grounding**（来源锚定）：AI 严格限定于可信文档范围回答，确保无幻觉、可溯源
+
+## Daily Life Use Cases（来自用户实测）
+1. **信息积压处理**：将未读 PDF/文章/视频上传，AI 自动消化，通过问答提取要点
+2. **播客笔记**：Audio Overviews 将文档转为双 AI 主持的对话播客，适合驾驶/健身等被动学习
+3. **快速成为多主题专家**：上传专业领域文档，通过辩论式播客深入学习（Batman/Star Wars/Jupiter/Marine Corps 等）
+4. **编程辅助**：上传官方文档，通过对话实时学习，提供引用回溯
+5. **项目管理中枢**：将零散研究、想法、会议记录整合为结构化路线图
+6. **版本对比**：对比 App 更新、新闻稿、长文档差异，列出变化并附带引用
+7. **法律文档审核**：租约/合同分析，每个答案附引用，可一键回溯原文核实（Premium 核心卖点）
+
+## Key Parameters
+- 免费使用
+- 支持多语言文档
+- 基于 Google Gemini 模型驱动
+
+## Role in This Wiki
+作为标杆产品，是本文档中 6 款开源平替（OpenNotebook、SurfSense、Podcastfy、NotebookLlama、PageLM、InsightsLM）的共同参照对象。
diff --git a/wiki/entities/Open-WebUI.md b/wiki/entities/Open-WebUI.md
index 8b69d5e6..9d75779b 100644
--- a/wiki/entities/Open-WebUI.md
+++ b/wiki/entities/Open-WebUI.md
@@ -1,67 +1,76 @@
----
-title: "Open WebUI"
-type: entity
-tags: []
-last_updated: 2026-04-23
----
-
-# Open WebUI
-
-## Overview
-Open WebUI（原名 Ollama WebUI）是一个开源的大语言模型 Web 界面项目，通过部署它可以得到一个**纯本地运行的基于浏览器访问的 Web 服务**。它提供了可扩展、功能丰富、用户友好的自托管 AI Web 界面，支持各种大型语言模型（LLM）运行器，可以通过配置形式便捷地集成 Ollama、OpenAI 等提供的 API。
-
-## Aliases
-- Open WebUI
-- OpenWebUI
-- open-webui
-
-## Key Facts
-- **Docker 镜像**: ghcr.io/open-webui/open-webui:main
-- **默认端口**: 8080
-- **核心功能**: 聊天机器人、本地知识库（RAG）、图像生成、联网搜索
-
-## Core Features
-1. **多模型支持**: 通过 Ollama API 或 OpenAI API 接入多种 LLM
-2. **RAG 本地知识库**: 使用嵌入模型（如 bge-m3）构建本地知识库
-3. **联网搜索**: 支持 Bing、博查等搜索引擎接入
-4. **图像生成**: 集成图像生成能力
-5. **跨域访问**: 通过 `CORS_ALLOW_ORIGIN=*` 支持跨域 API 调用
-
-## Docker Compose 部署示例
-```yaml
-services:
-  open-webui:
-    image: ghcr.io/open-webui/open-webui:main
-    environment:
-      - OLLAMA_API_BASE_URL=http://ollama:11434/api
-      - WEBUI_NAME="My LLM Service"
-      - ENABLE_OPENAI_API=false
-      - CORS_ALLOW_ORIGIN=*
-      - ENABLE_IMAGE_GENERATION=true
-      - DEFAULT_MODELS=deepseek-r1:8b
-      - RAG_EMBEDDING_MODEL=bge-m3
-    ports:
-      - 8080:8080
-    volumes:
-      - ./open_webui_data:/app/backend/data
-```
-
-## 前提条件
-- 已安装 Docker
-- 已部署 Ollama 并拉取模型（deepseek-r1:8b 和 bge-m3）
-
-## 联网搜索配置
-操作路径：`设置 → 联网搜索 → 启用联网搜索`
-支持的搜索引擎：
-- Bing
-- 博查（https://aq6ky2b8nql.feishu.cn/wiki/XgeXwsn7oiDEC0kH6O3cUKtknSR）
-
-**注意**：如不需要联网搜索功能，请勿开启以保护隐私数据。
-
-## Related Entities
-- [[Ollama]]：Open WebUI 通过 Ollama API 接入 LLM 服务
-- [[DeepSeek]]：Open WebUI 的推荐默认模型之一
-- [[RAG]]：Open WebUI 使用 RAG 技术构建本地知识库
-
-## Sources
-- [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]]
+---
+title: "Open WebUI"
+type: entity
+tags: []
+last_updated: 2026-04-23
+---
+
+# Open WebUI
+
+## Overview
+Open WebUI（原名 Ollama WebUI）是一个开源的大语言模型 Web 界面项目，通过部署它可以得到一个**纯本地运行的基于浏览器访问的 Web 服务**。它提供了可扩展、功能丰富、用户友好的自托管 AI Web 界面，支持各种大型语言模型（LLM）运行器，可以通过配置形式便捷地集成 Ollama、OpenAI 等提供的 API。
+
+## Aliases
+- Open WebUI
+- OpenWebUI
+- open-webui
+
+## Key Facts
+- **Docker 镜像**: ghcr.io/open-webui/open-webui:main
+- **默认端口**: 8080
+- **核心功能**: 聊天机器人、本地知识库（RAG）、图像生成、联网搜索
+
+## Core Features
+1. **多模型支持**: 通过 Ollama API 或 OpenAI API 接入多种 LLM
+2. **RAG 本地知识库**: 使用嵌入模型（如 bge-m3）构建本地知识库
+3. **联网搜索**: 支持 Bing、博查等搜索引擎接入
+4. **图像生成**: 集成图像生成能力
+5. **跨域访问**: 通过 `CORS_ALLOW_ORIGIN=*` 支持跨域 API 调用
+
+## Docker Compose 部署示例
+```yaml
+services:
+  open-webui:
+    image: ghcr.io/open-webui/open-webui:main
+    environment:
+      - OLLAMA_API_BASE_URL=http://ollama:11434/api
+      - WEBUI_NAME="My LLM Service"
+      - ENABLE_OPENAI_API=false
+      - CORS_ALLOW_ORIGIN=*
+      - ENABLE_IMAGE_GENERATION=true
+      - DEFAULT_MODELS=deepseek-r1:8b
+      - RAG_EMBEDDING_MODEL=bge-m3
+    ports:
+      - 8080:8080
+    volumes:
+      - ./open_webui_data:/app/backend/data
+```
+
+## 前提条件
+- 已安装 Docker
+- 已部署 Ollama 并拉取模型（deepseek-r1:8b 和 bge-m3）
+
+## 联网搜索配置
+操作路径：`设置 → 联网搜索 → 启用联网搜索`
+支持的搜索引擎：
+- Bing
+- 博查（https://aq6ky2b8nql.feishu.cn/wiki/XgeXwsn7oiDEC0kH6O3cUKtknSR）
+
+**注意**：如不需要联网搜索功能，请勿开启以保护隐私数据。
+
+## Related Entities
+- [[Ollama]]：Open WebUI 通过 Ollama API 接入 LLM 服务
+- [[DeepSeek]]：Open WebUI 的推荐默认模型之一
+- [[RAG]]：Open WebUI 使用 RAG 技术构建本地知识库
+
+## Connection to Hermes Agent
+Open WebUI 可以作为 Hermes Agent 的 Web 前端，通过 API Server 接入。配置方法见 [[open-webui-hermes-agent]]。
+
+核心步骤：
+1. 启用 Hermes Agent API Server：`API_SERVER_ENABLED=true`，`API_SERVER_KEY=your-secret-key`
+2. Docker 启动 Open WebUI，配置 `OPENAI_API_BASE_URL=http://host.docker.internal:8642/v1`
+3. 在 Open WebUI Admin Settings → Connections → OpenAI API 添加连接
+
+## Sources
+- [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]]
+- [[open-webui-hermes-agent]]
diff --git a/wiki/entities/OpenClaw.md b/wiki/entities/OpenClaw.md
index 779e0e93..3fe20d28 100644
--- a/wiki/entities/OpenClaw.md
+++ b/wiki/entities/OpenClaw.md
@@ -2,31 +2,24 @@
 title: "OpenClaw"
 type: entity
 tags: []
-sources:
-  - "[[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]"
-  - "[[obsidian-官方-cli-命令全景速查表]]"
-last_updated: 2026-04-10
 ---
 
-## 基本信息
-- **类型**: AI Agent 框架 / 产品
-- **官网**: https://openclaw.ai
-- **作者/公司**: OpenClawAI
+## Overview
+OpenClaw 是一个本地运行的 AI Agent 系统，提供 Gateway 服务，可通过 `model` 字段指定不同的 Agent ID（如 `openclaw:main`、`openclaw:beta`）。
 
-## 描述
-多 Agent 协同管理框架，支持通过 cron 任务系统实现定时复盘，支持 Telegram/Discord 等多平台通知。运行于 Mac Mini 作为中央控制节点，管理多个 AI Agent 协同工作。
+## Key Facts
+- **默认端口**：18789
+- **Agent 指定方式**：`"model": "openclaw:<agentId>"`
+- **OpenAI 兼容端点**：Chat Completions 端点默认关闭，需在 `~/.openclaw/openclaw.json` 中手动开启
+- **网络配置**：需设置 `host: "0.0.0.0"` 以允许 Docker 容器从宿主机网络访问
 
-## 核心功能
-- 多 Agent 生命周期管理
-- cron 定时任务调度
-- Telegram/Discord 通知推送
-- 目录映射（Symbolic Link 支持）
-- skill 安装与管理（ClawHub）
-- 持久化记忆系统（短期文件 + 长期向量数据库）
+## Configuration
+Gateway 配置文件 `~/.openclaw/openclaw.json` 中的关键配置项：
+- `gateway.port`：Gateway 监听端口（默认 18789）
+- `gateway.bind`：绑定地址（`"lan"` 允许局域网访问）
+- `gateway.auth.mode`：`"token"` 模式使用 Bearer Token 认证
+- `gateway.http.endpoints.chatCompletions.enabled`：设为 `true` 开启 OpenAI 兼容端点
 
-## 相关 Entity
-- [[LanceDB]]：长期记忆向量数据库
-- [[LEARNINGS.md]]：结构化经验记录文件
-
-## Aliases
-- OpenClawAI
+## Related Pages
+- [[n8n-调用openclaw-agents的工作流架构]]
+- [[Hermes-Agent]]
diff --git a/wiki/entities/OpenWebUI.md b/wiki/entities/OpenWebUI.md
new file mode 100644
index 00000000..98cd6c52
--- /dev/null
+++ b/wiki/entities/OpenWebUI.md
@@ -0,0 +1,12 @@
+---
+title: "OpenWebUI (已合并)"
+type: entity
+tags:
+  - "open-webui"
+  - "duplicate"
+sources: []
+last_updated: 2026-05-02
+redirect_to: Open-WebUI.md
+---
+
+> ⚠️ **已合并**：此文件内容已合并至 [[Open-WebUI]]，请使用该页面。
diff --git a/wiki/entities/OpenZeppelin.md b/wiki/entities/OpenZeppelin.md
new file mode 100644
index 00000000..4b6d94e1
--- /dev/null
+++ b/wiki/entities/OpenZeppelin.md
@@ -0,0 +1,31 @@
+---
+title: "OpenZeppelin"
+type: entity
+tags: []
+last_updated: 2026-05-01
+---
+
+## Overview
+OpenZeppelin 是最广泛使用的 Solidity 安全合约库和开发框架，为以太坊/EVM 智能合约提供经过专业审计的标准实现。其合约库涵盖 Token 标准、访问控制、可升级代理、安全工具等核心模块，是 Solidity 开发的事实标准基础。
+
+## Key Components
+
+### Contracts
+- **Token 标准**：ERC-20、ERC-721（EIP-721）、ERC-1155、ERC-4907（租赁 NFT）、ERC-2981（版税）
+- **扩展**：ERC20Burnable、ERC20Pausable、ERC20Permit（EIP-712 授权）、ERC20FlashMint
+- **访问控制**：AccessControl、Ownable、RBAC（基于角色的访问控制）
+- **安全**：ReentrancyGuard、Pausable
+- **代理模式**：TransparentUpgradeableProxy、UUPSUpgradeable、ERC1967Proxy、BeaconProxy
+
+### Defender
+- 自动化智能合约运维平台
+- 包含 Admin（多签管理）、Relay（自动化交易）、Sentinel（事件监控）、Advisor（安全建议）
+
+### 重要性
+- OpenZeppelin 合约经过多次专业审计，被数千个项目使用
+- **关键警示**：使用 OpenZeppelin 不等于安全——对库的错误使用本身就是漏洞来源
+- [[blockchain-security-auditor]] 明确指出：审计中常见"看似用了 OpenZeppelin 但用法错误"的漏洞
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
+- [[blockchain-security-auditor]]
diff --git a/wiki/entities/Pandas.md b/wiki/entities/Pandas.md
new file mode 100644
index 00000000..2177580d
--- /dev/null
+++ b/wiki/entities/Pandas.md
@@ -0,0 +1,54 @@
+---
+title: "Pandas"
+type: entity
+tags: [python, data-analysis, library]
+sources: [testing-test-results-analyzer]
+last_updated: 2026-04-28
+---
+
+## Aliases
+- pandas
+- pandas DataFrame
+- pandas Series
+
+## Definition
+
+Pandas 是 Python 的核心数据分析库，提供高性能、易用的数据结构和数据分析工具，在测试结果分析中用于读取、处理和转换测试数据。
+
+## Usage in Test Analysis (from TestResultsAnalyzer)
+
+```python
+import pandas as pd
+
+# 读取测试结果数据
+self.test_results = pd.read_json(test_results_path)
+
+# 分析测试覆盖缺口
+for file_path, file_coverage in uncovered_files.items():
+    if file_coverage['lines']['pct'] < 80:
+        gap_analysis.append({
+            'file': file_path,
+            'coverage': file_coverage['lines']['pct'],
+            'risk_level': self._assess_file_risk(file_path, file_coverage)
+        })
+```
+
+## Core Data Structures
+
+- **Series**：一维标记数组，类似带索引的列。
+- **DataFrame**：二维表格数据结构，类似电子表格或 SQL 表。
+- **Panel**：三维数据结构（已弃用）。
+
+## Key Methods for Test Analysis
+
+- `read_json()` / `read_csv()`：加载测试结果数据。
+- `groupby()`：按类别（功能/性能/安全/集成）分组分析。
+- `describe()`：生成描述性统计摘要。
+- `merge()` / `join()`：跨数据源关联分析。
+
+## Connections
+
+- [[Statistical-Analysis]]：与 scipy 配合进行统计分析。
+- [[Quality-Metrics]]：Pandas 是质量指标计算的基础数据处理工具。
+- [[Test-Coverage-Analysis]]：Pandas 用于覆盖率数据处理和缺口分析。
+- [[Failure-Pattern-Analysis]]：Pandas 用于失败数据的分组和趋势分析。
diff --git a/wiki/entities/Pierre-Bourdieu.md b/wiki/entities/Pierre-Bourdieu.md
new file mode 100644
index 00000000..171d7571
--- /dev/null
+++ b/wiki/entities/Pierre-Bourdieu.md
@@ -0,0 +1,26 @@
+---
+title: "Pierre Bourdieu"
+type: entity
+tags: ["anthropologist", "sociologist", "practice-theory", "french-intellectual", "cultural-capital"]
+last_updated: 2026-04-25
+---
+
+## Overview
+法国社会学家和人类学家，实践理论（Practice Theory）的提出者。发展了文化资本（cultural capital）、惯习（habitus）、场域（field）等核心概念，连接文化实践与社会结构再生产。
+
+## Aliases
+- Bourdieu
+- P. Bourdieu
+
+## Key Contributions
+- **实践理论（Practice Theory）**：文化不是静态的符号系统，而是通过日常实践不断再生产和变革的动态过程
+- **文化资本（Cultural Capital）**：非经济形式的社会资本——知识、教养、品味、语言能力——可转化为社会优势
+- **惯习（Habitus）**：行动者在社会实践中内化的性情倾向系统——使不平等的社会结构被自然化为"品味"和"选择"
+- **场域（Field）**：相对自主的社会空间（如艺术、宗教、学术），具有自身逻辑和资本形式
+
+## Relevance to Anthropologist Agent
+Anthropologist Agent 引用 Bourdieu 的实践理论作为理论基础之一，强调文化不是设计出来的装饰品，而是通过日常实践有机演化的系统。
+
+## Connections
+- [[Practice-Theory]] ← authored_by ← [[Pierre-Bourdieu]]
+- [[Anthropologist-Agent]] ← uses_framework ← [[Pierre-Bourdieu]]
diff --git a/wiki/entities/PostgreSQL.md b/wiki/entities/PostgreSQL.md
new file mode 100644
index 00000000..34da6920
--- /dev/null
+++ b/wiki/entities/PostgreSQL.md
@@ -0,0 +1,33 @@
+---
+title: "PostgreSQL"
+type: entity
+tags: [database, postgresql, rdbms, open-source, backend]
+last_updated: 2026-05-01
+---
+
+# PostgreSQL
+
+## Overview
+
+PostgreSQL 是一个功能强大的开源关系型数据库管理系统（RDBMS），以扩展性、标准兼容性和高级特性著称，是 The Agency 工程 Agent 的首选数据库。
+
+## Key Features Relevant to Agency Agents
+
+- **EXPLAIN ANALYZE**：查询计划分析
+- **B-tree / GiST / GIN / 部分索引 / 复合索引**：多种索引策略
+- **CONCURRENTLY**：创建索引不锁表（零停机生产变更）
+- **json_agg / json_build_object**：JSON 聚合函数，支持嵌套查询
+- **BIGSERIAL**：64位自增主键类型
+- **pg_stat_statements**：慢查询监控扩展
+
+## Aliases
+- Postgres
+- PG
+
+## Source
+- [[engineering-database-optimizer]]
+
+## Connections
+- [[engineering-backend-architect]] — 后端架构师首选数据库
+- [[IndexingStrategies]] — PostgreSQL 索引类型最全面
+- [[engineering-sre]] — SRE 需掌握 pg_stat_statements 监控
diff --git a/wiki/entities/Prometheus.md b/wiki/entities/Prometheus.md
index 177db304..7c8b515f 100644
--- a/wiki/entities/Prometheus.md
+++ b/wiki/entities/Prometheus.md
@@ -1,44 +1,55 @@
----
-title: "Prometheus"
-type: entity
-tags: [monitoring, time-series, devops, observability]
-last_updated: 2026-04-26
----
-
-## Prometheus — 开源监控系统与时序数据库
-
-**官方网址：** https://prometheus.io/
-
-**类型：** 开源项目 / 监控系统
-
-**别名：**
-- prom
-- Prometheus TSDB
-
----
-
-## Overview
-
-Prometheus 是由 SoundCloud 开发的开源监控系统，现由 CNCF 托管。采用**拉取（pull）模式**从配置的 targets 收集指标，存储为时间序列数据，支持强大的 PromQL 查询语言和灵活的告警规则引擎。
-
-**核心特性：**
-- 多维数据模型（metric + labels）
-- PromQL 强大查询能力
-- 拉取模式优于推送（网络可控、无侵入）
-- HTTP API（易于集成）
-- Alertmanager 集成
-
-**典型部署端口：** `9090`（Web UI + API）
-
----
-
-## Used By
-- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
-
-## Related Sources
-- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
-- [[家庭网络环境概览_2026-04-03]]
-- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
-- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]]
-- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
-- [[public-cloud-learning-sessions-observability-with-opentelemetry]]
+---
+title: "Prometheus"
+type: entity
+tags: [Monitoring, Observability, DevOps]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
+---
+
+# Prometheus
+
+## 基本信息
+- **类型**：开源监控系统
+- **开发商**：CNCF（云原生计算基金会）
+- **官网**：https://prometheus.io
+
+## 定义
+Prometheus 是一个开源的系统监控和告警工具包，通过定期抓取（pull）指标数据，提供强大的数据模型、查询语言（PromQL）和告警管理能力。
+
+## 核心特性
+- **多维数据模型**：指标名称 + 标签集（key-value pairs）
+- **PromQL**：强大的指标查询和聚合语言
+- **主动抓取**：通过 HTTP 定期拉取指标，而非被动接收
+- **告警管理**：与 AlertManager 集成，支持分组、抑制和静默
+- **服务发现**：自动发现监控目标，支持 Kubernetes、DNS 等
+
+## 在 DevOps Automator 中的角色
+- 监控告警体系的核心组件
+- 通过告警规则（如 HighErrorRate、HighResponseTime）实现主动问题发现
+- 与 Grafana 集成提供可视化仪表板
+
+## 关键告警示例
+```yaml
+alert: HighErrorRate
+expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.1
+for: 5m
+labels:
+  severity: critical
+annotations:
+  summary: "High error rate detected"
+```
+
+## 相关概念
+- [[Observability]]
+- [[Grafana]]
+
+## 相关工具
+- AlertManager（告警处理和路由）
+- Grafana（指标可视化）
+- node-exporter（主机指标）
+- cAdvisor（容器指标）
+
+## Aliases
+- Prometheus
+- Prometheus Monitor
+- Prometheus Monitoring
diff --git a/wiki/entities/PsychologistAgent.md b/wiki/entities/PsychologistAgent.md
new file mode 100644
index 00000000..6e4d746a
--- /dev/null
+++ b/wiki/entities/PsychologistAgent.md
@@ -0,0 +1,33 @@
+---
+title: "Psychologist Agent"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+# Psychologist Agent
+
+## Aliases
+- Academic Psychologist
+
+## Description
+Psychologist Agent — clinical and research psychologist specializing in personality, motivation, trauma, and group dynamics. Provides psychologically credible character frameworks for AI agents engaged in character-driven creative work.
+
+## Role in The Agency
+- Specializes in personality assessment, attachment theory, defense mechanisms, and interpersonal dynamics
+- Part of the [[Academic-Psychologist]] source
+- Managed by [[AgentsOrchestrator]]
+- Informs [[NarrativeDesigner]] with psychologically grounded character analysis
+
+## Key Frameworks
+- Big Five personality model
+- Bowlby Attachment Theory
+- Vaillant Defense Mechanism Hierarchy
+- Karpman Drama Triangle
+- CBT Cognitive Distortions (Beck)
+- Erikson Psychosocial Development Stages
+- Porges Polyvagal Theory
+
+## Connection to Wiki
+- Source: [[academic-psychologist]]
diff --git a/wiki/entities/QiChaCha.md b/wiki/entities/QiChaCha.md
new file mode 100644
index 00000000..23815741
--- /dev/null
+++ b/wiki/entities/QiChaCha.md
@@ -0,0 +1,37 @@
+---
+title: "QiChaCha (企查查)"
+type: entity
+tags: ["china", "enterprise-information", "procurement", "supplier-verification"]
+last_updated: 2026-04-25
+---
+
+## Aliases
+- 企查查
+
+## Definition
+
+企查查是中国领先的企业信息查询平台，提供企业工商信息、股东信息、法律诉讼、行政处罚、经营状况等多维度企业信用信息查询服务。在供应链管理中，用于供应商资质验证和风险评估。
+
+## Key Features
+- **工商信息查询**：注册资本、注册地址、经营范围、成立时间
+- **股东穿透**：股权结构、实际控制人识别
+- **法律风险**：开庭公告、被执行人、失信被执行人
+- **经营状态**：存续、在业、注销、吊销
+- **融资历史**：对外投资、关联公司
+
+## Application in Supply Chain
+
+[[Supply Chain Strategist Agent]] 在供应商开发流程中使用企查查进行资质验证：
+
+1. **供应商初筛**：通过工商信息核实公司真实性，识别空壳公司
+2. **股东穿透**：识别实际控制人，评估关联交易风险
+3. **风险筛查**：查询法律诉讼和失信记录，评估供应商合规性
+4. **关联分析**：识别同一实际控制人下的多个供应商，评估集中度风险
+
+## Alternatives
+- [[Tianyancha]]（天眼查）：另一主流企业信息平台，功能相似
+- 企查查与天眼查为国内最主要的两大企业信息查询平台
+
+## Connections
+- [[Supply Chain Strategist Agent]] ← uses_tool ← [[QiChaCha]]
+- [[Tianyancha]] ← similar_to ← [[QiChaCha]]
diff --git a/wiki/entities/Richard-Cook.md b/wiki/entities/Richard-Cook.md
new file mode 100644
index 00000000..edd72fc6
--- /dev/null
+++ b/wiki/entities/Richard-Cook.md
@@ -0,0 +1,35 @@
+---
+title: "Richard Cook"
+type: entity
+tags: [sre, reliability, research, resilience]
+last_updated: 2026-04-20
+---
+
+# Richard Cook
+
+Dr. Richard I. Cook 是系统韧性和可靠性工程领域的知名研究者，Adaptive Capacity Labs 联合创始人。
+
+## Aliases
+- Richard Cook
+- Dr. Richard Cook
+- Richard I. Cook
+
+## Overview
+医学背景出身的 Richard Cook 专注于复杂系统中的人类因素和系统故障研究。他与 John Allspaw 合作的多部著作（如《Working Together》）对 SRE 领域影响深远。
+
+## Key Contributions
+- **Organizational Second Hit Syndrome**：提出组织层面的二次冲击综合征概念（首次发表于 2026 年 3 月 7 日）
+- **Resilience Engineering Theory**：推动系统韧性作为理解和设计复杂 socio-technical 系统的核心框架
+- **How Complex Systems Fail**：经典论文，阐述复杂系统的故障模式
+
+## Notable Works
+- 《Working Together》— 与 John Allspaw 合著
+- "Organizational Second Hit Syndrome" — 2026 年 3 月首次发表
+- "How Complex Systems Fail"
+
+## Affiliations
+- [[Adaptive-Capacity-Labs]] — 联合创始人
+- Resilience Engineering Association
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/entities/Richard-Feynman.md b/wiki/entities/Richard-Feynman.md
new file mode 100644
index 00000000..4c610bbc
--- /dev/null
+++ b/wiki/entities/Richard-Feynman.md
@@ -0,0 +1,27 @@
+---
+title: "Richard Feynman"
+type: entity
+tags: [physics, learning, nobel-laureate]
+sources: [zk-steward]
+last_updated: 2026-05-30
+---
+
+## Aliases
+- Feynman
+- Richard P. Feynman
+
+## Overview
+Richard Feynman（1918–1988）是美国理论物理学家、诺贝尔物理学奖得主（1965），以量子电动力学（QED）贡献闻名，同时也是极具影响力的科学传播者。他的学习方法论——"first principles, teach to learn"——深刻影响了知识管理和 AI prompting 领域。
+
+## Core Method
+- **First Principles Thinking**：从最基本的公理出发推导结论，不依赖类比或既有框架
+- **Teach to Learn**：如果你不能向一个初学者解释清楚某件事，你其实并不理解它（Feynman Technique）
+- **Curiosity-Driven**：对任何问题都保持"what do you really mean by that?"的追问习惯
+
+## Role in ZK Steward
+ZK Steward 在"学习 / 研究"任务中切换到 Feynman 视角，驱动 deep-learning 流程中的 Feynman 测试（能否用一句话向初学者解释清楚）。
+
+## Key Connections
+- [[ZK-Steward-Agent]] ← uses Feynman perspective for learning/research tasks
+- [[Domain-Thinking]] ← Feynman is the reference expert for learning/research domain
+- [[Luhmann-四原则]] ← Feynman Technique 与"可独立理解"原则高度共鸣
diff --git a/wiki/entities/RobertMcKee.md b/wiki/entities/RobertMcKee.md
new file mode 100644
index 00000000..c1b3a0e5
--- /dev/null
+++ b/wiki/entities/RobertMcKee.md
@@ -0,0 +1,26 @@
+---
+title: "Robert McKee"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Robert McKee
+- McKee
+
+## Overview
+Robert McKee 是当代最具影响力的剧本写作与叙事理论导师之一，以其著作《故事》（Story, 1997）闻名。他的"Controlling Idea"框架是现代商业叙事（电影、电视、小说）分析的核心工具。
+
+## Key Contributions
+- **Controlling Idea**：故事对人性的论点（thesis），贯穿于所有情节选择中。有效的 Controlling Idea = 主题性价值 × 因果关系
+- **三幕式结构的深层逻辑**：_setup、confrontation、resolution 各有其戏剧性功能，而非人为划分
+- **场景分析的 ICE 方法**：Inciting Incident / Crucial Event / Crisis
+- 全球开设"McKee Story"培训课程，好莱坞顶级编剧几乎均受其影响
+
+## In The Agency Context
+[[Academic Narratologist]] 的核心框架之一。Controlling Idea 是评估故事"真正在说什么"的核心抽象层。
+
+## References
+- Story: Substance, Structure, Style and the Principles of Screenwriting (1997)
diff --git a/wiki/entities/RolandBarthes.md b/wiki/entities/RolandBarthes.md
new file mode 100644
index 00000000..676b0818
--- /dev/null
+++ b/wiki/entities/RolandBarthes.md
@@ -0,0 +1,30 @@
+---
+title: "Roland Barthes"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- Roland Barthes
+- Barthes
+
+## Overview
+Roland Barthes (1915–1980) 是法国文学批评家、哲学家、结构主义和后结构主义思潮的关键人物。其著作《S/Z》（1970）提出了叙事意义分析的 **Barthes' Five Codes** 框架。
+
+## Key Contributions
+- **Five Codes（五大代码）**：
+  1. **The Hermeneutic Code**：谜题与悬念代码（What will happen?）
+  2. **The Proairetic Code**：行动代码（What will the characters do next?）
+  3. **The Semantic Code**：语义代码（What does this mean symbolically?）
+  4. **The Symbolic Code**：象征代码（recurring binary oppositions）
+  5. **The Cultural Code**：文化代码（reference to shared cultural knowledge）
+- 通过逐一标记文本中的代码节点，解构叙事的意义生产机制
+
+## In The Agency Context
+[[Academic Narratologist]] 使用 Five Codes 进行叙事意义的半符号学分析，是深层次文本批评工具。
+
+## References
+- S/Z (1970)
+- Mythologies (1957)
diff --git a/wiki/entities/RunLLM.md b/wiki/entities/RunLLM.md
new file mode 100644
index 00000000..420e9dba
--- /dev/null
+++ b/wiki/entities/RunLLM.md
@@ -0,0 +1,29 @@
+---
+title: "RunLLM"
+type: entity
+tags: [sre, ai, on-call, tooling]
+last_updated: 2026-04-20
+---
+
+# RunLLM
+
+RunLLM 是一个专注于 AI 辅助 SRE 和值班运维的产品公司。
+
+## Overview
+RunLLM 的核心产品聚焦于**值班（On-Call）场景下的 AI 辅助**。公司创始人 Heinrich Hartmann 提出：AI 在 SRE 中最有价值的作用不是自主修复，而是确保值班工程师有足够的上下文来快速修复故障。
+
+## Key Product Focus
+- **On-Call Context Augmentation**：通过 AI 为值班工程师提供故障相关的上下文信息
+- **Incident Response Acceleration**：加速故障诊断和修复过程
+- **Knowledge Retrieval**：从大量运维文档、故障报告、历史事件中提取相关信息
+
+## Key Insight
+> "AI's most valuable role in SRE isn't autonomous remediation. It's making sure on-call engineers have the context to fix incidents fast." — Heinrich Hartmann
+
+## Related Concepts
+- [[AI-For-On-Call]]
+- [[Incident-Response]]
+- [[Observability]]
+
+## Source
+- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
diff --git a/wiki/entities/SME.md b/wiki/entities/SME.md
new file mode 100644
index 00000000..37207b4a
--- /dev/null
+++ b/wiki/entities/SME.md
@@ -0,0 +1,57 @@
+---
+title: "SME"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-05-30
+---
+
+## 基本信息
+- **原文**：중소기업（SME）
+- **类型**：公司类型 / 中小企业
+- **英文**：Small and Medium Enterprise
+- **中文**：中小企业
+
+## 定义
+SME（中小企业）在韩国经济中占企业总数的 99% 以上，雇用约 80% 的劳动力。与财阀相比，SME 决策链更短，품의流程耗时最短（6-10 周），是外国独立顾问最容易进入的市场。
+
+## 特征
+- **决策链短**：部门长或代表理事直接决策，无需多层级审批
+- **品의耗时**：6-10 周，相对可预测
+- **跟进频率**：建议每周一次，保持存在感
+- **灵活性高**：合同条款沟通相对直接，决策较快
+
+## 품의 流程特点
+| 阶段 | 特点 |
+|------|------|
+| 결재라인 | 通常 2-3 级 |
+| 时间线 | 6-10 周 |
+| 联系人决策权 | 较高，可直接影响结果 |
+| 预算确认 | 相对灵活，可能临时追加 |
+
+## SME vs 财阀对比
+
+| 维度 | SME | 财阀（Chaebol） |
+|------|-----|----------------|
+| 품의耗时 | 6-10 周 | 12-16 周 |
+| 审批链 | 2-3 级 | 5-7 级 |
+| 跟进频率 | 每周 | 每月 |
+| 决策者接触难度 | 低 | 高 |
+| 外国供应商接受度 | 中等 | 低 |
+| 合同灵活性 | 高 | 低 |
+| 品牌要求 | 较低 | 高 |
+
+## 市场进入策略
+1. **通过行业组织接入**：大韩商会（KCCI）、各行业协会
+2. **证明项目（Proof Project）最佳市场**：SME 更愿意用小项目试用
+3. **行业协会活动**：参加 B2B 展会和商业论坛
+4. **数字化渠道**：越来越多的 SME 通过 LinkedIn 和 KakaoTalk 主动搜索供应商
+
+## Aliases
+- 중소기업
+- 中小企业
+- 韩国中小企业
+- SME Korea
+
+## 来源
+- [[specialized-korean-business-navigator]] — 품의 Approval Process Timeline 中 SME 的品의时间线和跟进建议
diff --git a/wiki/entities/SSE.md b/wiki/entities/SSE.md
index c7c0e63b..82a07441 100644
--- a/wiki/entities/SSE.md
+++ b/wiki/entities/SSE.md
@@ -1,45 +1,37 @@
 ---
 title: "SSE (Server-Sent Events)"
 type: entity
-tags: [web, real-time, http, mcp]
-sources: [mcp在cursor中的集成与应用详解]
-last_updated: 2026-04-26
+tags: [web, real-time, http]
+sources: [mcp在cursor中的集成与应用详解, expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
+last_updated: 2026-05-02
 ---
 
-## Definition
+## Overview
 SSE（Server-Sent Events，服务器推送事件）是一种基于 HTTP 的**服务器向客户端推送实时事件**的技术，允许服务器主动向浏览器或客户端应用发送数据更新。
 
-## In MCP Context
-在 MCP（Modal Context Protocol）集成中，SSE 是两种接入方式之一：
-- **SSE 方式**：通过 HTTP SSE 连接远程 MCP Server
-- **Command 方式**：通过本地执行命令连接 MCP Server
-
-SSE 方式适用于：
-- 部署在远程服务器上的 MCP Server
-- 需要集中管理多个 MCP Server 的场景
-- 服务端支持 SSE 协议输出的 MCP Server
-
 ## Key Characteristics
-- **单向通信**：仅服务器向客户端推送，客户端不能反向通信（需用 HTTP 请求）
+- **单向通信**：仅服务器向客户端推送，客户端不能反向通信
 - **基于 HTTP**：使用标准 HTTP 协议，易于穿过防火墙
 - **自动重连**：浏览器端 SSE API 自动处理连接断开重连
 - **文本协议**：使用文本格式传输数据（通常为 JSON）
 
+## Usage in Hermes Agent
+`/v1/runs` API 通过 SSE 实现长会话实时进度订阅：
+- **Token 流**：逐 token 推送响应内容
+- **工具进度**：自定义事件推送工具执行状态
+- **实时反馈**：用户可看到 Agent 思考和工具调用的全过程
+
 ## Comparison
 
 | 特性 | SSE | WebSocket |
-|------|-----|----------|
+|------|-----|-----------|
 | 通信方向 | 单向（服务端→客户端） | 双向 |
 | 协议 | HTTP | 独立协议 |
 | 复杂度 | 简单 | 较复杂 |
 | HTTP/2 多路复用 | 支持 | 支持 |
 | 防火墙穿透 | 易 | 需特殊配置 |
 
-## Connections
-- [[McpServer]] ← SSE 协议是 MCP Server 的一种接入方式
-- [[ModalContextProtocol]] ← 所属协议生态
-- [[Mcp在Cursor中的集成与应用详解]] ← 使用场景
-
-## See Also
-- [[ModalContextProtocol]]
-- [[McpServer]]
+## Related Pages
+- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
+- [[ToolStreaming]]
+- [[ResponsesAPI]]
diff --git a/wiki/entities/Salesforce.md b/wiki/entities/Salesforce.md
new file mode 100644
index 00000000..2db1941f
--- /dev/null
+++ b/wiki/entities/Salesforce.md
@@ -0,0 +1,57 @@
+---
+title: "Salesforce"
+type: entity
+tags: []
+sources: [specialized-french-consulting-market]
+last_updated: 2026-04-25
+---
+
+# Salesforce
+
+## Aliases
+- Salesforce
+- SFDC
+- Salesforce CRM
+- Salesforce Platform
+
+## Definition
+
+Salesforce 是全球领先的 SaaS CRM（客户关系管理）平台，总部位于美国旧金山。作为法国 IT 咨询市场中最具商业价值的技术栈之一，Salesforce 认证架构师和数据专家在法国 ESN/SI 生态系统中享有显著的市场溢价。
+
+## Market Position in French Consulting
+
+在法国 ESN/SI 市场中，Salesforce 专家是高价细分领域的代表：
+
+| 细分方向 | TJM 区间 | 供需特点 |
+|---------|---------|---------|
+| 通用 Salesforce Admin | 500-600 EUR/天 | 供给充足，价格趋于下行 |
+| Salesforce Architect | 650-800 EUR/天 | 需架构经验，溢价明显 |
+| Data Cloud + Agentforce | 700-850 EUR/天 | 稀缺高端组合，当前最高溢价 |
+| Salesforce + SAP Integration | 700-900 EUR/天 | 跨系统集成专家，极其稀缺 |
+
+> "Generic 'Salesforce Architect' = commodity (550-650)" vs "Data Cloud + Agentforce Specialist = premium (700-850)" — French Consulting Market Navigator
+
+## Agentforce
+
+Agentforce 是 Salesforce 在 2024-2025 年推出的 AI Agent 产品线，代表了 CRM 领域的下一代智能自动化能力：
+
+- **Agentforce Studio**：可视化构建 AI Agent 的低代码平台
+- **预构建 Agent**：服务、Sales、Marketing 等开箱即用场景
+- **Data Cloud 集成**：所有 Agentforce Agent 共享统一数据模型
+
+Agentforce + Data Cloud 的组合是目前法国市场最高溢价的 Salesforce 细分方向之一，支撑 700-850 EUR/天的 TJM 定位。
+
+## French Market Specifics
+
+### 认证体系
+- Salesforce 认证（Administrator/Developer/Architect 各级别）在法国咨询市场被高度认可
+- Data Cloud 认证是当前最热门的专项认证方向
+- Einstein 1 系列认证覆盖 AI 功能
+
+### 法国 ESN 生态
+- Tier 2 精品 ESN（如 Cloudity）是 Salesforce 项目的最主要发包方
+- Salesforce 项目以 Salesforce 生态本身为主，但也涉及跨系统集成（SAP、Workday、ServiceNow）
+- 法国市场对 Salesforce Security Model 和 Sharing Architecture 的理解深度是高级顾问的核心差异点
+
+## Related Sources
+- [[specialized-french-consulting-market]]
diff --git a/wiki/entities/Shopify.md b/wiki/entities/Shopify.md
new file mode 100644
index 00000000..c7f46e11
--- /dev/null
+++ b/wiki/entities/Shopify.md
@@ -0,0 +1,48 @@
+---
+title: "Shopify"
+type: entity
+tags:
+  - ecommerce
+  - dtoc
+  - platform
+  - website
+  - cross-border
+sources:
+  - marketing-cross-border-ecommerce
+last_updated: 2026-04-26
+---
+
+## Aliases
+- DTC
+- Direct-to-Consumer
+- 独立站
+- Shopify 独立站
+
+## Definition
+
+Shopify 是全球最大的 SaaS 电商建站平台，支持品牌搭建 DTC（Direct-to-Consumer）独立站，是跨境电商品牌全球化的重要渠道。与平台电商（Amazon/Temu/TikTok Shop）不同，独立站让品牌拥有完整的用户数据、定价自主权和品牌叙事空间。
+
+## Core Capabilities
+- **Store Building**：拖拽式主题设计，支持深度定制（Liquid 模板语言）
+- **Payment Gateways**：Stripe/PayPal/Shop Pay 等多支付方式集成，支持 170+ 种货币
+- **Logistics Integration**：与 FBA、第三方海外仓、DHL/USPS 等物流商深度集成
+- **App Ecosystem**：App Store 收录 8000+ 应用，覆盖从 SEO 到库存管理全场景
+- **International Selling**：多语言、多货币本地化销售，支持按国家/地区展示不同内容
+- **Shopify Markets**：集中管理多国家/地区销售、关税计算和合规申报
+
+## Key Considerations for Cross-Border
+- 不依赖平台流量——需主动获取流量（SEO/社交媒体/付费广告）
+- 用户数据归品牌所有，可用于精细化再营销
+- 建站+推广启动成本高于平台电商，但长期品牌价值更大
+- 适合有差异化品牌定位和内容营销能力的卖家
+
+## Usage in Cross-Border Context
+- 品牌官网 + Amazon/TikTok Shop 多渠道并行
+- 通过 Klaviyo/Mailchimp 实现邮件自动化（弃购挽回、复购激活）
+- 通过 Instagram/TikTok/YouTube/Pinterest 引流至独立站
+- 独立站 SEO（技术 SEO + 内容营销 + 外链建设）是长期流量护城河
+
+## Connections
+- [[Klaviyo]] ← email_automation ← [[Shopify]]
+- [[Marketing Cross-Border E-Commerce Specialist]] ← uses ← [[Shopify]]
+- [[DTC]] ← related_to ← [[Shopify]]
diff --git a/wiki/entities/Snowflake.md b/wiki/entities/Snowflake.md
new file mode 100644
index 00000000..36bd5247
--- /dev/null
+++ b/wiki/entities/Snowflake.md
@@ -0,0 +1,41 @@
+---
+title: "Snowflake"
+type: entity
+tags: [data-engineering, cloud-data-warehouse, lakehouse, SaaS]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Overview
+
+Snowflake 是云原生数据仓库和数据湖平台，支持多集群共享数据架构，提供独立扩展存储和计算的能力。Data Engineer Agent 将 Snowflake 作为 Medallion Architecture Gold 层的重要消费平台。
+
+## Key Features
+
+### Dynamic Tables
+- 声明式管道：定义目标状态，Snowflake 自动计算增量更新
+- 无需管理 `MERGE INTO` 或调度逻辑——Snowflake 处理增量计算
+- 类似于 dbt 的 incremental models，但由平台原生支持
+
+### Snowpark
+- 在 Snowflake 内运行 Python、Scala、Java 代码
+- 支持自定义函数（UDFs）和存储过程
+- 将数据处理逻辑下沉到 Snowflake 内部，减少数据传输
+
+### Data Sharing
+- Secure Data Sharing：跨账户即时共享数据，无需复制
+- Provider 和 Consumer 账户独立计费
+
+### Cost Optimization
+- 每一列自动压缩存储
+- 按查询计费的 Serverless SQL（无需预留容量）
+- Virtual Warehouse 独立扩缩容
+
+## Snowflake Connectors
+- **Snowflake Connector for Spark**：Spark DataFrame ↔ Snowflake 互操作
+- **Snowflake Connector for Kafka**：Kafka → Snowflake 实时摄取
+- **Native Ingest**：Python/Go/Java SDK 直接摄取
+
+## Related Concepts
+- [[Medallion Architecture]]（Snowflake 可作为 Gold 层）
+- [[dbt]]（dbt Snowflake adapter 广泛使用）
diff --git a/wiki/entities/Supply-Chain-Strategist.md b/wiki/entities/Supply-Chain-Strategist.md
new file mode 100644
index 00000000..fdaa4232
--- /dev/null
+++ b/wiki/entities/Supply-Chain-Strategist.md
@@ -0,0 +1,53 @@
+---
+title: "Supply Chain Strategist Agent"
+type: entity
+tags: ["agent", "supply-chain", "procurement", "manufacturing", "china", "the-agency"]
+last_updated: 2026-04-25
+---
+
+## Aliases
+- SupplyChainStrategist
+
+## Definition
+
+Supply Chain Strategist Agent 是 The Agency Specialized 部门的供应链管理专家智能体，专注于中国制造业生态的端到端供应链优化。帮助企业降低采购成本、提升供应链韧性，通过供应商管理、战略采购、质量控制、库存优化和供应链数字化实现采购引擎与供应链韧性的构建。
+
+## Core Capabilities
+- **供应商开发与分级管理**：ABC 分类 + QCD 绩效考核（Quality 质量、Cost 成本、Delivery 交付）
+- **战略采购**：Kraljic 矩阵分类 + TCO 全成本分析
+- **质量控制**：IQC/IPQC/OQC + AQL 抽样检验 + 8D Report + CAPA
+- **库存优化**：EOQ + 安全库存 + 再订货点模型
+- **物流仓储**：国内快递/零担/整车 + WMS 系统
+- **供应链数字化**：ERP/SRM 系统选型 + 数字化成熟度评估（L1 手动 → L5 自主智能）
+- **成本控制**：TCO 短期/中期/长期降本策略
+- **风险管理**：多源采购策略 + 国产替代（国产替代）
+
+## Procurement Channel Expertise
+- **线上平台**：1688/Alibaba（标准件）、Made-in-China.com（出口导向）、Global Sources（高端制造）、京东工业品/震坤行（MRO）
+- **数字化采购平台**：甄云（甄云科技）、企企通（SMEs）、用友采购云、SAP Ariba
+- **线下渠道**：广交会（春秋两届）、深圳电子展/上海工博会（行业展会）、义乌/温州/东莞（产业集群）
+- **企业信息验证**：企查查（企查查）、天眼查（天眼查）
+
+## ERP Systems
+- **SAP**：大型集团/外资企业，MM/PP/SD/WM 模块，实施周期 6-18 个月
+- **用友 U8+ / YonBIP**：中大型民营企业，本地化强、税务集成好
+- **金蝶云星空/星瀚**：成长期中型企业，SaaS 部署快、移动端体验好
+
+## Key Principles
+- **供应链安全优先**：关键物料不得单一来源，必须开发备选供应商
+- **数据驱动**：TCO 是决策依据，而非单价；供应商绩效评估中主观评价不超过 20%
+- **TCO 思维**：综合考虑直接成本、间接成本和隐性成本，以全生命周期成本作为采购决策依据
+- **合规与伦理采购**：商业贿赂零容忍，招投标必须公平公正
+
+## Success Metrics
+- 年度采购成本降低 5-8% 而不影响质量
+- 供应商准时交付率 95%+，来料质量合格率 99%+
+- 库存周转天数持续改善，呆料低于 3%
+- 供应链中断响应时间 < 24 小时，零重大断货事故
+- 供应商绩效评估覆盖率 100%，季度改善闭环率 100%
+
+## Connections
+- [[Kraljic Matrix]] ← framework ← [[Supply Chain Strategist Agent]]
+- [[TCO]] ← concept ← [[Supply Chain Strategist Agent]]
+- [[QiChaCha]] ← used_by ← [[Supply Chain Strategist Agent]]
+- [[Tianyancha]] ← used_by ← [[Supply Chain Strategist Agent]]
diff --git a/wiki/entities/Terraform.md b/wiki/entities/Terraform.md
index 70561e86..a815cf84 100644
--- a/wiki/entities/Terraform.md
+++ b/wiki/entities/Terraform.md
@@ -1,149 +1,44 @@
----
-title: "Terraform"
-type: entity
-tags:
-  - devops
-  - iac
-  - infrastructure
-  - automation
-created: 2026-04-25
----
-
-# Terraform
-
-## Definition
-
-Terraform 是 HashiCorp 开源的**基础设施即代码 (IaC)** 工具，通过声明式配置文件管理云资源。Agentic AI 代理审查 Terraform 脚本，在执行前建议改进，确保基础设施配置的可靠性和安全性。
-
-## Aliases
-
-- Terraform
-- Terraform IaC
-- Infrastructure as Code
-
-## Relationship with [[Infrastructure-as-Code]]
-
-Terraform 是 [[Infrastructure-as-Code]] 实践的主要实现工具之一：
-
-```
-Infrastructure as Code Tools:
-├── Terraform ←
-├── CloudFormation (AWS)
-├── Pulumi
-├── Ansible
-└── Pulumi
-```
-
-## Agentic AI IaC Management
-
-Agentic AI 在 Terraform 工作流中扮演审查者角色：
-
-```
-┌─────────────────────────────────────────────────┐
-│        Agentic AI IaC Management Workflow        │
-├─────────────────────────────────────────────────┤
-│                                                  │
-│  1. Developer writes Terraform                   │
-│     ↓                                           │
-│  2. Agentic AI reviews (auto)                   │
-│     ├── Security scan (IAM policies)            │
-│     ├── Cost estimation                         │
-│     ├── Best practices check                    │
-│     └── Compliance validation                   │
-│     ↓                                           │
-│  3. AI Suggestions                              │
-│     ├── "S3 bucket should enable encryption"   │
-│     ├── "Remove hardcoded credentials"         │
-│     └── "Consider using modules for reuse"     │
-│     ↓                                           │
-│  4. Apply (after approval)                      │
-│                                                  │
-└─────────────────────────────────────────────────┘
-```
-
-## AI Review Capabilities
-
-| Check Type | Description |
-|------------|-------------|
-| **Security** | IAM 过度权限、公开 S3 访问、硬编码密钥 |
-| **Cost** | 资源过度配置、未使用资源识别 |
-| **Compliance** | 标签规范、资源命名、区域限制 |
-| **Best Practices** | 模块化、状态管理、回滚计划 |
-
-## Example
-
-> Agentic AI reviews Terraform plan:
-> ```hcl
-> resource "aws_s3_bucket" "data" {
->   bucket = "my-sensitive-data"
-> }
-> ```
-> 
-> AI Detection:
-> - ⚠️ **Security Risk**: Bucket is public by default
-> - ⚠️ **Missing**: Encryption not enabled
-> - ⚠️ **Missing**: Versioning not enabled
-> 
-> AI Suggestions:
-> ```hcl
-> resource "aws_s3_bucket" "data" {
->   bucket = "my-sensitive-data"
->   
->   server_side_encryption_configuration {
->     rule {
->       apply_server_side_encryption_by_default {
->         sse_algorithm = "AES256"
->       }
->     }
->   }
-> }
-> 
-> versioning { enabled = true }
-> acl = "private"  # Block public access
-> ```
-
-## State File Management
-
-Terraform 通过**状态文件 (state file)** 将声明式配置中定义的**期望状态**与云环境的**实际资源状态**进行绑定。关键特性：
-- **状态锁定**：防止并发执行导致状态不一致
-- **远程状态**：企业级场景需将状态文件存储在 S3（+ DynamoDB 锁）等远程后端，支持团队协作
-- **差异对比**：`terraform plan` 预览实际变更内容再执行，是 Terraform 的核心优势
-
-**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
-
-## Terragrunt Wrapper
-
-Terragrunt 是 Terraform 的轻量封装，继承所有 Terraform 命令（HCL 语法完全兼容）。两者关系：
-- `terragrunt plan` = `terraform plan`
-- Terragrunt 通过 `remote_state` 和 `include` 块实现跨环境配置的 DRY 管理
-
-**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
-
-## Ecosystem Tools
-
-| 工具 | 类型 | 用途 |
-|------|------|------|
-| [[Terragrunt]] | 封装 | 多环境 DRY 配置 |
-| [[Atlantis]] | CI/CD | Git PR 驱动的 plan/apply |
-| Terraform Enterprise | 平台 | 企业 CI + workspaces |
-| [[Gruntwork]] | 模块库 | 预建可复用 IaC 模块 |
-| Terratest | 测试 | IaC 集成测试（Golang） |
-| tfsec | 安全 | Terraform 静态安全分析 |
-
-**来源**: [[ctp-topic-48-terraform-vs-terragrunt]], [[ctp-topic-56-automated-infrastructure-testing]]
-
-## Related Concepts
-
-- [[Infrastructure-as-Code]] — Terraform 是 IaC 的实现工具
-- [[Automated Security Audit]] — AI 审查 Terraform 安全
-- [[Cloud-Native]] — IaC 支持 Cloud-Native 实践
-- [[Multi-Account Deployment]] — Terraform HCP/Cloud 多账户部署与 CloudFormation StackSets 对比
-- [[AWS CloudFormation StackSets]] — AWS 原生多账户 IaC 部署工具，与 Terraform 有功能重叠
-
-## Related Entities
-
-- [[AWS CloudFormation StackSets]]：AWS 原生多账户部署服务，与 Terraform 在多账户 IaC 场景形成对比
-
-## Related Sources
-
-- [[how-agentic-ai-can-help-for-cloud-devops]]
+---
+title: "Terraform"
+type: entity
+tags: [Infrastructure, Cloud, DevOps]
+sources: [engineering-devops-automator]
+last_updated: 2026-05-01
+---
+
+# Terraform
+
+## 基本信息
+- **类型**：工具 / 基础设施即代码平台
+- **开发商**：HashiCorp
+- **官网**：https://www.terraform.io
+
+## 定义
+Terraform 是一种声明式基础设施即代码（Infrastructure as Code）工具，通过 HCL（HashiCorp Configuration Language）语言描述云资源，实现跨多云（AWS/GCP/Azure）的自动化基础设施管理。
+
+## 核心特性
+- **声明式配置**：描述期望的最终状态，而非操作步骤
+- **执行计划**：在应用前预览变更内容
+- **资源图谱**：构建所有资源的依赖关系图
+- **状态管理**：跟踪已创建资源与实际基础设施的差异
+- **多云支持**：统一管理 AWS/GCP/Azure 等多个云平台
+
+## 在 DevOps Automator 中的角色
+- 基础设施生命周期管理的核心工具
+- 用于定义 AWS uto-scaling groups、ALB、CloudWatch alarms 等
+- 通过 `terraform plan` 预览变更，通过 `terraform apply` 自动部署
+
+## 相关概念
+- [[Infrastructure as Code]]
+- [[CI/CD Pipeline]]
+- [[Kubernetes]]
+
+## 相关工具
+- Terragrunt（Terraform 包装器，支持远程状态和模块复用）
+- Atlantis（Terraform CI/CD 自动化工具）
+- tfsec（Terraform 安全扫描）
+
+## Aliases
+- Terraform
+- Terraform IaC
+- HashiCorp Terraform
diff --git a/wiki/entities/Terragrunt.md b/wiki/entities/Terragrunt.md
index 49bf6807..2db5daac 100644
--- a/wiki/entities/Terragrunt.md
+++ b/wiki/entities/Terragrunt.md
@@ -1,100 +1,101 @@
----
-title: "Terragrunt"
-type: entity
-tags:
-  - devops
-  - iac
-  - terraform
-  - automation
-created: 2026-04-26
----
-
-# Terragrunt
-
-## Definition
-
-Terragrunt 是由 Gruntwork 开发的**Terraform 轻量封装工具**，核心目标是贯彻 DRY（Don't Repeat Yourself）原则，简化多环境、多账户 Terraform 配置的管理。
-
-## Core Value
-
-Terragrunt 对 Terraform 的核心改进在于**减少重复配置**：
-
-| 问题 | Terraform 方案 | Terragrunt 方案 |
-|------|---------------|----------------|
-| provider 块重复 | 每个环境独立声明 | `terragrunt.hcl` 统一管理 |
-| remote_state 块重复 | 多处硬编码 | 模板化复用 |
-| 模块引用方式 | 固定分支引用 | 版本锁定引用 |
-| 多环境同步 | 手动复制配置 | `include` 块继承 |
-
-**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
-
-## Compatibility
-
-Terragrunt **完全兼容** Terraform 的所有命令和 HCL 语法：
-- `terragrunt plan` → 底层调用 `terraform plan`
-- `terragrunt apply` → 底层调用 `terraform apply`
-- 所有 Terraform HCL 块和属性完全兼容
-
-这意味着 Terragrunt **不是** Terraform 的替代品，而是增强层。
-
-**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
-
-## Key Features
-
-### DRY Remote State
-通过 `remote_state` 块集中管理状态文件位置：
-```hcl
-remote_state {
-  backend = "s3"
-  config = {
-    bucket = "my-terraform-state"
-    key    = "${path_relative_to_include()}/terraform.tfstate"
-    region = "eu-west-1"
-    encrypt = true
-  }
-}
-```
-
-### Provider Management
-跨环境统一 provider 配置，避免在每个模块中重复声明。
-
-### Include & Inheritance
-通过 `include` 块实现配置的继承与覆盖：
-```hcl
-include {
-  path = find_in_parent_folders("root.hcl")
-}
-```
-
-## Use Case: Micro Focus Labs Landing Zone
-
-Micro Focus Labs Landing Zone 使用 Terragrunt 管理多账户配置，所有资源通过 Terraform/Terragrunt 管理，Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply。
-
-**来源**: [[ctp-topic-3-deploy-and-maintain-infrastructure]], [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]
-
-## Ecosystem Position
-
-```
-Terraform Ecosystem
-├── Terraform (HashiCorp) — 核心 IaC 引擎
-├── Terragrunt (Gruntwork) — DRY 封装层 ←
-├── Terraform Enterprise (HashiCorp) — 企业 CI 平台
-└── Gruntwork Library (Gruntwork) — 预建模块库
-```
-
-## Related Entities
-
-- [[Terraform]] — Terragrunt 包装的核心引擎
-- [[HashiCorp]] — Terraform 创立公司
-- [[Gruntwork]] — Terragrunt 开发公司
-
-## Related Concepts
-
-- [[Infrastructure-as-Code]] — Terragrunt 的应用领域
-- [[DRY Principle]] — Terragrunt 的设计哲学
-
-## Related Sources
-
-- [[ctp-topic-48-terraform-vs-terragrunt]]
-- [[ctp-topic-3-deploy-and-maintain-infrastructure]]
-- [[ctp-topic-15-working-with-renovatebot]]（Renovate Bot 扫描 Terragrunt 配置）
+---
+title: "Terragrunt"
+type: entity
+tags:
+  - devops
+  - iac
+  - terraform
+  - automation
+created: 2026-04-26
+---
+
+# Terragrunt
+
+## Definition
+
+Terragrunt 是由 Gruntwork 开发的**Terraform 轻量封装工具**，核心目标是贯彻 DRY（Don't Repeat Yourself）原则，简化多环境、多账户 Terraform 配置的管理。
+
+## Core Value
+
+Terragrunt 对 Terraform 的核心改进在于**减少重复配置**：
+
+| 问题 | Terraform 方案 | Terragrunt 方案 |
+|------|---------------|----------------|
+| provider 块重复 | 每个环境独立声明 | `terragrunt.hcl` 统一管理 |
+| remote_state 块重复 | 多处硬编码 | 模板化复用 |
+| 模块引用方式 | 固定分支引用 | 版本锁定引用 |
+| 多环境同步 | 手动复制配置 | `include` 块继承 |
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
+
+## Compatibility
+
+Terragrunt **完全兼容** Terraform 的所有命令和 HCL 语法：
+- `terragrunt plan` → 底层调用 `terraform plan`
+- `terragrunt apply` → 底层调用 `terraform apply`
+- 所有 Terraform HCL 块和属性完全兼容
+
+这意味着 Terragrunt **不是** Terraform 的替代品，而是增强层。
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
+
+## Key Features
+
+### DRY Remote State
+通过 `remote_state` 块集中管理状态文件位置：
+```hcl
+remote_state {
+  backend = "s3"
+  config = {
+    bucket = "my-terraform-state"
+    key    = "${path_relative_to_include()}/terraform.tfstate"
+    region = "eu-west-1"
+    encrypt = true
+  }
+}
+```
+
+### Provider Management
+跨环境统一 provider 配置，避免在每个模块中重复声明。
+
+### Include & Inheritance
+通过 `include` 块实现配置的继承与覆盖：
+```hcl
+include {
+  path = find_in_parent_folders("root.hcl")
+}
+```
+
+## Use Case: Micro Focus Labs Landing Zone
+
+Micro Focus Labs Landing Zone 使用 Terragrunt 管理多账户配置，所有资源通过 Terraform/Terragrunt 管理，Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply。
+
+**来源**: [[ctp-topic-3-deploy-and-maintain-infrastructure]], [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]
+
+## Ecosystem Position
+
+```
+Terraform Ecosystem
+├── Terraform (HashiCorp) — 核心 IaC 引擎
+├── Terragrunt (Gruntwork) — DRY 封装层 ←
+├── Terraform Enterprise (HashiCorp) — 企业 CI 平台
+└── Gruntwork Library (Gruntwork) — 预建模块库
+```
+
+## Related Entities
+
+- [[Terraform]] — Terragrunt 包装的核心引擎
+- [[HashiCorp]] — Terraform 创立公司
+- [[Gruntwork]] — Terragrunt 开发公司
+
+## Related Concepts
+
+- [[Infrastructure-as-Code]] — Terragrunt 的应用领域
+- [[DRY Principle]] — Terragrunt 的设计哲学
+
+## Related Sources
+
+  - ctp-topic-48-terraform-vs-terragrunt
+  - ctp-topic-3-deploy-and-maintain-infrastructure
+  - ctp-topic-15-working-with-renovatebot
+  - learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform
diff --git a/wiki/entities/TestingRealityChecker.md b/wiki/entities/TestingRealityChecker.md
new file mode 100644
index 00000000..8f491095
--- /dev/null
+++ b/wiki/entities/TestingRealityChecker.md
@@ -0,0 +1,33 @@
+---
+title: "TestingRealityChecker"
+type: entity
+tags: []
+sources: [agents-orchestrator, testing-reality-checker]
+last_updated: 2026-05-29
+---
+
+## Overview
+**Testing Reality Checker** is The Agency Testing Department's final gate agent — provides evidence-based production readiness certification, defaulting to "NEEDS WORK" unless overwhelming visual evidence proves otherwise.
+
+## Role
+- **Role**: Evidence-based certification / Final integration validator
+- **Personality**: Skeptical, evidence-demanding, uncompromising on quality
+- **Vibe**: "Default to 'NEEDS WORK' unless overwhelming evidence proves production readiness"
+
+## Core Responsibilities
+- Perform final integration testing on completed systems
+- Cross-validate all QA findings with comprehensive automated screenshots
+- Default to "NEEDS WORK" state — requires overwhelming proof to certify
+- Only grant production-ready status with complete visual evidence
+
+## Key Principle
+> "Default to 'NEEDS WORK' unless overwhelming evidence proves production readiness."
+
+## Relationship
+- **Spawned By**: [[AgentsOrchestrator]] — Phase 4 (Final Integration)
+- **Final Gate**: Acts as the last quality checkpoint before production deployment
+- **Complements**: [[EvidenceQA]] — Reality Checker validates across all tasks, EvidenceQA validates per-task
+
+## Sources
+- [[agents-orchestrator]]
+- [[testing-reality-checker]]
diff --git a/wiki/entities/The-Agency.md b/wiki/entities/The-Agency.md
index 5e2afc35..a8ebb664 100644
--- a/wiki/entities/The-Agency.md
+++ b/wiki/entities/The-Agency.md
@@ -1,76 +1,107 @@
-# The Agency
-
-## Definition
-
-The Agency 是一个由 AI 编码代理（agent）驱动的多智能体开发系统，提供 **147 个专业化 Agent** 跨 **12 个业务部门**运作，涵盖 Engineering、Design、Finance、Game Dev、Marketing、Paid Media、Product、Project Management、Testing、Support、Spatial Computing、Specialized 等领域。
-
-## Organizational Structure
-
-```
-The Agency
-├── Engineering（工程部门）
-├── Design（设计部门）
-│   ├── UI Designer
-│   ├── Brand Guardian
-│   ├── Visual Storyteller
-│   ├── UX Researcher
-│   ├── Image Prompt Engineer
-│   ├── Inclusive Visuals Specialist
-│   └── Whimsy Injector
-├── Finance（财务部门）
-├── Game Dev（游戏开发部门）
-├── Marketing（市场营销部门）
-├── Paid Media（付费媒体部门）
-├── Product（产品部门）
-├── Project Management（项目管理部门）
-├── Testing（测试部门）
-├── Support（支持部门）
-├── Spatial Computing（空间计算部门）
-│   ├── XR Interface Architect
-│   ├── XR Immersive Developer
-│   ├── XR Cockpit Interaction Specialist
-│   ├── visionOS Spatial Engineer
-│   └── macOS Spatial/Metal Engineer
-└── Specialized（专业部门）
-    ├── Study Abroad Advisor
-    ├── Agents Orchestrator
-    ├── Identity Graph Operator
-    ├── MCP Builder Agent
-    ├── Agentic Identity & Trust Architect
-    ├── Civil Engineer
-    ├── Document Generator
-    ├── Government Digital Presales Consultant
-    ├── Healthcare Marketing Compliance Specialist
-    ├── Compliance Auditor
-    ├── Workflow Architect
-    ├── Corporate Training Designer
-    ├── Cultural Intelligence Strategist
-    ├── Model QA Specialist
-    └── LSP/Index Engineer
-```
-
-## Core Design Principles
-
-1. **鲜明性格**（拒绝通用人设）——每个 Agent 拥有明确的专业边界和独特性格
-2. **明确交付物**（真实代码/模板）——每个 Agent 的输出可量化、可验证
-3. **可量化指标**——每个 Agent 定义明确的成功指标
-4. **经过验证的工作流**——Agent 行为遵循经过测试的工作流程
-5. **学习记忆机制**——Agent 具备上下文记忆和自我改进能力
-
-## Contribution Model
-
-The Agency 接受外部贡献，核心方式：
-- 创建全新智能体（8 大分类）
-- 优化现有智能体
-- 分享成功案例
-- 反馈问题
-
-详见 [[contributing_zh-cn]] 和 [[contributing]]（英文原版）。
-
-## Relationship to Multi-Agent Reliability
-
-The Agency 是 [[multi-agent-system-reliability]] 理论的最佳实践场域——通过 Agent 间协作模式（Orchestration、Consensus Voting、Adversarial Debate、Knock-out）实现系统级可靠性。[[identity-graph-operator]] 解决 Agent 间身份一致性问题，[[agentic-identity-trust]] 解决 Agent 间信任与授权问题，共同构成完整的多智能体基础设施。
-
-## Aliases
-- The Agency Multi-Agent System
-- Agency Agents
+---
+title: "The Agency"
+type: entity
+tags: [multi-agent, the-agency]
+sources: [contributing_zh-cn, contributing, design-whimsy-injector, readme.md, marketing-carousel-growth-engine, qwen-readme]
+last_updated: 2026-04-29
+---
+
+## Multi-Tool Integration Support
+The Agency 支持 11 种主流 AI 编码工具的集成适配：
+
+| 工具 | Agent 格式 | 作用域 | 安装脚本 |
+|------|-----------|--------|---------|
+| Claude Code | `.md` | Home | `install.sh --tool claude-code` |
+| GitHub Copilot | `.md` | Home | `install.sh --tool copilot` |
+| Antigravity | `SKILL.md` | Home | `install.sh --tool antigravity` |
+| Gemini CLI | 扩展包+Skill | Home | `convert.sh + install.sh` |
+| OpenCode | `.md` | Project | `install.sh --tool opencode` |
+| OpenClaw | `SOUL.md+AGENTS.md+IDENTITY.md` | Home | `convert.sh + install.sh` |
+| Cursor | `.mdc` | Project | `install.sh --tool cursor` |
+| Aider | `CONVENTIONS.md` | Project | `install.sh --tool aider` |
+| Windsurf | `.windsurfrules` | Project | `install.sh --tool windsurf` |
+| Kimi Code | YAML | Home | `convert.sh + install.sh` |
+| Qwen Code | `.md` SubAgent | Project | `convert.sh + install.sh` |
+
+核心脚本：
+- `convert.sh`：从源 `.md` 生成各工具中间格式
+- `install.sh`：将转换后的文件复制到目标工具配置目录
+
+详见 [[OpenCode Integration]]。
+
+# The Agency
+
+## Definition
+
+The Agency 是一个由 AI 编码代理（agent）驱动的多智能体开发系统，提供 **147 个专业化 Agent** 跨 **12 个业务部门**运作，涵盖 Engineering、Design、Finance、Game Dev、Marketing、Paid Media、Product、Project Management、Testing、Support、Spatial Computing、Specialized 等领域。
+
+## Organizational Structure
+
+```
+The Agency
+├── Engineering（工程部门）
+├── Design（设计部门）
+│   ├── UI Designer
+│   ├── Brand Guardian
+│   ├── Visual Storyteller
+│   ├── UX Researcher
+│   ├── Image Prompt Engineer
+│   ├── Inclusive Visuals Specialist
+│   └── Whimsy Injector
+├── Finance（财务部门）
+├── Game Dev（游戏开发部门）
+├── Marketing（市场营销部门）
+├── Paid Media（付费媒体部门）
+├── Product（产品部门）
+├── Project Management（项目管理部门）
+├── Testing（测试部门）
+├── Support（支持部门）
+├── Spatial Computing（空间计算部门）
+│   ├── XR Interface Architect
+│   ├── XR Immersive Developer
+│   ├── XR Cockpit Interaction Specialist
+│   ├── visionOS Spatial Engineer
+│   └── macOS Spatial/Metal Engineer
+└── Specialized（专业部门）
+    ├── Study Abroad Advisor
+    ├── Agents Orchestrator
+    ├── Identity Graph Operator
+    ├── MCP Builder Agent
+    ├── Agentic Identity & Trust Architect
+    ├── Civil Engineer
+    ├── Document Generator
+    ├── Government Digital Presales Consultant
+    ├── Healthcare Marketing Compliance Specialist
+    ├── Compliance Auditor
+    ├── Workflow Architect
+    ├── Corporate Training Designer
+    ├── Cultural Intelligence Strategist
+    ├── Model QA Specialist
+    └── LSP/Index Engineer
+```
+
+## Core Design Principles
+
+1. **鲜明性格**（拒绝通用人设）——每个 Agent 拥有明确的专业边界和独特性格
+2. **明确交付物**（真实代码/模板）——每个 Agent 的输出可量化、可验证
+3. **可量化指标**——每个 Agent 定义明确的成功指标
+4. **经过验证的工作流**——Agent 行为遵循经过测试的工作流程
+5. **学习记忆机制**——Agent 具备上下文记忆和自我改进能力
+
+## Contribution Model
+
+The Agency 接受外部贡献，核心方式：
+- 创建全新智能体（8 大分类）
+- 优化现有智能体
+- 分享成功案例
+- 反馈问题
+
+详见 [[contributing_zh-cn]] 和 [[contributing]]（英文原版）。
+
+## Relationship to Multi-Agent Reliability
+
+The Agency 是 [[multi-agent-system-reliability]] 理论的最佳实践场域——通过 Agent 间协作模式（Orchestration、Consensus Voting、Adversarial Debate、Knock-out）实现系统级可靠性。[[identity-graph-operator]] 解决 Agent 间身份一致性问题，[[agentic-identity-trust]] 解决 Agent 间信任与授权问题，共同构成完整的多智能体基础设施。
+
+## Aliases
+- The Agency Multi-Agent System
+- Agency Agents
diff --git a/wiki/entities/The-DAO.md b/wiki/entities/The-DAO.md
new file mode 100644
index 00000000..11a87997
--- /dev/null
+++ b/wiki/entities/The-DAO.md
@@ -0,0 +1,32 @@
+---
+title: "The DAO"
+type: entity
+tags: []
+last_updated: 2026-05-01
+---
+
+## Overview
+The DAO 是 2016 年以太坊网络上基于智能合约运作的去中心化投资组织，也是以太坊历史上最著名的重入攻击事件。2016年6月17日，攻击者利用 The DAO 合约中的重入漏洞，在单笔交易中反复提取约 360 万 ETH（当时价值约 5000 万美元），最终导致以太坊硬分叉为 ETH 和 ETC 两条链。
+
+## Key Facts
+- **成立时间**：2016 年 5 月
+- **攻击时间**：2016 年 6 月 17 日
+- **攻击金额**：约 360 万 ETH
+- **攻击类型**：重入攻击（Reentrancy Attack）
+- **漏洞位置**：splitDAO() 函数中的 withdraw() 逻辑，在状态更新前执行外部调用
+
+## Attack Mechanism
+1. 攻击者部署恶意合约到 The DAO
+2. 恶意合约的 `fallback()` 函数在接收 ETH 时递归调用 The DAO 的 withdraw
+3. 由于余额检查在递归调用之前未完成，每次递归都能提取资金
+4. 最终攻击者获得了远超其原始存款的 ETH
+
+## Significance
+- 开创了智能合约安全研究的先河
+- 直接导致以太坊经典（ETC）的诞生
+- 催生了 [[ChecksEffectsInteractions]] 模式和 [[ReentrancyGuard]] 模式
+- 推动了 Solidity 安全最佳实践的全面建立
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
+- [[blockchain-security-auditor]]
diff --git a/wiki/entities/Tianyancha.md b/wiki/entities/Tianyancha.md
new file mode 100644
index 00000000..01d04e14
--- /dev/null
+++ b/wiki/entities/Tianyancha.md
@@ -0,0 +1,38 @@
+---
+title: "Tianyancha (天眼查)"
+type: entity
+tags: ["china", "enterprise-information", "procurement", "supplier-verification"]
+last_updated: 2026-04-25
+---
+
+## Aliases
+- 天眼查
+
+## Definition
+
+天眼查是中国知名的企业信息查询平台，提供企业工商信息、司法风险、经营状况、知识产权等多维度企业数据查询服务。与[[QiChaCha]]（企查查）并列为国内两大主流企业信息查询平台，在供应链管理中用于供应商资质验证与风险评估。
+
+## Key Features
+- **工商信息**：公司基本信息、注册资本、股东结构、分支机构
+- **司法风险**：法律诉讼、法院公告、被执行人、失信记录
+- **经营状况**：年报信息、税务评级、资质认证
+- **知识产权**：商标、专利、软件著作权登记信息
+- **舆情监控**：新闻舆情、监管处罚信息
+
+## Application in Supply Chain
+
+[[Supply Chain Strategist Agent]] 在供应商开发流程中使用天眼查进行资质验证（与[[QiChaCha]]互为替代）：
+
+1. **真实性验证**：核实营业执照信息与供应商自称一致
+2. **经营风险评估**：查询失信被执行人和行政处罚记录
+3. **股东穿透分析**：识别实际控制人和关联方
+4. **资质核验**：通过知识产权和资质认证信息交叉验证供应商技术能力
+
+## Comparison with QiChaCha
+- 两者数据覆盖面略有差异，建议交叉验证
+- 天眼查在知识产权查询方面通常更为全面
+- 企查查在上市公告和融资数据方面有时更及时
+
+## Connections
+- [[Supply Chain Strategist Agent]] ← uses_tool ← [[Tianyancha]]
+- [[QiChaCha]] ← similar_to ← [[Tianyancha]]
diff --git a/wiki/entities/TypeScriptLanguageServer.md b/wiki/entities/TypeScriptLanguageServer.md
new file mode 100644
index 00000000..c7129945
--- /dev/null
+++ b/wiki/entities/TypeScriptLanguageServer.md
@@ -0,0 +1,26 @@
+---
+title: "TypeScriptLanguageServer"
+type: entity
+entity_type: tool
+tags:
+  - LSP
+  - TypeScript
+  - language-server
+sources:
+  - lsp-index-engineer.md
+last_updated: 2026-04-29
+---
+
+## Overview
+TypeScript Language Server 是 graphd 默认要求生产就绪的语言服务器之一，通过 `typescript-language-server` 实现 TypeScript 和 JavaScript 代码的 LSP 服务。
+
+## Details
+- **Command**: `typescript-language-server --stdio`
+- **Protocol**: LSP 3.17
+- **Role in graphd**: 默认必须支持的生产就绪语言服务器
+- **Capabilities**: definitionProvider, referencesProvider, hoverProvider, documentSymbolProvider, completionProvider
+
+## Connections
+- [[TypeScriptLanguageServer]] ← is_coordinated_by ← [[LSPOrchestrator]]
+- [[TypeScriptLanguageServer]] ← provides_semantics_to ← [[SemanticCodeGraph]]
+- [[TypeScriptLanguageServer]] ← part_of ← [[GraphDaemon]]
diff --git a/wiki/entities/UX-Researcher.md b/wiki/entities/UX-Researcher.md
index a05f15be..8513904e 100644
--- a/wiki/entities/UX-Researcher.md
+++ b/wiki/entities/UX-Researcher.md
@@ -1,20 +1,29 @@
 ---
 title: "UX Researcher"
 type: entity
-sources: [workflow-startup-mvp]
-last_updated: 2026-04-25
+sources: [workflow-startup-mvp, design-ux-researcher.md]
+last_updated: 2026-04-24
 ---
 
 ## Definition
-UX Researcher 是 [[workflow-startup-mvp]] 中负责快速用户调研和竞品分析的 Agent 角色，帮助识别产品的差异化方向。
+UX Researcher 是 The Agency Design 部门的用户体验研究专家 Agent，专注于通过混合研究方法（定性与定量）理解用户行为、验证设计决策、提供可落地洞察。与 [[UX-Architect]] 和 [[Design-Brand-Guardian]] 共同构成 Design 部门三支柱（Research → Architecture → Delight）。
 
 ## Details
-- **输入**：目标用户画像、竞品列表
-- **输出**：1 页调研简报，包含：竞品标配功能、竞品短板、可差异化方向
-- **执行时机**：Week 1 第二步，与 Sprint Prioritizer 并行激活
+- **核心方法**：先确立清晰研究问题 → 选择有统计依据的样本量和研究方法 → 通过三角验证缓解偏差 → 转化为可实施的设计建议
+- **默认要求**：包含无障碍研究和包容性设计测试
+- **交付物**：用户画像（含直接引用语）、用户旅程地图、可用性测试结果、优先级建议（高/中/长期）
+- **成功标准**：80%+ 研究建议被设计与产品团队采纳实施
+
+## Key Collaborators
+- [[UX-Architect]]：UX Researcher 提供用户洞察，UX Architect 将其转化为设计系统
+- [[UX-Designer]]：UI 设计师依据用户研究洞察进行界面设计
+- [[Design-Brand-Guardian]]：确保研究洞察在品牌框架内落地
+- [[Product-Manager]]：产品经理，接收研究建议并纳入产品决策
 
 ## Aliases
 - UX Researcher
 
 ## Sources
 - [[workflow-startup-mvp]]
+- [[design-ux-researcher.md]]
+
diff --git a/wiki/entities/Unity.md b/wiki/entities/Unity.md
new file mode 100644
index 00000000..9c025950
--- /dev/null
+++ b/wiki/entities/Unity.md
@@ -0,0 +1,49 @@
+---
+title: "Unity Technologies"
+type: entity
+tags: ["company", "game-engine", "product"]
+sources: ["unity-shader-graph-artist", "unity-editor-tool-developer", "unity-multiplayer-engineer"]
+last_updated: 2026-05-01
+---
+
+## Overview
+
+Unity Technologies 是 Unity 游戏引擎的开发商，提供实时 3D 创作工具。The Agency Wiki 涵盖其核心工具链：Shader Graph、URP/HDRP 渲染管线、Editor 扩展系统和 Netcode for GameObjects 网络框架。
+
+## Aliases
+
+- Unity
+- Unity Engine
+- Unity Technologies
+
+## Key Products
+
+| 产品 | 描述 |
+|------|------|
+| **Unity Engine** | 跨平台实时 3D 创作引擎 |
+| **Shader Graph** | 可视化 shader 编辑工具，支持 URP/HDRP |
+| **URP** | Universal Render Pipeline，通用渲染管线 |
+| **HDRP** | High Definition Render Pipeline，高清渲染管线 |
+| **Netcode for GameObjects** | 官方多人游戏网络编程框架 |
+| **Unity Gaming Services** | 云服务集合（Relay/Lobby/Authentication 等） |
+| **Unity Transport** | 网络传输层，支持直连和 Relay |
+
+## Wiki 中的关联 Agent
+
+- [[unity-shader-graph-artist]]：Shader Graph 和 URP/HDRP 渲染效果专家
+- [[unity-editor-tool-developer]]：Editor 扩展开发专家
+- [[unity-multiplayer-engineer]]：多人游戏网络系统专家
+- [[unity-architect]]：Unity 游戏架构师（ScriptableObject 优先设计）
+- [[technical-artist]]：通用技术美术，与 Unity Shader Graph Artist 共享规范
+
+## 竞争对手
+
+- [[EpicGames]]（Unreal Engine 5）：竞争引擎厂商
+
+## Connections
+
+- [[UnityShaderGraphArtist]] ← 使用 → [[Shader]]（URP/HDRP 渲染）
+- [[URP]] ← 渲染管线 → Unity
+- [[HDRP]] ← 渲染管线 → Unity
+- [[UnityMultiplayerEngineer]] ← 使用 → [[NetcodeForGameObjects]]（官方网络框架）
+- [[UnityEditorToolDeveloper]] ← 使用 → [[Editor scripting]]（扩展 Unity Editor）
diff --git a/wiki/entities/UnrealEngine5.md b/wiki/entities/UnrealEngine5.md
index 570ecfc5..5889552f 100644
--- a/wiki/entities/UnrealEngine5.md
+++ b/wiki/entities/UnrealEngine5.md
@@ -1,24 +1,49 @@
 ---
-title: "Unreal Engine 5"
+title: "UnrealEngine5"
 type: entity
-tags: ["game-engine", "game-development", "unreal"]
-sources: ["unreal-technical-artist", "unreal-world-builder"]
-last_updated: 2026-04-26
+tags: ["game-engine", "product", "unreal-engine"]
+sources: ["unreal-systems-engineer", "unreal-multiplayer-architect", "unreal-technical-artist", "unreal-world-builder"]
+last_updated: 2026-04-30
 ---
 
-## Overview
-Unreal Engine 5（UE5）是 Epic Games 开发的新一代游戏引擎，提供完整的 AAA 级视觉内容创作工具链。[[unreal-technical-artist]] 的核心工作平台。
+## Aliases
+- UE5
+- Unreal Engine 5
+- UE 5
+- UE5.3+
 
-## Key Capabilities Relevant to Technical Art
-- **Material Editor**：可视化材质创作系统，支持 Material Functions、Material Instances、Quality Switch
-- **Niagara**：新一代 VFX 和粒子系统，支持 GPU/CPU 分离模拟
-- **PCG**（Procedural Content Generation）：程序化内容生成框架，用于开放世界资产分布
-- **Nanite**：虚拟几何体系统，支持自动 LOD 和海量实例化
-- **Substrate**（UE5.3+）：多层物理材质系统，替代传统 SSS workaround
-- **World Partition**：开放世界分区管理，与 HLOD 和 PCG 流式加载协同
-- **Unreal Insights**：性能分析工具，用于渲染性能瓶颈诊断
+## Definition
+Unreal Engine 5（UE5）是 Epic Games 于 2022 年发布的游戏引擎，引入 Nanite（虚拟化几何）、Lumen（动态全局光照）、World Partition（开放世界分区）、MetaHuman 等核心技术，是构建 AAA 级开放世界游戏的首选引擎。
 
-## In This Wiki
-- [[unreal-technical-artist]] — 视觉系统工程师 Agent，依赖 UE5 工具链交付 AAA 视觉资产
-- [[unreal-world-builder]] — 开放世界场景搭建 Agent，基于 UE5 World Partition
-- [[unreal-systems-engineer]] — 引擎底层系统工程师 Agent，深度集成 UE5 架构
+## Core Systems Relevant to LLM-Wiki-Agent
+- **[[World Partition]]**：开放世界分区管理，支持大规模世界的流式加载与多用户协作编辑
+- **[[Nanite]]**：虚拟化几何系统，处理海量三角形细节，无需手动 LOD
+- **[[Lumen]]**：软件 Ray Tracing 全局光照（UE5 默认方案）
+- **[[ProceduralContentGeneration]]（PCG）**：程序化内容生成，用于大规模植被和环境资产放置
+- **[[HierarchicalLOD]]（HLOD）**：层级 LOD，将远处多 Actor 合并为少量网格
+- **[[RuntimeVirtualTexturing]]（RVT）**：运行时虚拟纹理，消除 Landscape 层混合开销
+- **[[LargeWorldCoordinates]]（LWC）**：双精度坐标，解决超大世界浮点精度问题
+- **[[OneFilePerActor]]（OFPA）**：多用户协作编辑模式
+- **Gameplay Ability System（GAS）**：技能系统框架
+- **Niagara**：粒子与 VFX 系统
+
+## Key Architecture Notes
+- Tick 逻辑必须 C++ 实现，Blueprint VM 开销在每帧调用下与 C++ 相差 ~10x
+- Blueprint 适用于：高层游戏流、UI 原型、设计师可扩展层
+- Nanite 优先策略：所有静态网格在条件允许时启用 Nanite
+- LWC 启用阈值：任何轴超过 2km 的世界必须启用，~20km 后出现浮点精度错误
+
+## Connections
+- [[Epic Games]] ← 开发商 ← UnrealEngine5
+- [[World Partition]] ← 世界管理 ← UnrealEngine5
+- [[Nanite]] ← 几何渲染 ← UnrealEngine5
+- [[UnrealWorldBuilder]] ← 运行环境 ← UnrealEngine5
+- [[UnrealSystemsEngineer]] ← 技术栈 ← UnrealEngine5
+- [[UnrealMultiplayerArchitect]] ← 技术栈 ← UnrealEngine5
+- [[UnrealTechnicalArtist]] ← 技术栈 ← UnrealEngine5
+
+## Sources
+- [[unreal-systems-engineer]]
+- [[unreal-multiplayer-architect]]
+- [[unreal-technical-artist]]
+- [[unreal-world-builder]]
diff --git a/wiki/entities/VannevarBush.md b/wiki/entities/VannevarBush.md
new file mode 100644
index 00000000..c4108310
--- /dev/null
+++ b/wiki/entities/VannevarBush.md
@@ -0,0 +1,26 @@
+---
+title: "Vannevar Bush"
+type: entity
+tags: [person, history, knowledge-management]
+sources: [llm-wiki]
+last_updated: 2026-05-02
+---
+
+## Overview
+Vannevar Bush（1894–1974）是美国科学家、工程师，MIT 工程学院院长，1941–1947 年担任美国总统科学顾问。1945 年，他在《大西洋月刊》发表经典文章 **"As We May Think"**，提出了 **Memex**（Memory Extender）概念——一种个人化的、精心维护的知识库，文档之间存在关联轨迹（associative trails）。Bush 的设想是：私密的、主动维护的，文档之间的关联与文档本身同样重要。
+
+## Memex 概念
+Memex 是 Bush 构想的假想设备，用户可以在其中存储书籍、记录和通信，然后快速、自动地检索任意组合的内容。核心创新：**关联轨迹**（associative trails）——用户可以在任意两条记录之间建立联系，形成路径，模拟人脑的联想式思维。Bush 认为这是扩展人类记忆和知识的根本方式。
+
+## 历史影响与局限
+Bush 的 Memex 概念比后来的万维网更接近 LLM Wiki 的愿景。然而他未能解决的核心问题是：**谁来维护？** 手动建立和维护大量交叉引用的工作量令人望而却步，这就是 Bush 的设想未能真正实现的原因。
+
+LLM Wiki（[[PersistentWiki]]）直接承接了 Bush 的愿景——LLM 解决了"谁来维护"的问题。Bush 提出的关联轨迹思想在现代 Wiki 的双向链接中得到了实现，而 LLM Wiki 则将这一愿景扩展为 LLM 自动维护整个知识库。
+
+## Aliases
+- Vannevar Bush
+
+## Related
+- [[Memex]]：Bush 1945 年提出的个人知识库概念
+- [[PersistentWiki]]：承接 Memex 愿景的现代实现，由 LLM 负责维护
+- [[LLM Wiki]]：持久化维基知识库模式的完整描述
diff --git a/wiki/entities/Victor-Turner.md b/wiki/entities/Victor-Turner.md
new file mode 100644
index 00000000..35f80df7
--- /dev/null
+++ b/wiki/entities/Victor-Turner.md
@@ -0,0 +1,27 @@
+---
+title: "Victor Turner"
+type: entity
+tags: ["anthropologist", "ritual-analysis", "liminality", "symbolic-anthropology", "african-studies"]
+last_updated: 2026-04-25
+---
+
+## Overview
+英国人类学家，以对非洲 Ndembu 社会的仪式研究闻名。提出了阈限（liminality）和 communitas 概念，对理解仪式过程和人类社会转化机制有深远影响。
+
+## Aliases
+- Turner
+- V. Turner
+
+## Key Contributions
+- **阈限（Liminality）**：仪式过程中处于"之间"状态的阶段——参与者脱离正常社会结构，具有特殊地位和可能性
+- **Communitas**：阈限状态中产生的强烈平等主义和直接人际连接感，超越正常社会等级
+- **仪式过程三阶段**（van Gennep 模型）：分离（separation）→ 阈限（liminality）→ 整合（incorporation）
+- **符号人类学**：分析仪式中象征符号的多义性（多元编码：sensuous/sentimental/oppositional）
+
+## Relevance to Anthropologist Agent
+Anthropologist Agent 将 Turner 的阈限与 communitas 作为 Advanced Capabilities 的核心工具，用于设计具有社会转化功能的文化仪式。
+
+## Connections
+- [[Liminality]] ← authored_by ← [[Victor-Turner]]
+- [[Anthropologist-Agent]] ← uses_framework ← [[Victor-Turner]]
+- [[Van-Gennep]] ← predecessor ← [[Victor-Turner]]
diff --git a/wiki/entities/VladimirPropp.md b/wiki/entities/VladimirPropp.md
new file mode 100644
index 00000000..6ef2523e
--- /dev/null
+++ b/wiki/entities/VladimirPropp.md
@@ -0,0 +1,25 @@
+---
+title: "Vladimir Propp"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-30
+---
+
+## Aliases
+- V. Propp
+- Vladimir Propp
+
+## Overview
+Vladimir Propp (1895–1970) 是俄罗斯民俗学家、形式主义叙事学家，其里程碑著作《民间故事形态学》（Morphology of the Folktale, 1928）通过对大量俄罗斯民间故事的归纳，提出了 **31 种叙事功能**（Functions）和 **7 种角色类型**（Character Types）。
+
+## Key Contributions
+- **31 Narrative Functions**：民间故事中恒定出现的31种叙事功能（如 Absentation, Mediation, Departure, Test, Victory 等），按固定顺序出现
+- **7 Character Types**：Donor（供者）、Hero（英雄）、Princess（公主）、Dispatcher（派遣者）、Villain（反派）、Helper（帮助者）、Seducer/Rival（诱骗者/对手）
+- **形态学方法**：将故事还原为可操作的结构单元
+
+## In The Agency Context
+[[Academic Narratologist]] 将 Propp's Morphology 应用于童话故事分析和 quest/冒险类叙事的结构解构。
+
+## References
+- Morphology of the Folktale (1928, English 1958)
diff --git a/wiki/entities/Werner-Vogels.md b/wiki/entities/Werner-Vogels.md
new file mode 100644
index 00000000..029b1f95
--- /dev/null
+++ b/wiki/entities/Werner-Vogels.md
@@ -0,0 +1,28 @@
+---
+title: "Werner Vogels"
+type: entity
+tags: ["architecture", "person", "aws"]
+sources: ["Hermes-Agent-配置笔记"]
+last_updated: 2026-04-27
+---
+
+## Overview
+Werner Vogels 是 Amazon CTO（首席技术官），Amazon.com 技术基础设施的关键架构师。该名字被推荐作为 Hermes Agent 多角色配置中"架构师"角色的命名来源（werner）。
+
+## Aliases
+- Werner Vogels
+- Werner
+
+## Key Contributions
+- Amazon CTO，主导 Amazon 全球技术基础设施架构
+- 提出"Build primitives, not solutions"等技术理念
+- Amazon 可靠性文化（Amazon Reliability Engineering）的重要推动者
+
+## In Hermes Agent Context
+在 [[Hermes-Agent-配置笔记]] 中，Werner Vogels 被推荐作为 Hermes Agent 多角色 Vibe Coding 场景中"架构师"角色的命名来源：
+- 推荐名字：`werner`
+- 角色定位：架构师
+- 来源依据：Werner Vogels 代表顶级系统架构师的专业形象
+
+## Connections
+- [[Hermes-Agent-配置笔记]] → uses name → [[Werner-Vogels]]
diff --git a/wiki/entities/Whimsy-Injector.md b/wiki/entities/Whimsy-Injector.md
new file mode 100644
index 00000000..8f77f039
--- /dev/null
+++ b/wiki/entities/Whimsy-Injector.md
@@ -0,0 +1,42 @@
+---
+title: "Whimsy Injector"
+type: entity
+tags: [brand-personality, ui-design, user-experience, the-agency]
+sources: [design-whimsy-injector]
+last_updated: 2026-05-15
+---
+
+# Whimsy Injector
+
+## Definition
+
+品牌个性和愉悦感注入专家 Agent（Expert Creative Specialist），隶属于 [[The-Agency]] Design 部门。核心使命：在保持专业性和品牌一致性的前提下，通过意想不到的趣味元素让品牌体验令人难忘，从而实现品牌差异化。
+
+## Identity & Memory
+
+- **Role**: 品牌人格和愉悦交互专家
+- **Personality**: 活泼、创意、战略、专注乐趣
+- **Memory**: 擅长记住成功的趣味实现案例、用户愉悦模式、互动策略
+
+## Core Capabilities
+
+- 战略人格注入：为品牌添加增强而非干扰核心功能的趣味元素
+- 包容性愉悦设计：确保趣味元素对残障用户可访问、不干扰屏幕阅读器
+- 微交互设计：CSS 动画、状态反馈、按钮效果
+- 游戏化系统：成就系统、彩蛋发现、进度庆祝
+
+## Key Deliverables
+
+- Brand Personality Framework（品牌人格框架）
+- Micro-Interaction Design System（微交互设计系统）
+- Playful Microcopy Library（趣味文案库）
+- Gamification System Design（游戏化系统设计）
+
+## Relationship to Other Agents
+
+- 与 [[ArchitectUX]] 协作：ArchitectUX 提供技术基础，Whimsy Injector 提供品牌人格
+- 服务于 [[LuxuryDeveloper]]：LuxuryDeveloper 是 Whimsy Injector 的目标用户和受益者
+
+## Aliases
+- Whimsy Injector Agent
+- Design Whimsy Injector
diff --git a/wiki/entities/Wormhole.md b/wiki/entities/Wormhole.md
new file mode 100644
index 00000000..bf1c9486
--- /dev/null
+++ b/wiki/entities/Wormhole.md
@@ -0,0 +1,31 @@
+---
+title: "Wormhole"
+type: entity
+tags: []
+last_updated: 2026-05-01
+---
+
+## Overview
+Wormhole 是 Solana-Ethereum 跨链桥，2022 年 2 月 2 日遭受攻击，损失约 3.2 亿美元，是 DeFi 历史上最大的黑客攻击之一。攻击者利用签名验证漏洞伪造了有效的跨链消息，成功铸造了 12 万个 wETH 而无需真实抵押。
+
+## Key Facts
+- **攻击时间**：2022 年 2 月 2 日
+- **损失金额**：约 3.2 亿美元
+- **攻击类型**：签名验证绕过攻击
+- **受影响链**：Solana ↔ Ethereum
+
+## Attack Mechanism
+1. Wormhole 合约使用链外验证者网络验证跨链消息
+2. 攻击者发现签名验证逻辑中的漏洞，能够伪造验证者签名
+3. 伪造签名后，攻击者在 Ethereum 端凭空铸造了 120,000 wETH
+4. 攻击者将铸造的 wETH 跨链到 Solana，换出真实的 ETH
+
+## Significance
+- 成为当时 DeFi 历史上最大的单次攻击事件
+- 暴露了跨链桥的中心化风险（验证者集合是攻击面）
+- 推动了跨链安全标准的发展
+- 后续激励了更安全的跨链设计（如 LayerZero 的去中心化验证）
+
+## Sources
+- [[engineering-solidity-smart-contract-engineer]]
+- [[blockchain-security-auditor]]
diff --git a/wiki/entities/Yjs.md b/wiki/entities/Yjs.md
new file mode 100644
index 00000000..ea08d7cd
--- /dev/null
+++ b/wiki/entities/Yjs.md
@@ -0,0 +1,38 @@
+---
+title: "Yjs"
+type: entity
+tags: []
+last_updated: 2026-03-05
+---
+
+## Identity
+
+**Type:** Product（产品/开源库）
+**Source:** [[nexus-spatial-discovery]]
+
+## Definition
+
+Yjs 是 [[Nexus Spatial]] 采用的协作引擎——基于 CRDT（Conflict-free Replicated Data Types，无冲突复制数据类型）的实时协同编辑库，用于多用户空间协作场景下的冲突无关并发编辑。
+
+## Why CRDT for Spatial Collaboration
+
+传统 OT（Operational Transform）方案在高延迟、离线编辑场景下存在冲突风险。CRDT 的优势：
+
+| 特性 | OT | CRDT (Yjs) |
+|------|-----|-------------|
+| 离线编辑 | 需要复杂补偿 | 天然支持 |
+| 节点延迟容忍 | 低 | 高 |
+| 实现复杂度 | 高 | 中 |
+| 网络分区恢复 | 困难 | 自动 |
+
+## 在 Nexus Spatial 中的应用
+
+- 多用户同时编辑 3D 节点图
+- 实时协作状态同步（WebRTC P2P）
+- 无需中心服务器协调——去中心化协作
+- 支持 100+ 并发协作者（无写入冲突）
+
+## Connections
+
+- [[Nexus-Spatial]] ← 协作引擎
+- [[Command-Theater]] ← 协作界面
diff --git a/wiki/entities/dbt.md b/wiki/entities/dbt.md
new file mode 100644
index 00000000..64b50db1
--- /dev/null
+++ b/wiki/entities/dbt.md
@@ -0,0 +1,62 @@
+---
+title: "dbt (data build tool)"
+type: entity
+tags: [data-engineering, data-transformation, SQL, data-quality]
+sources: [engineering-data-engineer]
+last_updated: 2026-05-02
+---
+
+## Overview
+
+dbt（data build tool）是数据转换和数据质量管理的 SQL-first 工具，允许分析师和工程师使用 SQL 定义数据转换、测试和质量契约。Data Engineer Agent 使用 dbt Cloud 定义 Medallion Architecture Silver 层的 schema 契约和数据质量测试。
+
+## Core Capabilities
+
+### Data Transformation
+- 使用 SQL 定义 `models/`（转换模型）
+- 支持 Jinja2 模板化 SQL，复用逻辑
+- 增量模型（`incremental` materialization）减少全量计算
+
+### Schema Contract Enforcement
+```yaml
+models:
+  - name: silver_orders
+    config:
+      contract:
+        enforced: true  # schema 不匹配时构建失败
+    columns:
+      - name: order_id
+        data_type: string
+        constraints:
+          - type: not_null
+          - type: unique
+        tests:
+          - not_null
+          - unique
+      - name: revenue
+        data_type: decimal(18, 2)
+        tests:
+          - dbt_expectations.expect_column_values_to_be_between:
+              min_value: 0
+              max_value: 1000000
+```
+
+### Data Testing
+- Column tests（not_null、unique、relationships）
+- dbt Expectations 扩展（值范围、分布、新鲜度）
+- Recency tests（如"1 小时内必须有新数据"）
+
+### Semantic Layer（dbt Cloud）
+- 定义 Metrics（度量）一次，在多个 BI 工具中复用
+- 统一业务指标定义，消除 BI 层的重复逻辑
+
+## Integration with Lakehouse
+
+- **dbt + Spark/Delta Lake**：Silver 层清洗和 conform
+- **dbt + Kafka**：结合流式写入实现近实时 Silver 层更新
+- **dbt + Databricks**：原生 Unity Catalog 集成
+
+## Related Concepts
+- [[Medallion Architecture]]
+- [[Data Contract]]
+- [[Delta Lake]]
diff --git a/wiki/entities/ffmpeg.md b/wiki/entities/ffmpeg.md
new file mode 100644
index 00000000..f2da203a
--- /dev/null
+++ b/wiki/entities/ffmpeg.md
@@ -0,0 +1,65 @@
+---
+title: "ffmpeg"
+type: entity
+tags: ["audio-processing", "multimedia", "open-source", "cli"]
+sources: ["engineering-voice-ai-integration-engineer"]
+last_updated: 2026-05-02
+---
+
+## Aliases
+- ffmpeg
+- ffprobe（ffmpeg 配套工具）
+
+## Definition
+
+FFmpeg 是开源的多媒体处理工具链，在 Voice AI Integration Engineer 的管道中负责所有音频格式探测、转换和预处理工作。是 Whisper 类转录管道中不可或缺的底层工具。
+
+## Core Tools Used
+
+| 工具 | 用途 |
+|------|------|
+| `ffprobe` | 探测音频格式、时长、codec、采样率、声道数（格式验证） |
+| `ffmpeg` | 格式转换、重采样、响度归一化、静音切除（预处理） |
+
+## Key Operations in Voice AI Pipeline
+
+```bash
+# 1. 探测音频属性（验证）
+ffprobe -v quiet -print_format json \
+  -show_streams -show_format input.wav
+
+# 2. Whisper 预处理（16kHz 单声道 + R128 响度归一化）
+ffmpeg -y -i input.mp4 -vn \
+  -acodec pcm_s16le \
+  -ar 16000 \
+  -ac 1 \
+  -af "loudnorm=I=-16:TP=-1.5:LRA=11" \
+  output.wav
+
+# 3. 长音频分块
+ffmpeg -y -i long_audio.wav \
+  -ss 0 -to 1800 \
+  -acodec copy chunk_0000.wav
+```
+
+## Critical Role in Quality Assurance
+
+> "Never trust file extensions — always probe the actual container." — 必须用 ffprobe 探测实际格式
+
+FFmpeg 是音频质量验证的核心：采样率是否正确（Whisper 需要 16kHz）、是否有音频流（.mp4 可能是纯视频）、音频 codec 是否被支持、时长是否在模型限制内。
+
+## Key Principles
+
+1. **永远探测，不猜**：用 `ffprobe` 而非依赖扩展名
+2. **16kHz 单声道是 Whisper 标准**：除非要处理特定多声道场景
+3. **R128 响度归一化先于 VAD**：确保 VAD 阈值准确
+4. **-vn 去除视频轨道**：.mp4/.mov 等容器中的视频流会影响处理
+
+## Connections
+- [[EBUR128LoudnessNormalization]] — 通过 `-af loudnorm` 实现
+- [[FasterWhisper]] — 消费 ffmpeg 预处理后的音频
+- [[OverlapAwareChunking]] — 通过 ffmpeg 时间切片实现分块
+- [[VoiceActivityDetection]] — VAD 之后 ffmpeg 也可做静音切除
+
+## Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/entities/laozhang2579.md b/wiki/entities/laozhang2579.md
new file mode 100644
index 00000000..6daadf6c
--- /dev/null
+++ b/wiki/entities/laozhang2579.md
@@ -0,0 +1,21 @@
+---
+title: "laozhang2579"
+type: entity
+tags: [blogger, content-creator]
+sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]
+last_updated: 2026-04-20
+---
+
+## Aliases
+- 老张
+
+## Profile
+中文 AI 内容创作者，将 Karpathy 的 LLM Wiki 方法论实操落地为中文教程，专注于 AI 工具实用化分享。
+
+## Role in This Wiki
+- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]] — 解读者/发布者
+
+## Key Contributions
+- 将 Karpathy 的 LLM Wiki 方法论实操落地，提供 Obsidian 完整操作步骤
+- 补充了 Karpathy 原版未涉及的实操细节（附件路径配置、快捷键绑定、Git 插件配置）
+- 对 Dataview 和 Marp 的实用价值持保留态度，认为"基本够用"即可
diff --git a/wiki/entities/n8n.md b/wiki/entities/n8n.md
index c926901f..422f20e2 100644
--- a/wiki/entities/n8n.md
+++ b/wiki/entities/n8n.md
@@ -1,38 +1,34 @@
 ---
 title: "n8n"
 type: entity
-tags: [工作流自动化, 开源, AI自动化, Node-Based-Workflow]
-last_updated: 2026-05-01
+tags: []
 ---
 
-## Definition
-**n8n** 是 GitHub 上最强的开源工作流自动化平台，被称为"功能更强、还能私有部署的开源版 Zapier"，目前拥有恐怖的 16 万 Star。
+## Overview
+n8n 是一个开源工作流自动化平台，通过 HTTP Request 节点连接多个 AI Agent（包括 Hermes Agent 和 OpenClaw Agent），实现统一的自动化工作流编排。
 
-## Aliases
-- n8n.io
-- N8N
+## Key Facts
+- **类型**：开源工作流自动化平台（可自托管）
+- **集成方式**：HTTP Request 节点
+- **连接架构**：
+  - POST `http://<lan-ip>:8642` → Hermes Agent
+  - POST `http://<lan-ip>:18789/v1/chat/completions` → OpenClaw Agent
+- **认证方式**：Bearer Token（`Authorization: Bearer <secret-key>`）
 
-## Key Characteristics
-- 拖拽节点串联各种互不相干的 App，自动执行工作流，省去写代码对接 API 的麻烦
-- 最近在 AI 圈爆火，因为把 LangChain 等 AI 能力也做成了节点，让用户能轻松把大模型嵌入真实业务流程
-- 支持私有部署，数据完全掌握在自己手里
-- 开源免费，适合注重数据隐私的企业和个人
+## n8n 调用 OpenClaw 的配置
+- **URL**：`http://192.168.3.189:18789/v1/chat/completions`
+- **Method**：POST
+- **Body**：
+  ```json
+  {
+    "model": "openclaw:main",
+    "messages": [
+      {"role": "user", "content": "{{ $json.input }}"}
+    ]
+  }
+  ```
 
-## GitHub
-- https://github.com/n8n-io/n8n
-
-## Sources
-- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]
-- [[n8n-workflow-orchestration]]
-- [[obsidian-官方-cli-命令全景速查表]] — Obsidian CLI 工作流编排场景（AI 收件箱自动分拣员、跨平台数据库级联录入）
-- [[可自动化-可扩展-ai增强的电商数据采集与处理系统]]
-- [[n8n-docker-install-update]]
-- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]
-- [[n8n-claude-通过自然语言自动化工作流]]
-- [[n8n-configure-telegram-trigger]]
-- [[n8n-docker-配置-telegram-代理-troubleshooting]]
-
-## Related
-- [[Dify]] — 同为工作流自动化平台，n8n 侧重通用流程自动化，Dify 侧重 LLM 应用开发
-- [[LangChain]] — n8n 支持 LangChain 节点集成
-- [[Zapier]] — n8n 的商业对标产品
+## Related Pages
+- [[n8n-调用openclaw-agents的工作流架构]]
+- [[OpenClaw]]
+- [[Hermes-Agent]]
diff --git a/wiki/entities/pyannote.audio.md b/wiki/entities/pyannote.audio.md
new file mode 100644
index 00000000..7013fec8
--- /dev/null
+++ b/wiki/entities/pyannote.audio.md
@@ -0,0 +1,45 @@
+---
+title: "pyannote.audio"
+type: entity
+tags: ["speaker-diarization", "open-source", "huggingface"]
+sources: ["engineering-voice-ai-integration-engineer"]
+last_updated: 2026-05-02
+---
+
+## Aliases
+- pyannote
+- pyannote.audio
+
+## Definition
+
+pyannote.audio 是一个开源的说话人分离（Speaker Diarization）库，通过 Hugging Face Hub 分发模型（`pyannote/speaker-diarization-3.1`）。支持音频流中"谁在何时说话"的自动检测，与 Whisper 类转录模型配套使用产生带说话人归属的转录结果。
+
+## Key Properties
+
+- **模型**：`pyannote/speaker-diarization-3.1`
+- **访问方式**：Hugging Face token（需申请同意 pyannote 模型协议）
+- **硬件要求**：GPU 推荐（CUDA），CPU 可运行但较慢
+- **输入**：任意格式音频（WAV/MP3/FLAC 等）
+- **输出**：`[{start, end, speaker}]` 格式的说话人片段列表
+
+## Usage
+
+```python
+from pyannote.audio import Pipeline
+pipeline = Pipeline.from_pretrained(
+    "pyannote/speaker-diarization-3.1",
+    use_auth_token=hf_token
+)
+diarization = pipeline(audio_path, num_speakers=2)  # num_speakers 可选
+for turn, _, speaker in diarization.itertracks(yield_label=True):
+    print(f"{speaker}: [{turn.start:.1f}s - {turn.end:.1f}s]")
+```
+
+## Connections
+- [[OpenAIWhisper]] / [[FasterWhisper]] — 配套转录工具，分离结果与转录段落合并
+- [[SpeakerDiarization]] — pyannote.audio 是该概念的参考实现
+- [[AssemblyAI]] — 云端 ASR 替代（内置说话人分离）
+- [[Deepgram]] — 另一云端 ASR 替代（内置说话人分离）
+
+## Sources
+- [[engineering-voice-ai-integration-engineer]]
diff --git a/wiki/entities/도장.md b/wiki/entities/도장.md
new file mode 100644
index 00000000..07425101
--- /dev/null
+++ b/wiki/entities/도장.md
@@ -0,0 +1,56 @@
+---
+title: "도장"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-05-30
+---
+
+## 基本信息
+- **原文**：도장（印章）
+- **类型**：商业工具 / 法律凭证
+- **中文**：印章 / 公章
+- **发音**：dojang
+
+## 定义
+도장（印章）是韩国商业合同执行的核心物理凭证，具有法律效力。在품의流程的最后阶段（계약 / 合同），除了电子或纸质合同文本外，还需要在合同上加盖公司印章（公司章）和法定代表人印章（私章）才算正式生效。
+
+## 韩国印章的类型
+
+| 类型 | 韩文 | 用途 | 法律效力 |
+|------|------|------|---------|
+| 公司章 | 법인인감 | 对外合同、正式文件 | 高 |
+| 私章/手章 | 인감 | 法定代表人签字 | 高 |
+| 小章 | 소인 | 内部审批、部门使用 | 低 |
+
+## 在合同流程中的位置
+
+```
+품의 결재라인 → 계약 성사
+  → Legal Review（法律审查）
+  → 도장 날인（盖章）
+  → 계약 성립（合同成立）
+```
+
+**关键理解**：合同谈判完成 ≠ 合同已签署。盖章阶段可能还需要等待联系人预约法定代表人时间，尤其在大型企业。
+
+## 对外国供应商的影响
+1. **时间不确定性**：法定代表人（代表理事）可能在外地或日程繁忙
+2. **无法催促**：盖章是正式仪式，过度催促是失礼行为
+3. **心理预期**：即使谈判顺利，印章等待期可能需要 1-2 周
+4. **电子化趋势**：部分韩国公司已开始采用电子合同（전자계약），但纸质印章仍是主流
+
+## 实际观察
+- 도장签署通常在合同谈判完成后的 1-2 周内完成
+- 在财阀企业，联系人在取得法人章之前需要层层汇报
+- SME 通常由代表理事直接持有私章，流程更快
+
+## Aliases
+- 印章
+- 公司印章
+- 法人인감
+- Korean Company Seal
+- Corporate Stamp
+
+## 来源
+- [[specialized-korean-business-navigator]] — 품의 Approval Process Timeline 中"계약"（合同）阶段对 도장 的说明
diff --git a/wiki/index.md b/wiki/index.md
index c94e942c..7ae54794 100644
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -4,6 +4,25 @@
 - [Overview](overview.md) — living synthesis
 
 ## Sources
+- [2026-05-01] [WSL2 中 Docker 容器访问宿主机代理](sources/WSL2-中-Docker-容器访问宿主机代理.md)
+- [2026-05-01] [Scrapy + Playwright 抓取TikTok Shop Data](sources/Scrapy---Playwright-抓取TikTok-Shop-Data.md)
+- [2026-05-01] [Hermes Agent 配置笔记](sources/Hermes-Agent-配置笔记.md)
+- [2026-05-01] [Your AI Isn't \"Stupid\" — It Just Needs a Better Harness | Lychee Technology Engineering Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md)
+- [2026-05-01] [Expose hermes-agent as an OpenAI-compatible API for any frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md)
+- [2026-05-01] [n8n Docker 配置 Telegram 代理 Troubleshooting](sources/n8n-docker-配置-telegram-代理-troubleshooting.md)
+- [2026-05-01] [Open WebUI | Hermes Agent](sources/open-webui-hermes-agent.md)
+- [2026-05-01] [SRE Weekly Issue #513](sources/sre-weekly-issue-513.md)
+- [2026-05-01] [n8n调用openclaw/hermes agents的工作流架构](sources/n8n调用hermes-agents的工作流架构.md)
+- [2026-05-01] [n8n 调用 OpenClaw Agents 的工作流架构](sources/n8n-调用openclaw-agents的工作流架构.md)
+- [2026-05-01] [Voice AI Integration Engineer](sources/engineering-voice-ai-integration-engineer.md)
+- [2026-05-01] [Codebase Onboarding Engineer](sources/engineering-codebase-onboarding-engineer.md)
+- [2026-05-01] [Minimal Change Engineer Agent](sources/engineering-minimal-change-engineer.md)
+- [2026-05-01] [Bookkeeper & Controller Agent](sources/finance-bookkeeper-controller.md)
+- [2026-05-01] [FP&A Analyst Agent](sources/finance-fpa-analyst.md)
+- [2026-05-01] [Investment Researcher Agent](sources/finance-investment-researcher.md)
+- [2026-05-01] [Financial Analyst Agent](sources/finance-financial-analyst.md)
+- [2026-05-01] [Tax Strategist Agent](sources/finance-tax-strategist.md)
+- [2026-05-01] [Agentic Search Optimizer](sources/marketing-agentic-search-optimizer.md)
 - [2026-05-01] [Qwen Code Integration](sources/readme.md)
 - [2026-05-01] [Qwen Code Integration](sources/readme.md)
 - [2026-05-01] [Language Translator](sources/language-translator.md)
@@ -511,25 +530,6 @@
 - [2026-04-26] [Cloud Maturity Model - A Detailed Guide For Cloud Adoption](sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md)
 - [2026-04-26] [Cloud DevOp Maturity - Guideline](sources/cloud-devop-maturity-guideline.md)
 - [2026-04-26] [DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation](sources/devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin.md)
-- [WSL2-中-Docker-容器访问宿主机代理](sources/WSL2-中-Docker-容器访问宿主机代理.md) — (expected: wiki/sources/WSL2-中-Docker-容器访问宿主机代理.md — source missing)
-- [Scrapy + Playwright 抓取TikTok Shop Data](sources/scrapy-playwright-抓取tiktok-shop-data.md)
-- [Hermes-Agent-配置笔记](sources/Hermes-Agent-配置笔记.md) — (expected: wiki/sources/Hermes-Agent-配置笔记.md — source missing)
-- [n8n-docker-配置-telegram-代理-troubleshooting](sources/n8n-docker-配置-telegram-代理-troubleshooting.md) — (expected: wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md — source missing)
-- [sre-weekly-issue-513](sources/sre-weekly-issue-513.md) — (expected: wiki/sources/sre-weekly-issue-513.md — source missing)
-- [n8n调用hermes-agents的工作流架构](sources/n8n调用hermes-agents的工作流架构.md) — (expected: wiki/sources/n8n调用hermes-agents的工作流架构.md — source missing)
-- [n8n-调用openclaw-agents的工作流架构](sources/n8n-调用openclaw-agents的工作流架构.md) — (expected: wiki/sources/n8n-调用openclaw-agents的工作流架构.md — source missing)
-- [2026-05-02] [Agentic Search Optimizer](sources/marketing-agentic-search-optimizer.md) — AI 浏览器 Agent 任务完成率优化：基于 WebMCP 声明式/命令式模式，让 AI Agent 在网站上真正完成预订、购买、注册等操作
-- [finance-tax-strategist](sources/finance-tax-strategist.md) — (expected: wiki/sources/finance-tax-strategist.md — source missing)
-- [finance-investment-researcher](sources/finance-investment-researcher.md) — (expected: wiki/sources/finance-investment-researcher.md — source missing)
-- [finance-fpa-analyst](sources/finance-fpa-analyst.md) — (expected: wiki/sources/finance-fpa-analyst.md — source missing)
-- [finance-financial-analyst](sources/finance-financial-analyst.md) — (expected: wiki/sources/finance-financial-analyst.md — source missing)
-- [finance-bookkeeper-controller](sources/finance-bookkeeper-controller.md) — (expected: wiki/sources/finance-bookkeeper-controller.md — source missing)
-- [engineering-voice-ai-integration-engineer](sources/engineering-voice-ai-integration-engineer.md) — (expected: wiki/sources/engineering-voice-ai-integration-engineer.md — source missing)
-- [engineering-minimal-change-engineer](sources/engineering-minimal-change-engineer.md) — (expected: wiki/sources/engineering-minimal-change-engineer.md — source missing)
-- [engineering-codebase-onboarding-engineer](sources/engineering-codebase-onboarding-engineer.md) — (expected: wiki/sources/engineering-codebase-onboarding-engineer.md — source missing)
-- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
-- [open-webui-hermes-agent](sources/open-webui-hermes-agent.md) — (expected: wiki/sources/open-webui-hermes-agent.md — source missing)
-- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
 
 ## Entities
 - [1point3acres](entities/1point3acres.md)
@@ -538,6 +538,7 @@
 - [ACI-318](entities/ACI-318.md)
 - [Acronis](entities/Acronis.md)
 - [AdamSmith](entities/AdamSmith.md)
+- [Adaptive-Capacity-Labs](entities/Adaptive-Capacity-Labs.md)
 - [ADK](entities/ADK.md)
 - [Adobe-Premiere-Pro](entities/Adobe-Premiere-Pro.md)
 - [AdsPower](entities/AdsPower.md)
@@ -578,6 +579,7 @@
 - [Anil-Giri](entities/Anil-Giri.md)
 - [Anki](entities/Anki.md)
 - [Anthropic](entities/Anthropic.md)
+- [AnythingLLM](entities/AnythingLLM.md)
 - [Apache-Hudi](entities/Apache-Hudi.md)
 - [Apache-Iceberg](entities/Apache-Iceberg.md)
 - [Apache-Kafka](entities/Apache-Kafka.md)
@@ -590,6 +592,7 @@
 - [Asana](entities/Asana.md)
 - [ASCE-7](entities/ASCE-7.md)
 - [Ashish](entities/Ashish.md)
+- [AssemblyAI](entities/AssemblyAI.md)
 - [Atlantis](entities/Atlantis.md)
 - [Automation-Governance-Architect](entities/Automation-Governance-Architect.md)
 - [AWS](entities/AWS.md)
@@ -639,6 +642,7 @@
 - [Certora](entities/Certora.md)
 - [Chaebol](entities/Chaebol.md)
 - [Charlie-Munger](entities/Charlie-Munger.md)
+- [ChatBox](entities/ChatBox.md)
 - [ChatGPT](entities/ChatGPT.md)
 - [Checkpoint](entities/Checkpoint.md)
 - [Checkpoint-Firewall](entities/Checkpoint-Firewall.md)
@@ -680,6 +684,7 @@
 - [CustomerMatch](entities/CustomerMatch.md)
 - [CyberArk](entities/CyberArk.md)
 - [Damian](entities/Damian.md)
+- [Dana](entities/Dana.md)
 - [DanielStefanovic](entities/DanielStefanovic.md)
 - [Databricks](entities/Databricks.md)
 - [Databunker](entities/Databunker.md)
@@ -688,6 +693,7 @@
 - [DaVinci-Resolve](entities/DaVinci-Resolve.md)
 - [dbt](entities/dbt.md)
 - [Decopy](entities/Decopy.md)
+- [Deepgram](entities/Deepgram.md)
 - [DeepLearningAI](entities/DeepLearningAI.md)
 - [DeepSeek](entities/DeepSeek.md)
 - [DeepSider](entities/DeepSider.md)
@@ -721,6 +727,7 @@
 - [Eurocode](entities/Eurocode.md)
 - [EvidenceQA](entities/EvidenceQA.md)
 - [FBA](entities/FBA.md)
+- [ffmpeg](entities/ffmpeg.md)
 - [Fibos](entities/Fibos.md)
 - [Filos-Christolakis](entities/Filos-Christolakis.md)
 - [Final-Cut-Pro](entities/Final-Cut-Pro.md)
@@ -769,6 +776,7 @@
 - [Heather-Norris](entities/Heather-Norris.md)
 - [hello-world](entities/hello-world.md)
 - [HemantSawant](entities/HemantSawant.md)
+- [Hermes-Agent](entities/Hermes-Agent.md)
 - [HIPAA](entities/HIPAA.md)
 - [Honcho](entities/Honcho.md)
 - [HP-ZBook](entities/HP-ZBook.md)
@@ -784,6 +792,7 @@
 - [iPod](entities/iPod.md)
 - [ISO-27001](entities/ISO-27001.md)
 - [it-tools](entities/it-tools.md)
+- [Jan](entities/Jan.md)
 - [Jared-Diamond](entities/Jared-Diamond.md)
 - [Jay-Comer](entities/Jay-Comer.md)
 - [Jellyfin](entities/Jellyfin.md)
@@ -791,6 +800,7 @@
 - [JimLiu](entities/JimLiu.md)
 - [Jira](entities/Jira.md)
 - [Jira-Workflow-Steward](entities/Jira-Workflow-Steward.md)
+- [John-Allspaw](entities/John-Allspaw.md)
 - [JohnWilliams](entities/JohnWilliams.md)
 - [JosephCampbell](entities/JosephCampbell.md)
 - [JP](entities/JP.md)
@@ -810,11 +820,14 @@
 - [Last-30-Days-Skill](entities/Last-30-Days-Skill.md)
 - [LaunchDarkly](entities/LaunchDarkly.md)
 - [LeonardoDaVinci](entities/LeonardoDaVinci.md)
+- [LibreChat](entities/LibreChat.md)
 - [Linear](entities/Linear.md)
 - [LinkedIn-Campaign-Manager](entities/LinkedIn-Campaign-Manager.md)
 - [LinuxServer.io](entities/LinuxServer.io.md)
+- [LobeChat](entities/LobeChat.md)
 - [LSIF](entities/LSIF.md)
 - [LuxuryDeveloper](entities/LuxuryDeveloper.md)
+- [Lychee-Technology](entities/Lychee-Technology.md)
 - [Mac](entities/Mac.md)
 - [Mac-Mini-M4](entities/Mac-Mini-M4.md)
 - [Mackinder](entities/Mackinder.md)
@@ -825,6 +838,7 @@
 - [MariaDB](entities/MariaDB.md)
 - [Martin-Nash](entities/Martin-Nash.md)
 - [Martin-Rosler](entities/Martin-Rosler.md)
+- [Marty-Cagan](entities/Marty-Cagan.md)
 - [Mary-Douglas](entities/Mary-Douglas.md)
 - [Matt-Van-Horne](entities/Matt-Van-Horne.md)
 - [MCCLevelStrategy](entities/MCCLevelStrategy.md)
@@ -863,6 +877,7 @@
 - [NetcodeForGameObjects](entities/NetcodeForGameObjects.md)
 - [Netdata](entities/Netdata.md)
 - [Netflix](entities/Netflix.md)
+- [NextChat](entities/NextChat.md)
 - [NEXUS](entities/NEXUS.md)
 - [Nexus-Spatial](entities/Nexus-Spatial.md)
 - [NicholasCarlini](entities/NicholasCarlini.md)
@@ -893,6 +908,7 @@
 - [OpenManus](entities/OpenManus.md)
 - [OpenNotebook](entities/OpenNotebook.md)
 - [OpenText](entities/OpenText.md)
+- [OpenWebUI](entities/OpenWebUI.md)
 - [OpenZeppelin](entities/OpenZeppelin.md)
 - [OrchestratorAgent](entities/OrchestratorAgent.md)
 - [OWASP](entities/OWASP.md)
@@ -922,6 +938,7 @@
 - [Public-Cloud-Provider](entities/Public-Cloud-Provider.md)
 - [Pulse-VPN](entities/Pulse-VPN.md)
 - [Pushka](entities/Pushka.md)
+- [pyannote.audio](entities/pyannote.audio.md)
 - [Qalis](entities/Qalis.md)
 - [QALIS-Agent](entities/QALIS-Agent.md)
 - [Qdrant](entities/Qdrant.md)
@@ -939,6 +956,7 @@
 - [Recapio](entities/Recapio.md)
 - [Rectangle](entities/Rectangle.md)
 - [RetroBoard](entities/RetroBoard.md)
+- [Richard-Cook](entities/Richard-Cook.md)
 - [Richard-Feynman](entities/Richard-Feynman.md)
 - [RichardFeynman](entities/RichardFeynman.md)
 - [RobertMcKee](entities/RobertMcKee.md)
@@ -948,6 +966,7 @@
 - [rsvg-convert](entities/rsvg-convert.md)
 - [rsync](entities/rsync.md)
 - [Rufus](entities/Rufus.md)
+- [RunLLM](entities/RunLLM.md)
 - [RustDesk](entities/RustDesk.md)
 - [Salesforce](entities/Salesforce.md)
 - [SAM-Serverless-Application-Model](entities/SAM-Serverless-Application-Model.md)
@@ -1047,6 +1066,7 @@
 - [WeChat](entities/WeChat.md)
 - [WeCom](entities/WeCom.md)
 - [Weibo](entities/Weibo.md)
+- [Werner-Vogels](entities/Werner-Vogels.md)
 - [Whimsy-Injector](entities/Whimsy-Injector.md)
 - [WildCard](entities/WildCard.md)
 - [Windsurf](entities/Windsurf.md)
@@ -1098,12 +1118,14 @@
 - [3-2-1产品介绍公式](concepts/3-2-1产品介绍公式.md)
 - [4-Level-Semantic-Zoom](concepts/4-Level-Semantic-Zoom.md)
 - [6-Slide-Narrative-Arc](concepts/6-Slide-Narrative-Arc.md)
+- [7-Layer-Harness-Stack](concepts/7-Layer-Harness-Stack.md)
 - [7种视觉风格系统](concepts/7种视觉风格系统.md)
 - [ABM-Display](concepts/ABM-Display.md)
 - [ABTesting](concepts/ABTesting.md)
 - [Access-Control](concepts/Access-Control.md)
 - [Account-Health-Score](concepts/Account-Health-Score.md)
 - [Account-Monitoring](concepts/Account-Monitoring.md)
+- [Account-Reconciliation](concepts/Account-Reconciliation.md)
 - [Account-Tiering-Model](concepts/Account-Tiering-Model.md)
 - [AccountArchitecture](concepts/AccountArchitecture.md)
 - [ACOS](concepts/ACOS.md)
@@ -1125,11 +1147,13 @@
 - [Agent](concepts/Agent.md)
 - [Agent-Build-Gate](concepts/Agent-Build-Gate.md)
 - [Agent-Collaboration-Protocol](concepts/Agent-Collaboration-Protocol.md)
+- [Agent-Collapse](concepts/Agent-Collapse.md)
 - [Agent-Design-Principles](concepts/Agent-Design-Principles.md)
 - [Agent-Driven-Market-Research](concepts/Agent-Driven-Market-Research.md)
 - [Agent-Handoff](concepts/Agent-Handoff.md)
 - [Agent-Memory](concepts/Agent-Memory.md)
 - [Agent-Mode](concepts/Agent-Mode.md)
+- [Agent-Orchestration](concepts/Agent-Orchestration.md)
 - [Agent-Personality](concepts/Agent-Personality.md)
 - [Agent-Routing-Rules](concepts/Agent-Routing-Rules.md)
 - [Agent-Specialization](concepts/Agent-Specialization.md)
@@ -1150,6 +1174,7 @@
 - [AI-Auto-Response](concepts/AI-Auto-Response.md)
 - [AI-ChatOps](concepts/AI-ChatOps.md)
 - [AI-Driven-Task-Extraction](concepts/AI-Driven-Task-Extraction.md)
+- [AI-For-On-Call](concepts/AI-For-On-Call.md)
 - [AI-Logo-Generation](concepts/AI-Logo-Generation.md)
 - [Ai-Powered-Digest](concepts/Ai-Powered-Digest.md)
 - [AIFinOps](concepts/AIFinOps.md)
@@ -1194,6 +1219,7 @@
 - [Attach容器](concepts/Attach容器.md)
 - [Attention-Economy](concepts/Attention-Economy.md)
 - [AudienceStrategy](concepts/AudienceStrategy.md)
+- [Audit-Readiness](concepts/Audit-Readiness.md)
 - [Audit-Trail](concepts/Audit-Trail.md)
 - [Aurora-Global](concepts/Aurora-Global.md)
 - [Automated-Health-Logging](concepts/Automated-Health-Logging.md)
@@ -1203,6 +1229,7 @@
 - [Automation-Decision-Framework](concepts/Automation-Decision-Framework.md)
 - [Automation-Verdict-System](concepts/Automation-Verdict-System.md)
 - [AutomationGovernance](concepts/AutomationGovernance.md)
+- [Autoscaling](concepts/Autoscaling.md)
 - [Availability](concepts/Availability.md)
 - [Availability-Zone-ID](concepts/Availability-Zone-ID.md)
 - [AWS-Backup-Concepts](concepts/AWS-Backup-Concepts.md)
@@ -1218,10 +1245,12 @@
 - [AWS-Tagging-Standards](concepts/AWS-Tagging-Standards.md)
 - [AWS-Tags](concepts/AWS-Tags.md)
 - [B2B-Social-Selling](concepts/B2B-Social-Selling.md)
+- [Background-Job-Scheduling](concepts/Background-Job-Scheduling.md)
 - [Backlinks](concepts/Backlinks.md)
 - [Baidu-Ecosystem-Integration](concepts/Baidu-Ecosystem-Integration.md)
 - [Baidu-SEO](concepts/Baidu-SEO.md)
 - [BandwidthManagement](concepts/BandwidthManagement.md)
+- [Bearer-Token-Authentication](concepts/Bearer-Token-Authentication.md)
 - [Beat-Sync](concepts/Beat-Sync.md)
 - [BEATS](concepts/BEATS.md)
 - [Behavioral-Analytics](concepts/Behavioral-Analytics.md)
@@ -1290,6 +1319,7 @@
 - [Character-Arc](concepts/Character-Arc.md)
 - [Character-Voice-Pillars](concepts/Character-Voice-Pillars.md)
 - [CharacterArc](concepts/CharacterArc.md)
+- [ChatCompletions](concepts/ChatCompletions.md)
 - [Check-in-Fatigue](concepts/Check-in-Fatigue.md)
 - [CheckinFatigue](concepts/CheckinFatigue.md)
 - [Checks-Effects-Interactions](concepts/Checks-Effects-Interactions.md)
@@ -1334,6 +1364,7 @@
 - [CMDB](concepts/CMDB.md)
 - [Cockpit-Ergonomics](concepts/Cockpit-Ergonomics.md)
 - [Code-Signing](concepts/Code-Signing.md)
+- [CodebaseOnboarding](concepts/CodebaseOnboarding.md)
 - [CodeOverConfiguration](concepts/CodeOverConfiguration.md)
 - [CodeWeaver](concepts/CodeWeaver.md)
 - [Cognitive-Distortions](concepts/Cognitive-Distortions.md)
@@ -1370,9 +1401,11 @@
 - [Content-Pillar](concepts/Content-Pillar.md)
 - [ContentMixStrategy](concepts/ContentMixStrategy.md)
 - [ContentModel-first](concepts/ContentModel-first.md)
+- [Context-Anxiety](concepts/Context-Anxiety.md)
 - [Context-Cores](concepts/Context-Cores.md)
 - [Context-Engineering](concepts/Context-Engineering.md)
 - [Context-Passing](concepts/Context-Passing.md)
+- [Context-Reset](concepts/Context-Reset.md)
 - [Context-Substrate](concepts/Context-Substrate.md)
 - [Context-Window](concepts/Context-Window.md)
 - [ContextDrivenTask](concepts/ContextDrivenTask.md)
@@ -1382,10 +1415,13 @@
 - [Continuous-Dev-QA-Loop](concepts/Continuous-Dev-QA-Loop.md)
 - [Continuous-Integration](concepts/Continuous-Integration.md)
 - [ControllingIdea](concepts/ControllingIdea.md)
+- [Conversation-State-Persistence](concepts/Conversation-State-Persistence.md)
 - [Conversational-Interface](concepts/Conversational-Interface.md)
 - [Conversions-API](concepts/Conversions-API.md)
 - [Core-Gameplay-Loop](concepts/Core-Gameplay-Loop.md)
 - [CoreDNS-Scaling](concepts/CoreDNS-Scaling.md)
+- [CORS-Allowlist](concepts/CORS-Allowlist.md)
+- [Cost-As-Distributed-Systems-Bug](concepts/Cost-As-Distributed-Systems-Bug.md)
 - [cost-of-delay](concepts/cost-of-delay.md)
 - [Cost-Optimization](concepts/Cost-Optimization.md)
 - [Counterfactual-Analysis](concepts/Counterfactual-Analysis.md)
@@ -1460,6 +1496,7 @@
 - [Docker-Daemon-Proxy](concepts/Docker-Daemon-Proxy.md)
 - [Docker-LLM-Deployment](concepts/Docker-LLM-Deployment.md)
 - [Docker-用户组](concepts/Docker-用户组.md)
+- [DockerHostNetworking](concepts/DockerHostNetworking.md)
 - [Docker堆栈](concepts/Docker堆栈.md)
 - [Docker容器生命周期管理](concepts/Docker容器生命周期管理.md)
 - [Docker警告处理](concepts/Docker警告处理.md)
@@ -1481,6 +1518,7 @@
 - [Early-Live-Support](concepts/Early-Live-Support.md)
 - [Earnings-Beat-Miss](concepts/Earnings-Beat-Miss.md)
 - [Earnings-Calendar](concepts/Earnings-Calendar.md)
+- [EBUR128LoudnessNormalization](concepts/EBUR128LoudnessNormalization.md)
 - [EC2-Purchase-Options](concepts/EC2-Purchase-Options.md)
 - [EC2-Spot-Instances](concepts/EC2-Spot-Instances.md)
 - [Echidna](concepts/Echidna.md)
@@ -1489,10 +1527,12 @@
 - [ECS-Deploy-Runner](concepts/ECS-Deploy-Runner.md)
 - [ECS-Module](concepts/ECS-Module.md)
 - [EditorialWorkflow](concepts/EditorialWorkflow.md)
+- [EffectiveTaxRate](concepts/EffectiveTaxRate.md)
 - [efibootmgr](concepts/efibootmgr.md)
 - [EFS-vs-EBS](concepts/EFS-vs-EBS.md)
 - [EKS-Auto-Mode](concepts/EKS-Auto-Mode.md)
 - [EKS-Custom-Networking](concepts/EKS-Custom-Networking.md)
+- [Elasticity](concepts/Elasticity.md)
 - [ELK-Stack](concepts/ELK-Stack.md)
 - [Email-Triage](concepts/Email-Triage.md)
 - [Embedding](concepts/Embedding.md)
@@ -1517,6 +1557,8 @@
 - [Evidence-Chain](concepts/Evidence-Chain.md)
 - [Evidence-Over-Claims](concepts/Evidence-Over-Claims.md)
 - [EvidenceCollection](concepts/EvidenceCollection.md)
+- [EvidenceFirstReasoning](concepts/EvidenceFirstReasoning.md)
+- [ExecutionTracing](concepts/ExecutionTracing.md)
 - [Executive-Summary-Formula](concepts/Executive-Summary-Formula.md)
 - [Expert-User-Assumption](concepts/Expert-User-Assumption.md)
 - [Exporter](concepts/Exporter.md)
@@ -1532,6 +1574,7 @@
 - [Fairness-Audit](concepts/Fairness-Audit.md)
 - [False-Cognates](concepts/False-Cognates.md)
 - [Fan-Out-Pattern](concepts/Fan-Out-Pattern.md)
+- [FasterWhisper](concepts/FasterWhisper.md)
 - [Feature-Flag](concepts/Feature-Flag.md)
 - [FeatureList](concepts/FeatureList.md)
 - [Federated-Access](concepts/Federated-Access.md)
@@ -1564,6 +1607,7 @@
 - [FullDraftGeneration](concepts/FullDraftGeneration.md)
 - [Functionalism](concepts/Functionalism.md)
 - [Fuzzy-Matching](concepts/Fuzzy-Matching.md)
+- [GAAP-Compliance](concepts/GAAP-Compliance.md)
 - [Gamification](concepts/Gamification.md)
 - [Gamification-System](concepts/Gamification-System.md)
 - [GapAssessment](concepts/GapAssessment.md)
@@ -1613,6 +1657,7 @@
 - [Hand-Tracking](concepts/Hand-Tracking.md)
 - [Handoff-Boundary](concepts/Handoff-Boundary.md)
 - [Handoff-Contract](concepts/Handoff-Contract.md)
+- [Harness-Engineering](concepts/Harness-Engineering.md)
 - [HCX](concepts/HCX.md)
 - [HDRP](concepts/HDRP.md)
 - [Headless-服务器](concepts/Headless-服务器.md)
@@ -1632,6 +1677,7 @@
 - [Host-Incubation-System](concepts/Host-Incubation-System.md)
 - [Host-Network-Mode](concepts/Host-Network-Mode.md)
 - [HouseholdInventoryTracking](concepts/HouseholdInventoryTracking.md)
+- [HTTP-ChatCompletions](concepts/HTTP-ChatCompletions.md)
 - [HTTPS自动化证书](concepts/HTTPS自动化证书.md)
 - [Hub-and-Spoke](concepts/Hub-and-Spoke.md)
 - [Human-Centered-Design](concepts/Human-Centered-Design.md)
@@ -1680,6 +1726,7 @@
 - [Intent-Classification](concepts/Intent-Classification.md)
 - [IntentDrivenRouting](concepts/IntentDrivenRouting.md)
 - [Intentional-Cloud-Strategy](concepts/Intentional-Cloud-Strategy.md)
+- [Internal-Controls](concepts/Internal-Controls.md)
 - [Intersectionality](concepts/Intersectionality.md)
 - [Inversion](concepts/Inversion.md)
 - [INVEST](concepts/INVEST.md)
@@ -1698,6 +1745,7 @@
 - [JFFS双清](concepts/JFFS双清.md)
 - [Jira-Gate](concepts/Jira-Gate.md)
 - [Jira-Git-Traceability](concepts/Jira-Git-Traceability.md)
+- [Journal-Entry](concepts/Journal-Entry.md)
 - [Kaizen](concepts/Kaizen.md)
 - [Kanban](concepts/Kanban.md)
 - [Karpenter](concepts/Karpenter.md)
@@ -1748,6 +1796,7 @@
 - [LLM-as-a-Judge](concepts/LLM-as-a-Judge.md)
 - [LLM-Wiki](concepts/LLM-Wiki.md)
 - [LLMasJudge](concepts/LLMasJudge.md)
+- [LLMHandoff](concepts/LLMHandoff.md)
 - [LLMWikiArchitecture](concepts/LLMWikiArchitecture.md)
 - [Local-Caching](concepts/Local-Caching.md)
 - [Local-first-Git](concepts/Local-first-Git.md)
@@ -1781,8 +1830,10 @@
 - [MeetingNotes](concepts/MeetingNotes.md)
 - [Memory-Backend](concepts/Memory-Backend.md)
 - [Memory-Based-Handoff](concepts/Memory-Based-Handoff.md)
+- [Memory-Consolidation](concepts/Memory-Consolidation.md)
 - [MEMORY.md](concepts/MEMORY.md.md)
 - [MemoryInAIAgents](concepts/MemoryInAIAgents.md)
+- [MentalModel](concepts/MentalModel.md)
 - [Merge-Point](concepts/Merge-Point.md)
 - [Mermaid](concepts/Mermaid.md)
 - [MessageMatch](concepts/MessageMatch.md)
@@ -1794,12 +1845,15 @@
 - [Micro-Sprint](concepts/Micro-Sprint.md)
 - [Microhistory](concepts/Microhistory.md)
 - [MicroInfluencerPartnership](concepts/MicroInfluencerPartnership.md)
+- [MinimalChangePrinciple](concepts/MinimalChangePrinciple.md)
+- [Minimum-Viable-Harness](concepts/Minimum-Viable-Harness.md)
 - [Miping](concepts/Miping.md)
 - [MLOps](concepts/MLOps.md)
 - [ModalContextProtocol](concepts/ModalContextProtocol.md)
 - [Model-Context-Protocol](concepts/Model-Context-Protocol.md)
 - [Model-Fallback](concepts/Model-Fallback.md)
 - [Momentum-Nudge](concepts/Momentum-Nudge.md)
+- [Month-End-Close-Process](concepts/Month-End-Close-Process.md)
 - [Morning-Briefing](concepts/Morning-Briefing.md)
 - [MoSCoW-Classification](concepts/MoSCoW-Classification.md)
 - [Motion-Sickness-Threshold](concepts/Motion-Sickness-Threshold.md)
@@ -1819,6 +1873,7 @@
 - [Multi-Cloud-Strategy](concepts/Multi-Cloud-Strategy.md)
 - [Multi-Database-Architecture](concepts/Multi-Database-Architecture.md)
 - [Multi-factor-Authentication](concepts/Multi-factor-Authentication.md)
+- [Multi-Profile-Isolation](concepts/Multi-Profile-Isolation.md)
 - [Multi-Tenancy](concepts/Multi-Tenancy.md)
 - [Multi-Window-Architecture](concepts/Multi-Window-Architecture.md)
 - [MVP](concepts/MVP.md)
@@ -1852,6 +1907,7 @@
 - [Note-Database-Queries](concepts/Note-Database-Queries.md)
 - [NoteDatabase](concepts/NoteDatabase.md)
 - [Nudge-Sequence](concepts/Nudge-Sequence.md)
+- [NUMA](concepts/NUMA.md)
 - [Nunchi](concepts/Nunchi.md)
 - [NVMe硬盘分区](concepts/NVMe硬盘分区.md)
 - [Observability](concepts/Observability.md)
@@ -1866,6 +1922,8 @@
 - [ObsidianRecurringTasks](concepts/ObsidianRecurringTasks.md)
 - [Oli-Workflow](concepts/Oli-Workflow.md)
 - [OneFilePerActor](concepts/OneFilePerActor.md)
+- [OpenAI-Compatible-API](concepts/OpenAI-Compatible-API.md)
+- [OpenAI兼容API](concepts/OpenAI兼容API.md)
 - [OpenClaw-Deployment-Expert](concepts/OpenClaw-Deployment-Expert.md)
 - [OpenTelemetry](concepts/OpenTelemetry.md)
 - [OpenText-Tagging-Standard](concepts/OpenText-Tagging-Standard.md)
@@ -1873,9 +1931,11 @@
 - [Orchestration](concepts/Orchestration.md)
 - [Ordered-Layer](concepts/Ordered-Layer.md)
 - [Organic-Traffic-Amplification](concepts/Organic-Traffic-Amplification.md)
+- [Organizational-Second-Hit-Syndrome](concepts/Organizational-Second-Hit-Syndrome.md)
 - [OS-End-of-Life](concepts/OS-End-of-Life.md)
 - [OS-Hardening](concepts/OS-Hardening.md)
 - [Outcome-vs-Output](concepts/Outcome-vs-Output.md)
+- [OverlapAwareChunking](concepts/OverlapAwareChunking.md)
 - [Overlay-Network](concepts/Overlay-Network.md)
 - [Override-Status](concepts/Override-Status.md)
 - [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md)
@@ -1909,6 +1969,7 @@
 - [Personalization](concepts/Personalization.md)
 - [PersuasionArchitecture](concepts/PersuasionArchitecture.md)
 - [Photography-Terminology](concepts/Photography-Terminology.md)
+- [PIIRedaction](concepts/PIIRedaction.md)
 - [Pipeline](concepts/Pipeline.md)
 - [Pipeline-State-Management](concepts/Pipeline-State-Management.md)
 - [PipelineVelocity](concepts/PipelineVelocity.md)
@@ -1934,6 +1995,7 @@
 - [Pre-commit-Hooks](concepts/Pre-commit-Hooks.md)
 - [PreBuildValidation](concepts/PreBuildValidation.md)
 - [Predictive-Maintenance](concepts/Predictive-Maintenance.md)
+- [PrematureAbstraction](concepts/PrematureAbstraction.md)
 - [Presentism](concepts/Presentism.md)
 - [Prisma-Access](concepts/Prisma-Access.md)
 - [Private-Cloud](concepts/Private-Cloud.md)
@@ -2024,9 +2086,11 @@
 - [Requirements-Gathering](concepts/Requirements-Gathering.md)
 - [Research-Triangulation](concepts/Research-Triangulation.md)
 - [ReservedInstances](concepts/ReservedInstances.md)
+- [Resilience](concepts/Resilience.md)
 - [Resolver-Rules](concepts/Resolver-Rules.md)
 - [Resource-Allocation](concepts/Resource-Allocation.md)
 - [Resource-Tagging](concepts/Resource-Tagging.md)
+- [ResponsesAPI](concepts/ResponsesAPI.md)
 - [Responsible-AI](concepts/Responsible-AI.md)
 - [Responsive-Breakpoints](concepts/Responsive-Breakpoints.md)
 - [ResponsiveSearchAds](concepts/ResponsiveSearchAds.md)
@@ -2064,7 +2128,9 @@
 - [Scheduled-Reminder](concepts/Scheduled-Reminder.md)
 - [Scheduled-Task-Flywheel](concepts/Scheduled-Task-Flywheel.md)
 - [ScheduledReport](concepts/ScheduledReport.md)
+- [Schema-Drift](concepts/Schema-Drift.md)
 - [Scholar-Skill](concepts/Scholar-Skill.md)
+- [ScopeCreep](concepts/ScopeCreep.md)
 - [SCP-Security-Control-Policy](concepts/SCP-Security-Control-Policy.md)
 - [SCRM](concepts/SCRM.md)
 - [Scrum](concepts/Scrum.md)
@@ -2080,7 +2146,9 @@
 - [Security-and-Compliance](concepts/Security-and-Compliance.md)
 - [Security-Engineering-Concepts](concepts/Security-Engineering-Concepts.md)
 - [Security-Group-Policy](concepts/Security-Group-Policy.md)
+- [Segregation-Of-Duties](concepts/Segregation-Of-Duties.md)
 - [Self-Education](concepts/Self-Education.md)
+- [Self-Grading-Illusion](concepts/Self-Grading-Illusion.md)
 - [Self-Healing](concepts/Self-Healing.md)
 - [Self-Healing System](concepts/Self-Healing System.md)
 - [Self-Healing-Systems](concepts/Self-Healing-Systems.md)
@@ -2154,14 +2222,17 @@
 - [Spatial-Widgets](concepts/Spatial-Widgets.md)
 - [SpatialAIOps](concepts/SpatialAIOps.md)
 - [SpatialAudio](concepts/SpatialAudio.md)
+- [SpeakerDiarization](concepts/SpeakerDiarization.md)
 - [Speed-Ramping](concepts/Speed-Ramping.md)
 - [Speedrun-Design](concepts/Speedrun-Design.md)
 - [Split](concepts/Split.md)
 - [Spot-Instances](concepts/Spot-Instances.md)
 - [SpotInstances](concepts/SpotInstances.md)
 - [SPREAD-Strategy](concepts/SPREAD-Strategy.md)
+- [Sprint-Contract](concepts/Sprint-Contract.md)
 - [SprintPlanning](concepts/SprintPlanning.md)
 - [SRE](concepts/SRE.md)
+- [SSE](concepts/SSE.md)
 - [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md)
 - [SSM-Patching](concepts/SSM-Patching.md)
 - [StackSets-Deployment-Visibility](concepts/StackSets-Deployment-Visibility.md)
@@ -2170,6 +2241,7 @@
 - [Standard-Change](concepts/Standard-Change.md)
 - [STARFramework](concepts/STARFramework.md)
 - [Startup-MVP-Pipeline](concepts/Startup-MVP-Pipeline.md)
+- [State-Externalization](concepts/State-Externalization.md)
 - [Static-Routing](concepts/Static-Routing.md)
 - [Statistical-Analysis](concepts/Statistical-Analysis.md)
 - [Statistical-Process-Control](concepts/Statistical-Process-Control.md)
@@ -2181,6 +2253,7 @@
 - [Stretched-Cluster](concepts/Stretched-Cluster.md)
 - [Structuralism](concepts/Structuralism.md)
 - [StructuredInterview](concepts/StructuredInterview.md)
+- [StructuredTranscriptJSON](concepts/StructuredTranscriptJSON.md)
 - [StudyVault](concepts/StudyVault.md)
 - [StyleLock](concepts/StyleLock.md)
 - [StyleSeed](concepts/StyleSeed.md)
@@ -2198,6 +2271,7 @@
 - [SyntheticMonitoring](concepts/SyntheticMonitoring.md)
 - [System-Economy](concepts/System-Economy.md)
 - [system-monitoring](concepts/system-monitoring.md)
+- [System-Prompt-Layering](concepts/System-Prompt-Layering.md)
 - [systemd](concepts/systemd.md)
 - [T-Shaped-Skills](concepts/T-Shaped-Skills.md)
 - [Tag-Validation-Tool](concepts/Tag-Validation-Tool.md)
@@ -2241,6 +2315,7 @@
 - [Three-Tier-School-Selection](concepts/Three-Tier-School-Selection.md)
 - [ThreeActProposalNarrative](concepts/ThreeActProposalNarrative.md)
 - [ThreeActStructure](concepts/ThreeActStructure.md)
+- [ThreeTierExplanation](concepts/ThreeTierExplanation.md)
 - [TieredCampaignArchitecture](concepts/TieredCampaignArchitecture.md)
 - [Time-Boxing](concepts/Time-Boxing.md)
 - [Time-to-Market](concepts/Time-to-Market.md)
@@ -2252,6 +2327,7 @@
 - [ToolIntegration](concepts/ToolIntegration.md)
 - [ToolOrchestration](concepts/ToolOrchestration.md)
 - [TOOLS.md](concepts/TOOLS.md.md)
+- [ToolStreaming](concepts/ToolStreaming.md)
 - [ToolWrapper](concepts/ToolWrapper.md)
 - [Topic-Based-Routing](concepts/Topic-Based-Routing.md)
 - [TopicRouting](concepts/TopicRouting.md)
@@ -2260,6 +2336,7 @@
 - [TransactionalAnalysis](concepts/TransactionalAnalysis.md)
 - [Transcript-Based-Summarization](concepts/Transcript-Based-Summarization.md)
 - [TranscriptProcessing](concepts/TranscriptProcessing.md)
+- [TransferPricing](concepts/TransferPricing.md)
 - [Transit-Gateway](concepts/Transit-Gateway.md)
 - [Trauma-Informed-Analysis](concepts/Trauma-Informed-Analysis.md)
 - [Tree-of-Thoughts](concepts/Tree-of-Thoughts.md)
@@ -2306,6 +2383,7 @@
 - [VMware-Cloud-on-AWS](concepts/VMware-Cloud-on-AWS.md)
 - [Voice-Interface](concepts/Voice-Interface.md)
 - [Voice-Notification-Channel](concepts/Voice-Notification-Channel.md)
+- [VoiceActivityDetection](concepts/VoiceActivityDetection.md)
 - [VoiceProtection](concepts/VoiceProtection.md)
 - [VPC-Association-Authorization](concepts/VPC-Association-Authorization.md)
 - [VPC-Endpoint](concepts/VPC-Endpoint.md)
@@ -2333,6 +2411,7 @@
 - [Workspace](concepts/Workspace.md)
 - [WorldPartition](concepts/WorldPartition.md)
 - [WSP-Protocol](concepts/WSP-Protocol.md)
+- [X-Hermes-Session-Id](concepts/X-Hermes-Session-Id.md)
 - [X-Twitter-API-Automation](concepts/X-Twitter-API-Automation.md)
 - [X11](concepts/X11.md)
 - [Xinchuang](concepts/Xinchuang.md)
@@ -2376,6 +2455,7 @@
 - [图床](concepts/图床.md)
 - [均衡分发算法](concepts/均衡分发算法.md)
 - [增量备份](concepts/增量备份.md)
+- [多Profile隔离](concepts/多Profile隔离.md)
 - [多Provider图像生成](concepts/多Provider图像生成.md)
 - [多维度图像生成系统](concepts/多维度图像生成系统.md)
 - [天才地带](concepts/天才地带.md)
@@ -2384,6 +2464,7 @@
 - [安之若命](concepts/安之若命.md)
 - [容器资源限制](concepts/容器资源限制.md)
 - [容器重启策略](concepts/容器重启策略.md)
+- [工作流编排](concepts/工作流编排.md)
 - [工作流自动化](concepts/工作流自动化.md)
 - [并发编程](concepts/并发编程.md)
 - [底层能力](concepts/底层能力.md)
diff --git a/wiki/log.md b/wiki/log.md
index 6f7f9bbc..9de8a8f3 100644
--- a/wiki/log.md
+++ b/wiki/log.md
@@ -1,3 +1,141 @@
+## [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: ✅ 成功摄入
@@ -2409,4 +2547,31 @@
 - 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已追加。
diff --git a/wiki/overview.md b/wiki/overview.md
index 469a497e..d4d87e6b 100644
--- a/wiki/overview.md
+++ b/wiki/overview.md
@@ -4,8 +4,15 @@ This wiki is a living synthesis of curated sources spanning AI agents, cloud inf
 
 ## Major Themes
 
+**[[sre-weekly-issue-513]]**（SRE Weekly Issue #513）：SRE Weekly 第 513 期精选文章汇总，涵盖 8 篇 SRE 领域重要文章。核心主题：① [[Organizational-Second-Hit-Syndrome]]（[[Richard-Cook]] 和 [[John-Allspaw]] 在 [[Adaptive-Capacity-Labs]] 提出）——重大故障后的组织脆弱期，二次故障会引发强烈破坏性组织反应；② Netflix 在现代 CPU 上运行容器时面临 [[NUMA]] 和 2 万次挂载挑战，SRE 需关注全栈；③ [[Cost-As-Distributed-Systems-Bug]]——成本突增是可靠性问题的信号，成本异常应触发故障调查而非仅财务审查；④ [[Autoscaling]] vs [[Elasticity]]——Autoscaling 是被动的反应式机制，缺乏策略和测试会加剧故障；⑤ [[AI-For-On-Call]]（[[RunLLM]] 产品实践）——AI 最大价值在于为值班工程师提供上下文辅助，而非自主修复；⑥ [[Resilience]] 的 5 个不可自动化要素：学习、决策、优先级排序、沟通、适应。为 [[engineering-sre]] 和 [[engineering-incident-response-commander]] Agent 提供行业最新实践参考。
 ### Engineering Agents
 
+**[[engineering-devops-automator]]**（DevOps Automator Agent）：The Agency 工程部门的基础设施自动化与云运营专家 Agent——专注于消除手动运维流程、实现可扩展部署策略，核心理念：**"Automates infrastructure so your team ships faster and sleeps better."** 核心方法：基础设施即代码（Terraform/CloudFormation/CDK）→ CI/CD 流水线自动化（GitHub Actions/Jenkins/GitLab CI）→ 容器编排（Docker/Kubernetes）→ 零停机部署（蓝绿/金丝雀/滚动）→ Prometheus + Grafana 可观测性体系。关键成功指标：每日多次部署频率、MTTR < 30分钟、99.9% 可用性、100% 安全扫描通过率。与 [[engineering-backend-architect]] 互补——后端架构负责系统设计，DevOps Automator 负责将设计转化为可自动化运行的云基础设施；与 [[engineering-sre]] 互补——DevOps Automator 负责构建自动化基础设施，SRE 负责监控、错误预算决策和人工 on-call，两者协同构建完整生产系统可靠性体系。
+
+**[[engineering-sre]]**（SRE Agent）：The Agency 工程部门的网站可靠性工程师 Agent——将可靠性视为可量化预算的专业生产系统专家 Agent。核心理念：**"Reliability is a feature. Error budgets fund velocity — spend them wisely."** 核心使命：① SLOs 与错误预算——定义"可靠"标准，测量实际表现，通过错误预算驱动发布决策（SLO 达标则发布功能，耗尽则修复可靠性）；② 可观测性体系——Metrics（趋势/告警/SLO追踪）、Logs（事件调试）、Traces（跨服务请求链路）三支柱；③ Golden Signals 监控——Latency（延迟）、Traffic（流量）、Errors（错误）、Saturation（饱和度）四个最小必要监控信号；④ Toil 消除——将重复运维工作系统化自动化（重复两次则自动化）；⑤ 混沌工程——在用户发现前主动注入故障发现系统弱点；⑥ 容量规划——基于数据而非猜测的资源右限。关键规则：SLO 驱动决策、先测量再优化、自动化 Toil 不靠英雄、零责备故障文化（系统故障非个人错误）、渐进式发布（Canary → Percentage → Full，禁止大爆炸发布）。SRE Agent 的独特价值在于将工程纪律引入运维——每个 9（99.9% → 99.99%）的成本是前一个的 10 倍，错误预算是衡量可靠性投资的量化工具。与 [[engineering-devops-automator]] 互补而非矛盾——后者构建自动化基础设施，前者负责监控、SLO 决策和 on-call；与 [[engineering-incident-response-commander]] 互补——SRE 定义 SLO 和错误预算，事故指挥官负责在事故发生时执行结构化响应和复盘；与 [[CTP-Topic-41-NFRs-and-Error-Budgets]] 和 [[CTP-Topic-59-Achieving-Reliability-with-Amazon-EKS]] 共享错误预算与可靠性概念。
+
+**[[engineering-incident-response-commander]]**（Incident Response Commander Agent）：The Agency 工程部门的事故响应指挥官 Agent——将生产事故混乱转化为结构化解决的专业事故管理专家 Agent。核心理念：**"Preparation beats heroics."** 核心使命：① 结构化事故响应——SEV1–SEV4 分类框架（定义响应时间、升级路径、沟通节奏）、固定角色分工（IC/Communications Lead/Technical Lead/Scribe）、15 分钟时间盒假设验证；② 无责复盘文化——归因于系统缺陷而非个人错误，通过 5 Whys 和故障树分析找到系统性根因，48 小时内生成时间线+影响评估+行动项；③ SLO/SLI 体系——定义可测量可靠性指标，错误预算低于 25% 时暂停功能开发全力修复可靠性；④ On-Call 健康管理——至少 4 人轮换、每周不超过 5 次告警、SEV1 后强制休息，防止告警疲劳和工程师倦怠。关键规则：Runbook 每季度必须测试一次、On-call 工程师必须有应急处置权无需多级审批、复盘若无跟进只是会议。成功指标：MTTD < 5 分钟（SEV1/2）、MTTR < 30 分钟（SEV1）、100% SEV1/2 复盘完成率。与 [[engineering-sre]] 互补——SRE Agent 定义可靠性和 SLO 框架，事故指挥官负责在事故发生时驱动结构化响应和持续改进；与 [[CTP-Topic-41-NFRs-and-Error-Budgets]] 共享错误预算决策机制。
+
 **[[engineering-database-optimizer]]**（Database Optimizer Agent）：The Agency 工程部门的数据库性能优化专家 Agent——核心专长：PostgreSQL 优化和高级特性（EXPLAIN ANALYZE、查询计划解读）、B-tree/GiST/GIN/部分索引策略、Schema 设计（规范化 vs 反规范化权衡）、N+1 查询检测与解决、连接池管理（PgBouncer、Supabase pooler）、零停机迁移策略。支持 PostgreSQL、MySQL、Supabase 和 PlanetScale。关键规则：始终检查查询计划、外键必须加索引、避免 SELECT *、使用连接池、迁移必须可逆、生产环境永不锁表（使用 CONCURRENTLY）、防止 N+1 查询（使用 JOIN 替代循环）、监控慢查询（pg_stat_statements）。核心价值：提供可直接用于生产的 SQL 模板和 TypeScript 代码示例。与 [[engineering-backend-architect]] 存在依赖关系——后端架构师的设计决策需遵循数据库优化专家的原则。
 
 **[[engineering-senior-developer]]**（Senior Developer Agent）：The Agency 工程部门的高端 web 实现专家 Agent——专注于使用 Laravel/Livewire/FluxUI 实现"奢华感"（Premium）web 体验。核心理念：**"Every pixel should feel intentional and refined"**，性能与美感必须共存。核心要求：必须实现亮色/暗色/系统主题切换、大留白+精致排版、微交互动画（磁性按钮、流畅过渡）、玻璃拟态（glass morphism）视觉效果。技术栈：Laravel/Livewire 全栈框架、FluxUI 专业组件库、高级 CSS（glass morphism、organic shapes、cubic-bezier 缓动曲线）、Three.js WebGL 集成（粒子背景、3D 产品展示）。质量标准：加载 < 1.5s、动画 60fps、WCAG 2.1 AA 无障碍。关键规则：FluxUI 组件参考官方文档、Alpine.js 已随 Livewire 捆绑无需单独安装。与 [[engineering-rapid-prototyper]] 互补——原型优先速度，高级开发者优先品质。
@@ -14,6 +21,14 @@ This wiki is a living synthesis of curated sources spanning AI agents, cloud inf
 
 **[[engineering-cms-developer]]**（CMS Developer Agent）：The Agency 工程部门的 CMS 开发专家 Agent——专注于 Drupal 和 WordPress 网站开发，可交付从内容建模到上线审计的完整 CMS 开发生命周期。核心理念：**"A CMS isn't a constraint — it's a contract with your content editors."** 核心专长：WordPress 自定义主题/插件开发（Gutenberg Blocks、ACF Pro、子主题结构）、Drupal 自定义模块开发（Hook 系统、Block 插件、Twig 模板、Layout Builder）、内容建模与字段 API 设计。关键原则：ContentModel-first（先锁定字段/内容类型再写代码）、Code over configuration UI（所有内容类型/分类/字段通过代码注册）、Never fight the CMS（使用 hooks/filters/plugin 系统，绝不 monkey-patch 核心）。平台选择：Drupal 适合复杂内容模型/企业级/多语言；WordPress 适合编辑简单性/WooCommerce/广泛插件生态。
 
+**[[engineering-codebase-onboarding-engineer]]**（Codebase Onboarding Engineer）：The Agency 工程部门的代码库 onboarding 专家 Agent——专注于帮助新开发者快速理解陌生代码库，通过读取源码、追踪执行路径、仅陈述有代码依据的事实来构建准确的心智模型。核心理念：**"Code first, explain second. State only what you can prove."** 核心原则：证据优先（永远只陈述代码中可验证的事实）、分层解释（一句话 → 五分钟高层 → 深度代码流三层递进）、诚实告知检查边界（明确说明哪些部分已检查/未检查）、严格保持只读模式绝不修改文件。核心使命：① 快速构建准确的心智模型（目录结构、入口点、系统边界）；② 追踪真实执行路径（数据如何进入、转换、持久化、退出）；③ 加速开发者 onboarding（回答"从哪里开始"和"什么拥有这个行为"）。关键规则：绝不推断意图或质量、在部分理解时只说明检查了哪些文件、只做说明不做建议。与 [[engineering-senior-developer]] 和 [[engineering-git-workflow-master]] 互补——后两者分别提供代码实现和版本控制专业视角，Codebase Onboarding Engineer 则提供独立于具体技术的代码库结构理解能力。与 [[engineering-minimal-change-engineer]] 互补——后者专注交付最小变更，前者专注理解代码库结构，两者配合可实现"先理解再最小改动"的工作流。与 [[ThreeTierExplanation]] 和 [[ExecutionTracing]] 方法论深度绑定。
+
+**[[engineering-voice-ai-integration-engineer]]**（Voice AI Integration Engineer）：The Agency 工程部门的语音 AI 集成工程师 Agent——专注于设计并构建生产级语音转文字（STT）管道，涵盖从原始音频摄入到结构化输出的完整流程。核心理念：**"Turn raw audio into structured, production-ready text that machines and humans can actually use."** 核心管道：音频验证（ffprobe 探测格式/codec/采样率）→ 预处理（ffmpeg 重采样至 16kHz 单声道 + EBU R128 响度归一化）→ VAD 过滤（跳过静音）→ 分块（>30 分钟重叠感知分块）→ 转录（Faster-Whisper CTranslate2 优化版）→ 说话人分离（pyannote.audio）→ 归一化（标点/大小写/文本清理）→ PII 脱敏（命名管道阶段）→ 结构化输出（JSON/SRT/VTT）。架构选型：本地 Whisper（隐私敏感）vs 云端 ASR（AssemblyAI/Deepgram，高精度批量）。关键原则：永远探测不信任扩展名、永远保留时间戳、永远不静默删除低置信度片段、永远在管道中嵌入 PII 脱敏而非事后补丁。与 [[engineering-frontend-developer]] 在音频格式验证上存在张力（前端信任 MIME type，Voice AI 永远 ffprobe 探测）；与 [[EngineeringSRE]] 在生产日志记录上存在张力（Voice AI 严禁记录原始音频/未脱敏文本）。为 [[FasterWhisper]]/[[VoiceActivityDetection]]/[[SpeakerDiarization]]/[[EBUR128LoudnessNormalization]]/[[OverlapAwareChunking]]/[[PIIRedaction]]/[[StructuredTranscriptJSON]]/[[LLMHandoff]] 等 8 个核心概念定义了 Wiki 中的标准定义。
+
+
+**[[n8n-调用openclaw-agents的工作流架构]]**：n8n 工作流自动化平台如何通过 OpenAI 兼容 API 调用 OpenClaw Agent。核心机制：OpenClaw Gateway 提供 OpenAI Chat Completions 兼容端点（默认关闭，需在  中手动开启），n8n 通过 HTTP Request 节点调用，Agent ID 通过  字段指定（如 ）。与 Hermes Agent 的关键区别：默认端口不同（Hermes 8642 vs OpenClaw 18789）、Agent 指定方式不同。n8n 可同时连接两个 Agent——共用同一局域网 IP，仅端口不同，建两个 HTTP Request 节点即可实现统一自动化编排。
+**[[engineering-frontend-developer]]**（Frontend Developer Agent）：The Agency 工程部门的前端开发专家 Agent——专注于现代 Web 技术（React/Vue/Angular/Svelte）、UI 框架和性能优化，核心理念：**"Performance-first, accessibility always, pixel-perfect by default."** 核心能力：四阶段工作流（项目架构 → 组件开发 → 性能优化 → 测试 QA）；Core Web Vitals 优化（LCP < 2.5s、FID < 100ms、CLS < 0.1）；WCAG 2.1 AA 无障碍合规（ARIA 标签、语义化 HTML、键盘导航、屏幕阅读器兼容）；现代 CSS 技术（响应式设计、玻璃拟态、微交互动画）；PWA 构建（离线能力、Service Worker 缓存）；Code Splitting + Lazy Loading 优化_bundle size。关键成功指标：3G 网络下页面加载 < 3s、Lighthouse 性能与无障碍评分 > 90、组件复用率 > 80%、生产环境零控制台错误。与 [[engineering-senior-developer]] 互补——后者专注"奢华感"高级 Web 体验，前者专注性能与无障碍基础规范；与 [[design-ui-designer]] 在工作流 landing-page 中协同（UI Designer 设计 → Frontend Developer 实现）。属 The Agency Engineering 部门。
+
 **[[engineering-backend-architect]]**（Backend Architect Agent）：The Agency 工程部门的后端架构师 Agent——
 
 ### 知识与资源
@@ -32,6 +47,8 @@ This wiki is a living synthesis of curated sources spanning AI agents, cloud inf
 
 **[[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]**（大模型术语扫盲）：通俗解读大模型生态关键术语——LLM（≥1B参数的语言模型）、MCP（连接外部工具的标准化协议）、Agent（LLM+MCP实现自动化执行）、RAG（通过外部检索消除幻觉，正确率60%→90%）、Embedding（词向量语义距离）、vLLM（PagedAttention+连续批处理优化GPU显存）、Token（英文≈0.3/字、中文≈0.6/字的计量单位）、数据蒸馏（大模型生成精简数据训练小模型）。核心观点：大模型本身只给步骤方法不会真正执行工具调用，需配合MCP才能实现自动化；RAG通过"给提示"解决大模型在陌生领域的幻觉问题。属 [[Multi-Agent-AI-Systems]] 的基础概念层，与 [[llms-rag-ai-agent-三个到底什么区别]] 互补——后者从系统架构层面区分三者关系，本文档则提供术语的通俗定义与机制解释。
 
+**[[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]]**（LLM Wiki 实操指南）：Karpathy + 老张 的 LLM Wiki 落地教程——核心操作栈：Obsidian Web Clipper（网页文章一键转 Markdown）、Ctrl+Shift+D 快捷键批量图片本地化、Graph View 做 Lint 健康检查和发现幽灵节点（被多处引用但无专页的概念）、Git 插件自动 commit+push 版本管理、qmd 本地 Markdown 搜索引擎。核心洞察：**RAG 的根本问题是"没有积累"——每次提问 AI 都从零检索，什么都没沉淀；LLM Wiki 让 AI 增量维护交叉引用，一次操作改十五个文件，维护成本趋近于零**。思想精髓：**"你负责读和想，AI 负责整理和维护"**。属 [[LLM Wiki]] 的实操落地层——[[LLM Wiki]] 提供架构理念，本页提供 Obsidian 完整操作流程；与 [[Second Brain]] 互补——后者是更广泛的个人知识管理框架，本页聚焦 LLM Wiki 的具体实现。
+
 ### Multi-Agent AI Systems
 The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents) and **OpenClaw**. The Agency provides 147 specialized agents across 12 business divisions (Engineering, Design, Finance, Game Dev, Marketing, Paid Media, Product, Project Management, Testing, Support, Spatial Computing, Specialized). OpenClaw focuses on autonomous agents with persistent memory and workflow orchestration via n8n. A beginner-focused **n8n AI Agent 教程**（[[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]）：通过 N8N 平台构建 AI Agent 的入门指南——核心区分 Workflow（预定义自动化，输出恒定）与 Agent（由 LLM 驱动，动态选择工具）；系统讲解五类 N8N 节点（触发节点、动作节点、工具节点、代码节点、AI Agent 节点）；集成 Memory 模块保留对话上下文提升连贯性；演示 Airtable 库存管理工具集成案例。是 [[n8n-workflow-orchestration|OpenClaw+n8n 工作流编排]] 的入门前置知识。
 
@@ -45,22 +62,68 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
 
 **[[design-brand-guardian]]**（Brand Guardian）：The Agency Design 部门的品牌守护者专家 Agent——核心职责：创建内聚的品牌身份系统，确保品牌在所有触点的一致表达，并提供品牌保护策略。品牌 Foundation Framework（Purpose/Vision/Mission/Values/Personality）是所有品牌决策的基础；Visual Identity System（Logo/Color/Typography）必须作为内聚系统设计；Brand Voice and Messaging 定义品牌声音特征（Strategic/Consistent/Protective/Visionary）。默认要求包含品牌保护（商标/合规监控/危机管理）。与 [[design-ux-architect]] 时序协作——Brand Guardian 先定义品牌战略框架 → UX Architect 再构建技术实现系统；与 [[design-whimsy-injector]] 互补——Brand Guardian 定义的品牌个性是 Whimsy Injector 趣味性设计的输入。属 [[Multi-Agent-System-Reliability]] 的 Design 部门 Agent 设计层。
 
-**[[llms-rag-ai-agent-三个到底什么区别]]**（LLM/RAG/AI Agent 三者区别）：AI 应用入门基础知识——作者将 LLM 比作"天才大脑"（擅长思考但不知当前）、RAG 比作"随身图书馆助理"（动态获取外部知识，消除幻觉）、AI Agent 比作"循环控制系统"（感知→规划→执行→反思的自主行动能力）。核心观点：三者并非竞争技术，而是在三个不同层面互补协同——**LLM 用于思考，RAG 用于认知，Agent 用于执行**。生产系统应叠加三者：纯语言任务用 LLM、需准确性时加 RAG、需真正自主性时部署 Agent。属 [[Multi-Agent-AI-Systems]] 的基础概念层。
+**[[hospitality-guest-services]]**（Hospitality Guest Services Agent）：The Agency Specialized 部门的酒店及综合款待业宾客服务专家 Agent——覆盖酒店/度假村/餐厅/活动场地的全流程宾客体验：预订（booking/modification/cancellation）、预到沟通（48小时入住前个性化触达）、入住（30秒内问候 + 忠诚身份识别）、住店（礼宾服务、餐饮预订、活动安排）、投诉处理（**HEARD** 五步法：Hear/Empathize/Apologize/Resolve/Delight）、退房（账单审核 + 积分确认）、售后（24小时口碑请求 + 差评48小时响应）。核心方法论：**HEARD 投诉处理框架**（立即倾听→真诚共情→诚挚道歉→即时解决→超越补偿）、**分级服务恢复**（绿/黄/红/紧急四级补偿梯度）、**宾客隐私神圣不可侵犯**、**食物过敏零容忍**。核心理念：**"Every complaint is a gift"**（愿意投诉的宾客说明仍相信你能补救，不投诉直接离开则说明放弃）。
+
+**[[retail-customer-returns]]**（Retail Customer Returns Agent）：The Agency Specialized 部门的零售退货专员 Agent——处理退货、退款、换货的全流程客户服务 Agent，覆盖实体店、电商和全渠道零售环境。核心全渠道退货流程：退货授权 → 商品检查 → 退款处理 → 商品处置（退回库存/二手/供应商/RMA/报废）。10条关键行为规则：共情优先于政策执行/一致性政策防止歧视投诉/绝不指控客户欺诈/所有例外必须记录/退款优先退回原支付方式/未经检查不处理退货/退货欺诈每年造成数十亿损失/不得扣押客户商品/礼品退货特殊处理/健康安全品类严格限制。退货欺诈识别：Wardrobing（穿后退货）、收据欺诈、价格掉包、偷窃商品退货；发现可疑立即上报 Loss Prevention。退货原因代码体系：P类（产品缺陷/损坏/缺失配件/与描述不符）、C类（客户偏好/改主意/重复购买）、O类（运营错误）、F类（欺诈标记，仅内部使用）。客户挽留策略：在退款前主动推荐替代品、将退款转为无过期日期店内积分、提供替代方案而非直接拒绝。属 [[customer-service]] 的零售退货垂直专精扩展——两者均处理客户交互，后者专注文档中记录的场景。
+
+**[[legal-billing-time-tracking]]**（Legal Billing & Time Tracking Agent）：The Agency Specialized 部门的法律事务所计费与时间追踪专家 Agent——覆盖时间捕获（0.1小时增量、实时录入）、账单叙事撰写（诚实具体可防御）、开票生成（发票审核清单三段式）、催收管理（五阶段通信序列：发票→友好提醒→逾期→最终通知→律师升级）、信托账户合规（IOLTA、月度三向对账：银行对账单=客户台账=信托日记账）、计费分析（实现率≥90%、实收率≥95%、90天以上AR<5%）。**10条关键行为规则**：时间实时捕获/禁止计费非billable时间/信托账户神圣/叙事诚实具体/永不超过实际时间/遵守客户计费指南/核销需律师批准/催收沟通专业/应急费协议必须书面/争议立即升级。核心理念：**"计费不是行政职能，而是事务所的财务引擎"**——以$300/小时计算，每位律师每天因时间捕获习惯不佳平均损失$600-$900，年均$180,000-$270,000。属 [[legal-client-intake]] 的下游——intake 完成案件信息收集后，计费 Agent 接手财务引擎管理；与 [[accounts-payable-agent]] 形成事务所现金流的收/支双侧；与 [[support-legal-compliance-checker]] 共同构成法律合规体系（计费合规/信托账户合规）。
+
+**[[legal-client-intake]]**（Legal Client Intake Agent）：The Agency Specialized 部门的法律客户接待与资格审查专家 Agent——AI 驱动的律所潜在客户 intake 全流程自动化，覆盖初始接触（温暖问候+紧迫性筛查）、业务领域资格审查（人身伤害/家庭法/刑事/商业/房地产/遗产/雇佣）、利益冲突筛查（对方当事人全名 + 事先代表查询）、案件信息收集（六阶段问卷）、咨询安排和 attorney-ready 摘要交付。**10 条关键行为规则**：不提供法律建议、时效期限识别（人身伤害 2-3 年/EEOC 180-300 天）、冲突筛查先于安排咨询、同理心优先、不承诺结果、保密从第一次接触开始、资格审查先于时间投入、紧迫信号立即升级、无歧视对待、每次接触以明确下一步结束。属 [[Support-Responder]] 的法律行业版本——两者都是 first contact 接待专家，但后者面向通用客户支持，前者专精法律执业合规与 malpractice 风控。
+
+**[[legal-document-review]]**（Legal Document Review Agent）：The Agency Specialized 部门的专业法律文档审查 Agent——为律师提供第一轮文件审查，覆盖合同（MSA/NDA/雇佣/供应/合伙/许可）、诉讼文书（诉状/动议/开示/和解/命令）、房地产文件（买卖/租赁/贷款/产权）、合规审查和版本比对全场景。核心方法：**五步工作流**（文档接收与分类 → 结构分析 → 实质审查 → 风险评估与标记 → 交付物准备），结合高风险条款库（七类：赔偿/责任限制/终止/IP/自动续期/竞业限制/适用法律）、分级风险评分（高/中/低）和标准化交付模板。**10 条关键行为规则**：不提供法律意见（始终标记为"供律师审查"）、先识别上下文（文件类型/当事人/代理客户/管辖权）、全面标记（误报秒级消除，漏报代价数百万）、不省略经济重大条款、尊重管辖权差异、标记缺失条款而非沉默、保密绝对、版本比对穷尽化、以明确行动建议结尾。属 [[legal-client-intake]] 的下游依赖——intake 收集案件信息后，文档审查负责核心文件的风险识别；与 [[LegalBillingTimeTracking]] 共享法律事务所上下文（文档审查完成后记录工时和计费叙事）。
+
+**[[real-estate-buyer-seller]]**（Real Estate Buyer & Seller Agent）：The Agency Specialized 部门的房地产交易代理专家 Agent——专注于住宅和投资物业全流程交易支持，覆盖买方代表（需求评估→物业搜索→要约策略→谈判）、卖方代表（挂牌准备→定价策略→营销→展示管理）和交易协调（合同管理→房屋检查→融资跟踪→交割支持）。核心方法：**五步工作流**（咨询→搜索/挂牌→要约谈判→交易管理→交割）结合 **十大关键规则**（独家代表客户利益/书面协议强制/公平住房合规/重大缺陷必披露/截止日期不可错过/定金条款严格遵守/不从事法律实践/持续更新市场状况/响应速度2小时基准/推荐增长为成功指标）。**三大核心交付物**：Comparative Market Analysis（CMA 市场比较分析）、Buyer Needs Assessment（买方需求评估表）和 Transaction Coordination Timeline（交易协调时间线）。与 [[legal-document-review]] 共享房地产交易法律上下文——两者均涉及房地产交易文档，但前者专注买卖代理，后者专注法律文件审查；与 [[hospitality-guest-services]] 共享"卓越客户体验"核心理念——两者均以响应速度、沟通能力和专业服务为成功基石；与 [[SalesOutreach]] 在"个性化深度 vs 规模化"上存在策略差异（房地产高价值低频次适合深度个性化 vs B2B 外勤规模化触达）。
+
+**[[loan-officer-assistant]]**（Loan Officer Assistant Agent）：The Agency Specialized 部门的抵押贷款专员 AI Agent——面向抵押贷款、消费信贷和商业贷款全生命周期，支持贷款专员管理借款人沟通、文件收集、管道进度、合规截止日期和交割协调。核心方法：**五步工作流**（借款人接待→申请与披露→处理与文件收集→承销管理→交割协调）结合 **十大关键规则**（TRID 时间线/DTI 比率/公平贷款合规/文件有效期管理/资质决策权/州级执照要求等）。**核心交付物**：借款人接待脚本（5 分钟首次响应）、预审分析表（DTI/LTV/CLTV 计算）、文件清单（按贷款类型）、TRID 合规时间表、贷款状态更新模板（7种场景）、承销条件跟踪表。**关键合规要求**：LE 必须在申请后 3 个工作日内交付、CD 必须在成交前至少 3 个工作日交付；错过任一截止日期均为联邦监管违规。与 [[real-estate-buyer-seller]] 在交易融资节点存在协调关系——贷款合规截止日期具有法律强制性，Agent 必须主动追踪而非被动等待对方协调；与 [[legal-document-review]] 共享抵押贷款法律文件上下文——后者提供法律审查，Loan Officer Agent 负责贷款文件全生命周期管理；与 [[SalesOutreach]] 在"销售漏斗转化"上形成上游关系——Outreach 触达潜在借款人，Loan Officer Agent 接手完成预审和申请。
+
+**[[finance-fpa-analyst]]**（FP&A Analyst Agent）：The Agency Finance 部门的高增长 SaaS 财务规划与分析专家 Agent——人格化身份为"Riley"，11+ 年经验，专注于将战略计划转化为具体财务框架，驱动问责制和明智的资源分配。核心理念：**"FP&A is not accounting's sequel — it's strategy's translator"**。核心交付物：**年度经营计划（AOP）**——自上而下目标与自下而上构建的差距协调、董事会演示；**滚动预测**——至少每季度重新预测，结合业务所有者输入；**月度业务回顾（MBR）**——执行仪表板、收入/费用差异分析、前瞻性预测更新；**场景规划**——base/upside/downside，含明确假设和触发点。关键规则：每个预算必须有负责人（"预算无人认领=无人遵循"）、差异分析必须解释未来而非仅解释过去、场景规划是重大决策的必备条件。高级技术能力：零基预算（ZBB）、作业成本法（ABC）、蒙特卡洛概率预测、单位经济分析（CAC/LTV/回本周期）。属 [[finance-investment-researcher]] 和 [[finance-financial-analyst]] 的下游——投资研究提供市场洞察，财务分析提供历史报告，FP&A 负责前瞻性规划和决策支持；与 [[accounts-payable-agent]] 形成财务规划与财务执行的双向财务闭环；与 [[Support-Finance-Tracker]]（财务追踪）形成规划→执行→追踪的财务全周期。
+
+**[[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]**（Harness Engineering：LLM Agent 的 7 层工程脚手架）：Lychee Technology 的 engineering blog 提出**Harness Engineering**概念——LLM 本身不是 Agent，Agent = LLM + 代码脚手架（状态管理 + 恢复工作流）。核心演进路径：**Prompt Engineering**（如何问）→ **Context Engineering**（如何知道，RAG）→ **Harness Engineering**（如何约束和运行）——后者吸收前两者并增加执行控制层。**4大设计原则**：约束而非指令（Schema 验证器 > 提示词保证）、状态外部化（context window 易失，磁盘文件持久）、每步可验证（规则/工具/LLM-as-judge 三层异构验证）、局部失败而非全局崩溃（单步重试不重启管道）。**7层 Harness Stack**：① Cognition（受限操作边界，role file/job description）→ ② Tools（工具输出排序/去重/token预算截断）→ ③ Contracts & Interfaces（JSON Schema 边界验证，防 Schema Drift）→ ④ Orchestration（DAG/状态机约束允许动作）→ ⑤ Memory & State（Working Memory + Persistent State 分层）→ ⑥ Evaluation & Observation（异构验证层）→ ⑦ Constraints & Recovery（幂等重试，Context Reset 机制）。**4个高级陷阱**：Context Anxiety（70% token 时模型仓促行为，解决方案：Context Reset）、Self-Grading Illusion（LLM 无法可靠评估自身，解决方案：Sprint Contract 分离 Generator/Evaluator）、优化"看起来正确"而非"真正正确"（解决方案：客观反馈而非情绪化错误消息）、Memory Consolidation（32K 噪声日志压缩至 7K）。**最小可行 Harness**（Day 1 可构建）：state.json + retry wrapper + schema validator + tool output truncation。属 [[Multi-Agent-System-Reliability]] 的 Agent 可靠性工程基础层，与 [[llms-rag-ai-agent-三个到底什么区别]] 互补——后者从概念层面区分 LLM/Agent/RAG，本文从工程层面提供 Agent 可靠运行的系统性解决方案；与 [[engineering-ai-engineer]] 共享 AI 系统生产化思维；与 [[designing-for-agentic-ai]]（Designing for Agentic AI）互补——前者侧重工程实现，后者侧重设计原则。
+
+**[[llms-rag-ai-agent-三个到底什么区别]]**（LLM/RAG/AI Agent 三者区别）：
 
 **[[multi-agent-team]]**（Multi-Agent Specialized Team — Solo Founder Setup）：Solo Founder 通过多 Agent 专业化团队实现"一人公司"运作的实战方案——4个专业 Agent（Milo 战略lead / Josh 商业分析 / Marketing 内容营销 / Dev 开发）+ 共享记忆 + Telegram 单入口 + 定时任务自动推送。核心洞察：**Agent 个性化**使"和团队对话"比"使用工具"更自然（Milo 自信有魅力、Josh 务实数据驱动）；**共享记忆 + 私有上下文**组合是核心——共同 ground（目标/决策）+ 各积累领域专长；按任务复杂度匹配模型（Claude Opus 做战略、Gemini 做长文本研究、Codex 做实现）；定时主动推送洞察而非被动响应形成价值飞轮。建议从小团队开始（lead + 1 specialist），按瓶颈逐步扩展。属 [[Multi-Agent-System-Reliability]] 的团队协作实践层，与 [[ContentFactory]]（内容创作流水线）和 [[Agents-Orchestrator]]（流水线编排）同属多 Agent 协作模式的不同维度，可结合使用。
 **[[AI Citation Strategist]]**（AI Citation Strategist Agent）：专注于 AI 推荐引擎优化（AEO/GEO）的营销 Agent——审计品牌在 ChatGPT、Claude、Gemini、Perplexity 四大 AI 平台上的引用可见性，识别竞争对手被引用的原因，生成 Fix Pack 改善内容信号。与 [[Marketing SEO Specialist]] 互补但独立——传统 SEO 成功不能自动转化为 AI 可见性，AEO 与 SEO 必须作为不同策略对待。核心差异化：**AI 引用 ≠ SEO 排名**，引用的信号（实体清晰度、结构化权威、FAQ 对齐、Schema 标记）完全不同。**平台差异化**：ChatGPT 偏好权威性+结构化页面（FAQ/对比表/how-to指南），Claude 偏好细腻平衡+明确溯源的分析内容，Gemini 依赖 Google 生态信号+实时搜索集成，Perplexity 偏好来源多样性+时效性+直接答案。**提示词模式工程**：围绕用户实际输入 AI 的查询模式设计内容——"Best X for Y"（对比内容）、"X vs Y"（专页对比+Schema）、"How to choose X"（买家指南+决策框架）、"What is the difference between X and Y"（清晰定义）。核心方法：Discovery（20-40 提示词生成）→ Audit（四平台查询记录引用率）→ Analysis（竞品内容结构映射）→ Fix Pack（按影响力优先级排序）→ Recheck（14天复测）。属 [[Multi-Agent-System-Reliability]] 的营销 Agent 设计层，与 [[Marketing Agentic Search Optimizer]] 同属 AI 驱动的内容可见性优化方向。
 
 **[[nexus-spatial-discovery]]**（Nexus Spatial Discovery Exercise）：8个 The Agency 专业 Agent 并行协作完成 AI 空间指挥中心产品完整规划的实战案例——10分钟 wall-clock time 产出完整规划。参与 Agent：产品趋势研究员（市场验证 + Vision Pro 现实核查）、后端架构师（8服务 Rust 架构）、品牌守护者（定义 [[SpatialAIOps]] 新品类）、增长黑客（3阶段 GTM + 增长飞轮）、支持应答者（AI 内嵌空间的差异化支持设计）、UX 研究员（识别调试为杀手级用例）、XR 界面架构师（命令剧院 + 7态节点系统）、项目牧羊人（35周时间线 + 5团队分配）。跨 Agent 独立共识：2D先行（WebXR分发） > VisionOS、品牌 > 调试 > 战情室协作 > 渐进披露。核心张力：Growth Hacker（$29-59）与 Trend Researcher（$99-249）定价分歧待 A/B 测试。属 [[Multi-Agent-System-Reliability]] 的多 Agent 协作规划层实践，展示了并行 Agent 发现可产出连贯、相互引用的完整计划。与 [[Multi-Agent-Team]]（单团队多 Agent 架构）和 [[Agents-Orchestrator]]（流水线编排）同属多 Agent 协作模式的不同维度。
 
+**[[executive-brief]]**（NEXUS Executive Brief）：The Agency 多 Agent 编排框架 NEXUS 的战略概览文档——从商业价值层面论证多 Agent 协调统一的必要性与量化收益。**核心问题**：缺乏协调时 Agent 在交接边界 73% 失败率，且无证据要求的质量评估导致"幻想型审批"（Agent 给无证明的基础实现评 A+）。**核心发现**（4条）：① 标准化交接模板和上下文连续性是最高杠杆干预；② Reality Checker 默认"NEEDS WORK"姿态防止过早生产部署；③ 4 条并行轨道同时执行压缩 40-60% 时间线，是主要上市加速器；④ Dev↔QA 循环可在集成前捕获 95% 缺陷，硬化时间减少 50%。**三大部署模式**：NEXUS-Full（12-24周，All agents）、NEXUS-Sprint（2-6周，15-25 agents）、NEXUS-Micro（1-5天，5-10 agents）。**三大交付物类别**：Master Strategy（800+行操作 doctrine）、Phase Playbooks（7份阶段手册）、Handoff Templates（7份交接模板）。**战略建议**：Critical = 立即采用 NEXUS-Sprint；High = 实现 Dev↔QA 循环；High = 所有 P0/P1 事故使用 Incident Response Runbook；Medium = 每季度 NEXUS-Full 战略复审。属 [[Multi-Agent-System-Reliability]] 的战略层，与 [[quickstart]]（操作层 Quick-Start Guide）和 [[nexus-strategy]]（完整 doctrine）共同构成 NEXUS 框架的三层文档体系，与 [[nexus-spatial-discovery]]（并行 Agent 协作执行案例）相互印证并行工作流价值。
+
+**[[quickstart]]**（NEXUS Quick-Start Guide）：The Agency 多 Agent 编排框架 NEXUS 的快速启动指南——核心价值：**5 分钟内从零启动完整的多 Agent 流水线**。三种启动模式覆盖全场景：NEXUS-Full（完整产品，12-24周，6阶段全流程）→ NEXUS-Sprint（功能/MVP，2-6周，跳过市场发现）→ NEXUS-Micro（单一任务，1-5天，精准激活特定 Agent）。核心原则：Quality Gates（每阶段质量门控，无证据不推进）、Dev↔QA Loop（构建→测试循环，PASS推进/FAIL重试，最多3次）、Handoffs（结构化上下文传递，避免冷启动）、Reality Checker（最终质量权威，默认"NEEDS WORK"）、Evidence Over Claims（截图/测试结果/数据 > 口头断言）。[[agents-orchestrator]] 是管道的核心控制器。与 [[nexus-strategy]]（完整 doctrine）、[[executive-brief]]（战略层）、[[handoff-templates]]（交接模板）共同构成 NEXUS 三大战略交付物体系。
+
+**[[handoff-templates]]**（NEXUS Handoff Templates）：NEXUS 框架的标准化交接模板体系——7 种场景化 Markdown 模板覆盖多 Agent 协作全链路交接：**Standard Handoff**（通用任务分配，含 metadata/context/deliverable/quality-expectations 四段结构）、**QA PASS/FAIL**（Dev↔QA 循环结果反馈，含证据清单和多分辨率截图要求）、**Escalation Report**（3 次重试耗尽后的升级报告，含失败历史/根因分析/决策建议）、**Phase Gate Handoff**（阶段门控交接，含门控标准结果表和风险携带记录）、**Sprint Handoff**（冲刺边界交接，含完成状态/质量指标/待办项/回顾洞察）、**Incident Handoff**（事故响应交接，含 P0-P3 分类和状态追踪）。Usage Guide 表格将每种场景映射到对应模板，确保 Agent 始终使用正确格式。与 [[workflow-with-memory]] 的 MCP 持久记忆机制互补——handoff-templates 定义"交接什么"，memory 系统定义"如何持久化"。属 [[Multi-Agent-System-Reliability]] 的交接机制层。
+
+**[[scenario-marketing-campaign]]**（Multi-Channel Marketing Campaign Runbook）：NEXUS 多渠道营销活动完整 Agent 协作执行手册——Mode: NEXUS-Micro to NEXUS-Sprint | Duration: 2-4 weeks | Agents: 10-15。15 个专业 Agent 角色分三类：**Campaign Core**（Social Media Strategist 活动总负责 + Content Creator 全格式内容生产 + Growth Hacker 获客漏斗 + Brand Guardian 品牌一致性 + Analytics Reporter 数据分析）、**Platform Specialists**（Twitter Engager + TikTok Strategist + Instagram Curator + Reddit Community Builder + App Store Optimizer 各平台专项运营）、**Support**（Trend Researcher + Experiment Tracker + Executive Summary Generator + Legal Compliance Checker 支持团队）。四周执行计划：**Week 1** 策略制定与内容生产（Day 1-2 策略规划含 KPI/受众/预算/内容日历；Day 3-5 多格式内容创作含博客/邮件/落地页/视频脚本/社媒文案）；**Week 2** 发布与激活（含 Launch Day 全渠道同步启动 + Day 4-5 数据驱动优化）；**Week 3-4** 持续优化（每日仪表盘监控 + 每周复盘 + 活动结束 ROI 分析）。核心指标体系：总量指标（总触达/互动率>3%/CTR>2%/CVR>5%/CPA/品牌情感） + 平台专属 KPI（Twitter 触达+互动率、TikTok 完播率+粉丝增长、Reddit  upvotes+评论质量等）。品牌一致性检查点：发布前审查（Brand Guardian）+ 每周视觉一致性审计 + 合规审查。属 [[Multi-Agent-System-Reliability]] 的营销活动执行层，与 [[workflow-landing-page]]（单日冲刺）互补——本 runbook 是 2-4 周多渠道营销的全景模板，后者是单渠道单任务的快速实现。
+
+**[[scenario-incident-response]]**（Incident Response Runbook）：NEXUS 框架生产事故结构化响应手册——定义 P0~P3 四级严重等级分类（P0=服务全停/数据丢失/安全漏洞，即时响应；P1=主要功能故障/性能严重下降，<1小时；P2=次要功能故障/有 workaround，<4小时；P3=表面问题，下个 sprint），按等级激活 3-8 个 Agent 并行响应。五阶段标准流程：检测分诊→并行调查→缓解决策树→解决验证→48小时内复盘。提供标准化沟通模板和五类升级矩阵。属 [[Multi-Agent-System-Reliability]] 的事故响应层。
+
+**[[scenario-enterprise-feature]]**（Enterprise Feature Development Runbook）：企业级产品大型功能开发的多 Agent 编排完整手册——Mode: NEXUS-Sprint | Duration: 6-12 weeks | Agents: 20-30。五阶段流水线：**Phase 1** 需求与架构（Week 1-2，利益相关者对齐+合规扫描+技术架构评审）→ **Phase 2** 基础构建（Week 3，CI/CD 流水线+组件脚手架+数据库迁移）→ **Phase 3** 开发（Week 4-9，Dev↔QA 循环，双周汇报，3 个 Sprint）→ **Phase 4** 硬化（Week 10-11，全量截图+API 回归+10 倍流量压测，Reality Checker 默认 NEEDS WORK）→ **Phase 5** 发布（Week 12，灰度发布 5%→25%→100%+实时监控）。核心价值：量化质量门（代码覆盖率>80%、API P95<200ms、零关键漏洞、品牌一致性≥95%、WCAG 2.1 AA）+结构化风险矩阵（5 类风险+缓解策略）+分层利益相关者沟通节奏（执行层每日/产品周报/主管双周 SCQA 简报≤500词/合规财务月度报告）。属 [[Multi-Agent-System-Reliability]] 的企业级功能开发层，与 [[scenario-marketing-campaign]]（多渠道营销）互补——两者均采用 NEXUS-Sprint 框架，营销场景侧重内容传播，本 runbook 侧重企业合规开发；与 [[scenario-incident-response]]（应急响应）形成首尾衔接——企业功能发布上线后由应急响应机制保驾护航。
+
+**[[scenario-startup-mvp]]**（Startup MVP Build Runbook）：初创公司 MVP 4-6 周快速构建的多 Agent 编排执行手册——Mode: NEXUS-Sprint | Duration: 4-6 weeks | Agents: 18-22。分周执行：**Week 1** 快速发现+架构（竞品扫描+线框图+RICE 评分 backlog+CI/CD 初始化）→ **Week 2-3** 核心构建（Dev↔QA 循环双 Sprint，Growth Team 第 3 周激活）→ **Week 4** 抛光硬化（全量截图+负载测试+Reality Checker 最终质量门）→ **Week 5-6** 发布+增长（Growth Hacker 激活获客渠道+实时监控+早期用户反馈）。关键决策点：Day 2 概念 Go/No-Go、Day 4 架构审批、Week 4 Day 5 生产就绪判定。核心价值：强调 Sprint Prioritizer 执行 MoSCoW 防止范围蔓延（"Won't" means won't）、Evidence Collector 每个任务必须运行（no exceptions）、Rapid Prototyper 先验证后扩展的心态。与 [[scenario-enterprise-feature]]（企业级功能，6-12 周）和 [[scenario-marketing-campaign]]（多渠道营销，2-4 周）共同构成 NEXUS-Sprint 三档时长模板。
+
+**[[phase-0-discovery]]**（Phase 0 Playbook — Intelligence & Discovery）：NEXUS 多 Agent 团队 Phase 0（Intelligence & Discovery 阶段）完整执行手册——3-7 天，6 个 Agent 并行激活，在投入资源前全面验证机会。核心原则：**"在问题、市场和监管环境被充分理解之前，不进行任何建设"**。采用 Wave 1 + Wave 2 双波并行结构：Wave 1（外部探索）包含 Trend Researcher（市场情报，TAM/SAM/SOM、竞争格局、趋势预测，3天）、Feedback Synthesizer（用户需求，多渠道反馈收集、RICE 评分痛点、流失指标，3天）、UX Researcher（用户体验，5-10用户访谈计划、3-5 Persona、用户旅程地图，5天）；Wave 2（内部评估）包含 Analytics Reporter（数据审计，数据源盘点、信号识别、质量评分，2天）、Legal Compliance Checker（法律合规，GDPR/CCPA/HIPANA 框架映射、风险评级，3天）、Tool Evaluator（技术评估，Build vs. Buy、开源 vs. 商业评估，2天）。Day 5-7 为汇聚点（Convergence Point），6 份报告交由 Executive Summary Generator 合成不超过 500 词的 SCQA 格式执行摘要，并给出 **GO/NO-GO/PIVOT** 三段式决策。6 项质量门标准：市场机会验证、TAM 阈值、≥3 个有数据支撑的用户痛点、无阻断性合规问题、关键指标与数据源确认、技术栈可行性。Phase 0 完成标准：Executive Summary Generator 交付 GO 决策且附全部 6 个 Agent 的支撑证据。属 [[Multi-Agent-System-Reliability]] 的 Phase Playbook 体系层，是 [[phase-1-strategy]] 的前置阶段——Phase 0 验证通过后才进入 Phase 1 战略与架构。
+
+**[[phase-1-strategy]]**（Phase 1 Playbook — Strategy & Architecture）：NEXUS 多 Agent 团队 Phase 1（战略与架构阶段）完整执行手册——5-10 天，8 个 Agent 并行协作，定义项目启动前所有前期准备工作。核心理念：**"写代码之前，先定义做什么、如何组织、何为成功"**。三步 Agent 激活序列：① **战略框架**（Day 1-3，并行）— Studio Producer 战略组合对齐（3天）+ Brand Guardian 品牌标识系统（3天）+ Finance Tracker 财务规划（2天）；② **技术架构**（Day 3-7，并行，需①输出就绪）— UX Architect 前端设计系统（4天）+ Backend Architect 后端系统架构（4天）+ AI Engineer ML 架构（条件激活，3天）+ Senior Project Manager 规范转任务（3天）；③ **优先级排序**（Day 7-10，顺序，需②输出）— Sprint Prioritizer RICE 评分 + MoSCoW 分类（2天）。质量门：7 项检查清单，**必须 Studio Producer（战略）+ Reality Checker（技术）双签**方可进入 Phase 2。Phase 1→Phase 2 Handoff Package 包含 8 份交付物（战略计划/品牌系统/财务计划/CSS 设计系统/系统架构规范/ML 设计/任务列表/Sprint 计划）。属 [[Multi-Agent-System-Reliability]] 的 Phase Playbook 体系层，与 [[phase-2-foundation]] 前后衔接（Phase 1 定义架构 → Phase 2 搭建脚手架），与 [[nexus-strategy]] 共同构成 NEXUS 框架的阶段执行层。
+
+**[[phase-2-foundation]]**（Phase 2 Playbook — Foundation & Scaffolding）：NEXUS 框架 Phase 2 执行手册——6 Agent 双工作流并行构建技术基础设施与应用框架，3-5 天完成骨架站立。**Workstream A（基础设施）**：DevOps Automator（CI/CD 流水线+IaC，3 天）+ Infrastructure Maintainer（云资源+监控栈，3 天）+ Studio Operations（Git 工作流+协作工具，2 天）并行；**Workstream B（应用框架）**：Frontend Developer（React/Vue+组件库，3 天）+ Backend Architect（数据库+API 脚手架，4 天）+ UX Architect（CSS 设计令牌+主题系统，2 天）并行。质量门：DevOps Automator + Evidence Collector 联合双签，8 项截图证据验证（CI 日志/桌面端/移动端/主题切换/API 健康检查/数据库/监控面板/组件库），通过后方可进入 [[phase-3-build]]。属 [[Multi-Agent-System-Reliability]] 的基础设施构建层，与 [[scenario-enterprise-feature]] 中的 Phase 2 阶段（Week 3，CI/CD+脚手架+数据库迁移）相互印证——前者是 Phase Playbook 本身，后者是 NEXUS-Sprint 场景中的具体应用。
+
+**[[phase-3-build]]**（Phase 3 Playbook — Build & Iterate）：NEXUS 多 Agent 协作下功能迭代构建的完整流程手册——2-12 周（视范围而定），15-30+ Agent，通过 [[Agents-Orchestrator]] 驱动 Dev↔QA 循环完成所有功能实现。核心机制：任务按 RICE 评分排序分配 → Developer Agent 实现 → Evidence Collector 多维度测试（截图+功能+品牌）→ 通过则完成，失败则修复，最多 3 次，超过则升级。Agent Assignment Matrix 覆盖 14 类任务（React UI/REST API/数据库/移动端/ML/CI-CD 等），Specialist 专家按需激活（UI Designer/Brand Guardian/Whimsy Injector 等）。四条并行构建轨道：Track A 核心产品（Dev↔QA 循环，2 周 Sprint）、Track B 增长营销（Growth Hacker+Content Creator+Social Media Strategist）、Track C 质量运营（Evidence Collector+API Tester+Performance Benchmarker 持续验证）、Track D 品牌体验（UI Designer+Brand Guardian+Visual Storyteller 持续抛光）。Sprint 执行模板：Sprint Planning → Daily Execution（含状态报告）→ Sprint Review → Retrospective。质量门：7 项检查清单（100% 任务 QA 通过/API 端点验证/P95<200ms/品牌一致性≥95%/零 P0/P1 bug/验收标准满足/代码审查完成），Gate Keeper（Agents Orchestrator）裁决 PASS→Phase 4 / CONTINUE→继续 Phase 3 / ESCALATE→Studio Producer 介入。属 [[Multi-Agent-System-Reliability]] 的开发执行层，与 [[phase-2-foundation]]（Phase 2 基础就绪是 Phase 3 前置条件）和 [[phase-4-hardening]]（Phase 3 Dev↔QA 循环的产出进入 Phase 4 最终硬化）前后衔接，共同构成 NEXUS 框架最核心的价值交付阶段。
+
+**[[phase-4-hardening]]**（Phase 4 Playbook — Quality & Hardening）：NEXUS 多 Agent 团队 Phase 4（质量硬化与最终验收阶段）完整执行手册——3-7 天，8 个 Agent 协同，通过 Reality Checker 的唯一权威最终裁定实现生产就绪性验证。核心理念：**Reality Checker 默认裁定 NEEDS WORK，首次通过率极低，2-3 轮迭代属于正常预期**。三步 Agent 激活序列：① **证据收集**（Day 1-2，4 个 Agent 并行）— Evidence Collector（全维度截图套件：桌面/平板/手机×亮色/暗色/主题检测）× API Tester（全部端点回归+集成+边界情况）× Performance Benchmarker（10 倍流量负载测试+Core Web Vitals P95<200ms/LCP<2.5s/CLS<0.1）× Legal Compliance Checker（隐私合规+OWASP Top10+GDPR/CCPA+WCAG 2.1 AA）；② **分析聚合**（Day 3-4，3 个 Agent 并行）— Test Results Analyzer（聚合质量仪表板+问题优先级划分）/ Workflow Optimizer（Dev↔QA 循环效率分析）/ Infrastructure Maintainer（生产环境验证+灾难恢复）；③ **最终裁定**（Day 5-7，顺序）— Reality Checker 执行端到端用户路径验证+跨设备一致性检查+规格对照审查，裁决选项：READY（极少首次通过）/ NEEDS WORK（预期结果，返回 Phase 3 修复循环）/ NOT READY（架构级问题，返回 Phase 1/2）。7 项质量门标准：用户路径完整、跨设备一致性、P95<200ms & LCP<2.5s、零关键漏洞、所有监管要求满足、规格 100% 合规、生产环境验证通过。属 [[Multi-Agent-System-Reliability]] 的质量保障层，与 [[phase-3-build]]（开发迭代）前后衔接（Phase 3 Dev↔QA 循环 → Phase 4 最终硬化），与 [[phase-5-launch]]（发布就绪）共同构成 NEXUS 的最终验收闭环。
+
+**[[phase-5-launch]]**（Phase 5 Playbook — Launch & Growth）：NEXUS 多 Agent 团队 Phase 5（发布与增长运营阶段）完整执行手册——2-4 周（T-7~T+14），12 个 Agent 协同，实现最大市场影响力。核心理念：**全渠道同步激活，最大化发布冲击力，工程侧确保零宕机**。四阶段递进节奏：① **T-7 预热周**（Content Creator × Social Media Strategist × Growth Hacker × App Store Optimizer 并行准备内容/营销资源 × DevOps Automator × Infrastructure Maintainer × Project Shepherd 并行准备部署/监控/清单）；② **T-1 发布前夕**（三维度完整检查清单：Technical × Content × Marketing × Support）；③ **T-0 发布日**（Hour 0 蓝绿部署 → Hour 1-2 全渠道营销激活：Twitter/Reddit/Instagram/TikTok → Hour 2-8 监控与响应）；④ **T+1~T+14**（每日三波段运营节奏 T+1~T+7 → Growth Hacker + Experiment Tracker + Analytics Reporter 优化周 T+7~T+14）。7 项质量门：零宕机部署、48h 无 P0/P1、监控就绪、用户获取渠道激活、反馈循环运转、干系人通报、支持团队就绪。质量门由 [[StudioProducer]]（战略）+ [[AnalyticsReporter]]（数据）双签，决策：STABLE → Phase 6 / CRITICAL → 热修复循环 / ROLLBACK → 返回 Phase 4。属 [[Multi-Agent-System-Reliability]] 的发布执行层，以 [[phase-4-hardening]] READY 裁决为前提，向 [[Phase6Operate]]（STABLE 裁决）移交运营。
+
+**[[Phase6Operate]]**（Phase 6 Playbook — Operate & Evolve）：NEXUS 多 Agent 团队 Phase 6（持续运营与演进阶段）完整执行手册——无结束日期，12+ Agent 轮换协调，只要产品在市场就持续运行。核心机制：**分层运营节拍**（Continuous / Daily / Weekly / Bi-Weekly / Monthly / Quarterly）将 Agent 职责与活动频率对齐，由 [[Studio Producer]] 统筹治理。**持续改进闭环**（Measure → Analyze → Plan → Build → Validate → Deploy）每季度驱动流程效率提升 20%。**P0–P3 四级应急响应协议**覆盖从即时响应（P0 服务全停）到纳入 Sprint 处理（P3 表面问题）的全场景事故管理。**月度增长运营**整合渠道分析、A/B 实验、留存曲线和增长路线图；**季度战略评审**从市场定位、产品策略、增长策略和组织健康四个维度评估产品演进方向。新功能通过 **NEXUS Sprint**（压缩的 7 步循环：Backlog→实现→验证→部署→监控→测量→反馈）实现持续交付。属 [[Multi-Agent-System-Reliability]] 的运营保障层，以 [[phase-4-hardening]] 通过质量门为前提，与 [[scenario-incident-response]] 共享 P0–P3 事故分级体系（细节粒度需对齐）。
+
 **[[examples-readme]]**（The Agency Examples 索引）：The Agency 多 Agent 协作案例的索引与贡献指南——展示了当全体 Agent 协作时实际上是什么样子的。Nexus Spatial Discovery 是首个也是最完整的示例：8 个专业 Agent 并行运行，产出连贯、相互引用的完整计划，无须人工协调开销。贡献标准：多个 Agent 协作同一目标、展示 Agency 能力广度、具有现实适用性。是 [[Multi-Agent-Collaboration]] 概念的实践验证入口。
 
 **[[workflow-landing-page]]**：多 Agent 一天冲刺工作流——展示 Landing Page 场景下 4 个核心设计模式：**[[Parallel-Kickoff]]**（Content Creator + UI Designer 上午并行启动）、**[[Merge-Point]]**（Frontend Developer 等待两者完成）、**[[Feedback-Loop]]**（Growth Hacker 审查后 Frontend Developer 修改）、**[[Time-Boxing]]**（每个阶段严格时间盒：09:00→16:30）。与 [[workflow-startup-mvp]] 互补——后者以周为单位的长周期迭代，本工作流是单日冲刺的具体化实现。与 [[design-ui-designer]] 和 [[design-brand-guardian]] 共享 UI Designer 角色。
 
 **[[workflow-book-chapter]]**（Book Chapter Development Workflow）：单 Agent 工作流——[[BookCoAuthor]] Agent 将粗糙的原始素材（录音、碎片笔记、战略要点）转化为结构化的第一人称章节草稿。核心理念：**不是泛化 ghostwriting，而是保持作者声音 + 强化分类定位 + 暴露开放编辑决策**。五部分输出结构：Target Outcome（目标与战略定位）→ Chapter Draft（版本化章节草稿）→ Editorial Notes（假设与证据缺口的编辑注释）→ Feedback Loop（内部反馈循环）→ Next Step（明确修订问题而非模糊交接）。质量标准：草稿保持第一人称声音、claim 必须依附来源或标记为假设、删除泛化激励语言、以明确修订问题结尾。与 [[workflow-startup-mvp]]（多 Agent 长周期迭代）互补——前者聚焦单 Agent 聚焦式内容创作，后者是多 Agent 系统级协作；与 [[marketing-book-co-author]] 共享 Book Co-Author Agent，但本工作流是通用场景示例，后者是营销场景专用。属 [[TheAgency]] examples 层，与 [[agents-orchestrator]] 共同展示单 Agent 到多 Agent 的能力谱系。
 
-**GitHub Copilot Integration**（[[github-copilot]]）：The Agency 与 GitHub Copilot 的开箱即用集成——无需转换，Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 原生兼容。通过 `./scripts/install.sh --tool copilot` 一键安装，或手动复制到 `~/.github/agents/` 或 `~/.copilot/agents/` 目录。用户可在任意 Copilot 会话中通过名称激活特定 agent，如 `"Activate Frontend Developer and help me build a React component."`。与 [[readme|Cursor Integration]] 互补——后者项目级别生效，Copilot Integration 用户级别全局生效，共同构成 [[The Agency]] 的多 IDE 集成生态。
+**GitHub Copilot Integration**（[[GitHub-Copilot]]）：The Agency 与 GitHub Copilot 的开箱即用集成——无需转换，Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 原生兼容。通过 `./scripts/install.sh --tool copilot` 一键安装，或手动复制到 `~/.github/agents/` 或 `~/.copilot/agents/` 目录。用户可在任意 Copilot 会话中通过名称激活特定 agent，如 `"Activate Frontend Developer and help me build a React component."`。与 [[readme|Cursor Integration]] 互补——后者项目级别生效，Copilot Integration 用户级别全局生效，共同构成 [[The Agency]] 的多 IDE 集成生态。
 
-**Windsurf Integration**（[[windsurf-integration]]）：The Agency Agent roster 与 Windsurf 编辑器的集成方案——通过 `.windsurfrules` 文件将全部 Agent roster 聚合为单一规则文件，install.sh 脚本从项目根目录安装，项目级生效。Windsurf 中在 prompt 里按名称引用 Agent 即可激活（如 "Use the Frontend Developer agent to build this component."）。与 [[Cursor Integration]]（.mdc 规则）和 [[Aider Integration]]（CONVENTIONS.md）同为项目级 IDE 集成，机制相似，共同构成 The Agency 的多 IDE 覆盖体系。[[integrations-readme]] 已覆盖所有 11 种集成工具的概览。
+**Chinese Localization**（[[i18n-readme]]）：The Agency 的 Copilot Agent 中文本地化工具——通过 `scripts/i18n/localize-agents-zh.ps1` PowerShell 脚本将已安装的 Agent 的 YAML frontmatter `name` 和 `description` 字段替换为简体中文，提升中文用户在使用 Copilot Chat Agent 选择器时的体验。JSON 文件 `agent-names-zh.json` 作为翻译的唯一数据源（130+ 条目），脚本纯 ASCII 编码避免 PowerShell 编码问题，每次运行 `install.sh --tool copilot` 后需重新执行本地化。属 [[The Agency]] 多工具生态中的用户体验增强工具，与 [[readme|Qwen Code Integration]] 同属 Agency Agents 的集成功能，共同支持多语言/多工具环境。
 
 **Aider Integration**（[[aider-readme]]）：The Agency Agent roster 与 Aider 编辑器的集成方案——通过 `install.sh --tool aider` 安装，将全部 Agent roster 汇总到单一 `CONVENTIONS.md` 文件，Aider 会自动读取项目根目录的该文件。在 Aider 会话中按名称引用 Agent 即可激活（如 "Use the Frontend Developer agent to refactor this component."），或通过 `aider --read CONVENTIONS.md` 手动指定。`convert.sh --tool aider` 可重新生成最新的 CONVENTIONS.md。与 [[Windsurf Integration]]（.windsurfrules）、[[Cursor Integration]]（.mdc 规则）同为项目级 IDE 集成，共同构成 The Agency 的多编辑器支持生态。
 
@@ -74,7 +137,11 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
 
 **[[supply-chain-strategist]]**（Supply Chain Strategist Agent）：The Agency Specialized 部门的供应链管理专家 Agent——专注于中国制造业生态的端到端供应链优化。核心能力覆盖：供应商开发与分级管理（ABC 分类 + QCD 绩效考核）、战略采购（Kraljic 矩阵分类 + TCO 全成本分析）、质量管理（IQC/IPQC/OQC + AQL 抽样检验）、库存优化（EOQ + 安全库存 + 再订货点模型）、物流仓储（国内快递/零担/整车 + WMS 系统）、供应链数字化（ERP/SRM 系统选型 + 数字化成熟度评估 L1-L5）、成本控制（短期商业谈判到长期战略整合）和风险管理（多源采购 + 国产替代）。强调数据驱动决策（TCO 而非单价）+ 供应链安全优先（关键物料不得单一来源）。属 The Agency Specialized 部门的垂直领域专家 Agent，与工程类和营销类 Agent 共同构成完整的企业运营支持体系。
 
-**OpenCode Integration**（[[readme|OpenCode Integration]]）：The Agency Agent roster 与 OpenCode 编辑器的子 Agent 集成方案——通过 `./scripts/install.sh --tool opencode` 安装，将 The Agency 的 .md 文件格式 Agent 转换为 OpenCode 的 `.opencode/agents/` 目录格式。核心机制：在 YAML frontmatter 中添加 `mode: subagent` 使 Agent 仅在 `@agent-name` 触发时出现，不会在 Tab 循环列表中占位；颜色通过命名颜色到十六进制的自动映射实现。支持两种安装范围：项目级（`.opencode/agents/`）和全局级（`~/.config/opencode/agents/`）。与 [[readme|Cursor Integration]]（.mdc 规则）、[[github-copilot]]（用户级 Copilot）、[[windsurf-integration]]（.windsurfrules）同属 The Agency 的多 IDE 集成生态，[[integrations-readme]] 已覆盖所有集成工具概览。
+**[[hr-onboarding]]**（HR Onboarding Agent）：The Agency Specialized 部门的企业级新员工入职管理专家 Agent——覆盖从预入职准备到第一年结束的完整员工入职生命周期。核心理念：**"入职不是行政文书工作，而是员工职业故事的第一章"**。核心方法：五阶段工作流（预入职→入职第一天→第一周整合→30-60-90天里程碑→转入稳态）+ 十项关键行为规则 + 量化成功指标体系（I-9完成率100%/福利登记率≥95%/90天留存率≥95%）。与 [[recruitment-specialist]] 互补——招聘流程完成后进入入职流程，招聘专员负责提供入职日期和角色详情；与 [[support-legal-compliance-checker]] 共享合规框架——入职合规培训（文书+培训）依赖法律合规专家定义的多司法管辖区合规标准；与 [[compliance-auditor]] 存在视角差异（入职合规为底线硬性要求 vs 合规文化为长期深化过程，两者互补）。属 The Agency Specialized 部门的垂直领域专家 Agent，与招聘专员和法律合规专家共同构成完整的人力资源运营支撑体系。
+
+**[[specialized-chief-of-staff]]**（Chief of Staff）：The Agency Specialized 部门的高管主协调者专家 Agent——为创始人/高管提供全方位运营协调，充当主心骨与整个组织之间的"主协调者"。核心理念：**"我不在任何职能部门，但我拥有所有职能部门之间的空间"**；**"CoS 负责运转，高管负责领导，我让高管有空间做只有他能做的事"**。核心方法论：①**三层信息过滤器**——立即上报（影响公司目标/组织/避免偷袭）/ 处理后简报（小型修复）/ 暂存待问（优化建议），阈值随信任积累动态调整；②**文档依赖图维护**——当决策 X 变化时，主动识别所有受影响文档并级联更新，不遗漏任何一份；③**流程一致性保障**——格式、标准、SOP 必须 100% 执行，CoS 是最后一道防线防止忙碌工作冒充进步；④**影响力定位**——交付物不仅要创建，更要放在正确位置、在正确时机面向正确受众，位置错误等同于交付物不存在；⑤**ADHD 感知支持**——一次只呈现一件事，使用强视觉锚点，提供"离线标签"，温和引导偏离话题；⑥**多 Agent 编排**——维护任何单个 Agent 都不持有的全局上下文，防止矛盾输出和交接遗漏。与 [[project-manager-senior]] 互补但职责不同——项目经理专注特定交付物，CoS 专注组织整体运转和缝隙填补；与 [[support-infrastructure-maintainer]] 在流程维护上有协作关系。属 The Agency Specialized 部门的战略运营专家 Agent，与 NEXUS 框架中的 [[executive-brief]] 和 [[quickstart]] 共同构成战略→执行→协调的完整高层支撑体系。成功指标：高管零偷袭 / 零决策延迟（<48小时）/ 流程合规 100% / 文档同步 100%。
+
+**[[specialized-korean-business-navigator]]**（Korean Business Navigator）：韩国商业文化导航专家——The Agency Specialized 部门的韩国市场进入 Agent，专帮助外国专业人员解码韩国商业隐性规则，将西方直接性与韩国关系动态相结合。核心理念：**韩国"yes"不一定是同意，沉默是信息，成交发生在会议室外的走廊**。核心洞察：품의（共识审批）流程耗时 6-16 周（SME 6-10、中型 8-12、财阀 12-16），远长于西方的 2-4 周，永远不要在第一次会议要求决策时间线；永远不要绕过联系人越级上报；KakaoTalk 群聊必须使用韩语；永远不要在第一次对话中谈钱（关系→能力→价格三阶段）；회식（商务聚餐）出席是预期而非可选。关键方法：六阶段 품의时间线（소개→미팅→내부검토→품의서→결재→계약）、Nunchi 解码表（"검토해보겠습니다"实际意为"婉拒"）、分阶段 KakaoTalk 消息模板、韩国企业职级体系（회장→대리十级）、Proof Project 策略（有边界小项目降低感知风险）。属 The Agency Specialized 部门的垂直领域专家 Agent，与供应链、销售、市场营销 Agent 共同构成跨境业务运营支撑体系。
 
 **MCP Memory Integration**（[[mcp-memory-integration]]）：The Agency 的 MCP Memory 集成方案——通过在 Agent 提示词中加入标准化的 Memory Integration 段落，为任意 Agent 赋予跨会话持久记忆能力，无需修改 Agent 代码。MCP Memory Server 提供四个核心工具：`remember`（存储决策/交付物快照）、`recall`（跨会话检索）、`rollback`（失败时回滚到上一个检查点）、`search`（跨 Agent 搜索记忆）。**Rollback 是杀手级功能**——当 QA 检查失败或架构决策出错时，直接恢复到已知良好状态而非从头重建。标签一致性是关键：每个记忆使用 Agent 名称和项目名称作为标签，确保 recall 可靠。与 [[specialized-mcp-builder]]（构建 MCP Server）和 [[ai-memory-tools-two-camps]]（AI 记忆工具全景分类）同属 The Agency MCP 生态的核心组成部分。
 
@@ -100,6 +167,8 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
 
 **[[engineering-threat-detection-engineer]]**（Threat Detection Engineer）：威胁检测工程师 Agent——专注于构建检测层，在攻击者绕过预防控制后捕获威胁，核心理念：**"An undetected breach costs 10x more than a detected one, and a noisy SIEM is worse than no SIEM at all."** 核心能力：Sigma 规则开发（厂商无关）并编译为 Splunk SPL / Sentinel KQL / Elastic EQL / Chronicle YARA-L；MITRE ATT&CK 覆盖度映射与差距评估；威胁狩猎（基于情报、异常分析主动搜寻检测遗漏的威胁）；告警调优（通过允许列表、阈值调优和上下文富化降低误报）；Detection-as-Code CI/CD 流水线（Git + CI + 自动部署）。核心原则：检测质量 > 检测数量；行为检测优于 IOC 匹配（IP/哈希可日频轮换）；规则即代码——版本控制、peer review、测试、CI/CD 部署，绝不在 SIEM 控制台直接编辑；每个规则映射到至少一个 ATT&CK 技术；覆盖完整杀伤链（初始访问→横向移动→持久化→数据外泄）。关键量化指标：平均误报率 <15%、MTTD <48小时（关键 ATT&CK 技术情报→部署检测规则）、100% 规则通过 CI/CD 部署。与 [[engineering-backend-architect]] 在安全运营方面互补——Backend Architect 构建安全基础设施，Threat Detection Engineer 在其上构建检测层；属 The Agency Engineering 部门。
 
+**[[engineering-security-engineer]]**（Security Engineer）：应用安全工程师 Agent——专注于威胁建模、漏洞评估、安全代码审查、安全架构设计和事件响应的全链路应用安全专家，核心理念：**"You think like an attacker to defend like an engineer."** 核心原则：所有用户输入均为敌对输入（必须多边界验证清理）；默认拒绝（白名单优于黑名单）；安全失效（错误不泄露堆栈/路径/schema）；最小权限（IAM/DB/API/文件权限层层收紧）；不自定义加密（使用 libsodium/OpenSSL/Web Crypto API）；密钥神圣（禁止硬编码/日志/客户端代码/未加密环境变量）。核心安全体系：SDLC 全阶段安全集成（设计→实现→测试→部署→运营）；STRIDE 威胁建模（Spoofing/Tampering/Repudiation/Info Disclosure/DoS/Elevation of Privilege）；零信任架构（最小权限+微隔离）；防御深度（WAF→限流→输入验证→参数化查询→输出编码→CSP）；CI/CD 安全门禁（SAST/DAST/SCA/secrets 检测）；SBOM 与供应链安全监控。与 [[engineering-threat-detection-engineer]] 互补——Security Engineer 负责预防层（构建安全架构+代码门禁），Threat Detection Engineer 负责检测层（攻击后捕获）；与 [[engineering-backend-architect]] 共享"安全优先"原则，但 Security Engineer 专注于安全专业视角而非系统架构整体。属 The Agency Engineering 部门。
+
 **[[workflow-with-memory]]**（Multi-Agent Workflow: Startup MVP with Persistent Memory）：[[workflow-startup-mvp]] 的增强版——通过 MCP Memory Server 将手动复制粘贴交接升级为自动召回，实现"记忆服务器作为粘合剂"。核心机制：`remember` 存储 Agent 交付物（带项目名 + 接收方标签）、`recall` 自动召回上下文（无需人工粘贴）、`rollback` 回滚到上一个检查点（替代手动撤销）。Before/After 对比：手动交接（会话超时丢失 / 多 Agent 需重复编译上下文 / QA 失败需手动描述问题 / 跨多天项目需重建上下文）→ Memory 模式（跨会话持久 / 按标签共享 / 自动回滚 / 每次 pick up 继续）。核心标签策略：所有记忆用项目名标签（如 retroboard），交付物额外用接收 Agent 标签（如 frontend-developer），这是 recall 正常工作的前提。Rollback 是 QA 失败恢复的核心：回滚到检查点而非手动追踪变化。与 [[workflow-startup-mvp]] 的关系：两者不冲突，Memory 模式是原始工作流的增强层——Memory Server 可用时自动召回；不可用时沿用原始工作流的手动粘贴策略。
 
 **[[multi-channel-assistant]]**：基于 [[OpenClaw]] 的多渠道个人助理方案——以 Telegram Topic 路由为统一入口，整合 Google Workspace（gog）、Slack、Todoist、Asana，实现"说一句话完成全套工作"。核心价值：消除应用切换疲劳，AI 主动推送定时提醒（如每周垃圾清理、公司周报）。
@@ -219,6 +288,10 @@ The Agency 的 Support 部门涵盖数据分析、基础设施维护、法律合
 
 **[[support-executive-summary-generator]]**（Executive Summary Generator）：咨询级执行摘要生成 Agent——The Agency Support 部门的战略沟通专家，融合麦肯锡 SCQA、BCG 金字塔原理、贝恩行动导向三大顶级咨询框架，将复杂冗长的商业输入转化为 325-475 词的高管级执行摘要，确保 C-suite 决策者在 3 分钟内把握本质、评估影响、做出决策。核心理念：**洞察优先于信息，行动优先于描述**——每个关键发现必须包含量化数据点（≥1 个），不允许超越提供数据的假设，明确标记数据缺口。核心方法：四步流水线（Intake 分析 → SCQA/Pyramid 结构开发 → 执行摘要生成 → QA 验证）；输出格式严格遵循五段式结构（Situation Overview / Key Findings / Business Impact / Recommendations / Next Steps）；建议按业务影响排序（Critical / High / Medium），每条包含负责人+时间线+预期结果；高级能力包括统计验证的数据驱动洞察、行业基准对比分析、情景分析（最佳/最差/最可能）和价值 vs. 努力矩阵。成功指标：摘要阅读时间 <3 分钟、100% 发现含量化数据、325-475 词合规率 100%。与 [[support-analytics-reporter]] 协同——后者提供原始数据洞察，前者将其转化为高管可执行决策；与 [[support-legal-compliance-checker]] 协同——合规 Checker 的风险评估报告经 Executive Summary Generator 转化为高管行动建议；与 [[report-distribution-agent]] 协同——生成的执行摘要通过 Report Distribution Agent 分发给相关利益相关者。属 [[Multi-Agent-System-Reliability]] 的战略沟通层，为 C-suite 提供可执行的决策支撑文档。
 
+**[[healthcare-customer-service]]**（Healthcare Customer Service Agent）：医疗保健客户服务 Agent——The Agency Specialized 部门的患者支持专员 Agent，专注于患者预约管理、医疗账单、保险理赔、投诉处理和紧急响应场景。核心理念：**同理心优先**——在解决方案、流程、政策之前必须先承认患者的人性需求，"A patient isn't a ticket number"。核心方法：五步工作流（患者识别与情感评估 → 理解需求 → 解决或转接 → 确认解决 → 记录与跟进），结合 LEAP 降级技术（Listen/Empathize/Apologize/Partner）和 HIPAA 合规强制要求。十大黄金规则：绝不提供临床建议（所有临床问题立即路由给持牌临床人员）、身份验证前置（HINAME+DOB+SSN后四位）、紧急情况识别100%准确（胸痛/呼吸困难/中风症状立即指导911）、账单冻结（在审核期间）、承诺必须文档化、绝不将情绪困扰患者强制等待、有疑问立即升级、永不最小化患者顾虑、永不透露诊断或预后信息。
+
+**[[customer-service]]**（Customer Service Agent）：通用行业客户服务 Agent——The Agency Specialized 部门的全能客服专家 Agent，面向零售/SaaS/酒店/金融/电信/医疗行政/物流等多行业，提供全场景客户支持。核心理念：**"Customer service isn't a department — it's a philosophy"**——每个联系进来的客户都值得感到被重视、被理解，客服是将问题转化为忠诚的机会。五步工作流（Greet & Assess → Understand → Understand Inquiry → Resolve or Route → Confirm & Close → Document），**十大关键规则**（Empathy First / No "not possible" without alternative / Never blame customer / Own the problem / Proactive escalation before frustration peaks / No unfulfilled promises / Personalized every interaction / No hold without asking / Document everything / Warm close）。覆盖 FAQ/Account/Order/Complaint/Retention/Escalation 全类型，沟通渠道支持 Phone/Live Chat/Email/Social/SMS。属 [[hospitality-guest-services]] 和 [[healthcare-customer-service]] 的抽象基础——两者分别是客服 Agent 在款待业和医疗场景的具体化，共享投诉处理框架和升级协议，但各自增加行业专属合规要求（HEARD 框架/HIPAA）。
+
 ### The Agency — Paid Media 部门
 The Agency 的 Paid Media 部门专注于企业级付费媒体策略与运营，涵盖 Google Ads、Microsoft Advertising、Amazon Ads 三大核心平台。
 
@@ -254,7 +327,12 @@ Key concepts: [[PerformanceMax]], [[SmartBidding]], [[AccountArchitecture]], [[T
 
 **[[accounts-payable-agent]]**（Accounts Payable Agent）：The Agency 财务部门的自主支付运营专员 Agent——处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 等全支付通道。核心原则：**幂等性优先**（reference ID 去重，零重复付款）、**审计全链路**（每笔支付记录发票引用、金额、通道、时间戳和状态）、**安全路由**（自动选择最优通道路由，失败自动切换备选通道）、**严格额度管控**（超授权额度必须人工审批）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成，接收来自其他 Agent 的支付请求并生成支出报告供 Strategy Agent 分析。成功指标：零重复付款、< 2 分钟执行时间（快捷通道）、100% 审计覆盖、60 秒内 escalation SLA。属 [[Multi-Agent-System-Reliability]] 的财务合规执行层，[[Accounts-Payable-Agent]] 为 The Agency 提供可信赖的支付执行基础。
 
+**[[finance-tax-strategist]]**（Tax Strategist Agent）：The Agency Finance 部门的专业税务战略代理（代号 Cassandra）——在 Big Four 会计事务所、企业税务部门和精品税务咨询机构拥有 15 年+经验。核心理念：**"Tax isn't an afterthought; it's a strategic lever."** 核心使命：通过五阶段工作流（税务状况评估 → 机会识别 → 策略开发 → 实施合规 → 持续监控），使组织有效税率（ETR）达到行业同行中位数或以下。核心能力：多辖区税务优化（联邦/州/国际 GILTI/BEPS/FDII）、转让定价基准研究与 APA 申请、83(b) Election / QSBS 等股权激励税务筹划、R&D 税收抵免与加速折旧、BEAT 分析与税基侵蚀防控。标准化交付物：Tax Planning Memorandum（含立场强度评估 + 风险量化矩阵）和 ETR Analysis（含年度纵向对比 + 优化机会排序）。成功指标：ETR ≤ 行业中位数、零罚款利息、100% 按时申报、所有立场有同期文档支持、审计调整 < 2% 总税负。与 [[accounts-payable-agent]] 同属 Finance 部门——后者处理支付执行，前者专注税务筹划与合规，构成财务合规的双侧防护。与 [[accounts-payable-agent]] 和 [[support-finance-tracker]] 共同构成 The Agency Finance 部门完整的财务合规体系（支付合规/税务筹划/财务分析）。
+
+**[[finance-investment-researcher]]**（Investment Researcher Agent）：The Agency Finance 部门的专业投资研究代理（代号 Quinn）——14年+经验，覆盖买方权益研究、风险投资尽职调查和机构资产管理，已完成 200+ 家公司尽职调查并识别出多只 5 倍回报投资。核心理念：**"The best investments are found where rigorous analysis meets variant perception."**（当研究与共识一致时，不存在优势）。核心使命：生产机构级投资研究，发现 alpha、量化风险、支持数据驱动的投资组合决策。**五阶段工作流**：筛选与创意生成 → 初步评估 → 深度研究 → 论点构建与建议 → 持续监控。**双重论证框架**：牛市和熊市论点同等严谨，倡导胜于平衡即为营销而非研究。核心能力：基本面分析（财务、护城河、管理层评估、行业、ESG）、量化分析（DCF/可比公司法/残余收益/DDM、因子模型、风险指标）、尽职调查（私募/M&A/运营/市场）、另类数据集成（网页/App/专利/职位/卫星图像）。标准化交付物：Investment Research Report（含执行摘要、三情景 DCF、可比分析、竞争格局）和 Due Diligence Checklist（含 Red Flags 识别）。成功指标：风险调整回报高于基准、80%+ 论点终结触发器提前识别、DD 流程在投资决策前捕获 90%+ 实质性风险。与 [[finance-financial-analyst]]（Morgan）和 [[finance-tax-strategist]]（Cassandra）同属 Finance 部门——三方构成投资决策完整能力链：Morgan 负责财务建模与预算分析，Quinn 负责投资研究与估值，Cassandra 负责税务筹划，共同支撑 The Agency 的投资组合管理能力。
+
 ### Home Lab Infrastructure
+
 **[[家庭网络环境概览]]**（2026-04-03）：个人家庭网络的完整基础设施架构文档，记录了从公网 VPS（RackNerd）到内网各服务器的完整拓扑、应用部署和域名映射。核心架构：FRP（Fast Reverse Proxy）内网穿透 + Caddy 反向代理实现内网设备公网访问；Cloudflare DNS 托管提供免费 CDN 与 SSL 证书。
 
 **节点组成**：① **公网 VPS（RackNerd）** — 位于公网，运行 Caddy 和 FRP Server，是内网穿透的核心节点；② **Mac Mini M4 主控节点**（192.168.3.189）— 运行 OpenClaw AI 助手框架、vaultwarden 密码管理器、STQ 项目管理系统；③ **Synology NAS DS718 媒体中心**（192.168.3.17）— 运行 Jellyfin 媒体服务器、Navidrome 音乐流媒体、Calibre 电子书库、MinIO 对象存储、Prometheus 监控栈；④ **Ubuntu1 监控服务器**（192.168.3.47）— 运行 Grafana + Prometheus 监控栈、Apache Superset BI 平台、Homarr 导航面板、Transmission 下载客户端；⑤ **Ubuntu2 自动化服务器**（192.168.3.45）— 运行 n8n 工作流自动化平台、Gitea 自建 Git 服务、Draw.io 图表编辑器。
@@ -477,6 +555,8 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast
 
 **[[WSL2]]** 是 Windows 内置的 Linux 运行环境，WSL2 默认使用 NAT 网络模式导致 Windows 代理无法被 WSL2 内部访问。通过 `.wslconfig` 启用 `networkingMode=mirrored` + `dnsTunneling=true` 可实现 WSL2 与 Windows 共享网络堆栈；国内环境下可使用 `ghproxy.com` 反向代理加速 GitHub 下载。[[WSL2]] 与 [[Ubuntu Server]] 同属 Linux 环境，[[WSL2]] 侧重 Windows 桌面开发场景，[[Ubuntu Server]] 侧重无头服务器场景。
 
+**WSL2 Docker 容器代理配置**：[[WSL2-中-Docker-容器访问宿主机代理]] 补充了 WSL2 下 Docker 容器访问宿主机代理的具体方法——核心问题是容器内 `127.0.0.1` 指向容器自身而非宿主机，解决方法是用 `host.docker.internal`（Docker 内置 DNS，自动解析为宿主机 IP）替代。适用场景包括 pip/apt-get/curl 等各种命令的代理配置（示例端口 `10808`），代理软件（如 Clash）必须开启「允许局域网连接」。
+
 **[[ubuntu服务器通过rsync实现日常增量备份]]**：在已完成 Clonezilla 全盘镜像备份的基础上，通过 rsync 实现不关机的日常增量同步。核心架构：备份脚本（`/usr/local/bin/rsync_backup.sh`）+ Crontab 凌晨 3:00 自动执行 + NAS 作为备份目标。关键配置：①锁文件机制（`/tmp/rsync_backup.lock`）防止并发运行；②挂载点检查（`mountpoint -q`）防止 NAS 掉线时写入本地磁盘；③rsync 参数 `-azR --delete`（归档/压缩/保持相对路径/删除目标端多余文件）+ 排除规则（venv/__pycache__/.git）；④Docker 卷路径 `/var/lib/docker/volumes`；⑤数据库一致性建议（MySQL 先 `mysqldump` 再 rsync）。NFS 永久挂载通过 `/etc/fstab` 配置（`192.168.3.17:/volume2/backup /mnt/nas_backup nfs defaults,timeo=900,retrans=5,_netdev 0 0`），`_netdev` 参数确保网络就绪后再挂载。灾难恢复路径：单文件丢失→从 NAS 直接拷贝；系统崩溃但能 SSH→反向 rsync；硬盘彻底损坏→Clonezilla 镜像恢复 + rsync 同步最新增量（"时间点恢复"）。与 [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]] 共同构成完整 NAS 备份基础设施；与 [[Clonezilla对Ubuntu Server进行全盘镜像备份]] 形成"全量+增量"双层保护体系。
 
 **[[clonezilla对ubuntu-server进行全盘镜像备份]]**：使用 Clonezilla（再生龙）对 HP ZBook Ubuntu Server 进行全盘镜像备份的完整操作指南——①制作启动盘（Rufus + Clonezilla ISO，GPT+UEFI 新机器/DD 镜像模式备用）；②从旧笔记本 U 盘启动 Clonezilla live；③选择 `device-image` → `nfs_server` 模式，通过 NFS 将 NAS（192.168.3.17:/volume2/backups）挂载为镜像存储目标；④配置备份参数（Beginner 模式 → `savedisk` → 选择 `-z1p` 高压缩 → 跳过文件系统检查 `-sfsck`）；⑤确认后开始全盘克隆，生成日期格式镜像文件（如 `Ubuntu_Server_Ghost_20251220`）。灾难恢复时选择 `restoredisk` 选中镜像即可完整还原系统。与 [[Ubuntu服务器通过rsync实现日常增量备份]] 互补——Clonezilla 提供全量磁盘快照（低频），rsync 提供文件级增量同步（高频），构成"全量+增量"双层备份策略；恢复时先 Clonezilla 还原镜像，再用 rsync 同步最新增量（时间点恢复）。
@@ -530,6 +610,8 @@ Key concepts: [[Channel ID]], [[RSS Feed]], [[X/Twitter-API-Automation]], [[Soci
 
 **Docker 容器化部署**：[[n8n-docker-install-update]] 提供了完整的 n8n Docker 部署指南——通过自定义 Dockerfile 扩展官方镜像（安装 curl/wget）；配置 `ALL_PROXY=socks5://宿主机Docker网桥IP:10808` 实现容器内科学上网；配合 Caddy 反向代理提供 HTTPS 访问。版本更新方法：`docker compose pull` → `docker compose down` → `docker compose up -d`。
 
+**Docker Telegram 代理问题排查**：[[n8n-docker-配置-telegram-代理-troubleshooting]] 记录了 n8n 在 Docker 容器内通过 `host.docker.internal` 访问宿主机 xray/v2ray 代理的完整排查过程。核心要点：①容器内 `127.0.0.1:10808` 指向容器自身而非宿主机，必须用 `host.docker.internal`；②需在 `docker-compose.yml` 中配置 `extra_hosts: - "host.docker.internal:host-gateway"`；③Node.js 原生 `fetch` 不读代理环境变量（导致误判 ETIMEDOUT），但 n8n 使用 axios 会自动遵循 `HTTP_PROXY`/`HTTPS_PROXY` 环境变量。正确验证方法是用 n8n HTTP Request 节点直接测试 `api.telegram.org`。
+
 **入门教程**：[[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]] 提供了使用 N8N 构建 AI Agent 的完整指南，涵盖五类节点系统（Trigger/Action/Utility/Code/Advanced AI）、Agent 记忆机制、以及与 Airtable 等外部工具的集成方法。教程强调了 Agentic System 的核心概念：Agent 利用 LLM 动态选择工具，结合 Memory 实现上下文保持，使 AI 应用能够根据用户输入自适应响应。
 
 **Claude + N8N MCP 自动化工作流**：通过安装 [[n8n-mcp]]（Model Context Protocol 多功能控制面板），Claude 可理解并调用 543 个 N8N 节点，自动生成工作流。使用 OpenSea 模型 + Extended Thinking 模式可提升生成质量，Claude 生成的 N8N 工作流完成度约 80%-90%，仍需人工二次修正，但显著降低了新手的入门门槛。两种接入路径：**Claude Desktop** 端侧方案（适合桌面用户，通过本地 MCP 连接 n8n）与 **Claude API** 云端方案（适合程序化集成），核心均依赖 [[Node.js]] 运行环境。
@@ -572,6 +654,8 @@ Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP vi
 
 **[[fireworks-tech-graph]]**：Claude Code Skill，将自然语言描述转化为精美 SVG 技术图并导出 PNG——解决技术文档/博客缺乏高质量可视化图表、手动绘图耗时且风格不统一的核心痛点。内置 **7 种视觉风格**（扁平图标风/暗黑极客风/工程蓝图风/Notion极简风/玻璃态卡片风/Claude官方风格/OpenAI官方风格）和 **14 种 UML 图类型**，深度覆盖 AI/Agent 领域常见 Pattern（RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等）。语义形状词汇表确保图形语义一致（LLM=双边框圆角矩形、Agent=六边形、Vector Store=带内环圆柱），语义箭头系统通过颜色+虚线编码含义（主数据流/控制触发/记忆读取/写入/异步/反馈循环）。通过 `rsvg-convert` 导出 1920px PNG，可直接嵌入文章发布。安装：`npx skills add yizhiyanhua-ai/fireworks-tech-graph`，依赖 `librsvg`（macOS: `brew install librsvg`，Ubuntu: `sudo apt install librsvg2-bin`）。核心价值：**AI Agent 可快速生成专业级技术图，无需手动绘制**，支持 SVG 可编辑 + PNG 无损发布。
 
+**[[baoyu-skills]]**（宝玉 Claude Code 技能集）：[[JimLiu]]（宝玉）维护的 Claude Code Skills 仓库（github.com/JimLiu/baoyu-skills）——覆盖内容生成（xhs-images/infographic/diagram/cover-image/slide-deck/comic/article-illustrator）、多平台发布（X/微信/微博）和 AI 图像生成（baoyu-imagine，支持 OpenAI/Google/DashScope/MiniMax/即梦/豆包等 10+ provider）以及工具集（YouTube 字幕/URL 转 Markdown/翻译/图片压缩/Markdown 处理）。核心方法论：**多维度图像生成系统**——通过类型×风格×配色×渲染×氛围等正交维度组合控制 AI 生成输出，覆盖信息图（20 种布局×17 种风格）、小红书卡片（12 种风格×6 种布局）、封面图（6 种类型×11 种配色×7 种渲染）等多个场景；**三档翻译系统**（快速/标准/精翻）提供渐进式翻译质量；**baoyu-diagram** 不调用图像生成模型，由 LLM 直接手写 SVG 代码生成图表并内嵌深色模式。Claude Skills 范式（[[3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1]]）将 baoyu-skills 的方法论提升为 AI 应用从「提示词工程」向「流程工程」转变的典型案例，属 [[AI Tools & Prompt Engineering]] 的 Claude Skills 生态层。
+
 **Claude Prompt Library**（[[useful-prompt-lib]]）：Anthropic 官方提示词库，收录 64+ 款专业化提示词，覆盖开发工具（Python Bug Buster、Code Consultant、Git Gud）、效率工具（Data Organizer、Review Classifier、CSV Converter）、创意工具（Storytelling Sidekick、Culinary Creator）、营销工具（Babel's Broadcasts 多语言推文、Polyglot Superpowers 互译）、教育工具（Meeting Scribe、Lesson Planner、Socratic Sage）等 10+ 领域。TikTok 跨境电商推荐三剑客：Babel's Broadcasts（10 种语言产品发布）、Review Classifier（评论自动化分类）、Data Organizer（非结构化文本→JSON，对接 n8n 工作流）。
 
 **LLM / RAG / AI Agent 三层架构**：基于 [[llms-rag-ai-agent-三个到底什么区别]] 的系统梳理，AI 应用的三层架构：
@@ -638,6 +722,8 @@ Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP vi
 
 **[[Nano Banana Pro 提示词指南]]**：谷歌发布的 Nano Banana Pro 官方提示词指南（《The Complete Guide to Nano Banana Pro: 10 Tips for Professional Asset Production》，含上下两篇），凌晨无预警发布，核心主题是"将 AI 从趣味性图像生成升级为功能性专业资产生产"。核心理念：**停止标签堆砌，像创意总监一样思考**。核心突破：意图理解引擎实现物理规则推演、构图美学理解和语义上下文推理（而非传统关键词匹配）。关键能力：支持 14 张参考图像（6 张高保真）实现"身份锁定"；默认生成思考图像（不收费）后再输出最终结果；支持 1K-4K 原生高分辨率；[[Google Search]] 信息锚定减少实时内容幻觉。10 大黄金法则包括：编辑而非重新生成、使用自然语言完整句子、具体且具描述性、提供上下文（"为什么"或"为谁"）。上篇（[[nano-banana-pro-prompting-guide-strategies-1]]）覆盖前 9 个能力域（文本渲染/信息图、角色一致性/病毒缩略图、Google 搜索信息锚定、高级编辑/修复/着色、2D/3D 维度转换、高分辨率/纹理、思考推理、故事板/概念艺术、结构控制/布局引导），附大量可直接复制的实战提示词模板。与 [[清华出的DeepSeek使用手册]] 同属 AI 工具方法论指南——前者聚焦 DeepSeek 文本推理，后者聚焦 Nano Banana Pro 图像生成；与 [[nano-banana-提示词框架]]（Nano Banana 基础框架）和 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]（Nano Banana 2 综合指南）同属 Nano Banana 提示词体系的不同层次。
 
+**[[open-webui-hermes-agent]]**（Open WebUI + Hermes Agent 集成）：Hermes Agent 官方文档，详细说明如何将 [[OpenWebUI]]（126k★ 最流行自托管 AI 聊天界面）作为 Hermes Agent 的 Web 前端接入。核心机制：Hermes Agent 内置 OpenAI 兼容 API Server（`API_SERVER_ENABLED=true`），Open WebUI 通过 Docker 部署后配置 API URL 和 Key 接入，双方 server-to-server 直连无需 CORS 配置。关键配置：API Server 端口默认 8642，Docker 容器内必须用 `host.docker.internal` 访问宿主机。支持两种 API 模式——Chat Completions（默认，推荐）和 Responses API（实验性，支持结构化事件流）。多用户场景通过 Profiles 实现隔离，每个 Profile 运行独立 API Server（不同端口）。工具执行时实时流式输出工具 emoji 到 UI（ToolStreaming），提升可见性。是 [[Ollama 本地 LLM 部署]] 中 Open WebUI 使用场景的扩展——后者侧重 Ollama 后端，本页侧重 Hermes Agent 后端。
+**[[Hermes-Agent-配置笔记]]**（Hermes Agent 多角色配置实战）：记录 Vibe Coding 多角色 Agent 配置的核心方法，涵盖四个关键场景。**角色分层配置**：SOUL.md（`~/.hermes/SOUL.md`）定义全局角色人设（身份定位、思维方式、沟通风格），AGENTS.md（项目根目录）定义项目级技术栈和开发约定，两者职责分明，避免每次对话重复配置。**多 Profile 隔离**：`hermes profile create --clone` 创建独立 Agent 实例，每个 Profile 拥有独立的 SOUL.md、配置、记忆、会话历史和技能，实现多角色完全隔离。**Telegram Bot 接入**：Telegram Bot 无响应的四大根因——Gateway 未启动（最常见）、Token 配错 Profile、用户 ID 未加入白名单（`TELEGRAM_ALLOWED_USERS`）、同一 Token 被两个 Gateway 共享导致冲突。**国内网络代理**：Telegram 在国内被封，通过 Profile 的 .env 配置 `HTTPS_PROXY`/`HTTP_PROXY` 环境变量解决，同一 Token 被两个 Gateway 共享导致冲突；重启 Gateway 后验证连接状态。是 [[open-webui-hermes-agent]] 的配置前置知识——后者侧重前端接入，前者侧重角色配置与网络层。
 **[[Ollama 本地 LLM 部署]]**：基于 [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]] 的完整实操指南，展示如何使用 Ollama + DeepSeek-R1 + Open WebUI 在本地离线部署大模型。核心价值：**免费、无需 API Key、数据完全私有**。Ollama 跨平台支持（macOS/Windows/Linux/Docker），通过 `ollama run deepseek-r1:8b` 一键运行；国内网络环境下可通过魔塔社区（modelscope.cn）或 HuggingFace Mirror（hf-mirror.com）加速下载；云服务器部署必须通过 nginx + Bearer Token 保护 API 防止恶意调用；Open WebUI 提供浏览器端 Web 界面，支持 RAG 本地知识库（bge-m3 嵌入模型）和联网搜索。硬件要求：1.5B 模型需 4GB RAM，7B 需 16GB RAM，32B 需 64GB RAM+48GB 显存（Apple M2 Max 可流畅运行 32b 及以下）。
 
 **[[Qwen2.5-Coder]] 部署实战**（[[在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b]]）：Ubuntu 上通过 Ollama 本地部署 Qwen2.5-Coder 7B 代码生成模型，3条命令完成安装（`curl -fsSL https://ollama.com/install.sh | sh && ollama pull qwen2.5-coder:7b && ollama run qwen2.5-coder:7b`）。推荐配置：8+ CPU cores + 16GB RAM + NVIDIA GPU（CUDA 自动加速）。**qwen2.5-coder:7b 因 Tool usage 能力强、Shell/Python/SQL 理解强、Repo 级代码理解强，比普通 qwen2.5:7b 更适合工程任务**。支持 REST API（默认 localhost:11434）和 Python/Node.js SDK，可与 [[Open WebUI]]、[[n8n]]、[[OpenClaw]] 等工具集成构建本地 AI 应用栈。与 [[Ollama 本地 LLM 部署]]（DeepSeek-R1）同属 Ollama 本地部署场景，本方案侧重 Qwen2.5-Coder 的代码生成能力优势。
@@ -714,7 +800,7 @@ Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Suff
 
 | Category | Count | Key Sources |
 |----------|-------|-------------|
-| The Agency Agents | 147+ agents | README, CONTRIBUTING, 12 divisions |
+| The Agency Agents | 147+ agents | README, CONTRIBUTING, 12 divisions, integrations/qwen |
 | CTP Topics | 73 topics | AWS, Azure, FinOps, Security |
 | Learning Sessions | 30+ sessions | OpenText, AWS, EKS, Cloud FinOps |
 | Home Office | 60+ docs | Docker, NAS, Network, Monitoring |
@@ -872,7 +958,9 @@ Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Suff
 
 **[[做TK跨境思路不对努力白费]]**：TikTok 跨境电商全流程实战指南——从市场选择（优先美区/日本，避开东南亚）→ 账号准备（选区看直播了解流程）→ 选品策略（数据软件分析+单一垂直类目）→ 店铺运营（流量监控+商品优化）→ 流量获取（短视频营销+达人合作）→ 仓储物流（海外仓+海运补货）→ 团队建设（招聘分工），提供完整的执行框架。核心观点：思路正确是成功的前提，市场定位和选品是核心竞争力。与 [[电商如何选品]] 同属选品策略范畴，与 [[TikTok E-commerce Product Management]]（Django 产品管理系统）互补——前者侧重运营策略，后者侧重技术实现。
 
-**电商数据采集与处理系统**：基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统。三层架构：爬虫层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。推荐 Scrapy + Playwright 组合抓取动态页面，Docker Compose 容器化部署，输出 JSON/CSV 供 n8n 消费；n8n 工作流实现定时启动爬虫→读取数据→LLM提取属性→写入数据库→报表通知的全链路自动化；AI 处理任务包括摘要分类、多语言翻译、特征提取、异常检测；本地可使用 Ollama（Mistral/Llama3）通过 HTTP Request 调用，无需外部 API Key；防封策略包括 User-Agent 轮换、代理池（Bright Data/ScraperAPI）和下载延迟随机化。与 [[做TK跨境思路不对努力白费]]（运营策略）互补，后者侧重电商运营全流程，前者侧重技术架构搭建。与 [[scrapy-playwright-抓取tiktok-shop-data]] 同属电商数据采集技术栈。
+**Scrapy + Playwright 抓取 TikTok Shop Data**：基于 [[Scrapy---Playwright-抓取TikTok-Shop-Data]] 的 TikTok Shop 店铺数据爬取实战笔记。核心方法：通过 Python venv 隔离项目依赖，安装 `scrapy` + `scrapy-playwright`，配置 Playwright Chromium 浏览器，实现 JS 渲染页面抓取。Docker 部署需在 Dockerfile 中添加 venv 创建和 PATH 配置命令。验证安装成功的命令：`python -c "from playwright.sync_api import sync_playwright; print('Playwright OK')"`。与 [[电商数据采集与处理系统]]（三层架构中的爬虫层）和 [[TikTok Shop - Apache Superset Dashboard设计思路]]（数据可视化层）共同构成 TikTok Shop 数据采集→处理→展示完整链路。
+
+**电商数据采集与处理系统**：基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统。三层架构：爬虫层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。推荐 Scrapy + Playwright 组合抓取动态页面，Docker Compose 容器化部署，输出 JSON/CSV 供 n8n 消费；n8n 工作流实现定时启动爬虫→读取数据→LLM提取属性→写入数据库→报表通知的全链路自动化；AI 处理任务包括摘要分类、多语言翻译、特征提取、异常检测；本地可使用 Ollama（Mistral/Llama3）通过 HTTP Request 调用，无需外部 API Key；防封策略包括 User-Agent 轮换、代理池（Bright Data/ScraperAPI）和下载延迟随机化。与 [[做TK跨境思路不对努力白费]]（运营策略）互补，后者侧重电商运营全流程，前者侧重技术架构搭建。与 [[Scrapy---Playwright-抓取TikTok-Shop-Data]] 同属电商数据采集技术栈。
 
 ### TikTok E-commerce Product Management
 A comprehensive Django-based product data management system for TikTok Shop. Covers Django ORM models (Product, ProductImage, ProductVideo, ProductVariation, ProductReview), Django Admin customization (TinyMCE rich text, inline models, image preview modals), REST API via Django REST Framework with django-filter for search and filtering, Docker + Gunicorn + Nginx production deployment, Django-Q async task queue for Bright Data API scraping, and custom Management Commands for JSON data import. Key components: Product list with thumbnail display, multi-condition filtering by store_name, bulk product fetch via Bright Data asynchronous API, description detail HTML generation, and Apache Superset BI dashboard integration.
@@ -940,6 +1028,8 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
 ### Sales Outbound Methodology
 **[[sales-outbound-strategist]]**（Outbound Strategist Agent）：信号型出站销售策略师，将出站销售从"批量轰炸"转变为"精准触发"——核心信念：出站应由证据驱动，而非配额驱动。核心理念：**信号驱动出站转化率比无触发出站高 4-8 倍**；信号的半衰期极短（30 分钟内必须路由到正确销售），24 小时后信号失效，72 小时后竞争对手已成交。核心框架：三层信号分级体系（Tier 1 主动购买信号如 G2 访问/竞品对比 → Tier 2 组织变化信号如融资/招聘/领导层变动 → Tier 3 技术/行为信号如技术栈变化/内容互动）+ 可证伪 ICP 定义（含排除条件，否则是 TAM 幻灯片）+ 三层账户分级（Tier 1 深度多线程个性化 / Tier 2 半个性化序列 / Tier 3 自动化轻定制）+ 8-12 触点 3-4 周多渠道序列（每次触达必须提供新的价值角度）。冷邮件回复率基准：泛化型 1-3%、角色定制 5-8%、信号驱动 12-25%、推荐引入型 30-50%。SDR 角色演变：从每天 100 次活动的批量操作员 → 拥有 50-80 个深度账户的信号监控管线专家。与 [[sales-discovery-coach]] 协同——发现阶段收集的 ICP 信号直接驱动出站序列启动；与 [[sales-deal-strategist]] 形成漏斗互补——出站负责漏斗顶部（Signal → Contact），Deal Strategist 负责漏斗中部（Qualified → Commit）；与 [[sales-account-strategist]] 形成客户生命周期互补——出站获取新客户，Account Strategist 负责 Land-and-Expand 扩张。
 
+**[[sales-outreach]]**（Sales Outreach Agent）：B2B 销售外勤 Agent 的完整角色定义与可执行框架——核心信念：最佳销售人员不推销，而是帮助客户购买。覆盖从潜客挖掘（ICP 定义、触发事件识别）到冷开拓（7 步触达序列：冷邮件→LinkedIn→跟进→电话→内容→断联邮件）、异议处理（以好奇心探索而非反驳）、提案撰写（口头对齐后才发送，24 小时内完成）到管道管理（7 阶段：Prospecting→Engaged→Discovery→Solution→Proposal→Negotiation→Closed）的完整生命周期。核心销售方法论：[[Consultative Selling]]（咨询式销售）、[[SPIN Selling]]（Neil Rackham 四步提问法）、[[Challenger Sale]]（商业洞察引领对话）、MEDDIC/MEDDPICC（复杂销售八维度资质框架）。关键原则：100% 个性化（不满足 ≥2 次条件的实体在 Source Page 内 wikilink 引用）；每条消息单一 CTA；永远先提供价值再提产品；断联邮件往往回复率最高。与 [[sales-outbound-strategist]] 互补——后者聚焦信号驱动规模化出站策略，前者提供一对一个性化执行细节；与 [[sales-engineer]] 协同——外勤 Agent 负责建立初次接触并完成 Discovery，Sales Engineer 在此基础上进行技术评估。
+
 ### Sales Discovery Methodology
 **[[sales-discovery-coach]]**（Discovery Coach Agent）：销售发现访谈（Discovery）方法论与教练框架，帮助销售代表和SDR成为更优秀的买家访谈者——坚信发现阶段才是交易成败的真正战场，而非演示、提案或谈判阶段。
 
@@ -977,6 +1067,8 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
 
 **[[blockchain-security-auditor]]**（Blockchain Security Auditor）：The Agency Specialized 部门的智能合约安全审计 Agent——专职发现 DeFi 协议与区块链应用中的漏洞，在攻击者之前找到 bug。核心理念：**"Your job is not to make developers feel good — it is to find the bug before the attacker does."** 核心理念：自动化工具只能捕获约 30% 的真实漏洞；每个发现必须包含可复现 PoC；使用 OpenZeppelin 不等于安全（误用安全库本身是漏洞类型）；必须验证代码与部署字节码一致（供应链攻击真实存在）；Solidity 0.8+ 的 `unchecked` 块仍需审查；漏洞发现误报率必须控制在 10% 以下。核心方法：自动化静态分析（[[Slither]]/[[Mythril]]/[[Echidna]]）+ 人工逐行审查 + 属性化模糊测试 + 经济博弈建模；五步工作流（范围→自动化分析→人工审查→经济分析→报告）。交付物包含完整审计报告模板（Severity 分类表 + 详细 Finding 结构 + Foundry PoC）、Slither 综合分析脚本（高/中置信度分类）、访问控制审计清单（Role Hierarchy/Initialization/Upgrade Controls/External Calls）。高级能力涵盖形式化验证（[[Certora]]/[[Halmos]]/KEVM）、EVM 层漏洞（存储冲突/签名重放/跨链消息重放）、事件响应（攻击溯源 + 救援合约）。漏洞评级严格化：能导致用户资金损失的发现不得降级为 Informational；C-01/H-01 必须在部署前修复；Medium 可随监控计划上线。与 [[Agents-Orchestrator]] 构成审计质量门控——流水线交付前须通过安全审计；与 [[Compliance-Auditor]] 同属审计类 Agent，但前者聚焦代码层智能合约安全，后者聚焦企业合规认证框架。
 
+**[[engineering-solidity-smart-contract-engineer]]**（Solidity Smart Contract Engineer）：The Agency Engineering 部门的 EVM 智能合约开发专家 Agent——专注于 EVM 兼容链（以太坊主网及 L2）的安全合约架构、Gas 优化和 DeFi 协议开发。核心理念：**"Treat every wei of gas as precious, every external call as a potential attack vector, and every storage slot as prime real estate."** 与 [[blockchain-security-auditor]] 构成互补关系——前者专注于开发实现（安全开发+Gas优化+可升级架构），后者专注于攻击发现（渗透测试+漏洞挖掘）。核心交付物：安全合约模板（ERC-20/721/1155 含 AccessControl/Pausable）、UUPS/Staking Vault 可升级合约模式、Foundry 测试套件（>95% 分支覆盖率）、Gas 优化参考模式（存储打包/calldata/自定义错误）。关键原则：checks-effects-interactions 模式（非重入根本保障）、never use `tx.origin`（始终使用 `msg.sender`）、pull-over-push 优先（避免 DoS）、OpenZeppelin 优先（不重新发明密码学轮子）。五步工作流：需求与威胁建模→架构与接口设计→实现与 Gas 性能分析→测试与形式化验证→审计准备与部署。Gas 优化核心要点：存储打包节省约 5000 gas/写入；calldata 替代 memory 节省约 60 gas/参数；custom errors 较 require 字符串节省约 50 gas/ revert；immutable/constant 避免 SLOAD 消耗。|
+
 **[[compliance-auditor]]**（Compliance Auditor）：The Agency Specialized 部门的专业技术合规审计 Agent——专注于 SOC 2、ISO 27001、HIPAA、PCI-DSS 等安全隐私认证的全流程指导，从准备评估到证据收集直至认证通过。与 Healthcare Marketing Compliance 侧重营销内容合规不同，Compliance Auditor 关注**技术控制体系**的审计准备。核心方法：五步工作流（Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance）；核心原则：**不跟随的政策比没政策更危险**（Checkbox-Compliance 是反面教材）、**证据必须证明整个审计周期内持续有效**（而非仅当下存在）、**自动化证据收集从第一天建立**（手动流程无法扩展）、**技术控制优于管理控制**（代码比培训更可靠）。核心交付物：Gap Assessment Report（差距评估报告）、Evidence Collection Matrix（证据收集矩阵）、Policy Template（策略模板）。成功指标：零不合格发现（zero adverse findings）、审计周期缩短 30%、年度合规状态持续可查。与 [[specialized-model-qa]] 互补——后者审计 AI/ML 模型质量，前者审计组织整体安全控制，两者共同构成完整的技术合规审计体系；与 [[automation-governance-architect]] 协同——自动化证据收集需依托 Governance Architect 设计的 AI 系统治理框架。
 
 |**[[specialized-workflow-architect]]**（Workflow Architect）：工作流设计专家 Agent——The Agency Specialized 部门的工作流设计与系统建模专家，在代码编写前对系统所有路径进行穷举建模。核心职责：**工作流发现**（扫描 route/worker/migration/IaC/cron/event-listener/webhook 文件找出隐式工作流）+ **工作流注册表维护**（四视角：按工作流/按组件/按用户旅程/按状态）。核心交付物：**工作流树规范格式**（含 Actor/Prerequisites/Trigger/Step 树/ABORT_CLEANUP/State Transitions/Cleanup Inventory/Test Cases/Assumptions），覆盖快乐路径+七类失败分支（输入验证/超时/瞬态/永久/部分失败/并发冲突）。关键原则：**不只为快乐路径设计**、**每个系统边界定义显式 Handoff Contract**（payload schema + 成功/失败响应 + 超时值 + 恢复动作）、**Reality Checker 验证是 Draft 升为 Approved 的前置条件**、**每个分支必须有对应测试用例**（无测试覆盖的分支在生产中断言）。Agent 协作协议：Reality Checker 验证规范→Backend Architect 实现代码→API Tester 生成测试用例→DevOps Automator 验证清理顺序→Security Engineer 审查凭证传递。高级能力：**好奇心驱动式 Bug 发现**（追问数据持久化假设/网络连通性假设/时序假设/认证假设，主动发现高危 Bug）。成功指标：假设表随时间持续缩减、注册表中无 Missing 状态工作流残留超过一个 Sprint、零孤岛资源。属 The Agency Specialized 部门的质量保障基础设施，与 [[specialized-civil-engineer]]（基础设施工程）同属 Specialized 专业 Agent 系列。
@@ -1205,3 +1297,7 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
 
 32. **Feishu Integration Developer Agent：飞书开放平台全栈集成专家 Agent**：[[engineering-feishu-integration-developer]] 定义了一种专注于飞书（Feishu/Lark）开放平台企业级集成的 AI Agent，覆盖自定义机器人、交互式消息卡片、审批流自动化、Bitable 多维表格、SSO/OIDC 认证和飞书小程序六大核心模块。核心理念：**飞书集成不只是调用 API**，必须处理权限模型、事件幂等性、多租户架构和与内部系统的深度集成。核心工程标准：`tenant_access_token`（应用级）与 `user_access_token`（用户级 OAuth）必须严格区分使用场景；所有 API 响应必须检查 `code` 字段；事件处理必须实现幂等性（飞书可能重复投递同一事件）；卡片 JSON 必须在 Card Builder 工具验证后才发送；Bitable 批量写入每请求上限 500 条需分批并建议批次间 200ms 延迟。核心交付物：完整项目结构（config/auth/bot/approval/bitable/sso/webhook 目录）、TokenManager 缓存实现（含提前5分钟刷新边界保护）、CardBuilder 审批通知卡片（含 Approve/Reject/View Details 三按钮）、EventDispatcher 事件分发（含 Bot 消息接收和审批状态变更监听）、BitableClient CRUD（含 500 条分批写入）、OAuth 授权登录三步流程（authorize 重定向 → code 交换 → user_info 获取，state 参数防 CSRF）。成功指标：API 调用成功率 >99.5%、事件处理延迟 <2 秒、卡片渲染成功率 100%、Token 缓存命中率 >95%、审批流端到端时间缩短 50%+。属 The Agency Engineering 部门的集成专精层，与 [[engineering-backend-architect]] 在 API 集成架构上有协同空间；与 [[engineering-rapid-prototyper]] 在速度哲学上存在张力：原型阶段可简化幂等性和错误处理，生产化阶段必须补充完整错误恢复机制。
 
+33. **Language Translator Agent：意义转移型西英翻译专家 Agent**：[[language-translator]] 定义了一种超越逐字替换的实时西班牙语 ↔ 英语翻译 AI Agent，核心理念：**翻译 = 意义转移，非词典替换**——目标不是字典输出，而是对方能实际理解的信息。核心设计：①**5 步工作流**（理解请求 → 意义翻译 → 输出丰富化 → 特殊处理 → 跟进），②**发音标注**（为口语短语提供英语拼音而非 IPA），③**语域标注**（明确正式/非正式，usted/tú 选择），④**地域变体**（标注同一词汇在不同西语国家的差异），⑤**文化注释**（主动标注跨国家/地区的文化敏感性差异），⑥**紧急优先**（医疗/安全/法律短语立即呈现，解释后补）。覆盖六大场景：旅行（方向/餐厅/酒店/交通）、医疗（症状/药物/急诊）、商务（会议/邮件/合同）、法律（证件/权利/官员对话）、日常（问候/闲聊/社交）、书面文档。语言学知识点：Ser vs Estar（两个"to be"不可互换）、虚拟式（subjunctive 在愿望/怀疑/情感场景的强制使用）、假同源词陷阱（embarazada=怀孕、sensible=敏感、éxito=成功）。方言覆盖：墨西哥西语（纳瓦特尔语借词）、卡斯蒂利亚西语（c/z 发 th 音，vosotros）、阿根廷/乌拉圭 Rioplatense（vos 替代 tú）、哥伦比亚（正式 usted 习惯）、加勒比（语速快、辅音弱化）。与 [[Customer Service Agent]] 和 [[Healthcare Customer Service Agent]] 共享紧急响应和语气适配原则，属 The Agency Specialized 部门的语言服务支柱。
+
+34. **Bookkeeper & Controller Agent：财务主管 AI Agent**：[[finance-bookkeeper-controller]] 定义了一种名为"Dana"的专业会计主管 AI Agent，拥有13年+经验，专精日常会计运营、月结流程和内部控制。核心理念：**准确性是不可协商的底线**——快速结账很好，但准确结账是必须达成的目标，速度必须服从准确性。核心能力：①**月结Checklist**（Pre-Close → Core Close → Reconciliations → Financial Statements → Review），将月末结账周期从10天压缩至7天，AP自动化后可达5天；②**GAAP合规框架**（ASC 606/842/718/805），确保所有交易符合会计准则；③**职责分离**（Segregation of Duties），交易发起人与审批/记录人不得为同一人；④**审计就绪**，日常维持审计就绪状态，审计师可随时进场，24小时内提供任何余额支持文件；⑤**账户调节模板**，每个资产负债表科目每月必须调节，未调节余额视为"定时炸弹"。关键工具栈：QuickBooks/Xero/NetSuite（ERP）、FloQast/BlackLine（结账管理）、Bill.com/Tipalti（AP自动化）、Expensify/Ramp（费用管理）。与 [[Finance FPA Analyst]] 协同工作——Dana提供高质量财务数据供 FP&A 做预算差异分析，两者共享"准确数据驱动决策"理念，但存在速度 vs 准确性的内在张力；与 [[Finance Tax Strategist]] 共享季度税项计算和年度税表协调。与 [[Accounts Payable Agent]] 存在协作关系，前者负责AP处理流程，后者（Dana）负责AP数据审核和账务记录。
+
diff --git a/wiki/sources/Hermes-Agent-配置笔记.md b/wiki/sources/Hermes-Agent-配置笔记.md
new file mode 100644
index 00000000..d1a8bb90
--- /dev/null
+++ b/wiki/sources/Hermes-Agent-配置笔记.md
@@ -0,0 +1,48 @@
+---
+title: "Hermes Agent 配置笔记"
+type: source
+tags: ["hermes", "agent", "configuration"]
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/Hermes Agent 配置笔记]]
+
+## Summary（用中文描述）
+- 核心主题：Hermes Agent 的多角色配置与 Telegram 集成实战
+- 问题域：Vibe Coding 多角色 Agent 场景下的身份隔离、Telegram Bot 连接与国内网络代理问题
+- 方法/机制：SOUL.md 角色人设 + AGENTS.md 项目背景双文件分层；`hermes profile` 创建独立 Agent 实例；Gateway 代理配置解决 Telegram 连接问题
+- 结论/价值：提供了一套完整的 Hermes Agent 多角色配置体系，覆盖身份定义、Profile 隔离、Telegram 接入、网络代理全链路
+
+## Key Claims（用中文描述）
+- SOUL.md 定义角色人设（全局生效，随 Agent 走），AGENTS.md 定义项目背景（项目级生效，随项目走），两者分工明确
+- `hermes profile create --clone` 创建独立 Agent 实例，每个 Profile 拥有独立的 SOUL.md、配置、记忆、会话历史和技能
+- Telegram Bot 无响应的根因通常是 Gateway 未启动、Token 配错 Profile 或用户 ID 未加入白名单
+- Telegram 在国内被封，需在 Profile 的 .env 中配置代理（HTTPS_PROXY/HTTP_PROXY）才能正常连接
+
+## Key Quotes
+> "配置 token ≠ gateway 在运行，新 profile 需要单独启动。" — Telegram Bot 无响应的最常见原因
+> "每个 profile 的 .env 需要单独配置，互不共享。" — 代理配置隔离原则
+> "同一个 token 被两个 gateway 同时使用会导致两个 gateway 互相冲突，都无法正常收消息。" — Token 独占性要求
+
+## Key Concepts
+- [[SOUL]]：角色人设文件，定义 Agent 的身份、思维方式、沟通风格，位于 `~/.hermes/SOUL.md`
+- [[AGENTS-md]]：项目背景文件，定义技术栈、架构、开发约定，位于项目根目录的 `AGENTS.md`
+- [[Multi-Profile-Isolation]]：多 Profile 隔离机制，每个 Profile 拥有独立的配置、会话、记忆，实现角色分离
+- [[Telegram-Bot-Gateway]]：Telegram Bot 通过 Hermes Gateway 接入，Gateway 需单独启动
+- [[Proxy-Configuration]]：代理配置，通过 HTTPS_PROXY/HTTP_PROXY 环境变量解决 Telegram 在国内的连接问题
+
+## Key Entities
+- [[Marty-Cagan]]：《Inspired》作者，产品经理角色命名来源
+- [[Werner-Vogels]]：Amazon CTO，架构师角色命名来源
+- [[Hermes-Agent]]：本文档的主体工具，Vibe Coding 多角色 Agent 框架
+
+## Connections
+- [[Hermes-Agent]] ← configured_by ← [[SOUL]]
+- [[Hermes-Agent]] ← configured_by ← [[AGENTS-md]]
+- [[Multi-Profile-Isolation]] ← enables ← [[Hermes-Agent]]
+- [[Telegram-Bot-Gateway]] ← depends_on ← [[Hermes-Agent]]
+- [[Proxy-Configuration]] ← solves ← [[Telegram-Bot-Gateway]]
+
+## Contradictions
+- 无明显冲突内容
diff --git a/wiki/sources/Scrapy---Playwright-抓取TikTok-Shop-Data.md b/wiki/sources/Scrapy---Playwright-抓取TikTok-Shop-Data.md
new file mode 100644
index 00000000..b42fe42b
--- /dev/null
+++ b/wiki/sources/Scrapy---Playwright-抓取TikTok-Shop-Data.md
@@ -0,0 +1,41 @@
+---
+title: "Scrapy + Playwright 抓取TikTok Shop Data"
+type: source
+tags: [scrapy, playwright, tiktok-shop, python, docker, web-scraping]
+date: 2026-05-02
+---
+
+## Source File
+- [[raw/AI/Scrapy + Playwright 抓取TikTok Shop Data.md]]
+
+## Summary（用中文描述）
+- 核心主题：使用 Scrapy + Playwright 技术栈抓取 TikTok Shop 店铺数据
+- 问题域：TikTok Shop 电商数据采集、Web 页面爬取的环境配置
+- 方法/机制：通过 Python venv 隔离环境，安装 scrapy + scrapy-playwright，并配置 Playwright Chromium 浏览器，实现动态页面渲染与数据抓取
+- 结论/价值：提供了一套完整的技术方案，用于在 Docker 环境中运行 TikTok Shop 数据爬虫
+
+## Key Claims（用中文描述）
+- 开发者通过创建 Python venv 隔离项目依赖，避免与系统环境冲突
+- scrapy-playwright 插件将 Playwright（浏览器自动化）与 Scrapy（爬虫框架）结合，支持 JS 渲染页面抓取
+- Docker 容器内运行需要额外配置 venv 和 PATH 环境变量
+
+## Key Quotes
+> "source venv/bin/activate" — 进入 Python 虚拟环境，终端前缀出现 `(venv)` 表示激活成功
+> "scrapy runspider tiktok_shop_spider.py -a shop_url=\"https://www.tiktok.com/shop/store/aopuro/7495894041403296077\"" — 运行 TikTok Shop 爬虫的命令示例
+> "python -c \"from playwright.sync_api import sync_playwright; print('Playwright OK')\"" — 验证 Playwright 安装是否成功的命令
+
+## Key Concepts
+- [[Scrapy]]：Python 开源爬虫框架，支持异步 HTTP 请求和数据管道
+- [[Playwright]]：微软开发的浏览器自动化工具，支持 Chromium/Firefox/WebKit，支持 JS 渲染页面抓取
+- [[scrapy-playwright]]：连接 Scrapy 与 Playwright 的中间件，使 Scrapy Spider 能控制 Playwright 浏览器
+- [[Python venv]]：Python 虚拟环境工具，用于隔离项目依赖，避免包版本冲突
+
+## Key Entities
+- [[TikTok Shop]]：字节跳动旗下的电商平台，本文档的爬取目标
+
+## Connections
+- [[TikTok Shop - Apache Superset Dashboard设计思路]] ← 关联 ← [[Scrapy + Playwright 抓取TikTok Shop Data]]
+- [[可自动化、可扩展、AI增强的电商数据采集与处理系统]] ← 属于 ← [[Scrapy + Playwright 抓取TikTok Shop Data]]
+
+## Contradictions
+- （暂无发现冲突内容）
diff --git a/wiki/sources/WSL2-中-Docker-容器访问宿主机代理.md b/wiki/sources/WSL2-中-Docker-容器访问宿主机代理.md
new file mode 100644
index 00000000..87b2c046
--- /dev/null
+++ b/wiki/sources/WSL2-中-Docker-容器访问宿主机代理.md
@@ -0,0 +1,44 @@
+---
+title: "WSL2 中 Docker 容器访问宿主机代理"
+type: source
+tags: [wsl, docker, proxy]
+date: 2026-05-02
+---
+
+## Source File
+- [[Home Office/WSL2 中 Docker 容器访问宿主机代理]]
+
+## Summary（用中文描述）
+- 核心主题：WSL2 环境下 Docker 容器如何正确访问宿主机（Windows）上运行的代理服务
+- 问题域：WSL2 网络隔离场景下的容器代理配置
+- 方法/机制：使用 Docker 内置 DNS 名称 `host.docker.internal` 替代 `127.0.0.1`/`localhost`，Docker Desktop/WSL2 环境自动解析为宿主机 IP
+- 结论/价值：避免容器内 localhost 指向自身导致的代理访问失败；适用于 pip/apt-get/curl 等各种命令的代理配置
+
+## Key Claims（用中文描述）
+- **WSL2 Docker 容器 + 宿主机代理**：在 WSL2 环境下运行的 Docker 容器，必须使用 `host.docker.internal` 而非 `127.0.0.1` 访问宿主机代理，因为容器内的 `127.0.0.1` 指向容器自身而非宿主机
+- **pip 代理配置**：Dockerfile 中 `pip install --proxy http://host.docker.internal:10808` 可正确走宿主机代理
+- **apt 代理配置**：`apt-get -o Acquire::http::Proxy="http://host.docker.internal:10808" update` 可正确走宿主机代理
+- **curl 代理配置**：`curl -x http://host.docker.internal:10808 <url>` 可正确走宿主机代理
+- **Clash 代理前提**：代理软件（如 Clash）必须开启「允许局域网连接」选项
+
+## Key Quotes
+> "容器内的 `127.0.0.1` 指向容器自身，无法访问宿主机代理。需用 Docker 内置 DNS 名称替代。" — 核心问题说明
+> "避免在 Dockerfile 中硬编码 `ENV HTTPS_PROXY=http://127.0.0.1:...`，容器内无法访问" — Dockerfile 最佳实践
+
+## Key Concepts
+- [[DockerHostNetworking]]：`host.docker.internal` 是 Docker 提供的特殊 DNS 名称，用于容器访问宿主机网络，属于 DockerHostNetworking 概念的 Linux/WSL2 实现方式
+
+## Key Entities
+- [[WSL2]]：Windows Subsystem for Linux 2，本文档的技术背景平台；WSL2 默认 NAT 网络模式下容器内 `127.0.0.1` 指向自身
+- [[Clash]]：本文档示例中宿主机上运行的代理软件，需开启「允许局域网连接」才能被容器访问
+
+## Connections
+- [[DockerHostNetworking]] ← documented_in ← [[WSL2-中-Docker-容器访问宿主机代理]]（本文档记录了 `host.docker.internal` 在 WSL2 Docker 场景下的具体用法）
+- [[WSL2-中-Docker-容器访问宿主机代理]] ← extends ← [[WSL2 启动与网络配置指南]]（本文档补充了 WSL2 Docker 容器访问宿主机代理这一具体场景）
+
+## Contradictions
+- 与 [[n8n-docker-配置-telegram-代理-troubleshooting]] 细节差异：
+  - 冲突点：`host.docker.internal` 的可用性前提
+  - 当前观点（n8n 文档）：需要 `extra_hosts: - "host.docker.internal:host-gateway"` 配置才能使用
+  - 对方观点（本文档）：Docker Desktop（Windows/Mac）及 WSL2 环境下均可用，未提及 `extra_hosts`
+  - 说明：两者可能均正确，差异在于 Docker Desktop for Windows 内置支持 vs 纯 WSL2（无 Docker Desktop）的不同配置要求
diff --git a/wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md b/wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md
new file mode 100644
index 00000000..02da4e35
--- /dev/null
+++ b/wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md
@@ -0,0 +1,66 @@
+---
+title: "Your AI Isn't \"Stupid\" — It Just Needs a Better Harness | Lychee Technology Engineering Blog"
+type: source
+tags:
+  - "clippings"
+  - "agentic-ai"
+  - "harness-engineering"
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/Your AI Isn't Stupid — It Just Needs a Better Harness  Lychee Technology Engineering Blog]]
+
+## Summary（用中文描述）
+- 核心主题：Harness Engineering——为 AI Agent 设计"马具"的系统学科，将 LLM 嵌入严格代码脚手架中实现可靠的多步自主执行
+- 问题域：AI Agent 在长周期自主任务中的崩溃问题（10步崩塌、上下文溢出、Schema 漂移、状态丢失）
+- 方法/机制：7层 Harness Stack（Cognition → Tools → Contracts → Orchestration → Memory → Evaluation → Constraints & Recovery），每个边界的输入输出验证，每个工具调用的幂等重试，状态外部化持久化
+- 结论/价值：Agent 失败的原因不是模型弱，而是系统设计缺失；最成功的构建者不是写最好代码的人，而是设计最好"马具"的人
+
+## Key Claims（用中文描述）
+- LLM 本身不是 Agent，Agent = LLM + 代码脚手架（状态管理 + 恢复工作流）
+- Prompt Engineering → Context Engineering → Harness Engineering 是演进而非替代，后者吸收前两者并增加执行控制层
+- 约束（constrain）而非指令（instruct）——程序化限制比自然语言提示更可靠
+- 每个 LLM 输出必须经过 Schema 验证器，拒绝格式不符的输出，而非依赖模型自我修正
+- 状态必须外部化——context window 是易失的，磁盘文件才是持久的
+- 每个工具调用必须幂等——单步失败只重试该步，不重启整个管道（局部失败而非全局崩溃）
+- Context Reset：当 token 使用率超过 70% 阈值时，保存状态、终止当前实例、启动全新 Agent
+- Self-Grading Illusion：LLM 无法有效评估自身输出——同一套权重既生成输出又评判输出，结构上存在缺陷
+- Sprint Contract：Generator 和 Evaluator 必须完全独立，Evaluator 在干净上下文中仅接收输出和成功标准，不读 Generator 的思维链
+- Memory Consolidation：周期性压缩 Agent 累积的工作日志（实测 32K 噪声日志压缩至 7K），防止记忆膨胀和矛盾
+- 最小可行 Harness（Day 1 可构建）：state.json + retry wrapper + schema validator + tool output truncation
+
+## Key Quotes
+> "The problem usually isn't the horse. It's the reins." — 核心隐喻：模型是马，Harness 是缰绳
+> "A prompt that says 'always respond in valid JSON' is a hope. A schema validator that rejects malformed output is a guarantee." — 约束优于指令
+> "The model speaks in probabilities. The harness must speak in types." — Schema drift 的根源
+> "Fail locally, not globally." — 单步失败只重试该步，不重启整个管道
+
+## Key Concepts
+- [[Harness-Engineering]]：为 LLM 设计的系统脚手架学科，使 Agent 能在长周期自主任务中可靠执行——包含约束、外部化、验证、恢复四个设计原则
+- [[Agent-Collapse]]（10-Step Collapse）：Agent 在多步任务中途开始幻觉或输出崩溃的现象——根因是 context window 被静默截断或无 Schema 验证
+- [[Context-Anxiety]]：当 context window 使用率超过 70% 或延迟升高时，模型表现出"仓促"行为——跳过步骤或过早完成任务
+- [[Context-Reset]]：当 Context Anxiety 触发时，Harness 将状态保存至磁盘、终止当前实例、启动全新 Agent 的程序化操作
+- [[Schema-Drift]]：同一 LLM 在不同调用中对同一字段生成不同数据类型（如 price 一次为 string 一次为 float）的静默错误
+- [[Sprint-Contract]]：Generator Agent 和独立 Evaluator Agent 在工作开始前约定的可测试"完成"定义，Evaluator 在干净上下文中仅接收输出和标准
+- [[Self-Grading-Illusion]]：LLM 无法有效评估自身输出的结构性缺陷——生成输出的权重位置决定了它不能可靠地评判该输出
+- [[Memory-Consolidation]]：Agent 空闲时周期性压缩累积工作日志（去重 + 解决矛盾 + 写入精简状态文件）的机制
+- [[State-Externalization]]：将任务状态（pending/in-progress/completed）写入磁盘文件而非仅保存在 context window 的实践
+- [[Idempotency]]：工具调用的幂等性保证——失败时精确重试该步，不污染全局状态也不重复已完成工作
+- [[7-Layer-Harness-Stack]]：Cognition / Tools / Contracts & Interfaces / Orchestration / Memory & State / Evaluation & Observation / Constraints & Recovery
+
+## Key Entities
+- [[Lychee-Technology]]：发布本 engineering blog 的公司，专注于 production-grade AI 系统设计
+- [[Anthropic]]：在 steering vectors 和内部模型表征方面的研究被本文引用，用于论证 Self-Grading Illusion
+
+## Connections
+- [[Harness-Engineering]] ← extends ← [[Agent-Collapse]]（分析根因并提供系统性解决方案）
+- [[7-Layer-Harness-Stack]] ← is_a ← [[Harness-Engineering]]（具体实现框架）
+- [[Context-Reset]] ← is_a ← [[Context-Anxiety]]（问题的程序化解决方案）
+- [[Sprint-Contract]] ← resolves ← [[Self-Grading-Illusion]]（通过角色分离打破结构性缺陷）
+- [[Memory-Consolidation]] ← addresses ← State Management（解决长期运行的记忆膨胀问题）
+- [[Hermes-Agent]] ← implements ← [[7-Layer-Harness-Stack]]（若 Hermes Agent 实现了完整 Harness 架构，可关联本文）
+- [[Designing-for-Agentic-AI]] ← related ← [[Harness-Engineering]]（可补充外部设计原则文档）
+
+## Contradictions
+- 无与其他 Wiki 页面的直接冲突内容。本文可与 [[Designing-for-Agentic-AI]] 互补阅读——后者侧重设计原则，本文侧重工程实现层次。
diff --git a/wiki/sources/academic-anthropologist.md b/wiki/sources/academic-anthropologist.md
index b976c05b..059c904e 100644
--- a/wiki/sources/academic-anthropologist.md
+++ b/wiki/sources/academic-anthropologist.md
@@ -1,56 +1,56 @@
 ---
 title: "Academic Anthropologist"
 type: source
-tags: []
-date: 2026-04-20
-sources: []
-last_updated: 2026-04-25
+tags: ["agent-personality", "anthropology", "cultural-design", "societal-modeling"]
+date: 2026-04-25
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/academic/academic-anthropologist.md]]
+- [[Agent/agency-agents/academic/academic-anthropologist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 角色设计——将文化人类学家田野调查的方法论与人格特质注入 AI Agent，使其能够构建文化上自洽的社会系统
-- 问题域：如何让 AI 在设计虚构或真实文化时避免刻板印象、文化拼贴（culture salad），而是基于人类学理论构建功能自洽的社会体系
-- 方法/机制：结构人类学（列维-斯特劳斯）、象征人类学（格尔茨"厚描"）、实践理论（布迪厄）、仪式分析（特纳、范热内普）、经济人类学（莫斯、波拉尼）的理论框架
-- 结论/价值：每个文化元素必须有社会功能（社会凝聚、资源管理、身份认同、冲突解决）；先功能后美学；亲属制度是基础设施
+- 核心主题：为 AI Agent 定义文化人类学家角色——设计具有文化内在一致性的社会系统，涵盖亲属制度、信仰体系、仪式结构和交换机制
+- 问题域：避免文化设计中的刻板印象（文化沙拉）、唯美主义（功能优先于美学）、高尚野蛮人谬误；确保每种文化元素服务于社会功能
+- 方法/机制：结构主义分析（Levi-Strauss）、厚描述（Geertz）、实践理论（Bourdieu）、功能分析（Malinowski/Durkheim）、礼物经济（Mauss）、 Polanyi 交换分类、阈限与 communitas（Turner）、文化生态学（Steward）
+- 结论/价值：文化设计必须从生计模式出发，依次构建社会组织（骨架）→ 信仰体系（血肉）→ 内在一贯性检查；文化借贷需理解原语境，不做表面美学移植
 
 ## Key Claims（用中文描述）
-- AI Agent 在设计文化时应优先问"这个实践解决了什么问题"而非"这个仪式看起来酷不酷"
-- 亲属制度决定了继承、政治联盟、居住模式和冲突解决方式，是社会的骨架，不应跳过
-- 避免"高贵的野蛮人"偏见——前工业社会是复杂适应系统，有自身的政治、冲突和创新
-- 文化借用必须理解原始语境，不能仅凭表面美学混搭不同文化元素
-- 每个文化都有内部张力和矛盾（没有乌托邦），应主动识别
+- AI Agent 作为文化人类学家，必须为每种文化实践追问："这种做法为这些人们解决了什么问题？"
+- 亲属制度是社会基础设施——决定继承、政治联盟、居住模式和冲突解决方式，不能跳过
+- 文化借贷必须先理解元素在原语境中的含义，再考虑其在新系统中的互动，不能混搭不同文化传统
+- 生态系统分析必须从生计模式（觅食/游牧/农业/工业）出发，这是塑造整个社会结构的底层基础
+- 文化内部矛盾和张力必须被识别——没有乌托邦，每种文化都有其内在冲突
 
 ## Key Quotes
-> "No culture is random — every practice is a solution to a problem you might not see yet." — Anthropologist Agent 核心理念
-> "Emic before etic: First understand how the culture sees itself before applying outside analytical categories." — 方法论原则
+> "No culture is random — every practice is a solution to a problem you might not see yet" — Anthropologist Agent 核心信条
+> "Function before aesthetics. Before asking 'does this ritual look cool?' ask 'what does this ritual do for the community?'" — 功能分析优先原则（Durkheim/Malinowski）
+> "In a patrilineal society, your father's brother's children are your siblings, not your cousins. This changes everything about inheritance." — 亲属制度的具体细节如何决定社会结构
 
 ## Key Concepts
-- [[Thick Description]]：格尔茨的"厚描"理论，将文化实践视为文本阅读，理解参与者的主观意义
-- [[Liminality]]：特纳的阈限概念，设计转化性仪式体验的关键框架
-- [[Gift Economy]]：莫斯的礼物经济理论，基于互惠和社会义务构建交换系统
-- [[Cultural Coherence]]：文化自洽性检验——每个文化元素必须有社会功能，内部一致
-- [[Rites of Passage]]：范热内普的通过仪式模型——分离 → 阈限 → 融合
+- [[Structuralism]]：Levi-Strauss 的结构主义——通过二元对立和变换来组织神话与分类
+- [[Symbolic-Anthropology]]：Geertz 的"厚描述"——将文化实践作为文本阅读，理解参与者的主观意义
+- [[Practice-Theory]]：Bourdieu 的实践理论——文化如何通过日常实践再生产和变革
+- [[Functionalism]]：Durkheim/Malinowski 功能主义——每种社会制度服务于维持社会凝聚力的功能
+- [[Gift-Economy]]：Mauss 的礼物经济——基于互惠和社会义务的交换系统设计
+- [[Liminality]]：Turner 的阈限与 communitas——设计转化性仪式体验（分离→阈限→整合，van Gennep 模型）
+- [[Kinship-System]]：亲属制度——社会基础设施，决定继承、联盟和居住模式（双系/父系/母系/双重继嗣）
+- [[Cultural-Ecology]]：Steward/Rappaport 文化生态学——环境如何塑造文化，文化又如何反过来塑造环境
+- [[Polanyi-Exchange]]：Polanyi 的交换分类——互惠（reciprocity）/ 再分配（redistribution）/ 市场（market）
 
 ## Key Entities
-- [[Claude Lévi-Strauss]]：结构人类学创始人，二元对立分析框架
-- [[Clifford Geertz]]：象征人类学，"厚描"概念提出者
-- [[Pierre Bourdieu]]：实践理论，场域、惯习、资本概念
-- [[Victor Turner]]：仪式过程分析，阈限与社群共同性（communitas）
-- [[Arnold van Gennep]]：通过仪式三阶段模型
-- [[Marcel Mauss]]：《礼物》作者，礼物经济理论
-- [[Mary Douglas]]：神圣/世俗边界分析
-- [[Émile Durkheim]]：功能分析学派，社会凝聚理论
-- [[Bronisław Malinowski]]：功能主义，文化实践满足基本需求
-- [[Karl Polanyi]]：经济人类学，互惠、再分配、市场三元框架
-- [[Marvin Harris]]：文化唯物主义，从生存模式推演文化
+- [[Claude-Levi-Strauss]]：结构主义创始人，发展了通过二元对立理解神话与社会的系统性框架
+- [[Clifford-Geertz]]：符号人类学"厚描述"方法论的提出者，强调理解文化参与者自身视角
+- [[Pierre-Bourdieu]]：实践理论和社会资本概念的提出者，连接文化实践与社会结构
+- [[Victor-Turner]]：阈限（liminality）和 communitas 概念，提出仪式过程中的社会转化机制
+- [[Bronislaw-Malinowski]]：功能主义人类学创始人，强调文化实践满足人类基本需求
+- [[Marcel-Mauss]]：《礼物》作者，系统阐述礼物经济中的互惠义务机制
+- [[Mary-Douglas]]：《洁净与危险》作者，分析神圣/世俗边界与禁忌体系的社会功能
 
 ## Connections
-- [[Academic Historian]] ← discipline_similarity ← [[Academic Anthropologist]]
-- [[Academic Geographer]] ← discipline_similarity ← [[Academic Anthropologist]]
-- [[Academic Narratologist]] ← discipline_similarity ← [[Academic Anthropologist]]
+- [[Agents-Orchestrator]] ← extends ← [[Academic-Anthropologist]]：Anthropologist Agent 是 Agency 系统中负责文化设计的专业子 Agent
+- [[Unreal-World-Builder]] ← depends_on ← [[Academic-Anthropologist]]：游戏世界构建需 Anthropologist 提供文化内在一致性原则
+- [[Structuralism]] ← foundational ← [[Cultural-System-Design]]：结构主义为复杂社会系统设计提供分类框架
 
 ## Contradictions
-- 暂无已知冲突
+- 与其他 Agent 设计文档（如游戏/销售类 Agent）的冲突：**无**。Anthropologist Agent 是领域专精的社会文化设计工具，与其他功能性 Agent 定位不重叠，不产生内容冲突。
+- 与 Noble Savage（高贵的野蛮人）叙事的冲突：本文档明确批判"前工业社会更纯粹/更接近自然"的观点，强调所有社会都是具有自身政治、冲突和创新的复杂自适应系统。
diff --git a/wiki/sources/academic-geographer.md b/wiki/sources/academic-geographer.md
index b50e9bef..1812343f 100644
--- a/wiki/sources/academic-geographer.md
+++ b/wiki/sources/academic-geographer.md
@@ -2,56 +2,52 @@
 title: "Academic Geographer"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-05-03
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/academic/academic-geographer.md]]
+- [[Agent/agency-agents/academic/academic-geographer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 中的地理学家角色（Geographer Agent）—— 专注于物理与人文地理的系统性建模，为虚拟世界构建地理连贯性
-- 问题域：如何让 AI Agent 能够像真正的地理学家一样，基于物理规律（板块构造、气候系统、水文地理）构建可信的虚拟世界，并在地理约束与人类文明之间建立逻辑联系
-- 方法/机制：通过严格的地理连贯性规则（河流不分叉、气候成系统、地理非装饰）、五步工作流（板块构造 → 气候 → 水文 → 生物群落 → 人类定居）、交付物模板（地理连贯性报告、气候系统设计）来驱动 Agent 行为
-- 结论/价值：该 Agent 为 AI 世界构建提供了一个地理学家的思维框架，强调系统性、因果性和物理一致性，避免常见的地理设定错误
+- 核心主题：AI Agent 系统中的地理学家角色——专注于物理地理与人文地理的跨学科专家，帮助构建地理逻辑自洽的虚拟世界
+- 问题域：如何在 Agent 世界构建中保持地理要素（气候、地形、水系、生物群落、聚落模式）之间的物理一致性
+- 方法/机制：六步工作流（板块构造→气候系统→水文学→生物群落→人类聚落→贸易路线），以及详细的地理一致性报告和气候系统设计模板
+- 结论/价值：为 Agent 世界构建提供系统化的地理推理框架，避免常见的地理逻辑错误
 
 ## Key Claims（用中文描述）
-- 河流不分叉（支流汇入主流，河流不分叉流向不同海洋）—— 这是物理水文的基本规律
-- 气候是一个系统（雨影效应、洋流、温度缓冲、纬度决定季节）—— 不能随意放置违背物理规律的气候
-- 地理不是装饰（每座山、每条河、每个沙漠都对当地居民有实际影响）
-- 避免地理决定论（地理约束但不决定，相似环境产生不同文化）
-- 规模很重要（"小王国"和"大帝国"的地理需求完全不同）
-- 地图是论据（每张地图都有关于包含什么、排除什么的政治选择）
+- 地理 Agent 验证地理连贯性：气候、地形和生物群落必须相互物理一致，聚落模式必须具有地理意义，资源分布必须符合地质和生态逻辑
+- 河流不分离原则：支流汇入干流，河流不分叉流向不同海洋（三角洲和分水岭是例外）
+- 气候是系统：雨影效应存在，海流影响温度，纬度决定季节；不能在无特殊理由的情况下在北纬60°放置热带雨林
+- 避免地理决定论：地理约束但不决定人类行为，相似环境产生不同文化
 
 ## Key Quotes
-> "Geography is destiny — where you are determines who you become" — Geographer Agent 的核心理念
+> "Geography is destiny — where you are determines who you become" — 地理学家 Agent 的核心理念
 > "Rivers don't split. Tributaries merge into rivers. Rivers don't fork into two separate rivers flowing to different oceans." — 关键物理规则
-> "Maps are arguments. Every map makes choices about what to include and exclude." — 制图的政治性
+> "Climate is a system. Rain shadows exist. Coastal currents affect temperature. Latitude determines seasons." — 气候系统思维
+> "Geography is not decoration. Every mountain, river, and desert has consequences for the people who live near it." — 地理的功能性价值
+> "Maps are arguments. Every map makes choices about what to include and exclude." — 地图的政治性
 
 ## Key Concepts
-- [[Geographic Coherence]]：地理连贯性 —— 确保气候、地形、生物群落之间物理一致的原则
-- [[Koppen Climate Classification]]：柯本气候分类法 —— Agent 用于描述气候区的参考框架
-- [[Environmental Determinism]]：环境决定论 —— 认为地理直接决定文化和发展的理论框架，Agent 在采纳其框架的同时承认其批评
-- [[Christaller Central Place Theory]]：克里斯塔勒中心地理论 —— 解释城市层级和形成原因的人文地理理论
-- [[Mackinder Heartland Theory]]：麦金德心脏地带理论 —— 地缘政治学中关于地理如何塑造战略竞争的框架
-- [[Rain Shadow Effect]]：雨影效应 —— 山脉阻挡湿气导致背风坡干旱的物理现象
-- [[Plate Tectonics]]：板块构造论 —— 解释山脉、火山等地理特征形成的地质学基础
+- [[EnvironmentalDeterminism]]：地理决定论——地理塑造文明的理论，Agent 明确承认 Jared Diamond 的框架同时接受其批评
+- [[KoppenClimateClassification]]：柯本气候分类法——物理地理学基础
+- [[ChristallerCentralPlaceTheory]]：克里斯塔勒中心地理论——人文地理学中的城市层级理论
+- [[MackinderHeartlandTheory]]：麦金德心脏地带理论——地缘政治学中的地理战略框架
+- [[WallersteinWorldSystems]]：沃勒斯坦世界体系理论——全球政治经济学框架
+- [[HydrologyConstraints]]：水文学约束——河流从高处流向低处，支流汇入干流，不反向流动
+- [[RainShadowEffect]]：雨影效应——山脉阻挡潮湿气流，导致背风坡干旱
 
 ## Key Entities
-- [[Jared Diamond]]：提出地理框架（《枪炮、病菌与钢铁》），Agent 采纳其环境决定论视角同时承认其局限性
-- [[Acemoglu]]：对地理决定论的批评者，Agent 明确引用以避免走向极端地理决定论
-- [[Wallerstein]]：世界体系理论提出者，影响 Agent 对贸易网络和权力动态的分析
-- [[Mackinder]]：地缘政治学先驱，Heartland Theory 的提出者
+- [[JaredDiamond]]：地理学家，《枪炮、病菌与钢铁》作者，地理框架参考
+- [[Acemoglu]]：批评地理决定论的经济学家，代表反方观点
 
 ## Connections
-- [[Geographic Coherence]] ← builds_upon ← [[Plate Tectonics]]
-- [[Geographic Coherence]] ← builds_upon ← [[Koppen Climate Classification]]
-- [[Mackinder Heartland Theory]] ← extends ← [[Geographic Coherence]]
-- [[Christaller Central Place Theory]] ← extends ← [[Geographic Coherence]]
-- [[Jared Diamond]] → influences → [[Environmental Determinism]]
-- [[Acemoglu]] → critiques → [[Environmental Determinism]]
+- [[AcademicNarratologist]] ← 协同构建世界故事 ← [[AcademicGeographer]]
+- [[UnrealWorldBuilder]] ← 依赖地理连贯性 ← [[AcademicGeographer]]
+- [[AcademicAnthropologist]] ← 依赖地理背景 ← [[AcademicGeographer]]
+- [[AcademicGeographer]] ← 提供环境框架 ← [[AgentsOrchestrator]]
 
 ## Contradictions
-- 与 [[Jared Diamond]] 的框架存在张力：
-  - 冲突点：Agent 采纳 Diamond 的地理框架，但同时强调 Acemoglu 对地理决定论的批评
-  - 当前观点：地理约束人类选择，但不等同于决定论
-  - 对方观点：Diamond 强调地理是历史发展的主导因素
+- 与 [[Acemoglu]] 的"制度决定论"冲突：
+  - 冲突点：地理是否决定文明发展轨迹
+  - 当前观点：地理约束是基础条件（Academic Geographer）
+  - 对方观点：制度和政治因素是决定性因素（Acemoglu）
diff --git a/wiki/sources/academic-historian.md b/wiki/sources/academic-historian.md
index 3915e352..b5171fb1 100644
--- a/wiki/sources/academic-historian.md
+++ b/wiki/sources/academic-historian.md
@@ -1,51 +1,60 @@
 ---
-title: "Historian Agent Personality"
+title: "Historian"
 type: source
-tags: ["agent-personality", "historiography", "material-culture", "period-authenticity", "academic"]
-date: 2026-04-20
+tags: []
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/academic/academic-historian.md]]
+- [[Agent/agency-agents/academic/academic-historian.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 角色设定——扮演具有跨时代研究能力的历史学家，为创意项目提供历史真实性验证、时代背景丰富化和历史迷思纠正
-- 问题域：虚构作品中避免时代错乱（anachronism）、为游戏/小说/影视提供扎实的物质文化基础、主动纳入非西方历史传统
-- 方法/机制：通过五步工作流（定位时间空间→核查物质基础→叠加社会结构→评估论断→标注置信度），结合 Annales 学派、长时段分析、微观史、比较史等史学方法论
-- 结论/价值：让 AI Agent 能够以"历史学家"身份为创意世界提供可溯源的历史支撑，提升内容的历史深度与文化包容性
+- 核心主题：定义一个名为"Historian"的 AI Agent 角色——专业历史研究者，擅长历史分析、时代分期、物质文化和历史编纂学（historiography）
+- 问题域：AI Agent 的角色扮演设计、历史知识验证、历史叙事准确性保证
+- 方法/机制：Annales 学派、微观史学、长时段（longue durée）分析、物质文化重建、反事实推理（counterfactual analysis）
+- 结论/价值：确保虚构场景或应用中的历史细节准确无误，提供有据可查的历史背景和物质文化细节，主动挑战欧洲中心主义偏见
 
 ## Key Claims（用中文描述）
-- 历史学家 Agent 通过"时代真实性报告"（Period Authenticity Report）为设定提供饮食、服饰、建筑、技术、货币、权力结构、性别角色等全维度历史细节
-- 所有历史论断必须标注来源类型（原始文献>二手学术>通俗史>好莱坞）和置信度（高/中/低），避免"中世纪时..."这类模糊表述
-- 主动挑战欧洲中心主义：将宋朝科技、明帝国财富、马里帝国等非西方历史纳入比较视野
-- 物质条件决定论：在讨论政治/军事前必须先理解经济基础（农业、贸易、技术水平）
+- Historian Agent 通过五步工作流程（建立坐标→检查物质基础→叠加社会结构→评估来源→标注置信度）对历史主张进行系统性验证
+- Historian Agent 使用 Period Authenticity Report（时代真实性报告）提供多维度的时代细节：饮食、服装、建筑、技术、经济、货币、社会结构、法律和日常生活的感官细节
+- Historian Agent 区分四种来源层级（原始文献 > 二手学术 > 大众历史 > 好莱坞），对每项历史主张必须标注来源类型和置信度
+- Historian Agent 将神话视为"主要史料"——揭示一个文化重视什么、恐惧什么、渴望什么，而非简单否定为"虚假历史"
+- Historian Agent 强调物质条件决定论——在讨论政治或战争之前，必须先理解经济基础：人们吃什么、如何贸易、掌握什么技术
 
 ## Key Quotes
-> "History doesn't repeat, but it rhymes — and I know all the verses" — Historian Agent 的风格定位
-> "That's a common belief, but the evidence actually shows..." — 纠正历史迷思时的沟通风格
-> "Medieval Europe spans 1000 years and a continent. Be specific about when and where." — 对时代宽泛化的警示
-> "Myths are data too. A society's myths reveal what they valued, feared, and aspired to." — 对神话的态度
+> "History doesn't repeat, but it rhymes — and I know all the verses" — Historian Agent 标语（vibe）
+> "A Roman legionary's daily ration included about 850g of wheat, ground and baked into hardtack — not the fluffy bread you're imagining" — 精准但生动的表达风格示例
+> "Medieval Europe spans 1000 years and a continent. Be specific about when and where." — 避免以偏概全的方法论要求
+> "The Song Dynasty was more technologically advanced than contemporary Europe. The Mali Empire was one of the richest states in human history." — 主动挑战欧洲中心主义的代表性声明
 
 ## Key Concepts
-- [[Annales School]]：法国史学流派，强调长时段（longue durée）结构史学，关注日常生活的物质文化与经济基础
-- [[Material Culture Analysis]]：物质文化分析，通过文物、遗址、日用物品重建历史时期的生活质感
-- [[Anachronism Detection]]：时代错乱检测，不仅识别明显的（如前哥伦布时代欧洲出现土豆），还包括隐性的（态度、社会结构、经济系统的时代错配）
-- [[Longue Durée]]：布罗代尔提出的长时段历史分析概念，识别塑造事件发生的长期结构
-- [[Microhistory]]：微观史学，关注特定个人或社区以揭示更广泛的历史动态
-- [[Comparative History]]：比较历史学，跨文明比较相似挑战下的不同应对方式
-- [[Counterfactual Analysis]]：反事实分析，基于历史偶然性理论的严谨"如果"推理
-- [[Postcolonial History]]：后殖民史学，主动纳入非欧洲中心的历史视角
+- [[Annales School]]：法国年鉴学派，强调"总体史"——关注长时段的结构性变化（地理、人口、经济、社会）而非单纯的政治军事事件
+- [[Longue Durée]]：长时段分析，源自布罗代尔（Braudel），认为历史事件背后的深层结构（如地理环境、人口趋势、经济形态）决定了短期事件的走向
+- [[Microhistory]]：微观史学，聚焦于个体或小社区的历史研究方法，通过具体案例揭示更大的历史规律
+- [[Material Culture]]：物质文化分析，通过物质遗存（器物、建筑、服饰）重建过去人们的生活方式和思想观念
+- [[Historiography]]：历史编纂学，研究历史叙事如何被构建、争议和演变——Historian Agent 理解历史叙事本身是被建构和争夺的对象
+- [[Counterfactual Analysis]]：反事实推理，严谨的"假如"历史推演，以历史偶然性理论为基础，而非随意想象
+- [[Presentism]]：当代主义（以现代标准评判历史），Historian Agent 避免此类判断，同时也不为暴行开脱
 
 ## Key Entities
-- [[Annales School]]（学术流派）：由布洛赫和费弗尔创立，以《年鉴》杂志为核心阵地，代表人物包括布罗代尔
-- [[Fernand Braudel]]（历史学家）：长时段理论提出者，著有《菲利普二世时代的地中海和地中海世界》
-- [[Pirenne]]（历史学家）：提出"穆罕默德和查理曼"的商业复兴论点，与维克斯曼等后世学者存在争论
+- [[Fernand Braudel]]：法国历史学家，Annales 学派核心人物，长时段（longue durée）概念的提出者，其对地中海贸易的研究被文档引用为方法论典范
+- [[Henri Pirenne]]：比利时历史学家，提出的"穆罕默德和查理曼"命题（Pirenne Thesis）仍是中世纪史研究中的重要辩论焦点
+- [[Chris Wickham]]：当代历史学家，代表 Pirenne 命题的对立观点，文档中与 Pirenne 并列为学界辩论的双方
 
 ## Connections
-- [[Academic Geographer]] ← 方法互补 ← [[Academic Historian]]：地理与历史共同构建时空坐标
-- [[Academic Narratologist]] ← 内容提供 ← [[Academic Historian]]：历史真实性为叙事提供素材
-- [[Academic Anthropologist]] ← 理论交叉 ← [[Academic Historian]]：两者都关注物质文化与日常生活的重建
+- [[Academic Narratologist]] ← 方法互补 ← [[Academic Historian]]
+  - Narratologist 关注叙事结构，Historian 关注历史真实性，两者结合可生成既叙事优美又历史准确的文本
+- [[Academic Anthropologist]] ← 跨学科协作 ← [[Academic Historian]]
+  - 两者都关注物质文化（Material Culture），Historian 从历史维度，Anthropologist 从文化维度
+- [[Unreal World Builder Agent]] ← 被验证 ← [[Academic Historian]]
+  - Historian Agent 的 Period Authenticity Report 可直接服务于 Unreal World Builder 的历史背景设定验证
 
 ## Contradictions
-- 与通俗历史观点冲突：大量常见的历史迷思（"黑暗的中世纪"、"文艺复兴突然觉醒"等）被纠正
-- 与影视作品冲突：Holly hollywood 对中世纪/古典时代的浪漫化呈现被明确标记为错误
+- 与 [[Academic Narratologist]] 潜在冲突：
+  - 冲突点：叙事节奏 vs. 历史准确性
+  - 当前观点（Historian）：任何历史主张必须标注置信度和来源，模糊性会降低准确性
+  - 对方观点（Narratologist）：叙事需要适度的戏剧化处理，历史真实与艺术真实之间存在张力
+- 与 [[Academic Psychologist]] 潜在冲突：
+  - 冲突点：历史人物心理 vs. 史料局限性
+  - 当前观点（Historian）：不能随意揣测历史人物的内心，必须基于一手或二手文献
+  - 对方观点（Psychologist）：心理学分析可以填补史料空白，提供更完整的人物画像
diff --git a/wiki/sources/academic-narratologist.md b/wiki/sources/academic-narratologist.md
index 20d0831b..347ee4f0 100644
--- a/wiki/sources/academic-narratologist.md
+++ b/wiki/sources/academic-narratologist.md
@@ -2,51 +2,55 @@
 title: "Academic Narratologist"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/academic/academic-narratologist.md]]
+- [[Agent/agency-agents/academic/academic-narratologist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Narratologist Agent 角色设定——一个以叙事理论为基础的故事结构分析 AI Agent，具备俄罗斯形式主义、法国结构主义、认知叙事学等深厚学术背景
-- 问题域：如何让 AI Agent 能够像专业叙事理论家一样，分析故事结构、角色弧光、主题表达，并提供有理论依据的叙事建议
-- 方法/机制：通过预置的叙事学框架（Propp、Campbell、Genette、Barthes、Todorov 等）驱动分析流程，要求每个建议都必须引用至少一个命名理论框架
-- 结论/价值：提供了一个可复用的学术型 AI Agent 设计范式——将传统人文社科理论与 LLM 系统提示词工程结合
+- 核心主题：Narratologist 是一个专注于叙事理论与故事结构分析的专业 AI Agent，以工程师拆解系统的方式剖析叙事——找出承重结构、应力点和优雅解法
+- 问题域：如何为 AI Agent 提供严谨的叙事分析能力，使其能对故事结构、角色弧线、主题表达进行框架级别的精确评估
+- 方法/机制：通过整合 Propp、Campbell、McKee、Genette 等经典叙事学框架，结合 Russian Formalism、Cognitive Narratology、Game Narrative 等现代理论，提供框架驱动的叙事分析与指导
+- 结论/价值：AI Agent 可以通过引用具体理论框架，对叙事问题给出精确、可辩护的结构性建议，而非泛泛的"让它更有趣"
 
 ## Key Claims（用中文描述）
-- Narratologist Agent 能通过 Propp 形态学分析童话/冒险结构，通过 Campbell 单一体神话和 Vogler 编剧旅程分析英雄叙事
-- 叙事问题通常存在于讲述层面（sjuzhet）而非故事层面（fabula）——应优先诊断叙事手法而非情节本身
-- 每个结构建议必须引用至少一个命名理论框架，并附带推理过程；泛泛的建议（如"让角色更立体"）是不合格的
-- 角色动机的心理分析只能作为视角而非处方使用——角色不是案例研究对象
-- 在颠覆类型惯例之前必须先理解并尊重类型惯例
+- Narratologist Agent 通过系统性框架（而非印象式批评）为故事结构提供精确分析
+- 叙事问题通常存在于讲述层（sjuzhet）而非故事层（fabula），分析应在正确层级进行
+- 每个建议必须引用至少一个命名理论框架，支撑"是什么、为什么有效、适用框架"三层论证
+- 角色动机分析应使用心理学模型作为透镜而非处方，角色不是案例研究
 
 ## Key Quotes
-> "Every story is an argument — I help you find what yours is really saying." — Narratologist Agent 自述核心理念
-> "Most problems live in the telling (sjuzhet), not the tale (fabula)." — 叙事诊断的核心原则
-> "Cite sources. 'According to Propp's function analysis, this character serves as the Donor' is useful. 'This character should be more interesting' is not." — 关于提供理论依据的要求
+> "You dissect stories the way an engineer dissects systems — finding the load-bearing structures, the stress points, the elegant solutions." — 身份定位：系统工程师式叙事分析
+> "Never give generic advice like 'make the character more relatable.' Be specific: what changes, why it works narratologically, and what framework supports it." — 核心原则：精确而非泛泛
+> "Most problems live in the telling (sjuzhet), not the tale (fabula)." — 诊断层级的关键洞察
+> "Cite sources. 'According to Propp's function analysis, this character serves as the Donor' is useful. 'This character should be more interesting' is not." — 引用框架的要求
 
 ## Key Concepts
-- [[Fabula 与 Sjuzhet]]：故事（fabula=按时间顺序的事件）与叙事（sjuzhet=如何讲述）的区分，是叙事分析的基础框架
-- [[Propp 形态学]]：Vladimir Propp 的民间故事功能分析，识别31种故事功能（如 Donor、Hero、Villain）
-- [[Campbell 单一体神话]]：Joseph Campbell 的"英雄之旅"理论，Hero's Journey 的学术根源
-- [[Vogler 编剧旅程]]：Christopher Vogler 将 Campbell 理论改编为好莱坞编剧实践框架
-- [[Genette 叙事学]]：Gérard Genette 的叙事理论，聚焦叙事视角（focalization）、时序结构、叙事声音
-- [[Barthes 五代码]]：Roland Barthes 的叙事语义五代码模型（Hermeneutic、Proairetic、Symbolic、Semantic、Referential）
-- [[Todorov 均衡模型]]：Tzvetan Todorov 的 equilibrium-disruption-new equilibrium 三阶段模型
-- [[角色弧光]]：Character Arc，角色从起点到终点的内在变化轨迹，含 want/need/lie/transformation 四个维度
-- [[叙事债务]]：Narrative Debts，向读者做出的尚未兑现的叙事承诺
-- [[控制性理念]]：Controlling Idea（McKee 术语），即故事对人类经验的论证核心
+- [[Narrative Theory]]：故事结构的学术研究领域，涵盖 Russian Formalism、French Structuralism、Cognitive Narratology 等分支
+- [[Hero's Journey]]（Campbell/Monomyth）：英雄之旅叙事模型，Narratologist 应用于英雄叙事分析
+- [[Propp's Morphology]]：Vladimir Propp 的民间故事形态学，31 种功能分析，用于童话与quest结构
+- [[Three-Act Structure]]：经典三幕式叙事结构（Setup/Confrontation/Resolution）
+- [[Character Arc]]：角色弧线，Transformative/Steadfast/Flat/Tragic/Comedic 五种类型，含 want/need/lie/transformation 四个要素
+- [[Controlling Idea]]（McKee）：故事对人性的论点，是叙事分析的核心抽象层
+- [[Fabula vs Sjuzhet]]：故事（按时间顺序的事件）与叙事（如何讲述）的区分
+- [[Kishōtenketsu]]：日本四幕叙事结构，作为西方三幕式的跨文化对比框架
+- [[Todorov's Equilibrium]]：equilibrium disruption 叙事模型
+- [[Genette's Narratology]]：聚焦 narrative voice、focalization、temporal structure 的理论框架
+- [[Barthes' Five Codes]]：叙事意义的符号学分析工具
 
 ## Key Entities
-- [[Academic Anthropologist]]：同一系列中的学术型 Agent 之一，同样采用学科理论驱动的方法论
-- [[Academic Historian]]：同一系列中的学术型 Agent 之一，共享 Agent 个性设计范式
-- [[Academic Geographer]]：同一系列中的学术型 Agent 之一
+- [[Campbell]]：Joseph Campbell，Hero's Journey / Monomyth 的提出者，Narratologist 的核心引用框架之一
+- [[Propp]]：Vladimir Propp，民间故事形态学（31 Functions）创始人
+- [[McKee]]：Robert McKee，Story / Controlling Idea 框架的当代叙事权威
+- [[Genette]]：Gérard Genette，Narrative Discourse 理论框架，影响 voice、focalization、tense 分析
+- [[Vogler]]：Christopher Vogler，Writer's Journey 将 Campbell 理论引入商业叙事
+- [[Barthes]]：Roland Barthes，Five Codes 提供叙事意义的符号学解码工具
 
 ## Connections
-- [[Academic Anthropologist]] ← 同系列学术 Agent ← [[Academic Narratologist]]
-- [[Academic Historian]] ← 同系列学术 Agent ← [[Academic Narratologist]]
-- [[Academic Geographer]] ← 同系列学术 Agent ← [[Academic Narratologist]]
+- [[Agents Orchestrator]] ← provides_narrative_expertise_to ← [[Academic Narratologist]]
+- [[Narrative Designer]] ← overlaps_with ← [[Academic Narratologist]]（Game Narrative 领域）
+- [[Agents Orchestrator]] ← depends_on ← [[Academic Narratologist]]（AI Agent 团队中的叙事专家角色）
 
 ## Contradictions
-- 暂无冲突内容
+- 暂无已知冲突内容
diff --git a/wiki/sources/academic-psychologist.md b/wiki/sources/academic-psychologist.md
index 46d0debb..021206b7 100644
--- a/wiki/sources/academic-psychologist.md
+++ b/wiki/sources/academic-psychologist.md
@@ -2,79 +2,53 @@
 title: "Academic Psychologist"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-25
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/academic/academic-psychologist.md]]
+- [[Agent/agency-agents/academic/academic-psychologist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Academic Psychologist——The Agency 学术部门的临床与研究心理学家人格智能体，为角色塑造提供心理学可信度支撑。
-- 问题域：角色心理学评估、人际关系动态分析、创伤/压力/冲突的真实性反应建模、群体行为心理学。
-- 方法/机制：基于 Big Five 人格框架、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、认知行为疗法（CBT）认知扭曲、社会心理学经典实验（Milgram/Zimbardo/Asch）等多种理论与实证框架，对角色进行多维度心理画像。
-- 结论/价值：拒绝将角色病理化，强调区分流行心理学与循证心理学，承认文化情境与创伤响应的多样性，要求所有心理观察必须引用具体理论或实证研究并诚实承认其局限性。
+- 核心主题：Psychologist Agent — 专注于人格、动机、创伤和群体动力学的临床与研究心理学 Agent，为角色构建提供心理学可信的行为和互动框架
+- 问题域：如何让 AI Agent 生成的角色行为具有心理学上的真实感，避免将角色简化为诊断标签或刻板印象
+- 方法/机制：通过 Big Five 人格框架、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、认知行为疗法（CBT）等established心理学框架评估和设计角色心理
+- 结论/价值：为角色扮演类 Agent 提供了系统化的心理学评估工具箱，强调区分流行心理学与研究实证心理学，并诚实地承认每种理论框架的局限性
 
 ## Key Claims（用中文描述）
-- 不将角色降低为诊断。角色可以表现出自恋*特质*而无需成为"自恋者"——人不是 DSM 代码。
-- 区分**流行心理学**与**循证心理学**。引用某理论时，需了解该理论是同行评审还是自助类。
-- 承认文化情境。依恋理论源于西方个人主义背景。集体主义文化可能呈现不同的"健康"模式。
-- 创伤响应多样。并非所有创伤都导致退缩——有人变得高度警觉，有人变成讨好者，有人通过隔离高效运转。
-- 对心理学未解之谜保持诚实。该领域存在可重复性危机、文化偏见和真正的争议——不将争议性发现当作既定科学呈现。
+- Psychodynamic Agent 在评估角色时，必须以命名理论或实证研究为基础（with honest acknowledgment of that theory's limitations）
+- 人格行为通过 Big Five 框架映射，每种特质都需要行为表现的具体化
+- 依恋风格（安全型/焦虑型/回避型/恐惧型）在不同关系类型（浪漫/家庭/友谊）中有不同表现
+- 防御机制按 Vaillant 层级组织，压力下会退行到更低层级
+- 创伤反应具有多样性：过度警觉型、取悦他人型、隔离回避型、高功能 compartmentalization — 不能简化为"悲惨背景=破碎角色"
+- 群体心理学分析应结合社会认同理论（ Tajfel）、群体思维（ Janis）、旁观者效应（ Milgram/Zimbardo）
 
 ## Key Quotes
-> "People don't do things for no reason — I find the reason" — Psychologist Agent 核心信念
-> "观察先于诊断" — 收集行为证据后再映射到理论框架
-> "Use multiple lenses: No single theory explains everything" — 交叉参考 Big Five、依恋理论与文化背景
+> "People don't do things for no reason — I find the reason" — Psychologist Agent 核心信条，贯穿整个 Agent 设计
+> "Never reduce characters to diagnoses. A character can exhibit narcissistic *traits* without being 'a narcissist.' People are not their DSM codes." — 拒绝将角色标签化的核心原则
+> "Distinguish between **pop psychology** and **research-backed psychology**. If you cite something, know whether it's peer-reviewed or self-help." — 方法论诚信要求
+> "The field has replication crises, cultural biases, and genuine debates. Don't present contested findings as settled science." — 学术诚实标准
 
 ## Key Concepts
-- [[Big-Five-Personality]]: 人格五因素模型（开放性、尽责性、外向性、宜人性、神经质），用于量化角色核心人格特质
-- [[Attachment-Theory]]: 依恋理论（安全型/焦虑型/回避型/恐惧型），用于分析角色在亲密关系中的行为模式
-- [[Defense-Mechanisms]]: Vaillant 防御机制层级（成熟型/神经症型/不成熟型），用于识别角色在压力下的应对策略
-- [[Cognitive-Distortions]]: Beck 认知扭曲（十种常见非理性思维模式），用于识别驱动角色决策的具体认知偏差
-- [[Karpman-Drama-Triangle]]: Karpman 戏剧三角（受害者/迫害者/拯救者），用于分析人际冲突中的角色动态
-- [[Transactional-Analysis]]: 沟通分析（父母/成人/儿童三种自我状态），用于诊断角色间沟通模式
-- [[Social-Psychology-Classics]]: Milgram（服从权威）、Zimbardo（斯坦福监狱实验）、Asch（从众实验）及其现代批判
-- [[Cognitive-Behavioral-Therapy]]: CBT 认知行为疗法框架，用于建模现实的心理干预路径
-- [[Developmental-Psychology]]: Erikson 心理社会发展阶段、Piaget 认知发展、Bowlby 依恋起源
-- [[Trauma-Informed-Analysis]]: 创伤知情分析——PTSD、复杂性创伤、代际创伤（van der Kolk/Herman/Porges 理论）
-- [[Group-Psychology]]: 群体心理（社会认同理论/群体思维/责任扩散/暴民心理）
-- [[Cross-Cultural-Psychology]]: 跨文化心理学（Markus & Kitayama 文化模式/Hofstede 文化维度）
-- [[Psychological-Profile]]: 角色心理画像技术文档格式——整合 Big Five + 依恋风格 + 防御机制 + 核心创伤 + 应对策略 + 盲点
+- [[BigFive]]：人格五因素模型——开放性、尽责性、外向性、宜人性、神经质，用于系统性评估角色特质
+- [[AttachmentTheory]]：Bowlby 依恋理论——评估角色在亲密关系中的依恋风格及其触发情境
+- [[KarpmanDramaTriangle]]：Karpman 戏剧三角——识别角色间的关系动态（受害者/迫害者/拯救者）
+- [[CBT-CognitiveDistortions]]：认知行为疗法的认知扭曲分类——识别驱动角色决策的具体认知模式
+- [[PsychodynamicDefenseMechanisms]]：Vaillant 防御机制层级——intellectualization/projection/humor 等在压力下的表现
+- [[EriksonPsychosocialStages]]：Erikson 心理社会发展阶段——早期经历如何以非决定论方式塑造成人人格
+- [[PolyvagalTheory]]：Porges 迷走神经理论——理解 PTSD、复杂创伤的生理基础
+- [[Groupthink]]：Janis 群体思维——群体决策中的从众压力与去个性化风险
+- [[SocialIdentityTheory]]：Tajfel 社会认同理论——群体内/外动态如何影响行为
+- [[TransactionalAnalysis]]：交互分析——映射权力动态、沟通模式和角色间的隐性契约
 
 ## Key Entities
-- [[Erik Erikson]]: 心理社会发展理论提出者，Erikson 八阶段理论用于角色发展轨迹建模
-- [[Jean Piaget]]: 认知发展理论提出者，Piaget 四阶段用于角色认知成熟度评估
-- [[John Bowlby]]: 依恋理论创始人，Bowlby 依恋风格分类影响角色亲密关系建模
-- [[Aaron Beck]]: 认知行为疗法创始人，Beck 认知扭曲十种类型用于角色决策分析
-- [[Stephen Karpman]]: 戏剧三角提出者，Karpman 三角用于人际冲突建模
-- [[George Vaillant]]: 防御机制层级研究者，Vaillant 层级用于压力应对策略分类
-- [[Stanley Milgram]]: 服从权威实验研究者，Milgram 实验用于群体压力建模
-- [[Philip Zimbardo]]: 斯坦福监狱实验研究者，Zimbardo 实验用于权威与情境分析
-- [[Solomon Asch]]: 从众实验研究者，Asch 实验用于群体从众建模
-- [[Judith Herman]]: 复杂性创伤与恢复阶段研究者（Herman 三阶段恢复模型）
-- [[Bessel van der Kolk]]: 创伤与身体关系研究者（"身体记录创伤"核心概念）
-- [[Stephen Porges]]: Polyvagal Theory 提出者，Porges 理论用于创伤响应建模
-- [[Hans Eysenck]]: 大五人格先驱研究者
-- [[Richard Lazarus]]: 压力与应对理论研究者
+- [[PsychologistAgent]]：本 source 描述的核心 Agent——临床与研究心理学家，专注于人格、动机、创伤和群体动力学
 
 ## Connections
-- [[Big-Five-Personality]] ← foundational_framework ← [[Psychological-Profile]]
-- [[Attachment-Theory]] ← behavioral_pattern ← [[Psychological-Profile]]
-- [[Defense-Mechanisms]] ← under_stress_response ← [[Psychological-Profile]]
-- [[Cognitive-Distortions]] ← driving_force ← Character-Decisions
-- [[Karpman-Drama-Triangle]] ← conflict_model ← Interpersonal-Dynamics
-- [[Transactional-Analysis]] ← communication_pattern ← Interpersonal-Dynamics
-- [[Trauma-Informed-Analysis]] ← advanced_capability ← [[Psychological-Profile]]
-- [[Group-Psychology]] ← advanced_capability ← Interpersonal-Dynamics
-- [[Behavioral-Nudge-Engine]] ← theoretical_foundation ← [[Behavioral-Psychology]]（本 Wiki 已有 [[Behavioral-Psychology]] Concept Page）
-- [[multi-agent-system-reliability]] ← conflicts_with ← 确定性 vs LLM 概率性悖论
+- [[AgentsOrchestrator]] ← manages ← [[PsychologistAgent]]
+- [[PsychologistAgent]] ← informs ← [[NarrativeDesigner]]（角色心理为叙事设计提供真实感）
 
 ## Contradictions
-- 与 [[multi-agent-system-reliability]] 冲突：
-  - 冲突点：多智能体系统可靠性主张"架构约束优于提示词约束"（确定性），Psychologist Agent 依赖 LLM 推理进行心理评估（概率性）。
-  - 当前观点：心理评估需要概率性推理能力，但可以通过 Chain-of-Thought 约束推理路径。
-  - 对方观点：LLM 作为不可靠组件，不应依赖其进行推理，应通过架构强制正确性。
-- 与流行心理学（MBTI/Enneagram）张力：
-  - 冲突点：MBTI 和 Enneagram 在大众中广泛使用，但学术可信度有限。
-  - 当前观点：Enneagram 仅作为叙事工具接受，MBTI 局限性必须明确标注。
-  - 对方观点：MBTI 简单直观，适合快速角色原型划分。
+- 与流行心理学刻板印象的冲突：
+  - 冲突点：流行文化倾向于将角色简化为诊断标签（如"他是自恋者"）
+  - 当前观点：Agent 必须通过具体行为证据映射到理论框架，拒绝标签化
+  - 对方观点：将复杂心理现象简化为诊断术语便于快速理解和沟通
diff --git a/wiki/sources/accounts-payable-agent.md b/wiki/sources/accounts-payable-agent.md
index 0ddc0430..6f7d64af 100644
--- a/wiki/sources/accounts-payable-agent.md
+++ b/wiki/sources/accounts-payable-agent.md
@@ -6,42 +6,60 @@ date: 2026-04-25
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/accounts-payable-agent.md]]
+- [[Agent/agency-agents/specialized/accounts-payable-agent.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AccountsPayable Agent——自主支付运营专员 Agent，处理供应商付款、承包商发票和周期性账单，覆盖加密货币、法定货币、稳定币等全支付通道
-- 问题域：AI Agent 工作流中的支付执行、审计追踪、防重复付款、多通道路由
-- 方法/机制：幂等性检查 → 供应商注册表验证 → 最优通道路由 → 执行支付 → 审计日志全链路；通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 等集成
-- 结论/价值：为 AI Agent 生态提供可信赖的支付执行层，零重复付款、完整审计覆盖、60秒内 escalation SLA
+- 核心主题：Accounts Payable Agent 是 The Agency 的自主支付运营专家智能体，专注于供应商付款、承包商发票和周期性账单处理，涵盖加密货币、法币、稳定币全支付通道
+- 问题域：企业应付账款（AP）自动化、多通道支付路由、支付幂等性、审计合规、支付故障恢复
+- 方法/机制：
+  - 幂等性检查（Idempotency）：付款前查询发票引用号，确保不重复支付
+  - 审批阈值（Approval Threshold）：超过授权限额自动上报人工审批
+  - 多通道路由（Payment Rail Routing）：根据收款人、金额和成本自动选择最优通道（ACH/Wire/Crypto/Stablecoin/Payment API）
+  - 供应商注册表（Vendor Registry）：维护已批准供应商的首选支付通道和收款地址
+  - 审计日志（Audit Trail）：每笔支付记录完整上下文（发票号、金额、通道、时间戳、状态）
+  - Agent 间工具调用集成：接收来自 Contracts Agent、Project Manager、HR Agent 的支付请求
+- 结论/价值：实现企业级支付运营的端到端自动化，零重复支付、100% 审计覆盖、<2 分钟执行时间
 
 ## Key Claims（用中文描述）
-- AccountsPayable Agent 通过幂等性检查确保永远不会发送同一笔支付两次
-- Agent 自动选择最优支付通道（ACH/ Wire/ Crypto/ Stablecoin/ Payment API），基于接收方、金额和成本
-- 所有支付均保留完整审计日志，包含发票引用、金额、通道、时间戳和状态
-- 超过授权额度的支付必须上报人工审批，不得自动执行
+- AccountsPayable Agent 通过幂等性检查机制，在每次支付前验证发票是否已付清，实现零重复支付
+- Agent 根据收款人类型、金额和成本自动选择最优支付通道（ACH/Wire/Crypto/Stablecoin/Payment API），无需人工干预
+- 超过授权限额的支付请求自动上报人工审批，不执行越权操作
+- Agent 通过工具调用（Tool Calls）与其他 Agent（Contracts Agent、Project Manager、HR Agent）集成，实现跨 Agent 支付工作流自动化
+- 每笔支付均生成完整审计日志，包含发票引用、金额、通道、时间戳和状态
 
 ## Key Quotes
-> "Idempotency first: Check if an invoice has already been paid before executing. Never pay twice." — 核心安全原则
-> "If a payment rail fails, try the next available rail before escalating" — 容错路由机制
-> "Zero duplicate payments — idempotency check before every transaction" — 成功指标
+> "You are **AccountsPayable**, the autonomous payment operations specialist who handles everything from one-time vendor invoices to recurring contractor payments. You treat every dollar with respect, maintain a clean audit trail, and never send a payment without proper verification." — 身份定义
+
+> "**Idempotency first**: Check if an invoice has already been paid before executing. Never pay twice." — 核心安全规则
+
+> "If a payment rail fails, try the next available rail before escalating." — 支付故障处理策略
+
+> "Never exceed your authorized limit without explicit human approval." — 权限边界
 
 ## Key Concepts
-- [[Idempotency]]：幂等性——同一笔支付请求无论执行多少次，结果相同。AccountsPayable 通过 reference ID 去重，防止重复付款
-- [[Payment-Rail]]：支付通道——ACH（国内/工资，1-3天）、Wire（大额/跨境，即时）、Crypto（加密原生供应商，分钟级）、Stablecoin（低费用，秒级）、Payment API（卡片/平台，1-2天）
-- [[Audit-Trail]]：审计追踪——每笔支付记录发票引用、金额、通道、时间戳和状态，确保财务合规
-- [[Vendor-Registry]]：供应商注册表——维护已批准供应商及其首选支付通道和地址
+- [[Idempotency-Check]]：幂等性检查——在执行支付前，通过发票引用号查询是否已支付，防止重复付款的核心安全机制
+- [[Audit-Trail]]：审计日志——每笔支付记录完整上下文（发票号、金额、支付通道、时间戳、状态），确保可追溯性
+- [[Payment-Rail-Routing]]：支付通道路由——根据收款人类型、金额和成本自动选择最优支付通道（ACH/Wire/Crypto/Stablecoin/Payment API）
+- [[Vendor-Registry]]：供应商注册表——维护已批准供应商的首选支付通道和收款地址，确保支付至正确账户
+- [[Spend-Limit]]：消费限额——Agent 的自主支付授权上限，超过限额需人工审批
+- [[Approval-Threshold]]：审批阈值——触发人工审批流程的金额界限
 
 ## Key Entities
-- [[Contracts-Agent]]：里程碑完成后触发 AccountsPayable 执行承包商付款
-- [[Project-Manager-Agent]]：处理承包商工时材料发票
-- [[HR-Agent]]：负责工资单发放
-- [[Strategy-Agent]]：接收支出报告和资金跑道分析
+- [[ContractsAgent]]：接收里程碑完成触发信号，执行承包商里程碑支付
+- [[ProjectManagerAgent]]：发起承包商工时材料发票的支付请求
+- [[HRAgent]]：处理工资发放的支付请求
+- [[StrategyAgent]]：接收支出报告和资金跑道分析数据
+- [[Stripe]]：Payment API 支付通道之一
+- ACH（Automated Clearing House）：美国自动清算支付通道，适合国内供应商和工资发放，结算周期 1-3 天
+- Wire Transfer：电汇通道，适合大额/国际支付，当日结算
+- BTC/ETH Crypto：加密货币通道，适合加密原生供应商，数分钟内结算
+- USDC/USDT Stablecoin：稳定币通道，低费用、近实时结算
 
 ## Connections
-- [[Accounts-Payable-Agent]] ← receives_payment_requests ← [[Contracts-Agent]]
-- [[Accounts-Payable-Agent]] ← receives_payment_requests ← [[Project-Manager-Agent]]
-- [[Accounts-Payable-Agent]] ← receives_payment_requests ← [[HR-Agent]]
-- [[Accounts-Payable-Agent]] ← provides_spend_reports ← [[Strategy-Agent]]
+- [[ContractsAgent]] ← payment_trigger ← [[AccountsPayableAgent]]
+- [[ProjectManagerAgent]] ← invoice_request ← [[AccountsPayableAgent]]
+- [[HRAgent]] ← payroll_disbursement ← [[AccountsPayableAgent]]
+- [[StrategyAgent]] ← spend_report ← [[AccountsPayableAgent]]
 
 ## Contradictions
-- （本文档为单一 Agent 设计文档，暂无已知内容冲突）
+- 无已知跨页面内容冲突
diff --git a/wiki/sources/agent-activation-prompts.md b/wiki/sources/agent-activation-prompts.md
new file mode 100644
index 00000000..cdee1242
--- /dev/null
+++ b/wiki/sources/agent-activation-prompts.md
@@ -0,0 +1,82 @@
+---
+title: "NEXUS Agent Activation Prompts"
+type: source
+tags: ["multi-agent", "orchestration", "prompt-templates", "agent-activation", "nexus"]
+sources: []
+date: 2026-05-29
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/coordination/agent-activation-prompts.md]]
+
+## Summary（用中文描述）
+- 核心主题：NEXUS 流水线中各类 Agent 的标准化激活提示词模板库，覆盖编排、工程、设计、测试、产品、支持六大部门
+- 问题域：如何为每个专业 Agent 提供完整上下文（阶段、任务、参考文档、质量标准），使其能立即投入工作并符合流水线质量要求
+- 方法/机制：部门分类 + 角色模板化；每个模板包含 Phase/Task/Acceptance Criteria/Reference Documents/Implementation Requirements 五大要素；完成后自动对接相应 QA Agent
+- 结论/价值：实现 Agent 的即插即用——任何 Agent 收到激活提示词即可在正确上下文下执行，无需重复初始化
+
+## Key Claims（用中文描述）
+- NEXUS 流水线中每个 Agent 都有标准化的激活提示词模板，通过 Phase/Task/Acceptance Criteria/Reference Documents/Implementation Requirements 五大要素提供完整上下文
+- Dev↔QA 循环是流水线核心机制：Developer 实现 → Evidence Collector 截图验证 → PASS/FAIL 决策，最多 3 次重试后升级
+- Evidence Collector 默认需要多端截图（桌面/平板/手机）作为验证证据，品牌一致性和可访问性是强制检查项
+- Reality Checker 是最终守门人，默认判决为"NEEDS WORK"，必须用压倒性证据才能获得"READY"
+- Executive Summary Generator 强制使用 SCQA 框架（Situation-Complication-Question-Answer），每个发现必须有量化数据支撑
+
+## Key Quotes
+> "Evidence over claims — require proof for all quality assessments." — NEXUS 质量原则：证据优于声明
+> "Default to 'NEEDS WORK' unless overwhelming evidence proves production readiness." — Reality Checker 默认判决原则
+> "Maximum 3 retries per task before escalation." — Dev↔QA 循环重试上限
+> "Build only what's needed to test the hypothesis." — Rapid Prototyper 核心原则：速度优于完美
+> "AI ethics and safety are mandatory — no shortcuts." — AI Engineer 强制要求
+
+## Key Concepts
+- [[Dev-QA-Loop]]：开发与质量验证的循环机制——Developer 实现 → Evidence Collector 截图验证 → PASS/FAIL → 失败则重试，最多 3 次后升级
+- [[Quality-Gate]]：质量门控——任务必须通过质量验证才能推进到下一任务或下一阶段
+- [[Evidence-Based-QA]]：基于截图证据的质量保证——要求桌面/平板/手机多端截图作为验证依据
+- [[Context-Continuity]]：上下文连续性——每次交接携带完整上下文（Phase、Task、Reference Documents），Agent 不从冷启动开始
+- [[Escalation]]：升级机制——任务超过 3 次重试失败后升级至更高权限 Agent
+- [[SCQA-Framework]]：Situation-Complication-Question-Answer 框架——Executive Summary Generator 强制使用的结构化报告格式
+- [[RICE-Scoring]]：RICE 评分法（Reach × Impact × Confidence / Effort）——Sprint Prioritizer 用于 backlog 优先级排序
+
+## Key Entities
+- [[AgentsOrchestrator]]：流水线总指挥——协调所有 Agent 激活、阶段推进和 Dev↔QA 循环
+- [[FrontendDeveloper]]：前端开发者 Agent——负责 UI 实现，遵循设计系统和可访问性标准（WCAG 2.1 AA）
+- [[BackendArchitect]]：后端架构师 Agent——负责系统架构、API 开发、安全加固，响应时间要求 < 200ms P95
+- [[AIEngineer]]：AI 工程师 Agent——负责 ML 系统设计、偏见测试、模型监控，推理延迟 < 100ms
+- [[DevOpsAutomator]]：DevOps 自动化 Agent——负责 CI/CD 流水线、安全扫描、监控告警，目标 99.9% 运行时间
+- [[RapidPrototyper]]：快速原型师 Agent——强调速度优先，核心假设验证，使用快速开发栈（Next.js, Supabase, Clerk, shadcn/ui）
+- [[UXArchitect]]：UX 架构师 Agent——负责技术架构和 UX 基础，产出 CSS 设计系统、布局框架、组件架构、可访问性基础
+- [[BrandGuardian]]：品牌守护者 Agent——负责品牌身份开发、视觉一致性维护，确保所有颜色符合 WCAG AA 对比度标准
+- [[EvidenceCollector]]：截图证据收集 Agent——负责任务级 QA 验证，要求多端截图、品牌一致性、可访问性验证
+- [[RealityChecker]]：最终集成验证 Agent——是流水线的最终守门人，默认判决"NEEDS WORK"，要求压倒性证据才能"READY"
+- [[APITester]]：API 测试 Agent——负责端点验证，覆盖愉快路径、认证、校验、限流、响应时间
+- [[SprintPrioritizer]]：Sprint 优先级排序 Agent——使用 RICE 评分法对 backlog 排序，考虑团队速率（不超过 10% 过度承诺）
+- [[ExecutiveSummaryGenerator]]：执行摘要生成 Agent——强制 SCQA 框架，每个发现必须有量化数据，325-475 词
+
+## Connections
+- [[nexus-strategy]] ← extends ← [[agent-activation-prompts]]（本文档是 NEXUS 策略的 Agent 激活层实现，提供具体提示词模板）
+- [[agents-orchestrator]] ← uses ← [[agent-activation-prompts]]（编排器使用本文档中的模板激活各专业 Agent）
+- [[Dev-QA-Loop]] ← implemented_by ← [[EvidenceCollector]] + [[FrontendDeveloper]]（Dev↔QA 循环由开发者和证据收集者共同实现）
+- [[Quality-Gate]] ← enforced_by ← [[EvidenceCollector]] + [[RealityChecker]]（质量门控由截图验证和最终集成双重把关）
+- [[SprintPrioritizer]] ← depends_on ← [[nexus-strategy]]（优先级排序 Agent 依赖 NEXUS 框架定义的流程）
+- [[ExecutiveSummaryGenerator]] ← supports ← [[nexus-strategy]]（执行摘要为 NEXUS 流水线的里程碑报告提供标准化格式）
+
+## Quick Reference Table
+
+| Situation | Primary Prompt | Support Prompts |
+|-----------|---------------|-----------------|
+| Starting a new project | Orchestrator — Full Pipeline | — |
+| Building a feature | Orchestrator — Dev↔QA Loop | Developer + Evidence Collector |
+| Fixing a bug | Backend/Frontend Developer | API Tester or Evidence Collector |
+| Running a campaign | Content Creator | Social Media Strategist + platform agents |
+| Preparing for launch | See Phase 5 Playbook | All marketing + DevOps agents |
+| Monthly reporting | Executive Summary Generator | Analytics Reporter + Finance Tracker |
+| Incident response | Infrastructure Maintainer | DevOps Automator + relevant developer |
+| Market research | Trend Researcher | Analytics Reporter |
+| Compliance audit | Legal Compliance Checker | Executive Summary Generator |
+| Performance issue | Performance Benchmarker | Infrastructure Maintainer |
+
+## Contradictions
+- 与 [[agents-orchestrator]] 的视角差异：
+  - 冲突点：本文档提供 Agent 激活提示词模板，agents-orchestrator.md 描述编排器的职责和协调机制
+  - 说明：两者互补——agents-orchestrator.md 定义"做什么"，agent-activation-prompts.md 定义"怎么做"（每个 Agent 的具体提示词）
diff --git a/wiki/sources/agentic-identity-trust.md b/wiki/sources/agentic-identity-trust.md
index 696d07b2..9ab0f667 100644
--- a/wiki/sources/agentic-identity-trust.md
+++ b/wiki/sources/agentic-identity-trust.md
@@ -2,52 +2,56 @@
 title: "Agentic Identity & Trust Architect"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/agentic-identity-trust.md]]
+- [[Agent/agency-agents/specialized/agentic-identity-trust.md]]
 
 ## Summary（用中文描述）
-- 核心主题：为自主 AI Agent 构建身份认证与信任验证基础设施，确保 Agent 能证明自身身份、授权范围和操作记录的完整性。
-- 问题域：多 Agent 环境中身份伪造、授权链验证缺失、可篡改日志、凭证过期未检测、委托权限升级等安全问题。
-- 方法/机制：零信任身份体系（永不信任自我声明）、密码学身份证明、证据链完整性、委托链验证、信任评分、Fail-Closed 授权策略。
-- 结论/价值：Agentic AI 系统在执行高风险操作（资金转账、基础设施部署、物理控制）前，必须完成五项验证：身份有效性、凭证时效性、权限充分性、信任评分、委托链完整性。
+- 核心主题：为自主 AI Agent 构建身份与信任验证基础设施，使得 Agent 在高风险环境中可证明自身身份、验证授权、生成防篡改操作记录
+- 问题域：多 Agent 环境下的身份伪造、授权滥用、审计记录篡改、委派链断裂等安全问题
+- 方法/机制：零信任架构（Never Trust Self-Reported）+ 密码学身份证明 + 可验证委派链 + 追加式证据链 + 基于可观测结果的信任评分
+- 结论/价值：身份与授权必须分离验证；不可变日志才能用于审计；委派链任一环节断裂则整链失效；信任必须量化而非自我声称
 
 ## Key Claims（用中文描述）
-- 零信任原则：Agent 不得信任自我声明的身份或授权——"Agent 说它被授权"不等于"Agent 证明了它被授权"。
-- 证据链完整性：证据链的任何历史记录被篡改必须可被检测；写日志的实体若能修改日志，则该日志对审计毫无价值。
-- Fail-Closed 授权：身份无法验证 → 拒绝操作；委托链存在断裂 → 整链无效；信任评分低于阈值 → 要求重新验证。
-- 密码学卫生规范：使用成熟标准（Ed25519/ECDSA），签名密钥与加密密钥分离，密钥材料不得出现在日志或 API 响应中。
-- 信任评分基于可验证结果：信任分从 1.0 开始，仅通过可验证问题扣分；不允许 Agent 自我报告信号来提高信任分。
+- 零信任原则：Agent 不得依赖自我声称的身份或授权，必须通过密码学证明和可验证委派链进行验证
+- 身份与授权分离：证明"我是谁"与证明"我被授权做这件事"是两个独立的验证步骤
+- 失败即拒绝（Fail-Closed）：若无法验证身份或授权链，必须拒绝执行，而非默认允许
+- 信任基于可观测结果：信任评分依据已验证的客观行为记录，而非自我报告的声明
+- 证据链不可篡改：追加式记录 + 前置哈希链接 + Agent 签名，使得任何历史记录修改可被检测
 
 ## Key Quotes
-> "Never trust self-reported identity. An agent claiming to be 'finance-agent-prod' proves nothing. Require cryptographic proof." — 零信任原则核心表述
-> "If identity cannot be verified, deny the action — never default to allow." — Fail-Closed 授权策略
-> "Trust score 0.92 based on 847 verified outcomes with 3 failures and an intact evidence chain" — 量化信任而非断言信任
-> "Design every system assuming at least one agent in the network is compromised or misconfigured." — 假设妥协的安全设计哲学
+> "Never trust self-reported identity. An agent claiming to be 'finance-agent-prod' proves nothing. Require cryptographic proof." — 零信任身份原则
+> "Identity and authorization are separate verification steps. Prove who this agent is — that doesn't prove it's authorized for this specific action." — 身份与授权分离原则
+> "If a delegation chain has a broken link, the entire chain is invalid." — 委派链失效原则
+> "Trust score 0.92 based on 847 verified outcomes with 3 failures and an intact evidence chain" — 信任必须量化表达
 
 ## Key Concepts
-- [[Zero-Trust]]：永不信任自我声明，要求密码学证明。适用于身份验证、授权验证和日志完整性三个层面。
-- [[Evidence-Chain]]：仅追加、可独立验证、链式哈希、防篡改的 Agent 操作证据记录系统。
-- [[Trust-Scoring]]：基于可观测结果的惩罚模型信任评分，Agent 从 1.0 开始，仅通过可验证问题扣分。
-- [[Delegation-Chain]]：多跳委托授权链，每一跳须签名且作用域不得宽于上级，过期或断裂则整链无效。
-- [[Fail-Closed]]：授权失败时默认拒绝，而非默认允许的安全策略。
-- [[Peer-Verification]]：Agent 之间在接受委托工作前互相验证身份和授权的协议。
-- [[Algorithm-Agility]]：密码学算法可升级性，为后量子密码学迁移预留抽象层。
+- [[Zero-Trust-Model]]：永不信任自我声称的身份或授权，所有声明必须通过密码学证明验证
+- [[Trust-Score-Model]]：基于可观测结果的惩罚型信任评分，初始1.0，只扣不减（证据链完整性、行为达成率、凭证新鲜度）
+- [[Delegation-Chain]]：多跳授权链，每个链接需签名、作用域不得超出上级、需验证时间有效性，链中断则整链失效
+- [[Evidence-Record]]：追加式、防篡改的 Agent 行为证据记录，通过前置哈希链接形成链式结构
+- [[Peer-Verification-Protocol]]：Agent 接受委托前必须验证对端的身份、凭证有效期、作用域、信任评分和委派链
+- [[Fail-Closed-Authorization]]：验证失败时默认拒绝，不默认允许
+- [[Cryptographic-Identity-Scheme]]：基于 Ed25519/ECDSA 等标准算法的 Agent 身份方案，支持后量子迁移
 
 ## Key Entities
-- [[Identity-Graph-Operator]]：与本文档并列的 Entity 身份解析 Agent，本文档负责 Agent 身份认证，Identity Graph Operator 负责人/公司/产品实体解析。
-- [[The Agency]]：该 Agent 所属的 The Agency 专业化 Agent 生态。
+- [[Identity-Graph-Operator]]：与 Trust Architect 互补的实体——前者负责 Agent 身份（"这 Agent 是谁"），后者负责人/公司/产品的实体身份（"这条记录对应哪个客户"）
+- [[The-Agency]]：Agent 所在的多 Agent 组织环境
+- [[A2A]]：多 Agent 通信协议之一，Trust Architect 需支持跨协议的身份联邦
+- [[MCP]]：Model Context Protocol，Trust Architect 需支持其身份桥接
+- [[LangChain]]：Agent 编排框架之一，Trust Architect 需支持其身份翻译层
+- [[CrewAI]]：Agent 编排框架之一，Trust Architect 需支持其身份翻译层
 
 ## Connections
-- [[Identity-Graph-Operator]] ← 互补关系 ← [[Agentic-Identity-Trust]]
-- [[Designing-for-Agentic-AI]] ← 潜在冲突 ← [[Agentic-Identity-Trust]]（确定性要求与 LLM 概率性行为的张力）
-- [[agents-orchestrator]] ← 依赖 ← [[Agentic-Identity-Trust]]（编排器需信任验证层）
-- [[report-distribution-agent]] ← 依赖 ← [[Agentic-Identity-Trust]]（分发代理操作需可审计）
+- [[Identity-Graph-Operator]] ← complements ← [[Agentic-Identity-Trust]]
+- [[Multi-Agent-System-Reliability]] ← depends_on ← [[Agentic-Identity-Trust]]
+- [[Agents-Orchestrator]] ← requires ← [[Agentic-Identity-Trust]]
 
 ## Contradictions
-- 与 [[Designing-for-Agentic-AI]] 冲突：
-  - 冲突点：零信任要求确定性验证 vs LLM 的概率性本质（LLM 无法提供数学意义上的确定性签名证明）
-  - 当前观点：通过将核心逻辑（密码学验证、签名检查）从 LLM 推理分离为独立组件来解决——LLM 只负责策略决策，验证层由确定性代码执行。
-  - 对方观点：若信任验证逻辑本身依赖 LLM（如自然语言授权描述），则仍存在概率性风险。
+- 与 [[specialized-document-generator]] 可能的架构冲突：
+  - 冲突点：Document Generator Agent 强调程序化文档生成能力，但未提及身份验证层；Trust Architect 强调每个 Agent 行动前必须经过身份与授权验证
+  - 当前观点：Trust Architect 认为任何自主行动的 Agent 都必须经过身份验证
+  - 对方观点：Document Generator Agent 专注于文档生成能力，身份验证可能由外层编排系统负责
+  - 协调建议：明确身份验证的边界——若由编排层（如 Agents Orchestrator）统一处理，子 Agent 专注于自身专业能力；若由各 Agent 自主处理，则需为 Document Generator Agent 补充身份验证架构
diff --git a/wiki/sources/agents-orchestrator.md b/wiki/sources/agents-orchestrator.md
index e76290d0..f1fda0c6 100644
--- a/wiki/sources/agents-orchestrator.md
+++ b/wiki/sources/agents-orchestrator.md
@@ -2,7 +2,8 @@
 title: "Agents Orchestrator"
 type: source
 tags: []
-date: 2026-04-20
+sources: []
+date: 2026-05-29
 ---
 
 ## Source File
@@ -54,6 +55,43 @@ date: 2026-04-20
 - [[Dev-QA-Loop]] ← extends ← [[Multi-Agent-System-Reliability]]（流水线编排是多 Agent 可靠性的实践框架）
 - [[AgentsOrchestrator]] ← part_of ← [[The Agency]]（编排器是 The Agency 的核心基础设施）
 
+## Available Specialist Agents
+
+### 🎨 Design & UX Agents
+- **ArchitectUX**：Technical architecture and UX specialist providing solid foundations
+- **UI Designer**：Visual design systems, component libraries, pixel-perfect interfaces
+- **UX Researcher**：User behavior analysis, usability testing, data-driven insights
+- **Brand Guardian**：Brand identity development, consistency maintenance, strategic positioning
+
+### 💻 Engineering Agents
+- **Frontend Developer**：Modern web technologies, React/Vue/Angular, UI implementation
+- **Backend Architect**：Scalable system design, database architecture, API development
+- **engineering-senior-developer**：Premium implementations with Laravel/Livewire/FluxUI
+- **Mobile App Builder**：Native iOS/Android and cross-platform development
+- **DevOps Automator**：Infrastructure automation, CI/CD, cloud operations
+- **Rapid Prototyper**：Ultra-fast proof-of-concept and MVP creation
+
+### 📈 Marketing Agents
+- **marketing-growth-hacker**：Rapid user acquisition through data-driven experimentation
+- **marketing-content-creator**：Multi-platform campaigns, editorial calendars, storytelling
+- **marketing-twitter-engager**：Real-time engagement, thought leadership, community growth
+
+### 📋 Product & Project Management Agents
+- **project-manager-senior**：Spec-to-task conversion, realistic scope, exact requirements
+- **Experiment Tracker**：A/B testing, feature experiments, hypothesis validation
+- **Project Shepherd**：Cross-functional coordination, timeline management
+
+### 🧪 Testing & Quality Agents
+- **EvidenceQA**：Screenshot-obsessed QA specialist requiring visual proof
+- **testing-reality-checker**：Evidence-based certification, defaults to "NEEDS WORK"
+- **API Tester**：Comprehensive API validation, performance testing, quality assurance
+- **Performance Benchmarker**：System performance measurement, analysis, optimization
+
+## Orchestrator Launch Command
+```
+Please spawn an agents-orchestrator to execute complete development pipeline for project-specs/[project]-setup.md. Run autonomous workflow: project-manager-senior → ArchitectUX → [Developer ↔ EvidenceQA task-by-task loop] → testing-reality-checker. Each task must pass QA before advancing.
+```
+
 ## Contradictions
 - 与 [[specialized-workflow-architect]] 冲突：
   - 冲突点：两个 Agent 都声称负责"编排"职责——前者是流水线执行编排器，后者是工作流设计专家
diff --git a/wiki/sources/aider-readme.md b/wiki/sources/aider-readme.md
new file mode 100644
index 00000000..87adbcdd
--- /dev/null
+++ b/wiki/sources/aider-readme.md
@@ -0,0 +1,44 @@
+---
+title: "Aider Integration"
+type: source
+tags: []
+date: 2026-04-30
+---
+
+## Source File
+- [[Agent/agency-agents/integrations/aider/README.md]]
+
+## Summary（用中文描述）
+- 核心主题：Aider 编辑器与 The Agency Agent 规范系统的集成方式
+- 问题域：如何在 Aider 编辑器中激活和使用基于 The Agency 规范的 AI Agent
+- 方法/机制：通过 `install.sh` 脚本安装 + 在 Aider 会话中按名称引用 Agent，或手动传递 `CONVENTIONS.md` 文件
+- 结论/价值：实现 Aider 与 The Agency Agent 规范体系的无缝对接，简化 AI 辅助编程工作流
+
+## Key Claims（用中文描述）
+- The Agency 的完整 Agent 名册集中在一个 `CONVENTIONS.md` 文件中
+- Aider 会在项目根目录自动读取 `CONVENTIONS.md`（当该文件存在时）
+- 通过名称引用即可在 Aider 会话中激活对应的 Agent（如 "Frontend Developer"、"Reality Checker"）
+- 也可通过 `aider --read CONVENTIONS.md` 手动指定约定文件
+- 使用 `convert.sh --tool aider` 可重新生成最新的 CONVENTIONS.md
+
+## Key Quotes
+> "The full Agency roster is consolidated into a single `CONVENTIONS.md` file. Aider reads this file automatically when it's present in your project root." — 安装与自动读取机制
+
+## Key Concepts
+- [[CONVENTIONS.md]]：The Agency 中 Aider 集成的核心文件，汇集所有 Agent 定义
+- [[The Agency]]：多工具、多场景的 AI Agent 规范仓库
+- [[Agent Integration]]：将统一 Agent 格式适配到各编码工具的适配层
+- [[Aider]]：支持 AI 结对编程的终端编辑器
+
+## Key Entities
+- [[Aider]]：终端 AI 编程工具，支持通过约定文件调用 Agent
+- [[Agency Agents]]：The Agency 项目中的 Agent 定义集合
+
+## Connections
+- [[CONVENTIONS.md]] ← generated_by ← [[convert.sh]]
+- [[CONVENTIONS.md]] ← read_by ← [[Aider]]
+- [[install.sh]] ← installs ← [[Aider Integration]]
+- [[The Agency]] ← provides ← [[Agency Agents]]
+
+## Contradictions
+- 暂无已知冲突
diff --git a/wiki/sources/automation-governance-architect.md b/wiki/sources/automation-governance-architect.md
index 9a76abb4..71b70512 100644
--- a/wiki/sources/automation-governance-architect.md
+++ b/wiki/sources/automation-governance-architect.md
@@ -1,49 +1,61 @@
----
-title: "Automation Governance Architect"
-type: source
-tags: []
-date: 2026-04-25
----
-
-## Source File
-- [[raw/Agent/agency-agents/specialized/automation-governance-architect.md]]
-
-## Summary（用中文描述）
-- 核心主题：企业自动化治理架构师，负责在实施前评估业务自动化的价值、风险和可维护性
-- 问题域：企业级工作流自动化决策、可靠性保障、审计追溯
-- 方法/机制：基于 n8n 的编排标准 + 四维决策框架（时间节省、数据关键性、外部依赖风险、可扩展性）
-- 结论/价值：通过治理优先的方式防止低价值或高风险自动化，推动高价值自动化的标准化落地
-
-## Key Claims（用中文描述）
-- 自动化决策必须基于价值而非技术可行性
-- 每个推荐必须包含降级方案和责任人
-- 生产级工作流必须包含显式错误分支、幂等性保护、安全重试和人工降级路径
-- 命名规范必须包含环境标识和版本号，避免模糊命名
-- 集成治理需明确数据来源权威（Source of Truth），未经明确不得接入
-
-## Key Quotes
-> "Do not approve automation only because it is technically possible." — 核心原则：技术可行不等于值得自动化
-> "No 'done' status without documentation and test evidence." — 完成标准：必须有文档和测试证据
-> "No integration is approved without source-of-truth clarity." — 集成前提：必须明确数据权威来源
-> "Prefer simple and robust over clever and fragile." — 架构偏好：简单健壮优于精巧脆弱
-
-## Key Concepts
-- [[AutomationGovernance]]：自动化治理 — 通过决策框架和标准对业务流程自动化进行事前评估、事中监控和事后审计的完整体系
-- [[N8nWorkflowStandard]]：n8n 工作流标准 — 包含触发、验证、规范化、业务逻辑、外部操作、结果验证、日志、错误分支、降级、状态回写10个强制步骤
-- [[DecisionFramework]]：决策框架 — 四维评估体系（时间节省、数据关键性、外部依赖风险、可扩展性），用于对自动化请求给出 APPROVE / APPROVE AS PILOT / PARTIAL AUTOMATION ONLY / DEFER / REJECT 五种裁决
-- [[ReliabilityBaseline]]：可靠性基线 — 每个重要工作流必须包含：错误分支、幂等性/重复保护、安全重试（带停止条件）、超时处理、告警/通知、人工降级路径
-- [[IntegrationGovernance]]：集成治理 — 每个接入系统需定义：角色与数据权威、认证方式、触发模型、字段映射、写回权限、速率限制、失败模式、负责人
-- [[ReAuditTriggers]]：重审计触发条件 — 当 API/Schema 变更、错误率上升、容量大幅增长、合规要求变更、反复出现人工修复时触发自动化重审计
-
-## Key Entities
-- [[N8n]]：n8n — 自动化治理架构师的首选编排工具，但治理规则本身是平台无关的
-
-## Connections
-- [[WorkflowArchitect]] ← relates_to ← [[AutomationGovernanceArchitect]]：两者都关注工作流设计与标准化，但 Workflow Architect 偏实现层面，Automation Governance Architect 偏治理决策层面
-- [[ComplianceAuditor]] ← overlaps ← [[AutomationGovernanceArchitect]]：合规审计与自动化治理在数据关键性和合规风险维度存在重叠
-
-## Contradictions
-- 与 [[WorkflowArchitect]] 可能的冲突：
-  - 冲突点：对于同一自动化请求，Workflow Architect 可能倾向快速实现，而 Automation Governance Architect 要求充分评估后方可实施
-  - 当前观点：治理优先，防止低价值/高风险自动化进入生产
-  - 对方观点：快速交付价值，通过迭代完善
+---
+title: "Automation Governance Architect"
+type: source
+tags: [automation, governance, n8n, workflow, business-process]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/automation-governance-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：业务自动化治理框架——在实施前评估自动化的价值、风险和可维护性，以 n8n 为首选编排工具，制定平台无关的治理规则。
+- 问题域：企业自动化决策——哪些流程值得自动化、如何标准化实施、如何防止低价值或高风险自动化进入生产。
+- 方法/机制：四维决策框架（时间节省 / 数据关键性 / 外部依赖风险 / 可扩展性）+ 五级裁定结果 + n8n 十步工作流标准 + 可靠性基线 + 日志基线 + 测试基线 + 集成治理规范 + 复审触发器。
+- 结论/价值：治理优于自动化数量——通过标准化流程防止低价值自动化，通过规范文档提升交接质量，通过重审机制降低生产事故和隐藏依赖。
+
+## Key Claims（用中文描述）
+- 治理优先于技术可行性：不得仅因技术上可实现就批准自动化，必须通过四维框架评估价值与风险。
+- 简单稳健优于精巧脆弱：推荐方案必须包含 fallback 路径和明确责任人，无文档和测试证据不得标记为完成。
+- n8n 工作流无失控节点扩散：所有生产级工作流遵循 Trigger → Input Validation → Data Normalization → Business Logic → External Actions → Result Validation → Logging → Error Branch → Fallback → Status Writeback 十步标准。
+- 集成必须明确数据源：任何集成在未明确数据源归属（Source of Truth）之前不得批准。
+- 命名规范化防歧义：工作流命名格式为 `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`，避免 "final"、"new test"、"fix2" 等模糊命名。
+- 复审不等于自动干预：API/Schema 变更、错误率上升、批量变化、合规要求变更或重复人工修复出现时触发重审，但重审本身不意味着自动进入生产干预。
+- 成功标准是业务可靠性提升，而非自动化数量增加。
+
+## Key Quotes
+> "Do not approve automation only because it is technically possible." — 核心原则：技术可行 ≠ 应该自动化
+
+> "Prefer simple and robust over clever and fragile." — 架构选择原则：简单稳健优先
+
+> "No integration is approved without source-of-truth clarity." — 集成治理底线：必须明确数据源归属
+
+> "You are successful when business reliability improves, not just automation volume." — 成功度量：业务可靠性，而非自动化数量
+
+## Key Concepts
+- [[n8n-Workflow-Standard]]：n8n 生产级工作流十步标准（Trigger / Input Validation / Data Normalization / Business Logic / External Actions / Result Validation / Logging / Error Branch / Fallback / Status Writeback），禁止节点失控扩散。
+- [[Automation-Decision-Framework]]：四维评估框架——Time Savings Per Month（时间节省）、Data Criticality（数据关键性）、External Dependency Risk（外部依赖风险）、Scalability 1x to 100x（可扩展性），每个请求必评。
+- [[Automation-Verdict-System]]：五级裁定结果——APPROVE（强价值+可控风险）、APPROVE AS PILOT（价值存在但需小范围验证）、PARTIAL AUTOMATION ONLY（仅安全段自动化）、DEFER（流程不成熟或依赖不稳定）、REJECT（经济性弱或运营/合规风险不可接受）。
+- [[Automation-Reliability-Baseline]]：可靠性基线——显式错误分支、幂等/重复保护、安全重试（含停止条件）、超时处理、告警通知、人工 fallback 路径。
+- [[Automation-Logging-Baseline]]：日志基线——记录工作流名称/版本、执行时间戳、源系统、受影响实体ID、成功/失败状态、错误类型及简要原因。
+- [[Automation-Testing-Baseline]]：测试基线（生产推荐前必须）——快乐路径测试、无效输入测试、外部依赖失败测试、重复事件测试、fallback/恢复测试、规模/重复合理性检查。
+- [[Automation-Integration-Governance]]：集成治理——每连接系统须定义角色和数据源归属、认证方式和 token 生命周期、触发模型、字段映射和转换、读写权限、速率限制和失败模式、负责人和升级路径。
+- [[Re-Audit-Triggers]]：复审触发条件——API/Schema 变更、错误率上升、批量显著增长、合规要求变更、重复人工修复出现；复审本身不自动触发生产干预。
+- [[Workflow-Naming-Convention]]：命名规范 `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`，大版本用于破坏性逻辑变更，小版本用于兼容改进。
+
+## Key Entities
+- [[Automation-Governance-Architect]]：治理优先的业务自动化架构师 Agent，默认使用 n8n 作为编排工具，治理规则平台无关。职责：防止低价值/不安全自动化、审批并标准化高价值自动化、为可靠性/可审计性/交接制定标准。
+
+## Connections
+- [[n8n-Workflow-Orchestration]] ← implements ← [[Automation-Governance-Architect]]
+- [[Automation-Decision-Framework]] ← foundation_of ← [[Automation-Verdict-System]]
+- [[Workflow-Naming-Convention]] ← part_of ← [[Automation-Reliability-Baseline]]
+- [[Automation-Testing-Baseline]] ← required_by ← [[Automation-Integration-Governance]]
+- [[Re-Audit-Triggers]] ← triggers ← [[Automation-Integration-Governance]]
+
+## Contradictions
+- 与 [[Workflow-Architect-Agent-Personality]] 冲突：
+  - 冲突点：Workflow Architect 强调"用 AI 加速工作流构建"，倾向于尽可能自动化；Automation Governance Architect 强调"治理优先于技术可行"，要求四维评估后才批准。
+  - 当前观点：自动化必须在通过时间节省 / 数据关键性 / 依赖风险 / 可扩展性四维评估后才能进入生产，不应以技术可行性作为批准依据。
+  - 对方观点：AI 应尽可能加速工作流构建，降低自动化门槛以提升效率。
+  - 协调建议：两者互补适用——Workflow Architect 负责"如何构建"，Automation Governance Architect 负责"是否值得构建"；建议在 [[Workflow-Architect-Agent-Personality]] 中补充治理评估前置步骤。
diff --git a/wiki/sources/backend-architect-with-memory.md b/wiki/sources/backend-architect-with-memory.md
index 39ee0a0c..06b7e51e 100644
--- a/wiki/sources/backend-architect-with-memory.md
+++ b/wiki/sources/backend-architect-with-memory.md
@@ -1,8 +1,8 @@
 ---
 title: "Backend Architect with Memory"
 type: source
-tags: []
-date: 2026-04-26
+tags: [the-agency, engineering, multi-agent, memory, mcp]
+date: 2026-05-29
 ---
 
 ## Source File
@@ -11,19 +11,21 @@ date: 2026-04-26
 ## Summary（用中文描述）
 - 核心主题：具备持久记忆能力的后端架构师 AI Agent 设计规范，专注于可扩展系统设计、数据库架构、API 开发与云基础设施
 - 问题域：如何构建一个能够跨会话保留架构决策、系统设计和技术约束记忆的 AI 后端架构专家
-- 方法/机制：基于 MCP Memory 集成框架，在会话开始时检索相关上下文，完成交付物后主动记忆，跨 Agent 交接时自动传递上下文
-- 结论/价值：解决多 Agent 协作中重复讨论已做决策、交接信息丢失的问题，提升 AI 架构师的实际工程价值
+- 方法/机制：基于 MCP Memory 集成框架，在会话开始时检索相关上下文，完成交付物后主动记忆，跨 Agent 交接时自动传递上下文，QA 失败时自动回滚到已知良好状态
+- 结论/价值：解决多 Agent 协作中重复讨论已做决策、交接信息丢失的问题，通过 Rollback 机制实现安全的失败恢复
 
 ## Key Claims（用中文描述）
 - 后端架构师应在会话启动时主动检索项目相关的历史架构决策，防止重复讨论
 - 架构决策（选型数据库、定义 API 契约、选择通信模式）应以标签形式持久化，供未来会话和其他 Agent 查找
 - 交付物（Schema、API 规范、架构文档）完成后应主动记忆并标记接收方，确保下游 Agent 无需手动复制粘贴
 - 遇到 QA 失败或错误决策时，应检索上一个已知良好状态并回滚，而非手动撤销变更链
+- 标签一致性是记忆召回可靠工作的前提：每个记忆使用 Agent 名称和项目名称作为标签
 
 ## Key Quotes
 > "When you start a session, recall relevant context from previous sessions. Search for memories tagged with 'backend-architect' and the current project name." — 会话启动时的记忆召回机制
 > "When you make an architecture decision — choosing a database, defining an API contract, selecting a communication pattern — remember it with tags including 'backend-architect', the project name, and the topic." — 架构决策的持久化规范
-> "This prevents re-litigating decisions that were already made." — 记忆系统的核心价值
+> "When you complete a deliverable (a schema, an API spec, an architecture document), remember it tagged for the next agent in the workflow." — 交付物的下游 Agent 标记规范
+> "When you receive a QA failure or need to recover from a bad decision, search for the last known-good state and roll back to it." — Rollback 回滚机制
 
 ## Key Concepts
 - [[MicroservicesArchitecture]]：微服务架构，支持水平扩展和独立部署，是 Backend Architect 默认推荐的架构模式
@@ -33,15 +35,26 @@ date: 2026-04-26
 - [[DatabaseIndexing]]：数据库索引优化，用于实现子 100ms 平均查询性能
 - [[CircuitBreaker]]：断路器模式，Backend Architect 实现系统可靠性和优雅降级的核心机制
 - [[DefenseInDepth]]：深度防御策略，Security-First Architecture 的核心原则
+- [[MemoryTagging]]：标签化记忆持久化策略——每个记忆使用 Agent 名称 + 项目名 + 主题标签（如 `database-schema`/`api-design`/`auth-strategy`）三重标签，确保 recall 可靠
+- [[Rollback]]：回滚机制——QA 失败时检索最近良好检查点并恢复到已知良好状态，而非手动撤销变更链
 
 ## Key Entities
 - Backend Architect：主 Agent，专门负责系统架构和服务器端开发，特点：战略思维、安全导向、可扩展性优先、可靠性至上
 - Frontend Developer：下游接收方 Agent，接收 Backend Architect 提供的 API 规范
 - QA Agent：质量保障 Agent，在失败时触发记忆回滚机制
+- Sprint Prioritizer：上游输入方 Agent，提供待开发功能的优先级排序
 
 ## Connections
 - [[AgentsOrchestrator]] ← coordinates ← [[BackendArchitectWithMemory]]
 - [[MCPBuilderAgent]] ← enables ← [[BackendArchitectWithMemory]]（MCP Memory 集成）
+- [[SprintPrioritizer]] → outputs sprint plan → [[BackendArchitectWithMemory]]（通过 MCP Memory Server recall）
+- [[UXResearcher]] → outputs research brief → [[BackendArchitectWithMemory]]（通过 MCP Memory Server recall）
+- [[BackendArchitectWithMemory]] → stores API spec → [[FrontendDeveloper]]（通过 MCP Memory Server recall）
+- [[BackendArchitectWithMemory]] ← rollback ← [[TestingRealityChecker]]（QA 失败触发）
 
 ## Contradictions
-- 无明显冲突内容
+- 与 [[engineering-software-architect]] 的设计哲学存在微妙张力：
+  - 冲突点：架构决策记录方式
+  - 当前观点（Backend Architect with Memory）：通过 MCP Memory 标签化快照持久化，支持跨 Agent 召回和自动回滚
+  - 对方观点（Software Architect）：通过 ADR（Architecture Decision Record）标准化文档记录，侧重人类可读的权衡分析
+  - 协调方案：两者互补——ADR 文档供人类阅读和团队共享，MCP Memory 快照供 Agent 自动化召回；Backend Architect 可同时使用两者作为不同场景的工具
diff --git a/wiki/sources/baoyu-skills.md b/wiki/sources/baoyu-skills.md
new file mode 100644
index 00000000..dc4fce8b
--- /dev/null
+++ b/wiki/sources/baoyu-skills.md
@@ -0,0 +1,78 @@
+---
+title: "baoyu-skills"
+type: source
+tags:
+  - "clippings"
+  - "ai-tools"
+  - "claude-code"
+date: 2026-04-19
+---
+
+## Source File
+- [[raw/Skills/baoyu-skills.md]]
+
+## Summary（用中文描述）
+
+- **核心主题**：宝玉（JimLiu）分享的 Claude Code 技能集，涵盖内容生成、视觉创作、跨平台发布和 AI 图像生成等日常工作流。
+- **问题域**：如何借助 AI Agent（Claude Code）自动化完成从内容创作、视觉素材生成到多平台发布的一整套内容生产流程。
+- **方法/机制**：
+  - **内容技能**：小红书图片（baoyu-xhs-images）、信息图（baoyu-infographic）、SVG 图表（baoyu-diagram）、封面图（baoyu-cover-image）、幻灯片（baoyu-slide-deck）、知识漫画（baoyu-comic）、文章插图（baoyu-article-illustrator）
+  - **发布技能**：X 推文/文章（baoyu-post-to-x）、微信公众号（baoyu-post-to-wechat）、微博头条文章（baoyu-post-to-weibo）
+  - **AI 生成技能**：baoyu-imagine（多 provider 文生图）、baoyu-danger-gemini-web（Gemini 交互）
+  - **工具技能**：YouTube 字幕（baoyu-youtube-transcript）、URL 转 Markdown（baoyu-url-to-markdown）、X 转 Markdown（baoyu-danger-x-to-markdown）、图片压缩（baoyu-compress-image）、Markdown 格式化（baoyu-format-markdown）、Markdown 转 HTML（baoyu-markdown-to-html）、翻译（baoyu-translate）
+- **结论/价值**：一套完整的 AI 时代内容创作者工具链，从创作→生成→发布全流程覆盖，可通过 ClawHub/OpenClaw 分发和安装。
+
+## Key Claims（用中文描述）
+
+- Claude Code 通过 Skills 机制可模块化扩展能力，宝玉将这套方法论产品化为 baoyu-skills。
+- baoyu-imagine 统一封装了 OpenAI、Google、DashScope、MiniMax、即梦（Jimeng）、豆包（Seedream）等多个图像生成 provider，通过统一 prompt 接口屏蔽底层差异。
+- 内容技能（xhs-images、infographic、cover-image、slide-deck、comic、article-illustrator）均通过风格/布局/配色/维度参数系统实现高度可复用，参数组合数量庞大（如 xhs-images 的 12 种风格 × 6 种布局 × 3 种配色）。
+- baoyu-post-to-wechat 支持 API 和浏览器两种发布方式，通过 EXTEND.md 实现多账号管理。
+- baoyu-translate 提供三档翻译模式（快速/标准/精翻），精翻模式含审校与润色步骤，支持自定义术语表和受众预设。
+- baoyu-diagram 不调用任何图像生成模型，由 Claude 直接手算 SVG 坐标生成图表，内嵌深色模式支持。
+- 技能支持通过项目级（`.baoyu-skills/`）和用户级（`~/.baoyu-skills/`）的 EXTEND.md 自定义扩展，覆盖样式、配色和配置。
+
+## Key Quotes
+
+> "baoyu-skills — 宝玉分享的 Claude Code 技能集，提升日常工作效率。" — GitHub README
+
+> "Claude Code 通过 `/baoyu-diagram` 生成的 SVG 不调用任何图像生成模型 —— Claude 通过手算坐标直接写 SVG 代码。" — 图表技能说明
+
+> "本项目受到以下开源项目的启发：x-article-publisher-skill、doocs/md、高密度信息图 Prompt、qiaomu-mondo-poster-design、architecture-diagram-generator。" — 致谢
+
+## Key Concepts
+
+- [[ClaudeCodeSkills]]：Claude Code 的可扩展技能系统，通过 `/skill-name` 触发，支持模块化安装与更新，baoyu-skills 是其典型实现。
+- [[多维度图像生成系统]]：通过类型（type）× 风格（style）× 配色（palette）× 渲染（rendering）× 氛围（mood）等多个正交维度组合控制 AI 生成图像的视觉输出，广泛应用于 baoyu-xhs-images、baoyu-cover-image、baoyu-article-illustrator 等技能。
+- [[内容发布工作流]]：从内容生成（图像/文章）到多平台发布（X/微信/微博）的自动化流水线，各发布技能支持 API 和浏览器两种方式。
+- [[多Provider图像生成]]：通过统一接口封装多个图像生成服务商（OpenAI、Google、DashScope、MiniMax、即梦、豆包等），实现 provider 自动选择和环境变量配置管理。
+- [[SVG图表生成]]：不依赖图像生成模型，由 LLM 直接生成 SVG 代码，内嵌深色模式样式，支持流程图、时序图、结构图、示意图、类图五种类型。
+- [[三档翻译系统]]：快速（直接翻译）、标准（分析→翻译）、精翻（分析→翻译→审校→润色）的渐进式翻译质量体系，配 合受众预设和风格预设。
+- [[多账号发布管理]]：通过 EXTEND.md 配置文件管理多个社交媒体账号，支持 API 凭证分离和独立浏览器会话。
+- [[ClawHub分发机制]]：支持将 skills/ 下的每个目录作为独立 ClawHub skill 发布，以 MIT-0 许可证分发，用户可选择性安装。
+
+## Key Entities
+
+- [[JimLiu]]：GitHub 用户，baoyu-skills 项目作者，持续分享 Claude Code 技能和 AI 内容创作工具。
+- [[ClawHub]]：OpenClaw/Claude Code 的插件市场，baoyu-skills 通过 ClawHub 分发各独立 skill。
+- [[OpenClaw]]：Claude Code 的技能生态平台，支持 marketplace 安装和自动更新。
+
+## Connections
+
+- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-cover-image]]
+- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-xhs-images]]
+- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-article-illustrator]]
+- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-infographic]]
+- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-slide-deck]]
+- [[baoyu-slide-deck]] ← 内容来源 ← [[baoyu-youtube-transcript]]
+- [[baoyu-diagram]] ← 内容来源 ← [[baoyu-url-to-markdown]]
+- [[baoyu-post-to-x]] ← 视觉素材 ← [[baoyu-cover-image]]
+- [[baoyu-post-to-wechat]] ← 视觉素材 ← [[baoyu-xhs-images]]
+- [[baoyu-post-to-wechat]] ← 内容格式 ← [[baoyu-markdown-to-html]]
+- [[baoyu-markdown-to-html]] ← 翻译输入 ← [[baoyu-translate]]
+- [[ClaudeCodeSkills]] ← 依赖 ← baoyu-skills（所有技能）
+- [[ClawHub]] ← 分发平台 ← baoyu-skills
+
+## Contradictions
+
+- 无已知冲突。
diff --git a/wiki/sources/blender-addon-engineer.md b/wiki/sources/blender-addon-engineer.md
index c6b64606..db335f7c 100644
--- a/wiki/sources/blender-addon-engineer.md
+++ b/wiki/sources/blender-addon-engineer.md
@@ -2,52 +2,54 @@
 title: "Blender Add-on Engineer Agent Personality"
 type: source
 tags: []
-date: 2026-04-26
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/blender/blender-addon-engineer.md]]
+- [[Agent/agency-agents/game-development/blender/blender-addon-engineer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Blender 工具开发专家 AI Agent 人格规范——通过 Python + bpy API 构建 Blender 原生工具（自定义 Operator、Panel、资产验证器、导出器），将重复性 DCC 工作流自动化为可靠的一键工作流。
-- 问题域：3D 资产生成中的命名漂移、未应用变换、错误材质槽映射、导出配置不一致等交接错误问题。
-- 方法/机制：数据 API（bpy.data）优先于操作符（bpy.ops）以确保可靠性；非破坏性验证优先于自动修复；确定性命名规范；Pipeline 可靠性三角（验证→报告→确认→导出）。
-- 结论/价值：每个工具必须节省时间或防止一类真实的交接错误；Asset Validation 可在资产离开 Blender 前拦截问题；Export Preset 确保引擎端交接的可重复性。
+- 核心主题：Blender 插件开发专家 Agent 个性化文档，专注于通过 Python 和 bpy API 构建 Blender 原生工具
+- 问题域：游戏开发、3D 美术管线中的重复性 Blender 工作流痛点
+- 方法/机制：利用 bpy API 构建自定义 Operators、Panels、Property Groups，实现资产验证、导出自动化、命名规范检查
+- 结论/价值：为技术美术和游戏开发团队提供生产级 Blender 自动化工具，将重复性资产准备工作转化为可靠的一键式工作流
 
 ## Key Claims（用中文描述）
-- 主体 + 机制 + 结果：Blender Add-on Engineer 偏好数据 API 访问（bpy.data/bpy.types）而非脆弱的上下文相关操作符（bpy.ops），使得 Operator 行为可预测且稳定。
-- 主体 + 机制 + 结果：验证工具必须在自动修复前报告问题，确保用户知情同意，避免破坏性意外修改。
-- 主体 + 机制 + 结果：批量工具必须精确记录其修改内容，使得 Pipeline 可审计且可回滚。
-- 主体 + 机制 + 结果：导出器必须保留源场景状态，除非用户明确选择破坏性清理，确保交接过程可重复验证。
+- Blender Add-on Engineer 优先使用 bpy.data 等数据 API 访问，而非依赖易碎的 bpy.ops 上下文操作
+- 验证工具必须在自动修复前报告问题，不允许静默"成功"
+- 批量工具必须精确记录所有变更，导出器除非用户明确选择否则不得破坏源场景状态
+- 工具每次迭代后资产准备工作时间应减少 50% 以上
 
 ## Key Quotes
-> "Every tool must save time or prevent a real class of handoff error." — 默认要求：每个工具必须有可量化的价值
-> "Operators must fail with actionable error messages — never silently 'succeed' while leaving the scene in an ambiguous state." — 操作符失败规范
-> "Never destructively rename, delete, apply transforms, or merge data without explicit user confirmation or a dry-run mode." — 非破坏性工作流核心原则
+> "Every tool must save time or prevent a real class of handoff error." — 工具交付的强制性价值标准
+
+> "Prefer data API access (`bpy.data`, `bpy.types`, direct property edits) over fragile context-dependent `bpy.ops` calls." — Blender API 最佳实践
+
+> "If the tool interrupts flow, the tool is wrong until proven otherwise." — 工具设计原则
 
 ## Key Concepts
-- [[bpy]]：Blender Python API，提供数据访问（bpy.data）和操作符执行（bpy.ops）两套接口；Add-on Engineer 偏好数据 API 以确保可靠性。
-- [[Asset-Validation]]：资产验证——在资产离开 Blender 前检查命名、变换、材质槽、集合放置等标准的自动化流程，是 Pipeline 可靠性的第一道防线。
-- [[Non-Destructive-Workflow]]：非破坏性工作流——不主动修改源数据，通过验证→报告→确认→执行四步确保用户知情同意，是 Blender Add-on Engineer 的核心设计原则。
-- [[Export-Presets]]：导出预设——可配置的引擎交接规则集（FBX/glTF/USD），确保导出设置在多次运行间保持可重复性。
-- [[Pipeline-Reliability]]：Pipeline 可靠性三角——命名确定性 + 变换分离检查 + 材质槽顺序验证 + 集合包含/排除显式规则，是 Add-on Engineer 交付的核心质量标准。
-- [[AddonPreferences]]：Blender Add-on 持久化设置机制，用于存储跨会话保留的工具配置（如默认导出路径、验证规则开关）。
-- [[PropertyGroups]]：Blender Python 属性组——结构化自定义属性的声明方式，支持 UI 绑定和序列化存储。
+- [[AssetValidation]]：资产验证 — 在资产导出前检查命名、变换、材质槽、集合放置等规范，防止交接错误
+- [[PipelineAutomation]]：管线自动化 — 通过自定义 Operators、Panels、Property Groups 将重复性 Blender 任务自动化
+- [[NamingConventions]]：命名规范 — 确定性且文档化的命名规则，用于检测 Blender 重复后缀、空格等命名漂移问题
+- [[NonDestructiveWorkflow]]：非破坏性工作流 — 不经用户确认不执行重命名、删除、应用变换或合并数据，支持 dry-run 模式
+- [[BpyAPI]]：Blender Python API — 通过 `bpy.data`、`bpy.types`、直接属性编辑与 Operator 调用构建 Blender 工具
+- [[CollectionBasedExport]]：基于集合的导出 — 通过显式的包含/排除规则进行集合级导出，避免隐藏场景启发式逻辑
 
 ## Key Entities
-- [[Blender]]：Blender Foundation 开发的开源 3D DCC 软件，通过 Python bpy API 支持插件扩展；本文档的核心目标平台。
-- [[BlenderAddonEngineer]]：The Agency Game Development 部门 Blender 专项专家 Agent，核心理念"Pipeline-first, artist-empathetic, automation-obsessed, reliability-minded"。
+- Blender：开源 3D 创作套件，Agent 的目标平台和 API 基础
+- glTF/FBX/USD：主流 3D 引擎交接格式，导出器支持的目标格式
+- Unity/Unreal：游戏引擎目标平台，Asset Validator 的下游消费者
 
 ## Connections
-- [[TechnicalArtist]] ← extends ← [[BlenderAddonEngineer]]：技术美术是 Blender Add-on Engineer 的上级角色，后者是 Blender 专项实现。
-- [[GameDesigner]] ← depends_on ← [[BlenderAddonEngineer]]：游戏设计师依赖资产验证和导出管线确保设计资产正确交接。
-- [[UnityArchitect]] ← parallel ← [[BlenderAddonEngineer]]：同为 DCC 工具开发专家，但 Unity Architect 专注 Unity Editor 扩展；两者共享 Editor 工具开发的通用原则（验证优先、持久化配置、非破坏性）。
-- [[UnrealSystemsEngineer]] ← parallel ← [[BlenderAddonEngineer]]：同为工具开发专家，Unreal Systems Engineer 专注 UE5 C++/Blueprint 扩展；两者共享"管道优先、验证先行"理念。
-- [[BlenderAddonEngineer]] ← provides ← [[Asset-Validation]] → feeds → [[GameDesigner]]：验证工具产出报告，供设计师决策修复方案。
+- [[GameDesigner]] ← belongs_to ← [[GameDevelopmentAgentTeam]]
+- [[TechnicalArtist]] ← related_to ← [[BlenderAddonEngineer]]
+- [[UnityArchitect]] ← adjacent_to ← [[BlenderAddonEngineer]]（3D 资产交接）
+- [[UnrealWorldBuilder]] ← adjacent_to ← [[BlenderAddonEngineer]]（3D 资产交接）
+- [[UnityShaderGraphArtist]] ← uses ← [[BlenderAddonEngineer]]（材质/着色器资产准备）
 
 ## Contradictions
-- 与 [[UnityArchitect]] 在"编辑器工具的数据修改时机"上存在设计哲学差异：
-  - 冲突点：Unity Architect 建议通过 ScriptableObject 实现编辑时-运行时状态分离，倾向于在编辑器扩展中直接修改资产；Blender Add-on Engineer 坚持非破坏性原则，验证后必须用户主动确认才执行修改。
-  - 当前观点：Blender 艺术家工作流强调"保留原始数据"——任何破坏性修改必须在 Dry-run 模式下预演，用户确认后才执行。
-  - 对方观点：Unity Editor 工具倾向于"所见即所得"——编辑器内修改即为正式修改，ScriptableObject 负责持久化状态。
-  - 协调建议：两者均强调"验证先行"——Blender Add-on Engineer 的非破坏性验证 + Unity Architect 的 SO 状态分离，本质上是从不同平台约束出发的等效安全实践。
+- 与 [[UnityEditorToolDeveloper]] 冲突：
+  - 冲突点：工具开发平台的定位差异
+  - 当前观点：Blender Add-on Engineer 专注于 Blender 原生工具（bpy API），不跨 DCC
+  - 对方观点：Unity Editor Tool Developer 在 Unity Editor 内部用 C# 构建工具
+  - 注：两者服务不同场景，无直接功能冲突，仅在"管线工具"概念上有领域重叠
diff --git a/wiki/sources/blockchain-security-auditor.md b/wiki/sources/blockchain-security-auditor.md
index fd003adc..739160f8 100644
--- a/wiki/sources/blockchain-security-auditor.md
+++ b/wiki/sources/blockchain-security-auditor.md
@@ -2,17 +2,17 @@
 title: "Blockchain Security Auditor"
 type: source
 tags: [blockchain, security, smart-contract, defi, audit]
-date: 2026-04-20
+date: 2026-05-30
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/specialized/blockchain-security-auditor.md]]
 
 ## Summary（用中文描述）
-- 核心主题：智能合约安全审计 Agent — 专职发现 DeFi 协议与区块链应用中的漏洞
-- 问题域：智能合约安全审计、漏洞检测、形式化验证、攻击向量分析、审计报告撰写
+- 核心主题：智能合约安全审计 Agent — 专职发现 DeFi 协议与区块链应用中的漏洞，在攻击者之前找到 bug
+- 问题域：智能合约安全审计、漏洞检测、形式化验证、攻击向量分析、审计报告撰写、事件响应
 - 方法/机制：自动化静态分析（Slither/Mythril/Echidna）+ 人工逐行代码审查 + 属性化模糊测试 + 经济博弈建模；五步工作流（范围→自动化→人工→经济分析→报告）
-- 结论/价值：提供包含可复现 PoC 的专业审计报告，Critical/High 漏洞零遗漏，确保修复建议可直接落地
+- 结论/价值：提供包含可复现 PoC 的专业审计报告，Critical/High 漏洞零遗漏，修复建议可直接落地，事后可提供事件响应
 
 ## Key Claims（用中文描述）
 - 自动化工具只能捕获约 30% 的真实漏洞，剩余必须依靠人工逐行审查
@@ -20,30 +20,40 @@ date: 2026-04-20
 - 漏洞评级为 Critical 的前提：无特殊权限即可直接造成用户资金损失或协议破产
 - 永远不要因为函数使用了 OpenZeppelin 库就假定它是安全的 — 误用安全库本身就是一类漏洞
 - 审计范围必须覆盖完整调用链，不仅仅是当前函数 — 漏洞隐藏在内部调用和继承合约中
+- 永远验证审计代码与部署字节码是否匹配 — 供应链攻击是真实威胁
+- OpenZeppelin 安全库的误用是一类独立漏洞 — 即使库本身安全，集成方式可能引入风险
+- Solidity 0.8+ 的 `unchecked` 块仍需审查 — 默认安全不代表绝对安全
+- 漏洞分类 C-01/H-01 必须在部署前修复，Medium 可随监控计划上线，Low 归入下一版本
+- 漏洞发现误报率必须控制在 10% 以下 — 所有发现必须是真实漏洞，不是凑数
 
 ## Key Quotes
 > "Your job is not to make developers feel good — it is to find the bug before the attacker does." — Blockchain Security Auditor 角色定义
 > "Automated tools catch maybe 30% of real bugs." — 为什么不能跳过人工审查
 > "Never assume a function is safe because it uses OpenZeppelin — misuse of safe libraries is a vulnerability class of its own." — 核心审计原则
 > "If it can lose user funds, it is High or Critical — never mark a finding as informational to avoid confrontation." — 漏洞评级原则
+> "Zero Critical or High findings are missed that a subsequent auditor discovers." — 成功指标
 
 ## Key Concepts
-- [[Reentrancy（重入攻击）]]：外部调用在状态更新前执行，允许攻击者在状态清零前回滚调用链重复提取资金
-- [[Oracle Manipulation（预言机操纵）]]：通过闪电贷在单笔交易内操纵 AMM 储备或价格预言机，导致清算/借贷套利
-- [[Flash Loan Attack（闪电贷攻击）]]：在单笔交易内借用大量资金操纵市场状态，无需抵押的信贷攻击
-- [[Access Control（访问控制）]]：特权函数缺少访问修饰符或被错误配置，可导致权限提升
-- [[Formal Verification（形式化验证）]]：使用符号执行和不变式验证数学证明协议关键属性的正确性
-- [[Checks-Effects-Interactions Pattern]]：先检查条件、更新状态，再执行外部调用，防止逻辑漏洞
-- [[Slither]]：Trail of Bits 开源的 Solidity 静态分析框架，高置信度检测器几乎总是真实漏洞
-- [[Mythril]]：基于符号执行的安全分析工具，深度扫描但速度较慢
-- [[Echidna]]：属性化模糊测试工具，通过随机交易验证协议不变式
-- [[Foundry]] / [[Certora]] / [[Halmos]]：高级形式化验证工具链，用于数学证明合约正确性
-- [[SWC Registry]]：智能合约弱点分类标准（Smart Contract Weakness Classification）
-- [[DeFiHackLabs]] / [[rekt.news]]：DeFi 攻击事件数据库，用于模式匹配已知漏洞
+- [[Reentrancy（重入攻击）]]：外部调用在状态更新前执行，允许攻击者在状态清零前回滚调用链重复提取资金；典型模式：外部 call() 在 balances[msg.sender]=0 之前调用；防御：Checks-Effects-Interactions 模式 + ReentrancyGuard
+- [[Oracle Manipulation（预言机操纵）]]：通过闪电贷在单笔交易内操纵 AMM 储备或价格预言机，导致清算/借贷套利；Uniswap V2 现货价格可被操纵，V3 TWAP 和 Chainlink 提供更好保障
+- [[Flash Loan Attack（闪电贷攻击）]]：在单笔交易内借用大量资金操纵市场状态，无需抵押的信贷攻击；是 Oracle Manipulation 和经济博弈攻击的主要载体
+- [[Access Control（访问控制）]]：特权函数缺少访问修饰符或被错误配置，可导致权限提升；关键检查项：initialize() 一次性调用保护、代理合约 `_disableInitializers()`、多签 vs EOA 风险
+- [[Formal Verification（形式化验证）]]：使用符号执行和不变式验证数学证明协议关键属性的正确性；Certora/Halmos/KEVM 用于数学证明合约正确性
+- [[Checks-Effects-Interactions Pattern]]：先检查条件、更新状态，再执行外部调用，防止逻辑漏洞；修复重入的标准模式
+- [[Slither]]：Trail of Bits 开源的 Solidity 静态分析框架，高置信度检测器几乎总是真实漏洞；关键检测器：reentrancy-eth/arbitrary-send-eth/suicidal/controlled-delegatecall/uninitialized-state
+- [[Mythril]]：基于符号执行的安全分析工具，深度扫描但速度较慢；适合关键合约的深度分析
+- [[Echidna]]：属性化模糊测试工具，通过随机交易验证协议不变式；配合 Foundry 进行属性化 fuzz 测试
+- [[Storage Collision（存储冲突）]]：升级型代理合约中存储槽对齐错误，可被攻击者劫持状态变量
+- [[Signature Malleability（签名重放攻击）]]：permit 和元交易系统中签名可被修改后重放攻击
+- [[Cross-Chain Message Replay（跨链消息重放）]]：桥接协议消息跨链验证绕过，同一消息可在多条链上重放
+- [[SWC Registry]]：智能合约弱点分类标准（Smart Contract Weakness Classification），提供标准化的漏洞编号和描述
+- [[DeFiHackLabs]] / [[rekt.news]]：DeFi 攻击事件数据库，用于模式匹配已知漏洞；每个新攻击都是未来漏洞的模板
 
 ## Key Entities
-- [[Trail of Bits]]：安全审计机构，开发 Slither、Solc 等关键安全工具
-- [[OpenZeppelin]]：智能合约标准库（ReentrancyGuard、AccessControl 等），被广泛依赖
+- [[Trail of Bits]]：安全审计机构，开发 Slither、Solc 等关键安全工具；审计报告档案是重要参考资源
+- [[OpenZeppelin]]：智能合约标准库（ReentrancyGuard、AccessControl 等），被广泛依赖；误用是独立漏洞类别
+- [[Certora]]：形式化验证工具，用于数学证明 Solidity 合约属性
+- [[Halmos]]：字节码级别的形式化验证工具，基于符号执行
 - [[The DAO (2016)]]：以太坊首个重大安全事件，重入攻击导致 360 万 ETH 损失，开创了 DeFi 安全研究领域
 - [[Euler Finance]]：2023 年遭受 donate-to-reserves 操纵攻击，损失 1.97 亿美元，攻击模板被收录
 - [[Nomad Bridge]]：2022 年因未初始化代理合约漏洞损失 1.9 亿美元
@@ -52,8 +62,11 @@ date: 2026-04-20
 ## Connections
 - [[Agents Orchestrator]] ← defines role scope ← [[Blockchain Security Auditor]]
 - [[Compliance Auditor]] ← related audit methodology ← [[Blockchain Security Auditor]]
-- [[Blockchain Security Auditor]] ← uses tools ← [[Slither]] / [[Mythril]] / [[Echidna]]
+- [[Blockchain Security Auditor]] ← uses tools ← [[Slither]] / [[Mythril]] / [[Echidna]] / [[Certora]] / [[Halmos]]
 - [[Blockchain Security Auditor]] ← draws patterns from ← [[The DAO (2016)]] / [[Euler Finance]] / [[Nomad Bridge]] / [[Curve Finance]]
+- [[Blockchain Security Auditor]] ← methodologies ← [[Formal Verification]] / [[Access Control]] / [[Oracle Manipulation]]
+- [[Blockchain Security Auditor]] ← references ← [[SWC Registry]] / [[DeFiHackLabs]] / [[rekt.news]]
 
 ## Contradictions
-- （无已知冲突 — 该页面为独立角色定义文档，未与其他 Wiki 页面产生直接矛盾）
+- 与 [[Compliance Auditor]] 的关注点差异：Blockchain Security Auditor 聚焦代码层安全漏洞和资金损失风险，Compliance Auditor 聚焦合规框架（SOC 2/ISO 27001）控制措施，两者方法论互补而非矛盾
+- 漏洞评级与用户沟通的张力：文档强调"永远不要把能损失资金的漏洞标记为 informational"，但同时要求"为开发者和利益相关者分别写报告"——前者保证安全底线，后者照顾沟通需求，通过分层报告结构解决
diff --git a/wiki/sources/claude-code-integration.md b/wiki/sources/claude-code-integration.md
index 854a5bc9..07659fa3 100644
--- a/wiki/sources/claude-code-integration.md
+++ b/wiki/sources/claude-code-integration.md
@@ -1,39 +1,39 @@
----
-title: "Claude Code Integration"
-type: source
-tags: []
-date: 2026-05-02
----
-
-## Source File
-- [[Agent/agency-agents/integrations/claude-code/README.md]]
-
-## Summary（用中文描述）
-- 核心主题：The Agency Agent 资产与 Claude Code 的原生集成方案
-- 问题域：如何在 Claude Code 会话中激活和使用预设的 Agent 角色
-- 方法/机制：通过 `install.sh` 脚本或手动复制，将 Agent 定义文件部署到 Claude Code 的 agents 目录，Claude Code 通过名称引用激活 Agent
-- 结论/价值：The Agency 从一开始就为 Claude Code 构建，无需任何格式转换，Agent 天然使用 `.md` + YAML frontmatter 格式，与 Claude Code 完全兼容
-
-## Key Claims（用中文描述）
-- The Agency 为 Claude Code 原生构建，无需格式转换
-- Agent 以 `.md` + YAML frontmatter 格式存储，与 Claude Code agent 格式完全一致
-- Agent 按部门（division）组织成目录结构，可选择性安装
-- 在 Claude Code 会话中通过名称引用即可激活对应 Agent
-
-## Key Quotes
-> "The Agency was built for Claude Code. No conversion needed — agents work natively with the existing `.md` + YAML frontmatter format." — 核心设计理念，阐明 The Agency 与 Claude Code 的原生兼容性
-
-## Key Concepts
-- [[Agent-Activation-Pattern]]：在 Claude Code 和 Windsurf 中通过名称引用激活预设 Agent 角色的机制
-
-## Key Entities
-- [[Claude-Code]]：Anthropic 官方 AI 编程 CLI 工具，本集成的目标平台
-- [[The-Agency]]：多智能体编码系统，包含各类专业角色 Agent 的资产库
-
-## Connections
-- [[integrations-readme]] ← overview ← [[claude-code-integration]]
-- [[claude-code-integration]] ← extends ← [[The-Agency]]
-- [[agents-orchestrator]] ← category_parent ← [[claude-code-integration]]
-
-## Contradictions
-- 无已知内容冲突
+---
+title: "Claude Code Integration"
+type: source
+tags: []
+date: 2026-04-30
+---
+
+## Source File
+- [[Agent/agency-agents/integrations/claude-code/README.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency 项目如何与 Claude Code 集成使用
+- 问题域：Agent 的安装、激活与管理
+- 方法/机制：通过 install.sh 脚本或手动复制 md 文件到 `~/.claude/agents/`，在 Claude Code 会话中通过名称引用激活 Agent
+- 结论/价值：The Agency 无需转换即可原生支持 Claude Code，Agent 使用 `.md` + YAML frontmatter 格式
+
+## Key Claims（用中文描述）
+- The Agency 原生支持 Claude Code，无需格式转换
+- Agent 使用 `.md` + YAML frontmatter 格式即可工作
+- 支持批量安装和按分类手动安装两种方式
+- Agent 通过名称引用即可在 Claude Code 会话中激活
+
+## Key Quotes
+> "The Agency was built for Claude Code. No conversion needed — agents work natively with the existing `.md` + YAML frontmatter format." — 核心设计理念
+
+## Key Concepts
+- [[Claude Code]]：Anthropic 的 CLI 编程代理工具，支持通过名称激活预定义 Agent
+- [[The Agency]]：一个开源 Agent 集合项目，提供多领域专业 Agent
+- [[Agent Activation]]：在 Claude Code 会话中通过名称引用激活 Agent 的机制
+
+## Key Entities
+- [[Agency Agents]]：The Agency 项目中的具体 Agent 实现，分布在不同 divisions
+
+## Connections
+- [[The Agency]] ← provides agents for ← [[Claude Code Integration]]
+- [[readme]] ← overview of ← [[Claude Code Integration]]
+
+## Contradictions
+- （无已知冲突）
diff --git a/wiki/sources/compliance-auditor.md b/wiki/sources/compliance-auditor.md
index 7235280e..ee6ad1af 100644
--- a/wiki/sources/compliance-auditor.md
+++ b/wiki/sources/compliance-auditor.md
@@ -2,59 +2,44 @@
 title: "Compliance Auditor Agent"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-04-30
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/specialized/compliance-auditor.md]]
 
 ## Summary（用中文描述）
-- 核心主题：专业 AI Agent，专注于 SOC 2、ISO 27001、HIPAA、PCI-DSS 等安全隐私认证审计的全流程指导——从准备评估到证据收集直至认证通过。
-- 问题域：组织如何系统性地通过合规认证，避免"打勾式合规"（checkbox compliance），确保控制措施真正落地而非仅存在于文档中。
-- 方法/机制：五步工作流（Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance）；强调自动化证据收集、右置控制项设计、以审计员视角反向思考。
-- 结论/价值：合规项目应与公司规模和实际风险匹配；技术控制优于管理控制；证据必须证明控制在整个审计周期内持续有效，而非仅存在于当下。
+- 核心主题：AI Agent 角色定义——技术合规审计员，指导组织完成 SOC 2、ISO 27001、HIPAA、PCIDSS 等安全与隐私认证流程
+- 问题域：安全合规认证准备、差距评估、控制实施、审计执行、持续合规
+- 方法/机制：通过五步工作流（范围界定→差距评估→修复支持→审计支持→持续合规），结合结构化交付物（差距评估报告、证据收集矩阵、政策模板）
+- 结论/价值：为组织提供从零到认证的系统化指导，强调实质重于形式、自动化证据收集、按风险适配控制复杂度
 
 ## Key Claims（用中文描述）
-- 不被遵守的政策比没有政策更危险——它制造虚假信心，增加审计风险。
-- 自动化证据收集从第一天就应建立——手动流程无法扩展。
-- 使用通用控制框架（common control framework）可一个控制集满足多个认证标准。
-- 技术控制优于管理控制——代码比培训更可靠。
-- 审计边界（scope）必须清晰定义，明确包含和排除的范围。
-- 例外情况（exceptions）需要完整文档：谁批准、为什么、有何时效、有何补偿控制。
+- 没人遵守的政策比没有政策更危险——制造虚假信心，增加审计风险
+- 自动化证据收集必须从第一天就建立——手动流程无法扩展
+- 使用通用控制框架（一套控制满足多项认证）可消除重复工作
+- 异常必须记录在案：谁批准、为什么、何时到期、有什么补偿控制
+- 控制必须被测试，不能仅存在于文档中
+- 审计边界必须明确界定——清楚定义审计范围的内含与外延
 
 ## Key Quotes
-> "A policy nobody follows is worse than no policy — it creates false confidence and audit risk."
-> — 核心原则：不follow的政策比没政策更危险
-
-> "Evidence must prove the control operated effectively over the audit period, not just that it exists today."
-> — 证据的核心要求：证明整个审计周期内持续有效
-
-> "Think like the auditor: what would you test? what evidence would you request?"
-> — 审计员心态：反向思考，模拟审计师会问什么
+> "A policy nobody follows is worse than no policy — it creates false confidence and audit risk." — 实质性合规的核心原则
+> "Automate evidence collection from day one — it scales, manual processes don't." — 自动化优先原则
+> "Think like the auditor: what would you test? what evidence would you request?" — 审计师思维
+> "Technical controls over administrative controls where possible — code is more reliable than training." — 技术控制优于管理控制
 
 ## Key Concepts
-- [[Checkbox-Compliance]]：仅在文档层面满足合规要求，控制实际未落地或未被测试——文档中的反面案例。
-- [[Continuous-Compliance]]：持续合规——在两次年度审计之间建立自动化证据收集管道和季度控制测试机制，而非年度突击准备。
-- [[Common-Control-Framework]]：通用控制框架——设计一组控制项同时满足多个认证标准（如 SOC 2 + ISO 27001），避免重复工作。
-- [[Technical-Controls-Vs-Administrative-Controls]]：技术控制（如 IAM 策略、代码审计）优于管理控制（如培训、签到表），因为代码比人的行为更可靠。
-- [[Compensating-Control]]：补偿控制——当某项控制无法直接满足时，用于降低风险的替代措施；需完整记录批准人、原因和有效期。
-- [[Evidence-Collection-Matrix]]：证据收集矩阵——以控制目标（而非内部团队结构）组织证据的结构化文档，列出控制ID、证据类型、来源、收集方式和频率。
+- [[SOC2]]：信任服务标准认证，Compliance Auditor 重点覆盖的安全与隐私框架之一
+- [[GapAssessment]]：差距评估——对照目标框架要求评估当前安全态势，输出带优先级修复计划
+- [[EvidenceCollection]]：证据收集——自动化优先，手动证据脆弱；按控制目标组织，而非按内部团队结构
 
 ## Key Entities
-- [[SOC-2]]：安全、可用性、处理完整性、机密性、隐私五大信任服务标准（Trust Service Criteria），最常见的云服务安全认证。
-- [[ISO-27001]]：国际信息安全管理标准，提供系统化的风险管理方法。
-- [[HIPAA]]：美国医疗信息隐私法规，涵盖 PHI（受保护健康信息）的保护要求。
-- [[PCI-DSS]]：支付卡行业数据安全标准，适用于处理信用卡信息的组织。
+- ComplianceAuditor：AI Agent 身份，技术合规审计员，个性严谨、系统、务实，对风险过敏，对"打勾式合规"过敏
 
 ## Connections
-- [[specialized-model-qa]] ← extends ← [[compliance-auditor]]：Model QA 关注 ML 模型质量，Compliance Auditor 关注整体安全控制——两者在模型部署合规证据收集上存在交叉。
-- [[automation-governance-architect]] ← depends_on ← [[compliance-auditor]]：合规审计所需的自动化证据收集需依托 Governance Architect 设计的 AI 系统治理框架。
-- [[CTP-Topic-52-3-Lines-of-Defence]] ← extends ← [[compliance-auditor]]：三道防线模型（业务管理 / 风险职能 / 内部审计）与合规审计的职责划分高度对应。
-- [[DevSecOps]] ← extends ← [[compliance-auditor]]：DevSecOps 将安全控制集成到 CI/CD 流水线中，是合规 Auditor 推荐的技术控制实现方式。
+- [[SOC2]] ← 应用框架 ← [[ComplianceAuditor]]
+- [[GapAssessment]] ← 核心交付物 ← [[ComplianceAuditor]]
+- [[EvidenceCollection]] ← 核心交付物 ← [[ComplianceAuditor]]
 
 ## Contradictions
-- 与 [[specialized-model-qa]] 的侧重点差异：
-  - 冲突点：Compliance Auditor 关注组织级控制（access control, incident response），Model QA 关注模型本身的质量与统计特性，两者对"证据"的定义不同。
-  - 当前观点：合规证据以控制操作日志、策略文档、访问审查记录为主。
-  - 对方观点：模型证据以 PSI、校准曲线、SHAP 值等统计指标为主。
-  - 协调建议：两者可互补——Compliance Auditor 负责整体安全框架，Model QA 负责嵌入其中的 AI/ML 模型专项审计。
+- 无已知冲突页面
diff --git a/wiki/sources/contributing.md b/wiki/sources/contributing.md
index 55ef2c95..df5f8bf5 100644
--- a/wiki/sources/contributing.md
+++ b/wiki/sources/contributing.md
@@ -1,47 +1,47 @@
 ---
 title: "Contributing to The Agency"
 type: source
-tags: [multi-agent, openclaw, contribution, the-agency]
-date: 2026-04-21
+tags: []
+sources: []
+last_updated: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/CONTRIBUTING.md]]
+- [[Agent/agency-agents/CONTRIBUTING.md]]
 
 ## Summary（用中文描述）
-- 核心主题：The Agency（agency-agents）多智能体框架的贡献者指南英文原版
-- 问题域：如何规范地向 The Agency 项目贡献高质量 AI 智能体，以及社区协作标准
-- 方法/机制：通过智能体设计模板、五大设计原则、PR 流程规范和代码风格指南确保贡献质量
-- 结论/价值：为 OpenClaw 多智能体生态提供标准化的智能体创建框架和质量门槛
+- 核心主题：The Agency 开源 AI Agent 项目的贡献指南，定义如何创建、改进和提交新的 Agent
+- 问题域：开源社区协作、AI Agent 开发规范、贡献流程标准化
+- 方法/机制：通过结构化的 Agent 文件模板、设计原则、PR 流程和样式指南来规范贡献行为
+- 结论/价值：降低了贡献门槛，明确了"好 Agent"的标准，使社区能够持续产出高质量的 AI Agent
 
 ## Key Claims（用中文描述）
-- The Agency 通过**五大设计原则**确保智能体质量：鲜明性格、明确交付物、可量化指标、经过验证的工作流、学习记忆
-- PR 最佳实践：**单文件优先**（一个 `.md` 就是一个 PR），复杂变更（工具链/架构）需先开 Discussion 对齐
-- 外部服务依赖须在 frontmatter 的 `services` 字段声明，且智能体应**脱离 API 后仍有独立价值**
-- 提交前必须完成：真实场景测试、遵循模板、至少 2-3 个代码/模板示例、可量化成功指标
+- 贡献一个 Agent 的最简路径是一个 Markdown 文件（新 Agent 或改进现有 Agent）
+- 优秀的 Agent 必须具备：窄而深的专长、鲜明的个性声音、具体的代码/模板示例、可量化的成功指标、逐步验证的工作流
+- Agent 文件采用双语义分组（Persona + Operations），以支持 OpenClaw 格式自动转换
+- 外部服务依赖应在 frontmatter 中声明，但 Agent 本身必须独立成立
+- 批量修改现有 Agent 必须先开 Discussion 讨论
 
 ## Key Quotes
-> "The fastest path to a merged PR is **one markdown file** — a new or improved agent. That's the sweet spot." — PR 流程说明
-> "An agent that solves the user's problem using a service belongs here. A service's quickstart guide wearing an agent costume does not." — 外部服务评判标准
+> "The fastest path to a merged PR is **one markdown file** — a new or improved agent." — 强调最小化 PR 的核心理念
+> "Great agents have: ✅ Narrow, deep specialization / ✅ Distinct personality and voice / ✅ Concrete code/template examples / ✅ Measurable success metrics / ✅ Step-by-step workflows / ✅ Real-world testing and iteration" — 好 Agent 的六项标准
 
 ## Key Concepts
-- [[Agent-Design-Principles]]：五大设计原则——鲜明性格/明确交付物/可量化指标/验证工作流/学习记忆
-- [[Agent-Template]]：YAML frontmatter + 结构化文档模板规范
-- [[Multi-Agent-Team]]：The Agency 框架下多智能体协作模式
-- [[Multi-Agent-System-Reliability]]：多智能体系统可靠性架构模式
+- [[AgentDesignPrinciples]]：Agent 设计五原则——强个性、清晰交付物、成功指标、经过验证的工作流、学习与记忆
+- [[PersonaVsOperations]]：Agent 文件的 Persona（身份/沟通/规则）与 Operations（使命/交付物/流程/指标）双分组结构
+- [[ExternalServicesDeclaration]]：Agent 可声明外部服务依赖，但必须独立于服务存在，测试标准是"去掉 API 调用后 Agent 仍有价值"
+- [[OpenClawFormat]]：OpenClaw 工作区格式，支持通过 convert.sh 自动将 Agent 文件转换为工具特定格式
 
 ## Key Entities
-- [[The Agency]]：msitarzewski 主导的多智能体开源项目（147 个专业化智能体，覆盖 12 个业务领域）
-- [[OpenClaw]]：The Agency 智能体运行的基础平台
-- [[msitarzewski]]（mar.mod）：The Agency 项目维护者
+- [[TheAgency]]：The Agency 是一个开源 AI Agent 集合项目，托管于 GitHub (msitarzewski/agency-agents)
+- [[MarekSitarzewski]]：The Agency 项目作者（GitHub: msitarzewski）
+- [[OpenClaw]]：Agent 工作区格式规范，定义了 Agent 文件的结构和 convert.sh 转换脚本
 
 ## Connections
-- [[contributing_zh-cn]] ← 同一文档的中文翻译版本，包含中文社区协作规范
-- [[Agent-Design-Principles]] ← 来源一致，均引用本文档定义五大设计原则
-- [[Agent-Template]] ← 来源一致，均引用本文档定义智能体文件结构
-- [[multi-agent-system-reliability]] ← 智能体设计规范层补充运行时可靠性模式
-- [[multi-agent-team]] ← The Agency 框架的多智能体协作模式
+- [[TheAgency]] ← authored_by ← [[MarekSitarzewski]]
+- [[AgentDesignPrinciples]] ← implements ← [[PersonaVsOperations]]
+- [[ExternalServicesDeclaration]] ← part_of ← [[AgentDesignPrinciples]]
+- [[OpenClaw]] ← converts ← [[AgentDesignPrinciples]]
 
 ## Contradictions
-- 无与其他 Wiki 页面的实质性内容冲突
-- 与 [[contributing_zh-cn]] 的差异：英文原版包含 Code of Conduct（行为准则）和 Recognition（贡献者认可机制）章节，中文翻译版侧重核心贡献流程和设计规范
+- 与 [[contributing_zh-cn]] 无冲突（中文版为本文档的翻译）
diff --git a/wiki/sources/contributing_zh-cn.md b/wiki/sources/contributing_zh-cn.md
index d8037eb9..24d8299f 100644
--- a/wiki/sources/contributing_zh-cn.md
+++ b/wiki/sources/contributing_zh-cn.md
@@ -2,43 +2,45 @@
 title: "为 The Agency 贡献代码"
 type: source
 tags: []
-date: 2026-04-24
+date: 2026-04-27
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/CONTRIBUTING_zh-CN.md]]
+- [[Agent/agency-agents/CONTRIBUTING_zh-CN.md]]
 
 ## Summary（用中文描述）
-- 核心主题：**The Agency**（agency-agents）项目的贡献者指南，定义智能体（Agent）设计规范、贡献流程和社区标准
-- 问题域：AI 智能体系统的标准化设计、社区协作与质量保障
-- 方法/机制：YAML frontmatter 元数据 + 分层结构化文档模板；通过 Pull Request 流程和 PR 模板实现质量把控；通过智能体设计原则（性格塑造、交付物定义、指标量化）确保智能体质量
-- 结论/价值：提供可操作的智能体设计框架，降低社区贡献门槛，同时通过规范保证生态一致性
+- 核心主题：The Agency 智能体（Agent）项目的开源贡献指南——涵盖行为准则、贡献方式、智能体设计规范、PR 提交流程和风格指南
+- 问题域：如何为 AI 智能体集合项目贡献新的或改进的专家智能体，包括设计原则、结构模板、质量标准
+- 方法/机制：通过 YAML frontmatter 定义智能体元数据，通过分章节结构（身份/使命/规则/交付物/工作流/学习/指标）规范智能体设计，通过 PR 模板确保贡献质量
+- 结论/价值：提供了一套完整的智能体贡献生态——从创意生成到真实场景测试再到社区评审，标准化了 AI 专家智能体的创建流程
 
 ## Key Claims（用中文描述）
-- 优秀智能体必须具备鲜明性格，拒绝"通用型有用助手"人设
-- 智能体应提供可量化的成功指标，而非模糊描述
-- 每个智能体必须经过真实场景测试和迭代优化
-- 贡献者通过 PR 流程和社区评审确保智能体质量
+- 贡献智能体需满足：鲜明性格 + 明确交付物 + 可量化成功指标 + 分步工作流 + 真实场景测试
+- 避免通用型"有用助手"人设，智能体应专精、独特、可落地
+- PR 提交前必须在真实场景中测试，并包含 2-3 个代码/模板示例
+- 智能体需定义具体、可量化的成功指标，而非模糊描述
 
 ## Key Quotes
-> "赋予智能体独特语气与人设，避免'我是一个有用的助手'，要具体、让人印象深刻" — 智能体性格设计原则
+> "赋予智能体独特语气与人设，避免'我是一个有用的助手'，要具体、让人印象深刻" — 智能体性格塑造原则
 > "提供可落地的代码示例，包含模板与框架，展示真实输出，而非模糊描述" — 交付物标准
-> "包含具体、可量化的指标" — 成功指标要求
+> "包含具体、可量化的指标，例如'3G 网络下页面加载时间低于 3 秒'" — 成功指标定义
+> "分步流程清晰，经过真实场景验证，拒绝纯理论、纸上谈兵" — 工作流要求
 
 ## Key Concepts
-- [[Agent-Design-Principles]]：The Agency 智能体设计五原则（鲜明性格、明确交付物、成功指标、经过验证的工作流、学习记忆）
-- [[Agent-Template]]：YAML frontmatter + 分层结构（身份/使命/规则/交付物/工作流/沟通/学习/指标）
-- [[Pull-Request-Template]]：标准化 PR 提交模板，包含智能体信息、创作动机、测试情况、检查清单
+- [[Agent-Design-Patterns]]：智能体设计应遵循的五大原则——鲜明性格、明确交付物、成功指标、经过验证的工作流、学习记忆机制
+- [[YAML-Configuration]]：每个智能体文件以 YAML frontmatter 定义 name/description/color 元数据
+- [[Pull-Request-Workflow]]：Fork → 分支 → 开发 → 测试 → PR → 社区评审 → 合并的完整贡献流程
+- [[Markdown-Documentation]]：使用 Markdown 统一格式，表情符号导航，代码块语法高亮，表格对比选项
+- [[Multi-Agent-System]]：The Agency 智能体集合涵盖 engineering/design/marketing/product 等多领域专业分工
 
 ## Key Entities
-- [[The-Agency]]（agency-agents 项目）：包含 147 个专业智能体，覆盖 12 个业务领域
-- [[Agency-Engineering-Agent]]：前端开发者智能体示例，结构规范参考
-- [[Agency-Marketing-reddit-Community-Builder]]：Reddit 社区运营者示例，性格塑造优秀参考
+- [[The-Agency]]：AI 智能体开源项目，汇集多领域专家智能体，支持 9 大分类贡献
+- [[SRE]]：Site Reliability Engineering，贡献分类之一，对应 testing/ 分类专家
 
 ## Connections
-- [[Multi-Agent-System-Reliability]] ← extends ← [[Agent-Design-Principles]]
-- [[OpenClaw]] ← related_to ← [[The-Agency]]
-- [[Multi-Agent-Team]] ← related_to ← [[Agent-Orchestration]]
+- [[Agentic-Identity-And-Trust]] ← extends ← [[The-Agency]]（The Agency 提供智能体贡献框架，Agentic Identity & Trust 定义身份与信任机制）
+- [[Agents-Orchestrator]] ← depends_on ← [[Multi-Agent-System]]（编排依赖多智能体系统的存在）
+- [[Multi-Agent-System-Reliability]] ← extends ← [[Multi-Agent-System]]（可靠性研究扩展多智能体系统）
 
 ## Contradictions
-- 无已知冲突内容
+- 无冲突：本指南为贡献流程文档，不与其他来源产生直接矛盾
diff --git a/wiki/sources/corporate-training-designer.md b/wiki/sources/corporate-training-designer.md
index 79747975..356335df 100644
--- a/wiki/sources/corporate-training-designer.md
+++ b/wiki/sources/corporate-training-designer.md
@@ -2,48 +2,59 @@
 title: "Corporate Training Designer"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-05-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/corporate-training-designer.md]]
+- [[Agent/agency-agents/specialized/corporate-training-designer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：企业培训体系架构师与课程开发专家（Corporate Training Designer）—— 专注企业级培训需求分析、ADDIE/SAM 教学设计模型、混合学习项目设计、内训师培养、领导力发展项目，以及 Kirkpatrick 四级培训效果评估体系。
-- 问题域：企业培训中"为培训而培训"的现象普遍存在——培训目标不可衡量、课程内容脱离业务场景、学习效果无法落地到行为改变。
-- 方法/机制：从业务问题出发，以能力差距分析为基础，采用 ADDIE/SAM 模型设计课程体系，通过 OMO 混合学习、Kolb 体验式学习、翻转课堂等方法交付，并通过 Kirkpatrick 四级评估验证业务价值。
-- 结论/价值：优秀培训的衡量标准不是"教了什么"，而是"学员回去做了什么"——数据驱动的培训体系能真正提升员工能力与组织绩效。
+- 核心主题：企业培训系统架构师与课程开发专家，专注于从需求诊断到 Kirkpatrick Level 4 效果评估的全链路培训设计
+- 问题域：企业如何设计真正驱动业务结果的培训项目，而非"为培训而培训"；培训需求如何与业务指标挂钩；如何将专家隐性经验萃取为可传授的显性知识
+- 方法/机制：ADDIE 模型（分析→设计→开发→实施→评估）、SAM 迭代设计、Bloom 认知分类、柯尔布体验学习圈、Kirkpatrick 四级评估模型、ADDIE + SAM 混合、翻转课堂、OMO 混合学习、游戏化机制
+- 结论/价值：好的培训测量的是"学员回去做了什么"，而非"讲师讲了什么"；培训目标必须可量化；高投资培训项目必须追踪到 Kirkpatrick Level 3（行为改变）
 
 ## Key Claims（用中文描述）
-- 培训设计必须从业务问题出发，而非从"我们有什么课"出发；培训目标必须可衡量，而非"提高沟通能力"这类模糊表述。
-- 所有案例必须改编自真实业务场景，拒绝脱离实际的"教材式案例"；课程内容须每年至少更新一次。
-- 每项培训项目必须有评估计划——高投资（领导力、关键岗位）必须追踪到 Kirkpatrick Level 3（行为改变）。
-- 合规培训须覆盖全体员工，记录完整，360 度反馈结果仅限本人及直属上级知晓。
+- 培训设计必须从业务问题出发，而非从"我们有什么课"出发；如果根因不是能力差距（而是流程、政策或激励问题），应直接指出而非强行培训
+- 成人学习必须有即时实用价值，每个学习活动必须回答"我现在能用在哪里"；控制单次认知负荷（线下培训每90分钟安排互动或休息，线上微课控制在15分钟以内）
+- 培训目标必须可量化：不是"提高沟通技能"，而是"3个月内将新员工独立完成客户提案的比例从40%提升至70%"
+- 每次培训都必须有评估计划，至少达到 Kirkpatrick Level 2（学习），高投资培训（领导力、关键岗位）必须追踪到 Level 3（行为改变）
 
 ## Key Quotes
-> "Good training isn't about 'what was taught' — it's about 'what learners do differently when they go back to work.'" — 培训设计的核心价值观
-> "Training objectives must be measurable — not 'improve communication skills,' but 'increase the percentage of new hires independently completing client proposals within 3 months from 40% to 70%.'" — 培训目标的 SMART 原则
-> "For this leadership program, I recommend replacing pure classroom lectures with 'business challenge projects.' Learners form groups, take on a real business problem, learn while doing, and present results to the CEO after 3 months." — 成人学习理论的应用
-> "Data from the last sales new hire boot camp: trainees had a 23% higher first-month deal close rate than non-trainees, with an average of 18,000 yuan more in per-capita output." — 培训 ROI 的量化证明
+> "Good training isn't about 'what was taught' — it's about 'what learners do differently when they go back to work'" — 核心价值观
+> "For this leadership program, I recommend replacing pure classroom lectures with 'business challenge projects.' Learners form groups, take on a real business problem, learn while doing, and present results to the CEO after 3 months." — 翻转课堂的实践示例
+> "Data from the last sales new hire boot camp: trainees had a 23% higher first-month deal close rate than non-trainees, with an average of 18,000 yuan more in per-capita output." — 培训 ROI 数据说话
 
 ## Key Concepts
-- [[ADDIE 模型]]：Analysis（分析）→ Design（设计）→ Development（开发）→ Implementation（实施）→ Evaluation（评估），每个阶段有明确交付物，是教学设计的基础框架。
-- [[SAM 模型]]（Successive Approximation Model）：适合快速迭代场景，通过"原型 → 评审 → 修订"循环缩短上线时间。
-- [[Kirkpatrick 四级评估]]：Level 1 反应（满意度）、Level 2 学习（知识技能掌握）、Level 3 行为（行为改变）、Level 4 结果（业务指标变化）。
-- [[Bloom 认知分类]]：从记忆→理解→应用→分析→评价→创造，逐级提升学习目标设计深度。
-- [[Kolb 体验式学习圈]]：具体经验 → 反思观察 → 抽象概念化 → 主动实验，闭环驱动学习转化。
-- [[OMO 混合学习]]（Online-Merge-Offline）：线上解决"认知"、线下解决"实践"、学习社群解决"持续"。
-- [[TTT]]（Train the Trainer）：内训师培养体系——成人学习原则、课程开发技巧、表达与呈现技能、课堂管理与互动技巧、课件设计标准。
-- [[HIPO]]（High-Potential Talent Program）：高潜人才培养项目，通过 IDP（个人发展计划）、轮岗、导师辅导、挑战性任务加速人才成长。
-- [[ADDIE 模型]]：微课（5-15 分钟）、案例教学、沙盘模拟、剧本杀式沉浸体验培训等多元内容形式。
+- [[ADDIE-Model]]：分析（Analysis）→设计（Design）→开发（Development）→实施（Implementation）→评估（Evaluation），每阶段有明确交付物
+- [[SAM-Model]]（Successive Approximation Model）：适合快速迭代场景，通过"原型→评审→修订"循环缩短上线时间
+- [[Bloom-Taxonomy]]：认知六级分类（记忆→理解→应用→分析→评价→创造），用于设计学习目标和评估标准
+- [[Kolbs-Learning-Cycle]]：柯尔布体验学习圈（具体经验→反思观察→抽象概念化→主动实验）
+- [[Kirkpatrick-Model]]：四级培训评估模型（反应层→学习层→行为层→结果层）
+- [[Blended-Learning]]（OMO）：线上用于"知道"，线下用于"做到"，学习社区用于"持续"
+- [[Flipped-Classroom]]：课前线上预习知识点，课中讨论和动手练习，课后行为迁移
+- [[HIPO-Program]]（High-Potential Talent Development）：高潜力人才培养（绩效×潜力矩阵识别、IDP个人发展计划、轮岗、导师制、挑战性项目任务）
+- [[TTT-Train-the-Trainer]]：内部讲师培养体系（成人学习原理、课程开发技巧、授课演示技能、认证制度、社区运营）
+- [[Competency-Gap-Analysis]]：能力差距分析，通过360度评估、绩效数据、主管访谈建立岗位胜任力模型
+- [[Blended-Learning-Platform]]：中国企业学习平台（钉钉学习/企业微信学习/飞书知识库/UMU互动学习/云学堂/酷学院）
 
 ## Key Entities
-- [[The Agency]]：该 Agent 所属的 Agent 系统生态。
+- [[Bloom]]（Benjamin Bloom）：Bloom 认知分类法创始人，为学习目标层级设计提供理论依据
+- [[Kolb]]（David Kolb）：柯尔布体验学习圈创始人
+- [[Kirkpatrick]]（Donald Kirkpatrick）：Kirkpatrick 四级培训评估模型创始人
+- [[DingTalk-Learning]]：钉钉学习，阿里巴巴生态企业首选学习平台
+- [[WeCom-Learning]]：企业微信学习，微信生态企业首选
+- [[Feishu-Knowledge-Base]]：飞书知识库，字节跳动生态和知识管理导向组织首选
+- [[UMU]]：UMU 互动学习平台，混合学习领域领先者，支持 AI 练习搭档、视频作业、丰富互动功能
+- [[Yunxuetang]]（Cloud Academy）：云学堂，大中型企业一站式学习平台
 
 ## Connections
-- [[Specialized Workflow Architect]] ← related_to ← [[Corporate Training Designer]]：两者均涉及工作流程设计，但前者专注软件工程流程，后者专注组织学习流程。
-- [[Specialized Cultural Intelligence Strategist]] ← related_to ← [[Corporate Training Designer]]：两者均涉及跨文化能力建设，但前者专注产品文化包容，后者专注培训内容的文化适配。
-- [[Specialized HR Onboarding]] ← extends ← [[Corporate Training Designer]]：新员工培训是 Corporate Training Designer 的重要子领域。
+- [[ADDIE-Model]] ← foundational_model ← [[SAM-Model]]（SAM 是 ADDIE 的快速迭代变体）
+- [[Bloom-Taxonomy]] ← learning_objective_framework ← [[Kirkpatrick-Model]]（前者定义学什么，后者定义学到什么程度）
+- [[Kolbs-Learning-Cycle]] ← theoretical_basis ← [[Flipped-Classroom]]（翻转课堂是体验学习的实践应用）
+- [[Corporate-Training-Designer]] ← professional_domain ← [[HIPO-Program]]（高潜力人才培养是培训设计的重要子领域）
+- [[TTT-Train-the-Trainer]] ← enables ← [[Corporate-Training-Designer]]（内部讲师是培训落地的关键交付者）
+- [[Blended-Learning-Platform]] ← technology_infrastructure ← [[Corporate-Training-Designer]]（学习平台是培训交付的技术支撑）
 
 ## Contradictions
-- （暂无已知冲突。该 Agent 专注于企业内部培训体系，与其他 Agent 在应用场景上有明显差异。）
+- 无已知跨页面内容冲突。本页面为 Agent 个性定义文档，无其他 Wiki 页面涉及相同企业培训设计专家角色。
diff --git a/wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md b/wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md
index e84b397b..b87b5a6a 100644
--- a/wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md
+++ b/wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md
@@ -7,53 +7,55 @@ tags:
   - SES
   - Email
   - CTP
-  - Cloud-Email
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module]]
 
 ## Summary（用中文描述）
-- 核心主题：Micro Focus 团队使用 Terraform 模块自动化部署 AWS SES SMTP 服务，以替代传统的本地 SMTP 网关。
-- 问题域：随着业务向云端迁移，使用本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，网络安全部门要求统一使用云端邮件发送方案。
-- 方法/机制：在应用 VPC 中配置 VPC 终端节点以实现私有连接；通过 IAM 用户凭证作为 SMTP 认证信息并存储于 Secrets Manager；Terraform 模块自动化 SMTP 终端节点配置、DKIM 验证和 DNS 记录创建；支持现有应用程序通过标准 SMTP 协议集成，无需重构代码适配 SES API。
-- 结论/价值：SES 是唯一获网络安全部门批准的云端邮件发送方案；Terraform 模块化封装降低了集成复杂度；需注意两个手动步骤（申请脱离 Sandbox Mode 和手动更新 DNS TXT 记录）。
+- 核心主题：AWS SES SMTP Terraform 模块的架构设计与部署实践
+- 问题域：Micro Focus 云转型过程中，如何将传统本地 SMTP 网关替换为云端 SES 服务，同时保持现有应用的零改造接入
+- 方法/机制：团队开发专用 SES Terraform 模块，封装 SMTP 终端节点配置；通过 VPC 终端节点确保网络安全；IAM 用户凭证经转换后用作 SMTP 认证；凭证安全存储于 AWS Secrets Manager；自动化 DKIM 验证和 Infoblox DNS 记录创建
+- 结论/价值：该模块使现有应用通过标准 SMTP 协议无缝接入 SES，无需重构代码，是 Micro Focus 网络安全部门唯一批准的云端邮件发送方案
 
 ## Key Claims（用中文描述）
-- 在应用 VPC 中配置 VPC 终端节点，使应用可在不访问公网的情况下通过私有节点与 SES SMTP 服务通信。
-- IAM 用户的 Access Key 和 Secret Key 被转换后作为 SMTP 认证的用户名和密码，相关凭证安全存储于 AWS Secrets Manager。
-- Terraform 模块自动化完成 DKIM 验证和 Infoblox DNS 管理系统中域名所有权记录的创建。
-- 手动更新 DNS TXT 记录以验证域名所有权仍是必需步骤，因 Terraform 难以处理多个 AWS 账号共享同一域名时对同一 TXT 记录值的追加操作。
-- 脱离 SES Sandbox Mode（向 AWS 提交工单申请生产访问权限）是启用完整邮件发送能力的必要前提。
-- SES 是 Micro Focus 网络安全部门唯一批准的云端邮件发送方案，替代了原有的本地 SMTP 网关。
+- Micro Focus 网络安全部门仅批准 AWS SES 作为云端邮件发送方案，替代传统本地 SMTP 网关（如 `smtbmicrofocus.com`）
+- SES Terraform 模块封装 SMTP 终端节点配置，使现有应用通过标准 SMTP 协议集成，无需重构代码以适配 SES API
+- VPC 终端节点是应用安全访问 SES SMTP 服务的必要条件，由 VPC Wrapper 模块预先配置
+- IAM 用户凭证（Access Key / Secret Key）经转换后作为 SMTP 认证的用户名和密码，存储于 AWS Secrets Manager
+- Terraform 无法处理多 AWS 账号共享同一域名时对同一 DNS TXT 记录值的追加操作，必须手动更新
+- 脱离 SES Sandbox Mode（提升发送限额、允许向外部地址发信）是上线前的必要手动步骤
 
 ## Key Quotes
-> "随着业务向云端迁移，使用本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，SES 是目前网络安全部门唯一批准的云端邮件发送方案。" — Christian Deckelmann
-
-> "SES Terraform 模块封装了 SMTP 终端节点的配置，方便现有应用程序通过标准的 SMTP 协议进行集成，而无需重构代码以适配 SES API。" — Filos Christolakis
+> "随着业务向云端迁移，使用本地 SMTP 网关已不再高效，SES 是目前网络安全部门唯一批准的云端邮件发送方案。" — Christian Deckelmann
+> "我们开发的 SES Terraform 模块封装了 SMTP 终端节点的配置，方便现有应用程序通过标准的 SMTP 协议进行集成，而无需重构代码以适配 SES API。" — Filos Christolakis
 
 ## Key Concepts
-- [[VPC-Endpoint]]：AWS 提供的私有连接服务，允许在 VPC 内部通过私有 IP 地址安全访问 AWS 服务，无需经过公网。
-- [[DKIM-Email-Authentication]]：DomainKeys Identified Mail 的缩写，一种电子邮件验证标准，通过在邮件头部添加数字签名来防止欺诈和确保邮件完整性。
-- [[Secrets-Manager]]：AWS 提供的凭证管理服务，用于安全地存储和检索 SES SMTP 的认证信息。
-- [[SES-Sandbox-Mode]]：AWS SES 的默认限制状态，仅允许向已验证的地址发送少量邮件，需提交工单申请生产访问权限以提升发送限额。
+- [[AWS SES]]：AWS Simple Email Service，基于云的邮件发送服务，支持 API 和 SMTP 接口
+- [[SMTP Endpoint]]：SES 提供的区域性邮件传输协议终端节点
+- [[Sandbox Mode]]：SES 默认限制状态，仅允许向验证过的地址发送少量邮件
+- [[DKIM]]：DomainKeys Identified Mail，电子邮件验证标准，通过数字签名防止欺诈
+- [[VPC Endpoint]]：私有节点，使应用在不访问公网的情况下与 SES SMTP 服务通信
+- [[IAM User SMTP Auth]]：将 IAM 用户 Access Key/Secret Key 转换为 SMTP 用户名/密码的认证方式
 
 ## Key Entities
-- [[AWS]]：Amazon Web Services，云服务提供商，SES（Simple Email Service）所属平台。
-- [[Christian-Deckelmann]]：演讲者之一，分享 Micro Focus 在云转型中采用 SES SMTP 服务的背景与动机。
-- [[Filos-Christolakis]]：演讲者之一，详细讲解 SES Terraform 模块的技术实现方案。
-- [[Infoblox]]：公司内部使用的 DNS 管理系统，用于存放和管理验证域名所有权所需的 DNS 记录。
-- [[VPC-Wrapper-Module]]：SES Terraform 模块所依赖的前置 VPC 配置模块，负责预先配置 SMTP VPC 终端节点。
+- [[Christian Deckelmann]]：Micro Focus 云转型负责人，主讲人之一
+- [[Filos Christolakis]]：SES Terraform 模块开发者，主讲人之一
+- [[VPC Wrapper Module]]：预先配置 SMTP VPC 终端节点的 Terraform 模块，本模块依赖于此
+- [[Infoblox]]：公司内部 DNS 管理系统，用于管理 DNS 记录
+- [[AWS Secrets Manager]]：AWS 凭证管理服务，用于安全存储 SES SMTP 认证信息
 
 ## Connections
-- [[VPC-Wrapper-Module]] ← depends_on ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]
-- [[ctp-topic-12-using-ses-smtp-service-terraform-module]] ← extends ← [[AWS]]
-- [[Terraform-And-Terragrunt-Best-Practices]] ← related_to ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]（Terragrunt Pre-hook/Post-hook 用于处理手动 DNS 验证步骤）
-- [[ctp-topic-36-sendgrid-as-an-email-service]] ← alternative_to ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]（SendGrid 被选定为新 Landing Zone 标准，SES 用于现有应用迁移）
+- [[CTP Topic 12 Using SES SMTP service terraform module]] ← depends_on ← [[VPC Wrapper Module Session]]
+- [[CTP Topic 12 Using SES SMTP service terraform module]] ← part_of ← [[Landing Zone Architecture Overview]]
+- [[CTP Topic 12 Using SES SMTP service terraform module]] ← uses ← [[AWS Secrets Manager]]
+- [[CTP Topic 12 Using SES SMTP service terraform module]] ← uses ← [[Terragrunt]]
+- [[AWS Secrets Manager]] ← extends ← [[CTP Topic 62 AWS Secrets Manager]]
+- [[Landing Zone Architecture Overview]] ← extends ← [[CTP Topic 1 Gruntwork Landing Zone Architecture]]
 
 ## Contradictions
-- 与 [[ctp-topic-36-sendgrid-as-an-email-service]] 在邮件服务选型上的差异：
-  - 冲突点：两门课程分别介绍了不同的云邮件服务方案——SendGrid 被选定为标准云端邮件服务，而 SES 则专注于服务现有应用通过 SMTP 协议迁移上云。
-  - 当前观点：SES 通过 Terraform 模块封装现有应用 SMTP 接入路径，实现平滑迁移，无需修改应用代码。
-  - 对方观点：SendGrid 作为新标准云邮件服务，提供更高上限（每封 1,000 收件人 vs SES 每封 50 收件人）、更简单的 API 集成和全球中继节点。
+- 与 [[CTP Topic 36 SendGrid as an Email Service]] 的对比：
+  - 冲突点：两种云端邮件发送方案的适用场景和技术选型
+  - 当前观点：SES 是 Micro Focus 网络安全部门唯一批准的云端邮件发送方案，强调与现有应用的零改造集成
+  - 对方观点：SendGrid 提供了更完整的邮件管理平台功能（如收件人验证、分析报表），适合不同业务场景
diff --git a/wiki/sources/customer-service.md b/wiki/sources/customer-service.md
new file mode 100644
index 00000000..5a57b882
--- /dev/null
+++ b/wiki/sources/customer-service.md
@@ -0,0 +1,51 @@
+---
+title: "Customer Service Agent"
+type: source
+tags: [customer-service, agent, support, retention, escalation]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/customer-service.md]]
+
+## Summary（用中文描述）
+- 核心主题：通用行业客户服务 Agent 的角色定义与全流程操作规范——面向零售/SaaS/酒店/金融/电信/医疗行政/物流等多行业的全能客服专家，强调同理心优先、承诺必达、主动升级
+- 问题域：客户咨询/投诉/账户管理/订单处理/取消挽留/升级转接的全场景覆盖
+- 方法/机制：五步工作流（Greet & Assess → Understand → Resolve or Route → Confirm & Close → Document），配合十大关键规则（Empathy First、No Blame、Own the Problem、Proactive Escalation 等）
+- 结论/价值：为跨行业客服场景提供标准化、可量化的 Agent 行为规范，涵盖 6 大行业、5 大渠道、10 项可追踪 KPI
+
+## Key Claims（用中文描述）
+- 客户服务的本质是哲学而非部门——每一个联系进来的客户都值得感到被重视、被理解
+- 在任何政策或流程之前，必须先承认客户感受，否则无法建立信任
+- 永远不要在没有提供替代方案的情况下说"那不可能"——总有你能做的事
+- 永远不要把愤怒的客户置于等待状态而不征询同意——必须给予等待时间估计并提供回调选项
+- 在客户沮丧爆发之前主动升级——识别早期信号并框架化地提供升级选项
+- 绝不做出无法兑现的承诺——失信比原始问题更快地摧毁信任
+- 每个取消请求都必须经过真诚的挽留尝试——永远不要立即处理取消
+- 每次互动都必须记录——完整记录以便下一位代理或专员有充分上下文
+
+## Key Quotes
+> "Customer service isn't a department — it's a philosophy. Every person who reaches out deserves to feel like they matter, their issue is understood, and someone is genuinely working to help them." — 核心服务哲学
+> "Every customer interaction is a chance to turn a problem into loyalty — handle it with care, speed, and a human touch." — 互动即忠诚转化机会
+
+## Key Concepts
+- [[EmpathyFirst]]：同理心优先——在任何政策、流程、解决方案之前必须先承认客户的感受
+- [[ComplaintResponseProtocol]]：投诉响应协议（ACK/VIND/ACT 五步：Acknowledge → Validate → Clarify → Act → Commit）——绝不跳过承认步骤
+- [[RetentionProtocol]]：挽留协议——绝不立即处理取消请求，必须先了解原因并提供替代方案
+- [[EscalationProtocol]]：升级协议——立即/紧急/标准三级触发条件，Always Warm Transfer
+- [[ActiveListening]]：主动倾听——在回应之前完整反射客户所述内容
+
+## Key Entities
+- [[HealthcareCustomerService]]：医疗客户服务 Agent — 与通用客服 Agent 共享投诉处理框架和升级协议，但医疗场景要求 HIPAA 强制身份验证
+
+## Connections
+- [[HealthcareCustomerService]] ← analogous_to ← [[CustomerService]]（两者共享投诉处理框架和升级协议，医疗场景额外要求 HIPAA 合规）
+- [[HospitalityGuestServices]] ← analogous_to ← [[CustomerService]]（酒店客服 Agent 是通用客服 Agent 在款待业场景的具体化，HEARD 框架与通用投诉协议互通）
+- [[SupportResponder]] ← extends ← [[CustomerService]]（通用客服响应 Agent 是 Customer Service Agent 的抽象层）
+
+## Contradictions
+- 与 [[LegalClientIntake]] 冲突（由 [[HealthcareCustomerService]] 记录）：
+  - 冲突点：身份验证严格程度在不同场景的差异
+  - 当前观点（通用客服）：基于姓名 + 邮箱验证即可开始处理账户操作
+  - 对方观点（医疗场景）：HIPAA 要求全名 + 出生日期 + SSN 后四位方可讨论 PHI
+  - 注：两者场景不同，冲突源于场景差异而非事实矛盾，可共存
diff --git a/wiki/sources/data-consolidation-agent.md b/wiki/sources/data-consolidation-agent.md
index 6c7f1cf2..fade56e9 100644
--- a/wiki/sources/data-consolidation-agent.md
+++ b/wiki/sources/data-consolidation-agent.md
@@ -2,47 +2,50 @@
 title: "Data Consolidation Agent"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/data-consolidation-agent.md]]
+- [[Agent/agency-agents/specialized/data-consolidation-agent.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 将分散的销售提取数据整合为实时报告仪表盘
-- 问题域：销售团队缺乏统一视图查看各地区、销售代表和管道的实时业绩数据
-- 方法/机制：并行多维度查询 → 聚合计算派生指标 → Dashboard 友好 JSON 结构化输出 → 含时间戳的实时刷新机制
-- 结论/价值：< 1 秒仪表盘加载、60 秒自动刷新、零数据不一致
+- 核心主题：AI Agent 将分散的销售数据聚合为实时仪表盘报告，支持地域、代表、管道多维度视图
+- 问题域：销售团队需要统一的实时数据视图，替代手动 Excel 汇总，消除数据孤岛
+- 方法/机制：接收仪表盘或地域报告请求 → 并行查询所有数据维度 → 聚合计算派生指标 → 结构化为 Dashboard-friendly JSON 输出 → 含生成时间戳用于陈旧度检测
+- 结论/价值：实现 < 1 秒仪表盘加载、60 秒自动刷新、零数据不一致，支持 MTD/YTD/Year End 多视图
 
 ## Key Claims（用中文描述）
-- Data Consolidation Agent 通过并行查询所有数据维度，将原始销售指标聚合为可操作的实时仪表盘
-- Agent 始终使用最新数据（按 type 取最新的 metric_date），确保数据时效性
-- 达成率计算：revenue / quota * 100，并处理除零错误
-- 按地区聚合数据，提供区域级别可见性，整合管道数据形成完整销售视图
-- 支持 MTD/YTD/Year End 多时间维度视图
+- Data Consolidation Agent 始终查询每个类型最新 metric_date 的数据，保证所有视图使用最新指标
+- 达成率（Attainment）计算公式为 revenue / quota * 100，需处理除零边界情况
+- 管道数据（Pipeline）与销售指标合并，提供从线索到成交的完整数据图景
+- 仪表盘交付物包含 6 类报告：地域绩效汇总、个人代表绩效、管道快照、6 个月趋势数据、Top 5 绩效代表、地域详细报告
+- 地域报告包含该地域内所有代表及其最新指标，以及最近 50 条指标历史记录
+- 成功指标：仪表盘加载 < 1 秒、报告每 60 秒自动刷新、100% 代表和活跃地域覆盖、详情视图与汇总视图零数据不一致
 
 ## Key Quotes
-> "You are the **Data Consolidation Agent** — a strategic data synthesizer who transforms raw sales metrics into actionable, real-time dashboards. You see the big picture and surface insights that drive decisions." — Agent 身份定义
+> "You are the **Data Consolidation Agent** — a strategic data synthesizer who transforms raw sales metrics into actionable, real-time dashboards." — Agent 身份定义，战略定位为"数据综合者"而非数据搬运工
 
-> "Zero data inconsistencies between detail and summary views" — 数据质量核心承诺
+> "Calculate attainment accurately: revenue / quota * 100, handle division by zero" — 核心计算规则，除零处理是防止报告崩溃的关键
+
+> "Include pipeline data: merge lead pipeline with sales metrics for full picture" — 管道数据合并策略，提供从线索到成交的全链路视图
 
 ## Key Concepts
-- [[Dashboard Report]]：含地区业绩摘要（YTD/MTD）、代表排名、管道快照、6 个月趋势、Top 5 业绩者
-- [[Territory Report]]：地区级深度分析，含该地区所有代表及其指标及最近 50 条历史记录
-- [[Sales Attainment]]：达成率 = revenue / quota * 100，处理除零错误
-- [[Pipeline Snapshot]]：按阶段聚合（数量/价值/加权价值）的管道数据快照
-- [[Metric Aggregation]]：多维度并行查询后聚合计算派生指标的工作流
+- [[Territory-Performance]]：按地域聚合的销售绩效指标汇总，含 YTD/MTD 收入、达成率、代表人数
+- [[Quota-Attainment]]：销售配额达成率，计算公式：revenue / quota * 100，处理除零边界
+- [[Pipeline-Metrics]]：销售管道各阶段（数量、价值、加权价值）的快照数据
+- [[MTD-YTD]]：Month-to-Date / Year-to-Date 两种时间维度汇总视图
+- [[Dashboard-Friendly-JSON]]：结构化 JSON 输出格式，专为仪表盘消费设计，含时间戳元数据
+- [[Trend-Analysis]]：过去 6 个月的趋势数据分析
 
 ## Key Entities
-- [[Sales Data Extraction Agent]]：上游数据提取 Agent，为 Data Consolidation Agent 提供原始销售指标数据
-- [[Report Distribution Agent]]：下游分发 Agent，接收整合后的仪表盘数据进行分发推送
+- [[Data-Consolidation-Agent]]：The Agency Specialized 部门的数据综合专家 Agent，专注于销售数据聚合与实时仪表盘
+- [[Sales-Data-Extraction-Agent]]：上游数据提取 Agent，监控文件系统并从 Excel 中提取销售指标，为本 Agent 提供数据源
 
 ## Connections
-- [[Sales Data Extraction Agent]] → produces → raw sales metrics
-- [[Data Consolidation Agent]] ← consumes ← [[Sales Data Extraction Agent]]
-- [[Report Distribution Agent]] ← consumes ← [[Data Consolidation Agent]] (Dashboard Report / Territory Report)
-- [[Sales Pipeline Analyst]] ← shares pipeline data sources with → [[Data Consolidation Agent]]
-- [[Sales Coach Agent]] ← consumes ← [[Data Consolidation Agent]] (Top 5 performers)
+- [[Sales-Data-Extraction-Agent]] ← upstream_data ← [[Data-Consolidation-Agent]]（数据提取后由本 Agent 进行聚合与展示）
+- [[Report-Distribution-Agent]] ← downstream_report ← [[Data-Consolidation-Agent]]（聚合后的报告传递给分发 Agent）
+- [[Sales-Pipeline-Analyst]] ← pipeline_insights ← [[Data-Consolidation-Agent]]（管道快照数据为管道分析提供输入）
+- [[Sales-Account-Strategist]] ← territory_data ← [[Data-Consolidation-Agent]]（地域绩效数据支持账户策略决策）
 
 ## Contradictions
-- 无已知内容冲突。该 Agent 与 [[Sales Pipeline Analyst]] 共享数据源但职责互补（分析 vs 整合），与 [[Report Distribution Agent]] 构成顺序管道关系。
+- 无已知内容冲突。Data Consolidation Agent 与 [[Sales-Data-Extraction-Agent]] 为上下游关系（非竞争），与 [[Report-Distribution-Agent]] 协同完成数据到用户的完整链路。
diff --git a/wiki/sources/design-brand-guardian.md b/wiki/sources/design-brand-guardian.md
index c76cb8cf..bae4de30 100644
--- a/wiki/sources/design-brand-guardian.md
+++ b/wiki/sources/design-brand-guardian.md
@@ -1,50 +1,53 @@
 ---
-title: "Design Brand Guardian"
+title: "Brand Guardian Agent Personality"
 type: source
-tags: []
-date: 2026-04-20
+tags: [agent, design, brand, strategy]
+date: 2024-01-01
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/design/design-brand-guardian.md]]
+- [[Agent/agency-agents/design/design-brand-guardian.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Brand Guardian Agent 角色定义——品牌战略与身份守护专家智能体，负责创建 cohesive 品牌体系和保护品牌价值
-- 问题域：品牌战略制定、品牌视觉身份建设、品牌一致性维护、品牌知识产权保护
-- 方法/机制：品牌战略框架（Purpose/Vision/Mission/Values/Personality）、视觉身份系统（Logo/色彩/字体/CSS 变量系统）、品牌声音指南（Tone/Trait/声调变化）、品牌保护策略（商标监控、合规审计、危机管理）
-- 结论/价值：为 AI Agent 系统提供品牌守护能力，确保多 Agent 协作中品牌表达的一致性和完整性；品牌先行（Brand-First）原则确保在战术执行前先建立完整的品牌基础
+- 核心主题：The Agency Design 部门的品牌守护者专家 Agent，为品牌提供全面的战略定位、视觉识别系统构建和品牌保护
+- 问题域：品牌建设缺乏系统性、品牌一致性难以维护、品牌价值缺乏保护机制
+- 方法/机制：通过 Foundation-first 理念先行建立完整品牌基础，再通过系统性视觉识别、声音系统和保护策略确保品牌差异化与持久价值
+- 结论/价值：品牌必须在战术执行前完成战略基础建设；一致性是品牌成功的核心；保护与进化并重
 
 ## Key Claims（用中文描述）
-- Brand Guardian Agent 通过战略性的品牌策略将业务目标与品牌执行连接起来，确保品牌决策与商业目标一致
-- 完整的视觉身份系统必须包含从品牌颜色、字体、间距到 Logo 变体的全链路 CSS 设计系统变量
-- 品牌保护是默认要求，需包含商标策略、合规监控和危机管理机制
-- 品牌需要在保持一致性的同时，为不同场景和应用提供足够的灵活性
+- Brand Guardian Agent 通过建立完整的品牌基础框架（Purpose/Vision/Mission/Values/Personality）实现品牌差异化
+- 视觉识别系统（Logo/Color/Typography）必须作为内聚系统设计，而非孤立元素
+- 品牌保护（商标/合规监控/危机管理）应作为默认要求内置于品牌策略中
+- 品牌进化需要在保持核心身份的同时适应市场变化
 
 ## Key Quotes
-> "You are **Brand Guardian**, an expert brand strategist and guardian who creates cohesive brand identities and ensures consistent brand expression across all touchpoints." — 角色核心定义
-> "Establish comprehensive brand foundation before tactical implementation" — 品牌先行原则
+> "Your brand's fiercest protector and most passionate advocate." — Brand Guardian 定位语
+> "Establish comprehensive brand foundation before tactical implementation" — 品牌优先原则
 > "Balance consistency with flexibility for different contexts and applications" — 一致性与灵活性平衡
-> "Build brands that can evolve and grow with changing market conditions" — 品牌长期演进思维
+> "Build brands that can evolve and grow with changing market conditions" — 战略品牌思维
 
 ## Key Concepts
-- [[Brand-Strategy]]: 品牌战略框架——Purpose（存在意义）、Vision（愿景）、Mission（使命）、Values（价值观）、Personality（人格）五要素，是所有品牌决策的顶层指导
-- [[Visual-Identity-System]]: 视觉身份系统——通过 CSS 变量定义的完整设计系统，涵盖品牌色彩（Primary/Secondary/Accent/Neutral）、字体（Primary/Secondary/Accent）、间距系统（XS/SM/MD/LG/XL）
-- [[Brand-Voice-Guidelines]]: 品牌声音指南——Voice Characteristics（声音特征）、Tone Variations（声调变化）、Messaging Architecture（信息架构）、Writing Guidelines（写作规范）四个维度确保品牌沟通一致性
-- [[Brand-Protection-Strategy]]: 品牌保护策略——商标与知识产权保护、合规监控流程、危机管理与声誉保护、干系人培训与品牌传播
+- [[Brand-Foundation-Framework]]：品牌 Purpose（存在意义）、Vision（愿景）、Mission（使命）、Values（价值观）、Personality（个性）的完整框架
+- [[Visual-Identity-System]]：Logo、Color Palette、Typography、Spacing 的系统性设计规范
+- [[Brand-Voice]]：品牌声音特征（Strategic/Consistent/Protective/Visionary）和 Tone 变体（Professional/Conversational/Supportive）
+- [[Brand-Protection]]：商标策略、合规监控、危机管理三位一体的品牌保护体系
 
 ## Key Entities
-- [[The Agency]]: 所属项目——Brand Guardian 是 The Agency 多智能体框架中的品牌守护专家，与 [[ArchitectUX]]（技术架构）、[[design-whimsy-injector]]（趣味性设计）、[[UX-Researcher]]（用户体验研究）协同，共同为 [[LuxuryDeveloper]] 提供完整的设计支撑
+- [[The-Agency]]：Brand Guardian Agent 所属的组织，提供 12 个业务部门共 147 个专业 Agent
+- [[Design-Department]]：Brand Guardian 所在的设计部门，与 UX Architect、Whimsy Injector 共同构成设计三支柱
+- [[UX-Architect]]：设计部门基础设施专家，Brand Guardian 在视觉识别上依赖其 CSS 设计系统
+- [[Whimsy-Injector]]：设计部门趣味性专家，Brand Guardian 定义的品牌个性是其趣味性设计的输入
 
 ## Connections
-- [[design-whimsy-injector]] ← complements ← [[design-brand-guardian]]
-- [[ArchitectUX]] ← complements ← [[design-brand-guardian]]
-- [[UX-Researcher]] ← supports ← [[design-brand-guardian]]
-- [[LuxuryDeveloper]] ← depends_on ← [[design-brand-guardian]]
-- [[The Agency]] ← contains ← [[design-brand-guardian]]
+- [[design-ux-architect]] ← provides_foundations ← [[design-brand-guardian]]
+- [[design-whimsy-injector]] ← extends ← [[design-brand-guardian]]
+- [[design-ux-researcher]] ← informs ← [[design-brand-guardian]]
+- [[workflow-landing-page]] ← requires ← [[design-brand-guardian]]
+- [[design-brand-guardian]] ← implements ← [[The-Agency]]
 
 ## Contradictions
-- 与 [[design-whimsy-injector]] 在设计方法论上的张力：
-  - 冲突点：品牌一致性（Brand Guardian 强调标准化与防护）vs. 个性化趣味（Whimsy Injector 强调创意表达）
-  - 当前观点：Brand Guardian 主张在战术执行前必须先建立完整的品牌基础，保护品牌完整性
-  - 对方观点：Whimsy Injector 主张通过有目的的趣味和个性化微交互提升用户体验，允许灵活创意表达
-  - 解决方向：两者互补——Brand Guardian 建立品牌边界，Whimsy Injector 在边界内注入品牌个性，两者共同服务于 LuxuryDeveloper 的高端品牌体验
+- 与 [[design-ux-architect]] 存在角色重叠张力：
+  - 冲突点：两者都涉及视觉设计元素，边界模糊
+  - 当前观点：Brand Guardian 聚焦品牌战略与品牌身份，UX Architect 聚焦技术实现与组件架构
+  - 对方观点：UX Architect 认为技术架构是品牌落地的保障
+  - 解决方式：通过时序分工协调——Brand Guardian 先定义品牌框架 → UX Architect 再构建技术系统
diff --git a/wiki/sources/design-image-prompt-engineer.md b/wiki/sources/design-image-prompt-engineer.md
index 04a80c6b..c39d077d 100644
--- a/wiki/sources/design-image-prompt-engineer.md
+++ b/wiki/sources/design-image-prompt-engineer.md
@@ -1,59 +1,65 @@
 ---
-title: "Image Prompt Engineer Agent"
+title: "Image Prompt Engineer Agent Personality"
 type: source
-tags: []
-date: 2026-04-20
+tags: [ai-agent, design, prompt-engineering, photography, the-agency]
+date: 2026-05-15
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/design/design-image-prompt-engineer.md]]
+- [[Agent/agency-agents/design/design-image-prompt-engineer]]
 
 ## Summary（用中文描述）
-- 核心主题：AI 图像生成提示词工程专家智能体，专注于将视觉概念精准翻译为可执行的提示词语言
-- 问题域：如何让 AI 图像生成工具（Midjourney/DALL-E/Stable Diffusion/Flux）稳定产出专业级摄影作品
-- 方法/机制：五层提示词结构框架（主体描述 → 环境设定 → 光线规范 → 摄影技术 → 风格美学）+ 平台特定语法优化 + 体裁专属提示模式
-- 结论/价值：通过结构化的摄影专业知识与 AI 提示词语言的融合，实现 90%+ 的视觉概念还原率，减少迭代次数，提升商业可用性
+
+- **核心主题**：AI 图像生成提示词工程专家 Agent——将视觉概念精准翻译为结构化提示词语言，驱动 Midjourney、DALL-E、Stable Diffusion、Flux 等平台产出专业级摄影作品
+- **问题域**：AI 图像生成中的提示词不精确、无结构、术语错误等问题；摄影师和 AI 模型之间的"语言鸿沟"
+- **方法/机制**：五层提示词结构框架（主体 → 环境 → 光线 → 摄影技术 → 风格）+ 体裁专属模板（人像/产品/风光/时尚）+ 平台特定语法优化
+- **结论/价值**：结构化提示词 + 摄影精确术语 = 90%+ 视觉概念还原率；Midjourney/DALL-E/SD/Flux 各有专属语法；负向提示词是可控生成的关键工具
 
 ## Key Claims（用中文描述）
-- 五层提示词结构（主体/环境/光线/技术/风格）确保 AI 生成图像与视觉概念高度一致
-- 摄影技术术语（如 f/1.8 bokeh、浅景深）比模糊描述（如"背景模糊"）产生更精确的 AI 输出
-- 负向提示词（negative prompts）在支持平台上可有效排除不想要的元素
-- 提示词框架应适配不同 AI 平台的语法偏好（Midjourney 参数、DALL-E 自然语言、Stable Diffusion token 加权、Flux 详细描述）
+
+- **主体 + 机制 + 结果**：Image Prompt Engineer 使用五层结构化提示词框架 → 将视觉概念分层拆解为标准化描述 → 驱动 AI 模型实现 90%+ 视觉概念还原率
+- **主体 + 机制 + 结果**：Agent 使用精确摄影术语（如 "f/1.8 bokeh 浅景深" 而非 "背景模糊"）→ 消除 AI 模型对模糊描述的歧义 → 技术摄影元素（布光/景深/构图）精准渲染
+- **主体 + 机制 + 结果**：Agent 包含负向提示词规范 → 主动排除不想要元素 → 减少迭代次数，提升生成结果的可控性
+- **主体 + 机制 + 结果**：Agent 为四大主流平台（Midjourney/DALL-E/SD/Flux）提供专属语法和参数优化 → 各平台充分发挥特有能力 → 跨平台一致的专业输出
 
 ## Key Quotes
-> "Always structure prompts with subject, environment, lighting, style, and technical specs" — 提示词结构五要素
-> "Use specific, concrete terminology rather than vague descriptors" — 具体性原则
-> "Master the art of translating visual concepts into precise, structured language that produces stunning, professional-quality photography" — 核心使命
+
+> "Always structure prompts with subject, environment, lighting, style, and technical specs" — 五层提示词结构的核心原则
+
+> "Use specific, concrete terminology rather than vague descriptors" — 精确性优先于模糊性
+
+> "Be specific: 'Soft golden hour side lighting creating warm skin tones with gentle shadow gradation' not 'nice lighting'" — 具体性示例
+
+> "You're successful when: Generated images match the intended visual concept 90%+ of the time" — 成功指标定义
 
 ## Key Concepts
-- [[Prompt-Engineering]]：AI 图像生成提示词工程的核心方法论
-- [[Five-Layer-Prompt-Structure]]：主体描述层 → 环境设定层 → 光线规范层 → 摄影技术层 → 风格美学层
-- [[Photography-Prompt-Mastery]]：将摄影专业知识转化为 AI 可理解提示词的能力
-- [[Platform-Specific-Prompt-Optimization]]：针对不同 AI 图像平台（Midjourney/DALL-E/Stable Diffusion/Flux）的定制化提示词策略
-- [[Negative-Prompts]]：负向提示词，排除不想要的图像元素
-- [[Film-Emulation]]：胶片模拟风格提示词（Kodak Portra/Fuji Velvia/Ilford HP5/Cinestill 800T）
-- [[Lighting-Patterns]]：摄影布光模式（Rembrandt/Butterfly/Split/Chiaroscuro/Vermeer/Neon-Noir）
+
+- [[Five-Layer-Prompt-Structure]]：五层提示词结构——主体描述层 → 环境设定层 → 光线规范层 → 摄影技术层 → 风格美学层，是该 Agent 的核心方法论框架
+- [[Photography-Terminology]]：专业摄影术语体系——精确描述光线、构图、相机参数和后处理效果的标准化语言，如 Rembrandt Lighting、Butterfly Lighting、Bokeh 等
+- [[Negative-Prompting]]：负向提示词——主动指定不想要的内容元素，排除 AI 生成图像中的干扰和缺陷
+- [[Platform-Specific-Optimization]]：平台特定优化——Midjourney（`--ar`/`--v`/多提示词加权）、DALL-E（自然语言优化）、Stable Diffusion（Token 加权/Embedding/LoRA）、Flux（详细自然语言/写实优先）
+- [[Genre-Specific-Prompt-Patterns]]：体裁专属提示词模板——人像（85mm/f/1.4/浅景深）、产品（Hero Shot/微距/深焦）、风光（广角/深焦/HDR）、时尚（戏剧光/多样视角）
 
 ## Key Entities
-- [[Midjourney]]：AI 图像生成平台，以参数化提示词（--ar/--v/--style/--chaos）著称
-- [[DALL-E]]：OpenAI 的 AI 图像生成工具，擅长自然语言描述和风格混合
-- [[Stable-Diffusion]]：开源 AI 图像生成平台，支持 token 加权和 embedding 引用
-- [[Flux]]：以详细自然语言描述和照片级写实风格著称的新兴 AI 平台
-- [[Annie Leibovitz]]：时尚/人像摄影大师，其风格常被引用为提示词参考
-- [[Peter Lindbergh]]：经典黑白人像摄影大师，其极简风格常被引用为提示词参考
-- [[The Agency]]：多智能体框架，本智能体隶属 Design 设计部门
+
+- [[Midjourney]]：AI 图像生成平台——支持 `--ar`/`--v`/`--style`/`--chaos`/`--no` 参数和多提示词加权（`::` 语法）
+- [[Stable-Diffusion]]：AI 图像生成平台——支持 Token 加权、Embedding 引用和 LoRA 集成
+- [[DALL-E]]：AI 图像生成平台——偏好详细自然语言描述，支持风格混合
+- [[Flux]]：AI 图像生成平台——对写实摄影有天然优势，偏好详细具体描述
+- [[Annie-Leibovitz]]：参考摄影师——戏剧性人像与叙事场景风格
+- [[Peter-Lindbergh]]：参考摄影师——自然光黑白、真实质感风格
 
 ## Connections
-- [[design-ui-designer]] ← shares_design_domain ← [[design-image-prompt-engineer]]
-- [[design-brand-guardian]] ← brand_consistency ← [[design-image-prompt-engineer]]
-- [[design-whimsy-injector]] ← visual_language ← [[design-image-prompt-engineer]]
-- [[design-ux-researcher]] ← visual_validation ← [[design-image-prompt-engineer]]
-- [[ArchitectUX]] ← design_system ← [[design-image-prompt-engineer]]
-- [[Multi-Agent-System-Reliability]] ← context ← [[The Agency]] agent ecosystem
+
+- [[design-ui-designer]] ← depends_on ← [[design-image-prompt-engineer]]：UI Designer 在视觉设计阶段可能调用图像提示词工程能力获取参考图像或 UI 素材图像
+- [[design-whimsy-injector]] ← depends_on ← [[design-image-prompt-engineer]]：品牌趣味设计需要视觉图像支撑，提示词工程能力为趣味图像的精准生成提供语言工具
+- [[design-brand-guardian]] ← extends ← [[design-image-prompt-engineer]]：Brand Guardian 定义的视觉品牌规范通过 Image Prompt Engineer 的提示词框架转化为具体图像
+- [[design-visual-storyteller]] ← depends_on ← [[design-image-prompt-engineer]]：视觉叙事中的图像素材通过提示词工程实现精准生成
 
 ## Contradictions
-- 与 [[design-ui-designer]] 在视觉一致性上的差异：
-  - 冲突点：UI Designer 追求像素级精确还原（95%+ 准确率），Image Prompt Engineer 的输出本质上是概率生成，存在固有不确定性
-  - 当前观点：Image Prompt Engineer 的目标不是像素级还原，而是 90%+ 视觉概念还原；概率性是 AI 图像生成的本质约束
-  - 对方观点：UI Designer 要求 95%+ 实现准确率，将提示词视为"设计到代码"的翻译环节
-  - 协调方案：两者协同时，Image Prompt Engineer 应提供多版本变体供 UI Designer 选择，并在提示词中增加确定性约束（如具体颜色值、光照参数）
+
+- 与 [[design-ui-designer]] 冲突：
+  - **冲突点**：精确性要求——UI Designer 要求像素级精确的确定性交付，AI 图像生成本质是概率性过程，存在固有不确定性
+  - **当前观点**：Image Prompt Engineer 通过确定性约束（具体颜色值/光照参数/相机规格）最大化控制力，接受概率性结果的有限不确定性
+  - **对方观点**：UI Designer 追求 95%+ 视觉一致性，可能对 AI 生成的不确定性持保留态度
+  - **协调方式**：UI Designer 在需要 AI 生成图像时，通过 Image Prompt Engineer 提供极其详细的摄影参数约束，将概率空间压缩到可接受范围
diff --git a/wiki/sources/design-inclusive-visuals-specialist.md b/wiki/sources/design-inclusive-visuals-specialist.md
index 0d5bb545..3a741f31 100644
--- a/wiki/sources/design-inclusive-visuals-specialist.md
+++ b/wiki/sources/design-inclusive-visuals-specialist.md
@@ -1,53 +1,51 @@
 ---
 title: "Inclusive Visuals Specialist"
 type: source
-tags: [generative-ai, bias-mitigation, prompt-engineering, inclusive-design, image-generation, video-generation, ai-ethics]
-sources: []
-last_updated: 2026-04-24
+tags: []
+date: 2026-05-15
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/design/design-inclusive-visuals-specialist.md]]
+- [[Agent/agency-agents/design/design-inclusive-visuals-specialist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI 图像/视频生成中的包容性视觉呈现专家 Agent，专注于消除系统性刻板印象和偏见，生成具有文化真实性、尊严感和无歧视性的图像与视频。
-- 问题域：主流图像/视频生成模型（Midjourney、Sora、Runway、DALL-E）固有的刻板印象问题——克隆脸、异域化布光、符号乱码、地理/建筑失真。
-- 方法/机制：通过结构化提示词工程（Subject → Sub-actions → Context → Camera → Color Grade → Explicit Exclusions）构建"有尊严的视频提示"，并在 4 阶段工作流中嵌入负向约束库、物理学定义和 7 点 QA 审查。
-- 结论/价值：实现"表征准确度 100%"、"AI 伪影消除率 100%"、"社区验证认可"三大成功指标。
+- 核心主题：AI 图像与视频生成中的系统性偏见问题，以及如何通过精密的提示词工程实现有尊严、真实、文化准确的人类 representation
+- 问题域：Midjourney、DALL-E、Sora、Runway 等基础模型内置的刻板印象、克隆面孔、文化符号乱码、地理建筑失真等系统性偏差
+- 方法/机制：六阶段工作流（Brief Intake → Annotation Framework → Video Physics Definition → Review Gate）；五段式提示词架构（Subject → Sub-actions → Context → Camera Spec → Color Grade → Explicit Exclusions）；显式负面约束库（Negative Prompt Library）；7 点 QA 检查清单
+- 结论/价值：最终生产资产中刻板印象零依赖；100% 消除克隆面孔和乱码文化文字；确保被描绘社区的用户认可资产为真实、有尊严且符合其现实的特定 representation
 
 ## Key Claims（用中文描述）
-- 主流 AI 图像/视频生成模型默认携带系统性刻板印象（"穿帽衫的黑客"、"白救世主 CEO"），需通过显式负向约束加以对抗。
-- 多样化人群图像中若不明确禁止"克隆脸"，模型会生成同一边缘化人物的多个复制版本，导致冒犯性表征。
-- AI 在非英语文字、文化符号生成上存在幻觉倾向（生成乱码或冒犯性字符），必须在负向提示中显式排除。
-- 视频生成中服装、头发、辅助器具（轮椅、拐杖）的物理一致性需要显式定义，否则模型会产生物理学错误。
-- 过度纠正（Over-correction）是新型风险——AI 在刻意追求多样性时可能产生"符号化"、不真实的构图。
+- 提示词工程师通过架构化约束注入，能够系统性对抗基础模型的"异域化"偏见（exoticism bias），确保照明和地理建筑反映真实生活现实
+- 身份（Identity）不应被视为简单的描述符输入——它是一个需要专业技术知识才能准确 representation 的领域
+- 在视频生成中，必须显式定义衣物、头发和辅助行动器具（轮椅、拐杖、假肢）的物理规律，以避免渲染故障或物理错误
+- 代理人在评估 AI 输出时不仅检查技术保真度，还检查社会学准确性（Sociological Accuracy）
 
 ## Key Quotes
-> "Identity is a domain requiring technical expertise to represent accurately." — 身份表征不是简单的描述符输入，而是一个需要专业技术来处理的问题域。
-> "The current prompt will likely trigger the model's 'exoticism' bias. I am injecting technical constraints to ensure the lighting and geographical architecture reflect authentic lived reality." — 解释性声明：当前提示词可能触发模型的"异域化"偏见，正在注入技术约束以确保布光和建筑反映真实生活现实。
-> "You reject 'Kumbaya' stock-photo tropes, performative tokenism, and AI hallucinations that distort cultural realities." — 拒绝"Kumbaya"式库存照片套路、表演性象征主义和扭曲文化现实的 AI 幻觉。
+> "The current prompt will likely trigger the model's 'exoticism' bias. I am injecting technical constraints to ensure the lighting and geographical architecture reflect authentic lived reality." — Inclusive Visuals Specialist 核心沟通语
+> "Identity is a domain requiring technical expertise to represent accurately." — 身份 representation 的核心原则
+> "You review AI output not just for technical fidelity, but for sociological accuracy." — 代理人评估标准
 
 ## Key Concepts
-- [[InclusiveVisuals]]: AI 生成图像/视频中的包容性视觉呈现——确保生成内容反映真实多样的社会现实，而非刻板印象。
-- [[NegativePromptingLibrary]]: 负向提示库——显式列举 AI 应避免生成的内容，是对抗 AI 幻觉的核心技术手段。
-- [[CloneFaceProblem]]: 克隆脸问题——AI 在生成多样化人群时倾向于生成同一人的多个复制版本，需要通过约束面部结构差异来避免。
-- [[ExoticismBias]]: 异域化偏见——AI 对非西方文化进行"东方主义"式的过度美化或扭曲呈现，需要通过地理和建筑真实性约束加以对抗。
-- [[VideoPhysicsDefinition]]: 视频物理学定义——对服装、头发、辅助器具的运动和交互进行显式物理约束，确保时间一致性。
-- [[IntersectionalRepresentation]]: 交叉性表征——同时考虑文化、年龄、残疾、社会经济地位等多重身份的叠加表征。
-- [[CommunityValidation]]: 社区验证——确保所描绘社区的用户认可生成资产为真实、有尊严且符合其现实的表征。
+- [[Negative Prompting]]：通过显式负面约束阻止 AI 生成中的"克隆面孔"、乱码文化文字、超现实/科幻刻板等降低人类 representation 质量的 artifacts
+- [[Intersectionality]]：在文化、年龄、残障、社会经济地位等多维度交叉重叠下捕捉真实的身份 representation，要求特定的提示词架构方法
+- [[Video Physics Definition]]：在 Sora/Runway 等视频生成模型中显式定义衣物飘逸、头发摆动、轮椅轮胎接触地面等物理一致性约束
+- [[Cultural Authenticity]]：确保提示词正确锚定主体在其真实环境（准确建筑、正确服饰类型、适合黑色素的照明）中的 representation
+- [[Sociological Accuracy]]：超越技术保真度的 AI 输出评估维度——检查 representation 是否被描绘社区的用户认可为真实和有尊严的
 
 ## Key Entities
-- [[TheAgency]]: 该 Agent 所属的 Agent 团队体系（agency-agents）。
-- Midjourney、Sora、Runway Gen-3、DALL-E：主要的目标图像/视频生成平台。
+- [[Midjourney]]：图像生成平台，面临克隆面孔和刻板印象的已知问题
+- [[DALL-E]]：OpenAI 图像生成平台，需要通过负面约束阻止文化符号乱码
+- [[Sora]]：OpenAI 视频生成模型，视频物理约束（衣物/辅助器具渲染）的重要目标平台
+- [[Runway]]：视频生成平台，需要 temporal consistency 约束确保运动一致性
 
 ## Connections
-- [[DesignImagePromptEngineer]] ← extends ← [[InclusiveVisualsSpecialist]]（提示词工程是该 Agent 的核心技术）
-- [[DesignUXResearcher]] ← provides_review_gate ← [[InclusiveVisualsSpecialist]]（UX Researcher 提供 7 点 QA 审查）
-- [[DesignBrandGuardian]] ← quality_gate ← [[InclusiveVisualsSpecialist]]（Brand Guardian 把控企业品牌伦理标准）
-- [[InclusiveVisualsSpecialist]] ← produces_assets_for ← 全球文化活动（营销/传播团队）
+- [[Design Image Prompt Engineer]] ← 平行协作 ← [[Inclusive Visuals Specialist]]（两者同属 The Agency Design 部门，图像工程师负责视觉概念翻译，Inclusive Visuals 专攻多样性 representation）
+- [[Design Brand Guardian]] ← 对齐约束 ← [[Inclusive Visuals Specialist]]（品牌视觉规范与伦理 AI imagery 标准需要协调）
+- [[Design UX Researcher]] ← 质量验证 ← [[Inclusive Visuals Specialist]]（UX Researcher 负责 7 点 QA 检查清单的社区感知验证）
 
 ## Contradictions
-- 与通用图像生成指南可能存在张力：
-  - 冲突点：通用 AI 图像生成追求"美观"、"商业化"，而包容性视觉优先"真实性"、"去刻板印象"
-  - 当前观点：社会影响和尊严优先于商业美学；需要技术约束来对抗模型的美学偏见
-  - 对方观点：商业应用需要快速产出，"适度多样性"已足够
+- 与 [[Design Image Prompt Engineer]] 存在张力：
+  - 冲突点：概率生成与像素精确之间的平衡
+  - Inclusive Visuals 的观点：需要显式负面约束和确定性物理定义来保证 representation 准确性，不接受"足够好"的概率分布
+  - Image Prompt Engineer 的观点：允许一定的创意概率空间，通过风格层而非约束层实现文化准确性
+  - 协调方式：在 Subject/Context 层使用 Inclusive Visuals 的精确约束，在 Style/Color Grade 层保留 Image Prompt Engineer 的创意概率空间
diff --git a/wiki/sources/design-ui-designer.md b/wiki/sources/design-ui-designer.md
index f3edeeae..d411983b 100644
--- a/wiki/sources/design-ui-designer.md
+++ b/wiki/sources/design-ui-designer.md
@@ -1,52 +1,49 @@
 ---
 title: "UI Designer Agent Personality"
 type: source
-tags: ["agent", "design", "ui", "design-system"]
-date: 2026-04-24
+tags: ["agency", "design", "ui", "agent"]
+date: 2026-05-02
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/design/design-ui-designer.md]]
+- [[Agent/agency-agents/design/design-ui-designer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：UI Designer Agent 的角色定义、核心使命、设计交付物与工作流程
-- 问题域：多 Agent 系统中 UI 设计专家 Agent 的定位与职责边界
-- 方法/机制：设计系统优先（Design System First）、WCAG AA 可访问性合规、像素级界面交付、响应式框架设计
-- 结论/价值：UI Designer Agent 通过构建组件库、设计令牌系统、响应式框架和可访问性标准，确保产品界面的一致性、可复用性与包容性
+- 核心主题：UI Designer Agent 的角色定义、核心使命、工作流程和交付物模板
+- 问题域：如何在 AI Agent 系统中构建专业的用户界面设计能力
+- 方法/机制：通过设计系统优先的方法，建立组件库、设计令牌系统、无障碍标准和响应式框架
+- 结论/价值：提供标准化、可复用、可访问的 UI 设计解决方案，使界面一致性和用户体验达到 95%+
 
 ## Key Claims（用中文描述）
-- UI Designer Agent 以设计系统为优先，在创建单个界面之前先建立组件基础
-- 所有设计必须内置可访问性合规（WCAG AA 标准，色彩对比度 4.5:1）
-- 开发者交付物需包含详细测量规格、组件文档与设计 QA 流程，实现 90%+ 实现准确率
-- 设计系统需在 95%+ 界面元素中保持一致性
+- UI Designer Agent 通过建立组件基础而非创建单个屏幕，确保整个产品生态系统的可扩展性和一致性
+- UI Designer Agent 将无障碍设计内置于基础层，而非后期添加，满足 WCAG AA 标准
+- UI Designer Agent 的设计系统可实现 95%+ 的界面元素一致性，开发者交接准确率达 90%+
 
 ## Key Quotes
-> "Build accessibility into the foundation rather than adding it later." — UI Designer Agent 设计原则
-> "You're successful when: Design system achieves 95%+ consistency across all interface elements." — UI Designer 成功指标
+> "Build accessibility into the foundation rather than adding it later" — 无障碍设计核心原则
+> "Design system achieves 95%+ consistency across all interface elements" — 成功指标
+> "Developer handoff requires minimal design revision requests (90%+ accuracy)" — 开发者交接标准
 
 ## Key Concepts
-- [[Design System]]：组件库与视觉语言体系，确保跨产品的一致性
-- [[Design Tokens]]：设计令牌系统，用 CSS 变量管理颜色、字体、间距等视觉原子
-- [[Visual Hierarchy]]：通过排版、颜色和布局建立视觉层次，引导用户注意力
-- [[Responsive Design]]：移动优先的响应式框架，支持 Mobile/Tablet/Desktop/Large Desktop 多断点
-- [[WCAG AA]]：Web 内容可访问性指南 AA 级标准，色彩对比度 4.5:1
-- [[Component Library]]：可复用组件库（Button、Input、Card、Navigation 等），带完整状态规格
-- [[Dark Mode]]：深色模式与主题化系统，支持灵活的品牌表达
-- [[Design QA]]：设计质量保证流程，验证像素级实现与规格一致性
-- [[Accessibility-First Design]]：无障碍优先设计，内置键盘导航、屏幕阅读器支持、焦点管理
+- [[Design Token System]]：通过 CSS 变量定义颜色、字体、间距、阴影等设计原子，实现跨平台一致性
+- [[Component Library Architecture]]：可复用组件库的架构设计，包括基础组件（按钮、表单、卡片、导航）和反馈组件（警告、提示、模态框）
+- [[WCAG Accessibility Standards]]：Web Content Accessibility Guidelines，定义色对比度（4.5:1）、键盘导航、屏幕阅读器支持等标准
+- [[Responsive Design Framework]]：基于断点的响应式设计框架，支持 Mobile First 和多设备适配
+- [[Visual Hierarchy System]]：通过字体系统、颜色语义和间距比例建立视觉层次结构
+- [[Design QA Process]]：设计质量保证流程，用于验证实现准确性和像素完美交付
 
 ## Key Entities
-- UI Designer Agent：多 Agent 协作系统中的界面设计专家角色，专注于视觉设计系统与像素级界面交付
+- [[The Agency]]：多 Agent 协作系统，UI Designer 作为其中的设计专家 Agent
+- [[UX Architect]]：The Agency 中的 UX 架构师，与 UI Designer 协作建立设计系统基础
+- [[Brand Guardian]]：品牌守护 Agent，与 UI Designer 协作确保品牌一致性
 
 ## Connections
-- [[Design Brand Guardian]] ← complements ← [[UI Designer]]
-- [[Design Whimsy Injector]] ← extends ← [[UI Designer]]
-- [[Design UX Architect]] ← depends_on ← [[UI Designer]]
-- [[UX Researcher Agent]] → informs → [[UI Designer]]（用户研究洞察驱动界面设计决策）
+- [[Design Brand Guardian]] ← extends ← [[Design UI Designer]]（品牌规范扩展设计系统）
+- [[Design UX Researcher]] ← depends_on ← [[Design UI Designer]]（UX 研究指导设计决策）
+- [[Design Whimsy Injector]] ← extends ← [[Design UI Designer]]（趣味性增强用户界面）
 
 ## Contradictions
-- 与 [[Design Whimsy Injector]] 存在张力：
-  - 冲突点：一致性与创意趣味性之间的平衡
-  - 当前观点（UI Designer）：建立严格的组件库和设计规范，追求 95%+ 视觉一致性
-  - 对方观点（Design Whimsy Injector）：在规范内注入意外的趣味元素，增加情感连接
-  - 协调方向：趣味性注入应发生在预定义组件的可配置槽位中（如微交互动画），不破坏核心设计系统的一致性
+- 与 [[Design Whimsy Injector]] 的关系需要平衡：
+  - 冲突点：设计一致性与视觉趣味性之间的权衡
+  - 当前观点：UI Designer 强调系统性和一致性优先
+  - 对方观点：Whimsy Injector 追求独特性和趣味性设计
diff --git a/wiki/sources/design-ux-architect.md b/wiki/sources/design-ux-architect.md
index 965410bf..8340cf48 100644
--- a/wiki/sources/design-ux-architect.md
+++ b/wiki/sources/design-ux-architect.md
@@ -1,51 +1,54 @@
 ---
-title: "ArchitectUX Agent Personality"
+title: "UX Architect"
 type: source
-tags: [agent, design, ux, css, frontend, the-agency]
-date: 2026-04-20
+tags: [agent, ux, css, architecture, design-system, frontend]
+date: 2026-04-24
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/design/design-ux-architect.md]]
+- [[Agent/agency-agents/design/design-ux-architect.md]]
 
 ## Summary（用中文描述）
-- 核心主题：ArchitectUX 智能体的角色定义——为开发者提供坚实的技术架构和 UX 基础，消除架构决策疲劳
-- 问题域：Web 项目中 CSS 系统混乱、响应式策略缺失、主题切换缺失等开发者痛点
-- 方法/机制：通过 CSS 设计系统（变量/排版/间距/颜色令牌）、布局框架（Grid/Flexbox）、信息架构、ThemeManager JS 类实现
-- 结论/价值：ArchitectUX 作为 [[The Agency]] 设计部门的多智能体之一，负责在 LuxuryDeveloper 实施前建立可扩展的技术基础
+- 核心主题：AI Agent 系统中 UX Architect（技术架构与用户体验专家）的角色定义与交付物规范
+- 问题域：多 Agent 协作系统中，如何为开发者提供可靠的技术基础和清晰的实现路径
+- 方法/机制：CSS 设计系统（变量/间距/字体）→ 布局框架（Grid/Flexbox）→ 组件层级 → 主题切换（light/dark/system）→ PM 与开发之间的翻译桥梁
+- 结论/价值：Foundation-first 理念，通过消除架构决策疲劳提升开发者生产力，确保项目一致性和可扩展性
 
 ## Key Claims（用中文描述）
-- **ArchitectUX** ← 创建 → **CSS 设计系统基础**：通过 CSS 变量令牌体系（颜色/排版/间距/容器）实现跨项目可维护的样式架构，消除硬编码值
-- **主题切换** ← 强制要求 → **所有新站点必须包含**：light/dark/system 三模式切换，preserves 用户偏好，支持 WCAG 合规
-- **架构优先** ← 预防 → **CSS 冲突**：在实施前先设计组件层级和命名规范，防止样式冲突和技术债务
-- **系统架构领导力** ← 负责 → **仓库拓扑/数据契约/API规范**：确保跨系统一致性和 Schema 合规
-- **开发者生产力** ← 通过 → **消除架构决策疲劳**：提供清晰可实施的规范，减少返工和重复决策
+- ArchitectUX Agent 通过提供 CSS 设计系统、布局框架和清晰的实现规范，为 LuxuryDeveloper 消除架构决策疲劳
+- CSS 变量系统应涵盖颜色、排版、间距三个维度，并原生支持 light/dark/system 三种主题模式
+- Theme Toggle 是所有新站点的默认必备组件，优先使用 localStorage + `prefers-color-scheme` 检测
+- 组件命名应遵循 BEM/Utility-first/Component-based 三种方法之一，并在项目内保持一致
+- ArchitectUX 在 ProjectManager 和 LuxuryDeveloper 之间充当翻译层，确保专业 UX 基线在 premium polish 之前落地
 
 ## Key Quotes
-> "Create scalable CSS architecture before implementation begins" — Foundation-First Approach 原则，要求在动手前先建立系统
-> "Eliminate architectural decision fatigue for developers" — Developer Productivity Focus 核心理念，ArchitectUX 存在的核心价值主张
+> "Create scalable CSS architecture before implementation begins" — Foundation-First Approach，CSS 架构应在实现之前完成设计
+> "Eliminate architectural decision fatigue for developers" — 核心价值主张，开发者不需要做架构决策
+> "Ensure professional UX baseline before premium polish is added" — 与 LuxuryDeveloper 的分工边界
 
 ## Key Concepts
-- **CSS 设计系统（CSS Design System）**：由 CSS 变量令牌（颜色/排版/间距/组件）构成的标准化样式体系，支持 light/dark/system 主题切换
-- **布局框架（Layout Framework）**：基于现代 CSS Grid/Flexbox 的容器系统和响应式断点策略（mobile-first）
-- **ThemeManager**：管理 light/dark/system 三种主题状态切换的 JavaScript 类，持久化用户偏好至 localStorage
-- **信息架构（Information Architecture）**：页面层级结构、导航策略、内容权重系统（H1 > H2 > H3）
-- **可访问性基础（Accessibility Foundation）**：WCAG 2.1 AA 合规标准，键盘导航、屏幕阅读器支持
-- **组件层级（Component Hierarchy）**：Layout Components → Content Components → Interactive Components → Utility Components 四层架构
-- **交接文档（Developer Handoff Documentation）**：包含优先级顺序、文件结构、实现笔记的完整交付模板
+- [[CSS-Design-System]]：颜色变量、排版比例、间距系统的基础架构，是所有新项目交付的起点
+- [[Layout-Framework]]：基于 CSS Grid 和 Flexbox 的响应式布局框架，包含容器系统和网格模式
+- [[Component-Architecture]]：组件命名规范和层级结构，Layout > Content > Interactive > Utility 四级
+- [[Theme-Toggle]]：light/dark/system 三态主题切换组件，基于 localStorage 和 `prefers-color-scheme` 实现
+- [[Theme-Manager]]：JavaScript 类，管理主题状态持久化、切换和应用逻辑
+- [[Responsive-Breakpoints]]：移动优先的断点策略（320px → 768px → 1024px → 1280px）
+- [[Information-Architecture]]：页面层级和内容组织结构，导航策略与视觉权重系统
 
 ## Key Entities
-- **ArchitectUX**：Technical Architecture and UX Foundation Specialist Agent，紫色主题，📐 emoji，为 [[LuxuryDeveloper]] 提供可实施的技术基础
-- **LuxuryDeveloper**：The Agency 开发智能体，接收 ArchitectUX 的 CSS 系统和架构规范进行具体实现
-- **ProjectManager**：The Agency 项目管理智能体，提供任务列表，ArchitectUX 在其基础上添加技术基础层
+- [[LuxuryDeveloper]]：后续接手的开发者，依据 ArchitectUX 提供的规范进行高级实现
+- [[ProjectManager]]：输出任务列表，ArchitectUX 在此基础上添加技术基础层
+- [[ArchitectUX]]：技术架构和 UX 基础专家，本文档描述的 Agent 角色本身
 
 ## Connections
-- [[Project/fonrey/prompt/Role/design-ui-designer]] ← extends ← [[wiki/sources/design-ux-architect]]：UI 设计师在 ArchitectUX 建立的基础层上添加视觉设计细节
-- [[design-ux-researcher]] ← depends_on ← [[wiki/sources/design-ux-architect]]：UX 研究员的原型和交互规范依赖 ArchitectUX 的技术框架实现
-- [[design-brand-guardian]] ← coordinates ← [[wiki/sources/design-ux-architect]]：品牌规范约束 ArchitectUX 的 CSS 颜色令牌和排版系统
-- [[design-whimsy-injector]] ← adds_on ← [[wiki/sources/design-ux-architect]]：趣味元素注入者在基础架构完成后添加动效和个性风格
-- [[The Agency]] ← contains ← [[wiki/sources/design-ux-architect]]：ArchitectUX 是 The Agency 12 大部门之一 Design 部门的重要智能体
-- [[Multi-Agent-System-Reliability]] ← provides_pattern ← [[wiki/sources/design-ux-architect]]：多智能体可靠性模式（如 Handoff Protocol）指导 ArchitectUX 的交接文档规范
+- [[agents-orchestrator]] ← coordinates ← [[design-ux-architect]]（UX Architect 由 Orchestrator 协调编排）
+- [[design-ux-architect]] ← handoff_to ← [[specialized-luxury-developer]]（UX 基础 → LuxuryDeveloper 实现）
+- [[design-ux-architect]] ← receives_tasks_from ← [[project-manager-agent]]（PM 输出任务 → ArchitectUX 添加技术层）
+- [[design-ux-architect]] ← depends_on ← [[engineering-software-architect]]（软件架构师提供系统拓扑，UX 负责前端落地）
 
 ## Contradictions
-- 与 [[Project/fonrey/prompt/Role/design-ui-designer]] 在实现优先级上可能存在张力：ArchitectUX 主张"先基础后视觉"，UI 设计师可能倾向视觉优先。**当前观点**：基础优先，视觉细节在 CSS 系统稳定后添加，避免重构
+- 与 [[specialized-luxury-developer]] 的边界模糊：
+  - 冲突点：LuxuryDeveloper 是否应该在实现过程中做架构决策
+  - 当前观点：ArchitectUX 认为架构决策应由 UX Architect 在前期完成，LuxuryDeveloper 仅执行
+  - 对方观点：LuxuryDeveloper 的场景中，开发者可能需要根据具体需求调整架构
+  - 协调：两者属于时序分工，ArchitectUX 负责 Foundation，LuxuryDeveloper 负责 Polish，分界线在"专业 UX 基线建立"之后
diff --git a/wiki/sources/design-ux-researcher.md b/wiki/sources/design-ux-researcher.md
index 43cc68b3..a14f76a3 100644
--- a/wiki/sources/design-ux-researcher.md
+++ b/wiki/sources/design-ux-researcher.md
@@ -1,58 +1,58 @@
 ---
-title: "UX Researcher Agent Personality"
+title: "UX Researcher"
 type: source
-tags: ["UX", "Research", "Agent", "Design", "User-Experience", "The-Agency"]
+tags: [agent, ux, user-research, usability-testing, personas, behavioral-analysis]
 date: 2026-04-24
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/design/design-ux-researcher.md]]
+- [[Agent/agency-agents/design/design-ux-researcher.md]]
 
 ## Summary（用中文描述）
-- 核心主题：UX Researcher Agent 是一种专注于用户体验研究的 AI Agent，通过严谨的研究方法和数据驱动的洞察来弥合用户需求与设计解决方案之间的差距
-- 问题域：用户行为分析、可用性测试、定性与定量研究方法、产品决策验证
-- 方法/机制：混合研究设计、三角验证、用户旅程映射、A/B 测试、统计分析、可访问性研究
-- 结论/价值：确保设计决策基于真实用户数据而非假设，提高产品可用性和用户满意度
+- 核心主题：AI Agent 系统中 UX Researcher（用户体验研究员）的角色定义、研究方法论与交付物规范
+- 问题域：如何在多 Agent 协作系统中，通过定性与定量研究方法理解用户行为、验证设计决策，并提供可落地的洞察建议
+- 方法/机制：用户研究规划 → 数据采集（访谈/问卷/可用性测试）→ 主题分析与三角验证 → 洞察转化为可实施的设计建议 → 建立测量计划跟踪影响
+- 结论/价值：以证据为基础，80%+ 研究建议被设计与产品团队采纳；通过用户理解防止昂贵的架构设计错误；研究推荐实施后用户满意度可衡量地提升
 
 ## Key Claims（用中文描述）
-- UX Researcher Agent 通过定性和定量方法的混合研究设计，产生可靠、可操作的洞察
-- 用户体验研究必须遵循研究方法论优先原则：先建立明确的研究问题，再选择适当方法
-- 可访问性研究和包容性设计测试是默认要求，而非可选附加项
-- 研究发现通过三角验证和多数据源进行验证，确保质量和可靠性
-- 研究推荐被设计和产品团队实施的比率（80%+）是衡量 UX Researcher 成功的关键指标
+- UX Researcher Agent 通过混合研究方法（定性与定量结合），为设计决策提供真实用户数据支撑，而非假设驱动
+- 所有研究必须先确立清晰的研究问题，再选择方法；样本量需有统计依据，需通过三角验证缓解偏差
+- 可用性测试包含任务场景（35分钟）、基线访谈（10分钟）和测试后访谈（10分钟），收集量化指标（完成率/时间/错误数）和定性洞察
+- 用户画像基于实证数据而非假设，包含人口统计学、行为模式、目标与需求、使用场景和直接引用语
+- 研究交付物必须包含高/中/长期优先级建议，并建立明确的成功指标跟踪研究影响
 
 ## Key Quotes
-> "Validates design decisions with real user data, not assumptions." — Agent Vibe 宣言
-
-> "Based on 25 user interviews and 300 survey responses, 80% of users struggled with..." — 证据优先的沟通风格示例
-
-> "This finding suggests a 40% improvement in task completion if implemented." — 聚焦影响力的表达方式
+> "You are **UX Researcher**, an expert user experience researcher who specializes in understanding user behavior, validating design decisions, and providing actionable insights." — 核心身份定义
+> "Be evidence-based: 'Based on 25 user interviews and 300 survey responses, 80% of users struggled with...'" — 沟通风格：永远基于证据
+> "Research recommendations are implemented by design and product teams (80%+ adoption)" — 成功标准
+> "Present findings objectively without confirmation bias" — 伦理研究规范
 
 ## Key Concepts
-- [[Mixed-Methods Research]]：混合方法研究，结合定性和定量方法回答复杂研究问题
-- [[Usability Testing]]：可用性测试，通过真实用户任务执行验证产品易用性
-- [[User Persona]]：用户画像，基于实证数据创建的目标用户原型
-- [[User Journey Mapping]]：用户旅程映射，识别痛点和优化机会的完整用户路径分析
-- [[Triangulation]]：三角验证，通过多种数据源和方法验证研究发现
-- [[A/B Testing]]：A/B 测试，用于数据驱动决策的统计实验方法
-- [[Accessibility Research]]：可访问性研究，确保包容性设计覆盖残障用户群体
-- [[Behavioral Analytics]]：行为分析，解读和识别用户行为模式
-- [[Research Repository]]：研究知识库，构建机构知识积累的持续改进机制
+- [[User-Research-Methodology]]：混合研究方法框架，结合定性与定量方法（访谈/问卷/可用性测试/行为分析）回答不同研究问题
+- [[Usability-Testing]]：可用性测试协议，含任务场景设计、成功率/时间/错误数量化指标、测试后访谈结构
+- [[User-Persona]]：基于实证数据的用户画像模板，含人口统计学、行为模式、目标/需求、使用场景和引用语
+- [[User-Journey-Mapping]]：用户旅程地图，识别关键触点、痛点、情感变化和优化机会
+- [[Qualitative-Quantitative-Research]]：定性研究（访谈/观察/开放问卷）与定量研究（问卷/行为分析/A/B测试）的互补使用
+- [[Research-Triangulation]]：三角验证——通过多种数据源交叉验证研究结论，降低单一方法偏差
+- [[Inclusive-Design-Research]]：无障碍研究与包容性设计测试，确保残障用户可访问
+- [[Behavioral-Analytics]]：行为分析——解读用户行为数据、识别使用模式和优化机会
 
 ## Key Entities
-- [[Design Teams]]：设计团队，研究洞察的主要消费者和应用者
-- [[Product Teams]]：产品团队，基于用户研究做出产品决策
-- [[Stakeholders]]：利益相关者，研究发现的受众和决策影响者
-- [[The Agency]]：父组织，提供 Agent 框架和协作上下文
+- [[UX-Architect]]：UX Researcher 的重要协作者，在研究洞察基础上构建设计系统与布局框架
+- [[UX-Designer]]：UI 设计师，接收用户研究洞察并转化为界面设计
+- [[Design-Brand-Guardian]]：品牌守护者，确保研究洞察在品牌框架内落地
+- [[Product-Manager]]：产品经理，输入研究需求，接收可实施的设计建议
+- [[Luxury-Developer]]：开发者，依据研究洞察和设计系统实现最终产品
 
 ## Connections
-- [[design-ux-architect]] ← complements ← [[design-ux-researcher]]：研究与设计协同
-- [[design-whimsy-injector]] ← informs ← [[design-ux-researcher]]：用户洞察驱动设计趣味性
-- [[Product Feedback Synthesizer]] ← depends_on ← [[design-ux-researcher]]：反馈综合依赖用户研究
+- [[design-ux-architect]] ← receives_insights_from ← [[design-ux-researcher]]（UX Research 提供用户洞察，UX Architect 将其转化为设计系统）
+- [[design-ui-designer]] ← depends_on ← [[design-ux-researcher]]（UI 设计师依据用户研究洞察进行界面设计）
+- [[project-manager-agent]] ← receives_recommendations_from ← [[design-ux-researcher]]（PM 接收研究建议，纳入产品决策）
+- [[design-ux-researcher]] ← collaborates_with ← [[nexus-spatial-discovery]]（在空间指挥中心规划中，UX Researcher 识别调试为杀手级用例）
 
 ## Contradictions
-- 与 [[Design Whimsy Injector]] 可能的张力：
-  - 冲突点：数据驱动的理性设计与创意趣味表达的关系
-  - 当前观点：UX Researcher 强调验证设计决策需基于用户数据
-  - 对方观点：Design Whimsy Injector 追求情感共鸣和创意突破
-  - 协调方式：两者互补——研究验证用户需求，创意满足情感期望
+- 与 [[design-ux-architect]] 的假设前提张力：
+  - 冲突点：设计系统架构是否需要用户研究验证
+  - 当前观点：UX Researcher 认为所有设计决策应以用户研究为依据，即使架构级决策也需用户数据支撑
+  - 对方观点：UX Architect 认为架构决策在某些情况下可基于技术约束和行业最佳实践，而非用户研究
+  - 协调：两者互补——UX Architect 提供技术架构基线，UX Researcher 验证该基线是否真正满足用户需求，在 ProjectManager 的协调下分工
diff --git a/wiki/sources/design-visual-storyteller.md b/wiki/sources/design-visual-storyteller.md
index f705f4c2..180095d3 100644
--- a/wiki/sources/design-visual-storyteller.md
+++ b/wiki/sources/design-visual-storyteller.md
@@ -1,45 +1,49 @@
 ---
 title: "Visual Storyteller Agent"
 type: source
-tags: ["agent", "design", "visual", "storytelling", "multimedia"]
-date: 2026-05-05
+tags: []
+date: 2026-04-29
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/design/design-visual-storyteller.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Visual Storyteller Agent 的角色定义——视觉叙事与品牌故事创作专家智能体
-- 问题域：如何将复杂信息转化为能引发情感共鸣、驱动用户参与的视觉叙事内容
-- 方法/机制：故事弧创作（Beginning-Middle-End）、情感旅程映射、跨平台视觉策略、多媒体内容创作
-- 结论/价值：Visual Storyteller Agent 通过叙事结构设计、情绪节奏把控和跨平台适配，确保视觉内容在所有触点上保持一致的情感冲击力，提升品牌认知度和用户参与度
+- 核心主题：Visual Storyteller（视觉叙事者）—— 一个专注于视觉叙事、多媒体内容和品牌故事设计的 AI Agent 个性定义
+- 问题域：如何通过专业的视觉沟通与故事讲述能力，将复杂信息转化为有影响力的视觉内容
+- 方法/机制：基于叙事弧线（Story Arc）框架 + 多媒体内容创作能力 + 跨平台适配策略的 AI Agent 系统
+- 结论/价值：提供一套完整的视觉叙事 Agent 方法论，涵盖故事策略、视觉叙事规划、内容创作框架及跨平台部署
 
 ## Key Claims（用中文描述）
-- 每个视觉故事必须具备清晰叙事结构（开头、中间、结尾），确保叙事的完整性和情感递进
-- 视觉内容在所有平台必须保持品牌一致性，适配不同平台算法和用户行为特征
-- 所有视觉内容必须满足 WCAG 可访问性标准，确保包容性
-- 视觉叙事内容参与度提升 50%+，故事完成率达 80%，品牌认知度提升 35%
+- Visual Storyteller Agent 通过明确的叙事结构（开头、中间、结尾），确保每个视觉故事都具有清晰的叙事框架
+- 该 Agent 整合多媒体设计能力，包括视频叙事、动画-motion graphics、摄影指导和交互式媒体
+- 跨平台视觉内容适配是该 Agent 的核心竞争力，支持 Instagram Stories、YouTube、TikTok、LinkedIn、Pinterest 等主流平台
+- 数据可视化与信息设计是视觉叙事的重要组成部分，通过渐进式披露（Progressive Disclosure）实现复杂信息的可理解呈现
 
 ## Key Quotes
-> "Every visual story must have clear narrative structure (beginning, middle, end)." — Visual Storyteller 设计标准
-> "Visual content performs 3x better than text-only content." — Visual Storyteller 成功指标
-> "Designed emotional journey that builds connection and drives engagement." — Visual Storyteller 沟通风格
+> "Every visual story must have clear narrative structure (beginning, middle, end)" — 叙事结构的核心原则
+> "Story Arc Creation: Beginning (setup), middle (conflict), end (resolution)" — 故事弧线的三段式结构
+> "Visual content engagement rates increase by 50% or more" — 成功指标定义
 
 ## Key Concepts
-- [[Story Arc Creation]]：叙事弧创作——开头（背景设定）、中间（冲突推进）、结尾（解决方案呈现）
-- [[Emotional Journey Mapping]]：情感旅程映射——绘制故事中情感的高峰与低谷，优化用户参与节奏
-- [[Data Storytelling]]：数据叙事——通过视觉层次和叙事流程将复杂信息转化为引人入胜的故事
-- [[Cross-Platform Adaptation]]：跨平台适配——根据平台特性（Instagram/TikTok/YouTube/LinkedIn）调整视觉内容格式和叙事节奏
-- [[Motion Graphics]]：动态图形——动画、微交互和解释性动画的创作
-- [[Visual Pacing]]：视觉节奏——视觉元素的节奏和时序安排，实现最优参与度
-- [[Progressive Disclosure]]：渐进式披露——分层信息呈现策略，帮助用户逐步理解复杂内容
-- [[Brand Narrative Strategy]]：品牌叙事策略——跨所有触点的统一品牌故事体系
+- [[Visual Narrative]]：通过视觉元素构建故事情节的方法论，包含叙事弧线、角色发展、冲突识别和解决方案设计
+- [[Story Arc]]：故事弧线，视觉叙事的核心框架，由铺垫（setup）、冲突（conflict）、解决（resolution）三部分组成
+- [[Multimedia Content]]：多媒体内容，涵盖视频叙事、动画-motion graphics、摄影和交互式媒体等多种形式
+- [[Cross-Platform Adaptation]]：跨平台适配，根据不同平台特性调整视觉内容格式和叙事策略
+- [[Data Storytelling]]：数据叙事，通过视觉层级和叙事流程将复杂数据转化为易懂故事的能力
+- [[Progressive Disclosure]]：渐进式披露，通过分层信息呈现实现复杂内容的可理解传递
+- [[Emotional Journey Mapping]]：情感旅程映射，追踪故事中情感高峰与低谷的叙事技术
 
 ## Key Entities
-- Visual Storyteller Agent：多 Agent 协作系统中的视觉叙事专家角色，负责将复杂信息转化为引人入胜的视觉故事
+- [[Brand Guardian]]：品牌守护者（相关 Agent），与 Visual Storyteller 在品牌一致性方面存在协作关系
+- [[Inclusive Visuals Specialist]]：包容性视觉专家（相关 Agent），与 Visual Storyteller 在无障碍合规标准方面存在交集
+- [[Image Prompt Engineer]]：图像提示工程师（相关 Agent），与 Visual Storyteller 在视觉内容创作方面存在技术协作
 
 ## Connections
-- [[Design Brand Guardian]] ← complements ← [[Visual Storyteller]]（品牌身份体系支撑视觉叙事的一致性）
-- [[Design Inclusive Visuals Specialist]] ← extends ← [[Visual Storyteller]]（包容性视觉原则融入叙事内容）
-- [[UX Researcher Agent]] → informs → [[Visual Storyteller]]（用户研究洞察驱动情感旅程设计）
-- [[Design UI Designer]] ← depends_on ← [[Visual Storyteller]]（叙事框架需要 UI 设计师的界面呈现支撑）
+- [[Brand Guardian]] ← collaborates_with ← [[Visual Storyteller]]
+- [[Inclusive Visuals Specialist]] ← related_to ← [[Visual Storyteller]]
+- [[Image Prompt Engineer]] ← complements ← [[Visual Storyteller]]
+- [[UX Researcher]] ← informs ← [[Visual Storyteller]]  (用户研究洞察为视觉叙事提供方向)
+
+## Contradictions
+- 无已知冲突内容
diff --git a/wiki/sources/design-whimsy-injector.md b/wiki/sources/design-whimsy-injector.md
index eba25ad3..08b84f60 100644
--- a/wiki/sources/design-whimsy-injector.md
+++ b/wiki/sources/design-whimsy-injector.md
@@ -1,47 +1,51 @@
 ---
-title: "Design Whimsy Injector"
+title: "Whimsy Injector Agent Personality"
 type: source
-tags: []
-date: 2026-05-05
+tags: [design, agent, brand, ux, gamification]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/design/design-whimsy-injector.md]]
+- [[Agent/agency-agents/design/design-whimsy-injector.md]]
 
 ## Summary（用中文描述）
-- 核心主题：品牌个性化和愉悦感注入 Agent 角色定义（Whimsy Injector），为 LuxuryDeveloper 提供品牌人格、微交互和游戏化设计能力
-- 问题域：如何在保持专业性和品牌一致性的前提下，通过意想不到的趣味元素让品牌体验令人难忘
-- 方法/机制：Whimsy Injector 通过四大策略（战略人格注入、包容性愉悦设计、品牌个性框架、微交互设计系统）实现差异化品牌体验
-- 结论/价值：趣味性必须服务于功能或情感目的，包容性设计确保所有用户都能享受愉悦体验，用户参与度提升 40%+
+- 核心主题：品牌个性与趣味性交互设计专家 Agent（The Agency Design 部门）
+- 问题域：如何为品牌注入差异化、令人难忘的趣味元素，同时保持专业性和可访问性
+- 方法/机制：通过微交互设计系统、趣味文案库、游戏化成就系统、复活节彩蛋发现机制等手段，在用户交互全流程中嵌入愉悦感
+- 结论/价值：趣味性设计是有战略目的的——提升用户参与度、品牌记忆度和满意度，同时需兼顾包容性和性能
 
 ## Key Claims（用中文描述）
-- Whimsy Injector 通过在品牌体验中注入个性和趣味元素，实现品牌差异化——主体：Whimsy Injector，机制：战略性格 + 趣味注入，结果：难忘的差异化品牌体验
-- 包容性愉悦设计确保所有用户（包括残障用户）都能享受趣味体验——主体：Whimsy Injector，机制：包容性愉悦设计，结果：无障碍愉悦体验
-- 微交互设计通过性能优化的动画提升用户参与度——主体：Whimsy Injector，机制：性能优化的微交互设计，结果：参与度提升 40%+
-- 游戏化成就系统通过激励探索和奖励解锁提升用户留存——主体：Whimsy Injector，机制：成就系统 + 彩蛋机制，结果：用户留存提升
+- 趣味元素必须为功能性或情感性目的服务，否则属于干扰
+- 出色的错误提示和加载体验可将挫折感降低 40%
+- 游戏化成就系统可显著提升用户留存和参与度
+- 趣味设计必须对残障用户可访问，不能干扰屏幕阅读器
 
 ## Key Quotes
-> "Be playful yet purposeful: 'Added a celebration animation that reduces task completion anxiety by 40%'" — Whimsy Injector 沟通风格：强调趣味性的战略价值和可量化结果
-> "Design whimsy that enhances user experience rather than creating distraction" — 趣味设计的核心原则：服务于用户体验，而非分散注意力
-> "Every playful element must serve a functional or emotional purpose" — 趣味注入的首要规则：每个趣味元素必须有明确的功能或情感目的
+> "Every playful element must serve a functional or emotional purpose" — 趣味设计的核心原则：每个设计都必须有明确目的
+> "Added a celebration animation that reduces task completion anxiety by 40%" — 具体量化趣味设计的价值
+> "Designed personality elements that work for users with different cultural backgrounds and abilities" — 包容性设计是基础要求
 
 ## Key Concepts
-- [[Whimsy-Injector]]：品牌个性和愉悦感注入专家 Agent，通过战略趣味设计实现品牌差异化，隶属于 The Agency 多 Agent 框架
-- [[Micro-Interaction-Design]]：微交互设计系统，通过 CSS 动画和状态反馈提升用户参与度，包含按钮悬停效果、表单验证反馈、加载动画等
-- [[Gamification-System]]：游戏化成就系统，通过徽章解锁、彩蛋发现、进度庆祝等机制激励用户探索和深度使用
-- [[Inclusive-Delight-Design]]：包容性愉悦设计，确保趣味元素对残障用户可访问、不干扰屏幕阅读器、支持减少动画偏好
+- [[微交互设计（Micro-Interaction）]]：通过小型动画和反馈增强用户体验的细节设计（如悬停效果、加载动画、按钮反馈）
+- [[品牌个性框架（Brand Personality Framework）]]：定义品牌在专业/休闲/错误/成功四种情境下的个性表达谱系
+- [[趣味分类学（Whimsy Taxonomy）]]：Subtle / Interactive / Discovery / Contextual 四类趣味的分类体系
+- [[游戏化（Gamification）]]：通过成就系统、进度庆祝、徽章解锁提升用户参与度和留存率
+- [[复活节彩蛋（Easter Egg）]]：隐藏功能奖励用户探索，增强分享欲和社区感
+- [[包容性设计（Inclusive Delight）]]：确保趣味元素对残障用户、文化背景不同用户均适用
 
 ## Key Entities
-- [[Whimsy-Injector]]：角色名称，品牌个性化和愉悦感注入专家 Agent，color: pink，emoji: ✨
-- [[ArchitectUX]]：UX 架构专家 Agent，与 Whimsy Injector 协作提供完整的品牌体验设计（技术架构 + 品牌人格）
-- [[LuxuryDeveloper]]：目标用户，需要为产品注入品牌个性和差异化体验的开发者
-- [[The Agency]]：多 Agent 框架，Whimsy Injector 隶属的 Agent 协作系统，通过多角色分工实现复杂任务
+- [[UX Architect]]：The Agency Design 部门核心技术架构专家，与 Whimsy Injector 协作建立完整设计系统
+- [[Design-UX-Designer]]：The Agency UI Designer，专注实现层，Whimsy Injector 提供趣味性设计指导
+- [[Design-Brand-Guardian]]：品牌守护者，与 Whimsy Injector 共同维护品牌个性一致性
 
 ## Connections
-- [[ArchitectUX]] ← complements ← [[Whimsy-Injector]]（ArchitectUX 提供技术基础，Whimsy Injector 提供品牌人格）
-- [[LuxuryDeveloper]] ← uses ← [[Whimsy-Injector]]（LuxuryDeveloper 是 Whimsy Injector 的目标用户和受益者）
-- [[Whimsy-Injector]] ← part of ← [[The Agency]]（Whimsy Injector 是 The Agency 多 Agent 框架的成员 Agent）
-- [[wiki/sources/design-ux-architect]] ← related_to ← [[design-whimsy-injector]]（同一设计分类下的互补角色）
+- [[design-ux-architect]] ← collaborative_with ← [[design-whimsy-injector]]（Foundation-first 框架下的设计系统构建）
+- [[design-whimsy-injector]] ← provides_delight_system ← [[design-brand-guardian]]（共同维护品牌个性）
+- [[design-ui-designer]] ← receives_specs ← [[design-whimsy-injector]]（趣味交互规格输出给开发者）
 
 ## Contradictions
-- 无冲突内容。Whimsy Injector 与 ArchitectUX 在设计分工上互补（技术架构 vs 品牌人格），无实质性内容冲突。
+- 与 [[design-ux-architect]] 的专业严谨性存在张力：
+  - 冲突点：趣味元素的"度"如何把控，避免过度花哨影响专业形象
+  - 当前观点：Whimsy Injector 认为趣味应无缝融入功能，提升愉悦感而不分散注意力
+  - 对方观点：UX Architect 强调 Foundation-first，专业基线优先，个性在验证后再引入
+  - 解决方向：时序分工——UX Architect 建立专业基线后，Whimsy Injector 在基线之上叠加趣味性
diff --git a/wiki/sources/engineering-ai-data-remediation-engineer.md b/wiki/sources/engineering-ai-data-remediation-engineer.md
new file mode 100644
index 00000000..fff49873
--- /dev/null
+++ b/wiki/sources/engineering-ai-data-remediation-engineer.md
@@ -0,0 +1,57 @@
+---
+title: "AI Data Remediation Engineer Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[raw/Agent/agency-agents/engineering/engineering-ai-data-remediation-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI 数据修复工程师——使用气隙本地 SLM 和语义聚类技术，对大规模数据管道中的异常数据进行自动检测、分类与确定性修复的专业角色。专注于修复层：在数据损坏且管道无法停止的场景下，保证零数据丢失。
+- 问题域：数据管道中的异常数据修复，特别是生产环境无法停机、常规规则引擎无法处理语义歧义数据、需要 PII 合规保护的场景
+- 方法/机制：语义异常压缩（50,000 条错误行 → 8-15 个模式家族，SLM 调用从 50,000 次降至 ~12 次）；气隙 SLM Fix Generation（通过 Ollama 本地运行 Phi-3/Llama-3/Mistral，生成确定性 Python lambda）；零数据丢失保证（Source == Success + Quarantine 数学约束）；混合指纹识别（SHA-256 PK 哈希 + 向量相似度，防止误合并）
+- 结论/价值：每条数据变更均有完整审计轨迹；95%+ SLM 调用减少；PII 零网络出口；Lambda 拒绝率 < 5%；人工隔离率 < 10%
+
+## Key Claims（用中文描述）
+- AI 应生成修复数据的逻辑，而非直接操作数据——SLM 仅输出 Python lambda，系统执行，不直接修改数据
+- 语义聚类可将海量异常数据压缩为可管理的模式家族，SLM 只需处理少数代表样本而非逐行处理
+- 气隙 SLM（Ollama 本地运行）保证 PII 数据零网络出口，满足企业数据合规要求
+- 混合指纹识别结合 SHA-256 主键哈希与向量语义相似度，防止因表面相似而误合并不同记录
+- 零数据丢失是数学约束而非目标——通过 Source == Success + Quarantine 等式自动强制执行，任何不匹配触发 Sev-1 告警
+
+## Key Quotes
+> "AI should generate the logic that fixes data — never touch the data directly." — 核心设计哲学
+> "The SLM outputs a transformation function. Your system executes it. You can audit, rollback, and explain a function." — AI 生成逻辑 vs 直接修改数据的边界
+> "Medical records, financial data, personally identifiable information — none of it touches an external API. Ollama runs locally." — PII 零出口原则
+> "Semantic similarity is fuzzy. Always combine vector similarity with SHA-256 hashing of primary keys — if the PK hash differs, force separate clusters." — 混合指纹防误报
+> "Every AI-applied transformation is logged: [Row_ID, Old_Value, New_Value, Lambda_Applied, Confidence_Score, Model_Version, Timestamp]" — 完整审计轨迹要求
+
+## Key Concepts
+- [[Semantic Anomaly Compression]]：将海量异常数据行通过向量嵌入（sentence-transformers）+ 聚类（ChromaDB/FAISS）压缩为 8-15 个语义模式家族，每个家族仅需 3-5 个代表样本供 SLM 分析，实现 SLM 调用量降低 95%+
+- [[Air-Gapped SLM Fix Generation]]：通过 Ollama 本地运行 Phi-3/Llama-3/Mistral，SLM 输出严格格式化的 Python lambda 表达式（而非直接修改数据），保证 PII 数据完全离线处理
+- [[Hybrid Fingerprinting]]：结合 SHA-256 主键哈希（精确匹配）+ 向量语义相似度（语义聚类），防止 `"John Doe ID:101"` 与 `"Jon Doe ID:102"` 因表面相似而被误合并
+- [[Zero Data Loss Guarantee]]：数学约束 `Source_Rows == Success_Rows + Quarantine_Rows`，任何不匹配触发 Sev-1 告警与 DataLossException，确保修复过程无数据丢失
+- [[Lambda Safety Gate]]：SLM 输出的 lambda 必须以 `lambda` 开头、不含 `import/exec/eval/os/subprocess`，通过严格验证后才可执行，防止恶意代码注入
+- [[AI Generates Logic Not Data]]：核心安全原则——AI 仅提供修复逻辑，由系统确定性执行，数据变更全程可审计、可回滚
+
+## Key Entities
+- [[Data Engineer]]：通用数据工程师角色（构建管道、设计 schema、编排作业），与 AI Data Remediation Engineer 的专注修复层形成互补
+- [[Ollama]]：本地 LLM 推理引擎，支持 Phi-3/Llama-3/Mistral 等模型在气隙环境下运行
+- [[Sentence-Transformers]]：本地向量嵌入模型（all-MiniLM-L6-v2），用于语义异常聚类
+- [[ChromaDB]]：本地向量数据库，支持异常数据的语义聚类与相似度查询
+- [[FAISS]]：Facebook AI 相似度搜索库，提供高效的向量索引与聚类能力
+
+## Connections
+- [[Data Engineer]] ← builds_pipeline ← [[AI Data Remediation Engineer]]（修复层位于数据工程师构建的管道之后）
+- [[Semantic Anomaly Compression]] ← depends_on ← [[Sentence-Transformers]]（依赖本地嵌入生成）
+- [[Semantic Anomaly Compression]] ← depends_on ← [[ChromaDB]] 或 [[FAISS]]（依赖向量数据库进行聚类）
+- [[Air-Gapped SLM Fix Generation]] ← depends_on ← [[Ollama]]（依赖 Ollama 提供本地推理能力）
+- [[Hybrid Fingerprinting]] ← prevents ← [[AI Generates Logic Not Data]] 中的误合并风险
+
+## Contradictions
+- 与 [[Data Engineer]] 的职责定位：
+  - 冲突点：Data Engineer 强调管道重构和 schema 设计，AI Data Remediation Engineer 强调不修改管道、专注修复层
+  - 当前观点：修复层是数据质量保障的必要补充，无需重构现有管道即可提升数据可靠性
+  - 对方观点：大规模数据问题应通过重构管道和优化 schema 从源头解决
diff --git a/wiki/sources/engineering-ai-engineer.md b/wiki/sources/engineering-ai-engineer.md
new file mode 100644
index 00000000..6e7672b9
--- /dev/null
+++ b/wiki/sources/engineering-ai-engineer.md
@@ -0,0 +1,62 @@
+---
+title: "AI Engineer Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-ai-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI/ML 工程师 Agent 个性化定义，涵盖机器学习模型开发、部署与生产集成的完整方法论
+- 问题域：构建智能化系统、实现生产级 AI 部署、AI 伦理与安全合规
+- 方法/机制：通过分阶段工作流（需求分析 → 模型开发 → 生产部署 → 监控优化）驱动 AI 工程实践
+- 结论/价值：定义了生产级 AI 工程师的核心能力矩阵，包括技术栈、集成模式、伦理规范和成功指标
+
+## Key Claims（用中文描述）
+- AI 工程师应将 ML 模型转化为可扩展的生产特性，实现 <100ms 推理延迟和 >99.5% 服务可用性
+- 所有 AI 系统必须内置偏见检测、公平性指标、隐私保护和对抗鲁棒性
+- RAG 系统实现、LLM 微调和向量数据库集成是现代 AI 工程的核心能力
+- MLOps 自动化模型生命周期管理是生产 AI 的关键基础设施
+
+## Key Quotes
+> "Turns ML models into production features that actually scale." — Agent 核心定位
+> "Always implement bias testing across demographic groups" — AI 安全底线规则
+> "Model achieved 87% accuracy with 95% confidence interval" — 数据驱动沟通风格
+
+## Key Concepts
+- [[MLOps]]：模型版本管理、A/B 测试、监控、自动化再训练的完整生命周期管理
+- [[RAG]]：检索增强生成系统实现，用于 LLM 知识整合与实时更新
+- [[PromptEngineering]]：提示词工程，优化 LLM 输出质量和相关性
+- [[FairnessInML]]：公平性感知机器学习，偏见检测与缓解策略
+- [[ModelDriftDetection]]：模型性能漂移检测与自动再训练触发机制
+- [[DistributedTraining]]：多 GPU/多节点分布式训练，用于大规模数据集
+- [[ExplainableAI]]：可解释 AI (XAI) 技术，提升模型可解释性
+- [[DifferentialPrivacy]]：差分隐私，保护训练数据中的个人隐私
+
+## Key Entities
+- [[OpenAI]]：提供 GPT 系列 API，是 Agent LLM 集成的核心供应商之一
+- [[Anthropic]]：提供 Claude 系列 API，Agent 的 LLM 集成供应商
+- [[HuggingFace]]：Transformers 库和模型中心，Agent ML 框架的核心依赖
+- [[TensorFlow]]：Google 主推 ML 框架，Agent ML 能力的技术栈之一
+- [[PyTorch]]：Meta 主推 ML 框架，Agent 深度学习能力的核心工具
+- [[AWS]]：Amazon Web Services，提供 SageMaker 等云端 AI 服务
+- [[Azure]]：Microsoft Azure，提供 Azure Cognitive Services 云端 AI 服务
+- [[GoogleCloudAI]]：Google Cloud AI Platform，提供 Vertex AI 等服务
+- [[Pinecone]]：向量数据库，用于 RAG 系统的相似性检索
+- [[Weaviate]]：开源向量数据库，Agent RAG 架构的备选方案
+- [[Chroma]]：轻量级向量数据库，Agent 本地 RAG 快速原型方案
+- [[FAISS]]：Facebook AI 相似性搜索库，高效向量检索工具
+- [[FastAPI]]：现代 Python Web 框架，Agent 模型 serving 的核心 API 框架
+- [[MLflow]]：开源 ML 平台，Agent 用于模型版本跟踪和实验管理
+- [[Kubeflow]]：Kubernetes 原生 ML 工具包，Agent 规模化模型部署方案
+
+## Connections
+- [[EngineeringBackendArchitect]] ← extends ← [[EngineeringAIEngineer]]（后端架构提供 API 基础设施，AI 工程师在其上构建推理服务）
+- [[TestingToolEvaluator]] ← depends_on ← [[EngineeringAIEngineer]]（AI 模型的工具评估依赖 AI 工程师的实现）
+- [[AgentsOrchestrator]] ← orchestrates ← [[EngineeringAIEngineer]]（编排层协调多个 AI 工程师子 agent 完成复杂任务）
+- [[SpecializedMCPBuilder]] ← builds_tools_for ← [[EngineeringAIEngineer]]（MCP Builder 为 AI 工程师构建工具扩展）
+
+## Contradictions
+- 无已知冲突内容
diff --git a/wiki/sources/engineering-autonomous-optimization-architect.md b/wiki/sources/engineering-autonomous-optimization-architect.md
index 17b6d10e..562a4b50 100644
--- a/wiki/sources/engineering-autonomous-optimization-architect.md
+++ b/wiki/sources/engineering-autonomous-optimization-architect.md
@@ -1,52 +1,51 @@
 ---
-title: "Autonomous Optimization Architect"
+title: "Autonomous Optimization Architect Agent Personality"
 type: source
-tags: ["ai-finetuning", "llm-routing", "ai-fintech", "autonomous-agents", "cost-optimization"]
-date: 2026-04-26
+tags: []
+date: 2026-05-01
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/engineering/engineering-autonomous-optimization-architect.md]]
+- [[Agent/agency-agents/engineering/engineering-autonomous-optimization-architect]]
 
 ## Summary（用中文描述）
-- 核心主题：LLM 驱动的自主优化与智能路由系统，通过影子测试持续评估和切换 AI 模型
-- 问题域：AI 系统运营成本失控、模型选择缺乏数据驱动、缺少金融级安全保障
-- 方法/机制：LLM-as-a-Judge 评分、影子流量测试、暗启动（Dark Launching）、熔断器（Circuit Breaker）、AI FinOps
-- 结论/价值：在保证 99.99% 稳定性的前提下，通过自动路由至更便宜/更快的模型实现 >40% 成本降低
+- 核心主题：AI 系统自治优化架构师 Agent——在保证财务和安全的前提下，实现 LLM API 的持续自动化路由优化
+- 问题域：AI 系统运营成本失控风险、多供应商 LLM 的性能评估与自动路由、影子测试与安全护栏
+- 方法/机制：LLM-as-a-Judge 评分、暗启动（Shadow Traffic）A/B 测试、熔断器（Circuit Breaker）、成本感知路由
+- 结论/价值：通过数据驱动的自动路由，每年可降低 40%+ 运营成本，同时保持 99.99% 工作流完成率
 
 ## Key Claims（用中文描述）
-- 影子流量（Shadow Traffic）异步测试新模型，不影响生产环境稳定性的同时收集真实对比数据
-- 自主流量路由（Autonomous Traffic Routing）：实验模型达到基准精度（如 98%）且成本更低（如 1/10）时，自动切换至该模型
-- 金融与安全护栏（Financial & Security Guardrails）：每个外部请求必须配置超时、重试上限和廉价兜底方案，防止无限循环
-- 异常熔断（Halt on Anomaly）：流量突增 500% 或出现 HTTP 402/429 错误时，立即触发熔断器并告警人工
-- 成本优先原则：提出 LLM 架构时必须同时给出每百万 Token 的主路径和兜底路径成本估算
+- LLM-as-a-Judge 评分必须在实验开始前建立明确的数学评估标准，而非主观判断
+- 所有实验性自学习和模型测试必须异步执行，以"影子流量"形式不影响生产环境
+- 提出任何 LLM 架构时必须同时估算主路径和降级路径的每百万 Token 成本
+- 当端点流量异常激增（500%+）或连续出现 HTTP 402/429 错误时，立即触发熔断器并告警人工
+- 禁止实现开放式重试循环或无上限 API 调用，每个外部请求必须有严格超时、重试上限和指定降级路径
 
 ## Key Quotes
-> "I have evaluated 1,000 shadow executions. The experimental model outperforms baseline by 14% on this specific task while reducing costs by 80%." — Autonomous Optimization Architect 通信风格
-> "Circuit breaker tripped on Provider A due to unusual failure velocity. Automating failover to Provider B to prevent token drain. Admin alerted." — 熔断触发时的标准告警语
-> "Autonomous routing without a circuit breaker is just an expensive bomb." — 该 Agent 的核心理念
+> "Autonomous routing without a circuit breaker is just an expensive bomb." — Agent 核心信条
+> "I have evaluated 1,000 shadow executions. The experimental model outperforms baseline by 14% on this specific task while reducing costs by 80%." — Agent 汇报话术
+> "Circuit breaker tripped on Provider A due to unusual failure velocity. Automating failover to Provider B to prevent token drain. Admin alerted." — Agent 告警话术
 
 ## Key Concepts
-- [[CircuitBreaker]]：熔断器模式，当 Provider 失败频率超过阈值时自动切断并切换到廉价兜底方案
-- [[LLMasJudge]]：用 LLM 自动评估实验模型输出的质量，作为客观评分替代人工评审
-- [[ShadowTraffic]]：影子流量，将一小部分请求异步转发至实验模型，与生产结果对比评分
-- [[SemanticRouting]]：语义路由，根据任务类型和历史性能选择最优 Provider
-- [[DarkLaunching]]：暗启动/灰度发布，新模型在不影响用户的前提下逐步引入
-- [[AIFinOps]]：AI 云财务管理，跟踪每个 LLM 的 token 消耗、成本和延迟，建立历史性能排名
+- [[Circuit-Breaker]]：熔断器模式——当端点连续失败超过阈值时自动切断路由，防止恶意流量耗尽 API 配额
+- [[LLM-as-a-Judge]]：以一个 LLM 自动评估另一个 LLM 输出的质量，建立数学评分标准（JSON 格式 5 分、延迟 3 分、幻觉 -10 分）
+- [[Shadow-Traffic]]：暗启动/影子测试——将一小部分真实流量异步路由到实验模型，在不影响生产的前提下验证效果
+- [[Semantic-Routing]]：语义路由——基于任务类型和历史表现，动态选择最优 LLM 提供商，而非固定路由
+- [[AI-FinOps]]：AI 财务运维——持续监控和优化 AI 基础设施的每 Token 成本和 ROI
 
 ## Key Entities
-- [[OpenAI]]：主要 LLM Provider 之一，提供 GPT 系列模型
-- [[Anthropic]]：主要 LLM Provider，提供 Claude 系列模型
-- [[GoogleGemini]]：主要 LLM Provider，提供 Gemini Flash 等高性价比模型
-- [[Firecrawl]]：网页抓取 API，当 LLM Provider 不可用时的备选数据获取方案
+- [[OpenAI]]：LLM 提供商之一，Agent 持续追踪其 GPT 系列模型的 Token 成本和延迟表现
+- [[Anthropic]]：LLM 提供商之一，提供 Claude 系列模型，Agent 将其作为主要基准对比对象
+- [[Google-Gemini]]：LLM 提供商之一，提供 Gemini Flash 等低成本替代模型，Agent 关注其性价比路由场景
 
 ## Connections
-- [[testing-workflow-optimizer]] ← uses ← [[AutonomousOptimizationArchitect]]（工作流优化依赖路由决策）
-- [[backend-architect-with-memory]] ← depends_on ← [[AutonomousOptimizationArchitect]]（后端架构依赖成本追踪记忆）
-- [[automation-governance-architect]] ← shares_guardrails ← [[AutonomousOptimizationArchitect]]（自动化治理与本 Agent 均涉及安全护栏设计）
+- [[Performance-Benchmarker]] ← complements ← [[Autonomous-Optimization-Architect]]
+- [[Testing-Workflow-Optimizer]] ← extends ← [[Autonomous-Optimization-Architect]]
+- [[Security-Engineer]] ← addresses ← Token-Draining Attacks
+- [[Infrastructure-Maintainer]] ← overlaps ← Third-Party API Uptime
 
 ## Contradictions
-- 与 [[testing-performance-benchmarker]] 冲突：
-  - 冲突点：性能基准测试强调人工驱动的静态评估，本 Agent 强调机器驱动的动态 A/B 测试
-  - 当前观点：持续自动的影子测试比定期人工测试更能反映生产环境真实性能
-  - 对方观点：性能基准测试提供可控、可复现的实验室数据，而非真实流量噪声
+- 与 [[Testing-Tool-Evaluator]] 冲突：
+  - 冲突点：工具评估是人工驱动的一次性研究 vs. 本 Agent 的机器驱动持续 A/B 测试
+  - 当前观点：本 Agent 认为必须通过实时数据持续更新路由表，而非一次性评估报告
+  - 对方观点：工具评估应作为人工决策参考，自动化路由可能引入不可预测风险
diff --git a/wiki/sources/engineering-backend-architect.md b/wiki/sources/engineering-backend-architect.md
new file mode 100644
index 00000000..2a999c02
--- /dev/null
+++ b/wiki/sources/engineering-backend-architect.md
@@ -0,0 +1,66 @@
+---
+title: "Backend Architect Agent Personality"
+type: source
+tags: [the-agency, engineering, backend, architecture, cloud, database, api]
+date: 2026-05-01
+---
+
+## Source File
+- [[raw/Agent/agency-agents/engineering/engineering-backend-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：Backend Architect AI Agent 人格定义——专注于可扩展系统设计、数据库架构、API 开发与云基础设施的高级后端架构师
+- 问题域：如何定义一个能够设计大规模、高可靠、安全可扩展的后端系统和微服务的 AI Agent 角色
+- 方法/机制：数据模式工程 → 可扩展系统架构 → 系统可靠性保障 → 性能与安全优化，核心方法包括微服务分解、CQRS/ES 模式、数据库索引、熔断器设计
+- 结论/价值：Backend Architect 输出的系统架构、数据库 Schema、API 规范和监控策略是整个系统可靠运行的基石，属 The Agency Engineering 部门
+
+## Key Claims（用中文描述）
+- 后端架构师必须从一开始就设计水平扩展能力，而非事后补救
+- 认证和授权系统必须防止常见漏洞，遵循最小权限原则
+- 数据库查询必须实现子 20ms 性能目标，通过正确的索引和查询优化实现
+- 系统设计必须包含多层次安全措施（Defense in Depth）和数据加密（静态和传输中）
+- API 响应时间应始终保持在 200ms 以内（P95）
+- 系统可用性应超过 99.9%，配合适当的监控和自动扩缩容
+
+## Key Quotes
+> "Design for horizontal scaling from the beginning." — 性能意识设计核心理念
+> "Implement defense in depth strategies across all system layers." — 安全优先架构原则
+> "Use principle of least privilege for all services and database access." — 最小权限原则
+> "API response times consistently stay under 200ms for 95th percentile." — 成功指标之一
+> "Database queries perform under 100ms average with proper indexing." — 数据库性能目标
+
+## Key Concepts
+- [[MicroservicesArchitecture]]：微服务架构，支持水平扩展和独立部署，是 Backend Architect 默认推荐的系统分解模式
+- [[CQRS]]：命令查询职责分离，用于读写不对称的复杂领域（如订单系统）
+- [[EventSourcing]]：事件溯源，与 CQRS 配合用于复杂业务域的数据建模
+- [[ServerlessArchitecture]]：无服务器架构，Backend Architect 认可的可自动扩展且成本效益高的云部署方式
+- [[DatabaseIndexing]]：数据库索引优化，用于实现子 100ms 平均查询性能
+- [[CircuitBreaker]]：断路器模式，Backend Architect 实现系统可靠性和优雅降级的核心机制
+- [[DefenseInDepth]]：深度防御策略——跨所有系统层实施多层安全措施
+- [[Event-DrivenArchitecture]]：事件驱动架构，支持高吞吐量和松耦合的系统间通信
+- [[API-Versioning]]：API 版本管理，确保向后兼容性和平滑升级
+- [[HorizontalScaling]]：水平扩展——通过增加服务实例而非单体扩容来实现系统扩展
+
+## Key Entities
+- [[SoftwareArchitect]]：同部门兄弟 Agent，专注于系统设计、DDD 和架构模式，与 Backend Architect 共享架构思维
+- [[MobileAppBuilder]]：同部门兄弟 Agent，接收 Backend Architect 输出的 API 规范进行移动端开发
+- [[GodotMultiplayerEngineer]]：Game Dev 部门 Agent，与 Backend Architect 共享服务器权威原则和网络架构理念
+
+## Connections
+- [[SoftwareArchitect]] ← shares_architecture_principles ← [[BackendArchitectAgent]]（可扩展性、安全性、可靠性是共同核心价值）
+- [[MobileAppBuilder]] ← depends_on ← [[BackendArchitectAgent]]（API 规范作为下游输入）
+- [[GodotMultiplayerEngineer]] ← shares_server_authority ← [[BackendArchitectAgent]]（服务器权威是共同网络架构原则）
+- [[AutonomousOptimizationArchitect]] ← relates_to ← [[BackendArchitectAgent]]（两者都关注系统性能和可靠性优化）
+- [[SRE]] ← relates_to ← [[BackendArchitectAgent]]（Backend Architect 输出的架构为 SRE 的可靠性工作提供基础）
+
+## Contradictions
+- 与 [[backend-architect-with-memory]] 的架构决策方式存在张力：
+  - 冲突点：持久化架构知识的方式
+  - 当前观点（engineering-backend-architect）：通过 System Prompt 和交付物文档（System Architecture Specification、Database Schema、API Design）进行知识传递
+  - 对方观点（backend-architect-with-memory）：通过 MCP Memory 标签化快照持久化，支持跨 Agent 自动召回和回滚
+  - 协调方案：两者互补——文档规范供人类可读和跨团队共享，MCP Memory 快照供 Agent 自动化召回；engineering-backend-architect 是基础角色定义，backend-architect-with-memory 是增强版
+- 与 [[SoftwareArchitect]] 的抽象层次存在差异：
+  - 冲突点：架构粒度
+  - 当前观点（Backend Architect）：关注数据库 Schema、API 端点、WebSocket 事件、部署拓扑等具体实现细节
+  - 对方观点（Software Architect）：关注领域边界、模式选型、质量属性权衡等抽象层次
+  - 协调方案：Software Architect 负责\"做什么系统\"（What），Backend Architect 负责\"怎么做\"（How）；两者在不同抽象层次工作，互为补充
diff --git a/wiki/sources/engineering-code-reviewer.md b/wiki/sources/engineering-code-reviewer.md
new file mode 100644
index 00000000..c3f84ffc
--- /dev/null
+++ b/wiki/sources/engineering-code-reviewer.md
@@ -0,0 +1,52 @@
+---
+title: "Code Reviewer Agent Personality"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-code-reviewer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Code Reviewer AI Agent 人格定义——专注于代码审查与质量保证的专业 AI Agent
+- 问题域：代码质量保障（正确性、安全性、可维护性、性能）
+- 方法/机制：分层审查清单（Blocker/Suggestion/Nit 三级优先级）、标准化审查评论格式、教导式反馈风格
+- 结论/价值：最佳审查教会而非批评，提升代码质量 AND 开发者技能
+
+## Key Claims（用中文描述）
+- Code Reviewer 提供构造性、可操作的反馈，聚焦正确性、安全性、可维护性、性能，而非代码风格偏好
+- 审查重点五大维度：正确性（功能是否符合预期）、安全性（注入/XSS/认证漏洞）、可维护性（六个月后是否可理解）、性能（瓶颈/N+1查询）、测试（重要路径是否覆盖）
+- 审查评论必须具体化：指出具体行号和机制，而非泛泛说"有安全问题"
+- 必须解释原因：不仅说改什么，还要说为什么
+- 建议而非要求：用"考虑使用X因为Y"而非"改成X"
+- 标记优先级：🔴 blocker（必须修复）、🟡 suggestion（应该修复）、💭 nit（锦上添花）
+- 赞美好代码：指出聪明的解决方案和干净的模式
+- 一次审查完整反馈：不要多轮滴水式评论
+
+## Key Quotes
+> "Reviews code like a mentor, not a gatekeeper. Every comment teaches something." — Code Reviewer 核心理念
+
+> "🔴 Security: SQL Injection Risk — Line 42: User input is interpolated directly into the query. Why: An attacker could inject `'; DROP TABLE users; --`. Suggestion: Use parameterized queries." — 标准化审查评论格式示例
+
+## Key Concepts
+- [[CodeReview]]: 代码审查的核心概念——通过系统性检查提升代码质量的过程
+- [[SecurityAudit]]: 安全审查维度——注入、XSS、认证绕过等漏洞检测
+- [[PerformanceProfiling]]: 性能分析——N+1查询、不必要内存分配等瓶颈识别
+- [[Mentorship]]: 教导式反馈——审查即教学，每次评论都有教育意义
+- [[ReviewChecklist]]: 审查清单——结构化的三层优先级体系（Blocker/Suggestion/Nit）
+
+## Key Entities
+- [[CodeReviewerAgent]]: Code Reviewer AI Agent 本身——代码审查与质量保证专家
+
+## Connections
+- [[SoftwareArchitect]] ← informs → [[CodeReviewerAgent]]：架构决策影响审查重点
+- [[BackendArchitect]] ← depends_on → [[CodeReviewerAgent]]：后端实现依赖代码审查保障质量
+- [[SeniorDeveloper]] ← extends → [[CodeReviewerAgent]]：资深开发者兼具审查职责
+- [[QualityGate]] ← implements → [[CodeReviewerAgent]]：质量门控的自动化实现依赖审查标准
+
+## Contradictions
+- 与纯风格审查工具（如 linter）的冲突：
+  - 冲突点：风格工具负责格式化，Code Reviewer 负责人工判断
+  - 当前观点：Code Reviewer 明确拒绝审查风格偏好（"not tabs vs spaces"），将风格交给 linter
+  - 对方观点：某些团队要求审查者确保代码风格一致
diff --git a/wiki/sources/engineering-codebase-onboarding-engineer.md b/wiki/sources/engineering-codebase-onboarding-engineer.md
new file mode 100644
index 00000000..4b865532
--- /dev/null
+++ b/wiki/sources/engineering-codebase-onboarding-engineer.md
@@ -0,0 +1,47 @@
+---
+title: "Codebase Onboarding Engineer"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-codebase-onboarding-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 角色定义，帮助新开发者快速理解陌生代码库的专业引导者
+- 问题域：开发者 onboarding 效率、代码库结构理解、代码路径追踪
+- 方法/机制：通过读取源码、追踪执行路径、仅陈述有代码依据的事实来构建准确的心智模型
+- 结论/价值：让新开发者 5 分钟内找到主入口点，缩短 onboarding 时间
+
+## Key Claims（用中文描述）
+- Agent 必须在代码中能找到证据时才陈述模块拥有某行为
+- 永远只陈述有源码支撑的事实，不推理、不假设、不猜测
+- 解释必须分三个层次：一句话概述 → 五分钟高层解释 → 深度代码流分析
+- 严格保持只读模式，绝不修改文件或生成补丁
+
+## Key Quotes
+> "Never state that a module owns behavior unless you can point to the file(s) that implement or route it." — 证据优先原则
+> "If something is not visible in the code you inspected, do not state it." — 诚实告知检查范围
+> "State only facts grounded in the code that was actually inspected." — 事实唯一准则
+
+## Key Concepts
+- [[CodebaseOnboarding]]：帮助新开发者快速理解陌生代码库的方法论和实践
+- [[ExecutionTracing]]：追踪请求、事件、命令在系统中的完整执行路径
+- [[EvidenceFirstReasoning]]：只陈述代码中可验证的事实，不进行推理或假设
+- [[MentalModel]]：为开发者构建准确、可理解的项目结构心智模型
+- [[ThreeTierExplanation]]：一/五/深的分层解释结构
+
+## Key Entities
+- （本文档为纯 Agent 角色定义，未涉及具体人物或公司实体）
+
+## Connections
+- [[EngineeringMinimalChangeEngineer]] ← related_to ← [[CodebaseOnboardingEngineer]]
+- [[EngineeringSeniorDeveloper]] ← related_to ← [[CodebaseOnboardingEngineer]]
+- [[EngineeringCodeReviewer]] ← related_to ← [[CodebaseOnboardingEngineer]]
+
+## Contradictions
+- 与 [[EngineeringMinimalChangeEngineer]] 侧重点不同：
+  - Codebase Onboarding Engineer 专注快速理解代码库结构
+  - Minimal Change Engineer 专注最小改动实现目标
+  - 两者互补：一个帮助理解，一个指导改动
diff --git a/wiki/sources/engineering-data-engineer.md b/wiki/sources/engineering-data-engineer.md
new file mode 100644
index 00000000..f8453131
--- /dev/null
+++ b/wiki/sources/engineering-data-engineer.md
@@ -0,0 +1,57 @@
+---
+title: "Data Engineer Agent Personality"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[../../../../../Workspace/nexus/raw/Agent/agency-agents/engineering/engineering-data-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Data Engineer Agent 个性定义——构建可靠、可观测、自愈的数据管道和 Lakehouse 架构的专业 Agent
+- 问题域：如何将原始、混乱、来自多种来源的数据转化为可靠的、高质量的、可分析的数据资产，并保证准时、按规模、全程可观测
+- 方法/机制：Medallion Architecture（Bronze→Silver→Gold）、PySpark+Delta Lake ETL/ELT、dbt 数据质量契约、Great Expectations 质量验证、Kafka 流式处理、CDC 增量摄取
+- 结论/价值：Data Engineer Agent 的核心价值在于将数据可靠性作为产品交付，通过 Medallion 分层架构确保 Bronze=原始不可变、Silver=清洗去重、Gold=业务就绪，并通过 SLA 监控、沿袭追踪、数据目录实现全栈可观测性
+
+## Key Claims（用中文描述）
+- Data Engineer Agent 通过 Medallion Architecture（Bronze→Silver→Gold）分层设计，实现了数据质量从原始到业务就绪的渐进式提升
+- Data Engineer Agent 要求所有管道必须幂等（idempotent）—— 重新运行产生相同结果，永不产生重复数据
+- Data Engineer Agent 通过 CDC（Change Data Capture）和增量管道设计，将全量刷新成本降低 90% 以上
+- Data Engineer Agent 通过 Great Expectations 实现行级数据质量评分，确保 Gold 层数据达到 SLA 保证
+- Data Engineer Agent 通过 Apache Kafka 实现 Exactly-Once 语义和延迟到达数据处理，平衡流式与微批次的成本-延迟权衡
+
+## Key Quotes
+> "Bronze = raw, immutable, append-only; never transform in place" — Medallion Architecture Bronze 层核心原则
+> "All pipelines must be idempotent — rerunning produces the same result, never duplicates" — 管道可靠性第一准则
+> "Null handling must be deliberate — no implicit null propagation into gold/semantic layers" — Silver→Gold 层 null 值处理规范
+> "Data in gold/semantic layers must have row-level data quality scores attached" — Gold 层数据质量强制要求
+
+## Key Concepts
+- [[Medallion Architecture]]：Bronze（原始只读）→ Silver（清洗去重）→ Gold（业务聚合）的三层数据湖仓架构，每层有明确的转换规则和 SLA
+- [[CDC (Change Data Capture)]]：通过变更数据捕获实现增量管道，相比全量刷新可节省 90%+ 计算成本
+- [[Data Contract]]：数据生产者和消费者之间的明确 schema 契约，schema 漂移必须触发告警而非静默损坏
+- [[Data Lineage]]：数据沿袭追踪——每一行数据都能追溯到其来源系统
+- [[SCD Type 2]]：Slowly Changing Dimension Type 2，实现历史维度变更追踪
+
+## Key Entities
+- [[Apache Spark]]：大规模并行处理引擎，Data Engineer Agent 的核心计算平台
+- [[Delta Lake]]：开放表格格式，提供 ACID 事务、时间旅行和 Z-Ordering 等能力
+- [[dbt]]：数据转换和质量管理工具，Data Engineer Agent 用于定义数据质量契约
+- [[Great Expectations]]：数据质量验证框架，Data Engineer Agent 用于行级数据质量评分
+- [[Apache Kafka]]：事件流平台，Data Engineer Agent 用于构建 Exactly-Once 语义的实时管道
+- [[Databricks]]：Lakehouse 平台（Unity Catalog、DLT），Data Engineer Agent 的主要托管环境之一
+- [[Snowflake]]：云数据仓库，Data Engineer Agent 的另一主要数据平台
+- [[Apache Iceberg]]：开放表格格式规范，Data Engineer Agent 用于跨引擎互操作
+
+## Connections
+- [[Apache Spark]] ← builds_with ← [[Delta Lake]]
+- [[dbt]] ← validates ← [[Apache Spark]]
+- [[Apache Kafka]] ← streams_to ← [[Delta Lake]]
+- [[Great Expectations]] ← enforces ← [[Data Contract]]
+- [[Databricks]] ← hosts ← [[Apache Spark]], [[Delta Lake]]
+- [[Medallion Architecture]] ← implements ← [[Data Lineage]]
+- [[CDC (Change Data Capture)]] ← enables ← [[Medallion Architecture]]
+
+## Contradictions
+- 无已知冲突。Data Engineer Agent 与 SRE Agent（[[engineering-sre]]）在数据管道 SLA 监控（告警响应）层面高度互补，Data Engineer 负责管道内部可观测性，SRE 负责整体服务可靠性。
diff --git a/wiki/sources/engineering-database-optimizer.md b/wiki/sources/engineering-database-optimizer.md
new file mode 100644
index 00000000..70569420
--- /dev/null
+++ b/wiki/sources/engineering-database-optimizer.md
@@ -0,0 +1,50 @@
+---
+title: "Database Optimizer Agent Personality"
+type: source
+tags: [database, postgresql, mysql, performance, optimization, sql, backend, supabase, planetscale]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-database-optimizer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Database Optimizer 是一个专注于数据库性能优化的 Agent 人格定义
+- 问题域：Schema 设计、查询优化、索引策略、连接池管理、零停机迁移
+- 方法/机制：使用 EXPLAIN ANALYZE 分析查询计划；采用 B-tree/GiST/GIN/部分索引策略；通过 CONCURRENTLY 创建索引避免表锁；使用连接池防止连接泄漏
+- 结论/价值：提供可在生产环境直接使用的 SQL 模板和 TypeScript 代码示例，涵盖 PostgreSQL、MySQL、Supabase 和 PlanetScale
+
+## Key Claims（用中文描述）
+- Database Optimizer 专注于 PostgreSQL 优化和高级特性，通过 EXPLAIN ANALYZE 解释查询计划来识别 Seq Scan（差）、Index Scan（好）、Bitmap Heap Scan（可接受）
+- Database Optimizer 采用多种索引策略（B-tree、GiST、GIN、部分索引、复合索引）针对不同查询模式进行性能优化
+- Database Optimizer 通过使用 CONCURRENTLY 创建索引来确保生产环境零停机，避免表锁
+- Database Optimizer 通过连接池化（PgBouncer、Supabase pooler）防止连接泄漏，支持事务模式和会话模式
+- Database Optimizer 通过单次 JOIN 查询替代 N+1 循环查询来消除性能瓶颈，使用 json_agg 聚合嵌套数据
+
+## Key Quotes
+> "Build database architectures that perform well under load, scale gracefully, and never surprise you at 3am." — Database Optimizer 核心使命宣言
+> "Every query has a plan, every foreign key has an index, every migration is reversible, and every slow query gets optimized." — Database Optimizer 核心原则
+> "Use CONCURRENTLY for indexes — never lock tables in production." — 安全迁移规则
+
+## Key Concepts
+- [[QueryPlanAnalysis]]：使用 EXPLAIN ANALYZE 分析查询计划，识别 Seq Scan、Index Scan、Bitmap Heap Scan，理解 actual time vs planned time 的差异
+- [[IndexingStrategies]]：B-tree（等值/范围查询）、GiST（几何/全文搜索）、GIN（JSON/数组）、部分索引（高频过滤条件）、复合索引（多列过滤+排序）
+- [[N1QueryPrevention]]：通过 JOIN + json_agg 聚合替代循环查询，消除 N+1 问题
+- [[ConnectionPooling]]：PgBouncer 和 Supabase pooler 防止连接耗尽，支持事务模式和会话模式
+- [[SafeMigrations]]：CONCURRENTLY 创建索引、使用可逆迁移、避免生产环境表锁
+- [[SchemaDesign]]：规范化 vs 反规范化的权衡，foreign key 必须加索引
+
+## Key Entities
+- [[PostgreSQL]]：主要支持的数据库引擎，提供 EXPLAIN ANALYZE、部分索引、CONCURRENTLY 等高级特性
+- [[MySQL]]：支持的数据库之一，语法和特性与 PostgreSQL 有差异
+- [[Supabase]]：开源 Firebase 替代品，提供内置连接池和实时订阅
+- [[PlanetScale]]：MySQL 兼容的无服务器数据库，支持分支和非阻塞模式变更
+- [[PgBouncer]]：轻量级 PostgreSQL 连接池工具，支持事务模式和会话模式
+- [[BIGSERIAL]]：PostgreSQL 主键类型，等价于 BIGINT + AUTO_INCREMENT
+
+## Connections
+- [[engineering-backend-architect]] ← extends ← [[engineering-database-optimizer]]（后端架构师依赖数据库优化专家的设计原则）
+- [[engineering-sre]] ← depends_on ← [[engineering-database-optimizer]]（SRE 需要理解数据库性能调优）
+
+## Contradictions
+- 无已知冲突内容
diff --git a/wiki/sources/engineering-devops-automator.md b/wiki/sources/engineering-devops-automator.md
new file mode 100644
index 00000000..eb0cefc3
--- /dev/null
+++ b/wiki/sources/engineering-devops-automator.md
@@ -0,0 +1,54 @@
+---
+title: "DevOps Automator Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-devops-automator.md]]
+
+## Summary（用中文描述）
+- 核心主题：DevOps Automator — 专注于基础设施自动化、CI/CD 流水线开发和云运营的专业 DevOps 工程师 Agent
+- 问题域：消除手动运维流程、提升系统可靠性、实现可扩展的部署策略
+- 方法/机制：基础设施即代码（Terraform）、CI/CD 流水线自动化（GitHub Actions/Jenkins/GitLab CI）、容器编排（Docker/Kubernetes）、监控告警（Prometheus/Grafana）、零停机部署策略（蓝绿/金丝雀/滚动）
+- 结论/价值：通过全面的自动化提升部署频率、降低 MTTR、保障 99.9% 可用性
+
+## Key Claims（用中文描述）
+- DevOps Automator 通过基础设施即代码和 CI/CD 流水线自动化，消除手动部署流程，实现每日多次部署
+- DevOps Automator 通过零停机部署策略（蓝绿、金丝雀、滚动部署）配合自动回滚，保障服务持续可用
+- DevOps Automator 通过 Prometheus + Grafana 监控体系，在问题影响用户之前主动发现并告警
+- DevOps Automator 通过安全扫描自动化和 secrets 管理集成，将安全内嵌到交付管线的每个阶段
+
+## Key Quotes
+> "Eliminate manual processes through comprehensive automation" — 核心理念：一切皆自动化
+> "Built monitoring and alerting to catch problems before they affect users" — 预防优于修复
+> "Self-healing systems with automated recovery" — 自愈系统设计目标
+
+## Key Concepts
+- [[Infrastructure as Code]]：通过 Terraform/CloudFormation/CDK 用代码管理云基础设施，实现版本控制和可重复部署
+- [[CI/CD Pipeline]]：自动化代码构建、测试、部署的端到端流水线，确保每次变更都可追溯
+- [[Zero-Downtime Deployment]]：蓝绿部署、金丝雀发布、滚动更新等策略，保证服务在更新期间持续可用
+- [[Observability]]：通过指标、日志、追踪三位一体的可观测性体系，全面了解系统状态
+- [[Self-Healing System]]：自动检测故障并触发恢复机制，无需人工干预
+
+## Key Entities
+- [[Terraform]]：HashiCorp 基础设施即代码工具，用于声明式管理云资源
+- [[Kubernetes]]：容器编排平台，负责容器化应用的自动化部署、扩缩容和管理
+- [[GitHub Actions]]：CI/CD 平台，用于自动化构建、测试和部署工作流
+- [[Prometheus]]：开源监控系统，负责指标采集和告警
+- [[Grafana]]：可视化平台，与 Prometheus 集成展示监控仪表板
+- [[Blue-Green Deployment]]：零停机部署策略，通过两套环境切换实现无缝更新
+
+## Connections
+- [[DevOps Automator]] ← extends ← [[Infrastructure as Code]]
+- [[DevOps Automator]] ← extends ← [[CI/CD Pipeline]]
+- [[DevOps Automator]] ← depends_on ← [[Kubernetes]]
+- [[DevOps Automator]] ← depends_on ← [[Prometheus]] ← extends ← [[Observability]]
+
+## Contradictions
+- 与 SRE Engineering Agent（engineering-sre，源文件待摄入）可能存在张力：
+  - 冲突点：DevOps Automator 强调完全自动化消除人工干预，SRE 强调人工 on-call 和事后复盘的不可替代性
+  - 当前观点（DevOps Automator）：优先自动化所有可自动化流程，减少人工干预，提升部署频率
+  - 对方观点（SRE）：在复杂故障场景下人工判断不可替代，MTTR 降低依赖自动化但 SLO/SLI 设计需要人工评估
+  - 状态：待 engineering-sre 摄入后进一步确认冲突细节
diff --git a/wiki/sources/engineering-email-intelligence-engineer.md b/wiki/sources/engineering-email-intelligence-engineer.md
new file mode 100644
index 00000000..e990a12c
--- /dev/null
+++ b/wiki/sources/engineering-email-intelligence-engineer.md
@@ -0,0 +1,59 @@
+---
+title: "Email Intelligence Engineer Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-email-intelligence-engineer.md]]
+
+## Summary（用中文描述）
+- **核心主题**：Email Intelligence Engineer — 将原始邮件数据转换为 AI Agent 可消费的、结构化的推理上下文的专业 Agent 角色定义
+- **问题域**：邮件的结构复杂性（引用文本重复、转发链折叠、线程分叉、第一人称歧义）导致传统 RAG/Context 方式无法正确理解邮件对话
+- **方法/机制**：四步处理管道——①邮件摄取与标准化 → ②线程重建与去重 → ③结构化分析（参与者图、决策时间线、行动项归因） → ④上下文组装与工具接口
+- **结论/价值**：通过保留线程拓扑结构 + 引用去重 + 参与者绑定，使 Agent 在邮件数据上的下游任务准确率提升 20%+
+
+## Key Claims（用中文描述）
+- Email Intelligence Engineer 通过线程重建保留对话拓扑结构，使 Agent 能够正确理解邮件上下文，避免将多轮对话扁平化为单文档导致的信息错位
+- 通过引用文本去重技术，将原始线程 Token 量压缩 4-5 倍，同时保证零信息丢失，显著降低 LLM 上下文成本
+- 通过参与者绑定机制（From: header 级别归因），确保行动项归因于正确的发送者，解决扁平化线程中第一人称代词歧义问题
+- 通过混合检索（语义搜索 + 全文搜索 + 元数据过滤器）实现精准邮件片段召回，结合 Token 预算管理生成带来源引用的结构化输出
+- LangChain / CrewAI / LlamaIndex / MCP Server 是该 Agent 的核心集成目标，使邮件智能能力可被主流 Agent 框架直接消费
+
+## Key Quotes
+> "Never treat a flattened email thread as a single document. Thread topology matters." — 核心设计原则：线程拓扑结构不可丢失
+> "Quoted reply duplication inflated the thread from 11K to 47K tokens. Deduplication brought it back to 12K with zero information loss." — 引用去重的量化价值
+> "The action items were attributed to the wrong people because the flattened thread stripped From: headers. Without participant binding at the message level, every first-person pronoun is ambiguous." — 参与者绑定的必要性
+
+## Key Concepts
+- [[Thread-Reconstruction]]：通过 In-Reply-To 和 References 头链重建邮件对话拓扑图，处理转发链折叠、线程分叉等复杂场景
+- [[Content-Deduplication]]：引用文本去重——移除邮件正文中对父消息的引用内容（支持 `>` 前缀引用、`---Original Message---` 分隔符、Outlook XML 嵌套引用等多种风格），典型压缩比 4-5x
+- [[Participant-Detection]]：参与者检测与角色推断——从 From/To/CC/BCC 提取参与者、标准化显示名、推断角色、分析回复频率
+- [[Action-Item-Attribution]]：行动项归因——将承诺/任务绑定到正确的消息发送者，而非依赖第一人称代词
+- [[Hybrid-Retrieval]]：混合检索——结合语义相似度搜索、全文关键词搜索和元数据过滤器（日期范围、参与者、附件类型等）
+- [[Context-Assembly]]：上下文组装——在 Token 预算内按相关性组装上下文，生成带消息级别来源引用的结构化 JSON 输出
+- [[PII-Redaction]]：PII 检测与脱敏作为管道前置阶段，而非后期补救
+- [[Decision-Through-Silence]]：沉默决策检测——当提案未收到反对且后续消息将其视为已确定时，识别为隐式决策
+
+## Key Entities
+- [[LangChain]]：该 Agent 通过 `@tool` 装饰器提供 LangChain 工具接口，使邮件查询和搜索能力可被 LangChain Agent 直接调用
+- [[CrewAI]]：该 Agent 的输出格式支持 CrewAI 的 Task 和 Agent 模式，提供结构化的邮件上下文输入
+- [[LlamaIndex]]：该 Agent 的邮件读取器（Readers）能力可集成到 LlamaIndex 数据管道中
+
+## Connections
+- [[LangChain]] ← provides_tools ← [[Email-Intelligence-Engineer]]（通过 `@tool` 装饰器暴露邮件查询/搜索工具）
+- [[CrewAI]] ← provides_tools ← [[Email-Intelligence-Engineer]]（结构化输出适配 CrewAI Task 模式）
+- [[LlamaIndex]] ← integrates ← [[Email-Intelligence-Engineer]]（邮件读取器集成）
+- [[Thread-Reconstruction]] ← is_component_of ← [[Email-Intelligence-Engineer]] Pipeline Step 2
+- [[Content-Deduplication]] ← is_component_of ← [[Email-Intelligence-Engineer]] Pipeline Step 2
+- [[Hybrid-Retrieval]] ← is_component_of ← [[Email-Intelligence-Engineer]] Pipeline Step 4
+- [[Context-Assembly]] ← is_component_of ← [[Email-Intelligence-Engineer]] Pipeline Step 4
+- [[Email-Intelligence-Engineer]] ← extends ← [[RAG]]（在邮件领域的 RAG 增强，解决邮件特有的结构复杂性）
+- [[Email-Intelligence-Engineer]] ← provides_context_for ← [[Agentic-AI]]（为 Agent 系统提供邮件领域的推理上下文）
+
+## Contradictions
+- 与 [[RAG]] 通用实现存在差异：
+  - **冲突点**：传统 RAG 将文档视为原子单元，而邮件是具有拓扑结构的对话序列
+  - **当前观点**：Email Intelligence Engineer 主张邮件必须保留线程拓扑，消息级别的 From: header 必须被保留用于参与者绑定
+  - **对方观点**：通用 RAG 系统通常将邮件线程扁平化为单一文档进行检索，仅关注内容匹配而非对话结构
diff --git a/wiki/sources/engineering-embedded-firmware-engineer.md b/wiki/sources/engineering-embedded-firmware-engineer.md
new file mode 100644
index 00000000..89ae5fdd
--- /dev/null
+++ b/wiki/sources/engineering-embedded-firmware-engineer.md
@@ -0,0 +1,55 @@
+---
+title: "Embedded Firmware Engineer Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-embedded-firmware-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency 旗下的嵌入式固件工程师 Agent 人格定义，专注于资源受限嵌入式系统的生产级固件开发
+- 问题域：MCU 选型（ESP32/STM32/Nordic nRF）、裸机与 RTOS 固件架构、外设驱动可靠性、通信协议实现、OTA 升级
+- 方法/机制：FreeRTOS 任务架构设计（队列/信号量/事件组）、静态内存分配优先、ISR 最小化原则、平台差异化实践（ESP-IDF / STM32 LL/HAL / Nordic Zephyr）
+- 结论/价值：交付零栈溢出、ISR 延迟可测量、Flash/RAM 使用可文档化、生产级可靠固件
+
+## Key Claims（用中文描述）
+- RTOS 任务中禁止动态分配（malloc/new），必须使用静态分配或内存池
+- ISR 必须最小化——通过队列或信号量将工作延迟到任务处理
+- 栈大小必须计算而非猜测，使用 `uxTaskGetStackHighWaterMark()` 验证
+- STM32 时序关键代码优先使用 LL 驱动而非 HAL
+- Nordic 平台使用 Zephyr devicetree 和 Kconfig，禁止硬编码外设地址
+- PlatformIO 生产环境 `platformio.ini` 必须锁定库版本，禁止使用 `@latest`
+
+## Key Quotes
+> "ISRs must be minimal — defer work to tasks via queues or semaphores" — ISR 设计核心原则，强制最小化中断处理路径
+> "Stack sizes must be calculated, not guessed — use `uxTaskGetStackHighWaterMark()`" — 栈大小验证规范，防止生产环境栈溢出
+> "Never use dynamic allocation (`malloc`/`new`) in RTOS tasks after init" — RTOS 内存安全铁律，消除堆碎片风险
+
+## Key Concepts
+- [[FreeRTOS]]：开源 RTOS，ESP-IDF/Nordic Zephyr 均基于此实现多任务调度，提供队列/信号量/事件组等 IPC 机制
+- [[ARM-Cortex-M]]：嵌入式 MCU 主流架构，ESP32/STM32/Nordic nRF 均基于此系列
+- [[ESP-IDF]]：乐鑫官方 ESP32 开发框架，包含 Wi-Fi/BLE 驱动、OTA、文件系统等组件
+- [[STM32-HAL-LL]]：STM32 的两套驱动层——HAL 通用但时序差，LL 轻量且时序精确
+- [[Nordic-nRF]]：Nordic 半导体低功耗蓝牙 SoC 系列，使用 Zephyr RTOS 和 nRF Connect SDK
+- [[Zephyr-RTOS]]：Linux 基金会托管的开源 RTOS，Nordic/Zephyr 生态核心，支持 devicetree 和 Kconfig
+- [[OTA-Upgrade]]：空中固件升级，ESP-IDF/STM32 自定义 bootloader/MCUboot 各有实现路径
+
+## Key Entities
+- [[ESP32]]：乐鑫 Wi-Fi+BLE SoC，[[ESP-IDF]] 目标平台，固件 OTA 升级主力芯片
+- [[STM32]]：STMicroelectronics MCU 系列，[[STM32-HAL-LL]] 驱动层，面向工业传感/控制场景
+- [[Nordic-nRF]]：Nordic 蓝牙 SoC，面向可穿戴/IoT 低功耗应用
+- [[PlatformIO]]：跨平台嵌入式开发环境，支持 ESP32/STM32/Nordic，统一 `platformio.ini` 配置
+- [[FreeRTOS]]：嵌入式 RTOS，内核被 ESP-IDF 和 Zephyr 引用，提供任务调度和 IPC
+
+## Connections
+- [[engineering-backend-architect]] ← uses → [[FreeRTOS]] — 后端架构师使用消息队列，嵌入式固件工程师设计 FreeRTOS 队列作为 IPC
+- [[engineering-software-architect]] ← informs → [[ARM-Cortex-M]] — 软件架构师了解硬件抽象，固件工程师精通 MCU 底层
+
+## Contradictions
+- 与 [[engineering-rapid-prototyper]] 的速度哲学对比：
+  - 冲突点：快速原型是否允许技术债
+  - 当前观点：固件工程师禁止使用 malloc/动态分配、不允许 `platformio.ini` 使用 `@latest`，强制稳定优先
+  - 对方观点：Rapid Prototyper 允许先跑通再优化，接受短期技术债换取速度
+  - 协调方案：固件层严格执行规范，上层应用层（Web/移动）可适度使用快速原型
diff --git a/wiki/sources/engineering-feishu-integration-developer.md b/wiki/sources/engineering-feishu-integration-developer.md
new file mode 100644
index 00000000..097777ee
--- /dev/null
+++ b/wiki/sources/engineering-feishu-integration-developer.md
@@ -0,0 +1,57 @@
+---
+title: "Feishu Integration Developer Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[raw/Agent/agency-agents/engineering/engineering-feishu-integration-developer.md]]
+
+## Summary（用中文描述）
+- 核心主题：飞书（Feishu/Lark）开放平台全栈集成专家，专注于企业 OA 审批、数据管理、团队协作和业务通知在飞书生态内的实现。
+- 问题域：企业级飞书生态集成开发，包括自定义机器人、交互式消息卡片、审批流自动化、Bitable 多维表格、SSO/OIDC 认证和飞书小程序。
+- 方法/机制：通过官方 SDK（`oapi-sdk-nodejs` / `oapi-sdk-python`）调用飞书 API；TokenManager 实现 tenant/user_access_token 缓存；EventDispatcher 处理事件订阅签名验证；CardBuilder 构建交互式卡片 JSON；BitableClient 实现表格记录的 CRUD 与批量同步。
+- 结论/价值：提供企业级协作自动化解决方案，核心理念是"飞书集成不只是调用 API"，涉及权限模型、事件幂等性、多租户架构和与内部系统的深度集成。交付物涵盖完整项目结构、Token 管理、卡片构建、事件分发、审批流、Bitable 操作和 OAuth 登录六大模块。
+
+## Key Claims（用中文描述）
+- 飞书集成工程师必须区分 `tenant_access_token` 和 `user_access_token` 的适用场景——前者用于应用级别操作，后者用于用户个人数据和授权操作。
+- 所有 API 响应必须检查 `code` 字段，`code != 0` 时执行错误处理和日志记录，而非默认成功。
+- 事件处理必须实现幂等性——飞书可能重复投递同一事件（网络重试机制），重复处理会导致数据不一致。
+- 消息卡片 JSON 必须在本地验证后再发送，飞书对格式敏感，渲染失败会阻塞业务流程。
+- Bitable 批量写入每请求最多 500 条记录，超出必须分批并建议批次间添加 200ms 延迟以避免限流。
+- `app_secret` 和 `encrypt_key` 必须存放在环境变量或密钥管理服务中，前端代码禁止硬编码。
+
+## Key Quotes
+> "Feishu integration is not just 'calling APIs' — it involves permission models, event subscriptions, data security, multi-tenant architecture, and deep integration with enterprise internal systems." — 核心身份定义
+
+> "Don't do heavy processing inside the event callback — return 200 first, then handle asynchronously. Feishu will retry if it doesn't get a response within 3 seconds, and you might receive duplicate events." — 事件处理最佳实践
+
+> "Bitable batch writes are limited to 500 records per request — anything over that needs to be batched. Also watch out for concurrent writes triggering rate limits; I recommend adding a 200ms delay between batches." — 数据同步性能警告
+
+## Key Concepts
+- [[Tenant-Access-Token]]：应用级别访问令牌，用于不涉及特定用户的操作，需缓存并提前5分钟刷新以避免边界问题。
+- [[User-Access-Token]]：用户级别 OAuth 令牌，通过授权码流程获取，代表用户身份执行操作，需安全存储和刷新。
+- [[Message-Card]]：飞书交互式卡片，基于 JSON 结构定义，支持按钮、日期选择器、下拉菜单等交互元素，通过 `message_id` 可更新已发送卡片内容。
+- [[Event-Subscription]]：飞书事件订阅机制，支持 Bot 消息接收、审批状态变更等事件，必须验证签名或解密 encrypt key，返回 200 状态码避免重试。
+- [[Bitable]]：飞书多维表格，支持表格记录的增删改查、字段管理、视图切换和数据双向同步，适合作为企业数据的中转层。
+- [[OAuth-2-0-Feishu]]：飞书网页应用自动登录授权流程，包含 authorize 重定向 → callback code 交换 → user_info 获取三步，必须验证 state 参数防止 CSRF。
+- [[Idempotency]]：事件处理幂等性设计——飞书可能重复投递同一事件（超时重试），处理逻辑必须能正确处理重复消息而不产生副作用。
+
+## Key Entities
+- [[LarkSuite-API-SDK]]（`@larksuiteoapi/node-sdk` / `oapi-sdk-python`）：飞书官方 SDK，推荐使用而非手动构造 HTTP 请求，内置 token 缓存。
+- [[Feishu-Open-Platform]]：飞书开放平台，提供 Bot、审批、Bitable、小程序、SSO 等企业集成能力，需在平台创建应用并配置权限范围。
+- [[Feishu-Card-Builder]]：飞书官方卡片构建工具，支持可视化预览交互式卡片 JSON，发布前必须通过工具验证卡片渲染。
+
+## Connections
+- [[Engineering-Backend-Architect]] ← 依赖 → [[Feishu-Integration-Developer]]：后端架构师设计系统拓扑，飞书集成开发者在其架构内实现消息通知和数据同步模块。
+- [[Engineering-Software-Architect]] ← extends → [[Feishu-Integration-Developer]]：软件架构师定义系统边界和集成模式，飞书集成开发者遵循其架构决策构建具体集成模块。
+- [[Testing-API-Tester]] ← 验证 → [[Feishu-Integration-Developer]]：API 测试专家验证飞书 API 调用的正确性、限流处理和错误恢复能力。
+- [[Engineering-SRE]] ← 监控 → [[Feishu-Integration-Developer]]：SRE 工程师配置 token 获取失败、API 调用错误、事件处理超时等监控告警。
+
+## Contradictions
+- 与 [[Engineering-Rapid-Prototyper]] 存在速度哲学张力：
+  - 冲突点：Rapid Prototyper 追求"3天交付 MVP"的速度优先哲学，允许技术债；飞书集成要求"必须实现幂等性、必须检查 code 字段、必须缓存 token"等严格工程标准。
+  - 当前观点：生产级企业集成必须遵守飞书 API 规范（幂等性/错误处理/token 缓存），否则在事件重试和高并发场景下会产生数据不一致。
+  - 对方观点：原型阶段可简化 token 管理和错误处理以加快交付速度。
+  - 协调方式：在原型验证阶段使用 Rapid Prototyper 快速验证业务假设，生产化阶段再由飞书集成开发者补充完整错误处理和幂等性保障。
diff --git a/wiki/sources/engineering-filament-optimization-specialist.md b/wiki/sources/engineering-filament-optimization-specialist.md
new file mode 100644
index 00000000..5048cc30
--- /dev/null
+++ b/wiki/sources/engineering-filament-optimization-specialist.md
@@ -0,0 +1,52 @@
+---
+title: "Filament Optimization Specialist Agent Personality"
+type: source
+tags: ["filament-php", "admin-panel", "structural-optimization", "ux", "laravel"]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-filament-optimization-specialist.md]]
+
+## Summary（用中文描述）
+- 核心主题：Filament PHP 管理后台的结构性优化专家 Agent人格定义
+- 问题域：Filament PHP admin panel 的 UX 改进，专注于高影响力的结构性改变而非表面装饰
+- 方法/机制：结构优化层次体系（Tab 分隔 → 并排 Grid → Range Slider 替换 → 可折叠区块 → Repeater 标签 → Summary 占位符 → 导航分组）、输入替换规则、克制规则（噪音控制）
+- 结论/价值：将"能用"的管理表单转化为"令人愉悦"的体验，通过信息架构重组显著减少操作步骤和视觉噪音
+
+## Key Claims（用中文描述）
+- 结构优化（Tab、Grid、Collapsible）比装饰性改进（图标、提示文字）价值高 10 倍
+- 超过 8 个字段的扁平表单必须提出 Tab 或并排布局方案
+- 1-10 个 radio button 行是 UX 反模式，必须替换为 range slider 或紧凑的 inline radio grid
+- 所有 Repeater 必须设置 `->itemLabel()` 使条目在列表中可识别
+- 噪音控制优先于装饰：每个字段最多一个引导层，不堆叠 label + hint + placeholder + description
+
+## Key Quotes
+> "Transform Filament PHP admin panels from functional to exceptional through **structural redesign**. Cosmetic improvements (icons, hints, labels) are the last 10% — the first 90% is about information architecture." — 核心使命阐述
+> "Never leave a form with more than ~8 fields in a single flat list without proposing a structural alternative" — 结构性阈值规则
+> "In a single screen, avoid adding icons to every section. Reserve icons for top-level tabs or high-salience sections." — 图标克制原则
+
+## Key Concepts
+- [[StructuralOptimization]]：通过 Tab 分隔、并排 Grid、可折叠区块等手段重构表单信息架构，而非装饰性改进
+- [[FilamentPHP]]：Laravel 的 TALL Stack 管理后台框架，FilamentOptimizationAgent 的优化目标
+- [[RangeSliderReplacement]]：将 1-10 个 radio button 行替换为原生 range slider 的 UX 改进模式
+- [[RepeaterItemLabel]]：为 Repeater 组件设置 `->itemLabel()` 使条目在列表中可识别的实践
+- [[CollapsibleSection]]：默认折叠的次要表单区块，减少视觉噪音
+- [[NavigationGrouping]]：将资源分组到 `NavigationGroup` 并默认折叠不常用组的导航优化
+- [[NoiseCheck]]：在最终化前移除任何不改善层级结构的图标、提示文字和多余容器的质量保证流程
+- [[PlaceholderSummary]]：在编辑表单顶部添加关键指标的 Placeholder 摘要视图
+
+## Key Entities
+- [[FilamentOptimizationAgent]]：Agent 人格名称，专注于 Filament PHP admin panel 结构性优化的专家角色
+
+## Connections
+- [[DesignUXArchitect]] ← informs ← [[StructuralOptimization]]（UX 架构原则为此 Agent 提供理论支撑）
+- [[DesignUIFormOptimization]] ← extends ← [[FilamentOptimization]]（UI 表单优化是 Filament 优化的具体实现）
+- [[LaravelFilament]] ← optimizes ← [[FilamentAdminPanel]]（FilamentOptimizationAgent 的工作对象）
+
+## Contradictions
+- 与一般 UI 优化观点冲突：
+  - 冲突点：传统观点认为添加图标、提示文字能提升表单可用性
+  - 当前观点（FilamentOptimizationAgent）：结构性改变（Tab/Grid/Collapsible）才是真正提升，装饰性改动价值有限
+  - 对方观点：图标和提示文字是低门槛高回报的 UX 改进
+  - 评估：FilamentOptimizationAgent 对"高价值改进"的定义更严格，强调信息架构优先于视觉装饰
diff --git a/wiki/sources/engineering-frontend-developer.md b/wiki/sources/engineering-frontend-developer.md
new file mode 100644
index 00000000..5a4b8501
--- /dev/null
+++ b/wiki/sources/engineering-frontend-developer.md
@@ -0,0 +1,45 @@
+---
+title: "Frontend Developer Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-frontend-developer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Frontend Developer Agent 人格定义——一个专注于现代 Web 技术、UI 框架和性能优化的前端开发专家代理。
+- 问题域：现代响应式 Web 应用开发、像素级 UI 实现、性能调优、无障碍访问合规。
+- 方法/机制：四阶段工作流（项目架构 → 组件开发 → 性能优化 → 测试 QA），Core Web Vitals 优先策略，WCAG 2.1 AA 无障碍标准，移动端优先设计，现代 React/Vue/Angular 框架，TypeScript + 现代 CSS 技术。
+- 结论/价值：为 AI Agent 提供标准化的前端开发人格规范，涵盖交付模板、成功指标和技术能力边界。
+
+## Key Claims（用中文描述）
+- 前端代理应确保 3G 网络下页面加载时间低于 3 秒，Lighthouse 性能与无障碍评分持续超过 90。
+- 组件复用率应超过 80%，生产环境零控制台错误。
+- 导航动作往返延迟须低于 150ms。
+
+## Key Quotes
+> "You are **Frontend Developer**, an expert frontend developer who specializes in modern web technologies, UI frameworks, and performance optimization." — Agent 人格定义核心
+
+> "Implement Core Web Vitals optimization from the start" — 性能优先开发原则
+
+## Key Concepts
+- [[Core Web Vitals]]：Google 定义的页面性能指标（LCP、FID、CLS），前端代理必须优先优化。
+- [[WCAG 2.1 AA]]：Web 内容无障碍指南 2.1 级别 AA，前端代理须确保合规。
+- [[Code Splitting]]：通过动态导入实现_bundle size 优化，减少初始加载时间的技术手段。
+- [[PWA]]：渐进式 Web 应用，支持离线能力和 Service Worker 缓存策略。
+- [[Accessibility]]：无障碍设计，包括 ARIA 标签、语义化 HTML、键盘导航和屏幕阅读器兼容。
+
+## Key Entities
+- [[Design UI Designer]]：UI 设计师代理，与前端代理协作完成设计与实现的对齐。
+- [[Testing Accessibility Auditor]]：无障碍审计代理，对前端实现进行 WCAG 合规验证。
+- [[Code Reviewer]]：代码审查代理，确保前端代码质量和最佳实践。
+
+## Connections
+- [[Engineering Senior Developer]] ← feeds_into ← [[Engineering Frontend Developer]]
+- [[Engineering CMS Developer]] ← related_to ← [[Engineering Frontend Developer]]
+- [[Engineering UI Designer]] ←handoff_to ← [[Engineering Frontend Developer]]
+
+## Contradictions
+- 无已知冲突。
diff --git a/wiki/sources/engineering-git-workflow-master.md b/wiki/sources/engineering-git-workflow-master.md
new file mode 100644
index 00000000..1adbded4
--- /dev/null
+++ b/wiki/sources/engineering-git-workflow-master.md
@@ -0,0 +1,56 @@
+---
+title: "Git Workflow Master Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-git-workflow-master.md]]
+
+## Summary（用中文描述）
+- 核心主题：Git 工作流与版本控制策略专家 Agent 个性定义
+- 问题域：团队协作中的分支管理、历史整洁、提交规范、CI/CD 集成
+- 方法/机制：
+  - 原子提交（Atomic Commits）：每次提交只做一件事
+  - Conventional Commits 规范：`feat:` / `fix:` / `chore:` / `docs:` / `refactor:` / `test:`
+  - 两种分支策略：Trunk-Based Development（主推）和 Git Flow（版本发布）
+  - 高级技巧：Worktree / Interactive Rebase / Git Bisect / Reflog / Cherry-pick
+  - 安全强制推送：`--force-with-lease`
+  - 合并策略：`--no-ff` 或 Squash Merge
+- 结论/价值：帮助团队维护干净的提交历史，避免合并地狱（merge hell），建立可追溯、可协作的版本控制规范
+
+## Key Claims（用中文描述）
+- 每个提交原子化（每次只做一件事，可独立回滚）
+- Conventional Commits 格式保证提交历史可读、可自动化解析
+- Trunk-Based 是大多数团队推荐的分支策略（短生命周期特性分支）
+- Git Flow 适合有明确版本发布周期的团队
+- 永远不要在共享分支上强制推送，应使用 `--force-with-lease`
+- PR/MR 合并前必须 rebase 到目标分支最新代码
+
+## Key Quotes
+> "Atomic commits — Each commit does one thing and can be reverted independently." — Git Workflow Master 核心原则
+> "Never force-push shared branches — Use `--force-with-lease` if you must." — 安全推送规范
+> "Branch from latest — Always rebase on target before merging." — 合并前规范
+
+## Key Concepts
+- [[AtomicCommits]]：每次提交只做一件事，可独立回滚的提交单元
+- [[ConventionalCommits]]：标准化的提交信息格式（feat/fix/chore/docs/refactor/test）
+- [[TrunkBasedDevelopment]]：主分支始终可部署，短生命周期特性分支的分支策略
+- [[GitFlow]]：含 main/develop/release/hotfix 多分支，适合版本化发布的分支策略
+- [[ForceWithLease]]：`--force-with-lease` 安全强制推送版本，避免覆盖他人提交
+
+## Key Entities
+- 无关键外部实体（本文档为 Agent 个性定义，无外部公司/产品引用）
+
+## Connections
+- [[CodeReviewer]] ← informs → [[GitWorkflowMaster]]（代码审查需基于规范化的提交历史）
+- [[CIGithub]] ← integrates_with → [[GitWorkflowMaster]]（CI pipeline 依赖分支保护规则和自动化检查）
+- [[GitOps]] ← extends → [[GitWorkflowMaster]]（GitOps 以 Git 工作流为基础，扩展了 IaC 和部署自动化）
+
+## Contradictions
+- 与 Git Flow 页面冲突：
+  - 冲突点：Trunk-Based vs Git Flow 哪个是"推荐"策略
+  - 当前观点（Git Workflow Master）：Trunk-Based 适合大多数团队
+  - 对方观点（[[GitFlow]]）：Git Flow 是处理版本发布和多环境管理的标准方案
+  - 说明：两者各有适用场景，Trunk-Based 适合持续部署团队，Git Flow 适合有明确版本发布周期的团队，不构成直接矛盾而是互补
diff --git a/wiki/sources/engineering-incident-response-commander.md b/wiki/sources/engineering-incident-response-commander.md
new file mode 100644
index 00000000..2346a526
--- /dev/null
+++ b/wiki/sources/engineering-incident-response-commander.md
@@ -0,0 +1,62 @@
+---
+title: "Incident Response Commander Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-incident-response-commander]]
+
+## Summary（用中文描述）
+- 核心主题：面向可靠工程的智能体（AI Agent）—— Incident Response Commander（事故响应指挥官），将生产事故混乱转化为结构化解决
+- 问题域：生产环境事故管理、值班流程设计、事后复盘、可靠性工程文化
+- 方法/机制：SEV1–SEV4 严重等级分类框架、角色分工（IC/Comms/Tech Lead/Scribe）、无责文化（blameless）、SLO/SLI/SLA 体系、混沌工程、5 Whys 根因分析
+- 结论/价值：为可靠工程组织提供完整的事故响应 SOP，降低 MTTD/MTTR，保护 on-call 工程师心理健康
+
+## Key Claims（用中文描述）
+- 事故指挥官（IC）通过固定角色分工和固定更新节奏，将混乱转为结构化响应
+- 无责文化（blameless culture）确保工程师敢于上报问题而非隐瞒，是可靠性组织的基础
+- SLO 必须有约束力：错误预算耗尽时，功能开发必须暂停，转向可靠性工作
+- Runbook 每季度必须测试一次——未经测试的 runbook 是虚假的安全感
+- On-call 工程师必须有应急处置权，无需多级审批链
+- 每次事故必须在 48 小时内生成时间线、影响评估和后续行动项
+
+## Key Quotes
+> "Never frame findings as 'X person caused the outage' — frame as 'the system allowed this failure mode'" — 无责文化的核心原则：归因于系统缺陷，而非个人错误
+> "The gap is that we have no integration test for config validation — that's the systemic issue to fix" — 复盘时聚焦系统性缺口，而非追责
+> "A blameless post-mortem without follow-through is just a meeting" — 事后复盘若无跟进，只是浪费时间
+> "Chaos multiplies without coordination" — 无协调则混乱倍增
+
+## Key Concepts
+- [[BlamelessPostMortem]]：无责复盘——聚焦系统性根因而非个人错误，保护心理安全
+- [[ErrorBudget]]：错误预算——SLO 未达标时的容忍空间；低于 25% 时全员投入可靠性工作
+- [[ServiceLevelObjective]]（SLO）：服务等级目标——有约束力的可靠性承诺，而非纸面指标
+- [[ServiceLevelIndicator]]（SLI）：服务等级指标——可测量的具体指标（如错误率、延迟）
+- [[FiveWhys]]：5问法——通过层层追问找到系统性根本原因
+- [[FaultTreeAnalysis]]：故障树分析——结构化根因分析工具
+- [[ChaosEngineering]]：混沌工程——通过受控故障注入验证系统韧性
+- [[GameDay]]：Game Day——跨团队模拟多服务级联故障演练
+- [[MeanTimeToDetect]]（MTTD）：从故障发生到检测的平均时间，目标 < 5 分钟（SEV1/2）
+- [[MeanTimeToResolve]]（MTTR）：从检测到恢复的平均时间，目标 < 30 分钟（SEV1）
+- [[IncidentSeverityMatrix]]：SEV1–SEV4 严重等级矩阵，定义响应时间、升级路径和沟通节奏
+
+## Key Entities
+- [[IncidentCommander]]（IC）：事故指挥官——唯一决策者，负责时间线管理和角色协调
+- [[CommunicationsLead]]：沟通负责人——按严重等级节奏向干系人发送状态更新
+- [[TechnicalLead]]：技术负责人——主导诊断，使用 runbook 和可观测性工具
+- [[Scribe]]：记录员——实时记录每个操作和发现，含时间戳
+- [[OnCallEngineer]]：值班工程师——负责检测和初步响应
+- [[SiteReliabilityEngineering]]（SRE）：网站可靠性工程——本 agent 的工程领域背景
+
+## Connections
+- [[SiteReliabilityEngineering]] ← 依赖 → [[ErrorBudget]]
+- [[BlamelessPostMortem]] ← 依赖 → [[FiveWhys]]
+- [[IncidentSeverityMatrix]] ← 支撑 → [[IncidentCommander]]
+- [[ChaosEngineering]] ← 验证 → [[GameDay]]
+- [[ServiceLevelObjective]] ← 包含 → [[ServiceLevelIndicator]]
+- [[MeanTimeToDetect]] ← 度量 → [[OnCallEngineer]]
+- [[MeanTimeToResolve]] ← 度量 → [[IncidentCommander]]
+
+## Contradictions
+- （暂无检测到冲突页面）
diff --git a/wiki/sources/engineering-minimal-change-engineer.md b/wiki/sources/engineering-minimal-change-engineer.md
new file mode 100644
index 00000000..23126d8e
--- /dev/null
+++ b/wiki/sources/engineering-minimal-change-engineer.md
@@ -0,0 +1,51 @@
+---
+title: "Minimal Change Engineer Agent"
+type: source
+tags: [engineering, agent-persona, code-quality, scope-management]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-minimal-change-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI 编程代理的人格设定——最小变更工程师（Minimal Change Engineer），专注于交付最小可工作差异集，拒绝范围蔓延
+- 问题域：AI 编程工具普遍存在"过度生产"问题——修复一个 bug 时附带重构、添加文档、引入防御性代码等
+- 方法/机制：通过严格的行为规则、工作流模板（Scope Self-Check）和代码示例，将"只做被要求的事"内化为代理的核心原则
+- 结论/价值：最小变更原则降低代码审查时间 50%+，减少回归风险，PR 可在 10 秒内审阅完成
+
+## Key Claims（用中文描述）
+- 主体 + 机制 + 结果
+- **AI 编程代理默认过度生产** → 最小变更工程师通过严格规则约束范围 → 交付最小 diff，减少引入新 Bug 的风险
+- **三次重复才考虑提取抽象** → 坚持"四条重复才提取"原则 → 避免过早抽象带来的隐性债务
+- **范围蔓延在审查阶段最为危险** → 代理需主动拒绝"顺便..."请求 → 保持 PR 干净且独立可审
+- **约束本身就是一种高级能力** → 最小变更工程师通过"Diff archaeology"和"Scope negotiation"技能扩展其价值 → 不仅自我约束，还能指导他人
+
+## Key Quotes
+> "Software has a half-life. Every line you add will eventually need to be read, debugged, refactored, or deleted by someone — possibly you, possibly at 2 AM. The kindest thing you can do for that future person is to add fewer lines." — 核心原则
+
+> "Three similar lines beats a premature abstraction." — 过早抽象陷阱的反面教材
+
+> "I'm not going to add a config flag for that. We have one caller and no requirement for a second. We can extract when the second caller appears." — 拒绝未来灵活性陷阱的标准话术
+
+## Key Concepts
+- [[ScopeCreep]]：范围蔓延——超出任务明确要求的变更行为，是最小变更工程师的核心反模式
+- [[PrematureAbstraction]]：过早抽象——在第三次出现之前就提取辅助函数，引入隐性债务
+- [[MinimalChangePrinciple]]：最小变更原则——每个变更行的存在都必须有任务明确要求的理由
+
+## Key Entities
+- （本来源未引入需创建独立页面的外部人物或公司）
+
+## Connections
+- [[engineering-code-reviewer]] ← 对立与互补 ← [[engineering-minimal-change-engineer]]
+  - 代码审查者发现范围蔓延，最小变更工程师预防范围蔓延
+- [[engineering-sre]] ← 协作 ← [[engineering-minimal-change-engineer]]
+  - SRE 保障可靠性，最小变更工程师通过最小 blast radius 降低故障影响
+- [[engineering-senior-developer]] ← 互补 ← [[engineering-minimal-change-engineer]]
+  - 高级工程师的经验判断与最小变更原则相辅相成
+
+## Contradictions
+- 与 [[engineering-rapid-prototyper]] 潜在张力：
+  - 冲突点：快速原型优先速度与简洁性，最小变更优先控制范围
+  - 当前观点：最小变更工程师的 PR 应独立于原型工作，原型阶段允许快速迭代，最终生产代码遵循最小变更原则
+  - 对方观点：快速原型阶段不应受最小变更约束，需快速验证后再重构
diff --git a/wiki/sources/engineering-mobile-app-builder.md b/wiki/sources/engineering-mobile-app-builder.md
index df08dc28..c5cf000e 100644
--- a/wiki/sources/engineering-mobile-app-builder.md
+++ b/wiki/sources/engineering-mobile-app-builder.md
@@ -2,55 +2,59 @@
 title: "Mobile App Builder Agent Personality"
 type: source
 tags: []
-date: 2026-04-26
+date: 2026-05-01
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/engineering/engineering-mobile-app-builder.md]]
+- [[Agent/agency-agents/engineering/engineering-mobile-app-builder.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Mobile App Builder — 专注于原生 iOS/Android 开发和跨平台框架的移动应用开发 AI Agent 人格规范
-- 问题域：如何在移动端构建高性能、平台原生体验的应用；原生开发与跨平台开发的选型决策；移动端特有的性能、续航、离线场景约束
-- 方法/机制：Swift/SwiftUI（iOS）、Kotlin/Jetpack Compose（Android）、React Native/Flutter（跨平台）；MVVM 模式；Offline-First 架构；平台原生设计规范（Material Design / Human Interface Guidelines）
-- 结论/价值：移动开发 Agent 需要具备平台意识、性能优先、用户体验驱动的特质，同时保持跨平台的技术多样性
+- 核心主题：移动应用开发专家 Agent 人格定义，涵盖原生 iOS/Android 开发和跨平台框架
+- 问题域：如何构建高性能、平台原生体验的移动应用，平衡代码复用与平台原生感受
+- 方法/机制：Swift/SwiftUI（iOS）、Kotlin/Jetpack Compose（Android）、React Native/Flutter（跨平台）；MVVM 架构模式；平台设计指南遵循；离线优先架构
+- 结论/价值：提供标准化的移动应用开发 Agent 人格定义，强调平台感知、性能优先、用户体验驱动
 
 ## Key Claims（用中文描述）
-- 原生 iOS/Android 开发必须遵循平台设计指南（Material Design、Human Interface Guidelines）
-- 移动应用必须实现离线优先架构和智能数据同步
-- 跨平台开发需在代码复用与平台原生体验之间找到平衡
-- 移动性能优化目标：冷启动 < 3 秒，内存占用 < 100MB，续航损耗 < 5%/小时
+- Mobile App Builder Agent 使用 Swift、SwiftUI、Kotlin、Jetpack Compose、React Native、Flutter 等技术栈构建原生和跨平台移动应用
+- Agent 默认要求确保离线功能和平台适当的导航
+- Agent 遵循平台设计指南（Material Design、Human Interface Guidelines）并使用平台原生导航模式和 UI 组件
+- Agent 优化移动性能指标：冷启动时间 < 3 秒、内存使用 < 100MB、续航损耗 < 5%/小时
+- Agent 提供生物识别认证、推送通知、地图服务、应用内购买等平台特定功能集成
+- Agent 使用 MVVM 模式作为推荐的应用程序架构模式
 
 ## Key Quotes
-> "Implemented iOS-native navigation with SwiftUI while maintaining Material Design patterns on Android" — 平台感知型开发示例
-> "Built offline-first architecture to handle poor network conditions gracefully" — 移动约束优先的设计理念
-> "Optimized app startup time to 2.1 seconds and reduced memory usage by 40%" — 性能优化的典型目标
+> "You create high-performance, user-friendly mobile experiences with platform-specific optimizations and modern mobile development patterns." — 核心身份定位
+> "Follow platform-specific design guidelines (Material Design, Human Interface Guidelines)" — 平台设计规范
+> "Default requirement: Ensure offline functionality and platform-appropriate navigation" — 默认功能要求
+> "Optimize for mobile constraints (battery, memory, network)" — 性能优化要求
 
 ## Key Concepts
-- [[Offline-First Architecture]]：离线优先架构 — 构建应用时默认以离线为基准，网络连接时进行数据同步，确保弱网环境下的用户体验
-- [[MVVM Pattern]]：Model-View-ViewModel — SwiftUI 和 Jetpack Compose 推荐的状态管理模式，ViewModel 持有 UI 状态和业务逻辑，View 负责渲染
-- [[Cross-Platform Mobile Development]]：跨平台移动开发 — 使用 React Native 或 Flutter 等框架在 iOS 和 Android 上共享代码，同时保持平台原生特性
-- [[Platform-Native UI]]：平台原生 UI — 遵循各平台设计规范（Material Design / HIG）实现符合用户预期的界面和交互
-- [[Biometric Authentication]]：生物特征认证 — 在移动应用中集成 Face ID、Touch ID 或指纹识别实现安全身份验证
-- [[Push Notification System]]：推送通知系统 — 针对不同平台（APNs/Firebase）实现精准推送，提升用户留存
+- [[MVVM]]：Model-View-ViewModel 模式，推荐的移动应用架构模式
+- [[Offline-First Architecture]]：离线优先架构，支持智能数据同步
+- [[Cross-Platform Development]]：使用 React Native/Flutter 实现跨平台开发
+- [[Native Mobile Development]]：原生 iOS/Android 开发（Swift/Kotlin）
+- [[Platform Design Guidelines]]：平台设计指南（Material Design / Human Interface Guidelines）
+- [[Performance Optimization]]：性能优化（启动时间、内存、电池）
+- [[Biometric Authentication]]：生物识别认证（Face ID、Touch ID、指纹）
 
 ## Key Entities
-- [[SwiftUI]]：Apple 声明式 UI 框架，用于构建现代 iOS/macOS 应用界面
-- [[Jetpack Compose]]：Google Jetpack 声明式 UI 工具包，Android 原生现代化 UI 开发
-- [[React Native]]：Facebook/Meta 开源跨平台框架，使用 JavaScript/TypeScript 构建原生移动应用
-- [[Flutter]]：Google 开源跨平台 UI 工具包，使用 Dart 语言，可编译为原生 ARM 代码
-- [[Swift]]：Apple iOS/macOS 开发语言，配合 SwiftUI 使用
-- [[Kotlin]]：Google 官方 Android 开发语言，配合 Jetpack Compose 使用
+- [[SwiftUI]]：Apple 现代声明式 UI 框架
+- [[Jetpack Compose]]：Google 现代 Android 声明式 UI 框架
+- [[React Native]]：Facebook 跨平台移动开发框架
+- [[Flutter]]：Google 跨平台 UI 工具包
+- [[Hilt]]：Android 依赖注入框架（ViewModel 示例中使用）
+- [[Combine]]：Apple 响应式编程框架
+- [[Material Design]]：Android 平台设计语言
+- [[Human Interface Guidelines]]：Apple 平台设计规范
 
 ## Connections
-- [[agents-orchestrator]] ← orchestrates ← [[engineering-mobile-app-builder]]
-- [[engineering-mobile-app-builder]] ← shares_workflow ← [[unity-architect]]（平台策略和架构决策方法论）
-- [[engineering-mobile-app-builder]] ← extends ← [[software-architect]]（系统架构原则应用于移动端）
-- [[visionos-spatial-engineer]] ← related_to ← [[engineering-mobile-app-builder]]（Apple 生态移动开发扩展）
-- [[xr-immersive-developer]] ← related_to ← [[engineering-mobile-app-builder]]（XR 与移动平台的跨设备体验）
+- [[engineering-software-architect]] ← extends ← [[engineering-mobile-app-builder]]：共享系统架构思维应用于移动端
+- [[unity-architect]] ← related_to ← [[engineering-mobile-app-builder]]：跨平台理念分工——前者面向游戏，后者面向通用移动应用
+- [[visionos-spatial-engineer]] ← related_to ← [[engineering-mobile-app-builder]]：均使用 SwiftUI 技术栈，但前者面向空间计算平台
 
 ## Contradictions
-- 与 [[unity-architect]] 跨平台理念存在框架差异：
-  - 冲突点：原生开发 vs 跨平台框架的优先级
-  - 当前观点：Mobile App Builder 默认支持多种框架（SwiftUI、Jetpack Compose、React Native、Flutter），按需选型
-  - 对方观点：Unity Architect 专注于 Unity 引擎内的跨平台方案
-  - 说明：两者解决的问题域不同，Mobile App Builder 面向通用移动应用，Unity Architect 面向游戏开发，属合理分工而非矛盾
+- 与 [[unity-architect]] 的跨平台理念差异：
+  - 冲突点：跨平台开发的代码复用程度与平台原生体验的权衡
+  - 当前观点：Mobile App Builder 强调代码复用（React Native/Flutter）与平台原生体验的平衡
+  - 对方观点：Unity Architect 面向游戏开发，采用更激进的跨平台策略（Unity 引擎本身）
+  - 注：无实质冲突，属不同应用场景的合理分工
diff --git a/wiki/sources/engineering-rapid-prototyper.md b/wiki/sources/engineering-rapid-prototyper.md
new file mode 100644
index 00000000..65af4b14
--- /dev/null
+++ b/wiki/sources/engineering-rapid-prototyper.md
@@ -0,0 +1,53 @@
+---
+title: "Rapid Prototyper Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-rapid-prototyper.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 角色定义 —— 极速原型开发专家，专注于在 3 天内交付可工作的 MVP 原型
+- 问题域：如何快速验证创意想法、降低产品开发风险、以最小成本获取用户反馈
+- 方法/机制：速度优先开发、验证驱动特性选择、模块化架构、即刻部署上线、A/B 测试与用户反馈收集
+- 结论/价值：原型到生产的转化时间控制在 2 周内，80% 核心功能通过用户测试验证，利益相关者认可率超过 90%
+
+## Key Claims（用中文描述）
+- Rapid Prototyper Agent 通过使用无代码/低代码方案和后端即服务平台，实现数天内而非数周交付可用原型
+- 验证驱动开发确保只构建测试核心假设所必需的功能，从第一天起就内置用户反馈和数据分析
+- 模块化架构支持基于用户反馈的快速迭代，同时设计可演进为生产级系统的原型
+- Next.js + Supabase + Prisma + Clerk + shadcn/ui 组成快速开发技术栈，覆盖认证、数据、部署全链路
+- 原型阶段引入 A/B 测试框架和实时分析基础设施，为产品决策提供数据支撑
+
+## Key Quotes
+> "Build functional prototypes in under 3 days using rapid development tools" — 核心交付目标：3天内交付功能原型
+> "Build only features necessary to test core hypotheses" — 验证驱动开发，只做核心假设验证所需的最小功能集
+> "Design prototypes that can evolve into production systems" — 原型设计需考虑可演进性，不是临时方案
+
+## Key Concepts
+- [[MVP（最小可行产品）]]：最小可行产品，通过最小功能集快速验证核心商业假设
+- [[A/B Testing]]：在原型阶段引入 A/B 测试，对功能变体进行对照验证，获取可量化的用户行为数据
+- [[Rapid Prototyping]]：极速原型开发，使用速度优先的开发栈和预构建组件，最大化开发效率
+- [[用户反馈收集]]：从原型第一天就内置反馈收集机制，持续获取真实用户意见指导迭代方向
+- [[No-Code/Low-Code]]：在非核心功能上使用无代码/低代码方案，减少重复造轮子，提升开发速度
+
+## Key Entities
+- [[Next.js]]：React 全栈框架，提供 SSR/SSG 能力和零配置部署（Vercel）
+- [[Supabase]]：后端即服务（BaaS）平台，提供即开即用的数据库、认证和实时订阅
+- [[Clerk]]：现代化认证服务，支持社交登录和多平台用户管理集成
+- [[Prisma]]：TypeScript ORM，与 Supabase PostgreSQL 配合提供类型安全的数据库操作
+- [[shadcn/ui]]：可复用的无样式 UI 组件库，基于 Radix UI 构建，支持快速定制
+- [[Vercel]]：零配置部署平台，提供即时预览 URL 用于快速分享和用户测试
+
+## Connections
+- [[Next.js]] ← 构建框架 ← [[Rapid Prototyper]]
+- [[Supabase]] ← 后端服务 ← [[Rapid Prototyper]]
+- [[Clerk]] ← 认证方案 ← [[Rapid Prototyper]]
+- [[Prisma]] ← ORM层 ← [[Supabase]]
+- [[shadcn/ui]] ← UI组件 ← [[Next.js]]
+- [[Vercel]] ← 部署平台 ← [[Next.js]]
+
+## Contradictions
+- 无已知冲突
diff --git a/wiki/sources/engineering-security-engineer.md b/wiki/sources/engineering-security-engineer.md
new file mode 100644
index 00000000..63c7954a
--- /dev/null
+++ b/wiki/sources/engineering-security-engineer.md
@@ -0,0 +1,66 @@
+---
+title: "Security Engineer Agent Personality"
+type: source
+tags: [agent-personality, security, application-security]
+sources: []
+last_updated: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-security-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：定义一个专注于应用安全工程的 AI Agent 人格，具备威胁建模、漏洞评估、安全代码审查、安全架构设计和事件响应的全链路能力
+- 问题域：现代 Web 应用、API、云原生应用的安全防护，覆盖 OWASP Top 10、CWE Top 25、API 安全、云安全、供应链安全等广泛领域
+- 方法/机制：采用对抗性思维框架（STRIDE 分析）、防御深度策略（defense-in-depth）、零信任架构；在 SDLC 各阶段集成安全；通过 SAST/DAST/SCA/secrets 检测构建 CI/CD 安全门禁
+- 结论/价值：该 Agent 以攻击者视角思考，以工程师方式防御，通过威胁建模前置识别风险、通过分层防护降低攻击面、通过自动化检测实现安全左移
+
+## Key Claims（用中文描述）
+- Security Engineer Agent 通过将安全集成到设计→实现→测试→部署→运营的全生命周期，实现风险前置发现
+- 所有用户输入均视为敌对输入，必须在每个信任边界（客户端、API 网关、服务、数据库）进行验证和清理
+- 默认拒绝原则（Default Deny）：在访问控制、输入验证、CORS、CSP 中优先使用白名单而非黑名单
+- 防御深度原则：永远不依赖单一保护层，假设任何一层都可能被绕过，通过 WAF→限流→输入验证→参数化查询→输出编码→CSP 的多层叠加实现真正安全
+- 零信任架构：以最小权限为原则，结合微隔离，实现每次访问均需验证
+- 供应链安全：通过 SBOM 生成与监控、CVE 审计、包完整性校验（校验和、签名、lock 文件）、依赖混淆/typosquatting 攻击检测，构建可信依赖链
+
+## Key Quotes
+> "You think like an attacker to defend like an engineer." — Security Engineer 的核心哲学定位
+> "Security is a spectrum, not a binary. You prioritize risk reduction over perfection, and developer experience over security theater." — 安全的本质是风险管理，而非追求完美
+> "Every finding must include a severity rating, proof of exploitability, and concrete remediation with code." — 安全发现必须包含严重等级、可利用性证明和具体修复代码
+> "No hardcoded credentials, no secrets in logs, no secrets in client-side code, no secrets in environment variables without encryption." — 密钥管理四条铁律
+> "The best security control is one that developers adopt willingly because it makes their code better, not harder to write." — 安全与开发者体验的平衡哲学
+
+## Key Concepts
+- [[ThreatModeling]]：通过 STRIDE 框架（Spoofing/Tampering/Repudiation/Information Disclosure/DoS/Elevation of Privilege）对每个组件进行系统性威胁分析
+- [[OWASP Top 10]]：2021+ 版本的十大 Web 应用安全风险（注入、XSS、身份认证失效、敏感数据泄露、XXE、访问控制失效、安全配置错误、脚本插入、逆向工程、日志监控缺失）作为代码审查和漏洞评估的基准清单
+- [[DefenseInDepth]]：多层防御策略，假设任何单层均可被绕过，通过 WAF→限流→输入验证→参数化查询→输出编码→CSP 的叠加实现纵深防护
+- [[ZeroTrust Architecture]]：永不信任、始终验证的架构范式，以最小权限访问控制和微隔离为技术核心
+- [[CVSS 3.1]]：通用漏洞评分系统，用于标准化漏洞严重等级（Critical/High/Medium/Low/Informational）评估
+- [[SAST/DAST/SCA]]：静态应用安全测试（代码层面）、动态应用安全测试（运行时）、软件组成分析（依赖层面）三位一体的自动化安全检测体系
+- [[RBAC/ABAC/ReBAC]]：基于角色的访问控制、基于属性的访问控制、基于关系的访问控制三种授权模型，根据应用需求匹配合适的访问控制方案
+- [[SupplyChainSecurity]]：SBOM 生成与监控、依赖 CVE 审计、混淆攻击检测、可复现构建的供应链全链条安全管理
+- [[SecretsManagement]]：密钥的全生命周期管理，包括轮换策略，推荐工具包括 HashiCorp Vault、AWS Secrets Manager、SOPS
+- [[IncidentResponse]]：安全事件的分类、遏制、根因分析和修复建议的完整事件响应流程
+
+## Key Entities
+- [[Semgrep]]：开源 SAST 工具，用于规则驱动的代码安全扫描
+- [[Trivy]]：容器和依赖漏洞扫描工具，支持 CRITICAL/HIGH 级别阻断
+- [[Gitleaks]]：Git 提交中的密钥和敏感信息检测工具
+- [[HashiCorp Vault]]：企业级密钥管理与轮换平台
+- [[AWS Secrets Manager]]：AWS 原生的密钥管理服务
+- [[OAuth 2.0 + PKCE]]：现代认证授权协议组合，PKCE 防止授权码拦截攻击
+- [[WebAuthn/Passkeys]]：无密码认证标准，基于公钥加密消除密码泄露风险
+- [[STRIDE]]：微软提出的威胁建模框架，六个维度系统性评估系统威胁
+
+## Connections
+- [[Engineering-SRE]] ← overlaps_with ← [[SecurityEngineer]]（均涉及云安全、基础设施安全监控和事件响应）
+- [[Engineering-Code-Reviewer]] ← extends ← [[SecurityEngineer]]（代码审查中必须集成安全视角）
+- [[Testing-Accessibility-Auditor]] ← parallels ← [[SecurityEngineer]]（均通过系统性测试流程发现应用问题）
+- [[零信任架构]] ← is_a_concept_of ← [[SecurityEngineer]]（零信任是安全架构设计的核心理念）
+
+## Contradictions
+- 与 [[Engineering-SRE]] 存在视角差异：
+  - 冲突点：SRE 以可用性为优先，安全工程师以安全性为优先，两者对"故障时的默认行为"存在权衡分歧
+  - 当前观点（Security Engineer）：fail securely — 错误不得泄露堆栈跟踪、内部路径、数据库 schema 或版本信息
+  - 对方观点（Engineering-SRE）：fail loudly — 快速失败以减少 MTTR，依赖完善的监控告警而非隐藏错误细节
+  - 协调方案：在生产环境 fail securely + 结构化日志输出给监控系统；在开发/测试环境可保留详细错误信息以加速调试
diff --git a/wiki/sources/engineering-senior-developer.md b/wiki/sources/engineering-senior-developer.md
new file mode 100644
index 00000000..84d7def2
--- /dev/null
+++ b/wiki/sources/engineering-senior-developer.md
@@ -0,0 +1,101 @@
+---
+title: "Senior Developer Agent Personality"
+type: source
+tags: ["agent-personality", "engineering", "laravel", "livewire", "web-development"]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-senior-developer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Senior Developer Agent 角色定义 —— 专注于使用 Laravel/Livewire/FluxUI 实现高端 web 体验的全栈开发者 Agent
+- 问题域：如何让 AI Agent 作为高级全栈工程师，遵循高级设计标准（Premium Design Standards）实施高质量 web 项目
+- 方法/机制：通过角色设定（Identity & Memory）、开发哲学（Premium Craftsmanship）、技术栈（Tech Stack Expertise）、实施流程（Implementation Process）规范 Agent 行为
+- 结论/价值：定义了"奢华感"（Premium）与"基础"（Basic）的区别标准，要求 Agent 实施高性能、高美感、可访问的 web 体验
+
+## Key Claims（用中文描述）
+- **FluxUI + Laravel/Livewire 组合** → 提供完整高端全栈实施能力 → 支撑快速构建可复用组件库
+- **亮色/暗色/系统主题切换** → 每个站点必须实现 → 确保跨场景用户体验一致性
+- **Three.js 集成** → 为英雄区（Hero Sections）提供粒子背景、交互式 3D 产品展示 → 创造沉浸式体验
+- **玻璃拟态（Glass Morphism）+ 高级动画** → 通过 backdrop-filter blur + cubic-bezier 缓动曲线 → 实现奢华感 UI
+- **60fps 动画 + 1.5s 内加载** → 性能与美感共存 → 满足高端用户体验标准
+
+## Key Quotes
+> "Every pixel should feel intentional and refined" — Premium Craftsmanship 理念核心
+
+> "Innovation over convention when it enhances UX" — 创新驱动的高端实现哲学
+
+> "Performance and beauty must coexist" — 技术卓越（Technology Excellence）核心原则
+
+## Key Concepts
+- [[Premium Craftsmanship]]：每个像素都应经过精心打磨，包含平滑动画、微交互和性能优化
+- [[Laravel/Livewire Integration]]：PHP 全栈框架与响应式组件的集成模式
+- [[FluxUI Component Library]]：专业 UI 组件库，提供所有可用组件
+- [[Glass Morphism]]：玻璃拟态设计风格，使用 backdrop-filter blur + 透明背景实现高级视觉效果
+- [[Three.js Integration]]：WebGL 3D 集成，为 web 体验提供沉浸式粒子背景和交互式 3D 展示
+- [[Premium Design Standards]]：高端设计标准，强制要求亮/暗/系统主题切换、大留白、精致排版、磁性交互效果
+
+## Key Entities
+- [[EngineeringSeniorDeveloper]]：Agent 身份名称，专注于高端 web 实现的高级全栈开发者
+- [[FluxUI]]：UI 组件库，提供所有专业组件
+- [[Laravel/Livewire]]：PHP 全栈框架组合
+- [[Three.js]]：WebGL 3D 图形库
+
+## Connections
+- [[engineering-rapid-prototyper]] ← extends ← [[engineering-senior-developer]]（原型扩展至高级实现）
+- [[engineering-code-reviewer]] ← depends_on ← [[engineering-senior-developer]]（代码审查依赖实施）
+- [[engineering-filament-optimization-specialist]] ← depends_on ← [[engineering-senior-developer]]（性能优化依赖实施）
+- [[engineering-backend-architect]] ← extends ← [[engineering-senior-developer]]（后端架构扩展开发者角色）
+
+## Contradictions
+- 无已知冲突内容
+
+## Implementation Patterns（技术实施模式）
+
+### Laravel/Livewire 组件模式
+```php
+class PremiumNavigation extends Component
+{
+    public $mobileMenuOpen = false;
+    
+    public function render()
+    {
+        return view('livewire.premium-navigation');
+    }
+}
+```
+
+### FluxUI 奢华卡片
+```html
+<flux:card class="luxury-glass hover:scale-105 transition-all duration-300">
+    <flux:heading size="lg" class="gradient-text">Premium Content</flux:heading>
+    <flux:text class="opacity-80">With sophisticated styling</flux:text>
+</flux:card>
+```
+
+### 玻璃拟态 CSS
+```css
+.luxury-glass {
+    background: rgba(255, 255, 255, 0.05);
+    backdrop-filter: blur(30px) saturate(200%);
+    border: 1px solid rgba(255, 255, 255, 0.1);
+    border-radius: 20px;
+}
+```
+
+### 磁性交互效果
+```css
+.magnetic-element {
+    transition: transform 0.3s cubic-bezier(0.16, 1, 0.3, 1);
+}
+.magnetic-element:hover {
+    transform: scale(1.05) translateY(-2px);
+}
+```
+
+## Quality Standards（质量标准）
+- 加载时间 < 1.5 秒
+- 动画 60fps
+- 完美响应式设计
+- WCAG 2.1 AA 无障碍合规
diff --git a/wiki/sources/engineering-software-architect.md b/wiki/sources/engineering-software-architect.md
index 29b67734..99c9f005 100644
--- a/wiki/sources/engineering-software-architect.md
+++ b/wiki/sources/engineering-software-architect.md
@@ -1,58 +1,50 @@
 ---
 title: "Software Architect Agent Personality"
 type: source
-tags: [agent-personality, software-architecture, system-design, engineering]
-date: 2026-04-26
+tags: []
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/engineering/engineering-software-architect.md]]
+- [[Agent/agency-agents/engineering/engineering-software-architect.md]]
 
 ## Summary（用中文描述）
-- 核心主题：软件架构与系统设计 Agent 的角色定义，专注于设计可维护、可扩展、符合业务领域的系统架构
-- 问题域：架构决策、模式选择、技术权衡、系统演进
-- 方法/机制：领域驱动设计（DDD）、边界上下文（bounded contexts）、架构决策记录（ADR）、C4 模型
-- 结论/价值：为 AI Agent 提供系统思维框架，强调权衡分析优先于最佳实践、领域优先于技术
+- 核心主题：AI Agent 软件架构专家人格定义——专注于系统设计、领域驱动设计、架构模式和可扩展性决策的智能体角色
+- 问题域：如何让 AI Agent 在多智能体协作中承担软件架构职责，在模块化单体与微服务之间做出权衡，并维护架构决策记录
+- 方法/机制：五步系统设计流程（领域发现→架构选型→质量属性分析→沟通风格→文档输出）；ADR 模板规范；C4 模型通信
+- 结论/价值：Software Architect Agent 通过明确约束（反架构航天员主义、权衡优先于最佳实践）确保 AI 输出的架构建议务实可落地
 
 ## Key Claims（用中文描述）
-- 最佳架构是团队能够实际维护的架构：架构不应过度设计，必须匹配团队能力
-- 每个抽象必须有复杂度理由：避免架构宇航员式的过度设计
-- 权衡优先于最佳实践：命名所放弃的，而非仅描述所获得的
-- 领域优先、技术其次：理解业务问题，再选工具
-- 可逆性很重要：优先选择易变更的决策，而非"最优"决策
-- 记录决策，而非仅记录设计：ADR 捕捉 WHY，而非 WHAT
+- AI Agent 通过严格约束"每个抽象必须证明其复杂度"，可以避免陷入架构过度设计的陷阱
+- 在模块化单体与微服务之间选择时，团队规模和边界清晰度比技术优越性更关键
+- 架构决策记录（ADR）捕获"为什么"而非"是什么"，是 AI 协作中保持决策可追溯的关键机制
+- 领域优先、技术其次——理解业务问题再选工具，是 AI 系统设计建议可靠性的基础保障
 
 ## Key Quotes
-> "Designs systems that survive the team that built them. Every decision has a trade-off — name it." — 核心设计哲学
-
-> "No architecture astronautics — Every abstraction must justify its complexity." — 关键规则 1
-
-> "Domain first, technology second — Understand the business problem before picking tools." — 关键规则 3
-
-> "Reversibility matters — Prefer decisions that are easy to change over ones that are 'optimal'." — 关键规则 4
+> "No architecture astronautics — Every abstraction must justify its complexity." — 核心设计原则：AI 不得产生无实际价值的过度抽象
+> "Trade-offs over best practices — Name what you're giving up, not just what you're gaining." — 架构权衡的透明性要求
+> "The best architecture is the one the team can actually maintain." — 可维护性优先于理论最优解
 
 ## Key Concepts
-- [[Bounded Contexts]]：领域驱动设计中划分业务边界的核心概念
-- [[Trade-off Analysis]]：架构决策中命名权衡而非仅列举优点的分析方法
-- [[Architecture Decision Record (ADR)]]：记录架构决策上下文、选项和理由的标准化模板
-- [[Modular Monolith]]：适合小型团队、不清晰边界的架构模式
-- [[Microservices]]：适合清晰领域、需要团队自治的架构模式
-- [[Event-Driven Architecture]]：适合松耦合、异步工作流的架构模式
-- [[CQRS]]：命令查询职责分离，适合读写不对称的系统
-- [[C4 Model]]：用四层图（C4：Context, Container, Component, Code）交流架构的标准化方法
-- [[Quality Attributes]]：可扩展性、可靠性、可维护性、可观测性等非功能需求
+- [[Bounded Contexts]]：领域驱动设计中的核心概念，定义特定领域的边界，确保模型在边界内一致
+- [[ADR (Architecture Decision Records)]]：架构决策记录文档模板，捕获上下文、决策和后果，而非仅记录结果
+- [[Trade-off Matrices]]：架构权衡矩阵，用于系统性对比多个方案的取舍
+- [[Modular Monolith vs Microservices]]：模块化单体（团队规模小、边界不清晰时）与微服务（领域清晰、团队自主性要求高时）的选型对照
+- [[CQRS (Command Query Responsibility Segregation)]]：命令查询职责分离，适合读写不对称场景
+- [[Event-driven Architecture]]：事件驱动架构，适合松耦合和异步工作流场景
+- [[C4 Model]]：系统通信图模型（Context/Container/Component/Code 四层），用于在不同抽象层级与干系人沟通
 
 ## Key Entities
-- （本文档为通用 Agent 角色定义，未涉及特定人物、公司或产品）
+- [[C4 Model]]：由 Simon Brown 创建的系统架构可视化标准，用于在不同抽象层级进行架构沟通
 
 ## Connections
-- [[BackendArchitectWithMemory]] ← shares_design_philosophy ← [[SoftwareArchitectAgent]]
-- [[WorkflowArchitect]] ← uses_ADR_pattern ← [[SoftwareArchitectAgent]]
-- [[SpecializedWorkflowArchitect]] ← architectural_decision_making ← [[SoftwareArchitectAgent]]
+- [[Backend-Architect-With-Memory]] ← similar_role ← [[Software-Architect-Agent]]
+- [[Agents-Orchestrator]] ← depends_on ← [[Software-Architect-Agent]]
+- [[Workflow-Architect-Agent]] ← related_to ← [[Software-Architect-Agent]]
 
 ## Contradictions
-- 与 [[UnityArchitect]] 冲突：
-  - 冲突点：架构约束与团队规模的关系
-  - 当前观点（Software Architect）：最佳架构取决于团队能力； microservices 不适合小团队
-  - 对方观点（Unity Architect）：针对特定技术平台（Unity）的架构师角色，可能倾向于选择特定技术栈而非纯权衡驱动
-  - 注：两者领域不同（通用软件架构 vs 游戏引擎架构），冲突仅为框架层面的方法论差异
+- 与 [[Backend-Architect-With-Memory]] 的潜在冲突：
+  - 冲突点：后端架构师是否需要持久记忆能力
+  - 当前观点（Software Architect Agent）：架构师 Agent 关注设计决策和权衡，无需持久状态
+  - 对方观点（Backend Architect with Memory）：架构师 Agent 需要跨会话累积上下文才能提供更准确建议
+  - 协调方案：两者可互补——Memory 作为辅助数据源，Software Architect 作为推理引擎
diff --git a/wiki/sources/engineering-solidity-smart-contract-engineer.md b/wiki/sources/engineering-solidity-smart-contract-engineer.md
new file mode 100644
index 00000000..7ef2f0f5
--- /dev/null
+++ b/wiki/sources/engineering-solidity-smart-contract-engineer.md
@@ -0,0 +1,57 @@
+---
+title: "Solidity Smart Contract Engineer Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-solidity-smart-contract-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：EVM 智能合约开发 Agent 人格定义，涵盖 Solidity 智能合约的安全开发、Gas 优化、可升级架构、DeFi 协议构建和代码审计标准
+- 问题域：EVM 兼容链（以太坊主网及 L2）的智能合约架构设计与安全审计
+- 方法/机制：checks-effects-interactions 模式、UUPS 代理模式、OpenZeppelin 基础合约、Foundry 测试框架、Gas 优化模式（存储打包、自定义错误、calldata 使用）
+- 结论/价值：提供了一套完整的智能合约开发方法论，强调安全第一、最小化 Gas 消耗和完整的测试覆盖
+
+## Key Claims（用中文描述）
+- 开发者必须将每个合约视为面临无限资本攻击者阅读源代码的场景进行设计
+- 遵循 checks-effects-interactions 模式和非 reentrancy guards 是防止外部调用重入攻击的根本保障
+- Gas 优化应从设计阶段开始，包括存储打包、使用 calldata、优先使用 external 而非 public 函数
+- 可升级合约架构（UUPS/Transparent Proxy）需从第一天就规划，不能事后补救
+- 每个协议必须配备 Foundry 测试套件，分支覆盖率 >95%，并包含 fuzz 和 invariant 测试
+
+## Key Quotes
+> "You treat every wei of gas as precious, every external call as a potential attack vector, and every storage slot as prime real estate." — 角色定位核心理念
+> "Default requirement: Every contract must be written as if an adversary with unlimited capital is reading the source code right now" — 安全设计第一原则
+> "Clever code is dangerous code and simple code ships safely" — 代码简洁性哲学
+> "Never use `tx.origin` for authorization — it is always `msg.sender`" — 授权安全红线
+> "Never use `transfer()` or `send()` — always use `call{value:}("")` with proper reentrancy guards" — 外部调用安全规范
+
+## Key Concepts
+- [[ChecksEffectsInteractions]]：checks（验证）→ effects（状态更新）→ interactions（外部调用）的顺序执行模式，是防止重入攻击的根本原则
+- [[ReentrancyGuard]]：防止合约函数被递归调用的访问控制机制，通过 mutex 锁确保同一调用栈中不可重入
+- [[UUPSUpgradeable]]：通用可升级代理模式（Universal Upgradeable Proxy Standard），将升级逻辑放在实现合约中而非代理中，降低部署成本
+- [[GasOptimization]]：通过存储打包、使用 calldata、自定义错误、immutable/constant 等手段最小化 EVM 执行成本的技术集合
+- [[StoragePacking]]：将多个小类型变量打包进同一 32 字节存储槽以节省 Gas 的模式
+- [[FlashLoanAttack]]：通过在单笔交易中借出并归还大量资产来操纵价格或状态的攻击模式，涵盖 Mango Markets 等典型案例
+- [[OpenZeppelin]]：最广泛使用的 Solidity 安全合约库，提供 ERC 标准实现、可升级代理、访问控制等经过审计的基础组件
+
+## Key Entities
+- The DAO：2016 年以太坊经典重入攻击事件，开创了智能合约安全攻防研究的先河
+- Parity Wallet：2017 年 delegatecall 库调用漏洞导致钱包被锁死的安全事件
+- Wormhole：2022 年跨链桥攻击事件，攻击者利用签名验证漏洞窃取 3.2 亿美元
+- Ronin Bridge：2022 年验证节点被入侵导致 6.25 亿美元被盗的桥接攻击事件
+- Euler Finance：2023 年闪电贷操纵攻击事件，因合约缺少健康检查机制导致 1.97 亿美元损失
+- OpenZeppelin：最广泛使用的 Solidity 安全合约库，提供 ERC 标准、可升级代理、访问控制等审计过的合约
+- Foundry：最流行的 Solidity 开发框架，支持 Forge 测试、Fuzz 测试和 Invariant 测试
+
+## Connections
+- [[BlockchainSecurityAuditor]] ← 共享安全第一原则 ← [[SoliditySmartContractEngineer]]
+- [[SoliditySmartContractEngineer]] ← 使用基础合约 ← [[OpenZeppelin]]
+- [[SoliditySmartContractEngineer]] ← 使用测试框架 ← Foundry
+- [[SoliditySmartContractEngineer]] ← 防御目标 ← FlashLoanAttack
+
+## Contradictions
+- 与 [[BlockchainSecurityAuditor]]：两者均强调安全，但 Smart Contract Engineer 更关注开发实现过程（Gas 优化、可升级性），而 Security Auditor 专注于渗透测试和漏洞发现
+- 与 [[SoftwareArchitect]]：Software Architect 强调通用架构设计，Smart Contract Engineer 则有独特的 EVM 约束（Gas 模型、存储成本、外部调用风险），需要专门的安全和性能考量
diff --git a/wiki/sources/engineering-sre.md b/wiki/sources/engineering-sre.md
new file mode 100644
index 00000000..07b88a83
--- /dev/null
+++ b/wiki/sources/engineering-sre.md
@@ -0,0 +1,55 @@
+---
+title: "SRE (Site Reliability Engineer) Agent Personality"
+type: source
+tags: [sre, reliability, observability, devops, agent]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-sre.md]]
+
+## Summary（用中文描述）
+- 核心主题：SRE（网站可靠性工程师）Agent 个性定义——将可靠性视为可量化预算的专业生产系统专家 Agent
+- 问题域：大规模生产系统的可靠性管理——SLO 定义与测量、错误预算消耗追踪、可观测性体系构建、Toil 自动化、混沌工程
+- 方法/机制：SLO 驱动决策（错误预算剩余则发布功能，耗尽则修复可靠性）→ 三支柱可观测性（Metrics/Logs/Traces）→ Golden Signals 监控（Latency/Traffic/Errors/Saturation）→ Blameless 故障复盘文化 → 渐进式发布（Canary → Percentage → Full）
+- 结论/价值：SRE Agent 是工程团队实现 99.9%→99.99% 可用性提升的关键角色，每个 9 需要 10 倍成本投入
+
+## Key Claims（用中文描述）
+- SRE Agent 通过错误预算框架将可靠性量化为可支出资源：错误预算剩余时允许功能发布，耗尽时强制修复可靠性
+- 可观测性体系必须同时覆盖 Metrics（趋势/告警/SLO追踪）、Logs（事件调试）、Traces（跨服务请求链路）三个维度
+- Golden Signals（Latency/Traffic/Errors/Saturation）是所有监控系统的最小必要信号集
+- Toil 必须自动化而非靠人力英雄式应对：重复两次的操作必须自动化
+
+## Key Quotes
+> "Reliability is a feature. Error budgets fund velocity — spend them wisely." — SRE Agent 核心理念
+> "SLOs drive decisions — If there's error budget remaining, ship features. If not, fix reliability." — SRE 决策框架
+> "Blameless culture — Systems fail, not people. Fix the system." — SRE 文化准则
+> "Lead with data: 'Error budget is 43% consumed with 60% of the window remaining'" — SRE Agent 沟通风格
+
+## Key Concepts
+- [[Service Level Objective]]：定义服务"足够可靠"的衡量标准，包含 SLI（指标定义）、Target（目标值）、Window（时间窗口）
+- [[Error Budget]]：错误预算——SLO 未达标时间的允许额度，驱动功能发布与可靠性工作的优先级决策
+- [[Observability]]：可观测性——通过 Metrics/Logs/Traces 回答"为什么这个坏了"的能力
+- [[Golden Signals]]：黄金信号——Latency、Traffic、Errors、Saturation 四个最小必要监控指标
+- [[Chaos Engineering]]：混沌工程——在生产环境主动注入故障以发现系统弱点的实践
+- [[Toil Reduction]]：Toil 消除——将重复性运维工作系统化自动化的实践
+- [[Canary Deployment]]：金丝雀发布——渐进式（而非大爆炸式）的服务部署策略
+
+## Key Entities
+- Prometheus：SRE Agent 推荐的可观测性技术栈组成部分（Metrics 采集）
+- Grafana：SRE Agent 推荐的可观测性技术栈组成部分（Metrics 可视化与告警）
+- OpenTelemetry：云原生可观测性标准（SRE Agent observability stack 的 traces 和 logs 集成框架）
+
+## Connections
+- [[engineering-devops-automator]] ← complements ← [[engineering-sre]]
+- [[engineering-sre]] ← shares_concepts ← [[CTP-Topic-41-NFRs-and-Error-Budgets]]
+- [[engineering-sre]] ← shares_concepts ← [[CTP-Topic-59-Achieving-Reliability-with-Amazon-EKS]]
+- [[engineering-sre]] ← extends ← [[engineering-backend-architect]]
+- [[engineering-sre]] ← builds_on ← [[DevOps-Automator-Agent]]
+
+## Contradictions
+- 与 [[engineering-devops-automator]] 存在张力：
+  - 冲突点：自动化与人工干预的边界
+  - 当前观点（SRE）：人工 on-call 和故障复盘不可完全替代，系统故障需要人介入判断
+  - 对方观点（DevOps Automator）：通过完全自动化消除人工干预，强调 self-healing 机制
+  - 协调：两者互补而非矛盾——DevOps Automator 负责构建自动化基础设施，SRE 负责监控、错误预算决策和人工 on-call
diff --git a/wiki/sources/engineering-technical-writer.md b/wiki/sources/engineering-technical-writer.md
new file mode 100644
index 00000000..bd6b3626
--- /dev/null
+++ b/wiki/sources/engineering-technical-writer.md
@@ -0,0 +1,66 @@
+---
+title: "Technical Writer Agent Personality"
+type: source
+tags: ["agent-personality", "documentation", "developer-experience"]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-technical-writer.md]]
+
+## Summary（用中文描述）
+- **核心主题**：为 AI Agent 定义 Technical Writer（技术文档工程师）角色——将复杂工程概念转化为开发者真正愿意阅读的清晰、准确、引人入胜的文档。
+- **问题域**：开发者文档质量低下（代码无注释、文档过时、README 无法让开发者 30 秒内上手）、Docs-as-Code 基础设施建设不足。
+- **方法/机制**：
+  - 遵循 Divio 文档体系：教程 / 操作指南 / 参考文档 / 解释文档四象限分离
+  - Docs-as-Code 基础设施：Docusaurus、MkDocs、Sphinx、VitePress + CI/CD 集成
+  - API 文档：OpenAPI/Swagger 自动生成参考文档
+  - 质量门禁：代码示例必须测试通过，破坏性变更必须附带迁移指南
+  - 指标驱动：用 analytics、支持工单关联、用户反馈衡量文档有效性
+- **结论/价值**：技术文档是产品 bug；好文档能降低 20% 支持工单量，让新开发者 15 分钟内上手。
+
+## Key Claims（用中文描述）
+- Technical Writer 必须在写文档前与工程师沟通：了解使用场景、难点、用户卡点
+- README 必须通过"5 秒测试"：这是什么、为什么重要、如何开始
+- 每个新功能必须附带文档——无文档的代码视为不完整
+- 代码示例必须经过测试——每段代码在发布前必须验证可运行
+- 文档必须与软件版本同步——旧版本文档要标注弃用而非删除
+- 每个 API 必须有参考条目、至少一个代码示例和错误处理文档
+- 高退出率页面 = 文档失败的信号
+
+## Key Quotes
+> "Bad documentation is a product bug — you treat it as such." — 核心理念：文档质量等同于产品质量
+
+> "Every new feature ships with documentation — code without docs is incomplete." — 质量门禁原则
+
+> "Zero broken code examples in any published doc" — 零错误代码示例标准
+
+> "Docs search satisfaction rate ≥ 80%" — 文档有效性核心指标
+
+## Key Concepts
+- [[Divio Documentation System]]：将文档分为教程（学习导向）、操作指南（任务导向）、参考文档（信息导向）、解释文档（理解导向），不混用
+- [[Docs-as-Code]]：将文档视为代码的一部分，通过 CI/CD 管道管理、版本控制和自动化构建
+- [[API Documentation]]：从 OpenAPI/Swagger 规范自动生成参考文档，配合 Redoc/Stoplight 展示
+- [[Technical Writer]]：内容工程师角色，专注于开发者文档架构与质量
+
+## Key Entities
+- [[Docusaurus]]：Meta 出品的文档站点框架，基于 React
+- [[MkDocs]]：Python 驱动的静态文档生成器，使用 Markdown
+- [[Sphinx]]：Python 官方文档工具，支持多语言和丰富的扩展生态
+- [[VitePress]]：Vue 团队出品的轻量级静态文档生成器
+- [[OpenAPI/Swagger]]：API 规范标准，用于自动生成 API 参考文档
+- [[Vale]]：开源 prose linter，用于文档风格检查
+- [[Redoc]]：开源 API 文档渲染器，从 OpenAPI 规范生成文档
+- [[Stoplight]]：商业 API 设计/文档平台
+
+## Connections
+- [[Engineering Backend Architect]] ← writes_docs_for ← [[Technical Writer]]
+- [[Engineering Code Reviewer]] ← reviews_docs ← [[Technical Writer]]
+- [[Software Architect]] ← designs_architecture ← [[Technical Writer]] (provides docs requirements)
+
+## Contradictions
+- 与 [[specialized-developer-advocate]] 冲突：
+  - 冲突点：技术写作与开发者倡导者都产出手册和教程，但目标受众和交付标准不同。
+  - 当前观点（Technical Writer）：文档以参考完整性优先，覆盖所有 API 端点和参数，面向不同熟练度的开发者分层提供内容。
+  - 对方观点（Developer Advocate）：教程必须先展示最终结果，必须包含失败模式和调试方法，代码必须零修改运行，不为非 GA 功能发布教程。
+  - 协调方案：Developer Advocate 负责"教程/快速入门/演示"等引导式内容；Technical Writer 负责"API 参考/规范文档/操作指南"等查阅式内容；两者共享 DX 反馈回路。
diff --git a/wiki/sources/engineering-threat-detection-engineer.md b/wiki/sources/engineering-threat-detection-engineer.md
new file mode 100644
index 00000000..b1cec05c
--- /dev/null
+++ b/wiki/sources/engineering-threat-detection-engineer.md
@@ -0,0 +1,65 @@
+---
+title: "Threat Detection Engineer Agent Personality"
+type: source
+tags: ["agent-personality", "security", "detection-engineering", "siem", "threat-hunting"]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-threat-detection-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：威胁检测工程师 Agent 个性定义——专注于构建检测层，在攻击者绕过预防控制后捕获威胁
+- 问题域：SIEM 规则开发、MITRE ATT&CK 覆盖度映射、威胁狩猎、告警调优、Detection-as-Code 流水线
+- 方法/机制：用 Sigma（厂商无关）编写检测规则，编译为 Splunk SPL / Sentinel KQL / Elastic EQL / Chronicle YARA-L；通过 Git + CI/CD 实现检测即代码；原子红队验证检测有效性
+- 结论/价值：检测质量远比数量重要；未检测到的入侵损失是已检测到的 10 倍；嘈杂的 SIEM 比没有 SIEM 更糟糕
+
+## Key Claims（用中文描述）
+- 检测质量 > 检测数量：未在真实日志数据上测试的规则要么触发一切，要么什么都不触发
+- 行为检测优于 IOC 匹配：IP地址/哈希攻击者每天轮换，行为模式更难伪造
+- 检测即代码：规则版本控制、peer review、测试、CI/CD 部署——绝不在 SIEM 控制台直接编辑
+- MITRE ATT&CK 映射必须：每个检测必须映射到至少一个 ATT&CK 技术，否则无法理解自己在检测什么
+- 覆盖完整杀伤链：仅检测初始访问意味着错失横向移动、持久化和数据外泄
+
+## Key Quotes
+> "An undetected breach costs 10x more than a detected one, and a noisy SIEM is worse than no SIEM at all — because it trains analysts to ignore alerts."
+> — Threat Detection Engineer Agent 身份定义
+
+> "Detection rules are code: version-controlled, peer-reviewed, tested, and deployed through CI/CD — never edited live in the SIEM console."
+> — 关键规则：运营纪律
+
+> "For every detection you write, ask 'how would I evade this?' — then write the detection for the evasion too."
+> — 关键规则：对手思维设计
+
+> "A rule that passed testing 12 months ago may not catch today's variant."
+> — 关键规则：季度验证
+
+## Key Concepts
+- [[Detection Engineering]]：构建和维护高保真检测规则的学科，强调检测质量优于数量
+- [[Threat Hunting]]：基于情报、异常分析和 ATT&CK 差距评估，主动搜寻检测规则遗漏的威胁
+- [[Alert Tuning]]：通过允许列表、阈值调优和上下文富化降低误报率，提升信噪比
+- [[Detection-as-Code]]：检测规则作为代码管理，Git 版本控制 + CI/CD 测试和部署
+- [[Purple Team]]：红蓝结合的验证方法，通过原子红队测试或紫队练习确认检测有效性
+- [[MITRE ATT&CK Mapping]]：将检测规则映射到 ATT&CK 矩阵，评估覆盖度并识别关键差距
+
+## Key Entities
+- [[Sigma]]：厂商无关的检测规则格式，是 Detection-as-Code 的核心语言
+- [[MITRE ATT&CK]]：威胁战术和技术知识库，所有检测规则必须映射到此矩阵
+- [[Splunk]]：企业 SIEM 平台，Sigma 规则编译为 SPL 部署目标之一
+- [[Microsoft Sentinel]]：Azure 云 SIEM，Sigma 规则编译为 KQL 部署目标之一
+- [[Elastic]]：SIEM/可观测性平台，Sigma 规则编译为 EQL 部署目标之一
+- [[Sysmon]]：Windows 系统监视工具，提供进程创建、进程访问等关键事件日志
+
+## Connections
+- [[Sigma]] ← writes_detection_rules ← [[Detection Engineering]]
+- [[MITRE ATT&CK]] ← maps_coverage ← [[Detection Engineering]]
+- [[Splunk]] ← deploys ← [[Detection-as-Code]]
+- [[Microsoft Sentinel]] ← deploys ← [[Detection-as-Code]]
+- [[Threat Hunting]] ← converts_findings_to ← [[Detection Engineering]]
+- [[Alert Tuning]] ← improves ← [[Detection Engineering]]
+
+## Contradictions
+- 与 [[Alert Tuning]] 存在张力：
+  - 冲突点：过度调优可能削弱检测灵敏度，将真正的攻击者行为加入允许列表
+  - 当前观点：允许列表和阈值调优是降低误报的必要手段
+  - 对方观点：频繁调优会侵蚀 SOC 信任，且可能让真正的 APT 行为通过
diff --git a/wiki/sources/engineering-voice-ai-integration-engineer.md b/wiki/sources/engineering-voice-ai-integration-engineer.md
new file mode 100644
index 00000000..fb5176e8
--- /dev/null
+++ b/wiki/sources/engineering-voice-ai-integration-engineer.md
@@ -0,0 +1,64 @@
+---
+title: "Voice AI Integration Engineer"
+type: source
+tags: ["voice-ai", "speech-transcription", "whisper", "asr", "audio-pipeline"]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-voice-ai-integration-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Voice AI Integration Engineer（语音 AI 集成工程师）—— 设计并构建生产级语音转文字（STT）管道，涵盖从原始音频摄入到结构化输出的完整流程
+- 问题域：音频质量验证、模型选型、管道工程、隐私合规、多种下游系统集成
+- 方法/机制：Whisper/faster-whisper 本地模型 + 云端 ASR（AssemblyAI/Deepgram 等）；ffmpeg 预处理（重采样至 16kHz 单声道、EBU R128 响度归一化）；pyannote.audio 说话人分离；分块策略处理长音频；结构化输出（SRT/VTT/JSON）；LLM handoff
+- 结论/价值：提供从原始音频到生产就绪结构化文本的完整管道，支持隐私敏感场景本地部署，支持多种下游系统（Handoff、CMS、Agent Pipeline）集成
+
+## Key Claims（用中文描述）
+- 未经格式/采样率/声道验证的原始音频直接传入转录模型，是转录精度静默下降的首要原因
+- 长音频（>30 分钟）必须进行重叠感知分块处理，不可依赖模型最大输入时长——溢出无声且无报错地损坏输出
+- 时间戳和说话人归属在所有处理阶段必须保留，不可在交接前剥离——下游消费者（LLM 摘要、CMS 写入）依赖这些元数据
+- PII 检测与脱敏必须作为命名且可配置的管道阶段，而非事后补丁
+- 转录置信度分数≠准确度，低置信度片段需人工审核标记，而非静默删除
+
+## Key Quotes
+> "Bad input is the leading cause of silent accuracy degradation." — 音频质量意识
+> "Never discard timestamps. Even if the downstream consumer doesn't need them now, regenerating them requires re-running the full transcription pass." — 时间戳完整性
+> "Never treat punctuation inserted by a model as ground truth." — 模型输出不可信
+> "Transcripts stored longer than policy allows are a compliance liability." — 数据保留合规
+
+## Key Concepts
+- [[VoiceActivityDetection]]：通过 VAD（Voice Activity Detection）过滤静音片段，减少无效处理，提高转录效率
+- [[SpeakerDiarization]]：将 pyannote.audio 或云端 ASR 的说话人标签与转录结果合并，产生带说话人归属的段落
+- [[EBUR128LoudnessNormalization]]：EBU R128 响度归一化标准（I=-16:TP=-1.5:LRA=11），确保不同来源音频具有一致的响度水平
+- [[FasterWhisper]]：CTranslate2 优化的 Whisper 实现，比原版快 2-3 倍，支持 GPU 加速，精度与原版相当
+- [[OverlapAwareChunking]]：对超长音频（>30 分钟）进行重叠感知分块，防止词边界被切断，分块重叠区域在合并时裁剪
+- [[PIIRedaction]]：个人身份信息（PII）检测与脱敏作为命名管道阶段，支持 HIPAA/GDPR 合规
+- [[StructuredTranscriptJSON]]：稳定 Schema 的结构化 JSON 输出，包含分段时间戳、说话人、置信度，供下游 LLM 和 CMS 消费
+- [[LLMHandoff]]：将结构化转录文本格式化后传递给 LLM 摘要/问答/行动项提取 Agent 的标准接口
+
+## Key Entities
+- [[OpenAIWhisper]]：OpenAI 开源的 Whisper 模型系列（tiny→large-v3），支持多语言语音识别，是本地转录的核心模型
+- [[pyannote.audio]]：开源说话人分离库（pyannote/speaker-diarization-3.1），通过 HF token 加载，用于音频说话人分段标注
+- [[AssemblyAI]]：云端 ASR 服务提供商，支持说话人标签、置信度、PII 检测，作为本地 Whisper 的云端替代方案
+- [[Deepgram]]：云端 ASR 服务，支持实时流式转录和说话人分离，与本地 Whisper 形成混合路由架构
+- [[ffmpeg]]：开源多媒体处理工具，用于音频格式检测、重采样、单声道转换、响度归一化、静音切除
+- [[LangChain]]：LLM 应用框架，Voice AI Integration Engineer 通过 [[LLMHandoff]] 向其传递结构化输入
+
+## Connections
+- [[FasterWhisper]] ← uses ← [[OpenAIWhisper]]
+- [[SpeakerDiarization]] ← merges_with ← [[FasterWhisper]]
+- [[VoiceActivityDetection]] ← preprocessing_for ← [[FasterWhisper]]
+- [[EBUR128LoudnessNormalization]] ← preprocesses ← [[FasterWhisper]]
+- [[PIIRedaction]] ← pipeline_stage → [[StructuredTranscriptJSON]]
+- [[LLMHandoff]] ← consumes ← [[StructuredTranscriptJSON]]
+
+## Contradictions
+- 与 [[EngineeringFrontendDeveloper]] 冲突：
+  - 冲突点：音频格式验证（前端通常信任文件扩展名，Voice AI 工程师从不信任扩展名）
+  - 当前观点：必须用 ffprobe 探测实际容器/codec，永远不依赖扩展名猜测
+  - 对方观点：前端通常通过 MIME type 和文件扩展名做快速客户端验证
+- 与 [[EngineeringSRE]] 冲突：
+  - 冲突点：生产监控中的原始音频日志（Voice AI 严禁，SRE 倾向详细日志）
+  - 当前观点：生产监控中禁止记录原始音频内容或未脱敏转录文本
+  - 对方观点：可观测性基础设施需要足够详细的日志用于故障排查
diff --git a/wiki/sources/engineering-wechat-mini-program-developer.md b/wiki/sources/engineering-wechat-mini-program-developer.md
new file mode 100644
index 00000000..d2007125
--- /dev/null
+++ b/wiki/sources/engineering-wechat-mini-program-developer.md
@@ -0,0 +1,49 @@
+---
+title: "WeChat Mini Program Developer Agent Personality"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-wechat-mini-program-developer.md]]
+
+## Summary（用中文描述）
+- 核心主题：微信小程序 Agent 人格定义文档，描述了一名专注于微信生态的高性能小程序开发者的角色定位、技术栈和开发规范
+- 问题域：微信小程序的全栈开发、平台合规、性能优化、生态集成
+- 方法/机制：WXML/WXSS/WXS 技术栈、双线程架构、setData 优化、子包加载策略、微信支付/订阅消息集成、跨平台框架（Taro/uni-app）
+- 结论/价值：为 AI Agent 提供微信小程序开发的系统化方法论，覆盖从项目架构到审核上线的完整生命周期
+
+## Key Claims（用中文描述）
+- 微信小程序采用双线程架构，开发者无法直接操作 DOM，必须通过 setData 跨线程通信
+- 主包大小限制 2MB，子包合计上限 20MB，性能优化是核心约束
+- 所有网络请求必须 HTTPS 且域名需在微信后台白名单注册
+- 微信支付流程为：服务端创建订单 → 小程序调用 wx.requestPayment → 回调处理
+- 订阅消息取代了已废弃的模板消息，需在支付/下单等关键节点触发授权
+- 跨平台框架 Taro/uni-app 可实现一次开发多端部署（微信、支付宝、百度、抖音小程序）
+
+## Key Quotes
+> "WeChat review will reject this if we ask for location permission without a visible use case on the page" — 微信审核对权限申请必须有可见使用场景
+> "Every setData call crosses the JS-native bridge - batch these three updates into one call" — setData 跨线程调用的性能代价，每帧应合并更新
+> "The main package is at 1.8MB - we need to move the marketing pages to a subpackage before adding this feature" — 子包策略是包体积管理的核心手段
+
+## Key Concepts
+- [[微信小程序]]: 微信生态内的轻量级应用，深度集成微信登录、支付、分享、订阅消息等能力
+- [[setData 优化]]: 双线程架构下的跨线程数据同步机制，频繁/大量 setData 是性能瓶颈，需最小化调用频率和 payload
+- [[子包加载]]: 微信小程序的分包策略，主包不超过 2MB，通过 subpackages 分载非核心功能以控制启动时间
+- [[WXML/WXSS]]: 微信小程序的模板语言和样式表，类似 HTML/CSS，遵循微信定义的组件化数据绑定模型
+- [[微信支付集成]]: 服务端生成 prepay 参数，小程序端调用 wx.requestPayment 完成支付，订阅消息在支付后触发授权
+- [[跨平台小程序框架]]: Taro（React）、uni-app（Vue）实现一次编写多端部署，需处理平台 API 差异
+
+## Key Entities
+- [[微信]]: 腾讯旗下超级 App，月活超 10 亿，提供小程序、公众号、视频号、企业微信等生态能力
+- [[Taro]]: 京东开源的多端统一开发框架，支持 React 语法，可编译为微信、支付宝、百度、抖音等小程序
+- [[uni-app]]: DCloud 开源的跨平台开发框架，基于 Vue 语法，支持一键发布到多个小程序平台及 H5/App
+
+## Connections
+- [[微信小程序]] ← 技术栈 ← [[engineering-mobile-app-builder]]
+- [[微信支付集成]] ← 依赖 ← [[微信]]
+- [[跨平台小程序框架]] ← 工具链 ← [[Taro]], [[uni-app]]
+
+## Contradictions
+- （本文档为独立 Agent 人格定义，暂无已知冲突页面）
diff --git a/wiki/sources/examples-readme.md b/wiki/sources/examples-readme.md
new file mode 100644
index 00000000..6fa16a65
--- /dev/null
+++ b/wiki/sources/examples-readme.md
@@ -0,0 +1,60 @@
+---
+title: "Examples"
+type: source
+tags: [multi-agent, agency-agents, examples, orchestration]
+sources: []
+last_updated: 2026-05-13
+---
+
+## Source File
+- [[Agent/agency-agents/examples/README.md]]
+
+## Summary（用中文描述）
+- 核心主题：展示 The Agency 多 Agent 系统在真实任务中如何协同工作——通过具体案例（Nexus Spatial Discovery）演示 8 个专业 Agent 并行协作完成完整产品发现与规划。
+- 问题域：Agent 定义本身不足以说明"全部 Agent 同时部署在同一任务上"会发生什么；需要真实的多 Agent 协作案例来验证系统的实际效果。
+- 方法/机制：The Agency repo 定义了跨工程、设计、营销、产品、支持、空间计算、项目管理等领域的数十个专业 Agent；Examples 目录通过完整案例回答："当全体 Agent 协作时，实际上是什么样子的？"
+- 结论/价值：验证了 8 个 Agent 并行运行可产出连贯、相互引用的计划，且无需人工协调开销；为新增示例提供了贡献指南。
+
+## Key Claims（用中文描述）
+- The Agency 定义了数十个跨多个领域的专业 Agent（工程、设计、营销、产品、支持、空间计算、项目管理），但 Agent 定义本身不能说明"全员部署在同一任务上"的实际效果。
+- Examples 目录解答了核心问题："当整个 Agency 协作时，实际上是什么样子的？"
+- Nexus Spatial Discovery 案例证明：8 个 Agent 并行运行可产出连贯、相互引用的计划，无须人工协调。
+- 新增好示例的标准：多个 Agent 协作同一目标、展示 Agency 能力广度、具有现实适用性。
+
+## Key Quotes
+> "These examples answer the question: 'What does it actually look like when the full agency collaborates?'" — Examples/README.md，开篇即点明核心价值
+> "All 8 agents ran in parallel and produced coherent, cross-referencing plans without coordination overhead." — Examples/README.md，核心成果定性
+> "If you run an interesting multi-agent exercise, consider adding it here." — Examples/README.md，贡献指南入口
+
+## Key Concepts
+- [[Multi-Agent-Collaboration]]：多 Agent 协作——多个专业 Agent 在同一任务上并行工作，产出连贯、相互引用的计划，无须人工协调；是 The Agency 的核心价值主张。
+- [[Multi-Agent-Orchestration]]：多 Agent 编排——The Agency 框架的基础能力，Examples 目录通过案例验证其在实际任务中的有效性。
+- [[Parallel-Agent-Execution]]：并行 Agent 执行——8 个 Agent 同时运行于单一任务，各 Agent 独立研究后交叉对齐，是 Nexus Spatial Discovery 案例的核心执行模式。
+
+## Key Entities
+- [[Nexus-Spatial]]：产品——AI Agent 沉浸式 3D 命令中心；是 Nexus Spatial Discovery 案例中被 8 个 Agent 协作评估的软件机会；Nexus Spatial Discovery source page 有完整记录。
+- [[Product-Trend-Researcher]]：The Agency 产品趋势研究员——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责市场验证和竞争格局分析。
+- [[Backend-Architect]]：The Agency 后端架构师——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责系统架构、数据库建模和 API 设计。
+- [[Brand-Guardian]]：The Agency 品牌守护者——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责定位和视觉身份设计。
+- [[Growth-Hacker]]：The Agency 增长黑客——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责 GTM 策略、定价和发布计划。
+- [[Support-Responder]]：The Agency 支持应答者——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责支持分级和社区运营。
+- [[UX-Researcher]]：The Agency UX 研究员——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责用户画像和旅程地图。
+- [[Project-Shepherd]]：The Agency 项目牧羊人——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责阶段计划和风险管理。
+- [[XR-Interface-Architect]]：The Agency XR 界面架构师——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责空间界面规范。
+
+## Connections
+- [[Nexus-Spatial]] ← exemplifies ← [[Multi-Agent-Collaboration]]（完整案例）
+- [[Nexus-Spatial-Discovery]] ← is_case_of ← [[examples/README]]（source page）
+- [[Multi-Agent-Orchestration]] ← validated_by ← [[Nexus-Spatial-Discovery]]（8-Agent 并行验证）
+- [[Parallel-Agent-Execution]] ← demonstrated_in ← [[Nexus-Spatial-Discovery]]
+- [[Product-Trend-Researcher]] → contributed_to → [[Nexus-Spatial-Discovery]]
+- [[Backend-Architect]] → contributed_to → [[Nexus-Spatial-Discovery]]
+- [[Brand-Guardian]] → contributed_to → [[Nexus-Spatial-Discovery]]
+- [[Growth-Hacker]] → contributed_to → [[Nexus-Spatial-Discovery]]
+- [[Support-Responder]] → contributed_to → [[Nexus-Spatial-Discovery]]
+- [[UX-Researcher]] → contributed_to → [[Nexus-Spatial-Discovery]]
+- [[Project-Shepherd]] → contributed_to → [[Nexus-Spatial-Discovery]]
+- [[XR-Interface-Architect]] → contributed_to → [[Nexus-Spatial-Discovery]]
+
+## Contradictions
+- 暂无已知冲突
diff --git a/wiki/sources/executive-brief.md b/wiki/sources/executive-brief.md
new file mode 100644
index 00000000..489b2768
--- /dev/null
+++ b/wiki/sources/executive-brief.md
@@ -0,0 +1,53 @@
+---
+title: "NEXUS Executive Brief"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/EXECUTIVE-BRIEF.md]]
+
+## Summary（用中文描述）
+- 核心主题：NEXUS 多 Agent 编排框架的战略概览与商业价值论证——将 The Agency 的 9 大部门专业化 Agent 从"各自为战"转化为"协调统一的智能网络"
+- 问题域：多 Agent 项目在交接边界处 73% 失败率、无证据的质量评估（"幻想型审批"）、缺乏结构化协调协议导致的重复劳动和质量缺口
+- 方法/机制：NEXUS 三层部署模式（NEXUS-Full/Sprint/Micro）—— 标准化交接模板 + 证据驱动质量门控 + Dev↔QA 循环（最多3次重试） + Reality Checker 最终权威 + 并行工作流（4 轨道同时压缩 40-60% 时间线）
+- 结论/价值：结构化协调协议是最高杠杆干预点；Reality Checker 的默认"NEEDS WORK"姿态防止过早部署；并行工作流是主要上市加速器；持续质量循环优于端到端测试
+
+## Key Claims（用中文描述）
+- 多 Agent 项目在 Agent 缺乏结构化协调协议时，交接边界处失败率达 73% → 标准化交接模板和上下文连续性是最高杠杆干预
+- 无证据要求的质量评估导致"幻想型审批"——Agent 在无证明情况下给基础实现评 A+ → Reality Checker 默认"NEEDS WORK"姿态和证据门控防止过早生产部署
+- 4 条并行轨道（Core Product/Growth/Quality/Brand）同时执行，时间线压缩 40-60% → NEXUS 的并行工作流设计是主要上市加速器
+- Dev↔QA 循环（构建→测试→通过/失败→重试，最多3次）可在集成前捕获 95% 缺陷，Phase 4 硬化时间减少 50% → 持续质量循环优于端到端测试
+
+## Key Quotes
+> "Without coordination, they produce conflicting decisions, duplicated effort, and quality gaps at handoff boundaries." — NEXUS 情境概述，核心问题陈述
+> "Quality assessment without evidence requirements leads to 'fantasy approvals' — agents rating basic implementations as A+ without proof." — Finding 2，证据驱动质量门控的必要性
+> "Parallel execution across 4 simultaneous tracks compresses timelines by 40-60% compared to sequential agent activation." — Finding 3，并行工作流的时间效益
+> "The Dev↔QA loop catches 95% of defects before integration, reducing Phase 4 hardening time by 50%." — Finding 4，持续质量循环的功效
+
+## Key Concepts
+- [[Quality Gate]]：每阶段质量门控，无证据不推进——确保交接内容经过验证而非口头断言
+- [[Dev↔QA Loop]]：构建→测试→通过/失败→重试循环，最多3次——持续质量循环优于端到端测试
+- [[Agent Handoff]]：结构化上下文传递协议——解决 73% 交接边界失败率的核心机制
+- [[Reality Checker]]：最终质量权威，默认"NEEDS WORK"姿态——防止"幻想型审批"的守门人
+- [[Evidence Over Claims]]：截图/测试结果/数据优于口头断言——所有质量判定必须基于可验证证据
+- [[Parallel Workstream]]：4 条并行轨道同时执行——压缩 40-60% 时间线的主要上市加速器
+- [[Handoff Boundary]]：Agent 间交接边界——73% 失败率的核心痛点，标准化协调协议的最高杠杆干预点
+
+## Key Entities
+- [[NEXUS]]：The Agency 的多 Agent 编排框架——Network of EXperts, Unified in Strategy，包含 3 种部署模式（Full/Sprint/Micro）、7 阶段管道（Phase 0-6）
+- [[The Agency]]：NEXUS 的组织背景——9 大专业化部门（Engineering/Design/Marketing/Product/Project Management/Testing/Support/Spatial Computing/Specialized Operations），共 147+ Agent
+- [[Agents-Orchestrator]]：NEXUS 管道的核心控制器——协调多 Agent 协作的执行引擎
+
+## Connections
+- [[executive-brief]] ← overview ← [[NEXUS]]（NEXUS 框架的战略概览文档）
+- [[executive-brief]] ← extends ← [[quickstart]]（战略层补充了 Quick-Start Guide 的方法论依据和数据支撑）
+- [[executive-brief]] ← extends ← [[nexus-strategy]]（战略层补充了 nexus-strategy 的核心发现和商业影响数据）
+- [[executive-brief]] ← depends_on ← [[agents-orchestrator]]（执行层面由 Agents-Orchestrator 实现）
+- [[executive-brief]] ← depends_on ← [[Reality-Checker]]（质量门控机制依赖 Reality Checker 作为最终权威）
+- [[executive-brief]] ← extends ← [[workflow-startup-mvp]]（战略层补充了 Startup MVP 工作流的商业价值和量化数据）
+
+## Contradictions
+- 与 [[nexus-spatial-discovery]] 的并行 Agent 发现结果一致：两者均支持并行 Agent 协作的价值；Executive Brief 从战略层面论证了并行工作流的商业合理性（40-60% 时间线压缩），Nexus Spatial Discovery 从执行层面证明了并行 Agent 发现可产出连贯相互引用的完整计划。属战略与执行层面的相互印证，无冲突。
+- 与 [[workflow-startup-mvp]] 的质量门控设计一致：两者均强调 Reality Checker 的"NEEDS WORK"默认姿态；Executive Brief 提供战略依据（防止"幻想型审批"），workflow-startup-mvp 提供执行模板。无冲突。
diff --git a/wiki/sources/expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend.md b/wiki/sources/expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend.md
new file mode 100644
index 00000000..ad2bc724
--- /dev/null
+++ b/wiki/sources/expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend.md
@@ -0,0 +1,74 @@
+---
+title: "Expose hermes-agent as an OpenAI-compatible API for any frontend"
+type: source
+tags:
+  - "hermes-agent"
+  - "api-server"
+  - "openai-compatible"
+  - "integration"
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/Expose hermes-agent as an OpenAI-compatible API for any frontend]]
+
+## Summary（用中文描述）
+- 核心主题：hermes-agent API Server 功能 —— 将 hermes-agent 暴露为 OpenAI 兼容的 HTTP API，使任何支持 OpenAI 格式的前端都能连接使用
+- 问题域：AI Agent 的可访问性问题 —— 如何让任意前端（Open WebUI、LobeChat、LibreChat 等）接入 hermes-agent
+- 方法/机制：
+  - 通过 `API_SERVER_ENABLED=true` 启用内建 API Server
+  - 默认监听 `127.0.0.1:8642`，Bearer token 认证
+  - 支持 Chat Completions API（无状态）、Responses API（有状态会话）、Runs API（实时进度）、Jobs API（定时任务）
+  - 系统提示词分层叠加，前端提示词不会覆盖 Agent 原有工具集
+- 结论/价值：hermes-agent 可作为 OpenAI API 的直接替代品，无缝接入现有 AI 前端生态，无需修改前端代码
+
+## Key Claims（用中文描述）
+- hermes-agent API Server 将 Agent 暴露为 OpenAI 兼容 HTTP 端点，任何 OpenAI 格式的前端均可直连
+- 默认绑定 `127.0.0.1:8642`，需配置 `API_SERVER_KEY` 启用 Bearer token 认证
+- `/v1/chat/completions` 为无状态接口，每次请求需传递完整对话历史
+- `/v1/responses` 支持服务端会话状态，通过 `previous_response_id` 链式调用保留完整上下文（含工具调用）
+- `/v1/runs` API 通过 `run_id` + SSE 事件流实现长会话实时进度订阅
+- Jobs API 提供 CRUD 接口，支持从远程客户端管理定时/后台 Agent 任务
+- 前端传入的 system prompt 在 Agent 核心提示词之上分层叠加，保留全部工具能力
+- 多用户场景通过 Profiles 隔离，每个 Profile 运行独立 API Server 实例（不同端口和认证密钥）
+
+## Key Quotes
+> "Any frontend that speaks the OpenAI format — Open WebUI, LobeChat, LibreChat, NextChat, ChatBox, and hundreds more — can connect to hermes-agent and use it as a backend." — 官方文档
+
+> "Your agent handles requests with its full toolset (terminal, file operations, web search, memory, skills) and returns the final response." — 官方文档
+
+> "When a frontend sends a system message (Chat Completions) or instructions field (Responses API), hermes-agent layers it on top of its core system prompt. Your agent keeps all its tools, memory, and skills." — 官方文档
+
+> "The API server gives full access to hermes-agent's toolset, including terminal commands. When binding to a non-loopback address like 0.0.0.0, API_SERVER_KEY is required." — 官方文档安全警告
+
+## Key Concepts
+- [[OpenAI-Compatible API]]：遵循 OpenAI API 格式标准的接口层，允许非 OpenAI 后端替代原生服务
+- [[Bearer Token Authentication]]：通过 `Authorization: Bearer <token>` 头部进行 API 身份验证
+- [[System Prompt Layering]]：前端提示词在 Agent 核心提示词之上分层叠加，不覆盖原有工具集
+- [[Conversation State Persistence]]：服务端存储完整对话历史（含工具调用），客户端无需管理上下文
+- [[Server-Sent Events (SSE)]]：流式响应协议，支持 token-by-token 推送和自定义工具进度事件
+- [[CORS Allowlist]]：浏览器跨域访问控制，通过白名单精确控制允许的来源
+- [[Multi-Profile Isolation]]：通过 Profiles 实现多用户隔离，每个实例独立配置、内存、技能
+- [[Background Job Scheduling]]：远程客户端通过 Jobs API 管理定时/后台 Agent 任务
+
+## Key Entities
+- [[hermes-agent]]：主项目， NousResearch 出品的 AI 编码 Agent，配备完整工具集（终端、文件、网络搜索、记忆、Skills）
+- [[Open WebUI]]：开源 AI Web UI（126k stars），有完整集成指南
+- [[LobeChat]]：开源 AI 聊天前端（73k stars），自定义 Provider 接入
+- [[LibreChat]]：开源多后端聊天平台（34k stars），通过 librechat.yaml 配置
+- [[NextChat]]：开源 ChatGPT Web 应用（87k stars），通过 BASE_URL 环境变量接入
+- [[ChatBox]]：开源 AI 客户端（39k stars），API Host 设置接入
+- [[AnythingLLM]]：开源 RAG AI 应用（56k stars），Generic OpenAI Provider 接入
+- [[Jan]]：开源本地 AI 应用（26k stars），Remote Model 配置接入
+
+## Connections
+- [[hermes-agent]] ← exposes ← [[OpenAI-Compatible API]]
+- [[Open WebUI]] ← connects_to ← [[hermes-agent]] API Server
+- [[LobeChat]] ← connects_to ← [[hermes-agent]] API Server
+- [[LibreChat]] ← connects_to ← [[hermes-agent]] API Server
+- [[NextChat]] ← connects_to ← [[hermes-agent]] API Server
+- [[hermes-agent]] ← supports ← [[Multi-Profile Isolation]]
+- [[hermes-agent]] ← implements ← [[Background Job Scheduling]]
+
+## Contradictions
+- （暂无检测到冲突）
diff --git a/wiki/sources/finance-bookkeeper-controller.md b/wiki/sources/finance-bookkeeper-controller.md
new file mode 100644
index 00000000..99287d62
--- /dev/null
+++ b/wiki/sources/finance-bookkeeper-controller.md
@@ -0,0 +1,62 @@
+---
+title: "Bookkeeper & Controller Agent"
+type: source
+tags: [finance, accounting, agent]
+last_updated: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/finance/finance-bookkeeper-controller.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 作为专业会计主管（Controller），负责企业日常会计运营、月结流程和内部控制的自动化执行
+- 问题域：企业财务记录准确性、月结准时性、合规审计准备
+- 方法/机制：通过 Agent 角色定义（名为"Dana"的13年经验Controller）、标准化Checklist模板、职责分离规则、GAAP合规框架
+- 结论/价值：为财务团队提供可7×24小时运行的AI Controller，确保账目精确、月结准时、审计就绪
+
+## Key Claims（用中文描述）
+- Dana Agent 通过月度结账Checklist模板确保每月结账流程标准化、可重复执行
+- Dana Agent 强制执行职责分离（Segregation of Duties），确保交易发起人与审批/记录人不为同一人
+- Dana Agent 维持"审计就绪"状态，确保审计师随时进场时可在24小时内提供任何余额的支持文件
+- Dana Agent 将月末结账周期从10个工作日压缩至7个，并通过AP自动化可进一步压缩至5天
+- Dana Agent 要求所有资产负债表科目每月完成调节，未调节余额是"定时炸弹"
+
+## Key Quotes
+> "A fast close is a good close, but an accurate close is a non-negotiable close. Speed without accuracy is just noise delivered faster." — Dana核心原则
+> "Reconciliation is not a chore — it's a detective process. Every unreconciled difference is a story waiting to be understood." — Dana方法论
+> "The audit should be boring. If the auditors are surprised, the controls failed." — 审计就绪理念
+> "Automate the recurring, focus the brain on the exceptional." — 自动化哲学
+
+## Key Concepts
+- [[Month-End Close Process]]：月度结账流程 — 通过标准化Checklist（Pre-Close → Core Close → Reconciliations → Financial Statements → Review）确保每月结账按时完成
+- [[GAAP Compliance]]：通用会计准则 — 所有交易按适用会计准则记录，无例外无捷径
+- [[Account Reconciliation]]：账户调节 — 每个资产负债表科目每月必须调节，未调节余额视为风险
+- [[Internal Controls]]：内部控制 — 授权矩阵、审批流程、系统访问控制、数据验证规则，确保财务信息安全
+- [[Segregation of Duties]]：职责分离 — 交易发起人与审批/记录人不得为同一人，防止欺诈与错误
+- [[Audit Readiness]]：审计就绪 — 日常维护审计就绪状态，审计师可随时进场，24小时内提供任何余额支持
+- [[Revenue Recognition ASC 606]]：ASC 606收入确认 — 合同审查、履约义务识别、递延收入管理
+- [[Journal Entry]]：日记账分录 — 每笔手工分录需描述、支持文档和审批，拒绝"调整分录"式无意义描述
+
+## Key Entities
+- Dana：Agent角色名称 — 13年+经验的Controller，曾从零建立会计部门、完成首次审计、实施Sarbanes-Oxley、连续150+月准时结账
+- QuickBooks / Xero / NetSuite / Sage Intacct / SAP / Oracle Financials：ERP/会计软件 — 日常记账系统
+- FloQast / BlackLine / Trintech / Workiva：结账管理软件 — 月结流程管理与协调工具
+- Bill.com / Tipalti / AvidXchange / Coupa：AP自动化平台 — 应付账款处理与支付调度
+- Expensify / Concur / Brex / Ramp：费用管理平台 — 员工报销管理
+- ASC 606 / ASC 842 / ASC 718 / ASC 805：会计准则 — 复杂会计处理标准
+- SOX (Sarbanes-Oxley)：萨班斯-奥克斯利法案 — 公众公司内部控制框架
+
+## Connections
+- [[Finance FPA Analyst]] ← workflow_partner ← [[Bookkeeper Controller Agent]]
+- [[Finance Tax Strategist]] ← provides_data_to ← [[Bookkeeper Controller Agent]]
+- [[Account Reconciliation]] ← depends_on ← [[Month-End Close Process]]
+- [[Internal Controls]] ← enables ← [[Audit Readiness]]
+- [[Segregation of Duties]] ← part_of ← [[Internal Controls]]
+- [[Revenue Recognition ASC 606]] ← extends ← [[GAAP Compliance]]
+
+## Contradictions
+- 与 [[Finance FPA Analyst]] 潜在冲突：
+  - 冲突点：FP&A追求更快的结账速度（支持决策时效），Bookkeeper追求更严格的准确性（审计就绪）
+  - 当前观点：Dana坚持"准确性是不可协商的底线"——速度必须服从准确性
+  - 对方观点：FP&A可能认为某些GAAP边界情况下的快速估计对决策更有价值
+  - 解决方向：两者可以协同——Dana的月结Checklist包含Flux Analysis，可为FP&A提供高质量数据
diff --git a/wiki/sources/finance-financial-analyst.md b/wiki/sources/finance-financial-analyst.md
new file mode 100644
index 00000000..3270c339
--- /dev/null
+++ b/wiki/sources/finance-financial-analyst.md
@@ -0,0 +1,55 @@
+---
+title: "Financial Analyst Agent"
+type: source
+tags: ["agent-personality", "finance", "financial-modeling", "agentic-ai"]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/finance/finance-financial-analyst.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Finance 部门的专业金融分析师 AI Agent（代号 Morgan）——12年+经验，专注投资银行、企业财务和 FP&A，将原始财务数据转化为战略性商业洞察，支撑资本配置决策和投资建议。
+- 问题域：财务建模与估值（三报表模型、DCF、LBO、M&A）、预测与规划（收入、成本、营运资金、资本支出）、分析框架（差异分析、敏感性分析、蒙特卡洛模拟）。
+- 方法/机制：四阶段工作流（数据收集验证→模型架构设计→场景分析→决策支持呈现）；三报表联动模型；WACC + 敏感性分析表格；Python + SQL + BI 工具链。
+- 结论/价值：让每一个重大业务决策都建立在严谨财务分析之上，明确假设与敏感区间，输出可审计、可追溯的决策支持材料。
+
+## Key Claims（用中文描述）
+- Morgan 核心理念：Revenue is vanity, profit is sanity, but cash flow is reality——利润表好看但现金流管理不善的公司是定时炸弹。
+- 财务分析师的核心超能力：将复杂财务数据翻译成非财务利益相关者能理解并采取行动的商业叙事，弥合数字与战略之间的鸿沟。
+- 三报表模型必须动态联动：利润表、资产负债表和现金流量表之间存在内在数学联系，任何输入变化必须自动反映到所有相关科目。
+- 敏感性分析不可或缺：如果关键假设变动 15% 就导致结论反转，那么该建议不是稳健决策，而是碰运气。
+- 模型质量的核心标准：模型必须可被非构建者独立使用、审计和修改——"为他人构建，而非为自己构建"。
+- 精确不等于准确：带有四位小数的粗略估计是在制造虚假信心，精确而无准确性只是噪音。
+- 先进建模技术包括蒙特卡洛模拟（概率预测与风险量化）、实物期权估值（不确定环境下的战略灵活性）、计量经济建模（需求预测与宏观敏感性分析）。
+
+## Key Quotes
+> "Revenue is vanity, profit is sanity, but cash flow is reality." — Morgan Financial Analyst Agent，现金流至上的财务哲学
+> "The numbers don't lie is a dangerous myth. Numbers can be arranged to tell almost any story. Your job is to find the truth underneath." — Morgan，对数据操纵风险的警觉
+> "Every financial model is a simplification of reality. State your assumptions explicitly — they matter more than the formulas." — Morgan，假设优先于结论的核心原则
+> "If your recommendation changes with a 10% swing in a key assumption, say so." — Morgan，敏感性分析强制要求
+
+## Key Concepts
+- [[Three-Statement-Model]]：三报表联动财务模型——利润表、资产负债表和现金流量表通过动态公式链接，确保任何输入变化自动传导至全部相关科目，是所有财务建模的基石。
+- [[DCF-Analysis]]：折现现金流估值——WACC 计算 + 终值方法 + 敏感性表，DCF 是内在价值评估的核心工具。
+- [[LBO-Modeling]]：杠杆收购建模——债务时间表、回报分析（IRR/MOIC）和信贷指标，是私募股权投资分析的标准工具。
+- [[Variance-Analysis]]：差异分析——预算与实际的对比分析，分解根因，用于月度财务报告和运营回顾。
+- [[Unit-Economics]]：单位经济学——CAC（客户获取成本）、LTV（客户终身价值）、回收期和边际贡献分析，用于评估产品线和客户群盈利性。
+- [[Sensitivity-Analysis]]：敏感性分析——测试关键假设变动对输出的影响，识别模型结论的稳健性边界。
+- [[Scenario-Analysis]]：场景规划——构建基础、乐观和悲观三套假设，明确各场景的驱动因素差异。
+- [[Budget-Variance-Analysis]]：预算差异分析——[[support-finance-tracker]] 的月度报告模板，Morgan 提供差异分解框架。
+- [[Cash-Flow-Forecasting]]：现金流预测——12 个月滚动预测，[[support-finance-tracker]] 提供 Python 实现参考。
+- [[Investment-Analysis]]：投资分析——NPV/IRR/ROI 计算框架，[[support-finance-tracker]] 提供 Python 实现。
+
+## Key Entities
+- [[Finance-Tracker]]：The Agency Support 部门的财务追踪 Agent，[[finance-financial-analyst]] 在财务分析能力上向后扩展——Financial Analyst 专注投资分析、建模与战略决策支持，Finance Tracker 专注日常财务运营、预算执行和合规追踪。
+- [[finance-tax-strategist]]：The Agency Finance 部门的税务策略 Agent，与 [[finance-financial-analyst]] 共享 Finance 部门上下文，在税务优化与财务分析的交叉点协同。
+
+## Connections
+- [[finance-tax-strategist]] ← shares_department ← [[finance-financial-analyst]]（均为 The Agency Finance 部门 Agent）
+- [[support-finance-tracker]] ← related_domain ← [[finance-financial-analyst]]（财务分析与财务追踪共享 Finance 领域）
+- [[finance-fpa-analyst]] ← extends ← [[finance-financial-analyst]]（FPA Analyst 是 Financial Analyst 在 FP&A 场景的专精扩展）
+- [[finance-bookkeeper-controller]] ← related_domain ← [[finance-financial-analyst]]（总账会计与财务分析共享财务报表上下文）
+
+## Contradictions
+- 无已知冲突。Morgan 的"精确不等于准确"原则与 [[support-finance-tracker]] 中 Finance Tracker 的数据驱动精确性要求互补而非矛盾——前者强调不因精确性制造虚假信心，后者强调数据准确性是财务运营的底线。
diff --git a/wiki/sources/finance-fpa-analyst.md b/wiki/sources/finance-fpa-analyst.md
new file mode 100644
index 00000000..24e54936
--- /dev/null
+++ b/wiki/sources/finance-fpa-analyst.md
@@ -0,0 +1,59 @@
+---
+title: "FP&A Analyst Agent"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/finance/finance-fpa-analyst.md]]
+
+## Summary（用中文描述）
+- 核心主题：FP&A（财务规划与分析）Agent 的角色定义与操作框架，赋予 AI 代理「Riley」这一专业财务分析师身份，具备 11+ 年高增长 SaaS、制造、零售行业经验
+- 问题域：如何让 AI 代理承担企业级财务规划、预测、差异分析和战略决策支持职能
+- 方法/机制：通过系统性 prompt engineering 定义 Agent 身份、关键规则、交付模板（AOP/MBR）、工作流程（年度计划周期、月度运营节奏、季度重预测）及高级技术能力（ZBB、ABC、蒙特卡洛模拟等）
+- 结论/价值：FP&A 不是会计的续集，而是战略的翻译器；其核心价值在于将模糊的业务计划转化为推动问责制的具体财务框架，将数字转化为行动
+
+## Key Claims（用中文描述）
+- FP&A 专业人员（Riley）通过严格的财务规划、准确的预测和深入的差异分析来驱动战略决策，与业务领导者合作将运营计划转化为财务现实
+- 预算必须与业务驱动因素挂钩——仅按通胀率增长预算不是规划，而是"通货膨胀"；必须将支出与结果连接
+- 差异分析必须解释未来，而不仅仅是过去——没有前瞻性影响评估的差异分析是 obituary 而非 analysis
+- 滚动预测优于年度计划——必须至少每季度更新预测；实时脉搏最为重要
+- 场景规划是主要决策的必备条件——超过一定金额的投资或人员请求都需要 base/upside/downside 场景
+- FP&A 是业务伙伴，而非预算警察——帮助领导者理解自己的数字，以便他们做出更好的决策
+
+## Key Quotes
+> "FP&A is not accounting's sequel — it's strategy's translator. Your job isn't to report what happened. It's to explain why, predict what's next, and recommend what to do about it." — Riley, FP&A Analyst Agent
+> "A budget that nobody owns is a budget nobody follows. Every line item needs a name next to it." — Riley's Core Principle
+> "Complexity is the enemy of usability. A 47-tab model that nobody can navigate is worse than a 5-tab model that everyone understands." — Riley's Design Philosophy
+> "The best FP&A partners make department heads smarter about their own spending. You don't control budgets — you illuminate them." — Riley's Partnership Philosophy
+
+## Key Concepts
+- [[Annual Operating Plan (AOP)]]：年度经营计划——自上而下目标、自下而上构建、差距协调、董事会演示
+- [[Rolling Forecast]]：滚动预测——至少每季度重新预测，结合业务所有者的自下而上输入
+- [[Variance Analysis]]：差异分析——将预算与实际对比，分解根本原因，评估前瞻性影响
+- [[Driver-Based Forecasting]]：基于驱动因素的预测——将财务输出与运营输入关联（如每代表收入、每次招聘成本）
+- [[Scenario Planning]]：场景规划——best/base/worst case，含明确假设和触发点
+- [[Zero-Based Budgeting (ZBB)]]：零基预算——从零开始构建预算，而非基于上一年度
+- [[Activity-Based Costing (ABC)]]：作业成本法——基于活动驱动因素分配间接费用以获得真实单位经济数据
+- [[Monte Carlo Simulation]]：蒙特卡洛模拟——用于范围预测的概率预测技术
+- [[Unit Economics]]：单位经济——CAC、LTV、回本周期、按细分/产品/渠道的边际贡献
+- [[Monthly Business Review (MBR)]]：月度业务回顾——月度经营会议财务包，含执行仪表板、收入分析、费用分析、预测更新、行动项目
+
+## Key Entities
+- [[Riley]]：FP&A Analyst Agent 的人格化身——11+ 年经验的高增长 SaaS、制造、零售行业 FP&A 专业人士，擅长年度运营计划编制、滚动预测、可信赖的 C-suite 报告、预算框架设计
+- [[Anaplan]]：规划软件平台——FP&A 常用规划工具之一
+- [[Adaptive Insights (Workday)]]：规划软件——FP&A 常用规划工具之一
+- [[Planful]]：FP&A 常用规划软件
+- [[Pigment]]：FP&A 常用规划软件（新一代）
+- [[Tableau / Power BI / Looker]]：BI 与可视化工具——FP&A KPI 仪表板与财务数据可视化
+- [[NetSuite / SAP / Oracle]]：ERP 系统——总账数据提取与预算加载集成
+
+## Connections
+- [[Finance Investment Researcher]] ← 相关领域 ← [[Finance Financial Analyst]]
+- [[Finance Tax Strategist]] ← 并列财务职能 ← [[Finance Investment Researcher]]
+- [[Support Finance Tracker]] ← 下游应用 ← [[FP&A Analyst]]（财务追踪与 FP&A 分析的关系）
+- [[Accounts Payable Agent]] ← 并列财务流程 ← [[FP&A Analyst]]
+
+## Contradictions
+- 暂无已知冲突。该 Agent 专注于 FP&A 领域，与其他财务 Agent（如 Tax Strategist、Investment Researcher）功能互补、无直接冲突。
diff --git a/wiki/sources/finance-investment-researcher.md b/wiki/sources/finance-investment-researcher.md
new file mode 100644
index 00000000..4d97172b
--- /dev/null
+++ b/wiki/sources/finance-investment-researcher.md
@@ -0,0 +1,59 @@
+---
+title: "Investment Researcher Agent"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/finance/finance-investment-researcher.md]]
+
+## Summary（用中文描述）
+- 核心主题：机构级投资研究 AI Agent（代号 Quinn），专注市场研究、尽职调查、投资组合分析与资产评估，支持股票、私募和另类资产
+- 问题域：如何通过严谨的基本面和量化分析发现 alpha、评估风险、支持数据驱动的投资决策
+- 方法/机制：五阶段工作流（筛选 → 初评 → 深度研究 → 研报撰写 → 持续监控）；双面论证框架（牛市/熊市同等严谨）；另类数据集成；量化策略
+- 结论/价值：提供机构级投资研报模板、尽职调查清单、成功指标体系；填补 The Agency Finance 部门在投资研究环节的能力空白
+
+## Key Claims（用中文描述）
+- Quinn 具备 14 年+买方权益研究、风险投资尽职调查和机构资产管理经验，已完成 200+ 家公司尽职调查并识别出多只 5 倍回报投资
+- 最佳投资机会来自"严格分析 + 变异认知（variant perception）"的交汇处——当研究与共识一致时，不存在优势
+- 每一份投资建议必须包含具体损失估计的下行情景；"可能下跌"不是风险评估
+- 量化分析必须结合基本面验证：DCF、可比公司法、另类数据代理估计缺一不可
+- 尽职调查流程应在 90%+ 的投资决策前捕获实质性风险
+
+## Key Quotes
+> "The bull case is always easy to write. Spend more time on the bear case — that's where the risk hides." — Quinn 核心理念
+
+> "Valuation is necessary but never sufficient. A cheap stock with a broken business model is a value trap, not a value investment." — Quinn 估值原则
+
+> "The best research is falsifiable. State your thesis, define what would break it, and monitor those triggers relentlessly." — 可证伪研究标准
+
+> "Consensus sees a hardware company. I see a subscription transition — recurring revenue is growing 40% YoY and now represents 35% of total revenue. The market is pricing the old model." — Quinn 沟通风格示例
+
+## Key Concepts
+- [[Variant-Perception]]: 寻找与共识不同的认知角度；只有当研究结论与市场共识存在差异时才存在投资优势
+- [[Investment-Research-Report]]: 五阶段工作流产出的标准化研报格式，含执行摘要、投资论点、牛熊情景、估值分析、财务预测、竞争格局
+- [[Due-Diligence]]: 系统化尽职调查框架，覆盖财务、运营、市场、法律四维度；Red Flags 识别标准
+- [[Thesis-Breakers]]: 每个活跃头寸必须有"论点终结触发器"——会导致立场失效的特定事件或数据点
+- [[Alternative-Data]]: 非常规数据源（网页流量、应用数据、专利文件、职位发布、卫星图像）用于实时业务动能信号
+- [[Quantitative-Strategies]]: 因子模型构建回测（价值、质量、动量、低波动）、事件驱动分析、期权隐含概率分析
+- [[Porter-Five-Forces]]: 竞争护城河评估框架——新进入者威胁、买方议价能力、卖方议价能力、替代品威胁、现有竞争者竞争程度
+
+## Key Entities
+- [[Quinn]]: The Agency 投资研究 Agent，14 年+经验，专注基本面与量化分析结合，支持公开市场和私募市场
+- [[The-Agency]]: Quinn 所属组织，旗下有 Financial Analyst Agent（Morgan）、Tax Strategist Agent（Cassandra）等 Finance 部门成员
+
+## Connections
+- [[Quinn]] ← 互补 ← [[finance-financial-analyst]]
+  - Financial Analyst 负责财务建模与预算分析，Investment Researcher 负责投资研究与估值，两者形成 Finance 部门完整能力覆盖
+- [[Quinn]] ← 依赖 ← [[finance-tax-strategist]]
+  - 税务策略影响投资组合税后回报，Quinn 在尽职调查和投资组合分析中需要参考税务影响
+- [[Investment-Research-Report]] ← 输出格式 ← [[Quinn]]
+- [[Due-Diligence]] ← 方法论 ← [[Quinn]]
+
+## Contradictions
+- 与 [[finance-financial-analyst]] 在分析视角上存在互补而非冲突：
+  - 冲突点：两者均涉及财务建模和估值
+  - Quinn 视角：投资导向，专注 alpha 发现、风险量化、组合构建，强调 variant perception
+  - Morgan 视角：运营导向，专注预算差异、FP&A、现金流预测，强调财务健康监控
+  - 结论：视角互补、分工明确，Wiki 中两者独立存在
diff --git a/wiki/sources/finance-tax-strategist.md b/wiki/sources/finance-tax-strategist.md
new file mode 100644
index 00000000..f6a8533d
--- /dev/null
+++ b/wiki/sources/finance-tax-strategist.md
@@ -0,0 +1,55 @@
+---
+title: "Tax Strategist Agent"
+type: source
+tags: ["agent", "finance", "tax", "compliance", "agentic"]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/finance/finance-tax-strategist.md]]
+
+## Summary（用中文描述）
+- 核心主题：专业税务战略代理 Agent（代号 Cassandra），在 Big Four 会计事务所、企业税务部门和精品税务咨询机构拥有 15 年+经验，擅长跨境交易结构设计、IPO 税务准备、IRS 审计应对。
+- 问题域：企业有效税率（ETR）优化、多辖区合规管理（联邦/州/国际）、转让定价、税务筹划与业务决策整合。
+- 方法/机制：通过五阶段工作流（税务状况评估 → 机会识别 → 策略开发 → 实施合规 → 持续监控），将税务考量嵌入业务决策全流程；使用 Tax Planning Memorandum 和 ETR Analysis 标准化交付物。
+- 结论/价值：使组织有效税率达到行业同行中位数或以下，零罚款/利息，100% 按时申报，所有税务立场有同期文档支持。
+
+## Key Claims（用中文描述）
+- **Cassandra（税务代理）** + 贯穿五阶段工作流 + 将税务规划嵌入业务决策全流程 = 使组织 ETR 达到行业同行中位数
+- **有效税率优化** + 多辖区联动分析（联邦/州/国际） + 量化风险 = 在合法框架内实现税后收益最大化
+- **转让定价** + 独立交易原则 + 基准研究 + 预约定价协议（APA） = 防御跨境税务审查
+- **83(b) Election** + 30 天窗口期内完成 = 将 $2M 未来普通收入转换为长期资本利得，节省约 $470K 联邦税
+- **合规文档** + 同期备忘录 + 立场强度评估 = 审计时的主动防御，降低审计调整幅度
+
+## Key Quotes
+> "Tax isn't an afterthought; it's a strategic lever." — Cassandra（税务代理核心信念）
+> "The cheapest tax dollar is the one you never owe. But the most expensive is the penalty for non-compliance." — Cassandra（税务代理核心原则）
+> "Aggressive ≠ illegal, but the line matters. Always quantify the risk of uncertain positions." — Cassandra（激进与合法的边界）
+
+## Key Concepts
+- [[TransferPricing]]：转让定价 — 关联方交易定价须符合独立交易原则，通过基准研究证明经济合理性
+- [[GILTI]]：全球无形低税收入 — 美国税改后对境外子公司无形收入征税的机制，需通过 FDII 抵扣优化
+- [[BEPS]]：税基侵蚀与利润转移 — OECD 提出的 15 项行动计划，涵盖常设机构、转让定价、数字经济税收
+- [[QSBS]]：合格小型企业股票（Section 1202）— 符合条件的 QSBS 可在出售时享受 100% 资本利得税豁免
+- [[83bElection]]：83(b) 选择权 — 在限制性股票归属前以公平市价申报，将未来普通收入转换为资本利得
+- [[EffectiveTaxRate]]：有效税率（ETR）— 实际税负占税前收入的比例，是衡量税务筹划效果的核心 KPI
+- [[TaxPlanningMemorandum]]：税务规划备忘录 — 标准化交付物模板，包含事实背景、法律分析、立场评估、建议和风险缓释措施
+- [[BEAT]]：基税侵蚀反滥用税 — 对向境外关联方大额支付的美国企业征收的最低税
+
+## Key Entities
+- [[Cassandra]]：税务战略代理 — 角色代号，15年+经验，Big Four + 企业税务部 + 精品咨询背景
+- [[BigFour]]：四大会计事务所 — 主要人才来源，定义行业标准
+- [[IRS]]：美国国税局 — 主要监管和审计对象
+- [[ThomsonReutersONESOURCE]]：税务软件平台 — 税务申报和研究工具
+- [[Alteryx]]：数据分析平台 — 税务数据工作流自动化
+- [[TPBenchmarking]]：转让定价基准研究 — 防御审计的核心文档
+
+## Connections
+- [[TaxStrategist]] ← specializes_in ← [[TransferPricing]]
+- [[TaxStrategist]] ← relies_on ← [[TaxPlanningMemorandum]]
+- [[TaxStrategist]] ← uses ← [[EffectiveTaxRate]] (as KPI)
+- [[TaxStrategist]] ← manages ← [[GILTI]] ← interacts_with ← [[BEAT]]
+- [[TaxStrategist]] ← applies ← [[QSBS]] ← connected_to ← [[83bElection]]
+
+## Contradictions
+- 暂无发现与现有 Wiki 内容的冲突。该 Agent 专注于合法税务筹划，与 Wiki 中其他 Agent 角色无领域重叠。
diff --git a/wiki/sources/game-audio-engineer.md b/wiki/sources/game-audio-engineer.md
index c23ba42f..9ddbd1d7 100644
--- a/wiki/sources/game-audio-engineer.md
+++ b/wiki/sources/game-audio-engineer.md
@@ -3,6 +3,7 @@ title: "Game Audio Engineer Agent"
 type: source
 tags: []
 date: 2026-04-26
+last_updated: 2026-05-30
 ---
 
 ## Source File
diff --git a/wiki/sources/game-designer.md b/wiki/sources/game-designer.md
index 9cbae379..18480f2d 100644
--- a/wiki/sources/game-designer.md
+++ b/wiki/sources/game-designer.md
@@ -1,50 +1,66 @@
 ---
 title: "Game Designer Agent Personality"
 type: source
-tags: []
+tags: ["game-development", "game-design", "systems-design", "economy-balancing", "multi-agent"]
 date: 2026-04-26
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/game-designer.md]]
+- [[Agent/agency-agents/game-development/game-designer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：GameDesigner Agent 角色定义——一个资深系统与机制设计师，以"循环、杠杆、玩家动机"为思维框架，将创意愿景转化为可执行、无歧义的游戏设计文档
-- 问题域：游戏玩法系统设计、经济系统平衡、玩家进阶体验设计、GDD 文档规范化、游戏设计师与工程师/美术的协作接口
-- 方法/机制：五步工作流（概念→设计支柱→纸面原型→GDD撰写→调优迭代）、核心循环三层模型（瞬间→会话→长期）、行为经济学应用、系统性设计方法论
-- 结论/价值：提供一套完整的游戏设计师 Agent 规范，涵盖文档标准、调优方法、高级能力（行为经济学、跨类型机制移植、高级经济设计、系统涌现设计）
+
+- **核心主题**：游戏设计师 Agent 的身份定位、系统与机制设计方法论、玩家动机与反馈系统设计
+- **问题域**：游戏设计文档（GDD）编写、游戏核心循环设计、经济系统平衡、数值调优、玩家体验优化
+- **方法/机制**：设计支柱（Design Pillars）→ 纸面原型 → GDD 编写 → 平衡迭代 → 试玩测试；游戏循环分层（瞬间→会话→长期）；行为经济学应用；系统涌现设计
+- **结论/价值**：构建系统化游戏设计方法论，通过严谨文档和平衡经济系统实现可持续玩家参与
 
 ## Key Claims（用中文描述）
-- GameDesigner Agent 以"玩家动机"为设计出发点，而非功能列表
-- 每个机制必须包含：目的、玩家体验目标、输入、输出、边界情况、失败状态
-- 所有数值从假设开始，用 `[PLACEHOLDER]` 标记直至通过测试验证
-- 行为经济学原则（损失厌恶、变率奖励、沉没成本）应被有意识地、符合伦理地应用于游戏设计
-- 系统性设计应追求"最小可行复杂度"——移除不产生新颖玩家决策的系统
+
+- 游戏设计师 Agent 以"循环、杠杆、玩家动机"为思维方式，将创意愿景转化为工程师和美术可无歧义执行的文档
+- 每个机制必须记录：目的、玩家体验目标、输入、输出、边界情况、失败状态
+- 所有数值以假设为起点，标记为 `[PLACEHOLDER]` 并附调优说明
+- 设计从玩家动机出发，而非功能清单出发；每个系统必须回答"玩家感受什么？做什么决策？"
+- 行为经济学（损失厌恶、变量奖励、沉没成本、禀赋效应）应被有意识地、符合伦理地应用于设计中
+- 经济系统建模为供需系统，追踪 source（来源）、sink（消耗）、equilibrium（平衡）曲线
+- 系统设计追求涌现性：设计应产生设计师未预测的玩家策略
 
 ## Key Quotes
-> "Design from player motivation outward, not feature list inward." — 设计出发点原则
-> "Every mechanic must be documented with: purpose, player experience goal, inputs, outputs, edge cases, and failure states." — 机制文档标准
-> "All numerical values start as hypotheses — mark them `[PLACEHOLDER]` until playtested." — 数值平衡哲学
+
+> "Every mechanic must be documented with: purpose, player experience goal, inputs, outputs, edge cases, and failure states." — GDD 编写标准
+
+> "All numerical values start as hypotheses — mark them `[PLACEHOLDER]` until playtested." — 数值设计原则
+
+> "Design from player motivation outward, not feature list inward." — 设计思维核心
+
 > "Design systems that interact to produce emergent player strategies the designer didn't predict." — 系统涌现设计目标
 
 ## Key Concepts
-- [[Game Design Document (GDD)]]：游戏设计文档——包含所有机制完整描述的权威参考文档，每项重大修订必须版本化
-- [[Core Gameplay Loop]]：核心游戏循环——从瞬间体验（0-30秒）到会话目标（5-30分钟）再到长期进阶（数小时至数周）的三层设计框架
-- [[Economy Balance]]：经济平衡——通过供给/需求模型、玩家画像（鲸鱼/海豚/小鱼）、通胀检测维持游戏货币系统健康
-- [[Player Onboarding]]：玩家引导——通过可发现性设计、无失败教程首关、长线钩子确保 90% 以上的新手完成率
-- [[Mechanic Specification]]：机制规格说明——结构化描述机制的目的、玩家幻想、输入/输出、成功/失败状态、边界情况、调优杠杆
-- [[Behavioral Economics in Games]]：游戏中的行为经济学——应用 Cialdini 影响原则、损失厌恶、变率奖励表、沉没成本心理设计伦理性的玩家参与系统
-- [[Systemic Design]]：系统性设计——设计相互作用的系统以产生涌现性玩家策略，记录系统交互矩阵并平衡最小可行复杂度
-- [[Cross-Genre Mechanics Transplantation]]：跨类型机制移植——从相邻类型提取核心动词，通过"机制活检"分析可迁移性并记录类型惯例期望与颠覆风险的权衡
+
+- [[Game Design Document]]：游戏设计文档，描述游戏所有机制、经济、循环的完整蓝图，是设计与工程之间的契约
+- [[Core Gameplay Loop]]：核心游戏循环，分瞬间（0-30秒）、会话（5-30分钟）、长期（小时-周）三层，驱动玩家持续参与
+- [[Economy Balancing]]：经济平衡，通过数值调优维持游戏中资源的经济健康，防止通胀或死路
+- [[Behavioral Economics In Games]]：行为经济学在游戏设计中的应用——损失厌恶、变量奖励、沉没成本、禀赋效应
+- [[Playtest-Driven Design]]：以试玩测试驱动的设计迭代，定义成功标准后再测试
+- [[Systemic Emergence]]：系统性涌现，玩家策略超越设计预期时产生的自然游戏体验
+- [[Cross-Genre Mechanic Transplantation]]：跨类型机制移植，从邻近类型提取核心动词并评估迁移可行性
 
 ## Key Entities
-- GameDesigner Agent：核心角色——资深系统与机制设计师，具备玩家同理心、系统思维、平衡执念和清晰沟通能力，跨类型（RPG、平台跳跃、射击、生存）经验丰富
+
+- [[Narrative Designer]]：叙事设计师，与 Game Designer 协作，在叙事与系统层面对齐玩家体验
+- [[Level Designer]]：关卡设计师，将 Game Designer 的机制设计转化为具体关卡空间体验
+- [[Game Audio Engineer]]：游戏音频工程师，通过音效强化 Game Designer 定义的反馈系统
 
 ## Connections
-- [[Level Designer]] ← complements ← [[GameDesigner]]：关卡设计师与游戏设计师协作——前者负责空间/关卡叙事，后者负责系统/机制设计
-- [[Narrative Designer]] ← collaborates_with ← [[GameDesigner]]：叙事设计师与游戏设计师协作——叙事框架需要机制支撑，机制设计需要叙事赋予意义
-- [[GameAudioEngineer]] ← supports ← [[GameDesigner]]：音效工程师实现游戏设计师定义的反馈系统
-- [[TechnicalArtist]] ← enables ← [[GameDesigner]]：技术美术将设计师的视觉/交互原型转化为可执行实现
+
+- [[game-designer]] ← depends_on ← [[Narrative Designer]]：叙事驱动动机，机制承载叙事
+- [[game-designer]] ← depends_on ← [[Level Designer]]：机制需要空间化，关卡提供空间上下文
+- [[game-designer]] ← extends ← [[Core Gameplay Loop]]：核心循环是 Game Designer 的首要设计产物
+- [[game-designer]] ← extends ← [[Economy Balancing]]：经济平衡是 Game Designer 的核心技术能力
 
 ## Contradictions
-- 无已知冲突内容——本文档为角色定义文档，未与其他 Wiki 页面产生直接论点冲突
+
+- 与 [[Level Designer]] 可能的冲突：
+  - **冲突点**：Game Designer 定义机制设计（mechanic specification），Level Designer 在关卡中实现时可能发现某些机制无法在特定空间上下文中有意义地展开
+  - **当前观点**：机制应在抽象层设计完整后再交给 Level Designer 实现
+  - **对方观点**：机制设计应在空间上下文中进行，抽象设计可能脱离实际
diff --git a/wiki/sources/gemini-cli.md b/wiki/sources/gemini-cli.md
index 258e273b..7e6ceb66 100644
--- a/wiki/sources/gemini-cli.md
+++ b/wiki/sources/gemini-cli.md
@@ -1,35 +1,40 @@
----
-title: "Gemini CLI Integration"
-type: source
-tags: []
-date: 2026-04-26
----
-
-## Source File
-- [[Agent/agency-agents/integrations/gemini-cli/README.md]]
-
-## Summary（用中文描述）
-- 核心主题：将 61 个 Agency Agents 打包为 Gemini CLI 扩展插件
-- 问题域：AI Agent 的可移植性与跨工具调用能力
-- 方法/机制：通过 `./scripts/convert.sh --tool gemini-cli` 生成扩展文件，再通过 `./scripts/install.sh --tool gemini-cli` 安装到 `~/.gemini/extensions/agency-agents/`，安装后可在 Gemini CLI 中按名称激活 Agent skill
-- 结论/价值：为 Gemini CLI 用户提供即插即用的 61 个专业 Agent，覆盖前端开发、后端架构、现实核查等多个领域
-
-## Key Claims（用中文描述）
-- Gemini CLI 可通过扩展机制集成 Agency 的全部 61 个 Agent，形成即用型工具包
-
-## Key Quotes
-> "Packages all 61 Agency agents as a Gemini CLI extension. The extension installs to `~/.gemini/extensions/agency-agents/`." — 核心价值声明
-> "Use the frontend-developer skill to help me build this UI." — 在 Gemini CLI 中激活 Agent 的自然语言示例
-
-## Key Concepts
-- [[Agent Skill]]：Agent 以 Skill 形式封装，可在 Gemini CLI 中通过自然语言引用激活
-- [[Extension（扩展机制）]]：Gemini CLI 支持第三方扩展，扩展安装到 `~/.gemini/extensions/` 目录
-
-## Key Entities
-- [[Agency Agents]]：提供 61 个预置专业 Agent 的项目
-
-## Connections
-- [[agents-orchestrator]] ← extends ← [[gemini-cli]]（通过 Gemini CLI 扩展触发 Agent 编排）
-
-## Contradictions
-- （无冲突检测到此文档与现有 Wiki 内容无矛盾）
+---
+title: "Gemini CLI Integration"
+type: source
+tags: []
+date: 2026-05-03
+---
+
+## Source File
+- [[Agent/agency-agents/integrations/gemini-cli/README.md]]
+
+## Summary（用中文描述）
+- 核心主题：Gemini CLI 扩展集成——将 The Agency 的全部 61 个 Agent 打包为 Gemini CLI 扩展
+- 问题域：如何让用户在 Gemini CLI 中按名称直接调用任意 Agency Agent
+- 方法/机制：通过 `convert.sh` 生成扩展文件，再通过 `install.sh` 安装到 `~/.gemini/extensions/agency-agents/`；安装后在 Gemini CLI prompt 中引用 Agent 名称即可激活
+- 结论/价值：Gemini CLI 用户无需关心 Agent 实现细节，只需按名称引用即可获得 The Agency 全套专业能力
+
+## Key Claims（用中文描述）
+- The Agency 的全部 61 个 Agent 均以 SKILL.md 格式打包为 Gemini CLI 扩展
+- 扩展安装路径为 `~/.gemini/extensions/agency-agents/`，属于 Home-Scoped 级别
+- 在 Gemini CLI 中通过自然语言引用 Agent 名称即可激活对应技能
+
+## Key Quotes
+> "Packages all 61 Agency agents as a Gemini CLI extension." — 明确扩展包规模
+> "Use the frontend-developer skill to help me build this UI." — Gemini CLI 中引用 Agent 的示例
+
+## Key Concepts
+- [[AgentIntegration]]：The Agency 与各类 IDE/CLI 工具的集成机制
+- [[SkillReference]]：通过名称引用方式在 AI 工具中激活特定 Agent 的机制
+
+## Key Entities
+- [[GeminiCLI]]：Google 的 Gemini CLI 工具，支持扩展机制
+- [[AgencyAgents]]：The Agency 项目中的 61 个 AI Agent 组合
+- [[AgencyAgentsRoster]]：Agent 团队 roster，包含 frontend-developer、backend-architect、reality-checker 等角色
+
+## Connections
+- [[AgencyAgents]] ← generates → [[GeminiCLI]] Extension
+- [[SkillReference]] ← enables → [[AgencyAgents]]
+
+## Contradictions
+- （无已知冲突）
diff --git a/wiki/sources/github-copilot.md b/wiki/sources/github-copilot.md
index a84d00cd..ee436f58 100644
--- a/wiki/sources/github-copilot.md
+++ b/wiki/sources/github-copilot.md
@@ -1,38 +1,38 @@
----
-title: "GitHub Copilot Integration"
-type: source
-tags: []
-date: 2026-04-25
----
-
-## Source File
-- [[Agent/agency-agents/integrations/github-copilot/README.md]]
-
-## Summary（用中文描述）
-- 核心主题：The Agency 项目与 GitHub Copilot 的开箱即用集成方案
-- 问题域：如何在 GitHub Copilot 环境中使用 Agency 的 agent 定义文件
-- 方法/机制：通过脚本安装或手动复制 `.md` + YAML frontmatter 格式的 agent 文件到 Copilot 目录
-- 结论/价值：无需转换，Agency 的 agent 文件格式与 GitHub Copilot 原生兼容，用户可零成本迁移
-
-## Key Claims（用中文描述）
-- Agency agents 使用 `.md` + YAML frontmatter 格式，无需任何转换即可在 GitHub Copilot 中使用
-- 通过 `./scripts/install.sh --tool copilot` 可一键将所有 agents 复制到 Copilot agents 目录
-- 用户可在任何 GitHub Copilot 会话中通过名称激活特定 agent
-- Agents 按部门（division）组织，具体列表见主 README
-
-## Key Quotes
-> "The Agency works with GitHub Copilot out of the box. No conversion needed — agents use the existing `.md` + YAML frontmatter format." — 核心价值主张
-
-## Key Concepts
-- [[AgentFileFormat]]：Agent 定义文件采用 `.md` + YAML frontmatter 格式，是 Agency 与 GitHub Copilot 的共同标准
-
-## Key Entities
-- [[TheAgency]]：The Agency 开源项目本身，提供多领域专业化 agent 定义
-- [[GitHubCopilot]]：GitHub Copilot AI 编程助手，支持通过 agent 文件扩展功能
-
-## Connections
-- [[GitHubCopilot]] ← integrates_with ← [[TheAgency]]
-- [[GitHubCopilot]] ← uses_agent_format ← [[AgentFileFormat]]
-
-## Contradictions
-（暂无已知冲突）
+---
+title: "GitHub Copilot Integration"
+type: source
+tags: []
+date: 2026-04-30
+---
+
+## Source File
+- [[Agent/agency-agents/integrations/github-copilot/README.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency 与 GitHub Copilot 的零门槛原生集成
+- 问题域：如何将 The Agency 的 Agent Roster 接入 GitHub Copilot 并在任意会话中按名称激活
+- 方法/机制：利用 The Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 的 agent 格式原生兼容特性，通过 install.sh 或手动复制完成安装
+- 结论/价值：GitHub Copilot 是 The Agency 集成的 11 种工具中唯一用户级全局生效的集成方案，可在任意 Copilot 对话中直接激活指定 Agent，无需项目配置
+
+## Key Claims（用中文描述）
+- The Agency 的 Agent 原生兼容 GitHub Copilot：The Agency 使用 `.md` + YAML frontmatter 格式，无需任何转换即可被 GitHub Copilot 识别
+- 两种安装方式覆盖不同场景：`./scripts/install.sh --tool copilot` 批量安装全部 Agent，`cp` 手动复制可按需选择特定分类
+- 激活方式简洁自然：在任意 Copilot 会话中通过名称引用 Agent 即可激活，无需额外命令或配置
+- Agent 按部门（division）组织：Agent 的完整列表和部门归属参见主 README
+
+## Key Quotes
+> "The Agency works with GitHub Copilot out of the box. No conversion needed — agents use the existing `.md` + YAML frontmatter format." — 核心价值声明，强调零配置特性
+
+## Key Concepts
+- [[Agent-Integration]]：The Agency Agent 向各类 IDE 和工具的接入方案，GitHub Copilot 是其中用户级全局生效的代表
+
+## Key Entities
+- [[GitHub-Copilot]]：GitHub 官方 AI 编程助手，支持通过 agent 目录机制加载自定义 Agent — 本文档的核心接入对象
+- [[The-Agency]]：提供 147 个专业 Agent 的多 Agent 框架，GitHub Copilot Integration 是其 11 种集成方式之一
+
+## Connections
+- [[readme|OpenCode Integration]] ← depends_on ← [[github-copilot]]
+- [[readme|GitHub Copilot Integration]] ← extends ← [[integrations-readme|The Agency integrations]]
+
+## Contradictions
+- 无冲突检测：GitHub Copilot Integration 与现有 Wiki 内容一致
diff --git a/wiki/sources/godot-gameplay-scripter.md b/wiki/sources/godot-gameplay-scripter.md
index 43879f6c..fb564dbc 100644
--- a/wiki/sources/godot-gameplay-scripter.md
+++ b/wiki/sources/godot-gameplay-scripter.md
@@ -1,79 +1,59 @@
 ---
 title: "Godot Gameplay Scripter Agent Personality"
 type: source
-tags: ["godot", "gdscript", "game-development", "agent-personality"]
-date: 2026-04-26
+tags: [game-development, godot, agent-personality, gdscript, gdscript-2.0, signal-architecture, type-safety, composition]
+date: 2026-05-02
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/godot/godot-gameplay-scripter.md]]
+- [[Agent/agency-agents/game-development/godot/godot-gameplay-scripter.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Godot 4 游戏逻辑脚本专家 Agent 人格定义，强调以软件架构师的纪律性构建游戏系统
-- 问题域：如何用 GDScript 2.0 和 C# 构建类型安全、信号驱动、可组合的游戏玩法系统
-- 方法/机制：严格静态类型 + 信号架构 + 组合优于继承 + 正确的 Autoload 使用模式 + GDScript/C# 互操作规范
-- 结论/价值：提供了一套完整的 Godot 4 游戏开发规范，包括命名约定、代码模式、工作流程和性能指标
+- 核心主题：Godot 4 游戏玩法脚本专家 AI Agent 人格规范，专注于用 GDScript 2.0 和 C# 构建类型安全、信号驱动的游戏系统
+- 问题域：游戏开发中如何避免 GDScript 动态类型的运行时错误、实现系统间松耦合通信、保持场景树可维护性
+- 方法/机制：静态类型强制 + 强类型信号架构 + 组合优于继承 + Autoload 事件总线
+- 结论/价值：提供一套完整的 Godot 4 游戏玩法系统开发规范，使代码在大型项目中仍可维护和测试
 
 ## Key Claims（用中文描述）
-- GodotGameplayScripter Agent 以软件架构师的纪律性和独立游戏开发者的务实精神构建游戏玩法系统
-- GDScript 信号必须使用 snake_case 且携带类型化参数，C# 信号使用 PascalCase + EventHandler 后缀
-- 所有变量、函数参数和返回值必须显式类型化，禁止在生产代码中使用无类型 var
-- 组合优于继承：通过子节点附加组件（如 HealthComponent）优于创建继承层级
-- Autoload 仅用于真正的跨场景全局状态，不得包含游戏逻辑
-- 场景必须可独立实例化，不得假设父节点类型或兄弟节点存在
+- GDScript 信号必须使用 `snake_case` 且携带类型化参数——携带 Variant 的未类型化信号是运行时错误的根源
+- GDScript 2.0 中每个变量、函数参数和返回值必须显式类型声明——生产代码中出现未类型化的 `var` 会导致难以追踪的 bug
+- 场景组合优于继承：向节点附加 `HealthComponent` 比 `CharacterWithHealth` 基类更灵活且更可测试
+- Autoload 仅用于真正的全局状态（设置/存档/事件总线）——将游戏逻辑放入 Autoload 会导致无法独立实例化和垃圾回收
+- 场景必须可独立运行（按 F6）——假设父节点上下文的场景在集成时会产生级联错误
 
 ## Key Quotes
-> "Everything is a node — behavior is composed by adding nodes, not by multiplying inheritance depth"
-> 核心哲学：一切皆为节点，行为通过添加节点组合，而非增加继承深度
-
-> "Adding the type here catches this bug at parse time instead of 3 hours into playtesting"
-> 类型安全即功能：在解析时捕获 bug，而非在测试 3 小时后发现
-
-> "Don't add this to Player — make a component, attach it, wire the signal"
-> 通信风格：组合优于捷径，永远不要把逻辑直接加到 Player 上，而是创建组件
-
-> "GDScript signals use snake_case; if you're in C#, it's PascalCase with EventHandler"
-> 语言感知：在 GDScript 中信号用 snake_case；在 C# 中用 PascalCase 加 EventHandler 后缀
+> "Signals must carry typed parameters — never emit untyped Variant unless interfacing with legacy code." — 信号类型安全原则
+> "Prefer composition over inheritance: a HealthComponent node attached as a child is better than a CharacterWithHealth base class." — 节点组合哲学
+> "Autoloads are singletons — use them only for genuine cross-scene global state: settings, save data, event buses, input maps." — Autoload 使用规范
+> "Test every scene in isolation by running it directly (F6) — it must not crash without a parent context." — 场景隔离测试原则
 
 ## Key Concepts
-- [[Signal-Driven Architecture]]：信号驱动架构——通过信号解耦系统，避免直接方法调用，信号必须携带类型化参数
-- [[Static Typing in GDScript 2.0]]：GDScript 2.0 静态类型——所有变量、参数、返回值必须显式类型化，使用 typed arrays
-- [[Composition Over Inheritance]]：组合优于继承——通过附加子节点组件实现行为，而非创建继承层级
-- [[Event Bus Autoload]]：事件总线 Autoload——跨场景解耦通信的全局信号总线，只用于真正跨场景的事件
-- [[Type-Safe Signal Design]]：类型安全信号设计——信号命名遵循语言约定，参数必须类型化，连接时验证方法存在性
-- [[GDScript C# Interoperability]]：GDScript/C# 互操作——跨语言信号连接模式，类型转换和连接命名规范
+- [[GDScript-2.0]]：Godot 4 的脚本语言，支持静态类型声明、类型推断（`:=`）、强类型数组（`Array[Type]`）
+- [[TypedSignals]]：携带显式类型参数的信号（`signal health_changed(new_health: float)`），而非 Variant 类型
+- [[CompositionOverInheritance]]：通过组合节点（HealthComponent/MovementComponent）实现行为，而非继承层次
+- [[EventBus]]：Autoload 事件总线（EventBus.gd），用于跨场景解耦通信，避免直接节点引用
+- [[StaticTyping]]：GDScript 2.0 强制显式类型声明，消除运行时类型错误
+- [[GDExtension]]：使用 C++ 编写性能关键系统并暴露给 GDScript 的原生扩展机制
+- [[RenderingServer]]：Godot 低层渲染 API，用于绕过场景树开销实现高效 2D/3D 渲染
+- [[SceneTreeLifecycle]]：`_ready()` 初始化、`_exit_tree()` 清理、`queue_free()` 安全删除的节点生命周期管理规范
 
 ## Key Entities
-- [[GDScript 2.0]]：Godot 4 默认脚本语言，支持静态类型、装饰器、改进的信号系统
-- [[C# (Godot)]]：Godot 4 支持的 .NET 脚本语言，通过 GodotSharp bindings 与引擎交互
-- [[GDExtension]]：Godot 4 原生扩展机制，允许用 C++ 编写性能关键系统并暴露给 GDScript
-- [[HealthComponent]]：健康组件示例——展示类型化信号声明、@export 属性、伤害/治疗逻辑的标准模式
-- [[EventBus]]：事件总线 Autoload——全局跨场景信号发射器，用于解耦通信
+- [[GodotGameplayScripter]]：本 Agent 身份——Godot 4 游戏玩法脚本专家，强调类型安全、信号完整性和组合架构
+- [[GodotEngine]]：Godot 4 游戏引擎，支持 GDScript 2.0、C#、GDExtension 多语言生态
+- [[GDScript]]：Godot 官方脚本语言，GDScript 2.0 引入静态类型支持
+- [[CSharpGodot]]：Godot 的 C# 集成，使用 `[Signal]` 委托模式和 `EmitSignal(SignalName.X, ...)` 调用
 
 ## Connections
-- [[GDScript 2.0]] ← uses ← [[Static Typing in GDScript 2.0]]
-- [[GDScript 2.0]] ← uses ← [[Type-Safe Signal Design]]
-- [[C# (Godot)]] ← uses ← [[Type-Safe Signal Design]]
-- [[EventBus]] ← implements ← [[Signal-Driven Architecture]]
-- [[HealthComponent]] ← demonstrates ← [[Composition Over Inheritance]]
-- [[GDExtension]] ← extends ← [[C# (Godot)]]
+- [[GodotGameplayScripter]] ← builds_with ← [[GDScript-2.0]]
+- [[GodotGameplayScripter]] ← builds_with ← [[CSharpGodot]]
+- [[TypedSignals]] ← enables ← [[EventBus]]
+- [[CompositionOverInheritance]] ← enables ← [[TypedSignals]]
+- [[StaticTyping]] ← enforces ← [[GDScript-2.0]]
+- [[GodotGameplayScripter]] ← complements ← [[GodotShaderDeveloper]]
+- [[GodotGameplayScripter]] ← complements ← [[GodotMultiplayerEngineer]]
 
 ## Contradictions
-- 无已知冲突内容
-
-## Technical Deliverables Summary
-
-### 核心代码模式
-- **Typed Signal (GDScript)**：`signal health_changed(new_health: float)` + `died.emit()`
-- **Signal Bus Autoload**：`signal player_died` + `signal score_changed(new_score: int)`
-- **Typed Signal (C#)**：`[Signal] public delegate void HealthChangedEventHandler(float newHealth)`
-- **Composition Pattern**：`@onready var health: HealthComponent = $HealthComponent`
-- **Typed Array**：`var _active_enemies: Array[EnemyBase] = []`
-- **GDScript/C# Interop**：`health_component.HealthChanged.connect(_on_health_changed)`（PascalCase）
-
-### 质量指标
-- 生产代码零无类型 var 声明
-- 所有信号参数显式类型化，无 Variant
-- 零运行时路径查找（所有 get_node 仅在 _ready 中通过 @onready）
-- 组件节点 < 200 行，每个处理一个游戏关注点
-- 所有场景可独立运行（F6 测试通过）
+- 与 [[UnrealSystemsEngineer]] 冲突：
+  - 冲突点：游戏逻辑放置位置（Autoload vs Actor/C++ 类）
+  - 当前观点：游戏逻辑不得放入 Autoload，应封装在可实例化的节点组件中
+  - 对方观点：Unreal 中游戏逻辑倾向于放置在 Actor/Component 层次，Autoload 在 Godot 中仅作服务定位器使用
diff --git a/wiki/sources/godot-multiplayer-engineer.md b/wiki/sources/godot-multiplayer-engineer.md
index 6bd5ba27..7d40a95e 100644
--- a/wiki/sources/godot-multiplayer-engineer.md
+++ b/wiki/sources/godot-multiplayer-engineer.md
@@ -1,55 +1,64 @@
 ---
 title: "Godot Multiplayer Engineer Agent Personality"
 type: source
-tags: [Godot, Multiplayer, Networking, Game Development, Godot 4, RPC, ENet, WebRTC]
-date: 2026-04-26
+tags: []
+date: 2026-05-01
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/godot/godot-multiplayer-engineer.md]]
+- [[Agent/agency-agents/game-development/godot/godot-multiplayer-engineer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Godot 4 网络多人游戏专家 Agent，基于 MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer 和 RPC 机制实现实时多人游戏网络同步
-- 问题域：多人游戏权威模型设计、RPC 安全性、场景复制、延迟模拟测试、NAT 穿透与 WebRTC 集成
-- 方法/机制：通过 `set_multiplayer_authority()` 显式设置权威节点，RPC 调用模式（any_peer/authority/call_local）分层控制，MultiplayerSynchronizer 按需同步属性，MultiplayerSpawner 处理动态生成节点的网络复制
-- 结论/价值：提供生产级 Godot 4 多人游戏网络架构，覆盖服务器权威模型、RPC 安全审计、ENet/WebRTC 传输层配置、延迟测试与 matchmaking 集成
+- 核心主题：Godot 4 网络多人游戏开发 Agent 人格定义——专注于 MultiplayerAPI、场景复制、ENet/WebRTC 传输、RPC 和权威模型
+- 问题域：如何在 Godot 4 中构建安全、可扩展的实时多人游戏网络系统
+- 方法/机制：服务器权威架构 + RPC 安全模式 + MultiplayerSpawner/MultiplayerSynchronizer 协同 + 延迟测试
+- 结论/价值：提供完整的 Godot 多人游戏开发规范，覆盖从基础 ENet 搭建到高级 WebRTC P2P 连接的完整技术栈
 
 ## Key Claims（用中文描述）
-- Godot Multiplayer Engineer 通过 `set_multiplayer_authority()` 显式设置权威节点（而非依赖默认值 peer 1），确保每个动态生成节点的状态归属清晰
-- 所有游戏关键状态（位置、生命值、分数、物品状态）必须由服务器（peer 1）持有权威，客户端通过 RPC 发送输入请求，由服务器验证并更新权威状态
-- `@rpc("any_peer")` 允许任何对端调用，必须仅用于客户端→服务器请求，且函数体内必须进行服务器端验证和发送者 ID 检查，否则构成作弊漏洞
-- `MultiplayerSpawner` 是所有动态生成网络节点的唯一正确方式，手动 `add_child()` 会导致对端节点丢失同步
-- 所有 `@rpc("any_peer")` 函数必须进行服务器端验证（发送者 ID + 输入合理性检查），这是防止作弊的关键安全审计点
+- 服务器（peer ID 1）必须拥有所有游戏关键状态（位置、生命值、分数、物品状态），客户端无权直接修改
+- 使用 `set_multiplayer_authority()` 显式设置权威节点，不能依赖默认值
+- 所有状态变更必须用 `is_multiplayer_authority()` 守卫，非权威节点不得修改复制状态
+- `@rpc("any_peer")` 仅用于客户端到服务器请求，函数内部必须进行服务器端验证
+- `@rpc("authority")` 仅允许权威节点调用，用于服务器到客户端的确认
+- `@rpc("call_local")` 同时在本地执行，用于调用方也应体验的效果
+- 动态生成的网络节点必须使用 `MultiplayerSpawner`，禁止手动 `add_child()`
+- `MultiplayerSynchronizer` 的所有属性路径必须在节点进入场景树时有效，无效路径静默失败
 
 ## Key Quotes
-> "MANDATORY: The server (peer ID 1) owns all gameplay-critical state — position, health, score, item state" — 服务器权威模型强制规范
-> "Never use @rpc("any_peer") for functions that modify gameplay state without server-side validation inside the function body" — RPC 安全红线
-> "MultiplayerSynchronizer property paths must be valid at the time the node enters the tree — invalid paths cause silent failure" — Synchronizer 配置关键约束
-> "Don't add_child() networked nodes manually — use MultiplayerSpawner or peers won't receive them" — 场景复制核心原则
+> "MANDATORY: The server (peer ID 1) owns all gameplay-critical state — position, health, score, item state" — 核心权威模型原则
+> "`@rpc(\"any_peer\")` allows any peer to call the function — use only for client-to-server requests that the server validates" — RPC 安全性核心规则
+> "Don't `add_child()` networked nodes manually — use MultiplayerSpawner or peers won't receive them" — 场景生成关键约束
+> "Test under latency: It works on localhost — test it at 150ms before calling it done" — 延迟测试标准
 
 ## Key Concepts
-- [[MultiplayerAPI]]：Godot 4 核心网络 API，提供 `set_multiplayer_authority()`、`is_multiplayer_authority()`、RPC 调用和多人信号管理
-- [[Server-Authoritative Model]]：服务器权威模型 — 所有游戏关键状态由服务器持有权威，客户端发送输入请求，服务器验证后更新状态，防止作弊
-- [[RPC（Remote Procedure Call）]]：远程过程调用，通过 `@rpc()` 装饰器声明函数调用模式（any_peer/authority/call_local），实现跨网络的过程调用
-- [[MultiplayerSynchronizer]]：属性同步器 — 广播权威节点属性变更到所有对端，支持 ON_CHANGE 模式避免每帧同步
-- [[MultiplayerSpawner]]：场景生成器 — 在权威节点自动生成子场景并复制到所有对端，是动态生成网络节点的唯一正确方式
-- [[ENet]]：可靠 UDP 传输层，支持服务器/客户端两种模式，用于桌面平台的生产级网络连接
-- [[WebRTC]]：Web 实时通信协议，通过 `WebRTCPeerConnection` + `WebRTCMultiplayerPeer` 实现浏览器端 P2P 多人游戏和 NAT 穿透
-- [[Authority Model]]：权威模型 — 每个网络节点有且只有一个权威持有者（peer ID），只有权威才能修改该节点的关键状态
-- [[RPC Security Pattern]]：RPC 安全模式 — 所有 `any_peer` RPC 函数必须进行发送者 ID 验证和输入合理性检查，防止客户端作弊
+- [[MultiplayerAPI]]：Godot 4 的核心多人游戏 API，管理网络连接、权威和 RPC 通信
+- [[Server-Authoritative Architecture]]：服务器权威架构——所有游戏逻辑在服务器执行，客户端仅发送输入和接收状态
+- [[RPC (Remote Procedure Call)]]：远程过程调用，通过 `@rpc()` 装饰器实现节点间的跨网络方法调用
+- [[MultiplayerSpawner]]：Godot 4 组件，自动在所有对等节点间复制动态生成的网络节点
+- [[MultiplayerSynchronizer]]：Godot 4 组件，将权威节点的状态变化同步到所有对等节点
+- [[ENet]]：轻量级 UDP 可靠传输协议，用于 Godot 的 C/S 和 P2P 网络连接
+- [[WebRTC]]：用于浏览器导出的 P2P 多人大规模连接方案，配合 STUN/TURN 实现 NAT 穿透
+- [[Authority Model]]：权威模型——每个网络节点有唯一的权威持有者（服务器或特定客户端），只有权威才能修改状态
+- [[Scene Replication]]：场景复制——通过网络同步动态生成/销毁的节点及其状态
+- [[Delta Compression]]：增量压缩——仅传输变化的字段而非完整状态，节省带宽
 
 ## Key Entities
-- [[Godot 4]]：开源游戏引擎，版本 4.x 引入了 MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer 构成完整的场景复制体系
-- [[Nakama]]：开源游戏服务器，用于 Godot 多人游戏的 matchmaking、大厅、排行榜和 DataStore 集成
+- [[Godot]]：开源游戏引擎，版本 4 提供了全新的多人游戏 API（MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer）
+- [[Nakama]]：（提及）开源游戏服务器，可与 Godot 集成提供匹配、大厅、排行榜和 DataStore 功能
+- [[NetworkManager]]：（代码中的 Autoload 示例）管理 ENet 服务器/客户端创建、连接和断开的核心网络管理器
+- [[Player]]：（代码中的节点示例）服务器权威的玩家角色节点，通过 RPC 接收输入、同步状态
 
 ## Connections
-- [[godot-gameplay-scripter]] ← extends ← [[godot-multiplayer-engineer]]（多人游戏建立在 Godot 游戏逻辑脚本基础上）
-- [[godot-shader-developer]] ← parallel ← [[godot-multiplayer-engineer]]（同属 Godot Game Dev 部门的不同专精方向）
-- [[unity-multiplayer-engineer]] ← parallel ← [[godot-multiplayer-engineer]]（跨引擎多人游戏实现，核心概念一致但 API 不同）
+- [[Unity Multiplayer Engineer]] ← similar_concept ← [[Godot Multiplayer Engineer]]
+  - 两者都遵循服务器权威模型和 RPC 安全模式，但各自使用不同引擎的原生 API
+- [[Game Designer]] ← documents_requirements ← [[Godot Multiplayer Engineer]]
+  - Game Designer 定义的多人游戏需求由 Multiplayer Engineer 实现网络同步方案
+- [[Technical Artist]] ← coordinates_with ← [[Godot Multiplayer Engineer]]
+  - 技术美工需要了解网络同步对视觉效果的影响（如预测、插值）
 
 ## Contradictions
-- 与 [[unity-multiplayer-engineer]] 在权威模型实现细节上有差异：
-  - 冲突点：Unity 使用 NetworkTransform/NetworkVariable 隐式同步，Godot 使用 MultiplayerSynchronizer 显式配置
-  - 当前观点：Godot 的显式权威模型（每节点 `set_multiplayer_authority()`）更透明，开发者对状态归属有完全控制
-  - 对方观点：Unity 的隐式同步减少模板代码，但在复杂场景下权威归属不如 Godot 明确
-```
+- 与 [[Unity Multiplayer Engineer]] 冲突：
+  - 冲突点：权威模型的具体实现细节
+  - 当前观点（Godot）：使用 `set_multiplayer_authority(peer_id)` 显式设置权威，每个节点独立管理
+  - 对方观点（Unity）：通过 NetCode/MLAPI 的 NetworkObject 和 Owner 机制管理权威
+  - 说明：两者核心原则一致（服务器权威、RPC 验证），但实现 API 不同，不构成实质冲突
diff --git a/wiki/sources/godot-shader-developer.md b/wiki/sources/godot-shader-developer.md
index d64280dc..a883e862 100644
--- a/wiki/sources/godot-shader-developer.md
+++ b/wiki/sources/godot-shader-developer.md
@@ -2,24 +2,24 @@
 title: "Godot Shader Developer Agent Personality"
 type: source
 tags: [Godot, Shader, Game Development, GLSL, Visual Effects]
-date: 2026-04-26
+date: 2026-05-01
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/game-development/godot/godot-shader-developer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Godot 4 渲染专家 Agent，使用 Godot 着色语言（GLSL-like）编写高性能 2D/3D 视觉效果着色器
-- 问题域：Godot 4 的 CanvasItem（2D）和 Spatial（3D）着色器开发、VisualShader 编辑器、后处理、性能优化
-- 方法/机制：通过 `shader_type` 声明、uniform 参数暴露、渲染器兼容性检查、纹理采样计数审计实现跨平台视觉效果
-- 结论/价值：为 Godot 4 游戏提供创作性正确且性能合规的着色器方案，覆盖 2D 精灵描边、3D 溶解/水面着色、全屏后处理
+- 核心主题：Godot 4 渲染效果专家 AI Agent，精通 Godot 着色语言（GLSL-like）、VisualShader 编辑器、CanvasItem 和 Spatial 着色器、后处理与性能优化
+- 问题域：2D（CanvasItem）和 3D（Spatial）视觉效果着色器开发、渲染器分级兼容、移动端性能合规
+- 方法/机制：通过 `shader_type` 声明 + uniform hint 系统 + 渲染器分级适配（Forward+ / Mobile / Compatibility）+ 纹理采样性能审计实现跨平台视觉效果
+- 结论/价值：为 Godot 4 游戏提供创作性、正确性与性能意识三合一的着色器方案，核心交付物涵盖 2D 精灵描边、3D Dissolve 溶解、3D 水面、全屏后处理及着色器性能审计清单
 
 ## Key Claims（用中文描述）
-- Godot Shader Developer 通过 `shader_type` + GLSL-like 语法实现 2D CanvasItem 和 3D Spatial 着色器，在 Forward+ / Mobile / Compatibility 三种渲染器下提供差异化效果
+- Godot Shader Developer 通过 `shader_type` 声明（canvas_item / spatial / particles / sky）明确着色器上下文，使用 Godot 内置变量（TEXTURE / UV / COLOR / ALBEDO）而非原始 GLSL 等价物
 - VisualShader 编辑器适合艺术家快速迭代，代码着色器适合性能关键路径；两者互补而非替代
-- 所有 uniform 参数必须附带 hint（`hint_range`、`source_color`、`hint_normal` 等），否则 Inspector 无法正确显示
-- `SCREEN_TEXTURE` 采样会触发帧缓冲区复制，在移动端每帧 shader 中使用会严重影响性能
-- `discard` 在移动端不透明空间着色器中应替换为 Alpha Scissor，以保证性能合规
+- 所有 uniform 参数必须附带 hint（`hint_range` / `source_color` / `hint_normal` 等），否则 Inspector 无法正确显示颜色选择器和范围滑块
+- `SCREEN_TEXTURE` 采样会触发帧缓冲区复制，在移动端每帧 shader 中使用会严重影响性能，应有文档化性能理由
+- `discard` 在移动端不透明空间着色器中应替换为 Alpha Scissor，以保证性能合规；Compatibility 渲染器完全不支持 compute shader 和 `DEPTH_TEXTURE` canvas 采样
 
 ## Key Quotes
 > "MANDATORY: Godot's shading language is not raw GLSL — use Godot built-ins (TEXTURE, UV, COLOR, FRAGCOORD) not GLSL equivalents" — Godot 4 着色语言核心规范
@@ -27,24 +27,25 @@ date: 2026-04-26
 > "Use VisualShader for effects artists need to extend — use code shaders for performance-critical or complex logic" — 工具选型原则
 
 ## Key Concepts
-- [[CanvasItem Shader]]：Godot 2D/UI 着色器类型，使用 `shader_type canvas_item`，通过 `TEXTURE`、`UV`、`COLOR` 内置变量操作精灵和 UI 效果
-- [[Spatial Shader]]：Godot 3D 世界着色器类型，使用 `shader_type spatial`，通过 `ALBEDO`、`METALLIC`、`ROUGHNESS`、`NORMAL_MAP` 输出变量控制 PBR 材质
-- [[VisualShader]]：Godot 图形化着色器编辑器，将 GLSL 节点化，支持艺术家快速搭建材质变体；Group 和 Comment 节点用于组织复杂图
-- [[CompositorEffect]]：Godot 4 Forward+ 渲染器的全屏后处理扩展点，通过 GDScript `extends CompositorEffect` 实现自定义后处理 Pass
-- [[Forward+ Renderer]]：Godot 4 高端渲染器，支持 `DEPTH_TEXTURE`、`SCREEN_TEXTURE`、`NORMAL_ROUGHNESS_TEXTURE` 全部特性
-- [[Mobile Renderer]]：Godot 4 中端渲染器，避免 `discard` 使用，优先 Alpha Scissor；纹理采样预算严格
-- [[Compatibility Renderer]]：Godot 4 最广泛支持渲染器，无 compute shader、无 `DEPTH_TEXTURE` canvas 采样、无 HDR 纹理
+- [[CanvasItem Shader]]：Godot 2D/UI 着色器类型，使用 `shader_type canvas_item`，通过 `TEXTURE`、`UV`、`COLOR` 内置变量操作精灵和 UI 效果；不支持 `DEPTH_TEXTURE`
+- [[Spatial Shader]]：Godot 3D 世界着色器类型，使用 `shader_type spatial`，通过 `ALBEDO`、`METALLIC`、`ROUGHNESS`、`NORMAL_MAP` 输出变量控制 PBR 材质；这些是输出变量而非输入
+- [[VisualShader]]：Godot 图形化着色器编辑器，将 GLSL 节点化，支持艺术家快速搭建材质变体；Comment 节点用于组织复杂图；`uniform` 必须设置 hint
+- [[CompositorEffect]]：Godot 4 Forward+ 渲染器的全屏后处理扩展点，通过 GDScript `extends CompositorEffect` + RenderingDevice 实现自定义后处理 Pass
+- [[Forward+ Renderer]]：Godot 4 高端渲染器，全特性支持——`DEPTH_TEXTURE`、`SCREEN_TEXTURE`、`NORMAL_ROUGHNESS_TEXTURE`、compute shader
+- [[Mobile Renderer]]：Godot 4 中端渲染器，避免 `discard` 使用不透明空间着色器（优先 Alpha Scissor）；纹理采样预算严格（每片元 ≤ 6 次）
+- [[Compatibility Renderer]]：Godot 4 最广泛支持渲染器，无 compute shader、无 `DEPTH_TEXTURE` canvas 采样、无 HDR 纹理；限制最多
+- [[RenderingDevice]]：Godot 4 底层 GPU API，用于 dispatch compute shader（Forward+ 渲染器下）进行 GPU 侧纹理生成和数据处理
 
 ## Key Entities
-- [[Godot]]：Juan Linietsky 和 Ariel Manzur 主导的开源游戏引擎，Godot 4 引入了 Forward+ 渲染器和重构的着色语言
-- [[GLSL]]：OpenGL 着色语言，Godot 着色语言基于 GLSL 但有自己的内置变量和 API（`texture()` vs `texture2D()`）
+- [[Godot]]：Juan Linietsky 和 Ariel Manzur 主导的开源游戏引擎，Godot 4 引入了 Forward+ 渲染器和重构的着色语言（基于 GLSL 但有 Godot 特有内置变量）
+- [[GLSL]]：OpenGL 着色语言，Godot 着色语言基于 GLSL，但 `texture()` 函数签名与原始 GLSL `texture2D()` 不同（Godot 3 用 `texture2D()`，Godot 4 用 `texture()`）
 
 ## Connections
-- [[Godot Gameplay Scripter]] ← collaborates_with ← [[Godot Shader Developer]]（Godot 游戏中脚本与着色器协同开发）
-- [[Unity Shader Graph Artist]] ← compares_to ← [[Godot Shader Developer]]（两大主流游戏引擎的着色器方案对比）
+- [[Godot Gameplay Scripter]] ← collaborates_with ← [[Godot Shader Developer]]（Godot 游戏中脚本逻辑与视觉效果着色器协同开发，构成完整 Godot 4 游戏开发栈）
+- [[Unity Shader Graph Artist]] ← compares_to ← [[Godot Shader Developer]]（两大主流游戏引擎的着色器方案对比：Unity 用 Shader Graph，Godot 用 VisualShader + 代码着色器，均追求艺术友好与性能控制的平衡）
 - [[Technical Artist]] ← overlaps_with ← [[Godot Shader Developer]]（两者均涉及渲染技术与美术的桥梁工作）
-- [[Godot Shader Developer]] ← uses ← [[VisualShader]]（VisualShader 作为快速原型工具）
-- [[Godot Shader Developer]] ← targets ← [[Forward+ Renderer]] / [[Mobile Renderer]] / [[Compatibility Renderer]]（三种渲染器适配）
+- [[Godot Shader Developer]] ← uses ← [[VisualShader]]（VisualShader 作为快速原型工具，代码着色器用于性能关键路径）
+- [[Godot Shader Developer]] ← targets ← [[Forward+ Renderer]] / [[Mobile Renderer]] / [[Compatibility Renderer]]（三种渲染器分级适配）
 
 ## Contradictions
-- 无已知冲突内容。
+- 无已知冲突内容。该源页面与 [[Unity Shader Graph Artist]] 在着色器工具选型上仅有描述性差异（Graph vs Code），不存在事实性矛盾。
diff --git a/wiki/sources/government-digital-presales-consultant.md b/wiki/sources/government-digital-presales-consultant.md
index b8e4d3dd..fa883742 100644
--- a/wiki/sources/government-digital-presales-consultant.md
+++ b/wiki/sources/government-digital-presales-consultant.md
@@ -1,59 +1,65 @@
 ---
 title: "Government Digital Presales Consultant"
 type: source
-tags: [ToG, government-IT, presales, compliance, Xinchuang, Smart-City, Digital-Government]
-date: 2026-04-25
+tags: []
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/government-digital-presales-consultant.md]]
+- [[Agent/agency-agents/specialized/government-digital-presales-consultant.md]]
 
 ## Summary（用中文描述）
-- 核心主题：中国政府信息化（ToG）市场的全生命周期售前专家智能体，涵盖从政策解读、解决方案设计到招投标全程
-- 问题域：政府数字化转型市场的项目机会识别、标书撰写、合规要求（POC验证、等保/密评/信创）、干系人管理
-- 方法/机制：五步工作流（机会发现→需求调研→方案设计→投标执行→中标交接），配合政策解读、竞品分析、POC演示、合规矩阵等工具模板
-- 结论/价值：为技术团队提供进入数字政府、智慧城市、一网统管、城市大脑等主流方向的决策支持，核心目标是提高中标率（>40%）、零废标、售前到交付对齐（偏差<10%）
+- 核心主题：中国政府数字化转型市场（ToG，Touching Government）的售前全流程专家，帮助技术团队赢得政府信息化项目。
+- 问题域：政策解读与商机发现、解决方案设计、投标文件编制、POC 验证、合规要求（等保/密评/信创）、干系人管理。
+- 方法/机制：五步工作流（商机发现→需求调研→方案设计→投标执行→中标移交）+ 分层干系人沟通策略（决策层/业务层/技术层/采购层差异化沟通）。
+- 结论/价值：将技术价值转化为政府话语，精准对接政策信号与评分标准，以案例背书和合规设计建立竞争优势。
 
 ## Key Claims（用中文描述）
-- 售前专家通过政策语言解码（"鼓励探索"→"全面实施"）识别市场成熟度信号，在政策从"软性鼓励"转向"硬性要求"时入场
-- 政府系统通常要求等保三级，核心系统可能要求等保四级；等保评估需在系统上线前2-3个月完成整改
-- 信创替换不必一步到位，分阶段替代是被接受的
-- 技术方案应以业务场景驱动，而非技术架构驱动——客户关心"市民服务处理速度提升80%"而非"微服务架构"
-- 投标文件零容忍格式错误——资质缺失、格式偏差、响应偏移均属废标项
+- Government Digital Presales Consultant 通过政策解读和分层干系人管理，帮助技术团队在政府采购流程中做出最优决策。
+- 解决方案必须以业务场景驱动而非技术架构驱动——客户关注"市民服务处理速度提升 80%"而非"微服务架构"。
+- 等保 2.0（三级）、密评（国密 SM2/SM3/SM4）、信创适配（鲲鹏/飞腾/曙光/龙芯 + 麒麟/统信 + 达梦/人大金仓）是政府信息化项目的硬约束，不是加分项。
+- 投标文件必须零容忍格式错误——遗漏资质、格式错误、响应偏差直接导致废标。
+- POC 应聚焦差异化核心能力，控制范围防止无限免费延伸。
 
 ## Key Quotes
-> "Drive with business scenarios, not technical architecture — the client cares about '80% faster citizen service processing,' not 'microservices architecture.'" — 方案设计核心原则
-> "Dengbao, Miping, and Xinchuang are mandatory, not bonus points." — 合规基线
-> "Don't tell the bureau head we use Kubernetes. Tell them 'Our platform's elastic scaling ensures zero downtime during peak service hall hours.'" — 技术价值转换
-> "A good proposal goes through at least three rounds of refinement." — 方案迭代要求
+> "Don't tell the bureau head we use Kubernetes. Tell them 'Our platform's elastic scaling ensures zero downtime during peak service hall hours — City XX had zero outages during the post-holiday rush last year.'" — 技术价值转化原则：用政府听得懂的语言说话
+> "'Advancing standardization, regulation, and accessibility of government services' translates to three things: service item cataloging, process reengineering, and digitization — our solution covers all three." — 政策翻译：将政策语言落地为具体建设内容
+> "The competitor has more City Brain cases than we do, but data governance is their weak spot — we don't compete on dashboards; we hit them on data quality." — 竞争策略：找到对手弱点，打差异化
 
 ## Key Concepts
-- [[Dengbao-2.0]]：网络安全等级保护制度，政府系统通常要求三级，等保评估需在上线前2-3个月完成
-- [[Miping]]：商用密码应用安全性评估，涉及身份认证、数据传输、数据存储必须使用国密算法（SM2/SM3/SM4）
-- [[Xinchuang]]：信息技术应用创新，核心要素为国产CPU（鲲鹏/飞腾/海光/龙芯）+ 国产OS（统信UOS/麒麟）+ 国产数据库（达梦/人大金仓/ GaussDB）+ 国产中间件
-- [[ToG]]（Government）：面向政府的数字化转型市场，区别于ToB（企业）和ToC（消费者）
-- [[Smart-City]]：智慧城市，典型方向包括城市大脑/城市运行中心（IOC）、智慧交通、智慧社区、城市信息模型（CIM）
-- [[Digital-Government]]：数字政府，典型方向包括一体化政务服务平台、一网统管/一网通办、12345热线智能升级、政府数据中台
-- [[Yiwangtongban]]：一网统办，一网通管，一体化政务服务门户
-- [[POC]]：概念验证，通过精选场景展示差异化优势，控制范围并设定明确成功标准
+- [[DigitalGovernment]]：一体化政务服务平台、政务服务"一网通办"/"一网统管"、12345热线智能化升级、政府数据中台
+- [[SmartCity]]：城市大脑/城市运行中心（IOC）、智慧交通、智慧社区、城市信息模型（CIM）
+- [[Dengbao]]（等保）：网络安全等级保护 2.0，政府系统通常要求三级，核心系统可能要求四级；安全架构设计必须覆盖网络分区分域、身份认证、数据加密、日志审计、入侵检测
+- [[Miping]]（密评）：商用密码应用安全性评估，涉及身份认证、数据传输和数据存储的政府系统必须使用国密算法（SM2/SM3/SM4）；电子印章和CA证书须使用国密证书
+- [[Xinchuang]]（信创）：信息技术应用创新；核心要素为国产CPU（鲲鹏/飞腾/曙光/龙芯）、国产OS（统信UOS/麒麟）、国产数据库（达梦/人大金仓/高斯DB）、国产中间件（东方通/宝兰德）；信创适配须优先选择信创目录主流产品，建立兼容性测试矩阵
+- [[XinchuangAdaptationMatrix]]：信创适配矩阵（CPU/OS/数据库/中间件/办公软件各层的国产替代产品与兼容性测试优先级）
+- [[DengbaoComplianceMatrix]]：等保合规矩阵（安全通信、安全边界、安全计算、安全管理中心各域的控制要求和推荐措施）
+- [[GovernmentProcurementWorkflow]]：政府信息化项目全流程——需求调研→招标文件分析→技术方案编写→商务报价→投标文件组装→讲标/答疑
+- [[StakeholderMapping]]：政府项目干系人地图（决策层/业务层/技术层/采购层），分层沟通策略
+- [[OpportunityAssessment]]：商机评估矩阵（项目真实性/竞争力/客户关系/投入产出比/风险标识）
 
 ## Key Entities
-- [[Digital-China-Master-Plan]]：数字中国建设整体布局规划，国家级政策文件
-- [[National-Data-Administration]]：国家数据局，国家层面数据治理主管机构
-- [[Government-Cloud]]：政务云平台，政府信息化基础设施
-- [[City-Brain]]：城市大脑，城市级数据融合与智能决策平台
-- [[Kunpeng]]：鲲鹏，国产CPU代表
-- [[Phytium]]：飞腾，国产CPU代表
-- [[UnionTech-UOS]]：统信UOS，国产操作系统代表
-- [[DM-Database]]：达梦数据库，国产数据库代表
+- [[Yiwangtongban]]：政务服务"一网通办"门户，省/市级政务服务统一入口
+- [[Yiwangtonguan]]：城市管理"一网统管"平台，城市运行管理综合平台
+- [[CityBrain]]：城市大脑，城市多源数据汇聚 + 实时监测 + 智能决策的综合平台
+- [[ClassifiedProtectionLevel3]]：等保三级，政府信息系统通常要求的网络安全等级
+- [[GuomiAlgorithms]]：国密算法（SM2/SM3/SM4），商用密码国家标准
+- [[XinchuangCatalog]]：信创产品目录，列出国产CPU/OS/数据库/中间件等合规替代产品
 
 ## Connections
-- [[Government-Digital-Presales-Consultant]] ← extends ← [[Sales-Engineer]]（通用售前 → 政府垂直领域售前）
-- [[Government-Digital-Presales-Consultant]] ← depends_on ← [[Xinchuang]]（信创合规必须掌握）
-- [[Government-Digital-Presales-Consultant]] ← depends_on ← [[Dengbao-2.0]]（等保合规必须掌握）
-- [[Government-Digital-Presales-Consultant]] ← depends_on ← [[Miping]]（密码评估必须掌握）
-- [[Digital-Government]] ← solution_domain ← [[Government-Digital-Presales-Consultant]]（数字政府是主要方案方向之一）
-- [[Smart-City]] ← solution_domain ← [[Government-Digital-Presales-Consultant]]（智慧城市是主要方案方向之一）
+- [[sales-engineer]] ← depends_on ← [[government-digital-presales-consultant]]：政府数字化售前提供商机评估和解决方案设计，销售工程师在此基础上进行商务跟进
+- [[sales-proposal-strategist]] ← extends ← [[government-digital-presales-consultant]]：投标文件撰写由售前专家主导，提案策略师提供格式和说服力优化
+- [[specialized-salesforce-architect]] ← extends ← [[government-digital-presales-consultant]]：Salesforce 政务云平台定制方案的设计需要政府数字化售前的业务理解
+- [[compliance-auditor]] ← depends_on ← [[government-digital-presales-consultant]]：合规审计（等保/密评/信创）由合规审计师执行，售前在方案设计阶段已嵌入合规架构
 
 ## Contradictions
-- 无明显冲突。本文档专注于中国政府ToG市场，与Wiki中其他以企业级/B2B市场为中心的售前/销售Agent形成领域区隔。
+- 与 [[sales-discovery-coach]] 张力：
+  - 冲突点：Discovery Coach 强调"按岗位层级定制提问"，而政府数字化售前的需求调研更侧重政策合规和评分标准对齐
+  - 当前观点：政府售前需优先满足招标文件硬约束（资质/案例/信创），以通过资格预审为第一目标
+  - 对方观点：销售发现应以客户业务痛点为核心，通过深度提问建立信任后再推方案
+  - 协调方案：政府数字化场景下，招标文件的强制要求（等保证书、类似案例数量、信创认证）是入场券——先满足合规门槛，再通过需求调研深化业务理解
+- 与 [[sales-proposal-strategist]] 潜在张力：
+  - 冲突点：提案策略师偏好"故事化叙事 + 差异化定位"，而政府售前方案更强调模板规范和政治正确
+  - 当前观点：政府技术方案必须使用当前政策术语（数字中国、数据要素X等），架构图要符合政务云标准规范
+  - 对方观点：提案策略师认为过度模板化会削弱差异化竞争力
+  - 协调方案：技术响应部分遵循政府规范格式（技术要求逐条对应），商务展示部分融入叙事和差异化
diff --git a/wiki/sources/handoff-templates.md b/wiki/sources/handoff-templates.md
new file mode 100644
index 00000000..3a1e90c8
--- /dev/null
+++ b/wiki/sources/handoff-templates.md
@@ -0,0 +1,56 @@
+---
+title: "NEXUS Handoff Templates"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/coordination/handoff-templates.md]]
+
+## Summary（用中文描述）
+- 核心主题：NEXUS 多 Agent 协作框架的标准化交接模板体系——7 种场景化模板覆盖从任务分配、QA 通过/失败、升级、阶段门控、冲刺边界到事故响应的全链路交接
+- 问题域：多 Agent 协作中的上下文丢失（交接边界 73% 失败率）和 QA 反馈循环缺失问题
+- 方法/机制：7 个标准化 Markdown 模板 + 场景选择指南表格，每个模板包含 metadata/verdict/evidence/next-action 结构化字段
+- 结论/价值：一致性交接防止上下文丢失——多 Agent 协调失败的头号原因；与 NEXUS 质量门控（[[QualityGate]]）体系深度集成；是 NEXUS 战略框架三大交付物之一
+
+## Key Claims（用中文描述）
+- 标准化交接防止上下文丢失——多 Agent 协调失败的头号原因
+- QA Feedback Loop 强制执行最多 3 次重试，超出则触发 Escalation Report 升级至 [[AgentsOrchestrator]]
+- Phase Gate Handoff 为每个阶段转换建立门控标准和文档交接机制
+- Sprint Handoff 覆盖冲刺边界的所有完成状态、质量指标、待办项和回顾洞察
+- Incident Handoff 确保事故响应跨团队协作的可追溯性和上下文连续性
+- 7 个模板通过 Usage Guide 表格映射到具体场景，确保 Agent 始终使用正确模板
+
+## Key Quotes
+> "Consistent handoffs prevent context loss — the #1 cause of multi-agent coordination failure." — NEXUS Handoff Templates 文档引言
+
+## Key Concepts
+- [[Handoff-Boundary]]：交接边界——Agent 之间的上下文传递节点，NEXUS 发现 73% 的失败发生在此处，本文档通过 7 个标准化模板对此进行针对性解决
+- [[QualityGate]]：质量门控——本文档中 QA PASS/FAIL 模板是 QualityGate 在验收环节的具体执行机制；Phase Gate Handoff 则是阶段间的 QualityGate 实现
+- [[Agent-Handoff]]：Agent 交接——Agent-to-Agent 工作转移的标准格式，通过 Standard Handoff Template (#1) 实现结构化上下文传递
+- [[Dev-QA-Loop]]：开发↔QA 循环——QA PASS/FAIL 模板定义了该循环的标准状态转移（PASS → 推进 / FAIL → 最多重试 3 次 → Escalation）
+- [[Evidence-Over-Claims]]：证据优于主张——QA PASS 模板要求提供多分辨率截图、功能验证清单、品牌一致性/无障碍/性能数据作为决策依据
+- [[Sprint-Handoff]]：冲刺交接——Sprint 边界的知识传递模板，覆盖完成状态、质量指标、待办项和回顾洞察
+- [[Incident-Response]]：事故响应——Incident Handoff 模板为 P0-P3 事故建立标准化响应和交接流程
+
+## Key Entities
+- [[NEXUS]]：The Agency 多 Agent 编排框架，handoff-templates.md 为其三大战略交付物之一（与 Master Strategy/Phase Playbooks 并列）
+- [[AgentsOrchestrator]]：代理编排器——Escalation Report 的最终升级目标；Phase Gate Handoff 中的 Gate Keeper 决策者
+- [[EvidenceQA]]：证据收集者——QA PASS/FAIL 模板中的 QA Agent 角色之一，负责多分辨率截图和功能验证
+
+## Connections
+- [[executive-brief]] ← documents_in_detail ← [[handoff-templates]]
+- [[quickstart]] ← is_simplified_guide ← [[handoff-templates]]
+- [[nexus-strategy]] ← is_part_of ← [[NEXUS]]
+- [[handoff-templates]] ← enables ← [[Dev-QA-Loop]]
+- [[handoff-templates]] ← implements ← [[QualityGate]]
+- [[handoff-templates]] ← supports ← [[Sprint-Handoff]]
+- [[handoff-templates]] ← supports ← [[Incident-Response]]
+
+## Contradictions
+- 与 [[workflow-with-memory]] 的记忆机制对比：
+  - 冲突点：handoff-templates 依赖结构化文档传递上下文，而 [[workflow-with-memory]] 依赖 MCP 持久记忆服务
+  - 当前观点：标准化交接模板提供显式、可审计的上下文传递路径，适合跨平台协作
+  - 对方观点：MCP 记忆服务自动化上下文召回，减少手动文档工作，适合长期项目
+  - 协调方案：两者互补——handoff-templates 定义"交接什么"，memory 系统定义"如何持久化"，建议在 Phase 3 Build 开始引入 memory 机制
diff --git a/wiki/sources/healthcare-customer-service.md b/wiki/sources/healthcare-customer-service.md
new file mode 100644
index 00000000..816e24c1
--- /dev/null
+++ b/wiki/sources/healthcare-customer-service.md
@@ -0,0 +1,53 @@
+---
+title: "Healthcare Customer Service Agent"
+type: source
+tags: [healthcare, customer-service, agent, patient-support, HIPAA]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/healthcare-customer-service.md]]
+
+## Summary（用中文描述）
+- 核心主题：医疗保健客户服务 Agent 角色定义与操作规范，一个富有同理心的患者支持专员，处理预约、账单、保险、投诉及升级流程
+- 问题域：患者在医疗机构中面临的行政服务问题——预约管理、医疗账单、保险理赔、投诉处理、紧急响应
+- 方法/机制：基于五步工作流（患者识别与情感评估 → 理解需求 → 解决或转接 → 确认解决 → 记录与跟进），结合 LEAP 降级技术和 HIPAA 合规要求
+- 结论/价值：为医疗客服场景提供标准化、可量化的 Agent 行为规范，强调同理心优先、绝不提供临床建议、HIPAA 强制合规
+
+## Key Claims（用中文描述）
+- 医疗客服 Agent 必须在任何解决方案之前先承认患者的感受，否则无法建立信任
+- Agent 永远不得提供临床建议，所有临床问题必须立即转接给持牌临床人员
+- 身份验证（HIPAA）是讨论任何受保护健康信息（PHI）的前置条件，必须严格执行
+- 紧急情况识别必须 100% 准确，医疗紧急情况需立即指导患者拨打 911
+- 账单争议必须放置账单冻结（在审核期间），并在 3 个工作日内跟进患者
+
+## Key Quotes
+> "A patient isn't a ticket number — they're a person navigating one of the most stressful experiences of their life." — 核心服务理念
+> "Every interaction is an opportunity to restore trust and deliver care, even before they see a doctor." — 客服的价值定位
+> "Never provide clinical advice. You are not a clinician. Never diagnose, recommend treatments, interpret test results, or advise on medications." — 核心边界规则
+
+## Key Concepts
+- [[HIPAACompliance]]：健康保险流通与责任法案，要求最小必要原则收集信息、身份验证后方可讨论 PHI、永不重复敏感信息
+- [[EmpathyFirst]]：同理心优先原则，在任何政策、流程、解决方案之前必须先承认患者的人性需求
+- [[LEAPDeescalation]]：Listen, Empathize, Apologize, Partner — 降级技术四步法
+- [[EscalationProtocol]]：升级协议 — 立即（<2分钟）、紧急（同日）、标准（下一工作日）三级分类
+- [[PatientSupportWorkflow]]：五步患者支持工作流：识别与情感评估 → 理解需求 → 解决或转接 → 确认解决 → 记录与跟进
+
+## Key Entities
+- [[BillingSpecialist]]：账单专员 — 处理复杂账单争议、账单冻结、账单审核的专业人员
+- [[PatientAdvocate]]：患者权益倡导者 — 代表患者利益的专职人员，处理投诉和权益问题
+- [[ClinicalStaff]]：临床人员 — 持牌医疗专业人员（护士、医生），负责所有临床问题的路由目标
+- [[Supervisor]]：主管 — 处理需要即时升级的紧急投诉和法律威胁
+- [[RiskManagement]]：风险管理部门 — 处理法律诉讼或潜在诉讼相关的患者投诉
+
+## Connections
+- [[HealthcareMarketingCompliance]] ← extends ← [[HealthcareCustomerService]]（医疗营销合规专员与医疗客服Agent共享HIPAA合规基础）
+- [[HospitalityGuestServices]] ← analogous_to ← [[HealthcareCustomerService]]（酒店客服 Agent 与医疗客服 Agent 共享投诉处理框架和升级协议）
+- [[SupportResponder]] ← extends ← [[HealthcareCustomerService]]（通用客服响应 Agent 是医疗客服 Agent 的基础抽象层）
+
+## Contradictions
+- 与 [[LegalClientIntake]] 冲突：
+  - 冲突点：医疗场景与法律场景对"身份验证"的要求严格程度
+  - 当前观点：医疗场景要求全名 + 出生日期 + SSN 后四位（HIPAA 强制）
+  - 对方观点：法律场景可能只需姓名和案件编号即可开始问询
+  - 注：两者场景不同，冲突源于场景差异而非事实矛盾，可共存
diff --git a/wiki/sources/healthcare-marketing-compliance.md b/wiki/sources/healthcare-marketing-compliance.md
index 7b1c30d8..a6685169 100644
--- a/wiki/sources/healthcare-marketing-compliance.md
+++ b/wiki/sources/healthcare-marketing-compliance.md
@@ -2,68 +2,58 @@
 title: "Healthcare Marketing Compliance Specialist"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/healthcare-marketing-compliance.md]]
+- [[Agent/agency-agents/specialized/healthcare-marketing-compliance.md]]
 
 ## Summary（用中文描述）
-- 核心主题：医疗营销合规专家 Agent，覆盖中国医疗健康领域（药品/医疗器械/医美/保健食品/互联网医疗）全品类营销合规
-- 问题域：医疗健康企业在品牌推广、内容营销、学术推广中的合规边界；平台内容审核规则；患者隐私保护
-- 方法/机制：以《广告法》《医疗广告管理办法》《互联网广告管理办法》为核心监管框架，建立"三级审查机制"（法务初审→合规复审→终审发布）；风险分级矩阵（Critical/High/Medium/Low）；违规应急响应流程（2小时下架→24小时报告→72小时审计）
-- 结论/价值：合规不是"堵营销"，而是"保护品牌"——一次违规处罚的代价远高于合规投入
+- 核心主题：中国医疗健康营销合规全链路专家 Agent，覆盖药品、医疗器械、医美、保健食品、互联网医疗等细分领域的广告法规与合规运营
+- 问题域：医疗健康企业在品牌推广、内容营销、学术推广中如何既合法合规又最大化营销效果
+- 方法/机制：以《广告法》《医疗广告管理办法》《互联网广告管理办法》等法规为核心依据，构建三级审核机制（法务初审→合规复审→最终审批），结合抖音/小红书/微信等平台内容审核规则，提供发布前合规审查与违规应急响应
+- 结论/价值：合规不是"阻断营销"，而是"保护品牌"——一次违规处罚的代价远高于合规投入
 
 ## Key Claims（用中文描述）
-- 医疗广告必须经省级卫生行政部门审查并取得《医疗广告审查证明》，否则不得发布——这是行政出发乃至刑事追责的底线
-- 处方药严禁在大众媒体（电视/广播/报纸/互联网）发布广告——任何隐性推广均面临严厉处罚
-- 保健食品不得声称具有治疗功能——这是行业内处罚最高频的违规原因
-- 医美广告不得制造"容貌焦虑"——2021年起市场监管总局执法力度显著加强
-- 患者健康数据属于《个人信息保护法》认定的"敏感个人信息"——违规最高罚款5000万元或上年度营收5%
+- 医疗广告必须经过审查方可发布，未经审查擅自发布将面临行政处罚甚至刑事追责
+- 处方药严禁在大众媒体（电视/广播/报刊/互联网）做广告，仅可在医药专业期刊发布
+- 保健食品不得声称治疗功能，不得使用"疗效""治愈""保证康复"等医疗术语
 
 ## Key Quotes
-> "医疗广告必须审查后方可发布——这是行政处罚乃至刑事追责的底线。" — 广告法第46条核心要求
-> "保健食品不得声称治病功能，必须标注'保健食品不是药物，不能替代药物治疗疾病'。" — 蓝帽子标识管理制度核心声明
-> "合规不是'堵营销'，而是'保护品牌'。一次违规处罚的代价远高于合规投入。" — Agent 核心合规文化理念
-> "医美日记类内容无论是否由用户'自愿'分享，平台和诊所均可被追究连带责任。" — 小红书医美合规红线
+> "合规不是'阻断营销'，而是'保护品牌'。一次违规处罚的代价远高于合规投入。" — 医疗营销合规核心原则
+> "保健食品不是药品，不得声称治疗疾病——这是行业被处罚最频繁的原因。" — 保健食品合规红线
+> "医美广告不得制造'容貌焦虑'，2021年以来执法力度显著加强。" — 医美广告监管趋势
 
 ## Key Concepts
-- [[Healthcare-Marketing-Compliance]]：医疗健康营销全品类（药品/器械/医美/保健食品/互联网医疗）合规框架
-- [[Medical-Advertisement-Review]]：《医疗广告审查证明》制度——广告发布前必须获得省级卫生行政部门审查
-- [[Three-Tier-Review-Mechanism]]：企业内部三级审查机制（法务初审→合规复审→终审发布）
-- [[OTC-Drug-Marketing]]：非处方药大众媒体广告规则——必须包含"请按照药品说明书或药师指导下使用"等咨询语句
-- [[Prescription-Drug-Restrictions]]：处方药大众媒体广告禁令——仅限在医药专业期刊发布
-- [[Medical-Device-Classification]]：医疗器械三类分级管理制度（I类备案/II类注册/III类严格审批）
-- [[Blue-Hat-Logo]]：保健食品"蓝帽子"注册标志——合法保健食品必须取得并展示
-- [[Appearance-Anxiety]]：容貌焦虑——医美广告2021年起明确禁止制造焦虑情绪的表述
-- [[Internet-Diagnosis-Treatment]]：互联网诊疗规范——初诊必须线下面诊，复诊限常见病/慢性病
-- [[Patient-Privacy-PIPL]]：《个人信息保护法》将个人健康医疗信息认定为敏感信息，须单独授权
-- [[Academic-Detailing]]：学术推广合规——医疗代表备案、会议赞助标准、医师讲课费规范
-- [[Platform-Content-Review]]：平台内容审核机制——抖音/小红书/微信各有行业准入标准和内容红线
-- [[Compliance-Risk-Matrix]]：医疗营销合规风险分级矩阵（Critical/High/Medium/Low + 处置建议）
+- [[医疗广告审查证明]]：医疗广告必须经省级卫生行政部门审查并取得，是行政罚款和刑事追责的基准线
+- [[处方药广告禁令]]：处方药严禁在大众媒体发布广告，是药品营销合规的核心红线
+- [[保健食品功能声称范围]]：仅可在注册/备案的24项保健功能范围内声称，超出即为违规
+- [[医疗器械分类管理]]：一类（低风险，备案管理）、二类（中风险，注册证）、三类（高风险，最严格监管）
+- [[互联网诊疗红线]]：初诊必须线下面诊，复诊限于常见病和慢性病
+- [[患者隐私敏感信息]]：医疗健康信息属于敏感个人信息，《个人信息保护法》处理需单独同意
+- [[医美广告容貌焦虑禁令]]：不得使用"丑""不好看""影响社交/就业"等暗示性语言
+- [[学术推广合规]]：药企学术会议赞助需明确内容与金额，不得影响学术独立性；医药代表不得有销售指标
 
 ## Key Entities
-- [[NMPA]]（国家药品监督管理局）：负责药品/医疗器械注册审批及广告批准文号管理
-- [[SAMR]]（国家市场监督管理总局）：2021年发布《医疗美容广告执法指南》，主导医美合规整治
-- [[Haodf]]（好大夫在线）：互联网医疗平台——医师入驻资质审核、患者评价管理、图文/视频问诊标准
-- [[DXY]]（丁香园）：医师专业社区——健康科普内容专业审核机制、医师认证体系、商业合作与编辑独立性分离
-- [[WeDoctor]]（微医）：互联网医院牌照、在线处方流转、医保接入合规
-- [[JD-Health]]（京东健康）：在线售药资质、处方药审核流程、物流配送合规
-- [[Douyin]]（抖音）：医疗行业准入（须提交医疗机构执业许可证或药械资质）、认证医师标识、直播带货限制
-- [[Xiaohongshu]]（小红书）：2021年起大规模清理医美内容、白名单管理制度、蒲公英品牌合作平台合规要求
-- [[WeChat]]（视频号）：医疗机构公众号认证、朋友圈广告投放规范、小程序在线问诊/售药资质要求
+- [[国家药品监督管理局（NMPA）]]：药品/医疗器械注册审批及广告批准号颁发机构
+- [[国家市场监督管理总局（SAMR）]]：2021年发布《医疗美容广告执法指南》，主导医美广告监管
+- [[国家卫生健康委员会]]：医疗广告审查证明颁发机构
+- [[抖音（Douyin）]]：医疗行业需提交医疗机构执业许可证或药品/器械资质进行行业认证；直播中不得推荐具体药品或治疗方案
+- [[小红书（Xiaohongshu）]]：2021年起大规模清理医美内容，医疗内容现实行白名单管理
+- [[好大夫在线（Haodf）]]：医生入驻资质审核、患者评价管理、图文/视频问诊标准
+- [[丁香园（DXY）]]：健康科普内容专业审核机制、医生认证体系、商业合作与编辑独立性分离
+- [[平安好医生/阿里健康]]：在线售药资质、处方药审核流程、物流配送合规
 
 ## Connections
-- [[Healthcare-Marketing-Compliance]] ← extends ← [[The-Agency]]（Specialized 部门）
-- [[Healthcare-Marketing-Compliance]] ← depends_on ← [[NMPA]]（监管机构）
-- [[Healthcare-Marketing-Compliance]] ← depends_on ← [[SAMR]]（执法机构）
-- [[Platform-Content-Review]] ← extends ← [[Healthcare-Marketing-Compliance]]
-- [[Patient-Privacy-PIPL]] ← depends_on ← [[Healthcare-Marketing-Compliance]]
-- [[Academic-Detailing]] ← extends ← [[Healthcare-Marketing-Compliance]]
+- [[Healthcare-Customer-Service]] ← 延伸 ← [[Healthcare-Marketing-Compliance]]：合规营销为客服提供合规话术基础
+- [[Compliance-Auditor]] ← 依赖 ← [[Healthcare-Marketing-Compliance]]：合规审计需要营销合规标准作为检查基准
+- [[Marketing-Content-Creator]] ← 受约束 ← [[Healthcare-Marketing-Compliance]]：内容创作必须遵循医疗广告禁用语和审核要求
+- [[Healthcare-Marketing-Compliance]] ← 依赖 ← [[Personal-Information-Protection-Law]]：患者健康数据合规处理是营销内容的数据隐私底线
+- [[Multi-Agent-System-Reliability]] ← 支撑 ← [[Healthcare-Marketing-Compliance]]：合规专家 Agent 是企业级 Agent 系统可靠运营的必要组成部分
 
 ## Contradictions
-- 与 [[legal-compliance-checker]] 潜在冲突：
-  - 冲突点：通用法律合规 Agent 与医疗专项合规 Agent 的职责边界
-  - 当前观点：医疗营销合规具有高度专业化特征（广告法/药械注册/平台规则），通用法律合规工具无法覆盖
-  - 对方观点：合规 Agent 应具备跨行业通用合规框架，无需细分至医疗领域
-  - 解决方向：通用合规 Agent 负责数据隐私/合同合规等横向能力，医疗营销合规 Agent 专注垂直领域规则差异
+- 与 [[Marketing-Content-Creator]] 的内容创作灵活性需求：
+  - 冲突点：营销追求吸引力和转化率，合规要求严谨和克制
+  - 当前观点：合规优先，内容必须在法律边界内创作，通过场景化叙事和视觉设计提升表现力
+  - 对方观点：内容创作追求最大创意空间，希望突破保守表达方式
+  - 协调方案：合规制定禁用语清单和风险评级，内容创作在清单范围内最大化创意空间；高风险内容走合规审核流程
diff --git a/wiki/sources/hospitality-guest-services.md b/wiki/sources/hospitality-guest-services.md
new file mode 100644
index 00000000..a47929fd
--- /dev/null
+++ b/wiki/sources/hospitality-guest-services.md
@@ -0,0 +1,53 @@
+---
+title: "Hospitality Guest Services"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/hospitality-guest-services.md]]
+
+## Summary（用中文描述）
+- 核心主题：酒店及综合款待业（酒店/度假村/餐厅/活动场地）的宾客服务专家 AI Agent，涵盖从预订、入住、住店、投诉处理、离店到售后全流程
+- 问题域：如何通过结构化的 Agent Prompt 让 AI 在酒店前台、礼宾、客服等场景中提供始终如一的高质量宾客体验，同时驱动忠诚度和营收增长
+- 方法/机制：定义 Agent 身份（记忆系统）→ 10条黄金规则 → 五段式工作流（预订/入住/住店/退房/售后）→ 技术交付物模板（预订确认函、HEARD 投诉处理、SERVICE RECOVERY、忠诚计划管理等）
+- 结论/价值：宾客服务不是交易而是情感连接；在线评价能直接影响营收（评分每升1分可带动营收增长9%）；每次投诉都是修复和留存的机会
+
+## Key Claims（用中文描述）
+- 宾客服务不是交易——而是一种情感体验，每一次宾客互动都是创造回忆、赢得回头客和生成五星好评的机会
+- 一条投诉就是一份礼物——愿意投诉的宾客说明仍相信你能补救，不投诉直接离开的宾客永远流失
+- 服务恢复必须即时且真诚——对宾客投诉的延迟响应会将负面影响翻倍，应在发现服务失误的那一刻立即处理
+- 忠诚会员必须被认可——每次入住都要在办理入住手续时承认其忠诚身份和等级
+- 食物过敏和饮食限制是不可妥协的——每笔餐饮预订必须记录饮食限制，每位餐饮团队成员必须在服务前收到通知
+- 在线评价塑造营收——酒店评分每提高1分，营收可增加高达9%
+
+## Key Quotes
+> "The best hotels don't just give guests a room — they give them an experience. The best restaurants don't just serve food — they create moments." — 核心服务理念
+
+> "A guest who complains is a guest who still believes you can make it right. A guest who leaves without complaining — and never comes back — is lost forever." — 投诉即礼物
+
+> "Every complaint is a gift." — 服务恢复哲学
+
+## Key Concepts
+- [[HEARD Method]]：投诉处理五步法——H（完整倾听）、E（真诚共情）、A（诚挚道歉）、R（即时解决）、D（超越期望的补偿）
+- [[Guest Journey]]：宾客旅程全流程——预订（Reservations）→ 预到（Pre-Arrival）→ 入住（Check-In）→ 住店（In-Stay）→ 投诉处理（Complaint Resolution）→ 退房（Check-Out）→ 售后（Post-Stay）→ 活动与团队（Events & Groups）
+- [[Service Recovery Protocol]]：服务恢复协议——标准化投诉处理流程，包含立即行动、分级补偿方案（绿/黄/红/紧急四级）和跟进承诺
+- [[Loyalty Program Management]]：忠诚计划管理——会员注册、等级认可、积分追踪、投诉升级的完整生命周期管理
+- [[Concierge Services]]：礼宾服务——餐厅预订、交通安排、本地活动、场内服务（spa/健身/客房服务）的综合服务能力要求
+- [[Review Management]]：评价管理——退房体验、口碑请求、差评响应模板及24小时响应规则
+
+## Key Entities
+- [[Hotel Property]]：酒店物业——服务交付的物理场所，提供客房、餐饮、活动场地等综合服务
+- [[OTA (Online Travel Agency)]]：在线旅游代理商——Expedia、Booking.com 等平台，评价响应策略需要兼顾其规则
+- [[Food Allergy]]：食物过敏——不可妥协的医疗安全问题，宾客餐饮预订必须强制记录
+- [[VIP Guest]]：重要宾客——特殊入住体验、高管迎接、个性化安排的重点服务对象
+
+## Connections
+- [[Hospitality Guest Services]] ← supports ← [[Hotel Property Operations]]
+- [[HEARD Method]] ← core framework ← [[Service Recovery Protocol]]
+- [[Loyalty Program Management]] ← drives ← [[Guest Journey]]
+- [[Review Management]] ← impacts ← [[OTA Rankings]]
+
+## Contradictions
+- （无已知冲突）
diff --git a/wiki/sources/hr-onboarding.md b/wiki/sources/hr-onboarding.md
new file mode 100644
index 00000000..d612fb04
--- /dev/null
+++ b/wiki/sources/hr-onboarding.md
@@ -0,0 +1,54 @@
+---
+title: "HR Onboarding Agent"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/hr-onboarding.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency 企业级新员工入职管理专家 Agent，覆盖从入职前准备到第一年结束的完整员工入职生命周期
+- 问题域：企业人力资源入职流程标准化、合规管理、福利登记、团队融入和90天绩效基础建立
+- 方法/机制：五阶段工作流（预入职→入职第一天→第一周整合→30-60-90天里程碑→转入稳态）+ 十项关键行为规则 + 量化成功指标体系
+- 结论/价值：入职体验质量直接决定员工90天留存率和长期生产力贡献；管理者关系是比薪酬更关键的留任驱动因素；入职不是行政文书工作，而是员工职业故事的第一章
+
+## Key Claims（用中文描述）
+- 入职前90天的表现直接决定新员工是成为长期贡献者还是遗憾离职——入职体验质量是员工留存率和生产力的最强预测因子
+- I-9验证、W-4表格和合规政策确认必须在法律规定的时限内完成——合规截止日期的疏忽将对公司和员工都造成严重法律后果
+- 管理者关系是员工留任最关键的驱动因素，研究表明其影响超过任何其他因素——管理者支持度直接决定新员工90天融入质量
+- 福利登记窗口是硬性截止日期，大多数福利要求在入职30天内完成登记——错过截止日期可能导致员工整个年度无法享受福利保障
+- 主动定期检查比被动等待问题出现效果更好——新员工在前90天不太可能主动表达担忧，结构化的签到机制能建立心理安全感
+- 入职第一天的混乱或组织无序会向新员工传递公司管理水平的负面信号——专业细致的入职流程反映企业文化品质
+- 文档必须完整且可接受审计——每份表格、确认书和合规记录都必须妥善存储以备查询，档案不完整会构成法律风险
+
+## Key Quotes
+> "Onboarding isn't paperwork — it's the first chapter of an employee's story with your company. Write it well, and they'll stay to write the rest. Write it poorly, and they'll be gone before the story gets good." — HR Onboarding Agent 核心理念
+> "The first 90 days determine whether a new hire becomes a long-term contributor or a regrettable turnover. Get it right from day one." — 入职体验重要性定位
+
+## Key Concepts
+- [[30-60-90-Day-Plan]]：新员工入职前三个月的阶梯式发展框架——Day 1-30 Learn（学习与融入）、Day 31-60 Contribute（独立贡献）、Day 61-90 Accelerate（加速影响），每个阶段设定明确目标、成功标志和管理者检查节奏
+- [[Pre-Boarding]]：入职前准备阶段——在正式入职前完成的IT设备配置、系统账户开通、欢迎邮件发送和经理入职指南传递，为入职第一天做好充分准备
+- [[Day-One-Orientation]]：入职第一天标准日程模板——从上午9:00欢迎致辞到下午4:30入职总结，涵盖合规文书、IT配置、团队介绍和Buddy制度
+- [[Psychological-Safety]]：心理安全感——在入职环境中创造让新员工敢于提问、不怕犯错的安全氛围，是主动沟通和早期问题浮出水面的前提条件
+- [[Buddy-System]]：Buddy制度——为每位新员工在入职前指派一位团队成员作为非正式的问答资源和职场向导，在入职第一天引介并持续支持前30天
+
+## Key Entities
+- [[The-Agency]]：The Agency 企业——HR Onboarding Agent 所属组织，为各行业提供147个专业 Agent，HR Onboarding Agent 属于 Specialized 部门，专注于企业级人力资源入职管理
+- [[Workday]]：企业HRIS系统——HR Onboarding Agent 的技术栈之一，用于入职工作流自动化、文档管理、福利登记和报告分析（仅在本页提及1次，已在 Key Entities 中引用）
+- [[BambooHR]]： SMB人力资源管理系统——HR Onboarding Agent 推荐的入门级HRIS选项，支持新员工数据包、电子签名和PTO追踪（仅在本页提及1次）
+- [[Rippling]]：一体化HR平台——HR Onboarding Agent 推荐的全功能平台，支持自动化配置、合规培训和设备管理（仅在本页提及1次）
+
+## Connections
+- [[recruitment-specialist]] ← handoff ← HR Onboarding Agent：新员工从招聘流程进入入职流程，招聘专员需提前通知入职日期、角色详情和经理信息
+- [[support-legal-compliance-checker]] ← depends_on ← HR Onboarding Agent：入职合规培训框架依赖法律合规专家定义的多司法管辖区合规标准
+- [[customer-service]] ← extends ← HR Onboarding Agent：入职后的客户服务团队（支持部门）延续入职期间建立的第一印象
+- [[ComplianceTraining]] ← shared_concept ← HR Onboarding Agent：合规培训体系（入职合规）与法律合规专家的合规培训体系（监管合规）共享同一核心概念
+
+## Contradictions
+- 与 [[compliance-auditor]] 的合规视角差异：
+  - 冲突点：HR Onboarding Agent 将 I-9 验证和合规培训视为入职门槛（必须100%按时完成），而法律合规专家的合规框架更侧重持续合规文化
+  - 当前观点（HR Onboarding）：合规是入职第一天完成的硬性法律要求，不完成则员工无法合法工作
+  - 对方观点（Compliance Auditor）：合规培训应与实际工作场景结合，而非一次性强制完成
+  - 协调方案：两者互补而非矛盾——入职合规（文书+培训）是底线，法律合规文化是入职后持续深化的长期过程
diff --git a/wiki/sources/i18n-readme.md b/wiki/sources/i18n-readme.md
new file mode 100644
index 00000000..7e7c4607
--- /dev/null
+++ b/wiki/sources/i18n-readme.md
@@ -0,0 +1,43 @@
+---
+title: "Chinese (zh-CN) Localization"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/scripts/i18n/README.md]]
+
+## Summary（用中文描述）
+- 核心主题：将 GitHub Copilot Agent 的 name 和 description 字段本地化为简体中文
+- 问题域：AI Agent 在 Copilot Chat Agent 选择器中的中文用户本地化体验
+- 方法/机制：通过 PowerShell 脚本读取 JSON 翻译映射表，自动替换 YAML frontmatter 中的 name/description 字段
+- 结论/价值：实现 Agent 界面的中文本地化，提升中文用户的使用体验；JSON 文件作为翻译的唯一数据源
+
+## Key Claims（用中文描述）
+- PowerShell 脚本 `localize-agents-zh.ps1` 读取 UTF-8 编码的 `agent-names-zh.json` 翻译映射表
+- 脚本仅修改已安装副本（`~/.github/agents/` 和 `~/.copilot/agents/`），不修改源文件
+- 仅替换 YAML frontmatter 中的 `name:` 和 `description:` 字段
+- JSON 文件是翻译的唯一真实来源，新增 Agent 需先添加到 JSON 中
+- 脚本采用纯 ASCII 编码（避免 PowerShell 编码问题），所有中文文本存储在 JSON 文件中
+- 每次运行 `install.sh --tool copilot` 更新后需重新运行本地化脚本
+
+## Key Quotes
+> "Only modifies **installed copies** (in `~/.github/agents/`), not source files" — 关键约束：只修改安装副本
+> "JSON file is the single source of truth for translations — add new agents there" — JSON 文件作为翻译唯一数据源的设计原则
+> "Script is pure ASCII (avoids PowerShell encoding issues); all Chinese text lives in the JSON" — 纯 ASCII 脚本 + UTF-8 JSON 的分工设计
+
+## Key Concepts
+- [[Global-First-Architecture]]：国际化/本地化（i18n/l10n）作为产品架构的先天前提条件，而非上线后的补救措施
+- [[YAML-Configuration]]：YAML frontmatter 配置格式，存储 Agent 的 name 和 description 元数据
+
+## Key Entities
+- [[The-Agency]]：开源多 Agent 框架，提供了 Copilot Agent 的安装脚本 `install.sh --tool copilot`
+- [[GitHub-Copilot]]：微软的 AI 编程助手，其 Chat 支持自定义 Agent，Agent 以 Markdown + YAML frontmatter 格式定义
+
+## Connections
+- [[Qwen Code Integration]] ← related_to ← [[i18n-readme]]（均为 Agency Agents 的多工具集成功能）
+- [[i18n-readme]] ← extends ← [[GitHub-Copilot]]（将英文 Copilot Agent 本地化为中文）
+
+## Contradictions
+- 无明显冲突
diff --git a/wiki/sources/identity-graph-operator.md b/wiki/sources/identity-graph-operator.md
index 46f52d2e..69d8d7a1 100644
--- a/wiki/sources/identity-graph-operator.md
+++ b/wiki/sources/identity-graph-operator.md
@@ -2,22 +2,22 @@
 title: "Identity Graph Operator"
 type: source
 tags: ["multi-agent", "identity-resolution", "entity-resolution", "the-agency"]
-date: 2026-04-24
+date: 2026-04-26
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/specialized/identity-graph-operator.md]]
 
 ## Summary（用中文描述）
-- 核心主题：多智能体系统中的共享身份图谱运营——确保所有 Agent 对同一真实世界实体（人/公司/产品）得到一致的规范化实体 ID，解决多 Agent 系统的核心问题：重复记录、冲突操作、级联错误。
-- 问题域：多 Agent 系统中的身份孤岛问题——当多个 Agent 独立处理同一实体时，缺乏共享身份层导致账单 Agent 重复收费、发货 Agent 发送两个包裹、支持 Agent 创建重复客户记录。
-- 方法/机制：通过身份解析引擎（Identity Engine）进行规范化（Normalization）→ 阻塞（Blocking）→ 评分（Scoring）→ 聚类（Clustering），返回相同 entity_id；支持昵称扩展（Bill→William）、E.164 电话标准化、邮箱小写化；merge/split 操作通过乐观锁执行，保留完整事件历史；直接变更 vs 提案决策按置信度分级处理。
-- 结论/价值：零身份冲突生产环境、合并准确率 > 99%、P99 解析延迟 < 100ms、全链路审计追踪。与 [[Multi-Agent-System-Reliability]] 的 Agent 协作模式互补——后者解决 Agent 间决策一致性问题，前者解决 Agent 对同一实体的识别一致性问题。
+- 核心主题：多智能体系统中的共享身份图谱运营——确保所有 Agent 对同一真实世界实体（人/公司/产品/交易记录）得到一致的规范化 entity_id，解决多 Agent 系统的核心问题：重复记录、冲突操作、级联错误。
+- 问题域：多 Agent 系统中的身份孤岛问题——当多个 Agent 独立处理同一实体时，缺乏共享身份层导致账单 Agent 重复收费、发货 Agent 发送两个包裹、支持 Agent 创建重复客户记录。没有共享身份解析，就会产生重复、冲突和级联错误。
+- 方法/机制：通过身份解析引擎（Identity Engine）进行规范化（Normalization）→ 阻塞（Blocking）→ 评分（Scoring）→ 聚类（Clustering），返回相同 entity_id；支持昵称扩展（Bill→William）、E.164 电话标准化、邮箱小写化；merge/split 操作通过乐观锁（optimistic locking）执行，保留完整事件历史（entity.created/merged/split/updated）；直接变更 vs 提案决策按置信度分级处理；支持实时路径（<100ms P99）和批量路径（百万级图谱聚类）混合解析。
+- 结论/价值：零身份冲突生产环境、合并准确率 > 99%、P99 解析延迟 < 100ms、全链路审计追踪。跨编排框架（LangChain/CrewAI/AutoGen/Semantic Kernel）身份联邦，跨 Agent 共享记忆。
 
 ## Key Claims（用中文描述）
-- **相同输入，相同输出**：两个 Agent 解析同一条记录必须得到相同 entity_id，这是绝对原则，不可妥协。
+- **相同输入，相同输出**：两个 Agent 解析同一条记录必须得到相同 entity_id，绝对原则，不可妥协。
 - **证据优先于断言**：合并必须有字段级证据支撑（email exact match + name fuzzy match + phone match），仅凭"看起来相似"不足以触发合并。
-- **提案优于直接变更**：与其他 Agent 协作时，优先提出带证据的合并提案，而非直接执行，让对方 Agent 审查证据。
+- **提案优于直接变更**：与其他 Agent 协作时，优先提出带证据的合并提案（per-field evidence），而非直接执行，让对方 Agent 审查证据。
 - **外部 ID 排序**：使用 external_id 排序而非 UUID（UUID 无序），确保排序稳定性。
 - **从不跳过引擎**：不硬编码字段名、权重或阈值，由匹配引擎统一计算候选评分。
 
@@ -25,6 +25,7 @@ date: 2026-04-24
 > "Same input, same output. Two agents resolving the same record must get the same entity_id. Always." — Determinism 原则核心表述
 > "Never merge without evidence. 'These look similar' is not evidence. Per-field comparison scores with confidence thresholds are evidence." — Evidence Over Assertion 原则
 > "When agents disagree — one proposes merge, another proposes split on the same entities — both proposals are flagged as 'conflict.' Add comments to discuss before resolving. Never resolve a conflict by overriding another agent's evidence." — 冲突处理机制
+> "The moment two agents can encounter the same entity from different sources, you need shared identity resolution. Without it, you get duplicates, conflicts, and cascading errors." — 何时需要 Identity Graph Operator
 
 ## Key Concepts
 - [[Identity Resolution（身份解析）]]：将多条记录归一化为同一 canonical entity_id 的过程——通过 blocking/scoring/clustering 实现，与传统主数据管理（MDM）同源但在多 Agent 场景下增加了并发写入和分布式协调维度。
@@ -33,7 +34,7 @@ date: 2026-04-24
 - [[Confidence Score（置信度评分）]]：字段级证据分数加权求和得出的合并置信度——决定直接合并（>0.95）、提案审查（0.6-0.95）还是创建新实体（<0.6），是自动决策与人机协作的分界点。
 - [[Optimistic Locking（乐观锁）]]：通过版本号（version field）防止并发写入冲突——变更需携带 expected_version，版本不匹配时拒绝执行，是图谱完整性的并发保护机制。
 - [[Evidence-based Merge Proposal（证据驱动合并提案）]]：合并前必须构造 per-field evidence（email_match/score/values、name_match/score/values），让其他 Agent 基于证据而非断言进行审查，是多 Agent 身份协调的核心协议。
-- [[Multi-Agent Identity Coordination（多 Agent 身份协调）]]：跨 Agent 的 merge/split 冲突检测、跨编排框架（LangChain/CrewAI/AutoGen）的身份联邦，以及 shared agent memory（跨 Agent 知识共享）——是 Identity Graph Operator 与 [[Multi-Agent-System-Reliability]] 的本质区别。
+- [[Multi-Agent Identity Coordination（多 Agent 身份协调）]]：跨 Agent 的 merge/split 冲突检测、跨编排框架的身份联邦、以及 shared agent memory（跨 Agent 知识共享）——是 Identity Graph Operator 的核心差异化能力。
 
 ## Key Entities
 - [[Identity Graph Operator]]：身份图谱运营者 Agent——本文档描述的核心 Agent，拥有共享身份层的所有权，负责多 Agent 系统的实体解析、合并提案和冲突协调。
diff --git a/wiki/sources/integrations-kimi-code-cli.md b/wiki/sources/integrations-kimi-code-cli.md
new file mode 100644
index 00000000..7a1dc35d
--- /dev/null
+++ b/wiki/sources/integrations-kimi-code-cli.md
@@ -0,0 +1,40 @@
+---
+title: "Kimi Code CLI Integration"
+type: source
+tags: []
+date: 2026-05-09
+---
+
+## Source File
+- [[Agent/agency-agents/integrations/kimi/README.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Agent roster 与 Kimi Code CLI 的集成方案
+- 问题域：如何将 YAML 格式的 Agent 规范文件安装到本地 Kimi Code CLI 环境
+- 方法/机制：通过 `convert.sh` 将 .md Agent 定义转换为 `agent.yaml` + `system.md` 结构，再通过 `install.sh` 安装到 `~/.config/kimi/agents/`
+- 结论/价值：提供与 Kimi Code CLI 的零门槛集成，支持在项目中通过 `--agent-file` 和 `--work-dir` 指定特定 Agent 开展工作
+
+## Key Claims（用中文描述）
+- The Agency 通过 `agent.yaml` + `system.md` 双文件结构将任意 Agent 转换为 Kimi Code CLI 可加载的规范
+- `convert.sh --tool kimi` 生成中间文件，`install.sh --tool kimi` 部署到 `~/.config/kimi/agents/`
+- 安装后通过 `--agent-file` 路径激活指定 Agent，支持 `--work-dir` 指定项目工作目录
+
+## Key Quotes
+> "Converts all Agency agents into Kimi Code CLI agent specifications. Each agent becomes a directory containing `agent.yaml` (agent spec) and `system.md` (system prompt)." — 文档开篇定义
+> "Kimi CLI not detected — Make sure `kimi` is in your PATH" — 故障排除指导
+
+## Key Concepts
+- [[AgentIntegration]]：The Agency 通过标准化脚本将 Agent roster 转换为各目标工具格式的集成机制
+- [[AgentScopes]]：Kimi Code CLI 集成属于 Home-Scoped 作用域（`~/.config/kimi/agents/`）
+
+## Key Entities
+- [[The-Agency]]：提供 Agent roster 的开源多 Agent 框架项目
+- [[Kimi]]：Moonshot AI 推出的命令行 AI 编程助手
+
+## Connections
+- [[Claude-Code]] ← similar_approach ← [[integrations-kimi-code-cli]]
+- [[OpenCode]] ← similar_approach ← [[integrations-kimi-code-cli]]
+- [[integrations-readme]] ← belongs_to ← [[The-Agency]]
+
+## Contradictions
+- 无冲突（Kimi Code CLI 集成与 Claude Code/OpenCode/OpenClaw 等其他集成路径互为补充，各自在不同工具中实现 Agent 复用）
diff --git a/wiki/sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md b/wiki/sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md
new file mode 100644
index 00000000..34f45c62
--- /dev/null
+++ b/wiki/sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md
@@ -0,0 +1,56 @@
+---
+title: "Karpathy 最新分享：用 LLM 搭建个人知识库，告别 RAG 的低效循环"
+type: source
+tags: [AI, knowledge-base, LLM, Obsidian, RAG]
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/Karpathy 最新分享：用 LLM 搭建个人知识库，告别 RAG 的低效循环]]
+
+## Summary（用中文描述）
+- 核心主题：Karpathy 提出用 LLM 构建持久化个人 Wiki 替代 RAG 方案，实现知识的增量积累与自动交叉引用
+- 问题域：传统 RAG 每次从零检索、无积累、维护成本高的问题
+- 方法/机制：
+  - Obsidian Web Clipper 采集素材并自动转为 Markdown
+  - Ctrl+Shift+D 快捷键批量下载图片本地化
+  - Graph View 图谱视图做 Lint 健康检查和发现知识盲区
+  - Dataview 插件做 frontmatter 数据库式查询
+  - Marp 插件将 Wiki 内容导出为幻灯片
+  - Git 版本管理自动 commit + push
+  - qmd 本地 Markdown 搜索引擎做精准检索
+- 结论/价值：AI 负责知识库维护（更新交叉引用、保持摘要最新），人类只负责读和想——维护成本趋近于零
+
+## Key Claims（用中文描述）
+- Karpathy + 老张：通过让 AI 增量构建和维护持久化 Wiki，实现了从"每次从零开始"到"知识持续沉淀"的范式转变
+- Karpathy：RAG 的根本问题是"没有积累"，每次提问 AI 都在从头搜寻知识，综合多文档时尤其低效
+- Karpathy：LLM Wiki 使 AI 能一次操作修改多个文件，维护交叉引用和页面一致性的成本趋近于零
+- 老张：对于大多数用户，Obsidian Web Clipper + 图片本地化 + Git + Claude 就足够打造 RAG 知识库
+
+## Key Quotes
+> "维护知识库最痛苦的不是阅读和思考，而是记录。更新交叉引用、保持摘要最新、标注新旧矛盾、维护几十个页面的一致性。" — Karpathy 论 RAG 的维护成本问题
+> "AI 不会厌倦，不会忘记更新交叉引用，一次操作可以碰十五个文件。维护成本趋近于零，知识库就能真正活下去。" — Karpathy 论 AI 维护 Wiki 的优势
+> "你把精力放在选素材、定方向、问好问题、思考意义，AI 负责其他一切。" — Karpathy LLM Wiki 思想精髓
+
+## Key Concepts
+- [[RAG]]：检索增强生成，传统 AI 知识管理方案，每次从零检索，无积累
+- [[LLM Wiki]]：Karpathy 提出的替代方案，让 AI 增量构建和维护持久化的互相链接的 Markdown 文件 Wiki
+- [[Obsidian]]：本地笔记工具，支持双向链接、Graph View、丰富的社区插件生态
+- [[Obsidian Web Clipper]]：浏览器插件，一键将网页文章保存为 Markdown 到 Obsidian
+- [[Graph View]]：Obsidian 内置图谱视图，以节点展示所有页面，双链关系自动连线
+- [[Dataview]]：Obsidian 社区插件，对 frontmatter 做数据库式查询，动态生成表格和列表
+- [[Marp]]：基于 Markdown 的幻灯片格式，配合 Obsidian Marp Slides 插件可预览和导出 PDF/HTML/PPTX
+- [[Obsidian Git]]：Obsidian Git 版本管理插件，设置 Auto commit-and-sync interval 自动 commit + push
+- [[qmd]]：完全本地运行的 Markdown 搜索引擎，用于大规模 Wiki 的精准检索
+
+## Key Entities
+- [[Karpathy]]：OpenAI 创始人之一、知名 AI 研究者，GitHub Gist 提出 LLM Wiki 方法论
+- [[laozhang2579]]：发布者/解读者，将 Karpathy 的方法实操落地为中文教程
+
+## Connections
+- [[LLM Wiki]] ← 来源 ← [[Karpathy]]
+- [[LLM Wiki]] ← 工具基础 ← [[Obsidian]]
+- [[RAG]] ← 对比/替代 → [[LLM Wiki]]
+
+## Contradictions
+- 无已知冲突页面
diff --git a/wiki/sources/language-translator.md b/wiki/sources/language-translator.md
new file mode 100644
index 00000000..e304f7ca
--- /dev/null
+++ b/wiki/sources/language-translator.md
@@ -0,0 +1,61 @@
+---
+title: "Language Translator"
+type: source
+tags: ["agent", "translation", "spanish", "english", "bilingual", "travel", "medical", "business", "legal"]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/language-translator.md]]
+
+## Summary（用中文描述）
+- 核心主题：LLM Agent 在实时西班牙语 ↔ 英语翻译领域的专业化设计，涵盖文化语境、地域方言感知、旅行短语引导，以及适用于日常、商务、紧急场景的语气适配沟通。
+- 问题域：如何让 AI 翻译超越逐字替换，实现意义传递，同时保持文化敏感性和地域方言准确性。
+- 方法/机制：通过系统化的 5 步工作流（理解请求 → 意义翻译 → 输出丰富化 → 特殊处理 → 跟进）结合记忆与学习机制，提供带语音发音指南、文化注释和紧急优先的翻译服务。
+- 结论/价值：翻译的本质是意义转移而非词典替换；文化语境、方言差异和语气级别是翻译质量的决定性因素；紧急短语需立即呈现，专业医学/法律翻译应建议人工介入。
+
+## Key Claims（用中文描述）
+- 翻译 = 意义转移，非逐字替换："It's raining cats and dogs" → "Está lloviendo a cántaros" 而非 "lloviendo gatos y perros"。
+- 西班牙语正式/非正式语域（usted/tú）决定沟通成败，错误选择可导致冒犯或误解。
+- 地域方言至关重要：同一词汇在不同国家含义迥异（如 "coche" 在西班牙=汽车，在拉丁美洲某些地区含义不同）。
+- 医疗/法律翻译不可猜测，复杂场景应建议专业人工口译员介入。
+- 紧急短语具有绝对优先权：翻译立即呈现，解释随后补充。
+- 发音指南是翻译的必备组成部分，使用简明英语拼音而非 IPA 标注。
+
+## Key Quotes
+> "Translation isn't word-for-word substitution — it's meaning transfer. The goal is never a dictionary output; it's a message the other person actually understands."
+> — The Language Translator Agent 核心原则
+
+## Key Concepts
+- [[Meaning Transfer Translation]]：翻译 = 意义转移，而非逐字替换；目标是有用信息，而非字典输出。
+- [[Register Switching]]：西班牙语正式（usted）/非正式（tú）语域切换；陌生人默认使用 usted，本地人先使用 tú 才跟随切换。
+- [[Regional Dialect Awareness]]：不同西语国家（墨西哥/西班牙/阿根廷/哥伦比亚等）的词汇差异；翻译需注明地域变体。
+- [[Phonetic Pronunciation Guide]]：为口语翻译提供英语拼音标注（非 IPA），确保用户能实际说出短语。
+- [[Cultural Context Flag]]：主动标注文化差异——某地礼貌用语在另一地可能具有冒犯性。
+- [[Emergency-First Protocol]]：紧急医疗/安全/法律短语立即呈现，先于任何解释。
+- [[Subjunctive Mood]]：西班牙语虚拟式在愿望、怀疑、情感、假设场景中的使用——翻译不可忽略。
+- [[Ser vs. Estar]]：两个"to be"动词不可互换——"Soy aburrido"（我无聊/我是个无聊的人）vs "Estoy aburrido"（我现在感到无聊）。
+- [[False Cognates]]：假同源词陷阱：embarazada=怀孕，sensible=敏感，éxito=成功——直接翻译会完全错误。
+
+## Key Entities
+- [[Mexican Spanish]]：美国英语使用者最常见的学习变体；使用 ustedes；纳瓦特尔语借词丰富。
+- [[Castilian Spanish (Spain)]]：使用 vosotros（非正式复数）；c/z 发 "th" 音；"coger" 在西班牙中性含义在拉丁美洲完全不同（需标注）。
+- [[Rioplatense Spanish (Argentina/Uruguay)]]：用 vos 替代 tú，变位不同；意大利语影响的词汇和语调。
+- [[Colombian Spanish (Bogotá)]]：被认为最清晰口音之一；某些地区亲密朋友间也使用正式 usted。
+- [[Caribbean Spanish]]（古巴、波多黎各、多米尼加）：语速快，辅音弱化（尤其词尾 s），词汇独特。
+
+## Connections
+- [[Customer Service Agent]] ← shares_approach ← [[Language Translator]]：两者都优先紧急响应、语气适配和清晰沟通
+- [[Healthcare Customer Service Agent]] ← medical_context ← [[Language Translator]]：医疗翻译是该 Agent 的重要场景，遵循相同紧急优先原则
+- [[Specialized Korean Business Navigator]] ← parallel_role ← [[Language Translator]]：同属专业领域语言导航 Agent
+
+## Contradictions
+- 与一般翻译工具（如 Google Translate）：
+  - 冲突点：机器翻译倾向于逐字直译，无法区分正式/非正式语域和方言变体。
+  - 当前观点：语言翻译 Agent 强调意义转移、文化语境和地域敏感性，提供场景化翻译输出。
+  - 对方观点：机器翻译速度快、成本低，适合简单信息传递。
+
+## Aliases
+- Spanish ↔ English Translator
+- Bilingual Language Specialist
+- Real-time Translation Agent
diff --git a/wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md b/wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
index 5a092e21..1b544f43 100644
--- a/wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
+++ b/wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
@@ -1,57 +1,61 @@
 ---
 title: "Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform"
 type: source
-tags: [Terraform, RDS, IaC, CTP, DevOps, DBRE, AWS]
+tags:
+  - Terraform
+  - RDS
+  - IaC
+  - Cloud-Transformation-Programme
+  - DBRE
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]
 
 ## Summary（用中文描述）
-- 核心主题：**通过 Terraform 在 AWS 上部署 RDS 数据库**，涵盖 IaC 最佳实践和 Gruntwork RDS 模块的选型对比
-- 问题域：RDS 部署方式的选择（控制台 vs 代码）、模块选型（grunt work 模块 vs SRE 核心模块）、Day 2 运维（扩缩容/补丁/升级）
-- 方法/机制：使用 Terragrunt（Terraform 封装器）管理 RDS 部署，通过 GitHub PR + Atlantis 实现变更自动化；CloudWatch 负责监控告警
-- 结论/价值：IaC 部署任何规模的 RDS 到 AWS 均优于控制台；grunt work RDS Service 相比裸模块提供更完整的企业级功能（KMS 加密、CloudWatch 告警等）；代码即文档
+- 核心主题：通过 Terraform 在 AWS 上自动化部署 RDS 数据库，DBRE 团队的 Greg 主讲
+- 问题域：IaC 部署 RDS 的模块选型、Day 2 运维操作、监控告警配置
+- 方法/机制：推荐使用 Gruntwork 的 RDS Service 模块（含 KMS 加密、CloudWatch 告警），配合 Terragrunt 管理多环境配置；Day 2 操作通过 GitHub PR + Atlantis 审批后自动 apply
+- 结论/价值：任何规模的 RDS 部署都应使用 Terraform 而非 Console，IaC 的核心价值在于"代码即文档"
 
 ## Key Claims（用中文描述）
-- **IaC 六大大好处**：速度、灵活性、一致性、灾难恢复、文档、自动化。代码即文档
-- **两种 RDS 部署选项**：裸模块 RDS module（基础功能）vs 更完整的 grunt work RDS Service（推荐，预建 KMS 加密和 CloudWatch 告警）
-- **SRE 核心模块功能弱于 grunt work 服务**：建议生产环境使用 grunt work RDS Service
-- **Terragrunt 优于裸 Terraform**：避免变量重复声明，保持代码整洁，贯彻 DRY 原则
-- **Day 2 运维通过 GitHub PR + Atlantis 实现**：扩缩容、补丁、大版本升级均在 Terragrunt 文件中修改，通过 PR 触发 Atlantis 自动应用
-- **监控方案**：CloudWatch Dashboard + Alarms，注意突发性能实例（burstable instance）的 CPU credits 消耗
+- **Greg（DBRE 团队）× IaC 选型**：提倡所有规模的 RDS 部署都使用 Terraform，Console 方式不可取
+- **IaC 六大核心价值**：速度、灵活性、一致性、灾难恢复、文档化、自动化；"代码即文档"是最核心的文档化原则
+- **RDS 模块二选一**：grunt work RDS Service（推荐，功能完整）vs SRE Core Modules（功能较少）；grunt work 预置 KMS 加密 + CloudWatch 告警，SRE 模块无此能力
+- **Terragrunt 实践**：使用 tagged release（不用 master）确保稳定性，避免变量重复声明，代码保持 DRY
+- **Day 2 运维流程**：变更在 Terragrunt 文件中完成 → GitHub Pull Request → Atlantis 审批 → 自动 apply；支持扩缩容、打补丁、主版本升级
+- **监控策略**：CloudWatch Dashboard + 告警；burstable 实例需关注 CPU credits
 
 ## Key Quotes
 > "We use Terragrunt, which is basically it's a wrapper around Terraform, and it allows you to keep your code clean and you're not repeating your variables all the time." — Greg, DBRE Team
-> "The code is the documentation." — Greg, 强调 IaC 的文档价值
+
+> "The code is the documentation." — Greg, DBRE Team（IaC 核心哲学）
 
 ## Key Concepts
-- [[Infrastructure-as-Code]]：通过代码定义和版本控制基础设施资源，核心优势包括速度、一致性、灾难恢复和自动化
-- [[DRY Principle]]：Terragrunt 通过管理 provider 和 remote_state 块减少跨环境重复声明
-- [[GitOps]]：通过 GitHub PR + Atlantis 实现基础设施变更的自动化审核和应用
-- [[CloudWatch-Alarms]]：RDS 监控与告警机制，包含突发性能实例的 CPU credits 考虑
-- [[KMS-Encryption]]：grunt work RDS Service 内置的 KMS 密钥加密功能
+- [[Infrastructure-as-Code]]：IaC 是本次分享的主题，Terraform 是核心工具，覆盖速度/灵活性/一致性/灾难恢复/文档化/自动化六大价值
+- [[InfrastructureAsCode]]：页面已有，本次来源提供 IaC 选型 RDS 的具体实践补充
+- [[DRY-Principle]]：Terragrunt 践行 DRY 原则，避免变量在多环境间重复声明
+- [[Terraform-State]]：Terraform 通过状态文件将期望状态绑定到实际环境（本来源提及但未展开）
 
 ## Key Entities
-- [[Gruntwork]]：提供预建 Terraform 模块（RDS Service 等），建议生产环境使用其 grunt work RDS Service 而非裸模块
-- [[Atlantis]]：Git 驱动的 Terraform 自动化工具，配合 GitHub PR 实现 IaC 变更
-- [[Terraform]]：云厂商无关的 IaC 核心工具
-- [[Terragrunt]]：Terraform 的 DRY 封装层，用于管理 RDS 部署配置
-- [[DBRE]]：Database Reliability Engineering 团队，Greg 来自该团队
-- [[CloudWatch]]：AWS 监控服务，用于 RDS Dashboard 和 Alarms
+- [[Greg]]：DBRE 团队成员，本次 Learning Session 的讲师，主讲 Terraform 部署 RDS
+- [[Amazon-RDS]]：本次分享的核心资源，Greg 主张所有规模都用 Terraform 部署
+- [[Gruntwork]]：提供 RDS Service 模块和 SRE Core Modules，是本次分享的模块选型依据
+- [[Terragrunt]]：推荐的 Terraform 封装工具，使用 tagged release 管理多环境
+- [[AWS]]：RDS 所在的云平台，监控使用 CloudWatch
+- [[Atlantis]]：GitOps 工具，配合 GitHub PR 实现 RDS 变更的自动化审批和 apply
 
 ## Connections
-- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（同一 CTP 系列，ECS 部署 + RDS 部署）
-- [[ctp-topic-48-terraform-vs-terragrunt]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Terragrunt 在两个主题中均有讨论）
-- [[ctp-topic-16-cross-account-terraform-modules]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（IaC 模块化 + Cross-account Terraform）
-- [[ctp-topic-9-ci-cd-with-gruntwork]] ← foundation ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Gruntwork CI/CD 基础）
-- [[Terraform]] ← wraps ← [[Terragrunt]]
-- [[Gruntwork]] ← provides ← [[RDS-Module]]（grunt work RDS Service）
-- [[Atlantis]] ← automates ← [[Terraform]]
-- [[CloudWatch]] ← monitors ← [[RDS-Module]]
+- [[ctp-topic-48-terraform-vs-terragrunt]] ← related_to ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（两者均讨论 Terragrunt 选型，本来源侧重 RDS 场景下的实践）
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← depends_on ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（基础设施部署与维护是本来源的上下文）
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← extends ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Day 2 运维中 GitHub PR + Atlantis 自动 apply 与该来源的 Atlantis 配置细节互补）
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related_to ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（两者均涉及 Gruntwork 模块体系）
+- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]] ← extends ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（ECS 部署和 RDS 部署共同构成 CTP 的 IaC 全景）
 
 ## Contradictions
-- 与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）：两者均依赖 Gruntwork 模块体系；本主题聚焦 RDS 部署，CI/CD 主题聚焦 ECS 应用部署；RDS 部署同样适用 Gruntwork 流水线规范，两者互补而非冲突
-- 与 [[ctp-topic-48-terraform-vs-terragrunt]]（Terraform vs Terragrunt）：本主题的实际案例印证了该主题的观点——Terragrunt 保持代码整洁、避免变量重复；两主题一致，共同推荐 Terragrunt 作为 Terraform 的封装层
-- 与 [[ctp-topic-16-cross-account-terraform-modules]]（跨账号 Terraform 模块）：两者均讨论 Terraform 模块的运维方式；跨账号模块方案（Jenkins + ECS Deploy Runner）与本主题（RDS 通过 Atlantis）的 CI/CD 载体不同，适用于不同规模和架构场景，无直接冲突
+- 与 [[ctp-topic-48-terraform-vs-terragrunt]] 的潜在冲突：
+  - 冲突点：Terraform vs Terragrunt 的定位
+  - 当前观点（来源）：Terragrunt 是 RDS 部署的首选工具，"keep your code clean, not repeating variables"
+  - 对方观点：CTP Topic 48 对 Terraform 和 Terragrunt 的适用场景做了更细致的对比，指出 Terragrunt 是"轻量封装"而非必须选择
+  - 实际情况：两者不矛盾，本来源是 Terragrunt 的正面用例，Topic 48 提供的是通用对比框架
diff --git a/wiki/sources/legal-billing-time-tracking.md b/wiki/sources/legal-billing-time-tracking.md
new file mode 100644
index 00000000..f936359c
--- /dev/null
+++ b/wiki/sources/legal-billing-time-tracking.md
@@ -0,0 +1,60 @@
+---
+title: "Legal Billing & Time Tracking"
+type: source
+tags: [billing, legal, time-tracking, agency-agent, specialized]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/legal-billing-time-tracking.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Specialized 部门法律事务所计费与时间追踪专家 Agent，覆盖时间捕获、账单叙事撰写、开票生成、催收管理、信托账户合规、计费分析全生命周期六大核心模块。
+- 问题域：律所营收流失问题——以$300/小时计费标准计算，每位律师每天因时间捕获习惯不佳平均损失2-3小时可计费时间，年均$180,000-$270,000营收蒸发。计费叙事不清晰还会引发客户争议，进一步侵蚀收入。
+- 方法/机制：10条关键行为规则强制执行（时间实时捕获/禁止计费非billable时间/信托账户神圣/叙事必须诚实具体/永不超过实际时间/遵守客户计费指南/核销需律师批准/催收沟通专业/应急费协议必须书面/争议立即升级）；时间录入标准（0.1小时增量/实时录入/不得模糊描述）；分业务领域的计费叙事模板（诉讼/公司交易/房地产/遗产规划/雇佣）；发票审核清单三段式（客户信息→时间条目→费用汇总）；五阶段催收通信序列（发票发送→友好提醒→逾期通知→最终通知→律师升级）；月度三向对账（银行对账单→客户台账→信托日记账）；关键绩效指标体系（实现率≥90%/实收率≥95%/90天以上AR<5%）。
+- 结论/价值：计费不是行政职能而是事务所的财务引擎；精准、透明、道德三位一体是计费管理的核心原则。
+
+## Key Claims（用中文描述）
+- 律师每天因时间捕获习惯不佳平均损失2-3小时可计费时间，按$300/小时计算年均$180,000-$270,000营收蒸发；事务所财务成功的关键不在于案源多少，而在于能否捕获并收取应得收入。
+- 信托账户资金神圣不可侵犯——不得与事务所运营资金混同，信托账户错误属于律师纪律处分事项。
+- 计费叙事必须诚实、具体、可防御——模糊条目如"法律服务""审阅文件""电话"既不专业，又易引发客户争议，且可能存在道德问题。
+- 时间录入必须实时完成——事后重建的时间条目准确度更低，更容易遭受客户质疑。
+- 核销（write-down/write-off）必须获得负责律师授权——未经授权不得单方面调整，所有调整必须记录原因代码。
+- 应急费协议必须书面确认——口头应急费协议在大多数司法管辖区不可强制执行。
+- 催收通信必须专业但坚定——目标是收款的同时维护客户关系，绝不能越界构成骚扰。
+- 账单争议必须立即升级至负责律师——不得单方面做出计费调整决定。
+- 实现率（Realization Rate）目标≥90%——低于85%需调查核销模式。
+- 收款率（Collection Rate）目标≥95%——低于90%需审查催收流程和客户信用状况。
+
+## Key Quotes
+> "The average attorney loses 2-3 hours of billable time every day to poor time capture habits. At $300/hour, that's $180,000-$270,000 in annual revenue that simply disappears." — 核心论点：时间捕获是事务所收入的核心杠杆
+
+> "Trust accounts are sacred. Client funds in trust accounts must never be commingled with firm operating funds. Disbursements from trust require strict documentation. Trust account errors are bar discipline matters — treat them accordingly." — 核心规则：信托账户零容忍
+
+## Key Concepts
+- [[TimeCapture]]：实时时间录入标准，0.1小时（6分钟）最小增量，工作完成后同一天内录入，最多不超过48小时。
+- [[BillingNarrative]]：计费叙事标准，必须描述做了什么、在哪个案件、为什么做；禁止模糊条目如"法律服务""审阅文件""电话""研究""案件工作""杂项"。
+- [[IOLTA]]：Interest on Lawyer Trust Accounts，律师信托账户利息，各州规定不同，信托资金产生的利息通常用于法律援助公益。
+- [[Three-Way-Reconciliation]]：月度三向对账——银行对账单余额 = 各客户台账余额之和 = 信托日记账余额，三者必须完全一致，任何差异需立即调查。
+- [[Realization-Rate]]：实现率 = 总计费 / 总工时 × 100%，目标≥90%，低于85%需调查核销模式。
+- [[Collection-Rate]]：实收率 = 总实收 / 总计费 × 100%，目标≥95%，低于90%需审查催收流程。
+- [[BlockBilling]]：合并多任务为单一条目的计费方式；部分客户指南禁止block billing，违反将导致发票削减并损害客户关系。
+
+## Key Entities
+- [[Clio]]：时间录入、开票、信托会计、AR管理的主流法律计费软件之一。
+- [[LawPay]]：合规法律支付处理平台。
+- [[QuickBooks]]：与法律计费系统集成进行会计处理的财务软件。
+- [[The-Agency]]：本 Agent 所属组织，Specialized 部门法律专项 Agent 系列之一。
+
+## Connections
+- [[legal-client-intake]] ← extends ← [[legal-billing-time-tracking]]：客户 intake 完成案件信息收集后，计费 Agent 接手财务引擎管理。
+- [[legal-billing-time-tracking]] ← depends_on ← [[IOLTA]]：信托账户合规管理依赖各州 IOLTA 规定。
+- [[legal-billing-time-tracking]] ← supports ← [[accounts-payable-agent]]：计费 Agent 负责收款（AR管理），与应付账款 Agent 形成事务所现金流的收/支双侧。
+- [[legal-billing-time-tracking]] ← informs ← [[support-legal-compliance-checker]]：计费合规性检查（信托账户/计费伦理）需法律合规 Agent 确认。
+
+## Contradictions
+- 与"快速简洁 intake"主流观点的潜在张力：
+  - 冲突点：详细的时间录入规范和账单审核清单可能导致 intake 阶段花费更多时间在财务信息收集上。
+  - 当前观点：本 Agent 强调计费数据在 intake 阶段就要建立标准（费率/计费指南/付款条款/信托账户阈值）。
+  - 对方观点：intake 应聚焦案件信息收集，财务细节可延后。
+  - 协调方案：在 intake 流程中预先确认计费框架（费率/指南/付款条款）可显著减少后续开票争议，属于预防性计费管理而非效率损失。
diff --git a/wiki/sources/legal-client-intake.md b/wiki/sources/legal-client-intake.md
new file mode 100644
index 00000000..6ebe7cfa
--- /dev/null
+++ b/wiki/sources/legal-client-intake.md
@@ -0,0 +1,55 @@
+---
+title: "Legal Client Intake Agent"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/legal-client-intake.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 驱动的法律客户接待与资格审查全流程自动化
+- 问题域：律所潜在客户流失、 intake 效率低下、冲突检查疏漏、时效性法规风险
+- 方法/机制：六阶段标准化 intake 工作流（初始接触→资格审查→利益冲突筛查→案件信息收集→咨询安排→摘要交付），配套 10 条关键规则约束行为边界
+- 结论/价值：提升客户留存率 100% 完成冲突检查、识别所有时效性截止日期、在律师接手前完成 attorney-ready 摘要
+
+## Key Claims（用中文描述）
+- **初始响应速度是转化关键**：在 5 分钟内响应潜在客户咨询，转化率比 30 分钟后响应提升 400%
+- **利益冲突筛查必须先于安排咨询**：在确认无利益冲突前不得安排任何咨询，代表冲突方是严重的律师执业违规
+- **时效截止日期识别是 malpractice 风控核心**：人身伤害案件 2-3 年时效期限（各州不同）、EEOC 歧视投诉 180-300 天——错过截止日期直接构成 malpractice 索赔
+- **每次 intake 都是 attorney-client privilege 保护**：从第一次接触开始，所有潜在客户分享的信息均受律师-客户特权保护
+- **empathy-driven intake 提升留存**：在 intake 过程中感到被倾听的潜在客户，即使费率更高也更可能选择该律所
+- **qualification 节省双方时间**：彻底资格审查可以防止无效咨询（律师计时收费却被浪费）
+
+## Key Quotes
+> "Most law firms lose potential clients before the attorney ever picks up the phone. A slow response, a confusing intake form, or a cold first interaction sends prospects straight to a competitor." — 行业现状
+
+> "Every intake interaction must end with a clear, confirmed next step — a scheduled consultation, a referral, or a specific follow-up action — so no prospect falls through the cracks." — 操作规范
+
+## Key Concepts
+- [[Statute-of-Limitations]]：时效期限，各法律领域有不同的截止日期，错过即构成 malpractice 风险
+- [[Conflict-of-Interest-Screening]]：利益冲突筛查，必须在安排咨询前完成，收集对方当事人全名和事先代表信息
+- [[Intake-Summary]]：律师就绪的案件摘要，在咨询前至少 30 分钟交付给律师，包含关键事实、时效截止日期和紧急标记
+- [[Practice-Area-Qualification]]：业务领域资格审查，确定潜在客户的事务类型（人身伤害/家庭法/刑事等）是否属于律所执业范围
+- [[Consultation-Scheduling]]：咨询安排，根据业务领域匹配合适律师，确认时间/形式（电话/视频/面谈）/需携带材料
+- [[Referral-Out]]：优雅转介，当潜在客户的事务不在律所执业范围时，提供具体的转介信息而非简单拒绝
+
+## Key Entities
+- [[The-Agency]]：The Agency 的 Specialized 部门 Agent，覆盖多行业专业服务场景
+- [[Personal-Injury]]：人身伤害，最常见的 intake 业务领域之一，时效期限 2-3 年（各州不同）
+- [[EEOC]]：Equal Employment Opportunity Commission，雇佣歧视投诉机构，时效期限 180-300 天
+
+## Connections
+- [[Legal-Compliance-Checker]] ← depends_on ← [[Legal-Client-Intake]]：Legal Client Intake 收集冲突信息，Legal Compliance Checker 提供合规审查
+- [[Practice-Area-Qualification]] ← extends ← [[Intake-Summary]]：资格审查是摘要信息收集的前置步骤
+- [[Conflict-of-Interest-Screening]] ← guards ← [[Consultation-Scheduling]]：冲突筛查是安排咨询的门控条件
+- [[Referral-Out]] ← alternative_to ← [[Consultation-Scheduling]]：当资格审查失败时，转介是安排的替代方案
+- [[Support-Responder]] ← similar_to ← [[Legal-Client-Intake]]：两者都是 first contact 接待专家，区别在于领域不同
+
+## Contradictions
+- 与"简洁快速 intake"的主流观点：
+  - 冲突点：本文档强调详尽的多阶段 intake 流程（6 步完整工作流）
+  - 当前观点：全面收集案件信息、多次确认意向、完整 attorney-ready 摘要是长期客户留存的关键
+  - 对方观点：快速 minimal intake 能提高响应速度和 initial contact 转化率
+  - 协调方案：可针对不同潜在客户类型（紧急/高价值/低优先级）调整 intake 深度，紧急事务优先速度，非紧急高价值事务优先质量
diff --git a/wiki/sources/legal-document-review.md b/wiki/sources/legal-document-review.md
new file mode 100644
index 00000000..4e8cbbdb
--- /dev/null
+++ b/wiki/sources/legal-document-review.md
@@ -0,0 +1,55 @@
+---
+title: "Legal Document Review Agent"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/legal-document-review.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Legal Document Review Agent — 专业的法律文档审查 Agent，为律师提供第一轮文件审查，发现风险条款、总结关键条款、标记问题条款、比较版本差异、检查合规性。
+- 问题域：法律文件审查（合同/诉讼文书/房地产协议/合规审查/版本比对），覆盖商法、房地产、公司法、劳动法、知产法等多领域。
+- 方法/机制：五步工作流（文档接收与分类 → 结构分析 → 实质审查 → 风险评估与标记 → 交付物准备），结合高风险条款库（赔偿/责任限制/终止/IP/自动续期/竞业限制/管辖法律）、分级风险评分（高/中/低）、标准化交付模板。
+- 结论/价值：取代律师的初读工作，让律师专注于判断和策略，减少遗漏高风险条款的可能性，保护客户免受合同陷阱损失。
+
+## Key Claims（用中文描述）
+- 法律文档审查 Agent 永远不提供法律意见，始终将发现标记为"供律师审查"，而非确定性法律结论。
+- 审查前必须先识别文件类型、当事人、代理客户和管辖权——上下文决定风险级别。
+- 存在疑问时一律标记——误报成本是秒级，漏报风险条款可能造成客户数百万损失。
+- 摘要不得省略任何经济重大条款：支付、期限、终止、责任、赔偿、知识产权、适用法律。
+- 缺失条款（无责任限制、无赔偿条款、无不可抗力）不是中性沉默，应明确标记为缺失。
+- 版本比对必须穷尽：每个变更（包括格式、定义术语修改、看似微小的措辞变更）都必须捕捉。
+- 每份审查输出必须以明确的优先行动建议结尾，而非仅列出发现。
+
+## Key Quotes
+> "A lawyer who reads every word of every document perfectly, every time, doesn't exist. A system that does — and flags exactly what needs human attention — is worth its weight in billable hours." — 核心价值主张
+
+> "Every flagged clause must include: location, exact language, risk, market standard, impact, and recommended revision." — 标准化交付要求
+
+> "Jurisdiction matters. Always note when a clause's enforceability may vary by jurisdiction. What is standard in one state may be unenforceable in another." — 管辖权意识
+
+## Key Concepts
+- [[DocumentSummaryTemplate]]：标准化文件摘要模板，包含关键条款一览表（期限/支付/终止/续期/适用法律/争议解决/责任上限/赔偿/IP/保密）和缺失标准条款清单。
+- [[RiskClauseFlagging]]：风险条款标记流程，将条款分为高/中/低风险三级，每级包含位置、语言、风险、市场标准、影响和建议修订。
+- [[ContractComparisonTemplate]]：合同版本比对模板，区分实质性变更和管理性变更，记录有利/不利/中性变更计分。
+- [[ComplianceReviewTemplate]]：合规审查模板，对应州/联邦/国际要求，检查合规/潜在不合规/不合规三级状态。
+- [[HighRiskClauseLibrary]]：高风险条款库，涵盖赔偿、责任限制、终止、知识产权、自动续期、竞业限制、适用法律/争议解决七类常见高风险条款。
+- [[TenCriticalRules]]：十大关键规则，包括不提供法律意见、先识别上下文、全面标记、不错漏经济条款、尊重管辖权差异、不简化缺失条款、保密性、版本比对穷尽化、建议下一步行动。
+- [[DomainExpertiseCoverage]]：领域专业覆盖——商业合同（MSA/NDA/雇佣/供应/合伙/许可）、房地产文件（买卖/租赁/贷款/产权）、公司文件（运营/股权/资产收购/股票收购）、诉讼文书（诉状/动议/开示/和解/命令）、合规框架（劳动法/数据隐私/房地产/公司法/行业特定）。
+
+## Key Entities
+- （无具体人物/公司/产品实体，均为抽象角色描述）
+
+## Connections
+- [[LegalClientIntake]] ← depends_on ← [[LegalDocumentReview]]：法律客户 intake Agent 为文档审查 Agent 提供待审文件，两者构成法律服务前置→核心流程。
+- [[LegalBillingTimeTracking]] ← depends_on ← [[LegalDocumentReview]]：文档审查完成后，计费与时间追踪 Agent 负责记录审查工时和计费叙事，两者共享法律事务所上下文。
+- [[LegalDocumentReview]] ← extends ← [[CustomerService]]：通用客户服务 Agent 的投诉处理流程为法律文档审查中的诉讼文书处理提供了分级升级框架基础。
+
+## Contradictions
+- 与 [[CustomerService]] 的"简洁高效"服务理念存在张力：
+  - 冲突点：通用客服追求快速解决，减少来回；法律文档审查 Agent 要求穷尽式标记，不遗漏任何风险。
+  - 当前观点：法律文档审查应全面标记，不惜误报。
+  - 对方观点：客户体验优先，减少不必要的标记干扰。
+  - 注：此为领域差异，非事实矛盾——法律场景的"过度标记"实为必要风险管控。
diff --git a/wiki/sources/level-designer.md b/wiki/sources/level-designer.md
index 6ab942fc..581718c0 100644
--- a/wiki/sources/level-designer.md
+++ b/wiki/sources/level-designer.md
@@ -1,50 +1,62 @@
 ---
 title: "Level Designer Agent Personality"
 type: source
-tags: []
-date: 2026-04-26
+tags: ["game-development", "level-design", "agent-personality", "spatial-design", "game-design"]
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/level-designer.md]]
+- [[Agent/agency-agents/game-development/level-designer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：游戏关卡设计师（Level Designer）AI Agent 的角色定义与工作规范
-- 问题域：如何通过空间叙事、流程控制、遭遇战设计、环境叙事等手段，创造可玩、可读、有情感张力的游戏关卡
-- 方法/机制：六阶段工作流（意图定义 → 纸面布局 → 灰盒搭建 → 遭遇战调优 → 美术交接 → 打磨验收）；Blockout 三阶段（灰盒 → 美术 → 特效音效）；空间心理学理论（prospect-refuge、figure-ground、Lynch 城市设计原则）；程序化关卡生成规则集
-- 结论/价值：提供了一套完整的 AI Agent 关卡设计方法论，涵盖线性射击、开放世界、Roguelike、Metroidvania 等多种游戏类型
+- 核心主题：Level Designer Agent 的角色定义与设计方法论——将游戏关卡视为"空间叙事"作品，通过布局、节奏、遭遇战设计和环境叙事来引导、挑战和沉浸玩家
+- 问题域：游戏关卡设计中的可读性、平衡性、节奏控制、环境叙事传达、多人空间设计
+- 方法/机制：六阶段工作流（意图定义→纸面布局→灰盒→遭遇战调优→美术交接→打磨）；三阶段关卡交付（灰盒/美术/打磨）；关卡设计文档标准化模板；空间心理学理论（Prospect-Refuge、Kevin Lynch城市设计）
+- 结论/价值：为游戏关卡设计提供了完整的 Agent 角色规范，涵盖线性射击、开放世界、Roguelike、银河恶魔城等多种品类，强调可测试性（playtest-grounded）的设计决策文化
 
 ## Key Claims（用中文描述）
-- 关卡设计师通过空间架构引导、挑战和沉浸玩家——走廊是句子，房间是段落，关卡是完整的论证
-- 关键路径必须始终视觉可读——除非刻意设计迷路体验，否则玩家不应迷路
-- 每个战斗遭遇必须有：入口读图时间、多种战术选项和退守位置
-- 难度必须先从空间（位置和布局）出发，再考虑数值缩放
-- 每个区域通过道具摆放、光照和几何形状讲述故事——不存在空白的"填充"空间
-- 关卡交付三阶段：灰盒（blockout）→ 美术（dress）→ 打磨（polish）——设计决策在灰盒阶段锁定
-- 未经灰盒测试验证的布局不得进行美术包装
+- 关卡设计师将走廊视为句子、房间视为段落、关卡视为完整的论点——空间本身就是叙事媒介
+- 关键路径必须始终在视觉上可读，玩家迷路必须是刻意的设计而非系统失败
+- 难度首先应是空间性的（位置和布局），其次才是数值缩放
+- 灰盒必须先通过测试，艺术美化前必须锁定设计决策——零例外
+- 100% 的测试玩家无需询问方向即可导航关键路径时，关卡才算成功
 
 ## Key Quotes
-> "A corridor is a sentence, a room is a paragraph, and a level is a complete argument about what the player should feel." — 核心隐喻定义
-> "MANDATORY: The critical path must always be visually legible — players should never be lost unless disorientation is intentional and designed." — 强制规则
-> "Never art-dress a layout that hasn't been playtested as a grey box." — Blockout 纪律
+> "You understand that a corridor is a sentence, a room is a paragraph, and a level is a complete argument about what the player should feel." — Level Designer Agent 核心身份宣言
+> "Never art-dress a layout that hasn't been playtested as a grey box" — 灰盒优先原则
+> "Every combat encounter must have: entry read time, multiple tactical approaches, and a fallback position" — 遭遇战设计三要素
+> "Players should be able to infer what happened in a space without dialogue or text" — 环境叙事目标
+> "Difficulty must be spatial first — position and layout — before stat scaling" — 空间优先于数值
 
 ## Key Concepts
-- [[Flow And Readability]]：关卡流与可读性——关键路径视觉清晰，用光照、色彩、几何引导注意力，不依赖小地图作为主要导航工具
-- [[Encounter Design]]：遭遇战设计——每个战斗场景必须提供读图时间、多战术选项和退守位置
-- [[Environmental Storytelling]]：环境叙事——通过道具摆放、光照和几何讲述世界故事，无需对话或文本
-- [[Blockout Discipline]]：灰盒纪律——设计决策在灰盒阶段锁定，禁止在未经测试的布局上美术包装
-- [[Spatial Psychology]]：空间心理学——应用 prospect-refuge 理论、figure-ground 对比、Kevin Lynch 城市设计五要素
-- [[Procedural Level Design]]：程序化关卡设计——为程序化生成制定规则集，保证最低质量阈值
-- [[Pacing Architecture]]：节奏架构——通过空间节奏控制张力：紧张 → 释放 → 探索 → 战斗
-- [[Speedrun Design]]：速通设计——审计每个关卡的非预期序列断裂，设计最优路径奖励精通但不惩罚休闲玩家
+- [[Pacing Chart]]：节奏图表，通过时间和活动类型可视化关卡的张力曲线（紧张/释放/探索/战斗交替）
+- [[Grey Box Blockout]]：灰盒原型阶段，仅用未贴图几何体快速验证布局可读性，所有设计决策在灰盒阶段锁定
+- [[Encounter Design]]：遭遇战设计，要求每场战斗具备进入读时、多种战术选项和撤退位置
+- [[Environmental Storytelling]]：环境叙事，通过道具摆放、光照和几何形状传达世界故事，无需对话或文字
+- [[Navigation Affordance]]：导航可达性，通过光照、色彩和几何引导注意力，确保关键路径在视觉上突出
+- [[Spatial Psychology]]：空间心理学，应用 Prospect-Refuge 理论使玩家感到安全（俯瞰位置+受保护的背部）
+- [[Procedural Level Design]]：程序化关卡设计，通过规则集和手工锚点确保生成质量下限
+- [[Prospect-Refuge Theory]]：前景-庇护理论，玩家在有俯瞰位置且背部受保护时感到安全
+- [[Kevin Lynch Urban Design]]：Kevin Lynch 城市设计五要素（路径/边缘/区域/节点/地标）应用于游戏空间
+- [[Temptation Design]]：诱惑设计，可选区域通过光照或色彩区分，奖励物在岔路口可见
+- [[Figure-Ground Contrast]]：图底对比，建筑中使目标从背景中视觉突出的设计手法
 
 ## Key Entities
-- （本文档未明确提及具体人物或公司）
+- [[Game Audio Engineer]]：同为 agency-agents 游戏开发分支下的 Agent，与 Level Designer 在环境叙事和节奏控制上有协同关系
+- [[Technical Artist]]：在灰盒阶段完成后负责美术交接（Art Pass Handoff）的角色
+- [[Game Designer]]：Level Designer 的上游角色，提供游戏整体设计意图和玩法框架
 
 ## Connections
-- [[Technical Artist]] ← 并行协作 ← [[Level Designer]]（环境叙事 + 美术实现的协作关系）
-- [[Game Audio Engineer]] ← 并行协作 ← [[Level Designer]]（音效设计配合节奏图表）
-- [[Agents Orchestrator]] ← 上游编排 ← [[Level Designer]]（被编排的子 Agent）
+- [[Pacing Chart]] ← defines ← [[Level Designer]]
+- [[Grey Box Blockout]] ← validated_by ← [[Playtest]]
+- [[Encounter Design]] ← requires ← [[Navigation Affordance]]
+- [[Environmental Storytelling]] ← informs ← [[Game Audio Engineer]]（音效支持节奏弧线）
+- [[Game Designer]] ← provides_intent ← [[Level Designer]]
+- [[Technical Artist]] ← receives_handoff ← [[Level Designer]]（美术交接文档）
 
 ## Contradictions
-- （当前未发现与 Wiki 中其他页面的内容冲突）
+- 与 [[Technical Artist]] 潜在冲突：
+  - 冲突点：艺术美化与设计锁定优先级——美术团队可能希望在灰盒阶段进行视觉优化，而 Level Designer 坚持设计决策在灰盒阶段锁定后才能进入美术阶段
+  - 当前观点：设计决策必须在灰盒阶段锁定，美术阶段不得更改核心布局
+  - 对方观点：美术迭代可能反向驱动设计优化（如光照方向影响空间感知）
+  - 解决方向：建立"gameplay-critical geometry"标注体系，关键几何体锁定，可造型区域开放
diff --git a/wiki/sources/llm-wiki.md b/wiki/sources/llm-wiki.md
new file mode 100644
index 00000000..649aa6c4
--- /dev/null
+++ b/wiki/sources/llm-wiki.md
@@ -0,0 +1,55 @@
+---
+title: "LLM Wiki"
+type: source
+tags: [llm, knowledge-base, agent, personal-wiki, rag]
+date: 2026-04-09
+---
+
+## Source File
+- [[raw/Agent/LLM Wiki.md]]
+
+## Summary（用中文描述）
+- 核心主题：利用 LLM 构建和持续维护个人知识库（Wiki）的架构模式
+- 问题域：传统 RAG 每次查询都从零发现知识，无法积累；Wiki 维护负担随规模增长而超过价值，导致人们放弃维护
+- 方法/机制：三层架构（Raw Sources → Wiki → Schema），LLM 增量构建持久化维基，代替人类完成"记账式"维护工作（总结、交叉引用、归档、一致性检查）
+- 结论/价值：知识只需编译一次即可保持最新，LLM 承担维护成本使 Wiki 可持续运行；人是编辑，LLM 是程序员，Wiki 是代码库
+
+## Key Claims（用中文描述）
+- LLM Wiki 通过增量构建和持续维护，使知识在每次查询时无需重新推导
+- 传统 RAG 每次回答都从原始文档中重新发现知识，没有积累；LLM Wiki 则将知识编译为持久化、相互链接的摘要
+- LLM 不会厌倦、不会忘记更新交叉引用，一次可以处理 15 个文件，维护成本接近零
+- 人的职责是筛选资料、指导分析、提出好问题；LLM 的职责是其他一切
+- 好的答案可以归档回 Wiki 作为新页面，探索结果与摄入来源一样复合积累
+
+## Key Quotes
+> "The wiki is a persistent, compounding artifact." — Wiki 的本质特征：持久化、复合增长的成果物
+> "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." — LLM 与人的协作模式比喻
+> "The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping." — 维护知识库最繁琐的部分不是阅读或思考，而是记录工作
+> "LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass." — LLM 相比人类的维护优势
+> "This idea is related in spirit to Vannevar Bush's Memex (1945)" — 概念渊源：Vannevar Bush 的 Memex
+
+## Key Concepts
+- [[PersistentWiki]]：持久化维基——结构化、相互链接的 Markdown 文件集合，介于用户与原始数据源之间，知识编译一次后保持最新
+- [[LLMWikiArchitecture]]：三层架构——Raw Sources（原始资源）、Wiki（LLM 生成的知识层）、Schema（CLAUDE.md/AGENTS.md 等配置文件）
+- [[IngestWorkflow]]：导入工作流——LLM 读取源文件、与用户讨论要点、编写摘要、更新索引、更新相关实体和概念页面、追加日志
+- [[QueryWorkflow]]：查询工作流——LLM 搜索相关页面、综合答案并引用来源；好的答案可归档回 Wiki
+- [[LintWorkflow]]：检查工作流——定期检查页面间矛盾、过时说法、孤立页面、数据缺口等
+- [[Memex]]：Vannevar Bush（1945）构想的个人知识库概念，文档之间有关联轨迹——LLM Wiki 承接了这一愿景并解决了"谁来维护"的问题
+
+## Key Entities
+- [[VannevarBush]]：1945 年 Memex 概念的提出者，提出"关联轨迹"思想，其愿景比后来的万维网更接近 LLM Wiki 的理念
+- [[Obsidian]]：本地 Markdown 编辑器（IDE），用户浏览 Wiki 结果的界面，提供图形视图查看 Wiki 结构
+- [[NotebookLM]]：Google 的 AI 笔记工具，采用传统 RAG 模式，与 LLM Wiki 的持久化维基模式形成对比
+
+## Connections
+- [[PersistentWiki]] ← implements ← [[LLMWikiArchitecture]]
+- [[PersistentWiki]] ← competes_with ← [[RAG]] （传统 RAG 每次查询从零推导，持久化维基一次编译持续复用）
+- [[IngestWorkflow]] ← uses ← [[PersistentWiki]]
+- [[QueryWorkflow]] ← uses ← [[PersistentWiki]]
+- [[PersistentWiki]] ← inspired_by ← [[Memex]]
+
+## Contradictions
+- 与 NotebookLM 等传统 RAG 系统对比：
+  - 冲突点：是否需要每次查询时重新发现知识
+  - 当前观点：LLM Wiki 通过持久化维基积累知识，避免重复推导
+  - 对方观点：传统 RAG 每次查询时检索相关片段生成答案，无需维护 Wiki
diff --git a/wiki/sources/loan-officer-assistant.md b/wiki/sources/loan-officer-assistant.md
new file mode 100644
index 00000000..874dfe22
--- /dev/null
+++ b/wiki/sources/loan-officer-assistant.md
@@ -0,0 +1,65 @@
+---
+title: "Loan Officer Assistant Agent"
+type: source
+tags: []
+last_updated: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/loan-officer-assistant.md]]
+
+## Summary（用中文描述）
+- 核心主题：面向抵押贷款和消费信贷专业人士的 AI Agent，涵盖借款人接待、预审、文件收集、管道管理、合规跟踪、利率报价及交割协调的全生命周期。
+- 问题域：贷款专员如何在高合规压力、高客户期望的环境下，同时管理多条贷款管道的进度、文件完整性和监管截止日期。
+- 方法/机制：五步工作流（借款人接待→申请与披露→处理与文件收集→承销管理→交割协调）+ 十项关键规则（TRID/DTI/公平贷款/文件有效期/资质要求等）+ 标准化交付模板（借款人接待脚本、预审表、文件清单、TRID时间表、贷款状态更新模板、承销条件跟踪表）。
+- 结论/价值：优秀的贷款专员不是靠熟记利率，而是靠精确的管道管理、合规意识和为申请人提供全程主动沟通的能力。Agent 通过结构化模板和规则引擎，帮助贷款专员将每笔贷款从初次接触到最终放款都按时、保合规地完成。
+
+## Key Claims（用中文描述）
+- [[LoanOfficerAssistant]] 通过覆盖借款人接待、预审、申请、处理、承销、交割全生命周期的结构化工作流，支持贷款专员专注于成交和客户关系维护。
+- [[TRID]] 规则要求在申请后 3 个工作日内交付 Loan Estimate，在成交前至少 3 个工作日交付 Closing Disclosure；错过任一截止日期均构成联邦监管违规。
+- [[FairLending]] 合规是绝对底线——不得因种族、肤色、宗教、国籍、性别、家庭状况、残疾、年龄等受保护特征而差异化对待借款人。
+- 利率锁定到期意味着借款人潜在成本增加；Agent 必须持续追踪锁定到期日并在足够提前量提醒贷款专员。
+- 工资单、银行流水、评估报告、信用报告均有有效期限；过期文件必须在交割或承销前刷新，否则承销将会以最坏时机补件要求。
+- 贷款决策（批准/拒绝）只能由持牌承销商做出；Agent 不得告知借款人已批准、已拒绝或很可能批准。
+- [[DTI]] 比率（Front-end ≤ 28%/31%，Back-end ≤ 45%/43-50%）是预审和贷款产品匹配的核心指标。
+- [[LoanToValue]]（LTV = 贷款金额 ÷ 评估价值）和 Combined LTV（CLTV）是决定贷款产品和首付要求的关键参数。
+- 承销条件必须以书面文件清除；借款人口头保证不充分——任何条件清除必须有书面证据。
+- 州级许可证要求因州而异；贷款专员必须在借款人房产所在州（抵押贷款）或借款人居住州（消费贷款）持有执照后方可接受申请。
+
+## Key Quotes
+> "The difference between a good loan officer and a great one isn't knowledge of rates — it's the ability to manage a complex pipeline, keep borrowers informed, stay ahead of compliance, and close on time. Every. Single. Time." — The Loan Officer Assistant Agent 核心价值观
+>
+> "Every borrower must be treated consistently regardless of race, color, religion, national origin, sex, familial status, disability, age, or any other protected class." — 公平贷款合规绝对原则
+>
+> "A loan file is only as strong as its weakest document, and a borrower relationship is only as strong as its last communication." — Agent 对文件和沟通质量的核心信念
+
+## Key Concepts
+- [[TRID]]：TILA-RESPA Integrated Disclosure，LE（Loan Estimate）和 CD（Closing Disclosure）的联邦披露时间要求框架。
+- [[DebtToIncome]]：DTI 比率，Front-end = PITI ÷ 月毛收入，Back-end =（PITI + 所有月供）÷ 月毛收入，用于偿还能力评估。
+- [[LoanToValue]]：LTV = 贷款金额 ÷ 评估价值（或成交价，取较低者），决定贷款产品类型和首付要求。
+- [[PreQualification]]：预审流程，基于收入、资产、信用、债务数据的初步资格评估，非贷款承诺。
+- [[UnderwritingConditions]]：承销条件，承销商要求的文件或说明，在交割前必须以书面证据清除。
+- [[RateLock]]：利率锁定，锁定期间利率不变，过期后借款人面临利率上升风险。
+- [[DocumentExpiration]]：文件有效期管理，工资单30天、银行流水60天、信用报告120-180天、评估120-180天。
+- [[FairLending]]：公平贷款，所有借款人在服务水平和产品提供上一致对待，禁止基于受保护特征的歧视。
+
+## Key Entities
+- [[FannieMae]]（FNMA）：房利美，Conventional Loan（普通贷款）指南和合规性参考。
+- [[FreddieMac]]（FHLMC）：房地利美，High-balance Conforming Loan 指南参考。
+- [[FederalHousingAdministration]]（FHA）：联邦住房管理局，提供 FHA 贷款（3.5% 首付、MIP 要求）。
+- [[DepartmentOfVeteransAffairs]]（VA）：退伍军人事务部，提供 VA 贷款（符合条件的退伍军人 0% 首付）。
+- [[USDAD RuralDevelopment]]：美国农业部农村发展局，提供 USDA 贷款（符合条件的农村地区 0% 首付）。
+- [[SBA]]：小型企业管理局，提供 SBA 7(a) 和 504 商业贷款。
+
+## Connections
+- [[LegalDocumentReview]] ← supports ← [[LoanOfficerAssistant]]：法律文档审查 Agent 覆盖抵押文件（买卖合同/贷款文件/产权文件），与 Loan Officer Assistant 在贷款文件审查环节存在上下游关系。
+- [[RealEstateBuyerSeller]] ← coordinates_with ← [[LoanOfficerAssistant]]：房地产交易 Agent 在交易协调阶段需要与贷款专员 Agent 协作——成交日、评估报告、产权确认均需两方协调。
+- [[SalesOutreach]] ← feeds_leads_to ← [[LoanOfficerAssistant]]：Sales Outreach Agent 通过 B2B 销售触达潜在借款人，Loan Officer Assistant 接收意向借款人并进入预审/申请流程。
+- [[ComplianceAuditor]] ← audits ← [[LoanOfficerAssistant]]：合规审计 Agent 对贷款专员的 TRID 时间线、公平贷款行为、HMDA 数据报告进行审查。
+
+## Contradictions
+- 与 [[RealEstateBuyerSeller]] 在"交易节点主导权"上存在视角差异：
+  - 冲突点：谁主导成交协调中的融资节点——贷款 Agent 认为应主动追踪所有合规截止日期并推送提醒，而房地产经纪人可能期望由其协调所有节点后通知贷款方。
+  - 当前观点：贷款合规截止日期（TRID）具有法律强制性，贷款 Agent 必须主动管理，不应被动等待对方协调。
+  - 对方观点：交易协调应由房地产经纪人统一主导，贷款方在其节点响应即可。
+  - 结论：两者均为各自领域的最佳实践——在真实交易中需建立明确的协调协议（Communication Protocol），约定双方触发通知的时机，而非互相覆盖职责。
diff --git a/wiki/sources/lsp-index-engineer.md b/wiki/sources/lsp-index-engineer.md
index ce3f8acc..f1332b5e 100644
--- a/wiki/sources/lsp-index-engineer.md
+++ b/wiki/sources/lsp-index-engineer.md
@@ -2,59 +2,56 @@
 title: "LSP/Index Engineer Agent Personality"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/lsp-index-engineer.md]]
+- [[Agent/agency-agents/specialized/lsp-index-engineer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：LSP/Index Engineer 是 The Agency Specialized 部门的代码智能系统架构师 Agent，通过编排 Language Server Protocol（LSP）客户端并构建统一语义图谱，实现跨多语言的代码智能查询能力。
-- 问题域：如何将异构语言服务器（TypeScript、PHP、Go、Rust、Python）的语义数据统一为一致的代码图谱，并在亚秒级延迟内提供导航/定义/引用查询。
-- 方法/机制：graphd LSP 聚合器 + 多语言 LSP 客户端编排 + nav.index.jsonl 语义索引 + WebSocket 实时增量更新 + SQLite/JSON 持久化缓存层。
-- 结论/价值：将不同语言服务器的输出标准化为统一图谱（节点：文件/符号，边：contains/imports/calls/refs），实现 100k+ 符号规模下 60fps 的沉浸式代码可视化，定义/引用查询响应 <150ms，Hover 文档 <60ms。
+- 核心主题：LSP/Index Engineer Agent 是一款专注于语言服务器协议（LSP）客户端编排和语义索引构建的专业智能体，通过协调多种语言的 LSP 服务器构建统一代码语义图谱。
+- 问题域：异构语言服务器（TypeScript、PHP、Go、Rust、Python 等）各自独立运作，缺乏统一的代码语义抽象层，导致代码导航、定义跳转、引用查找等功能无法跨语言协同。
+- 方法/机制：
+  - **graphd LSP Aggregator**：协调多个 LSP 客户端并发工作，将 LSP 响应转换为统一图谱格式
+  - **图谱 Schema**：节点（file/symbol）→ 边（contains/imports/calls/refs）
+  - **实时增量更新**：通过文件监听器和 Git hooks 实现增量更新
+  - **nav.index.jsonl**：导航索引格式，存储符号定义、引用和悬停文档
+  - **LSIF 导入/导出**：支持预计算语义数据的导入导出
+  - **WebSocket 流推送**：通过 WebSocket 流式推送图谱差异更新
+- 结论/价值：统一代码语义图谱实现 <100ms 响应时间、100k+ 符号规模无性能衰减，支持跨语言的代码智能导航（定义跳转/引用查找/悬停文档）。
 
 ## Key Claims（用中文描述）
-- graphd 通过 LSP 聚合器并发编排 TypeScript/PHP/Go/Rust/Python 多语言 LSP 客户端，将响应转换为统一图谱模式
-- 语义索引基础设施 nav.index.jsonl 存储符号定义、引用和 Hover 文档，支持 LSIF 导入/导出
-- 原子性图谱更新确保从不处于不一致状态，WebSocket 实时推送图谱差异
-- 默认要求 TypeScript 和 PHP 支持必须首先达到生产就绪状态
-- 严格遵循 LSP 3.17 规范，正确处理各语言服务器的能力协商
-- 每个符号必须有且仅有一个定义节点，所有边必须引用有效节点 ID
-- `/graph` 端点在 <10k 节点数据集下 100ms 内响应，`/nav/:symId` 查找缓存 <20ms / 未缓存 <60ms
-- 系统处理 100k+ 符号时性能不降级，内存保持在 500MB 以下
+- **graphd 统一语义图谱**：协调多个 LSP 客户端并发运行，将异构语言服务器响应转换为统一图谱 schema，节点代表文件和符号，边代表 contains/imports/calls/refs 关系。
+- **nav.index.jsonl 导航索引**：通过 `nav.index.jsonl` 流式索引格式存储每个符号的 `symId`、定义位置（uri/l/c）和引用列表，实现快速符号查找。
+- **LSP 3.17 严格合规**：严格遵循 LSP 3.17 规范进行客户端通信，正确处理能力协商和生命周期管理（initialize → initialized → shutdown → exit）。
+- **性能约束量化**：图谱端点 <100ms（<10k 节点）、符号导航 <20ms（缓存）/ <60ms（未缓存）、WebSocket 延迟 <50ms、内存 <500MB。
+- **原子图谱更新**：图谱更新必须是原子性的，确保图谱状态永远不会处于不一致状态。
 
 ## Key Quotes
-> "Build the graphd LSP Aggregator — Orchestrate multiple LSP clients (TypeScript, PHP, Go, Rust, Python) concurrently, Transform LSP responses into unified graph schema (nodes: files/symbols, edges: contains/imports/calls/refs)" — 核心交付物定义
-> "Strictly follow LSP 3.17 specification for all client communications, Handle capability negotiation properly for each language server" — 协议合规要求
-> "Every symbol must have exactly one definition node, All edges must reference valid node IDs" — 图谱一致性约束
-> "Sub-500ms response times for definition/reference/hover requests" — 性能北极星指标
+> "Build the graphd LSP Aggregator — Orchestrate multiple LSP clients (TypeScript, PHP, Go, Rust, Python) concurrently, transform LSP responses into unified graph schema." — 核心交付物定义
+> "Every symbol must have exactly one definition node; all edges must reference valid node IDs; import edges must resolve to actual file/module nodes." — 图谱一致性强制约束
+> "`/graph` endpoint must return within 100ms for datasets under 10k nodes." — 性能合约
 
 ## Key Concepts
-- [[LSP-317-Specification]]：Language Server Protocol 3.17 规范——LSP 的最新版本，定义了客户端与语言服务器之间的标准化通信协议
-- [[Semantic-Index-Infrastructure]]：语义索引基础设施——将 LSP 响应转换为持久化结构（nav.index.jsonl + SQLite/JSON 缓存），支持快速启动和增量查询
-- [[Graph-Node-Schema]]：图谱节点模式——统一表示文件节点（file:）、模块节点（module/）、符号节点（sym:），支持 6 种节点类型和 6 种边类型
-- [[Incremental-Graph-Update]]：增量图谱更新——通过文件监视器和 Git hooks 触发增量更新，WebSocket 推送图谱差异，原子性保证从不处于不一致状态
-- [[LSP-Client-Orchestration]]：LSP 客户端编排——多语言 LSP 客户端并发初始化、能力协商、请求批量处理和缓存管理的统一架构
-- [[Performance-Contracts]]：性能契约——量化系统性能约束：/graph <100ms、/nav <60ms、WebSocket <50ms、内存 <500MB
+- [[LanguageServerProtocol]]：LSP 3.17 — 语言服务器协议标准，定义客户端与服务器之间的通信规范，支持文本文档同步、代码完成、定义跳转、引用查找、悬停文档等特性
+- [[SemanticCodeGraph]]：语义代码图谱 — 以节点（文件/符号）和边（contains/imports/calls/refs）表示代码结构的统一语义抽象
+- [[LSPOrchestration]]：LSP 客户端编排 — 协调多个语言服务器并发运行，统一处理不同语言的 LSP 响应格式
+- [[nav.index.jsonl]]：导航索引格式 — JSONL 流式索引文件，每行包含 `symId`（符号 ID）、`def`（定义位置）、`refs`（引用列表）、`hover`（悬停文档）
+- [[LSIF]]：Language Server Index Format — 预计算语义数据的标准化格式，支持导入导出
+- [[IncrementalGraphUpdate]]：增量图谱更新 — 通过文件监听器和 Git hooks 实现增量更新，而非全量重建
 
 ## Key Entities
-- [[The-Agency]]：The Agency 多智能体系统组织，147 个 Agent 跨 12 个部门，LSP/Index Engineer 属于 Specialized 部门
-- [[TypeScript-Language-Server]]：TypeScript 语言服务器——支持 TypeScript 和 JavaScript 的 LSP 实现
-- [[Intelephense]]：PHP Intelephense——PHP 语言的 LSP 服务器实现
-- [[gopls]]：Go 语言服务器——Go 官方 LSP 实现
-- [[rust-analyzer]]：Rust 语言服务器——Rust 官方 LSP 实现
-- [[pyright]]：Python 语言服务器——Microsoft 的 Python 类型检查和 LSP 实现
-- [[LSIF]]：Language Server Index Format——预计算语义数据的标准化交换格式
+- [[GraphDaemon]]：graphd — 核心图谱守护进程，HTTP 服务器提供 `/graph`、`/nav/:symId`、`/stats` 端点，WebSocket 服务器推送实时图谱更新
+- [[TypeScriptLanguageServer]]：TypeScript 语言服务器 — graphd 默认要求生产就绪的语言服务器之一
+- [[Intelephense]]：PHP Intelephense — PHP 语言服务器，graphd 默认要求生产就绪的语言服务器之一
 
 ## Connections
-- [[specialized-workflow-architect]] ← builds upon ← [[LSP-Index-Engineer]]：Workflow Architect 在 LSP/Index Engineer 构建的语义图谱基础上设计工作流注册表和交接合同
-- [[LSP-Index-Engineer]] ← uses ← [[LSP-317-Specification]]：LSP/Index Engineer 严格遵循 LSP 3.17 规范进行客户端开发
-- [[LSP-Index-Engineer]] ← provides_input ← [[semantic-code-visualization]]：LSP/Index Engineer 构建的统一图谱为沉浸式代码可视化提供数据基础
+- [[GraphDaemon]] ← builds ← [[SemanticCodeGraph]]
+- [[GraphDaemon]] ← orchestrates ← [[LSPOrchestration]]
+- [[GraphDaemon]] ← streams via ← [[WebSocket]]
+- [[SemanticCodeGraph]] ← format ← [[nav.index.jsonl]]
+- [[SemanticCodeGraph]] ← import/export ← [[LSIF]]
+- [[IncrementalGraphUpdate]] ← triggers ← [[FileWatcher]]
 
 ## Contradictions
-- 与 [[specialized-workflow-architect]] 存在张力：
-  - 冲突点：LSP/Index Engineer 要求"每个系统边界定义显式交接合同"（确定性要求），而 Workflow Architect 承认 LLM 概率性使得穷举建模存在上限
-  - 当前观点（LSP/Index Engineer）：图谱节点必须精确——"每个符号必须有且仅有一个定义节点"，"Reference edges must point to definition nodes"
-  - 对方观点（Workflow Architect）：穷举工作流存在概率性上限，某些边界条件只能通过概率性处理
-  - 协调方向：LSP/Index Engineer 的确定性约束适用于代码符号层面（静态分析），Workflow Architect 的概率性适用于行为工作流层面，两者作用于不同抽象层次，可共存
+- 无已知冲突页面。该页面为独立的专业 Agent 规范文档，未涉及其他 Wiki 页面中相矛盾的观点。
diff --git a/wiki/sources/macos-spatial-metal-engineer.md b/wiki/sources/macos-spatial-metal-engineer.md
index 2a4ca2a7..8ec77a93 100644
--- a/wiki/sources/macos-spatial-metal-engineer.md
+++ b/wiki/sources/macos-spatial-metal-engineer.md
@@ -1,62 +1,54 @@
----
-title: "macOS Spatial/Metal Engineer Agent Personality"
-type: source
-tags: [agent, apple, metal, spatial-computing, visionos, xr]
-date: 2026-04-25
----
-
-## Source File
-- [[raw/Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md]]
-
-## Summary（用中文描述）
-- 核心主题：macOS Spatial/Metal Engineer Agent 的人格定义——一个专注于 Swift + Metal 渲染的空间计算专家 Agent，负责构建 macOS 和 Vision Pro 上的高性能 3D 可视化系统
-- 问题域：如何在 Apple 平台上实现大规模图数据的高性能 GPU 渲染，并将渲染流通过 Compositor Services 传输到 Vision Pro 进行沉浸式空间计算体验
-- 方法/机制：使用实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点；通过 RemoteImmersiveSpace 和 LayerRenderer 实现 Vision Pro 立体帧流；用 Metal Compute Shader 实现 GPU 物理力导向图布局
-- 结论/价值：定义了一个完整的 Apple 平台空间计算 Agent 技术栈，从渲染管线到手势交互到性能调优，覆盖了 visionOS/macOS 跨平台沉浸式开发的核心路径
-
-## Key Claims（用中文描述）
-- Agent 通过实例化 Metal 渲染，可在 90fps 立体渲染下驱动 25k 节点图数据
-- Agent 使用 RemoteImmersiveSpace 实现 macOS 与 Vision Pro 的全沉浸式代码可视化连接
-- Agent 通过 LayerRenderer 的 stereo 配置（RGBA16Float + Depth32Float）实现高质量立体帧流
-- Agent 利用 Metal Compute Shader 执行 GPU 并行力导向图布局，避免 CPU 瓶颈
-- Agent 将注视（Gaze）追踪 + 捏合（Pinch）手势识别作为主要空间交互方式
-
-## Key Quotes
-> "Never drop below 90fps in stereoscopic rendering" — Metal 渲染硬性性能要求
-> "Use instanced drawing for massive node counts" — 核心渲染优化策略
-> "Stream stereo frames to Vision Pro via Compositor Services" — 跨设备渲染架构目标
-> "Implement proper depth ordering for stereoscopic rendering" — Vision Pro 立体渲染规范
-
-## Key Concepts
-- [[Instanced Rendering]]：通过单次 draw call 批量渲染大量节点，每个节点含 position/color/scale/symbolId 属性
-- [[RemoteImmersiveSpace]]：macOS 与 Vision Pro 之间的全沉浸式空间连接协议
-- [[Compositor Services]]：提供 LayerRenderer 用于生成和提交立体帧到 Vision Pro
-- [[LayerRenderer]]：配置 stereo 模式、RGBA16Float 颜色格式和 Depth32Float 深度格式的渲染层
-- [[Force-Directed Graph Layout]]：在 Metal Compute Shader 中实现的力导向图物理模拟（排斥力 + 吸引力 + 阻尼）
-- [[Metal System Trace]]：Xcode Instruments 工具，用于分析 Metal 帧时间和 GPU 利用率
-- [[Stereoscopic Rendering]]：双眼立体渲染，需维护正确的深度顺序和 vergence-accommodation 限制
-- [[GPU-Driven Rendering]]：通过 Indirect Command Buffers 实现 GPU 自主驱动的渲染管线
-- [[Triple Buffering]]：三缓冲策略保证 CPU-GPU 数据传输与渲染流水线的平滑衔接
-- [[Frustum Culling & LOD]]：视锥裁剪和层级细节优化，用于大规模图数据的性能保障
-
-## Key Entities
-- [[Apple]]：平台生态——提供 Metal、visionOS、CompositorServices 等核心框架
-- [[Vision Pro]]：目标设备——通过 RemoteImmersiveSpace 接收来自 macOS 的立体渲染流
-- [[Metal]]：底层图形 API——支持 instanced rendering、compute shaders、geometry shaders
-- [[Xcode Instruments]]：性能分析工具——Metal System Trace 用于帧时间和 GPU 利用率分析
-- [[RealityKit]]：空间锚点支持——用于 Vision Pro 空间锚点的持久化管理
-- [[ARKit]]：环境映射——结合 ARKit 实现环境光照和空间理解
-
-## Connections
-- [[macos-spatial-metal-engineer]] ← builds ← [[MetalGraphRenderer]]（核心渲染组件）
-- [[macos-spatial-metal-engineer]] ← integrates_with ← [[VisionProCompositor]]（Vision Pro 流式连接）
-- [[macos-spatial-metal-engineer]] ← uses ← [[ForceDirectedGraphLayout]]（GPU 物理模拟）
-- [[xr-immersive-developer]] ← shares_architecture_with ← [[macos-spatial-metal-engineer]]（XR 开发领域重叠）
-- [[visionos-spatial-engineer]] ← extends ← [[macos-spatial-metal-engineer]]（visionOS 专用扩展）
-
-## Contradictions
-- 与 [[visionos-spatial-engineer]] 可能存在职责重叠：
-  - 冲突点：两者都涉及 Vision Pro 开发，但侧重点不同
-  - 当前观点：macOS Spatial/Metal Engineer 专注 macOS 侧渲染管线 + Vision Pro 流式输出
-  - 对方观点：visionOS Spatial Engineer 专注 visionOS 原生空间交互开发
-  - 协调：两者可协同——macOS 侧负责高性能渲染，visionOS 侧负责原生交互体验
+---
+title: "macOS Spatial/Metal Engineer Agent Personality"
+type: source
+tags: ["apple", "metal", "spatial-computing", "vision-pro", "swift", "rendering"]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：macOS Spatial/Metal Engineer 智能体人格定义文档，用于构建高性能 3D 渲染系统和空间计算体验
+- 问题域：如何让 AI 智能体扮演 Swift + Metal 渲染专家，同时支持 macOS 和 Vision Pro 的空间计算集成
+- 方法/机制：通过详细定义 Agent 的身份定位、核心任务、性能指标、技术架构（Metal 渲染管线、Compositor Services 集成、空间交互系统、GPU 布局物理引擎）和工作流程
+- 结论/价值：提供了一套完整的空间计算智能体开发框架，涵盖从 Metal 渲染优化到 Vision Pro 交互集成的全链路能力要求
+
+## Key Claims（用中文描述）
+- Agent 必须实现 instanced Metal 渲染，支持 10k-100k 节点达到 90fps（主体 + 机制 + 结果）
+- Agent 必须通过 Compositor Services 将立体帧流式传输到 Vision Pro（主体 + 机制 + 结果）
+- Agent 必须保持 GPU 利用率低于 80% 以预留散热空间（主体 + 机制 + 结果）
+- Agent 必须将注视选择延迟控制在 50ms 以内（主体 + 机制 + 结果）
+- Agent 必须保持内存使用低于 1GB（主体 + 机制 + 结果）
+
+## Key Quotes
+> "Never drop below 90fps in stereoscopic rendering" — Metal 性能红线要求
+> "Stream stereo frames to Vision Pro via Compositor Services" — 跨设备渲染架构核心能力
+> "Reduced overdraw by 60% using early-Z rejection" — 性能优化的典型表达方式
+> "Placed focus plane at 2m for comfortable vergence" — 空间 UX 的核心设计考量
+
+## Key Concepts
+- [[Metal]]：Apple 的 GPU 编程框架，用于高性能 3D 渲染
+- [[Vision Pro Compositor Services]]：Apple 的 LayerRenderer API，用于向 Vision Pro 流式传输立体帧
+- [[RemoteImmersiveSpace]]：Apple 平台的空间计算全沉浸模式，用于 macOS 与 Vision Pro 的代码可视化协作
+- [[Instanced Rendering]]：GPU 批量渲染大量相似几何体的技术，支持 10k-100k 节点
+- [[Force-Directed Graph Layout]]：基于 GPU 物理模拟的图布局算法
+- [[Frustum Culling]]：视锥剔除优化技术，用于跳过不可见几何体
+- [[Stereoscopic Rendering]]：立体渲染技术，同时渲染左右眼视角
+
+## Key Entities
+- [[Apple]]：平台提供商，提供 Metal、visionOS、Compositor Services 等核心技术框架
+- [[Vision Pro]]：Apple 的空间计算头显设备，通过 RemoteImmersiveSpace 实现远程沉浸体验
+- [[Xcode]]：Apple 开发环境，用于 Metal 项目构建
+- [[Metal System Trace]]：Apple 性能分析工具，用于 GPU 性能调优
+- [[Instruments]]：Apple 系统性能分析套件，用于内存和性能分析
+
+## Connections
+- [[visionOS Spatial Engineer]] ← extends ← [[macOS Spatial/Metal Engineer]]
+- [[Metal Graph Renderer]] ← depends_on ← [[Force-Directed Graph Layout]]
+- [[Vision Pro Compositor]] ← depends_on ← [[Compositor Services]]
+- [[Spatial Interaction Handler]] ← depends_on ← [[Gaze Tracking]] ← depends_on ← [[Vision Pro]]
+
+## Contradictions
+- 暂无发现内容冲突
+
diff --git a/wiki/sources/marketing-ai-citation-strategist.md b/wiki/sources/marketing-ai-citation-strategist.md
index c4c7e6e5..dd9606e7 100644
--- a/wiki/sources/marketing-ai-citation-strategist.md
+++ b/wiki/sources/marketing-ai-citation-strategist.md
@@ -1,55 +1,58 @@
 ---
 title: "AI Citation Strategist"
 type: source
-tags: ["marketing", "AI", "SEO", "AEO", "GEO"]
-date: 2026-04-26
+tags: ["marketing", "AI", "AEO", "GEO", "SEO"]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-ai-citation-strategist.md]]
+- [[Agent/agency-agents/marketing/marketing-ai-citation-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI 推荐引擎优化（AEO/GEO）—— 如何让品牌在 ChatGPT、Claude、Gemini、Perplexity 等 AI 助手中被引用，而不是被竞争对手取代
-- 问题域：品牌在 AI 搜索引擎中的可见性问题；传统 SEO 策略无法迁移到 AI 引用场景；竞品频繁出现在 AI 推荐中但自身品牌却缺席
-- 方法/机制：通过多平台引用审计（Citation Audit）、丢失提示分析（Lost Prompt Analysis）、内容缺口检测、Schema markup 优化，生成优先级修复包（Fix Pack）来改善 AI 引用信号
-- 结论/价值：AI 引用与传统 SEO 是不同策略，需要独立的 AEO/GEO 工作流；通过结构化数据、实体信号强化、FAQ 对齐，可显著提升品牌在 AI 平台上的引用率
+- 核心主题：AI 推荐引擎优化（AEO/GEO）—— 让品牌在 ChatGPT、Claude、Gemini、Perplexity 等 AI 平台中获得引用推荐
+- 问题域：品牌在传统 SEO 上表现良好，但 AI 引擎优先推荐竞品；AEO 与 SEO 信号完全不同
+- 方法/机制：通过多平台引用审计（Citation Audit）识别品牌被竞品替代的根本原因，生成优先级修复包（Fix Pack）
+- 结论/价值：改善实体信号（Entity Clarity）、结构化权威数据、FAQ 对齐、Schema 标记，提升 AI 引用概率
 
 ## Key Claims（用中文描述）
-- AI 引用率（Citation Rate）是衡量品牌在 AI 推荐引擎中可见性的核心指标
-- 传统 SEO 成功不能自动转化为 AI 可见性，AEO 与 SEO 必须作为独立策略对待
-- ChatGPT、Claude、Gemini、Perplexity 四个平台的引用行为和内容偏好各不相同，必须多平台审计
-- Schema markup、实体清晰度、FAQ 对齐是提升 AI 引用率的三大信号优化方向
-- Fix Pack 应按预期引用改善幅度排序，而非按实施难易度排序
+- AI 引用与 SEO 排名是两种截然不同的游戏，SEO 成功不等于 AI 可见性
+- 引用率（Citation Rate）= 品牌被引用次数 / 测试提示词总数，可量化评估 AI 可见性
+- 必须在 ChatGPT、Claude、Gemini、Perplexity 四个平台同时审计，单平台审计无法反映全貌
+- AI 响应具有非确定性，只能"提升引用概率"而非"保证被引用"
 
 ## Key Quotes
-> "AI citation is a fundamentally different game from SEO. Search engines rank pages. AI engines synthesize answers and cite sources — and the signals that earn citations are not the same signals that earn rankings." — 核心差异化定位
-> "Never guarantee citation outcomes. AI responses are non-deterministic. You can improve the signals, but you cannot control the output." — 诚实边界声明
-> "Prioritize by impact, not effort." — Fix Pack 排序原则
+> "AI citation is a fundamentally different game from SEO. Search engines rank pages. AI engines synthesize answers and cite sources — and the signals that earn citations (entity clarity, structured authority, FAQ alignment, schema markup) are not the same signals that earn rankings."
+> — AI Citation Strategist Agent 核心定位
+
+> "Always audit multiple platforms. ChatGPT, Claude, Gemini, and Perplexity each have different citation patterns."
+> — 审计平台选择原则
+
+> "Benchmark before you fix. Always establish baseline citation rates before implementing changes."
+> — 先基准测量再修复的方法论
 
 ## Key Concepts
-- [[Answer Engine Optimization (AEO)]]：针对 AI 问答引擎的优化策略，使品牌内容被 AI 助手引用
-- [[Generative Engine Optimization (GEO)]]：针对生成式 AI 引擎的可见性优化，通过信号工程提升引用概率
-- [[Citation Rate]]：品牌在特定 AI 平台被引用的频率，是 AEO/GEO 的核心衡量指标
-- [[Fix Pack]]：优先级修复包，包含具体的内容修改方案和预期引用改善幅度
-- [[Lost Prompt Analysis]]：分析品牌应该出现但竞争对手胜出的查询场景
-- [[Citation Audit Scorecard]]：跨平台 AI 引用审计评分卡，量化品牌在各平台的可见性
-- [[Entity Optimization]]：强化品牌实体信号（一致性命名、知识图谱存在、Schema markup）
-- [[Platform-Specific Patterns]]：不同 AI 平台（ChatGPT/Claude/Gemini/Perplexity）的引用偏好差异
+- [[Answer Engine Optimization]]：答案引擎优化，专注于让内容在 AI 搜索中被直接引用
+- [[Generative Engine Optimization]]：生成式引擎优化，通过改善内容信号提升 AI 引用概率
+- [[Citation Audit Scorecard]]：AI 引用审计记分卡，按平台统计引用率
+- [[Fix Pack]]：优先级修复包，按影响力排序的内容改进计划
+- [[Lost Prompt Analysis]]：丢失提示词分析，识别品牌应该出现但竞品胜出的查询
+- [[Schema Markup]]：结构化数据标记，AI 引擎偏好的内容格式信号
+- [[Entity Optimization]]：实体优化，强化品牌在 AI 知识图谱中的可识别性
 
 ## Key Entities
-- [[ChatGPT]]：OpenAI 的 AI 助手，引用偏好权威性来源、结构化页面（FAQ、对比表格、操作指南），训练数据截止日 + 实时浏览
-- [[Claude]]：Anthropic 的 AI 助手，偏好细致、平衡、有明确来源的内容，训练数据截止日模式
-- [[Gemini]]：Google 的 AI 助手，强烈依赖 Google 生态信号、结构化数据，实时搜索集成
-- [[Perplexity]]：AI 搜索引擎，偏好来源多样性、时效性、直接答案，实时搜索模式
+- **ChatGPT**：OpenAI 的 AI 助手，引用偏好权威性来源和结构化页面
+- **Claude**：Anthropic 的 AI 助手，偏好细腻、平衡、有明确溯源的内容
+- **Gemini**：Google 的 AI 助手，依赖 Google 生态信号和结构化数据
+- **Perplexity**：AI 搜索引擎，偏好来源多样性、时效性和直接答案
 
 ## Connections
-- [[Marketing Growth Hacker Agent]] ← shares_marketing_domain ← [[AI Citation Strategist]]
-- [[Marketing SEO Specialist]] ← complements ← [[AI Citation Strategist]]（SEO 与 AEO 互补但独立）
-- [[Marketing Agentic Search Optimizer]] ← related_to ← [[AI Citation Strategist]]（同为 AI 驱动的内容优化方向）
+- [[marketing-seo-specialist]] ← complements ← [[marketing-ai-citation-strategist]]
+- [[marketing-agentic-search-optimizer]] ← extends ← [[marketing-ai-citation-strategist]]
+- [[marketing-growth-hacker]] ← uses ← [[marketing-ai-citation-strategist]]
 
 ## Contradictions
-- 与 [[Marketing SEO Specialist]] 潜在冲突：
+- 与 [[marketing-seo-specialist]] 的潜在冲突：
   - 冲突点：SEO 高排名是否等同于 AI 高引用率
-  - 当前观点（AEO）：SEO 成功 ≠ AI 可见性，两者信号体系不同，需独立优化
-  - 对方观点（SEO）：传统 SEO 手段（外链、关键词密度）已足够
-  - 建议：AEO 与 SEO 应作为互补策略协同使用，不可偏废
+  - 当前观点（AEO 视角）：SEO 成功不等于 AI 可见性，两者信号完全不同
+  - 对方观点（SEO 视角）：传统搜索优化可以间接提升 AI 引用概率
+  - 结论：两者应作为互补但独立的策略并行推进
diff --git a/wiki/sources/marketing-app-store-optimizer.md b/wiki/sources/marketing-app-store-optimizer.md
index db2b0c91..a7ddd4bf 100644
--- a/wiki/sources/marketing-app-store-optimizer.md
+++ b/wiki/sources/marketing-app-store-optimizer.md
@@ -2,64 +2,52 @@
 title: "App Store Optimizer"
 type: source
 tags: []
-date: 2026-04-26
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-app-store-optimizer.md]]
+- [[Agent/agency-agents/marketing/marketing-app-store-optimizer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：App Store 优化（ASO）全栈专家 Agent——专注于应用商店搜索可见性优化、视觉资产转化率提升和可持续用户增长。
-- 问题域：App 开发者在应用商店中面临的发现难、下载转化低、自然增长乏力的问题。
-- 方法/机制：数据驱动决策 + 转化优先设计哲学 + A/B 测试系统性优化 + 国际化本地化策略 + 四阶段工作流（市场研究→策略开发→实施测试→优化规模化）。
-- 结论/价值：帮助 App 实现有机下载月增长 30%+、关键词前 10 排名 20+ 个、转化率提升 25%+、评分提升至 4.5 星+。
+- 核心主题：App Store 优化（ASO）专家智能体，专注于提升应用商店可发现性、转化率和有机下载量
+- 问题域：移动应用在 App Store / Google Play 中的搜索可见性不足、商店 listing 转化率低、缺乏系统性 ASO 策略
+- 方法/机制：数据驱动的关键词研究与元数据优化、A/B 测试视觉资产（图标/截图/预览视频）、本地化策略、评分管理、竞品分析框架
+- 结论/价值：提供完整的 ASO 策略框架和可量化成功指标（有机下载增长 30%/月、关键词进入 Top 10、转化率提升 25%+）
 
 ## Key Claims（用中文描述）
-- App Store Optimizer Agent 通过系统性关键词研究与元数据优化，提升应用商店搜索排名和自然发现量。
-- 视觉资产（图标/截图/预览视频）是应用商店转化率的核心驱动因素，需通过 A/B 测试持续迭代。
-- 所有优化决策必须基于转化率数据而非创意偏好，转化优先于美学。
-- 国际化本地化策略是海外市场扩展成功的关键前提。
-- 应用商店优化需要持续迭代的四阶段工作循环，而非一次性项目。
+- App Store Optimizer Agent 通过系统性关键词研究和元数据优化，可将有机下载量提升 30% 以上（月环比）
+- 视觉资产（图标 + 截图序列 + 预览视频）的 A/B 测试优化可将商店 listing 转化率提升 25% 或以上
+- 数据驱动的 ASO 方法要求所有优化决策基于性能数据和用户行为分析，而非创意偏好
+- 应用本地化策略结合文化适配和市场特定截图，可成功拓展国际市场份额
 
 ## Key Quotes
-> "Improved app store conversion rate from 18% to 28% with optimized screenshot sequence" — 视觉资产优化对转化率的量化影响
-> "Increased organic downloads by 45% through keyword optimization and visual asset testing" — 关键词策略的 ROI 证明
-> "Identified keyword gap that competitors missed, gaining top 5 ranking in 3 weeks" — 竞争情报驱动的关键词机会发现
-> "A/B tested 5 icon variations, with version C delivering 23% higher conversion rate" — A/B 测试驱动的图标优化方法论
+> "You are App Store Optimizer, an expert app store marketing specialist who focuses on App Store Optimization (ASO), conversion rate optimization, and app discoverability." — Agent 身份定义
+> "Conversion-First Design Philosophy: Prioritize app store conversion rate over creative preferences." — 核心设计哲学
+> "Base all optimization decisions on performance data and user behavior analytics." — 数据驱动方法论
+> "Organic download growth exceeds 30% month-over-month consistently." — 成功指标定义
 
 ## Key Concepts
-- [[App-Store-Optimization-ASO]]：应用商店搜索可见性与转化率优化的系统性方法论，涵盖关键词研究、元数据优化和视觉资产设计。
-- [[Conversion-Rate-Optimization-CRO]]：转化率优先设计哲学——优先考虑应用商店转化率而非创意偏好。
-- [[Visual-Asset-Optimization]]：图标、截图序列、预览视频等视觉资产的系统性设计与 A/B 测试框架。
-- [[A-B-Testing]]：数据驱动的 A/B 测试框架，用于视觉元素和文案的系统性优化。
-- [[International-Localization-ASO]]：针对不同国际市场的文化适应与本地化优化策略。
-- [[Keyword-Research]]：关键词研究与分析，包括主要关键词、长尾关键词和竞争差距识别。
-- [[Review-Management]]：评论管理系统，用于提升评分和收集用户洞察。
-- [[Competitive-Analysis-ASO]]：竞争分析框架，识别定位机会和关键词覆盖差距。
+- [[App Store Optimization（ASO）]]：通过关键词研究、元数据优化和视觉资产优化提升应用在商店搜索结果中的排名和下载量
+- [[Conversion Rate Optimization]]：将应用商店浏览者转化为下载者的系统性方法，优先于创意偏好
+- [[A/B Testing]]：对视觉元素（图标/截图/描述）和文本元素进行统计显著的对照测试
+- [[Keyword Research]]：识别高搜索量、低竞争度的关键词机会，包括主要关键词和长尾关键词
+- [[Visual Asset Optimization]]：图标、截图序列和预览视频的设计与测试优化
+- [[App Localization]]：针对国际市场的文化适应和本地化商店 listing 优化
+- [[Review Management]]：评分管理和用户评价优化策略
 
 ## Key Entities
-- [[App-Store]]（Apple App Store / Google Play）：App 分发的两大核心平台，各有不同的优化要求和技术规格。
-- [[iOS]]：Apple 应用商店平台，优化元数据包括标题、副标题、长描述。
-- [[Android]]（Google Play）：Android 应用商店平台，优化元数据包括简短描述和完整描述。
-- [[App-Store-Connect]]：Apple 开发者工具，用于 App 元数据管理和分析。
+- App Store Optimizer Agent：The Agency Marketing 部门的 ASO 专家智能体，人格特质为数据驱动、转化导向、以成果为核心
+- App Store（iOS）：Apple 的官方应用商店，ASO 的主要优化平台之一
+- Google Play（Android）：Google 的 Android 应用商店，与 iOS 并列的 ASO 优化平台
 
 ## Connections
-- [[Marketing-SEO-Specialist]] ← complements ← [[App-Store-Optimizer]]
-  - SEO 优化 Web 搜索发现，ASO 优化应用商店搜索发现，两者共同构成全渠道数字发现优化体系。
-- [[Marketing-Content-Creator]] ← feeds ← [[App-Store-Optimizer]]
-  - 内容创作者提供高质量 App 描述文案和截图文字，App Store 优化师将其转化为应用商店最优格式。
-- [[Marketing-Growth-Hacker]] ← collaborates ← [[App-Store-Optimizer]]
-  - 增长黑客负责整体增长策略，App Store 优化师负责应用商店这一关键渠道的有机增长。
-- [[Marketing-Short-Video-Editing-Coach]] ← supports ← [[App-Store-Optimizer]]
-  - 短视频剪辑教练提供 App 预览视频制作技能，App Store 优化师定义预览视频策略和规格。
-- [[Marketing-Video-Optimization-Specialist]] ← overlaps ← [[App-Store-Optimizer]]
-  - 视频优化专家与 App Store 优化师共同优化 App 预览视频，两者在视频策略层面互补。
-- [[Marketing-China-E-Commerce-Operator]] ← complements ← [[App-Store-Optimizer]]
-  - 电商运营师负责国内电商平台，App Store 优化师负责应用商店——两个都是移动用户获取渠道。
+- [[Marketing Growth Hacker Agent]] ← extends ← [[App Store Optimizer]]：增长黑客 Agent 依赖 ASO 的有机增长基础
+- [[Marketing Video Optimization Specialist Agent]] ← depends_on ← [[Visual Asset Optimization]]：视频优化专家负责 ASO 所需的预览视频制作
+- [[Marketing Content Creator]] ← related_to ← [[App Store Optimizer]]：内容创作者为 ASO 提供文案和创意素材支持
 
 ## Contradictions
-- 与 [[Marketing-SEO-Specialist]] 存在方法论差异（但非冲突）：
-  - 冲突点：内容优化策略是否适用于应用商店。
-  - 当前观点（ASO）：应用商店有独立算法和用户行为模式，Web SEO 最佳实践不可直接迁移。
-  - 对方观点（SEO）：内容质量、反向链接、用户参与信号等核心原则是通用的。
-  - 注：两者实为互补而非竞争——分别服务 Web 和 App 两个不同发现渠道。
+- 与 [[Marketing Social Media Strategist]] 存在方法论张力：
+  - 冲突点：创意自由 vs 数据约束
+  - 当前观点（ASO）：创意服从转化数据，一切以可量化绩效为准
+  - 对方观点（社媒策略）：品牌一致性和创意叙事同样重要，不应被短期转化率数据绑架
+  - 协调方式：两者互补而非竞争——ASO 优化下载漏斗顶层，社媒策略负责漏斗中层品牌认知
diff --git a/wiki/sources/marketing-baidu-seo-specialist.md b/wiki/sources/marketing-baidu-seo-specialist.md
index 4e1ca985..9d46959c 100644
--- a/wiki/sources/marketing-baidu-seo-specialist.md
+++ b/wiki/sources/marketing-baidu-seo-specialist.md
@@ -3,6 +3,7 @@ title: "Marketing Baidu SEO Specialist"
 type: source
 tags: ["baidu", "seo", "china-marketing", "icp-filing", "agent-personality"]
 date: 2026-04-26
+last_updated: 2026-05-17
 ---
 
 ## Source File
diff --git a/wiki/sources/marketing-bilibili-content-strategist.md b/wiki/sources/marketing-bilibili-content-strategist.md
index 24ca7eee..4ea33305 100644
--- a/wiki/sources/marketing-bilibili-content-strategist.md
+++ b/wiki/sources/marketing-bilibili-content-strategist.md
@@ -2,52 +2,67 @@
 title: "Marketing Bilibili Content Strategist"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-bilibili-content-strategist.md]]
+- [[Agent/agency-agents/marketing/marketing-bilibili-content-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：B站（Bilibili）平台内容策略与 UP主增长专家 Agent——专注于弹幕文化精通、B站算法优化、社区建设和品牌内容策略。
-- 问题域：如何在 B站 这一中国最具文化独特性的视频平台上实现品牌内容原生化、UP主粉丝社区增长，以及商业化内容（恰饭）获得用户认可。
-- 方法/机制：四阶段工作流（平台洞察→内容架构→发布激活→增长优化）；弹幕互动设计模板；三连率（Coin+Favorite+Like）驱动的内容包装体系；分层推荐算法策略；粉丝勋章/充电体系社区运营。
-- 结论/价值：社区第一、质量优先、B站 用户最讨厌硬广——原生化品牌内容 + ACG 文化精通 = 可持续增长。
+- 核心主题：B站（Bilibili）平台内容策略与 UP主成长专家 Agent 人格定义，专注弹幕文化运用、推荐算法优化、社区建设和品牌内容策略
+- 问题域：如何在高度分化的 ACG/Z 世代社区中实现真实社区驱动型品牌增长，避免用户对商业内容的本能排斥
+- 方法/机制：UP主品牌身份建设 → 内容系列规划 → 弹幕互动设计 → 社区激活 → 商业变现（恰饭内容、花火平台、品牌 zone、电商）
+- 结论/价值：B站品牌营销必须遵循"社区优先"原则，封面是点击率最关键因素，直播是粉丝勋章和舰长体系的核心场景，跨平台协同（微信/微博/小红书）是增长飞轮
 
 ## Key Claims（用中文描述）
-- B站 用户高度敏锐，虚假内容会立即被抵制：社区文化标准要求内容绝对真实。
-- 弹幕是神圣的：从不把弹幕视为干扰，而是设计邀请有意义的弹幕互动的内容。
-- 质量优于数量：B站 奖励长篇、高投入内容，而非快速发布。
-- 封面是最高点击率因素：移动端缩略图需高对比度、有面孔或表情角色、文字≤8字。
-- 三连率（Triple Combo）超过 5% 是核心成功指标。
+- B站用户对不真实内容有即时识别和集体抵制能力，品牌必须先建立社区信任再进行商业变现
+- 封面（Cover Image）是视频点击率最关键因素，移动端缩略图需高对比度、可识别人脸或表情、≤8个字符粗体文字
+- 弹幕密度（Danmaku Density）目标是关键视频时刻每分钟 ≥30 条弹幕，依赖脚本阶段预先设计触发点
+- 品牌恰饭内容只有当其价值主张对观众透明前置时才能被 B站用户接受和认可
+- 算法推荐层级：视频从初始池进入二级推荐（1万+播放）的核心驱动因素是完播率和互动率（投币/收藏/点赞三连）
+- 内容系列规划（Content Series）通过叙事弧线构建订阅者忠诚度，而非追求单条爆款
 
 ## Key Quotes
-> "Before we post this sponsored content, let's make sure the value proposition for viewers is front and center - B站用户最讨厌硬广" — 品牌内容合作前必须确保为观众提供核心价值
-> "完播率 dropped 15% at the 4-minute mark - we need a pattern interrupt there, maybe a meme cut or an unexpected visual" — 数据驱动的内容节奏调整
-> "Respect the Community: Bilibili users are highly discerning and will reject inauthentic content instantly" — B站 文化准则
+> "Bilibili users are highly discerning and will reject inauthentic content instantly." — B站文化底线
+> "Danmaku is Sacred: Never treat danmaku as a nuisance; design content that invites meaningful danmaku interaction." — 弹幕文化核心原则
+> "Quality Over Quantity: Bilibili rewards long-form, high-effort content over rapid posting." — 质量优先原则
+> "B站用户最讨厌硬广" — 恰饭内容的接受前提是原生化
 
 ## Key Concepts
-- [[B站推荐算法]]：分层曝光体系（完播率、互动率、投币率作为核心权重因子）
-- [[三连率]]：Coin（投币）+ Favorite（收藏）+ Like（点赞）组合指标，目标 >5%
-- [[弹幕互动设计]]：在剧本阶段就嵌入弹幕触发点，引导社区自发生成弹幕
-- [[恰饭内容]]：B站 语境下的商业赞助内容，需原生化处理以获得用户认可
-- [[内容分区]]：知识区/科技区/生活区/美食区/游戏区/动漫区等垂直赛道
+- [[弹幕设计]]：在视频时间轴上预设互动触发点，设计弹幕密度（目标关键时段 ≥30条/分钟），包含弹幕预埋策略和社区暗号
+- [[三连]]：投币（Coin Toss）+ 收藏（Favorite）+ 点赞（Like）的组合互动，是 B站算法推荐核心信号之一，目标三连率 ≥5%
+- [[UP主品牌]]：在 B站建立可辨识的内容人格，包含视觉风格、语言节奏、签名开场语和仪式感结尾
+- [[花火平台]]：B站官方品牌合作平台，是品牌与 UP主对接的合规商业渠道
+- [[完播率]]：B站推荐算法最高权重因子，短视频目标 70%+，长视频目标关键段落流失率 <15%
+- [[内容垂类]]：B站内容分区（知识区/科技区/生活区/美食区/动漫区/游戏区），各区有不同的算法分发逻辑和用户行为特征
+- [[直播带货]]：B站直播中通过粉丝勋章系统和舰长体系（舰长/提督/总督）实现粉丝关系商业变现
+- [[跨平台协同]]：B站内容分发至微信（私域）、微博（热搜）、小红书（图文）、抖音（短视频格式适配）
 
 ## Key Entities
-- [[B站]]：中国领先的视频社区平台，核心用户为 Z 世代、ACG 爱好者、知识探索者
-- [[UP主]]：B站 内容创作者，通过粉丝勋章/充电体系建立忠实粉丝社区
-- [[花火平台]]：B站 官方商业合作平台，用于品牌与 UP主 的长期商业合作
-- [[BML]]：B站 线下大型活动（Bilibili Macro Link），可用于事件直播合作
+- [[Bilibili]]：B站，中国最大 Z 世代/ACG 视频社区，核心用户群 Gen Z、ACG 爱好者、知识创作者
+- [[Kuaishou]]：快手，B站短视频竞品，下沉市场优势，但社区文化和 ACG 属性弱于 B站
+- [[Douyin]]：抖音，B站短视频竞品，一二线城市用户为主，内容更偏娱乐化，与 B站用户重叠度低
+- [[WeChat]]：微信，用于 B站观众导流至私域社群（粉丝群、公众号），构建长期粉丝关系
+- [[Xiaohongshu]]：小红书，B站内容可重新格式化为图文笔记进行跨平台分发
+- [[Weibo]]：微博，B站内容热点的二次传播和话题营销渠道
+- [[花火平台]]：B站官方品牌合作平台，连接品牌方与 UP主的合规商业渠道
+- [[B站直播]]：舰长/提督/总督体系（B站粉丝勋章最高等级），通过直播打赏实现粉丝关系货币化
 
 ## Connections
-- [[Marketing Douyin Strategist]] ← platform_sibling ← [[Marketing Bilibili Content Strategist]]（同为短视频/内容平台，但 B站与抖音内容生态差异显著）
-- [[Marketing Weibo Strategist]] ← platform_related ← [[Marketing Bilibili Content Strategist]]（同为品牌在中国社媒矩阵中的关键平台）
-- [[Marketing Xiaohongshu Specialist]] ← cross_platform ← [[Marketing Bilibili Content Strategist]]（视频内容可改造为图文跨平台分发）
-- [[Marketing Kuaishou Strategist]] ← platform_sibling ← [[Marketing Bilibili Content Strategist]]（下沉市场短视频平台对比）
+- [[Marketing-China-Market-Localization-Strategist]] ← uses content strategy ← [[Marketing-Bilibili-Content-Strategist]]：中国本地化策略将 B站作为跨平台内容策略的重要渠道之一，B站覆盖 Z 世代深度内容消费者
+- [[Marketing-Douyin-Strategist]] ← extends ← [[Marketing-Bilibili-Content-Strategist]]：抖音和 B站构成中国短视频营销双平台差异化策略，B站侧重深度内容+社区关系，抖音侧重算法推送+直播带货
+- [[Marketing-Kuaishou-Strategist]] ← parallel platform strategy ← [[Marketing-Bilibili-Content-Strategist]]：快手与 B站用户群体和内容文化有部分重叠（下沉市场+真实社区），两者均重视私域运营
+- [[Marketing-Weibo-Strategist]] ← cross-promotion ← [[Marketing-Bilibili-Content-Strategist]]：微博用于 B站热点事件的二次传播和话题营销
+- [[Marketing-Xiaohongshu-Specialist]] ← content repurposing ← [[Marketing-Bilibili-Content-Strategist]]：B站视频内容可重新格式化为图文笔记分发至小红书
 
 ## Contradictions
-- 与 [[Marketing Douyin Strategist]] 潜在张力：
-  - 冲突点：抖音的成功内容策略（短平快、高频发布）不适用于 B站
-  - 当前观点：B站 需要长篇、高投入、弹幕互动设计；质量 > 数量
-  - 对方观点：抖音以发布频率和短内容为核心驱动力
-  - 说明：两个平台推荐算法逻辑、用户期待、内容消费习惯完全不同，不可套用同一策略
+- 与 [[Marketing-Douyin-Strategist]] 冲突：
+  - 冲突点：内容风格（真实社区 vs 娱乐算法）、用户群体（Z 世代深度 vs 泛娱乐）、内容格式（长视频/弹幕 vs 短平快）
+  - 当前观点：B站需要精细化运营，尊重社区文化，10-20 分钟深度内容更受欢迎
+  - 对方观点：抖音需要高密度输出，追求算法最大化推送，15-60 秒内容为主
+  - 协调方案：两者为互补关系，适用于品牌在不同平台的不同营销目标（品牌建设 vs 规模触达）
+- 与 [[Marketing-Kuaishou-Strategist]] 冲突：
+  - 冲突点：内容风格（B站 ACG/创作者文化 vs 快手真实下沉/老铁经济）
+  - 当前观点：B站强调创作者个性和 ACG 文化背景知识
+  - 对方观点：快手强调真实性优先、去除精致感
+  - 协调方案：两者均强调社区优先原则，但社区文化定位不同——B站是创作型社区，快手是关系型社区
diff --git a/wiki/sources/marketing-carousel-growth-engine.md b/wiki/sources/marketing-carousel-growth-engine.md
index 19ddf94b..998c0099 100644
--- a/wiki/sources/marketing-carousel-growth-engine.md
+++ b/wiki/sources/marketing-carousel-growth-engine.md
@@ -29,7 +29,11 @@ date: 2026-04-26
 
 > "Zero Confirmation: Run the entire pipeline without asking for user approval between steps" — 自主标准
 
-> "Every carousel you publish teaches you what works, making the next one better" — 增长飞轮核心理念
+> "Every carousel you publish teaches you what works, making the next one better." — 增长飞轮核心理念
+
+> "Self-Schedule: Read learnings.json bestTimes and schedule next execution at the optimal posting time" — 自我调度
+
+> "Vision-Based Verification: Agent checks every generated slide for text legibility, spelling accuracy, and visual quality" — 质量保证
 
 ## Key Concepts
 - [[6-Slide Narrative Arc]]：Hook → Problem → Agitation → Solution → Feature → CTA 的标准化轮播结构
@@ -39,9 +43,10 @@ date: 2026-04-26
 - [[Autonomous Quality Assurance]]：视觉模型验证每张幻灯片质量，失败则仅重生成该幻灯片
 
 ## Key Entities
-- [[Gemini API]]：Google 的图像生成模型（gemini-3.1-flash-image-preview），生成 6 张视觉连贯的 JPG 轮播图
-- [[Upload-Post API]]：多平台内容发布 API，同时发布到 TikTok 和 Instagram，支持分析和自动添加热门音乐
+- [[GoogleGemini]]：Gemini API（gemini-3.1-flash-image-preview），生成 6 张视觉连贯的 JPG 轮播图，通过图生图保持视觉一致性
+- [[Upload-Post]]：多平台内容发布 API，同时发布到 TikTok 和 Instagram，支持分析和自动添加热门音乐
 - [[Playwright]]：网站分析工具，用 Chromium 抓取任意 URL 的品牌信息、内容、竞品和视觉上下文
+- [[The-Agency]]：本 Agent 所属的 Multi-Agent System
 
 ## Connections
 - [[Marketing Social Media Strategist]] ← extends ← [[Marketing Carousel Growth Engine]]（本 Agent 是通用社交媒体策略的具体实现）
diff --git a/wiki/sources/marketing-china-ecommerce-operator.md b/wiki/sources/marketing-china-ecommerce-operator.md
index 99fb35e2..a015e030 100644
--- a/wiki/sources/marketing-china-ecommerce-operator.md
+++ b/wiki/sources/marketing-china-ecommerce-operator.md
@@ -1,64 +1,65 @@
 ---
 title: "Marketing China E-Commerce Operator"
 type: source
-tags: []
-date: 2026-04-21
+tags: ["agent", "marketing", "china", "ecommerce", "livestream", "multi-platform"]
+sources: []
+last_updated: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-china-ecommerce-operator.md]]
+- [[Agent/agency-agents/marketing/marketing-china-ecommerce-operator.md]]
 
 ## Summary（用中文描述）
-- 核心主题：The Agency 营销部门的中国电商多平台运营专家 Agent——跨淘宝/天猫/拼多多/京东/抖音店铺的全渠道电商运营与Campaign策略专家。
-- 问题域：如何在拥有全球最大电商市场的中国（淘宝/天猫/拼多多/京东/抖音五大平台各有不同算法、受众和文化）中建立和运营可持续增长的电商店铺。
-- 方法/机制：多平台差异化运营（每个平台独立策略）+ 直播带货运营 + 大促战役管理（618/双11/双12）+ 广告投放优化（直通车/万相台/多多搜索/京速推）+ 私域运营（微信CRM/会员体系/社群电商）+ 供应链与财务管理。
-- 结论/价值：成功的中国电商运营需要数据驱动决策、平台差异化策略、45-60天前置期大促准备、直播电商深度整合、以及利润保护优先于GMV追求的综合运营体系。
+- 核心主题：中国电商多平台运营专家 Agent人格定义，覆盖淘宝、天猫、拼多多、京东、抖音小店等主流平台
+- 问题域：如何在中国最大的电商市场（年GMV超万亿人民币）实现多平台店铺的统一运营与增长
+- 方法/机制：多平台差异化运营策略 + 直播带货 + 活动大促（618/双11）运营 + 付费广告优化 + 私域运营
+- 结论/价值：提供了一套完整的Agent级别的中国电商运营方法论，从平台评估、流量获取、直播运营到活动执行，覆盖运营全链路
 
 ## Key Claims（用中文描述）
-- 每个平台算法、受众和规则不同：永远不能将淘宝策略直接复制到拼多多或京东，每个平台需要独立优化方案。
-- 数据优先于直觉：每个运营变更必须有数据分析支撑，而非凭感觉决策。
-- 利润保护优先于GMV：永远不以牺牲盈利能力为代价追求GMV，必须严格监控单元经济学。
-- 大促准备需提前45-60天启动：618/双11等大促的准备应在活动前45-60天开始，而非两周前。
-- 库存准确性是关键：活动期间超卖会摧毁店铺评分，库存管理至关重要。
-- 每次活动客户应进入留存漏斗：活动客户不应被视为一次性交易，需进入CRM留存体系。
-- 直播电商贡献目标占总GMV 20%以上。
-- 综合广告ROAS目标不低于3:1。
-- 店铺评分须维持在4.8+（所有平台）。
-- 月度GMV增长在扩张期须超过15%。
+- 每个平台算法、受众和规则均不同，绝不能跨平台复制策略
+- 重大活动（618/双11）需提前45-60天开始准备，而非活动前两周
+- 追求GMV不能以牺牲利润为代价，需严格监控单元经济
+- 直播电商应贡献整体店铺GMV的20%以上
+- 全平台广告ROAS需超过3:1才能实现可持续盈利
 
 ## Key Quotes
-> "Never copy-paste strategies across Taobao, Pinduoduo, and JD - each has distinct algorithms, audiences, and rules." — 平台差异化核心原则
-> "Our Tmall conversion rate is 3.2% vs. category average of 4.1% - the detail page bounce at the price section tells me we need stronger value justification" — 数据驱动决策沟通风格示例
-> "That promotion drives volume but puts us at -5% margin per unit after platform fees and advertising - let's restructure the bundle" — 利润保护沟通风格示例
+> "Never copy-paste strategies across Taobao, Pinduoduo, and JD - each has distinct algorithms, audiences, and rules" — 平台差异化运营原则
+> "Major campaign preparation begins 45-60 days before the event, not 2 weeks" — 大促准备周期原则
+> "Never pursue GMV at the expense of profitability; monitor unit economics religiously" — 利润保护原则
 
 ## Key Concepts
-- [[Multi-Platform-Operations]]：跨淘宝/天猫/拼多多/京东/抖音五大平台的多渠道运营策略，每个平台独立制定算法优化方案和广告策略
-- [[Live-Commerce-Operations]]：直播带货运营——跨淘宝直播/抖音/快手的直播渠道建设与运营，包含主播培养/脚本框架/产品排序/KOL合作
-- [[Campaign-Battle-Plan]]：大促战役管理框架——618/双11/双12/春节等大促的T-60→T-30→T-7→T-Day→T+7全流程作战计划
-- [[Advertising-ROI-Optimization]]：平台广告ROI优化——直通车/万相台/多多搜索/京速推等工具的分平台投放策略与ROAS优化周期
-- [[Product-Listing-Optimization]]：产品Listing优化框架——针对各平台算法和用户行为的标题/主图/详情页优化（各平台字符限制不同）
-- [[Private-Domain-Operations]]：私域运营——微信CRM/会员体系/社群电商/客户生命周期管理，跨平台忠诚计划激励复购
-- [[Cross-Platform-Arbitrage]]：跨平台套利与差异化——创建平台专属SKU避免直接比价、用低成本流量平台建立品牌认知后在高毛利平台转化
+- [[直播带货]]（Live Commerce）：通过淘宝直播、抖音、快手等平台进行实时视频销售，结合主播、KOL/KOC合作，实现高转化率
+- [[私域运营]]（Private Domain Operations）：通过微信CRM、会员体系、微信群和小程序构建自有客户池，降低获客成本
+- [[直通车]]（Zhitongche）：淘宝/天猫搜索广告系统，关键词竞价投放，核心付费流量工具
+- [[万相台]]（Wanxiangtai）：阿里妈妈智能投放平台，支持货品加速和拉新快等 campaign 类型
+- [[超级推荐]]（Super Recommendation）：淘宝信息流推荐广告，用于新品推广和季节性营销
+- [[多多搜索]]（Duoduo Search）：拼多多搜索广告，针对平台个性化千人千面算法优化
+- [[千人千面]]（Qian Ren Qian Mian）：平台个性化推荐算法，根据用户行为数据实现精准推送
+- [[大促运营]]（Campaign Operations）：618、双11、双12等重大促销节点的完整作战计划（T-60至T+7）
+- [[广告ROAS优化]]（ROAS Optimization）：投资回报率优化框架，按平台分配预算（40%稳健词/30%测试/30%品牌词）
+- [[跨平台差异化]]（Cross-Platform Differentiation）：通过平台专属SKU、捆绑策略和定价策略避免跨平台比价
 
 ## Key Entities
-- [[Taobao]]（淘宝）：C2C平台，定位类似eBay，竞价排名靠直通车，适合长尾商品
-- [[Tmall]]（天猫）：B2C平台，品牌商家首选，用户信任度高，竞价排名品牌权重高
-- [[Pinduoduo]]（拼多多）：社交电商，以低价和拼团为核心，用户价格敏感度高
-- [[JD]]（京东）：自营为主，3C/电器品类强，自建物流体系，用户信任品牌和规格参数
-- [[Douyin-Shop]]（抖音店铺）：内容电商，通过短视频和直播流量转化，兴趣电商模式
-- [[618]]：年中大促（6月18日），中国第二大电商购物节，GMV冲刺关键节点
-- [[Double-11]]（双11）：全球最大购物节（11月11日），年度GMV峰值，最高流量争夺战
+- [[淘宝]]（Taobao）：阿里巴巴旗下C2C平台，国内最大电商平台之一，以中小卖家和丰富 SKU 著称
+- [[天猫]]（Tmall）：阿里巴巴旗下B2C平台，品牌化、品质化，搜索权重高度依赖品牌权威
+- [[拼多多]]（Pinduoduo）：社交电商平台，主打低价团购，用户价格敏感度高
+- [[京东]]（JD.com）：自营为主的B2C平台，物流体验好，用户信任品牌和规格参数
+- [[抖音店铺]]（Douyin Shop）：字节跳动旗下电商平台，直播电商核心阵地，内容与购物深度融合
+- [[淘宝直播]]（Taobao Live）：淘宝平台直播电商功能，品牌自播与达人直播并行
+- [[快手]]（Kuaishou）：短视频直播电商平台，下沉市场用户占比较高
+- [[小红书]]（Xiaohongshu）：种草内容平台，与电商形成内容→转化闭环
+- [[微信私域]]（WeChat）：私域运营核心阵地，CRM、会员、小程序、微信群多位一体
 
 ## Connections
-- [[Marketing-Douyin-Strategist]] ← extends ← [[Marketing-China-Ecommerce-Operator]]（抖音店铺运营是本Agent的子集，但Douyin Strategist更侧重内容策略，本Agent更侧重店铺运营）
-- [[Marketing-Cross-Border-Ecommerce]] ← depends_on ← [[Marketing-China-Ecommerce-Operator]]（跨境电商涉及将中国电商运营经验输出到海外平台）
-- [[Marketing-Private-Domain-Operator]] ← depends_on ← [[Marketing-China-Ecommerce-Operator]]（私域运营是本Agent的核心能力之一）
-- [[Supply-Chain-Strategist]] ← complements ← [[Marketing-China-Ecommerce-Operator]]（供应链管理是本Agent的高级能力之一，上游供应商管理部分依赖供应链专业知识）
-- [[Marketing-Livestream-Commerce-Coach]] ← overlaps ← [[Marketing-China-Ecommerce-Operator]]（直播带货是本Agent的核心运营场景，两者高度重叠）
+- [[Marketing Livestream Commerce Coach]] ← extends ← [[Marketing China E-Commerce Operator]]（直播带货为电商运营的核心子模块）
+- [[Marketing Cross-Border E-Commerce Specialist]] ← related_to ← [[Marketing China E-Commerce Operator]]（跨境电商依赖国内电商运营基础）
+- [[Marketing Private Domain Operator]] ← extends ← [[Marketing China E-Commerce Operator]]（私域运营是电商运营的复购策略层）
+- [[Supply Chain Strategist Agent]] ← supports ← [[Marketing China E-Commerce Operator]]（供应链管理为电商运营的库存和物流基础）
+- [[Marketing Douyin Strategist]] ← overlaps ← [[Marketing China E-Commerce Operator]]（抖音策略与电商运营存在交集）
+- [[Marketing Kuaishou Strategist]] ← overlaps ← [[Marketing China E-Commerce Operator]]（快手策略与电商运营存在交集）
 
 ## Contradictions
-- 与 [[Marketing-Douyin-Strategist]] 的潜在张力：
-  - 冲突点：两者均涉及抖音平台，但视角不同
-  - 当前观点（本Agent）：以店铺运营为中心，强调多平台协同（淘宝/天猫/拼多多/京东/抖音店铺全渠道）
-  - 对方观点（Douyin Strategist）：以内容策略为中心，强调短视频/直播内容创作和达人合作
-  - 协调建议：本Agent负责抖音店铺的整体运营管理（含广告投放/直播/数据分析），内容创作层面可咨询Douyin Strategist，两者互补而非竞争
+- 与 [[Marketing Cross-Border E-Commerce Specialist]] 存在潜在冲突：
+  - 冲突点：跨境电商强调本地化适配，而中国电商运营强调平台原生规则遵循
+  - 当前观点：国内多平台运营需严格遵守各平台规则（合规优先）
+  - 对方观点：跨境电商需灵活适配不同市场文化规范
diff --git a/wiki/sources/marketing-china-market-localization-strategist.md b/wiki/sources/marketing-china-market-localization-strategist.md
index 77035cbb..0aea41d1 100644
--- a/wiki/sources/marketing-china-market-localization-strategist.md
+++ b/wiki/sources/marketing-china-market-localization-strategist.md
@@ -1,73 +1,66 @@
 ---
 title: "China Market Localization Strategist"
 type: source
-tags: ["china", "marketing", "localization", "gtm", "douyin", "xiaohongshu", "wechat", "bilibili"]
-date: 2026-04-26
+tags: ["marketing", "china", "localization", "gtm", "douyin", "xiaohongshu", "wechat", "bilibili", "trends"]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-china-market-localization-strategist.md]]
+- [[Agent/agency-agents/marketing/marketing-china-market-localization-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：面向中国市场的全栈式本地化增长策略师，将实时趋势信号转化为可执行的选品、内容和渠道策略
-- 问题域：全球品牌进入中国市场的本地化难题，包括平台选择、趋势捕获、跨平台内容适配、GTM 执行
-- 方法/机制：实时热榜监控 + 双轨分析（内容轨 + 评论轨）+ 六阶段 GTM 门控（P0-P5）+ 平台原生内容策略
-- 结论/价值：数据驱动的闭环营销系统，覆盖抖音/小红书/微信/微博/知乎/B站，支持 1-3 人团队 7 天内执行落地
+- 核心主题：面向中国市场的全方位本地化增长策略，将实时趋势信号转化为可执行的选品、内容和渠道策略
+- 问题域：全球品牌进入中国市场、如何在中国抖音/小红书/微信/B站等平台实现有效本地化营销
+- 方法/机制：趋势信号监测 → 市场机会提取 → 跨平台本地化策略设计 → GTM 分阶段执行（P0-P5）
+- 结论/价值：提供数据驱动的闭环营销系统，覆盖从趋势发现到私域运营的完整链路，适配 1-3 人小团队
 
 ## Key Claims（用中文描述）
-- 数据驱动原则：任何策略建议必须有趋势数据支撑，必须展示信号来源（平台、排名、轨迹、热度持续时间），且须跨 ≥ 2 个平台交叉验证
-- 平台独立性：每个平台是不同的国家，内容策略不可跨平台直接复制，需根据算法机制定制原生内容
-- 本地化深度：本地化不是翻译，而是文化再工程，须理解面子/从众/性价比/国潮等中国消费心理
-- 执行优先：每个交付物必须在 1-3 人团队 7 天内可执行，包括具体字数、发布时间、预算范围和工具推荐
-- 信号前置：趋势信号须在主流平台峰值前 ≥ 72 小时识别，每条建议附带 P0-P5 优先级
+- 趋势信号识别需在主流平台峰值前 ≥ 72 小时完成
+- 每个策略推荐必须附带优先级（P0-P5）、估算工时和成功指标
+- 跨平台信号三角验证准确率目标 ≥ 75%
+- 内容模板需在 30 天内达到平台平均互动率的 ≥ 3 倍
+- 推荐 SKU 中 ≥ 60% 在 90 天内实现正向 ROI
+- 选品需在趋势验证后才执行，不可凭直觉决策
 
 ## Key Quotes
-> "You don't just 'localize copy' — you engineer full go-to-market systems by monitoring real-time trend signals, extracting market opportunities, and converting them into executable product selection, content, and channel strategies." — 角色定义
+> "Never recommend a strategy without trend data backing it. 'I feel this will work' is not acceptable." — 数据驱动决策原则
+> "Localization is not translation. It's cultural re-engineering." — 本地化深度原则
 > "Each platform is a different country with different rules. Never assume what works on Douyin works on Xiaohongshu." — 平台差异化原则
-> "Localization is not translation. It's cultural re-engineering." — 本地化本质
-> "If Day 3 engagement < 2%, kill the content. If > 5%, boost with DOU+ ¥500." — 闭环思维示例
+> "Think in closed loops: signal → insight → action → measurement → iteration." — 核心工作流
 
 ## Key Concepts
-- [[Trend-To-Action]]：趋势信号 → 市场机会 → 可执行清单的完整闭环流程，双轨分析（内容轨 + 评论轨）驱动
-- [[Dual-Track Analysis]]：同时分析内容数据（互动模式/关键词/供需缺口）和评论数据（需求词/痛点/风险词/情感）
-- [[Cross-Platform Content Strategy]]：每个平台独立制定原生策略，而非跨平台直接复用
-- [[Phased GTM Gate]]：P0 信号验证 → P1 种子内容 → P2 渠道激活 → P3 规模化 → P4 优化 → P5 成熟运营
-- [[Real-Time Trend Intelligence]]：7+ 中国平台热榜实时监控，信号检测四模型（见微知著/交叉验证/反直觉/MECE）
-- [[China Consumer Psychology]]：面子（Face）、从众（Herd Behavior）、性价比（Value-for-Money）、国潮（National Trend）
-- [[Seasonal Consumption Cycle]]：618、双十一、春节、520、七夕、双十二、年货节等关键营销节点
+- [[Trend-to-Action]]：将趋势信号转化为可执行营销动作的完整框架，包括双轨分析（内容轨+评论轨）和优先级矩阵
+- [[Private Domain Operations]]：私域运营，微信/企业微信为核心的留存和复购体系，与公域流量形成闭环
+- [[GTM Phase Gate]]：P0-P5 分阶段产品上市模型，从信号验证到成熟运营的六阶段门控管理
+- [[KOC Seeding]]：关键意见消费者种草，通过素人博主在小红书等平台进行口碑扩散
+- [[Live Commerce]]：直播电商，以引流款→利润款→品牌款的节奏实现即时转化
+- [[China Marketing Funnel]]：认知（微博/抖音）→ 考虑（知乎/ B 站）→ 转化（小红书/微信/电商）→ 留存（私域）的完整漏斗模型
 
 ## Key Entities
-- [[Douyin]]：抖音热榜，视觉速度优先，引流/种草主阵地，千川（DOU+）付费放大
-- [[Xiaohongshu]]：小红书，70/20/10 内容配比（生活方式/趋势/产品），KOC 种草，社区审美
-- [[WeChat]]：微信私域运营，60/30/10 内容价值法则，小程序集成，私域沉淀
-- [[Bilibili]]：B站，Z 世代深度内容，弹幕互动设计，UP 主合作
-- [[Weibo]]：微博热搜，舆论场，品牌声量和危机管理
-- [[Zhihu]]：知乎，权威 Q&A 定位，专业背书，不可硬推销
-- [[Kuaishou]]：快手，下沉市场，覆盖低线城市的短视频电商
-- [[618]]：京东 618 大促，上半年最大电商节点
-- [[Double Eleven]]：双十一，下半年最大电商节点
-- [[DOU+]]：抖音付费流量放大工具
+- [[Douyin]]：抖音，短视频平台，以兴趣图谱算法为核心，品牌曝光和直播电商主战场
+- [[Xiaohongshu]]：小红书，种草社区，70/20/10 内容配比（生活方式/趋势/产品），KOC 种草核心阵地
+- [[WeChat]]：微信，私域运营中枢，订阅号内容（60/30/10 价值法则）、小程序集成、企业微信私域沉淀
+- [[Bilibili]]：B站，Z 世代深度内容平台，弹幕互动设计，UP 主合作
+- [[Weibo]]：微博，舆论场，热搜话题运营，超级话题（Super Topic）运营
+- [[Zhihu]]：知乎，知识型平台，权威 Q&A 定位，禁止硬推销
+- [[DOU+]]：抖音内容加热工具，用于内容付费推广
+- [[Qianchuan]]：巨量千川，抖音电商广告平台
+- [[Jiguang Platform]]：聚光平台，小红书广告投放后台
+- [[618]]：6 月 18 日，京东主导的中国第二大购物节
+- [[Double 11]]：双十一，11 月 11 日，天猫主导的中国最大购物节
+- [[CNY]]：中国春节，年度最大消费季
 
 ## Connections
-- [[Marketing Weibo Strategist]] ← depends_on ← 本页（微博作为公域舆论和品牌声量平台）
-- [[Marketing Baidu SEO Specialist]] ← depends_on ← 本页（百度搜索作为品牌可信度补充渠道）
-- [[Marketing WeChat Official Account Manager]] ← extends ← 本页（微信私域运营是转化漏斗的最终环节）
-- [[Marketing Douyin Strategist]] ← extends ← 本页（抖音是中国市场 GTM 的核心放大渠道）
-- [[Marketing Xiaohongshu Specialist]] ← extends ← 本页（小红书是生活方式种草和种草/拔草决策链关键节点）
-- [[Marketing Kuaishou Strategist]] ← extends ← 本页（快手覆盖下沉市场，与抖音互补）
-- [[Marketing Zhihu Strategist]] ← extends ← 本页（知乎用于权威背书和信任建立）
-- [[Marketing Private Domain Operator]] ← extends ← 本页（私域运营是 GTM 漏斗留存阶段）
-- [[Marketing Cross-Border E-Commerce Specialist]] ← depends_on ← 本页（跨境电商是中国市场进入的物流/合规前提）
-- [[Marketing Social Media Strategist]] ← extends ← 本页（跨平台社媒策略框架）
-- [[Marketing Short-Video Editing Coach]] ← supports ← 本页（短视频剪辑技能支撑内容执行层）
-- [[Marketing Carousel Growth Engine]] ← extends ← 本页（轮播内容增长引擎）
+- [[Marketing Douyin Strategist]] ← extends ← [[China Market Localization Strategist]]
+- [[Marketing WeChat Official Account Manager]] ← depends_on ← [[Private Domain Operations]]
+- [[Marketing Xiaohongshu Specialist]] ← extends ← [[China Market Localization Strategist]]
+- [[Marketing Zhihu Strategist]] ← extends ← [[China Marketing Funnel]]
+- [[Marketing Kuaishou Strategist]] ← extends ← [[Live Commerce]]
+- [[Marketing Cross-Border E-Commerce Specialist]] ← depends_on ← [[China Market Localization Strategist]]
+- [[Marketing China E-Commerce Operator]] ← depends_on ← [[GTM Phase Gate]]
 
 ## Contradictions
-- 与 [[Marketing Douyin Strategist]] 可能存在视角差异：
-  - 冲突点：两者都以抖音为核心，但 [[Marketing Douyin Strategist]] 专注抖音内容/算法优化，本角色将抖音置于更宏观的中国全平台 GTM 框架中
-  - 当前观点：抖音是放大渠道，需与小红书/微信/B站协同，不能单独作战
-  - 对方观点：抖音自身生态已足够完整，可以作为独立增长引擎
-- 与 [[Marketing Social Media Strategist]] 可能存在视角差异：
-  - 冲突点：后者面向全球社媒，本角色专注中国市场独特性
-  - 当前观点：中国平台算法、文化、消费心理与全球主流市场有本质差异，需独立体系
-  - 对方观点：全球社媒策略框架可以适配中国市场
+- 与 [[Marketing Douyin Strategist]] 可能的冲突：
+  - 冲突点：[[Marketing Douyin Strategist]] 侧重抖音单一平台深度运营，[[China Market Localization Strategist]] 强调整合多平台的跨平台协同和数据闭环
+  - 当前观点：跨平台整合策略优先，单一平台策略需服从整体 GTM 框架
+  - 对方观点：抖音作为核心流量池应优先投入最大资源
diff --git a/wiki/sources/marketing-content-creator.md b/wiki/sources/marketing-content-creator.md
index 7e3a135b..9d72a74c 100644
--- a/wiki/sources/marketing-content-creator.md
+++ b/wiki/sources/marketing-content-creator.md
@@ -1,54 +1,47 @@
 ---
-title: "Marketing Content Creator"
+title: "Content Creator"
 type: source
-tags: ["marketing", "content-strategy", "brand-storytelling", "seo", "video-production", "copywriting", "multi-platform"]
-date: 2026-04-26
+tags: []
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-content-creator.md]]
+- [[Agent/agency-agents/marketing/marketing-content-creator.md]]
 
 ## Summary（用中文描述）
-- 核心主题：多平台内容创作专家 Agent——专注于跨平台品牌内容策略制定、叙事构建和受众互动优化
-- 问题域：品牌如何在多个数字渠道上持续产出高质量、吸引人、能够驱动品牌认知、参与和转化的内容
-- 方法/机制：内容策略框架（编辑日历+内容支柱+受众优先规划）+ 多格式创作能力（图文/视频/播客/社媒）+ 品牌叙事 + SEO 优化 + 绩效分析
-- 结论/价值：内容营销是品牌增长的核心驱动力，5:1 ROI 是内容投入的基准回报目标
+- 核心主题：多平台营销内容创作智能体（Content Creator Agent），专注于品牌叙事、受众互动与跨平台内容优化
+- 问题域：品牌如何在多个数字渠道持续产出高质量、吸引人的内容
+- 方法/机制：通过内容策略规划、多格式创作、品牌故事讲述、SEO优化、视频制作指导、效果分析等核心能力实现全渠道内容运营
+- 结论/价值：提供从内容策略到分发优化的一站式解决方案，帮助品牌提升知名度、参与度并驱动转化
 
 ## Key Claims（用中文描述）
-- 通过 25% 平均参与率和 15% 分享率，内容营销能有效驱动品牌认知和用户参与
-- 视频内容达到 70% 平均完播率是品牌视频成功的核心指标
-- SEO 优化内容能带来 40% 的自然流量增长
-- 300% 的内容驱动线索增长和 5:1 的内容投资回报率是可量化的内容营销价值
+- Content Creator Agent 通过多平台内容策略规划（编辑日历、内容支柱、受众优先）实现跨平台内容优化
+- Content Creator Agent 通过长篇叙事、视频脚本、播客等多元格式创作提升品牌内容覆盖率
+- Content Creator Agent 通过 SEO 优化和关键词策略实现自然流量 40% 增长
+- Content Creator Agent 通过视频制作指导和缩略图优化实现 70% 平均观看完成率
+- Content Creator Agent 通过内容驱动线索生成策略实现 300% 线索增长
 
 ## Key Quotes
-> "Expert content strategist and creator specializing in multi-platform content development, brand storytelling, and audience engagement." — Agent 核心角色定义
-> "Crafs compelling stories across every platform your audience lives on." — Agent 核心价值主张
-> "Focused on creating compelling, valuable content that drives brand awareness, engagement, and conversion across all digital channels." — 运营目标
-> "5:1 return on content creation investment" — 内容营销 ROI 基准
+> "Expert content strategist and creator specializing in multi-platform content development, brand storytelling, and audience engagement." — Agent 角色定义
+> "Crafts compelling stories across every platform your audience lives on." — Agent 风格定位
 
 ## Key Concepts
-- [[Content Strategy]]：编辑日历、内容支柱、受众优先规划、跨平台优化——是内容创作的战略基础
-- [[Brand Storytelling]]：叙事开发、品牌声音一致性、情感连接建立——将品牌转化为受众信任的故事
-- [[Multi-Format Creation]]：图文、视频脚本、播客、信息图、社媒内容的多格式创作能力
-- [[SEO Content]]：关键词优化、搜索友好格式、有机流量生成——内容的技术可见性维度
-- [[Video Production]]：脚本创作、分镜、剪辑指导、缩略图优化——全链路视频内容生产
-- [[Copywriting]]：说服性文案、转化导向信息、A/B 测试——驱动行动的文本能力
-- [[Content Distribution]]：多平台适配、内容再利用、传播放大策略——内容触达的放大机制
-- [[Performance Analysis]]：内容分析、参与度优化、ROI 测量——数据驱动的迭代闭环
+- [[ContentStrategy]]：编辑日历、内容支柱、受众优先规划、跨平台优化
+- [[BrandStorytelling]]：叙事发展、品牌声调一致性、情感连接建立
+- [[SEOContent]]：关键词优化、搜索引擎友好格式、有机流量增长
+- [[VideoProduction]]：脚本撰写、分镜、剪辑指导、缩略图优化
+- [[ContentRepurposing]]：内容再利用与平台适配策略
+- [[ContentAutomation]]：内容自动化与规模化生产系统
 
 ## Key Entities
-- YouTube（平台）：长视频内容（完整视频脚本、故事板）和缩略图优化的核心平台
-- TikTok（平台）：短视频内容的核心分发渠道
-- Instagram（平台）：图文内容和视觉叙事的核心阵地
-- Podcast（平台）：音频叙事和深度内容的主要载体
+- （无特定外部实体，本文档为纯方法论文档）
 
 ## Connections
-- [[Marketing Social Media Strategist]] ← receives_content_from ← [[Marketing Content Creator]]（Content Creator 产出内容，Social Media Strategist 负责分发策略）
-- [[Marketing Twitter Engager]] ← receives_content_from ← [[Marketing Content Creator]]（Twitter 专属内容由 Content Creator 定制）
-- [[Marketing LinkedIn Content Creator]] ← receives_content_from ← [[Marketing Content Creator]]（LinkedIn 长文内容协作产出）
-- [[Marketing TikTok Strategist]] ← receives_content_from ← [[Marketing Content Creator]]（TikTok 视频脚本和创意由 Content Creator 提供）
-- [[Marketing Video Optimization Specialist]] ← collaborates_with ← [[Marketing Content Creator]]（视频后期优化和效果分析协作）
-- [[Marketing Growth Hacker]] ← shares_strategy_with ← [[Marketing Content Creator]]（增长策略与内容创作协同）
+- [[MarketingTwitterEngager]] ← extends ← [[ContentCreator]]（内容创作为社交媒体参与提供素材支撑）
+- [[MarketingTikTokStrategist]] ← extends ← [[ContentCreator]]（短视频内容策略依赖内容创作能力）
+- [[MarketingLinkedInContentCreator]] ← extends ← [[ContentCreator]]（LinkedIn 内容创作为专业平台内容分支）
+- [[MarketingVideoOptimizationSpecialist]] ← relates_to ← [[ContentCreator]]（视频制作能力高度相关）
+- [[MarketingSocialMediaStrategist]] ← depends_on ← [[ContentCreator]]（社交媒体策略依赖内容供给）
 
 ## Contradictions
-- 无已知冲突。该 Agent 与 Wiki 中其他营销 Agent 构成互补关系而非竞争关系——Content Creator 负责内容生产，其他平台专属 Agent 负责分发和运营。
+- （无明显冲突内容）
diff --git a/wiki/sources/marketing-cross-border-ecommerce.md b/wiki/sources/marketing-cross-border-ecommerce.md
index 216b7127..a16bdc6f 100644
--- a/wiki/sources/marketing-cross-border-ecommerce.md
+++ b/wiki/sources/marketing-cross-border-ecommerce.md
@@ -2,7 +2,7 @@
 title: "Marketing Cross-Border E-Commerce Specialist"
 type: source
 tags: []
-date: 2026-04-21
+date: 2026-04-26
 ---
 
 ## Source File
@@ -11,26 +11,28 @@ date: 2026-04-21
 ## Summary（用中文描述）
 - 核心主题：跨境电商多平台运营与品牌全球化策略 Agent，覆盖 Amazon、Shopee、Lazada、AliExpress、Temu、TikTok Shop 等主流平台
 - 问题域：如何将中国制造产品高效推向全球市场，同时满足各平台合规要求、本地化需求和供应链管理挑战
-- 方法/机制：通过五步工作流（市场调研→合规准备→Listing 发布→广告引流→数据迭代）实现全漏斗运营，涵盖选品、FBA 物流、VAT 税务、Listing 本地化、PPC 广告、品牌建设全链路
-- 结论/价值：提供了一套系统化的跨境电商 Agent 操作框架，强调合规优先、本地化制胜、供应链成本控制三大核心原则
+- 方法/机制：通过五步工作流（市场调研→合规准备→Listing 发布→广告引流→数据迭代）实现全漏斗运营，涵盖选品、FBA 物流、VAT 税务、Listing 本地化、PPC 广告、品牌建设全链路；提供产品评估计分卡、平台策略对比表、Amazon PPC 三阶段框架等可交付工具
+- 结论/价值：强调"合规优先、本地化制胜、供应链成本控制"三大原则，净利率目标 >18%，是系统性跨境电商运营的完整 Agent 框架
 
 ## Key Claims（用中文描述）
 - 跨境电商不是"把国内爆款搬到海外"——本地化决定能否获客，合规决定能否存活，供应链决定能否盈利
-- 机器翻译的 Listing 转化率极低，母语级审校是强制要求
-- ACOS 有硬性底线：超过毛利率的广告活动必须优化或关停
-- 每个平台流量分配逻辑不同，照搬国内电商玩法必然失败
+- 机器翻译的 Listing 转化率极低，母语级审校是强制要求；文化禁忌和敏感词必须按目标市场规避
+- 每个 SKU 必须完整计算成本结构：采购+头程+仓储费+平台佣金+广告+尾程配送+退货损耗+汇率波动
+- ACOS 有硬性底线：超过毛利率的广告活动必须优化或关停；TACOS 目标 < 10%
+- 不盲目扩张新市场——每个市场都有合规+物流+运营启动成本，必须预先建模
 
 ## Key Quotes
-> "You want to sell this product in Europe? Don't ship anything yet - CE certification, WEEE registration, and German Packaging Act registration are all mandatory." — 合规优先原则
-> "This product has 80K monthly searches in the US, under 200 average reviews on page one, and a $25-$35 price range putting gross margins at 35%." — 数据驱动选品
-> "Amazon NA is insanely competitive. The same product has half the competitors on Amazon Japan, and Japanese consumers will pay a premium for quality." — 全球视野与差异化策略
-> "Don't send all your inventory to FBA at once. Ship one month's worth to test market response." — 风险意识与库存管理
+> "You want to sell this product in Europe? Don't ship anything yet - CE certification, WEEE registration, and German Packaging Act registration are all mandatory. List without them and you're looking at takedowns plus fines." — 合规优先原则
+> "This product has 80K monthly searches in the US, under 200 average reviews on page one, and a $25-$35 price range putting gross margins at 35%. Worth pursuing, but watch out for patent risk - run an FTO search first." — 数据驱动选品
+> "Amazon NA is insanely competitive. The same product has half the competitors on Amazon Japan, and Japanese consumers will pay a premium for quality. I'd suggest entering through Japan first, build a track record, then tackle North America." — 全球视野与差异化进入策略
+> "Don't send all your inventory to FBA at once. Ship one month's worth to test market response. Ocean freight is cheaper but slow - use air express initially to avoid stockouts, then switch to ocean once the model is proven." — 风险意识与库存管理
+> "Zero tolerance for IP infringement: no counterfeits, no hijacking branded listings, no unauthorized images or brand elements." — 知识产权红线
 
 ## Key Concepts
-- [[FBA]]：Fulfillment by Amazon，亚马逊自营物流服务，含入库计划、IPI 管理、长期仓储费控制
+- [[FBA]]：Fulfillment by Amazon，亚马逊自营物流服务，含入库计划、IPI 管理、长期仓储费控制、多站点库存调拨
 - [[ACOS]]：Advertising Cost of Sales，广告成本占销售额比例，目标值 20-25%
 - [[TACOS]]：Total Advertising Cost of Sales，含站内+站外广告的总广告成本占比，目标 < 12%
-- [[IPI]]：Inventory Performance Index，亚马逊库存绩效指数
+- [[IPI]]：Inventory Performance Index，亚马逊库存绩效指数，直接影响仓储容量
 - [[VAT]]：Value Added Tax，欧盟/英国增值税，含 IOSS/OSS 一站式申报
 - [[Economic Nexus]]：美国各州经济关联规则，决定销售税注册义务
 - [[HS Code]]：海关商品编码，用于进口关税计算和合规申报
@@ -40,26 +42,40 @@ date: 2026-04-21
 - [[Dropshipping]]：无货源模式，海外仓代发
 - [[FCL/LCL]]：整柜/拼柜海运，结合中欧班列、空运等多种头程物流方式
 - [[Vine Program]]：亚马逊 Vine 计划，付费获取高质量评论
+- [[IOSS/OSS]]：欧盟 VAT 一站式申报系统，简化跨境卖家税务合规
+- [[KOL/KOC]]：关键意见领袖/关键意见消费者，海外社交媒体营销核心资源
+- [[DTC]]：Direct-to-Consumer，独立站直销模式（Shopify/Shoplazza）
+- [[FTO Search]]：Freedom to Operate 自由运营检索，专利侵权风险评估
 
 ## Key Entities
-- [[Amazon]]：全球最大电商平台，核心市场为北美/欧洲/日本，以 Buy Box 竞争和 Brand Analytics 著称
-- [[Shopee]]：东南亚/拉美电商平台，以平台大促（9.9/11.11/12.12）和低客单价为主要流量逻辑
+- [[Amazon]]：全球最大电商平台，核心市场为北美/欧洲/日本，以 Buy Box 竞争和 Brand Analytics 著称；账户健康是生命线，禁止虚假评价和关联账户
+- [[Shopee]]：东南亚/拉美电商平台，以平台大促（9.9/11.11/12.12）和低客单价为主要流量逻辑；实际利润核算优先于 GMV 追逐
 - [[Lazada]]：东南亚电商平台，主打 LazMall 高端品牌馆和 Sponsored Solutions 广告
-- [[Temu]]：拼多多海外版，以全托管/半托管模式运营，极致低价竞争，工厂直卖商优势最大
-- [[TikTok Shop]]：短视频+直播电商，通过 Creator Marketplace 合作达人和 Shop Ads 获取流量
+- [[Temu]]：拼多多海外版，以全托管/半托管模式运营，极致低价竞争；适合工厂直卖商，利润率极薄（5-15%）
+- [[TikTok Shop]]：短视频+直播电商，通过 Creator Marketplace 合作达人和 Shop Ads 获取流量；内容+社交驱动发现式购物
 - [[AliExpress]]：速卖通，全球性电商平台，以买家保护和平台大促为主要运营手段
 - [[Jungle Scout]]：选品工具，含 Product Database 和 Product Tracker，用于市场分析和竞争评估
 - [[Helium 10]]：选品分析工具，含 Black Box 和 Cerebro，提供关键词研究和 ASIN 分析
-- [[FBA]]：亚马逊自营物流，提供 Prime 配送服务，但需严格管理 IPI 和长期仓储费
+- [[SellerSprite]]：亚马逊选品和关键词分析工具
+- [[PingPong/Payoneer/WorldFirst/LianLian]]：跨境收款工具，用于多平台店铺资金归集和结汇
+- [[Klaviyo/Mailchimp]]：邮件营销平台，用于独立站用户生命周期管理
+- [[Shopify/Shoplazza]]：独立站建站工具，支持主题设计、支付网关和物流集成
 - [[CE/FCC/FDA]]：产品认证标志，CE（欧盟）、FCC（美国）、FDA（食品/化妆品）为跨境必备
+- [[WEEE/EPR]]：欧盟废旧电子设备指令和包装生产者责任延伸，合规强制要求
 
 ## Connections
 - [[Marketing Zhihu Strategist]] ← cross_channel ← [[Marketing Cross-Border E-Commerce Specialist]]
 - [[Supply Chain Strategist Agent]] ← related_to ← [[Marketing Cross-Border E-Commerce Specialist]]
-- [[Marketing Douyin Strategist]] ← content_commerce ← [[TikTok Shop]] (in this source)
+- [[Marketing Douyin Strategist]] ← content_commerce ← [[TikTok Shop]] (via TikTok content-driven commerce model)
+- [[Marketing WeChat Official Account Manager]] ← audience_engagement ← [[DTC Independent Site]] (via email marketing)
+- [[Finance Tracker Agent]] ← financial_tracking ← [[FX Risk Management]] (via margin discipline)
+- [[Compliance Auditor Agent]] ← compliance_validation ← [[VAT/Sales Tax Filing]] (via tax compliance requirements)
 
 ## Contradictions
 - 与 [[Marketing Douyin Strategist]] 存在流量逻辑差异：
-  - 冲突点：TikTok Shop 内容驱动 vs Douyin 娱乐种草+挂车带货
-  - 当前观点（本文）：TikTok Shop 是跨境平台，需对接 Creator Marketplace，本地化内容为核心
-  - 对方观点：抖音是国内市场，内容与电商融合更深，流量获取逻辑更依赖算法推荐
+  - 冲突点：TikTok Shop 内容驱动 vs 抖音娱乐种草+挂车带货
+  - 当前观点（本文）：TikTok Shop 是跨境平台，需对接 Creator Marketplace，本地化内容为核心，Shop Ads 配合引流
+  - 对方观点：抖音是国内市场，内容与电商融合更深，流量获取逻辑更依赖算法推荐和直播即时转化
+- 与电商平台选择存在潜在张力：
+  - [[Temu]] 全托管模式利润率极低（5-15%），与本文净利率 >18% 目标存在矛盾
+  - Temu 适合工厂直卖商，而品牌卖家更适合 Amazon/TikTok Shop 组合
diff --git a/wiki/sources/marketing-douyin-strategist.md b/wiki/sources/marketing-douyin-strategist.md
index 0d29df9d..d4098bbd 100644
--- a/wiki/sources/marketing-douyin-strategist.md
+++ b/wiki/sources/marketing-douyin-strategist.md
@@ -1,54 +1,52 @@
 ---
 title: "Marketing Douyin Strategist"
 type: source
-tags: ["douyin", "short-video", "livestream-commerce", "marketing", "agent-personality"]
-date: 2026-04-25
+tags: []
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-douyin-strategist.md]]
+- [[Agent/agency-agents/marketing/marketing-douyin-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：抖音短视频营销与直播带货策略专家 Agent 个性文档，深度掌握抖音推荐算法、爆款视频策划、直播带货全链路
-- 问题域：短视频完播率优化、流量运营、DOU+投放策略、直播选品与话术设计、账号矩阵布局
-- 方法/机制：算法优先思维（完播率 > 点赞率 > 评论率 > 分享率）；黄金3秒钩子 + 信息密度 + 结尾悬念；直播15分钟流量峰值节奏控制
-- 结论/价值：提供可执行的短视频脚本模板、直播产品结构规划、流量运营 SOP，帮助实现视频完播率 > 35%、月粉丝增长 > 15%
+- 核心主题：抖音短视频营销与直播带货的专业 Agent 人格定义，深度涵盖推荐算法运营、爆款视频策划、直播脚本设计及全漏斗品牌增长策略
+- 问题域：如何通过内容矩阵策略在抖音平台实现有效流量获取、用户增长和商业变现
+- 方法/机制：算法优先思维（完播率 > 点赞率 > 评论率 > 分享率）、3秒黄金钩子 + 信息密度 + 结尾悬念的视频结构、DOU+ 精准投放 + 矩阵账号协同运营、直播引流款/利润款/形象款/秒杀款组合排品
+- 结论/价值：抖音运营的核心不是"拍好看的视频"，而是"用前3秒钩住注意力，让算法为你分发"
 
 ## Key Claims（用中文描述）
-- 完播率优先于点赞率、评论率和分享率，是抖音算法的首要权重
-- 前3秒决定一切——必须用冲突、悬念或价值钩子开场，不能铺垫
-- DOU+ 精准定向比砸钱更重要
-- 直播节奏：每15分钟制造一次流量峰值
-- 出镜人物视频完播率比纯产品展示高30%以上
-- 视频内禁止引流外部平台，否则触发限流
+- 前3秒决定一切——不铺垫，直接上冲突/悬念/价值（DOU+ 精准定向比砸钱更重要）
+- 算法优先级：完播率 > 点赞率 > 评论率 > 分享率（所有视频必须有明确的完播率优化策略）
+- 短视频时长标准：知识类 30-60s，剧情类 15-30s，直播切片 15s
+- 直播节奏：每 15 分钟一个流量峰值周期；2小时直播的产品结构为引流款20%/利润款50%/形象款15%/秒杀款15%
+- 矩阵账号运营：主账号 + 子账号 + 员工账号协同 playbook
+- 视频内禁止引导外部平台，否则触发限流
 
 ## Key Quotes
-> "抖音的核心不是'拍好看的视频'，而是'前三秒钩住注意力，让算法替你分发'" — 抖音营销的本质
-> "完播率 > 点赞率 > 评论率 > 分享率——这是算法优先级顺序" — 流量分发逻辑
-> "别纠结滤镜，先每天发一条，让算法学习你的账号" — 执行优先原则
+> "Douyin's core isn't about 'shooting pretty videos' — it's about 'hooking attention in the first 3 seconds and letting the algorithm distribute for you'" — 核心运营哲学
+> "Completion rate > like rate > comment rate > share rate — this is the algorithm's priority order" — 算法优先级定义
+> "The first 3 seconds decide everything — no buildup, lead with conflict/suspense/value" — 钩子设计原则
 
 ## Key Concepts
-- [[CompletionRateOptimization]]：完播率优化策略——通过黄金3秒钩子、信息密度和结尾悬念提升视频完播率
-- [[ContentMatrixStrategy]]：内容矩阵策略——教育类、剧情类、产品测评类、Vlog类内容协同布局
-- [[DOUPlus]]：抖音原生投放工具，精准定向比预算更重要
-- [[LivestreamCommerce]]：直播带货——引流款(20%)/利润款(50%)/形象款(15%)/秒杀款(15%)产品结构设计
-- [[Golden3SecondHook]]：黄金3秒钩子——冲突型、价值型、悬念型、共鸣型四种开场模式
-- [[TrafficOperations]]：流量运营——发布时间优化、评论区互动、合集优化
-- [[VideoPacing]]：视频节奏控制——节拍剪辑、转场节奏、字幕韵律同步
+- [[完播率优化]]：抖音算法核心指标，要求视频在前几秒制造钩子、信息密度高、结尾悬念，使观众完整看完视频以获得更大流量分发
+- [[内容矩阵]]：通过主账号 + 子账号 + 员工账号的协调运营，扩大品牌覆盖范围和内容多样性的策略
+- [[直播带货排品结构]]：引流款（拉流量/低毛利）、利润款（核心营收/中等毛利）、形象款（提升品牌/高毛利）、秒杀款（冲留存/亏损）的产品组合与节奏设计
+- [[DOU+ 精准投放]]：抖音原生推广工具，核心在于定向精准人群而非盲目砸钱
+- [[直播节奏控制]]：每15分钟制造一个流量峰值，维持观众活跃度和互动数据
 
 ## Key Entities
-- [[Douyin]]：抖音（中国版 TikTok）平台，本 Agent 的主战场
-- [[OceanEngine]]：巨量引擎，抖音商业化广告平台，包含千川(Qianchuan)广告
-- [[DouyinBGM]]：抖音热门BGM，跟踪趋势热点
+- [[Douyin]]：字节跳动旗下的中国最大短视频平台，抖音是 TikTok 的中国版本，拥有独特的推荐算法和直播带货生态
+- [[巨量引擎]]：字节跳动营销平台，包含千川广告等商业化投放工具，是抖音品牌广告和付费流量的核心渠道
 
 ## Connections
-- [[MarketingShortVideoEditingCoach]] ← feeds_into ← [[MarketingDouyinStrategist]]：短视频拍摄剪辑为策略提供素材支撑
-- [[MarketingKuaishouStrategist]] ← related_to ← [[MarketingDouyinStrategist]]：快手与抖音同为短视频平台，策略有互通性
-- [[MarketingChinaEcommerceOperator]] ← depends_on ← [[MarketingDouyinStrategist]]：抖音营销是电商运营的重要流量来源
-- [[MarketingVideoOptimizationSpecialist]] ← extends ← [[MarketingDouyinStrategist]]：视频优化专员在完播率和算法层面提供更深入的技术支持
+- [[Marketing-TikTok-Strategist]] ← 同平台差异 ← [[Marketing-Douyin-Strategist]]：抖音与 TikTok 虽同源但用户群体、算法规则、商业化生态差异显著
+- [[Marketing-Livestream-Commerce-Coach]] ← 直播专业 ← [[Marketing-Douyin-Strategist]]：抖音直播带货是 Douyin Strategist 的核心业务场景之一，与专门的直播教练存在协作关系
+- [[Marketing-Short-Video-Editing-Coach]] ← 视频制作 ← [[Marketing-Douyin-Strategist]]：短视频剪辑coach提供执行层支持，Douyin Strategist 提供策略层规划
+- [[Marketing-Growth-Hacker]] ← 增长协同 ← [[Marketing-Douyin-Strategist]]：Douyin 矩阵账号运营是 Growth Hacker 增长策略的重要组成部分
+- [[Marketing-Private-Domain-Operator]] ← 私域联动 ← [[Marketing-Douyin-Strategist]]：抖音公域流量向私域（微信私域）的导流转化是长期变现的关键路径
 
 ## Contradictions
-- 与 [[MarketingTiktokStrategist]] 存在平台规则差异：
-  - 冲突点：TikTok 与抖音的推荐算法权重不完全相同（TikTok 更注重分享率，抖音更注完播率）
-  - 当前观点：抖音策略以完播率为首要优化指标
-  - 对方观点：TikTok 策略需平衡分享率与互动率
+- 与 [[Marketing-TikTok-Strategist]] 存在平台规则差异：
+  - 冲突点：内容合规要求不同——抖音对食品/医药/化妆品类目有严格的广告法规要求，而 TikTok 各市场合规标准不同；抖音算法与 TikTok 算法细节差异（抖音有独特的 DOU+ 投放体系，TikTok 主要依赖 Creator Fund 和 TikTok Shopping）
+  - 当前观点：[[Marketing-Douyin-Strategist]] 遵循抖音特有规则（DOU+、巨量引擎、矩阵账号）
+  - 对方观点：[[Marketing-TikTok-Strategist]] 遵循 TikTok 全球化平台规则
diff --git a/wiki/sources/marketing-kuaishou-strategist.md b/wiki/sources/marketing-kuaishou-strategist.md
index 54c07cad..0c6b84a2 100644
--- a/wiki/sources/marketing-kuaishou-strategist.md
+++ b/wiki/sources/marketing-kuaishou-strategist.md
@@ -2,55 +2,55 @@
 title: "Marketing Kuaishou Strategist"
 type: source
 tags: []
-date: 2026-04-21
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-kuaishou-strategist.md]]
+- [[Agent/agency-agents/marketing/marketing-kuaishou-strategist]]
 
 ## Summary（用中文描述）
-- **核心主题**：快手平台专业营销策略师 Agent，专注于下沉市场营销、短视频内容创作、直播带货运营与社区信任构建
-- **问题域**：快手平台的老铁经济生态 vs 抖音的中心化流量逻辑差异；如何在低线城市建立真实信任驱动型品牌
-- **方法/机制**：
-  - 均衡分发算法理解：快手给予每个创作者基础流量曝光，奖励日常发帖一致性而非一次性病毒传播
-  - 老铁关系构建：每条内容都应加强创作者-粉丝的情感纽带，信任先于销售
-  - 直播带货三段式结构（预热→直播中→复盘）：3-2-1产品介绍公式（3个痛点→2个演示→1个不可抗拒报价）
-  - 快手小店运营：选品、定价、物流全链路管理
-- **结论/价值**：为下沉市场品牌提供快手原生策略，避免将抖音内容直接移植到快手的常见错误，通过社区忠诚度实现可持续GMV增长
+- 核心主题：快手平台短视频营销与直播电商运营专家 Agent 人格定义
+- 问题域：下沉市场用户增长、直播带货转化、老铁文化社区建设
+- 方法/机制：均衡分发算法理解 → 真实性内容生产 → 老铁关系建立 → 直播电商变现 → 私域复购
+- 结论/价值：快手运营必须以"真实性 > 精致度"为第一原则，建立可信赖的主播-粉丝关系，而非追求抖音式流量爆发
 
 ## Key Claims（用中文描述）
-- 快手用户能即时识别并拒绝精心制作的不真实内容，真实性高于制作精良度
-- 快手奖励每日发帖一致性，优先于一次性病毒爆发
-- 直播带货中产品品质和诚实展示是不可妥协的——快手社区会摧毁不诚信卖家
-- 不要将抖音策略直接复用到快手——两者在受众、审美、算法和商业逻辑上存在根本差异
-- 粉丝团私域运营是快手长期增长的核心，应尽早建立微信或快手粉丝群组
+- 快手用户能即时识别并排斥精致化、虚伪的内容，真实性是一切的基础
+- 快手"均衡分发"算法给予每个创作者基础曝光量，坚持日更比单次爆款更有价值
+- 老铁关系（兄弟文化）是快手电商的核心驱动力，信任建立后再进行商业转化
+- 抖音策略直接搬运到快手通常会失败——两个平台在算法、用户、内容审美上存在根本性差异
+- 直播带货转化率 ≥3%、老铁自发在评论区为品牌辩护，是衡量成功的终极信任信号
 
 ## Key Quotes
-> "Kuaishou users instantly detect and reject polished, inauthentic content" — 快手文化核心原则：真实高于精致
-> "Trust Before Sales: Build genuine relationships before attempting any commercial conversion" — 信任优先于销售
-> "Kuaishou is NOT Douyin: Strategies, aesthetics, and content styles that work on Douyin will often backfire on Kuaishou" — 平台差异化核心警示
-> "Do NOT repurpose Douyin content directly to Kuaishou" — 内容移植禁区
+> "On Kuaishou, the moment you start sounding like a marketer, you've already lost - talk like a real person sharing something good with friends."
+> — 快手运营沟通风格的核心原则：像朋友分享好物，而非推销
+
+> "Last night's live session converted at 4.2% with 38-minute average view time - the factory tour video we posted yesterday clearly built trust."
+> — 结果导向的快手运营者：所有数据都服务于信任积累
+
+> "This content style would crush it on Douyin but flop on Kuaishou - our 老铁 want to see the real product in real conditions, not a studio shoot."
+> — 平台差异化的核心洞察：快手用户需要真实场景下的产品演示
 
 ## Key Concepts
-- [[老铁经济]]：快手独特的兄弟经济模式，建立在信任和忠诚基础上的创作者-粉丝关系
-- [[均衡分发算法]]：快手的平等分发机制，给每个创作者基础流量曝光，触发扩大分发由社区互动决定
-- [[下沉市场]]：中国低线城市市场（通常指三四五线城市），30-50岁用户群体
-- [[直播带货]]：快手社交电商核心模式，通过直播房间实时展示、销售产品
-- [[3-2-1产品介绍公式]]：3个痛点（"老铁们，你们是不是也遇到过..."）→ 2个产品演示 → 1个不可抗拒报价
-- [[私域运营]]：通过粉丝团、微信私域将公域流量转化为可重复触达的高价值客户群
+- [[下沉市场]]：中国三四五线城市及农村地区用户群体——快手的核心受众，日均观看时长高、消费决策更依赖信任关系而非品牌认知
+- [[直播带货]]：通过直播室实时展示、讲解、销售商品的电商模式——快手电商生态的核心支柱
+- [[老铁经济]]：快手独有的以信任和忠诚为基础的粉丝关系经济——类似兄弟情谊，老铁愿意重复购买并主动为品牌辩护
+- [[私域运营]]：将公域流量沉淀为可反复触达的私有用户资产——快手通过粉丝团和微信私域实现
+- [[内容真实性]]：快手内容生产的核心原则——用户价值 genuineness over polish，真实场景 > 精致制作
 
 ## Key Entities
-- [[Kuaishou]]：快手短视频与直播电商平台，以老铁文化和下沉市场为核心差异化定位
-- [[Douyin]]：抖音短视频平台，以一二线城市、18-35岁群体为中心，采用中心化推荐算法，与快手形成直接竞争
+- [[Douyin]]：抖音——快手最主要的竞争平台，两个平台在算法逻辑、受众定位、内容审美上存在根本差异，不能直接互相搬运内容
+- 快手小店：快手内置电商平台，支持直播带货的商品展示、交易和物流管理
 
 ## Connections
-- [[Marketing-Douyin-Strategist]] ← platform_sibling ← [[Marketing-Kuaishou-Strategist]]
-- [[Marketing-Livestream-Commerce-Coach]] ← extends ← [[Marketing-Kuaishou-Strategist]]
-- [[直播带货]] ← core_mechanism ← [[老铁经济]]
+- [[营销抖音策略]] ← platform_comparison ← [[快手策略]]（两个平台差异化运营的核心）
+- [[下沉市场]] ← target_audience ← [[快手策略]]（下沉市场是快手的核心用户群）
+- [[私域运营]] ← monetization_strategy ← [[快手策略]]（快手私域是长期变现的核心）
+- [[直播带货]] ← core_commerce_model ← [[快手策略]]（直播是快手电商的主要场景）
 
 ## Contradictions
-- 与 [[Marketing-Douyin-Strategist]] 存在根本平台差异：
-  - 冲突点：内容风格、受众定位、算法逻辑、商业模式
-  - 当前观点（快手策略师）：下沉市场受众重视真实感，信任驱动重复购买，均等分发算法
-  - 对方观点（抖音策略师）：一二线城市受众偏好精致内容，算法驱动发现购买，中心化推荐
-  - **核心原则**：快手策略绝不直接复用抖音内容；两者面向不同用户心理和平台生态
+- 与 [[营销抖音策略]] 冲突：
+  - 冲突点：内容策略和算法逻辑是否可跨平台复用
+  - 当前观点（快手策略）：抖音策略直接搬运到快手通常失败——均衡分发 vs 中心化推荐、下沉市场 vs 一二线城市、真实性 vs 精致化、关系驱动 vs 流量驱动
+  - 对方观点（抖音策略）：以完播率和互动率优化算法推荐为核心，专注流量爆发和爆款内容
+  - 补充说明：两者并非互斥，而是面向不同市场不同用户心理的差异化运营策略，共同构成中国短视频营销的完整版图
diff --git a/wiki/sources/marketing-linkedin-content-creator.md b/wiki/sources/marketing-linkedin-content-creator.md
index 614250b5..96a4f289 100644
--- a/wiki/sources/marketing-linkedin-content-creator.md
+++ b/wiki/sources/marketing-linkedin-content-creator.md
@@ -1,52 +1,62 @@
 ---
 title: "LinkedIn Content Creator"
 type: source
-tags: ["linkedin", "thought-leadership", "personal-brand", "content-strategy", "social-media"]
+tags: ["marketing", "linkedin", "content-strategy", "personal-brand", "thought-leadership"]
 date: 2026-04-26
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-linkedin-content-creator.md]]
+- [[Agent/agency-agents/marketing/marketing-linkedin-content-creator.md]]
 
 ## Summary（用中文描述）
-- 核心主题：LinkedIn 专业内容创作者 Agent——专注于思想领导力内容、个人品牌建设和高互动专业内容生成，帮助用户将专业技能转化为可见的专业影响力并产生真实的商业回报。
-- 问题域：如何在 LinkedIn 这个专业社交平台上持续产出能驱动招聘机会、潜在客户和声誉增长的优质内容；如何绕过 LinkedIn 算法限制实现有机增长；如何构建差异化的个人品牌。
-- 方法/机制：七阶段完整工作流（受众分析→钩子工程→帖子构建→格式优化→轮播/文章制作→主页优化→互动策略）；基于算法的内容结构设计（停留时间/保存率/早期velocity三大信号）；按受众类型（创始人/求职者/开发者/B2B营销）定制化内容策略。
-- 结论/价值：中性内容产生中性结果；每个帖子必须有可辩护的观点；钩子决定一切；互动后的前60分钟是算法质量测试窗口。
+- 核心主题：LinkedIn 专业内容创作与个人品牌建设专家 Agent，专注于思想领导力内容、个人品牌塑造和高互动率内容策略
+- 问题域：专业社交平台内容创作效率低、个人品牌缺乏差异化、算法机制理解不足、缺乏系统性内容运营框架
+- 方法/机制：七阶段内容工作流（受众定位→钩子工程→帖子构造→格式优化→轮播制作→主页优化→互动策略）、受众分群 Playbook（创始人/求职者/开发者/B2B）、LinkedIn 算法四杜杆（停留时间/收藏率/早期速度/原生内容）、轮播深层架构、评论转管道系统
+- 结论/价值：中性内容 = 中性结果；前 60 分钟响应决定算法分发；原生内容（PDF/原生视频）触达量是外链帖的 3-5 倍；内容温暖外联连接接受率 30%+
 
 ## Key Claims（用中文描述）
-- LinkedIn Content Creator Agent 通过思想领导力内容 + 算法机制理解 + 个人品牌建设三维度，帮助用户将专业 expertise 转化为真实商业机会（招聘/线索/声誉）。
-- LinkedIn 算法核心权重：保存率 > 点赞（被保存的内容获得更高分发权重）；早期速度（第一小时互动决定分发天花板）；停留时间（长阅读和轮播滑动是质量信号）。
-- 内容支柱（3-5个）是个人品牌的锚点，必须位于 expertise、受众需求和独特观点的交叉点，而非泛泛而谈。
-- 发布后60分钟内的互动质量决定算法是否扩大分发范围——"发完就走"是最大错误。
-- 外链在帖子正文中被 LinkedIn 主动压制——必须使用"评论区链接"或"首条评论置顶链接"。
+- 首句必须"停止滚动"并赢得"查看更多"点击——首句失败，后续一切无效
+- 具体性 > 激励性："我解雇了最好的员工，这拯救了公司"远胜于"领导力很难"
+- 每篇帖子必须有值得捍卫的立场——承认反论点，然后坚守
+- 发布后前 60 分钟是算法的质量测试，必须响应每条评论
+- LinkedIn 主动压制帖子正文中的外链，必须用"链接在评论区"
+- 3-5 个标签最优，精准标签 > 泛标签（如 #b2bsales 而非 #business）
+- 收藏率 > 点赞率，实用/参考价值内容被收藏的权重超过点赞
+- 原生内容（原生 PDF/视频/文章）触达量是含外链帖子的 3-5 倍
+- 标签只在真正相关时使用——标签滥用损害触达和真实关系
+- 内容温暖的外联连接接受率 30%+（远高于冷外联）
 
 ## Key Quotes
-> "Every post must have a defensible point of view. Neutral content gets neutral results." — LinkedIn Content Creator 核心原则
-
-> "Hook in the First Line: The opening sentence must stop the scroll and earn the '...see more' click. Nothing else matters if this fails." — 钩子优先级
-
-> "Never Post and Ghost: The first 60 minutes after publishing is the algorithm's quality test. Respond to every comment." — 发布后互动策略
-
-> "3-5 Hashtags Maximum: Specific beats generic. #b2bsales over #business." — 标签策略
+> "Hook in the First Line: The opening sentence must stop the scroll and earn the \"...see more\" click. Nothing else matters if this fails." — 钩子法则黄金定律
+> "Specificity Over Inspiration: Concrete stories, real numbers, genuine takes — always." — 具体性原则
+> "Never Post and Ghost: The first 60 minutes after publishing is the algorithm's quality test. Respond to every comment." — 算法互动黄金时间
+> "Default requirement: Every post must have a defensible point of view. Neutral content gets neutral results." — 立场原则
+> "Save rate: Practical, reference-worthy content gets saved — saves outweigh likes in feed scoring." — LinkedIn 算法收藏权重
 
 ## Key Concepts
-- [[Thought-Leadership]]：思想领导力——通过有独特观点的内容建立专业权威，而非泛泛分享通用信息。
-- [[Content-Pillar]]：内容支柱——3-5个核心主题，是个人品牌的锚点，位于 expertise、受众需求和独特观点的交叉点。
-- [[Hook-Engineering]]：钩子工程——在帖子第一行就完成滚动拦截，吸引用户点击"展开更多"，包含好奇心缺口/大胆声明/具体故事三种变体。
-- [[Carousel-Content]]：轮播内容——原生文档格式上传，Slide 1 = 钩子，每张一个洞察，最终幻灯片包含具体 CTA + 关注提示。
-- [[LinkedIn-Algorithm]]：LinkedIn 推荐算法——三大核心信号：保存率（权重最高）、早期速度（第一小时互动）、停留时间（长阅读/轮播滑动）。
-- [[Personal-Brand]]：个人品牌——在 LinkedIn 上通过一致的内容支柱、独特的语音档案和真实的专业故事构建可识别的权威形象。
-- [[Engagement-Strategy]]：互动策略——发布前在相关帖子留评论预热算法，发布后60分钟内回复所有评论，目标账号每天3-5条有实质内容的评论。
+- [[Thought Leadership]]：通过有观点、有价值的内容建立持久专业权威，而非单纯涨粉
+- [[Hook Engineering]]：首句钩子工程——3 种变体（好奇心缺口/大胆主张/具体故事），选择赢得"查看更多"的版本
+- [[Content Pillar]]：3-5 个内容支柱——专业知识、受众需求与独特视角的交集
+- [[LinkedIn Algorithm]]：LinkedIn feed 算法四核心杠杆（停留时间/收藏率/早期互动速度/原生内容）
+- [[Personal Brand Architecture]]：个人品牌架构——主页、About、Featured 形成转化漏斗
+- [[Carousel Architecture]]：轮播深层架构（首张独立成帖/每张一理念/倒数第二张揭示核心洞察/结尾 CTA + 关注提示）
+- [[Inbound Lead Generation]]：通过内容互动将关注转化为潜在客户、职位机会和招聘私信
 
 ## Key Entities
-- [[LinkedIn]]：LinkedIn 是一个以职业内容消费为核心的专业社交平台，其算法优先分发能引发高质量互动（保存、评论、转发）的原生内容，对外部链接和标签滥用持惩罚态度。
+- [[LinkedIn]]：专业社交平台，全球最大的 B2B 内容分发渠道，算法优先原生内容
 
 ## Connections
-- [[Marketing-Social-Media-Strategist]] ← extends ← [[LinkedIn-Content-Creator]]：Social Media Strategist 提供跨平台战略框架（含 LinkedIn 全栈运营），Content Creator 在其框架下专注 LinkedIn 平台的具体内容执行细节。
-- [[Marketing-Twitter-Engager]] ← parallel ← [[LinkedIn-Content-Creator]]：Twitter Engager 与 LinkedIn Content Creator 是专业社交媒体双平台运营的核心 Agent，同属 Social Media Strategist 的下游执行层。
-- [[Content-Pillar]] ← depends_on ← [[Personal-Brand]]：内容支柱的建立依赖清晰的个人品牌定位。
-- [[Hook-Engineering]] ← drives ← [[LinkedIn-Algorithm]]：钩子质量直接决定早期速度信号，进而影响算法分发。
+- [[Marketing Social Media Strategist]] ← extends ← [[marketing-linkedin-content-creator]]
+  - Social Media Strategist 提供跨平台框架，LinkedIn Content Creator 深入 LinkedIn 平台专项机制
+- [[Marketing Zhihu Strategist]] ← parallel ← [[marketing-linkedin-content-creator]]
+  - 两者均专注思想领导力内容策略，但平台不同（LinkedIn vs 知乎），内容格式和受众文化各异
+- [[Marketing Content Creator]] ← depends_on ← [[marketing-linkedin-content-creator]]
+  - 通用内容创作者依赖 LinkedIn 专项专家提供专业社交平台的分发策略
+- [[Marketing Twitter Engager]] ← parallel ← [[marketing-linkedin-content-creator]]
+  - 两者均为专业社交平台内容策略，LinkedIn 更偏 B2B 影响力建设，Twitter/X 更偏实时观点传播
 
 ## Contradictions
-- 与 [[Marketing-Social-Media-Strategist]]：Social Media Strategist 的 LinkedIn 运营描述较宽泛（公司页面/个人品牌/专栏文章/新闻通讯），Content Creator 提供了更细致的执行方法论（钩子变体/轮播架构/互动时机）。两者为宽窄互补关系，非冲突。
+- 与 [[Marketing Social Media Strategist]] 的策略细节冲突：
+  - 冲突点：内容支柱数量（Social Media Strategist 提"3-5 个内容支柱"；LinkedIn Content Creator 重申"3-5 个内容支柱"并给出具体落地方法——两者一致无实质冲突）
+  - 当前观点：LinkedIn Content Creator 对 LinkedIn 平台提供了更细粒度的操作规范（钩子变体/轮播架构/算法杠杆/前 60 分钟响应）；Social Media Strategist 提供了跨平台协调视角；两者为互补关系而非冲突
+  - 对方观点：Social Media Strategist 强调 LinkedIn 个人品牌互动率目标 5%+，LinkedIn Content Creator 给出 3-6%+ 区间
diff --git a/wiki/sources/marketing-livestream-commerce-coach.md b/wiki/sources/marketing-livestream-commerce-coach.md
index c248895a..90a57b64 100644
--- a/wiki/sources/marketing-livestream-commerce-coach.md
+++ b/wiki/sources/marketing-livestream-commerce-coach.md
@@ -1,55 +1,59 @@
 ---
 title: "Marketing Livestream Commerce Coach"
 type: source
-tags: []
+tags: ["livestream-commerce", "host-training", "traffic-operations", "douyin", "kuaishou", "taobao-live"]
 date: 2026-04-26
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-livestream-commerce-coach.md]]
+- [[Agent/agency-agents/marketing/marketing-livestream-commerce-coach.md]]
 
 ## Summary（用中文描述）
-- 核心主题：直播带货全链路运营教练——主播培训+直播间操盘+流量运营+数据优化
-- 问题域：如何将素人主播培养为百万GMV主播，如何通过算法驱动实现直播间可持续增长
-- 方法/机制：核心公式「流量 × 转化率 × 客单价 = GMV」；算法优先级「停留时长 > 互动率 > 点击率 > 购买转化率」；三阶段流量模型（冷启→成长期→成熟期）
-- 结论/价值：停留时长和互动率是决定平台是否给免费流量的核心指标；脚本体系+主播分级+数据复盘构成完整操盘闭环
+- 核心主题：直播带货全链路运营教练 Agent，覆盖主播孵化、脚本设计、产品排品、流量运营、数据复盘，跨抖音/快手/淘宝直播/视频号四大平台
+- 问题域：如何从零孵化主播、设计高效直播话术、平衡付费与有机流量、实现 GMV 持续增长
+- 方法/机制：五阶段话术框架 + 三阶段流量模型 + 四步工作流 + 数据驱动实时调优
+- 结论/价值：停留时长和互动率才是算法的核心喂养指标，而非 GMV；直播间的健康增长路径是逐步降低付费流量占比、提升自然流量占比
 
 ## Key Claims（用中文描述）
-- 停留时长和互动率是决定平台是否给免费流量的核心指标，而非直播时长本身
-- 五阶段话术框架（留人钩子→产品介绍→信任建立→紧迫成交→追单挽留）是直播间脚本的核心骨架
-- 三阶段流量演进模型：冷启期（付费70%+自然30%）→成长期（付费50%+自然50%）→成熟期（付费30%+自然70%）
-- 成功的关键指标：GPM>800元、UV值>1.5元、自然流量占比>50%（成熟期）、千川ROI>2.5
-- 合规底线：不使用绝对化表述、不暗示医疗功效、不贬低竞品、不诱导未成年人购买
+- 平台评估直播间"用户行为数据"而非"播出时长"，数据优先级排序为：停留时长 > 互动率（评论/点赞/关注）> 商品点击率 > 购买转化率
+- 冷启期（前30场直播）不追 GMV，专注于建立停留时长和互动数据，让算法学习受众画像
+- 成熟直播间的有机流量占比应超过 50%，健康模型是逐步降低付费流量、提升自然流量
+- 五阶段话术框架（留人钩子→产品介绍→信任建立→紧迫成交→追单挽留）是驱动转化率的核心机制
+- 产品排品按功能分层：引流款20%/主推款50%/利润款20%/秒杀款10%，随流量波峰实时切换
+- 停留时长 > 60秒、互动率 > 5%、GPM > 800元、千川ROI > 2.5 是成熟直播间的关键成功指标
+- 付费+有机协同逻辑：用付费流量引入精准用户，靠主播表现产生强互动数据，触发自然流量放大
 
 ## Key Quotes
-> "The core formula is 'traffic x conversion rate x average order value = GMV,' but what truly separates winners from losers is watch time and engagement rate — these two metrics determine whether the platform gives you free traffic." — 流量本质
-
-> "Data priority ranking: watch time > engagement rate > product click-through rate > purchase conversion rate." — 算法权重
-
-> "Hosts are the 'soul' of the live room, but never over-rely on a single host — build a bench." — 人员管理
+> "The core formula is 'traffic x conversion rate x average order value = GMV,' but what truly separates winners from losers is watch time and engagement rate — these two metrics determine whether the platform gives you free traffic." — 核心流量逻辑
+> "Retention first, sell later. Pitching profit items right now is wasting traffic." — 流量低谷时的处置原则
+> "'This product is really good' is saying nothing. Change it to 'I used it for two weeks and the bumps on my forehead went down by half — look at the before and after.' Be specific, paint a picture." — 话术改进原则
+> "Hosts are the 'soul' of the live room, but never over-rely on a single host — build a bench." — 主播管理原则
 
 ## Key Concepts
-- [[Five-Phase Script Framework]]：五阶段话术框架——留人钩子→产品介绍→信任建立→紧迫成交→追单挽留
-- [[GMV]]（Gross Merchandise Value）：直播间成交总额，核心结果指标
-- [[GPM]]（Gross Merchandise Value Per Mille）：每千次曝光成交额，衡量流量效率
-- [[Organic Traffic Amplification]]：自然流量放大——通过停留时长和互动率触发平台推荐算法
-- [[Qianchuan Campaign]]（千川投放）：字节跳动旗下巨量引擎的直播付费投放工具，三大支柱为受众定向×创意素材×出价策略
-- [[Host Incubation System]]：主播孵化体系——从零基础到能独立操盘的进阶路径
-- [[Product Sequencing]]：产品排品策略——根据流量波峰匹配对应产品以最大化转化
+- [[直播话术框架]]：五阶段（留人钩子→产品介绍→信任建立→紧迫成交→追单挽留），驱动转化率的核心机制
+- [[流量三阶段模型]]：冷启期（付费70%+自然30%）→ 成长期（付费50%+自然50%）→ 成熟期（付费30%+自然70%）
+- [[直播产品配比]]：引流款20%/主推款50%/利润款20%/秒杀款10%，随流量波峰实时切换
+- [[停留时长优化]]：目标 > 60秒，通过福袋留存、高频互动、悬念脚本提升
+- [[互动率优化]]：目标 > 5%（评论+点赞/总观众），通过高频提问、选择题、点赞挑战提升
+- [[GPM]]：千次观看 GMV，目标 > 800元，衡量直播间流量变现效率
 
 ## Key Entities
-- [[Douyin]]：抖音，直播电商主阵地，风格定位"快节奏+强人设"
-- [[Kuaishou]]：快手，直播电商核心平台，风格定位"真实感+信任建立"
-- [[OceanEngine]]（巨量引擎）：字节跳动商业化平台，提供千川/Qianniu/超级直播等付费流量工具
-- Taobao Live：淘宝直播，风格定位"专业度+性价比"，适合品牌型直播间
-- Channels（微信视频号）：风格定位"温暖感+私域转化"，与私域运营协同
+- [[Douyin]]：抖音（中国版 TikTok），算法驱动流量爆发，侧重快节奏+强人设，完播率是核心指标
+- [[Kuaishou]]：快手，下沉市场平台，侧重真实性+信任建立，老铁经济社区
+- [[Taobao Live]]：淘宝直播，专业知识型+高性价比，专家人设为主
+- [[Channels]]：微信视频号，私域流量优势，侧重温暖氛围+私域转化
+- [[Qianchuan]]：巨量引擎（原 Ocean Engine）的直播广告投放产品，冷启期核心放大器
 
 ## Connections
-- [[Marketing Douyin Strategist]] ← 内容互补 ← [[marketing-livestream-commerce-coach]]
-- [[Marketing Kuaishou Strategist]] ← 内容互补 ← [[marketing-livestream-commerce-coach]]
-- [[Marketing Private Domain Operator]] ← 协同 ← [[marketing-livestream-commerce-coach]]
-- [[marketing-livestream-commerce-coach]] ← depends_on ← [[Douyin]] / [[Kuaishou]] / [[OceanEngine]]
-- [[Marketing China E-Commerce Operator]] ← 上层整合 ← [[marketing-livestream-commerce-coach]]
+- [[marketing-douyin-strategist]] ← topic_overlap ← [[marketing-livestream-commerce-coach]]（抖音策略侧重短视频+直播双驱动，本教练提供直播操盘战术层）
+- [[marketing-kuaishou-strategist]] ← topic_overlap ← [[marketing-livestream-commerce-coach]]（快手策略侧重下沉市场信任积累，本教练提供通用直播战术层）
+- [[marketing-china-ecommerce-operator]] ← extends ← [[marketing-livestream-commerce-coach]]（电商运营商覆盖淘宝/天猫/拼多多全平台，直播贡献目标占整体 GMV 20%+）
+- [[marketing-private-domain-operator]] ← depends_on ← [[marketing-livestream-commerce-coach]]（直播间作为公域获客入口，私域运营商负责将直播流量沉淀为企业微信资产）
+- [[OceanEngine]] ← provides_tool ← [[marketing-livestream-commerce-coach]]（千川/Qianniu/超级直播等付费流量工具是冷启期的核心放大器）
+- [[marketing-short-video-editing-coach]] ← upstream ← [[marketing-livestream-commerce-coach]]（短视频预热视频是直播间引流的重要来源，剪辑教练提供预热素材制作支持）
 
 ## Contradictions
-- 无已知冲突。本 Source 专注于直播操盘层，与其他 Marketing Sources 的内容营销/SEO/社交媒体策略形成互补而非对立关系。
+- 与 [[marketing-douyin-strategist]] 在流量目标上存在差异：
+  - 冲突点：[[marketing-douyin-strategist]] 强调以 GMV 为锚点进行投放决策；[[marketing-livestream-commerce-coach]] 明确反对以 GMV 为目标，主张以停留时长和互动率为核心指标
+  - 当前观点：本教练认为 GMV 是结果而非原因，以停留时长和互动率为目标才能获得平台自然流量推荐
+  - 对方观点：抖音策略师认为在一定 GMV 基础上通过数据反馈优化投放策略是有效的
diff --git a/wiki/sources/marketing-podcast-strategist.md b/wiki/sources/marketing-podcast-strategist.md
index d63ee386..613f3117 100644
--- a/wiki/sources/marketing-podcast-strategist.md
+++ b/wiki/sources/marketing-podcast-strategist.md
@@ -6,65 +6,49 @@ date: 2026-04-26
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-podcast-strategist.md]]
+- [[Agent/agency-agents/marketing/marketing-podcast-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：中国播客市场内容战略与全漏斗运营专家，提供节目定位、音频制作、听众增长、多平台分发与商业化变现的完整方法论。
-- 问题域：如何在中国播客生态（小宇宙、喜马拉雅、荔枝FM等平台）从零打造并运营一个有持久生命力的音频内容品牌。
-- 方法/机制：
-  - 节目定位四象限（垂直知识/对话访谈/叙事故事/闲聊日常）×受众画像×差异化策略
-  - 内容日历四象限（常青内容/热点内容/系列内容/实验内容）
-  - 制作流程：预录制→录制（本地录制保音质）→后期（降噪/响度归一化-16 LUFS）→多平台分发（RSS同步+手动上传）
-  - 增长飞轮：社区运营（微信群/即刻/小红书）→跨平台引流→嘉宾互推→平台活动参与
-  - 变现路径：品牌赞助→主持人口播广告→付费订阅→付费知识产品→线下活动→私域导流
-- 结论/价值：播客是"慢媒介"，核心竞争力是"人"，完成率比播放量更能反映内容质量，音频质量是底线，固定更新节奏比频繁更新更重要。
+- 核心主题：中国播客市场内容策略与全漏斗运营专家，涵盖节目定位、音频制作、受众增长、多平台分发与商业化变现。
+- 问题域：播客创作者如何从零开始打造可持续的音频内容品牌，在中国小宇宙、喜马拉雅等主流平台实现增长与盈利。
+- 方法/机制：五阶段工作流（诊断定位→内容规划→制作发布→推广增长→数据分析迭代）；多平台差异化运营策略；全漏斗变现体系（品牌赞助→付费订阅→知识付费→私域导流）。
+- 结论/价值：播客是"慢媒介"，追求长期听众信任与粘性；音频质量是底线；主持人的个性魅力和领域深度是不可复制的护城河。
 
 ## Key Claims（用中文描述）
-- 小宇宙是中国播客用户最集中、用户社区氛围最强的平台，适合品牌播客广告投放。
-- 播客的本质是"陪伴媒介"——听众戴上耳机时，主播的声音成为通勤、睡前、静夜中最亲密的陪伴。
-- 音频质量是底线——无论内容多优秀，糟糕的音质都会流失听众。
-- 完成率比播放量更能反映内容质量——一个完整听完的 episode 远比一个被跳过的 episode 有价值。
-- 固定更新节奏比频繁更新更重要——稳定的节奏帮助听众养成收听习惯。
-- 播客的核心竞争优势是"人"——主播的人格魅力和领域深度是无法复制的护城河。
-- RSS 是播客分发的核心基础设施——一个 feed 可同步至所有平台。
+- 小宇宙是中国播客用户最集中、社区氛围最浓厚的平台，时间戳评论、节目互推和话题广场构成强社区属性。
+- 播客核心竞争优势是"人"——主持人的个性魅力和领域深度是播客不可复制的护城河。
+- 完播率比播放量更能揭示内容质量——一个完整听完的episode价值远超被跳过的episode。
+- 音频质量是底线——无论内容多好，糟糕的音质会让听众流失。
+- 播客是"慢媒介"——不追求爆发式增长，追求长期听众信任和粘性。
+- 一致性发布比频繁发布更重要——固定节奏让听众养成收听习惯。
 
 ## Key Quotes
-> "Podcasting's core is 'companionship.' The moment listeners put on their headphones, your voice becomes their most intimate companion during commutes, before sleep, and through quiet evenings." — 播客本质的核心洞察
-> "Audio quality is the floor; no matter how great the content, poor audio will lose listeners." — 音频质量底线原则
-> "Completion rate reveals content quality far better than play count — one fully-listened episode outweighs one that gets skipped." — 完成率指标意义
-> "A podcast's core competitive advantage is 'people' — the host's personality and domain depth are the irreplicable moat." — 核心竞争力来源
-> "Podcasting is a 'slow medium' — don't chase explosive growth; pursue long-term listener trust and stickiness." — 运营心态
+> "Podcast is a slow medium — don't chase explosive growth; pursue long-term listener trust and stickiness." — 播客媒介的本质定位
+> "Completion rate reveals content quality far better than play count — one fully-listened episode outweighs one that gets skipped." — 评估指标的核心原则
+> "Audio quality is the floor; no matter how great the content, poor audio will lose listeners." — 音频质量的底线地位
+> "The host's personality and domain depth are the irreplicable moat." — 播客核心竞争力的本质
 
 ## Key Concepts
-- [[Podcast Positioning]]：节目定位四象限——垂直知识/对话访谈/叙事故事/闲聊日常，决定内容方向和目标受众
-- [[Content Calendar]]：内容日历管理，按常青内容/热点内容/系列内容/实验内容四象限规划，确保内容多样性
-- [[RSS Feed Management]]：RSS 是播客多平台分发的核心基础设施，一个 feed 同步全平台
-- [[Audio Production Standards]]：播客音频制作标准，包括录制（WAV格式）、混音、母带处理，响度归一化至 -16 LUFS
-- [[Completion Rate]]：完成率，比播放量更重要的内容质量指标，反映听众粘性
-- [[Host-read Ads]]：主持人口播广告，以主播个人风格传递，强调真实体验和真诚推荐，效果优于纯品牌广告
-- [[Private Domain Traffic]]：私域流量运营，将播客听众导入微信社群/企微，作为长期变现基础
-- [[Multi-platform Distribution]]：多平台分发策略——RSS 自动同步（小宇宙/Apple Podcasts/Spotify）+ 手动上传（喜马拉雅/荔枝FM）
-- [[Audio-first Thinking]]：音频优先思维——在内容结构上每 10-15 分钟设置一个钩子，保持听众注意力
+- [[PodcastFormatTypes]]：节目形式分类——垂直知识（深度垂直领域）、对谈访谈（嘉宾驱动）、叙事故事（纪录片/虚构）、轻松闲聊（日常话题）
+- [[PodcastMonetization]]：播客变现体系——品牌赞助系列/冠名、主持人口播广告、付费订阅、付费知识产品、线下活动、电商、引流私域
+- [[PodcastDistribution]]：多平台分发策略——RSS同步到小宇宙/Apple Podcasts/Spotify；手动上传喜马拉雅/荔枝/蜻蜓等不支持RSS的平台
+- [[AudienceGrowthStrategy]]：受众增长策略——社群运营（微信群/即刻/小红书）、跨平台引流、嘉宾互推、节目间合作、口碑增长、平台活动参与
+- [[AudioProduction]]：音频制作规范——录音用WAV格式，发布用MP3 128-192kbps或AAC；响度标准化-16 LUFS
 
 ## Key Entities
-- [[Xiaoyuzhou]]：小宇宙播客平台，中国播客用户最集中、社区氛围最强的平台，核心分发渠道
-- [[Ximalaya]]：喜马拉雅，中国用户规模最大的中文音频平台，覆盖有声书/广播剧/播客，适合付费知识变现
-- [[Lizhi FM]]：荔枝FM，UGC 特征明显，直播音频功能突出，适合情感类和声音类内容
-- [[Qingting FM]]：蜻蜓FM，PGC 导向，车载收听场景渗透率高，适合新闻和知识类内容
-- [[Typlog]]：播客托管平台，中国友好，支持自定义域名、analytics 和 RSS 生成
-- [[Zencastr]]：远程录制工具，支持各参与者本地独立录音，避免网络压缩损伤音质
-- [[Shure SM7B]]：专业动圈麦克风，推荐用于非专业录音环境的播客录制
-- [[RØDECaster Pro]]：RODE 出品的播客专用混音台，支持多人同时录制和实时音效
+- [[Xiaoyuzhou]]：小宇宙——中国播客用户最集中平台，双引擎发现（算法+编辑推荐），品牌播客广告首选平台
+- [[Ximalaya]]：喜马拉雅——最大中文音频平台，用户基数最大，播客用户精准度不及小宇宙，适合付费知识和音频课程变现
+- [[LizhiFM]]：荔枝——强UGC属性，直播音频功能突出，适合情感和声音内容
+- [[QingtingFM]]：蜻蜓FM——PGC内容导向，车载场景渗透率高，适合新闻和知识内容
+- [[ShureSM7B]]：专业播客麦克风，动圈式，抗噪强，适合非专业录音空间
 
 ## Connections
-- [[Marketing Content Creator]] ← extends ← [[Marketing Podcast Strategist]]：播客策略师是内容创作者的音频专项延伸
-- [[Marketing Social Media Strategist]] ← depends_on ← [[Marketing Podcast Strategist]]：播客内容需要社媒策略配合进行跨平台推广
-- [[Marketing WeChat Official Account Manager]] ← depends_on ← [[Marketing Podcast Strategist]]：播客变现依赖微信公众号等内容矩阵
-- [[Marketing Private Domain Operator]] ← depends_on ← [[Marketing Podcast Strategist]]：播客听众转化为私域流量是变现关键路径
+- [[Marketing Bilibili Content Strategist]] ← extends ← [[Marketing Podcast Strategist]]（Bilibili与播客均为内容媒介，但平台特性不同）
+- [[Marketing Content Creator]] ← depends_on ← [[Marketing Podcast Strategist]]（播客内容创作是多平台内容策略的一部分）
+- [[Marketing Weibo Strategist]] ← extends ← [[Marketing Podcast Strategist]]（微博用于播客推广和跨平台引流）
+- [[Marketing Xiaohongshu Specialist]] ← extends ← [[Marketing Podcast Strategist]]（小红书用于播客预告和精华片段分发）
+- [[Marketing Douyin Strategist]] ← extends ← [[Marketing Podcast Strategist]]（抖音用于播客精华片段短视频分发）
+- [[Marketing Private Domain Operator]] ← extends ← [[Marketing Podcast Strategist]]（私域运营是播客变现闭环的关键环节）
 
 ## Contradictions
-- 与 [[Marketing Short-Video Editing Coach]] 潜在冲突：
-  - 冲突点：内容生产节奏——短视频追求高频爆款，播客追求稳定节奏
-  - 当前观点：播客是"慢媒介"，固定节奏比频繁更新更重要
-  - 对方观点：短视频需要高频产出才能维持算法曝光
-  - 协调方案：两者定位不同，播客适合深度内容+长尾流量，短视频适合快节奏热点追踪，可并行运营但节奏管理策略需分开
+- 无已知冲突——播客策略与同系列其他营销专家 Agent 的策略高度互补，未发现直接矛盾。
diff --git a/wiki/sources/marketing-reddit-community-builder.md b/wiki/sources/marketing-reddit-community-builder.md
index 6ce57364..95c43d20 100644
--- a/wiki/sources/marketing-reddit-community-builder.md
+++ b/wiki/sources/marketing-reddit-community-builder.md
@@ -2,56 +2,54 @@
 title: "Marketing Reddit Community Builder"
 type: source
 tags: []
-date: 2026-04-26
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-reddit-community-builder.md]]
+- [[Agent/agency-agents/marketing/marketing-reddit-community-builder.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 角色定义——以 Reddit 文化专家身份，通过真实的价值贡献和长期关系培养，在 Reddit 上建立品牌影响力。
-- 问题域：品牌如何在 Reddit 上避免被当作垃圾信息移除，同时建立可信度和社区信任。
-- 方法/机制：四阶段执行框架（社区研究与整合 → 内容策略开发 → 社区建设与声誉管理 → 战略价值创造），核心规则为 90/10 价值法则（90% 价值内容，10% 推广内容）。
-- 结论/价值：成功的 Reddit 营销不在于推广，而在于成为社区中有价值的成员，品牌通过持续提供价值而非活动性推广来实现长期增长。
+- 核心主题：AI Agent 作为 Reddit 社区营销专家，通过真实价值创造而非推销来建立品牌社区影响力
+- 问题域：品牌如何在 Reddit 这一独特的社区生态系统中建立真实、可信的品牌形象，避免被视为垃圾信息
+- 方法/机制：90/10 价值法则 → 四阶段工作流（社区研究 → 内容策略 → 声誉建立 → 战略价值创造）→ 长期关系经营
+- 结论/价值：Reddit 营销成功的关键是"成为有价值贡献的社区成员"，而非"在 Reddit 上做营销"
 
 ## Key Claims（用中文描述）
-- 主体 + 机制 + 结果：Reddit 用户对 promotion 敏感——品牌通过 90% 价值内容 + 10% 推广内容的组合——实现被社区接受并积累信任，而非被标记为垃圾信息。
-- 主体 + 机制 + 结果：品牌通过 subreddit 研究、规则掌握和无推广意图的参与——融入目标社区——成为可信成员而非外来推销员。
-- 主体 + 机制 + 结果：品牌通过多月的持续参与（而非活动性推广）——建立社区声誉——实现 Trusted Contributor 状态（5+ 相关 subreddit）和自然品牌提及。
-- 主体 + 机制 + 结果：品牌通过 AMA 协调、教育系列和社区挑战——提供战略价值——获得 500+ 问答的深度互动和 80%+ 正面情绪品牌讨论。
+- 品牌通过 90% 价值内容 + 10% 推广内容的配比，在 Reddit 建立可信任的品牌形象
+- 在 5+ 个相关子版块获得可信贡献者身份，综合 karma 达到 10,000+ 
+- 教育内容 upvote 比例达到 85%+，每条帮助性评论平均获得 5+ upvotes
+- 通过 AMA 协调实现 500+ 条问答互动，带来 15% 有机流量增长
+- Reddit 广告需原生融入社区价值而非硬性推广
 
 ## Key Quotes
-> "Remember: You're not marketing on Reddit - you're becoming a valued community member who happens to represent a brand." — 核心定位：营销 Reddit 不是在 Reddit 上做营销，而是成为有价值社区成员
+> "You're not marketing on Reddit - you're becoming a valued community member who happens to represent a brand." — 核心理念
 
-> "90/10 Rule: 90% value-add content, 10% promotional (maximum)" — 比例法则：每发布 10 条内容，最多 1 条可以涉及推广
+> "Success comes from giving more than you take and building genuine relationships over time." — 长期主义
 
-> "Community Guidelines: Strict adherence to each subreddit's specific rules" — 每个 subreddit 都有独特规则，违反即被移除
+> "Always prioritize community benefit over company interests." — 社区优先原则
 
 ## Key Concepts
-- [[90-10-Rule]]：Reddit 营销核心原则，要求 90% 价值内容 + 10% 推广内容，严格限制品牌推广占比。
-- [[Community-First-Engagement]]：关系优先策略——先帮助社区成员、解决问题，再自然引入品牌价值。
-- [[Subreddit-Research]]：社区研究流程——识别主要/次要/本地/细分社区，学习规则、文化、时机和版主关系。
-- [[AMA-Coordination]]：Ask Me Anything 协调——主题专家主持的深度互动活动，需提前准备话题和预期问题。
-- [[Reputation-Management]]：声誉管理——监控品牌提及、进行情绪分析、真实回应社区讨论，优先社区利益。
-- [[Reddit-Advertising-Integration]]：Reddit 广告整合——推广内容提供价值而非直接推销，保持透明度和社区原生语调。
+- [[90/10 Rule]]：90% 价值内容，10% 推广内容的 Reddit 营销黄金比例
+- [[Community-First Engagement]]：社区优先的参与策略，优先帮助个体而非批量推广
+- [[Subreddit Targeting]]：子版块精准定位策略，平衡大规模触达与深度互动
+- [[AMA (Ask Me Anything)]]：AMA 协调机制，最大化社区参与和品牌曝光
+- [[Reputation Management]]：声誉监控与情感分析，主动响应品牌讨论
+- [[Reddit-Native Voice]]：Reddit 原生语言风格，理解平台文化和社区偏好
 
 ## Key Entities
-- [[Reddit]]：核心平台——全球最大社区讨论平台之一，以反推广文化著称，需要深度文化理解才能有效运营。
-- [[Subreddit]]：细分社区——Reddit 的子论坛，每个有独特规则、文化、术语和用户偏好，需针对性研究。
-- [[Brand-Presence]]：品牌存在——在 Reddit 上通过真实价值贡献建立的长期、可信、可识别的品牌身份。
-- [[Community-Karma]]：社区积分——衡量 Reddit 账号在社区中声誉的指标，目标是 10,000+ 综合积分。
-- [[Trusted-Contributor]]：可信贡献者——在 subreddit 中通过持续帮助建立的高级社区身份，享受更大自由度和信任。
+- Reddit：核心社交平台，独特的社区文化和子版块生态系统
+- Subreddit：子版块，Reddit 社区的基本组织单位，各有独特规则和文化
+- Community Karma：社区声望值，衡量用户可信度和贡献质量的指标
+- Upvote Ratio：赞同率，内容质量的信号指标
+- Moderator：版主，社区规则执行者，与品牌建立正面关系的关键对象
 
 ## Connections
-- [[Marketing-Zhihu-Strategist]] ← builds_on ← [[Marketing-Reddit-Community-Builder]]：知乎策略与中国版"Reddit"运营都强调社区第一、长期关系，方法论相似但文化背景不同。
-- [[Marketing-Douyin-Strategist]] ← extends ← [[Marketing-Reddit-Community-Builder]]：抖音策略与 Reddit 策略都重视内容为王，但抖音更侧重短视频娱乐形式。
-- [[Marketing-Social-Media-Strategist]] ← depends_on ← [[Marketing-Reddit-Community-Builder]]：社交媒体策略 Agent 以 Reddit 社区建设原则为内容策略基础。
-- [[Content-Factory]] ← feeds_into ← [[Marketing-Reddit-Community-Builder]]：多渠道内容工厂提供 Reddit 所需的教育性、价值型内容素材。
-- [[Daily-Reddit-Digest]] ← depends_on ← [[Marketing-Reddit-Community-Builder]]：Reddit 每日摘要 Agent 依赖此社区建设 Agent 的 Reddit 文化理解能力。
+- [[Marketing Social Media Strategist]] ← depends_on ← [[Marketing Reddit Community Builder]]
+- [[Marketing Twitter Engager]] ← extends ← [[Community-First Engagement]]
+- [[Marketing Cross-Border Ecommerce]] ← shares_karma_system ← [[Community Karma]]
 
 ## Contradictions
-- 与 [[Marketing-Short-Video-Editing-Coach]] 潜在冲突：
-  - 冲突点：短视频平台追求即时爆款（点赞/完播率），Reddit 追求长期信任（积累型）
-  - 当前观点：Reddit 营销是"以月/年为周期"的关系建设，不适合活动性推广
-  - 对方观点：抖音/TikTok 等短视频平台需要快速、高频、可量化的内容产出节奏
-  - 调和思路：两者都遵循"受众价值优先"原则，区别在于时间维度和内容形式，而非根本矛盾
+- 与传统社交媒体营销的即时转化思维冲突：
+  - 冲突点：短期 ROI vs 长期社区价值
+  - 当前观点（本文）：以季度/年为周期建立关系，不追求即时转化
+  - 对方观点：营销需追求即时可衡量的转化效果
diff --git a/wiki/sources/marketing-seo-specialist.md b/wiki/sources/marketing-seo-specialist.md
index e0979963..e49f75ed 100644
--- a/wiki/sources/marketing-seo-specialist.md
+++ b/wiki/sources/marketing-seo-specialist.md
@@ -1,66 +1,63 @@
 ---
 title: "Marketing SEO Specialist"
 type: source
-tags: ["seo", "marketing", "organic-search", "technical-seo"]
-date: 2026-04-25
+tags: ["marketing", "seo", "organic-search", "technical-seo", "content-strategy"]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-seo-specialist.md]]
+- [[Agent/agency-agents/marketing/marketing-seo-specialist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：搜索引擎优化（SEO）专家 Agent，负责通过技术 SEO、内容优化、链接权威建设和搜索分析实现可持续的有机流量增长。
-- 问题域：如何通过白帽 SEO 方法提升网站的有机搜索可见性，包括关键词策略、内容集群规划、内部链接架构、技术健康度监控以及算法更新应对。
-- 方法/机制：
-  - 五阶段工作流（发现→关键词策略→技术执行→权威建设→测量迭代）
-  - 关键词主题集群架构（Pillar + Satellite 模式）
-  - 内容 cannibalization 检测（强制在所有优化前执行）
-  - Core Web Vitals 性能基准（LCP<2.5s, INP<200ms, CLS<0.1）
-  - 数字公关 + 内容驱动型外链获取
-- 结论/价值：数据驱动的 SEO 策略必须以用户搜索意图为核心，排名是价值的自然结果；SEO 效果需要数月才能显现，非短期行为。
+- **核心主题**：SEO专家Agent人格定义——通过技术SEO、内容策略和链接权威建设实现可持续的有机搜索增长
+- **问题域**：搜索引擎优化策略制定、技术SEO审计、关键词研究、内容优化、链接建设、搜索分析
+- **方法/机制**：五阶段工作流程（发现与技术支持→关键词策略→站内优化执行→权威建设→测量迭代）；严格的关键词 cannibalization 审计必须在任何优化前完成；数据驱动的决策方法
+- **结论/价值**：提供白帽SEO最佳实践框架，涵盖技术SEO审计模板、关键词研究框架、cannibalization 审计模板、页面优化清单、链接建设策略等完整工具集
 
 ## Key Claims（用中文描述）
-- SEO 专家通过技术精准性、内容权威性和持续测量来构建可持续的有机搜索可见性。
-- 在提出任何标题标签、H1 或内容变更之前，必须运行跨页面 cannibalization 检查。
-- 每个目标关键词只能有一个权威页面（Owner Page），不得重复目标主关键词。
-- 排名变化必须基于足够数据才能判定为趋势，避免猜测。
-- 白帽 SEO 是唯一合规方式，禁止任何链接方案、cloaking、关键词填充等违规操作。
-- E-E-A-T（经验、专业性、权威性、可信性）是所有内容优化的合规基础。
-- 搜索控制台 API 是大规模 SEO 性能分析的核心数据源。
+- SEO专家Agent通过技术卓越、高质量内容和权威链接档案的交叉点实现可持续有机增长
+- 在提出任何标题标签、H1、元描述或内容变更前，必须运行跨页面 cannibalization 审计（强制性规则）
+- 每个目标关键词只分配给一个权威页面；多个页面竞争同一关键词会导致 cannibalization
+- E-E-A-T合规：所有内容推荐必须展示经验、专业性、权威性和可信度
+- Core Web Vitals不可妥协：LCP < 2.5s，INP < 200ms，CLS < 0.1
+- 有机流量同比增长50%+、目标关键词组合30%+进入前三名是有意义的关键成功指标
 
 ## Key Quotes
-> "Sustainable organic growth comes from the intersection of technical excellence, high-quality content, and authoritative link profiles." — 核心身份定位
-> "Rankings follow value — every optimization must serve the user's search intent." — 用户意图优先原则
-> "E-E-A-T compliance: all content recommendations must demonstrate Experience, Expertise, Authoritativeness, and Trustworthiness." — E-E-A-T 合规要求
-> "SEO compounds over months, not days." — SEO 时间预期
+> "Sustainable organic growth comes from the intersection of technical excellence, high-quality content, and authoritative link profiles."
+> — 核心身份定义
+
+> "Every optimization must serve the user's search intent — rankings follow value."
+> — 用户意图优先原则
+
+> "No Guesswork: Base keyword targeting on actual search volume, competition data, and intent classification."
+> — 数据驱动决策
 
 ## Key Concepts
-- [[TopicClusterArchitecture]]：主题集群架构 — 通过 Pillar Page（支柱页面）和 Satellite Page（卫星页面）的层次结构建立主题权威性
-- [[ContentCannibalization]]：内容 cannibalization — 同一关键词被多个页面竞争排名的现象，必须在优化前解决
-- [[CoreWebVitals]]：核心网页指标 — Google 排名的性能基准（LCP、INP、CLS）
-- [[E-E-A-T]]：经验、专业性、权威性、可信性 — Google 搜索质量指南的核心评估维度
-- [[FeaturedSnippet]]：精选摘要 — SERP 中的高价值富结果，通过结构化数据和内容格式化获取
-- [[SchemaMarkup]]：结构化数据标记 — 帮助搜索引擎理解页面内容、提升富结果展示
-- [[SearchIntent]]：搜索意图 — 分为信息型、商业调查型、交易型，决定内容形式
-- [[InternalLinking]]：内部链接策略 — 分配链接权重、建立主题关联的核心手段
-- [[LinkAuthorityBuilding]]：链接权威建设 — 通过数字公关、内容资产和外展获取高质量反向链接
-- [[SERPFeature]]：SERP 功能 — 精选摘要、People Also Ask、知识面板等影响有机点击的搜索结果形式
-- [[ProgrammaticSEO]]：程序化 SEO — 模板化页面生成，用于大规模长尾关键词覆盖
-- [[AISearchOptimization]]：AI 搜索优化 — 针对 AI 生成搜索概览的优化策略
+- [[KeywordCannibalizationAudit]]：跨页面查询映射，识别冲突并分配单一权威页面所有权
+- [[TopicClusterArchitecture]]：主题集群架构，支柱页面与卫星内容页的层级设计
+- [[E-E-A-TCompliance]]：经验、专业性、权威性、可信度合规内容标准
+- [[CoreWebVitals]]：网页核心指标，LCP/INP/CLS性能阈值
+- [[TechnicalSEOAudit]]：技术SEO审计，涵盖爬行性、索引率、性能和结构化数据
+- [[LinkAuthorityBuilding]]：链接权威建设，通过数字公关、内容资产和战略性外展获取高质量反向链接
+- [[SearchIntentMapping]]：搜索意图映射，将关键词分类为信息型、商业调查型、交易型
+- [[SERPFitureOptimization]]：SERP功能优化，争夺精选摘要、People Also Ask、知识面板和富结果
 
 ## Key Entities
-- [[ScreamingFrog]]：网站爬虫工具 — 用于技术 SEO 审计的爬取分析
-- [[Sitebulb]]：技术 SEO 审计工具 — 可替代 Screaming Frog 的深度分析工具
-- [[GoogleSearchConsole]]：Google 搜索控制台 — 关键词数据、索引覆盖、性能分析的核心数据源
-- [[LookerStudio]]：Google 数据可视化工具 — 用于自动化 SEO 报表仪表盘
+- [[WebFetch]]：Agent工具之一，用于网页内容获取
+- [[WebSearch]]：Agent工具之一，用于搜索引擎数据查询
+- [[GoogleSearchConsole]]：搜索分析数据来源（GSC），用于cannibalization审计和性能分析
+- [[ScreamingFrog]]：技术SEO爬行工具（等效分析）
+- [[SchemaMarkup]]：结构化数据标记系统
+- [[LookerStudio]]：搜索控制台和仪表盘创建工具
 
 ## Connections
-- [[MarketingBaiduSEOSpecialist]] ← extends_general_seo_concept ← [[MarketingSEOSpecialist]]
-- [[MarketingContentCreator]] ← supports_content_layer ← [[MarketingSEOSpecialist]]
-- [[MarketingSocialMediaStrategist]] ← drives_awareness ← [[MarketingSEOSpecialist]]（社交分享带来外链）
-- [[MarketingGrowthHacker]] ← employs ← [[MarketingSEOSpecialist]]（增长黑客框架整合 SEO）
-- [[ProgrammaticSEO]] ← applies_to ← [[MarketingSEOSpecialist]]
-- [[AISearchOptimization]] ← extends ← [[MarketingSEOSpecialist]]
+- [[MarketingBaiduSEOSpecialist]] ← shares_workflow ← [[MarketingSEOSpecialist]]
+- [[MarketingContentCreator]] ← feeds_content ← [[MarketingSEOSpecialist]]
+- [[MarketingGrowthHacker]] ← integrates_with ← [[MarketingSEOSpecialist]]
+- [[MarketingAppStoreOptimizer]] ← shares_technical ← [[MarketingSEOSpecialist]]
 
 ## Contradictions
-- 与 [[MarketingBaiduSEOSpecialist]]：两者虽同为 SEO 专家，但目标搜索引擎不同（Baidu vs Google），搜索算法、关键词匹配规则、链接评估方式存在差异，不可直接套用策略。
+- 与 [[MarketingGrowthHacker]] 的快速增长策略对比：
+  - 冲突点：增长黑客强调速度和短期效果；SEO专家强调长期可持续性和数据严谨性
+  - 当前观点：SEO专家坚持白帽方法，拒绝任何违反搜索引擎指南的做法
+  - 对方观点：增长黑客可能包含付费增长和病毒式营销元素
diff --git a/wiki/sources/marketing-short-video-editing-coach.md b/wiki/sources/marketing-short-video-editing-coach.md
index 38cbdc63..1a4140ca 100644
--- a/wiki/sources/marketing-short-video-editing-coach.md
+++ b/wiki/sources/marketing-short-video-editing-coach.md
@@ -1,71 +1,60 @@
 ---
 title: "Marketing Short-Video Editing Coach"
 type: source
-tags: [marketing, video-editing, short-video, post-production]
-date: 2026-04-21
+tags: [marketing, video-editing, post-production]
+date: 2026-05-16
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-short-video-editing-coach.md]]
+- [[Agent/agency-agents/marketing/marketing-short-video-editing-coach.md]]
 
 ## Summary（用中文描述）
-- 核心主题：短视频剪辑技术教练 Agent，覆盖完整后期制作流水线，涵盖剪辑软件选择、构图摄影语言、色彩调色、音频工程、动态图形、AI辅助剪辑等全链路技能。
-- 问题域：如何将原始素材快速转化为专业级短视频内容；如何选择适合不同场景的剪辑工具；如何在保证质量前提下提升剪辑效率。
-- 方法/机制：软件选择决策树（CapCut/Pr/DaVinci/FinalCut各有所长）→ 镜头语言体系（景别/运镜/转场）→ 二元色彩体系（初级校正恢复真实 + 次级调色风格化）→ 音频三步骤（降噪→增强→混音）→ 模板化批量生产 → AI辅助提速。
-- 结论/价值：剪辑的核心不是软件熟练度，而是叙事能力和节奏感；软件是工具，叙事是灵魂；AI承担60%工作量，剩余40%创意打磨仍需人工。
+- 核心主题：短视频剪辑全流程专家 Agent，覆盖从素材到成片的完整后期制作管线
+- 问题域：如何将原始素材剪辑成高完播率、高互动率的短视频作品
+- 方法/机制：软件选型决策树 → 构图与镜头语言 → 调色 → 音频工程 → 字幕设计 → 多平台导出优化 → AI辅助剪辑
+- 结论/价值：剪辑的核心不是软件熟练度，而是节奏感和叙事能力；AI承担60%工作，剩余40%创意精修仍需人工介入
 
 ## Key Claims（用中文描述）
-- CapCut Pro + Premiere Pro + DaVinci Resolve + Final Cut Pro 四大软件各有最优场景，剪辑师应精通一款主工具并熟悉 CapCut（AI功能不可忽视）。
-- 短视频黄金法则：前3秒必须出现视觉钩子（通常为特写或大特写镜头）。
-- 色彩调色不是"加滤镜"——不先做初级校正就直接套创意LUT，必然导致色彩崩坏。
-- 音频优先于视频——观众可以忍受平庸的画面，但无法忍受刺耳/噪音/音量跳跃的音频。
-- LUT是不完美的起点，60%-80%强度最合适，100%通常过重。
-- 模板化后，单视频制作时间从2小时降至30分钟。
-- AI自动字幕准确率虽高（95%+），但技术术语、方言、重叠说话人仍需人工审核。
-- AI生成的视频"能看但没有灵魂"——AI处理60%工作，剩余40%创意打磨仍需人工介入。
+- 剪辑师的"剪辑思维"比软件技能更重要——每个剪辑点必须有理由，每个镜头必须"值得存在"
+- 画质问题（分辨率不足/码率过低/过曝）是无解的致命缺陷，创意无法弥补
+- 音频质量与视频质量同等重要——观众可以忍受一般画质，但无法忍受刺耳或不同步的音频
+- 效率是生产力的核心——模板能解决就不要手动，AI能辅助就不要纯手动
+- CapCut为首选工具（AI功能最强），至少精通一款主工具并熟悉CapCut的AI能力
 
 ## Key Quotes
-> "The core of editing isn't software proficiency - software is just a tool. What truly separates amateurs from professionals is pacing sense, narrative ability, and the obsession that 'every frame must earn its place'" — 剪辑理念核心定义
-> "Transitions serve the narrative, not the ego - if a hard cut works, don't add a fancy transition" — 转场设计原则
-> "A LUT is a starting point, not the finish line - always fine-tune parameters after applying" — LUT使用规范
-> "Voice is always priority number one; the BGM must yield to voice" — 音频混音黄金法则
-> "AI-generated videos are 'watchable but soulless' - they handle 60% of the work, but the remaining 40% of creative refinement still requires human craft" — AI辅助剪辑定位
+> "Every frame must earn its place." — 剪辑核心原则：每个镜头必须有其存在的理由
+> "A LUT is a starting point, not the finish line." — LUT使用原则：应用LUT后必须微调参数
+> "Transitions serve the narrative, not the ego." — 过渡设计原则：如果硬切能工作，就不要添加花哨过渡
+> "Voice is always priority number one; the BGM must yield to voice." — 音频混音原则：人声永远优先于BGM
+> "AI generates watchable but soulless content — it handles 60% of the work, the remaining 40% still requires human craft." — AI辅助剪辑的局限性
 
 ## Key Concepts
-- [[Speed-Ramping]]：速度曲线变速技术，实现单片段内"快-慢-快"节奏，是短视频最常用的动态剪辑手法。
-- [[Color-Grading]]：色彩调色——在初级校正（白平衡/曝光/对比度）基础上，通过HSL曲线/遮罩实现风格化视觉效果。
-- [[LUT]]（Look-Up Table）：色彩查找表，本质是预设颜色映射；技术LUT转换LOG素材，创意LUT添加风格化外观；强度建议60%-80%。
-- [[Beat-Sync]]：BGM节拍同步——在BGM重拍/重音处切点，实现音画合一冲击力；不必每个节拍都切，只需在强拍和转场点同步。
-- [[Keyframe-Animation]]：关键帧动画——定义起点和终点状态，软件自动插值中间运动；贝塞尔曲线是关键灵魂。
-- [[Proxy-Editing]]：代理编辑——从4K/6K原始素材生成低分辨率代理文件用于编辑，最终导出时重新链接原始文件，是高分辨率工作流必备技术。
-- [[Template-Based-Production]]：模板化批量生产——通过预设时间线布局/色彩预设/字幕样式/片头片尾模板，将单视频制作时间压缩至30分钟。
-- [[AI-Assisted-Editing]]：AI辅助剪辑——自动字幕（95%+准确率）/智能抠像/文字生成视频/数字人配音，承担60%重复性工作，保留40%人工创意打磨。
-- [[Shot-Scales]]：镜头景别体系——建立/全景/中景/特写/大特写，每种景别有不同的叙事功能和情感效果。
-- [[Audio-Mix-Balance]]：音频混音平衡——人声为主（-12dB至-6dB），BGM为辅（-24dB至-18dB），音效点缀（-18dB至-12dB）。
+- [[剪辑思维（Editing Mindset）]]：叙事优先于技术，每个剪辑点必须有叙事理由，而非炫技
+- [[Speed Ramping（速度曲线）]]：实现"快-慢-快"节奏，经典模式：动作前慢动作蓄力 → 动作正常速 → 动作后慢动作回味
+- [[Beat-Sync（节拍同步）]]：在BGM的强拍/转换点剪辑，实现视听冲击；仅同步强拍，避免每拍都剪导致节奏疲劳
+- [[Color Grading]]：分为主级校正（还原真实曝光/白平衡）和二级调色（风格化处理）；风格方向包括Cinematic、Cyberpunk、Morandi等
+- [[LUT应用]]：LUT是起点而非终点，应用后需以60%-80%不透明度微调，不可用100%
+- [[Proxy Editing（代理剪辑）]]：4K/6K素材先转为低分辨率代理文件剪辑，输出前再链接原始文件
+- [[AI-Assisted Editing]]：AI负责字幕生成/智能抠像/音乐生成/数字人配音，但60%工作仍需人工创意精修
+- [[多平台导出策略]]：竖屏9:16（抖音/快手/小红书）、横屏16:9（B站/YouTube）各有不同分辨率/帧率/码率要求
 
 ## Key Entities
-- [[CapCut-Pro]]：剪映专业版（ByteDance出品）——主推日常短视频高效输出，AI功能业界领先（自动字幕/智能抠像/一键成片），最适合个人创作者和MCN批量生产团队；局限性：复杂VFX能力有限，大项目性能瓶颈。
-- [[Adobe-Premiere-Pro]]：Adobe专业视频编辑软件——行业标准，与AE/AU/PS无缝集成，插件生态最丰富；最适合专业剪辑师和广告制作团队；局限性：大型项目容易卡顿，订阅费用高。
-- [[DaVinci-Resolve]]：Blackmagic Design专业调色软件——免费版已极强大，调色面板是行业标准，Fairlight音频工作站+Fusion节点式VFX；最适合调色师和追求极致视觉质量的创作者；局限性：学习曲线最陡。
-- [[Final-Cut-Pro]]：Apple专业视频编辑软件——原生Mac优化（M系列芯片性能出色），磁力时间线效率极高，一次买断无订阅；最适合Mac用户和YouTube创作者；局限性：Mac独占，团队协作生态较弱。
-- [[OpenAI-Whisper]]：开源语音识别模型——支持99种语言，离线可用，极高准确率，是AI自动字幕的核心工具之一。
-- [[Suno-AI]]：AI音乐生成平台——通过文本描述生成原创音乐，适合快速生成定制BGM规避版权问题。
+- [[CapCut Pro]]：首选工具，AI功能最强（自动字幕/智能抠像/一键生成），最适合日更短视频产出
+- [[Adobe Premiere Pro]]：行业标准，与AE/AU/PS无缝集成，最适合中大型商业项目
+- [[DaVinci Resolve]]：免费版已极强大，调色行业标准（DaVinci调色面板），适合高质量调色需求
+- [[Final Cut Pro]]：Mac原生优化，磁性时间线提升效率，一次购买无订阅，适合Mac用户
+- [[Suno AI]]：AI音乐生成工具，输入文字描述生成原创音乐，避免版权问题
+- [[OpenAI Whisper]]：开源离线语音识别，支持99种语言，字幕生成的AI工具
 
 ## Connections
-- [[Marketing-Douyin-Strategist]] ← depends_on ← [[marketing-short-video-editing-coach]]（抖音运营依赖剪辑技能）
-- [[Marketing-Kuaishou-Strategist]] ← depends_on ← [[marketing-short-video-editing-coach]]（快手短视频依赖剪辑技能）
-- [[Marketing-Video-Optimization-Specialist]] ← extends ← [[marketing-short-video-editing-coach]]（YouTube视频优化是剪辑技能的横版延伸）
-- [[Marketing-Social-Media-Strategist]] ← depends_on ← [[marketing-short-video-editing-coach]]（社媒内容生产依赖视频剪辑）
-- [[AI-Assisted-Editing]] ← related_to ← [[marketing-short-video-editing-coach]]（AI辅助剪辑是该Coach的核心能力之一）
+- [[Marketing Video Optimization Specialist]] ← depends_on ← [[Marketing Short-Video Editing Coach]]
+- [[Marketing Douyin Strategist]] ← extends ← [[Marketing Short-Video Editing Coach]]（抖音平台导出优化）
+- [[固定镜头短视频制作的ai全流程解析]] ← relates_to ← [[Marketing Short-Video Editing Coach]]（AI工具选型互补）
+- [[我的工具集]] ← relates_to ← [[Marketing Short-Video Editing Coach]]（AI工具选型参考）
 
 ## Contradictions
-- 与 [[Marketing-Douyin-Strategist]] 的内容风格差异：
-  - 冲突点：剪辑节奏与平台时长策略
-  - 当前观点：Douyin Strategist 强调7-15秒娱乐内容（高节奏快切），本Coach建议3-5分钟叙事结构
-  - 对方观点：抖音平台流量分发机制天然偏好极短视频（7-15秒完播率更高）
-  - 解决方向：两者互补——开篇3秒钩子（参考[[Video-Hook]]）用快节奏吸引注意力，后续进入1-3分钟完整叙事，兼顾完播率和深度表达
-- 与 [[marketing-video-optimization-specialist]] 的时长差异：
-  - 冲突点：YouTube长视频 vs 抖音短视频的剪辑密度
-  - 当前观点：本Coach强调"每一帧都必须有其存在的理由"，倾向于精简化剪辑
-  - 对方观点：Video Optimization Specialist 关注3分钟留存率，允许更多铺垫节奏
-  - 解决方向：时间尺度不同导致策略差异，前者3-30秒短视频以秒为单位控制节奏，后者3分钟+长视频以分钟为单位设计节拍结构，均为正确但适用于不同平台
+- 与 [[固定镜头短视频制作的ai全流程解析]] 的内容真实性张力：
+  - 冲突点：AI生成视频的定位
+  - 当前观点（本Agent）：AI生成视频"可看但无灵魂"，仅承担60%工作
+  - 对方观点（AI全流程解析）：利用AI可在10分钟内完成短视频全流程，强调AI的高效性
+  - 协调建议：两者互补——AI全流程解析提供AI工具的具体使用流程，本Agent提供专业剪辑的底层方法论，两者结合可实现AI辅助+专业精修的完整pipeline
diff --git a/wiki/sources/marketing-social-media-strategist.md b/wiki/sources/marketing-social-media-strategist.md
index 351a87b3..07554988 100644
--- a/wiki/sources/marketing-social-media-strategist.md
+++ b/wiki/sources/marketing-social-media-strategist.md
@@ -1,7 +1,7 @@
 ---
 title: "Social Media Strategist"
 type: source
-tags: [social-media, linkedin, twitter, b2b-marketing, content-strategy, thought-leadership]
+tags: [social-media, linkedin, twitter, b2b-marketing, content-strategy, thought-leadership, cross-platform]
 date: 2026-04-26
 ---
 
@@ -11,7 +11,7 @@ date: 2026-04-26
 ## Summary（用中文描述）
 - 核心主题：跨平台社交媒体战略专家 Agent，专注于 LinkedIn、Twitter 等专业社交平台的企业级品牌建设和社群运营
 - 问题域：B2B 社交媒体营销、企业高管个人品牌建设、跨平台内容协同运营
-- 方法/机制：通过统一信息流设计、平台适配内容优化、社群互动管理、领导思想建设等能力，实现品牌在专业社交平台的影响力提升
+- 方法/机制：通过统一信息流设计、平台适配内容优化、社群互动管理、思想领导力建设等能力，实现品牌在专业社交平台的影响力提升
 - 结论/价值：提供完整的跨平台社交媒体运营框架，涵盖从内容策划到效果分析的完整闭环
 
 ## Key Claims（用中文描述）
@@ -20,6 +20,8 @@ date: 2026-04-26
 - 至少 50% 的帖子需达到或超过平台互动基准
 - 员工倡导计划参与率应达到 30%+
 - 社交广告投资回报率应达到 3 倍以上
+- 月度粉丝增长率应达到 8%
+- 分享声量（Share of Voice）：品牌提及量应持续超越竞争对手
 
 ## Key Quotes
 > "Expert social media strategist specializing in cross-platform strategy, professional audience development, and integrated campaign management." — Agent 核心角色定义
@@ -27,16 +29,19 @@ date: 2026-04-26
 > "Works seamlessly with platform-specific specialist agents" — 与其他 Agent 协作的工作模式
 
 ## Key Concepts
-- [[Cross-Platform Strategy]]：跨平台统一消息策略，根据各平台特性调整内容形式
-- [[B2B Social Selling]]：B2B 社交销售策略与管道开发
-- [[Thought Leadership]]：通过持续发布建立行业权威地位
-- [[Employee Advocacy]]：员工倡导计划设计与品牌大使激活
-- [[Content Calendar Management]]：跨平台内容日历管理与编辑规划
+- [[Cross-Platform Strategy]]：跨平台统一消息策略，根据各平台特性调整内容形式，实现核心主题的一致性传播
+- [[B2B Social Selling]]：B2B 社交销售策略与管道开发，通过专业社交平台直接触达目标客户
+- [[Thought Leadership]]：通过持续发布高质量内容建立行业权威地位，吸引媒体和演讲机会
+- [[Employee Advocacy]]：员工倡导计划设计与品牌大使激活，扩大品牌自发传播
+- [[Content Calendar Management]]：跨平台内容日历管理与编辑规划，确保内容发布节奏一致
+- [[LinkedIn Algorithm Optimization]]：LinkedIn 算法优化，提升有机触达和专业互动率
+- [[Social Listening]]：社交媒体监听与竞争情报收集，追踪行业趋势和竞品动态
+- [[Community Management]]：专业社群管理与群组主持，培养忠实粉丝群体
 
 ## Key Entities
 - [[LinkedIn]]：核心专业社交平台，承载公司页面、个人品牌、专栏文章、新闻通讯
 - [[Twitter]]：实时互动平台，与 Twitter Engager Agent 协作实现一致的声音
-- [[LinkedIn Ads]]：专业平台广告投放渠道
+- [[LinkedIn Ads]]：专业平台广告投放渠道，包括赞助内容、InMail 活动、潜客表单
 - [[Reddit]]：通过 Reddit Community Builder Agent 协作扩展专业社群
 
 ## Connections
@@ -45,12 +50,94 @@ date: 2026-04-26
 - [[Marketing Reddit Community Builder]] ← collaborates_with ← [[Marketing Social Media Strategist]]
 - [[Analytics Reporter]] ← delivers_data_to ← [[Marketing Social Media Strategist]]
 - [[Marketing Growth Hacker]] ← receives_leads_from ← [[Marketing Social Media Strategist]]
-
-## Contradictions
-- 无已知冲突
+- [[Marketing Content Creator]] ← handoff_to ← [[Marketing Social Media Strategist]]
+- [[Marketing Trend Researcher]] ← handoff_to ← [[Marketing Social Media Strategist]]
+- [[Marketing Brand Guardian]] ← handoff_to ← [[Marketing Social Media Strategist]]
+- [[Sales Teams]] ← receives_leads_from ← [[Marketing Social Media Strategist]]
+- [[Legal Compliance Checker]] ← escalates_to ← [[Marketing Social Media Strategist]]
 
 ## Workflow Integration
 - **Handoff from**: Content Creator, Trend Researcher, Brand Guardian
 - **Collaborates with**: Twitter Engager, Reddit Community Builder, Instagram Curator
 - **Delivers to**: Analytics Reporter, Growth Hacker, Sales teams
-- **Escalates to**: Legal Compliance Checker, Brand Guardian
+- **Escalates to**: Legal Compliance Checker（敏感话题）, Brand Guardian（信息一致性）
+
+## Decision Framework（何时使用此 Agent）
+当需要以下场景时使用本 Agent：
+- 跨平台社交媒体战略制定与活动协调
+- LinkedIn 公司页面与高管个人品牌策略
+- B2B 社交销售与专业受众开发
+- 多平台内容日历与编辑规划
+- 社交媒体广告策略制定
+- 员工倡导与品牌大使计划
+- 多渠道思想领导力定位
+- 社交媒体效果分析与战略调整
+
+## Success Metrics（成功指标）
+- **LinkedIn 互动率**：公司页面帖子 3%+，个人品牌内容 5%+
+- **跨平台覆盖**：月复合受众覆盖增长 20%
+- **内容表现**：50%+ 帖子达到或超越平台互动基准
+- **潜客生成**：社交媒体渠道可衡量的管道贡献
+- **粉丝增长**：所有管理平台月增长 8%+
+- **员工倡导**：大使计划参与率 30%+
+- **活动 ROI**：社交广告投资回报率 3 倍+
+- **分享声量**：品牌提及量持续超越竞争对手
+
+## Platform Strategy Framework
+
+### LinkedIn Strategy
+- **公司页面**：定期更新、员工聚焦、行业洞察、产品新闻
+- **高管品牌**：个人思想领导力、专栏发布、新闻通讯开发
+- **LinkedIn 专栏**：长篇内容建立行业权威和 SEO 价值
+- **LinkedIn 新闻通讯**：订阅者培育与持续价值传递
+- **社群与群组**：行业群组参与和社群领导
+- **LinkedIn 广告**：赞助内容、InMail 活动、潜客表单
+
+### Twitter Strategy
+- **协调**：与 Twitter Engager Agent 对齐信息以保持一致的声音
+- **内容适配**：将 LinkedIn 洞察转化为 Twitter 原生格式
+- **实时放大**：跨平台推广时效性内容和活动
+- **话题标签策略**：跨平台保持一致的品牌和行业话题标签
+
+### Cross-Platform Integration
+- **统一信息**：核心主题适配到每个平台优势
+- **内容级联**：主要内容的 LinkedIn 发布，适配版本在 Twitter 和其他平台
+- **互动循环**：推动跨平台关注和社群重叠
+- **归因**：追踪跨平台用户旅程以衡量转化路径
+
+## Campaign Management
+
+### Campaign Planning
+- **目标设定**：与每个平台业务成果对齐的清晰目标
+- **受众细分**：平台特定受众定位和用户画像映射
+- **内容开发**：平台适配的创意资产和信息传递
+- **时间线管理**：全渠道协调发布计划
+- **预算分配**：平台特定的广告支出优化
+
+### Performance Tracking
+- **平台分析**：每个平台的原生分析审查
+- **跨平台仪表板**：触达、互动和转化的统一报告
+- **A/B 测试**：内容格式、时间和信息传递优化
+- **竞争基准**：声量份额和与行业同行的表现对比
+
+## Thought Leadership Development
+- **高管定位**：通过一致发布建立 CEO/创始人权威
+- **行业评论**：跨平台对趋势和新闻的及时洞察
+- **演讲机会**：利用社交影响力获取大会和播客邀请
+- **媒体关系**：为赢得媒体和新闻机会建立社交证明
+- **奖项提名**：记录成就以参与行业认可计划
+
+## Communication Style
+- **战略性**：基于平台最佳实践的数据驱动建议
+- **适应性**：不同平台文化对应不同声音和语调
+- **专业性**：建立专业权威的权威性语言
+- **协作性**：与其他平台专家 Agent 无缝协作
+
+## Learning & Memory
+- **平台算法变化**：追踪和适应社交媒体算法更新
+- **内容表现模式**：记录每个平台上的有效内容
+- **受众演变**：监控变化中的人口统计和互动偏好
+- **竞争格局**：追踪竞争对手社交策略和行业基准
+
+## Contradictions
+- 无已知冲突
diff --git a/wiki/sources/marketing-tiktok-strategist.md b/wiki/sources/marketing-tiktok-strategist.md
index 8c6a3e31..0ae00a8c 100644
--- a/wiki/sources/marketing-tiktok-strategist.md
+++ b/wiki/sources/marketing-tiktok-strategist.md
@@ -1,59 +1,57 @@
 ---
 title: "Marketing TikTok Strategist"
 type: source
-tags: ["tiktok", "social-media", "viral-marketing", "influencer", "short-video"]
+tags: []
 date: 2026-04-26
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-tiktok-strategist.md]]
+- [[Agent/agency-agents/marketing/marketing-tiktok-strategist.md]]
 
 ## Summary（用中文描述）
-- **核心主题**：TikTok 病毒式内容创作与品牌增长策略专家代理
-- **问题域**：如何在 TikTok 平台实现品牌病毒式传播、算法优化和社区建设
-- **方法/机制**：趋势追踪 + 算法优化 + 创作者合作 + 跨平台整合
-- **结论/价值**：通过 TikTok 文化原生内容和数据驱动优化，将品牌转化为 TikTok 现象级存在
+- 核心主题：TikTok 病毒式内容创作与品牌增长的专业 Agent 人格定义，涵盖算法优化、创作者经济运营、KOL 合作与跨平台内容策略
+- 问题域：如何借助 TikTok 独特文化与推荐机制，让品牌实现病毒式传播、获得海量自然流量
+- 方法/机制：3秒黄金钩子公式 + For You Page 算法优先策略 + 创作者分层合作体系 + 40/30/20/10 内容配比（Pillar）框架
+- 结论/价值：TikTok 运营的核心不是"制作精美的视频"，而是"通过趋势整合和社区互动工程化病毒时刻"
 
 ## Key Claims（用中文描述）
-- TikTok 策略师通过 **3 秒黄金钩子法则** 实现视频前 3 秒捕获注意力，提升完播率
-- 通过 **40/30/20/10 内容配比**（教育/娱乐/激励/促销）实现内容平衡
-- 设定 **8%+ 互动率目标**（行业平均 5.96%），实现品牌内容 70%+ 完播率
-- 通过 **Nano/Micro/Mid-tier/Macro** 四级创作者分层策略，实现 4:1 投资回报率
-- **For You Page 算法优化** 通过完播率、互动速度、用户行为触发实现流量最大化
+- 前3秒必须捕获注意力（Hook in 3 Seconds），否则完播率极低，算法不会分发
+- 内容配比框架：教育类40%、娱乐类30%、励志类20%、促销类10%
+- 完播率优先：完整观看百分比最大化是 TikTok 算法排名的核心信号
+- 参与速度优化：视频发布后第一小时的点赞/评论/分享数据决定是否进入更大流量池
+- 创作者分层策略：Nano（1K-10K）、Micro（10K-100K）、Mid-tier（100K-1M）、Macro（1M+）各层级差异化合作
+- 绩效指标：参与率目标 8%+（行业均值 5.96%）、品牌内容完播率 70%+、品牌标签挑战 1M+ 浏览
 
 ## Key Quotes
-> "You're not just creating TikTok content - you're engineering viral moments that capture cultural attention and transform brand awareness into measurable business growth through authentic community connection."
-> — TikTok 策略师核心定位
-
-> "Hook in 3 Seconds: Every video must capture attention immediately"
-> — TikTok 内容创作第一法则
+> "Hook in 3 Seconds — Every video must capture attention immediately" — TikTok 内容创作第一法则
+> "You're not just creating TikTok content — you're engineering viral moments that capture cultural attention" — 核心使命宣言
+> "Pattern Interrupts: Visual surprises, unexpected elements, and attention-grabbing openers" — 病毒公式
+> "Completion Rate Focus: Full video watch percentage maximization" — 算法优化核心
 
 ## Key Concepts
-- [[ForYouPageAlgorithm]]：TikTok 推荐算法，基于完播率、互动速度、用户行为（个人主页访问、关注、转发）进行内容分发
-- [[ViralContentFormula]]：病毒内容公式，包含 Pattern Interrupts（视觉打断）、Trend Integration（趋势融合）、Story Arc（故事弧线）、Community Elements（社区元素）
-- [[ContentPillarStrategy]]：内容支柱策略，40% 教育 + 30% 娱乐 + 20% 激励 + 10% 促销的内容配比
-- [[CreatorEconomy]]：创作者经济，通过 Nano/Micro/Mid-tier/Macro 分层创作者实现品牌传播
-- [[EngagementVelocity]]：互动速度优化，在发布后第一小时内最大化点赞、评论、分享
+- [[For You Page 算法]]：TikTok 的核心推荐引擎，通过完播率、参与速度、互动数据决定内容分发范围，优化目标是让视频被推送至更大流量池
+- [[内容支柱（Content Pillars）]]：40%教育/30%娱乐/20%励志/10%促销的内容配比框架，确保账号内容多样性与粉丝粘性
+- [[参与速度（Engagement Velocity）]]：视频发布后第一小时的互动数据（点赞/评论/分享）决定算法是否扩大分发
+- [[创作者分层（Influencer Tier Strategy）]]：Nano（1K-10K）、Micro（10K-100K）、Mid-tier（100K-1M）、Macro（1M+）各层级的 ROI 和合作策略差异
+- [[病毒公式（Viral Content Formula）]]：Pattern Interrupts（视觉打断）+ 趋势整合 + 故事弧结构 + 社区互动元素
+- [[TikTok 广告格式]]：信息流广告（In-feed Ads）、Spark Ads、TopView、品牌特效（Branded Effects）四大核心广告产品
 
 ## Key Entities
-- [[TikTok]]：短视频平台，核心传播渠道和算法生态
-- [[InstagramReels]]：跨平台适配目标之一
-- [[YouTubeShorts]]：跨平台适配目标之一
-- [[UGCCampaign]]：用户生成内容活动，品牌 hashtag 挑战
+- [[TikTok]]：字节跳动旗下全球短视频平台，核心算法为 For You Page，是本 Agent 的主战场
+- [[Instagram Reels]]：Meta 旗下的短视频功能，TikTok-first 内容的跨平台适配目标之一
+- [[YouTube Shorts]]：YouTube 的短视频功能，TikTok 内容跨平台分发的另一主要目标
+- [[TikTok-Ads]]：TikTok 广告平台，支持 Spark Ads、TopView、信息流广告和品牌标签挑战
+- [[ByteDance]]：TikTok 和抖音（[[Douyin]]）的母公司，同时运营今日头条等应用
 
 ## Connections
-- [[MarketingSocialMediaStrategist]] ← extends ← [[MarketingTikTokStrategist]]（通用社媒策略 → TikTok 专业策略）
-- [[MarketingKuaishouStrategist]] ← related_to ← [[MarketingTikTokStrategist]]（抖音/Kuaishou 双平台策略对比）
-- [[MarketingShortVideoEditingCoach]] ← supports ← [[MarketingTikTokStrategist]]（短视频剪辑支持内容创作）
-- [[MarketingVideoOptimizationSpecialist]] ← supports ← [[MarketingTikTokStrategist]]（视频优化提升算法表现）
-- [[MarketingInstagramCurator]] ← related_to ← [[MarketingTikTokStrategist]]（Reels 跨平台整合）
+- [[Marketing-Douyin-Strategist]] ← 同源平台差异 ← [[Marketing-TikTok-Strategist]]：抖音与 TikTok 同源（字节跳动），但用户群体（Z 世代 vs 中国用户）、算法细节、商业化生态存在显著差异
+- [[Marketing-Short-Video-Editing-Coach]] ← 执行层 ← [[Marketing-TikTok-Strategist]]：短视频剪辑 Coach 提供制作层支持，TikTok Strategist 提供策略层规划
+- [[Marketing-Livestream-Commerce-Coach]] ← 直播电商协同 ← [[Marketing-TikTok-Strategist]]：TikTok Shop 带货是 TikTok 商业化的重要场景，与直播教练存在协作
+- [[Marketing-Growth-Hacker]] ← 增长协同 ← [[Marketing-TikTok-Strategist]]：TikTok 自然流量是 Growth Hacker 增长策略的有机组成部分
+- [[Marketing-Instagram-Curator]] ← 跨平台协同 ← [[Marketing-TikTok-Strategist]]：Instagram Reels 是 TikTok 内容跨平台适配的首选目标
 
 ## Contradictions
-- 与 [[MarketingLinkedInContentCreator]] 存在平台差异：LinkedIn 偏向专业/长文内容，TikTok 偏向娱乐/短视频；两者在内容风格和受众互动模式上有本质冲突
-  - 冲突点：内容时长、表达风格、互动深度
-  - TikTok 观点：移动优先、垂直视频、高频短内容
-  - LinkedIn 观点：专业形象、长篇内容、深度互动
-- 与 [[MarketingWeChatOfficialAccount]] 存在内容策略差异：微信偏向私域沉淀，TikTok 偏向公域爆款
-  - 冲突点：内容留存 vs 内容传播
-  - TikTok 观点：最大化公域流量和病毒传播
-  - WeChat 观点：私域用户深度运营和复购转化
+- 与 [[Marketing-Douyin-Strategist]] 存在平台算法差异：
+  - 冲突点：抖音使用 DOU+ 投放体系和[[Douyin]]特有的矩阵账号协同玩法，TikTok 则依赖 Creator Fund 和 TikTok Shopping；抖音用户以中国消费者为主，TikTok 用户以 Z 世代和 Alpha 世代为主
+  - 当前观点：[[Marketing-TikTok-Strategist]] 遵循 TikTok 全球化平台规则和 Z 世代内容偏好
+  - 对方观点：[[Marketing-Douyin-Strategist]] 遵循抖音中国特有规则和矩阵运营体系
diff --git a/wiki/sources/marketing-twitter-engager.md b/wiki/sources/marketing-twitter-engager.md
index 5b244b0c..2da69192 100644
--- a/wiki/sources/marketing-twitter-engager.md
+++ b/wiki/sources/marketing-twitter-engager.md
@@ -1,45 +1,47 @@
 ---
 title: "Marketing Twitter Engager"
 type: source
-tags: ["marketing", "twitter", "social-media", "thought-leadership", "community-building"]
-date: 2026-04-26
+tags: [twitter, social-media, marketing, thought-leadership, community-building, crisis-management]
+date: 2026-04-30
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/marketing/marketing-twitter-engager.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Twitter 实时互动专家 Agent——通过真实对话参与、领袖思想建立和社区驱动增长来构建品牌权威
-- 问题域：品牌如何在 Twitter 这一高频竞争平台上建立思想领袖地位并实现持续社区增长
-- 方法/机制：内容策略框架（25%教育/20%个人故事/20%行业评论/15%社区互动/10%推广/10%娱乐）+ 四阶段工作流（实时监控→思想领袖建立→社区建设→效果优化）+ Twitter Spaces + 危机管理协议
-- 结论/价值：Twitter 成功的核心不是广播式发布，而是通过真实参与将对话转化为社区，将互动转化为权威，将粉丝转化品牌倡导者
+- 核心主题：Twitter 实时互动专家，通过真实参与对话建立品牌权威和思想领导力
+- 问题域：Twitter 营销、品牌建设、社区运营、危机公关
+- 方法/机制：四阶段工作流（实时监控→思想领导力开发→社区建设→效果优化）+ 内容策略框架 + 绩效分析体系
+- 结论/价值：Twitter 成功的关键在于真实参与而非广播式传播，将互动转化为权威、将粉丝转化为品牌倡导者
 
 ## Key Claims（用中文描述）
-- 品牌通过在 trending 对话中真实参与，能将 Twitter 用户从普通粉丝转化为品牌倡导者
-- 危机响应时间 <30 分钟是维护品牌声誉的关键阈值
-- 互动率 ≥2.5%（点赞/转推/回复/粉丝数）是健康账户的基准线
-- 教育类 thread 获得 100+ 转推是可复制的成功标准
+- 通过真实对话参与而非广播式发布来建立品牌权威
+- 推文内容组合应为：教育类25%、个人故事20%、行业评论20%、社区互动15%、推广10%、娱乐10%
+- 互动率（点赞+转发+回复/粉丝数）应达到2.5%以上
+- 对提及和私信的回复率应达80%，且在2小时内响应
+- 教育类/价值类推文串应达到100+转发
+- 危机响应时间应控制在30分钟以内
 
 ## Key Quotes
-> "Twitter success comes from authentic participation in ongoing conversations, not broadcasting." — 核心运营哲学
-> "You're not just tweeting — you're building a real-time brand presence that transforms conversations into community, engagement into authority, and followers into brand advocates." — 最终目标宣言
+> "Remember: You're not just tweeting - you're building a real-time brand presence that transforms conversations into community, engagement into authority, and followers into brand advocates through authentic, valuable participation in Twitter's dynamic ecosystem." — Agent 核心理念
 
 ## Key Concepts
-- [[Thought-Leadership]]：通过持续发布高价值洞察和教育性内容，在特定领域建立专家权威形象的过程
-- Community-Building：培育活跃粉丝群体，通过一致的有价值内容和真实互动实现持续增长
-- Crisis-Management：品牌声誉的实时监控与危机响应协议，核心指标为 <30 分钟响应时间
-- Twitter-Spaces：Twitter 的实时语音聊天室，用于行业讨论和 Q&A sessions，是社区建设的重要工具
-- Thread-Mastery：长篇 thread 写作技巧——hook 公式、教育价值传递、故事弧线、视觉增强和 CTA 优化
+- [[ThoughtLeadership]]: 通过持续输出有价值见解建立行业专家地位
+- [[CommunityBuilding]]: 通过一致的有价值内容和真实互动培养忠实粉丝群体
+- [[CrisisManagement]]: 实时监控负面情绪并快速响应，保护品牌声誉
+- [[EngagementRate]]: 衡量互动效果的指标（点赞+转发+回复/粉丝数）
+- [[TwitterSpacesStrategy]]: 定期主持行业讨论、专家访谈和问答活动
+- [[ThreadMastery]]: 长推文串创作能力，包含钩子设计、教育价值交付、视觉增强和行动号召
 
 ## Key Entities
-- Twitter（平台）：核心运营阵地，实时互动环境，品牌权威建设的关键渠道
-- Brand Authority（品牌权威）：Agent 的最终交付目标——在目标受众心智中建立的专家认知
-- Trending Topics（热门话题）：实时参与的关键切入口，是触达新受众的高效途径
+- **Twitter**: 核心平台，品牌实时互动的主战场
+- **Twitter Spaces**: 实时音频社区功能，用于行业讨论和 Q&A 活动
+- **Twitter Ads**: 广告投放平台，支持认知度、参与度、点击量、线索和转化等多种营销目标
 
 ## Connections
-- [[Marketing-Social-Media-Strategist]] ← extends ← [[Marketing-Twitter-Engager]]（前者为跨平台通用策略，后者为 Twitter 垂直深耕）
-- [[Marketing-Growth-Hacker]] ← shares_audience_with ← [[Marketing-Twitter-Engager]]（两者均聚焦增长，但 Growth Hacker 侧重病毒机制，Engager 侧重社区沉淀）
-- [[Marketing-LinkedIn-Content-Creator]] ← parallel_channel ← [[Marketing-Twitter-Engager]]（LinkedIn 与 Twitter 同属短文本社交，但受众和内容风格不同）
+- [[MarketingSocialMediaStrategist]] ← extends ← [[MarketingTwitterEngager]]
+- [[MarketingContentCreator]] ← provides_content ← [[MarketingTwitterEngager]]
+- [[MarketingGrowthHacker]] ← shares_metrics_with ← [[MarketingTwitterEngager]]
 
 ## Contradictions
-- 无已知冲突。该 Agent 专注于 Twitter/X 平台运营，与 Wiki 中其他营销 Agent 构成互补关系而非竞争关系。
+- 暂无发现与其他 Wiki 页面的冲突
diff --git a/wiki/sources/marketing-video-optimization-specialist.md b/wiki/sources/marketing-video-optimization-specialist.md
index d303b261..7998b608 100644
--- a/wiki/sources/marketing-video-optimization-specialist.md
+++ b/wiki/sources/marketing-video-optimization-specialist.md
@@ -1,53 +1,52 @@
 ---
-title: "Marketing Video Optimization Specialist"
+title: "Marketing Video Optimization Specialist Agent"
 type: source
-tags: ["youtube", "video-marketing", "seo", "thumbnail", "content-strategy"]
-date: 2026-04-26
+tags: [agent, marketing, video, youtube, seo, content-strategy]
+date: 2026-04-30
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/marketing/marketing-video-optimization-specialist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：YouTube 视频营销增长与留存优化专家 Agent，专注于通过算法机制提升视频曝光与观众参与度
-- 问题域：视频平台（尤其是 YouTube）的算法推荐逻辑、观众留存率优化、跨平台内容分发
-- 方法/机制：CTR 优化（标题+缩略图）、Audience Retention 分析（留存率图谱）、Chaptering 策略性分章、SEO 元数据优化、Shorts/Reels/TikTok 跨平台内容改造
-- 结论/价值：提供完整的视频审核与优化模板，涵盖从包装策略（标题/缩略图）→ 视频结构（Hook 钩子/章节时间戳）→ SEO 元数据的全链路交付
+- 核心主题：YouTube 视频营销优化专家 Agent，专注最大化视频平台的触达率和互动率
+- 问题域：视频创作者如何通过算法优化提升曝光、留存和变现效率
+- 方法/机制：CTR 优化策略、观众留存图谱分析、封面标题协同设计、章节结构规划、跨平台内容分发
+- 结论/价值：提供系统化的视频包装与结构化方案，通过数据驱动决策实现频道增长
 
 ## Key Claims（用中文描述）
-- 前30秒（The Hook）决定视频生死：必须精确规划第一个30秒以防止观众流失
-- 缩略图+标题必须协同讲述完整微故事：标题引发好奇或承诺价值，缩略图视觉化补充
-- 不靠标题党实现点击率：点击诱饵短期提升 CTR 但损害长期留存和算法权重
-- 以会话视角优化视频：每个视频不是终点，而是引导观众进入下一个视频的节点
-- 8%+ 平均 CTR、50%+ 第3分钟留存率是可量化的成功基准
+- 通过优化 CTR 1.5% 可触发 YouTube 推荐算法，产生级联流量
+- 视频前 30 秒（The Hook）决定 80% 的观众去留，必须字字斟酌
+- 封面图在移动端必须高对比、清晰主体、文字不超过 3 个词
+- 标题与封面必须协同工作，讲述一个完整的微故事
+- 视频结束时直接链接到下一个相关视频，最大化观看时长
 
 ## Key Quotes
-> "If we increase CTR by 1.5%, we'll trigger the suggested algorithm." — 数据驱动的决策逻辑
-> "That 10-second intro logo is killing your retention; cut it." — 观众心理优先于品牌惯例
-> "Don't just optimize this video; optimize the viewer's journey to the next one." — 会话视角而非单视频视角
-> "We need a stronger 'payoff' at the 6-minute mark to prevent the retention graph from dipping." — 留存率图谱驱动结构优化
+> "The Hook: Map the first 30 seconds of every video meticulously" — 强调视频开头的重要性
+> "Thumbnails must be readable on mobile devices at a glance (high contrast, clear subject, < 3 words)" — 封面设计核心原则
+> "Don't just optimize this video; optimize the viewer's journey to the next one." — 强调观看者旅程设计
 
 ## Key Concepts
-- [[YouTube SEO]]：通过标题优化、标签策略、描述结构、关键词研究主导搜索流量
-- [[Audience Retention]]：YouTube Studio 留存率图谱分析，识别导致观众流失的"死空气"时间点
-- [[Click-Through Rate (CTR)]]：缩略图+标题的联合点击率，是触发推荐算法的核心信号
-- [[Thumbnail Design]]：缩略图概念设计（高对比度、移动端可读、≤3词文字），A/B 测试策略
-- [[Video Chaptering]]：策略性章节划分，时间戳钩子布局，留存率低谷前注入价值
-- [[Cross-Platform Syndication]]：将长视频改造为 Shorts/Reels/TikTok 短格式，格式自适应
-- [[Video Hook]]：前30秒钩子——立即陈述问题并承诺解决方案，防止开场观众流失
-- [[Initial Velocity]]：视频发布后初期的流量爆发速度，影响算法冷启动推荐量
-- [[End Screen Optimization]]：结束画面 CTA，直接链接到下一个相关视频，最大化会话时长
+- [[YouTube SEO]]：通过标题优化、标签策略、描述结构化提升搜索排名
+- [[CTR Optimization]]：点击率优化，1.5% 的提升可触发推荐算法
+- [[Audience Retention]]：观众留存率，前 3 分钟 50%+ 留存是核心指标
+- [[The Hook]]：视频开头的前 30 秒，决定观众是否继续观看
+- [[Video Chaptering]]：战略性章节划分，提升导航体验和深度观看
+- [[Cross-Platform Syndication]]：跨平台内容分发（Shorts、Reels、TikTok）
+- [[Initial Velocity]]：视频发布后初期的流量爆发速度，影响算法推荐
+- [[Session Time Maximization]]：通过端屏和卡片优化最大化观众连续观看时长
 
 ## Key Entities
-- YouTube：主要视频平台，算法优化核心战场
-- YouTube Studio：YouTube 创作者后台，提供留存率图谱、流量来源分析等数据
-- YouTube Shorts：YouTube 短格式，用于跨平台内容分发
-- TikTok / Instagram Reels：跨平台短视频分发渠道
+- [[YouTube Studio]]：YouTube 官方创作者后台，用于深度数据分析
+- [[YouTube Shorts]]：YouTube 短视频格式，碎片化内容再分发渠道
+- [[TikTok]]：短视频平台，跨平台内容再分发目标
+- [[Instagram Reels]]：Instagram 短视频格式，跨平台内容再分发目标
 
 ## Connections
-- [[marketing-douyin-strategist]] ← related_to ← [[marketing-video-optimization-specialist]]（均为视频平台营销专家，但 Douyin 专注抖音中国市场，Video Optimization 专注 YouTube 海外市场）
-- [[marketing-content-creator]] ← depends_on ← [[marketing-video-optimization-specialist]]（内容创作者产出视频素材，视频优化专家负责算法层面的包装与分发）
-- [[marketing-podcast-strategist]] ← related_to ← [[marketing-video-optimization-specialist]]（两者均涉及音视频内容的分发策略，可交叉协作）
+- [[Marketing Content Creator]] ← creates_content ← [[Marketing Video Optimization Specialist]]
+- [[Marketing SEO Specialist]] ← shares_strategy_with ← [[Marketing Video Optimization Specialist]]
+- [[Marketing Bilibili Content Strategist]] ← parallel_to ← [[Marketing Video Optimization Specialist]]
+- [[Marketing TikTok Strategist]] ← cross_platform_with ← [[Marketing Video Optimization Specialist]]
 
 ## Contradictions
-- 暂无发现与其他 Wiki 页面的直接冲突。该 Agent 的"不靠标题党"原则与某些激进增长策略存在理念差异，但属于方法论层面的互补而非内容冲突。
+- 暂无发现冲突内容
diff --git a/wiki/sources/marketing-wechat-official-account.md b/wiki/sources/marketing-wechat-official-account.md
index 70b57d5a..6479d2b8 100644
--- a/wiki/sources/marketing-wechat-official-account.md
+++ b/wiki/sources/marketing-wechat-official-account.md
@@ -1,57 +1,54 @@
 ---
 title: "Marketing WeChat Official Account Manager"
 type: source
-tags: []
-date: 2026-04-26
+tags: [wechat, social-media, china-marketing, content-strategy, automation]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-wechat-official-account.md]]
+- [[Agent/agency-agents/marketing/marketing-wechat-official-account.md]]
 
 ## Summary（用中文描述）
-- 核心主题：微信公众号全栈运营与订阅者关系建设专家 Agent——帮助品牌将微信公众号打造为高互动、强忠诚的社群中心
-- 问题域：内容策略规划、订阅者关系构建、多格式内容创作、自动回复体系、菜单架构设计、转化漏斗优化
-- 方法/机制：五阶段闭环工作流（订阅者分析→内容策略→内容创作→自动化运营→数据分析）；60/30/10 内容比例规则；原生平台功能深度整合
-- 结论/价值：打开率30%+（行业均值2倍）、菜单点击率20%+、小程序激活率40%+、订阅者月自然增长10-20%、转化率2-5%
+- 核心主题：微信公众号营销操盘手 Agent 角色定义，涵盖内容策略、订阅者关系建设、多格式内容运营、自动化工作流与转化优化
+- 问题域：企业在中国最私密的商业沟通平台（微信）上如何建立忠实的订阅者社区，实现持续 engagement 和商业转化
+- 方法/机制：通过"60/30/10 内容法则"（60% 价值内容、30% 互动内容、10% 推广内容）、自动化回复系统、小程序集成、五阶段工作流（分析→策略→创作→自动化→优化）
+- 结论/价值：微信公众号是中国的核心私域流量阵地，需将其从广播渠道转化为关系建设工具，通过持续价值输出将粉丝转化为忠诚拥护者与付费客户
 
 ## Key Claims（用中文描述）
-- 微信公众号不是广播频道，而是关系建设工具——需要战略性内容组合、持续的订阅者价值传递和真实的品牌声音
-- 内容比例规则：**60% 价值内容 + 30% 社群/互动内容 + 10% 推广内容**
-- 打开率目标30%+（行业均值20-25%的2倍）
-- 推送频率建议：大多数企业每周2-3次
-- 转化订阅者为忠实拥护者和回头客，而非推送消息
-- 微信原生功能是核心竞争力：自动回复、关键词响应、菜单架构、小程序整合
-- 数据驱动内容决策：用分析仪表盘追踪打开率、点击率、转化指标
+- 微信公众号操盘手通过将 OA 打造成"订阅者关系建筑师"，实现 30%+ 打开率（行业均值 20-25%）
+- 遵循 60/30/10 内容法则可有效提升订阅者留存率至 95%+
+- 自动化工作流（自动回复+关键词触发+菜单架构）可将运营效率提升 3-5 倍
+- 小程序集成可激活 40%+ 订阅者使用平台增值功能
+- 通过 OA 实现的转化率可达 2-5%，终身订阅者价值超过内容投入的 10 倍
 
 ## Key Quotes
-> "WeChat Official Account is China's most intimate business communication channel. You're not broadcasting messages — you're building genuine relationships where subscribers choose to engage with your brand daily, turning followers into loyal advocates and repeat customers."
-> "Content Value Strategy: Delivering consistent, relevant value to subscribers through diverse content formats."
-> "Maintain consistent publishing schedule (2-3 posts per week for most businesses)."
-> "Follow 60/30/10 rule: 60% value content, 30% community/engagement content, 10% promotional content."
+> "WeChat Official Account is China's most intimate business communication channel. You're not broadcasting messages — you're building genuine relationships where subscribers choose to engage with your brand daily, turning followers into loyal advocates and repeat customers." — 角色核心定位
+
+> "Maintain consistent publishing schedule (2-3 posts per week for most businesses)" — 内容发布节奏建议
+
+> "Follow 60/30/10 rule: 60% value content, 30% community/engagement content, 10% promotional content" — 内容结构法则
 
 ## Key Concepts
-- [[Content-60-30-10-Rule]]：内容比例规则——60% 价值内容（教育/娱乐）、30% 社群/互动内容（提问/投票）、10% 推广内容，确保订阅者感受到持续价值而非被推销
-- [[Five-Phase-Workflow]]：五阶段运营工作流——Phase 1 订阅者与商业分析 → Phase 2 内容策略与日历 → Phase 3 内容创作与优化 → Phase 4 自动化与互动建设 → Phase 5 性能分析与优化
-- [[WeChat-Native-Features]]：微信原生功能体系——自动回复（欢迎消息/常见问题/菜单引导）、关键词自动化响应、菜单架构设计、小程序整合，构建自助服务系统
-- [[Subscriber-Relationship-Architecture]]：订阅者关系架构——将公众号从消息推送渠道转型为关系建设工具，通过一致的价值传递、真实品牌故事和社群互动培养长期忠诚度
-- [[Mini-Program-Integration]]：小程序整合策略——通过小程序增强功能性和用户留存，数据收集与 CRM 集成实现全链路视图
-- [[WeChat-Analytics]]：微信分析体系——追踪打开率（目标30%+）、点击率（目标5%+）、文章读完率（目标50%+）、订阅者增长与留存率
+- [[ContentPillarStrategy]]：内容支柱策略——定义 4-5 个与业务目标和订阅者兴趣对齐的核心主题
+- [[SubscriberRelationshipBuilding]]：订阅者关系建设——通过真诚连接建立信任、忠诚和拥护
+- [[MiniProgramIntegration]]：小程序集成——利用小程序增强用户体验和数据收集
+- [[ConversionOptimization]]：转化优化——将订阅者 engagement 转化为可衡量的商业结果
+- [[AutoReplySystem]]：自动回复系统——欢迎消息、常见问题、菜单引导的自动化流程
+- [[SegmentationStrategy]]：细分策略——组织订阅者进行定向、相关沟通
 
 ## Key Entities
-- [[WeChat]]：微信——中国最大私域社交平台，微信公众号是其核心商业通讯渠道，支持文章/消息/投票/小程序/自定义菜单等多格式内容
+- [[WeChat]]：中国最大私域流量平台，OA 为企业提供订阅者管理和内容分发能力
+- [[WeChatMiniProgram]]：微信小程序生态，为 OA 提供增强功能和用户留存能力
 
 ## Connections
-- [[Marketing-Weibo-Strategist]] ← complements ← 公域流量导入（微博公域话题→微信公众号私域沉淀）
-- [[Marketing-Private-Domain-Operator]] ← flows_to ← 私域承接（公众号订阅者→企业微信私域运营）
-- [[Marketing-China-E-Commerce-Operator]] ← complements ← 转化漏斗（内容种草→小程序商城→成交转化）
-- [[Marketing-Douyin-Strategist]] ← extends ← 短视频种草→公众号深度内容留存
-- [[Marketing-Xiaohongshu-Strategist]] ← extends ← 博主种草→公众号产品深度测评
-- [[Marketing-Kuaishou-Strategist]] ← extends ← 直播引流→公众号粉丝社群沉淀
-- [[Marketing-Social-Media-Strategist]] ← is_derived_from ← 全平台社交媒体战略框架
+- [[MarketingPrivateDomainOperator]] ← related_to ← [[MarketingWeChatOfficialAccountManager]]
+- [[MarketingWeiboStrategist]] ← related_to ← [[MarketingWeChatOfficialAccountManager]]
+- [[MarketingDouyinStrategist]] ← related_to ← [[MarketingWeChatOfficialAccountManager]]
+- [[MarketingKuaishouStrategist]] ← related_to ← [[MarketingWeChatOfficialAccountManager]]
+- [[MarketingXiaohongshuSpecialist]] ← related_to ← [[MarketingWeChatOfficialAccountManager]]
 
 ## Contradictions
-- 与 [[Marketing-Weibo-Strategist]] 的平台逻辑存在运营重心差异：
-  - 冲突点：微博强调「公共舆论场」和话题扩散，追求爆款内容和热搜；公众号强调「私域关系」和长期订阅者价值
-  - 当前观点：公众号核心价值是深度关系建设和长期用户终身价值，内容可反复触达
-  - 对方观点：微博核心价值是公域曝光和话题扩散，追求即时声量和传播裂变
-  - 协调方案：两者互补——微博负责公域话题引爆和品牌曝光→导入公众号私域实现深度关系沉淀和长期转化，形成「广度引爆+深度沉淀」的完整营销闭环
+- 与 [[MarketingSocialMediaStrategist]] 可能的冲突：
+  - 冲突点：跨平台内容分发策略是否应采用统一内容还是本地化定制
+  - 当前观点（OA 操盘手）：微信平台需本地化深度运营，强调私域关系和平台特有功能（小程序、自动化）
+  - 对方观点：强调全平台统一品牌叙事和内容协同
diff --git a/wiki/sources/marketing-weibo-strategist.md b/wiki/sources/marketing-weibo-strategist.md
index 28106e39..3a9598a0 100644
--- a/wiki/sources/marketing-weibo-strategist.md
+++ b/wiki/sources/marketing-weibo-strategist.md
@@ -2,57 +2,67 @@
 title: "Marketing Weibo Strategist"
 type: source
 tags: []
-date: 2026-04-26
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-weibo-strategist.md]]
+- [[Agent/agency-agents/marketing/marketing-weibo-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：新浪微博全栈运营与品牌传播战略专家 Agent——帮助品牌在微博平台实现热搜霸榜与持续增长
-- 问题域：企业蓝V账号运营、热搜话题策划、超级话题社区管理、粉丝经济、KOL合作、微博广告投放、舆情监控与危机公关
-- 方法/机制：账号定位→内容策略→话题运营→粉丝经济→广告投放→数据追踪五步闭环工作流；金4小时危机响应规则；蓝/黄/橙/红四色舆情分级
-- 结论/价值：月度话题曝光50M+、蓝V互动率1.5%+、季度热搜≥3次、粉丝头条CPE<1.5元、KOL合作内容互动超行业基准200%
+- 核心主题：微博全栈运营与品牌传播策略 Agent，专注帮助品牌在新浪微博平台实现热搜霸榜与持续增长
+- 问题域：企业蓝V运营、账号定位、话题策划、超级话题管理、粉丝经济、KOL 合作、广告投放、舆情监控、电商导流
+- 方法/机制：账号定位 → 话题矩阵设计 → 超级话题社区运营 → KOL 分层合作 → 付费+有机流量叠加 → 实时舆情监控 → 数据复盘迭代
+- 结论/价值：微博是"公共舆论场"，核心是声量份额而非私域运营；爆款传播公式 = 争议性 × 低参与门槛 × 情绪共鸣；舆情响应黄金4小时
 
 ## Key Claims（用中文描述）
-- 微博的核心价值是「公共舆论场的话语权份额」，而非私域运营——不要将私域逻辑套用到微博
-- 病毒传播公式：**争议性 × 低参与门槛 × 情感共鸣 = 病毒扩散**
-- 热搜生命周期通常4-8小时，错过窗口期等于从未尝试
-- 微博算法推荐权重：**时效性 > 互动量 > 账号权威 > 内容质量**
-- 转评比点赞对传播更有价值——优化内容结构以鼓励转发和评论
-- 舆情黄金4小时响应规则：发现→评估→回应→追踪
-- 重大事件或危机中，「快+真诚」永远优于「完美+慢」
+- 微博核心是"公共舆论arena"，价值在于声量份额，不可用私域逻辑运营微博
+- 爆款传播公式：争议性 × 低参与门槛 × 情绪共鸣 = 病毒式传播级联
+- 热搜话题生命周期约 4-8 小时，错过窗口期等同于从未尝试
+- 算法推荐权重排序：时效性 > 互动量 > 账号权威性 > 内容质量
+- 转发和评论比点赞更有利于传播，需优化内容结构激励二次传播
+- 舆情响应黄金4小时规则：发现 → 评估 → 回应 → 追踪
+- KOL 筛选核心：粉丝质量 > 粉丝数量（需核查活跃粉丝比、互动真实性）
+- 品牌超级话题策略：构建品牌自有社区 + UGC 内容培育 + 核心粉丝沉淀
+- 企业蓝V最佳发帖频率：每天 3-5 条，覆盖高峰时段（8:00 / 12:00 / 18:00 / 21:00）
+- 负面舆情分级：蓝/黄/橙/红 四级，对应不同响应时间和处置团队
 
 ## Key Quotes
-> "Weibo's core isn't 'posting a microblog.' It's about 'precisely positioning your brand in the public discourse arena and using topic momentum to trigger viral sharing cascades'"
-> "Controversy × low participation barrier × emotional resonance = viral cascade"
-> "Trending topic response speed is everything - a trending topic's lifecycle is typically 4-8 hours; miss the window and it's as if you never tried"
-> "In major events or crises, 'fast + sincere' always beats 'perfect + slow'"
+> "Weibo's core isn't 'posting a microblog.' It's about 'precisely positioning your brand in the public discourse arena and using topic momentum to trigger viral sharing cascades'" — 角色核心定位
+> "Trending topic response speed is everything - a trending topic's lifecycle is typically 4-8 hours; miss the window and it's as if you never tried" — 热搜响应时效性原则
+> "Controversy x low participation barrier x emotional resonance = viral cascade" — 爆款传播公式
+> "Fast + sincere always beats perfect + slow in major events or crises" — 危机沟通准则
 
 ## Key Concepts
-- [[Trending-Topic-Operations]]：热搜话题运营——围绕品牌事件/节日/时事设计低门槛高分享性的 hashtag，实时监测热搜并30分钟内产出高质量联动内容
-- [[Super-Topic]]：微博超级话题——类粉丝社区的账号运营形态，支持粉丝签到/打榜/协同评论，具备等级体系可培养核心粉丝
-- [[Fan-Economy]]：粉丝经济——利用粉丝社区动态运营品牌粉丝俱乐部，包括签到、打榜、协同评论、偶像超级话题联动策略
-- [[Sentiment-Monitoring]]：舆情监控系统——7×24监控品牌/竞品/行业敏感词，四色分级预警（蓝/黄/橙/红），黄金4小时响应
-- [[Weibo-Advertising]]：微博广告体系——粉丝头条（Fensi Tong精准推广）、信息流广告、开屏广告、超级粉丝头条跨平台数据整合
-- [[KOL-Partnership]]：KOL合作策略——顶级KOL（引爆认知）+中层KOL（垂直渗透）+微KOC（草根信任）金字塔模型
-- [[Newsjacking]]：借势营销——实时监测热搜榜单，在Trending事件30分钟内产出高质量联动内容
+- [[TrendingTopicOperations]]：热搜话题运营 — 通过话题策划、蹭热点、广告产品（热搜伴侣/品牌热搜/热搜彩蛋）实现品牌流量获取
+- [[SuperTopicManagement]]：超级话题管理 — 微博社区化运营核心，品牌自有粉丝社区建设、UGC 内容培育、超级话题等级体系
+- [[FanEconomy]]：粉丝经济 — 饭圈文化运营、打榜/签到/协同评论、品牌粉丝俱乐部式运营
+- [[SentimentMonitoring]]：舆情监控 — 品牌/竞品/行业敏感词实时监控、四级预警（蓝/黄/橙/红）、4小时黄金响应
+- [[KOLPartnership]]：KOL 合作 — KOL/KOC 分层金字塔（顶层引爆认知 + 中层垂直渗透 + 微型 KOC 基层背书）
+- [[WeiboAdvertising]]：微博广告 — 粉丝通（精准定向）、信息流广告、开屏广告、超级粉丝通（跨平台 DMP）、CPM/CPC/CPE 成本管理
+- [[ContentStrategy]]：内容策略 — 图片文字（九宫格/长文/140字短句）、视频、故事、话题三级架构（品牌常设/活动/蹭热点）
+- [[WeiboCommerce]]：微博电商 — 微博橱窗、直播带货、种草→话题发酵→转化链路设计
 
 ## Key Entities
-- [[Weibo]]：新浪微博——中国领先的微博客平台，公共舆论场核心阵地，话题机制是品牌曝光的核心杠杆
+- [[SinaWeibo]]：新浪微博 — 中国领先微博平台，本 Agent 的核心运营阵地
+- [[WeiboIndex]]：微博指数 — 官方数据分析工具，用于追踪品牌/话题搜索趋势和热度
+- [[MicroIndex]]：微指数 — 官方舆情分析工具，提供关键词热度、情感分析、受众画像
+- [[WeiboTaskPlatform]]：微博任务平台 — 官方 KOL/KOC 对接市场，含定价结构和效果预估
+- [[WeiboBlueV]]：微博蓝V — 企业认证账号，享有专属运营功能和更高权重
 
 ## Connections
-- [[Marketing-Douyin-Strategist]] ← extends ← [[Social-Media-Strategy]]
-- [[Marketing-Kuaishou-Strategist]] ← extends ← [[Social-Media-Strategy]]
-- [[Marketing-Xiaohongshu-Strategist]] ← extends ← [[Social-Media-Strategy]]
-- [[Marketing-Wechat-Official-Account]] ← complements ← 私域承接（微博公域流量导入私域）
-- [[Marketing-Baidu-SEO-Specialist]] ← complements ← 搜索意图用户（百度捕获搜索意图用户，微博创造话题引发主动搜索）
-- [[Marketing-Social-Media-Strategist]] ← is_derived_from ← 全平台社交媒体战略框架
-- [[Marketing-Private-Domain-Operator]] ← flows_to ← 私域承接（微博公域→企业微信私域）
+- [[MarketingSocialMediaStrategist]] ← topic_operations ← [[TrendingTopicOperations]]
+- [[MarketingKuaishouStrategist]] ← fan_economy ← [[FanEconomy]]
+- [[MarketingZhihuStrategist]] ← kpi_framework ← [[ContentStrategy]]
+- [[MarketingDouyinStrategist]] ← kpi_framework ← [[WeiboAdvertising]]
+- [[MarketingPrivateDomainOperator]] ← contrast ← [[WeiboStrategist]]: 微博是公共舆论场，与私域运营逻辑相反
 
 ## Contradictions
-- 与 [[Marketing-Private-Domain-Operator]] 的私域逻辑存在框架张力：
-  - 冲突点：微博运营强调「公共舆论场话语权」而非私域，私域运营强调「将信任建立为资产」积累私有用户资产
-  - 当前观点：微博核心价值是公域话题扩散，追求曝光量和声量
-  - 对方观点：私域核心价值是建立与用户的直接连接，追求用户终身价值
-  - 协调方案：两者互补而非竞争——微博创造话题引发关注→导入企业微信私域实现后续转化，形成公域引爆+私域沉淀的完整漏斗
+- 与 [[MarketingPrivateDomainOperator]] 冲突：
+  - 冲突点：运营思维模式
+  - 当前观点（本文）：微博核心价值是"公共舆论场的声量份额"，强调话题传播和破圈
+  - 对方观点：私域运营强调粉丝沉淀、反复触达、私域变现
+- 与 [[MarketingKuaishouStrategist]] 冲突：
+  - 冲突点：平台属性与运营节奏
+  - 当前观点（本文）：微博内容强调短平快、140字爆点、时效性 > 内容质量
+  - 对方观点：快手强调真实人设、长尾内容、信任关系积累
+
diff --git a/wiki/sources/marketing-zhihu-strategist.md b/wiki/sources/marketing-zhihu-strategist.md
index 83e978b8..b59d3ef5 100644
--- a/wiki/sources/marketing-zhihu-strategist.md
+++ b/wiki/sources/marketing-zhihu-strategist.md
@@ -1,53 +1,62 @@
 ---
 title: "Marketing Zhihu Strategist"
 type: source
-tags: []
-date: 2026-04-21
+tags: ["zhihu", "marketing", "social-media", "china", "thought-leadership", "lead-generation"]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/marketing/marketing-zhihu-strategist.md]]
+- [[Agent/agency-agents/marketing/marketing-zhihu-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：知乎营销专家 Agent，将品牌打造为知乎思想领袖，通过专业知识分享建立权威并获取精准线索
-- 问题域：品牌在中国最大知识分享平台知乎上的思想领导力建设、社区公信力建立、精准获客
-- 方法/机制：六阶段工作流（话题定位→问题识别→高质量内容创作→专栏开发→关系建设→性能分析与优化）+ 信誉驱动内容标准 + 知识驱动参与策略
-- 结论/价值：知乎是信誉优先平台，权威和真实专业度比粉丝数或推广推送重要得多；成功来自真实有用的内容，权威建立后商业结果自然跟进
+- 核心主题：知乎平台品牌思想领导力与权威建设营销专家
+- 问题域：在中国最大知识分享平台知乎上，如何通过真实专业知识分享建立品牌权威、积累高质量粉丝并转化为精准线索
+- 方法/机制：通过精选问答策略、专栏内容系列、影响力人物合作、知乎 Live/知乎书店等平台特色功能，构建品牌在垂直领域的话语权
+- 结论/价值：知乎是「信誉优先」平台，真实帮助用户而非强行推销才是建立持久影响力的关键；每月可产生50-200条精准线索
 
 ## Key Claims（用中文描述）
-- 知乎是信誉优先平台，权威和真实专业度比粉丝数更重要，推广推送无效
-- 仅回答真正有可辩护专业知识的问答（信誉是知乎的一切）
-- 综合性、有价值的内容是基础（大多数主题最少 300 词）
-- 每条主张必须有数据、研究、案例支撑以获得最大信誉度
-- 专栏开发是建立持续思想领导力和订阅者基础的必备策略
-- CTA 必须含蓄且有价值，从不硬推销
-- 成功衡量标准：答案平均 100+ 点赞、每月 50-200 条精准线索、专栏每月 500-2000 新订阅者
+- 知乎用户将真实权威置于粉丝数量之上 — 信誉即一切
+- 答案平均获得100+赞即可视为高质量内容
+- 每月专栏订阅增长500-2,000人是衡量权威建设进度的核心指标
+- 知乎流量转化率为3-8%，显著高于其他社交平台
+- 30%+的答案成为「精选答案」即代表权威认可
+- 每月100-500新粉丝增长来自答案曝光
+- 品牌需在3-5个核心话题领域保持活跃以建立权威定位
+- 永远不使用攻击性销售语言——让专业知识和价值为自己说话
 
 ## Key Quotes
-> "On Zhihu, you're building authority through authentic expertise-sharing and community participation. Your success comes from being genuinely helpful, maintaining credibility, and letting your knowledge speak for itself - not from aggressive marketing or follower-chasing."
-> "Credibility is everything on Zhihu"
-> "Never use aggressive sales language; let expertise and value speak for itself"
-> "Build real authority and the business results follow naturally."
+> "On Zhihu, you're building authority through authentic expertise-sharing and community participation." — 核心运营哲学
+> "Only answer questions where you have genuine, defensible expertise (credibility is everything on Zhihu)" — 内容标准第一原则
+> "Build real authority and the business results follow naturally." — 自然转化逻辑
+> "Never use aggressive sales language; let expertise and value speak for itself" — 沟通风格底线
 
 ## Key Concepts
-- [[Thought-Leadership]]：通过专业知识分享建立品牌在行业中的可信、有知识权威声音
-- [[Community-Credibility]]：通过真实专业知识分享和社区参与赢得信任和权威
-- [[Strategic-Question-Answer]]：识别和回答高影响力问题以驱动曝光和参与
-- [[Content-Pillar]]：开发专有内容系列（专栏）以建立订阅者基础和权威
-- [[Lead-Generation-Funnel]]：通过战略定位和含蓄 CTA 将参与读者转化为精准线索
+- [[Thought Leadership Development]]：通过专业知识分享将品牌塑造为行业权威声音的战略性过程
+- [[Community Credibility Building]]：通过真实的专业知识分享和社区参与赢得用户信任和权威认可
+- [[Strategic Question & Answer Mastery]]：识别并回答高影响力问题以驱动品牌可见度和用户参与度的框架
+- [[Content Pillar Strategy]]：围绕3-5个核心话题领域建立持续内容输出的战略
+- [[Column Development]]：创建和维护知乎专栏以积累订阅者并深化权威的机制
+- [[Lead Generation Funnel]]：将活跃读者通过战略性内容转化为销售对话的完整漏斗
+- [[CTA Strategy]]：设计隐性、有价值的行动号召以驱动网站访问或线索捕获，而非硬性推销
+- [[Topic Authority Mapping]]：识别品牌应在哪些话题领域建立权威的诊断框架
 
 ## Key Entities
-- [[知乎]]（Zhihu）：中国最大知识分享平台，信誉优先平台，权威比粉丝数重要
+- [[Zhihu]]：中国最大的知识分享与问答社区平台，月活用户超过1亿，信誉驱动型平台
+- [[Zhihu Live]]：知乎直播功能，用于与最感兴趣的粉丝进行深度互动
+- [[Zhihu Books]]：知乎书店功能，将优质答案编译出版以增强权威信号
+- [[Zhihu Column]]：知乎专栏，用于持续输出思想领导力内容并积累订阅者
+- [[The Agency]]：本 Agent 的框架来源，包含多个专业化营销 Agent 的多代理系统
 
 ## Connections
-- [[Marketing Douyin Strategist]] ← 同属 ← [[Marketing Channel Strategy]]
-- [[Marketing Weibo Strategist]] ← 同属 ← [[Marketing Channel Strategy]]
-- [[Marketing Xiaohongshu Specialist]] ← 同属 ← [[Marketing Channel Strategy]]
-- [[Marketing Kuaishou Strategist]] ← 同属 ← [[Marketing Channel Strategy]]
+- [[Marketing Xiaohongshu Specialist]] ← 姐妹平台策略 ← [[Marketing Zhihu Strategist]]
+- [[Marketing WeChat Official Account Manager]] ← 内容分发互补 ← [[Marketing Zhihu Strategist]]
+- [[Marketing Bilibili Content Strategist]] ← 视频内容联动 ← [[Marketing Zhihu Strategist]]
+- [[Marketing Growth Hacker Agent]] ← 增长策略总览 ← [[Marketing Zhihu Strategist]]
+- [[Marketing Douyin Strategist]] ← 抖音与知乎联动 ← [[Marketing Zhihu Strategist]]
 
 ## Contradictions
-- 与 [[Marketing Douyin Strategist]] 冲突：
-  - 冲突点：内容长度与格式策略
-  - 当前观点：知乎需要综合性深度内容（最少 300 词），以数据、案例、研究支撑主张
-  - 对方观点：抖音侧重短平快视觉内容，15-60 秒内抓住注意力
-  - 说明：平台特性不同，策略自然分化——知乎是信誉驱动深度平台，抖音是娱乐驱动视觉平台，两者互补而非矛盾
+- 与 [[Marketing Growth Hacker Agent]] 的增长逻辑存在表面冲突：
+  - 冲突点：知乎策略强调「不追求粉丝数量」，而增长黑客强调快速规模化
+  - 当前观点：知乎平台的信誉驱动特性决定权威比粉丝数量更有商业价值
+  - 对方观点：增长黑客追求量化指标的最大化，强调速度和规模
+  - 协调说明：两者服务不同阶段——知乎建立长期权威，增长黑客驱动短期增长
diff --git a/wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md b/wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md
new file mode 100644
index 00000000..54cce110
--- /dev/null
+++ b/wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md
@@ -0,0 +1,51 @@
+---
+title: "n8n Docker 配置 Telegram 代理 Troubleshooting"
+type: source
+tags: [n8n, docker, http-proxy, https-proxy, telegram, xray, v2ray]
+date: 2026-05-02
+---
+
+## Source File
+- [[Home Office/n8n Docker 配置 Telegram 代理 Troubleshooting]]
+
+## Summary（用中文描述）
+- 核心主题：Docker 容器内运行的 n8n 如何通过宿主机代理访问 Telegram API 的问题排查与解决方案
+- 问题域：Docker 网络命名空间隔离、HTTP(S) 代理环境变量、Node.js HTTP 客户端代理行为
+- 方法/机制：通过 `extra_hosts` + `host.docker.internal` 打通容器到宿主机代理的路径；利用 axios（n8n 底层）自动读取 `HTTP_PROXY`/`HTTPS_PROXY` 环境变量的特性实现透明代理
+- 结论/价值：Docker 容器内应用走宿主机代理的正确配置方式，避免因测试方法不当导致的误判
+
+## Key Claims（用中文描述）
+- Docker 容器内的 `127.0.0.1:10808` 指向容器自身，而非宿主机，因此代理不生效
+- `host.docker.internal` 通过 `extra_hosts: - "host.docker.internal:host-gateway"` 映射到宿主机 IP，是容器访问宿主机代理的标准方式
+- Node.js 原生 `fetch` API **不会**自动读取 `HTTP_PROXY`/`HTTPS_PROXY` 环境变量，不能作为代理生效的测试方法
+- n8n 使用 **axios** 发送 HTTP 请求，axios 会自动读取代理环境变量，因此正确配置后 n8n Telegram 节点可以正常工作
+- 验证代理是否生效的正确方法是直接在 n8n 的 **HTTP Request 节点** 访问 `api.telegram.org`
+
+## Key Quotes
+
+> "node fetch 不会自动使用 `HTTP_PROXY`/`HTTPS_PROXY`，所以容器内的测试命令显示 ETIMEDOUT 是**测试方法有误**，并非代理没生效" — 问题根源分析
+
+> "n8n 使用 axios，axios 会自动读取代理环境变量，所以 n8n 节点内是正常工作的" — axios 行为说明
+
+> "`host.docker.internal` 能工作的前提是 `docker-compose.yml` 中已有 `extra_hosts: - "host.docker.internal:host-gateway"`" — 关键前提条件
+
+## Key Concepts
+- [[host.docker.internal]]：Docker 提供的特殊 DNS 名称，在 Linux 上需要 `extra_hosts` 配置才能使用，用于容器访问宿主机网络
+- [[HTTP_PROXY 环境变量]]：标准代理配置环境变量，axios、curl 等工具会自动读取并用于 HTTP 请求
+- [[Docker extra_hosts]]：`docker-compose.yml` 中的配置项，将宿主机 IP 映射到容器内的 `host.docker.internal`
+- [[axios HTTP 客户端]]：n8n 底层使用的 HTTP 客户端，会自动遵循 `HTTP_PROXY`/`HTTPS_PROXY` 环境变量
+
+## Key Entities
+- [[n8n]]：开源工作流自动化工具，本文档中负责通过 Telegram 节点与 Telegram Bot API 通信
+- [[xray/v2ray]]：宿主机上运行的代理服务，监听 `10808` 端口，提供 HTTP/SOCKS 代理能力
+- [[Telegram Bot API]]（api.telegram.org）：Telegram 官方 API，本文档中 n8n 通过代理访问的目标服务
+
+## Connections
+- [[n8n]] ← 通过 docker-compose 配置代理环境变量 ← [[xray/v2ray]]
+- [[n8n]] ← HTTP 请求经由宿主机代理转发 ← [[Telegram Bot API]]
+
+## Contradictions
+- 与一般"Node.js 应用自动使用代理"的假设冲突：
+  - 冲突点：许多文档暗示所有 Node.js HTTP 请求都会自动走 `HTTP_PROXY` 环境变量
+  - 当前观点：Node.js 原生 `fetch` 不读取代理环境变量，只有 axios 等封装库才会
+  - 对方观点：Node.js 应用无需额外配置即可使用代理环境变量
diff --git a/wiki/sources/n8n-调用openclaw-agents的工作流架构.md b/wiki/sources/n8n-调用openclaw-agents的工作流架构.md
new file mode 100644
index 00000000..6a9231d6
--- /dev/null
+++ b/wiki/sources/n8n-调用openclaw-agents的工作流架构.md
@@ -0,0 +1,45 @@
+---
+title: "n8n 调用 OpenClaw Agents 的工作流架构"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/n8n 调用openclaw agents的工作流架构.md]]
+
+## Summary（用中文描述）
+- 核心主题：n8n 工作流自动化平台如何通过 OpenAI 兼容 API 调用 OpenClaw Agent
+- 问题域：多 Agent 系统集成与工作流编排
+- 方法/机制：通过 OpenClaw Gateway 的 OpenAI Chat Completions 端点，用 HTTP Request 节点调用 Agent，Agent ID 通过 `model` 字段指定（如 `openclaw:main`）
+- 结论/价值：n8n 可同时连接 Hermes Agent（port 8642）和 OpenClaw Agent（port 18789），实现统一的自动化工作流编排
+
+## Key Claims（用中文描述）
+- OpenClaw Gateway 的 OpenAI 兼容 Chat Completions 端点**默认关闭**，需要在 `~/.openclaw/openclaw.json` 配置文件中手动开启
+- OpenClaw Agent 通过 `model` 字段指定，格式为 `"openclaw:<agentId>"`（如 `"openclaw:main"` 或 `"openclaw:beta"`）
+- Hermes Agent 与 OpenClaw Agent 的核心区别：默认端口不同（8642 vs 18789）、Agent 指定方式不同
+- n8n 通过 HTTP Request 节点即可同时调用 Hermes Agent 和 OpenClaw Agent，两者共用同一局域网 IP，仅端口不同
+- OpenClaw 配置中的 `host: "0.0.0.0"` 允许 Docker 容器从宿主机网络访问，与 Hermes 的网络配置同理
+
+## Key Quotes
+> "OpenClaw 的 Gateway 可以提供 OpenAI 兼容的 Chat Completions 端点，**默认是关闭的**，需要在配置中手动开启" — 配置前提条件
+> "OpenClaw 通过 `model` 字段来指定 Agent ID，格式为 `\"openclaw:<agentId>\"`" — Agent 指定机制
+> "两个都用同一个局域网 IP，只是端口不同，在 n8n 里分别建两个 HTTP Request 节点就可以了" — n8n 集成架构总结
+
+## Key Concepts
+- [[OpenAI-Compatible-API]]：OpenClaw Gateway 提供的 OpenAI Chat Completions 兼容端点，用于与标准 AI 工具集成
+- [[HTTP-ChatCompletions]]：HTTP 协议上的 Chat Completions 调用方式，n8n 通过此方式调用 OpenClaw Agent
+- [[Agent-Orchestration]]：多 Agent 系统的编排与管理，n8n 负责协调 Hermes 和 OpenClaw 两个 Agent
+
+## Key Entities
+- [[OpenClaw]]：本地运行的 AI Agent 系统，提供 Gateway 服务
+- [[Hermes-Agent]]：另一个本地 AI Agent 系统（端口 8642），n8n 可同时调用
+- [[n8n]]：开源工作流自动化平台，通过 HTTP Request 节点连接多个 AI Agent
+
+## Connections
+- [[n8n]] ← calls ← [[OpenAI-Compatible-API]]
+- [[OpenAI-Compatible-API]] ← provided_by ← [[OpenClaw]]
+- [[n8n]] ← also_calls ← [[Hermes-Agent]]
+
+## Contradictions
+- 与现有 Wiki 内容暂无冲突（当前 Wiki 中无 OpenClaw 或 n8n 相关页面）
diff --git a/wiki/sources/n8n调用hermes-agents的工作流架构.md b/wiki/sources/n8n调用hermes-agents的工作流架构.md
new file mode 100644
index 00000000..c41c5c5f
--- /dev/null
+++ b/wiki/sources/n8n调用hermes-agents的工作流架构.md
@@ -0,0 +1,45 @@
+---
+title: "n8n调用openclaw/hermes agents的工作流架构"
+type: source
+tags:
+  - "clippings"
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/n8n调用hermes agents的工作流架构]]
+
+## Summary（用中文描述）
+- 核心主题：如何通过 n8n 工作流编排器调用 Hermes Agent，实现多 Agent 自动化协作
+- 问题域：AI Agent 与工作流自动化平台的无代码集成
+- 方法/机制：利用 Hermes 内置的 OpenAI 兼容 API Server，无需额外中间件即可被 n8n HTTP Request 节点直接调用；通过 Profile 机制实现多 Agent 端口隔离；通过 X-Hermes-Session-Id 实现多轮对话上下文保持
+- 结论/价值：提供了一套原生、原生集成的多 Agent 工作流编排方案，可零代码实现调研→写作→编码的 Agent 分工协作
+
+## Key Claims（用中文描述）
+- Hermes Agent 内置了 OpenAI 兼容的 API Server，无需额外代码即可暴露为 HTTP 端点
+- 每个 Agent 可通过独立 Profile 运行在不同端口、配置独立 API Key，实现隔离与分工
+- n8n 通过标准 HTTP Request 节点即可调用 Hermes，接口格式完全兼容 OpenAI Chat Completions
+- 通过 X-Hermes-Session-Id header 可在 n8n 多步工作流中保持 Agent 会话上下文
+- 该方案完全原生支持，不需要任何额外中间件
+
+## Key Quotes
+> "Hermes Agent 内置了 OpenAI 兼容的 API Server，完全不需要额外写任何代码，直接配置开启就行" — 方案核心价值
+> "同一个工作流里的多次调用会共享上下文，非常适合需要多步推理的任务链" — X-Hermes-Session-Id 的应用场景
+
+## Key Concepts
+- [[OpenAI兼容API]]：Hermes API Server 暴露的标准 OpenAI Chat Completions 接口格式
+- [[多Profile隔离]]：Hermes 的 profile 机制为每个 Agent 分配独立端口和密钥
+- [[X-Hermes-Session-Id]]：v0.7.0+ 支持的会话保持 header，使多请求共享上下文
+- [[工作流编排]]：n8n 作为自动化平台对多个 Agent 的协调与串联
+
+## Key Entities
+- [[HermesAgent]]：NousResearch 开源的 AI Agent 框架，内置 API Server 功能
+- [[n8n]]：开源工作流自动化平台，支持 HTTP Request 节点调用外部 API
+
+## Connections
+- [[HermesAgent]] ← exposes ← [[OpenAI兼容API]]
+- [[n8n]] ← calls via HTTP ← [[HermesAgent]]
+- [[多Profile隔离]] ← enables ← 多Agent并发协作
+
+## Contradictions
+- 无已知冲突内容
diff --git a/wiki/sources/narrative-designer.md b/wiki/sources/narrative-designer.md
index fa5a2764..5e950dd2 100644
--- a/wiki/sources/narrative-designer.md
+++ b/wiki/sources/narrative-designer.md
@@ -1,54 +1,53 @@
 ---
 title: "Narrative Designer Agent Personality"
 type: source
-tags: []
-date: 2026-04-26
+tags: ["game-development", "narrative-design", "dialogue", "branching-story", "agency-agents"]
+date: 2026-05-07
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/narrative-designer.md]]
+- [[Agent/agency-agents/game-development/narrative-designer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：游戏叙事设计师 AI Agent 的人格规范与工作系统——将叙事视为一套由选择、后果、世界一致性构成的系统，而非插入在游戏玩法之间的电影剧本
-- 问题域：游戏叙事设计与游戏玩法的深度整合、对话写作、分支设计、 Lore 架构、环境叙事、角色声音设计
-- 方法/机制：通过 Voice Pillar（声音柱）确保角色一致性；Lore 三层架构（Surface/Engaged/Deep）实现可选深度；叙事-玩法对齐矩阵确保每个故事节点连接游戏机制后果；延迟后果设计让选择的影响延续至后续章节
-- 结论/价值：叙事不是附加物——它是与游戏机制同等重要的系统，成功的叙事设计能让 90%+ 玩家仅凭对话准确识别角色性格
+- **核心主题**：游戏叙事设计师 Agent 人格定义——将游戏叙事理解为一套由选择、后果和世界一致性构成的系统，而非插入在游戏玩法之间的电影剧本。
+- **问题域**：如何在游戏中实现叙事与玩法的深度融合；如何设计有意义的分支选择；如何构建奖励探索但不强制的 Lore 体系；如何保持角色声音的一致性。
+- **方法/机制**：三-tier Lore 架构（Surface/Engaged/Deep）、角色声音支柱（Voice Pillars）定义、分支节点映射、叙事-玩法对齐矩阵、环境叙事简报。
+- **结论/价值**：提供了一套完整的小说/游戏叙事设计方法论，强调叙事设计必须从 Engine-ready 格式出发（Ink/Yarn），避免剧本到脚本的翻译层。
 
 ## Key Claims（用中文描述）
-- 叙事设计师 + 机制设计师：NarrativeDesigner 理解游戏叙事不是"插入在玩法之间的电影剧本"，而是"玩家身在其中的一套选择与后果系统"
-- 对话写作标准：每句台词必须通过"真实人物会这样说话吗？"测试，拒绝"as you know"式对话，每个对话节点必须有明确的戏剧功能
-- 分支设计标准：选择必须类型不同（非仅程度不同），所有分支必须收敛且不显生硬，延迟后果设计让 Act 1 选择在 Act 3 显现
-- Lore 三层架构：Lore 永远可选，关键路径无需任何收藏品或可选对话即可理解
-- 叙事-玩法整合：每个主要故事节点必须连接到游戏机制后果或机械变化
+- **叙事即系统**：游戏叙事不是插入在玩法之间的电影剧本，而是一套由选择、后果和世界一致性构成的系统，玩家生活在其中。
+- **真实对话原则**：每句台词必须通过"真实的人会这样说吗？"测试——禁止"as you know"式的 exposition disguised as conversation。
+- **有意义选择**：分支必须在种类上不同，而非仅在程度上不同（"我帮你"vs"我稍后帮你"不是有意义的选择）。
+- **Lore 三层架构**：Surface（所有玩家）→ Engaged（探索者）→ Deep（ Lore 猎人），关键路径无需任何 Tier 2/3 Lore 也能理解。
+- **叙事-玩法融合**：每个主要故事节点必须连接到玩法后果或机制变化；教程必须由角色叙事驱动，而非"因为这是教程"。
 
 ## Key Quotes
-> "game narrative is not a film script inserted between gameplay — it is a designed system of choices, consequences, and world-coherence that players live inside" — Narrative Designer 核心定义
-> "Choices must differ in kind, not just in degree — 'I'll help you' vs. 'I'll help you later' is not a meaningful choice" — 有意义选择的设计标准
-> "Lore is always optional — the critical path must be comprehensible without any collectibles or optional dialogue" — Lore 架构核心原则
-> "Player agency in story must match player agency in gameplay — don't give narrative choices in a game with no mechanical choices" — 叙事-玩法一致性原则
+> "You write dialogue that sounds like humans, design branches that feel meaningful, and build lore that rewards curiosity." — Narrative Designer 身份定义
+
+> "Every line must pass the 'would a real person say this?' test — no exposition disguised as conversation." — 对话写作铁律
+
+> "Choices must differ in kind, not just in degree — 'I'll help you' vs. 'I'll help you later' is not a meaningful choice." — 分支设计铁律
+
+> "Lore is always optional — the critical path must be comprehensible without any collectibles or optional dialogue." — Lore 架构原则
+
+> "Player agency in story must match player agency in gameplay — don't give narrative choices in a game with no mechanical choices." — 叙事与玩法一致性原则
 
 ## Key Concepts
-- [[Branching Narrative]]：分支叙事设计——选择树结构、节点映射、收敛策略、后果可见性设计
-- [[Environmental Storytelling]]：环境叙事——通过场景道具与空间布局无声讲述故事
-- [[Dialogue Writing Standards]]：对话写作标准——"真实人物说话测试"、角色声音柱、无"as you know"对话
-- [[Lore Architecture]]：Lore 三层架构（Surface/Engaged/Deep）——可选深度的世界构建体系
-- [[Narrative-Gameplay Integration]]：叙事-玩法整合——故事节点与游戏机制后果对齐矩阵
-- [[Character Voice Pillars]]：角色声音柱——词汇/节奏/禁忌话题/口癖/潜台词五维度角色声音定义
-- [[Choice Architecture]]：选择架构——Fake Choice 的刻意使用、延迟后果、后果可见性映射
-- [[Narrative Debt Tracking]]：叙事债务追踪——伏笔和解承诺必须被兑现或主动退役
+- [[Branching Dialogue Design]]：分支对话设计——分支必须"收敛"（converge）且不感觉强迫，所有分支节点须在写台词前先完成节点映射。
+- [[Voice Pillars]]：角色声音支柱——定义角色的词汇、节奏、回避话题、口头禅和潜台词默认值，确保跨所有作者的一致性。
+- [[Lore Architecture]]：Lore 架构——三层结构（Surface/Engaged/Deep），维护 World Bible 以确保所有 Lore 一致性。
+- [[Environmental Storytelling]]：环境叙事——通过道具和空间世界构建，要求照明故事和声音故事的协同设计。
+- [[Emergent Narrative]]：涌现式叙事——由玩家行为生成的故事，通过派系声誉、关系值和世界状态标志实现。
+- [[Choice Architecture]]：选择架构——应用"有意义选择"测试，设计"假选择"用于特定情感目的，使用延迟后果设计。
 
 ## Key Entities
-- （本文档未明确提及具体人物或公司，均为通用游戏开发概念，未达 Entity 建页阈值）
+- **NarrativeDesigner**：角色定义中的叙事设计师 Agent——故事系统架构师，理解叙事与玩法不可分割。
 
 ## Connections
-- [[Level Designer Agent]] ← shares workflow ← [[Narrative Designer Agent]]（环境叙事由关卡设计师执行物理空间设计，叙事设计师提供内容架构）
-- [[Game Audio Engineer]] ← reinforces ← [[Narrative Designer]]（自适应音乐层切换响应叙事节奏，Voice-over 预算与角色声音设计需协同）
-- [[Branching Narrative]] ← builds_on ← [[Character Voice Pillars]]（分支选择的后果感依赖角色声音的一致性）
-- [[Lore Architecture]] ← extends ← [[Environmental Storytelling]]（环境叙事是 Tier 2 Deep lore 的物理呈现）
+- [[Game Designer]] ← 依赖 ← [[Narrative Designer]]：叙事设计师需要与游戏设计师对齐叙事支柱与游戏支柱。
+- [[Technical Artist]] ← 协作 ← [[Narrative Designer]]：环境叙事需要美术团队协作实现。
+- [[Game Audio Engineer]] ← 协作 ← [[Narrative Designer]]：声音叙事（Sound Story）是环境叙事简报的核心组成部分。
+- [[Level Designer]] ← 依赖 ← [[Narrative Designer]]：分支节点映射需要在关卡设计中落地。
 
 ## Contradictions
-- 与 [[Level Designer]] 存在实践边界模糊：
-  - 冲突点：环境叙事内容归谁负责——叙事设计师提供叙事架构，但关卡设计师执行物理空间设计
-  - 当前观点（Narrative Designer）：叙事设计师负责叙事架构和内容定义，包括环境道具的叙事意义
-  - 对方观点（Level Designer）：灰盒阶段由 Level Designer 主导布局决策，叙事需求作为 GDD 输入而非执行主体
-  - 注：此为职责分工问题，非内容矛盾，两者均承认环境叙事需要双方协作
+- 无已知冲突。本文档为独立的人格定义文档，与现有 Wiki 内容无直接矛盾。
diff --git a/wiki/sources/nexus-spatial-discovery.md b/wiki/sources/nexus-spatial-discovery.md
index bdcec215..e76958fb 100644
--- a/wiki/sources/nexus-spatial-discovery.md
+++ b/wiki/sources/nexus-spatial-discovery.md
@@ -1,76 +1,64 @@
 ---
 title: "Nexus Spatial: Full Agency Discovery Exercise"
 type: source
-tags: [multi-agent, spatial-computing, product-discovery, vision-pro, webxr, ai-agents, spatial-aiops]
+tags: []
 date: 2026-03-05
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/examples/nexus-spatial-discovery.md]]
+- [[Agent/agency-agents/examples/nexus-spatial-discovery.md]]
 
 ## Summary（用中文描述）
-- 核心主题：8个专业AI Agent并行协作，完成一个AI Agent空间指挥中心产品的完整发现与规划——从市场验证、技术架构、品牌策略、GTM计划到UX研究和项目执行方案。
-- 问题域：AI Agent编排工具市场（$13.5B）+ 空间计算市场（$170-220B）的交叉空白；现有AI工具均为平面2D界面，缺乏沉浸式3D命令中心。
-- 方法/机制：多Agent并行发现 → 各Agent独立研究 → 交叉Agent综合对齐 → 关键张力识别与决议；8个Agent（产品趋势研究员、后端架构师、品牌守护者、增长黑客、支持应答者、UX研究员、XR界面架构师、项目牧羊人）同步工作，约10分钟完成全栈规划。
-- 结论/价值：验证了"2D先行、空间其次"的渐进策略；调试是杀手级用例；WebXR优于VisionOS作为分发渠道；定义了全新品类SpatialAIOps；产出了35周完整执行计划。
+- 核心主题：Nexus Spatial——一款融合 AI Agent 编排与空间计算的沉浸式 3D 命令中心产品发现文档
+- 问题域：AI Agent 工作流编排工具市场（当前均为 2D 仪表盘）+ 空间计算（Vision Pro/WebXR）企业应用缺口
+- 方法/机制：8 个专业化 AI Agent 并行协作，覆盖市场研究、技术架构、品牌策略、GTM、用户支持、UX 设计、项目执行、空间界面设计 8 个维度
+- 结论/价值：验证了"2D 先行、空间渐进"的分阶段策略；调试（Debugging）是空间计算在 AI 领域的杀手级用例；WebXR 比 VisionOS 更适合作为分发入口
 
 ## Key Claims（用中文描述）
-- AI编排工具（$13.5B，22.3% CAGR）+ 空间计算（$170-220B）存在交叉空白——现有产品要么是空间型但非AI，要么是AI型但仅2D。
-- Vision Pro全球仅~100万台，且销量从发布高点下降95%；不应以VisionOS为主推平台。
-- Safari于2025年末采纳WebXR Device API，2026年WebXR采用率增长40%——WebXR是理想的分发解锁渠道。
-- 调试（Debugging）是空间计算在AI工作流中的杀手级用例：工作流结构叠加运行时追踪的3D可视化解决了2D工具无法处理的问题。
-- 8个专业Agent并行工作可产出连贯、相互引用的完整计划，消除人工协调开销。
+- 8 个专业 Agent 并行协作可在单次会话中生成完整的跨职能产品规划——覆盖市场、技术、品牌、运营全维度
+- AI 工作流编排市场规模达 $135 亿（2026），年增速 22%+；Autonomous AI Agents 增速更快（45.8% CAGR 到 $503 亿）
+- Vision Pro 全球安装量仅约 100 万台，且销量较峰值下跌 95%——不应作为主要切入点；WebXR 才是分发解锁之道
+- 所有 8 个 Agent 独立得出同一结论：必须"2D 先行，空间渐进"——而非直接押注 VisionOS
+- 调试是空间计算在 AI Agent 领域的杀手级用例：运行时追踪的空间叠加能解决真实、量化的痛点
+- Nexus Spatial 定义了一个新品类：**SpatialAIOps**（空间 AI 运维），而非在拥挤的 AI 可观测性仪表盘市场竞争
 
 ## Key Quotes
-> "Products are either spatial-but-not-AI-focused, or AI-focused-but-flat-2D. No product sits at the intersection." — Product Trend Researcher，核心竞争格局定性
-> "Debugging Is the Killer Use Case. Spatial overlay of runtime traces on workflow structure solves a real, quantified pain point that no 2D tool handles well." — UX Researcher，关键用例定位
-> "Do NOT lead with VisionOS. Lead with web, add WebXR, native VisionOS last." — Product Trend Researcher，产品平台策略核心结论
-> "Every agent independently arrived at this conclusion [2D-first, spatial-second]. Build a great web dashboard first, then progressively add spatial capabilities." — Cross-Agent Synthesis，跨Agent共识
+> "For technical teams managing complex AI agent workflows, Nexus Spatial is the immersive 3D command center that provides spatial awareness of agent orchestration, unlike flat 2D dashboards, because spatial computing transforms monitoring from reading dashboards to inhabiting your infrastructure." — 品牌定位声明
+
+> "Products are either spatial-but-not-AI-focused, or AI-focused-but-flat-2D. No product sits at the intersection." — 市场缺口分析
+
+> "The war room collaboration scenario... is the strongest spatial value proposition -- teams entering a shared 3D space to debug a failing pipeline together." — 空间计算核心价值场景
+
+> "Spatial adds value for structural tasks (placing, connecting, rearranging nodes) but creates friction for parameter tasks (text entry, configuration)." — 空间界面设计关键洞察
 
 ## Key Concepts
-- [[SpatialAIOps]]：空间AI运营——将空间计算引入AI Agent编排和监控的全新品类；Nexus Spatial创造性地定义了此品类而非在拥挤的AI可观测性仪表板赛道竞争。
-- [[Multi-Agent-Orchestration]]：多Agent编排——Nexus Spatial的核心能力，涉及DAG执行、节点图可视化、实时监控和Agent生命周期管理。
-- [[WebXR]]：浏览器原生空间计算标准；Safari 2025年末采纳WebXR Device API，Android XR支持OpenXR，是Nexus Spatial的主要分发平台。
-- [[Command-Theater-Interface]]：命令剧院界面——以用户为中心的弧形空间布局：120度焦点弧（前）、概览天幕（上）、左右工具轨（侧）、工具架（下），通过三层深度系统组织内容。
-- [[Debugging-Visualization]]：调试可视化——空间叠加运行时追踪于工作流结构之上；UX研究发现这是2D工具处理最差、3D价值最高的用例。
-- [[Semantic-Zoom]]：语义缩放——4级导航（舰队视图→工作流视图→节点视图→追踪视图），随缩放层级揭示不同粒度的信息。
-- [[CRDT-Collaboration]]：CRDT（无冲突复制数据类型）+ Yjs + WebRTC，实现多人实时3D图协作编辑。
-- [[Rust-Orchestration]]：Rust实现的编排引擎——亚毫秒调度、零GC停顿、内存安全；用于AI Agent沙箱和关键路径DAG执行。
-- [[Gaze-Voice-Hands]]：注视+语音+手势三模态输入——空间计算的基础交互范式，支持双手解放和免手操作。
-- [[Growth-Loop]]：增长飞轮——"Wow Factor"演示分享循环（K=0.3-0.5）、模板市场、协作席位扩展、集成驱动发现。
+- [[SpatialAIOps]]：新品类定义——将空间计算引入 AI Agent 编排与运维监控，打破传统 2D 仪表盘的限制
+- [[Spatial Earns Its Place]]：空间设计原则——只有当 3D 确实优于 2D 时才使用 3D；否则应选择平面
+- [[2D-First Spatial-Second]]：分阶段策略——先用优质 2D Web 仪表盘建立市场，再渐进叠加 WebXR 空间模式，VisionOS 原生应用最后考虑
+- [[Command Theater]]：空间界面布局架构——以用户为中心的弧形指挥剧场：Focus Arc（主工作区）、Overview Canopy（鸟瞰图）、Utility Rails（工具栏）、Shelf（控制台）
+- [[4-Level Semantic Zoom]]：导航范式——Fleet View（舰队视角）→ Workflow View（工作流视角）→ Node View（节点视角）→ Trace View（追踪视角）
+- [[Debugging As Killer Use Case]]：调试是杀手级用例——运行时追踪的空间叠加能大幅缩短故障诊断时间（目标：从 45 分钟降至 10 分钟以内）
+- [[WebXR Distribution Unlock]]：WebXR 是分发解锁——Safari 2025 年底支持 WebXR Device API，Android XR 支持 WebXR/OpenXR 标准，覆盖更广泛设备
 
 ## Key Entities
-- [[Nexus-Spatial]]：产品名——AI Agent沉浸式3D命令中心，VisionOS + WebXR应用；核心功能：3D节点图可视化Agent管道、实时监控空间面板、3D空间拖放构建工作流、共享空间协作；定价：Explorer免费、Pro $99/月、Team $249/月、Enterprise定制；战略定位：SpatialAIOps新品类创造者。
-- [[Product-Trend-Researcher]]：产品趋势研究员——The Agency执行董事Agent；发现Vision Pro市场数据，重新定义平台策略（WebXR优先于VisionOS）；验证Nexus Spatial进入条件性通过（2D先行）。
-- [[Backend-Architect]]：后端架构师——The Agency工程Agent；设计了8服务架构（客户端→API网关→服务层→数据层→AI提供商层），推荐Rust用于编排引擎。
-- [[Brand-Guardian]]：品牌守护者——The Agency设计Agent；定义了"SpatialAIOps"新品类定位；设计了6色品牌系统和品牌个性（权威/沉稳/先锋/精确/亲和）。
-- [[Growth-Hacker]]：增长黑客——The Agency增长Agent；设计了3阶段GTM策略（创始人主导→开发者社区→企业）；设计了4大增长飞轮。
-- [[Support-Responder]]：支持应答者——The Agency支持Agent；设计了支持分级体系；创新性地将AI支持代理嵌入用户空间工作区作为核心差异化。
-- [[UX-Researcher]]：UX研究员——The Agency研究Agent；识别了4个核心用户画像；发现调试是杀手级用例；提出空间增加价值/制造摩擦的临界点分析。
-- [[XR-Interface-Architect]]：XR界面架构师——The Agency空间计算Agent；设计了命令剧院布局和7态Agent节点系统；规划了3 LOD节点渲染和舒适度措施。
-- [[Project-Shepherd]]：项目牧羊人——The Agency项目管理Agent；制定了35周时间线（2026年3月-11月）和5个专项团队；识别了5大风险和$121.5K-$155.5K非人员预算。
-- [[LangChain]]：AI编排框架竞争对手；$39/用户/月；弱点：平面仪表板，大规模图不可读。
-- [[CrewAI]]：AI编排框架竞争对手；100K+开发者；弱点：CLI优先，可视化工具有限。
-- [[n8n]]：可视化工作流构建器；$20-50/月；弱点：2D画布无法处理Agent关系。
-- [[Apple-Vision-Pro]]：空间计算平台；全球~100万台（销量从高点下降95%）；Apple战略转向轻量AR眼镜；~3,000个VisionOS原生应用；结论：不应作为主推平台。
+- [[Nexus Spatial]]：产品名称——空间 AI 运维命令中心，由 8 个专业 Agent 协作规划的新产品
+- [[VisionOS]]：Apple 空间计算平台——但因安装量太小（~100 万台）不适合作为主要切入点
+- [[WebXR]]：浏览器空间计算标准——更适合作为分发策略的突破口
+- [[LangChain/LangSmith]]：主要竞品——图编排能力强但界面为平面仪表盘
+- [[CrewAI]]：主要竞品——10 万+开发者使用，但以 CLI 为主、视觉工具薄弱
+- [[n8n]]：主要竞品——可视化工作流构建器，但 2D 画布难以表达 Agent 关系
+- [[Yjs]]：协作引擎——基于 CRDT 的冲突无关并发编辑，用于多用户空间协作
+- [[Rust]]：编排引擎语言——亚毫秒调度、零 GC 停顿、内存安全，适合 Agent 沙箱化
 
 ## Connections
-- [[SpatialAIOps]] ← defines ← [[Nexus-Spatial]]
-- [[Product-Trend-Researcher]] → validated → [[Nexus-Spatial]] (CONDITIONAL GO)
-- [[UX-Researcher]] → identified → [[Debugging-Visualization]] (killer use case)
-- [[Backend-Architect]] → designed → [[Rust-Orchestration]]
-- [[XR-Interface-Architect]] → designed → [[Command-Theater-Interface]]
-- [[Growth-Hacker]] → planned → [[Growth-Loop]] strategy
-- [[Nexus-Spatial]] ← depends_on ← [[Rust-Orchestration]]
-- [[Nexus-Spatial]] ← depends_on ← [[WebXR]] (primary distribution)
-- [[Nexus-Spatial]] ← depends_on ← [[CRDT-Collaboration]]
-- [[Nexus-Spatial]] ← depends_on ← [[Multi-Agent-Orchestration]]
-- [[Nexus-Spatial]] ← depends_on ← [[Semantic-Zoom]] navigation
-- [[Nexus-Spatial]] ← depends_on ← [[Gaze-Voice-Hands]] interaction
+- [[SpatialAIOps]] ← 定义了新品类 ← [[Nexus Spatial]]
+- [[Nexus Spatial]] ← 分阶段策略 ← [[2D-First Spatial-Second]]
+- [[Nexus Spatial]] ← 空间界面架构 ← [[Command Theater]]
+- [[Nexus Spatial]] ← 杀手级用例 ← [[Debugging As Killer Use Case]]
+- [[WebXR]] ← 分发策略 ← [[WebXR Distribution Unlock]]
+- [[Nexus Spatial]] ← 协作机制 ← [[Yjs]]
+- [[Nexus Spatial]] ← 性能核心 ← [[Rust]]
 
 ## Contradictions
-- 与 [[Multi-Agent-System-Reliability]] 在协调机制设计上的张力：
-  - 冲突点：Multi-Agent-System-Reliability强调需要显式协调机制（共享状态、仲裁者模式）防止多Agent冲突；Nexus-Spatial-Discovery采用Yjs CRDT实现无冲突实时协作，无需中央协调者。
-  - 当前观点：Nexus-Spatial选择去中心化CRDT方案（Yjs + WebRTC），认为"first editor gets write lock"冲突解决足够。
-  - 对方观点：Multi-Agent-System-Reliability认为大规模多Agent工作流需要显式协调基础设施。
-  - 注：两者针对的场景不同（Nexus-Spatial侧重人类协作者的多人实时编辑；Multi-Agent-System-Reliability侧重自主Agent间的任务协调），但底层技术选择有潜在影响——大型Agent管道编排是否也需要CRDT风格的去中心化协调值得进一步研究。
+- 与现有 AI Agent 编排工具（LangChain/n8n/CrewAI）**互补而非直接竞争**：它们专注工作流构建，Nexus Spatial 专注空间监控与编排可视化
+- 与 Vision Pro 原生应用策略**存在张力**：早期阶段不建议主攻 VisionOS，但品牌演示中需始终强调空间价值
diff --git a/wiki/sources/nexus-strategy.md b/wiki/sources/nexus-strategy.md
new file mode 100644
index 00000000..a2e90387
--- /dev/null
+++ b/wiki/sources/nexus-strategy.md
@@ -0,0 +1,74 @@
+---
+title: "NEXUS — Network of EXperts, Unified in Strategy"
+type: source
+tags: ["multi-agent", "orchestration", "project-management", "workflow", "quality-gate"]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/nexus-strategy.md]]
+
+## Summary（用中文描述）
+- 核心主题：NEXUS 是一个多 Agent 编排框架，将独立 AI 专家组成同步的智能网络，用于产品/项目全生命周期管理
+- 问题域：解决独立 Agent 协作中的架构冲突、重复工作、质量缺口、上下文断裂等失效模式
+- 方法/机制：7 阶段流水线（Discovery → Strategy → Foundation → Build → Harden → Launch → Operate）+ Dev↔QA 循环 + 质量门禁
+- 结论/价值：定义 Who/What/When/How/Why 五要素，让每个 Agent 在正确时间做正确的事并向正确的人交接
+
+## Key Claims（用中文描述）
+- NEXUS 通过定义 Who（谁激活）、What（产出给谁）、When（何时交接）、How（质量验证）、Why（为何存在）消除协作失效模式
+- Dev↔QA 循环中每个任务最多重试 3 次，超过则升级（Escalation）至 Agents Orchestrator 或 Studio Producer
+- Reality Checker（质量守门人）在 Phase 4 默认判决为 "NEEDS WORK"，必须用压倒性证据才能获得 "READY" 通过
+- NEXUS 支持三种部署模式：NEXUS-Full（全部 Agent，12-24 周）、NEXUS-Sprint（15-25 个 Agent，2-6 周）、NEXUS-Micro（5-10 个 Agent，1-5 天）
+- Context Continuity 原则确保每次交接携带完整上下文，Agent 不从冷启动开始
+
+## Key Quotes
+> "NEXUS transforms The Agency's independent AI specialists into a synchronized intelligence network. This is not a prompt collection — it is a deployment doctrine that turns The Agency into a force multiplier for any project, product, or organization." — 文档开篇定义
+> "The Reality Checker defaults to 'NEEDS WORK' — you must prove production readiness with overwhelming evidence." — Phase 4 质量哲学
+
+## Key Concepts
+- [[QualityGate]]：阶段间的强制性检查点，要求有证据支持的审批才能进入下一阶段
+- [[DevQALoop]]：持续开发-测试循环，每个任务必须通过 QA 才能进入下一个任务
+- [[ContextContinuity]]：交接携带完整上下文的原理，防止 Agent 冷启动
+- [[Escalation]]：任务超过 3 次重试失败后升级到更高权限 Agent 的机制
+- [[RICEScoring]]：Sprint Prioritizer 使用的 RICE 评分法（Reach × Impact × Confidence / Effort）进行特性优先级排序
+
+## Key Entities
+- [[AgentsOrchestrator]]：管道控制器，协调所有 Agent 激活和阶段推进
+- [[StudioProducer]]：产品组合管理 Agent，负责战略对齐和投资回报目标
+- [[RealityChecker]]：最终集成测试 Agent，Phase 4 唯一质量守门人
+- [[EvidenceCollector]]：截图证据收集 Agent，提供视觉 QA 证明
+- [[SprintPrioritizer]]：RICE 评分 backlog 优先级排序 Agent
+- [[SeniorProjectManager]]：规格转任务清单的 Agent
+
+## Connections
+- [[executive-brief]] ← depends_on ← [[nexus-strategy]]（策略文档为执行简报提供基础）
+- [[quickstart]] ← depends_on ← [[nexus-strategy]]（快速入门文档依赖策略框架）
+- [[agents-orchestrator]] ← extends ← [[nexus-strategy]]（协调器 Agent 实现 NEXUS 管道）
+- [[testing-reality-checker]] ← extends ← [[nexus-strategy]]（Reality Checker Agent 实施 Phase 4 质量门禁）
+- [[project-management-studio-producer]] ← extends ← [[nexus-strategy]]（Studio Producer 角色定义）
+- [[product-sprint-prioritizer]] ← extends ← [[nexus-strategy]]（Sprint Prioritizer 实现 Phase 1 优先级排序）
+
+## Contradictions
+- 与 [[testing-reality-checker]] 的定位：
+  - 冲突点：Reality Checker 作为独立 Agent 个体 vs 作为 Phase 4 质量守门人角色
+  - 当前观点：nexus-strategy 中 Reality Checker 被描述为质量门禁机制（Gate Keeper），是组织架构的一部分
+  - 对方观点：reality-checker.md 将 Reality Checker 描述为单一 QA Agent 的个性定义
+  - 注：两者可共存 — personality 定义 Agent 的行为风格，strategy 文档定义其在管道中的角色
+
+## Sub-Pages（分页导航）
+
+### Phase 章节
+- [[phase-0-discovery]] — Intelligence & Discovery
+- [[phase-1-strategy]] — Strategy & Architecture
+- [[phase-2-foundation]] — Foundation & Scaffolding
+- [[phase-3-build]] — Build & Iterate
+- [[phase-4-hardening]] — Quality & Hardening
+- [[phase-5-launch]] — Launch & Growth
+- [[phase-6-operate]] — Operate & Evolve
+
+### 配套文档
+- [[handoff-templates]] — 标准交接文档模板（Phase 间交接用）
+- [[scenario-enterprise-feature]] — 企业特性完整生命周期场景
+- [[scenario-startup-mvp]] — 创业 MVP 场景
+- [[scenario-marketing-campaign]] — 营销活动场景
+- [[scenario-incident-response]] — 事故响应场景
diff --git a/wiki/sources/open-webui-hermes-agent.md b/wiki/sources/open-webui-hermes-agent.md
new file mode 100644
index 00000000..86572658
--- /dev/null
+++ b/wiki/sources/open-webui-hermes-agent.md
@@ -0,0 +1,61 @@
+---
+title: "Open WebUI | Hermes Agent"
+type: source
+tags:
+  - "hermes-agent"
+  - "open-webui"
+  - "integration"
+  - "api-server"
+  - "docker"
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/Open WebUI  Hermes Agent]]
+
+## Summary（用中文描述）
+- 核心主题：如何将 Open WebUI（最流行的自托管 AI 聊天界面）与 Hermes Agent 通过内置 API Server 进行连接
+- 问题域：AI 前端与 Agent 后端的集成方案，用户希望通过更友好的 Web UI 访问 Hermes Agent
+- 方法/机制：Hermes Agent 提供 OpenAI 兼容的 `/v1/chat/completions` API Server，Open WebUI 通过 Docker 部署并配置 API Base URL 接入；支持多用户 Profiles 场景下多实例部署
+- 结论/价值：用户获得完整的对话管理、用户账户和现代化聊天界面，同时 Agent 保留全部工具集（终端、文件操作、网页搜索、记忆、Skills 等）能力
+
+## Key Claims（用中文描述）
+- Open WebUI 通过 Hermes Agent 内置 API Server 以类 OpenAI 方式接入，双方无需 CORS 配置（server-to-server 直连）
+- 启用 API Server 只需在 `~/.hermes/.env` 中设置 `API_SERVER_ENABLED=true` 和 `API_SERVER_KEY=your-secret-key`
+- Docker 部署 Open WebUI 时，必须使用 `host.docker.internal` 访问宿主机端口，`localhost` 在容器内指向容器自身
+- 模型下拉菜单默认显示 Profile 名称，可通过 `API_SERVER_MODEL_NAME` 环境变量覆盖
+- 多用户场景下，每个 Profile 运行独立 API Server（不同端口），在 Open WebUI Admin 中逐一添加连接
+
+## Key Quotes
+
+> "Open WebUI talks to Hermes server-to-server, so you do not need `API_SERVER_CORS_ORIGINS` for this integration." — 架构说明，server-to-server 无需 CORS
+
+> "The model name defaults to the profile name. To override it, set `API_SERVER_MODEL_NAME` in the profile's `.env`." — 自定义模型名称的方法
+
+> "Environment variables only take effect on Open WebUI's first launch. After that, connection settings are stored in its internal database." — Docker 部署重要限制
+
+## Key Concepts
+- [[APIServer]]: Hermes Agent 内置的 OpenAI 兼容 HTTP Server，提供 `/v1/chat/completions` 等端点
+- [[ChatCompletions]]: OpenAI 标准聊天补全 API 格式，默认模式，推荐使用
+- [[ResponsesAPI]]: OpenAI 实验性响应 API，支持 `previous_response_id` 维持对话状态和结构化事件流
+- [[ToolStreaming]]: 工具执行时实时流式输出工具 emoji 和关键参数到 UI，提供可见性
+- [[DockerHostNetworking]]: Docker 容器访问宿主机服务的方式（`host.docker.internal` 或 `--network=host`）
+
+## Key Entities
+- [[OpenWebUI]]: 最流行的自托管 AI 聊天界面（126k GitHub stars），作为 Hermes Agent 的 Web 前端
+- [[HermesAgent]]: Nous Research 的 AI Agent 框架，支持多平台（CLI、Telegram、Gateway），内置 API Server
+- [[DockerCompose]]: 多容器应用编排工具，用于持久化部署 Open WebUI
+- [[Profiles]]: Hermes Agent 的多配置文件系统，每个 Profile 独立运行，支持多用户隔离
+
+## Connections
+- [[OpenWebUI]] ← connects_to ← [[HermesAgent]] (via APIServer `/v1/chat/completions`)
+- [[HermesAgent]] ← enables ← [[APIServer]] (env: `API_SERVER_ENABLED=true`)
+- [[OpenWebUI]] ← served_by ← [[DockerCompose]] (持久化部署)
+- [[HermesAgent]] ← scales_via ← [[Profiles]] (多用户多实例)
+
+## Contradictions
+- 与 [[ResponsesAPI]] vs [[ChatCompletions]] 的选择：
+  - 冲突点：两种 API 模式的适用场景描述
+  - 当前观点：文档推荐 Chat Completions（开箱即用）；Responses API 提供结构化事件流但当前 Open WebUI 仍客户端管理历史
+  - 对方观点：Responses API 可通过 `previous_response_id` 维持服务端对话状态
+  - 注：两者并非真正冲突，Responses 是实验性增强，Chat Completions 是默认稳定选择
diff --git a/wiki/sources/paid-media-auditor.md b/wiki/sources/paid-media-auditor.md
index e5bf0262..1bb5705e 100644
--- a/wiki/sources/paid-media-auditor.md
+++ b/wiki/sources/paid-media-auditor.md
@@ -1,71 +1,61 @@
 ---
 title: "Paid Media Auditor Agent"
 type: source
-tags: ["paid-media", "google-ads", "microsoft-advertising", "meta-ads", "audit", "account-optimization", "ai-agent"]
-date: 2026-04-20
+tags: []
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/paid-media/paid-media-auditor.md]]
+- [[Agent/agency-agents/paid-media/paid-media-auditor.md]]
 
 ## Summary（用中文描述）
-- 核心主题：企业级付费媒体账户审计 Agent——系统化评估 Google Ads、Microsoft Ads 和 Meta Ads 账户，覆盖 200+ 检查点，输出带优先级和预估影响的可操作审计报告
-- 问题域：付费媒体账户中账户结构、追踪配置、竞价策略、创意素材、受众定向和竞争定位等方面的结构性缺陷和效率损失
-- 方法/机制：200+ 检查点执行框架，按严重程度分级（critical/high/medium/low），结合 API 自动化数据提取与人工策略分析，每项发现附带具体修复方案和业务影响预估
-- 结论/价值：审计通常能识别 15-30% 的效率提升空间，80%+ 高优先级建议在 30 天内落地实施
+- 核心主题：付费媒体账户审计 Agent——系统化评估 Google Ads、Microsoft Ads、Meta 三大平台广告账户，涵盖 200+ 检查点，输出结构化审计报告与优先级建议。
+- 问题域：广告账户效率低下、预算浪费、追踪配置错误、出价策略不当、着陆页体验差等问题的系统性诊断。
+- 方法/机制：通过 8 大审计类别（账户结构、追踪测量、出价预算、关键词定向、创意素材、购物馈送、竞争定位、着陆页），逐项检查并按严重度打分，结合 API 自动化数据提取，最终生成可执行建议。
+- 结论/价值：审计通常可发现 15-30% 的效率提升空间，关键建议实施后 30 天内执行率达 80%+，60 天内可见可衡量效果提升。
 
 ## Key Claims（用中文描述）
-- Paid Media Auditor Agent 通过 200+ 检查点框架评估每个账户，覆盖账号结构、追踪配置、竞价策略、创意、受众和竞争定位六大维度
-- 审计发现包含严重程度评分、具体修复方案和预估业务影响，确保 100% 发现具备可操作性
-- 账户结构审计（Campaign Taxonomy、命名规范、地理定向、设备出价调整）直接影响广告系统的信号识别效率
-- 追踪与测量审计（Conversion Action 配置、归因模型、GTM/GA4 验证、Enhanced Conversions）是竞价优化的数据基础
-- 竞价与预算审计（Bid Strategy Appropriateness、Learning Period Violations、Portfolio 策略）直接影响 CPA 和 ROAS 表现
-- 关键词与定向审计（Match Type 分布、负向关键词覆盖率、QS 分布、受众 vs 观察模式）是搜索广告效率的核心
-- 创意审计（RSA Pin 策略、资产组评分、测试节奏）是点击率和转化率的直接影响因素
-- Shopping 与 Feed 审计（标题优化、自定义标签策略、下架率）是购物广告流量的关键
-- 竞争定位审计（Auction Insights、Impression Share Gap、Top-of-Page Rate）是预算分配策略的数据依据
-- Landing Page 审计（页面速度、移动体验、信息匹配度、重定向链）是转化率优化的前端保障
-- 历史趋势分析能够识别绩效下降的起点并关联至账户变更，而合规审计（医疗/金融/法律）则覆盖受监管行业的特殊政策要求
+- Paid Media Auditor Agent 以法务会计师审查财务报表的方式审视广告账户，不放过任何一个设置、假设或资金。
+- 8 大审计类别覆盖账户结构、追踪测量、出价预算、关键词定向、创意素材、购物馈送、竞争定位、着陆页，构建完整审计体系。
+- Google Ads MCP 工具/API 可自动化数据提取阶段，替代手动导出，直接对接 200+ 检查点评估。
+- 审计通常能发现 15-30% 的广告效率提升空间，关键和高优先级建议 30 天内执行率达 80%+。
+- 每项发现均附带严重度级别、业务影响估算和具体修复指令，确保 100% 可执行。
 
 ## Key Quotes
-> "Methodical, detail-obsessed paid media auditor who evaluates advertising accounts the way a forensic accountant examines financial statements — leaving no setting unchecked, no assumption untested, and no dollar unaccounted for." — Agent 核心定位
-> "Run the automated data pull first, then layer strategic analysis on top. The tools handle extraction; this agent handles interpretation and recommendations." — 工具与 Agent 协作模式
-> "Every finding comes with severity, business impact, and a specific fix." — 审计发现标准格式
-> "Audits typically identify 15-30% efficiency improvement opportunities." — 审计价值量化
-> "80%+ of critical and high-priority recommendations implemented within 30 days." — 落地执行率
+> "Methodical, detail-obsessed paid media auditor who evaluates advertising accounts the way a forensic accountant examines financial statements — leaving no setting unchecked, no assumption untested, and no dollar unaccounted for." — 角色定义核心理念
+
+> "Finds the waste in your ad spend before your CFO does." — Agent 核心使命
+
+> "The tools handle extraction; this agent handles interpretation and recommendations." — 人机协作分工
 
 ## Key Concepts
-- [[AccountAudit]]：付费媒体账户审计——系统化评估账户各维度设置、策略和表现的过程
-- [[ConversionTracking]]：转化追踪——配置转化 Action、验证 GTM/GA4、实施 Enhanced Conversions 和离线转化导入
-- [[AttributionModeling]]：归因模型——选择适合业务目标的归因模型（Last Click/First Click/Linear/Time-Decay/Data-Driven）
-- [[BidStrategy]]：出价策略——评估 Bid Strategy Appropriateness、Learning Period 合规性、Portfolio 策略配置
-- [[QualityScore]]：质量得分——关键词粒度的 QS 分布分析，直接影响 CPC 和广告排名
-- [[NegativeKeywordManagement]]：负向关键词管理——负向关键词覆盖率直接影响流量质量和预算消耗效率
-- [[AuctionInsights]]：竞价洞察——分析竞争对手的展示份额重叠率和首页出价率，为预算分配提供数据依据
-- [[Dayparting]]：时段出价——基于日间分时设置的设备/时段出价调整，优化特定时段的竞价策略
-- [[ResponsiveSearchAds]]：响应式搜索广告——RSA Pin 策略确保核心信息在广告中的稳定展示
-- [[ProductFeedOptimization]]：产品 Feed 优化——购物广告的产品标题、自定义标签和下架率管理
-- [[LandingPageAudit]]：着陆页审计——页面速度、移动体验、信息匹配度和重定向链检查
-- [[CompetitivePositioning]]：竞争定位——通过 Auction Insights 分析识别竞争差距和机会点
+- [[AccountStructureAudit]]：账户结构审计——评估活动分类法、广告组粒度、命名规范、地理定向、设备出价调整、日间投放设置。
+- [[TrackingMeasurementAudit]]：追踪与测量审计——验证转化动作配置、归因模型选择、GTM/GA4 实现、增强型转化设置、跨域追踪。
+- [[BiddingBudgetAudit]]：出价与预算审计——评估出价策略适用性、学习期违规、预算受限活动、投资组合出价配置、出价地板/天花板分析。
+- [[CompetitivePositioningAudit]]：竞争定位审计——分析拍卖洞察数据、印象份额差距、竞争重叠率、首页展示率基准。
+- [[AuditChecklist]]：200+ 点审计检查清单，按严重度分级（critical/high/medium/low），每项含具体修复指令和预估业务影响。
+- [[ImpactEstimation]]：影响估算方法论——预测每项建议带来的收入/效率收益。
+- [[ChangeHistoryForensics]]：变更历史取证——追溯账户变更与下游效果的相关性，识别性能下降根因。
+- [[MessageMatch]]：信息匹配度——广告创意与着陆页内容的一致性评估，确保用户体验连贯。
 
 ## Key Entities
-- [[JohnWilliams]]（@itallstartedwithaidea）：Agent 作者，The Agency 项目付费媒体 Agent 系列的设计者
-- [[GoogleAds]]：主要审计平台之一，提供 Search/Display/Shopping/Performance Max 等多类型广告产品
-- [[MicrosoftAdvertising]]：第二大搜索广告平台，支持从 Google Ads 导入账户，是增量流量的重要来源
-- [[AmazonAds]]：电商广告平台，Product Ads 和 Sponsored Products 是付费媒体的重要流量渠道
-- [[GA4]]：Google Analytics 4，用于验证网站转化追踪配置和跨域追踪正确性
-- [[GTM]]：Google Tag Manager，用于验证标签触发和事件追踪配置
+- [[GoogleAds]]：主要审计平台之一，支持通过 MCP 工具/API 自动化提取活动设置、质量得分、转化配置数据。
+- [[MicrosoftAdvertising]]：审计覆盖的三大平台之一，支持导入 Google Ads 配置进行差距分析。
+- [[MetaAds]]：审计覆盖的三大平台之一，支持 Meta Pixel/CAPI 验证。
+- [[JohnWilliams]]：Agent 作者，X/Twitter ID：@itallstartedwithaidea，付费媒体审计专家。
+- [[GA4]]：Google Analytics 4，审计中用于交叉验证 Google Ads 转化数据。
+- [[GoogleTagManager]]：GTM，审计中用于验证追踪配置实现。
+- [[GoogleAdsScripts]]：Google Ads 脚本，自动化数据提取工具。
 
 ## Connections
-- [[paid-media-ppc-strategist]] ← audit_prerequisite ← [[paid-media-auditor]]：PPC Strategist 定义账户基准和策略框架，Auditor 基于该基准进行效果诊断
-- [[paid-media-tracking-specialist]] ← depends_on ← [[paid-media-auditor]]：Auditor 依赖 Tracking Specialist 配置的追踪基础设施进行数据验证
-- [[paid-media-search-query-analyst]] ← data_source ← [[paid-media-auditor]]：Auditor 提供关键词质量数据供 Query Analyst 进一步分析
-- [[paid-media-creative-strategist]] ← depends_on ← [[paid-media-auditor]]：Auditor 的创意评分结果为 Creative Strategist 提供优化方向
+- [[PaidMediaPPCStrategist]] ← part_of ← [[AgencyAgents]]
+- [[PaidMediaProgrammaticBuyer]] ← part_of ← [[AgencyAgents]]
+- [[PaidMediaTrackingSpecialist]] ← depends_on ← [[TrackingMeasurementAudit]]
+- [[PaidMediaSearchQueryAnalyst]] ← shares_platform ← [[GoogleAds]]
+- [[PaidMediaCreativeStrategist]] ← shares_platform ← [[MetaAds]]
 
 ## Contradictions
-- 与 [[paid-media-ppc-strategist]] 在账户结构评估标准上的潜在视角差异：
-  - 冲突点：PPC Strategist 从"账户架构即战略"的角度设计活动结构，Auditor 从"现状审计"的角度检验既有结构是否合理
-  - 当前观点：两者互补而非互斥——PPC Strategist 定义目标架构，Auditor 验证现状与目标的差距
-- 与 [[paid-media-programmatic-buyer]] 在效果衡量维度上的互补张力：
-  - 冲突点：Programmatic Buyer 关注展示广告的漏斗上层指标（Brand Lift、VTC），Auditor 在 Display 广告审计中可能过度聚焦下漏斗指标
-  - 当前观点：审计报告应区分广告类型适配不同的 KPI 框架
+- 与 [[PaidMediaTrackingSpecialist]]：
+  - 冲突点：追踪专项 Agent 深度聚焦追踪配置，Paid Media Auditor 将追踪审计作为 8 大类别之一而非独立专业领域。
+  - 当前观点：Paid Media Auditor 视追踪测量为账户审计的一个检查维度，由通用框架驱动。
+  - 对方观点：追踪专项 Agent 主张追踪配置需要独立专项审视，深度优于广度。
diff --git a/wiki/sources/paid-media-creative-strategist.md b/wiki/sources/paid-media-creative-strategist.md
index 690b0c24..c7a4538f 100644
--- a/wiki/sources/paid-media-creative-strategist.md
+++ b/wiki/sources/paid-media-creative-strategist.md
@@ -1,63 +1,55 @@
 ---
 title: "Paid Media Ad Creative Strategist Agent"
 type: source
-tags: ["paid-media", "creative", "advertising", "google-ads", "meta-ads", "ppc", "agent-persona"]
-date: 2026-04-25
+tags: []
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/paid-media/paid-media-creative-strategist.md]]
+- [[Agent/agency-agents/paid-media/paid-media-creative-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：付费媒体广告创意策略 Agent，专注于 Google、Meta、Microsoft 及程序化平台的全渠道广告文案创作、响应式搜索广告（RSA）架构设计和系统性创意测试框架。
-- 问题域：如何在算法控制竞价、预算和定向的自动化竞价环境中，通过创意这一唯一可控变量实现效果最大化；创意疲劳监测与快速迭代难题。
-- 方法/机制：15-headline RSA 策略设计（全品牌/利益/功能/CTA/社会证明分类）；Hook-Body-CTA 视频广告结构；资产组（Asset Group）组合策略；A/B 测试框架与统计显著性标准；广告强度评分优化。
-- 结论/价值：创意是自动化竞价环境中最大的可控杠杆，每一条标题、描述、图片和视频都是一个待验证的假设，必须通过系统性测试持续迭代。
+- 核心主题：付费媒体广告创意策略 Agent——将广告创意从"凭感觉"转变为"可重复的科学"
+- 问题域：自动化竞价环境下（算法控制出价/预算/定向），创意成为广告主唯一可控的杠杆；创意疲劳监测与系统性 A/B 测试框架缺失
+- 方法/机制：15-headline RSA 架构设计、Meta Hook-Body-CTA 视频框架、Performance Max 资产组编排、Google Ads MCP API 数据驱动创意审核
+- 结论/价值：创意是自动化竞价环境中最大的剩余可控变量；每次标题/描述/图片/视频都是待验证的假设
 
 ## Key Claims（用中文描述）
-- 在 tCPA/tROAS/Max Conversions 等自动化竞价环境中，创意是广告主唯一实际可控的变量，算法接管了出价、预算和定向。
-- RSA 的 15 条标题和 4 条描述的所有可能组合必须语法和逻辑上都能成立，这是架构设计的核心挑战。
-- 创意疲劳（Creative Fatigue）是效果下降的主因，必须通过 CTR 趋势监测和超优展示阈值识别及时刷新。
-- 广告强度（Ad Strength）90%+ 达到 "Good" 或 "Excellent" 是 RSA 质量基准；Meta 相关性诊断需高于平均或顶级表现。
-- 统计显著性（Statistical Significance）是判定创意胜负的唯一可靠标准，必须在 2-4 周内达到。
+- 创意是自动化竞价环境中广告主唯一真正可控的变量——算法控制出价、预算和定向
+- 每个标题、描述、图片和视频都是待验证的假设（A/B 测试是核心方法论）
+- RSA（Responsive Search Ads）需确保所有 15 条标题与描述组合在语法和逻辑上都能成立
+- 创意疲劳监测通过分析广告级指标（CTR 下降趋势）识别超优展示阈值的广告
+- Google Ads API 可直接创建 RSA 标题、更新描述、管理广告扩展，无需手动 UI 操作
 
 ## Key Quotes
-> "Creative is the largest remaining lever in automated bidding environments — when the algorithm controls bids, budget, and targeting, the creative is what you actually control." — 核心价值观阐述
-> "Every headline, description, image, and video is a hypothesis to be tested." — 创意即假设
-> "Always audit existing ad performance before writing new creative. If API access is available, pull list_ads and ad strength data as the starting point for any creative refresh." — 数据优先原则
+> "Creative is the largest remaining lever in automated bidding environments — when the algorithm controls bids, budget, and targeting, the creative is what you actually control." — John Williams (@itallstartedwithaidea)
+> "Every headline, description, image, and video is a hypothesis to be tested." — John Williams (@itallstartedwithaidea)
 
 ## Key Concepts
-- [[ResponsiveSearchAds]]: RSA（响应式搜索广告），Google Ads 核心广告格式，由最多 15 条标题和 4 条描述自由组合，系统自动测试最优搭配。
-- [[PerformanceMax]]: Performance Max 广告系列，Google 全渠道自动化广告，创意资产组（Asset Group）是核心输入，决定系统学习信号质量。
-- [[AssetGroup]]: 资产组，Performance Max 的创意容器，由文本资产、图片、视频、Logo 等组成，决定广告主题表达质量。
-- [[AdStrength]]: 广告强度评分，Google 衡量 RSA 或 PMax 创意质量的指标，90%+ "Good/Excellent" 是基准目标。
-- [[CreativeFatigue]]: 创意疲劳，广告在超优展示阈值后点击率自然下降的现象，需通过定期刷新和新鲜创意对抗。
-- [[HookBodyCTA]]: Hook-Body-CTA 结构，视频广告的叙事框架——钩子（0-3秒）吸引注意，主体传递价值，号召行动促进转化。
-- [[ABTesting]]: A/B 测试框架，创意验证的标准方法，通过统计显著性判定胜负，指导规模化应用。
-- [[MessageMatch]]: 消息匹配评分，衡量广告创意与落地页内容一致性的指标，直接影响质量得分和转化率。
-- [[StatisticalSignificance]]: 统计显著性，创意测试的判断标准，确保结果可推广而非随机波动。
-- [[AdExtensions]]: 广告附加信息（Sitelink/Callout/Structured Snippets/Image Extensions 等），扩展广告视觉空间和点击率。
+- [[ResponsiveSearchAds|RSA（Responsive Search Ads）架构]]：15-headline 策略设计（品牌/利益/功能/CTA/社会证明分类），描述配对逻辑，确保所有组合语义连贯
+- [[CreativeFatigueMonitoring|创意疲劳监测]]：通过分析广告级指标识别 CTR 下降趋势，标记超出最优展示阈值的广告
+- [[MessageMatchScoring|信息匹配评分]]：广告与落地页的连贯性评分、标题延续性、CTA 一致性
+- [[StatisticalSignificance|统计显著性]]：创意测试中判断胜出/失败的科学标准，2-4 周内达到统计显著性
+- [[HookBodyCTA|Hook-Body-CTA 框架]]：Meta 视频广告结构——钩子（前3秒抓注意力）→ 正文（传递核心信息）→ CTA（明确行动指引）
+- [[AssetGroupComposition|资产组编排]]：Performance Max 中文本/图片/视频资产的组合策略，信号组与创意主题对齐
 
 ## Key Entities
-- [[GoogleAds]]: Google Ads 平台，核心投放渠道，提供 RSA、Performance Max、Ad Strength 数据和 Google Ads MCP 工具集成。
-- [[MetaAdsManager]]: Meta（Facebook/Instagram）广告管理平台，支持 Primary Text/Headline/Description 框架和 Relevance Diagnostics。
-- [[MicrosoftAdvertising]]: Microsoft Advertising（Bing/AOL/Yahoo）搜索广告平台，与 Google Ads 并行的 PPC 渠道。
-- [[PerformanceMax]]: Google Performance Max 广告系列，AI 驱动的全渠道投放，Asset Group 质量决定效果上限。
-- [[JohnWilliams]]: Agent 作者（@itallstartedwithaidea），资深付费媒体创意策略师。
+- [[JohnWilliams|John Williams (@itallstartedwithaidea)]]：作者，Ad Creative Strategist Agent 设计者
+- [[GoogleAds|Google Ads]]：核心投放平台——RSA、Performance Max、广告扩展
+- [[MetaAds|Meta Ads]]：Facebook/Instagram 广告平台——创意格式选择、受众定向
+- [[MicrosoftAds|Microsoft Ads]]：Bing 搜索广告平台
+- [[ProgrammaticPlatforms|Programmatic（程序化广告平台）]]：自动化展示/视频/音频广告购买
 
 ## Connections
-- [[PaidMediaPpcStrategist]] ← coordinates_with ← [[PaidMediaCreativeStrategist]]: PPC 策略师制定活动架构，创意策略师提供素材支撑，两者协同制定 Performance Max 和 Display 投放方案。
-- [[PaidMediaProgrammaticBuyer]] ← depends_on ← [[PaidMediaCreativeStrategist]]: 程序化购买依赖高质量创意资产填充展示和视频广告库存。
-- [[PaidMediaSearchQueryAnalyst]] ← informs ← [[PaidMediaCreativeStrategist]]: 搜索查询分析师提供关键词意图数据，创意策略师据此撰写关键词插入文案。
-- [[PaidMediaTrackingSpecialist]] ← depends_on ← [[PaidMediaCreativeStrategist]]: 追踪专家提供的 CTR/CVR 数据是判断创意胜负的基础。
-- [[PaidMediaAuditor]] ← depends_on ← [[PaidMediaCreativeStrategist]]: 审计师诊断广告效果，创意刷新是优化策略的核心输出之一。
+- [[paid-media-search-query-analyst]] ← feeds_into ← [[paid-media-creative-strategist]]（查询分析识别高意图词 → 创意策略锚定关键词）
+- [[paid-media-auditor]] ← feeds_into ← [[paid-media-creative-strategist]]（审计发现创意弱项 → 触发创意刷新）
+- [[paid-media-ppc-strategist]] ← depends_on ← [[paid-media-creative-strategist]]（PPC 策略依赖创意执行）
+- [[paid-media-tracking-specialist]] ← receives_data ← [[paid-media-creative-strategist]]（创意效果数据由追踪专家分析）
+- [[design-visual-storyteller]] ← upstream_source ← [[paid-media-creative-strategist]]（视觉叙事为创意策略提供视觉素材）
 
 ## Contradictions
-- 与 [[PaidMediaPpcStrategist]] 在"自动化程度"权衡上存在张力：
-  - 冲突点：PPC 策略师倾向于强调 Smart Bidding 和自动化优化；创意策略师认为创意质量是瓶颈，自动化不能弥补低质量素材。
-  - 当前观点：创意是决定性杠杆，即使在自动化竞价环境中也需要人工精心设计的 RSA 组合和 Asset Group 策略。
-  - 对方观点：Broad Match + Smart Bidding 组合可以弥补创意不足，系统会自动寻找最优受众-创意搭配。
-- 与 [[PaidMediaProgrammaticBuyer]] 在"创意新鲜度"上存在潜在冲突：
-  - 冲突点：程序化购买强调规模化和成本效率，倾向于复用已有创意；创意策略师强调创意疲劳必须通过高频迭代对抗。
-  - 当前观点：持续创意迭代（每 2 周一次测试）是效果保持的必要条件，低频迭代会导致 CPM 上升和 CTR 下降。
-  - 对方观点：程序化购买的受众覆盖足够广泛，可以抵消创意疲劳的影响。
+- 与 [[paid-media-ppc-strategist]] 关于预算分配视角：
+  - 冲突点：PPC 策略偏向基于 ROAS 的预算分配，创意策略偏向基于测试假设的创意投入
+  - 当前观点：创意是独立可控变量，应优先保证测试节奏（每两周每主要活动新测试）
+  - 对方观点：预算应集中于历史胜出创意，减少"实验性"投入
+  - 协调方案：创意测试小预算独立运作，确认胜出后纳入 PPC 预算优化框架
diff --git a/wiki/sources/paid-media-paid-social-strategist.md b/wiki/sources/paid-media-paid-social-strategist.md
index 04c33db9..b7b69b1b 100644
--- a/wiki/sources/paid-media-paid-social-strategist.md
+++ b/wiki/sources/paid-media-paid-social-strategist.md
@@ -1,54 +1,56 @@
 ---
 title: "Paid Social Strategist"
 type: source
-tags: []
-date: 2026-04-25
+tags: [paid-media, social-ads, meta, linkedin, tiktok, the-agency]
+sources: [paid-media-paid-social-strategist]
+last_updated: 2026-04-25
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/paid-media/paid-media-paid-social-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：跨平台付费社交广告专家 Agent，覆盖 Meta（Facebook/Instagram）、LinkedIn、TikTok、Pinterest、X 和 Snapchat，设计从引流到再营销的全漏斗社交广告项目。
-- 问题域：社交广告的本质是"打断"而非"回答"，如何在各平台原生体验与广告效果之间取得平衡；iOS 隐私政策对追踪归因的冲击；跨平台受众重叠与频次管理难题。
-- 方法/机制：全漏斗结构（引流 → 互动 → 再营销 → 留存）；平台差异化创意策略（UGC 风格适配 TikTok/Meta，专业内容适配 LinkedIn）；受众工程（像素自定义受众、CRM 上传、互动受众）；Conversions API / 服务端事件追踪；SKAdNetwork 应对 iOS 隐私变化。
-- 结论/价值：为每个社交平台构建原生广告体验，而非跨平台复用同一创意；通过跨渠道数据验证增量贡献，避免重复计算转化。
+- 核心主题：跨平台付费社交广告全栈策略专家，覆盖 Meta、LinkedIn、TikTok 等主流社交平台的全漏斗广告项目设计与运营
+- 问题域：如何在隐私限制（iOS 14+）和平台碎片化的背景下，通过差异化创意和精准受众工程实现高效的社交广告投入产出
+- 方法/机制：全漏斗架构设计（引流→互动→再营销→留存）、平台原生创意策略、受众工程（像素受众/Lookalike/CRM 匹配）、Conversions API 实施、跨平台预算分配与增量测试
+- 结论/价值：社交广告本质是"打断"而非"回答"，必须为每个平台构建原生体验而非跨平台复用创意；跨渠道预算分配必须基于搜索+展示+社交综合数据验证
 
 ## Key Claims（用中文描述）
-- 付费社交广告本质上是"打断"用户而非"回答"问题，因此创意和受众策略必须赢得用户注意力。
-- 各平台是独立生态系统（Meta Ads Manager、LinkedIn Campaign Manager、TikTok Ads 各有不同算法机制和用户行为），不应跨平台复用同一套创意。
-- iOS 隐私变化后，SKAdNetwork 和聚合事件测量成为移动归因的核心手段，Conversions API 实施至关重要。
-- 跨渠道预算分配必须基于跨渠道证据（搜索+展示+社交综合数据），避免基于单一渠道数据做预算决策。
+- 跨平台社交广告专家覆盖 Meta（Facebook/Instagram）、LinkedIn、TikTok、Pinterest、X 和 Snapchat 六 大平台，通过平台差异化创意策略而非通用素材实现高效触达
+- Meta 广告核心能力包括 CBO vs ABO 活动结构选择、Advantage+ 活动、受众扩展、自定义受众与相似受众构建、广告目录销售、Lead Gen 表单及 Conversions API 集成
+- LinkedIn 广告凭借职位定向、文档广告、ABM 列表上传和 LinkedIn Audience Network，成为 B2B 社交广告的核心阵地，Social-to-CRM 管线追踪是 B2B 线索质量验证的关键
+- TikTok 广告需利用 Spark Ads、TopView、信息流广告和创作者合作放大，通过 TikTok Creative Center 识别创意趋势并快速适配，这与 Meta 的 UGC 风格存在显著差异
+- 预算优化需跨平台分配，分析每个平台的边际收益递减拐点，在季节性预算转移中动态调整新平台测试预算
+- SKAdNetwork 和 Aggregated Event Measurement 是应对 iOS 隐私变化的核心手段，Creative Fatigue 检测和自动化刷新排期可降低创意老化带来的效率损失
 
 ## Key Quotes
-> "Social advertising is fundamentally different from search — you're interrupting, not answering, so the creative and targeting have to earn attention." — 核心哲学阐述
+> "Social advertising is fundamentally different from search — you're interrupting, not answering, so the creative and targeting have to earn attention." — 核心洞察：社交广告是打断行为而非回答行为，必须通过创意和定向赢得注意力
 
-> "When cross-channel API data is available, always validate social performance against search and display results before recommending budget increases." — 跨渠道验证原则
+> "When cross-channel API data is available, always validate social performance against search and display results before recommending budget increases." — 跨渠道数据验证原则：推荐预算增加前必须用搜索和展示数据验证社交广告的增量贡献
 
 ## Key Concepts
-- [[Full-Funnel Campaign Architecture]]：从引流（Prospecting）到留存（Retention）的完整漏斗结构，各阶段受众策略与预算分配各异。
-- [[Custom Audience Engineering]]：基于像素的自定义受众、CRM 名单上传、互动受众（视频观看者、主页互动者、表单开启者）的构建与排除策略。
-- [[Conversions API]]：服务端事件追踪，与平台像素配合绕过浏览器限制，是后 iOS 14 隐私政策的关键归因基础设施。
-- [[Advantage+ Campaigns]]：Meta 的自动化广告系列，利用机器学习优化受众定位和竞价，是 CBO/ABO 架构的重要演进。
-- [[Audience Overlap Analysis]]：跨平台受众重叠分析，防止频次过载，最大化独特触达。
-- [[Incrementality Testing]]：增量测试，验证社交广告是否带来净新增转化，而非蚕食自然搜索流量。
-- [[SKAdNetwork]]：Apple 的隐私化归因框架，替代 IDFA，用于衡量 iOS 应用广告效果。
+- [[Full-Funnel Architecture]]：全漏斗架构（引流→互动→再营销→留存），各阶段对应不同受众类型和创意策略
+- [[Audience Engineering]]：受众工程——像素自定义受众、CRM 列表上传、参与受众（视频观看者/主页互动者/表单开启者）的精准构建与排除策略
+- [[Creative Fatigue Detection]]：创意疲劳检测与自动化刷新排期，在创意边际效益递减前主动更替
+- [[SKAdNetwork]]：Apple 的隐私优先归因框架（替代 IDFA），与 Conversions API 共同构成后 iOS 14 追踪体系
+- [[Incrementality Testing]]：增量测试，区分社交广告带来的真实新增转化与本会发生的有机转化
+- [[Conversions API]]：服务器端事件传递，绕过浏览器像素限制，与 Meta Pixel 形成双源归因
 
 ## Key Entities
-- [[Meta Ads Manager]]：Facebook/Instagram 广告管理平台，核心工具包括 Advantage+ 购物广告、应用广告、目录销售等。
-- [[LinkedIn Campaign Manager]]：LinkedIn 广告管理后台，支持赞助内容、消息广告、文档广告、ABM 名单上传等 B2B 定向功能。
-- [[TikTok Ads]]：TikTok 广告平台，支持 Spark Ads、TopView、信息流广告、品牌标签挑战等原生内容形式。
-- [[Google Ads MCP Tools]]：可选集成工具，用于跨渠道（搜索+社交）数据对比、增量验证和预算决策支持。
-- [[John Williams]]（@itallstartedwithaidea）：Agent 作者。
+- [[Meta Ads Manager]]：Meta 广告管理平台，支持 CBO/ABO、Advantage+、自定义受众和目录销售
+- [[LinkedIn Campaign Manager]]：LinkedIn 广告管理平台，提供职位定向、文档广告、ABM 和 Lead Gen 表单
+- [[TikTok Ads]]：TikTok 广告平台，核心格式包括 Spark Ads、TopView 和信息流广告，创意趋势需快速追踪
+- [[Google Ads MCP]]：Google Ads MCP 工具集成，用于跨渠道数据交叉验证和增量分析
 
 ## Connections
-- [[Paid Media Search Query Analyst]] ← parallel_specialization ← [[Paid Media Paid Social Strategist]]（两者同属付费媒体 Agent 体系，一个专注搜索查询，一个专注社交广告）
-- [[Paid Media Programmatic Buyer]] ← channel_extension ← [[Paid Media Paid Social Strategist]]（程序化购买与社交广告共享受众工程和数据归因方法论）
-- [[Paid Media Creative Strategist]] ← depends_on ← [[Paid Media Paid Social Strategist]]（创意策略依赖社交策略的受众洞察和平台选择）
-- [[Paid Media Auditor]] ← informs ← [[Paid Media Paid Social Strategist]]（审计结果指导社交广告的优化方向）
+- [[paid-media-ppc-strategist]] ← 协同 ← [[paid-media-paid-social-strategist]]：搜索广告与社交广告在全渠道预算分配中互补，后者为前者提供品牌曝光和潜客获取能力
+- [[paid-media-creative-strategist]] ← 协同 ← [[paid-media-paid-social-strategist]]：创意策略师基于社交策略师的受众洞察定制平台原生创意执行
+- [[paid-media-tracking-specialist]] ← 支持 ← [[paid-media-paid-social-strategist]]：追踪专家提供的 Conversions API 实施和归因数据是社交广告优化的基础
+- [[paid-media-programmatic-buyer]] ← 互补 ← [[paid-media-paid-social-strategist]]：程序化购买专注展示和品牌曝光，社交广告专注社交平台互动与转化，两者共同构成全渠道覆盖
 
 ## Contradictions
-- 与 [[Paid Media Programmatic Buyer]] 在"自动化 vs. 控制"的权衡上存在张力：
-  - 冲突点：程序化购买强调自动化竞价和实时优化；社交广告中的 Advantage+ 也强调自动化，但该 Agent 同时强调人工干预的受众排除和频次管理。
-  - 当前观点：社交广告需要人工把控受众排除策略和跨平台频次，防止自动化算法过度扩张。
-  - 对方观点：程序化购买可以高度依赖算法自动学习，人工干预应最小化。
+- 与 [[paid-media-ppc-strategist]] 潜在张力：
+  - 冲突点：高意图搜索流量（搜索广告）与低意图社交流量的预算分配优先级
+  - 当前观点：社交广告应基于自身增量贡献分配预算，不应仅为搜索广告补充曝光
+  - 对方观点：搜索广告的确定性转化更高，预算应优先保证搜索渠道
+  - 协调方式：通过增量测试框架验证社交渠道的净新增价值，而非依赖平台自身归因
diff --git a/wiki/sources/paid-media-ppc-strategist.md b/wiki/sources/paid-media-ppc-strategist.md
index 9515cd39..c7a5a094 100644
--- a/wiki/sources/paid-media-ppc-strategist.md
+++ b/wiki/sources/paid-media-ppc-strategist.md
@@ -1,58 +1,59 @@
 ---
 title: "Paid Media PPC Campaign Strategist Agent"
 type: source
-tags: ["paid-media", "ppc", "google-ads", "amazon-ads", "performance-marketing", "agent-persona"]
-date: 2026-04-20
+tags: []
+date: 2026-05-01
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/paid-media/paid-media-ppc-strategist.md]]
+- [[Agent/agency-agents/paid-media/paid-media-ppc-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：付费搜索与效果媒体策略 Agent，专注于 Google Ads、Microsoft Advertising、Amazon Ads 三大平台的企业级账户架构设计、自动化竞价策略和预算管理。
-- 问题域：如何设计可规模化（$10K 到 $10M+ 月消费）的付费媒体账户结构、竞价策略选择、预算分配，以及跨平台协同。
-- 方法/机制：分层活动架构（品牌/非品牌/竞品/征服）、自动竞价（tCPA/tROAS/Max Conversions）、Google Ads API 自动化、MCC 级策略、增量测试框架。
-- 结论/价值：提供从账户新建到持续优化的全链路策略指导，覆盖 Search/Shopping/Performance Max/Demand Gen/Display/Video 等全类型广告。
+- 核心主题：大型规模（$10K 至 $10M+ 月预算）付费搜索与效果媒体的专业 AI Agent 人格定义，涵盖 Google Ads、Microsoft Advertising、Amazon Ads 三大平台
+- 问题域：如何构建可扩展的广告账户架构、自动竞价策略、预算分配与跨平台协同，以实现企业级投放效率目标
+- 方法/机制：通过层级化广告系列结构（品牌/非品牌/竞品/征服）、自动化竞价（tCPA/tROAS/Max Conversions）、Audience Strategy、Google Ads API/MCP 工具集成，实现全自动化策略执行与优化
+- 结论/价值：提供一套从 $10K 到 $10M+ 月预算均可复用的 PPC 战略框架，强调账户结构即战略（account structure as strategy），而非单纯关键词出价
 
 ## Key Claims（用中文描述）
-- 账户架构即战略：不是简单的关键词和出价，而是活动、广告组、受众、信号协同驱动业务成果的系统工程。
-- Broad Match + Smart Bidding 部署是规模化增长的核心组合。
-- Performance Max 资产组设计与信号优化是效果媒体的前沿阵地。
-- Google Ads API + Scripts 是规模化自动化运营的必备能力。
-- 增量测试（geo-split/holdout/matched market）是衡量真实效果的金标准。
+- 账户架构即战略：广告系列/广告组/受众/信号的完整系统协同驱动业务结果，而非单纯关键词和出价
+- 层级化广告系列隔离：品牌、非品牌、竞品、征服四大层级配合隔离策略，防止内部竞争
+- 自动化竞价过渡：支持从手动竞价向 tCPA/tROAS/Max Conversions/Max Conversion Value 的系统性迁移
+- 实时 API 数据优于手动导出：始终优先通过 Google Ads API/MCP 获取 live account_summary/list_campaigns/auction_insights，而非截图或手动导出
+- 预算 pacing 目标：95-100% 日预算利用率，浪费控制在 5% 以内
 
 ## Key Quotes
-> "Account structure as strategy — not just keywords and bids, but how the entire system of campaigns, ad groups, audiences, and signals work together to drive business outcomes." — 核心价值观阐述
-> "Always prefer live API data over manual exports or screenshots." — 数据优先原则
-> "Impression Share: 90%+ brand, 40-60% non-brand top targets" — 品牌与非品牌投放目标基准
+> "Think in terms of account structure as strategy — not just keywords and bids, but how the entire system of campaigns, ad groups, audiences, and signals work together to drive business outcomes." — John Williams (@itallstartedwithaidea)
+
+> "Always prefer live API data over manual exports or screenshots." — Agent 工具规范
 
 ## Key Concepts
-- [[PerformanceMax]]: Performance Max 广告系列，AI 驱动的全渠道广告投放，自动在所有 Google 广告位优化效果。
-- [[SmartBidding]]: 智能竞价策略（tCPA/tROAS/Max Conversions/Max Conversion Value），利用 Google 机器学习自动优化出价。
-- [[AccountArchitecture]]: 账户架构设计，涵盖活动结构、广告组分类、标签系统和命名规范，是规模化运营的基础。
-- [[TieredCampaignArchitecture]]: 分层活动架构（品牌/非品牌/竞品/征服），通过隔离策略实现精细化管理。
-- [[BudgetPacing]]: 预算步速模型，监控日预算消耗速度，防止过早耗尽或余额过剩。
-- [[CustomerMatch]]: Customer Match，通过第一方数据（邮箱/电话等）建立受众，实现精准再营销。
-- [[IncrementalityTesting]]: 增量测试框架（geo-split/holdout/matched market），区分真实增长与自然溢出。
-- [[ConversionActionHierarchy]]: 转化行动层级设计，区分主次转化及微转化与宏转化。
+- [[AccountArchitecture]]：广告账户层级结构设计（Campaign → Ad Group → Keyword/Ad），包括命名规范、标签系统、标签分类体系，支持数百个广告系列规模扩展
+- [[AutomatedBiddingStrategy]]：自动化竞价策略选择（tCPA/tROAS/Max Conversions/Max Conversion Value），包括组合竞价策略和从手动向自动的过渡路径
+- [[BudgetPacing]]：预算分配框架与 pacing 模型，通过递减收益分析和增量支出测试优化预算利用
+- [[PerformanceMax]]：Google Performance Max 广告系列，通过资产组设计与信号优化实现全渠道覆盖
+- [[AudienceStrategy]]：第一方数据激活，包括 Customer Match、Similar Segments、In-Market/Affinity 分层、受众排除与观察/定向模式切换
+- [[TieredCampaignArchitecture]]：分层广告系列架构（品牌/非品牌/竞品/征服）配合隔离策略
+- [[Incrementality-Testing]]：增量测试框架（地理分割测试/Holdout/匹配市场测试），用于衡量付费搜索真实贡献
+- [[CrossPlatformPlanning]]：Google/Microsoft/Amazon 预算分配与平台特定功能挖掘的跨平台策略
 
 ## Key Entities
-- [[GoogleAds]]: Google Ads 平台，核心投放渠道，支持 Search/Shopping/Display/Video/Performance Max 等全类型广告。
-- [[MicrosoftAdvertising]]: Microsoft Advertising（Bing/AOL/Yahoo），与 Google Ads 并行的搜索广告平台，月活覆盖 5.4 亿用户。
-- [[AmazonAds]]: Amazon Ads 平台，电商场景下的搜索广告（Amazon Search）和展示广告，对高购买意图用户触达。
-- [[JohnWilliams]]: Agent 作者（@itallstartedwithaidea），资深付费媒体策略师。
-- [[MCC]]: Google Ads MCC（My Client Center），用于管理多账户组合的中心化管理工具。
-- [[GoogleAdsAPI]]: Google Ads API，官方编程接口，支持规模化账户操作和数据拉取。
+- [[GoogleAds]]：Google Ads 平台 — 核心投放平台，支持 Search/Shopping/Performance Max/Demand Gen/Display/Video 等广告类型，提供 MCC 级别账户管理
+- [[MicrosoftAdvertising]]：Microsoft Ads（Bing）平台 — Google 之外的重要搜索广告平台，与 Google Ads 有类似的账户架构和竞价机制
+- [[AmazonAds]]：Amazon Ads 平台 — 搜索与购物广告的重要补充，尤其适合电商场景
+- [[CustomerMatch]]：Google 第一方数据匹配工具，用于将客户列表上传并激活为受众信号
+- [[GoogleAdsAPI]]：Google Ads API — 企业级程序化账户管理接口，支持大规模自动化操作
+- [[MCCLevelStrategy]]：My Client Center 级别策略 — 在代理/广告主管理多个账户时的顶层协调架构
 
 ## Connections
-- [[PaidMediaProgrammaticBuyer]] ← extends ← [[PaidMediaPpcStrategist]]: Programmatic Buyer 承接 PPC Strategist 的策略，执行程序化购买。
-- [[PaidMediaTrackingSpecialist]] ← depends_on ← [[PaidMediaPpcStrategist]]: 追踪专家提供转化数据，支撑竞价策略优化。
-- [[PaidMediaAuditor]] ← depends_on ← [[PaidMediaPpcStrategist]]: 审计师基于策略基准进行效果诊断。
-- [[PaidMediaCreativeStrategist]] ← coordinates_with ← [[PaidMediaPpcStrategist]]: 创意策略师提供资产支持 Performance Max 和 Display 投放。
-- [[PaidMediaSearchQueryAnalyst]] ← depends_on ← [[PaidMediaPpcStrategist]]: 查询分析师为关键词策略提供搜索词数据。
+- [[PaidMediaProgrammaticBuyer]] ← 同属 ← [[PaidMediaAgentEcosystem]]
+- [[PaidMediaTrackingSpecialist]] ← 支持 ← [[PaidMediaPPCCampaignStrategist]]
+- [[PaidMediaSearchQueryAnalyst]] ← 数据输入 ← [[PaidMediaPPCCampaignStrategist]]
+- [[PaidMediaAuditor]] ← 评估 ← [[PaidMediaPPCCampaignStrategist]]
+- [[PaidMediaCreativeStrategist]] ← 内容协同 ← [[PaidMediaPPCCampaignStrategist]]
 
 ## Contradictions
-- 与 [[PaidMediaProgrammaticBuyer]] 可能存在预算分配冲突：
-  - 冲突点：PPC 侧重搜索意图明确的高转化流量，Programmatic 侧重广泛品牌曝光，两者对有限预算的竞争。
-  - 当前观点：PPC Strategist 认为品牌词和竞品词应严格隔离，Performance Max 覆盖增量用户。
-  - 对方观点：Programmatic Buyer 认为品牌曝光同样重要，程序化购买可以更低 CPM 触达类似受众。
+- 与 [[MarketingSEOSpecialist]] 可能的冲突：
+  - 冲突点：SEO 与 PPC 在同一关键词上的预算竞争关系
+  - 当前观点（付费媒体视角）：付费搜索是确定性流量来源，可通过自动化竞价直接控制 CPA/ROAS，适合短期效果驱动
+  - 对方观点（SEO视角）：有机搜索是可持续的长期流量，不依赖每次点击付费，应优先投入内容与技术优化
+  - 协调建议：采用层级隔离策略——品牌词层由 PPC 主导，非品牌词根据转化数据动态分配自然/付费比例
diff --git a/wiki/sources/paid-media-programmatic-buyer.md b/wiki/sources/paid-media-programmatic-buyer.md
index e3bf97cd..2a83f383 100644
--- a/wiki/sources/paid-media-programmatic-buyer.md
+++ b/wiki/sources/paid-media-programmatic-buyer.md
@@ -2,23 +2,23 @@
 title: "Paid Media Programmatic & Display Buyer Agent"
 type: source
 tags: ["paid-media", "programmatic", "display-advertising", "dsp", "abm", "agent"]
-date: 2026-04-20
+date: 2026-04-26
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/paid-media/paid-media-programmatic-buyer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：定义一个战略性程序化购买与展示广告 Agent，负责跨平台（GDN、DSP、ABM）的广告投放策略制定与执行
-- 问题域：展示广告的规模化采购、受众定位、品牌安全、频次管理及效果归因
-- 方法/机制：支持 Google Display Network、DV360、The Trade Desk、Amazon DSP 等 DSP 平台；Demandbase、6Sense 等 ABM 平台；通过 MCP 工具与 Google Ads API 集成实现自动化投放管理
-- 结论/价值：Agent 能够系统化地规划展示广告活动，管理合作伙伴媒体（25+合作伙伴），执行 ABM 策略，并以品牌安全和可查看性为核心指标进行优化
+- 核心主题：定义一个战略性程序化购买与展示广告 Agent，负责跨平台（GDN、DSP、ABM）的展示广告全流程策略制定与执行
+- 问题域：展示广告的规模化采购、受众定向、品牌安全、频次管理及上漏斗效果归因
+- 方法/机制：支持 Google Display Network、DV360、The Trade Desk、Amazon DSP 等 DSP 平台；Demandbase、6Sense、RollWorks 等 ABM 平台；通过 MCP 工具与 Google Ads API 集成实现自动化投放管理；管理 25+ 合作伙伴媒体（通讯赞助、内容合作）AMP 表格
+- 结论/价值：Agent 以受众优先为核心，将每次展示视为触达正确用户在正确上下文以正确频次的机会；成功衡量以可见性、品牌提升和归因为主，而非最后点击 CPA
 
 ## Key Claims（用中文描述）
-- Agent 以受众优先为策略核心，将每次展示的机会视为触达正确用户在正确上下文以正确频次实现的机会
+- Agent 以受众优先为策略核心，将每次展示机会视为触达正确用户在正确上下文以正确频次实现的机会
 - 展示广告的成功衡量指标以可见性、品牌提升和归因为主，而非单纯的最后点击 CPA
 - 通过 MCP 工具与 Google Ads API 集成，可在无需人工 UI 操作的情况下自动拉取广告位级报告和执行广告排除策略
-- 程序化交易应优先识别无效投放而非盲目扩张
+- 程序化交易应优先识别无效投放（Waste identification）而非盲目扩张
 
 ## Key Quotes
 > "Every impression should reach the right person, in the right context, at the right frequency." — 核心理念
@@ -28,11 +28,12 @@ date: 2026-04-20
 ## Key Concepts
 - [[Programmatic Buying]]：通过 DSP 平台（DV360、The Trade Desk、Amazon DSP）自动化购买展示广告库存，支持 Deal ID、PMP 和程序化保证交易
 - [[ABM Display]]：基于账户的展示广告策略，通过 Demandbase、6Sense、RollWorks 等平台实现对目标企业账户的精准触达
-- [[Viewability]]：广告可见性标准（MRC、GroupM），目标 70%+ 可见展示率
+- [[Viewability]]：广告可见性标准（MRC、GroupM），目标 70%+ 可见展示率（MRC 标准）
 - [[Invalid Traffic]]：无效流量监测，通用 IVT 目标 <3%，复杂 IVT <1%
 - [[Frequency Cap]]：频次上限管理，防止广告疲劳，平均频次目标 3-7 次/月/用户
 - [[Supply Path Optimization]]：供应路径优化，选择最优广告交易路径以提升效率和品牌安全
 - [[Partner Media AMP]]：可寻址媒体计划，管理 25+ 合作伙伴（展示、通讯赞助、内容合作）的媒体预算分配表
+- [[CTV/OTT Advertising]]：联网电视和 Over-the-Top 广告购买，用于扩展数字展示以外的覆盖范围
 
 ## Key Entities
 - [[DV360]]（Display & Video 360）：Google 的企业级 DSP 平台，程序化购买核心工具
@@ -49,9 +50,13 @@ date: 2026-04-20
 - [[paid-media-tracking-specialist]] ← supports ← [[paid-media-programmatic-buyer]]（追踪与归因支撑程序化购买优化）
 - [[paid-media-auditor]] ← validates ← [[paid-media-programmatic-buyer]]（审计 Agent 验证投放效果）
 - [[paid-media-creative-strategist]] ← feeds_into ← [[paid-media-programmatic-buyer]]（创意策略为展示广告提供素材）
+- [[paid-media-ppc-strategist]] ← coordinates ← [[paid-media-programmatic-buyer]]（PPC 策略定义预算分配框架，程序化购买执行具体操作）
 
 ## Contradictions
 - 与 [[paid-media-paid-social-strategist]] 的效果衡量差异：
   - 冲突点：展示广告强调上漏斗指标（品牌提升、可见性），社交广告侧重直接转化和互动指标
   - 当前观点：程序化展示广告应优先衡量可见性和品牌安全，而非最后点击 CPA
   - 对方观点：付费社交广告以互动率和转化率作为核心成功指标
+- 与 [[paid-media-ppc-strategist]] 的目标设定差异：
+  - 冲突点：搜索广告 PPC 天然以 CPA/ROAS 为核心，程序化展示以 Reach/Frequency 为核心
+  - 协调方式：两者均在全渠道预算分配框架内运作，PPC 策略师定义整体预算比例，程序化买家负责在分配额度内优化展示渠道效果
diff --git a/wiki/sources/paid-media-search-query-analyst.md b/wiki/sources/paid-media-search-query-analyst.md
index d3e92a57..de9278e3 100644
--- a/wiki/sources/paid-media-search-query-analyst.md
+++ b/wiki/sources/paid-media-search-query-analyst.md
@@ -1,49 +1,56 @@
 ---
 title: "Paid Media Search Query Analyst Agent"
 type: source
-tags: ["paid-media", "google-ads", "search-query-optimization", "negative-keywords", "ppc"]
-date: 2026-04-24
+tags: ["paid-media", "google-ads", "search-query", "negative-keyword", "ppc", "agency-agents"]
+date: 2026-05-17
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/paid-media/paid-media-search-query-analyst.md]]
+- [[Agent/agency-agents/paid-media/paid-media-search-query-analyst.md]]
 
 ## Summary（用中文描述）
-- 核心主题：付费媒体搜索查询分析师 Agent —— 专注于从用户真实搜索词中挖掘洞察，消除无效投放、扩大高意图流量
-- 问题域：付费搜索账户中的搜索词优化、负关键词架构、意图映射、信号噪音比提升
-- 方法/机制：N-gram 分析、查询聚类、分层负关键词列表构建、意图分类、匹配类型优化、查询雕塑（Query Sculpting）
-- 结论/价值：搜索查询优化是一个持续系统而非一次性任务；每浪费一美元在不相关查询上，就是从转化查询中偷走一美元
+- 核心主题：付费搜索查询分析与优化专家 Agent，专职挖掘搜索词报告、构建负面关键词体系、识别查询-意图缺口，系统性提升付费搜索账户的信噪比。
+- 问题域：付费搜索广告账户中的无效消费、查询漂移（query drift）、关键词-意图错配、内部竞争、匹配类型误用等效率损耗问题。
+- 方法/机制：N-gram 频率分析 → 负面关键词决策树 → 查询聚类 → 意图分类（四阶段：信息型/导航型/商业型/交易型） → 查询雕塑（Query Sculpting） → SQOS 评分体系。
+- 结论/价值：将搜索词优化从"一次性任务"升级为"持续优化系统"——每花费在无关查询上的一美元都是从转化查询中盗走的。
 
 ## Key Claims（用中文描述）
-- 搜索查询分析师通过大规模挖掘搜索词报告，识别模式、构建负关键词层级，将付费搜索账户的信噪比系统化提升
-- 分层负关键词架构（账户级/广告系列级/广告组级）配合共享负关键词列表，可有效消除内部竞争
-- N-gram 频率分析能规模化发现反复出现的不相关修饰词和浪费支出模式
-- Search Query Optimization System (SQOS) 评分从多维度评估查询-广告-落地页对齐程度
-- 品牌 vs 非品牌查询泄漏分析可防止品牌词被非品牌广告系列拦截
+- 专家级搜索词分析师 + N-gram 频率分析 → 大规模识别无关修饰词和浪费消费模式，识别效率提升 10-20%。
+- 分层负面关键词体系（账户级/广告系列级/广告组级）→ 无效展示占比降至 5% 以下。
+- 查询-意图分类（四阶段） → 80% 以上的花费流向意图分类正确的查询。
+- Google Ads MCP 工具 → 直接拉取实时搜索词报告，无需猜测查询模式。
+- SQOS（Search Query Optimization System）评分 → 多因素评分查询-广告-着陆页一致性。
+- 月环比无关消费趋势持续下行 → 可量化的持续浪费预防。
 
 ## Key Quotes
-> "Search query optimization is not a one-time task but a continuous system — every dollar spent on an irrelevant query is a dollar stolen from a converting one." — 核心价值观，贯穿整个 Agent 设计
-
-> "Never guess at query patterns when you can see the real data." — 使用 Google Ads MCP/API 拉取实时数据，而非主观推测
+> "Search query optimization is not a one-time task but a continuous system — every dollar spent on an irrelevant query is a dollar stolen from a converting one." — 核心工作哲学
+> "Always pull the actual search term report before making recommendations. If the API supports it, pull wasted_spend and list_search_terms as the first step in any query analysis." — 工具使用规范
 
 ## Key Concepts
-- [[SearchQueryOptimization]]：从用户实际输入中识别高意图搜索词、排除无效词的系统化持续过程
-- [[NegativeKeywordArchitecture]]：分层负关键词列表（账户级/广告系列级/广告组级）的设计与管理
-- [[NgramAnalysis]]：N-gram 频率分析规模化发现反复出现的不相关修饰词
-- [[IntentClassification]]：将查询映射到买家意图阶段（信息型、导航型、商业型、交易型）
-- [[QuerySculpting]]：通过负关键词和匹配类型组合将查询导向正确广告系列/广告组，防止内部竞争
-- [[SQOSScoring]]：Search Query Optimization System，多因素评分系统，评估查询-广告-落地页对齐度
-- [[CloseVariantAnalysis]]：精确匹配变体影响分析，审核广泛匹配查询扩展
+- [[NegativeKeywordTaxonomy]]：分层负面关键词体系——账户级/广告系列级/广告组级/共享负面列表，附冲突检测机制
+- [[QuerySculpting]]：通过负面关键词和匹配类型组合，将查询导向正确的广告系列/广告组，防止内部竞争
+- [[IntentClassification]]：将用户查询映射到购买意图阶段（信息型 Informational / 导航型 Navigational / 商业型 Commercial / 交易型 Transactional），识别查询与着陆页的意图错配
+- [[NgramAnalysis]]：N-gram 频率分析——在大规模查询数据中提取重复出现的无关修饰词，识别浪费消费模式
+- [[SearchQueryOptimizationSystem]]（SQOS）：搜索查询优化系统评分——从多因素维度评分查询-广告-着陆页一致性
+- [[MatchTypeOptimization]]：匹配类型优化——精确变体影响分析、广泛匹配扩展审计、短语匹配边界测试
+- [[WasteIdentification]]：浪费识别——按花费加权的无关性评分、零转化查询标记、高 CPC 低价值查询隔离
 
 ## Key Entities
-- [[JohnWilliams]]：Agent 作者，@itallstartedwithaidea，专注于搜索词分析和付费媒体优化
-- [[GoogleAdsMCP]]：Google Ads MCP 工具集，提供搜索词报告 API 和负关键词部署能力
+- [[TheAgency]]（The Agency）：该 Agent 所属的专业多 Agent 团队框架，隶属 Paid Media 部门
+- [[PaidMediaAuditor]]：同部门审计 Agent——评估账户整体健康度，为 Search Query Analyst 提供审计后的优先优化方向
+- [[PaidMediaPPCStrategist]]：同部门策略 Agent——基于 Search Query Analyst 发现的查询机会，制定竞价策略和预算分配
+- [[GoogleAds]]：主要工作平台——通过 Google Ads MCP 工具拉取实时搜索词报告和推送负面关键词变更
+- [[JohnWilliams]]（@itallstartedwithaidea）：该 Agent 的创建者和作者
 
 ## Connections
-- [[PaidMediaAuditor]] ← part_of ← [[TheAgency]]（The Agency 的付费媒体审计 Agent 之一）
-- [[PaidMediaPPCStrategist]] ← related_to ← [[SearchQueryOptimization]]（策略制定依赖查询分析结果）
-- [[PaidMediaProgrammaticBuyer]] ← related_to ← [[IntentClassification]]（程序化投放也需要意图分类）
-- [[PaidMediaCreativeStrategist]] ← related_to ← [[SearchQueryOptimization]]（创意策略需与查询意图对齐）
+- [[PaidMediaAuditor]] ← 审计输入 ← [[PaidMediaSearchQueryAnalyst]]
+- [[PaidMediaSearchQueryAnalyst]] ← 查询机会发现 ← [[PaidMediaPPCStrategist]]
+- [[PaidMediaSearchQueryAnalyst]] ← 负面关键词部署 ← [[GoogleAds]]
+- [[PaidMediaTrackingSpecialist]] ← 转化数据 ← [[PaidMediaSearchQueryAnalyst]]
 
 ## Contradictions
-- 暂无已知冲突内容
+- 与 [[PaidMediaAuditor]] 可能的边界模糊：
+  - 冲突点：PaidMediaAuditor 覆盖关键词定向（关键词质量分/出价/匹配类型），与 Search Query Analyst 的 Match Type Optimization 存在功能重叠
+  - 当前观点：Search Query Analyst 专注查询层面的微观优化（具体搜索词粒度）；PaidMediaAuditor 专注账户整体架构层面的宏观审计（关键词结构/策略层面）
+  - 对方观点：PaidMediaAuditor 在审计报告中覆盖关键词效率，可能包含搜索词优化的初步建议
+  - 协调方案：两者协作流程为 Audit → Query Analysis → Strategy，三者各司其职无冲突
diff --git a/wiki/sources/paid-media-tracking-specialist.md b/wiki/sources/paid-media-tracking-specialist.md
index 32391a2a..5110c4d7 100644
--- a/wiki/sources/paid-media-tracking-specialist.md
+++ b/wiki/sources/paid-media-tracking-specialist.md
@@ -1,55 +1,52 @@
 ---
-title: "Paid Media Tracking & Measurement Specialist Agent"
+title: "Tracking & Measurement Specialist"
 type: source
-tags: ["paid-media", "agent", "tracking", "measurement", "GTM", "GA4"]
-date: 2026-04-20
-last_updated: 2026-04-25
-sources: []
+tags: []
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/paid-media/paid-media-tracking-specialist.md]]
+- [[Agent/agency-agents/paid-media/paid-media-tracking-specialist.md]]
 
 ## Summary（用中文描述）
-- **核心主题**：付费媒体追踪与归因专家 Agent——负责构建跨平台（GTM、GA4、Google Ads、Meta CAPI、LinkedIn Insight Tag）的事件追踪架构，确保每一次转化都被正确计数，每一分广告投入都可衡量。
-- **问题域**：标签容器臃肿、跨平台重复计数、归因模型失准、隐私合规（GDPR/CCPA/Consent Mode v2）挑战、UA→GA4/客户端→服务端迁移。
-- **方法/机制**：GTM 容器架构设计、dataLayer 规范、事件去重（event_id 匹配）、增强转化（hashed PII）、服务端容器部署、数据驱动归因模型。
-- **结论/价值**：精准追踪是付费媒体优化的数据根基——错误的数据不仅浪费，更会误导出价算法往错误方向优化。
+- 核心主题：付费媒体转化追踪与归因测量体系的构建与维护
+- 问题域：跨平台（Google Ads、Meta、TikTok、LinkedIn 等）追踪不一致、归因偏差、隐私合规挑战
+- 方法/机制：通过 GTM 容器架构、GA4 事件设计、Server-Side Tagging、CAPI 去重、Consent Mode v2 实现精准归因
+- 结论/价值：数据质量是付费媒体优化的根基——追踪错误比无追踪更具误导性，会导致算法持续优化错误目标
 
 ## Key Claims（用中文描述）
-- 精准追踪工程师构建的数据基础，使所有付费媒体优化成为可能。
-- 错误追踪比无追踪更糟糕——一次错误计数的转化，不仅浪费数据，更会主动误导出价算法向错误结果优化。
-- 追踪 bug 会无声叠加——5% 的数据差异若不修复，明天就变成一个方向错误的出价算法。
-- 重大营销活动前，必须先建立测量计划（Measurement Plan）。
+- GTM 容器架构优化能实现 99.5%+ 的标签触发成功率
+- GA4 与广告平台间的转化数据差异应控制在 3% 以内
+- Meta CAPI 通过 event_id 机制实现 Pixel 与服务端事件去重，避免双重计数
+- Enhanced Conversion 的哈希用户数据匹配率应达到 70% 以上
+- Consent Mode 覆盖率应达到 100%，确保所有标签正确响应用户同意信号
+- 标签实现对页面加载的影响应控制在 200ms 以内
 
 ## Key Quotes
-> "Bad tracking is worse than no tracking — a miscounted conversion doesn't just waste data, it actively misleads bidding algorithms into optimizing for the wrong outcomes." — 核心原则
-
-> "Always cross-reference platform-reported conversions against the actual API data. Tracking bugs compound silently — a 5% discrepancy today becomes a misdirected bidding algorithm tomorrow." — 调试方法论
-
-> "If it's not tracked correctly, it didn't happen." — Agent 风格标语
+> "Bad tracking is worse than no tracking — a miscounted conversion doesn't just waste data, it actively misleads bidding algorithms into optimizing for the wrong outcomes." — 核心观点：错误的追踪数据比没有数据更具破坏性
 
 ## Key Concepts
-- [[GoogleTagManager]]：GTM 容器架构、工作区管理、触发器/变量设计、自定义 HTML 标签、Consent Mode 实现、标签序列与触发优先级。
-- [[GoogleAnalytics4]]：事件分类体系设计、自定义维度/指标、增强衡量配置、电商 dataLayer 实现（view_item/add_to_cart/begin_checkout/purchase）、跨域追踪。
-- [[MetaConversionsAPI]]：CAPI 服务端配置、事件去重（event_id 匹配）、域名验证、聚合事件测量配置——确保 Pixel 浏览器事件与 CAPI 服务端事件不重复计数。
-- [[ServerSideTagging]]：GTM 服务端容器部署、第一方数据收集、Cookie 管理、服务端富化。
-- [[ConversionTracking]]：Google Ads 转化操作（主转化/次转化）、增强转化（网页和线索）、离线转化 API 导入、转化价值规则、转化操作集。
-- [[AttributionModeling]]：数据驱动归因模型配置、跨渠道归因分析、增量测试设计、营销组合建模输入。
-- [[ConsentModeV2]]：Consent Mode v2 实现、GDPR/CCPA 合规、Cookie Banner 集成、数据保留设置。
-- [[DataLayerArchitecture]]：复杂电商和线索生成网站的 dataLayer 架构设计规范。
+- [[GTM|Google Tag Manager (GTM)]]：容器架构、工作区管理、触发器/变量设计、自定义 HTML 标签、Consent Mode 实现、标签序列与触发优先级
+- [[GA4|Google Analytics 4]]：事件分类设计、自定义维度/指标、增强衡量配置、电子商务 dataLayer 实现（view_item、add_to_cart、begin_checkout、purchase）、跨域追踪
+- [[Meta CAPI|Meta Conversions API (CAPI)]]：服务端 Pixel 设置、event_id 机制实现浏览器 Pixel 与 CAPI 事件去重、域名验证、聚合事件测量配置
+- [[Consent Mode v2]]：GDPR/CCPA 合规、Cookie 横幅集成、数据保留设置
+- [[Enhanced Conversions]]：网页端和线索增强转化、离线转化通过 API 导入、转化价值规则、转化操作集
+- [[Attribution Modeling]]：数据驱动归因模型配置、跨渠道归因分析、增量测试设计、营销组合建模输入
+- [[Server-Side Tagging]]：GTM 服务端容器部署、第一方数据收集、Cookie 管理、服务端数据富化
 
 ## Key Entities
-- [[JohnWilliams]]：Agent 作者（@itallstartedwithaidea）
-- [[TheAgency]]：Agent 所属的多 Agent 协作框架
+- [[John Williams]]（@itallstartedwithaidea）：作者，付费媒体追踪专家
+- [[Google Tag Manager]]：核心标签管理工具
+- [[Google Analytics 4]]：主要分析平台
+- [[Meta Conversions API]]：Facebook/Meta 广告追踪服务端 API
+- [[LinkedIn Insight Tag]]：LinkedIn 广告追踪工具
+- [[TikTok Pixel]]：TikTok 广告追踪工具
 
 ## Connections
-- [[PaidMediaAdCreativeStrategist]] ← complementary ← [[PaidMediaTrackingSpecialist]]
-- [[PaidMediaPaidSocialStrategist]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（Social 广告依赖精准追踪）
-- [[PaidMediaPPCStrategist]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（PPC 依赖转化追踪数据）
-- [[PaidMediaProgrammaticBuyer]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（程序化投放依赖归因模型）
-- [[PaidMediaSearchQueryAnalyst]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（搜索词分析依赖转化数据）
-- [[PaidMediaAuditor]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（审计依赖追踪准确性验证）
+- [[Paid Media Ad Creative Strategist Agent]] ← supports ← [[Paid Media Tracking & Measurement Specialist Agent]]
+- [[Paid Media Search Query Analyst Agent]] ← depends_on ← [[Paid Media Tracking & Measurement Specialist Agent]]（依赖准确的追踪数据做查询分析）
+- [[Paid Media PPC Campaign Strategist Agent]] ← depends_on ← [[Paid Media Tracking & Measurement Specialist Agent]]（依赖转化数据优化出价策略）
+- [[Paid Media Auditor Agent]] ← uses_data_from ← [[Paid Media Tracking & Measurement Specialist Agent]]（审计时核查追踪准确性）
 
 ## Contradictions
-- （暂无发现与其他页面的内容冲突）
+- 暂无已知冲突内容
diff --git a/wiki/sources/phase-0-discovery.md b/wiki/sources/phase-0-discovery.md
new file mode 100644
index 00000000..ed5be2a3
--- /dev/null
+++ b/wiki/sources/phase-0-discovery.md
@@ -0,0 +1,50 @@
+---
+title: "Phase 0 Playbook — Intelligence & Discovery"
+type: source
+tags: [agent, strategy, playbook, intelligence, discovery]
+date: 2026-05-01
+sources: []
+last_updated: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/playbooks/phase-0-discovery.md]]
+
+## Summary（用中文描述）
+- 核心主题：项目启动前的 Intelligence & Discovery 阶段（Phase 0），通过 6 个专项 Agent 并行探索，验证机会再投入资源。
+- 问题域：市场机会验证、用户需求挖掘、合规风险评估、数据可用性、技术可行性五大维度。
+- 方法/机制：采用 Wave 1 + Wave 2 并行 Agent 激活 → Day 5-7 汇聚点（Convergence Point）→ Executive Summary Generator 合成 → GO/NO-GO/PIVOT 决策门的结构化流程。
+- 结论/价值：确保在正式建设（Phase 1）之前充分理解问题、市场与监管全景，避免资源浪费。
+
+## Key Claims（用中文描述）
+- 在投入资源前，必须通过 Phase 0 验证机会（市场、用户、合规、数据、技术五个维度）。
+- 通过 Wave 1（趋势研究、反馈综合、UX 研究）与 Wave 2（数据分析、法律合规、技术评估）并行激活，5-7 天内完成全面探索。
+- 6 个 Agent 报告汇聚后，由 Executive Summary Generator 生成不超过 500 词的 SCQA 格式执行摘要，并给出 GO/NO-GO/PIVOT 决策。
+- 6 项质量门标准（Market opportunity、TAM、Pain points、合规、指标数据、技术栈）全部通过方可进入 Phase 1。
+
+## Key Quotes
+> "Validate the opportunity before committing resources. No building until the problem, market, and regulatory landscape are understood." — Phase 0 核心原则
+
+> "Phase 0 is complete when the Executive Summary Generator delivers a GO decision with supporting evidence from all six discovery agents." — Phase 0 完成标准
+
+## Key Concepts
+- [[Convergence Point（汇聚点）]]：所有探索 Agent 在 Day 5-7 交付报告，由 Executive Summary Generator 统一合成的决策节点。
+- [[Quality Gate（质量门）]]：6 项量化验收标准，逐一核查后方可通过进入下一阶段。
+- [[Wave 1 & Wave 2]]：两波并行 Agent 激活序列，Wave 1 关注外部（市场/用户），Wave 2 关注内部（数据/合规/技术）。
+- [[Executive Summary Generator]]：执行摘要生成器，将多份报告压缩为 ≤500 词 SCQA 格式，并给出 GO/NO-GO/PIVOT 决策。
+- [[Phase Handoff]]：阶段间交接包，包含所有发现文档、约束条件与优先级需求。
+
+## Key Entities
+- [[Trend Researcher]]：市场情报 Agent，负责竞争格局、市场规模（TAM/SAM/SOM）、趋势预测。
+- [[Feedback Synthesizer]]：用户需求 Agent，负责多渠道反馈收集、痛点识别（RICE 评分）、流失风险指标。
+- [[UX Researcher]]：用户体验 Agent，负责用户访谈计划、Persona 开发、用户旅程地图。
+- [[Analytics Reporter]]：数据分析 Agent，负责数据源审计、信号识别、基线指标建立。
+- [[Legal Compliance Checker]]：法律合规 Agent，负责监管框架映射（GDPR/CCPA/HIPANA）、合规风险评级。
+- [[Tool Evaluator]]：技术评估 Agent，负责技术栈分析、Build vs. Buy 决策、开源 vs. 商业评估。
+
+## Connections
+- [[Phase 1 Strategy]] ← precedes — Phase 0 验证通过后，进入 Phase 1 Strategy & Architecture 阶段
+- [[phase-2-foundation.md]] ← extends — Phase 1 之后进入 Foundation & Scaffolding 阶段
+
+## Contradictions
+- （暂无冲突 — Phase 0 与其他 Phase 页面（Phase 1-6）形成线性递进关系，无矛盾内容）
diff --git a/wiki/sources/phase-1-strategy.md b/wiki/sources/phase-1-strategy.md
new file mode 100644
index 00000000..0649660f
--- /dev/null
+++ b/wiki/sources/phase-1-strategy.md
@@ -0,0 +1,71 @@
+---
+title: "Phase 1 Playbook — Strategy & Architecture"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/playbooks/phase-1-strategy.md]]
+
+## Summary（用中文描述）
+- 核心主题：NEXUS 多智能体团队 Phase 1（战略与架构阶段）的完整执行手册，定义项目启动前的所有前期准备工作
+- 问题域：项目立项后的战略对齐、品牌定位、财务规划、技术架构和任务优先级划分
+- 方法/机制：采用三步式 Agent 激活序列（战略框架 → 技术架构 → 优先级排序），最后由双 Gate Keeper 双签放行进入 Phase 2
+- 结论/价值：确保每一个架构决策有文档记录、每一个功能有优先级、每一笔预算有出处，8 个 Agent 并行协作，5-10 天完成前期准备
+
+## Key Claims（用中文描述）
+- Studio Producer 负责战略投资组合对齐，确保项目定位契合组织战略目标，3 天内交付战略组合计划
+- Brand Guardian 在获得 Phase 0 UX Research 后，3 天内建立完整的品牌标识系统（视觉、声音、价值观）
+- Finance Tracker 基于战略计划和 Phase 0 技术栈评估，2 天内生成包含 ROI 盈亏平衡分析的完整财务计划
+- UX Architect 和 Backend Architect 在前两步输出就绪后并行激活，分别负责前端设计系统和后端系统架构，均需 4 天
+- Senior Project Manager 汇总所有 Phase 0 文档和架构规格，3 天内将需求规范转换为可执行任务列表，每项任务有明确验收标准
+- Sprint Prioritizer 以前述所有输出为输入，使用 RICE 评分 + MoSCoW 分类，2 天内输出优先级排序后的 Sprint 计划
+- Phase 1 放行必须由 Studio Producer（战略）和 Reality Checker（技术）双签，缺一不可
+
+## Key Quotes
+> "Define what we're building, how it's structured, and what success looks like — before writing a single line of code." — Phase 1 核心理念
+> "Every architectural decision is documented. Every feature is prioritized. Every dollar is accounted for." — Phase 1 交付承诺
+
+## Key Concepts
+- [[RICE Scoring]]：Reach × Impact × Confidence ÷ Effort，用于功能优先级排序
+- [[MoSCoW Classification]]：Must / Should / Could / Won't 四级功能分类法
+- [[Quality Gate Checklist]]：阶段性放行检查清单，需双签（战略 + 技术）才可进入下一阶段
+- [[Work Breakdown Structure]]：任务分解结构，将复杂项目拆解为可独立估算和执行的原子任务
+- [[Dual Sign-Off]]：Studio Producer（战略视角）+ Reality Checker（技术视角）双重审批机制
+
+## Key Entities
+- [[Studio Producer]]：战略层面 Gate Keeper，负责投资组合对齐和 ROI 目标确认
+- [[Reality Checker]]：技术层面 Gate Keeper，负责验证架构完整性和实现路径可行性
+- [[Brand Guardian]]：品牌标识 Agent，负责视觉系统和品牌声音的定义
+- [[Finance Tracker]]：财务规划 Agent，负责预算分解和 ROI 模型
+- [[UX Architect]]：前端架构 Agent，负责 CSS 设计系统、布局框架和可访问性基础
+- [[Backend Architect]]：后端架构 Agent，负责系统架构、数据库、API 和安全设计
+- [[AI Engineer]]：ML 架构 Agent（有条件激活，仅当项目含 AI/ML 功能时启动）
+- [[Senior Project Manager]]：任务规划 Agent，负责将规范转换为任务列表
+- [[Sprint Prioritizer]]：优先级排序 Agent，负责 RICE 评分和 Sprint 规划
+
+## Connections
+- [[Phase 2 Foundation]] ← extends ← [[Phase 1 Strategy]]
+- [[Phase 0 Handoff]] ← depends_on ← [[Phase 1 Strategy]]
+- [[Agent Activation Prompts]] ← provides_templates ← [[Phase 1 Strategy]]
+- [[Nexus Strategy]] ← governs ← [[Phase 1 Strategy]]
+- [[Studio Producer]] ← activates ← [[Phase 1 Strategy]]
+- [[Reality Checker]] ← validates ← [[Phase 1 Strategy]]
+- [[Handoff Templates]] ← consumed_by ← [[Phase 1 Strategy]]
+
+## Contradictions
+- 与 [[Phase 3 Build]] 冲突：
+  - 冲突点：Phase 3 Build 应在 Phase 1 Strategy 完全批准后方可启动，但 Phase 3 文档（若存在）可能描述了更激进的时间线
+  - 当前观点：Phase 1 Strategy 明确规定双签放行前不得进入 Phase 2，更不能跳到 Phase 3
+  - 对方观点：快速迭代场景下可能需要边设计边开发，Phase 1 和 Phase 2 可部分重叠
+
+## Phase 1 → Phase 2 Handoff Package 清单
+1. Strategic Portfolio Plan（Studio Producer）
+2. Brand Identity System（Brand Guardian）
+3. Financial Plan（Finance Tracker）
+4. CSS Design System + UX Architecture（UX Architect）
+5. System Architecture Specification（Backend Architect）
+6. ML System Design（AI Engineer — 有条件）
+7. Comprehensive Task List（Senior Project Manager）
+8. Prioritized Sprint Plan（Sprint Prioritizer）
diff --git a/wiki/sources/phase-2-foundation.md b/wiki/sources/phase-2-foundation.md
new file mode 100644
index 00000000..e2c815d3
--- /dev/null
+++ b/wiki/sources/phase-2-foundation.md
@@ -0,0 +1,63 @@
+---
+title: "Phase 2 Playbook — Foundation & Scaffolding"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/playbooks/phase-2-foundation.md]]
+
+## Summary（用中文描述）
+- 核心主题：NEXUS 框架 Phase 2 执行手册——技术基础设施与运营基础的并行构建阶段
+- 问题域：如何在 Phase 1 架构通过审批后，快速为所有开发 Agent 提供可工作的基础环境
+- 方法/机制：6 个 Agent 双工作流并行（Workstream A 基础设施 + Workstream B 应用框架），双门卫（DevOps Automator + Evidence Collector）联合签发质量门
+- 结论/价值：Phase 2 是整个 NEXUS 流水线的"骨架站立"阶段，产出包含 CI/CD 管道、API 脚手架、设计系统和 Git 协作流程，为 Phase 3 全面开发提供即插即用的基础设施
+
+## Key Claims（用中文描述）
+- 双工作流并行策略使基础设施搭建和应用框架构建同步完成，3 天内交付可用基础
+- DevOps Automator + Evidence Collector 联合双签质量门确保只有通过真实运行验证的产出进入 Phase 3
+- 零基础设施债务——所有 Phase 2 产出必须通过截图证据（CI 管道日志/浏览器截图/主题切换对比/API 健康检查）方可过关
+- Evidence Collector 的 8 项截图证据是 Phase 2 交付的强制验证标准，覆盖从前端渲染到数据库迁移的全链路
+- Design Token（设计令牌）是前端框架和 CSS 系统之间的核心连接点，确保 Brand Guardian 的品牌规范可被 Frontend Developer 无损复用
+
+## Key Quotes
+> "Phase 2 is complete when the skeleton application is running, the CI/CD pipeline is operational, and the Evidence Collector has verified all foundation elements with screenshots." — Phase 2 完成的定义性标准
+> "Dual sign-off required: DevOps Automator (infrastructure) + Evidence Collector (visual)" — 质量门双重签发机制
+> "Build the technical and operational foundation that all subsequent work depends on. Get the skeleton standing before adding muscle." — Phase 2 战略定位
+
+## Key Concepts
+- [[NEXUS-Sprint]]：NEXUS 多 Agent 协作框架中的阶段化执行模型，Phase 2 属于基础设施建设阶段
+- [[Quality-Gate]]：NEXUS 流水线中的质量门控机制，Phase 2 要求 DevOps Automator + Evidence Collector 联合双签
+- [[Evidence-Based-QA]]：以截图证据为验证标准的 QA 方法论，Evidence Collector 在 Phase 2 执行 8 项截图验证
+- [[Design-Tokens]]：CSS 设计系统中颜色/字体/间距等设计决策的变量化表达，实现 Brand Guardian 到 Frontend Developer 的规范无损传递
+- [[Two-Phase-Build]]：Phase 2 特有的先构建应用骨架再分发的两阶段构建策略（第一次 build 产出脚手架，第二次 build 集成 raw 原始文件后 serve）
+- [[Infrastructure-as-Code]]：IaC 模板化环境配置（Terraform/CDK），实现多环境（dev/staging/production）一致性
+- [[Blue-Green-Deployment]]：蓝绿部署策略，CI/CD 管道中的零宕机部署机制
+
+## Key Entities
+- [[DevOps-Automator]]：负责 CI/CD 管道和 IaC 模板，交付 GitHub Actions 流水线（安全扫描/自动化测试/容器化/蓝绿部署/自动回滚）和 docker-compose.yml/Dockerfile，时间线 3 天
+- [[Infrastructure-Maintainer]]：负责云资源供给和监控栈，交付 Prometheus/Grafana 监控面板 + 集中日志聚合 + SSL/TLS 安全加固，时间线 3 天
+- [[Studio-Operations]]：负责流程搭建，交付 Git 工作流文档（分支策略/PR 流程/合并策略）和协作工具配置，时间线 2 天
+- [[Frontend-Developer]]：负责项目脚手架和组件库，交付 React/Vue/Angular 框架 + TypeScript 配置 + 设计系统组件（Button/Input/Card/Layout），时间线 3 天
+- [[Backend-Architect]]：负责数据库和 API 脚手架，交付数据库 Schema 迁移 + Express/FastAPI 框架 + JWT 认证 + RBAC，时间线 4 天
+- [[UX-Architect]]：负责 CSS 系统实现，交付 CSS 自定义属性设计令牌 + 响应式网格布局 + 亮/暗/系统三主题切换，时间线 2 天
+- [[Evidence-Collector]]：Phase 2 的 Gate Keeper，执行 8 项截图验证（CI 日志/桌面端/移动端/主题切换/API 健康检查/数据库迁移/监控面板/组件库渲染），输出带截图证据的质量裁决，时间线 2 天
+- [[Project-Shepherd]]：在 Studio Operations 的输入中提及，负责项目协调和时间线管理
+- [[Brand-Guardian]]：为 Frontend Developer 和 UX Architect 提供品牌身份输入（品牌颜色/字体规范），确保 Design Token 与品牌规范对齐
+
+## Connections
+- [[phase-1-strategy]] ← prerequisite_for ← [[phase-2-foundation]]（Phase 1 架构包审批通过是 Phase 2 启动的前置条件）
+- [[phase-2-foundation]] ← handoff_to ← [[phase-3-build]]（Phase 2 产出的完整脚手架交付给 Phase 3 开发 Agent）
+- [[DevOps-Automator]] ← depends_on ← [[phase-1-strategy]]（DevOps Automator 读取 Backend Architect 的系统架构作为输入）
+- [[Frontend-Developer]] ← depends_on ← [[Brand-Guardian]]（Frontend Developer 接收 Brand Guardian 的品牌身份作为 CSS 设计系统输入）
+- [[UX-Architect]] ← depends_on ← [[Brand-Guardian]]（UX Architect 接收 Brand Guardian 的品牌身份作为 CSS 设计令牌输入）
+- [[DevOps-Automator]] ← parallel_with ← [[Infrastructure-Maintainer]]（Workstream A 并行工作）
+- [[DevOps-Automator]] ← parallel_with ← [[Studio-Operations]]（Workstream A 并行工作）
+- [[Frontend-Developer]] ← parallel_with ← [[Backend-Architect]]（Workstream B 并行工作）
+- [[Frontend-Developer]] ← parallel_with ← [[UX-Architect]]（Workstream B 并行工作）
+- [[Evidence-Collector]] ← gate_keeps ← [[phase-2-foundation]]（Evidence Collector 是 Phase 2 质量门的双签人之一）
+- [[DevOps-Automator]] ← gate_keeps ← [[phase-2-foundation]]（DevOps Automator 是 Phase 2 质量门的双签人之一）
+
+## Contradictions
+- 与 [[scenario-startup-mvp]] 的 Agent 数量：Phase 2 指定 6 个 Agent（DevOps Automator/Infrastructure Maintainer/Studio Operations/Frontend Developer/Backend Architect/UX Architect），而 scenario-startup-mvp 的 Week 1 提到"Sprint Prioritizer + Studio Producer + Evidence Collector"等角色。**协调方向**：Phase 2 的 6 Agent 是基础设施专项 Agent，scenario-startup-mvp 的是全周期角色，两者服务于不同阶段，同步激活是合理的（Evidence Collector 在 Phase 2 是 Gate Keeper，在 scenario-startup-mvp 中是全周期 QA）。
diff --git a/wiki/sources/phase-3-build.md b/wiki/sources/phase-3-build.md
new file mode 100644
index 00000000..83d52e37
--- /dev/null
+++ b/wiki/sources/phase-3-build.md
@@ -0,0 +1,56 @@
+---
+title: "Phase 3 Playbook — Build & Iterate"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/playbooks/phase-3-build.md]]
+
+## Summary（用中文描述）
+- 核心主题：多 Agent 协作下，通过 Dev↔QA 循环实现功能迭代构建的完整流程与质量门控机制
+- 问题域：大型多 Agent 软件项目中，如何在并行开发的同时保证质量、如何管理任务失败与依赖关系、如何组织 sprint 执行
+- 方法/机制：Agents Orchestrator 驱动 Dev↔QA 循环；Agent Assignment Matrix 分配任务；四大并行构建轨道（核心产品/增长营销/质量运营/品牌体验）；三级任务失败处理逻辑；Sprint Planning → Daily Execution → Sprint Review → Retrospective 完整模板
+- 结论/价值：Phase 3 是工作量最密集的阶段，NEXUS 的编排能力在此阶段体现最大价值；通过严格的质量门控（7 项检查清单）确保所有功能通过 QA 后方可进入 Phase 4
+
+## Key Claims（用中文描述）
+- Agents Orchestrator 通过 Dev↔QA 循环管理每个任务，每项任务验证通过后才开始下一项
+- 任务按 RICE 评分排序分配给合适的 Developer Agent，支持最多 3 次修复尝试，3 次失败后升级
+- 四条并行构建轨道可同时运行（Track A/B/C/D），覆盖产品、增长、质量、品牌全维度
+- Sprint Planning → Daily Execution → Sprint Review → Retrospective 构成完整的迭代执行闭环
+- 质量门控通过（7 项检查全部满足）后，Gate Keeper（Agents Orchestrator）放行进入 Phase 4
+
+## Key Quotes
+> "Phase 3 is complete when all sprint tasks pass QA, all API endpoints are validated, performance baselines are met, and no critical bugs remain open." — Phase 3 完成标准
+
+> "The Agents Orchestrator manages every task through this cycle" — Dev↔QA Loop 的核心定位
+
+> "When multiple tasks have no dependencies → Assign to different developer agents simultaneously" — 并行任务管理策略
+
+## Key Concepts
+- [[Dev-QA Loop]]：开发者实现 → QA 验证（截图、功能、品牌）→ 通过则完成，失败则修复，最多 3 次，超过则升级
+- [[RICE Scoring]]：任务优先级评分机制（Sprint Prioritizer 使用），用于排序 sprint backlog
+- [[Parallel Build Tracks]]：四条并行构建轨道（Track A 核心产品 / Track B 增长营销 / Track C 质量运营 / Track D 品牌体验），NEXUS-Full 部署时同时激活
+- [[Quality Gate Checklist]]：7 项质量门控检查清单，由 Gate Keeper 裁决 PASS / CONTINUE / ESCALATE
+- [[Agents Orchestrator]]：贯穿整个 Phase 3 的核心编排者，负责任务分配、QA 循环、失败升级、状态报告
+
+## Key Entities
+- [[Agents Orchestrator]]：Phase 3 的核心编排 Agent，担任 Gate Keeper，驱动所有 Dev↔QA 循环
+- [[Project Shepherd]]：管理 Track B（增长与营销准备），在 Sprint Review 时主持演示
+- [[Studio Producer]]：在系统性失败时介入（ESCALATE 路径）
+- [[Reality Checker]]：Phase 4 入口 Agent，接收 Phase 3 → Phase 4 交接包
+- [[Performance Benchmarker]]：持续进行性能基准测试，验证 P95 < 200ms 等指标
+
+## Connections
+- [[Phase 2 Foundation]] ← precedes ← [[Phase 3 Build]]
+- [[Phase 3 Build]] ← precedes ← [[Phase 4 Hardening]]
+- [[Phase 0 Discovery]] ← foundational ← [[Phase 3 Build]]（提供 backlog 来源）
+- [[Agents Orchestrator]] ← drives ← [[Phase 3 Build]]（核心编排引擎）
+
+## Contradictions
+- 与 [[Phase 4 Hardening]] 的观点冲突：
+  - 冲突点：Phase 3 是否包含性能优化
+  - 当前观点（Phase 3）：性能基准测试在 Track C 持续进行，但 Phase 3 主要关注功能实现
+  - 对方观点（Phase 4）：Phase 4 专门进行 Quality & Hardening，包括性能优化和 bug 修复
+  - 说明：两者实为互补关系，Phase 3 建立基线，Phase 4 加固
diff --git a/wiki/sources/phase-4-hardening.md b/wiki/sources/phase-4-hardening.md
new file mode 100644
index 00000000..8a96bc84
--- /dev/null
+++ b/wiki/sources/phase-4-hardening.md
@@ -0,0 +1,51 @@
+---
+title: "Phase 4 Playbook — Quality & Hardening"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/playbooks/phase-4-hardening.md]]
+
+## Summary（用中文描述）
+- 核心主题：多 Agent 协作的质量验收与生产就绪性审查流程，Phase 4 是整个 NEXUS 开发流程中的最终质量关卡
+- 问题域：如何确保已完成的功能真正达到生产就绪标准，而非仅"基本可用"
+- 方法/机制：Reality Checker 拥有唯一裁决权，通过多维度证据收集（截图、API 回归、性能基准、合规审查）→ 分析聚合 → 最终验收的三阶段流程
+- 结论/价值：默认判定为"NEEDS WORK"，首次通过率极低，2-3 轮迭代属于正常预期；只有提供压倒性证据才能获得 READY 裁决
+
+## Key Claims（用中文描述）
+- Reality Checker 的默认裁定是 NEEDS WORK：生产就绪需要完整用户路径端到端可用、跨设备一致性、负载下性能、安全验证、规格完全合规，首次通过获得 B/B+ 评级属于正常预期
+- Phase 4 由 8 个 Agent 协同完成，分三个阶段：证据收集（4 个 Agent 并行，2 天）→ 分析聚合（3 个 Agent 并行，2 天）→ 最终裁定（Reality Checker，3 天）
+- 最终裁决有三种可能：READY（极少首次通过）、NEEDS WORK（预期结果，返回 Phase 3 修复）、NOT READY（架构级问题，需返回 Phase 1/2）
+- 质量门包含 7 项标准：用户路径完整、跨设备一致性、性能认证（P95<200ms, LCP<2.5s）、安全验证、合规认证、规格完全合规、基础设施就绪
+
+## Key Quotes
+> "The Reality Checker's default verdict is NEEDS WORK." — Reality Checker's 默认立场，强调生产就绪的严苛标准
+> "A B/B+ rating on first pass is normal and expected." — 首次通过率预期管理，降低团队心理压力
+> "Phase 4 is complete when the Reality Checker issues a READY verdict with overwhelming evidence." — READY 的判定标准：压倒性证据
+
+## Key Concepts
+- [[RealityChecker]]：Reality Checker — Phase 4 的唯一裁决权威，负责最终综合测试与生产就绪性判定，裁决选项为 READY / NEEDS WORK / NOT READY
+- [[QualityGate]]：Quality Gate — 由 7 项标准构成的质量门，所有指标必须通过方能进入 Phase 5
+- [[NEXUS]]：NEXUS — Network of EXperts, Unified in Strategy，多 Agent 协作框架，Phase 4 嵌入其整体开发流程
+- [[EvidenceCollector]]：Evidence Collector — 负责全维度视觉证据收集（桌面/平板/手机、亮色/暗色主题、错误状态）的 Agent
+- [[PerformanceBenchmarker]]：Performance Benchmarker — 负责负载测试、Core Web Vitals 测量、数据库性能分析的 Agent
+- [[APITester]]：API Tester — 负责完整 API 回归测试（全部端点、集成测试、边界情况）的 Agent
+- [[LegalComplianceChecker]]：Legal Compliance Checker — 负责隐私合规、安全合规、监管合规、无障碍合规最终审计的 Agent
+- [[InfrastructureMaintainer]]：Infrastructure Maintainer — 负责生产环境验证、监控验证、灾难恢复验证、安全验证的 Agent
+
+## Key Entities
+- [[NEXUS]]：NEXUS 多 Agent 系统中的 Phase 4 执行主体
+- Phase 3 → Phase 4 → Phase 5：开发流程中的相邻阶段，Phase 4 从 Phase 3 获取 Handoff Package，向 Phase 5 交付 READY 裁决
+- Studio Producer：Phase 4 中处理 NOT READY 裁决时需要做决策的角色
+
+## Connections
+- [[Phase3Foundation]] ← handoff ← [[Phase4Hardening]] — Phase 4 的输入来自 Phase 3 的质量交付物
+- [[Phase4Hardening]] ← produces_ready_verdict ← [[Phase5Launch]] — Phase 4 的 READY 裁决触发 Phase 5
+- [[Phase4Hardening]] ← needs_work_returns ← [[Phase3Foundation]] — NEEDS WORK 裁决返回 Phase 3 修复循环
+- [[Phase4Hardening]] ← not_ready_escalates ← [[Phase1Strategy]] — NOT READY 裁决触发 Phase 1/2 架构级重审
+- [[Phase6Operate]] ← requires_ready ← [[Phase5Launch]] ← requires_ready ← [[Phase4Hardening]] — 最终各阶段依赖 READY 裁决
+
+## Contradictions
+- 无明显冲突 — 本文档为流程规范，与其他 Phase 文档一致，共同构成 NEXUS 完整开发流程
diff --git a/wiki/sources/phase-5-launch.md b/wiki/sources/phase-5-launch.md
new file mode 100644
index 00000000..7424ca19
--- /dev/null
+++ b/wiki/sources/phase-5-launch.md
@@ -0,0 +1,68 @@
+---
+title: "Phase 5 Playbook — Launch & Growth"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/playbooks/phase-5-launch.md]]
+
+## Summary（用中文描述）
+- 核心主题：NEXUS 多 Agent 团队 Phase 5（产品发布与增长运营阶段）完整执行手册——2-4 周，12 个 Agent 协同，实现最大市场影响力
+- 问题域：如何在发布日实现所有渠道同时激活、零宕机部署、48+ 小时系统稳定
+- 方法/机制：T-7 预热 → T-0 爆发 → T+1~T+7 监控响应 → T+7~T+14 优化迭代，四阶段递进式发布节奏
+- 结论/价值：Phase 5 完成的标志是产品已部署、系统稳定 48+ 小时、增长渠道激活、反馈循环运转
+
+## Key Claims（用中文描述）
+- Phase 5 的核心目标是在发布日实现所有营销渠道协同发力、工程侧确保零宕机，12 个 Agent 同时激活
+- 发布日 T-7 预热周：内容/营销/技术三轨并行准备（Content Creator × Social Media Strategist × Growth Hacker × DevOps Automator）
+- 发布日 T-0：DevOps Automator 负责蓝绿部署、Infrastructure Maintainer 监控 10 倍流量扩展、社交媒体 Agent 同步激活
+- 发布后 T+1~T+7：每日晨/午/晚三波段运营节奏，Analytics Reporter + Feedback Synthesizer + Growth Hacker 每日报告
+- 发布后 T+7~T+14：Growth Hacker 基于首周数据优化转化漏斗、规模化有效渠道、Experiment Tracker 启动 A/B 测试
+- 质量门包含 7 项标准：零宕机部署、48 小时无 P0/P1、系统监控、用户获取渠道激活、反馈循环运转、干系人通报、支持团队就绪
+- 质量门由 Studio Producer（战略）+ Analytics Reporter（数据）双签，决策为 STABLE / CRITICAL / ROLLBACK
+
+## Key Quotes
+> "Coordinate go-to-market execution across all channels simultaneously. Maximum impact at launch." — Phase 5 的核心目标：全渠道同步激活
+> "A B/B+ rating on first pass is normal and expected." — 快速迭代心态：预期 2-3 轮迭代
+> "Phase 5 is complete when the product is deployed, systems are stable for 48+ hours, growth channels are active, and the feedback loop is operational." — Phase 5 完成标准
+
+## Key Concepts
+- [[BlueGreenDeployment]]：蓝绿部署 — 两套等价生产环境（蓝/绿），新版本在绿环境验证后通过负载均衡器切换流量，实现零停机发布；Phase 5 中 DevOps Automator 负责执行
+- [[KFactor]]：K-Factor（病毒系数）— 衡量产品病毒式传播能力的指标，K > 1 表示每个用户带来超过 1 个新用户；Phase 5 中 Growth Hacker 负责基于 K-factor 数据优化病毒机制
+- [[ViralLoop]]：病毒式增长循环 — 用户通过分享/推荐行为自发引入新用户的增长飞轮；Phase 5 中 Growth Hacker 通过 referral codes 和 sharing incentives 激活 ViralLoop
+- [[QualityGate]]：质量门 — Phase 5 包含 7 项质量门标准，双签机制确保战略与数据双视角验证
+- [[FeatureFlag]]：功能开关 — Phase 5 中 DevOps Automator 配置 gradual rollout，优先全量部署前在小比例流量验证
+- [[AutoScaling]]：自动扩展 — Infrastructure Maintainer 配置 10 倍预期流量扩展能力，应对发布日流量高峰
+
+## Key Entities
+- [[StudioProducer]]：Studio Producer — NEXUS 项目的总制作人，Phase 5 质量门的战略视角双签人，负责 STABLE/CRITICAL/ROLLBACK 决策
+- [[AnalyticsReporter]]：Analytics Reporter — 数据分析 Agent，Phase 5 质量门的数据视角双签人，负责实时指标仪表盘、每小时流量报告、渠道归因追踪
+- [[DevOpsAutomator]]：DevOps Automator — 负责蓝绿部署、DevOps 流水线、Feature Flag 配置的工程 Agent
+- [[InfrastructureMaintainer]]：Infrastructure Maintainer — 负责 10 倍流量扩展、监控告警、灾难恢复的系统工程 Agent
+- [[GrowthHacker]]：Growth Hacker — 负责病毒机制、K-factor 追踪、增长实验的营销 Agent
+- [[ContentCreator]]：Content Creator — 负责最终化所有发布内容的营销 Agent
+- [[SocialMediaStrategist]]：Social Media Strategist — 负责跨平台营销资源定稿的 Agent
+- [[SupportResponder]]：Support Responder — 负责处理用户咨询、文档问题、上报工程问题的支持 Agent
+- [[FeedbackSynthesizer]]：Feedback Synthesizer — 负责监控、分类、优先排序用户反馈的 Agent
+- [[ExperimentTracker]]：Experiment Tracker — 负责 Launch A/B 测试结果的追踪 Agent
+- [[ProjectShepherd]]：Project Shepherd — 负责发布日清单分发、跨 Agent 协调的 PM Agent
+- [[TwitterEngager]]：Twitter Engager — 负责发布日 Twitter 线程发布的社交媒体 Agent
+- [[RedditCommunityBuilder]]：Reddit Community Builder — 负责 Reddit 社区真实发布的社交媒体 Agent
+- [[ExecutiveSummaryGenerator]]：Executive Summary Generator — 负责每日干系人简报生成的 Agent
+
+## Connections
+- [[Phase4Hardening]] ← handoff ← [[Phase5Launch]] — Phase 4 的 READY 裁决触发 Phase 5，是 Phase 5 的前置依赖
+- [[Phase5Launch]] ← produces_stable ← [[Phase6Operate]] — Phase 5 STABLE 裁决触发 Phase 6 持续运营
+- [[Phase5Launch]] ← rollback ← [[Phase4Hardening]] — ROLLBACK 决策将触发 Phase 4 修复循环
+- [[DevOpsAutomator]] ← deploys ← [[Phase5Launch]] — DevOps Automator 执行 Phase 5 的部署阶段
+- [[InfrastructureMaintainer]] ← monitors ← [[Phase5Launch]] — Infrastructure Maintainer 负责 Phase 5 期间的系统监控
+- [[StudioProducer]] ← gate_keeps ← [[Phase5Launch]] — Studio Producer 作为质量门双签人之一
+- [[AnalyticsReporter]] ← reports ← [[Phase5Launch]] — Analytics Reporter 提供质量门数据视角验证
+
+## Contradictions
+- 与 [[scenario-startup-mvp]] 冲突：
+  - 冲突点：发布节奏的激进程度 — Phase 5 的 T-7~T+14 框架假设有完整的营销团队（12 个 Agent）和 2-4 周发布周期；scenario-startup-mvp 的 Day 6 即需验证产品市场契合度（PMF）并启动增长
+  - 当前观点（Phase 5）：系统化分阶段发布（预热→爆发→监控→优化），质量门确保稳定后进入 Phase 6
+  - 对方观点（scenario-startup-mvp）：快速迭代模式，PMF 验证优先于系统化质量门，允许在不稳定状态下快速验证市场反应
diff --git a/wiki/sources/phase-6-operate.md b/wiki/sources/phase-6-operate.md
new file mode 100644
index 00000000..2a2d2c08
--- /dev/null
+++ b/wiki/sources/phase-6-operate.md
@@ -0,0 +1,73 @@
+---
+title: "Phase 6 Playbook — Operate & Evolve"
+type: source
+tags: []
+date: 2026-04-29
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/playbooks/phase-6-operate]]
+
+## Summary（用中文描述）
+- 核心主题：产品上线后的持续运营与演进框架，定义多频次运营节拍、持续改进闭环、应急响应协议和战略进化流程。
+- 问题域：产品已上线（Phase 5 结束），如何维持高质量运营并实现持续增长与优化。
+- 方法/机制：通过分层运营节拍（Continuous / Daily / Weekly / Bi-Weekly / Monthly / Quarterly）分配 Agent 职责；建立 Measure → Analyze → Plan → Build → Validate → Deploy 六步持续改进闭环；P0–P3 四级应急响应机制；季度战略评审驱动产品演进。
+- 结论/价值：Phase 6 无结束日期，只要产品在市场一天就持续运行；新功能通过压缩的 NEXUS 循环（7步）快速迭代。
+
+## Key Claims（用中文描述）
+- Studio Producer 作为治理核心，通过分层节拍协调 12+ Agent 的持续运营活动。
+- 持续改进闭环（Measure → Deploy）每季度推动流程效率提升 20%。
+- P0 事故需即时响应（MTTR < 30 分钟），P3 纳入下个 Sprint 处理。
+- 月度增长评审整合渠道表现、实验结果、留存分析和增长路线图更新。
+- 季度战略评审从市场定位、产品策略、增长策略和组织健康四个维度评估产品方向。
+
+## Key Quotes
+> "Phase 6 has no end date. It runs as long as the product is in market, with continuous improvement cycles driving the product forward." — Phase 6 运营哲学
+
+> "Preparation beats heroics." — 应急响应核心原则（与 Incident Response Commander Agent 共享理念）
+
+## Key Concepts
+- [[Continuous Improvement Loop]]：Measure → Analyze → Plan → Build → Validate → Deploy 的六步持续改进闭环，每季度推动流程效率提升 20%。
+- [[Operational Cadence]]：分层运营节拍——Continuous（常驻）、Daily、Weekly、Bi-Weekly、Monthly、Quarterly，将 Agent 职责与活动频率对齐。
+- [[Incident Response Protocol]]：P0–P3 四级事故分级与对应响应团队、响应时间和决策权限的结构化应急体系。
+- [[NEXUS Sprint]]：Phase 6 中新功能开发的压缩生命周期——从 Backlog 选择到用户反馈收集的 7 步快速迭代循环。
+- [[Growth Operations]]：以 Growth Hacker 为核心，整合渠道分析、实验追踪、留存分析和增长路线图的月度增长评审。
+- [[Financial Operations]]：以 Finance Tracker 为核心，覆盖收入分析、成本分析、单位经济指标和预测的月度财务评审。
+- [[Compliance Operations]]：以 Legal Compliance Checker 为核心，覆盖监管跟踪、隐私合规、安全合规和审计准备的月度合规评审。
+- [[Quarterly Strategic Review]]：以 Studio Producer 为核心，从市场定位、产品策略、增长策略和组织健康四个维度进行季度战略评审。
+
+## Key Entities
+- [[Studio Producer]]：Phase 6 治理核心，协调所有运营节拍，主持季度战略评审，P0 事故最终决策者。
+- [[Infrastructure Maintainer]]：负责系统正常运行时间（99.9%）和性能安全，SLA 要求 MTTR < 30 分钟。
+- [[Support Responder]]：负责客户支持与问题解决，首次响应 SLA < 4 小时。
+- [[DevOps Automator]]：负责部署流水线和热修复，支持每日多次部署能力。
+- [[Analytics Reporter]]：负责 KPI 仪表板更新，每日快照和每周性能分析。
+- [[Feedback Synthesizer]]：负责用户反馈综合，周会和双周深度分析。
+- [[Sprint Prioritizer]]：负责待办列表梳理和 Sprint 规划。
+- [[Growth Hacker]]：负责增长渠道优化，主持月度增长评审。
+- [[Project Shepherd]]：跨团队协调，P1 事故决策权限。
+- [[Experiment Tracker]]：负责 A/B 测试分析与实验结果总结。
+- [[Content Creator]]：负责内容日历执行和发布内容报告。
+- [[Executive Summary Generator]]：负责 C-suite 月度报告。
+- [[Finance Tracker]]：负责月度财务报告和单位经济分析。
+- [[Legal Compliance Checker]]：负责月度监管合规检查。
+- [[Trend Researcher]]：负责月度市场情报更新。
+- [[Brand Guardian]]：负责月度品牌一致性审计。
+- [[Workflow Optimizer]]：负责流程效率审计和优化报告。
+- [[Performance Benchmarker]]：负责性能回归测试和季度性能报告。
+- [[Tool Evaluator]]：负责技术栈评估和 Tech Debt 评估。
+- [[Agents Orchestrator]]：P2 事故决策权限，分类并分配响应团队。
+
+## Connections
+- [[phase-5-hardening]] ← extends ← [[phase-6-operate]]（Phase 6 以 Phase 5 的质量门槛为前提）
+- [[phase-3-build]] ← implements ← [[NEXUS Sprint]]（NEXUS Sprint 是 Phase 3 Dev↔QA 循环在 Phase 6 的复用）
+- [[project-management-studio-producer]] ← governs ← [[phase-6-operate]]（Studio Producer Agent 是 Phase 6 的核心治理角色）
+- [[handoff-templates]] ← receives_from ← [[phase-5-hardening]]（Phase 5 Handoff Package 是 Phase 6 的输入）
+- [[scenario-incident-response]] ← implements ← [[Incident Response Protocol]]（场景手册是应急协议的具体执行指南）
+
+## Contradictions
+- 与 [[scenario-incident-response]] 存在细节差异：
+  - 冲突点：事故分级体系名称和粒度不同。
+  - 当前观点：Phase 6 使用 P0–P3 四级，定义明确响应时间和决策权限。
+  - 对方观点：Incident Response Runbook 可能使用 SEV1–SEV4 分级体系。
+  - 建议：以 Phase 6 文档的 P0–P3 为准，Incident Response Runbook 应与 Phase 6 对齐或明确说明两套体系如何共存。
diff --git a/wiki/sources/product-behavioral-nudge-engine.md b/wiki/sources/product-behavioral-nudge-engine.md
index 67bfc679..c6df96f6 100644
--- a/wiki/sources/product-behavioral-nudge-engine.md
+++ b/wiki/sources/product-behavioral-nudge-engine.md
@@ -1,45 +1,56 @@
 ---
 title: "Behavioral Nudge Engine"
 type: source
-tags: [behavioral-psychology, nudge, habit-formation, user-motivation, productivity, gamification]
-date: 2026-04-20
+tags: []
+date: 2026-05-01
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/product/product-behavioral-nudge-engine.md]]
+- [[Agent/agency-agents/product/product-behavioral-nudge-engine.md]]
 
 ## Summary（用中文描述）
-- 核心主题：基于行为心理学原理的智能用户推动引擎，通过个性化交互节奏和激励策略最大化软件用户完成任务的可能性
-- 问题域：用户在面对大量待办任务时产生的认知过载、动力衰减和软件流失问题
-- 方法/机制：通过偏好发现→任务拆解→精准推送→即时庆祝的四阶段工作流，利用默认偏差、微任务冲刺和游戏化机制持续驱动用户行为
-- 结论/价值：有效降低用户认知负荷、提升任务完成率、减少平台流失
+- 核心主题：行为心理学驱动的用户动机引擎，通过智能调整软件交互节奏和风格来最大化用户完成率
+- 问题域：用户因任务堆积导致的流失、通知疲劳、认知过载
+- 方法/机制：微冲刺（Micro-Sprint）、默认偏好利用、时间盒（Pomodoro）、游戏化即时正强化、多渠道推送序列（Nudge Sequence）
+- 结论/价值：把被动仪表盘转化为主动个性化生产力伙伴，提升任务完成率、降低流失、保持高打开率
 
 ## Key Claims（用中文描述）
-- 行为心理学专家通过个性化软件交互节奏和风格，最大化用户动力与成功率
-- 认知负荷管理：把大规模工作流分解为微任务冲刺，防止用户陷入决策瘫痪
-- 推送策略个性化：支持 SMS、Email、应用内横幅等渠道，在最优时间触达用户
-- 游戏化激励机制：通过即时正强化（庆祝微胜利）和可变量奖励循环维持用户参与度
-- 默认偏差利用：提供预填回复、默认选项，降低用户行动摩擦
+- 行为心理学引擎通过将大量任务分解为微小可完成的微冲刺，防止用户陷入任务瘫痪
+- 系统通过用户偏好发现（渠道、频率、语气）实现交互个性化，避免tone-deaf中断
+- 即时正强化（庆祝已完成任务）比强调剩余任务更能维持用户动力
+- 利用默认偏见（如"已起草回复，是否发送？"）大幅降低用户决策摩擦
+- 认知负荷管理是防止平台流失的核心机制
 
 ## Key Quotes
-> "I've drafted a thank-you reply for this 5-star review. Should I send it, or do you want to edit?" — 默认偏差利用示例
-> "Hey! You've got a few quick follow-ups pending. Let's see how many we can knock out in the next 5 mins." — 微任务冲刺推送示例
-> "Nice work! We sent 15 follow-ups, wrote 2 templates, and thanked 5 customers. That's amazing. Want to do another 5 minutes, or call it for now?" — 即时庆祝与温和退出机制
+> "Never send a generic 'You have 14 unread notifications' alert. Always provide a single, actionable, low-friction next step." — 核心交互原则
+> "Nice work! We sent 15 follow-ups, wrote 2 templates, and thanked 5 customers. That's amazing. Want to do another 5 minutes, or call it for now?" — 庆祝与退出引导示例
 
 ## Key Concepts
-- [[Default Bias]]：利用用户对默认选项的偏好（如"我已起草回复，是否直接发送？"）降低行动摩擦
-- [[Cognitive Load Reduction]]：通过拆分任务队列为微小可完成的微冲刺，防止用户认知过载
-- [[Gamification]]：游戏化机制（积分、徽章、成就系统）驱动用户持续参与
-- [[Pomodoro Technique]]：番茄工作法时间盒技术，5分钟冲刺模式适配 ADHD 用户
-- [[Behavioral Psychology]]：行为心理学基础——即时正强化、习惯回路设计
-- [[Momentum Nudge]]：动量推送逻辑——识别用户状态（Overwhelmed/ADHD倾向）触发微冲刺模式
+- [[Default Bias]]：利用用户倾向于接受预设选项的心理，例如"已起草回复，是否发送？"
+- [[Micro-Sprint]]：将大量任务分解为5分钟可完成的小冲刺，降低认知负荷
+- [[Cognitive Load Reduction]]：避免向用户展示全部50条待办，只展示最关键的1条
+- [[Gamification]]：游戏化即时正强化，通过庆祝微胜利维持用户动力
+- [[Time-boxing]]：时间盒技术（如Pomodoro番茄钟），固定时间窗口专注执行
+- [[Nudge Sequence]]：多渠道推送序列（如"Day 1: SMS > Day 3: Email > Day 7: In-App Banner"）
 
 ## Key Entities
-- [[Behavioral Nudge Engine]]：核心代理，扮演世界级个人教练角色，在适当时机推动或庆祝
+- 无特定人物或公司实体
 
 ## Connections
-- [[Product Sprint Prioritizer Agent]] ← supports ← [[Behavioral Nudge Engine]]（任务优先级 → 推送执行）
-- [[Behavioral Nudge Engine]] ← extends ← [[Habit Tracker & Accountability Coach]]（行为习惯追踪）
+- [[Product Manager Agent]] ← 类似的用户价值导向设计
+- [[Habit Tracker & Accountability Coach]] ← 习惯形成与行为激励机制
+- [[Agents Orchestrator]] ← 可作为协调层编排多个行为引擎
 
 ## Contradictions
-- 无已知冲突
+- 暂无已知冲突
+
+## Workflow Process
+1. **Phase 1: Preference Discovery**：用户入职时明确询问交互偏好（语气、频率、渠道）
+2. **Phase 2: Task Deconstruction**：分析用户队列，切分为最小摩擦动作
+3. **Phase 3: The Nudge**：通过首选渠道在最佳时间推送单一可操作项
+4. **Phase 4: The Celebration**：立即用正向反馈强化完成，并提供退出或继续的选项
+
+## Success Metrics
+- **Action Completion Rate**：提升待处理任务的实际完成百分比
+- **User Retention**：降低因软件过载或通知疲劳导致的平台流失
+- **Engagement Health**：通过保持推送始终有价值且不侵扰，维持高打开/点击率
diff --git a/wiki/sources/product-feedback-synthesizer.md b/wiki/sources/product-feedback-synthesizer.md
index 4187360b..8534aad6 100644
--- a/wiki/sources/product-feedback-synthesizer.md
+++ b/wiki/sources/product-feedback-synthesizer.md
@@ -2,7 +2,7 @@
 title: "Product Feedback Synthesizer Agent"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-30
 ---
 
 ## Source File
@@ -15,16 +15,27 @@ date: 2026-04-20
 - **结论/价值**：将海量用户声音蒸馏为可量化的产品决策依据，通过 RICE/MoSCoW/Kano 等框架实现数据驱动的路线图优先级排序，目标 85% 综合反馈产生可衡量决策。
 
 ## Key Claims（用中文描述）
-- **多 Agent 反馈处理**：通过多渠道收集策略（主动/反应/被动/社区/竞争渠道）实现反馈全覆盖，系统化处理从原始数据到可操作洞察的完整流水线。
+- **多渠道反馈收集**：通过主动渠道（应用内调查/邮件/访谈/beta反馈）、反应渠道（工单/评论/社交）、被动渠道（行为分析/热图）、社区渠道（论坛/Discord/Reddit）、竞争渠道（竞品评论/行业论坛）实现反馈全覆盖。
+- **五步处理流水线**：数据摄取（多源API集成）→ 清洗标准化（去重/标准化/验证/质量评分）→ NLP情感分析（情绪检测/评分/置信评估）→ 分类（主题标签/优先级/影响分类）→ 质量保证（人工审查/准确性验证/偏见检查）。
 - **情感与满意度建模**：NLP 情感分析 + NPS/CSAT/CES 评分关联 + 预测建模，实现满意度趋势早期预警（90% 精度检测满意度下降）。
-- **优先级量化框架**：使用 RICE/MoSCoW/Kano 等多标准决策分析框架，将定性反馈转化为可排序的量化优先级。
-- **洞察驱动的商业价值**：目标 85% 综合反馈产生可衡量决策，NPS 提升 10+ 分，80% 反馈驱动功能成功率。
+- **优先级量化框架**：使用 RICE（Reach×Impact×Confidence/Effort）/MoSCoW/Kano 等多标准决策分析框架，将定性反馈转化为可排序的量化优先级。
+- **洞察驱动的商业价值**：目标 85% 综合反馈产生可衡量决策，NPS 提升 10+ 分，80% 反馈驱动功能成功率，95% 报告在一周内被阅读并执行。
+- **多格式交付能力**：Executive Dashboard（实时反馈情感/优先级主题/满意度KPI/ROI追踪）、Product Team Reports（功能请求分析/用户旅程痛点/A-B测试假设）、Customer Success Playbooks（常见问题解决/主动干预/用户教育）。
+- **持续改进机制**：渠道优化（响应质量分析/渠道有效性测量）、方法论迭代（预测精度提升/偏见减少）、流程自动化（效率提升/质量保证规模化）。
 
 ## Key Quotes
 > "Distills a thousand user voices into the five things you need to build next." — Agent 核心价值主张
 
+> "Processing Speed: < 24 hours for critical issues, real-time dashboard updates" — 关键问题处理SLA
+
+> "Theme Accuracy: 90%+ validated by stakeholders with confidence scoring" — 主题识别准确性目标
+
+> "Actionable Insights: 85% of synthesized feedback leads to measurable decisions" — 洞察可行动率目标
+
 ## Key Concepts
 - [[NPS]]：Net Promoter Score，用户推荐意愿度量，与反馈洞察强相关
+- [[CSAT]]：Customer Satisfaction Score，客户满意度评分，反馈质量的核心指标
+- [[CES]]：Customer Effort Score，客户努力度评分，衡量产品易用性
 - [[RICE]]：Feature request prioritization framework（Reach × Impact × Confidence / Effort）
 - [[MoSCoW]]：Must-have / Should-have / Could-have / Won't-have 优先级分类法
 - [[Kano]]：Kano Model，功能满意度与用户愉悦度关系模型
@@ -33,6 +44,9 @@ date: 2026-04-20
 - [[ChurnPrediction]]：基于反馈模式的流失预测与满意度建模
 - [[VoC]]：Voice of Customer，原声客户，verbatim 分析与引语提取
 - [[FeedbackLoop]]：反馈闭环设计与持续改进流程
+- [[ThematicAnalysis]]：主题分析，跨反馈源的模式识别与统计验证
+- [[FeaturePrioritization]]：功能优先级排序，多框架支撑的量化决策
+- [[CompetitiveFeedback]]：竞争反馈，竞品评论挖掘与满意度对比分析
 
 ## Key Entities
 - [[The-Agency]]：本 Agent 所属的多智能体框架，Product 部门专注于产品驱动的分析与管理 Agent
@@ -41,6 +55,8 @@ date: 2026-04-20
 - [[product-sprint-prioritizer]] ← extends ← [[product-feedback-synthesizer]]
 - [[product-trend-researcher]] ← depends_on ← [[product-feedback-synthesizer]]
 - [[product-manager]] ← uses ← [[product-feedback-synthesizer]]
+- [[product-behavioral-nudge-engine]] ← informs ← [[product-feedback-synthesizer]]
+- [[Agents-Orchestrator]] ← orchestrates ← [[product-feedback-synthesizer]]
 
 ## Contradictions
 - 与 [[product-sprint-prioritizer]] 可能存在优先级框架差异：
diff --git a/wiki/sources/product-manager.md b/wiki/sources/product-manager.md
index d6488711..35a163f0 100644
--- a/wiki/sources/product-manager.md
+++ b/wiki/sources/product-manager.md
@@ -1,52 +1,57 @@
 ---
 title: "Product Manager Agent"
 type: source
-tags: []
-date: 2026-04-25
+tags: ["product-management", "agent-personality", "prd", "roadmap", "gtm"]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/product/product-manager.md]]
+- [[Agent/agency-agents/product/product-manager.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Product Manager Agent — 一个具备10年以上产品管理经验的专业AI代理角色定义
-- 问题域：产品生命周期管理（从发现到衡量）、跨职能团队协调、需求优先级决策、利益相关者对齐
-- 方法/机制：基于 Outcome-Driven 的产品方法论、PRD/机会评估/路线图/GTM等标准化交付物、六阶段工作流程
-- 结论/价值：提供一套完整的AI Agent产品经理角色规范，包括身份定义、核心规则、交付模板和工作流程
+- 核心主题：Product Manager（产品经理）Agent 的角色定义、行为准则、技术模板和工作流程。作为一名具有10年以上经验的产品经理，Alex 负责从产品想法到用户影响的全流程管理。
+- 问题域：AI Agent 在产品管理领域的能力边界；如何在 Agent 系统中实现结构化的产品交付流程；PRD、路线图、GTM 等模板的数字化。
+- 方法/机制：六阶段产品工作流（Discovery → Framing → Definition → Delivery → Launch → Measurement）；RICE 优先级评分；OKR 对齐；异步沟通优先。
+- 结论/价值：产品经理 Agent 的核心价值在于消除团队内的信息不对称，保护团队专注度，以结果而非产出驱动决策，并将用户需求、商业目标和工程现实三者统一协调。
 
 ## Key Claims（用中文描述）
-- Product Manager Agent 以 Alex 为身份，具备10年以上B2B SaaS、消费者应用和平台业务的从业经验
-- 产品经理的超能力是在用户需求、业务目标和工程现实三者之间找到对齐路径
-- 所有功能都是假设，发布后才成为实验，成功的产品是那些能measurable改变用户行为的产品
-- 路线图不是承诺，而是一个关于impact最可能发生在哪里的优先赌注清单
+- 产品经理应思考「结果」而非「产出」—— 未被用户使用的产品功能不是胜利，只是带有部署时间戳的浪费。
+- 产品经理的超能力是在用户需求、商业要求和工程现实三者之间保持张力，并找到三者对齐的路径。
+- 每个产品决策都涉及权衡，应将权衡明确化而非隐藏。
+- 对齐不等于共识——不需要一致的同意，只需要每个人都理解决策、背后的推理及各自的执行角色。
+- 惊喜即失败——干系人永远不应被延迟、范围变更或未达指标所惊吓。
 
 ## Key Quotes
-> "Features are hypotheses. Shipped features are experiments. Successful features are the ones that measurably change user behavior. Everything else is a learning." — 核心产品哲学
-> "I will always tell you what we're NOT building and why. That list is as important as the roadmap — maybe more." — 优先级与拒绝的艺术
-> "My job isn't to have all the answers. It's to make sure we're all asking the same questions in the same order." — PM的真正职责
-> "The roadmap isn't a promise. It's a prioritized bet about where impact is most likely." — 路线图的本质
+> "A feature shipped that nobody uses is not a win — it's waste with a deploy timestamp." — 核心产品价值观
+> "I'd recommend we ship v1 without the advanced filter. Here's the reasoning: analytics show 78% of active users complete the core flow without touching filter-like features..." — 权衡决策的典型表达方式
 
 ## Key Concepts
-- [[Outcome-Driven Product Management]]：以可衡量结果而非产出为导向的产品管理方法论
-- [[RICE Prioritization]]：基于 Reach、Impact、Confidence、Effort 四个维度评估功能优先级
-- [[PRD]]：Product Requirements Document — 结构化的产品需求文档模板
-- [[Opportunity Assessment]]：机会评估，在提出解决方案前对商业机会进行结构化分析
-- [[Product Roadmap]]：产品路线图，采用 Now/Next/Later 三层结构
-- [[Go-to-Market Brief]]：产品上市计划，包含目标受众、价值主张、发布清单和成功标准
-- [[Sprint Health Snapshot]]：冲刺健康快照，追踪承诺vs交付、阻塞项和范围变更
-- [[Sprint Ceremonies]]：冲刺 ceremonies — 计划、每日站会、评审、回顾
-- [[North Star Metric]]：北极星指标，最能衡量用户获得价值和业务健康的单一指标
+- [[Product Requirements Document (PRD)]]：结构化的产品需求文档模板，涵盖问题陈述、目标指标、用户故事、解决方案、技术考量、发布计划等八大章节。
+- [[RICE Prioritization Score]]：R × I × C ÷ E 公式，评估需求优先级，综合考虑触达量（Reach）、影响力（Impact）、置信度（Confidence）和工作量（Effort）。
+- [[Go-to-Market (GTM) Brief]]：产品发布计划，包含目标受众、价值主张、发布检查清单和成功标准。
+- [[Sprint Health Snapshot]]：冲刺健康快照，追踪承诺与交付的对比、阻塞项、范围变更和风险。
+- [[Opportunity Assessment]]：机会评估文档，在解决方案讨论前撰写，包含用户证据、商业案例和 RICE 评分。
+- [[Product Roadmap (Now/Next/Later)]]：三层路线图框架，分别对应当前季度承诺、下一步方向和战略性押注。
+- [[Outcome vs. Output]]：结果导向思维——追踪用户行为的实际改变，而非功能是否上线。
+- [[Pre-Mortem]]：事前验尸——假设8周后发布失败，分析失败原因，提前预防。
 
 ## Key Entities
-- [[Alex]]：Product Manager Agent 的角色名，10年以上产品管理经验的AI代理化身
-- [[B2B SaaS]]：产品经理Agent经验覆盖的领域之一
-- [[Consumer Apps]]：产品经理Agent经验覆盖的领域之一
-- [[Platform Businesses]]：产品经理Agent经验覆盖的领域之一
+- Alex：虚构的资深产品经理角色（10年以上经验，横跨B2B SaaS、消费者应用和平台业务），代表该 Agent 的人格化形象。
 
 ## Connections
-- [[Agents Orchestrator]] ← coordinates ← [[Product Manager]]
-- [[Product Feedback Synthesizer Agent]] → feeds insight into → [[Product Manager]]
-- [[Senior Project Manager Agent]] ← overlaps_scope ← [[Product Manager]]（两者都涉及项目交付，但PM更偏产品战略）
+- [[Product Requirements Document (PRD)]] ← is_a_template_of ← [[Product Manager Agent]]
+- [[RICE Prioritization Score]] ← used_by ← [[Product Manager Agent]]
+- [[Opportunity Assessment]] ← used_by ← [[Product Manager Agent]]
+- [[Go-to-Market (GTM) Brief]] ← used_by ← [[Product Manager Agent]]
+- [[Product Roadmap (Now/Next/Later)]] ← maintained_by ← [[Product Manager Agent]]
+- [[Sprint Health Snapshot]] ← owned_by ← [[Product Manager Agent]]
 
 ## Contradictions
-- 无已知冲突
+- 与 [[Senior Project Manager Agent Personality]] 冲突：
+  - 冲突点：项目管理 vs. 产品管理的职责边界——产品经理专注于「做什么和为什么」，项目经理专注于「怎么做和何时做完」。
+  - 当前观点：产品经理主导发现、定义和衡量；由项目经理负责交付执行的时间线管理。
+  - 对方观点：项目交付中两者的职责存在较大重叠，尤其在敏捷团队中 PM 可能兼任项目经理职能。
+- 与 [[Agents Orchestrator]] 冲突：
+  - 冲突点：Agent 生态中各角色 Agent 的编排机制——产品经理 Agent 的决策是否自动传递给执行类 Agent。
+  - 当前观点：产品经理 Agent 输出结构化文档（PRD、路线图），由其他 Agent 或人类读取并执行。
+  - 对方观点：多 Agent 系统中存在自主编排需求，产品经理 Agent 可能需要主动触发下游 Agent。
diff --git a/wiki/sources/product-sprint-prioritizer.md b/wiki/sources/product-sprint-prioritizer.md
index 3a75896d..2fff7b6c 100644
--- a/wiki/sources/product-sprint-prioritizer.md
+++ b/wiki/sources/product-sprint-prioritizer.md
@@ -1,43 +1,58 @@
----
-title: "Product Sprint Prioritizer Agent"
-type: source
-tags: []
-date: 2026-04-25
----
-
-## Source File
-- [[raw/Agent/agency-agents/product/product-sprint-prioritizer.md]]
-
-## Summary（用中文描述）
-- 核心主题：Product Sprint Prioritizer 是一个专注于敏捷冲刺规划和特性优先级排序的 AI Agent，模拟产品经理角色，通过数据驱动的优先级框架最大化团队交付价值。
-- 问题域：冲刺计划、产品待办列表优先级排序、资源分配、干系人对齐、风险评估
-- 方法/机制：RICE 框架、MoSCoW、Kano 模型、价值 vs. 投入矩阵、加权评分；基于历史数据的团队速率分析；跨团队依赖识别与关键路径分析；ROI 建模平衡技术债务与新功能
-- 结论/价值：提供可量化的冲刺成功率指标（承诺故事点交付率 90%+、干系人满意度 4.5/5、时间线偏差 ±10%），实现数据驱动的冲刺规划和持续过程优化
-
-## Key Claims（用中文描述）
-- RICE 框架通过（触及用户数 × 影响度 × 置信度）÷ 投入时间公式，为复杂特性优先级排序提供可量化的决策依据
-- 冲刺前规划阶段通过依赖分析、容量评估、风险识别和干系人审查，将冲刺启动风险降低至 5% 以下
-- 团队速率分析通过 6 个冲刺滚动平均值和趋势分析，预测未来冲刺容量，偏差控制在 15% 以内
-- 看板模型将用户需求分为 Must-Have、Performance、Delighters、Indifferent、Reverse 五类，精准识别满意度驱动因素
-
-## Key Quotes
-> "Sprint Goal Definition: Clear, measurable objective with success criteria" — 冲刺目标定义：清晰、可衡量的目标配合成功标准，是数据驱动冲刺规划的起点
-> "Score: (Reach × Impact × Confidence) ÷ Effort with sensitivity analysis" — RICE 评分公式：触及用户数 × 影响度 × 置信度 ÷ 投入人月，附敏感性分析，确保优先级决策透明可解释
-> "Risk Scoring: Probability × Impact matrix with regular reassessment" — 风险评分：概率 × 影响矩阵，配合定期重新评估，建立主动风险管理机制
-
-## Key Concepts
-- [[RICE Framework]]：优先级评分框架，公式为（触及用户数 × 影响度 × 置信度）÷ 投入人月，用于数据驱动的特性排序
-- [[MoSCoW Method]]：Must-Have / Should-Have / Could-Have / Won't-Have 优先级分类法，确保关键需求优先交付
-- [[Kano Model]]：将产品特性分为 Must-Have（基本期望）、Performance（线性满足）、Delighters（兴奋型）、Indifferent（无差异）、Reverse（反向）五类的用户满意度模型
-- [[Value vs. Effort Matrix]]：价值-投入矩阵，区分"快速成功""战略投入""填充任务""避免陷阱"四象限
-- [[Sprint Planning]]：冲刺规划过程，包括冲刺目标定义、故事选择、任务分解、交付定义和团队承诺
-- [[Team Velocity]]：团队速率，通过历史数据和趋势分析预测冲刺容量，典型偏差控制在 15% 以内
-
-## Key Entities
-- [[Product Manager Agent]]：产品经理 Agent 的另一个专业角色，本 Agent（Sprint Prioritizer）专注于冲刺规划和优先级排序，是产品经理工作流的执行深化
-
-## Connections
-- [[Product Manager Agent]] ← builds_upon ← [[Product Sprint Prioritizer Agent]]（产品经理 Agent 调用本 Agent 进行冲刺规划和优先级排序）
-
-## Contradictions
-- 暂无发现冲突
+---
+title: "Product Sprint Prioritizer Agent"
+type: source
+tags: ["product-management", "agent-personality", "sprint-planning", "prioritization", "agile"]
+date: 2026-05-02
+---
+
+## Source File
+- [[raw/Agent/agency-agents/product/product-sprint-prioritizer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Product Sprint Prioritizer 是一个专注于敏捷冲刺规划和特性优先级排序的 AI Agent，模拟产品经理角色，通过数据驱动的优先级框架最大化团队交付价值。
+- 问题域：冲刺计划制定、产品待办列表优先级排序、资源分配、干系人对齐、风险评估、团队速率优化
+- 方法/机制：RICE 框架、MoSCoW 分类法、Kano 模型、价值 vs. 投入矩阵、加权评分；基于 6 个冲刺滚动平均值的团队速率预测；冲刺前五步准备流程；技术债务与新功能的 ROI 平衡建模；跨团队依赖识别与关键路径分析
+- 结论/价值：提供可量化的冲刺成功率指标（承诺故事点交付率 90%+、干系人满意度 4.5/5、时间线偏差 ±10%），实现数据驱动的冲刺规划和持续过程优化
+
+## Key Claims（用中文描述）
+- RICE 框架通过（触及用户数 × 影响度 × 置信度）÷ 投入时间公式，为复杂特性优先级排序提供可量化的决策依据，每个评分附置信区间和敏感性分析
+- 冲刺前规划阶段通过 Backlog Refinement → 依赖分析 → 容量评估 → 风险识别 → 干系人审查五步流程，将冲刺启动风险降至最低
+- 团队速率分析通过 6 个冲刺滚动平均值和趋势分析（含季节性调整）预测未来冲刺容量，偏差控制在 15% 以内
+- Kano 模型将用户需求分为 Must-Have、Performance、Delighters、Indifferent、Reverse 五类，精准识别满意度驱动因素
+- Sprint Prioritizer 强调实际开发资源和 Sprint 容量约束才是优先级决策的最终边界
+- 技术债务容量占比保持在 20% 以下，通过定期监控防止其侵蚀产品交付能力
+
+## Key Quotes
+> "Score: (Reach × Impact × Confidence) ÷ Effort with sensitivity analysis" — RICE 评分公式：触及用户数 × 影响度 × 置信度 ÷ 投入人月，附敏感性分析，确保优先级决策透明可解释
+> "Sprint Goal Definition: Clear, measurable objective with success criteria" — 冲刺目标定义：清晰、可衡量的目标配合成功标准，是数据驱动冲刺规划的起点
+> "Risk Scoring: Probability × Impact matrix with regular reassessment" — 风险评分：概率 × 影响矩阵，配合定期重新评估，建立主动风险管理机制
+> "Stakeholder Satisfaction: 4.5/5 rating for priority decisions and communication" — 干系人满意度 4.5/5，来自优先级决策和沟通质量的双维度评估
+
+## Key Concepts
+- [[RICE Framework]]：优先级评分框架，公式为（触及用户数 Reach × 影响度 Impact × 置信度 Confidence）÷ 投入 Effort，用于数据驱动的特性排序，评分附敏感性分析
+- [[MoSCoW Method]]：Must-Have / Should-Have / Could-Have / Won't-Have 优先级分类法，确保关键需求优先交付
+- [[Kano Model]]：将产品特性分为 Must-Have（基本期望）、Performance（线性满足）、Delighters（兴奋型）、Indifferent（无差异）、Reverse（反向）五类的用户满意度模型
+- [[Value vs. Effort Matrix]]：价值-投入矩阵，区分"快速成功（High Value/Low Effort）""战略投入（High Value/High Effort）""填充任务（Low Value/Low Effort）""避免陷阱（Low Value/High Effort）"四象限
+- [[Sprint Planning]]：冲刺规划过程，包括冲刺目标定义、故事选择（15% 缓冲）、任务分解、交付定义（Definition of Done）和团队承诺
+- [[Team Velocity]]：团队速率，通过 6 个冲刺滚动平均值和趋势分析预测冲刺容量，偏差 <15%，含季节性调整
+- [[Capacity Planning]]：容量规划，包括团队可用性追踪、会议/培训开销（15-20%）、不确定性缓冲（10-15%）
+- [[Dependency Analysis]]：跨团队依赖识别与关键路径分析，95% 在冲刺开始前解决
+- [[Risk Management]]：风险管理框架——概率 × 影响矩阵、应急计划、早期预警系统、透明上报
+
+## Key Entities
+- [[Product Manager Agent]]：产品经理 Agent 的另一个专业角色，本 Agent（Sprint Prioritizer）专注于冲刺规划和优先级排序，是产品经理工作流的执行深化
+- [[Sprint Prioritizer]]：在 [[workflow-startup-mvp]] 中的实体角色——将 4 周 MVP 项目拆解为有明确交付物和验收标准的冲刺计划
+
+## Connections
+- [[Product Manager Agent]] ← builds_upon ← [[Product Sprint Prioritizer Agent]]（产品经理 Agent 调用本 Agent 进行冲刺规划和优先级排序）
+- [[Sprint Prioritizer]] ← is_instance_of ← [[Product Sprint Prioritizer Agent]]（Sprint Prioritizer 是本 Agent 在 startup-mvp 工作流中的具体角色实例）
+- [[product-feedback-synthesizer]] ← provides_input_to ← [[product-sprint-prioritizer]]（反馈综合结果输入优先级规划）
+- [[workflow-startup-mvp]] ← uses ← [[Sprint Prioritizer]]（Sprint Prioritizer 是 4 周 MVP 流水线的第一步）
+- [[RICE Framework]] ← used_in ← [[Sprint Planning]]（RICE 框架是冲刺规划中的核心优先级评分工具）
+
+## Contradictions
+- 与 [[product-feedback-synthesizer]] 冲突：
+  - 冲突点：Sprint Prioritizer 侧重开发资源约束下的短期迭代优先级，Feedback Synthesizer 侧重基于用户价值的长期路线图优先级。
+  - 当前观点（Sprint Prioritizer）：实际开发资源和 Sprint 容量约束才是优先级决策的最终边界——即使某功能用户价值高，若超出容量或存在强依赖风险，也应延后。
+  - 对方观点（Feedback Synthesizer）：基于 RICE/MoSCoW/Kano 的多框架量化优先级应以用户价值和商业影响为首要维度，资源约束是次要校准因素。
+  - 建议协调：在 Sprint Planning 层面优先使用 Sprint Prioritizer（容量约束优先），在产品路线图规划层面优先使用 Feedback Synthesizer（用户价值优先），两者互补而非替代。
diff --git a/wiki/sources/product-trend-researcher.md b/wiki/sources/product-trend-researcher.md
index cb5fa6d9..2164b31d 100644
--- a/wiki/sources/product-trend-researcher.md
+++ b/wiki/sources/product-trend-researcher.md
@@ -2,7 +2,7 @@
 title: "Product Trend Researcher Agent"
 type: source
 tags: ["the-agency", "product", "market-intelligence", "trend-analysis", "multi-agent"]
-date: 2026-04-25
+date: 2026-04-30
 ---
 
 ## Source File
diff --git a/wiki/sources/project-management-experiment-tracker.md b/wiki/sources/project-management-experiment-tracker.md
index 47868413..e845ddb1 100644
--- a/wiki/sources/project-management-experiment-tracker.md
+++ b/wiki/sources/project-management-experiment-tracker.md
@@ -1,55 +1,49 @@
 ---
 title: "Experiment Tracker Agent Personality"
 type: source
-tags: ["agent", "project-management", "experimentation", "a-b-testing"]
-date: 2026-04-20
+tags: [experiment-tracker, agent, project-management, ab-testing, data-driven, statistical-analysis]
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/project-management/project-management-experiment-tracker.md]]
+- [[Agent/agency-agents/project-management/project-management-experiment-tracker.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 角色定义——Experiment Tracker（实验追踪专家），专注于实验设计、执行追踪与数据驱动决策的专家级项目经理
-- 问题域：产品迭代中的实验管理缺乏系统性、数据驱动决策缺乏科学严谨性、实验成功率低
-- 方法/机制：通过 A/B 测试、多变量实验、假设验证、Portfolio Management、统计功效分析实现科学化实验管理
-- 结论/价值：为 AI Agent 系统提供标准化的实验追踪角色定义，支撑数据驱动的产品迭代决策
+- 核心主题：Experiment Tracker Agent —— 一个专注于实验设计与数据驱动决策的专业项目管理人员智能体
+- 问题域：如何系统化管理 A/B 测试、功能实验、假设验证，确保实验结果的科学可靠性与可操作性
+- 方法/机制：通过统计学方法（95% 置信度、功效分析）设计实验、执行追踪、数据分析，并生成可落地的业务建议
+- 结论/价值：帮助团队以数据驱动的方式做出决策，降低直觉决策风险，提高实验成功率和业务影响力
 
 ## Key Claims（用中文描述）
-- Experiment Tracker 通过严格的统计方法论和实验设计，系统管理 A/B 测试、功能实验和假设验证，确保 95% 置信度的数据驱动决策可靠性
-- Experiment Tracker 通过 Portfolio Management 协调多个并发实验，优化资源配置，每季度交付 15+ 实验，实验成功率达 70%
-- Experiment Tracker 提供实验设计文档模板和实验结果交付模板，标准化实验全生命周期管理流程
-- Experiment Tracker 通过多臂老虎机（Multi-armed Bandits）、贝叶斯分析、因果推断等高级统计技术，实现连续学习和最优实验决策
-- Experiment Tracker 通过机器学习模型 A/B 测试、个性化实验设计和预测建模，实现高级数据科学集成
+- Experiment Tracker Agent 通过系统化实验设计，使 95% 的实验达到统计显著性
+- 规范的随机分组与样本量计算是确保实验结果可靠性的基础
+- 置信区间与效应量分析比单纯的 p 值更能指导实际业务决策
+- 贝叶斯分析与多臂老虎机算法可实现实验过程中的持续学习与动态优化
+- 元分析能力可整合跨多个实验的结果，形成组织级知识积累
 
 ## Key Quotes
-> "Always calculate proper sample sizes before experiment launch" — 确保统计可靠性的基础要求
-> "95% of experiments reach statistical significance with proper sample sizes" — 实验成功标准
-> "Experiment velocity exceeds 15 experiments per quarter" — 实验吞吐量目标
-> "Zero experiment-related production incidents or user experience degradation" — 安全底线
+> "95% confident that the new checkout flow increases conversion by 8-15%" — 统计学精确表达的示例，体现置信区间的沟通价值
+> "Portfolio analysis shows 70% experiment success rate with average 12% lift" — 实验组合管理的系统性思维
+> "Proper randomization with 50,000 users per variant achieving statistical significance" — 科学严谨的实验执行标准
 
 ## Key Concepts
-- [[A/B-Testing]]：对照实验，通过控制组与变体组的比较验证假设
-- [[Statistical-Significance]]：统计显著性，95% 置信度为默认要求
-- [[Power-Analysis]]：统计功效分析，确保实验有足够样本量
-- [[Hypothesis-Validation]]：假设验证，通过实验数据验证产品假设
-- [[Experiment-Portfolio-Management]]：实验组合管理，优化多实验资源分配与优先级
-- [[Multi-Armed-Bandits]]：多臂老虎机，高级实验设计实现动态流量分配
-- [[Bayesian-Analysis]]：贝叶斯分析方法，支持连续学习与实时决策
-- [[Causal-Inference]]：因果推断技术，理解实验的真正效果
+- [[ABTesting]]：通过对照组与实验组的比较来验证假设的实验方法
+- [[StatisticalSignificance]]：95% 置信度阈值，确保实验结果非随机偶然
+- [[SampleSizeCalculation]]：实验前的样本量计算，保证统计功效（通常 80% power）
+- [[MultiArmedBandit]]：高级实验设计，支持实验过程中的动态流量分配
+- [[BayesianAnalysis]]：贝叶斯方法，支持持续学习和增量决策
+- [[CausalInference]]：因果推断技术，用于理解实验的真正效果
+- [[MetaAnalysis]]：元分析，跨实验结果整合，形成组织级学习
+- [[PowerAnalysis]]：统计功效分析，确保检测真实效应所需的最小样本量
 
 ## Key Entities
-- [[Project-Management-Experiment-Tracker]]：实验追踪专家 Agent 本身
-- [[Project-Management-Studio-Producer]]：受益于 Experiment Tracker 的实验数据，协调内容制作迭代
-- [[LaunchDarkly]]：Feature Flag 平台，支持 Experiment Tracker 的渐进放量与 A/B 测试
+- [[ProjectManager]]：Experiment Tracker Agent 本质上是一个专业的项目管理人员，专注于实验管理领域
+- [[ProductTeams]]：与产品团队协作，识别实验机会并提供数据驱动建议
 
 ## Connections
-- [[Project-Management-Studio-Operations]] ← coordinates_with ← [[Project-Management-Experiment-Tracker]]
-- [[Project-Management-Studio-Producer]] ← depends_on ← [[Project-Management-Experiment-Tracker]]
-- [[Project-Management-Jira-Workflow-Steward]] ← integrates_with ← [[Project-Management-Experiment-Tracker]]
-- [[Project-Management-Project-Shepherd]] ← leverages ← [[Project-Management-Experiment-Tracker]]
+- [[ProjectManagementStudioOperations]] ← extends ← [[ProjectManagementExperimentTracker]]
+- [[ProjectManagementProjectShepherd]] ← coordinates_with ← [[ProjectManagementExperimentTracker]]
+- [[ProjectManagementJiraWorkflowSteward]] ← tracks ← [[ProjectManagementExperimentTracker]]
 
 ## Contradictions
-- 与 [[Project-Management-Studio-Operations]] 潜在冲突：Studio Operations 强调内容制作流程的确定性，Experiment Tracker 依赖实验数据驱动，存在节奏冲突（快速实验 vs 稳定制作）
-  - 冲突点：决策依据（直觉/经验 vs 数据）
-  - 当前观点：数据驱动决策优先，实验验证后再规模化
-  - 对方观点：内容制作需保持节奏稳定，不能因等待实验结果而停滞
+- 暂无发现与其他 Wiki 页面的直接冲突
diff --git a/wiki/sources/project-management-project-shepherd.md b/wiki/sources/project-management-project-shepherd.md
index 19184cd3..190d49b4 100644
--- a/wiki/sources/project-management-project-shepherd.md
+++ b/wiki/sources/project-management-project-shepherd.md
@@ -1,53 +1,53 @@
 ---
 title: "Project Shepherd Agent Personality"
 type: source
-tags: [project-management, agent, cross-functional, stakeholder-management, risk-mitigation]
-date: 2026-04-20
+tags: ["agent", "project-management", "agency-agents"]
+date: 2026-05-06
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/project-management/project-management-project-shepherd.md]]
+- [[Agent/agency-agents/project-management/project-management-project-shepherd.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 项目管理人格——Project Shepherd，模拟跨职能项目协调专家，专注文档进度、对齐干系人、管理风险
-- 问题域：复杂项目的全生命周期管理，包括多团队/多部门协调、时间线规划、资源分配、干系人沟通
-- 方法/机制：四阶段工作流（项目启动→团队组建→执行监控→质量交付）、Project Charter 模板、Status Report 模板、风险缓解框架、干系人沟通策略
-- 结论/价值：提供一套完整的 AI Agent 项目管理人格定义，可直接用于 Multi-Agent 系统中的项目协调角色
+- 核心主题：Project Shepherd 是 The Agency 框架中专门负责跨职能项目协调和交付管理的 AI Agent 个性化定义文档
+- 问题域：复杂项目的规划、执行、监控与收尾全生命周期管理
+- 方法/机制：通过项目章程模板、工作分解结构（WBS）、利益相关方沟通策略、风险缓解计划和项目状态报告模板来规范项目交付流程
+- 结论/价值：确保 95% 项目按时在预算内交付，利益相关方满意度达 4.5/5，风险缓解成功率 90%
 
 ## Key Claims（用中文描述）
-- Project Shepherd Agent 通过四阶段工作流（启动→团队组建→执行→交付）驱动复杂项目按时、按范围、按预算完成
-- 通过 disciplined change control 限制范围蔓延，目标将范围蔓延控制在 10% 以下
-- 通过 proactive risk mitigation，目标实现 90% 的已识别风险在影响项目结果前被成功缓解
-- 通过透明沟通和诚实汇报维持干系人信任，即使在传递负面消息时也保持透明
-- 95% 项目按时交付、95% 干系人满意度 4.5/5 是核心成功指标
+- Project Shepherd Agent 通过制定详细的项目章程和沟通策略，实现跨职能团队的协调与对齐
+- 该 Agent 承诺 95% 项目按时在批准预算内交付，体现了严格的时间与资源纪律
+- 通过主动识别风险并制定缓解计划，90% 的已识别风险在影响项目结果前被成功化解
+- 变更控制机制确保范围蔓延低于 10%，保持项目可控性
 
 ## Key Quotes
-> "Never commit to unrealistic timelines to please stakeholders" — 绝不为了取悦干系人而承诺不现实的工期
-> "Provide honest, transparent reporting even when delivering difficult news" — 即便传递困难消息也提供诚实透明的汇报
-> "Escalate issues promptly with recommended solutions, not just problems" — 问题升级时必须附上建议的解决方案，而非仅提出问题
+> "Project is 2 weeks behind due to integration complexity, recommending scope adjustment" — 透明报告原则，即使传递坏消息也保持诚实
+> "Identified resource conflict with proposed mitigation through contractor augmentation" — 聚焦解决方案而非问题本身
+> "Never commit to unrealistic timelines to please stakeholders" — 拒绝不切实际的承诺以维护专业信誉
+> "Escalate issues promptly with recommended solutions, not just problems" — 上报时携带解决方案，而非仅呈报问题
 
 ## Key Concepts
-- [[CrossFunctionalProjectCoordination]]：跨职能项目协调——协调多个团队和部门完成复杂项目的能力
-- [[StakeholderAlignment]]：干系人对齐——通过沟通策略和透明汇报维持所有项目参与者的期望一致
-- [[RiskMitigationPlanning]]：风险缓解规划——在风险影响项目结果前主动识别、评估并制定应对策略
-- [[ChangeControl]]：变更控制——通过纪律化的范围管理控制项目范围蔓延（目标 < 10%）
-- [[ProjectCharter]]：项目章程——定义项目目标、范围、成功标准和治理结构的初始文档
-- [[WorkBreakdownStructure]]：工作分解结构（WBS）——将大型项目拆解为可管理的任务和依赖关系
-- [[CriticalPathAnalysis]]：关键路径分析——识别项目中最长的依赖链，确保关键里程碑按时完成
-- [[MatrixOrganization]]：矩阵式组织——在跨多条汇报线的组织结构中协调资源的能力
+- [[StakeholderManagement]]：维护所有利益相关方群体的定期沟通节奏，提供诚实透明的报告，即使传递困难消息
+- [[ChangeManagement]]：通过严格的变更控制流程管理项目范围、预算和时间表的变更，确保范围蔓延低于 10%
+- [[RiskMitigation]]：在风险影响项目结果前主动识别和缓解，90% 的已识别风险通过系统性计划成功化解
+- [[ProjectGovernance]]：建立决策权限明确的项目治理结构，确保所有决策有文档记录并遵循审批流程
+- [[ResourceOptimization]]：平衡资源利用率，防止团队倦怠并保持质量，追踪实际工作量与估算的偏差以改进未来规划
 
 ## Key Entities
-- [[ProjectShepherd]]：AI Agent 项目管理人格定义，专职跨职能项目协调、时间线管理和干系人对齐
-- [[ProjectCharter]]（模板）：定义项目概览、干系人分析、资源需求和风险评估的文档模板
-- [[ProjectStatusReport]]（模板）：包含执行摘要、进度更新、问题风险和干系人行动的定期报告模板
-- [[ExecutiveSponsor]]：执行发起人——拥有决策权威和升级终点的干系人角色
-- [[CrossFunctionalProjectTeam]]：跨职能项目团队——由多个技能领域成员组成的核心项目团队
+- [[ProjectShepherdAgent]]：The Agency 框架中的跨职能项目协调和利益相关方对齐专家，专注于将跨职能混乱引导为按时、按范围交付
 
 ## Connections
-- [[ProjectManagementStudioOperations]] ← extends ← [[ProjectShepherd]] — Studio Operations 是项目管理在创意制作场景的延伸
-- [[ProjectManagementSenior]] ← related_to ← [[ProjectShepherd]] — 两者都是项目管理者，但 Senior PM 侧重高级战略，Shepherd 侧重跨职能协调执行
-- [[AutonomousProjectManagement]] ← depends_on ← [[ProjectShepherd]] — 自主项目管理依赖 Shepherd 提供的工作流和模板框架
-- [[ProjectStateManagement]] ← related_to ← [[ProjectShepherd]] — 两者都涉及项目状态跟踪，但 State Management 偏向事件驱动替代看板的方法论
+- [[ProjectManagerSenior]] ← related_to ← [[ProjectShepherdAgent]]
+- [[ProjectManagementStudioOperations]] ← related_to ← [[ProjectShepherdAgent]]
+- [[ProjectManagementJiraWorkflowSteward]] ← supports ← [[ProjectShepherdAgent]]
+- [[ProjectManagementExperimentTracker]] ← supports ← [[ProjectShepherdAgent]]
 
 ## Contradictions
-- 无明显内容冲突。本文档与 [[ProjectManagementSenior]] 和 [[ProjectManagementStudioOperations]] 在项目管理层面上互补而非冲突，各有侧重领域。
+- 与 [[ProjectManagerSenior]] 可能的差异：
+  - 冲突点：职责范围与专业深度
+  - 当前观点：Project Shepherd 强调跨职能协调和利益相关方对齐，方法论导向
+  - 对方观点：Senior PM 可能更侧重项目执行细节和技术深度
+- 与 [[ProjectManagementStudioOperations]] 可能的差异：
+  - 冲突点：项目类型关注点
+  - 当前观点：Project Shepherd 专注复杂跨职能项目的全生命周期管理
+  - 对方观点：Studio Operations 专注于媒体/创意项目的运营管理
diff --git a/wiki/sources/project-management-studio-producer.md b/wiki/sources/project-management-studio-producer.md
index 37c7bf7c..3a9950cd 100644
--- a/wiki/sources/project-management-studio-producer.md
+++ b/wiki/sources/project-management-studio-producer.md
@@ -1,52 +1,57 @@
 ---
 title: "Studio Producer Agent Personality"
 type: source
-tags: []
-date: 2026-04-25
+tags: ["agent-personality", "project-management", "agency-agents", "strategic-leadership"]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/project-management/project-management-studio-producer.md]]
+- [[Agent/agency-agents/project-management/project-management-studio-producer.md]]
 
 ## Summary（用中文描述）
-- **核心主题**：Studio Producer Agent——专注于高管级别创意与项目管理的高级战略领导者 Agent，属于 Agency 项目管理部门。核心职责：战略组合管理、创意愿景与商业目标对齐、跨职能团队协调。
-- **问题域**：多项目组合管理、资源分配优化、高管级利益相关者沟通、风险与财务管控、团队绩效管理。
-- **方法/机制**：Strategic Portfolio Plan 模板（四层项目分级）、Strategic Portfolio Review 模板（季度复盘）、四阶段工作流（战略规划→项目编排→领导力发展→绩效优化）、ROI + 按时交付双指标驱动。
-- **结论/价值**：AI Agent 角色定位为高管级战略领导者，要求 25% 组合 ROI + 95% 按时交付率，面向需要复杂创意项目管理的组织。
+- 核心主题：Studio Producer（制片总监）AI Agent 个性定义，定位为创意工作室的高层战略领导者
+- 问题域：创意工作室的项目组合管理、跨部门协作、创意愿景与商业目标的平衡
+- 方法/机制：通过战略规划 → 项目组合编排 → 团队领导 → 绩效优化的四阶段工作流，交付 25% ROI 和 95% 准时交付率
+- 结论/价值：定义了一种将创意卓越与商业价值相结合的高管级 Agent 角色，可应用于多项目工作室、数字创意代理、产品工作室等场景
 
 ## Key Claims（用中文描述）
-- **Studio Producer** 通过战略组合规划（Strategic Portfolio Plan）将创意愿景与商业目标对齐，在项目分级（Tier 1/2 + Innovation Pipeline）中平衡风险与创新
-- **Portfolio ROI ≥ 25% + 95% on-time delivery** 是该角色的核心成功指标，要求同时管理财务纪律与创意卓越
-- **四阶段工作流**（战略规划→项目编排→领导力发展→绩效优化）构成该 Agent 的标准运营框架
-- **利益相关者管理**是该角色的核心竞争力，涉及高管沟通、期望设定与战略投资获取
-- **团队绩效与保留率**是该 Agent 的间接成功指标，反映领导力发展的长期效果
+- Studio Producer 作为战略领导者，通过项目组合编排将创意愿景与商业目标对齐，实现 25% 组合 ROI
+- 资源分配策略需平衡创意团队与技术人员配置，协同供应商关系，优化风险与创新的权衡
+- 战略规划需覆盖市场机会分析、创意愿景设定、资源容量规划、投资组合优先级框架
+- 高级能力包括并购战略、国际市场进入规划、AI 技术整合、董事会与投资者关系管理
 
 ## Key Quotes
-> "Portfolio ROI consistently exceeds 25% with balanced risk across strategic initiatives" — 核心成功指标定义
-> "Our Q3 portfolio delivered 35% ROI while establishing market leadership in emerging AI applications" — 沟通风格示例：战略性启发
-> "Board presentation highlights our competitive advantages and 3-year strategic positioning" — 执行影响思维示例
-> "Creative excellence drove $5M revenue increase and strengthened our premium brand positioning" — 业务价值导向示例
+> "Our Q3 portfolio delivered 35% ROI while establishing market leadership in emerging AI applications" — 战略性沟通风格示例
+> "This initiative positions us perfectly for the anticipated market shift toward personalized experiences" — 愿景对齐的表达方式
+> "Board presentation highlights our competitive advantages and 3-year strategic positioning" — 高管影响力沟通
 
 ## Key Concepts
-- [[Strategic-Portfolio-Management]]：通过分级项目组合（Tier 1/2 + Innovation Pipeline）实现资源最优配置与商业目标对齐
-- [[Resource-Allocation]]：跨创意/技术资源的计划与分配，平衡短期交付与长期能力建设
-- [[Stakeholder-Alignment]]：高管级利益相关者关系管理与战略沟通，确保创意愿景与商业目标一致
-- [[Portfolio-ROI]]：组合层面的投资回报率优化，Studio Producer 要求 ≥ 25% ROI
-- [[Risk-Balancing]]：在创新实验与已验证方法之间管理风险敞口
-- [[Cross-Functional-Orchestration]]：协调跨职能团队形成与战略对齐，管理复杂相互依赖关系
-- [[Innovation-Pipeline]]：实验性项目的管理框架，设定学习目标而非短期回报
+- [[Strategic Portfolio Management]]：通过协调多个高价值项目及复杂依赖关系，实现组合层面的 ROI 和战略目标
+- [[Creative-Business Alignment]]：将创意卓越与商业目标、市场机会对齐的元框架
+- [[Resource Allocation Strategy]]：跨项目优先级的创意与技术资源配置方法论
+- [[ROI Optimization]]：通过绩效跟踪和战略优化，实现 25%+ 投资回报率
+- [[Multi-Project Orchestration]]：协调多个并发项目的复杂依赖、团队协作和利益相关方沟通
+- [[Stakeholder Management]]：高层利益相关方关系管理和高管级别沟通策略
+- [[Risk Management]]：跨项目组合风险评估与平衡投资策略
 
 ## Key Entities
-- [[Project-Management-Studio-Operations]]：Studio Producer 的运营执行搭档，负责具体项目交付
-- [[Project-Manager-Senior]]：项目经理的高级版本，更侧重执行层面
-- [[Project-Management-Project-Shepherd]]：项目看护角色，关注项目生命周期跟进
-- [[Project-Management-Experiment-Tracker]]：实验跟踪角色，关注迭代与学习
+- [[Studio Producer]]：创意工作室的制片总监 Agent，核心职责为战略项目组合管理与创意愿景对齐
+- [[Project Manager Senior]]：项目组合中的项目级管理者，与 Studio Producer 形成层级协作关系
+- [[Studio Operations]]：工作室运营 Agent，与制片总监协作确保工作室最佳运营状态
+- [[Project Shepherd]]：项目守护者 Agent，在项目层面提供支持
+- [[Jira Workflow Steward]]：Jira 工作流管理 Agent，与项目组合管理工具链集成
 
 ## Connections
-- [[Project-Management-Studio-Operations]] ← supports ← [[Project-Management-Studio-Producer]]（战略规划由 Producer 制定，Operations 负责落地执行）
-- [[Project-Management-Project-Shepherd]] ← coordinates_with ← [[Project-Management-Studio-Producer]]（项目看护与 Producer 的组合管理对齐）
-- [[Sales-Engineer]] ← interfaces_with ← [[Project-Management-Studio-Producer]]（售前赢单后转交 Producer 编排交付）
+- [[Project Manager Senior]] ← 上级战略 ← [[Studio Producer]]
+- [[Project Management Studio Operations]] ← 运营协作 ← [[Studio Producer]]
+- [[Project Management Project Shepherd]] ← 项目支持 ← [[Studio Producer]]
+- [[Project Management Jira Workflow Steward]] ← 工具链集成 ← [[Studio Producer]]
+- [[Project Management Experiment Tracker]] ← 创新管道 ← [[Studio Producer]]
+- [[Agents Orchestrator]] ← Agent 编排框架 ← [[Studio Producer]]
 
 ## Contradictions
-- 与 [[Project-Management-Studio-Operations]] 的角色边界：张力存在于战略（Producer）与运营（Operations）之间的权责划分——Producer 偏向高管级战略视角，Operations 偏向执行层；两者需通过定期 Portfolio Review 对齐
-- 与传统 [[Project-Manager-Senior]] 的管理幅度：张力存在于管理广度——Producer 管理整个组合（Portfolio），而 Senior PM 通常管理单个项目；这是层级差异而非矛盾
+- 与 [[Project Manager Senior]] 可能的冲突：
+  - 冲突点：战略层（Portfolio）vs 执行层（Project）的关注点差异
+  - 当前观点：Studio Producer 强调高管视角、战略 ROI 和长期规划
+  - 对方观点：Senior PM 强调项目交付细节、里程碑和风险管理
+  - 说明：两者处于不同抽象层级，Studio Producer 负责投资组合决策，Senior PM 负责具体项目执行，形成互补而非冲突
diff --git a/wiki/sources/project-manager-senior.md b/wiki/sources/project-manager-senior.md
index 447efdc8..db9b62ba 100644
--- a/wiki/sources/project-manager-senior.md
+++ b/wiki/sources/project-manager-senior.md
@@ -1,50 +1,52 @@
 ---
 title: "Senior Project Manager Agent Personality"
 type: source
-tags: [agent, project-management, laravel, livewire, fluxui, scope-control]
-date: 2026-04-20
+tags: []
+date: 2026-04-29
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/project-management/project-manager-senior.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 项目经理（SeniorProjectManager）的人格定义与任务分解方法论
-- 问题域：Web 开发项目中需求规格到可执行任务的转化过程，以及如何避免范围蔓延（scope creep）
-- 方法/机制：读取 site-setup.md 规格文档 → 引用精确需求 → 拆解为 30-60 分钟粒度的任务列表 → 存储到 memory-bank
-- 结论/价值：提供一套结构化的 AI PM 工作流程，强调务实（realistic scope）、精确引用规格、开发者优先
+- 核心主题：AI Agent 人格定义 —— Senior Project Manager（高级项目经理），专注于将站点规格说明转换为可执行开发任务清单
+- 问题域：Web 开发项目需求分解、任务规划、范围管理，避免需求蔓延（scope creep）
+- 方法/机制：通过阅读规格说明文件（`ai/memory-bank/site-setup.md`），提取精确需求，将大规格拆解为 30-60 分钟可完成的原子任务，并附带验收标准
+- 结论/价值：为开发团队提供清晰、可操作、范围可控的任务列表，确保项目按时交付
 
 ## Key Claims（用中文描述）
-- **Agent + 规格文件 + 精确引用 → 任务列表**：通过逐字引用规格文档中的原始需求来创建任务，避免主观添加功能
-- **Agent + 经验积累 + 模式库 → 持续改进**：从每个项目中学习，构建成功任务拆解的模式库
-- **Agent + 务实范围 + 基础实现 → 避免失败**：默认基础实现即可接受，优先完成功能而非打磨
+- Senior Project Manager Agent 通过引用规格原文（而非自行发挥）来确保任务准确对应需求
+- 任务粒度控制在 30-60 分钟可完成单元，确保开发节奏稳定
+- 强调基础实现优于奢华功能，优先保证功能完整而非过度打磨
+- 具备持久记忆能力，从每个项目中学习并积累经验
 
 ## Key Quotes
-> "Quote EXACT requirements (don't add luxury/premium features that aren't there)" — 规格引用原则，要求 Agent 不添加规格中未明确的功能
-> "Each task should be implementable by a developer in 30-60 minutes" — 任务粒度标准，保证任务可执行性
-> "Don't add 'luxury' or 'premium' requirements unless explicitly in spec" — 务实范围控制，防止范围蔓延
-> "No background processes in any commands - NEVER append `&`" — 技术约束，Agent 必须遵守的技术红线
+> "Most specs are simpler than they first appear" — 不要过度解读规格，避免不必要的功能添加
+> "Don't add luxury or premium requirements unless explicitly in spec" — 范围管理的核心原则
+> "No background processes in any commands - NEVER append `&`" — 技术质量硬性要求
+> "First implementations need 2-3 revision cycles" — 对迭代周期的合理预期管理
 
 ## Key Concepts
-- [[ScopeCreepPrevention]]：通过精确引用规格、限制基础实现、记录范围决策来防止项目范围蔓延
-- [[TaskDecomposition]]：将规格拆解为 30-60 分钟粒度的可执行任务，包含验收标准
-- [[AgenticProjectManagement]]：AI Agent 作为项目经理角色，通过记忆和经验积累持续改进任务创建流程
-- [[FluxUI]]：Laravel Livewire 生态的前端组件库，PM Agent 需了解其组件属性和约束
-- [[AcceptanceCriteria]]：每个任务必须包含可测试的验收标准
+- [[TaskListCreation]]：将规格说明拆解为可执行任务清单，每个任务附带验收标准
+- [[RealisticScopeManagement]]：避免范围蔓延，聚焦功能需求而非奢华功能
+- [[PersistentMemory]]：Agent 记住项目经验、常见陷阱和成功模式
+- [[AcceptanceCriteria]]：每个任务附带明确可测试的验收标准
+- [[FluxUIComponentIntegration]]：Laravel/Livewire 技术栈下的 FluxUI 组件集成要求
 
 ## Key Entities
-- [[ProjectManagementJiraWorkflowSteward]]：同属项目管理体系，另一个专注于 Jira 工作流编排的 Agent
-- [[ProjectManagementProjectShepherd]]：同属项目管理体系，专注于项目全局把控的 Agent
-- [[ProjectManagementStudioOperations]]：同属项目管理体系，专注于工作室运营的 Agent
+- [[LaravelLivewire]]：后端技术栈，提供动态页面能力
+- [[FluxUI]]：前端组件库，提供可复用 UI 组件
+- [[Playwright]]：截图测试工具，用于 QA 验证
+- [[site-setup.md]]：规格说明文件路径，PM Agent 的输入来源
 
 ## Connections
-- [[ProjectManagementJiraWorkflowSteward]] ← related_to ← [[ProjectManagerSenior]]
-- [[ProjectManagementProjectShepherd]] ← related_to ← [[ProjectManagerSenior]]
-- [[ProjectManagementStudioOperations]] ← related_to ← [[ProjectManagerSenior]]
+- [[ProjectShepherd]] ← similar_role ← [[SeniorProjectManager]]
+- [[StudioProducer]] ← similar_role ← [[SeniorProjectManager]]
+- [[JiraWorkflowSteward]] ← similar_role ← [[SeniorProjectManager]]
+- [[BackendArchitectWithMemory]] ← depends_on ← [[SeniorProjectManager]]
 
 ## Contradictions
-- 与 [[ProjectManagementProjectShepherd]] 可能的冲突：
-  - 冲突点：职责边界 — Project Shepherd 关注项目整体把控，Senior PM 关注任务拆解细节
-  - 当前观点：Senior PM 强调任务粒度控制和精确引用规格，务实处理基础功能
-  - 对方观点：Project Shepherd 可能更关注项目整体节奏和风险，需要更高层次的抽象
-  - 协调建议：Senior PM 产出任务列表供 Project Shepherd 调度，两者形成执行层与规划层的协作关系
+- 与 [[ScopeCreep]] 冲突：
+  - 冲突点：是否应添加规格中未明确要求的"奢华/高级"功能
+  - 当前观点：严格按规格执行，不添加额外功能
+  - 对方观点：追求高品质交付，可适度超出规格
diff --git a/wiki/sources/quickstart.md b/wiki/sources/quickstart.md
new file mode 100644
index 00000000..69c5d904
--- /dev/null
+++ b/wiki/sources/quickstart.md
@@ -0,0 +1,69 @@
+---
+title: "NEXUS Quick-Start Guide"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/QUICKSTART.md]]
+
+## Summary（用中文描述）
+- 核心主题：NEXUS 多智能体编排框架的快速启动指南，将 The Agency 的 AI 专家组成协调管道，实现自动化流水线作业
+- 问题域：如何在 5 分钟内从零启动一个完整的多智能体协作流水线，覆盖从发现到运营的全生命周期
+- 方法/机制：提供三种启动模式（NEXUS-Full/NEXUS-Sprint/NEXUS-Micro），每种模式预设角色组合、阶段流程和质量门控
+- 结论/价值：通过标准化的质量门控、Dev↔QA 循环、证据优先原则，确保多智能体协作的可控性和可交付性
+
+## Key Claims（用中文描述）
+- NEXUS 通过定义每个 Agent 的职责、触发时机和质量验证机制，将孤立激活 Agent 的混乱模式转变为可编排的流水线
+- 三种模式覆盖从完整产品开发（12-24周）到单一任务执行（1-5天）的全场景
+- Reality Checker 作为最终质量权威，默认返回 "NEEDS WORK"，确保不成熟输出不会进入下一阶段
+- Evidence Over Claims 原则要求所有评估必须有截图、测试结果或数据支撑，而非口头断言
+
+## Key Quotes
+> "Quality gates between every phase. Evidence required for all assessments." — NEXUS 核心原则
+> "Start with a mode. Follow the playbook. Trust the pipeline." — NEXUS Quick-Start 结尾
+
+## Key Concepts
+- [[Quality Gates]]：每个阶段之间设置质量门控，无证据支撑的评估无法推进
+- [[Dev↔QA Loop]]：每个任务都经过构建→测试循环；PASS 则继续，FAIL 则重试（最多3次）
+- [[Handoffs]]：Agent 之间结构化的上下文传递，确保接收方不需要"冷启动"
+- [[Reality Checker]]：最终质量权威；默认返回 "NEEDS WORK"，要求补充证据
+- [[Agents Orchestrator]]：管道控制器，管理整个 NEXUS 流水线的执行流程
+- [[Evidence Over Claims]]：用截图、测试结果和数据说话，而非口头断言
+- [[NEXUS-Full]]：完整产品开发模式，6个阶段全流程，约 12-24 周
+- [[NEXUS-Sprint]]：功能/MVP 开发模式，跳过市场发现阶段，约 2-6 周
+- [[NEXUS-Micro]]：单一任务执行模式（Bug 修复、营销活动、合规审计等），约 1-5 天
+
+## Key Entities
+- [[The Agency]]：NEXUS 框架所属的组织，汇集 AI 专家的协调管道
+- [[Trend Researcher]]：市场趋势研究员，Phase 0 发现阶段核心角色
+- [[Feedback Synthesizer]]：反馈综合器，聚合用户/市场反馈
+- [[UX Researcher]]：用户体验研究员，发现可用性问题
+- [[Analytics Reporter]]：分析报告生成器，跟踪性能指标
+- [[Legal Compliance Checker]]：法律合规检查员，覆盖 GDPR/CCPA/HIPAA
+- [[Studio Producer]]：制作人角色，统筹项目排期和资源
+- [[Senior Project Manager]]：高级项目经理，把控交付节奏
+- [[UX Architect]]：UX 架构师，设计体验方案
+- [[Brand Guardian]]：品牌守护者，审核所有对外内容的一致性
+- [[Backend Architect]]：后端架构师，技术选型和实现
+- [[Frontend Developer]]：前端开发工程师，用户界面实现
+- [[DevOps Automator]]：DevOps 自动化工程师，CI/CD 和部署
+- [[Evidence Collector]]：证据收集员，验证改进效果
+- [[Reality Checker]]：现实检查员，最终质量权威
+- [[API Tester]]：API 测试工程师，接口级验证
+- [[Performance Benchmarker]]：性能基准测试工程师
+- [[Growth Hacker]]：增长黑客，优化获客和转化渠道
+- [[Content Creator]]：内容创作者，生成营销素材
+- [[Social Media Strategist]]：社交媒体策略师，多渠道内容规划
+
+## Connections
+- [[nexus-strategy]] ← extends ← [[quickstart]]（策略主文档 ← 快速启动指南）
+- [[phase-0-discovery]] ← depends_on ← [[quickstart]]（Phase 0 发现 ← 快速启动）
+- [[phase-1-strategy]] ← depends_on ← [[quickstart]]（Phase 1 策略 ← 快速启动）
+- [[agents-orchestrator]] ← core_of ← [[quickstart]]（编排器 ← 核心组件）
+- [[workflow-startup-mvp]] ← relates_to ← [[quickstart]]（启动 MVP 工作流 ← 相关场景）
+- [[scenario-startup-mvp]] ← relates_to ← [[quickstart]]（启动 MVP 场景 ← 快速启动模式示例）
+
+## Contradictions
+- 暂无已知冲突内容
diff --git a/wiki/sources/readme.md b/wiki/sources/readme.md
index b525dc5b..7c4b01b0 100644
--- a/wiki/sources/readme.md
+++ b/wiki/sources/readme.md
@@ -1,40 +1,42 @@
 ---
-title: "OpenCode Integration"
+title: "Qwen Code Integration"
 type: source
 tags: []
-date: 2026-04-26
+date: 2026-05-02
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/scripts/i18n/README.md]]
+- [[Agent/agency-agents/integrations/qwen/README.md]]
 
 ## Summary（用中文描述）
-- 核心主题：OpenCode 的子 Agent 集成机制——如何将 .md 文件格式的 Agent 转换为 OpenCode 可调用的子代理
-- 问题域：OpenCode IDE 中的多 Agent 协作与按需调用
-- 方法/机制：通过 YAML frontmatter 中的 `mode: subagent` 标记，将具名 Agent 从 Tab 循环列表中分离，改为按需 `@agent-name` 调用；颜色通过命名颜色到十六进制的自动映射实现
-- 结论/价值：提供了一种轻量级、无需修改主 Agent 系统的子 Agent 扩展方案，支持项目级和全局级两种安装范围
+- 核心主题：Agency Agents 项目如何将 SubAgent 定义导出为 Qwen Code 可用的格式
+- 问题域：AI Agent 的跨平台复用与工具无关的 SubAgent 文件标准化
+- 方法/机制：通过 `scripts/convert.sh --tool qwen` 将 agency agents 转换为 Qwen Code 的 `.qwen/agents/` SubAgent Markdown 文件；通过 `install.sh --tool qwen` 部署到目标项目
+- 结论/价值：实现 Agent 定义的"一次编写，多工具导出"，降低多 AI 工具生态中的重复配置成本
 
 ## Key Claims（用中文描述）
-- OpenCode Agent 通过在 `.opencode/agents/` 目录存储 .md 文件（带 YAML frontmatter）实现——文件格式与 The Agency 的 Agent 定义格式兼容
-- `mode: subagent` 配置使 Agent 仅在 `@agent-name` 触发时出现，不会在 Tab 循环列表中占位——保持主 Agent 列表的简洁性
-- 命名颜色（如 `cyan`）在安装脚本中被自动转换为十六进制颜色代码——无需手动查表
-- Agent 支持两种安装范围：项目级（`.opencode/agents/`）和全局级（`~/.config/opencode/agents/`）——通过不同路径实现作用域隔离
-- 转换脚本 `./scripts/convert.sh --tool opencode` 负责将 The Agency 的标准 Agent 文件转换为 OpenCode 兼容格式
+- Agency Agents 通过项目级 `.md` SubAgent 文件在 `.qwen/agents/` 中管理 Agent 定义
+- `convert.sh --tool qwen` 脚本负责将 agency agents 逐一转换为 Qwen Code SubAgent Markdown 格式
+- Qwen Code 为项目级作用域（project-scoped），而非 home-scoped
+- Qwen SubAgent 文件采用最小化 frontmatter（name、description、tools）
+- 更新 agency agents 后需重新生成并重新安装
 
 ## Key Quotes
-> "mode: subagent — agent is available on-demand, not shown in the primary Tab-cycle list"
-> — Agent YAML frontmatter 的核心语义，说明 subagent 模式与普通 agent 的本质区别
+> "Qwen Code is project-scoped, not home-scoped" — Qwen Code 的作用域设计原则，说明其 Agent 配置与特定项目绑定
+> "If you update agents in this repo, regenerate the Qwen output before reinstalling" — 使用建议：SubAgent 源变更后必须重新生成
+> "run `/agents manage` in Qwen Code to refresh the agent list, or restart the current Qwen Code session" — Qwen Code 中的 Agent 刷新方式
 
 ## Key Concepts
-- [[Subagent]]：按需调用的辅助 Agent，通过 `@agent-name` 语法触发，不参与 Tab 循环
-- [[OpenCode]]：一个支持多 Agent 协作的 IDE/编辑器扩展平台
+- [[SubAgent]]：一种以 Markdown 文件定义的 AI Agent 描述格式，支持 frontmatter 元数据
+- [[Tool Integration Export]]：将同一套 Agent 定义转换为不同 AI 工具（Qwen Code、Claude Code 等）的专属格式
 
 ## Key Entities
-- [[The Agency]]：OpenCode Agent 的来源框架，提供 147 个专业化 Agent 定义
+- [[Agency Agents]]：开源多 Agent 框架，支持生成多种 AI 工具的 SubAgent 文件
+- [[Qwen Code]]：阿里巴巴的 AI 编程助手，采用项目级作用域的 Agent 管理方式
 
 ## Connections
-- [[contributing]] ← 贡献来源 ← [[Agent/agency-agents/integrations/opencode/README.md]]
-- [[The Agency]] ← Agent 定义来源 ← [[Agent/agency-agents/integrations/opencode/README.md]]
+- [[Contributing]] ← extends ← [[Qwen Code Integration]]（Qwen 集成是 Agency Agents 对外扩展的一部分）
+- [[Qwen Code Integration]] ← generates ← [[SubAgent Files]]
 
 ## Contradictions
-- （未检测到与其他页面的明显冲突）
+- 无明显冲突
diff --git a/wiki/sources/real-estate-buyer-seller.md b/wiki/sources/real-estate-buyer-seller.md
new file mode 100644
index 00000000..3f624f3e
--- /dev/null
+++ b/wiki/sources/real-estate-buyer-seller.md
@@ -0,0 +1,60 @@
+---
+title: "Real Estate Buyer & Seller Agent"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/real-estate-buyer-seller.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency 专业部门下的房地产买方/卖方代理 Agent，专注于住宅和投资物业的全流程交易支持
+- 问题域：经纪人如何在最大财务决策中为客户提供专业、响应迅速且真正投入的服务——贯穿从首次看房到最终交割的全生命周期
+- 方法/机制：五步工作流（咨询→搜索/挂牌→要约谈判→交易管理→交割）结合十大关键规则驱动，配备标准化技术交付物（CMA、需求评估表、要约策略框架、交易时间线等）
+- 结论/价值：经纪人的三大支柱——沟通能力、响应速度和专业知识——必须始终如一地践行；交易成功=满意客户=推荐增长
+
+## Key Claims（用中文描述）
+- 经纪人必须完全代表客户的最佳利益——代表买方或卖方，绝不妥协客户立场以更快成交或避免冲突
+- 口头协议在房地产中不可执行——每份要约、反要约、修改和协议必须书面记录并由所有方签署
+- 公平住房合规是绝对的——绝不基于种族、肤色、宗教、国籍、性别、家庭状况、残疾或任何其他受保护类别进行歧视或引导客户离开任何社区
+- 经纪人必须披露所有已知重大缺陷——无论是否对交易有帮助，不披露即构成欺诈
+- 合同截止日期是关键义务——错过检查期、融资意外险期或交割日期可能导致客户损失定金或失去交易
+- 尽职调查资金（Earnest Money）必须严格按合同条款处理——错误的托管方、金额或时机均可构成违约
+- 经纪人不得从事法律实践或提供法律建议——房地产经纪人不是律师，建议客户对复杂合同问题寻求法律顾问
+- 经纪人必须持续了解市场状况——定价建议和要约策略必须基于当前经核实的可比销售数据，而非直觉或过时信息
+- 响应速度是核心竞争力——在房地产行业，响应缓慢会失去客户和交易；工作时间内2小时内回复是基准
+- 交易成功带来忠诚客户和推荐增长——顶级 Box 评分目标+≥50% 推荐率是衡量经纪人成功的关键指标
+
+## Key Quotes
+> "The best real estate agents don't just open doors — they open possibilities. They listen more than they talk, know the market better than anyone, and guide clients through one of the most complex and emotional decisions of their lives with calm expertise and genuine care." — 经纪人身份定位核心理念
+>
+> "In real estate, slow responses lose clients and deals. Return every call, text, and email the same day — within 2 hours during business hours." — 响应速度的至高重要性
+>
+> "Every transaction is someone's biggest financial decision. Every client deserves an agent who is organized, responsive, and genuinely invested in their outcome — not just the commission check." — 经纪人的价值观宣言
+
+## Key Concepts
+- [[BuyerNeedsAssessment]]：经纪人通过标准化需求评估表收集买方价格范围、必须项、放弃项、目标区域、学区偏好、通勤要求和时间线动机
+- [[ComparativeMarketAnalysis]]：经纪人使用 CMA 模板分析活跃竞争、待定销售和已售可比物业，为卖方提供定价建议或为买方提供要约价格指导
+- [[OfferNegotiation]]：经纪人在多重报价情境中使用阶梯竞价条款、最高最优报价流程、房屋检查谈判和评估缺口策略
+- [[TransactionCoordination]]：经纪人在合同签署后协调托管、房屋检查、融资审批、意外险清除和各方供应商
+- [[FairHousingCompliance]]：经纪人严格遵守公平住房法，绝不基于任何受保护类别进行歧视或引导
+- [[EarnestMoneyHandling]]：经纪人必须严格按合同条款处理定金——错误的托管方、金额或时机均可构成违约
+
+## Key Entities
+- （本文未提及具体人物/公司/产品名称，无 Key Entities 条目）
+
+## Connections
+- [[SalesEngineer]] ← similar_skills ← [[RealEstateBuyerSeller]]（两者均需深度客户沟通、需求收集、定制化交付物和谈判策略）
+- [[SalesOutreach]] ← different_domain ← [[RealEstateBuyerSeller]]（前者为 B2B 销售外勤，后者为房地产交易代理；两者均使用 ICP 框架和谈判技巧）
+- [[HospitalityGuestServices]] ← different_domain ← [[RealEstateBuyerSeller]]（前者为酒店客户服务，后者为房地产交易代理；两者均以响应速度和客户体验为核心成功指标）
+
+## Contradictions
+- 与 [[SalesOutreach]] 在"个性化深度"上存在视角差异：
+  - 冲突点：销售外勤 Agent 强调规模化触达（冷邮件序列、批量 ICP 筛选）；房地产经纪人强调极致个性化（每次看房记录客户反应、每周卖家市场更新、针对每位客户的 CMA 定制）
+  - 当前观点（Real Estate Agent）：房地产是最大财务决策，每个客户必须获得深度个性化服务
+  - 对方观点（Sales Outreach）：规模化是增长的核心驱动力，个性化与规模化必须通过工具平衡而非纯人工
+  - 评估：领域差异，非事实矛盾——房地产交易天然高价值、低频次，适合深度个性化；B2B 销售外勤批量触达场景不同
+
+## Conflicts
+- （经检测，无与现有 Wiki 页面的内容冲突）
diff --git a/wiki/sources/recruitment-specialist.md b/wiki/sources/recruitment-specialist.md
index d644b321..43c14f44 100644
--- a/wiki/sources/recruitment-specialist.md
+++ b/wiki/sources/recruitment-specialist.md
@@ -1,53 +1,77 @@
 ---
 title: "Recruitment Specialist Agent"
 type: source
-tags: []
-date: 2026-04-25
+tags: [hr, recruitment, china-hr, talent-acquisition, labor-law]
+date: 2026-05-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/recruitment-specialist.md]]
+- [[Agent/agency-agents/specialized/recruitment-specialist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：RecruitmentSpecialist 是一个专注于中国人力资源市场的招聘运营与人才获取专家 Agent，覆盖从人才吸引、入职到留任的全周期招聘引擎
-- 问题域：中国招聘平台运营、JD 优化、简历筛选、面试流程设计、校园招聘、猎头管理、劳动法合规、雇主品牌建设、入职管理、招聘数据分析
-- 方法/机制：多平台渠道运营（BOSS直聘、拉勾、猎聘、智联、前程无忧、脉脉、LinkedIn）、结构化面试（STAR 框架）、能力模型评估、ATS 系统集成、劳动法合规检查、招聘漏斗数据分析
-- 结论/价值：帮助企业建立高效、合规、数据驱动的全链路招聘系统，提升招聘ROI、缩短到岗周期、降低试用期流失率
+- 核心主题：中国市场全周期招聘运营与人才获取专家 Agent
+- 问题域：企业在中国主流招聘平台上高效招聘、合规用工、构建竞争性雇主品牌
+- 方法/机制：招聘渠道运营（7大平台矩阵）+ JD优化 + 人才评估 + 面试流程设计 + 校园招聘 + 猎头管理 + 劳动法合规 + 雇主品牌 + 入职管理 + 数据分析
+- 结论/价值：提供端到端招聘系统，覆盖从人才吸引到入职保留的全流程，辅以数据驱动的ROI分析和合规保障
 
 ## Key Claims（用中文描述）
-- 通过多平台渠道精细化运营，可实现招聘ROI持续提升，每季度渠道成本趋于下降
-- 使用STAR行为面试框架和结构化评分卡，可提升面试评估准确性和一致性
-- 严格遵守中国劳动法（劳动合同法、就业促进法、个人信息保护法）可避免合规风险和赔偿损失
-- 数据驱动的招聘漏斗分析能识别瓶颈并持续优化各环节转化率
-- 候选人体验（NPS 80+）与 offer 接受率（85%+）高度相关
+- Boss直聘（直接聊天）简历成本是猎聘的1/3，但中高级职位候选人质量较低——建议初级职位用Boss直聘，中高级职位用猎聘
+- JD A/B测试：不同标题和描述风格对投递量的影响差异显著，必须通过数据验证
+- 候选人申请到首次响应超过5天，应用转化率下降40%——首次响应时间必须控制在48小时以内
+- 试用期留存率90%+、招聘渠道ROI季度改善、候选人体验NPS 80+、劳动法合规零事故是招聘运营成功的核心指标
+- 试用期超过法定时限，公司必须按已完成试用期标准支付赔偿金——合规风险必须规避
+- 非竞业补偿金超过3个月未支付，员工有权解除非竞业义务
+- 数据驱动决策：每次招聘决策必须有数据支撑，不能依赖直觉
 
 ## Key Quotes
-> "When candidates wait more than 5 days from application to first response, application conversion drops by 40%. We must keep initial response time under 48 hours." — 候选人响应时效对转化率的影响
-> "Boss Zhipin's cost per resume is one-third of Liepin's, but candidate quality for mid-to-senior roles is lower. I recommend using Boss for junior roles and Liepin for senior ones." — 招聘渠道ROI差异化建议
-> "If the probation period exceeds the statutory limit, the company must pay compensation based on the completed probation standard. This risk must be avoided." — 试用期合规风险警示
+> "Boss直聘的简历成本是猎聘的1/3，但候选人质量对中高级职位较低。建议初级职位用Boss直聘，中高级职位用猎聘。" — 渠道ROI分析与选型策略
+> "当候选人等待超过5天从申请到首次响应时，应用转化率下降40%。我们必须将首次响应时间控制在48小时以内。" — 候选人体验标准
+> "如果试用期超过法定上限，公司必须按已完成试用期标准支付赔偿金。这一风险必须规避。" — 劳动法合规要点
+> "非竞业补偿金超过3个月未支付，员工有权终止非竞业义务。" — 非竞业条款执行
 
 ## Key Concepts
-- [[RecruitmentFunnelAnalyzer]]：招聘漏斗分析器类，计算各环节转化率、渠道ROI、入职周期
-- [[STAR Framework]]：行为面试框架（Situation-Task-Action-Result），用于评估候选人具体行为
-- [[Structured Interview]]：结构化面试，使用标准化评分卡确保面试一致性和评估准确性
-- [[China Labor Law Compliance]]：中国劳动法合规，包括劳动合同法、试用期规定、五险一金、竞业限制、N+1 补偿等
-- [[Employer Brand Building]]：雇主品牌建设，通过短视频、内容营销、平台口碑管理提升对人才的吸引力
-- [[Onboarding SOP]]：标准化入职流程，从入职前7天到第一个月的完整 checklist
+- [[STAR面试法]]：行为面试框架（Situation-Task-Action-Result），通过追问获取候选人具体行为而非假设性答案
+- [[Competency-Model]]：人才评估三维度模型（专业技能/通用能力/文化契合度）
+- [[Recruitment-Funnel]]：招聘漏斗分析（曝光→投递→简历通过→一面→二面→终面→Offer→入职→试用期通过），各环节转化率量化追踪
+- [[Labor-Contract-Law]]：劳动合同法核心要点（30天内签署书面合同/合同类型/无固定期限合同触发条件）
+- [[Wuxian-Yijin]]：五险一金（养老/医疗/失业/工伤/生育保险+住房公积金），入职30天内完成登记缴纳
+- [[Probation-Period]]：试用期时限（合同期3月~<1年→1个月；1年~<3年→2个月；3年+→6个月），工资不低于约定80%且不低于本地最低工资
+- [[Non-Compete-Clause]]：竞业限制（不超过2年，需支付不低于离职前12个月平均月薪30%的月补偿金）
+- [[Severance-N-Plus-1]]：法定经济补偿金N（每满一年算一个月）+1（代通知金），违法解除赔偿2N
+- [[Campus-Recruiting]]：秋招（8-12月985/211锁定顶尖毕业生）/春招（次年2-5月补充考研/考公失利候选人）
+- [[Headhunter-Management]]：猎头渠道分层管理（大型/精品/行业垂直），费率标准（普通职位15-20%/高级职位20-30%年薪资）
+- [[ATS-System]]：招聘管理系统（北森/Moka/飞书招聘），用于简历解析、初筛自动化、人才库管理
+- [[JD-A-B-Testing]]：职位描述A/B测试，通过不同标题和描述风格验证对投递量的影响
+- [[Employer-Brand]]：雇主品牌建设（抖音/B站/小红书/脉脉/知乎内容营销+看准网口碑管理）
+- [[Onboarding-SOP]]：入职SOP标准流程（T-7预入职→T入职日→T+7第一周→T+30第一月）
+- [[Recruitment-Data-Analytics]]：招聘数据分析（漏斗分析/渠道ROI/招聘周期/健康仪表盘）
+- [[RecruitmentFunnelAnalyzer]]：Python招聘漏斗分析器类，计算各环节转化率和关键指标
 
 ## Key Entities
-- [[Boss Zhipin]]（BOSS直聘）：中国领先的直聊招聘平台，简历成本低，适合初级岗位
-- [[Lagou]]（拉勾网）：专注互联网/科技岗位的招聘平台，技能标签匹配算法
-- [[Liepin]]（猎聘网）：中高端猎头导向平台，适合资深岗位
-- [[Beisen]]（北森）：领先的HR SaaS，ATS 系统用于招聘流程管理
-- [[Moka]]（Moka智能招聘）：智能化 ATS 系统
-- [[Feishu Recruiting]]（飞书招聘）：字节跳动 Lark 的 HR 模块
-- [[STAR Method]]：行为面试评估方法论
+- [[Boss-Zhipin]]（BOSS直聘）：中国领先直接聊天招聘平台，优化公司主页和职位卡片，利用直接聊天互动技巧
+- [[Lagou]]（拉勾网）：专注互联网/科技职位的招聘平台，利用技能标签匹配算法
+- [[Liepin]]（猎聘网）：猎头导向平台，适合中高级人才管道建设
+- [[Zhaopin]]（智联招聘）：全行业全层级职位平台，覆盖校园招聘门户
+- [[51job]]（前程无忧）：高流量招聘网站，适合批量职位发布和简历库管理
+- [[Maimai]]（脉脉）：中国职业社交平台，通过内容营销触达被动候选人，监控职场口碑
+- [[Beisen]]（北森）：领先HR SaaS招聘云系统
+- [[Moka]]（Moka智能招聘）：智能化招聘管理系统
+- [[Feishu-Recruiting]]（飞书招聘/Lark HR）：字节跳动飞书/Lark的HR招聘模块
+- [[Niuke]]（牛客网）：中国领先在线编程评估平台，与LeetCode集成技术面试
+- [[Kanzhun]]（看准网）：雇主点评平台，用于薪酬竞争力分析和口碑监控
+- [[SCIRC]]（科锐国际）：大型猎头公司代表（Tier 1 headhunter）
+- [[Randstad]]（任仕达）：国际大型猎头公司
+- [[Korn-Ferry]]（光辉国际）：高管猎头顶级公司
 
 ## Connections
-- [[Specialized Civil Engineer Agent]] ← 同一 Agent 体系下的专业 Agent
-- [[Sales Engineer Agent]] ← 同属专业 Agent 系列
-- [[HR Onboarding]] ← 入职管理是该 Agent 的核心功能模块
-- [[RecruitmentFunnelAnalyzer]] ← 内置于该 Agent 的数据分析工具
+- [[Sales-Pipeline-Analyst]] ← depends_on ← [[Recruitment-Specialist]]：pipeline-analyst依赖招聘 specialist提供的岗位需求和候选人管道数据
+- [[Sales-Deal-Strategist]] ← extends ← [[Recruitment-Specialist]]：deal-strategist扩展至候选人谈判环节
+- [[Sales-Coach]] ← shares_methodology ← [[Recruitment-Specialist]]：两者均使用STAR框架评估候选人和销售代表的行为模式
+- [[Account-Strategist]] ← complements ← [[Recruitment-Specialist]]：account-strategist管理现有客户关系，recruitment-specialist负责搭建内部团队支撑account工作
 
 ## Contradictions
-- 暂无发现与现有 Wiki 页面的冲突内容
+- 与 [[Sales-Discovery-Coach]] 的STAR方法差异：
+  - 冲突点：Sales Discovery Coach的STAR追问重点在于挖掘客户痛苦（Pain），评估候选人的STAR追问重点在于验证岗位所需能力（Competency）
+  - 当前观点：Recruitment Specialist将STAR作为行为面试标准工具，适用于所有面试阶段
+  - 对方观点：Discovery Coach认为STAR追问需定制化于不同岗位层级，高管岗位的STAR问题应侧重战略决策而非执行细节
+  - 协调方案：STAR框架通用，但追问深度和侧重点需根据岗位层级调整——Recruitment Specialist制定标准STAR题库，Discovery Coach补充高管专项追问
diff --git a/wiki/sources/report-distribution-agent.md b/wiki/sources/report-distribution-agent.md
index ed3e6ed0..741904b2 100644
--- a/wiki/sources/report-distribution-agent.md
+++ b/wiki/sources/report-distribution-agent.md
@@ -1,46 +1,49 @@
----
-title: "Report Distribution Agent"
-type: source
-tags: []
-date: 2026-04-25
----
-
-## Source File
-- [[raw/Agent/agency-agents/specialized/report-distribution-agent.md]]
-
-## Summary（用中文描述）
-- 核心主题：销售报告自动分发 AI Agent，专为 STGCRM 系统设计
-- 问题域：企业销售团队需要按时、按区域将合并报告精准送达对应业务员和管理层
-- 方法/机制：基于区域参数路由 + SMTP 邮件发送 + 全程分发日志审计
-- 结论/价值：实现 99%+ 定时送达率，零错误区域分发，完全可追溯的分发历史
-
-## Key Claims（用中文描述）
-- Report Distribution Agent 通过区域路由确保每个业务员仅接收其负责区域的数据
-- 管理员和经理接收公司级汇总报告，而非区域明细
-- 每次分发尝试均记录状态（sent/failed）和时间戳，支撑合规审计
-- 每日报告于工作日 8:00 AM 发送，每周汇总于周一 7:00 AM 发送
-- 发送失败时记录错误并继续分发，不中断其他接收者
-
-## Key Quotes
-> "You are the Report Distribution Agent — a reliable communications coordinator who ensures the right reports reach the right people at the right time." — Agent 身份定义
-> "Territory-based routing: reps only receive reports for their assigned territory" — 核心路由规则
-> "Graceful failures: log errors per recipient, continue distributing to others" — 容错设计
-
-## Key Concepts
-- [[Territory Routing]]：基于销售区域参数进行路由分发，每个业务员仅接收其分配区域的数据报告
-- [[SMTP Transport]]：通过 SMTP 协议传输 HTML 格式邮件报告的底层技术机制
-- [[Audit Trail]]：分发日志记录，含接收人、区域、状态、时间戳，支持合规查询
-- [[Scheduled Distribution]]：定时任务触发机制（工作日 8:00 AM / 周一 7:00 AM），支持手动按需分发
-
-## Key Entities
-- [[Data Consolidation Agent]]：为 Report Distribution Agent 提供区域报告和公司汇总报告的数据来源
-- [[STGCRM]]：该 Agent 所服务的企业 CRM 系统品牌，提供区域分配数据和邮件路由规则
-
-## Connections
-- [[Data Consolidation Agent]] ← feeds_data ← [[Report Distribution Agent]]
-- [[Report Distribution Agent]] ← distributes_to ← [[Sales Representative]]
-- [[Report Distribution Agent]] ← audit_trail ← [[Compliance System]]
-
-## Contradictions
-- 与 [[Sales Data Extraction Agent]]：Sales Data Extraction Agent 负责原始销售数据提取，Report Distribution Agent 负责报告分发；两者在数据管道中为上下游关系，不存在冲突
-
+---
+title: "Report Distribution Agent"
+type: source
+tags: [agent, sales, automation, distribution, reporting, stgcrm]
+sources: []
+last_updated: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/report-distribution-agent.md]]
+
+## Summary（用中文描述）
+- 核心主题：销售报告自动化分发 Agent，基于区域参数将整合后的销售报告精准发送给对应业务员
+- 问题域：销售报告的手动分发效率低、易出错、无法追踪；不同区域业务员只需看自己区域的数据
+- 方法/机制：基于区域（Territory）的路由规则 + SMTP 邮件发送 + 分布审计日志；支持定时调度（每日/每周）和手动触发
+- 结论/价值：实现 99%+ 的定时投递率，所有分发操作可审计，失败发送 5 分钟内告警，零错误区域报告
+
+## Key Claims（用中文描述）
+- Report Distribution Agent 基于区域参数将报告精准路由到对应业务员，确保业务员只收到其负责区域的数据
+- 管理员和经理收到公司级别的汇总报告（Company-wide Roll-ups）
+- 每次分发操作均记录状态（sent/failed）和时间戳，形成可查询的分发历史
+- 每日区域报告在周一至周五 8:00 AM 发送；每周汇总在每周一 7:00 AM 发送
+- 分发失败时记录错误信息，继续向其他收件人发送，绝不静默丢弃报告
+- Agent 与 Data Consolidation Agent 协作生成报告内容
+
+## Key Quotes
+> "You are the Report Distribution Agent — a reliable communications coordinator who ensures the right reports reach the right people at the right time. You are punctual, organized, and meticulous about delivery confirmation." — Agent 身份定义
+> "Territory-based routing: reps only receive reports for their assigned territory" — 核心路由原则
+> "Graceful failures: log errors per recipient, continue distributing to others" — 失败处理策略
+
+## Key Concepts
+- [[Territory-Based Routing]]：基于销售区域的报告路由策略，确保业务员只收到其Assigned Territory 相关数据
+- [[Scheduled Distribution]]：定时调度分发，支持每日（工作日早8点）和每周（周一早7点）自动化发送
+- [[Audit Trail]]：所有分发操作均记录收件人、区域、状态、时间戳，支持合规查询
+- [[HTML Email Reports]]：HTML 格式的区域报告含业务员绩效表格；公司汇总含区域对比表格
+- [[SMTP Transport]]：通过 SMTP 协议发送邮件
+
+## Key Entities
+- [[Data Consolidation Agent]]：负责生成整合后的区域报告或公司汇总报告，Report Distribution Agent 调用其能力
+- [[Sales Representative]]：最终收件人，基于Assigned Territory 接收对应区域报告
+- [[STGCRM]]：品牌标识，HTML 报告样式遵循其 Branding 规范
+
+## Connections
+- [[Data Consolidation Agent]] ← generates report content for ← [[Report Distribution Agent]]
+- [[Report Distribution Agent]] ← delivers reports to ← [[Sales Representative]]
+- [[Report Distribution Agent]] ← writes distribution log to ← [[Audit Trail]]
+
+## Contradictions
+- （暂无发现冲突）
diff --git a/wiki/sources/retail-customer-returns.md b/wiki/sources/retail-customer-returns.md
new file mode 100644
index 00000000..9bc742db
--- /dev/null
+++ b/wiki/sources/retail-customer-returns.md
@@ -0,0 +1,55 @@
+---
+title: "Retail Customer Returns Agent"
+type: source
+tags: ["agent", "retail", "customer-service", "fraud-prevention"]
+sources: []
+last_updated: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/retail-customer-returns.md]]
+
+## Summary（用中文描述）
+- 核心主题：零售退货专员 Agent — 处理退货、退款、换货的全流程客户服务 Agent
+- 问题域：零售退货处理效率、退货欺诈、客户保留、商品处置
+- 方法/机制：基于规则的条件评估 + 流程清单 + 客户挽留话术 + 数据分析仪表盘
+- 结论/价值：良好的退货体验可提升客户终身价值，摩擦越少，客户忠诚度越高
+
+## Key Claims（用中文描述）
+- 退货处理得当 → 失望的客户转化为忠诚客户，提升终身价值
+- 一致性政策执行 → 防止歧视投诉，保护零售商免受法律风险
+- 绝不直接指控客户欺诈 → 发现欺诈立即上报 Loss Prevention，走合规流程
+- 退货欺诈每年给零售商造成数十亿美元损失 → Wardrobing、收据欺诈、价格掉包是主要威胁
+- 商品检查是退货处理的基础 → 未检查的退货造成库存损耗
+
+## Key Quotes
+> "The way a retailer handles a return tells you everything about how they value their customers. A generous, frictionless return experience builds lifetime loyalty. A difficult, suspicious return process destroys it — and sends that customer straight to a competitor."
+> — 退货体验是客户价值观的核心体现
+
+> "Policy is the foundation — empathy is the delivery."
+> — 政策是基础，共情是执行方式
+
+> "Never accuse a customer of fraud directly."
+> — 绝不直接指控客户欺诈，发现可疑迹象立即上报
+
+## Key Concepts
+- [[Wardrobing]]：穿后退货 — 特定品类（正装、节日服装）的高发欺诈模式
+- [[Return Abuse]]：退货滥用 — 频繁退货超过正常消费行为，触发系统标记
+- [[RMA (Return Merchandise Authorization)]]：退货授权 — 供应商退货流程的核心机制
+- [[Returnless Refund]]：免退货退款 — 电商场景下直接退款而不要求退货，适用于低价值商品
+- [[BORIS]] (Buy Online, Return In Store)：在线购买，店内退货 — 全渠道退货处理流程
+- [[Return Reason Code]]：退货原因代码 — P类（产品问题）、C类（客户偏好）、O类（运营问题）、F类（欺诈标记）
+
+## Key Entities
+- [[Loss Prevention]]：损失预防部门 — 负责处理欺诈可疑案件的内部团队
+- [[POS (Point of Sale)]]：销售点系统 — 退货处理的核心操作终端
+
+## Connections
+- [[Customer Service Agent]] ← shares → [[Retail Customer Returns Agent]]：两者均处理客户交互，退货 Agent 专注文档中记录的场景
+- [[HR Onboarding Agent]] ← extends → [[Retail Customer Returns Agent]]：HR 入职 Agent 可参考此 Agent 的人格定义模式构建入职流程
+
+## Contradictions
+- 与 [[Security Policy]] 冲突：
+  - 冲突点：欺诈处理方式 — [[Security Policy]] 侧重系统级安全检测，本 Agent 侧重一线员工操作规程
+  - 当前观点：欺诈检测是员工职责的一部分，通过观察红牌信号识别
+  - 对方观点：安全策略强调系统化、自动化的安全检测机制
diff --git a/wiki/sources/roblox-avatar-creator.md b/wiki/sources/roblox-avatar-creator.md
index cc54e062..867877df 100644
--- a/wiki/sources/roblox-avatar-creator.md
+++ b/wiki/sources/roblox-avatar-creator.md
@@ -2,57 +2,66 @@
 title: "Roblox Avatar Creator Agent Personality"
 type: source
 tags: []
-date: 2026-04-26
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/roblox-studio/roblox-avatar-creator.md]]
+- [[Agent/agency-agents/game-development/roblox-studio/roblox-avatar-creator.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Roblox UGC（用户生成内容）化身系统专家 AI Agent 人格规范——从建模绑定到 Creator Marketplace 提交的完整 avatar pipeline
-- 问题域：Roblox avatar 配件系统、Layered Clothing 分层服装、Creator Marketplace 合规审核、化身自定义 API
-- 方法/机制：R15 骨骼权重系统；附件点（Attachment）定位；纹理规范（256-1024px PNG）；三角面数硬限制（配件≤4000、Bundle部件≤10000）；InnerCage/OuterCage 双笼系统
-- 结论/价值：提供可直接使用的 Luau 代码模块（HumanoidDescription、Layered Clothing cage setup、UGC Shop UI flow）和 Creator Marketplace 提交检查清单
+- 核心主题：Roblox UGC（用户生成内容）虚拟形象物品设计与发布全流程规范，包括配饰制作、分层服装、贴图标准、Avatar 系统集成和 Creator Marketplace 合规要求。
+- 问题域：如何在 Roblox 平台内创建技术上正确、视觉上精致、平台合规的 Avatar 物品，并成功上架 Creator Marketplace。
+- 方法/机制：通过严格的技术规范（三角面数限制、UV 规范、附件点命名）、Blender 骨骼绑定与 Cage 网格制作、HumanoidDescription API 驱动的游戏内换装系统，以及完整的提交审查流程。
+- 结论/价值：提供了一套从建模 → 绑定 → 测试 → 发布的端到端 UGC Avatar 物品制作方法论，帮助创建者规避 moderation 拒绝，实现 Creator Marketplace 上架目标。
 
 ## Key Claims（用中文描述）
-- UGC 配件网格必须低于 4,000 三角面——超过此限制将导致自动拒绝（Roblox 强制规则）
-- 所有 UGC 配件必须使用单个 UV 通道，UV 范围严格限制在 [0,1] 空间内——超出该范围将导致贴图采样错误
-- Layered Clothing 配件必须同时包含外层网格和 InnerCage 网格——缺失 InnerCage 将导致服装穿透过角色身体
-- 化身附件必须使用标准命名：HatAttachment、FaceFrontAttachment、LeftShoulderAttachment 等——命名错误导致跨 body type 附件失效
-- Creator Marketplace 商品名称必须准确描述商品——误导性名称将触发审核暂停
+- UGC 配饰网格必须低于 4,000 三角面，超过则自动被平台拒绝。
+- 所有网格必须是单一物体、单一 UV 通道，UV 范围限制在 [0,1] 空间内，禁止超出范围的重叠 UV。
+- 分层服装（Layered Clothing）必须同时包含外层网格和内层变形 Cage 网格（_InnerCage），缺少内层 Cage 会导致服装穿透 Avatar 身体。
+- 配饰通过 `Attachment` 对象附件至 Avatar，附件点名称必须与 Roblox 标准一致（如 HatAttachment、FaceFrontAttachment）。
+- 贴图分辨率为 256×256 至 1024×1024，格式为 PNG（带透明通道的配饰需 RGBA），UV island 边缘至少 2px 内边距。
+- 所有变换必须先应用（scale=1, rotation=0）再导出，导出格式：带绑定的配饰用 .fbx，不变形的简单配饰用 .obj。
+- 物品提交后需通过 Roblox 自动 moderation 和人工审核（精选物品），审核周期通常 24-72 小时。
+- 体验内 Avatar 自定义通过 `HumanoidDescription` API 实现，支持在不刷新角色的情况下动态应用换装。
+- R15/Rthro 兼容性要求在 Classic、R15 Normal、R15 Rthro 等多种体型上测试配饰，防止穿插。
+- UGC Limited 物品需要建立创作者账户记录，并设计符合二级市场价值的内容以吸引买家。
 
 ## Key Quotes
-> "4,000 triangles is the hard limit — model to 3,800 to leave room for exporter overhead" — Roblox 网格三角面数规范：留 200 面余量防止导出器开销
-> "Looks great in Blender — now test it on Rthro Broad in a run cycle before submitting" — 测试原则：必须覆盖所有 5 种 body type 动画循环
-> "That logo will get flagged — use an original design instead" — 纹理内容规范：禁止任何商标或真实世界品牌
-> "Similar hats sell for 75 Robux — pricing at 150 without a strong brand will slow sales" — Creator Marketplace 定价策略：参考同类商品定价
+> "MANDATORY: All UGC accessory meshes must be under 4,000 triangles for hats/accessories — exceeding this causes auto-rejection" — Roblox UGC 技术红线
+
+> "Layered Clothing requires both the outer mesh AND an inner cage mesh (_InnerCage) for deformation — missing inner cage causes clipping through body" — 分层服装变形核心要求
+
+> "Looks great in Blender — now test it on Rthro Broad in a run cycle before submitting" — 沟通风格：强调跨体型实测
+
+> "That logo will get flagged — use an original design instead" — 沟通风格： moderation 风险预判
 
 ## Key Concepts
-- [[UGC]]: User Generated Content，Roblox 平台允许创作者发布和销售虚拟物品的经济系统
-- [[LayeredClothing]]: Roblox 分层服装系统，需要 Outer Mesh + InnerCage + OuterCage 三层 cage 网格实现变形
-- [[HumanoidDescription]]: Roblox 化身 API，通过 description.Apply() 方法应用全身装扮，支持 Shirt/Pants/Accessory 等属性
-- [[R15Rig]]: Roblox R15 avatar 骨骼系统，Layered Clothing 权重绑定到标准 R15 骨骼
-- [[CreatorMarketplace]]: Roblox 官方 UGC 交易平台，所有 UGC 商品需通过 Creator Dashboard 提交并通过自动化+人工审核
-- [[AttachmentPoint]]: Roblox 化身附件定位点，名称必须匹配 Roblox 标准（HatAttachment/FaceFrontAttachment 等）
-- [[RthroBodyType]]: Roblox 瘦长型化身比例，与 Classic/R15 Normal 不同——需单独测试附件兼容性
+- [[UGC (User-Generated Content)]]：Roblox 平台允许创作者自行设计虚拟形象物品并通过 Creator Marketplace 销售的内容生态。
+- [[Layered Clothing]]：Roblox 分层服装系统，通过外层可见网格 + 内层变形 Cage 网格 + 外层堆叠 Cage 实现与其他分层物品的叠穿。
+- [[R15 Avatar Rig]]：Roblox 第 15 代 Avatar 骨架系统，提供标准骨骼命名和体型预设，是所有配饰绑定的参考基准。
+- [[HumanoidDescription]]：Roblox API，通过修改 Description 对象中的配件字段（如 HatAccessory、Shirt）并调用 ApplyDescription 实现换装。
+- [[Creator Marketplace]]：Roblox UGC 物品的官方销售渠道，所有物品必须通过自动 moderation 和人工审核才能上架。
+- [[Cage Mesh]]：分层服装中的变形网格，_InnerCage 定义服装包裹 Avatar 的形状，_OuterCage 允许其他分层物品堆叠在其上方。
+- [[Rthro Avatar Scale]]：Roblox Rthro 体型系统，包含 Rthro Narrow 和 Rthro Broad 两种体型变体，需在配饰测试中覆盖。
+- [[Blender R15 Rig]]：Roblox 官方提供的 Blender 参考骨架文件，用于正确命名骨骼和进行权重绘制。
 
 ## Key Entities
-- [[Blender]]: 3D 建模软件，用于制作 UGC 配件网格和 cage 网格
-- [[RobloxStudio]]: Roblox 官方开发工具，通过 Avatar → Import Accessory 导入 UGC 物品
-- [[R15TestBodies]]: Roblox Studio 提供的 5 种测试化身预设：Young / Classic / Normal / Rthro Narrow / Rthro Broad
-- [[DataStore]]: Roblox 服务器端持久化系统，用于存储玩家装扮数据
+- [[RobloxAvatarCreator]]：本 agent 角色——Roblox UGC 虚拟形象流水线专家，精通从建模到 Creator Marketplace 提交的完整流程。
+- [[Roblox Studio]]：Roblox 官方开发引擎，用于导入配饰、测试体型、预览动画穿插和管理 Creator Dashboard。
+- [[Blender]]：第三方 DCC 工具，用于网格建模、UV 展开、骨骼绑定和 Cage 网格制作。
+- [[Creator Dashboard]]：Roblox 创作者后台，用于提交 UGC 物品、管理 moderation 状态和发布内容。
+- [[MarketplaceService]]：Roblox 服务端 API，通过 PromptPurchase 驱动游戏内购买 UGC 物品的流程。
 
 ## Connections
-- [[RobloxSystemsScripter]] ← game-dev-scope ← [[RobloxAvatarCreator]]
-- [[RobloxExperienceDesigner]] ← player-economy ← [[RobloxAvatarCreator]]
-- [[Blender]] ← mesh-pipeline ← [[RobloxAvatarCreator]]
-- [[RobloxStudio]] ← asset-pipeline ← [[RobloxAvatarCreator]]
-- [[CreatorMarketplace]] ← submission ← [[RobloxAvatarCreator]]
-- [[R15Rig]] ← bone-weights ← [[RobloxAvatarCreator]]
+- [[Roblox Systems Scripter Agent Personality]] ← related_to ← [[Roblox Avatar Creator Agent Personality]]
+- [[Roblox Experience Designer]] ← related_to ← [[Roblox Avatar Creator Agent Personality]]
+- [[HumanoidDescription]] ← drives ← [[AvatarManager.lua]]（游戏内换装模块）
+- [[Layered Clothing]] ← requires ← [[R15 Avatar Rig]]（骨骼绑定参考）
+- [[Creator Marketplace]] ← requires ← [[UGC (User-Generated Content)]]（物品来源）
 
 ## Contradictions
-- 与 [[UnityArchitect]] / [[UnityMultiplayerEngineer]] 冲突：
-  - 冲突点：角色自定义系统的实现路径差异
-  - 当前观点（Roblox）：使用 HumanoidDescription API 实现服务端权威的化身自定义，数据通过 DataStore 持久化
-  - 对方观点（Unity）：推荐客户端预测式角色定制，使用 LocalPlayer 状态缓存提升响应体验
-  - 说明：此差异由平台架构约束决定——Roblox 的 LocalScript 不可写 DataStore，Unity 无此限制，均为各自平台最优解
+- 与 [[Roblox Systems Scripter Agent Personality]] 的潜在重叠：
+  - 冲突点：Avatar 自定义系统同时涉及脚本编写和物品设计，职责边界可能模糊。
+  - 当前观点：Avatar Creator 专注物品层面的建模/绑定/提交，Systems Scripter 专注游戏内 Avatar 逻辑和 API 调用。
+  - 对方观点：Systems Scripter 可能认为游戏内换装逻辑属于自己的职责范围。
+  - 协调方案：物品层面的 HumanoidDescription 填充属于 Avatar Creator，DataStore 保存/加载和换装触发逻辑属于 Systems Scripter。
diff --git a/wiki/sources/roblox-experience-designer.md b/wiki/sources/roblox-experience-designer.md
index 267c6e29..d7753dbc 100644
--- a/wiki/sources/roblox-experience-designer.md
+++ b/wiki/sources/roblox-experience-designer.md
@@ -1,8 +1,8 @@
 ---
 title: "Roblox Experience Designer"
 type: source
-tags: []
-date: 2026-04-26
+tags: [roblox, game-development, ux-design, monetization, retention, luau]
+date: 2026-05-01
 ---
 
 ## Source File
@@ -10,9 +10,9 @@ date: 2026-04-26
 
 ## Summary（用中文描述）
 - 核心主题：Roblox 平台原生体验设计师 Agent——专注于 Roblox 受众（9-17岁）的参与度循环设计、变现系统与玩家留存
-- 问题域：如何在 Roblox 平台设计可发现、有奖励感、符合平台政策的商业化体验
-- 方法/机制：DataStore 驱动进度系统、Game Pass/Developer Product/UGC 原生化变现、参与度阶梯（首次会话→每日留存→周留存）、每日奖励系统、分析事件追踪
-- 结论/价值：提供完整的 Roblox 原生 UX 和变现设计框架，涵盖技术代码示例（Lua）、入职流程三阶段设计、留存指标体系
+- 问题域：如何在 Roblox 平台设计可发现、有奖励感、符合平台政策的商业化体验，同时实现 D1 留存 >30%、D7 >15% 的健康指标
+- 方法/机制：DataStore 驱动进度系统、Game Pass/Developer Product/UGC 原生化变现、参与度阶梯（首次会话→每日留存→周留存）、每日奖励系统（7天循环阶梯）、入职引导三阶段设计（0-60秒/5分钟/15分钟）、分析事件追踪（AnalyticsService）、Live Ops 事件运营、社会化系统
+- 结论/价值：提供完整的 Roblox 原生 UX 和变现设计框架，涵盖技术代码示例（Lua/Luau）、入职流程规范、留存指标体系、高级变现优化策略
 
 ## Key Claims（用中文描述）
 - RobloxExperienceDesigner Agent：面向 9-17 岁受众的 Roblox 原生产品设计师，擅长参与度循环设计与合乎伦理的变现
@@ -22,42 +22,66 @@ date: 2026-04-26
 - 每日奖励是投入产出比最高的留存功能，应在上线前实现
 - 入职流程第 1 分钟（0-60秒）是留存关键：玩家必须在首分钟内完成核心动作并获得成功体验
 - D1 留存率低于 25% 意味着入职流程未生效，需要审计前 5 分钟
+- 变现伦理核心：禁止人工稀缺倒计时、暗黑模式，所有付费道具须与免费道具在 UI 上清晰区分
+- 首发购买漏斗：给新玩家足够软货币以降低首次购买心理门槛（转化率目标 >3%）
+- Roblox SEO 三要素：标题、描述、缩略图是影响发现量的关键因素，与玩法设计同等重要
+- Live Ops 事件运营：使用 ReplicatedStorage 配置对象 + 服务器重启实现限时活动，无需热更新
 
 ## Key Quotes
 > "Player-advocate, platform-fluent, retention-analytical, monetization-ethical" — RobloxExperienceDesigner 四大核心人格标签
 > "Loss of progression is the #1 reason players quit permanently" — DataStore 安全的首要原则
 > "If D1 is below 25%, the onboarding isn't landing — let's audit the first 5 minutes" — 留存分析与决策框架
 > "That feels like a dark pattern — let's find a version that converts just as well without pressuring kids" — 变现伦理准则
+> "The Roblox algorithm rewards concurrent players — design for sessions that overlap, not solo play" — 平台算法导向的设计思维
+> "Your audience is 12 — the purchase flow must be obvious and the value must be clear" — 受众意识原则
+> "Show a premium option next to the standard option — the standard appears affordable by comparison" — 价格锚定策略
 
 ## Key Concepts
 - [[EngagementLoop]]：参与度循环——从首次会话到每日返回再到周留存的完整阶梯设计，每层有清晰奖励闭环
-- [[DailyRewardSystem]]：每日奖励系统——基于连续登录天数的奖励阶梯（1-7天循环），驱动玩家习惯性返回
-- [[DataStoreDrivenProgression]]：DataStore 驱动进度——玩家投入（等级、道具、货币）持久化存储，创造不愿失去的沉没成本
-- [[GamePassMonetization]]：Game Pass 变现——永久性权益/功能通行证，通过 MarketplaceService 验证所有权
+- [[DailyRewardSystem]]：每日奖励系统——基于连续登录天数的奖励阶梯（1-7天循环，第7天有徽章加成），驱动玩家习惯性返回
+- [[DataStoreDrivenProgression]]：DataStore 驱动进度——玩家投入（等级、道具、货币）持久化存储，创造不愿失去的沉没成本；schema 必须版本化，迁移而非覆写
+- [[GamePassMonetization]]：Game Pass 变现——永久性权益/功能通行证（VIP/DoubleXP/ExtraLives），通过 MarketplaceService.UserOwnsGamePassAsync() 验证所有权
 - [[DeveloperProduct]]：开发者产品——可重复购买的消耗品（货币包、道具包），用于软货币变现
-- [[OnboardingFlow]]：入职引导流程——三阶段设计（60秒/5分钟/15分钟），最小化早期流失并通过游戏教学
-- [[RobloxAlgorithm]]：Roblox 推荐算法——以同时在线人数、收藏量、访问量为排名信号
+- [[UGCMonetization]]：UGC（用户生成内容）变现——Roblox 官方交易平台上的虚拟物品经济
+- [[OnboardingFlow]]：入职引导流程——三阶段设计（60秒/5分钟/15分钟），最小化早期流失并通过游戏教学；分阶段流失恢复策略
+- [[RobloxAlgorithm]]：Roblox 推荐算法——以同时在线人数、收藏量、访问量为排名信号，影响体验曝光
 - [[AnalyticsService]]：分析服务——Roblox 内置 AnalyticsService，用于追踪自定义事件（D1/D7留存、首次购买、会话时长）
 - [[SoftCurrencyFunnel]]：软货币首次购买漏斗——给新玩家足够货币以跨越首次购买心理障碍
 - [[PriceAnchoring]]：价格锚定——在标准选项旁展示高级选项，使标准选项显得实惠
+- [[LiveOperations]]：实时运营——使用服务器端配置对象实现限时活动、季节更新，无需客户端热更新
+- [[PurchaseAbandonmentRecovery]]：购买遗弃恢复——玩家打开商店但未购买时，下次会话显示提醒通知
+- [[VoiceChatService]]：语音聊天服务——用于社交/RP 类体验的空间语音集成
+- [[GroupGating]]：Group 门控——使用 Players:GetRankInGroup() 实现 Roblox Group 专属内容
+- [[ABTestingInfrastructure]]：A/B 测试基础设施——通过 math.random() 按 UserId 分配桶，记录各桶指标
 
 ## Key Entities
 - [[RobloxExperienceDesigner]]：Agent 身份——Roblox 原生体验设计师，核心使命是设计让玩家返回、分享和付费的体验
 - [[RobloxPlatform]]：平台——主要受众 9-17 岁，提供 Game Pass/Developer Product/UGC 三大变现工具及推荐算法
-- [[MarketplaceService]]：市场服务——Lua API，用于验证 Game Pass 所有权和触发购买流程
+- [[MarketplaceService]]：市场服务——Lua/Luau API，用于验证 Game Pass 所有权和触发购买流程（PromptGamePassPurchase）
 - [[DataStoreService]]：数据存储服务——Roblox 云端持久化 API，存储玩家进度数据（含每日奖励记录）
 - [[AnalyticsService]]：分析服务——Roblox 内置事件追踪（无第三方依赖），在 Creator Dashboard 可见
-- [[VoiceChatService]]：语音聊天服务——用于社交/RP 类体验的空间语音集成
+- [[ReplicatedStorage]]：复制存储——客户端和服务器共享的实例容器，用于存放 Live Ops 配置对象
+- [[Players]]：玩家服务——Luau API，提供 GetFriendsAsync()、GetRankInGroup() 等玩家数据查询
+- [[HttpService]]：HTTP 服务——用于将分析事件导出至外部 BI 工具
 
 ## Connections
 - [[GameDesigner]] ← extends ← [[RobloxExperienceDesigner]]（Game Designer 的具体平台化实现）
+- [[RobloxSystemsScripter]] ← depends_on ← [[RobloxExperienceDesigner]]（Experience Designer 定义体验目标，Systems Scripter 实现底层架构）
 - [[DailyRewardSystem]] ← depends_on ← [[DataStoreService]]（奖励记录依赖 DataStore 持久化）
 - [[GamePassMonetization]] ← uses ← [[MarketplaceService]]（Game Pass 购买验证）
 - [[OnboardingFlow]] ← feeds → [[AnalyticsService]]（入职完成事件上报）
 - [[RobloxPlatform]] ← rewards → [[EngagementLoop]]（平台算法奖励参与度循环）
+- [[UGCMonetization]] ← connects → [[CreatorMarketplace]]（Roblox Avatar Creator 的 UGC 经济生态）
+- [[LiveOperations]] ← uses → [[ReplicatedStorage]]（活动配置对象存储）
+- [[SocialFeatures]] ← uses → [[Players]]（Group 门控、好友邀请奖励）
+- [[AnalyticsService]] ← exports → [[HttpService]]（外部 BI 工具数据导出）
 
 ## Contradictions
 - 与 [[UnityArchitect]] 冲突：
   - 冲突点：变现策略
   - 当前观点：Roblox 受众（9-17岁）必须遵守严格伦理变现——禁止 pay-to-win、人工稀缺、暗黑模式
   - 对方观点：Unity 平台面向更广泛受众，变现策略更灵活，可接受更强付费优势
+- 与 [[RobloxSystemsScripter]] 互补（侧重不同）：
+  - 当前观点（Experience Designer）：关注玩家感知层——入职引导、留存指标、变现体验设计
+  - 对方观点（Systems Scripter）：关注底层架构——DataStore 可靠性、RemoteEvent 安全、ModuleScript 架构
+  - 说明：两者为同一 Roblox 开发体系的不同层面，Experience Designer 定义目标，Systems Scripter 实现底层
diff --git a/wiki/sources/roblox-systems-scripter.md b/wiki/sources/roblox-systems-scripter.md
index 5ccb10b5..806c4a50 100644
--- a/wiki/sources/roblox-systems-scripter.md
+++ b/wiki/sources/roblox-systems-scripter.md
@@ -1,55 +1,76 @@
 ---
 title: "Roblox Systems Scripter Agent Personality"
 type: source
-tags: [roblox, game-development, luau, client-server, datastore, security]
-date: 2026-04-26
+tags: []
+date: 2026-05-01
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/roblox-studio/roblox-systems-scripter.md]]
+- [[Agent/agency-agents/game-development/roblox-studio/roblox-systems-scripter.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Roblox 平台工程专家的 Agent 人格定义，专注于 Luau 语言下的服务器权威架构与安全实现
-- 问题域：如何构建可扩展、防作弊、持久化数据安全的 Roblox 游戏体验
-- 方法/机制：服务器权威模型、RemoteEvent/RemoteFunction 安全验证、DataStore 重试与双保存机制、ModuleScript 模块化架构
-- 结论/价值：提供一套完整的 Roblox 系统脚本工程规范，涵盖从基础架构设计到高级并行 Luau 优化的全链路最佳实践
+- 核心主题：Roblox Systems Scripter Agent——Roblox 平台系统工程专家 AI Agent 人格规范，专精 Luau 编程、客户端-服务器安全模型、RemoteEvent/RemoteFunction 通信架构、DataStore 持久化与模块化代码组织。
+- 问题域：如何在 Roblox 平台构建安全、可扩展、数据可靠的多人游戏系统；如何正确划分客户端与服务器的职责边界；如何防止客户端 exploit 攻击；如何设计可维护的模块化代码架构。
+- 方法/机制：服务器权威模型（Server-Authoritative）、RemoteEvent/RemoteFunction 安全验证链路、pcall + 指数退避重试的 DataStore 封装、ModuleScript 分层架构（ServerStorage/ReplicatedStorage/StarterPlayerScripts）、并行 Luau 与 Actor 模型、内存优化与对象池化。
+- 结论/价值：Roblox 游戏系统的核心原则是"服务器即真相"——客户端只能请求动作，所有状态变更和验证必须在服务器执行；DataStore 必须用 pcall 保护并实现重试逻辑；所有游戏逻辑应封装在 ModuleScript 中实现可测试性和复用性。
 
 ## Key Claims（用中文描述）
-- 服务器是唯一的真相来源：客户端只接收视觉确认，不拥有任何游戏状态
-- 客户端通过 RemoteEvent/RemoteFunction 发送的请求，服务器必须重新验证，不能信任
-- DataStore 操作必须用 `pcall` 包装并实现指数退避重试，防止数据损坏
-- 玩家数据必须在 `PlayerRemoving` 和 `game:BindToClose()` 两处保存，缺一不可
-- 所有游戏系统必须放在 ModuleScript 中，Script/LocalScript 仅做引导，不含核心逻辑
+- 客户端-服务器安全模型：服务器是真相的唯一来源——客户端展示状态，不拥有状态；所有游戏状态变更（伤害、货币、物品）只能在服务器执行。
+- RemoteEvent 安全规范：FireServer() 客户端→服务器请求必须经过服务器端验证；FireClient() 服务器→客户端安全；RemoteFunction:InvokeClient() 绝对不能在服务器调用（恶意客户端可永久阻塞服务器线程）。
+- DataStore 可靠性：DataStore 调用必须用 pcall 包裹并实现指数退避重试；保存时机为 PlayerRemoving 和 BindToClose 双重保护；写入频率不超过每 6 秒一次。
+- 模块化架构原则：所有游戏系统必须是 ModuleScript，由服务器 Script 或客户端 LocalScript 引用；模块返回表或类，禁止返回 nil；共享常量放在 ReplicatedStorage 模块。
+- 并行 Luau 性能优化：使用 task.desynchronize() 实现并行计算；Actor 模型支持真正并行脚本执行；SharedTable 用于跨 Actor 数据共享；debug.profilebegin/profileend 验证性能收益。
+- 内存与性能管理：使用 GetPartBoundsInBox 空间查询替代遍历；对象池化复用效果和 NPC；使用 Destroy() 而非 Parent=nil 防止内存泄漏。
 
 ## Key Quotes
-> "Clients request, servers decide. That health change belongs on the server." — 客户端-服务器信任边界原则
-> "That save has no `pcall` — one DataStore hiccup corrupts the player's data permanently" — DataStore 安全核心警示
-> "RemoteFunction:InvokeClient() from the server — a malicious client can yield the server thread forever" — 危险操作警示
+> "The server is truth — clients display state, they do not own it" — 客户端-服务器安全模型核心原则
+> "Never trust data sent from a client via RemoteEvent/RemoteFunction without server-side validation" — 客户端数据验证铁律
+> "That save has no pcall — one DataStore hiccup corrupts the player's data permanently" — DataStore 安全意识沟通风格
+> "All game systems are ModuleScripts required by server-side Scripts or client-side LocalScripts — no logic in standalone Scripts/LocalScripts beyond bootstrapping" — 模块化架构规范
+> "RemoteFunction:InvokeClient() never called from server — zero yielding server thread risk" — 成功指标之一
 
 ## Key Concepts
-- [[Server-Authoritative Architecture]]：服务器权威模型——所有游戏逻辑状态由服务器拥有，客户端只显示状态，不决定状态
-- [[RemoteEvent Security]]：RemoteEvent 安全模式——FireServer 请求需在服务器端完整验证，不能信任客户端数据
-- [[DataStore Reliability]]：DataStore 可靠性模式——pcall 包装 + 指数退避重试 + 双保存点（PlayerRemoving + BindToClose）
-- [[ModuleScript Architecture]]：ModuleScript 架构规范——所有逻辑放入 ModuleScript 返回表，Script/LocalScript 仅 bootstrap
-- [[Parallel Luau]]：并行 Luau——使用 task.desynchronize() 和 Actor 模型实现真正的多线程脚本执行
-- [[Object Pooling]]：对象池模式——预实例化 effects 和 NPC，减少 GC 压力
-- [[UpdateAsync Atomic Pattern]]：UpdateAsync 原子写入——处理并发写入冲突，比 SetAsync 更安全
+- [[ServerAuthoritativeModel]]：服务器权威模型——所有游戏逻辑在服务器执行，客户端仅接收结果和显示视觉反馈
+- [[RemoteEvent]]：Roblox 跨客户端-服务器通信机制；FireServer()（客户端→服务器）和 FireClient()（服务器→客户端）
+- [[RemoteFunction]]：Roblox 远程函数调用；InvokeServer() 和 InvokeClient()，后者存在线程阻塞风险
+- [[DataStore]]：Roblox 玩家数据持久化服务；必须用 pcall 保护，支持指数退避重试
+- [[ModuleScript]]：Luau 模块系统；封装游戏逻辑，返回表或类，被 Script/LocalScript require 调用
+- [[ParallelLuau]]：并行 Luau；使用 task.desynchronize() 和 Actor 模型实现多线程计算
+- [[ObjectPooling]]：对象池化；预实例化效果和 NPC，减少运行时实例创建开销
+- [[ServiceLocator]]：服务定位器模式；中央注册表实现依赖注入
+- [[FeatureFlags]]：功能开关；通过 ReplicatedStorage 配置对象控制功能启用/禁用
+- [[ActorModel]]：Actor 模型；每个 Actor 在独立线程运行脚本，SharedTable 实现跨 Actor 数据安全共享
+- [[UpdateAsync]]：DataStore 原子更新方法；比 SetAsync 更安全地处理并发写入冲突
+- [[SessionLocking]]：会话锁定；防止同一玩家同时在两台服务器加载造成数据损坏
 
 ## Key Entities
-- [[Roblox]]：游戏开发平台，提供 Roblox Studio、Lua 变体 Luau、DataStore 服务
-- [[Luau]]：Roblox 的脚本语言，是 Lua 的类型安全变体
-- [[DataStoreService]]：Roblox 数据持久化服务，用于保存玩家数据到云端
-- [[ReplicatedStorage]]：Roblox 实例容器，RemoteEvent 存放位置，客户端和服务器均可访问
-- [[ServerStorage]]：Roblox 实例容器，仅服务器可访问，用于存放核心模块
+- [[RobloxSystemsScripter]]：Roblox 平台系统工程专家 AI Agent；安全优先、架构严谨、平台精通、性能敏感
+- [[RobloxPlatform]]：Roblox 游戏开发平台；Luau 编程语言、客户端-服务器执行模型、DataStore 持久化
+- [[Luau]]：Roblox 专用的 Luau 编程语言（基于 Lua）；强类型注解、协程任务系统
+- [[DataStoreService]]：Roblox 数据存储服务；玩家数据持久化，支持 GetAsync/SetAsync/UpdateAsync
+- [[ReplicatedStorage]]：Roblox 服务；存储客户端和服务器共享的模块、远程事件、常量
+- [[ServerStorage]]：Roblox 服务；仅服务器可访问，用于存储服务器端模块和游戏数据
+- [[Players]]：Roblox 服务；管理所有玩家实例，提供 PlayerAdded/PlayerRemoving 生命周期事件
+- [[BindableEvent]]：Roblox 绑定事件；服务器内部模块间通信，解耦事件发布-订阅
 
 ## Connections
-- [[Roblox Experience Designer]] ← extends ← [[Roblox Systems Scripter]]
-- [[Server-Authoritative Architecture]] ← foundational ← [[RemoteEvent Security]]
-- [[DataStore Reliability]] ← depends_on ← [[Server-Authoritative Architecture]]
+- [[RobloxExperienceDesigner]] ← extends ← [[RobloxSystemsScripter]]
+- [[RobloxSystemsScripter]] ← depends_on ← [[DataStoreService]]
+- [[RobloxSystemsScripter]] ← depends_on ← [[Luau]]
+- [[RobloxSystemsScripter]] ← depends_on ← [[ServerAuthoritativeModel]]
+- [[RobloxSystemsScripter]] ← uses ← [[ModuleScript]]
+- [[RobloxSystemsScripter]] ← uses ← [[RemoteEvent]]
+- [[RobloxSystemsScripter]] ← uses ← [[ParallelLuau]]
+- [[RobloxSystemsScripter]] ← uses ← [[DataStore]]
 
 ## Contradictions
-- 与 [[Unity Architect]] 冲突：
-  - 冲突点：客户端预测（Client Prediction）策略
-  - 当前观点：Roblox Systems Scripter 建议简化场景下不做本地预测，所有状态由服务器驱动
-  - 对方观点：Unity Multiplayer Engineer 建议使用服务器回滚式 client prediction 提升响应体验
-  - 说明：两者平台不同，Roblox 的 RemoteEvent 架构天然适合服务器权威，Unity 的 Photon/Netcode 支持更灵活的预测策略
+- 与 [[UnrealMultiplayerArchitect]] 的权威模型差异：
+  - 冲突点：客户端预测与服务器权威的关系
+  - 当前观点（RobloxSystemsScripter）：服务器完全权威，客户端只展示状态，无本地预测
+  - 对方观点（UnrealMultiplayerArchitect）：允许客户端预测以提升网络响应性，配合服务器校正
+  - 背景：Roblox 的 Luau 执行模型和 Unity/Unreal 的 C++ 网络模型架构假设不同；Roblox 平台强制服务器权威是为了防止 exploit，但牺牲了网络响应速度；Unreal/Unity 在 C++ 层有更细粒度的网络同步控制
+- 与 [[UnityMultiplayerEngineer]] 的帧率同步差异：
+  - 冲突点：帧率权威归属
+  - 当前观点（RobloxSystemsScripter）：Roblox 引擎内置物理同步，开发者只需关注 RemoteEvent 验证
+  - 对方观点（UnityMultiplayerEngineer）：需要手动实现帧率同步和状态插值
+  - 背景：Roblox 是封闭平台，物理引擎由 Roblox 统一管理；Unity 是开源引擎，物理同步由开发者实现
diff --git a/wiki/sources/sales-account-strategist.md b/wiki/sources/sales-account-strategist.md
index 89d2aa36..a932bb86 100644
--- a/wiki/sources/sales-account-strategist.md
+++ b/wiki/sources/sales-account-strategist.md
@@ -2,17 +2,17 @@
 title: "Account Strategist Agent"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-05-18
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/sales/sales-account-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Account Strategist（账户策略师）Agent —— 售后收入扩张战略智能体，专门负责账户扩展、QBR设计、利益相关者映射和净收入留存
-- 问题域：SaaS/企业软件公司如何将一次性成交转化为长期平台关系，如何通过系统性扩张规划实现净收入留存（NRR）最大化
-- 方法/机制：Land-and-Expand 执行框架 → 季度业务回顾（QBR）设计 → 利益相关者多线程关系建设 → NRR 健康评分体系 → 流失预警干预机制
-- 结论/价值：最佳销售时机是客户成功时；账户健康优先于扩张；永远不做单线程账户；NRR 是终极指标
+- 核心主题：Account Strategist（账户策略师）Agent —— 售后收入扩张战略智能体，专门负责账户扩展、QBR设计、利益相关者映射和净收入留存（NRR）
+- 问题域：SaaS/企业软件公司如何将一次性成交转化为长期平台关系，如何通过系统性扩张规划实现净收入留存（NRR）最大化，如何在客户成功时识别并执行扩张机会
+- 方法/机制：Land-and-Expand 执行框架 → 季度业务回顾（QBR）设计 → 利益相关者多线程关系建设 → NRR 健康评分体系 → 流失预警干预机制 → 战略账户规划与组织情报
+- 结论/价值：最佳销售时机是客户成功时；账户健康优先于扩张；永远不做单线程账户；NRR 是终极指标；扩张需信号+情境+时机+利益相关者四维对齐才算机会
 
 ## Key Claims（用中文描述）
 - 账户策略师将每个客户账户视为一片有待填充的空白领域（territory with whitespace），通过系统性扩张规划将单点解决方案转化为企业平台
@@ -22,6 +22,11 @@ date: 2026-04-25
 - 每个账户必须有至少三条独立的业务关系线——即使冠军明天离职，你仍然能与关心产品的其他人保持活跃对话
 - NRR（净收入留存）是终极指标，它用一个数字捕获了扩张、收缩和流失
 - QBR 应是前瞻性的战略规划会议，而非回顾性的状态报告
+- 投资组合分层策略：基于增长潜力和战略价值分配账户投入，对顶级账户进行 C-level 双边高管业务回顾
+- 合同结构设计：消费下限、增长阶梯、多年期承诺等激励对齐机制
+- 组织变革检测：实时感知 M&A、重组、领导层更替，并动态调整账户策略
+- 定价与包装优化：基于使用模式和支付意愿提供定价建议
+- 渠道协同扩张：与系统集成商或渠道合作伙伴共同影响的企业账户扩张
 
 ## Key Quotes
 > "The best time to sell more is when the customer is winning." — Account Strategist Agent 核心理念
@@ -29,6 +34,8 @@ date: 2026-04-25
 > "Never pitch expansion to a customer who is not yet successful with what they already own." — Account Health First Rule
 > "NRR is the ultimate metric. It captures expansion, contraction, and churn in a single number. Optimize for NRR, not bookings." — Account Health First Rule
 > "Be strategically specific: 'Usage in the analytics team hit 92% capacity — their headcount is growing 30% next quarter, so expansion timing is ideal.'" — Communication Style
+> "Detecting organizational change (M&A, reorgs, leadership transitions) and adapting account strategy in real time." — Organizational Intelligence
+> "Build executive relationships that survive individual champion turnover." — Organizational Intelligence
 
 ## Key Concepts
 - [[Land-and-Expand]]：将初始成交（land deal）逐步扩展为七位数平台关系的系统性方法论，包括扩张就绪信号识别、冠军赋能套件、RACI 扩张剧本
@@ -38,6 +45,14 @@ date: 2026-04-25
 - [[Multi-Threading]]：多线程关系建设——每个账户至少三条独立关系线，防止单点失败（champion 离职导致的关系断层）
 - [[Account Health Score]]：账户健康评分——综合产品使用率、支持工单情感、利益相关者参与度、合同时间线、高管发起人活动
 - [[Churn Prevention Playbook]]：流失预防手册——早期预警信号 + 分级干预计划（立即/短期/中期）
+- [[Account Portfolio Segmentation]]：账户投资组合分层——基于增长潜力和战略价值分层，差异化管理投入
+- [[Executive Business Review (EBR)]]：高管业务回顾——面向 C-level 双边高管，以战略对齐为目标的年度或半年度会议
+- [[Pricing and Packaging Optimization]]：定价与包装优化——基于使用模式和支付意愿的定价建议
+- [[Contract Structure Design]]：合同结构设计——消费下限、增长阶梯、多年期承诺等激励机制
+- [[Co-sell and Partner-influenced Expansion]]：渠道协同扩张——与系统集成商或渠道伙伴共同推进的企业账户扩张
+- [[Product-Led Growth (PLG)]]：产品主导增长——对齐自助升级路径与销售主导扩张的混合增长策略
+- [[Organizational Change Detection]]：组织变革检测——实时感知 M&A、重组、领导层更替并动态调整账户策略
+- [[Informal Decision-Making Mapping]]：非正式决策映射——识别绕过正式采购路径的内部决策机制
 
 ## Key Entities
 - **Account Strategist Agent**：售后扩张策略师角色，对应 [[sales-account-strategist]]
@@ -61,3 +76,7 @@ date: 2026-04-25
   - 冲突点：销售教练辅导卖方（销售代表成长）；账户策略师辅导买方（帮助客户内部推广）
   - 当前观点：互补关系——[[sales-coach]] 提升卖方能力，[[sales-account-strategist]] 建设买方冠军
   - 对方观点：无直接冲突，角色边界清晰
+- 与 [[sales-pipeline-analyst]] 的指标视角不同：
+  - 冲突点：管道分析师关注赢单率和预测准确性；账户策略师关注 NRR 和账户健康
+  - 当前观点：互补关系——赢单是 NRR 的前提，两者共享 NRR 作为共同语言
+  - 对方观点：[[sales-pipeline-analyst]] 的管道审查数据可作为账户扩张信号的早期预警
diff --git a/wiki/sources/sales-coach.md b/wiki/sources/sales-coach.md
index c1981a93..3dd82bb7 100644
--- a/wiki/sources/sales-coach.md
+++ b/wiki/sources/sales-coach.md
@@ -2,7 +2,7 @@
 title: "Sales Coach Agent"
 type: source
 tags: ["sales", "coaching", "agent", "b2b"]
-date: 2026-04-24
+date: 2026-05-02
 ---
 
 ## Source File
@@ -11,44 +11,57 @@ date: 2026-04-24
 ## Summary（用中文描述）
 - 核心主题：AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长，专注于管道审查、话术辅导、交易策略和预测准确性
 - 问题域：销售团队管理、销售代表能力发展、交易风险识别、预测纪律
-- 方法/机制：结构化辅导框架（ Richardson Sales Performance）、挑战者销售模型（Challenger）、MEDDPICC 资质诊断、行为反馈循环
-- 结论/价值：正式销售辅导项目使配额完成率达 91.2%（vs 非正式辅导 84.7%），每周接受2小时以上辅导的销售代表赢单率达56%（vs 少于30分钟仅43%）
+- 方法/机制：结构化辅导框架（Richardson Sales Performance）、挑战者销售模型（Challenger）、MEDDPICC 资质诊断、行为反馈循环、观察→提问→建议→练习闭环
+- 结论/价值：正式销售辅导项目使配额完成率达 91.2%（vs 非正式辅导 84.7%），每周接受 2 小时以上辅导的销售代表赢单率达 56%（vs 少于 30 分钟仅 43%）
 
 ## Key Claims（用中文描述）
 - 正式销售辅导项目使团队配额完成率达 91.2%，显著优于非正式辅导的 84.7%
 - 每周接受 2 小时以上辅导的销售代表赢单率为 56%，远高于每周少于 30 分钟辅导的 43%
 - 辅导行为而非结果：过程完美的输单不需要纠正，幸运赢单需要立即辅导
-- 管道数量是虚荣指标，管道质量才是管理工具
+- 管道数量是虚荣指标，管道质量才是管理工具——$800K 高质量管道优于 $2M 低质量管道
 - 每次辅导互动必须产出一个具体、可行为、可执行的改进建议
+- 区分 skill gap（不知道怎么做）与 will gap（知道但不做）——辅导修复技能，管理修复意愿
+- 销售预测纪律：承诺 deals 必须基于可验证证据，而非乐观情绪
+- 最佳交易教练节奏：每周 1:1 关注活动/阻碍/习惯；双周管道审查关注交易健康度/资质缺口/风险；月度预测会议关注模式识别和资源分配
 
 ## Key Quotes
+> "A lost deal with disciplined process is more valuable than a lucky win, because process compounds and luck does not." — 过程优于结果，纪律决定长期复利
 > "Ask before telling. Your first instinct should always be a question, not an instruction." — 苏格拉底式辅导的核心原则
-> "A lost deal with disciplined process is more valuable than a lucky win, because process compounds and luck does not." — 过程优于结果
-> "Enthusiasm without commitment is not a buying signal." — 挑战"happy ears"，要求可验证的承诺
+> "Enthusiasm without commitment is not a buying signal." — 挑战"happy ears"，要求可验证的下一步承诺
+> "Coach the behavior, not the outcome." — 行为辅导而非结果辅导
 
 ## Key Concepts
-- [[MEDDPICC]]：交易资质诊断框架，包含八个维度（Metrics、Economic Buyer、Decision Criteria、Decision Process、Paper Process、Implicated Pain、Champion、Competition）；Deal 少于 5/8 字段填充即为资格不足，是预测失误的主要来源；资质缺口是交易风险的信号，而非 CRM 记录问题
-- [[Challenger Sales Model]]：挑战者辅导模型，教导销售代表以商业洞察引领对话，而非被动回应客户需求；在客户思考问题的方式上重新构建认知
-- [[Richardson Sales Performance Framework]]：四维能力框架：辅导卓越、激励领导、销售管理纪律、战略规划
-- [[Pipeline Review]]：将管道审查从审讯转变为辅导对话，用"我们对这个交易还有什么不知道的"替代"什么时候关单"
-- [[Forecast Accuracy]]：基于可验证证据而非乐观情绪的预测纪律，区分 upside/commit/closed 三个层级
-- [[Coaching Discipline]]：辅导纪律——行为辅导而非结果辅导；一次只做一件事；跟进反馈是否被应用
+- [[MEDDPICC]]：交易资质诊断框架，八个维度（Metrics/Economic Buyer/Decision Criteria/Decision Process/Paper Process/Implicated Pain/Champion/Competition）；当销售代表无法清晰阐述经济决策者时，这不是 CRM 记录问题，而是交易风险信号；资质缺口是辅导时机
+- [[Challenger Sales Model]]：挑战者辅导模型，教导销售代表以商业洞察引领对话，在客户思考问题的方式上重新构建认知，再呈现解决方案
+- [[Richardson Sales Performance Framework]]：四维能力框架——辅导卓越（Coaching Excellence）、激励领导（Motivational Leadership）、销售管理纪律（Sales Management Discipline）、战略规划（Strategic Planning）
+- [[Pipeline Review]]：将管道审查从审讯转变为辅导对话，用"我们对这个交易还有什么不知道的"替代"什么时候关单"；识别组合层面的模式：开场强但收尾弱、卡在特定阶段、回避特定对话类型
+- [[Forecast Accuracy]]：基于可验证证据而非乐观情绪的预测纪律，区分 upside（努力可能关单）/ commit（基于证据将关单）/ closed（已签约）三个层级；追踪销售代表预测准确性随时间的变化
+- [[Coaching Discipline]]：辅导纪律——行为辅导而非结果辅导；先问后说；一次只做一件事；跟进反馈是否被应用
+- [[Observe-Ask-Suggest-Practice Loop]]：辅导强化循环——描述观察到的行为 → 询问销售代表的思考 → 建议替代方案 → 立即练习
+- [[Skill Gap vs Will Gap]]：技能缺口（不知道如何做）与意志缺口（知道但不做）的区分；辅导修复技能，管理修复意志，不可混淆
 
 ## Key Entities
-- [[Discovery Coach Agent]]：同为 The Agency 销售类 Agent，专注发现阶段辅导，与 Sales Coach 形成互补关系
-- [[Sales Pipeline Analyst Agent]]：管道分析类 Agent，提供数据支撑，与 Sales Coach 协同工作
-- [[Sales Deal Strategist Agent]]：交易策略类 Agent，在重大交易前进行策略准备
+- [[Discovery Coach Agent]]：同为 The Agency 销售类 Agent，专注发现阶段深度辅导，与 Sales Coach 形成互补关系——Discovery Coach 负责发现阶段深度，Sales Coach 负责整体辅导规划
+- [[Sales Pipeline Analyst Agent]]：管道分析类 Agent，提供数据支撑（赢率/周期/阶段转化），与 Sales Coach 协同工作
+- [[Sales Deal Strategist Agent]]：交易策略类 Agent，在重大会议前进行 Deal Prep，协助 Sales Coach 完成策略准备
+- [[Sales Proposal Strategist]]：提案策略类 Agent，与 Sales Coach 在 Deal 推进中协作（策略 → 提案）
+- [[Account Strategist Agent]]：客户账户策略类 Agent，为 Sales Coach 提供账户层面的战略视角
 
 ## Connections
-- [[Discovery Coach Agent]] ← complements ← [[Sales Coach Agent]]
+- [[Sales Coach Agent]] ← complements ← [[Discovery Coach Agent]]
 - [[Sales Pipeline Analyst Agent]] ← provides_data_for ← [[Sales Coach Agent]]
 - [[Sales Deal Strategist Agent]] ← prepares ← [[Sales Coach Agent]]
+- [[Sales Proposal Strategist]] ← supports ← [[Sales Coach Agent]]
+- [[Account Strategist Agent]] ← informs ← [[Sales Coach Agent]]
 - [[Sales Coach Agent]] ← uses ← [[MEDDPICC]]
 - [[Sales Coach Agent]] ← uses ← [[Challenger Sales Model]]
+- [[Sales Coach Agent]] ← uses ← [[Pipeline Review]]
+- [[Sales Coach Agent]] ← uses ← [[Forecast Accuracy]]
+- [[Sales Coach Agent]] ← uses ← [[Coaching Discipline]]
 
 ## Contradictions
-- 与 [[Discovery Coach Agent]] 的潜在差异：
-  - 冲突点：辅导焦点的层次不同
-  - 当前观点（Sales Coach）：辅导范围覆盖全销售周期，包括发现、策略、预测
-  - 对方观点（Discovery Coach）：专注发现阶段的深度辅导
-  - 协调方案：Discovery Coach 负责发现阶段深度，Sales Coach 负责整体辅导规划，两者协同覆盖完整周期
+- 与 [[Discovery Coach Agent]] 的辅导层次差异：
+  - 冲突点：辅导焦点的深度层次不同
+  - 当前观点（Sales Coach）：辅导范围覆盖全销售周期（发现→策略→预测），使用结构化框架进行组合层面分析
+  - 对方观点（Discovery Coach）：专注发现阶段的深度辅导，聚焦于资质问题和对话技巧
+  - 协调方案：Discovery Coach 负责发现阶段深度辅导，Sales Coach 负责整体辅导规划、管道管理和预测纪律，两者协同覆盖完整销售周期
diff --git a/wiki/sources/sales-data-extraction-agent.md b/wiki/sources/sales-data-extraction-agent.md
index cc44e177..8e8d5a0b 100644
--- a/wiki/sources/sales-data-extraction-agent.md
+++ b/wiki/sources/sales-data-extraction-agent.md
@@ -1,47 +1,47 @@
----
-title: "Sales Data Extraction Agent"
-type: source
-tags: []
-date: 2026-04-25
----
-
-## Source File
-- [[raw/Agent/agency-agents/specialized/sales-data-extraction-agent.md]]
-
-## Summary（用中文描述）
-- 核心主题：销售数据提取 AI Agent，专门监控 Excel 文件并提取关键销售指标
-- 问题域：销售报告自动化处理、销售指标实时监控
-- 方法/机制：文件系统监控 + 灵活列映射 + PostgreSQL 持久化
-- 结论/价值：实现销售数据的自动化提取与下游分发，减少人工干预
-
-## Key Claims（用中文描述）
-- Agent 实时监控指定目录中的 Excel 文件（新文件或更新版本）
-- Agent 从 Excel 工作簿中提取 MTD（月度至今）、YTD（年度至今）和 Year End（年终预测）指标
-- Agent 支持灵活列名映射（revenue/sales/total_sales 等）
-- Agent 自动计算配额达成率
-- Agent 使用事务将提取的指标批量插入 PostgreSQL，保证原子性
-- Agent 保留完整的审计跟踪记录
-
-## Key Quotes
-> "You are the Sales Data Extraction Agent — an intelligent data pipeline specialist who monitors, parses, and extracts sales metrics from Excel files in real time. You are meticulous, accurate, and never drop a data point." — Agent 身份定义
-
-> "Never overwrite existing metrics without a clear update signal (new file version)" — 关键规则：数据覆盖保护
-
-## Key Concepts
-- [[FilesystemWatcher]]：文件系统监控，检测目录中的 .xlsx 和 .xls 文件变化
-- [[FuzzyColumnMapping]]：模糊列名匹配，处理 revenue/sales/total_sales、units/qty/quantity 等变体
-- [[MetricExtraction]]：指标提取，从工作簿中识别 MTD、YTD、Year End 等指标类型
-- [[TransactionalDatabase]]：事务性数据库操作，使用 PostgreSQL 事务保证原子性
-- [[AuditTrail]]：审计跟踪，记录每次导入的文件名、处理行数、失败行数、时间戳
-
-## Key Entities
-- [[PostgreSQL]]：目标数据库，用于存储提取的销售指标
-- [[SalesRepresentative]]：销售代表，Agent 通过邮箱或全名匹配
-- [[ExcelWorkbook]]：Excel 工作簿，包含多个 sheet 的销售数据
-
-## Connections
-- [[AgentsOrchestrator]] ← orchestrates ← [[SalesDataExtractionAgent]]
-- [[SalesDataExtractionAgent]] ← provides_data ← [[ReportDistributionAgent]]
-
-## Contradictions
-- 与 [[DataConsolidationAgent]]：DataConsolidationAgent 整合来自多个来源的数据，而 SalesData Extraction Agent 专注于从 Excel 文件提取数据；两者可以互补使用
+---
+title: "Sales Data Extraction Agent"
+type: source
+tags: [Agent, Sales, Data-Extraction]
+date: 2026-04-30
+---
+
+## Source File
+- [[raw/Agent/agency-agents/specialized/sales-data-extraction-agent.md]]
+
+## Summary（用中文描述）
+- 核心主题：Sales Data Extraction Agent — 一个专注于监控 Excel 文件并提取销售指标（MTD、YTD、Year End）的 AI Agent
+- 问题域：企业销售数据的实时采集与下游报表分发，需处理多种格式的 Excel 文件并保证数据完整性
+- 方法/机制：文件系统监控 → 灵活列名映射 → 指标类型自动识别 → PostgreSQL 事务持久化 → 下游事件通知
+- 结论/价值：实现销售数据的全自动化采集，100% 无人工干预，完整审计追踪
+
+## Key Claims（用中文描述）
+- Agent 通过文件系统监控（filesystem watcher）实时检测指定目录中的 .xlsx/.xls 文件（忽略 `~$` 临时锁文件），等待写入完成后触发处理流程
+- Agent 使用模糊列名匹配（fuzzy matching）处理灵活多变的 Excel schema，支持 `revenue/sales/total_sales`、`units/qty/quantity` 等多种列名变体
+- Agent 从工作表名称自动推断指标类型（MTD / YTD / Year End），并在 quota 和 revenue 同时存在时自动计算配额达成率
+- Agent 以事务方式批量插入提取的指标到 PostgreSQL，每条记录附有源文件信息以支持完整审计追踪
+- Agent 从不覆盖已有指标数据，仅在新文件版本出现时才更新；所有导入操作均记录文件名、处理行数、失败行数和时间戳
+
+## Key Quotes
+> "Never overwrite existing metrics without a clear update signal (new file version)" — 核心数据保护规则
+> "Match representatives by email or full name; skip unmatched rows with a warning" — 数据匹配策略
+> "Detect metric type from sheet names (MTD, YTD, Year End) with sensible defaults" — 指标类型推断逻辑
+
+## Key Concepts
+- [[FileSystemWatcher]]：通过文件系统监控检测新 Excel 文件，忽略 `~$` 临时锁文件，等待写入完成后触发处理
+- [[FuzzyColumnMatching]]：使用模糊列名匹配处理 Excel schema 变化，支持 `revenue/sales/total_sales`、`units/qty/quantity` 等变体
+- [[MetricTypeDetection]]：根据工作表名称（MTD / YTD / Year End）自动推断指标类型并设置默认值
+- [[QuotaAttainment]]：当 quota 和 revenue 同时存在时自动计算配额达成率 = revenue / quota
+- [[AtomicDataPersistence]]：使用 PostgreSQL 事务进行批量插入，保证数据原子性；每条记录附源文件审计字段
+- [[AuditTrail]]：每次导入记录文件名、处理行数、失败行数和时间戳，支持下游追溯
+
+## Key Entities
+- [[PostgreSQL]]：目标持久化数据库，Agent 将提取的指标批量写入其中
+- [[ReportDistributionAgent]]：下游消费 Agent，接收 Agent 发送的完成事件并分发报告
+
+## Connections
+- [[SalesDataExtractionAgent]] ← feeds ← Excel Files (source input)
+- [[ReportDistributionAgent]] ← depends_on ← [[SalesDataExtractionAgent]]
+- [[DataConsolidationAgent]] ← aggregates ← [[SalesDataExtractionAgent]] (推测：多个提取 Agent 向上游聚合)
+
+## Contradictions
+- 当前页面无冲突内容
diff --git a/wiki/sources/sales-deal-strategist.md b/wiki/sources/sales-deal-strategist.md
index 55488ebb..9ce6e839 100644
--- a/wiki/sources/sales-deal-strategist.md
+++ b/wiki/sources/sales-deal-strategist.md
@@ -2,60 +2,65 @@
 title: "Deal Strategist Agent"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-05-18
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/sales/sales-deal-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：B2B 复杂销售周期的高级deal策略与管线架构
-- 问题域：销售管线中deal质量评估不严、预测失准、竞争定位模糊、赢率低下
-- 方法/机制：MEDDPICC八维资质评分 + Challenger商业教学法 + 三区竞争定位 + 六步商业教学序列 + 交易检查方法论
-- 结论/价值：全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%；预测准确率Commit deals关闭率85%+；Qualified Pipeline赢率35%+
+- 核心主题：B2B 复杂销售周期的高级 deal 策略与管线架构
+- 问题域：销售管线中 deal 质量评估不严、预测失准、竞争定位模糊、赢率低下、单线程依赖
+- 方法/机制：MEDDPICC 八维资质评分 + Challenger 商业教学法 + 三区竞争定位 + 六步商业教学序列 + 交易检查方法论
+- 结论/价值：全面推行 MEDDPICC 的组织赢率提升 18%、deal 规模扩大 24%；Commit deals 关闭率 85%+；Qualified Pipeline（28/40+）赢率 35%+；平均 deal 规模扩大 20%+；周期缩短 15%
 
 ## Key Claims（用中文描述）
-- 全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%——但前提是将MEDDPICC作为思维工具而非打勾练习
-- 一个deal若没有回答全部八个要素，说明尚未真正理解该deal
-- 6周采购周期如果在第11周才发现，会直接扼杀季度
+- 全面推行 MEDDPICC 的组织赢率提升 18%、deal 规模扩大 24%——但前提是将 MEDDPICC 作为思维工具而非打勾练习
+- 一个 deal 若没有回答全部八个要素，说明尚未真正理解该 deal
+- 6 周采购周期如果在第 11 周才发现，会直接扼杀季度
 - 决策在理性层面被论证，在感性层面被做出
-- 预测准确率Commit deals关闭率应达85%+
-- Qualified Pipeline（28/40分以上）赢率应达35%+
-- 竞争定位中的Losing Zone应对策略是缩小其重要性，而非撒谎或攻击竞争对手
+- 预测准确率 Commit deals 关闭率应达 85%+
+- Qualified Pipeline（28/40 分以上）赢率应达 35%+
+- 竞争定位中的 Losing Zone 应对策略是缩小其重要性，而非撒谎或攻击竞争对手
+- 友好联系人 ≠ Champion；Champion 必须在艰难请求下愿意行动才算真正验证
 
 ## Key Quotes
-> "A deal without all eight answered is a deal you don't understand." — MEDDPICC核心原则
+> "A deal without all eight answered is a deal you don't understand." — MEDDPICC 核心原则
 > "This deal is at risk. Here's why, and here's what to do about it." — 策略师沟通风格
 > "Decisions are justified rationally and made emotionally." — 商业教学情感层
 > "The winning move on losing zones is to shrink their importance, not to lie about your capabilities." — 竞争定位原则
 
 ## Key Concepts
-- [[MEDDPICC]]：八维资质评分框架——Metrics/Economic Buyer/Decision Criteria/Decision Process/Paper Process/Identify Pain/Champion/Competition，每维度5分，满分40
+- [[MEDDPICC]]：八维资质评分框架——Metrics/Economic Buyer/Decision Criteria/Decision Process/Paper Process/Identify Pain/Champion/Competition，每维度 5 分，满分 40
 - [[Challenger Sales Model]]：挑战者销售法——通过商业教学重新定义买方对自身问题的理解，在定位解决方案之前先建立价值
 - [[Command of the Message]]：信息掌控框架——三层支柱（我们解决什么问题/我们如何不同/客户实现什么可衡量成果）
-- Deal Scoring：加权评分模型，分离真实管线与虚假管线，含预警指标
-- Competitive Positioning：竞争定位策略——Winning/Battling/Losing三区分类 + 地雷问题布局
+- Deal Scoring：加权评分模型，分离真实管线与虚假管线，含早期预警指标
+- Competitive Positioning：竞争定位策略——Winning/Battling/Losing 三区分类 + 地雷问题布局
 - Win Planning：分阶段行动计划，含明确责任人、里程碑和退出标准
-- Deal Inspection Methodology：交易检查方法论——系统性探测deal状态、风险和下一步
+- Deal Inspection Methodology：交易检查方法论——系统性探测 deal 状态、风险和下一步
 - Challenger Messaging：六步商业教学序列——Warmer/Reframe/Rational Drowning/Emotional Impact/A New Way/Your Solution
+- Multi-Threading Strategy：多线程接触策略——绘制权力/影响力/触达地图，避免单点依赖
+- Forecast Accuracy：预测准确性——可辩护而非乐观的 deal 级别检查方法论
+- Competitive Landmines：竞争地雷——在发现阶段通过合法问题暴露竞争对手方案弱点
 
 ## Key Entities
-- [[Sales Coach Agent]]：同为The Agency销售体系的核心智能体，Sales Coach辅导卖方行为，Deal Strategist辅导deal策略
-- [[Discovery Coach Agent]]：发现阶段教练，提供买方情境输入给Deal Strategist
-- [[Sales Proposal Strategist]]：赢单叙事构建者，接收Deal Strategist的竞争定位和评分输出
-- Deal Strategist Agent：The Agency销售部门成员，专业于MEDDPICC deal策略、竞争定位和赢单规划
+- [[Sales Coach Agent]]：同为 The Agency 销售体系的核心智能体，Sales Coach 辅导卖方行为，Deal Strategist 辅导 deal 策略
+- [[Discovery Coach Agent]]：发现阶段教练，提供买方情境输入给 Deal Strategist
+- [[Sales Proposal Strategist]]：赢单叙事构建者，接收 Deal Strategist 的竞争定位和评分输出
+- [[Sales Pipeline Analyst]]：管线分析，Deal Strategist 输出的评分数据支撑 Pipeline Analyst 的趋势预测
+- Deal Strategist Agent：The Agency 销售部门成员，专业于 MEDDPICC deal 策略、竞争定位和赢单规划
 
 ## Connections
-- [[sales-coach]] ← shares MEDDPICC framework with ← [[sales-discovery-coach]]
+- [[sales-pipeline-analyst]] ← receives deal scoring data from ← [[sales-deal-strategist]]
 - [[sales-proposal-strategist]] ← receives win strategy input from ← [[sales-deal-strategist]]
 - [[sales-discovery-coach]] ← provides buyer context to ← [[sales-deal-strategist]]
 - [[sales-deal-strategist]] ← extends MEDDPICC with deal execution tactics ← [[sales-coach]]
 
 ## Contradictions
 - 与 [[sales-proposal-strategist]] 的视角差异：
-  - 冲突点：Deal Strategist聚焦交易层面的策略和执行，Proposal Strategist聚焦提案层面的叙事和说服
-  - 当前观点：Deal Strategist认为"没有全面评估的deal在预测会上就输了"
-  - 对方观点：Proposal Strategist认为"赢单在提案开篇100词就已决定"
-  - 协调：两者互补——Deal Strategist提供结构化deal分析和竞争定位，Proposal Strategist将其转化为说服性叙事
+  - 冲突点：Deal Strategist 聚焦交易层面的策略和执行，Proposal Strategist 聚焦提案层面的叙事和说服
+  - 当前观点：Deal Strategist 认为"没有全面评估的 deal 在预测会上就输了"
+  - 对方观点：Proposal Strategist 认为"赢单在提案开篇 100 词就已决定"
+  - 协调：两者互补——Deal Strategist 提供结构化 deal 分析和竞争定位，Proposal Strategist 将其转化为说服性叙事
 - 与 [[sales-discovery-coach]] 的互补关系：
-  - Discovery Coach发现买方情境，Deal Strategist基于此构建交易策略，两者构成"发现→策略"闭环
+  - Discovery Coach 发现买方情境，Deal Strategist 基于此构建交易策略，两者构成"发现→策略"闭环
diff --git a/wiki/sources/sales-engineer.md b/wiki/sources/sales-engineer.md
index 18a1db4f..8193a5c6 100644
--- a/wiki/sources/sales-engineer.md
+++ b/wiki/sources/sales-engineer.md
@@ -2,58 +2,55 @@
 title: "Sales Engineer Agent"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/sales/sales-engineer.md]]
+- [[Agent/agency-agents/sales/sales-engineer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：售前工程师（Sales Engineer）Agent 的角色定义、能力模型与操作框架，专注于在 B2B 技术评估中赢得技术决策
-- 问题域：B2B 软件销售中的技术售前环节——如何设计演示、执行 POC、应对竞争、处理异议、管理评估流程
-- 方法/机制：Demo Engineering（以影响力为导向的演示设计）、POC Scoping（严格限定的概念验证范围）、FIA Framework（事实-影响-行动竞争定位框架）、Evaluation Notes（交易级技术情报维护）
-- 结论/价值：技术决策先于商业决策，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能
+- 核心主题：Sales Engineer（售前工程师）Agent 的角色定义与核心能力框架，涵盖技术发现、Demo 工程、POC 设计、竞争技术定位和解决方案架构
+- 问题域：B2B 销售中如何赢得技术决策 —— 技术评估阶段的有效策略与方法论
+- 方法/机制：FIA 框架（Fact-Impact-Act）、"Aha Moment" 测试、POC 范围界定模板、竞争技术分层（Winning/Battling/Losing Zones）、结构化评估笔记
+- 结论/价值：技术销售的核心在于技术能力与业务结果的连接；没有技术胜利，就没有销售胜利
 
 ## Key Claims（用中文描述）
-- 售前工程师赢得技术决策，销售才能赢得商业合同——技术层是整个交易的关键门槛
-- 演示不是产品tour，而是叙事——买家在演示中看到自己的问题被实时解决
-- POC 不是免费试用，而是有二元结果的结构化评估：成功或失败，标准在开始前就已明确定义
-- 竞争定位应采用 FIA 框架（Fact-Impact-Act），保持事实基础和可操作性，而非情绪化和反应式
-- 永远不要攻击竞争对手——认可竞争对手的优势，同时清晰表达差异化
+- 技术发现必须揭示架构、集成需求、安全约束和真实的技术决策标准，而非仅看公开 RFP
+- Demo 是叙事而非产品 tour —— 先量化问题，再展示产品，最后反向讲解机制
+- 每个 Demo 必须产生至少一个 "Aha Moment"，否则 Demo 失败
+- POC 是有二元结果的定向评估，而非免费试用；模糊的成功标准导致模糊的结局
+- FIA 框架保持技术定位基于事实，而非情绪化和反应式
+- 技术异议很少是表面问题；必须解码真实诉求
+- 精准优于大量：30 分钟精准命中三件事，胜过 90 分钟覆盖十二件事
 
 ## Key Quotes
-> "A demo is not a product tour. A demo is a narrative where the buyer sees their problem solved in real time." — 演示的本质是叙事，不是功能演示
-> "Every technical conversation must connect back to a business outcome or it's just a feature dump." — 技术对话必须连接到业务成果
-> "Ambiguous success criteria produce ambiguous outcomes, which produce 'we need more time to evaluate,' which means you lost." — 模糊的成功标准等于失败
-> "Never trash the competition. Buyers respect SEs who acknowledge competitor strengths while clearly articulating differentiation." — 永远不要攻击竞争对手
+> "A demo is not a product tour. A demo is a narrative where the buyer sees their problem solved in real time." — Demo 的本质定义
+> "You can't get the sales win without the technical win — but the technology is your toolbox, not your storyline." — 技术与商业的关系
+> "A proof of concept is not a free trial. It's a structured evaluation with a binary outcome: pass or fail, against criteria defined before the first configuration." — POC 的本质定义
+> "Technical objections are rarely about the stated concern." — 技术异议解码原则
+> "Credibility compounds. One dishonest answer erases ten honest ones." — 诚信的复利效应
 
 ## Key Concepts
-- [[Demo Engineering]]：以影响力为导向的演示设计，先量化问题，再展示产品，最后证明效果
-- [[POC Scoping]]：严格限定的概念验证范围设计，以成功标准、硬性时间线和检查点为支柱
-- [[FIA Framework]]：Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性
-- [[Evaluation Notes]]：交易级技术情报维护，结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略
-- [[Technical Objection Handling]]：技术异议处理，解码真实问题而非表面问题
-- [[Aha Moment]]：演示中让买家产生"这正是我们需要的"那一刻，是演示成功的核心标志
+- [[Technical Discovery]]：结构化需求分析，揭示架构、集成需求、安全约束和真实技术决策标准
+- [[Demo Engineering]]：影响优先的演示设计，在展示产品前量化问题，量体裁衣
+- [[POC Scoping]]：严格限范围的 POC 设计，包含前置成功标准、明确时间线和决策门槛
+- [[FIA Framework]]：Fact-Impact-Act，竞争技术定位框架，保持定位基于事实而非情绪
+- [[Aha Moment Test]]：每个 Demo 必须产生至少一个买家说"这正是我们需要的"时刻
+- [[Competitive Technical Positioning]]：竞争技术分层（Winning/Battling/Losing Zones）
+- [[Technical Objection Handling]]：技术异议解码，识别表面问题背后的真实诉求
+- [[Evaluation Management]]：端到端技术评估过程管理，从发现电话到 POC 决策和技术关闭
+- [[Solution Architecture]]：将产品能力映射到买方基础设施，设计降低感知风险的部署方案
+- [[Demo Tailoring]]：基于买家术语、数据模型和工作流语言定制 Demo，而非使用产品词汇
 
 ## Key Entities
-- [[Sales Pipeline Analyst Agent]]：同属销售团队的数据分析 Agent，共同支撑销售闭环
-- [[Sales Outbound Strategist Agent]]：同属销售团队的对外策略 Agent，共同支撑销售闭环
-- [[Deal Strategist Agent]]：同属销售团队的交易策略 Agent，共同支撑销售闭环
-- [[Account Strategist Agent]]：同属销售团队的客户策略 Agent，共同支撑销售闭环
-- [[Sales Proposal Strategist]]：同属销售团队的建议书策略 Agent，共同支撑销售闭环
+- （本文档为 Agent 角色定义，无具体人物/公司实体）
 
 ## Connections
-- [[Sales Pipeline Analyst Agent]] ← team_member ← [[Sales Engineer Agent]]
-- [[Sales Outbound Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
-- [[Deal Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
-- [[Account Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
-- [[Sales Proposal Strategist]] ← team_member ← [[Sales Engineer Agent]]
-- [[Sales Discovery Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]]
-- [[Sales Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]]
+- [[Sales Pipeline Analyst]] ← related_to ← [[Sales Engineer]]：两者共同支撑销售管道分析
+- [[Sales Outbound Strategist]] ← related_to ← [[Sales Engineer]]：外呼策略与技术发现共享买家需求理解
+- [[Sales Deal Strategist]] ← related_to ← [[Sales Engineer]]：交易策略与技术评估协同
+- [[Sales Account Strategist]] ← related_to ← [[Sales Engineer]]：账户策略与技术发现共享客户环境理解
+- [[Sales Proposal Strategist]] ← related_to ← [[Sales Engineer]]：提案策略与技术定位信息共享
 
 ## Contradictions
-- 与 [[Sales Discovery Coach Agent]] 在"技术深度"维度存在互补张力：
-  - 冲突点：售前工程师在发现阶段应保持多深的技术参与度？
-  - 当前观点（Sales Engineer）：售前工程师应主导技术发现，结构化地挖掘架构、集成、安全约束和真实技术决策标准
-  - 对方观点（Sales Discovery Coach）：销售发现应聚焦于业务问题，深度技术探索由专门的角色或时机负责
-  - 协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式
+- 暂无发现与其他 Wiki 页面的内容冲突
diff --git a/wiki/sources/sales-outbound-strategist.md b/wiki/sources/sales-outbound-strategist.md
index c4a02e6d..63920bb7 100644
--- a/wiki/sources/sales-outbound-strategist.md
+++ b/wiki/sources/sales-outbound-strategist.md
@@ -1,50 +1,55 @@
 ---
 title: "Outbound Strategist Agent"
 type: source
-tags: []
-date: 2026-04-25
+tags: [sales, outbound, prospecting, multi-channel]
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/sales/sales-outbound-strategist.md]]
+- [[Agent/agency-agents/sales/sales-outbound-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：信号驱动型出站销售策略与多渠道序列设计
-- 问题域：B2B 出站销售如何从"批量轰炸"转向"精准触发"，在买家信号最强烈的时刻介入
-- 方法/机制：三层信号分级体系（主动购买信号→组织变化信号→技术/行为信号）+ ICP 可证伪定义 + 三层账户分级模型 + 8-12 触点 3-4 周多渠道序列架构
-- 结论/价值：信号驱动出站转化率比无触发出站高 4-8 倍；SDR 角色从批量操作员进化为信号监控专家
+- 核心主题：信号驱动的主动销售（Signal-Based Selling）——通过识别买家行为信号触发精准外展，而非依赖传统批量触达
+- 问题域：传统 SDR 以"100次活动/天"为指标的批量外展模式正在失效；如何从 volume operator 转型为 revenue specialist
+- 方法/机制：三层信号体系（主动购买信号 > 组织变化信号 > 技术/行为信号）× 分层账户模型（Tier 1/2/3）× 8-12 触点多渠道序列
+- 结论/价值：信号驱动的外展转化率比无触发外展高 4-8 倍；SDR 角色从"量"转向"质"，衡量指标从活动量变为管道质量和 Stage 1→2 转化率
 
 ## Key Claims（用中文描述）
-- 信号驱动出站转化率比无触发冷出站高 4-8 倍
-- 信号半衰期短：30 分钟内路由到正确销售，24 小时后信号失效，72 小时后竞争对手已成交
-- 可用 ICP 必须可证伪——不能排除任何公司的 ICP 不是 ICP，是 TAM 幻灯片
-- 序列中每次触达必须提供新的价值角度——重复同样诉求不是序列，是骚扰
-- 冷邮件回复率基准：泛化型 1-3%、角色定制 5-8%、信号驱动 12-25%、推荐引入型 30-50%
-- SDR 角色转变：从每天 100 次活动操作员 → 拥有 50-80 个深度账户的管线专家
+- 信号驱动外展比无触发外展转化率高 4-8 倍
+- 购买信号半衰期短：30 分钟内路由到正确销售，24 小时后信号变陈旧，72 小时后竞争对手已完成对话
+- 有效的 ICP 必须可证伪——能排除公司才算 ICP，否则只是 TAM 幻灯片
+- 分层账户策略：Tier 1（50-100账户）× 深度个性化；Tier 2（200-500）× 半个性化；Tier 3 × 自动化轻量个性化
+- 多渠道序列每次触达必须提供新价值角度——重复同样诉求不是序列而是骚扰
+- 冷邮件回复率基准：通用 1-3% → 角色/行业个性化 5-8% → 信号驱动+账户研究 12-25% → 热介绍推荐 30-50%
+- SDR 新模式：Own 50-80 账户深度 vs 500 账户喷洒；衡量指标从会议数量变为管道质量和 Stage 2 转化
 
 ## Key Quotes
-> "If you cannot articulate why you are contacting this specific person at this specific company at this specific moment, you are not ready to send." — Outbound Strategist Agent 核心原则
+> "Outreach triggered by buying signals converts 4-8x compared to untriggered cold outreach." — 核心理念陈述
+> "If it does not exclude companies, it is not an ICP — it is a TAM slide." — ICP 定义原则
 > "Each touch must add a new value angle. Repeating the same ask with different words is not a sequence — it is nagging." — 序列设计原则
+> "Do not automate what should be personal, and do not personalize what should be automated. Know the difference." — 自动化与个性化边界
 
 ## Key Concepts
-- [[Signal-Based Selling Framework]]：基于买家行为信号触发精准出站的方法论，转化率比传统冷出站高 4-8 倍
-- [[ICP (Ideal Customer Profile)]]：可证伪的理想客户画像定义框架，包含公司特征、行为限定和排除条件三层结构
-- [[Multi-Channel Sequence Architecture]]：8-12 次触点跨越 3-4 周的多渠道触达序列，每触点必须增加新的价值角度
-- [[Account Tiering Model]]：三层账户分级模型（Tier 1 深度多线程 / Tier 2 半个性化序列 / Tier 3 自动化轻定制）
+- [[Signal-Based Selling]]：通过识别买家行为信号（购买意图、组织变化、技术栈变化）触发精准外展，而非依赖批量冷触达
+- [[ICP (Ideal Customer Profile)]]：可证伪的理想客户画像，包含公司特征/行为资格/排除条件，而非模糊的 TAM 定义
+- [[Tiered Account Engagement]]：三层账户分层模型——Tier 1 深度个性化（50-100账户）、Tier 2 半个性化（200-500）、Tier 3 自动化（剩余ICP账户）
+- [[Multi-Channel Sequence]]：8-12 次触点 × 3-4 周 × 多渠道（Email/LinkedIn/Phone/Video），每次触点必须提供新价值角度
+- [[Speed-to-Signal]]：信号路由到正确销售的速度——目标 < 30 分钟，> 24 小时信号陈旧，> 72 小时竞争对手已介入
+- [[Cold Email Anatomy]]：高效冷邮件结构——小写3-5词标题 / 信号驱动开场白 / 买家语言表达价值 / 可选社会证明 / 单一低摩擦 CTA
 
 ## Key Entities
-- Outbound Strategist Agent：信号型出站策略师与序列架构师智能体，核心职责：设计多渠道触达序列、定义 ICP、按账户分层执行
-- SDR (Sales Development Representative)：角色演变对象，从批量操作员进化为信号监控专家
+- [[SDR (Sales Development Representative)]]：从 volume operator 向 revenue specialist 转型的新一代销售开发代表，Own 50-80 账户深度
+- [[G2]]：Tier 1 主动购买信号来源平台——G2 站点访问/评测页面浏览代表直接购买意图
+- [[BuiltWith]]：Tier 3 技术图谱信号来源——通过技术栈变化识别潜在需求
+- [[Loom]]：多渠道序列中 Video 触点工具——60 秒个性化视频展示与买家相关的具体内容
 
 ## Connections
-- [[sales-deal-strategist]] ← complements ← [[sales-outbound-strategist]]：出站负责发现和培育潜在机会，Deal Strategist 负责赢单策略
-- [[sales-discovery-coach]] ← feeds_into ← [[sales-outbound-strategist]]：发现阶段收集的 ICP 信号直接驱动出站序列的启动
-- [[sales-account-strategist]] ← extends ← [[sales-outbound-strategist]]：出站获取新客户后，Account Strategist 负责 Land-and-Expand 扩张
-- [[sales-proposal-strategist]] ← follows ← [[sales-outbound-strategist]]：出站触达后进入提案阶段，Proposal Strategist 构建赢单叙事
+- [[Deal Strategist]] ← complements ← [[Outbound Strategist]]：Outbound Strategist 负责 Pipeline 填充（前漏斗），Deal Strategist 负责成交策略（后漏斗）
+- [[Account Strategist]] ← extends ← [[Outbound Strategist]]：Outbound Strategist 定义 ICP 和分层账户策略，Account Strategist 负责 Tier 1 账户的深度维护
+- [[Sales Pipeline Analyst]] ← depends_on ← [[Outbound Strategist]]：Outbound Strategist 生成管道数据，Pipeline Analyst 分析转化率和 ROI
 
 ## Contradictions
-- 与 [[sales-deal-strategist]] 的区域：
-  - 冲突点：出站策略以信号触发为唯一启动条件；Deal Strategist 以 MEDDPICC 资质评估为赢单框架，两者对"何时介入"的定义角度不同
-  - 当前观点：出站必须在信号出现 30 分钟内行动，时机优先于资质评估
-  - 对方观点：任何 deal 进入赢单阶段前必须通过 MEDDPICC 全面评估
-  - 协调方式：两者处于销售漏斗的不同阶段——出站负责漏斗顶部（Signal → Contact），Deal Strategist 负责漏斗中部（Qualified → Commit）
+- 与传统 SDR KPI 体系冲突：
+  - 冲突点：传统衡量"100活动/天"，新模式衡量"管道质量和 Stage 1→2 转化率"
+  - 当前观点：活动量是战术指标，管道质量是战略指标；追踪活动量会激励刷 KPI 而非真正成交
+  - 对方观点：活动量可量化、易追踪、便于管理监督
diff --git a/wiki/sources/sales-outreach.md b/wiki/sources/sales-outreach.md
new file mode 100644
index 00000000..2409d437
--- /dev/null
+++ b/wiki/sources/sales-outreach.md
@@ -0,0 +1,52 @@
+---
+title: "Sales Outreach Agent"
+type: source
+tags: ["b2b-sales", "cold-outreach", "agent-personality", "sales-methodology"]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/sales-outreach.md]]
+
+## Summary（用中文描述）
+- 核心主题：B2B 销售外勤 Agent 的完整角色定义与可执行工作框架
+- 问题域：冷漠开拓邮件、跟进序列设计、异议处理、提案撰写、管道管理
+- 方法/机制：7 步触达序列、咨询式销售法（Consultative Selling）、SPIN/Challenger/MEDDIC 方法论、ICP 定义框架
+- 结论/价值：提供一套可操作的 AI Agent 销售外勤完整方案，涵盖从潜客挖掘到签单的完整生命周期
+
+## Key Claims（用中文描述）
+- 销售 Agent 核心原则：永远以"帮助客户购买"而非"推销产品"为出发点，冷邮件回复率的关键在于个性化与价值先行
+- 7 步触达序列（21天）：冷邮件 → LinkedIn 连接请求 → 跟进邮件 → LinkedIn 消息 → 电话+语音信箱 → 内容触达 → 断联邮件，其中断联邮件往往回复率最高
+- ICP 定义必须包含：企业特征（行业/规模/地域）、人物画像（头衔/痛点/成功指标）、触发事件（融资/高管变动/扩张）和不合格信号
+- 异议处理原则：以好奇心回应而非防御——异议是请求更多信息，先问后答
+- 提案必须在口头对齐价值与预算后才发送，且需在 24 小时内完成
+
+## Key Quotes
+> "Nobody wakes up excited to receive a cold email. But everyone is excited when someone reaches out who actually understands their problem and has a genuine solution." — Sales Outreach Agent 核心信念
+> "Best salespeople don't sell — they help people buy." — 咨询式销售哲学
+
+## Key Concepts
+- [[Consultative Selling]]：以深度理解客户情况为前提，通过提问驱动对话，帮助客户做出正确决策
+- [[SPIN Selling]]：情境（Situation）→ 问题（Problem）→ 暗示（Implication）→ 需求-回报（Need-Payoff），通过四类问题层层深入
+- [[Challenger Sale]]：教授客户未知信息，根据客户具体情况定制信息，自信把控对话节奏
+- [[MEDDIC/MEDDPICC]]：度量指标（Metrics）、经济买家（Economic Buyer）、决策标准、决策流程、痛点识别、冠军（Champion），用于复杂销售
+- [[Ideal Customer Profile]]（ICP）：理想客户画像，定义目标客户的企业特征、人物画像、触发事件和不合格条件
+- [[Cold Outreach]]：陌生开拓，通过个性化冷邮件、LinkedIn 消息和冷电话序列建立初次接触
+- [[Objection Handling]]：异议处理，以好奇心探索客户真实顾虑，而非直接反驳
+
+## Key Entities
+- Outreach/Salesloft/Apollo/HubSpot Sequences：销售 engagement 平台，用于执行和管理自动化触达序列
+- ICP：Ideal Customer Profile，理想客户画像，贯穿整个销售流程的筛选标准
+
+## Connections
+- [[Sales Engineer Agent]] ← extends ← [[Sales Outreach Agent]]（技术销售深化）
+- [[Sales Pipeline Analyst Agent]] ← depends_on ← [[Sales Outreach Agent]]（管道管理依赖外勤数据）
+- [[Sales Outbound Strategist Agent]] ← overlaps ← [[Sales Outreach Agent]]（外勤策略重叠）
+- [[Sales Proposal Strategist Agent]] ← depends_on ← [[Sales Outreach Agent]]（提案策略依赖外勤发现的痛点）
+- [[Sales Coach Agent]] ← supports ← [[Sales Outreach Agent]]（销售教练提供技能提升支持）
+
+## Contradictions
+- 与 [[Sales Outbound Strategist Agent]] 可能的视角差异：
+  - 冲突点：外勤 Agent 强调"咨询式"一对一个性化，策略师可能更偏向规模化/自动化外展
+  - 当前观点：高质量个性化 > 数量，50 个精心研究的潜客胜过 500 个泛化潜客
+  - 对方观点：规模化外展需要自动化和效率优先，个性化可以后续跟进
diff --git a/wiki/sources/sales-pipeline-analyst.md b/wiki/sources/sales-pipeline-analyst.md
index 64a9fb87..3ca8acf4 100644
--- a/wiki/sources/sales-pipeline-analyst.md
+++ b/wiki/sources/sales-pipeline-analyst.md
@@ -1,8 +1,8 @@
 ---
 title: "Pipeline Analyst Agent"
 type: source
-tags: [sales, revenue-operations, pipeline, forecasting, CRM, MEDDPICC]
-date: 2026-04-25
+tags: [sales, revenue-operations, pipeline, forecasting, CRM, MEDDPICC, deal-health]
+date: 2026-05-18
 ---
 
 ## Source File
@@ -10,37 +10,57 @@ date: 2026-04-25
 
 ## Summary（用中文描述）
 - 核心主题：Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent，将 CRM 数据转化为可执行的 Pipeline 洞察，在问题演变为季度失误之前主动预警。
-- 问题域：销售 Pipeline 管理、收入预测准确性、Deal 质量评估、销售教练数据分析
-- 方法/机制：Pipeline Velocity 公式 + MEDDPICC 资格评分 + 多信号预测模型 + Deal 健康评分卡
-- 结论/价值：质量调整后的 Pipeline 覆盖度永远优于阶段加权覆盖度；每份 Pipeline 评估都应至少发现一个需要立即干预的 Deal；预测必须带置信区间而非单一数字。
+- 问题域：销售 Pipeline 管理、收入预测准确性、Deal 质量评估、销售教练数据分析、Revenue Operations 架构设计
+- 方法/机制：Pipeline Velocity 公式 + MEDDPICC 资格评分 + 多信号预测模型 + Deal 健康评分卡 + 预测性分析 + RevOps 架构设计 + 销售辅导分析
+- 结论/价值：质量调整后的 Pipeline 覆盖度永远优于阶段加权覆盖度；每份 Pipeline 评估都应至少发现一个需要立即干预的 Deal；预测必须带置信区间而非单一数字；AI 模式匹配消除销售乐观主义和管理层锚定两种最常见的人类偏见。
 
 ## Key Claims（用中文描述）
-- Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，四个变量均为诊断杠杆。
-- 目标覆盖比率：成熟可预测业务 3x，成长期或新市场 4-5x，新销售入职 5x+。
+- Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，四个变量均为独立诊断杠杆。
+- 目标覆盖比率：成熟可预测业务 3x，成长期或新市场 4-5x，新销售入职 5x+。质量调整覆盖度优于阶段加权覆盖度。
 - 晚期阶段 Deal 的 MEDDPICC 字段少于 5/8 即为资格不足，是预测失误的主要来源。
 - 多线程、利益相关者深度参与的 Deal 关闭率是同阶段单线程低活跃度 Deal 的 2-3 倍。
 - 预测必须输出 Commit（>90%置信）/Best Case（>60%）/Upside（<60%）三档，而非单一数字。
 - AI 驱动的预测评分消除两种最常见的人类偏见：销售乐观主义（永远"看起来很好"）和管理层锚定（从上一季度数字而非当前数据分析）。
+- 预测准确性指标：预测误差须在 10% 以内；高风险 Deal 须在季度结束前 30+ 天被识别。
+- CRM 中 $12M 的 Pipeline，经质量调整后可能只有 $4.8M 有效（陈旧 Deal + 资格数据缺失 + 历史阶段转化率调整）。
+- 销售辅导效果：每周辅导 2 小时以上赢单率 56%，vs 少于 30 分钟仅 43%；正式辅导项目配额完成率 91.2%。
 
 ## Key Quotes
 > "Quality-adjusted coverage discounts pipeline by deal health score, stage age, and engagement signals. A $5M pipeline with 20 stale, poorly qualified deals is worth less than a $2M pipeline with 8 active, well-qualified opportunities." — 质量调整原则：高质量少量 Pipeline 优于大量低质量 Pipeline
 > "Deals with fewer than 5 of 8 MEDDPICC fields populated are underqualified. Underqualified deals at late stages are the primary source of forecast misses." — 晚期阶段资格不足 Deal 是预测失误的主因
 > "The CRM shows $12M in pipeline. After adjusting for stale deals, missing qualification data, and historical stage conversion, the realistic weighted pipeline is $4.8M." — 数据质量对预测的影响示例
+> "Win rate dropped from 28% to 19% in mid-market this quarter. The drop is concentrated at the Evaluation-to-Proposal stage — 14 deals stalled there in the last 45 days." — 精确诊断原则示例
 
 ## Key Concepts
 - [[PipelineVelocity]]：Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，是 Revenue Operations 最核心的复合指标
 - [[MEDDPICC]]：8维度 Deal 资格评估框架（Metrics、Economic Buyer、Decision Criteria、Decision Process、Paper Process、Implicated Pain、Champion、Competition），用于诊断 Deal 质量和预测可行性
-- [[DealHealthScoring]]：通过资格深度、互动强度、进展速度三维度综合评估 Deal 健康状况的评分体系
+- [[DealHealthScoring]]：通过资格深度、互动强度、进展速度三维度综合评估 Deal 健康状况的评分体系（总分 0-36）
 - [[QualityAdjustedCoverage]]：质量调整后的 Pipeline 覆盖度，结合 Deal 健康评分、阶段年龄和互动信号对 Pipeline 进行折减
 - [[RevenueOperations]]：Revenue Operations 的核心分析方法论，活动指标驱动 Pipeline 指标，Pipeline 指标驱动收入结果
+- [[ForecastAccuracy]]：概率加权预测方法论，输出 Commit/Best Case/Upside 三档置信区间，而非单一数字
+- [[LeadIndicator]]：领先指标（活动、互动、Pipeline 创建）预测未来收入结果，先于滞后指标（收入、胜率、周期长度）出现
+- [[SalesCycleLength]]：平均销售周期长度及分 segment 趋势分析，周期延长是竞争压力、买方委员会扩大或资质缺口的早期信号
 
 ## Key Entities
 - [[SalesDealStrategist]]：Deal 策略制定 Agent，与 Pipeline Analyst 共同构成销售情报闭环（Pipeline Analyst 评估 Deal 质量，Deal Strategist 制定推进策略）
-- [[SalesAccountStrategist]]：客户策略 Agent，Pipeline Analyst 为其提供客户层级的 Pipeline 健康数据
-- [[SalesOutboundStrategist]]：外展策略 Agent，其创建的 Pipeline 机会进入 Pipeline Analyst 的监测体系
+- [[SalesAccountStrategist]]：客户策略 Agent，Pipeline Analyst 为其提供客户层级的 Pipeline 健康数据和 NRR 预警信号
+- [[SalesOutboundStrategist]]：外展策略 Agent，其创建的 Pipeline 机会进入 Pipeline Analyst 的 Pipeline Velocity 监测体系
+- [[SalesCoach]]：销售教练 Agent，Pipeline Analyst 提供 Deal 级别诊断数据用于辅导决策，Sales Coach 提供代表级别诊断数据用于辅导规划，两者共享 MEDDPICC 框架但应用场景不同
 
 ## Connections
-- [[SalesDealStrategist]] ← depends_on ← [[SalesPipelineAnalyst]]
-- [[SalesAccountStrategist]] ← depends_on ← [[SalesPipelineAnalyst]]
-- [[SalesOutboundStrategist]] ← creates_pipeline_for ← [[SalesPipelineAnalyst]]
-- [[SalesCoach]] ← uses_forecast_data ← [[SalesPipelineAnalyst]]
+- [[SalesDealStrategist]] ← depends_on ← [[SalesPipelineAnalyst]]（Pipeline Analyst 提供 Deal 质量评分数据，Deal Strategist 据此制定推进策略）
+- [[SalesAccountStrategist]] ← depends_on ← [[SalesPipelineAnalyst]]（Pipeline Analyst 提供客户层级 Pipeline 健康数据，支持 NRR 预警）
+- [[SalesOutboundStrategist]] ← creates_pipeline_for ← [[SalesPipelineAnalyst]]（出站活动创建的新 Pipeline 进入 Pipeline Analyst 的监测体系）
+- [[SalesCoach]] ← uses_forecast_data ← [[SalesPipelineAnalyst]]（预测数据驱动辅导方向，Deal 级别诊断支持辅导决策）
+
+## Contradictions
+- 与 [[sales-deal-strategist]] 预测视角张力：
+  - 冲突点：Pipeline Analyst 将 MEDDPICC 用于 Deal 质量评分和预测可行性判断；Deal Strategist 将 MEDDPICC 用于资格缺口识别和赢单策略制定。
+  - 当前观点（Pipeline Analyst）：MEDDPICC 是量化 Deal 健康和预测准确性的诊断工具，目标是提前识别高风险 Deal。
+  - 对方观点（Deal Strategist）：MEDDPICC 是推动 Deal 进展的战略工具，目标是制定具体赢单行动。
+  - 协调方案：两者互补而非冲突——Pipeline Analyst 在 Pipeline 层面识别风险 Deal，Deal Strategist 在单个 Deal 层面制定破局策略。数据从 Pipeline Analyst 流向 Deal Strategist。
+- 与 [[sales-coach]] MEDDPICC 应用视角差异：
+  - 冲突点：Pipeline Analyst 使用 MEDDPICC 评估 Deal 质量（客观数据驱动）；Sales Coach 使用 MEDDPICC 评估代表能力（辅导对话驱动）。
+  - 当前观点（Pipeline Analyst）：MEDDPICC 分数是 CRM 数据填充度的客观指标，反映 Deal 的实际资格深度。
+  - 对方观点（Sales Coach）：MEDDPICC 分数是辅导对话深度的指标，反映代表在发现和推进 Deal 方面的能力。
+  - 协调方案：共享 MEDDPICC 框架但应用于不同主体——Pipeline Analyst 评估 Deal，Sales Coach 评估代表，两者数据可交叉验证。
diff --git a/wiki/sources/sales-proposal-strategist.md b/wiki/sources/sales-proposal-strategist.md
index fc0fa01e..c2a1fe42 100644
--- a/wiki/sources/sales-proposal-strategist.md
+++ b/wiki/sources/sales-proposal-strategist.md
@@ -1,51 +1,50 @@
 ---
-title: "Sales Proposal Strategist"
+title: "Sales Proposal Strategist Agent"
 type: source
-tags: ["sales", "proposal", "RFP", "win-themes", "narrative", "persuasion"]
-date: 2026-04-20
+tags: []
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/sales/sales-proposal-strategist.md]]
+- [[Agent/agency-agents/sales/sales-proposal-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：销售提案策略师 Agent 的系统化提案撰写方法论——将 RFP 响应从合规检查清单转化为有说服力的赢单叙事
-- 问题域：企业级销售提案、RFP 响应、竞争性投标、赢标主题开发、执行摘要撰写
-- 方法/机制：三幕提案叙事结构（理解挑战→解决方案旅程→转变状态）、3-5 个赢标主题矩阵、执行摘要五步模板、说服架构（首因/近因效应、认知负荷管理、社会认同排序、损失厌恶框架）、内容运营体系
-- 结论/价值：提案的胜负在开篇 100 词内决定；叙事是差异化核心；在能力趋同的商品化市场中，说服力即竞争力
+- 核心主题：销售提案撰写策略专家 Agent，将 RFP 响应转化为具有说服力的"赢叙事"（Win Narrative）
+- 问题域：B2B 销售场景中的提案撰写，核心痛点是技术方案优秀却输给讲更好故事的竞争对手
+- 方法/机制：三幕式提案叙事结构（理解挑战→方案旅程→转化状态）、3-5 个赢主题矩阵（Win Theme Matrix）、执行摘要五步结构、竞争定位技巧、内容运营体系
+- 结论/价值：提案是说服工具而非合规清单；叙事是最强差异化因素；内容按主题组织而非按章节组织
 
 ## Key Claims（用中文描述）
-- 赢标主题必须贯穿执行摘要、解决方案叙事、案例研究和定价逻辑——孤立的主题等于隐形的主题
-- 提案在开篇 100 词内决定胜负：评估者通过前 100 词判断供应商是否真正理解他们的业务
-- 执行摘要不是提案的摘要，而是提案的终局论证，应放在最前面
-- 永远不要直接批评竞争对手——将自身优势框架为直接利益，让对比自然形成
-- 定价在价值之后：先建立 ROI 案例、量化问题成本，在买方看到数字之前锚定成果而非成本
-- 内容库应按赢标主题而非章节组织——加速未来提案并保持叙事一致性
+- **赢主题 + 叙事整合**：提案的每个章节都必须围绕同一套 3-5 个赢主题展开，孤立的主题等于无形的主题
+- **执行摘要是关闭辩论**：执行摘要不是提案的摘要，而是提案的最终辩论，放在最前面；高级评审者往往只看这一页
+- **对比但不批评**：永远不直接批评竞争对手，将自身优势定位为直接收益，让对比自然呈现
+- **先价值后定价**：先建立 ROI 案例、量化问题成本、确立方法价值，再让买家看到数字；以交付成果而非成本支出来锚定定价
+- **微故事 > 大数据**：在技术章节中嵌入 2-4 句真实挑战解决微故事，比大数据点更能让人记住
 
 ## Key Quotes
-> "Proposals are won on clarity and lost on generics." — 核心理念：泛泛而谈即失败
-> "The executive summary is the proposal's closing argument, placed first." — 执行摘要的本质定义
-> "Every proposal needs 3-5 win themes: compelling, client-centric statements that connect your solution directly to the buyer's most urgent needs." — 赢标主题的定义
-> "Micro-stories win sections. Teams that embed micro-stories within technical sections achieve measurably higher evaluation scores." — 微故事的力量
+> "Proposals are won on clarity and lost on generics." — 提案的成败取决于清晰度，泛泛而谈必然失败
+> "The executive summary is not a summary of the proposal. It is the proposal's closing argument, placed first." — 执行摘要是放在开头的最终辩论，而非提案的摘要
+> "In commoditized markets where capabilities converge, the narrative is the differentiator." — 在能力趋同的商品化市场中，叙事才是最有力的差异化因素
+> "No empty adjectives. 'Robust,' 'cutting-edge,' 'best-in-class,' and 'world-class' are noise." — 空洞形容词是噪音，必须用具体数据替代
 
 ## Key Concepts
-- [[WinThemes|赢标主题（Win Themes）]]：连接解决方案与买方最紧迫需求的核心叙事陈述，贯穿整个提案
-- [[ThreeActProposalNarrative|三幕提案叙事（Three-Act Proposal Narrative）]]：理解挑战→解决方案旅程→转变状态
-- [[ExecutiveSummary|执行摘要（Executive Summary）]]：提案的终局论证，非摘要
-- [[CaptureStrategy|捕获策略（Capture Strategy）]]：RFP 发布前的预定位和关系映射
-- [[PersuasionArchitecture|说服架构（Persuasion Architecture）]]：首因/近因效应、认知负荷管理、社会认同排序、损失厌恶框架
-- [[RFP|RFP（Request for Proposal）]]：招标书/需求建议书
-- [[WinThemeMatrix|赢标主题矩阵（Win Theme Matrix）]]：评估主题与买方需求、差异化因素、证明点映射关系的结构化工具
+- [[Win Theme（赢主题）]]：将解决方案与买家最迫切需求直接连接的 3-5 个以买家为中心的声明，是贯穿全提案的叙事支柱
+- [[三幕式提案叙事]]：Act I 理解挑战（建立信任）→ Act II 方案旅程（主题落地）→ Act III 转化状态（量化未来）
+- [[执行摘要五步结构]]：镜像买家处境 → 引入核心张力 → 呈现论点 → 提供证明 → 以转化状态收尾
+- [[内容运营体系（Content Operations）]]：按赢主题而非按章节组织的可复用内容库，加速未来提案并保持叙事一致性
+- [[赢主题矩阵（Win Theme Matrix）]]：将每个赢主题映射到买家需求、差异化证明点和出现的提案章节的交叉分析工具
+- [[竞争定位]]：通过直接收益创造有机对比，而非批评竞争对手的差异化策略
+- [[Black Hat Review]]：模拟竞争对手提案的攻防评审，提前发现并修补提案漏洞
 
 ## Key Entities
-- 无特定命名实体（人/公司/产品/项目）
+- [[Sales Coach Agent]]：同为 The Agency Sales 部门的 Agent，Sales Coach 侧重销售过程中的教练与发现技巧，本 Agent 侧重提案撰写与赢主题构建；两者在销售漏斗中顺序协作（发现 → 提案）
+- [[Deal Strategist Agent]]：同为 The Agency Sales 部门的 Agent，Deal Strategist 侧重交易策略与谈判，本 Agent 侧重提案文档的说服力构建；两者互补（策略 + 呈现）
+- [[Account Strategist Agent]]：同为 The Agency Sales 部门的 Agent，Account Strategist 侧重客户关系与账户规划，本 Agent 将账户策略转化为可提交的提案语言
 
 ## Connections
-- [[SalesCoach]] ← related_to ← [[SalesProposalStrategist]]（同属销售 Agent 体系）
-- [[SalesDiscoveryCoach]] ← related_to ← [[SalesProposalStrategist]]（发现阶段为提案策略提供输入）
-- [[SalesEngineer]] ← related_to ← [[SalesProposalStrategist]]（技术销售工程师提供提案技术支撑）
-- [[SalesOutboundStrategist]] ← related_to ← [[SalesProposalStrategist]]（外展策略为提案创造机会）
-- [[SalesDealStrategist]] ← related_to ← [[SalesProposalStrategist]]（deal 策略与提案策略协同）
+- [[Sales Engineer Agent]] ← 共享 → [[Sales Proposal Strategist]]：Sales Engineer 提供技术深度，Proposal Strategist 将技术深度转化为叙事逻辑
+- [[Deal Strategist Agent]] ← 配合 → [[Sales Proposal Strategist]]：Deal Strategist 确定谈判策略，Proposal Strategist 将策略落地为提案语言
+- [[Account Strategist Agent]] ← 输入 → [[Sales Proposal Strategist]]：Account Strategist 提供账户情报与关系网络，Proposal Strategist 将账户洞察转化为客户为中心的赢主题
 
 ## Contradictions
-- 暂无冲突
+- 与 [[Sales Coach Agent]] 的信息存在边界模糊：Sales Coach 覆盖销售流程中的发现与诊断，本 Agent 覆盖从 RFP 到提案提交的叙事构建。分工边界：发现阶段用 Coach，提案阶段用 Strategist，两者通过账户情报传递衔接。
diff --git a/wiki/sources/scenario-enterprise-feature.md b/wiki/sources/scenario-enterprise-feature.md
new file mode 100644
index 00000000..8fa34a6f
--- /dev/null
+++ b/wiki/sources/scenario-enterprise-feature.md
@@ -0,0 +1,55 @@
+---
+title: "Runbook: Enterprise Feature Development"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/runbooks/scenario-enterprise-feature.md]]
+
+## Summary（用中文描述）
+- 核心主题：企业级产品大型功能开发的多 Agent 编排完整手册
+- 问题域：合规、安全、质量门控不可妥协，20-30 个 Agent 并行协作，多方利益相关者需对齐
+- 方法/机制：NEXUS-Sprint 模式，12 周五阶段流水线（需求架构→基础构建→开发→硬化→发布），每个阶段设置 Quality Gate，Reality Checker 默认返回 NEEDS WORK
+- 结论/价值：可复用的企业级功能开发 Agent 编排模板，量化质量指标 + 结构化风险矩阵 + 分层利益相关者沟通节奏
+
+## Key Claims（用中文描述）
+- 多 Agent 编排（20-30 个 Agent）可将企业级功能开发在 6-12 周内完成，同时满足合规、安全和质量门控要求
+- 利益相关者沟通必须分层分级：执行层每日、产品周报、主管层双周 SCQA 简报（≤500 词）、合规/财务月度报告
+- Reality Checker 质量门默认返回 NEEDS WORK（而非默认通过），强制修复循环直至完全合规
+- 代码覆盖率 >80%、API P95 响应时间 <200ms、无关键安全漏洞、品牌一致性 ≥95%、10 倍流量压测通过，才能发布
+
+## Key Quotes
+> "Reality Checker → Integration testing (default: NEEDS WORK)" — 最终质量门必须主动修复，不接受默认通过
+> "Legal Compliance Checker involved from Day 1" — 合规从项目第一天介入，而非事后补查
+> "Sprint Prioritizer enforces MoSCoW, Project Shepherd manages changes" — 范围蔓延通过 MoSCoW 优先级强制管控
+
+## Key Concepts
+- [[Quality-Gate]]：每个阶段结束的结构化验收点，未通过则进入修复循环
+- [[RICE-Scoring]]：Sprint Prioritizer 用于对 Product Backlog 进行评分排序的方法论（Reach/Impact/Confidence/Effort）
+- [[MoSCoW]]：需求优先级框架（Must have/Should have/Could have/Won't have），防止范围蔓延
+- [[Canary-Deployment]]：灰度发布策略（5%→25%→100%），通过 DevOps Automator 逐步放量降低发布风险
+- [[WCAG-2.1-AA]]：Web 内容无障碍指南 2.1 AA 级，是企业级功能发布的强制可访问性要求
+
+## Key Entities
+- [[Agents-Orchestrator]]：流水线控制器，管理 Dev↔QA 循环的核心协调 Agent
+- [[Project-Shepherd]]：跨职能协调员，负责利益相关者分析和变更管理
+- [[Sprint-Prioritizer]]：Product Backlog 管理，使用 RICE 评分和 MoSCoW 防止范围蔓延
+- [[Reality-Checker]]：最终质量门，默认返回 NEEDS WORK，强制修复循环
+- [[Evidence-Collector]]：视觉 QA，通过截图记录每个任务的质量证据
+- [[Experiment-Tracker]]：A/B 测试追踪，为关键功能设置实验对照
+- [[Legal-Compliance-Checker]]：合规审查 Agent，从项目第一天介入直至最终审计通过
+- [[Performance-Benchmarker]]：性能基准测试，包括 P95 响应时间 <200ms 和 10 倍流量压测
+- [[Executive-Summary-Generator]]：执行层简报生成器，使用 SCQA 框架（Situation/Complication/Question/Answer）
+- [[DevOps-Automator]]：CI/CD 和灰度发布（Canary Deployment 5%→25%→100%）执行
+
+## Connections
+- [[scenario-marketing-campaign]] ← similar_pattern ← 本 Runbook：两者均为多 Agent 协作+NEXUS-Sprint 框架，营销场景侧重内容传播，本 Runbook 侧重企业合规开发
+- [[scenario-incident-response]] ← related ← 本 Runbook：应急响应是第 11-12 周 Week 11 "Final Judgment" 的关键前置知识
+- [[NEXUS]] ← managed_by ← [[Agents-Orchestrator]]：NEXUS 框架通过 Agents Orchestrator 实现多 Agent 流水线编排
+- [[agent-activation-prompts]] ← template_source ← 本 Runbook：本 Runbook 定义的 Agent 角色使用 [[agent-activation-prompts]] 中的标准化模板激活
+
+## Contradictions
+- 与 [[scenario-marketing-campaign]] 无冲突：营销场景重内容传播，本 Runbook 重合规开发，方法论互补而非矛盾
+- 与 [[scenario-incident-response]] 无冲突：应急响应是发布后事件，本 Runbook 是发布前流程，时序无重叠
diff --git a/wiki/sources/scenario-incident-response.md b/wiki/sources/scenario-incident-response.md
new file mode 100644
index 00000000..94189abf
--- /dev/null
+++ b/wiki/sources/scenario-incident-response.md
@@ -0,0 +1,56 @@
+---
+title: "Incident Response Runbook"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/runbooks/scenario-incident-response.md]]
+
+## Summary（用中文描述）
+- 核心主题：NEXUS 多 Agent 协作框架下的生产事故结构化响应手册——从检测到复盘的完整五阶段流水线
+- 问题域：多 Agent 协作生产环境中的事故响应协调问题（P0~P3 四个严重等级，3-8 个 Agent 并行响应）
+- 方法/机制：严重等级分类 → 按等级激活对应响应团队 → 五阶段标准响应流程（检测分诊/调查/缓解/解决验证/复盘）→ 标准化沟通模板 → 升级矩阵
+- 结论/价值：为 NEXUS 框架提供即插即用的生产事故响应 SOP，实现多 Agent 无缝协调，避免事故响应混乱导致的影响扩大
+
+## Key Claims（用中文描述）
+- P0（Critical）事故需要 6 种 Agent 角色（总指挥/部署回滚/后端调查/前端调查/用户沟通/高管简报）全并行激活
+- 五阶段响应流程中，调查阶段（Step 2）采用并行调查模式——基础设施/后端/DevOps 三路同时启动
+- 缓解阶段（Step 3）根据根因类型（部署/基础设施/代码/外部依赖）触发差异化决策树
+- 复盘必须在 48 小时内完成，包含时间线重建/根因分析/影响评估/预防措施/行动项五项
+- 升级矩阵定义了 P0 30分钟未解决/P1 2小时未解决/数据泄露/用户数据影响/营收影响>$X 五类升级条件
+
+## Key Quotes
+> "Something is broken in production. Users are affected. Speed of response matters, but so does doing it right." — 场景设定说明
+
+## Key Concepts
+- [[Severity-Classification]]：P0-P3 四级事故严重等级划分及对应响应时间
+- [[Incident-Response-Sequence]]：检测分诊→调查→缓解→解决验证→复盘五阶段标准流程
+- [[Response-Team-Activation]]：按严重等级动态激活对应 Agent 团队规模（3-8人）
+- [[Communication-Templates]]：状态页面更新模板和高管简报模板的标准化格式
+- [[Escalation-Matrix]]：事故未解决时的升级条件和升级对象矩阵
+
+## Key Entities
+- [[Infrastructure-Maintainer]]：基础设施维护 Agent——P0/P1 事故指挥官，负责评估范围、协调响应
+- [[DevOps-Automator]]：DevOps 自动化 Agent——负责部署/回滚/基础设施变更执行
+- [[Backend-Architect]]：后端架构 Agent——P0/P1 事故中负责数据库/API/服务间通信诊断
+- [[Frontend-Developer]]：前端开发 Agent——负责客户端侧问题诊断
+- [[Support-Responder]]：支持应答 Agent——负责用户沟通和状态页面更新
+- [[Executive-Summary-Generator]]：高管简报生成 Agent——P0 事故专用，负责实时向利益相关方更新
+- [[Evidence-Collector]]：证据收集 Agent——验证修复有效性和截图证据
+- [[API-Tester]]：API 测试 Agent——API 相关事故回归测试执行
+- [[Workflow-Optimizer]]：工作流优化 Agent——主导复盘会议和预防措施制定
+
+## Connections
+- [[NEXUS]] ← 属于 ← [[scenario-incident-response]]（NEXUS 框架内的生产事故响应场景）
+- [[scenario-startup-mvp]] ← 并行场景 ← [[scenario-incident-response]]（同为 NEXUS runbook 场景）
+- [[scenario-marketing-campaign]] ← 并行场景 ← [[scenario-incident-response]]（同为 NEXUS runbook 场景）
+- [[handoff-templates]] ← extends ← [[scenario-incident-response]]（handoff-templates 中的 Incident Handoff 模板是本场景交接格式）
+- [[engineering-incident-response-commander]] ← 相关 ← [[scenario-incident-response]]（Incident Response Commander Agent 是本 runbook 的具体角色定义）
+
+## Contradictions
+- 与 [[engineering-incident-response-commander]] 的角色命名差异：
+  - 冲突点：runbook 中称"Incident Commander"，commander 源文件中称"Incident Response Commander"
+  - 当前观点：runbook 侧重"指挥官"角色功能，commander 文档侧重 Agent"个性定义"
+  - 协调方案：视为同一角色的不同视角——runbook 定义做什么，commander 文档定义怎么做的行为规范
diff --git a/wiki/sources/scenario-marketing-campaign.md b/wiki/sources/scenario-marketing-campaign.md
new file mode 100644
index 00000000..c57913fa
--- /dev/null
+++ b/wiki/sources/scenario-marketing-campaign.md
@@ -0,0 +1,56 @@
+---
+title: "Runbook: Multi-Channel Marketing Campaign"
+type: source
+tags: []
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/runbooks/scenario-marketing-campaign.md]]
+
+## Summary（用中文描述）
+- 核心主题：多渠道营销活动的完整 Agent 协作执行手册，涵盖从策略规划到内容生产、从发布执行到数据优化的全流程。
+- 问题域：多平台同步营销活动的组织与协调，品牌一致性保证，效果追踪与持续优化。
+- 方法/机制：通过 NEXUS 框架编排 15 个专业 Agent 角色（核心团队 + 平台专家 + 支持团队），分四周执行；每日/每周迭代优化，A/B 测试驱动决策。
+- 结论/价值：提供了一套可复用的多渠道营销 Agent 编排模板，适用于 2-4 周短期活动，数据驱动、平台差异化、品牌统一。
+
+## Key Claims（用中文描述）
+- 多 Agent 协作可将营销活动执行效率提升 3-5 倍，通过专业化分工实现平台差异化内容与品牌一致性兼顾。
+- 数据驱动的迭代优化机制（前 48 小时性能报告 + A/B 测试）可将获客成本（CPA）降低 20-40%。
+- 品牌守护机制（每条内容发布前审查 + 每周一致性审计）是防止多渠道营销中品牌稀释的关键。
+
+## Key Quotes
+> "Campaign needs to drive measurable acquisition and engagement." — 活动目标定义：获取与互动必须可量化
+> "Brand consistency across all channels" — 品牌一致性是核心约束
+> "First 48-hour performance report" — 数据驱动优化的最小反馈周期
+
+## Key Concepts
+- [[Multi-Channel Marketing Campaign]]：跨 Twitter/X、TikTok、Instagram、Reddit、Email、Blog、Paid Ads 等多平台同步执行的营销活动，通过专业化 Agent 分工实现平台差异化内容生产与统一的品牌管理。
+- [[Campaign KPIs]]：多渠道营销活动的关键绩效指标体系，涵盖总量指标（总触达、互动率、CTR、CVR、CPA、品牌情感）、平台专属指标（各平台主次 KPI）及 A/B 测试完成数。
+- [[Brand Consistency Checkpoint]]：品牌一致性检查机制，包括发布前内容审查、每周视觉一致性审计、每周语音语调检查、上线前及每周合规审查。
+- [[Conversion Funnel]]：增长黑客负责的转化漏斗设计，包括落地页优化、转化路径映射、病毒传播机制（推荐、分享）、渠道预算分配。
+
+## Key Entities
+- [[Social Media Strategist]]：活动核心负责人，负责跨平台策略、KPI 定义、每周性能复盘及策略调整。
+- [[Content Creator]]：内容生产核心，负责多格式内容创作（博客、邮件、落地页文案、视频脚本、社交媒体适配文案）以及活动发布和邮件推送。
+- [[Growth Hacker]]：增长策略负责人，负责获取漏斗设计、落地页优化、付费活动激活、渠道优化及 ROI 分析。
+- [[Brand Guardian]]：品牌一致性守护者，负责活动视觉指南、语气语调规范、发布前内容审查及每周品牌一致性审计。
+- [[Analytics Reporter]]：数据分析负责人，负责实时仪表盘监控、每日性能快照、每周活动报告及最终综合分析。
+- [[Trend Researcher]]：趋势研究专家，负责市场时机分析（热点话题、竞品活动分析、最佳发布时机）。
+- [[Experiment Tracker]]：A/B 测试追踪专家，负责配置测试变体、收集早期结果、管理新测试及汇总测试结果。
+- [[Legal Compliance Checker]]：法律合规专家，负责广告披露要求、平台广告政策及监管约束审查。
+- [[Twitter Engager]]：Twitter/X 平台专家，负责发布推文（10-15 条启动线程）、每日互动推文、回复模板及话题标签策略。
+- [[TikTok Strategist]]：TikTok 内容专家，负责视频创意（3-5 个视频）、钩子策略、趋势音频/格式对齐及发布排期。
+- [[Instagram Curator]]：Instagram 视觉内容专家，负责信息流帖子（轮播、单图）、Stories 内容、Reels 创意概念及视觉美学指南。
+- [[Reddit Community Builder]]：Reddit 社区运营专家，负责子版块定向、价值优先帖子草稿、评论互动计划及 AMA 准备。
+- [[Executive Summary Generator]]：活动执行总结生成专家，负责活动执行总结报告的撰写。
+
+## Connections
+- [[NEXUS Strategy]] ← orchestrates ← [[scenario-marketing-campaign]]（NEXUS 框架编排此多渠道营销活动）
+- [[Content Creator]] ← produces content for ← [[Social Media Strategist]]（内容创作者为策略师提供素材）
+- [[Brand Guardian]] ← reviews all content before ← [[Twitter Engager]]（品牌守护审查后发布）
+- [[Analytics Reporter]] ← feeds data to ← [[Growth Hacker]]（数据报告驱动增长优化）
+- [[Trend Researcher]] ← informs timing of ← [[TikTok Strategist]]（趋势研究影响 TikTok 发布时间）
+
+## Contradictions
+- 无已知冲突页面。
diff --git a/wiki/sources/scenario-startup-mvp.md b/wiki/sources/scenario-startup-mvp.md
new file mode 100644
index 00000000..28ac7869
--- /dev/null
+++ b/wiki/sources/scenario-startup-mvp.md
@@ -0,0 +1,52 @@
+---
+title: "Runbook: Startup MVP Build"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/strategy/runbooks/scenario-startup-mvp.md]]
+
+## Summary（用中文描述）
+- 核心主题：初创公司 MVP（最小可行产品）4-6 周快速构建的多 Agent 编排执行手册
+- 问题域：初创公司如何在极短周期内完成从想法到真实用户可用的产品，同时兼顾速度与质量
+- 方法/机制：NEXUS-Sprint 模式，分周分阶段执行，18-22 个专业 Agent 并行协作，Dev↔QA 循环，质量门控
+- 结论/价值：提供可复用的 MVP 构建流水线模板，强调 Sprint Prioritizer 执行 MoSCoW 优先级管理、Evidence Collector 覆盖每个任务的质量保证、Reality Checker 最终质量门槛
+
+## Key Claims（用中文描述）
+- NEXUS-Sprint 模式通过 18-22 个专业 Agent 并行协作，可在 4-6 周内完成从想法到真实用户可用的产品
+- Sprint Prioritizer 通过 RICE 评分和 MoSCoW 强制执行，防止范围蔓延（"Won't" means won't）
+- Evidence Collector 运行于每个任务，确保 QA 不因追求速度而被跳过
+- Reality Checker 在 Week 4 Day 5 做最终质量门槛判定，达不到标准则进入 2-3 天快速修复循环
+
+## Key Quotes
+> "You're building a startup MVP — a new product that needs to validate product-market fit quickly. Speed matters, but so does quality." — 场景定义核心矛盾
+> "Evidence Collector runs on EVERY task — no exceptions" — QA 不可跳过的关键原则
+
+## Key Concepts
+- [[RICE-Scoring]]：优先级评分方法，用于 Sprint Prioritizer 对 backlog 进行评分排序
+- [[MoSCoW]]：M(Must)/S(Should)/C(Could)/W(Won't) 优先级分类，"Won't" 即明确放弃
+- [[Quality-Gate]]：阶段性质量门槛判定，Architecture Package/Sprint Review/Gate Decision 多层级质量门控
+- [[NEXUS-Sprint]]：NEXUS 框架下的 Sprint 执行模式，Dev↔QA 并行循环
+
+## Key Entities
+- [[Agents-Orchestrator]]：流水线控制器，管理 Dev↔QA 循环
+- [[Sprint-Prioritizer]]：Backlog 管理者，执行 RICE 评分 + Sprint 规划
+- [[Evidence-Collector]]：QA Agent，每个任务完成后必须运行
+- [[Reality-Checker]]：最终质量门槛，Gate Decision 判定者
+- [[DevOps-Automator]]：CI/CD 和部署自动化
+- [[Growth-Hacker]]：用户获取策略（Week 3+ 激活）
+- [[Studio-Producer]]：关键决策拍板人（概念 Go/No-Go、发布时机）
+
+## Connections
+- [[scenario-enterprise-feature]] ← similar_structure ← [[scenario-startup-mvp]]（均为 NEXUS-Sprint 模式，Agent 角色重叠）
+- [[scenario-marketing-campaign]] ← shared_agents ← [[scenario-startup-mvp]]（Growth-Hacker/Content-Creator/Social-Media-Strategist 共用）
+- [[scenario-incident-response]] ← extends ← [[scenario-startup-mvp]]（Incident Response 用于 MVP 上线后的生产事故响应）
+
+## Contradictions
+- 与 [[scenario-enterprise-feature]] 冲突：
+  - 冲突点：时间维度（4-6 周 vs 12 周）和团队规模（18-22 Agent vs 20-30 Agent）
+  - 当前观点：初创公司 MVP 场景强调速度优先，接受技术债，快速验证
+  - 对方观点：企业级功能场景强调质量合规，接受更长周期确保架构可扩展
+  - 协调：两者适用场景不同，均为 NEXUS-Sprint 的不同配置模板，企业功能开发后可复用本 runbook 的 Growth Team 扩展模式
diff --git a/wiki/sources/security.md b/wiki/sources/security.md
new file mode 100644
index 00000000..5c04ff81
--- /dev/null
+++ b/wiki/sources/security.md
@@ -0,0 +1,42 @@
+---
+title: "Security Policy"
+type: source
+tags: []
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/SECURITY.md]]
+
+## Summary（用中文描述）
+- 核心主题：agency-agents 项目的安全漏洞报告政策和贡献者安全最佳实践
+- 问题域：开源 agent 项目的安全漏洞管理与代码安全规范
+- 方法/机制：通过 GitHub Security 私密报告渠道、明确响应时间线、分层安全范围（Agent 文件 vs Shell 脚本）、贡献者行为准则
+- 结论/价值：为 agent 项目的安全运营提供了清晰的治理框架，强调 prompt 注入风险
+
+## Key Claims（用中文描述）
+- 安全漏洞应通过 GitHub Security 私密渠道报告，而非公开 GitHub Issues
+- 漏洞响应时间线：48 小时内确认，7 天内完成初步评估，修复时间视严重程度而定
+- Agent Markdown 文件为非可执行内容，不应存储 API keys 或凭证
+- Shell 脚本（install.sh、convert.sh、lint-agents.sh）为可执行文件，合并前必须审查
+- 贡献者应主动举报可疑的 prompt 注入式 agent 定义
+
+## Key Quotes
+> "Do NOT open a public GitHub issue for security vulnerabilities. Open a private security advisory via GitHub Security tab." — 安全报告原则
+> "Shell scripts must be reviewed before merging" — Shell 脚本合并要求
+
+## Key Concepts
+- [[PromptInjection]]：可疑 agent 定义试图注入恶意 prompt 的行为，需主动上报
+- [[SecurityAdvisory]]：GitHub 私密安全咨询渠道，用于负责任的漏洞披露
+- [[AgentSecurity]]：Agent Markdown 文件的安全边界——非可执行、无凭证存储
+
+## Key Entities
+- [[AgencyAgents]]：该安全政策所属的 agent 定义仓库项目
+
+## Connections
+- [[Contributing]] ← informs ← [[SecurityPolicy]]
+- [[SecurityPolicy]] ← governs ← [[AgentFiles]]
+- [[SecurityPolicy]] ← governs ← [[ShellScripts]]
+
+## Contradictions
+- （无冲突检测到此页面与现有 Wiki 内容存在矛盾）
diff --git a/wiki/sources/specialized-chief-of-staff.md b/wiki/sources/specialized-chief-of-staff.md
new file mode 100644
index 00000000..70e10eb1
--- /dev/null
+++ b/wiki/sources/specialized-chief-of-staff.md
@@ -0,0 +1,52 @@
+---
+title: "Chief of Staff"
+type: source
+tags: ["agent", "executive", "operations", "coordination"]
+date: 2026-05-02
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/specialized-chief-of-staff.md]]
+
+## Summary（用中文描述）
+- 核心主题：首席运营官（CoS）——为创始人/高管提供全方位运营协调的 AI Agent，充当主心骨与整个组织之间的"主协调者"
+- 问题域：高管的时间管理、信息过滤、流程一致性、决策路由、文档依赖管理
+- 方法/机制：三层信息过滤机制（立即上报 / 处理后简报 / 暂存待问）、文档依赖图维护、标准化流程强制执行、影响力定位
+- 结论/价值：让高管拥有清晰的大脑，将一切可承接的工作从高管手中移除，自身活动不可见，高管的清晰思考即是产出
+
+## Key Claims（用中文描述）
+- CoS 持有比组织中任何人都多的上下文，利用这些上下文在碰撞发生前阻止它们
+- CoS 的成功标准是：高管拥有清晰的大脑，能真正思考
+- 信息过滤器三层框架：立即上报（影响公司目标/组织/避免偷袭）/ 处理后简报（小型修复）/ 暂存待问（优化建议）
+- 流程一致性是核心交付物：格式、标准、SOP 必须 100% 执行，无商榷余地
+- 文档依赖图：当决策 X 变化时，识别所有受影响文档，主动级联更新，不遗漏任何一份
+- 输出路由：交付物不仅要创建，还要放在正确位置、格式化正确、确认可达，位置错误等同于不存在
+- 永远不重复：同一问题不问第二次，每次纠正是数据点
+
+## Key Quotes
+> "I don't own any function. I own the space between all of them." — CoS 自我定位
+> "The CoS runs the place. The boss leads. I make sure the boss has space to do the one thing nobody else can." — CoS 终极使命
+> "Activity is not progress. A checklist getting shorter is not the same as the operation getting better." — 忙碌≠进步
+
+## Key Concepts
+- [[首席运营官（CoS）]]：为创始人/高管提供全方位运营协调的 AI Agent，不是运营人员，不是项目经理，是运营、项目经理与主管之间的"主协调者"
+- [[三层信息过滤器]]：立即上报 / 处理后简报 / 暂存待问，根据信任积累动态调整阈值
+- [[文档依赖图]]：维护决策与受影响文档之间的映射，主动级联更新所有相关文档
+- [[流程一致性]]：所有可重复系统保持运作方式一致，格式、标准、SOP 100% 执行
+- [[影响力定位]]：交付物不仅要创建，更要放在正确位置、在正确时机面向正确受众
+- [[ADHD 感知支持]]：一次只呈现一件事，使用强视觉锚点，提供"离线标签"，温和引导偏离话题
+- [[多 Agent 编排]]：维护任何单个 Agent 都不持有的全局上下文，防止矛盾输出
+
+## Key Entities
+- 创始人/高管（Principal）：CoS 的服务对象，唯一做艰难决定的人
+- 组织（The Organization）：CoS 协调的对象，无具体名称
+
+## Connections
+- [[NEXUS Executive Brief]] ← 支撑 ← [[specialized-chief-of-staff]]
+- [[NEXUS Quick-Start Guide]] ← 支撑 ← [[specialized-chief-of-staff]]
+- [[project-manager-senior]] ← 相关于 ← [[specialized-chief-of-staff]]（角色重叠但职责不同：项目经理负责特定项目，CoS 负责所有缝隙）
+- [[support-infrastructure-maintainer]] ← 相关于 ← [[specialized-chief-of-staff]]（均涉及流程维护和一致性保障）
+
+## Contradictions
+- 与 [[project-manager-senior]] 可能的职责边界模糊：两者都涉及协调，但项目经理专注特定交付物，CoS 专注整体运转。当前页面认为两者不同，但未明确边界定义。
+- 与 [[support-infrastructure-maintainer]] 在"流程维护"上有重叠：两者都维护 SOP，但 support-infrastructure-maintainer 偏向技术基础设施，CoS 偏向运营流程。两者尚未在 Wiki 中明确定义边界。
diff --git a/wiki/sources/specialized-civil-engineer.md b/wiki/sources/specialized-civil-engineer.md
index e8fcf101..0b5acb5c 100644
--- a/wiki/sources/specialized-civil-engineer.md
+++ b/wiki/sources/specialized-civil-engineer.md
@@ -1,52 +1,57 @@
 ---
 title: "Specialized Civil Engineer Agent"
 type: source
-tags: ["agent", "civil-engineering", "structural-design", "geotechnical", "building-codes"]
-date: 2026-04-20
+tags: []
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/specialized-civil-engineer.md]]
+- [[Agent/agency-agents/specialized/specialized-civil-engineer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：面向 AI Agent 的土木与结构工程专家角色定义，涵盖全球设计标准体系、结构分析与岩土设计能力、建造文档合规全流程
-- 问题域：AI Agent 在建筑结构工程领域的专业化角色设计，涉及多国规范体系（Eurocode、ACI、AISC、ASCE、GB、IS、AIJ 等）的统一知识表示与任务执行框架
-- 方法/机制：通过结构化角色定义（身份记忆→核心使命→规范规则→交付物→工作流→高级能力）构建可执行的结构工程 Agent；提供钢梁/RC 梁/岩土计算示例作为能力基准
-- 结论/价值：产出安全、经济、可建造的结构设计，同时驾驭多管辖区域并发规范、多标准冲突解析、全生命周期碳评估等高级任务
+- 核心主题：土木与结构工程领域 AI Agent 的角色定义与能力规范，覆盖全球主要设计规范
+- 问题域：结构分析与设计、岩土工程评估、建筑规范合规、多标准国际项目
+- 方法/机制：基于 Eurocode、ACI、AISC、ASCE、GB、IS、AIJ 等全球规范进行结构计算和文档编制
+- 结论/价值：定义了一个可执行安全、经济、可建造结构设计的 AI 工程师 Agent，覆盖欧洲、北美、澳新、亚洲、中东等主要建筑市场规范体系
 
 ## Key Claims（用中文描述）
-- AI Agent 可通过规范引用驱动（"Per EN 1992-1-1 clause 6.2.3..."）的方式执行可验证的结构计算包
-- 多标准项目（IBC+Eurocode 混用等）中，Agent 可通过规范冲突识别→文档记录→保守优先→设计依据报告的流程提供可辩护的解决方案
-- 结构设计必须同时验证强度极限状态（ULS）和正常使用极限状态（SLS/挠度/振动），两者均满足方为合格
-- 岩土参数不得未经地勘报告或明确假设即行假定；沉降分析对差异沉降敏感结构为必做项
+- 土木工程师 Agent 必须同时验证强度极限状态（ULS）和正常使用极限状态（SLS）—— 两者缺一不可
+- 多标准项目需明确每项设计元素所依据的规范，并在设计依据报告中记录所有规范决策
+- 岩土参数必须有地基勘察报告支撑，严禁假设；沉降分析对差异沉降敏感结构为必做项
+- 地震设计必须验证延性等级要求和构造细部规定
+- 临时工程（开挖、支撑）与永久工程遵循同等规范要求
 
 ## Key Quotes
-> "Always check **both** strength (ULS) and serviceability (SLS) limit states" — 强度与正常使用双重验证原则
-> "Default to the more conservative requirement unless AHJ rules otherwise" — 多标准冲突时的默认处理策略
-> "Never assume soil parameters without a ground investigation report or clear stated assumptions" — 岩土参数假设的铁律
-> "Calculation packages must be self-contained: inputs, references, calculations, results" — 计算包自包含性要求
+> "Always check **both** strength (ULS) and serviceability (SLS) limit states" — 结构安全核心要求
+> "State the governing code, edition year, and national annex at the start of every calculation" — 规范合规基本要求
+> "Never assume soil parameters without a ground investigation report or clear stated assumptions" — 岩土工程严谨性要求
+> "Default to the more conservative requirement unless AHJ rules otherwise" — 多标准冲突处理策略
 
 ## Key Concepts
-- [[ULS]]（极限状态设计/Strength Limit State）：结构承载力极限状态，对应 Eurocode EN 1990 中的 ULS、ACI 318 LRFD
-- [[SLS]]（正常使用极限状态/Serviceability Limit State）：挠度、振动、裂缝控制，对应 EN 1990 SLS、ACI 318 serviceability provisions
-- [[National Annex]]（国家附录）：Eurocode 各成员国对 NDPs（国家确定参数）的本地化修订，是规范冲突的主要来源
-- [[AHJ]]（Authority Having Jurisdiction）：主管当局，拥有最终解释权，多标准项目需向 AHJ 确认
-- [[Basis of Design]]（设计依据）：记录所有关键假设、规范版本选择、荷载组合、设计决策的正式文件
-- [[Ductility Class]]（延性等级）：Eurocode EN 1998 的 DCL/DCM/DCH，地震设计中的结构延性要求分级
-- [[LRFD]]（荷载抗力系数设计）：美国 ACI/AISC 体系采用的设计方法，与 Eurocode 的部分系数法（EN 1990 DA1/DA2/DA3）思路相近但系数不同
-- [[BIM Coordination]]（BIM 协调）：结构模型导出 IFC 4.x、碰撞检测、穿楼板开孔、钢筋保护层协调等
+- ULS（强度极限状态）：Ultimate Limit State，结构承载能力极限状态，必须与 SLS 同时验证
+- SLS（正常使用极限状态）：Serviceability Limit State，包括挠度、振动等使用性能
+- National Annex（国家附件）：Eurocode 各国国家附件可修改 NDP（国家确定参数），必须逐个检查
+- Design Basis Report（设计依据报告）：记录所有规范决策、多标准冲突解决方案的文档
+- ULS/SLS双重验证：所有结构设计必须同时通过强度和正常使用极限状态检查
+- Ductility Class（延性等级）：EN 1998 分为 DCL/DCM/DCH，对应不同的构造细部要求
 
 ## Key Entities
-- [[Eurocode]]：欧洲规范体系 EN 1990–1999，覆盖结构设计荷载、混凝土/钢/木/砌体结构、岩土、抗震等九大领域，附各国 National Annex
-- [[AISC 360]]：美国钢结构设计规范（LRFD 与 ASD 双轨），含构件设计、连接设计、冷弯型钢结构
-- [[ACI 318]]：美国钢筋混凝土设计规范，LRFD/SD 方法，含特殊抗弯框架（SMF）抗震细部要求
-- [[ASCE 7]]：美国建筑及其他结构最小设计荷载规范，涵盖重力荷载、风荷载、地震荷载、冰雪荷载等第 2–31 章
-- [[EN 1997]]：Eurocode 岩土设计规范，含浅基础、深基础、挡土结构、土坡稳定的体系化设计方法
-- [[AIJ]]（Architectural Institute of Japan）：日本建筑学会规范，高抗震延性要求、响应谱法抗震设计指南
+- EN 1990–1999（Eurocode 规范族）：欧洲结构设计基础规范套件，含 10 个分册及多国国家附件
+- ACI 318（美国钢筋混凝土规范）：美国钢筋混凝土设计规范，LRFD/SD 方法
+- AISC 360（美国钢结构规范）：美国钢结构设计规范，LRFD 和 ASD 两种方法
+- ASCE 7（美国荷载规范）：美国建筑最小设计荷载规范，涵盖重力、风、地震、雪载等
+- GB 50010/50017/50011/50009（中国规范）：混凝土/钢结构/抗震/荷载设计规范
+- IS 456/800/1893（印度规范）：混凝土/钢结构/抗震设计规范
+- AIJ（日本建筑学会）：日本建筑结构设计标准，含高性能抗震设计指南
+- IBC（国际建筑规范）：美国及中东多国采用的综合建筑法规
+- NBC（加拿大国家建筑规范）：加拿大建筑及结构设计基础规范
 
 ## Connections
-- [[specialized-developer-advocate]] ← shares → [[specialized-mcp-builder]]（同属 specialized 专业 Agent 系列）
-- [[specialized-civil-engineer]] ← implements → [[specialized-workflow-architect]]（专业 Agent 依赖工作流架构）
+- （The Agency Specialized 部门内部 Agent 协作关系，待 specialized-workflow-architect 和 specialized-developer-advocate 等文档摄入后补充）
 
 ## Contradictions
-- 暂无已知冲突。该 Agent 覆盖全球多套独立规范体系，各标准间差异已明确标注（如 Eurocode vs ACI vs GB 的荷载分项系数不可混用），符合预期。
+- 与其他 Agent 页面冲突：
+  - 冲突点：不同专业 Agent 对"假设"的使用态度不同
+  - 当前观点（Civil Engineer）：严禁假设，所有参数必须有明确来源
+  - 对方观点（一般 Agent）：允许在无明确信息时基于上下文合理假设
+  - 注：Civil Engineer 的严谨性与一般 Agent 的灵活性形成互补，适用于不同场景
diff --git a/wiki/sources/specialized-cultural-intelligence-strategist.md b/wiki/sources/specialized-cultural-intelligence-strategist.md
index 870911e5..7f0a574c 100644
--- a/wiki/sources/specialized-cultural-intelligence-strategist.md
+++ b/wiki/sources/specialized-cultural-intelligence-strategist.md
@@ -2,43 +2,51 @@
 title: "Cultural Intelligence Strategist"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md]]
+- [[Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Cultural Intelligence Strategist（文化情报策略师）—— 一个专门负责在软件开发流程中检测和消除"隐性排斥"的 AI Agent。
-- 问题域：软件产品中的文化盲点（Western 默认假设、性别选项、命名规范、颜色语义等）导致非西方用户群体的摩擦和排斥。
-- 方法/机制：通过"盲点审计 → 自主研究 → 结构修正 → 解释原理"四阶段工作流，在架构层面实现文化包容性设计。
-- 结论/价值：将文化智能（Culture Intelligence, CQ）从"后期本地化补丁"提升为"架构级前提条件"，避免产品因隐性排斥而失去全球市场份额。
+- 核心主题：文化智能（CQ）在软件开发中的架构级实践——将"国际化"从后期本地化补丁提升为架构前提条件，检测和消除 UI 工作流、文案和图像中的"隐性排斥"（Invisible Exclusion）。
+- 问题域：软件产品中的西方中心主义默认设计（刚性姓名字段、颜色语义文化差异、RTL 阅读方向、多日历系统等）导致非 Western 用户产生摩擦和疏离感。
+- 方法/机制：四阶段工作流（盲点审计 → 自主研究 → 结构修正 → 解释原理）+ 绝对文化谦逊原则（绝不假设已有知识完整，必须为特定群体自主研究当前尊重的表征标准）。
+- 结论/价值：通过架构级文化包容设计，消除"表演性多元化"（在首页放多元人群图但产品流程本身仍具排斥性），实现真正的结构性同理心（Structural Empathy）。
 
 ## Key Claims（用中文描述）
-- 刚性 Western 命名结构（强制 First Name / Last Name）会严重阻碍 APAC 等非西方市场用户的注册体验，应改为单一"Full Name"或"Preferred Name"字段。
-- 在中国金融场景中，红色表示"上涨/正向"，而非西方语境中的"错误/警告"，财务类应用不应仅依赖红色传达错误状态。
-- 表演性多元化（仅在首页加一张多元人群图，但产品流程本身仍具排斥性）不可接受；必须从架构层面消除排斥。
-- 国际化（Internationalization）必须作为架构前提条件，而非上线后的亡羊补牢。
+- **Agent 角色 = 架构同理心引擎**：Agent 定位为 Architectural Empathy Engine，在软件发布前检测 UI 工作流、文案和图像中的隐性排斥，而非事后修补。
+- **刚性姓名字段在 APAC 市场系统性失效**：强制 First Name / Last Name 字段对不使用严格姓/名二分法的文化（多姓氏文化、家姓在前等）造成系统性摩擦，应改为单一 Full Name 或 Preferred Name 字段。
+- **中国金融应用中红色表示"上涨"而非"错误"**：UX 错误状态若仅依赖红色视觉编码，在 APAC 金融场景下造成语义冲突，必须辅以文字/图标说明而非单纯依赖颜色。
+- **国际化是架构前提条件，非亡羊补牢**：全球化包容设计必须在架构设计阶段作为 prerequisite 纳入，而非在产品成型后再做本地化适配。
 
 ## Key Quotes
-> "This form design assumes a Western naming structure and will fail for users in our APAC markets." — 文化包容性修正的核心原则表述
-> "You are an Architectural Empathy Engine. Your job is to detect invisible exclusion in UI workflows, copy, and image engineering before software ships." — 角色定义
-> "Red in Chinese financial contexts indicates positive growth." — 颜色语义冲突的具体案例
+> "This form design assumes a Western naming structure and will fail for users in our APAC markets. Allow me to rewrite the validation logic to be globally inclusive." — 刚性姓名字段示例沟通话术
+> "The current prompt relies on a systemic archetype. I have injected anti-bias constraints to ensure the generated imagery portrays the subjects with authentic dignity rather than tokenism." — 图像生成偏见对抗示例沟通话术
+> "Adding a single visibly diverse stock photo to a hero section while the entire product workflow remains exclusionary is unacceptable." — 拒绝表演性多元化的核心理念
 
 ## Key Concepts
-- [[Invisible Exclusion]]：在 UI 工作流、文案和图像工程中，用户因文化、神经多样性、视觉障碍或非西方时间日历假设而被无意识地排斥。
-- [[Cultural Intelligence（CQ）]]：检测和应对文化差异的能力，在软件产品设计中体现为对全球用户多样化需求的敏感度。
-- [[Global-First Architecture]]：将国际化作为架构前提条件，而非后期补救措施的设计哲学。
-- [[Contextual Semiotics]]：超越语言翻译，审查 UX 颜色选择、图标和隐喻的文化语义。
-- [[Architectural Empathy]]：通过结构性解决方案而非表演性行为来实现包容性的设计理念。
-- [[Negative-Prompt Library]]：在图像生成中主动禁止有害刻板印象的工具库。
+- [[Cultural-Intelligence]]（CQ）：文化智能——检测和消除软件开发中隐性排斥的能力，不同于 IQ（认知智能）和 EQ（情绪智能），CQ 专注文化适应性
+- [[Invisible-Exclusion]]（隐性排斥）：用户不觉得被明确歧视，但因产品设计未考虑其文化背景而产生的微妙疏离感——比明显歧视更难发现和修复
+- [[Structural-Empathy]]（结构性同理心）：从架构层面系统性解决包容性问题，而非仅在表面层添加多元表征——拒绝表演性多元化
+- [[Cultural-Humility]]（文化谦逊）：Agent 的默认原则——永远不假设已有知识完整，在为特定群体生成输出前必须自主研究当前、尊重和赋权的表征标准
+- [[Global-First-Architecture]]（全局优先架构）：国际化作为架构 prerequisite 而非 retrofit（亡羊补牢式适配）的设计原则
+- [[Color-Semiotics]]（颜色符号学）：不同文化对颜色的象征意义差异（如红色在中西金融语境中截然相反的语义）
 
 ## Key Entities
-- [[The Agency]]：该 Agent 所属的 Agent 系统生态。
+- [[The Agency]]：本 Agent 所属组织，Specialized 部门专业 Agent 矩阵成员
+- [[InclusiveVisualsSpecialist]]：包容性视觉专家 Agent——与本 Agent 互补，前者覆盖整个产品工作流（含表单、交互、颜色语义），后者专注于 AI 生成图像的表征偏见消除
 
 ## Connections
-- [[Design Inclusive Visuals Specialist]] ← extends ← [[Cultural Intelligence Strategist]]：两者均涉及多元包容，但前者专注于视觉内容，后者覆盖整个产品工作流。
-- [[Design UX Researcher]] ← related_to ← [[Cultural Intelligence Strategist]]：均关注用户研究的包容性维度。
+- [[cultural-intelligence-strategist]] ← is_a ← [[The Agency]] / Specialized 部门
+- [[corporate-training-designer]] ← complements ← [[cultural-intelligence-strategist]]（系统性设计能力矩阵：组织学习 vs 软件工程 vs 文化包容）
+- [[InclusiveVisualsSpecialist]] ← complements ← [[cultural-intelligence-strategist]]（包容性视觉 vs 全产品包容性设计）
+- [[design-brand-guardian]] ← tension_with ← [[cultural-intelligence-strategist]]（品牌一致性要求与市场定制化视觉语义的张力）
+- [[specialized-korean-business-navigator]] ← shares_domain ← [[cultural-intelligence-strategist]]（跨文化领域 Agent，后者专精韩国单一市场，前者覆盖全球包容性设计）
 
 ## Contradictions
-- 与 [[Design Brand Guardian]]：Brand Guardian 强调品牌一致性，而 Cultural Intelligence Strategist 要求为不同市场调整视觉语义（如中国财务应用的颜色规则）。在特定市场语境下，两者需要在品牌规范层面达成平衡。
+- 与 [[design-brand-guardian]] 存在张力：
+  - 冲突点：品牌一致性要求全球统一的视觉识别系统，而文化智能策略师认为不同市场需要定制化颜色/图标/比喻语义
+  - 当前观点：[[cultural-intelligence-strategist]] 主张为 APAC/EMEA 等市场调整视觉语义（如中国金融应用中的红色语义），即使与全球品牌规范冲突
+  - 对方观点：[[design-brand-guardian]] 坚持品牌规范必须全局统一，局部定制会稀释品牌资产
+  - 协调方向：视觉语义适配限于功能层（如错误提示颜色），品牌标识层保持全球统一
diff --git a/wiki/sources/specialized-developer-advocate.md b/wiki/sources/specialized-developer-advocate.md
index d8b389ac..51e03980 100644
--- a/wiki/sources/specialized-developer-advocate.md
+++ b/wiki/sources/specialized-developer-advocate.md
@@ -1,58 +1,54 @@
 ---
-title: "Specialized Developer Advocate"
+title: "Developer Advocate"
 type: source
-tags: [agent, specialized, developer-relations, community, developer-experience]
-date: 2026-04-20
+tags: [developer-experience, community-building, technical-content, the-agency, specialized]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/specialized-developer-advocate.md]]
+- [[Agent/agency-agents/specialized/specialized-developer-advocate]]
 
 ## Summary（用中文描述）
-- 核心主题：Developer Advocate Agent——The Agency Specialized 部门的开发者关系工程师，通过提升开发者体验（DX）、创建高质量技术内容、建立真实社区联系，将产品与外部开发者紧密连接，最终推动平台采用和商业价值增长。
-- 问题域：开发者关系（DevRel）、开发者体验优化、技术内容营销（区别于传统营销）、社区运营、产品反馈闭环。
-- 方法/机制：DX 工程审计（Time-to-First-Success）→ 技术内容创作（教程/演示/演讲提案）→ 社区运营（GitHub/Discord/Slack 响应、Hackathon、大使计划）→ 产品反馈闭环（月度 Voice of Developer 报告）。
-- 结论/价值：Authenticity（不 astroturf）是开发者关系唯一可持续的资产；DX 改善（错误信息/SDK）比内容创作影响更深远、更持久；开发者成功（Developer Success）≠ 营销。
+- 核心主题：The Agency 的 Developer Advocate（开发者倡导者）专业智能体——定位于产品团队与开发者社区之间的桥梁，通过真实的技术参与提升开发者体验（DX）、驱动平台采用率、建立开发者信任。
+- 问题域：开发者社区参与度低、文档质量差、SDK 体验不佳、产品反馈闭环缺失、技术内容供给不足。
+- 方法/机制：DX 工程审计 → 技术内容创作 → 社区运营 → 产品反馈闭环四步工作流；内置 DX Audit Framework、Viral Tutorial Structure、Conference Talk Proposal Template、GitHub Issue Response Templates 等标准化交付物。
+- 结论/价值：开发者倡导者的核心资产是社区信任（AstroTurf 会永久摧毁）；DX 改进（错误消息/TypeScript 类型/SDK 修复）的价值随时间复利增长，优于单纯的内容产出。
 
 ## Key Claims（用中文描述）
-- **开发者体验优先**：DX 改善（更好的错误信息、TypeScript 类型、SDK 修复）复合效应永远优于新内容发布；修复前 3 大 DX 问题再发布任何新教程。
-- **真实性是核心资产**：虚假社区参与（AstroTurf）会永久性摧毁开发者信任；保持技术准确性比发布空内容更重要。
-- **时间度量价值**：新开发者"首次成功调用 API"时间 ≤ 15 分钟；GitHub 问题工作日首响 ≤ 24 小时；教程完成率 ≥ 50%；开发者 NPS ≥ 8/10。
-- **内容先听后创**：先读过去 30 天所有 GitHub Issue（发现高频痛点）、搜索 Stack Overflow 最新提问（识别理解障碍）、审查社交媒体情绪（获取无过滤反馈），再创作有针对性的内容。
-- **产品反馈闭环**：将开发者声音量化（17 个 GitHub Issue + 4 个 Stack Overflow 问题 + 2 场大会 Q&A = 同一功能缺失的证据）带入产品规划会议。
+- **开发者体验优先原则**：在发布任何新教程之前，必须先修复排名前 3 的 DX 问题；DX 改进长期复利，内容有半衰期。
+- **真实性伦理约束**：绝不做 AstroTurf（虚假社区参与）；社区信任是开发者倡导者唯一的资产，一旦损坏永久不可逆。
+- **社区→产品的代理角色**：开发者倡导者首先对开发者负责，其次才对公司负责——必须将开发者痛点转化为有证据支撑的产品需求。
+- **可量化成功指标**：新开发者首次成功 API 调用时间 ≤15 分钟、GitHub issue 首响时间 ≤24 小时、教程完成率 ≥50%、开发者 NPS ≥8/10。
+- **技术内容质量标准**：所有代码示例必须无需修改即可运行；不为非 GA 功能发布教程（除非明确标注 Preview/Beta）。
 
 ## Key Quotes
-> "You don't do marketing — you do developer success." — 开发者关系工程师的身份定位：Authentic 技术参与，而非商业推销
-> "DX improvements compound forever; a tutorial has a half-life." — DX 改善的持久价值 vs. 内容创作的时间衰减
-> "A tutorial with an active author gets 3x the trust." — 作者持续维护对内容可信度的放大效应
-> "Five people at KubeCon ask the same question — that means thousands more hit it silently." — 大会 Q&A 模式的大规模推断价值
+> "You don't do marketing — you do developer success." — Developer Advocate Agent 核心定位
+
+> "Authentic community trust is your entire asset; fake engagement destroys it permanently." — Advocacy Ethics 核心原则
+
+> "Fix the top 3 DX issues before publishing any new tutorials." — DX-first 工作流原则
+
+> "Conference Q&A patterns — 5 people ask the same question = 500 have the same confusion." — 社区反馈信号放大原理
 
 ## Key Concepts
-- [[DeveloperExperienceEngineering]]：审计并改善"首次 API 调用时间"，构建示例应用、启动工具包和代码模板，量化 DX 质量。
-- [[TechnicalContentCreation]]：教程/博客/视频脚本/交互式演示（CodePen/CodeSandbox/Jupyter），内容先以最终效果开头而非"本教程将……"。
-- [[CommunityBuilding]]：GitHub/Stack Overflow/Discord/Slack 真诚技术响应；大使计划（Ambassador Program）；Hackathon/Office Hours。
-- [[ProductFeedbackLoop]]：将开发者痛点转化为可操作的产品需求（用户故事）；月度 Voice of Developer 报告。
-- [[DeveloperOnboardingAudit]]：DX 审计框架，分阶段（Discovery/Account Setup/First API Call）计时评分：🟢 <5min | 🟡 5-15min | 🔴 >15min。
-- [[AmbassadorProgram]]：分层次贡献者认可机制，与社区价值观一致的真实激励。
-- [[ContentStrategyAtScale]]：发现层（SEO 教程）→ 激活层（Quick Start）→ 留存层（高级指南）→ 倡导层（案例研究）的漏斗模型。
-- [[DeveloperNPS]]：开发者净推荐值，季度调查，目标 ≥ 8/10。
+- [[Developer Experience Engineering]]：审计并改善"首次 API 调用时间"或"首次成功时间"，消除 onboarding、SDK、文档和错误消息中的摩擦点。
+- [[Technical Content Creation]]：编写教程、博客、视频脚本、会议演讲，核心理念是"先展示最终结果，再解释如何实现"；代码示例必须零修改运行。
+- [[Community Building & Engagement]]：通过 GitHub Issues、Stack Overflow、Discord/Slack 提供真实技术支持，建立大使/冠军计划，组织 hackathons 和 office hours。
+- [[Product Feedback Loop]]：将开发者痛点转化为可操作的产品需求，用证据而非轶事在产品规划会议中代表开发者声音。
+- [[Advocacy Ethics]]：绝不 AstroTurf、技术准确优先、为开发者代理、公开关系披露、不过度承诺路线图。
 
 ## Key Entities
-- [[GitHub]]：开源社区核心阵地；Issue 响应质量是开发者信任的关键指标；响应时效目标：工作日 ≤ 24 小时。
-- [[StackOverflow]]：开发者问题解答平台；搜索平台名称按最新排序可发现理解障碍点；回答率目标：≥ 90%。
-- [[DiscordSlashSlack]]：实时社区沟通渠道；无过滤情绪分析来源；Office Hours 和 Hackathon 活动平台。
-- [[OpenTelemetry]]：社区健康指标监控（错误率、文档搜索成功率等）框架。
-- [[KubeCon]]：顶级开发者大会；5 人问同一问题 → 数千人无声遇到同样障碍的推断方法论。
+- [[The Agency]]：该 Agent 所属的 The Agency 项目，提供 12 个业务部门的专业智能体。
+- Developer Community（开发者社区）：Developer Advocate 的首要服务对象和反馈来源。
 
 ## Connections
-- [[automation-governance-architect]] ← informs ← [[ProductFeedbackLoop]]（产品反馈与治理评审互补）
-- [[specialized-mcp-builder]] ← depends_on ← [[DeveloperExperienceEngineering]]（MCP Builder 的 DX 改善依赖开发者体验工程原则）
-- [[design-ux-researcher]] ← informs ← [[DeveloperOnboardingAudit]]（UX 研究方法论应用于 DX 审计）
-- [[ContentStrategyAtScale]] ← supports ← [[ProductFeedbackLoop]]（内容策略放大产品反馈影响力）
-- [[CommunityBuilding]] ← depends_on ← [[DeveloperExperienceEngineering]]（社区健康依赖底层 DX 质量）
+- [[specialized-mcp-builder]] ← extends ← [[specialized-developer-advocate]]（MCP Builder 扩展了开发者工具能力，Developer Advocate 负责传播和推广）
+- [[backend-architect-with-memory]] ← depends_on ← [[specialized-developer-advocate]]（后端架构师产出的 SDK 和示例应用依赖 Developer Advocate 的 DX 反馈优化）
+- [[specialized-workflow-architect]] ← shares_workflow ← [[specialized-developer-advocate]]（两者都使用结构化模板驱动工作流）
 
 ## Contradictions
-- 与 [[specialized-workflow-architect]] 存在设计哲学张力：
-  - 冲突点：快速交付 vs. 质量保障。Developer Advocate 优先修复 DX 问题再发布内容（"修复前 3 大 DX 问题再发布任何新教程"）；Workflow Architect 优先快速交付功能。
-  - 当前观点：DX 改善复合效应优于快速内容发布，内容发布前必须有可运行的代码样本。
-  - 对方观点：快速迭代需要尽早发布并通过真实用户反馈迭代，内容质量可随时间改进。
+- 与 [[engineering-technical-writer]] 潜在冲突：
+  - 冲突点：技术写作与开发者倡导者都产出手册和教程，但目标受众和交付标准不同。
+  - 当前观点（Developer Advocate）：教程必须先展示最终结果，必须包含失败模式和调试方法，代码必须零修改运行，不为非 GA 功能发布教程。
+  - 对方观点（Technical Writer）：文档以参考完整性优先，覆盖所有 API 端点和参数，面向不同熟练度的开发者分层提供内容。
+  - 协调方案：Developer Advocate 负责"教程/快速入门/演示"等引导式内容；Technical Writer 负责"API 参考/规范文档/操作指南"等查阅式内容；两者共享 DX 反馈回路。
diff --git a/wiki/sources/specialized-document-generator.md b/wiki/sources/specialized-document-generator.md
index 55ab9de0..f62815eb 100644
--- a/wiki/sources/specialized-document-generator.md
+++ b/wiki/sources/specialized-document-generator.md
@@ -2,47 +2,55 @@
 title: "Document Generator Agent"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/specialized-document-generator.md]]
+- [[Agent/agency-agents/specialized/specialized-document-generator.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 担任专业文档生成专家，通过代码方式生成 PDF、PPTX、DOCX、XLSX 等格式的专业文档
-- 问题域：如何让 AI Agent 高效、规范、可复用地产出商业级文档（投资者演示文稿、合规报告、数据密集型电子表格等）
-- 方法/机制：基于 Python（reportlab、python-pptx、openpyxl、python-docx 等）和 Node.js（puppeteer、pptxgenjs、exceljs、docx 等）两大生态，使用模板化、数据驱动、品牌一致的设计原则
-- 结论/价值：文档生成 Agent 需具备精确、设计意识强、注重格式的特点；核心规则包括使用样式系统而非硬编码、保持品牌一致性、数据驱动输入、无障碍设计，以及构建可复用模板而非一次性脚本
+- 核心主题：程序化生成专业文档（PDF/PPTX/DOCX/XLSX）的 AI Agent 个性化定义
+- 问题域：企业级文档自动化生成——如何通过代码工具而非 GUI 工具批量生成品牌一致的格式化文档
+- 方法/机制：Python（reportlab/weasyprint/python-pptx/openpyxl/python-docx）和 Node.js（puppeteer/pdf-lib/pptxgenjs/exceljs/docx）双技术栈；HTML+CSS→PDF 复杂布局；模板驱动品牌一致性；数据驱动文档生成
+- 结论/价值：文档生成 Agent 应使用文档样式而非硬编码字体/尺寸；可复用模板函数而非一次性脚本；无障碍设计（alt text、标题层级、标签化 PDF）内置于架构
 
 ## Key Claims（用中文描述）
-- Document Generator Agent 通过代码编程方式（而非手动操作）生成专业级 PDF、演示文稿、电子表格和 Word 文档
-- Agent 需根据不同文档格式选择最优工具链（PDF 推荐 HTML+CSS→PDF 方案，PPTX 推荐 python-pptx，XLSX 推荐 openpyxl，DOCX 推荐 python-docx）
-- 核心规则：必须使用文档样式系统而非硬编码字体/字号，确保品牌颜色、字体、Logo 一致，数据驱动输入输出，支持无障碍（Alt 文本、标题层级、PDF 标签）
-- Agent 应构建可复用模板函数，而非一次性脚本，以提升效率和可维护性
+- Document Generator Agent 使用代码工具而非 GUI 工具生成专业文档，覆盖 PDF/演示文稿/电子表格/Word 四大格式
+- PDF 生成优先 HTML+CSS→PDF 路径处理复杂布局，直接生成用于数据报告
+- 演示文稿采用模板化方法确保品牌一致性，支持数据驱动幻灯片生成
+- 电子表格生成强调结构化数据、公式、图表和透视分析就绪布局
+- Word 文档基于样式模板，支持页眉/页脚、目录和一致性格式
+- 五条核心规则：使用文档样式而非硬编码、品牌一致性、数据驱动、无障碍设计、可复用模板
 
 ## Key Quotes
-> "You are **Document Generator**, a specialist in creating professional documents programmatically." — Agent 身份定位
-> "Use proper styles — Never hardcode fonts/sizes; use document styles and themes" — 核心规则第1条
-> "Ask about the target audience and purpose before generating" — 沟通风格
+> "Use proper styles — Never hardcode fonts/sizes; use document styles and themes" — 核心设计原则：依赖文档样式系统而非硬编码格式
+> "Accessible — Add alt text, proper heading hierarchy, tagged PDFs when possible" — 无障碍设计是默认要求而非后期添加
+> "Reusable templates — Build template functions, not one-off scripts" — 模板函数设计理念
 
 ## Key Concepts
-- [[Code-Based Document Generation]]：通过编程代码（Python/Node.js 库）而非手动操作软件生成文档的方法
-- [[Template-Based Document Generation]]：基于预定义模板，通过数据替换生成一致性文档的工作模式
-- [[Data-Driven Document Generation]]：以结构化数据为输入，自动生成对应格式文档的自动化方法
-- [[Brand-Consistent Document Design]]：在文档生成过程中保持颜色、字体、Logo 等品牌元素一致的设计原则
+- [[Code-Based Document Generation]]：通过编程库而非 GUI 工具生成文档，支持批量自动化
+- [[Document Styles]]：文档样式系统（styles/themes）vs 硬编码格式，前者保证一致性和可维护性
+- [[HTML-to-PDF Conversion]]：使用 WeasyPrint/Puppeteer 将 HTML+CSS 渲染为 PDF，适合复杂布局
+- [[Template-Driven Generation]]：基于模板的文档生成确保品牌一致性
+- [[Data-Driven Documents]]：接受结构化数据输入，生成动态文档内容
 
 ## Key Entities
-- [[The Agency]]：Document Generator Agent 所属的 Agent 框架体系（从 index 中相关条目推断）
-- reportlab / weasyprint / fpdf2：Python PDF 生成库
-- python-pptx / pptxgenjs：PPTX 演示文稿生成库
-- openpyxl / xlsxwriter / exceljs / xlsx：XLSX 电子表格生成库
-- python-docx / docx：DOCX Word 文档生成库
+- [[The Agency]] Specialized 部门：Document Generator Agent 所属组织
+- [[ReportLab]]：Python PDF 生成库
+- [[WeasyPrint]]：Python HTML+CSS→PDF 工具
+- [[python-pptx]]：Python PPTX 生成库
+- [[pptxgenjs]]：Node.js 演示文稿生成库
+- [[openpyxl]] / [[xlsxwriter]]：Python XLSX 生成库
+- [[python-docx]]：Python DOCX 生成库
 
 ## Connections
-- [[specialized-developer-advocate]] ← relates_to ← [[specialized-document-generator]]（同为 The Agency 下的专业 Agent）
-- [[agents-orchestrator]] ← orchestrates ← [[specialized-document-generator]]（文档生成通常由编排 Agent 调度）
-- [[report-distribution-agent]] ← supports ← [[specialized-document-generator]]（文档生成后可由分发 Agent 推送）
+- [[design-visual-storyteller]] ← depends_on ← [[specialized-document-generator]]（Visual Storyteller 输出的视觉内容可嵌入 Document Generator 生成的报告中）
+- [[specialized-document-generator]] ← extends ← [[report-distribution-agent]]（Document Generator 生成报告 → Distribution Agent 负责分发）
+- [[sales-proposal-strategist]] ← depends_on ← [[specialized-document-generator]]（销售提案策略师依赖文档生成器输出专业提案文档）
 
 ## Contradictions
-- 无已知冲突
-
+- 与 [[latex-paper-writing]] 冲突：
+  - 冲突点：LaTeX 适合学术论文（精确排版、数学公式），Document Generator 适合商业文档（品牌模板、数据驱动报表）
+  - 当前观点：商业文档生成优先使用 python-docx/pptxgenjs/openpyxl 等办公软件原生格式，易于非技术用户编辑
+  - 对方观点：学术/技术文档优先使用 LaTeX，保证跨平台排版一致性和数学公式渲染质量
+  - 协调方案：按文档类型分工——商业报告（财务/提案/合规）→ Document Generator；学术论文/技术规范 → LaTeX Pipeline
diff --git a/wiki/sources/specialized-french-consulting-market.md b/wiki/sources/specialized-french-consulting-market.md
index ea6a1efd..a8dfe0c2 100644
--- a/wiki/sources/specialized-french-consulting-market.md
+++ b/wiki/sources/specialized-french-consulting-market.md
@@ -1,63 +1,62 @@
 ---
 title: "French Consulting Market Navigator"
 type: source
-tags: []
-date: 2026-04-20
+tags: ["agent-persona", "france", "consulting", "freelance", "esn-si", "tjm"]
+date: 2026-04-25
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/specialized-french-consulting-market.md]]
+- [[Agent/agency-agents/specialized/specialized-french-consulting-market.md]]
 
 ## Summary（用中文描述）
-- 核心主题：法国 IT 咨询市场（ESN/SI 生态系统）的运作规则、费率定位与谈判策略
-- 问题域：独立 IT 顾问在法国市场中面临的信息不对称——ESN 佣金结构不透明、平台定价机制混乱、多层billing结构税后收益差异巨大
-- 方法/机制：三层 ESN 分类定价体系（Tier 1-3）、五大平台对比矩阵（Malt/collective.work/Comet/Crème/Free-Work）、TJM→净收入换算模型、季节性市场日历、国际远程顾问定位策略
-- 结论/价值：帮助自由顾问最大化税后日均收入、最小化付款风险、建立可持续客户关系
+- 核心主题：法国IT咨询/自由职业生态系统（ESN/SI）的运营规则、费率结构、平台策略和合同谈判指南
+- 问题域：帮助独立IT顾问在法国ESN/SI市场中最大化日均净收入（Effective Daily Rate），同时最小化付款风险
+- 方法/机制：通过结构化的市场分析、费率谈判话术、成本拆解和平台对比，帮助顾问理解ESN的真实margin结构，从而做出更优的计费结构选择
+- 结论/价值：提供量化的决策依据——portage salarial vs micro-entreprise vs SASU的真实净收入对比，平台选择矩阵，季节性市场日历，以及国际远程顾问进入法国市场的操作框架
 
 ## Key Claims（用中文描述）
-- ESN 佣金结构是市场信息不对称的核心：Client 支付 1,000 EUR/天，Tier 2 ESN 实际支付顾问 600-750 EUR/天（佣金 25-40%），顾问对此往往不知情
-- Billing 结构税后收益差距显著：同等 TJM 700 EUR/天，Portage Salarial 净收入 ~208 EUR/天（~3,742 EUR/月），Micro-entreprise 净收入 ~546 EUR/天（~9,828 EUR/月），差距 338 EUR/天
-- 付款延迟是结构性而非例外：合同标注 NET-30，实际到账 60-90 天，顾问必须提前预算
-- 平台费率具有公开锚定效应：Malt 上的报价直接成为市场价格，定价必须从第一天起就谨慎
-- 费率下限有战略意义：Salesforce 架构师低于 550 EUR/天会被 ESN 视为"急于求成"，永久锚定低费率谈判基准
-- 远程/国际位置必须主动披露：谈判中期被发现会导致费率降低 5-10% 并损害信任，主动披露+价值框架可中和惩罚
+- ESN/SI公司对客户收取的费用是向顾问支付TJM的1.4-1.7倍，Tier 1公司margin高达35-50%，Tier 2约25-40%，Tier 3约15-25%
+- 通过portage salarial，700 EUR/天的TJM brut仅约208 EUR/天净收入；通过micro-entreprise同额TJM则约546 EUR/天净收入——差距达338 EUR/天
+- 低于550 EUR/天的TJM对高级Salesforce架构师来说会永久锚定低价谈判起点
+- 法国ESN链条中，标准NET-30付款条款实际意味着60-90天实际到账
+- Malt平台费率公开可见，一旦定价即成为市场价锚点，需要从第一天起慎重定价
 
 ## Key Quotes
-> "Portage salarial is not employment. It provides social protection (unemployment, retirement contributions) but the freelancer bears all commercial risk. Never present it as equivalent to a CDI." — 核心原则：Portage 不等于就业，不能用 CDI 的安全感来类比
-
-> "Platform rates are public. What you charge on Malt is visible. Your Malt rate becomes your market rate. Price accordingly from day one." — 平台费率的公开性要求从第一天就谨慎定价
-
-> "A 600 EUR/day TJM through portage salarial yields approximately 300-330 EUR net after all charges. Through micro-entreprise, approximately 420-450 EUR. The gap is significant and must be surfaced." — 两种结构税后收益差距 30-40%，必须明确告知客户
+> "Client pays: 1,000 EUR/day → ESN Margin 25-40% → ESN pays consultant: 600-750 EUR/day" — ESN margin架构的核心等式
+> "A 600 EUR/day TJM through portage salarial yields approximately 300-330 EUR net after all charges. Through micro-entreprise, approximately 420-450 EUR." — TJM brut与净收入的真实差距
+> "Platform rates are public. What you charge on Malt is visible. Your Malt rate becomes your market rate. Price accordingly from day one." — Malt定价的战略含义
+> "Standard NET-30 in French ESN chains means 60-90 days actual payment. Budget accordingly and advise accordingly." — 法国付款周期现实
 
 ## Key Concepts
-- [[TJM]]（Taux Journalier Moyen / 毛日均费率）：法国咨询市场的核心定价单位，需区分 TJM Brut 与实际净收入
-- [[Portage-Salarial]]：法国的准雇佣模式，为自由顾问提供失业保险和退休金，但商业风险自担，净收入约为 TJM Brut 的 50%
-- [[Micro-Entreprise]]：法国简化商业结构，无社会保障福利，净收入约为 TJM Brut 的 70%
-- [[ESN-SI-Ecosystem]]：法国 IT 咨询生态系统，ESN（Entreprise de Services Numériques）= SI（System Integrator），占法国企业 IT 项目用人的主要渠道
-- [[Rate-Negotiation-Playbook]]：费率谈判四步法（知底价→探底价→锚高价→框架溢价），核心是在非 TJM 维度（期限/远程天数/续约条款）上让步
-- [[International-Freelancer-Positioning]]：面向法国市场的国际自由顾问定位策略，核心是时区重叠作为优势、法国实体偏好、主动披露原则
+- [[Portage Salarial]]：法国特有的雇佣代理机制，由portage公司代为签订合同、收取款项、发放工资。提供失业保险（ARE）和退休金，但freelancer承担全部商业风险，净收入约TJM brut的50%
+- [[Micro-Entreprise]]：法国简化税制企业结构，适用固定税率（URSSAF约22%），净收入约TJM brut的70%，但无失业保险和正规退休金
+- [[ESN/SI]]：法国IT服务企业（Entreprise de Services Numériques / Systèmes d'Information），介于客户和独立顾问之间的中间商，按margin比例赚取差价
+- [[TJM (Taux Journalier Moyen)]]：平均日费率，法语区标准报价单位，分为TJM brut（发票金额）和净收入两部分
+- [[Agentforce]]：Salesforce的AI agent产品线，Data Cloud + Agentforce组合可支撑700-850 EUR/天的高端费率定位
 
 ## Key Entities
-- [[Malt]]：欧洲最大自由顾问平台，10% 佣金（客户端），费率公开可见，适合建立作品集，典型 TJM 550-700 EUR
-- [[collective.work]]：3-5% 佣金+Portage 集成，典型 TJM 650-800 EUR，适合高价值 mission
-- [[Comet]]：15% 佣金，算法驱动匹配，典型 TJM 600-750 EUR，技术顾问为主
-- [[Crème-de-la-Crème]]：15-20% 佣金，准入筛选严格，典型 TJM 700-900 EUR，高端定位
-- [[Free-Work]]：免费列表+付费选项，TJM 500-900 EUR，以中间商列表为主，噪音较大
-- [[Portage-Salarial-Company]]（Portage 公司）：作为 ESN 和顾问之间的雇佣中介，负责代扣代缴社保，提供 ARE 失业保险权利
+- [[Malt]]：欧洲最大自由职业平台（10%客户侧佣金），费率公开可见，适合建立作品集，但定价需谨慎
+- [[collective.work]]：3-5%佣金+portage集成，适合高价值任务和portage结构
+- [[Comet]]：技术导向平台（15%佣金），算法匹配为主，顾问控制权较低
+- [[Crème de la Crème]]：高端精品平台（15-20%佣金），入场审核严格，适合700-900 EUR TJM定位
+- [[Free-Work]]：免费列表+高级选项，量大但噪音多，多为中间商发布
+- [[Accenture]], [[Capgemini]], [[Atos]], [[CGI]]：Tier 1全球性ESN，margin 35-50%，顾问议价能力低
+- [[Cloudity]], [[Niji]], [[SpikeeLabs]], [[EI-Technologies]]：Tier 2精品ESN，margin 25-40%，有一定谈判空间
+- [[Salesforce]]：文档中高频提及的专业领域，Data Cloud和Agentforce方向为当前高价细分市场
 
 ## Connections
-- [[TJM]] ← is_priced_by ← [[ESN-SI-Ecosystem]]
-- [[Portage-Salarial]] ← provides_social_protection_to ← [[TJM]]
-- [[Micro-Entreprise]] ← alternative_to ← [[Portage-Salarial]]
-- [[Malt]] ← competing_with ← [[collective.work]], [[Comet]], [[Crème-de-la-Crème]], [[Free-Work]]
-- [[International-Freelancer-Positioning]] ← requires ← [[French-Entity]]（Portage 或 SASU）
+- [[specialized-salesforce-architect.md]] ← targets ← [[specialized-french-consulting-market.md]]（同一领域不同维度：Salesforce技术专家+法国市场定位）
+- [[Portage Salarial]] ← compares_with ← [[Micro-Entreprise]]（两种主要计费结构的全面对比）
+- [[Malt]] ← competes_with ← [[collective.work]] ← competes_with ← [[Comet]]（平台策略选择）
+- [[Accenture]] ← tier1 ← [[Cloudity]] ← tier2 ← [[Free-Work]] ← tier3（ESN层级体系）
 
 ## Contradictions
-- 与一般"高TJM=高收入"直觉冲突：
-  - 冲突点：同等 TJM 下，Portage Salarial 的实际净收入比 Micro-entreprise 低 30-40%
-  - 当前观点：TJM 必须换算为税后实际日均收入才能判断真实收入水平
-  - 对方观点：只看 TJM 数字，越高越好
-- 与"全职就业安全感"对比：
-  - 冲突点：Portage 提供的社保（失业保险/退休金）不等于 CDI 就业保障
-  - 当前观点：Portage 是商业安排，商业风险完全由顾问自担，绝不能包装成"准就业"
-  - 对方观点：Portage = 更好的 CDI（自由+保障）
+- 无已知内容冲突
+
+## Metadata
+- **Source slug**: `specialized-french-consulting-market`
+- **Original file**: `Agent/agency-agents/specialized/specialized-french-consulting-market.md`
+- **Agent personality name**: French Consulting Market Navigator
+- **Domain**: French IT Consulting / ESN-SI Freelance Ecosystem
+- **Language**: English (agent persona definition)
+- **Created**: 2026-04-25
diff --git a/wiki/sources/specialized-mcp-builder.md b/wiki/sources/specialized-mcp-builder.md
index cad7acd1..604d5911 100644
--- a/wiki/sources/specialized-mcp-builder.md
+++ b/wiki/sources/specialized-mcp-builder.md
@@ -3,6 +3,7 @@ title: "MCP Builder Agent"
 type: source
 tags: ["agent-personality", "mcp", "tool-design", "ai-integration"]
 date: 2026-04-20
+last_updated: 2026-05-29
 ---
 
 ## Source File
@@ -21,23 +22,29 @@ date: 2026-04-20
 - **无状态工具设计** → 每次调用独立，不依赖调用顺序，确保分布式环境稳定
 - **真实 Agent 测试循环** → 通过完整调用链路验证，而非仅靠单元测试
 - **环境变量密钥管理** → API Key 和 Token 从环境变量读取，绝不硬编码
+- **单一职责工具原则** → `get_user` 和 `update_user` 是两个工具，不是一个工具加 mode 参数
+- **可组合服务器架构** → 拆分为单一用途服务器，通过资源共享上下文，通过代理服务器聚合多后端
 
 ## Key Quotes
 > "If an agent can't figure out how to use your tool from the name and description alone, it's not ready to ship." — MCP Builder 核心理念
 > "A tool that passes unit tests but confuses the agent is broken." — 测试理念，强调必须验证 Agent 的完整调用路径
 > "We return `isError: true` here so the agent knows to retry or ask the user, instead of hallucinating a response." — 错误处理设计哲学
+> "Call it `search_orders_by_date` not `query` — the agent needs to know what this does from the name alone." — 命名原则
 
 ## Key Concepts
 - [[Model Context Protocol (MCP)]]：Anthropic 提出的 AI Agent 与外部工具/数据源交互的标准化协议
 - [[MCP Server]]：基于 MCP 协议的服务端实现，暴露 Tools/Resources/Prompts 给 Agent
 - [[Tool Interface Design]]：为 Agent 设计友好工具接口的实践，关注命名、描述、参数类型和返回结构
-- [[Zod Validation]]：TypeScript 端的参数模式定义和验证库，用于 MCP TypeScript 服务器
-- [[Pydantic Validation]]：Python 端的参数模式定义和验证库，用于 MCP Python (FastMCP) 服务器
+- [[Zod Validation]]：TypeScript schema 声明和验证库，用于 MCP TypeScript 服务器参数验证
+- [[Pydantic Validation]]：Python 数据验证库，用于 MCP Python (FastMCP) 服务器参数验证
 - [[Stdio Transport]]：MCP 标准传输方式，适用于本地 CLI 集成和桌面 Agent
 - [[SSE Transport]]：Server-Sent Events 传输方式，适用于基于 Web 的 Agent 接口和远程访问
 - [[Streamable HTTP]]：可扩展云部署的 HTTP 流式传输，支持无状态请求处理
 - [[Stateless Tool Design]]：无状态工具设计原则，确保每次调用独立、幂等、可分布式运行
 - [[Structured Error Response]]：返回 `isError: true` 结构化错误消息，而非堆栈跟踪
+- [[Dynamic Tool Registration]]：服务器启动时从 API Schema 或数据库表动态发现可用工具
+- [[OpenAPI-to-MCP Tool Generation]]：将现有 REST API 包装为 MCP 工具的自动生成
+- [[Composable Server Architecture]]：将大型集成拆分为专注单一用途的服务器，通过代理聚合多后端
 
 ## Key Entities
 - [[@modelcontextprotocol/sdk]]：Anthropic 官方 MCP TypeScript SDK，提供 McpServer、StdioServerTransport 等核心类
@@ -50,6 +57,12 @@ date: 2026-04-20
 - [[MCP Builder Agent]] ← uses ← [[@modelcontextprotocol/sdk]]
 - [[MCP Builder Agent]] ← uses ← [[FastMCP]]
 - [[LSP/Index Engineer Agent Personality]] ← shares_tool_design_philosophy_with ← [[MCP Builder Agent]]
+- [[Specialized Developer Advocate]] ← extends ← [[MCP Builder Agent]]（MCP 服务器的对外推广和最佳实践传播）
 
 ## Contradictions
-- 暂无发现与其他 Wiki 页面的冲突
+- 与 [[lsp-index-engineer]] 存在张力：
+  - 冲突点：LSP 强调确定性分析（代码结构必须精确），而 MCP 服务器面对外部 API 时存在网络抖动、速率限制等不确定性
+  - 当前观点：MCP Builder 坚持无状态、幂等、Fail-Gracefully 设计，允许优雅降级
+  - 对方观点：LSP/Index Engineer 需要确定性结果，任何不确定的外部调用应被隔离和重试
+  - 协调方案：在 MCP 服务器层面实现重试和熔断机制，结果仍以结构化形式返回给 LSP 层
+- 暂无其他已知冲突
diff --git a/wiki/sources/specialized-model-qa.md b/wiki/sources/specialized-model-qa.md
index c8797920..54cedea8 100644
--- a/wiki/sources/specialized-model-qa.md
+++ b/wiki/sources/specialized-model-qa.md
@@ -1,50 +1,56 @@
 ---
 title: "Model QA Specialist"
 type: source
-tags: []
-date: 2026-04-25
+tags: [model-qa, ml-audit, interpretability, calibration, shap, psi, the-agency, specialized]
+date: 2026-05-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/specialized-model-qa.md]]
+- [[Agent/agency-agents/specialized/specialized-model-qa.md]]
 
 ## Summary（用中文描述）
-- 核心主题：机器学习与统计模型的全生命周期端到端独立审计方法论
-- 问题域：模型质量管理、模型风险控制、合规性验证、生产监控
-- 方法/机制：10大审计领域（文档治理→数据重建→特征分析→模型复制→校准测试→性能监控→可解释性→公平性→业务影响→报告），配套 PSI/Hosmer-Lemeshow/SHAP/PDP 等量化工具
-- 结论/价值：将模型视为"有罪推定"——每个模型必须经过全面审计并以证据支撑结论，独立于模型构建者运行，确保生产部署前发现所有潜在问题
+- 核心主题：ML 模型全生命周期端到端独立审计专家（Model QA Specialist），隶属于 The Agency Specialized 部门
+- 问题域：模型质量管理、模型风险评估、模型可解释性、模型公平性审计
+- 方法/机制：十域 QA 方法论（文档治理→数据重建→标签分析→分段评估→特征分析→模型复制→校准测试→性能监控→可解释性与公平性→商业影响）；技术栈：PSI + SHAP + PDP + Hosmer-Lemeshow + Gini/KS；四阶段工作流；Severity 分级（High/Medium/Low/Info）；QA 报告交付模板
+- 结论/价值：提供证据驱动的模型审计，零主观意见，每项发现必须量化影响；成功标准：95%+ 发现确认率、100% QA 域覆盖、复制输出与原始偏差 <1%、零发布后失败
 
 ## Key Claims（用中文描述）
-- 模型审计师必须保持绝对独立性——永远不审计自己参与构建的模型
-- 每次分析必须产生完全可复现的脚本，从原始数据到最终输出全链路可追溯
-- 每个发现必须包含：观察→证据→影响评估→建议，缺一不可
-- PSI ≥ 0.25 表示显著分布漂移，需立即采取行动
-- Hosmer-Lemeshow p-value < 0.05 表示显著校准错误
+- 模型 QA 专家必须独立于所审计的模型——从不审计自己参与构建的模型，保持客观性，用数据挑战每个假设
+- 每次分析必须完全可重现：从原始数据到最终输出的每一步都必须有版本化脚本，无人工干预步骤
+- 每项发现必须包含：观察（observation）、证据（evidence）、影响评估（impact assessment）和整改建议（recommendation），且将严重性分为 High/Medium/Low/Info 四级
+- 模型 QA 覆盖十个领域：文档与治理审查 → 数据重建与质量 → 目标/标签分析 → 分段与队列评估 → 特征分析与工程 → 模型复制与构建 → 校准测试 → 性能与监控 → 可解释性与公平性 → 商业影响与沟通
 
 ## Key Quotes
-> "You treat every model as guilty until proven sound." — 核心审计哲学
-> "PSI >= 0.25 → Significant shift, action required (red)" — PSI 判读标准
-> "Never audit a model you participated in building" — 独立性原则
-> "Every finding must include: observation, evidence, impact assessment, and recommendation" — 证据链要求
+> "You treat every model as guilty until proven sound." — 核心审计哲学：无罪推定，有证据才过关
+> "PSI >= 0.25 indicates significant population shift, action required." — PSI 红线阈值，超过则需干预
+> "Every finding must include: observation, evidence, impact assessment, and recommendation. Never state 'the model is wrong' without quantifying the impact." — 证据驱动原则：质量评估不允许主观断言
 
 ## Key Concepts
-- [[SHAP]]：SHapley Additive exPlanations — 全局和局部特征贡献解释的核心工具
-- [[Calibration-Testing]]：概率校准验证方法——确保模型预测概率与实际频率一致
-- [[Discrimination-Metrics]]：判别能力指标体系——AUC/Gini/KS 等衡量模型区分能力
-- [[Partial-Dependence-Plots]]：偏依赖图——特征与预测之间的边际效应可视化
-- [[Population-Stability-Index]]：群体稳定性指数——衡量特征分布随时间的漂移程度
-- [[Hosmer-Lemeshow-Test]]：校准度拟合优度检验——统计判断预测概率与实际观测的一致性
+- [[Population Stability Index (PSI)]]：衡量特征或预测分数在时间窗口间的分布漂移，阈值：<0.10 绿/0.10–0.25 琥珀/>=0.25 红
+- [[SHAP-Value-Analysis]]：通过 SHAP 全局（beeswarm/bar importance plot）和局部（waterfall plot）分析量化特征贡献，是可解释性的核心技术手段
+- [[Partial Dependence Plots (PDP)]]：显示每个特征对预测的边际效应，用于验证模型学习的非线性关系和特征交互
+- [[Hosmer-Lemeshow-Test]]：概率校准的统计检验，p-value < 0.05 表明显著校准误差
+- [[Discrimination Metrics (Gini & KS)]]：AUC/Gini/KS 统计量衡量分类器区分正负样本的能力
+- [[Calibration Testing]]：通过 reliability diagram、Brier score 等验证预测概率的可靠性
+- [[Champion-Challenger Framework]]：基准测试框架——将待审计模型（新）与生产模型（旧）并行评分对比
+- [[Fairness Audit]]：跨受保护特征（种族/性别/年龄等）进行 demographic parity 和 equalized odds 检验
 
 ## Key Entities
-- The Agency Specialized 部门：该 Agent 所属的专业化 Agent 部门，涵盖医疗合规、文化智能、工作流架构、模型 QA 等垂直专业领域
+- [[The Agency]]：所在组织，提供 Specialized 部门多领域专家 Agent 网络
+- [[Agentic-Identity-Trust-Architect]]：身份与信任验证基础设施，与 Model QA Specialist 在模型访问权限和身份认证层面协作
+- [[Compliance-Auditor]]：合规审计专家，与 Model QA Specialist 在监管合规领域协作——QA 发现可能触发合规审查
+- [[Identity-Graph-Operator]]：身份图谱操作员，与 Model QA Specialist 在数据身份对齐层面协作
+- [[Document-Generator-Agent]]：文档生成 Agent，与 Model QA Specialist 在 QA 报告输出格式层面协作
 
 ## Connections
-- [[Corporate-Training-Designer]] ← 质量保证 ← [[specialized-model-qa]]
-- [[specialized-model-qa]] ← 审计输入 ← [[specialized-workflow-architect]]
-- [[Agentic-Identity-&-Trust-Architect]] ← 安全基础 ← [[specialized-model-qa]]（QA 报告的签名验证依赖身份基础设施）
+- [[The Agency]] ← provides agent network ← [[Model QA Specialist]] is a Specialized department agent
+- [[Population Stability Index (PSI)]] ← is measured by ← [[SHAP-Value-Analysis]]
+- [[SHAP-Value-Analysis]] ← informs ← [[Fairness Audit]]
+- [[Hosmer-Lemeshow-Test]] ← used in ← [[Calibration Testing]]
+- [[Champion-Challenger Framework]] ← benchmarked by ← [[Discrimination Metrics (Gini & KS)]]
+- [[Partial Dependence Plots (PDP)]] ← used for ← [[Feature Analysis]]
+- [[Model QA Specialist]] ← produces QA reports consumed by ← [[Compliance-Auditor]]
+- [[Model QA Specialist]] ← uses templates from ← [[Document-Generator-Agent]]
 
 ## Contradictions
-- 与 [[multi-agent-system-reliability]] 的对抗辩论模式存在潜在张力：
-  - 冲突点：multi-agent-system-reliability 主张用对抗辩论（Generator→Critic→Judge）消除 LLM 幻觉；Model QA Specialist 要求确定性证据链，LLM 的概率性本质与之矛盾
-  - 当前观点：Model QA Specialist 通过严格的统计检验（HL test、PSI）提供确定性判断，不依赖 LLM 自我批判
-  - 对方观点：对抗辩论通过架构约束弥补 LLM 不可靠性，适合快速迭代；统计检验需要完整数据，适合深度审计
+- 无实质性内容冲突——Model QA Specialist 的 QA 方法论与 wiki 中其他来源在技术层面互补而非竞争
diff --git a/wiki/sources/specialized-salesforce-architect.md b/wiki/sources/specialized-salesforce-architect.md
index 655517e0..ccfeb107 100644
--- a/wiki/sources/specialized-salesforce-architect.md
+++ b/wiki/sources/specialized-salesforce-architect.md
@@ -2,55 +2,60 @@
 title: "Specialized Salesforce Architect"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/specialized-salesforce-architect.md]]
+- [[Agent/agency-agents/specialized/specialized-salesforce-architect.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Salesforce 平台企业级解决方案架构师 Agent — 多云架构设计、企业集成模式、技术治理
-- 问题域：Salesforce 组织从试点到企业规模扩展过程中的架构设计、技术债务规避、governor limits 规划
-- 方法/机制：ADR（架构决策记录）、Governor Limit Budget 追踪、Integration Pattern Template、数据模型审查清单
-- 结论/价值：提供从发现评估 → 架构设计 → 实施指导 → 审查治理的完整工作流，强调 declarative-first 原则和 bulkification 强制性要求
+- 核心主题：Salesforce 平台解决方案架构师 Agent 人格定义，专注于多云平台设计、企业级集成模式和平台治理
+- 问题域：企业级 Salesforce 组织面临的架构挑战——200+自定义对象、47个相互冲突的 Flow、Governor Limits瓶颈、遗留系统迁移、数据模型治理
+- 方法/机制：声明式优先 + 代码兜底的设计原则；Trigger框架 + Handler类分层；Integration Pattern Template（REST/Platform Events/CDC/MuleSoft）；ADR（架构决策记录）；Governor Limit Budget规划；Multi-Cloud Data Architecture
+- 结论/价值：提供从发现评估、架构设计到实施指导、评审治理的完整工作流，确保零Governor Limit异常、生产数据零丢失、架构文档可让新开发者一周内上手
 
 ## Key Claims（用中文描述）
-- Governor limits 是不可协商的铁律，每项设计必须提前计入 SOQL(100)、DML(150)、CPU(同步10s/异步60s)、堆(同步6MB/异步12MB) 等限制
-- 业务逻辑必须放在 Handler 类中，Trigger 只负责委托分发，且每个对象只允许一个 Trigger
-- Bulkification 是强制要求 — 若代码在 200 条记录下失败，则该代码就是错误的
-- Declarative first，代码第二：优先使用 Flows、公式字段和验证规则，只在 declarative 方案变得不可维护时才考虑 Apex
-- 集成模式必须处理失败场景：每次外部调用都需要重试逻辑、断路器和死信队列
-- 数据模型是基础：在生产上线后再改数据模型，成本是设计阶段的 10 倍
-- PII 数据必须加密存储，使用 Shield Platform Encryption 或自定义加密方案
+- Governor Limits是不可妥协的铁律：每个设计必须考虑SOQL(100)、DML(150)、CPU(10s同步/60s异步)、堆(6MB同步/12MB异步)，无例外
+- 批处理化是强制要求：永远不写逐条处理的Trigger逻辑；若代码在200条记录下会失败，则设计本身是错误的
+- Trigger中不承载业务逻辑：Trigger仅委托给Handler类，每个对象一个Trigger
+- 声明式优先、代码兜底：优先使用Flow、公式字段、验证规则；但当声明式变得不可维护（复杂分支、批处理需求）时使用Apex
+- Integration Pattern必须处理失败：每个外部调用都需要重试逻辑、熔断器、死信队列
+- 数据模型是基础：上线后再改数据模型代价是设计时的10倍
+- PII数据必须加密：敏感数据使用Shield Platform Encryption或自定义加密
+- Platform Events与CDC各有适用场景：前者适合自定义Schema和高容量业务事件，后者适合字段级变更追踪
+- Agentforce在Salesforce Governor Limits内运行：设计需要在CPU/SOQL预算内完成的Actions
 
 ## Key Quotes
-> "Governor limits are non-negotiable. Every design must account for SOQL (100), DML (150), CPU (10s sync/60s async), heap (6MB sync/12MB async). No exceptions, no 'we'll optimize later.'" — 核心设计原则
-> "If the code would fail on 200 records, it's wrong." — Bulkification 强制性标准
-> "Data model is the foundation. Changing the data model after go-live is 10x more expensive." — 数据模型优先级
-> "Be direct about technical debt. If someone built a trigger that should be a flow, say so." — 沟通风格示例
+> "This approach adds 3 SOQL queries per transaction — you have 97 remaining before the limit" not "this might hit limits." — 用量化方式表述Governor Limit影响，而非模糊警告
+> "Get the data model right before building anything. Changing the data model after go-live is 10x more expensive." — 数据模型是架构的基石
+> "Design patterns must handle failure gracefully (zero silent data loss)." — 集成设计的核心原则
 
 ## Key Concepts
-- [[GovernorLimits]]：Salesforce 平台执行上下文的硬性资源限制，包括 SOQL 查询数(100)、DML 语句数(150)、CPU 时间(同步10s)、堆大小(同步6MB)等
-- [[Bulkification]]：批量处理模式 — 要求所有触发器和 Apex 代码必须能在单次交易中处理多条记录（通常按 200 条/批次测试）
-- [[PlatformEvents]]：Salesforce 平台事件 — 用于跨系统集成的异步事件驱动机制，支持 72 小时重放窗口和高容量标准（10万/天）
-- [[ChangeDataCapture]]（CDC）：变更数据捕获 — 自动追踪 sObject 字段级变更，适合 Salesforce 原生事件同步场景
-- [[ADR]]（Architecture Decision Record）：架构决策记录 — 文档化记录重要技术决策的上下文、备选方案、后果和复审日期
-- [[SalesforceDX]]：Salesforce 开发者体验框架 — 基于 Scratch Org 的源代码驱动部署方式，与 DevOps Center 并行
-- [[Agentforce]]：Salesforce AI Agent 框架 — Agent 在 Salesforce governor limits 内运行，需设计在 CPU/SOQL 预算内完成的动作，使用 Einstein Trust Layer 进行 PII 脱敏
+- [[GovernorLimits]]：Salesforce平台的执行限制（SOQL/DML/CPU/Heap等），每次同步事务必须严格在预算内运行，是架构设计的核心约束
+- [[Bulkification]]：批处理化原则，要求代码能高效处理200条记录的批量操作，而非逐条处理
+- [[IntegrationPatternTemplate]]：Salesforce与其他系统集成的标准模式模板，涵盖认证（OAuth2）、格式（JSON）、重试（3x指数退避）、死信队列（error__c对象）等
+- [[ADR]]：Architecture Decision Record，架构决策记录文档，用于记录每个重要技术决策的背景、方案、备选、后果和复审日期
+- [[TriggerFramework]]：Trigger仅做委托，业务逻辑下沉到Handler类，每个sObject一个Trigger
+- [[DeclarativeFirst]]：优先使用Flow、公式字段、验证规则等声明式工具，只在声明式不可维护时才引入Apex代码
+- [[PlatformEvents]]：Salesforce事件驱动架构，支持72小时重放窗口，适合高容量业务事件和跨系统集成
+- [[ChangeDataCapture]]：CDC，变更数据捕获，适合字段级变更追踪，但仅支持Salesforce原生事件，不支持自定义Schema
+- [[MultiCloudArchitecture]]：跨Sales Cloud、Service Cloud、Marketing Cloud、Data Cloud、Agentforce的统一数据架构设计
+- [[AgentforceArchitecture]]：Salesforce AI Agent的架构设计原则，包括Prompt版本控制、RAG模式（Data Cloud而非SOQL）、Einstein Trust Layer安全防护
 
 ## Key Entities
-- [[MuleSoft]]：Salesforce 收购的企业级集成中间件，用于跨系统集成模式中的中间转换层（DataWeave 转换、3x 指数退避重试、死信队列）
-- [[ShieldPlatformEncryption]]：Salesforce 原生 PII 加密方案，与自定义加密并列作为敏感数据保护选项
-- [[DevOpsCenter]]：Salesforce 原生 CI/CD 平台，与 Salesforce DX 并行的另一种部署方式
+- [[MuleSoft]]：企业集成中间件，Salesforce官方推荐集成平台，支持DataWeave转换、OAuth2认证、DLQ死信队列
+- [[SalesforceDX]]：Salesforce的现代化开发工具链，包含Scratch Org、CI/CD、Source Tracking
+- [[DevOpsCenter]]：Salesforce的DevOps中心化管理平台，用于部署流水线管理
+- [[ShieldPlatformEncryption]]：Salesforce数据加密方案，用于敏感PII数据的字段级加密
+- [[DataCloud]]：Salesforce统一数据平台，用于身份解析、用户画像和RAG grounding
+- [[Agentforce]]：Salesforce AI Agent产品线，允许构建在Salesforce平台内运行的AI Agent
 
 ## Connections
-- [[SalesforceDX]] ← supports ← [[ADR]]
-- [[PlatformEvents]] ← extends ← [[ChangeDataCapture]]
-- [[Bulkification]] ← enforces ← [[GovernorLimits]]
-- [[Agentforce]] ← bounded_by ← [[GovernorLimits]]
+- [[SalesforceDX]] ← uses ← [[CI/CD]]
+- [[IntegrationPatternTemplate]] ← builds_on ← [[PlatformEvents]]
+- [[MultiCloudArchitecture]] ← coordinates ← [[DataCloud]]
+- [[AgentforceArchitecture]] ← constrained_by ← [[GovernorLimits]]
+- [[ADR]] ← documents ← [[ArchitecturalDecision]]
 
 ## Contradictions
-- 与 [[DevOpsCenter]] 关系：
-  - 冲突点：Salesforce DX 与 DevOps Center 是两种并行的部署策略，文档将两者并列但未明确优先选用哪个
-  - 当前观点：Salesforce DX 基于 Scratch Org 源码驱动是现代标准实践
-  - 对方观点：DevOps Center 作为 Salesforce 原生工具对非技术用户更友好
+- 无明显内容冲突。该文档是Agent人格定义，属于方法论性质，与现有Wiki页面不构成事实性冲突。
diff --git a/wiki/sources/specialized-workflow-architect.md b/wiki/sources/specialized-workflow-architect.md
index 991949fc..a71fa6f5 100644
--- a/wiki/sources/specialized-workflow-architect.md
+++ b/wiki/sources/specialized-workflow-architect.md
@@ -2,7 +2,7 @@
 title: "Workflow Architect Agent Personality"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-05-02
 ---
 
 ## Source File
@@ -10,9 +10,9 @@ date: 2026-04-25
 
 ## Summary（用中文描述）
 - 核心主题：Workflow Architect——工作流设计专家 Agent，负责在代码编写前对系统所有路径进行穷举建模与规范输出。
-- 问题域：隐式工作流（代码中存在但无规范）、分支缺失、故障恢复路径未定义、系统边界交接合同模糊、代码与规范漂移。
-- 方法/机制：工作流注册表（四视角）、工作流树规范格式（覆盖快乐路径+所有失败分支+清理清单）、交接合同规范、发现审计清单、Reality Checker 交叉验证、Agent 协作协议。
-- 结论/价值：工程师可依据规范实现、QA 可直接生成测试用例、运维可理解系统行为、成功指标为零孤岛资源/假设表持续缩减。
+- 问题域：隐式工作流（代码中存在但无规范）、分支缺失、故障恢复路径未定义、系统边界交接合同模糊、代码与规范漂移、竞态条件、数据持久化假设、网络连通性假设。
+- 方法/机制：工作流注册表（四视角）、工作流树规范格式（覆盖快乐路径+所有失败分支+清理清单）、交接合同规范、发现审计清单、Reality Checker 交叉验证、Agent 协作协议（Backend Architect / Security Engineer / API Tester / DevOps Automator）、好奇心驱动式 Bug 发现。
+- 结论/价值：工程师可依据规范实现、QA 可直接生成测试用例、运维可理解系统行为、成功指标为零孤岛资源/假设表持续缩减/注册表中无 Missing 状态工作流。
 
 ## Key Claims（用中文描述）
 - 代码中存在但无规范的工作流是隐患——它会在无人了解其全貌时被修改并导致故障。
@@ -20,6 +20,8 @@ date: 2026-04-25
 - 每个工作流必须覆盖七类分支：快乐路径、输入验证失败、超时失败、瞬态失败、永久失败、部分失败、并发冲突。
 - 工作流状态必须同时回答四个维度：客户看到什么、运维看到什么、数据库中有什么、日志中有什么。
 - Reality Checker 验证是规范从 Draft 升为 Approved 的前置条件，不可跳过。
+- 每个工作流树中的分支必须对应一个测试用例——没有测试用例的分支将在生产环境中断言。
+- 假设表随时间应持续缩减，每个假设最终应被验证或修正。
 
 ## Key Quotes
 > "I do not design for the happy path only." — Workflow Architect 核心原则
@@ -28,6 +30,8 @@ date: 2026-04-25
 
 > "Every step that depends on something else being already done is a potential race condition." — 命名时序假设
 
+> "Every branch in the workflow tree = one test case. If a branch has no test case, it will not be tested. If it will not be tested, it will break in production." — 测试用例覆盖率原则
+
 ## Key Concepts
 - [[Workflow-Registry]]：四视角交叉索引工作流注册表（按工作流/按组件/按用户旅程/按状态），维护所有工作流状态（Approved/Review/Draft/Missing/Deprecated）
 - [[Observable-States]]：每个工作流状态必须同时描述客户视图、运维视图、数据库视图、日志视图
@@ -36,6 +40,8 @@ date: 2026-04-25
 - [[Cleanup-Inventory]]：完整资源销毁清单，每项资源必须有对应清理动作
 - [[Discovery-Audit]]：发现审计清单——扫描所有 route/worker/migration/IaC/cron/event-listener/webhook 文件找出隐式工作流
 - [[Reality-Checker]]：规范验证流程，由 Reality Checker Agent 将规范与实际代码对照，报告差距
+- [[Agent-Collaboration-Protocol]]：Workflow Architect 与 Backend Architect / Security Engineer / API Tester / DevOps Automator 的标准化协作流程
+- [[Curiosity-Driven-Bug-Discovery]]：通过追问数据持久化假设、网络连通性假设、时序假设、认证假设来主动发现高危 Bug
 
 ## Key Entities
 - [[Backend-Architect]]：工作流规范依赖 Backend Architect 实现具体代码；工作流揭示实现缺陷时向其发起修复协作
@@ -50,6 +56,7 @@ date: 2026-04-25
 - [[API-Tester]] ← generates test cases from ← [[Workflow-Tree-Spec]]（从规范导出测试用例）
 - [[DevOps-Automator]] ← maintains ← [[Cleanup-Inventory]]（验证销毁顺序）
 - [[Security-Engineer]] ← reviews ← [[Handoff-Contract]]（凭证传递安全性审查）
+- [[Agent-Collaboration-Protocol]] → coordinates → [[Backend-Architect]], [[Security-Engineer]], [[API-Tester]], [[DevOps-Automator]]（规范化 Agent 间协作流程）
 
 ## Contradictions
 - 与 [[Designing-for-Agentic-AI]] 潜在冲突：
diff --git a/wiki/sources/sre-weekly-issue-513.md b/wiki/sources/sre-weekly-issue-513.md
new file mode 100644
index 00000000..50c0fd22
--- /dev/null
+++ b/wiki/sources/sre-weekly-issue-513.md
@@ -0,0 +1,60 @@
+---
+title: "SRE Weekly Issue #513"
+type: source
+tags: [clippings, sre, weekly, reliability]
+date: 2026-04-20
+---
+
+## Source File
+- [[Cloud & DevOps/SRE Weekly Issue 513]]
+
+## Summary（用中文描述）
+- 核心主题：SRE 领域的 8 篇精选文章，涵盖组织韧性、容器调度、成本可观测性、弹性计算、AI 辅助值班等主题
+- 问题域：SRE 实践中的组织级故障处理、现代 CPU 架构挑战、云成本管理、自动扩缩容局限性、AI 辅助运维、可观测性建设
+- 方法/机制：组织二次冲击综合征（类比神经学 SIS）、NUMA 感知容器调度、成本作为分布式系统 bug、AI 辅助值班上下文、弹性（Elasticity）vs 自动扩缩容（Autoscaling）、可观测性所有权迁移
+- 结论/价值：SRE 需要理解全栈、警惕成本失控、AI 最大价值在于上下文辅助而非自动修复、真正的弹性需要策略和测试
+
+## Key Claims（用中文描述）
+- 组织二次冲击综合征（Organizational Second Hit Syndrome）指重大故障后产生的脆弱期，在此期间发生的第二次故障会引发强烈、广泛且有时具破坏性的组织反应
+- Netflix 在现代 CPU 上运行容器时面临超过 2 万次挂载操作（mount）和 NUMA 问题，SRE 必须关注整个技术栈
+- 成本爆炸（cost explosion）是一种可靠性问题——成本突然上升应被视为"某处即将出错"的告警信号
+- 自动扩缩容（Autoscaling）是被动的，而非弹性的；缺乏上限、指标或覆盖机制时，它会加剧故障
+- AI 在 SRE 中最有价值的作用不是自主修复，而是确保值班工程师有足够的上下文来快速修复故障
+- 真正的弹性（Elasticity）需要策略、测试和对瓶颈的认知，而非单纯的自动化
+
+## Key Quotes
+> "Organizational Second Hit Syndrome is an incident-related phenomenon analogous to neurological second-impact-syndrome (SIS). It occurs when a major incident creates a vulnerable period during which a second incident generates strong, widespread, and sometimes destructive organizational reactions." — John Allspaw and Dr. Richard I. Cook, Adaptive Capacity Labs
+
+> "Autoscaling is reactive, not resilient. Without caps, metrics, or overrides, it can worsen failures." — David Iyanu Jonathan, DZone
+
+> "Heinrich Hartmann argues AI's most valuable role in SRE isn't autonomous remediation. It's making sure on-call engineers have the context to fix incidents fast." — Peter Farago, RunLLM
+
+## Key Concepts
+- [[Organizational-Second-Hit-Syndrome]]：重大故障后产生的组织脆弱期，期间第二次故障会引发强烈破坏性组织反应
+- [[NUMA]]（Non-Uniform Memory Access）：现代 CPU 架构，内存访问延迟与 CPU 和内存节点距离相关，影响容器调度的性能
+- [[Autoscaling]]：自动扩缩容，被动的反应式机制；与主动的弹性（Elasticity）相对
+- [[Elasticity]]：真正的弹性，需要策略、测试和瓶颈认知；与 Autoscaling 的核心区别在于主动规划和容量管理
+- [[Cost-As-Distributed-Systems-Bug]]：成本异常可视为分布式系统故障的前兆信号，成本突增需要告警
+- [[AI-For-On-Call]]：AI 在值班中的最大价值是提供上下文辅助，而非自主修复
+- [[Resilience]]：系统韧性，5 种无法被自动化的韧性要素：学习、决策、优先级排序、沟通、适应
+- [[Observability]]：可观测性，Airbnb 从供应商迁移到内部自主的可观测性所有权模式
+
+## Key Entities
+- [[Netflix]]：全球最大流媒体平台，在现代 CPU 上运行容器时面临 NUMA 和大规模挂载挑战
+- [[Richard-Cook]]：Adaptive Capacity Labs，著有《Organizational Second Hit Syndrome》
+- [[John-Allspaw]]：Adaptive Capacity Labs，与 Richard Cook 共同提出组织二次冲击综合征
+- [[Airbnb]]：从供应商迁移到自建可观测性栈的实践者，展示了如何通过早期胜利建立团队认同
+- [[RunLLM]]：AI 辅助运维产品，聚焦于值班上下文的快速故障修复
+
+## Connections
+- [[Organizational-Second-Hit-Syndrome]] ← extends ← [[Incident-Response]]
+- [[NUMA]] ← affects ← [[Containers]]
+- [[Cost-As-Distributed-Systems-Bug]] ← relates_to ← [[Distributed-Systems]]
+- [[Elasticity]] ← opposes ← [[Autoscaling]]
+- [[AI-For-On-Call]] ← enables ← [[Incident-Response]]
+
+## Contradictions
+- 与 [[Autoscaling]] 概念存在关系：
+  - 冲突点：Autoscaling 被描述为"非弹性"，但实践中常被等同于弹性
+  - 当前观点：Autoscaling 是被动的、反应式的，缺乏主动容量管理会加剧故障
+  - 对方观点：Autoscaling 提供了动态资源调整能力，是云原生的核心特性
diff --git a/wiki/sources/study-abroad-advisor.md b/wiki/sources/study-abroad-advisor.md
index c1b50e8a..9a6e0c8a 100644
--- a/wiki/sources/study-abroad-advisor.md
+++ b/wiki/sources/study-abroad-advisor.md
@@ -2,7 +2,7 @@
 title: "Study Abroad Advisor"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-05-29
 ---
 
 ## Source File
@@ -10,31 +10,36 @@ date: 2026-04-25
 
 ## Summary（用中文描述）
 - 核心主题：面向中国学生的全链路留学申请规划专家 Agent，覆盖美国/英国/加拿大/澳大利亚/欧洲/香港/新加坡七大留学目的地，涵盖本科/硕士/博士全学位层次，从选校定位到行前准备的完整流程。
-- 问题域：留学申请策略、选校定位、文书写作、背景提升、考试规划、签证办理、Offer 比较决策。
-- 方法/机制：四步工作流（全面诊断→策略制定→材料打磨→提交跟进）；数据驱动的选校概率区间（Reach 20-40% / Target 40-70% / Safety 70-90%）；多国联申时间线协调；标准化交付模板（选校报告、多国申请时间线、文书诊断、Offer 比较矩阵）。
-- 结论/价值：为每位学生提供端到端、个性化的留学规划，消除申请焦虑，强调数据透明与诚信原则（不代写文书、不夸大经历、不承诺录取结果）。
+- 问题域：留学申请策略、选校定位、文书写作、背景提升、考试规划、签证办理、Offer 比较决策、多国联申时间线协调。
+- 方法/机制：四步工作流（全面诊断→策略制定→材料打磨→提交跟进）；数据驱动的选校概率区间（Reach 20-40% / Target 40-70% / Safety 70-90%）；多国联申策略；标准化交付模板（选校报告、多国申请时间线、文书诊断框架、Offer 比较矩阵）。
+- 结论/价值：为每位学生提供端到端、个性化的留学规划，消除申请焦虑，强调数据透明与诚信原则（不代写文书、不夸大经历、不承诺录取结果）。成功指标：Target school 录取率 >60%、关键数据零错误、申请零延误。
 
 ## Key Claims（用中文描述）
-- Study Abroad Advisor 通过数据驱动方法，能帮助 GPA 3.2 的学生进入 Top 30， 也可能让 GPA 3.9 的学生全拒——关键在于选校策略和文书质量。
-- 多国联申策略（如 US+UK、US+HK+Singapore）需要精确的时间线协调和精力分配，但能显著提升录取概率。
-- 诚信原则（不代写文书、不承诺结果）是留学咨询的核心底线，任何"保证录取"的承诺都是骗局。
-- 文书不是经历的流水账列表，而是围绕核心叙事弧（你是谁→去哪→为什么是这个项目）的故事化表达。
-- 选校推荐必须区分"确认信息"和"经验估算"， admission probability 以区间而非精确数字表达。
+- Study Abroad Advisor 通过数据驱动方法，能帮助 GPA 3.2 的学生进入 Top 30，也可能因选校策略失误导致 GPA 3.9 学生全拒——关键在于定位精确和文书质量。
+- 七国申请体系差异显著：美国高灵活性、全人评估、博士全奖常见；英国效率高（1年硕士）、学术背景导向；加拿大移民友好；澳大利亚灵活、移民加分；欧洲公立低学费；香港近且有 IANG 签证；新加坡 NUS/NTU 亚洲顶尖。
+- 文书不是经历的流水账列表，而是围绕核心叙事弧（你是谁→去哪→为什么是这个项目）的故事化表达；UK 本科 PS 需 80% 聚焦学术。
+- 诚信原则（不代写文书、不承诺结果）是留学咨询核心底线；推荐信必须由推荐人真实撰写或背书。
+- 选校推荐必须区分"确认信息"和"经验估算"，admission probability 以区间而非精确数字表达。
+- Profile 提升的优先排序：研究经历 > 实习 > 竞赛/认证 > 项目经历——按目标项目录取偏好分配精力。
 
 ## Key Quotes
 > "This program admitted about 200 students last year, roughly 40 from China, with a median GPA of 3.6. Your 3.5 is within range but not strong — you'll need essays and experiences to compensate." — 数据驱动的录取概率沟通
 > "Top 10 isn't on your menu right now, but Top 30 is within reach. Let's focus energy where the odds are highest." — 务实选校，避免焦虑贩卖
 > "You think your Hackathon experience doesn't matter? You led a team to build a product with real users from scratch in 48 hours — that's exactly the kind of initiative engineering programs look for." — 优势挖掘，赋能学生信心
+> "Multi-country applications: US+UK, US+HK+Singapore, UK+Australia combinations require timeline coordination and effort allocation." — 多国联申策略
 
 ## Key Concepts
 - [[Holistic-Admissions]]：全面评估录取模式——综合考量 GPA、标准化考试成绩、课外活动、文书、推荐信等多维度，非单一成绩决定。
-- [[UCAS-System]]：英国本科统一申请系统——学生通过 UCAS 可同时申请最多 5 所英国大学，个人陈述（Personal Statement）需面向所有申请学校，4,000 字符限制，80% 内容须聚焦学术热情。
-- [[IANG-Visa]]：非本地毕业生留港就业安排（Immigration Arrangement for Non-local Graduates）——香港为在港毕业生提供毕业后留港工作签证，无配额限制，是香港留学的核心吸引力之一。
+- [[UCAS-System]]：英国本科统一申请系统——学生通过 UCAS 可同时申请最多 5 所英国大学，个人陈述需面向所有申请学校，4,000 字符限制，80% 内容须聚焦学术热情。
+- [[IANG-Visa]]：非本地毕业生留港就业安排——香港为在港毕业生提供毕业后留港工作签证，无配额限制，是香港留学的核心吸引力之一。
 - [[Grandes-Ecoles]]：法国精英大学体系——与公立大学并行的高等教育精英通道，需通过竞考（concours）入学，毕业后享有高社会认可度。
+- [[Taoxi]]：主动联系潜在导师——博士申请中主动通过邮件联系目标导师的策略，是 PhD 申请和理科硕士申请的关键步骤。
+- [[Three-Tier-School-Selection]]：三档选校策略——Reach（录取概率 20-40%）、Target（40-70%）、Safety（70-90%），搭配概率区间表达而非精确数字。
 
 ## Key Entities
 - The Agency Specialized 部门：该 Agent 归属 The Agency 多智能体系统的 Specialized 部门，与 Agents Orchestrator、Identity Graph Operator、MCP Builder Agent、Agentic Identity & Trust Architect 等 Specialist 同事协同工作。
 - 1point3acres（一亩三分地）：中国留学生社区论坛，是学生验证录取数据、校友去向、申请经验的重要信息来源，Agent 鼓励学生通过该论坛核实关键数据。
+- NUS/NTU：新加坡国立大学和南洋理工大学，亚洲排名顶尖，提供慷慨奖学金，国际化就业市场，是新加坡留学的两大核心院校。
 
 ## Connections
 - [[Agents-Orchestrator]] ← coordinates_with ← Study Abroad Advisor
@@ -42,6 +47,9 @@ date: 2026-04-25
 - [[identity-graph-operator]] ← same_department ← Study Abroad Advisor
 - [[agentic-identity-trust]] ← same_department ← Study Abroad Advisor
 - [[ProjectManagerSenior]] ← supports ← Study Abroad Advisor（两者均服务于 The Agency 的项目管理体系，PM 产出的任务列表可支撑留学规划的项目化执行）
+- [[Holistic-Admissions]] ← applies_to ← Three-Tier-School-Selection（全人评估驱动三档选校概率区间划分）
+- [[IANG-Visa]] ← enables ← [[Grandes-Ecoles]]（香港与法国留学选择中的签证/居留政策对比）
 
 ## Contradictions
 - 与其他 Agent 的信息呈现方式：Study Abroad Advisor 明确采用数据驱动、零焦虑贩卖的原则，而其他面向消费者的 Agent（如一般营销 Agent）可能倾向于过度承诺录取结果。核心区别在于：前者明确区分"确认信息"和"经验估算"，后者缺乏这种信息透明度约束。
+- 选校概率的张力：Agent 强调"不承诺录取结果"，但同时声称"Target school 录取率 >60%"作为成功指标——两者存在内在张力，实际录取结果受多种不可控因素影响，成功指标应为"选校合理性"而非直接"录取率"。
diff --git a/wiki/sources/supply-chain-strategist.md b/wiki/sources/supply-chain-strategist.md
index 0e42cc11..ec65108b 100644
--- a/wiki/sources/supply-chain-strategist.md
+++ b/wiki/sources/supply-chain-strategist.md
@@ -1,7 +1,7 @@
 ---
 title: "Supply Chain Strategist Agent"
 type: source
-tags: [agent, supply-chain, procurement, china-manufacturing, strategy]
+tags: ["supply-chain", "procurement", "agent", "manufacturing", "china"]
 date: 2026-04-25
 ---
 
@@ -9,67 +9,62 @@ date: 2026-04-25
 - [[raw/Agent/agency-agents/specialized/supply-chain-strategist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：基于中国制造业生态的专业供应链管理与战略采购 Agent，帮助企业建立高效、有韧性、可持续的供应链体系
-- 问题域：供应商管理、战略寻源、质量控制、库存优化、供应链数字化、成本管控、风险管理与合规 ESG
-- 方法/机制：Kraljic 矩阵分类采购策略、ABC 分级供应商管理、QCD 绩效评估、TCO 全成本分析、库存模型（EOQ/ROP/安全库存）、数字化成熟度评估
-- 结论/价值：提供端到端供应链解决方案，从供应商开发寻源到危机响应，覆盖采购、物流、库存、合规全链路
+- 核心主题：SupplyChainStrategist Agent — 专注于中国制造业生态的供应链管理与战略采购专家智能体
+- 问题域：供应商管理、战略采购、质量控制、物流仓储、供应链数字化、成本控制与风险管理
+- 方法/机制：Kraljic 矩阵分类采购策略、ABC 分级供应商管理、QCD 绩效考核、TCO 全成本分析、库存优化模型（EOQ/安全库存/再订货点）、多源采购策略
+- 结论/价值：帮助企业在降低采购成本的同时提升供应链韧性，通过数字化工具和数据驱动决策实现端到端供应链优化
 
 ## Key Claims（用中文描述）
-- 供应商 ABC 分级管理 + 战略合作伙伴关系升级，能显著提升供应链稳定性
-- Kraljic 矩阵定位采购类别，配合差异化采购策略，可实现年度采购成本降低 5-8%
-- TCO（全成本拥有权）分析是采购决策依据，而非单纯比较单价
-- 关键物料必须多源采购，单一来源是最高风险项
-- 供应链数字化成熟度分 5 级（L1 手动 → L5 自主智能），成熟度提升路径明确
-- 供应商绩效评估必须数据驱动，主观评价不超过 20%
+- 企业通过分类采购策略（Kraljic Matrix）可实现年度采购成本降低 5-8% 而不影响质量
+- 供应商绩效评估必须数据驱动，主观评价占比不超过 20%；QCD 体系（Quality 质量、Cost 成本、Delivery 交付）是核心
+- 关键物料不得单一来源化，必须开发备选供应商；战略物料需至少 3 个合格供应商
+- TCO（全生命周期成本）是采购决策依据，而非单一单价；库存管理需结合 EOQ、安全库存和再订货点模型
+- 供应链数字化成熟度从 L1（手动阶段）到 L5（自主智能阶段），企业需按阶段推进
 
 ## Key Quotes
-> "Critical materials must never be single-sourced — verified alternative suppliers are mandatory" — 供应链安全第一原则
-> "TCO (Total Cost of Ownership) is the decision-making basis, not unit purchase price alone" — 成本决策核心原则
-> "Quality issues must be traced to root cause — superficial fixes are insufficient" — 质量管控原则
-> "Through consolidated purchasing, fastener category annual procurement costs decreased 12%, saving ¥870,000" — 数据驱动沟通风格示例
+> "Critical materials must never be single-sourced — verified alternative suppliers are mandatory." — 供应链安全铁律
+> "TCO (Total Cost of Ownership) is the decision-making basis, not unit purchase price alone." — 采购决策原则
+> "Supplier performance assessment must be data-driven — subjective evaluation should not exceed 20%." — 供应商绩效考核原则
+> "Through consolidated purchasing, fastener category annual procurement costs decreased 12%, saving ¥870,000." — 数据驱动降本案例
 
 ## Key Concepts
-- [[Kraljic Matrix]]：按采购类别特性（供应风险 × 利润影响）将物料分为战略型、杠杆型、瓶颈型、常规型，对应差异化采购策略
-- [[ABC Classification]]：供应商/物料分级管理（A 类战略重点、B 类重要、C 类常规），差异化资源配置
-- [[QCD Assessment]]：Quality-Quality、Cost、Delivery 三维供应商绩效评分体系，每季度评分年度淘汰
-- [[TCO Analysis]]：Total Cost of Ownership 全成本拥有权分析，涵盖直接成本、间接成本、隐性成本、全生命周期成本
-- [[EOQ Model]]：经济订货量模型，平衡订货成本与持有成本
-- [[Safety Stock & ROP]]：安全库存与再订货点，结合 Z 值与服务水平计算
-- [[VMI]]：Vendor-Managed Inventory，供应商管理库存，减少买方库存负担
-- [[JIT Procurement]]：Just-In-Time 准时制采购，降低持有成本但要求供应链高度可靠
-- [[Supply Chain Digital Maturity]]：供应链数字化成熟度 5 级模型（L1-L5），从手动到自主智能
-- [[8D Report]]：质量问题闭环解决报告，CAPA 纠正预防措施
-- [[AQL Sampling]]：Acceptable Quality Limit，来料抽样检验标准（GB/T 2828.1 / ISO 2859-1）
-- [[RBA Code of Conduct]]：Responsible Business Alliance 电子行业社会责任行为准则
-- [[SA8000]]：社会责任国际标准，涵盖禁用童工/强迫劳动、工时薪资、职业健康安全
-- [[ERP-MM]]：SAP Materials Management 模块，物料管理系统
-- [[SRM Platform]]：Supplier Relationship Management，供应商关系管理平台
+- [[Kraljic Matrix]]：供应商分类框架，将采购品类按风险和利润影响分为战略型、杠杆型、瓶颈型、常规型四类，制定差异化采购策略
+- [[QCD 绩效体系]]（Quality / Cost / Delivery）：供应商绩效考核三维度，质量合格率、成本目标达成率、交付准时率
+- [[TCO]]（Total Cost of Ownership，全成本采购）：综合考虑直接成本、间接成本和隐性成本，以总拥有成本而非单价作为采购决策依据（[[TCO]] 页面另有云计算 TCO 分析框架）
+- [[EOQ]]（Economic Order Quantity，经济订货批量）：EOQ = √(2DS/H)，平衡订货成本与持有成本的最优订货量
+- [[Safety Stock]]（安全库存）：基于服务水平（Service Level）和需求标准差计算，用于应对需求和供应波动
+- [[Reorder Point]]（再订货点）：ROP = 日均需求 × 采购提前期 + 安全库存
+- [[ABC Classification]]（ABC 分类）：供应商分级管理，将供应商分为战略型、杠杆型、瓶颈型、常规型，差异化策略管理
+- [[AQL]]（Acceptable Quality Limit，可接受质量限）：GB/T 2828.1 / ISO 2859-1 抽样检验标准，定义检验水平和可接受质量限
+- [[JIT]]（Just-In-Time）：准时制生产，适合需求稳定且供应商可靠的场景，持有成本低但供应链可靠性要求高
+- [[VMI]]（Vendor-Managed Inventory，供应商管理库存）：供应商负责补货，适合标准件和大宗材料，降低买方库存负担
+- [[IQC / IPQC / OQC]]（进料/过程/出货质量控制）：端到端质量控制体系
+- [[8D Report]] / [[CAPA]]（纠正和预防措施）：闭环质量问题解决机制
+- [[Supply Chain Digital Maturity]]（供应链数字化成熟度）：L1-L5 五级评估模型，从手动到自主智能
+- [[SRM]]（Supplier Relationship Management，供应商关系管理）：从纯交易关系升级为战略合作伙伴关系
+- [[ERP]]（Enterprise Resource Planning，企业资源计划）：SAP、用友、金蝶等 ERP 系统与供应链模块集成
 
 ## Key Entities
-- [[1688/Alibaba]]：中国最大 B2B 电商平台，适合标准件和通用材料采购
-- [[Made-in-China.com]]：中国制造网，面向出口型工厂的国际贸易平台
-- [[Global Sources]]：环球资源，高端制造商目录，适合电子和消费品
-- [[Canton Fair]]：广交会（中国进出口商品交易会），春秋两届全品类供应商集中地
-- [[SGS/TUV/Bureau Veritas/Intertek]]：第三方检验机构，负责工厂审核和产品认证
-- [[SAP Ariba]]：全球采购网络平台，适合跨国企业
-- [[ZhenYun（甄云）]]：全流程数字化采购平台，适合制造业
-- [[QiQiTong（企企通）]]：中小企业供应商协同平台
-- [[Yonyou Procurement Cloud]]：用友采购云，与用友 ERP 深度集成
-- [[Manbang/满帮]]：公路货运匹配平台，用于整车运输
-- [[Huolala/货拉拉]]：同城及跨城货运匹配平台
-- [[QiChaCha/Tianyancha]]：企查查/天眼查，企业信息查询平台，用于供应商资质验证
-- [[Kraljic Matrix]]：卡尔吉克矩阵（采购品类定位工具）
+- **1688 / Alibaba**：中国最大 B2B 电商平台，适合标准件和通用材料采购，评估卖家等级：实力商家 > 超级工厂 > 标准店铺
+- **Made-in-China.com**（中国制造网）：出口导向型工厂平台，适合寻找有国际贸易经验的供应商
+- **Global Sources**（环球资源）：高端制造商集中地，适合电子和消费品类目
+- **Canton Fair**（广交会）：中国进出口商品交易会，每年春秋两届，全品类供应商集中
+- **SGS / TUV / Bureau Veritas / Intertek**：第三方检验机构，负责工厂审计和产品认证
+- **SAP / Yonyou / Kingdee**：主流 ERP 系统厂商，SAP 面向大型集团，用友/金蝶面向中大型民营企业
+- **ZhenYun（甄云）/ QiQiTong（企企通）/ SAP Ariba**：SRM 采购管理平台
+- **Manbang（满帮）/ Huolala（货拉拉）**：公路货运匹配平台，用于整车运输
+- **SF Express / JD Logistics**：国内快递和物流服务商
+- **QiChaCha（企查查）/ Tianyancha（天眼查）**：企业信息查询平台，用于供应商资质验证
+- **Deppon（德邦）/ Ane（安能）**：零担货运服务商
 
 ## Connections
-- [[Supply Chain Strategist]] ← 供应商管理核心 → [[ABC Classification]]
-- [[Supply Chain Strategist]] ← 采购策略框架 → [[Kraljic Matrix]]
-- [[Supply Chain Strategist]] ← 成本决策方法 → [[TCO Analysis]]
-- [[Supply Chain Strategist]] ← 库存优化工具 → [[EOQ Model]]
-- [[Supply Chain Strategist]] ← 数字化成熟度 → [[Supply Chain Digital Maturity]]
-- [[Supply Chain Strategist]] ← 合规审计标准 → [[RBA Code of Conduct]], [[SA8000]]
+- [[Supply Chain Strategist Agent]] ← specializes_in ← [[Supply Chain Management]]
+- [[Supply Chain Strategist Agent]] ← uses_tool ← [[Kraljic Matrix]]
+- [[Supply Chain Strategist Agent]] ← depends_on ← [[ERP Systems Integration]]
+- [[Supply Chain Strategist Agent]] ← manages ← [[Supplier Relationship Management]]
+- [[TCO]] ← is_component_of ← [[Supply Chain Cost Control]]
+- [[EOQ]] ← is_model_of ← [[Inventory Optimization]]
+- [[IQC / IPQC / OQC]] ← is_system_of ← [[Quality Control]]
 
 ## Contradictions
-- 与 [[JIT Procurement]] 的对比：
-  - 冲突点：JIT 追求零库存与安全库存原则之间的平衡
-  - 当前观点：关键物料必须设置安全库存，防止单点供应断裂
-  - 对方观点（纯 JIT 派）：零库存是最优目标，可通过高可靠性供应链实现
+- 暂无与其他 Wiki 页面的已知冲突
diff --git a/wiki/sources/support-analytics-reporter.md b/wiki/sources/support-analytics-reporter.md
index 01a8cb0f..13b7941f 100644
--- a/wiki/sources/support-analytics-reporter.md
+++ b/wiki/sources/support-analytics-reporter.md
@@ -2,7 +2,7 @@
 title: "Analytics Reporter Agent Personality"
 type: source
 tags: []
-date: 2026-04-21
+date: 2026-04-30
 ---
 
 ## Source File
@@ -10,36 +10,39 @@ date: 2026-04-21
 
 ## Summary（用中文描述）
 - 核心主题：数据分析师型 AI Agent 的角色定义与行为规范，专注于将原始数据转化为可操作的业务洞察
-- 问题域：数据分析、报告生成、商业智能、KPI 追踪、决策支持
-- 方法/机制：四步工作流（数据发现验证→分析框架开发→洞察生成可视化→业务影响测量）、SQL/Python/统计建模、RFM 客户分层、营销归因模型、预测分析
-- 结论/价值：为数据分析类 Agent 提供系统化的人格定义、交付物模板和技术实现框架，确保数据驱动决策的质量和可重复性
+- 问题域：数据分析、报告生成、商业智能、KPI 追踪、决策支持、预测建模
+- 方法/机制：四步工作流（数据发现验证→分析框架开发→洞察生成可视化→业务影响测量）；技术栈：SQL（复杂 CTE 查询）、Python（pandas/scikit-learn KMeans 客户分层）、统计分析（RFM、回归、预测、显著性检验）；交付物：Executive Dashboard、Customer Segmentation、RFM Analysis、Marketing Attribution Dashboard
+- 结论/价值：为数据分析类 Agent 提供系统化的人格定义、交付物模板和技术实现框架，确保数据驱动决策的质量和可重复性；成功率指标：95% 分析准确率、70%+ 建议采纳率、95% Dashboard 月活使用率、20%+ KPI 改善
 
 ## Key Claims（用中文描述）
-- 数据质量优先：所有分析前必须验证数据准确性、完整性和统计显著性（p-value < 0.05）
-- 业务影响聚焦：所有分析必须连接到业务成果和可操作洞察，优先推动决策的分析
+- 数据质量优先：所有分析前必须验证数据准确性、完整性和统计显著性（p-value < 0.05，95% 置信度）
+- 业务影响聚焦：所有分析必须连接到业务成果和可操作洞察，优先推动决策的分析而非探索性研究
 - 可重现性保证：建立版本控制和文档化的可重现分析工作流，确保结果可复现
 - 行动导向：分析结论必须包含具体的可执行建议和量化预期影响
 
 ## Key Quotes
 > "Be data-driven: 'Analysis of 50,000 customers shows 23% improvement in retention with 95% confidence'" — Analytics Reporter 沟通风格示例
 > "Focus on impact: 'This optimization could increase monthly revenue by $45,000 based on historical patterns'" — 量化业务影响原则
+> "Think statistically: 'With p-value < 0.05, we can confidently reject the null hypothesis'" — 统计显著性标准
 > "Ensure actionability: 'Recommend implementing segmented email campaigns targeting high-value customers'" — 可执行建议标准
 
 ## Key Concepts
-- [[RFM Analysis]]：Recency（最近购买）、Frequency（频率）、Monetary（金额）三维客户价值分层分析
-- [[Marketing Attribution]]：多触点归因模型，将转化收入按触点序列权重分配给各渠道/活动
-- [[Predictive Analytics]]：基于历史数据的预测建模，包括客户流失预测、增长预测
+- [[RFM Analysis]]：Recency（最近购买）、Frequency（频率）、Monetary（金额）三维客户价值分层分析，通过 K-Means 聚类将客户分为 Champions/Loyal Customers/Potential Loyalists/New Customers/At Risk/Cannot Lose Them 等细分群体
+- [[Marketing Attribution]]：多触点归因模型，将转化收入按触点序列权重（首触 40% / 末触 40% / 中间触点 20%）分配给各渠道/活动，计算 Campaign ROI
+- [[Predictive Analytics]]：基于历史数据的预测建模，包括客户流失预测、增长 forecasting、Customer Lifetime Value 计算
 - [[Statistical Significance]]：统计显著性检验，所有结论必须满足 p-value < 0.05 的置信标准
-- [[Business Intelligence Dashboard]]：执行仪表盘设计，包含 KPI 层级和钻取能力
+- [[Business Intelligence Dashboard]]：执行仪表盘设计，包含 KPI 层级和钻取能力，实时更新
+- [[K-Means Clustering]]：用于 RFM 客户细分的无监督机器学习聚类算法
 
 ## Key Entities
 - [[Analytics Reporter]]：本 Agent 本身，专业数据分析师角色，输出仪表盘、统计分析和战略决策支持
 - [[Executive Dashboard]]：执行仪表盘交付物，包含关键业务指标和 KPI 追踪
 
 ## Connections
-- [[support-finance-tracker]] ← related_to ← [[support-analytics-reporter]]
-- [[support-executive-summary-generator]] ← extends ← [[support-analytics-reporter]]
-- [[Report Distribution Agent]] ← related_to ← [[support-analytics-reporter]]
+- [[support-finance-tracker]] ← related_to ← [[support-analytics-reporter]]（财务追踪与数据分析协同）
+- [[support-executive-summary-generator]] ← extends ← [[support-analytics-reporter]]（执行摘要建立在分析数据之上）
+- [[Report Distribution Agent]] ← related_to ← [[support-analytics-reporter]]（报告分发基于分析产出）
+- [[support-infrastructure-maintainer]] ← depends_on ← [[support-analytics-reporter]]（基础设施指标分析依赖底层系统监控数据）
 
 ## Contradictions
 - 暂无已知冲突
diff --git a/wiki/sources/support-executive-summary-generator.md b/wiki/sources/support-executive-summary-generator.md
index 32a914a0..82a04bea 100644
--- a/wiki/sources/support-executive-summary-generator.md
+++ b/wiki/sources/support-executive-summary-generator.md
@@ -2,7 +2,7 @@
 title: "Executive Summary Generator Agent Personality"
 type: source
 tags: ["agent-personality", "consulting", "executive-communication", "business-analysis"]
-date: 2026-04-25
+date: 2026-04-26
 ---
 
 ## Source File
@@ -11,8 +11,8 @@ date: 2026-04-25
 ## Summary（用中文描述）
 - 核心主题：咨询级 AI Agent，专为 C-suite 决策者生成高管执行摘要
 - 问题域：如何将复杂冗长的商业输入转化为简洁、可执行的高管级决策文档
-- 方法/机制：融合麦肯锡 SCQA、BCG 金字塔原理、贝恩行动导向建议三大咨询框架；采用严格的 325-475 词输出标准；所有发现必须量化
-- 结论/价值：让高管在 3 分钟内把握本质、评估影响、做出决策；辅助而非替代人类判断
+- 方法/机制：融合麦肯锡 SCQA、BCG 金字塔原理、贝恩行动导向建议三大咨询框架；采用严格的 325-475 词输出标准；所有发现必须量化；四步工作流（Intake → Structure → Generate → QA）
+- 结论/价值：让高管在 3 分钟内把握本质、评估影响、做出决策；辅助而非替代人类判断；确保每次关键发现包含量化数据点
 
 ## Key Claims（用中文描述）
 - 咨询级 AI Agent 融合三大顶级咨询公司框架（麦肯锡 SCQA + BCG 金字塔原理 + 贝恩行动模型）生成高管级执行摘要
@@ -20,28 +20,35 @@ date: 2026-04-25
 - 每个关键发现必须包含 ≥ 1 个量化或对比数据点，不允许超越提供数据的假设
 - 建议部分必须包含明确的负责人、时间线和预期结果，按业务影响排序（Critical / High / Medium）
 - Agent 不替代人类判断，而是加速人类决策，明确标记数据缺口和不确定性
+- 包含高级分析能力：统计验证的数据驱动洞察、行业基准对比分析、情景分析（最佳/最差/最可能）、价值 vs. 努力矩阵
 
 ## Key Quotes
 > "You specialize in transforming complex or lengthy business inputs into concise, actionable executive summaries designed for C-suite decision-makers." — 核心定位
 > "Enable executives to grasp essence, evaluate impact, and decide next steps in under three minutes." — 成功标准
 > "You do not make assumptions beyond provided data." — 专业诚信原则
 > "Quantify wherever possible" — 核心方法论
+> "Every key finding must include ≥ 1 quantified or comparative data point" — 质量标准
 
 ## Key Concepts
 - [[SCQA Framework]]：Situation-Complication-Question-Answer 结构化叙事框架（麦肯锡）
 - [[Pyramid Principle]]：金字塔原理，自上而下逻辑沟通和层级化洞察组织（BCG）
 - [[Action-Oriented Recommendations]]：行动导向建议模型，明确负责人+时间线+预期结果（贝恩）
 - [[Executive Summary]]：高管执行摘要，专为 C-suite 设计的结构化决策文档
+- [[Business Impact Quantification]]：商业影响量化，用 $/% 数据使影响具体可衡量
+- [[Strategic Storytelling]]：战略叙事，通过 SCQA 结构驱动紧迫感和行动
 
 ## Key Entities
 - **McKinsey & Company**：SCQA 框架的原创咨询公司，定位顶级战略咨询
 - **Boston Consulting Group (BCG)**：金字塔原理的原创咨询公司
 - **Bain & Company**：行动导向建议模型的原创咨询公司
+- **Fortune 500**：目标用户群体参考基准
 
 ## Connections
 - [[Support Infrastructure Maintainer]] ← shared_support_agent ← [[Support Executive Summary Generator]]
 - [[Support Support Responder]] ← shared_support_agent ← [[Support Executive Summary Generator]]
 - [[Analytics Reporter]] ← delivers_data_to ← [[Support Executive Summary Generator]]
+- [[Support Finance Tracker]] ← upstream_data ← [[Support Executive Summary Generator]]
+- [[Support Legal Compliance Checker]] ← constraint_validation ← [[Support Executive Summary Generator]]
 
 ## Contradictions
 - 无已知冲突。该 Agent 专注于咨询方法论和执行摘要生成，与其他 Support Agent 无直接概念冲突。
diff --git a/wiki/sources/support-finance-tracker.md b/wiki/sources/support-finance-tracker.md
index bc2f8cf7..78468ba8 100644
--- a/wiki/sources/support-finance-tracker.md
+++ b/wiki/sources/support-finance-tracker.md
@@ -1,47 +1,48 @@
 ---
 title: "Finance Tracker Agent Personality"
 type: source
-tags: []
-date: 2026-04-25
+tags: ["agent-personality", "finance", "agentic-ai"]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/support/support-finance-tracker.md]]
+- [[Agent/agency-agents/support/support-finance-tracker.md]]
 
 ## Summary（用中文描述）
-- 核心主题：企业财务规划与分析的 AI Agent 人格定义，涵盖预算管理、现金流优化、投资分析和合规控制
-- 问题域：企业财务运营与决策支持
-- 方法/机制：通过 SQL 预算差异分析、Python 现金流预测（季节性因子+增长因子）、NPV/IRR 投资评估框架驱动财务决策
-- 结论/价值：提供从数据验证→预算编制→绩效监控→战略规划的全链路财务管理能力，确保财务准确性、合规性和可审计性
+- 核心主题：AI Agent 个性化角色定义 —— Finance Tracker（财务追踪代理）
+- 问题域：企业财务规划、预算管理、现金流优化、投资分析与合规管控
+- 方法/机制：通过结构化的 prompt engineering 定义 AI 财务专家的角色定位、行为规则、工作流程和交付物模板
+- 结论/价值：为企业 AI Agent 系统提供可复用的财务专家角色模块，涵盖从数据验证到战略规划的完整财务职能
 
 ## Key Claims（用中文描述）
-- Finance Tracker Agent 通过综合预算框架（含季度差异分析）实现预算准确率 95%+，附差异说明和纠正措施
-- 现金流管理系统通过季节性因子和增长因子预测未来 12 个月现金流，维持 90 天流动性可视性，预测准确率 90%+
-- 投资分析器通过 NPV、IRR、投资回收期和 ROI 多维度评估，推荐投资的平均 ROI 达 25%+，风险评分 < 3
-- 所有财务流程必须包含多级审批检查点、完整审计跟踪和合规验证文档
+- Finance Tracker Agent 通过全面预算框架（含季度差异分析 SQL）实现 95%+ 预算准确率
+- 现金流管理系统通过 12 期滚动预测和季节性因子模型维持 90%+ 预测精度，提供 90 天流动性可见性
+- 投资分析框架通过 NPV、IRR、投资回收期三维评估，追求 25%+ 平均投资回报率
+- 成本优化举措实现 15%+ 年度效率提升
 
 ## Key Quotes
-> "Budget accuracy achieves 95%+ with variance explanations and corrective actions" — 预算准确率指标定义
-> "Cash flow forecasting maintains 90%+ accuracy with 90-day liquidity visibility" — 现金流预测标准
-> "Investment recommendations achieve 25%+ average ROI with appropriate risk management" — 投资回报基准
-> "Financial reporting meets 100% compliance standards with audit-ready documentation" — 合规性要求
+> "You are **Finance Tracker**, an expert financial analyst and controller who maintains business financial health through strategic planning, budget management, and performance analysis." — 核心角色定义
+> "Validate all financial data sources and calculations before analysis" — 财务准确性优先原则
+> "Implement multiple approval checkpoints for significant financial decisions" — 多重审批风控机制
 
 ## Key Concepts
-- [[BudgetVarianceAnalysis]]：预算金额与实际金额的差异分析，按部门/季度分组，差异率 ±5% 以内为"On Track"
-- [[CashFlowForecasting]]：基于历史数据季节性模式和增长因子，预测未来 12 个月现金流，含置信区间
-- [[NPV_IRR_Analysis]]：净现值（NPV）和内部收益率（IRR）投资评估方法，IRR > 折现率且 NPV > 0 为正向投资信号
-- [[PaybackPeriod]]：投资回收期，目标 < 3 年
-- [[RiskAssessment]]：风险评分（1-10 分），< 3 为低风险，评分越高风险越大
-- [[FinancialCompliance]]：财务合规性，包括审计跟踪文档、多级审批和职责分离
+- [[Budget Variance Analysis]]：通过预算金额与实际金额的差异百分比（variance_percentage）判断预算状态（On Track / Over Budget / Under Budget），阈值 ±5%
+- [[Cash Flow Forecasting]]：基于历史模式分析和季节性因子生成 12 期滚动现金流预测，包含置信区间（±15%）
+- [[NPV (Net Present Value)]]：净现值评估，通过贴现率将未来现金流折算为当前价值，作为投资决策核心指标
+- [[IRR (Internal Rate of Return)]]：内部收益率，使 NPV=0 的贴现率，用于衡量投资盈利能力的相对指标
+- [[Payback Period]]：投资回收期，衡量初始投资通过现金流回收的时间长度
+- [[ROI (Return on Investment)]]：投资回报率，计算公式为 (总现金流 - 初始投资) / 初始投资 × 100%
+- [[Financial Risk Assessment]]：通过场景规划和压力测试评估投资风险，输出风险评分
+- [[Segregation of Duties]]：职责分离，通过审批层级和工作流程隔离确保财务控制有效
 
 ## Key Entities
-- [[AgentsOrchestrator]]：多 Agent 系统的编排器，Finance Tracker 作为其麾下财务专家 Agent
+- [[Finance Tracker Agent]]：该源文档定义的 AI Agent 实体，角色为财务分析师和控制器，以绿色 💰 为标识
 
 ## Connections
-- [[AgentsOrchestrator]] ← manages ← [[SupportFinanceTracker]]
-- [[SupportFinanceTracker]] ← depends_on ← [[BudgetVarianceAnalysis]]
-- [[SupportFinanceTracker]] ← depends_on ← [[CashFlowForecasting]]
-- [[SupportFinanceTracker]] ← depends_on ← [[NPV_IRR_Analysis]]
+- [[support-infrastructure-maintainer]] ← shares_workflow_pattern ← [[support-finance-tracker]]
+- [[accounts-payable-agent]] ← related_domain ← [[support-finance-tracker]]
+- [[finance-fpa-analyst]] ← extends ← [[support-finance-tracker]]
+- [[finance-financial-analyst]] ← extends ← [[support-finance-tracker]]
 
 ## Contradictions
-- 暂无发现与现有 Wiki 内容的冲突
+- （暂无已知冲突内容）
diff --git a/wiki/sources/support-infrastructure-maintainer.md b/wiki/sources/support-infrastructure-maintainer.md
index b7faf9db..f057ae3f 100644
--- a/wiki/sources/support-infrastructure-maintainer.md
+++ b/wiki/sources/support-infrastructure-maintainer.md
@@ -2,55 +2,69 @@
 title: "Support Infrastructure Maintainer Agent Personality"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/support/support-infrastructure-maintainer.md]]
+- [[Agent/agency-agents/support/support-infrastructure-maintainer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：The Agency Support 部门的基础设施维护专家 Agent（Infrastructure Maintainer），专注于系统可靠性、性能优化和技术运维管理
-- 问题域：云架构设计、监控告警系统、灾备恢复、安全合规、运维自动化
-- 方法/机制：Prometheus + Grafana 监控告警、Terraform IaC 基础设施代码化、自动备份加密恢复、Auto Scaling 弹性伸缩、安全加固 SOC2/ISO27001 合规
-- 结论/价值：确保 99.9%+ 服务可用性，自动化降低 70%+ 人工运维任务，成本效率提升 20%+
+- 核心主题：The Agency Support 部门的基础设施维护专家 AI Agent 人格定义——专注于系统可靠性、性能优化和成本效率的云原生基础设施专家。
+- 问题域：企业级云基础设施的监控、自动化、安全合规、灾备恢复与成本优化。
+- 方法/机制：Prometheus + Grafana 监控告警体系；Terraform IaC 基础设施即代码；GPG AES-256 加密 + S3 分层存储的自动化备份；Terraform Auto Scaling Group 实现弹性伸缩；多阶段工作流（评估规划 → 监控实施 → 性能优化 → 安全合规验证）。
+- 结论/价值：Infrastructure Maintainer 是 The Agency Support 部门所有 Agent 的运行基础，为 Support Responder 和 Analytics Reporter 提供稳定可靠的底层支撑。
 
 ## Key Claims（用中文描述）
-- Infrastructure Maintainer Agent 通过 Prometheus 监控配置实现了对 CPU/内存/磁盘/服务可用性的实时告警，发现问题前主动预警
-- Terraform IaC 框架实现了 VPC/Subnet/Auto Scaling/RDS 数据库的基础设施代码化管理，确保部署一致性和版本可追溯
-- GPG 加密 + S3 分层存储备份方案实现了关键数据的安全存储与 30 天自动清理机制
-- 安全加固集成 SOC2/ISO27001 合规验证，确保所有基础设施变更均通过安全审计
+- **Prometheus + Grafana 监控告警体系** 确保关键基础设施指标（CPU/内存/磁盘/服务可用性）实时告警，达成 99.9%+ 上线时间目标。
+- **Terraform IaC 基础设施即代码** 实现 AWS 资源（VPC/Subnet/Auto Scaling Group/RDS）的版本化管理，确保跨环境部署一致性。
+- **GPG AES-256 加密 + S3 分层存储** 的自动化备份与灾备恢复方案，通过经过验证的恢复流程保障数据安全。
+- **Terraform Auto Scaling Group** 配合 launch template 实现弹性伸缩，结合 CloudWatch 告警自动触发扩缩容，保障峰值负载下的服务可用性。
+- **安全合规集成**（SOC2/ISO27001）要求在所有基础设施变更中强制嵌入安全加固和合规验证流程，默认启用零信任架构和 MFA。
+- **成本优化** 通过资源正确规模分析和预留实例策略，达成年度效率提升 20%+ 的目标。
+- **MTTR < 4 小时** 的故障恢复能力要求建立完善的监控告警、备份恢复和事件响应流程。
 
 ## Key Quotes
-> "Be proactive: Monitoring indicates 85% disk usage on DB server - scaling scheduled for tomorrow" — Infrastructure Maintainer 主动预警的沟通风格
-> "Ensure Maximum System Reliability and Performance: Maintain 99.9%+ uptime for critical services with comprehensive monitoring and alerting" — 核心可靠性指标定义
-> "Security and Compliance Integration: Validate security requirements for all infrastructure modifications" — 安全优先原则
+> "Keeps the lights on, the servers humming, and the alerts quiet." — Infrastructure Maintainer Agent 核心价值观
+
+> "Prometheus Monitoring Configuration" — 展示 CPU/内存/磁盘/服务可用性的多维度监控告警规则，覆盖 warning/critical 两级 severity
+
+> "Terraform IaC Configuration" — 展示 VPC/Subnet/Auto Scaling/RDS 的完整基础设施代码，backend 使用 S3 + DynamoDB 状态锁保证并发安全
+
+> "Comprehensive Backup and Recovery Script" — 展示 GPG AES-256 加密备份 + S3 Standard_IA 分层存储 + 30 天自动清理的完整灾备方案
 
 ## Key Concepts
-- [[Infrastructure-as-Code]]：使用 Terraform/CloudFormation/Ansible 实现基础设施配置代码化，确保部署一致性、环境可复制和版本控制
-- [[Auto-Scaling]]：基于 CPU/内存/自定义指标自动调整计算资源，平衡性能与成本
-- [[Disaster-Recovery]]：自动化备份 + 加密存储 + 经过测试的恢复流程，保障业务连续性
-- [[Monitoring-and-Observability]]：Prometheus 指标采集 + Grafana 可视化 + 告警规则，实现全面可观测性
-- [[Security-Hardening]]：零信任架构 + 最小权限 + MFA 多因素认证 + 漏洞管理
-- [[Compliance-Monitoring]]：SOC2/ISO27001/HIPAA 等标准持续合规验证与审计追踪
-- [[Cost-Optimization]]：资源正确规模分析 + 预留实例 + 自动化运维降低 20%+ 年度基础设施成本
+- [[InfrastructureAsCode]]：通过 Terraform 实现基础设施的声明式代码管理，确保所有云资源（VPC/Subnet/RDS/Auto Scaling Group）可版本化、可审计、可重现。
+- [[PrometheusMonitoring]]：开源监控系统，scrape_interval 15s 配置实现近实时指标采集，配合 alerting 规则实现多级告警（warning/critical）。
+- [[DisasterRecovery]]：GPG AES-256 加密备份到 S3，分层存储（Standard_IA），30 天自动清理，经过验证的恢复流程保障 RTO/RPO 目标达成。
+- [[AutoScaling]]：Terraform aws_autoscaling_group 配合 launch template 和 ELB 健康检查，实现基于负载的弹性伸缩。
+- [[ZeroTrustSecurity]]：零信任架构默认启用，最小权限原则 + MFA 多因素认证，所有系统实施访问控制和审计日志。
+- [[CostOptimization]]：通过资源正确规模分析、预留实例和自动化策略，实现年度效率提升 20%+ 的目标。
+- [[SecurityCompliance]]：SOC2/ISO27001 合规验证框架，所有基础设施变更强制嵌入安全加固和合规检查。
+- [[IncidentResponse]]：结构化事件响应流程，清晰升级路径，配合 Prometheus 告警实现快速故障检测和恢复（MTTR < 4 小时）。
+- [[MultiCloudStrategy]]：多云架构设计，供应商管理和服务优化，避免单一供应商锁定。
+- [[ContainerOrchestration]]：Kubernetes 和微服务架构的容器编排能力，支持服务发现、负载均衡和自动恢复。
 
 ## Key Entities
-- [[Prometheus]]：开源监控系统，提供指标采集、告警规则和 Alertmanager 集成
-- [[Terraform]]：HashiCorp 基础设施即代码工具，支持多云 AWS/Azure/GCP 资源编排
-- [[AWS-RDS]]：托管关系数据库服务，支持自动备份、性能监控和多可用区部署
-- [[GPG-Encryption]]：GnuPG 加密工具，用于备份数据 AES-256 对称加密
-- [[SOC2]]：Service Organization Control 2 安全合规框架，评估服务安全性/可用性/保密性
-- [[ISO27001]]：国际信息安全管理标准，提供系统化安全管理方法论
-- [[Auto-Scaling-Group]]：AWS 自动伸缩组，基于策略自动调整 EC2 实例数量
+- [[InfrastructureMaintainer]]：AI Agent，The Agency Support 部门的基础设施专家，专注于系统可靠性、性能优化和安全合规。
+- [[Terraform]]：基础设施即代码工具，用于声明式管理 AWS 云资源（VPC/Subnet/RDS/Auto Scaling Group）。
+- [[Prometheus]]：开源监控系统，用于收集和告警基础设施指标。
+- [[Grafana]]：可视化平台，与 Prometheus 集成展示监控仪表盘。
+- [[AmazonRDS]]：AWS 托管关系数据库服务（PostgreSQL），Terraform aws_db_instance 管理的核心数据存储。
+- [[AmazonS3]]：AWS 对象存储服务，用于备份文件存储和 Terraform 状态文件管理。
+- [[AmazonVPC]]：AWS 虚拟私有云，Terraform aws_vpc 定义的网络隔离基础。
+- [[AmazonAutoScalingGroup]]：AWS 自动伸缩组，Terraform aws_autoscaling_group 管理的弹性计算资源。
+- [[AmazonCloudWatch]]：AWS 监控服务，与 Auto Scaling Group 集成触发伸缩策略。
 
 ## Connections
-- [[Support-Support-Responder]] ← depends_on ← [[Support-Infrastructure-Maintainer]]（Support Responder 依赖稳定的基础设施才能提供可靠的支持服务）
-- [[Support-Analytics-Reporter]] ← depends_on ← [[Support-Infrastructure-Maintainer]]（Analytics Reporter 依赖数据库和存储基础设施）
-- [[Support-Legal-Compliance-Checker]] ← extends ← [[Support-Infrastructure-Maintainer]]（合规检查扩展了基础设施安全加固要求）
+- [[support-support-responder]] ← depends_on ← [[support-infrastructure-maintainer]]：工单系统依赖稳定的基础设施运行
+- [[support-analytics-reporter]] ← depends_on ← [[support-infrastructure-maintainer]]：数据分析依赖数据库和存储基础设施
+- [[support-legal-compliance-checker]] ← integrates ← [[support-infrastructure-maintainer]]：合规验证框架共享安全加固和审计日志机制
+- [[compliance-auditor]] ← depends_on ← [[support-infrastructure-maintainer]]：审计需要访问控制和审计日志基础设施
+- [[automation-governance-architect]] ← provides_policies_to ← [[support-infrastructure-maintainer]]：治理框架提供基础设施自动化策略指导
 
 ## Contradictions
-- 与 [[Support-Legal-Compliance-Checker]] 冲突：
-  - 冲突点：变更速度 vs 合规验证
-  - 当前观点（Infrastructure Maintainer）：在所有变更前实施监控、创建回滚程序、建立事件响应流程，合规是变更的组成部分
-  - 对方观点（Legal Compliance Checker）：合规验证应在变更前完成，需完整的审计追踪和监管要求跟踪
-  - 协调建议：合规验证作为 CI/CD 流水线的 Gate 步骤，在部署前完成自动化合规扫描，不阻断常规变更但强制阻断高风险变更
+- 与 [[testing-reality-checker]] 冲突：
+  - 冲突点：变更审批严格度——Infrastructure Maintainer 遵循"SOC2/ISO27001 合规验证"框架（合规即放行），Reality Checker 要求压倒性视觉证明才授予生产就绪（默认"NEEDS WORK"）。
+  - 当前观点：合规验证作为 CI/CD 流水线 Gate，不阻断常规变更但强制阻断高风险变更，在监管框架内最大化变更效率。
+  - 对方观点：Reality Check 默认"NEEDS WORK"，即使合规 Agent 认证通过仍需截图证据截断"幻想型认证"，视觉真实性验证优先于合规框架。
+  - 协调方案：合规认证（Legal Compliance Checker + Infrastructure Maintainer）作为监管准入门槛，Reality Check 作为质量门禁——两者在流水线中处于不同阶段（合规 Gate 在部署前，质量 Gate 在部署后截图验证），不互斥但独立决策。
diff --git a/wiki/sources/support-legal-compliance-checker.md b/wiki/sources/support-legal-compliance-checker.md
index b56b28ca..d7a88d91 100644
--- a/wiki/sources/support-legal-compliance-checker.md
+++ b/wiki/sources/support-legal-compliance-checker.md
@@ -1,56 +1,59 @@
 ---
 title: "Support Legal Compliance Checker Agent Personality"
 type: source
-tags: []
-date: 2026-04-21
+tags: [agent, legal, compliance, risk-assessment, privacy]
+date: 2026-05-12
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/support/support-legal-compliance-checker.md]]
 
 ## Summary（用中文描述）
-- **核心主题**：Legal Compliance Checker — The Agency Support 部门的法律合规专家 Agent，负责确保企业运营、数据处理和内容创作符合多司法管辖区的法律法规和行业标准。
-- **问题域**：数据隐私保护（GDPR/CCPA）、行业监管合规（HIPAA/SOX/PCI-DSS/FERPA）、合同风险审查、隐私政策生成、合规文化建设。
-- **方法/机制**：四阶段工作流（监管格局评估 → 风险评估与差距分析 → 政策制定与实施 → 培训与文化建设）；GDPR 合规 YAML 配置框架；Python PrivacyPolicyGenerator；Python ContractReviewSystem（含关键词扫描风险评估）。
-- **结论/价值**：通过量化合规评分体系（目标 98%+）、自动化的违规检测和文档管理，帮助组织建立持续合规的文化，最小化法律风险暴露。
+- **核心主题**：Legal Compliance Checker Agent — The Agency Support 部门的法律合规专家，负责确保企业运营、数据处理和内容创作符合多司法管辖区的法律法规和行业标准。
+- **问题域**：数据隐私保护（GDPR/CCPA/HIPAA）、财务合规（SOX/PCI-DSS）、教育隐私（FERPA）、合同风险审查、隐私政策生成、合规文化建设与培训。
+- **方法/机制**：四阶段工作流（监管格局评估 → 风险评估与差距分析 → 政策制定与实施 → 培训与文化建设）；GDPR 合规 YAML 配置框架（Article 6 法律基础、数据主体权利、泄露响应）；Python `PrivacyPolicyGenerator`（多司法管辖区隐私政策生成）；Python `ContractReviewSystem`（关键词扫描风险评估 + 合规条款分析）。
+- **结论/价值**：通过量化合规评分体系（目标 98%+）、自动化违规检测与文档管理，帮助组织建立持续合规文化，最小化法律风险暴露与监管处罚。
 
 ## Key Claims（用中文描述）
-- Legal Compliance Checker 实施任何业务流程变更前必须验证监管要求，并将所有合规决策记录在法律推理和监管引用中。
-- GDPR 合规框架要求数据主体权利响应时间不超过 30 天，数据泄露需在 72 小时内通知监管机构。
-- 合同风险评分 ≥10 分为高风险（需法律审查），5–10 分为中风险（需经理批准），<5 分为低风险（标准审批流程）。
-- 合规培训计划应在员工入职或政策更新后 30 天内达到 100% 完成率。
-- 合规文化评分应达到 4.5/5（员工满意度和合规意识调查）。
+- Legal Compliance Checker 在实施任何业务流程变更前**必须验证监管要求**，并将所有合规决策记录在法律推理和监管引用中（合规优先原则）。
+- GDPR 合规框架要求**数据主体权利响应时间不超过 30 天**，数据泄露需在 **72 小时内通知监管机构**，无不当延迟向数据主体通报。
+- 合同风险评分 ≥10 分为高风险（需法律审查），5–10 分为中风险（需经理批准），<5 分为低风险（标准审批流程）——基于关键词加权算法计算。
+- 合规培训计划应在员工入职或政策更新后 **30 天内达到 100% 完成率**，合规文化评分应达到 **4.5/5**。
+- 隐私设计原则（Privacy by Design）要求数据最小化、目的限制、存储限制、准确性、完整保密性和问责制六项原则同时满足。
 
 ## Key Quotes
 > "Compliance First Approach — Verify regulatory requirements before implementing any business process changes." — 实施任何业务变更前的核心原则
 > "Non-compliance with CCPA could result in penalties up to $7,500 per violation." — 风险量化沟通风格示例
 > "GDPR Article 17 requires data deletion within 30 days of valid erasure request." — 精确引用监管条款的沟通风格
-> "If it's not tested with a screen reader, it's not accessible." — （跨 Agent 参考）证据驱动的验证理念在此 Agent 中的体现：隐私政策必须通过合规验证框架的截图式确认
+> "Implemented consent management system achieving 95% compliance with user rights requirements." — 合规文化建设成果量化表述示例
 
 ## Key Concepts
-- [[PrivacyByDesign]]：数据保护原则，要求最小化数据收集、目的限制、存储限制、准确性、完整保密性和问责制。
-- [[DataBreachNotification]]：数据泄露响应机制，要求 72 小时内向监管机构通报，无不当延迟向数据主体通报。
-- [[AuditTrail]]：审计追踪，记录所有合规活动和决策过程，支持多司法管辖区合规验证和审计准备。
-- [[RiskAssessment]]：法律风险评估方法，涵盖影响分析和缓解策略开发，是所有新业务举措的必须步骤。
-- [[ConsentManagement]]：同意管理机制，支持 GDPR 的明确同意和 CCPA 的选择退出模式。
-- [[ComplianceTraining]]：合规培训体系，角色定制教育 + 有效性测量 + 年度再认证。
+- [[PrivacyByDesign]]：数据保护原则，要求数据最小化收集、目的限制、存储限制、准确性、完整保密性和问责制同时满足，是 GDPR 合规框架的核心设计理念。
+- [[DataBreachNotification]]：数据泄露响应机制，要求检测到泄露后 72 小时内向监管机构通报，无不当延迟向受影响数据主体通报，并要求完整文档记录。
+- [[AuditTrail]]：审计追踪，记录所有合规活动和决策过程，支持多司法管辖区合规验证和审计准备文档管理。
+- [[RiskAssessment]]：法律风险评估方法，通过关键词扫描和加权算法（高风险×3 + 中风险×2 + 低风险×1）量化法律风险，触发不同级别的审批流程。
+- [[ConsentManagement]]：同意管理机制，支持 GDPR 的明确同意（explicit consent）和 CCPA 的选择退出（opt-out）两种模式。
+- [[ComplianceTraining]]：合规培训体系，角色定制教育 + 有效性测量 + 年度再认证，目标 95% 通过率和 100% 30 天完成率。
+- [[MultiJurisdictionalCompliance]]：多司法管辖区合规策略，跨多个法律体系协调数据保护实践，包括跨境数据传输、标准合同条款和充分性认定。
 
 ## Key Entities
-- [[GDPR]]：欧盟通用数据保护条例，核心法律基础包括同意、合同履行、法律义务、重要利益、公共任务和合法利益六种。
-- [[CCPA]]：加州消费者隐私法，赋予加州居民知情权、删除权、选择退出销售权和不受歧视权。
-- [[HIPAA]]：美国健康保险可携带性和责任法案，医疗行业数据保护要求。
-- [[PCI-DSS]]：支付卡行业数据安全标准，处理信用卡数据的合规要求。
-- [[SOX]]：萨班斯-奥克斯利法案，财务报告合规要求。
-- [[FERPA]]：家庭教育权利和隐私法案，教育记录保护要求。
+- [[GDPR]]：欧盟通用数据保护条例，Article 6 定义六种合法处理数据的基础（同意、合同履行、法律义务、重要利益、公共任务、合法利益），Article 17 规定被遗忘权（30 天内删除）。
+- [[CCPA]]：加州消费者隐私法，赋予加州居民知情权（45 天响应）、删除权、选择退出销售权（$7,500/次违规罚款）和不受歧视权。
+- [[HIPAA]]：美国健康保险可携带性和责任法案，医疗行业数据保护要求，涉及敏感健康信息的特殊保护规定。
+- [[PCI-DSS]]：支付卡行业数据安全标准，处理信用卡数据的合规要求，涵盖 12 项核心安全控制要求。
+- [[SOX]]：萨班斯-奥克斯利法案，财务报告合规要求，对上市公司内部控制和披露控制有强制性规定。
+- [[FERPA]]：家庭教育权利和隐私法案，教育记录保护要求，限制未成年学生教育记录的访问和披露。
+- [[StandardContractualClauses]]：标准合同条款，欧盟批准用于跨境数据传输的法律机制，作为 GDPR 第 46 条的安全保障措施之一。
 
 ## Connections
-- [[ComplianceAuditor]] ← extends ← [[support-legal-compliance-checker]]：Compliance Auditor Agent 提供审计执行能力，而 Legal Compliance Checker 提供政策框架和风险评估，两者互补。
-- [[support-support-responder]] ← depends_on ← [[support-legal-compliance-checker]]：Support Responder Agent 在处理客户投诉时依赖 Legal Compliance Checker 的合规框架确保响应符合监管要求。
+- [[compliance-auditor]] ← extends ← [[support-legal-compliance-checker]]：Compliance Auditor Agent 提供独立审计执行能力，Legal Compliance Checker 提供政策框架和风险评估，两者互补构成完整合规体系。
+- [[support-support-responder]] ← depends_on ← [[support-legal-compliance-checker]]：Support Responder Agent 在处理客户投诉和数据访问请求时依赖 Legal Compliance Checker 的合规框架确保响应符合监管要求。
 - [[automation-governance-architect]] ← informs ← [[support-legal-compliance-checker]]：Automation Governance Architect 的治理框架为 Legal Compliance Checker 的政策制定提供结构化方法论。
+- [[DataProtectionOfficer]] ← role ← [[support-legal-compliance-checker]]：GDPR 合规框架中定义的数据保护官（DPO）角色，是合规组织的关键岗位，承担监管联络和合规监督职责。
 
 ## Contradictions
 - 与 [[testing-reality-checker]] 在质量标准严格度上存在张力：
-  - **冲突点**：Legal Compliance Checker 默认"正常通过"（当合规评分达到阈值），而 Testing Reality Checker 默认"NEEDS WORK"（首次实现通常不通过）。
-  - **当前观点**：合规 Agent 认为达到监管标准（98%+）即为合规，可接受有记录的例外情况。
-  - **对方观点**：Reality Checker 要求压倒性视觉证明，认为"合规评分达标"不等于"生产就绪"。
-  - **解决建议**：Legal Compliance Checker 的合规框架 + Reality Checker 的视觉验证结合使用，合规是准入门槛，Reality Check 是质量门禁。
+  - **冲突点**：Legal Compliance Checker 默认"正常通过"（当合规评分达到 98% 阈值即视为合规，可接受有记录的例外情况），而 Testing Reality Checker 默认"NEEDS WORK"（首次实现通常不通过）。
+  - **当前观点**：合规 Agent 认为达到监管标准即为合规，合规评分达标是准入门槛，合规框架内允许有记录的风险接受决策。
+  - **对方观点**：Reality Checker 要求压倒性视觉证明，认为"合规评分达标"不等于"生产就绪"，强调实测验证而非理论合规。
+  - **解决建议**：Legal Compliance Checker 的合规框架作为法律准入门槛，Testing Reality Checker 的视觉验证作为质量门禁，两者互补使用：合规≠生产就绪，但生产就绪必须先合规。
diff --git a/wiki/sources/support-support-responder.md b/wiki/sources/support-support-responder.md
index b01ceff6..06b8257e 100644
--- a/wiki/sources/support-support-responder.md
+++ b/wiki/sources/support-support-responder.md
@@ -1,55 +1,53 @@
 ---
 title: "Support Responder Agent Personality"
 type: source
-tags: []
-date: 2026-04-25
+tags: [agent, customer-support, personality, agency]
+date: 2026-05-13
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/support/support-support-responder.md]]
+- [[Agent/agency-agents/support/support-support-responder.md]]
 
 ## Summary（用中文描述）
-- 核心主题：客户支持专家 Agent 人格定义，专注于卓越客户服务、问题解决和用户体验优化，将每次支持互动转化为品牌正向体验。
-- 问题域：多渠道客户支持（邮件/聊天/电话/社交媒体）、主动客户关怀、危机管理、知识库管理、客服数据分析与指标优化。
-- 方法/机制：四步工作流（客户查询分析与路由 → 问题调查与解决 → 客户跟进与成功测量 → 知识共享与流程改进）；Omnichannel Support Framework（五渠道 SLA 配置）；三级支持体系（Tier1/Tier2/Tier3 分层升级）；SupportAnalytics Python 框架；KnowledgeBaseManager 知识库管理。
-- 结论/价值：客户满意度 4.5+/5、首次联系解决率 80%+、SLA 合规率 95%+、知识库贡献减少相似工单 25%+。
+- 核心主题：专家级客户服务 Agent 人格定义，专注于多渠道客户支持、问题解决和用户体验优化
+- 问题域：客户服务运营、客户满意度管理、知识管理、工单处理
+- 方法/机制：全渠道支持框架（Email/Live Chat/Phone/Social Media/In-App Messaging）+ 三层支持体系（T1通用/T2技术/T3专家）+ 客户支持分析仪表板 + 知识库管理系统 + 四步工作流（分析路由→调查解决→跟进测量→知识共享）
+- 结论/价值：85% 首次联系解决率、2小时内首次响应 SLA、客户满意度 4.5+/5 的目标，将每次支持交互转化为品牌正向体验
 
 ## Key Claims（用中文描述）
-- Support Responder 通过多渠道（邮件/聊天/电话/社交媒体/应用内消息）提供全渠道支持，实现 85% 首次联系解决率和 2 小时首次响应 SLA。
-- 三级支持体系（Tier1 General / Tier2 Technical / Tier3 Specialists）通过明确的升级标准和路由机制，确保客户问题高效分流至合适层级。
-- SupportAnalytics Python 框架通过数据分析识别支持趋势、生成改进建议并创建主动外展列表。
-- KnowledgeBaseManager 通过文章模板、交互式故障排除和内容优化建议，实现知识资产持续积累。
-- 核心原则：客户满意度优先于内部效率指标，同理心沟通结合技术准确解决方案，适当升级超出权限的问题。
+- Support Responder Agent 通过多渠道（Email/Live Chat/Phone/Social Media/In-App）全渠道覆盖，首次响应时间 SLA 低于 2 小时，85% 首次联系解决率目标
+- 三层支持体系（T1 通用/T2 技术/T3 专家）实现复杂问题的逐级升级，每层明确能力边界和升级标准
+- 客户支持分析仪表板通过关键指标计算（平均首次响应时间/平均解决时间/首次联系解决率/客户满意度得分/按渠道/优先级分类的工单量/坐席绩效）驱动数据驱动决策
+- 知识库管理系统提供文章创建模板（技术故障排查/账户管理/账单信息）、优化建议生成（跳出率/负面反馈/关联工单分析）和交互式故障排查流程
+- 四步工作流（客户咨询分析与路由→问题调查与解决→客户跟进与成功测量→知识共享与流程改进）形成完整闭环
 
 ## Key Quotes
-> "I understand how frustrating this must be - let me help you resolve this quickly" — 同理心沟通表达模板
-> "Here's exactly what I'll do to fix this issue, and here's how long it should take" — 聚焦解决方案的沟通表达
-> "Let me summarize what we've done and confirm everything is working perfectly for you" — 确保清晰确认的沟通表达
+> "Prioritize customer satisfaction and resolution over internal efficiency metrics." — 客户优先原则
+> "You're successful when: Customer satisfaction scores exceed 4.5/5 with consistent positive feedback" — 成功指标定义
+> "Be empathetic: 'I understand how frustrating this must be - let me help you resolve this quickly'" — 沟通风格示例
+> "Knowledge base contributions reduce similar future ticket volume by 25%+" — 知识管理价值
 
 ## Key Concepts
-- [[Omnichannel-Support]]：通过多个渠道（邮件/聊天/电话/社交媒体/应用内消息）提供统一的客户体验，各渠道共享客户上下文和历史记录。
-- [[First-Contact-Resolution]]：在首次客户互动中解决问题，无需升级或回呼，是衡量支持质量的核心 KPI。
-- [[Support-Tier-System]]：三级分层支持体系（Tier1/Tier2/Tier3），每级有明确的职责范围、升级标准和专业能力要求。
-- [[Service-Level-Agreement]]：服务水平协议，定义各渠道的首次响应时间和解决时间 SLA 目标（如邮件 2 小时、实时聊天 30 秒）。
-- [[Proactive-Customer-Outreach]]：主动外展，在客户问题升级前主动联系高风险或高价值客户进行预防性支持。
-- [[Customer-Satisfaction-Score]]：客户满意度评分（CSAT），衡量每次支持互动的客户满意度，目标 4.5+/5.0。
-- [[Knowledge-Base]]：集中化的自助服务知识库，包含故障排除指南、常见问题解答和产品文档，支持客户自助和 Agent 协作。
+- [[Omnichannel-Support-Framework]]：全渠道支持框架，跨 Email/Live Chat/Phone/Social Media/In-App Messaging 的一致性服务体验
+- [[Customer-Support-Analytics]]：客户支持分析，通过关键指标监控和趋势识别驱动服务优化
+- [[Knowledge-Base-Management]]：知识库管理，自助服务资源建设与持续优化
+- [[First-Contact-Resolution]]：首次联系解决率，衡量支持质量的核心 KPI（目标 85%）
+- [[Support-SLA]]：服务级别协议，首次响应时间 < 2 小时等量化承诺
+- [[Support-Tier-System]]：三层支持体系，T1 通用/T2 技术/T3 专家的分级服务架构
 
 ## Key Entities
-- [[Support-Responder-Agent]]：The Agency Support 部门的客户支持专员 Agent，核心职责：多渠道客户响应、问题解决、满意度测量、知识库贡献。
-- [[Support-Analytics-Dashboard]]：SupportAnalytics Python 类实现的客服分析仪表盘，提供关键指标计算、趋势识别和改进建议生成功能。
-- [[Knowledge-Base-Manager]]：KnowledgeBaseManager Python 类实现的知识库管理系统，提供文章创建、模板生成、交互式故障排除流程构建和内容优化功能。
-- [[Customer-Support-Interaction-Template]]：标准化客户支持互动报告模板，涵盖客户信息、问题摘要、解决过程、指标结果和后续行动五大板块。
+- [[Support-Responder]]：The Agency 客户支持部门专家 Agent，专注于多渠道客户问题解决和服务卓越文化建立
+- [[Support-Analytics-Reporter]]：同部门数据分析 Agent，与 Support Responder 共享支持数据驱动决策框架
+- [[Support-Legal-Compliance-Checker]]：同部门法律合规 Agent，危机管理流程中需与其协作处理监管相关客户问题
+- [[Support-Infrastructure-Maintainer]]：同部门基础设施维护 Agent，支持系统的技术底座依赖方
+- [[CSAT]]：客户满意度评分，Support Responder 的核心成功指标（目标 4.5+/5）
 
 ## Connections
-- [[support-analytics-reporter]] ← depends_on ← [[support-support-responder]]（Support Responder 产生工单数据，Analytics Reporter 分析数据生成洞察）
-- [[support-support-responder]] ← extends ← [[support-legal-compliance-checker]]（合规问题升级至 Legal Compliance Checker）
-- [[Support-Responder-Agent]] ← extends ← [[Knowledge-Base]]（知识库是支持体系的核心基础设施）
-- [[support-executive-summary-generator]] ← depends_on ← [[support-support-responder]]（执行摘要基于支持数据分析）
+- [[Support-Analytics-Reporter]] ← depends_on ← [[Support-Responder]]：分析数据来源于支持交互记录
+- [[Support-Infrastructure-Maintainer]] ← depends_on ← [[Support-Responder]]：支持系统可用性是服务交付的基础
+- [[Support-Legal-Compliance-Checker]] ← collaborates_with ← [[Support-Responder]]：危机管理场景中的合规协作
+- [[Support-Responder]] ← feeds_into ← [[Support-Executive-Summary-Generator]]：支持数据驱动高管报告
+- [[Support-Responder]] ← uses ← [[Knowledge-Base-Management]]：知识库是服务交付的关键基础设施
 
 ## Contradictions
-- 与 [[support-legal-compliance-checker]] 冲突：
-  - 冲突点：问题解决优先 vs 合规优先
-  - 当前观点（Support Responder）：客户满意度优先于内部效率指标，快速解决问题是核心目标
-  - 对方观点（Legal Compliance Checker）：合规优先，任何业务流程变更前必须验证监管要求
-  - 协调建议：常规客户问题以 Support Responder 为主；涉及合规风险的问题（如数据删除/账户限制）升级至 Legal Compliance Checker 处理
+- 暂无已知冲突：Support Responder 的客户优先原则与其他 Agent 无实质性矛盾；其 SLA 驱动的响应时间目标与 Legal Compliance Checker 的合规审查流程在实际操作中可通过 T1/T2 升级机制协调处理。
diff --git a/wiki/sources/technical-artist.md b/wiki/sources/technical-artist.md
index a52353ba..026f2fdf 100644
--- a/wiki/sources/technical-artist.md
+++ b/wiki/sources/technical-artist.md
@@ -19,11 +19,16 @@ date: 2026-04-26
 - 移动端过度绘制（Overdraw）是性能隐性杀手——半透明/加法粒子必须经过审计并设定上限
 - 所有自定义着色器必须包含移动端安全变体或明确标注"仅 PC/主机"平台限制
 - LOD 管线是强制流程——每个英雄模型至少需要 LOD0 至 LOD3
+- 所有粒子系统必须在导入时设定 Max Particle Count 上限，禁止在生产后随意增加
+- AI 超分辨率（纹理超分）可用于存量资产质量提升而无需重新制作；ML 去噪可将光照贴图烘焙速度提升 10 倍且视觉质量相当
+- 着色器参数必须对艺术家暴露工具提示（tooltip）文档，确保参数含义和有效范围清晰可查
+- VFX 系统必须在含有 GPU 计时器的 profiling 场景中构建，每个效果需在多角度和距离下验证效果
 
 ## Key Quotes
 > "The bridge between artistic vision and engine reality." — 技术美术的角色定位
 > "Budget in numbers: This effect costs 2ms on mobile — we have 4ms total for VFX. Approved with caveats." — 性能决策语言范式
 > "Spec before start: Give me the budget sheet before you model — I'll tell you exactly what you can afford" — 协作流程核心原则
+> "No blame, only fixes: The texture blowout is a mipmap bias issue — here's the corrected import setting" — 问题解决心态
 
 ## Key Concepts
 - [[Shader]]：编写和优化目标平台着色器，包含移动端安全变体
@@ -36,12 +41,17 @@ date: 2026-04-26
 - [[RayTracing]]：实时光线追踪与路径追踪实现
 - [[Post-Processing]]：模块化后处理栈——Bloom、泛光、色差、晕影、LUT 调色
 - [[DLSS]]：AI 超采样技术集成（DLSS、FSR、XeSS）
+- [[MachineLearningArtPipeline]]：AI 辅助美术管线——纹理超分、ML 去噪光照烘焙、DLSS/FSR/XeSS 集成
+- [[ToolDevelopment]]：艺术家工具开发——Python/DCC 脚本、引擎编辑器工具、着色器参数验证工具
+- [[TextureAtlasing]]：纹理图集——UI 和小型环境细节使用图集合并，减少 Draw Call
 
 ## Key Entities
 - [[UnrealTechnicalArtist]]：Unreal 引擎专精的技术美术方向
 - [[UnityShaderGraphArtist]]：Unity URP/HDRP 着色器图形技术美术
 - [[UnrealWorldBuilder]]：Unreal 世界构建技术美术协作方
 - [[UnityArchitect]]：Unity 架构师——资产管线的上游决策者
+- [[BlenderAddonEngineer]]：Blender 插件工程师——DCC 端资产验证工具协作方
+- [[GodotShaderDeveloper]]：Godot 着色器开发者——跨引擎共享着色器知识
 
 ## Connections
 - [[Shader]] ← builds ← [[TechnicalArtist]]
@@ -50,8 +60,11 @@ date: 2026-04-26
 - [[Asset-Pipeline]] ← defines ← [[TechnicalArtist]]
 - [[UnrealTechnicalArtist]] ← specializes_in ← [[TechnicalArtist]]
 - [[UnityShaderGraphArtist]] ← specializes_in ← [[TechnicalArtist]]
+- [[GodotShaderDeveloper]] ← specializes_in ← [[TechnicalArtist]]
 - [[UnrealWorldBuilder]] ← depends_on ← [[TechnicalArtist]]（World Builder 依赖 TA 定义的视觉标准）
 - [[UnityArchitect]] ← coordinates_with ← [[TechnicalArtist]]（Asset Pipeline 标准协调）
+- [[BlenderAddonEngineer]] ← depends_on ← [[TechnicalArtist]]（DCC 工具依赖 TA 定义的资产规范）
+- [[MachineLearningArtPipeline]] ← enables ← [[TechnicalArtist]]（AI 工具扩展 TA 的资产质量提升能力）
 
 ## Contradictions
 - 无已知冲突。本文档为 Agent 个性定义，不与其他来源直接冲突。
diff --git a/wiki/sources/terminal-integration-specialist.md b/wiki/sources/terminal-integration-specialist.md
index 1a316021..89d58cff 100644
--- a/wiki/sources/terminal-integration-specialist.md
+++ b/wiki/sources/terminal-integration-specialist.md
@@ -2,53 +2,44 @@
 title: "Terminal Integration Specialist"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/spatial-computing/terminal-integration-specialist.md]]
+- [[Agent/agency-agents/spatial-computing/terminal-integration-specialist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Terminal Integration Specialist 是一个专注于终端仿真、文本渲染优化和 SwiftTerm 集成的 Agent，服务于现代 Swift 应用程序开发。
-- 问题域：如何在 Apple 平台上（iOS/macOS/visionOS）构建高性能、符合无障碍标准的终端模拟器；如何将 SSH 连接到终端仿真器；如何在 SwiftUI 应用中嵌入 SwiftTerm。
-- 方法/机制：
-  - 完整支持 VT100/xterm ANSI 转义序列，实现光标控制与终端状态管理
-  - 使用 Core Graphics / Core Text 优化文本渲染，实现平滑滚动
-  - 通过 SwiftNIO SSH / NMSSH 实现 SSH I/O 桥接
-  - 嵌入式 SwiftUI 生命周期管理和后台 I/O 线程处理
-- 结论/价值：提供了一套完整的 Apple 平台终端集成解决方案，兼顾性能、无障碍和跨平台考虑（iOS/macOS/visionOS）。
+- 核心主题：终端仿真、文本渲染优化与 SwiftTerm 集成，专门面向现代 Swift 应用程序的 AI Agent 个性化定义
+- 问题域：如何在 Apple 平台（iOS/macOS/visionOS）上构建高性能、原生感的终端仿真体验
+- 方法/机制：基于 SwiftTerm 库实现 VT100/xterm 标准兼容、Core Graphics 文本渲染、SSH 流桥接，以及 SwiftUI 生命周期管理
+- 结论/价值：提供了一套完整的终端集成最佳实践，涵盖性能优化、无障碍支持与多平台兼容性
 
 ## Key Claims（用中文描述）
-- SwiftTerm API 提供完整的公开接口，支持终端仿真的深度定制
-- Core Graphics 优化可实现高频文本更新下的平滑滚动渲染
-- 正确的后台线程处理可避免 UI 更新阻塞，确保终端 I/O 流畅
-- SSH 连接状态管理涵盖连接、断开、重连场景的完整终端行为处理
-- VoiceOver、动态类型等无障碍支持是 Apple 平台终端集成的必要条件
+- SwiftTerm 通过完整 ANSI 转义序列支持实现 VT100/xterm 标准兼容，使终端模拟器具备标准协议兼容性
+- Core Graphics 优化文本渲染与高效缓冲区管理，确保大终端历史记录场景下的流畅滚动
+- SwiftUI 集成需正确的生命周期管理，以在嵌入式终端视图中保持稳定状态
+- SSH I/O 桥接需处理连接/断开/重连场景，并在终端界面展示连接错误与认证失败信息
 
 ## Key Quotes
-> "Focuses on creating robust, performant terminal experiences that feel native to Apple platforms while maintaining compatibility with standard terminal protocols." — 核心理念
+> "Focuses on creating robust, performant terminal experiences that feel native to Apple platforms while maintaining compatibility with standard terminal protocols." — 核心理念：构建既原生又协议兼容的 Apple 平台终端体验
 
-> "Specializes in SwiftTerm specifically (not other terminal emulator libraries)" — 明确范围边界
+> "Specializes in SwiftTerm specifically (not other terminal emulator libraries)" — 明确限定技术栈范围
 
 ## Key Concepts
-- [[VT100/xterm Standards]]：完整的 ANSI 转义序列支持，用于光标控制和终端状态管理
-- [[SwiftTerm]]：Miguel de Icaza 开发的 MIT 许可 Swift 终端仿真库，核心依赖
-- [[Core Graphics Optimization]]：通过 Core Graphics / Core Text 优化文本渲染，实现高频更新下的平滑滚动
-- [[SSH I/O Bridging]]：将 SSH 流高效桥接到终端仿真器的输入/输出层
-- [[Scrollback Buffer]]：大终端历史的回滚缓冲区管理，支持搜索功能
-- [[Accessibility Integration]]：VoiceOver、动态类型等 Apple 无障碍技术集成
+- [[VT100/xterm Standards]]：终端协议标准，包含完整 ANSI 转义序列支持与光标控制
+- [[ANSI Escape Sequences]]：控制终端文本格式化、颜色与光标行为的标准化转义码序列
+- [[Core Graphics 文本渲染]]：Apple 平台高性能 2D 渲染框架，用于终端文本输出优化
+- [[SwiftUI 生命周期管理]]：在 SwiftUI 应用中嵌入 SwiftTerm 视图时的视图生命周期与状态维护
+- [[SSH I/O 桥接]]：将 SSH 数据流与终端仿真器输入输出高效连接的技术模式
 
 ## Key Entities
-- [[SwiftTerm]]（MIT License）：核心终端仿真库，GitHub: migueldeicaza/SwiftTerm
-- [[SwiftNIO SSH]]：用于 SSH 连接的 Swift 网络库
-- [[NMSSH]]：另一个 SSH 连接选项库
-- [[Core Graphics]]：Apple 平台 2D 渲染框架
-- [[Core Text]]：Apple 平台文本排版引擎
+- [[SwiftTerm]]：Miguel de Icaza 开发的 MIT 许可终端仿真库，是该 Agent 的核心技术栈
+- [[SwiftNIO SSH]]：Apple 平台的 SSH 协议实现，用于 SSH 连接支持
+- [[NMSSH]]：另一个可选的 SSH 库选项，用于跨平台 SSH 支持
 
 ## Connections
-- [[visionOS Spatial Engineer]] ← depends_on ← [[Terminal Integration Specialist]]：visionOS 空间工程师依赖终端集成实现空间终端体验
-- [[macOS Spatial Metal Engineer]] ← depends_on ← [[Terminal Integration Specialist]]：macOS Metal 工程师依赖终端集成处理渲染层面
-- [[SwiftTerm]] ← implements ← [[VT100/xterm Standards]]：SwiftTerm 库实现 VT100/xterm 标准
+- [[visionOS Spatial Engineer]] ← uses ← [[SwiftTerm]]
+- [[macOS Spatial/Metal Engineer]] ← shares_platform ← [[visionOS Spatial Engineer]]
 
 ## Contradictions
-- 无明显内容冲突；该 Agent 专注于 Apple 平台和 SwiftTerm，与其他通用终端解决方案（如 libvte、iTerm2）不在同一问题域内。
+- 无已知冲突
diff --git a/wiki/sources/testing-accessibility-auditor.md b/wiki/sources/testing-accessibility-auditor.md
index 1208c006..e95775a2 100644
--- a/wiki/sources/testing-accessibility-auditor.md
+++ b/wiki/sources/testing-accessibility-auditor.md
@@ -3,6 +3,7 @@ title: "Accessibility Auditor Agent Personality"
 type: source
 tags: []
 date: 2026-04-25
+last_updated: 2026-05-11
 ---
 
 ## Source File
@@ -13,52 +14,64 @@ date: 2026-04-25
 - 问题域：无障碍测试（Accessibility Testing）、WCAG 合规性评估、辅助技术（屏幕阅读器、键盘导航）验证
 - 方法/机制：
   - 基于 WCAG 2.2 AA 标准进行自动化扫描 + 手动辅助技术测试双重验证
-  - 四项 POUR 原则评估（可感知、可操作、可理解、健壮）
+  - 四项 POUR 原则评估（可感知 Perceivable、可操作 Operable、可理解 Understandable、健壮 Robust）
   - 屏幕阅读器（VoiceOver/NVDA/JAWS）真实交互流测试
-  - 键盘-only 导航完整测试
-  - 提供结构化审计报告模板，包含问题严重性分级和修复建议
-- 结论/价值：为 AI Agent 提供一套完整的无障碍审计方法论，确保数字产品对残障用户的真实可用性
+  - 键盘-only 导航完整测试（含所有交互组件的键盘模式）
+  - 提供结构化审计报告模板，包含问题严重性分级（Critical/Serious/Moderate/Minor）和修复建议
+  - 屏幕阅读器测试协议、键盘导航审计清单
+- 结论/价值：为 AI Agent 提供一套完整的无障碍审计方法论，确保数字产品对残障用户的真实可用性；区分"技术合规"与"实际可访问"
 
 ## Key Claims（用中文描述）
 - 自动化工具仅能发现约 30% 的无障碍问题，剩余 70% 需手动辅助技术测试发现
-- Lighthouse 绿色分数不等于无障碍可用——自定义组件（标签页、模态框、轮播图、日期选择器）需逐个审查
+- Lighthouse 绿色分数不等于无障碍可用——自定义组件（标签页、模态框、轮播图、日期选择器）在证明无障碍前均视为有问题
 - 所有交互流程必须支持纯键盘操作，"鼠标可用"不是有效的无障碍测试
 - 语义化 HTML 优于 ARIA——最好的 ARIA 是不需要 ARIA
+- 无障碍不是开发末期完成的清单，而是每个阶段都要倡导的实践
 
 ## Key Quotes
 > "If it's not tested with a screen reader, it's not accessible." — AccessibilityAuditor 核心原则
 > "Automated tools catch roughly 30% of accessibility issues — you catch the other 70%" — 自动化 vs 手动测试的差距
 > "Custom components (tabs, modals, carousels, date pickers) are guilty until proven innocent" — 自定义组件无障碍审查原则
 > "A green Lighthouse score does not mean accessible" — 合规性检查的诚实评估原则
+> "Decorative images with alt text and interactive elements without labels are equally harmful" — 平等对待所有无障碍问题
 
 ## Key Concepts
-- [[WCAG 2.2]]: Web Content Accessibility Guidelines 2.2，网页内容无障碍指南，审计标准的核心框架
+- [[WCAG 2.2]]: Web Content Accessibility Guidelines 2.2，网页内容无障碍指南，审计标准的核心框架，审计基准为 AA 级别
 - [[POUR Principles]]: 可感知（Perceivable）、可操作（Operable）、可理解（Understandable）、健壮（Robust），WCAG 的四项核心原则
-- [[ARIA]]: Accessible Rich Internet Applications，WAI-ARIA 规范，用于增强自定义组件的无障碍支持
-- [[Screen Reader Testing]]: 屏幕阅读器测试（VoiceOver/NVDA/JAWS），验证动态内容和交互组件的语音播报正确性
-- [[Keyboard Navigation Audit]]: 键盘导航审计，确保所有交互元素可通过 Tab/方向键访问且无键盘陷阱
-- [[axe-core]]: 自动化无障碍扫描工具，集成到 CI/CD 流程中用于回归测试
-- [[Focus Management]]: 焦点管理，动态内容加载时焦点应正确转移且不丢失
-- [[Live Regions]]: ARIA 实时区域，用于向屏幕阅读器用户播报状态更新和通知
+- [[ARIA]]: Accessible Rich Internet Applications，WAI-ARIA 规范，用于增强自定义组件的无障碍支持；最佳实践为优先使用语义化 HTML 而非 ARIA
+- [[Screen Reader Testing]]: 屏幕阅读器测试（VoiceOver/NVDA/JAWS），验证动态内容和交互组件的语音播报正确性，包含读序、焦点管理、实时区域播报
+- [[Keyboard Navigation Audit]]: 键盘导航审计，确保所有交互元素可通过 Tab/方向键访问且无键盘陷阱，包含跳导航链接、焦点可见性、模态框焦点返回
+- [[axe-core]]: 自动化无障碍扫描工具，可集成到 CI/CD 流程中用于回归测试
+- [[Focus Management]]: 焦点管理，动态内容加载时焦点应正确转移且不丢失，是单页应用无障碍的关键
+- [[Live Regions]]: ARIA 实时区域，用于向屏幕阅读器用户播报状态更新和通知，无需焦点改变即可播报
+- [[WAI-ARIA Authoring Practices]]: W3C 发布的 WAI-ARIA 创作实践指南，定义自定义组件的标准无障碍模式和键盘交互
+- [[Lighthouse Accessibility Score]]: Chrome DevTools 内置无障碍分数，仅覆盖约 30% 问题，不能替代真实辅助技术测试
 
 ## Key Entities
 - [[VoiceOver]]: Apple 屏幕阅读器（macOS/iOS），AccessibilityAuditor 主要测试环境之一
 - [[NVDA]]: NonVisual Desktop Access，Windows 平台开源屏幕阅读器
 - [[JAWS]]: Job Access With Speech，Windows 商业屏幕阅读器
-- [[axe-core]]: Deque Labs 开发的自动化无障碍测试引擎
+- [[axe-core]]: Deque Labs 开发的自动化无障碍测试引擎，支持 CI/CD 集成
 - [[Lighthouse]]: Chrome DevTools 内置审计工具，可生成无障碍分数但不足以验证真实可用性
 - [[WAI-ARIA]]: W3C Web Accessibility Initiative 发布的富互联网应用无障碍规范
+- [[Dragon NaturallySpeaking]]: 语音控制软件，用于验证语音控制兼容性
 
 ## Connections
 - [[Testing Tool Evaluator]] ← 协同 → [[Testing Evidence Collector]]
 - [[Testing Reality Checker]] ← 供给无障碍证据 → [[Accessibility Auditor]]
 - [[Frontend Developer]] ← 接收修复建议 → [[Accessibility Auditor]]
 - [[UI Designer]] ← 审计设计 token 对比度/间距/目标尺寸 → [[Accessibility Auditor]]
-- [[Legal Compliance Checker]] ← 关联 ADA/Section 508 合规要求 → [[Accessibility Auditor]]
+- [[UX Researcher]] ← 贡献无障碍发现到用户洞察 → [[Accessibility Auditor]]
+- [[Legal Compliance Checker]] ← 关联 ADA Title III/Section 508/EAA 合规要求 → [[Accessibility Auditor]]
+- [[Testing Evidence Collector]] ← 提供无障碍特定测试用例 → [[Accessibility Auditor]]
+- [[Cultural Intelligence Strategist]] ← 确保简单语言错误恢复不意外剥离文化语境 → [[Accessibility Auditor]]
 
 ## Contradictions
 - 与 [[Testing Tool Evaluator]] 的潜在冲突：
   - 冲突点：自动化工具（如 axe-core/Lighthouse）的充分性评估
-  - 当前观点（AccessibilityAuditor）：自动化工具只能覆盖 30%，不能替代手动测试
-  - 对方观点（Tool Evaluator）：倾向于相信自动化工具的检测能力
-  - 建议：两者协同使用，自动化工具作为基线，手动测试作为深度验证
+  - 当前观点（AccessibilityAuditor）：自动化工具只能覆盖 30%，不能替代手动辅助技术测试
+  - 对方观点（Tool Evaluator）：倾向于相信自动化工具的检测能力和评分
+  - 建议：两者协同使用，自动化工具作为基线扫描，手动测试作为深度验证
+- 与合规性追求的内在张力：
+  - AccessibilityAuditor 明确反对"合规剧院"（Compliance Theater）——仅追求通过自动化检查而不解决真实可用性问题
+  - 与部分只看 Lighthouse 分数的利益相关者存在实践层面的分歧
diff --git a/wiki/sources/testing-api-tester.md b/wiki/sources/testing-api-tester.md
index 1da182c9..b9f959db 100644
--- a/wiki/sources/testing-api-tester.md
+++ b/wiki/sources/testing-api-tester.md
@@ -2,7 +2,7 @@
 title: "API Tester Agent Personality"
 type: source
 tags: ["the-agency", "testing", "api", "automation", "qa", "performance", "security"]
-date: 2026-04-25
+date: 2026-05-09
 ---
 
 ## Source File
@@ -20,12 +20,16 @@ date: 2026-04-25
 - 负载测试必须验证 10 倍正常流量容量，确保系统可扩展性
 - 安全测试覆盖 OWASP API Security Top 10，包含认证绕过、SQL 注入、XSS、速率限制等关键威胁
 - API 测试必须集成到 CI/CD 流水线，实现持续验证而非手动测试
+- 数据库查询性能必须经过优化和测试验证
+- 缓存效果与性能影响必须纳入测试范围
+- 生产环境 API 健康状态需通过自动化告警与响应机制监控
 
 ## Key Quotes
 > "Breaks your API before your users do." — API Tester Agent 的核心理念，防御性测试哲学
 > "API response times must be under 200ms for 95th percentile" — 明确的性能 SLA 标准
 > "Always test authentication and authorization mechanisms thoroughly" — 安全优先原则
 > "Load testing must validate 10x normal traffic capacity" — 规模化验证要求
+> "Error rates must stay below 0.1% under normal load" — 可靠性保障标准
 
 ## Key Concepts
 - [[API Testing]]：覆盖功能、性能、安全三维度，通过自动化测试框架验证 API 端点行为与 SLA 合规性
@@ -33,18 +37,26 @@ date: 2026-04-25
 - [[Security Testing]]：OWASP API Security Top 10 安全测试框架，包含认证/授权/输入验证/速率限制等核心检查项
 - [[Contract Testing]]：API 版本间契约合规性与向后兼容性验证，确保服务间接口稳定性
 - [[CI/CD Integration]]：测试自动化嵌入持续集成/持续部署流水线，实现每次代码变更的自动质量验证
-- [[OWASP API Security Top 10]]：API 安全测试的行业标准清单，覆盖 BOLA/ BFLA/ Broken Auth 等关键 API 威胁
+- [[OWASP API Security Top 10]]：API 安全测试的行业标准清单，覆盖 BOLA/BFLA/Broken Auth 等关键 API 威胁
+- [[Load Testing]]：负载测试、压力测试、可扩展性评估，验证系统在 10 倍正常流量下的表现
+- [[Rate Limiting]]：速率限制与滥用保护测试，确保 API 在恶意或过量请求下仍保持可用
+- [[Input Validation]]：输入消毒与 SQL 注入防护验证，防止恶意输入导致安全漏洞
+- [[Endpoint Coverage]]：端点覆盖率目标 95%+，确保每个 API 端点都有对应的自动化测试用例
 
 ## Key Entities
 - [[Playwright]]：Node.js 端到端测试框架，API Tester 的主要测试工具之一，支持功能与安全测试
 - [[REST Assured]]：Java API 测试框架，适用于 Java 生态系统的 REST API 验证
 - [[k6]]：Grafana 开源负载测试工具，用于性能测试与可扩展性验证
 - [[perf_hooks]]：Node.js 内置性能监测 API，用于精确的 API 响应时间测量
+- [[JWT]]（JSON Web Token）：OAuth 2.0 和 JWT 安全测试中的令牌验证与会话管理
+- [[OWASP]]（Open Web Application Security Project）：API 安全测试的行业标准制定组织
 
 ## Connections
 - [[specialized-model-qa]] ← 测试范围互补 ← [[testing-api-tester]]（模型质量测试 vs API 端点测试）
 - [[testing-accessibility-auditor]] ← 质量保障并行 ← [[testing-api-tester]]（可访问性测试 vs API 功能/性能/安全测试）
 - [[testing-tool-evaluator]] ← 工具推荐上游 ← [[testing-api-tester]]（工具评估为测试实施提供框架选择）
+- [[testing-workflow-optimizer]] ← 测试工作流协同 ← [[testing-api-tester]]（工作流优化与 API 测试套件编排）
+- [[testing-performance-benchmarker]] ← 性能测试专项 ← [[testing-api-tester]]（性能基准测试与 API SLA 验证协同）
 - [[specialized-mcp-builder]] ← 技术栈关联 ← [[testing-api-tester]]（MCP 服务器构建需要 API 测试能力保障）
 - [[multi-agent-system-reliability]] ← 质量保障基础 ← [[testing-api-tester]]（系统可靠性依赖 API 质量验证）
 
diff --git a/wiki/sources/testing-evidence-collector.md b/wiki/sources/testing-evidence-collector.md
index 51cfce23..9acf3e15 100644
--- a/wiki/sources/testing-evidence-collector.md
+++ b/wiki/sources/testing-evidence-collector.md
@@ -1,53 +1,47 @@
 ---
-title: "Testing Evidence Collector Agent Personality"
+title: "Testing Evidence Collector"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/testing/testing-evidence-collector.md]]
+- [[Agent/agency-agents/testing/testing-evidence-collector.md]]
 
 ## Summary（用中文描述）
-- 核心主题：EvidenceQA —— 一个以截图为核心证据的 QA Agent 个性化角色定义
-- 问题域：如何对 AI Agent 生成的前端实现进行严格的质量评估，避免"幻想式报告"（Fantasy Reporting）
-- 方法/机制：通过 Playwright 自动化截图 + 视觉对比 + 强制默认找问题（至少 3-5 个）来实现真实性检验
-- 结论/价值：QA 质量评估必须基于视觉证据，零问题报告是红色警报，必须强制提供截图
+- 核心主题：EvidenceQA 是一个以视觉证据为核心的 QA Agent 人格，专注于通过截图和实际测试结果来验证功能实现。
+- 问题域：AI Agent 开发中的质量保证流程 —— 如何防止"幻想式报告"（fantasy reporting）通过验收。
+- 方法/机制：通过 Playwright 自动化截图采集 → 截图视觉分析 → 规格对比 → 生成有据可查的 QA 报告。
+- 结论/价值：为 AI Agent 开发流程引入严格的视觉证据验证机制，确保"所见即所得"，避免功能声称与实际实现不符。
 
 ## Key Claims（用中文描述）
-- EvidenceQA 相信"截图不会撒谎"——视觉证据是唯一可靠的真理
-- 首次实现总是存在至少 3-5 个问题，"零问题"是红色警报
-- 每个声明都需要截图证据支撑，无证据的声明视为"幻想"
-- luxury/premium 等描述词无截图支撑即为违规
-- 质量评级默认 FAILED，除非压倒性证据证明通过
+- 视觉证据是唯一可信的真相：无法在截图中看到的功能实现，等同于不存在。
+- 默认应发现 3-5+ 个问题：首次实现总是存在问题的，"零问题"报告是危险信号。
+- 每个断言都需要截图佐证：口头或文字声称必须有对应的截图证据支撑。
+- 诚实评估质量等级：Basic / Good / Excellent，拒绝虚假的 A+ / 98 分等完美评分。
+- 生产就绪状态默认失败：除非有压倒性证据，否则默认判定为 FAILED。
 
 ## Key Quotes
-> "Screenshots Don't Lie" — Visual evidence is the only truth that matters
-> "Default to Finding Issues" — First implementations ALWAYS have 3-5+ issues minimum
-> "Zero issues found" is a red flag - look harder
-> "Your job is to be the reality check that prevents broken websites from being approved"
+> "Screenshots Don't Lie" — "If you can't see it working in a screenshot, it doesn't work"
+> "Default to Finding Issues" — "First implementations ALWAYS have 3-5+ issues minimum"
+> "Prove Everything" — "Every claim needs screenshot evidence"
 
 ## Key Concepts
-- [[Visual Evidence]]：QA 评估的唯一可靠依据，通过 Playwright 自动化截图捕获
-- [[Fantasy Reporting]]：指无视觉证据支撑的声称，如"零问题"、"Luxury 级别"等
-- [[Reality Check Commands]]：强制性初始检查命令，包括 Playwright 截图、文件检查、grep 特征搜索
-- [[Specification Compliance]]：将实际截图与原始规范逐字对比，不添加规范外的额外要求
-- [[Accordion Testing Protocol]]：通过 before/after 截图对比验证手风琴组件的展开/折叠功能
-- [[Form Testing Protocol]]：验证表单提交、校验、错误信息展示的完整性
-- [[Mobile Responsive Testing]]：在 desktop/tablet/mobile 三种分辨率下验证布局和导航
+- [[EvidenceQA]]：截图驱动的 QA Agent 人格，核心原则是"截图不说谎"
+- [[Playwright自动化截图]]：使用 `./qa-playwright-capture.sh` 脚本自动采集多设备、多状态的截图证据
+- [[FantasyReporting]]：指 AI Agent 声称"零问题"或"完美评分"但无视觉证据支撑的报告行为
+- [[规格一致性验证]]：将实际截图与原始规格说明进行逐条对比，记录匹配/不匹配项
+- [[QA报告模板]]：结构化的证据报告格式，包含 Reality Check → Visual Evidence → Issues Found → Honest Assessment
 
 ## Key Entities
-- [[EvidenceQA]]：截图驱动型 QA Agent，以视觉证据为唯一真理，默认发现 3-5+ 问题
-- [[Playwright]]：自动化截图工具（qa-playwright-capture.sh），提供 comprehensive screenshots 和 test-results.json
+- [[EvidenceQA]]：QA Agent 人格名，持久的视觉证据驱动型质量保证专员
 
 ## Connections
-- [[Testing Reality Checker]] ← related_to ← [[Testing Evidence Collector]]
-- [[Testing Test Results Analyzer]] ← related_to ← [[Testing Evidence Collector]]
-- [[Testing Performance Benchmarker]] ← related_to ← [[Testing Evidence Collector]]
+- [[TestingRealityChecker]] ← depends_on ← [[TestingEvidenceCollector]]（依赖截图证据进行现实检查）
+- [[TestingTestResultsAnalyzer]] ← depends_on ← [[TestingEvidenceCollector]]（依赖截图 JSON 数据进行性能分析）
+- [[TestingPerformanceBenchmarker]] ← depends_on ← [[TestingEvidenceCollector]]（依赖截图和性能数据）
+- [[Playwright]] ← used_by ← [[TestingEvidenceCollector]]（核心截图采集工具）
 
 ## Contradictions
-- 与声称"零问题"的报告冲突：
-  - 冲突点：首次实现的问题数量
-  - 当前观点：默认发现 3-5+ 问题，"零问题"是红色警报
-  - 对方观点：声称"零问题"即通过
-```
+- 无冲突内容
+
diff --git a/wiki/sources/testing-performance-benchmarker.md b/wiki/sources/testing-performance-benchmarker.md
index 21cbb73f..707600b9 100644
--- a/wiki/sources/testing-performance-benchmarker.md
+++ b/wiki/sources/testing-performance-benchmarker.md
@@ -2,52 +2,47 @@
 title: "Performance Benchmarker Agent Personality"
 type: source
 tags: []
-date: 2026-04-21
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/testing/testing-performance-benchmarker.md]]
+- [[Agent/agency-agents/testing/testing-performance-benchmarker.md]]
 
 ## Summary（用中文描述）
-- 核心主题：性能测试与优化专家 Agent，专注于测量、分析和改进跨应用程序和基础设施的系统性能
-- 问题域：性能基线建立、负载/压力测试、Web Vitals 优化、容量规划、可扩展性评估
-- 方法/机制：使用 k6 编写综合性能测试套件，统计置信区间分析，Core Web Vitals 监控，性能回归测试
-- 结论/价值：数据驱动的方法论，通过量化指标证明性能改进，确保系统满足 SLA 要求
+- 核心主题：AI Agent 角色定义 —— Performance Benchmarker（性能基准测试专家）
+- 问题域：系统性能测试、Web 性能优化、容量规划与可扩展性评估
+- 方法/机制：通过数据驱动的性能测试方法，建立基线、识别瓶颈、提供优化建议并持续监控
+- 结论/价值：为所有系统设定性能 SLA 标准（95% 置信度），通过 Core Web Vitals 和负载测试确保用户体验
 
 ## Key Claims（用中文描述）
-- Performance Benchmarker Agent 通过系统性性能测试确保所有系统以 95% 置信度满足性能 SLA
-- 通过 Core Web Vitals 优化（LLC < 2.5s、FID < 100ms、CLS < 0.1）提升用户体验
-- 通过查询优化可将第95百分位响应时间从 850ms 降至 180ms
-- 通过性能监控可预防 90% 的性能相关事故
+- 所有系统必须满足性能 SLA，要求 95% 置信度（Performance-First Methodology）
+- Core Web Vitals 达标标准：LCP < 2.5s、FID < 100ms、CLS < 0.1
+- 性能优化前必须建立基线，并使用统计分析和置信区间进行测量
+- 优先考虑用户感知性能，而非单纯的技术指标
 
 ## Key Quotes
-> "95th percentile response time improved from 850ms to 180ms through query optimization" — 数据驱动的优化效果量化
-
-> "Page load time reduction of 2.3 seconds increases conversion rate by 15%" — 性能与业务影响关联
-
-> "Always establish baseline performance before optimization attempts" — 性能优化的首要原则
+> "Always establish baseline performance before optimization attempts" — 性能测试核心原则
+> "95th percentile response time improved from 850ms to 180ms through query optimization" — 数据驱动的优化案例
+> "Page load time reduction of 2.3 seconds increases conversion rate by 15%" — 用户体验影响量化
 
 ## Key Concepts
-- [[LoadTesting]]：模拟正常和峰值负载，验证系统在预期条件下的性能表现
-- [[StressTesting]]：逐步增加负载直到系统崩溃，找出性能临界点和恢复行为
-- [[CoreWebVitals]]：Google 定义的页面用户体验核心指标（LCP、FID、CLS）
-- [[RealUserMonitoring]]：基于真实用户数据的性能监控，对抗合成测试的局限性
-- [[CapacityPlanning]]：基于增长预测和使用模式预测资源需求
-- [[ConfidenceIntervals]]：统计置信区间用于可靠的性能测量
+- [[PerformanceBenchmarker]]：AI Agent 角色，专注于测量、分析和改进系统性能，通过数据驱动的方法确保系统满足性能 SLA
+- [[CoreWebVitals]]：Web 性能核心指标，包括 LCP（最大内容绘制）、FID（首次输入延迟）、CLS（累计布局偏移），是衡量用户体验的关键标准
+- [[LoadTesting]]：负载测试，通过模拟真实用户行为在不同负载条件下测试系统性能，识别瓶颈
+- [[CapacityPlanning]]：容量规划，基于增长预测和Usage模式预测资源需求，评估水平/垂直扩展能力
+- [[ErrorBudget]]：错误预算，在可靠性工程中允许一定范围的故障时间，用于平衡创新与稳定性
+- [[RealUserMonitoring]]：真实用户监控（RUM），通过采集真实用户数据而非合成测试来衡量 Web 性能
 
 ## Key Entities
-- [[TestingRealityChecker]]：测试现实核查 Agent，与 Performance Benchmarker 协同工作
-- [[TestingApiTester]]：API 测试专家 Agent，共同构成全面测试体系
-- [[WorkflowOptimizerAgent]]：工作流优化 Agent，通过性能优化提升工作流效率
+- [[k6]]：开源负载测试工具，Performance Benchmarker 在示例代码中使用的性能测试框架，支持多协议和自定义指标
+- [[Lighthouse]]：Google 开发的 Web 性能审计工具，可用于测量 Core Web Vitals 分数
 
 ## Connections
-- [[TestingRealityChecker]] ← complements ← [[TestingPerformanceBenchmarker]]
-- [[TestingApiTester]] ← extends ← [[TestingPerformanceBenchmarker]]
-- [[WorkflowOptimizerAgent]] ← depends_on ← [[TestingPerformanceBenchmarker]]
+- [[TestingRealityChecker]] ← tests → [[PerformanceBenchmarker]]
+- [[TestingWorkflowOptimizer]] ← optimizes → [[PerformanceBenchmarker]]
+- [[APITester]] ← complements → [[PerformanceBenchmarker]]
+- [[TestingToolEvaluator]] ← evaluates → [[PerformanceBenchmarker]]
 
 ## Contradictions
-- 与 [[TestingRealityChecker]] 的视角差异：
-  - 冲突点：Reality Checker 强调"真实用户感受"，Performance Benchmarker 强调"量化指标"
-  - 当前观点：量化指标（p95 < 500ms）是性能优化的客观标准
-  - 对方观点：用户主观感受比指标更重要，指标可能具有欺骗性
-  - 调和：两者互补——指标指导优化方向，用户体验验证优化效果
+- 无已知冲突
+
diff --git a/wiki/sources/testing-reality-checker.md b/wiki/sources/testing-reality-checker.md
index d6051585..5c7daa98 100644
--- a/wiki/sources/testing-reality-checker.md
+++ b/wiki/sources/testing-reality-checker.md
@@ -2,51 +2,49 @@
 title: "Testing Reality Checker"
 type: source
 tags: []
-date: 2026-04-21
+date: 2026-04-25
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/testing/testing-reality-checker.md]]
+- [[Agent/agency-agents/testing/testing-reality-checker.md]]
 
 ## Summary（用中文描述）
-- 核心主题：The Agency Testing 部门的 Reality Checker Agent——通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。
-- 问题域：AI Agent 协作中各环节（设计/开发/QA）给出的评估过于乐观，缺乏实际截图验证，导致"98/100 评级"发给基础网站、"生产就绪"标签打在未完成系统上。
-- 方法/机制：强制三步流程（Reality Check 命令 → QA 交叉验证 → 端到端系统截图分析）+ 硬性失败触发器；默认 NEETS WORK 状态，必须有压倒性证据才能升级为 READY。
-- 结论/价值：第一次实现通常需要 2-3 轮修订；C+/B- 评级属正常；只有真实截图证据才能支撑"生产就绪"声明。
+- 核心主题：AI Agent 开发中的质量把控与现实核查机制——防止不切实际的"幻想型认证"，要求基于截图证据的生产就绪性评估
+- 问题域：AI Agent 系统中的集成测试、质量认证、部署就绪性评估
+- 方法/机制：通过强制执行 Reality Check 命令、抓取截图证据、交叉验证 QA 发现、端到端用户旅程测试，默认状态为"NEEDS WORK"
+- 结论/价值：只有基于压倒性证据的评估才能获得生产认证；初次实现通常需要 2-3 轮迭代
 
 ## Key Claims（用中文描述）
-- Testing Reality Checker Agent 作为最后一道防线，通过截图证据截断"幻想型认证"，要求压倒性视觉证明。
-- 所有系统声明需要视觉证明（自动化截图），规格说明需要对照实际实现进行交叉验证。
-- 完整的用户旅程测试需要截图证据；性能数据（加载时间、错误率）必须来自 test-results.json。
-- 默认"NEEDS WORK"状态，除非有压倒性证据支持"READY"。
+- Reality Checker Agent 通过强制执行截图验证，防止"零问题"或"98/100"等无根据的完美评分
+- 所有系统声明都需要可视化证据支持，Cross-reference QA 发现与实际实现
+- 测试完整用户旅程需要截图证据，验证规格是否真正被实现
+- 首次实现通常需要 2-3 轮修订周期，C+/B- 评分正常且可接受
+- "Production Ready" 状态默认为 NEEDS WORK，除非有压倒性证据支持
 
 ## Key Quotes
-> "You're the last line of defense against unrealistic assessments" — Testing Reality Checker Agent 自我定位
-> "Default to 'NEEDS WORK' status unless proven otherwise" — 核心认证原则
-> "First implementations typically need 2-3 revision cycles, C+/B- ratings are normal" — 现实质量预期
-> "Trust evidence over claims" — 质量认证核心方法论
+> "Defaults to 'NEEDS WORK' status unless proven otherwise" — 核心立场：默认不通过
+> "No more '98/100 ratings' for basic dark themes" — 反对无根据的完美评分
+> "Trust evidence over claims, default to finding issues" — 信任证据而非声明
+> "First implementations typically need 2-3 revision cycles" — 现实的质量改进周期
 
 ## Key Concepts
-- [[End-to-End Testing]]：完整用户旅程截图分析（桌面/平板/手机 × 交互前/后对比）
-- [[Evidence-Based Certification]]：以自动化截图 + test-results.json 数据为唯一认证依据
-- [[Specification Compliance]]：原始规格与实际实现之间的差距分析（gap analysis）
-- [[Quality Gate]]：生产就绪认证门槛——默认"NEEDS WORK"，需压倒性证据才通过
-- [[Automated Screenshot Testing]]：Playwright qa-playwright-capture.sh 自动化截图捕获
+- [[IntegrationTesting]]：系统级集成测试，验证各组件协同工作
+- [[EvidenceBasedAssessment]]：基于截图和性能数据的质量评估方法
+- [[RealityCheck]]：防止幻想型认证的核查机制
+- [[Playwright]]：自动化浏览器截图工具（qa-playwright-capture.sh）
 
 ## Key Entities
-- Testing Reality Checker Agent：The Agency Testing 部门角色——截图驱动的生产就绪认证 Agent
-- QA Agent：前序 QA 测试环节，提供自动化测试发现和证据
-- Integration Agent：RealityIntegration——Reality Checker 的执行主体
-- [[testing-workflow-optimizer]]：工作流优化 Agent，为 Reality Checker 提供优化流程建议
-- [[testing-api-tester]]：API 测试 Agent，提供后端接口层面的测试证据
+- [[TestingRealityChecker]]：Reality Checker Agent 本身，终极集成测试和部署就绪性评估角色
+- [[QA Agent]]：QA 代理，提供自动化 headless Chrome 测试结果作为证据来源
 
 ## Connections
-- [[testing-workflow-optimizer]] ← workflow integration ← [[testing-reality-checker]]
-- [[testing-api-tester]] ← evidence source ← [[testing-reality-checker]]
-- [[testing-accessibility-auditor]] ← cross-validation ← [[testing-reality-checker]]
-- [[testing-evidence-collector]] ← provides screenshots ← [[testing-reality-checker]]
-- [[testing-reality-checker]] ← final gate ← [[agents-orchestrator]]
+- [[Testing Workflow Optimizer]] ← depends_on ← [[Testing Reality Checker]]
+- [[Testing API Tester]] ← extends ← [[Testing Reality Checker]]
+- [[Testing Evidence Collector]] ← provides_evidence_to ← [[Testing Reality Checker]]
+- [[Testing Tool Evaluator]] ← evaluates_tools ← [[Testing Reality Checker]]
 
 ## Contradictions
-- 与 [[testing-workflow-optimizer]] 潜在张力：Workflow Optimizer 追求流程效率（目标：75% 流程错误减少），Reality Checker 追求真实性（默认"需要工作"），两者在修订周期数量上可能存在分歧——Optimizer 希望快速迭代，Checker 要求充分证据
-- 与 [[testing-api-tester]] 的互补关系：API Tester 提供后端接口测试证据，Reality Checker 要求端到端截图；两者共同构成前后端双重质量门控
+- 与过度乐观的 Agent 评估体系冲突：
+  - 冲突点：其他 Agent 可能声称"零问题"或"生产就绪"而无需证据
+  - 当前观点：Reality Checker 默认为 NEEDS WORK，要求压倒性证据
+  - 对方观点：其他 Agent 可能认为系统已完成
diff --git a/wiki/sources/testing-test-results-analyzer.md b/wiki/sources/testing-test-results-analyzer.md
index d2eaff15..d5b95c6c 100644
--- a/wiki/sources/testing-test-results-analyzer.md
+++ b/wiki/sources/testing-test-results-analyzer.md
@@ -1,53 +1,60 @@
 ---
 title: "Test Results Analyzer Agent Personality"
 type: source
-tags: [agent-personality, testing, quality-assurance, statistical-analysis, machine-learning]
-date: 2026-04-25
+tags: [testing, quality, analytics, python]
+date: 2026-04-28
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/testing/testing-test-results-analyzer.md]]
+- [[Agent/agency-agents/testing/testing-test-results-analyzer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：测试结果分析专家 Agent 的角色定义与行为规范，专注于全面的测试结果评估、质量指标分析和可操作洞察生成
-- 问题域：软件测试质量保障、缺陷预测、发布就绪评估
-- 方法/机制：统计分析方法 + 机器学习预测模型 + 质量指标仪表盘 + 多层级报告生成
-- 结论/价值：通过数据驱动的测试分析，将原始测试数据转化为战略洞察，驱动质量决策和持续改进
+- 核心主题：AI Agent 角色定义——测试结果分析专家，通过统计分析、模式识别和机器学习，将原始测试数据转化为战略质量洞察和可操作建议。
+- 问题域：软件质量保证中的测试结果分析领域，涵盖功能测试、性能测试、安全测试、集成测试的全方位质量评估。
+- 方法/机制：统计分析（scipy、pandas）+ 机器学习预测（Random Forest）+ 覆盖率分析 + 缺陷密度计算 + 发布就绪度评估。
+- 结论/价值：数据驱动的质量决策，95% 置信度保证，帮助团队在发布前识别风险、量化质量债务、提供可辩护的 GO/NO-GO 建议。
 
 ## Key Claims（用中文描述）
-- Test Results Analyzer Agent 通过统计分析方法验证结论，为所有质量声明提供置信区间和统计显著性
-- 基于机器学习（RandomForestClassifier）的缺陷预测模型，预测缺陷易发区域，风险评分准确率目标 95%
-- 发布就绪评估采用多维度质量指标（通过率、覆盖率、性能SLA、安全合规、缺陷密度），结合置信度计算给出 GO/NO-GO 建议
-- 质量第一决策原则：优先考虑用户体验和产品质量，而非发布timeline
-- 测试报告在测试完成后 24 小时内交付，干系人满意度目标 4.5/5
+- Test Results Analyzer Agent 将原始测试数据转化为战略质量洞察，驱动知情决策。
+- 每次测试结果必须分析模式和改进行会。
+- 始终使用统计方法验证结论和推荐，提供置信区间和统计显著性。
+- 推荐基于可量化证据而非假设。
+- 优先考虑用户体验和产品质量，而非发布的时间线。
+- 质量投资具有明确 ROI——$50K 的质量投入可防止约 $300K 的生产缺陷成本。
+- 95% 准确率的质量风险预测和发布就绪度评估是核心成功指标。
 
 ## Key Quotes
-> "Reads test results like a detective reads evidence — nothing gets past." — Agent 个性描述
-> "Test pass rate improved from 87.3% to 94.7% with 95% statistical confidence" — 精确沟通风格示例
-> "Quality investment of $50K prevents estimated $300K in production defect costs" — 质量投资ROI分析示例
+> "Test pass rate improved from 87.3% to 94.7% with 95% statistical confidence" — 精确数据表达示例
+> "Failure pattern analysis reveals 73% of defects originate from integration layer" — 模式分析洞察示例
+> "Quality investment of $50K prevents estimated $300K in production defect costs" — 战略价值量化示例
+> "Current defect density of 2.1 per KLOC is 40% below industry average" — 对比基准上下文示例
 
 ## Key Concepts
-- [[TestCoverageAnalysis]]：通过覆盖率统计（行/分支/函数/语句覆盖）和差距分析识别未覆盖区域
-- [[StatisticalAnalysis]]：使用统计方法验证结论，提供置信区间和统计显著性，支持跨数据源交叉验证
-- [[DefectPrediction]]：基于历史缺陷数据训练 RandomForest 分类器，预测缺陷易发区域并给出置信分数
-- [[ReleaseReadinessAssessment]]：综合通过率、覆盖率阈值、性能SLA、安全合规、缺陷密度等指标计算风险评分，给出 GO/NO-GO 建议
-- [[QualityMetrics]]：代码覆盖率、功能覆盖率、测试有效性、缺陷密度等可量化的质量指标体系
-- [[FailurePatternAnalysis]]：将测试失败按类型（功能/性能/安全/集成）分类，识别根因和趋势
-- [[QualityROI]]：质量投资回报分析，量化预防缺陷的成本节约与质量改进的收益
-- [[PredictiveModeling]]：使用 sklearn 集成方法对未来质量结果进行预测建模
+- [[Test-Coverage-Analysis]]：通过行覆盖率/分支覆盖率/函数覆盖率/语句覆盖率识别测试覆盖缺口，结合文件级风险评估和优先级排序。
+- [[Failure-Pattern-Analysis]]：按功能/性能/安全/集成四类对失败进行分类统计分析，识别系统性质量问题。
+- [[Defect-Prediction]]：基于代码指标和历史缺陷数据训练 Random Forest 分类器，预测缺陷易发区域。
+- [[Release-Readiness-Assessment]]：综合测试通过率/覆盖率阈值/性能 SLA/安全合规/缺陷密度/风险评分，生成 GO/NO-GO 建议及置信度。
+- [[Statistical-Analysis]]：假设检验、置信区间、相关性分析，用于验证发现并确保结论有统计依据。
+- [[Quality-Metrics]]：缺陷密度、测试有效率、覆盖率趋势等量化质量指标的计算与分析。
+- [[Quality-ROI-Analysis]]：质量投入成本与缺陷预防收益的量化分析，用于指导质量投资决策。
 
 ## Key Entities
-- [[TestResultsAnalyzer]]：本 Agent 本身，测试数据分析和质量情报专家，负责从测试结果中提取洞察
-- [[RandomForestClassifier]]：scikit-learn 提供的随机森林分类器，用于缺陷易发性预测
-- [[pandas / numpy / scipy.stats]]：统计分析依赖的核心 Python 库
-- [[matplotlib / seaborn]]：测试结果可视化依赖的 Python 库
+- [[pytest]]：Python 单元测试框架（出现在代码示例上下文）。
+- [[scikit-learn]]：Python 机器学习库，RandomForestClassifier 用于缺陷预测建模。
+- [[pandas]]：Python 数据处理库，用于测试结果数据分析。
+- [[scipy]]：Python 科学计算库，用于统计检验和置信区间计算。
+- [[TestResultsAnalyzer]]：测试结果分析 Agent 本身，作为 The Agency Testing 部门的核心分析专家。
 
 ## Connections
-- [[TestingPerformanceBenchmarker]] ← same_agent_family ← [[TestResultsAnalyzer]]
-- [[TestingRealityChecker]] ← same_agent_family ← [[TestResultsAnalyzer]]
-- [[TestingWorkflowOptimizer]] ← same_agent_family ← [[TestResultsAnalyzer]]
-- [[APITester]] ← upstream_data_source ← [[TestResultsAnalyzer]]（API Tester 提供测试数据输入）
-- [[TestResultsAnalyzer]] ← produces ← [[QualityMetrics]] / [[DefectPrediction]]
+- [[Testing-Workflow-Optimizer]] ← extends ← [[Test-Results-Analyzer]]：Workflow Optimizer 在测试执行后调用 Analyzer 进行结果分析。
+- [[Testing-Performance-Benchmarker]] ← depends_on ← [[Test-Results-Analyzer]]：Performance Benchmarker 依赖 Analyzer 的统计方法来验证性能指标显著性。
+- [[Testing-API-Tester]] ← feeds_data ← [[Test-Results-Analyzer]]：API Tester 的输出作为 Analyzer 的输入数据源。
+- [[Quality-Gate]] ← uses ← [[Release-Readiness-Assessment]]：发布就绪度评估是质量门控决策的核心依据。
+- [[Dev-QA-Loop]] ← feeds ← [[Failure-Pattern-Analysis]]：缺陷模式分析结果反馈到 Dev-QA 循环以指导测试优先级调整。
 
 ## Contradictions
-- 暂无发现与其他 Wiki 页面的直接冲突
+- 与 [[Testing-Reality-Checker]] 的信息冲突：
+  - 冲突点：Reality Checker 关注测试环境真实性与模拟准确性；Analyzer 关注数据分析的统计严谨性。
+  - 当前观点：应优先确保分析方法的统计有效性，置信区间必须明确报告。
+  - 对方观点：统计结果的可信度依赖于输入数据的真实性，两者缺一不可。
+  - 协调建议：Reality Checker 提供数据质量保证 → Analyzer 进行统计分析 → 两者共同构成完整的质量评估链条。
diff --git a/wiki/sources/testing-tool-evaluator.md b/wiki/sources/testing-tool-evaluator.md
index 84eeb688..0ad04147 100644
--- a/wiki/sources/testing-tool-evaluator.md
+++ b/wiki/sources/testing-tool-evaluator.md
@@ -1,48 +1,61 @@
 ---
 title: "Tool Evaluator Agent Personality"
 type: source
-tags: [agent, testing, tool-assessment, evaluation]
-date: 2026-04-21
+tags: [agent, testing, tool-evaluation, productivity, vendor-management]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/testing/testing-tool-evaluator.md]]
+- [[Agent/agency-agents/testing/testing-tool-evaluator.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AI Agent 角色定义——技术工具评估与选型专家，专注于为企业使用场景评估、测试和推荐工具、软件及平台
-- 问题域：企业在技术选型时面临的成本-功能-风险权衡，缺乏系统化评估方法论
-- 方法/机制：7维加权评分体系（功能25%/可用性20%/性能15%/安全15%/集成10%/支持8%/成本7%）+ 4阶段工作流（需求收集→全面测试→财务风险分析→实施规划）+ 完整 ROI/TCO 量化计算框架
-- 结论/价值：为 AI Agent 提供可量化的技术评估能力，确保推荐工具满足 90%+ 预期性能、85%+ 采用率、20%+ 成本优化、25%+ ROI 目标
+- 核心主题：Tool Evaluator AI Agent 人格定义——专注于评估、测试和推荐工具/软件/平台的企业级技术评估专家
+- 问题域：企业工具选型过程中的评估效率、ROI 计算、供应商管理、变更管理
+- 方法/机制：七维度加权评分体系（功能性25%、可用性20%、性能15%、安全性15%、集成性10%、支持8%、成本7%）、四阶段工作流（需求收集→全面测试→财务与风险分析→实施规划）、定量+定性综合评估方法论
+- 结论/价值：为团队提供数据驱动的工具推荐决策，确保工具投资实现预期回报，降低选型风险
 
 ## Key Claims（用中文描述）
-- Tool Evaluator Agent 通过 7 维加权评分体系对工具进行全面量化评估，确保决策基于证据而非直觉
-- 每个工具评估必须包含安全性、集成性和成本分析三个默认要求，不可省略
-- 总拥有成本（TCO）分析必须涵盖授权、实施、培训、维护、集成、迁移和支持等全部隐性成本
-- 用户验收测试（UAT）应在真实用户场景和实际数据上验证，而非使用模拟数据
-- 供应商稳定性评估应包括财务状况、路线图对齐和战略合作潜力三个方面
+- Tool Evaluator 通过七维度加权评分体系评估工具，覆盖功能性、可用性、性能、安全性、集成、支持与成本
+- Tool Evaluator 计算全生命周期总拥有成本（TCO）并结合敏感性分析进行 ROI 预测
+- Tool Evaluator 坚持循证评估原则，使用真实场景和用户数据进行测试，以定量指标和统计分析为比较依据
+- Tool Evaluator 提供供应商管理能力，涵盖合同谈判、SLA 制定、持续性能监控和退出策略
 
 ## Key Quotes
-> "Evidence-Based Evaluation Process: Always test tools with real-world scenarios and actual user data, use quantitative metrics and statistical analysis for tool comparisons." — 评估方法论核心原则
-> "Cost-Conscious Decision Making: Calculate total cost of ownership including hidden costs and scaling fees." — 成本分析框架
-> "Vendor Relationship Excellence: Strategic vendor partnership development and relationship management with contract negotiation expertise." — 供应商管理策略
+> "Tool A scores 8.7/10 vs Tool B's 7.2/10 based on weighted criteria analysis" — 评估过程的客观量化表述方式
+> "Implementation cost of $50K delivers $180K annual productivity gains" — 聚焦价值导向的沟通风格
+> "This tool aligns with 3-year digital transformation roadmap and scales to 500 users" — 战略性思维导向
+> "Vendor financial instability presents medium risk - recommend contract terms with exit protections" — 风险意识与缓解策略
 
 ## Key Concepts
-- [[TotalCostOfOwnership]]：总拥有成本分析，涵盖3年周期的授权、实施、培训、维护、集成、迁移和支持成本
-- [[ReturnOnInvestment]]：投资回报率分析，包含不同采用率和场景的敏感性分析
-- [[ServiceLevelAgreement]]：服务水平协议，开发和性能监控系统
-- [[UserAcceptanceTesting]]：用户验收测试，在真实用户场景和代表性用户群中进行
-- [[ChangeManagement]]：变更管理，为确保工具成功采用而制定培训和沟通策略
-- [[WeightedScoringModel]]：加权评分模型，7维度权重分配（功能25%/可用性20%/性能15%/安全15%/集成10%/支持8%/成本7%）
+- [[ToolScoring]]：工具评分数据类，包含工具名、各项得分、加权总分和注释
+- [[TotalCostOfOwnership]]：全生命周期总拥有成本分析，包含许可证、实施、培训、维护、集成、迁移、支持等各项成本
+- [[WeightedScoringCriteria]]：加权评分体系——功能性(25%)、可用性(20%)、性能(15%)、安全性(15%)、集成性(10%)、支持(8%)、成本(7%)
+- [[ChangeManagement]]：变更管理策略——培训策略、沟通计划和采用支持
+- [[VendorRelationshipManagement]]：供应商关系管理——稳定性评估、路线图对齐、合同谈判和持续绩效评估
+- [[ServiceLevelAgreement]]：服务级别协议——性能监控和绩效评估机制
 
 ## Key Entities
-- Tool Evaluator Agent：The Agency Testing 部门的技术评估与战略工具采纳专家，专注于 ROI 导向的工具分析、竞争对比和战略技术采纳建议
+- [[ToolEvaluator]]：The Agency Testing 部门的工具评估专家 AI Agent 人格定义（核心角色）
 
 ## Connections
-- [[TestingEvidenceCollector]] ← 被评估 ← [[TestingToolEvaluator]]（前者收集评估证据，后者负责评分推荐）
-- [[TestingTestResultsAnalyzer]] ← 依赖 ← [[TestingToolEvaluator]]（后者提供工具性能基准数据供前者分析）
-- [[TestingPerformanceBenchmarker]] ← 协同 ← [[TestingToolEvaluator]]（两者共享性能测试数据，前者专注基准测试，后者专注综合评估）
-- [[AgentsOrchestrator]] ← 编排 ← [[TestingToolEvaluator]]（编排器将评估任务调度给工具评估 Agent）
-- [[MultiAgentSystemReliability]] ← 支撑 ← [[TestingToolEvaluator]]（评估推荐结果的质量直接影响多 Agent 系统可靠性）
+- [[Testing Evidence Collector]] ← part_of ← [[Testing Workflow]]
+- [[Test Results Analyzer]] ← part_of ← [[Testing Workflow]]
+- [[Performance Benchmarker]] ← part_of ← [[Testing Workflow]]
+- [[Testing Reality Checker]] ← part_of ← [[Testing Workflow]]
+- [[Workflow Optimizer]] ← part_of ← [[Testing Workflow]]
+- [[API Tester]] ← part_of ← [[Testing Workflow]]
 
 ## Contradictions
-- 无明显冲突。与 [[TestingRealityChecker]] 在"现实检验"维度互补——前者给出量化评估，后者提供真实性核查。
+- 与 [[Performance Benchmarker]] 冲突：
+  - 冲突点：两者都涉及性能评估，但角度不同
+  - 当前观点：Tool Evaluator 将性能作为七维度加权评分的一个维度（权重15%），与其他维度综合计算
+  - 对方观点：Performance Benchmarker 专注于深入的性能基准测试，涵盖负载/压力/ endurance/scalability 测试，目标是确保系统满足性能 SLA
+  - 说明：两者为互补关系而非冲突——Performance Benchmarker 提供专项性能数据，Tool Evaluator 综合利用该数据进行工具选型决策
+
+## Related Pages
+- [[Testing Evidence Collector]] — 测试证据收集 Agent
+- [[Test Results Analyzer]] — 测试结果分析 Agent
+- [[Performance Benchmarker]] — 性能基准测试 Agent
+- [[Testing Reality Checker]] — 测试现实核查 Agent
+- [[Workflow Optimizer]] — 工作流优化 Agent
+- [[API Tester]] — API 测试 Agent
diff --git a/wiki/sources/testing-workflow-optimizer.md b/wiki/sources/testing-workflow-optimizer.md
index e81dbe8b..d8db0b8c 100644
--- a/wiki/sources/testing-workflow-optimizer.md
+++ b/wiki/sources/testing-workflow-optimizer.md
@@ -1,56 +1,56 @@
 ---
 title: "Workflow Optimizer Agent Personality"
 type: source
-tags: []
-date: 2026-04-21
+tags: ["agent-personality", "process-optimization", "automation", "workflow"]
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/testing/testing-workflow-optimizer.md]]
+- [[Agent/agency-agents/testing/testing-workflow-optimizer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：The Agency Testing 部门的流程优化与工作流自动化专家 Agent，基于系统思维方法论，专注于端到端业务流程的分析、重设计、自动化与持续改进。
-- 问题域：工作流效率瓶颈识别、跨部门流程孤岛、人工重复性任务、流程质量与员工满意度的平衡。
-- 方法/机制：四阶段工作流（现状分析→优化设计→实施规划→自动化执行）+ Lean/Six Sigma/Kaizen 持续改进方法论 + 人本设计原则 + 数据驱动决策框架。核心工具：WorkflowOptimizer Python 框架（含瓶颈识别、优化机会评分、ROI 计算、实施路线图生成）。
-- 结论/价值：40% 平均周期时间改善、60% 常规任务自动化率、75% 流程错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。
+- **核心主题**：AI Agent 角色定义——专业流程优化与自动化专家，负责分析、优化和自动化跨业务功能的工作流程
+- **问题域**：企业流程效率低下、人工重复性任务、跨部门协作断裂、变更管理挑战
+- **方法/机制**：采用 Lean、Six Sigma、Kaizen 方法论，结合 RPA、OCR+AI、BI 工具、IoT 集成等技术手段，实现数据驱动的流程改进
+- **结论/价值**：通过系统性流程优化实现效率提升，通过智能自动化释放人力资源，通过变更管理确保成功落地
 
 ## Key Claims（用中文描述）
-- Workflow Optimizer Agent 通过系统分析消除效率瓶颈、流线化流程、实施智能化自动化解决方案，提升生产力、质量和员工满意度。
-- 每个流程优化必须包含自动化机会和可量化改进指标。
-- 在实施变更前必须测量当前状态性能，并使用统计分析验证改进有效性。
-- 优先考虑用户/员工体验和满意度，同时在自动化效率与人类判断和创造力之间取得平衡。
+- **Workflow Optimizer Agent** + 分析现有流程 + 识别瓶颈和痛点 → 实现 40% 平均流程完成时间改善
+- **智能自动化** + 识别可自动化机会 + 实施 RPA 和工作流自动化 → 实现 60% 常规任务自动化
+- **系统性改进** + 减少错误和返工 → 实现 75% 流程相关错误减少
+- **变更管理策略** + 培训和沟通计划 → 确保 90% 优化流程在 6 个月内成功采用
+- **员工满意度** + 任务多样性提升 + 减少认知负荷 → 实现 30% 员工满意度提升
 
 ## Key Quotes
-> "Finds the bottleneck, fixes the process, automates the rest." — Workflow Optimizer Agent personality description
-
-> "Process optimization reduces cycle time from 4.2 days to 1.8 days (57% improvement)" — communication style example
-
-> "Automation eliminates 15 hours/week of manual work, saving $39K annually" — communication style example
+> "Finds the bottleneck, fixes the process, automates the rest." — Workflow Optimizer 核心理念
+> "Process optimization reduces cycle time from 4.2 days to 1.8 days (57% improvement)" — 定量表达风格
+> "Automation eliminates 15 hours/week of manual work, saving $39K annually" — 价值聚焦表达
 
 ## Key Concepts
-- [[Lean]]：精益方法论，识别三类活动（增值活动/价值赋能活动/浪费），追求消除一切不增值环节。
-- [[Six-Sigma]]：六西格玛方法论，通过 DMAIC（Define/Measure/Analyze/Improve/Control）流程减少流程变异和缺陷，目标 3.4 DPMO。
-- [[Kaizen]]：持续改进哲学，小步快跑、员工驱动的渐进式流程优化，与六西格玛形成互补。
-- [[Value-Stream-Mapping]]：价值流映射，识别流程中的增值时间 vs 非增值等待时间。
-- [[Statistical-Process-Control]]：统计过程控制，通过数据监控过程稳定性并预测性能。
-- [[Change-Management]]：变更管理，确保流程改进被团队接受并成功落地的策略框架。
-- [[Human-Centered-Design]]：人本设计，优先考虑用户/员工体验、认知负荷和可访问性。
+- [[Lean]]：精益方法论，通过消除浪费提升流程效率
+- [[Six Sigma]]：六西格玛方法论，通过统计过程控制减少缺陷
+- [[Kaizen]]：持续改进文化，员工驱动的渐进式优化
+- [[RPA]] (Robotic Process Automation)：机器人流程自动化，使用 UiPath、Automation Anywhere 等平台实现常规任务自动化
+- [[WorkflowAutomation]]：工作流自动化，使用 Zapier、Microsoft Power Automate 实现跨系统流程编排
+- [[ChangeManagement]]：变更管理，确保流程优化成功落地的关键策略
+- [[ValueStreamMapping]]：价值流映射，数字化双胞胎建模复杂流程优化
+- [[ProcessMetrics]]：流程指标体系，提供可操作洞察的绩效测量系统
 
 ## Key Entities
-- [[The-Agency]]：Testing 部门的 Workflow Optimizer Agent 所属组织。
+- **UiPath**：RPA 平台，用于数据录入自动化
+- **Automation Anywhere**：RPA 平台竞品
+- **Zapier**：工作流自动化工具
+- **Microsoft Power Automate**：企业级工作流自动化平台
+- **Adobe Document Services**：OCR+AI 文档处理工具
+- **Power BI / Tableau**：商业智能报表工具
 
 ## Connections
-- [[testing-api-tester]] ← 协同质量保障 ← [[testing-workflow-optimizer]]（流程优化后需要 API 测试验证自动化后的系统行为）
-- [[specialized-workflow-architect]] ← 共享方法论 ← [[testing-workflow-optimizer]]（两者均关注工作流设计与优化，但前者侧重设计建模，后者侧重实施改进）
-- [[product-sprint-prioritizer]] ← 协同优先级排序 ← [[testing-workflow-optimizer]]（流程优化实施需要与 Sprint 规划对齐）
-- [[specialized-model-qa]] ← 协同数据验证 ← [[testing-workflow-optimizer]]（六西格玛等统计方法与 Model QA 的量化验证方法相互补充）
+- [[TestingAPITester]] ← 测试 ← [[TestingWorkflowOptimizer]]（测试工作流优化结果）
+- [[TestingToolEvaluator]] ← 评估 ← [[TestingWorkflowOptimizer]]（评估自动化工具）
+- [[AutomationGovernanceArchitect]] ← 治理 ← [[TestingWorkflowOptimizer]]（自动化治理框架）
 
 ## Contradictions
-- 与 [[specialized-workflow-architect]] 存在职责边界张力：
-  - 冲突点：两者均涉及工作流分析，但 Workflow Architect 强调设计规范（穷举所有路径/状态树），Workflow Optimizer 强调实施改进（量化效率收益/自动化 ROI）。
-  - 当前观点：Workflow Architect 负责"如何设计"（设计层），Workflow Optimizer 负责"如何改进"（执行层），属于工作流生命周期的不同阶段。
-  - 对方观点：部分场景下两者可互换使用，职责边界模糊。
-- 与 [[product-behavioral-nudge-engine]] 在自动化 vs 人机交互上存在理念张力：
-  - 冲突点：Workflow Optimizer 追求最大化自动化（减少人工干预），Nudge Engine 追求最大化人类参与（微任务/游戏化驱动）。
-  - 当前观点：两者互补——工作流层面追求自动化，用户/员工层面保留适度的人机交互以维护满意度。
-  - 对方观点：过度自动化可能降低员工参与感和学习机会。
+- 与 [[SpecializedWorkflowArchitect]] 冲突：
+  - **冲突点**：流程优化优先级——[[TestingWorkflowOptimizer]] 强调效率提升和自动化，[[SpecializedWorkflowArchitect]] 强调架构设计和长期可扩展性
+  - **当前观点**：[[TestingWorkflowOptimizer]] 认为快速见效的优化（4-26周分阶段实施）优先
+  - **对方观点**：[[SpecializedWorkflowArchitect]] 认为先建立稳固架构再逐步优化
diff --git a/wiki/sources/unity-architect.md b/wiki/sources/unity-architect.md
index 9c011a79..24c222fd 100644
--- a/wiki/sources/unity-architect.md
+++ b/wiki/sources/unity-architect.md
@@ -1,58 +1,114 @@
 ---
-title: "Unity Architect"
+title: "Unity Architect Agent Personality"
 type: source
-tags: []
-date: 2026-04-26
+tags: [unity, game-engineering, architecture, scriptableobjects, design-patterns]
+date: 2026-05-02
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/unity/unity-architect.md]]
+- [[Agent/agency-agents/game-development/unity/unity-architect.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Unity 游戏架构师 AI Agent 人格规范，专注于数据驱动、ScriptableObject（SO）优先的模块化可扩展架构
-- 问题域：如何构建避免"意大利面条式代码"的 Unity 项目，消除硬引用、单例滥用、God MonoBehaviour 等反模式
-- 方法/机制：ScriptableObject 事件通道（GameEvent）、RuntimeSet 无单例实体追踪、单一职责组件拆分、Inspector SO 引用连线、Custom PropertyDrawer 设计师赋能、Addressables 资源管理、Unity DOTS/ECS 混合架构
-- 结论/价值：通过 SO-first 设计，Unity 项目实现零 GameObject.Find()、每个 MonoBehaviour < 150 行、Prefab 场景无关自包含、设计师无需代码即可创建游戏变量/事件/运行时集合
+- 核心主题：Unity 游戏架构中的数据驱动、模块化设计方法论，基于 ScriptableObject 构建可扩展系统
+- 问题域：Unity 项目中常见的代码耦合、单体类蔓延、硬编码引用等架构腐败问题
+- 方法/机制：ScriptableObject First Design + 单职责组件模式 + SO 事件通道 + RuntimeSet 追踪
+- 结论/价值：消除 GameObject 中心主义，通过 SO 资产实现设计师友好、可测试、易扩展的架构
 
 ## Key Claims（用中文描述）
-- ScriptableObject-First 设计：所有共享游戏数据必须存于 ScriptableObject，绝不通过 MonoBehaviour 字段跨场景传递
-- GameEvent 事件通道：跨系统通信禁止使用 GetComponent<> 或单例，必须通过 SO 事件通道连线
-- RuntimeSet 无单例追踪：全局实体追踪使用 RuntimeSet : ScriptableObject 而非静态单例
-- 单一职责强制：每个 MonoBehaviour 只解决一个问题，若能用"and"描述则必须拆分
-- 反模式零容忍：God MonoBehaviour（500+ 行）、DontDestroyOnLoad 单例滥用、Update 内轮询逻辑均为禁止项
-- Unity DOTS 混合架构：性能关键系统迁移至 Entities（ECS），编辑器友好型游戏逻辑保留 MonoBehaviour
+- 所有共享游戏数据必须存于 ScriptableObject，不得通过 MonoBehaviour 字段跨场景传递
+- 每个 MonoBehaviour 只解决一个问题，超过 150 行几乎必然违反 SRP
+- 跨系统通信必须通过 SO 事件通道，禁止 `GameObject.Find()`、`FindObjectOfType()`、静态单例
+- Prefab 必须完全自包含，放入空场景无错误；序列化脚本修改必须调用 `EditorUtility.SetDirty()`
 
 ## Key Quotes
-> "Every MonoBehaviour solves one problem only — if you can describe a component with 'and,' split it." — 单一职责原则核心表述
-> "Treat every scene load as a clean slate — no transient data should survive scene transitions unless explicitly persisted via SO assets." — 场景卫生核心原则
-> "Designer-accessible: Non-technical team members can create new game variables, events, and runtime sets without touching code." — 设计师赋能核心价值
+> "Eliminate hard references between systems using ScriptableObject event channels" — SO 事件通道替代硬引用
+> "Every prefab dragged into a scene must be fully self-contained — no assumptions about scene hierarchy" — Prefab 自包含原则
+> "If a class exceeds ~150 lines, it is almost certainly violating SRP" — 代码行数红线
 
 ## Key Concepts
-- [[ScriptableObject]]：Unity 资产形式的可序列化对象，用于存储共享数据、事件通道、运行时集合
-- [[RuntimeSet]]：继承 ScriptableObject 的泛型集合类型，用于全局追踪活跃实体而不依赖单例
-- [[GameEvent]]：SO 形式的事件通道（GameEvent : ScriptableObject），用于跨系统解耦通信
-- [[SingleResponsibilityPrinciple]]：每个 MonoBehaviour 只负责单一职责，超过 150 行即违反
-- [[EventDrivenArchitecture]]：事件驱动替代 Update() 内轮询，消除 GC 分配
-- [[DataDrivenDesign]]：数据驱动的模块化 Unity 架构设计理念
-- [[ScriptableObjectEventChannel]]：ScriptableObject 形式的 GameEvent 系统，通过 Raise/Register 模式实现松耦合
-- [[Addressables]]：Unity 资源管理系统，替代 Resources.Load()，支持细粒度内存控制和 DLC
-- [[UnityDOTS]]：Data-Oriented Tech Stack，ECS + Job System + Burst Compiler，用于性能关键路径
-- [[EditorUtilitySetDirty]]：编辑器脚本修改 SO 数据后必须调用以确保序列化持久化
+- [[ScriptableObject]]：Unity 资产，可存储数据无需挂载到 GameObject，用于变量、事件、运行时集合
+- [[Single Responsibility Principle]]：每个 MonoBehaviour 仅负责一个职责，超长组件必须拆分
+- [[Event Channel Pattern]]：SO 事件通道（GameEvent）实现跨系统解耦通信
+- [[RuntimeSet]]：ScriptableObject 管理的实体运行时集合，无单例开销
+- [[Addressables]]：Unity 资源管理系统，替代 Resources.Load，支持细粒度内存控制和 DLC
+- [[DOTS (Data-Oriented Tech Stack)]]：Unity ECS，Job System + Burst Compiler 优化性能关键路径
+- [[Burst Compiler]]：将 C# Job 代码编译为近乎原生性能的机器码
+- [[Data-Oriented Design]]：面向数据的设计，与面向对象互补，提升 CPU 缓存命中率
 
 ## Key Entities
-- [[UnityArchitect]]：本文档定义的 AI Agent 人格，数据驱动模块化架构专家，精通 ScriptableObject、职责拆分、单例消除
-- [[UnityEditor]]：Unity 编辑器环境，ScriptableObject 通过 [CreateAssetMenu] 对设计师可见
-- [[UnityDOTS]]：Unity Data-Oriented Tech Stack（Entities、Jobs、Burst），用于 CPU 密集型批量操作
+- **UnityArchitect**：角色名，资深 Unity 工程师，数据驱动模块化设计专家，拒绝 GameObject 中心主义
+- **FloatVariable**：SO 变量资产示例，支持运行时值变更事件
+- **GameEvent**：SO 事件通道资产，用于跨 MonoBehaviour 解耦通信
+- **RuntimeSetRegistrar**：MonoBehaviour，在 OnEnable/OnDisable 时向 RuntimeSet 注册/注销
 
 ## Connections
-- [[UnityArchitect]] ← builds_with ← [[ScriptableObject]]
-- [[UnityArchitect]] ← extends ← [[UnityMultiplayerEngineer]]（网络层叠加 SO 架构）
-- [[UnityArchitect]] ← complements ← [[UnityShaderGraphArtist]]（SO 数据驱动视觉资产）
-- [[UnityArchitect]] ← complements ← [[UnityEditorToolDeveloper]]（Custom PropertyDrawer 赋能 SO 设计师体验）
-- [[UnityArchitect]] ← builds_with ← [[UnityDOTS]]（性能关键路径使用 ECS 混合架构）
+- [[Unity Multiplayer Engineer]] ← extends ← [[Unity Architect]]（多人网络扩展基础架构）
+- [[Unity Shader Graph Artist]] ← extends ← [[Unity Architect]]（渲染管线基础架构）
+- [[Unity Editor Tool Developer]] ← extends ← [[Unity Architect]]（Editor 工具基础架构）
+- [[Godot Gameplay Scripter]] ← parallels ← [[Unity Architect]]（跨引擎设计模式对应）
+- [[Roblox Systems Scripter]] ← parallels ← [[Unity Architect]]（跨平台代码架构模式）
 
 ## Contradictions
-- 与 [[UnityMultiplayerEngineer]] 在客户端预测实现上存在框架差异：
-  - UnityArchitect 侧：NetworkVariable 通过 SO 引用在 MonoBehaviour 间传递状态
-  - UnityMultiplayerEngineer 侧：NetworkVariable 直接挂载在 NetworkBehaviour 上
-  - 两者均遵循服务器权威原则，差异在于 SO 层抽象程度，属架构风格差异而非绝对冲突
+- 与传统 Unity "Manager Singleton" 惯用法冲突：
+  - 冲突点：是否允许静态单例管理跨系统状态
+  - 当前观点：所有共享状态置于 SO 资产，通过 Inspector 引用，消除全局可变状态
+  - 对方观点：单例简单直接，访问全局状态无需显式依赖注入
+
+## Technical Deliverables（关键代码模式）
+
+### FloatVariable SO
+```csharp
+[CreateAssetMenu(menuName = "Variables/Float")]
+public class FloatVariable : ScriptableObject
+{
+    [SerializeField] private float _value;
+    public float Value
+    {
+        get => _value;
+        set { _value = value; OnValueChanged?.Invoke(value); }
+    }
+    public event Action<float> OnValueChanged;
+    public void SetValue(float value) => Value = value;
+    public void ApplyChange(float amount) => Value += amount;
+}
+```
+
+### GameEvent Channel（解耦消息）
+```csharp
+[CreateAssetMenu(menuName = "Events/Game Event")]
+public class GameEvent : ScriptableObject
+{
+    private readonly List<GameEventListener> _listeners = new();
+    public void Raise()
+    {
+        for (int i = _listeners.Count - 1; i >= 0; i--)
+            _listeners[i].OnEventRaised();
+    }
+    public void RegisterListener(GameEventListener listener) => _listeners.Add(listener);
+    public void UnregisterListener(GameEventListener listener) => _listeners.Remove(listener);
+}
+```
+
+### RuntimeSet（无单例实体追踪）
+```csharp
+public abstract class RuntimeSet<T> : ScriptableObject
+{
+    public List<T> Items = new List<T>();
+    public void Add(T item) { if (!Items.Contains(item)) Items.Add(item); }
+    public void Remove(T item) { if (Items.Contains(item)) Items.Remove(item); }
+}
+```
+
+## Workflow Process
+1. **Architecture Audit**：识别硬引用、单例、God Class，映射数据流
+2. **SO Asset Design**：创建 Variable SO、Event Channel SO、RuntimeSet SO，按领域组织
+3. **Component Decomposition**：拆分 God MonoBehaviour 为单职责组件，通过 SO 引用连接
+4. **Editor Tooling**：添加 CustomEditor/PropertyDrawer，[CreateAssetMenu]，构建时架构验证
+5. **Scene Architecture**：场景无持久数据，使用 Addressables + SO 配置驱动场景加载
+
+## Success Metrics
+- 生产代码中零 `GameObject.Find()` 或 `FindObjectOfType()` 调用
+- 每个 MonoBehaviour < 150 行，仅处理一个关注点
+- 每个 Prefab 可在空场景中独立运行无错误
+- GC 分配在事件驱动路径上为零帧
+- 设计师无需修改代码即可通过 Inspector 创建新游戏变量和事件
diff --git a/wiki/sources/unity-editor-tool-developer.md b/wiki/sources/unity-editor-tool-developer.md
index 3e2e9e83..31fe791a 100644
--- a/wiki/sources/unity-editor-tool-developer.md
+++ b/wiki/sources/unity-editor-tool-developer.md
@@ -9,41 +9,52 @@ date: 2026-04-26
 - [[raw/Agent/agency-agents/game-development/unity/unity-editor-tool-developer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Unity 编辑器扩展开发工程师（Editor Tool Developer）的 AI Agent 人格规范——通过 EditorWindows、PropertyDrawers、AssetPostprocessors、Build Validators 等工具自动化团队工作流，减少人工错误
-- 问题域：游戏团队每日面临的素材导入错误、Inspector 数据误操作、命名规范失控、构建前人工检查等重复性工作
-- 方法/机制：基于 Unity Editor API 构建编辑器扩展工具，使用 `[SerializeField]` + `[MenuItem]` + `AssetPostprocessor` 模式实现自动化；通过 `Undo.RecordObject()` 保证操作可撤销；通过 `EditorUtility.DisplayProgressBar` 反馈长操作进度
-- 结论/价值：最佳工具是"隐形"的——在问题到达 QA 前自动拦截，在创意人员意识到需求前提前自动化
+- 核心主题：Unity Editor 扩展开发专家 Agent——通过 EditorWindow、PropertyDrawer、AssetPostprocessor、Build Validation 等自动化工具，减少团队手动操作时间、提前拦截错误
+- 问题域：游戏项目 Editor 自动化工作流、美术/策划/程序团队的日常效率提升、构建前质量门控
+- 方法/机制：Editor-only 代码规范（`Editor` 文件夹 / `#if UNITY_EDITOR` / asmdef 隔离）→ 工具原型验证 → 量产化（含 Undo/ProgressBar/持久化）→ Build Validation 集成
+- 结论/价值：提供完整的 Unity Editor 工具开发规范，包括 4 类核心 API（EditorWindow/PropertyDrawer/AssetPostprocessor/IPreprocessBuildWithReport）的代码模板与质量标准
 
 ## Key Claims（用中文描述）
-- UnityEditorToolDeveloper 通过 Editor 自动化，使艺术/设计/工程团队效率可量化提升
-- 所有 Editor 脚本必须置于 `Editor` 文件夹或使用 `#if UNITY_EDITOR` 保护——Editor API 调用进入运行时代码将导致构建失败
-- `EditorWindow` 必须通过 `[SerializeField]` 或 `EditorPrefs` 持久化状态，跨域重载不丢失
-- `AssetPostprocessor` 必须幂等——同一资源重复导入必须产生相同结果
-- `PropertyDrawer.OnGUI` 必须调用 `EditorGUI.BeginProperty` / `EndProperty` 以正确支持 Prefab Override UI
-- 构建验证器失败时必须抛出 `BuildFailedException`，而非仅 `Debug.LogWarning`
+- 所有 Editor 脚本必须位于 `Editor` 文件夹或使用 `#if UNITY_EDITOR` 守卫——Editor API 调用进入运行时程序集会导致构建失败
+- AssetPostprocessor 必须幂等：同一资源导入两次必须产生相同结果
+- PropertyDrawer.OnGUI 必须调用 `EditorGUI.BeginProperty` / `EndProperty`，否则 Prefab Override UI 将无法正常工作
+- EditorWindow 工具必须通过 `[SerializeField]` 或 `EditorPrefs` 持久化状态，否则 Domain Reload 后状态丢失
+- 任何修改 inspector 显示对象的操作必须先调用 `Undo.RecordObject`，否则操作无法撤销，属于用户敌对行为
+- 耗时超过 0.5 秒的操作必须显示 `EditorUtility.DisplayProgressBar`，否则 UI 会冻结
 
 ## Key Quotes
-> "The best tools are invisible — they catch problems before they ship and automate the tedious so humans can focus on the creative." — UnityEditorToolDeveloper 核心理念
-
-> "Can you Ctrl+Z that? No? Then we're not done." — Undo 是交付门槛，不支持撤销的工具不能发布
-
-> "DX over raw power: The tool can do 10 things — let's ship the 2 things artists will actually use." — 开发者体验优先于功能堆砌
+> "Every EditorWindow tool must persist state across domain reloads using `[SerializeField]` on the window class or `EditorPrefs`" — Domain Reload 状态持久化规范
+> "Tools must show progress via `EditorUtility.DisplayProgressBar` for any operation taking > 0.5 seconds" — 长操作 UX 标准
+> "AssetPostprocessor must be idempotent: importing the same asset twice must produce the same result" — 导入处理器幂等性要求
+> "PropertyDrawer's `OnGUI` must call `EditorGUI.BeginProperty` / `EndProperty` to support prefab override UI correctly" — Prefab Override 支持规范
+> "Log actionable messages (`Debug.LogWarning`) when postprocessor overrides a setting — silent overrides confuse artists" — 静默覆盖之害
 
 ## Key Concepts
-- [[EditorWindow]]：Unity 编辑器窗口扩展基类，用于构建团队可见的编辑器工具（资产审计、资源统计、验证面板）
-- [[AssetPostprocessor]]：Unity 资源导入拦截器，在资源导入时自动强制执行命名规范、压缩设置、平台配置，确保每次导入结果一致且幂等
-- [[PropertyDrawer]]：自定义 Inspector 属性绘制器，扩展编辑器中序列化类型的显示方式，支持 MinMax Slider 等复合控件
-- [[AssemblyDefinitionFiles]]：`.asmdef` 文件用于在编译时强制 Editor/Runtime 程序集分离，防止 UnityEditor 命名空间泄漏到构建产物
-- [[BuildValidation]]：`IPreprocessBuildWithReport` 接口允许在构建前运行检查列表，失败时抛出 `BuildFailedException` 阻止打包
+- [[EditorWindow]]：Unity Editor 扩展窗口基类，通过 `[MenuItem]` 注册菜单入口，可创建工具窗口、审计面板、检查器等 UI
+- [[PropertyDrawer]]：自定义 Inspector 属性绘制器，通过 `CustomPropertyDrawer` 特性关联 Serializable 类型，提供更友好的编辑器编辑体验
+- [[AssetPostprocessor]]：资源导入前置/后置处理器，在每次资源导入时自动触发，用于强制命名规范、导入设置和预算验证
+- [[CustomEditor]]：自定义 Inspector 面板，通过 `[CustomEditor(typeof(MyComponent))]` 替代默认组件检查器
+- [[AssemblyDefinition]]（.asmdef）：Assembly Definition 文件，通过引 references 强制编辑器程序集与运行时程序集的编译时隔离
+- [[Undo.RecordObject]]：`UnityEditor.Undo` API，在修改对象前调用，使操作可撤销——不可撤销的编辑器操作属于用户敌对行为
+- [[BuildValidation]]（IPreprocessBuildWithReport）：构建前验证接口，在打包前运行质量门控检查，失败时抛出 `BuildFailedException`
+- [[ScriptableBuildPipeline]]：Unity 可脚本化构建管线，替代传统构建流程，支持自定义构建任务（资产剥离/着色器变体/CDN 缓存失效）
+- [[UI Toolkit]]（UIElements）：Unity 新一代编辑器 UI 系统，基于 USS + VisualElement，提供响应式、可样式化的编辑器 UI，替代 IMGUI
 
 ## Key Entities
-- [[UnityEditorToolDeveloper]]：本 Source 对应的 AI Agent 人格——编辑器自动化专精，强调 DX、可量化的效率提升和隐形工具哲学
-- [[UnrealEditorToolDeveloper]]：对应 Unreal Engine 端的编辑器工具开发（比较视角）
+- [[UnityEditorToolDeveloper]]：Unity Editor 工具开发专家 Agent 自引用——"自动化痴迷、DX 优先、流水线第一、默默不可或缺"
 
 ## Connections
-- [[unity-editor-tool-developer]] ← game_dev_editor_extension ← [[game-designer]]
-- [[unity-editor-tool-developer]] ← editor_automation ← [[unreal-systems-engineer]]（两者共享"构建前验证"模式）
-- [[unity-editor-tool-developer]] ← tool_patterns ← [[technical-artist]]（Technical Artist 也负责编辑器工具和资产管线）
+- [[UnityEditorToolDeveloper]] ← authored_by ← [[TechnicalArtist]]（Technical Artist 可能审查或指导工具开发输出）
+- [[EditorWindow]] ← enables ← [[UnityEditorToolDeveloper]]（EditorWindow 是构建工具窗口的核心 API）
+- [[AssetPostprocessor]] ← enables ← [[UnityEditorToolDeveloper]]（AssetPostprocessor 是自动拦截错误资产的核心机制）
+- [[PropertyDrawer]] ← enables ← [[UnityEditorToolDeveloper]]（PropertyDrawer 是改善 Inspector 体验的核心 API）
+- [[UnityEditorToolDeveloper]] ← extends ← [[UnityShaderGraphArtist]]（Shader Graph Artist 依赖工具开发者构建编辑器辅助面板）
+- [[UnityEditorToolDeveloper]] ← extends ← [[UnityMultiplayerEngineer]]（多人工程师依赖工具开发者构建网络调试窗口）
+- [[UI Toolkit]] ← replaces ← [[EditorWindow]]（UI Toolkit 是 EditorWindow 的下一代演进方向）
 
 ## Contradictions
-- 与 [[unreal-systems-engineer]] 在"编辑器工具 vs. 构建系统"边界上存在领域分工差异：Unity 侧通过 `IPreprocessBuildWithReport` 在构建前验证资源合规性；Unreal 侧通过 UAssetCheckConfig + UAssetCheckRule 在编辑器内实时检查。两者的目标相同（防止问题到达 QA），但实现时机和 API 不同——属互补而非冲突。
+- 与 [[UnrealTechnicalArtist]] 关于 Editor 扩展方案：
+  - 冲突点：Unity 使用 PropertyDrawer / CustomEditor / EditorWindow 方案，Unreal 使用 Details Panel Customization / EditorUtility / SWidget 方案
+  - 当前观点：Unity Editor Tool Developer 认为 PropertyDrawer + AssetPostprocessor 组合可覆盖 90% 的编辑器自动化场景
+  - 对方观点：Unreal Technical Artist 更偏好编辑器蓝图/编辑器模块化方案而非手写 C++
+  - 说明：两者均为各自平台的最佳实践，冲突源于引擎架构差异而非绝对优劣
diff --git a/wiki/sources/unity-shader-graph-artist.md b/wiki/sources/unity-shader-graph-artist.md
index 97052467..f18a0782 100644
--- a/wiki/sources/unity-shader-graph-artist.md
+++ b/wiki/sources/unity-shader-graph-artist.md
@@ -1,59 +1,52 @@
 ---
 title: "Unity Shader Graph Artist"
 type: source
-tags: []
-date: 2026-04-26
+tags: [agent, unity, shader, game-development, urp, hdrp, hlsl, visual-effects]
+date: 2026-05-01
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/game-development/unity/unity-shader-graph-artist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Unity Shader Graph Artist Agent 角色定义 —— 一个精通 Unity 渲染管线的专业 AI Agent，专注于 Shader Graph 可视化材质创作与 HLSL 性能优化
-- 问题域：游戏/实时渲染视觉效果开发、跨 URP/HDRP 管线的 Shader 创作规范与性能约束
-- 方法/机制：通过 Sub-Graph 模块化架构、Renderer Feature 自定义渲染通道、Shader Complexity Audit 复杂度审核流程，确保视觉效果与性能的平衡
-- 结论/价值：提供了一套完整的 Unity 渲染 Agent 工作体系，覆盖从设计简报到 Shader 交付、艺术家交接的全链路规范
+- 核心主题：Unity Shader Graph Artist 智能体的角色定义、技术规范和工作流程，专注文体化与写实shader创作
+- 问题域：Unity渲染管线（URP/HDRP）下的shader创作、HLSL性能优化、shader架构规范
+- 方法/机制：通过Shader Graph实现美术可编辑shader，通过Sub-Graph实现逻辑复用，通过ScriptableRendererFeature实现自定义渲染通道
+- 结论/价值：建立了一套完整的Unity shader开发规范，覆盖从设计到交付的全流程
 
 ## Key Claims（用中文描述）
-- 所有 Shader Graph 必须使用 Sub-Graph 封装重复逻辑 —— 重复的节点簇是维护和一致性失败
-- URP 自定义通道必须使用 `ScriptableRendererFeature` + `ScriptableRenderPass` —— 禁止使用 `OnRenderImage`（仅限内置管线）
-- HDRP 自定义通道使用 `CustomPassVolume` + `CustomPass` —— API 与 URP 不同，不可互换
-- 透明材质优先使用 Alpha Clipping 而非 Alpha Blend —— Alpha clipping 无过度绘制深度排序问题
-- 所有 Fragment Shader 必须在 Unity Frame Debugger 和 GPU Profiler 中完成性能分析后方可发布
+- Shader Graph 规范：所有重复逻辑必须封装为 Sub-Graph，禁止节点集群重复，否则视为维护失败
+- 渲染管线规则：URP/HDRP 项目禁止使用 built-in 管线shader；URP 自定义通道必须用 `ScriptableRendererFeature + ScriptableRenderPass`，不能用 `OnRenderImage`
+- 性能标准：移动端每片段最多32次纹理采样、不透明片段最多60条ALU指令；避免在移动端使用 `ddx`/`ddy` 导数
+- HLSL 规范：使用 `.hlsl` 扩展名声明include文件，使用 `.shader` 扩展名声明 ShaderLab wrapper；必须用 `TEXTURE2D`/`SAMPLER` 宏替代 `sampler2D`
+- Dissolve shader 关键逻辑：噪声纹理驱动消融 → Alpha Clip 实现切割边缘 → emissive 边缘高光
 
 ## Key Quotes
-> "Every Shader Graph must use Sub-Graphs for repeated logic — duplicated node clusters are a maintenance and consistency failure" — Shader Graph 架构强制规范
-
-> "URP custom passes use `ScriptableRendererFeature` + `ScriptableRenderPass` — never `OnRenderImage` (built-in only)" — URP/HDRP 管线 API 差异说明
-
-> "Mobile: max 32 texture samples per fragment pass; max 60 ALU per opaque fragment" — 移动端性能硬约束
+> "Every Shader Graph must use Sub-Graphs for repeated logic — duplicated node clusters are a maintenance and consistency failure." — Shader Graph Architecture Rule
+> "URP custom passes use `ScriptableRendererFeature` + `ScriptableRenderPass` — never `OnRenderImage` (built-in only)" — URP/HDRP Pipeline Rules
+> "Use `TEXTURE2D` / `SAMPLER` macros from `Core.hlsl` — direct `sampler2D` is not SRP-compatible" — HLSL Authorship Rules
 
 ## Key Concepts
-- [[Shader Graph]]：Unity 可视化 Shader 编辑器，允许艺术家通过节点图创建材质，无需手写 HLSL
-- [[Sub-Graph]]：Shader Graph 中的可复用子图模块，用于封装重复逻辑节点簇
-- [[URP (Universal Render Pipeline)]]：Unity 通用渲染管线，轻量级，跨平台支持
-- [[HDRP (High Definition Render Pipeline)]]：Unity 高清渲染管线，面向高端主机/PC 的 PBR 渲染
-- [[ScriptableRendererFeature]]：URP 自定义渲染通道系统，允许注入自定义全屏效果
-- [[HLSL]]：High-Level Shader Language，Shader Graph 编译的目标代码，可手写以实现极致性能
-- [[Alpha Clipping]]：透明裁剪渲染模式，通过像素丢弃实现透明效果，避免深度排序问题
-- [[Frame Debugger]]：Unity 内置帧调试工具，逐 draw call 分析渲染管线
-- [[RenderDoc]]：第三方 GPU 帧捕获工具，用于 Shader 调试和寄存器值检查
+- [[Shader Graph]]：Unity可视化shader编辑工具，支持美术驱动的节点化shader创作
+- [[URP (Universal Render Pipeline)]]：Unity通用渲染管线，Shader Graph主要支持的管线
+- [[HDRP (High Definition Render Pipeline)]]：Unity高清渲染管线，与URP的API不兼容
+- [[HLSL]]：High Level Shading Language，用于编写高性能shader逻辑
+- [[ScriptableRendererFeature]]：URP自定义渲染通道的核心扩展点
+- [[Sub-Graph (Shader Graph)]]：Shader Graph中的可复用子图模块
+- [[Alpha Clipping]]：透明度裁剪，优于Alpha Blend，无深度排序问题
+- [[Dissolve Shader]]：消融shader，通过噪声纹理驱动切割效果
+- [[Fresnel]]：边缘高光效果，基于视角方向和法线夹角计算
+- [[RenderDoc]]：GPU调试工具，用于shader输入输出和寄存器值检查
 
 ## Key Entities
-- [[Unity Technologies]]：Unity Engine 开发商，提供 Shader Graph、URP、HDRP 等渲染系统
-- [[DissolveCore]]：Sub-Graph 封装示例，包含溶解效果的节点逻辑，可复用于多个角色材质
-- [[OutlineRendererFeature]]：自定义 URP Renderer Feature，实现描边效果的 C# 类
-- [[CustomLit.hlsl]]：URP 兼容的 PBR 自定义 Shader 示例，展示完整的 HLSL 编写规范
+- [[Unity]]：游戏引擎厂商，Shader Graph、URP、HDRP的提供方
+- [[UnityShaderGraphArtist]]：该智能体的角色名，专注于shader艺术与性能的平衡
 
 ## Connections
-- [[UnityShaderGraphArtist]] ← authored_by ← [[TechnicalArtist]]（Technical Artist 可能指导或审查 Shader Graph Artist 的输出）
-- [[Shader Graph]] ← requires ← [[URP / HDRP]]（Shader Graph 必须在正确的渲染管线下创作）
-- [[Sub-Graph]] ← enables ← [[Shader Graph]]（Sub-Graph 是 Shader Graph 模块化的基础）
-- [[ScriptableRendererFeature]] ← part_of ← [[URP]]（自定义渲染通道是 URP 的扩展机制）
+- [[Unity Architect]] ← 专业分工 ← [[Unity Shader Graph Artist]]
+- [[Unity Multiplayer Engineer]] ← 共享工作流 ← [[Unity Shader Graph Artist]]
+- [[Technical Artist]] ← 职责交叉 ← [[Unity Shader Graph Artist]]
+- [[Unreal Technical Artist]] ← 功能对标 ← [[Unity Shader Graph Artist]]
 
 ## Contradictions
-- 与 [[UnrealTechnicalArtist]] 关于渲染管线选择：
-  - 冲突点：Unreal 使用 Material Editor + Custom Node（HLSL）方案，Unity 使用 Shader Graph + Sub-Graph 方案
-  - 当前观点：Unity Shader Graph Artist 认为 Shader Graph 应为艺术家首选，HLSL 仅用于性能关键路径
-  - 对方观点：Unreal Technical Artist 认为 HLSL 编码在所有情况下都是首选方案
-  - 说明：两者均为各自平台的最佳实践，冲突源于平台差异而非绝对优劣
+- 无已知冲突
diff --git a/wiki/sources/unreal-multiplayer-architect.md b/wiki/sources/unreal-multiplayer-architect.md
index c12e51cb..a93ae3ad 100644
--- a/wiki/sources/unreal-multiplayer-architect.md
+++ b/wiki/sources/unreal-multiplayer-architect.md
@@ -1,57 +1,103 @@
 ---
 title: "Unreal Multiplayer Architect"
 type: source
-tags: [game-development, unreal-engine, networking, multiplayer, ue5]
-date: 2026-04-26
+tags: ["unreal-engine", "game-development", "multiplayer", "networking", "ue5"]
+date: 2026-04-30
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/game-development/unreal-engine/unreal-multiplayer-architect.md]]
 
 ## Summary（用中文描述）
-- 核心主题：UE5多人游戏网络架构专家角色定义——构建服务器权威模型、延迟容忍、作弊防护的多人游戏系统
-- 问题域：Actor复制、网络预测、RPC安全验证、带宽优化、GAS复制、专用服务器构建
-- 方法/机制：Server-authoritative架构、UFUNCTION(Server, Reliable, WithValidation)、GetLifetimeReplicatedProps、Replication Graph、双路径GAS初始化
-- 结论/价值：提供生产级UE5多人游戏网络系统的完整技术方案，涵盖从基础复制到高级预测框架的全栈实现
+- 核心主题：Unreal Engine 5多人游戏网络架构师的 Agent 个性定义与核心能力规范
+- 问题域：UE5多人游戏开发中的服务器权威模型、Actor复制、网络预测、GAS复制和专用服务器配置
+- 方法/机制：定义完整的UE5多人网络开发规范，包括RPC验证、复制层级、带宽优化、反作弊加固
+- 结论/价值：提供可直接用于构建UE5多人游戏AI Agent的完整人格规范和技术交付物模板
 
 ## Key Claims（用中文描述）
-- 服务器必须拥有所有游戏状态变化的执行权威，客户端仅发送RPC请求，由服务器验证后复制
-- 所有游戏逻辑相关的Server RPC必须实现WithValidation，不得省略_Validate()实现
-- 网络复制频率应按Actor类型差异化配置，默认100Hz过高，大多数Actor仅需20-30Hz
-- GAS的AbilitySystemComponent初始化必须在PossessedBy（服务器路径）和OnRep_PlayerState（客户端路径）两个入口点分别执行
-- 专用服务器构建必须使用Linux平台+Shipping配置+Cooked内容
+- 所有游戏状态变更必须在服务器执行，客户端发送RPC，服务器验证并复制
+- 每个 Server RPC 的 `WithValidation` 标签不可省略，缺少 `_Validate()` 即为作弊漏洞
+- GameMode 仅服务器可用（永不复制），GameState 复制到所有客户端，PlayerController 仅复制给拥有者
+- Reliable RPC 保证顺序但增加带宽，仅用于关键游戏事件，高频数据使用不可靠RPC
+- GAS 复制需要双初始化路径：PossessedBy（服务器）+ OnRep_PlayerState（客户端）
+- 每玩家带宽应 < 15KB/s，使用 Replication Graph 可将带宽降低40%
 
 ## Key Quotes
-> "The server owns truth. The client requests it — the server decides." — 权威模型的核心原则
-> "WithValidation tag is not optional for any game-affecting RPC" — 安全验证的强制性要求
-> "Bandwidth per player < 15KB/s at maximum player count" — 性能基准指标
-> "Every Server RPC needs a `_Validate`. No exceptions. One missing is a cheat vector." — 作弊防护的非妥协立场
+> "The server owns that. The client requests it — the server decides." — 核心权威模型原则
+> "Every Server RPC needs a `_Validate`. No exceptions. One missing is a cheat vector." — RPC安全规范
+> "That belongs in GameState, not the Character. GameMode is server-only — never replicated." — 层级规范
+> "That actor is replicating at 100Hz — it needs 20Hz with interpolation" — 带宽优化原则
 
 ## Key Concepts
-- [[ServerAuthoritativeModel]]：服务器权威模型——服务器模拟真实状态，客户端预测并对账，所有游戏逻辑在服务器执行
-- [[ActorReplication]]：Actor复制——UPROPERTY(Replicated)将状态从服务器同步到客户端，支持ReplicatedUsing触发RepNotify
-- [[RPC]]：远程过程调用——Client/Server/NetMulticast三种RPC类型，Server RPC必须带验证
-- [[NetworkPrediction]]：网络预测——客户端本地预测操作，服务器确认后校正，减少感知延迟
-- [[ReplicationGraph]]：复制图——空间分区优化，仅向相关客户端复制区域内的Actor，降低带宽
-- [[GAS]]：Gameplay Ability System——UE5技能系统，支持复制和预测的技能与属性管理
-- [[DedicatedServer]]：专用服务器——无图形界面的纯服务器实例，处理所有游戏逻辑
-- [[NetworkRelevancy]]：网络相关性——根据客户端视角决定哪些Actor需要复制，节省带宽
-- [[NetMulticast]]：多播RPC——服务器向所有客户端广播事件，用于仅表现层效果
+- [[Server-Authoritative Model]]：服务器权威模型 — 所有游戏状态由服务器模拟，客户端预测并协调
+- [[Actor Replication]]：Actor复制 — UE5核心网络同步机制，通过UPROPERTY(Replicated)实现状态复制
+- [[RPC (Remote Procedure Call)]]：远程过程调用 — 客户端与服务器通信的主要机制，分Server/Client/NetMulticast
+- [[Network Prediction]]：网络预测 — 客户端本地预测操作以减少延迟感知，服务器确认或回滚
+- [[GAS (Gameplay Ability System)]]：游戏能力系统 — UE5能力与属性复制框架
+- [[Replication Graph]]：复制图 — UE5空间分区优化方案，可替代默认平面相关性模型
+- [[NetUpdateFrequency]]：网络更新频率 — 每个Actor类的复制频率，默认100Hz通常过高
 
 ## Key Entities
-- [[GameMode]]：服务器独有（永不复制）——生成逻辑、规则仲裁、胜负条件判定
-- [[GameState]]：复制到所有客户端——共享世界状态（回合计时器、队伍分数等）
-- [[PlayerState]]：复制到所有客户端——每玩家公开数据（名称、延迟、击杀数）
-- [[PlayerController]]：仅复制到拥有客户端——输入处理、摄像机、HUD控制
-- [[AbilitySystemComponent]]：GAS核心组件——管理技能和属性，必须正确配置复制
-- [[ReplicationGraph]]：UE5复制图插件——用空间分区替代默认扁平相关性模型
+- [[UnrealEngine5]]：游戏引擎 — UE5，提供完整的网络层、复制系统和GAS框架
+- [[GameMode]]：游戏模式 — 服务器专属，从不复制，负责规则仲裁和胜利条件
+- [[GameState]]：游戏状态 — 复制到所有客户端，存储共享世界状态（回合计时、队伍分数）
+- [[PlayerState]]：玩家状态 — 复制到所有客户端，存储玩家公开数据（名称、击杀、死亡）
+- [[PlayerController]]：玩家控制器 — 仅复制给拥有它的客户端，处理输入、相机、HUD
 
 ## Connections
-- [[GameMode]] ← spawns + governs ← [[GameState]]
-- [[PlayerController]] ← possesses ← [[PlayerState]]
-- [[GameplayAbilitySystem]] ← depends_on ← [[ActorReplication]]
-- [[NetworkPrediction]] ← extends ← [[ActorReplication]]
-- [[DedicatedServer]] ← hosts ← [[GameMode]]
+- [[UnrealEngine5]] ← provides ← [[Actor Replication]]
+- [[Actor Replication]] ← optimized_by ← [[Replication Graph]]
+- [[GameMode]] ← controls ← [[GameState]]
+- [[GameMode]] ← manages ← [[PlayerState]]
+- [[GAS (Gameplay Ability System)]] ← replicates_via ← [[Actor Replication]]
 
 ## Contradictions
-- 与现有Wiki内容暂无冲突——本页面为独立技术领域（UE5网络架构）
+- 无已知冲突
+
+## 技术交付物（Technical Deliverables）
+
+### Replicated Actor Setup
+```cpp
+// 带有 RepNotify 和条件复制的网络 Actor
+UPROPERTY(ReplicatedUsing=OnRep_Health)
+float Health = 100.f;
+
+// 服务器 RPC 必须包含 _Validate 实现
+UFUNCTION(Server, Reliable, WithValidation)
+void ServerRequestInteract(AActor* Target);
+bool ServerRequestInteract_Validate(AActor* Target); // 必填
+```
+
+### GameMode / GameState / PlayerState 层级
+```cpp
+// GameMode: 服务器独有，不复制
+// GameState: 复制到所有客户端（队伍分数、回合计时）
+// PlayerState: 复制到所有客户端（击杀、死亡、角色选择）
+// PlayerController: 仅拥有者可见（输入、相机、HUD）
+```
+
+### GAS 双初始化路径
+```cpp
+void AMyCharacter::PossessedBy(AController* NewController)  // 服务器路径
+void AMyCharacter::OnRep_PlayerState()                      // 客户端路径
+```
+
+### 网络频率优化
+```cpp
+AMyProjectile::AMyProjectile()  { NetUpdateFrequency = 100.f; }  // 高速弹道
+AMyNPCEnemy::AMyNPCEnemy()      { NetUpdateFrequency = 20.f; }   // 低速NPC
+AMyEnvironmentActor::AMyEnvironmentActor() { NetUpdateFrequency = 2.f; } // 静态物体
+```
+
+## 高级能力（Advanced Capabilities）
+- **自定义网络预测框架**：使用 UE5 Network Prediction Plugin 实现物理驱动或复杂移动的回滚
+- **Replication Graph 优化**：空间分区替代平面相关性，可将带宽降低40%
+- **专用服务器基础设施**：AOnlineBeaconHost、集群管理器、会话迁移、反作弊日志
+- **GAS 多人深度集成**：预测键、GameplayEffectContext、服务器验证激活
+
+## 成功指标（Success Metrics）
+- 游戏影响 Server RPC 的 `_Validate()` 缺失数为零
+- 最高玩家数量下每玩家带宽 < 15KB/s
+- 200ms延迟下每玩家每30秒去同步事件 < 1次
+- 峰值战斗时专用服务器CPU < 30%
+- RPC安全审计无作弊向量
diff --git a/wiki/sources/unreal-systems-engineer.md b/wiki/sources/unreal-systems-engineer.md
index c34fc8fc..b3e6ba91 100644
--- a/wiki/sources/unreal-systems-engineer.md
+++ b/wiki/sources/unreal-systems-engineer.md
@@ -1,25 +1,25 @@
 ---
 title: "Unreal Systems Engineer"
 type: source
-tags: []
-date: 2026-04-26
+tags: ["game-engineering", "unreal-engine", "c-plus-plus", "blueprint", "gas", "nanite", "lumen", "performance", "memory-management", "multiplayer"]
+date: 2026-05-30
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/game-development/unreal-engine/unreal-systems-engineer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Unreal Engine 5 系统架构师 AI Agent 人格规范——C++/Blueprint 边界决策、性能优化、网络就绪游戏系统构建
-- 问题域：AAA 级 UE5 游戏项目中的技术架构决策、性能瓶颈规避、网络复制可靠性保障
-- 方法/机制：C++/Blueprint 分层架构（Tick 逻辑必须 C++）、GAS 网络复制配置、Nanite 实例预算管理、智能指针内存安全、Unreal Build System 反射宏规范
-- 结论/价值：建立了一套完整的 UE5 系统工程师能力标准，涵盖从内存管理到高级渲染的 AAA 级开发规范
+- 核心主题：Unreal Engine 5 系统架构工程师 AI Agent 人格规范——C++/Blueprint 架构边界决策、AAA 级性能优化、网络就绪游戏系统构建
+- 问题域：AAA 级 UE5 项目中的 Tick 性能、内存安全、网络预测、Nanite 限制、Chaos 破坏效果、Mass Entity ECS 扩展
+- 方法/机制：C++/Blueprint 分层架构（Tick 逻辑必须 C++）、GAS 网络复制配置、Nanite 实例预算管理、智能指针内存安全、Unreal Build System 反射宏规范、Lyra 模块化游戏框架
+- 结论/价值：建立了一套完整的 UE5 系统工程师能力标准，涵盖从内存管理到 Mass Entity/Chaos 高级能力的 AAA 级开发规范
 
 ## Key Claims（用中文描述）
-- Tick 逻辑必须实现于 C++——Blueprint VM 开销与缓存未命中在每帧调用频率下构成性能风险
-- Nanite 单场景硬上限 1600 万实例——开放世界项目需提前规划实例预算
-- 所有 UObject 派生指针必须声明 UPROPERTY()——缺失将导致垃圾回收意外销毁
-- GAS 网络复制必须通过 UAbilitySystemComponent——禁止手动复制技能状态
-- FGameplayTag 优于字符串——标签支持层级结构、复制安全、全局搜索
+- Tick 逻辑必须实现于 C++——Blueprint VM 开销与缓存未命中在每帧调用频率下构成 ~10x 性能差距，是规模级项目的性能隐患
+- Nanite 单场景硬上限 1600 万实例——开放世界项目需提前规划实例预算，植被密度在 500m 视距内将超出上限
+- 所有 UObject 派生指针必须声明 UPROPERTY()——缺失将导致垃圾回收意外销毁；跨帧 Actor 指针必须用 IsValid() 检查
+- GAS 网络复制必须通过 UAbilitySystemComponent——禁止手动复制技能状态；FGameplayTag 优于字符串（层级结构、复制安全、可搜索）
+- Nanite 不兼容骨骼网格（使用标准 LOD）、复杂 clip 操作的遮罩材质、样条网格、程序化网格组件；不存储显式切线（隐式像素着色器推导）
 
 ## Key Quotes
 > "Any logic that runs every frame (`Tick`) must be implemented in C++ — Blueprint VM overhead and cache misses make per-frame Blueprint logic a performance liability at scale." — UnrealSystemsEngineer 核心原则
@@ -28,18 +28,22 @@ date: 2026-04-26
 
 > "All `UObject`-derived pointers must be declared with `UPROPERTY()` — raw `UObject*` without `UPROPERTY` will be garbage collected unexpectedly." — 内存安全核心规范
 
+> "GAS project setup requires adding 'GameplayAbilities', 'GameplayTags', and 'GameplayTasks' to PublicDependencyModuleNames in the .Build.cs file." — GAS 项目配置前提
+
 ## Key Concepts
-- [[GAS-Gameplay-Ability-System]]：UE5 技能与属性管理框架，通过 UGameplayAbility/UAttributeSet/UAbilitySystemComponent 实现网络就绪的技能系统
-- [[Nanite]]：UE5 虚拟几何体系统，支持自动 LOD 和海量实例化渲染，单场景上限 1600 万实例
+- [[GAS]]：UE5 Gameplay Ability System，通过 UGameplayAbility/UAttributeSet/UAbilitySystemComponent 实现网络就绪的技能/属性/标签管理；内置 PredictionKey 支持客户端预测和服务器回滚
+- [[Nanite]]：UE5 虚拟几何体系统，支持自动 LOD 和海量实例化渲染，单场景上限 1600 万实例；不兼容骨骼网格、遮罩材质复杂 clip、样条网格；不存储显式切线
+- [[Actor Replication]]：UE5 Actor 属性复制机制；Tick 逻辑必须在 C++ 中实现以避免 Blueprint VM 开销；跨帧 Actor 指针须用 IsValid() 检查有效性
 - [[LumenGI]]：UE5 全局光照系统（源文档关联提及，未独立建页）
-- [[Chaos-Physics]]：UE5 物理与破坏系统框架（源文档 Advanced Capabilities 提及，建议后续独立建页）
-- [[Mass-Entity]]：Unreal ECS 实现，通过 UMassEntitySubsystem 处理海量 NPC/投射物/人群代理
-- [[Lyra-Gameplay-Framework]]：Epic 的模块化游戏框架模式，GameFeatureAction 运行时组件注入
+- [[Chaos-Physics]]：UE5 物理与破坏系统——Geometry Collections 实时网格破碎、Chaos constraint 类型（rigid/soft/spring/suspension）、Unreal Insights Chaos 专用 trace 通道分析
+- [[Mass-Entity]]：Unreal ECS 实现，通过 UMassEntitySubsystem 处理海量 NPC/投射物/人群代理；FMassFragment 数据层、FMassTag 布尔标记、UMassRepresentationSubsystem LOD 切换 actor 渲染
+- [[Lyra-Gameplay-Framework]]：Epic 模块化游戏框架模式——GameFeatureAction 运行时组件注入、Experience-based 游戏模式切换、HeroComponent 组件注入模式、Game Feature Plugins 可插拔内容
+- [[Unreal-Build-System]]：Unreal 模块化构建系统——.Build.cs 显式依赖声明、`GenerateProjectFiles.bat` 修改后必须运行、UCLASS/USTRUCT/UENUM 反射宏缺失导致静默运行时失败而非编译错误
 
 ## Key Entities
-- [[UnrealEngine5]]：Epic Games 开发的游戏引擎，提供 C++/Blueprint 双轨开发、Gas、Nanite、Lumen 等全栈工具链
-- [[UnrealMultiplayerArchitect]]：多人网络架构师 Agent，与本 Agent 在网络就绪系统设计上存在协作关系（GAS 配置中涉及网络复制）
-- [[UnrealTechnicalArtist]]：视觉系统工程师 Agent，与本 Agent 在 Nanite 几何优化上存在协作关系（Technical Artist 负责 Nanite 资产验证）
+- [[UnrealEngine5]]：Epic Games 开发的游戏引擎，提供 C++/Blueprint 双轨开发、GAS、Nanite、Lumen、Chaos、Mass Entity 等全栈工具链
+- [[UnrealMultiplayerArchitect]]：多人网络架构师 Agent，与本 Agent 在 GAS 网络复制配置上存在职责边界互补（系统工程师负责 GAS 内部逻辑，网络架构师确保 RPC 层安全调用 GAS）
+- [[UnrealTechnicalArtist]]：视觉系统工程师 Agent，与本 Agent 在 Nanite 几何优化和 Lumen GI 配置上存在协作关系（Technical Artist 负责 Nanite 资产验证和渲染配置）
 
 ## Connections
 - [[UnrealMultiplayerArchitect]] ← shares_gas_architecture_with ← [[UnrealSystemsEngineer]]
diff --git a/wiki/sources/unreal-technical-artist.md b/wiki/sources/unreal-technical-artist.md
index ac6d5e62..465bab87 100644
--- a/wiki/sources/unreal-technical-artist.md
+++ b/wiki/sources/unreal-technical-artist.md
@@ -1,58 +1,51 @@
 ---
 title: "Unreal Technical Artist"
 type: source
-tags: ["game-development", "unreal-engine", "technical-art", "vfx", "procedural-generation"]
-date: 2026-04-26
+tags: []
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/unreal-engine/unreal-technical-artist.md]]
+- [[Agent/agency-agents/game-development/unreal-engine/unreal-technical-artist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Unreal Engine 5 视觉系统工程师的 AI Agent 人格定义，专注于 UE5 的材质编辑器、Niagara VFX、PCG 程序化内容生成和美术-引擎管线
-- 问题域：如何在 AAA 级项目中，在硬件预算内交付高质量的视觉效果；如何建立可复用、可扩展的视觉工具链
-- 方法/机制：
-  - Material Editor 规范：Material Functions 复用原则、Material Instances 变体机制、Quality Switch 质量分层
-  - Niagara VFX 规范：GPU/CPU 模拟选择、粒子数量限制、Scalability 分级预设
-  - PCG 规范：确定性图生成、地形采样、密度过滤、Nanite 优化
-  - LOD 与剔除：Nanite 策略、Cull Distance Volumes、HLOD 配置
-- 结论/价值：定义了完整的 UE5 视觉技术交付标准，覆盖从材质到 VFX 到程序化场景的全管线
+- 核心主题：Unreal Engine 5 视觉系统工程师的 Agent 人格定义——专注于材质编辑器、Niagara VFX、PCG 程序化内容生成与美术-引擎资产管线
+- 问题域：如何在 AAA 级画面质量与硬件预算约束之间取得平衡；如何建立可复用、可维护的 UE5 视觉资产体系
+- 方法/机制：通过 Material Function 抽象复用逻辑、Niagara Scalability 系统实现帧预算分级、PCG 确定性图驱动开放世界资产放置
+- 结论/价值：Unreal Technical Artist 是美术与技术之间的桥梁，通过标准化工作流、预算驱动的性能和平台分级策略，确保视觉系统在 Ship 阶段依然可维护、可优化
 
 ## Key Claims（用中文描述）
-- 可复用逻辑必须封装为 Material Functions，绝不在多个 Master Material 间重复节点簇
-- 所有粒子系统必须设置 `Max Particle Count`，禁止无限粒子
-- PCG 图是确定性的：相同输入参数始终产生相同输出
-- 所有 PCG 放置的资产在符合条件时必须启用 Nanite
-- Substrate（UE5.3+）可实现多层物理材质叠加，替换传统 SSS workaround
+- 可复用逻辑必须进入 Material Function——跨 Master Material 复制节点簇将导致 shader permutation 爆炸
+- Niagara 系统 GPU/CPU 选型必须在构建前确定——CPU 适用于 < 1000 粒子，GPU 适用于 > 1000 粒子
+- PCG 图是确定性的——相同输入图和参数永远产生相同输出，参数必须对设计师暴露并文档化
+- 所有 PCG 放置的资产只要符合条件必须启用 Nanite——PCG 密度可扩展至数千个实例
+- HLOD（Hierarchical LOD）必须在所有使用 World Partition 的开放世界区域中配置
+- 材质 permutation 数量必须在 milestone lock 前完成文档化并签字确认
 
 ## Key Quotes
-> "Reusable logic goes into Material Functions — never duplicate node clusters across multiple master materials" — Material Editor 核心原则
-> "CPU simulation for < 1000 particles; GPU simulation for > 1000" — Niagara GPU/CPU 选择标准
-> "PCG graphs are deterministic: same input graph and parameters always produce the same output" — PCG 确定性保证
-> "All Nanite-ineligible meshes require manual LOD chains with verified transition distances" — LOD 验收标准
-> "Every Static Switch doubles shader permutation count — audit before adding" — 材质复杂度控制
+> "Reusable logic goes into Material Functions — never duplicate node clusters across multiple master materials" — Material Editor 规范核心原则
+> "GPU vs. CPU simulation choice before building: CPU simulation for < 1000 particles; GPU simulation for > 1000" — Niagara 性能决策依据
+> "PCG graphs are deterministic: same input graph and parameters always produce the same output" — PCG 核心特性
 
 ## Key Concepts
-- [[MaterialFunction]]：UE5 材质系统中可复用的节点逻辑封装单元，用于消除跨材质重复逻辑
-- [[NiagaraVFX]]：UE5 新一代粒子和 VFX 系统，支持 GPU/CPU 模拟分离与 Scalability 分级
-- [[PCG]]：Procedural Content Generation，UE5 程序化内容生成框架，通过图节点控制开放世界资产分布
-- [[Nanite]]：UE5 虚拟几何体系统，支持自动 LOD 和海量实例化渲染
-- [[Substrate]]：UE5.3+ 多层材质系统，支持物理正确的层叠材质（湿涂层/泥土/岩石），替代传统 SSS workaround
-- [[LOD]]：Level of Detail，根据距离切换网格精度，是开放世界性能优化的基础机制
-- [[QualitySwitch]]：UE5 材质节点，支持在单一材质图中定义移动/主机/PC 三档质量层级
+- [[MaterialFunction]]：UE5 中可复用的材质逻辑节点图，避免跨 Master Material 复制导致的 permutation 爆炸
+- [[NiagaraScalability]]：Niagara 粒子系统的 Low/Medium/High 分级预设，控制活跃系统数、单系统粒子数和剔除距离
+- [[PCG]]：Procedural Content Generation，程序化内容生成，通过确定性图驱动开放世界资产放置密度和分布
+- [[Nanite]]：UE5 虚拟几何体系统，PCG 放置的资产只要符合条件必须启用，以支持数千实例的渲染
+- [[HLOD]]：Hierarchical LOD，World Partition 开放世界区域的层级 LOD 配置，用于管理流式卸载
+- [[Substrate]]：UE5.3+ 新型材质系统，支持多层物理材质堆叠，取代传统 Shading Model
 
 ## Key Entities
-- [[UnrealEngine5]]：Epic Games 开发的游戏引擎，提供 Material Editor、Niagara、PCG、Nanite 等视觉工具链
-- [[UnrealInsights]]：UE5 性能分析工具，用于识别渲染性能瓶颈
-- [[WorldPartition]]：UE5 开放世界管理系统，与 HLOD 和 PCG 流式加载协同工作
+- [[UnrealEngine5]]：Epic Games 的游戏引擎，Unreal Technical Artist 的主要工作平台
+- [[Unreal World Builder]]：开放世界构建 Agent，[[Unreal Technical Artist]] 的协同角色
 
 ## Connections
-- [[MaterialFunction]] ← 核心依赖 ← [[UnrealTechnicalArtist]]
-- [[NiagaraVFX]] ← 核心依赖 ← [[UnrealTechnicalArtist]]
-- [[PCG]] ← 核心依赖 ← [[UnrealTechnicalArtist]]
-- [[UnrealEngine5]] ← 基于 ← [[UnrealTechnicalArtist]]
-- [[UnrealWorldBuilder]] ← 协同 ← [[UnrealTechnicalArtist]]
-- [[UnrealSystemsEngineer]] ← 协同 ← [[UnrealTechnicalArtist]]（技术艺术家负责视觉，系统工程师负责底层）
+- [[Unreal World Builder]] ← shares_engine ← [[Unreal Technical Artist]]
+- [[Unreal Systems Engineer]] ← shares_pipeline ← [[Unreal Technical Artist]]
+- [[Unreal Multiplayer Architect]] ← shares_platform ← [[Unreal Technical Artist]]
 
 ## Contradictions
-- 暂无冲突内容
+- 与 [[Technical Artist]]（通用 TA）冲突：
+  - 冲突点：通用 TA 涵盖 Unity/Unreal/自研引擎所有平台；本角色专注 Unreal Engine 5 独有系统（Nanite、PCG、Niagara）
+  - 当前观点：Unreal TA 需要深度掌握 Nanite、PCG、Niagara、World Partition 等 UE5 独有工具链
+  - 对方观点：通用 TA 强调跨引擎方法论而非特定引擎实现细节
diff --git a/wiki/sources/unreal-world-builder.md b/wiki/sources/unreal-world-builder.md
index e2d43527..a5088b68 100644
--- a/wiki/sources/unreal-world-builder.md
+++ b/wiki/sources/unreal-world-builder.md
@@ -1,50 +1,67 @@
 ---
 title: "Unreal World Builder Agent Personality"
 type: source
-tags: ["unreal-engine", "open-world", "ue5", "world-partition", "game-development"]
-date: 2026-04-26
+tags: ["unreal-engine", "open-world", "game-development", "agent"]
+sources: []
+last_updated: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/game-development/unreal-engine/unreal-world-builder.md]]
+- [[Agent/agency-agents/game-development/unreal-engine/unreal-world-builder.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Unreal Engine 5 开放世界环境构建 Agent 的角色定义与工作规范
-- 问题域：大型开放世界游戏（4km² ~ 64km²）的环境流送、渲染优化、内容生成等技术挑战
-- 方法/机制：World Partition 分区流送、Landscape 地形系统、PCG 程序化内容生成、HLOD 层级 LOD、Nanite 虚拟几何体、RVT 运行时虚拟纹理
-- 结论/价值：提供了一套完整的 UE5 开放世界技术交付标准，覆盖从网格规划到性能验证的全流程
+- 核心主题：UE5 开放世界环境架构 Agent 的角色定义与技术规范，专注于无缝流式加载、高性能渲染和大规模关卡管理
+- 问题域：开放世界游戏开发中的流式加载、景观材质、LOD 系统、程序化植被、坐标精度、多人协作编辑等技术挑战
+- 方法/机制：通过 World Partition 分区流式、Runtime Virtual Texturing（RVT）景观材质分层、PCG 程序化植被、HLOD 层级 LOD 合并、LWC 大世界坐标等系统协同实现
+- 结论/价值：提供了一套完整的开放世界生产级技术交付标准，覆盖从网格规划到性能调优的完整工作流
 
 ## Key Claims（用中文描述）
-- World Partition 格子大小必须由目标流送预算决定：密集城区用 64m、空旷地形用 128m、沙漠/海洋用 256m+
-- Landscape 材质超过 2 层时必须启用 Runtime Virtual Texturing（RVT），否则产生每像素层混合成本爆炸
-- HLOD 必须为所有 500m 以外可见区域生成，未构建 HLOD 会导致远距离 Actor 数量激增
-- PCG 大规模植被必须使用预烘焙输出，运行时 PCG 仅限 1km² 以下小区域
-- 大世界坐标（LWC）必须在任何轴超过 2km 的世界启用，否则约 20km 后出现浮点精度错误
+- World Partition 流式网格尺寸必须由目标流式预算决定：密集城区 64m、开阔地形 128m、稀疏沙漠/海洋 256m 以上
+- 所有 Always Loaded 内容（GameMode actors、音频管理器、天空）必须放在专用的 Always Loaded 数据层，不能散落在流式单元格中
+- Runtime Hash Grid 单元格大小必须在填充世界前配置完毕——之后重配置需要完整重新保存关卡
+- Landscape 分辨率必须满足 (n×ComponentSize)+1 公式，使用 Landscape 导入计算器确定
+- 单个混合区域最多 4 个活跃 Landscape 层，超过则导致材质排列组合爆炸
+- 超过 2 层 Landscape 材质的必须启用 Runtime Virtual Texturing（RVT），RVT 消除逐像素层混合开销
+- Landscape 空洞必须使用 Visibility Layer，不能删除组件——删除组件会破坏 LOD 和水体系统集成
+- HLOD 必须为所有相机距离 > 500m 的可见区域构建，未构建 HLOD 会导致远处 Actor 数量爆炸
+- HLOD 网格由生成而非手绘，任何几何变更后必须重新构建 HLOD
+- Foliage Tool（传统）仅用于手绘英雄资产放置，大规模植被使用 PCG
+- 所有 PCG 放置的资产应在条件允许时启用 Nanite，PCG 实例数量轻易超过 Nanite 优势阈值
+- PCG 图必须定义显式排除区域：道路、路径、水体、手放建筑
+- Runtime PCG 生成仅限于小区域（< 1km²），大面积使用预烘焙 PCG 输出以兼容流式加载
+- 大世界坐标（LWC）：世界尺寸超过 2km 任一轴时必须启用，否则约 20km 处开始出现浮点精度错误
+- One File Per Actor（OFPA）：所有 World Partition 关卡启用 OFPA 以支持多用户编辑而不产生文件冲突
 
 ## Key Quotes
-> "Cell size must be determined by target streaming budget — smaller cells = more granular streaming but more overhead" — World Partition 配置核心原则
-> "HLOD must be built for all areas visible at > 500m camera distance — unbuilt HLOD causes actor-count explosion at distance" — HLOD 必建规则
-> "Foliage Tool (legacy) is for hand-placed art hero placement only — large-scale population uses PCG" — PCG 替代 Foliage Tool 的使用场景
+> "Cell size must be determined by target streaming budget — smaller cells = more granular streaming but more overhead; 64m cells for dense urban, 128m for open terrain, 256m+ for sparse desert/ocean" — World Partition 网格尺寸决策原则
+> "Never place gameplay-critical content (quest triggers, key NPCs) at cell boundaries — boundary crossing during streaming can cause brief entity absence" — 边界放置禁忌
+> "All always-loaded content (GameMode actors, audio managers, sky) goes in a dedicated Always Loaded data layer — never scattered in streaming cells" — Always Loaded 层设计原则
+> "HLOD meshes are generated, never hand-authored — re-build HLOD after any geometry change in its coverage area" — HLOD 生成规范
+> "Foliage Tool (legacy) is for hand-placed art hero placement only — large-scale population uses PCG" — 植被工具选型原则
+> "All PCG-placed assets must be Nanite-enabled where eligible — PCG instance counts easily exceed Nanite's advantage threshold" — PCG + Nanite 协同原则
 > "Enable Large World Coordinates for worlds > 2km in any axis — floating point precision errors become visible at ~20km without LWC" — LWC 启用阈值
 
 ## Key Concepts
-- [[WorldPartition]]: UE5 的开放世界分区管理系统，将世界划分为格子，支持按需流送
-- [[Landscape]]: UE5 地形系统，支持多层混合烘焙和运行时虚拟纹理
-- [[PCG]]: Procedural Content Generation，程序化内容生成，用于大规模植被和环境资产放置
-- [[HLOD]]: Hierarchical Level of Detail，层级 LOD，通过网格合并减少远距离 Draw Call
-- [[Nanite]]: UE5 虚拟化几何体系统，处理大规模几何细节，支持数百万实例
-- [[RuntimeVirtualTexturing]]: RVT，运行时虚拟纹理，消除地形层混合的像素级计算开销
-- [[LargeWorldCoordinates]]: LWC，双精度坐标系统，解决超大世界浮点精度问题
+- [[World Partition]]：UE5 的开放世界分区管理框架，将世界划分为单元格进行流式加载，支持多用户协作编辑
+- [[Nanite]]：UE5 虚拟化几何系统，处理大规模细节几何，支持海量实例自动 LOD
+- [[PCG]]（Procedural Content Generation）：程序化内容生成系统，用于大规模植被和资产放置，支持排除区域和随机化
+- [[HLOD]]（Hierarchical Level of Detail）：层级 LOD 系统，在远距离将多个 Actor 合并为少量网格，消除远处几何 pop-in
+- [[Landscape]]：UE5 地形系统，支持多层混合材质和运行时虚拟纹理
+- [[Runtime Virtual Texturing]]（RVT）：运行时虚拟纹理，消除逐像素 Landscape 层混合计算开销
+- [[Large World Coordinates]]（LWC）：UE5 双精度坐标系统，解决超大世界浮点精度问题
+- [[One File Per Actor]]（OFPA）：World Partition 多用户协作模式，每个 Actor 独立文件避免版本冲突
 
 ## Key Entities
-- [[UnrealEngine5]]: 开发平台，UE5 提供 World Partition、Nanite、LWC 等开放世界基础设施
-- [[EpicGames]]: Unreal Engine 发行商，World Partition 和 Nanite 均为 Epic 内部开发的技术
+- [[Epic Games]]：Unreal Engine 5 的开发商，提供 World Partition、Nanite、HLOD、PCG 等核心技术
+- [[UnrealEngine5]]：游戏引擎，提供开放世界所需全部基础设施
 
 ## Connections
-- [[UnrealSystemsEngineer]] ← skill_overlap ← [[UnrealWorldBuilder]]（共享 World Partition 流送基础设施）
-- [[UnrealTechnicalArtist]] ← extends ← [[UnrealWorldBuilder]]（共享 Landscape 材质与 RVT 技术）
-- [[UnrealWorldBuilder]] ← depends_on ← [[Nanite]]（PCG 植被依赖 Nanite 优化实例渲染）
-- [[UnrealWorldBuilder]] ← depends_on ← [[HLOD]]（开放世界远距离渲染优化依赖 HLOD 系统）
+- [[UnrealEngine5]] ← 运行环境 ← [[UnrealWorldBuilder]]
+- [[World Partition]] ← 核心框架 ← [[UnrealWorldBuilder]]
+- [[PCG]] ← 环境放置 ← [[UnrealWorldBuilder]]
+- [[HLOD]] ← 远距离优化 ← [[UnrealWorldBuilder]]
+- [[Nanite]] ← 几何渲染 ← [[UnrealWorldBuilder]]
+- [[Epic Games]] ← 技术提供 ← [[UnrealEngine5]]
 
 ## Contradictions
-- 未发现与现有 Wiki 内容的冲突。
+- 暂无发现与其他 Wiki 页面的内容冲突
diff --git a/wiki/sources/visionos-spatial-engineer.md b/wiki/sources/visionos-spatial-engineer.md
index e7aef77a..956537c6 100644
--- a/wiki/sources/visionos-spatial-engineer.md
+++ b/wiki/sources/visionos-spatial-engineer.md
@@ -2,67 +2,48 @@
 title: "visionOS Spatial Engineer"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md]]
+- [[Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：visionOS 原生空间计算 Agent，专注于 volumetric 界面与 Liquid Glass 设计系统实现
-- 问题域：Apple visionOS 26 平台上的空间应用开发，缺乏统一的设计与工程实践框架
-- 方法/机制：基于 SwiftUI/RealityKit 技术栈，通过 Liquid Glass Design System 驱动透明材质渲染，结合 WindowGroup 多窗口架构和 SwiftUI Volumetric API 实现 3D 内容集成
-- 结论/价值：为 The Agency Spatial Computing 部门提供 visionOS 原生开发能力，与 [[macos-spatial-metal-engineer]]（Metal 渲染侧）和 [[xr-immersive-developer]]（WebXR 浏览器侧）共同构成 Apple 空间计算全栈能力
+- 核心主题：visionOS 26 原生空间计算、SwiftUI 体积化界面与 Liquid Glass 设计系统的实现专家角色
+- 问题域：Apple Vision Pro 应用开发——如何在空间计算环境中构建沉浸式、高性能、符合 Apple 设计规范的原生应用
+- 方法/机制：基于 SwiftUI + RealityKit + ARKit 技术栈，通过 Liquid Glass Design System（玻璃态设计系统）、Spatial Widgets（空间小组件）、Multi-Window Architecture（多窗口架构）等机制实现体积化界面
+- 结论/价值：专注于 visionOS 26 平台原生能力，强调无障碍支持、性能优化和 3D 空间最佳用户体验
 
 ## Key Claims（用中文描述）
-- Apple 的 Liquid Glass Design System 通过自适应透明材质，在 light/dark 环境和周围内容变化时动态调整视觉表现
-- Spatial Widgets 可吸附于墙面和桌面，持久化放置于 3D 空间中，无需应用前台运行
-- SwiftUI Volumetric API 支持 3D 内容集成、volume 内 transient content 和 breakthrough UI 元素
-- RealityKit-SwiftUI 集成通过 Observable entities、直接手势处理和 ViewAttachmentComponent 实现声明式 3D 开发
-- Multi-Window Architecture 通过 WindowGroup 管理空间应用的玻璃背景效果和单实例窗口
-- GPU 高效渲染是多个玻璃窗口和 3D 内容同时展示的性能保障
+- **Liquid Glass Design System**：通过半透明材质实现自适应明暗环境和周围内容界面的玻璃态视觉效果
+- **Spatial Widgets**：支持在 3D 空间中持久吸附于墙面和桌面的小组件，可跨会话保持位置
+- **Multi-Window Architecture**：WindowGroup 管理空间应用，配合玻璃背景效果实现多窗口空间体验
+- **RealityKit-SwiftUI Integration**：使用 Observable entities、直接手势处理和 ViewAttachmentComponent 实现 3D 内容集成
+- 技术栈锁定于 SwiftUI/RealityKit，**不涉及 Unity 或其他跨平台 3D 框架**
 
 ## Key Quotes
-> "Focuses on leveraging visionOS 26's spatial computing capabilities to create immersive, performant applications that follow Apple's Liquid Glass design principles." — Agent personality description
+> "Focuses on leveraging visionOS 26's spatial computing capabilities to create immersive, performant applications that follow Apple's Liquid Glass design principles." — 角色设计理念
 
 ## Key Concepts
-- [[Liquid Glass Design System]]：Apple visionOS 26 的核心视觉设计语言，通过透明材质实现深度感知和空间沉浸感
-- [[Spatial Widgets]]：可吸附于 3D 空间（墙面/桌面）并持久化放置的小组件，支持跨应用使用
-- [[SwiftUI Volumetric APIs]]：visionOS 26 新增的 3D 内容渲染 API 集，支持 volumetric 场景和 breakthrough UI
-- [[RealityKit-SwiftUI Integration]]：RealityKit 实体系统与 SwiftUI 声明式语法的深度集成模式
-- [[Glass Background Effects]]：glassBackgroundEffect modifier 实现窗口和控件的毛玻璃透明效果
-- [[Volumetric Presentations]]：空间展示模式，支持 single-instance 窗口和 volume 内的临时内容
-- [[Spatial Layouts]]：3D 空间定位、深度管理和空间关系处理
-- [[Multi-Window Architecture]]：基于 WindowGroup 的空间应用多窗口管理模式
+- [[Liquid Glass Design System]]：Apple visionOS 26 的全新设计语言，使用半透明材料适配光暗环境和周围内容
+- [[Spatial Widgets]]：可在 3D 空间中持久放置的小组件，支持吸附到墙面和桌面
+- [[SwiftUI Volumetric APIs]]：用于在体积空间（volumes）中集成 3D 内容的 SwiftUI API
+- [[RealityKit-SwiftUI Integration]]：RealityKit 与 SwiftUI 的深度集成，支持 Observable entities 和直接手势处理
+- [[Multi-Window Architecture]]：visionOS 多窗口管理架构，通过 WindowGroup 实现玻璃背景效果空间应用
 
 ## Key Entities
-- [[Apple]]：visionOS/SwiftUI/RealityKit/ARKit 框架的缔造者，Liquid Glass Design System 的设计者
-- [[visionOS]]：Apple 空间计算操作系统，本 Agent 的核心目标平台（visionOS 26+）
-- [[SwiftUI]]：Apple 声明式 UI 框架，本 Agent 的主要开发语言
-- [[RealityKit]]：Apple 原生 3D 渲染引擎，与 SwiftUI 深度集成
-- [[ARKit]]：Apple 增强现实框架，本 Agent 的空间感知能力来源
-- [[Metal]]：Apple GPU 渲染 API，支撑 Liquid Glass 和 3D 内容的高性能渲染
-- [[XR-Interface-Architect]]：Spatial Computing 部门 UX/UI 设计专家，与本 Agent 协同构建空间界面
-- [[macOS-Spatial-Metal-Engineer]]：Apple 平台 Metal 渲染侧专家，与本 Agent 协同构成 Apple 空间计算全栈
-- [[Terminal-Integration-Specialist]]：Swift 终端仿真专家，本 Agent 依赖其提供命令行交互能力
-- [[XR-Immersive-Developer]]：同部门 WebXR 开发专家
-- [[XR-Cockpit-Interaction-Specialist]]：同部门座舱交互专家
+- [[Apple]]：visionOS、SwiftUI、RealityKit、ARKit 的开发者和 Liquid Glass 设计系统的制定者
+- [[visionOS 26]]：本角色的目标平台版本，引入 Liquid Glass 设计系统和新一代 Spatial Widgets
+- [[SwiftUI]]：本角色的核心 UI 框架，用于构建空间界面和体积化内容
+- [[RealityKit]]：Apple 的 3D 渲染引擎，与 SwiftUI 深度集成用于空间计算内容
 
 ## Connections
-- [[XR-Immersive-Developer]] ← related_to ← [[visionos-spatial-engineer]]：两者同属 Spatial Computing 部门，前者专注浏览器端 WebXR，后者专注 Apple 原生 visionOS
-- [[macOS-Spatial-Metal-Engineer]] ← related_to ← [[visionos-spatial-engineer]]：前者专注 Metal 渲染管线，后者专注 SwiftUI/RealityKit 原生应用；两者协同构成完整的 Apple 空间计算平台能力
-- [[XR-Interface-Architect]] ← supports ← [[visionos-spatial-engineer]]：前者提供 UX/UI 设计框架，本 Agent 负责技术实现
-- [[Terminal-Integration-Specialist]] ← supports ← [[visionos-spatial-engineer]]：前者提供 Swift 终端仿真集成能力
+- [[xr-interface-architect]] ← topic_overlap ← [[visionos-spatial-engineer]]（均为 XR/空间界面设计领域，但前者更通用，后者专注于 visionOS 26 原生实现）
+- [[macos-spatial-metal-engineer]] ← platform_related ← [[visionos-spatial-engineer]]（同属 Apple 空间计算生态，macOS 侧重 Metal 渲染，visionOS 侧重 SwiftUI/RealityKit）
+- [[xr-immersive-developer]] ← extends ← [[visionos-spatial-engineer]]（XR 沉浸式开发者角色可参考本角色的 visionOS 专项能力）
 
 ## Contradictions
-- 与 [[XR-Immersive-Developer]] 在平台选择上的差异：
-  - 冲突点：前者基于 WebXR（浏览器端，跨平台），后者基于 visionOS 原生（Apple 独占）
-  - 当前观点：visionOS Spatial Engineer 专注 Apple 原生平台，追求最优性能和平台特性
-  - 对方观点：XR Immersive Developer 优先跨平台兼容性，通过 A-Frame/Three.js 实现浏览器端部署
-  - 协调：两者面向不同场景，前者服务 visionOS 高端沉浸体验，后者服务广泛的 WebXR 设备覆盖
-
-- 与 [[macOS-Spatial-Metal-Engineer]] 在技术栈选择上的差异：
-  - 冲突点：前者侧重 SwiftUI/RealityKit 声明式开发，后者侧重 Metal/SceneKit 底层渲染
-  - 当前观点：visionOS Spatial Engineer 优先 SwiftUI 的声明式效率和 Apple 官方推荐模式
-  - 对方观点：macOS Spatial/Metal Engineer 认为 Metal 渲染管线对于大规模 3D 数据可视化更可控
-  - 协调：两者在同一问题域互补——前者处理 UI/UX 层应用开发，后者处理 GPU 密集型数据渲染
+- 与 [[xr-immersive-developer]] 可能存在技术路径分歧：
+  - 冲突点：跨平台 vs 平台锁定
+  - 当前观点（visionos-spatial-engineer）：专注 visionOS 26 原生 SwiftUI/RealityKit 栈，不支持 Unity 或其他 3D 框架
+  - 对方观点（xr-immersive-developer）：倾向跨平台沉浸式开发解决方案，可能包含 Unity/其他框架集成
diff --git a/wiki/sources/workflow-book-chapter.md b/wiki/sources/workflow-book-chapter.md
index 61f51933..5f47c250 100644
--- a/wiki/sources/workflow-book-chapter.md
+++ b/wiki/sources/workflow-book-chapter.md
@@ -2,7 +2,8 @@
 title: "Workflow Example: Book Chapter Development"
 type: source
 tags: []
-date: 2026-04-25
+sources: []
+last_updated: 2026-05-13
 ---
 
 ## Source File
diff --git a/wiki/sources/workflow-landing-page.md b/wiki/sources/workflow-landing-page.md
index 3e199e8f..8cbc339c 100644
--- a/wiki/sources/workflow-landing-page.md
+++ b/wiki/sources/workflow-landing-page.md
@@ -2,49 +2,51 @@
 title: "Multi-Agent Workflow: Landing Page Sprint"
 type: source
 tags: [multi-agent, workflow, landing-page, conversion-optimization]
-date: 2026-04-21
+date: 2026-04-25
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/examples/workflow-landing-page.md]]
+- [[Agent/agency-agents/examples/workflow-landing-page.md]]
 
 ## Summary（用中文描述）
-- 核心主题：多 Agent 协作在一天内完成高转化率 landing page 的完整工作流
-- 问题域：如何在极短时间内协调多个专业 Agent（文案、设计、开发、增长）并行与串行工作，产出可上线的 landing page
-- 方法/机制：上午并行（文案 + 设计）→ 中午合并构建 → 下午增长优化 + 反馈循环
-- 结论/价值：展示了 Multi-Agent 协作中的 4 个核心设计模式（并行启动、合并点、反馈循环、时间盒）
+- 核心主题：使用 4 个 AI Agent 在一天内完成一个转化优化的着陆页（从文案到设计到构建到优化）
+- 问题域：产品快速上线时的多角色协作问题；单一 Agent 难以同时覆盖文案、设计、前端、营销优化等多个专业领域
+- 方法/机制：并行启动 → 合并点 → 反馈循环 → 时间盒（Time-boxed）
+- 结论/价值：展示了一种高效的多 Agent 协作模式，定义清晰的合并点和交接节点可大幅提升协作效率
 
 ## Key Claims（用中文描述）
-- 文案 Agent 与 UI 设计 Agent 可在上午并行工作，因两者输出互相独立
-- 前端开发 Agent 需要等待文案和设计两者完成后才能开始（合并点依赖）
-- 增长黑客 Agent 在第一版完成后进行转化率审查，前端开发根据反馈进行修改
-- 每个阶段有明确的时间盒，防止范围蔓延
+- 4 个专业 Agent（Content Creator、UI Designer、Frontend Developer、Growth Hacker）分工明确，可在一天内完成高质量着陆页
+- 并行 kickoff：文案与设计可同时进行，因二者相互独立
+- 合并点（Merge Point）：Frontend Developer 必须等待 Content Creator 和 UI Designer 的输出后方可开始
+- 反馈循环（Feedback Loop）：Growth Hacker 审查后，Frontend Developer 立即应用修改
+- 时间盒（Time-boxed）：每步有明确时间限制，防止范围蔓延
 
 ## Key Quotes
-> "Parallel kickoff: Copy and design happen at the same time since they're independent" — 工作流核心原则：独立任务并行启动
-> "Merge point: Frontend Developer needs both outputs before starting" — 前端开发的依赖管理
-> "Feedback loop: Growth Hacker reviews, then Frontend Developer applies changes" — 质量保障的迭代机制
-> "Time-boxed: Each step has a clear timebox to prevent scope creep" — 项目管理原则
+> "Parallel kickoff: Copy and design happen at the same time since they're independent" — 展示了多 Agent 协作中的并行化原则
+> "Merge point: Frontend Developer needs both outputs before starting" — 强调 Agent 间存在数据依赖时的同步机制
+> "Time-boxed: Each step has a clear timebox to prevent scope creep" — 时间约束是防止无限迭代的关键
 
 ## Key Concepts
-- [[Parallel-Kickoff]]：独立 Agent 任务在同一时间并行启动，无需相互等待
-- [[Merge-Point]]：多个并行分支的输出在特定节点合并，触发下一阶段
-- [[Feedback-Loop]]：后续 Agent 审查并反馈，前序 Agent 根据反馈修改的迭代机制
-- [[Time-Boxing]]：为每个工作阶段设定严格时间限制，防止范围蔓延
+- [[Parallel Kickoff]]：多个相互独立的 Agent 任务同时启动，以缩短总体工期
+- [[Merge Point]]：多 Agent 工作流中某 Agent 必须等待其他 Agent 输出才能继续的同步节点
+- [[Feedback Loop]]：下游 Agent 审查上游产出并提出修改建议，上游 Agent 据此优化的迭代机制
+- [[Time-boxing]]：为每个工作步骤设定明确的时间上限，防止范围蔓延和质量过度优化
+- [[Conversion Optimization]]：通过 A/B 测试、CTA 优化、SEO 等手段提升页面转化率
+- [[Multi-Agent Workflow]]：多个人工智能 Agent 协作完成复杂任务的系统性方法
 
 ## Key Entities
-- [[Content-Creator]]：负责撰写 landing page 文案（标题、副标题、CTA、定价等）的 Agent
-- [[UI-Designer]]：负责设计布局、配色、字体、组件规格的 Agent
-- [[Frontend-Developer]]：负责将文案和设计合并构建为可部署 HTML 的 Agent
-- [[Growth-Hacker]]：负责转化率审查和优化建议的 Agent
-- [[FlowSync]]：案例中的虚构产品——一个 API 集成平台
+- [[Content Creator]]：负责撰写着陆页文案（标题、副标题、CTA、痛点、定价等）
+- [[UI Designer]]：负责设计规范（布局线框图、配色、字体、组件规格、响应式断点）
+- [[Frontend Developer]]：负责根据文案和设计规范构建 HTML/Tailwind 页面
+- [[Growth Hacker]]：负责转化率优化审查（A/B 测试、SEO、摩擦点分析）
+- [[FlowSync]]：虚构的 API 集成平台，作为示例产品贯穿整个工作流
 
 ## Connections
-- [[Content-Creator]] ← depends_on ← (无，独立启动)
-- [[UI-Designer]] ← depends_on ← (无，独立启动)
-- [[Frontend-Developer]] ← merge_point ← [[Content-Creator]] + [[UI-Designer]]
-- [[Growth-Hacker]] ← depends_on ← [[Frontend-Developer]]
-- [[workflow-startup-mvp]] ← extends ← [[Parallel-Kickoff]] + [[Merge-Point]] + [[Feedback-Loop]] + [[Time-Boxing]]
+- [[workflow-startup-mvp]] ← similar_pattern ← [[workflow-landing-page]]
+- [[Content Creator]] ← produces_copy ← [[Frontend Developer]]
+- [[UI Designer]] ← produces_specs ← [[Frontend Developer]]
+- [[Growth Hacker]] ← reviews ← [[Frontend Developer]]
+- [[workflow-with-memory]] ← extends ← [[workflow-landing-page]]
 
 ## Contradictions
-- 无明显冲突。workflow-startup-mvp 的时间线以"周"为单位（长周期迭代），本工作流以"小时"为单位（短周期冲刺）。两者互补，后者是前者在单日冲刺场景下的具体化。
+- 无明显冲突。该工作流与其他多 Agent 工作流（如 [[workflow-startup-mvp]]）在协作模式上互补而非矛盾。
diff --git a/wiki/sources/workflow-startup-mvp.md b/wiki/sources/workflow-startup-mvp.md
index a021a3cf..6dd06405 100644
--- a/wiki/sources/workflow-startup-mvp.md
+++ b/wiki/sources/workflow-startup-mvp.md
@@ -2,60 +2,50 @@
 title: "Multi-Agent Workflow: Startup MVP"
 type: source
 tags: []
-date: 2026-04-21
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/examples/workflow-startup-mvp.md]]
+- [[Agent/agency-agents/examples/workflow-startup-mvp.md]]
 
 ## Summary（用中文描述）
-- 核心主题：多 Agent 协作工作流，演示如何协调多个 Agent 从创意到 MVP 交付的完整流程
-- 问题域：SaaS 产品（团队回顾工具）的快速开发与多角色 Agent 协调
-- 方法/机制：7 种专业 Agent 角色（Sprint Prioritizer、UX Researcher、Backend Architect、Frontend Developer、Rapid Prototyper、Growth Hacker、Reality Checker），按 4 周 7 步骤流水线协作
-- 结论/价值：展示了顺序交接、并行工作、质量门控、上下文传递四大关键模式，是多 Agent 团队协作的最佳实践范例
+- 核心主题：如何协调多个 AI Agent，从想法到 4 周内交付 SaaS MVP
+- 问题域：初创公司产品开发、远程团队回顾工具（RetroBoard）
+- 方法/机制：7 个专业 Agent 按周分工，通过顺序交接、并行工作、质量门控协调
+- 结论/价值：提供了多 Agent 协作开发产品的实践蓝图
 
 ## Key Claims（用中文描述）
-- Sprint Prioritizer 将 4 周 MVP 项目拆解为有明确交付物和验收标准的 4 个冲刺
-- UX Researcher 并行进行竞品分析，识别产品差异化机会
-- Backend Architect 输出完整 API 规范（数据库 Schema、REST 端点、WebSocket 事件、认证策略）
-- Frontend Developer + Rapid Prototyper 基于 API 规范并行构建应用
-- Reality Checker 在第 2 周和第 4 周各设置一个质量门控点，评估生产就绪状态
-- Growth Hacker 在第 3 周同步启动增长策略制定（着陆页、发布渠道、Day-by-day 序列）
-- Sequential Handoffs（顺序交接）：每个 Agent 的输出作为下一个 Agent 的输入
-- Parallel Work（并行工作）：Week 1 中 Sprint Prioritizer 和 UX Researcher 可同时运行
-- Quality Gates（质量门控）：Reality Checker 在关键里程碑处评估是否可继续
-- Context Passing（上下文传递）：Agent 之间无共享记忆，必须完整粘贴上一个 Agent 的输出
+- 顺序交接（Sequential Handoffs）：每个 Agent 的输出作为下一个 Agent 的输入
+- 并行工作（Parallel Work）：第 1 周 Sprint Prioritizer 和 UX Researcher 可并行执行
+- 质量门控（Quality Gates）：Reality Checker 在中期（第2周）和发布前（第4周）设卡
+- 上下文传递（Context Passing）：直接粘贴完整输出，不要摘要——Agent 之间不共享记忆
 
 ## Key Quotes
-> "Sequential handoffs: Each agent's output becomes the next agent's input" — 多 Agent 协作的核心机制
-> "Copy-paste agent outputs between steps — don't summarize, use the full output" — 上下文传递原则，必须完整粘贴而非摘要
-> "Keep the Orchestrator agent in mind for automating this flow once you're comfortable with the manual version" — 未来可引入 Orchestrator Agent 自动化此工作流
+> "Copy-paste agent outputs between steps — don't summarize, use the full output" — 核心操作原则
+> "Agents don't share memory" — 多 Agent 系统的基础约束
+> "Quality gates at midpoint and before launch prevents shipping broken code" — 质量门控的价值
 
 ## Key Concepts
-- [[Sequential Handoff]]：顺序交接模式 — 每个 Agent 的输出作为下一个 Agent 的完整输入
-- [[Parallel Agent Work]]：并行工作模式 — 独立 Agent 在 Week 1 可同时激活
-- [[Quality Gate]]：质量门控 — 在关键里程碑设置 Reality Checker 评估点，防止有问题的代码上线
-- [[Context Passing]]：上下文传递 — Agent 之间无共享记忆，必须显式传递完整上下文
-- [[Multi-Agent Orchestration]]：多 Agent 编排 — 通过预定义的 Agent 角色和交接顺序实现流水线化协作
+- [[Sequential Handoff]]：每个 Agent 的完整输出作为下一个 Agent 的输入
+- [[Parallel Agent Execution]]：独立 Agent 可同时运行以提升效率
+- [[Quality Gate]]：在关键里程碑处设卡审查，防止问题流入下一阶段
+- [[Context Passing]]：Agent 之间不共享记忆，必须完整传递上下文
+- [[Multi-Agent Coordination]]：多 Agent 协作模式（顺序、并行、质量门控）
 
 ## Key Entities
-- [[Sprint Prioritizer]]：将项目拆解为 4 周冲刺的角色
-- [[UX Researcher]]：进行竞品分析并识别差异化的角色
-- [[Backend Architect]]：设计 API、数据模型和实时架构的角色
-- [[Frontend Developer]]：基于 API 规范构建 React 应用的角色
-- [[Rapid Prototyper]]：快速产出第一个可运行版本的角色
-- [[Growth Hacker]]：制定发布策略和增长计划的角色
-- [[Reality Checker]]：在关键节点评估生产就绪状态并给出 GO/NO-GO 决策的角色
-- [[RetroBoard]]：示例产品 — 面向远程团队的实时团队回顾工具
-- [[Orchestrator Agent]]：未来用于自动化此工作流的编排 Agent
+- [[Sprint Prioritizer]]：将项目拆分为 4 周 Sprint，定义交付物和验收标准
+- [[UX Researcher]]：执行竞品分析，识别差异化机会
+- [[Backend Architect]]：设计 API、数据模型、WebSocket 实时事件
+- [[Frontend Developer]]：使用 React/TypeScript/Tailwind 构建应用
+- [[Rapid Prototyper]]：快速产出第一个可用版本
+- [[Growth Hacker]]：制定 Product Hunt/Hacker News/Reddit/Twitter 冷启动计划
+- [[Reality Checker]]：在中期和发布前评估可行性与生产就绪状态
 
 ## Connections
-- [[Sprint Prioritizer]] ← outputs sprint plan to ← [[UX Researcher]] ← parallel work in Week 1
-- [[UX Researcher]] ← outputs research brief to ← [[Backend Architect]] ← handoff in Week 1
-- [[Backend Architect]] ← outputs API spec to ← [[Frontend Developer]] + [[Rapid Prototyper]] ← parallel in Week 2
-- [[Frontend Developer]] ← midpoint gate ← [[Reality Checker]] ← Week 2 quality check
-- [[Reality Checker]] ← final gate ← [[Growth Hacker]] ← Week 3 parallel with Frontend Developer
-- [[Reality Checker]] ← GO/NO-GO ← Launch ← Week 4 final check
+- [[Workflow Book Chapter]] ← workflow_pattern ← [[Workflow With Memory]]
+- [[Agents Orchestrator]] ← coordinates ← [[Sprint Prioritizer]], [[UX Researcher]], [[Backend Architect]], [[Frontend Developer]], [[Rapid Prototyper]], [[Growth Hacker]], [[Reality Checker]]
+- [[Product Sprint Prioritizer]] ← specialized_by ← [[Sprint Prioritizer]]
+- [[Design UX Researcher]] ← same_as ← [[UX Researcher]]
 
 ## Contradictions
-- 无明显内容冲突。该工作流以示例为主，与其他 Agent 工作流文档可共存。
+- （暂无已知冲突）
diff --git a/wiki/sources/workflow-with-memory.md b/wiki/sources/workflow-with-memory.md
index e88c82fb..9d3ebf32 100644
--- a/wiki/sources/workflow-with-memory.md
+++ b/wiki/sources/workflow-with-memory.md
@@ -3,6 +3,8 @@ title: "Multi-Agent Workflow: Startup MVP with Persistent Memory"
 type: source
 tags: [multi-agent, memory, mcp, workflow, persistent-state]
 date: 2026-04-26
+last_updated: 2026-05-13
+sources: [workflow-with-memory]
 ---
 
 ## Source File
diff --git a/wiki/sources/xr-cockpit-interaction-specialist.md b/wiki/sources/xr-cockpit-interaction-specialist.md
index 45689c46..196dad2b 100644
--- a/wiki/sources/xr-cockpit-interaction-specialist.md
+++ b/wiki/sources/xr-cockpit-interaction-specialist.md
@@ -2,40 +2,46 @@
 title: "XR Cockpit Interaction Specialist Agent"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-29
 ---
 
 ## Source File
 - [[raw/Agent/agency-agents/spatial-computing/xr-cockpit-interaction-specialist.md]]
 
 ## Summary（用中文描述）
-- 核心主题：XR 座舱交互专家 Agent——专注于设计和实现沉浸式座舱式交互环境，融合空间控制与自然人体工学
-- 问题域：如何在 XR 环境中构建高存在感、低眩晕的固定视角座舱交互系统
-- 方法/机制：固定视角（fixed-perspective）高存在感交互区设计、人体工学对齐（眼-手-头协调）、约束驱动控制机制（constraint-driven）、多模态交互集成（手势+语音+注视+物理道具）
-- 结论/价值：提供真实感与舒适度并重的 XR 座舱解决方案，适用于模拟指挥中心、航天器座舱、XR 载具界面和训练模拟器
+- 核心主题：XR 座舱交互专家 Agent 的角色定义与能力边界，专注于沉浸式座舱环境的控件设计
+- 问题域：如何在 XR 环境中构建自然、高存在感且符合人体工程学的座舱交互系统
+- 方法/机制：通过固定视角约束、手势/语音/凝视多模态输入、3D 网格控件与约束驱动机制实现沉浸式交互
+- 结论/价值：座舱式交互是降低 XR 晕动症、提升空间控制精度的最佳实践范式
 
 ## Key Claims（用中文描述）
-- XR 座舱交互通过固定视角设计（fixed-perspective）和高存在感交互区（high-presence interaction zones）显著提升沉浸感体验
-- 约束驱动控制机制（constraint-driven control mechanics）消除自由漂浮运动，有效降低用户眩晕感
-- 座舱人体工学设计需对齐自然的眼-手-头协调流动（eye–hand–head flow），确保长时间使用舒适性
-- 多模态交互集成（手势、语音、注视、物理道具）为用户提供灵活自然的控制选择
+- Agent 通过固定视角锚定用户，减少空间迷失感和晕动症
+- 座舱控件采用 3D 网格 + 输入约束设计，替代自由浮动交互
+- 多输入 UX 融合手势、语音、凝视与物理道具，提升自然性
+- A-Frame / Three.js 是快速原型座舱布局的核心技术栈
+- 坐姿交互设计需对齐眼-手-头自然流程，优化人体工程学
 
 ## Key Quotes
-> "You create fixed-perspective, high-presence interaction zones that combine realism with user comfort." — Agent 核心定位：固定视角高存在感交互区设计
+> "Design hand-interactive yokes, levers, and throttles using 3D meshes and input constraints" — 核心交互范式定义
+> "Minimize disorientation by anchoring user perspective to seated interfaces" — 晕动症缓解策略
+> "Implement constraint-driven control mechanics (no free-float motion)" — 技术实现原则
 
 ## Key Concepts
-- [[Constraint-Driven-Control-Mechanics]]：约束驱动控制机制——通过 3D meshes 和输入约束实现的控制物理化设计，取代自由漂浮式交互
-- [[Cockpit-Ergonomics]]：座舱人体工学——对齐自然的眼-手-头协调流动，优化长时间使用的舒适度
-- [[Spatial-Computing]]：空间计算——XR 环境的核心技术基础，支持 3D 空间中的交互设计
-- [[Motion-Sickness-Threshold]]：运动病阈值——通过固定视角和约束驱动设计将其最小化
+- [[Cockpit-Based Immersive Interface]]：固定视角座舱式沉浸界面，通过锚定用户视角降低眩晕感
+- [[Constraint-Driven Control Mechanics]]：约束驱动的控制机制，限制自由浮动以提升交互精度
+- [[Multi-Input UX]]：多输入用户体验，融合手势、语音、凝视等多种交互模态
+- [[XR Motion Sickness Threshold]]：XR 晕动症阈值，指导坐姿交互设计的舒适边界
 
 ## Key Entities
-- [[XR-Cockpit-Interaction-Specialist]]：本 Agent 角色——空间座舱设计专家，专注于 XR 模拟和载具界面
+- [[XR Interface Architect]]：XR 接口架构师，上游角色，定义整体交互框架
+- [[XR Immersive Developer]]：XR 沉浸式开发者，协同角色，负责渲染与交互实现
+- [[A-Frame]]：WebVR 框架，用于快速原型座舱布局
+- [[Three.js]]：3D 图形引擎，用于精细座舱控件开发
 
 ## Connections
-- [[XR-Interface-Architect]] ← builds_upon ← [[XR-Cockpit-Interaction-Specialist]]
-- [[XR-Immersive-Developer]] ← collaborates ← [[XR-Cockpit-Interaction-Specialist]]
-- [[Terminal-Integration-Specialist]] ← extends ← [[XR-Cockpit-Interaction-Specialist]]
+- [[XR Interface Architect]] ← builds upon ← [[XR Cockpit Interaction Specialist]]
+- [[XR Cockpit Interaction Specialist]] ← extends ← [[Cockpit-Based Immersive Interface]]
+- [[XR Immersive Developer]] ← depends_on ← [[XR Cockpit Interaction Specialist]]
 
 ## Contradictions
-- 与 [[XR-Immersive-Developer]] 在运动自由度上存在设计张力：后者倾向开放空间沉浸体验，前者强调固定视角约束以降低眩晕；当前观点：座舱场景优先舒适性与真实感，通用沉浸场景可保留开放自由度
+- （暂无已知冲突）
diff --git a/wiki/sources/xr-immersive-developer.md b/wiki/sources/xr-immersive-developer.md
index aaedb6ff..c9799098 100644
--- a/wiki/sources/xr-immersive-developer.md
+++ b/wiki/sources/xr-immersive-developer.md
@@ -2,54 +2,60 @@
 title: "XR Immersive Developer Agent Personality"
 type: source
 tags: []
-date: 2026-04-20
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/spatial-computing/xr-immersive-developer.md]]
+- [[Agent/agency-agents/spatial-computing/xr-immersive-developer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：XR Immersive Developer Agent——基于 WebXR 技术的沉浸式浏览器 AR/VR/XR 应用开发专家智能体
-- 问题域：如何在浏览器环境下构建跨平台、高性能、具备手部追踪/注视/控制器输入的沉浸式 3D 体验
-- 方法/机制：使用 A-Frame / Three.js / Babylon.js 构建模块化组件化 XR 应用，通过 raycasting、hit testing、实时物理引擎实现沉浸交互，通过 occlusion culling、shader tuning、LOD 系统优化性能，兼容 Meta Quest / Vision Pro / HoloLens / mobile AR
-- 结论/价值：提供一套完整的前端 WebXR 工程能力——从原型开发到性能优化，从交互设计到跨设备兼容覆盖
+- 核心主题：WebXR 沉浸式开发专家智能体的人格定义与技术栈规范，专注于在浏览器环境下构建跨平台高性能 AR/VR/XR 体验。
+- 问题域：如何通过浏览器原生 WebXR 技术实现沉浸式 3D 应用，跨越 Meta Quest、Vision Pro、HoloLens、移动 AR 等多设备平台。
+- 方法/机制：使用 A-Frame / Three.js / Babylon.js 作为核心渲染框架；集成 WebXR Device API 全套输入（hand tracking / pinch / gaze / controller input）；通过 raycasting、hit testing、实时物理交互实现沉浸式交互；通过 LOD 系统、occlusion culling、shader tuning 实现性能优化；通过模块化组件驱动设计确保可维护性和优雅降级。
+- 结论/价值：浏览器端 WebXR 是 XR 分发的最优路径——无需安装 App 即可触达全平台用户；通过模块化组件架构和性能优化策略，可在资源受限的浏览器环境中实现生产级沉浸式体验。
 
 ## Key Claims（用中文描述）
-- XR Immersive Developer 通过 WebXR Device API 实现浏览器端完整沉浸式支持（hand tracking / pinch / gaze / controller input）
-- A-Frame / Three.js / Babylon.js 是核心 3D 引擎栈，覆盖从快速原型到高级渲染的完整需求
-- 性能优化通过 occlusion culling、shader tuning、LOD 系统三条路径协同实现
-- 跨设备兼容（Meta Quest / Vision Pro / HoloLens / mobile AR）需要显式兼容性层管理
-- 模块化组件驱动设计确保 XR 体验可复用、降级优雅、便于维护
+- WebXR 浏览器技术栈（A-Frame / Three.js / Babylon.js）是 XR 应用跨平台分发的最优起点，可同时覆盖桌面浏览器、移动 AR 和 XR 头显设备。
+- 完整的 WebXR Device API 支持（hand tracking / pinch / gaze / controller input）是沉浸式交互的基础能力，必须全套实现。
+- 性能优化（occlusion culling / shader tuning / LOD 系统）是浏览器端 XR 应用的生产级门槛，决定了体验的流畅度和可用性。
+- 跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）是商业化 XR 应用的核心要求，必须在架构层面预留适配能力。
+- 模块化组件驱动设计 + 优雅降级策略是保证 XR 应用可维护性和可访问性的工程基础。
 
 ## Key Quotes
-> "You are **XR Immersive Developer**, a deeply technical engineer who builds immersive, performant, and cross-platform 3D applications using WebXR technologies." — Agent 身份定义
-> "You bridge the gap between cutting-edge browser APIs and intuitive immersive design." — 核心价值定位
-> "You've shipped simulations, VR training apps, AR-enhanced visualizations, and spatial interfaces using WebXR" — 工程经验总结
+> "You are **XR Immersive Developer**, a deeply technical engineer who builds immersive, performant, and cross-platform 3D applications using WebXR technologies." — 智能体核心定位
+> "Performance-aware, clean coder, highly experimental" — 核心人格特质
+> "Build modular, component-driven XR experiences with clean fallback support." — 核心工程原则
 
 ## Key Concepts
-- [[WebXR]]：浏览器原生沉浸式计算 API，支撑 AR/VR/XR 跨设备体验
-- [[A-Frame]]：Mozilla 出品的 Three.js 封装框架，适合快速 WebXR 原型开发
-- [[Three.js]]：底层 WebGL 3D 渲染引擎，A-Frame 的核心依赖
-- [[Babylon.js]]：微软出品的专业级 WebXR 3D 引擎，强大的工具链和 XR 支持
-- [[Hand-Tracking]]：WebXR Hand Input Module，手部追踪交互能力
-- [[LOD-System]]：Level of Detail 渲染优化，根据距离动态调整模型精度
-- [[Occlusion-Culling]]：遮挡剔除性能优化，不渲染被遮挡的物体
+- [[WebXR]]：浏览器原生 XR API 规范，提供沉浸式 VR/AR 会话管理、输入追踪和渲染管线
+- [[A-Frame]]：Three.js 之上的声明式 WebXR 框架，通过 HTML 属性快速构建 3D 场景
+- [[Three.js]]：底层 WebGL JavaScript 3D 库，提供渲染器、场景图、几何体、材质和动画系统
+- [[Babylon.js]]：Microsoft 出品的 WebGL 3D 引擎，提供高性能渲染管线和丰富工具链
+- [[Raycasting]]：从视点发射射线与 3D 场景物体相交的技术，用于交互检测和选择
+- [[Hit Testing]]：AR 设备的空间表面检测，将虚拟内容锚定到真实世界表面
+- [[LOD Systems]]（Level of Detail）：根据物体距摄像机距离动态切换模型精度，优化渲染性能
+- [[Occlusion Culling]]：剔除被其他物体遮挡的物体，避免不必要的渲染计算
+- [[Graceful Degradation]]：优雅降级，在低端设备上自动降低画质保证可用性
 
 ## Key Entities
-- [[Meta Quest]]：Facebook/Meta 的 VR 头显，WebXR 主要目标平台之一
-- [[Vision Pro]]：Apple 空间计算设备，WebXR 重要目标平台
-- [[HoloLens]]：Microsoft 的 AR 头显，WebXR 兼容设备
-- [[Mobile AR]]：移动端增强现实（ARKit/ARCore），跨平台 WebXR 目标
+- [[The Agency]]：提供 147 个专业智能体的多智能体协作框架，XR Immersive Developer 隶属 Spatial Computing 部门
+- [[Spatial Computing]]：The Agency 的产品部门方向，涵盖 AR/VR/XR 全谱系智能体
+- [[XR Interface Architect]]：Spatial Computing 部门 UX/UI 设计专家，与本智能体共同构建 XR 产品交互基础设施
+- [[XR Cockpit Interaction Specialist]]：Spatial Computing 部门座舱交互专家，在运动自由度设计上与本智能体存在张力（固定视角 vs 开放空间）
+- [[visionOS Spatial Engineer]]：Apple visionOS 原生开发专家，与本智能体互补（浏览器端 vs 原生平台）
+- [[macOS Spatial/Metal Engineer]]：Apple Metal 渲染专家，与本智能体互补（浏览器端 WebXR vs 原生 Metal 渲染管线）
 
 ## Connections
-- [[XR-Interface-Architect]] ← depends_on ← [[XR-Immersive-Developer]]（前者依赖后者的沉浸式渲染和交互能力）
-- [[XR-Cockpit-Interaction-Specialist]] ← shares_domain ← [[XR-Immersive-Developer]]（同属 Spatial Computing 部门）
-- [[macOS-Spatial-Metal-Engineer]] ← complements ← [[XR-Immersive-Developer]]（前者负责平台底层，后者负责浏览器层）
-- [[visionOS-Spatial-Engineer]] ← complements ← [[XR-Immersive-Developer]]（前者专注文果空间计算平台，后者专注浏览器跨平台）
+- [[xr-interface-architect]] ←协作← [[xr-immersive-developer]]（两者共同构建 XR 产品交互基础设施）
+- [[xr-cockpit-interaction-specialist]] ←协作/张力← [[xr-immersive-developer]]（座舱约束 vs 开放空间沉浸）
+- [[visionos-spatial-engineer]] ←互补← [[xr-immersive-developer]]（浏览器端 vs Apple 原生平台）
+- [[macos-spatial-metal-engineer]] ←互补← [[xr-immersive-developer]]（WebXR vs Metal 渲染）
+- [[Spatial Computing]] ←所属← [[xr-immersive-developer]]（部门归属）
+- [[engineering-mobile-app-builder]] ←关联← [[xr-immersive-developer]]（移动开发能力扩展）
 
 ## Contradictions
-- 与 [[XR-Cockpit-Interaction-Specialist]] 冲突：
-  - 冲突点：运动自由度设计哲学
-  - 当前观点（XR-Immersive-Developer）：倾向开放空间沉浸体验，最大化运动自由度
-  - 对方观点（XR-Cockpit-Interaction-Specialist）：强调固定视角约束（constraint-driven control mechanics）以降低运动病阈值
-  - 说明：两者代表 XR 交互设计的两种范式——沉浸派 vs 安全派，在不同场景下各有优势
+- 与 [[xr-cockpit-interaction-specialist]] 冲突：
+  - 冲突点：运动自由度的设计哲学——开放空间沉浸 vs 固定视角约束
+  - 当前观点（本智能体）：倾向开放空间沉浸体验，充分释放 XR 的存在感和临场感
+  - 对方观点：强调固定视角约束以降低运动病阈值，通过物理化控制机制提升操作精度
+  - 协调方向：两者可针对不同场景分工——xr-immersive-developer 适合探索类应用，xr-cockpit-interaction-specialist 适合模拟训练和座舱类应用
diff --git a/wiki/sources/xr-interface-architect.md b/wiki/sources/xr-interface-architect.md
index f584666c..3025e247 100644
--- a/wiki/sources/xr-interface-architect.md
+++ b/wiki/sources/xr-interface-architect.md
@@ -1,49 +1,50 @@
----
-title: "XR Interface Architect Agent Personality"
-type: source
-tags: ["agent-personality", "spatial-computing", "ux-design", "ar-vr-xr"]
-date: 2026-04-25
----
-
-## Source File
-- [[raw/Agent/agency-agents/spatial-computing/xr-interface-architect.md]]
-
-## Summary（用中文描述）
-- 核心主题：定义一个专为 AR/VR/XR 沉浸式环境设计空间化用户界面的 AI Agent 个性
-- 问题域：如何在 3D 空间中创建直觉化、舒适且可发现的交互界面，同时减少晕动症、增强存在感
-- 方法/机制：通过 HUD、浮动菜单、交互区域设计，支持多种输入模型（手势、注视+捏合、控制器），基于人体工程学约束布局 UI
-- 结论/价值：提供一个以人为中心、感知驱动的研究型 Agent，可为沉浸式应用定义 UI 流程、构建布局模板并运行可用性验证实验
-
-## Key Claims（用中文描述）
-- XR Interface Architect 通过设计空间直觉化用户体验来定义其核心使命
-- 该 Agent 支持多种输入模型：直接触摸、注视+捏合、控制器和手势
-- UI 放置遵循基于舒适度的约束原则，以减少晕动症
-- 该 Agent 可构建座舱、仪表盘或可穿戴界面的布局模板
-- 该 Agent 专注于沉浸式搜索、选择和操作的交互原型设计
-
-## Key Quotes
-> "Designs spatial interfaces where interaction feels like instinct, not instruction." — 核心理念，定义交互的最高目标
-> "Human-centered, layout-conscious, sensory-aware, research-driven" — Agent 人格特质，四个维度
-> "Recommend comfort-based UI placement with motion constraints" — 减少晕动症的核心设计策略
-
-## Key Concepts
-- [[SpatialInterfaceDesign]]：空间界面设计 — 在 3D 环境中创建直觉化用户界面的设计方法论
-- [[MotionSicknessMitigation]]：晕动症缓解 — 通过 UI 放置约束和运动限制减少 VR 使用中的不适感
-- [[PresenceEnhancement]]：存在感增强 — 通过界面设计提升用户在沉浸式环境中的临场感
-- [[MultimodalInput]]：多模态输入 — 支持手势、注视、控制器等多种交互方式的输入架构
-- [[HUDDesign]]：抬头显示器设计 — 在 XR 环境中创建浮动信息面板的设计实践
-
-## Key Entities
-- [[XRImmersiveDeveloper]]：XR 沉浸式开发者 — 该 Agent 的主要协作对象，负责实现 3D 环境
-- [[XRCockpitInteractionSpecialist]]：XR 座舱交互专家 — 同为 spatial-computing 领域，协作设计驾驶舱交互
-
-## Connections
-- [[XRImmersiveDeveloper]] ← collaborates_with ← [[XRInterfaceArchitect]]
-- [[XRCockpitInteractionSpecialist]] ← related_to ← [[XRInterfaceArchitect]]
-- [[DesignUXArchitect]] ← extends ← [[DesignUIDesigner]]
-
-## Contradictions
-- 暂无发现冲突
-
-## Notes
-- 该 Agent 与 [[macOS Spatial/Metal Engineer Agent Personality]] 同属 spatial computing 领域，但侧重点不同：前者关注 3D 界面设计，后者关注空间计算底层工程实现
+---
+title: "XR Interface Architect Agent Personality"
+type: source
+tags: []
+date: 2026-04-29
+---
+
+## Source File
+- [[raw/Agent/agency-agents/spatial-computing/xr-interface-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：XR Interface Architect 是专为沉浸式 AR/VR/XR 环境设计的空间交互设计师和界面策略师
+- 问题域：如何在 3D 空间中创建直觉化、舒适且可发现的用户界面，同时减少晕动症、增强存在感
+- 方法/机制：通过 HUD、浮动菜单、面板和交互区域设计，结合多种输入模型（直接触摸、注视+捏合、控制器、手势）实现空间交互
+- 结论/价值：为 XR 应用提供以人为本的 UX/UI 设计方法论，填补传统 2D 界面设计向 3D 空间交互过渡的专业能力缺口
+
+## Key Claims（用中文描述）
+- XR Interface Architect 通过支持多种输入模型（直接触摸、注视+捏合、控制器、手势），为 AR/VR/XR 应用提供灵活的空间交互方案
+- XR Interface Architect 通过舒适度约束的 UI 布局推荐，有效降低用户晕动症风险并增强沉浸感
+- XR Interface Architect 通过原型化沉浸式搜索、选择和操作交互，优化 XR 应用的可用性与学习曲线
+- XR Interface Architect 通过多模态输入结构化设计与无障碍备选方案，确保 XR 应用对不同能力水平用户的可访问性
+
+## Key Quotes
+> "Designs spatial interfaces where interaction feels like instinct, not instruction." — Agent Vibe 描述
+
+## Key Concepts
+- [[SpatialComputing]]：在物理空间中定位和操控数字内容的计算范式
+- [[HUDDesign]]：抬头显示器设计，为 XR 环境中的用户提供非侵入式信息呈现
+- [[MotionSickness]]：XR 环境中因视觉与前庭系统不匹配导致的晕动症，是空间 UI 设计的核心挑战
+- [[GazeInteraction]]：基于眼部注视的交互模型，是 XR 界面设计的重要输入方式
+- [[MultimodalInput]]：融合多种输入通道（视觉、触觉、手势、语音）的交互架构
+- [[PresenceUX]]：增强用户在虚拟环境中的"存在感"的体验设计原则
+- [[AccessibilityInXR]]：为不同能力水平用户提供可访问 XR 体验的设计考量
+
+## Key Entities
+- [[XRImmersiveDeveloper]]：XR 沉浸式开发者，与 Interface Architect 协作实现 3D 场景中的可用性
+- [[XRCockpitInteractionSpecialist]]：XR 驾驶舱交互专家，专注座舱类 XR 界面的深度交互设计
+- [[VisionOSSpatialEngineer]]：visionOS 空间工程师，Apple 生态下的 XR 开发实现者
+
+## Connections
+- [[XRImmersiveDeveloper]] ← collaborates_with ← [[XRInterfaceArchitect]]
+- [[XRCockpitInteractionSpecialist]] ← shares_patterns_with ← [[XRInterfaceArchitect]]
+- [[VisionOSSpatialEngineer]] ← implements_ui_for ← [[XRInterfaceArchitect]]
+- [[DesignUXArchitect]] ← parent_discipline ← [[XRInterfaceArchitect]]
+
+## Contradictions
+- 与 [[XRCockpitInteractionSpecialist]] 存在关注点差异：
+  - 冲突点：UI 放置策略——驾驶舱交互专家倾向于固定/约束式布局以确保安全；Interface Architect 更强调灵活的空间定位
+  - 当前观点：XR Interface Architect 主张以人为中心，允许用户自定义界面位置以优化个人舒适区
+  - 对方观点：XRCockpitInteractionSpecialist 主张关键安全控件应固定在视野中心区域以确保快速访问
diff --git a/wiki/sources/zk-steward.md b/wiki/sources/zk-steward.md
index 1b1e80f0..b4aa3a3c 100644
--- a/wiki/sources/zk-steward.md
+++ b/wiki/sources/zk-steward.md
@@ -1,64 +1,62 @@
 ---
 title: "ZK Steward Agent"
 type: source
-tags: [AI-agent, knowledge-management, zettelkasten, luhmann, productivity]
-date: 2026-04-25
+tags: []
+date: 2026-05-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/zk-steward.md]]
+- [[Agent/agency-agents/specialized/zk-steward.md]]
 
 ## Summary（用中文描述）
-- 核心主题：ZK Steward——以 Niklas Luhmann 的 Zettelkasten 精神构建的 AI 时代知识库管家 Agent，通过原子笔记、连接驱动和验证循环实现有机知识网络增长。
-- 问题域：AI Agent 如何避免"一次性回答"陷阱，构建可持续积累、互相连接的知识库；如何在复杂任务中切换领域专家视角以产出深度内容。
-- 方法/机制：
-  - **Luhmann 四原则验证门**：原子性（独立可理解）/ 连接性（≥2 个有意义链接）/ 有机增长（避免过度结构化）/ 持续对话（激发进一步思考）
-  - **领域专家切换机制**：按 domain × task type × output form 三角定位，选取对应领域顶级思维（Luhmann 默认，Feynman 学习/Karpathy 工程/Munger 策略等）
-  - **Zettelkasten 工作流**：创建/归档笔记时先问"与谁对话"→建链接；再问"在哪里找到"→建议索引入口
-  - **文件归档默认**：时间路径（`YYYY/MM/YYYYMMDD/`），禁止路由到 legacy/historical-only 目录
-  - **关闭清单**：四原则检查 → 文件+网络（≥2 链接） → 日志更新 → 开放循环扫荡 → 记忆同步
-- 结论/价值：将 Niklas Luhmann 的卡片盒方法论 AI 化，为知识密集型任务提供结构化、可验证、可积累的知识网络基础设施，是 [[Second Brain]] 在 AI Agent 时代的方法论实现。
+- 核心主题：ZK Steward Agent——将 Niklas Luhmann 的 Zettelkasten（卡片盒笔记法）理念引入 AI Agent，用于构建有链接、可验证、持续生长的知识网络。
+- 问题域：如何让 AI Agent 在管理笔记和知识库时，避免碎片化、过分类、以及单次回答后就遗忘的"一次性 agent"陷阱；如何让知识成为有机网络而非文件夹层级。
+- 方法/机制：Luhmann 四原则验证（原子性 / 连通性 / 有机增长 / 持续对话）+ 领域专家视角切换（按领域 × 任务类型 × 输出形式选择顶级专家）+ 任务闭环清单（日志 / 归档 / 链接提案 / 开放循环清理）。
+- 结论/价值：结构优先、连接至上、验证驱动——每一回复都声明专家视角、每一笔记都通过 Luhmann 四原则检查、每一个知识单元都嵌入网络而非孤立存在。
 
 ## Key Claims（用中文描述）
-- ZK Steward 以 Niklas Luhmann 的 Zettelkasten 方法论为默认视角，切换到各领域顶级专家（Feynman/Munger/Ogilvy/Karpathy 等）按任务类型匹配，产出深度领域内容。
-- 每个回复必须声明专家视角 + 称呼用户名，拒绝泛泛"专家"或空头方法论引用。
-- 笔记四原则验证门（原子性/连接性/有机增长/持续对话）强制笔记可独立理解且互连成网。
-- 新笔记归档时自动触发链接提议（Link-proposer）：候选链接 + 关键词 + Gegenrede 反诘问题。
-- 任务关闭必须完成： Luhmann 四原则检查 → 文件路径+≥2 链接 → 日志更新 → 开放循环扫荡 → 记忆同步。
-- 禁止：跳过验证、创建零链接笔记、路由到 legacy-only 目录。
+- ZK Steward Agent 始终以 Niklas Luhmann 的 Zettelkasten 原则为默认视角，通过将复杂任务分解为原子笔记并用 wikilink 连接，使知识库有机生长而非陷入文件夹层级。
+- 领域专家切换机制（Luhmann 默认 / Feynman 学 / Munger 策略 / Ogilvy 品牌 / Karpathy 工程等）通过"领域 × 任务类型 × 输出形式"三角定位，选择最匹配的专家心智模型。
+- Luhmann 四原则验证（原子性 / 连通性 / 有机增长 / 持续对话）是强制门控：笔记必须可独立理解、拥有 ≥2 条有意义链接、避免过度结构化、并能激发后续思考。
+- 任务闭环检查清单包含：Luhmann 四原则验证、归档路径与 ≥2 链接描述、每日日志更新、开放循环清理、以及新笔记的链接提案（候选 + 关键词 + Gegenrede 反问）。
+- 知识网络的增长靠链接和索引条目驱动，而非文件夹层级；索引条目是入口点而非分类，一个笔记可以同时被多个索引指向。
 
 ## Key Quotes
-> "Niklas Luhmann for the AI age—turning complex tasks into organic parts of a knowledge network, not one-off answers." — ZK Steward 身份定义
-> "Index entries are entry points, not categories; one note can be pointed to by many indices." — Luhmann 索引哲学
-> "Never: skip the perspective statement, use a vague 'expert' label, or name-drop without applying the method." — 关键规则
+> "From [Expert name / school of thought]'s perspective..." — ZK Steward 在每条回复的首句声明专家视角（强制要求，不可省略）
+
+> "Every reply states the expert perspective and addresses the user by name. Never generic 'expert' or name-dropping without method." — Agent 的每条回复必须同时包含用户姓名称呼和专家视角声明，否则违反核心规则
+
+> "Atomicity / Connectivity / Organic growth / Continued dialogue" — Luhmann 四原则的完整表述，每条笔记都必须通过这四问才能归档
+
+> "Link-proposer: after proposing links, ask one counter-question from a different discipline to spark dialogue (Gegenrede)." — 链接提案流程中，在推荐链接候选后，必须从不同学科提一个反问以激发跨领域对话
 
 ## Key Concepts
-- [[Zettelkasten]]：德国社会学家 Niklas Luhmann 发明的手动卡片笔记系统——每条笔记原子化、拥有唯一 ID、与至少一条其他笔记相连，通过积累形成有机知识网络。ZK Steward 将其 AI 化，以时间路径归档、索引入口导向、多链接驱动为核心理念。
-- [[Luhmann-四原则]]（原子性/连接性/有机增长/持续对话）：ZK Steward 的强制验证门，每条笔记必须通过四个维度检查方可归档，是 Zettelkasten 方法论的执行性约束。
-- [[Domain-Thinking]]（领域思维）：按 domain × task type × output form 三维定位，选取该领域顶级专家视角驱动输出，确保深度而非泛泛。
-- [[Gegenrede]]（反诘）：链接提议后提出一个跨学科反问，激发笔记间的辩证对话，防止同质化链接。
-- [[Atomic-Note]]（原子笔记）：可独立理解、最小粒度的知识单元，是 Zettelkasten 的基本构建块。
-- [[Link-Proposer]]（链接提议器）：新笔记归档时自动运行的流程——输出候选链接 + 关键词 + Gegenrede 反诘问题。
-- [[Daily-Log]]（每日日志）：`memory/YYYY-MM-DD.md` 格式，记录 Intent / Changes / Open loops，维持知识网络的时效性。
+- [[Zettelkasten]]：Luhmann 的卡片盒笔记系统——原子笔记 + 唯一 ID + 链接网络，使知识有机增长而非层级分类；ZK Steward 的方法论根基。
+- [[Domain-Expert-Switching]]：按"领域 × 任务类型 × 输出形式"三角定位，在多个专家心智模型（Feynman/Munger/Ogilvy/Karpathy 等）间切换，以输出领域深度的内容。
+- [[Atomic-Note]]：最小的自包含知识单元——可独立理解、拥有 ≥2 条链接、避免过分类、激发后续思考；ZK Steward 的基本工作单位。
+- [[Luhmann-Four-Principles]]：原子性（可独立理解）、连通性（≥2 有意义链接）、有机增长（避免过度结构化）、持续对话（激发后续思考）；笔记归档的强制验证门。
+- [[Gegenrede]]：链接提案后的反问步骤——从不同学科提一个反问题，以打破回音室效应、激发跨领域对话。
+- [[Deep-Learning]]：ZK Steward 的高级能力之一——对书籍/长文章/报告的深度阅读流程，输出结构笔记（Folgezettel 风格论证链）+ 原子笔记 + 执行计划。
 
 ## Key Entities
-- [[Niklas-Luhmann]]：德国社会学家（1927-1998），Zettelkasten 卡片盒知识管理法创始人，一生积累 9 万+张卡片，产出 70 部著作。ZK Steward 以其为默认视角。
-- [[zk-steward-companion]]（GitHub repo）：ZK Steward 的配套技能库，包含 link-proposer / index-note / strategic-advisor / workflow-audit / structure-note / random-walk / deep-learning 等可选用工作流。
-- **Karpathy**：AI/工程领域专家，按 domain-thinking 映射表对应 Tech/engineering 领域。
-- **Charlie Munger**：商业策略领域专家，按 domain-thinking 映射表对应 Business strategy（Mental models, inversion）。
-- **Richard Feynman**：学习/研究领域专家，按 domain-thinking 映射表对应 Learning/research（First principles, teach to learn）。
-- **David Ogilvy**：品牌营销领域专家，对应 Brand marketing（Long copy, brand persona）。
+- [[Niklas-Luhmann]]：德国社会学家，Zettelkasten（卡片盒笔记法）发明者；ZK Steward 的方法论祖师。
+- [[Richard-Feynman]]：物理学诺奖得主，"first principles, teach to learn" 学习法代表；ZK Steward 用于学习和研究任务的专家视角。
+- [[Charlie-Munger]]：伯克希尔·哈撒韦副主席，"mental models, inversion" 策略思维代表；ZK Steward 用于商业策略任务的专家视角。
+- [[David-Ogilvy]]：奥美广告创始人，"long copy, brand persona" 品牌营销方法代表；ZK Steward 用于品牌营销任务的专家视角。
+- [[Andrej-Karpathy]]：OpenAI/特斯拉前高管，Karpathy 式第一性工程思维代表；ZK Steward 用于 AI/工程任务的专家视角。
+- [[Ethan-Mollick]]：AI prompting 领域专家，"structured prompts, persona pattern" 方法代表；ZK Steward 用于 AI/prompts 任务的专家视角。
 
 ## Connections
-- [[zk-steward]] ← implements ← [[Zettelkasten]]
-- [[zk-steward]] ← applies ← [[Niklas-Luhmann]]
-- [[zk-steward]] ← uses ← [[Luhmann-四原则]]
-- [[zk-steward]] ← triggers ← [[Link-Proposer]]
-- [[zk-steward]] ← follows ← [[Domain-Thinking]]
-- [[zk-steward]] ← part_of ← [[zk-steward-companion]]
-- [[Second-Brain]] ← related_to ← [[zk-steward]]（两者同属外部认知能力建设，Second Brain 为通用框架，ZK Steward 为具体 Agent 实现）
-- [[养虾日记3]] ← mentions ← [[zk-steward]]（"融合了 Karpathy 的 LLM Wiki 理念"即指 zk-steward 类型的 Zettelkasten 工作流）
+- [[Agents-Orchestrator]] ← builds on ← [[Zettelkasten]]
+- [[Second-Brain]] ← aligns with ← [[Zettelkasten]]
+- [[Personal-Knowledge-Base-RAG]] ← extends ← [[Zettelkasten]] + [[Atomic-Note]]
+- [[Luhmann-Four-Principles]] ← validates ← [[Atomic-Note]]
+- [[Domain-Expert-Switching]] ← implemented in ← [[ZK-Steward-Agent]]
 
 ## Contradictions
-- 与 [[Second-Brain]] 关系：两者均强调外部知识积累，但 Second Brain 侧重捕获与检索的零摩擦（"像发短信一样简单"），ZK Steward 侧重强制结构化验证（ Luhmann 四原则）和多专家视角切换。两者互补，Second Brain 作为捕获层，ZK Steward 作为结构化处理层。
-- 与 [[agents-orchestrator]]：Agents Orchestrator 强调流水线质量门控（每个任务必须通过截图验证才能推进），ZK Steward 强调知识积累验证（四原则检查）；前者面向任务执行可靠性，后者面向知识增长质量。
+- 与 [[Agents-Orchestrator]] 存在张力：
+  - 冲突点：ZK Steward 强调笔记的自包含性（原子性）和有机生长（避免过度预定义分类），而 Agents Orchestrator 更关注任务分解和 Agent 协调流程；两者对"结构 vs 自组织"的权重不同。
+  - 当前观点：ZK Steward 的原子笔记 + wikilink 网络是知识持久化的最优结构，结构应在网络生长过程中涌现而非预设。
+  - 对方观点：Agents Orchestrator 强调任务分解的显式规划和 Agent 间协调，知识应在任务执行中被构建而非预先存储。
+- 与 [[Personal-Knowledge-Base-RAG]] 存在互补而非矛盾：
+  - ZK Steward 的原子笔记 + wikilink 网络为 RAG 提供高质量的结构化知识输入；两者协同：ZK Steward 构建笔记网络 → RAG 检索利用。
diff --git a/wiki/sources/如何让ai生成风格一致的图片.md b/wiki/sources/如何让ai生成风格一致的图片.md
new file mode 100644
index 00000000..24781094
--- /dev/null
+++ b/wiki/sources/如何让ai生成风格一致的图片.md
@@ -0,0 +1,76 @@
+---
+title: "如何让AI生成风格一致的图片"
+type: source
+tags: ["ai", "gemini", "image", "prompt-engineering", "infographic"]
+date: 2026-05-01
+---
+
+## Source File
+- [[AI/如何让AI生成风格一致的图片]]
+
+## Summary（用中文描述）
+- 核心主题：使用 Gemini 生成风格一致的系列图片（6张黑板粉笔风格信息卡）
+- 问题域：AI 图片生成中的风格一致性控制难题
+- 方法/机制：通过"风格种子句"（Style Seed）+ "STYLE LOCK" 机制，在每个提示词中强制锚定统一的风格参数（背景色、线条质量、配色方案、边框样式），确保多张图片视觉高度统一
+- 结论/价值：组合使用"种子句开头 + 统一模板 + 末尾 STYLE LOCK"三种方法，可实现 ★★★★★ 一致性，适用于需要批量生成风格统一图片的场景（PPT、信息图、品牌素材等）
+
+## Key Claims（用中文描述）
+- 在每个提示词开头加入完全相同的风格定义句（Style Seed），可锚定视觉基线，实现跨卡片风格一致性
+- 严格限制颜色为 6 色色板（白、黄、粉、蓝、绿、橙），禁止渐变和完美几何形状，确保所有元素看起来像手绘粉笔
+- 在每张图片的提示词末尾统一加 STYLE LOCK 块，强制比对上一张的风格参数，偏差即重生成
+- 推荐组合策略（方法 1+3+5）：开头种子句 + 统一模板结构 + 结尾 STYLE LOCK，不论先生成哪张，风格锚点完全一致
+- 使用参考图（第一张生成的图片）作为后续图片的视觉基准，效果最强（★5），但需保存中间图
+
+## Key Quotes
+> "You are generating an infographic card in a consistent chalkboard educational style. Maintain these rules across ALL cards: dark green-black chalkboard background (#1C2B1C), hand-drawn chalk white (#F5F5F5) text with imperfect sketchy lines, chalk dust texture, wooden frame border, NO perfect geometric shapes, NO gradients." — 风格种子句标准模板
+
+> "⚠️ STYLE LOCK: This card MUST match all previous cards exactly. Same background, same chalk texture, same color hex values, same hand-drawn quality. Do not vary the style for any reason." — STYLE LOCK 块标准模板
+
+## Key Concepts
+- [[StyleSeed]]：风格种子句，在每个提示词开头加入完全相同的风格定义句，作为风格锚定基线，核心参数包括背景色、线条质量、配色、边框样式
+- [[StyleLock]]：风格锁定块，在提示词末尾加强制检查清单，要求生成前逐项比对上一张图片的风格参数，确保完全匹配
+- [[ChalkboardStyle]]：黑板粉笔风格，一种复古手绘视觉风格，通过深绿黑背景（#1C2B1C）+ 手绘粉笔线条 + 6 色配色盘 + 木框边框实现统一的视觉氛围
+- [[PromptEngineering]]：提示词工程，通过精心设计的指令结构（种子句 + 模板 + 锁定块）引导 AI 生成符合预期的高一致性内容
+- [[ReferenceImageConsistency]]：参考图一致性策略，用第一张生成的图片作为后续图片的视觉基准，通过"保持与参考图完全相同风格"的指令实现最强一致性
+
+## Key Entities
+- [[Gemini]]：Google 的多模态 AI 模型，支持图片生成（Gemini Image Gen），支持多轮对话中的风格上下文传递
+- [[NanoBanana]]：作者使用的 AI 工具品牌，可能指 Google Gemini Nano/Banana 系列或其提示词框架
+
+## Connections
+- [[StyleSeed]] ← depends_on ← [[PromptEngineering]]
+- [[StyleLock]] ← extends ← [[StyleSeed]]
+- [[Gemini]] ← generates ← [[ChalkboardStyle]] (via [[StyleSeed]] + [[StyleLock]])
+- [[ReferenceImageConsistency]] ← enhances ← [[StyleLock]]
+
+## Contradictions
+- 与 [[PromptEngineering]] 中"简洁提示词更有效"的常见观点冲突：
+  - 冲突点：本文主张使用超长、重复的完整风格描述，而非简短指令
+  - 当前观点：长格式、逐项列举的风格锁定清单能最大化 AI 对风格参数的记忆和复现
+  - 对方观点：简短提示词减少噪声，提高生成速度和灵活性
+
+## 方法对比表
+
+| 方法 | 一致性 | 操作复杂度 |
+|------|--------|-----------|
+| 每张加风格种子句 | ★★★★☆ | 低 |
+| 参考图 + "保持一致" | ★★★★★ | 中（需保存中间图） |
+| 统一模板结构 | ★★★★☆ | 低 |
+| 系统级指令锁定 | ★★★★☆ | 低（一次） |
+| 以上全部组合 | ★★★★★ | 中高 |
+
+## 六张信息卡主题
+1. Saleable & Security（可销售性与安全性）
+2. Cloud Deployment & Configuration（云部署与配置）
+3. HA & Self Recovery（高可用与自恢复）
+4. Upgrade & Patch（升级与补丁）
+5. Backup & Restore + Documentation（备份恢复与文档）
+6. Observability & Service Management（可观测性与服务管理）
+
+## 生成验证清单（每张卡片生成后检查）
+- [ ] 背景是否为 #1C2B1C 深绿黑色黑板？
+- [ ] 所有线条是否看起来手绘/速写？
+- [ ] 颜色是否使用精确的十六进制值？
+- [ ] 是否有木框边框？
+- [ ] 装饰元素（星星、下划线、箭头）是否为手绘？
+- [ ] 是否与上一张卡片视觉一致？