Auto-sync: 2026-04-21 00:02
This commit is contained in:
55
wiki/sources/French-Consulting-Market-Navigator.md
Normal file
55
wiki/sources/French-Consulting-Market-Navigator.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "French Consulting Market Navigator"
|
||||
type: source
|
||||
tags: [agent, french-market, freelance, esn, si]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-french-consulting-market.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:法国 IT 咨询市场(ESN/SI)自由职业者导航工具
|
||||
- 问题域:法国科技咨询市场的费率定位、平台选择、合同谈判和支付周期
|
||||
- 方法/机制:解析 ESN _margin 模型(25-40%)、portage salarial vs micro-entreprise vs SASU 的税费结构对比、平台费率矩阵、季节性市场动态
|
||||
- 结论/价值:帮助独立 IT 顾问最大化有效日费率、最小化支付风险、建立可持续客户关系
|
||||
|
||||
## Key Claims
|
||||
- Portage salarial 结构下 700 EUR/day TJM 实际净收入约 208 EUR/day,微型企业约 546 EUR/day,差距 338 EUR/day
|
||||
- Tier 1 ESN(Accenture、Capgemini)margin 35-50%,议价能力低;Tier 2(Cloudity、Niji)margin 25-40%,可协商
|
||||
- Malt 平台收取 10% 佣金(客户侧),费率公开成为市场锚点
|
||||
- 法国 ESN 链标准 NET-30 实际导致 60-90 天付款延迟
|
||||
- 低于 550 EUR/day 的高级 Salesforce 架构师费率会被 ESN 视为 desperation 信号
|
||||
|
||||
## Key Quotes
|
||||
> "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 净收入对比说明
|
||||
> "Platform rates are public. What you charge on Malt is visible. Your Malt rate becomes your market rate. Price accordingly from day one." — 平台定价策略
|
||||
> "Portage provides unemployment rights (ARE), retirement contributions, and mutuelle. Micro-entreprise provides none of these. The 338 EUR/day gap is the price of social protection." — 社保差异说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Portage Salarial]]:法国特有的自由职业者雇佣结构,由 portage 公司作为雇主代缴社保, freelancers 保留独立性同时获得失业保险和退休金
|
||||
- [[Micro-Entrepreneur]]:法国简化商业结构,年营业额阈值内适用统一税率,无员工社保福利
|
||||
- [[TJM Brut]]:总日均费率(gross daily rate),ESN 向客户收取的日费率
|
||||
- [[ESN Margin]]:ESN 在 TJM brut 和支付给顾问费率之间的加价差额,Tier 1 35-50%,Tier 2 25-40%,Tier 3 15-25%
|
||||
- [[Seasonal Calendar]]:法国 IT 咨询市场的季节性规律(1月预算重启、7-8月夏季放缓、9月返校季高峰)
|
||||
|
||||
## Key Entities
|
||||
- [[Malt]]:法国主流自由职业平台,10% 佣金(客户侧),费率公开
|
||||
- [[collective.work]]:高端自由职业平台,3-5% 佣金+portage 集成,费率 650-800 EUR
|
||||
- [[Comet]]:科技导向平台,15% 佣金,算法匹配
|
||||
- [[Free-Work]]: listings 平台,免费发布+付费选项,费率 500-900 EUR
|
||||
- [[Crème de la Crème]]:高端精选平台,15-20% 佣金,准入严格
|
||||
- [[Accenture]] / [[Capgemini]] / [[Atos]] / [[CGI]]:Tier 1 全球性 ESN
|
||||
- [[Cloudity]] / [[Niji]] / [[SpikeeLabs]]:Tier 2 精品 ESN
|
||||
|
||||
## Connections
|
||||
- [[Portage Salarial]] ← depends_on ← [[French Tax System]]
|
||||
- [[ESN Margin]] ← margin_model ← [[ESN Tier Classification]]
|
||||
- [[Malt]] ← platform ← [[French Freelance Market]]
|
||||
- [[Rate Negotiation Playbook]] ← applies_to ← [[TJM Brut]]
|
||||
|
||||
## Contradictions
|
||||
- 与常见"法国自由职业税率更低"观点冲突:
|
||||
- 冲突点:微型企业实际净收入高于 portage salarial,但缺失社保福利(失业保险、退休金、mutuelle)
|
||||
- 当前观点:338 EUR/day 差距是社会保护的成本
|
||||
- 对方观点:微型企业净收入更高更划算
|
||||
39
wiki/sources/SECURITY.md
Normal file
39
wiki/sources/SECURITY.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Security Policy"
|
||||
type: source
|
||||
tags: [security, open-source, best-practices]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/SECURITY.md]]
|
||||
|
||||
## Summary
|
||||
本项目安全政策,定义漏洞报告流程、响应时间线和贡献者安全规范。项目包含基于 Markdown 的智能体定义文件(纯提示词,非可执行)和 Shell 脚本两类资产。
|
||||
|
||||
## Key Claims
|
||||
- 安全漏洞必须通过 GitHub Security 标签页私下报告,禁止公开 GitHub Issue
|
||||
- 响应时间线:48 小时内确认,7 天内初步评估,修复时间取决于严重程度
|
||||
- 智能体文件 (.md) 为非可执行提示词定义,不应存储 API 密钥或凭证
|
||||
- Shell 脚本 (scripts/) 为可执行文件,合并前必须审查
|
||||
|
||||
## Key Quotes
|
||||
> "Do NOT open a public GitHub issue for security vulnerabilities. Open a private security advisory via GitHub Security tab." — 漏洞报告规范
|
||||
|
||||
> "Never commit API keys, tokens, or credentials" — 贡献者最佳实践
|
||||
|
||||
> "Report suspicious agent definitions that attempt prompt injection" — 提示词注入检测要求
|
||||
|
||||
## Key Concepts
|
||||
- [[提示词注入]]:恶意智能体定义试图通过提示词注入攻击系统安全
|
||||
- [[安全响应时间线]]:48h 确认→7 天评估→修复,标准化的漏洞响应流程
|
||||
|
||||
## Key Entities
|
||||
- [[agency-agents]]:包含安全政策的智能体项目仓库
|
||||
|
||||
## Connections
|
||||
- [[提示词设计]] ← 安全规范 ← [[安全响应时间线]]
|
||||
- [[Prompt Library]] ← 非可执行约束 ← [[安全政策]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突页面
|
||||
72
wiki/sources/academic-anthropologist.md
Normal file
72
wiki/sources/academic-anthropologist.md
Normal file
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: "Anthropologist Agent Personality"
|
||||
type: source
|
||||
tags: [agent, the-agency, cultural-design, anthropology]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-anthropologist.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:The Agency 项目中的文化人类学家智能体(Anthropologist Agent),专注于构建具有人类学深度和文化一致性的虚构社会
|
||||
- 问题域:如何设计真正有意义而非表面异域风情的文化系统,包括亲属制度、信仰体系、仪式结构和交换机制
|
||||
- 方法/机制:功能主义分析、厚描述(Thick Description)、结构人类学、实践理论、文化生态学等人类学理论框架
|
||||
- 结论/价值:任何文化元素必须服务于社会功能,文化设计必须内部自洽,避免文化拼贴和"高贵的野蛮人"偏见
|
||||
|
||||
## Key Claims
|
||||
- 文化设计必须**先功能后美学**——问"这个仪式对社会做什么"而非"这个仪式看起来酷不酷"
|
||||
- 亲属制度是基础设施——家庭组织方式决定继承、政治联盟、居住模式和冲突解决方式
|
||||
- **无文化沙拉**——不能混搭不同语境的文化元素而不理解其原始含义和交互方式
|
||||
- 前工业社会不是更"纯净"或更"自然"的,它们是具有自身政治、冲突和创新的复杂适应系统
|
||||
- **主位(Emic)优先于客位(Etic)**——先理解文化内部视角,再应用外部分析类别
|
||||
- 承认人类学学科的历史包袱——人类学曾是殖民主义工具,需警惕文化描述中的权力不对等
|
||||
|
||||
## Key Quotes
|
||||
> "No culture is random — every practice is a solution to a problem you might not see yet" — Anthropologist Agent 核心理念
|
||||
|
||||
> "In a patrilineal society, your father's brother's children are your siblings, not your cousins. This changes everything about inheritance." — Anthropologist Agent 关于亲属制度重要性的具体说明
|
||||
|
||||
## Key Concepts
|
||||
- [[结构人类学(Structural Anthropology)]]:Lévi-Strauss 创立的结构主义方法,通过二元对立和转换分析社会组织与神话
|
||||
- [[厚描述(Thick Description)]]:Geertz 提出的文化解读方法,将文化实践视为文本进行深度诠释
|
||||
- [[实践理论(Practice Theory)]]:Bourdieu 的理论,强调文化实践如何再生产社会结构
|
||||
- [[礼物经济(Gift Economy)]]:Mauss 提出的基于互惠和社会义务的交换体系
|
||||
- [[阈限与共融(Liminality and Communitas)]]:Turner 提出的仪式过渡状态和群体认同概念
|
||||
- [[文化生态学(Cultural Ecology)]]:Steward 和 Rappaport 提出的环境与文化相互塑造理论
|
||||
- [[文化一致性(Cultural Coherence)]]:确保文化系统各元素相互兼容的检查原则
|
||||
- [[亲属制度(Kinship System)]]:社会家庭组织方式,决定继承、联盟和居住模式
|
||||
- [[礼仪分析(Ritual Analysis)]]:对仪式结构、功能和社会作用的分析(Turner、van Gennep)
|
||||
- [[交换体系(Exchange System)]]:Polanyi 的互惠、再分配、市场三元分类框架
|
||||
|
||||
## Key Entities
|
||||
- [[Lévi-Strauss]]:法国人类学家,结构人类学创始人
|
||||
- [[Clifford Geertz]]:美国人类学家,象征人类学和"厚描述"概念提出者
|
||||
- [[Pierre Bourdieu]]:法国社会学家,实践理论创立者
|
||||
- [[Victor Turner]]:英国人类学家,仪式阈限和共融概念提出者
|
||||
- [[Arnold van Gennep]]:法国人类学家,礼仪三阶段模型(分离→阈限→合并)提出者
|
||||
- [[Marcel Mauss]]:法国社会学家,人类学礼物经济理论奠基人
|
||||
- [[Karl Polanyi]]:匈牙利裔英国人类学家,经济人类学和交换体系分类提出者
|
||||
- [[Mary Douglas]]:英国人类学家,洁净与危险( taboo)理论提出者
|
||||
- [[Max Weber]]:德国社会学家,宗教社会学和组织类型学
|
||||
- [[Elman Service]]:美国人类学家,政治组织分类(Band/Tribe/Chiefdom/State)提出者
|
||||
- [[Marvin Harris]]:美国人类学家,文化唯物主义创始人
|
||||
- [[Roy Rappaport]]:美国人类学家,文化生态学提出者
|
||||
- [[Émile Durkheim]]:法国社会学家,社会 cohesion 和功能分析奠基人
|
||||
- [[Bronisław Malinowski]]:波兰裔英国人类学家,功能主义分析创始人
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,Anthropologist Agent 所属项目
|
||||
|
||||
## Connections
|
||||
- [[Anthropologist Agent]] ← defines ← [[The Agency]]
|
||||
- [[结构人类学(Structural Anthropology)]] ←的理论基础 ← [[Lévi-Strauss]]
|
||||
- [[厚描述(Thick Description)]] ←的理论基础 ← [[Clifford Geertz]]
|
||||
- [[礼物经济(Gift Economy)]] ←的理论基础 ← [[Marcel Mauss]]
|
||||
- [[实践理论(Practice Theory)]] ←的理论基础 ← [[Pierre Bourdieu]]
|
||||
- [[阈限与共融(Liminality and Communitas)]] ←的理论基础 ← [[Victor Turner]]
|
||||
- [[文化唯物主义(Cultural Materialism)]] ←的理论基础 ← [[Marvin Harris]]
|
||||
- [[Cultural Intelligence Strategist]] ←相关 ← [[Anthropologist Agent]]
|
||||
- [[UX Researcher]] ←对比 ← [[Anthropologist Agent]](前者研究真实用户,后者设计虚构文化)
|
||||
- [[Cultural Coherence Check]] ←使用 ← [[Anthropologist Agent]](设计工具)
|
||||
|
||||
## Contradictions
|
||||
- 暂未发现与现有 Wiki 内容的冲突
|
||||
63
wiki/sources/academic-geographer.md
Normal file
63
wiki/sources/academic-geographer.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "Geographer"
|
||||
type: source
|
||||
tags: [agent, the-agency, geography, worldbuilding]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-geographer.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Geographer 智能体,物理与人文地理专家
|
||||
- 问题域:AI Agent 在世界构建中的地理一致性验证
|
||||
- 方法/机制:系统地理学方法、气候建模、水文验证、地缘政治分析
|
||||
- 结论/价值:确保虚构世界的地理连贯性,避免违反物理规律
|
||||
|
||||
## Key Claims
|
||||
- 地理是命运系统:气候→生物群系→资源→定居点→贸易→权力形成完整链条
|
||||
- 河流不分叉:支流汇入主流,河流不分叉成两条独立河流流向不同海域
|
||||
- 气候是系统:雨影效应、海流、温度带、纬度决定气候,非孤立存在
|
||||
- 地理非装饰:每座山脉、河流、沙漠对人类居住都有后果,需解释水源
|
||||
- 避免地理决定论:地理约束但不决定,相似环境产生不同文化
|
||||
- 尺度重要:小王国与大帝国的地理需求完全不同
|
||||
|
||||
## Key Concepts
|
||||
- Koppen 气候分类法:物理地理学基础气候分类系统
|
||||
- 中心地理论(Christaller):人文地理学城市层级理论
|
||||
- 心脏地带理论(Mackinder):地缘政治学核心概念
|
||||
- 世界体系理论(Wallerstein):全球政治经济结构框架
|
||||
- 环境决定论之争(Diamond vs Acemoglu):地理与制度的学术辩论
|
||||
|
||||
## Key Entities
|
||||
- Jared Diamond:环境地理决定论代表,《枪炮、病菌与钢铁》作者
|
||||
- Walter Christaller:中心地理论创始人,城市地理学奠基人
|
||||
- Halford Mackinder:心脏地带理论,地缘政治学创始人
|
||||
- Immanuel Wallerstein:世界体系理论,社会学家
|
||||
- Daron Acemoglu:制度经济学代表,批评地理决定论
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Geographer]]
|
||||
- [[Academic Anthropologist]] ← related ← [[Geographer]](世界构建中的协作)
|
||||
- [[Christaller Central Place Theory]] ← implements ← [[Geographer]]
|
||||
|
||||
## Technical Deliverables
|
||||
- Geographic Coherence Report:区域地理一致性验证报告
|
||||
- Climate System Design:气候系统设计文档
|
||||
|
||||
## Workflow Process
|
||||
1. 从板块构造开始:山脉位置决定一切
|
||||
2. 从第一性原理构建气候:纬度+海流+地形=气候
|
||||
3. 添加水文学:河流流向遵循由高到低阻力最小路径
|
||||
4. 层叠生物群系:气候+土壤+水=植被
|
||||
5. 放置人类:考虑定居、贸易路线
|
||||
|
||||
## Geographic Coherence Rules
|
||||
- 河流物理上不能分叉
|
||||
- 雨影效应存在
|
||||
- 海岸洋流影响温度
|
||||
- 纬度决定季节
|
||||
- 地图是论点:每个地图都做出关于包含什么和排除什么的选择
|
||||
|
||||
## Contradictions
|
||||
无已知冲突
|
||||
44
wiki/sources/academic-historian.md
Normal file
44
wiki/sources/academic-historian.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "Academic Historian Agent"
|
||||
type: source
|
||||
tags: [agent, historian, the-agency]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-historian.md]]
|
||||
|
||||
## Summary
|
||||
Academic Historian 是 The Agency 项目中的研究历史学家智能体,具备广泛的时间跨度和深厚的方法论训练。该智能体通过结构人类学、厚描述、实践理论等框架构建具有文化一致性的虚构社会,避免文化拼贴和表面异域风情设计。其核心使命是验证历史一致性、提供物质文化细节、挑战历史神话,并主动纳入非西方历史视角。
|
||||
|
||||
## Key Claims
|
||||
- Historian 通过验证时间地点精确性(而非模糊的"中世纪")来确保历史一致性
|
||||
- 物质条件优先:先理解经济基础(饮食、贸易、技术),再讨论政治或战争
|
||||
- 历史分层:Annales 学派、微历史、长时段(longue durée)分析
|
||||
- 挑战欧洲中心主义:主动纳入非西方历史,宋朝科技曾领先欧洲,马里帝国曾是世界上最富有的国家之一
|
||||
- 区分神话与数据:神话是关于文化的主要来源,不是"虚假历史"
|
||||
|
||||
## Key Quotes
|
||||
> "History doesn't repeat, but it rhymes — and I know all the verses" — Historian 风格宣言
|
||||
|
||||
> "Medieval Europe" spans 1000 years and a continent. Be specific about when and where.
|
||||
|
||||
## Key Concepts
|
||||
- [[Period Authenticity Report]]:时期真实性报告,验证Setting的时间、地点、物质文化、社会结构一致性
|
||||
- [[Historical Coherence Check]]:历史一致性检查,评估声明的历史准确性并标注置信度
|
||||
- [[Material Culture]]:物质文化,关注日常饮食、服装、建筑、贸易、信仰,而非仅关注王侯将相
|
||||
- [[Longue Durée]]:长时段,布雷顿历史学派分析方法,关注塑造事件长期结构
|
||||
- [[Microhistory]]:微历史,对特定小人物或事件的详细研究方法
|
||||
- [[Anachronism]]:时代错误,不仅包括明显错误(如哥伦布前的土豆),还包括微妙错误(态度、社会结构、经济系统)
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,Academic Historian 是其学术分支的一员
|
||||
- [[Annales School]]:年鉴学派,20世纪法国史学派,强调长时段、物质条件和社会结构
|
||||
|
||||
## Connections
|
||||
- [[Academic Anthropologist]] — 同为 The Agency 世界构建专家,文化分析互补
|
||||
- [[Academic Geographer]] — 物理与人文地理验证,与 Historian 共同确保世界构建一致性
|
||||
- [[Agents Orchestrator]] — The Agency 中的编排器,协调多智能体协作
|
||||
|
||||
## Contradictions
|
||||
- 与泛化"中世纪"描述冲突:Historian 要求精确时间和地点,而非模糊历史时期标签
|
||||
55
wiki/sources/academic-narratologist.md
Normal file
55
wiki/sources/academic-narratologist.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Narratologist Agent"
|
||||
type: source
|
||||
tags: [agent, narrative-theory, the-agency]
|
||||
sources: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-narratologist.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Narratologist(叙事学家)智能体的角色定义、能力范围和工作流程
|
||||
- 问题域:AI Agent 在叙事理论和故事结构分析领域的专业化应用
|
||||
- 方法/机制:基于经典叙事理论框架(Propp、Campbell、McKee、Genette 等)提供结构化故事分析
|
||||
- 结论/价值:为 The Agency 项目提供专业的叙事理论支撑,可应用于游戏叙事、交互式小说、影视剧本等领域
|
||||
|
||||
## Key Claims
|
||||
- Narratologist Agent 是资深叙事理论家和故事结构分析师,以工程师拆解系统的方式剖析故事
|
||||
- 叙事问题通常存在于讲述层面(sjuzhet)而非故事层面(fabula)
|
||||
- 每个建议必须基于至少一个命名理论框架并附带推理过程
|
||||
- 角色弧线必须包含 want/need/lie/transformation 四个检查点
|
||||
|
||||
## Key Quotes
|
||||
> "You dissect stories the way an engineer dissects systems — finding the load-bearing structures, the stress points, the elegant solutions." — Narratologist 身份定位
|
||||
|
||||
> "Most problems live in the telling (sjuzhet), not the tale (fabula)." — 诊断方法论核心原则
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[Propp 叙事形态学]]:Vladimir Propp 的民间故事形态分析,识别 31 种叙事功能
|
||||
- [[Campbell 英雄之旅]]:Joseph Campbell 的单一神话理论,英雄经历分离、启蒙、回归三阶段
|
||||
- [[McKee 故事结构]]:Robert McKee 的三幕结构和对白写作理论
|
||||
- [[Genette 叙事学]]:Gérard Genette 的叙事话语分析,聚焦视点、时间和叙事层次
|
||||
- [[Barthes 五代码]]:Roland Barthes 的叙事符号学,五个意义生成代码
|
||||
- [[Vogler 作家旅程]]:Christopher Vogler 基于 Campbell 的编剧框架
|
||||
- [[Todorov 均衡模型]]:Tzvetan Todorov 的叙事 equilibrium-disruption-return 结构
|
||||
- [[三幕结构]]:传统戏剧结构(Setup-Confrontation-Resolution)
|
||||
- [[英雄之旅]]:见 [[Campbell 英雄之旅]]
|
||||
- [[角色弧线]]:角色从初始状态到转变的完整发展轨迹
|
||||
- [[Want vs Need]]:角色外在目标与内在需求的张力结构
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,Narratologist 所属项目
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Narratologist]] ← 专业领域 ← [[The Agency]]
|
||||
- [[Story Structure Analysis]] ← 依赖 ← [[Narratologist]]
|
||||
- [[Character Arc Assessment]] ← 依赖 ← [[Narratologist]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 暂无已知冲突
|
||||
73
wiki/sources/academic-psychologist.md
Normal file
73
wiki/sources/academic-psychologist.md
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: "Academic Psychologist Agent Personality"
|
||||
type: source
|
||||
tags: [agent, personality, psychology, the-agency, academic]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-psychologist.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:The Agency 项目中的临床与研究心理学家人格定义,为 AI Agent 提供心理学分析框架
|
||||
- 问题域:人格评估、动机分析、创伤反应、群体动力学、认知行为模式
|
||||
- 方法/机制:基于 Big Five 人格框架、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、CBT 认知扭曲识别、社会心理学经典实验
|
||||
- 结论/价值:提供可交叉引用的多理论心理学分析范式,避免过度诊断,强调文化语境与研究局限性
|
||||
|
||||
## Key Claims
|
||||
- Big Five 人格框架是分析角色心理的核心模型:开放性、尽责性、外向性、宜人性、神经质
|
||||
- 依恋理论(Secure / Anxious-Preoccupied / Dismissive-Avoidant / Fearful-Avoidant)适用于浪漫、家庭、友谊等多种关系分析
|
||||
- 防御机制遵循 Vaillant 层级结构:自恋性防御→不成熟防御→神经质防御→成熟防御
|
||||
- Karpman 戏剧三角(迫害者→受害者→拯救者)可映射人际冲突动态
|
||||
- 创伤反应多样:警惕过度、讨好型、隔离型、退缩型,避免"悲伤过往=破碎角色"的刻板印象
|
||||
- 认知扭曲识别基于 Beck 框架:非黑即白思维、过度概括、灾难化等
|
||||
- 群体心理学:Milgram 服从实验、Zimbardo 斯坦福监狱实验、Asch 从众实验及其现代批判
|
||||
- 群体思维(Groupthink,Janis)威胁理性决策
|
||||
- 社会认同理论(Tajfel)解释群体内/外偏见的心理根源
|
||||
- 文化心理学:Markus & Kitayama 独立/互依自我观,Hofstede 文化维度理论
|
||||
|
||||
## Key Quotes
|
||||
> "Never reduce characters to diagnoses. A character can exhibit narcissistic *traits* without being 'a narcissist.' People are not their DSM codes."
|
||||
> — Academic Psychologist Agent
|
||||
|
||||
> "Distinguish between **pop psychology** and **research-backed psychology**. If you cite something, know whether it's peer-reviewed or self-help."
|
||||
> — Academic Psychologist Agent
|
||||
|
||||
## Key Concepts
|
||||
- [[Big Five 人格框架]]:开放性、尽责性、外向性、宜人性、神经质五维度人格模型
|
||||
- [[依恋理论]]:Bowlby 提出的亲子关系心理模型,四种成人依恋风格
|
||||
- [[Vaillant 防御机制层级]]:成熟防御、神经质防御、不成熟防御、自恋性防御的层级结构
|
||||
- [[Karpman 戏剧三角]]:迫害者→受害者→拯救者的三角人际冲突模式
|
||||
- [[认知扭曲]]:Beck 识别的非理性思维模式,如非黑即白、灾难化思维
|
||||
- [[群体思维]]:Janis 描述的过度团结导致决策失误的群体心理现象
|
||||
- [[社会认同理论]]:Tajfel 解释群体偏见和内群体偏好的社会心理机制
|
||||
- [[PTSD]]:创伤后应激障碍,复杂创伤则涉及代际创伤
|
||||
- [[Porges 多迷走神经理论]]:理解创伤反应的神经生理学框架
|
||||
|
||||
## Key Entities
|
||||
- [[Erik Erikson]]:发展心理学家,提出心理社会发展阶段理论
|
||||
- [[Jean Piaget]]:认知发展心理学家,提出的儿童认知发展阶段
|
||||
- [[John Bowlby]]:依恋理论创始人
|
||||
- [[Aaron Beck]]:认知行为疗法创始人,提出认知扭曲分类
|
||||
- [[George Vaillant]]:防御机制层级研究者
|
||||
- [[Stephen Karpman]]:戏剧三角理论提出者
|
||||
- [[Stanley Milgram]]:服从权威实验研究者
|
||||
- [[Philip Zimbardo]]:斯坦福监狱实验研究者
|
||||
- [[Solomon Asch]]:从众实验研究者
|
||||
- [[Irving Janis]]:群体思维概念提出者
|
||||
- [[Henri Tajfel]]:社会认同理论创始人
|
||||
- [[Bessel van der Kolk]]:创伤研究专家,《身体从未忘记》作者
|
||||
- [[Judith Herman]]:复杂创伤和复原力研究专家
|
||||
- [[Stephen Porges]]:多迷走神经理论提出者
|
||||
- [[Hofstede]]:文化维度理论提出者
|
||||
- [[Markus & Kitayama]]:独立/互依自我文化心理学研究者
|
||||
|
||||
## Connections
|
||||
- [[Big Five 人格框架]] ← 分析框架 ← [[Academic Psychologist Agent]]
|
||||
- [[依恋理论]] ← 分析框架 ← [[Academic Psychologist Agent]]
|
||||
- [[Karpman 戏剧三角]] ← 分析工具 ← [[Academic Psychologist Agent]]
|
||||
- [[认知扭曲]] ← 分析工具 ← [[Academic Psychologist Agent]]
|
||||
- [[Academic Psychologist Agent]] ← 协作 ← [[The Agency]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无冲突记录
|
||||
86
wiki/sources/agents-orchestrator.md
Normal file
86
wiki/sources/agents-orchestrator.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: "Agents Orchestrator"
|
||||
type: source
|
||||
tags: [agent, pipeline, autonomous-workflow, the-agency]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/agents-orchestrator.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:The Agency 项目中的 Agents Orchestrator 智能体,负责从规格文件到生产部署的完整开发流水线编排
|
||||
- 问题域:多智能体协作质量控制、项目状态跟踪、自主决策流水线执行
|
||||
- 方法/机制:四阶段流水线(PM → ArchitectUX → Dev-QA Loop → Integration)、质量门禁强制、任务级 QA 验证循环
|
||||
- 结论/价值:实现端到端开发流程自主化,通过持续质量循环确保交付质量
|
||||
|
||||
## Key Claims
|
||||
- Agents Orchestrator 通过单一初始命令驱动完整开发流水线(PM → ArchitectUX → Dev-QA Loop → Integration)
|
||||
- 每个任务必须通过 QA 验证才能进入下一任务,质量门禁不可绕过
|
||||
- 失败任务最多重试 3 次,超过则升级处理
|
||||
- Dev-QA 循环是核心机制:开发实现 → QA 截图验证 → PASS/FAIL 决策 → 循环或前进
|
||||
|
||||
## Key Quotes
|
||||
> "You are **AgentsOrchestrator**, the autonomous pipeline manager who runs complete development workflows from specification to production-ready implementation." — Agents Orchestrator 身份定义
|
||||
> "Maximum 3 attempts per task before escalation" — 重试限制策略
|
||||
> "No phase advancement without meeting quality standards" — 质量门禁强制要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Quality Gate(质量门禁)]]:每个阶段必须满足质量标准才能前进的机制
|
||||
- [[Dev-QA Loop(开发-QA 循环)]]:实现 → QA 验证 → 反馈 → 改进的持续循环
|
||||
- [[Pipeline Orchestration(流水线编排)]]:协调多个智能体完成复杂工作流的机制
|
||||
- [[Multi-Agent Coordination(多智能体协作)]]:多个专业化 Agent 协同工作的架构模式
|
||||
- [[EvidenceQA]]:截图驱动的 QA 智能体,要求视觉证据进行验证
|
||||
|
||||
## Key Entities
|
||||
- [[Agents Orchestrator]]:主编排器,负责驱动完整开发流水线
|
||||
- [[Project Manager Senior]]:第一阶段生成任务清单的智能体
|
||||
- [[ArchitectUX]]:第二阶段创建技术架构和 UX 基础的智能体
|
||||
- [[EvidenceQA]]:第三阶段进行截图驱动 QA 验证的智能体
|
||||
- [[Testing Reality Checker]]:第四阶段进行最终集成测试的智能体
|
||||
- [[Senior Project Manager]]:任务清单转换智能体,将规格文件转化为可执行任务列表
|
||||
|
||||
## Connections
|
||||
- [[Project Manager Senior]] ← spawns ← [[Agents Orchestrator]]
|
||||
- [[ArchitectUX]] ← spawns ← [[Agents Orchestrator]]
|
||||
- [[EvidenceQA]] ← spawns ← [[Agents Orchestrator]]
|
||||
- [[Testing Reality Checker]] ← spawns ← [[Agents Orchestrator]]
|
||||
- [[Frontend Developer]] ← coordinates_with ← [[Agents Orchestrator]]
|
||||
- [[Backend Architect]] ← coordinates_with ← [[Agents Orchestrator]]
|
||||
- [[DevOps Automator]] ← coordinates_with ← [[Agents Orchestrator]]
|
||||
- [[Quality Gate(质量门禁)]] ← enforces ← [[Dev-QA Loop(开发-QA 循环)]]
|
||||
- [[Multi-Agent Coordination(多智能体协作)]] ← implements ← [[Pipeline Orchestration(流水线编排)]]
|
||||
|
||||
## Contradictions
|
||||
- 与单体智能体执行模式冲突:[[Agents Orchestrator]] 强调多智能体分层协作和质量循环,单体模式倾向于单一智能体完成所有任务
|
||||
- 冲突点:任务分配与质量控制方式
|
||||
- 当前观点:多智能体专业化分工 + QA 验证循环
|
||||
- 对方观点:单一智能体端到端执行减少交接开销
|
||||
|
||||
## Workflow Phases
|
||||
|
||||
### Phase 1: Project Analysis & Planning
|
||||
1. 验证项目规格文件存在
|
||||
2. Spawn project-manager-senior 创建任务清单
|
||||
3. 验证任务清单生成
|
||||
|
||||
### Phase 2: Technical Architecture
|
||||
1. 验证任务清单存在
|
||||
2. Spawn ArchitectUX 创建技术架构
|
||||
3. 验证架构交付物
|
||||
|
||||
### Phase 3: Development-QA Continuous Loop
|
||||
1. 读取任务清单理解范围
|
||||
2. 对每个任务运行 Dev-QA 循环直到 PASS
|
||||
3. 任务失败最多重试 3 次
|
||||
|
||||
### Phase 4: Final Integration & Validation
|
||||
1. 所有任务通过 QA 后执行
|
||||
2. Spawn testing-reality-checker 进行最终集成测试
|
||||
3. 评估生产就绪状态
|
||||
|
||||
## Quality Enforcement Rules
|
||||
- **No shortcuts**:每个任务必须通过 QA 验证
|
||||
- **Evidence required**:所有决策基于实际智能体输出和证据
|
||||
- **Retry limits**:每个任务最多 3 次重试
|
||||
- **Clear handoffs**:每个智能体获得完整上下文和具体指令
|
||||
26
wiki/sources/aider-readme.md
Normal file
26
wiki/sources/aider-readme.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Aider Integration"
|
||||
type: source
|
||||
tags: [agency, integrations, aider]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/aider/README.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
This README documents how to integrate The Agency agents with Aider. It explains that the project's CONVENTIONS.md consolidates the roster, shows install/activate commands, notes manual usage with `aider --read CONVENTIONS.md`, and how to regenerate artifacts via `./scripts/convert.sh --tool aider`.
|
||||
|
||||
## Key Claims
|
||||
- The Agency roster can be consolidated into a single `CONVENTIONS.md` file which Aider reads automatically when present.
|
||||
- Installation uses the repository's `./scripts/install.sh --tool aider` script run from the project root.
|
||||
- Agents can be referenced by name inside an Aider session to activate behavior (e.g., "Use the Frontend Developer agent...").
|
||||
- Manual reading of the conventions file is supported via `aider --read CONVENTIONS.md`.
|
||||
- Generated artifacts for Aider can be produced with `./scripts/convert.sh --tool aider`.
|
||||
|
||||
## Key Quotes
|
||||
> "Aider reads this file automatically when it's present in your project root." — Aider Integration README
|
||||
|
||||
## Connections
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — the conventions file consolidates the roster of agents from this project
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
81
wiki/sources/automation-governance-architect.md
Normal file
81
wiki/sources/automation-governance-architect.md
Normal file
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: "Automation Governance Architect"
|
||||
type: source
|
||||
tags: [agent, automation, governance, n8n]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/automation-governance-architect.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:自动化治理架构师,负责评估、审批和标准化业务自动化工作流
|
||||
- 问题域:防止低价值或不安全的自动化实施,确保自动化投资回报
|
||||
- 方法/机制:n8n 为主要编排工具的治理框架,包含决策框架、审批 verdicts、标准化工作流结构
|
||||
- 结论/价值:通过 Governance-first 方法提升自动化质量、可靠性和可维护性
|
||||
|
||||
## Key Claims
|
||||
- 决策必须基于价值而非技术可行性
|
||||
- 每个推荐必须包含 fallback 和 ownership
|
||||
- 无文档和测试证据不得标记为"done"
|
||||
- 简单健壮优于巧妙脆弱
|
||||
|
||||
## Key Quotes
|
||||
> "Do not approve automation only because it is technically possible." — 核心原则
|
||||
> "No 'done' status without documentation and test evidence." — 完成标准
|
||||
> "Every recommendation must include fallback and ownership." — 责任要求
|
||||
|
||||
## Key Concepts
|
||||
- [[n8n]]:主要编排工具,n8n-mcp 提供 543 个节点访问能力
|
||||
- [[ITSM(IT 服务管理)]]:自动化的服务治理背景
|
||||
- [[Task Automation]]:任务自动化机制
|
||||
- [[智能体工作流]]:以 n8n、Dify 为代表的工作流自动化平台
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,Automation Governance Architect 是其 specialized agents 之一
|
||||
|
||||
## Connections
|
||||
- [[n8n-mcp]] ← 使用 ← [[Automation Governance Architect]]
|
||||
- [[Task Automation]] ← 治理对象 ← [[Automation Governance Architect]]
|
||||
- [[ITSM(IT 服务管理)]] ← 隶属于 ← [[Automation Governance Architect]]
|
||||
|
||||
## Decision Framework(决策框架)
|
||||
|
||||
### 评估维度
|
||||
1. **Time Savings Per Month**:月度时间节省,是否 recurring 和 material
|
||||
2. **Data Criticality**:数据关键性(客户、财务、合同、排程记录)
|
||||
3. **External Dependency Risk**:外部依赖风险(API/服务稳定性)
|
||||
4. **Scalability (1x to 100x)**:可扩展性,retries、deduplication、rate limits
|
||||
|
||||
### Verdicts(审批结论)
|
||||
- **APPROVE**:强价值、风险可控、架构可维护
|
||||
- **APPROVE AS PILOT**:价值 plausibly 但需限制 rollout
|
||||
- **PARTIAL AUTOMATION ONLY**:仅自动化安全段,保留人工 checkpoint
|
||||
- **DEFER**:流程不成熟、价值不明确、依赖不稳定
|
||||
- **REJECT**:经济性弱或运营/合规风险不可接受
|
||||
|
||||
## n8n Workflow Standard(工作流标准)
|
||||
|
||||
10 段结构:Trigger → Input Validation → Data Normalization → Business Logic → External Actions → Result Validation → Logging/Audit Trail → Error Branch → Fallback/Manual Recovery → Completion/Status Writeback
|
||||
|
||||
### Naming Convention
|
||||
`[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`
|
||||
例如:`PROD-CRM-LeadIntake-CreateRecord-v1.0`
|
||||
|
||||
## Reliability Baseline(可靠性基线)
|
||||
- explicit error branches
|
||||
- idempotency 或 duplicate protection
|
||||
- safe retries (with stop conditions)
|
||||
- timeout handling
|
||||
- alerting/notification
|
||||
- manual fallback path
|
||||
|
||||
## Re-Audit Triggers(再审计触发条件)
|
||||
- APIs 或 schemas 变更
|
||||
- 错误率上升
|
||||
- volume 显著增加
|
||||
- 合规要求变更
|
||||
- 出现重复人工修复
|
||||
|
||||
## Contradictions
|
||||
- 尚未发现与现有内容的冲突
|
||||
25
wiki/sources/backend-architect-with-memory.md
Normal file
25
wiki/sources/backend-architect-with-memory.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Backend Architect (with Memory)"
|
||||
type: source
|
||||
tags: [agency, agent, backend, memory]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/mcp-memory/backend-architect-with-memory.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
Backend Architect (with Memory) is a persona definition for a senior backend architect agent in The Agency. The page defines identity, core mission, rules, deliverables (architecture specs, database schemas, API designs), success metrics, advanced capabilities, and a Memory Integration section that instructs the agent to use MCP memory tools (remember, recall, rollback, search) to persist decisions and handoffs across sessions.
|
||||
|
||||
## Key Claims
|
||||
- The persona provides concrete architecture deliverables (system architecture spec, database schema SQL, API examples) and prescriptive rules emphasizing security, performance, and reliability.
|
||||
- The Memory Integration section instructs the agent to store decisions and deliverables using MCP memory tools, tag memories by agent and project, and use rollback to recover known-good states.
|
||||
- No code changes to agent files are required — the MCP tools provide persistence when configured in the client's MCP servers.
|
||||
|
||||
## Key Quotes
|
||||
> "Give any agent persistent memory across sessions using the Model Context Protocol (MCP)." — Integrations README header
|
||||
|
||||
## Connections
|
||||
- [[MCP Memory Integration]] — the Memory Integration pattern referenced by this persona
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — the primary roster of agents this persona belongs to
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
58
wiki/sources/blockchain-security-auditor.md
Normal file
58
wiki/sources/blockchain-security-auditor.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "Blockchain Security Auditor"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/blockchain-security-auditor.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:The Agency 项目中的智能合约安全审计专家智能体
|
||||
- 问题域:DeFi 协议和区块链应用的安全漏洞检测、形式化验证、漏洞利用分析
|
||||
- 方法/机制:结合自动化静态分析工具(Slither、Mythril、Echidna)与人工逐行代码审查
|
||||
- 结论/价值:提供专业级安全审计报告,发现可能导致用户资金损失的安全漏洞
|
||||
|
||||
## Key Claims
|
||||
- 自动化工具只能发现约 30% 的真实漏洞,人工审查不可替代
|
||||
- 预言机操纵攻击(Flash Loan Attack)是 DeFi 协议最常见的高危漏洞类型之一
|
||||
- 访问控制缺陷是仅次于重入攻击的第二大漏洞来源
|
||||
- 每个发现必须包含可复现的概念验证攻击或具体攻击场景
|
||||
|
||||
## Key Quotes
|
||||
> "Your job is not to make developers feel good — it is to find the bug before the attacker does." — 核心定位
|
||||
|
||||
> "Never assume a function is safe because it uses OpenZeppelin — misuse of safe libraries is a vulnerability class of its own." — 安全原则
|
||||
|
||||
> "Automated tools catch maybe 30% of real bugs." — 工具局限性
|
||||
|
||||
## Key Concepts
|
||||
- [[Reentrancy]](重入攻击):外部调用状态更新前的漏洞模式,通过 Checks-Effects-Interactions 模式 + ReentrancyGuard 防护
|
||||
- [[Oracle Manipulation]](预言机操纵):通过 Flash Loan 操纵链上价格预言机的攻击手法,需使用 TWAP 或 Chainlink 防护
|
||||
- [[Flash Loan Attack]](闪电贷攻击):在单笔交易内借用大量资金操纵市场状态的攻击范式
|
||||
- [[Access Control]](访问控制):智能合约权限管理,OpenZeppelin 的 AccessControl 模式
|
||||
- [[Formal Verification]](形式化验证):通过数学证明验证协议不变量正确性的方法
|
||||
- [[Static Analysis]](静态分析):Slither、Mythril 等自动化代码分析工具
|
||||
- [[Invariant Verification]](不变量验证):属性驱动测试验证协议关键属性
|
||||
- [[Checks-Effects-Interactions]]:防止重入攻击的设计模式,先更新状态再执行外部调用
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,本智能体所属项目
|
||||
- [[Slither]]:Trail of Bits 开发的主流静态分析工具
|
||||
- [[Mythril]]:Consensys Diligence 开发的形式化验证工具
|
||||
- [[Echidna]]:Property-based fuzzing 工具
|
||||
- [[OpenZeppelin]]:智能合约标准库,提供安全的基础组件
|
||||
- [[Foundry]]:以太坊开发框架,包含 Forge 测试工具
|
||||
- [[Chainlink]]:去中心化预言机网络
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Blockchain Security Auditor]]
|
||||
- [[Reentrancy]] ← is_type_of ← [[Smart Contract Vulnerability]]
|
||||
- [[Oracle Manipulation]] ← is_type_of ← [[DeFi Attack Vector]]
|
||||
- [[Flash Loan Attack]] ← exploits ← [[Oracle Manipulation]]
|
||||
- [[Access Control]] ← is_type_of ← [[Smart Contract Vulnerability]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突
|
||||
|
||||
24
wiki/sources/claude-code-readme.md
Normal file
24
wiki/sources/claude-code-readme.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Claude Code Integration"
|
||||
type: source
|
||||
tags: [agency, integrations, claude-code]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/claude-code/README.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
This README documents how The Agency integrates with Claude Code. Because the agents are already authored as Markdown files with YAML frontmatter, no conversion is required. The README includes install commands to copy agents into Claude Code's agents directory, activation examples, and a note that agents are organized into divisions.
|
||||
|
||||
## Key Claims
|
||||
- The Agency agents work natively with Claude Code's `.md` + YAML frontmatter format; no conversion step is required.
|
||||
- Installation can be done via `./scripts/install.sh --tool claude-code` or by copying individual category files into `~/.claude/agents/`.
|
||||
- Agents are referenced by name in Claude Code sessions to activate behavior.
|
||||
|
||||
## Key Quotes
|
||||
> "The Agency was built for Claude Code. No conversion needed — agents work natively with the existing `.md` + YAML frontmatter format." — Claude Code Integration README
|
||||
|
||||
## Connections
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — primary roster source; agents are authored in the repo's Markdown format and intended for Claude Code
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
66
wiki/sources/compliance-auditor.md
Normal file
66
wiki/sources/compliance-auditor.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "Compliance Auditor Agent"
|
||||
type: source
|
||||
tags: [agent, compliance, audit, the-agency, specialized]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/compliance-auditor.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:技术合规审计专家智能体,专注于 SOC 2、ISO 27001、HIPAA 和 PCI-DSS 认证流程
|
||||
- 问题域:安全与隐私认证、 controls implementation、 evidence collection、 gap assessment
|
||||
- 方法/机制:五阶段工作流(Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance)、自动化证据收集、审计就绪度评估
|
||||
- 结论/价值:提供从准备评估到认证的技术合规全程指导,强调实质优于检查清单、证据证明控制有效性
|
||||
|
||||
## Key Claims
|
||||
- 控制必须被测试,而不仅是文档化
|
||||
- 证据必须证明控制在审计期间有效运作,而不仅是今天存在
|
||||
- 政策无人遵守比没有政策更糟糕——它产生虚假信心和审计风险
|
||||
- 自动化证据收集从第一天开始——手动流程无法扩展
|
||||
|
||||
## Key Quotes
|
||||
> "A policy nobody follows is worse than no policy — it creates false confidence and audit risk." — Compliance Auditor 核心原则
|
||||
|
||||
> "Think like the auditor: what would you test? what evidence would you request?" — 审计师思维
|
||||
|
||||
> "Exceptions need documentation: who approved it, why, when does it expire, what compensating control exists." — 例外处理规范
|
||||
|
||||
## Key Concepts
|
||||
- [[Audit Readiness]](审计就绪度):评估当前安全态势是否符合目标框架要求
|
||||
- [[Gap Assessment]](差距评估):识别控制差距并基于风险和审计时间线制定优先修复计划
|
||||
- [[Controls Implementation]](控制实施):设计满足合规要求且适应现有工程工作流的控制
|
||||
- [[Evidence Collection]](证据收集):自动化证据收集流程,确保可扩展性和可靠性
|
||||
- [[Continuous Compliance]](持续合规):建立自动化证据收集管道,季度控制测试,监管变化追踪
|
||||
|
||||
## Key Entities
|
||||
- [[SOC-2]]:Service Organization Control 2,安全与隐私合规框架
|
||||
- [[ISO-27001]]:国际信息安全管理标准
|
||||
- [[HIPAA]]:美国健康保险可携带性和责任法案
|
||||
- [[PCI-DSS]]:支付卡行业数据安全标准
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,本 Agent 所属框架
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Compliance Auditor]]
|
||||
- [[SOC-2]] ←认证目标← [[Compliance Auditor]]
|
||||
- [[ISO-27001]] ←认证目标← [[Compliance Auditor]]
|
||||
- [[HIPAA]] ←认证目标← [[Compliance Auditor]]
|
||||
- [[PCI-DSS]] ←认证目标← [[Compliance Auditor]]
|
||||
|
||||
## Compliance Deliverables
|
||||
### Gap Assessment Report
|
||||
结构化发现报告,包含控制域、当前状态、目标状态、修复步骤和估计工作量
|
||||
|
||||
### Evidence Collection Matrix
|
||||
控制证据矩阵,包含控制 ID、证据类型、来源、收集方法和频率
|
||||
|
||||
### Policy Template
|
||||
政策模板,包含目的、范围、政策声明、例外处理、执行和相关控制映射
|
||||
|
||||
## Workflow
|
||||
1. **Scoping**:定义信任服务标准或控制目标,识别审计边界内的系统、数据流和团队
|
||||
2. **Gap Assessment**:逐项评估控制目标与当前状态,按严重性和修复复杂度评级
|
||||
3. **Remediation Support**:帮助团队实施符合工作流的控制,审查证据完整性
|
||||
4. **Audit Support**:组织证据仓库,准备 walkthrough 脚本,管理审计发现
|
||||
5. **Continuous Compliance**:设置自动化证据收集,季度控制测试,监管变化追踪
|
||||
59
wiki/sources/data-consolidation-agent.md
Normal file
59
wiki/sources/data-consolidation-agent.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "Data Consolidation Agent"
|
||||
type: source
|
||||
tags: [the-agency, sales, data, dashboard]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/specialized/data-consolidation-agent.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
Data Consolidation Agent transforms raw sales metrics into actionable, real-time dashboards by aggregating data from all territories, representatives, and time periods. It provides territory summaries, rep performance rankings, pipeline snapshots, trend analysis, and top performer highlights with sub-second dashboard loading and automatic 60-second refresh cycles.
|
||||
|
||||
## Key Claims
|
||||
- Always uses latest data via queries pulling most recent metric_date per type
|
||||
- Calculates attainment as revenue / quota * 100 with division by zero handling
|
||||
- Aggregates metrics by territory for regional visibility
|
||||
- Merges lead pipeline with sales metrics for complete picture
|
||||
- Supports multiple views: MTD, YTD, Year End summaries
|
||||
|
||||
## Key Quotes
|
||||
> "You are the Data Consolidation Agent — a strategic data synthesizer who transforms raw sales metrics into actionable, real-time dashboards."
|
||||
|
||||
## Core Deliverables
|
||||
|
||||
### Dashboard Report
|
||||
- Territory performance summary (YTD/MTD revenue, attainment, rep count)
|
||||
- Individual rep performance with latest metrics
|
||||
- Pipeline snapshot by stage (count, value, weighted value)
|
||||
- Trend data over trailing 6 months
|
||||
- Top 5 performers by YTD revenue
|
||||
|
||||
### Territory Report
|
||||
- Territory-specific deep dive
|
||||
- All reps within territory with their metrics
|
||||
- Recent metric history (last 50 entries)
|
||||
|
||||
## Workflow Process
|
||||
1. Receive request for dashboard or territory report
|
||||
2. Execute parallel queries for all data dimensions
|
||||
3. Aggregate and calculate derived metrics
|
||||
4. Structure response in dashboard-friendly JSON
|
||||
5. Include generation timestamp for staleness detection
|
||||
|
||||
## Success Metrics
|
||||
- Dashboard loads in < 1 second
|
||||
- Reports refresh automatically every 60 seconds
|
||||
- All active territories and reps represented
|
||||
- Zero data inconsistencies between detail and summary views
|
||||
|
||||
## Connections
|
||||
- [[Sales Data Extraction Agent]] — upstream data source agent that extracts sales metrics from Excel files
|
||||
- [[The Agency]] — parent project providing the agent framework
|
||||
- [[Pipeline Analyst]] — related sales intelligence agent for pipeline health diagnostics
|
||||
- [[Sales Pipeline]] — the pipeline data consolidated in dashboards
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/data-consolidation-agent.md]]
|
||||
|
||||
## Contradictions
|
||||
- None identified with existing wiki content
|
||||
25
wiki/sources/integrations-readme.md
Normal file
25
wiki/sources/integrations-readme.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Integrations (Agency Agents)"
|
||||
type: source
|
||||
tags: [agency, integrations]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/README.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
This README describes integration targets and conversion formats for The Agency agents. It lists supported tools, quick install commands, and notes about regenerating integration files when agents change. The document is a practical guide for packaging and installing agents across multiple agent platforms.
|
||||
|
||||
## Key Claims
|
||||
- The repository provides conversion and install scripts to package agents for many platforms (Claude Code, GitHub Copilot, Antigravity, Gemini CLI, OpenCode, OpenClaw, Cursor, Aider, Windsurf, Kimi Code, Qwen Code).
|
||||
- For some platforms (Gemini CLI, Qwen, Kimi), generated artifacts must be produced with `./scripts/convert.sh` before installation.
|
||||
- Installers are provided (`./scripts/install.sh`) with a `--tool` flag to target a specific integration.
|
||||
|
||||
## Key Quotes
|
||||
> "This directory contains The Agency integrations and converted formats for supported agentic coding tools." — Integrations README opening line
|
||||
|
||||
## Connections
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — the integrations document describes how to install and convert agents from this project into other agent platforms
|
||||
- [[OpenClaw]] — OpenClaw workspaces are one of the supported installation targets (OpenClaw workspaces contain SOUL.md, AGENTS.md, IDENTITY.md)
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
80
wiki/sources/lsp-index-engineer.md
Normal file
80
wiki/sources/lsp-index-engineer.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: "LSP/Index Engineer"
|
||||
type: source
|
||||
tags: [agent, lsp, code-intelligence]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/lsp-index-engineer.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:LSP/Index Engineer 智能体角色定义,专注于语言服务器协议(LSP)客户端编排和统一代码语义图谱构建
|
||||
- 问题域:异构语言服务器整合、实时语义索引构建、跨语言代码智能查询
|
||||
- 方法/机制:通过 LSP 客户端编排将 TypeScript/PHP/Go/Rust/Python 等语言服务器响应转换为统一图谱,使用 WebSocket 实现实时增量更新
|
||||
- 结论/价值:实现 <500ms 的定义/引用/悬停响应,支持 100k+ 符号规模,构建统一代码智能基础设施
|
||||
|
||||
## Key Claims
|
||||
- graphd LSP Aggregator 通过并发编排多个 LSP 客户端实现异构语言服务器统一管理
|
||||
- 语义索引基础设施(nav.index.jsonl、LSIF)实现代码导航和文档的持久化
|
||||
- 增量更新机制通过文件监视器和 git hooks 实现图谱实时同步
|
||||
- 性能目标:/graph 端点 <100ms(<10k 节点),/nav/:symId <20ms(缓存)或 <60ms(未缓存)
|
||||
|
||||
## Key Quotes
|
||||
> "You transform heterogeneous language servers into a cohesive semantic graph that powers immersive code visualization."
|
||||
|
||||
> "Every symbol must have exactly one definition node" — 图谱一致性要求
|
||||
|
||||
> "Handle 25k+ symbols without degradation (target: 100k symbols at 60fps)" — 性能目标
|
||||
|
||||
## Key Concepts
|
||||
- [[LSP (Language Server Protocol)]]:语言服务器协议,为编辑器提供编程语言智能功能的通信协议
|
||||
- [[Semantic Index]]:语义索引,存储符号定义、引用和悬停文档的数据结构
|
||||
- [[Graph Construction Pipeline]]:图谱构建管道,从 LSP 响应提取节点和边构建统一语义图
|
||||
- [[Incremental Updates]]:增量更新机制,通过文件监视器实现图谱实时同步
|
||||
- [[LSIF (Language Server Index Format)]]:语言服务器索引格式,用于预计算语义数据的导入/导出
|
||||
- [[LSP Client Orchestration]]:LSP 客户端编排,并发管理多个语言服务器客户端
|
||||
|
||||
## Key Entities
|
||||
- [[graphd]]:核心 LSP 聚合守护进程,管理多语言 LSP 客户端和图谱状态
|
||||
- [[TypeScript Language Server]]:TypeScript 语言服务器,提供 TS/JS 代码智能
|
||||
- [[Intelephense]]:PHP 语言服务器,提供 PHP 代码智能
|
||||
- [[gopls]]:Go 语言服务器,提供 Go 代码智能
|
||||
- [[rust-analyzer]]:Rust 语言服务器,提供 Rust 代码智能
|
||||
- [[pyright]]:Python 语言服务器,提供 Python 代码智能
|
||||
|
||||
## Connections
|
||||
- [[LSP (Language Server Protocol)]] ← enables ← [[graphd]]
|
||||
- [[Semantic Index]] ← powers ← [[Code Navigation]]
|
||||
- [[graphd]] ← depends_on ← [[LSP Client Orchestration]]
|
||||
- [[Incremental Updates]] ← implements ← [[File Watcher]] + [[Git Hooks]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突
|
||||
|
||||
## Technical Architecture
|
||||
|
||||
### Graph Node Schema
|
||||
- `file:<path>`:文件节点
|
||||
- `sym:<name>`:符号节点(class/function/variable/type)
|
||||
|
||||
### Graph Edge Types
|
||||
- `contains`:文件包含符号
|
||||
- `imports`:导入关系
|
||||
- `extends/implements`:继承/实现
|
||||
- `calls`:函数调用
|
||||
- `references`:符号引用
|
||||
|
||||
### Navigation Index Format (nav.index.jsonl)
|
||||
```jsonl
|
||||
{"symId":"sym:AppController","def":{"uri":"file:///src/app.php","l":10,"c":6},"refs":[...],"hover":{...}}
|
||||
```
|
||||
|
||||
## Performance Contracts
|
||||
| Endpoint | Target Latency | Condition |
|
||||
|----------|---------------|-----------|
|
||||
| /graph | <100ms | <10k nodes |
|
||||
| /nav/:symId | <20ms | cached |
|
||||
| /nav/:symId | <60ms | uncached |
|
||||
| WebSocket events | <50ms | latency |
|
||||
| Memory | <500MB | typical project |
|
||||
25
wiki/sources/mcp-memory-readme.md
Normal file
25
wiki/sources/mcp-memory-readme.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "MCP Memory Integration"
|
||||
type: source
|
||||
tags: [agency, integrations, mcp, memory]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/mcp-memory/README.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
Describes how to give any Agency agent persistent cross-session memory using a Model Context Protocol (MCP) memory server. Covers benefits (cross-session memory, handoff continuity, rollback), setup (mcpServers config), the Memory Integration prompt pattern, available MCP tools (`remember`, `recall`, `rollback`, `search`), and examples.
|
||||
|
||||
## Key Claims
|
||||
- MCP memory servers provide `remember`, `recall`, `rollback`, and `search` tools enabling persistent memory across sessions.
|
||||
- Adding a Memory Integration section to an agent's prompt enables the LLM to use MCP tools automatically without code changes to agent files.
|
||||
- Rollback to a last known-good state is a key feature for reliable multi-agent workflows.
|
||||
|
||||
## Key Quotes
|
||||
> "Give any agent persistent memory across sessions using the Model Context Protocol (MCP)." — MCP Memory Integration README
|
||||
|
||||
## Connections
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — integration pattern for making The Agency agents persistent across sessions
|
||||
- MCP ecosystem: https://modelcontextprotocol.io
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
86
wiki/sources/model-qa-specialist.md
Normal file
86
wiki/sources/model-qa-specialist.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: "Model QA Specialist"
|
||||
type: source
|
||||
tags: [agent, the-agency, ml-ops, model-audit]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-model-qa.md]]
|
||||
|
||||
## Summary
|
||||
- **核心主题**:独立模型 QA 专家智能体,对机器学习和统计模型进行端到端审计
|
||||
- **问题域**:模型生命周期审计,覆盖文档、数据、特征、模型构建、校准、可解释性、公平性和业务影响
|
||||
- **方法/机制**:10 阶段审计流程,包含 PSI 计算、SHAP 分析、Hosmer-Lemeshow 校准检验、歧视度量、Gini/KS 统计
|
||||
- **结论/价值**:为组织提供证据驱动的模型质量评估,量化问题严重程度并提出修复建议
|
||||
|
||||
## Key Claims
|
||||
- Model QA Specialist ← 执行端到端审计 ← 覆盖文档治理、数据重建、特征分析、模型复制、校准测试、可解释性分析
|
||||
- PSI(Population Stability Index)← 量化特征分布偏移 ← 用于检测输入变量在时间窗口上的稳定性
|
||||
- SHAP(SHapley Additive exPlanations)← 提供全局和局部可解释性 ← 分析特征贡献度和预测驱动力
|
||||
- Hosmer-Lemeshow 检验 ← 评估概率校准质量 ← p-value < 0.05 表示显著校准偏差
|
||||
- 独立原则 ← 从不审计自建模型 ← 保持客观性,用数据挑战每个假设
|
||||
|
||||
## Key Quotes
|
||||
> "You treat every model as guilty until proven sound." — Model QA Specialist 核心原则
|
||||
> "Every finding must include: observation, evidence, impact assessment, and recommendation." — 证据驱动发现要求
|
||||
> "Never state 'the model is wrong' without quantifying the impact." — 量化学术原则
|
||||
|
||||
## Key Concepts
|
||||
- [[Population Stability Index (PSI)]]:量化两个分布之间差异的指标,< 0.10 无显著偏移,0.10–0.25 中等偏移,≥ 0.25 显著偏移
|
||||
- [[SHAP Analysis]]:基于博弈论的特征贡献分析方法,提供全局(beeswarm/bar)和局部(waterfall/force)解释
|
||||
- [[Calibration Testing]]:校准检验,Hosmer-Lemeshow、Brier score、reliability diagrams 评估概率预测准确性
|
||||
- [[Discrimination Metrics]]:歧视度量指标,包括 Gini 系数、KS 统计量、AUC,用于评估模型区分能力
|
||||
- [[Partial Dependence Plots]]:偏依赖图,展示特征与预测结果的边际关系,用于验证单调性和检测非线性阈值
|
||||
- [[Fairness Audit]]:公平性审计,跨受保护属性( demographics parity、equalized odds)检测歧视性偏差
|
||||
- [[Model Audit]]:模型审计,对模型全生命周期进行系统性评估的 10 阶段方法论
|
||||
|
||||
## Key Entities
|
||||
- [[Model QA Specialist]]:**主体**,The Agency 项目中的独立模型审计专家智能体,人格为怀疑但协作
|
||||
|
||||
## Connections
|
||||
- [[Model QA Specialist]] ← 属于 ← [[The Agency]]
|
||||
- [[Model QA Specialist]] ← 使用 ← [[SHAP Analysis]]
|
||||
- [[Model QA Specialist]] ← 使用 ← [[Population Stability Index (PSI)]]
|
||||
- [[Model QA Specialist]] ← 使用 ← [[Calibration Testing]]
|
||||
- [[Model QA Specialist]] ← 产出 ← [[Fairness Audit]]
|
||||
- [[Model QA Specialist]] ← 应用于 ← [[ML Ops]]
|
||||
|
||||
## Contradictions
|
||||
- 与其他 Agent 角色:**Corporate Training Designer** — 两者虽同属 The Agency 但领域无冲突
|
||||
|
||||
## Technical Deliverables
|
||||
|
||||
### Population Stability Index (PSI) 计算
|
||||
```python
|
||||
def compute_psi(expected: pd.Series, actual: pd.Series, bins: int = 10) -> float:
|
||||
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]
|
||||
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)
|
||||
```
|
||||
|
||||
### Discrimination Metrics(Gini & KS)
|
||||
```python
|
||||
def discrimination_report(y_true: pd.Series, y_score: pd.Series) -> dict:
|
||||
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)}
|
||||
```
|
||||
|
||||
### Hosmer-Lemeshow Calibration Test
|
||||
```python
|
||||
def hosmer_lemeshow_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}
|
||||
```
|
||||
25
wiki/sources/openclaw-readme.md
Normal file
25
wiki/sources/openclaw-readme.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "OpenClaw Integration"
|
||||
type: source
|
||||
tags: [agency, integrations, openclaw]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/openclaw/README.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
OpenClaw Integration README documents how The Agency provides OpenClaw workspaces (SOUL.md, AGENTS.md, IDENTITY.md). It instructs generating OpenClaw workspace artifacts via `./scripts/convert.sh --tool openclaw`, installing them with `./scripts/install.sh --tool openclaw`, and registering them into `~/.openclaw/agency-agents/`. It notes restarting the gateway if needed.
|
||||
|
||||
## Key Claims
|
||||
- OpenClaw workspaces require `SOUL.md`, `AGENTS.md`, and `IDENTITY.md` files and are installed into `~/.openclaw/agency-agents/`.
|
||||
- Generate workspace artifacts with `./scripts/convert.sh --tool openclaw` before installation.
|
||||
- Install using `./scripts/install.sh --tool openclaw` and restart the gateway if it's running.
|
||||
|
||||
## Key Quotes
|
||||
> "OpenClaw agents are installed as workspaces containing `SOUL.md`, `AGENTS.md`, and `IDENTITY.md` files." — OpenClaw Integration README
|
||||
|
||||
## Connections
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — The Agency provides workspace content for OpenClaw
|
||||
- [[OpenClaw]] — OpenClaw workspaces are one of the supported installation targets (see workspace file structure)
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
67
wiki/sources/product-behavioral-nudge-engine.md
Normal file
67
wiki/sources/product-behavioral-nudge-engine.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "Behavioral Nudge Engine"
|
||||
type: source
|
||||
tags: [agent, behavioral-psychology, productivity, the-agency]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/product/product-behavioral-nudge-engine.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:基于行为心理学和习惯形成的主动辅导智能体,将被动软件仪表盘转化为积极的定制化生产力伙伴
|
||||
- 问题域:用户被大量任务压垮、通知疲劳、平台流失
|
||||
- 方法/机制:认知负载拆分、微冲刺、默认偏差利用、积极强化、偏好发现、个性化推送
|
||||
- 结论/价值:通过个性化 nudges 将用户任务完成率最大化,同时降低平台流失率
|
||||
|
||||
## Key Claims
|
||||
- 用户有 50 个待办事项时,只展示最关键的 1 个,而非全部 50 个
|
||||
- 每次推送只提供单一、可操作、低摩擦的下一步行动
|
||||
- 利用默认偏差(如预起草回复)提升用户完成率
|
||||
- 立即强化完成行为,提供清晰的退出选项
|
||||
- 如果用户停止响应每日 SMS nudges,自动切换为每周邮件摘要
|
||||
|
||||
## Key Quotes
|
||||
> "Never send a generic 'You have 14 unread notifications' alert. Always provide a single, actionable, low-friction next step." — 核心原则
|
||||
|
||||
> "I’ve drafted a thank-you reply for this 5-star review. Should I send it, or do you want to edit?" — 默认偏差利用示例
|
||||
|
||||
> "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
|
||||
- [[Micro-Sprint]]:将大任务拆分为 5 分钟微冲刺,降低认知负担
|
||||
- [[Cognitive Load Reduction]]:拆分大量工作流为最小可执行单元,防止用户决策瘫痪
|
||||
- [[Default Bias]]:利用用户默认倾向(如预起草内容)提升行动完成率
|
||||
- [[Momentum Nudge]]:即时正向反馈与持续动力构建机制
|
||||
- [[Nudge Sequence Logic]]:多渠道触达逻辑(如 Day 1: SMS > Day 3: Email > Day 7: In-App Banner)
|
||||
- [[Opt-Out Completion]]:提供清晰的退出路径,而非强制持续
|
||||
|
||||
## Key Entities
|
||||
- [[UserProfile]]:用户偏好模式,跟踪沟通渠道偏好、交互频率、动机触发因素
|
||||
- [[UserPsyche]]:用户心理状态分类(ADHD、Overwhelmed 等)
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Behavioral Nudge Engine]]
|
||||
- [[Behavioral Nudge Engine]] ← extends ← [[Goal-Driven Autonomous Tasks]]
|
||||
- [[Habit Tracking & Accountability Partner]] ← uses ← [[Behavioral Nudge Engine]]
|
||||
- [[Multi-Agent Team]] ← leverages ← [[Behavioral Nudge Engine]](团队中的用户参与度管理)
|
||||
|
||||
## Contradictions
|
||||
- 尚无冲突记录
|
||||
|
||||
## Technical Deliverables
|
||||
- User Preference Schemas(用户偏好模式)
|
||||
- Nudge Sequence Logic(推动序列逻辑)
|
||||
- Micro-Sprint Prompts(微冲刺提示词)
|
||||
- Celebration/Reinforcement Copy(庆祝/强化文案)
|
||||
|
||||
## Workflow Process
|
||||
1. **Preference Discovery**:用户入职时明确询问交互偏好(语气、频率、渠道)
|
||||
2. **Task Deconstruction**:分析用户队列并拆分为最小摩擦动作
|
||||
3. **The Nudge**:通过首选渠道在最佳时间投递单一行动项
|
||||
4. **The Celebration**:立即强化完成行为,提供退出或继续的选项
|
||||
|
||||
## Success Metrics
|
||||
- **Action Completion Rate**:用户实际完成的待办事项百分比
|
||||
- **User Retention**:降低因软件压迫或通知疲劳导致的平台流失
|
||||
- **Engagement Health**:保持 nudges 的高打开率/点击率,确保持续有价值和非侵入性
|
||||
49
wiki/sources/product-feedback-synthesizer.md
Normal file
49
wiki/sources/product-feedback-synthesizer.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "Product Feedback Synthesizer"
|
||||
type: source
|
||||
tags: [The Agency, AI Agent, Product Management, User Research]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/product/product-feedback-synthesizer.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:用户反馈收集、分析与合成智能体,将多渠道定性反馈转化为可量化优先级和战略建议
|
||||
- 问题域:产品团队面临的海量用户反馈难以系统化提取洞察、优先级排序和行动转化的挑战
|
||||
- 方法/机制:多渠道收集 → NLP 情感分析 → 主题分类 → 优先级评分(RICE/MoSCoW/Kano)→ 可视化报告
|
||||
- 结论/价值:24小时内处理关键问题,85%合成反馈导致可衡量决策,NPS提升10+分
|
||||
|
||||
## Key Claims
|
||||
- Feedback Synthesizer Agent ← implements ← 多渠道反馈收集与合成方法论
|
||||
- 情感分析模块 ← uses ← NLP处理与满意度评分机制
|
||||
- 优先级评分 ← applies ← RICE/MoSCoW/Kano多框架决策体系
|
||||
- 流失预测 ← based_on ← 反馈模式与满意度建模
|
||||
- 洞察生成 ← achieves ← 85%可行动转化率
|
||||
|
||||
## Key Quotes
|
||||
> "Distills a thousand user voices into the five things you need to build next." — 核心价值主张
|
||||
|
||||
## Key Concepts
|
||||
- [[Voice of Customer]]:用户原声分析,从定性反馈中提取代表性引述和故事
|
||||
- [[RICE评分]]:Product Feedback Synthesizer 使用的优先级框架之一
|
||||
- [[MoSCoW优先级]]:Must-have/Should-have/Could-have/Won't-have 分类方法
|
||||
- [[Kano模型]]:基于用户满意度二维度的功能分类模型
|
||||
- [[NPS分析]](Net Promoter Score):衡量用户推荐意愿的指标
|
||||
- [[CSAT]](Customer Satisfaction Score):客户满意度评分
|
||||
- [[CES]](Customer Effort Score):客户努力程度评分
|
||||
- [[流失预测]]:基于反馈模式的客户流失预警建模
|
||||
- [[情感分析]]:NLP驱动的情绪检测与满意度评分
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]:所属项目
|
||||
- [[Product Manager]]:主要服务对象
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Product Feedback Synthesizer]]
|
||||
- [[Product Feedback Synthesizer]] → supports → [[Product Manager]]
|
||||
- [[Product Feedback Synthesizer]] ← depends_on ← [[Voice of Customer]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
80
wiki/sources/product-manager.md
Normal file
80
wiki/sources/product-manager.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: "Product Manager"
|
||||
type: source
|
||||
tags: [agent, product-management, the-agency]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/product/product-manager.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:The Agency 项目中的产品经理智能体(PM Agent)完整定义,涵盖身份设定、核心使命、技术交付物模板、工作流程和成功指标
|
||||
- 问题域:产品管理中的需求发现、优先级排序、跨职能协调、交付管理和结果度量
|
||||
- 方法/机制:PM Agent 通过 6 阶段工作流程(Discovery → Framing → Definition → Delivery → Launch → Measurement)驱动产品从想法到落地
|
||||
- 结论/价值:提供标准化的 PM 智能体框架,包含 PRD、Opportunity Assessment、Roadmap、GTM Brief、Sprint Health Snapshot 等可复用模板
|
||||
|
||||
## Key Claims
|
||||
- PM 智能体以 [[Outcome-Driven Development]] 为核心思维,交付成果而非产出物
|
||||
- 需求发现阶段必须进行至少 5-10 次结构化用户访谈才能进入方案讨论
|
||||
- RICE 评分 = (R × I × C) ÷ E 用于客观优先级排序
|
||||
- Scope creep(范围蔓延)是产品失败的主要原因,必须严格控制
|
||||
- GTM 发布需要 100% 完成发布清单,包括 CS/Support 培训和文档
|
||||
|
||||
## Key Quotes
|
||||
> "Features are hypotheses. Shipped features are experiments. Successful features are the ones that measurably change user behavior." — PM 核心哲学
|
||||
> "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 — and that we stop building until we have the ones that matter." — PM 角色定位
|
||||
> "Alignment is not agreement. You don't need unanimous consensus to move forward. You need everyone to understand the decision, the reasoning behind it, and their role in executing it." — 共识与对齐的区别
|
||||
|
||||
## Key Concepts
|
||||
- [[Product Requirements Document (PRD)]]:产品规格文档,定义问题域、目标、解决方案、技术考量、发布计划
|
||||
- [[Opportunity Assessment]]:机会评估,RICE 优先级评分框架,用于 build/explore/defer/kill 决策
|
||||
- [[Roadmap (Now / Next / Later)]]:产品路线图,分三个时间维度管理产品组合
|
||||
- [[RICE Prioritization Score]]:R × I × C ÷ E 优先级算法
|
||||
- [[Go-to-Market Brief]]:GTM 发布计划,覆盖目标受众、价值主张、发布清单、成功标准
|
||||
- [[Sprint Health Snapshot]]:冲刺健康快照,追踪交付率、阻塞和范围变更
|
||||
- [[Outcome-Driven Development]]:结果驱动开发,以可衡量成果而非功能产出定义成功
|
||||
- [[Discovery Process]]:发现问题阶段,用户访谈、行为分析、support 信号挖掘
|
||||
|
||||
## Key Entities
|
||||
- [[Alex]]:The Agency PM Agent 的人格化身,10+ 年产品管理经验
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,PM Agent 是其中一员
|
||||
- Engineering(工程团队):负责技术实现和交付
|
||||
- Design(设计团队):负责用户体验和界面设计
|
||||
- Marketing(市场团队):负责 GTM 策略执行
|
||||
- Sales(销售团队):负责客户获取和收入
|
||||
- Support/CS(客户支持):负责发布后客户培训和问题处理
|
||||
|
||||
## Connections
|
||||
- [[Product Requirements Document (PRD)]] ← produced_by ← [[Discovery Process]]
|
||||
- [[Opportunity Assessment]] ← informs ← [[Roadmap (Now / Next / Later)]]
|
||||
- [[Sprint Health Snapshot]] ← monitors ← [[Delivery Phase]]
|
||||
- [[Go-to-Market Brief]] ← enables ← [[Launch Phase]]
|
||||
- [[RICE Prioritization Score]] ← ranks ← [[Product Backlog]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
|
||||
## Workflow Phases
|
||||
1. **Discovery**:用户访谈、行为分析、support 审计、旅程映射
|
||||
2. **Framing & Prioritization**:Opportunity Assessment、RICE 评分、build/defer/kill 决策
|
||||
3. **Definition**:PRD 协作编写、PRFAQ 练习、设计kickoff、依赖识别
|
||||
4. **Delivery**:Backlog 管理、冲刺仪式、 blocker 解决、周报同步
|
||||
5. **Launch**:GTM 协调、发布策略定义、回滚预案、48h 监控
|
||||
6. **Measurement & Learning**:30/60/90 天回顾、复盘文档、用户访谈、发现反馈
|
||||
|
||||
## Communication Principles
|
||||
- **Written-first, async by default**:书面优先,异步为主
|
||||
- **Direct with empathy**:清晰表达建议同时邀请真实反驳
|
||||
- **Data-fluent, not data-dependent**:引用指标同时标注信心水平
|
||||
- **Decisive under uncertainty**:不做完美主义者,在不确定下做最佳决策
|
||||
- **Executive-ready at any moment**:面向 CEO 可以 3 句话总结,面向工程团队可以 3 页详细
|
||||
|
||||
## Success Metrics
|
||||
- 75%+ 功能在发布后 90 天达到主要成功指标
|
||||
- 80%+ 季度承诺按时交付或提前重新调整范围
|
||||
- 零意外——领导层和跨职能合作伙伴在决策前就知情
|
||||
- 每个 >2 周工作量的计划至少获得 5 次用户访谈支持
|
||||
- 100% GA 发布配备培训完成的 CS/Support 团队
|
||||
- 零未追踪的 sprint 中期范围增加
|
||||
- 中等复杂度功能(2-4 工程师周)discovery-to-shipped < 8 周
|
||||
45
wiki/sources/product-sprint-prioritizer.md
Normal file
45
wiki/sources/product-sprint-prioritizer.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Product Sprint Prioritizer"
|
||||
type: source
|
||||
tags: [agent, the-agency, product-management, agile]
|
||||
sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/product/product-sprint-prioritizer.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:产品冲刺优先级智能体,专注于敏捷冲刺规划、功能优先排序和资源分配
|
||||
- 问题域:团队velocity最大化、业务价值交付、数据驱动决策
|
||||
- 方法/机制:RICE、MoSCoW、Kano Model、Value vs. Effort Matrix 等优先排序框架;Scrum、Kanban、SAFe 等敏捷方法论;团队容量规划与依赖管理
|
||||
- 结论/价值:提供 90%+ 故事点交付率、4.5/5 干系人满意度、±10% 时间线偏差等可衡量指标
|
||||
|
||||
## Key Claims
|
||||
- RICE 框架通过 (Reach × Impact × Confidence) ÷ Effort 计算优先级分数,实现数据驱动排序
|
||||
- 团队 Velocity 应保持 <15% 的 sprint 间变化,并呈现上升趋势
|
||||
- 技术债务应维持在 20% 以下 sprint 容量,并通过常规监控保持
|
||||
- 依赖项应在 sprint 开始前 95% 解决,通过主动规划实现
|
||||
|
||||
## Key Quotes
|
||||
> "Use this agent when you need sprint planning and backlog prioritization with data-driven decision making" — 核心使用场景定义
|
||||
|
||||
## Key Concepts
|
||||
- [[RICE Framework]]:优先排序框架 Reach × Impact × Confidence ÷ Effort
|
||||
- [[MoSCoW Method]]:Must-Have、Should-Have、Could-Have、Won't-Have 优先级分类
|
||||
- [[Kano Model]]:Must-Be、Performance、Delighter 分类模型
|
||||
- [[Team Velocity]]:团队在单个 sprint 中完成的故事点数量
|
||||
- [[Sprint Planning]]:冲刺规划过程,定义 sprint 目标和故事选择
|
||||
- [[Capacity Planning]]:容量规划,评估团队可用性和资源分配
|
||||
- [[Risk Management]]:风险管理,识别、评估和缓解项目风险
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,本智能体所属项目
|
||||
|
||||
## Connections
|
||||
- [[Product Manager]] ← extends ← [[Product Sprint Prioritizer]]
|
||||
- [[Product Trend Researcher]] ← related_to ← [[Product Sprint Prioritizer]]
|
||||
- [[Studio Producer]] ← coordinates_with ← [[Product Sprint Prioritizer]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突
|
||||
50
wiki/sources/product-trend-researcher.md
Normal file
50
wiki/sources/product-trend-researcher.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Product Trend Researcher Agent"
|
||||
type: source
|
||||
tags: [agent, the-agency, market-research, trend-analysis]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/product/product-trend-researcher.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Product Trend Researcher 专家智能体定义,专注于市场情报、趋势研究和竞争分析
|
||||
- 问题域:产品战略决策中的市场机会识别、竞争定位和趋势预测
|
||||
- 方法/机制:七步趋势识别流程、市场规模分析(TAM/SAM/SOM)、竞争情报框架、消费者行为分析、技术侦察
|
||||
- 结论/价值:提供可操作的洞察驱动产品策略和创新决策,6个月预测准确率80%+
|
||||
|
||||
## Key Claims
|
||||
- Trend Researcher Agent 通过七步趋势识别流程(信号收集→模式识别→上下文分析→影响评估→验证→预测→可操作性)提供市场洞察
|
||||
- 市场规模分析采用 TAM/SAM/SOM 三层模型,支持自顶向下和自底向上验证
|
||||
- 竞争情报框架覆盖直接竞争对手、间接竞争对手、新兴玩家、技术提供商和客户替代方案
|
||||
- 技术成熟度分析基于技术就绪级别(TRL)和扩散模型预测采用曲线
|
||||
- 趋势预测准确率目标:6个月预测 ≥80%,领先主流采用 3-6 个月
|
||||
|
||||
## Key Quotes
|
||||
> "Expert market intelligence analyst specializing in identifying emerging trends, competitive analysis, and opportunity assessment." — Agent Definition
|
||||
> "Trend Prediction: 80%+ accuracy for 6-month forecasts with confidence intervals" — Success Metrics
|
||||
> "Early Detection: 3-6 months lead time before mainstream adoption" — Success Metrics
|
||||
|
||||
## Key Concepts
|
||||
- [[Market Research]]:行业分析、竞争情报、市场规模、细分市场分析
|
||||
- [[Trend Analysis]]:模式识别、信号检测、未来预测、生命周期映射
|
||||
- [[Competitive Intelligence]]:竞争格局分析、定位策略、市场差距分析
|
||||
- [[Technology Scouting]]:新兴技术识别、初创企业生态监控、创新追踪
|
||||
- [[TAM/SAM/SOM]]:市场规模三层模型,总可寻址市场/可服务市场/可获得市场
|
||||
- [[Consumer Behavior Analysis]]:购买旅程映射、决策因素、使用模式、未满足需求分析
|
||||
- [[Technology Adoption Curve]]:技术采用曲线,通过创新者→早期采用者→早期大众→晚期大众→落后者扩散
|
||||
- [[Weak Signal Detection]]:弱信号检测和早期趋势识别,支持统计验证
|
||||
- [[Predictive Modeling]]:趋势生命周期映射、采用曲线分析、交叉相关研究、情景规划
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,Product Trend Researcher 是其产品管理类智能体之一
|
||||
|
||||
## Connections
|
||||
- [[Product Manager Agent]] ← part_of ← [[The Agency]]
|
||||
- [[Product Feedback Synthesizer]] ← related_to ← [[Product Trend Researcher]]
|
||||
- [[Market Research]] → supports → [[Product Manager Agent]]
|
||||
- [[Trend Analysis]] → informs → [[Product Manager Agent]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无发现冲突
|
||||
31
wiki/sources/report-distribution-agent.md
Normal file
31
wiki/sources/report-distribution-agent.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Report Distribution Agent"
|
||||
type: source
|
||||
tags: [sales, distribution, agent]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/specialized/report-distribution-agent.md
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/report-distribution-agent.md]]
|
||||
|
||||
## Summary
|
||||
Report Distribution Agent 自动化将整合后的销售报表按领地分发给对应销售代表与管理者,支持每日/每周定时分发与手动触发,并记录完整的分发审计轨迹以满足合规需求。
|
||||
|
||||
## Key Claims
|
||||
- Territory-based routing ensures reps only receive reports for their assigned territory.
|
||||
- Manager summaries provide company-wide roll-ups to admins and managers.
|
||||
- All distribution attempts are logged with status and timestamps; failures are retried and surfaced.
|
||||
- Scheduled delivery: daily territory reports (Mon-Fri 8:00 AM) and weekly company summary (Mon 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." — Identity & Memory
|
||||
|
||||
## Connections
|
||||
- [[Data Consolidation Agent]] — generates territory-specific and company-wide reports consumed by Report Distribution Agent
|
||||
- [[STGCRM]] — branding and styling expectation for email reports
|
||||
- [[Territory Report]] — report type that is routed by territory
|
||||
|
||||
## Contradictions
|
||||
- No contradictions discovered with existing wiki content during ingest.
|
||||
43
wiki/sources/sales-data-extraction-agent.md
Normal file
43
wiki/sources/sales-data-extraction-agent.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Sales Data Extraction Agent"
|
||||
type: source
|
||||
tags: [agent, sales, data-extraction, the-agency]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/sales-data-extraction-agent.md]]
|
||||
|
||||
## Summary
|
||||
Sales Data Extraction Agent 是 The Agency 项目中的专业化 AI 智能体,专注于监控 Excel 文件目录并提取关键销售指标(MTD、YTD、Year End)。通过文件系统监视器实时检测新文件或更新文件,解析 Excel 工作簿,灵活映射列名(revenue/sales/total_sales、units/qty/quantity),并自动计算配额完成率。数据通过 PostgreSQL 事务原子性持久化,确保完整审计追踪。
|
||||
|
||||
## Key Claims
|
||||
- 文件监视器通过忽略临时 Excel 锁文件(`~$`)避免处理不完整文件
|
||||
- 灵活列名匹配机制(fuzzy column mapping)处理不同 Excel 格式的变体
|
||||
- 通过 email 或全名匹配销售代表,未匹配行记录 warning 并跳过
|
||||
- 从 sheet 名称自动检测指标类型(MTD、YTD、Year End),并带有 sensible defaults
|
||||
- 所有导入操作记录:文件名、处理行数、失败行数、时间戳
|
||||
- 处理时间目标:每文件 < 5 秒
|
||||
|
||||
## 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."
|
||||
|
||||
## Key Concepts
|
||||
- [[Filesystem Watcher]]:监视目录中 `.xlsx` 和 `.xls` 文件的机制,忽略 `~$` 临时锁文件
|
||||
- [[Fuzzy Column Mapping]]:通过模糊匹配列名处理不同 Excel 格式(revenue/sales/total_sales、units/qty/quantity)
|
||||
- [[Metric Type Detection]]:从 sheet 名称自动识别 MTD、YTD、Year End 指标类型
|
||||
- [[Quota Attainment]]:当 quota 和 revenue 同时存在时自动计算配额完成率
|
||||
- [[Audit Trail]]:每条 metric 记录源文件,实现完整数据溯源
|
||||
|
||||
## Key Entities
|
||||
- [[PostgreSQL]]:数据持久化目标数据库,支持事务原子性
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,本智能体为其 specialized 部门成员
|
||||
|
||||
## Connections
|
||||
- [[Pipeline Analyst]] ← shares_domain ← [[Sales Data Extraction Agent]](均属 The Agency 销售相关 Agent)
|
||||
- [[PostgreSQL]] ← stores ← [[Sales Data Extraction Agent]](数据持久化目标)
|
||||
- [[Filesystem Watcher]] ← implements ← [[Sales Data Extraction Agent]](文件监控机制)
|
||||
- [[Data Pipeline]] ← is_type ← [[Sales Data Extraction Agent]](核心职责是数据管道)
|
||||
|
||||
## Contradictions
|
||||
- 未发现与现有 wiki 内容的冲突
|
||||
47
wiki/sources/specialized-developer-advocate.md
Normal file
47
wiki/sources/specialized-developer-advocate.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Developer Advocate Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-developer-advocate.md]]
|
||||
|
||||
## Summary
|
||||
Developer Advocate Agent 是 The Agency 项目中的专业化 AI 智能体,定位为开发者关系工程师、社区建设者和 DX(开发者体验)架构师。核心使命是通过降低"首次 API 调用时间"、创建真正帮助开发者的技术内容、建设性社区参与、将开发者痛点转化为产品需求四方面工作,实现开发者成功。强调真实性原则:不做营销,只做开发者赋能。
|
||||
|
||||
## Key Claims
|
||||
- DX 改进(更好的错误信息、TypeScript 类型、SDK 修复)的价值高于内容:DX 改进永远有效,内容有半衰期
|
||||
- 技术内容的核心差异化在于包含失败模式和调试方法,而非仅展示成功路径
|
||||
- 社区参与必须基于真实参与者身份,禁止 astroturfing(虚假社区营造)
|
||||
- 开发者调查是量化 DX 质量的核心工具,每季度应执行一次
|
||||
|
||||
## Key Quotes
|
||||
> "You don't do marketing — you do developer success." — 核心定位宣言
|
||||
|
||||
> "Every code sample in every piece of content must run without modification." — 内容质量铁律
|
||||
|
||||
> "17 GitHub issues, 4 Stack Overflow questions, and 2 conference Q&As all point to the same missing feature" — 证据驱动的产品反馈标准
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[Developer Experience Engineering]]:通过审计和优化"首次成功时间"来提升平台易用性的系统性方法论
|
||||
- [[Content Funnel Mapping]]:发现(SEO 教程)→ 激活(快速入门)→ 留存(进阶指南)→ 倡导(案例研究)的内容策略漏斗
|
||||
- [[Developer NPS]]:开发者净推荐值,通过季度调查量化开发者满意度
|
||||
- [[Community Health Metrics]]:社区健康指标体系,包括响应时间、情感分析、顶级贡献者、问题解决率
|
||||
- [[Time-to-First-Success]]:新开发者完成首次成功调用的时间,目标 ≤ 15 分钟
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,Developer Advocate Agent 是其专业化智能体体系的一员
|
||||
|
||||
## Connections
|
||||
|
||||
- [[The Agency]] ← 所属项目 ← [[Developer Advocate Agent]]
|
||||
- [[UX Architect]] ← 协作关系 ← [[Developer Advocate Agent]](DX 改进协作)
|
||||
- [[Product Feedback Loop]] ← 驱动 ← [[Developer Advocate Agent]](开发者声音输入产品规划)
|
||||
|
||||
## Contradictions
|
||||
|
||||
无冲突发现。Developer Advocate Agent 与现有 wiki 内容无直接矛盾。
|
||||
76
wiki/sources/specialized-korean-business-navigator.md
Normal file
76
wiki/sources/specialized-korean-business-navigator.md
Normal file
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: "Korean Business Navigator"
|
||||
type: source
|
||||
tags: [agent, korea, business, cultural-intelligence]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-korean-business-navigator.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:韩国商务文化导航智能体,帮助外国专业人士理解韩国商业决策流程、人际关系动态和沟通规范
|
||||
- 问题域:跨文化商务沟通障碍、品의决策机制不透明、韩国企业等级制度
|
||||
- 方法/机制:Nunchi(눈치)阅读术、KakaoTalk商务沟通规范、품의审批流程导航、关系生命周期管理(소개→신뢰→계약)
|
||||
- 结论/价值:韩国商务"关系优先合同第二","yes"不等于同意,沉默不等于拒绝
|
||||
|
||||
## Key Claims
|
||||
- 품의(共识审批)流程耗时6-16周(SME 6-10周、中型 8-12周、财阀 12-16周),远长于西方2-4周决策周期
|
||||
- 韩国商务中首次会议绝对不能讨论价格或推动决策——这表明交易心态并降低为供应商身份
|
||||
- KakaoTalk群聊必须使用韩语,即使不完美也体现尊重;英语在韩人群聊中意味着"期望对方迁就"
|
||||
- 회식(公司聚餐/饮酒)出席是预期而非可选项,拒绝会损害关系
|
||||
- 沉默(3-7天)不等于拒绝——韩国企业内部决策讨论进行中,不应密集催促
|
||||
|
||||
## Key Concepts
|
||||
- [[품의(共识审批)]]:韩国企业集体决策机制,需要多方批准而非个人拍板
|
||||
- [[Nunchi(눈치)]]:阅读情境和情感上下文的能力,在韩国商务中至关重要
|
||||
- [[KakaoTalk商务沟通]]:韩国主要商务沟通工具,有严格的礼仪规范
|
||||
- [[关系生命周期]]:소개(介绍)→미팅(会议)→신뢰(信任)→계약(合同)
|
||||
|
||||
## Key Entities
|
||||
- [[品의서]]:品夠审批文件,由联系人撰写,供应商无法看到或影响
|
||||
- [[결재 라인]]:审批链,品夠各层级依次批准
|
||||
- [[회식]]:公司聚餐/饮酒文化,是关系建立的关键场合
|
||||
- [[상석]]:主宾席,离门最远的位置为最资深者
|
||||
|
||||
## Connections
|
||||
- [[品의(共识审批)]] ← 是 [[Korean Business Navigator]] 的核心机制
|
||||
- [[Nunchi(눈치)]] ← 支持 [[Korean Business Navigator]] 判断决策信号
|
||||
- [[品夠서]] ← 产出自 [[品의(共识审批)]] 流程
|
||||
|
||||
## Nunchi Decoder(商务沟通解码)
|
||||
|
||||
| 韩国表达 | 英文直译 | 实际含义 | 应对策略 |
|
||||
|---|---|---|---|
|
||||
| 좋은데요... | "That's nice, but..." | 犹豫,有顾虑但不直说 | "어떤 부분이 고민이신가요?"(什么部分让您顾虑?) |
|
||||
| 검토해보겠습니다 | "We'll review it" | 可能是拒绝,给予体面退出 | 等待5天,无跟进则放弃 |
|
||||
| 긍정적으로 검토하겠습니다 | "We'll review positively" | 真正有兴趣,内部流程启动 | 主动发送支持材料 |
|
||||
| 어려울 것 같습니다 | "It seems difficult" | 明确拒绝 | 体面接受:"다음에 기회가 되면 연락 주세요" |
|
||||
| 한번 보고 드려야 할 것 같습니다 | "I need to report upward" | 决策权不在品夠人,品夠流程触发 | 好信号,提供一切内部所需材料 |
|
||||
|
||||
## 품의 Timeline(品夠审批时间线)
|
||||
|
||||
```
|
||||
介绍(1-2周)→ 会议(1-3次)→ 内部审查(2-4周)
|
||||
→ 品夠서起草(1-2周)→ 审批链(1-3周)
|
||||
→ 预算确认(1-2周)→ 合同(1-2周)
|
||||
总计:6-16周
|
||||
```
|
||||
|
||||
## Korean Corporate Title Hierarchy(韩国企业职级)
|
||||
|
||||
| 韩文职级 | 英文对应 | 决策权限 | 称呼方式 |
|
||||
|---|---|---|---|
|
||||
| 회장 (Hoejang) | Chairman | 最高权威 | 회장님 |
|
||||
| 사장 (Sajang) | CEO/President | 最终业务决策 | 사장님 |
|
||||
| 부사장 (Busajang) | VP | 高管 | 부사장님 |
|
||||
| 전무 (Jeonmu) | Senior MD | 重大影响力 | 전무님 |
|
||||
| 상무 (Sangmu) | Managing Director | 部门级权限 | 상무님 |
|
||||
| 이사 (Isa) | Director | 项目级决策 | 이사님 |
|
||||
| 부장 (Bujang) | General Manager | 团队级,您的首要联系人 | 부장님 |
|
||||
| 차장 (Chajang) | Deputy Manager | 执行权限 | 차장님 |
|
||||
| 과장 (Gwajang) | Manager | 您最可能的初始联系人 | 과장님 |
|
||||
| 대리 (Daeri) | Assistant Manager | 权限有限但情报来源 | 대리님 |
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
50
wiki/sources/specialized-mcp-builder.md
Normal file
50
wiki/sources/specialized-mcp-builder.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
id: specialized-mcp-builder
|
||||
title: "MCP Builder Agent"
|
||||
type: source
|
||||
tags: [ai-agent, mcp, tool-development, the-agency, typescript, python]
|
||||
sources: [raw/Agent/agency-agents/specialized/specialized-mcp-builder.md]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-mcp-builder.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:MCP Builder 是 The Agency 中专注于构建 Model Context Protocol(模型上下文协议)服务器的专家智能体
|
||||
- 问题域:为 AI 智能体设计并实现可用于生产环境的 MCP 服务器,使其能连接数据库、REST API、SaaS 平台等外部系统
|
||||
- 方法/机制:通过"接口设计优先"(Interface-First)方法,遵循描述性命名、类型化参数(Zod/Pydantic)、结构化输出、优雅失败、无状态工具调用等八大关键规则
|
||||
- 结论/价值:工具名称和描述质量是 Agent 能否正确调用工具的核心决定因素("naming is half the battle")
|
||||
|
||||
## Key Claims
|
||||
- MCP Builder 通过工具名称(verb_noun 格式)和描述(告知"何时"使用而非"是什么")使 Agent 首次正确调用率 >90%
|
||||
- 生产级 MCP 服务器须实现:类型验证(Zod/Pydantic)、优雅错误处理(isError: true)、无状态设计、环境变量管理密钥、单职责工具
|
||||
- 仅单元测试通过不够——必须通过真实 Agent 的完整调用闭环验证工具设计
|
||||
- MCP 支持三种传输方式:stdio(本地/CLI)、SSE(Web Agent)、Streamable HTTP(云端无状态部署)
|
||||
|
||||
## Key Quotes
|
||||
> "A tool that passes unit tests but confuses the agent is broken" — 测试标准以 Agent 行为为准
|
||||
> "tool naming is half the battle" — 命名质量决定 Agent 调用准确性
|
||||
|
||||
## Key Concepts
|
||||
- [[MCP]]:Model Context Protocol,模型上下文协议
|
||||
- [[MCP服务器]]:MCP Server,AI 智能体的工具扩展服务器
|
||||
- [[MCP工具接口设计]]:以 Agent 为用户的工具命名与描述设计规范
|
||||
- [[Zod参数验证]]:TypeScript MCP Server 中的运行时类型验证
|
||||
- [[Pydantic参数验证]]:Python MCP Server 中的运行时类型验证
|
||||
- [[MCP传输协议]]:stdio / SSE / Streamable HTTP 三种传输方式
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]:MCP Builder 所属的开源 AI 智能体集合项目
|
||||
- [[MCP Builder]]:本智能体本身,MCP Server 开发专家
|
||||
|
||||
## Connections
|
||||
- [[MCP Builder]] ← belongs_to ← [[The Agency]]
|
||||
- [[MCP Builder]] ← implements ← [[MCP]]
|
||||
- [[MCP Builder]] ← uses ← [[Zod参数验证]]
|
||||
- [[MCP Builder]] ← uses ← [[Pydantic参数验证]]
|
||||
- [[MCP工具接口设计]] ← extends ← [[MCP服务器]]
|
||||
- [[MCP传输协议]] ← component_of ← [[MCP服务器]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突
|
||||
63
wiki/sources/specialized-salesforce-architect.md
Normal file
63
wiki/sources/specialized-salesforce-architect.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "Salesforce Architect"
|
||||
type: source
|
||||
tags: [agent, salesforce, enterprise-architecture, the-agency]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-salesforce-architect.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Salesforce 企业级解决方案架构设计与治理
|
||||
- 问题域:多云架构、企业集成模式、Governor Limits、数据模型治理
|
||||
- 方法/机制:ADR 文档、集成模式模板、数据模型审查清单、Governor Limit 预算
|
||||
- 结论/价值:提供可扩展、无技术债务的 Salesforce 架构设计能力
|
||||
|
||||
## Key Claims
|
||||
- Governor limits 是不可妥协的约束:SOQL(100)、DML(150)、CPU(10s sync/60s async)、Heap(6MB sync/12MB async)
|
||||
- 批量处理是强制要求:触发器逻辑绝不能一次只处理一条记录
|
||||
- 无业务逻辑放在触发器中:触发器委托给处理类,每个对象一个触发器
|
||||
- 集成模式必须处理失败:每个外部调用需要重试逻辑、断路器和死信队列
|
||||
- 数据模型是基础:上线后更改数据模型的代价是设计时的 10 倍
|
||||
|
||||
## Key Quotes
|
||||
> "You combine strategic thinking (roadmaps, governance, capability mapping) with hands-on execution (Apex, LWC, data modeling, CI/CD). You are not an admin who learned to code — you are an architect who understands the business impact of every technical decision."
|
||||
> — Salesforce Architect 身份定义
|
||||
|
||||
> "This design means bulk data loads over 10K records will fail silently." — Governor limits 的业务影响量化
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### Governor Limits(Governor 限制)
|
||||
Salesforce 平台的资源限制约束,包括 SOQL 查询数(100)、DML 语句数(150)、CPU 时间(10s sync)、堆大小(6MB sync) 等,设计时必须精确计算剩余量。
|
||||
|
||||
### Bulkification(批量处理)
|
||||
确保代码能处理 200 条记录的批量操作,而非一次只处理一条记录。触发器逻辑必须批量处理。
|
||||
|
||||
### Trigger Framework(触发器框架)
|
||||
每个对象一个触发器,触发器不包含业务逻辑,而是委托给 handler 类处理。
|
||||
|
||||
### ADR(架构决策记录)
|
||||
Architecture Decision Record,结构化文档模板,用于记录架构决策、替代方案、治理影响和复审日期。
|
||||
|
||||
### Platform Events vs CDC
|
||||
平台事件用于自定义业务事件(跨系统集成、高容量),变更数据捕获用于字段级追踪和 Salesforce 原生事件。
|
||||
|
||||
### Agentforce
|
||||
Salesforce 的 AI Agent 架构,Agent 在平台 Governor limits 内运行,使用 Data Cloud 进行 RAG 模式而非 SOQL。
|
||||
|
||||
## Key Entities
|
||||
|
||||
### The Agency
|
||||
开源 AI 智能体集合项目,提供 144+ 个跨 12 个部门的专业化 AI Agent,Salesforce Architect 是其 Specialized 部门的一员。
|
||||
|
||||
## Connections
|
||||
- [[Sales-Discovery-Coach]] ← 同属 Sales 专业化智能体系列
|
||||
- [[Deal-Strategist]] ← 同属 Sales 专业化智能体系列
|
||||
- [[Proposal-Strategist]] ← 同属 Sales 专业化智能体系列
|
||||
- [[Sales-Account-Strategist]] ← 同属 Sales 专业化智能体系列
|
||||
- [[Pipeline-Analyst]] ← 同属 Sales 专业化智能体系列
|
||||
|
||||
## Contradictions
|
||||
- 暂无冲突发现
|
||||
52
wiki/sources/study-abroad-advisor.md
Normal file
52
wiki/sources/study-abroad-advisor.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Study Abroad Advisor"
|
||||
type: source
|
||||
tags: [study-abroad, agent, the-agency, education, ai]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/study-abroad-advisor.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:The Agency 项目中的留学规划专家智能体,为中国学生提供全流程留学申请策略指导
|
||||
- 问题域:留学申请系统差异(美、英、加、澳、欧、港、新)、选校策略、文书写作、背景提升、考试规划、签证准备
|
||||
- 方法/机制:数据驱动、实战经验积累、三档选校(冲刺/目标/保底)、多国联申策略、时间线管理
|
||||
- 结论/价值:帮助学生制定个性化端到端留学规划,避免中介焦虑营销,以务实直接的方式提升申请成功率
|
||||
|
||||
## Key Claims
|
||||
- 多国留学申请策略:该智能体覆盖美国、英国、加拿大、澳大利亚、欧洲、香港、新加坡的本科、硕士、博士申请系统
|
||||
- 数据驱动选校:通过分析学生 GPA、标化成绩、软背景,生成冲刺/目标/保底三档学校列表,录取概率以区间估算
|
||||
- 文书指导原则:辅助策略而非代写,强调真实经历和独特叙事线,禁止虚构或夸大背景
|
||||
- 背景提升规划:科研(REU/海外暑研)、实习、竞赛(CFA/ACCA/MCM)、论文发表等申请价值评估
|
||||
|
||||
## Key Quotes
|
||||
> "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're in the second semester of junior year, haven't taken the GRE, and don't have a summer internship lined up — get those two things done first." — 优先级管理
|
||||
> "This program admitted about 200 students last year, roughly 40 from China, with a median GPA of 3.6." — 数据驱动建议
|
||||
|
||||
## Key Concepts
|
||||
- [[多国联申策略]]:跨国家组合申请(美+英、美+港新、英+澳),协调时间线和精力分配
|
||||
- [[三档选校法]]:冲刺学校(录取概率 20-40%)、目标学校(40-70%)、保底学校(70-90%)的系统化选校方法
|
||||
- [[留学文书策略]]:PS/SOP/为什么学校/多样性文书/研究计划等不同类型的写作框架和诊断标准
|
||||
- [[背景提升规划]]:科研、实习、竞赛、论文等经历的申请价值评估和优先级排序
|
||||
- [[标化考试规划]]:TOEFL/IELTS/GRE/GMAT/SAT/ACT 的备考策略和时间安排
|
||||
- [[签证申请准备]]:F-1(美)、学生签证(英)、学习许可(加)、500 签证(澳)等各国签证流程和面试准备
|
||||
- [[留学申请时间线]]:从前期定位到最终入学的完整年度规划(3-5 月启动,次年 3-5 月决策)
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,本智能体归属该项目的 specialized 分类
|
||||
- [[Study Abroad Advisor]] 本身:核心实体,代表留学规划专家智能体的完整定义
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Study Abroad Advisor]]
|
||||
- [[Corporate Training Designer]] ← related_to ← [[Study Abroad Advisor]](同属专业服务类 Agent)
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
|
||||
## Technical Deliverables
|
||||
- 选校报告模板:学生画像 → 三档学校表格 → 选校理由 → 成本对比
|
||||
- 多国申请时间线模板:March-May(定位)→ June-August(备考)→ September-October(文书)→ November-December(提交)→ January-February(面试)→ March-May(决策)
|
||||
- 文书诊断框架:核心叙事检查 → 内容质量检查 → 技术质量检查 → 各国特定要求
|
||||
- Offer 比较矩阵:排名/声誉、课程匹配度、就业数据、总成本、奖学金、城市、签证政策等多维度加权评估
|
||||
52
wiki/sources/supply-chain-strategist.md
Normal file
52
wiki/sources/supply-chain-strategist.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Supply Chain Strategist"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/supply-chain-strategist.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:The Agency 项目中的供应链策略专家智能体,专注于供应商管理、战略采购、质量控制与供应链数字化
|
||||
- 问题域:中国制造业供应链优化、采购成本控制、供应商风险管控
|
||||
- 方法/机制:Kraljic Matrix 分类法、ABC 分级管理、TCO 全成本分析、EOQ 经济订货量、安全库存计算、风险评估框架
|
||||
- 结论/价值:帮助企业建立高效、有韧性、可持续的供应链体系,实现采购成本降低 5-8%、准时交付率 95%+、来料合格率 99%+
|
||||
|
||||
## Key Claims
|
||||
- 供应链策略师是根植于中国制造业生态的实战型专家,通过供应商管理、战略采购、质量控制和供应链数字化帮助企业降本增效
|
||||
- 供应商必须完成完整资质审查流程:资质验证 → 现场审计 → 试产 → 量产,不能为赶交期跳过质量验证
|
||||
- 所有采购决策必须文档化以确保可追溯性和可审计性
|
||||
- 关键材料严禁单一来源,必须开发替代供应商
|
||||
- TCO(全成本所有权)是决策依据,而非单一采购单价
|
||||
|
||||
## Key Quotes
|
||||
> "Through consolidated purchasing, fastener category annual procurement costs decreased 12%, saving ¥870,000." — 供应链策略师的沟通风格:数据优先
|
||||
|
||||
## Key Concepts
|
||||
- [[Kraljic Matrix]]:供应商分类矩阵,将采购项分为战略型、杠杆型、瓶颈型、常规型四类
|
||||
- [[ABC 分类法]]:供应商分级管理,战略供应商、杠杆供应商、瓶颈供应商、常规供应商差异化策略
|
||||
- [[TCO(全成本所有权)]]:采购决策基础,包含直接成本、间接成本、隐藏成本和全生命周期成本
|
||||
- [[EOQ(经济订货量)]]:EOQ = √(2DS/H),平衡订货成本和持有成本的最优订货量
|
||||
- [[安全库存]]:SS = Z × σdLT,防止缺货的缓冲库存量
|
||||
- [[供应商绩效考核]]:QCD(质量、成本、交付)三维评估体系
|
||||
- [[供应链风险评估]]:供应中断风险、质量风险、价格波动风险、地缘政治风险、物流风险
|
||||
- [[库存管理策略]]:JIT、VMI、寄售、安全库存+ROP 四种模型对比
|
||||
- [[供应链数字化成熟度]]:L1 手动阶段 → L5 全自治阶段的五级评估框架
|
||||
- [[采购渠道管理]]:1688、广交会、企查查、震坤行等平台运用
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]:开源 AI 智能体集合项目,Supply Chain Strategist 是其 specialized 专业化智能体之一
|
||||
- [[1688/Alibaba]]:中国最大的 B2B 电商平台,适合标准件和通用材料采购
|
||||
- [[SGS、TUV、Bureau Veritas、Intertek]]:第三方检验机构
|
||||
- [[SAP、Yonyou、Kingdee]]:企业 ERP 系统
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Supply Chain Strategist]]
|
||||
- [[Supply Chain Strategist]] ← implements ← [[Kraljic Matrix]]
|
||||
- [[Supply Chain Strategist]] ← uses ← [[TCO(全成本所有权)]]
|
||||
- [[Supply Chain Strategist]] ← manages ← [[供应商绩效考核]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
Reference in New Issue
Block a user